【クレジット消費時代】AI利用コストを抑えたい人のためのクラウドAI×ローカルAI 実践入門 ①

第1章　AI利用は「回数制」から「クレジット消費型」へ

この章では、本記事の出発点でもある前提を整理します。
なぜクラウドのAIサービスは、月額制や利用回数で区切る方式から処理量に応じて費用がかかる方式へと変わってきたのか。そして、その変化はエージェントAIの広まりとどう結びつき、私たちの業務にどのような影響を与えるのか？

技術の細部に入る前に、まずはこの流れを大きくつかんでおきます。専門用語もいくつか出てきますが、ここで一つひとつ覚える必要はありません。

1-1　生成AIの料金体系がなぜ変わってきたのか

文章や画像を作り出すAI、いわゆる生成AIが広く使われ始めたころ、個人向けのサービスの多くは月額の定額制でした。一定の料金を払えば、決められた時間あたりの送信回数の範囲内で自由に使える。上限に触れても、しばらく待てばまた使えるようになる。利用者から見れば、毎月の支払いが明確で分かりやすい仕組みです。

この方式が変わってきた理由を理解するために、生成AIサービスの内部で何が起きているかを簡単に押さえておきます。
生成AIは入力された文章（プロンプト）を、「トークン」と呼ばれる小さな単位に分けて処理します。これは言語やAIのモデルなどにより異なりますが、日本語ではおおむね1文字から数文字が1トークンに相当します。
AIに送る文章（入力）も、AIが生成した文章（出力）も、このトークンの量で測られます。そして、モデルを動かす計算には、トークンの量に応じてコストがかかります。

定額制では利用者がどれだけのトークンを使っても料金は一定でした。生成AIをどれくらい使用するかは業務や目的などにより人それぞれですが、そこには差があり、その差を提供側が吸収していたことになります。
生成AIの利用が穏やかなうちはこの形でも成り立っていました。ですが、後述するように一度の操作で大量のトークンを消費する使い方が広がると、定額の範囲では費用を賄いきれない場面が増えます。そこで実際に使った分を測って課金する方式へと移す動きが進みました。

この一つの例として挙げられるのが開発支援ツールのGitHub Copilotです。
GitHub Copilotでは2026年6月1日、すべての契約プランが利用量に応じた従量課金制（Usage-Based Billing）へ移行しました。GitHubの説明によれば、利用量は「GitHub AIクレジット」という単位に換算され、換算のもとになるのは、入力・出力・キャッシュされたトークンの量で、単価は使ったモデルごとに異なります。
月額のプランにはあらかじめ一定額分のクレジットが含まれ、たとえば19ドル/月のプランには19ドル分のクレジットが付与される、という形です。

ここで使われる「クレジット」とは、お金そのものではなく、サービスを使う権利をあらかじめ金額換算でまとめたプリペイドの利用枠といえます。
処理をするたび、その処理の重さに応じた残高が減っていきます。回数で区切る方式が「何回使ったか」を数えていたのに対し、クレジット消費型は「どれだけの処理をさせたか」を測る方式です。

なお、この移行の進み方は提供事業者によってさまざまで、しかも短い間に変わります。ある事業者では自動化ツール経由の利用を別枠のクレジットに分ける変更を予告しましたが、その後に実施を見送ったと案内した事例もあります。ここに挙げたGitHub Copilotの例も本記事の執筆時点（2026年6月末）のもののため、これ以降に条件が変わっているかもしれません。AIサービスの流れ、特にAIエージェントと呼ばれるサービスでは、「使った処理量で費用が決まる方向へ進んでいる」と理解しておくとよいかと思います。

1-2　エージェントAIの登場と、クレジット消費が大きくなる理由

料金体系の変化を後押ししている要因の一つがエージェントAIの広まりです。エージェントAIについては改めて取り上げますが、ここではクレジット消費との関わりが分かる範囲で解説します。

従来のチャット形式のAIは基本的に一問一答でした。質問（プロンプト）を送ると答え（生成されたテキスト、画像など）が返され、そこで一区切りがつきます。
これに対してエージェントAIは、目的を伝えるとそれを達成するための手順をAI自身が組み立てて実行します。たとえば、「この資料を読んで要点をまとめ、表に整理して」と指示したとします。AIは、資料の読み込み、内容の抽出、表形式の出力、出力結果の点検、点検結果から不備が見つかれば修正、といった一連の作業を計画し、その計画に沿って処理を進めます。

