レッスン2：エージェントの 5 つの構成要素——観察・思考・行動・記憶・道具

このレッスンで学ぶこと

エージェントを構成する 5 つの要素（観察・思考・行動・記憶・道具）を整理する
5 要素で自社のユースケースを分解できる発想を持つ
「思考」のフレームと「行動」のループの関係を理解する
短期・長期・エピソード記憶の役割の違いを区別する
「最小エージェント」と「フル装備エージェント」の境界を意識する

前のレッスンでは、AI エージェントを「観察・思考・行動の循環を持つ自律的システム」と定義しました。本レッスンは、その循環をもう一段詳細に分解する 5 要素のフレームワークを学びます。自社のユースケースを設計するときの「分解の道具」として、繰り返し参照することになります。

5 つの構成要素

AI エージェントは、次の 5 つの要素で整理できます。

flowchart TD
  P[① 観察<br/>Perception] --> R[② 思考<br/>Reasoning]
  R --> A[③ 行動<br/>Action]
  A --> P
  M[④ 記憶<br/>Memory] -.-> P
  M -.-> R
  T[⑤ 道具<br/>Tools] -.-> A

要素	役割
① 観察（Perception）	環境から情報を受け取る。ユーザー入力、ファイル、API レスポンス、Web ページなど
② 思考（Reasoning）	観察から計画を立て、次の行動を選択する。LLM の中核機能
③ 行動（Action）	計画を実世界に作用させる。ツール呼び出し、ファイル書き込み、メッセージ送信など
④ 記憶（Memory）	過去の観察・思考・行動を保持し、後のループで参照可能にする
⑤ 道具（Tools）	行動を可能にする外部機能の集合。API、ファイルシステム、検索エンジンなど

観察・思考・行動が「循環の骨格」で、記憶・道具が「循環を支える基盤」になります。本レッスンでは、それぞれを詳しく見ていきます。

💡 ポイント 5 要素のフレームは、業界で広く参照されています。古典的には Russell & Norvig 『Artificial Intelligence: A Modern Approach』（人工知能の標準教科書）で、エージェントの一般理論として体系化されました。LLM ベースのエージェントでは、これを LLM の特性に合わせて読み替える形で使います。

① 観察（Perception）

観察は、エージェントが環境から情報を取り込む入口です。

観察の対象

ユーザーからの指示（自然言語のプロンプト）
ファイルやデータベースの内容
Web ページや API のレスポンス
ほかのエージェントからのメッセージ
時刻・センサー情報（IoT 系の場合）

観察の設計論点

何を観察するか：すべての情報を渡せばよいわけではない。コンテキストウィンドウに収まる量に絞る必要がある
どう整形するか：生のデータより、LLM が理解しやすい形式（JSON、Markdown など）に整える方が判断が安定する
ノイズと信号の分離：不要な情報を取り除き、判断に必要な情報を強調する

📝 補足 観察の質は、後の思考と行動の質を直接決めます。「エージェントが間違った判断をした」と思ったら、まず観察に何が渡っているかを確認するのが、デバッグの基本です。

② 思考（Reasoning）

思考は、観察から次の行動を選ぶ中核機能です。LLM がエージェントの「頭脳」になる部分です。

思考の典型的な形

観察を読み取り、現状を要約する
ゴールとのギャップを言語化する
次に取るべき行動を 1 つ選ぶ
行動の前提条件と期待される結果を予想する

思考のパターン

レッスン 4 で詳しく扱いますが、代表的な思考パターンは次の通りです。

ReAct：Thought → Action → Observation を繰り返す
Plan-and-Execute：最初に全体計画を立て、順に実行する
Reflection：行動の結果を振り返り、次の計画を修正する

reasoning モデル（Claude Extended Thinking、OpenAI の o シリーズ、Gemini Thinking）の登場により、思考の一部はモデル内部で実行されるようになりました。この設計の使い分けはレッスン 4 で扱います。

⚠️ 注意 思考の段階を全部 LLM に委ねると、コストとレイテンシが膨らみます。実用的なエージェントは「LLM に委ねる思考」と「コードで決め打ちする処理」を明確に分けます。思考のフレーム設計が、運用の腰になります。

③ 行動（Action）

行動は、思考の結果を外部世界に作用させる出力です。

行動の典型例

