2026 年 5 月、InfoQ が Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project を公開し、同時期に OpenAI が Simplex rethinks software development with Codex で 「Codex を全工程に組み込んだソフトウェア開発」 の事例を発表しました。
両者に共通するのは、「AI 補助」ではなく「エージェント主導」 で開発プロセスそのものを作り変えている点です。これは Claude Code・Codex CLI・Copilot CLI を QCD で比較する で扱った “ツール選定” の次の段階で、ツールではなく工程設計を変える話です。
弊社では受託案件で 「AI を入れて何倍速くなった？」 という顧客の問いに答えるため、デリバリー体制そのものを再設計しています。本記事では契約・体制・QA の 3 軸で実装ガイドを整理します。
なぜ「AI 補助」では速くならないのか
「AI を入れたが、思ったより速くならない」という相談は受託案件で典型的です。InfoQ プレゼンが指摘する原因は次の 3 つです。
| 失敗パターン | 受託案件での現れ方 |
|---|---|
| 個人技にとどまる | 「使える人だけ速い」状態でチーム生産性が変わらない |
| レビューがボトルネック | PR は速く出るが、レビュアーで詰まる |
| QA が追いつかない | 機能は出るが、テストが手作業のまま |
これらは DORA・SPACE・Core 4 で測る受託 AI の ROI で扱った “計測の話” の前段にある 「工程の話」で、計測の前に 「速くなる工程」を組まないと数字も出ません。
Simplex 流 — 「エージェント主導工程」5 つの再設計
再設計 1: 仕様書を「エージェントが読む形式」に変える
人間向けに書かれた仕様書はエージェントに読みにくく、「曖昧表現で誤実装が増える」 現象が起きます。Gherkin / BDD 形式の受け入れ条件に変換することで、エージェントの一発正答率が大幅に向上します。
再設計 2: PR を「機能単位」から「変更単位」に細分化
人間がレビューしやすい 「1 PR = 1 機能」 は AI 主導では大きすぎます。「1 PR = 1 変更（数十行）」 に細分化することで、レビュー時間が短縮され、回し方が変わります。
再設計 3: テストファースト前提を契約に書く
エージェントは 「テストが先にあれば自分で検証できる」 が、人間が後からテストを書く運用だと AI の速度に追いつきません。「実装前にテストコードを納品物として書く」を契約条項に入れます。
再設計 4: 「レビュアー」を「ペアプロ的監督者」に再定義
PR レビューを 「事後の品質ゲート」 から 「実装中の対話パートナー」 に変えます。レビュアーは 「エージェントが何を作っているか」 をリアルタイムに把握し、方向転換指示を出します。
再設計 5: 完了定義を「動く」から「証拠付き」に変える
「動きました」では不十分で、「テストが緑」「ベンチが基準値内」「セキュリティスキャンが OK」の 3 点セットを完了の証拠とします。これは GitHub Codeql 宣言型セキュリティ受託 で扱った “宣言型 QA” と同じ思想です。
受託契約に書く「AI Speed 条項」
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 完了定義 | テスト緑 + ベンチ基準内 + 静的解析 OK の 3 点セット | 検収基準の明確さ |
| PR 単位 | 1 PR = 1 変更、500 行以下 | レビュー負荷 |
| テストファースト | 実装前のテストコード納品 | 品質担保 |
| AI 出力責任 | エージェント生成コードの最終責任は受託側 | リスク分担 |
| 再現可能性 | ビルド・テストがコンテナで再現できる | 引き継ぎ性 |
| 観測可能性 | ログ・メトリクスがダッシュボードで見える | 運用引き継ぎ |
特に 「AI 出力責任」は、「AI が書いたから知らない」が通用しないことを明文化する重要な条項です。
体制設計 — 「3 倍速」を支える 4 ロール
[案件オーナー] : 顧客との合意形成・スコープ管理
│
├──→ [テックリード（人間）] : アーキ設計・難所対応・最終判断
│
├──→ [監督者（人間）] : エージェントの方向修正・レビュー
│
└──→ [Agent Fleet] : 並列で実装（Codex / Claude Code）
├ Implementer Agent
├ Test Generator Agent
└ Documenter Agent従来 5 〜 8 人いた実装チームを 「人間 2 〜 3 人 + Agent Fleet」で運用することで、ヘッドカウントは減らさず アウトプット 3 倍 を狙えます。これは マルチリポ中央地図 AI 受託 で扱った “全社展開” の小さい単位です。
QA 設計 — 速度を品質で殺さない 4 層
| 層 | 検査対象 | 担当 |
|---|---|---|
| L1: 単体テスト | 関数単位の正しさ | Agent 生成 + 人間レビュー |
| L2: 統合テスト | API / DB の連携 | Test Generator Agent |
| L3: E2E テスト | ユーザー操作シナリオ | Playwright + Agent |
| L4: 受け入れテスト | 顧客承認 | 人間（必須） |
L4 だけは必ず人間にすることが、「AI が AI を承認する」自己循環を避けるための鉄則です。
価格モデル — AI Speed 受託パッケージ
| プラン | 単価 | 対象 | 体制 |
|---|---|---|---|
| Speed Lite | 500 万円〜 | MVP / 機能追加 | 人間 1 + Agent Fleet |
| Speed Standard | 1,500 万円〜 | 新規プロダクト | 人間 2 + Agent Fleet |
| Speed Enterprise | 5,000 万円〜 | 基幹刷新 | 人間 4 + 複数 Agent Fleet |
価格は人月単価ベースから「機能単位の成果報酬」に近づけることが、「AI で速くなった」を顧客の予算意思決定に反映する現実的な構造です。
ハマりやすい 4 つの落とし穴
落とし穴 1: PR レビューがボトルネックのまま
PR を細分化しても、レビュアーが従来通り 1 件 30 分かけると速度は出ません。レビュアーロールを「監督者」に変え、リアルタイムに方向修正する運用に変えます。
落とし穴 2: テスト生成 AI を盲信
テスト生成 Agent が 「実装と同じ間違いをするテスト」を書く失敗が頻発します。最低 1 ケースは人間が手書きすることを契約に書きます。
落とし穴 3: 顧客との同期が遅れる
エージェント主導で速く動くと、顧客側の意思決定が間に合わない状態になります。週 2 回のショートチェックポイントで同期を取ります。
落とし穴 4: 引き継ぎ性の劣化
Agent が書いたコードは 「人間にとって読みにくい」 ことがあり、保守フェーズで顧客側エンジニアが詰みます。「人間が読める」基準の lint / formatterを契約に書きます。
まとめ — 「AI 補助」から「エージェント主導」へ
Engineering at AI Speed と Simplex の事例が示すのは、「ツールを入れる」ではなく「工程を作り変える」ことです。受託の現場で 「AI を入れて 3 倍速くなった」 を顧客の言葉で語るためには、契約・体制・QA を同時に再設計する必要があります。
弊社では Speed Lite / Standard / Enterprise の 3 段階で AI Speed 受託パッケージを提供しています。「AI を入れたが速くなった気がしない」「新規プロダクトを 3 倍速で出したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
