agent-orchestration-advisor

目的

プロダクトマネージャーがマルチエージェントワークフローを設計できるように支援します。複雑で反復的なPM業務を、直線的で順次進行するプロセスや手作業ではなく、専門性を持つ複数のAIエージェントが並行して処理する形に分解します。これを活用し、「文書作成に追われる管理者」から、AIエージェント、人間のチーム、市場データが継続的に相互作用する「生きたシステム」を連携させる「システムレベルのオーケストレーター」へと移行しましょう。

重要な変化： 直線的なプロジェクト管理（1つずつタスクを進める）からオーケストレーション（明確な境界と引き継ぎを持つ複数のエージェントが同時に作業する）へ。

これはプロンプトの作成に関するものではありません。AIエージェントが反復的な調査、情報の統合、検証を担い、PMが戦略と意思決定に集中できるワークフローを設計することです。

入力

最も効果的な情報： オーケストレーションしたいワークフローや定期的なタスクを、現在どれほど手作業で煩雑かにかかわらず、1〜2文で説明したもの。 あると役立つ情報： 現状でどこに問題があるか（遅すぎる、逐次的すぎる、あなたに頼りすぎているなど）、チームがすでに使っているツール、そして事前にcontext-engineering-advisorに取り組んだかどうか（これは前提となる手法です）。

呼び出し時に入力された内容（スキル名の後のテキスト、貼り付けられたコンテキスト、追加された ARGUMENTS: 行）は、すでに回答済みの情報として扱います。その情報を使い、該当する内容は再質問しないでください。

何も準備していなくても大丈夫です。 アドバイザーは、週の大半を費やしているPMワークフローを尋ねるところから始め、そのワークフローに沿って4つのオーケストレーションの側面を順に確認します。

呼び出し例： 毎週の競合情報収集をオーケストレーションしてください。現状では、PMが1人で6時間かけて情報を収集・要約し、順番に報告しています。

主要な概念

オーケストレーションとプロジェクト管理の違い

側面	プロジェクト管理	オーケストレーション
アプローチ	スケジュールと人間のタスクを直線的に管理する	AIエージェント、人間、データが継続的に相互作用する「生きたシステム」を管理する
タスクの流れ	順次進行（Aを終えてからB、次にC）	並行進行（A、B、Cを同時に実行する）
PMの役割	文書作成に追われる管理者	自動化システムと人間の判断を連携させるシステムレベルのリーダー
重視するもの	アウトプット（リリースした機能）	成果（ビジネス上の結果、学習の速度）
リスク管理	手作業での追跡と軽減	エージェントシステムがギャップを検知するリアルタイム監視

重要な洞察： オーケストレーションは人間を置き換えることではありません。反復的で時間のかかるタスクを自動化し、人間の判断力を何倍にも高めることです。

---

オーケストレーションの4つの側面

1. マルチエージェントワークフローの調整

複雑なタスクを、並行して実行される専門エージェントに分解します。

例：

• 手作業（従来）： PMが競合情報の収集に8時間、顧客フィードバックの統合に4時間、ロードマップのギャップ特定に3時間を順番に費やす＝合計15時間
• オーケストレーション（新方式）： 3つのエージェントを同時に実行する：
  • エージェントA：競合情報（調査エージェント）
  • エージェントB：顧客情報の統合（統合エージェント）
  • エージェントC：ロードマップのギャップ分析（分析エージェント）
  • 合計所要時間：8時間（最も遅いエージェントによって決まる）。PMが2時間かけて出力を確認するため、合計10時間となり、5時間を削減できる

重要な原則： 手作業による選定から、仮説のオーケストレーションへ移行します。エージェントが仮説を生成し、PMが検証して判断します。

2. 部門横断型AIポッドのリーダーシップ

多様なチーム（データサイエンティスト、MLエンジニア、コンプライアンス担当者、倫理専門家）を統括し、拡張性、倫理性、方針との整合性を備えたソリューションを実現します。

含まれる内容：

• 多様性を考慮したワークフローの組み込み
• リスク管理（後回しにしない）
• 倫理的なオーケストレーション（AIが「暴走」しないようにする）
• 部門横断の連携（エンジニアリング、コンプライアンス、デザイン）

PMの役割： ガバナンスの守護者として、AIシステムが会社の価値観を反映するようにします。

3. コントロールタワー機能の立ち上げ

エージェント型システムを使用して、機能ごとの組織の準備状況をリアルタイムで監視し、重大な障害が発生する前に不足を警告します。

監視対象：

• サポートの準備状況（ドキュメント、トレーニング、エスカレーション経路）
• マーケティングの準備状況（メッセージ、アセット、GTM 計画）
• 運用の準備状況（インフラストラクチャ、スケーリング、監視）

