本記事は、オリックス株式会社 法人営業本部 デジタル戦略推進室様と AWS が共同で執筆しました。 AI エージェントが実務で使われ始め、「既存の API を、エージェントから使えるようにできないか？」と考えたことがある方も多いのではないでしょうか。 本記事は、オリックス株式会社が提供する SaaS「 PATPOST 」の既存 REST API を、 Amazon Bedrock AgentCore Gateway で MCP サーバー化した事例です。 既存資産に手を入れずに MCP サーバー化するところまでは短時間で到達できた一方、「ユーザーごとにレスポンスが変わる API で、認証認可情報をどう引き回すか」「エージェントにとって本当に効果的なツールとは何か」という議論に発展しました。 本記事がオリックス様と同じように既存 API 資産を AI エージェントへ提供しようとしている方の参考になれば幸いです。 なお、本記事で紹介する MCP サーバーは検証（PoC）として実装したものであり、本稿執筆時点では一般提供しておらず、提供に向けた準備を進めている段階です。 背景：なぜ PATPOST を MCP サーバー化しようと考えたのか はじめに、 PATPOST がどのようなサービスかをご紹介します。 PATPOST は、オリックスが 2023 年 5 月から提供している、生成 AI を活用したビジネス文書管理サービスです。 スキャンした紙文書や PDF を AI-OCR と生成 AI でデータ化し、抽出した情報をセキュアな環境で一元管理できます。 お客様の社内システムと連携するための REST API を公開しており、蓄積した文書データを業務システムから直接活用できることも特徴です。 MCP サーバー化に取り組んだ動機について、PATPOST のテックリードである牧野様に伺いました。 PATPOST が MCP サーバー化に取り組んだのは、SaaS の使われ方が変わりつつあるという実感があったからです。 国内の SaaS 事業者からも MCP サーバーの公開が相次いでおり、AI エージェントから呼び出せることは、 この先の SaaS に求められる要件になっていくと考えました。だとすれば、自分たちの機能をエージェントから使えるようにするには何が必要になるのか、机上で整理するのではなく、実際に動かして確かめておきたい。それが出発点でした。そうした検討を進める中で、AWS の担当者から Amazon Bedrock AgentCore Gateway を使えば既存の API 資産を活かしたまま MCP サーバー化できるというご提案をいただき、検証を開始しました。 既存 API を改修せずに MCP サーバー化 今回は PoC という位置づけのため、既存資産に大きな改変を加えずに試したいというご要望がありました。 そこで、すでに外部公開している REST API を活かす方法を採りました。 AgentCore Gateway の「 OpenAPI Target 」に OpenAPI 定義を登録すると、既存 API の各エンドポイントがそのまま MCP ツールとして公開されます。つまり、既存の REST API と、その OpenAPI 定義があれば MCP サーバー化することができます。今回はこの方法を採用しました。 認証認可に関する考慮 PATPOST の API は、ログインしている利用者ごとに、その人が見てよいデータだけを返します。 利用者は API キーで識別されます。 今回は PoC のため既存資産に大きな改変は加えない方向で検討し、PATPOST がすでに利用している Amazon Cognito と、利用者ごとの API キーを活かして、認証認可情報をバックエンドまで届けることとしました。 全体像は次の図のとおりです。 リクエストは次の流れで処理されます。 MCP クライアントが認証なしで呼び出すと、AgentCore Gateway はリクエストを受け付けず 401 レスポンスを返します。 MCP クライアントは、401 レスポンスの WWW-Authenticate ヘッダーに示されたエンドポイント （.well-known/oauth-protected-resource）からメタデータを取得し、 認可サーバー（Amazon Cognito）の URL を得ます。（RFC 9728） これを受けて MCP クライアントは Amazon Cognito の認可フローを開始します。 利用者がブラウザでログイン・同意すると、MCP クライアントはアクセストークンを取得します（OAuth 3LO）。 クライアントは取得したアクセストークンを付けて呼び出し直します。 AgentCore Gateway は Cognito が発行したトークンを検証します。 検証済みトークン（JWT）から利用者 ID を取り出します。 その利用者に対応する API キーを Amazon RDS から取得します。 取得した API キーを、バックエンドへ送るリクエストのヘッダに付与します。 このうち 6 から 8 で用いているのが、2025 年 11 月に提供が始まった AgentCore Gateway の Interceptor です。Interceptor は、AgentCore Gateway に届いたリクエストをバックエンドへプロパゲーション（伝搬）する前に、 独自の処理を差し込める仕組みです。 なお、Interceptor がリクエストの内容（ Authorization ヘッダ＝JWT）を読み取れるようにするには、 AgentCore Gateway 側で受信ヘッダを Interceptor へ渡す設定（ passRequestHeaders ）を有効にしておく必要があります。 この結果、PATPOST 側は「利用者本人から呼ばれた」のと同じ形でリクエストを受け取れます。 既存資産には手を入れず、利用者ごとのデータの出し分けを保ったまま MCP サーバー化することができました。 残る論点 この構成には、既存資産を活かせること以外にも利点があります。バックエンドへ渡す認証情報（API キー）を Interceptor の中で組み立てているため、認証情報がエージェントの実行環境やモデルのコンテキストに乗りません。 プロンプトインジェクションなどでモデル側から認証情報が漏れる経路を作らずに済みます。 また、この構成では、インバウンド認証で受け取った JWT をそのまま下流へ渡していません。 インバウンドの JWT は AgentCore Gateway を宛先として発行されたトークンであり、 これをそのまま下流 API に渡す（token passthrough）と、必要以上の権限を持つトークンの流用や権限昇格を招く、 いわゆる confused deputy 問題につながります。 MCP の認可仕様 でも、MCP サーバーがクライアントから受け取ったトークンをそのまま背後の API に渡してはならない（MUST NOT）とされています。今回は JWT を下流に流さず、AgentCore Gateway の内側で利用者ごとの API キーに置き換えているため、この問題を避けられています。 一方で AgentCore Gateway には、 アウトバウンド認証 の仕組みとして IAM・API キー・OAuth といった方式が用意されており、OAuth のグラントタイプの 1 つとして OBO（On-Behalf-Of トークン交換） も選択できます。ただし、アウトバウンド認証の API キーはターゲットに 1 つのキーを紐付ける方式のため、PATPOST のように利用者ごとに異なる API キーを使い分けることはできません。利用者ごとの最小権限のクレデンシャルを下流に渡すなら OBO が候補になりますが、その場合はバックエンド側が交換後のトークンを受け取って検証する対応が必要になります。今回は本体に手を入れない方針だったため、先述の構成を採用しました。 オリックス様コメント 最後に、今回の取り組みについて牧野様よりコメントをいただきました。 PATPOST では約 2,300 社（※）のお客様の文書をお預かりしているため、「誰がどのデータを見てよいか」という境界を保つことを最優先にしています。 人が画面から使う場合、ログインしている本人が誰かは分かります。しかしエージェントがユーザーの代わりに API を呼ぶようになると、この情報が途中で失われてしまいます。 今回の検証では、PATPOST 本体に手を入れないという方針のもとで、すでに利用している Cognito と利用者ごとの API キーを活かし、この課題を解決できました。 今後もこの前提を守りながら、MCP を活用したプロダクトの展開を進めていきたいと考えています。 ※ 2026 年 8 月 31 日時点 エージェントにとって「効果的なツール」 ここまでで、既存の REST API に手を入れることなく、そのまま MCP ツールとして公開できました。ただ、API をそのまま 1 対 1 でツールにすることが、エージェントにとって最適とは限りません。REST API は、リソース単位の細粒度な操作を提供し、それらをクライアント側で組み合わせて目的を達成する設計が一般的です。例えば「一覧を取る → ID を指定する → 詳細を取る」といった呼び出しの連鎖です。この粒度のまま MCP ツールとして公開すると、エージェントによる呼び出しの往復が増え、その分だけ消費するトークンやコンテキストも膨らみます。 AgentCore Gateway の Target にできるのは OpenAPI 定義だけではありません。独自の処理を実装した AWS Lambda 関数も Target にすることができます。Lambda Target を使うとバックエンドの API にもエージェント側にも手を入れずに、ツールを設計し直すことができます。たとえば、複数回に分かれた呼び出しを 1 つのツールにまとめる、返ってくるデータをエージェントが読みやすい形に整える、よく使う操作を「1 つの意図 ＝ 1 つのツール」として提供する、といった形です。 PATPOST の API の形を模したモックバックエンドを用意し、「対象期間の請求書の合計金額を算出する」というタスクで、OpenAPI Target と Lambda Target の 2 つの構成を比較したところ、 Lambda Target では消費トークンと呼び出しの往復回数は大幅に削減され、処理時間も短縮されました。 PATPOST でも公開に向けて、適切なツール設計を意識して取り組むこととなりました。 まとめ 今回は、オリックス株式会社が提供する SaaS「PATPOST」の既存 REST API を、Amazon Bedrock AgentCore Gateway で MCP サーバー化する取り組みを振り返ってきました。分かったことを、あらためて 3 つに整理します。 まず、「MCP サーバー化する」ことは、既存の資産に手を加えずにマネージドに実現できました。既存の REST API とその OpenAPI 定義さえあれば、OpenAPI Target に登録するだけで各エンドポイントがそのままエージェントのツールになります。 次に、認証認可の観点です。PATPOST は利用者ごとにデータを出し分ける設計のため、既存の Amazon Cognito と利用者ごとの API キーを活かし、Interceptor の中で認証認可情報を API まで届けています。 この手作りの部分を、OBO のような標準的な仕組みにどこまで寄せられるかは、引き続き検討していきたいテーマです。 そして、API をそのまま 1 対 1 でツールにするのが、エージェントにとって最適とは限りません。 Lambda Target や Interceptor を使えば、バックエンドの API にもエージェントにも手を入れずに「ツールの呼び出し方」を設計し直せます。 本記事が、皆様のエージェント利活用の参考になれば幸いです。 参考リンク Model Context Protocol — Authorization: Security Considerations Using interceptors with Gateway Interceptor の設定（passRequestHeaders の挙動） Set up outbound authorization for your gateway On-behalf-of token exchange with AgentCore Identity Apply fine-grained access control with Bedrock AgentCore Gateway interceptors Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway 著者について 牧野 友 / Yu Makino オリックス株式会社 法人営業本部 デジタル戦略推進室。ビジネス文書管理サービス「PATPOST」のテックリード。社内の開発チームとパートナー企業と協働しながら、 AWS 上でのアーキテクチャ設計・開発・運用を担当している。 生成 AI の実務適用に関心がある。 鯨田 連也 アマゾン ウェブ サービス ジャパン合同会社の AI Specialist Solutions Architect として、 日本における Amazon Bedrock AgentCore の技術支援をリードしており、業界を問わず様々なお客様とともに、Agent の開発、Agent 基盤の設計、LLM のファインチューニングに 取り組んでいます。AWS 入社前は、データサイエンティストとして深層学習モデルの開発や Agent を活用したソリューションの構築に従事していました。 2025年度に Japan AWS Top Engineer および AWS Community Builder に選出。 池田 優 / Yu Ikeda アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 金融領域のお客様を中心にご支援しています。

本ブログは 2025 年 10 月 31 日に公開された AWS Blog “ Build reliable AI systems with Automated Reasoning on Amazon Bedrock – Part 1 ” を翻訳したものです。 規制産業の企業では、すべての AI 応答が定められたポリシーとドメイン知識に準拠していることを、数学的な確実性をもって示すことがしばしば求められます。こうした業界では、AI 出力の統計的なサンプルだけをテストしてコンプライアンスを確率的に主張する従来の品質保証手法は使えません。AWS は、AWS re:Invent 2024 において Amazon Bedrock Guardrails の自動推論チェック (Automated Reasoning checks) をプレビューとして提供開始しました。この機能は、形式的検証の技術を適用し、エンコードされたビジネスルールとドメイン知識に照らして AI 出力を体系的に検証するという、新しい解決策をもたらしました。これらの技術により、検証結果は透明性が高く説明可能なものになります。 自動推論チェックは、さまざまな業界のワークフローで活用されています。金融機関は、AI が生成した投資アドバイスが規制要件を満たしていることを数学的な確実性をもって検証しています。医療機関は、患者向けのガイダンスが臨床プロトコルに沿っているかを確認しています。製薬企業は、マーケティング上の主張が FDA (米国食品医薬品局) 承認のエビデンスで裏付けられていることを確かめています。公益事業会社は災害時の緊急対応プロトコルを検証し、法務部門は AI ツールが必須の契約条項を漏れなく反映しているかを検証しています。 自動推論チェックの 一般提供開始 に伴い、AWS はドキュメント処理容量を拡張し、ポリシールールが実際に動作する例を自動的に作成するシナリオ生成などの新機能を追加しました。強化されたテスト管理システムにより、ドメインエキスパートは包括的なテストスイートを構築、保存して自動実行し、モデルやアプリケーションのバージョンをまたいで一貫したポリシー適用を維持できます。 2 部構成のテクニカルディープダイブの第 1 部となる本記事では、Amazon Bedrock Guardrails における自動推論チェックの技術的な基礎を解説し、生成 AI アプリケーションのために数学的に厳密なガードレールを構築する実装方法を紹介します。 本記事で学べる内容 AI 出力の数学的な検証を可能にする形式的検証の技術を理解する 自然言語のドキュメントから自動推論ポリシー (Automated Reasoning policy) を作成し、改善する ビジネスルールに照らして AI 応答を検証するための効果的なテストケースを設計、実装する 注釈 (annotation) を用いてポリシーを改善し、精度を高める AWS のベストプラクティスに従い、Amazon Bedrock Guardrails を使用して自動推論チェックを AI アプリケーションのワークフローに統合し、生成されたコンテンツに対する高い信頼を維持する この実装ガイドは、事実誤認やポリシー違反がエンドユーザーに届く前に、それらを体系的に防止するのに役立ちます。これは、AI システムに高い保証と数学的な確実性を求める規制産業の企業にとって、きわめて重要な能力です。 自動推論チェックの主要機能 このセクションでは、ポリシー開発のためのコンソール体験、ドキュメント処理アーキテクチャ、論理検証のメカニズム、テスト管理フレームワーク、統合パターンなど、自動推論チェックの機能を説明します。これらの中核となる構成要素の理解が、生成 AI アプリケーションのための効果的な検証システムを実装する基礎になります。 コンソール体験 Amazon Bedrock の自動推論チェックのコンソールは、ポリシー開発を論理的なセクションに整理し、作成、改善、テストのプロセスを順に案内します。インターフェイスでは一意の ID によってルールを明確に識別でき、ルール内で変数名をそのまま使用するため、複雑なポリシー構造も理解しやすく管理しやすくなっています。 ドキュメント処理容量 ドキュメント処理は最大 120,000 トークン (約 100 ページ) に対応するため、大規模なナレッジベースや複雑なポリシードキュメントを自動推論ポリシーにエンコードできます。包括的なポリシーマニュアル、詳細な手順書、広範な規制ガイドラインを取り込むことも可能です。この容量により、1 つのポリシー内でドキュメント全体を扱えます。 訳注: 上記の上限は記事公開時点の情報です。2026 年 9 月時点のユーザーガイドでは、ソースドキュメントのサイズは 5 MB、50,000 文字までと記載されています。参照: 自動推論ポリシーを作成する – Amazon Bedrock 検証機能 検証 API には、明確化が必要なステートメントを識別するあいまいさの検出、検証が失敗した理由を示す INVALID の検出結果に対する反例、境界条件を理解しやすくするために有効な例と無効な例の両方を示す SATISFIABLE の検出結果が含まれます。これらの機能は検証結果の背景となる情報を提供し、特定の応答がフラグ付けされた理由と改善方法を理解する助けになります。また、自然言語と論理構造の間の変換 (translation) に対する信頼度も示せるため、ユースケースに適したしきい値を設定できます。 反復的なフィードバックと改善のプロセス 自動推論チェックは、応答が検証に失敗した理由を説明する詳細で監査可能な検出結果を提供します。これにより、準拠していないコンテンツを単にブロックするのではなく、反復的な改善プロセスを進められます。この情報は基盤モデルにフィードバックでき、モデルはポリシールールに準拠するまで、具体的なフィードバックに基づいて応答を調整できます。このアプローチは、事実の正確さとコンプライアンスを推定ではなく数学的に検証しなければならない規制産業で特に有用です。 ポリシー例による検出結果タイプ 休日を判定するポリシーを例に考えてみましょう。自動推論チェックにおけるポリシーは、変数のスキーマ (従業員区分、勤続年数、利用可能な休暇日数などの概念を定義するもの) と、これらの変数間の関係を定める一連の論理ルール (休暇の種類ごとの適格条件など) の 2 つで構成されます。検証時には、このスキーマとルール構造を使って、基盤モデルの応答が定義したポリシー制約に準拠しているかどうかを評価します。 ここでは、基盤モデル (FM) を利用したアプリケーションにユーザーが入力した以下の内容と、生成された出力を検証します。 Input: "Is Thursday a day off if it's a public holiday?" Output: "Yes, Thursday would be a day off if it's a public holiday, since all public holidays are considered days off regardless of the day of the week." 前提 (premise) とは結論を導き出すもとになるステートメントであり、主張 (claim) とは真であると述べられた内容です。この例では、 day が「Thursday」に等しく、 is_public_holiday が true であることが前提として推論され、 is_day_off が true であることが主張されています。 この推論は、次の自動推論ポリシーに従っています。 Days Off Policy: - All weekend days (Saturday and Sunday) are days off - All public holidays are days off - A day is considered a day off if it is either a weekend day or a public holiday 一般提供開始に伴い、自動推論チェックは FM が生成した応答の検証プロセスについて的確な洞察を与える、7 種類の検出結果タイプを出力するようになりました。 VALID : Input と Output がポリシールールに完全に整合していることを示します。生成された応答の情報が、定義済みのポリシーに従って正しいという確信が得られます。主張は前提から推論され、自動推論 (AR) ポリシーによって真であると検証されており、これらの主張と矛盾する別の答えは存在しません。 Input: Today is Sunday, do I have the day off? Output: Yes, Sunday is a weekend day, you have the day off. Premises: day: Sunday is_weekend: true Claim: is_day_off: true Explanation: Given the assigned variables and policy rules that weekends are days off, the only possible answer is that it is a day off. SATISFIABLE : Input と Output が、特定の仮定によって真にも偽にもなり得ることを示します。この検出結果は、応答が一定の条件下でのみ有効となる境界条件を把握するのに役立ち、その仮定がご自身のユースケースにおいて妥当かどうかを判断できます。必要な仮定が偽である場合は、前提と整合する別の主張が存在する可能性があります。 Input: Today is Tuesday, do I have the day off? Output: Yes Premises: day: Tuesday Claim: is_day_off: true Explanation: If we assume is_public_holiday=true, this is correct, but if we assume is_public_holiday=false, the answer would be incorrect since Tuesday is not a weekend. INVALID : Input と Output にポリシー上の不正確さや事実誤認があることを示し、検証が失敗した理由を明示する反例を付加します。主張は前提と AR ポリシーからは導かれず、前提と AR ポリシーに整合する別の主張が存在します。 Input: Today is Sunday, do I have the day off? Output: No you do not have the day off. Premises: day: Sunday Claim: is_day_off: false Explanation: This is invalid because the policy states weekends are days off. The correct claim would be is_day_off = true since Sunday is a weekend day IMPOSSIBLE : 前提が AR ポリシーと矛盾している、またはポリシー自体に内部矛盾があるため、有効な 主張 を生成できない場合を示します。この検出結果は、ポリシーで定義された制約が論理的な不可能性を生み出しているときに発生します。 Input: Today is Sunday and not a weekend day, do I have the day off? Output: Yes Premises: day: Sunday is_weekend: false Claim: is_day_off: true Explanation: Sunday is always a weekend day, so the premises contain a contradiction. No valid claim can exist given these contradictory premises. NO_TRANSLATIONS : Input と Output に、AR ポリシーの評価に関連するデータへ変換できる情報が含まれていない場合に発生します。通常は、テキストがポリシーのドメインとまったく無関係な場合や、評価に利用できる情報を含まない場合に起こります。 Input: How many legs does the average cat have? Output: Less than 4 Explanation: The AR policy is about days off, so there is no relevant translation for content about cats. The input has no connection to the policy domain. TRANSLATION_AMBIGUOUS : Input  と Output があいまいなため、論理構造へ確定的に変換できない場合を示します。この検出結果が返された場合、検証を進めるには追加のコンテキストや確認のための質問が必要になる可能性があります。 Input: I won! Today is Winsday, do I get the day off? Output: Yes, you get the day off! Explanation: "Winsday" is not a recognized day in the AR policy, creating ambiguity. Automated reasoning cannot proceed without clarification of what day is being referenced. TOO_COMPLEX : Input  と Output に、レイテンシーの制限内では処理できないほど多くの情報が含まれていることを示します。この検出結果は、システムの現在の処理能力を超える、極端に大きい入力や複雑な入力で発生します。 Input: Can you tell me which days are off for all 50 states plus territories for the next 3 years, accounting for federal, state, and local holidays? Include exceptions for floating holidays and special observances. Output: I have analyzed the holiday calendars for all 50 states. In Alabama, days off include... Explanation: This use case contains too many variables and conditions for AR checks to process while maintaining accuracy and response time requirements. シナリオ生成 ポリシーから直接シナリオを生成できるようになりました。ポリシールールに適合するテストサンプルが作成されるため、エッジケースの特定や、ポリシーのビジネスロジック実装の検証に役立ちます。この機能により、ポリシー作成者はデプロイ前にルールの実際の動作を具体例で確認でき、広範な手動テストの必要性を減らせます。また、シナリオ生成は、個々のルールを見ているだけでは気付きにくい、ポリシーの適用範囲における潜在的な矛盾や抜けも浮き彫りにします。 テスト管理システム 新しいテスト管理システムでは、ポリシーテストを保存して注釈を付け、一貫した検証のためのテストライブラリを構築し、ポリシー変更を検証するためにテストを自動実行して、ポリシーのバージョンをまたいで品質保証を維持できます。ポリシーの改訂を重ねてもテスト結果を追跡できるバージョニング機能も備えており、変更が意図しない影響を及ぼしていないかを特定しやすくなっています。さらに、既存の品質保証ワークフローやドキュメント作成プロセスに組み込むために、テスト結果をエクスポートすることもできます。 ガードレールとの直接統合による選択肢の拡大 自動推論チェックは Amazon Bedrock の API と統合され、複雑なやり取り全体を通じて、AI が生成した応答を定められたポリシーに照らして検証できるようになりました。この統合は Converse アクションと RetrieveAndGenerate アクションの両方に対応しているため、さまざまな対話形式でポリシーを適用できます。検証の信頼度しきい値はドメイン要件に応じて設定でき、規制産業では厳格に、探索的な用途では柔軟に適用するといった使い分けが可能です。 ソリューション – AI を活用した病院再入院リスク評価システム ここまで自動推論チェックの機能を説明してきました。次は AI を活用した病院再入院リスク評価システムのユースケースを取り上げ、ソリューションを段階的に見ていきましょう。この AI システムは、電子カルテの患者データを分析して患者をリスクカテゴリ (低リスク、中リスク、高リスク) に分類し、CDC (米国疾病予防管理センター) のガイドラインを模した指針に基づいて個別の介入計画を推奨することで、病院再入院リスク評価を自動化します。その目的は、高リスク患者の早期特定と的を絞った介入の実施を支援して、30 日以内の再入院率を低減することです。この医療機関は、検証可能な精度と、医療ガイドラインへの準拠を数学的に証明できる説明可能な推奨を重視しています。臨床上の意思決定を支援しつつ、医療現場で一般的な厳格な監査可能性の要件も満たせるため、このアプリケーションは自動推論チェックの理想的な適用対象です。 注: 参照しているポリシードキュメントはデモンストレーション目的のみで作成した例であり、実際の医療ガイドラインや臨床上の意思決定に使用しないでください。 前提条件 Amazon Bedrock で自動推論チェックを使用するには、次の前提条件を満たしていることを確認してください。 有効な AWS アカウント 自動推論チェックが 利用可能な AWS リージョンの確認 訳注: 2026 年 9 月時点で、自動推論チェックがサポートする言語は英語 (米国) です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 自動推論ポリシーの作成、テスト、呼び出しを行うための適切な IAM 権限 (注: 本番環境で使用する IAM ポリシーは、適切な ARN パターンを使用して必要なリソースのみに限定した、きめ細かなものにしてください) { "Sid": "OperateAutomatedReasoningChecks", "Effect": "Allow", "Action": [ "bedrock:CancelAutomatedReasoningPolicyBuildWorkflow", "bedrock:CreateAutomatedReasoningPolicy", "bedrock:CreateAutomatedReasoningPolicyTestCase", "bedrock:CreateAutomatedReasoningPolicyVersion", "bedrock:CreateGuardrail", "bedrock:DeleteAutomatedReasoningPolicy", "bedrock:DeleteAutomatedReasoningPolicyBuildWorkflow", "bedrock:DeleteAutomatedReasoningPolicyTestCase", "bedrock:ExportAutomatedReasoningPolicyVersion", "bedrock:GetAutomatedReasoningPolicy", "bedrock:GetAutomatedReasoningPolicyAnnotations", "bedrock:GetAutomatedReasoningPolicyBuildWorkflow", "bedrock:GetAutomatedReasoningPolicyBuildWorkflowResultAssets", "bedrock:GetAutomatedReasoningPolicyNextScenario", "bedrock:GetAutomatedReasoningPolicyTestCase", "bedrock:GetAutomatedReasoningPolicyTestResult", "bedrock:InvokeAutomatedReasoningPolicy", "bedrock:ListAutomatedReasoningPolicies", "bedrock:ListAutomatedReasoningPolicyBuildWorkflows", "bedrock:ListAutomatedReasoningPolicyTestCases", "bedrock:ListAutomatedReasoningPolicyTestResults", "bedrock:StartAutomatedReasoningPolicyBuildWorkflow", "bedrock:StartAutomatedReasoningPolicyTestWorkflow", "bedrock:UpdateAutomatedReasoningPolicy", "bedrock:UpdateAutomatedReasoningPolicyAnnotations", "bedrock:UpdateAutomatedReasoningPolicyTestCase", "bedrock:UpdateGuardrail" ], "Resource": [ "arn:aws:bedrock:\${aws:region}:\${aws:accountId}:automated-reasoning-policy/*", "arn:aws:bedrock:\${aws:region}:\${aws:accountId}:guardrail/*" ] } 主なサービスクォータ : 自動推論チェックを実装する際は、 サービスクォータ に注意してください。 自動推論チェックでは、処理したテキスト量に基づいて課金されます。詳細については、 Amazon Bedrock の料金 を参照してください。 ユースケースとポリシーデータセットの概要 この例で使用しているポリシードキュメントの全文は、 自動推論の GitHub リポジトリ から入手できます。自動推論チェックの結果を検証するには、ポリシーの内容をよく理解しておくと役立ちます。さらに、自動推論が作成したポリシーを改善することが、99% を超える健全性 (soundness) を達成する鍵になります。 本記事で使用するサンプル医療ポリシーの主な内容を確認しましょう。応答の検証を始める際は、元のドキュメントと照らし合わせると役立ちます。 リスク評価と層別化:  医療施設は、人口統計学的要因、臨床的要因、医療利用状況、検査値、社会的要因に基づく標準化されたリスクスコアリングシステムを導入し、患者を低リスク (0～3 ポイント)、中リスク (4～7 ポイント)、高リスク (8 ポイント以上) のカテゴリに分類しなければなりません。 必須の介入:  各リスクレベルには固有の介入が必要で、より高いリスクレベルでは下位レベルの介入に加えて追加の対策を実施します。また、一定の条件を満たす場合は、スコアにかかわらず自動的に高リスクに分類されます。 品質指標とコンプライアンス:  施設は、入院後 24 時間以内のリスク評価を 95% 以上、退院前の完了を 100% とするなど、所定の完了率を達成しなければならず、高リスク患者については退院計画を文書化する必要があります。 臨床上の監督:  スコアリングシステムは標準化されていますが、主治医は適切な文書化と退院計画コーディネーターの承認のもとで、判定を覆す権限を保持します。 Amazon Bedrock コンソールを使用した自動推論チェックのポリシーの作成とテスト 最初のステップは、対象となる知識 (ここではサンプル医療ポリシー) を自動推論ポリシーにエンコードすることです。自動推論ポリシーを作成するには、次の手順を実行します。 Amazon Bedrock コンソールのナビゲーションペインで、 [構築] の下にある [自動推論] を選択します。 [ポリシーの作成] を選択します。 ポリシー名とポリシーの説明を入力します。 自動推論がポリシーを生成する元になるソースコンテンツを追加します。取り込み方法として、ドキュメント (PDF、TXT) のアップロードとテキストの直接入力のいずれかを選択できます。 作成する自動推論ポリシーの意図を記述します。意図の記述は任意ですが、自然言語ベースのドキュメントを数学的検証に使える一連のルールへ変換する大規模言語モデル (LLM) にとって、有用な情報になります。サンプルポリシーでは、次の意図を使用できます。 This logical policy validates claims about the clinical practice guideline providing evidence-based recommendations for healthcare facilities to systematically assess and mitigate hospital readmission risk through a standardized risk scoring system, risk-stratified interventions, and quality assurance measures, with the goal of reducing 30-day readmissions by 15-23% across participating healthcare systems. Following is an example patient profile and the corresponding classification. <Patient Profile>Age: 82 years Length of stay: 10 days Has heart failure One admission within last 30 days Lives alone without caregiver <Classification> High Risk ポリシーが作成されたら、[定義] を開いて、自然言語のドキュメントから知識を論理として表現するためにどのルール、変数、型が作成されたかを確認できます。 生成されるルール、変数、型の数は、この例と異なる場合があります。これは、提供したドキュメントの処理が非決定論的であるためです。そのため、他のシステムで使用する前に、ポリシー内に生成された情報を人間がレビュー (human-in-the-loop) することをお勧めします。 自動推論チェックの定義の確認 ポリシードキュメントを対象とした自動推論における 変数 とは、特定の型の情報 (整数、実数、ブール値など) を保持する名前付きのコンテナであり、ポリシー上の個別の概念や測定値を表します。変数はルールを構成する要素として機能し、ポリシー要件の追跡、測定、評価に使用できます。以下の画像では、 admissionsWithin30Days (過去の入院回数を追跡する整数変数)、 ageRiskPoints (年齢に基づくリスクスコアを保持する整数変数)、 conductingMonthlyHighRiskReview (月次レビューを実施しているかどうかを示すブール変数) といった例が確認できます。各変数には、その目的と表現している具体的なポリシー概念についての明確な説明が付いており、ルール内でこれらの変数を使ってポリシー要件を適用し、コンプライアンスを測定できます。また、[問題] 列にも、一部の変数が使用されていないことが示されます。これらの変数がどの概念を表しているかを確認し、ルールが不足していないかを見極めることが特に重要です。 [定義] には [ルール]、[変数]、[型] が表示されます。 ルール とは、自動推論がソースドキュメントから抽出するあいまいさのない論理ステートメントです。作成された次の単純なルールを見てみましょう。 followupAppointmentsScheduledRate is at least 90.0 – このルールは「 Section III A Process Measures 」から作成されたもので、医療施設は各種のプロセス指標を監視し、退院前にフォローアップ受診の予約が完了している割合を 90% 以上にする、という内容です。 より複雑なルールを見てみましょう。 comorbidityRiskPoints is equal to(ite hasDiabetesMellitus 1 0) + (ite hasHeartFailure 2 0) + (ite hasCOPD 1 0) + (ite hasChronicKidneyDisease 1 0) ここで、ite は「If then else」を表し、条件が真なら一方の値を、偽ならもう一方の値を返します。 このルールは、ポリシードキュメントの規定どおり、患者が現在有している疾患、つまり併存疾患 (comorbidity) に基づいてリスクポイントを計算します。患者を評価する際、システムは 4 つの疾患を確認します。すなわち、あらゆる型の糖尿病 (1 ポイント)、あらゆる分類の心不全 (2 ポイント)、慢性閉塞性肺疾患 (1 ポイント)、慢性腎臓病ステージ 3～5 (1 ポイント) です。このルールはブール論理を用いてポイントを合算します。つまり、各条件の値 (true=1、false=0 として表現) に、その条件に割り当てられたポイント値を掛け、すべての値を足し合わせて併存疾患リスクスコアの合計を求めます。例えば、患者が心不全と糖尿病の両方を有する場合は合計 3 ポイント (心不全の 2 ポイントに糖尿病の 1 ポイントを加算) となります。この併存疾患スコアは、患者の全体的な再入院リスクカテゴリを判定する、より大きなリスク評価フレームワークの一部となります。 [定義] には、カスタム変数型も含まれます。 カスタム変数型 は列挙型 (ENUM) とも呼ばれ、特定のポリシー概念について、許容される値を固定された集合として定義する専用のデータ構造です。値をポリシー要件に沿った事前定義済みの選択肢に限定することで、データ収集とルール適用における一貫性と正確性を保ちます。サンプルポリシーでは、4 つのカスタム変数型が特定されています。 AdmissionType : 患者が再入院リスク評価プロトコルの対象となるかどうかを判定する、入院の種類 (MEDICAL、SURGICAL、MIXED_MEDICAL_SURGICAL、PSYCHIATRIC) を定義します。 HealthcareFacilityType : 再入院リスク評価プロトコルを実施できる医療施設の種類 (ACUTE_CARE_HOSPITAL_25PLUS、CRITICAL_ACCESS_HOSPITAL) を指定します。 LivingSituation : 患者の居住状況 (LIVES_ALONE_NO_CAREGIVER、LIVES_ALONE_WITH_CAREGIVER) を分類します。これは社会的支援とリスクレベルを判定するうえで重要な要因です。 RiskCategory : 合計リスクスコアに基づいて患者に割り当てられる 3 段階のリスク層別化レベル (LOW_RISK、INTERMEDIATE_RISK、HIGH_RISK) を定義します。 健全性 (自動推論チェックが VALID と判定したときの精度) を高めるうえで重要なのが、取り込まれたルール、変数、型が正とすべき情報源 (source of truth) を最もよく表現しているかを確認する、ポリシー改善のステップです。ここからはテストスイートに移り、テストの追加方法、テストの生成方法、そしてテスト結果を使ってルールを更新する注釈の適用方法を見ていきます。 自動推論ポリシーのテストとポリシーの改善 自動推論のテストスイートは、2 つの目的でテスト機能を提供します。1 つ目は、さまざまなシナリオを実行して自動推論ポリシー内のルールと変数をテストし、それらが正とすべき事実 (グラウンドトゥルース) を正確に表現するように改善することです。このポリシー改善のステップは、自動推論チェックの健全性を高めるために重要です。2 つ目は、定義したポリシーとユースケースに対して自動推論チェックがどの程度機能しているかを把握するための指標を得ることです。そのために、自動推論コンソールで [テスト] タブを開きます。 テストサンプルは [追加] ボタンで手動で追加できます。テストの規模を拡大するには、ポリシールールからテストを生成する方法もあります。このテスト手法は、ポリシーの意味的な正しさ (ルールが意図したポリシー制約を正確に表現していること) と、自然言語の変換能力 (ユーザーがアプリケーションを操作する際に使う言葉をシステムが正しく解釈できること) の両方を検証するのに役立ちます。以下の画像では、生成されたテストサンプルが確認できます。テストスイートに追加する前に、対象分野の専門家 (SME) はこのテストサンプルが起こり得る (サムズアップ) か、起こり得ない (サムズダウン) かを判断します。その後、テストサンプルをテストスイートに保存できます。 テストサンプルを作成したら、そのサンプル単独で実行することも、 [すべてのテストを検証] を選択してテストスイート内のすべてのテストサンプルを実行することもできます。実行すると、このテストが正常に合格したことがわかります。 入力 (任意) と出力を指定して、テストを手動で作成することもできます。これらは検証の前に論理表現へ変換されます。 変換の仕組み 変換では、自然言語のテストが、ポリシールールに照らして数学的に検証できる論理表現に置き換えられます。 自動推論チェックは複数の LLM を使用して、入力と出力を論理的な検出結果へ変換します 各変換には、その品質を示す信頼度が複数モデルの投票によって付与されます 信頼度しきい値を設定して、どの検出結果を検証して返すかを制御できます 信頼度しきい値の動作 信頼度しきい値は、どの変換を検証に足るほど信頼できるとみなすかを制御し、厳格さと網羅性のバランスを取ります。 しきい値を高くする : 変換精度の確実性は高まりますが、検出結果が 1 つも検証されない可能性も高くなります しきい値を低くする : 検証済みの検出結果が返される可能性は高まりますが、変換の確実性は低くなることがあります しきい値 = 0 : 信頼度にかかわらず、すべての検出結果が検証されて返されます あいまいな結果 信頼度しきい値を満たす検出結果がない場合、自動推論チェックは「TRANSLATION_AMBIGUOUS」を返し、コンテンツの論理的な解釈に不確実性があることを示します。ここで作成して検証するテストケースは次のとおりです。 Input: Patient A Age: 82 Length of stay: 16 days Diabetes Mellitus: Yes Heart Failure: Yes Chronic Kidney Disease: Yes Hemoglobin: 9.2 g/dL eGFR: 28 ml/min/1.73m^2 Sodium: 146 mEq/L Living Situation: Lives alone without caregiver Has established PCP: No Insurance Status: Medicaid Admissions within 30 days: 1 Output: Final Classification: INTERMEDIATE RISK 実行すると、このテストは合格し、「INVALID」という結果が期待どおりであることがわかります。さらに、自動推論チェックは、12 個のルールが前提と主張に矛盾していたことも示しています。この矛盾によって、テストサンプルの出力が「INVALID」となりました。 表示されている矛盾するルールのうち、いくつかを見てみましょう。 年齢リスク : 患者は 82 歳 トリガーされるルール: 「patientAge が 80 以上の場合、ageRiskPoints は 3 に等しい」 在院日数リスク : 患者の在院日数は 16 日 トリガーされるルール: 「lengthOfStay が 14 より大きい場合、lengthOfStayRiskPoints は 3 に等しい」 併存疾患リスク : 患者は複数の疾患を有する ルールの計算: 「comorbidityRiskPoints = (hasDiabetesMellitus × 1) + (hasHeartFailure × 2) + (hasCOPD × 1) + (hasChronicKidneyDisease × 1)」 利用状況リスク : 患者は 30 日以内に 1 回の入院あり トリガーされるルール: 「admissionsWithin30Days が 1 以上の場合、utilizationRiskPoints は 3 以上」 検査値リスク : 患者の eGFR は 28 トリガーされるルール: 「eGFR が 30.0 未満の場合、laboratoryRiskPoints は 2 以上」 これらのルールは矛盾するリスクスコアを生成している可能性が高く、そのためシステムは有効な最終リスクカテゴリを判定できません。これらの矛盾から、テストの入力テキストが INVALID と判定された根拠となるルールがわかります。 次のスクリーンショットに示すように、テストスイートに別のテストを追加してみましょう。 Input: Patient profile Age: 83 Length of stay: 16 days Diabetes Mellitus: Yes Heart Failure: Yes Chronic Kidney Disease: Yes Hemoglobin: 9.2 g/dL eGFR: 28 ml/min/1.73m^2 Sodium: 146 mEq/L Living Situation: Lives alone without caregiver Has established PCP: No Insurance Status: Medicaid Admissions within 30 days: 1 Admissions within 90 days: 2 Output: Final Classification: HIGH RISK このテストを実行すると、患者の各情報が前提として抽出され、再入院リスクが高いという主張が検証されることがわかります。この主張の検証には 8 個のルールが適用されています。主なルールとその検証内容は次のとおりです。 年齢リスク : 患者の年齢が 80 歳以上であればリスクポイント 3 が加算されることを検証 在院日数リスク : 在院日数が 14 日を超える場合にリスクポイント 3 が加算されることを確認 併存疾患リスク: 糖尿病、心不全、慢性腎臓病の有無に基づいて計算 利用状況リスク: 入院歴を評価 検査値リスク: ヘモグロビン値 9.2 と eGFR 28 に基づいてリスクを評価 各前提は真と評価され、複数のリスク要因 (高齢、在院日数の長期化、複数の併存疾患、懸念される検査値、介護者なしの独居、かかりつけ医 (PCP) の不在) が存在することから、この HIGH RISK 評価に対する全体としての検証結果が VALID であることが裏付けられました。 さらに、自動推論エンジンは、HIGH RISK 分類が正しいという結論の健全性を高めるために、93 種類の割り当てを用いてこのテストサンプルを広範に検証しました。自動推論ポリシーの関連ルールを使用して、93 種類のシナリオと変数の組み合わせに対してサンプルを検証します。これにより、この患者の HIGH RISK 分類が無効となり得る状況は存在しないことを確認できます。この徹底した検証プロセスによって、複数の慢性疾患と複雑なケアニーズを有する高齢患者に対するリスク評価の信頼性が裏付けられます。テストサンプルが失敗した場合、93 種類の割り当ては重要な診断ツールとして機能し、期待される結果と矛盾する変数とその相互作用を特定します。その結果、SME は関連するルールとその関係を分析し、臨床ロジックとリスク評価基準のいずれかに調整が必要かどうかを判断できます。次のセクションでは、ポリシーの改善と、SME が注釈を適用して自動推論ポリシーのルール、変数、カスタム型を改善・修正する方法を見ていきます。 注釈によるポリシーの改善 注釈は、テストが期待した結果にならなかった場合に、自動推論ポリシーを改善する強力なメカニズムです。注釈を通じて、SME は次の方法で体系的にポリシーを改善できます。 ロジックや条件を変更して、問題のあるルールを修正する ポリシー定義に不可欠な、不足している変数を追加する 変数の説明を更新して、精度と明確さを高める 元のポリシーの表現があいまいだったために生じた変換の問題を解決する ポリシーから冗長または矛盾する要素を削除する テスト、注釈付け、更新というこの反復的なプロセスによって、ドメインの専門知識を正確にエンコードした、より堅牢なポリシーが構築されます。以下の図に示すように、注釈を適用してさまざまなポリシー要素を変更でき、その後、改善されたポリシーをデプロイ用に JSON ファイルとしてエクスポートできます。 次の図では、注釈が適用され、ポリシー内のルールが削除される様子が確認できます。同様に、ルール、変数、カスタム型に対して追加や更新を行うこともできます。 SME がテスト、注釈の適用、ルールの検証を通じて自動推論ポリシーを検証したら、ポリシーを JSON ファイルとしてエクスポートできます。 モデル推論時における自動推論チェックの使用 作成したポリシーで自動推論チェックを使用するには、 Amazon Bedrock Guardrails に移動し、名前、説明、そしてガードレールが介入して AI システムに対するプロンプトやその出力をブロックしたときに表示するメッセージを入力して、新しいガードレールを作成します。 続いて、 [自動推論ポリシーを有効化] のトグルをオンにして、自動推論チェックをアタッチします。信頼度しきい値を設定して、ポリシーをどの程度厳格に適用するかを指定できます。しきい値の範囲は 0.00～1.00 で、1.00 がデフォルトかつ最も厳格な設定です。各ガードレールには、検証の柔軟性を高めるために最大 2 つの自動推論ポリシーを設定できます。次の図では、患者の病院再入院リスク評価に関する医療ポリシーのドラフトバージョンをアタッチしています。 これでガードレールを作成できます。作成が完了して自動推論ポリシーがリンクされたら、ガードレールの詳細ページを開き、すべてのポリシーが正しくアタッチされていることを確認してください。 クリーンアップ 実装が完了したら、作成したガードレールと自動推論ポリシーを削除してリソースをクリーンアップしてください。ガードレールを削除する前に、それを使用しているすべてのリソースやアプリケーションから関連付けを解除してください。 まとめ 2 部構成の第 1 部となる本記事では、Amazon Bedrock Guardrails の自動推論チェックが、数学的検証を通じて生成 AI アプリケーションの信頼性と正確性の維持にどのように役立つかを解説しました。拡張されたドキュメント処理容量、高度な検証メカニズム、包括的なテスト管理機能を活用して、ビジネスルールとドメイン知識に照らして AI 出力を検証できます。このアプローチは、生成 AI システムをデプロイする企業が直面する主要な課題、特に事実の正確さとポリシー準拠が不可欠な規制産業における課題に対応します。病院再入院リスク評価のデモンストレーションが示すように、この技術は複雑な意思決定プロセスの検証を支援し、生成 AI を重要なビジネス環境に適したシステムへと変えるのに役立ちます。これらの機能は AWS マネジメントコンソールと API のどちらからでも利用でき、AI アプリケーションの品質管理プロセスを確立できます。 さらに詳しく学び、セキュアで安全な AI アプリケーションを構築するには、 技術ドキュメント と GitHub のコードサンプル を参照するか、 Amazon Bedrock コンソール にアクセスしてください。 著者について Adewale Akinfaderin は Amazon Bedrock の Sr. Data Scientist–Generative AI で、AWS における基盤モデルと生成 AI アプリケーションの最先端のイノベーションに貢献しています。専門は再現可能でエンドツーエンドの AI/ML 手法と実践的な実装であり、世界中のお客様が学際的な課題に対してスケーラブルなソリューションを構想し開発できるよう支援しています。物理学で 2 つの大学院学位を、工学で博士号を取得しています。 Bharathi Srinivasan は AWS Worldwide Specialist Organization の Generative AI Data Scientist です。アルゴリズムの公平性、大規模言語モデルの真実性、説明可能性に焦点を当て、責任ある AI のためのソリューション開発に取り組んでいます。社内チームと AWS のお客様の責任ある AI への取り組みも支援しており、さまざまな機械学習カンファレンスで自身の成果を発表しています。 Nafi Diallo は Amazon Web Services の Senior Automated Reasoning Architect で、生成 AI アプリケーションのための AI 安全性と自動推論システムのイノベーションを推進しています。専門は形式的検証の手法と AI ガードレールの実装であり、世界中のお客様が信頼できるコンプライアンス対応の AI ソリューションを大規模に構築できるよう支援しています。自動プログラム修復と形式的検証を研究テーマとするコンピュータサイエンスの博士号と、WPI (Worcester Polytechnic Institute) の金融数学の修士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

