.NETやAzure・Microsoft製品で学んだことや気づいたことを共有しよう

@ochtum(オクトゥム)Team Coffee

トークンをケチるな、設計しろ：GitHub Copilotを賢く使うコンテキスト戦略

Last updated at 2026-07-01Posted at 2026-07-01

※お役に立てたらストック、いいねをよろしくお願いします！！

＜📝本記事のターゲット層＞

GitHub Copilot ChatやAgent modeを業務で使い始めた方
MCPやAgent Skillsを導入している、または導入を検討している方
AGENTS.md や設計文書の置き場所に迷っている方
AI開発の速度・品質・コストを管理するテックリード
AIによる自動化と人間によるレビューの境界を設計したい方

.NETラボの2026年6月勉強会での登壇資料はこちら

GitHub Copilotを使い始めた頃は、次のようなことが気になります。

どう質問すれば、正しいコードを書いてくれるのか
どこまで具体的に指示すればよいのか
プロンプトを短くした方がよいのか
何度もやり直すのは、質問の仕方が悪いからなのか

もちろん、質問の仕方は大切です。

しかし、Copilot Chat、Agent mode、MCP、Agent Skills、カスタム指示などを使い込むほど、課題は少しずつ変わっていきます。

「どう質問するか」だけでなく、何をAIに読ませるかが重要になります。

たとえば、AIが意図と違う実装をしたとします。この原因は、必ずしもプロンプトが下手だったからとは限りません。

必要な設計文書を読んでいなかった
関係のないツールが大量に提示されていた
検索結果やコマンド出力が長すぎた
古い会話履歴に引っ張られた
重要な制約が巨大な指示ファイルに埋もれていた
AIへ任せるべきではない判断まで自動化していた

このような問題は、プロンプトの言い回しだけでは解決できません。

AIが作業するときに使う情報全体、つまりコンテキストを設計する必要があります。

本記事で一番お伝えしたいことは、次の一文です。

トークンを減らすことが目的ではありません。AIが良い判断をするための情報を、適切なタイミングと粒度で渡すことが目的です。

単にトークンを削るだけでは、必要な設計情報やレビューまで失いかねません。逆に、念のために全資料を渡せば、コストだけでなく判断のノイズも増えます。

そこで本記事では、GitHub Copilotへ渡る情報を次のように分解します。

常に守る固定指示
特定作業で使う手順
必要時に読むデザインシステムや設計知識
利用可能なツールの定義
ツールの実行結果
会話履歴
キャッシュや圧縮で再利用する情報
タスクに合わせたモデル選択

そのうえで、MCP、Skills、AGENTS.md、DESIGN.md、CLI、モデル選択をどう使い分けるか、初心者の方にも分かるように整理します。

🔷1. トークンは質問文だけで増えるわけではない

最初に、トークンとコンテキストの基本を整理しましょう。

生成AIへ入力する文章は、小さな単位へ分割されて処理されます。この単位がトークンです。

日本語では、必ずしも「1文字＝1トークン」ではありません。英単語、記号、コード、JSON、ファイルパスなども、モデルの方式に応じて複数のトークンへ分割されます。

ただし、実務で毎回「この文字列は何トークンか」を手計算する必要はありません。

重要なのは、質問文以外にも多くの情報がモデルへ渡ることです。

🔹コンテキストウィンドウはAIの作業机

コンテキストウィンドウは、AIが今回の処理で参照できる情報の範囲です。

初心者向けには、AIの作業机と考えると分かりやすいです。

作業机には、ユーザーが入力した質問だけでなく、次のようなものが載ります。

システム側の指示
AGENTS.md などのカスタム指示
利用できるツールの名前・説明・入力スキーマ
ユーザーの質問
AIの過去の回答
読み込んだソースコードや設計書
ツール呼び出しの引数
検索結果、ログ、JSONなどのツール実行結果
最終的に生成する回答

次の図は、これらの情報が一つのコンテキストウィンドウを共有する様子を表しています。

GitHub Copilotのコンテキストは、質問文だけでなく指示・ツール・実行結果・会話履歴の合計で消費される。

ここで注目したいのが、ツールの実行結果です。

ツール呼び出し自体は、ツール名と短い引数だけで済むことがあります。しかし、その結果として次のような情報が返ると、一気にコンテキストを使います。

Slackのメッセージ500件
GitHub Issue 200件
数万行のビルドログ
ソースコードの全ファイル
データベース検索結果1000行
巨大なJSONレスポンス

質問文を20文字短くするより、不要な検索結果を500件から20件に減らした方が、はるかに効果が大きい場合があります。

つまり、トークンを考えるときは「プロンプトを短くする」だけでは不十分です。

AIが常に持つ情報と、作業中に追加される情報の両方を見ます。

🔹入力トークン・出力トークン・キャッシュトークンの違い

「トークン」という言葉は、いくつかの意味で使われます。混乱しやすいので分けておきましょう。

用語	意味
コンテキストウィンドウ	モデルが一度に参照できる情報の範囲
入力トークン	モデルへ渡された指示、質問、履歴、ツール定義、ツール結果など
出力トークン	モデルが生成した説明、コード、要約など
キャッシュトークン	以前のリクエストと共通し、再利用された入力部分
料金・AI Credits	製品、モデル、契約、キャッシュ単価などを基に算出される利用量

ここで大切なのは、コンテキスト量と料金は完全に同じ概念ではないことです。

たとえば、同じ長い固定指示を毎回モデルへ渡していても、Prompt Cachingが効けば、通常の入力とは異なる単価や計算方法になることがあります。

一方で、キャッシュされたからといって、不要な情報がAIの判断へ与える影響まで消えるわけではありません。

「課金上は安く再利用できる」と「AIへ読ませる価値がある」は別の判断です。

なお、GitHub Copilotの料金体系は変更される可能性があります。2026年6月1日以降の料金説明ではAI Creditsとトークン利用量の関係が案内されていますが、記事を読む時点の最新情報は、GitHub Copilotのモデルと料金を確認してください。

固定の単価を記事へ書き込むと、将来の料金改定で内容が古くなります。そのため、本記事では仕組みと判断方法を中心に扱います。

🔹MCP通信が発生しただけでは、LLMトークンとは限らない

もう一つ、最初に区別しておきたいことがあります。

MCPの通信やローカルコマンドの実行そのものと、LLMのトークン消費は同じではありません。

たとえば、MCPクライアントがMCPサーバーへ tools/list を送り、ツール一覧を取得したとします。

