チームにMLエンジニアがいなくても、PMがAgent Spec設計を主導できますか？

できます。Agent Specの核心は決定境界と成功基準の定義であり、モデルトレーニングやフレームワークコードの知識は不要です。PMが把握すべきは「どんな状況でエージェントが人間に確認を求めるべきか」と「タスク完了率をどう定量化するか」。これらはプロダクト上の判断であり、技術的判断ではありません。

Agent Specと従来のPRDの最大の違いは何ですか？

PRDはユーザーフロー（確定的システム）を記述します。Agent Specは決定境界（非確定的システム）を定義します。最も重要な違いは三点：エスカレーション条件（エージェントはいつ人間に介入を求めるか）、ツール境界（エージェントが何を使用でき、何は禁止か）、コンテキスト戦略（各ステップでエージェントが見える情報は何か）。PRDはこれらの回答を求めませんが、エージェント設計はリリース前に必ずすべてを明確にする必要があります。

最初のエージェントプロジェクトはどこから始めるべきですか？

「提案のみ（suggestion only）」モードから始めてください。最初のバージョンは提案のみで、操作は実行しません。タスク完了率が目標を達成してからAutonomy Ladderを上がっていきます。リリース前に八次元デプロイチェックリストのすべての質問に答えておくことも必須です。特にエスカレーション条件とエラー回復については事前に明確にしておく必要があります。

良いAgent Specとは何か？PMがAIエージェントを設計するための三層決定フレームワーク

エンジニアから「エージェントの設計が完了しました」と言われたとき、何を質問すれば品質を確認できるか分からない。それはあなたのせいではありません。既存のAIエージェントチュートリアルはほぼすべてエンジニア向け（LangGraphのコード解説、フレームワーク比較、デプロイパイプライン）で、PMの視点からの設計仕様ガイドはほとんど存在しません。結果として、PMはPRDロジックで要件を書き、エンジニアは技術的直感でアーキテクチャを決め、エスカレーション条件はリリース後になって初めて議論されます。

この記事はそのギャップを埋めます。三層決定フレームワークでPMが何を決定すべきかを整理し、八次元デプロイチェックリストでスプリントプランニング前のSpec完整性を確認し、10の必須質問で次回のSpec確認から即活用できるようにします。

TL;DR

エージェント設計には三層あります：戦略層（なぜ作るか、誰が責任者か）、アーキテクチャ層（ツール/メモリ/エスカレーション）、実装層（プロンプト/テスト/監視）。PMは戦略層を主導し、アーキテクチャ層を共同決定します。
良いAgent Specはリリース前に八つの次元を回答しなければなりません：信頼性、ガードレール、成功基準、ツール統合、コスト/レイテンシ、人間介入、エラー回復、可観測性。
MorphLLMが引用するPrinceton研究によると、AGENTS.mdを持つエージェントシステムは28.6%速く、16.6%トークンを節約します。人間が書いたSpecは自動生成より効果的です。
最初のバージョンは提案のみ（suggestion only）で始め、タスク完了率が目標を達成してから自律度を上げます。

PMとエンジニアがエージェント設計で話が噛み合わない理由

従来のPRDフレームワークがエージェント設計で機能しない理由は根本的です。PRDは確定的システムを記述します。ユーザーがAをすれば、システムはBを返す。すべてのパスを列挙できます。しかしエージェントには自律的判断能力があり、不確定な状況でも自分で決断する権限を与えることになります。

その権限の範囲が明確に定義されていない場合、問題はシステムが壊れることではありません。想定外の決断をすることです。Mind the Productの分析によると、エージェント設計の核心的課題はどのモデルを選ぶかではなく、「ゴールとガードレール」を定義することです。PRDはこの二つを求めません。

あるエンジニアの言葉が的確です。「一番困るのは、Specに『エージェントがカスタマーサービスのメールに自動返信する』とだけ書いてあって、それ以上何もない場合です。どんな状況で人間にエスカレーションするか、失敗したときのフォールバックは何か、使えるツールと使えないツールは何かが書いていない。だから推測するしかない。推測が外れれば修正することになるけど、Specには書いていなかった。」推測のコストは最終的にチーム全体が負担します。

PMのSpecで最もよく抜け落ちる四つの本番環境ギャップ：

コンテキストエンジニアリング：各ステップでエージェントが見る情報は何か、精度とフォーマットは何か
可観測性：エージェントの動作をトレースしデバッグできるか
ガードレール：どの操作が許可され、どれが人間の承認を必要とするか
コストアーキテクチャ：タスクごとのトークン予算とコスト上限は何か

