Amazon Bedrock AgentCoreとは。AIエージェントを本番で動かす部品群と、会社で使うときの費用の考え方

Amazon Bedrock AgentCoreとは、AWSが提供する、AIエージェントを作って本番で動かし、運用し続けるための部品群です。AWSによると、実行環境・記憶・道具の接続・認証・監視などのサービスで構成され、使うフレームワークやAIモデルを選ばない作りになっています。社員がそのまま開いて使うチャット画面ではなく、開発者が自社の仕組みに組み込んで使う土台になります。料金は使った分だけの従量で、呼び出すAIモデルの料金は別にかかる、と考えておくのが実態に近いでしょう。

モデルごとの単価や、社員数別の月額の目安はAmazon Bedrockの料金の記事で扱っています。

Amazon Bedrock AgentCoreとは｜AIエージェントを本番で動かすための部品群

Amazon Bedrock AgentCoreは、AIエージェントを作って本番で動かし、運用し続けるための土台を、AWSが部品の形でまとめたサービスになります。AWSの日本語製品ページでは「エージェントを大規模かつ安全に構築、デプロイ、運用するためのエージェントプラットフォーム」と説明されています。英語の開発者向けドキュメントでも、どのフレームワークや基盤モデルを使う場合でも、インフラの管理なしにエージェントを作って動かせる、という位置づけです。サーバーの用意や台数の調整をAWS側に任せられる点が、マネージドという言葉の中身と考えてよいでしょう。

部品どうしは組み合わせても、1つだけ使ってもかまいません。AWSによると、CrewAI・LangGraph・LlamaIndex・Strands Agentsなどのオープンソースの開発用フレームワークや、どの基盤モデルとも組み合わせて使うことが出来ます。実行環境のRuntimeについては、Bedrockの中にあるモデルだけでなく外のモデルも使える、とドキュメントの表にあり、例としてOpenAIのモデルやGoogleのGemini、AnthropicのClaude、Amazon Nova、Meta Llama、Mistralのモデルが並んでいます。AWSのモデルだけに縛られない作りだと受け止めてよさそうです。

製品ページには、Ericsson・Thomson Reuters・Cox Automotive・Amazon Devices（Amazonのグループ内の部門）が利用企業として紹介されています。いずれも同社が掲載している事例で、海外の大きな企業が中心となります。

エージェントとは何か｜チャットで答えるAIとの違い

エージェントとは、質問に文章で答えるだけでなく、道具を使いながら仕事を何段階か進めるAIのことを指します。チャットのAIは、聞かれたことに答えたところでひと区切りになるのが普通です。エージェントは、社内のシステムを調べ、Webで情報を確かめ、必要ならフォームに入力し、結果をまとめて返すところまでを、決められた範囲の中で自分で順に進めます。人が1つずつ指示を出すチャットと比べると、任せる範囲がずっと広くなります。

総務や経理の仕事に置きかえると、申請書に必要な項目がそろっているかを確かめる作業や、社員からのよくある問い合わせに一次回答する作業が、エージェントの考えやすい使い道になるでしょう。ただし、社内のどのシステムに触らせ、どこまで任せ、どこで人が確認するかは、会社が決めて作り込む部分です。AgentCoreが用意するのは、その作り込みを支える部品のほうになります。

社員がそのまま使うチャット画面ではない

AgentCoreは、社員がブラウザで開いて質問を打ち込む画面を持ったサービスではありません。開発者がプログラムからAPIで呼び出し、自社のアプリや業務システムに組み込んで使う部品の集まりです。AgentCoreという名前を社内で聞いたら、まず作るための部品の話なのか、社員が使う道具の話なのかを確かめてみてください。名前にBedrockと付いていますが、Bedrock自体も、AWSのドキュメントではAPIやSDKから呼び出す使い方が前提になっています。コンソールには試しにモデルを動かせるプレイグラウンドもありますが、社員全員に配る業務用のチャット画面とは別物と考えたほうがよいでしょう。この境目は社員にAIを配るときの判断を左右するので、5つ目の節で費用と手間の面からもう一度取り上げます。

AgentCoreの名前が社内に出てくる場面

AgentCoreの名前を経営者や総務の方が耳にするのは、開発会社からの提案や、AWSに詳しい社員の相談の中であることが多いでしょう。そのときに確かめたいのは、作ろうとしているのが社員みんなが使うチャットなのか、特定の業務を進めるエージェントなのか、という1点になります。前者であれば、AgentCoreのような部品から作らなくても、ほかの選び方が見つかる場合があります。後者であれば、後半にある会社が決めることの一覧と、開発会社への質問の一覧が役に立つはずです。

AgentCoreの13のサービスを会社の言葉に言い換える

AWSの開発者向けドキュメントには、2026年10月14日時点でAgentCoreを構成するサービスが13個並んでいます。英語の名前のままでは役割がつかみにくいので、会社の仕事に置きかえた言葉と並べると次のようになります。

  • Harness（ハーネス）＝お任せで組める作業の段取り使うモデル、システムプロンプト（AIへの基本の指示文）、使わせる道具を指定すると、1回のAPI呼び出しでエージェントを動かせる管理型の仕組みです。2026年6月に一般提供が始まっています。
  • Runtime（ランタイム）＝エージェント専用の作業部屋エージェントを動かすサーバーレスの実行環境です。セッション（1回の利用）ごとに分けて動かす作りで、製品ページでは最大8時間の非同期タスクまで扱えると説明されています。
  • Memory（メモリー）＝引き継ぎメモと、これまでの経緯の控え短期記憶で同じ会話の続きを、長期記憶でセッションをまたいで残したい情報を扱います。
  • Gateway（ゲートウェイ）＝社内システムへの受付窓口既存のAPIやLambda（AWSでプログラムを動かす仕組み）を、MCP（AIに道具をつなぐための共通の規格）に対応したツールに変換します。Salesforce・Zoom・JIRA・Slackなどとの連携も用意されています。
  • Identity（アイデンティティ）＝社員証と入館の権限エージェントの認証と権限を扱います。Cognito・Okta・Microsoft Entra ID・Auth0などの既存のIdP（社員のログインを管理する仕組み）と連携できます。
  • Code Interpreter（コードインタープリター）＝計算や集計を任せる別室の作業机隔離された環境で、Python・JavaScript・TypeScriptのコードを実行します。
  • Browser（ブラウザー）＝代わりにWebで手続きする担当クラウド上のブラウザでWebサイトを操作し、フォームに入力します。
  • Observability（オブザーバビリティ）＝業務日報と作業の記録係CloudWatch（AWSの監視サービス）で各ステップを追跡・監視します。OpenTelemetry（監視データの共通形式）に互換があります。
  • Payments（ペイメンツ）＝小口の支払い係エージェントによる少額の決済を扱い、Coinbase CDPやStripe（Privy）とつなぎます。2026年10月14日時点で、東京リージョンでは使えません。
  • Evaluations（エバリュエーションズ）＝品質チェックの検査係エージェントの品質を自動で評価します。
  • Optimization（オプティマイゼーション）＝改善の提案係改善の推奨やA/Bテストで、エージェントを良くしていくための部品です。
  • Policy（ポリシー）＝社内規程と決裁のルールツールを呼び出す前に、規則で止めます。規則は自然言語か、Cedar互換の言語で書けます。2026年3月に一般提供が始まっています。
  • Registry（レジストリー）＝社内の道具の台帳エージェント・MCPサーバー・ツールをまとめた社内向けのカタログです。