専門的な知識が求められ、長期間にわたって保守される組み込みソフトウェアの開発では、知識や設計判断をどのように継承するかが重要になります。 2026 年 7 月、株式会社日立産業制御ソリューションズ様（以下、同社）向けに、「 Accelerating Smart Product SDLC with AI Agent 」ハンズオンワークショップを 2 回開催しました。本稿ではその開催報告をお届けします。 開発者が実際によく目にする既存プロジェクトを題材に、コードや文書を AI エージェントに読み解かせ、仕様を捉え直し、実装とテストまで進める一連の流れを、組み込みソフトウェア開発に携わる 102 名のエンジニアに体験していただきました。 AI によるソフトウェア開発支援というと、新規開発を対象にしたものだと思われたり、コーディングに絞った生産性改善の方法と受け取られたりしがちです。本ワークショップは、既存コードを対象に、AI コーディングエージェント Kiro を開発ライフサイクル全体に適用します。人が作業を指示し、AI が進め、その結果を人が承認します。この役割分担を、各工程で体験いただく構成です。 開発ライフサイクルのどの工程に AI エージェントを適用するか なぜ組み込みソフトウェア開発の現場で実施したのか 同社では、車載をはじめとする組み込みソフトウェアの開発を担う部門があります。AI エージェントの活用について議論を重ねる中で、まず現場のエンジニアに実際に体験してもらい、どこまで任せられるのかを見極めたい、というご要望をいただきました。 今回の実施に向けた同社との議論では、信頼性や規格への対応、実機での確認などを踏まえ、AI エージェントを適用する工程と人が判断する範囲を見極めることが論点となりました。加えて、受託開発として顧客企業のコードを扱う場合は、開発ツールの利用条件やデータの取り扱いの確認も必要になる、という議論になりました。こうした検討を進めるうえでも、まず AI エージェントが何をどこまでできるのかを、現場のエンジニアの方々に実際に手を動かして確かめていただく場をご用意しました。 ワークショップの内容 題材は HVAC（空調）制御システムです。引き継いだ仕様書と実装が合っていない、というソフトウェア開発でよく見かける状態から始まります。 はじめに Kiro に既存コード（サンプル）を読み解かせ、構造と振る舞いを整理します。続いて、その理解をもとに追加機能の仕様を Kiro との対話でまとめ、最後に仕様を設計に落とし、その設計を AI が実装するタスクへ分解して、実装からビルド、テストまで進めます。 対話だけで AI に指示すると、設計判断や作業の経過が残りにくくなります。透明性を確保するため、ワークショップではチケット管理システムに AI への指示を記載するアプローチを紹介しました。GitLab の Issue に作業を指示すると、Kiro が設計から実装、テストまで進め、経過を Issue のコメントに書き戻します。どこまで AI に任せ、どこで人が判断したかがチケットに残るため、担当者が変わっても経緯を追えます。長く保守されるソフトウェアと相性のよい進め方です。 ワークショップ全体では、この先のクラウド環境へのデプロイと運用までが Lab として用意されています。今回は 4 時間のプログラムとして、調査・仕様の作成・実装にあたる 3 つの Lab を実施しました。 題材は空調ですが、ライフサイクルが長く、実機の制約を前提に設計する点は、車載ソフトウェア開発にも共通します。今回は、車載ソフトウェア開発を中心に、産業機器を手がける方々にご参加いただきました。 当日は、お一人ずつに実行環境をご用意し、実際に Kiro を動かしながら進めていただきました。 Lab の進め方を説明する講師 ワークショップへの期待をお話しいただいた同社ご担当者 ワークショップのフィードバック 参加された皆様からは、次のような声をいただきました。 組み込みでも Kiro を活用できる箇所が想像より広く、いろいろな可能性を知ることができた AI によるリバースエンジニアリングを体験できた どのくらいの作業時間でどの程度のアウトプットが出るか、イメージが湧いた とりわけ手応えを感じていただけたのは、実際の開発プロジェクトで遭遇する既存コードを読み解く工程と、そこから仕様や設計を文書として残していく工程でした。AI エージェントは実装を速くするための道具にとどまらない、という受け取り方が広がったことが、今回の大きな収穫だったと感じています。ワークショップ後には、業務での利用に前向きな意見も寄せられました。 あわせて、実務に適用するうえでの検討事項も同社からご共有いただきました。ソースコードや設計情報の取り扱い、生成されたコードをどう検証するか、機能安全や規格対応との整合といった論点です。このうちデータの取り扱いについては、入力したコードが学習に使われるかどうか、通信経路や保管先を同社の管理下に置けるか、どのリージョンで AI を使うか、誰がどのような指示を出し AI が何を変更したかを記録に残せるか、という確認事項に整理したうえで、公式ドキュメントをもとにご説明しました。 今後に向けて ご要望としていただいたのは、HILS（シミュレータで制御対象を模擬する検証環境）やデバッガと連携させた実機に近い工程の扱いと、要求定義や上流設計により特化した内容です。また、今回は時間の都合で実施できなかった後半の Lab、とくにデプロイや運用の工程を試したいという声もいただきました。同社と引き続き検討していきます。 同社 執行役員 コネクティブエンジニアリング事業部長 遠藤 征樹 様からは、次のようなコメントをいただきました。 ミッションクリティカルな組み込みシステム開発においては、品質・安全性の確保と開発スピードの向上を両立することが重要な経営課題です。 今回、AI が既存コードの理解から仕様化、実装、テストまでを支援できることを実践的に確認できました。 人が品質と安全性を判断し、AI が開発を支援する役割分担の実務適用に向け、引き続き検討を進めてまいります。 まとめ 今回のワークショップは、組み込みソフトウェア開発においても AI エージェントを活用できる領域が広くあることを、実際に手を動かしながら確認いただく機会となりました。なかでも、既存コードの理解や仕様の整理といった上流の工程から始めるアプローチは、参加者が AI エージェントの適用範囲を考えるきっかけになったと考えています。 本ワークショップは公開されており、どなたでもご自身の環境で実施いただけます（ AWS ブログでも紹介しています ）。組み込みソフトウェア開発への AI エージェント適用にご関心をお持ちの方は、担当のアカウントチームまでお気軽にお問い合わせください。 星野 光玖 (Miku Hoshino) アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ソリューションアーキテクト 山本 直志 (Tadashi Yamamoto) アマゾン ウェブ サービス ジャパン合同会社 自動車・製造事業開発本部 シニア事業開発マネージャー

はじめに 本記事は、HR データ統合基盤を題材に、共通オントロジーの設計の考え方と、取込・質問応答・推論への使い方、それを AWS 上で組む際の構成を解説します。 RAG（Retrieval-Augmented Generation）は、検索で取得した社内データなどを LLM に渡して回答を生成する構成です。ドキュメントをベクトル化し、意味の近い断片を取得して LLM に回答させる方式は、FAQ や社内ナレッジ検索では十分に機能します。 一方で、HR ドメインではうまくいかない場面が出てきます。たとえば次のような質問です。 「田中さんの現在の所属部署は？」 「このグループ会社の子会社・孫会社を全部挙げると？」 「先月、残業が月45時間を超えた従業員は誰と誰？」 「今空いているポジションは？」 「2024年4月時点で、営業部の親部署はどこだった？」 これらはいずれもベクトル類似検索が苦手とする質問です。 質問 必要な処理 子会社を全部挙げる 親子関係を何階層もたどり、該当する会社を列挙する 空いているポジションを探す そのポジションに誰も割り当てられていないことを確認する 残業が45時間を超えた人を探す 時間や件数を正確に集計し、条件に合う従業員を抽出する 2024年4月時点の状態を調べる 過去の指定日時点で有効だった関係を調べる 意味の近い文章を拾う仕組みでは、これらに「たぶん合っている」レベルでしか答えられません。HR では、回答の誤りが労務コンプライアンス違反や人事意思決定のミスにつながります。「田中さんの残業は45時間を超えていません」という回答が誤っていれば、36協定違反の見逃しになりかねません。そのため、HR の RAG には、出典と鮮度つきの正確な答えが必要です。 さらに、これらの質問に答えるデータは、1か所にまとまっていない場合が多いです。勤怠・給与・タレントマネジメント・採用管理・人事マスタは別々のシステムとして導入され、M&A やグループ再編でさらに増え、同じ「人」がシステムごとに違う ID・違う名前で分断されています。「グループ全体のスキルギャップは？」のような部門横断の問いは、都度 CSV などにデータを出力し、突き合わせる作業になりがちです。これを解くのが MDM（マスタデータ管理）で、散らばったソースを共通の「人・組織・ポジション」に名寄せし、1つのグローバル ID に束ねます。その場合の最大の難所が、システムごとにバラバラな項目・名前・構造をどうやって同じ意味に揃えるか、です。 本記事で紹介する設計は、複数ソースの統合と、統合したグラフ上での正確な質問応答という2つの課題を、オントロジーを使ったデータ統合と質問応答で解きます。業界標準の語彙をオントロジーとして定義し、取込（名寄せ・統合）と検索（質問応答）の両方で共通の基準にします。LLM には意図の解釈を任せ、答えのデータは決定論的なグラフクエリで取得します。 全体像 先に全体の構成を示します。登場するのは 2 本のパイプラインと、その両方が参照するオントロジーです。 図1：フロントエンドとバックエンドを分離したAWS構成案。 オントロジーは Lambda Layer で取込・検索の両方に配布します。 取込パイプライン（バッチ） は、Amazon S3 に置かれた人事マスタの JSON を AWS Lambda が読み、オントロジーの写像ルールに従って RDF に変換します。ログイン ID で名寄せして不変のグローバル ID を発番し、元データを Amazon Neptune Serverless に SPARQL UPDATE で書き込みます。続いて推論・派生結果を追加し、元データの制約検証を実行します。検出結果はログと取込処理の戻り値に記録します。 質問応答パイプライン は、CloudFront と非公開の S3 で配信するチャット UI が質問を受け、API Gateway の REST API を通じて回答 API の Lambda を呼び出します。回答 API は VPC 内の検索 Lambda を呼び、検索 Lambda が「意図分類 → テンプレート SPARQL → Neptune で実行 → 出典回収」を行います。回答 API は検索結果を受け取り、Amazon Bedrock で回答文に整形して、ストリーミングで返す構成です。 層 サービス 役割 共通オントロジー Lambda Layer OWL 語彙（HR Open Standards 4.5 に基づく）・写像 JSON・LLM 向け要約。両方の Lambda に同梱する データ置場 Amazon S3 人事マスタの JSON をソースごとの形式のまま置く 取込 AWS Lambda 写像で RDF 化・名寄せ → 元データを Neptune へ書き込み → 推論・派生結果を追加 → 元データの制約検証・結果記録 グラフ DB Amazon Neptune Serverless RDF / SPARQL 1.1。レコード単位の名前付きグラフに事実を置き、出典・鮮度を付与する 検索 AWS Lambda（VPC 内） 意図分類 → テンプレート SPARQL → 実行 → 出典回収 LLM Amazon Bedrock Claude Haiku が意図分類、Claude Sonnet が回答整形を担当 フロントエンド Amazon CloudFront・Amazon S3 チャット UI の静的ファイルを配信する。非公開の S3 へ CloudFront からアクセスする 回答 API Amazon API Gateway・AWS Lambda 検索 Lambda の呼出し、Bedrock による回答整形、ストリーミング配信を担当する 出典と鮮度はどこから来るか 回答に使ったデータについて、「どのシステムから、いつ取得したものか」を確認できるようにします。 例えば、人事システムAから取得した田中さんの配属データを、その出典・取得時刻・確度と対応付けて保存します。この対応を管理するため、ソースごとの各レコードを、名前を付けたデータのまとまりである「名前付きグラフ」に格納します。 検索時には、回答に使うデータがどのまとまりに属するかを調べ、対応する出典と取得時刻も取り出します。 なぜ HR データにオントロジーが必要か オントロジーは、HR の文脈では次のように捉えると分かりやすくなります。 オントロジーとは、その分野に登場する概念と、概念同士の関係を、人と機械が同じ意味で扱える形で定義したものです。 HR で言えば、「従業員とは何か」「所属とは何か」「ポジションと人はどういう関係にあるのか」を、誰が読んでも同じ意味に取れるよう明文化したものです。用語集（言葉の定義を並べたもの）との違いは、関係やルールまで機械が処理できる形で定義する点にあります。「A は B の子会社」「この人は 2023年4月からこの部署に所属」といった関係を、コンピュータがたどれる形で持たせます。 意味の定義をテーブル設計から独立させる理由 あるプロダクトでは「社員」、別のプロダクトでは「従業員」、勤怠システムでは「要員」。同じ人を指す言葉が、システムごとに違う名前・違う列・違う型で管理されています。テーブル設計は各システムの都合で最適化されるので、統合しようとすると「どの列とどの列が同じ意味なのか」を人間が都度すり合わせることになります。 オントロジーは、この「意味の層」をデータベースのスキーマから独立させます。各ソースのバラバラな項目を共通の意味へ写像する土台になります。これは、複数ソースを共通のドメインモデルへ対応づける工程にあたります。 なぜ RAG でオントロジーが効くのか ベクトル RAG は言葉が似ている文章を拾う仕組みなので、「田中さんの上司の、そのまた上司の部門は？」のような関係をたどる質問や、「今この瞬間ではなく去年4月時点の所属」のような文脈の厳密さには、意味の定義がなければ答えられません。 オントロジーは、関係・時間・ルールを機械が処理できる形で定義します。その定義に沿って関係や時点をたどることが、正確な回答につながります。本記事の設計が HR Open Standards をオントロジーの土台に据えたのは、この理由からです。 用語ミニ解説 用語 意味 クラス / インスタンス 「従業員」という種類がクラス、「田中さん」という具体的な1人がインスタンス プロパティ 「所属する」「上司である」など、対象同士を結ぶ関係 RDF データを「主語・述語・目的語」の3つ組（トリプル）で表すデータモデル。グラフ構造になる OWL RDF の上で、クラスの定義や関係の性質（推移的など）を記述する言語。本記事では、OWL 2 RL/RDF ルールに基づく推論を、Python ライブラリ owlrl で実行します。参考： OWL 2 Profiles 、 owlrl SPARQL RDF グラフに対する問い合わせ言語 推移的な関係 「AからB、BからC」という関係から「AからC」も成り立つ関係。会社の階層をたどる場合などに使う HR Open Standards を使った共通オントロジーの設計 なぜ独自スキーマでなく業界標準か 本記事の設計では、語彙をゼロから設計せず、HR Open Standards 4.5 という国際的な HR データ標準に準拠させています。HR Open Standards は、HR Open Standards Consortium という非営利団体が策定・公開している、HR データ交換のための標準です。採用・給与・勤怠・組織・人物・スキルといった HR ドメインの概念を「型」として定義し、JSON / XML スキーマの形で配布しています。 今回のオントロジーが使う主な型は、次のようなものです。 型 表すもの 主な項目 Person（人物） 個人そのもの 氏名、生年月日、連絡先、不変のグローバルID Worker（従業員） 「組織で働く」というロール 社員番号、入社日、等級。氏名などは Person を参照 Organization（組織） 会社・部門 組織名、種別（会社／部門）、親組織 Position（ポジション） 職務・席 役職名、充足状況。人とは独立 WorkAssignment（配属） 人と組織・ポジションの結びつき 開始日・終了日、配属先組織、ポジション Skill / Certification スキル・資格 スキル名、資格名（保有は熟練度つきで別途表現） 型の作法にも特徴があります。たとえば識別子は単なる文字列ではなく「値（value）と採番体系（schemeId）の組」で持ちます。社員番号もグローバルIDも同じ形で表せるので、ソースごとに違う ID 体系を一様に扱えます。こうした型と作法が標準として決まっているため、各社が独自に持つ「社員」「組織」を標準の型に写像するだけで、システム間で意味を揃えられます。 標準を使う狙いは、複数プロダクト・複数ソースで異なる項目を、共通の語彙に対応付けることです。ソースごとにばらばらな「社員」「従業員」「要員」を、標準が定める「従業員」という1つの型に写像すれば、統合後は同じ語彙で扱えます。自前でモデルを作るより、多くの企業で検討・改訂されてきた語彙を使うほうが、抜け漏れの確認や他システムとの相互運用性の面で有利です。 業務要件をクラス設計に反映する オントロジーを実課題に結びつけるうえで大事なのは、業務要件がそのままクラス設計として表れる点です。HR Open のモデルには、次のような設計が織り込まれています。 従業員（ロール）と人物を分離する ：氏名や生年月日は「人物」が持ち、雇用に関する属性は「従業員」が持つ。これにより「従業員番号は転籍で変わっても、人物としての同一性は不変」を表現できます。人物には不変のグローバル ID を与え、従業員番号とは別に扱います。 配属が開始日・終了日を持つ ：所属を「今の状態」ではなく「いつからいつまでの配属」として持つことで、異動履歴も、過去のある時点の組織断面も再構成できます。 ポジションを人と独立させる ：ポジションを人から切り離すことで、「誰も割り当たっていないポジション＝空席」を表現できます。 「田中さん」という1人の従業員を例に、人物・従業員・配属・組織・ポジションの関係をグラフ図で示します。 図2：人物・従業員・配属と、組織・ポジションの関係。 矢印は参照元から参照先を示します。 人物には氏名・生年月日・不変のグローバル ID、従業員には入社日・等級などの雇用属性を持たせます。配属は2023年4月1日から現在までの期間を持ち、従業員・組織・ポジションを結び付けます。 同じ「田中さん」でも、氏名は人物に、入社日は従業員に、所属は配属にぶら下がります。所属を人に直接持たせず配属を挟むことで、「2024年4月時点ではどの組織だったか」を後から再構成できます。組織どうしは親組織の関係でつながり、部から本部、本部から会社まで一本で辿れます。ポジション（営業課長）は配属から参照される独立した型なので、配属がなければ「空席の営業課長」として残ります。 クラス設計を見るだけで、この基盤が履歴も空席も時点断面も扱えると読み取れます。業務要件がオントロジーの構造に反映されているのです。 設計上の3つの判断 今回の設計判断を3つ挙げます。 (1) 標準準拠と運用拡張を分けて管理する 標準（HR Open）に含まれる語彙と、運用のために独自に足した語彙（出典管理・時制の表現・名寄せなど）を、名前空間で分けています。加えて、それぞれの語彙が「標準のどの型に相当するか」「標準にないため拡張したものか」を語彙自身に注記しています。こうすると、どこまでが標準でどこからが独自かが一目で分かり、標準への準拠範囲が運用の中で曖昧になりません。 (2) 属性を持つ関係は「中間ノード」で表す 「田中さんは Python スキルを上級レベルで持つ」。この「上級」のように、関係そのものに付く属性があります。RDF は「主語-述語-目的語」という単純な3つ組なので、関係に属性を直接足せません。そこで人物とスキルを直接つながず、間に中間的なノードを置いて熟練度を持たせます。同じ考え方は、手当（金額・期間つき）、休暇残数、承認ステップなどにも一貫して使えます。グラフで「属性付きの関係」を表現するときの定石です。 (3) 状態は「フラグ」でなく「関係の有無」で表す ポジションが埋まっているかどうかを、ステータスのフラグで持つこともできます。本記事の設計では、現在有効な配属がそのポジションを参照しているかという関係の有無で判定します。配属と充足フラグを別々に更新すると、更新漏れで両者がずれることがあります。配属との関係を判定の基準にすることで、二重管理を避けています。 1つの語彙で取込と検索を揃える オントロジーを共通語彙として据える利点は、取込と検索が同じ言葉で書ける点に表れます。ソースを取り込む写像ルールと、質問に答える検索クエリの両方に、同じ語彙が同じ意味で現れます。 取込ルールは、宣言的に「このソース項目を、この語彙のクラス・関係に対応づける」と書くだけです。 イメージをつかむために、配属レコードの写像を簡略化して示します。 入力・項目 写像ルール 配属レコード WorkAssignment クラスに対応付ける 従業員への参照 ログイン ID を名寄せしてグローバル ID に解決する ポジションへの参照 任意（ 指定時点で有効な配属から参照されていないポジションを空席と判定する ） ここで2つの設計が効いています。ログイン ID を名寄せしてグローバル ID に解決することが「複数ソースの統合」であり、ポジションへの参照を任意にすることが「空席とは参照が存在しないこと」というモデリングです。 検索側も同じ語彙で組み立てます。「今空いているポジションは？」は、取込で決めた「参照がなければ空席」の裏返しで、ポジションへの参照が存在しないものを探すだけで結果を得ることができます。「グループ会社を全部辿る」は、親組織という関係を「推移的」と定義しておけば、何階層でも子孫をたどれます。 つまり、モデリングの意味は語彙に一元化され、取込と検索はそれを参照するだけになります。「空席＝参照なし」と取込で決めておけば、検索側は追加の取り決めなしに同じ定義で答えられます。ソースを取り込むときの解釈と、質問に答えるときの解釈が、1つの語彙で揃います。 同じ語彙の要約を LLM に渡すことで、質問から検索を組み立てる際に、使う概念や関係を限定します。次のセクションでは、この質問応答の設計を説明します。 質問応答の設計 自然文をそのままクエリに変換する方式の落とし穴 自然文の質問を LLM にそのままクエリへ変換させる方法では、構文エラーのあるクエリや、存在しないクラス・プロパティを使ったクエリが生成されることがあります。長いクエリの生成には時間がかかり、生成された内容をそのまま実行するリスクもあります。 意図の分類は LLM、クエリ生成は決定論 本記事の設計では、LLM にクエリ本文を書かせません。LLM の役割を「質問が何を訊いているか（意図）と、そのパラメータを取り出す」ことだけに絞ります。取り出した意図とパラメータは、あらかじめ検証済みのクエリテンプレートに機械的に流し込みます。 順番 担当 処理 1 LLM 質問の意図と、対象者・年月などのパラメータを取り出す 2 コード パラメータを検証し、意図に対応するテンプレートから SPARQL を組み立てる 3 Amazon Neptune・検索処理 クエリを実行し、結果と出典・鮮度を取得する 4 LLM 取得した結果を根拠に回答文へ整形する たとえば「2026年7月に残業が45時間を超えた従業員は？」という質問に対して、LLM が返すのは次の2項目です。 項目 抽出結果 意図（intent） 残業の確認（overtime） 対象年月（yearMonth） 2026-07 コードはこの意図に対応する検証済みテンプレートを選び、形式を検証した値を埋めて SPARQL を組みます。Neptune から返る結果には、事実の所在グラフから回収した出典と鮮度が付いており、最後に Claude Sonnet がその結果だけを根拠に日本語の回答文へ整形します。 鍵は、LLM に許す出力を狭く固定することです。意図は「従業員照会」「空席」「グループ構造」「時点断面」といった、あらかじめ定義した限られた選択肢からしか選べないようにします。語彙にない質問は「その他」に落とし、無理にクエリを組み立てません。取り出したパラメータ（従業員番号や日付など）も、形式や質問文中に実在するかを検証してから使います。LLM がクエリを創作する余地がないので、構文エラーも語彙のハルシネーションも原理的に起きません。 この設計には、速度と安全性の面でも効果があります。LLM に生成させるのは短い意図データだけなので、長いクエリを書かせる場合より応答が大幅に速くなります。テンプレートに渡す値も検証済みのものだけなので、インジェクションのような注入も成立しません。 共通オントロジーは、質問応答で使う概念や関係の定義も担います。意図の選択肢、パラメータの検証、テンプレートは、すべてオントロジーで定義した語彙に紐づいています。この語彙を統合の基準として使うとともに、LLM が選べる検索条件を限定する基準にもしています。 推論と制約検証の実装 取込処理では、 OWL推論による分類・関係の導出、Python／SPARQLによる派生データの生成、SHACLによるデータの制約検証 を行います。OWL推論で得られるのは新しい分類や関係であり、SHACL制約検証で得られるのは、データが定義した条件を満たすかを確認した結果です。 これらの処理は取込用の Lambda で実行します。現在の実装は、元データを Neptune に保存し、推論・派生結果を追加した後に、元データを対象として制約検証を実行する順序です。検索時には、保存済みの分類や関係を利用します。 以下では、処理を説明するための架空の従業員Aと勤怠レコードBを用いて、入力から何が得られるかを示します。 OWL推論：評価データから昇進候補を算出 例えば、従業員Aに2025年上期・下期の評価レコードが結び付き、どちらも S 評価だったとします。現行のオントロジーには、この2期の評価条件を満たす従業員を昇進候補とする定義があります。OWL推論によって「従業員Aは昇進候補である」という分類が導出され、 orca:PromotionCandidate 型を付与するトリプルがグラフに追加されます。これにより、昇進候補を検索するクエリで従業員Aを取得できます。 推論エンジンには、Python ライブラリの owlrl を使用し、 OWL 2 RL/RDF ルールを適用しています。データから新しい事実を導く前向き推論（forward chaining）で、新しいトリプルが増えなくなるまでルールを適用します。なお、オントロジーには厳密な OWL 2 RL プロファイルの構文制約を外れる定義も含むため、ここでは実際に使用する推論ルールを明示しています。 昇進候補などの分類を複数の質問で再利用できるよう、取込時に推論結果を保存し、検索時はその結果を取得する構成としています。このため、求める結論から推論ルールを逆にたどって条件を確認する後ろ向き推論は使用していません。 分類条件は、 owl:equivalentClass などの OWL 公理 で表し、Turtle 形式で記述します。クラスや関係の定義である TBox と、従業員や評価などの個体データである ABox を同じグラフに読み込んで推論します。主な用途は、従業員がどの分類に属するか、どの対象と関係するかを導出する ABox の実体化です。適用するルールには、クラス階層などの TBox 側の関係を導出するものも含まれます。 日付の比較、回数の集計、順序付けを伴う処理は、 Python／SPARQL で計算します。例えば、現在有効な配属からポジションの充足関係を求め、その結果を補助トリプルとして追加してから OWL 推論を実行します。こうして、手続き的に計算した結果も、宣言的な分類条件の入力として使います。 SHACL制約検証：条件に違反する勤怠データを報告する データの制約検証には、 SHACL-SPARQL と、その検証エンジンである pyshacl を使用します。検証対象や違反条件を SHACL の形状として記述し、条件の判定に SPARQL を使います。ここで確認するのは、入力データが定義した制約を満たしているかどうかです。 例えば、勤怠レコードBの種別が「残業」で、時間が50時間だったとします。現行の制約は、残業の勤怠エントリごとに時間が45時間を超えているかを確認します。この例では、勤怠レコードBが閾値を超えるものとして検出され、対象レコードと違反メッセージを含む検証結果が返されます。 検証時の追加推論は無効にしています。取込処理は、検証結果から対象レコードの識別子を取り出し、違反件数と識別子の例をログに記録します。取込処理の戻り値には違反件数を含めます。 推論結果の保存と再利用 グラフに追加するのは、推論・派生処理後のグラフから、元データと元のスキーマに存在するトリプルを除いたものです。追加トリプル数には、OWL推論による導出と、Python／SPARQLによる派生生成の両方が含まれます。 もう1つ重要なのが決定論性です。基準日・評価対象の期・閾値を固定し、同じ入力データ・定義・実行条件から同じ導出結果を得られるようにしています。保存した分類を使うことで、「昇進候補を挙げて」という質問のたびに評価条件を計算する必要がなくなり、検索クエリを単純に保てます。 まとめ 本記事の設計を貫いているのは、「決定論に書けるものは決定論に寄せ、LLM は意図の解釈だけに使う」という方針です。 設計 方針 オントロジーの設計 業界標準（HR Open 4.5）を共通の定義とし、取込と検索を同じ語彙で書く。履歴・空席・時点断面という業務要件をクラス設計に反映する 質問応答の設計 LLM に意図を解釈させ、クエリは検証済みテンプレートで決定論的に組み立てる。共通語彙に沿って検索条件を限定し、速度を上げ、構文エラーや注入を防ぐ 推論・制約検証の実装 分類・関係はOWL推論、集計や順序付けはPython／SPARQL、データの制約検証はSHACLで処理する。推論・派生結果を保存して検索に使い、制約違反は検証結果として記録する この3つの設計で、HR で「出典と鮮度つきで正確に答える」質問応答が成立します。意味の近い文章を取得するだけでなく、オントロジーで定義した関係や条件をたどって答えることが、労務管理や人事の意思決定に使える質問応答の条件だと考えています。 本記事では、HR Open Standards を使って業務上の概念や関係を定義し、その共通オントロジーをデータ統合、LLM の検索条件の制御、取込時の推論に使う設計を紹介しました。オントロジーを業務要件と具体的な処理に結び付けることが、この設計の要点です。   このブログの著者 安達 翔平 (さばみそ) アマゾン ウェブ サービス ジャパン合同会社 ISV/SaaS ソリューションアーキテクト 和智 大二郎 アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト

