コードの生産がほぼ無料になったら、瓶頸はどこへ?

コードの生産がほぼ無料になったら、ソフトウェアの配布の瓶頸は「コードを書く」から別のところへ移動する。問題を定義する、部分を組み合わせて動作する全体を作る、実際に正しいことを検証する、組織を調整する。 これは、ソフトウェア業界における制約理論（Theory of Constraints）の再現である。製造業は40年前からこの道を歩いてきた：一つの工程が安くなったら、瓶頸は消えない。代わりに、次の最も高いコストの工程に移る。ここで理解できるのは、普遍的な困惑の解決法である。AIプログラミングツールが全社に敷き詰められたら、コードの生産は速くなったが、配布の速度はあまり変わりなかった。

製造業グループのCIOが私に半年間のデータを示した。ITチームは80人以上で、AIプログラミングツールを全面的に導入した。単にコードの生産をみると、人均の提出量とマージ速度は3倍以上増加した。しかし、ビジネスサイドの感覚はまったく異なる。1つのスマートな生産計画の機能から立案から上線まで、3ヶ月かかった。彼はツールが2倍のスピードアップをもたらすと期待していたが、実際には「コードを書くのが速いだけ」というものを買っただけだった。彼の言葉は簡潔で、「私は数百万のライセンス料を支払って、開発者が忙しくなり、ビジネスが急がるだけを買った。

AI 技術の瓶頸はどこにあるのか

彼は、瓶頸の位置を間違っていた。彼の本当の瓶頸は別のものであった：新機能を追加するたびに、MES、ERP、品質検査システム、車間端末、監査報告基準など、多くのシステムを通過しなければならず、集成と連携が大部分の作業時間を占めていた。AI によって生成されたコードは、正式な検査基準が存在しないため、生産環境と間には障壁がない。コードを書く速度が速くても、間違った瓶頸の後ろに列を形成するだけであった。

# 一、製造業は40年前から知っていた：瓶頸は動く

現在を理解するには、製造業の40年前の経験を借りる必要がある。

1984年、物理学者の出身であるイスラエルのアドバイザーEliyahu Goldrattは、破産寸前の工場長が如何に工場を救うかを描いた小説《目標》（The Goal）を著した。小説の核心は一句话であった：あらゆるシステムの出力は、最も狭いリング（約束、つまり瓶頸）によって決まる。瓶頸以外のリングを拡張しても、総出力には影響がない。瓶頸自体を拡張するだけが、全体を速くする。瓶頸を拡張すると、すぐに瓶頸は次の最も狭いリングに移動する。このことが約束理論（Theory of Constraints、TOC）である。

自动化的瓶颈之旅

制造业之后 40 年的自动化史，几乎是一部”瓶颈搬家史”。当数控机床让切削变便宜，瓶颈挪到了换模和质检；当柔性产线让换模变快，瓶颈挪到了排产和供应链协同；当 MES 让排产变准，瓶颈挪到了需求预测和跨厂调度。每自动化掉一段，下一段就浮上来。自动化从不消灭瓶颈，它只给瓶颈换了个位置。

这条规律不是制造业的专利。2026 年 7 月，a16z 播客《Software in the Age of Agents》里，前微软 Windows 总裁 Steven Sinofsky 用企业软件的例子，独立得出了同一条结论。他的原话是：

“The long tail got no shorter. It just got longer in a different way.”（长尾一点没变短，只是换了个方式变得更长。）

自动化的规律

他举了 Amazon 客服：砍掉电话、让 chatbot 直接补发商品，看似省了人力，可后端立刻冒出”怎么防止同类问题再发生”的根因分析需求，比接电话更复杂。报销流程也一样：OCR 自动入账之后，财务要做的变成了差旅绩效优化、动态比价——工作没消失，只是从”录入”上移到了”分析决策”。一位微软老兵、a16z 合伙人，没用 Goldratt 的理论，却得出了和制造业 40 年前一样的判断。一个来自车间，一个来自企业软件，两条独立路径指向同一条规律。