MCPクライアント
    ↓ tools/list
MCPサーバー
    ↓ ツール一覧
MCPクライアント

これはMCPのRPC通信です。

取得したツール一覧のうち、どの情報をモデルへ渡すかは、クライアントやエージェントランタイムの実装に左右されます。

モデルへ渡された場合は、ツール名、description、input schemaなどが入力コンテキストへ影響します。一方、クライアント内部に保持されるだけでモデルへ渡されない情報は、そのままLLM入力トークンになるとは限りません。

したがって、次のように考えると整理しやすいです。

通信が発生した
    ↓
クライアントが情報を取得した
    ↓
その情報をモデルへ渡した
    ↓
モデルの入力コンテキストへ影響する

「MCPへ接続した瞬間に、すべての定義とリソース本文が毎回モデルへ渡る」と一律に説明するのは正確ではありません。

ただし、AIがツールを選ぶには、何らかの形で利用可能なツールの情報を知る必要があります。そのため、ツール数やschemaの大きさは、コンテキスト設計上の重要な観点です。

🔹最適化する前に観測する

トークンを減らしたいとき、いきなり指示ファイルを短くするのはおすすめしません。

まずは、どこが膨らんでいるかを観測します。

GitHub Copilot CLIでは、コンテキストや使用量を確認するためのコマンドが提供されています。

/context

現在のコンテキストウィンドウの使用状況を確認します。

/usage

セッションの利用量やモデル別のトークン情報などを確認します。

/compact

長くなった会話履歴を要約し、コンテキストを圧縮します。

コマンドの対応状況や表示内容は製品更新で変わる可能性があるため、GitHub Copilot CLIのコンテキスト管理も併せて確認してください。

▸観測するときのポイント

同じ作業を、次の条件で比較すると原因を見つけやすくなります。

比較	確認すること
MCP有効／無効	ツール定義の追加で固定領域がどれだけ変わるか
検索結果500件／20件	ツール結果がコンテキストへ与える影響
ファイル全文／該当範囲	読み込むファイル量の影響
長い会話／新しいセッション	会話履歴の蓄積による影響
圧縮前／`/compact` 後	履歴要約による変化
Auto／手動モデル指定	モデル選択で品質、速度、利用量がどう変わるか

モデル、設定、リポジトリ、質問をそろえて比較することが大切です。

複数の条件を一度に変えると、何が効いたのか分からなくなります。

💡 最初の結論

質問文だけを削るのではなく、固定指示、ツール定義、読み込んだファイル、ツール結果、会話履歴のどこが膨らんでいるかを確認しましょう。

🔷2. AGENTS.md・Skills・DESIGN.mdは情報の寿命で分ける

AIに必要な情報を整理するとき、すべてを一つの巨大な指示ファイルへ書きたくなることがあります。

「毎回読ませておけば、見落とさないだろう」という考えです。

しかし、これは人間の仕事に置き換えると、毎朝すべての就業規則、作業手順書、製品設計書、過去の議事録を読んでから仕事を始めるようなものです。

必要な情報は、情報の寿命と適用範囲で分けましょう。

ほぼすべての作業で守る情報
特定の作業だけで必要な情報
設計変更時だけ必要な情報
対象ファイルやディレクトリによって変わる情報
今回の依頼だけで必要な情報

🔹AGENTS.mdは「全知識の倉庫」ではなく入口

GitHub Copilotでは、AGENTS.md をエージェント向けの指示として利用できます。

ここでファイル名に注意してください。

AGENTS.md

複数形です。AGENT.md ではありません。

AGENTS.md へ置くのは、ほぼすべてのタスクで守る短いルールと、必要な資料への導線です。

たとえば、次のような内容です。

# Repository rules

- 回答とコードコメントは日本語で記述する。
- 既存の公開APIを変更する前に、影響範囲を列挙する。
- 作業後は変更対象に対応するテストを実行する。
- 無関係なファイルを変更しない。

# Architecture and design rules

- 公開APIを変更する前に `docs/adr/0002-api-versioning.md` を読む。
- UIの見た目を変更する前に `DESIGN.md` を読む。
- DBスキーマ変更では `docs/database/` の該当ADRを確認する。
- UIだけの変更ではバックエンド設計文書を読まない。

ポイントは、DESIGN.md の内容をすべてコピーしないことです。

AGENTS.md は、次のような役割を持つルーターにします。

今回のタスクは何か
    ↓
常に守るルールは何か
    ↓
追加で読むべき資料はあるか

この構成なら、通常の小さな変更では短い共通ルールだけを使い、設計変更時だけ詳細な資料を追加できます。

🔹Agent Skillsは必要時に開く作業手順書

Agent Skillsは、特定の作業に必要な手順、知識、スクリプト、参照資料などをまとめる仕組みです。

初心者向けには、専門作業のマニュアルと考えると分かりやすいです。

たとえば、次のような作業はSkillへ分けられます。

技術記事を作成する
セキュリティレビューを行う
リリースノートを作成する
データベース移行を検証する
図解を生成する
Azureへデプロイする

Skillでは、最初からすべての本文を常時読ませるのではなく、まずnameやdescriptionなどの情報を基に、タスクへ適用するか判断する設計が考えられます。

選択されたときに SKILL.md 本文や必要な参照ファイルを読みます。

▸Skillのdescriptionは発火条件を書く

悪い例です。

description: 開発を支援します

これでは、いつ使うSkillなのか分かりません。

良い例では、対象作業と利用条件を具体的にします。

description: >
  GitHub Copilotをテーマにした技術記事のセクション素案から、
  Qiita向けのMarkdown記事本文を作成するときに使用します。
  元ネタ、図解生成記録、文体ルールを参照します。

descriptionが曖昧だと、必要なSkillが選ばれなかったり、関係のないタスクで発火したりします。

これはトークンだけの問題ではありません。AIが間違った作業手順を適用する原因にもなります。

▸Skill本文を巨大化させない

SKILL.md へ、サンプルコード、全API仕様、過去の事例、長いチェックリストをすべて詰め込むと、発火時のコンテキストが大きくなります。

次のように分けると整理しやすくなります。

my-skill/
├─ SKILL.md
├─ scripts/
│  └─ validate.ps1
├─ references/
│  ├─ api-rules.md
│  └─ review-checklist.md
└─ assets/
   └─ template.md

SKILL.md には、作業の入口と判断手順を書きます。

詳細なAPI規約が必要になったときだけ references/api-rules.md を読み、検証処理は既存の scripts/validate.ps1 を実行します。

