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

by Nstock

Embed

Start on current slide

Slide 1

Slide 1 text

設計レビューとAIハーネスで向き合う AIが生み出した新しいボトルネックの対処法 AI DevEx Conference 2026 2026年7月22日田中清 / 柿木太志

Slide 2

Slide 2 text

本日お伝えしたいこと人間と AI の責務を分け、仕組み（ハーネス）で支える生成 AI でコードを書くコストは劇的に下がった。だがチームの生産性は伸びない。ボトルネックは消えたのではなく、形を変えて現れたその変化に対応するには、まず人間と AI の責務を分ける。設計の合意・判断・責任の所在は人間が握り、コード生成や検証の実行は AI に渡す渡した範囲を仕組み（ハーネス）で支える。仕組みが先にあれば、人間は判断そのものに集中でき、品質は保てる 2

Slide 3

Slide 3 text

本日のアジェンダ前半：ボトルネックの正体と、関与すべき場所の再設計「実装スピード」は手に入った。なぜ Outcome は伸びないかボトルネックは「書く速さ」から「資産を守る判断」へ。しかも移り続ける人間が関与すべき場所を再設計する3方針（合意を前に倒す／責務を分ける／観点を分ける）後半：セカンダリーチームでの実装＝ AI ハーネスの実体 3方針をハーネスでどう実装したか（設計レビュー前倒し／責務分担／観点構造化）ハーネスの全体像と運用（hooks・スキル・エージェント・自動レビュー）成果と、それでも残る課題 3

Slide 4

Slide 4 text

発表者田中清：前半担当 Nstock 株式会社 CTO 2024年8月入社柿木太志：後半担当 Nstock 株式会社セカンダリー事業部エンジニア 2024年8月入社 4

Slide 5

Slide 5 text

AIの導入は進んだ。でも、課題は消えていない個々の「実装スピード」は手に入った。では、チームは前に進んだのか

Slide 6

Slide 6 text

Output は増えたが、Outcome は変わっていない個人差の拡大：AI活用できる人・できない人で生産性格差が大きく広がったアウトプット増：それでもチーム全体の実装量は増えた。PR レビューも増えた価値の不確かさ：作る価値があったのか不明なものも、増えた作らない判断：作るコストが下がった分、何を作り・何を作らないかの判断が問われるようになった 6

Slide 7

Slide 7 text

速くなったのは、実装の時間だけだったでは、速くならなかったのはどこか

Slide 8

Slide 8 text

フローは速くなったが、ストックは静かに劣化するフロー（開発プロセス）設計実装レビューデプロイ ✓ 速くなった AI が担当する範囲ストック（積み上がる資産）デプロイのたびに積み上がるユーザーが使い、次の開発の⼟台になるプロダクト資産 ✗ 静かに劣化するフロー＝開発プロセス：設計から実装・デプロイまでの「作って届ける」流れ。AI が速くしたのはここだけストック＝積み上がる資産：コードベース・ドメインモデル・情報設計・運用設計。Outcome を決める 8

Slide 9

Slide 9 text

日々の指標は健全なまま、劣化だけが進んでいく日々の指標は健全：コード承認率は上がり、PR マージ速度・テスト網羅率・バグ数も悪化しない静かな腐敗：それでも、ストックは静かに腐敗していく。AI が局所最適なコードを量産するほど、加速する信号は遅行指標：「機能追加あたりの改修コスト」の上昇に現れる頃には、劣化はかなり進んでいる 9

Slide 10

Slide 10 text

見えないところで変化は起きていたしかし、別の場所に顕在化してくる

Slide 11

Slide 11 text

ボトルネックは「書く速さ」から「資産を守る判断」へ従来要件定義仕様策定実装テストボトルネック＝エンジニアの⼿移動 AI 時代要件定義仕様策定実装テストボトルネック＝上流の合意と判断「エンジニアを増やす」では解消しない問題が増えている 11

Slide 12

Slide 12 text

しかも、一度きりではなく移り続ける今回の移動もその一例：AI が「書く速さ」を解消し、隠れていた「判断」が表に出た解消すれば、次が現れる：ひとつ潰しても終わらない。次に重い場所が顕在化する固定発想では追いつかない：移り続ける前提で、「人間が関与すべき場所」を設計し直す ※ 探索期は別。捨てる前提のプロトタイプは速く作って試す。積み上げる資産とは使い分ける 12

Slide 13

Slide 13 text

人間が関与すべき場所を再設計する 1. 合意を前に倒す 2. AI と人間で、責務を分ける 3. 職種間で、ストックを守る観点を分ける

Slide 14

Slide 14 text

