AIのトークンコストを節約する：文脈を細く保つ3系統の実践

結論：文脈を細くする3系統を順番で選ぶ

AIのトークンコストを節約するとき、指示をむやみに短くする必要はありません。先に削るべきなのは、判断に使わない情報と、同じ内容の重複です。

取り組む順番は、次の3系統です。

1. 入力を絞る：目的に関係する資料だけを渡す。
2. 途中経過を圧縮する：長い会話を決定事項へ置き換える。
3. 役割を分ける：検索や集計と、重い判断を別の工程にする。

まずは、いま困っている症状を次の表に当てはめてください。

文脈が膨らむ場所	使う系統	最初の一手	削らない情報
最初から資料が多い	入力を絞る	目的・対象・終了条件を3行にする	原因判断に必要な原文
会話の往復で長くなった	途中経過を圧縮する	決定事項メモへ置き換える	制約、検証済みと未確認の境界
全工程を同じ会話へ任せている	役割を分ける	検索と判断を二段階にする	受け渡し先の完了条件

迷ったら、入力を絞るところから始めます。長期作業だけ途中経過を圧縮します。それでも大きな検索結果やログが残る場合に、役割を分けます。

トークンは、AIが文章などを処理する細かな単位です。日本語の一文字が一トークンになるとは限りません。英単語、記号、コード、モデルによって区切り方が変わります。

しかも、入力になるのは文字だけではありません。Googleの公式説明では、Gemini APIでテキストのほか、画像、動画、音声もトークンとして数えます。送信前の入力はcount_tokens、応答後の内訳はusageで確認できます。詳しい項目はGemini APIのトークン解説にまとまっています。

コンテキスト（＝AIが今回参照できる情報）も覚えておきたい言葉です。長い会話では、過去の指示、貼り付けた資料、AIの返答、ツールの結果などが次の処理へ含まれることがあります。

Claude Platformの公式説明では、コンテキストウィンドウを「回答を作るときの作業記憶」として扱い、生成する回答もその範囲に含めています。また、文脈は大きいほど常によいわけではありません。情報が増えると、正確さや必要な情報の思い出しやすさが下がる場合もあると説明しています。詳しくはContext windowsで確認できます。

つまり、節約の目的は「AIに渡す情報を少なくすること」ではありません。必要な情報を見つけやすくし、仕事が完了するまでの無駄を減らすことです。

1回の安さより、完了までの合計を測る

一つの返答が短くても、前提不足で何度も聞き直せば合計は増えます。最初に小さな依頼票を渡し、一往復で終わる方が軽い場合もあります。

APIを使っているなら、サービスが返す使用量を記録します。チャット製品で細かな内訳が見えない場合だけ、文字数、添付ファイル数、往復回数、完了時間を代理の指標にします。

記録する項目	何が分かるか	記録例
入力トークン	渡した文脈の大きさ	3,200
出力トークン	返答の大きさ	900
キャッシュ	再利用された入力の量	1,100
思考・ツール使用	製品が表示する追加の使用量	表示あり
往復回数	前提不足や手戻り	3回
完了可否	安くても未完成ではないか	テスト成功
完了時間	人の待ち時間も減ったか	18分
手戻り理由	次に直す場所	対象OSの指定漏れ

表示される項目は、サービスによって異なります。たとえばGemini APIの公式案内では、入力、出力、思考、キャッシュ、ツール使用、合計を応答後のusageで確認できます。2026-07-27時点の仕様なので、実際に使うときは公式案内を再確認してください。

次は、同じREADME修正を頼んだと仮定した説明用の計算例です。実測値ではありません。一般的な削減率を示すものでもありません。

依頼方法	初回入力	追加の往復	合計入力	合計出力	完了
「短く直して」だけ送る	120	4回	2,300	1,900	済
目的・読者・終了条件を送る	650	1回	1,050	900	済

