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

by r-kagaya

Embed

Start on current slide

Slide 1

Slide 1 text

2026年6月9日 Asterminds株式会社 r.kagaya AI Engineering Summit Tokyo 2026 「AIで開発し、AIを届ける」をEvalでつなぐ〜AIネイティブに始めるプロダクト開発の実践〜

Slide 2

Slide 2 text

2022年に株式会社ログラスに入社経営管理SaaSの開発、開発生産性向上に取り組んだのち、生成AI/LLMチームを立ち上げ、新規AIプロダクトの立ち上げに従事、その後、25年8月に独立・現職翻訳を担当したAIエンジニアリングがオライリージャパンより出版 Asterminds（アスターマインズ）株式会社共同創業者・CTO r.kagaya(@ry0_kaga) 自己紹介

Slide 3

Slide 3 text

26年3月にシードラウンド調達を公開

Slide 4

Slide 4 text

事業・プロダクト事業・プロダクトの現在

Slide 5

Slide 5 text

問い AIに作らせた成果物と、AIとして届けるプロダクト私たちは何を根拠に受け入れるのか？

Slide 6

Slide 6 text

From AI to AI

Slide 7

Slide 7 text

From AI to AIが現実になっている AI（生成AI/LLM）は、開発工程とプロダクトの両方で前提となりつつある AIでプロダクトを作り、そのプロダクト自体もAIが搭載されるようになっている AIを使って開発する AIをプロダクトとして届ける AIがタスクを遂行し、業務で使える出力を返す AIプロダクト AIコーディングやAgentic Engineering まとまった作業を委任する開発形態へと進んでいる

Slide 8

Slide 8 text

Cursor Developer Habits Report Cursor利用データからAI Codingによる開発者行動の変化を見るリサーチ https://cursor.com/ja/insights

Slide 9

Slide 9 text

Cursor Developer Habits Reportから見る変化 AI Codingは「まとまった作業を委任する」へ移っているより大きい作業単位をAIに任せる方向へ進んでいることを示している

Slide 10

Slide 10 text

Cursor Developer Habits Reportから見る変化 Cursorの使われ方は、目の前でコードを書かせるIDE/エディタから SDLC Automationへ進んでいる

Slide 11

Slide 11 text

Cursor Developer Habits Reportから見る変化 AIに任せる作業単位が大きくなるほど、成果物をどう受け入れるかが重要に

Slide 12

Slide 12 text

生成の自動化ではなく、受け入れ可能性の自動化 AIが作ること自体は前提になり、差が出るのは、その成果物をどれだけ低い負荷で受け入れられるか？ ● 作業速度が上がるほど、人間レビューはボトルネックになる ● 証拠のない成果物は、AIが早いほどレビュー待ちを増やす ● 投資対象は、生成器だけでなく受け入れライン

Slide 13

Slide 13 text

2つのループは同じような形をしている AIの出力を、何を根拠に信頼するかという似た問題に向き合っている「AIエンジニアリングのEvalは、AIに開発を委任するプロセスにも適用できる」

Slide 14

Slide 14 text

生成の自動化ではなく、受け入れ可能性の自動化ソフトウェア開発サイクルの自動化（AI Software Factory）に向かう中で人間の役割は、3E（Entry / Exit / Eval）、ループの設計に移っていく？ Exit Eval task / spec / scope / context / constraintsを明確にし、何を任せるかを曖昧にしない AIに課される制約条件も含む evidence / review packet / feedback routeを揃え、何を証拠に受け入れるかを決める acceptance contractとして、入口と出口をつなぐ判断基準を置く Entry

Slide 15

Slide 15 text

委任条件を定めるということ信頼して、深く作業を任せるためにも、AIに委任できる条件を設計すること任せられる範囲は、モデルの賢さだけでは決まらない

Slide 16

Slide 16 text

Evalの概念を振り返る

Slide 17

Slide 17 text

AIエンジニアリングとは何で、何から生まれた？ AIエンジニアリングとは、基盤モデルを用いてアプリケーションを構築すること AI利用の民主化がもたらした新しいエンジニアリング分野 AIアプリケーション開発のハードルの低下による環境の変化が勃興の要因基盤モデルの登場汎用的にタスクを解ける基盤モデルの登場インコンテキストラーニングなど、モデル自体の変更はなしに、モデルの振る舞いを変更することが可能 Model as a Service 一部の専門組織が開発した巨大なAIモデルを、APIを通じて誰もがサービスとして利用できるようになった「Model as a Service」

