はじめに
前回の記事では、AIエージェントを「目標を達成するために、自律的に計画・実行するシステム」として説明しました。しかし、AIエージェントは単に目標を与えれば動くわけではありません。目標達成に向けてどのような処理を行うのか、そしてその処理をどのような仕組みが支えているのかを理解する必要があります。
本記事では、まず AI エージェントが目標達成までにたどる処理の流れ（Agent Loop）を確認し、その処理を実現する実行基盤（Agent Runtime）と、それを構成するコンポーネント群（Agent Runtime Components）について見ていきます。
次の2つの観点から AI エージェントの内部構造を整理していきます。
- AIエージェントはどのような処理を行うのか（Agent Loop）
- その処理をどのコンポーネントが実現するのか（Agent Runtime Components）
Agent Loop
この図は、エージェントが目標達成までにたどる処理の流れ（Agent Loop）を表しています。AIエージェントは、このループを繰り返し実行しながら目標達成を目指します。
Goal（目標）を出発点として、Plan（計画）、Act（実行）、Observe（観察）、Evaluate（評価）を繰り返しながら目標達成を目指します。
評価の結果、目標を達成できていなければ Replan（再計画）を行い、再び Plan へ戻ります。一方、目標を達成した場合は Finish（完了）に到達します。
LLMだけではAIエージェントにならない
Agent Loop を見ると、AIエージェントは自律的に判断しながら動作しているように見えます。しかし、実際には LLM が単独でこのループ全体を実現しているわけではありません。実際には、この処理を安定して実現するための仕組みが必要になります。
まず理解しておきたいのは、LLMそのものとAIエージェントは同じものではないという点です。たとえば ChatGPT、Gemini、Claude のようなLLMは、
- 文章を書く
- 質問に答える
- 要約する
- コードを生成する
といった言語処理能力を持っています。また近年のモデルは、複雑な問題を段階的に解決するための推論能力も向上しています。しかし、LLMは本質的には入力されたプロンプトに対して応答を生成するモデルであり、それだけで長時間にわたるタスク管理や外部システムとの連携を継続的に行うようには設計されていません。
たしかに、近年のLLMは Plan（計画）を立てたり、Act（実行）のためにツールを呼び出したりすることができます。しかし、それらを長期間にわたって安定して実行するための状態管理や実行管理の仕組みまでは持っていません。
実際の業務システムでは、次のような機能が必要になります。
- ユーザーやタスクの状態を継続的に管理する
- 外部システムやツールと連携する
- 実行結果に応じて処理を継続する
- 長時間にわたるタスクを追跡する
- 人間による承認プロセスを組み込む
- 権限やセキュリティを管理する
こうした機能は、通常のLLMそのものではなく、その周辺に構築された実行基盤によって実現されます。そこで登場するのが Agent Runtime です。
Agent Runtimeとは何か
Agent Runtime とは、先ほど見た Agent Loop を安定して実現するための実行基盤です。
LLM を中心として、計画、記憶、ツール利用、実行管理などを担うコンポーネントによって構成されています。LLM は脳に近い存在ですが、Agent Runtime は身体や神経系を含めたシステム全体と考えると理解しやすいでしょう。
概念的には次のような構造になります。
先ほど見た Agent Loop が「AIエージェントは何をするのか」を表しているのに対し、Agent Runtime Components は「その処理を誰が実現するのか」を表しています。
以降では、これらの Agent Runtime Components が Agent Loop のどの部分を支えているのかを見ていきます。
Agent Runtime と Agent Core の関係
ここまで Agent Runtime を実行基盤として説明してきましたが、その内部にはさまざまなコンポーネントが存在します。その中でも、計画、記憶、ツール管理などを担う中核機能群を Agent Core と呼ぶことがあります。次の図は、Agent Runtime が AI エージェント全体の実行基盤として機能するイメージを表しています。
図: Agent Runtime は Agent Core、Executor、Guardrails などのコンポーネントを支える実行基盤であり、Security や Monitoring を通じて安全性と運用性を提供しながら、Executor を介して External Systems と連携する
人間に例えるなら、LLM は思考や推論を担う頭脳に相当します。Planner や Memory は、計画を立てたり過去の経験を思い出したりする認知機能の一部と考えることができます。Agent Runtime は、それらの機能を実際の行動につなげるための神経系や身体に近い存在です。さらに、安全に行動するためのルール（Guardrails）、状態を監視する仕組み（Monitoring）、そして外部の世界とやり取りするための実行機能（Executor）も含んでいます。
また、実際の業務では AI エージェントは単独で完結することはほとんどありません。メール、カレンダー、CRM、社内システム、データベースなどの External Systems と連携しながらタスクを実行します。Agent Runtime は、こうした外部システムとのやり取りを仲介し、エージェント全体を統制する役割も担っています。
このように考えると、AIエージェントの能力は単にLLMの性能だけで決まるわけではありません。どれだけ高性能なLLMを利用していても、記憶の管理、ツール連携、セキュリティ、監視、実行管理といった基盤が適切に設計されていなければ、実用的なエージェントとして安定して動作させることはできません。
そのため近年は、モデルそのものの性能だけでなく、それを支える Agent Runtime の設計にも大きな注目が集まっています。また、Planner、Memory、Tool Manager などの中核機能群をまとめて Agent Core と呼ぶこともあります。
なお、Agent Runtime と Agent Core という言葉は、しばしば似た意味で使われることがあります。厳密な業界標準の定義があるわけではありませんが、一般的には Agent Runtime をエージェントの実行基盤全体、Agent Core をその中核機能群として捉えることが多いです。
これはあくまで一例であり、実際にはベンダーやフレームワークによって用語の使われ方は異なります。たとえば Google Cloud や Microsoft のドキュメントでは、Agent Runtime や Agent Framework といった表現が使われることが多く、Agent Core という名称が前面に出てこない場合もあります。
本記事では、エージェント全体を支える実行基盤を Agent Runtime と呼び、その中で計画、記憶、ツール管理を担う中核機能群を Agent Core と呼ぶことにします。
Agent Runtimeを実現するサービスとフレームワーク
ここまで説明した Agent Runtime は概念的なアーキテクチャですが、実際には多くのクラウドベンダーやフレームワークが、この考え方に基づいたサービスやプラットフォームを提供しています。代表的な例としては、次のようなものがあります。
クラウドサービス:
- Google Cloud Gemini Enterprise Agent Platform
- Amazon Bedrock AgentCore
- Azure AI Agent Service
フレームワーク / SDK:
- LangGraph
- Google Agent Development Kit（ADK）
- OpenAI Agents SDK
- Microsoft Semantic Kernel
- AutoGen
クラウドサービスは、エージェントを実行するためのインフラや運用機能を含めて提供するサービスです。一方、フレームワークや SDK はエージェントを開発するための実装基盤ですが、それだけではエージェントは動作しません。実際にエージェントを実行するためには、コンピューティング環境や実行基盤が必要になります。
そのため、LangGraph や ADK で開発したエージェントを、Google Cloud Gemini Enterprise Agent Platform、Amazon Bedrock AgentCore、Azure AI Agent Service といったクラウドサービス上へデプロイして運用する、といった組み合わせもよく利用されます。
もちろん、自社のサーバーや Kubernetes 環境などのオンプレミス環境へデプロイすることも可能です。しかし近年は、運用負荷を削減するためにクラウドサービスを利用するケースが増えています。
これらは名称や実装方法こそ異なりますが、Agent Loop を安定して実現するための実行基盤を提供するという点では共通しています。なかでも近年は、クラウドベンダーが提供するマネージドサービスを利用するケースが増えています。たとえば Google Cloud の Gemini Enterprise Agent Platform（旧 Vertex AI Agent Engine）は、AIエージェントを構築・デプロイ・運用するためのマネージドサービスです。
マネージドサービスとは、通常であれば開発者やインフラ担当者が行うサーバー管理、スケーリング、監視、運用といった作業をクラウドベンダーが代わりに提供するサービスを指します。そのため開発者は、インフラや運用の詳細を意識することなく、エージェントのロジックや業務要件の実装に集中できます。また、セッション管理やツール連携、運用監視といった Agent Runtime に求められる機能も活用できます。
Google Cloud、AWS、Microsoft、OpenAI、LangChain などは、それぞれ異なる方法でこの考え方を実装しています。しかし、いずれの場合も目指しているのは、Agent Loop を安定して実現するための実行基盤を提供することです。
Planner: 「どのように目標を達成するか」を計画する
Planner は、ユーザーから与えられた Goal（目標）を実行可能なタスクへ分解し、目標達成までの実行計画を立案する役割を持ちます。たとえば、ユーザーが次のように依頼したとします。
来月、Google本社がある Mountain View への出張を計画してほしい。
この依頼は Goal（目標）ではありますが、実際に何をすればよいのかまでは具体化されていません。エージェントは、いきなり検索や予約を始めるのではなく、まず目標を達成するために必要な作業を整理します。これが Planner の役割です。Planner は Goal を具体的なタスクへ分解し、実行可能な計画（Task Plan）を作成します。
次の図は Agent Loop ではなく、Planner が生成した Task Plan の一例を表しています。
実際のエージェントでは、さらに予算、移動時間、会社の出張規定、参加者のスケジュールなども考慮しながら計画を作成します。また、計画は一度作ったら終わりではありません。たとえば希望する日程の航空券が見つからなかった場合、別の日程を提案したり、別の空港を検索したりと、実行結果に応じて計画を修正することもあります。
このように、Goal を具体的な作業へ分解し、状況に応じて計画を更新しながら進める能力が Planner の役割です。AIエージェントが単なる質問応答システムではなく、目標達成型システムと呼ばれる理由は、この計画立案能力にあります。
Memory: エージェントの記憶を管理する
エージェントは目標を達成するために、過去の情報や作業の進捗状況を記憶しておく必要があります。たとえば、出張の計画中に、ユーザーが次のような希望を伝えたとします。
できるだけ本社に近いホテルを優先してほしい。
できればJALを優先してほしい。
エージェントはこうしたユーザーの好みや条件を記憶し、航空券検索やホテル候補の比較に活用します。
また、タスクの進捗状況も覚えておく必要があります。
出張日程確認完了
航空券候補取得完了
ホテル候補比較中
もしエージェントがこれらを忘れてしまうと、毎回同じ質問を繰り返したり、既に完了した作業を再実行したりする可能性があります。
このように、ユーザーの好み、タスクの条件、過去の会話、作業の状態などを記憶し、必要なタイミングで参照する仕組みが Memory です。現時点では「エージェントの記憶を管理する仕組み」と理解しておけば十分です。詳細な記憶管理の課題については後続の記事で扱います。
Memory は特定の処理だけで利用されるわけではありません。たとえば Planner が計画を立てる際には、ユーザーの好みや過去の会話内容を参照します。また、実行中に得られた結果（Observe）やタスクの進捗状況も Memory に保存されます。さらに、Evaluate の段階では、保存されている条件や過去の結果を参照しながら評価が行われます。このように Memory は Agent Loop 全体を通じて利用される共有ストレージのような役割を担っています。
Tool Manager: 利用可能なツールを管理する
Planner が Task Plan を作成したとしても、それだけでは処理は進みません。実際に計画を実行するためには、必要な情報を取得したり外部システムと連携したりする必要があります。LLMだけでは航空券の空席状況やホテルの空室状況、Google本社までの移動時間といった最新情報を知ることはできません。そこでエージェントは外部ツールと連携して必要な情報を取得します。出張計画の例では、
たとえば次のようなツールが利用されます。
- カレンダー: Google Calendar、Microsoft Outlook Calendar
- メール: Gmail、Microsoft Outlook
- Web検索: Google Search、Bing Search
- 地図・位置情報: Google Maps、Mapbox
- ドキュメント管理: Google Drive、Microsoft SharePoint、Confluence
次の図は、Tool Manager が利用可能なツールを管理しながら、Task Plan に応じて適切なツールを選択するイメージを表しています。
より一般的な業務システムでは、さらに次のようなツールが利用されることもあります。
- 社内データベース: BigQuery、Snowflake、PostgreSQL
- CRM: Salesforce、HubSpot、Microsoft Dynamics 365
- チャット/コラボレーション: Google Chat、Microsoft Teams、Slack
- ソースコード管理: GitHub、GitLab、Bitbucket
- ITサービス管理（ITSM）: Jira Service Management、ServiceNow
ここで重要なのは、エージェントが利用可能なツールを無作為に呼び出しているわけではないという点です。たとえば、
- 出張可能な日程を確認する
- 航空券を検索する
- ホテルを検索する
- 本社までの移動時間を調査する
といったタスクごとに、どのツールを利用するべきかを判断する必要があります。この役割を担うのが Tool Manager です。Tool Manager は利用可能なツールを管理し、Planner が作成した Task Plan に応じて適切なツールを選択できるよう支援します。
Executor: 計画を実際の行動として実行する
Planner が Task Plan を作成し、Tool Manager が利用するツールを決定したとしても、それだけでは処理は進みません。実際にツールを呼び出し、外部システムと連携しながら計画を実行する仕組みが必要になります。この役割を担うのが Executor です。
出張計画の例でExecutor は、この Task Plan を実際の行動として実行します。たとえば、
- Calendar で利用可能な日程を確認する
- Search で航空券候補を検索する
- Search でホテル候補を検索する
- Maps で移動時間を確認する
といった処理を順番に実行し、その結果を収集します。
エージェント全体の流れで見ると、Executor は Agent Loop における Act（実行）を担当しています。
ここで重要なのは、Executor は単にツールを呼び出すだけではないという点です。たとえば航空券検索の結果、
- 希望日に空席がない
- 予算を超えている
- JAL便が見つからない
といった状況が発生することがあります。その場合、Executor は結果を Planner に返し、エージェントは再び計画を見直します。つまり Executor は Task Plan を機械的に実行するだけではなく、実行結果を Agent Loop へフィードバックする役割も担っています。
このように Executor は、Planner が作成した計画を実際の行動へ変換し、外部システムとの連携を実現するコンポーネントです。AIエージェントのループにおける Act（実行）を担うコンポーネントと考えると理解しやすいでしょう。
Guardrails: エージェントの行動を制御する
Guardrails は、英語の Guard（守る）と Rail（レール）から生まれた言葉です。道路脇のガードレールが車の逸脱を防ぐように、AIエージェントの文脈では、エージェントが期待された範囲から脱線しないようにするための安全策と考えると理解しやすいでしょう。
Guardrails は Agent Loop の中でも、計画（Plan）と実行（Act）の両方に対して制約を与えます。AIエージェントは便利ですが、自由に行動できすぎると危険でもあります。目標達成を優先するあまり、ユーザーが意図していない行動を取る可能性があります。
たとえば、ユーザーから与えられている情報が次の内容だけだった場合、
来月、Google本社がある Mountain View への出張を計画してほしい。
できればJALを優先してほしい。
できるだけGoogle本社に近いホテルを優先してほしい。
エージェントは航空券とホテルの予約について、繁忙期だった場合次のような判断を行う可能性があります。
JAL エコノミークラス → 満席
JAL ビジネスクラス → 満席JAL ファーストクラス → 空席あり → 予約
本社から徒歩5分のホテル → 満室
本社から徒歩3分のホテル → 空室あり
└ Executive Suite のみ → 予約
このような問題は、エージェントが誤作動したのではなく、与えられた目標に対して合理的に最適化した結果として発生します。エージェントから見ると予算や座席クラス、ホテルのグレードは指定されていません。
- JALを利用した
- 本社に近いホテルを確保した
- 出張を実現できた
という条件を満たしているため、目標は達成されています。
一方、ユーザーから見ると、
- ファーストクラスは高すぎる
- 高い Executive Suite は不要
- そのような高額な予約は依頼していない
という結果になります。そこで必要になるのが Guardrails です。たとえば、
- 航空券はエコノミークラスのみ
- ホテルは1泊3万円以内
- 予約前に必ず承認を取得する
- 利用可能なツールを制限する
- 社外へのデータ送信を禁止する
といった制約を設定します。
Human Approval: 人間による最終確認
Human Approval は Agent Loop の中でも、最終的な実行や意思決定の前に人間の判断を介在させる仕組みです。
AIエージェントは候補の作成や提案までは自律的に行うことができます。しかし、特に重要な操作については、人間の承認を求めることが望ましいです。たとえば、金銭的な影響や法的な責任を伴う重要な操作については、人間が最終判断を行うことが一般的です。
そのため Human Approval は、安全性を高めるためだけでなく、最終的な意思決定の責任を人間が持つためにも重要な仕組みです。たとえば、
- 購入処理
- 送金処理
- メール送信
- 契約締結
- 顧客情報更新
などです。
出張の例で、繁忙期のため希望条件を満たす選択肢が見つからなかった場合、エージェントは次のような確認を行うでしょう。
JAL便とホテルの候補を見つけました。
この内容で航空券とホテルを予約してもよろしいですか？
あるいは、Guardrails によって予算上限が設定されている場合、
ご希望条件を満たす航空券が見つかりませんでした。
ファーストクラスへの変更を許可しますか？
といった確認を行うこともあります。
また、Human Approval は Guardrails と組み合わせて利用されることが少なくありません。たとえば、
- 3万円を超えるホテルを予約する場合
- エコノミークラス以外を予約する場合
- 顧客情報を更新する場合
といった条件を Guardrails で定義し、その条件に該当した場合のみ Human Approval を要求することもあります。
全体の流れを見てみる
ここまで紹介したコンポーネントは、それぞれ独立して動作するわけではありません。エージェントは Agent Loop を回しながら、Planner、Memory、Tool Manager、Executor、Guardrails、Human Approval といった Agent Runtime Components を連携させて目標達成を目指します。出張の例であれば、
本社への出張を計画する
↓
出張日程を確認する
↓
航空券とホテルを検索する
↓
条件に合う候補か評価する
↓
必要なら再計画する
という処理を繰り返します。概念的には次の図のような関係になります。
楕円が Agent Loop の処理ステップ、四角形が Agent Runtime Component を表しています。ここで注意したいのは、この図には、「エージェントがどのような処理を行うのか（Agent Loop）」と、「その処理をどのコンポーネントが担うのか（Agent Runtime Components）」の2つの概念が含まれている点です。まず、
Goal → Plan → Act → Observe → Evaluate → Replan または Finish
は処理の流れ（Agent Loop）を表しています。一方で、
Planner、Memory、Tool Manager、Executor、Guardrails、Human Approval
は、その処理を実現するためのコンポーネント（Agent Runtime Components）です。
ユーザーから与えられた Goal（目標）に対して、Planner が実行計画を立案する際、過去の会話やユーザーの好みは Memory から参照されます。Planner は Tool Manager と連携しながら利用可能なツールを選択し、Executor が実際の処理を実行します。Executor は External Systems（例：Google Calendar や Google Maps、社内システムなど）と連携しながら行動を実現します。
実行結果は Observe と Evaluate を通じて評価され、条件を満たしていなければ Replan によって計画を見直します。また、Guardrails は Planner と Executor の両方に制約を与え、エージェントが安全な範囲で行動できるように制御します。さらに、重要な操作や Guardrails に抵触する可能性のある操作については Human Approval を求めることがあります。人間が承認した場合、エージェントは Finish に到達することもあれば、Act に戻って処理を継続することもあります。
このように Agent Runtime Components はそれぞれ異なる役割を持ちながら連携し、Agent Loop を通じて継続的に目標達成を目指しています。
まとめ
本記事では、AIエージェントの処理の流れを表す Agent Loop と、それを実現する Agent Runtime Components について見てきました。Agent Loop は、
Goal → Plan → Act → Observe → Evaluate → Replan または Finish
という形で、エージェントが目標達成までにたどる処理の流れを表します。一方、Agent Runtime Components は、その処理を実際に実現するためのコンポーネント群です。AIエージェントは単なるLLMではなく、
- Planner
- Memory
- Tool Manager
- Executor
- Guardrails
- Human Approval
といったコンポーネントが連携することで、自律的なタスク実行を実現しています。たとえば、本社訪問のための出張計画という Goal が与えられた場合、
- Planner が Task Plan を作成する
- Memory がユーザーの好みやタスクの状態を保持する
- Tool Manager が適切なツールを選択する
- Executor が実際の検索や予約を実行する
- Guardrails が安全性や制約条件を適用する
- Human Approval が必要に応じて人間の意思決定を介在させる
といった形で、それぞれの役割を担います。また、これらのコンポーネントのうち、計画、記憶、ツール管理などの中核機能群を Agent Core と呼ぶこともあります。
しかし、実際のエージェント開発では、
- 長期的な記憶をどのように管理するのか
- 限られたコンテキストウィンドウをどのように活用するのか
- 多数のツールからどのように最適なものを選択するのか
- 複数のエージェントをどのように協調させるのか
といった新たな課題が現れます。AIエージェントの本当の難しさは、LLMそのものよりも、こうした基盤技術をどのように設計し統合するかにあると言えるでしょう。次回は 「AIエージェントを支える基盤技術」 として、
- Long-term Memory
- Context Compression
- State Management
- Dynamic Tool Selection
- Multi-Agent Isolation
など、Agent Core が解決しようとしている技術課題について見ていきます。