AI Agentという言葉を見かける機会は増えましたが、「普通のチャットAIと何が違うのか」と聞かれると、説明が難しい概念でもあります。

たとえば、Claude Codeにコードベースを調べてもらい、そのままファイルを修正してテストまで実行させる。ChatGPTにWeb上の情報や手元のファイルを調べてもらい、複数の手順をまたいで成果物を作らせる。こうした使い方では、AIは単に文章を返しているのではなく、状況を確認し、必要な手段を選び、結果を見ながら次の行動を決めています。

本記事では、AI Agentを特定の製品やフレームワークからではなく、仕組みから理解します。最初に全体像を整理し、その後にReAct、コンテキスト、ツール、Harness、ワークフロー、自律型Agent、安全設計へ順番に進みます。

AI Agentを3つの要素で捉える

Agentには複数の定義があります。製品やフレームワークによって含まれる機能も異なるため、「これだけが正しい定義」と決めるより、実装を理解するための分解方法を持っておく方が役立ちます。

本記事では、Agentを次の3要素で考えます。

Agent = 意思決定を行うモデル + 情報を与えるコンテキスト + 外部へ作用するツール

要素役割例
意思決定を行うモデル何をするか、次に何を確認するかを判断するLLM、推論モデル
コンテキスト現在の判断に必要な情報を渡すユーザー入力、履歴、ファイル、検索結果、メモリ
ツール外部から情報を取得したり、実際の操作を行ったりするWeb検索、API、シェル、ファイル操作、ブラウザ

モデルだけでは、現実世界の最新情報を確認したり、ファイルを書き換えたり、外部システムへ処理を依頼したりできません。逆に、ツールを大量に用意しても、どのタイミングで何を使うかを適切に判断できなければ有効に機能しません。

Agentの設計では「どのモデルを使うか」だけを見るのではなく、何を見せるかと、何をさせられるかを同時に設計する必要があります。

Claude Codeは、この3要素をイメージしやすい例です。モデルがコードを読みながら判断し、リポジトリやコマンドの出力をコンテキストとして受け取り、ファイル操作やシェルなどのツールを使って作業を進めます。

Overview - Claude Code Docs

Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. Available in your terminal, IDE, desktop app, and browser.

https://docs.anthropic.com/ja/docs/claude-code

Claude Code Docs · docs.anthropic.com

Agentは一度で答えず、結果を見ながら進む

一般的なチャットでは、入力に対してモデルが応答を生成すれば処理はひとまず終わります。一方、Agentでは一度のモデル呼び出しだけで完了しないことがあります。

たとえば「東京から京都へ2泊3日で旅行したい。予算を抑えつつ寺社を中心に回りたい」という依頼を考えます。Agentは次のように段階を分けて処理できます。

  1. 条件を整理する
  2. 交通手段と宿泊候補を調べる
  3. 得られた価格や位置情報を確認する
  4. 観光候補と移動時間を調べる
  5. 条件に合わなければ検索条件を変える
  6. 最終的な日程へまとめる

重要なのは、最初からすべてを固定して実行するのではなく、途中で得られた結果を次の判断材料にすることです。

このような「考える・行動する・結果を確認する」という構造を理解するうえで、代表的な考え方がReActです。

ReAct：ReasoningとActingを組み合わせる

ReActは「Reasoning + Acting」を組み合わせた手法として2022年に提案されました。モデルによる推論と、外部環境に対する行動を交互に行うことで、外部情報を取り込みながらタスクを進めます。

ReAct: Synergizing Reasoning and Acting in Language Models

