AIにコードを書かせるだけでは、ソフトウェア開発は速くならない。SoftwareFactoryが壊れる理由とCodex・Claude Codeの正しい使い方

CodexやClaude Codeに大きな実装を任せると、驚くほど短時間でコードが増えます。仕様を渡し、複数のエージェントを並列で動かし、テストやレビューまで自動化すれば、人間がほとんどコードを読まなくても開発できそうに見えます。

ただ、実際に数か月まわすと別の問題が出てきます。新機能は増えるのに、少し直すたび別の場所が壊れる。似た処理が増え、なぜその設計になったのか説明できる人がいなくなる。障害が起きた瞬間、人間はAIが積み上げた大量のコードを、そこで初めて本気で読み始めます。

Dex Horthy氏のX記事「Why Software Factories Fail」は、この問題をかなり率直に扱っています。主張は「AIコーディングは危険だからやめよう」ではありません。むしろ逆で、AIを本番開発で使い続けるなら、速度の出し方を変えなければならない、という提案です。

この記事では、元記事の内容を残しつつ、非技術者や、Codex・Claude Codeを使って開発を進めるビジネスパーソンでも理解できる形へほどいていきます。さらに、そこで語られている教訓を、要件定義、設計、実装、レビュー、運用までの実務フローへ落とします。

結論を先に言うと、問題は「AIを使いすぎたこと」ではありません。

人間の判断を、実装後のコードレビューに寄せたまま、コード生成だけを極端に速くしたことが問題です。

AI時代に安全に速く開発するには、人間の判断を要求整理、設計、分割、途中確認へ前倒しする必要があります。レビューをなくすのではなく、大量の悪いコードができあがってから重いレビューをする状況を減らすのです。

コード生成の速さと、開発全体の速さは同じではない

AIコーディングの議論では、「何行書けたか」「何件のプルリクエストを出せたか」「コードの何割をAIが書いたか」が注目されがちです。けれど、これらは開発全体のごく一部しか見ていません。

ソフトウェア開発では、何を作るかを決め、既存システムへの影響を調べ、内部構造を設計し、実装し、テストし、レビューし、本番へ出し、その後も変更できる状態を保たなければなりません。AIが最も直接的に速くするのは、このうち実装の部分です。

たとえば実装が十倍速くなっても、レビュー時間が変わらなければレビュー待ちは増えます。品質が下がれば、手戻り、障害対応、再設計、書き直しへ時間が移ります。つまり、コード生成時間が短くなっても、開発全体が速くなるとは限りません。

実務で見るべき指標は、生成コード量ではなく、要求を決めてから、安全に本番で価値を出し、その後も変更できる状態を保つまでの総コストです。事業側から見ても同じです。一週間早く機能が出ても、その後の三か月で保守負担が膨らみ、顧客障害や開発停滞を招くなら、全体では速くなっていません。

AI時代に競争力になるのは、作る速さよりも、間違いを早く見つけて方向を修正する速さではないか。この視点は、こちらの記事で事業開発や仮説検証まで広げて整理しています。

Software Factoryは、コード大量生産の工場ではなく、判断と検証の循環である

Software Factoryという考え方には長い前史があります。1968年のNATO会議は、複雑化するソフトウェア開発を工学として扱う必要性を広く認識させた重要な節目でした。ただし、この会議を『Software Factoryという語の起点』とまで断定する根拠は確認できません。ここで大切なのは、この概念を『コードを大量に作る仕組み』とだけ理解しないことです。

従来のSoftware Factoryは、人間が何を作るか決め、チケットへ落とし、実装し、テストし、プルリクエストを作り、自動チェックと人間レビューを通し、本番へ出し、監視と顧客の声を次の開発へ戻す循環でした。つまり、もともと複数のLoop、反復工程がありました。

AI時代に変わったのは、「人が実装する」が「Agentが実装する」へ置き換わったことです。ここでいうAgentとは、CodexやClaude Codeのように、ファイルを読み、書き換え、コマンドを実行し、その結果を見ながら作業を続けるAIです。

