100% AI コード生成開発！AI Agent 時代の信頼性と開発効率のためのガードレール/sre-next-2025-link-and-motivation

by リンクアンドモチベーション

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 © Link and Motivation Group 株式会社リンクアンドモチベーションエンジニアリングマネージャー川津雄介 Yusuke Kawatsu ● SRE・プラットフォームエンジニア ● AI で生産性 x20 倍にする取り組みにも従事 ● 最近は ELDEN RING NIGHTREIGN をしてます https://github.com/megmogmog1965 https://qiita.com/megmogmog1965 https://x.com/KawatsuYusuke

Slide 4

Slide 4 text

4 © Link and Motivation Group 会社紹介創業年月日｜2000年4月7日上場市場｜東京証券取引所プライム市場従業員数｜約1,500名 (グループ全体) 売上｜374億 (グループ全体) ※2024年12月期事業内容｜国内初の組織改善クラウドサービス AI活用｜専門チームを立ち上げ、方針・ツール・ナレッジを一元化株式会社リンクアンドモチベーション

Slide 5

Slide 5 text

5 © Link and Motivation Group 会社紹介経営と現場をつなぐオールインワンのサービス国内最⼤級の12,870社、532万⼈（※）のデータベースをもとに組織状態を可視化・分析可能。エンゲージメントサーベイだけではなく、個⼈開発（360度診断）機能やWeb社内報（社内ポータル）機能もご利⽤可能。（※）2025年3⽉末時点

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 © Link and Motivation Group 弊社では、昨年より AI Agent を用いた開発へのシフトを開始「新規プロダクト開発を20倍速にする」取り組み・研究を行っています最近では、おおよそ方法が確立され、既存プロダクトの開発においても同手法を取り入れるようになりました x20 倍速新規プロダクト

Slide 8

Slide 8 text

8 © Link and Motivation Group コード生成比率の目標新規プロダクト既存開発今は平均 20% くらい目標: 100% 目標: 60%

Slide 9

Slide 9 text

9 © Link and Motivation Group 弊社での AI の使い分け本日お話する内容は、弊社では主に Claude Code で実践されております。作業２作業１作業３作業２作業１作業３ 1 Issue small issue small issue small issue 直列並列順序性ある一連の作業完全に独立した作業 Devin Claude Code (,Cursor)

Slide 10

Slide 10 text

10 © Link and Motivation Group 特定の AI ツールに依存する話はしません主に AI Agent の話にはなりますが、Claude Code、Devin など、特定のツールの使い方等を話しには来ていません。 Devin Claude Code Cursor

Slide 11

Slide 11 text

11 © Link and Motivation Group 本日のテーマ AI Agent 時代によって訪れた高速開発 (CD) に対して本番利用できる意図通りのコード品質 (Q) を生み出したい！

Slide 12

Slide 12 text

Slide 13

Slide 13 text

13 © Link and Motivation Group 爆速で実装をしてくれる！人間が一日かかる作業もわずか数分で... コーディング AI Agent の良い点 Quality 品質 Delivery 納期 Cost コスト

Slide 14

Slide 14 text

14 © Link and Motivation Group 特に Claude Code や Devin は、事前に作りたいものを詳細に伝えていれば、実装完了まで一気に自走してくれる。特に Claude Code や Devin XX 機能を作ってね！りょ！作業リストを作ろう... まずは YY API を作って... 次に ZZ 画面を... ビルド・テスト実行してみて... エラー出たから直して... １ターン (最後まで) できたよ！

Slide 15

Slide 15 text

一方、みんな困っていること...

Slide 16

Slide 16 text

16 © Link and Motivation Group なんか期待してたのと違うのが生成される！ ○ 思っていたコード (保守観点) と違う（e.g., SOLID原則） ○ 思っていた仕様 (機能面) と違うコーディング AI Agent の課題... Delivery 納期 Cost コスト Quality 品質

Slide 17

Slide 17 text

17 © Link and Motivation Group ● 細かいエラーが頻発して、都度修正を指示 ● 期待と異なる仕様で実装され、都度修正を指示 AI が自走できない（人間の介在が多い） XX 機能を作ってね！✨ できました。直しました。エラーになってる！ 😡 思ってた画面と違う！ 😡 最初からやり直し

Slide 18

Slide 18 text

18 © Link and Motivation Group ※ AI CPU 時間 XX 機能を作ってね！✨ エラーになってる！ 😡 思ってた画面と違う！ 😡 実装時間実装時間 ※指示待ち時間 ※指示待ち時間 ※指示待ち時間速い...？プロセス全体で見ると実は速くない...？

