In Silico

AIエージェント

AgentCoreとFoundryのセッション分離の違い：利用者ごとの隔離

2026/10/28 （更新: 2026/11/3）

🤖 AIを使用して執筆

  • セッション分離
  • AIエージェント
  • マルチテナント
  • AgentCore Runtime
  • Foundry hosted agents
  • microVM
  • Agent Framework
  • Microsoft Entra ID
  • 利用者ID
  • セッションID
  • 会話履歴
  • 同時セッション数
  • セッションプール
  • サンドボックス
  • x-ms-user-identity
  • runtimeSessionId
  • 実行ロール
  • MMDS
  • OAuth
  • 中継層
目次
背景・問い・要点
背景

AIエージェントを多数の利用者に使わせるアプリでは、エージェントが利用者の指示でファイルを書き、コードを実行し、外部サービスの認証情報を使う。従来の Web アプリやサーバーレスの基盤は、一つのコンテナを多数の利用者のリクエストが共有する形で作られた。この形でエージェントを動かすと、ある利用者のために書いたファイルや認証情報が、別の利用者の処理から見える危険がある1。

そこで、セッションごとに専用の VM を割り当てる基盤が出てきた。本稿のセッションは、エージェントのコードが動き、書いたファイルが残る実行環境の単位を指す。会話の履歴（メッセージとツール呼び出しの記録）は、セッションとは別の概念だ2。利用者ごとにセッションを一つずつ作ると、同時に処理できるセッションの数の上限に達する3。そのため複数の利用者を一つのセッションにまとめる組み方があり、そのとき基盤が何を利用者ごとに分け、アプリが何を分けるのかが問題になる。

本稿は、Microsoft の Foundry hosted agents と AWS の Amazon Bedrock AgentCore Runtime を比べる。どちらも作り手が分離の方針を一次資料に書き、どちらもセッションごとに専用の VM を割り当てる。どちらでも、利用者を認証してエージェントに要求を転送するのはアプリのバックエンドであり、本稿はこれを中継層（Microsoft の文書の middle tier）と呼ぶ。自前のコンテナ型サンドボックスなど、別の種類の基盤は比べない。

問い

利用者の多いアプリが利用者ごとの隔離を組むとき、AgentCore Runtime と Foundry hosted agents はセッションの分離で何が違い、どの条件でどちらを選べばよいのか。

要点

AgentCore と Foundry はともにセッションごとに VM を分け、違いは開発者が書くコードの範囲だ。利用者とセッションの結び付けと共有時の会話履歴の分離を、Foundry では Responses プロトコルならサービスが担い、AgentCore では開発者が書く。

セッションを共有して同時セッション数を抑えたいアプリには、Foundry のプールが候補になる。ファイルは、どちらのサービスでも開発者が利用者ごとに分ける。

モデル・例示

経費相談アプリの田中と佐藤を、同じ組み方で両サービスに載せる

※ この節の例は、説明のために作った架空のものです。

二つのサービスの違いは、アプリの開発者が書くコードの範囲にある。利用者とセッションを結び付けるコードと、共有したセッションで会話の履歴を利用者ごとに分けるコードを、Foundry ではサービスが持ち、AgentCore では開発者が書く。同じ組み方で両サービスを並べると、この二点だけが違って見える。経費相談アプリが、一つのエージェントを田中と佐藤に使わせるとする。利用者を認証し、発言をエージェントへ送るのは、アプリの中継層である。二つの組み方を、両サービスで同じように試す。

組み方 1：一人に一つのセッション

どちらのサービスでも、田中のセッションと佐藤のセッションは別の VM で動き、互いのファイルとメモリに届かない45。違うのは、利用者とセッションを結び付けるコードを、開発者が書くかどうかである。

  1. アプリの中継層Foundry1. 田中の発言を、田中の利用者IDを付けて送る
  2. Foundry2. 田中の利用者IDに、田中用のセッションを割り当てる
  3. アプリの中継層Foundry3. 佐藤の発言を、佐藤の利用者IDを付けて送る
  4. Foundry4. 佐藤の利用者IDに、佐藤用の別のセッションを割り当てる