※サービスの一覧は、AWSの開発者向けドキュメント（What is Amazon Bedrock AgentCore）の表を2026年10月14日に確認したものです。会社の言葉への言い換えは、役割を伝えるための例えです。

13個すべてを使う必要はなく、作りたいエージェントに要るものだけを選んで組み合わせる使い方が出来ます。どれを使ったかで請求の項目も変わるので、料金の節で見る単価もサービスごとに分かれています。社内で説明するときは、この言い換えをそのまま資料に使ってみてください。

このうち、エージェントを動かす土台になるのはRuntime・Memory・Gateway・Identity・Observability・Browser・Code Interpreterの7つです。残りのHarness・Payments・Evaluations・Optimization・Policy・Registryは、作る手間を減らしたり、品質や規則、道具の台帳を管理したりするための部品と見ることが出来ます。部品の数が増えたぶん、どれを使うかを選ぶ判断も作り手に任されるようになっています。

名前に付いたBedrockという言葉から、Bedrockの中の機能の1つと思われがちですが、AgentCoreは料金ページもリージョン表も別に用意されたサービスです。Bedrockのモデルを使わずに、Runtimeから外部のモデルを呼ぶ組み方も出来ます。見積もりを取るときも、BedrockとAgentCoreの料金を分けて出してもらうと比べやすくなります。

中心になる7つの機能（Runtime・Memory・Gateway・Identity・Observability・Browser・Code Interpreter）の役割

7つの機能は、エージェントが動く場所、覚えておくこと、つなぐ先、誰として動くか、何をしたかの記録、Web操作とコード実行という、仕事の段取りの各場面を分けて受け持っています。それぞれが会社の仕事のどこに当たるのかを添えて並べると、全体の形がつかみやすくなります。

Runtime｜セッション分離（microVM）と最大8時間の長時間実行

Runtimeは、作ったエージェントを載せて動かす、サーバーレスの実行環境です。サーバーレスとは、サーバーの台数や性能を自分で用意しなくても、使った分だけAWS側で処理してくれる形のことになります。AWSによると、Runtimeはセッションごとに分離されていて、1回の利用ごとに区切られた環境で動きます。リージョンの表や料金表にも、Runtime microVMsという名前が出てきます。製品ページでは、最大8時間の非同期タスクまで扱えると説明されています。非同期タスクとは、依頼を受けてから結果を返すまで、人が画面の前で待たなくてもよい長めの作業のことです。書類の束を順に読み込んで確かめるような、時間のかかる仕事も任せられる長さと見ることが出来ます。

Memory｜会話の続きと、セッションをまたぐ記憶

Memoryは、エージェントに覚えさせておく情報を扱う部品です。短期記憶は同じ会話の続きを、長期記憶はセッションが終わった後も残しておきたい情報を受け持つ、とAWSは説明しています。問い合わせ対応のエージェントであれば、前回どんな相談を受けたかを覚えておくような使い方になるでしょう。覚えさせる情報が増えるほど保存の料金もかかるため、何を残して何を消すかは会社で決めることになります。料金ページでは、短期記憶の取り込みが2026年10月6日から1GBあたり1.00ドルとなり、長期記憶は1,000レコードあたりの月額で保存の料金がかかる形が示されています。

Gateway｜MCP対応で、既存のAPIやLambdaをツールにする

Gatewayは、社内にすでにあるシステムを、エージェントが使える道具に変える受付窓口のような部品です。AWSによると、既存のAPIやLambdaを、MCPに対応したツールに変換できます。MCPはAIに外部の道具をつなぐための共通の規格で、対応したツールであれば、エージェントから同じ手順で呼び出せるようになります。Salesforce・Zoom・JIRA・Slackなどとの連携も用意されていると案内されています。社内のどのシステムを窓口の向こうに置くかが、エージェントにどこまで任せるかを決める分かれ目になってきます。ツールの索引にも、100ツールあたり月0.02ドルの料金がかかると料金ページにあります。

Identity｜既存のIdP連携による認証・権限

Identityは、エージェントが誰として、どの権限で動くのかを管理する部品です。社員のログインを管理するIdPと呼ばれる仕組みと連携でき、AWSの例ではCognito・Okta・Microsoft Entra ID・Auth0などが挙がっています。すでに社内のログインをこうした仕組みでまとめている会社であれば、同じ社員の情報をもとに権限を分ける作りになります。料金ページには、RuntimeやGatewayを通して使う場合はIdentityに追加の料金がかからない、と書かれています。ただし、どの社員にどこまで触らせるかという権限の中身は、使う会社が決めて設定することになります。

Observability｜OpenTelemetry互換で、CloudWatchから監視する

Observabilityは、エージェントが何を考え、どの道具を呼び、どこで止まったかを、ステップごとに追いかけるための部品です。AWSの監視サービスであるCloudWatchで追跡・監視し、監視データの共通形式であるOpenTelemetryにも互換があると説明されています。料金はCloudWatchの料金表に沿ってかかるとされ、AgentCoreの料金表とは別に確かめる必要があります。あとから原因を調べられるよう記録を残しておくことは、社員が使う道具として運用するうえで欠かせない土台になります。

Browser・Code Interpreter｜Web操作とコード実行を隔離して行う

Browserは、クラウド上のブラウザでWebサイトを操作し、フォームに入力するための部品です。Code Interpreterは、隔離された環境でPython・JavaScript・TypeScriptのコードを実行するための部品になります。どちらも、エージェントに手を動かす作業を任せるための道具と言うことが出来ます。Webでの手続きや集計を任せるなら便利な反面、どのサイトで何をしてよいかを決めずに渡すと、思わぬ操作につながりかねません。任せる範囲は、Policyで止める規則と合わせて最初に決めておきましょう。

総務・経理の仕事に置いたときの部品の組み合わせ例

部品の役割は、身近な仕事に置いてみると分かりやすくなります。ここで挙げるのは、AgentCoreの部品をどう組み合わせるかを説明するための例で、AWSが公開している事例ではありません。

例1：経費の申請書を確かめるエージェント

社員が出した経費の申請に、必要な項目と領収書がそろっているかを確かめ、足りないものを本人に知らせる仕事を考えてみます。エージェントそのものはRuntimeで動かし、経費の申請システムにはGatewayを通してつなぐ形になります。誰の申請を読んでよいかはIdentityで分け、支払いの承認のような操作はPolicyの規則で止めておくことが出来ます。どの申請をどう判断したかはObservabilityに残るので、経理の担当者があとから確かめられます。最後に支払いを決めるのは人、という線を最初に引いておくのが安心でしょう。

例2：社内の問い合わせに一次回答するエージェント

総務に届く、休暇の手続きや備品の申し込み方などの質問に、まずエージェントが答える使い方もあります。社内規程を探して答えるならGateway、前回の相談の続きを覚えさせるならMemoryを使う組み合わせになるでしょう。答えの品質はEvaluationsで確かめ、答えにくい質問は総務の担当者へ回す決まりにしておけば、社員も安心して使えます。

例3：取引先のWebサイトで手続きを進めるエージェント

取引先の受発注サイトにログインして、注文の状況を確かめる作業を任せる場合は、Browserの出番になります。ただ、Webでの操作は思わぬ画面に進んでしまうこともあり、任せる範囲を狭く決めておく必要があります。決済をエージェントに任せるPaymentsは、2026年10月14日時点で東京リージョンでは使えない点も覚えておきましょう。

例4：月次の数字を集計し、報告の下書きを作るエージェント

