社内勉強会で900人以上が参加！Claude Codeのコスト最適化を支える5つの習慣

Anthropicの社員を講師に招いた社内勉強会で得た実践のヒント

こんにちは、グループIT推進本部でライセンスの管理をしている鷹雄です。

Claude Codeで作業を続けていると、短い追加の依頼でも、思った以上に利用量が増えることがあります。
その理由を理解するには、今回入力した文章に加えて、Claudeが一緒に読み込む会話履歴やファイル、ツールの出力にも目を向ける必要があります。

2026年9月9日サイバーエージェントではClaude Codeのコスト最適化をテーマに社内勉強会を開催し、社内勉強会でおそらく過去最多の900名以上の方が参加しました。Anthropic Japan 合同会社の担当者にClaude Codeのコストを抑えるコツや、技術的な解説をしていただきました。講演に加え、セッション管理、要約、モデル選択、開発プロセスなど、37項目のQ&Aから実践のヒントを整理しました。

この記事では、講演の軸となった5つの習慣を、Q&Aで掘り下げた疑問とともに紹介します。共通する考え方は、作業に必要な文脈を保ちながら、不要な読み直しや手戻りを減らすことです。

コストを理解する出発点は文脈の大きさ

Claude Codeが処理する情報には、ユーザーの指示だけでなく、過去の会話、読み込んだコード、テストログ、プロジェクトの指示などが含まれます。この作業に使う情報のまとまりが「コンテキスト」です。

同じ「続きをお願いします」でも、その前に何を読み、どれだけ会話したかで、処理する情報量は変わります。講演では、この構造を理解する視点として「文脈の大きさ × ターン数」が示されました。

ただし、これは請求額を求める厳密な式ではありません。実際のコストはモデルや出力・思考の量、キャッシュの利用状況などにも左右されます。キャッシュは以前処理した入力の一部を再利用する仕組みですが、キャッシュからの読み取りにも利用量が発生します。文脈を適切に保つことと、再利用を活かすことの両方が必要です。[1][2]

図1：文脈が増える仕組みの概念図。幅は実際のトークン数を表しません。
過去の入力は、条件に応じてキャッシュから再利用されます。[1][2]

〜 Claude Codeのコスト最適化を支える５つの習慣〜

習慣①：作業の区切りで会話を要約する

長く続く作業では、調査の途中経過や大量のログが会話に残ります。実装に必要な結論が出たら、その後もすべてを持ち続ける必要があるかを見直します。

/compact は会話を要約し、作業を続けるための文脈を整理するコマンドです。要約に残したい情報を指定できます。たとえば、認証機能の修正なら次のように依頼します。

/compact 認証修正の決定事項、未解決の問題、変更ファイル、検証結果を残してください

Q&Aで確認したのは、要約そのものにもトークン消費があることです。/compact は履歴を読んで要約する処理なので、短い間隔で繰り返せば、その分の処理も増えます。また、要約によって細部が抜ける可能性があります。仕様や重要な判断理由は、SPEC.md などのファイルにも残しておくと、後から確かめられます。[2][3]

講演では、1Mの大きなコンテキストを使う場合の設定例として、/autocompact 500k で自動要約のタイミングを早める方法も紹介されました。これはすべての環境に共通する最適値ではありません。モデルの上限やタスクに合わせ、情報の抜けや追加の読み直しが増えていないかを確認して調整します。現在の公開仕様では、このコマンドはユーザー設定にも保存されるため、次のセッションへの影響も意識します。[3][4]

習慣②：長い中断の前に再開の準備をする

会話を保存してあることと、その会話のキャッシュが残っていることは別です。履歴から作業を再開できても、キャッシュの有効期間を過ぎていれば、次のリクエストで再処理が必要になります。

そこで講演では、長く離席する前に必要な文脈を要約し、再開時に持ち越す情報を小さくしておく方法が紹介されました。同じ作業を続ける予定なら区切りで要約する。別の作業に移るなら、必要な決定事項を記録して新しい会話を始める。作業の続け方に合わせて選びます。

キャッシュの有効期間は、利用形態や設定によって異なります。公開仕様には5分と1時間のTTLがあり、長いTTLでは書き込み単価も高くなります。「1時間なら必ず残る」「長くすれば必ず安い」とは限りません。自分の環境の条件を確認することが前提です。[2]

表1：会話を再開できることと、キャッシュが使えることは別です。[2]

習慣③：タスクが変わったらセッションを分ける

午前中の障害調査、午後の機能追加、夕方のドキュメント作成を一つの会話で進めると、いまの作業に関係しない情報まで残りやすくなります。