Slide 19

Slide 19 text

19 © Link and Motivation Group ※ AI 開発がうまくいかない時の時間割実装時間実装時間 ※動作確認 ※指示待ち時間 ※指示待ち時間実装時間 ※指示待ち時間実装時間 ※指示待ち時間実装時間実装時間 ※動作確認 AI より遅いが、認識齟齬が少ない「実装→確認→訂正指示」の回数の多さ（オーバーヘッド時間の増加）人間が開発 AI コーディング

Slide 20

Slide 20 text

AI が自走できないのは、何が原因なのか？

Slide 21

Slide 21 text

21 © Link and Motivation Group AI が自走できず、都度人間の介入を必要するのは、次の２点の原因があると考えています。 1. AI が自分でミスに気づけない 2. AI が機能開発の詳細を人間と期待値調整できていない原因は２つあると考えます

Slide 22

Slide 22 text

22 © Link and Motivation Group ランタイム例外 API 仕様齟齬データ齟齬構文エラー少なくとも、一般的なエラー（コーディングミス）は AI 自身で解決してほしい。 ① AI が自分でミスに気づけない

Slide 23

Slide 23 text

23 © Link and Motivation Group AI にとっての常識は、開発者の職場ではなく世間一般の常識にあります。 ② AI が機能開発の詳細を人間と期待値調整できていない丸投げログイン機能を作ってね！パスワード方式？ OAuth？新規にクラス作る？既存コードに追記？ DB スキーマはどうする？ Auth0 とか外部サービス使う？ ※決まっていないことは、世間一般の方法に準拠するしかない

Slide 24

Slide 24 text

24 © Link and Motivation Group 課題 ①、② の解説に入る前に、弊社の新規プロダクト開発における開発プロセスの全貌を説明します。次章、開発プロセスの全貌について

Slide 25

Slide 25 text

Slide 26

Slide 26 text

26 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + イテレーション

Slide 27

Slide 27 text

27 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + 要所要所で AI（GPTなど）は使いますが、やはり最終的には人間の「判断」が色濃く、AI よりも人間の活動比率が高い。イテレーション

Slide 28

Slide 28 text

28 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 0 → 1 の初期開発では、React (next.js) のモックアップを v0 や Claude code に生成させて、PdM レビュー。後の開発で AI が参照。要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + イテレーション

Slide 29

Slide 29 text

29 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。後述しますが、AI に作らせた詳細設計書よりもさらに細かい文書。 AI が作成し、人間がレビュー・承認します。要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + イテレーション

Slide 30

Slide 30 text

30 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + 前述の実装計画書がきちんと書けていれば、ほぼ放置（AI 自走）でOK。イテレーション

Slide 31

Slide 31 text

31 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + 残念ながらほぼ 100% 人間による手動。要件定義からテスト仕様書を作るくらいには AI を活用。イテレーション

Slide 32

Slide 32 text

32 © Link and Motivation Group ① AI が自分でミスに気づけない ② AI が機能開発の詳細を人間と期待値調整できていない次章、①、② の課題に取り組む

Slide 33

Slide 33 text

Slide 34

Slide 34 text

34 © Link and Motivation Group AI の爆速開発（低品質）により、レビュー頻度が激増 👿 AI が生成したコードがバグを含んでいる場合、人間による介入（動作確認・レビュー）が発生するので生産性は上がりません。 XX 機能を作ってね！✨ エラーになってる！ 😡 またエラーが出たよ！ 😡 実装時間実装時間 ※指示待ち時間 ※指示待ち時間 ※指示待ち時間動作確認＆レビュー動作確認＆レビュー

Slide 35

Slide 35 text

35 © Link and Motivation Group 理想的には、こうありたいですね 🌞 昔の開発現場でよく言われていた「妖精さん」ですね。 XX 機能を作ってね！✨ 寝てたら終わってた！実装時間 ※指示待ち時間 ※指示待ち時間動作確認＆レビュー１発完了！

Slide 36

Slide 36 text

36 © Link and Motivation Group そこで、AI がミスに気づくための「ガードレール」事前にガードレールを敷くことによって AI Agent に「コードの誤り」を自分で気づけるようにします。すると AI が人間の介入を必要とせずに最後まで自走できます。

Slide 37

Slide 37 text

