Skip to content

ステージ1 — 意図定義 (Intent)

何を、なぜ作るのかを検証可能な文で釘付けにする。

このステージの目的

このステージの成果物はコードではなく文書だが、以降すべてのステージの上限を定めるのはこの文書だ。意図が曖昧だとエージェントは隙間を推測で埋め、その推測はレビューステージで手戻りとして返ってくる。目標は「何を作るか」についての合意を人々の間でまず終わらせ、その合意をエージェントが行間なしに読める文書として残すことだ。

実行順序

  1. 問題/機会を一段落で叙述する。 いま何が苦痛で、なぜ今解決すべきかをデータや具体的な事例で裏づける。「もっと良ければいい」という水準の叙述は差し戻す。
  2. PR-FAQで完成した姿を逆算する。 リリース発表文と想定FAQを先に書き、ユーザー視点で「これが成功したら何が変わるのか」を具体的に描く。
  3. 6-pager縮約形で背景・制約・トレードオフを叙述する。 検討したうえで捨てた代替案とその理由を必ず残す。捨てたものを書かないと、後で同じ代替案が再検討なしに繰り返し提案される。
  4. 検証可能な成功基準を明示する。 「使いやすくなる」ではなく「オンボーディング所要時間が30分以内なら成功」のように、真/偽を判定できる文で書く。
  5. ステークホルダーの合意を取る。 レビューコメントや承認記録を文書に残し、後から「そんな話はなかった」という蒸し返しを封じる。

成果物

二つの文書はリポにコミットし、次ステージ(コンテキスト設計)と以降のサイクルの入力として残す。

完了基準チェックリスト

  • [ ] 成功基準が「〜なら成功」のように検証可能な文で書かれている
  • [ ] トレードオフにおいて意図的に捨てた代替案とその理由が明示されている
  • [ ] エージェントが行間を推測せずに読めるほど背景と制約が具体的だ
  • [ ] ステークホルダー全員の合意(レビューコメント・承認記録)が文書に残っている
  • [ ] 文書がリポにコミットされ、次のセッションでそのまま参照できる

よくある誤り

  • 機能列挙式の要求。 「A画面、Bボタン、C API」だけを並べてなぜ必要かがないと、エージェントは目的なく表面だけを実装する。
  • 成功基準のない意図。 「速く安定的に」のように測定不能な形容詞だけだと、検証ステージで合格ラインを定められない。
  • 一度書いて捨てる文書。 合意直後に放置され、セッションごとに口頭で説明し直すと、文書は死んだ記録となりコンテキスト資産につながらない。

Claude Codeなら

TIP

意図文書をspecs/またはdocs/にコミットし、プロジェクトのCLAUDE.mdに「セッション開始時に最新の意図文書をまず読む」というルールを明示する。そうすれば毎セッションが同じスタート地点から始まる。

意図文書が用意できたらplan modeへ移る。文書のパスをプロンプトに指定して「この意図文書を基準に実装計画を立ててほしい」と依頼すると、エージェントが意図を作業単位に分解した計画を提案する。この計画を承認することがステージ3(共同構築)へ移る関門だ。意図文書自体を承認なしに計画へ飛ばさない — 文書化されていない意図は次のセッションで揮発する。