設計レビューとAIハーネスで向き合う AIが生み出した新しいボトルネックの対処法 / Design Reviews and AI Harnesses Against New Bottlenecks Created by AI

Transcript

1. 設計レビューとAIハーネスで向き合う AIが生み出した新しい ボトルネックの対処法 AI DevEx Conference 2026 2026年7月22日 田中 清 / 柿木 太志
2. 本日お伝えしたいこと 人間と AI の責務を分け、仕組み（ハーネス）で支える 生成 AI で コードを書くコスト は劇的に下がった。だがチームの生産性は伸びない。ボトルネックは消えたのでは なく、形を変えて現れた その変化に対応するには、まず 人間と AI の責務を分ける。設計の合意・判断・責任の所在は人間が握り、コード 生成や検証の実行は AI に渡す 渡した範囲を 仕組み（ハーネス）で支える。仕組みが先にあれば、人間は判断そのものに集中でき、品質は保てる 2
3. 本日のアジェンダ 前半：ボトルネックの正体と、関与すべき場所の再設計 「実装スピード」は手に入った。なぜ Outcome は伸びないか ボトルネックは「書く速さ」から「資産を守る判断」へ。しかも移り続ける 人間が関与すべき場所を再設計する3方針（合意を前に倒す／責務を分ける／観点を分ける） 後半：セカンダリーチームでの実装 ＝ AI ハーネスの実体 3方針をハーネスでどう実装したか（設計レビュー前倒し／責務分担／観点構造化） ハーネスの全体像と運用（hooks・スキル・エージェント・自動レビュー） 成果と、それでも残る課題 3
4. 発表者 田中 清：前半担当 Nstock 株式会社 CTO 2024年8月入社 柿木 太志：後半担当 Nstock 株式会社 セカンダリー事業部 エンジニア 2024年8月入社 4
5. AIの導入は進んだ。でも、課題は消えていない 個々の「実装スピード」は手に入った。では、チームは前に進んだのか
6. Output は増えたが、Outcome は変わっていない 個人差の拡大：AI活用できる人・できない人で生産性格差が大きく広がった アウトプット増：それでもチーム全体の実装量は増えた。PR レビューも増えた 価値の不確かさ：作る価値があったのか不明なものも、増えた 作らない判断：作るコストが下がった分、何を作り・何を 作らない かの判断が問われるようにな った 6
7. 速くなったのは、実装の時間だけだった では、速くならなかったのはどこか
8. フローは速くなったが、ストックは静かに劣化する フロー（開発プロセス） 設計 実装 レビュー デプロイ ✓ 速くなった AI が担当する範囲 ストック（積み上がる資産） デプロイのたびに積み上がる ユーザーが使い、次の開発の⼟台になる プロダクト資産 ✗ 静かに劣化する フロー＝開発プロセス：設計から実装・デプロイまでの「作って届ける」流れ。AI が速くしたのはここだけ ストック＝積み上がる資産：コードベース・ドメインモデル・情報設計・運用設計。Outcome を決める 8
9. 日々の指標は健全なまま、劣化だけが進んでいく 日々の指標は健全：コード承認率は上がり、PR マージ速度・テスト網羅率・バグ数も悪化しない 静かな腐敗：それでも、ストックは静かに腐敗していく。AI が局所最適なコードを量産するほど、 加速する 信号は遅行指標：「機能追加あたりの改修コスト」の上昇に現れる頃には、劣化はかなり進んでいる 9
10. 見えないところで変化は起きていた しかし、別の場所に顕在化してくる
11. ボトルネックは「書く速さ」から「資産を守る判断」へ 従来 要件定義 仕様策定 実装 テスト ボトルネック＝エンジニアの⼿ 移動 AI 時代 要件定義 仕様策定 実装 テスト ボトルネック＝上流の合意と判断 「エンジニアを増やす」では解消しない問題が増えている 11
12. しかも、一度きりではなく移り続ける 今回の移動もその一例：AI が「書く速さ」を解消し、隠れていた「判断」が表に出た 解消すれば、次が現れる：ひとつ潰しても終わらない。次に重い場所が顕在化する 固定発想では追いつかない：移り続ける前提で、「人間が関与すべき場所」を設計し直す ※ 探索期は別。捨てる前提のプロトタイプは速く作って試す。積み上げる資産とは使い分ける 12
13. 人間が関与すべき場所を再設計する 1. 合意を前に倒す 2. AI と人間で、責務を分ける 3. 職種間で、ストックを守る観点を分ける
14. 方針① 合意を前に倒す タイミング：コードレビューでの合意では遅すぎる。先に「とりあえず動くもの」ができてしまう 揃えるもの：目的／作らないこと／担当の責務 作らないこと：特に効く。目的は語られるが「作らない」は暗黙のまま。書けば膨張が止まる 揃える場：企画段階。多職種が持ち寄って価値を判別する（誰が何を止めるかは方針③） ※ 重い設計書を先に作る話ではない。制約を先に敷くから、後が速い 14
15. 方針② AI と人間で、責務を分ける ⼈間が握る 不可逆な意思決定・ドメイン前提 企画 設計判断 AI実装・定型チェック が完結する 先に 引く 実装 ユーザーに届く 定型チェック （リリース） ユーザー 境界を先引き：「人間が握る範囲」と「AI がやる範囲」の境界を、先に引いておく ※「AI ですぐ直せる」が効くのは、ユーザーに届く前まで。リリース後の負債は、作り手側の理屈では片付かない 15
16. 方針③ 職種間で、ストックを守る観点を分ける もっともらしさ問題：AI のコードは一見正しく見える。一観点のレビューでは違和感を言語化でき ない 善意頼みの限界：個人の気づき頼みでは、AI で増える判断量に追いつかない 価値ベース分担：スキルベースではなく価値ベースで、職種ごとに「何を止めるか」を持つ PdM：目的・作らないこと・優先度 Designer：体験・認知負荷 Engineer：保守性・データ設計 QA：品質リスク・検証可能性 16
17. 方針の話はここまで では、これをどう回すのか 人間が関与すべき場所を再設計する （合意を前に倒す／AI と人間で責務を分ける／職種間でストック観点を分ける） 後半は、開発プロセスと AI ハーネスの 2 軸で、セカンダリーチームでの具体例をお話します 17
18. Nstock セカンダリーチームの事例 18
19. 事例として話すこと 01 前半の 3 つの方針の具体策 02 AI ハーネスの全体像 「誰でも実装できる」状態を実現した土台 方針を開発プロセスにどう落とし込んだか 19
20. 事例として話すこと 01 前半の 3 つの方針の具体策 02 AI ハーネスの全体像 「誰でも実装できる」状態を実現した土台 方針を開発プロセスにどう落とし込んだか 20
21. AI ハーネスの全体像
22. ハーネスの主な構成要素 Claude Code を中心に以下の要素でハーネスを構成している 構成要素 数 役割 Skills 71 コミット・PR・レビューなど手続きの定型実行 Hooks 8 破壊的操作や機密混入を止めるガードレール Subagents 15 セキュリティ・ドメインなど領域別の専門家にタスクを委譲 MCP 連携 7 Linear・Figma・Datadog など外部システムへの接続 Docs 188 ナレッジ・ルール 108 ＋ DBスキーマ自動生成 80 Memory - 状態を保存し、セッション開始時に自動注入 Feedback Loop - テスト・リンター・型・CI で自動評価し再試行 22
23. AI ハーネスのイメージ図 ⼈ 依頼 結果／質問 AIエージェント (Claude Code) 呼ぶ Skills (71) Subagents (15) MCP 連携 (7) 参照 ⾃動で発⽕ Docs (188) Memory Hooks (8) Feedback Loop 結果を返す ⾃動評価 テスト / リンター / 型 / CI Skills/Hooks/Subagents からも Feedback を呼ぶ 23
24. AIエージェントが自律的に動くことでエンジニア以外でも実装できる 進め方：文脈取得 → 計画・実装 → コミット・PR まで、専用 Skills が実行 専門知識：ドメイン・セキュリティなど15体のSubagentsが、計画とコードをレビュー 事故防止：危険コマンドや機密・PII の混入を、コミット前にHooksが自動で止める →エンジニアの知識・スキルの形式化 24
25. 実装イメージ PdM・デザイナー・エンジニア 意図を⼊⼒ 意図（要件・設計・受け⼊れ条件） AI ハーネス｜この中で AI エージェントが⾃⾛ Docs / Memory / MCP ⽂脈を供給 （Linear などからも取得） ガードレール AI 実装 事故を遮断 専⾨エージェント ＋ ⾃動テスト 評価 ⾃⼰修正ループ 成果物 エンジニア 最終承認・マージ 25
26. 例1: PdM がCSVエクスポート機能を実装 業務データをエクスポートする機能を FE/BE まで自分で実装 DB スキーマ・業務ドメインの構造を踏まえないと実装できない領域 性能対応（DB インデックス追加）や共通化リファクタまで含む 26
27. 例2: PdM が外部APIとの接続を含む機能を実装 郵便番号APIを使って住所を自動補完する機能を FE/BFF まで自分で実装 API 連携の注意が必要な部分（トークンキャッシュ・エラーハンドリング）まで自分で実装 27
28. 例3: デザイナーによるデザインシステムの実装 デザイナーが、管理画面のデザインシステムを自ら整備した デザイントークン → コンポーネント定義 → コード実装 を一人で段階的に進めた 整えた定義は、AI レビューの基準としても使われている 28
29. ハーネスで「誰でも実装できる」土台ができた 職種を問わず、意図を伝えれば AIエージェントがPR作成まで行う PdM・デザイナーは、プロダクションコードにコミットできるように エンジニアは、実装を任せた分、設計・レビューなどの判断に注力できるように では、この土台をチームの成果につなげるには？ 29
30. 事例として話すこと 01 前半の 3 つの方針の具体策 02 AI ハーネスの全体像 「誰でも実装できる」状態を実現した土台 方針を開発プロセスにどう落とし込んだか 30
31. 前半の 3 つの方針の具体策
32. 方針 ① 合意を前に倒す ② 人間と AI の責務を分ける ③ 職種間で、ストックを守る観点を分ける 32
33. 方針は「仕組み」だけでなく「開発プロセス」も設計する 仕組みを整えるだけでは成果につながりにくい (例) ビルドトラップ 各方針について「仕組み」と「開発プロセス」の両方を設計する 設計する内容 仕組み Skills / Hooks / Agents / Docs / Feedback Loop 開発プロセス 誰が何を判断するか・コミュニケーション設計・レビュー体制 33
34. ① 合意を前に倒す
35. 誰でも開発できるようになり、一見順調に進んでいたが、、、 コードレビューで手戻りが発生するように 35
36. 原因: 合意形成がないまま開発が進んでいた 各職種が自律的にタスクを進められる分、背景や文脈がよく分からないままコードレビューに直面 結果として、 レビュー時に機能の背景が分からず、仕様の議論に戻ってしまう 設計思想に合わないコードを最初から実装し直してもらう (最適ではない実装も増幅してしまう) 36
37. 対策: 合意の方法を設計する コンテキストを集約 実装計画レビュー 気軽に話せる場 Linear からリポジトリへ 実装の前に合意を取る 朝会で⽇々の合意を拾う 37
38. コンテキストをIssueに集約し、リポジトリに反映する 合意に至るには文脈や背景の理解が重要 情報が1か所に集まることで、人も AI も文脈を拾いやすい 要件定義〜設計(PRD, Design Doc)を、1つの Linear Issue に記載する 大きなIssueの場合にはSub-Issuesに分割 重要な知識は実装と同時にコード側の Docs へ反映し、最終的にはリポジトリに集約 あとからも追いやすいように 38
39. 事例: Slack の会話も、Linear の Issue に集約される Slack と Linear を連携し、スレッドから直接 Issue を起票できる 会話の文脈が、元スレッドへのリンク付きで Issue に残る 39
40. 実装の前に、「実装計画」をレビューする 実装計画 = 何を作るか、どう作るか、どの順で作るか 実装に入る前にエンジニアと認識合わせすることで、手戻りを減らせるように 実装計画は、AIエージェントとエンジニアの両方でレビュー AIレビューは、専門領域ごとの縦軸 × 全体設計を見る横軸 エンジニアは重要な部分の判断 レビュー全体のコストを下げられるように 40
41. 気軽に仕様や設計を相談できる場をつくる リモートワークなこともあり、徐々に同期コミュニケーションの割合が減っていた 短時間の朝会を復活させ、気軽に相談のきっかけとなる場を用意した 非同期では伝わりづらい文脈や背景を補完する 41
42. まとめ: ① 合意を前に倒す 01 コンテキストを Issue に集約し、リポジトリに反映する 02 実装の前に、実装計画をエンジニアと AI でレビューする 03 気軽に相談できる同期の場で、日々の小さな合意を拾う 42
43. ② 人間と AI の責務を分ける
44. AIが自分で評価・検証できる部分は、仕組みで自動化する 金融ドメインの各指針・基準を遵守するための人間のチェックは欠かせない 一方、AIが生成したものを人がレビューし続けるとスケールしない 人が判断する部分を事前に決める → 仕様策定 / 設計方針 / マージ前の最終確認 他の部分はAIが自動評価可能な状態にした 44
45. AIが自動評価する仕組み: 推論の過程に決定論的なチェックを埋め込む Hooks・Skills・CI が、それぞれのタイミングで自動で検査する（内容は一例） タイミング チェック内容の例 コマンド実行 deny リストで危険操作をブロック（ rm -rf ・本番 DB・ .env 読取） ファイル編集 不可視文字の混入 / 機密情報・PII のハードコード 特定の変更 Controller・DTO → 監査ログ漏れ / 金額計算 → 型安全性 コミット テスト・フォーマット・機密情報を再チェック CI 機密スキャン・lint・テストを再実行 45
46. 自動評価によって、AI が自律実行できる チケット 計画 計画承認 実装 PR 作成 ⼈間が判断 AI が実⾏ PR 監視 マージ ⾃⼰修正ループ：テスト・リンター・CI の結果を受けて、⾃分で直す ※ ⾦額計算・認証・DB スキーマなど影響が⼤きい変更は、途中でも⼈間が確認する 46
47. QAもAIに任せる テストの設計から実行まで：計画時に9つの観点の表を作り、全件通るまで生成と修正を繰り返す 動作確認も AI で実施：実 DB＋シードデータで起動し、実操作・スクリーンショットで自己検証 ※ 重要なロジックの人のレビューやQA エンジニアによるテストも引き続き実施 47
48. まとめ: ② 人間と AI の責務を分ける 01 人が判断する部分を事前に決め、他は AI が自動評価する 02 推論の過程に決定論的なチェックを埋め込む 03 自動評価を土台に、実装も QA も AI が自律実行する 48
49. ③ 職種間で、ストックを守る観点を分ける
50. AI が理解しやすいよう、Docs を観点で構造化している 観点 Docs 職種 目的・背景 ドメイン Docs PdM UI・UX デザインシステム Docs Designer 責務境界・データモデル 設計 Docs Engineer 品質リスク・検証可能性 テスト観点 Docs QA → 結果的に、職種ごとの観点の構造になっている 50
51. 構造化されているから、各職種が自分の領域をメンテできる 51
52. 構造化された Docs が、AI の並行作業の土台になる 1つの巨⼤なドキュメントの場合 巨⼤なドキュメント すべての知識が1か所に 観点で構造化した場合 ドメイン デザイン Docs Docs 設計 Docs テスト Docs Subagent Subagent Subagent Subagent Subagent Subagent Subagent コンテキストが混ざり、精度と効率が落ちる ⾃分の専⾨ Docs だけを読む → 並⾏で動ける 52
53. AI 自身も学びを抽出して、Docs・Skills・Agents に還元する 定期実⾏で反映 （Skill） PR ごとに抽出 PR レビュー （Skill） 学び Docs 学び・知識を反映 Skills チェックリストを改善 Agents レビュー観点を改善 次の開発・レビューの基準になる AI が参照する知識と実行する手順を、常に実装と一致した状態で保てる 53
54. DocsやSkillsを陳腐化させず、適切に保つ DocsをCIで定期点検：適切なコンテキストを保ち、トークンも抑えられる Skills作成時にもテストを実施：実行テストと整合性チェック。劣化したら検知 54
55. まとめ: ③ 職種間で、ストックを守る観点を分ける 01 Docs を観点で構造化し、各職種が自分の領域を保つ 02 構造化された Docs が、AI の並行作業の土台になる 03 AI 自身も学びを抽出し、Docs・Skills・Agents に還元する 55
56. 今後の課題 人間側 AI に任せられる範囲は拡大したが、人の判断はなくならない 人が判断する部分を、どれだけ加速させられるか 新たな取り組み例 議論を保存・整理して、人の判断材料を準備する Skill など 生産性だけでなく、価値創造の割合を増やしていくことも重要 AI側 自律起動(ループエンジニアリング) 56
57. まとめ 前半: ボトルネックが「書く速さ」から「判断」へ移った。しかも、移り続ける 後半: 合意を前に倒す / 責務を分ける / 観点を分けて保つ、の3つで開発プロセスを設計した 重要なポイント 01 AIエージェントに任せる仕組み(ハーネス)と開発プロセスの両方を整える 02 人間が対応する範囲を事前に決め、人間はそこに集中する 03 仕組みは作って終わりにせず、改善し続ける 57
58. ご清聴ありがとうございました