これにより、毎回すべてを読むのではなく、必要な情報だけを段階的に読み込めます。

🔹DESIGN.mdは必要時に参照

DESIGN.md は、Google Labsの公式リポジトリでは「coding agentsにvisual identityを説明するためのフォーマット」として公開されています。

つまり、アーキテクチャ設計書やDB設計書ではなく、AIにブランドやプロダクトの見た目を一貫して扱わせるためのデザインシステム文書です。

公式仕様では、DESIGN.md は主に次の二層で構成されます。

YAML front matter：機械可読なデザイントークン。必要に応じて付ける
Markdown body：人間にも読めるデザイン上の理由とガイダンス

YAML front matterには、次のようなトークンを定義できます。

version / name / description
colors
typography
rounded
spacing
components

色はCSSカラー値、サイズは px / em / rem などの単位付きDimensionとして書けます。{colors.primary} のようなトークン参照も使えます。

Markdown本文は、必要なセクションだけを書けます。公式仕様では、存在するセクションは次の順序にすることが推奨されています。

Overview
Colors
Typography
Layout
Elevation & Depth
Shapes
Components
Do's and Don'ts

ここで大事なのは、すべてのタスクで常時読み込ませる必要はないという点です。

DESIGN.md という名前を付けただけで、GitHub Copilotがすべてのタスクで必ず自動読込するとは限りません。一方で、プロンプトや AGENTS.md から明示的に参照させれば、GitHub CopilotでもUI生成やデザイン判断の文脈として利用できます。

そのため、AGENTS.md やSkillから条件付きで参照させます。

# AGENTS.md

- UIを新規作成する場合、または見た目を変更する場合は `DESIGN.md` を読む。
- 色、文字、余白、角丸、コンポーネント状態を決める場合は `DESIGN.md` の該当セクションを確認する。
- API、DB、認証認可の構造を変更する場合は、ADRや `docs/architecture.md` など別の設計文書を確認する。

この構成には二つの利点があります。

小さな変更でデザインシステム全文を毎回読ませずに済む
UIや見た目の判断では必要なトークンとガイダンスを確実に読ませられる

つまり、単に「読ませない」のではなく、読む条件を設計するわけです。

🔹三つの役割を図で整理する

次の図では、ユーザータスクが AGENTS.md を入口として、通常タスク、Skill、DESIGN.md などの参照資料へ分岐する流れを示しています。

常設ルールは短く保ち、専門手順とデザインシステムは必要なタスクでだけ読み込ませる。

役割を短くまとめると、次のようになります。

情報	役割	読ませるタイミング
`AGENTS.md`	常設ルールと参照先	対象タスクの入口
`SKILL.md`	特定作業の手順	該当する作業で発火したとき
`DESIGN.md`	デザインシステム	UIや見た目の判断が必要なとき
`*.instructions.md`	パス固有のルール	対象ファイルやディレクトリを扱うとき
ユーザープロンプト	今回だけの条件	その依頼を実行するとき

🔹どこへ書くか迷ったときの判断方法

次の質問を順番に使ってください。

▸質問1：ほぼ全タスクで必要ですか

Yesなら、AGENTS.md やリポジトリ共通のCopilot instructionsを候補にします。

例：

使用言語
テスト実行方針
無関係なファイルを変更しない
秘密情報を出力しない

▸質問2：特定種類の作業だけで必要ですか

Yesなら、Agent Skillを候補にします。

例：

記事作成手順
デプロイ手順
セキュリティスキャン手順
リリース作業

▸質問3：詳細な背景や設計理由ですか

Yesなら、内容に応じて置き場所を分けます。UIや見た目の判断なら DESIGN.md、アーキテクチャや過去の技術判断ならADRや docs/ 配下の設計文書を候補にします。

▸質問4：特定パスだけに適用しますか

Yesなら、パス固有のinstructionsや対象に近い AGENTS.md を候補にします。

▸質問5：今回の依頼だけで必要ですか

Yesなら、ユーザープロンプトやタスク文書へ書きます。

💡 配置の原則

ファイル名から決めるのではなく、情報の寿命と適用範囲から置き場所を決めましょう。

🔷3. MCPは接続数ではなく、定義と実行結果を設計する

MCPは、AIアプリケーションが外部のツールやデータへ接続するための共通プロトコルです。

MCPサーバーは、主に次の能力を公開します。

機能	内容
Tools	モデルが実行できる操作
Resources	ファイル、DBスキーマ、文書などのコンテキスト
Prompts	定型メッセージやワークフロー

MCPを使うと、GitHub、データベース、社内システム、ブラウザなどの機能をAIから利用しやすくなります。

一方、利用できるMCPサーバーやツールを無制限に増やすと、モデルが選択するための情報や、ツールの実行結果が大きくなる可能性があります。

ここでは、MCPを「つなぐか、つながないか」ではなく、何をモデルへ見せ、何を返すかで考えます。

🔹MCP通信とモデル入力を分ける

MCPサーバーとクライアントの間では、ツール一覧取得、リソース一覧取得、ツール実行、リソース読込などの通信が行われます。

概念的には、次のような流れです。

MCPサーバー
  ├─ Tools
  ├─ Resources
  └─ Prompts
        ↓ MCP通信
MCPクライアント / エージェントランタイム
        ↓ 必要な定義・本文・結果を選択
LLMのコンテキスト

MCPサーバーから返された情報を、クライアントがどこまでモデルへ渡すかは実装によって異なります。

したがって、次の二つを分けます。

MCP通信で取得された情報
実際にLLMへ渡された情報

LLMの入力へ影響する代表例は次のとおりです。

tool name
tool description
input schema
prompt本文
resource本文
tool callの引数
tool result

🔹MCPで重くなりやすい三つの場所

▸1. 大量・巨大なtool schema

AIがツールを選ぶには、ツールの役割と引数を理解する必要があります。

たとえば、次のような定義です。

{
  "name": "search_issues",
  "description": "Search issues in the selected repository.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repository": {
        "type": "string"
      },
      "query": {
        "type": "string"
      },
      "limit": {
        "type": "integer",
        "minimum": 1,
        "maximum": 100
      }
    },
    "required": ["repository", "query"]
  }
}

一つであれば大きな問題にならなくても、似たツールが数十個、数百個あると、モデルへ提示する定義量が増えます。

また、descriptionが長文で、input schemaが複雑で、例や制約を大量に含むと、一つのツールでも大きくなります。

