AIが「途中で忘れる」本当の理由とコスト──context-mode で学ぶトークン節約の仕組みと実測値

2026年6月30日

AIコーディングツールの利用コストが急速に増えています。Claude Code・Codex・GitHub Copilot はいずれも強力な開発支援をしてくれる反面、サブスクリプションプランには日次・週次の利用上限が設けられており、上限を超えると追加課金が発生するか、その日はそれ以上使えなくなります。API を直接利用する場合は「トークン」という単位での従量課金になるため、使い方によっては想定外の費用に達することもあります。この記事では、「トークンとは何か」という基礎から「context-mode がなぜトークンを削減できるのか」という仕組みまで、エンジニアでなくても理解できるよう図を交えて解説します。開発コストの削減・リードタイムの短縮・チームの生産性向上につながる考え方として活用してください。

通常開発と context-mode 導入後の比較

比較項目	通常の開発	context-mode 導入後
1セッションのコンテキスト消費量	数百MB 規模に達することがある	最大 98% 削減
長時間作業での精度低下	起きやすい（コンテキスト枯渇）	起きにくい
AIへの再指示・やり直し頻度	高い	低い
セッション中断のリスク	高い	大幅に低下
開発リードタイムへの影響	枯渇のたびに伸びる	安定して短縮

詳細な削減効果の数値は後半の「仕組み別削減効果まとめ」で示します。

検証環境

OS: macOS Sequoia 15.5
Node.js: 22.13.0
主要パッケージ:
- context-mode: latest（npm）
検証日: 2026年06月17日

AIコーディングツールの課金モデルとプラン別制限の背景

この章では、各ツールの最新の課金モデルとプラン制限を整理します。

Claude Code・Codex CLI・GitHub Copilot のようなAIコーディングツールは、2025年以降で急速に実務利用が進みました。「月額固定で使い放題」に見えても、実際にはトークン消費量に応じた上限や追加課金が存在します。

Claude Code（Anthropic）

Claude Code は Anthropic のサブスクリプションプランを通じて利用します。プランによって使える量（利用上限）が異なります。

プラン	月額	特徴
Free	無料	限定的な利用のみ
Pro	$20	標準的な利用量
Max 5x	$100	Pro の約5倍の利用量
Max 20x	$200	Pro の約20倍の利用量

Claude Code を本格的に使う場合は Max プランが前提になることが多く、ヘビーユーザーは Max 20x でも制限に達するケースがあります。API を直接利用する場合は、モデルごとのトークン従量課金が別途かかります（Claude Opus 4.8・Sonnet 4.6・Haiku 4.5 など）。

Codex CLI（OpenAI）

Codex CLI は OpenAI の API を直接利用する従量課金モデルです。利用するモデル（GPT-5.5 など）によって 100 万トークンあたりの入力・出力単価が異なります。使えば使うほどコストが積み上がる構造で、大規模な作業やチーム利用では月次コストの予測が難しくなります。

GitHub Copilot

GitHub Copilot は個人向けから企業向けまで複数のプランがあります。

プラン	月額	主な対象
Free	無料	限定利用
Pro	$10	個人開発者
Pro+	$39	プレミアムモデル利用
Max	$100	ヘビーユーザー・エージェント利用
Business	$19/シート	チーム・組織
Enterprise	$39/シート	大規模組織

重要な注意点（2026年4月以降）：Pro・Pro+・Max の個人向け新規登録は 2026年4月20日から一時停止されています。また Max プランへの加入は、2026年6月1日以降は既存プランからのアップグレードのみとなっています。最新状況は公式ドキュメントで確認してください。

各プランには「GitHub AI Credits」と呼ばれる利用枠が付与されており、エージェントモードやプレミアムモデルの利用がこの枠を消費します。枠を超えると追加課金が発生するか、その機能が使えなくなります。

いずれのツールも、AIとのやり取りの量（＝トークン数）が増えるほどコストが上がるか、上限に達するという構造を持っています。

mermaidflowchart LR
  dev["開発者が指示を出す"] --> input["入力トークン"]
  input --> ai["AIが処理・回答"]
  ai --> output["出力トークン（コード等）"]
  input --> bill["課金発生"]
  output --> bill
  bill --> cost["月次費用 / 利用制限"]

