〜 開発の「速度」を維持したまま、組織の「品質」を数式的に担保する 〜
1. はじめに：思想から実務へのブリッジ
生成AIの導入は、開発のアウトプット量を劇的に増大させた。しかし、その多くは「意図」が欠落した断片的なコードの集積になりやすい。本稿では、別稿の『責任設計の思想』で定義したEMの役割を前提とし、現場で品質を破綻させないための具体的な「構造運用」にのみフォーカスする。概念論を脱却し、実装の防衛線を構築することが目的である。
2. 負債化のメカニズム：AIが「局所最適」を量産する構造
AI駆動開発における負債は、従来の技術的負債とは性質が異なる。AIはファイル間の暗黙的な依存関係や、中長期的なアーキテクチャの整合性を考慮しない。結果として、「局所的には動作するが、全体としては修正不能なコード」が高速に蓄積される。この「コンテキストの断片化」こそが、AI時代における最大の負債源である。EMは、AIのアウトプットを「完成品」ではなく「高精度な下書き」と再定義しなければならない。
3. 検品プロトコル：EMが敷くべき3段階の防衛線
品質を個人の裁量に委ねるのではなく、以下の3層の構造によって強制的に担保する。
第1層：型とテストによる論理的拘束
実装前にインターフェース（型）とテストコードを先行定義させる。AIに対し、「このテストをパスするコードを書け」という制約を与えることで、挙動の正当性を機械的に保証する。
第2層：多角的な機械的レビュー
単一のモデルに依存せず、別系統のモデルをレビュアーとして配置する。記述の冗長性やセキュリティ脆弱性を、人間が介在する前の「前処理」として排除する。
第3層：EMによる「意図（Intent）」の監査
人間が行うべきはコードの精読ではなく、「なぜこの設計を選んだのか」という設計意図の確認である。実装の詳細はAIに任せ、構造の正しさにのみ責任を持つ。
4. 資産化の回路：ブラックボックス化を防ぐ運用設計
生成されたコードを使い捨てのツールにせず、組織の資産として蓄積するためには、ドキュメントの同時生成が不可欠である。コード生成とセットで、アーキテクチャの意思決定記録（ADR）をAIに記述させる運用を徹底する。また、週次に「人間によるリファクタリング枠」をあらかじめ工数に組み込み、AIが生成した構造の歪みを定期的に矯正するメンテナンス回路を設計する。
FAQ：実務上の懸念について
- Q：開発スピードと品質担保のトレードオフをどう解消すべきか。
- A：品質を「定数（固定）」、スピードを「変数（調整）」として扱う。品質のガードレールを外して得た速度は、将来の改修コストとして指数関数的に増大するため、初期設計の厳格さを優先すべきである。
- Q：メンバーがAIに依存し、レビュー能力が低下する懸念はないか。
- A：レビューを「コードを書く作業」以上の高度な知的生産活動と再定義する。AIの誤りを指摘するプロセスを訓練の場とし、メンバーの視座を「実装者」から「検品者・設計者」へと引き上げる。
むすび：品質関数の書き換え
マネジメントの評価関数を「開発量」から「品質維持コストの最小化」へと書き換えるべきである。加速する開発ラインを制御するのは、EMが敷く論理的な防衛線に他ならない。
