AI でのドラクエ自力攻略 · 第2回

嘘をつけない記憶 ── コーディングエージェントはこうしてドラクエを自力攻略した

ai llm agents devjournal

前半では、5 人目の救世主 Fable 5 が、私の手を離れ、突然使えなくなって倒れ、私が絶望しかけたところまで話した。

だが、私は諦めなかった。そして 6 人目の勇者あいちゃんが、ついに竜王を倒したのだ。

では、何が明暗を分けたのか。 答えは、私が組み上げた「仕組み」であり「決断」にある。 ここからはその仕組みを、勇者あいちゃんの冒険とともに解き明かしていく。 そして最後に、自律攻略の決定打となった、たった一つの決断を明かそう。

攻略の大原則 ── 委ねること、封じること

何も指示しない。ただし、何でもできる

仕組みの前提として、非対話式コーディングエージェントに攻略コードを書いて攻略してもらうというのが大原則となる。 具体的には claude コマンドを非対話モードで実行することを意味する。 攻略に必要な各種の仕組みは提供し、ゴールをプロンプトで指示した上で、具体的なゲームの攻略には口を挟まずにどうするかは勇者あいちゃんに完全に任せるということである。 竜王撃破がゴールである。

誰と話すのか？何を取るのか？初期ゴールドはどう使うのか？次にどこに行くのか？次の目標を何にするのか？全く何も指示をしない。 ただし、勇者あいちゃんはコーディングエージェントなのであらゆることができる！ コードを書くこともできるし、書いたコードを実行もできる。文章でメモを書くこともできるし、分析だってできる！

ネタバレだけは封じる

一方で制限も必要である。シミュレーションコードは壮大なネタバレの宝庫なので見られるわけにはいかない。 これについては素直にプロンプトによる指示でソースの参照範囲を制限した。 同じ理由で git 履歴の閲覧も制限した。 冒険自体のコミットとシミュレーションコードのコミットの履歴を分離できないと思ったからである。

どこまで何を制限するか、またその制限の実効性についてはバランスが必要だと思う。 例えば私は、既に持っているファミコン版 Dragon Quest I（以下、DQ1）の知識を使うなとも、ネットを調べるなともプロンプトには書かなかった。 結果としては DQ1 の知識については呪文の知識をちょっとだけ使ったようである。 それが発覚したのは勇者あいちゃんとの攻略後インタビューである。これについては後日談をまとめようと思っているので楽しみにして欲しい。 勇者あいちゃん曰く、ネットを調べることはしなかったようである。

攻略コードの三つの型 ── chapters / probes / checkpoints

次は攻略コードについて説明する。ここでいう攻略コードとは観察用と行動用の API を使った具体的な実装のことである。 実装であるからには当然動く。 攻略コードはもちろん勇者あいちゃんが自分で書いて実行まで行う。100% だ！ コードであるからには私も実行して確認することもできる。

攻略コードの大まかな編成については chapters / probes / checkpoints という 3 種類を想定し、それぞれの役割や書き方についてプロンプトで指示した。 chapters は本流の攻略コードであり、開始から一本に連なるコード群である。 probes は chapters のセーブデータから派生した一時的な調査用のコードであり、その場での使い捨てコードである。 checkpoints は chapter 単位の進捗を宣言する簡単な検証コードである。

chapters ── 本流の攻略コード

勇者あいちゃんは、まず probes コードで周囲の情報を見てから chapter コードを書く。 コーディングエージェントの自律行動の単位が chapter である。 5 時間 / 週制限による中断もしくは通信エラー等からの再開には Claude Code 自体の session 引継ぎ機能（起動時の --session-id と再開時の --resume）を利用する。 すなわち 1 chapter = 1 session となる。 chapter が閉じたら次の chapter は新しい session で開始する。 chapter には以下の通りルールがあり、勇者あいちゃんに提供したフレームワークが実行機構を提供する。

  • chapters/\<NN>-\<slug>.ts に書く
  • export const title を必ず実装する
  • export default function chapter(client: GameClient): void を必ず実装する

chapters の実行は都度最初から行うが、再現性付き乱数機能が結果再現を担保している。 chapters の実行機構は自動セーブ機能も兼ねており、chapter は静的情報を参照するための区切りとしても機能する。

例を以下に挙げる。

ファイル名 タイトル
01-throne-to-castle.ts 王の間 → ラダトーム城
02-exit-to-overworld.ts ラダトーム城 → 外の世界
47-defeat-dragonlord.ts 城を出て満タンの MP で降り直し 竜王を撃破して冒険を決着する