Slide 18

Slide 18 text

AIエンジニアリングでは何が変わる？モデル作成から始めなくて良くなったが故のサイクルや活動領域の変化プロダクトファーストモデル構築から適応へ評価の固有度の増加今はモデル開発自体は行わずとも、先にAIアプリケーショ開発が行えるモデルの適応（アプリケーション要件にモデルの振る舞いを調整する）の必要性の高まりアプリケーション固有・オープンエンドな出力を前提とする機会が増加。評価の独自度も高めることに

Slide 19

Slide 19 text

AIエンジニアリング ≠ プロンプトエンジニアリング特に中心になるのはモデル適応技術と評価（Eval）モデル適応評価汎用的な基盤モデルを特定のアプリケーションに”適応”させる・コンテキストの制御 (Prompt/Context Engineering) ・知識と行動の拡張(RAG & Agents) ・モデルの専門化(Fine-tuning) 汎用的に賢いモデルを、いかに特定のアプリケーション要件に適合させるか「確率的で非決定的な振る舞い」を、許容できる品質、安全性、トーン、専門性の担保まで確認するプロセス

Slide 20

Slide 20 text

全ての土台となる評価信頼できる評価軸があるからこその体系的な改善「この修正で本当にシステムは良くなったか？」に自信を持って答えるためには？ Vibe Check（雰囲気での確認）には限界があるなぜ難しいのか？オープンエンドな出力は正解が一つに収斂しないため AIエンジニアリングの世界においては、オープンエンドな出力の利用が増える。なぜ重要なのか？評価パイプライン・基準がなければ、開発は単なる「手探りの試行錯誤」に陥る可能性

Slide 21

Slide 21 text

EvalはAIアプリケーションの品質管理 AIエンジニアリングにおけるEvalは、AIに点数を付ける作業だけではない AIアプリの品質を測り、回帰を検知し、改善している確信を持つための仕組み

Slide 22

Slide 22 text

評価駆動開発（Eval Driven Development） AIアプリケーションを作る前に、評価基準とデータセット、採点方法を用意する TDDがシステム設計に向き合うためのプラクティスだったように EDDはAIアプリケーションの要求と品質基準に向き合うためのプラクティス https://vercel.com/blog/eval-driven-development-build-better-ai-faster

Slide 23

Slide 23 text

Evalは改善ループ Evalで集まる「判断・証拠・失敗理由」自体が、改善するための価値のある情報 AI出力を評価するだけでなく、AIシステムを作る・改善するための情報を集める仕組みでもある

Slide 24

Slide 24 text

Evalをどう始めるか？

Slide 25

Slide 25 text

Evalは改善ループ直近の失敗をcase化し、再評価できる形で残すことで、改善ループが回り始める単発の採点ではなく、Pipelineとして設計する

Slide 26

Slide 26 text

基準と方法 Evalは基準と方法を分ける何を良しとするかと、どう測るかを混ぜない

Slide 27

Slide 27 text

評価方法の種類評価方法は一枚岩ではない明確なNGは機械的に止め、曖昧な品質はJudgeと人間の判断に寄せる

Slide 28

Slide 28 text

評価方法の種類評価方法は一枚岩ではない明確なNGは機械的に止め、曖昧な品質はJudgeと人間の判断に寄せる AIコードレビューはJudgeの典型

Slide 29

Slide 29 text

Rubric / Grader / Gate / Judge / Calibrationの関係 Graderは判定シグナルを作る評価関数。Gate/Judgeはシグナルの使い方 calibrationは判断のズレを直す（ここではJudgeを、model graderそのものではなく、主にLLMを用いたレビュー役として呼んでいます）

Slide 30

Slide 30 text

種類ではなく、結果の使い方種類ではなく、結果の使い方でGateにもJudgeにもなる

Slide 31

Slide 31 text

AIネイティブを目指したプロダクト開発の実践

Slide 32

Slide 32 text

