はじめに

Claude Codeのようなコーディングエージェントを日常的に使い始めると、最初にぶつかる壁は「動くかどうか」ではありません。数日〜数週間運用してから初めて直面するのは、「コストがどこでどう積み上がっているのか、実感として掴めない」という問題です。

個人で経理・保守・メディア配信など複数の業務をAIエージェントに任せて運用する中で、実際に踏んだ地雷とそこから作った運用ルールを共有します。「〇〇%削減」のテクニック集ではなく、何が起きて、どう気づいて、どう直したかという記録です。

結論（先にまとめ）

「動いているかどうか」より「どれだけ静かにコストが積み上がっているか」の方が扱いにくい
コストが見えにくくなる原因は3つ：毎回自動で読み込まれる固定コンテキスト、伸び続ける会話履歴、意図せず自分自身を呼び直す再帰的な処理
実際に起きた象徴的な事故4つ
1. プロセス確認コマンドの選び方一つでセッション予算の19%を溶かした
2. 常時読み込む指示ファイルの肥大化に気づかず、見直しでセッションあたり2,500〜3,000トークン削減
3. 処理方式（複数パス→単一パス）の変更で、処理量が増えているのにコストが＄1.10→＄0.36（約69%減）
4. 委任先の判断基準を誤り、失敗・タイムアウトを繰り返して逆に時間とコストを溶かした
「節約のつもりが逆にコストを増やした」失敗例（軽い単発作業をわざわざ別セッションに委任し、実質何もされずに終わった話）も紹介
導いた運用ルールは、特別なツールではなくコマンドの選び方・ファイル構成・委任判断という地味な工夫の積み重ね

なぜコストが見えにくくなるのか

AIエージェントのコストは、大きく3種類が積み上がって見えなくなります。

固定コンテキスト — 毎セッション自動で読み込まれる設定ファイル・指示書・常時接続のツール定義
会話履歴 — やり取りが長くなるほど蓄積する
再帰的な処理 — フックや自動実行が意図せず自分自身を呼び直すケース

一番厄介なのは1番目です。会話履歴は目に見えて伸びていくので気づきやすく、途中で要約・圧縮するといった対策も取りやすい領域です。一方、固定コンテキストは「設定した瞬間は正しかったが、その後見直していない」という形で静かに積み上がります。しかも固定コンテキストは「毎回同じだけ払い続ける」性質があるため、1回あたりの無駄が小さくても、日々の運用回数をかけると無視できない金額に膨らみます。

3番目の再帰的な処理も見落としやすい領域です。自動実行の仕組み（フックやスケジューラ）が、想定していなかった条件で自分自身を再度呼び出してしまうと、気づかないうちに実行回数そのものが膨張します。これはコストだけでなく、サービスの利用上限に触れて運用が止まるリスクにもつながるため、金額以上に注意が必要な領域です。

実際にやった節約策

1. コマンドの選び方一つで19%を溶かした話

背景

複数のドメインの保守・開発をAIエージェントに任せる中で、サーバー上でバックグラウンド実行しているプロセスが「まだ動いているか」を確認する作業が日常的に発生します。深く考えずに一般的なプロセス一覧コマンドを使っていました。

気づいたきっかけ

あるセッションのコンテキスト消費を振り返ったところ、大きな実装や調査をしていないのに想定より消費が多いことに気づきました。原因は、プロセスの生存確認を複数回行っていたことでした。

一般的なプロセス一覧コマンドは、実行中のプロセスのコマンドライン全体を表示する列を含みます。CLIの呼び出しでプロンプト文字列を引数として渡している場合、その数百文字の依頼文がまるごとプロセス一覧に表示されます。確認するたびにその全文がコンテキストに乗っていたことになり、この確認作業だけでセッショントークンの19%を消費していたことが判明しました。

対策

生存・経過時間だけを見たいなら、コマンドライン全体ではなくPID・経過時間・ステータスのみを出力するオプションに切り替える
対象PIDが不明なら、まずプロセス名やユニークなキーワードで絞り込んでから照会する
絞り込みにgrepを使う場合も、長いプロンプト文字列にマッチしない短くユニークな識別子（実行IDなど）を使う

その後

以降、状態確認系のコマンドを書くときは「このコマンドの出力に、自分が渡した長い文字列が含まれていないか」を先に確認する癖がつきました。「確認のための確認」が一番高くつく、というのは地味ですが典型的な事故だったと思います。

2. 常時読み込まれる指示ファイルの肥大化

背景

エージェントに与える指示ファイルには、他ファイルをインポートして参照をまとめる記法があります。関連情報を一箇所に集約できて便利なため、モデル選定基準をまとめた文書をこの形式で組み込んでいました。

気づいたきっかけ

このドキュメントは元々、実装やデプロイ作業でどのモデル・エージェントに委任するかを選ぶときにだけ参照すればよい内容でした。ところがインポート方式で組み込んでいたため、雑談レベルのやり取りでも毎回全文が読み込まれていることに、あらためてファイルサイズ（9KBほど）を確認して気づきました。

対策

