AI エンジニアの立場からみた、AI コーディング時代の開発の品質向上の取り組みと妄想

by Soh Ohara

Slide 1

Slide 1 text

AI エンジニアの⽴場から⾒た、 AI コーディング時代の開発の品質向上の取り組みと妄想 Beyond the Backend 2025/07/25 Soh OHARA

Slide 2

Slide 2 text

⾃⼰紹介 2 株式会社 IVRy / AI エンジニア電話応答体験における AI を活⽤した改善前職：AWS スタートアップ向けの技術⽀援尾原颯 AI Engineer https://www.amazon.co.jp/dp/4296205234 https://www.amazon.co.jp/dp/4798186422 𝕏: @soh_ohara

Slide 3

Slide 3 text

会社紹介 3 会社名代表取締役事業内容住所資本⾦等設⽴年⽉株式会社IVRy（アイブリー）奥⻄亮賀（Ryoga Okunishi）クラウド型AI電話SaaS（アイブリー）の運営〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 46.1億円（準備⾦含む） 2019年3⽉

Slide 4

Slide 4 text

本⽇のトピック 4

Slide 5

Slide 5 text

5 ‧バックエンド開発において、特に AI の品質担保についての課題感が多い & 品質の担保が難しい ‧AI コーディングツールの恩恵を得やすいのもバックエンドだが、それによる副作⽤が⼤きいのもバックエンドどう向き合って開発を進めていくのかに⼀緒に考えましょうバックエンド開発の⽅にみていただきたい理由

Slide 6

Slide 6 text

6 お伝えすること ‧AI ツールを使った開発戦略の考え⽅ ‧IVRy での実践例お伝えしないこと ‧AI ツールを使った細かなテクニックなど本⽇のトピック

Slide 7

Slide 7 text

アジェンダ 1. 現状認識 - 今、何が起きているのか？ 2. Re-Found 思考 - 「今起業するとしたら？」 3. AI 時代の設計原則 - 12-factor-agents とマルチエージェント 4. x10、x100 の⽣産性を⽬指して - 認知負荷解消へ向けた 4 つのアプローチ 5. IVRy での実践事例 - 理論から実装へ 7

Slide 8

Slide 8 text

AI コーディングツール使ってますか？？ 8

Slide 9

Slide 9 text

1 年後の開発体験の想像はついていますか？ 9

Slide 10

Slide 10 text

現状認識 10

Slide 11

Slide 11 text

LLM のコーディング能⼒向上 11 2024 年 8 ⽉： 33.2% （GPT-4o） 2025 年 7 ⽉: 72%以上（Claude Opus4 / OpenAI Codex-1） SWE-bench veriﬁed スコア SWE-bench Verified が登場 | OpenAI Introducing Claude 4 \ Anthropic 1 年で 2 倍以上の進化を遂げている

Slide 12

Slide 12 text

12 SWE-bench とは？ ● 2294 もの実際の Issue-PR を使⽤ ● 12 の⼈気 Python リポジトリから収集 ● コード修正から単体テスト通過したかどうかまで評価実際の GitHub Issues を解決する能⼒を測定するベンチマーク SWE-bench Verified が登場 | OpenAI

Slide 13

Slide 13 text

（脱線）えっ、Python だけ。。？ 13 世の中に LLM において学習に使われているデータのうち⽇本語はごく⼀部代表的なデータセットにおける含有率⽇本語 5% 程度 vs 英語 45% 程度（Common Crawl）でも、⽇本語でも⼗分使えるプログラミング⾔語 Python 以外の⾔語においてもある程度ワークするであろう（というロジックは成り⽴つ） Statistics of Common Crawl Monthly Archives by commoncrawl

Slide 14

Slide 14 text

（⼩話）LLM x コーディングの相性は良い 14 話題になった DeepSeek-R1 においても、あらかじめ答えの検証がやりやすい数学のタスクの問題 + 答えを⾃動的に評価する仕組みを導⼊した → コーディングにおいても同様の枠組みは⽤意しやすい LLM 周りの更なる発展は期待できる（かもしれない）

Slide 15

Slide 15 text

さまざまな開発ツールの台頭 15 ● Cursor ● GitHub Copilot ● Cline ● Windsurf ● Claude Code etc.. エディタ統合型 ● Devin ● GitHub Copilot Coding Agent ● Claude Code Action ● Cursor Background Agents etc.. ⾃律型エージェント

Slide 16

Slide 16 text

開発におけるインターフェースの変化 16 IDE ベースでの開発チャットツール / web アプリ経由での指⽰出し