Evalの考えを、AI開発フローに移植する AIプロダクトの品質保証だけでなく、AIに開発を委任するプロセスにも使える AIに深く任せるために、Entry / Exit / Evalを設計する

Slide 33

Slide 33 text

SpecはRubric Evalの要素は、AIで開発するにも、AIプロダクトを開発するにも必要な考え AI Software Factoryは、ほぼAIソフトウェア（みたいなもの）例えば、SpecはAIへの入力であると同時に、Rubricでもある

Slide 34

Slide 34 text

Own Background Coding Workflow 弊社ではClaude Agent SDK + TypeScriptで、 Agentic Engineeringのプロセスを型化したWorkflowを内製していた（ローカル開発ではCodex/Claude Codeも利用）

Slide 35

Slide 35 text

Own Background Coding Workflow 弊社ではClaude Agent SDK + TypeScriptで、 Agentic Engineeringのプロセスを型化したWorkflowを内製していた（ローカル開発ではCodex/Claude Codeも利用） AIによるdevサーバーの立ち上げ / ブラウザ操作の機能も保持しており、 PR上で「@xxxx ブラウザQAを実行」を依頼 / PR上にスクショ添付他開発者のPRやAI自動生成のPRに対してもブラウザQAを自動実行もできる

Slide 36

Slide 36 text

背景背景としては開発チームはベース言語が英語で、海外在住メンバーも半数 AIコーディングをどのように行っているかも見えづらい自分がAIに書かせたコードをどう信頼するか？も難しいが国や言語を跨いだ、自分以外の開発者がAI生成したコードを信頼する難しさこのような背景もあり、「自動PRマージ率30％」をお題目に内製/整備を始めた

Slide 37

Slide 37 text

Claude Agent SDK + TypeScriptでAI開発フローをまとめる良さコード化すると、プロセスを仕組みに埋め込める AIの作業がレビュー/評価可能な非同期プロセスになる品質保証の組み込み計測と改善の基盤誰が起動しても同じプロセスが走る個人のAI開発への熟練度に依存しなくなるブラウザテスト・証跡スクショ・動画まで完了した状態で PRが出る不良specを早期に弾き、 Codexクロスモデルレビューで検証全実行のログが取れる設計判断・インシデント履歴をDBに永続化させるなど、「効いてるかわからない」を解消する土台も組み込みやすい再現性と属人性の排除

Slide 38

Slide 38 text

ローカル実行とクラウド実行の違い local worktreeとcloud asyncは委任モデルが違うローカル実行は「AIと一緒に考える場所」クラウド実行は「AIに仕事を委任し、チームのプロセスとして回す場所」

Slide 39

Slide 39 text

ローカル実行とクラウド実行の違い人間が直すほど、ワークフローの失敗は隠れやすいポン出し型の方が改善が強制的に回しやすいと考える理由の一つ（ある種Human in the Loopで介入してしまう)

Slide 40

Slide 40 text

Human-in-the-loop / Human-on-the-loop AIに深く作業を委任するにつれ、「毎回判断」から「ループを設計し、監督」に

Slide 41

Slide 41 text

Harnessにも、評価して育てる仕組みが必要 PR単位で実行履歴やフェーズ（実装、QA等）毎の時間の割合を確認可能なダッシュボードを整備（裏側はBraintrustを利用）

Slide 42

Slide 42 text

Harnessにも、評価して育てる仕組みが必要人間がどの程度介入したか？等も確認 AI開発フローの改善箇所を見つけるためトレースできると便利（LLM Ops / Evalの考えや仕組みから転用）

Slide 43

Slide 43 text

ワークフローを作るだけでは足りなかった Background Coding Workflowは今でも便利に活用中一方で、最終的にボトルネックと感じたのはAIの成果物を受け入れるプロセス AIに深く任せる / SDLCのAutomationにはAIの成果物を受け入れる仕組みの方が重要、コーディング単体は解決されつつある特に力を入れているのは、Browser ProofとAI Design System Background Coding Workflowからの、切り出しを進めている

Slide 44

Slide 44 text

良い出力が出やすい環境と出たものを証明・確認する仕組み生成前の制約と、生成後の証拠/レビューを揃えることが、 AIに委任する条件に SDLCの自動化を進めるには、このような設計が必要ではないか

Slide 45

