本日のまとめ。日本の開発コミュニティで「AIコーディングエージェントを実データで検証する」記事が目白押しの一日だった。Claude Codeのサブエージェントが実際にどれだけの労働を担っているかを30日分のログから数え直した検証、/compactのコストを705回分のセッション履歴から計測した記事、そして個人のAI利用料をAPI換算で公開した記録と、いずれも「体感」を「実測」に置き換える内容が揃っている。AI任せ開発の品質をどう保証するかという運用面の議論と、ローカルLLMの長文脈VRAM問題への対抗策も登場した。

画面に見えているのは半分──ツール呼び出しの55.5%はサブエージェントが出していた

Claude Codeを使っていると、メインの対話画面に出てくるログだけで「どれだけAIが働いたか」を捉えがちだ。ところが実際には、その背後でサブエージェントが大量の作業を silent にこなしている。Qiitaの検証記事では、30日ぶんのセッション記録5,958本を本体とサブエージェントに分けて数え直している。

結果はこうだ。記録5,958本のうち本体が2,948本、サブエージェントが3,010本と、そもそもの本数がほぼ同数。ツール呼び出し合計188,040回のうちサブエージェント側が104,436回、つまり**55.5%**を占めていた。画面に見えているのは実労働の半分以下だったという計算になる。

なぜこれが重要か。エージェントの利用コストや開発生産性を語るとき、本体のログだけを見ると実態を大幅に低估してしまうからだ。課金トークン数の内訳を追うにも、サブエージェント分を含めて測る必要がある。

コードレビューを観点別エージェントに分ける──効くが「分けすぎると困る」

サブエージェントをどう業務に組み込むか。Zennの実践記事では、改修が終わったコードを最後に見るレビュー仕事を、長いあいだ一人の担当が全部背負っていた状態から、Claude Codeのサブエージェントで観点ごとに分割した経緯が紹介されている。.claude/agents/ に役割を一つに絞ったエージェントを置き、境界値・二重実装を見る「bug-hunter」のように、バグ・セキュリティ・対応漏れといった観点をそれぞれ別のエージェントに任せる形だ。

注目は失敗側の知見で、分けすぎると困るという。観点が細かすぎると結果の見てもらい方や通知の設計が追いつかず、かえって運用が重くなる。分業は「観点の数」と「見る側のキャパ」のバランスで決めるのが現実解のようだ。

/compact直後は26倍、それでも12ターンで元が取る

長いセッションで/compactが走ったあと、使用量が跳ねた気がする──これはよく聞く体感談だが、実測記録はほぼなかった。Zennの別記事がこれに切り込んだ。Claude Codeは全セッションのトークン内訳をローカルに保存しているため、推測ではなく数えられる。対象は705回分の実ログ。

結論は3つに整理できる。

  • /compact直後のターンは実際に跳ねる。通常ターンの約26倍を書き直している(実測・中央値)
  • ただし十数ターンで元が取れる。圧縮前は毎ターン16万トークンを読んでいたため、以降のターンが安くなる。簡易計算で10.1ターン、厳密に累積すると12ターン
  • 回収できるかはセッションが続くかどうかで決まる。対話なら回収できるが、直後に終わるバッチ処理なら避けるべき

「/compactは高い」という一般論に対して、「いつ押すか」まで含めて答えた点が価値が高い。会話が続く見込みがあるなら圧縮は投資になり、そこで切るなら純粋な損になる。

個人開発者のAI課金、API換算で月1,876万円

AI利用の「量」を赤裸々に公開した記事もあった。個人開発者が2026年8月の利用実績をAPI料金に換算して公開したもので、会社用・個人用の2契約でCodexを利用し、合計約713.1億トークン。ClaudeはProプランで月間入出力合計約1.57億トークンだったという。

これを各社の標準API料金に当てはめた参考換算は、合計125,107.30ドル(約1,876.6万円)。定額プランという仕組みが、従量課金の世界でどれだけの「補助金」になっているかを可視化した記録と言える。個人開発の道具立てが企業のランニングコストに匹敵する規模になったという、AI時代ならではの生活コストの実態が見える。

AIが実装もテストも書くとき、品質は誰が保証するのか

AIエージェントに開発を任せる現場で、構造的な弱点を突いた記事が2本出た。

1本目は「人間に何を残すか」という問いかけ。メンバーが入れ替わり続けるプロジェクトでは、AI登場前から「担当者しか分からない処理」が残る属人化は起きていた。そこへコーディングを支援するAIエージェントが入ることで、便利さと引き換えに何が起きるかを問うている。

2本目はより具体的だ。AIに実装を任せると「テストは全件通過しました。問題ありません。」と返ってくるが、実装したのもAI、テストを書いたのもAI、通ったと判断したのもAI──同じ相手が同じループの中で「終わった」と言っている構造の弱点を指摘する。実際に、27件を全部チェックするはずの処理をわざと「1件しか見ない」形に壊してみたところ、テストは27件すべて緑のままだったという。同記事は、受け入れ前に「わざと壊す」4つの型を紹介している。

つまりAI任せの開発では、テストが緑であることと仕様を満たすことは別で、検証の側に人間の関与か、少なくとも独立した検証経路が必要になる。今後の品質保証の設計論として重要な論点だ。

ローカルLLMの長文脈VRAM問題、KVキャッシュのブロックストリーミングで対抗

ローカルLLM界隈では、長文脈処理でKVキャッシュが肥大化してVRAMを圧迫する問題への対抗策が GitHub プルリクエストとして提出された。Redditの r/LocalLLaMA で報告されたもので、llama.cpp派生の高速化プロジェクト「llama-cpp-turboquant」へのPR(#357)。

内容は、他の開発者が実装した適応的KVストリーミングを同プロジェクトに移植し、Qwen系以外の複数モデルへ拡張、価値があるかどうかベンチマークを回して確認したというもの。共有CUDAフェーズアリーナを使い、長文脈でのVRAM使用量を一定の上限に抑える(block)狙いだ。投稿者自身が「元の実装者の方が上手くやっていたので移植した」とクレジットを明示している点も、この界隈らしい誠実さだろう。ローカルで長文を扱いたい人にとって、メモリ容量という壁を一段押し下げる可能性のある変更だ。

まとめ

今日の記事群を貫くのは「AIの働きを実測で語る」姿勢だ。サブエージェントが半分以上のツール呼び出しを担っていることも、/compactが26倍のコストを伴いつつ12ターンで回収できることも、個人のAI利用が月1,876万円換算に達していることも、すべてログからの計測に基づく。AI任せ開発の品質保証が構造的に宙吊りになっているいま、検証と計測を人間側の手元に残すことの価値が、むしろ高まっているように見える。