AI駆動開発を実現するためのアーキテクチャと取り組み

by Yuichiro Yamashita

Slide 1

Slide 1 text

AI駆動開発を実現するためのアーキテクチャと取り組み  baseballyama 

Slide 2

Slide 2 text

本日のメインメッセージ  人間がやるべきことを見極め  それ以外は完全自動化を目指せ 

Slide 3

Slide 3 text

横断で使うもの  実装支援  壁打ち・相談  最近のAIツール振り返り (感覚)  Gemini  ChatGPT  Codex  Claude Code  コードレビュー  Codex  Claude Code  その他  (自社では今は使っていないもの)  GitHub Copilot 

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

AIにほとんどの実装を任せられる  状況に近づいている感覚がある 

Slide 7

Slide 7 text

ということは... 

Slide 8

Slide 8 text

開発作業全てを  AIに任せられる状況になったのか❔ 

Slide 9

Slide 9 text

Slide 10

Slide 10 text

そもそもソフトウェア開発とはなんなのか  There are many things that make software development complex.   But the heart of this complexity is the essential intricacy of the problem domain itself.  If you’re trying to add automation to complicated human enteprise, then your software cannnot dodge this complexity — all it can do is control it.     ソフトウェア開発の複雑さの核心は、自動化しようとしている対象領域（ドメイン）そのものが持つ本質的な複雑さにあります。ソフトウェアは、その複雑さから逃れることはできず、それをうまく制御（コントロール）することしかできないのです。 

Slide 11

Slide 11 text

本日のメインメッセージ  人間がやるべきことを見極め  それ以外は完全自動化を目指せ 

Slide 12

Slide 12 text

今日はこれを深掘り  していきましょう 

Slide 13

Slide 13 text

baseballyama 自己紹介  ● baseballyama (山下裕一朗)  ● 株式会社フライル  ○ ソフトウェアエンジニア    ● Svelte コアチームメンバー  ○ 元々は Svelte コンパイラを担当  ○ 最近は主に eslint-plugin-svelte や svelte-eslint-parser を担当    本日スポンサーブースを出しています!   ぜひお話しましょう!   便利なポーチが貰えます。  

Slide 14

Slide 14 text

ソフトウェア開発における3つのフェーズ  ①ドメイン理解  ②要件定義・設計  ③実装  業務を理解する  IT化する方法を考える  IT化を実現する 

Slide 15

Slide 15 text

ソフトウェア開発における3つのフェーズ  ①ドメイン理解  ②要件定義・設計  ③実装  業務を理解する  IT化する方法を考える  IT化を実現する  本日は①と③にフォーカスします  

Slide 16

Slide 16 text

①ドメイン理解 

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

そもそもソフトウェア開発とはなんなのか  There are many things that make software development complex.   But the heart of this complexity is the essential intricacy of the problem domain itself.   If you’re trying to add automation to complicated human enteprise, then your software cannnot dodge this complexity — all it can do is control it.     ソフトウェア開発の複雑さの核心は、自動化しようとしている対象領域（ドメイン）そのものが持つ本質的な複雑さにあります。ソフトウェアは、その複雑さから逃れることはできず、それをうまく制御（コントロール）することしかできないのです。 

Slide 20

Slide 20 text

自動化しようとしている   対象領域（ドメイン）     とはなんなのでしょうか 

Slide 21

Slide 21 text

弊社の例だと... 

Slide 22

Slide 22 text

通話ログを  登録  ラベルを付与  (例: 製品区分)  通話内容を要約  顧客から受電  ラベルを頼りに  検索・集計  個別のデータを  深掘り  レポートを作成し  社内に共有  現状のドメインを理解する  データ発生  (コールセンター)  加工  (コールセンター)  連携  (API連携)  分析  (製品部門)  共有  (製品部門 → 全社)  ⚠ 非常に単純化しています  

Slide 23

Slide 23 text

⚠ 非常に単純化しています   通話ログを  登録  ラベルを付与  (例: 製品区分)  通話内容を要約  顧客から受電  ラベルを頼りに  検索・集計  個別のデータを  深掘り  レポートを作成し  社内に共有  現状のドメインを理解する  データ発生  (コールセンター)  加工  (コールセンター)  連携  (API連携)  分析  (製品部門)  共有  (製品部門 → 全社)    ● 入力負荷が高い  ● 入力品質が属人化している    💡課題    ● 新しい軸でラベルづけができない (工数的に)  ● 人間では深掘りに限界がある (工数的に)  ● 上記に起因して効果的なレポートが作成できない  💡課題 