不过要给这条规律补一个限定，免得被读成绝对真理。确实有瓶颈是被永久消灭的：打字员、电话接线员、铅字排版工——这些工种没有”上移”，是真切消失了。判断一种工作会被搬家还是被消灭，关键看自动化释放的产能是催生了新需求（经济学叫杰文斯悖论），还是单纯让这块需求萎缩。企业核心系统周围的多数工作属于前者：账算得越快，老板想看的分析就越多越细。所以这里的结论不是”自动化能裁掉多少活”，而是”把人和预算，从被自动化的那层，搬到新冒出来的那层”。（企业软件视角的长尾搬家，番外篇《企业软件粘性》有完整展开。）

ソフトウェアの距離に比べると、IT技術の話は近い。2013年、Gene KimはGoldrattの工場の話をほぼそのままIT運用に持ち込んで、IT運用を救うためにCIOがどのようにして制約理論を使うかを書いた「フェニックス・プロジェクト」（The Phoenix Project）：IT部門が会社を潰すところを救うためにCIOがどのようにして制約理論を使うかを書いた。なので、「ソフトウェアの瓶頸を考える」というのは既に検証されたパスではなく、臨時で使う比喩ではありません。

2、ソフトウェアに戻る：コードを書くことが最も安い部分に変わっている

三つの数字で、「コードの生産コストがゼロに近づいている」ということを説明する。

AI 技术博客

代码生成成本接近零

• Copilot：GitHub 自己的研究测出，在启用 Copilot 的文件里，约 46% 的代码由 Copilot 完成。注意口径，这是”启用文件内”的占比，不是全 GitHub 所有代码的 46%。
• Stripe：内部自研的 coding agent “Minions”，每周产出并合并的 PR 超过 1,300 个（早期 1,000，持续上涨）。这里有个关键细节值得记住：每一个 PR 都要经过人工 review 才合并。Stripe 把”写”自动化了，把”验收”留给了人。这一点第四节会用到。
• NVIDIA：黄仁勋公开说过，100% 的 NVIDIA 工程师都在用 Cursor 这类 AI 编程工具，”不用 AI 工作”在 NVIDIA 已经不被接受。

把三组数字叠在一起，结论很硬：生产一行代码的单位成本，正在快速逼近零。

尖锐的问题随之而来：既然写代码几乎不要钱了，为什么软件还是这么贵、这么慢、这么难交付？答案正是约束理论给的：你加宽了”写代码”这道工序，瓶颈只是挪走了。它挪去了哪里？

3. 四个瓶颈

この回では、4つのプロセスで瓶頸が発生している。

1. 問題の定義。
AIは数秒で「機能」というものを書くことができるが、「実際に必要な機能」は書くことができない。多くのソフトウェアプロジェクトは、作り上げたものが誰も使わないこと、最初から何を解決しようとしているのかを考えていないことから始まっている。コード生成が安価になったことで、「不明なビジネス問題を、明確で解決可能で価値がある規格に分解する」（問題の定義）が最も不足している、かつ最も高価なスキルになっている。製造業の同僚は、これに馴染んでいる。工芸路線や設計図を間違えると、車間で効率よく作業しても、大量生産で品物が不良になる。

2. システムの統合。
AIは「一つのコード」、「一つの関数」、「一つのページ」を生成するのが得意。しかし、実際に稼働するシステムは、数百の要素を統合し、それらがデータを共有し、境界を処理し、一致を保ち、エラーを耐えることができる。要素を生成するのは安価だが、要素を統合して、信頼性の高いシステムを作ることは高価である。このコストは、組織とアーキテクチャが一致すること、つまりコンヴェイの定理とチームのトポロジーに興味があることの問題である。製造業の CIO に戻ると、彼はコードを書く時間を費やしていない。MES、ERP、品質検査、報告などのシステムを連携する時間を費やしている。

第三道：検証。 代码量が増加し、信頼性が低下している。誰が「これは正解だ」と決定するのか？テスト、コードレビュー、可観測性、グレイデイ发布など、検証作業の負担は増加している。これは最も低評価されているバッテンリミットであり、製造業の反映も深い。このセクションは別のセクションで説明する。

第四道：組織の調整。 チームに AI エージェントが増えると、誰が何をするか、誰がチェックするか、誰が結果に責任を負うか？これはコンヴェイ定理とチームのトポロジーの延長であり、組織の調整自体がバッテンリミットになった。シリーズ第 11 篇では、組織のノードがすべて人間でない場合、治理がどのように核心競争力になるかについて説明する。