対策として、クライアント側では次の考え方があります。

今回のタスクに関係するnamespaceだけを提示する
必要なツールだけを動的に選ぶ
似たツールを整理する
descriptionを短く具体的にする
巨大な一つのツールを用途別に分ける

ただし、どの方式を利用できるかは、使用するクライアントやエージェントランタイムに依存します。

▸2. 長いtool result

実務では、tool schema以上にtool resultが大きくなることがあります。

悪い例です。

{
  "issues": [
    {
      "number": 1,
      "title": "...",
      "body": "長い本文...",
      "comments": ["全コメント..."],
      "events": ["全イベント..."]
    }
  ]
}

一覧表示だけが目的なのに、本文、全コメント、全イベントまで返すと、モデルが読む情報が増えます。

一覧用ツールでは必要なフィールドだけを返します。

{
  "issues": [
    {
      "number": 1,
      "title": "ログイン処理でタイムアウトする",
      "state": "open",
      "updatedAt": "2026-06-15"
    }
  ],
  "nextCursor": "..."
}

詳細が必要になったときだけ、別のツールでIssue本文やコメントを取得します。

search_issues
    ↓ 一覧を20件返す
AIが対象を選ぶ
    ↓
get_issue
    ↓ 選択した1件の詳細を返す

この「一覧と詳細を分ける」設計は、MCPに限らずAPI設計全般で有効です。

▸3. 長文のresource本文

resources/list でリソース一覧を取得することと、resources/read で本文を読むことは分けて考えます。

一覧が短くても、本文が巨大であれば、読込時にコンテキストを使います。

たとえば、5000行の DESIGN.md 全文を毎回読むのではなく、次の方法を検討します。

見出し一覧を先に確認する
対象キーワードで検索する
関連セクションだけを読む
文書を機能別に分割する
要約版と詳細版を分ける

🔹MCPサーバー側で結果を制御する

モデルへ返す結果を小さくするには、MCPサーバーのツール設計も重要です。

次の引数を用意すると、クライアントやAIが出力量を制御しやすくなります。

{
  "name": "search_issues",
  "description": "Search issues and return a limited summary.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string"
      },
      "limit": {
        "type": "integer",
        "minimum": 1,
        "maximum": 20,
        "default": 10
      },
      "fields": {
        "type": "array",
        "items": {
          "type": "string",
          "enum": ["number", "title", "state", "updatedAt"]
        }
      }
    },
    "required": ["query"]
  }
}

実務で使いやすい制御項目は次のとおりです。

limit：最大件数
cursor：ページネーション
fields：返す項目
top_k：関連度上位だけを返す
include_body：本文を含めるか
max_chars：最大文字数
summary：全文ではなく要約を返すか

重要なのは、AIへ「結果を短くして」とお願いするだけでなく、ツールのインターフェースとして制限できることです。

🔹MCPよりCLIが向くとき

MCPは便利ですが、すべての処理をMCPツールにする必要はありません。

特に、Skillや固定プロンプトの中で、使用するツールと実行手順が完全に決まっている場合は、CLIコマンドを固定した方が単純になることがあります。

たとえば、Skillへ次の手順が書かれているとします。

変更ファイルの一覧を取得する
対象プロジェクトのテストを実行する
失敗したテスト名だけを抽出する

使用するコマンドが一意に決まっているなら、AIへ複数のMCPツールを提示して選ばせなくても、次のコマンドを実行できます。

git diff --name-only
dotnet test --logger "console;verbosity=minimal"

この場合、CLIを固定指定する利点は次のとおりです。

AIが複数のツールから選択する工程を減らせる
選択材料としてMCPツールのdescriptionやschemaを提示する必要が薄くなる
Skill内の実行手順を再現可能な形に固定できる
開発者が普段使うコマンドをそのまま利用できる
同じコマンドを人間もCIも実行しやすい

判断基準を一文にすると、次のようになります。

AIへ「どの道具を使うか」を選ばせるならMCP。Skillが「このコマンドを使う」と決めているならCLIを候補にします。

次の図では、MCP経路とCLI経路を比較しています。

AIに操作を選ばせるならMCP、Skillで処理が決まっているならCLIも候補になる。どちらもモデルへ返す結果の量を制御する。

▸CLIでも出力が大きければ重い

ここは誤解しやすいポイントです。

CLIを使えば自動的に省トークンになるわけではありません。

次のようなコマンドは、大量の出力を返す可能性があります。

git log
dotnet test --verbosity diagnostic
Get-ChildItem -Recurse
kubectl logs deployment/my-app

大量の出力をそのままモデルへ渡せば、MCPのtool resultと同様にコンテキストを使います。

CLIでも、次のように出力を絞ります。

# 変更されたファイル名だけ
git diff --name-only

# 直近20件だけ
git log -n 20 --oneline

# エラーを含む行だけ
dotnet test --logger "console;verbosity=minimal" |
  Select-String -Pattern 'Failed|Error'

# JSONを必要な項目へ絞る
gh issue list --limit 20 --json number,title,state

CLIとMCPの差よりも、最終的にモデルへ返す情報量の方が重要です。

🔹MCPを選ぶ価値がある場面

一方、次のような場合はMCPが適しています。

タスクに応じてAI自身が複数の操作から選ぶ
型付きschemaで引数を検証する
認証、権限、監査、承認を共通化する
ローカルへCLIを導入できない外部サービスを扱う
IDE、CLI、クラウドエージェントから同じ機能を使う
サーバー側で検索、ページング、要約を統一する
利用者へ内部のAPI実装を見せずに機能を公開する

目的別に整理すると、次の表になります。

条件	MCP	CLI
AIが操作を動的に選ぶ	向いている	固定処理には向く
型付き引数	schemaで表現しやすい	コマンド引数として管理
認証・権限の共通化	サーバー側で実装しやすい	CLIごとに異なる
既存開発コマンドの再利用	MCP化が必要	そのまま使いやすい
複数クライアントから利用	向いている	環境差が出やすい
固定された一連の処理	過剰になる場合がある	向いている
出力制御	ツール設計で制御	オプションや後処理で制御

「MCPとCLIのどちらが優れているか」ではなく、選択の必要性、権限管理、再利用性、結果の量で決めましょう。

🔷4. キャッシュ・圧縮・自動化を品質とセットで考える

長い指示、ツール定義、会話履歴を扱うと、Prompt Cachingという言葉が出てきます。

Prompt Cachingは有用ですが、コンテキスト設計の代わりにはなりません。

