速習 AIエージェント入門 — LegalOn Technologies 社内セミナー整理¶

作成日: 2026-07-20 出典 / きっかけ: LegalOn Technologies 浅野卓也「速習 AIエージェント入門」社外公開版（2025-11-18公開） https://speakerdeck.com/legalontechnologies/aiagent-introduction ／解説記事「社内資料「速習 AIエージェント入門」を公開します」（2025-11-21） https://tech.legalforce.co.jp/entry/aiagent-introduction 関連: ai_agent_9社_本番運用アーキテクチャ agentic_reference_architecture_評価ループ社内mcp共通基盤_認証認可ログ_整理 llm_agent_sandbox_隔離技術 context_engineering_ast活用

0. 要点（3行）¶

社内の全プロダクトマネージャー・デザイナー・エンジニア・EM向けに「エージェント用語の共通認識合わせ」を目的とした入門資料。2025年11月に2回（PdM・デザイナー向け／エンジニア・EM向け）計約190名に社内セミナーを実施した上で社外公開版として整理されている。エージェントの厳密な定義論争には深入りせず、「環境と相互作用し、与えられた目標を達成しようとするAI」という実務的な作業定義に振り切っているのが特徴。
骨格は「① 用語・定義の整理 → ② 内部構造・推論ループ → ③ 設計パターン（ReAct／Agentic Workflow／マルチエージェント）→ ④ ツール実装（MCP中心）→ ⑤ 人間とのインタラクション（HITL／Generative UI／アンビエントエージェント）→ ⑥ セキュリティ」の6段構成、全70枚。
記憶・計画・内省・コンテキストエンジニアリング・エージェント評価といった発展トピックは資料側が明示的にスコープ外としており、社内の別勉強会や新設の「AIエンジニアリングギルド」というコミュニティに委ねる設計になっている。つまりこの資料は「土台」であって「網羅的な決定版」ではない。

1. 資料の背景・位置づけ¶

項目	内容
発表者	浅野卓也（LegalOn Technologies ソフトウェアエンジニア、X: @takuya_b / @takuya_a）
スライド公開日	2025-11-18（Speaker Deck、社外公開版）
解説記事公開日	2025-11-21（LegalOn Technologies Engineering Blog）
社内セミナー実施日	2025-11-05（PdM・デザイナー向け、約40名参加）／2025-11-13（エンジニア・EM向け、約150名参加）
対象読者	開発系全職種（PdM、デザイナー、エンジニア、EM）。非エンジニア職種やエージェント実践経験の少ないエンジニアも想定
スライド枚数	70枚（社外公開版、Speaker Deckのtranscript機能で確認）
閲覧数（確認時点）	約4万回

原文で明言されている社内課題認識:

情報が溢れかえっていて、エージェント技術の基礎となる考え方を身につけるまでが大変（とくに初学者はどこから手をつけていいかわからない）
エージェント関連の用語やその言葉の意味について、共通認識が確立されておらず、コミュニケーションが非効率的

この課題に対する姿勢が明快で、「エージェントの定義についての議論に時間を費やすのは非生産的」「産業界において重要なのは、エージェントの技術を利用して役に立つシステムを開発すること」と資料内で明言し、業界の定義論争より現場の共通言語づくりを優先している。

2. 「エージェント」という用語の混乱と実務的な定義¶