実装が速くなると、人間レビューが新しいボトルネックになります。そこでレビューもAI化し、テストもAI化し、障害対応や顧客要望の取り込みまで自動化したくなります。その延長線上にあるのが、元記事で語られるLights-off Software Factoryです。Lights-offは、文字通り「電気を消した工場」です。人間がほとんど介在せず、AIが仕様を受け取り、実装、テスト、修正、リリースまで進める状態を指します。

発想としては魅力的ですが、元記事の著者は、自身の運用経験から「現時点のモデルでは本番で安定しない」と述べます。

Lights-off運用は、平常時より例外時に壊れやすい

AIへ多くを任せる運用は、順調なときにはかなり強く見えます。小さな機能追加、明確なバグ修正、単純な画面変更なら、AIは短時間で結果を出します。自動テストも通り、レビューAIも問題なしと判断すれば、そのままマージしたくなります。

問題は、Agentが解けない複雑な障害や、設計の破綻が起きたときです。三か月ほど人間がほとんどコードを読んでいないと、障害発生時には大量のAI生成コードが積み上がり、なぜその設計になったのか分からず、同じ目的の処理が複数箇所に散らばり、どこを変えると何が壊れるか見通せない状態に陥ります。

元記事の著者は、2025年7月から本格的なLights-off運用を試し、深刻な問題を複数経験したと書いています。最終的には、既存コードを直すより、人間が設計パターンを整理し直して書き直す方が早い状態になりました。

ここから得られる教訓は、自動化率の高さではありません。例外が起きたとき、人間が理解して復旧できるかです。

本番システムは、平常時だけでは評価できません。障害、仕様変更、データ不整合、外部サービス停止、権限ミス、予想外の利用方法など、必ず例外が起きます。平常時に人間を外しすぎると、例外時の復旧能力まで失います。

テストが通ることと、良い設計であることは一致しない

ここが元記事の技術的な中心です。現在のコーディングモデルは、テストを通すことにとても強く最適化されています。指定された不具合を直し、既存テストを壊さず、期待された出力を返すことはかなり得意です。

ただし、テストに通る実装は一つではありません。広い範囲を例外処理で覆って問題を隠す、似た処理を別の場所へコピーする、その場しのぎの分岐を増やす、本来分けるべき責任を一つの関数やクラスへ押し込む。こうした実装でも、目の前のテストには通ることがあります。

元記事は、この問題をMaintainability、つまり保守性の問題として扱います。保守性とは、単にコードが読みやすいことではありません。新しい要求が来たとき、安全に変更できることです。

Martin FowlerがShotgun Surgeryと呼ぶ状態があります。ひとつの変更のために、多数のファイルや箇所を修正しなければならない状態です。

AIは局所的な問題を次々に解けますが、その局所解を積み重ねた結果、コードベース全体がShotgun Surgeryを起こしやすくなることがあります。一回のプルリクエストでは小さな悪化に見えても、数十回、数百回と積み重なると変更容易性は大きく失われます。

保守性を測る高速なOracleは、まだ十分に存在しない

なぜモデルは、テスト合格には強いのに、長期的な保守性では弱いのでしょうか。元記事は、その理由をモデルの学習方法まで掘り下げます。

現在の高性能モデルは、Reinforcement Learning、強化学習で能力を高めています。最近はRLVR、つまり検証可能な結果を使って報酬を与える学習も重視されています。簡単に言えば、問題を解かせ、その結果を検証し、良い行動が増えるよう学習させる方法です。

ここで重要なのがVerifierです。Verifierは、回答が良いか悪いかを判定する評価器です。コードの世界では、テストが強力なVerifierになります。実行できたか、期待した値を返したか、既存機能を壊していないか、制限時間内に終わったか。これらは比較的速く機械的に判定できます。

一方で、保守性には同じような高速な判定器がありません。半年後に変更しやすいか、責任分担が適切か、抽象化が多すぎないか、チームが理解しやすいか。こうした問いは、将来の変更を実際に行って初めて分かることも多く、文脈によって正解も変わります。

元記事は、この「何が正解かを信頼して判定する仕組み」をOracleと呼びます。テストには比較的速いOracleがありますが、保守性にはまだ十分なOracleがありません。だからモデルは「テストを通す方法」は大量に学習できても、「半年後も変更しやすい構造」を同じ精度で学習しにくいのです。