ここでは、次の三つを分けます。

コンテキスト設計
Prompt Caching
コンテキスト圧縮

🔹コンテキスト設計は不要な情報を入れない

コンテキスト設計では、今回の判断に不要な情報を最初から入れません。

例：

今回使わないツールを提示しない
対象外の設計書を読まない
検索結果を上位20件に制限する
ログ全文ではなくエラー周辺を返す
一覧取得と詳細取得を分ける

これは入力トークンを減らすだけでなく、AIの判断ノイズを減らします。

🔹Prompt Cachingは同じ先頭部分を再利用する

Prompt Cachingは、複数のリクエストで共通する入力の先頭部分、つまりprefixの計算を再利用する仕組みです。

概念的には次のようになります。

1回目
[固定instructions][固定tools][固定文書][質問A]
 └──────── キャッシュ作成 ────────┘

2回目
[固定instructions][固定tools][固定文書][質問B]
 └──────── キャッシュ読込 ────────┘

固定部分が同じであれば、2回目以降の処理で再利用できます。

キャッシュの対象になり得る固定情報には、次のものがあります。

system instructions
同じツール定義
同じSkill本文
同じ長文ドキュメント
会話履歴の共通部分
同じtool resultが履歴の同じ位置へ残る場合

ただし、ツール順序、schema、タイムスタンプ、前半のメッセージなどが変わると、共通prefixが崩れる可能性があります。

また、MCPサーバーが結果を保存することと、Prompt Cachingは別の仕組みです。

MCPサーバー側のキャッシュ
  → API呼び出しやDB検索結果を再利用する

Prompt Caching
  → モデルへ渡す共通入力の計算を再利用する

同じレスポンスを返すMCPツールでも、その結果が次のモデル入力で共通prefixとして再送されなければ、Prompt Cachingのヒットとは限りません。

🔹コンテキスト圧縮は長い履歴を要約する

コンテキスト圧縮は、長くなった会話履歴を短い要約へ置き換える考え方です。

たとえば、次のような履歴があるとします。

User: 要件を説明
Assistant: 調査結果
Tool: ファイル一覧
Assistant: 設計案
User: 修正依頼
Tool: テスト結果
Assistant: 修正版

これを、次のような要約へ圧縮します。

ここまでの決定事項:
- 公開APIは変更しない
- OrderServiceのみを修正する
- テストは3件追加済み

未解決:
- タイムアウト値の決定

次の作業:
- 設定値を確認して実装を完了する

これにより、古い会話をすべて保持しなくても、重要な判断を引き継げます。

ただし、要約時に細かな情報が失われる可能性があります。後から必要になる原文は、ファイルや外部記録へ残しておく方が安全です。

🔹三つの違いを図で比較する

次の図は、設計、キャッシュ、圧縮の違いを表しています。

コンテキスト削減・キャッシュ・圧縮は別の対策であり、解決する問題も異なる。

実施する順番は、次のように考えると分かりやすいです。

不要な情報を入れない
必要だが繰り返す固定情報をキャッシュする
長くなった会話履歴を圧縮する

最初から不要な情報を大量に入れて、「キャッシュされるから問題ない」と考えるのはおすすめしません。

課金上の負担が下がっても、AIが不要な情報を読んで判断する問題は残るためです。

🔹Claude APIでキャッシュを確認する

Claude APIでは、Prompt Cachingの利用状況をusage情報で確認できます。

代表的な値は次のとおりです。

{
  "usage": {
    "cache_creation_input_tokens": 5000,
    "cache_read_input_tokens": 0,
    "input_tokens": 80
  }
}

cache_creation_input_tokens が増えている場合は、キャッシュへ書き込まれた入力があります。

後続リクエストで、次のように cache_read_input_tokens が増えれば、キャッシュから実際に読み込まれています。

{
  "usage": {
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 5000,
    "input_tokens": 60
  }
}

つまり、確認するときは次のように考えます。

cache creation：次回に備えてキャッシュを作った
cache read：今回のリクエストでキャッシュが使われた

詳細はAnthropicのPrompt Caching公式ドキュメントを確認してください。

🔹OpenAI APIでキャッシュを確認する

OpenAI APIでは、対象となる長いプロンプトに対してPrompt Cachingが自動的に適用されます。

利用状況は、レスポンスのusageに含まれる cached_tokens で確認します。

{
  "usage": {
    "prompt_tokens": 4200,
    "prompt_tokens_details": {
      "cached_tokens": 3072
    }
  }
}

固定のinstructionsやツール定義など、共通する情報を前方へ置き、毎回変わるユーザー入力を後方へ置くと、共通prefixを作りやすくなります。

詳細はOpenAIのPrompt Caching公式ドキュメントを確認してください。

🔹GitHub Copilotと基盤APIを混同しない

GitHub Copilot、Claude API、OpenAI APIは、同じモデルを利用する場合があっても、利用者が操作できる設定は同じではありません。

Claude APIの cache_control のような設定を、通常のGitHub Copilotプロンプトへ直接書けば有効になる、という意味ではありません。

GitHub Copilotでは、Copilotサービス側や利用モデル側がキャッシュを管理します。

そのため、次を分けて説明しましょう。

利用形態	キャッシュの扱い
Claude APIを直接利用	API仕様に従って設定・usage確認
OpenAI APIを直接利用	自動キャッシュとusageを確認
GitHub Copilotを利用	Copilotの機能・表示・課金仕様に従う

「Claudeでは設定できるから、Copilotでも同じJSONを指定できる」とは限りません。

※製品仕様、対応モデル、料金、キャッシュ保持時間は更新される可能性があります。実装時は各サービスの最新公式ドキュメントを確認してください。

🔷5. モデル選択はタスクの難しさとリスクで決める

コンテキスト設計では「何を読ませるか」だけでなく、どのモデルに読ませるかも重要です。

同じプロンプト、同じファイル、同じツール結果でも、使うモデルによって次のような差が出ます。

応答の速さ
推論の深さ
長い文脈への強さ
幻覚の少なさ
コード変更の安定性
入力・出力トークンあたりのAI Credits

GitHub Copilotでは、Chatのモデルを選べる場合があります。また、利用できるモデルは、契約プラン、組織ポリシー、IDEやGitHub.comなどの利用場所によって変わります。

そのため、「このモデルを常に使えばよい」と固定するより、タスクの種類で選ぶ方が実務的です。