基本原則： エージェント型システムは早期警告システムとして機能し、不足が障害要因になる前に警告します。

4. 戦略的意図の整合（コンテキストエンジニアリングの適用）

ミッション、制約、優先事項を適切に組み合わせて AI エージェントに与え、自動化された意思決定に会社の価値観を反映させます。

関連性： これはオーケストレーションレイヤーでのコンテキストエンジニアリングです。基礎については context-engineering-advisor を参照してください。

エージェントに必要なもの：

• 製品の制約（構築するもの／しないもの）
• 戦略的優先事項（現時点で最も重要なこと）
• 運用上の定義（共有用語集）
• エビデンスの基準（何を検証とみなすか）

---

4 つの AI 管理ワークフロー（Productside の設計図）

すべての PM は、迅速に進めながら地に足をつけるために、次のワークフローを習得する必要があります。

1. コンテキストエンジニアリング ✅（基盤）

   • 製品領域、調査、JTBD、ペルソナ、制約を記憶する AI ワークスペースを作成する
   • スキル： context-engineering-advisor

2. 合成評価 📋（品質保証）

   • AI の推論を自動検証するテスト
   • 合成データを生成し、トレースに対してワークフローを実行する
   • ハルシネーションのリスクを 80% 排除する

3. エージェント型ワークフロー ← 現在の項目です

   • エージェントが反復的なタスク（競合情報、顧客の統合分析、ロードマップの不足箇所）を処理する
   • PM は戦略に集中する

4. バイブコーディング 📋（迅速なプロトタイピング）

   • コンテキストワークスペースからクリック可能なプロトタイプを生成する
   • フィードバックループを数週間から数時間に短縮する
   • 関連性： pol-probe-advisor（バイブコーディングによる PoL プローブ）

---

AI に適した課題（Teresa Torres）

どのような課題が「AI に適している」のでしょうか？

• 人の関与が必要なため、以前は規模を拡大するのが困難だった（例：50 件のユーザーインタビューの統合分析）
• 現在の AI を使わないソリューションでは不十分（例：競合の手動追跡）
• 大規模でも一貫性が必要（例：100 の機能にわたるリスク分析）

重要な洞察：「AI によって構築は容易になりますが、何を構築するかを選ぶことが依然として最大の課題です。」オーケストレーションが「構築」の部分を支援することで、PM は「選択」に集中できます。

---

4 つの大きなリスク（Marty Cagan、AI 時代）

オーケストレーターは、組織全体で次のリスクを管理します。

リスク	標準的な定義	AI 時代の視点	オーケストレーターの役割
価値リスク	顧客はお金を払うか？	AI はコストに見合うだけの追加価値を提供するか？	オーケストレーションの前に PoL プローブで価値を検証する
ユーザビリティリスク	ユーザーは使い方を理解できるか？	UX は適切か？（チャットが適切とは限りません！）	実際のユーザーでワークフローをテストする
実現可能性リスク	構築できるか？	「AI の物理法則」を理解しているか？トークン予算は？	技術的な制約の範囲内で設計する
事業継続性リスク	販売やサポートができるか？	法的制限は？データプライバシーは？OpEx を持続できるか？	コスト、コンプライアンス、スケーラビリティを監視する

---

アンチパターン（これは何ではないか）

• PM を置き換えるものではありません： オーケストレーションは判断力を高めるものであり、なくすものではありません
• すべてを自動化するものではありません： 人間の共感力や文脈が必要なタスクもあります
• 複雑さ自体を目的とするものではありません： 大幅な時間短縮や品質向上につながる場合にのみオーケストレーションします
• 「設定して放置」するものではありません： オーケストレーションされたワークフローには監視と保守が必要です

---

このスキルを使用するタイミング

✅ 次の場合に使用してください：

• 週に5時間以上かかる反復的なPMタスクがある場合（競合分析、顧客情報の統合、ロードマップのメンテナンスなど）
• 並列化できる作業を順番に行っている場合（調査、その後に統合、その後に分析）
• 大規模な処理でも一貫性が必要な場合（50件の機能のリスク分析、100件の顧客インタビューの統合など）
• 戦略ではなく実行に時間を費やしている場合

❌ 次の場合は使用しないでください：

• タスクが一度きり、または頻度が低い場合（オーケストレーションのオーバーヘッドに見合いません）
• すべてのステップで人間の判断が重要な場合（共感が求められる作業）
• タスクがすでに十分速く完了している場合（過剰に設計しないでください）
• 先にコンテキストエンジニアリングの基盤を構築していない場合（context-engineering-advisorを参照してください）

---

適用

