AI Tools on KnightLiブログ

Claude Codeのtoken消費が急に増える理由：チュートリアル、排障、FAQ

Wed, 08 Jul 2026 10:11:38 +0800

Claude Codeを使っていると、同じような小さな修正なのに急にtoken消費が増えることがあります。必ずしも価格やモデルの問題ではありません。多くの場合、会話履歴、ファイル読み込み、ログ、Hooks、MCP、失敗の再試行が積み重なっています。

まず最近何が変わったかを確認し、コンテキストを減らし、タスク範囲を狭くするのが基本です。

tokenはどこで使われるか

ユーザーの指示、Claude Codeが読んだファイル、ターミナル出力、テストログ、エラースタック、会話履歴、ツール結果、CLAUDE.md、Memory、Hooksの出力、モデルの返答がすべて消費に関係します。短い指示でも周辺コンテキストが大きければ高くなります。

まず止血する

新しい会話を始める。
読んでよいファイルを明示する。
リポジトリ全体の分析を避ける。
ログは重要な末尾だけ渡す。
不要なMCPツールを一時的に切る。
Hooksが大量出力していないか見る。
調査と修正を分ける。

1
2
3

Please only inspect src/auth/session.ts and tests/auth/session.test.ts.
Goal: find why login state is lost.
Do not scan the whole repository. Do not modify files. First give the diagnosis.

原因1：会話が長すぎる

長い会話には、ログ、ファイル、計画、古い判断が蓄積します。後半の小さな質問でも、それらを抱えたまま処理されます。

独立したタスクは新しい会話にし、長い作業は要約してから続けます。安定したルールは会話ではなくCLAUDE.mdへ移します。

原因2：ファイルを読みすぎている

広すぎる指示は探索を増やします。

`1`	`Help me optimize this project’s login logic.`

よりよい指示：

1
2

Please analyze the login refresh flow. Start with src/auth and tests/auth.
If you need other directories, explain why first.

関係ないファイルを開き続けるなら、いったん止めて範囲を言い直します。

原因3：テストやビルドログが長い

依存インストール、詳細テスト、Playwright trace、TypeScriptの大量エラー、Docker buildのログはコンテキストを大きくします。

`1`	`pnpm test -- auth`

のように狭いテストから始めます。

`1`	`pnpm test`

を毎回そのまま渡す必要はありません。

原因4：CLAUDE.mdが長すぎる

CLAUDE.mdは便利ですが、巨大な百科事典にすると毎回重くなります。技術スタック、コマンド、禁止ファイル、検証方法、プロジェクト固有の約束だけに絞ります。

長い背景説明はdocs/に置き、必要なときだけ読ませます。

原因5：Memoryの汚染

Memoryは横断的な好みに向いています。特定プロジェクトのパスやコマンドを入れると、他プロジェクトに持ち込まれ、tokenも行動も無駄になります。

リポジトリ固有の事実はCLAUDE.mdやプロジェクト文書に戻します。

原因6：Hooksの出力が多い

Hooksが完全なdiff、長いテストログ、環境変数、重複エラーを毎回出すと、静かにtokenが増えます。

1
2

lint failed: 3 errors in src/auth/session.ts
full log saved to .tmp/lint.log

のように要約し、詳細はファイルへ保存します。

原因7：MCPが大量データを返す

検索、DB、Web、コードインデックスのMCPは全文や大量結果を返しがちです。

`1`	`Return only the 5 most relevant results. Do not expand full text. Explain why each result is relevant.`

limit、page_size、summary_onlyが使えるなら指定します。

原因8：モデルが変わった

token数が同じでも、モデルや推論モードが変わると消費感が変わります。現在のモデル、チームの既定値、高effort設定を確認します。

原因9：失敗の再試行

同じ失敗を繰り返すと、ログ、説明、パッチ、ツール呼び出しが積み上がります。2回失敗したら止めます。

