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.
→
chiaoi
December 23, 2025
0
1
私なりのAIエージェントの理解と開発ツールの選び方
chiaoi
December 23, 2025
Tweet
Share
More Decks by chiaoi
See All by chiaoi
State machineはTurningの夢を見るか?
chiaoicchi
0
99
Fine-tuning Hands-on
chiaoicchi
0
4
kani
chiaoicchi
0
41
Trn3 UltraServer
chiaoicchi
0
8
DeepRacer cup本戦 ~30秒の切り方~
chiaoicchi
0
19
Featured
See All Featured
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
0
140
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Test your architecture with Archunit
thirion
1
2.2k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Context Engineering - Making Every Token Count
addyosmani
9
670
RailsConf 2023
tenderlove
30
1.3k
A Tale of Four Properties
chriscoyier
162
24k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
200
The Spectacular Lies of Maps
axbom
PRO
1
530
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
94
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
120
Transcript
私なりのAIエージェントの理解と 開発ツールの選び方 chiaoi
Agenda 1. 一般的なAIエージェントの定義 2. グラフで考えて理解する 3. フレームワークをグラフで捉える 4. マルチエージェントもグラフで分かる 5.
まとめ
AIエージェントの一般的定義 ワークフロー (workflows) LLMとツールが事前定義されたコードパスを通じてオーケストレーションされるシステム エージェント (agent) LLMが自らのプロセスとツール使用を動的に指示し、タスクを達成する方法についての 制御を維持するシステム 出典: https://www.anthropic.com/engineering/building-effective-agents
前提: LLMが組み込まれたシステム
AIエージェントの一般的定義 ワークフロー (workflows) LLMとツールが事前定義されたコードパスを通じてオーケストレーションされるシステム エージェント (agent) LLMが自らのプロセスとツール使用を動的に指示し、タスクを達成する方法についての 制御を維持するシステム 出典: https://www.anthropic.com/engineering/building-effective-agents
前提: LLMが組み込まれたシステム 抽象的な定義で、 AIエージェント初心者に は少しわかりづらい。
グラフで考えて整理する (LangGraphの考え方)
システムをグラフとみなす END 処理 D 処理 B 処理 A STA RT
処理 C
ノード(頂点)は処理 処理 例 State型の値が 入っていく 処理された State型の値が出てくる
エッジ(辺)は処理の流れ 処理A 処理Aを行ったあとに、 - 処理Bを行うことができる - 処理Cを行うことはできない 処理B 処理C
分岐は条件分岐(or並列実行) 処理A 処理Aを行ったあとに、 - 処理Bのみ - 処理Cのみ - 処理Bと処理Cを同時に 処理B
処理C
システムの実行はSTARTからENDへのパス END 処理 D 処理 B 処理 A STA RT
処理 C 例) START → 処理A → 処理B → 処理C → 処理B → END START → 処理A → 処理D → END
ワークフローとエージェントの違い = 分岐の進む先を誰が決めるかの違い 処理A 処理C 処理B
ワークフローの理解 処理A 処理C 処理B 処理Bに進む条件が... - 「常にBに進む」(固定フロー) - 「state.count <
3」(状態を見る) - 「random() < 0.2」(ランダム) - 「”B” in response.content」 (LLMの出力をデータとして読む) 開発者が判断ロジックを定義する
エージェントの理解 LLM 呼び 出し 処理C 処理B 処理Bに進む条件が... - 「response.tool_calls」(Tool useを見る)
- 「llm.invoke(“次はB or C?”).content == “B”」 (LLMにどうするかを直接質問する) LLMが判断をする
Tool use LLM 呼び出し 処理A Tool A LLMの判断を「構造化されたデータ 」として受け取る仕 組み。
1. LLMに使えるtoolと、その使い方を教える。 (tool として登録) 2. LLMが、「使うツール名」「引数」を構造化データとし て返す。 開発者はtool_callsを見るだけで分岐できる。 自律的な分岐が簡単に実装できる。→ 必須ではない Tool B
私なりのAIエージェント理解 1. システムをグラフで捉えると理解がしやすい 2. ワークフローとエージェントの違いは「分岐の進み先を誰が決めるか 」 3. Tool useはエージェントの必須条件ではない →
自律的な分岐(LLMが判断する分岐)を簡単にする手段 さらに 全てのフレームワークが明示的にグラフを使っているわけではないが、実装 の方法もグラフを使って理解できる。
フレームワークのAIエージェント構築方法 を グラフで表現する 注) ここからは、LLMによる条件分岐の判断がどこかにあるシス テムを「Agent」と呼びます。 一部分だけにしかないものを「Agentic Workflow」と呼ぶ方も います。
明示的にグラフを定義する END 処理 D 処理 B 処理 A STA RT
tool C 例) LangGraph 条件付き エッジ ノード エッジ ツール ノード
暗黙的にグラフを定義する 例) LangGraph、Mastra Workflow プログラミング言語を用いて - if文やwhile文を用いてグラフを作成する - 関数合成を繰り返してグラフを作成する (then:
順次実行、branch: 条件分岐)
toolを紐付けると自動的にグラフが作られる 例) Strands Agents、Mastra Agentに、 - Tool A - Tool
B を登録する STA RT END LLM Tool B Tool A
単独エージェントのまとめ LangGraph Mastra Workflow Mastra Strands Agents コントロールのしやすさ 実装の難易度 細かく制御
できる 多様なタスクに対 応できる 大変 簡単
マルチエージェント = 複数のエージェントを使用して、さらに複雑な エー ジェントタスクを行う。
エージェントを一つの処理とみなすこともできる END 処理 D 処理 B 処理 A STA RT
処理 C マルチエージェントを考えるときには、 この考え方が大切。
ノードの一部をエージェントにする END 処理 B エージェントA STA RT tool C 例)
LangGraph、Mastra 条件付き エッジ ノード ツール ノード エージェントB
全てのノードをエージェントにする STA RT 例) Strands Graph エージェント A エージェント C
エージェント B 条件付きエッ ジ or 並列実行 エージェント D END
まとめ役エージェントがいる STA RT 例) Strands Agent as Tools エージェント Top
エージェント B エージェント A END
エージェントみんなで考える STA RT 例) Strands Swarm エージェント A エージェント C
エージェント B エージェント D END
フレームワーク選定 → システムをコントロールしたい、開発期間が長い。 (LangGraph) → エージェント間の繋がりくらいはコントロールしたい。 (Mastra) → エージェントに柔軟にやってほしい、開発期間が短い。 (Strands
Agents) = 作りたいシステムがどのようなグラフで書く と表 現しやすそうかを考えてみる
紹介) 自作校正エージェント 事前に決めた7つの観点から、必ずレ ビューをして欲しかった。 7つの項目は、時間がかかるので非同期で レビューしたかった。 7つの観点からの集約の同期ポイントも確 実にして欲しかった。 実装したいシステムの流れも頭の中でイ メージができている。
LangGraphを使った 実装は大変だった
まとめ - システム全体を「グラフ」として捉えると、ワークフローやAIエージェント理解へ の助けとなった。 - 「グラフ」と捉える考え方で、「単独エージェント」や「マルチエージェント」の特徴 を解釈することができた。 - フレームワークごとにグラフのどの部分を「明示的に」開発者が作成し、どの部 分を「暗黙的に」フレームワーク内で作成するかが、かなり変わってくる。
- その違いに注目すると、エージェントフレームワークのどれを使うと良さそうか 見えてくる 。