このインタラクティブなスキルでは、適応型の質問を用いて、マルチエージェントのワークフローを段階的に設計します。

---

ステップ 0：コンテキストを収集する

エージェントからの質問：

オーケストレーションするワークフローを設計する前に、まずコンテキストを集めましょう。

現在のPM業務：

• 毎週、どの反復的なタスクに最も時間がかかっていますか？（競合分析、顧客情報の統合、ロードマップの更新など）
• これらのタスクにどれくらい時間を費やしていますか？（週あたりの時間）
• これらのタスクは順番に行うものですか？それとも並列で実行できますか？

望ましい成果：

• 「十分に良い」自動化とは、どのようなものでしょうか？（手作業を80％削減する？一貫性を高める？）
• どの部分で人間の判断が必要ですか？（最終決定、共感、倫理的な配慮）

技術的なコンテキスト：

• コンテキストエンジニアリングの基盤は整っていますか？（制約レジストリ、運用用語集—context-engineering-advisorを参照してください）
• 現在、どのようなAIツールを使っていますか？（Claude Projects、ChatGPT、カスタムエージェント）

簡潔に説明するか、例を貼り付けてください。

---

ステップ 1：タスクがAIに適しているか評価する

エージェントからの質問：

タスクがオーケストレーションに適しているか判断しましょう。あなたの状況を最もよく表すものはどれですか？

1つ選択してください：

1. 「反復的な調査や情報の統合に、週10時間以上費やしています」

   • 例：競合情報の取りまとめ、顧客フィードバックの統合、機能リクエストの追跡
   • 評価：オーケストレーションの可能性が高い

2. 「複数の段階を順に進める必要があり、各段階に時間がかかるタスクがあります」

   • 例：競合他社を調査 → 調査結果を統合 → ギャップを特定 → ロードマップを更新（合計15時間、順番に実施）
   • 評価：並列化に適した候補です

3. 「大規模な処理でも一貫性が必要です。同様の項目を多数分析します」

   • 例：50件の機能のリスク分析、100件のユーザーインタビューの統合、20社の競合他社の追跡
   • 評価：オーケストレーションに最適です（エージェントによって一貫性を確保できます）

4. 「主に人間の判断と共感を必要とするタスクがあります」

   • 例：ステークホルダーとの交渉、チームのコーチング、倫理的なトレードオフ
   • 評価：オーケストレーションには適していません（人間主導のままにしてください）

ユーザーの回答：［選択］

エージェントによる分析：

選択内容に基づいて：

• 選択肢1～3： ワークフローの設計に進みます
• 選択肢4： タスクを人間主導のままにすることを推奨し、代替アプローチを提案します（例：調査にはAIを使い、意思決定は人間が行う）

---

ステップ 2：タスクをエージェントごとのサブタスクに分解する

エージェントの質問：

タスクを個別のサブタスクに分解し、それぞれを専門エージェントが担当する形にしましょう。

選択したタスクには、どのような個別のステップがありますか？

分解例（競合情報分析）：

手作業でのプロセス（従来）：

1. 競合 10 社の製品ページを調査する（3 時間）
2. 最近の機能リリースを追跡する（2 時間）
3. 価格変更を分析する（2 時間）
4. 調査結果を競合状況のドキュメントにまとめる（3 時間）
5. 戦略上のギャップを特定する（2 時間） 合計： 12 時間、順番に実施

オーケストレーションされたプロセス（新）：

• エージェント A（調査）： 競合の製品ページをスクレイピングし、機能を抽出する
• エージェント B（リリース追跡）： 競合のリリースノート、ブログ投稿、ソーシャルメディアを監視する
• エージェント C（価格分析）： 価格ページを追跡し、変更を特定する
• エージェント D（統合）： A、B、C の調査結果をまとめ、構造化されたレポートを作成する
• エージェント E（ギャップ分析）： 自社のロードマップと競合の機能を比較し、ギャップを洗い出す 合計： エージェント A〜C を並列実行（3 時間）した後、D と E を順番に実行（2 時間）＝ 5 時間 ＋ PM のレビュー 1 時間 ＝ 合計 6 時間（時間を 50％ 削減）

エージェントの提案：

タスクの分解をお手伝いします。現在のプロセスをステップごとに説明してください。 以下を特定します。

• エージェントが担当できるステップ
• 並列実行できるステップ
• 人間の判断が必要なステップ

ユーザーの回答： ［プロセスを説明］

エージェントが提示するもの： エージェントの担当割り当てを含む、分解されたワークフロー。

---

ステップ 3：並列フローと逐次フローを設計する

エージェントの質問：

次に、ワークフローの構成、つまりエージェントを並列実行するか、逐次実行するかを設計しましょう。