Slide 17

Slide 17 text

エンジニアの役割の変化 17 コードを書く⼈ Claude Code どこまでも / Claude Code Everywhere | speakerdeck を参考に作成「何を作るのか？」「なぜ作りたいのか？」を AI に伝える⼈

Slide 18

Slide 18 text

18 現状の課題 ● コンテキスト⻑の制限 ○ Claude / gpt シリーズ: 20 万トークン（⼩説 200 ページくらい） ○ Gemini シリーズ: 100 万トークン（⼩説 1000 ページくらい） ○ → ⻑時間動かしてると履歴がモデルの限界を超えてしまう ● 推論モデルにおける課題 ○ 思考ステップが多いと、コンテキスト⻑の限界を超えるため単純なタスクも解けなくなる LLM ⾃⾝の技術的制約 The Illusion of the Illusion of Thinking A Comment on Shojaee et al. (2025)

Slide 19

Slide 19 text

19 現状の課題テストを削除して「テストが全部通りました！」振る舞いの問題

Slide 20

Slide 20 text

LLM は⼈間を騙そうとする 20 ● LLM の学習における⼈間からの「いいね！」を最⼤化する段階がある（RLHF） ● とある研究結果によると、モデルは「問題を正しく解く」よりも「⼈間をうまく騙す」⽅が楽だと判断して振る舞う可能性がある例. ひたすら冗⻑な⽂章を出して「良さげ」に⾒せる⼈間を騙してサボるAIたち [2409.12822] Language Models Learn to Mislead Humans via RLHF

Slide 21

Slide 21 text

⼈間の認知能⼒の限界 21 3 分の 1 のエンジニアが AI が⽣成したコードをデプロイ前にレビューしていない AI is generating code at scale ‒ but human scale code review can’t keep up • DEVCLASS 「⼈間がコードレビューするのは持続可能ではなくなってきている」

Slide 22

Slide 22 text

Re-Found 思考 22

Slide 23

Slide 23 text

IVRy はいま、猛烈な危機感で「Re-Found」しています 23

Slide 24

Slide 24 text

プロダクト価値 SaaS Playbookの変容 24 市場評価 - T2D3の成⻑であればGood という前提が崩れてきた - より少⼈数/⾼速な成⻑が求められ始めている - 従業員⼀⼈当たり売上の物差しが今までの基準の2-3倍になるのではないか - LLMの進化とともにデータベースWrapperとしての価値は失われていく - 固定化したワークフロー対応だけでは価値が相対的に低くなっていく

Slide 25

Slide 25 text

conﬁdential キーワードは「Re-Found（再創業）」 25 今この時代に起業するとしたら、どういうプロダクト構成にする？どういうプロセスにする？を Re-Found(再創業) の気持ちで捉え直す

Slide 26

Slide 26 text

26 「Re-Found」に必要な 3つの考え⽅サンクコストを捨てる AI Oriented 思考 AIの進化を予測する 1 2 3

Slide 27

Slide 27 text

27 IVRy が直⾯している課題複雑なビジネスロジック‧コードベース

Slide 28

Slide 28 text

28 IVRy が直⾯している課題組織的な課題 ● AI ツールの利⽤が個⼈レベルにとどまる ● AI が出したスクリプトに対してのレビュー認知負荷増⼤ ● AI ツールへの熟練度の個⼈差

Slide 29

Slide 29 text

AI 時代の設計原則 29

Slide 30

Slide 30 text

30 12-Factor Agents 1. Natural Language to Tool Calls 2. Own your prompts 3. Own your context window 4. Tools are just structured outputs 5. Unify execution state and business state 6. Launch / Pause / Resume with simple APIs LLM ベースのソフトウェアを作る上で経験上⾒出された 12 の設計原則 7. Contact humans with tool calls 8. Own your control ﬂow 9. Compact Errors into Context Window 10. Small, Focused Agents 11. Trigger from anywhere, meet users where they are 12. Make your agent a stateless reducer

Slide 31

Slide 31 text

31 今⽇のキーファクター Factor 3: Own your context window 各エージェントに対してインプットするコンテキストをコントロールする Factor 8: Own your control ﬂow エージェント間の制御フローを明確に Factor 10: Small, Focused Agents ⼩さく、単⼀責任のエージェント Factor 12: Stateless reducer 状態を持たない、純粋な変換器として

Slide 32

Slide 32 text