会計システムから月次の数字を取り出し、前月との差を集計して、役員向けの報告の下書きを作る仕事も考えられます。数字の取り出しはGateway、集計の計算はCode Interpreter、毎月の書き方の決まりはMemoryに覚えさせる組み合わせになるでしょう。計算をAIの文章づくりに任せず、隔離された環境のコードで行わせる点が、数字を扱う仕事では安心材料になります。ただ、会計の数字は社内でも見られる人を絞っている会社が多いので、Identityで誰の依頼なら読めるかを分けておく必要があります。

どの例でも、エージェントが触るシステムと任せる範囲を決めるのは会社で、AgentCoreはそれを形にする部品を貸してくれる立場です。社内でエージェントの話が出たときは、どの仕事を、どこまで任せたいのかを一文で書き出してみてください。書き出した仕事に、どの部品が要るかを当てていくと、作る規模の見当もついてきます。

AgentCoreを契約すれば、社員がすぐAIを使えるのか

AgentCoreを使い始めただけでは、社員がChatGPTのように開いて使える画面は手に入りません。AgentCoreは作り手のための部品で、社員が触る画面やログインの仕組み、部署ごとの権限、費用の管理は、自社で作るか別に用意する必要があります。部品と完成品の境目を、社員にAIを配るときに必要なものごとに分けて見てみましょう。

社員に配るときに必要になるもの

  • 社員が質問を打ち込み、答えを読むための画面（Webアプリやチャットツールへの組み込み）
  • 社員ごとのログインと、退職・異動のときにアカウントを止める手順
  • 部署や役職ごとに、使えるAIや触れる社内データを分ける権限の設計
  • 誰がいつ何に使ったかを残す利用ログと、それを会社が見る画面
  • 入力したデータが学習に使われないかなど、AIごとの条件の確認
  • 毎月の費用を見積もり、使いすぎを止める仕組み
  • モデルの入れ替えや不具合への対応などの、作った後の保守

AgentCoreには、このうちの一部を支える部品がそろっています。ログインと権限はIdentity、利用の記録はObservability、使い方の規則はPolicyが受け持ちます。それでも、部品をどうつなぎ、社員にどんな画面で見せ、どの部署に何を許すかを決めて作るのは、使う会社の仕事になります。社員が質問を打ち込む画面そのものは、13のサービスの一覧に入っていません。

作る場合と、完成品を使う場合で変わること

自社で作る場合は、画面の見た目から権限の分け方まで、自社の業務に合わせて決められる自由があります。その代わり、決めたことを形にして守り続ける手間も、すべて自社に残ります。完成品のAIサービスを使う場合は、画面・ログイン・管理の仕組みが最初からそろっているため、決めることは誰に何を使わせるかという運用の中身が中心になります。できることの幅はサービスが用意している範囲に限られるので、自社の業務に合うかどうかを、実際の画面で確かめておくことになるでしょう。どちらが正しいというより、社員に配る道具がほしいのか、業務を自動で進める仕組みがほしいのかで選ぶものが変わる、と考えてみてください。

AgentCoreの請求書に載らない費用

AgentCoreの請求に出てくるのは、部品を使った分の利用料だけです。実際に会社が負担するものには、呼び出したAIモデルの利用料、エージェントを作る人の手間、作った後の保守、社員向けの画面と権限の管理が、それぞれ別に加わってきます。このうち人の手間と保守はAWSの請求書に載らないため、見積もりの段階で見落とされやすい費用となってしまいます。社内で作るのか、外部の開発会社に頼むのかによっても、金額の出方は大きく変わるでしょう。情報システムの担当が少ない会社では、作った人が異動や退職をすると、仕組みを直せる人がいなくなるおそれも出てきます。AgentCoreの料金だけを見て安いと判断せず、作る手間と保守の担い手まで含めて比べてみてください。社員にAIを使わせること自体が目的であれば、作らずに使える方法から検討したほうが、近道になる場合も多いでしょう。

画面・ログイン・権限まで自社で作らずに全員へ配るなら

開発をせずに、社員が使う画面と管理の仕組みを会社で1つにまとめる方法もあります。UPGEAR AI（アップギアAI）は、ChatGPT・Claude・Gemini・Perplexityを1つの契約で使える法人向けサービスです（人数無制限）。

資料をダウンロードUPGEAR AI（アップギアAI）を詳しく見る

Bedrock・Bedrock Agentsとの違い｜基盤か、マネージドの完成品か

Bedrockは多くのAIモデルを1つの窓口で呼び出せる基盤で、AgentCoreはBedrockと組み合わせることの多い、エージェントを作って動かすための部品群、という関係になります。AWSの英語ドキュメントでは、Bedrockは主要なAI企業の高性能な基盤モデルに、安全で企業向けの形でアクセスできるフルマネージドサービスと説明されています。同じドキュメントによると、100以上の基盤モデルに対応し、Amazon・Anthropic・DeepSeek・OpenAI・xAIなどの提供元が名を連ねる形になります。モデルを呼ぶ料金はBedrockの料金、エージェントの実行や道具の接続にかかる料金はAgentCoreの料金、と分けて考えると整理しやすいでしょう。

Bedrock Agents（Bedrock Agents Classic）は新規の受付を終えている

Bedrockには、以前からBedrock Agentsというエージェントを作る機能があります。AWSのドキュメントによると、この機能は現在Amazon Bedrock Agents Classicという名前になり、新しい利用者の受付を終えています。同じページには、Bedrock Agents Classicに近い機能を求めるならAgentCoreを、という案内もあります。これから新しくエージェントを作る会社にとって、AWSの上での選択肢はAgentCoreが中心になってきます。

AgentCoreは部品を選んで組み合わせる作りのため、自由がきく反面、何をどう組むかを決める仕事は作り手の側に残ります。開発の経験が少ない会社ほど、この組み立ての手間を重く感じやすいでしょう。すでにBedrock Agents Classicで作ったエージェントがある会社は、今後の置き場所をAgentCoreで考えるかどうか、担当の方と早めに話し合ってみてください。

役割の分担を、社内の言葉で言うと

Bedrockを、さまざまな会社のAIモデルを借りられる窓口と考えると、AgentCoreは、借りたAIに仕事の段取りを与え、道具を持たせ、記録を取るための作業場のような立場になります。窓口だけを使ってもモデルに質問して答えを受け取る仕組みは作れますが、道具を使って何段階も仕事を進めさせるには、作業場の部品が要ってきます。社員が使う画面をどう用意するかは、どちらを使う場合でも別に考えることになるでしょう。社内の会議では、窓口と作業場という言い方で説明すると、開発に詳しくない方にも伝わりやすいはずです。

GAの経緯と、東京リージョンで使える機能

AgentCoreは2025年7月にプレビューとして発表され、2025年10月13日に一般提供（GA）が始まり、その時点から東京リージョンでも使えるサービスとなっています。

2025年7月のプレビューから一般提供開始まで

AWSのブログでプレビューが発表されたのは2025年7月のことです。AWSのWhat's Newでは、2025年10月13日の投稿で一般提供の開始が告知され、そのとき使えるリージョンとして東京を含む9つが挙がっていました。その後も部品は増えていて、規則でツールの呼び出しを止めるPolicyは2026年3月に、管理型でエージェントを動かすHarnessは2026年6月に一般提供が始まっています。1年ほどの間に部品の数がふくらんできたサービスなので、解説を読むときは、書かれた時点を確かめてみてください。料金とリージョンは、AWSの公式ページの現在の表示を正としておくのが安全です。

東京リージョンで使える機能・使えない機能