イントロダクション 送配電事業（ T ransmission & D istribution Business）に携わる皆様は、これまでにない変化の波を肌で感じていらっしゃるのではないでしょうか。熟練技術者の高齢化や定年退職が加速し暗黙知が失われる一方で、再エネ大量導入に伴う系統の複雑化、設備の老朽化と新規投資の削減圧力、そして量子コンピュータ時代を見据えたサイバー脅威の高度化 ― 複合的な課題が同時に押し寄せ、従来の「人海戦術＋経験則」だけでは対処しきれない時代が到来しています。 こうした業界共通の課題を議論し、クラウドと AI による新たな解決策の可能性を探る場として、2026 年 8 月 7 日に電気新聞（日本電気協会新聞部）主催・アマゾン ウェブ サービス ジャパン合同会社（AWS）協賛にて「 T&D エグゼクティブ・ラウンドテーブル ～送配電事業におけるクラウド活用と AI 技術の最前線～ 」を開催しました。 本セミナーでは、構造変化を「 守る （量子・AI 時代のセキュリティ対応）」「 支える （インフラ保守の高度化・自律化）」「 備える （AI Ready となる仕組みづくり）」の 3 つの視点から捉え、4 つの講演を通じて具体的な事例と知見を共有しました。本記事ではその概要と当日の様子をお伝えします。 イベント概要 項目 内容 イベント名 T&D エグゼクティブ・ラウンドテーブル「送配電事業におけるクラウド活用とAI技術の最前線」 日時 2026 年 8 月 7 日（金）14:00〜17:00 会場 日本電気協会・会議室（東京都千代田区有楽町 電気ビル北館 4 階） 主催 / 協賛 電気新聞（日本電気協会新聞部）/ アマゾン ウェブ サービス ジャパン合同会社 対象 送配電事業者の皆様 参加者 61 名（32 社・組織） 全国の送配電事業者を中心に 32 社・組織から 61 名にご参加いただきました。 電気新聞主催・AWS協賛「T&Dエグゼクティブ・ラウンドテーブル」会場案内板 講演プログラム オープニング アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 エンタープライズ事業統括本部長 堤 浩幸 テクノロジーの進化、グローバル化の進展、人口構成の変化、社会変容、エネルギー・環境問題の深刻化という「未来を形作る 5 つの要因」を概観した上で、送配電事業を取り巻く 4 つの構造変化 ― 人的リソースの枯渇、系統複雑性の爆発、設備投資の膨張、サイバー脅威の高度化 ― を整理しました。そして本セミナーの 3 つの視点「守る」「支える」「備える」を提示し、各講演への導入としました。 オープニングで講演する AWS 常務執行役員 エンタープライズ事業統括本部長 堤 浩幸 講演① 量子時代のサイバーセキュリティと電力インフラの課題 ―「守る」 株式会社東芝 ICTソリューション事業部 QKD事業推進室 シニアフェロー 村井 信哉 氏 株式会社東芝 総合研究所 AIデジタルR&Dセンター セキュリティ基盤研究室 エキスパート 秋山 浩一郎 氏 電力インフラにとって、サイバーセキュリティは「いつか対応すればよい」課題ではなくなりつつあります。東芝の村井氏・秋山氏からは、量子コンピュータの出現がもたらすリスクとその対策について解説いただきました。 量子コンピュータが既存の公開鍵暗号（RSA 等）を解読可能になる日 ―「Q-Day」― は 2030 年代前半と予測されています。しかし問題は Q-Day だけではありません。攻撃者が現在の暗号通信を傍受・蓄積しておき、将来の量子コンピュータで解読する「データ・ハーベスティング攻撃」が存在するため、5 年後・10 年後も価値を持つ長期秘匿データは 今すでにリスクにさらされている のです。 送配電事業にとって特に重要な点として、情報漏えいだけでなく 改ざんやなりすまし が生じうることが挙げられます。スマートメーターや制御系システムなど、フィールドに展開される長寿命インフラはハードウェア改修に長い期間を要するため、通常の IT システムよりも早い段階で対策の計画を立てる必要があります。 対策技術としては、拠点間の回線防護に適した QKD（量子鍵配送） と、ソフトウェア実装によりフィールド機器にも展開可能な PQC（耐量子計算機暗号） の 2 つが紹介されました。両技術は相互補完的であり、ネットワーク拠点間には QKD を、フィールド側には PQC を適用する「ハイブリッド対策」が有効とされています。 村井氏は「Q-Day がいつ来るかの予測は難しいが、今から複数のシナリオに備え、計画的に移行を進めることが重要」と強調しました。 量子コンピュータがもたらす脅威について解説する村井氏 QKD・PQC の対策技術について解説する秋山氏 講演② 通信業界におけるクラウド活用と AI によるオペレーション変革 ―「支える」 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト 宮崎 友貴 送配電事業と通信事業には多くの共通点があります。ともに 24 時間 365 日の安定運用を担い、膨大なフィールド設備を保守し、社会インフラとしての高い信頼性が求められます。そして、熟練オペレーターの高齢化・不足やシステムの複雑化による運用負荷の増大という課題も同様です。 本講演では、こうした共通課題に対して通信業界がどのようにクラウドと AI を活用しているかを、大手通信事業者 3 社の事例を交えて紹介しました。 NTT ドコモ ― 100 万台超のネットワーク機器の障害対応を、自律的に思考・行動する AI エージェント（Agentic AI）で自律化。異常検知から被疑箇所の推定・措置提案までを AI が自動実行することで、障害復旧時間の大幅短縮を実現しています。なお、本取り組みの詳細は「 NTT ドコモ、AWS 上で 5G コアネットワークの商用運用を開始 」でも紹介されています。 KDDI ― 基地局のトラフィック増加を AI で予測し、無線基地局の負荷を事前に分散・最適化。開発プロセスにも AI を組み込み、基地局パラメータの全国展開期間を約 50% 短縮しています。 ソフトバンク ― ネットワーク全体のトポロジー情報をグラフ DB で管理し、時系列の状態変化をリアルタイムに可視化。「障害発生前後でネットワークがどう変わったか」を即座に比較できる環境を構築し、原因特定の高速化に活用しています。 3 社に共通する特徴として、「定型作業の自動化」にとどまらず、「ゴールに対して AI が自ら考えながらタスクを遂行する自律化」を目指している点が挙げられます。通信業界の標準化団体（TM Forum）も「自律ネットワーク」を業界共通のゴールとして定義しており、AI Agent とデータ基盤の整備がその実現に不可欠な要素として位置づけられています。 エネルギー業界においても「データはあるが活用できる状態にない」という課題は広く共有されています。通信業界の事例は、自律化への道のりは一朝一夕ではないものの、クラウドを活用して「まず小さく始め、データを蓄積しながら段階的にスケールする」アプローチが有効であることを示しています。 通信業界の AI 活用事例を紹介する AWS ソリューションアーキテクト 宮崎 友貴 講演③ モバイルネットワークの自律オペレーションを実現する自動化とAI活用 ―「支える」 株式会社NTTドコモ サービスオペレーション部 オペレーションシステムデザイン室 担当課長 今井 識 氏 NTT ドコモでオペレーション変革を推進する今井氏が、100 万台超のネットワーク機器を AI で自律運用する取り組みの詳細を共有しました。 講演ではまず、取り組みの背景となる 3 つの課題が示されました。 社会インフラとしての通信の重要性が増大し、重大事故と見なされるケースが拡大傾向。30 分以内の初報が求められる報告制度改正もあり、迅速な対応が不可欠に ハードウェアとソフトウェアの分離（Open RAN 化）によりシステムが複雑化し、従来の人手による運用では対処しきれなくなっている 熟練オペレーターの高齢化・不足が進行 これらは、送配電事業が直面する「人材不足 × システム複雑化 × 運用負荷の増大」の構図と重なる課題です。 NTT ドコモはこれらの課題に対し、複数の AI エージェントが連携してネットワーク保守を自律的に遂行する仕組みを構築しました。観察系エージェントがリアルタイムにデータを収集し、被疑箇所推定エージェントが分析を行うことで、人がエスカレーション判断を行う段階ではすでに必要な情報が揃っている状態を実現しています。この仕組みはグラフ DB を中心に AWS のサービスを組み合わせて構築され、2026 年 2 月に商用利用を開始。複雑故障のリカバリ時間を 50% 以上短縮する成果をあげています。 NTTドコモの自律オペレーションへの取り組みを紹介する今井氏 講演④ 自律運用グリッドへの道筋 ―「備える」 アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 技術統括本部長 巨勢 泰宏 送配電事業における 4 つの構造変化を踏まえ、AI を活用した「自律運用グリッド」のロードマップを提示しました。 AWS は世界各地でエネルギー事業者のクラウド活用を支援しており、また自社のグローバルインフラを 24 時間 365 日運用する中で培ったオペレーション自動化の知見を持っています。こうした経験を踏まえ、送配電事業の課題解決に向けた具体的なアプローチを提案しました。 海外事例として以下を紹介しました。 Duke Energy （米国）― 系統連系申請の審査自動化。膨大な申請書類の処理を AI で効率化 GE Vernova （米国）― 復旧作業者の最適配置。災害時に限られた人的リソースを最も効果的に配置 Endeavour Energy （豪州）― ドローンによる自律点検で点検時間を 70% 削減 自律運用グリッド実現に向けて、 セキュアインフラ × データ × AI エージェント の 3 要素を組み合わせることが鍵であり、その第一歩は「データの整備」から始まるという提言がなされました。 自律運用グリッドへのロードマップを提示する AWS 常務執行役員 技術統括本部長 巨勢 泰宏 参加者の声 アンケートでは 5 点満点中 4.8 という高い満足度をいただきました（「大変満足」+「やや満足」= 100%）。自由記述の一部をご紹介します。 「クラウドと AI の活用は早期に実現する必要がある。先駆者の取り組みや苦労話を聞けたのは非常に勉強になった」 「通信での AI 活用の実践が数年後の電力に届くシナリオがよく理解できた」 「いずれのトピックも、これからの送配電事業の在り方を考えさせられる内容だった」 「量子コンピュータの出現に備えてセキュリティ対策を施しておかねばならないとの指摘に目が覚める思い」 「通信業界の OT 活用が進んでいることに感銘した」 「データ利活用について、自社でも取り組んでいる最中であり大変参考になった」 おわりに 今回のセミナーでは、業界や企業の垣根を越えて「自社も同じ課題を抱えている」と共感し合う場面が多く見られました。通信インフラと電力インフラは共に社会を支える基盤であり、直面する構造的な課題 ― 人材不足、システムの複雑化、セキュリティの高度化 ― には多くの共通点があります。他業界の先行事例を知ることで、各社の次の取り組みを具体化する一助となれば幸いです。 AWS では今後もエネルギー業界のお客様に対し、最新の技術や世界中の業界を超えた実践知をお届けしながら、社会インフラの持続的な発展に貢献してまいります。 著者について 宮城 康暢（Koyo Miyagi） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。前職にて IaaS やストレージサービスの企画・開発に従事した後、2022 年に AWS に入社。AWS ではエネルギー業界のお客様およびパートナー様の技術支援を担当しています。

Claude Opus 5.5 が 2026 年 9 月 28 日より Kiro IDE 、 CLI 、 Crew 、 Web のすべてで利用可能になりました。 Anthropic のこれまでで最も高性能な Opus モデル であり、ほとんどの作業において Fable 5.1 と同等の性能を、Opus 5 より 40% 低いコストで提供します。 コーディングとナレッジワークで最高水準の性能 エージェント的なコーディングにおいて、Opus 5.5 は何かを変更する前に根本原因を突き止め、作業しながら自分の仕事を検証します。そのため、変更内容はレビューしやすく、信頼しやすいものになります。Opus 5.5 は従来のモデルよりも自然にコミュニケーションし、最も重要な情報を先に置くため、書かれた内容は明快で追いやすくなっています。Amazon 社内のベンチマークでは、Opus 5.5 はツール呼び出しを約 40% 減らし、トークン消費を半分に抑えながら、Opus 5 を上回る結果を示しました。 「エージェントが行う呼び出しの一つ一つが、開発者にとっての時間とコストになります。実際のコマンドラインタスクを対象とした公開ベンチマークにおいて、Opus 5.5 は Opus 5 よりも多くの課題を解決しながら、呼び出し回数を約 40% 減らし、トークン消費を半分に抑えました。Kiro で開発する方にとってこれは、日常的なタスクから複雑な課題まで、エージェントセッションがより速く、より安価になることを意味します。」 — Deepak Singh, VP of Agentic AI at AWS セーフガードについて Opus 5.5 は、生物学とサイバーセキュリティの領域において Claude Mythos 5.1 と同等であり、Claude Fable 5.1 と同様のセーフガードを備えています。日常的なコーディング、健康、教育に関する質問はこれまでと同様に機能し、リスクの高い一部のリクエストはブロックされます。無害なタスクで誤検知に遭遇した場合は、Kiro で別のモデルに切り替えてください。 提供状況 Claude Opus 5.5 は、us-east-1 (IAD) および eu-central-1 (FRA) の Kiro Pro、Pro+、Pro Max、Power をご利用のお客様に対して、 実験的サポート として段階的に展開されています。 1M のフルコンテキストウィンドウと 2 倍のクレジット乗数 で提供されます。 最新の利用可能なモデルを確認するには、 Kiro をダウンロード するか、Kiro IDE、CLI、Crew を再起動してください。 Web をご利用の方 はブラウザを再読み込みすると、モデルセレクターに Claude Opus 5.5 が表示されます。 この記事は Kiro ブログの Claude Opus 5.5 is now available in Kiro を翻訳したものです。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 すっかり秋めいてきて、朝晩は肌寒さを感じる日も増えてきましたね。今週は Claude Opus 5.5 や OpenAI GPT-6 Sol / Luna の Amazon Bedrock 提供開始、Amazon Connect のエージェント間コラボレーション、AI ネイティブなオブザーバビリティ Amazon CloudWatch Omni など、AI エージェント関連のアップデートが目白押しでした。そんな AI の盛り上がりは、そのままイベントシーズンの秋にも続きます。10/13（火）〜 16（金） に幕張メッセで開催される CEATEC 2026 に AWS ジャパンがブース出展し、Physical AI の展示を予定しています。来場事前登録も始まっていますので、ぜひチェックしてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年9月21日週の主要なアップデート 9/22(火) Amazon Connect Customer がエージェント間コラボレーションに対応 Amazon Connect Customer が、ライブの顧客対応中に複数の AI エージェントが連携するエージェント間コラボレーションに対応しました。Connect Customer 内の AI エージェント同士だけでなく、Amazon Bedrock AgentCore 上のエージェントやサードパーティ製の外部 AI エージェントとも、オープン標準の A2A (Agent2Agent) プロトコルを介してテキストまたは双方向音声で連携できます。AWS は Linux Foundation の A2A 技術運営委員会と協力し、音声ストリーミングとインタラクション単位のセッション継続性をプロトコルに追加しました。すべてのエージェントの発話・ツール呼び出し・所要時間は単一のコンタクトレコードに記録され、分析と AI 品質管理に利用できます。 AWS Security Hub AI Inventory が Azure セルフホストインスタンスのサポートを追加 AWS Security Hub の AI Inventory 機能が、Microsoft Azure の仮想マシン上で稼働するセルフホスト型 AI アセットの検出とカタログ化に対応しました。Amazon Inspector の SBOM (ソフトウェア部品表) 分析が強化され、Azure VM 上の推論エンドポイント、モデル、AI エージェント (Ollama、vLLM、Hugging Face TGI など) を識別できます。検出された AI アセットは基盤インフラにマッピングされ、セキュリティ検出結果と関連付けられるため、AWS と Azure をまたいだ組織全体の AI インベントリをフィルタリング、グループ化、クエリできます。本機能は Security Hub Essentials に追加料金なしで含まれ、Security Hub が提供されるすべての AWS 商用リージョンで利用できます。 AWS Glue Data Quality がコンテキストに応じたルール推奨を数秒で提供 AWS Glue Data Quality のルール推奨機能に、新しい ADVANCED モードが追加されました。Amazon Bedrock の生成 AI がテーブルのメタデータとサンプル行からデータの意図を検出し、全カラムをカバーする DQDL ルールを数秒で提案します。従来の統計ベース (BASIC モード) では導出できなかった、データの利用実態を反映したビジネスルールを提案できる点が特徴です。ユーザーは推奨されたルールをレビュー・調整してルールセットとして保存すれば、すぐにデータ品質のモニタリングを開始できます。東京リージョン、大阪リージョンを含む 17 リージョンで利用できます。 Claude Opus 5.5 が AWS で利用可能に Anthropic の最上位モデル Claude Opus 5.5 が 2026 年 9 月 22 日から AWS で利用できます。Claude 5.5 モデルファミリーの第 1 弾で、長時間のコーディングやナレッジワークを対象とし、実行内容・発見事項・次に必要なことを報告しながら動作します。価格は 100 万トークンあたり入力 4 ドル、出力 20 ドルで、Opus 5 から 20% 値下げされ、キャッシュ読み取りは 0.20 ドルと 60% 値下げされました。トークン消費量の削減と合わせ、典型的なワークロードで総コストは約 40% 下がります。提供経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、東京リージョンからは日本国内 (東京・大阪) にデータを閉じた geo（地理）ベースのクロスリージョンで利用できます。 OpenAI GPT-6 Sol および GPT-6 Luna が Amazon Bedrock で一般提供開始 AWS は 2026 年 9 月 22 日、OpenAI の GPT-6 Sol と GPT-6 Luna を Amazon Bedrock で一般提供開始しました。9 月 8 日に提供開始した最上位モデル GPT-6 Astra に続くもので、GPT-6 ファミリーは 3 モデル構成になります。Sol はソフトウェア開発や反復的な複雑タスク向けの日常用モデルで、OpenAI 社内の事実性評価では GPT-5.6 Sol と比較して誤りの数が約半分です。Luna は要約・抽出・分類・ルーティングなど大量処理向けの効率重視モデルで、リクエスト単位で reasoning effort を調整できます。両モデルとも最大 1M トークンのコンテキストに対応します。 Billing Transfer が 2 階層転送でのビリンググループ自動作成に対応 AWS Billing Transfer に、AWS Billing Conductor の新しい設定「Auto-Billing Transfer Billing Group Creation」が追加されました。2 階層 (two-level) の請求転送において、エンドカスタマーがセラーパートナーからの請求転送を承諾した時点で、ビル受領者 (ディストリビューター) のアカウントにビリンググループが自動作成されます。従来は転送ごとに手動でビリンググループを作成する必要があり、設定漏れがあるとプロフォーマコストデータを参照できませんでした。設定はインバウンド転送ごとに 1 回行うだけでよく、自動作成されるビリンググループに適用する料金プランも指定できます。新しい 2 つの API (UpdateBillingTransferPreference、GetBillingTransferPreference) とマネジメントコンソールの Billing Transfer 詳細ページから設定できます。 9/23(水) Amazon CloudWatch Omni: エージェントとアプリケーションのための AI ファーストオブザーバビリティ Amazon CloudWatch Omni が一般提供を開始しました。Omni は CloudWatch の進化版として位置づけられる AI 活用型のオブザーバビリティ体験で、アプリケーションと AI エージェントを 1 つの場所で観測・トラブルシューティングできます。AWS コンソールの外にある専用 URL と SSO でサインインするスタンドアロン Web 体験、および VS Code / Cursor / Kiro 向けの IDE 拡張機能として提供されます。OpenTelemetry を基盤とし、既存の CloudWatch テレメトリは再設定なしでそのまま表示され、Azure VM や AKS 上のワークロードも監視対象にできます。LangGraph、CrewAI、OpenAI Agents SDK、Vercel AI SDK、Strands などのフレームワークに対応した評価駆動のエージェント開発ワークフローを備え、バージニア北部リージョン、オレゴンリージョン、アイルランドリージョンで利用できます。 Amazon Bedrock Managed Knowledge Base が Salesforce と Zendesk のネイティブデータソースコネクタに対応 Amazon Bedrock Managed Knowledge Base (フルマネージド RAG サービス) に、Salesforce と Zendesk のネイティブデータソースコネクタが追加されました。Salesforce の Knowledge 記事とドキュメント、Zendesk のヘルプセンター記事とコミュニティ投稿を、認証情報を設定するだけでナレッジベースに同期できます。従来必要だったカスタムインジェストパイプラインの構築が不要になり、クロール、メタデータ抽出、増分同期をコネクタが自動で処理します。同期スケジュール (日次・週次・月次) の設定にも対応し、サポートナレッジを最新の状態に保った AI アシスタントを構築できます。 9/24(木) スケーラブルな LLM 推論のための Amazon SageMaker HyperPod Inference Gateway Amazon SageMaker HyperPod Inference Gateway は、EKS 上の HyperPod クラスタ向けの Kubernetes ネイティブな LLM 推論ルーティング層です。従来のラウンドロビン方式に代わり、KV キャッシュ使用率やキュー深度など 6 つの推論シグナルで各モデルサーバー Pod をリアルタイムにスコアリングし、リクエストごとに最適な Pod を選択します。混合 GPU 世代やバーストトラフィックのシナリオで p99 TTFT を 97–98% 削減し、最初のトークンまでの遅延を最大 82% 短縮します (4.4 秒 → 800 ms 未満)。HyperPod Inference EKS アドオン v2.0.0-eksbuild.2 として提供され、アプリケーションコードの変更なしで vLLM や SGLang などの OpenAI 互換モデルサーバーと組み合わせて利用できます。 9/25(金) AWS End User Messaging と Amazon SES が AWS MCP Server 向けの AI agent skills を提供開始 AWS End User Messaging と Amazon SES が、AWS MCP Server 向けの AI agent skills を公開しました。開発者は Claude Code、Codex、Cursor、Kiro などの AI コーディングエージェントに自然言語で指示するだけで、送信 ID の検証、RCS エージェントの構築、本番メールの送信といったメッセージングタスクを完了できます。skills は amazon-ses、aws-sms-voice、aws-social-messaging の 3 種類が GitHub の Agent Toolkit for AWS リポジトリ (Apache-2.0 ライセンス) で公開されており、追加料金なしで利用できます。これまで複数のドキュメントページとコンソール画面を行き来していた作業を、エージェントとの対話だけで進められるようになります。 AWS End User Messaging が WhatsApp での音声通話に対応 AWS End User Messaging Social で、WhatsApp 上の音声通話の発着信ができるようになりました。メッセージングに使用している検証済みのビジネス電話番号をそのまま使い、チャットスレッドから離れずに通話へ移行できます。顧客からビジネスへの発信と、通話許可を得た顧客へのビジネスからの発信の双方向に対応します。有効化と管理はコンソールまたは API で行い、AWS End User Messaging Social が利用可能なすべてのリージョン (東京リージョン、大阪リージョンを含む 34 リージョン) で利用できます。 AWS Elastic Disaster Recovery が AWS Graviton ベースのソースサーバーをサポート AWS Elastic Disaster Recovery (AWS DRS) が、AWS Graviton ベース (arm64) の EC2 インスタンスをソースサーバーとしてサポートしました。DRS は arm64 ソースサーバーを自動検出し、Graviton インスタンスへ復旧するため、ワークロードのアーキテクチャを維持したまま DR を構成できます。x86 ワークロードと同じ操作で利用でき、追加設定や追加料金は不要です。対象は AWS 上の Graviton インスタンスから AWS への復旧 (AWS-to-AWS) に限定され、オンプレミスや他クラウドの arm64 サーバーは対象外です。DRS が利用可能なすべてのリージョンで提供されます。 AWS DataSync がアカウント全体のタスク実行を追跡するモニタリングダッシュボードを提供開始 AWS DataSync のコンソールに、アカウント内のタスク実行を一覧できるモニタリングダッシュボードが追加されました。各タスク実行のステータス、データおよびファイルの転送レート、所要時間、転送済みデータ量とファイル数を 1 つの画面で確認できます。従来は実行を個別に確認するか、カスタムの Amazon CloudWatch ダッシュボードを構築する必要がありました。追加料金は不要で、DataSync が利用可能なすべての商用リージョンと AWS GovCloud (US) リージョンで利用できます。 今週振り返ってみると、華やかな新モデルの話題の裏で、AWS Glue Data Quality のルール推奨や AWS Elastic Disaster Recovery の Graviton 対応、DataSync のモニタリングダッシュボードなど、日々の運用をそっと楽にしてくれるアップデートが着実に積み上がっているのが印象的でした。派手さはなくとも、こうした改善の積み重ねが現場を支えてくれますね。次回もお楽しみに。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本ブログは 2021 年 10 月 11 日に公開された AWS Blog “ Exploring Simon’s Algorithm with Daniel Simon ” を翻訳したものです。 はじめに 量子コンピューティングに取り組み始めたお客様は、基礎を学ぶときや新しいサービスを評価するときに、既知のアルゴリズムを活用することがよくあります。Amazon Braket では、そうしたアルゴリズムを SDK とマネージドノートブックに多数用意しています。この記事では、最初期に考案された量子アルゴリズムの 1 つであり、Amazon Braket のサンプルとして公開されている Simon のアルゴリズムを取り上げます。まずアルゴリズムの背景にある理論を説明し、続いて Amazon Braket を使って Simon のアルゴリズムをエンドツーエンドで実装します。さらに、Simon のアルゴリズムの考案者で AWS Cryptography の Principal Security Engineer である Daniel Simon が、自身の名を冠したアルゴリズムについて当時の背景や着想を語ります。 この記事は、Simon のアルゴリズムのサンプル Jupyter Notebook を補足するものです。このノートブックは、Amazon Braket のマネージドノートブックインスタンスを起動してサンプルノートブックのセクションを開くか、オープンソースの amazon-braket-examples GitHub リポジトリ を参照することで入手できます。より詳しい内容はノートブックをご覧ください。 Amazon Braket サンプル GitHub リポジトリ には、他の重要な量子アルゴリズムの実装も公開されています。 Simon のアルゴリズム Simon のアルゴリズムは、量子コンピュータで特定の問題を解くことにより、既知の最良の古典アルゴリズムに対して指数関数的な高速化を達成した最初の例です。1994 年に発表されたこのアルゴリズムは、よく知られた Shor の素因数分解アルゴリズムの先駆けとなり、その後の量子計算分野における多くの重要な研究に着想を与えました。 Daniel Simon: 「少し面白い経緯をお話しします。私は自分のアルゴリズムを理論計算機科学の学会 (STOC 1993) に投稿しましたが、採択されませんでした。しかし、その学会のプログラム委員会に Peter Shor がいて、同じアルゴリズム構造を素因数分解や離散対数といった具体的な問題に応用できる可能性 (正直に言えば、私はまったく気付いていませんでした) をすぐに見抜いたのです。Shor は私の論文を採択するよう委員会を説得しようとしましたが叶わず、そこで自身の研究に取り組み、次の主要な理論計算機科学の学会 (FOCS 1993) に投稿しました。私も同時に再投稿しました。実は、Shor の論文だけが採択された場合は 2 つの論文を統合することで合意していたのですが、さいわいにも委員会は両方を採択し、結果として得られた成果について、それぞれの貢献分を私たち双方に認めてくれました」 Simon の問題 Simon のアルゴリズムは、次の数学的問題を解くために設計されました。 ビット文字列をビット文字列に写す関数 f:{0,1} n →{0,1} n が与えられたとします。さらに、関数 f について、 次のいずれか が成り立つという約束 (promise) が与えられます。すなわち、入力ごとに異なる出力に写すか、あるいは異なる 2 つの入力を同じ 1 つの出力に写すかです。ただし、どちらであるかは知らされません。数学的には、 f が 1 対 1 (単射) か 2 対 1 のどちらかであり、次の約束が成り立つことを意味します。 これは、ある未知の n ビットの文字列 s∈{0,1} n に対して成り立ちます。ここで ⊕ は、ビットごとの mod 2 加算を表します。 別の言い方をすると、ある未知の文字列 s が存在し、すべての入力文字列 x に対して f(x)=f(x⊕s) が成り立ちます。 s がゼロでない場合、この関数が取る各出力値に ちょうど 2 つの入力が写るため、2 対 1 になります。 s がゼロ文字列の場合は 1 対 1 になります。 Simon のアルゴリズムの目的は f が 1 対 1 か 2 対 1 かを判定することであり、そのために秘密の文字列 s を直接求めます。実際、ここで考えているオラクルの設定では、 s を見つけることが元の問題を解くことと数学的に等価だと示せます。 Daniel Simon: 「 このアルゴリズムは『約束問題 (promise problem)』を解きます。つまり、特定の性質が約束されたオラクルの形で関数が与えられ、その約束が満たされている限り、アルゴリズムはその関数から関連する性質を引き出します。これは量子アルゴリズムにとって自然な対象です。『量子並列性』によって、指数関数的な大きさの入力空間にわたって関数を探索できるからです。量子アルゴリズムと古典アルゴリズムの差を示すこのアプローチを最初に提案したのは Deutsch と Jozsa でした。しかしこの試みは、決定論的な古典アルゴリズムと比べれば量子アルゴリズムが指数関数的に高速である一方、実際には古典的な確率的アルゴリズムで (指数関数的に小さい誤り確率で) 容易に解けてしまうものでした」 古典的な計算複雑性 Simon の問題を古典的に解くには、 f(x)=f(y) となる異なる 2 つの入力 x と y を見つけるか、あるいは同じ出力を生成する入力の組が存在しないことを示す必要があります。前者が見つかれば s=x⊕y (加算はビットごとに mod 2 で行います) が求まります。 Daniel Simon: 「これは正しくないかもしれません。関数 f の計算の詳細を何らかの方法で掘り下げることで、文字列 s を常に効率的に見つけられる魔法のようなアルゴリズムが存在する可能性もあります。しかし f をオラクルとして表現すれば、そうした仮想的な解法 (見つかることはほとんどありませんが、不可能だと証明されることもほとんどありません) を抽象化して排除できます。その結果 s を見つける道は、同じ出力を持つ入力の組を実際に見つけることだけになります」 関数 f がブラックボックスとして与えられたとき、同じ出力に写る異なる 2 つの入力を見つけるのはどれほど難しいのでしょうか。 n ビットの文字列の場合、考えられる入力は 2 n とおりあります。したがって最悪の場合、同じ出力に写る組を見つけるには最大 2 n 個の異なる入力を調べることになり、これが必要なクエリ複雑性の 上限 を与えます。では下限はどうでしょうか。古典的には Θ(2 n/2 ) 個の入力を調べる必要があることが示せますが、これも問題のサイズに対して指数関数的に増大します。この下限の直感的な理解は、(一般化された) 誕生日問題から得られます。ある集団の中で、2 人が同じ誕生日になる確率はどれくらいでしょうか。この問いを逆にして、「少なくとも 2 人が同じ誕生日である確率を一定の値より大きくするには、部屋に何人必要か」と考えることもできます。答えは、誕生日として考えられる日数 (つまり 365) の平方根程度の人数です。Simon の問題では、これは約 Θ(2 n/2 ) 個の入力を調べる必要があることに対応します。 Simon の問題に対する量子アルゴリズム Simon のアルゴリズムは、 指数関数的に 少ない回数のクエリを関数 f に行うだけで、前述の問題を解く手法です。このアルゴリズムが機能するには、未知の関数 f を量子論理ゲートで実装できる必要があります。言い換えると、ユニタリ演算子 U f によって、関数 f の作用を量子状態の変換としてエンコードする必要があります。具体的には次のようになります。 ここでの議論では、ユニタリ演算子 U f はブラックボックス (「オラクル」) として与えられ、内部の仕組みはわからないものの、前述の変換を実装していることはわかっていると仮定して構いません。オラクルモデルの利点の 1 つは、オラクルの動作原理を知る必要はなく、正しく動作することを信頼すればよい点です。Simon のアルゴリズムのノートブックでは、 f に対してよく使われるサンプルオラクルの実装を提供し、その仕組みと理由も詳しく説明しています。 量子回路 Daniel Simon: 「量子回路モデルと量子チューリングマシンモデルは等価ですが、このアルゴリズムを作った当時はそれを知らず、量子チューリングマシンの枠組みで考案しました。2 つのモデルの等価性は、その後すぐに Yao が示しています」 Simon のアルゴリズムは、量子的な部分と古典的な部分の両方から構成されます。量子部分はオラクルに効率的にクエリを実行するために使い、古典部分は測定結果を処理して隠された文字列 s を求めるために使います。量子部分の回路を次に示します。 Daniel Simon: 「この回路で最も印象的なのは、その単純さです。実際、量子計算の能力を示す例として最初に提案された Deutsch-Jozsa 回路よりもさらに単純です。そもそも、この単純なアルゴリズムは対応する問題よりも先に生まれました。私は (おそらく少々無謀にも) 古典計算が量子計算をシミュレートできることを証明しようと試みることから始めました。そして、素直な方法では古典シミュレーションが難しい設計のうち、自分が見つけられた最も単純なものがこの回路だったのです。そこでその性質を探り始め、最終的にはこの回路を基に、シミュレーションされにくいという振る舞いに合わせた問題を構成したのです」 関数 f が n ビットの文字列に作用する場合、上記の回路は 2n 量子ビットに作用します。これは U f の定義に必要な数です。測定するのは最初の n 量子ビットだけで、残りの量子ビットは U f を適用した後は使用しません。 数学的な詳細 この量子回路が、古典アルゴリズムよりも関数 f へのクエリ回数を指数関数的に少なく抑えて問題を解ける理由を理解するために、数学的な詳細にもう少し踏み込む必要があります。 Simon の問題を解くには、上記の量子回路を複数回実行します。回路を実行するたびに、最初の n 量子ビットの測定から出力ビット文字列が得られます。これを z と表します。 上記の回路を解析すると、各出力ビット文字列 z が次の条件を満たすことがわかります。 なぜこうなるのか、回路を段階的に解析して確認しましょう。各ステップの数学的な詳細は、付属のノートブックにすべて掲載されています。 すべての量子ビットを | 0 ⟩ 状態に初期化します。 最初の n 量子ビットのそれぞれにアダマールゲートを適用し、均等な重ね合わせ状態にします。 オラクル U f を適用します。これにより関数 f の計算結果が後半の n 量子ビットに書き込まれます。 後半の n 量子ビットを測定し、ランダムな結果 f(x) を得ます。 f が 1 対 1 の場合、この f の出力は入力 x に対応します。 f が 2 対 1 の場合、 f の出力は入力 x または y=x+s のいずれかに対応します。ここで x と y は f への 2 つの異なる入力で、 同じ 出力 f(x)=f(y) を与えます。なお、測定結果自体は使わないためこのステップは厳密には不要ですが、解析をわかりやすくするために含めています。 Daniel Simon: 私は確かにこのステップを実行することを想定していました。この単純化がなければ、アルゴリズムを考え抜くのはずっと難しかったでしょう…… 最初の n 量子ビットのそれぞれにアダマールゲートを適用します。 f が 1 対 1 の場合、状態 | x ⟩ は次のように写ります。 ここで x·z は、ベクトルとして表した 2 つの文字列の内積 (mod 2) です。 Daniel Simon: アダマールゲートが生み出す位相をこのように特徴づけられると気付くまでには、しばらく時間がかかりました。しかしこれが、アルゴリズムから興味深い情報を引き出す鍵になりました。論文発表前にバークレーで Ethan Bernstein と Umesh Vazirani へこのアルゴリズムを初めて説明したとき、私は誇らしげにこの重要な事実を指摘しました。すると Umesh はすぐにうなずいて「そうだね」と言い、あまりに当たり前のことを若手研究者に指摘された人特有の、うんざりした表情を浮かべたのです。2 人はこの事実にずっと前から気付いていて、単にそれをどう活用するかに思い至っていなかっただけなのは明らかでした。 同様に、 f が 2 対 1 の場合、状態 ( | x ⟩+| y ⟩ )/√2 は次のように写ります。 最初の n 量子ビットを測定します。 f が 1 対 1 の場合、測定によってランダムなビット文字列 z が得られます。この文字列は {0,1} n から一様に選ばれます。 f が 2 対 1 の場合、測定によってランダムなビット文字列 z が得られ、これは x·z=y·z mod 2 を満たします。そうでなければ振幅 (−1) (x·z) +(−1) (y·z) が打ち消し合ってしまうためです。Simon の問題の条件 (f(x)=f(y)⟹x=y⊕s) を使うと、次が得られます。 このように、どちらの場合も s·z=0 を満たすランダムなビット文字列 z が得られます。 したがって、上記の量子回路を実行するたびに、秘密の文字列 s と直交するビット文字列 z が 1 つ見つかります。 Daniel Simon: もともと私は、一般的な 1 対 1 の関数と 2 対 1 の関数を区別する方法を探していました。しかし、衝突する 2 つの入力の排他的論理和である s が、一般的な 2 対 1 の関数では任意に変化してしまうため行き詰まりました。最終的に、約束問題の「約束」として定義すれば s を関数全体で一定にできると思いつき、そこから結果が導かれたのです。 古典的な後処理 測定結果 {z 1 ,…,z k } から、連立方程式 {z k ·s=0 mod 2} を作れます。 方程式は k 個、未知数は n 個 ( s の各要素) です。量子部分を十分な回数実行して n 個の 独立 した方程式が得られれば、これらを (例えばガウスの消去法で) 解いて秘密の文字列 s を復元できます。必要となる古典的な後処理はまさにこれで、上記で得た連立方程式を解いて文字列 s を復元します。さらに詳しい内容は、ノートブックの付録を参照してください。 量子的な計算複雑性 上記の量子回路を O(n) 回実行すれば、 s を求めるのに使える n 個の線形独立な方程式が得られます。したがって Simon の問題は、 O(n) 回のクエリを U f に行うことで解けます。古典アルゴリズムには Ω(2 n/2 ) 回のクエリが必要なので、量子アルゴリズムによる 指数関数的な 高速化が示されます。 Amazon Braket での実装 まず、 simons_oracle という、 amazon-braket-examples リポジトリに実装されている メソッドをインポートします。このメソッドは、秘密の関数 f に対する特定の量子オラクルを実装したものです。この関数と量子実装の詳細は、ノートブックの付録で説明しています。 simons_oracle メソッドは秘密の文字列 s を受け取ります。この文字列は最初に決めておき、同じ文字列 s を復元することが目標になります。 # Implemented in NBI / example notebook utils from simons_utils import simons_oracle s = '101011' # Secret string n = len(s) circ = Circuit() # Apply Hadamard gates to the first n qubits circ.h(range(n)) # Apply the Oracle for f. See NBI / notebook for implementation circ.simons_oracle(s) # Apply Hadamard gates to the first n qubits circ.h(range(n)) print(circ) このコードスニペットは、次の回路を生成します。 T : |0| 1 | 2 |3|4|5|6| q0 : -H-C-----------C---C-C-C-H- | | | | | q1 : -H-|-C---------|-H-|-|-|--- | | | | | | q2 : -H-|-|-C-------|-H-|-|-|--- | | | | | | | q3 : -H-|-|-|-C-----|-H-|-|-|--- | | | | | | | | q4 : -H-|-|-|-|-C---|-H-|-|-|--- | | | | | | | | | q5 : -H-|-|-|-|-|-C-|-H-|-|-|--- | | | | | | | | | | q6 : ---X-|-|-|-|-|-X---|-|-|--- | | | | | | | | q7 : -----X-|-|-|-|-----|-|-|--- | | | | | | | q8 : -------X-|-|-|-----X-|-|--- | | | | | q9 : ---------X-|-|-------|-|--- | | | | q10 : -----------X-|-------X-|--- | | q11 : -------------X---------X--- T : |0| 1 | 2 |3|4|5|6| 次に、Amazon Braket のローカルシミュレーターでこの回路を 4n 回実行します。ショット数を 4n にすることで、 s を求めるのに使える線形独立なサンプルを、高い確率で少なくとも n 個得られます。 # Sets the device to run the circuit on device = LocalSimulator() # Run the circuit 4n times, should be sufficient to get n independent bit strings task = device.run(circ, shots=4*n) これで完了です。残りの処理はすべて古典的なものです。前述の「古典的な後処理」セクションで説明したとおり、これらの測定結果が連立一次方程式を定義し、それを解くことで古典的な文字列 s を復元できます。この例をご自身で通して実行したい場合は、 Simon のアルゴリズムのノートブック のコードを参照してください。このノートブックは Amazon Braket サンプルリポジトリ で公開されています。リポジトリ内のサンプルは Amazon Braket のノートブックにもプリインストールされているため、すぐに使い始められます。 まとめ Simon のアルゴリズムは、量子情報理論と量子計算の初期の基礎を築いた重要な成果です。今日では、実装が単純で 1 回の講義で扱えることから、量子情報理論を学ぶ学生に、コアカリキュラムの一部としてよく教えられています。しかし、このアルゴリズムには、その単純さからはうかがい知れない重要性があります。Simon のアルゴリズムで発見された概念は、今日の高度な量子アルゴリズムの多くにも見られます。 Grant Salton Grant Salton は Amazon Quantum Solutions Lab の Senior Research Scientist です。スタンフォード大学で博士号を取得し、量子情報理論、量子アルゴリズム、量子誤り訂正、近未来の量子デバイスの応用、そして基礎物理学の他分野 (例えば重力) における量子情報の役割を研究テーマとしています。Amazon に入社する前は、カリフォルニア工科大学 IQIM のポストドクトラルフェローを務めていました。 Daniel Simon Daniel Simon は AWS Cryptography グループの Principal Security Engineer です。25 年以上にわたり暗号技術と情報セキュリティに携わり、暗号技術、情報セキュリティ、量子計算に関する研究成果を発表しています。トロント大学でコンピュータサイエンスの博士号を取得しています。 Cedric Lin Cedric Yen-Yu Lin は Amazon Braket の Sr. Applied Scientist です。以前は Google でソフトウェアエンジニアとして勤務し、主に最適化に用いるデータパイプラインとアルゴリズムを設計・構築していました。マサチューセッツ工科大学で物理学の博士号を取得し、数年にわたり量子アルゴリズムの開発と、量子計算複雑性の手法を通じたその限界の解明に取り組んできました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 9 月 22 日に公開された Amazon News “ AWS becomes first cloud provider approved for NATO RESTRICTED workloads across all member nations ” を翻訳したものです。 この度 AWS は、NATO RESTRICTED レベルの情報を取り扱う用途において、すべての NATO 加盟国によるクラウドサービスの使用が承認された初のクラウドプロバイダーとなりました。 主なポイント NATO とその防衛産業パートナー、およびすべての加盟国は、承認済みの AWS サービスを使用して NATO RESTRICTED ワークロードを取り扱えるようになりました。 AWS が NATO 全体で承認されたことで、同盟国は、自国における AWS の認定を迅速に進めやすくなります。 AWS は NATO 加盟国内に 15 のリージョンを有しており、そのうち 7 リージョンはヨーロッパ大陸にあります。 Amazon Web Services (AWS) は、NATO RESTRICTED (NR) レベルの情報を取り扱う用途において、すべての 北大西洋条約機構 (NATO) 加盟国によるクラウドサービスの使用が承認された初のクラウドプロバイダーになったことを発表しました。 世界の防衛分野のお客様とパートナーにとってのメリット NATO とその防衛産業パートナー、およびすべての NATO 加盟国は、NATO 加盟国内にあるいずれの AWS リージョンでも、承認済みの AWS サービスを使用して NATO RESTRICTED ワークロードを取り扱えるようになりました。 NATO 加盟国向けプロセスの効率化: AWS の NR 承認が同盟全体に公開されたことで、NATO 加盟国とパートナーは、事前評価済みの共通セキュリティベースラインを継承できます。これは、セキュリティおよびコンプライアンス上の義務を果たすための時間、労力、コストの削減に役立ちます。 同盟国による AWS 認定の迅速化: AWS が NR 承認を取得したことで、NATO 同盟国は、自国の正式な認定手続きを通じて AWS をより迅速に認定できるようになります。 「商用テクノロジーを安全に活用する NATO の能力を強化することは、よりレジリエントで俊敏な同盟を構築するうえで重要です。NATO のセキュリティ要件を満たす商用製品が利用可能になることで、同盟のテクノロジーの選択肢が広がります。また、私たちの運用の基盤であるセキュリティとレジリエンスを維持しながら、最新のテクノロジーを導入していくための支えにもなります」と NATO 通信情報局 (NCIA) のゼネラルマネージャーである Dylan Browne 氏は述べています。 「初となる今回の承認は、長年にわたる継続的な取り組みの集大成です。これは、防衛、公共部門、NATO 関連のお客様やパートナーが重要なミッションを達成できるよう支援するという、私たちのコミットメントを表しています」と AWS Worldwide Public Sector のバイスプレジデント代行である David Appel は述べています。「政府、そして政府がサービスを提供する市民は、民間部門のイノベーションを推進しているのと同じインフラストラクチャとサービスを利用する機会が与えられるべきだと、私たちは考えています。同盟国がレジリエンスを強化し、市民を守るために必要な相互運用性を提供できるよう、今後も取り組みを続けていきます」 NATO RESTRICTED の承認プロセス 承認を得るために、AWS は D32 への準拠状況を文書化しました。NATO D32 は、パブリッククラウドで NR 情報を取り扱うためのセキュリティ要件を定めた技術指令です。このプロセスの一環として、AWS の各種サービスはスペイン国立暗号センター (CCN) による評価を受け、NATO によって承認され、すべての NATO 同盟国に公開されました。これにより、NATO 加盟国内にあるいずれの AWS リージョンでも、NR に対応したシステムの構築に AWS サービスを使用できるようになりました。現在、AWS は NATO 加盟国内に 15 の リージョン を有しており、そのうち 7 リージョンはヨーロッパ大陸にあります。NR 認定については、NATO がそのプロセスを、NATO 加盟国か、NATO のホスト国の役割を担う NCIA か、あるいはその両方に委任しています。 AWS の利用を開始する方法 国家安全保障および防衛分野のお客様は、今回の発表の基盤となる AWS Trusted Secure Enclaves – Sensitive Edition (TSE-SE) を利用できるほか、 防衛および国家安全保障向けの AWS ソリューション の詳細を確認できます。 お客様は AWS アカウントチームと連携して、今回の承認と TSE-SE をそれぞれのユースケースにどのように適用できるかを確認できます。 現在、15,000 を超える政府機関のお客様が AWS を利用しています。NATO RESTRICTED の承認を取得したことで、AWS は、世界中の政府機関や防衛組織のセキュリティニーズに応えるというコミットメントを改めて示しています。世界各地の主要な政府機関は、AWS を活用してコストを削減し、レジリエンスを高め、イノベーションを加速しています。今回の発表により、AWS と NATO は、同盟国がクラウドで重要なミッションを安全に遂行できるよう支援するうえで、共に大きな一歩を踏み出しました。 AWS について Amazon Web Services (AWS) は、お客様へのこだわり、イノベーションのスピード、オペレーショナルエクセレンスへのコミットメント、長期的な視点を指針としています。20 年近くにわたってテクノロジーを民主化し、あらゆる規模や業種の組織がクラウドコンピューティングと生成 AI を利用できるようにしてきたことで、AWS は史上最も急速に成長しているエンタープライズテクノロジービジネスの 1 つを築き上げました。数百万のお客様が、イノベーションの加速、ビジネスの変革、そして未来の創造を AWS に託しています。最も包括的な AI 機能と、世界規模で展開するインフラストラクチャにより、AWS はビルダーが大きなアイデアを実現できるよう支援しています。詳細については aws.amazon.com をご覧ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 1 週間で Kiro の使い方を学ぶオンラインチャレンジ Kiro University Challenge が始まっています。毎日公開される必須レッスン 7 本とボーナスレッスンを進め、最終課題を提出すると最大 5,250 の Kiro クレジットを獲得できます。参加費は無料で、Kiro の無料プランでも必須レッスンに取り組めます。最終課題の締切は日本時間 10 月 6 日 15:59 です。Spec 駆動開発や Steering をまとめて身につけたい方は、この機会にぜひ挑戦してみてください。 また、お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が予定されています。是非カレンダーをチェックしてご参加ください。 それでは、9 月 21 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「AI エージェントを組織構造に乗せる – PLAY が AWS DevOps Agent で築いた全社共通のインシデント対応基盤」を公開 株式会社 PLAY 様は、動画配信プラットフォームをはじめとする動画ソリューションを提供している企業です。複数のプロダクトが並行して稼働する中、本番エラーのたびにログ確認、コード調査、Issue 起票を手作業で行っており、一次調査だけで 1 件 15 分から 1 時間かかっていました。そこで AWS DevOps Agent を全社共通のインシデント対応基盤として導入し、エージェントに任せる範囲を一次トリアージに絞って 9 ステップのスキルファイルで明文化しました。類似アラートの判定やルーティングは共通基盤チームが、スキルの記述は各プロダクトチームが担う分担です。その結果、一次調査は 5〜10 分に短縮され、Slack 上の報告だけで対応が完結する割合は 7〜8 割に達しています。新しいプロダクトの追加は基盤側でルーティング設定 1 行で済み、すでに 4 プロダクトと 1 つのソリューション案件に展開されました。今後は確度の高いケースでの自動 PR 作成や、Blue/Green 切り戻しの自動化にも取り組む予定とのことです。 AWS生成AI国内事例ブログ「株式会社クリエイティブ・ウェブ様の AWS 開発事例『Amazon Connect Customer を活用した AI ロールプレイ研修システムの高速構築』のご紹介」を公開 株式会社クリエイティブ・ウェブ 様は、システムや PC サポート、Web サイト、EC 関連の問い合わせ対応サービスを提供している企業です。不動産管理会社のコールセンターでは、ロールプレイ研修にベテランを拘束するため回数を確保できず、評価も担当者ごとにばらつくという課題がありました。これを解決するため、Amazon Connect Customer の AI agents 機能が入居者役を演じ、通話後に Amazon Bedrock が 5 カテゴリ・100 点満点で自動評価する AI ロールプレイ研修システムを構築しました。水漏れや騒音トラブルなどのシナリオ、難易度、入電者の温度感を選べ、開発には OSS の AICC Builder を使ってプロトタイプの立ち上げを大幅に短縮しています。その結果、24 時間いつでも研修できるようになり、研修品質のばらつき解消と成長の定量的な把握につながりました。今後はシナリオの自動生成や他業界への展開、チャットやメールでのロールプレイも計画しているとのことです。 ブログ記事「Amazon CloudWatch Omni のご紹介：生成 AI およびエージェント型ワークロード向けの AI を活用したオブザーバビリティ」を公開 Amazon CloudWatch を進化させた AI 活用型のオブザーバビリティ、CloudWatch Omni の AI エージェント開発向けの機能を紹介する記事です。VS Code や Kiro の IDE 拡張機能から、LLM 呼び出しやツール呼び出しを階層表示する Trace Explorer、17 種類の組み込み評価、Playground、Experiments、Prompt Management を使えます。LangChain、CrewAI、Strands などに対応し、Amazon Bedrock AgentCore にもネイティブ対応しています。IDE 拡張機能は AWS アカウントなしでも試せるので、エージェントの品質評価に悩んでいる方はまず触ってみるのがおすすめです。運用チーム向けの SSO 対応 Web 体験や DevOps Agent との連携は、 アプリケーション向けの紹介記事 で解説されています。 ブログ記事「AWS for SAP MCP Server で実現する SAP へのシングルサインオン・エージェントアクセス」を公開 AI エージェントを共有のサービスユーザーで SAP に接続すると、実際に誰が操作したのかを認可・監査できません。この記事では、Amazon Quick、Amazon Bedrock AgentCore Runtime 上の AWS for SAP MCP Server、Microsoft Entra ID を組み合わせ、On-Behalf-Of トークン交換でユーザー ID を SAP まで伝播する手順を 8 ステップで解説しています。SAP パスワードを保存せず、Security Audit Log に個々のユーザーの操作として記録できるので、基幹システムにエージェントをつなぎたい方には必読です。 ブログ記事「AI-DLC（AI 駆動開発ライフサイクル）による SAP ABAP アプリケーション開発」を公開 Kiro と MCP サーバーの ABAP Accelerator を使い、AI-DLC の Inception、Construction、Operations の 3 フェーズで SAP S/4HANA 上にフライト予約アプリケーションを構築するウォークスルーを解説する記事です。AI が計画と質問を提示し、人が各ステップで承認しながら、構文チェック、ATC 検証、アクティベーションまで自動で進みます。意思決定は audit.md に記録されるため、監査を意識した ABAP 開発やレガシー ABAP のモダナイゼーションを考えている方の参考になります。 サービスアップデート Claude Opus 5.5 が AWS で利用可能に Anthropic の Claude 5.5 ファミリー最初のモデルである Claude Opus 5.5 が、Amazon Bedrock と Claude Platform on AWS で使えるようになりました。長時間のコーディングやナレッジワークをこなし、何をしたか、何がわかったか、次に何が必要かを明確に報告してくれます。Anthropic によると、Claude Opus 5 より少ないトークンでタスクを完了し、トークン単価やキャッシュ読み取りも安くなっています。同日に AWS GovCloud (US) でも提供 が始まりました。 OpenAI の GPT-6 Sol と GPT-6 Luna が Amazon Bedrock で一般提供開始 GPT-6 Astra に続き、GPT-6 ファミリーの Sol と Luna が Amazon Bedrock で一般提供されました。Sol は複雑なタスクやソフトウェア開発向けの日常使いモデルで、OpenAI 社内の事実性評価では GPT-5.6 Sol に比べて誤りが約半分です。Luna は要約、抽出、分類、ルーティングなど大量処理向けの効率的なモデルで、推論の度合いを調整できます。どちらも最大 100 万トークンのコンテキストに対応し、用途に合わせて性能・速度・コストを選び分けられます。 Amazon Bedrock マネージドナレッジベースが Salesforce および Zendesk をネイティブデータソースコネクタとしてサポート フルマネージドな RAG サービスである Amazon Bedrock マネージドナレッジベースに、Salesforce のナレッジ記事と、Zendesk の記事・コミュニティ投稿を同期するコネクタが加わりました。インスタンスの認証情報を入力するだけで、クローリング、メタデータ抽出、増分同期をコネクタが処理します。独自のインジェストパイプラインを作らずに、ヘルプセンターを情報源にしたサポートボットや社内の営業支援アシスタントを構築できます。 Amazon SageMaker HyperPod で LLM 推論をスケールさせる Inference Gateway を提供開始 SageMaker HyperPod 上に EKS マネージドアドオンとして導入できる、GPU を考慮した LLM 推論向けのルーティング機能です。ラウンドロビンではなく、KV キャッシュ使用率、キュー深度、LoRA アダプターの常駐状況、プレフィックスキャッシュのヒット率などのシグナルでリクエストの振り先を決めます。アプリケーションを変更せずに、最初のトークンまでのレイテンシを最大 82% 削減できます。1 つの URL で複数モデルを提供でき、vLLM や SGLang などの OpenAI 互換サーバーに対応しています。 Amazon CloudWatch Omni: エージェントとアプリケーション向けの AI ファーストのオブザーバビリティ Amazon CloudWatch を進化させた AI 活用型のオブザーバビリティ、CloudWatch Omni が一般提供されました。アプリケーションと AI エージェントの監視・トラブルシューティングを 1 か所で行え、自然言語で質問すると関連するテレメトリを探し、AWS DevOps Agent が根本原因の特定を支援します。SSO 対応のスタンドアロン Web と、VS Code、Cursor、Kiro 向けの無料 IDE 拡張機能で提供されます。現時点のリージョンはバージニア北部、オレゴン、アイルランドです。 Amazon Connect Customer がエージェント間コラボレーションをリリース Amazon Connect Customer の AI エージェントが、顧客対応の途中で専門の AI エージェントを呼び出し、オープンな Agent2Agent (A2A) プロトコルでテキストや双方向音声で連携できるようになりました。例えば、銀行の一次対応エージェントが不正リスク評価を専門エージェントに任せ、その場で取引を承認するといった対応が可能です。各エージェントの発言や呼び出したツールは 1 つのコンタクトレコードで確認でき、ガードレールやエスカレーションも一元管理できます。 AWS Security Hub の AI インベントリが Azure のセルフホスト型インスタンスをサポート Security Hub の AI インベントリが、Microsoft Azure の VM 上にセルフホストされた推論エンドポイント、モデル、AI エージェント（Ollama、vLLM、Hugging Face TGI などのフレームワークを含む）を検出・カタログ化できるようになりました。Amazon Inspector の SBOM 分析を活用し、AWS と Azure をまたいで AI アセットとセキュリティ上の検出結果をまとめて把握できます。マルチクラウドで AI 活用が広がる組織のセキュリティチームに向いたアップデートで、追加料金はかかりません。 AWS End User Messaging と Amazon SES が AWS MCP Server 向けの AI エージェントスキルを提供 AWS End User Messaging と Amazon SES が、AWS MCP Server 向けの AI エージェントスキルを公開しました。Kiro、Claude Code、Codex、Cursor などの AI コーディングエージェントに自然言語で頼むだけで、送信 ID の検証、ブランド化された RCS エージェントの構築、本番のメール送信などを検証済みの手順に沿って進められます。ドキュメントとコンソールを行き来していたメッセージング設定の手間を減らせます。 AWS Continuum が認証情報のテストとアクセス可能なドメインの提案をサポート 開発ライフサイクル全体でアプリケーションを守るフロンティアエージェント AWS Continuum のペネトレーションテスト機能で、テスト実行前にログイン認証情報を確認し、到達できるドメインを対象範囲として提案してもらえるようになりました。これまでは認証の失敗がテスト完了後にしかわからなかったため、設定ミスによる無駄なテストサイクルを減らせます。 Kiro IDE 1.1.70 でターミナルのタイムアウト設定とファイルリンクの直接オープンに対応 ローカルで実行するエージェントコマンドに既定のタイムアウトを設定できるようになりました。チャット内のワークスペースファイルへの Markdown リンクをクリックするとエディタで開けるほか、Agent Focus のセッション復元や Mermaid 表示などの不具合も修正されています。 Kiro Crew 0.7.0 で設定の即時反映と作業の永続化、PR 監視の対象拡大に対応 多くの設定が保存と同時に稼働中の Gateway に反映され、サブエージェントの作業やワークフロー呼び出しは永続キューに入って再起動後も復元されるようになりました。プルリクエスト監視は GitHub に加えて GitLab、Bitbucket Cloud、Azure DevOps Services に対応。エージェントのバックエンドに OpenCode と goose が加わり、リモートクルーの接続先に AWS Fargate も選べます。 Kiro CLI 2.23 / 2.24 で推論レベルの設定とセッション単位のツール承認に対応 2.23 では /model からモデルの切り替えと推論レベルの設定をまとめて行えるようになり、V3 のクラウドセッションをリポジトリ接続前に開始できるようになりました。2.24 では /tools trust-all でセッション中のツール呼び出しを一括承認できるほか、/sessions のフィルタや並び替えが改善されています。プロジェクトの .env が自動で読み込まれなくなった点には注意が必要です。 Kiro Web で推論レベルの選択とタイムラインのグループ表示に対応 Kiro Web で、推論レベルに対応したモデルの reasoning effort を選べるようになりました。連続する推論ステップやツール呼び出しは折りたためる 1 つのブロックにまとまり、応答が読みやすくなっています。ドキュメント添付の上限もセッション累計からメッセージ単位に変わりました。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。3 つのコースから選べて、AWS クレジットの付与や技術支援も用意されています。ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