この例では、2番目の方法は初回入力が530トークン増えています。一方で、合計入力は1,250、合計出力は1,000少なくなりました。

大事なのは、この数字をそのまま自分の削減率にしないことです。同じ作業、同じ資料、同じ完了条件で変更前後を比べます。安くなっても、テスト失敗や事実誤認が増えた方法は採用しません。

OpenAIのモデル活用ガイドも、繰り返しの指示や不要な例を減らし、ツール説明を簡潔にする考え方を示しています。同ページにはGPT-5.6を使った内部のcoding-agent評価例もあります。ただし、その数値は一般的な節約率ではありません。自分の代表的な作業で、品質と総使用量を測る必要があります。

系統1：入力を絞り、必要な資料だけを渡す

入力を絞るとは、情報を隠すことではありません。今回の判断に使う資料を先に選び、関係の薄い資料を待機させることです。

冒頭を「目的・対象・終了条件」の3行にする

長い背景説明の前に、仕事の輪郭を置きます。

目的：ログインエラーの原因を一つに絞る。
対象：src/login.tsと最初のエラー周辺だけ。
終了条件：原因候補、根拠、次に試すコマンドを返す。

この3行は、現在地、目的地、到着条件に当たります。AIは何を探し、どこで返答を終えればよいか判断しやすくなります。

「詳しく教えて」「最高の案を全部出して」だけでは、出力の終点がありません。必要な件数、項目、長さ、形式を指定します。

原因候補を可能性の高い順に3件。
各候補に、根拠・確認方法・外れた場合の次の一手を書く。
各項目は2文以内。

単に「短く」と頼むより、必要な項目を先に示す方が安全です。短さだけを指定すると、根拠や確認方法まで省かれることがあるからです。

全文の前に索引を渡す

大きなリポジトリや長い資料を、最初から全部貼る必要はありません。先にファイル名、見出し、検索結果などの索引を作ります。関係する候補が分かってから、必要な範囲だけを開きます。

ローカルのコードなら、PowerShellで次のように絞れます。

rg --files src tests
rg -n "login|session|token" src tests

rgは、複数のファイルから文字を探す検索道具です。図書館の本を全ページ読む前に、蔵書検索で棚を絞る作業に似ています。

検索結果だけで原因を決めてはいけません。候補が2件に絞れたら、その2件の必要なコードを読みます。テストや設定ファイルが関係するなら、それも追加します。

長いログは、エラーの周辺を切り出します。

Select-String -Path ".\logs\app.log" -Pattern "ERROR" -Context 5,10

ただし、最初のエラーを消さないでください。後に出たエラーは、最初の失敗から連鎖した結果かもしれません。

ログを絞るときは、次の情報を残します。

1. エラーが起きた時刻。
2. 直前に行った操作。
3. 最初に出たエラーの全文。
4. 同じ問題を起こす手順。
5. 成功した環境と失敗した環境の違い。

2回目以降は全文ではなく差分を渡す

同じ仕様や原稿を毎回貼り直すと、重複した文脈が増えます。前回から変わった点だけをまとめます。

前回からの変更：
- 保存先をローカルだけに限定
- 対応OSにWindows 10を追加
- 公開機能は今回の範囲外

前回案のうち、手順3とテスト項目だけ更新する。

コードなら、git diffで変更部分を確認できます。

git diff -- src/login.ts tests/login.test.ts

差分は、地図全体ではなく工事した道路だけを示します。レビューする側は、変更していないコードの説明を減らし、変更の意図と副作用へ集中できます。

ただし、新しい会話のAIが前回の内容を持っているとは限りません。新しい会話では、短い引き継ぎと差分をセットにします。前回の全文を覚えている前提で「さっきの続き」とだけ書かないようにします。

共通指示へ何でも詰め込まない

毎回同じ背景を手入力する作業は、短いテンプレートに移せます。

【目的】
【入力】
【変更してよい範囲】
【出力形式】
【合格条件】
【してはいけないこと】

