こんにちは。ACS事業部の越川です。
- まず「2つの選択」を分ける
- 「定額が当たり前」が崩れた
- 判断軸1: タスクの性質で振り分ける
- 判断軸2: 課金モデルを設計として読む
- 判断軸3: データの扱いを契約で読む
- 個人の感覚を、組織の判断軸に落とす
- まとめ
- 参考
- ACS 事業部のご紹介
今年の4月、Claude Codeを業務で本格的に使い始めました。そのタイミングで「GitHub Copilotのリクエスト枠を2日で56%消費した失敗から見えた、Claude Codeとの補完関係」という記事を書き、最後に「3ヶ月の検証期間で結果が見えてきたら、改めて記事にしたい」と宣言していました。
本記事はその答えです。ただし、予定より1ヶ月早い、2ヶ月目での報告になりました。3ヶ月を待たずに書かざるを得なくなった理由があります。2026年6月1日のGitHub Copilotの従量課金（AI Credits）移行です。
この仕様変更の影響力が、想定よりはるかに大きかったのです。これまで「なんとなく」で済ませられていたツールとモデルの選び方が、コスト設計の問題として一気に誰の目にも見えるようになりました。倍率の高いモデルを使えば請求がそのまま跳ね上がり、組織全体でクレジットを共有していれば一部の重い利用が全体に波及する。判断を先送りにできる猶予が、6月1日を境に消えたのです。検証をのんびり3ヶ月続けている場合ではなくなった、というのが正直なところです。
この2ヶ月で、私が個人の感覚でやっていた「定額ツールと従量ツールの使い分け」を、チームの誰でも同じ判断ができる形に落とし込みました。
本記事では、価格モデルが変わった今、AIコーディングツールをどう選ぶかの判断軸を3つに整理します。具体的な金額や契約交渉の話ではなく、意思決定の構造の話です。この記事は、4月からの2ヶ月の検証の到達点です。
まず「2つの選択」を分ける
本題に入る前に、ひとつ整理しておきます。AIコーディングのコストには、レイヤーの違う2つの選択が絡みます。
- エコシステムの選択: どのツール（＝どの課金体系）を使うか。たとえば従量課金のGitHub Copilotか、定額シートのClaude Codeか
- モデルの選択: 選んだツールの中で、どのモデルを使うか。たとえばSonnetかOpusか
この2つは別レイヤーです。そして、モデル選択がコストに直結するかどうかは、上のエコシステム選択によって決まります。従量課金のツールを使えば、モデルの倍率がそのまま請求額を動かします。一方で定額シートのツールに寄せれば、モデルを変えても定額の枠内で、モデル選択は主にコストではなく性能の判断になります。
4月の「AIコーディングは何にいくら払うかを選ぶ時代へ」では、後者のモデル選択（従量課金の中での倍率）を扱いました。本記事はその一段上、まずどのエコシステムを選ぶかの判断軸を整理します。
「定額が当たり前」が崩れた
少し前まで、AIコーディングは定額で使えるのが当たり前でした。月額いくらを払えば、あとは使い放題に近い感覚で、どのモデルを選んでも請求額は変わりませんでした。
その前提が、2026年6月を境に崩れました。GitHub Copilotがリクエスト単位の課金からトークン消費ベースの従量課金（AI Credits）に移行し、モデルごとに消費レートが大きく異なる構造になりました。私はこの構造の分析を「AIコーディングは何にいくら払うかを選ぶ時代へ」で書きましたが、当時は施行前の予測でした。
施行を迎えた今、現場で起きていることはシンプルです。昨日まで標準だったモデルが、今日から高コスト側に倒れたという体験が、あちこちで同時多発的に起きています。「とりあえず一番賢いモデルで」という使い方が、そのまま請求額に跳ね返るようになりました。
LayerXの福島良典さんは、この変化を「トークンマキシングからトークンマネジメントへ」という言葉で表現しています。エンジニアが消費するトークンコストは給与の数十%に達するケースもあり、経営にとって新しいコスト科目になった。だからこそ「踏むべきところは踏み、コントロールすべきところはコントロールする」マネジメントができる会社が抜きんでる、という主張です。
私もまったく同じ問題意識を持っています。そして個人の実践として、この2ヶ月でその「踏むかコントロールするか」を判断するための軸を組み立ててきました。以下、その3つの軸を共有します。
判断軸1: タスクの性質で振り分ける
最初の軸は、4月の記事から一貫しています。タスクの性質で、どのツールに寄せるかを振り分けることです。これはエコシステム選択のレイヤーの話です。
私が4月にたどり着いた基準は単純でした。
- 数秒で終わる補完・確認 → 従量ツールの軽量な機能（多くの場合は無料の補完）
- 数分以上の対話・設計・生成 → 定額ツールでまとまった文脈を渡す
この基準自体は2ヶ月使っても変わりませんでした。むしろ従量課金への移行で、この振り分けの経済的な意味がはっきりしました。
ポイントは、AIコーディングのリソース消費の振れ幅が極端だということです。同じ1回の操作でも、その中身は桁違いに振れます。
| 操作の種類 | おおよそのトークン消費 | 桁 |
|---|---|---|
| コード補完 | 数百トークン | 2〜3桁 |
| 軽いチャット | 数千トークン | 3〜4桁 |
| エージェントのマルチステップ実行 | 数十万〜数百万トークン | 5〜6桁 |
この表のとおり、補完とエージェント実行では4桁から6桁の差があります。この振れ幅を定額で吸収するのは構造的に無理があり、だからこそ従量課金への移行が起きました。
逆に言えば、振れ幅を理解していれば振り分けられます。常時オンで使う軽い補完は、それ専用に最適化された機能（多くは無料）に任せる。長い文脈を抱えて深く対話する作業は、まとまった使用量が確保された定額ツールに寄せる。何にいくら払うかをタスクの性質から逆算するのが第一の軸です。
判断軸2: 課金モデルを設計として読む
第二の軸は、課金モデルそのものを設計判断として読むことです。
ここで重要なのは、定額と従量それぞれの向き不向きを理解することです。
| 従量課金 | 定額課金 | |
|---|---|---|
| 課金の仕組み | 消費したトークン量に比例 | 一定額で一定の使用量込み |
| 強み | 軽い利用ならコストが下がる。組織で予算をプール管理しやすい | 重い利用でもコストが予見できる。上限を気にせず使える |
| 注意点 | 重い利用で青天井になりうる | 軽い利用だと割高になりうる |
| 向く使い方 | 補完・短い質問・軽量モデル中心 | 長時間の自律作業・設計・深い対話 |
組織として従量課金を採用する場合、見落としやすい落とし穴があります。従量課金のクレジットを組織単位でプールすると、個人単位で上限を設けない限り、一部のヘビーユーザーの消費が全体に波及します。 月初の数日で大半を使い切るような事態を防ぐには、組織プールに頼り切らず、利用者単位の予算上限を設定する設計が必要です。これはGitHub Actionsの利用枠が組織全体で共有されるのと同じ構造で、運用経験のある方には馴染みのある話だと思います。
一方で定額ツールは、シートに使用量が込みで、個人ごとの従量が青天井にならない安心感があります。ただし軽い利用しかしないメンバーには割高になります。
つまり、ツールごとに課金モデルがどんな使い方を想定して設計されているかを読み取り、自分たちの使い方と一致させるのが第二の軸です。値上げか値下げかという表面ではなく、課金の構造からそのツールが何に向いているかを逆算します。
判断軸3: データの扱いを契約で読む
第三の軸は、コストとは別系統ですが、業務でAIを使う以上は外せません。データの扱いを契約レベルで確認することです。
ここで私が2ヶ月で痛感したのは、学習利用とデータ保持はまったく別の話で、混同されやすいということです。
| 項目 | 意味 |
|---|---|
| 学習利用 | 送ったデータをAIモデルの学習に使うかどうか |
| データ保持 | 学習とは無関係に、提供事業者のサーバーにデータが保存される期間 |
この2つは独立しています。たとえば「学習には使わないが、運用や不正防止のためにサーバー上に一定期間は保存される」という状態は普通にありえます。保存されること自体と、学習に流用されることは、分けて考える必要があります。
業務でAIコーディングツールを使うなら、最低限ここを公式ドキュメントで確認すべきだと考えています。
- 送ったコードやプロンプトが、デフォルトで学習に使われるか
- 個人向けプランと、組織向けの商用プランで、その既定が違わないか
- データがサーバーに保存される期間はどれくらいか
- 一切保存させない設定が用意されているか
私が確認した範囲では、ツールによっては個人向けプランと商用プランで学習利用の既定が逆になっていることがありました。個人向けは学習に使う設定がデフォルトで、商用プランはデフォルトで使わない、というように。業務で使うなら必ず商用プランで揃えるという判断は、この確認をして初めて根拠を持って言えます。
ここで大事なのは、「公式サイトに書いてあったから安全」で済ませないことです。自分でドキュメントを読み、プランごとの違いを確認し、根拠を持って説明できる状態にする。AIツールの選定は、性能比較やコスト比較だけでなく、この契約面の確認まで含めて初めて完結します。
個人の感覚を、組織の判断軸に落とす
ここまでの3つの軸は、もともと私が個人で「なんとなく」やっていたことです。タスクが重いか軽いかで使うツールを変える。課金が高くつきそうなら別の手段を考える。データの扱いは気になったら調べる。少し前までの私は、これを言語化せずに体感でやっていました。
問題は、体感は他人に引き継げないことです。私の頭の中にしかない基準では、チームの誰かが同じ判断をできません。「越川さんに聞かないと分からない」状態は、組織としては機能しません。
そこでこの2ヶ月でやったのは、頭の中の基準を3つの軸として外に出すことでした。
- タスクの性質で振り分ける（軸1）
- 課金モデルを設計として読む（軸2）
- データの扱いを契約で読む（軸3）
この3軸を共有しておけば、誰でも目の前のタスクに対して「これは補完で十分」「これは定額ツールで深く対話する作業」「このツールは業務に使う前にデータ規約を確認する」と判断できます。判断の結論ではなく、判断の構造を共有することが、2ヶ月の検証で得た一番の学びでした。
4月の記事で、私は CLAUDE.md のような合意文書でチームの判断軸を共有する仮説を書きました。2ヶ月を経て、その仮説は方向として正しかったと感じています。共有すべきは「どのモデルを使え」という固定の答えではなく、「どう判断するか」という軸そのものです。価格構造は今後も変わり続けます。答えを配ってもすぐ陳腐化しますが、判断の軸は変化に追従できます。
まとめ
GitHub Copilotの従量課金移行をきっかけに、AIコーディングツールの選び方を3つの判断軸に整理しました。
| 軸 | 内容 |
|---|---|
| 軸1: タスクの性質 | 数秒の補完は軽量機能へ、数分以上の対話は定額ツールへ。消費の振れ幅から逆算する |
| 軸2: 課金モデル | 定額と従量の向き不向きを設計として読む。組織プールは個人単位の上限設定が必須 |
| 軸3: データの扱い | 学習利用とデータ保持は別物。業務利用は商用プランで揃え、規約を自分で確認する |
価格モデルの変化は、技術の問題ではなく組織設計の問題です。まずどのエコシステムを選ぶか、その中でどのモデルを使うか。この2つのレイヤーは、もはや性能比較だけでは決まりません。コストの根拠も、データの扱いの根拠も含めて説明できることが、これからのエンジニアリングに求められる能力になります。
そして、その判断を個人の感覚に留めず、チームの誰もが再現できる軸に落とす。とりあえず一番賢いモデルで、ではなく、どのツールのどのモデルかを意思を持って選ぶ。その意思の質が、組織のAI活用の質を決めると考えています。
私たちはNDAやガイドラインに従い、案件ごとに適切なAIツールを選定しています。「何でもAIを使う」のではなく、企業としてのガバナンスの下で、判断の根拠を持って使う。価格構造を読むことも、その根拠の一部です。
価格は今後も変わり続けます。だからこそ、変わらない判断の軸を持つことに意味があります。
参考
- GitHub Copilotのリクエスト枠を2日で56%消費した失敗から見えた、Claude Codeとの補完関係 — 筆者の過去記事（4月）。使い分けの起点と「3ヶ月後に書く」宣言
- AIコーディングは「何にいくら払うか」を選ぶ時代へ — 筆者の過去記事（4月）。従量課金移行の構造分析とモデル選択の倍率
- トークンマキシングからトークンマネジメントへ — 福島良典（LayerX）。トークンコストを新しいコスト科目として捉える視点
- GitHub Copilot is moving to usage-based billing — GitHub Blog（2026-04-27）従量課金移行の一次情報
- Claude Code公式ドキュメント — Data usage — 商用プランの学習利用・データ保持の既定
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