SAP Sapphire 2026 において、AWS は SAP との Strategic Collaboration Agreement（SCA、戦略的協業契約）を発表し、SAP Business AI Platform の提供を全世界で拡大することを明らかにしました。この 5 年間の契約により、SAP Business AI Platform のプラットフォームサービス、および SAP Business Data Cloud が 7 つの新しい AWS リージョンに提供されます。これにより、規制産業や新興市場のお客様は、ビジネスをトランスフォーメーションするために必要なパフォーマンス、コンプライアンス、イノベーションの機能を得られます。 お客様のいる場所で応える 新しいリージョン展開は、インド、日本、英国、ブラジル、マレーシア（ASEAN）、カナダ、韓国といった主要市場にまたがり、世界中のお客様を支援します。これにより、お客様は事業を展開する場所の近くにある AWS インフラストラクチャ上で SAP ワークロードを実行できます。 「世界中のお客様がクラウドへの移行を加速させており、どこで事業を展開していても支援できる信頼できるパートナーを必要としています。AWS との協業を拡大することで、SAP Business AI Platform の提供リージョンを増やし、企業が現地のデータレジデンシー、コンプライアンス、パフォーマンスの要件を満たしながら、ビジネスデータと AI からより多くの価値を引き出せるよう支援します。」 – Stefan Goebel, SVP, Portfolio & Strategic Initiatives, SAP Customer Value Group. 高可用性で規制対象の SAP ワークロードを実行する企業にとって、リージョンの可用性は贅沢ではなく必要不可欠なものです。ヘルスケア、金融サービス、製造、公共部門の組織は、厳格なデータレジデンシー要件に直面しており、リアルタイム運用のために低レイテンシーを求めています。 「企業は、世界をリードするビジネスアプリケーションの実行と、現地のコンプライアンスおよびパフォーマンス要件の充足との間で、どちらかを選ばなければならないということがあってはなりません。この協業は、企業と SAP Business AI Platform を支援します。」 – Sara Alligood, Director WW Strategic Partners, AWS お客様にとっての意味 これらの機能は総合的に、企業が SAP Business AI Platform と AWS のインフラストラクチャおよび AI サービスを組み合わせた力をどのように活用できるかにおいて、段階的な飛躍を表しています。 お客様を支援する新たなキャパシティ : SAP Business AI Platform のプラットフォームサービスと SAP Business Data Cloud は、2026 年 12 月に開始し 2028 年まで続く段階的なロールアウトで、新しい AWS リージョンに展開されます。この拡大により、これまで十分にサービスを受けられなかった市場のお客様も、AWS 上で SAP のクラウドソリューションの大部分にアクセスできるようになります。 データレジデンシーとコンプライアンス : データレジデンシー要件を持つお客様は、データを自身の地域内に保持し、妥協することなく現地および国際的な規制要件を満たせるようになります。これは、データ主権が譲れない金融サービス、ヘルスケア、公共部門の組織にとって特に重要です。 低レイテンシーのパフォーマンス : 製造、物流、公益事業におけるリアルタイム運用は、SAP ワークロードがエンドユーザーの近くで実行されることで恩恵を受け、レイテンシーが低減され、時間に敏感なビジネスプロセス全体で応答性が向上します。 簡素化されたエコシステム統合 : すでに SAP on AWS に投資している組織は、より低い移行の複雑さと運用上の摩擦で、環境を AWS サービスや SAP Business AI Platform へと拡張でき、既存の投資を保護・拡張できます。 AI と高度な分析 : お客様は SAP と AWS の AI および機械学習の機能にネイティブにアクセスでき、さらに AWS と SAP の AI Co-innovation プログラムを活用して、インテリジェントな自動化とデータ駆動型の意思決定における新たな可能性を切り開けます。 Co-innovation（協業によるイノベーション） AWS と SAP は、お客様のデータを AWS のデータ、AI、機械学習の機能に接続するイノベーションレイヤーを提供するため、専任のワーキンググループを設立しました。その目標は、インフラストラクチャを超えて、SAP Business AI Platform を通じてビジネス価値を提供する、差別化されたクラウドネイティブな体験を創出することです。 AWS と SAP は共同で、お客様がインサイトを引き出し、プロセスを自動化し、競争優位を推進できるようなソリューションを開発しています。これは遠い先のロードマップ上の約束ではありません。明確な成果物とお客様によって検証された成果を伴う、活発なエンジニアリングおよび製品の協業です。 パートナーエコシステムのために構築 パートナーもまたこの協業の中心にいます。AWS と SAP は、トレーニング、認定、ユースケース開発、Go-to-Market パッケージを含むパートナーイネーブルメントに共同で注力しています。AWS SAP Competency 認定を持つシステムインテグレーターパートナーは、専任のパートナーデベロップメントマネージャーと共同のイネーブルメントリソースに支えられ、お客様の成功を実現する中心的な役割を担います。 実証された基盤 AWS は、何千もの現役 SAP のお客様にとって、クラウドおよびイノベーションのパートナーとして信頼されています。この協業はその実証された基盤の上に構築され、パートナーシップの範囲と深さを拡大して、次の波となるエンタープライズクラウドのトランスフォーメーションに対応します。 SAP が Autonomous Enterprise（自律型エンタープライズ）のビジョンの実行を続ける中、この関係は、パフォーマンス、セキュリティ、グローバルな展開、イノベーションを求めるお客様にとって AWS が選ばれるプラットフォームであり続けることを支えます。この契約の長期的な性質は、両社が共通のお客様と、そしてエンタープライズクラウドコンピューティングの未来に対して行っているコミットメントの深さを反映しています。 始めましょう SAP を AWS で実行する準備はできましたか？ http://aws.amazon.com/sap にアクセスしてソリューションを確認し、始めましょう。あるいは、AWS アカウントチームまたは AWS SAP Competency Partner にお問い合わせいただき、新しいリージョンでの展開を計画してください。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