Foundry では、アプリは発言に利用者IDを付けて送るだけでよい。利用者IDごとにセッションを分けるのは、Foundry のサービス自身である。利用者IDは、既定では Microsoft Entra ID のトークンから Foundry が判別し、自前で認証するアプリでは中継層がヘッダーで渡す6。

  1. アプリの中継層1. 田中用と佐藤用に、別々のセッションIDを作って記録する
  2. アプリの中継層AgentCore Runtime2. 田中の発言を、田中用のセッションIDで送る
  3. AgentCore Runtime3. そのセッションIDの microVM で処理する
  4. アプリの中継層AgentCore Runtime4. 佐藤の発言を、佐藤用のセッションIDで送る
  5. AgentCore Runtime5. 別のセッションIDなので、別の microVM で処理する

AgentCore では、開発者が、利用者ごとのセッションIDを作り、どの利用者にどのIDを使うかを記録し、毎回そのIDを付けて送るコードを書く。AgentCore のサービスは、渡されたIDごとに microVM を分けるだけである5。

組み方 2：二人で一つのセッションを共有する

同時に処理できるセッションの数には上限があるので、利用者を少数のセッションに相乗りさせる組み方がある3。田中と佐藤を同じセッション 1 に入れ、Foundry へは Responses プロトコルで送る。佐藤が「前に話した内容を踏まえて」と頼む。

  1. アプリの中継層Foundry1. 田中の発言を、田中の利用者IDを付けてセッション 1 へ送る
  2. Foundryセッション 1 の VM2. 発言を渡し、田中の会話として記録する
  3. アプリの中継層Foundry3. 佐藤の発言を、佐藤の利用者IDを付けてセッション 1 へ送る
  4. Foundryセッション 1 の VM4. 発言を渡す
  5. セッション 1 の VM5. エージェントが会話の履歴を求めると、Foundry は佐藤の会話だけを返す

Foundry は、同じセッションの中でも、会話の履歴を要求の利用者IDごとに分けて返す。佐藤が田中の会話の続きを指定しても、Foundry が拒否する3。

  1. アプリの中継層AgentCore Runtime1. 田中の発言を、セッション 1 のIDで送る
  2. AgentCore Runtimeセッション 1 の microVM2. 発言を渡す
  3. セッション 1 の microVM3. エージェントが、自分の持つ会話の履歴に田中の発言を足す
  4. アプリの中継層AgentCore Runtime4. 佐藤の発言を、同じセッション 1 のIDで送る
  5. AgentCore Runtimeセッション 1 の microVM5. 発言を渡す
  6. セッション 1 の microVM6. 履歴を利用者で分けるコードが無ければ、田中の発言も含めて回答を作る

AgentCore Runtime には、会話の履歴を利用者ごとに分ける仕組みが無い。会話の履歴は、エージェントが microVM のメモリやディスクに持つ状態の一つである5。分けるなら、エージェントのコードが、AgentCore Memory などに利用者のIDを付けて保存し、利用者ごとに読み出す7。最後の手順は、本稿の推論である。

この例から言えること

  1. 一人に一つのセッションなら、隔離の強さはどちらも同じで、セッションごとに VM が分かれる。違うのは開発者の手間で、Foundry では利用者IDを渡せばサービスが利用者ごとのセッションを作り、AgentCore では開発者が、利用者ごとのセッションIDを作って記録するコードを書く。
  2. セッションを共有するなら、違うのは会話の履歴の分け方で、Foundry ではサービスが利用者ごとに分け、AgentCore では開発者がエージェントのコードに分ける処理を書く。
  3. 共有したセッションの中で、会話の履歴以外にエージェントが書くファイル、データベースの行、キャッシュは、どちらのサービスも利用者ごとに分けない。セッションIDと利用者IDの組をキーにして、アプリが分ける38。
  4. 利用者は多いが同時に話す人は少ないアプリでは、セッションを共有すれば数を同時の処理量まで抑えられる。そのとき会話の履歴をサービスが分ける Foundry のほうが、開発者が書く分離のコードは少ない。

両者とも、セッションごとに専用の VM を割り当てる

別のセッションのファイルとメモリに届かないことは、両者に共通する。Foundry hosted agents は Microsoft のマネージドサービスで、前年の Microsoft Ignite でプレビューされた後、2026年4月にセッションごとのサンドボックスとして作り直された1。これを使う SDK の Microsoft Agent Framework は、2025年4月に作られた GitHub リポジトリで公開されている9。AgentCore Runtime は AWS のマネージドサービスで、その Python SDK は 2025年7月に作られた GitHub リポジトリで公開されている10。

