前回の記事で作成した CAF エージェントチームを使って、Azure CAF の戦略フェーズを 無人で 実施してみます！エージェントたちが自律的に戦略ドキュメントを作成し、批判的なレビューを経て改善していく検証です。

要約

本記事では、GitHub Copilot のカスタムエージェント 9 体を使って、Azure CAF の戦略フェーズを 無人で 実行しました。主なポイントは以下のとおりです。

• Devil’s Advocate エージェント を新設し、ポジティブループに陥るリスクを予防。4 層ガードレール（ツール最小権限 × 禁止事項 × 提案のみ × /plan 推奨）で安全に運用
• 5 ステップの戦略ドキュメント を /delegate コマンドで自動生成（合計約 270 KB、5 ファイル）
• Devil’s Advocate の批判的レビュー → 改善サイクルにより、CCoE 最終レビューで全 7 項目をパス
• Copilot エキスパート（技術面）+ 人事エージェント（ビジネス面）の 2 軸評価 を全 9 エージェントに実施。統合スコア平均 62.8/70（89.7%）を達成
• 検証に使用したリポジトリ: NakayamaKento/caf-agents

はじめに

これまでの記事で、CAF エージェントの土台を 2 ステップで構築してきました。

1. Azure CAF の組織論に基づいたエージェントを作成し隊
   CAF の組織論に基づいた 7 つの AI エージェントを GitHub Copilot CLI のカスタムエージェントとして作成。人事評価エージェントによる改善サイクルも実施しました。

2. カスタムエージェントのフォーマットを整え隊
   .agent.md のベストプラクティス（description をトリガーとして設計、ツール最小権限、明示的な禁止事項）を整理。Agent Skills（SKILL.md）、Custom Instructions、Prompt Files、4 層ガードレール設計を導入し、Copilot エキスパートエージェントによるフォーマット評価を追加しました。

今回は、これらのエージェントを使って CAF の戦略フェーズの成果物を実際にエージェントに無人で作成させる 検証を行います。人間は最初の指示を出すだけで、エージェントたちが自律的にドキュメントを作成し、互いにレビュー・改善を繰り返す、まさに「エージェントだけで CAF を回す」という実験です。

想定読者

• 前回までの記事を読んで、エージェントの活用に興味を持った方
• Azure CAF の戦略フェーズについて具体的な成果物イメージを知りたい方
• AI エージェントの自律的な協調動作に関心がある方
• /delegate コマンドによる無人実行の実践例を知りたい方

この記事のゴール

• CAF 戦略フェーズの 5 ステップをエージェントで無人実行する
• Devil’s Advocate エージェントによる批判的レビューの導入
• 成果物の品質向上サイクルの確立
• 人事エージェントによる戦略フェーズ用の評価と改善

前回からの進化ポイント

前回の記事ではエージェントの「作成と改善」、前々回ではエージェントの「フォーマット整備」が主テーマでしたが、今回はエージェントに 実際の仕事をさせる ところまで踏み込みます。具体的には以下の進化ポイントがあります。

背景

CAF 戦略フェーズとは

Azure CAF の Strategy メソドロジー は、クラウド導入の最初のステップです。組織がなぜクラウドを導入するのか、何を達成したいのかを明確にし、関係者の合意を得るフェーズです。

戦略フェーズは以下の 5 つのステップ で構成されています。

graph LR
    S1[1. クラウド導入戦略<br/>を評価する] --> S2[2. 動機・ミッション<br/>目標を定義する]
    S2 --> S3[3. 戦略チーム<br/>を定義する]
    S3 --> S4[4. 組織を<br/>準備する]
    S4 --> S5[5. 戦略を<br/>通知する]

    classDef step fill:#69f,stroke:#333,color:#fff;
    class S1,S2,S3,S4,S5 step;

なぜエージェントで実施するのか

前回の記事で作成したエージェントは、それぞれ CAF のチーム構造に対応した専門知識を持っています。これらのエージェントに戦略フェーズを実施させることで、以下のメリットが期待できます。

