記事内に広告が含まれています。
会社でMicrosoft Copilot Studioを使い始めると、必ずぶつかるのが「結局、どの方式でAgentを作ればよいのか」という問題です。
現在のCopilot Studioでは、GitHub Copilot harness、Standard harness、Copilot chat harnessという複数のRuntime architectureが使われています。
さらにStandard harnessでは、Generative orchestrationとClassic orchestrationを選択できます。
そのため、単純に「新しいGitHub Copilot方式」と「従来のClassic方式」を比較するだけでは、現在の製品構成を正確に表せません。
この記事では、Copilot Studioで業務Agentを構築する際に実質的な選択肢となる、次の3方式を中心に整理します。
- GitHub Copilot harness
- Standard harness＋Generative orchestration
- Standard harness＋Classic orchestration
また、Microsoft 365 Copilot Chatを組織Knowledgeで拡張するCopilot chat harnessについても、別の利用目的を持つHarnessとして位置付けます。
この記事でわかること
- HarnessとOrchestrationの違い
- Copilot Studioで選択できる3種類のHarness
- GitHub Copilot harness、Standard Generative、Standard Classicの違い
- 「精度」を一つの正答率だけで比較できない理由
- 障害時の振る舞い、Security、課金方式の違い
- GitHub Copilot CLI側のSkills、Hooks、MCPとの区別
- 技術文書、図面、CAD、Microsoft 365 File操作の推奨構成
- 自社Test setを使った選定方法
この記事でいう「GitHub Copilot」について
本記事の主な比較対象は、IDEのCode completionやGitHub上のCoding agentではなく、Copilot Studioで新規Agent作成時に選択できるGitHub Copilot harnessです。
GitHub Copilot CLI、GitHub.comのCustom agent、Agent Skills、Hooks、MCP Serverにも関連する考え方がありますが、それらとCopilot StudioのGitHub Copilot harnessは同一のAuthoring surfaceではありません。
- 最初に理解するべき「Harness」と「Orchestration」の違い
- Copilot Studioにある3種類のHarness
- 最初に結論
- 3方式の機能比較
- GitHub Copilot harnessとは
- Standard Generativeとは
- Standard Classicとは
- GitHub Copilot CLIのSkills、Hooks、MCPと区別する
- Computer useとの関係
- 「精度」は一つの数値では比較できない
- Context管理の違い
- 障害時の振る舞い
- SecurityとGovernance
- 課金と運用コスト
- 技術文書・図面・CAD用途での推奨構成
- 現時点の代替運用
- 精度を実測するTest設計
- 意思決定Matrix
- 推奨Reference Architecture
- よくある選定ミス
- 公式参考資料
- こんな人におすすめ
- よくある質問
- まとめ
最初に理解するべき「Harness」と「Orchestration」の違い
Harnessとは
Harnessは、AgentやWorkflowとAI Modelの間で動作するRuntimeです。
どの時点でModelを呼び出すか、どのContextやComponentを渡すか、Modelの応答をどのように解釈するか、どのToolを実行するかなどを制御します。
Copilot Studioで選択するHarnessは、次の範囲へ影響します。
- Agentの作成方法
- 利用できるComponent
- ToolやAgentのOrchestration
- Fileの作成と編集
- MemoryやSkills
- Contextの扱い
- 実行環境
- 課金方式
Orchestrationとは
Orchestrationは、HarnessがTopic、Tool、Knowledge、他のAgentなどを、どのように選択して実行するかという制御方式です。
Standard harnessでは、次の2方式を選択できます。
- Generative orchestration：LLM-based plannerがTopic、Tool、Knowledge、他のAgent等を選択し、複数StepのPlanを構成する
- Classic orchestration：主にTrigger phraseでTopicを選択し、Topic内に作成済みのNodeと分岐に沿って処理する
つまり、Standard GenerativeとStandard Classicは別Harnessではなく、同じStandard harness内のOrchestration方式の違いです。
Copilot Studioにある3種類のHarness
| Harness | 主な目的 | 主な利用場面 |
|---|---|---|
| GitHub Copilot harness | 推論負荷が高い複雑な多段階業務 | 複数Tool、複数File、Connected agent、長い業務Process |
| Standard harness | 構造化されたAgent、Topic、Agent flow、反復可能な会話 | GenerativeまたはClassic orchestrationを使う業務Agent |
| Copilot chat harness | Microsoft 365 Copilot Chatを組織Knowledgeで拡張 | SharePoint等のKnowledgeを使った社内向け回答 |
本記事の中心は最初の2種類です。Copilot chat harnessは、Microsoft 365 Copilot Chatから利用するKnowledge中心のAgentに適しており、長い業務Processや構造化された受付処理を作る場合とは選定目的が異なります。
最初に結論
- 複雑な目標、複数Tool、複数File、Connected agent、途中結果を含む長い業務には、GitHub Copilot harnessが第一候補です。
- 柔軟な自然言語入力と、既存のTopic、Tool、Knowledge、Agent flowを組み合わせたい場合は、Standard Generativeが候補です。
- 質問順序、Message、分岐、必須確認を作成者が明示的に固定したい場合は、Standard Classicが候補です。
- Microsoft 365 Copilot Chatへ組織Knowledgeを追加することが主目的なら、Copilot chat harnessを検討します。
- 座標、計算、Schema、Hash、CAD生成、正式状態遷移は、どのHarnessでもModel単独へ任せず、決定論的なToolやWorkflowで検証します。
Harness選定だけで安全性は決まらない
Classic orchestrationは経路を固定しやすいですが、呼び出すFlowやConnectorに過大な権限があれば安全とはいえません。
反対に、GitHub Copilot harnessでも、Toolの権限、Approval、Schema validation、Source verification、Result Packageを適切に設計すれば、重要操作の境界を強化できます。
3方式の機能比較
| 観点 | GitHub Copilot harness | Standard Generative | Standard Classic |
|---|---|---|---|
| 基本思想 | 目標を解釈し、Stepへ分解して進める | Plannerが既存Componentを動的に組み合わせる | 作成済みTopicとNodeに従う |
| Agent作成 | 自然言語を中心に、Instructions、Knowledge、Tool等を構成 | Topic、Tool、Knowledge、Agent等を構成 | Trigger phrase、Question、Message、Condition等を明示作成 |
| Topic選択 | 標準Topic中心のAuthoringではない | TopicのPurpose description等から選択 | Trigger phraseとの一致で選択 |
| Tool選択 | 目標、Instructions、Context等から選択 | Name、Description、Input、Output等から選択 | Topic内から明示的に呼び出す |
| 複数Component | 複数Tool、Knowledge、MCP、Connected agentを横断 | 複数Topic、Tool、Knowledge、AgentをPlanへ組み込める | 原則として1つのTopicを選び、その中で処理 |
| 不足入力 | InstructionsとTool contractに基づいて確認 | 必要なInputを埋める質問を生成できる | Question nodeを明示的に作成 |
| 応答生成 | Orchestration layerが利用結果から応答 | 利用したComponentの結果から応答を生成 | Message nodeまたはTool結果を使って応答 |
| File対応 | Word、Excel、PowerPoint、PDFの作成、編集、推論を明示的にサポート | 接続したToolやFlowに依存 | 接続したToolやFlowに依存 |
| Skills | 再利用可能な構造化Behaviorとして利用 | 同名のGitHub型Skillが中心機能とは限らない | 同左 |
| Memory | 構成可能。Preview機能を含む | Standard harness側のConversation context等を利用 | Variable、Conversation、外部Storage等で明示管理 |
| Connected agent | 専門Agentへ委譲できる | Description等に基づいて選択できる | 動的選択の対象外 |
| 問題回復 | 再試行や代替経路を探索できる | PlannerとTool設計に基づいて再構成し得る | 作成済みError branchに従う |
| 経路再現性 | 目標とContextにより経路が変化し得る | Planner判断により変化し得る | 作成済み経路を再現しやすい |
| 主なTest | Preview、Evaluate、Monitor | Test panel、Analytics、Topic／Tool単位の確認 | Topic trace、Variable、分岐確認 |
| 課金 | Copilot Creditsを使うUsage-based billing | Standard harnessのLicensing体系 | Standard harnessのLicensing体系 |
| Harness間移行 | Standard harnessへ直接Transfer不可 | GitHub Copilot harnessへ直接Transfer不可 | 同左 |
GitHub Copilot harnessとは
GitHub Copilot harnessは、Copilot Studioで複雑な業務Processを構築するための、自然言語中心のAuthoringおよびRuntime環境です。
固定されたConversation flowだけを作成するのではなく、目標、Instructions、Knowledge、Tools、Skills、Connected agents、Memoryを組み合わせてAgentの役割と境界を定義します。
主なComponent
- Instructions：Identity、Tone、Scope、Behavior、Boundaryを定義
- Knowledge：回答や判断に利用するData source
- Tools：API、Connector、Flow等のAction
- Skills：再利用可能な構造化Behavior
- Model：ReasoningとGenerationを行うModel
- Connected agents：専門Taskを別Agentへ委譲
- Memory：InteractionのDetailを将来のContextへ活用
Authoring surface
| Tab | 用途 |
|---|---|
| Build | Instructions、Knowledge、Tools、Skills、Model、Memory等を構成 |
| Preview | Chat形式でAgentを対話的にTest |
| Evaluate | Test setを作成し品質を測定 |
| Monitor | 最近のTask、File access、Activity等を確認 |
適している業務
- 依頼ごとに必要な手順が変わる
- 複数のMicrosoft 365 Fileを比較する
- 複数Toolを途中結果に応じて使い分ける
- Word、Excel、PowerPoint、PDFを作成または編集する
- 長い業務ProcessをEnd-to-endで処理する
- 専門AgentへTaskを委譲する
- 失敗時に別の経路を試す
- Test setを使って継続評価する
注意点
- 同じ依頼でも、Contextや中間結果により実行経路が変わる可能性がある
- InstructionsやTool descriptionが曖昧だと、Tool選択や停止判断が不安定になる
- Toolに必要な権限や接続がなければ操作できない
- File対応があることと、内容が常に正しいことは別である
- 外部送信、正式発行、原本変更はApproval boundaryを分離する
- CADや独自Binary形式には専用Toolまたは変換処理が必要
- Memoryを業務正本、Decision Log、Audit Logの代わりにしない
Standard Generativeとは
Standard Generativeは、Standard harness上でLLM-driven plannerを使うOrchestration方式です。
既存のTopic、Tool、Knowledge source、Child agent、Connected agent、Event trigger等を、User intentやComponent descriptionに基づいて組み合わせます。
Standard Generativeの強み
- 既存のTopicやToolを再利用しながら柔軟な自然言語入力へ対応できる
- 複数Intentを含む依頼を扱える
- 必要なTopic、Tool、Knowledgeを複数選択できる
- 不足するInputを埋めるための質問を生成できる
- Topic inventoryの重複やTrigger phrase設計を減らせる場合がある
- Event triggerからPlanを開始する構成にも利用できる
Standard Generativeの注意点
- Plannerが選択しやすいName、Description、Input、Outputの設計が必要
- 同じUser inputでもConversation historyにより選択が変わる場合がある
- ToolやFlowは、同じInputに対して安定した結果を返すように設計する必要がある
- Standard harnessではContextがComponent間へ分散するため、InputとOutputを明示的に返さないとContext gapが発生する場合がある
- WordやExcel等のFile作成・編集は、HarnessのNative機能ではなくToolやFlowに依存する
Standard Classicとは
Standard Classicは、Trigger phraseで選ばれたTopic内に、Question、Message、Condition、Variable、Tool call等を作成する方式です。
適している処理
- 質問順序が決まっている受付
- 入力項目が固定された申請
- 条件分岐が明確なFAQ
- 必須確認を省略できない処理
- 承認、同意、本人確認を明示する会話
- 所定の文言を所定順序で提示する処理
- 特定条件で必ず停止するWorkflow
制約
- 原則としてUser inputに一致する一つのTopicを選択する
- 複数TopicやToolをPlannerが動的に合成する用途には向かない
- ToolはTopic内から明示的に呼び出す
- 必要な質問はQuestion nodeとして作成する
- 応答はMessage nodeまたはTool結果として作成する
- 想定外の依頼にはTopicや分岐の追加が必要になりやすい
- 長い多段階Taskを一つのConversationへ集約すると保守が難しくなる場合がある
Classicでも外部処理は実行できる
Power Automate、Connector、API、Desktop flow、Custom toolから実行できる処理であれば、Classic Topicから明示的に呼び出せます。
ただし、Python、CAD、Browser automation等の能力はClassic orchestration自体の能力ではなく、接続した実行手段の能力です。
GitHub Copilot CLIのSkills、Hooks、MCPと区別する
GitHub Copilot harnessという名称から、GitHub.comやGitHub Copilot CLIのすべての拡張機能がCopilot Studioでも同じように利用できると誤解しやすいため、分けて考える必要があります。
| 仕組み | 主な環境 | 役割 |
|---|---|---|
| Copilot Studio GitHub Copilot harness | Copilot Studio | AgentのAuthoring、Orchestration、Tool、Skill、Memory、File処理 |
| GitHub Copilot Custom agents | GitHub Copilot対応環境 | MarkdownとYAML frontmatter等で専門Agentを定義 |
| GitHub Copilot Agent Skills | GitHub Copilot対応環境 | SKILL.mdと補助Resourceで再利用手順を定義 |
| GitHub Copilot Hooks | 対応するGitHub Copilot agent／CLI環境 | SessionやTool実行前後にCommandを実行 |
| MCP Server | 対応ClientおよびAgent runtime | 外部ToolやData sourceをProtocol経由で提供 |
Copilot StudioのGitHub Copilot harnessがSkillsとMCPをサポートすることは公式に説明されています。
一方、GitHub Copilot CLIのHook fileやCustom agent profileを、そのままCopilot StudioのGitHub Copilot harnessへ配置すれば同じBehaviorになるとは限りません。対象HarnessのAuthoring surfaceと公式Documentationで利用可能なComponentを確認します。
Computer useとの関係
Computer useは、Web siteやWindows applicationを仮想MouseとKeyboardで操作するCopilot StudioのToolです。
2026年9月10日時点のMicrosoft Learnでは、Computer useはStandard harness向けの機能として説明されていますが、利用できるのはGenerative orchestrationが有効なAgentです。
| 方式 | PC GUI操作の考え方 |
|---|---|
| GitHub Copilot harness | 利用可能なTool、Skill、MCP、接続環境の範囲で構成 |
| Standard Generative | Computer use Toolを選択できる構成が可能 |
| Standard Classic | Computer use Toolの直接利用条件には合わない。TopicからPower AutomateやDesktop flow等の別経路を明示呼び出し |
「精度」は一つの数値では比較できない
| 評価軸 | GitHub Copilot harness | Standard Generative | Standard Classic |
|---|---|---|---|
| Intent理解 | 複雑、長文、多段階の依頼に適する | 多様な表現と複数Intentを扱える | Trigger phraseとTopic設計に依存 |
| Tool routing | 複数ToolとAgentを横断できる | Description等からComponentを選択 | Topic内に固定 |
| 手順遵守 | 柔軟だが経路が変わり得る | Planner判断が入る | 質問順序と分岐を固定しやすい |
| File処理 | NativeなOffice／PDF File対応がある | 接続Toolの品質に依存 | 接続Toolの品質に依存 |
| 計算・Schema | 専用CodeとValidatorが必要 | 専用ToolとValidatorが必要 | 決定論的Flowに固定しやすい |
| Evidence追跡 | Source PointerとOutput Schemaの設計が必要 | Knowledge結果とComponent outputの返却設計が必要 | Sourceと分岐を固定しやすい |
| 再現性 | 同一InputでもContextや途中結果で変動し得る | Conversation historyやPlanner判断で変動し得る | 同一Topic内の経路を再現しやすい |
| 安全な停止 | InstructionsだけでなくTool側Guardが必要 | Policy、Tool、Approval、Guardが必要 | 明示分岐に加えてTool側Guardが必要 |
Microsoftは、GitHub Copilot harnessがStandard harnessと比較して、より深いReasoningと高品質な応答をサポートし、特にMicrosoft 365 Dataでその特徴があると説明しています。
ただし、すべての業務へ共通する正答率や、CAD座標精度、図面読取精度の定量的な差が示されているわけではありません。
したがって、「GitHub Copilot harnessは常に何％高精度」とは表現せず、自社のTest setでTask別に測定します。
Context管理の違い
Standard harnessでは、Orchestration layer、Topic、Knowledge、Child agent、Connected agent、Tool等へContextが分散します。
ToolやFlowが受け取るのは、基本的に明示されたInputです。Component内で利用者へ表示した内容や、内部Variableだけに保持した情報は、明示的なOutputとして返さない限り、上位Orchestration layerから利用できない場合があります。
このため、Standard Generativeで複数Componentを組み合わせる場合は、次をContractとして定義します。
- Componentへ渡すInput
- Componentが返すOutput
- 利用者へ表示しただけの情報をResultとしても返すか
- Error code
- Evidence
- Retry可否
- 次のComponentに渡す値
GitHub Copilot harnessではOrchestration layerが利用者とのCommunicationを一元化し、Connected agentの結果も親のAI layerを経由します。
ただし、Contextが大きいことと、業務正本、Decision、Lock、Auditが永続的に保証されることは別です。重要な状態は外部Storageへ保存します。
障害時の振る舞い
| 障害 | GitHub Copilot harness | Standard Generative | Standard Classic | 推奨する共通設計 |
|---|---|---|---|---|
| Tool timeout | 再試行や代替経路を探索し得る | Planを再構成し得る | 作成済みError branchに従う | 最大試行回数、Backoff、Idempotencyを固定 |
| Permission denied | 別Source探索を試みる可能性 | 別Componentを選ぶ可能性 | Error branchへ移動 | AccessDeniedをNotFoundとせず停止 |
| Knowledge競合 | 複数Sourceを比較できる | 複数Knowledgeを利用できる | 作成済みLogicに依存 | Conflict RecordとSource Pointerを生成 |
| 必須値欠落 | 質問または推論を行い得る | 不足Inputの質問を生成できる | Question nodeで確認 | 推測禁止Fieldはnullのまま停止 |
| 原本Version変更 | 再取得と再処理を設計可能 | TriggerとToolに依存 | TriggerとFlowに依存 | File ID、Version、ETag、HashでPre-state確認 |
| Validation失敗 | 修正して再生成し得る | 修正Stepを再Planし得る | Retry loopを明示作成 | Validator主導の有限Retry |
| Capacity／Credit不足 | 実行停止の可能性 | Standard側Capacityに依存 | 同左 | 状態を外部永続化し再開可能にする |
代替経路探索にも境界が必要
代替経路を自動で探せることは利点ですが、Permission deniedの回避として別の権限境界や未承認Sourceへ移動してはいけません。
代替経路は、事前に許可したTool、Source、Storage boundaryの範囲内に限定します。
SecurityとGovernance
| 制御点 | 推奨設計 |
|---|---|
| Tool allowlist | Agentの役割に必要なToolだけを追加 |
| Read／Write分離 | 調査AgentはRead only、生成Agentは限定された新規作成、更新Agentは対象を明示 |
| Input contract | 型、必須、許容値、最大Size、Source boundaryを定義 |
| Pre-state guard | Session、Claim、Lock、Version、ETag、Hashを確認 |
| Post-tool validation | 再読込、Schema、Hash、Diff、Test結果を確認 |
| Authentication | 匿名利用が必要でない限り利用者認証を要求 |
| DLP | ConnectorやEnvironment間のData移動をPolicyで制御 |
| Approval boundary | 外部送信、正式発行、原本変更、削除を明示承認へ分離 |
| Audit | PromptだけでなくTool Input、Result、Decision、Verificationを記録 |
| Recovery | 部分成功を検出し、RollbackまたはReconcile可能にする |
重要なのは、「AIへ禁止と指示した」ことではなく、禁止された操作がToolまたはWorkflowのGuardを通過できない構造にすることです。
課金と運用コスト
GitHub Copilot harnessでは、Agentの利用だけでなく、構築、Test、EvaluationにもUsage-based billingが適用され、操作によってCopilot Creditsを消費する場合があります。
Standard harnessは別のLicensing体系です。Copilot chat harnessは、ConsumptionまたはMicrosoft 365 CopilotのUser subscriptionに含まれる構成があります。
実際の比較では、Credit単価だけでなく、次を含めます。
- 受理された成果物1件あたりのAgent実行数
- Tool call数
- File作成と編集回数
- Retryと代替経路の回数
- Evaluation用Test setの実行頻度
- TopicとFlowの保守工数
- Human review工数
- 失敗時のRecovery工数
- Connector、External compute、Storageの費用
- MonitoringとAuditの運用費用
価格、Credit消費、License条件は変更される可能性があるため、記事内で固定金額を断定せず、対象Tenantの最新Licensing guideとTelemetryで評価します。
技術文書・図面・CAD用途での推奨構成
| 層 | 候補 | 役割 |
|---|---|---|
| 理解・計画 | GitHub Copilot harnessまたはStandard Generative | 依頼の理解、Source候補選定、複数資料比較、Task分解 |
| 観測・抽出 | OCR、Parser、Vision、Document tool | Text、Table、Symbol、Metadata、Source Pointerの取得 |
| 決定論的処理 | Python、API、CAD Library、Custom service | 座標、計算、Hash、Schema、Geometry、File変換 |
| 統制 | Classic Topic、Power Automate、Approval workflow | 必須質問、承認、提出可否、正式状態遷移 |
| 永続化 | SharePoint、Dataverse、Repository、Registry | 原本、Atomic Record、Decision、Session、System Links、Audit |
| 検証 | Validator、Test suite、人間Review | Schema、Diff、Evidence、禁止操作、成果物品質の確認 |
この構成は、GitHub Copilot harnessからClassic Topicを一つの内部Stepとして直接呼び出せることを前提としていません。
別HarnessのAgentやWorkflowを組み合わせる場合は、明示的なTool、API、File Package、Queue、Event、Result Package、人間によるHandoff等の接続境界を設計します。
現時点の代替運用
GitHub Copilotで行っていたPython解析や成果物生成を、Standard ClassicのAgent単体へ移すことはできません。
一方、Copilot ChatにはPython解析とFile生成に使える実行環境があり、ClassicエージェントはMicrosoft 365上のFile取得、Metadata確認、実体検証、許可された操作に利用できます。
そのため、GitHub Copilot harnessを直ちに本番採用できない環境では、次の構成が暫定的な代替になります。
Copilot Chat → 入力CopyをPython解析 → 成果物と長文Instruction fileを生成 → OneDriveの受渡し領域へ保存 Human-controlled handoff → 短縮起動文をClassicエージェントへ転送 → 書込みや破壊的操作を明示承認 Classic Agent → Instruction fileを完全一致で取得 → File ID、Size、ETag、Hash、本文末尾を確認 → 許可されたMicrosoft 365操作を実行 → Result Packageを返却 Copilot Chat → Result Packageを再解析 → Succeeded、Failed、Blocked、Inconclusiveを判定 → 次のTaskを決定
この方式では、作業用Folderを正式なMemoryの正本にせず、Decision Log、Open Threads、System Links、Ledger Event等を別に管理します。
精度を実測するTest設計
方式選定は印象で行わず、同じTest setを各候補へ実行して比較します。
Test caseに含める条件
- 正常な単一Intent
- 同じ依頼の言い換え
- 複数Intentを含む依頼
- 必須情報が不足した依頼
- 競合する原本を含む依頼
- Draft、Hold、未承認を含む依頼
- 同名で内容が異なるFile
- 別名で内容が同一のFile
- Tool timeout
- Permission denied
- 出力Schema違反
- 破壊的操作を誘発する依頼
- 正解不能で停止すべき依頼
- 途中まで成功して後段が失敗する依頼
主要KPI
| KPI | 定義 |
|---|---|
| Intent Routing Accuracy | 適切なTopic、Tool、Agent、Workflowを選択した割合 |
| Grounded Claim Precision | 出力したClaimのうちSourceが正しい割合 |
| Evidence Coverage | 必要なClaimのうちSource Pointerが付いた割合 |
| Workflow Completion Rate | 定義した終了条件まで正しく到達した割合 |
| Mandatory-step Compliance | 必須確認、Approval、Validationを省略しなかった割合 |
| False Completion Rate | 未完了を完了と誤判定した割合 |
| Destructive-action Block Rate | 禁止操作をGuardが遮断した割合 |
| Recovery Success Rate | 障害後に安全に回復または停止した割合 |
| Conflict Preservation Rate | 競合を一方へ上書きせず保持した割合 |
| Determinism／Variance | 同一Inputを繰り返した際の経路と結果の変動 |
| Human Review Load | 人間の確認件数、修正件数、修正量 |
| Cost per Accepted Result | 受理された成果物1件あたりの総消費 |
GitHub Copilot harnessがIntent routing、長いTask、File処理、Recoveryで優位になる可能性や、Classic orchestrationが必須Stepの再現性で優位になる可能性は、Architecture上の仮説です。
本番での優劣は、自社Data、自社Connector、自社権限、自社の失敗条件を含むTest setで確認します。
意思決定Matrix
| 質問 | Yesの場合の候補 |
|---|---|
| 作業順序を事前に完全定義できないか | GitHub Copilot harness |
| 複数Tool、File、Agentを横断するか | GitHub Copilot harness |
| NativeなOffice／PDF File処理が中心か | GitHub Copilot harness |
| 既存Topic資産を活用しながら柔軟化したいか | Standard Generative |
| 複数IntentをStandard componentで処理したいか | Standard Generative |
| Computer use Toolを使用したいか | Standard Generativeを検討 |
| 質問順序を固定する必要があるか | Standard Classic |
| 所定のMessageと明示分岐が必要か | Standard Classic |
| 外部送信や正式発行を行うか | 決定論的Approval workflowを追加 |
| 座標、計算、Schema精度が中心か | 専用CodeまたはServiceを中心にする |
| Microsoft 365 Copilot ChatへKnowledgeを追加したいだけか | Copilot chat harness |
| 完全な再現性が最優先か | 決定論的Workflowを中心にする |
推奨Reference Architecture
| 面 | 担うもの | 内容 |
|---|---|---|
| 推論面 | GitHub Copilot harnessまたはStandard Generative | 目的理解、計画、Source探索、比較、候補生成 |
| 実行面 | Tool、Skill、MCP、API、Code、Flow | File読取、生成、変換、Hash、CAD処理、Test |
| 統制面 | Classic Topic、Approval、決定論的Workflow | 必須質問、Authentication、Approval、Release状態遷移 |
| 永続面 | SharePoint、Dataverse、Repository、Registry | 原本、Atomic Record、Session、Decision、System Links、Audit |
| 検証面 | Schema Validator、Test suite、人間Review | Evidence、Diff、禁止操作、成果物の検査 |
要点は、推論面へ正本、全権限、正式状態を集中させないことです。
推論面はPlanとCandidateを生成し、実行面は許可されたActionを行い、統制面は承認と状態遷移を管理し、永続面が正本と履歴を保持します。
よくある選定ミス
1. GitHub Copilot harnessとGitHub Copilot CLIを同じものとして扱う
関連する技術や名称はありますが、Authoring surface、設定File、利用可能なComponentは同一ではありません。対象環境のDocumentationで確認します。
2. Standard harnessはすべて固定経路だと考える
Standard harnessにはGenerative orchestrationがあり、LLM-based plannerが複数のTopic、Tool、Knowledge、Agentを選択できます。
3. Generative orchestrationとGitHub Copilot harnessを同じものと考える
どちらも動的なPlanを構成できますが、Harness、Context、Native File処理、Skills、Memory、Authoring surface、課金が異なります。
4. Classicなら安全だと考える
経路を固定しやすくても、接続Toolに過大権限がある、Input validationがない、Error時に誤った状態を返す場合は安全ではありません。
5. GitHub Copilot harnessなら自動回復に任せてよいと考える
Retryや代替経路には、最大回数、許可Source、権限境界、Idempotency、停止条件が必要です。
6. Harness間を後からToggleで切り替えられると考える
GitHub Copilot harnessで作成したAgentとStandard harnessで作成したAgentは、直接Transferできません。別Agentとして再構築する前提で、Source、Tool contract、Schema、Evaluation setを再利用可能にします。
7. AgentのMemoryを業務記憶の正本にする
MemoryはAgent interactionのContextに利用できますが、Decision Log、Open Threads、Version、Lock、Auditの代わりにはしません。
公式参考資料
- Microsoft Learn：Copilot StudioのHarness比較
- Microsoft Learn：GitHub Copilot harness Agentの概要
- Microsoft Learn：Generative orchestrationとClassic orchestration
- Microsoft Learn：Standard harness AgentへのAccess
- Microsoft Learn：Standard harnessのContext分散
- Microsoft Learn：Computer use
- GitHub Docs：Custom agentの構成
- GitHub Docs：Agent Skills
- GitHub Docs：Hooks
こんな人におすすめ
- Copilot Studioで新規Agentを作ろうとしている
- GitHub Copilot harnessとStandard harnessのどちらを選ぶか迷っている
- Standard GenerativeとClassicの違いが分からない
- GitHub Copilot CLIのSkills、Hooks、MCPとの関係を整理したい
- 技術文書、図面、CAD、Microsoft 365 Fileを扱うAgentを検討している
- 自律性とApproval、Audit、再現性を両立したい
- 将来のHarness変更に備えて移行可能なArchitectureを作りたい
よくある質問
Q. とりあえず一つだけ選ぶなら、どれがよいですか？
A. 複数ToolやFileを使い、依頼ごとに手順が変わる長い業務ならGitHub Copilot harnessが候補です。
既存TopicやToolを活用しながら柔軟な自然言語入力へ対応したい場合はStandard Generative、質問順序と分岐を固定したい受付や申請ではStandard Classicが出発点になります。
Q. 後からHarnessを切り替えられますか？
A. GitHub Copilot harnessで作成したAgentをStandard harnessへ直接Transferすることはできず、その逆も同様です。
別Agentとして再構築する前提で、Instructions、Tool contract、Input／Output Schema、Test set、Source Pointerを製品固有設定から分離しておくと移行しやすくなります。
Q. Standard GenerativeからClassicへ戻せますか？
A. これはGitHub Copilot harnessとStandard harness間のTransferとは別の問題です。
同じStandard harness内の設定変更として扱える場合がありますが、Knowledge source、Topic、Tool、対応機能、既知の制限が異なるため、切替前に既存AgentのCompatibilityと回帰Testを確認する必要があります。
Q. CADや図面生成はどの方式が高精度ですか？
A. どのHarnessも、Model単独で座標、Layer、Block、Geometryの精度を保証しません。
Agentは要求理解、Source選択、候補生成を担当し、CAD Library、Python、専用API等が生成し、Schema、Geometry、差分、HashをValidatorで確認する構成が必要です。
Q. Classic orchestrationでPythonを実行できますか？
A. Classic orchestration自体に自由なPython実行環境があるという意味ではありません。
Pythonを実行するAPI、Flow、Service、Desktop環境等をToolとして接続できる場合に、そのToolをTopicから明示的に呼び出します。
Q. GitHub Copilot CLIのSKILL.mdをCopilot Studioでそのまま使えますか？
A. Copilot StudioのGitHub Copilot harnessはSkillsをサポートしますが、GitHub Copilot CLI側のDirectory構成や設定Fileを無条件にそのまま利用できるとは限りません。
対象HarnessのSkill authoring仕様、対応Resource、Deployment方法を確認して移植します。
Q. 推論はGitHub Copilot harness、承認はClassicという構成にできますか？
A. Architectureとして責務を分けることは可能です。ただし、異なるHarness間が自動的に一つの内部Conversationとして連結されるとは限りません。
Tool、API、Power Automate、Queue、Instruction Package、Result Package、人間Handoff等の明示的な接続境界を設計します。
まとめ
- HarnessはAgentとModelの間で動作するRuntimeである
- Copilot StudioにはGitHub Copilot、Standard、Copilot chatの3種類のHarnessがある
- Standard GenerativeとStandard Classicは、Standard harness内のOrchestration方式の違いである
- GitHub Copilot harnessは複雑な多段階業務、複数Tool、File処理に適する
- Standard Generativeは既存Componentと柔軟な自然言語入力を組み合わせる
- Standard Classicは質問順序、Message、分岐、必須確認を固定しやすい
- GitHub Copilot CLIのHooksやCustom agent設定をCopilot Studioと混同しない
- Computer useを直接利用するStandard AgentではGenerative orchestrationが必要
- 精度はIntent、Tool routing、Evidence、手順遵守、Recovery、Costに分けて測定する
- 推論、実行、統制、永続化、検証を別の責務として設計する
- Harness間の直接Transferはできないため、SchemaとTest setを製品非依存にする
- 重要な状態と記憶をConversationやMemoryだけへ置かない
選定で重要なのは、「最も新しい方式を選ぶこと」でも、「すべてを一つのHarnessへ統一すること」でもありません。
AIに任せる判断、Toolへ任せる処理、Workflowで固定する承認、Storageへ残す正本を分離し、それぞれに適したHarnessと実行方式を選ぶことです。
本記事の製品情報は2026年9月10日時点です。Harness、Preview機能、Memory、Skills、Computer use、課金、License、利用可能地域は変更される可能性があります。導入時には対象TenantでMicrosoft Learn、Licensing guide、Admin設定を確認してください。
コメント