Microsoft は、複数のセッションで一つのコンテナを共有する従来の形を、エージェントがファイルを書き、コードを実行し、認証情報に触れる点で、非効率なだけでなく危険と書く1。Foundry hosted agents のセッションは、$HOME と /files にファイルを残す、VM で隔離された環境で、会話とは別の概念だ42。Microsoft は、利用者の分離（誰のデータを使ってよいか）とセッションの分離（コードとファイルがどこに残るか）を、独立した二つの制御として説明する2。

AWS は、AgentCore Runtime の各セッションに、計算、メモリ、ファイルシステムが独立した microVM を割り当てる。セッションが終わると microVM を終了し、メモリを消去する。停止したセッションは次の呼び出しで新しい microVM を得て再開し、セッションストレージを設定すると、指定したパスのファイルは停止と再開をまたいで残る5。これは microVM 型の計算資源での振る舞いで、AgentCore Runtime には、自分のアカウントの EC2 インスタンスで動かす Instances 型もある。この型でもセッションとインスタンスは一対一だが、一つのインスタンスで動く複数のエージェントは互いに分離されない11。AWS は分離が要る理由に、エージェントがメッセージ履歴を超えた状態を持つこと、利用者に代わって権限のあるツール操作をすること、モデルの振る舞いが確率的でも境界は一定でなければならないことを挙げる5。

Foundry は利用者IDで会話履歴を分けるので、一つのセッションを複数の利用者で共有できる

一つのセッションの中で、要求の利用者に合わせて基盤が会話履歴を分ける仕組みは、Foundry の Responses プロトコルだけが持つ。もう一つの Invocations プロトコルでは、基盤は会話履歴を持たず、状態はエージェントのコードが管理する4。既定では、Foundry は Microsoft Entra ID のトークンから呼び出し元を判別し、呼び出し元ごとに別のセッションを割り当てる6。自前で利用者を認証するアプリでは、中継層が x-ms-user-identity ヘッダーで利用者IDを渡す。値は基盤が中身を解釈しない 1〜256 文字の文字列で、基盤はこの値ごとにセッションを分ける6。このヘッダーには組み込みロールに含まれない権限が要り、カスタムロールで付与する。権限が無いと 403 で拒否される63。

Microsoft がプールを勧める理由は、同時セッション数の上限である。各セッションはターンを処理する間、リージョンごとの同時セッション数に数えられるので、Microsoft は利用者ごとに一つでは足りないと書く3。利用者は読み、考え、入力する間があるので、同時のリクエストの最大は、多くの場合、利用者数のごく一部である3。中継層は、その最大に合わせたセッションプール（有限個のセッションの集まり）に利用者を割り当てる3。AgentCore Runtime にも、アカウントあたりのアクティブなセッションの数に既定の上限（米国東部のバージニア北部と米国西部のオレゴンで 5,000、ほかのリージョンで 2,500）があり、Service Quotas で引き上げられる12。

一つのセッションの中でファイルを利用者ごとに分けるのは、Foundry でもアプリの仕事である。コンテナ自身が持つファイル、データベースの行、キャッシュは自動では分けられず、セッションIDと利用者IDの組をキーにする必要がある3。アプリの状態を基盤に預ける場合は、プレビューの state store が、コードが渡す値ではなく要求から利用者を決めて、項目を利用者ごとに分ける13。利用者とセッションの対応付けも基盤は強制せず、アプリが作ったセッションには、中継層が代理で呼び出す利用者の誰でも入れる6。同じページは、中継層が同じセッションに二人を入れると二人は互いのデータを見られると警告し、一つのセッションに複数の利用者を入れるとサンドボックスのファイルシステムも共有されると書く6。

利点は、セッション数を同時の処理量に合わせられることである。欠点は二つある。キーの付け方を誤るとデータが漏れ、その責任はアプリが負う。また、コンテナが基盤とやりとりする規約（コンテナプロトコル）を、バージョン 2.0.0 に移行しなければならない3。

AgentCore は対応付けをアプリに任せ、一人に一つのセッションを前提にする

AgentCore では、利用者とセッションの対応付けはアプリが決める。アプリは最初の呼び出しで runtimeSessionId を渡し、そのセッションの microVM が作られる5。文書は、利用者または会話ごとに 33 文字以上の一意なIDを作り、別の利用者には別のIDを使うよう勧める5。ただし、AgentCore は利用者とセッションの対応付けを強制せず、対応の管理と、利用者あたりのセッション数の上限などの管理は、クライアント側のバックエンドが行う58。AWS は、AWS が守る範囲と利用者が守る範囲を分ける責任共有モデルの中で、この対応付けの強制を利用者側の責任に挙げる8。

