新しいCopilot Studio｜GitHub Copilotハーネスは「作成段階から課金」の新体系に【2026年8月】

Microsoft Copilot Studioは、ノーコード・ローコードで業務用のAIエージェントを構築できるプラットフォームとして、2026年に入ってから急速に機能を拡張してきました。なかでも大きな転換点になったのが、2026年6月に本番運用可能なプレビューとして公開された、GitHub Copilotの推論エンジンをベースにした新しいエージェント実行基盤です。

2026年8月3日、これまでプレビューとして提供されていた新しいCopilot Studioが、正式に一般提供（GA）となりました。あわせて、「GitHub Copilotハーネス」という名称と、Copilotクレジットによる従量課金体系が公式に発表されました。これまで単に「Copilot Studio」と呼ばれてきた従来の作り方も、「標準ハーネス」「Copilot Chatハーネス」として明確に位置づけ直されています。

用語の整理だけであれば単なる呼称変更ですが、今回のGAで実務上とくに重要なのは、GitHub Copilotハーネスで作るエージェントの課金の仕組みが、従来のCopilot Studioとはまったく異なる設計になっている点です。本記事では、Microsoft公式ドキュメントに基づき、新しいCopilot Studioの全体像と、企業の担当者が導入前に押さえておくべき料金体系の変更点を整理します。

Contents

3つのハーネス
- ハーネスとは何か
- GitHub Copilotハーネス・標準ハーネス・Copilot Chatハーネスの違い
新しいCopilot Studioの体験：4つのタブで完結する設計
- Build／Preview／Evaluate／Monitorの役割
- 自然言語でエージェントを作る「オーサリング」
最大の変更点：Microsoft 365 Copilotライセンスの使用権が適用されない
- これまでの標準ハーネスとの違い
- 「作成段階から課金される」の意味
課金は3段階で発生する
クレジットが枯渇するとどうなるか
クレジットの購入方法
企業の担当者が押さえておくべきポイント
まとめ
参考サイト

3つのハーネス

ハーネスとは何か

Copilot Studioで何かを作るとき、裏側では必ず「ハーネス」と呼ばれる実行基盤（ランタイム）が動いています。公式ドキュメントでは、ハーネスは「モデルをいつ呼び出すか、どの部品をモデルに渡すか、返ってきた結果をどう解釈してどのツールを呼ぶかを制御する仕組み」と説明されています。AIモデル自体はテキストを出力するだけの存在であり、実際にメールを送ったりSharePointを検索したりする処理は、モデルの外側にあるこのハーネスが担っています。

GitHub Copilotハーネス・標準ハーネス・Copilot Chatハーネスの違い

Copilot Studioは現在、次の3種類のハーネスをサポートしています。

ハーネス	位置づけ	得意なこと
GitHub Copilotハーネス	複雑で多段階の業務プロセスに対応する、最も高機能な選択肢	目標を自ら分解して段階的に処理し、失敗時は代替手段を探して続行。Word・Excel・PowerPoint・PDFの作成編集、スキル、記憶（メモリ）に対応
標準ハーネス	あらかじめ定義したトピックやフローに沿って動くルールベースのエージェント	予測可能で一貫した応答が求められる場面。既存のプロンプトライブラリや社内ナレッジを活用しやすい
Copilot Chatハーネス	Microsoft 365 Copilot Chatを拡張するための基盤	社内のSharePointなどのナレッジに基づいた回答を、日常業務の中で提供

公式ドキュメントは、GitHub Copilotハーネスを「請求書を読み取り、発注書と突合し、例外を承認ルートに回す買掛金エージェント」のような、複数ツールをまたいだ自律的な業務プロセスに適した選択肢として例示しています。一方、標準ハーネスは「よくある質問に答え、簡単な依頼をワークフローに流す社内ヘルプデスク」のような、定型的で予測可能な用途に向くとされています。

なお、既存のハーネス（標準ハーネス・Copilot Chatハーネス）は廃止されるわけではなく、GitHub Copilotハーネスと共存します。新しいエクスペリエンスで作成したエージェントを標準ハーネスに変換すること、あるいはその逆はできず、エージェントの作成時にどちらの体験で作るかを選ぶ形になっています。

