ソフトウェアファクトリーは、人の介入をほとんど必要とせず、意図をテスト済みのコードへ変換できます。エージェントはキューに入った作業を引き受け、実装を作成してテストし、指摘に対応して、リリースに向けて準備します。十分なサンドボックス、ツール、評価器、再試行の仕組みがあれば、ソフトウェア生産プロセスの大部分を自律的に進められます。
チェックに合格すれば、そのチェックが対象とする挙動への確信は高まります。しかし、より難しい判断はその後に待っています。コードは仕様どおりに動作していても、不適切な境界、予期しない依存関係、あるいは変更の価値を上回るリスクをもたらすことがあります。
レビューゲートでは、コードが動作するかだけでなく、システムの一部にするべきかどうかもチームが判断します。
StrongDMは、ソフトウェアファクトリーの一つの形を紹介しています。人が意図、シナリオ、制約を定義し、その後はエージェントが従来のような人によるコードレビューを経ずに実装を生成し、検証するというものです。この方法では、検証ハーネスがより大きな責任を担います。
長く使い続けるシステムを構築するチームには、実用的な設計原則があります。レビューの深さは、誤りがもたらす損失に応じて決めるべきです。
VercelのCEO、Guillermo Rauchは次のように述べています。
だからといって、すべての変更で人がコードを一行ずつ読む必要があるわけではありません。定型的で範囲が明確に限定された変更は、自動チェックで進められます。しかし、セキュリティ、アーキテクチャ、顧客データ、公開インターフェースに影響する変更には、判断の過程が見えるレビューゲートが今も必要です。
自動化によって変更を前に進めながら、リスクと影響範囲に応じて人によるレビューを深める、ソフトウェアファクトリーのワークフロー。
コーディングの生産性向上は、リリースに近づくにつれて小さくなる
コーディングエージェントによる生産性向上は確かなものです。しかし、その効果は作業が本番環境に近づくにつれて小さくなります。
2026年のワーキングペーパー「Writing Code vs. Shipping Code」は、10万人を超えるGitHub開発者を調査しました。AIツールの世代が進むにつれてコーディング活動は大きく増えましたが、プロジェクト数や完了したリリース数の増加はそれより小さいものでした。著者らはこの傾向を、最も弱い部分が全体を制約する「弱い環」の問題として説明しています。レビュー、統合、テスト、リリースにまたがる人の作業が、生産の連鎖を制約しているのです。
プロセスに流れ込むコードは増える一方で、レビュー、統合、リリースには引き続き時間と技術的判断が必要です。
対策の一つとして提案されているのが、レビューゲートの自動化をさらに進めることです。Dex Horthyは「Why Software Factories Fail」で、テストやエージェントのループは、長期的な保守性よりも目先の正しさを評価しやすいと論じています。
テストは、定義された挙動が動くかどうかを数分で確認できます。しかし、不適切な境界や不要な結合、「ショットガンサージャリ」の代償は、数か月後、次の変更が本来より難しくなったときに表面化することがあります。
こうした遅れて現れるコストは、即座に得られる報酬シグナルとして表現しにくいものです。モデルは今日の評価に合格しながら、明日の作業をより高コストにしてしまう可能性があります。SlopCodeBenchのような長期タスクのベンチマークは、一連のチェックポイントを通じて要件が追加されていく状況で、エージェントがどのように対応するかを測定し始めています。
ビルドの成功は、有用な根拠です。保守性は、その変更が将来の作業にどのような形を与えるかにも左右されます。
ハーネスが測定できるのは、チームが確認方法を知っていること
ハーネスエンジニアリングは不可欠です。エージェントには、使用範囲を制限したツール、再現可能な環境、明確な停止条件、信頼できるフィードバックが必要です。
Addy Osmaniのエージェント時代のコード品質に関する論考は、ソフトウェア品質が、エージェントを取り巻く制約にますます依存するようになることを説得力のある形で示しています。
こうした制約は、デリバリープロセス全体に必要です。
- 型とコンパイラは、不正な状態を拒否します。
- ユニットテスト、統合テスト、プロパティテスト、ミューテーションテストは、挙動を検証します。
- リンターとセキュリティスキャナーは、既知の種類の問題を検出します。
- サンドボックスは、失敗の影響を閉じ込めます。
- CIとポリシーゲートは、必須要件を強制します。
これらのチェックは、測定可能な問題を素早く検出し、レビュアーに届く作業を減らします。
一方で、システムのより広い範囲にまたがる問いもあります。テストは、アサーションに合格したかどうかを報告できます。しかし、認証の変更をレビューするには、それが在庫検索、チャット、データストア、差分に含まれないAPIクライアントにどう影響するかを理解する必要があるかもしれません。リンターは、既存のアーキテクチャルールを強制できます。そのルールが新しいプロダクト要件に適しているかどうかの判断には、プロダクトとエンジニアリングの文脈が必要です。
自動チェックは根拠を提供し、レビュープロセスはその根拠を変更がもたらす影響に結び付けます。
レビューの深さは、誤りの代償に応じて決める
リスクに基づくレビューは、人の注意をどこに向けるかについて、チームに具体的な基準を与えます。
エージェントが生み出す変更が増えるほど、レビュアーはプロセス全体を監督し、失敗したときの代償が最も大きい判断に直接責任を持つことで、より大きな効果を発揮できます。
決定的な検証でカバーされた、範囲の狭い依存関係の更新には、人の注意はほとんど必要ないかもしれません。認証、課金、データ保持、公開APIへの変更には、より深いレビューが必要です。変更の作者は、開発者でもエージェントでもかまいません。レビューの経路を決めるのは、変更の範囲とその影響です。
Osmaniはエージェント時代のコードレビューに関する論考で、これを人が「ループの中」から「ループを監督する側」へ移ることだと説明しています。人はシステムを監督し、その出力をサンプリングして確認し、失敗の代償が大きい判断に注意を集中させます。
Horthyも別の方向から、似た結論に到達しています。人の判断は、プロダクトレビュー、アーキテクチャ、プログラム設計といった、より早い段階へ移ります。実装は、検証や軌道修正がしやすい、小さな垂直スライスに分けて進めます。
独立したレビューは、コードベースの文脈と組織のルールに基づく第二の見方をチームに提供します。根拠を明らかにし、より注意深く確認すべき作業を特定しながらも、出荷するかどうかの判断はチームに委ねます。
システム全体の視点からコードへたどれる経路が必要
従来の要約は変更を短くまとめますが、レビューには圧縮するだけでは不十分です。レビュアーには、要約の内容を検証する方法が必要です。
レビュアーには、互いにつながった二つの視点が必要です。
- 変更の意図、挙動、依存関係、リスク、想定される影響を示す、システム全体の視点。
- 説明を裏付ける関連する指摘事項、ファイル、正確な行を示す、コードの視点。
システム全体の視点があれば、レビュアーはファイルツリーから変更の全体像を組み立て直さずに済みます。二つの視点を追跡可能な形でつなぐことで、すべての主張を実装に照らして検証できます。
レビュアーは、コードの具体的な指摘事項からシステム全体の文脈へ、そして再びコードへと移動し、根拠と影響範囲の両方を理解できます。
大規模なプルリクエストを見ると、このレビューモデルに実際に何が必要なのかがわかります。以下のChange StackとBlast Radiusのデモは、レビュアーが変更の範囲から確認を始め、その根拠となるコードへ直接移動する方法を示しています。
Change StackとBlast Radiusのデモをご覧ください：
Change StackとBlast Radiusの実例
デモは、およそ35ファイル、2,000行に及ぶプルリクエストから始まります。元の差分には、FastAPIバックエンド、認証、SQLiteとQdrantのストレージ、AI画像処理、チャット、テスト、レビュー設定が含まれています。
Change Stackは、ファイル単位の差分を、API契約と起動、認証と永続化、AI処理と検索、チャットとAPI検証、レビュー制御を扱う意味的なレイヤーに再構成します。これらのレイヤーは、ファイルパスのアルファベット順ではなく、挙動と依存関係に基づく読み進め方をレビュアーに示します。
レビュアーは、データベース初期化の要約を選び、平文の認証情報とプロファイルデータを持つデフォルト管理者を挿入するコードへ移動し、その範囲に付いた重大な指摘事項を確認できます。
Blast Radiusは、影響を受けるシステム全体へ視野を広げます。このデモでは、直接変更された五つの領域を示し、プルリクエストでは変更されていないフロントエンドのAPIクライアントにも、影響が及ぶ可能性があることを特定します。
信頼できないユーザー名に関するセキュリティ上の指摘を、FastAPIのエントリーポイントから、認証と永続化を経て、SQLite、Qdrant、検索、チャットまで追跡できます。
このグラフは、変更がシステム内をどのように伝わるかを示すモデルをレビュアーに提供します。レビュアーは、そのモデルをコードに照らして検証し、その実装を取り込むべきかどうかを判断できます。
レビューの時間を、提示された説明の検証、前提への問い直し、設計の妥当性の判断に使えるようになります。
チームが信頼できるレビューゲート
レビューゲートは、その深さが変更の影響に見合っているときに信頼を得られます。定型的な作業は自動検証の根拠によって素早く進められますが、重大な変更には、何が問題となり得るのかをレビュアーが理解し、それぞれの主張の根拠となるコードを確認できるだけの文脈と追跡可能性が必要です。
エージェントが実装のより多くを担うようになるほど、チームには出荷前の変更を独立した視点から確認する仕組みが必要です。レビュアーは、変更の影響がどこまで及ぶ可能性があるかを把握し、それぞれの指摘から確認可能なコードまでたどれる必要があります。
そうすればチームは、変更の全体像を一から組み立て直すことにレビュー時間を費やすのではなく、その根拠に基づいて最終判断を下せます。
