ボトルネックは消えない、移動する

2026/06/23、弊社オフィスにて【【AI駆動開発】AI自走環境整備・運用スペシャル #3 〜ハーネスエンジニアリングへの入り口〜】を開催しました。
弊社社員がLT（ライトニングトーク）を発表いたしましたので、こちらに掲載いたします。

Transcript

1. ボトルネックは消えない、移動する 18 AI駆動開発を "通す" 側から設計する
2. 燈株式会社／Akari Inc. 2021年2月 野呂　侑希 425名(2026年3月現在) 東京都千代田区神田駿河台4-6 御茶ノ水ソラシティ21階 AIを中心とする最先端技術の研究開発、パートナー企業とのDX・AI PJの 設計・実施、AI SaaSの開発・提供 企業名 設立 代表 従業員数 本社住所 事業内容 URL https://akariinc.co.jp/ 燈について
3. 日本を照らす 燈となる 現在、GAFAM5社の時価総額の合計は日本の全上場企業 の時価総額の合計を上回っていて、情報革命以降、日本企 業の競争力は欧米・中国などに遅れを取っています。 我々は日本の大きな燈となり、AI技術を中心とするテク ノロジーを用いて産業を照らし、全ての人々の希望の光と なることを目指しています。 We are “Akari” that illuminates Japan. 燈の使命
4. 自己紹介 DX Solution事業本部 ITコンサルタントグループ,SWE Manager 山本 智晴 | Tomoharu Yamamoto 新卒未経験でIT業界に飛び込み、エンジニアとしてのキャリアをスター ト。保守運用や追加開発を通じて、フロントエンドからバックエンド、イン フラまで幅広い技術基盤を構築。 その後、多数の新規開発案件にてPMやテックリードを担当。顧客折衝 をはじめ、クレジットカード決済などの重要システムの設計・開発をリー ドし、管理職としてチームを牽引。 2024年4月に燈株式会社へ参画し、システム開発やデリバリー業務を 担当。2026年からはSWチームおよびITコンサルティンググループのマ ネージャーに就任し、開発組織のマネジメントや組織の技術力向上に 従事。
5. Ⓒ Akari Inc. l Confidential 今日の主張は、ひとつの定理とその4つの帰結 エグゼクティブサマリ 衝突は「管理」でなく「 予防」する。 予防の量が、後段（統合・レビュー・検証）の 重さを決める。 ＝ 並列で書いたコードが衝突するのは「同じ場所を触る」から。触らない構造にすれば衝突は起きず 、統合もレビューも検証も軽くなる。 後段の重さは、手前の予防量で先に決まっている（＝従属変数）。 帰結① 予防は「場所の分離」 並列単位が物理的に同じ場所を触らない構造にする（モジュラモノリス＋生成契約）。完 全には消せず、残る「核＝複数機能が必ず共有する少数の場所」を特定する （dx-templateでは4箇所）。 帰結② 安全は「核の直列化」 マルチエージェントを壊さない条件は 2つ。上流を単一仕様に固定し、核だけを依存順に 直列化、残りは全並列。これが「第三の道」。 帰結③ ブランチ＝検証スコープの数 深さは衝突管理のためではない。「いくつの検証関心事を別ゲートで持つか」で決まる。 トランクベースも 3層も同じ原理の現れ。 帰結④ レビュー＝リスクで分ける 重さはブランチの段数でなく「核に触れたか」で決まる。機能内は軽く（本人＋ AI）、核に 触れたら重く（別の人が要件・結合を見る）。 通奏低音： ボトルネックは消えない、移動する。作る →通す→（予防で設計したら） →要件の解釈・上流の drift へ。残る課題は不備ではなく「ボトルネックが移動した足跡」。
6. 問題 ― 律速は「通す」側へ移った Ⓒ Akari Inc. l Confidential CHAPTER 01
7. Ⓒ Akari Inc. l Confidential 「速く作る」はもうコモディティ。詰まるのは "通す" 側だ。 問題定式化 コード生成が速くなった結果、ボトルネックは「作る」から「通す（レビュー・統合・検証）」へ移った。各社の公表データが、それを裏づけている。 作る コード生成 ― もう速い → 移動 → 通す レビュー・統合・検証 ― ここが詰まる 80%超 本番マージのうち AIが書いたコードの割合（ 2026 年5月）。人間のレビューが律速（アムダールの法 則）に。 出典：Anthropic Institute「When AI builds itself」(2026) PR急増 ×レビュー停滞 AI導入でPR作成数は大きく増える（エンジニア 1人 あたりのマージ量は 2024年比8倍）一方、レ ビューが追いつかず滞留する。 出典：Anthropic Institute「When AI builds itself」(2026) 1.7倍 AI生成PRに含まれる問題の相対量（ 470件のPR 分析）。"速いが失敗の質が違う "＝差分を眺める だけでは捕まらない。 出典：CodeRabbit「State of AI vs Human Code Generation」(2025) 23% AIエージェントの PRがマージ衝突を起こす割合 （Devinの実測。全体平均は 27.7%）。並列で動か すほど衝突は避けられない。 出典：AgenticFlict (arXiv, 2026) 本日の問い 「通す」側を どう設計すれば 、AI駆動開発はスケールするのか
8. 設計 ― 衝突を予防し、安全に並列化する Ⓒ Akari Inc. l Confidential CHAPTER 02
9. Ⓒ Akari Inc. l Confidential ブランチもレビューも、独立には選べない 中心定理 ― 従属変数論 運用して気づいたこと ― ブランチ戦略もレビュー段数も試したが、後段をいじるだけでは本質的に軽くならなかった。 発見の順序： 最初からこう設計したのではない。トランクベース／フィーチャーブランチ、レビュー段数 ― 後段をどう組み替えても、衝突と手戻りの総量は本質的に減らな かった。本当の変数は、その手前＝アーキテクチャが衝突をどれだけ「起こさないか」だった。 衝突は「管理」でなく「 予防」する。 予防の量が、後段（統合・レビュー・検証）の 重さを決める。 ✕ 管理する発想（従来） 衝突は起きる前提。ブランチとレビューという「網」で後から捌く。頑張って管理するほど 後段が重くなる。統合の瞬間にまとめて爆発する。 ◦ 予防する発想（本提案） 衝突が起きない地形にコードを作り変える。予防の量が増えれば、後段は構造的に軽く できる。管理の重さを、予防の規律に置き換える。 予防の量 アーキテクチャで先に決まる ⟶ 決定する ⟶ 後段の重さ 統合・レビュー・検証は従属変数 ＝ 衝突を「後で捌く（管理）」のをやめ、そもそも起きない構造にする（予防） どれだけ予防できたかで、統合・レビュー・検証にかかる手間が先に決まる 後段は自分で選ぶものでなく、予防量から自動的に決まる従属変数 。
10. Ⓒ Akari Inc. l Confidential 予防とは「同じ場所を触らせない」こと＝共有可変状態を構造から消す 第一帰結 ― 予防の中身 ✕ 同じ場所を共有して並列 • 複数エージェントが同じファイルを編集 • 統合の瞬間に衝突がまとめて爆発 • 後で「管理」するしかなくなる ◦ 場所を仕切って並列（モジュラモノリス） • 機能を縦割り（モジュラモノリス）にする • 新機能＝新フォルダ。担当が触る場所が分かれる • 機能間の参照を禁止し、結節点を断つ 予防を「強制」する4つの仕掛け（規約でなく、構造とテストで守らせる） 仕掛け 何を予防するか 機能間参照の禁止 機能Aが機能Bの内部を直接参照すること。 依存方向をCIで自動検査し、機械的に落とす （人が気をつけるに頼らない）。 自動生成された型付き契約 フロントとバックが同じファイルを編集すること。両者はスキーマから 自動生成された型付きクライアント 経由でしか出会わない。手書き通信・生 成物の手編集は禁止。 中央レジストリの廃止 共通の登録ファイルへの同時追記による衝突。暗黙の集約点をなくし、明示登録に変える。 境界・禁止事項の明文化 エージェント向けのルールファイルに、何を触ってよいか／いけないかを文書で固定し、逸脱を抑える。 並列で動く単位が物理的に同じファイルを触らなければ、衝突は起きようがない。これを「願い」でなく「構造」で強制する。 要点：2体のエージェントが物理的に同じ場所を触らないなら、衝突は「起きようがない」。レビューも統合もテストも、その時点で軽くなることが約束される。
11. Ⓒ Akari Inc. l Confidential 完全には消せない。だから "残る結節点" を特定する 第一帰結 ― 予防の限界 機能を縦割りにすると各機能は自分のフォルダ内で完結し衝突の大多数が消える。 だが複数機能が必然的に共有する結節点だけは残る。予防の本質は、その残る少数を特定すること。 features 内＝各機能で完結 機能A 担当が触るのはここだけ 機能B 担当が触るのはここだけ 機能間の参照は禁止 ＝ 機能内の衝突は起きない どう割っても残る結節点 ＝ 複数機能が同じ場所を共有 アプリ本体への登録 全機能の入口に集まる 共有ドメインモデル 複数機能が参照する中核 DBスキーマ テーブル定義＋マイグレーション 全体設定 環境変数・依存定義 ＝ 衝突しうるのは、この少数の結節点だけ 少数に絞れた（数自体より「特定できる」ことが重要） この結節点に触るタスクだけを、次章で直列化すればよい 転換点： 大多数の衝突は縦割りで消え、 残るのは複数機能が必然的に共有する少数の結節点だけ 。重要なのは数ではなく「 衝突しうる場所を特定できる 」こと ―― 特定できたから、 次章で並列の安全を最小コストで満たせる。 だが必ず 共有する
12. Ⓒ Akari Inc. l Confidential 並列エージェントを壊さない条件は、2つだけ 第二帰結 ― 並列の安全（なぜ壊れないか） 並列エージェントが壊れる主因は「共有文脈の食い違い」。各エージェントが勝手な前提（私的仮定）で動き、後で噛み合わなくなる。予防で核を絞れたから、対策は最小で済む。 「核」とは＝ どう分割しても複数の機能が必ず共有してしまう少数の場所（前章で特定した、消せない衝突点）。以下、この核を起点に考える。 ⚠ 罠①：マルチエージェントの脆さ ― ピアツーピアに会話させると文脈が分岐し、整合が取れず壊れる（作り手自身が警告）。　 → 打ち手： 司令役が文脈を所有・実装役は隔離し会話させない。≫ ほぼ解消 ① 私的な仮定を消す ＝ 上流を単一仕様に固定 判断を事前に 1つの仕様へ固める（共有された "不変"の真実をつくる）。要件 →仕様→設 計→エピック分割までを上流のスキル連鎖で一気通貫し、各エージェントが勝手な前提 で動かないようにする。 予防で核を少数に特定できたから、 並列の安全が「その少数だけ直列化」という最小コストで満たせる 第三の道： 「全部直列」は安全だが遅い。「全部並列」は速いが壊れる。 核だけ直列・残りは並列 が、安全と速度を両立する唯一の構造。これは核を特定できて初めて成立する。 ② 核だけを直列化 ＝ 残りは全並列 残る共有"可変"の核（前章で特定した少数の結節点）に触るタスクだけを依存順に直列 化。それ以外は同じ場所を触らないので、安全に全並列で流せる。直列化のコストは「核 の数」に比例する＝少数なら安い。
13. Ⓒ Akari Inc. l Confidential 上流を仕様に固定 → 司令役が依存順に実装役へ配り続ける 第二帰結 ― 実装（どう動かすか） 上流の判断をスキル連鎖で仕様に固定し、司令役（自走オーケストレーション）が核に触るものだけ直列・残りは並列で実装役へ配り続ける。人間はレビューとマージだけ。 人間 方向性の確認 ▼ 司令役 依存順に配る・ 見張る（自走） ▼ 実装役（並列） 実装・PR作成 ▼ 人間 レビュー＆マージ判断 ① 上流：各工程をスキルが順に実行し、前段の出力を引き継いで自動で成果物を生成 。 　 人手で書くのでなく、曖昧な依頼を「 1PR＝1タスク」の粒度まで自動で落としていく。 要件定義 → 仕様化 → 設計 → エピック分割 → タスク分割（1PR） ② 核に触るタスクだけ直列・独立タスクは並列で配布（同時数に上限） 依存順に直列▶ 核Aに触る 独立 依存順に直列▶ 核Bに触る 独立 配られたタスクを 並列で実装し PRを作成 。エージェント同士は 会話しない（隔離） ＝共有文脈の食い違いを構造的に防ぐ。 PRをレビューしマージ。 司令役はマージを実行しない ／実装役にマージ権限なし ―― 最終判断の一線だけは構造的に人間へ固定。 ⚠ 罠②：判断の自律性の漏れ ― 自動化を進めるほど、マージ等の重要判断がエージェントへ静かに移譲される。 → 打ち手： マージ権限を 構造的に人間へ固定 。状態の正本はバージョン管理側に置き冪等に保つ。 独立 独立 独立 独立
14. Ⓒ Akari Inc. l Confidential 浅い/深いは本質でない ― 深さは「検証スコープの数」で決まる 第三帰結 ― ブランチ 予防が衝突を消した結果、ブランチは「衝突の溜め場」でなく純粋な検証ゲートに専念できる。3つの段は、それぞれ別の検証関心事を担当する（入れ子構造）。 機能間の結合を検証 独立機能が初めて出会う場所。別メンバーが要件充足・結合動作・リリース可否を判断。 残る核の噛み合わせは、ここで表面化して捕まる 。E2Eを自動実行し、 PR本文にスクショを証跡として残す。 機能単体を検証 スライスが集まり、その機能が まとまって正しく動く かを確認。機能の境界内で閉じたテスト。 差分の妥当性を検証 1スライス＝1PRの小さな単位。作業した 本人が実装の細部とテスト妥当性を確認。認知負荷を最小化する粒度。 ブランチ戦略の選び方： 深さは「いくつの検証スコープを別ゲートで持ちたいか」で決まる。検証が 1段に集約できるならトランクベースが合理的だし、機能単体と結合を別々に見たいなら 層を分ける ―― どちらも同じ原理の異なる現れ 。プロジェクトの検証関心事の数に応じて選べばよい。 develop 統合線（一番外側） └ epic/{機能名} 機能集約層（developの中） └ feat/{機能名}/{スライス} スライス層（epicの中・並列で複数・ 1PR）
15. Ⓒ Akari Inc. l Confidential レビューは「段」でなく「核に触れたか」のリスクで分かれる 第四帰結 ― レビュー レビューが実際に発生するのはPR（段と段の境界） 。第三帰結と同じ並び（develop→epic→feat）に対し、レビューは2つの境界に対応する。 ▲ PR ▲ PR • 重く ― epic → develop のPR（別メンバー ＋ 全文脈型AIレビュー） 独立機能が初めて出会い、共有する核・機能間の結合に触れる。別メンバーが要件充足・結合・影響範囲を見る。リポジトリ全体をインデックスす る全文脈型AIで結合の破綻を捕まえる（例： Greptile／Claude Code Review ― 全コード文脈を読む）。 ◦ 軽く ― feat → epic のPR（本人 ＋ 差分型AIレビュー） 予防済みの機能内に閉じ、他機能と衝突しない。本人が細部を確認すれば十分。変更差分に集中する差分型 AIを全PRに必須化（例： CodeRabbit ― 低ノイズで高速）。 実践 ― レビューを支える仕組み（手法） ・全PRに差分型AIレビューを必須化（人間レビューの前段で機械的に通す） ・核に触れるPRを自動でリスクラベル付けし、全文脈型 AIと別メンバーのレビューを強制 ・PR本文にE2Eのスクショを自動添付し仕様充足を可視化 ・コミット時の自動シークレット検査で機密混入を入口で遮断 ・CIで依存方向を検査し機能間参照の逸脱を機械的に落とす 使い分けの軸： 差分型（CodeRabbit 等）は変更差分だけを見るので軽く低ノイズ＝機能内に必須化。全文脈型（ Greptile／Claude Code Review 等）はリポジトリ全体を読むので 差分の外 に 依存するバグを捕まえられる＝核・結合に触れる時に投入。重要なのは製品名でなく、 「差分の中で足りるか／全文脈が要るか」をリスク で切り替えること。 develop 統合線（一番外側） └ epic/{機能名} 機能集約層（developの中） └ feat/{機能名}/{スライス} スライス層（epicの中・並列で複数・ 1PR）
16. 人間に残るもの Ⓒ Akari Inc. l Confidential CHAPTER 03
17. Ⓒ Akari Inc. l Confidential AIに渡せない最後の一点は「要件の解釈」 現在の到達点 自動化できるのは「仕様どおり動くか」まで。できないのは「その仕様が、要件として正しいか」。ここが理論の到達点。 ◦ 自動化できる ― 仕様充足の検証 • E2Eが緑＝「仕様どおりに動く」ことの担保 • テスト・CI・自動レビューで機械的に守れる • スケールする（人手に依存しない） ✕ 自動化できない ― 要件の解釈 • その仕様が、要件として正しいかの判断 • 取り違えると "整合した上で "間違いが通る • E2Eが緑でも、綺麗に間違ったものが完成する 核心： エージェントが要件を取り違えると、テストごと整合して緑のまま通る。これを止められるのは、要件を持つ人間が、要件と照らして見ること だけ。これは人数の問題 ではない ― レビュアーが10人いても、全員が「仕様どおりか」しか見ないなら、要件の取り違えは素通りする。 ゆえに、人間の介在は 2点に収束する 判断は人間が握り、エージェントには境界の明確な実装だけを任せる ― この境界は理論から導かれる。
18. Ⓒ Akari Inc. l Confidential これで完成ではない ― 予防がまだ届いていない4つ 現在の到達点 これらは設計の不備ではなく、「中心定理（予防）の網がまだかかっていない場所」。隠さず開示する。 課題① 上流の未予防 上流ドキュメントの drift 契約層はスキーマからの自動生成で drift を封じた（罠は部分解消）。だが手前の要件定義書・設計書は、 実装が進むほど実態と乖離していく。上流の予防は未解決。 課題② 人間に残った宿題 「正しく間違える」 要件の取り違えは検証をすり抜ける（前章）。 E2Eで仕様充足は守れるが、要件解釈の正しさは守れない。 AI に渡せない最後の一点が、そのまま課題として残る。 課題③ 構造の限界 自己レビューの弱さ 機能内の変更を本人が見る構造は、見落としを完全には防げない。全 PRへのAIレビュー必須化で補ってい るが、本人レビュー自体の弱さは残る。 課題④ 自前機械の寿命 自走オーケストレーションの寿命 状態の正本をバージョン管理に置き 冪等に保つことで載せ替え可能性は確保。だが自走ループ自体は作り 込んだ自前機械で、標準ツール側が同領域を吸収しつつある。持ち続けるか載せ替えるかは未決。 次に効く一手 ― オブザーバビリティ： これら4つは「ボトルネックが移動した先」。次に効くのは移動先を 観測すること 。どこが新しい律速かを測ってから、次の予防を設計する。 具体例（ OpenTelemetry 等で計装） ：エージェント単位のトークン消費・実行時間・成功率／リトライ回数の急増（＝タスク粒度や仕様が曖昧なサイン）／核に触れた PRの滞留時間（＝直列化 ボトルネックの実測）／コスト異常の検知。「どのスキル・どの工程が重いか」を数値で当てて、次に予防すべき場所を特定する。
19. Ⓒ Akari Inc. l Confidential 問うべきは「どのツールか」でなく「ボトルネックは今どこにあるか」 まとめ ― 結論と、持ち帰ってほしい問い 律速はこう移動してきた 作る コード生成 → 通す レビュー・統合・検証 → 予防で設計したら → 要件の解釈・上流の drift 次の律速 ボトルネックは消えない、 移動する。 問うべきは「どのツールを使うか」ではなく、 「いま自分のボトルネックはどこにあり、それは予防で消せる場所か、消せない核として直列化すべき場所 か」。残る課題は不備ではなく、予防が効いて律速が次へ移った「足跡」。 速く作るのはコモディティ。 差がつくのは、移動を読み、 予防で先回りする設計力 。
20. 懇親会