これらは標準のPRDテンプレートには現れませんが、答えがないままリリースすると運用コストが予想を大幅に超えます。

三層決定フレームワーク

PMとエンジニアのコミュニケーションギャップを解消する出発点は、誰がどの層で何を決定するかを明確にすることです。

層	核心的な質問	担当
戦略層	なぜこのエージェントを作るのか？成功基準は何か？Build vs. buy vs. configure？オーナーは誰か？	PMが主導
アーキテクチャ層	ツールの境界は何か？メモリ戦略（コンテキスト/リトリーバル/外部メモリ）？エスカレーション条件？自律度レベル？	PM + エンジニアが共同決定
実装層	システムプロンプト設計原則？テストフレームワーク（多シナリオ精度検証）？監視指標？	エンジニアが主導

戦略層がPMの最も重要な貢献です。 設計を始める前に、このエージェントが何の問題を解決するのか、何は対象外か、成功はどう見えるかを明確に答えられる必要があります。あるCTOがこの欠如のコストを説明しています。「先月PMが『顧客行動を自動分析するエージェント』を提案して、簡単だと言いました。エンジニアは三ヶ月と見積もった。その三ヶ月のうち二ヶ月は、最初のSpecで答えられるべきだった設計上の決定を補うのに費やされました。」

アーキテクチャ層はコミュニケーションが最も断絶しやすい場所です。 特に三つの決定事項：

ツール境界：エージェントはどのツールを使用できるか、各ツールの制約（できないこと）は何か。Anthropicのツール設計原則では、ツールは「API-shaped」ではなく「task-shaped」であるべきとされています。ツールの境界はビジネス上の判断を反映すべきで、技術的実装を反映するものではありません。

メモリ戦略：現在のコンテキスト（今必要な情報）、リトリーバル（時々必要な情報）、外部メモリ（長期保持する情報）のどれが適切か。Anthropicのコンテキストエンジニアリング研究では「コンテキストロット」という概念が登場します。タスクの進行とともにコンテキストが膨らむと、エージェントの性能は線形に低下するのではなく、ある閾値を超えた後に急激に悪化します。正しいアプローチは「最小限のハイシグナルトークン」です。

Autonomy Ladder：エージェントの自律度は段階的に上げていきます。提案のみ（suggest only）から始め、部分的な承認（partial approval）、そして完全自律（independent）へ。Mind the Productはこれを「Autonomy Ladder」と呼び、昇格のタイミングはタスク完了率が目標を達成したかどうかで決まります。時間ではありません。

良いAgent Specとは：八次元デプロイチェックリスト

これが記事の核心的なデリバラブルです。Product Schoolの八次元デプロイフレームワークをAnthropicのベストプラクティスと組み合わせ、各次元にPMがすぐに使える検証質問を付けています。

1. 信頼性テスト 本番に近い環境でテストしましたか？具体的なレイテンシとスループット目標がありますか（例：「250同時リクエスト、P95レイテンシ300ms以内」）？

2. ガードレール どの操作が不可逆ですか？それらの操作に承認ゲートはありますか？エージェントの最小権限は何ですか（できること、できないこと）？

3. 成功基準 タスク完了率の目標は何ですか？ツール正確度をどう測定しますか？タスク成功コストの目標は何ですか？Product Schoolの原則：「『良い』を明確に定義できなければ、安全にリリースできない」。

4. ツール統合 各ツールの境界は何ですか？タイムアウト、リトライ、バックオフ戦略がありますか？Anthropicは、リトライによる重複操作を防ぐため冪等性（idempotency）の設計を推奨しています。

5. コスト/レイテンシ予算 タスクごとのトークン予算は何ですか？コスト上限はどこに設定しますか？予算超過時のフォールバックは何ですか？エンジニアはこれを自発的に聞いてこない場合が多いですが、答えがなければコスト対応のコンテキスト戦略を設計できません。

6. Human-in-the-loop どの状況が人間の介入をトリガーしますか？人間に引き継ぐ際、エージェントは完全なコンテキストを渡しますか？エスカレーション後の人間応答SLAは何ですか？

7. エラー回復 失敗した場合のフォールバックは何ですか？タブレトップドリル（エージェント失敗シナリオのシミュレーション）を行いましたか？ロールバックメカニズムは存在しますか？