上図のように、AIに何かを伝えるたびに「入力トークン」、AIが返答するたびに「出力トークン」が発生し、その合計が費用として積み上がります。

mermaidflowchart LR
  subgraph r1["1回目のやり取り"]
    direction TB
    x1["入力 500T / 出力 300T\n累計 800T"]
  end
  subgraph r2["数回後"]
    direction TB
    x2["入力 5,000T / 出力 2,000T\n累計 30,000T"]
  end
  subgraph r3["30分後"]
    direction TB
    x3["入力 80,000T / 出力 40,000T\n累計 500,000T+"]
  end
  r1 -->|"やり取りを重ねるたびに積み上がる"| r2 --> r3
  r3 --> limit["⚠️ 利用制限 / 追加課金に到達"]

やり取りを繰り返すだけで、知らないうちにトークン消費量が指数的に膨らむ構造になっています。

トークンとコンテキストウィンドウの仕組みをわかりやすく解説

「トークン」という言葉は技術的に聞こえますが、概念自体はシンプルです。

トークンとは何か

トークンとは、AIが文章を処理するときの「最小単位」です。英語では単語 1 つがおおよそ 1〜2 トークン、日本語では文字 1〜2 文字が 1 トークンに相当します。

わかりやすいたとえ：手紙の「文字数制限」に近いイメージです。AIへの入力と出力の合計文字数が多いほど、コストが高くなります。

コンテキストウィンドウとは何か

AIは過去の会話をそのまま覚えているわけではありません。毎回、「直近の会話の内容をまとめて一緒に送る」ことで文脈を理解しています。この「一度に送れる情報量の上限」がコンテキストウィンドウです。

mermaidflowchart TD
  window["コンテキストウィンドウ（上限あり）"]
  window --> inst["あなたの指示"]
  window --> hist["これまでの会話履歴"]
  window --> code["読み込んだコードファイル"]
  window --> tool["ツールの実行結果"]
  window --> web["Webから取得した情報"]

図のように、コンテキストウィンドウの中にはあらゆる情報が詰め込まれます。上限（Claude Sonnet 4.6 は 20 万トークン、Opus 4.8 は 20 万トークン）に近づくと、AIが古い情報を「忘れた」ように振る舞い始めるか、処理自体がエラーになります。

mermaidflowchart LR
  subgraph win["コンテキストウィンドウ（上限 200,000 トークン）"]
    direction LR
    inst["📝 指示・ルール\n10,000 T / 5%"] --> hist["💬 会話履歴\n50,000 T / 25%"] --> code["📄 コードファイル\n60,000 T / 30%"] --> tool["⚙️ ツール実行結果\n70,000 T / 35%"] --> rem["🔴 残り\n10,000 T / 5%"]
  end
  rem --> warn["⚠️ 上限間近\nAI が過去の指示を忘れ始める"]

左から右へ情報が積み上がっていき、残り容量がわずか 5% になった状態です。この状態でコンプレッションが走ると、過去の決定や指示の詳細が失われます。

開発作業でトークンが大量消費される原因

実際に試したところ、AIコーディングエージェントを使った開発では、想定よりはるかに多くのトークンが消費されることがわかりました。

原因は「ツールの呼び出し結果がそのままコンテキストに追加される」という仕組みにあります。

mermaidsequenceDiagram
  participant Dev as 開発者
  participant Agent as AIエージェント
  participant Ctx as コンテキスト（上限あり）

  Dev->>Agent: このファイルを読んで修正して
  Agent->>Ctx: ファイル全文を追加（+100KB〜）
  Dev->>Agent: テストを実行して
  Agent->>Ctx: テスト出力を追加（+300KB〜）
  Dev->>Agent: 依存パッケージを確認して
  Agent->>Ctx: npm list の出力を追加（+200KB〜）
  Note over Ctx: ⚠️ 上限に近づく
  Agent->>Dev: 精度低下・コンプレッション発生

npm test の出力・大きなファイルの読み込み・ls -la の結果・Web フェッチの内容——これらはすべてそのままコンテキストに積み重なります。