なお、GitHub Docsでは、モデルごとに強みが異なり、AI Creditsの消費もモデルのトークン価格に応じて異なると説明されています。記事を読む時点の最新の対応状況は、GitHub Copilotのモデル比較とモデル変更手順を確認してください。

🔹まずはAutoを基準にする

初心者の方は、まずAutoを基準にするとよいです。

Autoは、対応している環境では利用可能状況などを踏まえてモデルを選択します。手動でモデルを選ぶ理由が明確でないうちは、Autoを使うことで、モデル選択そのものに悩む時間を減らせます。

ただし、Autoに任せることと、設計を放棄することは別です。

次のような場合は、手動でモデルを選ぶ価値があります。

重要な設計判断を伴う
原因不明のバグを深く調査する
複数ファイルにまたがる変更を計画する
セキュリティや認証認可に関わる
生成結果の品質が何度も安定しない
コストや速度を優先して軽い作業を大量に処理したい

Autoをデフォルトにしつつ、必要な場面で明示的に切り替える、という考え方です。

🔹モデルは三つの層で考える

モデル名は変わります。新しいモデルが追加され、プレビューが外れ、組織ポリシーで使えるモデルも変わります。

そのため、記事やチームルールでは、特定のモデル名だけでなく、次のような役割で考えると長持ちします。

層	向いている作業	注意点
高推論モデル	設計、計画、難しいデバッグ、レビュー、セキュリティ判断	高品質だが、コストや待ち時間が増えやすい
標準モデル	通常の実装、テスト追加、複数ファイルの修正、ドキュメント更新	迷ったときの中心候補
軽量モデル	小さなリファクタリング、定型変換、要約、単純な文言修正	複雑な設計判断を任せすぎない

たとえば、次のように分けます。

調査・計画：高推論モデルまたはAuto
通常実装：標準モデルまたはAuto
単純修正：軽量モデル
レビュー：高推論モデル
大量の定型処理：軽量モデル + テスト・リンター

大事なのは、「高いモデルを使うか、安いモデルを使うか」ではありません。

必要十分な分析力を持つモデルを選び、足りない品質はコンテキスト、テスト、人間レビューで補うことです。

🔹高性能モデルを使う前に、情報の渡し方を見直す

うまくいかないとき、すぐ上位モデルへ切り替えたくなります。

しかし、失敗の原因がモデル能力ではなく、コンテキスト設計にある場合も多いです。

必要な設計文書を読ませていない
関係ないログを大量に渡している
タスクのゴールが曖昧
変更対象のファイルが特定されていない
テスト条件が書かれていない
古い会話履歴が残っている

この状態で高性能モデルへ切り替えると、たしかに改善することはあります。

ただし、それは「モデルが強いから雑な入力でも耐えた」だけかもしれません。再現性のある運用にするには、まず入力を整理します。

おすすめの順番は次のとおりです。

/context や /usage で膨らんでいる箇所を確認する
関係ないファイル、ログ、ツール結果を減らす
必要な設計文書や制約を追加する
タスクを調査、計画、実装、レビューへ分ける
それでも難しい判断だけ高推論モデルへ渡す

高性能モデルは、不要な情報を大量に処理させるためではなく、難しい判断へ集中させるために使います。

🔹ChatとInline suggestionのモデルは分けて考える

もう一つ混同しやすい点があります。

GitHub Copilot Chatで選ぶモデルと、エディタ上のInline suggestionで使われるモデルは、同じ設定とは限りません。

GitHub Docsでも、Chatのモデル変更はInline suggestionのモデルに影響しないこと、Inline suggestion側も利用できる代替モデルや拡張機能のバージョンに条件があることが説明されています。

つまり、次のように分けて考えます。

場面	主な用途	モデル選択の見方
Copilot Chat / Agent mode	調査、説明、計画、複数ファイル変更	タスクの難しさとレビューリスクで選ぶ
Inline suggestion	入力中のコード補完	速度、書き味、利用可能モデルで選ぶ
Cloud agent / CLI	非同期作業、長い作業、ツール実行	コスト、実行時間、レビュー境界も含めて選ぶ

「Chatでは高推論モデルを使うが、補完は軽快なモデルにする」という選択もあり得ます。

🔹モデル選択もAGENTS.mdやSkillへ書ける

チームでモデル選択を運用するなら、毎回口頭で伝えるより、AGENTS.md やSkillへ判断基準を書いておくと便利です。

例です。

# Model selection

- 通常の実装とテスト追加はAutoまたは標準モデルを使う。
- アーキテクチャ変更、認証認可、セキュリティ判断では高推論モデルを検討する。
- 単純な文言修正、形式変換、軽微なリファクタリングでは軽量モデルを優先する。
- モデルを切り替えた場合は、理由を作業メモに残す。

ここでも、特定モデル名だけを固定しない方が保守しやすいです。

組織で利用可能なモデル、base model、LTS model、料金、ポリシーは変わります。名前ではなく、どの種類の判断にどの程度の推論力を使うかを決めておきます。

💡 モデル選択の結論

迷ったらAutoを基準にし、難しい設計・デバッグ・レビューでは高推論モデルを検討します。軽い定型作業は軽量モデルやCLIへ寄せ、品質はテストとレビューで支えます。

🔷6. 自動化はCDQRで判断する

ここまで、トークンやコンテキストを中心に説明しました。

しかし、実務で本当に最適化したいのはトークンだけではありません。

AI活用では、次の四つをセットで考える必要があります。

Cost：コスト
Delivery：速度
Quality：品質
Review：人間による確認

本記事では、これをCDQRとして整理します。

🔹Cost：不要な入力と出力を減らす

Costでは、単にプロンプトの文字数を見るのではなく、処理全体を確認します。

常設指示が巨大になっていないか
利用しないツール定義を毎回提示していないか
検索結果を全件返していないか
ログを無制限に返していないか
同じファイルを何度も読み直していないか
長いセッションを放置していないか
何度もやり直す原因が説明不足ではないか
軽い作業に高推論モデルを使い続けていないか

適切なinstructionsを少し増やすことで、やり直しが減り、トータルのトークンが下がる場合もあります。

「入力を短くする」だけでなく、「往復回数を減らす」「タスクに合ったモデルへ切り替える」こともCost改善です。

🔹Delivery：AIへ任せることで本当に速くなるか

AIによる自動化は、次のような作業と相性がよいです。

リポジトリ内の探索
変更候補の列挙
定型コードの生成
形式変換
テストの実行
差分の要約
ドキュメントの下書き