テンプレートは、情報を増やすためではありません。必要な項目の漏れを防ぐための小さなチェックリストです。

5回ほど使って空欄が続く項目は外します。毎回追加している項目は、共通項目へ移します。こうすると、短さと情報不足の両方を調整できます。

製品に専用機能がある場合は、対象にだけ効く指示も使えます。たとえばGitHub Copilotの応答カスタマイズには、個人、リポジトリ、組織の指示に加え、特定のパスだけへ適用する指示が説明されています。

パス固有の指示なら、テスト用の決まりをすべてのファイルへ読ませずに済みます。ただし、これはGitHub Copilotの製品機能です。すべてのAIサービスで同じ設定が使えるわけではありません。再利用できるprompt fileも、2026-07-27時点では公開プレビューです。使う前に公式案内を確認してください。

系統2：長い途中経過を決定事項へ圧縮する

会話が長くなったら、過去の発言を時系列で短くするのではなく、いま有効な状態へまとめ直します。

古い仮説、撤回した案、途中の言い間違いをすべて残すと、要約しても判断が散らかります。次の担当者が元の会話を読まずに再開できる「決定事項メモ」を作ります。

【引き継ぎ】
目的：ログイン失敗の修正
決定済み：メール認証を維持。新しい依存は追加しない
制約：公開設定と本番データは変更しない
変更済み：src/login.tsの例外処理
検証済み：単体テスト12件に成功
未確認：実ブラウザでの再ログイン
次の一手：既存E2Eテストを1件追加
参照先：src/login.ts、tests/login.test.ts

良い引き継ぎには、結論だけでなく、変えてはいけない条件があります。「検証済み」と「未確認」も分けます。ここが混ざると、次の担当が未確認の内容を事実として扱うおそれがあります。

採用しなかった案は、基本的に削ります。ただし、同じ失敗を繰り返す可能性がある場合は、理由を1行だけ残します。

不採用：新しい認証ライブラリの追加
理由：今回の範囲外で、既存テストへの影響が大きいため

新しい会話へ移る基準

次の3つのうち、どれかが変わったら区切りを検討します。

1. 目的が変わった。
2. 対象ファイルや対象資料が変わった。
3. 終了条件が変わった。

たとえば、ログインエラーの原因調査から、会員登録画面のデザイン変更へ移るなら別の仕事です。前の会話から必要な制約だけを引き継ぎ、新しい会話へ分けた方が整理しやすくなります。

反対に、同じ不具合の原因候補を一つずつ確認している間は、同じ会話を続けてもかまいません。分けすぎると、毎回同じ前提を送り直す費用が増えます。

簡単な判断方法は、「目的・対象・終了条件が同じか」です。3つとも同じなら続けます。どれかが変わったら、決定事項メモを作って分けます。

手動の要約と製品の自動圧縮は別

ここまで説明した引き継ぎは、人がどのチャット製品でも使える手動の整理方法です。一方で、APIや一部の製品には、会話履歴を自動で圧縮する機能があります。

Claude PlatformのContext editingでは、古いツール結果などを選択的に外す方法と、会話履歴を要約へ置き換えるcompaction（＝圧縮）が説明されています。これはClaude Platformの機能です。すべてのチャット製品に同じ仕組みがあるわけではありません。

自動圧縮を使う場合も、次の3点を確認します。

1. 禁止事項や環境条件が要約に残っているか。
2. 検証済みと未確認が混ざっていないか。
3. ファイル名、コマンド、数値が変わっていないか。

自動要約は便利ですが、元の履歴を正しく理解した保証にはなりません。元資料は消さず、必要なときに戻れる参照先として残します。

系統3：検索・機械処理と重い判断を分ける

入力を絞り、途中経過を圧縮しても、大きな検索結果や大量のログが残ることがあります。その場合は、機械で確認できる前処理と、人の目的を考える重い判断を分けます。

