【ITニュース解説】Traceroute devlog #6

この開発日誌では、ゲーム開発を通じて、あるシステムエンジニアが経験した様々な挑戦と学びが語られている。プロジェクトの初期段階から温めていたアイデアの一つに、「パズルを自動で生成し、AIがレビューし、最終的に人間が承認する」という一連の自動処理の流れ、すなわちパイプラインの構築があった。このアイデアは、コードが一行も書かれる前から存在し、開発者の頭の中に絵として描かれていた。そして数ヶ月後、それが実際に動き出す様子を目にした時、それは単なる機能の完成というより、プロジェクト初日から抱えていた大きな目標が達成された瞬間だったと感じられたという。

しかし、その実現までの道のりは決して平坦ではなかった。最初の大きな課題は、レビューを担当するAIからの出力が途中で途切れてしまい、その不完全な回答をデータとして読み込もうとしたプログラムがエラーを起こし、システム全体が停止してしまったことだ。開発者はAIが生成するテキストの長さに上限を設けていたが、その制限がAIの「説明」を途中で切ってしまい、プログラムが正しく処理できなかったのだ。この問題を修正して再実行したところ、今度はシステムは停止しなかったが、パズルが見つかるまで無限に試行を繰り返すループに入ってしまい、処理が終わらないという事態が発生した。パズルを見つけるための試行回数に上限を設定していなかったため、システムは延々と探し続けてしまったのである。これも修正し、数分で一連の処理が完了するようになった。

しかし、まだ問題は残っていた。今度は、自動化されたシステムが、生成されたパズルをプログラムの設計図やコードが保管されている場所（リポジトリと呼ぶ）に書き込む権限を持っていなかったため、新しい変更をリポジトリに取り込んでもらうための提案（プルリクエストと呼ぶ）を開く段階で処理が拒否されたのだ。自動化システムには読み取り権限しか与えられておらず、書き込みは許可されていなかった。この権限を付与することでようやく処理が進むかと思いきや、最後に立ちはだかったのは、コードの問題ではなく、リポジトリ自体に設定されていた誰も有効にしていなかった項目だった。

このように、続けて発生した四つの失敗は、最初はパズル生成のアルゴリズムの問題かと思われたが、最終的にはAIの出力の限界、試行回数の上限、リポジトリへのアクセス権限、そしてリポジトリ自体の設定といった、パズル生成とは直接関係のない「権限や制限の連鎖」をデバッグすることになった。そしてこれらの問題を一つずつ解決した時、システムは初めて自動でプルリクエストを開き、無事に動作したのだ。「パイプラインが自己レビューする」という短い一文の裏には、これほど多くの「インフラの仕組み（plumbing）」が存在することを、開発者は身をもって理解したのである。

次に直面したのは、ゲーム内の予期せぬバグだった。まだクリアされていないはずのレベルが、あたかも完璧にプレイされたかのように、完了リストに満点として表示されるという奇妙な現象だ。このバグの原因は、それぞれは正しく機能しているはずの三つの要素の間にあったわずかな「ずれ」だった。一つ目は、レベルをクリアした際のアニメーションが意図的にゆっくりと再生されること。二つ目は、ゲームがレベルクリアを判定するタイミングが、プレイヤーがクリック操作をしてから少し遅れて行われること。そして三つ目は、この判定が「今現在ロードされているレベル」に対して行われる仕様になっていたことだ。プレイヤーはアニメーションの遅延中に別のレベルに移動できてしまうため、あるレベルで得られたはずのクリア結果が、遅れて実行された判定によって、その時メモリ上にロードされていた別のレベルに誤って記録されてしまうことがあったのだ。さらにデバッグを困難にしたのは、ゲームのセーブシステムが、既に記録されているスコアよりも改善されない誤った記録を「静かに破棄する」仕様だったことだ。このため、開発者はバグを再現させるために、手動でセーブデータをクリアする必要があった。この問題の解決策は、遅延して実行されるクリア判定の処理が、それが作成された際のセッションとまだ一致しているかを、その都度確認することだった。これにより、結果が誤ったレベルに適用されることを防ぐことができた。

開発のプロセスを通じて、他にも重要な学びがあった。プロジェクト当初は、変更を直接コードに書き込むのではなく、AIへの指示（プロンプト）として記述するという方針だったが、週の半ばで無意識のうちにファイルを直接編集する以前の習慣に戻ってしまっていたことに気づいたという。これは、誰かに指摘されて元の方針に戻したが、コードのバグというよりは、開発プロセスの運用に関する一時的な逸脱だった。

プロジェクトの始まりから、企画書だけを前にして一行もコードを書かなかった日を振り返ると、開発者が繰り返し実感したのは、紙の上では「完成した」と思えるものが、実際のユーザーやシステムの権限、あるいは外部サービスとの連携といった「現実」と触れ合った時に、全く異なる種類の「完成」を必要とすることだった。例えば、ゲームの「元に戻す」機能は、一度完全に作り直して初めて意図通りに機能した。また、「双方向パス」という機能は、開発者が用意したあらゆるテストをパスしたが、実際にプレイヤーがマウスで触れた途端に「何か違う」と感じられたという。ヒントシステムも、知らぬ間に他のパズルを台無しにしてしまうことがあったため、三度も再設計を重ねる必要があった。これらは真の意味での「失敗」ではなかった。むしろ、開発者の「意図」と「実際に構築されたもの」との間に存在するギャップが、予想よりも遅い段階で、そして別の層で現れただけのことだったと開発者は語る。

この開発日誌の筆者は、当初「パズルを解くAI（ソルバー）」の技術的な側面を、採用面接で自信を持って説明できるようになることを目指していた。探索範囲の絞り込み（pruning）、試行回数の管理（retry budget）、そしてパズルの難易度を、生成時の偶発的な要素ではなく、ソルバーが実際にパズルを解く過程でどれだけ苦労したかで測る方法など、重要な部分は説明できると考えている。しかし、それ以上に確信しているのは、もっと小さなことだという。それは、「エンドツーエンドで何かを作り上げ、それがどのように壊れたのかを追跡し、その修正方法を明確に説明できるようになった」という経験だ。これが、昨年7月、空の企画書を前にしてコードを一行も書かずに過ごした日々に、開発者が自分自身に証明しようとしていたことのほとんどだったのだ。

このエントリーが開発日誌の最終回となる。プロジェクト自体が完全に終わったわけではなく、まだ細部の調整やドキュメント作成の作業は残っている。しかし、この日誌全体を通して密かに追跡されていた、つまり「白紙の状態から始めて、実際に動き、ほとんど問題なく動作するものを構築できるのか」という、開発者自身の能力に関する問いへの答えは、すでにこれまでのエントリーのどこかで達成されていたことに、筆者は気づいたのだ。