`1`	`Stop editing. Summarize the common cause of the last two failures and propose one minimal verification command.`

原因10：タスクが抽象的すぎる

`1`	`Improve this module.`

より：

1
2
3

Only optimize the expiration cleanup logic in src/cache/store.ts.
Do not change the public API.
After editing, run tests/cache/store.test.ts.

の方が省tokenです。

排障チェックリスト

確認項目	症状	対処
会話長	後半ほど遅い	新しい会話にする
ファイル範囲	無関係なファイルを読む	ディレクトリを制限
ログ	出力が長い	重要なエラーだけ渡す
`CLAUDE.md`	ルールが長すぎる	高頻度ルールだけ残す
Memory	他プロジェクト情報が混ざる	一時情報を削除
Hooks	自動出力が多い	要約にする
MCP	検索結果が大きい	件数制限
モデル	既定が変わった	タスクに合わせて選ぶ
再試行	同じ失敗が続く	止めて原因整理
指示	広すぎる	小さな作業票にする

省tokenワークフロー

目的と範囲を明示する。
必要なファイルだけ読ませる。
最初は分析だけ、次に編集。
小さいファイル集合を変更する。
関連する最小テストを実行する。
失敗ログを短くする。
次のタスクは新しい会話で行う。

Goal: fix login refresh failure.
Scope: start with src/auth/session.ts and tests/auth/session.test.ts.
Limit: first round only, no edits, no full-repo scan.
Output: the 3 most likely causes and verification methods.

FAQ

token増加はバグですか？

多くの場合は違います。コンテキスト、ファイル読み込み、ログ、Hooks、MCP、モデル設定を先に確認します。

MCPを切れば節約できますか？

大量結果を返すMCPなら節約できます。完全に切るより、件数と要約を制限する方が実用的です。

CLAUDE.mdは詳しいほどよいですか？

いいえ。行動に影響する安定ルールだけを書きます。

小さな変更なのに高いのはなぜ？

変更行数ではなく、会話全体のコンテキストが効くためです。

新しい会話で重要情報を失いませんか？

古い詳細は失いますが、多くの場合それが利点です。必要な結論だけ再提示します。

まとめ

Claude Codeのtoken消費増加は、長い会話、広いタスク、長いログ、肥大化したCLAUDE.md、Memory汚染、Hooks、MCP、モデル変更、再試行が重なって起こります。新しい会話、狭い範囲、短いログ、限定されたツール出力で、必要な部分にだけコンテキストを使うのが重要です。

CodexでOllamaのローカルモデルに接続するときのよくあるエラー：チュートリアル、トラブルシュート、FAQ

Wed, 08 Jul 2026 10:09:57 +0800

Codexからローカルモデルを使えるようになると、低リスクなコード作業をOllamaに任せたくなります。クォータを節約でき、機密性の高いテキストも手元で扱えます。ただし初期設定では、Ollamaは動いているのにCodexから接続できない、接続できても出力が弱い、という問題がよく起きます。

このガイドでは、Ollama単体の確認、Codex側の設定、エラー別の排障という順番で整理します。

ローカルモデルに向く作業

小さなコード説明、スクリプトの下書き、READMEや設定説明の編集、簡単なレビュー、クラウドに出しにくい私的なテキストには向いています。一方で、大規模リファクタ、深いリポジトリ推論、セキュリティ重要箇所、長時間の自律実行には向きません。

ステップ1：Ollama単体を確認する

`1`	`ollama --version`

コード向けモデルを取得します。

`1`	`ollama pull qwen2.5-coder:7b`

一度実行します。

`1`	`ollama run qwen2.5-coder:7b`

ここで失敗するなら、Codex設定ではなくOllama、モデル、リソース、ネットワークを先に直します。

ステップ2：Ollama APIを確認する

既定のAPIは通常次です。

`1`	`http://localhost:11434`

`1`	`curl http://localhost:11434/api/tags`

Windows PowerShellでは：