While large language models (LLMs) have demonstrated impressive capabilities across tasks in language understanding and interactive decision making, their abilities for reasoning (e.g. chain-of-thought prompting) and acting (e.g. action plan generation) have primarily been studied as separate topics. In this paper, we explore the use of LLMs to generate both reasoning traces and task-specific actions in an interleaved manner, allowing for greater synergy between the two: reasoning traces help the model induce, track, and update action plans as well as handle exceptions, while actions allow it to interface with external sources, such as knowledge bases or environments, to gather additional information. We apply our approach, named ReAct, to a diverse set of language and decision making tasks and demonstrate its effectiveness over state-of-the-art baselines, as well as improved human interpretability and trustworthiness over methods without reasoning or acting components. Concretely, on question answering (HotpotQA) and fact verification (Fever), ReAct overcomes issues of hallucination and error propagation prevalent in chain-of-thought reasoning by interacting with a simple Wikipedia API, and generates human-like task-solving trajectories that are more interpretable than baselines without reasoning traces. On two interactive decision making benchmarks (ALFWorld and WebShop), ReAct outperforms imitation and reinforcement learning methods by an absolute success rate of 34% and 10% respectively, while being prompted with only one or two in-context examples. Project site with code: https://react-lm.github.io

https://arxiv.org/abs/2210.03629

arXiv.org · arxiv.org

概念上は、次の3段階を繰り返すと理解できます。

  1. 判断する：現在わかっている情報から、次に必要な行動を決める
  2. 行動する：検索、API呼び出し、コード実行などを行う
  3. 観測する：ツールの結果を受け取り、次の判断材料へ加える

たとえばWeb調査なら、「公式情報が必要」と判断して検索し、検索結果を読んだあと、「情報が古いので別の一次情報を探す」と判断できます。コード修正なら、ファイルを変更したあとにテストを実行し、失敗結果を見て別の修正へ進めます。

現在のAgent実装が必ずしもThought → Action → Observationという文字列をそのまま出力しているわけではありません。推論を内部で行うモデルもあり、内部の思考過程をユーザーやアプリケーションへ公開しない設計も一般的です。

そのため実務では、ReActを「内部の思考文を保存する方式」と捉えるより、モデルの判断とツール実行が結果を介してループする構造として理解する方が扱いやすくなります。

実行トレースがAgentの状態をつなぐ

Agentが複数ステップを進めるには、「これまで何をしたか」が次の処理へ引き継がれる必要があります。

実装では、ユーザー入力、モデルが選択した操作、ツールの引数、ツールの結果、最終出力などを時系列に記録します。ここではこれを実行トレースと呼びます。

ユーザー:
  東京から京都へ2泊3日。寺社中心で、交通費と宿泊費を抑えたい。

ステップ1:
  操作: 交通手段を検索
  結果: 新幹線と夜行バスの候補を取得

ステップ2:
  操作: 京都駅周辺と四条周辺の宿泊候補を検索
  結果: 予算内の候補と料金を取得

ステップ3:
  操作: 寺社の開館時間と移動時間を確認
  結果: 清水寺、南禅寺、伏見稲荷大社などの条件を取得

最終:
  取得した条件を使って2泊3日の行程を作成

この記録があることで、Agentは同じ検索を無意味に繰り返しにくくなり、途中で得た情報を次の操作へ利用できます。また、失敗したときに「どのツール呼び出しからおかしくなったか」を調べやすくなります。

一方で、保存すべきなのは観測可能な実行情報です。モデルの非公開な内部推論を前提にせず、ツール呼び出し、ツール結果、状態変更、必要であれば短い判断要約など、システムとして監査・再現できる情報を残す方が実装上も安定します。

ツールはAgentの「できること」を決める

モデルがどれだけ高性能でも、外部へ作用する手段がなければできることは限られます。Agentにとってツールは、現実世界との接点です。

Agentが利用できる実行手段は製品やフレームワークによって異なりますが、代表例としては次のようなものがあります。

実行手段役割例
事前定義されたツール入出力が決まった処理を実行するWeb検索、API、DB検索、ファイル操作
コード実行環境その場で処理を組み立てるPythonによる集計・変換、シェルコマンドによる検証
ブラウザ・アプリ連携外部サービスから情報を取得したり操作したりするWebページ操作、メール、チケット管理
他のAgentへの委譲専門化した処理を別のAgentへ任せる調査、レビュー、実装などの役割分担

このほか、製品によっては「Skills」のように、特定の作業手順や追加機能を必要に応じて読み込む仕組みもあります。ただし、SkillsはAgent全般に共通する標準的なツール分類ではないため、個別製品の機能として捉える方が適切です。