3 つのフローパターン：

パターン 1：完全並列（最速）

[Agent A] ─┐
[Agent B] ─┼─→ [PM Review] → [Decision]
[Agent C] ─┘

• すべてのエージェントを同時に実行する
• PM がすべての出力をまとめてレビューする
• 次の場合に使用： エージェントが独立している場合（相互の依存関係がない）

パターン 2：パイプライン（引き継ぎを伴う逐次処理）

[Agent A] → [Agent B] → [Agent C] → [PM Review] → [Decision]

• 各エージェントが、直前のエージェントの出力に依存する
• 次の場合に使用： 後続のエージェントが前のエージェントの結果を必要とする場合

パターン 3：ハイブリッド（並列＋逐次）

[Agent A] ─┐
[Agent B] ─┼─→ [Agent D] → [Agent E] → [PM Review] → [Decision]
[Agent C] ─┘

• 一部のエージェントを並列実行し、その出力を逐次処理を行うエージェントに渡す
• 次の場合に使用： 初期ステップが独立しており、後続ステップで結果を統合する場合

このタスクには、どのパターンが最適ですか？

選択肢：

1. 完全並列 — すべてのエージェントが独立している
2. パイプライン — 各エージェントが前のエージェントの出力を必要とする
3. ハイブリッド — 並列処理と逐次処理を組み合わせる
4. わからない — ［エージェントが分解内容を分析し、推奨する］

ユーザーの回答： ［選択］

エージェントが提示するもの： エージェント間の依存関係を示すワークフロー図。

---

ステップ 4：エージェントの境界と引き継ぎを定義する

エージェントからの質問：

各エージェントが何を知っているか（コンテキストの境界）と、エージェント間でどのように引き継ぐかを定義しましょう。

各エージェントについて、次の項目を定義します：

1. エージェント名と目的（どのような役割ですか？）
2. 必要なコンテキスト（どのような情報が必要ですか？）
   • 常に利用可能（コンテキストエンジニアリングによるもの）
   • 必要に応じて取得（今回の実行に固有のもの）
3. 出力形式（何を生成しますか？）
4. 次のエージェントへの引き継ぎ（何を渡しますか？何をフィルタリングしますか？）

例（競合インテリジェンスのオーケストレーション）：

エージェント A：競合調査エージェント

• 目的： 競合 10 社の製品ページをスクレイピングし、機能を抽出します
• 必要なコンテキスト：
  • 常に利用可能：競合のリスト（制約レジストリから）
  • 取得：競合の URL（データベースから）
• 出力形式： 構造化された JSON：{competitor, features[], last_updated}
• 引き継ぎ： JSON をエージェント D（統合エージェント）に渡します

エージェント D：統合エージェント

• 目的： エージェント A、B、C の調査結果をまとめて、構造化されたレポートを作成します
• 必要なコンテキスト：
  • 常に利用可能：レポートのテンプレート、文章のトーン（コンテキストワークスペースから）
  • 取得：エージェント A、B、C の出力
• 出力形式： 「概要」「主な機能」「価格」「ローンチ活動」の各セクションを含む Markdown ドキュメント
• 引き継ぎ： レポートをエージェント E（ギャップ分析エージェント）に渡します

エージェントからの提案：

各エージェントの境界を定義するお手伝いをします。ワークフローについて、次の項目を定義しましょう：

• 各エージェントが必要とするコンテキスト（常に利用可能か、取得するものか）
• 各エージェントが生成する形式（JSON、Markdown、構造化データ）
• エージェント間の引き継ぎ方法（渡すものとフィルタリングするもの）

ユーザーの回答：［エージェントが必要とするものを説明してください］

エージェントが提供するもの： エージェント境界の定義と引き継ぎ仕様一式。

---

ステップ 5：戦略的意図との整合性を実装する

エージェントからの質問：

エージェントが「独自の判断で暴走」するのを防ぐには、ミッション、制約、優先事項を適切に組み合わせて与える必要があります。

戦略的意図のチェックリスト（エージェントごと）：

1. ミッション： このエージェントの主な目標は何ですか？

   • 例：「第 2 四半期のロードマップに影響する可能性のある競合の脅威を特定する」

2. 制約： エージェントがしてはならないことは何ですか？

   • 例：「戦略上の重点領域から外れた機能を推奨しない」
   • 例：「スクレイピングを禁止しているサイトからデータを取得しない（robots.txt を確認する）」

3. 優先事項： 選択が必要な場合、最も重要なものは何ですか？

   • 例：「古い機能よりも、直近 30 日間にリリースされた機能を優先する」

4. 証拠の基準： 何を有効な情報と見なしますか？

   • 例：「公式の製品ページ、リリースノート、または検証済みのブログ記事に記載された情報のみを引用する」