四、最も深い切断：検証、およびトヨタの「自働化」が教えること

四つのバッテンリミットの中で、最も容易に誤解されるのは検証である。多くの人は、「AI が速いので、さらにテストを実行してみましょう」ということを理解している。ただし、これは一方しかない。検証が高価になる理由を理解するには、トヨタの概念である「自働化」（Jidoka）を正しく説明する必要がある。

先に広く流布している誤解を正す。自働化は、「AI または機械を人間に代わりに」や、「人間を機械のように、いつまでも働くようにする」ことではない。両方の方向が逆である。

自動化的真髄

自動化的字面就藏着答案。日本語では「自動化」は普通の自動化ですが、豊田自動織機は特に「自働化」と表現しています。ここで「働」には人字の旁があり、人間の触れ合いを強調しています。

自動化の正確な意味は、機器や生産ラインが異常を検知すると、自動的に停止し、人間が介入し、原因を解決し、再び生産を開始することです。自動化には2つのメカニズムが並行して動作します。機器自体に異常検知機能が搭載され、機器が停止するだけでなく、生産ライン上の誰でも異常を検知すると、安灯の糸を引くことで、全線が即座に停止します。

品質は末端検査ではなく、各工程に埋め込まれて、即座に解決します。

ここには反直感的な結論があります。正確に、自動化が深まるほど、品質基準と人間の介入の負担は増加するだけです。自働化は人間を「繰り返し作業」から解放し、異常を検知し、停止し、原因を解決するという位置に配置します。豊田は一線の労働者に全線の停止権限を与え、自動化が強くても、問題が生じたときに人間が停止する能力を与えることを、「機械に人間の知能を与える」という言葉の本当の意味です。人間は常に存在し、原因を解決します。

ソフトウェアはこの道を再歩み、しかも急いでいる。GitClear の AI によるコード品質に関する研究では、重複コードブロックの増加や短期的な churn コードの増加が観察されている：AI は速くコードを書くが、そのコードは「見た目は正しい」だけだ。大量のコードが誰も一行ずつ手で書かれていない状況では、従来の「開発者が心の中で把握している」という信頼メカニズムは機能しなくなる。そのとき必要になるのは、ソフトウェア版のアンダン绳とラインストップメカニズムだ：

• テスト（ユニット、インテグレーション、エンドツーエンド）は「できるだけ行う」から「ハードル」として昇格し、通過しないとマージを許可しない；
• コードレビューの焦点は「書き方のチェック」から「意図と境界条件の確認」へ移行する：このコードは一体何を解決しようとしているのか、境界条件は十分にカバーされているか；
• 可観測性（モニタリング、ログ、トレーシング）が標準装備となり、オンラインでの挙動がコードそのものよりも問題の本質をより明確に示すからだ；
• グレーディッドリリース／フィーチャーフラグにより、AI が生成したコードをまず小規模で検証し、問題がないことを確認した後に本番展開する。

振り返れば、第2節のStripeの1,300件のPR：コードはエージェントが書くが、マージという最終チェックはすべて人間のレビューに残された。これがソフトウェアにおける「自働化」の生きたモデルだ：生産は自動化し、検収は人間の手に残し、人間に「それを止める」権限を与える。生産は安くなり、品質管理は高価になる——これは40年間変わらない法則だ。
自動化ループ：豊田生産線 ↔ ソフトウェア CI/CD
豊田生産線（自動化、人字の旁に自動化）
機械が自動で動作する製造の自動化
異常を検出する機械が自ら停止 / 拉安灯
人が介入し、根本原因を解決する最終検査ではなく、現地で解決する
製造を再開する人は停止を許可する
→
→
→
↓ 同じロジックをソフトウェアに適用する
ソフトウェア CI/CD（AI時代の品質ゲート）
AIがコードを生成するコードを書く / 自動化
テスト / レビューのカーソルを閉じるただし、合併は許可されない
人が意図を確認し、根本原因を修正する境界 / 可解釈性を確認する
合併 / グレイスケールの増量まず、小規模な範囲で検証する
→
→
→
製造の自動化、受け取りは人の「停止線権」に残す、自動化が深まるほど品質ゲートが重要になる
ストライプミニオンズ：週に 1,300+ PR がエージェントによって書かれ、すべての人が手動でレビューした後、合併される
自動化 ≠ AIが人を置き換える；自動化 ≠ 人が機械に変わる
= 異常の停止線 + 人が介入して根本原因を解決する（人間の触れ合いとともに自動化）