AI研究の歴史として「人間のように／合理的に」×「思考／行動」の4アプローチ（Russell & Norvig の教科書 Artificial Intelligence: A Modern Approach（AIMA）でおなじみの整理）に触れているが、スライド本文の詳細な引用は未確認。
エージェントアプリケーションの例として Computer Use（OpenAI Operator、Claude）、Browser Use を挙げている。
用語整理: 「AIエージェント（AI Agents）」「LLMエージェント」という呼び分けに言及。単に「エージェント」と言うと、ソフトウェア以外（人など）もエージェントの範疇に入りうる、という注意喚起がある。
定義の紹介: AIMA の定義、および Franklin & Graesser（1996）の定義を挙げた上で「エージェントの定義は数多く提案されているが、まだ業界内で固まっていない」「単なるプログラムやLLMアプリケーションか、真にエージェントであるかを厳密に区別することはできない」と整理している。
エージェンティック（agentic）な特性として、Franklin & Graesser（1996）の特性の一つ「反応的である（reactive）: 環境の変化に応じてタイムリーに行動する」を提示（他の特性もスライドに記載があるが、本文までは未確認）。
資料としての作業定義（要点）: 「ひとまずは曖昧に、環境と相互作用し、与えられた目標（ゴール）を達成しようとするAI としよう」。行動＝ツールを利用して環境に影響を与える、知覚＝ツールを利用して環境からフィードバックを得る、という整理。

3. エージェントの内部構造と推論ループ¶

エージェントの基本概念は「環境」「エージェント」「知覚（percepts）」「行動（actions）」の4要素のループとして説明されている。

        知覚(percepts)
   環境 ───────────────▶ エージェント
   ▲                         │
   │                         │ 行動(actions)
   └─────────────────────────┘

エージェントが持つべき能力として、資料は以下を挙げている（tool use / profile はスライド18本文で確認、planning / reflection / memory はスライド25のまとめで言及）。

能力	概要
ツール利用 (tool use)	外部環境と相互作用するツールを呼び出し、知覚・行動する
プロファイル (profile)	エージェントに役割・ユーザーの好みなどを与え、振る舞いを最適化する
計画 (planning)	まとめスライドで能力の一つとして言及（詳細本文は未確認）
内省 (reflection)	同上
記憶 (memory)	同上

エージェントプログラムは内部で「思考 → 行動 → 知覚」の推論ループ（エージェントループ）を実行し、これらのモジュールを使って自律的に目標を達成しようとする、というのが資料のまとめ。

4. 設計パターン — ReAct / Agentic Workflow / マルチエージェント¶

ワークフロー vs エージェント¶

観点	ワークフロー	エージェント
ロジック	固定のロジックと依存関係を事前に定義	LLMが動的に判断
挙動	決められた条件で動作。予測可能で一貫性がある	柔軟だが予測しづらい
弱点	柔軟な対応が難しい	未確認（一般に非決定性・コストが論点になりやすい）

Agentic Workflow: ワークフローとエージェントは相互に補完できるという立場で、「ワークフローの中にエージェントを組み込む」「エージェントの中にワークフローを組み込む」というハイブリッドな方法をエージェンティックワークフロー（Agentic Workflow）と呼び、柔軟性と予測可能性の両立を狙う。

ReActエージェント: 資料内で紹介される最も基本的な設計パターン（start → agent → tools → continue/done → end のループ図）。「エージェントの設計に『正解』はまだない」「この分野は急速に発展しているので変化を柔軟に取り入れるのが大事」と明言した上で、より高度な推論・計画・内省の技法として Plan-and-Solve、Least-to-Most (L2M)、Reflexion の名前を参照のみ挙げている（本資料では詳細に立ち入らない）。

マルチエージェントシステム: 「LLMがlong contextを扱えるようになっても、1回のLLM呼び出しではうまくいかないケースがある」という課題認識（コンテキスト劣化＝Context Rot）から、マルチエージェント化の必要性を説明。初歩的なパターンとして Routingパターン（Hand-off、ルーティング先のエージェントに委譲し、呼び出されたエージェントがユーザーに直接回答する）を紹介。ブログ記事側では加えて Supervisorパターンにも言及がある（スライド本文の詳細は未確認）。エージェント間の通信については A2A と MCP の2つの手段があるとし、「ツールとして呼び出す（Agent as Tools）」などのパターンに触れている。

5. 開発フレームワークとツール実装（MCP）¶

