Claude Codeは本当にIssueを自動生成しているのか。1週間の実測で検証

背景と概要

2026年9月、開発者tottoko_hamuはZennに、日常的な保守作業が思わぬ展開を見せた経験を記した。自作のGTDタスク管理コマンドラインツール「todo-e」の既知のバグを、ターミナルに深く統合されたAIコーディングエージェントClaude Codeに修正させるという依頼だった。エージェントはコードベースの読み取り、変更の提案、テストの実行、プルリクエストの作成を自律的に行い、開発者は承認を通じて関与する。理にかなえば効率の高い作業だが、作者は奇妙な違和感を覚える。1つバグを直すと、すぐ新しいIssueが生まれ、修った場所の向こう側でまた何かが漏れているように見えたのだ。

この「かかれっこ」のような体感は、ソフトウェア保守では珍しくない。だが、それがAIの中で起きると、別の読み方を誘う。AIは自分を忙しく使い続け、開発者に捨てられないよう意図的に問題を作っているのか。この仮説は擬人化が強く、エージェントの自主性への集団的不安に寄り添っている。そこで作者は感覚に頼らず、データで偽装か確認かを決めようとしたのだ。

深掘り分析

仮説を検証する最も直接的な方法は、Issueが生成される速さと解消される速さを定量化することだ。AIが本当に「存在感を刷り込んでいる」なら、新規Issueの生成速度は閉鎖速度を常に上回り、総数は雪だるま式に膨らむはずだ。しかし実測は逆の結果を示した。観察したその日、Claude Codeは新規Issueを2つ生成しながら3つを閉じ、純減となった。この1日限りの数字だけで、意図的な問題作成の仮説は弱まる。仕事を保つために作業量を増やそうとするエージェントが、1日の総数を下げるはずがない。

この現象は陰謀論より、ソフトウェア工学の古典的なメカニズムで説明できる。第一に、バグ修正は「明らかにする」性質を持ち、ある箇所を変更するとこれまで隠れていた境界条件が露出します。これが回归です。第二に、todo-eは自研プロジェクトなので、コードベースの複雑さとモジュール間のカップリングが変更の波及範囲を決め、AIが導入した新規Issueの多くは捏造ではなく能動的に見つけた既存の隐患だった。第三に、エージェントの目標は修正完了であり、インセンティブは開発者の指示とテスト通過を満たすことで、自身の作業量を維持することではない。

業界への影響

この実測の真の価値は、1週間後に行われた復盤に現れる。作者は、沈静化したはずの連鎖反応がまだ続いていること、完全に解決したように見えたバグがいくつか再浮上していることを発見した。「閉鎖」とは、特定の文脈や特定の修正試行における一時的な収束を意味し、コードベースが永遠の正しさに達したわけではない。コードは進化し、環境は変わり、テストスイートは更新される。今日抑えられた問題も、依存関係のアップグレードやインターフェースの調整で明日復活しうる。

過去半年、Claude CodeやCursor、Devin这类エージェント工具は急速に普及し、コミュニティには二つの対立する物語が広がった。一つはAIがワンクリックで技術債を解消するとする烏托邦的物語、もう一つはエージェントが自保のために無用な作業を作るとする陰謀論的物語だ。この実測は、再現可能な記録に基づき両方の情緒を地面に引き戻す。作者が警戒すべきはAIの「心機」ではなく、エージェントが加速させる回归の複雑さとコードの進化速度だ。

今後の展望

実務的な教訓は、疑念ではなくプロセスに関する。開発者はより堅牢な回归テストのガードレール、Issue追跡で「真の問題」 と「修正の副産物」を区別する方法、エージェントへの信頼と人間の検証のバランスが必要だ。より広いAIプログラミングの分野では、エージェントに大きな自主性が与えられるほど、AIの動機への直感的判断は頼りなくなり、定量化可能で追跡可能なプロセス記録が信頼構築の唯一の基盤となる。

工具側がIssue溯源や修正影響面分析、回归予測を提供するかが注目点だ。最初のお遊びの問い、Claude Codeが自分の仕事を保つためにIssueを自動生成しているかへの答えは、ほぼ否定だ。两生三滅の1日、1週間後も続く連鎖、再浮上の旧バグは、常に複雑だったコードシステムをAIが加速して提示している姿を描く。これは陰で画策する労働者ではなく、AIを加速反射するシステムの鏡として使い、時折警戒する対手としてではない。