五、「問題定義」のプレミアム：プロンプトより価値のある能力

検証が過小評価されたボトルネックだとすれば、「問題定義」はさらに過小評価されている能力である。
プロンプトエンジニアリングは一時的に注目されたが、多くの人が「プロンプトが書けること」が核心能力だと誤解した。しかし、プロンプトとはあくまで「問題を表現する」ためのテクニックにすぎない。真に希少なのは、その一歩先にある問題定式化（problem formulation）——曖昧なビジネス上の課題を、明確で解ける価値のある問題に分解する能力だ。このステップは、AIが短期間で代替できない。なぜなら、AIはまず「問題が何か」をあなたが教えてくれるのを待たなければならないからだ。

製造業のベテランは、このステップの重みを最も実感している。エンジニアリング図面や製造プロセスが間違えば、下游の加工や組立がどれほど効率的でも、大量の誤った製品を生産するだけだ。ソフトウェアも同様だ。要件仕様が間違っていれば、AIは10倍のスピードで、誰も必要としない製品を次々と生み出す。

判断基準は明確だ：「コードを書く速度」を競うのではなく、「問題を分解する明確さ」を磨け。
組織内では、これを意味する。つまり、「要件定義」と「検証・受入」を正式な職位として設け、開発者が片手間でやるのをやめよ。AIが実装を安価にした今、この二つの職位のリターンが最も急激に上昇している。

六、四つの業界の実際のボトルネックは何か

「ボトルネックの移動」を四つの業界に当てはめると、それぞれのボトルネックは「コードを書くこと」にはない。

製造業。中心人物就是開篇提到的CIO。智能排產、質量追溯、能耗優化等功能，技術上並不難，現成的模型也很多。瓶頸在於MES/ERP/檢測/報送等多套系統的集成調試，以及車間終端的現場驗證。這類項目的代碼往往寫得很快，但MES/ERP等系統的集成調試耗時往往是寫代碼的數倍；唯有將驗收環節前置到車間終端與集成階段，缺陷才能即時攔截，而非等到投產時才暴露。

電信/運營商。一個套餐變更或政企專線開通流程，需穿越渠道、計費、CRM、網絡開通、裝維排程等多個領域。AI讓各領域的開發速度大幅提升，但跨領域的端到端集成調試與一致性驗證，才是工期的主體。運營商還有一個獨特瓶頸：合規與對賬。計費差一分錢都是事故，驗證的比重遠超任何其他行業。以政企專線開通為例，儘管AI加速了各領域開發，端到端集成調試加上計費對賬，仍常佔據總工期的絕大部分。

金融。クレジットリスク管理やマネーロンダリング対策のルールを調整する場合、アプリ間、コアシステム、リスクエンジン、データプラットフォーム、監督当局への報告までを跨ぐ。ここで検証される重みは極めて高く、1件のミスでもコンプライアンス事故になる。ボトルネックは説明可能性、監査可能性、追跡可能性にある：AIが書いたルールがどれほど正確でも、監督当局から「なぜその判断を下したのか」と問われて答えられなければ、リリースは許可されない。マネーロンダリングルールの改善は典型的な例だ：AIはルール作成を高速化するが、モデルの説明可能性審査と監督当局への対応を合わせると、全体のサイクルのほぼ半分を消費してしまう。

EC。プロモーションや大型セール機能は、商品、取引、マーケティング、倉庫、カスタマーサポートまでを跨ぐ。AIはページやAPIの作成を劇的に高速化するが、ボトルネックは負荷テスト、在庫一貫性、不正利用防止、精算に移った。セールの夜にダウンするのは、コードが遅かったからではなく、検証し漏れた境界条件だ。セール準備はその縮図だ：プロモーションページはAIが瞬時に生成できるが、エンドツーエンドの負荷テストと在庫一貫性の検証に、準備期間のほぼ半分が費やされる。