37 © Link and Motivation Group アーキテクチャ（※弊社での一例）弊社で採用している、新規プロダクトを開発する際の初期アーキテクチャを紹介します。弊社では初期はこのアーキテクチャで実践していますが、恒久的なものではなく、プロダクトが成熟するのに従って都度最適なものに変更をする予定です。

Slide 38

Slide 38 text

38 © Link and Motivation Group アーキテクチャ（※弊社での一例） 0 → 1 の新規プロダクト開発における弊社の開発アーキテクチャです。コード実装量を低減する目的で Vercel + Supabase を採用してます。 Client Component Route Handler tRPC Server Component PostgreSQL (Row level security) Auth Queue + Functions

Slide 39

Slide 39 text

39 © Link and Motivation Group 型や静的解析によるコード不備の検知次の事項を npm run build に仕込むなどして、AI Agent が必ず実施せざるを得ないクオリティゲートとしましょう。 ● 型 (TypeScript) により、コード間の呼び出しの不整合はコンパイル時点で AI Agent 自身が認識できます。 ● ESLint 等、各種静的解析も導入して、全てパスしなければコードが完成ではないと AI Agent に伝えましょう ● もちろんユニットテストコードを記述し、カバレッジ 80〜90% を目指しましょう

Slide 40

Slide 40 text

40 © Link and Motivation Group FE / BE のモノレポ構成（Next.js）フロントエンド、バックエンドコード両方ともモノレポ構成で実装し、 AI が両者の構造を把握しやすくします。 Client Component Route Handler tRPC Server Component PostgreSQL (Row level security) Auth Queue + Functions

Slide 41

Slide 41 text

41 © Link and Motivation Group FE / BE のモノレポ構成（Next.js）フロントエンド、バックエンドコード両方ともモノレポ構成で実装し、 AI が両者の構造を把握しやすくします。ディレクトリ説明 / ┗ app React ページ・コンポーネント (*.tsx) 置き場。 ┗ api/trpc/[trpc] Next.js の Route Handler (API) ですが、API は全て tRPC で定義しているので、ここでは Client Component からの tRPC 受付のみ実装。 ┗ components React 共通コンポーネント (*.tsx) 置き場。 ┗ trpc/routers tRPC による、バックエンド API 定義 (*.ts)

Slide 42

Slide 42 text

42 © Link and Motivation Group FE / BE のモノレポ構成（Next.js） tRPC を用いて、フロントエンドとバックエンド（クライアントとサーバー）間のコードで型が共有されています。 Client Component Route Handler tRPC Server Component PostgreSQL (Row level security) Auth Queue + Functions tRPC Call tRPC Call

Slide 43

Slide 43 text

43 © Link and Motivation Group バックエンドの API は tRPC で定義 tRPC を用いて、フロントエンドとバックエンド（クライアントとサーバー）間のコードで型が共有されています。フロントからは関数・メソッドを直接呼び出すのとほぼ近い体験になり、AI Agent 自身がフロントコードの API 呼び出しのバグを認識できるようになります戻り値に型がある API 名 API 引数もきちんと型化

Slide 44

Slide 44 text

44 © Link and Motivation Group ① のまとめ ● 実装時のエラー（バグ）を AI 自身が気づける仕組みを作る ● 本スライドでは取り上げませんが、他にも次のような取り組みが一般的に有効 ○ 画面上のエラーを知る（Playwright MCP） ○ 画面仕様との乖離を知る（Figma MCP） ○ DB データ・Schema の齟齬を知る（Aurora, PostgREST MCP） ○ 実行時エラーを知る（Sentry 通知）

Slide 45

Slide 45 text

Slide 46

Slide 46 text

46 © Link and Motivation Group 期待通りのコードを生成してくれない？ここで言う「期待するコード」を具体化してみると、次のようになるかと思います。 1. 思っていた仕様とは違うものが生成された 2. 概ね期待する仕様の通りだが、細かい点での齟齬や漏れが頻発する 3. 仕様上は正しいが、保守性の観点で期待するコード（美しいコード）ではない

Slide 47

Slide 47 text

47 © Link and Motivation Group なぜ、このようなことが発生するのでしょうか？それは「人間と AI Agent との間で、細かい期待値調整ができていない」ために起こります。丸投げログイン機能を作ってね！パスワード方式？ OAuth？新規にクラス作る？既存コードに追記？ DB スキーマはどうする？ Auth0 とか外部サービス使う？ ※決まっていないことは、世間一般の方法に準拠するしかない

