context-autopsyでAI開発ログを点検する：長い出力とトークン推定の読み方

この記事では0.2.0をMacで動かし、日本語を含む10種類の架空ログを解析しました。製品の集計結果は実際に取得していますが、ClaudeやCodexへ依頼して生成したログではありません。モデルの性能、請求額、実務での節約率を測った結果ではなく、ツールの読み方と限界を確かめる教材です。

公式リポジトリの開発者はAlistair Clark氏です。npmの公開記録では、最初の通常版0.1.0が2026年10月15日4:32、今回使った0.2.0が同日5:18に公開されています（日本時間）。Hacker Newsの作者投稿を入口に確認しました。公開直後なので、ここでは他社製品との優劣より、何を判断できるかに絞ります。

たとえば、テスト結果を毎回120行ずつ返す作業と、成功件数と失敗箇所だけを返す作業では、次のモデル要求に残る情報量が違います。context-autopsyはツール名やコマンドを手掛かりに種類を分け、繰り返し現れる長い出力やエラーを集計します。指摘された行を自動で削除したり、エージェントの設定を最適化したりする機能ではありません。

チームで使うなら、「開発者の使い方が悪い」と結論づける前に、ビルドが冗長な出力を返していないか、同じ調査を繰り返す指示になっていないかを点検する材料になります。失敗時の詳細ログは原因調査に必要です。短くする対象は、内容を確認したうえで決める必要があります。

Nodeの条件はpackage.json、対応形式はREADMEで確認できます。公式はClaude Code・Codex・Roo Codeを実ログで検証したと説明していますが、全対応製品の全版で同じ精度を保証する意味ではありません。CursorのCLI版、GitHub Copilot Chat、Aiderは、この版の対応外として挙げられています。

使い始める際に重要なのは、対象ファイルを指定することです。公式トップの引数なしコマンドは、端末内にある対応エージェントのログを自動探索します。試しに表示だけ見たい場合には範囲が広いため、この記事ではファイル名を明示する手順にしています。

日本語架空ログと検算スクリプトのZIPを展開し、そのフォルダで次のコマンドを実行します。初回のnpxはnpmから0.2.0を取得し、キャッシュへ保存するためインターネット接続が必要です。版を固定しておくと、この記事と異なる版が自動で使われることを避けられます。

今回は公開npmパッケージを展開し、CLIの分岐と読み込み処理を確認してから動かしました。明示ファイルがある場合は自動探索へ進みません。解析経路には外部送信処理がなく、既存ログの変更も行いません。--copyはクリップボードを変更する別機能なので、今回の試用では使用していません。

レポートの「in context」は、取り込まれた内容の推定サイズです。「processed」は、その内容が後続のモデル要求に何回残ったとみなすかを掛けた推定量です。たとえば、早い段階で入った長いテスト結果は、あとから同じ会話が続くほど大きく計上されます。どの出力が繰り返し処理される構造になっているかを見る指標です。

これは本文を実際のモデルのトークナイザーで数え直す処理ではありません。推定関数は文字列長を3.8で割り、端数を切り上げます。ログに使用量があれば集計処理が補正しますが、補正倍率には0.5〜2の範囲があり、最初の要求から固定分も推定します。したがって、表示合計がAPIの記録と常に一致するとは限りません。

今回「A」を190文字並べた入力と、「あ」を190文字並べた入力は、どちらも50推定トークンでした。文字数を基にした概算であることを確認した結果です。日本語の実トークン数が英語と同じだと分かったわけではありません。言語が混在する案件で、細かな差だけを比較して良し悪しを決めるのは避けたいところです。

教材は架空の注文管理システムを想定しています。120件の成功行が並ぶテスト結果を2回格納し、その後に日本語名の計算ファイルを読む、という4要求分の記録を作りました。比較用には、要求数を変えずテスト結果だけを短い要約へ置き換えた記録と、長い出力の後に圧縮境界と要約を挟んだ記録を用意しています。

長い出力のケースでは、同じ内容の再登場も1,137推定トークンとして検出されました。圧縮境界を入れると、それ以前の内容を後続要求へ足し続ける計上が止まります。短い要約に変えたケースでも数値が下がりました。この比較から確かめられるのは、出力の長さと残り方を解析器が区別できたことです。実際の開発で同じ割合の削減が得られる、という結果ではありません。

実務に持ち帰るなら、毎回の成功ログは件数と要点を返し、失敗時には詳細を残す運用を候補にできます。ログ全文はローカルのファイルへ保存し、エージェントが必要になったときに該当箇所を読む方法もあります。ただし、要約で原因や警告が消えていないかは別に確かめます。数値だけを小さくするより、必要な情報を保ちながら繰り返しを減らす判断に使います。

キャッシュについては、各要求の入力合計を同じ1,000にし、内訳だけを「通常入力100・キャッシュ読込900」と「通常入力1,000・キャッシュ読込0」にした架空ログを比べました。4要求のprocessedは双方4,090でしたが、記録した入力合計は双方4,000です。キャッシュ内訳はJSONに残る一方、processedには料金の違いが反映されず、補正後の値にも差が残ることを確認しました。

そのため、processedに通常入力の単価を掛けて請求額を求める使い方はできません。料金確認には利用サービス側の使用量・請求情報と、そのモデルのキャッシュを含む単価を使います。この教材のusageは人為的に入れた値です。JSONのmeasured: trueは解析器が使用量フィールドを見つけたという扱いであり、この記事でAPIを実行した証明ではありません。

エラー検出にも注意が必要です。日本語の「失敗: 注文IDが見つかりません」という出力だけではエラーは0件、同じ記録にis_error: trueを付けると1件でした。0.2.0は明示フラグや特定の英語パターンを手掛かりにしており、日本語の意味を読んで判定しているわけではありません。エラー0件を、作業が全て成功した根拠にはできません。

さらに、不完全なJSON行を1行挟んでもコマンドは正常終了し、その行を読み飛ばしました。読み取り処理は書き込み途中のログを想定して不正な行をスキップします。レポートが出たことと、全行を漏れなく集計できたことは別です。原本の件数やログ形式を確認し、重要な判断では元の記録に戻る必要があります。

ZIPには架空入力10件、製品のJSON出力、ログを生成して再解析するスクリプト、保存結果だけを検算するスクリプトを入れています。保存結果の20項目は全て通過し、検算対象のエラー件数を意図的に変えた別コピーでは失敗することも確認しました。教材の詳しい導入手順と取得する配布物のハッシュはREADMEにあります。

context-autopsyを使う価値は、料金を一発で確定することより、普段は見落としやすい長文出力や再読込に気づける点にあります。最初は範囲を絞った1セッションを読み、元ログと見比べる。改善案を一つ試したら、同じ条件の作業で情報不足や手戻りが増えていないかまで確認する。その順序なら、集計の限界を踏まえて開発手順の改善に役立てられます。