方針① 合意を前に倒すタイミング：コードレビューでの合意では遅すぎる。先に「とりあえず動くもの」ができてしまう揃えるもの：目的／作らないこと／担当の責務作らないこと：特に効く。目的は語られるが「作らない」は暗黙のまま。書けば膨張が止まる揃える場：企画段階。多職種が持ち寄って価値を判別する（誰が何を止めるかは方針③） ※ 重い設計書を先に作る話ではない。制約を先に敷くから、後が速い 14

Slide 15

Slide 15 text

方針② AI と人間で、責務を分ける⼈間が握る不可逆な意思決定・ドメイン前提企画設計判断 AI実装・定型チェックが完結する先に引く実装ユーザーに届く定型チェック（リリース）ユーザー境界を先引き：「人間が握る範囲」と「AI がやる範囲」の境界を、先に引いておく ※「AI ですぐ直せる」が効くのは、ユーザーに届く前まで。リリース後の負債は、作り手側の理屈では片付かない 15

Slide 16

Slide 16 text

方針③ 職種間で、ストックを守る観点を分けるもっともらしさ問題：AI のコードは一見正しく見える。一観点のレビューでは違和感を言語化できない善意頼みの限界：個人の気づき頼みでは、AI で増える判断量に追いつかない価値ベース分担：スキルベースではなく価値ベースで、職種ごとに「何を止めるか」を持つ PdM：目的・作らないこと・優先度 Designer：体験・認知負荷 Engineer：保守性・データ設計 QA：品質リスク・検証可能性 16

Slide 17

Slide 17 text

方針の話はここまででは、これをどう回すのか人間が関与すべき場所を再設計する（合意を前に倒す／AI と人間で責務を分ける／職種間でストック観点を分ける）後半は、開発プロセスと AI ハーネスの 2 軸で、セカンダリーチームでの具体例をお話します 17

Slide 18

Slide 18 text

Nstock セカンダリーチームの事例 18

Slide 19

Slide 19 text

事例として話すこと 01 前半の 3 つの方針の具体策 02 AI ハーネスの全体像「誰でも実装できる」状態を実現した土台方針を開発プロセスにどう落とし込んだか 19

Slide 20

Slide 20 text

事例として話すこと 01 前半の 3 つの方針の具体策 02 AI ハーネスの全体像「誰でも実装できる」状態を実現した土台方針を開発プロセスにどう落とし込んだか 20

Slide 21

Slide 21 text

AI ハーネスの全体像

Slide 22

Slide 22 text

ハーネスの主な構成要素 Claude Code を中心に以下の要素でハーネスを構成している構成要素数役割 Skills 71 コミット・PR・レビューなど手続きの定型実行 Hooks 8 破壊的操作や機密混入を止めるガードレール Subagents 15 セキュリティ・ドメインなど領域別の専門家にタスクを委譲 MCP 連携 7 Linear・Figma・Datadog など外部システムへの接続 Docs 188 ナレッジ・ルール 108 ＋ DBスキーマ自動生成 80 Memory - 状態を保存し、セッション開始時に自動注入 Feedback Loop - テスト・リンター・型・CI で自動評価し再試行 22

Slide 23

Slide 23 text

AI ハーネスのイメージ図⼈依頼結果／質問 AIエージェント (Claude Code) 呼ぶ Skills (71) Subagents (15) MCP 連携 (7) 参照⾃動で発⽕ Docs (188) Memory Hooks (8) Feedback Loop 結果を返す⾃動評価テスト / リンター / 型 / CI Skills/Hooks/Subagents からも Feedback を呼ぶ 23

Slide 24

Slide 24 text

AIエージェントが自律的に動くことでエンジニア以外でも実装できる進め方：文脈取得 → 計画・実装 → コミット・PR まで、専用 Skills が実行専門知識：ドメイン・セキュリティなど15体のSubagentsが、計画とコードをレビュー事故防止：危険コマンドや機密・PII の混入を、コミット前にHooksが自動で止める →エンジニアの知識・スキルの形式化 24

Slide 25

Slide 25 text

実装イメージ PdM・デザイナー・エンジニア意図を⼊⼒意図（要件・設計・受け⼊れ条件） AI ハーネス｜この中で AI エージェントが⾃⾛ Docs / Memory / MCP ⽂脈を供給（Linear などからも取得）ガードレール AI 実装事故を遮断専⾨エージェント＋⾃動テスト評価⾃⼰修正ループ成果物エンジニア最終承認・マージ 25

Slide 26

Slide 26 text

例1: PdM がCSVエクスポート機能を実装業務データをエクスポートする機能を FE/BE まで自分で実装 DB スキーマ・業務ドメインの構造を踏まえないと実装できない領域性能対応（DB インデックス追加）や共通化リファクタまで含む 26

Slide 27

Slide 27 text