代表的なエージェント開発フレームワークとして、スライドは SDK 系の例に OpenAI Agents SDK、Google ADK (Agent Development Kit) を挙げている（他にも列挙があるが本文は未確認）。

MCP（Model Context Protocol）: 「AIアプリケーションにとってのUSB-C」という比喩で、ツール利用のための汎用的なプロトコルとして紹介。外部システム・DBとの接続を統一的に扱う狙い。

MCPサーバーが持つ主要APIとして tools/list（どんなツールがあるかを提示）、tools/call（ツールを呼び出す）に言及。
リモートMCPサーバー（インターネット上で動くMCPサーバー）について、認証認可仕様の標準化が進行中であることに触れ、公式のリモートMCPサーバーの例として Atlassian を挙げている。
実装面では、SDKを用いれば簡単にMCPサーバーを開発できるが言語によって仕様のサポート状況はまちまちであり、TypeScriptとPythonのサポートに言及している。

ツールの粒度のトレードオフ¶

設計	長所	使いどころ
シンプルなツール群（プリミティブな操作を1つずつツール化）	ツール選択・操作をエージェントに任せられ柔軟性が高い	リモートMCPサーバーとして外部公開する場合に向く
複雑な単一ツール（ひとかたまりのワークフローを1つのツールに集約）	挙動の一貫性を高めて最適化しやすい	挙動の一貫性を優先したい場合に向く

MCPの認証認可・監査ログの共通基盤設計は社内mcp共通基盤_認証認可ログ_整理に詳しい整理があるので、実装まで踏み込む場合はそちらを参照。

6. エージェントと人間のインタラクション（UI設計）¶

チャットUI: OpenAIのChatGPTを例に、基本はテキストフォームとして実装され、画像や文書ファイルの添付でコンテキストに含める場合もある。トークンをリアルタイム表示するストリーミングがUX向上に寄与するとしている。
ヒューマンインザループ（HITL）: エージェントがアクションを実行する前後に、人間が確認・修正・承認できる仕組み。例として Claude Code CLI の承認フローに言及。承認を求めるかどうかの判定基準は「実行内容の影響度・不可逆性・スコープ・機密性」やユーザーの過去の指示内容・設定によって変わるとし、「クリティカルな部分は判断をエージェント（LLM）に任せず、バックエンドのロジックで強制的にHITLを挟む」ことを推奨している。
Generative UI: エージェントがリッチなUIコンポーネントを返し、それをフロントエンドでレンダリングする方式。Markdownだけでは表現できない独自UIや、「承認ボタン」などHITLをインタラクティブに表現できる。実装イメージは、structured outputでJSONを生成 → サーバーでスキーマ・値をバリデーション → イベントに変換してフロントエンドに送信 → フロントエンドで指定UIをレンダリング、という流れ。
アンビエントエージェント（Ambient Agents）: ユーザーが能動的に指示を出すチャットUIと対照的に、環境のイベントによってトリガーされるエージェント。タスクが完了したらユーザーに報告し、承認依頼や質問があれば一時停止してHITLを挟む。UI面では、エージェントからの承認依頼・質問に回答するUI（Agent Inbox）と、Eメール・プッシュ通知などユーザーへの通知システムが必要になるとし、LangChainのAgent Inbox的な実装に言及している（詳細は未確認）。
代表的なエージェントUIフレームワーク: Vercel AI SDK（フレームワーク非依存、UIコンポーネント自体は提供されないため自分たちで用意する必要がある）、CopilotKit を挙げている。
選択の観点: 薄いフレームワークは自由度が高いが自前実装の範囲が広い、厚いフレームワークは初期開発速度は出やすいがカスタマイズが難しいこともある。独自のデザインシステムを適用したい場合はヘッドレスUIや薄いフレームワークを選ぶ、独自イベントをストリーミングできるとGenerative UIが実装しやすく拡張性が高い、とまとめている。

7. エージェントシステムのセキュリティ¶

