ChatGPT dotsとAWS AgentCoreは何が違う？ AIエージェントを「買うか作るか」の技術選定ガイド
「ChatGPT dotsが使えるなら、AWS Bedrock AgentCoreでエージェントを作る必要はないのでは？」。逆に「AgentCoreを使っているから、dotsのような常時稼働エージェントは要らないのでは？」。この二つは似ているようで、比較の粒度が違います。dotsは利用者が仕事を任せるための完成済みエージェントサービス。一方、Amazon Bedrock AgentCoreは、開発者がエージェントを実行・接続・保護・評価・監視するためのマネージド基盤です。完成済みの業務アシスタントと、そのようなアシスタントを自分で作るための部品を、単純な機能数や月額だけで比較しても結論を誤ります。[1][2]
この記事では技術選定の立場から、両者の構造、責任分界、業務連携、運用、コストを並べます。どちらが「上位」かではなく、何を自社が設計・維持したいのかを判断するための整理です。
最初の結論：個人の仕事を継続して任せるならdots、業務システムを設計するならAgentCore
OpenAIが2026年9月29日に発表したdotsは、専用クラウドコンピューター、ブラウザー、接続済みアプリを使い、利用者との会話が途切れても目標に沿って作業を進める設計です。ChatGPTに加えてSlackやTeamsで連絡し、音声会話や、承認の必要な場面でのユーザーへの確認ができます。企業向けには、ワークスペースの機能制限とプラグインの権限管理があります。[1][3]
一方AWS公式は、AgentCoreのRuntime、Memory、Gateway、Identity、Observability、Evaluations、Browser、Code Interpreter、Policyなどを、開発・運用のための構成要素として提供しています。Strands Agentsのようなフレームワークを使う場合でも、オーケストレーターの判断、業務データモデル、失敗時の復旧方法、承認フローをどう組み合わせるかは、システムを作る側が設計します。[2][4]
したがって、比較の出発点は「チャットができるか」「ブラウザーが使えるか」ではありません。完成した働き方を使いたいのか、業務ごとの制御面を自分たちで持ちたいのかです。
アーキテクチャの責任範囲を並べる
dots側では、利用者が目標と前提を伝え、OpenAIの完成サービスとして提供されるdotに作業を任せ、許可したアプリ・クラウド作業環境と連携させます。利用者や管理者は権限・承認・結果確認に責任を持ちます。Enterpriseではdots自体の利用許可、ローカルPC接続、クラウドブラウザー・ネットワークなどを管理できます。これらの設定と、各アプリが持つ認可は別々に確認する必要があります。[3]
AgentCore側の参考構成なら、EventBridgeや既存のWeb APIからイベントを受け、業務固有のオーケストレーターが判断し、AgentCore Runtimeで動くエージェントがGateway経由で社内API・Lambda・業務アプリのツールを呼び出します。Identityで認証情報を扱い、Memoryで必要な状態を保持し、Observabilityで実行トレースを監視し、Evaluationsで期待する品質を測る設計が考えられます。ここで挙げたEventBridgeや業務承認DBの使い方は本記事の参考アーキテクチャであり、AWSが唯一の正解として規定するものではありません。
特に重要なのは認証と認可の差です。Gatewayの認証設定によっては、認証した呼び出しを下流へ転送するだけで、操作単位の認可をGateway自身が行わない構成もあります。AWS公式は、AUTHENTICATE_ONLYの場合、対象API側の認可かGatewayのPolicy Engineがなければ、認証済みの呼び出しがバックエンドへ到達しうると注意しています。「IAMを設定したから安全」と一言で片づけるべきではありません。[5]
図：BuyとBuildの責任分界（筆者作成。機能の一対一対応表ではありません）
Buy vs Build：技術的な判断軸
提供物：dotsは「利用者が使う完成エージェント」。AgentCoreは「エージェント開発・実行・運用部品」。
初期作業：dotsは「利用資格・接続・権限・使い方を設定」。AgentCoreは「プログラム、ツール、認証、業務状態、監査を設計」。
主な利用目的：dotsは「個人やチームの継続的な調査・作業支援」。AgentCoreは「業務プロセスに統合した専用エージェント」。
データ接続：dotsは「対応アプリと各接続権限に依存」。AgentCoreは「自社API・認証・データ基盤を開発者が接続」。
承認：dotsは「組み込みの安全確認とCustom Rules等」。AgentCoreは「Policy、ツール認可、承認UI・DBを組み合わせて設計」。
長期状態：dotsは「dotの文脈・記憶を製品機能として利用」。AgentCoreは「Memoryと必要に応じた業務DBの役割を定義」。
監視・評価：dotsは「サービスの提供するActivity等を利用」。AgentCoreは「ObservabilityやEvaluationsで計測系を設計」。
運用責任：dotsは「利用部門・管理者の統制とサービス提供者の役割を分ける」。AgentCoreは「実装・デプロイ・バージョン・失敗復旧を自社側で設計」。
コスト：dotsは「契約プラン、利用条件、深い作業の使用枠を確認」。AgentCoreは「推論・実行・メモリ・ツール・監視・評価・開発運用費を分解」。
これは仕様をもとに筆者が整理した比較表であり、ベンチマーク実測ではありません。dotsで業務システムの深い統合が一切できない、AgentCoreで個人秘書型のエージェントを絶対に作れない、という意味でもありません。
参考書籍：AgentCoreで何を自社実装するかを学ぶ
『AWSではじめるAIエージェント開発・運用』（掌田津耶乃著、日経BP）は、Amazon Bedrockの標準エージェントとAgentCoreを使ったコード実装の違い、SDK、デプロイ、ツール連携を学びたい人向けの入門書です。出版社の公式書誌・目次から内容を確認しました。dotsとの直接比較を扱う書籍という意味ではありません。価格・版・入手可能性は販売ページでご確認ください。
この本が向く人・見送ってよい人：AgentCoreのRuntimeやGatewayをコードで組み、権限・監視・失敗復旧を検証したいエンジニア向けの補助教材として選びました。単にdotsの利用操作を知りたい人には内容が遠回りになる可能性があります。AWS公式Developer Guideで小さなPoCを進められるなら、先に必要な機能を絞り込んでから書籍の購入を判断する方が合理的です。
PR｜書籍の購入リンク
AWSではじめるAIエージェント開発・運用（紙版・Amazon）
あわせて、エージェント開発・設計に関する別の書籍も比べたい方は、Book Media Techの技術書ガイドを参照できます。これは学習テーマを比較するための補助導線です。
「常時稼働」と「常に課金」は同義ではない
エージェントのTCOを見積もるとき、24時間利用可能なことと、24時間CPUを占有し続けることを混同しがちです。AgentCore RuntimeはCPUとメモリなどの実際のリソース消費をベースにした料金体系を用意しており、v1と新しいv2では料金・計測の前提が異なります。AgentCore Memoryの短期メモリについては、2026年10月6日からイベント件数方式からデータの取り込み・取得・保管量ベースへ変更されています。日本語の料金ページと英語の最新料金表で反映内容に差が見える場合があるため、見積もり時は利用リージョンと選んだRuntime世代、最新の公式料金表を固定してから計算すべきです。[6][7]
最低限、次の五つに分けて考えます。①モデル推論費、②Runtime/Browser/Code Interpreterの実行費、③Gateway/APIやMemoryの利用費、④CloudWatchなどの観測・評価費、⑤開発・運用・障害対応の人件費。月額を出すなら、業務イベント数、セッション継続時間、CPUのアクティブ時間、メモリ使用量、外部API回数、モデル入出力トークン、失敗再試行率を入力として積み上げます。初期工数を無視して「従量課金だから安い」と判断するのは危険です。
dots側も、最初のdotが対象のPro／Business Premiumプランに含まれることと、Codex・ChatGPT Workへ依頼した深い作業の利用枠が別途消費されることを分ける必要があります。Enterpriseの提供条件や利用可能地域、プランの対象は変わり得るため、公開当日の公式案内で再確認します。[1][8]
実務の三つの判断ケース
ケースA：部門リーダーの仕事の整理、調査、資料下書き。 社内ルールで利用が許され、必要なアプリと権限が接続可能なら、まずdotsでどの程度仕事が進むか試すのが合理的です。評価するのは「AIに質問した回数」ではなく、成果物の採用率、再指示回数、承認待ち時間です。規制情報や社内機密の取り扱いは管理者の方針を優先します。
ケースB：在庫・生産・販売などの業務システムに連動し、処理権限を厳格に分離する。 例えば「在庫不足を発見したら補充案を作るが、発注書確定は担当者が承認する」なら、業務DBとトランザクション、在庫・権限・承認の整合性を決める必要があります。既存基盤がAWSにあり、API境界を自社で定義したいならAgentCoreは有力候補です。ただし、AgentCoreを選んだだけで業務設計やデータの正しさが保証されるわけではありません。
ケースC：全社でのAI利用と専用業務エージェントが併存する。 これは二者択一にしない方が自然です。個人の調査や資料準備はdotsに任せ、会社のコア業務を更新する専用ワークフローはAgentCore等のシステム基盤で制御する、という住み分けも考えられます。両者を直接接続する特定の公式統合方式を本稿では確認していません。存在するものとして設計図に描かず、必要なら別途検証します。
小さなPoCで確認する7項目
技術選定前に、同じ業務課題を使って次をテストしておくと、機能紹介に流されにくくなります。①使うデータに最小権限でアクセスできるか、②人間が承認するまで書き込みが止まるか、③根拠が古い・欠けているとき停止できるか、④途中失敗の再実行で二重更新しないか、⑤第三者が操作と判断を追跡できるか、⑥処理時間と再指示を実測できるか、⑦全費用を漏れなく追跡できるか。これらは製品の標準性能を示す数値ではなく、採用検証のチェックリストです。
結論：AIに何をさせるかではなく、どこを自社の責任にするか
AIエージェントが仕事を継続する時代には、開発者が作るものも変わります。プロンプトの賢さだけでなく、権限とツールの境界、業務状態、失敗の検出、停止と復旧、効果の観測が中心になります。dotsは完成した継続エージェントを使い始める選択肢であり、AgentCoreはそれらの制御面を自社の業務に合わせて組み立てる選択肢です。どちらにも万能の答えはなく、「自分たちが責任を持つ必要のある差分」が大きくなるほど、Buildの合理性が増すと考えます。
企業への展開を検討する際には、使い勝手だけでなく、人が取り戻せる制御権と責任を先に設計することが重要です。企業でのdots導入を詳しく扱う別記事へのリンクは、両記事の公開URLが確定してから追加します。
出典と条件
[1] OpenAI（2026-09-29）Introducing dots https://openai.com/index/introducing-dots/ [2] AWS AgentCore公式 https://aws.amazon.com/bedrock/agentcore/ [3] OpenAI Help, Manage dots in ChatGPT workspaces https://help.openai.com/en/articles/20001554-manage-dots-in-chatgpt-workspaces [4] AWS, AI agents in enterprises: Best practices with Amazon Bedrock AgentCore https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/ [5] AWS AgentCore Gateway inbound authorization https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html [6] AWS AgentCore pricing（英語）https://aws.amazon.com/bedrock/agentcore/pricing/ [7] AWS（2026-10-12）短期メモリ従量料金の発表 https://aws.amazon.com/jp/about-aws/whats-new/2026/10/agentcore-memory-consumption-based-pricing/ [8] OpenAI Help, Getting started with your dot https://help.openai.com/en/articles/20001530-getting-started-with-your-dot [9] 出版社書籍情報 https://bookplus.nikkei.com/atcl/catalog/26/03/12/02522/
※Amazonのアソシエイトとして、light_arnica2159は適格販売により収入を得ています。