実際の計測値として、1 回の npm test 実行で数十万バイト、大型リポジトリのファイル読み込みで数百 KB がコンテキストに流れ込むことは珍しくありません。数十分の作業で数百万トークンに達するケースも確認しています。

つまずきやすい点：コンテキスト枯渇は「AIの性能が落ちた」のではなく「情報量が上限に達した」構造上の問題です。どれだけ高性能なモデルを使っても、コンテキストが埋まれば同じ結果になります。

context-mode のサンドボックスによるトークン節約の仕組み

context-mode は「ツールの出力をサンドボックス内で処理し、必要な結果だけをコンテキストに返す」という方法でトークンを削減します。

通常の処理との違い

mermaidflowchart LR
  subgraph normal["❌ 通常の処理"]
    direction LR
    A1["ツールを呼び出す"] --> B1["生の出力がそのまま届く\n（数百KB）"]
    B1 --> C1["コンテキストに全量追加"]
  end

  subgraph ctx["✅ context-mode を使った処理"]
    direction LR
    A2["ctx_execute などを呼び出す"] --> B2["サンドボックス内で処理"]
    B2 --> C2["console.log した内容だけ返す\n（数百B〜数KB）"]
    C2 --> D2["コンテキストへの追加は最小限"]
  end

  normal ~~~ ctx

上図のように、通常の処理では生の出力がそのままコンテキストに入るのに対し、context-mode ではサンドボックスで処理したあと「コードが出力した内容だけ」がコンテキストに返ります。

mermaidflowchart LR
  subgraph ng["❌ 通常の処理"]
    direction TB
    cmd1["npm test 実行"] --> raw["生の出力\n300 KB\nそのままコンテキストへ"]
  end
  subgraph ok["✅ context-mode 使用時"]
    direction TB
    cmd2["ctx_batch_execute"] --> sb["サンドボックスで処理"] --> res["必要な結果のみ\n62 KB（94% 削減）"]
  end
  ng ~~~ ok

同じ操作でも、context-mode を経由するだけで左から右へとコンテキスト流入量が大幅に変わります。

検索・インデックス機能によるさらなる節約

context-mode のもう一つの仕組みが「FTS5 インデックス」による検索です。大きなドキュメントや複数ファイルを一度インデックス化しておけば、次回以降は検索クエリに一致した部分だけを取得できます。

mermaidflowchart LR
  doc["大量のドキュメント・ファイル<br/>（数MB規模）"]
  doc --> idx["ctx_index でインデックス化<br/>（1回だけ）"]
  idx --> db["FTS5 ナレッジベース<br/>（ローカル保存）"]
  db --> search["ctx_search で必要な部分だけ取得<br/>（数百B）"]
  search --> ctx["コンテキストに追加"]

たとえば 60KB のドキュメントをそのままコンテキストに読み込む代わりに、インデックス化してから検索すると、コンテキストへの追加は 40B 程度で済みます。1,500 分の 1 以下への圧縮です。

mermaidflowchart LR
  doc["📄 ドキュメント\n60 KB"]
  doc -->|"ctx_index\n（初回のみ）"| fts[("🗄️ FTS5\nナレッジベース\nローカル保存")]
  fts -->|"ctx_search\n検索クエリ"| hit["🔍 関連部分のみ\n40 B"]
  hit --> ctx["📥 コンテキストへ追加\n60 KB → 40 B\n1,500 分の 1 に圧縮"]

一度インデックス化しておけば、以降は検索クエリで関連部分だけを取得でき、ドキュメント全体をコンテキストに読み込む必要がなくなります。

ツール別の削減効果と実測値

context-mode の各ツールが実際にどれだけトークンを削減するか、公式の計測値をまとめます。

ツール	用途	通常の消費量	context-mode 使用後	削減率
`ctx_batch_execute`	コマンド並列実行 + 検索	986 KB	62 KB	約 94%
`ctx_execute`	サンドボックスでコード実行	56 KB	299 B	約 99.5%
`ctx_execute_file`	ファイルをサンドボックスで処理	45 KB	155 B	約 99.7%
`ctx_index`	ドキュメントのインデックス化	60 KB	40 B	約 99.9%
`ctx_fetch_and_index`	URL 取得 + インデックス化	60 KB	40 B	約 99.9%
`ctx_search`	インデックスから検索	（再取得不要）	オンデマンド取得	—