8. 監視/可観測性 エンドツーエンドのトレースがありますか？エンジニアリングダッシュボード（デバッグ用）とプロダクトダッシュボード（ビジネス指標用）は分けていますか？リリース後に最初に確認する指標は何ですか？

自分たちのエージェントフリートを運用して学んだ教訓：可観測性をリリース前に定義しなかった場合の結果は、システムの故障ではありません。何か問題が起きたとき、どこで問題が発生したかを把握するのに非常に時間がかかることです。現在、私たちのすべてのエージェントには構造化ログとトレースIDがあり、診断時間が「不明」から数分に短縮されました。

エンジニアへの10の必須質問

エンジニアはこれらを自発的に提起しませんが、あなたが聞く必要があります。次のスプリントプランニングまたはSpec確認にこのリストを持ち込んでください：

このエージェントはどんな状況で自分で決定せず、人間に確認を求めるべきですか？
ツール呼び出しが失敗した場合、エージェントのフォールバックは何ですか？
エージェントは何を記憶する必要がありますか？どれくらいの期間？誰がクリアできますか？
成功指標は何ですか？タスク完了率の目標は何ですか？
エージェントはどのツールを持っていますか？各ツールの境界（できないこと）は何ですか？
コンテキストウィンドウが一杯になったらどうなりますか？コンパクション戦略はありますか？
エージェントはどうやって自分のミスを知りますか？評価者（evaluator）はいますか？
最初のバージョンのリリース後、どうモニタリングしますか？どの指標を見ますか？
不可逆的な操作は何ですか？それらの操作に承認ゲートはありますか？
エージェントのSpecはどこにありますか？AGENTS.mdですか、それとも別のドキュメントですか？

質問10はファイルの場所を確認するだけでなく、Specドキュメントの存在とフォーマットを確認するものです。「Confluenceのどこかのページ」や「エンジニアの頭の中」という答えは、受け入れられる状態ではなく、解決すべき問題です。

三層Specファイル：AGENTS.md / SKILL.md / DESIGN.md の役割

2025年から2026年にかけて、「エージェントの動作をどう仕様化するか」という問いへの業界全体の答えが登場しました。三層Specファイルの慣例です。

AGENTS.md = 行動層 エージェント全体のコンテキスト、役割、禁止事項、操作原則を定義します。MorphLLMが引用するPrinceton研究のデータによると、AGENTS.mdを持つエージェントシステムは実行時間が28.6%短縮、トークン使用量が16.6%削減されます。さらに重要な発見：人間が書いたAGENTS.mdは自動生成より効果的であり、自動生成版はエージェントの成功率を2%低下させ、コストを23%増加させました。

これは、AGENTS.mdが人間向けの規範ドキュメントにとどまらないことを意味します。エージェントのコンテキストアンカーであり、その品質がエージェントの動作に直接影響します。明確なAGENTS.mdを維持することは、定量化可能な技術投資です。

SKILL.md = タスク層 再利用可能なスキルと手続き的知識を定義します。AGENTS.mdが「誰か」であれば、SKILL.mdは「どうやるか」です。具体的なタスクのステップバイステップのワークフロー、判断ルール、出力フォーマットです。

DESIGN.md = プレゼンテーション層 Google LabsのDESIGN.md規格は、機械可読（YAMLデザイントークン）と人間可読（Markdownデザイン理念）の二軌道フォーマットを提供し、AIエージェントがシステムのビジュアルデザインを永続的かつ構造化された形で理解できるようにします。

DEV Community（AWS Builders）の三層フレームワーク記事は有用な原則を提示しています：形式的に検証可能なコンテンツはSpecファイルに、判断に基づくコンテンツは自然言語で記述する。この二つを混同することが、Specファイルが効果を失う最も一般的な原因です。

私たち自身のShareuhackエージェントフリートもまさにこの三層アーキテクチャで動いています：CLAUDE.mdをグローバル行動Specとして、agents/AGENTS.mdで各エージェントの役割と操作原則を定義し、.claude/skills/をスキル層として使用。実際の運用経験から言えば、この三層分離によってエージェントの動作がより予測可能になり、新しいタスクを受け取った際に自分の決定境界を素早く特定できるようになりました。エージェントのメモリアーキテクチャ設計についてはさらに詳しい記事もあります。

よくある設計ミス：過度なエンジニアリングとその他の落とし穴