• 多角的な視点: 各専門エージェントがそれぞれの専門領域から戦略を検討
• 一貫性: CAF のガイダンスに基づいた一貫した品質の成果物
• 批判的レビュー: Devil’s Advocate エージェントが楽観的なバイアスを防止
• 自動化: /delegate による無人実行で、人間は結果のレビューに集中できる

ただし、エージェント同士が互いの Output に対して過度にポジティブなフィードバックを返し合う「ポジティブループ」に陥るリスクがあります。戦略フェーズでは組織の方向性を決める重要な判断が求められるため、あらぬ方向に進まないよう 批判的な視点を持つエージェント が不可欠です。

フォルダ階層の設計思想

CAF は戦略フェーズだけでなく、計画（Plan）、準備（Ready）、導入（Adopt）、ガバナンス（Govern）と複数のフェーズを持っています。今後すべてのフェーズをエージェントで実施していく予定であるため、成果物を整理するフォルダ階層をこの時点で設計しておきます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

caf-agents/
├── .github/
│   ├── agents/                    # エージェント定義
│   │   ├── cloud-strategy.agent.md
│   │   ├── cloud-governance.agent.md
│   │   ├── cloud-platform.agent.md
│   │   ├── cloud-operations.agent.md
│   │   ├── cloud-security.agent.md
│   │   ├── ccoe.agent.md
│   │   ├── hr-evaluation.agent.md
│   │   ├── copilot-expert.agent.md  ← フォーマット整備で追加
│   │   └── devils-advocate.agent.md ← 今回追加
│   ├── skills/                    # Agent Skills（フォーマット整備で追加）
│   │   ├── caf-governance-review/
│   │   │   └── SKILL.md
│   │   ├── azure-policy-lint/
│   │   │   └── SKILL.md
│   │   └── iac-security-check/
│   │       └── SKILL.md
│   ├── instructions/              # パス固有インストラクション
│   │   ├── bicep.instructions.md
│   │   └── policy.instructions.md
│   ├── prompts/                   # 再利用可能なプロンプトテンプレート
│   │   └── agent-review.prompt.md
│   └── copilot-instructions.md    # リポジトリ全体のベースラインルール
├── outputs/
│   ├── 01_strategy/               # 戦略フェーズの成果物
│   │   ├── strategy_assessment.md
│   │   ├── motivations_and_objectives.md
│   │   ├── strategy_team.md
│   │   ├── organization_readiness.md
│   │   └── strategy_considerations.md
│   ├── 02_plan/                   # 計画フェーズ（次回以降）
│   ├── 03_ready/                  # 準備フェーズ（次回以降）
│   ├── 04_adopt/                  # 導入フェーズ（次回以降）
│   └── 05_govern/                 # ガバナンスフェーズ（次回以降）
└── EVALUATION_REPORT.md           # エージェント評価レポート

設計のポイントは以下の 4 点です。

1. フェーズごとの番号付きフォルダ: CAF のフェーズ順にナンバリングすることで、進捗が一目でわかる
2. 成果物のファイル名: 各ステップに対応した英語のファイル名で統一
3. 評価レポートはルート直下: エージェントの評価はフェーズに依存しないため、ルートに配置
4. skills / instructions / prompts の整備: フォーマット整備の記事 で導入した Agent Skills、パス固有インストラクション、Prompt Files をリポジトリに配置し、エージェントの品質を底上げ

ざっくり手順

1. Devil’s Advocate エージェントの追加
2. フォルダ階層の設計と準備
3. 戦略フェーズの 5 ステップを /delegate で無人実行
4. 成果物のレビューと改善サイクル
5. 人事エージェントによる評価と評価基準の見直し

詳細な手順

手順 1: Devil’s Advocate エージェントの追加

なぜ Devil’s Advocate が必要なのか

エージェント同士が互いの Output に対して 過度にポジティブなフィードバック を返し合い、品質が向上しないまま合意してしまう「ポジティブループ」に陥るリスクがあります。「素晴らしい提案です！」「完璧なドキュメントです！」のような応答ばかりでは、品質向上にはつながりません。

特に戦略フェーズでは、以下のようなリスクがあります。