関連事項： これはオーケストレーションに適用するコンテキストエンジニアリングです。詳しくは context-engineering-advisor を参照してください。

エージェントからの提案：

ワークフロー内の各エージェントについて、次の項目を定義しましょう：

• ミッション（目標は何ですか？）
• 制約（何が許容範囲外ですか？）
• 優先事項（最も重要なのは何ですか？）
• 証拠の基準（何を有効と見なしますか？）

ユーザーの回答：［エージェントごとの戦略的意図を定義してください］

エージェントが提供するもの： エージェントごとの戦略的意図ドキュメント。

---

ステップ 6：Launch Control Tower のモニタリングを設定する

エージェントが質問します：

Launch Control Tower は、リアルタイムでモニタリングを行い、問題が重大な障害になる前にギャップを検出します。

モニタリング対象（3 つの側面）：

1. エージェントのパフォーマンス：

• エージェントはタスクを期限内に完了していますか？
• 出力は品質基準を満たしていますか？
• エージェントはトークン／コストの予算内に収まっていますか？

2. 組織の準備状況（機能をローンチする場合）：

• サポートの準備状況：ドキュメントは更新済みですか？トレーニングは完了していますか？エスカレーション経路は定義されていますか？
• マーケティングの準備状況：メッセージは確定していますか？アセットは作成済みですか？GTM 計画は確定していますか？
• 運用の準備状況：インフラはスケールされていますか？モニタリングは導入されていますか？ロールバック計画は準備できていますか？

3. リスクフラグ：

• エージェントは予期しない出力を生成していますか？（ハルシネーションの可能性）
• エージェントは制約に違反していますか？（倫理／コンプライアンス上の問題）
• 引き継ぎに失敗していますか？（エージェント B がエージェント A の出力を正しく受け取れていない）

モニタリング方法：

オプション 1：手動ダッシュボード

• PM が毎週、エージェントの出力をレビューする
• 品質をスポットチェックし、ゴールデンデータセットと比較する
• リスクフラグを手動で特定する

オプション 2：自動モニタリング

• エージェントが出力を中央のダッシュボードに記録する
• 出力ごとに自動評価を実行する（ステップ 7 を参照）
• 品質がしきい値を下回った場合にアラートを発する

オプション 3：ハイブリッド

• 自動評価と PM による週次レビューを組み合わせる
• 重大な問題についてはアラートを発し、その他の項目は PM がスポットチェックする

チームの成熟度に合うモニタリング方法はどれですか？

オプション：

1. 手動ダッシュボード（成熟度が低く、小規模な場合）
2. 自動モニタリング（成熟度が高く、大規模な場合）
3. ハイブリッド（ほとんどのチームにおすすめ）

ユーザーの回答： [選択]

エージェントが提供する内容： 具体的な指標とアラートしきい値を含むモニタリング計画。

---

ステップ 7：評価計画を作成する

エージェントが質問します：

オーケストレーションされたワークフローが高品質な出力を生成できるよう、評価フレームワークが必要です。

4 種類の評価（調査に基づく）：

評価の種類	方法	使用するタイミング
ゴールデンデータセット	実際の入力と期待される出力の例を 20～100 件用意する	品質のベースライン測定
コードアサーション	出力が従うべきルール（例：有効な JSON を含む必要がある）	構造の検証
LLM-as-Judge	強力なモデル（GPT-4o）がエージェントの出力を採点する	迅速な自動フィードバック
人間による評価	PM がトレースを手動でレビューする	「センス」や「プロダクト感覚」の最終確認

評価プロセス：

1. トレースを収集する： エージェントを実行するたびに入力と出力を記録する
2. 毎週レビューする： トレースに注釈を付け、失敗モードを分類する
3. 失敗モードの分類体系を作成する： よくあるエラー（ハルシネーション、制約違反、品質の低さ）を整理する
4. 自動評価を作成する： ゴールデンデータセットやコードアサーションを使って、よくある失敗モードを対象にする
5. 反復する： 評価結果に基づいて、エージェントのプロンプト／コンテキストを改善する

ワークフローに適している評価はどれですか？

オプション：

1. ゴールデンデータセットから始める — 各エージェントについて、良質な出力の例を 20 件作成する
2. コードアサーションから始める — 構造上のルールを定義する（例：出力は必須フィールドを含む有効な JSON でなければならない）
3. 人間による評価から始める — 最初の 2 週間は PM がすべての出力をレビューし、パターンを特定する
4. 3 つすべて — 包括的な評価戦略（重要なワークフローにおすすめ）

ユーザーの回答： [選択]