Slide 24

Slide 24 text

これって  AIで自動化  できるんでしたっけ? 

Slide 25

Slide 25 text

Slide 26

Slide 26 text

ドメインの理解は  顧客との対話でのみ  理解できることですよね    (だってAIが知らないことですから) 

Slide 27

Slide 27 text

ドメイン理解にAIは使えない  そもそも、業務ドメインは、ユーザー (人間) の業務フローを観察することでのみ理解できます。AIと対話しても理解できません。  また、ユーザー (人間) の業務フローは、歴史的経緯を含む膨大なコンテキストの上に成り立っており、AIはこれを知りません。  よって、ドメイン理解にAIを使うことは無理と考えるのが自然である。  ⚠ 勿論ドメイン理解を促進するために ChatGPT / Gemini に質問しまくる、  などの活用は存分にしましょう。 

Slide 28

Slide 28 text

Slide 29

Slide 29 text

③実装 

Slide 30

Slide 30 text

弊社の実装フロー  方針検討  既存コードを前提とした   実装方針を検討する。   必要に応じてチームで検討する。   Gemini  ChatGPT  Claude Code   実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip  レビュー  AIによるレビュー   必要に応じて人間レビュー   Claude Code   Codex 

Slide 31

Slide 31 text

Slide 32

Slide 32 text

弊社の実装フロー  方針検討  既存コードを前提とした   実装方針を検討する。   必要に応じてチームで検討する。   Gemini  ChatGPT  Claude Code   ● 一般的な技術調査や壁打ちに使用  ● 既存のコードベースに対する調査に使用  ● 具体的な実装方針検討に使用 

Slide 33

Slide 33 text

DeepWiki  (回答はまだ続きますが省略...) 

Slide 34

Slide 34 text

DeepWiki  (回答はまだ続きますが省略...)  チャットを通じて   詳細にコードベースを理解できます。   オンボーディングでも活躍しています。   (実装の詳細を解説する資料は全て捨てました)  

Slide 35

Slide 35 text

Cursor Agent  (回答はまだ続きますが省略...) 

Slide 36

Slide 36 text

Cursor Agent  (回答はまだ続きますが省略...)  複数のモデルを使用して   並列に実装プランを作成できます。   各プランの良いところを選択しながら   最終的な実装プランを検討できます。  

Slide 37

Slide 37 text

弊社の実装フロー  方針検討  既存コードを鑑みた   実装方針を検討する。   必要に応じてチームで検討する。   Gemini  ChatGPT  Claude Code   実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip  レビュー  AIによるレビュー   必要に応じて人間レビュー   Claude Code   Codex 

Slide 38

Slide 38 text

弊社の実装フロー  実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip 

Slide 39

Slide 39 text

弊社の実装フロー  実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip  ● 実装を担当 

Slide 40

Slide 40 text

VIBE-KANBAN 

Slide 41

Slide 41 text

VIBE-KANBAN 

Slide 42

Slide 42 text

VIBE-KANBAN  実装方針をちゃんと記述すれば   多くのケースで適切に実装してくれます。   コードの自己レビューと動作確認をすれば   作業完了になるケースも多いです。  

Slide 43

Slide 43 text

AIコーディングの課題  実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip  ● 実装を担当 

Slide 44

Slide 44 text

AIコーディングの課題  実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip  ● 実装を担当    ● コードが無秩序になりメンテナンス不能になる   ● 人間が完全に把握しきれなくなり影響範囲を読みきれなくなる   💡AIコーディングの課題  

Slide 45

Slide 45 text

この発表は  ここからが  面白いところです 

Slide 46

Slide 46 text

これらの課題を乗り越えるために  弊社が実践していることを  共有します 

Slide 47

Slide 47 text

AIコーディングの課題を乗り越える  実装  実装方針をAIに説明し   AIに実装させる。   必要に応じて手で修正する。   Claude Code   Vitest  Knip  ● 実装を担当  ● コードの秩序を維持する  ● 意図しないリグレッションを防ぐ 

Slide 48

Slide 48 text

Slide 49

Slide 49 text

コードの秩序を維持する 

Slide 50

Slide 50 text

ここからは  TypeScript 前提で  進めます 

Slide 51

Slide 51 text

コードの秩序を維持する  フォーマット  型検査  静的検査  不要コード  検査  パッケージ  設定検査  Knip 

Slide 52