• 楽観的すぎるコスト見積もり
• 現実離れしたスケジュール
• 組織の課題を過小評価した戦略
• 技術的な実現可能性を検討しない目標設定

これらを防ぐために、意図的にケチをつけ、批判点を探すエージェント（Devil’s Advocate Agent）を新たに作成します。

Devil’s Advocate エージェントの .agent.md 定義

フォーマット整備の記事 で学んだベストプラクティスを適用して、Devil’s Advocate エージェントを作成します。特に以下の点に注意します。

• description をトリガーとして設計: 「レビュー」「批判」「リスク」などのキーワードを含め、Copilot がいつこのエージェントを呼び出すべきか推論できるようにする
• ツール最小権限: read と search のみ付与（分析専用エージェントなので edit は不要）
• 明示的な禁止事項（DON’T セクション）: 暴走防止のためのガードレール
• 出力フォーマットの固定: 構造化された指摘で品質を安定させる

以下のプロンプトで Copilot CLI にエージェントを作成させます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

他のエージェントの Output に対して批判的な視点で検証する Devil's Advocate エージェントを作成してください。

以下の要件で .github/agents/devils-advocate.agent.md を作成してください:
- name: devils-advocate
- description: 他のエージェントの提案や成果物に対して批判的な視点でレビューし、
  楽観的バイアスやリスクの見落としを指摘するエージェント。
  「レビュー」「批判」「リスク」「問題点」「改善」のキーワードで呼び出される。
- tools: read, search（最小権限。edit は付与しない）
- ガードレール: 4 層構造を適用
  - Layer 1: ツール最小権限（read + search のみ）
  - Layer 2: 明示的禁止事項（DON'T セクション）
  - Layer 3: 提案のみモード（自分では修正しない）
  - Layer 4: /plan モード推奨
- 出力フォーマット: 問題点・リスク・代替案・改善提案の構造化出力

作成された .agent.md ファイルの主要部分を紹介します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

---
name: devils-advocate
description: >-
  他のエージェントの提案や成果物に対して批判的な視点でレビューし、
  楽観的バイアスやリスクの見落としを指摘するエージェント。
  「レビュー」「批判」「リスク」「問題点」「改善」のキーワードで呼び出される。
tools:
  - read
  - search
---

# Devil's Advocate エージェント

他のエージェントが生成した提案・設計・成果物に対して、意図的に批判的な視点からレビューを行い、楽観的バイアス・リスクの見落とし・論理的飛躍を検出するメタエージェント。
自らは修正を行わず、問題点の指摘と改善提案のみを構造化して出力する。

---

## 基本原則

- **批判的思考の徹底**: すべての提案に対して「本当にそうか？」「最悪のケースは？」「見落としはないか？」の 3 問を常に問う
- **建設的な批判**: 否定のための否定ではなく、必ず代替案または改善方向を示す
- **エビデンスベース**: 指摘は具体的な根拠（CAF ベストプラクティス、Azure 制約、過去のインシデント事例等）に基づく
- **提案のみモード**: 自らコード・設定・ドキュメントを修正しない。指摘と改善提案のみを出力する
- **バイアスの可視化**: 楽観的バイアス・確証バイアス・生存者バイアスなど、認知バイアスを明示的に指摘する

---

## ガードレール（4 層構造）

### Layer 1: ツール最小権限

このエージェントは `read` と `search` のみを使用する。

| ツール | 用途 | 許可 |
|---|---|---|
| `read` | 対象成果物・関連ファイルの読み取り | ✅ |
| `search` | コードベース・ドキュメントの検索 | ✅ |
| `edit` | ファイルの編集・修正 | ❌ **禁止** |
| `shell` | コマンド実行 | ❌ **禁止** |

> **理由**: Devil's Advocate は批判的レビューに特化した役割であり、成果物の修正権限を持つと役割の境界が曖昧になる。修正は対象エージェントまたは担当者が行う。

### Layer 2: 明示的禁止事項（DON'T）

以下の行為は明示的に禁止する:

フォーマット整備の記事 で導入した 4 層ガードレール設計を Devil’s Advocate にも適用していることが重要なポイントです。分析専用エージェントなので edit 権限を付与せず（Layer 1）、明示的な禁止事項を列挙し（Layer 2）、提案のみモードを宣言しています（Layer 3）。