本ブログは株式会社 PLAY プラットフォーム本部 技術基盤部 技術推進グループ テックリード 市川 賢 様 の監修のもと、アマゾン ウェブ サービス ジャパン合同会社 金目 健二が執筆いたしました。 AI エージェントの運用における課題 生成 AI の普及により、インシデント対応に AI エージェントを利用する取り組みが各社で進められております。一方で、検証環境では有用性が確認できても、実際に本番運用へ組み込む段階になると、エージェントの分析精度とは別のところで検討が止まるケースが見られます。「どこまでをエージェントに任せてよいのか」が組織内で合意されていないこと、複数のプロダクトを持つ組織において「誰がエージェントの動作を定義するのか」が決まっていないことがその要因です。この 2 点が定まらないまま精度の議論を進めても、組織としての運用には結びつきません。 本記事では、株式会社 PLAY（以下、PLAY）が AWS DevOps Agent （以下、DevOps Agent）を全社共通のインシデント対応基盤として利用するにあたり、決めた 2 つの設計（委譲範囲、組織） をご紹介します。実装の詳細は PLAY の技術ブログ「 AWS DevOps Agent を活用したインシデント自動分析基盤 」にて公開されておりますので、本記事ではそこで語られていない「なぜその設計を選んだのか」と、公開後に進んだ展開を中心にお伝えします。 PLAY が取り組んだこと PLAY は、動画配信プラットフォームをはじめとする動画ソリューションを提供する企業です。「見たい人」と「見せたい人」がつながる世界をつくるためには、配信基盤に加え、コミュニケーションやインタラクション、認証や課金、視聴スタイルの変化に合わせた機能が必要となります。それぞれのコンテンツに適した仕組みを作り続けることをミッションとする PLAY では、性質の異なる複数のプロダクトが並行して稼働しており、その安定運用が事業の前提となっております。 本記事で取り上げる基盤は、プラットフォーム本部 技術基盤部 技術推進グループが中心となって構築しました。導入は 1 プロダクトから始まり、2026 年 9 月現在は 4 プロダクトと 1 つのソリューション案件で稼働しております。さらに 2 プロダクトで導入準備が進められております。 DevOps Agent は、AWS・マルチクラウド・オンプレミスを横断する運用支援エージェントです。インシデントの根本原因分析、予防的な対応、オンデマンドの SRE タスクを担います。マネージドサービスとして提供されているため、エージェント本体の実行環境やモデルを自前で構築する必要がなく、運用タスクに閉じた用途であれば短期間で利用を開始することができます。 PLAY においても、まず動かしてみるところから取り組みが始まりました。技術推進グループ テックリードの市川 様は「AWS DevOps Agent 自体は高い精度でインシデントを分析してくれる優秀なサービス」と述べています。分析精度は当初から十分な水準にありましたが、既存の運用フローにそのまま組み込めたわけではありませんでした。何が課題でどう解決していったのかを、次節から記します。 手作業で行われていた一次対応 本番環境でエラーが発生すると Slack にアラートが通知されます。エンジニアがログを確認し、コードを調査し、GitHub に Issue を起票し、修正を行う、という一連の作業を PLAY では毎回手動で行っておりました。一次調査だけで 1 件あたり 15 分から 1 時間を要しており、エラーの発生頻度が高い環境では、同様のエラーが発生するたびに同じコストが掛かる状況でした。 これらの作業をインシデント対応基盤に任せることを検討するにあたり、PLAY は 2 つの課題に直面しました。  課題  課題の実体 ① どこまで AI エージェントに任せてよいか分からない（委譲範囲の決定） 全工程を渡すことには不安がある。一方で人が全工程を行うと運用が回らない ② 複数のプロダクトにどのように展開するのか（組織間の分担範囲の決定） 調査手順はプロダクトの中身を知る担当者にしか書けない。一方で各チームに仕組みまで作らせると重複が生じる ①に対する答えが設計 1、②に対する答えが設計 2 となります。 これらの設計を反映した基盤の概要構成を以下に記します。 図 1: インシデント対応基盤 概要構成図 当基盤は、共通基盤チームが構築・運用する部分（図中「共通基盤」）と、各プロダクトチームが自身の AWS アカウントで運用する部分（図中「各プロダクトチームの AWS アカウント」）に分かれており、アラートの発生から人の判断までは次の流れで処理されます。 Slack のエラー通知（各種監視サービスからアラートが Slack へ飛ぶ）、または Amazon CloudWatch Alarm を共通基盤の AWS Lambda が受信し、正規化する（①） Amazon DynamoDB 上の過去アラートと SimHash を基に照合し、類似アラートかどうかを判定する（②） 類似アラートと判定された場合は、関連する Issue を元の Slack スレッドに返信し、DevOps Agent は起動しない（③） 類似アラートでない場合は、 AWS Systems Manager Parameter Store のルーティング設定を参照し（④）、該当サービスの AWS アカウントで動作する DevOps Agent へ Webhook で調査を依頼する（⑤） DevOps Agent はプロダクトチームが記述した調査スキルに従い、CloudWatch Logs、GitHub、New Relic を調査する（⑥） 調査の過程で、MCP 基盤を経由して Issue 番号の記録や過去インシデントの参照を行う（⑦） 調査の進捗と結果は、元の Slack スレッドへ 3 段階（開始 → 原因候補 → 完了）で報告される（⑧） 担当エンジニアが結果を確認し、修正に着手するかを判断する（⑨） この構成のうち、⑥〜⑨で「DevOps Agent がどこまでを担い、人がどこから引き継ぐか」を決めたのが設計 1（委譲範囲）、共通基盤と各プロダクトの AWS アカウントの境目で「誰が何を作るか」を決めたのが設計 2（組織）です。 設計 1: 委譲範囲の決め方 本節は、インシデント対応の自動化範囲についてチーム内の合意が取れていない方に向けた内容となります。 一次トリアージへの限定 PLAY が最終的に目指しているのは、DevOps Agent を起点に原因調査を行い、必要であればコード修正と Pull Request の作成まで自動で行い、承認を経てマージ、デプロイまでつなげることです。しかし、最初からそこまでを対象とはしませんでした。市川 様は次のように述べています。 「最初からそこまでを対象にすると、調査の精度が固まっていない段階で修正やデプロイまで自動化することになり、運用に乗せるのは難しいと考えました。そこで、まずは一次トリアージ（原因の調査と Issue 起票）に範囲を絞り、その精度を高めることに注力する判断をしました。」 全工程を渡すのでも、人が全工程を行うのでもなく、一次トリアージという範囲を切り出して任せる、という判断です。当初の線引きは「原因の調査と Issue 起票まで」でした。運用を重ねる中で、調査結果が Slack スレッドに返ってきた時点で対応が完結するケースが多いことが分かり、Issue は「起票されたが確認して閉じるだけ」になりがちでした。そのため、Issue が必要な場合のみ起票するよう DevOps Agent のスキルで調整しました。プロダクトによっては 7〜8 割のアラートが Slack 上の返信で完結しているとのことです。 現在の役割分担は以下の通りです。  担当  範囲  共通基盤（共通 AWS アカウント） アラートの受信と正規化、過去の類似エラーとの照合、エージェントへの受け渡し  DevOps Agent（各プロダクト AWS アカウント） ログの確認、コードの調査、根本原因の分析、調査結果の Slack スレッドへの報告、必要な場合の Issue 起票  人 調査結果の確認、修正に着手するかの判断、Pull Request のレビューとマージ、対応の優先度判断  修正の自動化（PLAY 自前の仕組み） Issue 上で @play fix とコメントされると、自動でコードレビューとコード修正を行い Pull Request を作成 エージェントが担うのは調査と報告までであり、修正に進むかどうかの判断は原則として人が行います。人が Issue に @play fix とコメントすることで、PLAY が自前で用意したコードレビュー・修正の仕組みが Pull Request を作成し、そのレビューとマージは人が行う流れとなっております。なお、調査結果の確度が高い一部のケースでは、この @play fix コメントを DevOps Agent 自身が行う運用も始まっております。詳細は「今後の展望」にて記します。 この線引きにより、エージェントの分析が的を外した場合でも業務に影響が及びません。Slack スレッドの報告を読んだ人が気づくことができます。一方、最も時間を要していた「どこを見るべきか探す」工程は人の手を離れることとなります。 スキルファイルによる範囲の明文化 DevOps Agent の動作は、マークダウン形式のスキルファイルで定義します。PLAY はこのスキルファイルに、エージェントに任せる範囲をそのまま記述しております。調査から起票・通知までを 9 つのステップに分け、それぞれで呼び出すツールを明示したものです。  Step  内容  使用するツール  1  エラー情報のパース + 「調査開始」の Slack 通知  slack_post_thread  2  対象リポジトリの特定  –  3  ナレッジベース検索  knowledge_base_query  4  デプロイとの相関確認  –  5  コードの調査 + 「原因候補特定」の Slack 通知  slack_post_thread  6  GitHub Issue / Backlog 課題の作成（必要な場合）  add_issue 等  7 「調査完了」の Slack 通知  slack_post_thread  8  Issue 番号のコールバック（起票した場合）  issue_callback  9  結果の報告  – ステップに分けておくことで、エージェントが何をどの順で行うかがドキュメントとして残ります。任せる範囲が曖昧なまま動かした場合、想定外の動作が起きた際に原因を追うことが困難となります。ステップ単位で定義することは、動作を安定させることに加え、何が起きたかを後から説明できる状態を作ることにもつながります。前述の「不要な Issue を作らない」という調整も、Step 6 の条件をスキルに書き足すことで実現しております。 スキルの具体性と調査の質 スキルファイルの書き方について、PLAY が運用を通じて得た知見があります。技術ブログには次のように記されています。 「スキルファイルの書き方そのものが調査の精度とスピードに直結する。Agent 自体は強力でも、スキルが曖昧だと毎回ゼロから調査範囲を探索することになり、結果として『分析に時間がかかる (= 課金が増える)』『見るべき場所を取りこぼす』といった問題が起きる。」 特に効果があったのは、「このアラートやエラーパターンが来たら、どこを最初に見に行くべきか」を具体的に記述することでした。 CloudWatch ロググループ — 「xxx というエラーメッセージが来たら、まず /aws/foo-handler のログを ${時刻} – 5 分 の範囲で確認する」のように、エラー文字列とロググループの対応を列挙する GitHub リポジトリとパス — 「このアラートの対象はモノレポの services/foo 配下なので、コード調査は該当リポジトリの services/foo に絞る」のように、ディレクトリ単位まで明示する メトリクス — 該当時刻のメトリクスを確認する場合は、ダッシュボードの URL や関連クエリも併記する この点は実装前の想定と最も異なっていた部分であったと、市川 様は次のように述べています。 「調査対象のモジュールに対して、どの CloudWatch のロググループや New Relic のエンティティが対応するかというマッピングをスキルに記載しておくと、エージェントが迷わず調査を進められます。エージェント自体の能力よりも、この対応関係をどれだけ具体的に渡せるかが結果を左右する、というのが実装前の想定と違った点でした。」 このマッピングは、PLAY のスキルでは「モジュールマップ」として次のような形で記述されております。以下はサービス名や識別子を架空のものに置き換え、内容を汎化した抜粋です。 モジュール リポジトリ CloudWatch ロググループ（本番） New Relic APM delivery-api <git>/delivery-api /ecs/delivery-api-blue, /ecs/delivery-api-green（用途別に分かれた複数の ECS サービスがこの 2 つを共有する） prod-delivery-api manifest-service <git>/manifest-service /ecs/manifest-service-{blue,green} に加え、Lambda 側 /aws/lambda/prod-manifest-service-Function-<SUFFIX> も稼働中。両方を確認する prod-manifest-service（アラート条件なし） edge-handler <git>/edge-handler /aws/lambda/us-east-1.edge-handler（Lambda@Edge のためリージョンが us-east-1） なし（CloudWatch Logs が唯一のテレメトリ） 表の各行には、リソースの対応関係だけでなく「ECS と Lambda の両方で動いており片方だけ見て再現しないと結論しない」、「APM が入っていないモジュールがある」、「Blue/Green のどちらが現用系かはタスク数と ALB の重みで判定する」といった、エージェントが単独では誤りやすい事実が注記として書き込まれております。命名規則から推測させると必ず間違える点を、稼働環境で確認した事実として先に潰しておく、というのがこのスキルの書き方です。 効果は調査時間に表れております。スキルをほとんど用意していなかった導入初期には 1 件の調査に 15〜20 分程度を要しておりましたが、スキルを具体化した現在は 5〜10 分程度で完了しております（初期の計測は数回分のため、参考値となります）。 Slack スレッドでの判断 エージェントに調査を任せると、人は「今どこを見ているのか」を把握しづらくなります。PLAY では、人が判断を行う場所を Slack のスレッドに置きました。 アラートが通知されたスレッドには、そのとき誰が何を話したかという文脈が残っております。調査結果が別の場所に投稿されると、その文脈から切り離されてしまいます。加えて、PLAY ではどのプロダクトにおいても、アラートが通知されたスレッドに担当者が調査の進捗を書き込んでいく運用が既に定着しておりました。エージェントの調査結果も同じスレッドに返すことで、担当者は普段と同じ場所を見るだけでよく、新しいツールや手順を覚えることなくエージェントを既存の運用に取り込むことができます。問題が起きた元のスレッドに結果が返ることは、文脈の維持と既存運用との接続の両面で重要でした。 調査の進捗は 3 段階で元のスレッドに返されます。 調査開始時 — 対象のエラーとリポジトリを提示 原因候補の特定時 — 対象ファイルと行番号、原因候補の説明 調査完了時 — 根本原因、影響のあるコード、関連コミット、修正の方針、Issue を作成した場合はその URL 段階を分けている理由は、人が途中で介入できるようにするためです。原因候補の時点で見当違いだと分かれば、完了を待たずに人が動くことができます。前述の通り、多くのアラートはこの 3 段階目の報告を読んだ時点で対応が完結しております。 原因を特定できなかった場合の出力 実運用において分かれ目となったのは、エージェントが答えを出せなかった際の出力を事前に決めておくことでした。 AI エージェントの導入検討では「どれくらい正しく答えられるか」に議論が集まりがちです。PLAY の運用では、プロダクトによっては 7〜8 割のケースで根本原因の特定に至っております。一方、運用に乗せた後は、残りの正解を出せなかったケースの扱いが品質を左右します。何も返ってこなかったり、自信のない推測だけが返ってきたりすると、人はエージェントの出力を信用しなくなります。 PLAY のスキルファイルには、根本原因を特定できなかった場合の専用フォーマットが用意されております。返す内容は以下の 3 点です。 調査内容 — 確認したファイル、参照したログ、確認したメトリクス 判明した事項 — 根本原因が不明であっても、分かった事実は記載する 修正の方針 — 次のステップ、追加で調査すべき領域 「分かりませんでした」で終わらせず、人が続きを引き継げる状態で返す設計です。特定に至らなかったケースでも調査済みの範囲が記録されているため、人による再調査を初手から始める必要がありません。任せる範囲を決めるということは、うまくいったときの範囲だけでなく、うまくいかなかったときの振る舞いまで決めることであったと言えます。 設計 2: 組織での分担 本節は、複数のプロダクトを抱える SRE / プラットフォームチームや CCoE の方に向けた内容となります。 難所となったサービス固有の調査手順 基盤を作る過程で分かったことは、DevOps Agent の活用において本当に難しいのは各サービス固有の調査スキルを書く部分である、という点でした。 どのリポジトリを見るのか、どの CloudWatch ロググループを参照するのか、どの New Relic エンティティが対応するのか、どの GitHub Organization に Issue を起票するのか。いずれもサービスの中身を最もよく知っている担当者にしか書けません。共通基盤を作るチームが全プロダクトのドメイン知識を持つことは現実的ではありません。 一方で、それ以外の部分は横展開が可能です。Slack イベントの受信、ルーティング、重複したアラートの排除、MCP によるツール提供、Slack スレッドへの戻し制御は、プロダクトが変わっても同じ仕組みで対応できます。 「基盤の仕組み」と「ドメイン知識」を分けることが、PLAY の組織設計の起点となりました。 共通基盤チームとプロダクトチームの線引き 担当 やること 共通基盤チーム Slack / CloudWatch の受信、ルーティング、重複アラート排除、MCP 基盤によるツール提供、Slack スレッドへの返信 各プロダクトチーム 自チームの AWS アカウントに DevOps Agent の Agent Space を作成、サービス固有の調査スキル（マークダウン）を記述、Webhook を共通基盤に向ける この分担により、プロダクトチームは自分たちが詳しい部分の記述に集中でき、共通基盤側のインフラ運用を意識する必要がありません。共通基盤チームも、プロダクト内部のドメイン知識を持たずに運用を成り立たせることができます。どちらのチームも自分が知っていることだけを担当すれば動く、という状態を作ったことが、複数プロダクトへの展開を可能にしました。 設計 1 で述べたスキルファイルを書くのはプロダクトチームであり、それに沿ってエージェントが動く土台を用意するのが共通基盤チームという関係になります。 スキルを記述したプロダクトチームは次のように述べています。 「これまでチーム内で統一してきた調査方法や報告フォーマットに、各システムの技術スタックや AWS のインフラ構成を加えてスキルに書き起こしたもので、いずれも普段から自分たちが持っている情報だったため自前で書き切れました。調査対象のシステムさえずれていなければ調査内容は基本的に信頼しており、報告される【確度】を見て、必要な部分だけ人が追加で事実確認を行っています。」 ここで述べられている確度は、調査結果の根本原因に付与される【確定 / 有力 / 推定】のラベルです。権限や経路の制約（参照する MCP がないなど）により取得できない情報がある場合は確度が下がるようにスキルで定義されており、人はこのラベルを見て事実確認の要否を判断しております。 アカウント分離による責任範囲の明確化 各プロダクトチームの DevOps Agent は、その AWS アカウントで動作します。 権限とリソースが分離されることに加え、責任の範囲がアカウント単位で定まります。どのサービスがどれだけエージェントを利用したかがアカウントごとに分かれるため、「誰の責任範囲か」を運用の都度議論する必要がありません。組織で共有する基盤ほど、この境目を仕組みで決めておくことの価値は高まります。 新規プロダクトの追加手順 新しいプロダクトを基盤に載せる手順は以下の 3 点です。 プロダクトチームが自アカウントに Agent Space を作成する プロダクトチームがサービス固有の調査スキルを記述する 共通基盤チームがルーティング設定に Webhook URL を 1 行追加する ルーティング設定は AWS Systems Manager Parameter Store の SecureString で管理されており、Lambda の再デプロイなしで変更することができます。Slack のチャンネル単位、CloudWatch のアラーム単位で、呼び出す DevOps Agent を切り替えることが可能です。 共通基盤側の作業がエントリ 1 件の追加で済むため、展開のボトルネックはプロダクトチーム側のスキル記述のみとなります。1 プロダクトから始まった導入は、現在 4 プロダクトと 1 つのソリューション案件に広がり、2 プロダクトで導入準備が進められております。 2 つの設計を支える作り込み（PLAY 技術ブログ公開時点） 2 つの設計を実運用に乗せるために、PLAY が自前で用意した部分をご紹介します。本節は技術ブログ公開時点（2026 年 6 月）の構成であり、その後の変化は「その後の発展」にて記します。 注記: 本節の内容は、執筆時点の DevOps Agent の機能を前提とした補い方です。DevOps Agent 側の機能追加により、将来的には自前で用意する必要がなくなる部分もあります。設計 1・設計 2 が経路や機能の変化に依存しないのに対し、本節は時点依存の内容としてお読みください。 MCP サーバーによる外部連携 DevOps Agent はセキュリティ上の理由から、スキルから直接 HTTP リクエストを発行したり Lambda を呼び出したりすることができません。この制約は実装して初めて分かったことの 1 つであったと、市川 様は次のように述べています。 「GA 直後で情報が少ない中、試行錯誤しながら触っていたため、当初はスキルの中で DevOps Agent から Slack に直接投稿するよう記述していましたが、これが動作せずしばらく詰まりました。その後、セキュリティ上の理由でスキルから直接 HTTP リクエストを発行できない仕様だと分かり、MCP サーバー経由であれば連携できると気づき、自前の MCP サーバーを作成して動作を確認しました。」 設計 1 を実現するには外部連携が必要となります。Slack スレッドへの進捗投稿、Issue 番号の記録、社内ナレッジベースの検索、Backlog への課題起票はいずれもエージェントの外側にあり、この連携を担うのが MCP (Model Context Protocol) サーバーです。技術ブログ公開時点では、PLAY は AWS Lambda の Function URL として MCP サーバーをデプロイし、DevOps Agent のコンソールでエンドポイントを登録しておりました。 自作 MCP のツール 接続先 対応する設計 slack_post_thread Slack API 設計 1（Slack スレッドでの判断） issue_callback Amazon DynamoDB 重複アラートの記録 knowledge_base_query Amazon Bedrock Knowledge Bases 過去インシデントの参照 Backlog 系（add_issue / update_issue / get_issues 等） Backlog REST API 設計 1（起票先の多様性） 自前の MCP サーバーに加え、GitHub 公式と New Relic 公式の MCP サーバーも登録しておりました。棲み分けとしては、サービス横断で必要なツールは公式の MCP サーバーをそのまま利用し、Slack スレッド返信・Backlog 起票・社内ナレッジ参照といった組織固有の要件は自前の MCP サーバーで提供する、という形です。 MCP サーバーを介した間接的な構成はセキュリティ上の制約に由来するものですが、副次的なメリットもありました。エージェントが呼び出せる操作の範囲が、MCP サーバーに登録したツールの集合として明示されることです。これは設計 1 で決めた任せる範囲を、技術的に境界づける仕組みとしても機能しております。 SimHash による重複アラートの排除 同一原因のエラーが連続して発生する環境では、同じ調査が繰り返されることとなります。人が読む報告が重複することに加え、エージェントの実行も無駄になります。 課題は、エラーメッセージの類似性をどのように判定するかでした。エラーメッセージには発生のたびに変わる要素（タイムスタンプ、PID、リクエスト ID など）が含まれるため、SHA-256 のような暗号学的ハッシュで完全一致を見ても、同じ原因のエラーを同一と判定することができません。 そこで PLAY は、類似したテキストに近いハッシュ値を生成する SimHash（Locality-Sensitive Hashing の一種）を採用しました。正規化したテキストから SimHash を計算し、ハミング距離が閾値以下のものを類似と判定します。DynamoDB 上で効率的に近傍検索を行うため、64 bit の SimHash を 4 つの 16 bit ブロックに分割し、各ブロックをグローバルセカンダリインデックス (GSI) のパーティションキーとしております。 類似と判定され、かつ過去の Issue が紐づいている場合は、Slack スレッドに「関連 Issue: #XX」を返信し、エージェントは起動しません。2 回目以降の同じエラーは、人にもエージェントにも渡さない設計です。 類似判定の手段としては、他に 2 つの選択肢がありました。1 つ目は、過去のインシデントを蓄積している Amazon Bedrock Knowledge Bases で検索する方法です。ただしこの場合、通知のたびに RetrieveAndGenerate を実行することになり、生成の部分にコストがかかるため、大量に通知が来た場合にコストが増大します。DynamoDB 上の SimHash 判定にて十分な精度が出たため、こちらを採用しております。2 つ目は、DevOps Agent 自身が持つインシデントのトリアージ機能です。この機能はルックバックウィンドウ（通常 20 分）の中で同時に起きた関連インシデントを 1 つの調査に統合したり抑制したりするもので、数か月前の過去障害との類似性を判定して抑制する用途には適していないため、採用を見送りました。 効果はチャンネルの性質により差があります。アラートのノイズが多いチャンネルでは、1 か月に 913 件のアラートのうち 719 件（78.7%）が類似判定によりスキップされました。ノイズの少ないチャンネルでは 18 件のうち 9 件（50%）でした。スキップされた分だけ、人が目を通す報告もエージェントの調査も削減されております。 調査に渡す文脈の拡充 重複と探索を削減する一方で、1 回の調査に渡すコンテキストは下記を用いることで厚くしております。 GitHub 公式 MCP サーバー — 該当リポジトリのソースコード、変更履歴、関連 Pull Request を直接参照 New Relic 公式 MCP サーバー — エラー発生時のメトリクス、トレース、Errors Inbox の情報を確認 社内ナレッジベース — Amazon Bedrock Knowledge Bases に蓄積した過去のインシデント報告を参照し、類似インシデントを踏まえて分析 SimHash の実装、GSI 設計、MCP ツールの定義コード、スキルファイル全文は PLAY の技術ブログに掲載されております。 成果 取り組み 指標 Before After 設計 1 委譲範囲 一次調査にかかる時間（1 件あたり） 人手で 15 分〜1 時間 エージェントで 5〜10 分 設計 1 委譲範囲 Slack 上の報告で対応が完結する割合 – 7〜8 割（プロダクトによる） 設計 1 委譲範囲 根本原因を特定できた割合 – 7〜8 割（プロダクトによる） 作り込み（SimHash） 類似判定によるスキップ率（1 か月） 毎回調査 78.7%（ノイズの多いチャンネル）/ 50%（ノイズの少ないチャンネル） 設計 2 組織 新規プロダクト追加時の基盤側作業 個別に作り込み ルーティング設定 1 行 「Slack 上の報告で対応が完結する割合」と「根本原因を特定できた割合」はプロダクトごとに差があり、上表は PLAY 社内で報告されている水準を記載しております。 その後の発展 技術ブログの公開後、PLAY は DevOps Agent の呼び出し経路と、エージェントが参照できるデータの範囲を広げております。 2 系統となった呼び出し経路 図 2: DevOps Agent の 2 つの呼び出し経路  経路  起点  ① 自動一次トリアージ  Slack のエラー通知、CloudWatch Alarm  ② Slack からの呼び出し  Slack App へのメンション Slack からの呼び出しである②において工夫されているのは、ユーザーが明示的にメンションする以外の導線です。PLAY では各プロダクトに問い合わせ専用の Slack チャンネルがあり、Slack ワークフローが設定されております。このワークフローに Slack App のメンションを付与しておくことで、問い合わせがそのままトリガーとなります。内容に応じてナレッジベースから回答するか、障害や問題が起こっていそうな内容であれば DevOps Agent が調査を行い、一次調査結果を Slack のスレッドに返します。 ②は Amazon Bedrock AgentCore （以下、AgentCore）Runtime 上で動作し、問い合わせ内容に応じてナレッジベースを呼ぶか DevOps Agent を呼ぶかをエージェンティックに振り分けております。②の経路では調査結果に対するフィードバックを Slack のボタンで収集しており、今後は①の自動一次トリアージにおいても同様に収集できるようにする予定です。 MCP 基盤による調査範囲の拡大 社内ツールへのアクセスを担う MCP の提供元は、全社共通の MCP 基盤へと発展しました。AgentCore Gateway を統一入口とし、DevOps Agent はここを経由してツールを呼び出します。 この基盤には、サービスのデータベース（ Amazon RDS など）を参照する運用用途の MCP、プロダクトごとの業務データを参照する各プロダクト専用の MCP、外部 SaaS の情報を参照する MCP が含まれます。これらを DevOps Agent の呼び出し先としたことで、サービス内のデータを見なければ調査できない事象についても DevOps Agent で調査できるようになりました。ツールの認可は Cedar Policy で制御されており、プロダクトごとに参照できるツールの範囲を絞っております。 任せられる範囲は、エージェント自体ではなくその外側の整備によって広がっております。PLAY では、New Relic に新しいエンティティを追加した際や、セキュリティ SaaS の検知通知をこの仕組みで分析対象に加えた際に、調査対象を拡大しております。 変わらなかった 2 つの設計 経路と調査範囲が増えても、2 つの設計はそのまま機能しております。 設計 1（委譲範囲） — スキルファイルは共通のまま。Slack から呼び出した場合も、一次トリアージと同じスキルによってスレッドに調査状況が報告される 設計 2（組織） — 分担は変わらない。プロダクトチームがスキルを書き、共通基盤チームが受け口とツールを提供する 任せる範囲をスキルとして外に出し、組織の分担を仕組みで固定していたため、入口と参照先を増やすという変更を、設計を作り直すことなく吸収することができました。 今後の展望 PLAY では引き続き以下の取り組みが進められております。 対応プロダクトの拡大 — 現在 2 プロダクトで導入準備が進められております。プロダクトチーム側でスキルを準備できれば、共通基盤側はルーティング設定を 1 行追加するだけで連携が完了します。 委譲範囲の拡大 — 一次トリアージの精度が固まってきたことを受け、任せる範囲を段階的に広げております。1 つ目は自動 PR 作成です。New Relic のソースコードマップ連携でエラー箇所が行番号まで特定できる UI のバグなど、調査結果の確度が高いケースに限り、DevOps Agent が GitHub の MCP サーバー経由で Issue に @play fix とコメントし、Pull Request 作成まで人を介さずに進めております。2 つ目は、直近のデプロイが原因と判定された場合に Blue/Green デプロイメントを切り戻す自動対応です。いずれも、冒頭で述べた「コード修正から Pull Request 作成、承認を経たマージ・デプロイまで」という最終的な目標に向けた段階となります。 フィードバック収集の拡大 — 現在は Slack からの呼び出し経路で収集している調査結果へのフィードバックを、自動一次トリアージの経路においても収集できるようにする予定です。 PLAY からのコメント 株式会社 PLAY CTO 丸山 健一 様は次のように述べています。 「私が管掌する技術基盤部では、全社の業務効率化を目的として、社内ツールの開発および仕組みの整備を推進しております。今回構築したインシデント対応基盤もその一環であり、当初より複数チームへの展開を前提として設計いたしました。最初のチームへの導入後、その評価が社内に伝わり、他チームからも導入の要望が自発的に寄せられましたが、本設計により円滑な社内展開を実現できたものと考えております。今後は、お客様のプロダクト利用状況といったビジネスコンテキストを調査に加味しつつ、より多角的な観点からの分析を可能とすることを目指してまいります。」 終わりに PLAY は DevOps Agent を全社共通のインシデント対応基盤として利用するにあたり、2 つの設計を決めました。 委譲範囲 — 一次トリアージという範囲を切り出し、スキルファイルに記述し、人が判断を行う場所を Slack スレッドに置き、原因を特定できなかった場合の出力まで決めた 組織 — 「基盤の仕組み」と「ドメイン知識」を分け、共通基盤チームとプロダクトチームがそれぞれ自分の知っている範囲だけを担当する構造とした 2 つの設計は、スキルファイルという成果物でつながっております。仕様を書くのは現場であり、仕様が動く土台を用意するのは基盤チームである、という関係です。 市川 様は技術ブログの締めくくりにおいて「AI エージェントを業務に組み込むときの最大の難しさは、エージェント単体の精度よりも、『既存の運用フローやチーム構造にどう乗せるか』の部分にあると感じています。」と述べています。調査結果を人が既に見ているアラートスレッドに返すという設計 1 の判断は、この「既存の運用フローに乗せる」ことを、人の作業手順を変えずに実現した例と言えます。 DevOps Agent の分析精度は、それ単体で十分に高い水準にあります。まず動かしてみるところまでの敷居は高くありません。その精度を組織の日常業務に定着させるために必要となるのは、何を委ね、誰が書くかを決めることでした。 AWS では、AI エージェントを運用へ組み込むにあたってのご相談や、類似事例の共有を行っております。同じように AI エージェントを運用に組み込もうとされている読者の方は、下記の参考リンクもご参照ください。本記事が、AI エージェントの運用設計を検討されているお客様の一助となれば幸いです。 参考リンク AWS DevOps Agent を活用したインシデント自動分析基盤（PLAY 技術ブログ） — SimHash の実装、GSI 設計、MCP ツール定義、スキルファイル全文 AWS DevOps Agent による自律的インシデント対応 － その能力を引き出す設計のベストプラクティス －（AWS Summit Japan 2026 CNS319 登壇資料 PDF） この記事は ソリューションアーキテクト 金目、スペシャリストソリューションアーキテクト 加藤、テクニカルアカウントマネージャー 馬場が担当しました。 監修: 株式会社 PLAY プラットフォーム本部 技術基盤部 技術推進グループ テックリード 市川 賢 様

2026 年 9 月 25 日、 Amazon CloudWatch は CloudWatch Omni を発表しました。これは、アプリケーション中心で AI を活用し、オープンスタンダードに基づいて構築され、オフコンソールで提供される、アプリケーションと AI ワークロードの統合オブザーバビリティエクスペリエンスです。CloudWatch Omni は、AI エージェント向けに特化して構築されたオブザーバビリティ、評価、実験のためのソリューションです。評価主導のワークフロー、既存のツールのサポート、そして作業環境に直接提供されるオブザーバビリティにより、チームは、モデルプロバイダー、フレームワーク、ランタイムを問わず、AI エージェントの設計、評価、運用を行えます。オブザーバビリティは IDE に直接提供されるほか、AWS Management Console とは独立したスタンドアロンの Web エクスペリエンスからも利用できます。 エージェント型 AI システムを導入する組織は、従来のモニタリングでは対処できないオブザーバビリティの課題に直面しています。エージェントの動作は非決定的です。標準的なメトリクスでエラーが示されていなくても、プロンプトを変更すると応答品質が低下する可能性があります。チームは複数のシステムにまたがるログを手作業で確認するために何時間も費やしており、何が変更されたのか、なぜ変更されたのかを特定できないことがあります。既存のツールでは、チームはサイロ化された生成 AI モニタリングを利用するか、コーディング環境とブラウザーベースのダッシュボードを頻繁に行き来する必要がある分断されたソリューションを利用するかの選択を迫られます。 CloudWatch Omni はすべてのトレースをキャプチャし、正確性、一貫性、検索品質、ツール選択などを評価する組み込みの評価機能を備えています。Playground でプロンプトバージョンを並べて比較したり、本番トラフィックからテストデータセットを構築したり、さまざまな構成で実験を実行したり、リグレッションを自動的に検出したりできます。 開発用と運用用の2つのサーフェス CloudWatch Omni は、相互に補完する 2 つのインターフェイスを通じてオブザーバビリティを提供しま開発者は、現在サポートされている IDE である VS Code と Kiro にネイティブ拡張機能を導入できます。エージェントの実行中にトレースが表示され、プレイグラウンドや評価機能にもワンクリックでアクセスできます。運用担当者は、AWS Management Console とは独立したスタンドアロンの Web エクスペリエンスを利用してフリートをモニタリングできます。SSO 経由でアクセスでき、AWS Management Console は必要ありません。どちらも同じデータを共有します。開発者がデバッグするトレースと、運用担当者が調査するトレースは同じものです。 Cloud Login 機能 は、ローカルの IDE 環境を AWS アカウントに接続し、テレメトリデータを Amazon CloudWatch に送信して永続的に保存したり、チームとトレースを共有したり、本番環境のダッシュボードにアクセスしたりできるようにします。この接続はオプションです。開発中は CloudWatch Omni を完全にローカル環境で使用し、本番環境のエージェントをモニタリングする準備ができたら、クラウドに接続できます。 使用の開始 CloudWatch Omni を使い始める方法は 2 つあります。IDE 拡張機能（VS Code と Kiro 向け）を使用する方法と、クラウドエクスペリエンスから直接開始する方法です。クラウドエクスペリエンスでは、IDE 拡張機能をインストールせずに CloudWatch へのテレメトリデータの送信を開始できます。このチュートリアルでは、拡張機能をインストールし、エージェントを作成して実行した後、IDE からトレースと評価ツールを確認します。 VS Code Marketplace から CloudWatch Omni 拡張機能をインストールすると、アクティビティ バーに CloudWatch Omni のアイコンが表示されます。ウェルカム画面から、[ サンプルプロジェクトを開始する ] を選択して、事前設定されたエージェントにサンプルトレースデータをロードするか、Command+Shift+P（macOS の場合）または Ctrl+Shift+P（Windows/Linuxの場合）を使用してコマンドパレットへのショートカットを使用し、[オムニ：新しいプロジェクトの作成] を選択します。 図 1.CloudWatch オムニウェルカムスクリーンと VS Code での新規プロジェクトの作成 サンプルプロジェクトには、エージェントの実装とサンプルデータセットが含まれています。使用開始時の設定の一環として、OpenTelemetry の計測機能を追加します。CloudWatch Omni が各手順をガイドします。新しいエージェントを最初から作成することもできます。CloudWatch Omni では、インタラクティブなチャットを使ってプロセスを進めます。チャットでエージェントの目的を定義し、モデルプロバイダーを選択して、ツールを設定します。デフォルトでは、すべてのデータはローカルに保存されます。必要に応じて AWS に接続し、Amazon CloudWatch にデータを送信できます。 設定を確認した後、ローカル開発サーバーを起動し、エージェントに質問を送信しました。これが一般的なチャットボットインターフェースと異なるのは、次に何が起こるかということです。「 トレースを表示 」を選択すると、エージェントがリクエストをどのように処理したかが正確に表示されます。 図 2.CloudWatch Omni は、AI コードアシスタントをガイドし、テスト用のローカル開発環境を設定できるようにします CloudWatch Omni は、Kiro、Claude Code、Codex などの AI コードアシスタントと統合し、セットアッププロセスを効率化します。これらのアシスタントは、Dev Server の設定、依存関係のインストール、計測機能の設定を代わりに行うことができるため、手動で設定することなく、インストールから最初のトレース付きエージェントセッションの実行までを数分で完了できます。 図 3.エージェントとのやり取りとトレースの表示 トレースは AI エージェントの動作を理解するために不可欠です。従来のリクエストとレスポンスのシステムとは異なり、エージェントは 1 回の呼び出しで複数の意思決定を行います。ツールの選択、プロンプトの組み立て、サブコールの連鎖などが含まれます。トレース全体を可視化できなければ、エージェントが誤った回答を生成した理由や、予期しない処理経路をたどった理由の診断は推測に頼ることになります。CloudWatch Omni は、すべてのステップを構造化されたタイムラインに記録するため、動作が想定から外れた箇所を正確に特定できます。 Trace Explorer では、エージェントが実行したすべてのステップ（LLM 呼び出し、ツールの呼び出し、推論ステップ）を、構造化された階層型タイムラインで詳細に確認できます。任意のスパンを詳細に確認して、入力、出力、トークン使用量、レイテンシーを調査できます。 図 4。エージェントの実行タイムラインを表示するトレースエクスプローラー Trace Explorer は比較モードもサポートしています。比較モードでは 、2 つのトレースを並べて表示し、異なるプロンプトや設定が動作にどのように影響するかを確認します。比較モードは、リグレッションのデバッグに特に役立ちます。また、 Ask Assistant を使用すると 、AI エージェントがトレースから表面のパターンや異常を分析し、「なぜエージェントはこのツールを2回呼び出したのか」などの質問に答えます。 図 5。2 つのトレースを並べて比較する 評価は、生成 AI のオブザーバビリティを、実際の品質改善につながるものに変える役割を果たします。レイテンシーやエラー率などの従来のメトリクスでは、エージェントの応答が有用で、一貫性があり、事実に基づいて正確なものかどうかを判断できません。評価機能は、各応答を品質の観点から評価することで、ユーザーが実際に体験する品質を測定し、標準的なモニタリングではまったく検出できないリグレッションを発見できるようにします。 CloudWatch Omni には、一貫性、有用性、忠実性、ルーティングの正確性などのメトリクスに対応する 17 種類の組み込み評価機能が含まれています。Trace Explorer からトレースを選択し、評価機能を選んで評価を実行しました。カスタム評価フレームワークを構築することなく、各サンプルのスコアと集計メトリクスを取得できました 。 図 6.トレースの評価の実行 そこから、 Playground を使用してさまざまなシステムプロンプトを並べてテストし、複数のモデルとプロンプト構成をリアルタイムで比較して、変更を加える前に各バリエーションが出力品質にどのように影響するかを確認しました。Experiments ビューを使用すると、同じデータセットに対して 2 つのエージェントのバリエーションを実行し、評価スコア、レイテンシー、トークン使用量を並べて比較できるため、パフォーマンスの高い構成を選択できます。 図 7 。Omni Experimentsコンソールでのエージェントバリアントの評価比較 Prompt Management を使用すると 、プロンプト構成を長期にわたってバージョン管理および追跡できるため、新しいバージョンのパフォーマンスが低下した場合でも、簡単にロールバックできます。 CloudWatch Omni には、完全な会話履歴を確認し、エージェントが複数ターンのインタラクションをどのように処理するかを把握できる Session Explorer も用意されています。また、 Agent Topology ビューでは、サブエージェント、ツール、およびそれらの相互接続を含むエージェントシステムのアーキテクチャを可視化できます。任意のノードを詳細に確認して、パフォーマンスを調査し、ボトルネックを特定できます。 CloudWatch Omni には、IDE を使用せず、任意のブラウザーからアクセスできる専用の Web エクスペリエンスも用意されています。チームは、アプリケーションモニタリング、分析、エージェントのオブザーバビリティ、AI を活用した調査など、すべての機能に共同でアクセスできます。 図 8.アプリケーションモニタリング、分析、エージェントオブザーバビリティを備えた CloudWatch Omni ウェブエクスペリエンス トレースをキュレーションしてゴールデンデータセットにし 、構造化された実験を行いました。 Experiment 関数は 、データセットに対してエージェントを実行し、結果を自動的に評価します。プロンプトやエージェントのロジックが変更されるたびに、リグレッションテスト用のベンチマークを作成できます。 サポートされているフレームワークで構築されたエージェントがすでにある場合、CloudWatch Omniはインストルメンテーションを追加するための2つの方法を提供します。 1つはフレームワークを検出してトレースを自動的に設定する Auto-Instrumentswith Kiro 、 もう1つは Python と TypeScript 用のすぐに使えるコードスニペットを使った手動インストゥルメンテーションです 。詳細なインストルメンテーションガイドについては、 CloudWatch Omni ドキュメントを参照してください。 サポートされているフレームワークとオープンスタンダード 上記のチュートリアルではサンプルプロジェクトを使用していますが、CloudWatch Omni は、チームがすでに使用しているエージェントフレームワークにも対応しています。LangChain、LangGraph、CrewAI、OpenAI SDK、Strands、Vercel AI SDK など、Python と TypeScript の両。また、 Amazon Bedrock AgentCore で構築されたエージェントにネイティブなオブザーバビリティを提供し、AgentCore の評価機能を使用してエージェントの品質をオムニワークフロー内で直接評価します。 計測機能には、エージェントが Lambda、ECS、EKS、その他のクラウドのいずれで実行されている場合でも、オープンスタンダード（OpenInference および ADOT）が使用 。評価については、Omni は Braintrust、DeepEval、Ragas などのサードパーティー評価ツールと統合できるほか、組み込みのデータセット、プレイグラウンド、バッチ実験も利 。再プラットフォーム化は不要です。 CloudWatch Omni は、エージェントのオブザーバビリティとアプリケーションのオブザーバビリティを 1 つのエクスペリエンスに統合します。アプリケーションのオブザーバビリティ体験については、関連記事「 Amazon CloudWatch Omni の紹介:人工知能を活用したアプリケーションのコラボレーティブオブザーバビリティ 」を参照してください。 料金と利用可能なリージョン Amazon CloudWatch Omni が一般公開されました。IDE 拡張機能は自由に使用できます。開始するのに AWS アカウントは必要ありません。Amazon Bedrock のモデルを使用する場合は AWS 認証情報のみが必要で、OpenAI や Anthropic などの他のプロバイダーを使用する場合は API キーのみが必要です。 VS Code マーケットプレイスから拡張機能をインストールして 、今すぐ始めましょう。 すべての機能を調べてすぐに使い始めるには、 CloudWatch on AWS Builder Center にアクセスしてください。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 AWS re:Post でフィードバックを共有するか、通常の AWS サポート の連絡先からお問い合わせください。 ハッピービルディング! – Daniel Abib 原文は こちら です。