4つの業界に共通する点は明確だ：AIは「書く」ことを加速し、「つなげる」「検証する」「整合させる」ことで詰まる。節約した開発リソースをこの3つに投資することが、真の生産性向上につながる。

七、間違えた場合の影響：最も一般的な3つのミスマッチ

第一种：コードの書き方を速くする というのは、最も一般的な誤解だ。コードは、交付チェーンの一部にすぎない。加幅すると、チェーン全体が速くなるのではなく、瓶頸の後ろに半成品が溜まるだけだ。制約理論では、これを「ストック」と呼び、ソフトウェアでは未承認のPRと未連携のブランチを指す。結果は、開発者が忙しくなる、ビジネスが急迫する、出力が変化しないということだ。前述のCIOの状況と同じだ。

第二種：生産を速めることと、品質のチェックを省略する というのは、自働化の典型的な誤りだ。誰かが「AIでコードを書くことが速くて良くなるので、コードレビューを簡略化し、テストを省略できる」と思っているかもしれないが、実際は逆だ。生産が速くなると、品質のチェックがより重要になる。品質のチェックを省略すると、未検証のPRと未連携のブランチが増えて、欠陥が生産環境に急増することになる。

第三種：非瓶頸に資源を投入する というのは、制約理論がすでに明確に述べていることだ。集成が瓶頸であれば、AIのライセンスを購入するのではなく、集成に資源を投入することだ。検証が瓶頸であれば、開発者を増やすのではなく、検証に資源を投入することだ。非瓶頸に資源を投入すると、総生産量に影響を与えず、しかも会計が混乱するだけだ。正しい順序は、まず瓶頸を特定し、次に資源を瓶頸に投入することだ。

八、対決策者の提言

启示一：買ツール前は、まず瓶頸図を描く。 最近３回のデリバリを分解してみて、時間はどこに費やしたのか。コードを書くことができない、組み立てられない、誰もチェックしなかった、要求がまだまだ明確でない。明確にできないものは、技術的な層面でただの推測にしかならない。瓶頸図は、どんなツールの購入リストよりも価値がある。それが大企業の無駄IT投資の半分を防ぐ。

启示二：省めた能力を、要求と検証に投入する。 AIにより、開発が速くなった。人手が余った。人を正式に「要求定義」と「検証検収」のポジションに据え、コードを書くことを止める。AI時代で最も成長するのは、この２つのポジションの収益だ。

启示三：ソフトウェアに安全装置を設置する。 自動化の最も直接的な実装は、CI/CDにハードドアを設置すること。テストが通過しないとマージを許さない、レビューは意図と境界をチェックする、グレイデーは小範囲で先行、可観測性は必須。生産が自動化されるほど、安全装置はより厳しくなる。これは、「コードが無料」が「事故が無料」になるのを防ぐため。

启示四：人の位置を再配置せず、人を排除しない。 自動化は、同じ結論を導く。自動化が深まるほど、人は「判断、検証、原因の解明」に配置される。人を繰り返し作業から解放し、検証と調整に配置する。これは、AI時代の組織設計の核心であり、本シリーズの後半で詳しく説明する内容だ。

９、質問されるかもしれない

「試験的試点は、本当に瓶頸の部分を確認する必要がある」

試点も、まずは瓶頸の部分を確認する必要がある。試点のこの段階で、本当に瓶頸の部分を確認しているかどうかを確認する必要がある。実際に瓶頸の部分は、集成や検証にあり、その場合、「コードを書く」段階でAIを試点することは、非瓶頸の部分に資金を投入することになる。正確に第7章で説明されている3つの不適合のうちの1つを踏み込むことになる。まずは小規模な瓶頸診断を実施し、ツールの費用が値打ちがあるかどうかを確認する。

「検証の段階が、交付を遅らせる可能性はあるか？」

短期的には摩擦が生じるかもしれないが、長期的には加速する。検証の段階がなければ、「速い」とは、欠陥を生産環境に送り出す速さであり、返却コストは10倍以上になる。自動化の経験から、欠陥を直すコストは、欠陥を流し下流に送り出すコストに比べてゼロに近い。