数字だけ見ると実感しにくいですが、1 回のコマンド実行で 900KB 以上節約できるということは、1 回の操作でおよそ 22 万トークン前後の削減に相当します（日本語混じりのテキストを想定した場合）。

mermaidxychart-beta
  title "ツール別 コンテキスト削減率（%）"
  x-axis ["ctx_batch_execute", "ctx_execute", "ctx_execute_file", "ctx_index", "ctx_fetch_and_index"]
  y-axis "削減率（%）" 90 --> 100
  bar [94, 99.5, 99.7, 99.9, 99.9]

いずれのツールも 94〜99.9% の削減率を達成しており、最も効果が大きいのは ctx_index と ctx_fetch_and_index です。

トークン節約が開発コスト・リードタイムに与える影響

トークンが減ることの恩恵は、単純な費用削減にとどまりません。

コスト削減

API 従量課金の場合、トークン数が直接費用に比例します。たとえば 1 セッションで 100 万トークン消費するところを 20 万トークンで済むなら、API 費用は単純計算で 80% 削減できます。チームで複数人が毎日 AI を使う環境では、月次で数十万円規模の差が出ることもあります。

セッション安定化による再作業の削減

コンテキストが枯渇すると、AIは過去の指示や決定を「忘れた」状態になります。このとき開発者は、

状況を再説明する
セッションを再起動して最初からやり直す
AIの誤った判断を修正する

という再作業が発生します。context-mode を使うとコンテキスト消費が抑えられるため、長時間のセッションでも精度が維持され、この再作業コストが大きく減ります。

mermaidflowchart LR
  saving["トークン節約"] --> cost["API 費用の削減"]
  saving --> stable["セッションの安定化"]
  stable --> focus["AIが指示に集中し続ける"]
  focus --> quality["コードの品質・一貫性を維持"]
  cost --> budget["開発予算の最適化"]
  quality --> rework["再作業・修正コストの削減"]
  budget --> lead["リードタイム短縮"]
  rework --> lead

リードタイム短縮の考え方

リードタイム（開発着手から完成までの時間）は、純粋なコーディング時間だけで決まりません。AIとのやり取りの中断・再起動・再説明にかかる時間も含まれます。context-mode によってセッションが安定することで、この「非生産的な待ち時間」が削減され、実質的なリードタイムが短縮されます。

仕組み別削減効果まとめ（詳細）

どの場面でどのツールが効くか、用途別にまとめます。

用途・場面	推奨ツール	節約の仕組み	効果の大きさ
シェルコマンド実行（ビルド・テスト）	`ctx_batch_execute`	出力をサンドボックス処理	大（数百KB → 数十KB）
ファイル分析・集計	`ctx_execute_file`	ファイルをサンドボックスで処理、生バイト非公開	大（数十KB → 数百B）
ドキュメント・仕様書の参照	`ctx_index` + `ctx_search`	インデックス化＋必要部分だけ取得	特大（60KB → 40B）
外部 API・ドキュメントサイトの参照	`ctx_fetch_and_index`	キャッシュ付きインデックス（デフォルト 24h）	特大（60KB → 40B）
コード処理・フィルタリング	`ctx_execute`	標準出力だけがコンテキストに入る	大（56KB → 299B）

導入前後の変化イメージ

mermaidflowchart LR
  subgraph before["❌ 導入前（通常の開発）"]
    direction TB
    b0["📝 指示"] --> b1["📄 ファイル読込\n+100 KB"]
    b1 --> b2["⚙️ テスト実行\n+300 KB"]
    b2 --> b3["📦 依存確認\n+200 KB"]
    b3 --> bx["💥 合計 600 KB+\nコンテキスト圧迫"]
  end

  subgraph after["✅ 導入後（context-mode）"]
    direction TB
    a0["📝 指示"] --> a1["ctx_execute_file\n+155 B"]
    a1 --> a2["ctx_batch_execute\n+62 KB"]
    a2 --> a3["ctx_search\n必要箇所のみ"]
    a3 --> ax["🟢 合計 ~62 KB\nコンテキスト余裕あり"]
  end

  before ~~~ after