この記事は、小規模 Web アプリケーション向けの AI 駆動開発ワークフローの解説であり、一連のフェーズとして示され、各フェーズについて実際のプロンプトと著者が期待する出力が添えられている。題材は機能リクエストの投票ボードである。ユーザーが機能リクエストを投稿し、他のユーザーがそれに投票し、プロダクトチームがその結果を使って優先順位を決める。各フェーズを具体的なものの上で示せるよう、この題材が選ばれている。
著者が思い描く役割分担のイメージは Google マップである。人間が目的地（なぜ）を伝え、AI が最適なルート（どのように）を提案し、成果物（何を）へと導く。示されている関係は、人間が達成したいことを定義し、AI がどう進めるかについて最適な選択肢を提示するというものである。
この記事が実際に扱っている手法は、記事が要件ベースのプロンプティングと呼ぶものである。プロンプトで出力先のパスを列挙するのではなく、要件と参照すべきドキュメントを伝え、事前に与えたルールに従ってエージェントにファイルを配置させる。記事自身のまとめは 5 つのポイントを挙げている。要件ベースのプロンプト設計、自動生成ルールを事前定義するための AGENTS.md と project-rules.md の活用、ASCII アートと Mermaid による UI ワイヤーフレーム、コンテキスト管理のための context.json、そして不要なフェーズを省くことによる小規模開発向けのサイクルの最適化である。
要点
- ワークフローは 6 つのフェーズで進む。プロジェクトビジョン（Phase 0）、プロジェクトの初期化（Phase 1）、要件定義とドメインモデリング（Phase 2）、アーキテクチャと技術スタックの選定（Phase 3）、開発環境のセットアップ（Phase 4）、そして
context.jsonの管理を伴う機能実装（Phase 5）である。 - いくつかのフェーズのプロンプトには、AI がソースコードを一切出力することを禁じる明示的な制約が含まれている。ビジョン、ワイヤーフレーム、ドメインモデル、アーキテクチャのプロンプトはいずれもそれを明記している。ビジョンのプロンプトはその理由として、議論を概念レベルにとどめ、技術やアーキテクチャの問題を後回しにすることを挙げ、ドメインモデルのプロンプトは、後の技術選定における自由度を保つことを独自の理由として挙げている。
- AGENTS.md はエージェントの長期記憶として示されている。そこにはプロジェクトの概要、フォルダ構成、必ず参照すべきドキュメント、作業ルール、現在のステータスが保持され、記事が述べる効果は、それによって AI が一貫した判断を下せるようになることである。
- 記事が
AGENTS.mdに置く 4 つの作業ルールは次のとおりである。行動する前に計画し、承認後に実行すること。計画や提案の際には 3 つの選択肢を提示すること。実装前に関連する仕様を確認し更新すること。機能が完了したらcontext.jsonを更新すること。 AGENTS.mdには自動生成ルールそのものも記述される。トリガーとなるフレーズ、実行するプロセス、生成するフォルダとファイルの構成、そして結果となるファイルの形である。これによって、人間の 1 行のプロンプト（「vision.md を読んでユーザーストーリーを生成して」）が多段階の実行へと展開される。- 生成の各ステップは完全に自動ではなく、人間の承認によってゲートされている。ストーリー分割のステップとインストールのステップは、どちらも計画を提示し、何かを作成する前に承認か修正かの回答を待つ。
- UI ワイヤーフレームは、画面については ASCII アートとして、画面遷移とコンポーネント構造については Mermaid の図として作成される。プロンプトは出力先のパスを指定せず、ルールに従ってエージェントにファイルを配置させる。
- ドメインモデルは意図的に技術非依存なものとして指定されている。プロンプトは設計項目としてエンティティ、値オブジェクト、集約、ドメインイベントを挙げ、クラス図と関係図を Mermaid で求め、特定のデータストアを前提とすることを禁じている。記事は、これが後の技術選定における自由度を保つと論じている。
context.jsonはストーリーごとのファイルであり、ストーリーのパス、関連するストーリー、レイヤーごとに触れたコード、新規および変更されたファイル、ステータス、タイムスタンプを記録する。記事はその 3 つの目的として、進捗の追跡、参照すべきファイルを AI に伝えること、そして依存関係の可視化を挙げている。- この記事はサンプルプロジェクト上での手法の実演である。測定、この手法を使わない場合との比較、本番のソフトウェアで運用した記録は報告されていない。
背景
記事は対象を小規模な Web アプリケーション開発に明示的に限定しており、アーキテクチャのフェーズもそれを前提に書かれている。プロンプトはドメインモデルを歪めない最も単純な構造を求めており、モノリスが推奨され、複雑なアーキテクチャはこの規模では過剰なものとして扱われている。
記事が掲げる狙いは、大きなコンテキストを扱えるコードモデル（記事が名指ししているのは Codex である）を、オートコンプリートではなく開発パートナーとして扱うことで、その潜在力を引き出すことである。そしてこのプロンプトのスタイルについて、ルールファイルが充実するほどプロンプトは単純になり、出力の品質は向上すると主張している。