新しい Copilot Studio が GA したので「ハーネス」とクレジット課金体系を改めて整理してみる

Last updated at 2026-08-05Posted at 2026-08-03

※本記事は 2026/8 時点の公開情報（Copilot Studio 公式ブログ、Microsoft Learn、Copilot Credits Guide 2026年8月版）をベースに整理しています。今後変更される可能性があるため、契約や導入判断の際は必ず最新の公式情報をご確認ください。

はじめに

2026 年 8 月 3 日、これまでプレビューで提供されていた新しい Copilot Studio が一般提供（GA）となりました。あわせて「GitHub Copilot ハーネス」という新しい名称と、Copilot クレジットによる従量課金体系が正式に発表されています。

以前以下の記事で新しい UI やワークフローを試してきましたが、GA にあわせて用語とライセンス体系が大きく整理されたため、本記事で改めて全体像をまとめたいと思います。

特に今回は、これまで多くの企業が前提としてきた「Microsoft 365 Copilot ライセンスの使用権（fair use）の範囲内で使えるのか」という点と、「作成段階から課金されるのか」という点について、公開情報を確認しながら整理します。この 2 点は、これから新しい Copilot Studio の検証を始める方が最初に押さえておくべきポイントと考えます。

そもそも「ハーネス」とは？

今回の発表で急に登場した「ハーネス」という言葉、正直、最初に聞いてもピンとこない方が多いと思います。まずはこの言葉を整理します。

公式の定義

Copilot Credits Guide（2026年8月版）では、ハーネスは以下のように定義されています。

エージェントが計画し、推論し、コンテキストを維持し、ツールやシステムや他のエージェントと連携してタスクを完了するための「ソフトウェアの足場（scaffolding）」

個人的なイメージ

これだけだとまだ分かりにくいと思うので、個人的には以下のように捉えています。

生成 AI のモデル（LLM）は、それ単体では「テキストなどを出力する」ことしかできません。メールを送ることも、SharePoint を検索することもできず、実際にはモデルが「このツールをこう使いたい」というテキストを出力し、それを受け取った周囲の仕組みが実行しています。さらに言うと、モデル自体は呼び出しのたびに何も覚えていない状態（ステートレス）で、会話の文脈や処理の途中経過を毎回まとめてモデルに渡し直す役割も、モデルの外側の仕組みが担っています。

そこで、モデルの周りに「出力されたテキストを実際の処理に変換し、その結果をモデルに返して、次の判断をさせる」仕組みが必要になります。この仕組み一式がハーネスです。

例えるなら、モデルがエンジンで、ハーネスは車体です。同じエンジンでも、車体の設計（計画の立て方、ツールの呼び出し方、結果の確認の仕方、処理ループの回し方）が違えば、走りはまったく変わります。ハーネスという言葉自体、もともとは「馬具」という意味なので、「モデルという馬に馬具を付けて、業務という荷車を引かせる」とイメージしていただいてもいいかと思います。

これまでの「オーケストレーション」との関係

「それって今まで生成オーケストレーションと呼んでいたものでは？」と思った方もいると思います。ここは階層が少し違う、という認識です。ただ、今後はあまり用語として使われなくなるかもしれないと思っています。

オーケストレーター。どのツールやナレッジをどう組み合わせるかを判断する「頭脳」の部分
ハーネス。その判断を実行に移すループや土台の一式。オーケストレーターはこの上に乗っている

Microsoft の発表でも「新しいオーケストレーターは、新しいコーディングハーネスと CLI レイヤーの上に構築されている」という説明がされています。

用語変更についての所感

ここからは完全に個人的な所感です。

正直なところ、この用語の出し方は Copilot の延長線上で Copilot Studio にチャレンジする人や市民開発者にとってあまり優しくないと感じています。「生成オーケストレーション」という言葉も、決して分かりやすい言葉ではありませんでしたが、、、

Copilot Studio の本当の価値は、作り方の知識がなくても「何の業務プロセスを AI エージェントに任せるか」を考えられる人が主役になれることだと考えています。実際、新しい UI によって、これまで必要だった Power Virtual Agents 時代からの知識やトピックの構成スキルといった技術的な敷居は下がり始めています。これは非常に望ましい変化です。