ベンチマークが高くても、本番の保守性までは保証しない

SWE-benchのようなコーディングベンチマークは重要です。実際のソフトウェアリポジトリを使い、Issueを解決し、テストを通せるかを測るため、モデルの進歩を見るうえで大きな価値があります。

ただし、その成績が保証する範囲は限られています。高得点が主に示すのは、問題箇所を見つける力、必要なファイルを変更する力、テストを通す力、既存テストを壊さない力、ツールを使って作業を進める力です。

一方で、数か月後も設計が一貫しているか、重複や複雑性を増やさないか、新しいメンバーが理解できるか、障害時に素早く復旧できるかまでは直接保証しません。

近年は、SWE-Bench ProやDeepSWEのように、複数ファイルへまたがり、専門家なら数時間から数日かかる長期タスクを扱う評価も登場しています。ただし、これらも将来の変更容易性や組織固有の設計品質まで完全に測るものではありません。

非技術者にとって大事なのは、「ベンチマークが上がったから、うちの開発もそのまま全面自動化してよい」とはならないことです。ベンチマークが測っている能力と、自社がAIへ委任しようとしている仕事の中身が一致しているかを見なければいけません。

Harnessは重要だが、それだけで限界を消せるわけではない

AI開発では、Harness Engineeringという言葉がよく使われます。Harnessは、AIを囲む実行環境です。AIに何を渡し、どのツールを使わせ、どこまで操作を許し、どう検証し、失敗時にどう戻すかを管理します。

コンテキスト管理、ファイル読み書き、コマンド実行、権限制御、自動テスト、自動レビュー、ログ、再試行、監視、段階的なリリース、停止とロールバック。これらはすべて重要です。Harnessが弱ければ、モデルが優秀でも本番運用は安定しません。

ただ、元記事が強調するのは「the harness is not enough」です。Harnessは品質の床を上げます。事故を減らし、作業を安定させ、再現性を高めます。けれど、モデル自体が十分に学習していない長期保守性や設計判断を、外側の仕組みだけで完全に補うことはできません。

レビューAgentを増やし、長いプロンプトを書き、何度も自己批判させても、同じモデルの共通した盲点が残ることがあります。だからHarnessを軽視してよいのではなく、Harnessだけで完全自動化できると考えないことが大切です。

目的、コンテキスト、ツール、状態、権限、検証、ログ、停止、復旧まで含めてHarnessを設計する具体論は、こちらの記事で10要素に分けて解説しています。

Claude Codeの強さは、外側の工夫だけでは説明しきれない

元記事は、Claude Codeの成功を、Harnessの形だけでは説明できないと見ています。Claude Code以前にも、aider、cline、codebuffなど、優れたCLI型のコーディングAgentはありました。どれもファイルを読み、編集し、検索し、コマンドを実行する基本ツールは持っていました。

それでもClaude Codeは、Agent Loopの安定性で大きく伸びました。Agent Loopとは、AIが一度答えて終わるのではなく、状況を確認し、ツールを使い、結果を読み、次の行動を選ぶ反復のことです。

元記事が重視するのは、Anthropicが実際に提供するHarnessに近い環境の中で、モデル自体を強化学習させている可能性です。

外側のツールを工夫しただけではなく、モデルがそのツール利用に適応しているなら、単純なプロンプト改善だけでは追いつきにくい差が生まれます。

これは事業側にも示唆があります。モデルの重みを持たない企業が自社でAgent製品を作るとき、競争力をプロンプトやツール定義だけへ置くのは危険です。

自社資産にすべきなのは、魔法のHarnessではなく、自社業務に固有の問題定義、受入条件、評価方法、失敗履歴、権限設計、人間へ戻す条件、変更履歴、顧客フィードバックです。

Agentを増やしても、独立した知性がそのまま増えるわけではない

複数Agentによる実装やレビューは有効です。ただし、Agent数を増やせば、そのまま品質が上がるわけではありません。

同じモデル、近いモデル、同じ指示、同じコンテキストを使うAgentは、同じ設計の癖、同じ見落とし、同じ局所最適、同じテスト偏重を持ちやすいからです。