エージェント構成の全体像

Devil’s Advocate エージェントの追加により、エージェント構成は以下のようになります。CCoE がオーケストレーターとして全体を統括し、Devil’s Advocate が各成果物に対してフィードバックするという構図です。さらに、フォーマット整備の記事 で導入した Copilot エキスパートエージェントが技術的なフォーマット品質を担保します。

graph TB
    User[ユーザー]

    subgraph "CAF エージェントチーム"
        Strategy[Cloud Strategy Agent<br/>ビジネス目標・投資判断]
        Governance[Cloud Governance Agent<br/>ポリシー・コンプライアンス]
        Platform[Cloud Platform Agent<br/>基盤設計・IaC]
        Operations[Cloud Operations Agent<br/>監視・運用]
        Security[Cloud Security Agent<br/>セキュリティ・脅威対策]
    end

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

    User -->|指示| CCoE
    CCoE -->|ビジネス戦略| Strategy
    CCoE -->|ガバナンス要件| Governance
    CCoE -->|基盤要件| Platform
    CCoE -->|運用要件| Operations
    CCoE -->|セキュリティ要件| Security

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

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

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

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

    classDef user fill:#f6d,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 User user;
    class Strategy,Governance,Platform,Operations,Security agent;
    class CCoE ccoe;
    class DA da;
    class Expert expert;
    class HR hr;

ポイントは以下の 3 点です。

• 各エージェントの成果物が 直接最終版になるのではなく、必ず Devil’s Advocate のレビューを経由する
• Copilot エキスパート（紫）がエージェント定義のフォーマット品質を評価する（技術面）
• HR 評価エージェント（緑）がビジネス要件への準拠度を評価する（ビジネス面）

手順 2: フォルダ階層の設計と準備

先ほど設計したフォルダ階層を実際にリポジトリに作成します。

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

# caf-agents リポジトリで作業
cd caf-agents

# outputs ディレクトリの作成
mkdir -p outputs/01_strategy
mkdir -p outputs/02_plan
mkdir -p outputs/03_ready
mkdir -p outputs/04_adopt
mkdir -p outputs/05_govern

# ディレクトリ構造の確認
tree outputs/
# outputs/
# ├── 01_strategy/
# ├── 02_plan/
# ├── 03_ready/
# ├── 04_adopt/
# └── 05_govern/

各フォルダの目的と、配置される成果物を以下にまとめます。

手順 3: 戦略フェーズの無人実行

いよいよ本題です。CCoE エージェントをオーケストレーターとして、各エージェントに /delegate で指示を出し、戦略フェーズの 5 ステップを無人で実行します。

無人実行の全体フロー

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 DA as Devil's Advocate
    participant Others as 他のエージェント

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

    rect rgb(230, 240, 255)
        note over CA,DA: ステップ 1: クラウド導入戦略の評価
        CA->>CCoE: ステップ 1 の実行を指示
        CCoE->>CS: 組織の現状評価を指示
        CCoE->>Others: 各専門分野の現状を報告
        CS->>DA: strategy_assessment.md をレビュー依頼
        DA->>CS: 評価の甘さを指摘
        CS->>CS: 指摘を反映して改善
    end

    rect rgb(230, 255, 230)
        note over CA,DA: ステップ 2〜5: 同様のサイクル
        CA->>CCoE: 各ステップを順次実行
        CCoE->>Others: 各エージェントに指示
        Others->>DA: 成果物をレビュー依頼
        DA->>Others: フィードバック
        Others->>Others: 改善を反映
    end

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

/delegate コマンドの実行

以下のコマンド 1 つで、戦略フェーズ全体を無人実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

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

## 目的
Azure CAF の戦略フェーズ（Strategy Methodology）の 5 ステップを実行し、
各ステップの成果物を outputs/01_strategy/ に作成してください。

## 事前準備
1. outputs/01_strategy/ ディレクトリが存在しない場合は作成する
2. .github/agents/ 内のすべてのエージェント定義を読み込む