だからこそ、その入り口で主に開発者に浸透している用語を前面に出すのは、恐らくマーケティング的な側面があるのだと思いますが、個人的には、敷居が高く感じる人も出る言葉遣いだと感じています。

個人的には、Copilot の延長や市民開発の延長で Copilot Studio を利用する人にとって、ハーネスという言葉を覚えること自体は、それほど重要ではないと考えています。重要なのは、やはり、マネージメントの延長で、問いを立てることや、どの業務を AI エージェントに任せるのか考え、業務の言語化、分解化を行う、必要に応じて業務プロセス自体を見直すことだと考えています。

また、次のセクションで説明する「どの作り方を選ぶと、何ができて、どう課金されるか」ということも知っておく必要があります。どの程度課金されるかを知っておくことは、それでも人がこの業務をやるよりよいのかという判断材料になると思います。

本記事でも、用語はここまでの説明に留めて、以降は判断に必要な情報に絞ります。

3 つのハーネスと新旧 Copilot Studio の対応

Copilot Studio は現在、3 つのハーネスをサポートしています。公式ガイドの整理は以下の通りです。今回の発表に伴い、従来の Copilot Studio についても、Standard ハーネス、Copilot Chat ハーネスと定義されました。ほとんどのケースでは、Standard ハーネスを使っていたという認識です。一旦、対比のためにそのように再定義されたとお考えください。

ハーネス	位置づけ	公式の例
GitHub Copilot ハーネス	エージェンティックな作成体験で業務プロセス全体を最適化	請求書を読み取り、発注書と突合し、例外を承認ルートに回す買掛金エージェント
Standard ハーネス	トピックとフローによるルールベースの会話型エージェント。現在の大半のエージェントが該当	PC 申請を承認・手配ワークフローに流す IT オンボーディングエージェント
Copilot Chat ハーネス	組織のナレッジで Microsoft 365 Copilot をカスタマイズ	SharePoint のコンテンツから回答する社員向け FAQ エージェント

新旧の UI との対応は、シンプルに以下の認識で良いと思います。

新しい Copilot Studio（新 UI、ホームの「Try now」から入る体験）で作るエージェントやワークフローは、GitHub Copilot ハーネスで動く
従来の Copilot Studio（クラシック）で作るエージェントは、Standard ハーネスまたは Copilot Chat ハーネスで動く

重要なのは、既存のハーネス (従来の Copilot Studio のことで昨日まではハーネスと呼んでいなかったですが) は廃止ではなく共存という点です。公式ブログでも、Copilot Chat / Standard ハーネスは既存エージェントも新規作成も継続サポートと明言されています。既存のエージェントが勝手に新しいハーネスに切り替わることもありません。「置き換え」ではなく「シナリオに応じて選ぶ選択肢が増えた」というのが正確な理解です。

なお、公式ドキュメントに明記されている注意点として、新しいエクスペリエンスで作成したエージェントをクラシックに変換することも、クラシックで作成したエージェントを新しいエクスペリエンスに変換することもできません。作成時にどちらの体験で作るかを選ぶ形であり、後から行き来はできない認識です。

ライセンス体系。どこでお金がかかるのか

ここからが本題です。結論から書くと、以下の 1 行に集約されます。

GitHub Copilot ハーネスのエージェントは、Microsoft 365 Copilot ライセンスの有無に関係なく、すべての利用が Copilot クレジットによる従量課金です。

これまで Standard ハーネスのエージェントでは、Microsoft 365 Copilot ライセンスを持つユーザーが社内（認証済み B2E）シナリオで使う分には使用権（fair use）に含まれる、という整理でした。この整理は Standard / Copilot Chat ハーネスでは今後も継続しますが、GitHub Copilot ハーネスは最初から対象外です。ここが今回の最大の変更点であり、Microsoft 365 Copilot ライセンス前提で展開を計画してきた企業にとって、コスト設計の前提が変わるポイントと考えます。

課金は 3 つの段階で整理できる

GitHub Copilot ハーネスの課金は「作成」「テスト・評価」「実行」の 3 段階で整理すると分かりやすいです。新しい UI は Build / Preview / Evaluate / Monitor の 4 タブで構成されているため、実際の画面と課金の対応を先に示しておきます。

個人的に、「作成」「テスト・評価」の段階でも課金が発生することは、かなりインパクトがあると感じており、IT 管理者側からすると意図せずクレジットが大量に消費されないよう対策が必要になると考えます。

