10月27日、Patrick McCanna氏が「Grow Your "Agentic Prompt" One Section at a Time – blog」と題した記事を公開した。複数セッションにわたって自律的にループ動作するAIエージェントに指示を与え続けるとき、プロンプトへの追記が既存の動作を静かに壊す——この問題に悩むエージェント開発者に向けて、McCanna氏は自身のQuakeサーバー構築プロジェクトで実際に使ったプロンプト設計パターンを公開した。「新要件は新セクションとして追加し、既存セクションには手を触れない」というシンプルな原則を軸に、矛盾なくプロンプトを成長させる4つのコアパターンが詳解されている。
背景：「毎晩動くエージェント」のプロンプト問題
McCanna氏が取り組んだのは、家族向けQuakeゲームサーバーを毎晩AIエージェントが自律改善し続けるシステムだ。記事の冒頭でClaude Codeがエージェントの実行環境として登場しており、長時間・複数セッションにわたる自律作業の文脈でプロンプト設計の問題が語られている。このような用途では、プロンプトは単なる指示書ではなく「引き継ぎ文書」として機能する。セッションをまたいでも作業を続けられるよう、プロンプトがすべての文脈を保持しなければならない。
直面した問題はシンプルだ。新しい要件が出てくるたびにプロンプトを書き直すと、既存の動作していたルールが壊れる。ビルドループが8ラウンドを経て、sudoの権限制御、iPad対応、LLM連携など次々と新要件が追加されたこのプロジェクトでは、そのたびにプロンプト全体を書き直すのは危険すぎる。
氏が行き着いたのが「1セクションずつ追加していく」というアプローチだ。
コアパターン①：ゴールを一箇所にランク付けしておく
最も重要なパターンが、プロンプトの冒頭に優先順位付きのゴールリストを1回だけ書くというルールだ。
1. Protect existing services. Every service on this host keeps running exactly
as it runs today. A Quake feature that risks an existing service gets
dropped or redesigned.
2. Working LAN Quake. Quake clients on the LAN connect and play fun sessions.
3. Game modes. Deathmatch and Quake Team Fortress work.
4. Web app. A local web app serves players and the operator.
5. Creativity. The experience produces stories the family retells later.
問題の核心はここにある。エージェントはゴール間の競合に頻繁に直面する。例えば別サービスがすでに使用中のポートをQuakeが必要とする場合、「プレイヤーが接続できること」と「既存サービスを守ること」がぶつかる。優先順位がなければ、エージェントは既存サービスを止めてポートを空けてしまう可能性がある。
解決策は明快だ。ゴールをリストに1回だけ書き、各ルールセクションはそのゴール番号を参照するだけにする。セクションが増えてもゴールの「文言」は一箇所にしか存在しないため、セクション間でゴールの解釈がズレていく問題を防げる。
「各ルールセクションはそれが守る優先度番号を冒頭で示す。ふたつのルールが衝突した場合、エージェントは番号を比較し、番号の小さい方に従う」
コアパターン②：新要件は新セクションとして追加し、3箇所に紐付ける
新要件が出たとき、既存セクションには触れず、新しい見出しセクションを追加する。ただし追加後に必ず3箇所——「ビルド計画リスト」「受け入れ基準」「ディレクトリレイアウト」——を編集する。新セクションを書くだけでは不十分で、この3点への追記がセットになってはじめてエージェントが「何を作り・何をテストし・どこに置くか」を一貫して把握できる。
iPad対応を追加した際の実例を示す。
ビルド計画への追記：
- Client bundle contents and install flow for Linux, plus the chosen iPad and
iPhone path: browser client hosting and transport bridge, or native app
build and install procedure, including any local TLS setup and the
per-device onboarding steps.
受け入れ基準への追記：
- An iPad and an iPhone each complete the documented onboarding and join the
same match as a Linux client, with playable frame rate and working touch or
controller input.
ディレクトリへの追記：
ios-ui/ # Apple device UI configs, envelope, tests, telemetry, fast-loop log
この3点セットを忘れると何が起きるか。エージェントはiPadの調査はするが、実装もテストもしないまま終わる。セクション単体では「研究して終わり」になってしまう。
コアパターン③：各フェーズの成果物ファイルを明示する
各フェーズの末尾にArtifact:行を設け、そのフェーズが完了したときに存在すべきファイル一覧を書く。
Artifact: STATE/discovery.md, STATE/storage-decision.md, STATE/blog-howto.md,
STATE/healthcheck.sh, STATE/baseline-health.md
このファイル群は進捗記録であると同時に、セッションが中断された際の「再開地点」となる。次のセッションのエージェントはこのファイルを読むことで、前回どこまで進んだかを把握できる。
コアパターン④：曖昧な要件は解釈を明文化してから動かす
「最後の訪問の翌日に見られる日次レポートページ」という要件があったとする。「誰かの訪問」の翌日なのか「特定のユーザーの訪問」の翌日なのか、解釈は分かれる。
McCanna氏のアプローチ：どちらかの解釈をプロンプトに書き、エージェントを動かす前に依頼者にその解釈を伝える。解釈が間違っていれば1メッセージで直せる。エージェントが1週間動いた後に発覚すれば、ログを読み返してどこで何が起きたかを追う羽目になる。
最初からやり直すとしたら
McCanna氏は「次のプロジェクトでは最初からこうする」として2点を挙げている。
- 最初のドラフトに「Plan contents」「Acceptance criteria」「Directory layout」の空見出しを入れておく。この3つが最初からあれば、新セクション追加のたびに自然とチェックリストとして機能する。
- 優先度リストを最初に書き、すべてのルールに優先度番号を付ける。番号のないルールはエージェントにとって「どれだけ重要か不明な指示」になる。
このシリーズはまだ続いており、ループの安全な実行、使用状況によるインターフェース自動改善、プロンプト自己改善など、6つのテーマが予定されている。一発起動の使い捨てプロンプトにはほぼ恩恵がないが、複数サイクルを繰り返すエージェント開発では、複利効果のように各サイクルの品質が積み上がっていくと氏は述べている。
詳細はGrow Your "Agentic Prompt" One Section at a Time – blogを参照していただきたい。