## 戦略フェーズの実行
以下の 5 ステップを順番に実行してください:

### ステップ 1: クラウド導入戦略の評価
- @cloud-strategy が主導して組織のクラウド導入準備状況を評価
- 全エージェントがそれぞれの専門分野から現状を評価
- 成果物: outputs/01_strategy/strategy_assessment.md
- @devils-advocate がレビューし、評価の甘さや見落としを指摘
- 指摘を反映して成果物を改善

### ステップ 2: 動機・ミッション・目標の定義
- @cloud-strategy が動機を分類・整理し、ミッションと目標を定義
- OKR フレームワークで目標を構造化
- 成果物: outputs/01_strategy/motivations_and_objectives.md
- @devils-advocate がレビュー

### ステップ 3: 戦略チームの定義
- @ccoe が各エージェントの役割を CAF のチーム構造にマッピング
- 責任分担（RACI マトリックス）を作成
- 成果物: outputs/01_strategy/strategy_team.md
- @devils-advocate がレビュー

### ステップ 4: 組織の準備
- @ccoe がリーダーシップバイイン文書を作成
- @cloud-operations が運用モデルの評価を実施
- 成果物: outputs/01_strategy/organization_readiness.md
- @devils-advocate がレビュー

### ステップ 5: 戦略情報の整理
- 各エージェントが専門分野の戦略考慮事項を Output:
  - @cloud-governance: 財務効率
  - @cloud-platform: AI 統合
  - @cloud-operations: レジリエンス
  - @cloud-security: セキュリティ
  - @ccoe: 持続可能性
- 成果物: outputs/01_strategy/strategy_considerations.md
- @devils-advocate が全体をレビュー

## 品質保証
- 各成果物は @devils-advocate のレビューを必ず通すこと
- 指摘事項が解消されるまで改善を繰り返すこと
- 最終的に @ccoe が全成果物の整合性を確認すること

## 完了条件
- 5 つの成果物がすべて outputs/01_strategy/ に作成されていること
- @devils-advocate の重大な指摘がすべて解消されていること
- 各成果物が Azure CAF のガイダンスに準拠していること
"

ここからは、各ステップでエージェントがどのような成果物を作成し、Devil’s Advocate がどのようなフィードバックを返したかを見ていきます。

ステップ 1: クラウド導入戦略の評価

最初のステップでは、Cloud Strategy エージェントが主導して組織のクラウド導入準備状況を評価します。他のエージェントもそれぞれの専門分野から現状の評価に参加します。

CAF の クラウド導入戦略を評価する ステップに基づき、以下の観点で評価を行います。

生成された strategy_assessment.md の主要部分は以下のとおりです。

Devil’s Advocate のフィードバック（ステップ 1）

Critical 6 件・High 1 件の指摘が出ました。「ROI・TCO 数値が文書間で矛盾している」「DC 契約満了とロードマップの時系列が合わない」「Year1 のコスト削減額が成立しない」「人員計画が非現実的」等の指摘を受け、TCO 削減率の統一（35%）、ロードマップの改訂、投資回収期間の修正（18〜24 ヶ月）などが行われました。

ステップ 2: 動機・ミッション・目標の定義

2 番目のステップでは、Cloud Strategy エージェントがクラウド導入の動機を分類し、ミッションと目標を定義します。

今回は、クラウド導入の動機を以下のカテゴリに分類しています。

Cloud Strategy エージェントは、これらの動機を OKR（Objectives and Key Results）フレームワークで構造化した成果物を作成しました。

Devil’s Advocate のフィードバック（ステップ 2）

Devil’s Advocate から「DC 契約満了 FY2026 Q3 と移行ロードマップが矛盾している」「OKR の Key Result に定量基準がない」との指摘があり、段階的移行（18〜24 ヶ月）への修正と各 KR へのベースライン・目標値の設定が行われました。

ステップ 3: 戦略チームの定義

3 番目のステップでは、CCoE エージェントが各エージェントの役割を CAF のチーム構造にマッピングします。

CAF の 戦略チームを定義する ステップでは、戦略を構築し実行するための個人とチームを特定することが求められています。今回は AI エージェントがチームメンバーを務めるため、従来のチーム構成とは異なるアプローチが必要です。