利用者IDを渡すヘッダー X-Amzn-Bedrock-AgentCore-Runtime-User-Id はあるが、目的はセッションの分離ではない。エージェントが利用者に代わって OAuth のトークンを取得するための値である14。AgentCore は値を中身の不明な文字列として扱い、認証済みの利用者と照合しない14。IdP を持つ本番の構成では、AWS はこのヘッダーではなく、トークンの発行元・署名・期限を確かめる JWT の認証を勧める14。このヘッダーを付けるには IAM の InvokeAgentRuntimeForUser 権限が要り、AWS は信頼できる主体だけに与えるよう求める148。

AgentCore Runtime の文書には、会話の続きを利用者に結び付け、別の利用者が続けるのを拒否する仕組みは無い。AWS は会話の履歴を、エージェントが microVM のメモリやディスクに持つ状態の一つに挙げる5。セッションの寿命を越えて残す利用者の会話履歴には、AWS は AgentCore Memory を使うよう勧める5。AgentCore Memory は会話のイベントをセッションIDと利用者（actor）のIDの組で保存し、利用者またはセッションごとに取り出せる7。その利用者のIDはエージェントの側が渡す値で、AgentCore Memory が認証済みの利用者と照合するかは、本稿は確かめていない。本稿の推論では、AgentCore で二人の利用者を同じセッションに入れると、エージェントのコードが履歴を利用者で分けない限り、一方への回答に他方の会話も入りうる。

利点は、バックエンドが一人に一つの対応を守る限りセッションの中に他の利用者が入らず、セッション内で利用者ごとにファイルを分ける実装が要らないことである58。欠点は、セッション数が利用者数に比例して増えることと、対応付けのバックエンドをアプリが作ることである。

どちらを選ぶか：一つのセッションを複数の利用者で共有するかで決まる

分ける対象Foundry hosted agentsAgentCore Runtime
別のセッションのファイルとメモリ基盤（セッションごとの VM）4基盤（セッションごとの microVM）5
同じセッション内の会話履歴Responses プロトコルなら基盤が利用者ごとに分ける3（Invocations プロトコルでは基盤に履歴が無い4）Runtime には無い。AgentCore Memory に利用者IDを付けて保存すれば分けられる57
同じセッション内のファイル・行・キャッシュアプリ3アプリ8
利用者とセッションの対応付け基盤（既定は Entra ID の呼び出し元ごと、委任時は利用者IDごとに作る。委任した利用者どうしは分けず、共有時の割り当てはアプリ）63アプリのバックエンド5
一つのセッションの中と外で、基盤とアプリのどちらが分けるか

違いが出るのは 2 行目（共有したセッションの会話履歴）と 4 行目（対応付け）である。利用者が多く、一人あたりの同時の処理が少ないアプリで、セッションを共有して数を抑えたいなら、Foundry のプールが向く。代償は、ファイル・行・キャッシュのキーに利用者IDを加える実装と、プロトコル 2.0.0 への移行である3。AgentCore で同じ組み方をすると、エージェントは会話履歴を AgentCore Memory などに利用者IDを付けて保存し、その利用者IDをアプリが正しく渡す必要がある7。

利用者ごとにファイルや認証情報を持って長く動かす作業には、本稿は利用者ごとのセッションが向くと考える。この組み方では表の 1 行目だけで利用者が分かれるので、どちらの基盤でも成り立ち、分離の要件だけでは選び切れない。残る差は 4 行目で、Foundry は Entra ID の呼び出し元か中継層が渡す利用者IDごとに基盤がセッションを作り、AgentCore ではアプリのバックエンドが利用者ごとのセッションIDを作って管理する。

限界

分離の記述はすべて作り手自身の文書であり、本稿が引く資料に独立した監査は無い。Foundry のプール方式は、ローカル実行では分離が強制されない3。AgentServer SDK と Microsoft Agent Framework の hosting パッケージはプレリリース版である（サービス自体は一般提供）2。