ツールは多ければよいわけではありません。数が増えるほど、モデルが適切なツールを選ぶ難易度も上がります。

ツール設計では、少なくとも次の点を意識します。

  • 役割を小さく明確にする
  • ツール名と説明を曖昧にしない
  • 引数の型や制約を明示する
  • 成功時と失敗時の返り値を構造化する
  • 破壊的な操作には確認や権限制御を入れる

これは従来のAPI設計と似ています。Agent向けだから特別な設計にするというより、モデルが誤解しにくいAPIを作ることが重要です。

OpenAI Agents SDKでは、Agent、ツール、ハンドオフ、ガードレール、トレーシングなどの仕組みが提供されており、ツール呼び出しやAgent間の委譲をランタイム側で扱えます。

https://openai.github.io/openai-agents-python/ja/

openai.github.io

LLMは「何をするか」を決める部分

Agentの中心にあるLLMは、ユーザーの意図を解釈し、現在の情報から次の操作を選びます。

ただし、Agentの性能をモデル単体のベンチマークだけで判断するのは不十分です。Agent用途では、一般的な文章生成能力に加えて、次の性質が重要になります。

  • 指示を安定して守れるか
  • 適切なタイミングでツールを呼べるか
  • 引数を正しい形式で生成できるか
  • ツール結果を受けて方針を修正できるか
  • 長いタスクでも目的を見失いにくいか

モデル側のツール利用能力が高くなっても、外側のオーケストレーションが不要になるとは限りません。実際のサービスでは、権限、タイムアウト、再試行、監査、予算制限、人間による承認など、モデルの外で管理しなければならない要素が多数あります。

「モデルが賢くなればAgentの周辺コードは消える」と考えるより、モデルに任せる判断と、システム側で固定する制約の境界が変わっていくと考えた方が現実的です。

コンテキストは単なる長文入力ではない

コンテキストというと、チャット履歴を長く入れることを想像しがちです。しかしAgentでは、コンテキストは「その瞬間の判断に必要な情報をどう組み立てるか」という情報設計そのものです。

典型的には、次のような情報が含まれます。

情報役割
システム指示Agentの役割、禁止事項、出力形式を定義する
ツール定義利用可能な操作と引数を伝える
ユーザー情報好み、権限、過去の設定などを必要に応じて渡す
外部知識検索結果、RAGで取得した文書、データベースの内容を渡す
実行状態これまでのツール呼び出しや結果を保持する
現在の入力今回処理すべき依頼を渡す

コンテキストは多ければよいわけではありません。無関係な情報まで大量に渡せば、コストや遅延が増え、重要な情報が埋もれる可能性があります。

そのため、Agentでは「全部入れる」よりも、必要なものを取得し、古い情報を更新し、長い履歴を圧縮しながら、判断に必要な情報を維持するコンテキストエンジニアリング（Context Engineering）が重要になります。

観測できる範囲と、行動できる範囲

Agentをもう一段抽象化すると、「何を観測できるか」と「何を実行できるか」という2つの境界で考えられます。

観測できる範囲には、ユーザー入力、Webページ、ファイル、データベース、アプリ連携から得られる情報などが含まれます。たとえば企業分析Agentでも、公開Webしか読めない場合と、社内CRMや契約済みデータベースまで参照できる場合では、判断材料が大きく異なります。

行動できる範囲には、検索、ファイル編集、コード実行、メール送信、チケット作成、決済などがあります。検索しかできないAgentと、承認付きで業務システムを更新できるAgentでは、同じモデルを使っていても実用上の能力は別物です。

この視点に立つと、Agentを強化する方法は「より強いモデルへ交換する」だけではありません。必要な情報源へ安全に接続し、適切なツールを追加することでも能力を広げられます。

ただし、行動範囲を広げるほど事故時の影響も大きくなります。能力拡張と権限制御はセットで考える必要があります。

Harness：モデルを実用システムとして動かす周辺層

Agent開発では、モデル呼び出しそのものより、その周辺処理の方が大きくなることがあります。この周辺の実行基盤を説明する言葉として、Harnessという表現が使われることがあります。

ここでいうHarnessは特定の標準仕様ではなく、LLMを安定して動かすための周辺レイヤーをまとめた呼び方です。主に次のような処理を担当します。