新 UI のタブ	役割	クレジット消費
Build	指示文、ナレッジ、ツール、スキル、モデルの構成	手動構成は無料。自然言語で AI に作らせる場合のみ消費
Preview	プレビューチャットでの対話テスト	消費する（実行と同等）
Evaluate	テストセットの作成と実行による品質評価	消費する（実行と同等）
Monitor	タスク、アクセスしたファイル、アクティビティの確認	無料

数値はすべて Copilot Credits Guide 2026年8月版に記載の公式目安です（1 クレジット = 0.01 ドル）。

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

新しい Copilot Studio では、自然言語でエージェント自体の作成も依頼することができます。

ただし、手動での構成にはクレジットは一切かからないです。Build タブや Monitor タブでの作業を含め、手で設定する分は無償と明記されています。

課金されるのは、自然言語で AI にエージェントやワークフローを作らせる場合です。消費量は 1 回の作成セッション中に自分が送ったメッセージ数（conversation-turn）で見積もります。

シナリオ	ターン数	推定クレジット	円換算の目安（1ドル150円）
Light	1〜2 ターン	1〜20	約 2〜30 円
Medium	3〜5 ターン	21〜60	約 32〜90 円
Heavy	6 ターン以上	61〜	約 92 円〜

Light の例は「メールを要約するエージェントを作って」といった一発指示、Heavy の例は委任先エージェントやツールの入出力定義、メモリの有効化まで含む本格的な設計指示です。

正直、この作成段階の課金は想定よりずっと軽いと感じました。もっとも重い Heavy でも 1 セッション 100 円前後からのオーダーです。「作成段階から課金される」という点を過度に心配する必要はない、というのが個人的な結論です。

【段階 2】プレビューとテスト、評価（Evaluation）

ここが注意ポイントです。プレビューでのテスト会話と評価（Evaluation）の実行は、次の「実行」と同等のクレジットを消費します。つまり、テストは「作成の一部だから安い」のではなく「本番実行と同じコスト」です。

検証でテスト実行を繰り返すと、作成よりもこちらの方がコストの中心になります。たとえば Light 相当のテストを 50 回実行すると、5,000〜15,000 クレジット（50〜150 ドル）です。検証プロジェクトの予算は、作成費ではなくテスト実行回数で見積もるのが良いと考えます。

【段階 3】実行（公開、展開後の実行）

公開後の実行時の消費は、モデル、ランタイム、コンテキスト、ツールの 4 要素で決まります。公式のシナリオ別目安は以下です。

シナリオ	特徴	推定クレジット	円換算の目安（1回あたり）
Light	少数ソース、軽い推論、成果物 1 つ以下	100〜300	約 150〜450 円
Medium	多数ソース、構造化された推論、成果物 2 つ以上	300〜500	約 450〜750 円
Heavy	広範なソース集約、深い推論、多数の成果物	500〜	約 750 円〜

公式の例では、Light は「日次運用メールを確認してステータス要約をチャネルに投稿」、Heavy は「複数年分のコンプライアンス監査を行い、報告書を作成して SharePoint、Teams、メールで配布」といった粒度です。

この単価感から見えてくるのは、Microsoft が意図している使い分けです。1 回 150〜450 円という単価は、人がやれば 15〜30 分かかる仕事なら十分見合いますが、数十秒で終わる FAQ 応答に使うと明らかに割高です。つまり、会話型で高頻度、1 回あたりが軽い用途は引き続き Standard / Copilot Chat ハーネス（Microsoft 365 Copilot の使用権の範囲）、低頻度でも 1 回あたりの業務価値が高い自律プロセスは GitHub Copilot ハーネス、という役割分担が価格からも読み取れます。

クレジットが尽きるとどうなるか

環境に割り当てられたクレジットを使い切ると、クレジットを必要とする機能はすべて停止します。エンドユーザーへのエージェントの応答が止まるだけでなく、作成者側の自然言語オーサリング、プレビュー、評価も使えなくなります。業務停止を避けるための一定の超過猶予はありますが、対処は「既存容量の再割り当て」「追加購入」「従量課金（Pay-as-you-go）メーターの設定」の 3 択です。