新しいCopilot Studioの体験：4つのタブで完結する設計

Build／Preview／Evaluate／Monitorの役割

GitHub Copilotハーネスで作るエージェントは、従来のような会話トピックやフロー、分岐ロジックを個別に組み立てる代わりに、自然言語でエージェントの目的や振る舞いを説明すると、システムがその内容を設定に落とし込む仕組みになっています。作成・管理の画面は、次の4つのタブで構成されています。

Build：エージェントの指示（identity・トーン・範囲）、ナレッジ、ツールとスキル、使用するAIモデル、他エージェントとの連携、メモリを設定する
Preview：プレビューのチャット画面で、対話形式でエージェントの動作をテストする
Evaluate：テストセットを作成・実行し、エージェントの品質を測定する
Monitor：直近のタスクやアクセスしたファイル、アクティビティを確認する

Build・Preview・Evaluate・Monitorという一連の流れは、「作成→テスト→公開→監視」というエージェントのライフサイクルにそのまま対応しています。標準ハーネスでは、トピックやトリガー、会話フローの分岐を作り込むことでエージェントの挙動を決めていましたが、GitHub Copilotハーネスでは、その作り込みの手間を減らし、指示文と接続するリソースを定義することに集中できる設計へと変わっています。

自然言語でエージェントを作る「オーサリング」

新しいCopilot Studioでは、エージェントそのものの作成を自然言語の指示で依頼できるようになりました。たとえば「メールを要約するエージェントを作って」といった簡単な指示から、委任先エージェントの設計やツールの入出力定義、メモリの有効化まで含む本格的な指示まで、自然言語のやり取りを通じてエージェントを組み立てていくことができます。ただし、この便利さには次に説明する新しい課金の考え方が伴います。

最大の変更点：Microsoft 365 Copilotライセンスの使用権が適用されない

これまでの標準ハーネスとの違い

標準ハーネスのエージェントでは、Microsoft 365 Copilotライセンスを持つ社員が社内向けの認証済みシナリオで使う分には、ライセンスの使用権（フェアユース）に含まれる、という整理がされてきました。この考え方は標準ハーネス・Copilot Chatハーネスでは今後も続きますが、GitHub Copilotハーネスは対象外です。

GitHub Copilotハーネスで動くエージェントは、Microsoft 365 Copilotライセンスの使用権（フェアユース）の対象外です。作成・実行のすべてがCopilotクレジットの従量課金になります。公式ドキュメントは「LLMのトークン、ツール（ナレッジやMCPを含む）、ハーネス自体のすべてに対してCopilotクレジットが課金される」と明記しており、これらの要素を使う経験はすべてクレジットを消費すると説明しています。Microsoft 365 Copilotライセンスを前提に展開を計画してきた企業にとっては、コスト設計の前提が変わる、実務上インパクトの大きい変更点です。

「作成段階から課金される」の意味

標準ハーネスは公開後に課金が始まるのに対し、GitHub Copilotハーネスは「作成を始めた瞬間」からクレジットが消費されます。自然言語でのエージェント作成、プレビューでのテスト対話、評価（Evaluation）の実行も、すべて課金対象です。

課金は3段階で発生する

GitHub Copilotハーネスのクレジット消費は、「作成」「プレビュー・テスト・評価」「公開後の実行」という3つの段階に分けて理解すると整理しやすくなります。以下の目安は、Microsoft公式のCopilot Credits Guide（2026年8月版）に基づいてIT専門メディアが整理した情報です。実際の消費量はエージェントの設計や利用状況によって変動するため、契約や予算検討の際は必ず最新の公式情報をご確認ください。

段階1：作成（自然言語オーサリング）

手動でBuildタブの項目を設定する分にはクレジットは一切かかりません。課金が発生するのは、自然言語でAIにエージェントやワークフローを作らせた場合のみです。消費量は、作成セッション中に送ったメッセージ数（会話のターン数）に応じて見積もられ、「メールを要約するエージェントを作って」のような一言の指示であれば数円〜数十円程度、委任先エージェントやツールの入出力定義まで含む本格的な指示でも、1セッションあたり100円前後からのオーダーとされています。

段階2：プレビュー・テスト・評価