Slide 52 text

コードの秩序を維持する  フォーマット  型検査  静的検査  不要コード  検査  パッケージ  設定検査  Knip  Claude Code  

Slide 53

Slide 53 text

コードの秩序を維持する  フォーマット  型検査  静的検査  不要コード  検査  パッケージ  設定検査  Knip  Claude Code  

Slide 54

Slide 54 text

AGENTS.md の一部分 

Slide 55

Slide 55 text

AGENTS.md の一部分 

Slide 56

Slide 56 text

コードの秩序を維持する  フォーマット  型検査  静的検査  不要コード  検査  パッケージ  設定検査  Knip  Claude Code  

Slide 57

Slide 57 text

前提知識  ● ESLint   JavaScript 製の静的検査ツール。プラグインを使用することで、 JavaScript 以外のコードに対しても静的検査を実行できる。  (例: TypeScript, Vue, Svelte, YAML, JSON)  ● Oxlint   ESLint 互換を目指した Rust 製静的検査ツール。  ESLint と比較して 50倍から100倍高速。 

Slide 58

Slide 58 text

徹底的な静的検査がコードの秩序を維持する鍵 

Slide 59

Slide 59 text

徹底的な静的検査がコードの秩序を維持する鍵  ESLint, Oxlint ともに   カスタムルールを実装できます。   (Oxlint はテクニカルプレビュー)   弊社では自社特有のルールを   沢山実装しています。  

Slide 60

Slide 60 text

自社特有のルール例  ● require-hono-request-validation   Hono (Webフレームワーク) の req.param / query / json / formData 直接取得を全部禁止して req.valid(...) 経由に統一、ルーターハンドラの第1引数をASTでたどって自動判定する。  ● no-unsafe-redirect   Hono / SvelteKit (UIフレームワーク) 双方の redirect 呼び出しを型情報込みで解析し、ユーザー入力由来・外部URL・定数でない変数を報告。Open Redirect耐性をLintで網羅的に守る。   ● void-promise-without-catch   void someAsync() パターンを解析して、catch() もしくは try/catch 無しの素のPromise を検出。未捕捉例外をLintで潰して適切なエラーハンドリングを強制する。  

Slide 61

Slide 61 text

Slide 62

Slide 62 text

補足  ESLint ルールは、AST と呼ばれる抽象構文木を走査したり、スコープマネージャーと呼ばれるシンボルのレキシカルスコープを分析しながらプログラムを検査するプログラムです。  これらに馴染みのない開発者にとって、ESLint ルールを実装するのはハードルが高いと感じるでしょう。  しかし実際には問題ありません。LLMがルールを実装してくれます。一部、技術的に正確に実装しようとするとLLMではまだ難しいルールがあるのですが、社内に閉じたルールではあれば実運用場は許容できることが多いです。 

Slide 63

Slide 63 text

Slide 64

Slide 64 text

意図しないリグレッションを防ぐ 

Slide 65

Slide 65 text

意図しないリグレッションを防ぐ  ● とにかくテストを書いておけば既存の動作が壊れていないかを判断できる  ● 但し、過去の失敗を避けながら行う必要がある  ○ ロンドン学派によるモック地獄によるメンテナンス工数爆発   

Slide 66

Slide 66 text

全体を n多重で実行   テストアーキテクチャ    ● データベースの初期データを定義   初期化    ● APIを実行 (Hono の testClient を使用)  実行    ● APIレスポンスを検証   ● データベースを検証   検証    ● データベースをロールバック   後処理 

Slide 67

Slide 67 text

全体を n多重で実行   テストアーキテクチャ    ● データベースの初期データを定義   初期化    ● APIを実行 (Hono の testClient を使用)  実行    ● APIレスポンスを検証   ● データベースを検証   検証    ● データベースをロールバック   後処理  変更頻度の低い外部IFに対して   モックを使用しない   結合テストを記述することで   変更耐性を確保する   (S3などの外部サービス連携部分はモックする)  

Slide 68

Slide 68 text

全体を n多重で実行   テストアーキテクチャ    ● データベースの初期データを定義   初期化    ● APIを実行 (Hono の testClient を使用)  実行    ● APIレスポンスを検証   ● データベースを検証   検証    ● データベースをロールバック   後処理  ● 実装を担当    ● テストケース設計から実装までAIが実施   ● テストが通るまでAIが繰り返し修正   ● 細かなテストケースの重複や欠損は気にしない   💡テストはAIが記述  

Slide 69