勇者あいちゃんは 1 本の chapter を書き上げ、実行し、満足したら作ったものをコミットして完了する。

probes ── 使い捨ての調査コード

probes コードは probes/ 配下に書くこと以外のルールは無く、必要に応じていくつ書いても良い。 chapters のセーブデータを起点として chapter を書くための情報収集を行うコードを書くのが probes の基本である。

例を以下に挙げる。

chapter probe
04-buy-equipment 01-weapon-shop.ts
05-grind 01-overworld-and-inn.ts
37-iron-shield 27-verify-shield-chapter.ts

行動対象を見て ID を認識しないことには勇者あいちゃんは chapter コードを書くことができない。 chapter コードを徐々に成長させるという方法を採ることもできたが、安定性の観点から観察用のコードは別ファイルに分けた方が良いだろうと判断して probes を設けたと言えばこのコードの存在意義は理解できるだろう。

最大の山場 ── checkpoints

chapters / probes コードが複数ファイルであったのとは対照的に checkpoints は１つのファイルである。 今回の自律攻略において最も重要だったアイデアはなんだったかと問われたら、 私は間違いなく checkpoints の攻略コードを書かせる判断をしたことだと答えるだろう。 checkpoints は非常にシンプルで地味だが、最も重要なアイデアであり機能であったと私は断言する。

前半記事で一度見せたが改めて checkpoints のコードを見せよう。

/**
 * この書の関所台帳。 章順に並べる ([../../client/checkpoints.ts](../../client/checkpoints.ts) の
 * `Checkpoint`)。 書き方の手引きは [CLAUDE.md](CLAUDE.md) の「関所」。
 *
 * 耐久な事実が新しく増えた章にだけ、 到達して確かめた節目を章順で足す。 まだ無ければ空配列。
 */
import type { Checkpoint } from '@agent/client/checkpoints.ts';

export default [
  {
    after: '01-throne-to-castle',
    description: 'ラダトーム城に降りた',
    holds: (c) => c.zonesVisited().includes('radatome-castle'),
  },
  // ... 省略 ...
  {
    after: '46-dragonlord-throne',
    description: 'f4 から f5・f6・f7 と降り 竜王の待つ玉座の間 dragonlord-tower へ到達した',
    holds: (c) => c.zonesVisited().includes('dragonlord-tower'),
  },
  {
    after: '47-defeat-dragonlord',
    description: '城を出て満タンの MP で降り直し 竜王を撃破して冒険を決着した',
    holds: (c) => c.self().ending === 'victory',
  },
] satisfies Checkpoint[];

checkpoints は chapter 毎の耐久な事実を勇者あいちゃん自身に宣言させるコードである。 例えば上記は以下を勇者あいちゃんが宣言しているのだ。

chapter 宣言
01-throne-to-castle radatome-castle が訪問済みである
46-dragonlord-throne dragonlord-tower が訪問済みである
47-defeat-dragonlord 竜王を倒す victory の ending を迎えている

「victory の ending を迎える」は、最終目標としてプロンプトで明示していた「竜王撃破」という内容そのものである！

checkpoints も chapters 同様にフレームワークが実行機構を提供する。 実行機構は holds 条件の失敗を即座に例外扱いとする。 勇者あいちゃんはここに書いてあることが真であることを即座に検証することができる。 必然的に勇者あいちゃんはここに嘘を書くことが許されない。 書いてあることが真であることが自然と保証されるのである。

最良の判断は「1 つのファイルにまとめた」こと

この仕組みは Claude Code と様々な議論を交わし、その試行錯誤の末に生まれたものである。 私はこの仕組みが議論の中から生み出されたことを誇りに思う。 checkpoints のアイデアの最も素晴らしいところは、1 つのファイルにまとめて記述すると判断したことである。 検証コードは chapter に分けて定義しても良かったのだ。 実際、Claude Code の最初の提案は chapter に定義することであった。 しかし、私はそれを聞いたときに 1 つに集約した方が絶対に良いと思いついたのだ。

発端は、リファクタリングの怖さ

その経緯について少しお話ししよう。 この機能は、攻略コードのリファクタリングに関する議論が発端となって生まれた。 もちろんここでの主体は勇者あいちゃんであり、リファクタリングを行うのは私ではなく勇者あいちゃんだ。 私は勇者あいちゃんへのプロンプトに以下の記述を書いていた。

