2026/09/14Copilot

料金・コスト比較非エンジニア向けAI活用

Copilot Coworkのコスト管理｜上限と使用量の確認方法

Copilot Coworkのコスト管理で最初につまずくのは、「クレジットの上限を決めておけば安心」という思い込みです。管理者からは「実際にいくらかかるのか読めない」「上限を超えたら即座に止まるのか」という相談をよく受けます。

結論から言うと、クレジット上限は支出の安全弁であって、リアルタイムの遮断装置ではありません。クレジットの消費と上限の適用は非同期に評価されるため、上限に達した後でも、その適用が効くまでの間にタスクが動いてしまうことがあります。だからこそ、上限の数値を決めて終わりにするのではなく、何がクレジットを消費するのかを理解したうえで、管理画面で日々の消費を確認し続ける運用が必要になります。

株式会社Fyveでも中小企業のAI活用を支援する中で、「上限は決めたのに使用量が読めない」という相談を扱ってきました。この記事では、Copilot Coworkの料金プランそのものではなく、運用に入ってからの監視と制御に絞って整理します。2026年9月15日時点の情報です。Copilot CoworkはGAから3か月で仕様が動いているため、契約・設定の前に最新のMicrosoft Learn公式ドキュメントでご確認ください。

Copilot Coworkは「使った分だけ」課金される

まず前提を押さえておきます。Copilot Coworkは、決まった月額に含まれる機能ではありません。Microsoft Learnの逐語です。

Copilot Cowork requires the Microsoft 365 Copilot User Subscription License (USL).
（訳：Copilot Coworkには、Microsoft 365 Copilotのユーザーサブスクリプションライセンス（USL）が必要です）

Users are then billed for Cowork on a usage-based basis, with charges determined by the tasks they run.
（訳：ユーザーは、実行したタスクに応じて決まる使用量ベースでCoworkの課金を受けます）

課金の単位はCopilot Creditsです。対象になるのはCowork本体だけでなく、Coworkで作ったアプリ、Work IQ APIも含まれます。また、Coworkは既定ではオフになっています（Cowork is off by default.）。管理者が有効化しない限り、勝手に課金が発生することはありません。

なお、Copilot BusinessのプランページではCoworkがMetered（従量制）と案内されており、Copilot Businessでも利用できることは読み取れます。ただし「USLが必要」という逐語との対応関係を、公式が一文で明示しているわけではないため、契約前に公式の価格ページでご自身のプランを確認することをおすすめします。

この「使った分だけ」という課金方式は、通常の月額固定のCopilotライセンスとは別会計になる、という点が実務上いちばん見落とされやすいポイントです。「Copilotのライセンス費用を払っているのだから、Coworkも追加費用なく使える」と誤解したまま有効化してしまうと、想定していなかった請求が発生することになります。有効化の前に、この記事でこのあと説明する消費要因と確認手段をセットで押さえておくことをおすすめします。

何がクレジットを消費するのか

コストをコントロールする第一歩は、何が消費を増減させるのかを知ることです。Microsoft Learnは、クレジット消費の増減要因を次のように説明しています。

model use, context retrieval, tool calls, and runtime
（訳：モデルの利用、文脈の取得、ツールの呼び出し、実行時間）

この4つが、同じ「1つのタスク」でもクレジット消費が大きく変わる理由です。具体的に消費する活動としては、次のようなものが挙げられています。

モデルの応答（チャットでのやり取りそのもの）
ツール・スキルの呼び出し（組み込みスキルやカスタムスキルの実行）
画像生成
ブラウザタスク（Web上での操作を伴うタスク）

この4つは、それぞれ性質が異なります。モデルの応答は文脈が長くなるほど消費が伸びやすく、ツール・スキルの呼び出しは1つのタスクの中で何回呼ばれるかがそのまま積み上がります。画像生成は単発の処理ですが、ブラウザタスクはWebページの読み込みや操作の往復が発生する分、他の活動より実行時間が長くなりやすい傾向があります。「同じ1タスク」という見た目でも、中身によってクレジットの減り方はまったく違う、という前提で見ておく必要があります。

選べるモデルには複数の候補があり、モデルの選択自体も消費に影響する一因です。Microsoft Learnが列挙しているのはClaude Fable, Opus and Sonnet variants from Anthropic, the Sonnet+Opus Advisor pairing, GPT 5.5, and ChatGPT Images 2.0（訳：Anthropic社のClaude Fable・Opus・Sonnet系列、Sonnet＋Opusのアドバイザー構成、GPT 5.5、ChatGPT Images 2.0）です。Microsoftはこれを「複数モデルの強み」と呼び、タスクに応じて適したモデルを選ぶ設計だと説明しています。

ここで一つ誤解しやすい点を補足します。Copilot Coworkと、Anthropicが提供するClaude Coworkは別製品です。名前がよく似ていますが、Claude Coworkの技術がMicrosoft 365 Copilotに組み込まれているという関係であり、上に挙げたAnthropic製モデルが選択肢に入っているのもその一環です。製品としては別物、という前提で読み進めてください。

1クレジットの単価は公開されていない——見積は公式ツールで