`1`	`Invoke-RestMethod http://localhost:11434/api/tags`

ここでモデル一覧が見えれば、Ollamaサービスは動いています。

ステップ3：Codex側を設定する

確認するのは主に3つです。

base_urlがOllamaを指している。
モデル名がollama listと完全一致している。
OllamaネイティブAPIかOpenAI互換APIかが合っている。

ポート抜け、タグ違い、WSLのlocalhost問題など、小さな設定ミスが多いです。

最小テスト

最初は読み取り専用で試します。

`1`	`Please explain the main purpose of README.md in this directory. Do not modify files.`

または：

`1`	`Please inspect this function and list possible edge cases. Do not edit the code.`

いきなり全体リファクタを頼まないことが大事です。

connection refused

1
2
3

connection refused
failed to connect
ECONNREFUSED 127.0.0.1:11434

Ollamaが起動していない、ポートが違う、CodexがWSLやコンテナ内にいてホストのlocalhostに届かない、プロキシやファイアウォールが邪魔している、などが原因です。

Codexと同じ環境で確認します。

`1`	`curl http://localhost:11434/api/tags`

WSLからWindows上のOllamaへ接続する場合は、WindowsホストIPを使います。

model not found

1
2
3

model not found
unknown model
pull model manifest: file does not exist

`1`	`ollama list`

表示がqwen2.5-coder:7bなら、Codex側にも完全に同じ名前を書きます。

`1`	`qwen2.5-coder:7b`

`1`	`ollama pull qwen2.5-coder:7b`

404またはAPIパス違い

OllamaにはネイティブAPIとOpenAI互換APIがあります。

Ollama native:
http://localhost:11434/api/chat

OpenAI compatible:
http://localhost:11434/v1/chat/completions

CodexがOpenAI互換を期待するなら、base URLは多くの場合：

`1`	`http://localhost:11434/v1`

悪い例：

`1`	`http://localhost:11434/api`

です。/apiを指定すると404になることがあります。

context length exceeded

1
2
3

context length exceeded
prompt is too long
input exceeds context window

ローカルモデルはコンテキストが狭いことがあります。対象ファイルを絞り、ログを短くし、関連箇所だけ渡します。大規模変更では、ローカルモデルは補助分析に使うのが安全です。

出力品質が悪い

モデルが小さい、コード向けでない、タスクが広すぎる、サンプリングが強すぎる、文脈が多すぎる、などが原因です。

狭い指示にします。

`1`	`Only read src/api/user.ts. Find possible null-handling issues. Do not modify files; list findings only.`

避けたい例：

`1`	`Optimize the whole project.`

遅い場合

速度はモデルサイズ、CPU/GPU、メモリ、コンテキスト長に依存します。最初は7Bから試し、必要なら14Bへ進みます。Codex用には、最大モデルより安定性と制御しやすさが重要です。

`1`	`ollama pull qwen2.5-coder:7b`

WindowsとWSLのlocalhost問題

OllamaがWindows、CodexがWSLの場合、WSL内のlocalhostはWSL自身を指すことがあります。

`1`	`curl http://localhost:11434/api/tags`

失敗したら：

`1`	`cat /etc/resolv.conf`

nameserverのアドレスを試します。

`1`	`curl http://<windows-host-ip>:11434/api/tags`

プロキシ環境変数

1
2
3

echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $NO_PROXY

PowerShell：

1
2
3

$env:HTTP_PROXY
$env:HTTPS_PROXY
$env:NO_PROXY

NO_PROXYに追加します。

`1`	`localhost,127.0.0.1`

Ollamaを使わない方がよいケース

本番の重要パス、大規模な複数ファイル変更、長時間の自律実行、テストが少ないプロジェクト、すでに何度も誤解しているタスクでは無理に使わない方が安全です。

タスクテンプレート

