graph LR
    subgraph "戦略フェーズの成果物（入力）"
        SA[strategy_assessment.md]
        MO[motivations_and_objectives.md]
        ST[strategy_team.md]
        OR[organization_readiness.md]
        SC[strategy_considerations.md]
    end

    subgraph "CAF エージェントチーム"
        Strategy[Cloud Strategy Agent<br/>導入体験マッピング]
        Governance[Cloud Governance Agent<br/>ガバナンス責任計画]
        Platform[Cloud Platform Agent<br/>AI 導入・技術評価]
        Operations[Cloud Operations Agent<br/>管理責任計画]
        Security[Cloud Security Agent<br/>セキュリティ責任計画]
    end

    CCoE[CCoE Agent<br/>オーケストレーター<br/>運用モデル選定・文書化]
    DA[Devil's Advocate Agent<br/>批判的レビュー]
    Expert[Copilot Expert Agent<br/>フォーマット評価]
    HR[HR Evaluation Agent<br/>品質評価・改善提案]

    SA --> Strategy
    MO --> Strategy
    ST --> CCoE
    OR --> Governance
    SC --> Security

    CCoE -->|指示| Strategy
    CCoE -->|指示| Governance
    CCoE -->|指示| Platform
    CCoE -->|指示| Operations
    CCoE -->|指示| Security

    Strategy -->|成果物| DA
    Governance -->|成果物| DA
    Platform -->|成果物| DA
    Operations -->|成果物| DA
    Security -->|成果物| DA
    CCoE -->|成果物| DA

    DA -->|フィードバック| CCoE

    Expert -.->|フォーマット評価| Strategy
    Expert -.->|フォーマット評価| Governance
    Expert -.->|フォーマット評価| Platform
    Expert -.->|フォーマット評価| Operations
    Expert -.->|フォーマット評価| Security

    HR -.->|ビジネス評価| Strategy
    HR -.->|ビジネス評価| Governance
    HR -.->|ビジネス評価| Platform
    HR -.->|ビジネス評価| Operations
    HR -.->|ビジネス評価| Security
    HR -.->|ビジネス評価| CCoE
    HR -.->|ビジネス評価| DA

    classDef input fill:#ffd,stroke:#333,color:#333;
    classDef agent fill:#6cf,stroke:#333,color:#fff;
    classDef ccoe fill:#fc6,stroke:#333,color:#333;
    classDef da fill:#f66,stroke:#333,color:#fff;
    classDef expert fill:#c6f,stroke:#333,color:#fff;
    classDef hr fill:#cfc,stroke:#333,color:#333;

    class SA,MO,ST,OR,SC input;
    class Strategy,Governance,Platform,Operations,Security agent;
    class CCoE ccoe;
    class DA da;
    class Expert expert;
    class HR hr;

ポイントは、左部の黄色ノードが 戦略フェーズの成果物（入力）で各エージェントが参照すること、CCoE が計画フェーズでもオーケストレーターとして全体を統括し自身も運用モデル選定とドキュメント統合を担当すること、Devil’s Advocate のレビューが戦略フェーズの成果物との 整合性チェック も含むことの 3 点です。

観点 7 と 8 を分けているのは フェーズごとの貢献を追跡 するためです。フェーズを重ねるほど観点が増えるため、将来的には「直近フェーズの貢献度」に集約する可能性もあります。観点が増えすぎると評価コストが上がるため、フェーズ共通の観点と固有の観点を分離する設計が重要です。

計画フェーズの実行では、Copilot CLI に追加された以下の新機能も活用しています。利用できない場合は前回の戦略フェーズと同じ手法（逐次実行）で問題なく実施できます。

インタラクティブモード（Shift+Tab で切替）

Copilot CLI のインタラクティブセッションでは、Shift+Tab でモードを切り替えられます。

• デフォルト（ask/execute）: ツール使用のたびに承認を求めるモード。安全だが手動操作が多い。
• plan モード: コードを書く前に実装計画を構造化し、スコープや要件を確認してから実行するモード。複雑なタスクの事前確認に活用。
• autopilot モード: 各ステップで承認を求めず、自律的にタスクを完了するモード。手順 1（評価ポイント更新）のようなローカル実行で活用。--max-autopilot-continues で継続回数を制限可能。

autopilot モードと /delegate は別レイヤーの機能です。autopilot はローカルマシンで自律実行し、/delegate は GitHub クラウド上の Copilot Coding Agent にタスクを委任します。今回の手順では、ローカル実行（手順 1）には autopilot モード、バックグラウンド実行（手順 2・4）には /delegate を使い分けています。

その他の新機能

• 並列実行: Explore・Task・Plan・Code-review の 4 つの特化エージェントを同時実行できる機能。複数ステップの並行処理に活用。
• /tasks コマンド: ローカル CLI セッション内のバックグラウンドタスク（サブエージェントやシェルセッション）の一覧を表示。autopilot モードでのローカル実行時に活用。なお、/delegate で委任した Cloud Agent の進捗は GitHub UI（PR・Actions タブ）で確認します。
• Auto-compaction: コンテキストウィンドウが上限に近づいた際に自動圧縮する機能。長時間セッションの安定化に活用。

利用可否は Copilot CLI のバージョンに依存します。

sequenceDiagram
    participant U as ユーザー
    participant CLI as Copilot CLI
    participant CA as Copilot Coding Agent
    participant CCoE as CCoE Agent
    participant CS as Cloud Strategy
    participant CG as Cloud Governance
    participant CP as Cloud Platform
    participant CO as Cloud Operations
    participant CSec as Cloud Security
    participant DA as Devil's Advocate

    U->>CLI: /delegate で計画フェーズ実行を委任
    CLI->>CA: タスクをバックグラウンドで実行

    rect rgb(230, 240, 255)
        note over CA,DA: ステップ 1: クラウド導入体験のマッピング
        CA->>CCoE: ステップ 1 の実行を指示
        CCoE->>CS: strategy_assessment.md を参照して導入体験を分析
        CS->>CP: 技術的な導入パスの評価を依頼
        CP-->>CS: クラウドネイティブ vs 移行の技術評価
        CS->>DA: cloud_adoption_experience.md をレビュー依頼
        DA->>CS: 評価根拠の不足を指摘
        CS->>CS: 指摘を反映して改善
    end

    rect rgb(230, 255, 230)
        note over CA,DA: ステップ 2: クラウド運用モデルの選択
        CA->>CCoE: ステップ 2 の実行を指示
        CCoE->>CG: strategy_team.md を参照して運用モデルを評価
        CCoE->>CO: 運用能力に基づくモデル推奨
        CG-->>CCoE: 運用モデル案
        CO-->>CCoE: 運用面の評価
        CCoE->>DA: operating_model.md をレビュー依頼
        DA->>CCoE: 選定理由の根拠不足を指摘
    end

    rect rgb(255, 240, 230)
        note over CA,DA: ステップ 3: クラウドの責任を計画する
        CA->>CCoE: ステップ 3 の実行を指示
        CCoE->>CG: ガバナンス責任を計画
        CCoE->>CSec: セキュリティ責任を計画
        CCoE->>CO: 管理責任を計画
        CCoE->>CP: AI 導入責任を計画
        CG-->>CCoE: ガバナンス計画
        CSec-->>CCoE: セキュリティ計画
        CO-->>CCoE: 管理計画
        CP-->>CCoE: AI 計画
        CCoE->>DA: cloud_responsibilities.md をレビュー依頼
        DA->>CCoE: 責任の重複・漏れを指摘
    end

    rect rgb(245, 230, 255)
        note over CA,DA: ステップ 4: クラウドの責任を文書化する
        CA->>CCoE: ステップ 4 の実行を指示
        CCoE->>CCoE: 全成果物を統合して導入計画を文書化
        CCoE->>DA: adoption_plan.md をレビュー依頼
        DA->>CCoE: 整合性の問題を指摘
        CCoE->>CCoE: 最終調整
    end

    CA->>CA: 全成果物の最終レビュー
    CA->>U: PR を作成して完了報告

主なポイント

• 5R 分類（22 ワークロード）: Rehost 27%（6 WL） / Replace 18%（4 WL） / Refactor 23%（5 WL） / Rearchitect 18%（4 WL） / Rebuild 14%（3 WL、COBOL 基幹 3 本を含む）
• 3 フェーズ ロードマップ: Phase 1（0〜6 ヶ月、Landing Zone 構築 + Rehost 試行）→ Phase 2（7〜18 ヶ月、Replace/Refactor 本格移行、DC 満了対応）→ Phase 3（19〜36 ヶ月、Rearchitect/Rebuild + クラウドネイティブ新規）
• DC 契約満了（2026 年 9 月）を最重要マイルストーン として Rehost 6 WL を最優先で移行。COBOL 基幹 3 本は Rebuild 対象として最終フェーズに配置

Devil’s Advocate のフィードバック（計 11 件：Critical 3 / High 4 / Medium 3 / Low 1）

Critical はすべて解消済み。中でも重要だったのは 5R 比率の内部矛盾を突いた以下の指摘でした。

§3.1 における 5R 比率の合計が 110% となっており、内部矛盾を起こしています。

v1.1 でワークロード本数を再カウントし、合計 100%≒表記で修正しました。数値の自己整合性は計画ドキュメントの信頼性を支える基本条件で、Devil’s Advocate のレビューが効果的に機能した好例です。

詳細は cloud_adoption_experience.md を参照してください。

主なポイント

• 最終姿: プラットフォームチームが共通基盤・ガードレールを提供し、事業部門側の連邦チームがその中で自律的にワークロードを運用
• 移行パス: Phase 1 は一時的に中央集権型 CCoE 主導 → Phase 2 以降でガバナンスとスキルの成熟度に応じて段階的に連邦要素を拡大
• 人員計画（Phase 1）: CCoE 専任 6 名 + 外部パートナー 10〜15 名でスタート、社内スキル豊富化に応じて連邦チームに責任を委譲
• ESLZ 整合性: Microsoft 推奨の Enterprise-Scale Landing Zone の責任分担モデルと一致

Devil’s Advocate のフィードバック（計 8 件：Critical 2 / High 4 / Medium 2）

うち 7 件は adoption_plan.md へ持ち越し。中でも重要な Critical 指摘は、フェーズ移行ゲートの設計思想に関するものでした。

フェーズ移行ゲート条件がカレンダーベース（Phase 1: 0〜6 ヶ月…）となっており、成熟度の定量的判断基準が欠如しています。「6 ヶ月経過したから次フェーズ」という取り決めで進めると、未成熟な連邦チームに権限・責任を付与してしまうリスクがあります。

この指摘は、後続の adoption_plan.md で 35 項目の Exit Criteria（フェーズ間移行の定量的判定基準）として体系化されることで解消されています。

詳細は operating_model.md を参照してください。

主なポイント

• 統合 RACI マトリックス: 40+ の活動領域（Policy as Code、コスト管理、インシデント対応、Landing Zone 運用、AI ガバナンス、データガバナンスなど）を一覧化し、チーム間の重複・漏れを可視化
• 主な改善目標: ガバナンス成熟度 Lv 2→4、重大インシデント応答 72h→4h、可用性 SLO 99.5%→99.95%、Azure Policy モード Audit→Deny（高リスクから段階適用）、AI ワークロード 0→3 本（Gate 条件付き）
• コンプライアンス連携: PCI DSS v4.0 / ISMAP / 改正個情法 / ISO 27001 を RACI の各項とトレーサビリティ可能な形で連携

Devil’s Advocate のフィードバック（計 8 件：Critical 2 / High 4 / Medium 2）

重要だった Critical 指摘は、AI 責任の重さと組織の技術的準備度のギャップを突いたものでした。

AI 導入の責任セクションで「3 年で AI ワークロード 3 本」をコミットしていますが、技術的準備度は 1.5/5.0 と評価された組織です。スキルもデータ基盤もガバナンスも不十分な状態で AI 推進の責任を負わせるのは、ゲート条件を付さない限り過大なコミットメントとなります。

この指摘を受け、adoption_plan.md では AI Gate 1（Month 12、0 条件） と AI Gate 2（Month 24、0 条件） を設け、条件未達成時は AI ワークロード推進を保留する設計に修正されています。

詳細は cloud_responsibilities.md を参照してください。

主なポイント

• 6 つの主要意思決定 (MD-01〜MD-06): 二軸アプローチ採用、ハイブリッド連邦モデル採用、AI Gate 設定、パートナー体制、責任分担、予算枠
• 22 マイルストーン (MS-01〜MS-22) を 3 年間に配置し、主要チームと OKR をマッピング
• 予算・リターン: 3 年トータル投資 ¥507M、5 年 ROI 81%、投資回収期間 18〜24 ヶ月
• Exit Criteria 35 項目 と AI Gate 1（Month 12, 10 条件） / Gate 2（Month 24, 10 条件） でフェーズ間移行をゲート
• パートナー体制: MSP＋SIer 2 社の三層体制、RACI / コスト / SLA を明記
• 変革管理 Wave 1〜3 ・ コンプライアンスロードマップ ・ リスク台帳 15 件 ・ KPI 3 階層（経営 / 部門 / チーム）

Devil’s Advocate のフィードバック（新規 7 件 + 持ち越し Critical 5 件を検証）

すべての持ち越し Critical 5 件は adoption_plan.md にて体系的に解消され、最終レビューで 「条件付き承認（Conditionally Approved）」 と判定されました。

本計画は CAF 計画フェーズの要件を概ね満たします。ただし、以下 3 点はキックオフ前に必ず解消してください。

1. Phase 0 開始日の明記：「0 ヶ月」とされている起点を YYYY-MM-DD で明示し、全マイルストーンをこれに連動
2. Exit Criteria 判定会議体の設置：各フェーズ間移行を 35 Exit Criteria でゲートするレビュー体を RACI 付きで明示
3. AI Gate 1 の Month 9 前倒し検討：データとスキルの成熟度を早期検知するために、Gate 1 を Month 12 から Month 9 へ前倒しする余地を検討

いずれもキックオフミーティングで解消できるレベルの指摘で、計画フェーズの成果物全体としては雇用可能な品質に達していると Devil’s Advocate が評価した形です。

詳細は adoption_plan.md を参照してください。

graph TB
    D1[初回 Output 生成] --> R1[Devil's Advocate<br/>レビュー]
    R1 --> F1{重大な<br/>指摘あり?}
    F1 -->|はい| I1[指摘を反映して改善]
    I1 --> R1
    F1 -->|いいえ| SC[戦略成果物との<br/>整合性チェック]
    SC --> F3{整合性<br/>OK?}
    F3 -->|いいえ| I1
    F3 -->|はい| C1[CCoE による<br/>最終レビュー]
    C1 --> F2{全体整合性<br/>OK?}
    F2 -->|はい| Done[成果物確定]
    F2 -->|いいえ| I1

    classDef process fill:#6cf,stroke:#333,color:#fff;
    classDef decision fill:#fc6,stroke:#333,color:#333;
    classDef done fill:#cfc,stroke:#333,color:#333;
    classDef check fill:#f9c,stroke:#333,color:#333;

    class D1,R1,I1,C1 process;
    class F1,F2,F3 decision;
    class Done done;
    class SC check;

評価は以下のコマンド 1 つで、技術評価 → ビジネス評価 → 統合改善 → 再評価までを一括実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

copilot -p "/delegate
以下のタスクを実行してください:

## 技術評価（Copilot エキスパート）
1. @copilot-expert を使って .github/agents/ 内の全エージェントのフォーマット評価を実施
2. SKILL.md のフロントマター検証、copilot-instructions.md との整合性チェックも含める
3. 7 観点 × 5 段階でスコアリングし、結果を出力

## ビジネス評価（人事エージェント）
4. @hr-evaluation を使って計画フェーズにおける各エージェントの働きを評価
5. 評価観点は更新済みの 9 観点（計画フェーズへの貢献度、戦略→計画の連携度を含む）
6. 各エージェントのスコアを 9 観点 × 5 段階でスコアリング

## 統合と改善
7. 両方の評価結果を統合し、低スコアの観点について改善提案を出す
8. 改善提案に基づいてエージェントの .agent.md を更新
9. 更新後に再評価を実施する
10. 結果を EVALUATION_REPORT.md に出力する
"