該当ファイルをインポートから外し、通常のリンク参照に変更しました。「モデル選定・委任の判断を行う前に必ず読むこと」という一文を明記しておくことで、実際に必要なタイミングでは変わらず参照される一方、不要なセッションでは読み込まれなくなります。

その後

この変更だけで、セッションあたり概算で2,500〜3,000トークンの削減になりました。特定の作業（実装・デプロイ・モデル選定等）の前提知識に過ぎないものは、オンデマンドのリンク参照に留めるのが基本方針になりました。

3. 出力方式を変えるだけでコストが3分の1になった話

背景

日々の作業ログを要約してナレッジベース化するバッチ処理を組んでいます。当初はこの処理を複数パスに分けて実行していました。パスを分けることで各回の処理は軽くなる、という発想でした。

気づいたきっかけ

処理対象のデータ量が増えるにつれ（22KB→125KB）、複数パスに分けている分、都度のコンテキスト読み込みや呼び出しオーバーヘッドが積み重なっていることに気づきました。「1回あたりを軽くする」ことを優先した結果、呼び出し回数そのものがコストの主因になっていたということです。

対策

複数パス処理をやめ、単一パスの書き直し＋キーワードで絞り込んだコンテキストに変更しました。全体を一度に処理する分、1回あたりのコンテキストは大きくなりますが、無駄な呼び出しの重複がなくなります。

その後

処理対象のデータ量はむしろ増えているにもかかわらず、1回あたりのコストは＄1.10→＄0.36（約69%減）になりました。「処理を賢くする」より先に「呼び出し回数・パス数そのものを減らせないか」を検討する方が、効果が大きいケースがあるという発見でした。

4. 委任先の使い分け

背景

作業の一部を別のエージェントに振ることで、自分のセッションのコンテキストを消費せずに並行して処理を進められます。当初は「委任できるものはとりあえず委任する」という運用にしていました。

気づいたきっかけ

サーバーへのSSH接続が必要な調査を委任したところ、委任先のサンドボックス環境にはネットワーク制限があり、外部サーバーへの接続ができず、失敗・タイムアウトを繰り返しました。委任した分の時間とやり取りが無駄になり、結局自分で直接実行するはめになりました。

対策

サーバー接続が必要な調査・操作は最初からメインセッションで直接実行する
委任するのは、取得済みデータをもとにした後工程（ローカルファイル生成・ドキュメント化等）、つまりネットワーク接続が不要な部分だけに絞る
委任が失敗・タイムアウトしたら、粘らずすぐ直接実行に切り替える判断を早める

その後

「委任できるかどうか」を作業の種類ではなく「ネットワークアクセスの有無」で先に判定するようになり、無駄な失敗を減らせるようになりました。

失敗した節約策

節約のつもりが逆にコストを増やした事例もあります。

単純な単発作業（1回のツール呼び出しで完結する程度の軽い作業）を、わざわざ別セッション（フォーク）に委任したことがありました。狙いは「メインセッションのコンテキストを汚さないこと」でした。ところが実際には、委任先が該当ツールを一度も呼ばずに「作業中です」とだけ返して完了扱いになっていました。実行ログを確認すると、ツール呼び出し回数が0件だったことが分かりました。

結果、状況確認のための再指示が1往復増え、フォークに割り当てたコンテキストごと無駄になりました。フォークという仕組みは本来、ノイズの多い出力をメインセッションのコンテキストから追い出すためのものです。1回のツール呼び出しで終わる程度の出力は、そもそもノイズになるほど大きくありません。

教訓: フォークへの委任は「出力がノイズになるほど大きい処理」にのみ使う。単発の軽い呼び出しは、迷わずメインセッションで直接実行した方が安い。また委任した場合は「完了しました」を額面通り受け取らず、実際に何回ツールが呼ばれたかを確認する習慣が必要です。

今の運用ルール

これらの経験から、今は次のルールで動いています。

複数のやり方がある作業は、着手前に「どちらがトークン消費が少ないか」を一呼吸おいて検討する
長大な出力が乗りうるコマンドは、対象・列を絞ってから実行する
常時読み込むファイルは、追加するたびに「本当に毎回必要か」を問い直す
委任するかどうかは、作業内容ではなく「ネットワークアクセスの要否」「出力のノイズ量」で判断する
委任先からの完了報告は鵜呑みにせず、実際の実行結果を確認する
定型の進捗報告は1〜2行に留め、詳細は聞かれたときだけ出す

どれも特別なツールを必要としません。「コマンドの選び方」「ファイル構成の見直し」「委任するかどうかの判断」といった、地味な運用上の工夫の積み重ねです。

おわりに

AIエージェントに仕事を任せ始めると、最初は「できること」に目が行きますが、しばらく運用すると次の課題は必ず「これをどのくらいのコストで回し続けられるか」に移ります。

今回紹介した4つは、日々の運用の中で踏んできた地雷のごく一部です。ツール検索の精度、調査時のデータ絞り込み、モデルグレードの使い分け、常時接続するツール群の管理など、まだ紹介していない事例もいくつかあります。続きはZennで連載形式で発信しています。

元記事（Zenn）: https://zenn.dev/sh39works/articles/6ff9e50f342be3
note版: https://note.com/sh39/n/nf438df3aaedd