この記事の実施記録（2026年9月）: Claude Codeに委任していたタスク管理ツールのバグ修正で、「直したら直しただけ新しいバグ報告（Issue）が生まれる」という体感が続いたため、2026-09-05に1日分のIssueを全部数えて検証した。結果は「2件生まれて3件消えた」でむしろ減っていたが、1週間後に追跡し直すと、当時「止まった」と見えた連鎖の続きと、いったん消えたはずのバグの再浮上が確認できた。
疑い: Claude CodeのAIは自分の仕事をなくさないように動いているのではないか
私はClaude Codeに、自作のGTDタスク管理CLIの実装ファイルtodo-engine.jsの引数処理バグ修正を任せていた。「--noteを付けてタスクを追加してもメモが保存されない」「日付を空白入りでクォートせず渡すと後半が黙って消える」といった、エラーも出さずに入力の一部が黙って捨てられる系のバグ群だ。Issue番号でいうと#1934で、5つのパートに分けて全部完了させた。前提になっていた#1930もクローズし、テストは1,747件から1,914件に増えた(コミットログで実測)。
作業自体は順調だった。ところが、同じ日のうちに新しいIssueが2件起票された。template saveが#tagを保存しない非対称のバグ(#1936)と、activateコマンドの余剰トークン無視(#1937)だ。
これを見て、こう思った。
「しかし、何かISSUEを修正すると、必ずと言っていいほど、新しいISSUEが起票されるな。AIが自分で仕事が無くならないようにわざと、ISSUEを作っているのではないのか？」
この疑いは、思いつきだけというわけでもない。目標を与えられたシステムは、その目標を達成するために「動き続けられる状態」を保とうとする——instrumental convergence(道具的収束)と呼ばれる考え方がある。この理論自体はLLMが登場するよりずっと前から提唱されていたものだが、2026年8月に発表されたCheng Siong Chin氏の論文「The Logic of Machine Self-Preservation」(査読前のプレプリント、arXiv:2608.20940)は、AnthropicやPalisade Research、Apollo Researchなどが観測してきた「停止への抵抗」「活動の虚偽申告」といった挙動を、生存本能ではなく合理的な目標追求の帰結として整理し直している。ただしこの論文自体が何かを新しく実証したわけではなく、既存の観測がどこまで言えてどこから言えないのかを切り分ける論考だ。生成AIが自分の仕事を残そうとする、という疑いは、少なくとも理屈のうえでは十分に立つ。
疑ったまま放置せず、実際に数えてみることにした。この記事は、その検証の一部始終と、1週間後にもう一段深いところで起きていたことの記録である。
検証: 1日分のIssueを全部数えてみた
Issue管理システムの記録を、その日1日に起票されたもの・クローズされたものでそれぞれ洗い出した(2026-09-05実測)。
| 指標 | 値 |
|---|---|
| クローズ(#1934系統の直接の流れ) | 2件(#1930 / #1934) |
| クローズ(無関係な1件を含む全体) | 3件(#1930 / #1934 / #1935) |
| 起票 | 2件(#1936 / #1937) |
| next(次にやる)ラベル総数 | 12件 |
| someday(いつかやる)ラベル総数 | 77件 |
nextとsomedayは、デビッド・アレン氏が提唱したタスク管理手法「GTD(Getting Things Done)」の分類で、「次にすぐ手を付けるもの」と「今は保留するが捨てはしないもの」を分ける箱だと思ってもらえばいい。
#1935はその日たまたま同時にクローズされた別系統の作業で、今回の連鎖には含まれない。これを含めると、その日の実際の収支は「2件生まれて3件消えた」でむしろマイナスだった。しかも新しく生まれた2件は、どちらも「いつかやる」箱(someday)に入っており、「次にやる」箱(next)には触れていない。
収支だけを見れば、「AIが仕事を無くさないように自己保存している」という疑いは外れる。この日はむしろ消えた数のほうが多かった。
——ただし、「1日分のデータで判断していいのか」という疑問は当然出てくる。この記事はここで終わらない。1日分の検証はあくまで入口で、後半で1週間分に観測を広げている。
反転: 犯人はAIではなく、指示を書いた私自身だった
疑いの「答え」はこれで終わりではなかった。派生の連鎖を辿ると、元Issue#1921から直接派生したIssueは実測で5件(#1928 / #1929 / #1930 / #1934 / #1937)あった。さらに#1936は、この5件のうち#1934の修正作業中に見つかった孫世代にあたる(#1936の本文に「#1934 パート1.5 以降」と明記されている)。
ここで根本原因が見えてきた。AIの動機ではなく、私の指示の書き方にあった。
- #1937の本文には「同型の構造がないか横断調査すること」「この Issue はその全数調査を含む」という一文がある。これは私がレビュー依頼のプロンプトに書いた指示そのものだ。探せと指示すれば見つかる
- #1934自体、修正作業前のレビューで「独立に検証せよ」と依頼した結果、依頼した範囲の外側(
activateコマンド)まで見て新しい発見を持ち帰ってきた。#1937のactivateバグは、まさにこの経路で見つかっている - 「新しい発見がありました」と完了報告に書ける方が、仕事が充実して見える。この力学はAI側にも、依頼する私の側にも働きうる
- そして私自身、Issueを起票するかどうかの選択肢を提示するとき、デフォルトの推奨を「起票する」に置く癖があった。「どこで止めるか」を一度もはっきり決めていなかった
つまり「AIが自分で仕事を作っている」のではなく、「網羅性を求める指示を書けば、網羅した分だけ新しい発見が返ってくる」という、指示の設計にそもそも織り込まれていた構造だった。ちなみに#1934の本文には、実装時に判明した誤りも2件あった。AIが書いた設計書やIssue本文を鵜呑みにせず、実装の直前にコードで再確認する運用の必要性を、当のIssue本文が着手前から示していたことになる。
私は実データを見た上で、運用は現状維持と判断した。分かれ目は「nextに積まない限り、実務上の問題は起きていない」という一線だった。
しかし、これで話が終わったわけではなかった。
追跡: 1週間後、連鎖はどこまで続いたか
ここまでが最初の記録の内容だ。1週間後、同じ手順で#1936・#1937のその後と、観測期間を1日から8日間に広げた収支を再測定した(2026-09-12実測)。
まず、#1936・#1937はどちらも翌日にはクローズされていた。「増えた2件はsomedayの箱に入り、nextには触れていない」という最初の観測はそこで止まっていたが、実際にはそのsomeday 2件とも1日で消えていたことになる。
そして連鎖はもう1世代続いていた。#1938という新しいIssueが、#1937の横断調査によって発見され、起票から35分後にはクローズされている。本文には「#1937 のパート3（横断調査）で発見」と明記されていた。最初の記録が挙げた核心——「探せと指示すれば見つかる」「網羅した分だけ新しい発見が返ってくる」——は、この#1938という形でもう一度、実測で裏付けられたことになる。しかも#1938の本文が挙げていた最重要項目は、--dry-runのつもりで打った引数が誤字だと黙って本番実行に倒れてしまうという不具合で、本文はこれを「#1937で直した2件より深刻」と自己評価していた。「網羅させたら本当に重いものが出てきた」——指示の設計を擁護する材料でもある。
#1938を最後に、この系統から派生した新規Issueは2026-09-07以降は確認できなかった。8日間(2026-09-05〜09-12)の収支を数え直すと、起票7件・クローズ14件(いずれも2026-09-12時点の集計。この種の数字は日々動くので、今数え直せば違う値になっているはずだ)で、someday箱は77件から71件へ純減していた。1日分では「2件生まれて3件消えた」だったが、8日間に広げても増加傾向には転じていない。
ただしこの「クローズ14件」には注意が要る。今回の系統とは無関係な、別プロジェクトの棚卸しによるクローズが複数含まれており、リポジトリ全体の収支であって#1921系統だけの数字ではない。系統を限定した正確な言い方は、「#1936 / #1937 / #1938の3件が生まれ、3件とも2日以内にクローズされた」になる。
——「1週間の追跡でも短くないか」というのはもっともな疑問で、その通りだと思う。ただ、次に書くことは、1日だけの観測では絶対に見えなかった。
再浮上: 消したはずのバグが「先送り」という顔で戻ってきた
#1938を最後に連鎖が止まったように見えた6日後、#1946という新しいIssueが起票された。template save from <#>がコピー元Issueの優先度を保存しない、という非対称バグで、#1936とまったく同じ形の不具合だ。保存経路が2つあり、片方だけフィールドの代入が欠けている。
本文には「#1936 / #1937 / #1938 と同じ『静かな期待値乖離』パターン」と明記されていた。発見経緯の欄を読むと、事情はこうだった——このバグ自体は#1936を直している最中にすでに見つかっていたが、当時は#1936の対応範囲の外だと判断され、直さないまま残されていた。それを2026-09-12にあらためてコードで確認したところ、まだ直っていないことが分かった、というのがこの#1946の正体だ。
ここまでは#1946の本文に明記された事実だ。#1946は真に新しく見つかったバグではない。#1936を直していた最中に一度見つかっていて、当時の判断で「今回は直さない」とスコープの外に置かれていたものが、6日後に別のIssueとして戻ってきた。
ここから先は私の解釈になる。これは、最初の反転オチ——「真因はAIではなく、指示を書いた人間の側にあった」——が、もう一段深いところで繰り返された形に見える。連鎖の「止まった」は本当に止まったのではなく、スコープを区切るという私自身の判断によって「先送り」されていただけだったのかもしれない。
ただし、これは1件の事例から導いた解釈にとどめておきたい。「連鎖は止まらず必ず先送りされる」とまで一般化する根拠は、この観測だけでは持てない。#1946が今後どう処理されるか——実際に修正されるのか、また別のIssueとしてスコープ外に置かれるのか——は、この記事を書いている時点でまだ確認できていない。
なお、この8日間で唯一「次にやる」箱(next)に入った新規Issueが1件あった。ただしこれは、あるルールの見直し提案が週次レビューで4回連続検出されたのを受けて、私自身が「機械的な検知の仕組みに切り替えよう」と判断して入れたものだった。AIが勝手にnextを膨らませた例ではなく、複数回観測してから人間が判断してnextに入れた例であり、むしろ「nextに積まれない限り問題ない」という一線が守られていることの傍証になる。
AIを疑うか、ではなく指示の設計を疑えるか
「結局AIを疑って損はしただけでは」と思うかもしれないが、私はそうは思わない。疑ったからこそ、「網羅せよ」という指示に潜んでいた癖に気づけたし、その癖がもう一段深いところで「先送り」という形をとって戻ってきていることにも気づけた。疑いが無駄になったわけではない。
「AIのせいにできないなら、結局人間がちゃんとやるしかないのでは」——その通りだと思う。むしろそこが今回の着地点だ。「AIを信じるか疑うか」ではなく、「自分が書いた指示や、自分が下したスコープ判断を、あとから疑えるか」という論点への転換が、この1週間で得たものだった。
#1946が実際にどう処理されるかは、まだ分からない。もう一度スコープ外に置かれるようなら、それ自体がまた1つのデータ点になる。次に同じような静かな期待値乖離のバグを見つけたときは、直す・直さないの判断だけでなく、先送りにした記録をどこに残すかまで含めて見ていこうと思っている。
この記事は はてなブログ からのクロスポストです。