8月7日、ソフトウェア開発の制約理論的アプローチを専門に発信するメディア・Constraint Labが「How AI changes our system of work」と題した記事を公開した。AIの登場によって私たちの「仕事のシステム」を支える前提がどのように崩れたかを、エリヤフ・ゴールドラットの制約理論（Theory of Constraints）を枠組みとして分析した内容だ。
崩れた「荷重壁」の前提
まずこの記事の核心から紹介したい。
私たちがこれまで作ってきた仕事のルール——コードレビュー、リンター、アップフロント設計、自動テスト、リスク分離——はすべて、ある暗黙の前提の上に成り立っていた。
「合理的な仮説には必ず人間の理解が伴う」
コードレビューでは、承認者に電話して実装を説明できると想定していた。リリースに含まれる20コミットの背後には、それぞれを理解した20人がいると想定していた。
だが今はこうだ：
- コードレビューの承認者？ AliceかもしれないしClaudeかもしれない
- テストをすべてパスしたPR？ BobかもしれないしCodexかもしれない
- 10ページの設計ドキュメント？ ほぼ確実にLLMが書いた
この前提はもはや成立しない。 記事はこれを「荷重壁（load-bearing）だった前提が崩れた」と表現する。仕事のルールはすべてこの前提に依存していたため、ルールの全体を見直す必要がある、というのが記事の主張だ。
「トークン最大化」では足りない
AIの活用を語る記事は多いが、この記事がユニークなのは制約理論を枠組みとして使っている点だ。制約理論はゴールドラットが『ザ・ゴール』をはじめとする著作群で体系化した思想で、システム全体のボトルネック（制約）を特定し、そこに集中して改善することで全体最適を図るアプローチである。
ゴールドラットは新技術を正しく活用するには4つの問いが必要だと述べている（この問いの枠組みは『It's Not Luck』や『Critical Chain』でも展開されており、著作群を通じて発展してきたものだ）。
- 新技術の力は何か？
- 新技術はどの制約を取り除くか？
- その制約を回避するために、どんなルールがあったか？
- 新しいルールは何か？
記事はこの4問をAIに当てはめて分析する。単に「AIを使え」「LLMをたくさん動かせ」という方向性——記事ではtokenmaxxing（トークン消費量の最大化を目標とすること）と呼ぶ——は、グッドハートの法則的な問題があるだけでなく、全員がその方針に賛同していたとしても意味がないと指摘する。
AIの「力」は仮説生成と検証のコスト削減
記事はAIの能力を次の3点に整理する。
- もっともらしい仮説を安価に生成できる
- 仮説を安価に検証できる
- ゆるく構造化されたデータを別の構造に変換できる
ここで重要なのは、変換の結果が「正しいとは限らない」という点だ。必ず現実に照らして検証する必要がある。その検証プロセスは小さな科学的実験であり、出力は常に「仮説」である。
まとめると：AIは仮説の生成と検証を繰り返すことで、かなりの確率で正解に近い答えを安価に出せる。
AIが取り除いた制約とは何か
ソフトウェアはすべて仮説だ。「この命令セットはこの動作をするはずだ」という予測の塊である。従来、「もっともらしい仮説（＝合理的なコード）」を生成するには人間の努力と理解が必要だった。検証にも同様に人間のコストがかかった。
AIはこの前提を変えた。「合理的な仮説を生成するには人間の努力が必要」という命題が、文脈によっては部分的または完全に偽になった。
これが冒頭で述べた「荷重壁の崩壊」に直結する。既存のルールはこの命題が真であることを前提として設計されていたため、前提が崩れればルールの再設計が必要になる。
新しいルールはまだ答えが出ていない
記事はここで一旦立ち止まる。「新しいルールは何か」という第4の問いへの答えは次回の投稿に持ち越された。
ただし重要な注意点として、「古いルールを単純に否定すればいい」わけではないと釘を刺している。コードレビューを廃止してすべてmainに直接プッシュする、という選択肢は動くかもしれないが、コードレビューが担っていたセキュリティやアカウンタビリティの役割も同時に置き換える必要がある。局所的な変更はシステム全体への影響で評価しなければならない。
制約理論の文脈でいえば、ボトルネック（制約）を一つ解消しても、次のボトルネックが顕在化するだけだ。システムとして見なければ改善にならない。日常的にコードレビューや設計プロセスを運用しているエンジニアリングマネージャーやCTOにとって、AIの影響をシステム全体の視点から捉え直す切り口として有効な記事だ。
詳細はHow AI changes our system of workを参照していただきたい。
