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
chiaoi
December 23, 2025
9
0
Share
私なりのAIエージェントの理解と開発ツールの選び方
chiaoi
December 23, 2025
More Decks by chiaoi
See All by chiaoi
Neptune Analytics SSSP Δ-parameter
chiaoicchi
1
58
RAG入門
chiaoicchi
0
160
State machineはTurningの夢を見るか?
chiaoicchi
0
120
Fine-tuning Hands-on
chiaoicchi
0
13
kani
chiaoicchi
0
52
Trn3 UltraServer
chiaoicchi
0
23
DeepRacer cup本戦 ~30秒の切り方~
chiaoicchi
0
25
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.3k
Practical Orchestrator
shlominoach
191
11k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
510
Designing for humans not robots
tammielis
254
26k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
260
Building the Perfect Custom Keyboard
takai
2
740
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
62
53k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Six Lessons from altMBA
skipperchong
29
4.2k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
330
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
310
Facilitating Awesome Meetings
lara
57
6.8k
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エージェント理解へ の助けとなった。 - 「グラフ」と捉える考え方で、「単独エージェント」や「マルチエージェント」の特徴 を解釈することができた。 - フレームワークごとにグラフのどの部分を「明示的に」開発者が作成し、どの部 分を「暗黙的に」フレームワーク内で作成するかが、かなり変わってくる。
- その違いに注目すると、エージェントフレームワークのどれを使うと良さそうか 見えてくる 。