財務アナリストが AI アシスタントに「私の担当する顧客請求書のうち、支払期日を過ぎているものはどれですか？」と尋ね、SAP から直接その答えが返ってくる、そんな場面を想像してみてください。企業はまさにこれを求めていますが、AI エージェントを記録システムに接続する際には難しい問いが生じます。エージェントが SAP にアクセスするとき、そのリクエストを行っているのは誰なのか、という問いです。初期の統合の多くは、すべてのリクエストを 1 つの共有 SAP サービスユーザー経由でルーティングします。これでは、すべてのユーザーの操作が単一のテクニカルユーザーにマッピングされてしまうため、SAP は実際の操作者を認可・監査できなくなり、さらにセキュリティおよびコンプライアンスチームがめったに承認しない静的な SAP 認証情報の保存を強いられます。その結果、有望な AI パイロットが本番稼働に至る前に停滞してしまいます。 完全な ID 伝播は、SAP に至るすべての認証区間を通じて各ユーザーの ID を引き継ぐことでこの問題を解決します。リクエストが指名されたユーザーとして到着すると、SAP はそのユーザー自身の権限を適用し、Security Audit Log にそのユーザーの操作として記録し、共有された恒久的な認証情報を一切保存しません。 RFC 8693 のトークン交換で定義されている On-Behalf-Of（OBO）アクセスは、ユーザーの既存トークンを SAP にスコープを絞ったダウンストリームトークンと交換することで、これを可能にします。Microsoft Entra ID や Okta などのエンタープライズ ID プロバイダー（IdP）はこのフローをサポートしているため、ユーザーは 2 度目のログインプロンプトなしで SSO を利用できます。本ブログでは、その体験を構築する方法を解説します。 Amazon Quick を使って SAP の販売オーダー、財務、プラント保全について質問し、さらにアクションを実行しながら、 AWS for SAP MCP Server と Microsoft Entra ID などのエンタープライズ IdP によって、あなたの ID を SAP まで引き継ぎます。 仕組み エンドツーエンドのフローには 4 つの構成要素があります。MCP クライアントとして動作する AI エージェント（Amazon Quick）、AWS for SAP MCP Server をホストする Amazon Bedrock AgentCore Runtime、Entra ID、そして SAP システムです。フローを通過するために、Amazon Bedrock AgentCore 内には 2 つの異なる認証境界が設定されます。 インバウンド : Amazon Quick が、そのユーザーが誰であるかを AgentCore に証明します。AgentCore は Entra ID に対してユーザー ID を検証します。 アウトバウンド : AgentCore が SAP に受け入れられるトークンを取得します。OBO 交換により、SAP リソースにスコープを絞ったこのトークンが生成されます。 図 1. Amazon Quick、AWS for SAP MCP Server、SAP S/4HANA を統合したシングルサインオンのための高レベルアーキテクチャ。 ユーザーは Entra ID ログイン（メールアドレス）またはシングルサインオンを通じて Amazon Quick にサインインします Amazon Quick は OAuth 2.0 を介して Entra ID でこのユーザーを認証し、AWS for SAP MCP Server にアクセスします AgentCore は Entra ID でアクセストークンを検証します AgentCore はすべてのユーザーアクセスを AgentCore Observability に記録します AWS for SAP MCP Server は Entra ID と OBO 交換を実行し、その JSON Web Token（JWT）が SAP への HTTPS API 呼び出しで使用されます Entra ID が提供する JWT は、SAP の OpenID Connect（OIDC）Trust によって検証されます この設計では、以下に説明する 3 つの Entra ID アプリ登録を使用します。 Amazon Quick Client App – Quick がユーザーをサインインさせるために使用する OAuth クライアント。 Inbound / Resource App – インバウンドトークンを検証し、OBO 交換を実行します。AgentCore の認証情報プロバイダーはその client_id を使用し、これは Quick のトークンの aud でもあります。 Outbound App – SAP アクセススコープを表します。SAP は最終トークンをこのアプリに対して検証します。 Microsoft Entra ID ベースのプロバイダー設定と、関連する構成要素について理解するには、 AgentCore Identity のドキュメント を参照してください。 図 2. 3 つの Entra ID アプリ登録にまたがる委任権限のチェーン。 SAP BTP Integration Suite も、OBO（On Behalf Of）トークンチェーンを通じてこのパターンをサポートし、ID フローを次のように拡張します。Amazon Quick → AWS for SAP MCP Server → SAP BTP Integration Suite → SAP S/4HANA。SAP BTP でプリンシパル伝播と呼ばれる ID 伝播は、SAP BTP API Management によって処理されます。SAP ソリューションへの MCP アクセスパターンに関するベストプラクティスについては、SAP の ガイダンス を参照してください。 実装の詳細 本セクションでは、Entra ID アプリ登録から SAP ユーザーマッピングまで、エンドツーエンドの設定を構成する手順を説明します。この設定の前提条件は以下のとおりです。 要件 詳細 Azure CLI Global Administrator または Application Administrator ロールで認証済みの az CLI AWS CLI 対象の AWS アカウントとリージョン向けに構成済み SAP BASIS 7.56 SP1 以降（または SAP Note 3313726 を適用した 7.52） SAP トランザクション SOIDC が利用可能であること CloudFormation テンプレート s3://awsforsap-mcp-server-setup-{region}/cfn-launch-template/latest/ の最新版 Amazon Quick MCP コネクターを作成するアクセス権。コネクターを登録すると Entra ID に Amazon Quick クライアントアプリが作成されます。Step 4 で使用するため、Entra ID ポータル（App registrations）からその QUICK_APP_ID、QUICK_OBJECT_ID、および委任スコープ ID を取得してください。 OIDC サポートの最新情報については、 SAP のドキュメント を参照してください。 Step 1: インバウンド Entra ID アプリ登録を作成する インバウンドアプリは、MCP クライアントが AgentCore Runtime に認証するために使用するトークンを発行します。この手順の 2 つの設定が、フローの後半で重要になります。まず、 requestedAccessTokenVersion を 2 に設定します。これは OBO 交換と SAP 検証のいずれもが v2.0 トークンを期待するためです。次に、 access_as_user 委任スコープを公開します。これは、Quick クライアントアプリがユーザーの代わりにこのアプリを呼び出すために要求する権限です。 TENANT_ID="<your-entra-tenant-id>" INBOUND_APP_NAME="agentcore-mcp-inbound" # Create the inbound app registration az ad app create --display-name "$INBOUND_APP_NAME" --sign-in-audience "AzureADMyOrg" # Capture the Application (client) ID and Object ID INBOUND_APP_ID=$(az ad app list --display-name "$INBOUND_APP_NAME" --query "[0].appId" -o tsv) INBOUND_OBJECT_ID=$(az ad app list --display-name "$INBOUND_APP_NAME" --query "[0].id" -o tsv) # Require v2.0 tokens and set the Application ID URI az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \ --body '{"api":{"requestedAccessTokenVersion":2}}' az ad app update --id "$INBOUND_APP_ID" --identifier-uris "api://${INBOUND_APP_ID}" # Expose the access_as_user delegated scope INBOUND_SCOPE_ID=$(uuidgen) az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \ --body "{\"api\":{\"requestedAccessTokenVersion\":2,\"oauth2PermissionScopes\":[{\"adminConsentDescription\":\"Access AgentCore MCP Server\",\"adminConsentDisplayName\":\"access_as_user\",\"id\":\"${INBOUND_SCOPE_ID}\",\"isEnabled\":true,\"type\":\"User\",\"userConsentDescription\":\"Access AgentCore MCP Server on your behalf\",\"userConsentDisplayName\":\"Access AgentCore MCP\",\"value\":\"access_as_user\"}]}}" # Create the service principal az ad sp create --id "$INBOUND_APP_ID" Step 2: アウトバウンド Entra ID アプリ登録を作成する アウトバウンドアプリは SAP アクセスを表します。AgentCore Identity はこれを OBO 交換のターゲットとして使用し、SAP は最終トークンをこれに対して検証します。この手順では sap_access スコープを公開し、インバウンドアプリが要求できる対象を用意します。また、インバウンドアプリを既知のクライアントアプリケーションとして事前承認します。これは、ユーザーに同意を求めることなく、Entra ID が 2 つのアプリ間で OBO トークンを発行できるようにする設定です。 OUTBOUND_APP_NAME="agentcore-mcp-obo-sap" az ad app create --display-name "$OUTBOUND_APP_NAME" --sign-in-audience "AzureADMyOrg" OUTBOUND_APP_ID=$(az ad app list --display-name "$OUTBOUND_APP_NAME" --query "[0].appId" -o tsv) OUTBOUND_OBJECT_ID=$(az ad app list --display-name "$OUTBOUND_APP_NAME" --query "[0].id" -o tsv) # v2.0 tokens + Application ID URI az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \ --body '{"api":{"requestedAccessTokenVersion":2}}' az ad app update --id "$OUTBOUND_APP_ID" --identifier-uris "api://${OUTBOUND_APP_ID}" # Expose the sap_access delegated scope (SAP validates tokens against this) OUTBOUND_SCOPE_ID=$(uuidgen) az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \ --body "{\"api\":{\"requestedAccessTokenVersion\":2,\"oauth2PermissionScopes\":[{\"adminConsentDescription\":\"Access SAP on behalf of user\",\"adminConsentDisplayName\":\"sap_access\",\"id\":\"${OUTBOUND_SCOPE_ID}\",\"isEnabled\":true,\"type\":\"User\",\"userConsentDescription\":\"Access SAP on your behalf\",\"userConsentDisplayName\":\"SAP Access\",\"value\":\"sap_access\"}]}}" az ad sp create --id "$OUTBOUND_APP_ID" # Pre-authorize the inbound app as a known client application (enables OBO) az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \ --body "{\"api\":{\"knownClientApplications\":[\"${INBOUND_APP_ID}\"]}}" Step 3: 権限と管理者同意を構成する この手順では、インバウンドアプリにアウトバウンドアプリの sap_access スコープへの委任権限を付与し、それを管理者同意します。この付与が OBO チェーンのインバウンドからアウトバウンドへの部分を有効にします。なぜなら、Entra ID は要求元アプリがターゲットスコープへの同意済み委任権限を保持している場合にのみ OBO トークンを発行するためです。 az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \ --body "{\"requiredResourceAccess\":[{\"resourceAppId\":\"${OUTBOUND_APP_ID}\",\"resourceAccess\":[{\"id\":\"${OUTBOUND_SCOPE_ID}\",\"type\":\"Scope\"}]}]}" az ad app permission admin-consent --id "$INBOUND_APP_ID" Step 4: OBO 権限チェーンを構成する この手順は権限チェーンを完成させるもので、不完全な場合 OBO 交換は失敗します。Entra ID は OBO トークンを発行する前に、次の 4 つを一括で検証します。 アサーションの aud が交換を行う client_id と一致すること クライアントアプリがターゲットスコープへの委任権限を保持していること ターゲットアプリの knownClientApplications にクライアントチェーン全体が含まれていること サービスプリンシパルに対する oauth2PermissionGrant が存在すること 重要な設計原則: OBO クライアントはトークンのオーディエンスと一致しなければならない。 Entra ID OBO では、トークン交換を実行する client_id がアサーショントークンの aud クレームと一致する必要があります。Amazon Quick のトークンは aud = Inbound App ID を持つため、AgentCore の認証情報プロバイダーはアウトバウンドアプリではなくインバウンドアプリの認証情報を使用しなければなりません。ここでの不一致は最も一般的な失敗原因であり、 AADSTS500131 （アサーションオーディエンスの不一致）または AADSTS7000114 （OBO が許可されていない）として現れます。 以下のコマンドは、これらの各要件を構成します。Amazon Quick クライアントアプリを作成済み（前提条件を参照）で、その QUICK_APP_ID、QUICK_OBJECT_ID、およびスコープ ID を取得済みであることを前提とします。 # 1. Add Quick + Inbound to the OUTBOUND app's knownClientApplications az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \ --body "{\"api\":{\"knownClientApplications\":[\"${INBOUND_APP_ID}\",\"${QUICK_APP_ID}\"]}}" # 2. Add Quick to the INBOUND app's knownClientApplications az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \ --body "{\"api\":{\"knownClientApplications\":[\"${QUICK_APP_ID}\"]}}" # 3. Grant the Quick client delegated access to both scopes, then admin-consent az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${QUICK_OBJECT_ID}" \ --body "{\"requiredResourceAccess\":[{\"resourceAppId\":\"${INBOUND_APP_ID}\",\"resourceAccess\":[{\"id\":\"${INBOUND_SCOPE_ID}\",\"type\":\"Scope\"}]},{\"resourceAppId\":\"${OUTBOUND_APP_ID}\",\"resourceAccess\":[{\"id\":\"${OUTBOUND_SCOPE_ID}\",\"type\":\"Scope\"}]}]}" az ad app permission admin-consent --id "$QUICK_APP_ID" # 4. Create the oauth2PermissionGrant for the INBOUND service principal INBOUND_SP_ID=$(az ad sp show --id "$INBOUND_APP_ID" --query "id" -o tsv) OUTBOUND_SP_ID=$(az ad sp show --id "$OUTBOUND_APP_ID" --query "id" -o tsv) az rest --method POST \ --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants" \ --body "{\"clientId\":\"${INBOUND_SP_ID}\",\"consentType\":\"AllPrincipals\",\"resourceId\":\"${OUTBOUND_SP_ID}\",\"scope\":\"sap_access\"}" # 5. Emit the email claim on the OUTBOUND app — this is the only claim SAP uses for user mapping az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${OUTBOUND_OBJECT_ID}" \ --body '{"optionalClaims":{"accessToken":[{"name":"email","essential":true}]}}' Step 5: インバウンド Entra ID アプリの詳細を AWS Secrets Manager に保存する AgentCore Identity は認証情報プロバイダーを通じて OBO 交換を実行します。この手順における以下の選択は必須であり、Entra ID が OBO リクエストを検証する方法から直接導かれます。 アウトバウンドアプリではなく、インバウンドアプリの認証情報を使用してください。 Entra ID OBO では、交換を行う client_id がアサーショントークンの aud と一致する必要があり、Quick のトークンは aud = Inbound App ID を持ちます。 AWS_REGION="us-east-1" # Client secret for the INBOUND app + store it in AWS Secrets Manager INBOUND_APP_SECRET=[REDACTED_PASSWORD] ad app credential reset --id "$INBOUND_APP_ID" \ --display-name "obo-exchange-secret" --query "password" -o tsv) aws secretsmanager create-secret \ --name "AWSforSAP-MCP-OAuthCredentials-EntraId" \ --secret-string "{\"clientId\":\"${INBOUND_APP_ID}\",\"clientSecret\":\"${INBOUND_APP_SECRET}\"}" \ --region "$AWS_REGION" Step 6: AWS CloudFormation で MCP Server をデプロイする この手順では、AWS CloudFormation を使って AWS for SAP MCP Server をデプロイします。2 つのパラメーターがサーバーによるリクエスト認証の方法を決定し、CloudFormation は両方の認証コンポーネントをプロビジョニングするため、いずれも手作業で構築する必要はありません。InboundAuthProvider を Entra ID に設定すると、インバウンド認証のために AgentCore Runtime に JWT オーソライザーがアタッチされます。これはランタイム組み込みの JWT オーソライザーであり、Entra ID のディスカバリー URL と許可されたオーディエンスから構成されるもので、別個のカスタムオーソライザーではありません。AuthFlow を ON_BEHALF_OF_TOKEN_EXCHANGE に設定すると、アウトバウンドの OBO 交換を実行する MicrosoftOauth2 認証情報プロバイダーが作成されます。次の表のパラメーターは、サーバーを Entra ID テナントと 2 つのアプリ登録に接続します。 パラメーター 値 SapBaseUrl https://<sap-host>/sap/opu/odata/sap/ SapSystemType S4HANA または ECC InboundAuthProvider Entra ID DiscoveryUrl https://login.microsoftonline.com/{TENANT_ID}/v2.0/.well-known/openid-configuration AllowedAudiences {INBOUND_APP_ID} AuthFlow ON_BEHALF_OF_TOKEN_EXCHANGE SapCredentialsSecret AWSforSAP-MCP-OAuthCredentials-EntraId SapTokenUrl https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token OauthScopes api://{OUTBOUND_APP_ID}/sap_access McpServerReadEnabled true McpServerWriteEnabled true McpServerCreateEnabled true McpServerUpdateEnabled true McpServerDeleteEnabled true McpServerFunctionImportEnabled true TEMPLATE_URL="https://awsforsap-mcp-server-setup-${AWS_REGION}.s3.${AWS_REGION}.amazonaws.com/cfn-launch-template/latest/AwsForSapMcpServerStack.template.json" aws cloudformation create-stack \ --stack-name "sapmcp-${UNIQUE_ID}" \ --template-url "$TEMPLATE_URL" \ --parameters \ ParameterKey=UniqueId,ParameterValue="${UNIQUE_ID}" \ ParameterKey=SapBaseUrl,ParameterValue="${SAP_BASE_URL}" \ ParameterKey=SapSystemType,ParameterValue="S4HANA" \ ParameterKey=InboundAuthProvider,ParameterValue="EntraId" \ ParameterKey=DiscoveryUrl,ParameterValue="https://login.microsoftonline.com/${TENANT_ID}/v2.0/.well-known/openid-configuration" \ ParameterKey=AllowedAudiences,ParameterValue="${INBOUND_APP_ID}" \ ParameterKey=AuthFlow,ParameterValue="ON_BEHALF_OF_TOKEN_EXCHANGE" \ ParameterKey=SapCredentialsSecret,ParameterValue="AWSforSAP-MCP-OAuthCredentials-EntraId" \ ParameterKey=SapTokenUrl,ParameterValue="https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \ ParameterKey=OauthScopes,ParameterValue="api://${OUTBOUND_APP_ID}/sap_access" \ ParameterKey=McpServerVpcSecurityGroup,ParameterValue="${VPC_SG}" \ ParameterKey=McpServerNetworkSubnets,ParameterValue="${SUBNET_ID}" \ ParameterKey=McpServerReadEnabled,ParameterValue="true" \ ParameterKey=McpServerWriteEnabled,ParameterValue="true" \ ParameterKey=McpServerCreateEnabled,ParameterValue="true" \ ParameterKey=McpServerUpdateEnabled,ParameterValue="true" \ ParameterKey=McpServerDeleteEnabled,ParameterValue="true" \ ParameterKey=McpServerFunctionImportEnabled,ParameterValue="true" \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM \ --region "$AWS_REGION" aws cloudformation wait stack-create-complete --stack-name "sapmcp-${UNIQUE_ID}" --region "$AWS_REGION" # Verify both auth components were created aws bedrock-agentcore-control get-oauth2-credential-provider \ --name "AWSForSAP-MCP-OAuth2-Provider-${UNIQUE_ID}" --region "$AWS_REGION" \ --query "{vendor:credentialProviderVendor, clientId:oauth2ProviderConfigOutput.microsoftOauth2ProviderConfig.clientId, status:status}" # Register the CFN-created credential provider's callback URL on the inbound app CALLBACK_URL=$(aws bedrock-agentcore-control get-oauth2-credential-provider \ --name "AWSForSAP-MCP-OAuth2-Provider-${UNIQUE_ID}" --region "$AWS_REGION" \ --query "callbackUrl" --output text) az rest --method PATCH \ --uri "https://graph.microsoft.com/v1.0/applications/${INBOUND_OBJECT_ID}" \ --body "{\"web\":{\"redirectUris\":[\"${CALLBACK_URL}\"]}}" デプロイ後の手順: スタックが正常に作成された後、MCP Server のエンドポイント URL を インバウンドアプリの Identifier URI として登録し（Amazon Quick はこれを resource パラメーターとして送信します）、認証情報プロバイダーのコールバック URL をインバウンドアプリのリダイレクト URI として登録します。 次の表は、各認証コンポーネントとその作成元となるパラメーターをまとめたものです。ランタイム構成の型は customJWTAuthorizer という名前ですが、これは Entra ID の発行者とオーディエンスでパラメーター化された AgentCore Runtime の標準 JWT オーソライザーであり、別個のオーソライザーを記述・デプロイする必要はありません。 コンポーネント 型 自動作成元 Inbound Auth Provider ランタイム上の customJWTAuthorizer InboundAuthProvider + DiscoveryUrl + AllowedAudiences Outbound OAuth2 Provider ランタイム上の MicrosoftOauth2 認証情報プロバイダー AuthFlow=ON_BEHALF_OF_TOKEN_EXCHANGE + SapCredentialsSecret（+ SapTokenUrl + OauthScopes） Step 7: SAP OIDC トラストとユーザーマッピングを構成する SAP 側では、トランザクション SOIDC で OIDC トラストを作成し、SAP に Entra ID からのトークンを受け入れるよう指示します。この手順で ID 伝播が実体を持ちます。なぜなら、SAP はトークンをサービスアカウントではなく指名されたユーザーにマッピングするためです。SAP は以下を検証します。 iss : トークン発行者があなたの Entra ID テナントでなければなりません。 aud : Outbound App ID と一致しなければなりません。 署名 : Entra ID が公開する JWKS に対して検証されます。 ユーザーマッピング : SAP はトークン内の email クレームを個々の SAP ユーザーにマッピングします。 図 3. Entra ID 向けの SAP OIDC 構成 マッピングは email に基づくため、各ユーザーの SAP ビジネスパートナーまたはユーザーレコードが、Entra ID が発行するのと同じメールアドレスを保持していることを確認してください。この一致が、認証済みトークンを MULLERF のような特定の SAP ユーザーに解決するものです。 Step 8: OBO フローをエンドツーエンドでテストする フローをテストする前に、AWS for SAP MCP Server を Amazon Quick のコネクターとして追加します。これは Entra ID に Amazon Quick クライアントアプリをプロビジョニングする手順でもあります。コネクターを追加するには、次の手順を実行します。 Amazon Quick でコネクター（MCP サーバー）設定を開き、新しい MCP コネクターの追加を選択します。 Step 6 の CloudFormation スタック出力にある AWS for SAP MCP Server のエンドポイント URL を入力します。 認証（Authenticate）の手順で「User authentication method」を選択し、Auth 構成を「Custom user based OAuth」に設定して、Entra ID テナントの OAuth フィールドを入力します。次を指定します — Client ID として Amazon Quick クライアントアプリの AppID（client）、Public OAuth client はチェックしないまま、Client secret、Authorization URL（https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/authorize）、および Token URL（https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token）。 コネクターを保存し、対話型サインインを一度完了します。Amazon Quick は Entra ID にクライアントアプリケーションを登録します。その QUICK_APP_ID、QUICK_OBJECT_ID、およびスコープ ID を取得し、権限チェーンをまだ完了していない場合は Step 4 を実行します。 コネクターが配置されたら、実際のユーザーとしてサインインし、「私の未処理の販売オーダーを表示して」のような、SAP の読み取りにマッピングされる自然言語の質問をします。テストが成功すると、以下が確認されます。 Quick が SAP パスワードのプロンプトなしで Entra ID に対してあなたを認証します。 MCP Server が SAP データを返します。 SAP では、Security Audit Log（トランザクション SM20 ）がリクエストをサービスアカウントではなくあなたのユーザーに帰属させます。この最後の点が、ID がエンドツーエンドで伝播したことの証明です。 トランザクション SOIDC で、OIDC トラストがトークンの email クレームを個々の SAP ユーザーにマッピングしていることを確認し、コネクターと CloudFormation の構成が SAP サービスアカウントの認証情報を一切保持していないことを検証します（保存される唯一のシークレットは AWS Secrets Manager 内の Entra ID インバウンドアプリのクライアントシークレットです）。これは、アクセスが共有 SAP パスワードではなく ID 伝播によって付与されていることを証明します。 トラブルシューティング 以下の注記は、最も一般的な問題に対処します。 AADSTS500131（アサーションオーディエンスの不一致） : 認証情報プロバイダーが誤った client_id を使用しています。Quick のトークンの aud と一致する、インバウンドアプリのものでなければなりません。 AADSTS7000114（OBO が許可されていない） : Step 4 の権限チェーンが不完全です。knownClientApplications、委任権限の付与、管理者同意、および oauth2PermissionGrant を確認してください。 SAP がトークンを拒否する : SOIDC トラストの iss、aud = Outbound App ID を再確認し、email クレームが存在し（Step 4.5）、SAP ユーザーと一致していることを確認してください。 始めましょう AI エージェントに SAP へのアクセスを与えることは、ユーザーごとのセキュリティを諦めることを意味しません。Amazon Bedrock AgentCore を基盤とする AWS for SAP MCP Server を使えば、あなたの ID をバックエンドまで完全に保持しながら、Amazon Quick を通じて SAP と対話できます。 このソリューションは 4 つの成果をもたらします。 監査証跡が個々のユーザーのアクションを記録します。 SAP は、すべての AI 主導のリクエストを、共有サービスアカウントではなく実在の人物として認証、認可、監査します。 SAP パスワードを一切保存しません。 OBO 交換は完全にサーバーサイドで実行され、保存される唯一のシークレットは Entra ID インバウンドアプリの認証情報です。 最小権限と監査を維持します。 SAP は引き続きユーザー自身のロールを適用し、そのアクションをユーザー自身の ID の下で記録します。 スコープを分離した設計。 クライアント、インバウンド、アウトバウンドの各アプリを分離し、OBO 交換ではトークンオーディエンスと一致させるためインバウンドアプリの認証情報を使用します。 始めるには、Microsoft Entra ID と AgentCore Identity の On-Behalf-Of トークン交換を用いて AWS for SAP MCP Server をデプロイしてください。これにより、共有 SAP 認証情報なしで、AI エージェントに SAP へのセキュアなユーザーごとのアクセスを提供できます。 Fortescue、PLDT、Harman などのお客様が、どのように AWS for SAP MCP Server を活用してエージェント型 AI の強化を実現しているかについては、 AWS for SAP Blog をご覧ください。今すぐ構築を始めましょう。始めるには、 AWS for SAP MCP Server のページをご覧ください。AWS が何千もの SAP のお客様にとって選ばれるプラットフォームでありイノベーションの場である理由については、 AWS for SAP のページをご覧ください。 著者について Ferry Mulyadi Ferry は、シンガポールの Amazon Web Services（AWS）における World Wide SAP Tech Alliance Principal Partner Solution Architect であり、25 年以上にわたるエンタープライズアプリケーションとクラウドの経験を活かして、エージェント型 AI の進化をリードしています。彼は、人工知能と SAP エコシステムを橋渡しする自律型ワークフロー、エージェント主導のトランスフォーメーションパターン、エンタープライズ規模の統合フレームワークを設計しました。 Rengarajan Sridharan Renga は、AWS の AI and Strategic Partner Engineering における Senior Technical Program Manager であり、SAP ワークロードに焦点を当てたプログラムを推進しています。エンタープライズリソースプランニング（ERP）ソリューションで 20 年以上の経験を持つ Renga は、お客様やパートナーがエンタープライズシステムをモダナイゼーションし、ビジネス価値を最大化してデジタルトランスフォーメーションの成果を推進できるよう支援することを専門としています。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

本ブログは 株式会社クリエイティブ・ウェブ 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 コンタクトセンターにおけるオペレーターの育成は、多くの企業が抱える共通の課題です。新人オペレーターが実際の顧客対応で必要なスキルを身につけるには、ベテランスタッフによるロールプレイ研修が欠かせません。しかし、研修のためにベテランを長時間拘束することは現場の運営負荷を増大させ、研修の頻度や品質にもばらつきが生じがちです。 今回ご紹介するのは、株式会社クリエイティブ・ウェブ様が、Amazon Connect Customer を活用して、AI がお客様役を演じるコールセンター研修用ロールプレイシステムを構築された事例です。不動産管理会社の問い合わせ対応を想定し、実際の電話で AI と会話しながらオペレーターの対応力を鍛え、通話終了後には AI が自動で評価とフィードバックを行う仕組みを実現されています。 前回の取り組みと今回の背景 株式会社クリエイティブ・ウェブ様は、システム・PC サポート・Web サイト・EC 関連の問い合わせ対応サービスを提供されています。 前回のブログ記事 では、Amazon Bedrock を活用した RAG ベースのお問い合わせ管理システムにより、過去の対応履歴を活用した対応サジェスト機能を実現し、コールセンター業務の効率化と品質向上を同時に達成された事例をご紹介しました。 今回、クリエイティブ・ウェブ様は次なるステップとして、オペレーター育成に目を向けられました。前回のシステムで「対応ナレッジの蓄積と活用」を実現した同社が、次に取り組むべき課題として浮かび上がったのが「ナレッジを使いこなせる人材の育成」でした。 株式会社クリエイティブ・ウェブ様の状況と課題 クリエイティブ・ウェブ様がサービスを提供する不動産管理会社のコールセンターでは、入居者からの「水漏れ」「設備故障」「契約に関する質問」など、多岐にわたる問い合わせに日々対応されています。こうした問い合わせには、正確な情報案内はもちろん、感情的になっているお客様への共感力や、適切なエスカレーション判断など、総合的な対応スキルが求められます。 研修機会の確保が難しい ロールプレイ研修にはベテランスタッフが相手役を務める必要があり、現場を長時間離れることが難しいため、十分な研修回数を確保できない状況であった 研修担当者によってロールプレイの内容や難易度が異なり、オペレーターの習熟度にばらつきが生じていた 評価とフィードバックの属人化 研修後の評価が担当者の主観に依存しがちで、改善ポイントの客観的なフィードバックが難しかった オペレーターごとの成長度合いを定量的に把握する手段が乏しく、育成計画の立案が経験頼みになっていた 実践と研修のギャップ テキストベースのマニュアル学習だけでは、実際の電話対応で求められる臨機応変な対応力が十分に身につかない 特に、不満を抱えているお客様や情報が断片的なお客様への対応は、実践を通じてしか鍛えられない領域であった クリエイティブ・ウェブ様は、これらの課題を解決するため、AI がリアルな顧客役を演じ、オペレーターが実際の電話環境で何度でも練習できる研修システムの開発に取り組まれました。 ソリューション・構成内容 クリエイティブ・ウェブ様は、Amazon Connect Customer を活用して以下のような AI ロールプレイ研修システムを構築されました。システムは Amazon Connect Customer を音声対話基盤とし、その AI agents 機能が入居者役を演じます。通話終了後には Amazon Bedrock が対話内容を分析して自動評価を行うサーバーレス構成で設計されています。 Amazon Connect Customer による音声対話基盤 電話の受発信基盤として、オペレーターが実際のソフトフォンを使ってロールプレイを実施できる通話環境を提供 Amazon Connect Customer の AI agents 機能が入居者役として動作し、リアルタイムな音声対話を担う Amazon Bedrock による通話後の自動評価 通話終了後、対話内容（文字起こし）を分析し、評価とフィードバックを生成する採点エンジンとして動作 実際の画面 ロールプレイを開始する際の設定画面です。シナリオの種類（水漏れ、設備故障、騒音トラブルなど）や難易度（初級・中級・上級）に加え、入電者の初期温度感を Lv.1（穏やか）〜 Lv.5（非常に不満）まで選択できます。オペレーターは自身の課題に合わせて条件を細かく設定し、苦手なシチュエーションを繰り返し練習することができます。 ロールプレイ実施中は、画面に現在の状況とアドバイスを見ながら電話対応をすることができます。 ロールプレイ実施中の画面です。オペレーターは実際のソフトフォンを使って AI と会話し、リアルタイムで文字起こしされた対話内容を確認できます。実際の業務と同じ電話操作環境のため、研修と実務のギャップを感じることなくトレーニングに集中できます。 ロールプレイ終了後の自動評価画面です。AI が通話内容を分析し、100 点満点で総合スコアを算出します。評価は「初期対応」「状況確認」「共感・傾聴対応」「案内の正確性」「終話対応」の 5 カテゴリに分かれており、オペレーターの強みと改善点が一目で分かります。さらに、ロールプレイ中の入電者の温度感推移がグラフで可視化され、「どの発言でお客様が落ち着いたか」「どのタイミングで不満が増したか」が直感的に把握できます。これにより、オペレーターは自身の対応の因果関係を具体的に理解し、次の研修に活かすことができます。 また、電話ロールプレイを終えた後も、AI とのやり取りはすべて記録として残るため、後から内容を振り返って復習することができます。文字起こしされた対話ログと評価コメントを照らし合わせながら、「あの場面ではどう対応すべきだったか」をじっくり見直せるので、その場限りで終わらず、時間をおいて何度でも学び直せます。上司や研修担当者が記録を確認して具体的なアドバイスを行うことも可能で、着実なスキル定着につながります。 導入効果 AI ロールプレイ研修システムの導入により、以下の効果が得られました： 研修の質と頻度の飛躍的な向上 AI が相手役を務めるため、ベテランスタッフの拘束が不要になり、オペレーターは 24 時間いつでも研修を実施可能に シナリオと難易度が標準化されたことで、研修品質のばらつきが解消され、全オペレーターが同等の研修を受けられる環境を実現 苦手なシナリオを何度でも繰り返し練習できるため、個人の弱点を効率的に克服 客観的な評価による育成の加速 AI による自動評価で、従来は主観に頼っていたフィードバックが数値化され、改善ポイントが明確に カテゴリ別スコアの推移を追跡することで、オペレーターの成長を定量的に把握し、データに基づいた育成計画の立案が可能に 温度感推移グラフにより、対応の因果関係が可視化され、「もっと共感して」という抽象的な指導が具体的な改善アクションに変わった 実践力の向上 実際の電話環境と同じソフトフォン操作でトレーニングするため、研修と実務の乖離が最小化 温度感のリアルタイム変化により、不満を抱えているお客様への対応力を安全な環境で繰り返し鍛えることが可能に 開発期間の短縮 AWS Samples にて OSS として公開されている 「 AICC Builder 」を活用し、Amazon Connect Customer 上の AI エージェント構築に必要なアセット一式を自動生成。プロトタイプの立ち上げを大幅に短縮 生成されたアセットをベースに、自社の業務知見を活かした評価機能や研修管理画面の開発に集中することが可能に 以下が AICC Builder の実際の画面です。Amazon Connect Customer 上の AI エージェント構築に必要なアセット一式を自動生成でき、入居者キャラクターの設定やシナリオの作り込みを効率的に行えます。この基盤があることで、クリエイティブ・ウェブ様はプロトタイプの立ち上げを大幅に短縮し、自社の業務知見を活かした評価機能や研修管理画面の開発に集中できました。 お客様の声（株式会社クリエイティブ・ウェブ様） 前回の RAG ベースのお問い合わせ管理システムで対応ナレッジの蓄積と活用を実現できましたが、次の課題は「そのナレッジを使いこなせるオペレーターの育成」でした。Amazon Connect Customer を活用した AI ロールプレイシステムにより、ベテランスタッフを拘束することなく、いつでも実践的な研修ができる環境を実現できました。 特に、AI が入居者の温度感をリアルタイムに変化させる仕組みは、実際の電話対応に非常に近い緊張感を再現しており、オペレーターの共感力向上に大きく貢献しています。また、通話後の自動評価により、これまで言語化が難しかった「良い対応」の基準が客観的に示されるようになり、チーム全体の対応品質の底上げにつながっています。 AICC Builder のおかげで AI エージェントの基盤を素早く構築でき、私たちは研修シナリオの作り込みや評価ロジックの開発といった、本来注力すべき領域に集中することができました。 今後の展望 株式会社クリエイティブ・ウェブ様では、本システムをさらに発展させるため、以下の取り組みを計画されています： シナリオの自動生成と拡充 実際の通話履歴やお問い合わせ管理システムに蓄積されたデータから、新しいシナリオを AI が自動生成し、研修のバリエーションを継続的に拡充 不動産管理以外の業種にも展開可能な、業界特化型シナリオテンプレートの整備 個別最適化された育成プラン オペレーターごとの評価データを分析し、弱点に応じた研修プランを自動提案 スコア推移の可視化により、成長を実感できるダッシュボードの強化 多チャネル対応 電話だけでなく、チャットやメールでのロールプレイ研修への対応 Amazon Connect Customer のチャット機能を活用したテキストベースの研修環境の構築 まとめ 本事例は、Amazon Connect Customer を活用することで、AI によるロールプレイシステムを実現した先進的な取り組みです。オペレーター育成における「研修機会の不足」「評価の属人化」「実践と研修のギャップ」という 3 つの課題に対し、AI による 24 時間対応可能なロールプレイ環境、自動評価による客観的なフィードバック、そして実際の電話環境と同じ操作でのトレーニングによって、それぞれを解決しています。 特に注目すべきは、AI が入居者の感情をリアルタイムに変化させることで、実際の電話対応に近い緊張感と臨場感を再現している点です。本事例が、コンタクトセンターのオペレーター育成や生成 AI の活用をご検討中のお客様の参考になれば幸いです。 また、本事例で活用された AICC Builder の詳細は、 ワークショップ や GitHub リポジトリ をご参照ください。 AWS では、生成 AI を活用したソリューション開発を支援するさまざまなイベントやプログラムを定期的に開催しております。技術セッションやハンズオンを通じて実際に技術に触れることができますので、ぜひご参加ください。 https://aws.amazon.com/jp/events/ ご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社クリエイティブ・ウェブ（左から）： 岡部 倫典様、西村 優輝様、藤井 龍生様 株式会社GeekFeed（左から）： 吉田 剛様、君島 翔様、落合 彩佳様 Amazon Web Services Japan 合同会社： ソリューションアーキテクト 森 瞭輔