2026年10月14日時点のAWSのリージョン表では、東京リージョン（アジアパシフィック（東京））で、決済のPayments以外の主な機能が使えるようになっています。

  • 東京でYesの機能：harness、Runtime microVMs、Runtime Instances、Memory、Gateway、Identity、Built-in Tools（組み込みの道具）、Observability、Policy、Evaluations、optimization、Agent Registry、Web Search Tool
  • 東京でNoの機能：payments（エージェントによる少額の決済）
  • 大阪リージョン：表に列がなく、対応していない扱い

大阪リージョンが表にないため、AgentCoreだけで考えると、国内の2か所に分けて置く構成は取りにくくなります。決済を任せるエージェントを考えている場合は、どのリージョンで使えるかを先に公式の表で確かめましょう。

※リージョンの対応は、AWSの開発者向けドキュメント（AgentCoreのリージョン一覧）を2026年10月14日に確認したものです。機能ごとに対応が変わることがあるため、契約前に公式の表でご確認ください。

リージョン表を見るときのコツ

AgentCoreのリージョン表は、サービスの単位ではなく、機能ごとにYesとNoが並ぶ作りになっています。Runtimeも、Runtime microVMsとRuntime Instancesのように分けて書かれているため、使いたい動かし方の行を探して確かめることになります。使う予定の部品を先に書き出し、1つずつ東京の列を見ていけば、見落としを防ぐことが出来ます。開発会社から提案を受けたときも、使う部品がすべて東京でYesになっているかを一緒に確かめてみてください。

AgentCoreが東京でも、モデルの推論の経路は別

AgentCoreを東京で動かしても、呼び出すAIモデルがどこで処理されるかは、モデルの側の推論方式で決まります。Bedrockには、東京から呼んだときに東京と大阪の範囲で処理するGeo（JP）と、元のリージョンの外にも送られうるGlobalという方式が用意されています。AWSのドキュメントには、GeoやGlobalの推論プロファイルは送信元のリージョンの外へリクエストを送ることがあり、1つのリージョン内にデータを留める保証にはならない、という趣旨の注意書きがあります。Claudeでも、東京からはGlobalにしか対応していないモデルがあり、2026年10月14日時点のAWSのモデルカードではSonnet 5.5・Fable 5.1・Opus 5・Sonnet 5・Opus 4.6がそれにあたります。反対に、Opus 5.5やHaiku 5.5、Sonnet 4.6、Haiku 4.5などは、東京からGeo（JP）で呼び出すことが出来ます。データを国内に留めたい会社では、AgentCoreのリージョンとモデルの推論方式を、別々に確かめる必要が出てきます。

AgentCoreの料金は従量課金｜I/O待ちの時間の扱い

AgentCoreの料金は、前払いや最低料金のない、使った分だけの従量課金です。公式の料金ページには、初期の約束や最低料金のない利用量ベースの料金と書かれており、表示の料金はAWSの商用リージョンに適用されるとされています。金額はすべて米ドルで、税の扱いは料金ページに書かれていません。新しくAWSを使い始める方には最大200ドル分の無料枠のクレジットがあると案内されていますが、これはAWS全体の新規向けのもので、AgentCore専用の無料枠ではない点に気をつけましょう。

サービスごとの単価（2026年10月14日時点）

主なサービスの単価は、公式の料金ページで次のように表示されています。

  • Runtime（microVMs v1）：CPUは1vCPU時間あたり0.0895ドル、メモリは1GB時間あたり0.00945ドル
  • Runtime（microVMs v2）：CPUの消費は1vCPU時間あたり0.1276ドル、メモリの消費は1GB時間あたり0.0169ドル。committed baseline（確約した基本量）はCPU 0.0997ドル・メモリ0.0132ドルで、2026年10月までに始まる予定と記載
  • Browser・Code Interpreter：CPUは1vCPU時間あたり0.0895ドル、メモリは1GB時間あたり0.00945ドル
  • Web Search：1,000回の検索あたり7.00ドル
  • Gateway：API呼び出し1,000回あたり0.005ドル、Search APIは1,000回あたり0.025ドル、ツールの索引は100ツールあたり月0.02ドル
  • Identity：トークンやAPIキーの要求1,000回あたり0.010ドル。RuntimeかGatewayを通して使う場合は追加の料金なし
  • Memory：短期記憶の取り込みは1GBあたり1.00ドル（2026年10月6日以降。それ以前は1,000イベントあたり0.25ドル）、取り出しは1GBあたり0.20ドル、保存は1GBあたり月0.10ドル。長期記憶の保存（組み込み）は1,000レコードあたり月0.75ドル、取り出しは1,000回あたり0.50ドル
  • Policy：認可のリクエスト1回あたり0.000025ドル
  • Evaluations：組み込みの評価で、入力1,000トークンあたり0.0024ドル、出力1,000トークンあたり0.012ドル
  • Observability：CloudWatchの料金に準じる

単価はとても小さな数字に見えますが、エージェントが1回の仕事で何度も道具を呼び、記憶を読み書きすると、項目ごとの料金が少しずつ積み上がっていく仕組みになります。組み込みの評価にはモデルの利用料が含まれる一方、自社で作る評価ではモデルの利用料が別にかかる、と料金ページに書かれています。

※料金は2026年10月14日時点でAWSの公式料金ページ（Amazon Bedrock AgentCore pricing）に表示されている米ドルの金額です。税は含めていません。料金は変更されることがあるため、契約前に公式ページでご確認ください。

Runtimeのv1とv2の読み方

RuntimeのmicroVMsには、料金表の上でv1とv2の2つの単価があります。v1は、CPUが1vCPU時間あたり0.0895ドル、メモリが1GB時間あたり0.00945ドルという1本の単価です。v2はCPUとメモリの消費に対する単価に加えて、committed baselineという、あらかじめ確約した基本量の単価が2026年10月までに始まる予定と書かれています。公式の計算例はv2の単価で計算されているので、試算をするときはどちらの単価かをそろえておくことになるでしょう。開発会社の見積もりでも、v1とv2のどちらで計算したかを確かめておきましょう。

LLMの応答待ち・I/O待ちの時間の扱い

Runtimeの料金で押さえておきたいのは、AIの返事を待っている時間の扱いです。料金ページによると、LLMの応答や道具・APIの呼び出し、データベースへの問い合わせを待つI/O待ちの間は、CPUの使用がゼロまで下がるとされています。同じページには、エージェントの処理は時間の30〜70%ほどをこうしたI/O待ちに使うのが一般的、という説明もあります。請求は1秒単位で計算され、最低1秒、メモリは最低128MB分から数える決まりになっています。待ち時間の多いエージェントほど、CPUの料金は実際に処理している時間に近づいていくと考えてよいでしょう。公式の計算例でも、CPUの料金は10分のうち処理中の1分ぶんで計算されています。I/O待ちの間にゼロまで下がると書かれているのはCPUで、メモリの料金は別に計算される形です。

請求が増えやすい使い方

単価が小さくても、使い方によって請求が増えやすい項目があります。

  • Web検索を何度も使うエージェント（Web Searchは1,000回の検索あたり7.00ドル）
  • 長い会話や多くの記録を、Memoryに残し続ける使い方
  • 1回の仕事で何度も道具を呼ぶ設計（Gatewayの呼び出しが重なる）
  • 処理の長いセッションを、たくさん同時に動かす使い方
  • 自社で作る評価を何度も回す使い方（モデルの利用料が別にかかる）