工程	仕事の例	確認方法
機械処理	一覧化、検索、形式変換、絞り込み、重複除去、集計	件数、形式、再実行結果
重い判断	設計比較、原因の特定、重要文章の最終確認	根拠、反例、合格条件

たとえば、先に検索コマンドで候補ファイルを100件から5件へ絞ります。その5件と検索条件だけを使い、原因分析を依頼します。

これは、判断をすべて性能の低いモデルへ移す話ではありません。高い判断力が必要な範囲を細くし、その範囲へ必要な資料を集める方法です。

OpenAIの公式ガイドも、大きな中間出力をコードで絞り込み、結合、順位付け、重複除去、集計、検証し、小さな構造化結果へする考え方を示しています。一方で、1回で済む作業や、一つの結果を見て次の判断を変える作業は、分割しすぎない方がよいと説明しています。

受け渡しは会話全文ではなく状態を渡す

前処理から判断工程へは、次の6項目を渡します。

目的：ログイン失敗の原因候補を絞る
対象：src/login.ts、該当テスト、最初のエラー
縮約結果：候補ファイル2件、該当行6か所
検証済み：再現コマンドで同じエラーを確認
未確認：ブラウザ保存データの影響
完了条件：原因候補と次の確認手順を3件以内で返す

元のログやコードは削除しません。参照先として保管します。判断工程が追加の根拠を必要とした場合だけ、その範囲を開きます。

次の条件が2つ以上あるときは、役割分担を検討しやすくなります。

• 入力資料が、独立した複数の集合に分かれる。
• 検索や重複除去など、結果を機械で確認できる前処理がある。
• 設計や原因分析など、判断へ集中させたい工程がある。
• 同じ型の作業が今後3回以上あり、依頼票を再利用できる。

5分で終わる一回作業を、無理に3工程へ分ける必要はありません。依頼票の作成、結果の統合、再確認にも時間とトークンがかかります。分割前後で完了時間まで比べてください。

削ってはいけない情報

文脈を細くしても、次の情報は残します。

1. 目的と利用者：何のために、誰が結果を使うか。
2. 合格条件：何を確認すれば仕事が終わるか。
3. 禁止事項と制約：変更禁止、公開禁止、期限、対象環境。
4. 原因判断の元データ：最初のエラー、再現手順、必要なコード。
5. 採用済みの決定：古い案と現在の方針を混同しないための結論。
6. 確認の境界：検証済みと未確認を分ける情報。

エラーの一行だけを貼り、OSや直前操作を隠すと、AIは不足部分を推測するしかありません。記事の一段落だけを渡し、読者像を省いた場合も同じです。

不要な情報を削ることと、判断材料を欠くことは違います。削ってよいか迷ったら、「この情報がないと原因、制約、完了を判断できるか」と考えます。判断できないなら残します。

キャッシュは文脈の削除ではない

キャッシュ（＝同じ入力を再利用する仕組み）は、手動の要約や自動圧縮とは別です。

Gemini APIのContext cachingでは、大きく共通する内容を入力の先頭へ置き、似た接頭辞の依頼を短い間隔で送る方法が案内されています。命中したトークン数はusage.total_cached_tokensで確認できます。

ただし、キャッシュへ命中しても、その入力がコンテキストから消えるわけではありません。次の3つを分けて考えます。

見るもの	キャッシュで起こり得ること	別に確認すること
費用や待ち時間	同じ入力の再処理が効率化される	最新の料金と保持条件
文脈量	入力はモデルが参照する文脈に残り得る	不要情報を手動で外せるか
回答品質	共通の前提を再利用できる	古い前提やノイズが残っていないか

対応モデル、最小入力長、保持時間、料金、使用量の項目名は変わる可能性があります。2026-07-27時点の公式案内だけで将来の仕様を固定せず、利用時の公式ページで確認してください。

