こんにちは、株式会社TIMEWELLの濱本です。Claude Code、Codex、Grok Build。この1年で、ターミナルの中で自律的にコードを書き、テストを回し、ドキュメントまで整えるコーディングエージェントが、開発現場の標準装備になりました。当社でも複数のエージェントを日常的に使っています。ただ、便利になった分だけ、エージェントは重くなりました。一つの仕事を任せると、裏側で何十回もモデルを呼び、コードベースを読み込み、試行錯誤を繰り返します。その結果、トークン代が月末に経営の議題に上がる会社が増えています。
この記事のテーマは、そのコストをどう下げるかです。結論から言うと、手段は五つあります。エージェントの接続先モデルを切り替えること。オープンソースのエージェントを使うこと。オープンウェイトのモデルを使うこと。国内のサーバレス推論サービスを使うこと。そして、社内にGPUを置くことです。それぞれに、公式ドキュメントで確認できる事実と、実際にやってみると分かる落とし穴があります。正直なところ、どれか一つで全部解決する話ではありません。だからこそ最後に、これらを組み合わせて「データを国内に置いたまま、コストを下げる」ためのAIゲートウェイという考え方を、初めての方にも分かるように説明します。自社のAI活用が今どの段階にあるかを先に確かめたい方は、AI活用レディネスの無料診断から入ってみてください。
なぜエージェントは高いのか。トークンの数え方を先に押さえる
まず、なぜコーディングエージェントはチャットより高くつくのかを、仕組みから説明します。AIモデルの利用料は「トークン」という単位で決まります。日本語なら1文字が1トークン前後、英語なら4文字で1トークン程度と考えてください。モデルに送る文章（入力）と、モデルが返す文章（出力）の両方に単価がかかり、多くのモデルでは出力のほうが5倍ほど高く設定されています。
チャットで質問を一つ投げるなら、入力も出力も数千トークンで済みます。しかしエージェントは違います。「このバグを直して」と一言頼むと、エージェントは関係するファイルを読み、テストを走らせ、結果を読み、修正案を書き、また試します。そのたびに、それまでの会話とファイルの中身をまとめて入力として送り直します。数十万トークン、大きな作業なら数百万トークンが動くのは珍しくありません。
単価を、公式の料金表で確認しておきます。AnthropicのClaude Opus 5は100万トークンあたり入力5ドル、出力25ドル。Claude Sonnet 5は入力2ドル、出力10ドル。Claude Haiku 4.5は入力1ドル、出力5ドルです。最上位のClaude Fable 5.1は入力10ドル、出力50ドルになります1。xAIのGrok 4.6は入力2ドル、出力6ドルで、コーディング専用のgrok-build-0.1は入力1ドル、出力2ドルです2。仮にOpus 5で1日に500万トークンの入力と50万トークンの出力を使う開発者が10人いれば、1日の費用は入力25ドルと出力12.5ドルの10倍で375ドル、月20営業日で7,500ドル、1ドル150円なら約112万円になります。これが「トークン代が経営の議題になる」の中身です。
なお、同じ料金表には値下げの仕組みも書かれています。プロンプトキャッシュを使うと、繰り返し送る部分の入力単価は基本の10分の1になり、非同期でよい処理をBatch APIに回すと入力も出力も半額です1。コストを下げる話は、モデルを変える前に、まず今のモデルの割引を使い切っているかを確認するところから始まります。Claude Codeの法人利用に絞った最適化は、Claude Code法人プランの料金最適化で詳しく書いています。
手段1。エージェントの接続先モデルを切り替える
一つ目の手段は、エージェントそのものは使い続けながら、裏側で呼ぶモデルを変えることです。ここは「技術的にできること」と「公式にサポートされていること」を分けて説明する必要があります。
OpenAIのCodex CLIは、この切り替えを公式にサポートしています。設定ファイルにmodel_providers.<id>という項目を書き、base_urlに接続先のAPIのURL、env_keyにAPIキーを入れた環境変数の名前を指定すると、OpenAI以外の互換APIに接続できます。さらに--ossというフラグがあり、oss_providerにollamaかlmstudioを指定すれば、手元のPCで動くローカルモデルにそのまま切り替えられます3。つまりCodex CLIは、OpenAIのモデル以外で動かすことを最初から想定した作りです。
xAIのGrok Buildも、公式ドキュメントにカスタムモデルの追加方法があります。設定ファイル~/.grok/config.tomlに[model.my-model]という項目を作り、modelにモデルID、base_urlに接続先、env_keyにAPIキーの環境変数を書き、[models]のdefaultに指定すれば、そのモデルが既定になります4。Grok Build自体は2026年5月に公開された比較的新しいツールですが、最大8つのサブエージェントを並列に走らせる設計と、この接続先の自由度が特徴です。
AnthropicのClaude Codeは、事情が少し違います。公式ドキュメントには「Other LLM gateways」という項目があり、ANTHROPIC_BASE_URLという環境変数で、組織が運用するゲートウェイを経由させる方法が書かれています。ゲートウェイの利点として、認証情報を端末に置かなくてよいこと、開発者ごとの利用量の追跡、予算とレート制限の一元管理、監査ログ、そして開発者の端末を触らずにプロバイダを切り替えられることが挙げられています。ただし同じページに、はっきりとこう書かれています。「Anthropicはサードパーティのゲートウェイ製品を推奨、保守、監査せず、いかなるゲートウェイを通じてであれ、Claude Codeを非Claudeモデルへルーティングすることはサポートしない」5。ゲートウェイの向こう側でAnthropic互換のAPIを話す別のモデルにつなぐことは技術的には成立しますが、それは自己責任の領域です。
私の整理はこうです。接続先の切り替えは、Codex CLIとGrok Buildでは公式の機能、Claude Codeでは公式のゲートウェイ機能を使った非公式の使い方です。どちらにしても、切り替えた先のモデルがエージェントの内部で使うツール呼び出しの形式に対応していなければ、動作は不安定になります。「安いモデルにつないだら、ファイルを編集してくれなくなった」という相談は実際に多く、モデルの能力ではなくツール呼び出しの互換性が原因であることがほとんどです。
手段2。オープンソースのエージェントを使う
二つ目は、エージェントそのものをオープンソースのものに替えることです。代表的なものが二つあります。
OpenCodeは、ターミナル、デスクトップアプリ、IDE拡張として使えるオープンソースのコーディングエージェントで、公式ドキュメントは「APIキーを設定すれば任意のLLMプロバイダを使える」と述べています6。特定のモデル会社に紐づかない設計なので、モデルの切り替えは最初から前提です。
Hermes Agentは、Nous Researchが公開しているMITライセンスのエージェントで、GitHub上で24万を超えるスターを集めています。READMEには「好きなモデルを使える。Nous Portal、OpenRouter、OpenAI、自前のエンドポイント、その他多数」とあり、hermes modelというコマンドでコードを変えずに切り替えられるとしています7。
以前は、オープンソースのエージェントには「誰が責任を持つのか」という不安がつきまといました。エージェントはファイルを書き換え、コマンドを実行するので、暴走したときの被害が大きいからです。ここは、Hermes Agentの公式のセキュリティ文書がかなり踏み込んでいます。DockerやModal、Daytonaなどのサンドボックスでエージェントのコマンドをホストから隔離し、Dockerでは--cap-drop ALLで権限を落とします。~/.sshや~/.aws、~/.kube、/etc/sudoers、~/.netrc、そしてエージェント自身の認証情報や.envへの書き込みは無条件に禁止され、書き込み先のディレクトリを指定した範囲に限定することもできます。危険なコマンドは既定の「smart」モードで補助的なLLMがリスクを評価し、確認を省くYOLOモードでもrm -rf /のような破滅的な操作はハードブロックのまま残ります。URLを扱うツールにはSSRF対策があり、社内ネットワークやクラウドのメタデータへのアクセスを遮断します。MCPの子プロセスに渡す環境変数は最小限に限定され、エラーメッセージに含まれるAPIキーは自動で伏せ字になります8。責任の所在は依然として利用者側にありますが、「何が守られているか」を文書で確認できる水準まで来ています。
オープンソースのエージェントを選ぶ現実的な理由は、コストそのものより、モデルの選択権を自分たちが持てることにあると私は考えています。エージェントの提供元がモデルの提供元でもある場合、値上げや仕様変更に対して交渉の余地がありません。エージェントとモデルを分離しておけば、モデルの市場価格が下がったときにその恩恵をすぐ受けられます。
手段3。オープンウェイトのモデルを使う
三つ目は、モデルそのものをオープンウェイトのものにすることです。オープンウェイトモデルとは、モデルの中身（重み）が公開されていて、誰でもダウンロードして自分の環境で動かせるモデルのことです。中国の研究機関や企業が公開しているKimi、GLM、MiniMax、Qwen、DeepSeek、NVIDIAのNemotron、Googleのgemma、OpenAIのgpt-ossなど、2026年には主要な提供元がそろいました。
オープンウェイトの利点は、モデルの提供元と、モデルを動かす場所を切り離せることです。中国の企業が作ったモデルを日本の事業者のサーバーで動かし、データは日本から出さない構成。あるいは、自社のGPUで動かして通信そのものを社外に出さない構成。どちらも成り立ちます。逆に言えば、オープンウェイトモデルを提供元のAPIで使うのなら、データの行き先という点では他社のクラウドモデルと変わりません。「オープンウェイトだから安全」ではなく、「オープンウェイトだから、どこで動かすかを選べる」と理解するのが正確です。
もう一つの利点は、供給元の都合に振り回されにくいことです。クラウドのモデルは、提供元の判断で性能が変わったり、旧モデルが提供終了になったりします。手元に重みがあれば、少なくとも「昨日まで動いていたものが今日動かない」という事態は避けられます。この点は、黙ってモデルを落とすのは信頼の話だで書いたとおりです。
コストは、モデルの単価だけで決まりません。オープンウェイトモデルは、それを動かす場所の料金で決まります。次の二つの手段は、その「動かす場所」の話です。
手段4。国内のサーバレス推論を使う
四つ目は、オープンウェイトモデルを国内の事業者がAPIとして提供している、いわゆるサーバレス推論サービスを使うことです。米国ではFireworks AIやTogether AIのような事業者がこの領域を作ってきましたが、日本にも同じ型のサービスが出てきています。
代表例が、さくらインターネットが2025年9月に一般提供を始めた「さくらのAI Engine」です。公式サイトは「すべて国内クラウドで完結。外部へのデータ送信なし」と謳い、OpenAI互換のChat Completions APIとResponses API、そしてAnthropic互換のMessages APIを提供しています。モデルはOpenAIのgpt-oss-120bや国産のllm-jp-3.1のほか、プレビューとしてQwen3、Phi-4、Kimi-K2、gemma-4-31B-itなどが並びます。料金は、gpt-oss-120bで入力1万トークンあたり0.15円、出力0.75円。無償プランではChat Completionsが月3,000リクエストまで使えます9。
この数字を、先ほどのClaude Opus 5と並べてみます。100万トークンに直すと、gpt-oss-120bは入力15円、出力75円。Opus 5は1ドル150円で入力750円、出力3,750円です。単価だけなら50倍の開きがあります。もちろん、モデルの能力は同じではありません。複雑な設計判断や大規模なリファクタリングでは上位モデルのほうが結果的に安くつくこともあります。しかし、定型的なコード生成、テストの雛形作り、ログの要約、コミットメッセージの生成のような作業に、毎回最上位モデルを使う必要はありません。作業の種類でモデルを振り分けるだけで、請求書の形は変わります。
さくらのAI EngineがAnthropic互換のMessages APIを持つことは、手段1と組み合わせたときに意味を持ちます。Claude CodeのANTHROPIC_BASE_URLをゲートウェイに向け、ゲートウェイが作業の種類に応じて国内のオープンウェイトモデルへ振り分ける、という構成が技術的に組めるからです。繰り返しますが、これはAnthropicがサポートしない使い方です5。それでも、国内でデータを完結させながらコストを下げる道筋として、選択肢に入れておく価値はあります。国内リージョンでどのモデルが動くかの全体像は、国内リージョンでLLMは動かせるのかにまとめています。
手段5。社内にGPUを置く。オンプレとローカルLLMの現実
五つ目は、自社でGPUを持ち、モデルを社内で動かすことです。ここ1年で、この選択肢は現実的になりました。NVIDIAのDGX Sparkは、128GBの統合メモリを持ち、最大2,000億パラメータのモデルをデスクトップで推論でき、700億パラメータまでのファインチューニングにも対応すると公式サイトは述べています。同社はこれを「エージェントや大規模モデルをローカルで動かし、クラウドのトークン生成への依存を減らす」ための機械と位置づけています10。Appleの大容量メモリを積んだMac Studioでオープンウェイトモデルを動かす開発者も増えました。もう少し本格的に、データセンター向けのGPUを数枚積んだサーバーを社内に置く企業もあります。
オンプレの利点は明快です。トークン単価がゼロになること、そしてデータが物理的に社外へ出ないこと。設計図や顧客データを扱う部署では、この二つ目が決め手でしょう。
ただし、実際にやってみると分かる弱点が三つあります。第一に、ウェブ検索や外部ツールとの連携です。クラウドのエージェントは、検索やドキュメント参照を含めた一連の流れを提供元が最適化していますが、ローカルでは自分たちで組む必要があり、ここの品質差が体感の差になります。第二に、速度です。同じモデルでも、手元の1台と、数千枚のGPUで並列に処理するクラウドでは、出力の速さが違います。エージェントは何十回もモデルを呼ぶので、1回の遅れが積み重なります。第三に、運用です。モデルの更新、ドライバやランタイムの管理、故障時の対応は、誰かの仕事になります。トークン代がゼロでも、人件費と電気代はゼロではありません。
私の見立てでは、オンプレは「全部をここでやる」ものではなく、「外に出せないデータを扱う作業を、ここに寄せる」ものです。最新モデルが必要な作業はクラウドへ、機密性の高い作業は社内へ。この振り分けを人手でやると必ず漏れるので、仕組みが要ります。それが次の話です。
五つの手段をつなぐ「データを国内に置いたままにするAIゲートウェイ」
ここまでの五つの手段は、どれも単独では中途半端です。モデルを切り替えれば安くなりますが、作業によって最適なモデルは違います。オープンウェイトは自由ですが、動かす場所を決めなければ意味がありません。国内サーバレスは安くて国内完結ですが、最上位の能力は出ません。オンプレは安全ですが、遅くて運用が重い。これらを一つの方針にまとめるのが、AIゲートウェイです。
AIゲートウェイとは、エージェントやアプリケーションとモデルの間に置く中継サーバーです。Anthropicの公式ドキュメントが挙げる利点をもう一度並べると、認証情報の集中管理、利用者ごとの使用量の追跡、予算とレート制限の一元管理、監査ログ、開発者の端末に触れないプロバイダ切り替え、の五つでした5。企業にとっての本当の価値は、ここに「ルール」を置けることです。たとえば、設計図を含むリクエストは国内のモデルにしか送らないというルール。コミットメッセージの生成は最も安いモデルに回すというルール。夜間のバッチ処理は半額のBatch APIに流し、特定の部署は最新モデルを使ってよいものの、月の予算を超えたら国内モデルに切り替えるというルール。こうしたルールを、開発者一人ひとりの設定ではなく、会社として一か所で決められます。
私たちが「データ主権のあるAI」と呼んでいるのは、まさにこの状態のことです。どのデータをどこで計算し、どこに置くかを、会社が自分で決めて、自分で説明できる状態です。コストの最適化と、データの管理は、別々の課題に見えて、実はゲートウェイという同じ場所で解決します。当社では、エンタープライズ向けのZEROCKをAWSの国内リージョンで運用し、Amazon Bedrock経由で国内リージョンのモデルを指定できる構成にしてきました。一部の最新モデルはグローバルリージョンで推論しますが、お客様のデータで再学習することはありません。この設計の延長として、社内のAIエージェントを常時運用し、自動化を回し続けたい企業向けに、データを国内に置いたままコストを下げるゲートウェイの提供に向けた開発も進めています。エージェントを「試す」段階から「毎日回す」段階に移る企業ほど、この部品が要ります。Bedrock経由のセキュアな構成については、Claude Code EnterpriseのBedrock/Vertex経由ゲートウェイ設計も参考になるはずです。
まとめ。安くする前に、振り分けを決める
コーディングエージェントのコストは、モデルを一つ安いものに替えれば下がる、という単純な話ではありません。今のモデルの割引を使い切っているか。エージェントの接続先を公式の方法で切り替えられるか。オープンソースのエージェントで選択権を自分たちに戻すか。オープンウェイトモデルを、どこで動かすか。国内サーバレスと社内GPUを、どの作業に割り当てるか。これらを個人の工夫ではなく、会社の方針として一か所に置くのがゲートウェイです。
この記事で確認した事実をまとめると、こうなります。Codex CLIとGrok Buildは接続先の切り替えを公式に持ち、Claude Codeはゲートウェイ経由を公式に案内しつつ非Claudeモデルはサポート外だと明記しています。Hermes Agentのようなオープンソースのエージェントは、サンドボックスと書き込み禁止パスを文書で示す水準に達しました。さくらのAI EngineのようにOpenAI互換とAnthropic互換の両方を国内で提供する事業者が現れ、gpt-oss-120bの出力は100万トークン75円です。そしてDGX Sparkのような機械で、2,000億パラメータのモデルが机の上で動きます。材料はそろっています。
まず今週やるなら、自社のエージェント利用を「外に出せないデータを扱う作業」「最新モデルが要る作業」「安いモデルで十分な作業」の三つに分けて、それぞれの割合を出してみてください。それだけで、どの手段から着手すべきかが見えます。振り分けのルール設計や、社内でエージェントを常時運用するための基盤について相談したい方は、個別相談からお声がけください。状況を伺ったうえで、一緒に構成を考えます。
参考
料金と仕様はいずれも2026年9月12日時点の公式ドキュメントに基づきます。為替換算は1ドル150円の概算です。