Slide 69 text

その他  ● バグ報告に対しては、修正なしでは落ちるが修正するとパスするテストを地道に積み上げる (このテストもAIに書かせる)  ● 複雑なロジックなど、結合テストで網羅するのが大変な処理に対しては単体テストを実装する (このテストもAIに書かせる) 

Slide 70

Slide 70 text

最近  この施策が良い結果を  生みました🎉 

Slide 71

Slide 71 text

最近この施策が良い結果を生みました🎉 

Slide 72

Slide 72 text

最近この施策が良い結果を生みました🎉  システムのコアとなるデータの構造を完全に変更する修正を実施     QAプロセスでも想定を大幅に下回るバグ検出となった     実際に本番リリース後も顧客からのバグ報告は1件もなかった  

Slide 73

Slide 73 text

レビュー 

Slide 74

Slide 74 text

Slide 75

Slide 75 text

弊社では3つの  AIレビューツールを使用しています 

Slide 76

Slide 76 text

Codex 

Slide 77

Slide 77 text

Codex  Codex からのレビューは   ほぼ必ず的確です。  

Slide 78

Slide 78 text

Claude Code 

Slide 79

Slide 79 text

Claude Code  AGENTS.md に書いてある内容に従って   大まかなレビューをしてくれます。     静的検査だけでは検査できない内容も含め   プロジェクトの設計に従っているかを確認できて便利です。  

Slide 80

Slide 80 text

Claude Code Security Reviewer  検出される脆弱性の種類   ● インジェクション攻撃：SQL、コマンド、LDAP、XPath、NoSQL、XXE   ● 認証・認可：認証破綻、権限昇格、IDOR、ロジックバイパス、セッション問題   ● データ露出：ハードコードされた秘密情報、機微情報のログ、情報漏えい、PII 取り扱い違反   ● 暗号化の問題：弱いアルゴリズム、不適切な鍵管理、安全でない乱数生成   ● 入力バリデーション：未検証入力、不十分なサニタイズ、バッファオーバーフロー   ● ビジネスロジック欠陥：レースコンディション、TOCTOU   ● 設定の不備：安全でない初期設定、欠落したセキュリティヘッダー、過度に許可された CORS   ● サプライチェーン：脆弱な依存関係、タイポスクワッティングリスク   ● コード実行：デシリアライズによる RCE、pickle インジェクション、eval インジェクション   ● XSS（クロスサイトスクリプティング）：反射型、保存型、DOM ベース   引用元: https://github.com/anthropics/claude-code-security-review 

Slide 81

Slide 81 text

Claude Code Security Reviewer 

Slide 82

Slide 82 text

Claude Code Security Reviewer  脆弱性を埋め込む可能性を   少しでも減らせて便利です。  

Slide 83

Slide 83 text

まとめ 

Slide 84

Slide 84 text

本日のメインメッセージ  人間がやるべきことを見極め  それ以外は完全自動化を目指せ 

Slide 85

Slide 85 text

そもそもソフトウェア開発とはなんなのか  There are many things that make software development complex.   But the heart of this complexity is the essential intricacy of the problem domain itself.   If you’re trying to add automation to complicated human enteprise, then your software cannnot dodge this complexity — all it can do is control it.     ソフトウェア開発の複雑さの核心は、自動化しようとしている対象領域（ドメイン）そのものが持つ本質的な複雑さにあります。ソフトウェアは、その複雑さから逃れることはできず、それをうまく制御（コントロール）することしかできないのです。 

Slide 86

Slide 86 text

Slide 87

Slide 87 text

ソフトウェア開発における3つのフェーズ  ①ドメイン理解  ②要件定義・設計  ③実装  業務を理解する  IT化する方法を考える  IT化を実現する  ● ドメイン理解は人間のみができること     ● AIによる自動化はするべきではない  

Slide 88

Slide 88 text

ソフトウェア開発における3つのフェーズ  ①ドメイン理解  ②要件定義・設計  ③実装  業務を理解する  IT化する方法を考える  IT化を実現する  ● 実装は徹底的に自動化を目指す     ● 自動化による以下の懸念に対処する   ○ コードが無秩序になりメンテナンス不能になる   ■ 徹底的な静的検査   ○ 人間が完全に把握しきれなくなり影響範囲を読みきれなくなる   ■ モックを使用しない結合テストを基本とする     ● コードレビューでもAIを活用する  

Slide 89

Slide 89 text

スポンサーブースで   お会いできることを   楽しみにしております  