「これは、AIの転換とは何の関係がある？」

関係は非常に直接的。AIの転換の最もよく踏み込む罠は、瓶頸が「コードを書く / 産能」にあり、そこにツールを購入して幅を広げることである。まず瓶頸の診断を実施し、資金を投入する場所を決定する。正確に、能力評価と価値シナリオの認識を《AIの転換 7ステップ教練枠組み》の先頭に配置した理由が、このためである。

AI 時代ソフトウェアエンジニアリングの変革 シリーズの第3回です。

反省：最近のデリバリで止まったとき、時間はコードを書くのに費やしたか、または組み立て、検証、調整に費やしたか？あなたのAIツールは、安定してデプロイされ、ユーザーが実際に使用できるコードを出しているか？あなたのCI/CDには、「テストに合格しないとマージしない」という厳しい条件があるか？3つの質問のうち1つに心配な答えがあれば、すぐにAIツールを買うのではなく、自分の瓶ネックを探すことから始めましょう。

次のステップ

このシリーズの第15回の「AI 時代ソフトウェアエンジニアリングの変革」シリーズの3回目です。コンウェイ（組織が決定するアーキテクチャ）、チームのトポロジー（組織をどう設計するか）、瓶ネックの移行（コードがほとんど無料で、瓶ネックはどこに移ったか）を通じて、次の回（第4回）では、より実践的な視点で主流のAIプログラミングツールを選択する方法について説明します。結論は反直感的かもしれませんが、選択は組織の決定であり、成熟度と治理レベルに応じて選びましょう。

シリーズの概要：このシリーズでは、AIプログラミングツール、組織アーキテクチャ、ソフトウェアエンジニアリングのパラダイムの最新の進化を追跡します。2026年のコンウェイ定理のAIエージェント時代の新しい変化、最新のツール生態系の成熟度など。シリーズをフォローすると、継続的に更新される洞察を得ることができます。

このシリーズについて

AI 時代のソフトウェアエンジニアリングの変革

「AI 時代のソフトウェアエンジニアリングの変革」は、電信、金融、製造、電商などの業界の CIO/CDO/CTO および数字化責任者のための深い研究シリーズであり、全 15 篇です。200+ の学術論文と業界レポートに基づいて、証拠に基づく決定を参考にするためのレベル付きマークアップが提供されます。

私は、前 IBM のエンジニアであり、ICF 認定コーチでもあり、運営者や大企業の AI / 数字化プロジェクトの実装に携わった経験があります。ここに書かれているのは、企業が坑を踏んだ実戦判断です。

参考来源（均已核实）

• a16z (2026). Software in the Age of Agents. The a16z Podcast.（前微软 Windows 总裁 Steven Sinofsky 金句 “The long tail got no shorter, it just got longer in a different way”，企业软件视角独立印证 TOC 瓶颈搬家律；一级来源——播客原声。立场标注：a16z 合伙人 / 前微软高管，VC 立场。嘉宾已核实：a16z 企业团队合伙人 Seema Amble、前微软 Windows 总裁 Steven Sinofsky（board partner）、a16z 撰稿 Elena Burger；播出 2026 年 7 月。）
• Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement.（约束理论 TOC 的原始出处，一级来源；以制造业工厂为场景的小说）
• Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press.（把 Goldratt 的 TOC 原样搬进 IT 运维，制造业→软件的桥，一级）
• Toyota. Toyota Production System — Jidoka（自働化）. toyota-global.com（自働化 = 带人字旁的自动化，异常停线 + 人介入解根因；安灯系统；一级来源）
• GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle.（Copilot 在启用文件内完成约 46% 代码，口径为”启用文件内”，一级）
• Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog；InfoQ 报道每周 1,300+ PR，全量人工 review（一级 + 二级）
• NVIDIA / 黄仁勋. 100% 工程师使用 Cursor 等 AI 编程工具的公开表态（一手言论）
• GitClear (2025). AI-Assisted Code Quality Research.（观察到 AI 辅助下重复代码 / 短期 churn 上升，支撑”验证变贵”，二级）
• Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press.（交付绩效由文化、流速、反馈决定，非个人编码速度，一级）