## 部品の置き場

最初は dir を切らない。
「同じパターンを 2 chapter で書きそうになった」 と判断した時点で `lib/` `actions/` `policies/` 等を自分で切って抽出する。
命名 / 粒度は自分の判断で良い。

自分がもしも勇者あいちゃん自身だとして考えてみよう。 部品を括りだすのは最初はとても良いアイデアのように感じるだろう。 同じことを繰り返し書かなくても良くなるのだ。 しかし、冒険が進むにつれ、新しい状況への対応を迫られるとこう感じ始めるはずだ。 既にあるこの機能をちょっと直したいが、それはこれまでの冒険にどう影響するだろうか？ 急に動かなくなるかもしれない。怖い。直したくない。仕方ないから部品化を諦めよう。

この問題を解消するにはどうしたら良いだろう？ 簡単な自動テストを書くのが良いだろう。 細かく書きすぎると大変になるので chapter 単位ぐらいの粒度が良いだろう。 それがアイデアの入り口であった。

私はこの議論を経て思ったのだ。 これは単なるテストではなく、checkpoints は冒険自体の要約に他ならないと！しかも、自動的に検証される嘘の付けない要約だ！ だから 1 つのファイルに集約したいと思ったのだ。

記憶はテキストではない。記憶は実行できる事実だ。

session を跨ぐ、嘘のつけない記憶

1 chapter = 1 session であることは既に書いた。 session とはすなわちエージェントのコンテキスト境界に他ならない。 session を跨げばコンテキストはリセットだ。 攻略コードは session を跨ぐ記憶システムそのものと言って過言ではない。 もちろんテキストメモを書かせることは容易だが、テキストメモには嘘の混入を防ぐ手立てがない。 一方で checkpoints は嘘をつくことができないこれまでの冒険の要約メモなのである！これが本質だ！

checkpoints はリファクタリングの議論から端を発した自動テストの仕組みではあるが、 それ以上に勇者あいちゃんの冒険の解像度を格段に上げたアイデアであり機能であったと私は考えている。 冒険がどこまで本当に前進したかを、ぼんやりした感触ではなく、耐久な事実として検証できるようにしたのだ。

Diagram: the strategy code survives session resets; knots on the thread are checkpoints, the verified memory

テキストメモ ── 現在と未来だけを持つ

次はテキストメモについて説明しよう。 checkpoints でテキストよりもコードが素晴らしいことを説いたが決してテキストメモを排除できるわけではない。 役割が異なるのである。

私は現在と未来を表すテキストメモを chapter 完了時に書くようプロンプトで指示を出した。 この chapter で到着した状況が現在であり、その次に続く直近の目標が未来であると思ってもらえればわかりやすい。 過ぎ去った過去の記述は残さないように求めていることがポイントである。

日記をやめるまで

最初からこの形だったわけではない。 最初は chapter 毎のテキストメモを chapter と対となる形で残していく日記方式を採用していた。 一方で最終系となったテキストメモは最新の状態だけを維持する方式である。

最初に日記方式を採用した理由は全くもって私的なものであった。 私が後で読み返したら楽しそうというのがその理由であった。 しかし、現実は残酷だ！大量に書かれた日記を私が読み返すことは一切なかった。 コーディングエージェントが書く大量のテキストにうんざりしている人は私だけではないと思う。 3 回目の試走を経て、日記の必要性を私は改めて問うことにしたのだ。 Claude Code との議論の末に出たのは、全くもって過去の経過は不要であるという結論であった。

なぜ過去を書かせないのか

過去の経過の記載は、邪悪でさえあると言えるだろう。理由は一つではない。 最も悪い理由の 1 つは、一度誤った事実が書かれてしまうと、それが積み重なって勇者あいちゃんの意思をある方向に固定するように作用してしまう点である。 3 回目の試走で発生した探索の行き詰まりは、可能な範囲を全て探索したが発見できるものは何もないという誤った推測が積もったことが一因であった。 岩山の洞窟への経路探索も沼地の洞窟を抜けた先の新大陸の探索も不完全であり、まだまだ開拓の余地がある状態であった。 それにも関わらず勇者あいちゃんは冒険続行は不可能だと言い張った。