一方、作業手順をAIに毎回考えさせるより、SkillやCLIで固定した方が速い場合があります。

たとえば、毎回同じテストコマンドを使うなら、AIが数十個のツールからテストツールを探す必要はありません。

# SKILL.md

検証時は次の順番で実行する。

1. `dotnet format --verify-no-changes`
2. `dotnet test --logger "console;verbosity=minimal"`
3. 失敗時はエラー周辺のみを報告する

判断が不要な部分は固定し、判断が必要な部分へAIの能力を使う方が効率的です。

🔹Quality：必要な設計意図と検証条件を渡す

トークンを減らすために設計文書を読ませなければ、短期的には入力が減ります。

しかし、次のような品質問題が起きる可能性があります。

既存アーキテクチャに反する
公開APIを壊す
セキュリティ境界を越える
データ整合性を損なう
テスト方針に反する
似た機能を重複実装する

品質を守るには、「設計書を全部読む」か「何も読まない」かの二択にしないことが大切です。

AGENTS.md へ、設計文書を読む条件を書きます。

- 公開API変更では `docs/api-design.md` を読む。
- 認証認可の変更では `docs/security/` を確認する。
- DB変更ではマイグレーションとロールバック手順を確認する。

必要なタスクでだけ適切な情報を追加すれば、コンテキスト量と品質を両立できます。

🔹Review：人間が承認すべき境界を残す

AIエージェントが自律的に作業できても、すべてを無条件に承認してよいわけではありません。

人間のレビューを残したい代表例は次のとおりです。

公開APIの破壊的変更
データ削除
本番環境へのデプロイ
認証・認可の変更
秘密情報や個人情報の取り扱い
アーキテクチャ変更
コストへ大きく影響する変更
要件の優先順位付け

AIは、候補を調査し、差分を作り、テストを実行し、レビュー材料を整理できます。

しかし、「このリスクを受け入れるか」「この仕様を正式採用するか」は、組織や責任者の判断です。

▸AIへ任せやすい部分

必要なファイルを探す
既存実装を説明する
変更案を複数出す
テストを追加する
静的解析を実行する
影響範囲を一覧化する
Pull Requestの説明文を作る

▸人間の承認を残す部分

方式の最終決定
本番反映
データ破壊操作
セキュリティ例外
予算や納期の優先順位
法務・コンプライアンス判断

🔹CDQRの判断表

軸	確認する問い
Cost	不要な入力、出力、再試行が増えていないか
Delivery	AIへ任せることで、作業全体が本当に速くなるか
Quality	設計意図、制約、検証条件を必要な範囲で読ませたか
Review	人間が承認すべき境界を残したか

モデル選択も、この表の中で判断できます。

Cost：軽い作業に高推論モデルを使いすぎていないか
Delivery：速さが必要な作業で重いモデルを選びすぎていないか
Quality：難しい設計判断に軽量モデルだけで挑んでいないか
Review：モデルを強くしたことで人間レビューを省略していないか

トークン最適化は、この中のCostだけを改善する活動ではありません。

コンテキスト設計によって、Delivery、Quality、Reviewも一緒に整えます。

🔷7. 実践例：リポジトリのコンテキストを設計する

ここまでの内容を、管理画面を持つ架空のWeb APIプロジェクトへ適用してみます。

🔹プロジェクト構成

shop-api/
├─ AGENTS.md
├─ DESIGN.md
├─ README.md
├─ src/
│  ├─ Api/
│  ├─ Application/
│  └─ Infrastructure/
├─ tests/
├─ docs/
│  ├─ architecture.md
│  ├─ security/
│  │  └─ authentication.md
│  └─ adr/
│     ├─ 0001-database.md
│     └─ 0002-api-versioning.md
└─ .github/
   └─ skills/
      ├─ api-review/
      │  └─ SKILL.md
      └─ database-migration/
         └─ SKILL.md

🔹AGENTS.mdへ常設ルールを書く

# General rules

- 回答は日本語で記述する。
- 既存のコーディング規約と命名規則に従う。
- 無関係なファイルを変更しない。
- 作業後に対象テストを実行する。
- 実行していないテストを「成功」と報告しない。

# Context routing

- UIを新規作成する場合、または見た目を変更する場合は
  `DESIGN.md` を読む。
- 公開APIを変更する場合は `docs/architecture.md` と
  `docs/adr/0002-api-versioning.md` を読む。
- 認証認可を変更する場合は
  `docs/security/authentication.md` を読む。
- DBスキーマを変更する場合は
  `database-migration` Skillを使用する。
- 単純な文言修正では設計文書や `DESIGN.md` を追加で読まない。

# Review boundary

- 本番デプロイは実行せず、手順と確認結果だけを提示する。
- データ削除を伴うコマンドは、実行前に人間の承認を得る。

# Model selection

- 通常の実装とテスト追加はAutoまたは標準モデルを使う。
- 公開API、認証認可、DB設計の変更では高推論モデルを検討する。
- 単純な文言修正や形式変換では軽量モデルを優先する。

このファイルには、詳細な設計内容ではなく、常設ルールと読み分け条件を書いています。

🔹DB変更をSkillへ分ける

---
name: database-migration
description: >
  DBスキーマ変更、マイグレーション作成、
  ロールバック確認が必要なタスクで使用する。
---

# 実行手順

1. `docs/adr/0001-database.md` を読む。
2. 対象Entityと既存Migrationを確認する。
3. Migrationを作成する。
4. 生成SQLを確認する。
5. ロールバック可能性を確認する。
6. テストDBで適用する。
7. 本番適用は行わず、レビュー結果を報告する。

# 固定コマンド

```powershell
dotnet ef migrations add <MigrationName>
dotnet ef migrations script
dotnet test --filter Category=Database
```

ここでは、実行するCLIコマンドが決まっています。

MCPから複数のDB操作ツールをAIへ選ばせるより、Skillへ固定コマンドを書く方が単純です。

一方、本番DBへ接続する必要があり、認証、承認、監査ログを共通管理したい場合は、MCPサーバーを介する価値があります。

🔹GitHub検索はMCPで動的に選ばせる

Issue、Pull Request、レビューコメントなどを横断的に調べるタスクでは、AIが操作を選ぶ価値があります。

例：

「過去に同じ認証エラーを修正したIssueとPRを探し、
採用された解決策を要約してください」

この場合、AIは次の操作を組み合わせる可能性があります。

Issueを検索する
関連PRを取得する
PRの差分を確認する
レビューコメントを読む
採用された結論をまとめる

