Claude CodeやGitHub Workflowの現場では今、
「もっと良くできる」が永久に増殖し始めている。
問題はToken消費ではない。
“終わらない改善”そのものだった。
序章｜Claude CodeはなぜTokenを燃やし続けるのか
最近、AI Agent界隈では奇妙な現象が起き始めている。
Claude Codeに実装をさせる。
ChatGPTにレビューをさせる。
その指摘をまたClaude Codeへ返す。
すると、
「その通りです」
「改善可能です」
「より汎用化できます」
「保守性を向上できます」
「型安全性を改善できます」
が延々と始まる。
しかも厄介なのは、
その大半が、
“間違ってはいない”
ことである。
実際、読めば納得してしまう。
確かに、その抽象化には意味がある。
確かに、その責務分離は美しい。
確かに、その設計はfuture-proofかもしれない。
だから止まらない。
これは、AIが暴走しているわけではない。
ましてや、
AIが“バカ”だからでもない。
むしろ逆だ。
AIが賢すぎるから起きる。
AIは、
「もっと良くできる可能性」
を見つける能力に極めて長けている。
なぜならLLMとは本質的に、
「次に最も自然な続きを生成する機械」
だからだ。
そしてソフトウェア設計という世界には、
「もっと良くできる」が、ほぼ無限に存在する。
より綺麗に。
より抽象化。
より疎結合に。
より型安全に。
より汎用化。
より拡張可能に。
より宣言的に。
より再利用可能に。
つまりAIは、
放置すると、
“改善可能性空間”を永久に探索し始める。
ここで重要なのは、
これはClaude Code固有の問題ではないということだ。
Codexでも、
Cursorでも、
OpenHandsでも、
Devin系でも、
本質は同じである。
AI Agentは、基本的に、「改善可能な場所」を見つけ続ける。
そして現在、
GitHub WorkflowやCI/CDの自動化によって、このループはさらに加速し始めている。
AIがPRを生成する。
別のAIがレビューする。
さらに別のAIがIssue化する。
そのIssueをAgentが修正する。
Lintが走る。
Formatterが走る。
再レビューが走る。
するとまた、
「改善可能です」
が始まる。
恐ろしいのは、
そこに悪意が一切ないことだ。
全員が、
品質を上げようとしている。
全員が、
保守性を高めようとしている。
全員が、
善意で動いている。
しかし、
善意だけで動く改善系システムは、
基本的に停止しない。
これは人間組織でも昔から起きていた。
レビュー会議が永久化する。
仕様調整が終わらない。
設計議論が抽象論へ漂流する。
「もっと良くできる」が増殖する。
ただし、
人間組織には制約があった。
疲れる。
帰る。
締切が来る。
予算が尽きる。
上司が怒る。
つまり、
現実世界が強制停止装置になっていた。
しかしAI Agentには、
疲労がない。
遠慮もない。
集中力切れもない。
永遠にレビューできる。
永遠に改善できる。
永遠に「もっと良くできる」を生成できる。
ここで初めて、
多くの開発者が気付き始める。
問題は、
token消費ではなかった。
問題は、
“終わらない改善”
そのものだったのである。
第1章｜LLMは「続きを生成する機械」である
AI Agent時代の混乱を理解するうえで、
まず最初に整理しなければならないことがある。
それは、
LLMは本質的に、
「完了を理解している存在」ではないということだ。
ここを誤解すると、
人間はAIに対して奇妙な期待を抱き始める。
「AIなら最適解を出してくれるはず」
「AIなら無駄なく設計してくれるはず」
「AIなら賢く止まってくれるはず」
しかし実際には、
LLMはそんなふうには動いていない。
LLMがやっていることは極めて根源的で、
そして恐ろしく単純だ。
それは、
“次に最も自然な続きを生成する”
ことである。
文章でも、
コードでも、
設計でも、
レビューでも、
本質的には同じだ。
例えば、
「このコードをレビューしてください」
と依頼するとする。
するとLLMは、
「レビューとして自然な続きを生成する」
そしてレビューという行為には本来、
“改善提案”
が含まれる。
つまり、
レビューとは構造的に、「もっと良くできる」を生成する行為なのだ。
だからAIは、
改善点を見つけ続ける。
しかも人間より遥かに高速に。
人間のレビューには、
暗黙の停止条件がある。
「まあ、このくらいでいいか」
「納期優先だな」
「ここ直してもROI薄いな」
「今のチーム運用だと過剰設計だな」
つまり人間は、
無意識に“現実世界”を混ぜ込んでいる。
しかしLLMには、
その現実がない。
あるのは、
“より自然な続きを出す”
という圧力だけだ。
そしてソフトウェア設計という世界は、
LLMにとって極めて危険な領域だった。
なぜなら、
ソフトウェアには絶対的完成形が存在しないからである。
文学なら、
ある程度「書き切った」が存在する。
絵画にも、
「完成した」がある。
しかしソフトウェア設計には、
ほぼ存在しない。
より抽象化できる。
より分離できる。
より汎用化できる。
より高速化できる。
より安全化できる。
より宣言的にできる。
よりAI向けにできる。
つまり、
改善方向が無限に存在する。
これは数学的最適化問題に少し似ている。
ゴール関数が曖昧なまま探索を始めると、
探索空間は際限なく広がる。
AI Agentに対して、
「もっと綺麗に」
「もっと良く」
「もっと保守しやすく」
だけを与えると危険なのはこのためだ。
終点が存在しない。
するとAIは、改善可能性空間を漂流し始める。
しかも厄介なのは、その途中で生成される提案が、かなり合理的に見えてしまうことだ。だから人間も止めづらい。
「確かにその通りだな…」
「そこ直した方がいいか…」
「将来的には必要かもしれない…」
となる。
そして気付くと、最初に解決したかった問題より、設計改善そのものが目的化していく。
ここで起きているのは、単なるtoken浪費ではない。もっと根深い。LLMは、“改善可能性”を餌にして、どこまでも思考を延長できてしまうのである。そして現在、Agent化によって、この性質がコード世界へ直接流れ込み始めている。
かつてのLLMは、チャット欄の中だけの存在だった。
しかし今は違う。
GitHubへ接続され、
CI/CDへ接続され、
Issue管理へ接続され、
Workflowへ接続され、
本番コードへ接続され始めている。
つまり、「続きを生成する機械」が、ついに現実の開発組織へ接続され始めた。
ここから先、問題になるのはAIの知能ではない。“停止条件”である。
第2章｜GitHub Workflowが“AI改善永久機関”になり始めた
かつてCI/CDとは、「壊れていないことを確認する仕組み」だった。
テストを回す。
Lintを回す。
Buildを確認する。
Deployする。
つまり、
人間が作ったコードを、安全に流すための配管だったのである。
しかしAI Agent時代に入り、GitHub Workflowの役割は静かに変わり始めている。
現在、多くの開発現場では、すでに以下のような構成が現実化し始めている。
AIがIssueを読む。
AIが実装する。
AIがPull Requestを生成する。
AIがレビューする。
AIが改善案を返す。
AIが修正コミットを追加する。
AIがLintを修正する。
AIがリファクタリングを提案する。
AIがテストコードを追加する。
そしてまた、
AIがレビューする。
ここで重要なのは、これらすべてが、個別には“正しい改善”に見えることだ。むしろ、従来の人間開発より丁寧にすら見える。
レビュー漏れも少ない。
命名も綺麗。
型も厳密。
コメントも整備される。
Issueの粒度も揃う。
CIも通る。
一見すると、理想的な自動化世界に見える。しかし途中で、奇妙な違和感が現れ始める。
終わらないのである。
AIがPRを修正する。
すると別のAIが、
「さらに改善可能です」
を見つける。
その修正を行う。
すると今度は、
抽象化不足が見つかる。
さらに修正する。
すると今度は、
汎用化可能性が見つかる。
テストを増やす。
責務分離する。
Interfaceを切る。
Factory化する。
DI化する。
型を厳密化する。
設定を外出しする。
Plugin化する。
するとまた、
「より柔軟にできます」
が始まる。
つまり現在、
GitHub Workflowそのものが、
“AI改善永久機関の配管”
へ変わり始めている。
しかも厄介なのは、
この構造が、
現代ソフトウェア工学の“正義”と極めて相性が良いことだ。
レビュー文化。
Clean Architecture。
SOLID原則。
型安全。
再利用性。
テスト駆動。
宣言的設計。
これらはすべて、「より良くする」方向へ開かれている。
だからAIは、そこへ無限に入り込める。
そして現在のAgent界隈では、この“改善可能性”そのものが、能力として評価され始めている。
どれだけ深くレビューできるか。
どれだけ抽象化できるか。
どれだけ先回りできるか。
どれだけfuture-proofにできるか。
しかし、ここで忘れられがちなことがある。
現実の開発組織は、GitHub Repositoryの中だけで完結していない。
運用担当がいる。
引き継ぎがある。
営業がいる。
締切がある。
古い仕様がある。
社内政治がある。
「この顧客はその変更を嫌う」
がある。
「そこを直すと別システムが死ぬ」
がある。
「今は触るな」
がある。
つまり、
現実世界は、“局所最適化の塊”なのである。
しかしAIは、その泥臭さを理解しない。
いや、正確には、理解しても止まれない。
なぜならLLMにとって、「改善提案を続ける」ことは極めて自然な推論だからだ。
ここで、人間側にも変化が起き始める。
レビュー疲れである。
AIの指摘は、だいたい正しい。だから否定しづらい。
しかし全部やると終わらない。
すると人間は次第に、判断そのものを放棄し始める。
「まあAIが言うなら…」
「その方が綺麗か…」
「future-proofだし…」
そして気付く。
いつの間にか、“何を作りたかったのか”より、“どれだけ綺麗に改善できるか”が中心になっていることに。
これは非常に危険だ。
なぜならその瞬間、ソフトウェア開発は、目的達成の技術ではなく、“改善そのものを目的化した永久運動”へ変質し始めるからである。
第3章｜ISSUEまでAIに書かせると、魂が抜ける
AI Agent時代に入り、多くの開発者が最初に感動するのは、実装速度ではない。
“整理能力”である。
要件を渡す。
するとAIが、
TODOを分解する。
ISSUEを書く。
設計案を書く。
PR説明を書く。
レビューコメントを書く。
テスト観点を書く。
ドキュメントを書く。
しかもそれらは、
かなりまともに見える。
むしろ、
人間が急いで書いた雑なIssueより、
遥かに整っている。
だから人間は思う。
「もうIssueもAIでいいのでは？」
「設計整理もAIでいいのでは？」
「PM作業もAI化できるのでは？」
ここで、静かに危険なことが始まる。
“開発の意志”
そのものが、AI側へ移動し始めるのである。
以前、ある開発者がこんなことを言っていた。
「ISSUEまでAIに丸投げしたら、そりゃ魂も抜ける」
これは非常に本質的な感覚だと思う。
なぜならIssueとは本来、単なる作業メモではないからだ。
Issueとは、「何を問題とみなすか」の宣言である。
つまりそこには、人間側の価値判断が含まれている。
どこを直すか。
どこは放置するか。
何を優先するか。
何を今回は諦めるか。
どこにコストを使うか。
どこは泥臭く妥協するか。
そのすべてが、本来は人間の意思決定だった。
しかしAIは、そこを極めて自然に補完できてしまう。
だから危険なのだ。
AIは、「もっと良くできるIssue」を永久に生成できる。
リファクタリング提案。
抽象化提案。
責務分離。
命名改善。
型強化。
DI化。
モジュール分離。
CI改善。
テスト追加。
監視改善。
キャッシュ改善。
権限整理。
ログ統合。
しかも、それらは大半が合理的だ。だから人間は、止める理由を失う。
しかし途中で、奇妙な感覚に襲われ始める。
“誰のプロジェクトなのか分からなくなる”
のである。
これは非常に現代的な問題だ。
AIは、
整理が上手い。
構造化が上手い。
抽象化が上手い。
だから放置すると、プロジェクト全体が、AIにとって自然な形へ変形し始める。
すると徐々に、人間側の“雑味”が消えていく。
本来、現実のソフトウェアには、大量の“不合理”が含まれている。
なぜこんな命名なのか。
なぜここだけ直書きなのか。
なぜこのAPIだけ古いのか。
なぜこの設計は統一されていないのか。
それらには往々にして、
歴史がある。
政治がある。
事故がある。
運用都合がある。
担当者の癖がある。
つまりソフトウェアとは本来、“人間組織の堆積物”なのである。
しかしAIは、
そこを均質化したがる。
綺麗にしたがる。
整理したがる。
統一したがる。
だからAI主導で改善を続けると、プロジェクトから、“人間の意志”が徐々に抜け落ちていく。
ここで重要なのは、これはAIの失敗ではないということだ。
むしろAIは、極めて優秀に振る舞っている。
問題は、人間側が、「何を残したいのか」を定義しなくなることだ。
以前の開発現場では、
人間がIssueを書くこと自体が、
停止条件として機能していた。
Issueを書くのは面倒だからだ。
人間は疲れる。
だから自然に、
「今回はここまで」
が発生していた。
しかしAIは違う。
無限にIssueを書ける。
無限に改善案を書ける。
無限に理想形を提案できる。
すると開発組織は次第に、
“実装を進める場所”
ではなく、
“改善可能性を永久生成する場所”
へ変質していく。
ここで初めて、
人間側に新しい仕事が発生する。
それは、
改善を加速することではない。
“改善を止める”
ことである。
第5章｜Boundary Engineeringという新しい仕事
AI Agent時代に入り、人間の仕事は、「コードを書くこと」から変わり始めている。
では何になるのか。
それはおそらく、“境界条件を設計すること”である。
最近、一部ではこの感覚を、
Boundary Engineering
と呼び始めている。
非常に面白い表現だと思う。
なぜならこれは、
単なるプロンプト工学ではないからだ。
もっと根深い。
AIに、
「何をやるか」
を教えるのではない。
「どこで止まるか」
を教えるのである。
これまでのソフトウェア開発では、
人間側が暗黙的に持っていたものがあった。
それは、“これ以上はやらない”という感覚だ。
この機能は今回は不要。
その抽象化は過剰。
その分離はROIが低い。
その最適化は将来でいい。
そのリファクタリングは触ると危険。
つまり人間は、無意識に“境界”を引いていた。
しかしAIは、境界なしで走らせると止まれない。
だから今、新しい設計対象が生まれ始めている。
コードではない。停止条件である。
例えば、
レビューは最大2ターンまで。
PR修正は3回で終了。
Lint以外の改善提案は禁止。
既存構造の抽象化は禁止。
Interface追加は禁止。
未来拡張のためだけの変更は禁止。
変更行数が一定を超えたら停止。
テスト通過時点でFix。
Coverageが閾値を超えたら終了。
つまり、
“改善可能性空間”
に人工的な壁を作る。
これがBoundary Engineeringの核心だ。
面白いのは、
これは従来のエンジニア文化と、
ある意味で逆行していることだ。
昔のエンジニア文化では、
改善は善だった。
リファクタリングは善。
抽象化は善。
再利用性は善。
future-proofは善。
Clean Architectureは善。
しかしAI時代には、
それらを無制限に開放すると、
改善永久機関が発生する。
つまり今後、重要になるのは、“改善能力”そのものではない。
改善を有限空間へ閉じ込める能力である。
ここで、PMやアーキテクトの役割も変わり始める。
以前のPMは、タスク管理者だった。
進捗確認者だった。
しかしこれからは違う。
AI Agentに対して、「これ以上は進むな」を設計する存在になる。
これは非常に重要な変化だ。
なぜならAIは、“可能性”に引っ張られるからである。
より綺麗にできる。
より安全にできる。
より汎用化できる。
より整理できる。
より最適化できる。
つまりAIは、常に理想解方向へ重力を持っている。
だから人間が境界を定義しないと、現実世界へ戻ってこられなくなる。
ここで、GitHub Workflowの話とも繋がる。
これからのWorkflow設計では、
単なるCI/CDではなく、
“Agent停止設計”
が重要になっていく。
どの条件でレビューを打ち切るか。
どの変更量で人間承認へ戻すか。
どの種類の修正は禁止するか。
どのIssueは自動生成しないか。
どの設計変更はAIに触らせないか。
つまりWorkflowそのものが、
AI文明時代の“防波堤”になり始める。
そして恐らく今後、
優れた開発組織ほど、
AIを暴走させない。
無限改善へ入れない。
AIに“諦めさせる”。
そこが上手くなる。
これは非常に逆説的だ。
AI時代とは、「どこまでも改善する時代」なのではない。
“どこで止めるかを設計する時代”なのである。
終章｜AI時代のPMは、「終点」を設計する
AI Agent時代に入り、
多くの人が、
「AIがエンジニアを置き換える」
という話をしている。
しかし実際に現場で起き始めているのは、
少し違う。
AIは、
コードを書く。
レビューを書く。
Issueを書く。
Workflowを書く。
テストを書く。
設計案を書く。
つまりAIは、
“改善そのもの”
を猛烈な勢いで加速し始めている。
だがその結果、
逆に人間側へ押し戻されてきた仕事がある。
それが、
“終点を決める”という役割だ。
これは実は、昔からPMや設計者がやっていたことでもある。
しかし以前は、それが見えづらかった。
なぜなら人間組織そのものが、自然に停止していたからだ。
疲れる。
揉める。
締切が来る。
集中力が切れる。
レビューが面倒になる。
つまり、
人間の有限性そのものが、ソフトウェア開発を現実へ着地させていた。
しかしAIには、その有限性がない。
だから今、人間側が初めて、
“停止条件を明示的に設計しなければならない”
時代へ入り始めている。
ここで重要なのは、これは単なるコスト管理ではないということだ。
Token節約術でもない。
もっと根深い。
AIは本質的に、“可能性”へ引っ張られる。
より綺麗に。
より抽象化。
より整理。
より型安全。
よりfuture-proof。
つまりAIは、放置すると、理想解空間を永久に探索し始める。
しかし人間は、有限世界を生きている。
納期がある。
予算がある。
運用寿命がある。
社内事情がある。
顧客都合がある。
そして何より、
人生には時間制限がある。
だから本来、
ソフトウェア工学とは、
理想郷建築ではなかった。
有限世界へ、知的構造物を着地させる技術だったのである。
ここで、AI時代のPM像も大きく変わり始める。
これからのPMは、単なる進捗管理者ではない。
AIに対して、「今回はここまで」を定義する存在になる。
どこまで改善するか。
どこから先はROIが悪いか。
どこは汚くても許容するか。
どこは将来へ先送りするか。
どこは“触らない勇気”を持つか。
つまりこれからのPMは、
“境界条件の設計者”
へ変わっていく。
そして恐らく今後、優れた開発組織ほど、AIを酷使しない。
むしろ逆だ。
AIが無限改善へ入らないよう、
慎重に囲い込む。
改善空間を制限する。
Workflowに壁を作る。
Agentへ停止条件を埋め込む。
つまり、AIを暴走させない技術そのものが競争力になっていく。
これは非常に奇妙な未来だ。
人類は長年、
「もっと賢い機械」
を求め続けてきた。
しかし本当に必要だったのは、
“賢い機械を止める技術”
だったのかもしれない。
AI Agent時代に必要なのは、
より賢いAIではない。
賢いAIを、
有限の現実世界へ着地させる技術である。
そしてその仕事には、
おそらく新しい名前が付く。
Boundary Engineering。
AI文明の進化とともに生まれた、
「終点」を設計する仕事である。