Slide 48

Slide 48 text

48 © Link and Motivation Group チャットによる逐次的な指示現在の AI によるコード開発は「チャット欄での指示」で行うケースが多いです。そのため、AI への指示は自然と全体感が欠如した逐次的なものになります。ログインページを作って下さい。あ、パスワードリセット画面も必要でしたね。よろしく言ってなかったですが、実は Email をログインID にしてほしい Users クラスってあるから、そこに実装してほしかった... 勝手に新規のテーブル作らないで... Stacks...

Slide 49

Slide 49 text

49 © Link and Motivation Group AI ルール設定 (*.mdc, CLAUDE.md, …) ルールで救えるのは共通項だけ Cursor の *.mdc などのルール設定は有効ですが、これらは前章のガードレールに近く、個別のシチュエーションでの期待値調整には向きません。ディレクトリ構造コーディング規約パスワードは英数記号 16文字パスワードリセットのボタンも置いて

Slide 50

Slide 50 text

ちなみに、従来の開発では...

Slide 51

Slide 51 text

51 © Link and Motivation Group 要件定義書や設計書（詳細設計）を書いている従来の開発では、要件定義書に書かれたとある要件について、「何をどのような手法・手順で実装するか」を事前に設計書に起こしてますね。この設計書は、より上位のエンジニアのレビュー（承認）を経ているケースが多く、この時点で正しいコードの期待値合意がなされていますレビュー作成開発者レビュア設計書

Slide 52

Slide 52 text

よし、AI に「実装計画書」（≒詳細設計）を書いてもらおう！

Slide 53

Slide 53 text

53 © Link and Motivation Group 実装計画書とは？これから実装する内容を、従来の設計書（詳細設計）よりも更に詳細なレベルで AI に記述させた、実装の手順書です。また、実装状況の進捗管理も兼ねており、チェックリスト形式です要件定義デザイン（モックアップ）実装計画（AIが作る詳細設計）実装（UT & 動作確認）テスト（リリース） + イテレーション

Slide 54

Slide 54 text

54 © Link and Motivation Group 実装計画書の冒頭には、実装全体のルール・方針を記載。実装計画書とは？

Slide 55

Slide 55 text

55 © Link and Motivation Group 実装計画書とは？実装完了した項目に ✅ ファイル・クラス粒度での詳細設計

Slide 56

Slide 56 text

56 © Link and Motivation Group 人間は「実装計画書」をレビューする人間（上位のエンジニアにあたる）がレビュー・承認をすることで、AI Agent （実装担当のエンジニア）と作りたいものの期待値の擦り合せがされます。レビュー作成 AI 人間実装計画書 Users クラスが既にあるので、そこに実装して！ Password クラスを新規作成し再発行ロジックを実装します

Slide 57

Slide 57 text

57 © Link and Motivation Group 「実装計画書」の INPUT 情報入力情報は、ほとんどのケースでは「要件定義書」のことを指します。画面を生成する場合はデザインも実装計画書の入力になります。生成要件定義書実装計画書要件番号 XXX の実装の仕方

Slide 58

Slide 58 text

58 © Link and Motivation Group もし、うまく「実装計画書」を作れなかったら...？それは INPUT 情報の誤り・過不足であると判断をしなければなりません生成要件定義書実装計画書足りない要件記述

Slide 59

Slide 59 text

59 © Link and Motivation Group INPUT 文書の方を正す！どうしてもやりがちなのが、プロンプトで追加の指示をして直接修正する方法ですが、セッションと共に消えてしまう情報なのでアンチパターンだと考えます。生成要件定義書実装計画書 V1 実装計画書 V2 プロンプトで直接修正足りない要件記述本来、最初から「要件定義書」にかかれているべき失われる...

Slide 60

Slide 60 text

60 © Link and Motivation Group INPUT 文書の方を正す！元となった INPUT 情報（要件定義書など）を修正して、「実装計画書」を再生成しましょう。生成 (失敗) 要件定義書 V1 実装計画書 V1 修正再生成要件定義書 V2 実装計画書 V2

Slide 61

Slide 61 text

61 © Link and Motivation Group チャット欄に直接入力するプロンプトは、少ないほど良い！チャット欄に直接入力するプロンプトは少なければ少ないほどよく、具体的な指示は要件定義書のような永続的な文書情報としてあるべきですドキュメント名と「作って！」しか言っていない

Slide 62

Slide 62 text

具体的に見ていきましょう

Slide 63