動的な選択が必要なので、MCPが向いています。

ただし、検索結果は全件返さず、次のように制限します。

{
  "query": "authentication timeout",
  "limit": 10,
  "fields": ["number", "title", "state", "updatedAt"]
}

必要なIssueが決まってから詳細を読みます。

🔹セッションが長くなったら圧縮する

調査、実装、テスト、修正を一つのセッションで続けると、履歴が長くなります。

適切な区切りで、次の情報を要約します。

今回の目的
読んだ設計文書
決定した方式
変更したファイル
実行したテスト
未解決事項
次に行う作業

要約例です。

# 作業要約

## 目的

認証タイムアウト時のリトライ処理を追加する。

## 読んだ資料

- docs/security/authentication.md
- docs/adr/0002-api-versioning.md

## 決定事項

- リトライは最大2回
- 4xxは再試行しない
- 5xxとタイムアウトのみ再試行する

## 変更ファイル

- src/Infrastructure/AuthClient.cs
- tests/AuthClientTests.cs

## テスト

- AuthClientTests: 8件成功

## 未解決

- 本番タイムアウト値は担当者確認待ち

この要約を残せば、古いツール結果や詳細な往復を圧縮しやすくなります。

❓困ったときは：よくある誤解

▸MCPサーバーを登録しただけで、必ず大量課金されますか

一律には言えません。

MCP通信で取得された情報のうち、何をモデルへ渡すかはクライアントやランタイムに依存します。

ただし、利用可能なツールをAIへ選ばせるには、ツール情報が必要です。ツール数、description、schemaが大きければ、コンテキストへ影響する可能性があります。

登録数だけで判断せず、実際のコンテキストとusageを確認してください。

▸Skillを作れば、自動的に省トークンになりますか

必ずしも省トークンになるわけではありません。

Skill本文が巨大であれば、発火時に多くの情報を読みます。

Skillの利点は、特定作業の手順を必要時に読み込ませられることです。本文を短く保ち、詳細資料やスクリプトを分ける設計が重要です。

▸DESIGN.mdは置くだけで毎回読まれますか

DESIGN.md というファイル名だけで、必ず毎回読まれるとは限りません。

AGENTS.md やSkillへ、「どの条件で読むか」を書いてください。

▸CLIはMCPより必ず安いですか

いいえ。

CLIでも大量ログをモデルへ渡せば重くなります。

CLIが向くのは、処理とコマンドが固定されており、AIへツールを選ばせる必要が薄い場合です。

▸高性能モデルを選べば、コンテキスト設計は不要ですか

不要にはなりません。

高性能モデルは、難しい推論や複雑な設計判断で有利になることがあります。

しかし、必要な設計文書が渡っていない、ログが多すぎる、ゴールが曖昧、古い会話履歴に引っ張られている、といった問題は残ります。

モデル選択は、コンテキスト設計、テスト、人間レビューとセットで考えてください。

▸Prompt Cachingが効けば、長いコンテキストでも問題ありませんか

問題がすべて解決するわけではありません。

Prompt Cachingは共通入力の計算を再利用しますが、不要な情報を削除しません。AIの判断ノイズやコンテキスト上限の問題は残ります。

最初にコンテキストを設計し、そのうえでキャッシュを活用してください。

▸指示は短いほどよいですか

短ければよいわけではありません。

重要な制約を削ると、やり直しやレビュー指摘が増える可能性があります。

指示は「短さ」ではなく、「適用範囲が明確で、必要な判断に役立つか」で評価します。

✅まとめ：読むべき情報が、読むべき瞬間に届く構造を作る

GitHub Copilotを使い込むほど、課題は「質問のうまさ」だけでは説明できなくなります。

AIが参照するコンテキスト全体を設計しましょう。

本記事の要点を振り返ります。

質問文だけがトークンではありません。
固定指示、ツール定義、ファイル、会話履歴、ツール結果、AI回答が同じコンテキストを使います。
最初に観測します。
/context、/usage、/compact などを使い、どこが膨らんでいるか確認します。
AGENTS.md は入口として使います。
常設ルールと、必要な資料を読む条件を書きます。
特定作業の手順はAgent Skillsへ分けます。
descriptionを具体的にし、詳細資料やスクリプトは必要時に読みます。
DESIGN.md は必要時に参照します。
置くだけで自動読込を期待せず、AGENTS.md やSkillから導線を作ります。
MCPは接続数より、モデルへ見せる定義と返す結果を設計します。
件数、項目、ページング、top-k、要約を使います。
AIが道具を選ぶならMCP、処理が固定ならCLIも候補です。
Skillでコマンドが決まっているなら、CLIへ固定すると単純になる場合があります。
CLIでも出力を制御します。
大量ログやファイル全文を返せば、MCPと同様にコンテキストを使います。
設計、キャッシュ、圧縮を分けます。
不要な情報を入れない、固定prefixを再利用する、古い履歴を要約する、という別の対策です。
モデル選択はタスクの難しさとリスクで決めます。
迷ったらAutoを基準にし、難しい設計・デバッグ・レビューでは高推論モデル、軽い定型作業では軽量モデルを検討します。
トークンだけでなくCDQRを見ます。
Cost、Delivery、Quality、Reviewのバランスを取ります。

最後に、リポジトリを見直すためのチェックリストを掲載します。

AGENTS.md は常設すべき短いルールに絞られている
詳細な設計書の全文を AGENTS.md へコピーしていない
設計文書を読む条件が書かれている
特定作業の手順をSkillへ分けている
Skillのdescriptionから発火条件が分かる
Skill本文と詳細資料を分けている
不要なMCPツールを常時提示していない
MCPツールの一覧取得と詳細取得を分けている
limit、fields、ページング、top-kを利用できる
tool resultやCLIログの量を制限している
固定処理をCLIへ寄せられないか検討した
Auto、標準モデル、高推論モデル、軽量モデルの使い分け方を決めている
Chat、Inline suggestion、CLI / Cloud agentのモデル選択を混同していない
モデルを切り替えた理由を作業メモやPR説明に残している
長いセッションを適切に要約・圧縮している
キャッシュヒットをusageで確認している
AIへ任せる範囲と人間のレビュー境界を決めている
トークン削減前後で成果物の品質も比較している

AIに読ませる情報を減らすのではなく、読むべき情報が、読むべき瞬間に届く構造を作りましょう。

🔷参考資料

※お役に立てたらストック、いいねをよろしくお願いします！！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up