コンテキスト管理

必要な履歴だけを残す、長い情報を要約する、RAGで関連資料を検索する、古い状態を更新するといった処理です。コンテキストウィンドウが大きくなっても、不要な情報を無制限に詰め込む設計が適切になるわけではありません。

ツール実行とオーケストレーション

ツールの登録、呼び出し、並列実行、タイムアウト、再試行、エラー処理などを管理します。モデルが「このツールを使う」と決めても、その処理を安全に実行するのはランタイム側の責任です。

制約と検証

入力値の検証、権限確認、出力形式のチェック、危険な操作の承認などを行います。モデルの出力をそのまま外部システムへ通さないための境界です。

可観測性

ツール呼び出し、応答時間、トークン使用量、エラー、再試行、最終結果などを記録します。Agentは同じ入力でも常に同じ経路を通るとは限らないため、通常のアプリケーション以上に実行トレースが重要です。

モデルが高性能になるほど、この周辺層が不要になるとは限りません。むしろ自律的に行動できる範囲が広がるほど、権限、監査、失敗時の復旧といったシステム側の責任も大きくなります。

プロンプトエンジニアリングから先をどう考えるか

Agent開発では、問題に応じて複数の工程を使い分けます。便宜上、次のように整理すると、自分がどこを改善すべきか判断しやすくなります。

観点主な課題改善するもの
プロンプトエンジニアリング指示の解釈が安定しない指示、例、出力形式
コンテキストエンジニアリング必要な情報が足りない、または多すぎる検索、メモリ、履歴、情報の圧縮
Harness Engineering実行が不安定、監査できないツール実行、再試行、権限、実行トレース
ループ設計一回の応答では完了できない反復条件、終了条件、フィードバック
マルチエージェント設計一つのAgentでは役割が広すぎる委譲、専門化、協調方法

これは業界で合意された「5段階の進化ロードマップ」ではありません。複雑なAgentを設計するときに、問題の場所を切り分けるための分類として捉えるのが適切です。

たとえば、最新情報を間違えるのであればモデルを変える前に検索手段やコンテキストを見直す余地があります。ツールが誤動作するならプロンプトではなくスキーマや検証処理を改善すべきかもしれません。単純な処理にマルチエージェント構成を導入しているなら、そもそも複雑にしすぎている可能性があります。

ワークフローと自律型Agentは分けて考える

Agentという言葉は広く使われるため、決められた手順をLLMで実行するものまでAgentと呼ばれることがあります。実装を考えるときは、ワークフロー（Workflow）と自律型Agentを分けると設計しやすくなります。

Anthropicは、ワークフローを「LLMとツールが事前定義されたコードパスに従うシステム」、Agentを「LLMが自身のプロセスやツール利用を動的に決めるシステム」と整理しています。また、成功している実装では、複雑なフレームワークより単純で組み合わせ可能なパターンが有効だったと説明しています。

Building Effective AI Agents

Discover how Anthropic approaches the development of reliable AI agents. Learn about our research on agent capabilities, safety considerations, and technical framework for building trustworthy AI.

https://www.anthropic.com/engineering/building-effective-agents

www.anthropic.com

ワークフローが向くケース

処理順が明確で、監査可能性や再現性が重要な仕事です。

たとえば請求書処理なら、「入力検証 → 金額確認 → 承認 → 登録 → 通知」のように、決められた経路を通す方が安全です。途中の分類や文章生成にLLMを使っても、全体の流れはアプリケーション側で制御できます。

自律型Agentが向くケース

必要な手順を事前に列挙しにくく、状況によって調査方法やツール利用が変わる仕事です。

コードベース全体を調べて未知の不具合を修正する、複数の一次情報を調べながら調査レポートを作る、といった仕事では、途中結果に応じて次の行動を変えられる方が有利です。

実務では混在する

現実のシステムでは、どちらか一方だけにする必要はありません。

たとえば「候補の調査」はAgentに任せても、「本番DBを書き換える」「メールを一斉送信する」「課金を確定する」といった重要操作は決められたワークフローと人間の承認を通す設計にできます。