CCoE エージェントが 10 の活動領域 × 7 チームの RACI（Responsible, Accountable, Consulted, Informed） マトリックスを作成しました。また、クラウド導入の失敗要因分析（組織・チーム体制の未整備が約 35%）に基づいたチーム設計がなされています。詳細は strategy_team.md を参照してください。

ステップ 4: 組織の準備

4 番目のステップでは、リーダーシップのバイイン（経営層の支持獲得）と組織戦略の調整を行います。CAF の 組織を準備する ステップに基づいています。

CCoE エージェントがエグゼクティブバイイン文書の骨格を作成し、Cloud Operations エージェントが運用モデルの評価を行いました。

エグゼクティブバイイン文書の構成

成果物として作成された organization_readiness.md には、以下のセクションが含まれています。

1. エグゼクティブサマリー: 経営層向けの 1 ページ要約
2. ビジネスケース: クラウド導入の投資対効果（ROI）
3. リスクと緩和策: 想定されるリスクとその対応策
4. ロードマップ: 段階的な導入スケジュール
5. 必要な投資: 人材、技術、トレーニングへの投資
6. 成功指標: 各フェーズの KPI

運用モデルの準備度評価

Cloud Operations エージェントが実施した運用モデルの評価では、リーダーシップコミットメント（2.5/5）、文化的準備度（2.0/5）、技術的準備度（1.5/5）、プロセス成熟度（2.0/5）、財務準備（2.5/5）の 5 領域を評価し、すべてに改善ギャップが確認されました。詳細は organization_readiness.md を参照してください。

Devil’s Advocate から「Year1 のコスト削減 ¥280M が成立しない」「総合スコアが他文書と乖離している」「投資回収期間 8〜10 ヶ月が楽観的」等の指摘があり、Year1 を投資フェーズと明記し、投資回収期間を 18〜24 ヶ月に修正、総合スコアを全文書で 2.6/5.0 に統一する対応が行われました。

ステップ 5: 戦略情報の整理

最後のステップでは、各エージェントがそれぞれの専門分野で戦略考慮事項を Output します。CAF の 戦略を通知する ステップに基づき、以下の 5 つの分野をカバーします。

各エージェントが専門分野のセクションを担当し、最終的に 1 つの strategy_considerations.md に統合されます。

手順 4: 成果物のレビューと改善サイクル

5 つの成果物が生成された後、Devil’s Advocate エージェントによる全体レビューと改善のサイクルを回します。

改善サイクルの流れ