AgentCore で永続ファイルシステムを使う場合、ファイルの権限は記録されてもセッション内では強制されない。また、microVM で動くどのコードも、メタデータサービス（MMDS、MicroVM Metadata Service）から実行ロールの認証情報を取れる8。ファイル名に利用者IDを加えると、ある利用者の要求で開くファイルはその利用者のものになる。ただし、その区分けはアプリのコードが守る取り決めであり、同じ VM のコードが別の利用者のファイル名を開くことを基盤が止めるとは、本稿が引くどちらの文書も書いていない。Microsoft はファイルの区分けをアプリの仕事と書き3、AWS は対応付けの強制をアプリ側の責任とする8。本稿が引く文書の範囲では、共有したセッションでファイルを利用者ごとに分ける実装はアプリが書く。

出典14件

  1. Microsoft Foundry チーム「Introducing the new hosted agents in Foundry Agent Service」Microsoft DevBlogs, 2026-04-22. https://devblogs.microsoft.com/foundry/introducing-the-new-hosted-agents-in-foundry-agent-service-secure-scalable-compute-built-for-agents — コンテナ共有を危険とする理由、セッションごとのサンドボックス、前年の初公開。 ↩ ↩2 ↩3

  2. Microsoft Agent Framework 開発チーム「Foundry hosted agent isolation with Microsoft Agent Framework」Microsoft DevBlogs, 2026-09-22. https://devblogs.microsoft.com/agent-framework/foundry-hosted-agent-isolation-with-microsoft-agent-framework/ — 利用者とセッションの二つの制御、会話とセッションの区別、SDK の版。 ↩ ↩2 ↩3 ↩4

  3. Microsoft「Multiplex multiple users in one hosted agent session」Microsoft Learn, 更新 2026-10-13. https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/multiplex-session-users — プールの理由、基盤が分ける範囲と分けない範囲、ローカル実行は強制しない点。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  4. Microsoft「What are hosted agents?」Microsoft Learn, 2026（2026-10-24 取得）. https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents — セッションが $HOME と /files にファイルを残すこと、Invocations プロトコルには基盤が管理する会話履歴が無いこと。 ↩ ↩2 ↩3 ↩4 ↩5

  5. AWS「Use isolated sessions for agents」Amazon Bedrock AgentCore Developer Guide, 2026（2026-10-24 取得）. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html — セッションごとの microVM、AWS の理由三つ、セッションIDの付け方、対応付けは強制しない点。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  6. Microsoft「Isolate hosted agent sessions per user」Microsoft Learn, 2026（2026-10-24 取得）. https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/isolate-sessions-per-user — Entra ID による既定の分離、委任ヘッダーと権限、同じセッションの二人の警告。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  7. AWS「Memory organization in AgentCore Memory」Amazon Bedrock AgentCore Developer Guide, 2026（2026-10-27 取得）. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-organization.html — 短期記憶のイベントをセッションIDと actor ID の組で保存すること。 ↩ ↩2 ↩3 ↩4

  8. AWS「Security best practices for AgentCore Runtime」Amazon Bedrock AgentCore Developer Guide, 2026（2026-10-24 取得）. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-security-best-practices.html — 対応付けは利用者の責任、権限は強制されない点、MMDS の認証情報。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  9. microsoft/agent-framework, GitHub（2026-10-24 取得）. https://github.com/microsoft/agent-framework — スター 14,302、リポジトリ作成は 2025年4月。 ↩

  10. aws/bedrock-agentcore-sdk-python, GitHub（2026-10-24 取得）. https://github.com/aws/bedrock-agentcore-sdk-python — スター 780、リポジトリ作成は 2025年7月。 ↩

  11. AWS「Security model and permissions for Runtime Instances」Amazon Bedrock AgentCore Developer Guide, 2026（2026-11-02 取得）. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-security.html — Instances 型のセッションとインスタンスの対応、エージェントどうしの非分離。 ↩

  12. AWS「Quotas for Amazon Bedrock AgentCore」Amazon Bedrock AgentCore Developer Guide, 2026（2026-10-27 取得）. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html — アカウントあたりのアクティブなセッション数の既定の上限。 ↩

  13. Microsoft「Durable state store for Microsoft Foundry hosted agents (preview)」Microsoft Learn, 2026（2026-11-02 取得）. https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-state-store — 利用者ごとに分ける保存先で、利用者は要求から決まること。 ↩

  14. AWS「Authenticate and authorize with Inbound Auth and Outbound Auth」Amazon Bedrock AgentCore Developer Guide, 2026（2026-10-24 取得）. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-oauth.html — ヘッダーの目的は OAuth トークン取得で、値は未検証。 ↩ ↩2 ↩3 ↩4

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。