ここが見落とされやすいポイントです。プレビュー画面でのテスト対話や、Evaluateタブでのテストセット実行は、後述する「公開後の実行」と同等のクレジットを消費します。つまりテストは「作成の一部だから安い」のではなく、「本番実行と同じコストがかかる」という前提で検証計画を立てる必要があります。検証段階でテスト実行を繰り返すほど、コストの中心は作成費用ではなくテスト実行の回数に移っていきます。

段階3：公開後の実行

公開後の実行時に消費されるクレジット量は、使用するAIモデル、ランタイム、コンテキストの量、呼び出すツールの4つの要素によって決まります。少数の情報源で軽い推論を行い成果物が1つ以下の「Light」なタスクから、複数年分の監査を行い報告書を作成して複数チャネルに配布するような「Heavy」なタスクまで、複雑さに応じてクレジット消費量には幅があります。1回あたりの単価感からは、高頻度・低負荷な会話型の用途は引き続き標準ハーネス／Copilot Chatハーネスで、低頻度でも1回あたりの業務価値が高い自律的な処理はGitHub Copilotハーネスで、という役割分担をMicrosoftが想定していることがうかがえます。

クレジットが枯渇するとどうなるか

環境に割り当てられたCopilotクレジットを使い切ると、クレジットを必要とするすべての機能が停止します。公式ドキュメントによれば、エンドユーザーへのエージェントの応答が止まるだけでなく、作成者側の自然言語オーサリング、プレビュー、評価の生成・実行もすべて利用できなくなります。業務への影響を避けるため一定の超過利用（オーバーエイジ）は許容されますが、それを超えた場合の対処は、既存容量の再割り当て、追加購入、従量課金（Pay-as-you-go）メーターの設定のいずれかになります。本番環境で運用する場合は、あらかじめPay-as-you-goメーターを保険として設定しておく運用が実質的に必須になりそうです。

クレジットの購入方法

「従量課金」と聞くとAzureサブスクリプションが必須に思われがちですが、購入方法は複数用意されており、事前購入型も選択できます。Copilotクレジットはテナントレベルでプールされ、どの購入方法で入手したクレジットも環境に割り当てて消費できる仕組みです。管理はPower Platform管理センターで行い、管理者が環境にクレジットを割り当て、使用状況を監視します。クレジットの割り当てが必要な場合は、まず自社の管理者に確認するのが現実的な進め方になります。

企業の担当者が押さえておくべきポイント

今回のGAが持つ実務上の意味は、大きく2つに整理できます。ひとつは、Entra Agent IDの必須化など、Copilot Studio全体でエージェントのガバナンス強化が進むなかで、GitHub Copilotハーネスは機能面で最も自由度が高い選択肢として位置づけられたことです。もうひとつは、その自由度と引き換えに、Microsoft 365 Copilotライセンスの使用権に含まれない、独立した従量課金の対象になったことです。

すでにMicrosoft 365 Copilotライセンスを全社に展開している企業であっても、GitHub Copilotハーネスを使った高度なエージェントを検討する場合は、別枠でのクレジット予算確保が必要になります。特に、検証段階のテスト実行が本番実行と同じ単価で課金される点は、PoC（概念実証）の予算を見積もる際に見落としやすいポイントです。まずは検証用の環境にクレジットの上限を設定したうえで、テスト実行回数を管理しながらスモールスタートする進め方が現実的でしょう。

まとめ

2026年8月3日、Copilot Studioの新しいエージェント作成体験が「GitHub Copilotハーネス」として正式にGAしました。自然言語でのエージェント作成、Word・Excel・PowerPoint・PDFのネイティブな操作、スキルやメモリへの対応など、機能面では標準ハーネスを大きく上回る一方、Microsoft 365 Copilotライセンスの使用権は適用されず、作成・テスト・実行のすべてがCopilotクレジットの従量課金になる点が最大の変更点です。既存の標準ハーネス・Copilot Chatハーネスは廃止されず併存するため、既存エージェントをすぐに作り直す必要はありません。まずは自社のユースケースが、定型的な会話型業務なのか、それとも複数ツールをまたぐ自律的な業務プロセスなのかを見極めたうえで、後者についてはクレジット予算を確保しながら検証を進めることをおすすめします。