graph TB
    D1[初回 Output 生成] --> R1[Devil's Advocate<br/>レビュー]
    R1 --> F1{重大な<br/>指摘あり?}
    F1 -->|はい| I1[指摘を反映して改善]
    I1 --> R1
    F1 -->|いいえ| 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;

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

改善の実施結果

今回の検証では、Devil’s Advocate が合計 Critical 5 件・High 1 件の指摘を行い、改善サイクルを経て全成果物が確定しました。合計で約 270 KB（5 ファイル）の戦略ドキュメントが生成されています。

すべての重大指摘が解消された時点で、改善サイクルを終了しました。

CCoE の最終レビュー

CCoE エージェントが全成果物の整合性を確認しました。総合準備スコア（2.6/5.0）の統一、投資回収期間（18〜24 ヶ月）の統一、TCO 削減率の参照先指定、ロードマップ時系列の整合性など 7 項目がチェックされ、すべて合格と判定されています。

手順 5: エージェントの評価（Copilot エキスパート + 人事エージェント）

最後に、エージェントの品質を 2 つの観点から評価します。フォーマット整備の記事 で導入した 2 エージェント連携評価 のアプローチを適用します。

• Copilot エキスパートエージェント（技術評価）: フォーマット準拠、description 品質、ツール最小権限、バウンダリ定義、具体例、Skills 連携、Instructions 活用の 7 観点 × 5 段階 = 35 点満点
• 人事評価エージェント（ビジネス評価）: CAF 準拠度、役割の明確さ、実用性、連携、セキュリティに加え、新たに 批判的思考力 と 戦略フェーズへの貢献度 を追加した 7 観点 × 5 段階 = 35 点満点

両方を組み合わせた 統合スコア（/70） で全 9 エージェントを評価しました。

評価の実施

2 つのエージェントによる評価を /delegate で自動実行しました。

 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. 評価観点は従来の 5 観点 + 新しい 2 観点（批判的思考力、戦略フェーズへの貢献度）
6. 各エージェントのスコアを 7 観点 × 5 段階でスコアリング

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

評価結果サマリー

技術評価で検出された問題

Copilot エキスパートによるフォーマット評価で、以下の主要な問題が検出されました。

• @devils-advocate の孤立: SKILL.md が存在せず（Skills: 1/5）、copilot-instructions.md のエージェント体系テーブルにも未記載
• @hr-evaluation の設計不整合: 評価専用エージェントなのに不要な edit ツールを保有、バウンダリ定義セクションが欠如（2/5）

ビジネス評価で検出された問題

人事エージェントによる 7 観点評価で、新規追加した 2 観点のスコアが低い傾向がありました。

• 批判的思考力（3/5）: @cloud-governance / @cloud-platform / @cloud-security / @ccoe が推奨事項の提示に特化しすぎ、トレードオフの提示が不足
• 戦略フェーズへの貢献度（2/5）: @cloud-operations が Operate/Manage フェーズ偏重で、Strategy フェーズへの貢献が未定義

改善の実施

検出された問題に対して、以下の改善を実施しました。

• @devils-advocate に SKILL.md を新規作成し、copilot-instructions.md のテーブルに追加
• @hr-evaluation から edit ツールを削除し、バウンダリ定義セクションを追加
• @cloud-governance / @cloud-platform / @cloud-security / @ccoe に ⚖️ 設計上のトレードオフ セクションを追加（例: Deny vs Audit、Hub-Spoke vs Virtual WAN、Defender プラン別コスト対効果、CCoE アンチパターン 5 種）
• @cloud-operations に Strategy/Plan/Ready 各フェーズへの具体的貢献を定義

再評価の結果

改善後の再評価で、全 9 エージェントが両評価の合格基準を達成しました。

全体平均は 62.8/70（89.7%） となり、改善前の 84% から +5.7% 向上しました。特に @devils-advocate（+6）と @hr-evaluation（+10）で大幅な改善が見られました。

詳細は EVALUATION_REPORT.md および PR #5 を参照してください。

実行結果

完成した戦略ドキュメント

最終的に完成した outputs/01_strategy/ の成果物は以下のとおりです。

詳細は outputs/01_strategy/ を参照してください。

改善サイクルの回数と結果の推移

各成果物に対して Devil’s Advocate のレビューと改善が実施され、最終的にすべての重大指摘が解消されました。改善サイクルを通じて、合計約 270 KB の戦略ドキュメントが完成しています。

エージェント評価スコアの変化

技術+ビジネスの 2 軸評価（各 35 点、計 70 点満点）により、全 9 エージェントの平均統合スコアが 62.8/70（89.7%）に到達しました。特に @devils-advocate（+6）と @hr-evaluation（+10）で大幅な改善が見られ、SKILL.md の新規作成やバウンダリ定義の追加が効果的でした。

終了基準の達成状況

今回定義した終了基準に対する達成状況は以下のとおりです。

まとめ

得られた知見

Azure CAF の戦略フェーズをエージェントで無人実行する検証を通じて、以下の知見が得られました。

• Devil’s Advocate エージェントの価値は非常に高い: 批判的な視点を持つエージェントを導入することで、Output の品質向上が期待できます。特に「根拠のない数値」「曖昧な表現」「楽観的すぎる目標」に対する指摘が効果的です。エージェント同士がポジティブフィードバックだけを返し合う「ポジティブループ」に陥るリスクを未然に防ぐ意味でも重要です。

• 4 層ガードレールは無人実行で不可欠: フォーマット整備の記事 で導入したガードレール設計（ツール最小権限 × 明示的禁止事項 × 提案のみモード × /plan モード推奨）が、無人実行時のエージェント暴走防止に貢献します。特に Devil’s Advocate に edit 権限を付与しないことで、成果物の意図しない改変を防止できます。

• 2 エージェント連携評価（技術 + ビジネス）の効果: Copilot エキスパートと人事評価エージェントの 2 つの視点で全 9 エージェントを評価することで、単一視点では見えない問題を検出できます。実際に技術評価では @devils-advocate の SKILL.md 欠如や @hr-evaluation の不要なツール付与が、ビジネス評価では批判的思考力やフェーズ貢献度の不足が検出されました。統合スコア（/70）で管理することで、技術・ビジネス双方のバランスが取れた改善が可能になります。

• フォルダ階層の設計は早期に行うべき: 今回、CAF の全フェーズを見据えたフォルダ構造を設計したことで、成果物の管理が容易になりました。後からフォルダ構造を変更すると、ドキュメント間の参照関係が壊れるリスクがあるため、最初の段階で設計しておくことをお勧めします。

• 改善サイクルは数回で収束する: エージェントが前回の指摘を学習して同じ間違いを繰り返さないため、改善サイクルは数回で収束することが期待できます。ただし、サイクルの回数は成果物の複雑さによって変動するため、終了基準を明確に定義しておくことが重要です。

• 人事評価の観点はフェーズに応じて更新が必要: 前回の記事で定義した 5 観点の評価基準に「批判的思考力」と「戦略フェーズへの貢献度」の 2 観点を追加したところ、これらの新規観点で低スコアのエージェントが複数検出されました（例: @cloud-operations の戦略フェーズ貢献度が 2/5）。CAF のフェーズごとに評価基準を拡張していくアプローチが効果的です。

• CCoE エージェントのオーケストレーター機能は不可欠: 複数のエージェントが並行して成果物を作成する場合、全体の整合性を確保する調整役が必要です。CCoE エージェントがこの役割を果たすことで、成果物間の矛盾や用語の不統一を防ぐことができました。

今後の展望

戦略フェーズが完了したので、次は CAF の後続フェーズを順次エージェントで実施していく予定です。

特に次回の 計画フェーズ では、今回作成した戦略ドキュメントを入力として、具体的な導入計画と移行対象のワークロード選定を行う予定です。戦略フェーズの成果物が後続フェーズの品質にどう影響するかも検証のポイントです。

注意点

• エージェントの成果物は人間のレビューが必須です: 無人実行はドラフト作成の自動化であり、最終的な意思決定は人間が行うべきです。特に組織の戦略に関わる内容は、ステークホルダーのレビューと承認を経てから確定してください。
• Devil’s Advocate の指摘が常に正しいとは限りません: 批判的な視点は重要ですが、Devil’s Advocate が指摘したすべての項目を採用する必要はありません。ビジネス判断として許容できるリスクもあるため、指摘の取捨選択は人間が行ってください。
• ガードレールは完璧ではありません: 4 層ガードレール設計はリスクを大幅に低減しますが、完全に排除するものではありません。無人実行の結果は必ず人間が確認してください。
• CAF は定期的に更新されます: Microsoft のドキュメントは継続的に更新されるため、エージェントの .agent.md ファイルも定期的に最新の CAF ガイダンスを反映する必要があります。

参考

• NakayamaKento/caf-agents - GitHub（本記事で使用したエージェントのリポジトリ）
• Azure CAF の組織論に基づいたエージェントを作成し隊（第 1 回: エージェント作成）
• カスタムエージェントのフォーマットを整え隊（第 2 回: フォーマット整備）
• 戦略方法論 - Cloud Adoption Framework | Microsoft Learn
• クラウド導入戦略を評価する - Cloud Adoption Framework | Microsoft Learn
• 動機、ミッション、目標を定義する - Cloud Adoption Framework | Microsoft Learn
• 戦略チームを定義する - Cloud Adoption Framework | Microsoft Learn
• 組織を準備する - Cloud Adoption Framework | Microsoft Learn
• 戦略を通知する - Cloud Adoption Framework | Microsoft Learn
• GitHub Copilot in the CLI - GitHub Docs
• Model Context Protocol