カスタム指示も別の仕組みです。毎回同じ前提を自動で追加できますが、追加された内容は入力の一部になります。古い指示や関係のない指示が増えていないか、定期的に見直します。

最後に、安全の条件を分けておきます。秘密鍵、パスワード、認証トークン、個人情報をAIへ貼らないことは、トークン節約とは別の問題です。ログを切り出す前に、秘密や個人を特定できる値が入っていないか確認してください。

よくある質問

指示は短いほどトークンを節約できますか？

短さだけでは決まりません。重複した背景、使わない例、関係のない資料は外せます。一方で、目的、対象、制約、合格条件を削ると、AIが確認の質問を増やしたり、別の作業を始めたりします。

同じ作業を、同じ完了条件で比べてください。入力だけでなく、出力、往復、完了時間、手戻りも合計します。短くした結果、修正が増えたなら節約になっていません。

新しい会話へ移るのはいつですか？

目的、対象、終了条件のどれかが変わったときが分かりやすい区切りです。履歴が長くなり、決定事項メモだけで再開できる状態になったときも移れます。

移る前に、制約、変更済み、検証済み、未確認、次の一手、参照先を残します。前の会話がなくても作業を始められるか、一度読み直してください。

キャッシュがあれば長い文脈を減らさなくてもよいですか？

キャッシュは、同じ入力の再処理にかかる費用や待ち時間を下げるための製品機能です。不要な情報を自動で選別し、回答の焦点を整える機能とは限りません。

費用が下がっても、古い前提が文脈に残れば判断を邪魔することがあります。キャッシュの命中、文脈の整理、回答品質は別々に確認します。

トークン数はどこで確認できますか？

APIでは、送信前のcount_tokensに相当する機能や、応答後のusage欄を使います。項目名はサービスごとに違います。

入力と出力だけでなく、思考、キャッシュ、ツール使用、合計のどこまで表示されるかを確認してください。細かな使用量を取得できないチャット製品では、文字数、添付数、往復、時間を代理の記録にします。

役割を分ければ必ず安くなりますか？

分割には、依頼票の作成、成果の統合、再確認が必要です。短い一回作業では、その手間の方が大きくなる場合があります。

役割分担が向くのは、検索、一覧化、重複除去などを機械で確認でき、大きな中間結果を小さな構造へ縮められる場合です。各結果を見て次の判断が変わる仕事は、一つの流れで進めた方が分かりやすいこともあります。

公式一次情報

確認日: 2026-07-27

• Model guidance | OpenAI API: 指示の重複を減らす考え方と、大きな中間出力を機械処理で縮約する方法が説明されています。
• Context editing - Claude Platform Docs: 古いツール結果を外す方法と、会話履歴を要約へ置き換えるcompactionが説明されています。
• Context windows - Claude Platform Docs: コンテキストを回答時の作業記憶として扱い、残す情報を選ぶ重要性が説明されています。
• Understand and count tokens | Gemini API | Google AI for Developers: 送信前のトークン計測と、応答後に確認できる使用量の内訳が説明されています。
• Context caching | Gemini API | Google AI for Developers: 共通する入力を再利用するキャッシュと、命中トークンの確認方法が説明されています。
• About customizing GitHub Copilot responses - GitHub Docs: 共通指示、パス固有指示、再利用するprompt fileの使い分けが説明されています。

まとめ

トークン節約は、文章を無理に短くする競技ではありません。必要な情報を見つけやすくし、完了までの手戻りを減らす取り組みです。

まず、いま続いている長い作業を一つ選びます。次の3つだけを実行してください。

• 目的・対象・終了条件を固定する：冒頭の3行へ書き、使わない資料は参照先へ退避します。
• 決定事項と未完了を要約する：制約、検証済み、未確認、次の一手を引き継ぎへ残します。
• 同じ完了条件で比較する：入力、出力、往復、時間、完了可否を記録し、品質が落ちた方法は採用しません。