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

2025/07/25 に開催されたイベントでの登壇資料になります。
「Beyond The Backend 〜AI時代のバックエンド開発の再定義〜」
https://penetrator.connpass.com/event/361048/

IVRy 採用ページ: https://ivry-jp.notion.site/

Transcript

1. AI エンジニアの⽴場から⾒た、 AI コーディング時代の開発の品質向上の 取り組みと妄想 Beyond the Backend 2025/07/25 Soh OHARA
2. ⾃⼰紹介 2 株式会社 IVRy / AI エンジニア 電話応答体験における AI を活⽤した改善 前職：AWS  スタートアップ向けの技術⽀援 尾原 颯 AI Engineer https://www.amazon.co.jp/dp/4296205234 https://www.amazon.co.jp/dp/4798186422 𝕏: @soh_ohara
3. 会社紹介 3 会社名 代表取締役 事業内容 住所 資本⾦等 設⽴年⽉ 株式会社IVRy（アイブリー） 奥⻄ 亮賀（Ryoga Okunishi） クラウド型AI電話SaaS（アイブリー）の運営 〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 46.1億円（準備⾦含む） 2019年3⽉
4. 本⽇のトピック 4
5. 5 ‧バックエンド開発において、特に AI の品質担保についての 課題感が多い & 品質の担保が難しい ‧AI コーディングツールの恩恵を得やすいのもバックエンド だが、それによる副作⽤が⼤きいのもバックエンド どう向き合って開発を進めていくのかに⼀緒に考えましょう バックエンド開発の⽅にみていただきたい理由
6. 6 お伝えすること ‧AI ツールを使った開発戦略の考え⽅ ‧IVRy での実践例 お伝えしないこと ‧AI ツールを使った細かなテクニックなど 本⽇のトピック
7. アジェンダ 1. 現状認識 - 今、何が起きているのか？ 2. Re-Found 思考 - 「今起業するとしたら？」 3. AI 時代の設計原則 - 12-factor-agents とマルチエージェン ト 4. x10、x100 の⽣産性を⽬指して      - 認知負荷解消へ向けた 4 つのアプローチ 5. IVRy での実践事例 - 理論から実装へ 7
8. AI コーディングツール 使ってますか？？ 8
9. 1 年後の開発体験の 想像はついていますか？ 9
10. 現状認識 10
11. LLM のコーディング能⼒向上 11 2024 年 8 ⽉： 33.2% （GPT-4o） 2025 年 7 ⽉: 72%以上（Claude Opus4 / OpenAI Codex-1） SWE-bench verified スコア SWE-bench Verified が登場 | OpenAI Introducing Claude 4 \ Anthropic 1 年で 2 倍以上の進化を遂げている
12. 12 SWE-bench とは？ • 2294 もの実際の Issue-PR を使⽤ • 12 の⼈気 Python リポジトリから収集 • コード修正から単体テスト通過したかどうかまで評価 実際の GitHub Issues を解決する能⼒を測定するベンチマーク SWE-bench Verified が登場 | OpenAI
13. （脱線）えっ、Python だけ。。？ 13 世の中に LLM において学習に使われているデータのうち⽇本語はごく⼀部 代表的なデータセットにおける含有率 ⽇本語 5% 程度 vs 英語 45% 程度（Common Crawl） でも、⽇本語でも⼗分使える プログラミング⾔語 Python 以外の⾔語においても ある程度ワークするであろう（というロジックは成り⽴つ） Statistics of Common Crawl Monthly Archives by commoncrawl
14. （⼩話）LLM x コーディングの相性は良い 14 話題になった DeepSeek-R1 においても、 あらかじめ答えの検証がやりやすい数学のタスクの問題 + 答えを⾃ 動的に評価する仕組みを導⼊した → コーディングにおいても同様の枠組みは⽤意しやすい LLM 周りの更なる発展は期待できる（かもしれない）
15. さまざまな開発ツールの台頭 15 • Cursor • GitHub Copilot • Cline • Windsurf • Claude Code etc.. エディタ統合型 • Devin • GitHub Copilot Coding Agent • Claude Code Action • Cursor Background Agents etc.. ⾃律型エージェント
16. 開発におけるインターフェースの変化 16 IDE ベースでの開発 チャットツール / web アプリ 経由での指⽰出し
17. エンジニアの役割の変化 17 コードを書く⼈ Claude Code どこまでも / Claude Code Everywhere | speakerdeck を参考に作成 「何を作るのか？」 「なぜ作りたいのか？」を AI に伝える⼈
18. 18 現状の課題 • コンテキスト⻑の制限 ◦ Claude / gpt シリーズ: 20 万トークン（⼩説 200 ページくらい） ◦ Gemini シリーズ: 100 万トークン（⼩説 1000 ページくらい） ◦ → ⻑時間動かしてると履歴がモデルの限界を超えてしまう • 推論モデルにおける課題 ◦ 思考ステップが多いと、コンテキスト⻑の限界を超えるため 単純なタスクも解けなくなる LLM ⾃⾝の技術的制約 The Illusion of the Illusion of Thinking A Comment on Shojaee et al. (2025)
19. 19 現状の課題 テストを削除して「テストが全部通りました！」 振る舞いの問題
20. LLM は⼈間を騙そうとする 20 • LLM の学習における⼈間からの「いいね！」を最⼤化する段階 がある（RLHF） • とある研究結果によると、モデルは 「問題を正しく解く」よりも「⼈間をうまく騙す」⽅が楽だ と判断して振る舞う可能性がある 例. ひたすら冗⻑な⽂章を出して「良さげ」に⾒せる ⼈間を騙してサボるAIたち [2409.12822] Language Models Learn to Mislead Humans via RLHF
21. ⼈間の認知能⼒の限界 21 3 分の 1 のエンジニアが AI が⽣成したコードを デプロイ前にレビューしていない AI is generating code at scale ‒ but human scale code review can’t keep up • DEVCLASS 「⼈間がコードレビューするのは         持続可能ではなくなってきている」
22. Re-Found 思考 22
23. IVRy は いま、猛烈な危機感で 「Re-Found」しています 23
24. プロダクト価値 SaaS Playbookの変容 24 市場評価 - T2D3の成⻑であればGood という前提が崩れてきた - より少⼈数/⾼速な成⻑が求 められ始めている - 従業員⼀⼈当たり売上の物 差しが今までの基準の2-3倍 になるのではないか - LLMの進化とともにデータ ベースWrapperとしての価 値は失われていく - 固定化したワークフロー対 応だけでは価値が相対的に 低くなっていく
25. confidential キーワードは「Re-Found（再創業）」 25 今この時代に起業するとしたら、どういうプロダクト構成にする？ どういうプロセスにする？を Re-Found(再創業) の気持ちで捉え直す
26. 26 「Re-Found」に必要な 3つの考え⽅ サンクコストを 捨てる AI Oriented 思考 AIの進化を 予測する 1 2 3
27. 27 IVRy が直⾯している課題 複雑なビジネスロジック‧コードベース
28. 28 IVRy が直⾯している課題 組織的な課題 • AI ツールの利⽤が個⼈レベルにとどまる • AI が出したスクリプトに対してのレビュー認知負荷増⼤ • AI ツールへの熟練度の個⼈差
29. AI 時代の設計原則 29
30. 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 flow 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
31. 31 今⽇のキーファクター Factor 3: Own your context window 各エージェントに対してインプットする コンテキストをコントロールする Factor 8: Own your control flow エージェント間の制御フローを明確に Factor 10: Small, Focused Agents ⼩さく、単⼀責任のエージェント Factor 12: Stateless reducer 状態を持たない、純粋な変換器として
32. 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)
33. 33 マルチエージェントによる解決 分業による効率化 • 設計エージェント‧テストエージェント‧実装エージェント etc 各エージェントは短いコンテキストで動作 • ⼊⼒コンテキストの削減 • 専⾨性の向上 • プロンプトのシンプル化
34. 34 （脱線）アダム‧スミス「国富論」 分業によって労働⽣産性が上昇すると説く 労働の⽣産性を⼤きく向上させ、また労働を効果的に導き活⽤する ための技能や熟練、判断⼒の多くは 分業（労働の分業化）によってもたらされているように思われる。 アダム‧スミス「国富論」より
35. 35 Claude.ai の実装例 複数のサブエージェントを連動させることでリサーチタスクを完遂 How we built our multi-agent research system \ Anthropic
36. ⽣産性を x10、x100 にするために 36
37. 37 開発⽣産性を上げるためのボトルネック AI の出すアウトプットに対する⼈間の認知負荷 ここのボトルネックをいかに排除するか？ ポイント - QA をいかにやりやすくするか - AI による⾃律部分を増やしていく - AI に⾃律的にやらせるところの境界線をいかに定義するか
38. 38 認知負荷解消への 4 つのアプローチ 1. Risk Score による⾃動判定 2. 最⼩単位での PR 分割 3. 実装計画の精緻化 4. マルチエージェント化（ワークフロー化）
39. 39 アプローチ 1: Risk Score による⾃動判定 （机上の空論を出ていないが。。。） AI が出した PR に対して、Risk Score を⾃動算出 （コード変更⾏、依存関係、影響 SLO、セキュリティ警告などをもとに算出） Risk Score が  低い = レビューなしで⾃動マージ  ⾼い = ⼈間によるレビュー必須 AI が⾏った変更内容が持つリスクを計算する新しい概念（提案）
40. 40 アプローチ 2: 最⼩単位での PR 分割 （机上の空論を出ていないが。。。） 1 PR = 最⼤ 30 分の作業量に制限 or 200 ⾏制限 これにより、PR を⼈間が⾒た時のレビュー負荷を下げる 30 分ルール
41. アプローチ 3: 実装計画の精緻化 41 • ビジネス要件の取り込み （MCP） • 技術仕様の具体化 • 曖昧さの事前解消 • コードレビュー時の 理解の助け Design Doc ⾃動⽣成 • テストシナリオの 網羅性担保 • E2E テストの ⾃動メンテナンス • リスクベースのテスト 戦略 QA 計画の⾃動策定
42. 42 アプローチ 4: マルチエージェント化 設計エージェント レビュー エージェント 実装 エージェント QA エージェント QA エージェント
43. IVRy での実践事例 43
44. 実践事例 1: AI 対話機能の⾃動 E2E テスト 44 • ⾳声インターフェイス経由で、 AI 応答機能が期待通りの挙動を ⽰すのか確認 効果 • E2E での品質保証（リグレッションテスト） • ⼈間のテスト⼯数削減 ⾳声応答品質の⾃動テスト
45. 実践事例 2: Design Doc ⾃動化フロー 45 Notion や Linear に存在しているストック情報を 連携させた Design Doc 実装フローの実現 Linear （特定コメント） Claude Code Action o3 search Notion （ビジネス背景‧ 機能要件） MCP Notion （Design Doc）
46. 実践事例 3: Linear の⾃動サマリー 46
47. 実践例 4: AI ハッカソン 47 全エンジニアが参加して1Dayの ハッカソンを実施。 全社の⽣産性改善という⽬的と、そ のプロセスの中でAIをプロダクトと して実装することを「当たり前にす る」取り組みを⾏っています。
48. おわりに 48
49. おわりに 「AI に仕事を奪われる」のではなく、 「AI とともに 10 倍以上の価値をうむ」 49
50. 50 We are Hiring!