GitHub Copilotハーネス vs Copilot Studio Classic　実務での選び方を彻底比較

記事内に広告が含まれています。

会社で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」の違い

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

本記事の中心は最初の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で検証します。

3方式の機能比較

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

適している業務

• 依頼ごとに必要な手順が変わる
• 複数の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へ集約すると保守が難しくなる場合がある

GitHub Copilot CLIのSkills、Hooks、MCPと区別する

GitHub Copilot harnessという名称から、GitHub.comやGitHub Copilot CLIのすべての拡張機能がCopilot Studioでも同じように利用できると誤解しやすいため、分けて考える必要があります。

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です。

「精度」は一つの数値では比較できない

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へ保存します。

障害時の振る舞い

代替経路探索にも境界が必要

代替経路を自動で探せることは利点ですが、Permission deniedの回避として別の権限境界や未承認Sourceへ移動してはいけません。

代替経路は、事前に許可したTool、Source、Storage boundaryの範囲内に限定します。

SecurityとGovernance

重要なのは、「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から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

GitHub Copilot harnessがIntent routing、長いTask、File処理、Recoveryで優位になる可能性や、Classic orchestrationが必須Stepの再現性で優位になる可能性は、Architecture上の仮説です。

本番での優劣は、自社Data、自社Connector、自社権限、自社の失敗条件を含むTest setで確認します。

意思決定Matrix

推奨Reference Architecture

要点は、推論面へ正本、全権限、正式状態を集中させないことです。

推論面は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設定を確認してください。