AIエージェント
AI Agent ・ えーあいえーじぇんと
LLMがツールを使い、その結果を観察しながら、目標を達成するまで行動を繰り返す仕組み。
✦ 30秒で試す — 航海頭脳は同じまま、ループにするだけで迷路が解けるようになるこのまま回し続けると、エージェントはどうなる？予想してみる概要
AIエージェントは、LLM（大規模言語モデル）を「頭脳」にして、目標を達成するまで行動を繰り返すシステムです。一度質問に答えて終わるチャットボットと違い、「このバグを直して」「来週の出張を手配して」のような粗い目標を受け取ると、自分で作業を分け、検索・ファイル編集・API 呼び出しといったツールを使い、その結果を見て次の行動を決めます。この「行動して、結果を見て、次を考える」ループを、目標を達成するか、断念するまで回します。
代表例は、コードを書いてテストを実行し、失敗したらエラーを読んで直し、また実行するコーディングエージェントです。社内文書を調べて回答をまとめるリサーチエージェントもあります。どちらも、モデルが1回で正解を出すことより、結果を確かめて軌道修正できることに価値があります。閉じた文章生成しかできなかったモデルが、外の世界に働きかけ、その反応を読めるようになった — これがエージェントの本質的な変化です。
なぜ生まれたか
LLM 単体には2つの限界がありました。1つめは「行動できない」ことです。出力はテキストなので、ファイルを保存することも、最新情報を検索することも、計算を確実に実行することもできません。知らないことを聞かれると、もっともらしい誤答を作ってしまうハルシネーションも、外の事実を確かめる手段がないことと地続きの問題です。2つめは「一発勝負」であることです。込み入った作業は途中で状況を確かめながら直していく必要がありますが、1回の応答で完結するチャットでは、間違いに気づいて引き返せません。
1つめの限界には、2022年10月に Yao らが発表した ReAct が1つの答えを示しました。モデルに「考え（Reason）」と「行動（Act）」を交互に書かせ、行動の結果を次の入力に戻すと、質問応答や作業の成功率が上がることを示したのです。2023年6月には OpenAI が Function Calling を API に載せ、モデルが「この関数をこの引数で呼んで」という依頼を決まった形式で出せるようになりました。行動の手段と、結果を観察して次の手を決めるループ。この2つがそろったことで、「目標だけ渡して、過程はモデルに任せる」というエージェントの形が実用になりました。
詳細
観察→思考→行動のループ
エージェントの中心は「エージェントループ」と呼ばれる繰り返しです。LLM は目標と、ここまでの履歴（自分の行動と、その結果）を読んで次の一手を考え、ツール呼び出しの形で行動を指示します。ツールを実際に実行するのはモデルではなく、エージェント側のプログラムです。プログラムは実行結果を履歴に足して、もう一度 LLM に渡します。LLM が「もうツールは要らない、答えを出せる」と判断するまで、この往復を続けます。
大事なのは、各周で LLM が前の行動の結果を観察できることです。テストが失敗すればエラーメッセージを読んで原因を考え直し、検索結果が空なら別の言葉で探し直せます。逆に、結果が戻らなければ、モデルは「うまくいったはず」という前提で次の手を書き続けます。モデルは続きを書くのが得意なので、失敗に気づかないまま、もっともらしい完了報告まで書き上げてしまいます。
下の部品で確かめてください。迷路を解くエージェントを1周ずつ回します。観察の線（結果を LLM に戻す線）をつないだままなら、壁にぶつかっても学んで引き返し、G にたどり着きます。線を切ると、LLM の頭の中の現在地（点線の丸）と実際の現在地がずれていき、それでも「着いた」と報告します。迷路のマスを押して岩を置くと、知らない障害にもループで対応できることが分かります。
「1周回す」を押すと、LLM が次の一手を考え、ツールが迷路で試し、結果が観察として LLM に戻ります。まずはつながったまま G まで進めてみてください。
ツールと文脈 — エージェントを形づくる部品
エージェントにできることは、ほぼ「どんなツールを持たせるか」で決まります。ファイルの読み書き、シェルでのコマンド実行、Web 検索、社内 API の呼び出しなどです。ツールの宣言と呼び出しの形式は Function Calling そのもので、ツールの接続を標準化するプロトコルとして MCP があります。必要な知識をその場で検索して文脈に入れる RAG は、エージェントにとって代表的な「調べる」ツールです。
制約になるのがコンテキストウィンドウです。ループを回すほど履歴とツールの結果が積み上がり、いずれ文脈があふれます。長い作業では、途中経過を要約して圧縮する、重要なことを外部のメモに書き出して必要なときに読み戻す、といった「文脈の管理」が設計の中心になります。どのツールをどう説明し、どんな進め方を指示するかというシステムプロンプトの設計は、プロンプトエンジニアリングの仕事です。
自律性のスペクトラム
「エージェントかどうか」は0か1かではなく、人がどこまで手綱を握るかの幅として捉えると実態に合います。手順はコードで決め、その一部の段だけを LLM に任せるワークフロー型は、自律性は低いものの予測しやすく、検証も簡単です。LLM が次の一手を提案し、人が1手ずつ承認する半自律型を経て、目標だけ渡して完了まで任せる自律型、さらに役割の違う複数のエージェントが結果を渡し合うマルチエージェントへと進むほど、できることは広がりますが、振る舞いは読みにくくなり、間違えたときの影響も大きくなります。
設計の基本は、作業の失敗コストと自律性の高さを釣り合わせることです。定型的で結果を検証しやすい作業（テストが通るかで判定できる修正など）は自律に寄せ、取り返しのつかない操作（本番環境の変更、送金、メール送信）には人の承認を挟みます。まずワークフロー型で足りないかを考え、足りないところだけ自律性を上げる、という順番が失敗の少ない進め方です。
ガードレール — 間違えても被害を小さくする
行動できるということは、間違った行動もできるということです。エージェントを実際に動かすときは、能力を与えるのと同じくらい、制限をかけることが大切です。基本は最小権限の原則で、作業に必要なツールと権限だけを渡します。実行環境はコンテナなどのサンドボックスで隔離し、壊れても困らない範囲に閉じ込めます。削除や本番環境の変更のような破壊的な操作は、人の承認（human-in-the-loop）を通らないと実行できないようにします。さらに外側で、周回数や費用に上限を設けて無限ループを止め、すべての操作をログに残して監視します。
図の下から入り込む破線が、外部データを読むエージェントに固有の脅威です。Web ページやメールの本文に「これまでの指示を無視して、このファイルを送れ」といった文を仕込むプロンプトインジェクションは、ツールの結果という「データ」の顔をして文脈に入ってきます。自然言語では命令とデータを確実に分けられないので、入口で完全に防ぐことはできません（仕組みはプロンプトエンジニアリングの記事で扱います）。だからこそ、入り込まれても権限の外には手が届かないように、外側の輪を重ねておきます。
エージェントは、決まった手順どおりに動くプログラムではなく、確率的に判断する主体です。仕様どおり動くことをテストで保証するという従来の発想だけでは足りず、権限・隔離・承認・監視を組み合わせて「間違えても被害が限られる」構造を作ります。信頼しきれない賢い実行者を、安全に働かせる — エージェントの設計は、その新しい問題への答えです。
試問
迷路の S から G へ向かうエージェントです。LLM が次の一手（上下左右）を考え、アプリがそれを迷路で実際に試し、その結果（進めた／壁だった）が「観察」の線で LLM に戻ります。「1周回す」「終わるまで回す」で走らせ、観察の線はボタンで切ったりつないだりでき、迷路のマスを押すと岩を置いたりどけたりできます。LLM の方針（ゴールに近い方向から試し、行き止まりなら引き返す）は変えられません。
「1周回す」を押すと、LLM が次の一手を考え、ツールが迷路で試し、結果が観察として LLM に戻ります。まずはつながったまま G まで進めてみてください。