「AIで開発し、AIを届ける」をEvalでつなぐ 〜AIネイティブに始めるプロダクト開発の実践〜 / Connecting "Develop with AI, deliver AI" with Eval

AI Engineering Summit Tokyo 2026の登壇資料です。
https://ai-engineering-summit-tokyo.findy-tools.io/2026-summer

Transcript

1. 2026年6月9日 Asterminds株式会社 r.kagaya AI Engineering Summit Tokyo 2026 「AIで開発し、AIを届ける」をEvalでつなぐ 〜AIネイティブに始めるプロダクト開発の実践〜
2. 2022年に株式会社ログラスに入社 経営管理SaaSの開発、開発生産性向上に取り組んだのち、 生成AI/LLMチームを立ち上げ、新規AIプロダクトの立ち 上げに従事、その後、25年8月に独立・現職 翻訳を担当したAIエンジニアリングが オライリージャパンより出版 Asterminds（アスターマインズ）株式会社 共同創業者・CTO r.kagaya(@ry0_kaga) 自己紹介
3. 26年3月にシードラウンド調達を公開
4. 事業・プロダクト 事業・プロダクトの現在
5. 問い AIに作らせた成果物と、AIとして届けるプロダクト 私たちは何を根拠に受け入れるのか？
6. From AI to AI
7. From AI to AIが現実になっている AI（生成AI/LLM）は、開発工程とプロダクトの両方で前提となりつつある AIでプロダクトを作り、そのプロダクト自体もAIが搭載されるようになっている AIを使って開発する AIをプロダクトとして 届ける AIがタスクを遂行し、業務で使える出力を返す AIプロダクト AIコーディングやAgentic Engineering まとまった作業を委任する開発形態へと進んでいる
8. Cursor Developer Habits Report Cursor利用データからAI Codingによる開発者行動の変化を見るリサーチ https://cursor.com/ja/insights
9. Cursor Developer Habits Reportから見る変化 AI Codingは「まとまった作業を委任する」へ移っている より大きい作業単位をAIに任せる方向へ進んでいることを示している
10. Cursor Developer Habits Reportから見る変化 Cursorの使われ方は、目の前でコードを書かせるIDE/エディタから SDLC Automationへ進んでいる
11. Cursor Developer Habits Reportから見る変化 AIに任せる作業単位が大きくなるほど、成果物をどう受け入れるかが重要に
12. 生成の自動化ではなく、受け入れ可能性の自動化 AIが作ること自体は前提になり、 差が出るのは、その成果物をどれだけ低い負荷で受け入れられるか？ • 作業速度が上がるほど、人間レビューはボトルネックになる • 証拠のない成果物は、AIが早いほどレビュー待ちを増やす • 投資対象は、生成器だけでなく受け入れライン
13. 2つのループは同じような形をしている AIの出力を、何を根拠に信頼するかという似た問題に向き合っている 「AIエンジニアリングのEvalは、AIに開発を委任するプロセスにも適用できる」
14. 生成の自動化ではなく、受け入れ可能性の自動化 ソフトウェア開発サイクルの自動化（AI Software Factory）に向かう中で 人間の役割は、3E（Entry / Exit / Eval）、ループの設計に移っていく？ Exit Eval task / spec / scope / context / constraintsを 明確にし、何を任せるかを曖 昧にしない AIに課される制約条件も含む evidence / review packet / feedback routeを揃え、 何を証拠に受け入れるかを 決める acceptance contractと して、入口と出口をつなぐ判 断基準を置く Entry
15. 委任条件を定めるということ 信頼して、深く作業を任せるためにも、AIに委任できる条件を設計すること 任せられる範囲は、モデルの賢さだけでは決まらない
16. Evalの概念を振り返る
17. AIエンジニアリングとは何で、何から生まれた？ AIエンジニアリングとは、基盤モデルを用いてアプリケーションを構築すること AI利用の民主化がもたらした新しいエンジニアリング分野 AIアプリケーション開発のハードルの低下による環境の変化が勃興の要因 基盤モデルの登場 汎用的にタスクを解ける基盤モデルの登場 インコンテキストラーニングなど、モデル自体の変更はなしに、モデルの 振る舞いを変更することが可能 Model as a Service 一部の専門組織が開発した巨大なAIモデルを、APIを通じて誰もがサー ビスとして利用できるようになった「Model as a Service」
18. AIエンジニアリングでは何が変わる？ モデル作成から始めなくて良くなったが故のサイクルや活動領域の変化 プロダクトファースト モデル構築から適応へ 評価の固有度の増加 今はモデル開発自体は行わ ずとも、先にAIアプリケー ショ開発が行える モデルの適応（アプリケー ション要件にモデルの振る舞 いを調整する）の必要性の高 まり アプリケーション固有・オー プンエンドな出力を前提とす る機会が増加。評価の独自度 も高めることに
19. AIエンジニアリング ≠ プロンプトエンジニアリング 特に中心になるのはモデル適応技術と評価（Eval） モデル適応 評価 汎用的な基盤モデルを特定のアプリケー ションに”適応”させる ・コンテキストの制御 (Prompt/Context Engineering) ・知識と行動の拡張(RAG & Agents) ・モデルの専門化(Fine-tuning) 汎用的に賢いモデルを、いかに特定のア プリケーション要件に適合させるか 「確率的で非決定的な振る舞い」を、許容 できる品質、安全性、トーン、専門性の担 保まで確認するプロセス
20. 全ての土台となる評価 信頼できる評価軸があるからこその体系的な改善 「この修正で本当にシステムは良くなったか？」に自信を持って答えるためには？ Vibe Check（雰囲気での確認）には限界がある なぜ難しいのか？ オープンエンドな出力は正解が一つに収斂しないため AIエンジニアリングの世界においては、オープンエンドな出力の利用が 増える。 なぜ重要なのか？ 評価パイプライン・基準がなければ、開発は単なる「手探りの試行錯誤」 に陥る可能性
21. EvalはAIアプリケーションの品質管理 AIエンジニアリングにおけるEvalは、AIに点数を付ける作業だけではない AIアプリの品質を測り、回帰を検知し、改善している確信を持つための仕組み
22. 評価駆動開発（Eval Driven Development） AIアプリケーションを作る前に、評価基準とデータセット、採点方法を用意する TDDがシステム設計に向き合うためのプラクティスだったように EDDはAIアプリケーションの要求と品質基準に向き合うためのプラクティス https://vercel.com/blog/eval-driven-development-build-better-ai-faster
23. Evalは改善ループ Evalで集まる「判断・証拠・失敗理由」自体が、改善するための価値のある情報 AI出力を評価するだけでなく、AIシステムを作る・改善するための情報を集める 仕組みでもある
24. Evalをどう始めるか？
25. Evalは改善ループ 直近の失敗をcase化し、再評価できる形で残すことで、改善ループが回り始める 単発の採点ではなく、Pipelineとして設計する
26. 基準と方法 Evalは基準と方法を分ける 何を良しとするかと、どう測るかを混ぜない
27. 評価方法の種類 評価方法は一枚岩ではない 明確なNGは機械的に止め、曖昧な品質はJudgeと人間の判断に寄せる
28. 評価方法の種類 評価方法は一枚岩ではない 明確なNGは機械的に止め、曖昧な品質はJudgeと人間の判断に寄せる AIコードレビューはJudgeの典型
29. Rubric / Grader / Gate / Judge / Calibrationの関係 Graderは判定シグナルを作る評価関数。Gate/Judgeはシグナルの使い方 calibrationは判断のズレを直す （ここではJudgeを、model graderそのものではなく、主にLLMを用いたレビュー役として呼んでいます）
30. 種類ではなく、結果の使い方 種類ではなく、結果の使い方でGateにもJudgeにもなる
31. AIネイティブを目指した プロダクト開発の実践
32. Evalの考えを、AI開発フローに移植する AIプロダクトの品質保証だけでなく、AIに開発を委任するプロセスにも使える AIに深く任せるために、Entry / Exit / Evalを設計する
33. SpecはRubric Evalの要素は、AIで開発するにも、AIプロダクトを開発するにも必要な考え AI Software Factoryは、ほぼAIソフトウェア（みたいなもの） 例えば、SpecはAIへの入力であると同時に、Rubricでもある
34. Own Background Coding Workflow 弊社ではClaude Agent SDK + TypeScriptで、 Agentic Engineeringのプロセスを型化したWorkflowを内製していた （ローカル開発ではCodex/Claude Codeも利用）
35. Own Background Coding Workflow 弊社ではClaude Agent SDK + TypeScriptで、 Agentic Engineeringのプロセスを型化したWorkflowを内製していた （ローカル開発ではCodex/Claude Codeも利用） AIによるdevサーバーの立ち上げ / ブラウザ操作の機能も保持しており、 PR上で「@xxxx ブラウザQAを実行」を依頼 / PR上にスクショ添付 他開発者のPRやAI自動生成のPRに対し てもブラウザQAを自動実行もできる
36. 背景 背景としては開発チームはベース言語が英語で、海外在住メンバーも半数 AIコーディングをどのように行っているかも見えづらい 自分がAIに書かせたコードをどう信頼するか？も難しいが 国や言語を跨いだ、自分以外の開発者がAI生成したコードを信頼する難しさ このような背景もあり、「自動PRマージ率30％」をお題目に内製/整備を始めた
37. Claude Agent SDK + TypeScriptでAI開発フローをまとめる良さ コード化すると、プロセスを仕組みに埋め込める AIの作業がレビュー/評価可能な非同期プロセスになる 品質保証の組み込み 計測と改善の基盤 誰が起動しても同じプロセス が走る 個人のAI開発への熟練度に依 存しなくなる ブラウザテスト・証跡スクショ ・動画まで完了した状態で PRが出る 不良specを早期に弾き、 Codexクロスモデルレ ビューで検証 全実行のログが取れる 設計判断・インシデント履歴 をDBに永続化させるなど、 「効いてるかわからない」を 解消する土台も組み込みや すい 再現性と属人性の排除
38. ローカル実行とクラウド実行の違い local worktreeとcloud asyncは委任モデルが違う ローカル実行は「AIと一緒に考える場所」 クラウド実行は「AIに仕事を委任し、チームのプロセスとして回す場所」
39. ローカル実行とクラウド実行の違い 人間が直すほど、ワークフローの失敗は隠れやすい ポン出し型の方が改善が強制的に回しやすいと考える理由の一つ （ある種Human in the Loopで介入してしまう)
40. Human-in-the-loop / Human-on-the-loop AIに深く作業を委任するにつれ、「毎回判断」から「ループを設計し、監督」に
41. Harnessにも、評価して育てる仕組みが必要 PR単位で実行履歴やフェーズ（実装、QA等）毎の時間の割合を確認可能なダッ シュボードを整備（裏側はBraintrustを利用）
42. Harnessにも、評価して育てる仕組みが必要 人間がどの程度介入したか？等も確認 AI開発フローの改善箇所を見つけるためトレースできると便利 （LLM Ops / Evalの考えや仕組みから転用）
43. ワークフローを作るだけでは足りなかった Background Coding Workflowは今でも便利に活用中 一方で、最終的にボトルネックと感じたのはAIの成果物を受け入れるプロセス AIに深く任せる / SDLCのAutomationにはAIの成果物を受け入れる仕組み の方が重要、コーディング単体は解決されつつある 特に力を入れているのは、Browser ProofとAI Design System Background Coding Workflowからの、切り出しを進めている
44. 良い出力が出やすい環境と出たものを証明・確認する仕組み 生成前の制約と、生成後の証拠/レビューを揃えることが、 AIに委任する条件に SDLCの自動化を進めるには、このような設計が必要ではないか
45. Browser QAの仕組みに投資する理由 ソフトウェア開発サイクルの自動化「AIに深く任せる」が周りやすくなる 失敗したシナリオは、次のAIへの入力 or Caseとして再利用できる
46. Browser QAの仕組みに投資する理由 ソフトウェア開発サイクルの自動化「AIに深く任せる」が周りやすくなる 失敗したシナリオは、次のAIへの入力 or Caseとして再利用できる 画面操作からバグを見つけ、ひたすら修正のループが ローカル環境でもクラウド環境でも実行できる
47. Vibe Coding（という名称）の生みの親によるVerifiability（検証可能性） Verifiableなタスクは、最適化・自動改善の対象にしやすい • Software 1.0: 指定できることを自動化しやすい • Software 2.0: 検証できることを自動化しやすい 引用: https://karpathy.bearblog.dev/verifiability/
48. Verifiability（検証可能性） AIの答えや行動が「正しいかどうか」を、自動的に判定できるか？ Verifiableなタスクは、AIは最適化・自動改善の対象にしやすい 引用: https://karpathy.bearblog.dev/verifiability/
49. Verifiability（検証可能性）なタスクの3条件 以下3つの特性を満たせば、自動化されたフィードバックループを回せる 元はAIの学習について。参考にできる点は多々ありそう Resettable Efficient Rewardable 何度でも最初からやり直せ るか？ タスクを繰り返し、初期状態 から何度もやり直せること AIは試行錯誤を繰り返して、 フィードバックサイクルを回 せる 短時間で大量の試行ができ るか？ タスクを高速に反復実行で きること。 膨大な量の練習やサイクルを 回せることが最適化の高速 化が期待できる 結果の良し悪しを自動でスコ アリングできる？ タスクの結果を明確なスコア や基準で自動的に評価でき ること AIは何が良い結果かを学習 できる
50. Browser QAでAI出力まで評価する Browser QAを、AIプロダクト自体のオンライン評価にも利用 ユーザー操作からAI出力までを、実ブラウザ上のシナリオとして評価する プロダクトEvalのcaseや観点の判定も合わせて実行可能に
51. Browser QAでAI出力まで評価する Browser QAを、AIプロダクト自体のオンライン評価にも利用 ユーザー操作からAI出力までを、実ブラウザ上のシナリオとして評価する プロダクトEvalのcaseや観点の判定も合わせて実行可能に 音声出力ツールを提供し、 音声入力/対話の自動ブラウザテストなど LLM as a Judge
52. Browser Proof: 画面確認もAgentic Workflowに Browser QA Agentsで、UI変更を証拠付きで受け取る 今は第三世代への移行中 画面ベースでの動作確認をチーム全体の共通Eval / ハーネスに 第二世代： Workflow 第三世代： Eval Harness 主にPlaywright MCPを使 い、AIがローカルブラウザ操 作と画面確認を実行 ローカル環境に依存し、チーム 運用に載せにくかった Claude Agent TypeScript SDKで Agentic Workflow化 PR上でクラウド実行を可能に したが、コストや実行効率、シ ナリオ再利用に課題 Browserbaseベース クラウド実行、録画、cache、 シナリオ管理を統合 今までの取り組みを踏まえて、 ブラウザベースでのEval Harnessに 第一世代： Local Skill
53. Browser Proof: 画面確認もAgentic Workflowに Browser QA Agentsで、UI変更を証拠付きで受け取る 今は第三世代への移行中 画面ベースでの動作確認をチーム全体の共通Eval / ハーネスに 第二世代： Workflow 第三世代： Eval Harness 主にPlaywright MCPを使 い、AIがローカルブラウザ操 作と画面確認を実行 ローカル環境に依存し、チーム 運用に載せにくかった Claude Agent TypeScript SDKで Agentic Workflow化 PR上でクラウド実行を可能に したが、コストや実行効率、シ ナリオ再利用に課題 Browserbaseベース クラウド実行、録画、cache、 シナリオ管理を統合 今までの取り組みを踏まえて、 ブラウザベースでのEval Harnessに 第一世代： Local Skill デザインレビューや操作ドキュメント生成等も 組み込んでいる途中
54. Browserbase AI agent向けにクラウドブラウザとWeb Data APIを提供し、ログイン・JS・動 的UIを含むWebをAPIのように扱えるようにする Rampのfinance agent事例でもvendor siteやmerchant portalを ブラウザで操作・自動化
55. AI Design Systemは、UI生成のRubric デザインシステムは、AIに渡す部品表 + UI判断ガイドライン AI CodingやBackground Coding Workflowに投資する中で、 Gateを引くのが難しかった / 人によるブレが大きかったのがUI / Design
56. 改めて取り組みの中で感じたこと Background Coding Workflowによる自動PRマージ率は数十%には到達 （ライブラリアップデートや挙動の変更がない自動リファクタリング含む） 一番の要因になったのは、AIコーディングではなく、 AIブラウザQAやAIレビュー等のテスト / レビュー / 確認工程の自動化・AI化 • 重要なのはAIへの委任条件や環境、ループをどう設計するか？
57. まとめ
58. まとめ • AIに深く任せるほど、ボトルネックは「生成」から「受け入れ可能性」へ • Evalの考えは、AIプロダクトだけでなく、AI開発フローにも適用できる • 開発側では、Specで入口を揃え、Review Packet / Browser Proofで 出口を証明する取り組みに力を入れている • それによりAIに作業を委任できる環境、ループの設計を目指す • AIに任せるとは、入口・出口・Evalからなるループを設計すること、受け入れ 可能性を設計すること
59. おわり