「Claude Codeに頼んだのに、うまく直らず何度もやり取りした」。そんな経験があると、トークンを減らす方法を探したくなるかもしれません。ただ、最初に見直したいのは指示文の文字数ではなく、一回の依頼で何を完成させるかです。今回は小さなToDoアプリを例に、作業を確認しやすくする進め方を紹介します。
トークンを減らす前に、何を改善するのか決める
Claude Codeでは、質問の文章だけでなく、作業中に使う情報もコンテキストに入ります。コンテキストの大きさと、実際の請求金額・プラン利用枠は同じ数字ではありません。節約だけを目標にして必要な検証を省くと、修正をやり直すことになりかねません。
初心者なら、まず「1件の修正を無理なく終えられたか」を改善の基準にするのがおすすめです。利用状況が気になる場合は、Claude Codeの `/usage` でプランの使用状況やセッションの情報を確認できます。契約プランによって表示の意味が異なるため、画面の金額をそのまま請求額とは判断しないでください。
- 今回直したい動作を一文で説明できる
- 終わったかどうかを実際の操作で判定できる
- 関係のない画面や機能を変更しない
題材は「ToDoアプリの空欄登録」を直す
学習用のToDoアプリで、何も入力せず「追加」を押すと空の項目が増えてしまうとします。今回はこの一点だけを修正する想定です。ログイン機能や画面全体のデザインは扱いません。
| 操作 | 期待する結果 |
|---|---|
| 入力欄が空のまま追加する | 項目が増えず、入力を促す |
| 「 買い物 」と入力して追加する | 前後の空白を除いた内容が登録される |
| 既存の項目を削除する | 以前と同じように削除できる |
この表は、AIの回答が正しいかどうかを決めるための確認項目です。実際にテストした結果ではなく、これから確かめる条件として使います。
依頼文には「目的・変更範囲・確認方法」を書く
「アプリをもっと使いやすくして」だけでは、どこまで修正すればよいか分かりません。作業の始点と終点を決めた文章にすると、不要な機能追加や説明の往復を避けやすくなります。
学習用ToDoアプリの入力チェックを直してください。
目的:空欄のまま「追加」を押しても項目を作らないこと。
変更範囲:追加処理と必要なエラー表示のみ。
確認条件:空欄・通常入力・既存項目の削除を確認すること。
不明点があれば、コードを変える前に確認してください。
フォルダー名やファイル名が分かっている場合は補足すると便利ですが、知らないのに推測で指定する必要はありません。AIに現在の実装を調べてもらい、対象が判明してから修正に進む方法でも構いません。
返答を受け取ったら「動いた証拠」を確認する
修正できたという説明だけで作業を終えず、先ほど決めた条件を順番に試します。画面操作で再現できるなら、実際にブラウザを触って確認することが重要です。テストを自動実行できる環境なら、その結果もあわせて確認してください。
たとえば入力文字列の判定を小さな関数に分ける場合、次のJavaScriptは考え方を確認するための例になります。既存アプリの実装を置き換える完成コードではありません。
function canAddTask(value) {
return typeof value === 'string' && value.trim().length > 0;
}
console.assert(canAddTask('') === false);
console.assert(canAddTask(' ') === false);
console.assert(canAddTask('買い物') === true);
この例で分かるのは入力値を判定する部分だけです。実際の画面にエラーメッセージが表示されるか、一覧に重複して項目が増えないかは別に確かめる必要があります。
結果が違ったら、次の依頼は「症状ひとつ」にする
たとえば空欄登録は止まったのに、スペースだけの文字列が保存されるなら、次の依頼ではその問題だけを伝えます。画面全体の作り直しを求めるより、前回から何が変わったかを示したほうが原因を追いやすくなります。
空欄の登録は止まりました。
ただし半角スペースだけを入力すると項目が増えます。
期待結果:空白文字だけの入力も登録しない。
前回の修正は維持し、この条件の原因と対処を確認してください。
ここでは問題の再現条件を具体的にすることが大切です。AIが提案した修正を採用するかどうかは、動作やテスト結果を見て判断します。
改善効果は「使用量」だけでは判断しない
依頼の切り分けを変えたら、同じ程度の難しさの作業で比較してみましょう。数字が少し減っただけで効果を断定しないように、作業品質も一緒に記録します。
| 確認項目 | 記録すること |
|---|---|
| 作業の条件 | モデル・作業内容・検証方法 |
| 進み具合 | 完了条件を満たしたか、何回修正したか |
| 品質 | 別の機能が壊れていないか |
| 利用状況 | 同じ条件で確認できた /usage 等の表示 |
異なるモデルや難易度を比べると、利用状況の差が依頼文の改善によるものか分かりません。また、Claude Codeのプラン利用枠とAPI利用時の料金は区別して扱います。数字を記録できなかった場合は、効果を「不明」として残してください。
CLAUDE.mdは今回の修正手順とは別に考える
Claude Codeには、プロジェクトの共通ルールを記録する `CLAUDE.md` があります。ただし、今回だけのToDoアプリ修正内容を、毎回読み込む共通指示に追加する必要はありません。継続的に必要なビルド・テスト方法や、そのプロジェクト特有の約束だけを厳選するのが適切です。
短い文章を何行か追加しただけでトークンが必ず節約されるわけではありません。共通ルールが増えるほど、別の作業にも不要な説明を持ち込む可能性があります。内容は公式資料を確認しながら整理しましょう。
小さく依頼するための疑問と答え
依頼を細かく分けると、やり取りが増えて逆効果では?
細分化しすぎると逆効果になることもあります。修正後に結果を確認できる、意味のある一単位で区切ることが重要です。
初心者でも使用量の改善を測れますか?
利用画面で確認できる値を記録できますが、同じ条件の比較が難しい場合もあります。まず完了条件とやり直し回数を記録し、数値による判断は条件が揃った場合だけ行ってください。
まとめ:小さな成功条件から始めよう
最初の目標は「AIに短く答えさせること」ではなく、「修正したかった一つの問題を、自分で確認できること」です。ToDoアプリの入力チェックのような小さな課題から試し、完了条件を満たすまでの手戻りを観察してみましょう。
(Claude Codeの利用量に関する公式情報については『Manage costs effectively(Anthropic公式)』をご参照ください)
(AIへの依頼の組み立て方については『Best practices for Claude Code(Anthropic公式)』をご参照ください)
(プロジェクト共通ルールの管理については『How Claude remembers your project(Anthropic公式)』をご参照ください)