どれも、エージェントの設計の段階で回数や量の見込みを立てておけば、見積もりに入れることが出来ます。AWSの予算の通知も合わせて設定し、想定より増えたときに気づける形にしておきましょう。

料金表に載っていないAIモデルの料金

AgentCoreの料金表には、AIモデルのトークン単価は載っていません。エージェントがBedrockのモデルを呼ぶ場合は、入力と出力のトークン数に応じたBedrockの料金が別にかかります。Bedrockの外にあるモデルを呼ぶなら、そのモデルの提供元の料金がかかることになるでしょう。モデルの単価と社員数ごとの月額の目安は、冒頭で触れたAmazon Bedrockの料金の記事で扱っています。AgentCoreの見積もりは、モデルの料金と足し合わせて見るようにしましょう。

公式の計算例を、社員100名×1日5回×20営業日に当てはめた試算

公式の計算例と同じ前提を社員100名の会社に当てはめると、Runtimeの部分だけで月67.03ドル、1ドル＝150円で計算した場合は約10,055円になります。

公式の計算例の前提

料金ページに載っている計算例は、Runtime（v2）で顧客サポートのエージェントを動かす想定です。

  • 月100万セッション
  • 1セッションは10分で、そのうち90%はI/O待ち
  • 処理中は1 vCPUを使い、メモリは1GBから、社内の資料を探して答える処理（RAG）の間は2GB、最大2.5GBまで使う
  • 1セッションあたり、CPU 0.002127ドル＋メモリ0.004576ドル＝0.006703ドル
  • 月の合計は6,703ドル（Runtimeの部分のみ）

100万セッションで月6,703ドルという数字は、大きな会社の顧客窓口を思わせる規模になります。社員10〜200名の会社がそのまま読むと、規模が違いすぎてつかみにくいかもしれません。

社員100名に同じ前提を当てた場合

1セッションの中身は公式の計算例と同じとして、回数だけを社員100名の会社に合わせて計算し直してみます。

  • 回数：100名×1日5回×月20営業日＝月10,000セッション
  • Runtimeの料金：0.006703ドル×10,000セッション＝67.03ドル
  • 円にすると：67.03ドル×150円＝約10,055円（1ドル＝150円で計算した場合）

1セッションの中身を変えずに回数だけを合わせた試算で、実際の金額はエージェントの作りと使われ方で上下します。この金額はRuntimeだけで、モデルの料金や監視の料金は入っていません。入っていないものには、Bedrockのモデルの料金、Memory・Gateway・Web Searchなどの料金、CloudWatchの料金があります。Runtimeだけなら月1万円ほどでも、モデルを呼ぶ料金はこれとは別に、質問の量と答えの長さに応じて積み上がることになります。社内の使い方に合わせて、1回の長さと回数を置きかえて計算してみてください。同じ前提のままなら、人数が2倍になればRuntimeの料金もそのまま2倍になる計算です。

※公式の計算例（Runtime v2・顧客サポート）と同じ前提を、回数だけ変えて当てはめた試算です。1ドル＝150円で計算した場合の金額で、税は含めていません。モデルの料金、Memory・Gateway等の料金、開発や保守の費用は含みません。

見積もりで並べたい費用の項目

AgentCoreで作るエージェントの費用は、AWSの請求に載るものと載らないものに分けて並べると、全体が見えやすくなります。

  • AWSの請求に載るもの：AgentCoreの各サービスの料金（Runtime・Memory・Gateway・Identity・Web Search・Policy・Evaluationsなど）
  • AWSの請求に載るもの：Bedrockのモデルの料金（入力と出力のトークン数に応じた料金）
  • AWSの請求に載るもの：Observabilityで使うCloudWatchの料金
  • AWSの請求に載らないもの：エージェントの設計と開発の費用
  • AWSの請求に載らないもの：作った後の保守と、モデルの入れ替えへの対応
  • AWSの請求に載らないもの：社員が使う画面とログインの仕組みを作り、守る費用

試算で出したRuntimeの約10,055円は、このうち最初の項目の、さらに一部にあたります。Bedrockの外のモデルを使う場合は、その提供元への支払いも加わります。見積もりを受け取ったら、6つの項目がそれぞれ入っているかを確かめてみてください。

動かし方の手順｜AWSアカウントの準備からデプロイ・運用までの流れ

AgentCoreでエージェントを動かすまでには、AWS側の準備、エージェントの作成、Runtimeへのデプロイ、道具と権限の接続、運用の監視という段階を順に踏むことになります。細かなコマンドや設定は開発者向けドキュメントにまとまっているため、ここでは会社として把握しておきたい流れだけを並べます。

  1. AWSアカウントを用意し、使う人ごとのIAM（AWSの中での権限の設定）を決める
  2. Bedrockのモデルを使えるようにする。AWS Marketplaceの購読に必要なIAMの権限と支払方法を用意し、Anthropicのモデルは初回利用のフォーム（利用目的とWebサイトのURL）を出す
  3. CrewAI・LangGraph・Strands Agentsなどのフレームワークでエージェントを作る
  4. 作ったエージェントをRuntimeにデプロイする（載せて動く状態にする）
  5. GatewayとIdentityで、社内システムや社員のログインとつなぐ
  6. Policyで止める規則を書き、Observabilityで動きを監視する
  7. Evaluationsで品質を確かめ、必要に応じて直す

2つ目の段階について、AWSのドキュメントでは、多くのモデルは正しいAWS Marketplaceの権限があれば既定で使える状態になっていて、初回の呼び出しで購読が自動で始まると説明されています。購読の開始には最大15分ほどかかる、という注意も同じページにあります。Anthropicのモデルを使う場合は、呼び出す前に初回利用のフォームを出す決まりで、アカウントごと、または組織の管理アカウントで1回の手続きになります。第三者のモデルは、初回の利用でEULA（利用許諾の契約）に同意したものとして扱われる点も、会社としては見落とせません。

契約の条件に同意する手続きが開発者の操作の中で自動的に進んでしまうので、誰が同意してよいのかを先に社内で決めておきましょう。3つ目から先は、エージェントの設計とプログラムの作成そのものなので、開発の経験がある人の手が要る段階になります。情シスの方が自分で手を動かすのか、外部に頼むのかは、この段階に入る前に決めておくのがよいでしょう。

開発者に任せる部分と、会社が押さえておく部分

手順の多くは開発者の仕事ですが、会社として押さえておきたい場面は限られます。AWSアカウントの持ち主を会社にしておくこと、支払方法を会社の管理の下に置くこと、規約への同意を誰がするかを決めることの3つは、開発を外部に頼む場合でも会社の側に残しておく必要があります。アカウントの持ち主が開発会社のままだと、契約を終えたときにエージェントや記録を引き取れなくなるおそれも出てきます。最初の打ち合わせで、アカウントを誰の名義で作るかを確かめておきましょう。

自社でエージェントを作るときに、会社が決めること・担う役割

AgentCoreで自社のエージェントを作るなら、部品を選ぶ前に、何を任せるか、誰が作り誰が守るかを会社として決めておく必要があります。決めずに作り始めると、作った後の直しや止める判断を誰もできない状態になってしまいます。次の項目を、社内の打ち合わせでひとつずつ確かめてみてください。