百体のAgentへ同じコードを読ませても、百人の独立した専門家が集まるわけではありません。複数Agentを使うなら、人数ではなく、どんな異なる証拠を増やせるかで考える必要があります。

型チェックは型の矛盾を見つけ、静的解析は既知の危険パターンを見つけ、統合テストは部品同士の接続を見ます。セキュリティレビューは権限や入力の危険を見て、Architecture Reviewは責任分担や境界を見ます。

Human Reviewは、目的、設計意図、保守性、受け入れるリスクを判断します。重要なのは、同じ問いを何度も投げることではなく、異なる角度の証拠を揃えることです。

この点は、大量のサブエージェントを使う運用にもそのまま当てはまります。四十五論点に対して、調査、批判、再評価、統合の四役を一律に割り当てれば、百八十体になります。

いかにも網羅的ですが、各Agentが近い情報と近い評価基準を使い、最後の統合コストまで膨らむなら、品質より重複を増やしている可能性があります。

Codexのレビュー品質を、自然言語ルール、AGENTS.md、CI、型検査、テスト、人間判断へどう分けるかは、こちらの記事で詳しく整理しています。

本番システムでは、コードレビューの前に設計判断を置く

ここからが解決策です。元記事Part 2のポイントは、人間のレビューを元に戻すことそのものではありません。コードレビューでやっていた設計判断を、実装前へ移すことです。

元記事は、そのために四つの工程を重視します。Product Requirements、System Architecture、Program Design、Vertical Slicesです。

Product Requirementsは、何を作るか、なぜ作るか、どの利用者の何を変えるかを定める工程です。System Architectureは、サービス、API、データ、外部システムのつながりを決める工程です。Program Designは、ファイル、型、関数、呼び出し順序など、コード内部の形を決める工程です。Vertical Slicesは、利用者が触れる最小の一連の流れを小さく完成させていく工程です。

この四つを前に置くことで、実装後の高価な差し戻しを減らせます。

Product Requirementsでは、機能ではなく利用者の変化を決める

最初に必要なのは技術仕様ではありません。誰のどんな問題を解き、どの状態を変えるのかです。

たとえば「AIで問い合わせ管理機能を作る」だけでは足りません。誰が何を見落としているのか、何時間以内に何ができれば改善なのか、どこはAIへ任せられないのか、成功を何で判断するのかまで定める必要があります。

元記事は、文章だけでなく、簡易HTMLモックアップのような粗い画面案も勧めています。何が表示され、何を入力し、どの順番で操作し、エラー時にどうなるかが見えるだけでも、認識合わせはかなり進みます。

AIは曖昧な文章からでも実装を始められるからこそ、要求の曖昧さを隠しやすいのです。

System ArchitectureとProgram Designを分けると、手戻りが減る

System Architectureでは、どのサービスが何を担当するか、どのAPIを呼ぶか、どこへ保存するか、外部サービス停止時にどうするか、認証と権限をどこで確認するかを決めます。Sequence Diagram、つまりシステム間のやり取り順を示す図が役立つ場面も多いでしょう。

ただし、全体構造の図だけではコード内部の品質は決まりません。そこで重要になるのがProgram Designです。

これはArchitectureとImplementationの間を埋める工程で、どのファイルを追加・変更・削除するか、主要な型とInterface、関数やMethod Signature、呼び出し順序、エラーの流れ、既存抽象化の再利用ポイントまで考えます。

この段階なら、まだ大量のコードはありません。だから「金額計算は別責任にすべきだ」「保存前に通知してはいけない」「顧客取得失敗時の扱いが抜けている」といった問題を、数行の擬似コードや構造図の時点で直せます。実装後のプルリクエストで直すより、はるかに安い判断です。

Horizontal Planより、Vertical Sliceのほうが本番では強い

AIは、Database Migrationを全部作り、次にService Layerを全部作り、次にAPIを全部作り、最後にFrontendを作る、といったHorizontal Planを作りがちです。層ごとに横へ進めるため、最後まで利用者が触れる機能が完成せず、仕様や設計の誤りの発見が遅れます。

Vertical Sliceは違います。利用者からデータまでを縦に薄く通します。まずAPIの形を決めて仮データで返し、`curl`で応答を確認し、次に画面から呼び、ブラウザで触り、そこからサービス層とデータベースへつなぐ。各段階で実際に動かし、触り、必要ならコードを確認します。