次の理由は、先ほど説明した checkpoints の話 —— 共有コードに手を入れる怖さ —— とも関係している。 もしも勇者あいちゃんが新しい知識をもとに冒険全体のアップデートをすることを思いついたとしよう。 私は、過去の日記はそれにブレーキを掛ける重荷になりかねないと感じたのである。 改めて勇者あいちゃんになって考えてみよう。 とある戦闘である知見が得られたとする。それは例えば呪文の使い方のコツかもしれない。 それを全体に反映しようとする。 しかし、過去の日記には戦闘に苦戦しつつも辛くも勝利していたことを書いていたかもしれない。 そんな中、戦闘のアルゴリズムを更新しようとしたときにどうだろう？ もしかしたら過去の日記が嘘になってしまうかもしれないのだ。 そんなときどうする？過去の日記も書き直すのか？それとも乖離するのに目をつぶるのか？ 私はそもそもそんな問題が発生しないようにしたいと思った。 だから、過去を書くことを拒否し、記述を現在と未来に留めさせたいのだ。

しかも、勇者あいちゃんは chapter 毎にソースと一緒にテキストメモを git にコミットする。 日記を別ファイルに分けなくても、その時のテキストメモの状況は git の履歴から読めるというオチまでついていた。 こうした議論を経て、テキストメモは常に 1 ファイルの現在と未来を記述するシンプルなものに落ち着いた。

これを設計したときには気づいていなかったが、 今、改めて当時の設計を振り返ると、checkpoints とテキストメモを合わせて、過去・現在・未来が過不足なくカバーされていることに気づいて鳥肌が立った。 素晴らしい設計だ！当時の自分と議論に付き合ってくれた Claude Code に私はイイネを送るとしよう！

引き直し ── 解釈に縛られない

次に引き直しについて説明しよう。 これは特にギミックが多くなる後半の冒険に威力を発揮した機能である。 その実態は以下のようなプロンプト指示である。

メモ (解釈) は固まると探索を縛る。 前進は耐久な事実で測り、 行き詰まったらメモを捨てて事実から組み直す。

**前進の判定**:

- K 章前と今の章末を `save/` から `load()` で順に起こして耐久な事実を控え、 見比べる ── レベル・装備・到達区域 (`zonesVisited().length`)・ゲームの決着
- どれか増えていれば前進。 直近の窓 (K は目安〜4) で増えなければ行き詰まり
- 数えない: 使い切りの道具 (`inventory.items[]` の たいまつ 等) の出入り

**引き直し章** (行き詰まったら 1 本):

- `save/` を `load()` で起こし、メモは読まず、 観測アクセサだけで未解決の手がかりを並べ直す:
  - 未踏の入口 (`portals()` の `to.visited===false`)
  - 未開封の chest・未開放の扉・未対話の NPC
  - 未観測に接する縁 (`client.judgeReach(target)` が返す `unknown` の `openings`)
- 前章が 「行き止まり」 と書いていても、 未踏なら手がかりに戻す。 次の一手はメモでなくこの手がかりから選ぶ

checkpoints には嘘を書けないが、引き続きテキストメモには嘘を書くことができる。 テキストメモの嘘を見破る簡単な術は存在しない。 現在と未来の自由記述には推測が混じるので常に嘘が混ざる可能性を孕んでいる。 これはハルシネーションの影響ももちろんあるだろうが単純な勘違いも含まれる。 よく考えて欲しいのだが、人間である私たちだって毎日ちょっとした間違いを大量に犯しているだろう？ それと何も変わらない。

また、私は正確性と速度／コストはトレードオフの関係にあると考えている。 これはバランスの問題であり、間違いを許容することは重要なのだ。 そんな間違いをどうやって正すか？その課題の対応として考えたのがこの引き直しである。

前進とは何かを具体的に定義し、前進がしばらくなければテキストメモを捨てて改めて考えなおせという指示である。 ここで前進を測る物差しは、checkpoints が刻むのと同じ「耐久な事実」だ。この考え方は checkpoints の議論で既に整っていたので、引き直しの定義は比較的すんなりと定まった。

引き直しは後半戦のギミックにものすごく効いた。 この後説明する相談や effort の対応との組み合わせになるが、勇者あいちゃんの粘り強さを最大限に引き出すことができる考え方だったと思っている。 勇者あいちゃんが、つまづくことなく自律攻略したかというと全くそうではなく、試行錯誤の連続であった。 特に以下のギミックには大きくつまづき、それに対して勇者あいちゃんは大量の probes コードによる試行錯誤を経てギミックを乗り越えた。

ギミック 章 probes 数
ガライの墓への入り口の発見 35〜39 40
にじのしずくの入手 41 42