会社が決めること

  • 任せる仕事の範囲どの業務の、どの手順までをエージェントに任せ、どこから人が確認するかを決めます。
  • 触らせる社内システムとデータGatewayの向こうに置くシステムと、読ませてよい資料・読ませない資料を分けます。
  • 権限の分け方部署や役職ごとに、使えるエージェントや触れるデータをどう分けるかをIdentityの設定に落とします。
  • 止める規則してはいけない操作を、Policyの規則としてどう書くかを決めます。規則は自然言語でも書けます。
  • 記録の見方と見直しの間隔Observabilityの記録を誰が、どのくらいの間隔で見るかを決めます。
  • 使うモデルと推論方式どのモデルを、Geo（JP）とGlobalのどちらで呼ぶかを決めます。データを国内に留めたいかどうかで答えが変わります。
  • 記憶の残し方Memoryに何を残し、いつ消すかを決めます。保存の量は料金にも響きます。
  • 費用の通知と上限の考え方AWSの予算の通知を誰が受け、超えたときにどうするかを決めます。AWSのドキュメントによると、AWS Budgetsの情報の更新は1日に最大3回で、通知のあとも費用は動くことがあります。
  • 規約への同意の判断モデルの初回利用の同意や、Anthropicのモデルのフォームを誰の判断で出すかを決めます。

担う役割

  • エージェントを設計する人任せる仕事の手順と、AIへの指示文を決めます。
  • プログラムを作る人フレームワークでエージェントを作り、Runtimeに載せます。
  • AWSの環境を管理する人IAMの権限、使うリージョン、費用の通知を設定します。
  • 社内システムをつなぐ人GatewayやIdentityで、既存のシステムやログインの仕組みとつなぎます。
  • セキュリティを確かめる人触らせるデータ、残す記録、止める規則が社内のルールに合っているかを見ます。
  • 運用と問い合わせの窓口社員からの質問や不具合の連絡を受け、直す段取りをつけます。

1人で複数の役割を兼ねることもできますが、作った人しか中身が分からない状態は避けたいところです。役割を並べてみると、情シスの担当が少ない会社ほど、エージェントを作ること自体より、作った後に守り続けることのほうが重くなると分かってきます。人件費や開発の期間は作るものと頼み方で大きく変わるため、見積もりは具体的な業務を決めてから取るようにしましょう。決めた内容を1枚の文書にまとめ、作る人と守る人の両方が見られる場所に置いておけば、担当が替わったときにも引き継げます。

外部の開発会社にAgentCoreでの開発を頼むときに確かめたい質問

開発を外部に頼む場合は、技術の細かな話が分からなくても、次の質問への答えを書面でもらっておくと、あとで困る場面を減らせます。答えがあいまいなまま進めると、作った後の費用や責任の分かれ目が見えないまま契約することになってしまいます。打ち合わせの前に、この一覧を先方へ送っておきましょう。

  • どの部品を使う設計ですか13のサービスのうち何を使い、それぞれ毎月どのくらい使う見込みかを聞きます。
  • AIモデルは何を、どの推論方式で呼びますかモデルの名前と、Geo（JP）かGlobalかを確かめます。データを国内に留めたい場合は、ここが条件になります。
  • 毎月の費用の見積もりに、何が入っていますかAgentCoreの料金、モデルの料金、CloudWatchの料金、保守の費用が分けて書かれているかを見ます。
  • 社員が使う画面は誰が作りますかAgentCoreには社員向けの画面がないため、画面とログインをどう用意するかを確かめます。
  • 権限と止める規則はどう決めますかIdentityの設定とPolicyの規則を、誰がどの資料をもとに決めるかを聞きます。
  • 記録はどこに残り、誰が見られますかObservabilityの記録が残る場所と、会社の側で見られる人を確かめます。
  • 作った後の保守はどこまで含まれますかモデルの入れ替え、不具合への対応、部品の更新への追随の範囲を聞きます。
  • 担当者がいなくなったとき、誰が直せますか設計の資料や手順書が、会社の手元に残る形になっているかを確かめます。
  • 東京リージョンで使えない機能を使いますかPaymentsなど東京で使えない機能を使う場合、どのリージョンに置くかを聞きます。
  • AWSアカウントは誰の名義で作りますか契約を終えたあとも、エージェントと記録を会社が引き取れる形かを確かめます。

質問に答えるのは開発会社の仕事ですが、答えを読んで決めるのは会社の側です。分からない答えが返ってきたときは、そのまま進めず、もう一度説明を求めてみてください。やり取りを残しておけば、担当が替わったときの引き継ぎにもそのまま使えます。

AgentCoreが担う部分と、使う側が決める部分

セキュリティの面では、AgentCoreが仕組みとして用意している部分と、使う会社が決めなければならない部分がはっきり分かれます。社内で説明するときは、この境目を最初に共有すると話がかみ合いやすくなります。

AgentCoreが仕組みとして用意しているもの

  • セッションごとに分離された実行環境（Runtime）
  • 既存のIdPとつなぐ認証と権限の仕組み（Identity）
  • ツールを呼ぶ前に規則で止める仕組み（Policy）
  • 各ステップを追跡する記録と監視（Observability）
  • 隔離された環境でのコード実行と、クラウド上のブラウザでのWeb操作（Code Interpreter・Browser）

使う会社が決めること

  • 入力してよいデータと、いけないデータの線引き
  • 誰に、どのエージェントと、どのデータを使わせるか
  • 記録を誰が見て、何を見つけたら止めるか
  • どのモデルを、どの推論方式で呼ぶか
  • 社員への説明と、使い方のルール

Policyで止める規則の例

Policyの規則は自然言語でも書けるため、社内規程の言葉に近い形で決めておくことが出来ます。たとえば、次のような規則が考えられます。

  • 支払いの確定や振込の指示は、エージェントには実行させない
  • 社外へのメールの送信は、担当者が確かめてからにする
  • 個人情報を含む資料を読めるのは、決められた部署の依頼のときだけにする
  • 取引先のWebサイトでの操作は、決められたサイトの決められた画面だけにする

ここに挙げたのは考え方の例で、実際の書き方は開発者とすり合わせることになります。規則を決める打ち合わせには、情シスだけでなく、その業務を受け持つ部署の方にも入ってもらいましょう。

データの扱いについてAWSが書いていること

Bedrockについて、AWSのよくある質問では、入力も出力もAmazon NovaやAmazon Titan、第三者のモデルの学習には使わないと説明されています。日本語の同じページにも、お客様のコンテンツが基本モデルの改善に使われることはなく、モデルの提供元と共有されることもない、という趣旨の記載があります。Bedrockのデータ保護のドキュメントでは、モデルが置かれたアカウントにモデルの提供元は入れないため、Bedrockのログや顧客のプロンプトと回答にも触れられない、とされています。

一方、AgentCoreのドキュメントには、サービスの使い勝手や性能を良くするために、AgentCoreがお客様のコンテンツを使ったり保存したりすることがある、という一文があります。同じ一文で、その改善はその会社のAgentCoreの利用のためのもので、ほかの顧客のためではないと添えられています。Bedrockの学習に使わないという説明と、AgentCoreのこの一文は別のものとして読む必要があります。モデルによっては安全や不正利用の防止のためにデータを保持するものもあり、AWSのデータ保持のページでは、既定ではそのモデルの保持の方針が適用されると説明されています。使うモデルごとの条件を、契約の前に一覧にしておくと安心でしょう。

社員にAIを配るだけなら、AgentCoreは要るのか｜判断表

