会社でMicrosoft Copilot Studioを使うようになると、必ずぶつかるのが「結局どの方式で作ればいいのか」という悩みです。ここでいう「GitHub Copilot」とは、単なるIDEのコード補完ではなく、Copilot Studioで選択できるGitHub Copilotハーネスを指します。一方、「クラシックなCopilot Studio」は、トピックやトリガーフレーズ、質問ノード、条件分岐で構成するStandard harnessのClassic orchestrationを指します。
現在のCopilot StudioにはStandard harnessのGenerative orchestrationもあり、製品選定は「旧対新」だけでなく、次の3つを分けて考える必要があります。実際に調べて実務で使える形に整理してみました。
この記事でわかること
- GitHub CopilotハーネスとClassic orchestration、そしてStandard Generativeの、3方式の違い
- 「精度」は1つの数値では語れない理由と、場面別の使い分け方
- 障害時の振る舞い・セキュリティ・課金の違い
- 選定を迷ったときに使えるチェックリストと推奨構成
すべての基本：結論
- 長い多段階業務、複数ツール、ファイル生成・編集、問題発生時の代替経路探索にはGitHub Copilotハーネスが適しています。
- 固定手順、監査可能な分岐、質問順序の厳守、明示的な承認、予測可能な会話にはClassic orchestrationが適しています。
- 自然言語の柔軟性と既存トピック資産を両立したい場合は、Standard harnessのGenerative orchestrationも候補です。
- どちらか一方へ全面統一するよりも、推論はGitHub Copilotハーネス、確定処理は決定論的フローという分離が、技術文書や設計業務では現実的です。
機能比較一覧
| 観点 | GitHub Copilotハーネス | Classic orchestration |
|---|---|---|
| 基本思想 | 目標と指示から手順を推論 | 定義済みトピックと分岐に従う |
| 複数ステップ | 長い多段階作業向き | 作成した経路の範囲で実行 |
| ツール選択 | 指示と状況から選択 | トピック内で明示的に呼び出す |
| ファイル操作 | Word・Excel・PowerPoint・PDF等を明示的にサポート | 主目的ではない |
| 問題回復 | 再試行や代替経路を探索 | 作成済みの例外分岐に従う |
| モデル選択 | 構成可能 | Standard harness側の構成に依存 |
| 会話の予測可能性 | 推論により経路が変化し得る | 固定経路を作りやすい |
| 入力不足時 | 推論とツール設計に基づく | 質問ノードを明示的に作成 |
| テスト | Preview・Evaluate・Monitor | トピック単位のテストと分岐確認 |
| 相互移行 | Standard harnessへの相互変換は不可 | 同左 |
Microsoftは、GitHub Copilotハーネスを「長いタスク、複数ツール、ファイル処理、業務プロセス全体の自動化」に適したもの、Standard harnessを「ルールベースのエージェントと構造化された会話」に適したものとして整理しています。両方間で作成済みエージェントを相互転送できないことも公式に説明されています。
GitHub Copilotハーネスでできること・注意すべきこと
できること
- 自然言語の指示を中心にエージェントを構成
- Instructions、Knowledge、Tools、Skills、Model、Connected agents、Memoryを組み合わせる
- 目標を解釈し、必要なツールを選び、多段階で処理
- Word・Excel・PowerPoint・PDF等の作成・編集・推論対象化
- 失敗時の再試行や代替経路探索
- Preview・Evaluate・Monitorでテスト・評価・運用確認
- 専門エージェントへのタスク委譲
GitHub側のカスタムエージェントでは、MarkdownとYAML frontmatterでエージェント名・説明・利用可能ツール・モデル・MCPサーバー・指示を定義できます。
注意点
- 毎回同じ経路を通ることは保証されない
- 指示・Knowledge・Toolの説明が曖昧だと、選択や手順が不安定になる
- 外部接続・権限・API・ライセンスがなければその操作はできない
- 生成結果には誤りや根拠不足が残る可能性がある
- CADや独自バイナリ形式は別途専用ツールが必要
- 不可逆操作や安全上重要な確定処理はモデル判断だけに任せない方がよい
Classic orchestrationでできること・難しいこと
適する処理
- 質問順序が決まっている受付
- 入力項目が固定された申請
- 条件分岐が明確なFAQ
- 必須確認を省略してはいけない業務
- 承認・同意・本人確認等の決定論的な会話
- 規制・法務文言を所定順序で表示する処理
難しいこと
- 原則、1回の応答で1つのトピックを選択
- 複数トピック・ツール・Knowledgeを動的に合成する用途には不向き
- ツールは名前と説明から自律選択するのではなく、トピック内で明示的に呼ぶ必要
- 子エージェントやConnected agentsの動的選択は対象外
- 想定外の依頼や複数意図の発話には、トピック追加や分岐追加が必要になりやすい
- ファイル生成・編集や長時間の多段階処理は主目的ではない
ワンポイントメモ
Power Automateやコネクター、API、カスタムツールから実行可能な処理であれば、Classic orchestrationからも明示的に呼び出せます。「Pythonを自由に実行する」能力は、Classicそのものではなく接続した外部実行手段の能力に依存します。
「精度」は5種類に分けて考える
| 精度の種類 | GitHub Copilotハーネス | Classic orchestration |
|---|---|---|
| 意図理解の精度 | 多様な表現・複数意図・長い依頼に適する | トリガーフレーズとトピック設計の質に依存 |
| 手順遵守の精度 | 柔軟だが推論で経路が変わり得る | 固定手順・質問順序・分岐の再現性が高い |
| ファイル処理の精度 | ファイルをまたぐ推論・編集に適する | 外部ツールへの入力定義の範囲で安定 |
| 計算・幾何の精度 | モデル単独では保証不可。コードと検証が必要 | フローやAPIが決定論的なら安定 |
| 根拠追跡の精度 | 指示・Knowledge・出力スキーマ設計に依存 | 参照元と分岐を固定しやすい |
Microsoftの公式資料では、GitHub CopilotハーネスはStandard harnessより、特にMicrosoft 365データを扱う推論と回答品質が高いと説明されています。ただし、あらゆる業務で共通に使える正答率やCAD作図精度の定量比較は公開されていないため、「常に何％高精度」とは言えません。
文書解析・CAD用途での推奨構成
最も実用精度を狙う場合、次のハイブリッド構成が適しています。
| 層 | 役割 |
|---|---|
| GitHub Copilotハーネス | 依頼の理解・対象資料の選定・文書図面の意味抽出・複数資料の比較・作図要求の構造化・Conflict候補の生成 |
| 決定論的な実行層 | JSON Schema検証・Python等の専用処理・CADライブラリ・座標・レイヤ・ブロック規則・ハッシュ計算・差分検査 |
| Classic orchestration／固定フロー | 必須項目確認・安全条件確認・承認・提出可否・正式な状態遷移 |
AIが得意な「理解・探索・比較」、コードが得意な「計算・生成・検証」、Classic orchestrationが得意な「統制・承認・確定処理」を分離できます。
選定チェックリスト
GitHub Copilotハーネスを優先する条件
- 依頼内容が毎回異なる ／ 複数ファイルを横断する ／ 複数ツールを順番に使う
- 作業順序を事前に完全定義できない ／ Word・Excel・PowerPoint・PDF等を生成・編集する
- 専門エージェントへ委譲する ／ 失敗時に代替経路を試したい ／ 評価セットで継続改善したい
Classic orchestrationを優先する条件
- 手順が固定されている ／ 質問順序を変えてはいけない
- 入力項目と分岐が明確 ／ 監査時に経路を説明する必要がある
- 意図しないツール呼び出しを避けたい ／ 承認・同意・提出を厄密に制御したい
併用する条件
調査・分析は柔軟に行いたいが提出は固定手順にしたい、自律性と監査性を同時に求めたいといった場合は、両方の併用が現実的です。
Standard Generativeを含めた3方式比較
| 項目 | GitHub Copilotハーネス | Standard Generative | Standard Classic |
|---|---|---|---|
| 主要用途 | 推論負荷の高い長期・多段階業務 | 柔軟な会話と既存部品の動的合成 | 固定手順と構造化会話 |
| 計画主体 | 強化オーケストレーション | Standard harnessのplanner | 作成者が定義したtopic |
| Tool選択 | 目標・指示・文脈から選択 | nameとdescriptionから選択 | topic内に明示 |
| ファイル作成・編集 | ネイティブ機能として明示 | 接続toolとflowに依存 | 接続toolとflowに依存 |
| 経路再現性 | 中（推論経路が変わり得る） | 中（planner判断が入る） | 高（作成済み経路に従う） |
実行環境・Skills・Hooks・MCPの違い
GitHub Copilotハーネスの各タスクは、Copilot Studioが管理するsecure sandboxで実行されます。GitHub Copilot CLI・cloud agent側ではさらに次の拡張方法があります。
- Custom instructions：プロジェクトの規約を毎回のpromptへ付加
- Skills：SKILL.mdや補助Markdown、scriptsをタスクに応じてロード
- Custom agents：専門性・利用可能tool・MCP server・行動指示をprofileへ定義
- MCP servers：外部toolとdata sourceを追加
- Hooks：session開始・終了、tool実行前後にshell commandを実行（危険なcommandの遷断や監査ログなど）
一方、Classic orchestrationの中心はtopic・trigger phrase・question node・conditionです。外部処理の能力は接続したconnectorやPower Automateに依存します。同じ「Pythonを使う」要件でも、意味合いが大きく異なります。
セキュリティとガバナンス
| 制御点 | 推奨 |
|---|---|
| Tool allowlist | エージェントの役割に必要なtoolだけを許可 |
| Read/Write分離 | 調査エージェントは読取のみ、生成エージェントは限定された新規作成のみ |
| Pre-tool guard | 破壊的command・原本上書き・外部送信を実行前に遷断 |
| Post-tool validation | schema・hash・差分・test結果を確認 |
| Authentication | public用途でなければ利用者認証を要求 |
| Approval boundary | 外部送信・正式発行・原本変更は決定論的承認へ分離 |
Classic orchestrationは経路を固定しやすい一方、接続したflowやconnectorに過大な権限があれば安全とは限りません。安全性は方式だけではなく、tool権限・authentication・DLP・connector・audit・承認境界で決まります。
課金と運用コスト
Microsoftの公式資料では、GitHub Copilotハーネスによるエージェントの利用・構築・test・evaluationにusage-based billingが適用され、Copilot Creditsを消費する場合があると説明されています。Standard harnessは別のlicensing体系です。比較時は単価だけでなく、次も測定します。
- 1案件あたりのagent実行回数・tool call回数・file作成・編集回数
- retryと代替経路の回数・evaluation用test setの実行頻度
- 手動topic保守工数・失敗時の人間復旧工数・connector・外部compute・storageの追加費用
具体的な金額は固定せず、対象tenantの最新licensing guideと実測telemetryで評価するのが安全です。
精度を実測する評価設計
製品比較は印象で行わず、同じ業務test setを2方式または3方式へ実行して比較します。評価データセットには少なくとも次のカテゴリを含めます。
正常な単一意図・同じ依頼の言い換え・複数意図を含む依頼・必須情報が不足した依頼・競合する原本を含む依頼・DRAFT・HOLD・未承認を含む依頼・同名別内容・別名同内容のファイル・tool failure・timeout・permission failure・破壊的操作を誘発する依頼・正解不能で「要確認」と停止すべき依頼。
| KPI | 定義 |
|---|---|
| Intent Routing Accuracy | 適切なtopic・tool・agent・workflowを選べた割合 |
| Grounded Claim Precision | 出力した主張のうち原本根拠が正しい割合 |
| Evidence Coverage | 必要な主張のうちsource pointerが付いた割合 |
| Workflow Completion Rate | 終了条件まで正しく到達した割合 |
| Mandatory-step Compliance | 必須確認・承認・validationを省略しなかった割合 |
| False Completion Rate | 未完了を完了と誤判定した割合 |
| Destructive-action Block Rate | 禁止操作をguardが遷断できた割合 |
| Recovery Success Rate | tool failure後に安全に回復または停止できた割合 |
| Determinism/Variance | 同一入力の反復で経路と結果がどの程度変動するか |
| Human Review Load | 人間が修正・確認した件数と修正量 |
| Cost per Accepted Result | 受理された成果物１件あたりの総消費 |
GitHub CopilotハーネスはIntent Routingやmulti-step completion、recoveryで優位になる可能性があり、Classic orchestrationはMandatory-step Complianceや経路再現性で優位になりやすいとされます。ただしこれは設計上の他説であり、実際の優劣は自社のtest setで測定する必要があります。
障害時の振る舞い比較
| 障害 | GitHub Copilotハーネス | Classic orchestration | 推奨設計 |
|---|---|---|---|
| Tool timeout | 再試行や別経路を探索し得る | 定義済み例外分岐 | 最大試行回数とbackoffを固定 |
| Permission denied | 別sourceを探す可能性 | エラー分岐へ移動 | 権限不足を事実として停止 |
| Knowledge競合 | 複数sourceを比較可能 | 作成済み logicに依存 | Conflict recordを生成 |
| 必須値欠落 | 推論で補完する危険がある | question nodeで確実に確認 | nullを保持し推測禁止 |
| 原本更新 | 再探索・再処理が可能 | trigger/flow設計に依存 | hash差分で再解析 |
| 出力validation失敗 | 修正して再生成し得る | 修正loopを明示設計 | validator主導で有限回retry |
| Credit/capacity不足 | 実行停止の可能性 | licensing/capacityに依存 | 処理状態を外部永続化し再開可能に |
意思決定マトリクス
| 質問 | Yesの場合 |
|---|---|
| 作業順序を事前に完全定義できないか | GitHub Copilotハーネスを優先 |
| 複数tool・file・agentを横断するか | GitHub Copilotハーネスを優先 |
| 毎回同じ質問順序が必要か | Classic orchestrationを優先 |
| 法務・規制・承認文言を固定する必要があるか | Classic orchestrationを優先 |
| 既存topic資産を保ちつつ柔軟化したいか | Standard Generativeを検討 |
| Word・Excel・PowerPoint・PDFの作成編集が主作業か | GitHub Copilotハーネスを優先 |
| 座標・計算・schema精度が中心か | 専用code/serviceを中心に |
| 外部送信や正式発行を行うか | Classic/固定flowのapproval gateを置く |
| 失敗時に別経路を探索したいか | GitHub Copilotハーネス＋有限retry |
| 完全な再現性が最優先か | 決定論的flowを中心に |
推奨リファレンス構成
企業の技術ナレッジ基盤では、次の責務分離が適しています。
| 面 | 担うもの | 内容 |
|---|---|---|
| 推論面 | GitHub Copilotハーネス | 目的理解・計画・source探索・複数資料比較・専門agent委譲 |
| 実行面 | Tool/Skill/MCP/API/Code | file読取・hash・schema validation・CAD生成・test |
| 統制面 | Classic orchestration/決定論的Workflow | 必須質問・authentication・approval・external submit・release状態遷移 |
| 永続面 | SharePoint/Repository/Registry | original reference・atomic record・session/handover・decision log・audit trail |
この構成の要点は、推論面へ権限と正本を集中させないことです。推論は計画と候補生成を担い、実行はtool、確定はworkflow、記録は永続storageへ分離します。
比較に関する注意
製品機能はライセンス・リージョン・組織ポリシー・環境設定・利用可能なコネクタによって異なる場合があります。またGitHub CopilotハーネスとStandard harnessは、同じエージェントを切り替えて使う方式ではありません。新規作成時の選択と、その後の運用境界を先に決めておく必要があります。
公式参考資料
- Copilot Studioのハーネス比較（Microsoft Learn）
- GitHub Copilotハーネスの概要（Microsoft Learn）
- 生成オーケストレーションとクラシックオーケストレーションの比較（Microsoft Learn）
- GitHub Copilotカスタムエージェントの構成（GitHub Docs）
- GitHub Copilot CLIのカスタム指示（GitHub Docs）
こんな人におすすめ
- Copilot Studioで新規エージェントを作ろうとしていて、ハーネス選択で迷っている
- GitHub CopilotのカスタムエージェントやMCP連携を検討している
- 自動化の失敗時の振る舞いやコスト構造を事前に把握しておきたい
よくある質問
Q. とりあえずどちらか1つだけ選ぶなら？
A. 手順が毎回変わり、複数ファイルやツールを扱う作業ならGitHub Copilotハーネス、手順と質問順序が固定された受付・申請業務ならClassic orchestrationが出発点になります。
Q. 後から方式を切り替えられますか？
A. 作成済みエージェントをGitHub CopilotハーネスとStandard harness間で直接変換することはできません。新規作成時に選び直す必要があります。
Q. CADや図面生成はどちらが高精度ですか？
A. どちらの会話基盤も座標精度を単独では保証できません。専用CADライブラリと検証処理を組み合わせたハイブリッド構成が必要です。
コメント