Please only inspect src/auth/session.ts.
Goal: find edge cases that may cause session loss.
Requirements:
1. Do not modify files.
2. Output only a list of issues.
3. For each issue, include trigger conditions and a suggested verification method.

編集する場合：

Please only modify src/utils/format.ts.
Goal: handle empty string and null.
Requirements:
1. Do not change function signatures.
2. Keep existing exports.
3. After editing, state which test should run.

FAQ

完全オフラインで使えますか？

Codex、モデル、ツールがすべてローカルで動き、クラウドモデルを呼ばなければ推論はローカルです。必要ならネットワーク監視で確認します。

どのモデルから始めるべきですか？

コード用途ならqwen2.5-coder:7bまたはqwen2.5-coder:14bから始めます。

クラウドモデルではできるのにローカルでは失敗するのはなぜですか？

モデル規模、学習データ、コンテキスト、ツール適応が違うためです。タスクを小さくします。

リポジトリ全体を渡してよいですか？

最初は避けます。ファイル、関数、エラー単位から始めます。

Ollamaは起動し続ける必要がありますか？

はい。停止するとCodexは接続エラーやタイムアウトになります。

まとめ

排障は、Ollamaプロセス、HTTP API、Codexのbase URL、APIモード、モデル名、コンテキスト、タスク範囲の順に確認します。ローカルモデルは小さく明確な作業で最も役に立ちます。

Claude Codeで複数プロジェクトの記憶を管理する方法：CLAUDE.md、Memory、Hooksのチーム運用

Wed, 08 Jul 2026 10:08:20 +0800

Claude Codeを本格的に使い始めると、すぐに問題になるのがプロジェクトごとの記憶です。あるリポジトリではpnpmを使い、別のリポジトリではPoetryを使う。あるプロジェクトでは先にテストを書き、別のプロジェクトでは先にドキュメントを直す。こうした違いを混ぜると、AIコーディングは一気に不安定になります。

解決策は、すべてのルールを巨大なプロンプトに詰め込むことではありません。CLAUDE.md、Memory、Hooksを役割ごとに分けることです。

複数プロジェクトで記憶が乱れる理由

実際のチームには、フロントエンド、バックエンド、運用スクリプト、ドキュメントなど複数のリポジトリがあります。技術スタックもテストコマンドも違います。口頭の約束だけでは、毎回同じ説明を繰り返すことになります。

目標はClaude Codeに何でも覚えさせることではなく、正しい場所に正しい情報を置くことです。

3層の記憶モデル

層	向いている内容	向いていない内容
`CLAUDE.md`	現在のリポジトリのビルド、テスト、ディレクトリ、禁止事項	個人設定、一時タスク、他プロジェクトの情報
Memory	チーム共通の長期的な好みや協業ルール	特定リポジトリのパスやコマンド
Hooks	フォーマット、テスト、秘密情報チェックなどの自動化	人間が判断すべきプロダクト判断

CLAUDE.mdは「このプロジェクトのやり方」、Memoryは「このチームの協業スタイル」、Hooksは「毎回自動で確認すべきこと」を担当します。

CLAUDE.mdはプロジェクトごとの作業マニュアル

CLAUDE.mdはリポジトリのルートに置き、具体的で安定した内容だけを書きます。READMEの代替ではなく、AIコーディングエージェント向けの作業手順書です。

# Project Guide

## Tech Stack

- Runtime: Node.js 22
- Package manager: pnpm
- Framework: Next.js
- Tests: Vitest and Playwright

## Common Commands

- Install dependencies: `pnpm install`
- Run dev server: `pnpm dev`
- Run unit tests: `pnpm test`
- Run lint: `pnpm lint`
- Run e2e tests: `pnpm test:e2e`

## Working Rules

- Before editing shared UI components, inspect existing usage first.
- Prefer existing helpers in `src/lib` before adding new utilities.
- Do not change database migrations unless the task explicitly asks for it.
- Keep unrelated refactors out of feature fixes.

## Verification