エージェントが提供する内容： 具体的な評価の種類、頻度、成功基準を含む評価計画。

---

ステップ 8：実装計画と次のステップ

エージェントがまとめます：

オーケストレーションされたワークフロー計画の全体像は次のとおりです。

┌─────────────────────────────────────────────────────────────┐
│ ORCHESTRATED WORKFLOW: [Your Task Name]                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ TOPOLOGY: [Full Parallel / Pipeline / Hybrid]              │
│                                                             │
│ AGENTS:                                                     │
│ • Agent A: [Name] - [Purpose]                              │
│ • Agent B: [Name] - [Purpose]                              │
│ • Agent C: [Name] - [Purpose]                              │
│                                                             │
│ FLOW:                                                       │
│ [Agent A] ─┐                                                │
│ [Agent B] ─┼─→ [Agent D] → [PM Review] → [Decision]        │
│ [Agent C] ─┘                                                │
│                                                             │
│ CONTEXT BOUNDARIES:                                         │
│ • Always-available: [List]                                  │
│ • Retrieved on-demand: [List]                               │
│                                                             │
│ STRATEGIC INTENT:                                           │
│ • Mission: [Per agent]                                      │
│ • Constraints: [Per agent]                                  │
│ • Priorities: [Per agent]                                   │
│                                                             │
│ MONITORING:                                                 │
│ • Approach: [Manual / Automated / Hybrid]                   │
│ • Metrics: [List]                                           │
│ • Alert thresholds: [List]                                  │
│                                                             │
│ EVALUATION:                                                 │
│ • Golden Datasets: [Y/N]                                    │
│ • Code Assertions: [Y/N]                                    │
│ • Human Evals: [Frequency]                                  │
│                                                             │
│ TIME SAVINGS:                                               │
│ • Manual (old): [X hours]                                   │
│ • Orchestrated (new): [Y hours]                             │
│ • Savings: [X-Y hours per week]                             │
└─────────────────────────────────────────────────────────────┘

実装ロードマップ：

第 1 週：コンテキストの基盤を構築

• まだ完了していない場合は、context-engineering-advisor を完了します
• 制約レジストリと運用用語集を作成します
• 各エージェントの戦略的意図を文書化します

第 2 週：最初のエージェントを実装

• 最もシンプルなエージェント（通常はリサーチまたはデータ収集）から始めます
• 実際の例を 5 件使ってテストします
• 出力品質を検証します

第 3 週：残りのエージェントを追加

• エージェント 2～5 を実装します（ワークフローに応じて調整）
• エージェント間の引き継ぎをテストします
• ワークフロー全体をエンドツーエンドで検証します

第 4 週：監視と評価を設定

• 選択した監視方法を実装します
• ゴールデンデータセットを作成します（選択した場合）
• 人による評価を最初の 1 週間実施し、失敗パターンを特定します

第 5 週以降：反復と拡張

• 評価結果に基づいてエージェントのプロンプトを改善します
• よくある失敗を対象とする自動評価を追加します
• より多くのユースケースに拡張します

成功基準：

• ✅ 時間の節約：手作業を 30％以上削減
• ✅ 品質：エージェントの出力が 80％以上の頻度で品質基準を満たす
• ✅ 一貫性：出力が 95％以上の頻度でテンプレート／形式に従う
• ✅ 監視：PM が気付く前にアラートで問題を検知する
• ✅ 評価：失敗パターンの分類体系を文書化し、自動評価を導入する

エージェントからの提案：

次のことをご希望ですか？

1. このワークフロー計画をエクスポートして、Markdown ドキュメントにする
2. 実装用テンプレートを提供する（エージェントプロンプトのテンプレート、監視ダッシュボード、評価チェックリスト）
3. このオーケストレーションの構築に使うツールを推奨する（Claude Projects、カスタム API、オーケストレーションプラットフォーム）

---

例

例 1：競合インテリジェンスのオーケストレーション

コンテキスト：

• B2B SaaS 企業の PM
• 競合他社 10 社を追跡
• 手作業でのプロセス：週 12 時間（リサーチ、統合、ギャップ分析）

目標： オーケストレーションされたワークフローで 6 時間に短縮する

ワークフロー設計：

エージェント：

• エージェント A（リサーチ）： 競合他社の製品ページをスクレイピングし、機能を抽出します
• エージェント B（ローンチトラッカー）： リリースノート、ブログ、ソーシャルメディアを監視して、新たなローンチを検出します
• エージェント C（価格分析）： 価格ページを追跡し、変更を特定します
• エージェント D（統合）： A、B、C の調査結果を構造化レポートにまとめます
• エージェント E（ギャップ分析）： 自社のロードマップを競合他社と比較し、戦略上のギャップにフラグを付けます