「4要素で消費が決まる」と分かっても、1クレジットがいくらなのかが分からなければ予算は立てられません。ここは正直にお伝えします。2026年9月15日時点、Microsoftの公式価格ページには1クレジットあたりの単価は掲載されていません。検索で単価らしき数字が出てきても、一次情報として確認できない以上、この記事では書きません。

単価が公開されていないということは、「このタスクは何円かかったか」を都度、頭の中の単価表で計算することができない、ということでもあります。だからこそ、この記事で紹介するCost managementの画面で実際の消費量を確認する運用のほうが、単価を推測して予算を立てるより現実的です。導入を検討する段階では金額の見積もりが欲しくなりますが、運用に入ってからは「消費量そのもの」を追うほうに軸足を移す、という考え方に切り替えたほうがよいということです。

その代わり、Microsoftは見積のための公式ツールを複数用意しています。実際の予算感をつかみたい場合は、これらを使って試算することをおすすめします。

Copilot Credit Estimator：https://aka.ms/CopilotCreditPlanningModel
Cowork cost estimator：https://aka.ms/CustomerCoworkEstimator
Copilot Credits Licensing Guide：https://aka.ms/CopilotCredits/LicensingGuide

上限を設定しても、その瞬間には止まらない

ここがこの記事でいちばん伝えたいことです。クレジットの上限は「設定したら自動でブロックされる」ものだと考えている方が多いのですが、Microsoft Learnの説明はそれとは異なります。逐語です。

Credit limits are a spending safeguard, not a real-time access gate. Credit consumption and limit enforcement are evaluated asynchronously, so a user might be able to start one or more tasks after their limit is reached before enforcement takes effect.

（訳：クレジット上限は支出の安全弁であって、リアルタイムのアクセス遮断装置ではありません。クレジットの消費と上限の適用は非同期に評価されるため、上限に達した後であっても、その適用が効くまでの間に、ユーザーが1つ以上のタスクを開始できてしまうことがあります）

言い換えると、上限に達した瞬間にシステムが自動でブレーキを踏むわけではないということです。消費量の集計と、上限を超えたかどうかの判定処理は、リアルタイムで同期して動いているのではなく、少し遅れて（非同期に）評価されます。その遅れの間に、ユーザーがもう1つ、もしかしたら複数のタスクを開始できてしまう可能性があります。

この仕組みを知らずに「上限を¥◯◯円相当に設定したから、それ以上は絶対に使われない」という前提で予算計画を立てると、想定より超過するタスクが発生したときに説明がつかなくなります。上限は「使いすぎを大きく外れないための安全弁」であって、「1円単位で切るスイッチ」ではない、と理解しておく必要があります。

実務への影響が大きいのは、スケジュール実行やイベント駆動タスクのように、人が操作していない場面です。担当者がチャット画面を見ながら使っているタスクなら、上限超過の兆候に気づく余地がありますが、自動で動くタスクは、上限に近づいていることに誰も気づかないまま非同期の判定を待つことになります。上限の数値だけを決めて放置するのではなく、後述するCost managementの画面を定期的に見に行く運用とセットにして、はじめて「安全弁」として機能します。

では非同期評価という前提を、運用でどう補えばよいのでしょうか。この記事のこのあとで説明する3つの仕組みが、そのまま補い方になります。ひとつは、Overviewビューで「上限に近づいているポリシーとユーザー」を先に見つけておくこと。もうひとつは、Usersビューの日次データで、達してから気づくのではなく達する前に気づく体制にすること。そして、達してしまった場合に備えて、増枠の申請経路をあらかじめ現場に周知しておくことです。上限という数値そのものより、この3点セットのほうが実際の防波堤になります。

Cost managementの画面で何が見られるか

上限だけに頼れない以上、実際の消費を継続的に見る運用が必要です。Microsoft 365の管理センターには、Cost management（コスト管理）という機能があり、次のようなビューで消費状況を確認できます。

ビュー	見られる内容
Overview	上限に近づいているポリシーとユーザー
Consumption	ポリシー別・ユーザー別・グループ別・サービス別の消費状況
Policies	支出ポリシーの一覧（既定で表示されるビュー）
Users	ユーザーごとの日次のクレジット消費

特にUsersビューは、日次でクレジット消費を確認できる点が実務では重要です。月末にまとめて確認するのではなく、上限に近づいているユーザーやポリシーがいないかを、Overviewとあわせて定期的に見に行く運用にすることで、非同期評価による「気づいたときには超過していた」という事態を早めに察知できます。

運用の担当を分けるなら、Overviewは「今、注意すべきユーザー・ポリシーはどれか」を素早く拾うための入口、Consumptionは「どの部門・どのサービスに消費が偏っているか」を月次で振り返るための集計、Usersは「特定の個人の消費が急に増えていないか」を日次で追うための画面、と役割を分けて見ると整理しやすくなります。Policiesは既定で開くビューなので、まずポリシー単位の全体像を確認してから、必要に応じてConsumptionやUsersに絞り込んでいく流れが自然です。

「アクティブユーザー」は対象者全員を指すわけではない