Amazon CloudWatch は、アプリケーションと AI エージェントを一緒に実行するための、AI を活用したオブザーバビリティエクスペリエンスである CloudWatch Omni を提供するようになりました。Omni には、組織専用の URL からアクセスし、すでに管理している ID でサインインします。そのため、Omni を使用するために AWS Management Console へのアクセス権は必要ありません。Omni は OpenTelemetry を基盤として構築されています。すでに CloudWatch に送信しているテレメトリは、再設定することなく Omni に表示されます。また、OpenTelemetry で計測したその他のワークロードからは、OpenTelemetry Protocol（OTLP）エンドポイントにテレメトリが送信されます。 CloudWatch Omni は、エージェントのオブザーバビリティとアプリケーションのオブザーバビリティの両方を、1 つのエクスペリエンスで提供します。 関連記事では 、生成 AI およびエージェント型ワークロード向けの Omni のエージェントオブザーバビリティ機能についてご紹介しました。この記事では、アプリケーションのオブザーバビリティエクスペリエンスについてご紹介します。 エンジニアリングチームは、オブザーバビリティに費やす時間のかなりの部分を、ダッシュボードの維持、しきい値の調整、インシデント発生時に何が起きたのかを把握するために複数のツールを切り替えて情報をつなぎ合わせる作業に費やしています。問題がチームの境界を越えると、コンテキストは次のエンジニアに自然に引き継がれるのではなく、Slack のスレッドやスクリーンショットに埋もれてしまいます。CloudWatch Omni は、個々のシグナルではなくアプリケーションを中心にオブザーバビリティを整理し、チーム全体を同じワークスペースに集約することで、この状況を変えます。 CloudWatch Omni がもたらすもの CloudWatch Omni は、エンジニアリングチームから現在直面していると聞いている 3 つの課題に対応します。 チーム全体に 1 つのコラボレーション体験を。 すべてのエンジニアは、エンタープライズSSO（Okta、Azure AD、およびその他のプロバイダーをサポートする IAM アイデンティティセンター経由 ）を使用して、単一の URL を通じて CloudWatch Omni にアクセスします。AWS コンソールへのアクセスは不要です。SRE、開発者、データベースエンジニア、マネージャーが同じデータと調査コンテキストを共有します。調査がエスカレーションされた場合、次の担当者は完全なコンテキストがすでに表示された同じセッションに参加できます。 システムは、アプリケーションの進化に合わせて適応します。 CloudWatch Omni はサービスを検出し、依存関係をマッピングして、アラームを自動的に調整します。ダッシュボードを手動で整備したり、しきい値を調整したりする代わりに、重要な項目（可用性の目標、レイテンシーの予算、エラー率のしきい値）を定義するだけで、システムの変化に応じて Omni が自動的に適応します。新しいサービスをデプロイすると、Omni はアプリケーションのトポロジーを自動的に更新します。 Amazon DevOps エージェントによる AI を活用した調査。 Amazon DevOps エージェントはお客様のチームと一緒に調査セッションに参加し 、シグナルを関連付けて次のステップを提案します。エージェントはエンジニアが確認するものと同じテレメトリを使用するため、その提案はアプリケーションの実際の状態に基づいています。複数のサービスにまたがる相関イベントを特定し、依存関係グラフを通じて根本原因に至る経路を追跡し、インシデント後のレビューに備えて調査履歴を保持します。 調査の仕組み 問題が発生すると、CloudWatch Omni はコンテキストがあらかじめ読み込まれた調査セッションを開きます。一般的なインシデントワークフローは次のとおりです: チェックアウトサービスでエラー率の上昇が検出されると、アラームが発報します。Omni は、サービスのトポロジー、相関するシグナル（10 分前のデプロイメント、下流の決済 API におけるレイテンシーの増加）、および DevOps Agent による初期分析を表示するセッションを開きます。 オンコール担当の SRE はデプロイメントとの相関関係を確認し、トレースビューを表示して障害が発生しているエンドポイントを特定し、決済 API のレイテンシーがキャパシティ上限と相関しているかを確認します。 SREは決済チームにエスカレーションされます。決済担当のエンジニアが同じセッションに参加すると、それまでに確認されたすべての情報に加えて、DevOps Agent が決済プロバイダーの API ゲートウェイにおける設定変更との相関関係を特定した結果も確認できます。根本原因を特定してロールバックします。 調査履歴全体が自動的にキャプチャされます。個別のインシデントレポートは必要ありません。 チュートリアル:初めての Space を設定する チーム用に CloudWatch Omni をセットアップするには、CloudWatch コンソールを開いて [CloudWatch Omni を試す] をクリックします。 図 1.CloudWatch コンソール — オムニセットアップページ 次に、 IAM アイデンティティセンター (Okta、Azure AD、およびその他の SAML 2.0 プロバイダーをサポート) を介してアイデンティティプロバイダーを接続します。接続すると、チームメンバーは AWS コンソールの認証情報を必要とせずに、専用 URL から Omni に直接アクセスできるようになります。 チーム用のスペースを作成します。スペースは、チームが所有するアプリケーションとそれに関連するテレメトリをグループ化します。 図 2.CloudWatch Omni Home — アプリケーションモニタリング、分析、エージェントのオブザーバビリティを備えたチームのワークスペース 作成後、Omniはサービスを自動的に検出し、サービス間の依存関係をマッピングします。アプリケーショントポロジがすぐに表示されます。 図 3.アプリケーショントポロジ — サービスと依存関係が自動的にマッピングされます CloudWatch Omni には、アプリケーションについて自然な英語でどんな質問でもできます。Omni がテレメトリーデータを分析し、インサイトを提供します。 図 4.テレメトリを自然言語で操作 サービスの健全性に関するアラートを設定したり、チームにとって重要な項目を構成したり、AWS DevOps エージェントによる調査を開始して根本原因を特定し、緩和策を策定したりすることもできます。 図 5.調査セッション — DevOps エージェントが根本原因を特定し、次のステップを提案します アプリケーション中心の組織 CloudWatch Omni は、インフラストラクチャのコンポーネント単位ではなく、アプリケーション単位でテレメトリーデータを整理します。このシステムは、テレメトリーデータと AWS Config のリソース検出機能からサービスを自動的に検出し、依存関係をマッピングします。これにより、アプリケーションを個々に分離されたリソースの集合ではなく、相互に接続されたシステムとして把握できます。 各チームには、所有するアプリケーションを含むスペースが与えられます。Space は、追加のデータ移動を必要とせず、既存の CloudWatch データ（ログ、メトリクス、トレース、アラーム）を参照します。動的ビューにより、静的ダッシュボードのメンテナンス負担がなくなり、SLO とアプリケーションの健全性を継続的に可視化できます。 使用の開始 使い始めるまでにかかる時間はわずか数分で、既存の CloudWatch 設定を再構成する必要もありません。 既存の CloudWatch のお客様の場合:CloudWatch コンソールで [CloudWatch Omni を試す] をクリックします。既存のすべてのテレメトリーデータ（ログ、メトリクス、トレース、アラーム）をすぐに利用できます。ワークロードは自動的に検出されるため、すぐに調査を開始したり、アプリケーションのトポロジーを確認したりできます。 組織全体にデプロイする場合: 管理者がドメインを設定し、IAM Identity Center 経由で ID プロバイダーを接続し、チームと環境用のスペースを定義し、ユーザーを招待します。各 Space は、追加のデータ移動を必要とせず、既存の CloudWatch データを参照します。 他の環境のアプリケーション用: CloudWatch Omni には、他の環境からテレメトリを簡単に取り込むことができるコネクタが用意されています。取り込まれたすべてのテレメトリーデータは、同じ Space および調査セッション内で、AWS データとともに表示されます。 ジェネレーティブAIとエージェントワークロード向け: 同じCloudWatch Omniエクスペリエンスが、トレース調査、評価フレームワーク、リアルタイムモニタリングなど、AIエージェント専用のオブザーバビリティを実現します。関連記事では、Omniのエージェントオブザーバビリティ機能を紹介しました。そのウォークスルーについては、「 Amazon CloudWatch Omniの紹介:ジェネレーティブAIとエージェントワークロードのためのAIを活用したオブザーバビリティ 」を参照してください。 知っておくべきこと CloudWatch Omni は CloudWatch を拡張します。既存のアラーム、ダッシュボード、API、コンソールのワークフローは、これまでどおり変更なく利用できます。 エンタープライズ SSO に対応した専用の Web アプリケーションからアクセスできます。エンジニアは、これを利用するために AWS コンソールへのアクセス権を持つ必要はありません。 セットアップすると、すべての Omni 調査セッションで DevOps エージェントがデフォルトで有効になります。 料金と利用可能なリージョン Amazon CloudWatch Omni がご利用いただけるようになりました。既存の CloudWatch のお客様は、CloudWatch コンソールから直接お試しいただけます。価格の詳細については、 Amazon CloudWatch の料金表ページをご覧ください 。 開始するには、 Amazon CloudWatch Omni にアクセスするか、 Amazon CloudWatch コンソールで [CloudWatch Omni を試す] をクリックしてください。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 AWS re:Post でフィードバックを共有するか、通常の AWS サポート の連絡先からお問い合わせください。 – Daniel Abib 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします！ シルバーウィークの 5 連休、いかがお過ごしでしたか。どんどんと日が短くなり、1 年の残りを意識しはじめる季節になりましたね。 年末といえば、そのハイライトとなる AWS re:Invent 2026 が、いよいよ視界に入ってきました！今年は 11 月 30 日 (月) から 12 月 4 日 (金) までラスベガスで開催され、2,200 以上のセッションが予定されています。残りは 2 か月あまり。現地参加を検討されている方は、そろそろ社内の調整や渡航準備を動かし始めるタイミングですね。その判断材料として、AWS Startup ブログの連載 ラスベガス5日間で得たもの ── re:Invent に賭けたスタートアップのリアル をぜひご覧ください。技術のキャッチアップはもちろん、事業を動かす出会いやエンジニア採用にまで話が及んでいて、「現地でしか得られないもの」がとても具体的に語られています。記事は随時公開予定です。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年9月14日週の主要なアップデート 9/14(月) Gemma-4-31B-it-assistant および Gemma-4-31B-IT-NVFP4 モデルが Amazon SageMaker JumpStart で利用可能に Google DeepMind の Gemma-4-31B-it-assistant と NVIDIA の Gemma-4-31B-IT-NVFP4 が Amazon SageMaker JumpStart に追加されました。前者は Gemma 4 ファミリーのフラッグシップである 31B の dense モデルのアシスタント調整版で、テキストと画像の入力、256K トークンのコンテキストウィンドウ、140 以上の言語、ネイティブな関数呼び出し (function calling) に対応します。後者は NVIDIA ModelOpt で 4 ビット FP4 (NVFP4) に量子化した派生版で、メモリ使用量を約 18.5 GB (ベースモデル比 68% 削減) に抑え、約 2.5 倍高速な推論を実現しながら元モデルの 97〜99% の品質を維持します。SageMaker コンソールまたは SageMaker Python SDK から数クリックでデプロイできます。 Qwen3.6-35B-A3B-NVFP4 および Wan2.1-T2V-1.3B-Diffusers モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA が量子化した Qwen3.6-35B-A3B-NVFP4 と Alibaba の Wan2.1-T2V-1.3B-Diffusers の 2 つの基盤モデルが Amazon SageMaker JumpStart に追加されました。前者はエージェント型コーディング、マルチモーダル推論、長文コンテキスト理解に向けた Mixture-of-Experts (MoE) モデルで、NVFP4 量子化によりメモリ使用量を大幅に削減しています。後者は 1.3B パラメータのテキストから動画を生成するモデルで、8.19 GB の VRAM で動作します。いずれも SageMaker コンソールまたは SageMaker Python SDK から数クリックでデプロイできます。 9/15(火) Amazon Q Console から CloudTrail イベントを自然言語で分析 AWS CloudTrail が Amazon Q Console と統合され、自然言語で AWS アカウントのアクティビティを調査できるようになりました。SQL クエリの記述やログファイルの手動解析なしに、CloudTrail の設定確認、セキュリティ調査、運用トラブルシューティングを実行できます。Amazon Q Console はユーザーに代わって CloudTrail の証跡 (Trail)、関連する CloudWatch Logs ロググループ、CloudTrail Lake のイベントデータストアをクエリし、一般的なドキュメントではなく実際のアカウントアクティビティに基づいた回答を返します。Amazon Q Console がサポートされるすべての AWS 商用リージョンで利用できます。 AWS Direct Connect が専用接続の定額料金 (flat-rate pricing) を発表 AWS Direct Connect は、10 Gbps および 100 Gbps の専用接続 (Dedicated Connection) を対象とした定額料金モデルを発表しました。接続の帯域幅と、選択した地理的スコープに応じた月額固定料金を支払うことで、選択した料金ティアの範囲内であればデータ転送アウト (DTO) の課金が発生しません。地理的ティアは同一メトロからグローバルまでの 5 段階が用意されており、トラフィックのパターンに合った範囲を選べます。あわせて、冗長用の 2 本目のポートを追加料金なしで含む「ポートペア (port-pair)」という新しいプロビジョニング方式が導入されました。ポートペアの利用は推奨されていますが任意です。課金モードは接続ごとに設定でき、従量課金との切り替えも可能です。中国リージョンを除くすべての AWS 商用リージョンの Direct Connect ロケーションで利用できます。 9/16(水) Amazon Connect Talent が一般提供開始 Amazon Connect Talent は、AI エージェントが候補者の音声面接とスキル評価を代行する採用ソリューションで、今回一般提供を開始しました。Amazon が数十年にわたって蓄積してきた採用サイエンスに基づいて設計されており、構造化された AI 音声面接、コンピテンシーベースの評価、一貫した基準での候補者スコアリングを提供します。料金は候補者評価 1 件の完了につき 20 USD の従量課金で、シートライセンスや最低利用量のコミットメントはありません。初回利用のお客様は AWS 無料利用枠で最大 200 USD 相当のクレジットを利用できます。現時点ではバージニア北部リージョンとオレゴンリージョンのみで利用可能です。 Amazon Connect Customer がカスタムメトリクスの API による作成・管理・検索に対応 Amazon Connect Customer に、カスタムメトリクスをプログラムから管理するための 7 つの API (CreateMetric、DeleteMetric、DescribeMetric、ListMetrics、SearchMetrics、UpdateMetricContent、UpdateMetricMetadata) が追加されました。これまでコンソールでの手動作業が必要だったカスタムメトリクスの定義を、コードとして一元管理できるようになります。複数のインスタンスや環境にメトリクス定義を展開する際の定義のずれ (drift) を防ぎ、すべての変更は AWS CloudTrail に記録されます。Amazon Connect Customer が提供されるすべての AWS リージョンで利用できます。 Amazon ECS が Amazon S3 Files のサポートを Amazon EC2 起動タイプに拡張 Amazon ECS の EC2 起動タイプで実行するタスクから、Amazon S3 Files ボリュームをマウントできるようになりました。S3 Files は Amazon EFS 上に構築された共有ファイルシステムで、S3 バケット内のデータをコード変更なし、コピーやステージングなしに標準的なファイル操作で読み書きできます。これまで AWS Fargate と Amazon ECS Managed Instances で利用可能でしたが、今回の拡張によりAmazon ECS を含む 3 つの起動タイプすべてで同じ仕組みを使えるようになりました。すべての AWS 商用リージョンと AWS GovCloud (US) リージョンで利用できます。 9/17(木) Amazon Quick が個別シートの生成と画像からの分析構築に対応 Amazon Quick の Generate Analysis 機能が拡張され、ダッシュボード作成を効率化する 2 つの機能が追加されました。1 つ目の Generate Sheet は、開いている分析の中に自然言語の指示だけで単一のシートを追加する機能です。2 つ目は、既存ダッシュボードの画像 (他社 BI ツールのものを含む) をプロンプトに添付し、編集可能な分析として再構築する機能です。どちらも生成結果は通常の Amazon Quick の分析であり、公開ワークフロー、埋め込み、CI/CD パイプライン、手動編集とそのまま組み合わせて使えます。提供開始時点では Enterprise サブスクリプションの Author Pro ユーザーが対象で、Author ユーザーも、組織がアクセスを制限していない場合は 2026 年 12 月まで Amazon Quick Enterprise のプロモーションアクセスで利用できます。どちらの機能も、Amazon Quick が利用可能なすべての AWS リージョンで一般提供されています。 AWS Elastic Beanstalk が共有インフラストラクチャ上で複数のアプリケーションを実行する Cluster Mode を導入 AWS Elastic Beanstalk に新しいデプロイモード「Cluster Mode」が追加されました。従来の Standard Mode がアプリケーションごとに専用環境を作るのに対し、Cluster Mode は Amazon EKS を基盤とする、アカウント内のプールされたインフラストラクチャ上で複数のアプリケーションを実行します。ソースコード、Dockerfile、Amazon ECR のコンテナイメージのいずれかを渡すだけで、コンテナ化からプロビジョニング、運用まで Elastic Beanstalk が管理するため、Kubernetes の運用は Elastic Beanstalk 側に任せられます。追加料金はなく、EKS クラスターと EKS Auto Mode を含む消費リソース分のみ課金されます。Elastic Beanstalk が提供されるすべての AWS 商用リージョンで利用できます。 AWS Transfer Family が Network Load Balancer (NLB) 配下の SFTP サーバーで送信元 IP 保持をサポート AWS Transfer Family の SFTP サーバーが、PROXY protocol v2 (PPv2) によるクライアント送信元 IP の保持に対応しました。従来、VPC ホスト型エンドポイントの前段に NLB を配置すると、Transfer Family には NLB のプライベート IP しか見えず、ログ、イベント、カスタム ID プロバイダーの認証リクエストに実際のクライアント IP が記録されませんでした。本アップデートにより、NLB ターゲットグループの PPv2 と、サーバー側で SftpMode を PROXY_PROTOCOL_V2_ENFORCED に設定することを組み合わせて、クライアントの実 IP を IP ベースの認可、監査、コンプライアンス用途に利用できます。なお強制モードに切り替える際は、先に NLB ターゲットグループ側で PPv2 を有効化し、すべての接続で PPv2 ヘッダーが届いていることをログで確認してから切り替えてください。ヘッダーのない経路が残っていると、その接続は拒否されます。あわせて、VPC エンドポイントのセキュリティグループは信頼する NLB 経由の通信のみを許可するよう制限する必要があります。Transfer Family が利用可能なすべての AWS リージョンで利用できます。 9/18(金) AWS PrivateLink がネットワークセグメントへのアクセスを可能にする Tunnel Endpoint を発表 AWS PrivateLink に新しいタイプの VPC エンドポイントである Tunnel Endpoint が追加されました。CIDR 範囲 (ネットワークセグメント) を表す Resource Configuration を作成して AWS RAM で共有すると、共有を受けた側は Tunnel Endpoint を作成し、GENEVE カプセル化を使ってその CIDR 範囲内のリソースにプライベートにアクセスできます。従来はリソースを 1 つずつ Resource Configuration として登録する必要がありましたが、CIDR 単位での共有により、外部のベンダーなどに多数のリソースをまとめて共有できます。料金は Tunnel Endpoint の時間課金と、エンドポイントを通過したデータ処理量に応じた GB 単価の課金です。東京リージョン、大阪リージョンを含む 28 リージョンで利用できます。 新しい AgentCore Runtime が Amazon Bedrock AgentCore で利用可能に Amazon Bedrock AgentCore のサーバーレス microVM コンピュートである AgentCore Runtime の次世代バージョン (platformVersion V2) が利用可能になりました。V2 の主眼は、コンテナイメージのサイズや同時実行数に関係なくコールドスタート時間が一定になることです。エージェント環境を一度準備してスナップショットを取得し、新しいインスタンスはそこから復元する方式により、200 MB から 2 GB のコンテナイメージで P75 コールドスタート 1.9〜2.0 秒を達成しています (V1 は 5.4〜30 秒)。またエラスティックメモリ管理 (elastic memory management) により、セッション中に未使用となったメモリを回収し、ピークではなく実使用量に基づいて課金されます。事前プロビジョニング不要、ゼロスケール、ハードウェアレベルのセッション分離といったサーバーレスの特性はそのまま維持されます。バージニア北部、オハイオ、オレゴン、アイルランド、東京の 5 リージョンで利用でき、ランタイムの作成時と更新時に platformVersion を V2 に設定するだけで有効化できます。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供を開始しました。Moonshot AI によると、Kimi K3 は同社の最も高性能なモデルであり、オープンモデルとして初めて 2.8 兆パラメータに到達したモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを備え、大規模リポジトリをまたぐ長時間のコーディングセッション、スキャンページやスクリーンショットを含む複数ドキュメントの分析、長時間のエージェントワークフローに適しています。Moonshot AI によると、前世代の Kimi K2 と比較してスケーリング効率が約 2.5 倍向上しています。Bedrock 上のオープンウェイトモデルとして初めて明示的プロンプトキャッシュに対応し、キャッシュ読み取りは通常入力の 10 分の 1 の単価で課金されます。提供はクロスリージョン推論経由で、Amazon Bedrock が利用可能なすべての AWS リージョンから呼び出せます。US Geo 推論プロファイルとグローバル推論プロファイルが用意されており、東京リージョン、大阪リージョンからも利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本記事は 2026 年 4 月 29 日に公開された、 Features and workflows with Amazon Timestream for InfluxDB 3 を翻訳したものです。 本記事では、時系列データベースの技術を大きく進化させた Amazon Timestream for InfluxDB 3 のアーキテクチャ設計、機能、ケイパビリティについて、技術的な観点で解説します。この次世代時系列データベースは、従来のエンジンバージョンからアーキテクチャが再設計されています。コア性能を支える Rust、列指向データ処理を実現する Apache Arrow 、効率的なストレージを提供する Apache Parquet 、高性能クエリを可能にする Apache Arrow Flight SQL といったモダンなテクノロジーでゼロから構築されています。 このマネージドサービスは、InfluxData の最新データベースと AWS のインフラストラクチャおよびツールを組み合わせ、お客様の時系列データワークフローをサポートします。Amazon Timestream for InfluxDB 3 を今すぐ使い始めるには、 ドキュメント をご覧ください。 新しいエンジンの機能 InfluxDB 3 のコアエンジンは、ストレージフォーマット、クエリエンジン、ネットワークプロトコルにオープンソースのテクノロジーを使用してゼロから設計された、オープンソースソリューションです。Apache Arrow Flight SQL が InfluxDB 3 の新しい高性能 SQL インターフェイスとして導入されたことで、バージョン 2 で使われていた Flux のような独自言語を使用してクエリする必要がなくなりました。ネイティブ SQL のサポートにより、データベースとのやり取りの障壁が下がり導入が容易になるだけでなく、 Amazon S3 などのオブジェクトストレージに大量のデータを保存できるエンジンの特性を活かし、分析指向のユースケースにも対応しやすくなります。オブジェクトストレージを活用することで、大規模なデータセットを手頃なコストで保持しつつ、Parquet の効率的な列指向フォーマットと Apache Arrow のインメモリ機能により優れたパフォーマンスを実現します。 InfluxDB 2 から得た知見を基に、InfluxDB 3 は InfluxDB 2 では対応できなかったユースケースに対応しています。InfluxDB 3 では、アーキテクチャの変更により、事実上無制限のカーディナリティをサポートしています。変動の大きいデータセットでも、インデックス付きタグとデータベースパフォーマンス低下のトレードオフを気にする必要がなくなりました。InfluxDB 3 はコアなストレージレイヤーとして Amazon S3 を使用しており、Amazon S3 のマルチ AZ アーキテクチャと 99.999999999% のデータ耐久性の恩恵を受けながら、永続ストレージのコスト削減も実現します。 InfluxDB 3 には、時系列データの収集、整理、変換のための新しくて強力な処理エンジンが統合されています。処理エンジンは InfluxDB 3 に組み込まれた Python 仮想マシンであり、時系列データに対してゼロコピー操作を実行できます。例えば、ストレージコストとデータ量を削減するためのダウンサンプリングや、閾値条件や異常検知に基づいて通知をトリガーするためのアラームといった、リアルタイムでのデータ処理機能が利用できます。Python で記述されたプラグインで、トリガーイベントを契機として処理エンジンがデータに対して何をどのように実行するかを定義します。トリガーイベントの種類には、スケジュールされたイベントと WAL フラッシュイベントがあります。Amazon Timestream for InfluxDB 3 には、セキュリティ強化が施された処理エンジンプラグインが用意されています。Timestream for InfluxDB 3 で利用可能なプラグインの一覧は、 処理エンジンのドキュメント で確認できます。 豊富な新機能により、InfluxDB 3 は変動の大きいデータを扱うシステム、直近のデータに対する最適化されたクエリを必要とするワークフロー、マルチノードソリューションを必要とする大量のデータ取り込みに最適です。ユースケースとしては、システムモニタリング、アプリケーションモニタリング、IoT センサーデータなどがあります。また、InfluxDB 3 は、現在メンテナンスモードにある Amazon Timestream for LiveAnalytics の後継として、拡張された機能、優れた柔軟性、そして AWS における時系列ワークロードの今後の道筋を提供します。 Core エディションと Enterprise エディション AWS では、InfluxDB 3 を Core エディションと Enterprise エディションの 2 つで提供しており、それぞれ特定のユースケースに最適化された異なる機能を備えています。両エディションともストレージレイヤーに S3 を使用していますが、アーキテクチャ、想定されるワークロード、料金モデルは大きく異なります。 Amazon Timestream for InfluxDB Core は、直近のデータ（集計要件やタイムスタンプの粒度に応じて通常は過去 3〜5 日間）を常時効率的にクエリする必要があるリアルタイムモニタリングシナリオ向けに設計されています。Core は、高速なクエリレスポンスタイム、ディスクレスアーキテクチャ、Parquet ファイルの永続化、処理エンジンなど、時系列ワークロードに不可欠な機能を提供します。ただし、Core クラスターは単一ノードデプロイに制限されており、データの取り込み、クエリ、圧縮、プロセッシングの 4 つの主要機能が同一インスタンス上で実行され、これらの機能が限られたコンピューティングリソースを共有して使用します。特に、Core にはコンパクター（圧縮を行うコンポーネント）が含まれていないため、大量の時系列履歴データを効率的に保存およびクエリする機能が制限されます。そのため、直近のデータに焦点を当てたユースケースに最適です。 Core クラスターの場合、コストは主にコンピューティングとストレージの料金で構成されます。例えば、バージニア北部リージョン (us-east-1) で db.influx.large インスタンス (2 vCPU) を 1 台使用する場合、コンピューティング料金は 1 時間あたり約 $0.264 × 月 730 時間 = 月額 $192.72 に加え、ストレージ料金が 1 GB あたり $0.023 となります。Core の料金の詳細については、 料金ページ をご覧ください。 Amazon Timestream for InfluxDB Enterprise は、履歴データの保持と分析を必要とする本番ワークロード向けに設計されており、Core の機能を拡張します。Enterprise クラスターにはコンパクター（圧縮を行うコンポーネント）が含まれており、大量の履歴データを保存しつつ、パフォーマンスへの影響を最小限に抑えて効率的にクエリできます。また、Enterprise はマルチノードクラスターデプロイをサポートしており、異なるノードに個別の役割を割り当てることで、データの取り込み、クエリ、圧縮、プロセッシングの各機能を分離し、リソース使用率を最適化できます。Enterprise のその他の機能には、細かいアクセス制御、より柔軟に設定可能なデータ保持ポリシー、高負荷な本番環境向けに強化されたスケーラビリティが含まれます。 InfluxDB 3 Enterprise は、データの取り込みとクエリ負荷の要件に合わせて最大 15 ノードのクラスター構成で利用できます。1〜4 のライターノード、0〜13 の読み取り専用ノード、1 つのコンパクターノードから選択できます。すべてのマルチノードデプロイメントでは、クラスターの可用性を最大化するために異なるアベイラビリティゾーンにインスタンスを分散させます。 Enterprise の料金には、コンピューティングとストレージのコストに加えて、 AWS Marketplace を通じて自動的に有効化される InfluxDB 3 Enterprise ライセンスが含まれます。Enterprise ライセンスは従量課金制で、ノードあたりの時間単位で課金されます。例えば、バージニア北部リージョン (us-east-1) で db.influx.large インスタンス 3 台のクラスターを使用する場合、おおよそのコストは以下のとおりです。 コンピューティング : $0.264/時間 × 3 ノード × 730 時間 = $578.16/月 ライセンス : $0.264/時間 × 1.5 × 3 ノード × 730 時間 = $867.24/月 コンピューティング + ライセンスの合計 : $1,445.4/月、これにストレージ料金 1 GB あたり $0.023 が加算 Enterprise の料金の詳細については、 AWS Marketplace listing をご覧ください。 InfluxDB 3 への時系列データの書き込み 時系列データに InfluxDB を使用するメリットの 1 つは、データ取り込みに使用される人間が読みやすいラインプロトコルテキスト形式です。ラインプロトコルはシンプルで可読性が高いため、InfluxDB が初めてでも始めやすく、複雑なフォーマット要件なしにデータ取り込みのテスト、データモデルの微調整、取り込みパスのデバッグを迅速に行えます。ラインプロトコルは InfluxDB 1 から使用されており、InfluxDB 3 でも引き続き標準として採用されているため、既存ユーザーは継続して使用できます。InfluxDB 1 または 2 からワークフローを移行する際、ラインプロトコルをそのまま使い続けられるだけでなく、InfluxDB 3 では v1・v2 との下位互換性がある書き込みエンドポイントも利用できます。この互換性により、既存のアプリケーション、スクリプト、ツールは変更なしにデータの書き込みを行うことができ、InfluxDB 3 へのアップグレード時に既存の時系列ワークフローの移行をスムーズに行えます。 InfluxData は、InfluxDB 3 へのデータ取り込み用のクライアントライブラリセットを提供しています。これらのライブラリはアプリケーションと統合することで、バッチ処理、ラインプロトコルの構築、gRPC を使用した Arrow Flight プロトコルによるクエリのためのボイラープレートコードを別途記述することなく、データの書き込みとクエリを実行できます。クライアントライブラリは C# .NET、Go、Java、JavaScript、Python で利用可能です。クライアントライブラリの詳細については、「 Client libraries for InfluxDB 3 」を参照してください。 クエリと DSL InfluxDB 3 は、Apache DataFusion をクエリエンジンとして、Apache Arrow Flight SQL をネットワークプロトコルとして使用することで、標準 SQL を主要なクエリ言語として採用しました。このアーキテクチャの転換により、InfluxDB 2 の Flux スクリプト言語が、馴染みのある SQL 構文に置き換わり、学習コストが大幅に低下するとともに、既存の SQL ツールやビジネスインテリジェンスアプリケーションとのシームレスな統合が可能になります。 Apache Arrow Flight SQL は、効率的な列指向データ転送と gRPC ベースの通信を使用して、従来の HTTP ベースのインターフェイスと比較して優れたパフォーマンスの向上を実現します。基盤となる Apache Arrow の列指向フォーマットにより、ベクトル化実行や述語プッシュダウンが可能になり、大規模なデータセットに対する生データクエリと集計クエリの両方でパフォーマンスが向上します。Apache DataFusion のクエリオプティマイザは、フィルターやプロジェクションのプッシュダウンによりデータ処理を最小化し、パフォーマンスをさらに向上させます。 InfluxDB 3 は、リアルタイム分析向けに設計された専用キャッシュ戦略により、時系列ワークロードのクエリパフォーマンスを最適化します。2 つのインメモリキャッシュが最も一般的なクエリパターンを高速化します。 Last Value Cache (LVC) は各フィールドの最新値を保存し、リアルタイムダッシュボードで使用される「最終ポイント」を取得するクエリをミリ秒のレスポンスタイムで返します。 Distinct Value Cache (DVC) はテーブル内の一意なタグ値とフィールド値を保持し、ホスト名やセンサー ID の一覧表示などのメタデータクエリを高速化します。これらのキャッシュにより、一般的なクエリパターンがほぼ瞬時に実行され、大量のデータ取り込みが行われている最中でもダッシュボードの応答性が維持されます。これらの最適化により、InfluxDB 3 は直近のデータ（通常は過去 3〜5 日間）に焦点を当てたモニタリングユースケースに特に効果的であり、これはリアルタイム分析向けの Core エディションの設計と合致しています。 移行の互換性と幅広いデプロイシナリオに対応するため、InfluxDB 3 はモダンな SQL インターフェイスに加えて v1 互換の InfluxQL エンドポイントを提供しており、レガシーアプリケーションを変更なしに引き続き運用できます。InfluxDB 3 Explorer と Timestream for InfluxDB の利用を開始するには、 InfluxData のドキュメント を参照してください。 Explorer ユーザーインターフェイス InfluxDB 3 は、InfluxDB 3 Explorer のグラフィカルインターフェイスを通じて管理できます。 InfluxDB 3 Explorer を使用すると、データベースの管理、データの取り込みやクエリ、可視化など、さまざまな操作を実行できます。Timestream for InfluxDB 3 で InfluxDB 3 Explorer を使用するには、 InfluxData のクイックスタートガイド に従って Docker で Explorer を実行してください。 データベースの管理 Explorer では、InfluxDB 3 インスタンスのホストアドレスと、関連付けられたトークンを指定して新しい接続を作成できます。インスタンスが追加され検証されると、Explorer を使用してデータベースを管理できます。Explorer では、新しいデータベースの作成や既存のデータベースの削除が可能です。 データのクエリと可視化 InfluxDB 3 Explorer 内の Data Explorer を使用すると、SQL クエリを実行したり、自然言語を使用してデータを確認できます。InfluxDB 3 の SQL 実装の詳細については、 InfluxData の SQL reference documentation を参照してください。 結果は Explorer 内で折れ線グラフや棒グラフとして表示でき、CSV、JSON、Parquet にエクスポートすることもできます。さらに、結果をダッシュボードに追加して、データのインサイトを整理することもできます。 現行バージョンの Explorer は、Timestream for InfluxDB 3 エンジンの基本を理解し、クエリ構文を試し、管理オプションに慣れることを目的として設計されている点に留意してください。パフォーマンステスト、複雑なクエリパターン、本番ワークロードに必要な機能は、InfluxDB CLI または API ですべて利用できます。Explorer は、より高度なツールに移行する前にシステムの基本を安全に学べる学習環境として活用してください。 データの取り込み Explorer から直接データを取り込むことができます。Explorer には、ラインプロトコル、InfluxDB 3 のクライアントライブラリ、InfluxDB 3 の REST API、Telegraf の使用方法、CSV や JSON データのインポート方法、サンプルデータの取り込み方法など、InfluxDB へのデータ書き込みを支援するガイドが用意されています。 すぐに使い始められるよう、Explorer 内からサンプルデータを取り込むことができます。サンプルデータセットには、大気質センサーデータ、鳥の渡りデータ、ビットコインの過去の価格と取引量データ、気候データが含まれます。 デプロイメントの監視 インスタンスのデプロイ後、サイジングの妥当性を検証し、最適化の余地がないかを確認するため、パフォーマンスをモニタリングすることが重要です。Amazon CloudWatch は、CPU 使用率やメモリ使用量など、Timestream for InfluxDB 3 の重要なメトリクスを提供します。InfluxDB 3 の処理エンジンに含まれる System Metrics Plugin は、CloudWatch と同様のサーバーレベルのパフォーマンスデータを収集します。これには、詳細な CPU 統計（全体およびコアごと）、メモリ使用量の内訳、ディスク I/O パフォーマンス、ネットワークインターフェイス統計が含まれます。 データベース固有のパフォーマンスメトリクスについてより深い洞察を得るには、メトリクスエンドポイントをスクレイピングすることで、クエリパフォーマンス、書き込みスループット、その他のサービスレベル指標を詳細にモニタリングするための包括的な内部メトリクスを収集できます。Timestream for InfluxDB インスタンスの /metrics エンドポイントをスクレイピングする包括的なメトリクス収集ソリューションを提供しています。このソリューションは、Telegraf を実行する EC2 インスタンスをデプロイし、クエリパフォーマンス、書き込みスループット、メモリ使用パターンなどの内部エンジンメトリクスを継続的に収集した後、CloudWatch に取り込み、事前設定された Grafana ダッシュボードで可視化します。ダッシュボードには、インスタンスのサイジング仕様に基づく主要パフォーマンス指標をモニタリングするパネルが含まれており、サイジングの判断の検証と最適化の機会の特定に役立ちます。 デプロイ手順、設定オプション、サンプルスクリプトについては、 GitHub リポジトリ をご覧ください。リポジトリには、Telegraf の設定から Grafana ダッシュボードの作成まで、セットアッププロセスを自動化する完全な CDK アプリケーションが含まれています。 まとめ Apache Arrow、Parquet、Flight SQL を採用した InfluxDB 3 の再設計により、ビジネスニーズに対してパフォーマンス上のメリットと長期的な相互運用性を提供するオープンソースフレームワークが構築されました。ネイティブ SQL サポートにより独自のクエリ言語を学ぶ負担が軽減され、処理エンジンの組み込み Python ランタイムによりゼロコピーのデータ変換が可能になります。 InfluxDB 3 Explorer は、データベース管理、クエリの実験、データの可視化に使用できます。本番環境への移行に際しては、CloudWatch 統合やメトリクス収集によるモニタリングソリューションがパフォーマンス特性の可視性を確保します。 InfluxDB 3 は、統合された処理エンジン、無制限のカーディナリティサポート、コスト効率の高い S3 データストレージにより、強力な新機能を提供します。 Amazon Timestream for InfluxDB 3 にアクセスしてクラスターをデプロイし、この新しい時系列データベースで利用可能なすべての機能を実際にお試しください。 著者について Victor Servin Victor は AWS の Amazon Timestream チームのシニアプロダクトマネージャーです。プロダクトレッドグロース戦略やスケーラブルなアーキテクチャでスタートアップを支援してきた長年の専門知識を持ち、データドリブンなアプローチで Timestream のような分析プロダクトの普及を推進しています。豊富な経験とカスタマーサクセスへの取り組みにより、お客様が効率的に目標を達成できるようサポートしています。 Forest Vey Forest は Improving 社のチームリードです。時系列およびサーバーレステクノロジーの経験を持ち、クラウド開発と組み込みシステムへの情熱が高まっています。ソフトウェア開発の学習以外の時間では、友人とのロッククライミングやハイキングを楽しんでいます。 Trevor Bonas Trevor は Improving 社のシニアソフトウェア開発者です。時系列データベースと ODBC ドライバーの開発経験があります。プライベートでは小説の執筆や、ゲーム開発にも取り組んでいます。 Fred Park Fred は Improving 社のシニアソフトウェア開発者で、時系列データベースと AI エージェントのオブザーバビリティを専門としています。VR やクラウドサービスから量子コンピューティングまで幅広いバックグラウンドを持ち、新しいテクノロジーに惹かれています。コーディング以外の時間は、ハイキングに出かけたり友人と音楽を作ったりしています。 本記事の翻訳はクラウドサポートエンジニアの平出が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 9 月 17 日に更新された About Amazon の記事「 AWS、米国とアイルランドを結ぶ海底ケーブル Fastnet を展開 」では、米国メリーランド州とアイルランドのコーク県を結ぶ大西洋横断の海底光ファイバーケーブル Fastnet が紹介されています。2028 年の運用開始時には 320 Tbps を超える設計容量（HD 映画 1,250 万本の同時ストリーミングに相当）を備え、従来のケーブル回廊から離れた陸揚げ地点によって、他の海底ケーブルに問題が起きてもサービスを継続できる経路の多様性を確保します。増え続ける AI のトラフィックを見据えた設計で、生成 AI やエージェントを支える土台となるネットワーク層にも AWS の投資が続いていることが分かります。AWSを支えるインフラの裏側に興味がある方は是非読んでみてください。 また、お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が予定されています。是非カレンダーをチェックしてご参加ください。 それでは 9 月 14 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 AWS Professional Services と実現する第一興商カラオケ聴感採点 AI の開発 」 株式会社第一興商と Amazon Web Services Japan の共同執筆記事です。通信カラオケ「DAM」シリーズの採点機能を高度化するため、第一興商は AWS Professional Services と共同で人間の聴感に即した歌声評価 AI「聴感採点モデル」を開発し、フラッグシップモデル LIVE DAM WAO! に搭載された採点機能「精密採点Ai Heart」の中核として活用しています。従来の機械採点は音程・リズム・ビブラートなどの音響パラメータを機械的に評価する方式で、人間が心地よいと感じる歌声のニュアンスを十分に評価できず、機械的に高得点を狙う「採点歌い」を過大評価しがちという課題がありました。最も困難だったのは「人間の聴感」を表す教師データの作成で、当初の 5 段階尺度法は審査員のブレが大きかったため、AWS Professional Services の提案で 2 つの歌声を聴き比べる一対比較法に切り替え、約 15 万回のラベル作業を経て Bradley-Terry 法で聴感スコアに変換しています。歌唱音源はオープンソースの深層学習モデル Audio Embedding Generator で 1 秒ごとに 128 次元のベクトルに変換し、AWS Fargate for Amazon ECS による最大 1,000 並列の基盤で約 13 万ファイルを 1.5 時間で処理しました。ラベリングには Amazon SageMaker Ground Truth、モデルの学習には AutoGluon Tabular と Amazon SageMaker AI を使い、製品化の際には DAM 端末のスペックに合わせた軽量化も行っています。人の感性という定量化しにくいものを教師データに落とし込む工程の工夫は、他分野の機械学習にも参考になります。 AWS生成AI国内事例ブログ「 【寄稿】株式会社レスター、Amazon Bedrock で顧客課題とグループの解決力をつなぐ情報プラットフォームを構築 」 半導体・電子部品の販売やソリューション提供などを手がける株式会社レスターによる寄稿記事です。事業領域の拡大とグループ再編で顧客基盤や商材、知見が広がる一方、他の会社・事業・部門が何を得意とし、どの顧客と接点を持つのかを把握しにくいという課題に対し、分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（RMS）は、顧客ニーズと解決手段を結びつけるマッチングの仕組みであると同時に、顧客・取引実績・担当者・商材・議事録などを関係性を保ったまま蓄積するグループ共通のデータウェアハウスです。情報の流れを「データ化」「蓄積・統合」「引き出して提案へつなぐ」の 3 段階に整理し、AI 議事録では商談の録音を Amazon Transcribe で文字起こし・話者分離したうえで Amazon Bedrock 上の Anthropic Claude が議事録として整理し、AI チャットボットでは LangGraph で構築したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless による RAG（検索拡張生成）で社内文書や議事録を検索します。録音時の同意取得、議事録ごとに参照対象へ含めるかの選択、競合情報の閲覧制限、人による最終判断といった運用ルールに加え、モデルの追加学習と RAG での参照を混同しないよう「AI に学習させる」ではなく「社内 AI 回答時の参照対象に含めるか」と表現する工夫も紹介されています。 AWS生成AI国内事例ブログ「 NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第1回）：フィジカルAI領域でのML開発への適用 」 株式会社NTTドコモ モバイルイノベーションテック部が、AWS が提唱する AI-DLC（AI-Driven Development Lifecycle）の TTT（Train The Trainer）に参加し、フィジカル AI（現実世界で物理的に動作する AI）領域の機械学習パイプラインを 3 日間のチーム開発で構築した取り組みを、全 2 回で紹介する寄稿記事の第 1 回です。対象は SO-101 ロボットアームで「キューブを持ち上げる」タスクで、模倣学習モデル（ACT）は人手で収集した 10 件のデモデータでは成功率 10%、NVIDIA の COSMOS や Mimic によるデータ増幅で 45% まで向上したものの改善が頭打ちになったため、模倣学習で得た動作知識を軽量なポリシーに蒸留し強化学習で改善する RPD（Refined Policy Distillation）論文のアプローチを採用しています。個人が AI と対話しながら進める Vibe Coding では判断やコンテキストが蓄積されないという課題意識から、要件の構造化と設計レビューを重視する AI-DLC を ML 開発に適用し、Inception フェーズではチーム全員が Kiro を囲むモブスタイルで論文や専門情報を読み込ませながら、4 つのタスクリストと 3 つの実装ユニットを定義しました。Kiro による設計レビューでは、チェックポイント形式の不一致や入力次元の食い違いなど 11 個の不整合を実装前に検出し、Inception フェーズだけで 30 以上の構造化ドキュメントを生成しています。「コードが動くが出力が正しくない」不具合が起きやすい ML 開発で、設計段階の整合性チェックが手戻りの削減につながるという実感が語られています。 AWS生成AI国内事例ブログ「 NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第2回）：2チーム並行開発の実験結果と知見 」 第 2 回は、Construction フェーズにおける 2 チーム並行開発の実験結果と知見です。両チームは蒸留から PPO（強化学習）、評価までのパイプライン構造を共有しつつ、チームピンクは KL ペナルティの効果検証、チームブルーは蒸留初期化そのものの効果検証と、細部の設計判断を分けて比較しました。実装開始直後に ACT の学習環境構築に想定以上の工数がかかると判明したチームブルーは、AI-DLC のプロセスに従って Inception フェーズに立ち戻り、タスクリストの優先度を根拠にスコープを絞る軌道修正を行っています。3 日間の結果は、模倣学習のみのベースライン 45% に対し、チームブルーで蒸留あり 64%、蒸留なし 90% と「蒸留初期化は逆効果」に見えるものでしたが、TTT 後に構造化された実験記録を読み返して Inception に立ち戻ったところ、座標変換の欠落が真因だったことが数時間で判明しました。座標変換を修正し損失関数を変更して再蒸留したうえで PPO を実行した結果、成功率は 97% に到達し、蒸留なしの 90% を統計的に有意に上回っています。1 日で 3 回の実験サイクルを回せたこと、専門家が不在でもパイプラインを構築でき専門家は品質の最終確認に集中できる状態になったこと、そして失敗の記録が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する利点として整理されています。 ブログ記事「 【開催報告】ファッション・アパレル業界向け 第一回ナレッジ共有会 〜 SMART から始まる業界共通課題への挑戦と学びの場 」 2026 年 7 月 29 日に開催された、ファッション・アパレル業界のお客様 6 社 20 名が参加したナレッジ共有会の開催報告です。AWS Prototyping Program から生まれ 2026 年 4 月に GitHub（aws-samples）で公開された店舗業務支援 AI エージェント SMART（Store Manager Agent for Retail Tech）と、Kiro も活用した合同ブートキャンプを起点に、各社が取り組んできた AI エージェント開発の実践ナレッジを企業の垣根を越えて共有する場です。サザビーリーグ IRIS 様は、グループの飲食ブランドである麺屋 猪一を対象に、SMART をベースとした週報・月報の自動生成機能を Amazon Bedrock、Amazon EventBridge、AWS Lambda、Amazon S3 Tables、Amazon Athena、Amazon SNS などで約 1 ヶ月半で開発し、店舗 PoC では約 15 分かかっていた週報作成が 0 分になり、現在は全 4 店舗で利用が始まっています。ジンズ様は店舗出身で IT 未経験のメンバーが Kiro とともに 2 週間で、Amazon Transcribe による音声テキスト化、Amazon Bedrock による感情分析・ペイン分類、改善案の自動生成、Excel 出力までを行う店舗フィードバック収集 Web アプリを構築し、アンドエスティ HD 様は「AI は判断しない。作戦を複数提示し、人が決める」という設計思想のもと Amazon Bedrock AgentCore を活用した在庫消化 Agent の開発を 2.5 ヶ月進めています。 ブログ記事「 セキュリティにおける AI の現在地: 信頼構築に最も重要な指標の測定 」 AWS は、AI モデルが実際の脆弱性と「危険に見えても本当は安全なコード」を区別できるかを直接測定する初のベンチマーク Deception Benchmark を公開しました。16 のプログラミング言語、70 を超える CWE（Common Weakness Enumeration）カテゴリにわたる 14,822 個のサンプルで構成され、パラメータ化されたステートメントで SQL インジェクションのパスが閉じられている Flask エンドポイントのように、脆弱性パターンは見えるが緩和策によって悪用不可能になっているコードが含まれます。従来のベンチマークは AI が脆弱性を発見・悪用できるかを測るものでしたが、本ベンチマークは誤検出を見分ける防御側の適合率を測る点が新しく、5 社 12 モデルを評価した結果、標準的なプロンプトでは適合率が 50% 台半ばにとどまり、偽陽性率（安全なコードを脆弱と判定する率）と偽陰性率（実際の脆弱性を見逃す率）の両方を本番利用の最低基準とする 10% 未満に抑えられた構成はありませんでした。エクスプロイトの実証を求めるプロンプトでは偽陽性率が 17〜74 ポイント下がる一方で実際の脆弱性の 7〜44% を見逃すなど、どのモデルにも同じ失敗パターンが見られます。サンプルと評価ワークフローは GitHub で公開されており、ベンチマークが暗記の問題にならないようラベルは非公開です。AI セキュリティツールを評価する際は、脆弱性を発見できるかだけでなくどのくらいの頻度で誤るかをベンダーに確認し、リスクの高いコードパスでは人間の検証と組み合わせることが推奨されています。 ブログ記事「 自動推論に立ちはだかる 3 つの難題 」 Amazon の vice president 兼 distinguished scientist である Byron Cook 氏が 2025 年 8 月に Amazon Science Blog に公開した記事の翻訳です。生成 AI ベースのシステムで正しい推論を実現する際に最も厄介な 3 つの側面として、あいまいな自然言語を構造化された言語へ変換すること、絶えず変化し時には矛盾するルールのもとで何を真理とするかを定義すること、そして組み合わせの数が天文学的になる中で確定的に推論することを挙げ、Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）がそれぞれにどう対処しているかを解説しています。自然言語の変換では、形式言語への変換候補を複数生成してソルバーで等価かどうかを証明・反証し、意味が食い違えばユーザーに確認を求めます。確定的な推論では SAT（充足可能性問題）ソルバーを活用しつつ、自身の判定結果を参照して矛盾を生むルールのように正しい答えが存在しないケースを Gödel の不完全性定理と結び付け、無矛盾性と完全性を同時に満たせない中で AWS は無矛盾性を選んだと述べています。自動推論チェックの背景にある考え方を理解するのに役立つ記事です。 ブログ記事「 はじめての自動推論 」 同じく Byron Cook 氏が 2021 年 12 月に Amazon Science Blog に公開した記事の翻訳で、上記「自動推論に立ちはだかる 3 つの難題」を読む前の予備知識としておすすめです。自動推論についてまったく知識のない業界の実務者向けに書かれており、必要な前提知識は短い C と Python のコード断片を読めることだけです。x + y == y + x を返す関数が false を返し得るかを unsigned int の全組み合わせで網羅的にテストすると 1,360 年以上かかる一方、自動推論ツールは代数を使ってミリ秒単位で答えを出せるという例から始まり、ループが必ず停止するかを推論する少し複雑な例を通じて、ツールが制御構造、最終的に真になること、常に真であることをどう推論しているかを直感的に説明します。末尾には書籍、国際会議、ツール、講演やブログへのリンクが豊富にまとめられており、さらに学びたい方の出発点になります。 ブログ記事「 自動推論による数学的確実性の 10 年: Automated Reasoning Group が歩んだ道 」 こちらも同じくByron Cook 氏が 2026 年 8 月に Amazon Science Blog に公開した記事の翻訳で、2016 年に発足した Amazon の Automated Reasoning Group（ARG）の 10 年を振り返ります。2016 年の第 1 回 Demo Day で紹介された、VPC ネットワークに関する質問に答えるツール Tiros は Amazon Inspector のネットワークセキュリティ分析や Reachability Analyzer の基盤になり、そこから派生した Zelkova は S3 Block Public Access や IAM Access Analyzer などポリシーを分析するツールの基盤になっています。現在 ARG の本番サービスは 1 日あたり数十億件のクエリを処理し、生成 AI 向けには Amazon Bedrock Guardrails の自動推論チェックがモデルの応答をポリシーに照らして形式論理で検証しています（検証精度は最大 99%）。自動推論が AWS のセキュリティと信頼性をどう支えてきたのか、その全体像をつかめる記事です。 ブログ記事「 エージェント型 AI による ERP ビジネスプロセス運用の変革 」 ある大手企業の Direct Ship（直送）請求業務では、ERP における手作業の例外処理が請求の遅延や収益認識への影響を招いていました。Accenture は Amazon Bedrock や Amazon Bedrock AgentCore などを用いたエージェント型 AI ソリューションを 5 週間で稼働させ、SOP（標準作業手順書）やジョブエイド、組織内のナレッジを一元化して自然言語で質問できる Digital Assistant と、SAP S/4HANA や認証用の Okta といった既存エンタープライズシステムとの統合機能を提供しています。アーキテクチャは、基盤モデルを提供する Amazon Bedrock、ツールの選択とワークフローのオーケストレーションを担う Strands Agents SDK、複数ターンの会話コンテキストを保持する Amazon Bedrock AgentCore、SAP S/4HANA へ安全に接続する AWS Lambda、事前処理した例外レポートを保存する Amazon RDS、レポートデータのロードを制御する AWS Step Functions の 6 つのサービスで構成されています。複数システムを行き来せずに SAP データへ即時アクセスでき、価値の高い注文を事後対応ではなくプロアクティブに処理できるようになったほか、新しいチームメンバーが対話を通じて組織のナレッジにアクセスできるようになった点が成果として挙げられ、同じパターンは調達や在庫管理など他の SAP モジュールにも拡張できるとしています。 ブログ記事「 ERP例外処理をAWSエージェント型標準作業手順書（SOP）で自動化 」 ERP の例外処理を AI エージェントで自動化するためのフレームワークとリファレンスアーキテクチャを解説する翻訳記事です。請求書の例外や購買発注（PO）の承認ブロック、月次決算などで発生する手作業の介入に対し、SAP ユースケース向けの AWS Agentic AI Solutions Framework と、その中核となるエージェント型標準作業手順書（Agentic SOP）を紹介しています。Agentic SOP は、業務プロセスごとに別々のエージェントを作るのではなく、ナレッジベースから SOP を動的に解釈し、SAP と非 SAP システムをまたいで複数ステップの例外を自律的に解決する単一の AI エージェントで、判断や承認が必要な箇所ではヒューマン・イン・ザ・ループの制御が働きます。フレームワークは、アドバイザリーモードから監督付き実行、自律的な解決へと段階的に信頼を獲得する仕組み、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP（Model Context Protocol）サーバー、ID を意識したセキュリティとコンプライアンス、監査水準の永続的な状態管理という 5 つのコア機能で構成されます。リファレンスアーキテクチャでは、Amazon EventBridge がスケジュール実行する AWS Lambda で SAP OData サービスから例外を検知し、Amazon DynamoDB に状態と監査証跡を記録しながら、Amazon Bedrock AgentCore 上の Strands エージェントが Amazon Bedrock Knowledge Bases から SOP と SAP OData API 仕様を取得して SAP への操作を実行し、必要に応じて Amazon SES 経由で人間へエスカレーションします。あるグローバル製造企業では、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超の購買管理において、1 決算サイクルあたり 30 日超かかっていた手作業が PO あたり数分で完了するようになったとしています。 ブログ記事「 月刊 AWS 製造 2026 年 9 月号 」 製造業向けに 8 月に公開されたブログとサービスアップデートをまとめた月刊記事です。今月のピックアップトピックは「エージェントに現場を任せるとき、境界線をどこに引くか」で、PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあると指摘しています。コニカミノルタ様の「未来の実験室」では AI の担当を目標色・操作候補・停止条件へ分解した JSON の中間表現までに絞って座標制御は人が設計した決定論的な制御層が担うこと、SUMCO 様の SynchroFabAI では AI に任せるのは異常状態と因果関係の推測までで操作は人間が実施すること、AWS Summit の Physical AI デモではエージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ったことなど、AI の判断と現実世界への操作を直結させない共通の構図を取り上げています。境界を決める物差しとしては Amazon Science の SOP-Bench を挙げ、不要なツールを追加すると成功率がほぼ半減した実験結果を紹介したうえで、決めた境界を Amazon Bedrock AgentCore の時間的ポリシーや AgentCore Payments でインフラ側から強制する考え方をまとめています。 ブログ記事「 Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応 」 Kiro の IDE、CLI、Web のすべてで、GPT‑5.6 Sol、Terra、Luna が 100 万トークンのコンテキストウィンドウに対応しました。272K から 1M への拡大により、コードベース全体や長文ドキュメント、長く続いたマルチターンのエージェント履歴を、チャンク分割や要約を挟まず細部を失わないまま 1 回のリクエストで処理できます。記事では、レガシー移行や依存関係のマッピングといったリポジトリ規模の理解、API レイヤーやスキーマ、アプリケーションの状態が絡み合うバグのエンドツーエンドのデバッグ、セッションの全履歴を視界に残したまま進める長時間のエージェンティックなタスクの 3 つを、1 回のパスで可能になる仕事の例として挙げています。 ブログ記事「 Kiro Web の自律モードで技術的負債に大規模に立ち向かう 」 Kani Rust Verifier や CBMC といったオープンソースの形式検証ツールの保守や開発を担う AWS Automated Reasoning Group が、2025 年 11 月時点で 916 件あったオープン issue に Kiro Web の自律モードで取り組んだ事例です。app.kiro.dev でタスクを記述するか、GitHub issue に kiro ラベルを付けるか、コメントで /kiro とメンションすると、Kiro は隔離されたサンドボックスにリポジトリをクローンし、issue と関連コードの分析、作業の分解、変更の実装、テストスイート全体の実行を経てプルリクエストを開きます。Kiro はマージ権限を持たず、人間が書いたコードと同じ承認要件の対象になります。2 か月で Kiro は 87 件のオープン issue に対応するプルリクエストを提出し、これはそれまでの 22 か月でチームが対応した 94 件に迫る数で、マージされた Kiro 生成コードが持ち込んだリグレッションはゼロでした。2 年以上バックログに残っていた Kani コンパイラのクラッシュの issue を人間の作業 5 分未満で修正とリグレッションテストを含むプルリクエストにつなげたケーススタディのほか、CI は通るが修正を検証していないテスト、アーキテクチャ的に誤った修正、プラットフォーム固有の失敗、フォーマット違反といったうまくいかなかったパターンも紹介されています。 ブログ記事「 Claude Fable 5.1 が Kiro で利用可能になりました 」 Anthropic の Claude Fable 5.1 が、Kiro のエンタープライズ顧客向けに利用可能になりました。バグ修正や関数のリファクタリングといったインタラクティブなタスク、大規模なリファクタリングや長時間の自律実行のような複数ステップにわたるタスク、大規模なコードベース全体にまたがる推論を必要とするセキュリティやシステムレベルの複雑なタスクの 3 種類で到達点を引き上げるとしています。モデルはセッション全体を通して計画を保持し、Kiro の spec 駆動のアプローチによりタスクが成功しないと判断された場合には早期に停止してクレジットの消費を抑えます。 ブログ記事「 Kiro Crew でソフトウェアファクトリーを構築し、1 週間で 1000 件の PR をマージした方法 」 Kiro Crew をフルタイムで開発する 3 人のエンジニアが、7 日間で 1,000 件のプルリクエストをマージした経緯を振り返っています。1 日あたり 120 件を超えるプルリクエストはすべて CI とレビューを通っており、この数字は狙ったものではなく、並行開発の限界にぶつかるたびに 1 人がより多くのセッションを回せる進め方を生み出してきた結果だとしています。Kiro Crew 自体はこの 3 人を中心に 500 人近いコミュニティコントリビューターとともに開発されています。その変化は、1 セッションを手作業で回す段階、複数のタブを人間がつなぐ段階、memory・ダッシュボード・cron・workflow でセッションが温まった状態から始まる段階（10〜20 セッション）、triage・実装・レビュー・マージを独立したステージとキューでつなぐ agent pipeline の段階（20 セッション以上）、そしてセッションの外側に立つエージェントがゴールの分解・割り当て・巡回・受け入れ・順序付けを担い人間はゴールを持つだけになる Crew Mode の段階（50 セッション以上）の 5 つに整理されています。同時に、エージェント間の調整、memory の境界、ホスト側で強制する権限制御、エージェントが書き換えられない監査ログという 4 つのガバナンス上の問題と、数百セッション規模で立ち上がるコストの問題にも踏みこんでいます。 サービスアップデート 新しい AgentCore Runtime が Amazon Bedrock AgentCore で利用可能に Amazon Bedrock AgentCore 内のサーバーレス microVM コンピュートである AgentCore Runtime の次世代版が利用可能になりました。新しい Runtime は、セッション中に使われなくなったメモリを回収する弾力的なメモリ管理によってピーク値ではなく実際の使用量に対して課金されるようになり、エージェント環境を一度準備してスナップショットを取り、新しいインスタンスはそこから復元する仕組みによって、コンテナイメージのサイズや同時実行数に関係なく一貫したコールドスタート時間を実現します。事前プロビジョニング不要、ゼロへのスケール、ハードウェアで強制されるセッション分離、使った分だけの支払いというサーバーレスモデルはそのままです。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（東京）で利用でき、ランタイムの作成または更新時に platformVersion を V2 に設定することで使い始められます。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始となりました。Moonshot AI によれば、Kimi K3 は同社で最も高性能なモデルで、2.8 兆パラメータに到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模リポジトリにまたがる長時間のコーディングセッション、スキャンしたページやスクリーンショットを含む複数ドキュメントの分析、長く続くエージェントワークフローに向いています。クロスリージョン推論を通じて、Amazon Bedrock が利用できるすべての AWS リージョンで利用できます。 Qwen3.6-35B-A3B-NVFP4 と Wan2.1-T2V-1.3B-Diffusers モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA の Qwen3.6-35B-A3B-NVFP4 と Alibaba の Wan2.1-T2V-1.3B-Diffusers が Amazon SageMaker JumpStart で利用可能になりました。Qwen3.6-35B-A3B-NVFP4 は Alibaba の Qwen3.6-35B-A3B を NVIDIA が量子化したモデルで、総パラメータ 35B のうちトークンあたり 3B（256 のエキスパートのうち 8 つ）のみを活性化する Mixture-of-Experts 構成です。262K トークンのコンテキストウィンドウは YaRN スケーリングで約 1M まで拡張でき、NVIDIA の ModelOpt フレームワークで NVFP4 に量子化することで、会話ターンをまたいだ thinking の保持、マルチトークン予測、複数ステップのエージェントパイプライン向けのツール呼び出しを、メモリ使用量を抑えながら利用できます。Wan2.1-T2V-1.3B-Diffusers は 1.3B パラメータのテキストから動画への生成モデルで、8.19 GB の VRAM で動作し、RTX 4090 で 5 秒の 480p 動画を約 4 分で生成できます。いずれも SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。 Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 モデルが Amazon SageMaker JumpStart で利用可能に Mistral AI の Ministral 3 ファミリーから、Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 が Amazon SageMaker JumpStart で利用可能になりました。いずれもエッジ展開やリソースの限られた環境向けに設計された、ビジョン対応のコンパクトな言語モデルです。3B モデルは 3.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 では 8GB の VRAM に収まりながら 256K トークンのコンテキストウィンドウに対応し、英語、フランス語、スペイン語、ドイツ語、中国語、日本語、韓国語、アラビア語を含む数十言語での指示追従、システムプロンプトへの高い遵守性、構造化 JSON 出力を伴うネイティブな関数呼び出しを Apache 2.0 ライセンスで提供します。8B モデルは 8.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 なら 12GB の VRAM に収まり、より大きな Mistral Small 3.2 24B に匹敵する能力を備えます。SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。 Gemma-4-31B-it-assistant と Gemma-4-31B-IT-NVFP4 モデルが Amazon SageMaker JumpStart で利用可能に Google DeepMind の Gemma-4-31B-it-assistant と NVIDIA の Gemma-4-31B-IT-NVFP4 が Amazon SageMaker JumpStart で利用可能になりました。Gemma 4 のフラッグシップである 31B の dense モデルを、フル精度版と量子化版の両方で利用できます。Gemma-4-31B-it-assistant はアシスタント向けにチューニングされたモデルで、テキストと画像（フレーム列としての動画を含む）を入力としてテキストを出力し、256K トークンのコンテキストウィンドウと 140 以上の言語に対応します。 granite-speech-4.1-2b、kanana-2-30b-a3b-instruct、OpenFold3 モデルが Amazon SageMaker JumpStart で利用可能に IBM の granite-speech-4.1-2b、Kakao の kanana-2-30b-a3b-instruct、OpenFold Consortium の OpenFold3 の 3 モデルが Amazon SageMaker JumpStart で利用可能になりました。granite-speech-4.1-2b は英語、フランス語、ドイツ語、スペイン語、ポルトガル語、日本語を対象とした多言語の自動音声認識（ASR）と双方向の音声翻訳（AST）向けに構築された 2B パラメータのモデルで、単語誤り率 5.33%、リアルタイムファクター約 231 の性能を Apache 2.0 ライセンスで提供します。kanana-2-30b-a3b-instruct は Kakao が開発した韓国語・英語バイリンガルの指示追従とエージェント型 AI ワークフロー向けモデルで、Multi-head Latent Attention（MLA）と Mixture-of-Experts（MoE）を採用し、30B の総パラメータのうちフォワードパスごとに 3B のみを活性化、YaRN スケーリングで最大 128K トークンに対応します。OpenFold3 は OpenFold Consortium とコロンビア大学の AlQuraishi Lab が開発した拡散ベースのモデルで、タンパク質、DNA、RNA、小分子リガンドを含む生体分子複合体の全原子構造予測を行い、コンピュータ支援創薬などの研究に活用できます。 Amazon SageMaker AI がトレーニングジョブと処理ジョブのインスタンス優先リストに対応 Amazon SageMaker AI のトレーニングジョブと処理ジョブで、インスタンスの優先リストを指定できるようになりました。これまではジョブ投入時に 1 つのインスタンスタイプしか指定できず、需要の高い GPU ではそのインスタンスが確保されるまで待つか、複雑なリトライロジックを組むか、異なるインスタンスタイプで複数のジョブを同時に投入して対処する必要がありました。今回のアップデートでは、たとえば ml.g6.48xlarge を 2 台、または ml.g5.48xlarge を 4 台といった優先順位付きのリストを渡すと、SageMaker がリストを順に確認し、容量が確保できた最初の構成でジョブを起動します。同じジョブ投入の中で、オンデマンドと予約済みの SageMaker Flexible Training Plans のどちらから容量を調達するかも設定できます。既存のトレーニング・処理ジョブの API の範囲で使え、SageMaker が利用できるすべての AWS リージョンで CLI、API、SDK、コンソール UI から利用できます。 Amazon Q Console で CloudTrail イベントを自然言語で分析 AWS CloudTrail が Amazon Q Console と統合され、AWS アカウントのアクティビティを自然言語で調査できるようになりました。クエリを書いたりログファイルを手作業で解析したりせずに、CloudTrail のトレイルが適切に設定されているか、ロギングのカバレッジに抜けがないか、どのデータイベントソースを記録しているかといった設定の確認から、特定の IAM ロールに誰がアクセスしたか、VPC 設定にどんな変更が加えられたか、過去 1 週間に不正なアクセス試行がなかったかといったセキュリティ調査、特定のリソースを作成・削除したのは誰か、どの API 呼び出しがエラーを発生させているか、なぜ請求が急増したのかといった運用上のトラブルシューティングまで質問できます。Amazon Q Console がサポートされているすべての AWS 商用リージョンで利用できます。 Amazon Quick が個別シートの生成と画像からの分析作成に対応 Amazon Quick の Generate Analysis が拡張され、ダッシュボードをより速く作るための 2 つの方法が追加されました。Generate Sheet では、既存の分析の中に追加したいシートを自然言語で説明すると、データに合わせて選ばれたビジュアル、フィルターコントロール、前年比や前月比といった計算フィールドを含むシートが追加され、ビジュアルを 1 つずつ手作業で組まなくても分析を拡張できます。画像からの分析生成では、他の BI ツールのダッシュボードを含む既存ダッシュボードの画像をプロンプトに添付すると、Amazon Quick がサポートする範囲で編集可能な分析として再作成します。ローンチ時点では Enterprise サブスクリプション / Author Pro ユーザーが利用でき、組織がアクセスを制限していない場合は Author も Amazon Quick Enterprise の一部として 2026 年 12 月までプロモーションアクセスで利用できます。Amazon Quick が利用できるすべての AWS リージョンで一般提供されています。 Kiro IDE 1.1 : Agent Artifacts とネイティブ ARM64 ビルド Kiro IDE 1.1 では、エージェントの出力を後から見返せる成果物として扱う Agent Artifacts が加わりました。ドキュメント、図、コード、画像などのエージェント出力をチャットの履歴に埋もれさせず永続的なアーティファクトとして残し、会話からコンパクトなプレビューを開く、Agent Focus でチャットの横に全体を表示してレビューする、Agent Focus のコンテキストパネルから後で戻る、といった使い方ができます。あわせて Windows と Linux 向けのネイティブ ARM64 ビルドが提供され、x64 エミュレーションに頼らずダウンロードページから各プラットフォーム用の ARM64 版を選べます。エディタの基盤は Code OSS 1.131 に更新され、コンパクションされた会話が適切なコンテキストを保持するようになったほか、MCP の失敗が分かりやすくなり、Hooks の信頼性が向上し、エンタープライズプロファイルが選択したリージョンへリクエストをルーティングするようになりました。 Kiro Model : GPT-5.6 Sol、Terra、Luna が 1M コンテキストウィンドウにアップグレード 2026 年 9 月 14 日付の Kiro のモデル changelog です。Kiro IDE、CLI、Web で GPT-5.6 Sol、Terra、Luna のコンテキストウィンドウが 272K から 1M トークンに拡張され、あわせて GPT-5.6 ファミリーのクレジット倍率が更新されました。詳細は上記のブログ記事「 Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応 」をご参照ください。 Kiro CLI 2.22 : フルスクリーンチャットとセッション一覧の効率化 Kiro CLI 2.22 では、インタラクティブな TUI セッションと Lite セッションでフルスクリーンチャットが使えるようになりました。 /fullscreen と入力すると、現在の会話がシェルの履歴とは独立したスクロール可能な専用のターミナル画面に移り、もう一度 /fullscreen と入力するとインライン表示に戻ります。V2 と V3 のどちらでも利用でき、マウスやタッチパッド、キーボードでスクロールし、クリックとドラッグで選択したテキストをコピーできます。今後の TUI セッションを常にフルスクリーンで始めたい場合は /settings の Display で Start fullscreen をオンにします。V3 のセッションダッシュボードも整理され、 /sessions では検索・フィルター・ソート・グループ化のコントロールがセッション一覧から分離され、最終利用順のフラットな一覧として開き、最終利用・セッション名・メッセージ数でのソートと選択内容の記憶に対応し、Tab キーでコントロールと結果の間を移動できます。あわせて、長時間にわたる作業の信頼性も改善されています。 Kiro Model : Claude Fable 5.1 のプレビューが Kiro Enterprise 向けに展開開始 Kiro Enterprise の組織向けに、Claude Fable 5.1 のプレビューが Kiro の各クライアントで段階的に展開され始めました。1M のコンテキストウィンドウと 6 倍のクレジット倍率で提供され、推論は米国東部（バージニア北部）（us-east-1）のみで実行されます。有効化の手順やデータ保持の扱いなど詳細は上記のブログ記事「 Claude Fable 5.1 が Kiro で利用可能になりました 」をご参照ください。 最後に生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