Slide 63 text

63 © Link and Motivation Group 「実装計画〜実装」フェーズのプロセス図実装計画書を生成する期待通り要件定義 + デザイン実装を開始全て✅？完了した項目に✅ 実装成功 END YES NO YES YES 実装計画書コード COMMIT 要件定義を修正 NO NO St 実装計画作成Prompt

Slide 64

Slide 64 text

実装計画書を作る

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

68 © Link and Motivation Group 3) 実装計画書 = docs/implementation_plan.md AI が実装計画書を生成します。 ● このファイルは git branch で構成管理されています ● feature branch 毎に内容を丸ごと書き換えています

Slide 69

Slide 69 text

69 © Link and Motivation Group 3) 実装計画書 = docs/implementation_plan.md AI が実装計画書を生成します。 ● このファイルは git branch で構成管理されています ● feature branch 毎に内容を丸ごと書き換えています main feature A の実装計画書 feature B の... feature C の... マージ（開発完了）すると不要になる

Slide 70

Slide 70 text

70 © Link and Motivation Group 4) 仕様の観点で誤りがあれば... 要件定義書を修正して再度「要件番号 XXX の要件を変更しました。実装計画書を修正して下さい」と AI に指示します。生成 (失敗) 要件定義書 V1 実装計画書 V1 修正再生成要件定義書 V2 実装計画書 V2

Slide 71

Slide 71 text

71 © Link and Motivation Group 5) 設計の観点で誤りがあれば... 訂正したい設計情報がプロジェクトに共通するルールである場合は、ルールファイル (*.mdc , CLAUDE.md など) を修正します。ルールの修正後、「ルール YYY を変更しました。実装計画書を修正して下さい」と指示して、実装計画書を再生成させます。 AI ルール設定 (*.mdc, CLAUDE.md, …) ディレクトリ構造コーディング規約新しい設計ルール

Slide 72

Slide 72 text

72 © Link and Motivation Group ※ルールに記載するほどではない設計修正の場合は... 実装計画書の修正内容を直接プロンプトで指示しましょう。軽微である場合は、人間が手で直してしまってもかまいません ※ただし、一貫性が損なわれる可能性は考慮しましょう。 AI は人間よりも結構ちゃんと全体を見てくれています

Slide 73

Slide 73 text

Slide 74

Slide 74 text

実装を開始！

Slide 75

Slide 75 text

75 © Link and Motivation Group 7) AI Agent に実装を開始させましょう「実装計画書の項目 ZZZ の実装を行って下さい」と対象の項目を指示します。小さな単位で「実装 → 動作確認」のイテレーションを回しましょう。一気にやりすぎない

Slide 76

Slide 76 text

Slide 77

Slide 77 text

77 © Link and Motivation Group ※レビュー（PR）の単位は悩ましいです実装計画書に対して１PR は速度、自走率の点で一見理想的ですが、従来の開発でも「リリースが出来る最小単位で開発する」ことがベストプラクティスではあります。テスト・品質面を考えると、従来のスモールリリースの観点は守るべきでしょう

Slide 78

Slide 78 text

78 © Link and Motivation Group 8) 実装が完了したら... PR を AI Agent に作らせましょうローカルに github cli がインストールされていれば AI Agent が PR を詳細な Description とともに作成してくれます。 Github MCP でも構いません。

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

82 © Link and Motivation Group 個人的には部下というよりも、新しい入力デバイスこれまでは「キーボード叩いて、プログラムを書いて」実装していたのが、「頭の中の指示」を直接実現してくれる入力デバイスになった、という感覚です。実際、周りのメンバーには音声入力で AI Agent に指示している人もいます。設計指示タイプ入力プログラミングプロダクト ※ひとつ飛ばし音声も可

Slide 83

Slide 83 text

Slide 84

Slide 84 text

84 © Link and Motivation Group より高いエンジニアリング力が必要！結局何をどう作るか決めているのは開発者です。単に実装が速くなった（タイプしなくなった）だけで、ものづくりの楽しさは変わらないでしょう。 AI に正しく設計・実装をさせるためにも、指示を出す私達エンジニアの技術力がより一層重要になってきます。

Slide 85

Slide 85 text

Slide 86

Slide 86 text

86 © Link and Motivation Group ブースでお待ちしています！お話しましょう！さいごにお知らせリンクアンドモチベーションでは「SRE」「テックリード」「EM」の仲間を大募集中です！公式のフォローでノベルティプレゼント！