個人的には、本番運用する環境には保険として Pay-as-you-go メーターをあらかじめ設定しておく運用が実質必須になるかもしれないと考えています。

クレジットの購入方法。事前購入でもいいのか、Azure サブスクリプションは必須なのか

「従量課金」と聞くと Azure サブスクリプションが必須に思えますが、購入方法は複数あり、事前購入型も選択できます。整理すると以下の通りです。

購入方法	内容	Azure サブスクリプション	特徴
Pay-as-you-go メーター	1 クレジット = 0.01 ドルで月末後払い	必要（Power Platform 管理センターで環境に請求プランを紐づけ）	コミット不要。超過時の保険としても機能
Copilot Studio ライセンス（クレジット容量パック）	月 200 ドルで 25,000 クレジット。サブスクリプション購入	不要	月次で失効（繰り越しなし）。実質単価は割安
Copilot Credit Pre-Purchase Plan（P3）	年間前払いのクレジットプール。規模に応じ 5〜20% 割引	必要（Azure ポータルの Reservation として購入）	年次で失効。MACC の消化対象
Microsoft Agent Pre-Purchase Plan（ACU）	Copilot Studio と Microsoft Foundry を横断して消化できる年間前払い	必要（同上）	プラットフォームをまたぐ企業向け

つまり、ご質問の「事前購入クレジットでもいいのか」への答えは Yes です。クレジットはテナントレベルでプールされ、どの購入方法で入手したものでも環境に割り当てて消費できます。Azure サブスクリプションが必須になるのは、Pay-as-you-go メーターと Pre-Purchase Plan（Azure の Reservation 扱い）を使う場合で、クレジット容量パックのサブスクリプション購入だけであれば Azure サブスクリプションなしでも始められる、という認識です。

※購入経路まわりは組織の契約形態（EA / CSP 等）によって選択肢が変わるため、実際の調達時は最新の Copilot Studio ライセンスガイドとアカウントチームへの確認をおすすめします。

月次コストの概算モデル

最後に、お客様への説明で使える簡単な概算式を載せておきます。

月次クレジット消費 ≒
  （1 日の実行回数 × シナリオ別クレジット × 稼働日数）
  ＋ 検証・改修期間のテスト実行分（実行と同単価）
  ＋ 自然言語オーサリング分（1 セッション 1〜60 クレジット程度）

たとえば、Medium シナリオのエージェントを 1 日 20 回、月 20 営業日実行する場合、300〜500 クレジット × 20 回 × 20 日 = 月 12〜20 万クレジット（1,200〜2,000 ドル）です。この金額を「同じ業務を人が行った場合の工数」と比較する形にすると、投資判断の材料として提示しやすいと思います。

まとめ

今回は、GA した新しい Copilot Studo（GitHub Copilot ハーネス）について、ハーネスという用語の意味と、クレジット課金体系を整理しました。要点は以下です。

ハーネスは「モデルを実際に働かせるための足場」。利用者は言葉自体より「どの作り方を選ぶと、何ができて、どう課金されるか」を押さえれば十分
新 UI = GitHub Copilot ハーネス、従来 UI = Standard / Copilot Chat ハーネス。既存ハーネスは廃止ではなく共存
GitHub Copilot ハーネスは Microsoft 365 Copilot ライセンスの使用権の対象外。すべてクレジット従量課金
手動構成は無料。自然言語での作成は 1 セッション数円〜100 円程度と軽い。コストの中心はテスト・評価と実行（1 回 150 円〜）
クレジットは事前購入型（容量パック、P3）でも従量型（Pay-as-you-go）でも購入可能。本番環境には超過時の保険として Pay-as-you-go メーターの併用を推奨

個人的には、課金体系そのものは、公式の目安が具体的に示されたことで、当初懸念していたよりも見積もりを立てやすいものになったと感じています。一方で、Microsoft 365 Copilot ライセンス前提で計画してきた企業にとっては前提が変わる話でもあるため、まずは検証環境にクレジットの上限を割り当てたうえで、テスト実行回数を管理しながらスモールスタートするのが良いかと思います。

本記事が、新しい Copilot Studio の導入やコスト設計を検討されている方のお役に立てば幸いです。

参考資料（公式情報）

本記事で参照した公式情報は以下の通りです。いずれも 2026/8 時点の内容です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up