トポロジー： ハイブリッド（A、B、C を並列実行 → D → E → PM によるレビュー）

戦略的意図：

• ミッション（エージェント E）：「Q2 のロードマップに影響する可能性のある競争上の脅威を特定する」
• 制約（エージェント E）：「戦略的重点領域（エンタープライズセキュリティ、AI を活用した分析）以外の機能は推奨しない」
• 優先事項（エージェント B）：「過去 30 日以内にローンチされた機能を優先する」

監視：

• ハイブリッド方式：自動評価と週次の PM レビュー
• 指標：エージェントの完了時間、出力品質スコア（LLM-as-Judge）
• アラート：エージェント E が 5 件を超える重大なギャップ（潜在的な戦略上の脅威）にフラグを付けた場合

評価：

• ゴールデンデータセット：適切に統合された競合レポートの例を 20 件
• コードアサーション：出力が必須フィールド（competitor、features[]、pricing[]、launch_date）を含む有効な JSON であること
• 人による評価：PM が毎週、ワークフロー全体の実行を 1 回レビューする

結果：

• 時間：12 時間 → 6 時間（50％削減）
• 品質：形式が一貫し、競合他社の見落としなし
• 戦略的価値：ギャップ分析により、手作業のプロセスより 2 週間早く脅威を検知

---

例2：顧客フィードバックの統合

コンテキスト：

• 消費者向けアプリのPM
• 毎週200件以上のフィードバックを受け取っています（アプリのレビュー、サポートチケット、NPSコメント）
• 手作業のプロセス：週8時間（読み込み、タグ付け、テーマの統合）

目標： オーケストレーションされたワークフローにより、2時間に短縮します

ワークフローの設計：

エージェント：

• エージェントA（取り込み）： App Store、Google Play、Zendesk、NPSアンケートからフィードバックを収集します
• エージェントB（タグ付け）： フィードバックをカテゴリ別にタグ付けします（バグ、機能リクエスト、ユーザビリティ、パフォーマンス）
• エージェントC（感情分析）： 感情を分類します（ポジティブ、中立、ネガティブ、重大）
• エージェントD（テーマ抽出）： フィードバック全体から繰り返し現れるテーマを特定します
• エージェントE（優先順位付け）： 頻度＋感情の強さに基づいてテーマをスコアリングします
• エージェントF（統合）： 上位5つのテーマと引用例を含む週次統合レポートを作成します

トポロジー： パイプライン（A → B → C → D → E → F → PMレビュー）

戦略的意図：

• ミッション（エージェントD）：「ロードマップの機会となり得る、満たされていない顧客ニーズを特定する」
• 制約（エージェントE）：「発生頻度が低くても、重大なバグの優先順位を下げない」
• 優先事項（エージェントF）：「過去7日間に10人以上のユーザーに影響したテーマに注目する」

モニタリング：

• 自動化：ダッシュボードにエージェントの完了状況とエラー率を表示します
• アラート：エージェントCが「重大」と判定した項目が10件を超えた場合、直ちにPMへエスカレーションします

評価：

• ゴールデンデータセット：適切にタグ付けされ、適切に統合されたフィードバックの例を50件用意します
• LLM-as-Judge：エージェントDのテーマ抽出品質を毎週評価します
• 人間による評価：PMがタグ付けされたフィードバックの10％を抜き取り確認します

結果：

• 時間：8時間 → 2時間（75％削減）
• 品質：テーマを定量データ（頻度、感情）で裏付けられるようになりました
• 戦略的価値：影響の大きい3つのテーマを特定し、Q2のロードマップ機能に採用されました

---

例3：大規模なリスク分析

コンテキスト：

• エンタープライズプラットフォームのPM
• 50件の機能について、セキュリティ、コンプライアンス、パフォーマンス、ユーザビリティのリスクを分析する必要があります
• 手作業のプロセス：15時間（機能1件あたり30分）

目標： オーケストレーションされたワークフローにより、5時間に短縮します

ワークフローの設計：

エージェント：

• エージェントA（セキュリティリスク）： 機能のセキュリティ脆弱性（データ露出、認証の問題）を分析します
• エージェントB（コンプライアンスリスク）： 機能が規制要件（GDPR、HIPAA、SOC2）に準拠しているか確認します
• エージェントC（パフォーマンスリスク）： 負荷への影響を推定し、スケーリング上の懸念点を特定します
• エージェントD（ユーザビリティリスク）： 複雑なワークフローやアクセシビリティの問題を指摘します
• エージェントE（統合）： リスクスコアをまとめ、リスクマトリクスを作成します

トポロジー： 完全並列（A、B、C、Dを同時に実行 → E → PMレビュー）