例2: PdM が外部APIとの接続を含む機能を実装郵便番号APIを使って住所を自動補完する機能を FE/BFF まで自分で実装 API 連携の注意が必要な部分（トークンキャッシュ・エラーハンドリング）まで自分で実装 27

Slide 28

Slide 28 text

例3: デザイナーによるデザインシステムの実装デザイナーが、管理画面のデザインシステムを自ら整備したデザイントークン → コンポーネント定義 → コード実装を一人で段階的に進めた整えた定義は、AI レビューの基準としても使われている 28

Slide 29

Slide 29 text

ハーネスで「誰でも実装できる」土台ができた職種を問わず、意図を伝えれば AIエージェントがPR作成まで行う PdM・デザイナーは、プロダクションコードにコミットできるようにエンジニアは、実装を任せた分、設計・レビューなどの判断に注力できるようにでは、この土台をチームの成果につなげるには？ 29

Slide 30

Slide 30 text

事例として話すこと 01 前半の 3 つの方針の具体策 02 AI ハーネスの全体像「誰でも実装できる」状態を実現した土台方針を開発プロセスにどう落とし込んだか 30

Slide 31

Slide 31 text

前半の 3 つの方針の具体策

Slide 32

Slide 32 text

方針 ① 合意を前に倒す ② 人間と AI の責務を分ける ③ 職種間で、ストックを守る観点を分ける 32

Slide 33

Slide 33 text

方針は「仕組み」だけでなく「開発プロセス」も設計する仕組みを整えるだけでは成果につながりにくい (例) ビルドトラップ各方針について「仕組み」と「開発プロセス」の両方を設計する設計する内容仕組み Skills / Hooks / Agents / Docs / Feedback Loop 開発プロセス誰が何を判断するか・コミュニケーション設計・レビュー体制 33

Slide 34

Slide 34 text

① 合意を前に倒す

Slide 35

Slide 35 text

誰でも開発できるようになり、一見順調に進んでいたが、、、コードレビューで手戻りが発生するように 35

Slide 36

Slide 36 text

原因: 合意形成がないまま開発が進んでいた各職種が自律的にタスクを進められる分、背景や文脈がよく分からないままコードレビューに直面結果として、レビュー時に機能の背景が分からず、仕様の議論に戻ってしまう設計思想に合わないコードを最初から実装し直してもらう (最適ではない実装も増幅してしまう) 36

Slide 37

Slide 37 text

対策: 合意の方法を設計するコンテキストを集約実装計画レビュー気軽に話せる場 Linear からリポジトリへ実装の前に合意を取る朝会で⽇々の合意を拾う 37

Slide 38

Slide 38 text

コンテキストをIssueに集約し、リポジトリに反映する合意に至るには文脈や背景の理解が重要情報が1か所に集まることで、人も AI も文脈を拾いやすい要件定義〜設計(PRD, Design Doc)を、1つの Linear Issue に記載する大きなIssueの場合にはSub-Issuesに分割重要な知識は実装と同時にコード側の Docs へ反映し、最終的にはリポジトリに集約あとからも追いやすいように 38

Slide 39

Slide 39 text

事例: Slack の会話も、Linear の Issue に集約される Slack と Linear を連携し、スレッドから直接 Issue を起票できる会話の文脈が、元スレッドへのリンク付きで Issue に残る 39

Slide 40

Slide 40 text

実装の前に、「実装計画」をレビューする実装計画 = 何を作るか、どう作るか、どの順で作るか実装に入る前にエンジニアと認識合わせすることで、手戻りを減らせるように実装計画は、AIエージェントとエンジニアの両方でレビュー AIレビューは、専門領域ごとの縦軸 × 全体設計を見る横軸エンジニアは重要な部分の判断レビュー全体のコストを下げられるように 40

Slide 41

Slide 41 text

気軽に仕様や設計を相談できる場をつくるリモートワークなこともあり、徐々に同期コミュニケーションの割合が減っていた短時間の朝会を復活させ、気軽に相談のきっかけとなる場を用意した非同期では伝わりづらい文脈や背景を補完する 41

Slide 42

Slide 42 text

まとめ: ① 合意を前に倒す 01 コンテキストを Issue に集約し、リポジトリに反映する 02 実装の前に、実装計画をエンジニアと AI でレビューする 03 気軽に相談できる同期の場で、日々の小さな合意を拾う 42

Slide 43

Slide 43 text

② 人間と AI の責務を分ける

Slide 44

Slide 44 text

AIが自分で評価・検証できる部分は、仕組みで自動化する金融ドメインの各指針・基準を遵守するための人間のチェックは欠かせない一方、AIが生成したものを人がレビューし続けるとスケールしない人が判断する部分を事前に決める → 仕様策定 / 設計方針 / マージ前の最終確認他の部分はAIが自動評価可能な状態にした 44