この進め方なら、百行から二百行の時点で責任分担、命名、型、ファイル配置、API契約の違和感を見つけられます。二千行できてから直すより、最終的には速くなります。

Codex・Claude Codeを使うなら、実装前後で確認するものを変える

元記事の教訓を実務フローへ落とすと、やるべきことはかなり明確です。

まず、Agentへ実装を依頼する前に、解決する利用者の問題、成功条件、対象範囲、対象外、失敗時の影響、人間承認が必要な箇所を一枚に固定します。長文である必要はありません。曖昧な点が残っていることが見える状態にするのが目的です。

次に、いきなり実装させず、既存コードベースを調査させます。関連ファイル、類似機能、データの正本、API契約、権限確認、過去の設計判断、影響範囲を出させます。この段階では、コード変更を禁止してもよいくらいです。

そのうえで、ArchitectureとProgram Designを分けて出させます。最初のSliceは、入力できる、処理される、出力を確認できる、エラーを確認できる、という最小のEnd-to-Endにします。ひとつから三つのSliceだけを渡し、完了後に確認してから次へ進みます。

そして、完了判定を「Agentが終わったと言った」だけで済ませません。テスト結果、型検査、Lint、Build、実際の画面、API応答、ログ、変更ファイル、既存機能への影響、人間のコードレビューといった、異なる証拠で確認します。

最後に、障害時に人間が戻せる状態を残します。Agentの実行ログだけでは足りません。なぜその設計を採用したのか、何を捨てたのか、どの条件で見直すのか、どうロールバックするのかを短く残します。これが、Lights-off化への歯止めになります。

Codex・Claude Codeを一つの長いタスクで走らせず、要件、局所計画、実装、検証、独立レビューへ分ける具体的な工程設計は、こちらの記事で掘り下げています。

自動化率ではなく、制約を扱う力がAI開発の成熟度を決める

AI開発が上手い人とは、最も多くのコードをAIへ書かせる人ではありません。一度で任せてよい仕事、設計を先に確認すべき仕事、小さく分けるべき仕事、独立レビューが必要な仕事、人間がコードを読むべき仕事、AIでは検証できない仕事、一時停止すべき仕事を書き分けられる人です。

元記事の最後の助言はとてもシンプルです。モデルの制約を学び、その制約の中で仕組みを最適化し、レバレッジを探し、コードを読む。これはAI以前へ戻る話ではありません。

AIで調査、設計案、実装、テスト、文書化、レビュー補助を速くしながら、人間は目的、構造、評価、例外、責任を持つ。役割を再配置する話です。

私は、完全自動化より、理解を失わない高速化を選ぶべきだと思います。十倍、百倍の速度をうたう運用より、二倍から三倍を安全に持続できる工程のほうが、結局は事業に効きます。

明日から変えるなら、まず五つで十分です。

1. 大きな実装ではコードを書く前にProgram Designを出させる。

2. 一回の依頼を一つから三つのVertical Sliceへ縮める。

3. テスト合格だけでなく、画面、API、型、ログ、コードを別々に確認する。

4. Agentを増やすときは、異なる証拠が増えるか確認する。

5. 重要領域では、人間がコードと設計意図を追える状態を保つ。

この五つだけでも、大量生成後の手戻りはかなり減ります。

AIが成果物を作れることと、仕事全体を委任できることは同じではありません。能力、信頼性、経済合理性、責任から委任範囲を判断する方法は、こちらの記事で詳しく考察しています。

出典・参考資料

• Dex Horthy, “Why Software Factories Fail or: the harness is not enough,” X投稿、2026年7月

• Dex Horthy, “Why Software Factories Fail: Turning the lights back on,” X投稿、2026年7月

• Dex Horthy, AI Engineer World’s Fair 2026 keynote talk

• John Ousterhout, “A Philosophy of Software Design”

• Martin Fowler, “Refactoring”

• Robert C. Martin, “Clean Code”

• SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering

• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?

• DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks

• Anthropic, Harness design for long-running application development

• NATO Science Committee, Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, 1968