戦略的意図：

• ミッション（全エージェント）：「リリースを遅らせたり、顧客に損害を与えたりする可能性のあるリスクを指摘する」
• 制約（エージェントB）：「曖昧な警告ではなく、具体的な規制要件を引用する」
• 優先事項（エージェントE）：「影響度 × 発生可能性（標準的なリスクマトリクス）に基づいてリスクの優先順位を付ける」

モニタリング：

• 自動化：ダッシュボードにリスクの分布（低／中／高／重大）を表示します
• アラート：いずれかの機能が「重大」リスクと評価された場合、PMと経営陣へエスカレーションします

評価：

• ゴールデンデータセット：既知のリスクを持つ、適切に分析された機能の例を30件用意します
• コードアサーション：リスクスコアは {low, medium, high, critical} のいずれかでなければなりません。それ以外の値は認められません
• 人間による評価：セキュリティチームがエージェントAの出力を毎月レビューします

結果：

• 時間：15時間 → 5時間（67％削減）
• 品質：50件すべての機能にわたって、一貫したリスクスコアを実現しました
• 戦略的価値：手作業のレビューでは見逃されていたはずの、重大なリスクを3件特定しました

---

よくある落とし穴

1. コンテキストエンジニアリングの前にオーケストレーションを行う

失敗のパターン： 制約、用語集、エビデンス基準といったコンテキストの基盤を整えずに、エージェントのワークフローを構築します。

結果： エージェントの出力に一貫性がなくなり、制約に違反し、幻覚が発生します。

解決策： まず context-engineering-advisor を完了します。制約レジストリ、運用用語集、戦略的意図のドキュメントを作成します。

---

2. 単純なタスクの過剰なオーケストレーション

失敗パターン： 週に2時間未満で済むタスクに、複雑なマルチエージェントのワークフローを構築します。

結果： オーケストレーションのオーバーヘッド（セットアップ、監視、メンテナンス）が、削減できる時間を上回ります。

対策： 週に5時間以上かかるタスク、または大規模に一貫性が必要なタスクのみをオーケストレーションします。

---

3. 評価計画がない

失敗パターン： 「設定したら放置」し、品質チェックなしでエージェントを実行します。

結果： 時間の経過とともに品質が低下し、ハルシネーションや制約違反を見逃します。

対策： 最低限、ゴールデンデータセットと週次の人手評価を導入します。失敗パターンの分類体系を構築し、自動評価を作成します。

---

4. 引き継ぎの失敗を無視する

失敗パターン： テストせずに、エージェント同士が正しくデータを受け渡すと思い込みます。

結果： エージェント B がエージェント A から不正な形式のデータを受け取り、役に立たない出力を生成します。

対策： 引き継ぎを明示的にテストします。各引き継ぎでデータ形式を検証します。コードアサーションを使って構造を強制します。

---

5. 「PM レビュー」の手順を忘れる

失敗パターン： オーケストレーションされたワークフローを完全自律型として扱い、人による監督を行いません。

結果： エージェントが、背景情報、共感、戦略との整合性を欠いた判断を下します。

対策： 必ず PM レビューの手順を含めます。エージェントが仮説や推奨事項を生成し、PM が検証して判断します。

---

参考資料

関連スキル

• context-engineering-advisor（対話型） — 前提条件： オーケストレーションの前にコンテキストの基盤を構築します
• ai-shaped-readiness-advisor（対話型） — エージェントオーケストレーションの成熟度を評価します（コンピテンシー #2）
• pol-probe-advisor（対話型） — バイブコーディングとの関連（迅速なプロトタイピング）
• discovery-process（ワークフロー） — ディスカバリーフェーズでオーケストレーションされたエージェントを使用します

外部フレームワーク

• Dean Peters — The Product Manager as an Orchestrator（Productside の調査）
• Dean Peters — Productside Blueprint（4 つの AI 管理ワークフロー：コンテキストエンジニアリング、合成評価、エージェント型ワークフロー、バイブコーディング）
• Teresa Torres — Continuous Discovery Habits（5 つの AI PM の実践分野：コンテキストエンジニアリング、オーケストレーション、オブザーバビリティ、評価、メンテナンス）
• Marty Cagan — Empowered（4 つの主要なリスク：価値、ユーザビリティ、実現可能性、事業性）

ツールとプラットフォーム

• Claude Projects — 1 つのプロジェクト内で複数のエージェントを使ったシンプルなオーケストレーション
• LangChain — エージェントチェーンを構築するためのフレームワーク
• LangGraph — 複雑なワークフロー向けのステートマシンオーケストレーション
• n8n / Zapier — ノーコードのワークフロー自動化（よりシンプルなオーケストレーション）