予算を見積もるときにもう一つ注意したいのが、「アクティブユーザー」という言葉の意味です。アクティブユーザーは、Coworkを使う権限を持つ対象者全員ではなく、その期間中に実際に使った人だけを指します。

たとえば、支出ポリシーの対象に100人を含めていても、その月に実際にCoworkを開いてタスクを実行したのが20人だけであれば、レポート上の「アクティブユーザー」は20人です。対象人数と実消費者数が一致しない前提で数字を読まないと、予算の見積もりが実態からずれます。「対象者数×想定単価」で単純に予算を組むのではなく、Usersビューの実データで実消費者数を確認するほうが確実です。

この違いは、導入初期ほど大きく出ます。ライセンスを配布した直後は、実際に触ってみる人と様子見のままの人に分かれるため、対象者数とアクティブユーザー数の差が特に開きやすい時期です。逆に、利用が定着してくると両者は近づいていきます。予算会議で「対象者数」を使うと導入初期は過大に見積もりがちになる、という点は覚えておいて損はありません。

逆に、しばらく運用してからアクティブユーザー数が減っている場合は、消費額が下がったことを単純に喜ぶ前に、対象者のうち実際に使う人が減っていないかを確認したほうがよい場面もあります。消費額とアクティブユーザー数は、あわせて見てはじめて意味を持つ数字です。

経理・統制担当には「見るだけ」の権限を渡せる

コスト管理は、必ずしもIT管理者だけが見る必要はありません。Copilot Coworkには読み取り専用のロールが用意されており、設定を変更する権限を持たせずに、経理担当や内部統制の担当者に消費状況の閲覧だけを渡すことができます。予算の実績確認や月次の突合作業を、設定変更のリスクなく別の担当者に任せられる、という運用が可能です。

設定変更の権限とレポート閲覧の権限を分けておく発想は、IT管理者が不在のときに経理側が状況を追えなくなる、という事態を避けるうえでも有効です。特に中小企業では、Coworkの設定を触れる担当者が1人しかいないケースが珍しくありません。その担当者が不在でも、経理担当が読み取り専用ロールでUsersビューを確認できれば、月次の予算チェックが止まらずに済みます。

クレジットが足りなくなったときの経路

現場からの相談で多いのが「上限に達して作業が止まった、増やしてほしい」というケースです。この場合に備えて、ユーザー側からクレジットの増枠を申請し、管理者がそれを承認するという経路が用意されています。現場の申請を都度ヒアリングして個別対応するのではなく、この申請経路を使った運用にしておくと、誰がいつ何のために増枠を求めたのかが記録に残ります。

この申請経路があること自体が、「上限はリアルタイムの遮断ではない」という前提と対になっています。仮に上限がその場で完全にブロックする仕組みだったなら、業務が止まるたびに緊急対応が必要になります。非同期評価で多少の猶予がある分、申請→承認という通常のフローの中で増枠を処理できる、という見方もできます。

支払い方法——プリペイドと従量、Azure連携

支払いの形式は1種類ではありません。Copilot Creditsの支払いには、事前購入（プリペイド）と従量の両方が用意されています。予算を固定額で先に確保しておきたい場合と、実際に使った分だけ都度支払う場合とで、運用に合わせて選べる形です。プリペイドは月々の支出を一定に保ちたい組織に、従量は利用量がまだ読めない導入初期の組織に、それぞれ向いていると考えられます。

また、課金の設定画面には、Azureサブスクリプションと接続するための項目があります。Microsoft Learnの逐語です。

Connect an Azure subscription to support billing
（訳：課金をサポートするためにAzureサブスクリプションを接続する）

Azure経由での契約・支払い管理をすでに行っている組織であれば、この接続によって既存の課金体系にCopilot Coworkの消費を統合できます。

誰が何を見て、何をするか

ここまでの内容を、役割ごとに整理し直すと次のようになります。コスト管理は1人がすべてを担うのではなく、権限を分けて運用することを前提に設計されています。

役割	できること・見えるもの
IT管理者	支出ポリシーの設定、Cost managementの全ビュー閲覧、増枠申請の承認、Azureサブスクリプションとの接続
経理・内部統制担当	読み取り専用ロールで、Overview・Consumption・Usersの消費状況を閲覧
一般ユーザー	Coworkでのタスク実行、上限に近づいた・達した場合の増枠申請

小規模な組織では、IT管理者と経理担当を同一人物が兼ねることも珍しくありません。それでも、設定変更の操作と、消費状況の確認という2つの作業を頭の中で分けて考えておくと、「見るだけのつもりが設定を変えてしまった」といった事故を防ぎやすくなります。

よくある質問

クレジット上限を低く設定すれば、その場でCoworkの利用を止められますか

いいえ、期待どおりには止まりません。クレジット上限は支出の安全弁であり、リアルタイムの遮断ではないためです。クレジットの消費と上限の判定は非同期に評価されるため、上限に達した後でもタスクが開始されてしまうことがあります。今すぐ確実に止めたい場面では、上限の数値だけに頼らず、Cost managementの画面で消費状況を継続的に確認する運用と組み合わせる必要があります。