第12章:総仕上げ(ゲームの制作)

Nanocodeは実際に何かを作れるのでしょうか?

「ゼロコードチャレンジ」:PythonとPygameを使用して、古典的なスネークゲームを作ります。ルールは単純で、Pythonのコードを1行も書いてはいけません。エージェントとは英語でのみコミュニケーションを取ります。

An icon of a info-circle1

補足: このデモには多くのAPI呼び出しが含まれています。レート制限(HTTP 429)に達した場合、エージェントは自動的に再試行します。長時間のセッションでは、制限を完全に回避するためにOllamaを通じてローカルモデルの使用を検討してください。

ステップ1:準備

プロジェクトルート(nanocode.py.envを含むディレクトリ)から、ゲーム用の作業ディレクトリを作成します:

1 mkdir -p snake_game
2 cp nanocode.py snake_game/
3 cp .env snake_game/
4 cd snake_game

本書のコードリポジトリを使用している場合は、ch11からコピーしてください:

1 mkdir -p snake_game
2 cp resources/code/ch11/nanocode.py snake_game/
3 cp .env snake_game/
4 cd snake_game

Pygameをインストール:

1 pip install pygame
An icon of a info-circle1

補足: Windowsでは、すぐに使えるはずです。macOSの場合、最初にSDLライブラリをインストールする必要があるかもしれません:brew install sdl2 sdl2_image sdl2_mixer sdl2_ttf。Linuxの場合、SDLの開発用パッケージをインストールしてください:sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev

ステップ2:アーキテクト(プランモード)

エージェントを起動します。設計図を描く前にレンガを積むことはできないので、まずはプランモードから始めます。

1 python nanocode.py

プロンプト:

1 Build a classic Snake game using Pygame. Include a score counter and Game Over screen with a restart option. Put ALL code in ONE file: snake.py. Write the plan in PLAN.md.

エージェントは write_file を使用して PLAN.md を作成します。その内容を確認してください。Snakeクラス、Foodクラス、そしてゲームループ—これらすべてを1つのファイルにまとめた概要が記載されているはずです。

内容が適切であれば、承認してください。

ステップ3:ビルダー(実行モード)

実行モードに切り替えます:

1 /mode act

プロンプト内容:

1 Implement the plan in snake.py. All code in one file.

ターミナルを確認してください:

1   → Writing snake.py

エージェントは PLAN.md に保存されているコンテキストに基づいてコードを生成しています。

ステップ4:現実確認

ゲームを実行する前に、タイムアウトの値を上げましょう。nanocode.py を開いて、RunCommand.execute()timeout=30timeout=300 に変更してください。デフォルトの30秒ではゲームを実際にプレイするのに十分な時間がありません。(これはゼロコードチャレンジにおける唯一の例外です。)

プロンプト:

1 Run the game with: python snake.py

エージェントが run_command を実行します。ウィンドウが表示されます。あなたはスネークゲームをプレイします。

クラッシュした場合: LLMは非決定的です。エージェントは最初の試行でバグを生成する可能性があります。AttributeError: 'Snake' object has no attribute 'draw' のようなエラーでゲームがクラッシュした場合、自分で修正しないでください。エージェントに標準エラー出力を確認させてください。

プロンプト:

1 The game crashed. Read the error and fix it.

エージェントはトレースバックを読み、read_fileを使用してバグを見つけ、edit_fileを使用して修正し、再度実行します。

ステップ5:方向転換(機能の拡張)

ゲームは動作しますが、見た目が良くありません。スネークは単なる緑の四角形の集まりです。エージェントのリファクタリング能力をストレステストしてみましょう。

プロンプト:

1 The game looks boring. Make the snake change color as it eats food, increase speed every 5 points, and search the web for 'cool retro game color palettes' to apply.

エージェントは以下を実行する必要があります:

  1. search_webを使用してカラーパレットを検索
  2. read_fileを使用して現在のレンダリングロジックを理解
  3. edit_fileを使用して新機能を注入
  4. ゲームを実行して検証

何が問題になるか

結果は私の場合と異なるでしょう—LLMは非決定的です。しかし、一般的に起こることと、注意すべき点を説明します。

最初の実行で起きがちな失敗:

  • ModuleNotFoundError: No module named 'pygame' — エージェントがインストールが必要なことを忘れているか、異なる環境でスクリプトを実行しています。最初にpip install pygameを実行するよう指示してください。
  • エージェントが定義したメソッドを呼び出し箇所でスペルミスしたことによるAttributeError。エラートレースバックを確認すると、エージェントはこれらをすぐに修正します。
  • 衝突判定での境界値エラー。蛇が壁をすり抜けたり、1ピクセル早く死んでしまったりします。これらの修正には2-3回の編集-実行-修正のイテレーションが必要です。

典型的なセッションの流れ:

私のテストでは、エージェントは通常2-4回のイテレーションで動作する(ただし見た目の悪い)ゲームを作成します。最初の記述ではクラッシュするものが生成されます。2回目か3回目の修正で動作するようになります。機能追加(色の変更、速度の調整など)のステップでは、エージェントが自身のコードを読み、的確な編集を行い、各変更を検証するため、さらに3-5回のイテレーションが必要になります。

最終的に、会話は15-20ラウンドに及びます。Claudeを使用している場合、圧縮のトリガーに注意してください—12-15ラウンド付近で、トークン数が75%のしきい値に近づくと「(会話を圧縮中…)」と表示されます。圧縮後、エージェントは初期ラウンドの詳細の一部を失いますが、作業は継続します。これは第9章のシステムが真価を発揮している例です。

エージェントが苦戦する部分:

Pygameの座標系とイベントループは扱いが難しいものです。エージェントは時々、正しくレンダリングされるものの、キーボード入力を適切に処理できないコードや、蛇の頭が体の後ろに表示されてしまうような順序で描画するコードを書きます。これらは人間なら一目で気付くバグですが、エージェントには分かりません—視覚的なフィードバックがなく、標準出力とエラー出力しか見えないためです。ゲームがエラーなく実行されても見た目がおかしい場合は、視覚的なバグを説明する必要があります:「蛇が逆向きにレンダリングされています—頭が前面にあるべきです。」

重要なのは最初から完璧を目指すことではありません。エージェントが収束すること—書いて、実行して、エラーを読んで、修正して、繰り返す—が重要で、これは11章にわたって構築してきたすべてのツールを活用しています。

まとめ

計画、実装、クラッシュ、デバッグ、修正、再実行—これが各章で学んだことの集大成です。

では、ここからどこへ向かうのでしょうか?

エピローグ

全体で約750行のPythonコードです。フレームワークは使用していません。nanocode.pyは自由に使えます。以下のようなことが可能です:

  • テストが成功した後に自動コミットするGit統合
  • フロントエンド作業のためのスクリーンショットベースのデバッグ(Claudeは画像を読み取れます)
  • Whisperを使用した音声入力で、タイプする代わりに話しかけることができます
  • チームが既に使用している外部サービスに接続するためのMCP

Claude Code、Cursor、Copilotのような本番環境のエージェントはこれ以上のことができます—ストリーミングレスポンス、並列ツール実行、tree-sitter解析、サンドボックス実行環境、数千ファイルにまたがるマルチファイルコンテキストウィンドウなどです。750行と750,000行の差は確かに存在します。しかし、アーキテクチャは同じです:脳、ループ、ツール、メモリ、そして安全性のためのハーネス。これで舞台裏で何が起きているのかが分かりましたね。

モデルは今後も改善を続けるでしょう。ハーネス—ループ、ツール、安全性チェック—その部分はエンジニアリングです。そしてその部分はこれからも変わることはありません。