社員にチャットのAIを使わせることが目的であれば、AgentCoreは多くの場合、必要ありません。AgentCoreは、社内の業務に合わせたエージェントを自社で作り、動かし続けたい会社のための部品です。やりたいことの種類ごとに、向いている方法を並べると次のようになります。

  • 社員全員に、質問・要約・文章作成に使うAIを配りたい完成品の法人向けAIサービスを契約する方法が近道になります。画面・ログイン・利用ログ・権限の管理が最初からそろったものを選べば、作る手間がかかりません。
  • 社内の特定の業務を、道具を使って自動で進めるエージェントにしたいAgentCoreで自社のエージェントを作る候補になります。作る人と守る人を、社内か外部に用意できることが前提です。
  • AWSの上に、自社専用のチャット画面を持ちたいAWSがGitHubで公開しているサンプル（GenU）のように、自社のAWSアカウントに業務向けのチャットを組み立てる方法もあります。料金は使った分の従量で、構築と保守は自社の仕事になります。
  • 社員が個人のアカウントで使うのに任せている会社から利用の中身が見えず、入力したデータの条件も確かめられないため、早めに会社の環境へ移したい状態です。
  • 社外の取引先や顧客が使う窓口にAIを置きたい社員向けの配布とは別の話になり、AgentCoreで作るエージェントの候補になります。画面・認証・記録の作り込みが要るため、開発の体制を先に考えることになります。
  • 一部の部署でエージェントを試したい全社への配布とは分けて考え、配布は完成品で、試作はAgentCoreで、と並べて進める形もあります。

社員に配る道具と、業務を自動で進めるエージェントは、同じ生成AIの話でも求めるものが違います。前者は全員がすぐに使えることと管理のしやすさ、後者は業務に合わせた作り込みが決め手になります。まず全員に配る環境を整え、そのあと効果の大きい業務からエージェントを考えるのが、無理のない順番になるでしょう。社員が個人のアカウントで使い始めている会社は、野良AI（シャドーAI）の対策として、配る環境を先に決めましょう。

AWSのAmazon Q Businessも、AWSのドキュメントによると新しい利用者の受付を終えていて、近い機能としてAmazon Quickが案内されています。AWSの上で何を選ぶにしても、新しい受付を続けているサービスかどうかを先に確かめておきたいところです。

AgentCoreが向いている会社・急がなくてよい会社

AgentCoreが向いているのは、自動で進めたい業務がはっきりしていて、作る人と守る人を用意できる会社です。反対に、まだ社員の多くがAIを使っていない段階であれば、急いで検討しなくても困ることは少ないでしょう。

向いている会社

  • 自動で進めたい業務と、任せる範囲がはっきりしている
  • すでにAWSを使っていて、IAMや費用の通知を管理できる担当がいる
  • 社内システムにAPIがあり、Gatewayでつなげる見込みがある
  • 作った後の保守を、社内か外部の決まった相手に任せられる

急がなくてよい会社

  • 社員の多くがまだAIを使っておらず、まず使い慣れるところから始めたい
  • やりたいことが、質問・要約・文章作成などのチャットの使い方に収まっている
  • 情シスの担当が少なく、作った後に守り続ける人を決められない
  • 社員が個人のアカウントでAIを使っていて、先に利用の実態をつかみたい

急がなくてよい会社でも、エージェントの考え方を知っておくことは無駄になりません。まずは全員がAIを使える環境で慣れてもらい、その中で手間のかかる仕事を集めていくと、エージェントに任せる候補が自然に見えてきます。候補の仕事がそろった段階でAgentCoreを検討する順番でも、遅くはないでしょう。

会社で安全に使うには｜学習させない設定・ログ管理・社員への配布・複数AIの使い分け

会社でAIを安全に使うには、学習に使わせない設定、利用ログの管理、社員への配り方、複数のAIの使い分けの4つを、仕組みとして会社の側でそろえることが出発点になります。

学習させない設定を、全員に同じ形でかける

入力したデータがAIの学習に使われるかどうかは、使うサービスや契約の形で条件が変わります。社員が自分で設定を切り替える方式では、設定を忘れる人が1人でもいれば、その人の入力は会社の管理の外に出てしまいます。会社の側で全員に同じ条件をかけられるかを、最初に確かめておきたいところです。AgentCoreで作る場合は、Bedrockの学習についての説明、AgentCoreのドキュメントにあるコンテンツの使い方の一文、使うモデルごとの保持の方針を、すべて確かめたうえで社内に説明することになります。完成品のサービスであれば、学習に使わない設定が全員に一律でかかるかどうかを、契約の前に聞いてみてください。

利用ログを会社が見られるようにする

誰が、いつ、どのAIを、どう使ったかを会社が見られなければ、問題が起きたときに経緯をたどれません。AgentCoreで作るならObservabilityとCloudWatchで記録を残す作りになり、記録を見る画面や見る人も自社で決めることになります。完成品のサービスを選ぶ場合は、管理者が利用ログを一覧で見られるか、書き出せるかを確かめてみてください。

社員への配り方を決める

一部の社員にだけ配ると、配られなかった社員が個人のアカウントで使い始め、会社から見えない利用が生まれやすくなります。人数で費用が増える形だと、全員に配るのをためらう理由にもなりがちです。費用の管理の考え方は生成AIのコスト管理で、点検したい項目は生成AIのセキュリティ対策チェックリストで整理しています。

使いすぎを止める仕組みを決める

従量で払う仕組みは使った分だけで済む反面、想定を超えて使われたときには費用が増えてしまいます。AWSのドキュメントによると、AWS Budgetsの情報は1日に最大3回の更新で、通知を受けたあとも費用は増えたり減ったりすることがあります。自社で作る場合は、通知を受ける人と、超えそうなときに止める手順をあらかじめ決めておく必要が出てきます。完成品のサービスを選ぶ場合も、利用量の上限に達したときにどうなるのかを、契約の前に確かめておくのが安心でしょう。

社員に説明するルールを決める

仕組みをそろえても、入力してよい情報といけない情報の線引きは、社員への説明がなければ守られません。顧客の個人情報や公開前の数字など、入力の前に立ち止まってほしい情報を、具体的な例と一緒に示すのが分かりやすいでしょう。ルールの作り方は生成AIの社内ガイドラインで整理していますので、社内向けの文書を作るときの下書きに使ってみてください。

複数のAIを使い分けられるようにする

AIモデルは提供元ごとに得意なことが分かれていて、新しいモデルも次々に出てきます。1つのAIに決めて契約すると、別のAIの方が向いている仕事が出てきたときに、また契約と設定をやり直すことになってしまいます。AgentCoreがどのモデルとも組み合わせられる作りになっているのも、モデルを入れ替えながら使う前提があるからと見ることが出来ます。社員に配る環境でも、複数のAIを1つの画面で切り替えられるかを、選ぶ条件に入れておくとよいでしょう。複数のAIをまとめて使う考え方はマルチAIの記事で、AIごとの向き不向きは4つのAIの使い分けで扱っています。

エージェントを作る前に、4つのAIを社員全員へ

UPGEAR AIは、ChatGPT・Claude・Gemini・Perplexityを1つの契約・1つの画面で使える法人向けサービスです。会話の途中でもモデルを切り替えられ、管理者ダッシュボードで利用ログ・権限・モデルのON/OFFを管理出来ます。自社の資料を読み込ませて答えさせる社内文書RAGや、よく使う指示と手順をBOTにして社内限定で共有できるカスタムプラスも備えています。基盤はAWSの日本リージョンで稼働しています。料金は月額30,000円（税抜）から。どのプランも利用人数は無制限で、料金は利用量に応じたプラン設計です（人数の目安はライト1〜5名、スタンダード6〜20名、プレミアム21〜50名）。初期費用100,000円（税抜）が別途かかります。

UPGEAR AIの詳細を見る

