Slide 1
Slide 1 text
2026年1月15日
Asterminds株式会社 r.kagaya
AI Agent 大勉強会 in Tokyo 〜2026 Winter〜
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
Verifiabilityを担保して、
自動評価パイプラインで、
10倍の試行を回したい...！
今日の内容
Slide 4
Slide 4 text
エージェントの「振る舞い」を設計する
Slide 5
Slide 5 text
エージェントの「振る舞い」を設計する
AIエージェントは、環境とツールによって規定される by オライリーAIエンジニアリング
与えられた環境とツールの中で、どう動くか？
状況 判断 行動
e.g. ユーザーの指示、現在
の状態
e.g. どのツールをいつ使う
か
e.g. ツールの実行
Slide 6
Slide 6 text
エージェントの「振る舞い」を設計する
AIエージェントは、環境とツールによって規定される by オライリーAIエンジニアリング
与えられた環境とツールの中で、どう動くか？
状況 判断 行動
e.g. ユーザーの指示、現在
の状態
e.g. どのツールをいつ使う
か
e.g. ツールの実行
「ファイル操作を求められたら、
まず影響範囲を確認する。
3ファイル以上に影響するなら、
実行前にユーザーに確認を取る。」
Slide 7
Slide 7 text
モデルはIQの高い天才 but...
コンテキストがなければ、モデルは適切に動けない可能性
「できること」だけではなく、手順まで構造化して渡した方がコンテキストリッチ
AIエージェント製品に求められるのは、大抵はExpert
賢さだけでなく、ドメイン知識・手順を保持すること
Slide 8
Slide 8 text
Tool Useの限界
Toolを渡すだけでなく、そのToolをいつ・どう使うか？までセットで構造化
実装方法に限らず、「何ができるか」だけではなく、「どう振る舞うか」の実現
Slide 9
Slide 9 text
振る舞いを定義したら、
次はそれをどう評価するか？
Slide 10
Slide 10 text
エージェントの「評価」を設計する
「正しく動いた」とは何か？を定義する
評価なきエージェントは、テストなきコード、振る舞いをどうにか測れる形に
評価軸 測り方
タスク完了率
ツール選択の適切さ
無駄なステップ
安全性
検索結果との一致
最短経路との比較
不要な実行の回数
確認なし操作の有無
Slide 11
Slide 11 text
評価ループを回す
評価は1回で終わりではない、ループで回す概念
振る舞い定義/修正
実行
評価
改善点特定
Slide 12
Slide 12 text
Anthropicのエンジニアリングチームも
言ってます。
「評価から始めよ」
Slide 13
Slide 13 text
でも、このループが回ると
何が実現できそうなのか？嬉しいのか？
Slide 14
Slide 14 text
Verifiability（検証可能性）
Slide 15
Slide 15 text
Vibe Coding（という名称）の生みの親によるVerifiability（検証可能性）
AIの答えや行動が「正しいかどうか」を、自動的に判定できるか？
Verifiableなタスクは、AIは加速度的に学習・進化できる
引用: https://karpathy.bearblog.dev/verifiability/
Slide 16
Slide 16 text
Verifiability（検証可能性）
検証できることはすべからず自動化・改善サイクルが回せる（意訳）
● Software 1.0: 指定できることを自動化する
● Software 2.0: 検証できることを自動化する
引用: https://karpathy.bearblog.dev/verifiability/
Slide 17
Slide 17 text
Verifiability（検証可能性）なタスクの3条件
以下3つの特性を満たせば、自動化されたフィードバックループを回せる
元記事は、AIの学習に寄った内容だが、参考にできる点は多々ありそう
Resettable Efficient Rewardable
何度でも最初からやり直せ
るか？
タスクを繰り返し、初期状態
から何度もやり直せること
AIは試行錯誤を繰り返して、
フィードバックサイクルを回
せる
短時間で大量の試行ができ
るか？
タスクを高速に反復実行で
きること。
膨大な量の練習やサイクルを
回せることが最適化の高速
化が期待できる
結果の良し悪しを自動でスコ
アリングできる？
タスクの結果を明確なスコア
や基準で自動的に評価でき
ること
AIは何が良い結果かを学習
できる
Slide 18
Slide 18 text
従来は「こう動け」とコードで指定した
エージェントは「こう動いたら正解」と評価
で検証する
Slide 19
Slide 19 text
AIエージェント開発（だけに限らないが）は
Verifiabilityそのものに感じる
Slide 20
Slide 20 text
Verifiabilityを担保して、
自動評価パイプラインで、
10倍の試行を回したい...！
Slide 21
Slide 21 text
具体的になにができる？
Slide 22
Slide 22 text
参考: Anthropic - Bloom
AIモデルが「特定の振る舞い」をどの程度起こすかを、AIエージェントを使って
自動でテスト・評価するオープンソースフレームワーク「Bloom」
引用: https://www.anthropic.com/research/bloom
Slide 23
Slide 23 text
評価を回すには？
何をもって正解とするか？どういうシナリオか？どう図るか？どう実際に実行す
る？
Slide 24
Slide 24 text
最近取り組んでいること
評価から改善のサイクルを半自動で回す
Slide 25
Slide 25 text
最近取り組んでいること
評価から改善のサイクルを半自動で回す
ブラウザ操作と評価の
半自動化
Slide 26
Slide 26 text
最近取り組んでいること
評価から改善のサイクルを半自動で回す
正解の流れとの差分判定と
近づけるための自動修正
Slide 27
Slide 27 text
最近取り組んでいること
評価から改善のサイクルを半自動で回す
プロダクト上でFew shotsを
動的に差し替える機能
Slide 28
Slide 28 text
Claude CodeとSkills使ったブラウザ操作テストの自動化
Skillsに加えて、理想のシナリオもディレクトリ内管理
それを元にひたすらAIでAIのテストを実施。TTS Scriptsなども整備して、音声
対話もある程度自動で回せるようにしてる（コストかかるが..）
よくやるのは、多言語対応の動作確認
ベトナム語・中国語の確認など
Slide 29
Slide 29 text
ブラウザ操作の自動化
ブラウザ操作の自動化、最近はVercelのAgent browserを利用
● CLI でブラウザを操作するツール
● Playwright MCPと比較してコンテキスト消費を抑えることが可能
e.g. 振る舞いの修正であれば、自動で10回テストさせて再現率をチェックする
Slide 30
Slide 30 text
評価から改善へ（Flywheel）
ゴールデンデータセットや評価基準が存在したら、一定の試行は自動化可能
1. 実行->実行結果/履歴を収集
2. 「何が良かった？悪かった？」をLLMにJudgeさせる
3. Skills/プロンプトの修正案を生成
4. 修正データを動的にプロンプト・Few-shots等に反映
5. 再評価
→ バックグラウンドで回して、人間は結果/レポートを確認する
Slide 31
Slide 31 text
Automated Design for Agent
自動でAIエージェント・AIワークフローを作成する取り組み例はちらほらあり、
読み物として面白い。From AI to AIの世界
Slide 32
Slide 32 text
「動くエージェント」は誰でも作れる時代 but 作り方で差が出る時代？
とは言え、甘めに見積もっても一部動作確認・修正作業を半自動化できるぐらい
先は長いが、現状の仕組みでも裏側でAIが操作させることで、その分だけ自分の
手は空いてる
ループをいかに早く・大量に回せるかで開発スピードにも顕著に差がつくか？
Slide 33
Slide 33 text
評価駆動の改善ループ高速化が進み、
開発速度に顕著に差が出る余地はあるか？
Slide 34
Slide 34 text
再掲
人間がやるのはここだけになるのが一つの理想？
何をもって正解とするか？どういうシナリオか？どう図るか？どう実際に実行す
る？
Slide 35
Slide 35 text
とはいえ課題は色々
Slide 36
Slide 36 text
一つはシミュレータ・評価自動化AIの
評価は誰がやるか？
（監視員を監視する監視員の世界）
Slide 37
Slide 37 text
まとめ
Slide 38
Slide 38 text
まとめ
● モデルを業務の専門家にするためのプロダクト設計
● AIプロダクトには評価は不可欠、どうせならVerifiabilityを活かせるか？
○ 振る舞いをモジュールとして設計できるか、検証可能な評価軸を設計で
きるか、高速で評価ループを回せるか
○ （AIエージェントに限らないが）
● 評価結果をFew shotsに還流させて、フライホイールを作るのは一つの
GOODパターンではないか
● Who Validates the Validatorsなどの問題はある
Slide 39
Slide 39 text
終わり