Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
戦えるAIエージェントの作り方
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Takuya Akiba
October 31, 2025
Technology
29
16k
戦えるAIエージェントの作り方
Takuya Akiba
October 31, 2025
Tweet
Share
More Decks by Takuya Akiba
See All by Takuya Akiba
KaggleはAIに解けるか?MLE-Benchのいま (2025/08/23; 第4回 関東Kaggler会)
iwiwi
5
3.4k
自然着想型アプローチによる基盤モデルの研究開発 (2025/01/23, 第35回ステアラボ人工知能セミナー)
iwiwi
2
160
Evolutionary Optimization ofModel Merging Recipes (2024/04/17, NLPコロキウム)
iwiwi
11
7.2k
LLMの開発は難しい?簡単?Stability AIの現場から (2023/10/11, W&B Fully Connected)
iwiwi
12
10k
Stability AI Japanにおける大規模言語モデルの研究開発
iwiwi
17
12k
Kaggle Traveling Santa 2018 - 4th Place Solution
iwiwi
1
45
Kaggle State Farm Distracted Driver Detection
iwiwi
15
10k
Other Decks in Technology
See All in Technology
茨城の思い出を振り返る ~CDKのセキュリティを添えて~ / 20260201 Mitsutoshi Matsuo
shift_evolve
PRO
1
350
15 years with Rails and DDD (AI Edition)
andrzejkrzywda
0
200
顧客との商談議事録をみんなで読んで顧客解像度を上げよう
shibayu36
0
260
Agent Skils
dip_tech
PRO
0
120
【Oracle Cloud ウェビナー】[Oracle AI Database + AWS] Oracle Database@AWSで広がるクラウドの新たな選択肢とAI時代のデータ戦略
oracle4engineer
PRO
2
170
セキュリティについて学ぶ会 / 2026 01 25 Takamatsu WordPress Meetup
rocketmartue
1
310
CDK対応したAWS DevOps Agentを試そう_20260201
masakiokuda
1
360
Bedrock PolicyでAmazon Bedrock Guardrails利用を強制してみた
yuu551
0
250
ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立
rvirus0817
1
1.5k
Bill One急成長の舞台裏 開発組織が直面した失敗と教訓
sansantech
PRO
2
380
AIエージェントに必要なのはデータではなく文脈だった/ai-agent-context-graph-mybest
jonnojun
0
130
Why Organizations Fail: ノーベル経済学賞「国家はなぜ衰退するのか」から考えるアジャイル組織論
kawaguti
PRO
1
110
Featured
See All Featured
The untapped power of vector embeddings
frankvandijk
1
1.6k
How to train your dragon (web standard)
notwaldorf
97
6.5k
The Curse of the Amulet
leimatthew05
1
8.7k
Done Done
chrislema
186
16k
How to Think Like a Performance Engineer
csswizardry
28
2.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
Embracing the Ebb and Flow
colly
88
5k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.2k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Odyssey Design
rkendrick25
PRO
1
500
Automating Front-end Workflow
addyosmani
1371
200k
How to build a perfect <img>
jonoalderson
1
4.9k
Transcript
Sakana AI Research Scientist 秋葉 拓哉 戦える AI エージェントの 作り方
W&B Fully Connected 2025 Tokyo
AIエージェント、作るのは簡単? 2 LLMにツールをくっつければエージェントは完成? そうやって出来たエージェントは本当に実用的? 人間の専門家にも匹敵できる 強力で実用的なエージェントを作る決め手は何なのか? 02 03 04 01
専門家と戦えるAIエージェント 推論時スケーリング ドメイン知識の活用 専門家と戦えるAIエージェント 01 02 03
専門家と戦えるAIエージェント 推論時スケーリング ドメイン知識の活用 01 02 03 専門家と戦えるAIエージェント 01
The AI Scientist V2 専門家の査読を通過する論文を執筆するエージェント 5 02 03 04 01
👉 Scores: [3,4,7] 👉 Scores: [3,3,3] 👉 Scores: [6,6,7] 世界初、100%AI生成の論文が査読通過! (ICLR’25 Workshop) sakana.ai/ai-scientist-first-publication/ arxiv.org/abs/2408.06292
ALE-Agent [NeurIPS’25] 専門家並の最適化アルゴリズムを自動設計するエージェント 6 02 03 04 01 sakana.ai/ale-bench-jp/ arxiv.org/abs/2506.09050
7 02 03 04 01 トップ専門家と肩を並べる実力を実プログラミングコンテストで実証! ALE-Agent [NeurIPS’25] 専門家並の最適化アルゴリズムを自動設計するエージェント sakana.ai/ale-bench-jp/
arxiv.org/abs/2506.09050
Darwin Gödel Machine 専門家並のエージェントを自己進化で設計するエージェント 8 02 03 04 01 sakana.ai/dgm-jp/ arxiv.org/abs/2505.22954
9 02 03 04 01 専門家が何ヶ月もかけて開発したエージェント 専門家が実装したエージェントに迫る性能に到達! sakana.ai/dgm-jp/ arxiv.org/abs/2505.22954 Darwin Gödel Machine
専門家並のエージェントを自己進化で設計するエージェント
今から話すこと 10 このような、人間の専門家にも匹敵できる 強力で実用的なエージェントを作る決め手は何なのか? 02 03 04 01
専門家と戦えるAIエージェント 推論時スケーリング ドメイン知識の活用 01 02 03 専門家と戦えるAIエージェント 01
専門家と戦えるAIエージェント 推論時スケーリング ドメイン知識の活用 01 02 03 推論時スケーリング 02
(学習時)スケーリングとは? 13 01 03 04 02 Kaplan+, Scaling Laws for
Neural Language Models, https://arxiv.org/abs/2001.08361
推論時スケーリングとは? 14 (学習時ではなく)推論時にもより多くの計算量を投入する! アプローチ1:LLMが長〜いCoTをする OpenAI o1, DeepSeek R1以降のreasoning model アプローチ2:LLMと丁寧に1つの解答を構築する
Process Reward Modelの利用など アプローチ3:LLMを大量に呼び出し解答を複数作り試行錯誤させる Repeated Sampling, AlphaEvolve/ShinkaEvolve, AB-MCTSなど 01 03 04 02
推論時スケーリングとは? 15 (学習時ではなく)推論時にもより多くの計算量を投入する! アプローチ1:LLMが長〜いCoTをする OpenAI o1, DeepSeek R1以降のreasoning model アプローチ2:LLMと丁寧に1つの解答を構築する
Process Reward Modelの利用など アプローチ3:LLMを大量に呼び出し解答を複数作り試行錯誤させる Repeated Sampling, AlphaEvolve/ShinkaEvolve, AB-MCTSなど 01 03 04 02
今すぐ出来る!推論時スケーリング 16 手法1:Repeated Sampling 1. 同じプロンプトでLLMを大量に呼び出しまくる 2. 一番良さそうな解答を選んでそれを採用する 01 03
04 02 Brown+, Large Language Monkeys: Scaling Inference Compute with Repeated Sampling, https://arxiv.org/abs/2407.21787
そんな簡単な方法、使える? 17 正直めちゃくちゃ強い! SWE-Bench Lite, DeepSeek-Coder-V2 • 1問1回呼び出し → 16%
• 1問250回呼び出し → 56% LLMを呼べば呼ぶほど “正解率” が上がる (※指標がPass@kであることに注意) 01 03 04 02 Brown+, Large Language Monkeys: Scaling Inference Compute with Repeated Sampling, https://arxiv.org/abs/2407.21787
2024年中旬ぐらいから威力が話題に 18 01 03 04 02 LLMを複数回呼び出し試行錯誤させる事例はあったが、 「思いの外めっちゃ呼んだらめっちゃ強い」って風潮が加熱
……だが意外とかなり前にも事例あり 19 AlphaCode [2022, Science] 1つの問題に最大1,000,000回LLMを呼び出し (後処理をして10個まで減らし、Pass@10を評価) 01 03 04
02 Li+, Competition-Level Code Generation with AlphaCode, https://arxiv.org/abs/2203.07814
AB-MCTS [NeurIPS’25 Spotlight] 20 01 03 04 02 sakana.ai/ab-mcts-jp/ arxiv.org/abs/2503.04412
Repeated Sampling (= “go wide” ) 利点:LLMの出力の多様性を活用 欠点:フィードバックを利用出来ない
AB-MCTS [NeurIPS’25 Spotlight] 21 01 03 04 02 sakana.ai/ab-mcts-jp/ arxiv.org/abs/2503.04412
Repeated Sampling (= “go wide” ) 利点:LLMの出力の多様性を活用 欠点:フィードバックを利用出来ない Sequential Refinement (= “go deep”) 利点:フィードバックを活用できる 欠点:スケールしない つまり、続けても伸びない、間違った方針にハマりがち
AB-MCTS [NeurIPS’25 Spotlight] 22 01 03 04 02 sakana.ai/ab-mcts-jp/ arxiv.org/abs/2503.04412
LLM出力の多様性とフィードバックの両方を適応的に活用できる 推論時スケーリング用のアルゴリズム
AB-MCTS [NeurIPS’25 Spotlight] 23 01 03 04 02 sakana.ai/ab-mcts-jp/ arxiv.org/abs/2503.04412
複数社のLLMを適応的に組み合わせるアルゴリズム的拡張も可 単体LLMよりも高性能
AB-MCTS [NeurIPS’25 Spotlight] 24 01 03 04 02 sakana.ai/ab-mcts-jp/ arxiv.org/abs/2503.04412
複数の実案件で試用中
25 01 03 04 02 AlphaEvolve (Google DeepMind)
26 01 03 04 02 ShinkaEvolve sakana.ai/shinka-evolve/ arxiv.org/abs/2509.19349
27 01 03 04 02 ShinkaEvolve in Action sakana.ai/icfp-2025/ 国際的プログラミングコンテスト
ICFP-PC 2025 にて ShinkaEvolve が優勝チーム*に貢献 (*: 私を含むチーム)
専門家と戦えるAIエージェント 推論時スケーリング ドメイン知識の活用 01 02 03 推論時スケーリング 02
専門家と戦えるAIエージェント 推論時スケーリング ドメイン知識の活用 01 02 03 ドメイン知識の活用 03
ドメイン知識の活用 30 01 02 04 03 有用な知識や正しい方法が分かっているのであれば、その活用は有効 結局、昔の機械学習と根本的な構造は変わらない 特徴量エンジニアリング、前処理、データにあったNN設計、etc…… ただし方法は変わった
1. プロンプト 31 01 02 04 03 専門的プロンプト追加 知識や方法論のようなドメイン知識をプロンプトに入れる ニッチなタスクに取り組む際に特に効果がある印象
言葉遣いがどうとか頼み方がどうとかは今やどうでもいい、重要な情報を含めよう 何をどう入力するかを考えるところが少し特徴量エンジニアリングに通じる部分がある 推論時スケーリング ALE-Agent のアブレーション分析 ALE-Agent のプロンプト例
2. ワークフロー 32 01 02 04 03 ワークフローも正しい取り組み方というドメイン知識を エージェントのコードとして表現していると言える The
AI Scientist のワークフローは科学者が研究に取り組む方法論に近い
3. ルーブリック (評価基準) 33 01 02 04 03 実務では解答の評価が難しく、LLM-as-a-Judge に頼ることが多い
ルーブリックにより評価が安定すれば推論時スケーリングも可 ルーブリックの作成にはドメイン知識を活用 PaperBenchでは、扱う論文は20個のみだが、専門家が作成したルーブリックが8,316個含まれる
まとめ 34 専門家にも匹敵できる 強力で実用的なエージェントを作る決め手は何なのか? 1. 専門家と戦えるAIエージェントの事例 2. 推論時スケーリングの主要アプローチと最先端 3. ドメイン知識の活用に関する考え方と展望
01 02 03 04