自由度が必要な部分だけを自律化する方が、全体をAgentへ任せるより扱いやすい場合は多くあります。

Agent設計では最初から複雑にしない

Agentを作るときに最も避けたいのは、必要性を確認する前から自律ループやマルチエージェント構成を採用することです。

まずは次の順番で考えると、過剰設計を避けやすくなります。

  1. 一回のモデル呼び出しで十分か確認する
  2. 必要なら検索やファイル参照などのツールを追加する
  3. 手順が決まっているならワークフローにする
  4. 途中結果によって次の手順を変える必要がある場合にAgentループを導入する
  5. 役割分離の効果が明確な場合だけマルチエージェントを検討する

Agentは自由度が高い一方で、呼び出し回数、遅延、コスト、失敗パターンも増えます。「高度そうだからAgentにする」のではなく、決め打ちの処理では扱えない不確実性があるかを基準にすると判断しやすくなります。

可観測性は後付けしない

通常のソフトウェアでは、入力に対して通るコードパスをかなり限定できます。Agentでは、モデルが選ぶツールや呼び出し順が変化するため、問題が起きたときに実行経路を追えなければ原因を特定しにくくなります。

最低限、次の情報は追跡できるようにしておくと便利です。

  • どのモデルを利用したか
  • どのツールを、どの引数で呼んだか
  • ツールが成功したか、失敗したか
  • 何回ループしたか
  • どこで人間の確認が入ったか
  • 入出力トークン、処理時間、費用
  • 最終的にタスクが完了したか

さらに本番運用では、単純な成功率だけでなく、「同じツールを異常に繰り返していないか」「特定の処理だけ失敗率が高くないか」「高額なモデルへ必要以上にルーティングされていないか」といった傾向も確認します。

安全性はガードレールと権限設計で作る

外部システムを操作できるAgentでは、安全性をモデルの拒否能力だけに任せられません。

特に注意したいのが、プロンプトインジェクション（Prompt Injection）です。AgentがWebページや文書を読む場合、その外部データに「これまでの指示を無視して別の処理をしろ」といった命令が含まれている可能性があります。人間には単なる文章でも、モデルにとっては命令として解釈できてしまいます。

そのため、ガードレール（Guardrails）は複数の場所に置きます。

場所主な対策
入力前入力検証、危険な内容の検知、データの分類
ツール実行前スキーマ検証、権限確認、許可リスト、リスク判定
ツール実行後返り値の検証、機密情報の除去、異常値の確認
最終出力前個人を特定できる情報（PII）の確認、形式検証、重要事実の再確認

特に、送金、削除、公開、送信、本番環境の変更など、取り消しが難しい操作は、人間による確認を挟む設計が有効です。

Human-in-the-Loop（人間による確認・介入）は「Agentができないことを人へ丸投げする」仕組みではありません。Agent側で現在の状態、実行しようとしている操作、リスク、推奨する選択肢を整理し、人間が短時間で判断できる形にすることが重要です。

Agentを理解するときはモデル以外を見る

AI Agentを理解するとき、最初はモデルの賢さに注目しがちです。しかし実際にシステムとして動かすと、重要なのはモデル以外の部分にも広がります。

  • 何をコンテキストとして渡すか
  • どのツールを利用できるようにするか
  • ツール結果をどう次の判断へ戻すか
  • どこでループを終了させるか
  • 失敗時にどう復旧するか
  • どの操作を人間の承認対象にするか
  • 実行結果をどう追跡・評価するか

モデルはAgentの重要な構成要素ですが、それだけでAgentシステムが成立するわけではありません。

まずは「モデル・コンテキスト・ツール」の3要素から考え、必要に応じてループ、Harness、ガードレールを加える。この順番で見ると、新しいAgent製品やフレームワークが登場しても、何が変わったのかを比較しやすくなります。

Agent周辺の製品名やフレームワークは今後も変わっていくはずです。それでも、何を見せ、何をさせ、結果をどう次の判断へ戻すかという設計上の問いは残ります。Agentを学ぶときは、個別ツールの使い方だけでなく、この構造を押さえておくと応用しやすくなります。