ビジネス価値の不明確さとリスクコントロールの不足が、エージェントAIプロジェクト失敗の主な原因です。技術的能力の不足ではありません。どちらも実装段階ではなく、設計段階の問題を指しています。

最も一般的な四つの落とし穴：

落とし穴1：最初からマルチエージェントアーキテクチャ マルチエージェントアーキテクチャは、単一エージェントの能力限界の問題を解決します。しかし、その限界がまだテストされていない段階でアップグレードすると、問題をN倍に増やしているだけです。Anthropicの推奨：まずprompt-responseで十分かを確認し、次に単一エージェント、最後にマルチエージェントを検討します。

落とし穴2：ツールが多すぎる ツールの数がエージェントの選択能力を超えると、間違ったツールを選ぶ可能性が高まります。Anthropicのツール設計原則は「増殖よりも統合（consolidation over proliferation）」であり、可能な限りツールを統合し、各ツールの境界を明確に重複しないようにします。

落とし穴3：コンテキストの詰め込みすぎ（コンテキストロット） Anthropicのコンテキストエンジニアリング研究は「コンテキストロット」という現象を説明しています：タスクを進めるにつれてコンテキストが積み重なると、エージェントのパフォーマンスは線形に低下せず、ある閾値を超えた後に急激に悪化します。最も一般的なミスは、関連しそうなすべての情報をコンテキストに入れることです。正しいアプローチは「最小限のハイシグナルトークン」です。

落とし穴4：エスカレーションパスがない これはエンジニア、PM、CTOの三者全員が言及するギャップです。エンジニアは推測できない。PMは考えていなかった。CTOはリリース後に気づく。Productsideの「エージェントジャーニーマップ」はエスカレーション設計をタスク設計より前に置いています。後回しにしてはいけない理由がまさにここにあります。

解決策はシンプルです：最初のバージョンは常に「提案のみ」で始め、指標が安定してからAutonomy Ladderを上がります。これは保守的なのではなく、失敗コストを本番環境で発見することを避けるための方法です。

重要：「シンプルファースト」と「最終的にマルチエージェントへの拡張」は矛盾ではなく、タイミングの問題です。まず最もシンプルな有効バージョンを構築し、データで複雑さの追加を判断する。これが持続可能なエージェント設計の道筋です。

エージェントを作るべきでない場合

エージェントの構築を決める前に、三つの質問に答えてください。三つのうち二つ以上が「No」なら、おそらくエージェントは必要ありません：

タスクは複数ステップか、分岐する判断がありますか？（固定フローならワークフローで十分）
タスクにツールまたはセッションを超えたメモリが必要ですか？（単一クエリならRAG + promptで十分）
実行パスはコンテキストによって大きく変わりますか？（パスが固定なら、エージェントよりワークフローが信頼できる）

三つすべてが「Yes」の場合のみ、エージェントを構築する価値があります。

Build vs. buy vs. configureの判断次元：

カスタマイズニーズ：既存ツールが要件の80%を満たせるなら、まずconfigureから。コア差別化機能のみbuildします。
維持コスト：自作エージェントの本当のコストはリリース後に始まります。モデルバージョンアップ、API変更、エッジケースの蓄積。既存ツールはそのメンテナンスをベンダーに委託できます。
コンプライアンス要件：機密データや特定の規制要件がある場合、自作でデータフローをコントロールできます。既存ツールのデータ処理はToSの確認が必要です。
既存ツールのカバレッジ：自作を決める前に、Zapier、Make、n8nなどのノーコード/ローコードツールで要件を満たせないかを評価してください。

エージェントのセキュリティ設計を評価している場合、OWASP Agentic AI成熟度評価フレームワークは有用な補足参照資料です。特にガードレールと監視設計において。

まとめ

PMの仕事はLangGraphを学ぶことではなく、「決定境界」をエンジニアが実行できる仕様に変換することです。三層フレームワークで自分が何を決定すべきかが分かり、八次元チェックリストでSpecが完全かどうかを確認でき、10の質問でスプリントプランニングの前に重要な決定を整合できます。

次のエージェント要件が来たときの二つの道：

PMであれば、三層決定フレームワークから始め、まず戦略層の三つのコア質問に答えを出し、次に10の質問をスプリントプランニングに持ち込みます。CTO / テックリードであれば、まず三条件フレームワークでエージェントが本当に必要かを判断し、必要と確認できたら、スプリント開始前にPMに八次元チェックリストの完成を求めてください。