Function Calling でツールを呼び出す（API、検索、ファイル操作など）
メッセージを送信する（メール、Slack、CRM 更新）
コードを実行する（Python、SQL クエリ）
ほかのエージェントを起動する（マルチエージェント協調）
ユーザーに質問する（情報不足を補うため）

行動の設計論点

取り消せるか／取り消せないか：メール送信、決済、データ削除は取り消しにくい。重要な行動には承認ステップを挟む設計が安全
副作用の範囲：1 つの行動が外部世界に何を残すかを設計時に明確にする
失敗時の挙動：ツール呼び出しが失敗したとき、リトライするのか、別案にフォールバックするのか、人間に問うのか

💡 ポイント エージェント設計で最もミスが起きやすいのは行動段階です。「ためしに動かしてみた結果、本番データが書き換わってしまった」「想定外の API コストが発生した」など、行動の副作用は事前の設計でかなり防げます。レッスン 8 のリスク管理で再度扱います。

④ 記憶（Memory）

記憶は、過去の観察・思考・行動を保持し、後のループで参照可能にする機能です。

3 種類の記憶

種類	内容	例
短期記憶	現在のループ内で参照する直近の文脈	直近の Thought・Observation の履歴
長期記憶	永続的な知識・設定・ルール	ユーザーの嗜好、企業の社内文書、ナレッジベース
エピソード記憶	過去のタスクや会話の経験	「先週同じユーザーが何を質問したか」

記憶の実装

短期記憶：コンテキストウィンドウに収まる範囲で履歴を保持。長くなれば古いものから捨てる、または要約する
長期記憶：ベクトルデータベース、構造化 DB、外部ファイルなどに保持し、必要時に検索して呼び出す
エピソード記憶：会話履歴 DB、要約スナップショット、ユーザー固有プロファイルなど

レッスン 5 で詳しく扱います。

📝 補足 「記憶」という言葉に騙されないでください。エージェントの記憶は人間の記憶とは構造が違います。重要なのは「いつ・何を・どう保存し、いつ・何を・どう取り出すか」の設計です。記憶を「持っているか／持っていないか」より「どう設計するか」が論点です。

⑤ 道具（Tools）

道具は、行動を可能にする外部機能の集合です。エージェントが「できること」の範囲を決めます。

道具の典型例

検索系：Web 検索、社内ドキュメント検索、データベースクエリ
コード実行：Python、SQL、シェルコマンド
ファイル操作：読み込み、書き込み、移動、削除
API 呼び出し：CRM、メール、Slack、決済、SaaS の各種 API
メディア処理：画像生成、音声合成、文字起こし
エージェント間通信：ほかのエージェントへのメッセージ送信

道具の設計論点

数の管理：道具を増やしすぎると LLM が選び方を間違える。10〜20 個程度に絞るのが現実的
インターフェースの統一：JSON Schema や MCP（Model Context Protocol）で、形式を揃える
権限の最小化：必要最低限の権限のみ持たせる。レッスン 8 で詳しく扱う

レッスン 3 で詳しく扱います。

⚠️ 注意 「便利だから」という理由で道具をどんどん追加すると、エージェントが「どれを使えばよいかわからない」状態になります。道具の選別は、エージェント設計の重要な投資判断です。

5 要素で自社ユースケースを分解する

5 要素のフレームは、自社で「何のエージェントを作るか」を考えるときの分解ツールとして使えます。

例：問い合わせメール対応エージェント

要素	設計
① 観察	受信メール、過去の顧客対応履歴、社内 FAQ DB
② 思考	問い合わせの種類分類、回答の下書き、必要なら担当者へ振り分け
③ 行動	回答メール送信（承認後）、CRM の問い合わせ記録更新
④ 記憶	顧客プロファイル（長期）、対応中のスレッド（短期）
⑤ 道具	メール送受信 API、社内 FAQ 検索、CRM 更新 API

例：社内データレポート作成エージェント

要素	設計
① 観察	ユーザーの指示（「先月の売上を業界別に集計して」）、データベース
② 思考	必要なクエリの計画、結果の解釈、グラフの選択
③ 行動	SQL 実行、グラフ生成、Markdown レポート出力
④ 記憶	過去のレポート設定、ユーザーの好みの形式
⑤ 道具	DB 接続、グラフ描画ライブラリ、Markdown 生成

💡 ポイント 5 要素で分解すると、「何を作るか」が具体化します。逆に分解できないなら、ユースケースとしてまだ漠然としているサインです。エージェントを作る前に、5 要素で書き出すワークショップを社内で開くだけでも、議論が一段深まります。