Slide 45 text

Browser QAの仕組みに投資する理由ソフトウェア開発サイクルの自動化「AIに深く任せる」が周りやすくなる失敗したシナリオは、次のAIへの入力 or Caseとして再利用できる

Slide 46

Slide 46 text

Browser QAの仕組みに投資する理由ソフトウェア開発サイクルの自動化「AIに深く任せる」が周りやすくなる失敗したシナリオは、次のAIへの入力 or Caseとして再利用できる画面操作からバグを見つけ、ひたすら修正のループがローカル環境でもクラウド環境でも実行できる

Slide 47

Slide 47 text

Vibe Coding（という名称）の生みの親によるVerifiability（検証可能性） Verifiableなタスクは、最適化・自動改善の対象にしやすい ● Software 1.0: 指定できることを自動化しやすい ● Software 2.0: 検証できることを自動化しやすい引用: https://karpathy.bearblog.dev/verifiability/

Slide 48

Slide 48 text

Verifiability（検証可能性） AIの答えや行動が「正しいかどうか」を、自動的に判定できるか？ Verifiableなタスクは、AIは最適化・自動改善の対象にしやすい引用: https://karpathy.bearblog.dev/verifiability/

Slide 49

Slide 49 text

Verifiability（検証可能性）なタスクの3条件以下3つの特性を満たせば、自動化されたフィードバックループを回せる元はAIの学習について。参考にできる点は多々ありそう Resettable Efficient Rewardable 何度でも最初からやり直せるか？タスクを繰り返し、初期状態から何度もやり直せること AIは試行錯誤を繰り返して、フィードバックサイクルを回せる短時間で大量の試行ができるか？タスクを高速に反復実行できること。膨大な量の練習やサイクルを回せることが最適化の高速化が期待できる結果の良し悪しを自動でスコアリングできる？タスクの結果を明確なスコアや基準で自動的に評価できること AIは何が良い結果かを学習できる

Slide 50

Slide 50 text

Browser QAでAI出力まで評価する Browser QAを、AIプロダクト自体のオンライン評価にも利用ユーザー操作からAI出力までを、実ブラウザ上のシナリオとして評価するプロダクトEvalのcaseや観点の判定も合わせて実行可能に

Slide 51

Slide 51 text

Browser QAでAI出力まで評価する Browser QAを、AIプロダクト自体のオンライン評価にも利用ユーザー操作からAI出力までを、実ブラウザ上のシナリオとして評価するプロダクトEvalのcaseや観点の判定も合わせて実行可能に音声出力ツールを提供し、音声入力/対話の自動ブラウザテストなど LLM as a Judge

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Browserbase AI agent向けにクラウドブラウザとWeb Data APIを提供し、ログイン・JS・動的UIを含むWebをAPIのように扱えるようにする Rampのfinance agent事例でもvendor siteやmerchant portalをブラウザで操作・自動化

Slide 55

Slide 55 text

AI Design Systemは、UI生成のRubric デザインシステムは、AIに渡す部品表 + UI判断ガイドライン AI CodingやBackground Coding Workflowに投資する中で、 Gateを引くのが難しかった / 人によるブレが大きかったのがUI / Design

Slide 56

Slide 56 text

改めて取り組みの中で感じたこと Background Coding Workflowによる自動PRマージ率は数十%には到達（ライブラリアップデートや挙動の変更がない自動リファクタリング含む）一番の要因になったのは、AIコーディングではなく、 AIブラウザQAやAIレビュー等のテスト / レビュー / 確認工程の自動化・AI化 ● 重要なのはAIへの委任条件や環境、ループをどう設計するか？

Slide 57

Slide 57 text

まとめ

Slide 58

Slide 58 text

まとめ ● AIに深く任せるほど、ボトルネックは「生成」から「受け入れ可能性」へ ● Evalの考えは、AIプロダクトだけでなく、AI開発フローにも適用できる ● 開発側では、Specで入口を揃え、Review Packet / Browser Proofで出口を証明する取り組みに力を入れている ● それによりAIに作業を委任できる環境、ループの設計を目指す ● AIに任せるとは、入口・出口・Evalからなるループを設計すること、受け入れ可能性を設計すること

Slide 59

Slide 59 text

おわり