- For UI changes, run `pnpm lint` and the nearest relevant test.
- For API changes, add or update request-level tests.
- For database changes, include migration notes in the final summary.

固定コマンド、特殊なディレクトリ、触ってはいけないファイルがあるなら、ここに書きます。

CLAUDE.mdをゴミ箱にしない

便利だからといって何でも追記すると、重要なルールが埋もれます。古いコマンド、長すぎる背景説明、一時タスク、同じ意味の繰り返しは避けます。あるディレクトリにだけ適用されるルールは、範囲を明示します。

Memoryはプロジェクト横断の好みを保存する

Memoryには、リポジトリをまたいで有効なルールを入れます。たとえば、コミットメッセージの言語、プロダクション設定変更時の説明、未コミット変更を勝手に戻さないこと、モバイル表示の確認、コードレビューの書き方などです。

一方で、特定リポジトリの起動コマンドやデプロイスクリプトのパスはMemoryではなくプロジェクト内ドキュメントに置くべきです。

Hooksで固定チェックを自動化する

Hooksは、毎回必要な処理に向いています。

編集後のフォーマット。
コミット前の秘密情報チェック。
特定ディレクトリ変更時のテスト実行リマインド。
.envやトークンの誤コミット防止。
作業終了時の変更ファイルと検証結果の要約。

Hooksは明確なチェックを自動化するものであり、プロダクト判断を代替するものではありません。

推奨ディレクトリ構成

workspace/
├── app-web/
│   ├── CLAUDE.md
│   └── package.json
├── app-api/
│   ├── CLAUDE.md
│   └── pyproject.toml
├── infra/
│   ├── CLAUDE.md
│   └── deploy.ps1
└── docs/
    └── ai-working-rules.md

各リポジトリに自分用のCLAUDE.mdを置き、チーム共通ルールは文書化し、長期的に安定したものだけMemoryに昇格します。

プロジェクト別の書き方

フロントエンド：

## Frontend Rules

- Use existing components in `src/components` before creating new ones.
- Keep layout stable on mobile and desktop.
- Use `pnpm lint` for quick validation.
- For visual changes, mention what viewport was checked.

バックエンド：

## Backend Rules

- API handlers live in `src/routes`.
- Database migrations must be reviewed manually.
- Do not change authentication middleware without explicit approval.
- Run `pytest tests/api` after endpoint changes.

運用：

## Operations Rules

- Treat deployment scripts as production-sensitive.
- Do not print secrets or tokens in logs.
- Prefer dry-run mode before changing remote state.
- Summarize changed commands before final handoff.

同じテンプレートにそろえる必要はありません。その場所で最も大事な制約がすぐ分かることが重要です。

いつ記憶を更新するか

Claude Codeが同じ間違いを繰り返す、同じルールを何度も説明している、検証フローが変わった、ディレクトリ構造が変わった、古いルールが無効になった。こうした時は更新のタイミングです。

コードレビューでの使い方

コードレビューでは、まず現在のCLAUDE.mdを読み、変更されたディレクトリを確認し、最小限の検証を行い、バグ・回帰・テスト不足を優先して指摘します。最後に短い変更概要を出します。

よくある失敗

すべてをMemoryに入れること、CLAUDE.mdを完全な開発マニュアルにすること、ルールだけ書いて自動化しないこと、古い記憶を掃除しないことです。

導入手順

各リポジトリに短いCLAUDE.mdを追加する。
技術スタック、コマンド、禁止ファイル、検証方法だけを書く。
横断的な好みをMemoryへ移す。
繰り返しチェックをHooksにする。
2週間ごとに古いルールを整理する。

まとめ

Claude Codeで複数プロジェクトを扱うなら、記憶を分けることが重要です。リポジトリの事実はCLAUDE.md、長期的な好みはMemory、繰り返し確認はHooksへ置きます。良い記憶システムは長いものではなく、正しいプロジェクトで正しい行動を助けるものです。