「最小エージェント」と「フル装備エージェント」

5 要素を全部リッチに作る必要はありません。ユースケースによっては、最小限の構成で十分なこともあります。

最小エージェント

観察：1 種類の入力のみ
思考：1 ステップのプランニング
行動：1〜2 個のツール呼び出し
記憶：なし、または短期のみ
道具：絞り込んだ 2〜3 個

フル装備エージェント

観察：複数チャネル、構造化と非構造化の両方
思考：複数ステップ、ReAct や Reflection を組み合わせ
行動：取り消しのある行動と取り消しのない行動を区別
記憶：短期・長期・エピソードのすべて
道具：10〜20 個、MCP で統一

段階的に育てる

実務では、最小エージェントから始めて、運用しながら必要な要素を足していくのが現実的です。最初からフル装備を目指すと、設計が複雑になりすぎ、デバッグが追いつかないことが多いです。

📝 補足 「最小エージェント」のラインを意図的に引く判断は、シニアエンジニアと PM のセンスが問われます。ユースケースが本当に「複数ループ」を必要としているか、「単発の LLM 呼び出し＋シンプルなコード」で十分か、を見極めることが、現実的な設計の出発点です。

講師の現場メモ：「5 要素を貼り出してから議論が変わった話」

私（高梨）が AI スタートアップで CTO だった頃、ある中堅製造業のクライアントから「自社の業務にエージェントを導入したい」と相談を受けました。最初の打ち合わせで、クライアント側から出てきた要求は、こうでした。

「AI で業務を自動化したい。何でもいいので、エージェントを作ってほしい」

何でもいい、という曖昧な依頼は、エージェント開発では最も困難な出発点です。私は 5 要素のフレームをホワイトボードに大きく書き出し、こう提案しました。

「いきなりエージェントの中身を考えるのではなく、まず 5 要素の枠に、御社の業務を当てはめてみませんか」

そして 3 つの候補業務を、5 要素で並べました。

候補 A：問い合わせメール対応
候補 B：見積書の作成
候補 C：在庫レポートの自動生成

それぞれの 5 要素を埋めていくうちに、議論の質が変わってきました。クライアントの担当者が、「Aの観察対象は実は 5 種類のメールアドレスから来ていて、種類ごとに対応が違う」「Bの行動には、税抜と税込で業界慣習が違う論点がある」「Cの記憶には、過去 3 年分のレポート設定の継続が必要」など、具体的な業務知識を次々と出してくれたのです。

3 時間のワークショップが終わるころには、「候補 C の在庫レポートが、5 要素のうち 4 つで明確にイメージできる。これから始めよう」という合意に至りました。Cの選定理由は「重要度」ではなく「5 要素で具体化できる度合い」でした。

その後 3 か月で在庫レポートエージェントを構築し、運用開始。担当者の作業時間が週 6 時間から 30 分に減りました。プロジェクトが軌道に乗ったあと、A と B も順次着手し、いずれも成功しました。

このときに学んだのが、5 要素のフレームは「設計の道具」であると同時に「ユースケース選定の道具」でもあるということです。何を作るか迷ったら、5 要素で書き出してみる。書き出せるユースケースから始める。書き出せないなら、まだ漠然としているサインなので、ユースケースをもっと具体化する。本コースの中で、5 要素のフレームを繰り返し参照するのは、この実感があるからです。

まとめ

このレッスンでは、以下のことを学びました。

エージェントは観察・思考・行動・記憶・道具の 5 要素で整理できる
観察・思考・行動が循環の骨格、記憶・道具が循環を支える基盤
観察は何を渡し、どう整形するかが鍵。観察の質が思考と行動の質を決める
思考は LLM の中核機能。reasoning モデルの登場で内部思考も主流に
行動は副作用の範囲と取り消し可能性で設計する
記憶は短期・長期・エピソードの 3 種類。それぞれ実装が違う
道具は数を絞り、インターフェースを統一し、権限を最小化する
5 要素で自社ユースケースを分解すると、設計が具体化する
最小エージェントから始め、段階的に育てるのが現実的

次のレッスンでは、5 要素の中の「道具」と「行動」を深掘りし、Function Calling、JSON Schema、Model Context Protocol（MCP）を通じてエージェントが外部世界とどう接続するかを学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。