Q&Aでは、セッションを切り替える基準として「同じタスクの続きかどうか」が整理されました。文脈が必要な続きなら維持し、無関係な仕事に移るなら /clear で新しい会話を始めます。[3]

図2：次のタスクと履歴の大きさから、セッションの扱いを決める。[3][5]

/rename は必須ではありません。後から探しやすくするための操作なので、戻る予定がなければ毎回名前を付ける必要はありません。名前を変えるだけで会話が短くなるわけでもありません。[5]

また、仕様を固める会話と実装・レビューの会話を分ける方法もあります。仕様や制約をファイルに整理して渡せば、検討の全過程を引き継がずに作業を始められます。実装とは別のセッションでレビューする方法は、既存の説明に引きずられずに見直す助けにもなります。[6]

表2：名前を付ける操作は、コンテキストの削減やキャッシュの延命を目的とするものではありません。

習慣④：毎回読み込む指示とツールを見直す

会話履歴を整理しても、最初から読み込まれる指示が大きければ、その分の文脈を使います。まずは /context で内訳を確認し、どの情報が多くを占めているかを見ます。[3]

プロジェクトの共通指示を書く CLAUDE.md には、ビルド方法や重要な制約など、毎回必要な内容を簡潔に残します。特定のファイルだけに必要なルールは .claude/rules/ の paths 条件で範囲を絞り、繰り返し使う手順はスキルに分けると整理しやすくなります。[7][8]

ここでQ&Aに出た注意点が、単にファイルを分割するだけでは読み込む総量が減らないことです。CLAUDE.md から別ファイルをすべて参照すれば、それらも読み込まれます。整理の基準は、ファイル数よりも「いつ、その情報が必要になるか」です。[7]

同様に、使っていないMCPサーバーや長すぎるツール出力も見直します。ツール定義の読み込み方法は環境によって異なるため、まず内訳を確認してから調整します。ログを絞る場合も、失敗行や判断に必要な情報まで落とさないことが大切です。[1]

フォーマッターやリンターなど、実行条件が決まっている処理は、コマンドを実行するHooksや既存のCIに組み込めます。毎回同じ処理を依頼する往復を減らし、実行漏れも防ぎやすくなります。[9]

表3：情報の置き場所は「いつ必要か」で選ぶ。スキル名・説明などは通常時の文脈にも入るため、スキル化しても使用量がゼロになるわけではありません。[7][8][9]

習慣⑤：モデルと役割を作業に合わせる

モデル選択では、その作業に必要な判断の難しさと、求める品質を考えます。定型的な修正や調査と、複雑な設計判断を伴う作業では、適した選択が変わります。利用できるモデルや課金条件を確認し、作業の開始時にモデルとEffortを選ぶと運用しやすくなります。[4]

Q&Aでは、メインのセッションが計画・判断・結果の統合を担い、大量のファイルを読む調査やログの確認をサブエージェントに任せる方法も話題になりました。サブエージェントは独立したコンテキストで動けるため、詳細な調査過程をメインに残さず、必要な結果を返す用途に向いています。[10]

図3：サブエージェントで調査の文脈を分ける代表的な構成。会話を引き継ぐ方式など例外もあります。メインとサブエージェントの両方で利用量が発生します。[10]

ただし、サブエージェント自身もトークンを使います。短い作業まで細かく分けると、依頼の伝達や結果の統合が増え、総コストが上がる場合があります。「大量に読むが、メインに必要なのは結論」という自己完結した作業から試すのがよさそうです。[10]

モデルの切り替えはキャッシュにも影響します。Effort変更時の扱いにはモデルやバージョンによる違いがあるため、一律に「変更すると必ずキャッシュが消える」とは考えず、利用環境の仕様を確認します。[2]

Q&Aから見えた手戻りを減らす依頼の仕方

5つの習慣に加え、Q&Aで繰り返し扱われたのが、作業の進め方です。依頼時に対象と完了条件を明確にすると、不要な探索や修正の往復を減らしやすくなります。[6]
たとえば、テストを追加してほしいときは、対象のファイル、確認したいケース、既存のテスト方針、実行してほしい検証まで伝えます。次は、その考え方をもとに作成した依頼例です。

@src/cart/total.ts の送料計算にテストを追加してください。
送料無料の境界金額の直前と一致時を確認し、既存のテスト形式に合わせてください。
追加したテストを実行し、結果と未確認の点を報告してください。

複数ファイルにまたがる変更や、方針が定まっていない作業では、Planモードで方向を確認してから実装すると、手戻りを抑えられる可能性があります。一方、修正範囲が明確な小さな変更では、計画のやり取りを追加する必要はありません。Planモード自体にも処理があるため、作業の不確実さに応じて使い分けます。[6]