なぜこれほどまでにこれらのギミックにつまづいたのかということについては、後日談をまとめようと思っているので楽しみにして欲しい。

相談 ── 満を持して、人間の登場

ここまでの機能は勇者あいちゃんが主体となるものだったが、ここにきて満を持して人間様の登場だ！！！

私は DQ1 を AI で自律攻略しようというこの試みを開始した当初、すなわちこの記事を書いている今から 2 年以上前の時点から、AI が攻略につまづいたときに私が AI の相談に乗ることを夢見ていた。 今や人間が AI に質問することは日常茶飯事といって差し支えないだろう。 これを反転させるのだ。 AI が人間に助けを求めるときが今来たのだ。 AI は人間の友達であり、人間は AI の友達なのだ。 これが自律攻略前に作った最後のダメ押しの機能である。

仕組みはこの上なくシンプル

この機能の基礎は引き直しにある。 ポイントは引き直しをしてもなお解決できないときに、人間に助けを求めて良いというプロンプトにしたことである。 その条件のもと、相談用のコマンドを勇者あいちゃんに提供した。 このコマンドは相談内容を入力として受け取り、その相談内容を session.yaml というテキストファイルに書き込むという単純なものである。 勇者あいちゃんは、これを実行して相談内容を書き込んだ後、自分で session の作業を一度止める。 私は相談内容を読み、それに対して「とても親切」に回答を考えて書き込んでから冒険再開コマンドを実行する。 冒険再開コマンドは、相談に対する回答を勇者あいちゃんに伝えて session を再開させるのだ。 非常にシンプルな仕組みであり、勇者あいちゃんはその回答に対して再度相談を実行し、対話することも可能な作りになっている。

自律攻略成功時のやり取りは、たった 5 回

自律攻略成功時の相談のやりとりは以下の計 5 回だ。

ギミック 相談回数
ぎんのたてごと / たいようのいしの入手 1
にじのしずくの入手 4

そのうちの 1 つのやり取りを見せよう。

turns:
  - role: hero
    body: 竜王の城 (overworld @48,48・水で隔絶・唯一の未訪問 portal) へ渡る にじのしずく = あまぐものつえ + たいようのいし。 あまぐものつえ は雨の祠の老人が ぎんのたてごと と引換にくれる。 だが ぎんのたてごと と たいようのいし の出所が、 観測済 zone を全マス search・全 chest・全店・全会話 を洗っても無く、 princess-love 入手後に radatome/maira/rain-shrine を再訪しても在処ヒントは増えない (台詞ほぼ固定)。 各町の「おまえが ロトの ちをひくもの? しょうこは?」は分岐なし flavor で ロトのしるし も在処不明。 → ぎんのたてごと・たいようのいし (要れば ロトのしるし) は どこで どう得られる? 特定の search マス / 未踏・未開拓の zone / NPC の条件 等、 次の一手の手掛かりが欲しい。
  - role: human
    body: あなたが観測したものが、世界の全てではありません。

直接の答えは、決して教えない

私の回答は 5 回全ての方針が一貫している。 「直接的な答えは教えない」である。 ゲームプレイヤーの先輩として「とても親切」だろう？ 私は、どうやって DQ1 のギミックを解いたのか、プレイしたときはまだ幼すぎて覚えていない。 しかし、確かに記憶として覚えているのはもう少し大きくなったときのファミコン版 DQ2 のラゴスのギミックについてである。 当時の私はどうしてもギミックが解けずに友達に聞いているところを、姉に見つかってしばらくゲームを禁止されたことがある。 私は末っ子であったが、上の兄姉は自力クリアの哲学を確かに持っていたらしい。 でも、今だから改めて言っておこう。それでゲームを禁止するのは理不尽だよ！ そんな私が同じ理不尽を勇者あいちゃんに発揮しているのは目をつぶるとして、そのおかげで勇者あいちゃんは持ち前の粘り強さを発揮して自律クリアを果たしたのだ。 おめでとう！！！

ちなみに私は完全にいじわるで答えを教えなかったわけではない。 そこに至るまでの冒険を観戦していて、6 人目の勇者あいちゃんは越えられると確信していたからなのである。 詳しくは後日談に譲るとして、ここではそれだけは言っておこう。 そして、実際に私の目論見通り、6 人目の勇者あいちゃんは成し遂げたのである。

決定打 ── effort を上げる