Slide 45

Slide 45 text

AIが自動評価する仕組み: 推論の過程に決定論的なチェックを埋め込む Hooks・Skills・CI が、それぞれのタイミングで自動で検査する（内容は一例）タイミングチェック内容の例コマンド実行 deny リストで危険操作をブロック（ rm -rf ・本番 DB・ .env 読取）ファイル編集不可視文字の混入 / 機密情報・PII のハードコード特定の変更 Controller・DTO → 監査ログ漏れ / 金額計算 → 型安全性コミットテスト・フォーマット・機密情報を再チェック CI 機密スキャン・lint・テストを再実行 45

Slide 46

Slide 46 text

自動評価によって、AI が自律実行できるチケット計画計画承認実装 PR 作成⼈間が判断 AI が実⾏ PR 監視マージ⾃⼰修正ループ：テスト・リンター・CI の結果を受けて、⾃分で直す ※ ⾦額計算・認証・DB スキーマなど影響が⼤きい変更は、途中でも⼈間が確認する 46

Slide 47

Slide 47 text

QAもAIに任せるテストの設計から実行まで：計画時に9つの観点の表を作り、全件通るまで生成と修正を繰り返す動作確認も AI で実施：実 DB＋シードデータで起動し、実操作・スクリーンショットで自己検証 ※ 重要なロジックの人のレビューやQA エンジニアによるテストも引き続き実施 47

Slide 48

Slide 48 text

まとめ: ② 人間と AI の責務を分ける 01 人が判断する部分を事前に決め、他は AI が自動評価する 02 推論の過程に決定論的なチェックを埋め込む 03 自動評価を土台に、実装も QA も AI が自律実行する 48

Slide 49

Slide 49 text

③ 職種間で、ストックを守る観点を分ける

Slide 50

Slide 50 text

AI が理解しやすいよう、Docs を観点で構造化している観点 Docs 職種目的・背景ドメイン Docs PdM UI・UX デザインシステム Docs Designer 責務境界・データモデル設計 Docs Engineer 品質リスク・検証可能性テスト観点 Docs QA → 結果的に、職種ごとの観点の構造になっている 50

Slide 51

Slide 51 text

構造化されているから、各職種が自分の領域をメンテできる 51

Slide 52

Slide 52 text

構造化された Docs が、AI の並行作業の土台になる 1つの巨⼤なドキュメントの場合巨⼤なドキュメントすべての知識が1か所に観点で構造化した場合ドメインデザイン Docs Docs 設計 Docs テスト Docs Subagent Subagent Subagent Subagent Subagent Subagent Subagent コンテキストが混ざり、精度と効率が落ちる⾃分の専⾨ Docs だけを読む → 並⾏で動ける 52

Slide 53

Slide 53 text

AI 自身も学びを抽出して、Docs・Skills・Agents に還元する定期実⾏で反映（Skill） PR ごとに抽出 PR レビュー（Skill）学び Docs 学び・知識を反映 Skills チェックリストを改善 Agents レビュー観点を改善次の開発・レビューの基準になる AI が参照する知識と実行する手順を、常に実装と一致した状態で保てる 53

Slide 54

Slide 54 text

DocsやSkillsを陳腐化させず、適切に保つ DocsをCIで定期点検：適切なコンテキストを保ち、トークンも抑えられる Skills作成時にもテストを実施：実行テストと整合性チェック。劣化したら検知 54

Slide 55

Slide 55 text

まとめ: ③ 職種間で、ストックを守る観点を分ける 01 Docs を観点で構造化し、各職種が自分の領域を保つ 02 構造化された Docs が、AI の並行作業の土台になる 03 AI 自身も学びを抽出し、Docs・Skills・Agents に還元する 55

Slide 56

Slide 56 text

今後の課題人間側 AI に任せられる範囲は拡大したが、人の判断はなくならない人が判断する部分を、どれだけ加速させられるか新たな取り組み例議論を保存・整理して、人の判断材料を準備する Skill など生産性だけでなく、価値創造の割合を増やしていくことも重要 AI側自律起動(ループエンジニアリング) 56

Slide 57

Slide 57 text

まとめ前半: ボトルネックが「書く速さ」から「判断」へ移った。しかも、移り続ける後半: 合意を前に倒す / 責務を分ける / 観点を分けて保つ、の3つで開発プロセスを設計した重要なポイント 01 AIエージェントに任せる仕組み(ハーネス)と開発プロセスの両方を整える 02 人間が対応する範囲を事前に決め、人間はそこに集中する 03 仕組みは作って終わりにせず、改善し続ける 57

Slide 58

Slide 58 text

ご清聴ありがとうございました