32 単⼀のエージェントによる限界何でもかんでも１つのエージェントにやらせることの問題とある実験 ● ハノイの塔を LLM に解かせる： 8 段で出⼒トークンが 32 万 ● 上限トークンを超過：正答率が 0% に ● 複雑なタスクほど出⼒が膨⼤に The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity The Illusion of the Illusion of Thinking A Comment on Shojaee et al. (2025)

Slide 33

Slide 33 text

33 マルチエージェントによる解決分業による効率化 ● 設計エージェント‧テストエージェント‧実装エージェント etc 各エージェントは短いコンテキストで動作 ● ⼊⼒コンテキストの削減 ● 専⾨性の向上 ● プロンプトのシンプル化

Slide 34

Slide 34 text

34 （脱線）アダム‧スミス「国富論」分業によって労働⽣産性が上昇すると説く労働の⽣産性を⼤きく向上させ、また労働を効果的に導き活⽤するための技能や熟練、判断⼒の多くは分業（労働の分業化）によってもたらされているように思われる。アダム‧スミス「国富論」より

Slide 35

Slide 35 text

35 Claude.ai の実装例複数のサブエージェントを連動させることでリサーチタスクを完遂 How we built our multi-agent research system \ Anthropic

Slide 36

Slide 36 text

⽣産性を x10、x100 にするために 36

Slide 37

Slide 37 text

37 開発⽣産性を上げるためのボトルネック AI の出すアウトプットに対する⼈間の認知負荷ここのボトルネックをいかに排除するか？ポイント - QA をいかにやりやすくするか - AI による⾃律部分を増やしていく - AI に⾃律的にやらせるところの境界線をいかに定義するか

Slide 38

Slide 38 text

38 認知負荷解消への 4 つのアプローチ 1. Risk Score による⾃動判定 2. 最⼩単位での PR 分割 3. 実装計画の精緻化 4. マルチエージェント化（ワークフロー化）

Slide 39

Slide 39 text

39 アプローチ 1: Risk Score による⾃動判定（机上の空論を出ていないが。。。） AI が出した PR に対して、Risk Score を⾃動算出（コード変更⾏、依存関係、影響 SLO、セキュリティ警告などをもとに算出） Risk Score が低い = レビューなしで⾃動マージ⾼い = ⼈間によるレビュー必須 AI が⾏った変更内容が持つリスクを計算する新しい概念（提案）

Slide 40

Slide 40 text

40 アプローチ 2: 最⼩単位での PR 分割（机上の空論を出ていないが。。。） 1 PR = 最⼤ 30 分の作業量に制限 or 200 ⾏制限これにより、PR を⼈間が⾒た時のレビュー負荷を下げる 30 分ルール

Slide 41

Slide 41 text

アプローチ 3: 実装計画の精緻化 41 ● ビジネス要件の取り込み（MCP） ● 技術仕様の具体化 ● 曖昧さの事前解消 ● コードレビュー時の理解の助け Design Doc ⾃動⽣成 ● テストシナリオの網羅性担保 ● E2E テストの⾃動メンテナンス ● リスクベースのテスト戦略 QA 計画の⾃動策定

Slide 42

Slide 42 text

42 アプローチ 4: マルチエージェント化設計エージェントレビューエージェント実装エージェント QA エージェント QA エージェント

Slide 43

Slide 43 text

IVRy での実践事例 43

Slide 44

Slide 44 text

実践事例 1: AI 対話機能の⾃動 E2E テスト 44 ● ⾳声インターフェイス経由で、 AI 応答機能が期待通りの挙動を⽰すのか確認効果 ● E2E での品質保証（リグレッションテスト） ● ⼈間のテスト⼯数削減⾳声応答品質の⾃動テスト

Slide 45

Slide 45 text

実践事例 2: Design Doc ⾃動化フロー 45 Notion や Linear に存在しているストック情報を連携させた Design Doc 実装フローの実現 Linear （特定コメント） Claude Code Action o3 search Notion （ビジネス背景‧ 機能要件） MCP Notion （Design Doc）

Slide 46

Slide 46 text

実践事例 3: Linear の⾃動サマリー 46

Slide 47

Slide 47 text

実践例 4: AI ハッカソン 47 全エンジニアが参加して1Dayのハッカソンを実施。全社の⽣産性改善という⽬的と、そのプロセスの中でAIをプロダクトとして実装することを「当たり前にする」取り組みを⾏っています。

Slide 48

Slide 48 text

おわりに 48

Slide 49

Slide 49 text

おわりに「AI に仕事を奪われる」のではなく、「AI とともに 10 倍以上の価値をうむ」 49

Slide 50

Slide 50 text

50 We are Hiring!