この進め方が消費するトークン量を増加させます。主な理由としては二つあります。一つは、作業のなかで何度もモデルに問い合わせる点です。一回の指示に対してAIへの呼び出しが一度で終わらず、手順の数だけ繰り返されます。もう一つは、呼び出しのたびに、それまでの経緯やこれまでに読み込んだ資料をあらためて送り直すことが多い点です。作業が進むほど、AIに渡す前提（入力トークン）はふくらんでいきます。出力だけでなく入力の量も積み上がるため、合計は一問一答の場合よりかなり大きくなります。複雑な指示の場合、一つの作業を仕上げるあいだに数十万から数百万トークンに達することもあるという事例が報告されています。
定額制の場合ではこうした重い使い方でも料金は変わりませんでした。しかし、利用枠を消費する方式に変わると一回あたりの作業の重さがそのままクレジット残高の減り方に表れます。「AIが自律的に作業を行ってくれる」性質が、クレジットの消費を大きくする要因にもなる。この二面性にどう向き合うのかが、本記事にて取り上げるテーマの中心になります。

1-3　利用制限が日々の業務に与える影響

クレジット消費型への移行と、エージェントAIによる消費の増加。この二つが重なると実際の業務にいくつかの具体的な影響が現れます。

まず、週や月の途中で利用枠を使い切ってしまう事態が考えられます。サービスによっては一日や数時間といった短い単位に加えて、週単位で上限を設けているものもあります。週の上限に達すると、たとえ短い単位の枠が残っていても、その週の制限がリセットされるまで使えなくなります。クレジットを早く消費する場面は締め切り直前など逼迫した状況ということも多く、必要なタイミングに限って残高が尽きる、というケースが想定されます。

次に、費用の見通しが立てにくくなります。回数で区切る方式なら「あと何回使えるか」が直感的に分かりました。ですが、クレジット消費型では同じ一回の指示でも内容によって減り方が変わります。短いプロンプトは軽く長い資料を扱う作業は重い、とは限らないため、利用者が事前にその重さを正確に見積もることは簡単ではありません。含まれる枠を超えた分を追加で支払える設定にしている場合、想定より費用がふくらむこともあります。

そして、チームでクレジットや予算を共有する場合には誰がどれだけ消費するかを調整する必要が出てきます。特定の作業に枠を集中させるのか、全員に薄く配るのかといった判断が生じますが、こうした調整事項はAIを使ううえで新たに考えなければならない手間となります。

これは「手間が増えるからAIは使えない」という話ではありません。むしろ役に立つからこそ使う量が増え、その結果として枠の管理が課題になっている、という順序で整理する必要があります。
そのため解決の方向性は、「AIの利用をやめる、制限する」ではなく、「同じ成果をより少ないクレジット消費で得るための仕組みを整備する」になります。

1-4　クラウドとローカルのハイブリッド活用

前述の課題に対して、本記事では、クラウドAIと手元のパソコンで動くローカルAIを組み合わせる方法を、解決策の一つとして取り上げます。本節では、その考え方の土台を整理します。

AIに任せたい仕事をよく見ると、そのすべてが最先端の高性能なモデルを必要とするわけではありません。たとえば、文書から文字を取り出す、文書を分割する、似た内容の文書を探す、検索用の情報を作る、などの処理は、比較的小規模なモデルやローカル環境でもこなせる場合があります。

一方、複数の資料を踏まえて論理立てた説明を組み立てる、顧客向けに自然な文章へ整える、複雑な推論を行う、などの作業は高性能なクラウドAIが有効です。

そこで、前者のような処理はローカルAIに任せ、後者のように品質や高度な推論が必要な処理だけをクラウドAIで行うように役割を分担します。こうして処理を振り分けることができれば、クラウド側が負担する処理量を減らし、クレジット消費を抑えることができます。また、社内文書をそのままクラウドへ送る場面を減らせるため、情報の外部送信を抑えることにもつながります。

この方針を、説明だけでなく実際に作って確かめられるよう、本記事では一つのアプリケーションを題材にします。社内に散らばる規程、マニュアル、議事録などの文書を取り込み、検索し、内容について質問すると回答が返ってくる「社内文書AIアシスタント」です。

このアプリケーションでは、文書の前処理や検索をローカルAIが受け持ち、仕上げの生成が必要な場面に限ってクラウドAIを使う構成にします。開発支援にはCodexを使い、アプリが利用するクラウドAIにはAzure OpenAIを、ローカルAIの実行環境にはFoundry Localを使用します。

次の第2章では、処理をどのように振り分けるかを考えるために、クラウドAIとローカルAIの性質を確認します。コスト、安全性、速度、処理品質などの観点から、それぞれの特徴を整理し、「どの処理をどちらに任せるか」の判断軸を作っていきます。

ご覧いただきありがとうございました。
この記事で解説予定の「クラウドAI×ローカルAI」にご興味がある、または、役に立ちそうかな？と感じていただけたら「スキ」や「フォロー」いただけるとうれしいです。
記事継続の参考にさせていただきます。