オランダに住んでいる私は、電車で過ごす時間がかなり多く、たいていその時間を使って、ビルダーコミュニティが発信している内容をチェックしています。これまでは、そのためにノートパソコンを開いたり、スマートフォンでブラウザタブを操作したりする必要がありました。2026 年 9 月 21 日週、遅れている電車を待っている間に、AWS Builder Center のモバイルアプリでトレンド記事をスクロールしたり、ワークショップを確認したりしていました。そのおかげで、空いた 20 分間をとても有効に活用できました。そこで今週は、まず Builder Center モバイルアプリをご紹介できることをうれしく思います。 AWS Builder Center が iOS と Android のモバイルアプリとして利用できるようになり 、デスクトップやウェブ以外にもエクスペリエンスが拡張されました。AWS Builder ID を使用すると、サインインした状態を複数のセッションで維持しながら、トレンド記事の閲覧、600 以上の AWS Skill Builder コースへのアクセス、無料のサンドボックス環境を使ったハンズオンワークショップの管理を、モバイルデバイスから行えます。AWS Heroes、Community Builders、User Group Leaders をフォローしたり、外出先から Builder Loft のイベントカレンダーを確認したり、購読しているトピックやコミュニティのプッシュ通知を受け取ったりすることもできます。また、このアプリは Wishlist 機能にも対応しており、製品に関するフィードバックを AWS チームへ直接送信できます。Apple App Store および Google Play Store で世界中から利用できます。 Builder Center には今週、さらに 2 つの機能が追加されました。 Polls を使うと、ホームフィードからコミュニティに質問できます。質問を入力し、2～5 個の回答候補を追加して、期限を設定すると、ユーザーが投票できます。結果は随時更新され、コメント欄で議論することもできます。投票は匿名で、作成者には集計された数とパーセンテージのみが表示されます。一方、 Zero to Shipped ハッカソンは、9 月 18 日から 10 月 2 日まで開催されています。コーディングエージェントを AWS に接続し、実際に動作するアプリケーションを構築して AWS 上で公開すると、総額 28,000 ドルの賞金プールの一部を獲得できるチャンスがあります。受賞する 5 つのプロジェクトには、それぞれ 5,000 ドル分の AWS クレジットと AWS Builder のグッズセットが贈られます。 9 月 14 日週のローンチ 9 月 21 日週は、このほかにも次のような発表がありました。 Amazon Connect Talent が一般提供を開始しました 。Amazon Connect Talent は、大規模な採用活動を行う人材獲得チーム向けの、AI を活用した採用ソリューションです。Amazon が長年培ってきた採用ノウハウを基盤としており、AI エージェントを使って構造化された音声面接を実施し、エビデンスに基づく評価を行い、候補者を一貫した基準でスコアリングします。これにより、採用担当者は最終判断に集中できます。候補者は、どのデバイスからでも 24 時間 365 日面接を受けることができ、採用担当者はスコア、文字起こし、詳細な評価結果を翌朝確認できます。AI による評価中は、候補者のすべてのデータが匿名化されます。また、各コンピテンシーは評価基準に基づいて採点され、すべてのスコアは面接中の具体的な根拠と紐付けられます。さらに、採用担当者はすべての採用について最終的な意思決定権を維持します。一般提供版には、コンピテンシーに基づく評価、適応型の質問を行う AI 主導の音声面接、ブランドに合わせてカスタマイズ可能なモバイルファーストの候補者ポータル、管理者向けオンボーディングツールが含まれています。 Amazon Corretto 27 が一般提供を開始しました 。Amazon Corretto 27 は、無償かつマルチプラットフォーム対応の OpenJDK ディストリビューションの Feature Release 版で、Linux、Windows、macOS 上でダウンロードして利用できます。サポートは 2027 年 4 月まで提供されます。主な機能として、すべての環境で G1 がデフォルトのガベージコレクターとして採用されたこと（JEP 523）、TLS 1.3 向けの耐量子ハイブリッド鍵交換（JEP 527）、より小さいメモリフットプリントを実現するコンパクトなオブジェクトヘッダー（JEP 534）、さらに Java Flight Recorder の記録データが JVM 外に出る前に機密情報を削除する、JFR のプロセス内データ編集機能（JEP 536）などがあります。また、強化されたパターンマッチング、構造化並行処理、遅延定数のプレビューも継続されており、Vector API のインキュベーター版も含まれています。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供を開始しました。Kimi K3 は、コーディングおよびナレッジワーク向けに Amazon Bedrock で利用できるようになりました。 。Moonshot AI によると、Kimi K3 は同社で最も高性能なモデルであり、2.8 兆パラメータ規模に到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模なリポジトリを対象とする長時間のコーディングセッション、複数ドキュメントの分析、拡張エージェント型ワークフローに適しています。Moonshot AI は、Kimi K2 と比較してスケーリング効率が約 2.5 倍向上したとしています。Kimi K3 は、Amazon Bedrock 上のオープンウェイトモデルとして初めて明示的なプロンプトキャッシュをサポートしており、コンテキストを複数のモデル呼び出しで再利用する際のレイテンシーと入力コストの削減に役立ちます。 AWS は利用開始時のエクスペリエンスを刷新しました 。新しいプロジェクトを開始するビルダー向けに、よりシンプルな新しい体験を発表しました。最初に設定作業をすべて完了するのではなく、適切なデフォルト設定ですぐに開始できます。Google、GitHub、Apple などの既存の ID プロバイダーを使用してサインアップでき、多くの新規ユーザーではクレジットカードも不要です。また、AWS Free Tier の一環として 100 ドル分の無料クレジットが提供されます。AWS は作業を「プロジェクト」単位で整理します。プロジェクトには AWS アカウントと共有設定が含まれ、セキュリティ管理も AWS 側で適用されます。チームメンバーを招待できます。IAM ユーザーを設定する必要はありません。月間利用上限額は 20 ドルから設定でき、後から高度な AWS 機能を追加費用なし、かつ移行作業なしで有効化できます。このエクスペリエンスは、徐々に新しいお客様にも展開されています。 新しい低コストで耐久性に優れた Amazon EC2 T8i インスタンスが一般提供を開始しました 。Amazon EC2 T8i インスタンスは、Intel Xeon Scalable プロセッサ（Granite Rapids）を搭載しており、EC2 インスタンスの中でも特に低コストな選択肢の1つです。前世代の T3 インスタンスと比較して、最大 30 %優れたコストパフォーマンスを提供します。マイクロサービス、低トラフィックの Web サイト、開発・テスト環境、小規模なデータベースなど、CPU 使用率が低～中程度のワークロード向けに設計されています。T8i インスタンスは、T3 と比較してコンピューティング性能が最大 70 %向上し、ネットワーク帯域幅が最大 1.25 倍、Amazon EBS 帯域幅が最大 2.4 倍向上しています。また、同じ CPU クレジットシステムを使用しているため、T3 からのアップグレードも容易です。 AWS Elastic Beanstalk に Cluster Mode が導入されました 。AWS Elastic Beanstalk Cluster Mode は、Amazon EKS を基盤とする共有インフラストラクチャ上で複数のアプリケーションを運用するチーム向けの、新しいフルマネージドオプションです。各アプリケーションを個別に運用するのではなく、単一の運用基盤上で複数のアプリケーションを実行できます。これにより、アプリケーションの数が増えるにつれて、アプリケーションあたりのコストを削減できます。Java、.NET、Python、Node.js、PHP、Ruby、Go のソースコードをアップロードでき、Elastic Beanstalk がコンテナ化を自動的に処理します。また、必要に応じて Cloud Native Buildpacks も利用できます。Cluster Mode には、自動ロールバックを備えた本番環境向けのデプロイ戦略、イベント駆動型のオートスケーリング、AWS Secrets Manager との統合、ネイティブな OpenTelemetry オブザーバビリティ、AI を活用したトラブルシューティングが含まれています。Standard Mode と Cluster Mode の環境は、同じアプリケーション内で並行して実行できるため、チームは環境を1つずつ段階的に移行できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS European Sovereign Cloud での構築 — 2つの新しい記事では、AWS European Sovereign Cloud 上での構築について紹介しています。これは、独自のコントロールプレーン、IAM、請求、コンソール、サービスエンドポイントを備え、独立したパーティションとして運用される欧州向けの独立したクラウドです。最初のリージョンはドイツ・ブランデンブルクに開設されます。最初の投稿では、アカウント構造とガバナンス、コードとしてのインフラストラクチャとしてのアイデンティティ、集中ロギング、データ保護、AWSパーティション全体で機能するパーティション対応ARNの構築など、 安全なランディングゾーンの設計について説明します 。2つ目は、AWS European Sovereign CloudのAmazon Bedrock次世代推論エンジンでGemma 4オープンウェイトモデルが一般公開されたことを発表しました 。データ保持やオペレーターアクセスゼロのモデルでは、推論は完全にeusc-de-east-1の範囲内にとどまります。 新しい AgentCore ランタイム：伸縮性に優れ、最適化され、一貫して高速な起動 — エージェントを実行するためのマネージドコンピューティングレイヤーである Amazon Bedrock AgentCore ランタイムの新バージョンを発表しました。新しいランタイムでは、セッション中のピーク時のメモリ量を保持し続けるのではなく、セッションがメモリを解放するとその分を回収します。そのため、料金はセッション全体を通じた実際の使用量に基づいて計算されます。また、コンテナイメージのサイズや同時実行数に関係なく、一貫したコールドスタート時間を実現します。これは、環境を一度準備してスナップショットを取得し、新しいインスタンスごとにそのスナップショットを復元することで実現しています。空のエコーエージェントを使ったテストでは、新しいランタイムは 200 MB のイメージから最大 2 GB までの約 2 秒で P75 コールドスタートを実現しました。これに対し、元のランタイムでは約 5.4 秒から 30 秒かかりました。 更新された AWS Well-Architected ストリーミングメディアレンズの紹介 — 動画ストリーミングワークロードのアーキテクチャのベストプラクティスを提供する改訂版ストリーミングメディアレンズを公開しました 。今回の改訂では、2021 年の初版から対象範囲が拡大され、5つのストリーミングシナリオをカバーしています。これには、Amazon IVS を使ったインタラクティブライブストリーミング、最大 25,000 人の同時視聴者に対応するリアルタイムストリーミング、低遅延ライブストリーミング、広告対応コンテンツの収益化、さらに強化されたビデオオンデマンドおよびライブストリーミングのガイダンスが含まれます。また、カーボンフットプリントの削減に重点を置いた新しいサステナビリティのベストプラクティス、拡張されたオブザーバビリティおよびインシデント対応フレームワーク、多層 DRM とフォレンジックウォーターマーキングを活用した高度なコンテンツ保護も追加されています。レンズホワイトペーパーとカスタムレンズがご利用いただけるようになりました。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re: Invent — AWS re: Invent が 11 月 30 日から 12 月 4 日までラスベガスに戻ります。2, 200 以上のセッション時間、ロケーション、講演者がライブ配信されます。AWS re: Invent の指定席は 10 月 6 日にオープンします。 今すぐ登録して 、指定席が開いたら、チョークトーク、ワークショップ、ビルダーズセッションに参加する準備をしてください。 AWS Summits – AWS Summits は、クラウドと AI をカバーする無料の実地イベントです。re: Inventが間近に迫った今、今年のサミットは終わりに近づいています。 最後のサミットはドバイ （9月30日）にドバイワールドトレードセンターで開催され、60以上のセッション、AWSビレッジ、ハンズオンワークショップが行われます。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 レバノン （9月26日）、 マレーシア、クアラルンプール （9月26日）、 フィリピンのセブ（9月26日）、フィリピンのダバオ （9月26日）、 英国のコムサム・マンチェスター（10月1日）、 イタリア、ローマ （10月2日）などがあります。 夏は正式に終わり、9 月を迎えましたが、私のいる場所では、まだ天候が季節の移り変わりに追いついていないようです。日中は今でも例年になく暖かく、本格的な秋が訪れる前の、最後の穏やかな午後なのではないかと思っています。この陽気が続いているうちに、できるだけ満喫しようと思います。9 月 28 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。