よくある質問

Amazon Bedrock AgentCoreは無料で使えますか？
前払いや最低料金はなく、使った分だけの従量課金です。新しくAWSを使い始める方には最大200ドル分の無料枠のクレジットがありますが、AWS全体の新規向けのもので、AgentCore専用の無料枠ではありません。料金は米ドルで表示され、AIモデルを呼ぶ料金は別にかかります。
Bedrock AgentsとAgentCoreは何が違いますか？
Bedrock Agentsは現在Bedrock Agents Classicという名前になり、AWSのドキュメントによると新しい利用者の受付を終えています。同じページには、近い機能を求めるならAgentCoreを、という案内があります。AgentCoreは、実行環境・記憶・道具の接続・認証・監視などの部品を選んで組み合わせ、エージェントを作って動かすための仕組みです。
AgentCore Identityとは何ですか？
エージェントが誰として、どの権限で動くかを管理する部品です。AWSによると、Cognito・Okta・Microsoft Entra ID・Auth0などの既存のIdPと連携できます。料金はトークンやAPIキーの要求1,000回あたり0.010ドルで、RuntimeかGatewayを通して使う場合は追加の料金がかからないと料金ページに書かれています。
AgentCoreは東京リージョンで使えますか？
使えます。2025年10月の一般提供開始の時点で東京を含む9つのリージョンが対象になり、2026年10月14日時点のリージョン表では、東京で決済のPayments以外の主な機能が使えると表示されています。大阪はリージョン表に列がありません。モデルの推論がどこで処理されるかは、モデルの推論方式で別に決まります。
AgentCoreを使えば、社員がChatGPTのようにAIを使えますか？
AgentCoreには、社員が開いて使うチャット画面は含まれていません。開発者が自社のアプリや業務システムに組み込んで使う部品のため、画面・ログイン・権限・利用ログ・費用の管理は、自社で作るか別に用意する必要があります。社員に配ることが目的なら、それらがそろった完成品の法人向けAIサービスを選ぶ方法もあります。
社員100名で使うと、AgentCoreの料金はいくらくらいになりますか？
公式の計算例（1セッション0.006703ドル）と同じ前提で、社員100名が1日5回・月20営業日使うと月10,000セッションになり、Runtimeの部分だけで月67.03ドル、1ドル＝150円で計算した場合は約10,055円になります。モデルの料金、MemoryやGatewayなどの料金、開発と保守の費用は含まれていません。
AgentCoreに入力したデータは学習に使われますか？
Bedrockについては、入力も出力もモデルの学習に使わないとAWSのよくある質問で説明されています。一方でAgentCoreのドキュメントには、サービスの使い勝手や性能を良くするためにお客様のコンテンツを使ったり保存したりすることがあり、その改善はその会社の利用のためのもの、という一文があります。使うモデルごとのデータ保持の条件と合わせて確かめることをおすすめします。
AgentCoreはどのフレームワークやAIモデルで使えますか？
AWSによると、CrewAI・LangGraph・LlamaIndex・Strands Agentsなどのオープンソースのフレームワークや、どの基盤モデルとも組み合わせられます。Runtimeは、Bedrockの外にあるOpenAIのモデルやGoogleのGeminiなども使えるとドキュメントに書かれています。
AgentCoreのPolicyとは何ですか？
ツールを呼び出す前に、決めた規則で操作を止めるための部品です。AWSによると、規則は自然言語か、Cedar互換の言語で書けます。2026年3月に一般提供が始まり、料金は認可のリクエスト1回あたり0.000025ドルと料金ページに表示されています。
AgentCore GatewayとMCPはどう関係しますか？
Gatewayは、既存のAPIやLambdaを、MCPに対応したツールに変換する部品です。MCPはAIに外部の道具をつなぐための共通の規格で、Gatewayを通すと、社内のシステムをエージェントが使える道具として扱えるようになります。Salesforce・Zoom・JIRA・Slackなどとの連携も用意されています。
AgentCoreのエージェントは、どのくらい長く動かせますか？
製品ページでは、Runtimeで最大8時間の非同期タスクまで扱えると説明されています。Runtimeはセッションごとに分離された環境で動き、請求は1秒単位で計算されます。LLMの応答などを待つI/O待ちの間は、CPUの使用がゼロまで下がるとされています。
AgentCoreのMemoryの料金は変わりましたか？
料金ページによると、短期記憶の取り込みは2026年10月6日以降、1GBあたり1.00ドルです。それ以前は1,000イベントあたり0.25ドルという表示でした。取り出しや保存、長期記憶の料金は、それぞれ別に設定されています。
AgentCoreとBedrockの料金は別々にかかりますか？
AgentCoreの料金表には、AIモデルのトークン単価は載っていません。エージェントがBedrockのモデルを呼ぶ場合は、入力と出力のトークン数に応じたBedrockの料金が、AgentCoreの料金とは別にかかります。Bedrockの外のモデルを呼ぶ場合は、そのモデルの提供元の料金がかかります。
AgentCoreのWeb Searchの料金はいくらですか？
料金ページでは、Web Searchは1,000回の検索あたり7.00ドルと表示されています。2026年10月14日時点のリージョン表では、Web Search Toolは東京でも使える機能として表示されています。
AgentCoreで作ったエージェントの品質は、どう確かめますか？
Evaluationsという部品で、エージェントの品質を自動で評価できます。料金ページによると、組み込みの評価は入力1,000トークンあたり0.0024ドル、出力1,000トークンあたり0.012ドルで、モデルの利用料が含まれています。自社で作る評価では、モデルの利用料が別にかかります。
AgentCore Harnessとは何ですか？
使うモデル、システムプロンプト、使わせる道具を指定すると、1回のAPI呼び出しでエージェントを動かせる管理型の仕組みです。AWSの発表によると、2026年6月に一般提供が始まっています。2026年10月14日時点のリージョン表では、東京でも使える機能として表示されています。
AgentCoreのObservabilityには、どんな料金がかかりますか？
AgentCoreの料金ページでは、ObservabilityはAmazon CloudWatchの料金に沿ってかかると書かれています。AgentCoreの料金表とは別に、CloudWatchの料金ページで確かめる必要があります。

まとめ

Amazon Bedrock AgentCoreは、AIエージェントを作って本番で動かし、運用するためにAWSが用意した部品群です。Runtime・Memory・Gateway・Identity・Observabilityなど13のサービスがあり、要るものだけを選んで組み合わせる形になります。料金は使った分の従量で、I/O待ちの間にCPUの料金がゼロまで下がる仕組みもありますが、AIモデルの料金は料金表に載っておらず、Bedrockの料金として別にかかります。

東京リージョンでは決済のPayments以外の主な機能が使え、大阪はリージョン表に列がありません。公式の計算例を社員100名に当てた試算では、Runtimeだけで月67.03ドル、1ドル＝150円で計算した場合は約10,055円となりました。ただ、AgentCoreは社員が使うチャット画面ではないため、社員に配るには画面・ログイン・権限・費用の管理まで自社で抱えることになります。社員にAIを配ることが目的なら完成品の環境から、業務を自動で進めたいならAgentCoreから、と目的で分けて考えてみてください。

会社として使うなら、学習に使わせない設定、利用ログの管理、社員への配り方、複数のAIの使い分けを、仕組みとしてそろえることが出発点になります。自社でエージェントを作る場合は、会社が決めることの一覧と開発会社への質問を、打ち合わせの最初に使ってみてください。

法人のAI活用に関するほかの記事はAI活用コラム一覧にまとめています。