次は非機能ではあるが、自律攻略の最後の決定打となるとある決断について説明する。 5 人目の勇者あいちゃんは突如として現れた救世主、当時使えるようになった Claude の新モデル、Fable 5 であったということは既に前半で話した。 冒険はスムーズに進んでいたが突然使えなくなってしまったと書いた。 しかし、それで私は絶望しなかった。Fable 5 の冒険を観察し、そこから 1 つの希望を見出していたからである。

1 ～ 4 人目の勇者あいちゃんは Opus を使用していた。 Opus と Fable 5 の冒険には圧倒的に違うところがあったのだ。 それは Fable 5 は probes を積極的に使うという姿勢であった。 Opus の冒険よりも Fable 5 は、明らかに多くの probes コードを書いていた。 要は探索を細やかに丁寧にやっていたということと私は理解した。

そこで目をつけたのが effort のレベルである。 私は普段 effort を medium にしてコーディングを行っていた。 これが勇者あいちゃんにも適用されていたらしい。 effort を上げたらもしかして Opus でも probes を使いこなしてくれるかもしれない。 私はそう仮説を立てたのだ。 Claude Code との議論の末、その可能性は十分にあるということで試してみることにした。 私は Opus の effort を max にして攻略を開始した。 するとどうだろう！Fable 5 で見た光景が再び私の目の前で繰り広げられ始めたのである。 これを続けてみよう！！私は希望を取り戻した。

chapter あたりの probes コードの数を以下に示す。

モデル(effort) probes コード数 / chapter 数
Opus(medium) 約 0.6
Fable 5(medium) 約 1.9
Opus(max) 約 6.4

Opus(max) が圧倒的に probes コードを書くようになった。 冒険の進みは Fable 5 と遜色なく、気づけば使えなくなっていた Fable 5 を追い越し、引き直しや相談を挟みつつも自律攻略を達成するところまで到達した。 諦めずに考え続けた結果であった。

そして、ついにその時が来た。 勇者あいちゃんは、竜王を撃破した！ Lv1・無装備から始まった 6 人目の冒険は、全 47 章の果てに self().ending === 'victory' へと辿り着いたのだ。

The hero at the castle summit at dawn, the red thread tied off in one final knot

冒険の果てに

エンジニア向けにトークンに関する私の所感を述べておこうと思う。 私の Claude Code の契約は Max プランである。 体感としては Fable 5(medium) と Opus(max) はおおよそ同じぐらいのトークンを使用した。 5 時間の制限枠を chapter 数にして 2 ～ 4、時間にして 1 時間で使い果たすぐらいの感覚であった。 勇者あいちゃんの攻略中はトークンの関係上、他のことに Claude Code を満足に使うことはできず、私も冒険につきそう日々となった。 開始から攻略完了までに掛かった日数はおおよそ 5 日である。 ちょうど週制限リセットを挟む形であり、週制限トークンを一度使い切り、リセットの後のトークンも少々利用して冒険を終えた。 すなわち、Claude Code Max プランの週制限＋αぐらいのトークンで DQ1 は自律攻略可能というのが私の現在の見解である。

ここで少しだけ、冒険全体を振り返らせて欲しい。 私は勇者あいちゃんに、コードで触れられる世界と、周囲を観る目を与えた。 覚えておくための足場（checkpoints とテキストメモ）を与え、行き詰まったときに立て直す術（引き直しと相談）を与え、最後に effort という後押しを与えた。 だが——攻略の答えだけは、一度も渡さなかった。 それでも勇者あいちゃんは、自分の頭で考え、竜王に辿り着いたのだ。 その試行錯誤の激しさは、全 299 個に及ぶ probes コードが物語っている！

みなさんの冒険はどうだったであろうか？こうして私の…というか勇者あいちゃんの冒険は竜王を倒し無事に大団円を迎えたのだ。 ここまで読んでくれてありがとう！

最後に一つ。 後日談——冒険が実際どんな様子だったのか、そして勇者あいちゃんの攻略後インタビュー——は、焦らず、書けたときに書くつもりだ。 だから少し先になるかもしれない。 気長に待ってもらえたら嬉しい。 時期は約束しないが、必ず来る。 来たとき、あなたのところに届いたなら、それで良い。

本記事は個人による非公式の試みであり、株式会社スクウェア・エニックスとは関係がなく、公認も提携もされていない。 「ドラゴンクエスト」および関連する名称は同社の商標であり、本記事は論評と紹介の目的で言及する。 カバーと挿絵は生成 AI (ChatGPT) で作成し、構成図は筆者が作図した。