プロンプトインジェクション: システム側が意図していない指示をLLMに読ませる攻撃。ユーザーが直接入力したプロンプトだけでなく、エージェントが読み込んだコンテンツ（Webページ・ファイル等）にも注意が必要で、攻撃者がエージェントを悪意あるコンテンツに誘導できるケースがあると指摘。事例としてGitHub MCPサーバーのプロンプトインジェクション事案がスライド内で引用されている（出典: iotot Security News、2025-05-27付記事）。
セキュリティ対策: モデルだけに頼らず追加のセキュリティ対策を検討すべきとし、参照フレームワークとして OWASP Top 10 for LLM Applications を挙げ、LLMの出力を検証することの重要性に言及している。

sandboxによる多層防御という切り口は本資料では扱われていない。実行環境の隔離まで踏み込む場合は llm_agent_sandbox_隔離技術を参照。

8. 扱わなかったトピックと参考文献¶

資料が明示的にスコープ外としている発展トピック（「今日話さなかったこと」）:

エージェントの記憶・計画・内省の手法
コンテキストエンジニアリング
高度なエージェント設計パターン
エージェントの評価・オブザーバビリティ

これらは社内の別勉強会でフォローする方針が示されており、社内で新設された「AIエンジニアリングギルド」というコミュニティが今後の知識共有の場になるとしている。

資料内で紹介されている書籍・リソース:

『現場で活用するためのAIエージェント実践入門』（講談社サイエンティフィク）— ユーザー手元の ~/genai-agent-advanced-book（masamasa59著）と同一書籍
『LangChainとLangGraphによるRAG・AIエージェント［実践］入門』（西見公宏・吉田真吾・大嶋勇樹、技術評論社、2024-11-09刊、ISBN 9784297145309）
「Business guides and resources | OpenAI」（ガイド・ホワイトペーパーとして言及、詳細URLは未確認）

9. まとめ — 一言で / いつ使うか¶

一言で言えば、「エージェントの定義論争に決着をつけず、『環境と相互作用し目標を達成するAI』という実務定義に振り切って、PdMからエンジニアまでの共通言語を1時間で作るための土台資料」。深い技術詳細（記憶・計画・内省・評価）は意図的に持たせておらず、後続学習への橋渡しとして設計されている。

状況	この資料の使い方
チームでAIエージェント開発を始めるが用語がバラバラ	定義論争を避け、実務定義＋ReAct／Agentic Workflow／マルチエージェントの語彙合わせに使う
MCP導入を検討中	MCP概要・`tools/list`／`tools/call`・リモートMCP・ツール粒度のトレードオフ整理の出発点にする。深掘りは社内mcp共通基盤_認証認可ログ_整理へ
HITL／Generative UI／アンビエントエージェントのUI設計を検討中	本ノートの6章を出発点に、実装はVercel AI SDK／CopilotKit／LangChainのAgent Inbox等の一次資料に当たる
記憶・計画・内省・評価など高度トピックが必要	本資料は意図的にスコープ外。context_engineering_ast活用や agentic_reference_architecture_評価ループ等の既存ノートで補完する

参考リンク¶

速習 AIエージェント入門（Speaker Deck、社外公開版・全70枚）: https://speakerdeck.com/legalontechnologies/aiagent-introduction
社内資料「速習 AIエージェント入門」を公開します（LegalOn Technologies Engineering Blog、2025-11-21）: https://tech.legalforce.co.jp/entry/aiagent-introduction
LegalOn Technologies, Inc（Speaker Deckアカウント）: https://speakerdeck.com/legalontechnologies
GitHub MCP Serverのプロンプトインジェクション事例（スライド内引用記事）: https://iototsecnews.jp/2025/05/27/critical-github-mcp-server-vulnerability-allows-unauthorized-access-to-private-repositories/
『LangChainとLangGraphによるRAG・AIエージェント［実践］入門』技術評論社: https://gihyo.jp/book/2024/978-4-297-14530-9

作成: 2026-07-20 ／最終更新: 2026-07-20