エージェントは「ループ」である ― まず解剖する
単発のLLM呼び出しは「入力 → 出力」で終わります。エージェントが違うのは、目標を受け取り、完了条件を満たすまで判断と行動を反復する「ループ」である点です。ループは次の4ステップを回ります。
- 計画(PLAN) ― 目標から手順を立てる。ここが起点になる。
- 実行(ACT) ― 行動はすべてツール経由。能力と危険性はどのツールを渡すかで決まる。
- 観測(OBSERVE) ― 実行結果を読み、何が分かったかを状態に記録する。
- 判断(JUDGE) ― 続行・修正・完了を判断する。同じ入力でも経路は毎回変わり得る。
このループ全体を「状態・メモリ(何をやったか、何が分かったか)」が支えます。つまりエージェントの構成要素は、LLM(判断)・ツール群(行動)・ループ制御(反復と終了)・状態/メモリ(文脈の保持)の4つです。この構造から、単発呼び出しにはなかった設計課題が生まれます。ループが終わらない(完了条件が曖昧だと反復が止まらない)、途中の小さな誤りが後段に増幅する、同じ入力でも毎回経路が違いテストや再現が難しい ― の3つです。
エージェント設計とは、この非決定的なループに「枠をはめる」作業です。賢くする工夫より先に、終了条件・権限・人の関与点という枠を決める。ここが単発のプロンプト設計と根本的に違うところです。
構成は5つの型から「最も左」を選ぶ
「エージェントにする」と決めても、構成には段階があります。下の型で足りるなら、下の型が正解です。非決定性の小さい順に5つ並べ、要件を満たす最も左の型を採るのが原則です。
| 型 | 構造 | 非決定性 | 向くタスク |
|---|---|---|---|
| ➀ 固定ワークフロー | 呼び出しを決めた順に並べる(分岐は人が設計) | 最小 | 手順が固定の変換・下書き・チェック |
| ➁ ルーター | LLMが入力を分類し、固定の処理に振り分ける | 小 | 問い合わせ振り分け、書類の仕分け |
| ➂ 単一エージェント | 1つのループ＋厳選したツール群 | 中 | 手順が動的で試行錯誤の要るタスク |
| ➃ 計画・実行分離 | 計画を先に立てて人が確認し、実行は計画に従う | 中(計画時に固定) | 長いタスクで途中の脱線を防ぎたい場合 |
| ➄ マルチエージェント | 複数のループが協調(親子・並列) | 大 | コンテキスト分離・権限分離が必要な場合のみ |
注意したいのは「エージェントを作りたいから➂以降」という発想です。これは事故の元になります。前段の適用判断で「ワークフローで足りる」となったタスクは、素直に➀➁で実装するのが健全です。➄マルチエージェントを選ぶ正当な理由は、後述する2つしかありません。
自律性は段階で設計する ― L0からL3の階段
「自律性を最後に足す」を設計に落とすと、レベルの階段になります。最初からL2/L3で設計しないことがポイントです。
| Lv | 名称 | エージェントの権限 | 人の役割 | 適用 |
|---|---|---|---|---|
| L0 | 提案のみ | 読み取り＋計画の提示まで | 全実行 | 最初は必ずここから |
| L1 | 承認付き実行 | 実行前に毎回人が承認 | 各実行の承認 | 書き込みを伴う最初の形 |
| L2 | 限定自律 | 定義済みの低リスク操作は自動、他は承認 | 例外・高リスクの承認 | 実績を積んだ後 |
| L3 | 監視付き自律 | 範囲内は自動実行、事後監査 | 監視・サンプル監査 | 十分な実績＋強いガードレール前提 |
設計上の勘所は3つあります。第一に、L0(提案のみ)から始め、実績データを根拠に一段ずつ上げること。第二に、レベルは「操作ごと」に設定すること ― 同じエージェントでも「検索はL3、メール送信はL1」が普通です。第三に、昇格は業務オーナーの決裁で行い、なし崩しに上げないこと。「全自動」を謳うノーコード/SaaS製品を使う場合でも、この階段は変わりません。承認フローや実行前確認が効くL0/L1相当から始めます。
昇格を「なんとなく安定してきたから」で判断しないために、基準を数字で決めておきます。たとえばL1→L2なら「直近の承認率95%以上・重大な差し戻しゼロ・その状態が2〜4週間継続・評価セットの通過」といった具合です。数字はタスクのリスクに応じて業務オーナーが決め、設計キャンバスに明記します。これらはすべて架空のモデルケースとしての目安で、実際の閾値は自社のリスク許容度で調整します。
ツール設計＝権限設計 ― 手足は最小に切る
エージェントの能力と危険性は、与えるツールで決まります。ツールを1つ増やすことは、権限を1つ増やすこと。だからツール設計は、そのまま権限設計になります。壊れにくくするための4原則を挙げます。
- 最小権限。タスクに必要な操作だけを持つ専用ツールを作る。「社内API全部入り」の汎用ツール1個より、目的特化のツール数個。
- 入出力の検証。ツール側で引数を検証する(金額上限・対象範囲・形式)。LLMが正しい引数を渡してくると信頼しない、「疑い深いAPI」として実装する。
- 冪等性/取り消し可能性。同じ操作が二重実行されても結果が壊れないようにする。二重送信・二重起票はループの定番事故。取り消せる設計もあわせて用意する。
- 監査可能性。読み取り系と書き込み系を別ツールに分け、書き込み系には自律性レベルと承認を個別に設定し、いつ・何を・なぜ実行したかをログに残す。
たとえば経費データを扱うツールを考えます。db_query(任意SQLを実行)のように「経理DB全テーブル読み書き・引数検証なし・例外はそのままループに漏れる」設計は、悪いツールの典型です。良いツールは、get_expense(ID)のように名前から役割が分かり、権限が対象テーブルの読み取りと下書きテーブルへの書き込みだけに絞られ、IDの実在や金額上限をツール側で強制し、失敗理由を構造化して返すものです(いずれも架空の例)。この差が、そのまま事故の起きやすさの差になります。
MCPの利点と代償、単一 vs マルチの使い分け
社内ツールをエージェントに公開する手段として、2026年7月時点ではMCP(Model Context Protocol)が事実上の標準になっています。利点は再利用性です。社内ツールをMCPサーバとして一度公開すれば、複数のエージェントや製品から使い回せ、対応する製品も広がっています。ただし公開はタダではありません。公開＝攻撃面の増加であり、呼び出し元が増えるほどリスクも増えます。認証・最小権限・監査ログをサーバ側に必ず実装する ― これは供給網リスクの観点でも譲れません。認証も監査ログもないMCPサーバは立てない、が原則です。
構成の話に戻ると、「調査係・執筆係・レビュー係に分ければ賢くなりそう」というマルチエージェント志向にも注意が必要です。分けると複雑さは指数的に増えます。エージェント間の伝言で情報が劣化し、デバッグ難度は経路の組み合わせ分だけ上がり、エージェント間の信頼関係が新しい攻撃面になります。単一エージェント＋良いツール群で成立するなら、それが正解(大半のケース)です。マルチに分ける正当な理由は2つだけ ― ①コンテキストの分離(長大な調査を並列に分け、結果だけ親に返す)、②権限の分離(危険な操作を持つ部分を隔離し、狭い接点だけで繋ぐ)です。
失敗の形も型どおりに起きます(以下はいずれも架空のモデルケースで考えます)。たとえば「経費集計」を頼んだエージェントに、社内APIゲートウェイをまるごと1本のツールとして渡してしまうと、途中で人事APIを叩いて他部門の給与情報を取得しかねません ― これは最小権限のツールに切り直せば構造的に起き得なくなります。あるいは5役割に分けた問い合わせ回答エージェントが原因不明の品質劣化を起こす、という筋書きも考えられます。受付係の要約で顧客の否定条件(「〜以外で」)が落ちれば、後段全員が誤った前提で動いてしまう。単一構成に組み直せば精度が改善し、デバッグ時間も大きく減る、という想定です。「行儀の良さ」をプロンプトで頼むのではなく、できないことを構造で保証するのが設計の要諦です。
人の関与とループ制御を「構造」として組み込む
自律性レベルを実装に落とすのがHITL(Human-in-the-Loop)です。操作の不可逆性・対外性・金額で使い分けます。代表的なのは、実行計画や個別操作を提示して承認後に実行する「事前承認」(L1・不可逆/対外/金額閾値超の操作)、人が内容を修正してから実行させる「編集付き承認」(対外送信の文面など)、実行中でも人が停止・介入できる「割り込み」(長時間タスクのkill switch)、曖昧・低確信のときエージェント側から人に聞く「確認質問」、そして実行後にサンプルや全件をレビューする「事後監査」(L2/L3・昇格判断のデータ源)です。自律性レベルとHITLパターンは、操作ごとに対で決めます。
ここで見落とされがちなのが承認の形骸化です。「全操作を承認制にしたが、人はEnterを連打しているだけ」という状態は、安心の錯覚を生むぶん承認がないより危険です。対策は3つ ― ①承認に「何を・なぜ・どのデータに基づき実行するか」の根拠を添えさせる、②人が判断できる件数に絞る(件数が処理能力を超えた瞬間、承認は儀式に変わる)、③差し戻し率を測って機能しているか継続的に確認する、です。
非決定的なループには、「上限のセット」を必ず付けます。プロンプトの「気をつけて」は上限ではありません。初期値の例として、最大ステップ数(10〜30程度)、タイムアウト(対話型は数分/バッチ型はタスクに応じて)、1タスクあたりのコスト上限、同一操作の反復回数(同じツール＋同じ引数は2〜3回まで)、再試行(一時エラーのみ2回まで・待ち時間を挟む)を決めます。あわせて、上限到達・低確信・想定外エラーのときに「経過＋困っている点」を構造化して人に渡すエスカレーションの出口を実装します。黙って止まる/黙って続けるのは、どちらも不可です。
メモリの扱い ― 精度と汚染は表裏
最後にメモリです。何を覚えさせ、何を捨て、何を都度取りに行くか ― 記憶の設計がタスク成功率とリスクの両方を左右します。タスク内状態はループの途中経過を、長いタスクではコンテキストが溢れるため要約・圧縮しながら進めます。タスク間メモリは精度を上げる一方で、悪意ある指示や誤情報が残り続ける「汚染」の経路にもなります。書き込みには検証を挟み、定期的に監査・クリアできる設計にします。そして組織知識(手順・規程)はメモリに溜め込まず、RAGから都度取得する方が、鮮度と権限管理の面で健全です。
ここまで挙げた項目 ― 完了条件、構成の型、ツール一覧と権限、自律性レベルとHITL、ループ制御の上限、エスカレーション、メモリ、昇格計画 ― は、1タスクにつき1枚の設計キャンバスに落としてから作り始めるのが定石です。設計と防御は不可分なので、本番接続の前にはセキュリティの検討(次回)を必ず通してください。