2026 年 6 月 15 日週、 AWS Summit New York City では、何千人ものお客様、パートナー、ビルダーが集まり、クラウドと AI のイノベーションの最新情報を紹介する無料の1日イベントを開催しました。Jane Goodall 博士とAWS のエージェンティック AI 担当副社長である Swami Sivasubramanianは、 基調講演 で一連のAIローンチを発表しました。これらはすべて、「時間の経過とともに価値を複合化するエージェント」という 1 つのテーマに基づいて構築されています。 作業用エージェント – Amazon Quickの新機能 により、自律型エージェントを起動し、よりスマートなアクティビティフィードにアクセスできます。これにより、デスクトップアプリで直接複数ステップのエージェントを作成して実行できるようになり、メール、Slack、カレンダー、タスクをパーソナライズされたルールで優先順位付けされた単一のビューに統合できます。 保護のためのエージェント – AWS Continuum は、 コードの脆弱性ライフサイクル全体 にわたってマシンスピードで推論し、検証し、行動する新しい AI ネイティブセキュリティサービスで、事後対応型から事前対応型のセキュリティに移行できます。AWS セキュリティエージェント（現在は AWS Continuum の一部）には、脅威モデリング、主要な Git プラットフォームでの修復を伴うプルリクエストコードスキャン、Kiro パワー、Claude Code プラグイン、MCP による IDE 統合などの 新機能 が追加されています。 ビルド用エージェント – Kiro、AWS DevOps エージェント、AWS Transform を使用すると、コードの記述、配布、モダナイズを 1 つの連続ループで行うことができます。Kiro は ネイティブ iOS アプリケーション を導入し、AWS DevOps エージェントは リリース管理機能 を追加して本番前にコードの変更を評価し、 AWS Transform の継続的なモダナイゼーション は技術的な負債を自律的に削減します。 お客様が作成するエージェント – Amazon Bedrock AgentCore を使用すると、エージェントのアイデアから本番稼働まで数分で完了できます。これには、インフラストラクチャとオーケストレーションのための GA ハーネス 、 ウェブ検索 、 マネージドナレッジベース 、 Guardrails とのポリシー統合 、組織のデータ関係をマッピングするための新しい AWS コンテキストサービス が含まれています。 詳細については、 トップアナウンスのブログ投稿 と Amazon ニュースの投稿 にあるサミットのまとめをご覧ください。 2026 年 6 月 15 日週のリリース 6 月 15 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 ベトナムのハノイにある AWS ローカルゾーン — この新しいローカルゾーンは、Amazon S3 と Amazon EBS ローカルスナップショットをサポートするアジア太平洋地域初の AWS ローカルゾーンの1つで、データをローカルに保存してバックアップすることで、お客様がデータレジデンシーの要件を満たすことができます。まず、AWS グローバルビューの [リージョンとゾーン] タブから、または ModifyAvailabilityZoneGroup API を使用して、ハノイローカルゾーン ( ap-southeast-1-han-1a ) を有効にします。 AWS Blocks は、アプリケーション開発者向けのオープンソース TypeScript フレームワークです (プレビュー) — AWS Blocks は Postgres、認証、リアルタイムメッセージングを備えた完全に機能するローカル環境を実行します。AWS アカウントは必要ありません。デプロイする準備ができたら、同じアプリケーションコードが本番環境の AWS サービスでも変更なしで実行され、いつでも AWS CDK にアクセスして直接リソースを設定できます。 Amazon BedrockのxAiのGrok 4.3 — Amazon BedrockではGrok 4.3モデルを使用できます。これにより、推論、エージェント、およびエンタープライズワークフローにわたる生成 AI アプリケーションを構築する際に、さらに多くの選択肢が得られます。Grok 4.3 は、価格パフォーマンスを重視して設計された Bedrock の新しい推論エンジン上で動作し、ツール呼び出し、構造化出力、応答ストリーミングをサポートしています。 Amazon S3 アノテーション: 豊富でクエリ可能なコンテキストをオブジェクトに直接アタッチ – Amazon S3 ではアノテーションを使用して、最大 1 GB のリッチで変更可能かつクエリ可能なコンテキストをオブジェクトに直接アタッチできるようになりました。これは、個別のメタデータシステムを維持することなく大規模なデータを発見、理解、処理する必要のある AI エージェントや自律型ワークフロー向けに構築されています。 Amazon ECS がより高速なサービス自動スケーリングを発表 — Amazon ECS サービスの自動スケーリングは、高解像度 (20 秒) のメトリックスとメトリックス公開の最適化をサポートすることで、負荷の変化をより迅速に検出して対応できるようになりました。AWS のベンチマーキングテストでは、スケールアウトがトリガーされるまでの時間が 363 秒から 86 秒に短縮され (76% の高速化)、新しいタスクのスケールとプロビジョニングにかかる合計時間が 386 秒から 109 秒に短縮されました (72% の高速化) Amazon EC2 G7 インスタンスは NVIDIA RTX PRO 4500 ブラックウェルサーバーエディション GPU で高速化されています — AWS は、NVIDIA RTX PRO 4500 ブラックウェルサーバーエディション GPU をサポートした最初の大手クラウドプロバイダーです。G7 インスタンスは、これらの GPU と第 6 世代のカスタムインテル Xeon Scalable プロセッサを組み合わせることで高速化されており、G6 インスタンスと比較して、最大 4.6 倍の AI 推論パフォーマンスと最大 2.1 倍のグラフィックスパフォーマンスを実現します。 Strands Agents に新機能が導入されました — Strands はプロダクションエージェントを構築するためのオープンソースツールキットです。Strands Shell による新しい分離された実行環境である Harness SDK でより優れたコンテキスト管理が可能になり、Strands Evals ではカオステストとレッドチーミングを使用できるようになりました。 AWS マネジメントコンソールのプライベートアクセス — インターネットに接続していなくても VPC から AWS コンソールにアクセスできるため、企業は隔離された環境でも厳格なネットワークセキュリティ管理を維持しながら、コンソールから AWS インフラストラクチャを管理できます。 AWS Marketplace Storefront が一般公開されました – AWS パートナーは、独自のブランド化されたソリューションとサービスのカタログを作成し、自社のウェブサイトやアプリケーションに数時間でデプロイできます。チャネルパートナーと独立系ソフトウェアベンダーは、クラウドマーケットプレイスビジネスの管理方法を簡素化し、顧客が AWS Marketplace からソリューションを見つけて購入しやすくできるようになりました。 Amazon Route 53 Resolver DNS ファイアウォールでのパロアルトネットワークス (PANW) 高度な DNS セキュリティ (プレビュー) – 組み込みの AWS Marketplace ウィジェットを使用して DNS ファイアウォールコンソールから PANW にサブスクライブすることで、個別のファイアウォールをデプロイしたり VPC 設定を変更したりすることなく、パロアルトネットワークスの DNS 脅威保護を Route 53 DNS ファイアウォールルールに直接適用できるようになりました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 価格引き下げ AWS は引き続き、お客様のためにパフォーマンスを向上し、価格を下げる方法を模索しています。6 月 15 日週、このような取り組みにいくつか気づいたので、それらを共有したいと思います。 Amazon S3 Vectors は、大規模なベクターインデックスのクエリ料金を最大 80% 削減します — この削減により、大規模な AI、RAG、およびセマンティック検索ワークロードにわたって類似検索を実行するお客様のコストが削減されます。新しい価格設定は自動的に適用され、アプリケーションを変更する必要はありません。 Amazon GameLift サーバーは無料のネットワーク帯域幅を導入します — Amazon GameLift Servers は、オンデマンドやスポットを含め、第 6 世代以降のすべてのインスタンスタイプについて、コミットメントなしで AWS 内外のネットワーク帯域幅を追加料金なしで提供します。Amazon GameLift Servers のインスタンス時間分のみのお支払いとなり、ネットワーク帯域幅はすべて無料になりました。 AWS Marketplace では、プロフェッショナルサービスの出品料が 2.5% から 0.5% に引き下げられました — この引き下げにより、コンサルティングパートナー、システムインテグレーター、マネージドサービスプロバイダー、独立系ソフトウェアベンダーが AWS Marketplace を通じてサービスを取引する際の費用対効果が高まり、調達や請求のメリットも維持されます。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 6 月 22 日週のニュースは以上です。6 月 29 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

6 月 25 日 (木)・26 日 (金) の 2 日間、千葉・幕張メッセにて開催される AWS Summit Japan 2026 の AWS for Games エリアにおいて、 Immersive Experience Platform のブースが出展されます。 本ブログではこちらの展示内容をご紹介します。 AWS Summit Japan 2026 登録はこちら ブース A012：Immersive Experience Platform アプリケーション × バックエンド × インフラ — イマーシブ空間に必要なすべてを、ひとつのプラットフォームで。 Immersive Experience Platform は、3D 空間の開発ツールから API、インフラ基盤までをフルスタックで提供するパートナーソリューションです。テンプレートやプラグインを活用することで、専門知識がなくても高品質なイマーシブ体験を短期間・低コストで実現できます。 こんな方におすすめ 来場者像 ブースで得られること 3D 空間エンジニア・ゲーム開発者・デザイナー   テンプレートを活用して簡単に 3D 空間を構築する方法 Web エンジニア・プロダクト開発者   既存 Web サイトに 3D コンテンツを組み込む方法 インフラエンジニア・SRE・CTO   自動化されたセキュアな AWS 基盤を自社環境に構築する方法 展示内容 Immersive Experience Platformは、アプリケーション、バックエンド、インフラストラクチャーの3つのレイヤーでビジネスの課題解決を支援するプラットフォームです。 1. アプリケーション – 特別な技術がなくても簡単に 3D 空間を構築できる テンプレートを活用しながら、簡単に3D空間制作が始められます。AIチャットを通して最適なテンプレートの検索や、クラウドで管理された3Dアセットの活用ができ、構築した空間はAWS上にデプロイし、URLを発行してすぐに共有することが可能です。 2. バックエンド – 便利な機能・コンテンツを既存サイトへ組み込むことができる 様々な機能を有効化し、既存 Web サイトに 3D コンテンツを組み込むことができます。3D ビューワー、AI チャットボットなどの機能を、専用の画面からカスタマイズすることで、簡単に導入することが可能です。 3. インフラストラクチャー – 自動化されたセキュアな AWS 基盤を自社環境へ構築できる 自動化されたセキュアな AWS 基盤を自社環境に簡単に立ち上げることが可能です。オンラインマルチプレイやチャット、AI支援分析ダッシュボード、統合開発環境といった機能を、用途に合わせて選択しながら導入可能です。 利用している AWS サービス・ソリューション 本プラットフォームは AWS プロフェッショナルサービス が開発を支援し、以下のような AWS サービス・ソリューションが利用されています。 Amazon CloudFront + Amazon S3 — Web コンテンツ配信 Amazon GameLift Streams — クラウドゲーミング（ゲームのストリーム配信） Amazon Elastic Container Service (ECS) — オンラインマルチプレイサーバー Amazon API Gateway + AWS Lambda — バックエンド API Amazon Cognito — ユーザー認証・認可 Amazon Bedrock  — AI チャットボット Amazon QuickSight — AI 支援ダッシュボード AWS CodePipeline + AWS CodeBuild — CI/CDパイプライン Spatial Data Management on AWS — 3D アセット管理基盤ソリューション ブースで得られること テンプレート × プラグインによる開発期間短縮のアプローチ — 専門の 3D エンジニアがいなくても簡単にイマーシブ体験を構築する方法 既存サービスにイマーシブ体験を組み込む設計パターン — 便利なイマーシブ機能・コンテンツを既存 Web サイトに組み込む方法 AWS 上で 3D アプリ配信基盤を運用するアーキテクチャ実例 — CI/CD で自動化されたセキュアな 3D 空間向け AWS 基盤の構築方法 ブース情報 ブース ID 　A012 エリア   AWS Industries Zone（AWS Expo エリア内） 日程   2026 年 6 月 25 日 (木)・26 日 (金) 会場   幕張メッセ まとめ Immersive Experience Platform ブース（A012）では、「アプリケーション」「バックエンド」「インフラ」の 3 レイヤーを横断して、イマーシブ体験構築の全体像をデモとともにご紹介します。業界エキスパートとの 1 対 1 のご相談も可能です。 皆さまのご来場を心よりお待ちしております。 AWS Summit Japan 2026 への登録はこちら

本記事では、AWS サンプルアセットである AI エージェント SMART（Store Manager Agent for Retail Tech） についてのご紹介と、それを活用した株式会社ユナイテッドアローズ（以下、ユナイテッドアローズ）の取り組みについてご紹介します。小売業にとって、店舗の声をどう本部に届けるかは永遠のテーマです。売上数字の裏には、現場スタッフだけが感じている気づきが必ずあります。しかし店舗の日報や週報のフォーマットだけでは、その気づきを届けるのは難しいのが実情です。SMART は、店舗の気づきを AI の力で引き出し言語化して、本部に届けることを支援するために誕生しました。 1. 現場の気づきをどう本部に届けるか 店長・店舗スタッフの皆さんは、毎日、たくさんの気づきを生み出されています。「今日は雨だったけれど、来店されたお客様の購買率は高かった」「新しいデザインの商品についてお客様の反応が予想以上にいい」「休憩の回し方を変えたら接客効率が上がった気がする」。こうした気づきは、売上や客数といった定量データだけでは見えない、店舗運営にとってかけがえのない手がかりです。 一方で、一日の売場で生まれる数多くの気づきを、閉店後の限られた時間のなかで日報の自由記述欄に記録するのは、仕組みとして難しいところがあります。接客、在庫確認、レジ締め、翌日準備をこなしたあとに、うまく言葉にしづらい感覚的な気づきまで文章化するのは、誰にとっても相応の負担がかかる作業です。現場で毎日生まれている観察の豊かさに対して、日報フォーマットが持つ受け皿で拾うには、自ずと限界があります。本部側としても、定型フォーマットの数字だけでは現場の肌感が読み取れず、良い兆候があっても背景までは見通しにくい状況があります。 このような課題は小売業界全体に共通しています。米国・カナダの小売業界のリーダー 227 人を対象にした Zipline 社の調査「Misaligned」2026 によれば、店舗施策が正しく実行される確率は 36% にとどまり、その主な原因としては 人員不足（51%） と 時間不足（32%） が挙げられています。店舗リーダーの 70% は「本部にフィードバックを伝える明確な手段がない」と答え、43% の小売リーダーが「実行不備による売上・収益の損失」を経験していると報告しています。 海外の調査ではありますが、日本の小売業の現場でも、似たような課題を感じておられる企業は多いのではないでしょうか。 業界も同じ課題に向き合っている — Tapestry の事例 こうした課題は、グローバルの大手企業も向き合ってきたテーマです。Coach や Kate Spade などのブランドを展開する Tapestry 社（ 2024 年時点で、世界 70 カ国以上で約 1,400 店舗を運営）は、店舗の第一線で生まれる気づきを本部に届ける仕組みの必要性を認識し、AWS 上で Tell Rexy というフィードバック収集アプリを開発しました。 Amazon Bedrock と Amazon Transcribe を組み合わせて音声入力に対応させ、1 年で 約 3 万件 の気づきを集め、マーチャンダイジングの改善に活かしています（ AWS Case Study: Tapestry ）。 SMART は、ユナイテッドアローズの店舗運営に関わる事業部門の声を伺いながら、AWS のプロトタイピングエンジニアがサンプルを開発し、AWS Samples として公開しました。 2. SMART のアプローチ — 本部の「問い」× AI の「深掘り」 なぜ “自由記入欄” では不十分なのか 忙しい閉店後の店舗スタッフに、日報フォーマットの自由記入欄や、普段コミュニケーションとして使っているチャットアプリケーション等に今日の気づきを書くのは難しいはずです。仮に仕組みとして「今日はどうでしたか」と問いかける形でも、返す答えは 「普通でした」「特に問題なし」 で終わるのではないでしょうか。一日の疲れのなか、自分の気づきを一から構造化して語るのは、誰にとっても負担が大きい作業のはずです。 SMART は、この前提を逆転させました。名前の通り、Store Manager Agent for Retail Tech — 店長を助ける AI エージェントです。ポイントは、本部からの “問い” を起点に AI が現場に深掘りする設計にあります。 3 層の設計 SMART は、次の 3 層で成り立っています。 本部の「問い」 — 本部は「今日気になったお客様の反応は？」「新しい商品の売れ行きは？」といった、確実に確認したい内容を定型質問として設定します。これはノーコードで編集可能で、キャンペーンや季節に合わせていつでも差し替えられます。 AI の「深掘り」 — 本部が設定した質問に対するスタッフの回答内容を起点に、AI が “なぜ？” を追いかけます。深掘りの仕方はプロンプトで調整でき、本部の仮説や関心を AI に埋め込むことができます。音声入力にも対応しており、閉店後、片手間でも答えられる設計です。 気づきがデータに — AI との一連の対話は、店舗名・日付・カテゴリといった構造化情報に変換され、売上などの定量データと同じ場所に蓄えられます。翌朝、店長や本部側には「売上データ × 現場の気づき」を掛け合わせたインサイトが届きます。 具体例：雨の日に何が起きたのか たとえば、本部が 「今日のお客様の反応で、気になったことは？」 と問いかけたとします。あるスタッフが「雨だったけど、購買率は高かった」と答える。ここで従来のアンケートなら、この回答は「雨 / 購買率高」とタグ付けされて終わります。SMART の場合、ここから AI が 「どんなお客様が来店されましたか？」 と深掘りします。「目的買いの方が多かった気がする。あ、今週発売した限定商品の T シャツを求めにきた若い男性が多く、それに似合うパンツも一緒によく売れました」という回答が返ってくる。この一連のやりとりから、「雨天 × 目的買い → 客単価が上がる可能性」 というインサイトが生まれます。翌朝、同じ問いへの回答が他店舗からも集まっていれば、本部は「この傾向は自店舗固有か、横展開できる学びか」 を、その日のうちに判断する材料として手にできます。 設計思想 — AI を介して、立場の異なる人どうしをつなぐ SMART が目指しているのは、立場の異なる人や組織を、AI やデータを介してつなぐという使い方です。興味深いのは、会話から生まれた気づきがデータ資産として蓄積される点にあります。元のコミュニケーションの当事者間（店舗と本部）を超えて、別の店舗や部門、別の AI エージェントがその資産を活用することができます。たとえば、商品企画の担当者が「去年の同時期、現場ではどんな気づきがあったか」を過去のデータから振り返る、あるいは別の AI が需要予測をするときに現場の声も参考材料にする、といった 他部門・他業務での再活用にも発展することが可能になります。 店舗の第一線と、本部の意思決定、そのあいだに AI エージェントを置くことで、本部の問いが現場に届き、現場の気づきが本部に還ってくる。さらに、その会話そのものが構造化されたコミュニケーションデータとして蓄積され、時間とともに双方の判断を支える資産になっていきます。 AI 任せでも、現場任せでもないこのバランスが、限られた時間のなかで豊かな気づきを引き出す鍵ではないかという仮説を持っています。AI がコミュニケーションを円滑にし、データを蓄積し、立場の異なる双方の意思決定を支える — SMART が目指しているのは、そうした関係性の支援です。 3. SMART を使うと何が起きるか — 画面と 1 日の流れ 3.1 3 つの画面と 1 日の流れ SMART は店舗スタッフと店長、それぞれの時間軸で主に  3 つの画面が連動して動きます。動画と合わせて利用シーンについて説明します。 閉店時に店舗スタッフが実施 ① 日次アンケート画面 — 定型質問に数分で回答 閉店後、店舗スタッフまたは店長がログインして最初に開く画面です。本部が事前に設定した定型質問（星評価・選択式・自由記述・数値）に、数分で回答します。画面上部には管理者や本部からの連絡事項も表示され、日報入力時に考慮して欲しい事項（新商品やキャンペーン、急な店舗オペレーションの変更など）を掲載することで、それに関連する気づきがあれば入力してもらうことを促すことができます。 ② AI チャット画面 — AI が “なぜ” を深掘りする アンケート回答を提出すると、AI チャット画面に移ります。本部が設定したプロンプトに沿って、AI がスタッフの回答を起点に “なぜ” を深掘りします。「なるほど、コラボ T シャツが売れたんですね。それは確かに珍しいから、お客さんも興味を持ちやすいですよね」といった自然な会話で追加ヒアリングが進みます。マイクアイコンから音声入力にも対応しており、片手間でも答えられます。 図1. 閉店時の店舗スタッフの実施イメージ — ① 日次アンケート（本部が設定した定型質問に数分で回答）→ ② AI チャット（本部が設定したプロンプトに沿って AI が追加ヒアリング） 翌朝に店長が実施 ③ Daily Insights 画面 — AI が売上 × 気づきを統合して分析する 翌朝、店長が確認できる AI からのフィードバック画面です。売上金額・購入件数・購入率（前日比・目標比）といった定量データに、前日の店舗スタッフによる日次アンケート回答と AI 対話から抽出した定性の「気づき」を統合し、AI が客観的分析結果を応答します。「売上達成／阻害要因の分析」「AI の気づき」「今日のアクション提案」という形で、本部の意思決定に直結するインサイトが 1 ページにまとまっています。AI に回答して欲しい内容は、プロンプトでチューニングが可能です。なお、売上などの定量データについては、すでにそのデータを管理する DB や DWH システムが別に存在することが一般的であるため、それらと連携するためのカスタマイズが必要となります。またこれらのデータは日次集計されているケースが多いため、翌朝にフィードバック確認の実施を想定しています。 図2. Daily Insights（AI が売上 × 定性データを統合して生成したフィードバック）を確認 3.2 リクエスト〜レスポンスのシーケンス 1 日の中で SMART が行う処理を、閉店後のアンケート入力と AI 対話、翌朝確認するフィードバックに分けて表現すると次のようになります。 図3. SMART のリクエスト〜レスポンスのシーケンス 閉店後はスタッフとの対話（ hearing エージェント）、翌朝は日報生成（ daily_summary エージェント）の 2 つが別のタイミングで動きます。 4. ユナイテッドアローズでの取り組み 4.1 導入の背景と取り組みの概要 ユナイテッドアローズは、1989 年の設立以来、日本のファッションアパレル業界をリードする小売企業です。同社でも「日報が手入力、週報作成には 2,3 時間要している」「店長の記憶頼りで報告粒度が店舗間で異なる」という、多くの小売業に共通する課題を抱えていました。解決するためのアイデアはあるものの、専任の内製開発体制があるわけではなく、企画からモック作成・PoC までに時間がかかることが、新しい仕組みを試すうえでのハードルになっていました。一方、 Kiro をはじめとした AI の活用を進めてきた中で、「今なら自分たちでも開発できるのではないか」という仮説のもと、AWS Prototyping Program を組み合わせて、プロトタイプの作成と内製開発力の獲得を同時に進めるアプローチを採りました。 取り組みは 2025 年 12 月から 2026 年 3 月にかけて、IT 部門、事業部門・店舗スタッフが連携して実施しました。SMART をベースに Kiro を活用して内製でカスタマイズをして、 4 店舗の協力のもと PoC を実行しました。目指したのは、現場の空気感や気づきを鮮度の高いうちに吸い上げ、構造化・データ化して戦略立案の土台にすることです。そして店舗スタッフが接客に集中できる環境を整えることでした。 4.2 店舗スタッフ・店長の声 PoC 後のアンケートでは、「誰もが直感的に操作できる」「曖昧で感覚的な表現を、具体化する質問で引き出してくれる」「『事実・考察・改善案』に分けて整理してフィードバックしてくれる」といった声が寄せられ、複数の設問で 8 割以上のスタッフが「当てはまる」と回答し、高い評価を得ました。 店長からは、こんな声がありました。「昨日の店舗がどうだったかを、わざわざ人に聞かなくてもすぐに把握できるようになった」。さらに想定していなかった変化として、「AI が『なぜ』を深掘りしてくれることで、スタッフ自身に『考える習慣』や『改善行動を意識する姿勢』が広がってきた」という気づきも語られました。日報の入力支援にとどまらず、現場の思考の質そのものに作用しはじめている点が印象的です。 4.3 本部スタッフの声 本部側にも変化がありました。「現場から直接ヒアリングする時間を減らせた」という業務効率の面に加えて、「店舗スタッフを効率よく配置するためのヒントが得られ、売上向上につながる気づきがあった」という、意思決定に直結する手応えも得られています。これまで数字だけでは見えなかった現場の “なぜ” が、定量データと並んで本部に届くようになったことで、施策の打ち手を考える材料が広がりつつあります。 4.4 加藤 大輔 氏のコメント — 開発視点での副次効果 「当初は、店舗スタッフの『日報業務の効率化』を主目的に始めましたが、実際にやってみて最も価値を感じたのは別のところでした。AI からのフィードバックを受けることで現場が能動的に改善を意識して行動するようになったと聞き、大きな手応えを感じています。また、AWS Prototyping Program という AWS さんからの支援 と Kiro を組み合わせたことで、内製開発の経験が少ない私たちでも、企画段階から事業部門とともに課題と要件の解像度を上げながら取り組みを進めることができました。後工程の手戻りや無駄な投資を抑えながらも、何よりチームメンバーの成長を感じることができたことは、今後の社内 DX を進めるうえで大きな財産になっています。」 — 加藤 大輔（IT ソリューション本部 IT セキュリティ部 副部長） 5. アーキテクチャと技術詳細 5.1 全体像 SMART のアーキテクチャーは、次の 3 点を軸に設計しました。 フルサーバーレス — DB・インスタンスなどサーバーレス構成のため、運用負荷が低く、また使われていない時間帯のコストを低く抑えることができます。 CDK ワンコマンドデプロイ — git clone して cdk deploy --all するだけで、約 20 分で環境一式が立ち上がります。 リージョン — デフォルトリージョンを ap-northeast-1 で指定しており、インスタンス・DB・LLM 実行などのデータを国内リージョンにとどめて利用が可能です（グローバル配信を担う Amazon CloudFront とそれに紐づく AWS WAF は us-east-1 に配置されます）。 図4. SMART の AWS アーキテクチャー 各サービスの役割は次の通りです。 レイヤ サービス 役割 フロントエンド配信 Amazon CloudFront + Amazon S3 + AWS WAF React アプリのグローバル配信、アクセス制御 認証 Amazon Cognito（User Pool） JWT トークンベースのユーザー認証、店舗所属グループ管理 Transcribe 認可 Amazon Cognito（Identity Pool） 認証済みユーザーに Transcribe Streaming の最小権限を払い出し 音声入力 Amazon Transcribe Streaming（ ja-JP ） ブラウザの AudioWorklet から送られた音声をリアルタイム文字起こし API エンドポイント Amazon API Gateway（REGIONAL）+ AWS WAF REST API、Cognito Authorizer で認証、WAF で IP・ドメイン制限 API 実行 AWS Lambda（Python 3.13、FastAPI + Mangum） ビジネスロジック、AgentCore Runtime の呼び出し AI エージェント実行 Amazon Bedrock AgentCore Runtime Strands Agents で書いた 2 種類のエージェントをサーバーレスでホスト 会話履歴の永続化 Amazon Bedrock AgentCore Memory セッション単位の短期記憶、actor 単位の長期記憶 LLM Amazon Bedrock（Claude） エージェントの思考・応答生成、日報マークダウンの生成 データ基盤 Amazon S3 Tables（Apache Iceberg）+ Amazon Athena アンケート・売上・チャット履歴・マスタを単一クエリで結合 ここでは、Agent 実行基盤・Agent 構成の 2 つについて解説します。 5.2 Agent 実行基盤 – Amazon Bedrock AgentCore Agent の開発・運用では、Agent の実行場所、メモリ戦略、ログの運用管理など様々な周辺機能が必要になります。特に、メモリ戦略では短期記憶・長期記憶をどう切り分け、どこまで遡り、何を要約するか。それらを自前で実装することもできますが、ここに手をかけすぎずに Agent のコアロジックの実装にできるだけ時間を割きたいと思われる方が多いと思います。 そこで SMART では、Agent を効率的に開発・運用するためのマネージドサービスである Amazon Bedrock AgentCore から、以下 2 つの機能を利用しています。 Amazon Bedrock AgentCore Runtime: AgentCore Runtime は Agent の実行基盤をすぐに立ち上げることができ、フルマネージドのため細かなインスタンスの運用管理が不要です。以下のように、Agent のコード内に Runtime のエントリポイントを定義することで実装できます。 BedrockAgentCoreApp が HTTP リクエストの受け口になり、 @app.entrypoint で関数を登録するだけで、ローカルでもクラウド（AgentCore Runtime）でも同じコードが動くため、ローカルでの検証やデバッグなど開発が行いやすいです。 # backend/store-agent/agentcore_main.py （一部抜粋） from bedrock_agentcore.runtime import BedrockAgentCoreApp from agent_router import route_agent_request app = BedrockAgentCoreApp() @app.entrypoint def invoke(payload, context): return route_agent_request(payload) if __name__ == "__main__": app.run() Amazon Bedrock AgentCore Memory: AgentCore Memory は、細かな Agent Memory ロジックの実装なしにすぐに立ち上げ、使い始めることができ、 Strands Agents とも簡単に連携できます。 AgentCoreMemorySessionManager を Strands Agents の Agent に渡すだけで、会話履歴の取得・保存が自動で行われます。アプリ側で「前回のセッションの取得」や、「プロンプトへの挿入」といったコードを書く必要がありません。 # backend/store-agent/hearing_agent.py （一部抜粋） from strands import Agent from bedrock_agentcore.memory.integrations.strands.config import AgentCoreMemoryConfig from bedrock_agentcore.memory.integrations.strands.session_manager import ( AgentCoreMemorySessionManager, ) def create_hearing_agent(session_id=None, actor_id=None) -> Agent: bedrock_model = get_bedrock_model() system_prompt = _load_system_prompt("hearing_system_prompt.txt") memory_id = config.HEARING_AGENTCORE_MEMORY_ID memory_config = AgentCoreMemoryConfig( memory_id=memory_id, session_id=session_id, actor_id=actor_id ) session_manager = AgentCoreMemorySessionManager( agentcore_memory_config=memory_config, region_name=config.REGION ) agent = Agent( model=bedrock_model, system_prompt=system_prompt, session_manager=session_manager, tools=[], ) return agent 5.3 Agent 構成 SMART の Agent は、 Strands Agents を使って以下の 2 つの Agent を実装しています。 SMART では、Agent のプロンプトをテキストファイルとして Amazon S3 に配置し、バージョニング管理しています。利用開始後にユーザーからのフィードバックや、業務要件の変化に合わせてプロンプトを修正したい時に、アプリケーションの改修なしにすぐにプロンプトを更新することが可能です。 ① ヒアリングエージェント（ hearing ） 閉店後の店舗スタッフへの追加ヒアリングを担います。事前にスタッフが回答したアンケート結果を Agent に渡し、回答の背景にあるコンテキスト情報を引き出す質問を考えます。質問の量や掘り下げる観点でプロンプトを記述しています（ cdk/prompt/hearing_system_prompt.txt ）。 ② 日次サマリエージェント（ daily_summary ）— ツールでデータを引いてレポート生成 翌朝の Daily Insights を生成するエージェントです。こちらは次の 2 つのツール を持ち、それぞれが Athena にクエリを投げてデータを取得します。 get_previous_day_survey_data — 前日の日次アンケート回答を取得（定性データ） get_store_sales_data — 前日の売上金額・来客数・購入件数・購入率・予算達成率などを取得（定量データ） この 2 つを組み合わせることで、「定量 × 定性」の両輪 で AI からのフィードバックを生成します。 6. 今すぐ試してみよう SMART は、 GitHub で公開しています。デプロイ手順や環境準備は、リポジトリの DEPLOYMENT.md をご覧ください。 自社に合わせるカスタマイズポイント SMART をそのまま使うのではなく、自社の業種・業態に合わせて調整するポイントは主に 3 つです。 質問項目 — 管理画面からノーコードで編集できます。 admin_survey テーブルに保存され、キャンペーンや季節などに応じて差し替え可能です。 AI の引き出し方（プロンプト） — 現行実装では cdk/prompt/ 配下のテキストファイルを編集します。自社で本格運用する際は、本部の運用担当者が管理画面から直接編集できる形に発展させることを推奨します。 データソース — backend/store-agent/tools.py に新しい @tool 関数を追加し、 daily_summary_agent.py の tools=[...] に並べれば、基幹システム側の在庫などのデータも AI に参照させて示唆を考えさせることが可能です。 まとめ 「現場の声をどう本部に届けるか」という課題は、小売業に限りません。たとえば飲食チェーンなら、営業後のヒアリングで「今日のランチ帯、満席で断ったお客様はいましたか？」といった本部からの問いに対して、AI が「その時間帯、待ち時間が長かったのは何組くらいですか？」とさらに深掘り。翌朝には、売上・原価率・回転率・スタッフシフトと前日の定性観察を統合した AI の気づきやアクション提案が店舗や本部に届けられます。ほかにも、ホテル・宿泊、物流・倉庫、医療・介護、製造業など、現場スタッフが定量データの裏にある “なぜ” を持っている業界であれば、SMART のひな型を自社に合わせてカスタマイズすることで、活用できるのではないかと考えています。 本記事では、店舗の気づきの言語化を支援し、本部に届ける AI エージェント SMART と、ユナイテッドアローズでの取り組みについてご紹介しました。忙しい店長を助ける仕組みのサンプルとして、ご活用いただけたら幸いです。 AWS Summit Japan 2026 でお会いしましょう 本記事の内容は、 AWS Summit Japan 2026 でも、AWS 濱上がユナイテッドアローズ 加藤氏とのセッションでご紹介します。 セッションID : AIM258（L200） タイトル : 忙しい店長を助ける AI エージェント「SMART」— ユナイテッドアローズと創る、現場の声がデータになる日 日時 : 2026 年 6 月 25 日（木）13:30 – 13:50 会場 : 幕張メッセ ホール7  Theater2 また会場では、ユナイテッドアローズの活用事例ブースでのデモ展示も実施します。 ぜひお立ち寄りください。 著者について 加藤 大輔（Daisuke Kato） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 副部長 セキュリティ、EA（エンタープライズアーキテクチャ）、データ活用領域を担当しています。社内システムの企画・運用や共通基盤の整備を推進しながら、生成 AI の活用による業務効率化や新たな価値創出に取り組んでいます。 好きな AWS サービスは Amazon Elastic Container Service です。 池添 雄起（Yuki Ikezoe） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 データ連携基盤、システム監視基盤を担当しています。好きな AWS サービスは Kiro です。 大橋 遼子（Ryoko Ohashi） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 業務効率化アプリの企画・開発に取り組んでいます。好きな AWS サービスは Amazon Bedrock です。 石橋 直樹（Naoki Ishibashi） アマゾン ウェブ サービス ジャパン合同会社 ML プロトタイピングエンジニア AWS では生成 AI・MLOps など AIML に関連するプロトタイピング開発、技術相談などの支援を中心に行っています。好きな AWS サービスは Amazon SageMaker AI です。好きなファッションブランドは、UNITED ARROWS green label relaxing です。 濱上 和也（Kazuya Hamagami） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 流通・小売業のお客様の技術支援を行っています。好きな AWS サービスは Amazon Connect Customer で、業界問わずコンタクトセンター関連の技術支援も行っています。好きなファッションブランドは、UNITED ARROWS green label relaxing です。

エンジニアリング組織で Claude Code のような AI コーディングエージェントを利用している場合、その利用は追跡できる速度を上回って増加している可能性が高いでしょう。トークン消費量、チームごとのコスト、開発者の生産性といった疑問に既存のダッシュボードが答えられないのは、テレメトリがそもそもオブザーバビリティバックエンドに届いていないためです。 Amazon CloudWatch の OpenTelemetry Protocol（OTLP）が 一般提供 となったことで、ベアラートークン認証によるメトリクスの取り込みが可能になりました。これにより、OTLP を出力するツールは通常、認可ヘッダー 1 つだけでメトリクスを直接 CloudWatch に送信できます。コレクターもサイドカーも、開発者マシン上での IAM 認証情報の配線も不要です。数分でシグナルを接続し、開発者ごとのコスト按分、チーム単位の利用分析、運用アラートを実現でき、すべて Prometheus Query Language（PromQL）でクエリできます。 本記事では、Claude Code 向けのエンドツーエンドのセットアップを解説します。ここでは Claude Code に焦点を当てますが、OpenAI Codex と GitHub Copilot に関する包括的なガイダンスは AWS Observability ベストプラクティス で提供しています。本記事では、開発者マシン上でのシンプルさを重視してベアラートークン認証に焦点を当てます。開発者認証に SSO（シングルサインオン）や OIDC（OpenID Connect）を必要とする組織は、フェデレーテッドアイデンティティのパターンやトークン更新ヘルパーについて ガイダンスリポジトリ を参照してください。 ベアラートークン認証 ベアラートークン（CloudWatch メトリクス API キー）を使用すると、AWS の外部で動作するツール（開発者のノート PC 上の Claude Code など）が、AWS SDK や IAM 認証情報チェーンを必要とせずに CloudWatch へメトリクスを送信できます。各トークンは、 CloudWatchAPIKeyAccess 管理ポリシーのみにスコープされた AWS IAM ユーザーに紐づけられます。 重要： ベアラートークンは長期的な認証情報です。本記事では、AI コーディングエージェントが AWS 外部の開発者ノート PC 上で動作するため、ベアラートークンを使用します。SigV4 認証では、中央集約型のコレクターを用意するか、すべての開発者マシンでコレクタープロセスを実行する必要があります。いずれの方式も運用上の複雑さを増します。ベアラートークンはそのインフラ要件を完全に排除します。短期的な認証情報を用いた SigV4 が実現可能な AWS 内部で動作するワークロードでは、より強固なセキュリティ態勢のためにそちらの方式を推奨します。CloudWatch の OTLP エンドポイントは HTTPS を必須とし、平文 HTTP でのリクエストは拒否されます。詳細は CloudWatch OTLP Metrics Bearer Token Auth を参照してください。 粒度（granularity）戦略 組織は、ベアラートークンをどのようにプロビジョニングするかによって、テレメトリ属性の粒度を制御します。最も細かいレベルでは、各開発者が専用の IAM ユーザーとベアラートークンを持つため、属性はトークン自体に内在します。より粗いレベルでは、単一のトークンをチーム全体や組織全体で共有し、アイデンティティの属性は代わりにクライアント側のリソース属性で処理します。次の図は、これら 3 つのアプローチを示しています。 図 1：トークン粒度戦略のオプション（開発者ごと、チームごと、組織全体＋クライアント側属性の 3 アプローチ） 3 つのアプローチはいずれも同一のダッシュボードと PromQL クエリを生成します。属性がトークン自体ではなくリソース属性によって駆動されるためです。まずは単一の共有トークンでパイプラインを検証し、その後セキュリティ態勢の要件に応じてチームごと、または開発者ごとのトークンに分割してください。コンプライアンス上、特定個人に紐づけ可能な認証情報が求められる場合や、クリーンなオフボーディング（単一 IAM ユーザーの失効）が必須要件である場合には、開発者ごとのトークンを推奨します。 前提条件 CloudWatch リソースを作成する権限を持つ AWS アカウント インストール・設定済みの AWS CLI v2 最新バージョンの Claude Code CloudWatch メトリクス API キー（以下で生成） コンソールでベアラートークンを作成する CloudWatch コンソールで、 セットアップ(Setup)  セクション配下の  設定(Settings) 配下の グローバル(Global)  に移動します。 API キー(API Keys)  までスクロールします。 作成(Create) を選択します。 API キーの有効期限(API key expiration) を選択します。 CloudWatch が、 CloudWatchAPIKeyAccess ポリシーをアタッチした関連 IAM ユーザーを代わりに作成します。 図 2：CloudWatch コンソールの Settings ページでベアラートークンを作成する CLI でベアラートークンを作成する あるいは、以下のコマンドで CLI を使ってトークンを作成します。 # CloudWatch メトリクス取り込み用の IAM ユーザーを作成 aws iam create-user --user-name cloudwatch-metrics-api-key-user # CloudWatchAPIKeyAccess 管理ポリシーをアタッチ aws iam attach-user-policy \ --user-name cloudwatch-metrics-api-key-user \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAPIKeyAccess # CloudWatch メトリクス取り込み用のサービス固有認証情報を作成 aws iam create-service-specific-credential \ --user-name cloudwatch-metrics-api-key-user \ --service-name cloudwatch.amazonaws.com レスポンスには ServiceCredentialSecret フィールドが含まれ、これがベアラートークンの値です。 AWS Secrets Manager または組織の Vault ソリューションに安全に保管してください。トークンは決してバージョン管理にコミットしないように注意してください。鍵の自動ローテーションには、 Lambda 関数を用いた AWS Secrets Manager のローテーション を利用してください。 クライアント側の設定 ベアラートークンを設定したら、メトリクスをエクスポートするように Claude Code を構成できます。このアプローチでは、各開発者が設定する（またはプロファイル管理で配布する）クライアント側のリソース属性を使用します。 # Secrets Manager からトークンを取得 BEARER_TOKEN=$(aws secretsmanager get-secret-value \ --secret-id cloudwatch-otlp-bearer-token \ --query SecretString \ --output text) export CLAUDE_CODE_ENABLE_TELEMETRY=1 export OTEL_METRICS_EXPORTER=otlp export OTEL_EXPORTER_OTLP_PROTOCOL=http/json export OTEL_EXPORTER_OTLP_ENDPOINT="https://monitoring.<AWS_REGION>.amazonaws.com" export OTEL_RESOURCE_ATTRIBUTES="user.id=$(whoami),user.email=${USER_EMAIL},team.id=${TEAM:-engineering},cost_center=${COST_CENTER:-default},department=${DEPARTMENT:-engineering},environment=${ENV:-dev}" # セキュリティ上の注意：環境変数はプロセス一覧やシェル履歴から露出する可能性があります。 export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer ${BEARER_TOKEN}" # エクスポート頻度の制御（テスト用に 2 秒） export OTEL_METRIC_EXPORT_INTERVAL=2000 <AWS_REGION> はお使いのリージョン（例： us-east-1 、 eu-west-1 ）に置き換えてください。 OTEL_RESOURCE_ATTRIBUTES の行は、すべてのメトリクスにアイデンティティのディメンションを付与します。開発者がこれらの属性を直接設定します。これらはダッシュボードやアラートでフィルタリング・グループ化するための PromQL ラベルになります。組織が必要とする任意の属性を使用してください。重要な要件は、集計が機能するようにフリート全体で一貫性を保つことです。 属性 目的 例 user.id 開発者ごとの属性 jdoe user.email 開発者ごとの属性（メール） jdoe@acme.com team.id チーム単位の集計 platform-eng cost_center 財務／チャージバックのグループ CC-4200 department 組織単位のロールアップ engineering environment dev／staging／prod の利用区別 production 利用可能な標準属性とメトリクスの完全な一覧は、 Claude Code のドキュメント で確認できます。 テレメトリ設定とプライバシー制御をフリート全体に強制するために、Claude Code は組織のプロファイル管理ソリューションを通じてデプロイ可能な 管理者管理の設定 をサポートしています。 メトリクスが流れていることを確認する 環境変数を設定したら、短い Claude Code セッションを実行します。 # 短いセッションを開始 claude -p "Let's conquer the world" --max-turns 1 メトリクスが流れていることを確認するには、 CloudWatch Query Studio を開いて claude_ と入力します。使用されたトークン数を追跡する claude_code.token.usage など、いくつかのメトリクスが表示されます。 図 3：CloudWatch Query Studio でメトリクスの取り込みを確認する サンプル利用状況ダッシュボード 前述の粒度戦略に関わらず、PromQL を使って Claude Code のテレメトリデータをクエリする CloudWatch ダッシュボード が用意されています。リソース属性がクライアント側設定セクションで説明したセマンティック規約に従っている限り、すべての値が自動的にダッシュボードに表示されます。 構築済みダッシュボードをデプロイします。 # ダッシュボード定義をダウンロード curl -o claude-code-dashboard.json \ https://raw.githubusercontent.com/aws-observability/aws-observability-accelerator/main/artifacts/cloudwatch-dashboards/claude-code/claude-code.json aws cloudwatch put-dashboard \ --dashboard-name claude-code-usage \ --dashboard-body file://claude-code-dashboard.json \ --output off \ --region <AWS_REGION> ダッシュボードが作成されたことを確認します。 aws cloudwatch list-dashboards --dashboard-name-prefix claude-code --region <AWS_REGION> ダッシュボードは 5 つのセクションで構成されています。まずステークホルダーが全体の健全性を一目で評価できるよう高レベルのサマリーから始まり、その後トークンの経済性、開発者の活動、組織のコスト配分、インフラの健全性へと段階的に掘り下げていきます。 概要 最上段には、消費トークン総数、アクティブユーザー数、総セッション数、キャッシュヒット率を含むサマリーが表示されます。OTel メトリクスを Amazon CloudWatch に送信するように構成したリージョンを選択してください。 図 4：総トークン数、アクティブユーザー数、セッション数、キャッシュヒット率を示す概要サマリーカード トークン使用量 このセクションは、エンジニアリングリーダーが最初に問う質問に答えます。「どれだけ消費していて、その内訳はどこにあるのか？」。トークン消費を時系列、種類別（入力、出力、キャッシュ読み取り、キャッシュ作成）、モデル別、ユーザー別、推定コスト別に分解します。これらのパネルを使って、どのモデルが支出を牽引しているか、どのユーザーが最も多く消費しているかを特定できます。 図 5：時系列の消費量、種類別の内訳、モデル別の使用量、上位ユーザー、ユーザーごとの推定コスト、アクティブユーザーの推移を示すトークン使用量セクション 開発者の生産性 コストにとどまらず、このセクションでは開発者がツールで実際に生み出しているものを追跡します。追加・削除されたコード行数、コミット数、アクティブなコーディング時間、作成されたプルリクエスト、コード編集パターンなどです。言語別の内訳円グラフは、コードベースのどの部分が AI 支援から最も恩恵を受けているかを明らかにします。コード編集の判断パネル（承認 vs 却下）は、エージェントの提案が開発者の意図とどれだけ合致しているかのシグナルになります。 図 6：コード行数、コミット数、アクティブ時間、プルリクエスト、言語分布、コード編集の承認／却下率を示す開発者生産性メトリクス 組織別の内訳 複数のチームや部門を持つ組織向けに、このセクションはコスト配分のビューを提供します。これらのパネルは、クライアント側設定セクションで構成した department および team.id リソース属性に直接対応します。チャージバック、予算計画、組織内のどこがツールを最も効果的に活用しているかの特定に活用してください。 図 7：部門別およびチーム別のトークン使用量を示す組織別内訳 Amazon Bedrock API の健全性 Claude Code のバックエンドとして Amazon Bedrock を使用している場合、ダッシュボードにはインフラの健全性パネルも含まれます。これらはモデル別に分類されたスロットリングイベント、クライアントエラー、サーバーエラーを表示します。開発者から報告された問題（応答の遅延、リクエストの失敗）を上流の API の挙動と関連付けるのに活用してください。 アラート ダッシュボードのすべてのパネルは PromQL クエリに支えられています。任意のパネルからアラームを作成するには、次の手順を実行します。 関心のあるパネル（例：ユーザー別トークン使用量）を開きます。 View in Query Studio を選択して、基になるクエリを開きます。 Query Studio から直接 Create alarm を選択します。 必要に応じてクエリやしきい値を調整します。 ダッシュボードが示す範囲を超えるシナリオに対して、カスタムの PromQL アラームクエリを記述することもできます。いくつか例を挙げます。 個人の支出スパイク ある人物が 1 時間で前日 1 日分の支出の 2 倍以上を費やした場合、それは異常を示します。これは暴走ループ、スタックしたエージェント、または侵害されたトークンを検知します。 sum by("user.email") (increase({"claude_code.cost.usage"}[1h])) > 2 * sum by("user.email") (increase({"claude_code.cost.usage"}[24h])) 図 8：ユーザーの 1 時間あたりの支出が 1 日分の支出を上回ったときにトリガーする PromQL アラーム チーム予算のしきい値 チームの 1 日の支出が定義した予算を超えたときにアラートを出します。 sum by ("team.id") (increase({"claude_code.cost.usage"}[24h])) > 500 利用の減少 チームの 1 日のセッション数が 7 日間平均の 50% を下回ったときに検知します。これはツールの問題やアクセスの問題の可能性を示すシグナルです。 sum by ("team.id") (increase({"claude_code.session.count"}[1d])) < 0.5 * avg_over_time(sum by ("team.id") (increase({"claude_code.session.count"}[1d]))[7d:1d]) Amazon Managed Grafana でダッシュボードを使用する Amazon Managed Grafana またはセルフマネージドの Grafana を使用している場合は、 Grafana からのクエリに関するドキュメント に従って CloudWatch を PromQL データソースとして追加し、 Grafana ダッシュボード JSON をインポートしてください。 コスト見積もり 各開発者が 1 日あたり約 20 セッションを実行し、それぞれがリソース属性付きで約 7 つのメトリクスデータポイントを出力し、開発者が月あたり約 22 日アクティブな、開発者 200 名の組織の場合： 10〜15 個の属性を持つ一般的な OTLP データポイントは 300〜600 バイトです。中間値として 450 バイトを使用すると： 200 開発者 × 20 セッション/日 × 7 メトリクス × 450 バイト = 12.6 MB/日 12.6 MB/日 × 22 日 = 約 277 MB/月 ≒ 0.27 GB/月 取り込み料金 $0.50/GB では、基本ケースで月あたり約 $0.14 です。高カーディナリティのメトリクス（100 倍のボリューム）でも、取り込み総額は月あたり $14 未満にとどまります。CloudWatch コンソールでの PromQL クエリは 無料 です。 この例における開発者 200 名分の総コストは、月あたり $15 未満 になります。 最新情報については Amazon CloudWatch 料金ページ を参照してください。 クリーンアップ 重要： CloudWatch はメトリクスを最大 15 か月間、無料で保持します。継続的なコストとセキュリティ上の露出を避けるため、アラームと IAM リソースを削除してください。 作成したすべてのリソースを削除するには、次のコマンドを実行します。 # ダッシュボードを削除 aws cloudwatch delete-dashboards --dashboard-names claude-code-usage --region <AWS_REGION> # CloudWatch アラームを削除 aws cloudwatch delete-alarms --alarm-names <alarm-name> --region <AWS_REGION> # サービス固有認証情報を削除 aws iam delete-service-specific-credential --user-name cloudwatch-metrics-api-key-user --service-specific-credential-id <credential-id> # IAM ユーザーからポリシーをデタッチ aws iam detach-user-policy --user-name cloudwatch-metrics-api-key-user --policy-arn arn:aws:iam::aws:policy/CloudWatchAPIKeyAccess # IAM ユーザーを削除 aws iam delete-user --user-name cloudwatch-metrics-api-key-user # Secrets Manager を使用している場合はシークレットを削除 # 警告：シークレットの削除は不可逆です。ベアラートークンは復元できません。 # 続行する前に、トークンが不要であることを確認してください。 aws secretsmanager delete-secret --secret-id <secret-name> --region <AWS_REGION> テレメトリのエクスポートを停止するには、環境変数の設定を解除するか、シェルプロファイルから削除します。 unset CLAUDE_CODE_ENABLE_TELEMETRY OTEL_METRICS_EXPORTER OTEL_EXPORTER_OTLP_ENDPOINT OTEL_EXPORTER_OTLP_HEADERS OTEL_RESOURCE_ATTRIBUTES まとめ 本記事では、ベアラートークン認証を使用して OpenTelemetry メトリクスを Amazon CloudWatch にエクスポートするように Claude Code を構成し、コストと利用状況を可視化する PromQL ベースのダッシュボードをデプロイし、支出の異常と利用の減少に対するアラートを設定しました。 同じ CloudWatch OTLP エンドポイントは、IDE エージェントだけでなく、OpenTelemetry で計装されたあらゆるワークロードからのテレメトリを受け付けます。複数のアカウントとリージョンを持つ大規模組織向けに、一般提供では クロスアカウント・クロスリージョンのメトリクス集約 も導入されました。これにより、統一された可視性を実現するために単一のオブザーバビリティアカウントへメトリクスを収集できます。 GitHub Copilot および OpenAI Codex 向けの IDE オブザーバビリティのセットアップ方法については、 完全ガイド をご覧ください。 TAGS: Amazon CloudWatch , Amazon Managed Grafana , Monitoring & Observability   本記事は、 Analyzing Claude Code usage with CloudWatch and OpenTelemetry を翻訳したものです。 翻訳は Solutions Architect の 津和崎 が担当しました。 Rodrigue Koffi Amazon Web Services のオブザーバビリティ担当スペシャリストソリューションアーキテクト。オブザーバビリティ、分散システム、機械学習に情熱を注ぐ。強力な DevOps とソフトウェア開発のバックグラウンドを持ち、Go でのプログラミングを好む。業務外では水泳と家族と過ごす時間を楽しむ。LinkedIn：/grkoffi Gianluca Cacace アイルランド・ダブリンの Amazon Web Services のプリンシパルエンジニア。オブザーバビリティを専門とし、大規模システムにおけるスケーラビリティと設計課題に情熱を注ぐ。余暇には旅行と個人プロジェクトを楽しむ。 Vadim Omeltchenko シニア AI/ML ソリューションアーキテクト。AWS のお客様がクラウドでイノベーションを起こすことを支援することに情熱を注ぐ。以前の IT 経験は主にオンプレミス環境でのもの。

re:Invent 2025 では、開発ライフサイクル全体を通じてあらゆる環境でアプリケーションをプロアクティブに保護するフロンティアエージェントである AWS セキュリティエージェント (現在は AWS Continuum の一部) を プレビュー公開しました 。アプリケーションに合わせてカスタマイズされたオンデマンドのペネトレーションテストを実行し、悪用可能性テストで検証されたセキュリティリスクを検出して報告できます。 プレビュー公開後、 オンデマンドのペネトレーションテスト の一般提供の開始と、コードベース全体に対してコンテキストを考慮した詳細なセキュリティ分析を実行する フルリポジトリコードレビュー のプレビューを発表しました。 6 月 17 日は、お客様からのフィードバックに基づき、さらに多くの機能をご紹介します: コードレビューのアップデート (プレビュー) – 是正、セキュリティ要件パック、シミュレーション検証とともに、プルリクエストスキャンを使用できるようになりました。新しい統合は、GitHub、GitLab、Bitbucket、Confluence をサポートします。 脅威モデリング (プレビュー) – AWS セキュリティエージェントは、設計ドキュメントまたはアプリケーションのソースコードを分析し、アプリケーションアーキテクチャのコンテキスト全体を理解して、STRIDE フレームワークを使用して脅威を特定し、推奨される緩和策を提示します。 Kiro パワー、Claude Code プラグイン、および MCP 統合 – オープンな MCP 統合を通じて、IDE、CLI、または AI を利用した IDE から直接、コードレビューの実行、脅威モデルの生成、および検出結果の是正を行うことができます。結果はコンテキストを切り替えることなく、インラインで表示されます。 各リリースの詳細を見てみましょう! コードレビューのアップデート GitHub に加えて、GitLab と Bitbucket にも接続できるようになりました。SaaS バージョンとセルフホストバージョンの両方をサポートしているため、コードが存在する場所にかかわらず、スキャンをトリガーできます。また、Confluence を統合して、既存のドキュメントをレビューのコンテキストとして参照することもできます。 開始するには、 [コードレビューを有効にする] を選択するか、または セキュリティエージェントコンソール でコードレビューの設定を更新します。 AWS セキュリティエージェントは、パターンマッチングでは検出できない複雑な脆弱性を特定するために、あらゆるプルリクエストとリポジトリ全体に対する高度な推論ベースの分析を提供します。組織のセキュリティ要件と一般的なセキュリティリスクに照らしてチェックすることで、他のツールでは検出できない脆弱性を検出します。開始するには、セキュリティエージェントのウェブアプリケーションにアクセスしてコードレビューを実行します。 セキュリティチームがモニタリング対象のリポジトリを設定し、重大な問題に介入している間、修正コミットと是正ガイダンスが GitHub、GitLab、または Bitbucket のワークフロー内で直接提供されます。AWS セキュリティエージェントは、悪用可能性を実証するために、シミュレーション環境で検出結果を検証します。これにより、すべてのリポジトリにセキュリティの専門知識が組み込まれ、開発パイプラインにおけるセキュリティ関連の遅延を削減できます。 新しいコードレビュー機能の詳細については、「AWS セキュリティエージェントユーザーガイド」の「 Create a code review 」にアクセスしてください。 設計レビューの更新 マネージドコンプライアンスパック ( AWS WAF 、 NIST CSF 、 PCI DSS 、AWS ベストプラクティス) を使用することで、あらゆる設計およびコードレビューにおいてセキュリティ要件を継続的に検証できます。また、社内ドキュメントや Confluence から直接、組織独自の要件をインポートすることも可能です。あらゆる検出結果はコンプライアンス体制にマッピングされるため、チームは構築を進めながら監査対応体制を維持できます。 詳細については、 設計レビューのドキュメント にアクセスしてください。 脅威モデリング AWS セキュリティエージェントは、設計ドキュメントまたはコードリポジトリに基づいて脅威モデルを生成し、データフロー、アーキテクチャ、信頼の境界など、アプリケーションに関するコンテキストを作成および構築します。アプリケーションのすべてのコンポーネントをマッピングし、潜在的な脅威アクターと攻撃ベクトルを特定するとともに、脆弱性が存在する可能性のある箇所を特定して、脅威に優先順位を付けることで、最初に対処すべき脅威を明確にします。 開始するには、 セキュリティエージェントコンソール で [脅威モデルを有効にする] と [ソースコードリポジトリを接続] を選択します。 詳細については、 脅威モデリングのドキュメント にアクセスしてください。 AWS セキュリティエージェント用の Kiro パワーおよび Claude Code プラグイン AWS セキュリティエージェントは、新しい Kiro パワー および Claude Code プラグイン (近日リリース予定) を導入します。アプリケーションを保護するために、オープン MCP 統合を通じてあらゆる AI IDE と統合できます。IDE から直接脅威モデルとコードレビューをトリガーでき、コンテキストを切り替えることなく、結果がインラインで表示されます。 開始するには、 Kiro パワー をインストールし、プロンプトを実行します。 Kiro パワーは、 AWS セキュリティエージェント MCP サーバー を使用します。「 Set up AWS Security Agent 」と指示することで、パワーの使用を開始できます。 Kiro は、エージェントスペースが存在するかどうかを確認し、既存のスペースを使用するか、または新しいスペースを作成するかをたずねます。 セキュリティエージェント向けの Kiro パワーを使用すると、 「 Run a full security scan on this repo 」と指示することで、構築する際にあらゆるプルリクエストで脆弱性を検出し、リポジトリ全体をスキャンして蓄積されたリスクを明らかにすることができます。セキュリティエージェントのパワーには、Kiro エージェントの処理完了後にコードレビュー差分スキャンを開始すべきかどうかを評価するエージェントフックが含まれています。本番にデプロイする前に、CLI からペネトレーションテストを実行して、ほとんどのスキャナーが見逃す脆弱性を見つけることができます。セキュリティエージェントは、あらゆる検出結果を検証し、すぐに実装できるコード修正を生成することで、ループを完結させます。 「 help me remediate my findings 」と指示することで、検出結果を開発環境にプルできます。AWS セキュリティエージェント用の Kiro パワーは、検出結果をローカルワークスペースにダウンロードし、最も重要な検出結果を優先して、バグ修正仕様セッションの開始を提案します。使い慣れた IDE と既存のツール、ステアリング、パワー、および MCP サーバーを使用して、検出結果の修正をイテレーションできます。 また「 Build a threat model for this application 」と指示することによって、IDE で Kiro パワーを通じて脅威モデルを実行することもできます。 生成された脅威モデルは .security-agent/threat_model.md に保存されます。 詳細については、 セキュリティエージェント用の Kiro パワー にアクセスしてください。 今すぐご利用いただけます AWS セキュリティエージェントは、設計段階のセキュリティ (設計レビューと脅威モデリングはプレビュー)、開発段階のセキュリティ (コードレビューはプレビュー)、デプロイ段階のセキュリティ (ペネトレーションテストは一般提供開始) を、単一の統合エージェントソリューションでカバーすることで、ソフトウェア開発ライフサイクル全体にわたる完全なセキュリティコンテキストを理解します。詳細については、AWS セキュリティエージェントの 製品ページ と 技術文書 をご覧ください。 これらの機能は、AWS セキュリティエージェントが利用可能な AWS 商用リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。料金に関する詳細と、2 か月間の無料トライアルオファーへのアクセスについては、 AWS セキュリティエージェントの料金ページ にアクセスしてください。 セキュリティエージェントのコンソール でお試しいただき、 AWS re:Post for Security Agent 宛てに、または通常の AWS サポートの連絡先担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

2026 年 6 月 18 日、AI 推論、グラフィックス、データ分析のワークロード向けに高性能な GPU アクセラレーションを提供する Amazon Elastic Compute Cloud (Amazon EC2) G7 インスタンスの一般提供の開始を発表しました。 AWS は、NVIDIA RTX PRO 4500 Blackwell Server Edition GPU をサポートする最初の主要クラウドプロバイダーです。G7 インスタンスは、これらの GPU と第 6 世代のカスタムインテル Xeon Scalable プロセッサを組み合わせることで高速化されており、 G6 インスタンス と比較して、最大 4.6 倍の AI 推論パフォーマンスと最大 2.1 倍のグラフィックスパフォーマンスを実現します。また、G7 インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 上の Amazon EMR における GPU アクセラレーテッド分析でも、より高速なパフォーマンスを発揮します。G7 インスタンスは、AI 推論、グラフィックスレンダリング、動画トランスコーディングおよび分析、空間コンピューティング、仮想デスクトップインフラストラクチャ (VDI)、データ分析など、GPU を活用する幅広いワークロードに適しています。 前世代と比較した G7 インスタンスの改善点は次のとおりです: より高速な GPU メモリ – NVIDIA RTX PRO 4500 Blackwell Server Edition GPU は、G6 インスタンスと比較して 1.33 倍の GPU メモリ容量と 2.45 倍の GPU メモリ帯域幅を提供します。GPU あたり 32 GB の GPU メモリ、第 5 世代 Tensor コア、第 4 世代 RT コアを搭載し、AI 推論およびグラフィックスパフォーマンスが向上しています。 高パフォーマンスのネットワーキングとストレージ – G7 インスタンスは、700 Gbps の EFA 対応ネットワーキングスループット (G6 と比較して 7 倍) を備えています。これにより、AI 推論、グラフィックス負荷の高いアプリケーション、GPU アクセラレーテッドデータ分析ワークロードが最高のパフォーマンスを発揮するために必要な、低レイテンシーで広帯域の接続を実現します。G7 インスタンスは最大 7.6 TB のローカル NVMe SSD ストレージをサポートしており、大規模なモデルやデータセットをコンピューティングの近くに保持することで、データ転送のオーバーヘッドを削減し、スループットを改善できます。 高度な動画エンコーディングおよびデコーディングエンジン – 第 9 世代 NVENC および第 6 世代 NVDEC エンジンは、高解像度動画ワークフロー向けの 4:2:2 エンコーディングおよびデコーディングをサポートしており、前世代の G6 インスタンスと比較して 1.5 倍の同時動画ストリームを実現します。 EC2 G7 インスタンスの仕様 G7 インスタンスには、最大 256 GB の合計 GPU メモリ (GPU あたり 32 GB のメモリ) を提供する最大 8 個の NVIDIA RTX PRO 4500 Blackwell Server Edition GPU と、カスタムインテル Xeon Scalable プロセッサが搭載されています。また、7 つのサイズでご利用いただけるほか、最大 192 個の vCPU、最大 700 Gbps のネットワーク帯域幅、最大 768 GiB のシステムメモリ、最大 7.6 TB のローカル NVMe SSD ストレージもサポートしています。 仕様は次のとおりです: インスタンス名 GPU GPU メモリ (GB) vCPU 数 メモリ (GiB) ストレージ EBS 帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) g7.2xlarge 1 32 8 32 1 x 600 最大 8 最大 60 g7.4xlarge 1 32 16 64 1 x 600 8 最大 100 g7.8xlarge 1 32 32 128 1 x 950 16 最大 100 g7.12xlarge 2 64 48 192 1 x 1900 20 175 g7.24xlarge 4 128 96 384 1 x 3800 40 350 g7.48xlarge 8 256 192 768 2 x 3800 80 700 g7.metal* 8 256 192 768 2 x 3800 80 700 * 近日リリース予定 G7 インスタンスは、マルチ GPU サイズ向けの NVIDIA GPUDirect P2P、EFA を使用した NVIDIA GPUDirect RDMA、および Amazon FSx for Lustre 向けの EFA を使用した GPUDirect RDMA をサポートしており、マルチ GPU およびマルチノードのワークロードにおいて低レイテンシーの GPU 間通信を可能にします。 G7 インスタンスの使用を開始するには、AI 推論やグラフィックスワークロード向けに事前パッケージ済みの GPU ドライバーを備えた AWS Deep Learning AMI (DLAMI) または NVIDIA Workstation AMI を使用できます。Amazon EKS で G7 インスタンスを使用するには、 EKS が提供するオートメーション を使用して、NVIDIA ドライバーバージョン R595 を含む EKS AMI を構築してください 。 G7 インスタンスは、Amazon Linux、Ubuntu、RHEL、Windows Server など複数のオペレーティングシステムをサポートしており、包括的な NVIDIA ドライバーの統合により、DirectX、Vulkan、OpenGL などの業界標準のグラフィックスライブラリとの互換性を提供します。 今すぐ始めましょう Amazon EC2 G7 インスタンスは、米国東部 (オハイオ) と米国西部 (オレゴン) の 2 つの AWS リージョンで今すぐ利用を開始できます。今後のリージョン展開計画を確認するには、「 AWS サービス (リージョン別) 」ページの CloudFormation リソースタブでインスタンスタイプを検索してください。 G7 インスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス など、複数の購入オプションを通じて提供されています。 12xlarge 、 24xlarge 、 48xlarge のサイズでは、 ハードウェア専有インスタンス もサポートされています。詳細な料金については、「 Amazon EC2 の料金 」ページにアクセスしてください。 始める準備はできましたか? Amazon EC2 コンソール から G7 インスタンスを起動してください。詳細については、「 Amazon EC2 G7 instances 」ページをご覧ください。フィードバックをぜひお寄せください。 AWS re:Post for EC2 で共有いただくか、または通常の AWS サポート担当者を通じてご連絡ください。 – Daniel Abib 原文は こちら です。

2026 年 6 月 17 日、 Amazon Bedrock マネージドナレッジベース を発表しました。これは、デベロッパーが所有データを使用してエンタープライズグレードの生成 AI アプリケーションを数分で構築できるようにする新しい機能セットです。エージェンティック AI アプリケーションを構築する組織は、正確かつ迅速で信頼性の高い結果をもたらすために、企業全体のデータへの、セキュアで信頼性の高い最新のアクセスを必要とします。マネージドナレッジベースは、検索拡張生成 (RAG) パイプラインの構築と管理の複雑さを抽象化し、デベロッパーがインフラストラクチャ管理ではなく、ビジネス成果の実現に注力できるようにします。 今日、エージェント向けのナレッジベースを構築するデベロッパーは、3 つの主要な課題に直面しています: エンタープライズデータへの接続 – エンタープライズナレッジは、コンテンツタイプ、アクセスコントロールリスト、ドキュメント形式が異なる、さまざまなシステムに分散して存在しています。各ソースごとにカスタムコネクタを構築および維持することは、開発の複雑さを増大させ、開発速度を低下させます。 RAG 精度の最適化 – 検索拡張生成に関するベストプラクティスは進化し続けています。デベロッパーは、データから正確な回答を得るために、さまざまな解析戦略、チャンキングアプローチ、埋め込みモデル、エージェンティック検索動作を実験する必要があります。 インフラストラクチャの大規模な管理 – 組織は、数百万のドキュメントを含む大規模なナレッジベースを運用したり、チーム間で数千の小規模なナレッジベースを管理したりする必要があります。いずれのパターンでも、信頼性の高いインフラストラクチャ、セキュリティ対策、コスト管理が不可欠です。 これらの課題により、デベロッパーは、アプリケーションに注力するのではなく、差別化につながらない作業を繰り返し実行せざるを得なくなります。 Amazon Bedrock マネージドナレッジベースは、デベロッパーが従来自らアセンブルおよび維持しなければならなかった複数のインフラストラクチャコンポーネント (ストレージ、検索、埋め込み、再ランキング、基盤モデルの選択など) を単一のマネージドプリミティブに抽象化することで、これらの課題を解決します。デフォルトでは、サービスがデフォルトの埋め込みモデル、再ランキング付けモデル、基盤モデルを自動的に選択および管理するため、お客様は、モデルを選択したり、管理したりすることなく、すぐに使用を開始できます。このマネージド基盤に加えて、使いやすさと精度をさらに高める 3 つの主要なイノベーションがあります: ネイティブデータコネクタ – エンタープライズデータと許可を SaaS アプリケーションからネイティブにプルする 6 つの事前構築済み取り込みコネクタにより、デベロッパーがアプリケーション固有の要件を管理する際のオーバーヘッドがなくなります。リリース時点では、Amazon S3、SharePoint、Confluence、Web Crawler、Google Drive、OneDrive がサポートされています。 Smart Parsing – コンテンツのタイプやソースによって、正確な検索を実現するために必要なアプローチは異なります。Smart Parsing は、この複雑さを自動的に処理し、各データタイプとコネクタに適したパーシング戦略を選択することで、エージェントのために極めて高い精度を提供します。 Agentic Retriever – 単一のナレッジベース内、または複数のナレッジベースにまたがる、マルチターン、マルチホップの検索を必要とする複雑なクエリ向けに最適化されています。Agentic Retriever は、エンドユーザーの意図を自動的に推測し、複数のデータソースやモダリティにわたって分散した組織のナレッジから関連するコンテキストを抽出します。 わずか数行のコードで、Amazon Bedrock マネージドナレッジベースは、エンタープライズナレッジエージェントを支えるエンドツーエンドの RAG パイプラインを自動的に管理およびスケールします。エージェントビルダー向けに、 Amazon Bedrock AgentCore Gateway で事前構築済みのターゲットタイプとして利用可能となっています。これにより、統合はわずか数行のコードで済むほか、ロールベースの許可が自動生成され、AgentCore Observability ダッシュボードでオブザーバビリティと評価メトリクスが提供されます。 Amazon Bedrock マネージドナレッジベースの開始方法 マネージドナレッジベースの作成は簡単です。 Amazon Bedrock AgentCore コンソール または Amazon Bedrock コンソール に移動し、 [ナレッジベース] ページを開いて、 [マネージド KB を作成] を選択します。操作感はいずれのコンソールでも同じです。既に慣れ親しんでいるかもしれない他のナレッジベースのタイプに加えて、推奨オプションとして [非構造化ベクトルストア KB] が利用可能になっています: 図 1 – Amazon Bedrock AgentCore コンソールのナレッジベースのリストページ。[タイプ] 列にさまざまな KB タイプが表示されており、[マネージド KB を作成] ボタンも確認できます 新しいナレッジベースを作成する際には、ドロップダウンで直接、サポートされているコネクタのリストから選択することで、エンタープライズデータソースに直接接続できます。 AWS Identity and Access Management (IAM) ロールが自動的に作成され、必要に応じてこれらの許可を編集することを選択できます: 図 2 – [ナレッジベースを作成] ページ。データソースのドロップダウンリストが展開されており、Amazon S3、Confluence、カスタム、Google Drive、OneDrive、SharePoint、Web Crawler といったサポートされているすべてのコネクタが表示されています 最適化されたデフォルト設定セットが表示されるため、わずか数回のクリックでナレッジベースを作成できます。データが同期されたら、ナレッジベースをエージェントと統合したり、基盤モデルのツールとして指定してクエリを開始したりできます。 正確なデータインジェストのための Smart Parsing ナレッジベースの構築における主要な課題の 1 つは、多様なデータタイプを正確に検索できるように準備することです。マネージドナレッジベースをデータソースにポイントすると、Smart Parsing が各データタイプとコネクタに最適なパーシング戦略を自動的に決定します。追加の設定は不要です。 Smart Parsing は、次の複数の手法を組み合わせています: コネクタ固有のデータモデル – 各データソースのために最適化された処理。例えば、Web Crawler コネクタは、埋め込み画像やテーブルを含む HTML 構造を保持し、取り込み中にリッチコンテンツが失われないようにします。SharePoint コネクタは、ドキュメントの階層とファイル間の関係を維持します。 マルチモーダル処理 – ドキュメント内のさまざまなコンテンツタイプの自動検出と処理。システムはドキュメント内のバウンディングボックスを識別し、データ抽出、キャプション生成、動画ファイルのシーン記述のために基盤モデルに送信します。 最適化されたチャンキング – Smart Parsing は、基盤モデルを活用してドキュメント構造を理解し、意味のあるコンテンツを抽出します。これにより、複数のフォーマットが混在する複雑なドキュメントも適切にインデックス化されます。インテリジェントなデフォルト設定はドキュメントのタイプとコンテンツ構造に基づいて検索の精度とパフォーマンスのバランスを取り、上級ユーザーは必要に応じてチャンキング戦略をカスタマイズできます。 この自動化されたアプローチにより、通常、本番レベルの質の検索精度を実現するために必要となる数週間に及ぶ実験が不要になり、必要に応じてカスタマイズできる柔軟性も維持されます。 複雑なクエリでの Agentic Retriever の使用 データの取り込みが完了したら、ナレッジベースへのクエリを開始できます。生成 AI アプリケーションは、推論、再帰的な複数ステップの検索、および結果の中間評価を必要とする複雑なユーザークエリの処理に苦慮することがよくあります。ユーザーが「ML プラットフォームチームのクラウドインフラストラクチャ予算はどうなっていますか?」と「当社の経費ポリシーでは、年間契約の事前払いは認められていますか?」という 2 つの関連する質問をする場合を考えてみましょう。 単一の検索ステップでは、ML プラットフォームチームに関するドキュメントは見つかるかもしれませんが、質問に完全に答えるために必要な予算に関する情報と経費ポリシーを結びつけることができない場合があります。 図 3 – Agentic Retriever は、複雑なユーザークエリをステップバイステップのプランに分解し、複数のナレッジベースでマルチホップ検索を実行して結果を組み合わせ、根拠がある正確な応答を提供します Agentic Retriever は、ステップバイステップのクエリプランを作成することでこれを解決します: 1.どのチームが ML プラットフォームを所有しているか? また、そのチームのクラウドインフラストラクチャの予算はどうなっているか? 2.年間契約の事前払いに関する経費ポリシーはどうなっているか? 3.ML プラットフォームチームがこの予算から事前払いすることはポリシーで認められているか? システムは各ステップでマルチホップ検索と推論を実行し、十分な関連パッセージが収集されたら検索プロセスを停止して、上位の結果を返します。このアプローチは、個別のマルチホップ推論パイプラインを構築する複雑さを抽象化することで、複雑なクエリの精度を劇的に高めつつ、デベロッパーがオーケストレーションロジックではなく、エージェンティック検索アプリケーションに注力できるようにします。 Amazon Bedrock AgentCore コンソールのナレッジベースのテストパネルから、Agentic Retriever を直接お試しいただけます。ナレッジベース全体にわたる複数ステップのクエリをシステムが自動的に計画および実行できるようにするには、検索タイプとして [エージェンティック検索のみ] を選択します: 図 4 – [ナレッジベースをテスト] パネル。検索タイプとして [エージェンティック検索 (回答生成あり)] が選択されており、モデルの選択、および最大エージェンティックイテレーションオプションが表示されています Bedrock AgentCore で MCP を有効にする Amazon Bedrock マネージドナレッジベースは、ネイティブターゲットタイプとして AgentCore Gateway とシームレスに統合します。この統合により、手動での統合が不要になり、組み込みのオブザーバビリティ、ポリシーの強制適用、および自動許可管理が提供されます。 Amazon Bedrock AgentCore コンソールまたは SDK に移動して、AgentCore Gateway を作成したり、既存のゲートウェイを選択したりできます。ゲートウェイにターゲットを追加する際、MCP サーバー、Lambda ARN、REST API、および他の統合オプションとともに、新しい事前構築済みターゲットタイプとして [ナレッジベース] が表示されます。ゲートウェイを通じて公開するために必要なのは、ナレッジベース ID を選択することだけです: 図 5 – AgentCore Gateway の [ターゲットを追加] ページ。ナレッジベース ID セレクタとランタイム検索モードオプションを備えた、新しい事前構築済みターゲットタイプとしてナレッジベースが表示されています AgentCore Gateway の [ターゲットを追加] ページ。ナレッジベース ID セレクタとランタイム検索モードオプションを備えた、新しい事前構築済みターゲットタイプとしてナレッジベースが表示されています ゲートウェイは標準のモデルコンテキストプロトコル (MCP) を公開するため、ナレッジベースツールは、 Strands Agents 、 LangChain 、 CrewAI 、 LlamaIndex 、 LangGraph など、MCP 互換フレームワークのクライアントによって自動的に検出されます。カスタム統合コードは不要です。 モデルの選択と柔軟性 Amazon Bedrock マネージドナレッジベースは、デベロッパーが Amazon Bedrock に期待する柔軟性を維持します。Bedrock で使用可能なすべての基盤モデルは生成ステップで使用でき、デベロッパーはさまざまな埋め込みモデルと再ランキングモデルから選択して、特定のユースケースに合わせて検索を最適化できます。これにより、チームはインフラストラクチャを変更することなく、精度とコストパフォーマンスをファインチューニングできます。 特定のモデルプロバイダーにロックインされるマネージドソリューションとは異なり、Amazon Bedrock マネージドナレッジベースは、インフラストラクチャ管理 (コネクタ、解析、ストレージ、検索オーケストレーション) とモデル選択を分離します。これは、次が可能であることを意味します: 最新モデルを活用する – 最新の埋め込みモデル、再ランキングモデル、基盤モデルが利用可能になり次第、それらを採用することで、RAG パイプラインを再構築することなく、アプリケーションの精度、レイテンシー、コストを改善できます。 料金パフォーマンスを最適化する – 同じナレッジベースインフラストラクチャを使用して、シンプルなクエリにはより小型で高速なモデルを、複雑な推論タスクにはより高性能なモデルを選択できます。 Bedrock 埋め込みモデルを使用する – Smart Parsing は最適化されたデフォルト設定を提供しますが、ドメインで特殊な意味論的理解が必要な場合は、Bedrock 埋め込みモデルを設定できます。 既存アプリケーションとの一貫性を維持する – Bedrock ナレッジベース API ( Retrieve 、 StartIngest 、 StopIngest 、 IngestKnowledgeBaseDocuments ) を既に使用している場合、マネージドナレッジベースは同じ API を使用するため、移行にはコードの変更は不要で、新しいナレッジベース ID をポイントするだけで済みます。 このアプローチにより、進化する要件や新しいモデル機能に基づいてモデルを変更する能力を失うことなく、生成 AI アプリケーションに時間を割けます。 今すぐ始めましょう Amazon Bedrock マネージドナレッジベースは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー、東京)、欧州 (ダブリン、フランクフルト、ロンドン)、および AWS GovCloud (米国西部) リージョンで現在利用可能です。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 Bedrock マネージドナレッジベースでは前払いの義務はなく、お支払いいただくのは使用した分の料金のみです。料金は、保存されるインデックス付きデータのサイズと、実行される検索回数 (オンデマンド) の 2 つの要素に基づきます。料金の詳細については、 Amazon Bedrock の料金ページ にアクセスしてください。また、Bedrock は AWS 無料利用枠 の一部でもあり、AWS の新規のお客様は無料で利用を開始し、主要な AWS サービスを試すことができます。 これらの機能は、CreWAI、LangGraph、LlamaIndex、Strands Agents などのあらゆるオープンソースフレームワークと、あらゆる基盤モデルで動作します。Bedrock サービスは一緒に使用することも、単独で使用することもできます。 AgentCore オープンソース MCP サーバー を使用して、お気に入りの AI 支援開発環境の使用を開始できます。 詳細を確認し、すぐに使用を開始するには、「 Bedrock ナレッジベースデベロッパーガイド 」にアクセスしてください。 Daniel Abib 原文は こちら です。

2026 年 6 月 17 日、 Amazon Bedrock AgentCore での Web Search の一般提供の開始を発表しました。これは、エージェントがお客様の保護された AWS 環境からデータを一切外部に持ち出すことなく、出典が明示された最新のウェブ知識に基づいて応答を生成できるようにするフルマネージドツールです。 Web Search は、モデルコンテキストプロトコル (MCP) を使用する Bedrock AgentCore Gateway で組み込みコネクタターゲットを使用します。エージェントが自然言語クエリを送信すると、Web Search は最も関連性の高いスニペット、ソース URL、タイトル、公開日を返します。モデルはこれらの情報に基づいて推論し、根拠に基づいた応答を生成します。 これは、Amazon の検索インフラストラクチャを基盤として構築されており、 Alexa+ 、 Amazon Quick 、 Kiro において長年にわたってエージェンティック検索エクスペリエンスを支えてきた経験に基づいています。Amazon のウェブインデックスと構造化されたナレッジグラフデータを組み合わせたマルチソースグラウンディングアプローチを採用しています。これは、標準的なウェブ検索の結果に加えて、検証済みの事実を含む Amazon Knowledge Graph へのアクセスをエージェントに提供するため、従来のウェブ検索のみの場合よりも、より関連性が高く正確な応答を取得するのに役立ちます。 今回のリリースにより、Bedrock AgentCore 上のエージェントにウェブ検索を手動で追加したり、そのインフラストラクチャを管理したりするのではなく、エージェントの構築に注力できます。AI エージェントはユーザーの質問を分析し、最新の事実を取得した後、モデルのトレーニングデータだけでなく、最新の動向に基づいて必要なアクションを実行します。また、AWS 以外の外部検索 API プロバイダーにユーザープロンプトや検索クエリを送信することなく、エンタープライズガバナンスポリシーを満たすことができます。 Bedrock AgentCore での Web Search が実際に機能している様子 開始するには、 Bedrock AgentCore コンソール で Web Search ツールターゲットを含む Bedrock AgentCore Gateway を作成します。ゲートウェイ URL が作成されると、API コール、コマンドラインインターフェイス (CLI)、または MCP Inspector を使用して操作できます。 ゲートウェイの作成時に Web Search ツールターゲットを追加するには、ターゲットプロトコルとして [MCP ターゲット] 、ターゲットタイプとして [コネクタ] を選択します。リンク、スニペット、メタデータなど、最も関連性の高いウェブ検索の結果を取得するには、 Web Search ツール を事前設定済みターゲットとして選択できます。 ゲートウェイを作成すると、ゲートウェイの詳細ページで Web Search ツールターゲットを確認できます。既存のゲートウェイに新しい Web Search ツールターゲットを追加することもできます。 Web Search ツールを操作するには、 [呼び出しコードを表示] セクションにあるサンプル呼び出しコードを使用します。API リクエスト、MCP Python SDK、Strands MCP Client、および MCP Inspector で、Python コードを通じてコードスニペットを使用できます。 例えば、MCP サーバーのテストとデバッグのためのインタラクティブなデベロッパーツールである MCP Inspector を操作できます。  ゲートウェイリソース URL を通じて MCP サーバーに接続すると、ゲートウェイ上の各コネクタターゲットに対応する Web Search ツールが表示されます。ウェブ検索クエリを入力し、 [ツールを実行] を選択すると、結果が表示されます。 Bedrock AgentCore での Web Search の使用方法の詳細については、 Bedrock AgentCore Gateway のドキュメント にアクセスしてください。 お客様の声 一部のお客様には、この新機能への早期アクセスが付与されていました。これらのお客様から寄せられたご意見を次にご紹介します: Benchling は、科学者が R&D を加速するのをサポートし、科学データの一元化、チーム間のコラボレーション、インサイトへのアクセスを容易にしています。Benchling の Head of AI Agents である Nicholas Larus-Stone 氏は次のように述べています。「Benchling AI を利用する科学者は、現在取り組んでいる研究対象について質問することで、Benchling に存在する自らの組織内データと公開文献の両方に基づいた回答を得ることができます。その結果、より包括的な科学的知見が得られ、仮説生成も適切に行われます。当社は Amazon Bedrock AgentCore の Web Search ツールを使用しているため、お客様はセキュアで統制された環境を使用して、データ管理方法に妥協することなく、質の高い公開データをワークフローで利用できます」。 Gen Digital は、消費者および小規模企業向けのサイバーセキュリティをリードしており、ウイルス対策、マルウェア対策、ID およびプライバシー保護、仮想プライベートネットワーク (VPN)、クラウドバックアップを提供しています。Gen Digital の Senior Director of AI & Innovation である Iskander Sanchez-Rola 氏は次のように述べています。「Amazon Bedrock AgentCore の Web Search ツールを活用することで、Norton Revamp は、現在の世の中の動きに基づく最新かつ的確なコンテンツアイデアにより、プロフェッショナルがオンラインでの評判を築くのを支援します。当社が最も高く評価しているのは、AWS が独自の検索インデックスを使用し、信頼できる AWS 環境内にクエリを保持する点です」。 その他のお客様事例については、「 Amazon Bedrock Customers 」にアクセスしてください。 今すぐご利用いただけます Amazon Bedrock AgentCore での Web Search は、米国東部 (バージニア北部) リージョンで本日より一般提供が開始されます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 Bedrock AgentCore の Web 検索は、初期費用なしですぐに使い始めることができます。料金体系はシンプルで、使用量に基づいています。エージェントが Web 検索に送信する検索クエリの数に応じて料金が発生します。Web 検索の料金は、1,000 クエリあたり 7 ドルです。AWS の新規のお客様は、最大 200 ドルの無料利用枠クレジットもご利用いただけます。詳細については、 Amazon Bedrock AgentCore の料金 ページをご覧ください。 Amazon Bedrock AgentCore コンソール でお試しいただき、 AWS re:Post for Amazon Bedrock AgentCore 宛てに、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

本記事は 2026 年 6 月 18 日に公開された Kyle Seaman、Alex Jia による “ Introducing automations in Kiro Web ” を翻訳したものです。 仕事の中には、決まった間隔で繰り返しやってくるものがあります。依存関係は週を追うごとに最新の状態から取り残されていき、ドキュメントはマージのたびに少しずつ遅れをとり、サービス間の API コントラクトは静かに食い違いを広げ、やがてステージングで何かが壊れます。同じことが巡ってくるたびに、同じファイルを開き、同じ diff を読み、同じような修正を書くことになります。 本日（2026 年 6 月 18 日）、Kiro Web にクラウドで動作する Automations 機能を追加しました。これにより、こうした繰り返しタスクの自動化を Kiro に任せられるようになります。Automations は自律型エージェントによって管理されます。Kiro は実行ごとにサンドボックス内で autonomous セッションを作成し、完了すると自動的にプルリクエストをオープンします。 仕組み Kiro Web の Automations に移動し、繰り返しタスクに名前を付けて、対象のリポジトリを GitHub または GitLab（あるいはその両方）から選びます。あとは実行したい内容を記述し、スケジュールを設定するだけです。 1 つの automation につき最大 5 つのスケジュールを追加できます。Daily や Weekly のような組み込みオプションから選ぶか、より細かい指定をしたい場合は cron 式を記述します。スケジュールの実行時刻になると、Kiro はクラウドサンドボックスを立ち上げ、リポジトリをクローンし、作業を実行して、変更内容を含むプルリクエストをオープンします。各実行は独立したサンドボックスを持つセッションであり、他のセッションやローカル環境から隔離されています。 Automations がプルリクエストをオープンするので、作業が完了したらレビューするだけです。 作成した automation はいつでも編集できます。スケジュールを変更したり、リポジトリを更新したり、実行内容を書き直したりできます。変更は次回のスケジュール実行に適用されます。automation を削除せずに無効化することもでき、準備ができたら再度有効化できます。 自動化できること main ブランチで変更されたコードと既存のドキュメントの間にあるギャップを見つけます。Kiro は毎朝、古くなった部分をチェックし、更新が必要なものがあれば PR をオープンします。 今週変更されたファイルのうち、対応するテストカバレッジがないものを確認します。Kiro は毎日、テストでカバーされていないパスを探し、見つかった場合は自動生成したテストを含む PR をオープンします。 コードベースに長く居座っている古い TODO や FIXME をスキャンします。毎週月曜日、Kiro が対応できるものを片付け、レビュー用に PR をオープンします。 今すぐ始めましょう すでに繰り返し発生している作業があれば今すぐ試してみてください。毎週月曜日に実行しているチェック、数日おきに見つけている食い違い、後回しにし続けている依存関係の整理などです。Kiro Web の Automations に移動して 1 つ設定し、走らせてみましょう。最初の実行は、次回のスケジュール時刻に開始されます。使い心地は、アプリ内の Feedback アイコンまたは GitHub からお知らせください。 Automations は現在、Pro、Pro+、Pro Max、Power プランのサブスクライバー向けに、Kiro Web で利用可能です。組織で AWS IAM Identity Center を使用している場合、automation を作成する前に管理者が Kiro Web へのアクセスを有効化する必要があります。 翻訳は Solutions Architect の吉村が担当いたしました。

2026 年 6 月 17 日、 AWS Transform の新機能である AWS Transform – 継続的モダナイズ (プレビュー) を発表しました。これは、技術的負債の継続的かつ自律的な分析と是正を大規模に可能にする機能です。AWS Transform は既に、企業がデータセンターからの移行、メインフレームおよび Windows アプリケーションのモダナイズ、および Java バージョンのアップグレード、非推奨フレームワークの置き換え、サポート終了前の AWS Lambda ランタイムの更新といった、差別化につながらないソフトウェアメンテナンス作業の処理をサポートしています。この新しいエクスペリエンスは、これらの機能をさらに強化するものです。お客様は、数千のリポジトリにわたるコードベースの状態、優先順位付けされた検出結果、および修正を行うプルリクエストを完全に可視化できます。 エンジニアリング組織は通常、IT 予算の最大 30% を消費します。お客様は、依存関係の問題を検出するツール、脆弱性を検出するツール、コード品質を管理するツールといった個別のツールを組み合わせて使用しています。しかし、既存のツールでは、技術的負債を継続的かつ大規模に検出、優先順位付け、および是正することはできません。その結果、アプリケーションごとの手動サイクルが発生し、エンジニアリングのキャパシティが消耗します。リーダーは、現実と乖離しており、リグレッションを隠蔽する、チームが自己申告する状況に頼らざるを得ません。AI 支援開発はこれをさらに悪化させます。すなわち、コーディングエージェントが変更のペースを加速させるにつれて、技術的負債はデベロッパーが追いつけないほどの速さで蓄積されます。お客様は、継続的、自律的、大規模に技術的負債を検出し、優先順位付けして、是正する機能を必要としています。 継続的分析 可視性の課題に対処するため、AWS Transform のこの新機能は、設定可能なベースラインに照らしてコードリポジトリを自動的にスキャンし、数週間ではなく数時間で検出結果を生成します。AWS Transform – 継続的モダナイズには、サポート終了の依存関係、非推奨となったフレームワーク、および他の一般的な技術的負債の原因を検出するための、すぐに使用できるポリシーが含まれています。また、組織に固有の独自の是正パターン (承認済みライブラリ、社内コーディング標準、プラットフォームチームが既に強制適用している技術的負債に関するポリシーなど) でこれらを拡張することもできます。例えば、チームが社内ライブラリを非推奨にした場合や、特定のログ記録パターンを推奨している場合は、それをポリシーとしてコード化し、すべてのリポジトリで継続的に実行できます。 定期的な手動作業とは異なり、継続的な分析はコードから直接、グラウンドトゥルースを提供します。リポジトリがベースラインから遅れた場合、チームがどのように対処することを選択するかにかかわらず、どのコンポーネントがどの程度遅れているのかを即座に把握できます。これにより、状況確認や手動でのコンプライアンス追跡が不要になり、プラットフォームチームは常に、最新の技術的負債の状況を把握できます。 大規模な自律的是正 検出結果を特定して優先順位を付けたら、影響を受けるリポジトリについてプルリクエストを自動的に生成する自律的な是正を設定できます。この新しい AWS Transform 機能は、Java バージョンのアップグレード、SDK の移行、ライブラリの更新などの一般的なシナリオに対応する、すぐに使用できる是正変換を提供します。また、組織固有のパターンに合わせてカスタム変換を作成することもできます。 是正を実行すると、継続的モダナイズ機能によって影響を受ける各リポジトリについてプルリクエストが作成され、次のようなメッセージで担当チームに通知が届きます:「このリポジトリは、この依存関係に関する組織のベースラインに遅れています。この問題を解決する PR はこちらです」。 チームは PR を確認してマージするか、または独自のアプローチを使用して是正することを選択できます。いずれの場合も、継続的分析によって修正が適用されたタイミングが検出され、手動での確認を必要とすることなく、グラウンドトゥルースが得られます。 AWS Transform – 継続的モダナイズは、 AWS セキュリティエージェント と統合し、ソースコードレベルでセキュリティの脆弱性を検出および是正します。そのため、セキュリティに関する検出結果は、他の技術的負債と同じ優先順位付けされたリストとプルリクエストのワークフローに反映されます。 試してみましょう 私はまず、AWS Transform のウェブアプリケーションにアクセスしました。ダッシュボードでは、組織のリポジトリの概要と、設定したベースラインに対する現在のステータスを確認できます。 最初に、ソース管理システムを接続し、指定したポリシーに基づく分析を開始しました。数時間以内に、リポジトリ全体に対する分析の検出結果が返され、どのリポジトリがベースラインからどの程度遅れているのかが示されました。重大度、影響を受けるファイルの数、検出された特定の技術的負債のパターンを確認できました。 ここから、優先度の高い検出結果のグループを選択し、是正キャンペーンを開始しました。AWS Transform – 継続的モダナイズは、影響を受ける各リポジトリについてプルリクエストを生成しました。キャンペーンの進捗状況をリアルタイムでモニタリングし、作成された PR、マージされた PR、コンプライアンス準拠状態に戻ったリポジトリを確認できました。 画像 1: AWS Transform – 継続的モダナイズのダッシュボード。接続されているすべてのリポジトリにおける技術的負債に関する検出結果のポートフォリオの概要が表示されています。 画像 2: 詳細な検出結果ビュー。個々の技術的負債の項目が、重大度、カテゴリ、リポジトリごとに一覧表示されており、利用可能な是正オプションも表示されています。 画像 3: ソースビュー。継続的モダナイズが分析のために追跡している、GitHub およびローカル環境の接続済みリポジトリが表示されています。 より迅速にモダナイズする方法 これらの機能は、コードモダナイズに対する 2 つの異なるアプローチをサポートします。継続モードでは、ベースラインの進化に合わせてコードベースを最新の状態に保つために、継続的モダナイズを使用できます。これは、ライブラリのアップグレード、セキュリティパッチの適用、組織全体でのコーディング標準の強制適用といった日常業務であるとお考えください。 あるフレームワークから別のフレームワークへの移行や、数百のアプリケーションにわたる主要なランタイムバージョンのアップグレードなど、大規模なモダナイズプロジェクトには、キャンペーンモードを使用して、ターゲットを絞ったプロジェクトベースのモダナイズを実施できます。AWS Transform カスタムは、これらの大規模な取り組みのための柔軟な基本機能を提供し続けます。AWS Transform – 継続的モダナイズは、プラットフォームチームが日々管理する、繰り返し発生する大量の作業のために特別に設計されています。 今すぐご利用いただけます AWS Transform – 継続的モダナイズ (プレビュー) は本日よりご利用いただけます。AWS Transform ウェブアプリケーション、AWS Transform Kiro パワー、または既存のコーディングエージェントと統合するための MCP とスキルを通じて、利用を開始できます。詳細については、 AWS Transform のドキュメント にアクセスしてください。 原文は こちら です。

2026 年 6 月 17 日、プレビューで提供が開始となった AWS DevOps エージェント に新しいリリース管理機能が追加されました。AWS DevOps エージェントは、AWS、マルチクラウド、オンプレミス環境にわたってソフトウェアの変更と運用をカバーする、いつでも利用可能なチームメンバーです。DevOps の慣行は、ソフトウェアの変更と運用を円滑でますます自律的にすることを目的としています。AWS DevOps エージェントは、お客様の環境、サービス、それらの依存関係、本番での動作の深い理解を活用することで、変更と運用の両方においてこの目的を実現します。デプロイ後の運用については既に一般提供されており、インシデントを自律的に調査し、根本原因分析と緩和ステップを提供して、問題の再発を防止するための的確なレコメンデーションを提示します。今回のプレビューでは、AWS DevOps エージェントに、コード変更のリリース準備状況レビューと自律リリーステストが追加されました。これらの新機能は、DevOps エージェントに対して指定する自然言語標準に照らしてあらゆる変更を検証し、本番のような環境で変更に固有のテストを実行します。AWS DevOps エージェントは、コードの作成から本番への移行まで、チームをサポートし、レビュー担当者とテスターが AI 生成コードの量に対応するのをサポートするようになりました。 開発チームが AI コーディングツールを採用するようになる中で、デリバリーパイプラインを通過するプルリクエストの量は、レビューおよびテストプロセスが処理できる速度を上回って増加しています。チームが対応に追われる状況では、徹底した検証なしでレビューが承認され、テスト環境が本番からドリフトしてしまいます。コーディングエージェントが生み出す価値は、エンドユーザーに届くことなく、レビューキューで待機状態のままになります。同時に、AI モデルは、人間のレビュー担当者が時間的プレッシャーの中で見落とす可能性のある、機能面やセキュリティ面の問題を検出する能力をますます強化しており、迅速かつ安全なデリバリーは、トレードオフではなく要件となっています。 リリース準備状況レビュー機能は、あらゆるコード変更を、本番の要件、依存関係の安全性、および DevOps エージェントに提供する標準とベストプラクティスに照らして評価します。エージェントは、他のサービスに影響を及ぼす可能性のあるリポジトリ間の依存関係リスクの確認、AWS Well-Architected フレームワークのベストプラクティスに照らしたアクセスコントロールの変更の確認、およびお客様が定義した標準への準拠の確認を行います。標準が指定されていない場合は、エージェントは一般的なベストプラクティスを適用します。また、レビューの一環として、エージェントは、AWS マネージドの隔離された環境でソフトウェアを実行して、軽量なユーザージャーニーテストを実行し、変更がパイプラインに入る前に、ソフトウェアがビルドされ、実行でき、基本的な機能チェックに合格することを検証します。検出結果は AWS DevOps エージェントコンソールと、GitHub または GitLab のプルリクエストに対するコメントとして表示されます。さらに、Kiro パワーまたは Claude Code プラグインを通じて IDE から直接レビューを呼び出すこともできるため、デベロッパーは、変更がバージョンコントロールにコミットされる前に、依存関係のリスク、標準に対する違反、アクセスコントロールの問題を特定して修正できます。 自律リリーステスト機能はさらに一歩進んで、変更がマージされる前に、お客様がプロビジョニングした本番のような環境において、ウェブアプリケーションおよび API ベースのアプリケーション向けに、変更固有のテストプランを生成して実行します。エージェントは、静的なテストスイートを実行するのではなく、変更内容を推論し、それに合わせたテストを構築します。これにより、手動で管理するテストプランでは想定できない可能性のある機能の正しさ、動作のリグレッション、統合シナリオをカバーします。テスト実行ごとに、メトリクス、ログ、トレース、実行の概要などの構造化されたアーティファクトが生成され、レビュー担当者は、テスト内容と結果の一貫した記録を得ることができます。 AWS DevOps エージェントのリリース管理の開始方法 このチュートリアルでは、AWS DevOps エージェントウェブアプリケーションを使用してオンデマンドのリリース準備状況レビューを実行する方法を説明します。開始する前に、少なくとも 1 つの GitHub または GitLab リポジトリがエージェントスペースに接続されていることを確認してください。リポジトリが接続されると、AWS DevOps エージェントはコードをインデックス化し、リポジトリ間およびクラウドの依存関係のナレッジグラフを構築します。 ウェブアプリケーションを開くには、 AWS DevOps エージェントコンソール に移動し、 [エージェントスペース] を選択して、 [ウェブアプリケーション] タブを選択します。ウェブアプリケーションを開くには、 [オペレーターアクセス] を選択します。 標準が設定されていない場合、エージェントは一般的なベストプラクティスを適用します。レビューを社内基準に合わせてカスタマイズするには、 [ナレッジ] に移動し、 [手順] タブを選択します。指示セットの一覧が表示されます。各指示セットは、特定のエージェントまたはタスクにスコープが設定されています。本番に向けた準備状況を確認するための変更レビューに関する指示を編集するには、 [リリース準備状況レビュー] の横にある [表示] を選択します。社内標準は平易な言葉で記述してください。例えば、暗号化やネットワークアクセスルールに関するインフラストラクチャおよびデータ標準、ログ記録やオブザーバビリティの要件など、ブロックせずに警告を発するベストプラクティス、より高度なセキュリティ対策が必要なアプリケーションやリソースを識別する機密データ分類に関するベストプラクティスを定義できます。スペース内のすべてのエージェントに指示を適用するには、 [すべてのエージェント] の横にある [表示] を選択します。 リリース準備状況レビューは、接続されているリポジトリにプルリクエストを送信する、またはチャットインターフェイスでオンデマンドクエリを入力する、という 2 つの方法でトリガーできます。チャットからオンデマンドレビューを実行するには、 [新しいチャット] を選択し、次のようなリクエストを入力します: Perform a production risk analysis on my repository branch エージェントは、分析対象のリポジトリとブランチをたずねます。ブランチ名、プルリクエスト番号、またはコミット SHA を提供できます。選択を確認すると、エージェントはレビューをキューに入れ、インフラストラクチャへの影響、設定の変更、潜在的な問題など、変更を分析して、本番のリスクがないかを確認します。 レビューが完了したら、チャットで直接フォローアップの質問をして、検出結果をより詳細に確認できます。例えば、どの下流のコンシューマーが変更の影響を受けるのかについて質問すると、エージェントは、リポジトリ内およびリポジトリ間の、動作しなくなるコンシューマーの構造化された内訳、影響を受ける特定のファイルと行番号、デプロイ前に問題を解決するための推奨ステップを返します。 レビューリクエストを送信したら、左側のナビゲーションペインの [変更] に移動します。 [提案された変更] テーブルには、実行された各レビューが表示されます。これには、提案された変更の説明、ソース、カテゴリ、ステータス、作成日時が含まれます。カテゴリまたはステータスでフィルタリングして特定のレビューを検索したり、検索バーを使用して名前で検索したりできます。いずれかのエントリを選択すると、完全な実行の詳細が開きます。 [タイムライン] タブには、エージェントのステップバイステップの推論プロセスが表示されます。これには、呼び出したツール、参照した依存関係、各ステップで行った観察が含まれます。各エントリにはタイムスタンプが付与されているため、エージェントが変更をどのように理解し、結論に至ったのかについての完全な記録が得られます。 [レポート] タブを選択すると、最終的なレコメンデーションが表示されます。レポートが開くと、推奨されるアクション、検出された重大な問題の数、コミットのリビジョン、変更されたファイルの数を示す概要ヘッダーが表示されます。推奨されるアクションは、 [ブロック] 、 [注意して続行] 、または [安全にリリース可能] のいずれかです。 概要ヘッダーの下にある [分析] セクションでは、レコメンデーションが作成された理由が説明されており、具体的なリスクと、エージェントが結論を裏付けるために見つけた証拠が示されます。 [問題] セクションでは、各検出結果が重要度別に一覧表示され、変更を進める前に対処する必要のある事項が優先順位付けされた形で確認できます。 [レコメンデーション] セクションでは、デベロッパーが各問題を解決するために実行できる具体的かつ実用的なステップが示されます。最後に、 [変更] セクションでは、変更された各ファイルが、変更のタイプ、該当するカテゴリ、および変更内容の説明とともに一覧表示されるため、レビュー担当者は、マージ前に変更内容を完全に把握できます。 また、チャットインターフェイスから直接、自律リリーステスト機能を呼び出すこともできます。ウェブアプリケーションまたは API ベースのアプリケーションで自律リリーステストを実行するには、 [新規チャット] を選択し、次のようなクエリを入力します: Run a release test on my application deployed at [application URL] エージェントは変更固有のテストプランを生成し、プロビジョニングされた環境で実行します。結果は [変更] に表示され、実行ステップとテスト内容の構造化された概要を確認できます。 今すぐ始めましょう AWS DevOps エージェントのリリース準備状況レビュー機能と自律リリーステスト機能はプレビューで提供されています。米国東部 (バージニア北部) リージョンでは、これらの機能はプレビュー期間中、追加料金なしでご利用いただけます。AWS DevOps エージェントの他の機能の料金に関する情報については、 AWS DevOps エージェントの料金 ページにアクセスしてください。 設定の詳細については、「 AWS DevOps エージェントユーザーガイド 」にアクセスしてください。 – Esra 原文は こちら です。

Amazon Elastic Container Service (Amazon ECS) サービス自動スケーリング は、包括的なスケーリングポリシーを使用して、ワークロードの需要に合わせてタスク数を自動的に調整します。これには、繰り返されるトラフィックパターンのための予測スケーリング、計画されたイベントのためのスケジュールされたスケーリング、およびリアルタイムメトリクスに基づいて動的にスケールするターゲット追跡スケーリングが含まれます。 予測スケーリング (自動) や スケジュールされたスケーリング (お客様が定義) を使用したプロアクティブなスケーリングや、スケールする基準となるターゲットを指定するだけの ターゲット追跡 を使用したリアクティブなスケーリングを選択できます。Amazon ECS サービス自動スケーリングは、 Amazon CloudWatch メトリクス (平均 CPU/メモリ使用率、ターゲットあたりのリクエスト数、キューの深さなどのカスタムメトリクス) や、高度な機械学習 (ML) アルゴリズムを使用した需要急増の予測に基づいて、ECS サービスのタスク数を調整します。 2026 年 6 月 18 日のリリースにより、高解像度 (20 秒間隔) メトリクスとメトリクス発行の最適化がサポートされ、Amazon ECS サービス自動スケーリングは、負荷の変化をより迅速に検出して、これに対応できるようになりました。AWS のベンチマーキングテストでは、スケールアウトがトリガーされるまでの時間が 363 秒から 86 秒に短縮され (76% の高速化、4.2 倍)、新しいタスクのスケールとプロビジョニングにかかる合計時間が 386 秒から 109 秒に短縮されました (72% の高速化、3.5 倍) このリリースは、アプリケーションに 3 つの重要な利点をもたらします: パフォーマンスの改善と信頼性の向上 : スケーリングが高速化することで、アプリケーションは需要の急増により迅速に対応できるようになり、エンドユーザーのために、急増時のレイテンシーや障害を低減します。 妥協のない適切なサイジング : 事前に余分なキャパシティを確保しておかなくても、トラフィックの急増に対処するのに十分高速なスケールアウトが可能になったため、ワークロードによっては、ベースラインのタスク数を削減できます。これにより、アプリケーションのパフォーマンスと可用性を維持しながら、コンピューティングコストを直接削減できます。 よりシンプルなスケーリング設定 : 高解像度メトリクスを使用したターゲット追跡により、以前はカスタムスケーリング設定 (ステップスケーリングポリシーの使用など) を必要としていた、積極的なスケーリング動作が可能になります。設定を 1 つ変更するだけで、カスタムエンジニアリング作業を代替できます。 仕組み ECS の高速化されたサービス自動スケーリングを使用するには、まず ECS サービスのために高解像度メトリクスを有効にし、次に高解像度メトリクスを使用するターゲット追跡スケーリングポリシーを設定します。ECS の高速化されたサービスオートスケーリングは、 AWS Fargate 、 ECS マネージドインスタンス 、 Amazon Elastic Compute Cloud (Amazon EC2) といった ECS におけるすべてのコンピューティングオプションで利用可能です。これらのメトリクスは、 Amazon ECS コンソール で、または AWS SDK およびツール や AWS CloudFormation を使用して ECS サービスを作成または更新する際に有効にすることができます。 コンソールでサービスを作成する際には、 [モニタリング設定] セクションで 20 秒間隔のメトリクスを追加してください。標準の解像度 (60 秒間隔) は無料ですが、これらのメトリクスには CloudWatch の追加料金が発生します。 [サービス自動スケーリング] セクションで [サービス自動スケーリングを使用] にチェックを入れ、スケーリングポリシータイプとして [ターゲット追跡] を選択します。これにより、リアルタイムデータを使用して、サービスが需要に基づいて実行するタスク数をスケールできます。 その後、ターゲット追跡の [スケーリングポリシータイプ] を選択します。新しいメトリクスとして、 ECSServiceAverageCPUUtilizationHighResolution または ECSServiceAverageMemoryUtilizationHighResolution を選択できます。 これで完了です – ECS サービスは、自動スケーリングのために高解像度メトリクスを使用するようになります。 既存の ECS サービスをより高速な自動スケーリングを使用するように更新するには、まず [サービスを更新] を介して高解像度メトリクスを設定する必要があります。デプロイが完了すると、サービスは高解像度メトリクスを生成するようになります。その後、サービスの詳細の [サービスと自動スケーリング] タブに移動し、より高解像度のメトリクスを使用するようにスケーリングポリシーを更新できます。 必要な手順はこれだけです。これで、ECS サービスは 20 秒間隔でスケーリングに関する決定を評価するようになります。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、Application Auto Scaling を通じて ECS サービスで新しいメトリクスを有効にすることもできます。詳細については、 より高速な自動スケーリングに関するドキュメント にアクセスしてください。 今すぐご利用いただけます Amazon ECS 向けの、高解像度メトリクスを使用したより高速なサービス自動スケーリングは、6 月 18 日よりご利用いただけます。機能自体に追加料金はかかりませんが、高解像度 CloudWatch メトリクスについては新しい料金ディメンションが導入されます。詳細については、「 CloudWatch の料金 」ページをご覧ください。 ぜひ今すぐお試しいただき、 AWS re:Post for ECS 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。6 月 15 日に Kiro 公式グッズストアが shop.kiro.dev にオープンしたのをご存じでしょうか？ アパレルや小物、アクセサリーの 15 アイテムがそろい、ラバーダックの代わりに Kiro のぬいぐるみでデバッグする、なんて楽しみ方もできそうです。Kiro を「使う」だけでなく「身にまとう」選択肢も生まれた今週も注目のアップデートをまとめています。 そしてAWS Summit Japan の開催（6 月 25 – 26 日）が近づいてまいりました！ 登録がまだの方は こちら から登録しぜひ来場ください！ それでは 6月 1 5日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 Kiro Pro Max の紹介 (月額 $100): クレジットは多く、コストの迷いは少なく 」 Kiro に、月額 $100 で月 5,000 クレジットを利用できる新プラン「Kiro Pro Max」が加わりました。月額 $40 の Pro+ と月額 $200 の Power の間を埋めるプランで、Claude Opus 4.8 や Sonnet 4.6、Auto を含むすべてのプレミアムモデル（地域ごとの提供状況に準じます）と、スペック・カスタムサブエージェント・Powers・フック・CLI といった Power と同等の機能セットを利用できます。価値は、料金の予測しやすさにあります。Pro+ のクレジットを常に大きく超過していたり、超過料金が $60〜70 に達していたりする開発者にとって、Pro Max は定額で余裕のある利用を実現します。1 日を通じて複数プロジェクトでコーディングやスペック実行、デバッグを行うような、業務の中核として Kiro を使う開発者に向いた選択肢です。6 月 11 日からアカウント設定画面で切り替えでき、月の途中のアップグレードは差額が日割り計算となります。 ブログ記事「 Kiro Web の新機能: Spec、GitLab、その他のアップデート 」 ブラウザから使える Kiro Web に、開発者から要望の多かった 2 つの機能が加わりました。構造化されたスペックワークフローをブラウザで実行できるようになり、さらに GitHub に加えて GitLab に対応しました。1 つのセッションで GitLab と GitHub のリポジトリを混在させることもできます。スペックは、コードを書く前に「何を作るか」「どう動くべきか」「何を含めないか」を Kiro と定義する進め方です。Kiro が要件・設計・タスクリストのドキュメントを生成し、ブラウザ上でレビューしながら磨き上げ、準備が整ったらサンドボックス内でタスクを実行してプルリクエストを開けます。GitLab はパーソナルアクセストークンで接続でき、Kiro がプロジェクトをクローンして変更を加え、マージリクエストを開きます。共有ライブラリとそれに依存するサービスが別々のプロバイダーにある場合でも、横断的に変更を調整できる点が便利です。Kiro Web は Pro、Pro+、Pro Max、Power の各サブスクライバー向けにプレビュー提供中です。 ブログ記事「 Kiro for iOS のご紹介 」 本格的な開発業務に対応するネイティブ iOS アプリとして Kiro が提供開始されました。スマートフォンから直接、Kiro セッションの起動・監視・軌道修正・対話ができ、ノート PC を開かなくても、差分のレビューや変更の承認といった作業を進められます。chat、spec、autonomous の 3 つのモードを選べます。アプリを開くとクラウドセッションのライブな状態が読み込まれ、エージェントの応答がリアルタイムにストリーミング表示されます。差分はファイルヘッダー付きのネイティブな差分カードとして描画されるため、小さな画面でもコードを読みやすくしています。Kiro Web や CLI、IDE で始めたセッションは、同じ ID・設定・モデルで自動的に同期されるため、接点をまたいでも作業が途切れません。Kiro Pro、Pro+、Pro Max、Power のお客様向けに、早期アクセスのリクエスト順に案内されます。iOS 26 以降が必要です。 ブログ記事「 AWS WAF に AI トラフィック収益化機能が追加され、コンテンツ所有者が AI ボットにコンテンツへのアクセス料金を請求することが可能に 」 AWS WAF の内容ですが運用の観点で有用です。AI ボットやエージェントが保護対象の Web コンテンツへアクセスした際に課金できる「AI トラフィック収益化」機能が追加されました。オリジンインフラの変更やアプリケーションコードの作成なしに、コンテンツパス・ボットカテゴリ・検証階層ごとにリクエスト単位の料金を AWS WAF コンソールから設定できます。背景には、AI ボットが Web トラフィックの 50% 以上を占めるケースがある一方、従来の検索エンジンと違い元サイトへの送客がほとんどないという課題があります。仕組みは AWS WAF Bot Control の新機能として提供され、GptBot や Claude-Web、Perplexity-Bot を含む 650 種類以上の AI ボットを分類し、検証済み・未検証の階層を割り当てます。収益化ルールに一致したリクエストには HTTP 402 応答を返し、機械間決済向けの x402 オープンプロトコルで価格情報を提示します。決済・検証フローは Coinbase の x402 Facilitator が提供し、支払いはステーブルコインで自社管理のウォレットに回収できます。Amazon CloudFront のお客様であれば、標準の AWS WAF 料金を超える追加料金なしで利用できます（収益化アクションは CloudFront に関連付けた Web ACL でのみ対応）。 ブログ記事「 VR × モーションキャプチャ × AI でパデルフォームを可視化する ── AWS Builders’ Fair 展示のご紹介 」 AWS Summit Japan 2026 の AWS Builders’ Fair で展示される、パデルフォーム分析アプリを紹介する記事です。VR ヘッドセット（Meta Quest）、モーションキャプチャ（HaritoraX）、カメラによる骨格推定（MoveNet）を組み合わせ、バーチャル空間でのパデルの動作を計測し、DTW アルゴリズムでトッププレーヤーのフォームと比較して、5 指標のスコアカードと Amazon Bedrock による改善アドバイスを返します。技術的な見どころは、AI 駆動の 3D 開発です。3D 空間のプログラミングは従来、空間座標やベクトル演算など専門性が高い領域でしたが、本プロジェクトでは Godot Engine 上のロジックを Kiro を使った自然言語プログラミングで実装しています。「ボールを放物線で飛ばしてラケットの当たり判定を追加して」といった指示で 3D の挙動を構築でき、3D/VR 開発の経験が浅くても複雑なアプリを素早く試作できることを示しています。クラウド側は Amazon Bedrock や AWS Lambda、Amazon S3、Amazon DynamoDB、AWS IoT Greengrass などで構成され、このコア（モーションキャプチャ × AI 比較分析 × リアルタイムフィードバック）はスポーツ全般やリハビリ、製造業の技能伝承など幅広い分野に応用できると述べられています。 ブログ記事「 AI が Arm SoC 間で組み込みコードベースを移行を支援 」 Arm SoC（System on a Chip）間での組み込みコードベース移行を支援する新しい Kiro Power「Arm SoC Migration Power」が、Arm と AWS の共同開発として紹介されました。Kiro は AWS の AI 搭載 IDE で、Powers は繰り返し発生する課題にドメイン固有のガイダンスを提供する仕組みです。変更を自動化するのではなく、アーキテクチャの違いや制約を明示し、エンジニアの判断を支援します。複数の Arm プラットフォームでコンパイル・実行できるコードでも、CPU マイクロアーキテクチャやメモリ階層、SIMD サポートの違いにより、特に安全性に関わるシステムでは挙動が変わることがあります。この Power は移行を発見・分析・計画・実装・検証のガイド付きワークフローとして構造化し、こうした違いを早い段階で明示します。記事では自動車産業を例に、AWS Graviton 搭載 EC2 での開発から、低コストな Arm ハードウェアでのプロトタイプ、NXP i.MX 8M Plus のような車載 SoC への移行という 3 段階を解説しています。Arm の数百の Learning Paths を参照できる Arm MCP Server の機能も含まれます。  イベント開催レポート 「 日立グループ合同「AI-DLC Unicorn Gym」開催レポート ── 日立 AI駆動開発のキーマンに聞く、グループ展開への道筋 」 2026 年 5 月 18〜20 日に日立のオフィスで開催された「日立グループ合同 AI-DLC Unicorn Gym」の開催レポートと、推進キーマンへのインタビューです。AI-DLC は、AI を要件定義から実装・テストまでの開発ライフサイクル全体に組み込みつつ、人間が主導権を握る（Human-in-the-Loop）開発手法で、3 日間で体験するワークショップが Unicorn Gym です。日立製作所・日立ハイテク・日立産業制御ソリューションズの 3 社・8 チーム・52 名が、実際の業務テーマを持ち寄って参加しました。全体満足度は 5 点満点中 4.67、回答者の 90% が開発工数の「70% 以上の削減」を体感したと報告されています。インタビューでは、「動くものをデプロイするまでの速さ」と「本番リリースまでの工数」は別物であり、日立が積み上げてきた品質保証の工程を AI-DLC の進め方に織り込んだ「日立版 AI-DLC」を作る必要があるという議論が語られています。AWS が GitHub で公開する AI-DLC Workflows をベースに汎用版を整え、各事業部が Fork してカスタマイズする構想や、グループ横断の AI 駆動開発ワーキンググループ立ち上げの方針も紹介されています。 「 【開催報告】通信事業者向けカスタム AI エージェントワークショップ開催しました！ ( 2026 年 4 月 23 日 ) – ネットワーク開発・運用を AI エージェントで変える 」 2026 年 4 月 23 日に AWS Startup Loft Tokyo で開催された、通信事業者向けカスタム AI エージェントワークショップの開催レポートです。NTTドコモ、KDDI、ソフトバンク、楽天モバイルに NTT、ソニーを加えた事業者から 121 名・6 グループが参加し、Autonomous Network 実現に向けた参考アーキテクチャや事例、Strands Agents・Amazon Bedrock AgentCore のハンズオン、ユースケース議論が行われました。事例では、NTTドコモが AI エージェントと GitOps を組み合わせ、5G コアネットワークの設計・構築のリードタイムを約 80% 短縮した取り組みや、NTTドコモビジネスがルータ連携 AI エージェントで設定作業の所要日数を 6 日から 1 日に短縮した事例が共有されました。ハンズオンでは、数行で実装できる Strands Agents でエージェントを作り、AgentCore Memory と AgentCore Runtime で永続的なメモリとサーバーレスのスケールを備えた本番対応構成へ発展させる流れを体験。ユースケース議論では、業務領域ごとに専門エージェントを分ける発想、既存社内ツールとの接続、AI に任せきれない判断ポイントの設計が、各社共通の論点として浮かび上がりました。 サービスアップデート Amazon Bedrock Managed Knowledge Base が一般提供開始 フルマネージドの RAG サービス Amazon Bedrock Managed Knowledge Base が一般提供を開始しました。ベクトルデータベースやデータパイプライン、検索インフラを自前で管理せずに、企業データに根ざした本番品質の AI エージェントを構築できます。データの取り込みやストレージの最適化、高度な検索を自動で引き受けてくれるため、プロトタイプから本番へ素早く移行できます。Amazon S3、SharePoint、Confluence、Google Drive、OneDrive、Web Crawler の 6 種のコネクタに対応し、複雑なマルチホップの問い合わせにはクエリプランニング、暫定応答の評価、再ランキングを自動で組み合わせるエージェント型検索も使えます。東京リージョンを含むアジアパシフィック（シドニー、東京）、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（ダブリン、フランクフルト、ロンドン）、AWS GovCloud（米国西部）で利用できます。 Amazon Bedrock Guardrails がエージェント型 AI ワークフロー向けの新しい API を発表 Amazon Bedrock Guardrails が、エージェント型 AI アプリケーション向けの新しい InvokeGuardrailChecks API を発表しました。ガードレールのリソースを作らずに、ワークフローの好きな地点で個別のセーフガードを呼び出せます。エージェント型 AI は計画・ツール呼び出し・出力処理を繰り返し、1 リクエストで数十ステップに及ぶこともあり、各ステップでリスクの種類も変わるため、こうした細かい制御が役立ちます。リクエストごとにどのチェックを走らせるかを細かく選べ、重大度と信頼度のスコアが返るので、ブロック・通過・再試行・記録といったアクションを自前のしきい値で実装できます。コンテンツフィルター、プロンプト攻撃検出（脱獄・プロンプトインジェクション・プロンプト漏洩）、機密情報フィルターに対応し、ガードレール ID やバージョンの管理が不要なのも扱いやすい点です。東京リージョンを含むアジアパシフィック（東京、シドニー）、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（ロンドン、ストックホルム）で利用できます。 Amazon Bedrock Guardrails がシドニーで Automated Reasoning checks に対応 Amazon Bedrock Guardrails の Automated Reasoning checks が、新たにアジアパシフィック（シドニー）リージョンで利用できるようになりました。これは形式的検証（数学的な手法）で AI の出力を検証する機能で、大規模言語モデルの正しい応答を最大 99% の精度で見極められるとされています。サンプリングに頼る確率的なテストとは異なり、数学的な裏付けで応答を検証できるため、金融・ヘルスケア・法務といった規制の厳しい領域での要件対応を後押しします。本番デプロイ前の応答チェックやビジネスルール準拠の確認に使え、Amazon Bedrock コンソールまたは SDK から利用できます。既存の提供リージョンである米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（フランクフルト、アイルランド、パリ）に、今回シドニーが加わりました。 AgentCore harness が一般提供開始 Amazon Bedrock AgentCore の managed agent harness が一般提供を開始しました。モデルが「脳」なら、ハーネスは「体」にあたる管理レイヤーで、オーケストレーションループの実行、ツールの実行、コンテキストウィンドウの管理、ターンをまたぐ状態保持、障害復旧、セッション分離を引き受けます。コードを書く代わりに、使うモデル・呼び出すツール・従う指示を設定として宣言すれば、本番品質のエージェントが数分で立ち上がります。モデルとハーネスが分離されているため、セッションの途中でもコンテキストを失わずにモデルを切り替えられ（計画はあるモデル、コード生成は別のモデル、といった使い分けが可能）、独自のオーケストレーションが必要になれば CLI コマンド一つで Strands ベースのコードへエクスポートできます。AgentCore が利用できるすべての AWS 商用リージョンで使えます。 Amazon Bedrock AgentCore が本番環境のエージェントを継続的に改善する最適化機能を追加 Amazon Bedrock AgentCore が、本番環境のトレースをエージェントの継続的な改善につなげる最適化機能を発表しました。エラーを出さずダッシュボード上は正常に見える「サイレントな障害」も対象に、本番データから改善点を見つけられます。繰り返し起きる障害パターン（サイレントな障害を含む）を見つけて根本原因を説明し、影響の大きさで順位づけする「失敗インサイト」、ユーザーの意図でリクエストをまとめる「意図インサイト」、エージェントがタスクをこなす経路をまとめる「トラジェクトリインサイト」で、エージェントの挙動を数分で把握できます。さらに、実際の挙動に基づいてシステムプロンプトやツール記述の改善を根拠つきで提案し、バッチ評価や本番トラフィックを分割した A/B テストで効果を統計的に検証できます。AgentCore ランタイムだけでなく、AWS Lambda、Amazon EKS、AWS 以外の環境でも動作します。失敗・意図・トラジェクトリのインサイトは 13 の AWS リージョンでプレビュー、バッチ評価・レコメンデーション・A/B テストは 14 の AWS リージョンで一般提供されています。 Amazon Bedrock AgentCore がポリシーで Bedrock Guardrails をサポート AI エージェントの実行可能なアクションを制御する認可機能 AgentCore policy が、Bedrock Guardrails をサポートするようになりました。認可済みアクションの出力や、ゲートウェイ先のツール・エージェント・モデルへの入力をリアルタイムで評価します。プロンプトインジェクション攻撃や有害コンテンツ、機密情報の漏洩を、下流システムに到達する前に検出・ブロックでき、評価はエージェントのコードの外、AgentCore ゲートウェイの境界で行われます。既存の AgentCore ゲートウェイ環境でそのまま動き、新たなインフラは不要です。ポリシーは自然言語でも policy-as-code でも記述でき、評価は従量課金制です。東京リージョンを含むアジアパシフィック（東京、シドニー）、米国東部（バージニア北部）、欧州（ロンドン、ストックホルム）で利用できます。 AWS DevOps Agent がリリース管理機能を追加（プレビュー） AWS DevOps Agent が、リリース管理機能をプレビューで追加しました。これにより、このエージェントがデリバリーと運用の両方をまたいで支援するようになります。機能は 2 つです。コード生成時に変更を本番安全性の観点で評価する「リリースレディネスレビュー」は、内部標準からのドリフトや依存関係への影響、アクセス制御を確認し、リポジトリをまたいだ依存関係を地図化してコミット前に破壊的変更を検出します。「リリーステスト」は、Web や API ベースのアプリ向けにテスト計画を生成・実行し、回帰や UX の問題、統合の失敗を見つけます。コードリポジトリとパイプラインを AWS DevOps Agent space に接続すれば始められ、プレビュー期間中は追加費用なしで、米国東部（バージニア北部）リージョンで利用できます。 CLI v3 への早期アクセス Kiro CLI 2.8 で、Kiro V3 の早期アクセスプレビューが導入されました。kiro-cli –v3 でオプトインでき、新しいハーネスを既存の 2.x 環境と並行して試せます。オプトインするまで 2.x の設定はそのままです。V3 は、Kiro の IDE と Web を動かすのと同じ統合エージェントハーネス上に構築されており、ハーネスへの改善がすべての面に同時に届くようになります。ターミナルでのスペック駆動開発、ケイパビリティベースの権限モデル、独立したファイル形式を持つ強化されたフック、タグベースのエージェント設定が新たに加わりました。 Automations の提供開始 Kiro on the web で、繰り返し作業をスケジュール実行できる Automations が使えるようになりました。オートメーションを作り、タスクを記述して GitHub または GitLab のリポジトリを選び、スケジュールを設定すれば、決めた周期で Kiro が自前のサンドボックス内で自律的に実行します。各実行は独立したサンドボックスを立ち上げてリポジトリをクローンし、作業を進めて、完了するとプルリクエストを開きます。1 つのオートメーションにつき最大 5 つのスケジュールを設定でき、毎時・毎日といった組み込みオプションのほか cron 式も使えます。編集・無効化・削除はいつでも可能で、変更は次回の実行から反映されます。 Amazon S3 Vectors が 1 クエリあたり最大 10,000 件の類似検索結果に対応 Amazon S3 Vectors が、1 クエリあたりの類似検索結果（topK 最近傍）を最大 10,000 件まで返せるようになりました。従来の上限から 100 倍の拡大です。これにより、より大きく網羅的な候補セットを一度の検索で取得でき、再ランキングや集約、重複排除を組み込んだ多段階のリトリーバルパイプラインを組みやすくなります。結果は複数ページに分けて返るため、最初のページをすぐ処理しながら後続を取得することもできます。最初の 512KB 分の返却データは無料です。Amazon S3 Vectors が利用できるすべての AWS リージョンで使えます。 Amazon S3 Vectors が大規模ベクトルインデックスのクエリ料金を最大 80% 削減 Amazon S3 Vectors が、1,000 万を超えるベクトルを持つインデックスへのクエリで、データ処理料金を最大 80% 削減しました。新しい料金は自動で適用され、アプリケーション側の変更は必要ありません。大規模な AI、RAG、セマンティック検索のワークロードで類似検索のコストを抑えられるのが利点です。なお、クエリ性能を高めるために、ベクトルを複数のインデックスに分散させることは引き続き推奨されています。この料金は、Amazon S3 Vectors が利用できるすべての AWS リージョンで適用されます。 Amazon Quick が自律エージェント、マルチデータセット分析、刷新されたアクティビティフィードを発表 AI アシスタントの Amazon Quick が、自律エージェント、マルチデータセット分析、刷新されたアクティビティフィードの 3 つを発表しました。自律エージェントは、自然言語でタスクを記述し、ステップごとの承認から目標ベースの幅広い実行まで承認の粒度を選べて、停滞中の取引のフォローアップや発注書の処理などを継続的に自動化します。マルチデータセット分析では、Snowflake やリレーショナルデータベースなど複数のデータソースを、事前のデータ結合なしに自然言語で横断的に問い合わせでき、既存の権限を尊重します。刷新されたアクティビティフィードは会話型のインターフェースで、メールや Slack への返信、リクエストの承認をアプリを切り替えずに行えます。 Amazon Quick が Adobe、Figma、WhatsApp などの新しいコネクタで連携を拡大 Amazon Quick が新たに 16 のツールと連携できるようになり、それらの情報をもとにアプリを切り替えずにアクションを起こせます。追加されたのは Adobe、Figma、WhatsApp、Snowflake、Shopify、Smartsheet、Zapier、Dun & Bradstreet、Moody’s、ZoomInfo など、生産性・デザイン・分析・データ基盤・金融・コマース・コミュニケーションにまたがる各種ツールです。たとえば営業チームなら、Dun & Bradstreet でアカウント情報を補強し、Snowflake のデータと突き合わせ、Smartsheet でアウトリーチのタスクを管理する、という一連の流れを Quick から離れずに進められます。新しいツールは数分でワークスペースに追加でき、すぐ使い始められます。 セマンティック検索・文類似度向けの all-MiniLM-L12-v2 が Amazon SageMaker JumpStart で利用可能に Sentence Transformers の all-MiniLM-L12-v2 モデルが、Amazon SageMaker JumpStart で利用できるようになりました。文章や段落を 384 次元の密ベクトルに変換するモデルで、セマンティック検索、テキストクラスタリング、文類似度に向いています。コンパクトな構造で高速な推論と高い埋め込み品質を両立しており、情報検索やドキュメントクラスタリング、重複検出、言い換え識別といった本番ワークロードに適しています。SageMaker Studio の Models セクション、または SageMaker Python SDK から数クリックでデプロイでき、高品質なセマンティック検索アプリを AWS インフラ上に構築できます。 マルチモーダル推論・エージェント AI 向けの Ministral-3-14B-Instruct が Amazon SageMaker JumpStart で利用可能に Mistral AI の Ministral-3-14B-Instruct-2512 が、Amazon SageMaker JumpStart で利用できるようになりました。14B パラメータのコンパクトな構造で、エッジでのデプロイに最適化されています。テキストに加えて画像を分析して知見を返せるほか、ネイティブの関数呼び出しと JSON 出力によるエージェント機能を備え、日本語を含む数十言語の多言語理解に対応します。SageMaker Studio の Models セクション、または SageMaker Python SDK から数クリックでデプロイでき、高度な AI アシスタントやエージェントシステム、画像対応のアプリケーションを AWS インフラ上で構築できます。 Amazon SageMaker AI が推論エンドポイント向けの新しいオブザーバビリティ機能を発表 Amazon SageMaker AI が、推論エンドポイント向けの新しいオブザーバビリティ機能を発表しました。生成 AI 推論の本番ワークロードを、安心して運用できるよう支援します。Time to First Token、トークン間レイテンシ、キュー深度、秒間トークン数などのパフォーマンス指標をリアルタイムで追跡し、Amazon CloudWatch 内の構築済み「SageMaker AI Insights」ダッシュボードで、トークンレイテンシや GPU 使用率、推論コンポーネントのコピー数、スケーリングイベント、コールドスタートの内訳を一画面で見られます。OpenTelemetry ネイティブのメトリクスが計装なしで自動公開され、問題の特定・解決が数時間ではなく数分で進みます。東京リージョンを含むアジアパシフィック（ムンバイ、シンガポール、シドニー、東京、ソウル、ジャカルタ）、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン、北カリフォルニア）、カナダ（中部）、南米（サンパウロ）、欧州（アイルランド、フランクフルト、ロンドン、ストックホルム、チューリッヒ）で利用できます。 AWS Marketplace が AI 支援による製品リスティングを発表 AWS Marketplace が、Partner Assistant チャット内で使える AI 支援の製品リスティング機能を発表しました。独立系ソフトウェアベンダー（ISV）やコンサルティングパートナーが対象です。Web サイトの URL や PDF、ケーススタディ、製品ドキュメントといった既存の資産から情報を取り込み、必要な製品情報の各項目を自動生成します。AWS Marketplace のサイズ・フォーマット要件に対する検証や検索向けの最適化、項目ごとの推奨も行い、掲載内容の水準を示す品質スコアを提示します。これにより、手作業の入力や要件を満たすための推測の手間を減らせます。AWS Partner Central、AWS Marketplace Management Portal、プログラム連携向けの Partner Agent MCP server から利用でき、AWS GovCloud（米国）と中国リージョンは対象外です。 AWS Partner Central のエージェントが新規パートナーを登録から販売準備完了まで案内 AWS Partner Central agents のオンボーディング機能が一般提供を開始し、新規パートナーを登録から販売準備の完了まで導きます。従来は AWS で販売を始める最短ルートを知るために複数の資料を調べる必要がありましたが、その手間を減らします。企業の Web サイトから情報を取得して対応業界や提供ソリューションを自動入力し、販売準備に必要なことと、その理由を提示します。税務・銀行・コンプライアンスの要件をステップごとに案内し、検証や支払い設定の完了、Marketplace での出品準備までを支援します。常時利用できるアドバイザーとして、オンデマンドでパーソナライズされたロードマップを得られるのが利点です。AWS Partner Central コンソール内、または Model Context Protocol（MCP）経由で利用でき、すべての商用 AWS リージョンで使えます。 Amazon EC2 G7 インスタンスが一般提供開始 Amazon EC2 G7 インスタンスが一般提供を開始しました。NVIDIA RTX PRO 4500 Blackwell Server Edition GPU を最大 8 基（各 32GB メモリ）と、カスタムの Intel Xeon 6 プロセッサ、最大 700 Gbps の Elastic Fabric Adapter（EFA）を備えます。前世代の G6 と比べて AI 推論性能が最大 4.6 倍、グラフィックス性能が最大 2.1 倍とされ、言語翻訳や動画・画像解析、音声認識、レコメンダーシステムといった AI 推論から、リアルタイムの高品質グラフィックスやゲームストリーミング、大規模データ処理まで幅広く使えます。オンデマンド、Savings Plans、スポットの 3 つの購入オプションに対応し、米国東部（オハイオ）、米国西部（オレゴン）の各リージョンで利用できます。 Amazon EC2 P6-B200 インスタンスがアジアパシフィック（ムンバイ）リージョンで利用可能に Amazon EC2 P6-B200 インスタンスが、新たにアジアパシフィック（ムンバイ）リージョンで利用できるようになりました。NVIDIA Blackwell GPU を 8 基、1,440 GB の高帯域幅 GPU メモリを搭載し、第 5 世代 Intel Xeon プロセッサと最大 3.2 Tbps の EFAv4 を備えます。AI のトレーニングと推論で、P5en インスタンスと比べて最大 2 倍の性能が得られ、GPU メモリ帯域幅は 60% 向上しています。Amazon EC2 UltraClusters 内で数万 GPU 規模まで安全かつ確実にスケールでき、これまでの米国西部（オレゴン）、米国東部（バージニア北部、オハイオ）、AWS GovCloud（米国西部、米国東部）に加えて、今回アジアパシフィック（ムンバイ）が加わりました。 最後に「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近作っただし巻き卵焼きを褒められました。

はじめに 建設業界では、設計・施工・維持管理の各フェーズで BIM（Building Information Modeling）の活用が広がっています。一方で、実際は「BIM に必要なデータをどのように定義して、工程間で受け渡していくか」「受発注者で求める情報をどう揃えるか」という、データの要件をめぐる悩みが尽きません。発注者が思い描く BIM の姿と、実際に納品される BIM の中身が噛み合わず手戻りが発生する、というケースもあります。 この課題に対するアプローチの一つが IDS（Information Delivery Specification） です。建設分野のオープンな BIM 標準を策定する、国際的な非営利団体である buildingSMART が策定し、2024 年に v1.0 が承認された IDS は、「BIM に何が含まれているべきか」をコンピュータが解釈可能な形で定義するための仕様です。IDS があれば、納品された IFC ファイルが要件を満たしているかをツールで自動チェックできます。 本ブログでは、自然言語で書かれた BIM の要件定義書から、生成 AI が IDS を自動生成するソリューションを、実装レベルで解説します。核となる工夫は、 Amazon Bedrock AgentCore Runtime と AWS Step Functions を組み合わせ、要件ごとに IDS specification を並列生成するアーキテクチャです。 なお本ブログは、1〜3 章で「なぜこの構成にしたのか」という課題とアプローチの考え方を、4 章で「どう実装したか」という詳細を扱い、5 章で適用上の考慮点に触れる構成になっています。 1. BIM 要件をどう揃えるか BIM が業界に普及するにつれ、「納品された BIM モデルに、本当に必要なデータが入っているか」を確認する作業が、どのプロジェクトでも悩みどころになっています。例えば、以下のような課題が挙げられます。 受発注者間の要件ミスマッチ : 受注者が作る BIM と、発注者が求める要件が噛み合わない。納品段階で欲しい情報が入っていないと手戻りが発生する チェック業務の煩雑さ : 標準ルールはあるものの、完成物が仕様に沿っているかの確認を人手で行う必要があり、大規模な BIM ほど工数がかさむ 後工程での作り替えの難しさ : 設計時の BIM を施工や維持管理で活用しようとすると、データ要件が合わず作り替えが必要になる。そもそも「どんなデータを入れれば良いか」の定義自体が難しい これらの課題の根底にあるのは、「BIM に必要なデータ要件を、誰もが同じ解釈で共有できる形にできていない」 ことです。Excel の要件定義書や PDF の仕様書は人間には読めますが、機械が自動で検証するには情報が構造化されていません。 2. IDS とは何か ここで登場するのが IDS（Information Delivery Specification） です。IDS は buildingSMART が策定する国際標準で、「BIM の IFC ファイルに何が含まれているべきか」を XML 形式で機械可読に定義 します。IDS に対応する検証ツール（ IfcTester など）を使えば、IFC ファイルが IDS の要件を満たしているかを自動で判定できます。 BIM 活用が拡大するなか、発注者・設計者・施工者・維持管理者の間で BIM に求める情報を共通フォーマットで共有できる IDS の重要性は、今後さらに増していくと考えられます。 IDS の基本構造 IDS の中身は、specification と呼ばれるルールの集まりです。1 つの specification は次の 2 つの要素から構成されます。 applicability（適用対象） : どの IFC 要素に対するルールか。たとえば「IfcWall (壁) すべて」「外部に面した IfcDoor (ドア) だけ」など requirements（要件） : 対象要素が満たすべき条件。たとえば「Pset_WallCommon の FireRating プロパティが存在する」「Uniclass の分類コードが付与されている」など 両者で使える facet（ファセット、チェック項目） は 6 種類あります。 ファセット 意味 entity IFC エンティティの種別 (IfcWall, IfcDoor など) attribute IFC 標準属性 (Name, Description, GlobalId など) property プロパティセット内のプロパティ (Pset_WallCommon の FireRating など) material 材料の定義 classification 分類コード (Uniclass, OmniClass など) partOf 親子関係 (ある要素が何の下に属しているか) 実際の IDS ファイルは XML です。たとえば「すべての壁に、Pset_WallCommon の FireRating プロパティが必須」という specification は、次のように表現されます。 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS http://standards.buildingsmart.org/IDS/1.0/ids.xsd"> <ids:info> <ids:title>耐火等級を持つ壁</ids:title> </ids:info> <ids:specifications> <ids:specification ifcVersion="IFC4" name="耐火等級を持つ壁"> <!-- applicability: どの要素に適用するか（すべての壁） --> <ids:applicability maxOccurs="unbounded"> <ids:entity> <ids:name> <ids:simpleValue>IFCWALL</ids:simpleValue> </ids:name> </ids:entity> </ids:applicability> <!-- requirements: 満たすべき条件（FireRating プロパティが必須） --> <ids:requirements> <ids:property dataType="IFCLABEL"> <ids:propertySet> <ids:simpleValue>Pset_WallCommon</ids:simpleValue> </ids:propertySet> <ids:baseName> <ids:simpleValue>FireRating</ids:simpleValue> </ids:baseName> </ids:property> </ids:requirements> </ids:specification> </ids:specifications> </ids:ids> applicability の entity で「壁 (IFCWALL) すべて」を対象に指定し、 requirements の property で「Pset_WallCommon の FireRating プロパティを要求する」という意図を表しています。 IDS 作成の難しさ IDS の強みは明確ですが、自分たちの要件を IDS として書き起こす 作業には、いくつかの壁があります。 IDS は XML ベースの仕様で、書くには IFC スキーマの専門知識 が必要になる（どのエンティティが何のプロパティを持つか、正確な名前は何か、など） 要件が自社の Excel や PDF に「全ての壁に耐火等級を指定」といった自然言語で書かれているケースが多く、そのままでは IDS にならない プロジェクトのフェーズやユースケースごとに必要な IDS が異なるため、量的にも無視できない数の specification を作る必要がある つまり「IDS が使える」ことと「IDS を作れる」ことの間には、まだ距離があります。この距離を埋めるのが、本ブログのソリューションです。 IDS を用いたチェックを実施する上での課題と、それぞれに求められる仕組みを整理すると、次のようになります。 3. 課題の性質から設計を考える 具体的な AWS サービスの話に入る前に、まず「この課題をどういう考え方で解くか」を整理します。2 章までで見た IDS 作成の難しさを性質ごとに分解すると、取るべき打ち手が見えてきます。 要件は数十〜数百件ある → 1 件ずつ逐次で AI に処理させると、待ち時間が積み重なって現実的な時間に収まらないため、要件ごとに並列で処理する必要がある IDS を正しく書くには IFC スキーマの専門知識が要る → 「耐火等級」が IFC のどのプロパティ名にあたるか、といった知識を AI に与えないと正確な IDS にならない。そのため、専門知識を参照できる道具（ツール）を持った AI エージェントが適している（AI に単純なプロンプトを与えるだけでは精度が出にくい） 生成結果にミスがあると実用にならない → スキーマに違反した IDS は検証ツールで検証出来ないため、AI 自身が出力を検証し、誤りがあれば直すループが必要になる これらを踏まえ、次のアプローチが考えられます。 自然言語で書かれた要件一覧を構造化し、要件ごとに専門知識を持った AI エージェントが並列で IDS specification を生成し、検証済みの結果を 1 つの IDS ファイルにまとめる。 機能の流れだけを抜き出すと、次のようなステップになります。具体的にどの AWS サービスで実現するかは 4 章で詳述します。 このアプローチのポイントは、「専門知識の付与（ツール）」「並列処理」「自己検証」という 3 つの仕組みを組み合わせ、人手では負担の大きい IDS 作成を自動化している点にあります。次章では、これを AWS 上でどう実装したかを見ていきます。 4. AWS 上での実装 ここからは、3 章のアプローチを AWS 上で具体的にどう実現したかを解説します。まず全体のアーキテクチャを示し、その後で実装上のポイントになる 3 点、すなわち「IDS 生成エージェントをどう書くか」「AgentCore でどう動かすか」「要件ごとに並列実行するオーケストレーション」を順に見ていきます。 4.1 アーキテクチャ全体像 3 章で説明した流れを、次のような構成で実装しています。 処理は大きく 3 つのフローに分かれます。要件の構造化と IDS 生成（3 章の①〜③）に加えて、生成した IDS で IFC を検証するフローも実装しています。 (1) 要件構造化フロー ユーザーがフロントエンドから要件定義書をアップロード 構造化用 AWS Lambda が Amazon S3 から要件定義書を取得し、生成 AI で要件を抽出・構造化 構造化された要件一覧を Amazon Aurora に保存 (2) IDS 生成フロー ユーザーが IDS 生成を実行すると、Step Functions の IDS 生成ワークフローが呼び出される Step Functions が「(1) 要件構造化フロー」で構造化された要件一覧を受け取り、要件 1 件ごとに並列で Amazon Bedrock AgentCore Runtime を起動 各 AgentCore Runtime が生成した specification を Aurora に保存 全要件の処理完了後、集約用 Lambda が specification を 1 つの IDS ファイルにまとめて S3 に保存 ユーザーは生成された IDS ファイルを確認する (3) 検証フロー ユーザーがチェック対象の IFC ファイルと、生成済みの IDS を指定して検証を実行 検証処理を AWS Batch 上で起動し、IFC ファイルが IDS の要件を満たしているかを判定（ IfcTester を利用） 検証結果をユーザーに返し、要件を満たす/満たさない要素を一覧で確認 ここで出てきた「Amazon Bedrock AgentCore Runtime」は、2025 年に GA した、AI エージェントをデプロイ・実行するための AWS のサーバーレス環境です。Strands Agents、LangGraph、CrewAI など任意のフレームワークで書いたエージェントを、セッションごとに専用 microVM（分離された CPU・メモリ・ファイルシステム）で動かせるため、セッション間でデータが混ざりません。リアルタイムの対話だけでなく、最大 8 時間の長時間処理にも対応します。本実装では Strands Agents で書いた IDS 生成エージェントを AgentCore Runtime 上で実行しています。 4.2 IDS 生成エージェントの構造 3 章で挙げた「専門知識の付与」と「自己検証」を担うのが、この IDS 生成エージェントです。 Strands Agents （AWS がオープンソースで公開しているエージェントフレームワーク）で記述し、Claude Sonnet 4.5 をモデルとして使用しています。エージェントには以下の 4 つのツールを与えています。 schema_instruction_tool : IDS の TypeScript インタフェース定義、スキーマ制約などを返す ifc_knowledge_tool : IFC のエンティティ / プロパティ / 分類を検索するためのツール。たとえばエージェントが「wall」と検索すれば IfcWall が、「耐火等級」と検索すれば FireRating がヒットする（＝「専門知識の付与」を担うツール） example_tool : 条件に応じたサンプルの Specification（25 件の実例）を返す。Few-Shot 学習の材料として、エージェントがプロンプトに取り込む validation_tool : 生成した仕様を jsonschema で検証し、エラーを AI にフィードバックする。エージェントは自己修正して再生成できる（＝「自己検証ループ」を担うツール） エージェントの本体は、Strands で記述されており、次のようなシンプルな書き方で定義できます。 # ids_generator_agent.py（抜粋・簡略化） from bedrock_agentcore.runtime import BedrockAgentCoreApp from strands import Agent from strands.models import BedrockModel from tools import ( schema_instruction_tool, ifc_knowledge_tool, example_tool, validation_tool, ) app = BedrockAgentCoreApp() agent = Agent( model=BedrockModel( model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0", temperature=0.3, ), tools=[ schema_instruction_tool, ifc_knowledge_tool, example_tool, validation_tool, ], system_prompt=SYSTEM_PROMPT, ) @app.entrypoint async def agent_invocation(payload): user_message = payload.get("prompt") result = await agent.invoke_async(user_message) return result.message if __name__ == "__main__": app.run() システムプロンプトには「出力は必ず純粋な JSON のみ」「markdown コードブロックや説明文を混ぜない」「IFC 用語は ifc_knowledge_tool で必ず検証する」といった細かい指示を含めており、出力の一貫性を担保しています。また、プロンプトで validation_tool を必ず最後に呼んでから返すよう指示することで、スキーマ違反の specification が保存されるリスクを防いでいます。 4.3 AgentCore Runtime へのデプロイ Strands で書いたエージェントを AWS 上で動かすには、通常であれば Amazon ECS や Lambda のコンテナイメージを組み、 Amazon API Gateway を前段に置いて…と手順が多くなります。AgentCore Runtime を使うと、こうしたデプロイ周りの作業が非常に簡単になります。AWS が提供する AgentCore Starter Toolkit （ pip で導入できる CLI ツール）を使えば、ローカルでの開発・テストから本番デプロイまでを、次のようなコマンドで実現できます。 # ローカル開発 (ホットリロード付き) agentcore dev # ローカルテスト agentcore invoke --dev "All walls must have a fire rating" # 本番デプロイ agentcore configure --entrypoint ids_generator_agent.py agentcore launch 4.4 Step Functions Map で IDS specification を並列生成する ここが本実装の中心です。3 章で述べたとおり、BIM の要件定義書には、1 件のプロジェクトで数十〜数百件の要件が含まれることも珍しくありません。これを逐次で処理すると、AI 呼び出しの待ち時間が積み重なり、現実的な応答時間に収まりません。 そこで本実装では、 Step Functions の Map ステート を使い、要件ごとに AgentCore Runtime を並列で呼び出します。Map ステートは「配列の各要素に対して同じ処理を実行する」ための制御で、並列度を制限したり、各要素のエラーを個別にハンドリングしたりできます。 処理フローを図にすると次のようになります。要件一覧を受け取った Map ステートが要件を 1 件ずつ並列レーンに割り当て、各レーンで AgentCore のエージェントが IDS を生成し、すべて出揃ったところで集約 Lambda が 1 つの IDS ファイルにまとめます。 この並列化のポイントは 3 つあります。 AgentCore Runtime が「セッション分離」を前提とした設計のため、並列呼び出しが安全 : 各セッションが専用の microVM で動くため、状態が混ざる心配がない。Lambda でエージェントをホストする場合のように「同じインスタンスでの実行順序」を考慮する必要がない 個別要件の失敗が全体を止めない : Map 内の各要件の処理は独立しているため、1 件の要件が失敗しても残りの要件は処理が続く。失敗した要件は DB に error ステータスで記録され、ユーザーは後で個別に再実行できる リトライ戦略を Step Functions 側で完結させられる : AgentCore の一時的なスロットリングや Claude のタイムアウトは、Step Functions の自動リトライ（指数バックオフ）に任せられる。Lambda のコードに再試行ロジックを書く必要がない これらの並列度・エラーハンドリング・リトライの設定は、すべて AWS CDK 上で宣言的に定義しています。Map ステートの並列処理を「アプリケーションのコードではなく、ワークフロー定義として外側に持てる」ことが、実装をシンプルに保つことに繋がっています。 4.5 動作イメージ ここまでの仕組みを、実際の画面で一連の流れとして見てみます。 まず、要件定義書（PDF）をアップロードすると、生成 AI が内容を解釈し、要件を 1 件ずつ構造化して一覧に展開します。 次に、構造化された要件のうち、IDS specification を生成する対象を選択します。 「生成」を実行すると、AgentCure Runtime により、選択した要件ごとに specification が並列で生成され、各要件の状況（処理中 / 完了など）がリアルタイムに更新されます。 生成された specification は、要件ごとに内容を確認できます。 最後に、生成した IDS を使い、チェック対象の IFC ファイルが要件を満たしているかを検証します。本ソリューションでは、検証処理は AWS Batch 上で実行しています。 5. 考慮点: 条件分岐の多い要件への対応 本ブログで紹介したアプローチは、「全ての壁に耐火等級」「外部ドアは防火性能 60 分以上」といった、独立したルールが多数並ぶタイプの要件定義に有効です。一方で、用途・地域・構造などの組み合わせで要求内容が変わる、条件分岐が多い領域（たとえば建築基準法のような規定群）には、IDS の仕様上の制約から、そのままでは適用しづらい点があります。 理由は、IDS の設計思想にあります。IDS は「情報デリバリー仕様」という名前のとおり、「何が含まれているべき/いないべきか」を記述するのがスコープで、1 つの specification の中に if-then-else のような条件分岐を入れ込む機能は持ちません。条件によって要求が変わるルールは、条件の組み合わせごとに別々の specification として分割する必要があります。 チェックのスコープや内容によっては、様々な条件の組み合わせで要求内容が変わるため、これらを素朴に specification として展開すると、その数は膨大になります。本ブログのアプローチは個々の要件を IDS 化する部分を自動化しますが、こうした「条件分岐をどう整理して IDS に落とすか」という設計の問題は依然として残ります。分岐の多い領域へ適用を広げる際の検討課題と言えるでしょう。 6. まとめ 本ブログでは、BIM の要件定義を巡る課題と、それに対する国際標準 IDS の位置づけを整理した上で、「自然言語で書かれた要件定義書から IDS を自動生成する」 ソリューションを、実装レベルで解説しました。要点は次のとおりです。 IDS は buildingSMART が 2024 年に v1.0 として承認した国際標準で、IFC ファイルに何が含まれているべきか/いないべきかを機械可読に定義する IDS 作成には IFC スキーマの専門知識が必要で、自然言語の要件定義からの変換は手作業では負担が大きい 課題の性質（要件が多い / 専門知識が要る / ミスが許されない）から、「並列処理」「専門知識ツールを持つ AI エージェント」「自己検証ループ」という 3 つの仕組みを組み合わせるアプローチを紹介 建築基準法のように条件分岐が多い領域には、IDS の仕様上、条件の組み合わせごとに specification を分割する必要があり、その整理が適用範囲を広げる際の検討課題となる このアプローチの利点は、既存の要件定義資産（自然言語の Excel / PDF）をそのまま活用しながら、機械可読な IDS に変換できることです。本ブログでは IDS を題材にしましたが、同じ並列エージェントパターン（「自然言語の要件 → 構造化 → 要件ごとの並列 AI 処理 → 集約」）は、仕様書からのテストケース生成、要件定義からのチェックリスト生成など、大量の個別要件を AI で処理する場面に応用できます。

はじめに 建設業界における BIM（Building Information Modeling）の導入は着実に進んでいます。BIM は建物の 3D 形状に加えて、各部材の寸法・材料・性能といった属性情報を一元的に持つ、いわば「建物のデータベース」とも言える存在です。しかし、その豊富なデータは、後述するいくつかの理由から、十分に活用されていない、という声もよく耳にします。 こうしたなか、BIM データ活用に向けた一つのアプローチとして注目されているのが生成 AI です。近年の生成 AI の発展により、「自然言語で BIM データを読み書きする」「AI エージェントが建物データを解釈して次のアクションに繋げる」といった使い方が現実的になりつつあります。本ブログでは、AWS Summit Japan 2025 の建設・不動産ブースで展示した IFC Viewer with GraphRAG を題材に、IFC ファイルをグラフに変換してグラフデータベースに格納し、生成 AI エージェントが情報を問い合わせる仕組みを、実装レベルで解説します。 なお本ブログは、1〜2 章で「なぜこの構成にしたのか」というアプローチと設計の考え方を、3 章で「どう実装したか」という詳細を扱い、4 章で発展的な拡張に触れる構成です。3 章以降は RDF グラフのモデリングや AI アプリの実装に踏み込む内容のため、グラフデータベースや生成 AI の開発経験があると読み進めやすくなりますが、各節の冒頭に要約を置いているため、詳細を読まなくても全体の流れは追えるようになっています。 1. BIM データを AI から扱うアプローチ BIM が普及するにつれ、3D 形状と属性情報を一元的に持つ「建物のデジタルデータ」が、案件ごとに蓄積されるようになりました。生成 AI を活用することで、こうしたデータに自然言語で問い合わせたり、AI エージェントに解釈させて次の作業へ繋げたりといった応用に繋げることができます。 その入口としてまず候補になるのが、各種 BIM プラットフォームが提供する REST API を、AI エージェントの Tool、あるいは MCP（Model Context Protocol）サーバー経由で渡す方法です。BIM データに API 経由でアクセスできるサービスは増えており、データを別の形式に変換したり外部に書き出したりせず、プラットフォームに置いたまま AI から参照できます。導入の手間が小さく、認証認可の仕組みや、ビューワーまで BIM プラットフォームで完結する利点があります。半面、取得できるデータやロジックは、ベンダーが提供する API の範囲に縛られます。API が想定していない切り口での集計や、他システムのデータとの突き合わせといった使い方には対応しにくいという制約があります。 （補足: MCP はアプリケーションが AI にツールやデータソースを提供するための共通プロトコルで、対応していれば異なる AI クライアントから同じツールを使えます） オープンフォーマットな BIM (IFC) を起点にする 特定ベンダーの API 範囲に縛られたくない場合、業界標準のオープンフォーマットである IFC（Industry Foundation Classes） を起点にする方法があります。IFC は、建設分野のオープンな BIM 標準を策定する、国際的な非営利団体である buildingSMART が定めた国際標準フォーマットで、特定ベンダーの製品に依存せず建物データを表現・交換できます。主要な BIM ツールは IFC のエクスポートに対応しているため、特定の製品で作成した BIM モデルであっても IFC 形式に変換できます。 ただし、IFC は AI がそのまま解釈できる形式にはなっていません。IFC は STEP 物理ファイル形式というテキスト形式で、中身は次のように、エンティティを #1234= のような ID 番号で繋いだフラットな構造になっています。 #129= IFCBUILDING('0w984V0GL6yR4z75XVLWOr',#41,'',$,$,#32,$,'',.ELEMENT.,$,$,#125); #138= IFCBUILDINGSTOREY('0w984V0GL6yR4z75YWgVfX',#41,'Nivel 1',$,'Nivel:Nivel 1',#136,$,'Nivel 1',.ELEMENT.,0.); #186= IFCWALLSTANDARDCASE('2idC0G3ezCdhA9WVjWemc$',#41,'Muro básico:Partición con capa de yeso:163541',...,#155,#182,'163541'); #6723= IFCWINDOW('2idC0G3ezCdhA9WVjWe$OB',#41,'Ventana simple:100 x 100 cm:164193',...,#25036,#6717,'164193',2.3,1.); 壁 ( #186 ) が所属する階 ( #138 ) は #136 経由でたどり、窓 ( #6723 ) が埋まっている壁は IFCRELVOIDSELEMENT / IFCRELFILLSELEMENT を介して参照する、といった具合です。エンティティの量（上記は数万行のうちの一部です）も相応にあり、AI にこの生テキストを渡してそのまま解釈させるのは現実的ではありません。 この IFC を扱いやすくするアプローチが、大きく 2 つあります。1 つは IFC を解釈できるライブラリを使ってその場で読む方法（A）、もう 1 つは IFC を別のデータモデルに変換し、データベースに格納してから問い合わせる方法（B）です。 (A) IFC を扱えるライブラリを AI のツールとして渡す 1 つ目は、IFC を扱えるオープンソースソフトウェア（OSS）を Tool として渡し、エージェントに探索させる方法です。代表的な OSS が IfcOpenShell で、先ほどのような生の STEP テキストを直接たどる必要はありません。 by_type("IfcWall") で壁を一覧したり、 #136 のような番号ではなく wall.Name のように属性名でアクセスしたり、ある要素を参照している関連要素を逆向きにたどったりと、IFC の構造を扱いやすい形で読み取ることができます。先ほど挙げたフラットさや参照の複雑さの多くは、こうしたライブラリが吸収します。 一方で、このアプローチには考慮すべき点もあります。問い合わせのたびに IFC ファイルを読み込んで探索する形になるため、エージェントにライブラリの API を組み合わせて目的の情報までたどらせると、問い合わせの内容によっては探索の手数が読みにくく、応答時間も安定しません。また、複数の建物をまたいだ横断検索や、大量要素の集計のように「あらかじめ整理されたデータ」を前提とする用途とは相性がよくありません。1 ファイルを対象とした素朴な参照には手軽で有効である一方、規模や横断性が増すほど追加の工夫を要する、という位置づけです。 (B) IFC を構造化してデータベースに格納し、AI が問い合わせる 2 つ目は、IFC を一度解釈し、用途に合わせたスキーマでデータベースに格納してから、エージェントには「データベースを問い合わせる Tool」を渡す方法です。問い合わせのたびにファイルを探索する代わりに、あらかじめ整理した状態を用意しておく、という発想です。 データの構造を案件・用途に合わせて設計できるので、カスタマイズの自由度が最も高くなります。複数ファイルをまたいだ横断検索や集計を書きやすい形に整えたり、他システムのデータと突き合わせやすいスキーマにしたりと、(A) では難しかった用途にも対応できます。半面、変換パイプラインとデータベースの両方を用意・運用する必要があり、導入コストは最も高くなります。 本ブログで扱うアプローチ ベンダー API（最初に触れた方法）、ライブラリでの直接探索（A）、データベースへの構造化（B）と、後ろにいくほど構築の手間は増えますが、その分、任意の構造でデータを格納でき、検索・集計・横断分析の自由度が高くなります。本ブログでは、この (B) のアプローチを採用した実装例を取り上げます。次の章では、データベースとして何を選び、どう組み立てたかを見ていきます。 2. IFC をグラフに変換して、グラフデータベースに格納する 採用したアプローチを一言でまとめると、「IFC をグラフ (RDF グラフ) に変換してグラフデータベース (Amazon Neptune Serverless) に格納し、AI エージェントがクエリ言語 (SPARQL) で問い合わせる」というものです。 (B) のデータモデルとして RDF グラフを選んだ理由は、BIM データの性質にあります。BIM データは「壁が窓を含む」「階が要素を持つ」といった、モノ同士の関係の集まりで、構造的にはグラフそのものです。また、検索する際も、関係をいくつもたどっていく問い合わせが中心になります。こうした「関係をたどる」処理は、テーブルを JOIN し続けるリレーショナルデータベースよりも、関係をそのままエッジとして持つグラフデータベースのほうが素直に記述できます。 RDF（Resource Description Framework）についても簡単に補足します。RDF は、あらゆる事実を「主語 – 述語 – 目的語」の 3 つ組（トリプル）で表す W3C 標準のデータモデルです。たとえば「Wall_001 は Window_002 を含む」という事実は、 Wall_001 - hasSubElement - Window_002 というトリプルで表せます。これを大量に集めると、ノード（モノ）とエッジ（関係）からなるグラフになります。 グラフの表現方法は他にもありますが、今回 RDF を選んだのは、既存の資産をそのまま活かせるためです。建設業界で広く使われている IFC を Linked Building Data（LBD）系のオントロジーで RDF 化する考え方や OSS が整備されており、さらに Amazon Neptune がマネージドサービスとして RDF / SPARQL をサポートしています。これにより、変換パイプラインとデータベース運用のいずれも、ゼロから構築する必要がありません。 アーキテクチャ 全体のアーキテクチャは以下の通りです。 処理の流れは大きく 2 系統に分かれます。 (1) 取り込み系: IFC → RDF グラフ → Neptune へのロード ユーザーが IFC ファイルを Amazon S3 にアップロード S3 イベントを Amazon EventBridge で受け、AWS Batch で変換用コンテナを起動 コンテナ内で IFC → Turtle 変換ツールを実行し、IFC を Turtle 形式（RDF を表現するテキスト形式の 1 つ）のファイルに変換して S3 へ書き戻す Turtle ファイルの S3 PUT イベントが AWS Lambda を起動し、Amazon Neptune の bulk loader API でグラフをロード 同じ Lambda が、後段の問い合わせで使うメタデータを Turtle から抽出して Amazon DynamoDB に保存 (2) 問い合わせ系: ユーザーの質問 → SPARQL → 自然言語回答 ユーザーがフロントエンドから自然言語の建物に関する質問を投げる Amazon API Gateway を経由して、エージェント実装の Lambda を起動 Lambda は対象 IFC のメタデータを DynamoDB から読み出し、Amazon Bedrock（Anthropic Claude）で SPARQL クエリを生成 生成した SPARQL を Neptune 上で実行し、結果を Bedrock で自然言語に整形してユーザーに返す 中間結果と最終回答は AWS AppSync Events で配信し、フロントの 3D ビューワー上で対象オブジェクトをハイライト なお、ここで出てきた「Turtle（タートル）」は RDF を表現するファイル形式の 1 つで、人間が読み書きしやすいように設計された構文です。次章で実例を載せます。 3. 主要コンポーネントの実装 ここからは実装の中身に入ります。(B) のアプローチで実装上のポイントになるのは、「IFC をどんな形の RDF グラフにするか」と「AI にどう SPARQL を書かせるか」の 2 点です。この章では RDF グラフのモデリングや AI アプリの実装に踏み込むため、グラフデータベースや生成 AI の開発経験があると読み進めやすい内容です。各節の冒頭に要約を置いているので、詳細を飛ばしても流れは追えるようにしています。 3.1 IFC を RDF グラフに変換する 要約 : IFC を RDF に変換すると、「建物 → 階 → 要素」という階層構造が、そのままグラフのノードとエッジになります。リレーショナルデータベースのような JOIN なしで関係をたどれるので、後段の問い合わせが書きやすくなります。 本ブログで紹介するソリューションでは、IFC からの RDF 変換に IFCtoLBD という OSS を使用しています。これは、IFC ファイルを、グラフとして扱いやすい RDF（Turtle 形式）に変換してくれるツールです。変換後のデータは、Linked Building Data（LBD）で整備されている公開オントロジー（建物データの語彙を定めたもの。建物トポロジーを表す BOT など）に沿った形になります。本実装では、この変換作業を AWS Batch のコンテナで実行しています。 変換後の Turtle は、たとえば次のようになります（1 章で示した IFC と同じ建物の変換結果からの抜粋です）。 @prefix bot: <https://w3id.org/bot#> . @prefix props: <http://lbd.arch.rwth-aachen.de/props#> . @prefix inst: <https://lbd.example.com/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . # 建物（Building）— 配下に階が 2 つ inst:building_3a24811f-0105-46f1-b13d-1c585f560635 a bot:Building ; bot:hasStorey inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9fa61 , inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9ff4b ; props:numberOfStoreys_property_simple 2 ; props:globalIdIfcRoot_attribute_simple "0w984V0GL6yR4z75XVLWOr" . # 階（Storey）が要素（Element）を含む inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9fa61 a bot:Storey ; rdfs:label "Nivel 1" ; props:elevationIfcBuildingStorey_attribute_simple "0."^^xsd:double ; bot:containsElement inst:wall_ac9cc010-0e8f-4c9e-b289-81fb60a309bf , inst:slab_76178dce-ff53-4da5-b52a-f5f1ad7930e7 , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f63e . # ... (door, furniture など同階の要素が続く) # 壁（Element）— 9 つの窓をサブ要素として持つ inst:wall_ac9cc010-0e8f-4c9e-b289-81fb60a309bf a bot:Element ; rdfs:label "Muro básico:Partición con capa de yeso:163541" ; props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWemc$" ; props:objectTypeIfcObject_attribute_simple "Muro básico:Partición con capa de yeso" ; props:loadBearing_property_simple false ; props:isExternal_property_simple false ; bot:hasSubElement inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f60b , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f608 , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f673 . # ... (計 9 個の窓が続く) # 窓（Element）— IFC 由来の属性がリテラル値で並ぶ inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f60b a bot:Element ; rdfs:label "Ventana simple:100 x 100 cm:164193" ; props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWe$OB" ; props:objectTypeIfcObject_attribute_simple "Ventana simple:100 x 100 cm" ; props:overallWidthIfcWindow_attribute_simple "1."^^xsd:double ; props:overallHeightIfcWindow_attribute_simple "2.3"^^xsd:double ; props:thermalTransmittance_property_simple 6.7069 . 注目してほしいのは次の点です。 bot:Building / bot:Storey の階層と bot:Element のフラットな要素集合 : 建物 → 階など、馴染みのある階層関係が bot:hasStorey でグラフ化されます。各階が直接持つ部材は bot:containsElement で壁・スラブ・窓・扉・家具・方立などを指し、これらはすべて bot:Element クラスでラベル付けされます 壁と窓のようなサブ要素の関係 : 壁に埋まっている窓は bot:hasSubElement で壁と関係性を持ちます。上の壁は 9 個の窓を含む要素で、これをたどれば「この壁には窓が何個あるか」という質問がそのまま 1 ホップのグラフ走査になります props: 接頭辞の属性 : 寸法・面積・体積・グローバル ID・熱貫流率（ thermalTransmittance ）・外部面かどうか（ isExternal ）といった IFC 由来の属性は、 props: 名前空間配下のプロパティとしてリテラル値で付与されます。 props:globalIdIfcRoot_attribute_simple は IFC の GlobalId にあたり、ビューワー上のハイライトなど、3D モデルのオブジェクトと紐付ける際のキーになります。 このように、「Wall ノードが Window ノードを hasSubElement で含み、寸法はリテラル属性として持つ」というシンプルなモデルで建物全体を表現できます。リレーショナルデータベースのように「壁テーブル」「窓テーブル」を JOIN する必要はなく、関係をそのまま辿ることができます。 3.2 ファイル単位で名前空間を分ける（Named Graph） 要約 : 複数の IFC を 1 つの Neptune に同居させると要素 URI が衝突します。RDF の Named Graph でファイルごとにグラフ空間を分けておくと、衝突を防ぎつつ「特定の建物だけに問い合わせる」のも簡単になります。 複数の IFC ファイルを 1 つの Neptune クラスタに同居させると、要素 URI が衝突したり、特定のファイルだけを対象にした問い合わせが書きづらくなったりします。本実装では RDF の Named Graph を使い、ファイルごとに専用のグラフ空間を割り当てています。 ファイル building-A.ifc → Named Graph URI http://example.com/graphs/ifc/building-A ファイル building-B.ifc → Named Graph URI http://example.com/graphs/ifc/building-B SPARQL では GRAPH <...> 句で対象を絞り込めるため、後述のクエリも基本的にこの形になります。Neptune の bulk loader はリクエストパラメータの parserConfiguration.namedGraphUri でロード先のグラフを指定できるので、ロードの時点で分割しています。 3.3 自然言語を SPARQL に変換する（text-to-SPARQL） 要約 : ユーザーの質問を AI が SPARQL に翻訳し、Neptune で実行し、結果を再び自然言語に戻します。LangChain の既製チェーンをベースに、LangGraph で 2 ノード構成にまとめています。クエリの精度を上げるうえで一番効くのは、「お手本のクエリ例（Few-Shot）」をプロンプトに同梱することです。 問い合わせ系の中心は、ユーザーの自然言語の質問を SPARQL クエリに変換し、結果を再び自然言語で返す、いわゆる text-to-SPARQL の処理です。 本実装のベースには LangChain の create_neptune_sparql_qa_chain を採用しています。これは「スキーマを AI に渡して SPARQL を生成 → Neptune で実行 → 結果を AI に渡して自然言語化」という一連のチェーンが実装されています。 全体の処理フローは以下のとおりです。 実装上は、LangGraph を使って ① の要素選択ノード と ② 〜 ⑤ をまとめた SPARQL 処理ノード の 2 ノードにまとめており、後者のノードの中で LangChain のチェーンを順に呼び出しています。 AI に SPARQL を生成させるときに効果的になるのが Few-Shot プロンプティング 、つまり「こういう質問にはこういうクエリを書く」という例題をプロンプトに同梱することです。本実装では、IFC ファイルをロードするタイミングで、その IFC に含まれる要素タイプを参考にしながら、問い合わせ例の質問・SPARQL ペアを自動生成して DynamoDB に保存しています。問い合わせ時にはここから読み出してプロンプトに差し込みます。 3.4 必要なスキーマだけを DynamoDB から読み出す 要約 : 既製チェーンをそのまま使うと、DB 上の全クラス・全述語をプロンプトに載せてしまい、IFC のように要素が多いと応答が遅く、コストもかさみます。本節では、必要なスキーマだけを事前に切り出して持っておく工夫を紹介します。 LangChain の create_neptune_sparql_qa_chain をデフォルトのまま使うと、内部の NeptuneRdfGraph が、対象データベース上のすべてのクラスと述語をスキーマとして取得し、まるごとプロンプトに含めます。小さいオントロジーなら問題ありませんが、IFC のように要素タイプ・属性が多い場合は、初回応答の遅さとプロンプトサイズの増加が問題になります。既製チェーンの「全スキーマをそのまま渡す」前提が、IFC の規模では合わなくなる、ということです。 そこで本実装では、 NeptuneRdfGraph を継承した NamedGraphAwareNeptuneRdf クラスを用意し、次の 2 点を変えました。 スキーマクエリを Named Graph 単位に絞る : GRAPH <namedGraphUri> { ... } で囲み、ファイル単位のスキーマだけを取得する DynamoDB から事前ロード済みスキーマを使う : IFC ロード時にスキーマを抽出して DynamoDB に保存しておき、問い合わせ時は Neptune ではなく DynamoDB から読み出す DynamoDB には、IFC ファイル 1 つにつき 1 レコードの形でメタデータを保存しています。1 レコードには、そのファイルのスキーマ（登場するクラスや述語の一覧）、Few-Shot 用のサンプルなどをまとめています。中身のイメージは次のとおりです。 { "loadStatus": "READY", "fileName": "small-l1-p", "namedGraphUri": "http://example.com/graphs/ifc/small-l1-p", "schema": { "classes": [ {"uri": "https://w3id.org/bot#Building", "local": "Building"}, ... ], "rels": [ {"uri": "https://w3id.org/bot#hasSubElement", "local": "hasSubElement"}, ... ], "dtprops": [ {"uri": ".../thermalTransmittance_property_simple", "local": "..."}, ... ], "oprops": [] }, "resourceTypes": { "wall": 3, "window": 10, "door": 1, "slab": 2, ... }, "examples": "<question>...</question><sparql>...</sparql>" } これにより、Neptune へのスキーマ問い合わせの往復が省けて応答時間が短くなり、プロンプトに載せるスキーマもそのファイルに必要な分だけになるので、コンテキストの消費とトークンコストを抑えられます。 参考までに、最終的に AI が生成する SPARQL は次のような形になります（ユーザーの質問は「特定の壁に含まれる窓の数は？」）。 PREFIX props: <http://lbd.arch.rwth-aachen.de/props#> PREFIX bot: <https://w3id.org/bot#> PREFIX inst: <https://lbd.example.com/> SELECT (COUNT(?window) AS ?windowCount) WHERE { GRAPH <http://example.com/graphs/ifc/small-l1-p> { ?wall props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWemc$" . ?wall bot:hasSubElement ?window . FILTER(STRSTARTS(STR(?window), STR(inst:window_))) } } GRAPH <...> で対象 IFC を絞り、 hasSubElement で壁配下の要素をたどり、URI 接頭辞 inst:window_ の一致で窓に絞る、という意図がそのままクエリになっています。先ほどの 9 個の窓を持つ壁にこのクエリを実行すると、 windowCount = 9 が返ります。 3.5 動作イメージ ここまでの仕組みを通すと、ユーザーから見た動作は次のようになります。自然言語で質問を投げると、AI が SPARQL を生成・実行して自然言語で回答を返し、同時に該当する建物要素が 3D ビューワー上でハイライトされます。 質問する側は SPARQL や IFC の内部構造を知らなくても、「窓の熱貫流率を教えて」「家具は全部で何個ある？」と尋ねるだけで、回答と該当箇所の表示を同時に得られます。1 章で触れた、IFC の構造を知らないと素朴な問い合わせすら難しいという問題が、この画面の中で解消されていることが見て取れます。 4. GNN（Graph Neural Network）と組み合わせた発展 要約 : text-to-SPARQL は「決まった問い合わせ」に強い一方、BIM の繋がり方そのものから何かを予測するタスクは、生成 AI 単体では扱いづらい領域です。同じ RDF グラフを訓練データとして GNN を併用すると、干渉解消・熱負荷予測・意味付け補強といった、研究実績のあるタスクに広げられます。 生成 AI の発展により、「以前は自前で機械学習モデルを訓練していたタスクも、AI エージェントに任せれば対応できる」場面は増えています。本ブログの text-to-SPARQL もその流れの上にあります。 一方で、BIM のように、ノードとエッジの繋がり方そのものに意味があるデータに対しては、グラフ構造を学習する Graph Neural Network（GNN）が効果的なタスクも残っています。GNN は、各ノードの属性と隣接ノードからの情報を集約してベクトル表現を学習する深層学習モデルです。グラフデータベースに格納したデータをそのまま訓練データに利用できるため、本ブログのアーキテクチャと組み合わせやすい拡張先です。 BIM の分野で GNN が効果を発揮するユースケースを、3 つ紹介します。いずれも「答えが既存データの検索では得られず、予測が必要になる」という点で、GNN が効果的な領域です。 4.1 干渉解消（クラッシュ・レゾリューション）の予測 干渉チェックツールが出力する大量の候補のうち、多くは無視できる重なりで、本当に対処すべき干渉の仕分けと、どのコンポーネントを動かすかの判断に時間がかかります。これが GNN に向いているのは、「どれを直すべきか」が周辺コンポーネントとの関係に左右され、単体の属性だけでは決まらないからです。Hu ら（2023, Clash context representation and change component prediction based on graph convolutional network in MEP disciplines ）は、干渉が起きたコンポーネントと周辺の依存関係をグラフで表現し、Graph Convolutional Network で「どのコンポーネントを修正すべきか」を予測する手法を提案しています。周辺への波及を加味して判断できる点が特徴です。 4.2 部屋やゾーンを跨いだ熱負荷・エネルギー予測 従来の機械学習モデルは、建物全体を 1 ゾーンとして扱うか、各ゾーンを独立に扱うかのどちらかで、ゾーン間の熱の相互作用を捉えきれないという課題がありました。GNN はゾーンをノード、ゾーン間の隣接関係をエッジとしてグラフ化できるので、熱伝達を構造として取り込んだ上で予測できます。Lu ら（2023, Temporal graph attention network for building thermal load prediction ）は Graph Attention Network と GRU を組み合わせ、多ゾーンの熱負荷を同時に予測するモデルを提案しています。 4.3 BIM の意味付け補強（セマンティック・エンリッチメント） BIM モデルは、設計者やツールの違いによって要素の分類ラベルや属性が不揃い・不完全になりやすく、これが下流の数量積算や確認申請の自動チェックに影響します。Tarabishy & Sacks ら（2024, Incorporating Context into BIM-Derived Data—Leveraging Graph Neural Networks for Building Element Classification ）は、GNN ベースの要素分類が、幾何特徴のみを見る従来手法（SVM など）よりも精度で上回ることを示しています。「予測ラベルと登録ラベルが食い違う要素」を要レビュー候補として抽出する整合性チェックにも応用でき、ルールエンジンだけでは難しい BIM データの品質維持に有効な領域です。 AWS でのアプローチ GNN を AWS で動かす場合、まず候補になるのが Amazon Neptune ML です。Neptune に格納したグラフから、GNN モデルを訓練・推論できる機能で、ノード分類・回帰、エッジ分類・回帰、リンク予測が標準でサポートされています。 5. まとめ 本ブログでは、BIM データ（IFC）に AI エージェントからアクセスさせる 3 つのアプローチを整理した上で、そのうちの「IFC をグラフに変換してグラフデータベースに格納し、AI エージェントが問い合わせる」という構成を、実装レベルで解説しました。要点は次のとおりです。 IFC → Turtle の変換を AWS Batch で実行し、 bot: / props: 系のオントロジーで「建物 → 階 → 要素」のグラフを生成 自然言語の質問から SPARQL を生成して回答する仕組み（text-to-SPARQL）を構築。各ファイルのスキーマやサンプルクエリを事前に用意しておくことで AI エージェントが素早く正確に情報を取得できる 建物のグラフデータは、Amazon Neptune ML で GNN を組み合わせて、干渉解消の優先度予測・多ゾーンの熱負荷予測・BIM の意味付け補強といった、生成 AI 単体では解決しにくいタスクに広げられる可能性がある このアプローチの一番の利点は、データ構造を自分たちの用途に合わせて設計できることです。1 章で見たアプローチの比較に戻ると、ベンダー API の範囲で実現する方法や、ライブラリで IFC をその場で読む方法に対して、本ブログで紹介した手法は IFC を予め整理した状態で持っておくことで、複数ファイルの横断検索や集計の書きやすさも、他システムのデータとの突き合わせもスキーマ設計で吸収できます。一方、柔軟性と引き換えに変換パイプラインやデータベースを設計・運用するコストがかかるため、ユースケースに応じて、上手く使い分けるのが良いでしょう。

本ブログでは、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースで展示するデモを題材に、AWS のクラウドサービスと産業用ロボットを組み合わせた自律オペレーションの実現方法をご紹介します。 はじめに Physical AI とは、ハードウェアを通じて物理世界を知覚し、ソフトウェア側で理解・推論・学習を行い、再びハードウェアを通じて物理世界に働きかける技術です。テキストの内容を返すデジタル AI とは異なり、ロボットやヒューマノイド、AGV といったハードウェアを通じて、物理的なアクションを自律的に実行します。AI とロボティクスの双方が同時に進化しブレークスルーを迎えた今、製造・物流・インフラ管理など、あらゆる産業の現場オペレーションが変革されようとしています。 従来の産業用ロボットは事前にすべての動作をプログラミングする必要があり、予期せぬ状況や形状が変化する対象物には対応できないという壁がありました。Physical AI は状況を自ら判断し、不確実性の高い環境にも適応できます。ここに、AI エージェントが自律的に「調査し、判断し、実行する」能力が加わることで、真に自律的なオペレーションが可能になります。 Physical AI とは — Agentic AI が現実世界に出るとき 本デモにおける Physical AI の中核 — Agentic AI 本デモにおける Physical AI の中核は、AI エージェント（Agentic AI）です。ソフトウェアの世界で発展してきたエージェントの能力 — ツール呼び出し、メモリへの学習蓄積、計画立案と実行 — を、カメラやセンサーによる「知覚」とロボットアームや自律走行車両による「行動」へと拡張し、知覚 → 判断 → 行動のループを自律的に回します。 なぜ今 Physical AI なのか Physical AI が注目される背景には、いくつかの技術的ブレークスルーがあります。 LLM の推論能力の飛躍的向上 — 複雑な状況判断や計画立案が可能に Agentic AI フレームワークの成熟 — ツール呼び出し、メモリ管理、マルチエージェント協調が実用レベルに クラウド-エッジ連携の高度化 — 低遅延通信と安全な制御の両立 協働ロボットの普及 — 人と同じ空間で安全に動作するロボットが入手可能に これらが揃った今、AI エージェントが現実世界で自律的にオペレーションを遂行する時代が到来しています。 デモコンセプト — 「知らない状態」から自律的に解決する 概要 現実世界とつながった AI エージェントが、想定外の障害に対して自ら調査し、自ら考え、ロボットを動かして解決する。 私たちが構築したデモは、空想の街に Amazon のラストワンマイル配送を模した配送網を作り、来場者が自由に障害を仕掛けることで、AI エージェントの自律的な問題解決能力を体験してもらうものです。 重要なのは、これが 事前にプログラムされたシナリオではない という点です。来場者が自由に障害物を配置するため、毎回異なる状況が発生します。AI エージェントは障害の存在も位置もあらかじめ知らない「ゼロ」の状態から、調査・判断・実行を自律的に回していきます。 来場者体験の設計 来場者の目の前には2つの画面が並びます。 画面 内容 AI エージェントの思考 AI エージェントがいま何を考え、次に何をしようとしているかをリアルタイム表示 AI が認識している世界 AI エージェントが現時点で認識している世界。調査が進むにつれて実際の状態に近づく この2つを見比べることで、AI がまだ何を知らず、いま何を考え、どう行動しようとしているかが一目でわかります。リアルタイムダッシュボードではエージェントの調査計画・復旧方針が逐次可視化されます。 デモフロー — 5ステップの自律オペレーション デモは1サイクル約3〜4分で、以下の5ステップで進行します。 Step 1: 通常配送（デモの起点） 空想の街で、配達車両（TurtleBot）が物流・倉庫エリアから配送先へルートを巡回しています。配送網は正常に動いており、来場者にはまずこの「通常状態」を見てもらいます。 Step 2: 来場者が障害を発生させる 来場者が配送ルート上に障害物を配置すると、配達車両が障害物を検知して停止し、配送が止まります。障害の場所は来場者が自由に決めるため、毎回パターンが異なります。 Step 3: AI エージェントが調査を開始する 配送停止を検知した AI エージェントが、障害の特定に動き出します。FANUC CRX-20iA/L 協働ロボットのアーム先端カメラ（FRAMOS D435e）でトラブルが起きた通りを探索し、段階的にデータを収集します。 以下のループで段階的に進みます。 周辺調査 — トラブルが起きた通りをカメラで撮影する 認識の更新 — 得られたデータをもとに AI が自分の地図を更新する 次の調査計画 — 追加で調べるべき箇所があるかを判断する 一発で全容がわかるわけではなく、このループを繰り返しながら障害を見極めます。 Step 4: 復旧の実行 障害物を特定した AI エージェントが、FANUC ロボットに除去を指示します。ロボットが障害物を把持し、ステージ上の回収エリアへ移動させることで道路を開通させます。把持できない障害物を発見した場合は、オペレーターに支援を要請します。 Step 5: 配送再開 復旧が完了すると、AI エージェントは配達車両に配送再開の指示を出します。来場者が止めた配送網が、目の前で復旧されます。 システムアーキテクチャ 設計原則 本システムは以下の原則に基づいて設計されています。 知性が必要な処理はクラウドで実行 — 物体認識、コンテキスト判断、アーム制御指示、車両の再開指示は LLM の推論力を活かしクラウドから発行 物理的な動作実行はエッジで処理 — クラウドからの指示を受けたモーションプランニング（MoveIt 2）やセンサー処理はエッジ PC 上で実行 通信断に耐える設計 — クラウドとの通信が切れた場合、アームは安全停止し、復旧後にクラウドから再開指示を受ける 全体構成 ▲ 知性が必要な処理はクラウド（Amazon Bedrock AgentCore / Amazon Bedrock / Amazon Polly）で実行し、物理的な動作実行はエッジ（ROS 2 / MoveIt 2）で処理。AWS IoT Core がクラウドとエッジをセキュアに接続します。 通信方式 通信経路 プロトコル 理由 FANUC ロボット AI エージェント AWS IoT Core（MQTT 5）Request/Response 低遅延・双方向制御。TLS 相互認証による安全性 配達車両 クラウド AWS IoT Core（Device Shadow） Named Shadow で走行状態・停止/再開・バッテリー・温度などを管理 ダッシュボード UI クラウド AWS IoT Core（MQTT 5）+ HTTPS エージェントの思考過程をリアルタイムに配信 使用する AWS サービス Amazon Bedrock AgentCore Runtime — AI エージェントの実行基盤 Amazon Bedrock AgentCore は、AI エージェントをインフラ管理不要でデプロイ・運用できるマネージドサービスです。本デモでは、AgentCore Runtime 上で動作する AI エージェントが、推論モデルに Amazon Bedrock の Claude Sonnet 4.6 を使用し、ツール呼び出し（ロボット制御 API）、メモリ（調査結果の蓄積）、データ（地図情報）を統合的に管理して、調査計画の立案から復旧指示までを自律的に遂行します。 Amazon Bedrock（Claude 4.5 Haiku）— 視覚認識と推論 Amazon Bedrock 上の Claude 4.5 Haiku が、D435e カメラから取得した画像をもとに周囲の状況を認識します。障害物の有無や周囲の状況を考慮した最適な行動の推論を担当します。 AWS IoT Core — エッジとクラウドの架け橋 AWS IoT Core が、会場内のロボットとクラウド上の AI エージェントをセキュアに接続します。MQTT 5 の Request/Response パターンによるアーム制御と、Device Shadow による配達車両の状態管理を実現します。通信断が発生しても最後の既知状態から安全に復帰できます。 Amazon Polly — AI の声 Amazon Polly により、AI エージェントの判断内容を音声で来場者に伝えます。「状況を確認します」「障害物を探します」「障害物を発見しました」「障害物を取り除きます」といったナレーションがデモの臨場感を高めます。 ハードウェア構成 FANUC CRX-20iA/L 協働ロボット × 2台 FANUC CRX-20iA/L は、可搬質量 20kg、リーチ 1,418mm の協働ロボットです。人と同じ空間で安全に動作します。 項目 仕様 リーチ 1,418 mm 制御装置 R-30iB Mini Plus 安全機能 接触検知による即時停止 ロボットハンド OnRobot 2FG7（ストローク 最大 68mm） カメラ FRAMOS D435e（RGB + Depth） 2台の CRX はそれぞれ担当エリアを持ち、AI エージェントの指示のもとで協調動作します。調査時はアーム先端の FRAMOS D435e カメラで隣接エリアを撮影し、復旧時はロボットハンド（OnRobot 2FG7）で障害物を把持して回収エリアへ移動します。 TurtleBot3 Burger — 配達車両 配送網を走行する自律走行ロボットです。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 ジオラマステージ 3,640mm × 3,640mm の木工ステージ上に、3D プリンタで製作したミニチュアの街を配置します。周回トラックには「オレンジ通り」「ブルー通り」「グリーン通り」「パープル通り」の4つの通りがあり、配達車両の走行ルートとしています。 道路は黒地マット仕上げの上に白線（幅 30mm）を敷設し、配達車両がライントレースで追従します。配送・積荷のポイントには配達車両のための停止線を配置しています。 AI エージェントの意思決定 — 調査し、学習し、適応する 1ターン = 1アクション AI エージェントは毎ターン、以下のアクションから1つを選択して実行します。 アクション 内容 調査 FANUC ロボットの FRAMOS D435e カメラで対象エリアを調査 障害物除去 FANUC ロボットで障害物を把持し、回収エリアへ移動 エージェントは MAP の構造（道路レイアウト）とスタート/ゴール位置は既知ですが、障害物の位置は一切知りません。 調査の選択 調査を行うかどうかは、AI エージェントが自律的に判断します。配達車両が障害物を検知した後、AI エージェントは FANUC ロボットのカメラで状況を確認し、把持可能な障害物かどうかを見極めてから行動を計画します。これは事前にプログラムされた手順ではなく、状況に応じた AI エージェントによる自律的な判断です。 障害物除去戦略の判断 障害物を発見した AI エージェントは、カメラ画像から障害物の形状・サイズを認識し、ロボットハンドで把持可能かを判断します。把持可能と判断すれば、ロボットに除去を指示し道路を開通させます。把持が困難と判断した場合は、オペレーターに支援を要請します。 まとめ 本ブログでは、AWS Summit Japan 2026 の Physical AI ブースで展示するデモを通じて、AI エージェントが現実世界で自律的にオペレーションを遂行する仕組みをご紹介しました。 このデモのポイントは以下の通りです。 想定外への対応力 — 事前に定義されたシナリオではなく、予測不能な状況に AI が自律的に対応する 調査から解決まで一気通貫 — 障害の検知・調査・判断・復旧までを AI エージェントが自律的に完走する リアルタイム可視化 — ダッシュボードにより、エージェントの思考と行動が常に可視化される クラウド AI × ロボットの協調 — クラウド上の AI エージェントが判断し、現場のロボットが実行する新しいオペレーションモデル Physical AI は、AI が「考える」だけでなく「行動する」時代の到来を示しています。AWS のクラウドサービスとロボティクスの組み合わせにより、この未来は今まさに実現可能になっています。 体験機会のご案内 Physical AI デモの実物は、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースでご覧いただけます。AI エージェントが現実世界で自律的に問題を解決する様子を、ぜひ目の前で体験してください。 AWS を活用した Physical AI ソリューションにご興味のある方は、ぜひ お問い合わせ ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 いよいよ、今週 6/25(木)、26(金) で AWS Summit Japan 2026 が幕張メッセで開催されます。私もブース対応や登壇を行いますので、現地で私を見たらぜひお声かけください。Builders Fair のコーナーで、VR ゴーグルと体にセンサーをつけて計測するパデルフォームのコーチングシステムを展示しています！詳細は こちら 。私が所属する Retail CPG でも Retail エリアがあり、私はスマートグラス、音声 AI を使った店舗業務改善のデモも担当しております。Retailブースエリアの紹介もこちらの ブログ を参照ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月15日週の主要なアップデート 6/15(月) AWS WAF が AI トラフィック収益化機能を発表 AWS WAF が Bot Control 機能の一部として AI traffic monetization を発表しました。この機能により、コンテンツ所有者やパブリッシャーは、AI ボットやエージェントがコンテンツや API にアクセスする際に、エッジで直接価格設定、計測、決済を行うことができます。x402 オープンプロトコルを使用した machine-to-machine 決済により、AI エージェントは自律的に支払いを行い、コンテンツにアクセスできます。決済は Coinbase の x402 Facilitator を通じて USDC (stablecoin) で処理され、CloudFront のすべてのエッジロケーションで利用可能です。追加料金はなく、標準の AWS WAF 料金のみが適用されます。 AWS DevOps Agent がカスタム SRE エージェントと MCP/A2A プロトコルに対応 AWS DevOps Agent は、カスタム SRE エージェント、bring-your-own sub-agents、MCP (Model Context Protocol) および A2A (Agent-to-Agent) プロトコル経由のヘッドレスアクセスに対応しました。これにより、チームは定期的な SRE ワークフローの自動化、他のエージェントとの接続による DevOps Agent の拡張、Kiro、Claude、その他のコーディングアシスタントなど既存ツールからの機能アクセスが可能になります。カスタム SRE エージェントでは、Agent Space 内でスケジュール実行されるエージェントを作成できます。また、チャット機能の強化、カスタマー定義ルールによるインシデントスキップ、メモリーと Git 管理スキルによる知識強化、タスク品質追跡用の人手ラベリングとカスタマーダッシュボードが追加されました。こちらは、5 つの新リージョンで追加対応されています。 Amazon CloudWatch Log Analytics を発表 Amazon CloudWatch は Log Analytics という統合コンソール体験を提供開始しました。これは CloudWatch Logs Insights (ログクエリと分析)、Live Tail (リアルタイムログストリーミング)、Contributor Insights (トップコントリビューター分析) を 1 つの画面に統合したものです。複数のタブで異なるクエリを同時実行でき、パターン分析、パラメータ付き保存クエリ、ファセット、自然言語クエリ生成、ビジュアライゼーションなどの既存機能もすべて利用できます。Log Analytics はデフォルトの体験となり、すべての商用 AWS リージョンで利用可能です。料金は基盤となる各機能 (Logs Insights クエリ、Live Tail、Contributor Insights) と同じです。 Amazon Bedrock AgentCore Memory が long-term memory に厳密に一貫したメタデータをサポート Amazon Bedrock AgentCore Memory の long-term memory に、メタデータの抽出タイプとして STRICTLY_CONSISTENT が追加されました。これにより、アプリケーションから直接設定したメタデータ値が LLM の推論を経ることなく、そのまま long-term memory レコードに記録されるようになります。この機能は、部署別のスコープ検索、コンプライアンス境界の管理、マルチテナント環境でのテナントごとの独立処理を実現します。戦略ごとに最大 3 個の STRICTLY_CONSISTENT キーを設定でき、semantic、user preference、episodic 戦略で利用可能です。 AWS Transform が技術負債の自動検出と修復を行う continuous modernization 機能を発表 AWS Transform は、エンタープライズのソフトウェアポートフォリオ全体で技術負債を自動的に検出・優先順位付け・修復する continuous modernization 機能 (プレビュー) を発表しました。数千のリポジトリを対象に、古い依存関係、非推奨フレームワーク、セキュリティ脆弱性を自動で修復し、プルリクエストを自動生成します。料金は $0.035 / エージェント分で、US East (N. Virginia) と Europe (Frankfurt) で利用可能です。GitHub、GitLab、Bitbucket と統合し、Kiro、Claude Code、Cursor などの agentic IDE から利用できます。 6/16(火) Amazon Quick が Adobe、Figma、WhatsApp など 16 の新しいコネクタで統合を拡大 Amazon Quick は 16 の新しいツールとの統合を開始しました。これにより、チームはデータ、分析、デザイン、コミュニケーションアプリからのインサイトに基づいて、コンテキストを切り替えることなくアクションを実行できるようになります。新しいコネクタには Adobe、Figma、WhatsApp、Snowflake などが含まれ、生産性、デザイン、分析、データインフラ、金融インテリジェンス、コマース、コミュニケーション領域をカバーします。チームは数分で新しいツールをワークスペースに追加し、Quick Flows、Chat、Spaces で既存の統合と組み合わせて利用できます。 AWS Blocks、アプリケーションバックエンドを構成するオープンソースフレームワーク (プレビュー) を発表 AWS は、インフラツールの学習を不要にするオープンソース TypeScript フレームワーク AWS Blocks のパブリックプレビューを発表しました。ローカル環境では AWS アカウント不要で Postgres、認証、リアルタイムメッセージングが動作し、本番デプロイ時もコード変更なしで AWS サービス上で実行できます。開発者は単一セッション内でデータベーステーブル、ユーザー認証、AI エージェント、ファイルアップロード、バックグラウンドジョブを追加し、フルスタックをローカルでテストした後、準備が整った段階で AWS にデプロイできます。料金は AWS Blocks 自体に追加費用はなく、使用した AWS サービスの料金のみが発生します。 Amazon S3 Vectors が類似性検索で最大 10,000 件の結果返却に対応 Amazon S3 Vectors の QueryVectors API が、1 回のクエリで最大 10,000 件の類似性検索結果を返却できるようになりました。これは以前の制限値 100 件から 100 倍の増加です。結果は複数ページに分割して返却され、最初のページから順次処理を開始できます。クエリごとに最初の 512 KB のデータ返却は無料で、超過分には $0.01/GB のデータ返却料金が適用されます。この改善により、リランキング、集約、重複排除などのマルチステージ検索パイプラインで、より包括的な候補セットを取得できるようになります。 6/17(水) Oracle Database@AWS が Oracle Autonomous AI Database Serverless に対応 Oracle Database@AWS が Oracle Autonomous AI Database Serverless (ADB-S) に対応しました。ADB-S は、Exadata インフラや VM クラスターのプロビジョニングが不要で、AWS Management Console、CLI、API から直接データベースを作成できる完全マネージド型 Oracle データベースサービスです。コンピュートとストレージが独立してスケールし、AI Transaction Processing、AI Lakehouse、AI JSON Database、Oracle APEX の 4 つのワークロードタイプに対応します。AWS Marketplace の公開オファーおよびプライベートオファーで利用可能で、BYOL (Bring Your Own License) と License Included の両方をサポートします。現時点では US East (N. Virginia) と US West (Oregon) リージョンで提供されています。 AWS Secrets Manager が Agent Toolkit for AWS に安全なシークレット処理スキルを導入 AWS Secrets Manager は、Agent Toolkit for AWS の aws-core プラグインの一部として、secret safety skill を提供開始しました。このスキルにより、開発者は AI コーディングエージェントのワークフロー内でシークレット値を LLM のコンテキストやセッションログに公開することなく使用できます。2 層アプローチ（スキルガイダンスと PreToolUse フック）により、プレーンテキストのシークレットがモデルコンテキスト、セッションログ、エージェントメモリに一切表示されなくなります。Claude Code、Codex、Cursor などのエージェントで利用可能で、Secrets Manager が提供されているすべての AWS リージョンで今すぐ使用できます。 Amazon Bedrock AgentCore harness が一般提供開始 Amazon Bedrock AgentCore のマネージドエージェントハーネス (harness) が一般提供を開始しました。エージェント開発において最も時間がかかるオーケストレーションループ、実行環境、ツール統合、メモリ管理を設定ファイルだけで定義できるようになり、数分でプロダクション対応のエージェントを構築できます。モデルはセッション途中でも切り替え可能で、ツールやスキルの追加も設定変更のみで対応します。harness 自体に追加料金はなく、利用した CPU やメモリなどのリソース分のみ課金されます。 Amazon Bedrock AgentCore のポリシーで Bedrock Guardrails をサポート AWS は Amazon Bedrock AgentCore のポリシー機能で Bedrock Guardrails のサポートを発表しました。これにより、本番環境で AI エージェントをスケールする際に、より深いセキュリティと安全性の制御が可能になります。AgentCore ポリシーは、AI エージェントが実行を許可されるアクションを制御する認可機能です。Guardrails は、プロンプトインジェクション攻撃や機密データの露出を含む、AI エージェントワークロードにおける主要なセキュリティおよび安全性リスクに対する防御を提供します。Guardrails は、許可されたすべてのエージェントアクションの出力と、ゲートウェイターゲット（ツール、エージェント、モデル）へのすべての呼び出しの入力をリアルタイムで評価し、ダウンストリームシステムに到達する前にプロンプトインジェクション攻撃、有害コンテンツ、機密情報の露出を検出してブロックします。 AWS Glue Data Catalog がビジネスコンテキストとセマンティック検索をサポート（プレビュー） AWS Glue Data Catalog に、ビジネスコンテキストの付与とセマンティック検索機能がプレビューとして追加されました。Glossary terms、custom metadata fields (Forms)、Skill assets の 3 つの仕組みでテーブルやカラムに業務的な意味を付与でき、新しい Search API で semantic meaning による検索が可能になります。Claude Code などの MCP 互換エージェントは、Agent Toolkit for AWS の aws-data-analytics plugin を使うことで、ほぼセットアップなしで Data Catalog にアクセスできます。現在、US East (N. Virginia、Ohio)、US West (Oregon)、Europe (Ireland) の 4 リージョンでプレビュー提供中です。 Amazon Bedrock AgentCore に継続的改善機能を追加、プロダクション環境のエージェントを最適化 AWS は Amazon Bedrock AgentCore に新しい最適化機能を追加し、プロダクション環境のトレースからエージェントを継続的に改善できるようになりました。この機能は「サイレント障害」（エラーを出さないが実際には失敗している動作）を検出し、データに基づいた修正案を生成し、統計的に検証します。Failure insights、Intent insights、Trajectory insights の 3 つの分析機能は本日 13 リージョンでプレビュー提供開始、Batch evaluation、Recommendations、A/B testing は本日 14 リージョンで一般提供開始されました。AgentCore Runtime、AWS Lambda、Amazon EKS、非 AWS 環境など、実行環境を問わず利用できます。 AWS DevOps Agent がリリース管理機能を追加 (プレビュー) AWS DevOps Agent がリリース管理機能のプレビューを開始しました。この機能は、コード変更のリリース準備状況を評価し、自律的なリリーステストを実行することで、本番環境へのコードデプロイを安全に行えるようにします。リリース準備レビューでは、内部標準からの逸脱、依存関係の影響、アクセス制御をチェックし、決定論的証明を使用してインフラ変更が AWS Well-Architected のベストプラクティスに準拠しているか検証します。リリーステストでは、Web および API ベースのアプリケーション向けにテスト計画を生成・実行し、回帰、UX の問題、統合の失敗を検出します。プレビュー期間中は US East (N. Virginia) リージョンで追加費用なしで利用できます。 6/18(木) Amazon GameLift Servers がコンテナフリートの新機能を追加 Amazon GameLift Servers は、コンテナフリートに 2 つの重要な機能強化を実施しました。1 つ目は、コンテナグループ定義で Linux capabilities をカスタマイズできるようになり、NET_RAW や SYS_PTRACE といった特殊な権限を付与できます。2 つ目は、新しい Server SDK API である ListContainersNetworkInfo() を追加し、同一インスタンス上で実行される全コンテナのネットワーク情報 (コンテナ名、ID、ローカル IP アドレス、コンテナグループタイプ) を取得できるようになりました。これにより、ゲームサーバーとメトリクス収集コンテナ、ログエージェント、キャッシュシステムなどの補助サービス間の自動サービス検出と通信が簡素化されます。 AWS Compute Optimizer が EBS ボリューム推奨で IOPS とスループットスパイクの可視性を強化 AWS Compute Optimizer は、Amazon EBS ボリュームのライトサイジング推奨を提供する際に、IOPS とスループットのスパイクに対する可視性を向上させました。新たに VolumeIOPSExceededCheck と VolumeThroughputExceededCheck という 2 つの CloudWatch メトリクスを分析対象に追加し、ワークロードがプロビジョニングされたパフォーマンスを超えて IOPS やスループットを要求したかどうかを 1 分単位で検出できるようになりました。この機能により、バースト性の高いワークロードにおいて、コストとパフォーマンスのバランスを取ったライトサイジング判断が可能になります。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

2026 年 6 月 1 日、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」の第 1 回コミュニティイベント「Community Meetup #1」を、 AWS ジャパン 麻布台オフィス にて開催しました。本プログラムは 2026 年 1 月 27 日に発表し 、 3 月 3 日にキックオフイベント を開催しました。今回の Community Meetup は、約 6 ヶ月間の開発支援期間のなかで、採択企業同士の交流を主な目的として開いた初めてのコミュニティイベントです。 フィジカル AI 開発支援プログラムとは フィジカル AI とは、物理世界で動作する AI の総称です。 AWS では、これを「物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステム」と定義しています。大規模言語モデル（LLM）の進化を背景に、視覚情報と言語、行動を統合的に扱う Vision-Language-Action（VLA）モデルをはじめとしたロボット基盤モデルの研究開発が、世界的に加速しています。 本プログラムは、AWS 上でこうしたロボット基盤モデルを開発する、日本に法人または拠点を持つ企業・団体を支援する取り組みです。データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまで、開発の一連のパイプラインづくりを、技術支援・コスト支援・コミュニティ形成・GTM 支援の 4 つの柱で支えます。 本プログラムが大切にしているのは、技術的な側面にとどまらず、一つのコミュニティとして共に取り組み、育てていくという考え方です。今回の Community Meetup は、その実践の第一歩として企画しました。 イベント概要 当日のアジェンダは以下のとおりです。 オープニング パネルディスカッション（採択企業 3 社が登壇） アンカンファレンス（テーマ別のグループディスカッション） クロージング ネットワーキング 以降では、パネルディスカッションとアンカンファレンスの様子をご紹介します。 パネルディスカッション 前半は、本プログラムに参画いただいている 3 社の方々によるパネルディスカッションです。AWSの針原をモデレーターとして、それぞれ異なる立場からフィジカル AI に取り組む登壇者をお迎えしました。 小堀 訓成 様 (株式会社メルカリ 研究開発組織R4D 所長) 末永 匡 様（株式会社Enactic オープンソース事業部長） 鈴木 徳馬 様（株式会社JDSC データサイエンティスト） 各社の取り組み 3 社それぞれ立場は異なりますが、「現実世界のデータをどう集め、どう活かすか」という共通の課題に向き合っています。 株式会社メルカリの小堀 訓成 様は、自社倉庫の作業をロボットに置き換える取り組みを紹介しました。海外向け出荷では、届いた商品の検品や、ブランド品が本物かを確かめる真贋判定、梱包までを人手で行っていますが、これらをロボットで担うことを目指しています。中古品はバリエーションが大きいため、まずはばらつきの小さい品目から着手しているといいます。たとえば靴、なかでもスニーカーのように形状が比較的安定したものを選び、テレオペレーション（遠隔操作）でロボットを動かして学習用データを集めています。 続いて、株式会社Enacticの末永 匡 様は、同社が開発するオープンソースのロボットアーム「OpenArm」について語りました。末永様が強調したのは、Sim-to-Real ギャップは大きく、実機でのデータ収集が重要だという点です。そのうえで、実機データの「質」と「量」をいかに確保するかが課題になるといいます。データの「質」は、操作者のスキルだけでなく、映像とロボットの関節データのタイムスタンプのずれといった見えにくい要素にも左右されるそうです。「量」を確保するには、収集作業の自動化や、並列に集める工夫が効くといいます。2026 年 5 月にリリースされた OpenArm 2.0では、アーム本体の改良に加え、照明や電源などをパッケージ化し、同じ条件でモデルを評価できる標準実験環境「OpenArm Cell」が含まれており、データの「質」と「量」の改善に寄与するとアピール。さらに、人間の肩にかけられる軽量かつ高精度な教示デバイス「OpenArm KER」の開発も進めているとのことです。OpenArm の GitHub スター数は、登壇時点で 2,500 ほどに達しており、オープンソースを起点にコミュニティが広がっています。 株式会社JDSCの鈴木 徳馬 様は、物流分野のパートナー企業と連携して参加しています。フィジカルAIの研究開発を行っていたタイミングで本プログラムの話が重なり、共同での参加に至ったそうです。実機でのデータ収集は重要です。一方で、人手作業はどうしてもばらつき、時間もかかります。そこで、シミュレーター内で合成データを生成し、量をスケールさせるアプローチを採用したといいます。実機とシミュレーションのそれぞれの長所をどう組み合わせるかが、議論の焦点となりました。 技術的な課題と AWS の支援 フィジカル AI の開発には、シミュレーションや大規模な学習など、つまずきやすい局面が数多くあります。パネルでは、そうした課題に直面したときに AWS がどう支援したかが語られました。 その一例として、株式会社JDSCの鈴木様がシミュレーションの事例を紹介しました。同社では、シミュレーター「Isaac Sim」での合成データ生成が GPU でうまく高速化できず、開発が思うように進みませんでした。社内の定例会で議論しても解決しきれなかったため、AWS を通じて NVIDIA に問い合わせ、一緒に原因を探ったところ、Isaac Sim 自体ではなく、その土台となる物理シミュレーターに起因する問題だと分かったといいます。これを踏まえ、同社は現在、使い慣れた別のシミュレーターと AWS Batch を組み合わせて合成データの生成を進めています。 この事例のように、一社では解決が難しい課題に対しても、AWS は日本の担当チームに加え、AWS グローバルのスペシャリストや NVIDIA のようなパートナーと連携して支援にあたります。株式会社メルカリの小堀様も、分散学習について個別にレクチャーを受けられた経験に触れ、「困っていることを相談すると、課題に適したエンジニアを呼んでくれる。かゆいところに手が届く」と語ってくださいました。答えを示すだけでなく、お客様とともに考えながら解決策を探っていくことを、本プログラムの技術支援では大切にしています。 会場との質疑応答 会場との質疑も活発でした。たとえば「現在の VLA モデルは英語ベースのものが多いが、日本語への対応は必要か」という問いには、登壇者から「英語で作って日本語に変換しても問題なく動くことが多く、現時点で言語は大きな障壁ではない。ただし触覚を表すオノマトペのような日本語特有の表現には工夫が要るかもしれない」といった実感が共有されました。照明の条件が学習データの質を左右するといった、現場ならではの作り込みについても質問が交わされました。 終盤には、「身体性があるからこそ生まれる知性はあるのか」「そもそもフィジカル AI とは何か」といった、より本質的な問いも飛び交いました。「入力か出力のどちらかに物理が関わっていればフィジカル AI ではないか」「ヒューマノイドに限らず、ロボットアームも、さらには工作機械も含まれるのではないか」など、登壇者それぞれの定義が語られました。 アンカンファレンス 後半は「アンカンファレンス」を行いました。これは、決まった発表を聞くのではなく、参加者が実際に困っていることや関心を本音で語り合うグループディスカッションの形式で、AWS の Tech コミュニティでも好評の進め方です。 まず全体で各社の開発進捗を共有したところ、多くのチームがまだ実機を導入して動作確認する段階にあり、本格的なモデル開発はこれからプログラム後半にかけて行うという状況が各社に共通していました。その後、希望の多かったテーマごとに分かれて議論を深めました。たとえばシミュレーションの活用場面については、多数を並列に回せる強化学習では有効な一方、実機で丁寧にデータを取りたい模倣学習とは相性が異なるといった使い分けが話題になりました。また、公開モデルはベンチマークでは高性能でも実機や異なる環境では期待どおり動かないことがあり、何を基準に選ぶか悩ましいという声も挙がりました。 普段はなかなか共有しづらい悩みや知見が、率直に語り合われました。 コミュニティとしての意義 パネルディスカッションとアンカンファレンスを通じて、各社が共通の課題に直面している様子が浮かび上がりました。データ収集の難しさ、ハードウェアとソフトウェアの融合、研究と社会実装のギャップ、計算資源へのアクセスなど、その多くは一社だけで解決するのが難しいものです。立場の異なる開発者が本音で知見を交換できる場は、こうした課題に向き合ううえで一つの助けになります。実際に、参加企業同士が連携して開発に取り組む動きも生まれています。 AWS は、開発者の皆さまが課題を持ち寄り、ともに議論を深められる伴走者でありたいと考えています。今後もこうしたコミュニティの場を重ねていきます。 今後のスケジュール 支援期間中、引き続き各種イベントを予定しています。 ※ 以下の日程・内容は調整中のものを含みます。最新の情報は各社の担当チームよりご案内します。 時期 イベント 内容 2026年6月12日 GENIAC ロボット基盤モデルの研究開発応募者向け勉強会 ロボット基盤モデルをスケーラブルに開発するための環境について、応募者向けに情報を提供します 2026年6月24日 ロボット勉強会 AWSのフィジカルAIスペシャリストがグローバルの動向を紹介するほか、ロボットメーカーを招き、協働ロボットの活用について学びます 2026年6月25–26日 AWS Summit Japan 幕張メッセにて開催。本プログラムの開発成果のデモ展示などを予定しています 2026年8月31日（調整中） 最終成果報告会 プログラムの成果発表と、採択企業による開発内容の共有を予定しています おわりに 第 1 回 Community Meetup を通じて、日本のフィジカル AI を担う多様な企業・関係者が一堂に会し、率直な対話を交わすことができました。ご登壇いただいた 3 社の皆さま、そしてご参加いただいた採択企業の皆さまに、心より御礼申し上げます。 AWS は、本プログラムを通じて日本のフィジカル AI エコシステムの発展に貢献してまいります。次回のコミュニティイベント、そして成果発表会をどうぞご期待ください。 関連リンク フィジカル AI 開発支援プログラム by AWS ジャパン 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました 「Physical AI on AWS 勉強会 #1」を開催しました   「NVIDIA Robotics Solutions 勉強会」を開催しました

本記事は 2026 年 6 月 8 日 に公開された「 Announcing Amazon RDS for Db2 12.1 with additional community edition 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 で IBM Db2 12.1 がサポートされました。Db2 データベースエンジンの最新世代です。今回のアップグレードに加えて、新しいエディション Community Edition (db2-ce) も導入され、Amazon RDS for Db2 インスタンスのプロビジョニング時に、3 つのエディションから選択できるようになりました。 本記事では、Db2 12.1 の新機能の紹介、Community Edition の概要と活用シーン、AWS マネジメントコンソール・AWS Command Line Interface (AWS CLI)・Terraform を使った開始方法、そして Db2 11.5 からのアップグレードパスについて説明します。 エディション エンジン識別子 推奨用途 Community Edition (new) db2-ce 開発、テスト、非本番ワークロード Standard Edition db2-se 汎用的な本番ワークロード Advanced Edition db2-ae より多くの CPU とメモリリソースを必要とするミッションクリティカルなワークロード Db2 12.1 の新機能 IBM Db2 12.1 は、 200 以上の新機能と機能強化 を含むメジャーリリースです。RDS ユーザーに特に関連するハイライトを紹介します。 AI を活用したクエリ最適化 Db2 12.1 には、機械学習 (ML) でカーディナリティ推定を改善する AI Query Optimizer が統合されています。カーディナリティ推定とは、クエリプランの各ステップで何行のデータが処理されるかをエンジンが予測することです。推定精度が向上すると、より適切なクエリプランが生成され、手動チューニングなしで複雑な分析やミックスワークロードのパフォーマンスが向上します。モデルのトレーニングは高速化され、よりコンパクトになり、mod pack (マイナーバージョン)リリースごとに精度も向上しています。 名前空間の分離とマルチテナンシー Db2 12.1 では論理的な名前空間の分離が導入されました。単一のデータベース内で、異なるデータベーススキーマのセットを互いに分離できます。データベース管理者は、別々のデータベースインスタンスを用意する手間なく、複数のチームやアプリケーション層のデータオブジェクトをきれいに分割できます。 セキュリティの強化 今回のリリースでは、テーブルスペース管理権限が追加されました。DBA はストレージグループ内でのテーブルスペースの作成と管理を委任できます。最小権限アクセスモデルにとって大きな改善です。既存の RDS for Db2 と AWS Key Management Service (AWS KMS) および AWS Secrets Manager の統合と組み合わせることで、データベースエンジンと AWS インフラストラクチャ層の両方にまたがる多層的なセキュリティ体制を構築できます。 管理性の向上 12.1 のその他の機能強化には、外部テーブル管理、KMIP クライアント証明書の一元管理、カラムナーテーブルのオンライン移動などがあります。本日 RDS for Db2 で提供開始される 12.1.4 mod pack は、運用の効率化と最新のデータプラットフォームへのデータ接続性の拡張に重点を置いています。 Community Edition (db2-ce) の紹介 Community Edition は ライセンス無料 の Db2 エディションで、RDSでは12.1から利用可能になります。開発者、パートナー、小規模ワークロードを運用するチーム向けに設計されています。Standard Edition や Advanced Edition と同じ Db2 コードベースを使用しており、違いは機能の深さではなくリソースのエンタイトルメントにあります。 Community Edition には、IBM ライセンスによる以下のリソース制限があります。 リソース 制限 メモリ 8 GB CPU コア 4 vCPU この制限は、基盤となる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスサイズに関係なく、Db2 エンジンレベルで適用されます。Community Edition デプロイ用のインスタンスクラスを選択する際は、この範囲内に収まるものを選択してください。例えば、Community Edition で利用可能なインスタンスは db.t3.small、db.t3.medium、db.t3.large、db.m7i.large (m7i が利用できないリージョンでは db.m6i.large) です。 注意 : 上記のリソース制限を超えるインスタンスクラスはプロビジョニング時にブロックされませんが、Db2 はライセンス制限までのリソースしか使用しません。 Amazon RDS for Db2 の Community Edition を使えば、IBM ソフトウェアライセンス費用なしでフルマネージドの Db2 12.1 インスタンスを起動できます。支払いは、標準の RDS 料金モデルに従い、基盤となる AWS インフラストラクチャ (インスタンス、ストレージ、I/O) のみです。 注意: Community Edition には IBM ライセンス料がかかりませんが、Amazon RDS for Db2 では db2-ce を含むすべてのエディションで、DB パラメータグループに IBM カスタマー ID と IBM サイト ID が必要です。IBM が使用状況とエンタイトルメントの追跡に使用します。IBM アカウントを使って IBM の Web サイトで無料登録して取得できます。各 ID の用途と入力場所について詳しくは、 Amazon RDS for Db2 のライセンス を参照してください。 Community Edition により、以下のような用途で Db2 on AWS を始めやすくなります。 アプリケーションの開発とテスト – ライセンスコストを気にせず、ブランチやスプリントごとに Db2 インスタンスをプロビジョニングできます。 概念実証 (PoC) – 本番ライセンスを契約する前に Db2 の機能を評価できます。 小規模な非本番ワークロード – Community Edition のリソース範囲で十分な小規模アプリケーションを実行し、必要に応じて Standard Edition や Advanced Edition に切り替えられます。 要件が拡大した場合、Community Edition から Standard Edition または Advanced Edition へのアップグレードは、インプレースのエンジンエディション変更で簡単に行えます。データの移行やインフラストラクチャの再構築は不要です。 既存の RDS for Db2 機能はすべて Db2 12.1 に適用 Db2 11.5 で利用されてきたフルマネージド機能のすべてが、3 つのエディション共通で Db2 12.1 に引き継がれます。 高可用性 同期スタンバイと自動フェイルオーバーによる Multi-AZ デプロイメント。 災害復旧とリードスケーリング リードレプリカとスタンバイレプリカ。地理的な災害復旧のためのクロスリージョンレプリカも含みます。 運用の自動化 ポイントインタイムリカバリ (PITR) 付きの自動バックアップ、マイナーバージョンの自動パッチ適用、ストレージの自動スケーリング。 セキュリティ AWS KMS カスタマーマネージドキーによる保存時の暗号化。 SSL/TLS による転送時の暗号化。 AWS Directory Service for Microsoft Active Directory またはオンプレミスの Active Directory を使用した Kerberos 認証。 モニタリング、Amazon Simple Storage Service (Amazon S3) 統合、ディレクトリサービスアクセス、監査ログに対する AWS Identity and Access Management (IAM) ベースのロール分離。 ライセンスの柔軟性 Bring Your Own License (BYOL) – AWS License Manager で追跡される既存の IBM Db2 ライセンスを使用。 AWS Marketplace 経由の時間課金ライセンス – Standard Edition と Advanced Edition で利用可能な従量制の IBM ライセンス課金。 Community Edition (db2-ce) – IBM ソフトウェアライセンス料なし。ただし IBM カスタマー ID とサイト ID は引き続き必要です。 IBM の Web サイトで無料で取得できます。 可観測性(オブザーバビリティ) Amazon CloudWatch メトリクスとログによるデータベースパフォーマンスモニタリング。 OS レベルのメトリクスの拡張モニタリング。 AWS Lambda 関数を使用した Db2 モニタリングのセルフ構築 。 開始方法 RDS for Db2 12.1 インスタンスは、AWS マネジメントコンソール、AWS CLI、AWS CloudFormation、または Terraform で今すぐ起動できます。 コンソール AWS コンソールで Amazon RDS に移動し、 データベースの作成 を選択します。 エンジンとして IBM Db2 を選択します。 エンジンバージョン 12.1.4 を選び、エディション ( db2-ce 、 db2-se 、 db2-ae ) を選択します。 インスタンスクラス、ストレージ、Multi-AZ、VPC 設定を構成します。 IBM カスタマー ID と IBM サイト ID を入力します。Community Edition を含むすべてのエディションで必須です。Standard Edition と Advanced Edition では、時間課金用の AWS Marketplace ライセンスオプションも選択できます。 データベースの作成 を選択します。 CLI aws rds create-db-instance \ --db-instance-identifier my-db2-12-1 \ --engine db2-ce \ --engine-version 12.1.4.0.sb00080714.r1 \ --db-instance-class db.r6i.xlarge \ --master-username admin \ --manage-master-user-password \ --allocated-storage 100 \ --storage-type gp3 \ --db-subnet-group-name my-subnet-group \ --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \ --no-publicly-accessible 注意: デプロイ時に最新のエンジンバージョンを確認するには、以下のコマンドを使用してください。 aws rds describe-db-engine-versions \ --query "DBEngineVersions[?contains(Engine,'db2')].{Engine:Engine,Version:EngineVersion,Family:DBParameterGroupFamily}" \ --region <RegionName> --output table Terraform Infrastructure as Code を使用する場合、RDS for Db2 のモジュラー Terraform テンプレートが GitHub リポジトリで公開されています。このテンプレートは、リモートステート、ネットワーキング、IAM ロール、AWS KMS 暗号化、パラメータグループ、RDS インスタンス、AWS License Manager 統合を 7 つの組み合わせ可能なモジュールでカバーしています。詳しい手順は、 Deploying Amazon RDS for Db2 using Terraform を参照してください。 Community Edition を選択するには、 5-rds/terraform.tfvars でエンジンとエディションを設定します。 engine = "db2-ce" engine_version = "12.1.4" 4-parameter-group/terraform.tfvars では、パラメータグループモジュールが Db2 12.1 の有効なエディションとして ce を受け付けます。Community Edition でも IBM カスタマー ID とサイト ID は必須です。Standard Edition や Advanced Edition と同様に、パラメータグループの tfvars で設定してください。両方の ID は Create an IBMid ページで無料で取得できます。 Db2 11.5.9 からのアップグレード 現在 RDS for Db2 でエンジンバージョン 11.5.9 を実行している場合、標準の RDS メジャーバージョンアップグレードパスで 12.1 にアップグレードできます。アップグレード前に、 Db2 エンジンバージョンのアップグレード のドキュメントでアップグレード前のチェック事項とアプリケーションの互換性に関する注意事項を確認してください。 注意点: Community Edition (db2-ce) は 12.1 で新たに追加されたもので、11.5.9 には同等のエディションがありません。11.5.9 の Standard Edition または Advanced Edition インスタンスを移行する場合、アップグレード時にエディションを変更できます。ただし、Community Edition を選択すると、IBM のリソース制限 (4 vCPU、8 GB RAM) が適用されます。 ソース DB インスタンスがアップグレードされると、レプリカも自動的にアップグレードされます。 パラメータグループの IBM カスタマー ID とサイト ID のパラメータは、Standard Edition と Advanced Edition のアップグレードで引き続き必須です。 提供リージョン Amazon RDS for Db2 12.1.4+ (Community Edition と db2-se、db2-ae) は、AWS GovCloud (US) リージョンを含む、RDS for Db2 がサポートされているすべての AWS リージョンで本日から利用可能です。完全なリストは、 Amazon RDS for Db2 の提供リージョン を参照してください。 まとめ Amazon RDS for Db2 12.1 は、IBM の最新データベースエンジンをフルマネージドサービスとして提供します。AI Query Optimizer、名前空間の分離、テーブルスペース管理権限といった新機能と、Multi-AZ 高可用性、リードレプリカとスタンバイレプリカ、自動バックアップ、AWS KMS による暗号化といった既存の運用機能を組み合わせています。新しい Community Edition (db2-ce) により、利用の障壁が下がりました。開発、テスト、非本番ワークロード向けに IBM ソフトウェアライセンス料なしでフルマネージドの Db2 12.1 インスタンスを実行でき、ニーズの拡大に応じて Standard Edition や Advanced Edition にアップグレードできます。コンソール、AWS CLI、 GitHub リポジトリの Terraform テンプレートのいずれを使っても、数分で開始できます。始めるには、 Amazon RDS コンソール にアクセスするか、 Amazon RDS for Db2 のドキュメント を参照してください。ぜひ Amazon RDS for Db2 12.1 をお試しいただき、ご質問やフィードバックはコメント欄にお寄せください。 謝辞 Rajib Sarkar 氏にこの記事のレビューを感謝します。 著者について Vikram S Khatri Vikram は、Amazon RDS for Db2 のシニアエンジニア。プロダクトマネジメント、アーキテクト、リーダーシップ、AI エキスパートユーザーなど複数の役割を担当。20 年以上の経験を持ち、ゼロから新しいプロダクトを生み出すことに情熱を注いでいます。 Ashish Saraswat Ashish は、Amazon RDS for Db2 のシニアソフトウェア開発エンジニア。10 年以上のソフトウェア開発経験があります。 Umair Hussain Umair は、Amazon RDS for Db2 チームのシニアデータベースエンジニア。20 年以上のテクニカルリーダーシップと Db2 および Oracle の深い専門知識を活かし、お客様のクラウドでの高パフォーマンスデータベースワークロードの構築と運用を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。

本ブログは、コニカミノルタ株式会社と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS Japan ソリューションアーキテクトの森下です。 本記事では、コニカミノルタ株式会社 ( 以下、コニカミノルタ ) が AWS と共同で 6 年以上にわたり推進してきたクラウド人財育成の歩みと、その最新の到達点の 1 つである事業課題解決型プログラム「AWS Boost Camp!」の取り組み、そして 2026 年 5 月 22 日に開催された最終成果報告会の模様についてご紹介します。 2025 年度 AWS Boost Camp! 最終成果報告会の参加メンバー及びテーマオーナーの皆様。約半年間の取り組みを終えて一堂に会しました。 1. はじめに ─ コニカミノルタについて コニカミノルタは、 1873 年創業の写真材料事業をルーツとし、現在では複合機・プロダクションプリントや、ヘルスケアやセンシングなど多様な事業を展開するグローバル企業です。「Imaging to the People」を長期経営ビジョンに掲げ、長年培ってきた光学・画像・材料などのコア技術に AI を掛け合わせ、既存領域に加えて成長領域へと事業を広げています。 近年では、自社プロダクトのクラウド化や生成 AI の業務活用を進めるとともに、AI とデータの活用を全社的な経営の軸に据えて事業変革を加速しています。こうした取り組みを支える土台として、社内の DX 専門技術者を計画的に育成する取り組みを長年にわたり継続して進めてきました。2024 年度末時点で、コニカミノルタの DX 専門技術者の登録人数は 1,000 名を超える規模に達しています。 2. コニカミノルタの人財育成の歩み コニカミノルタと AWS の人財育成における共同の取り組みは、2019 年にCloud Center of Excellence（以下 CCoE）構想の議論として始まりました。当時から一貫して掲げてきたのは、「座学や資格取得で終わらせず、実プロジェクトで成果を出せる人財を育てる」という思想です。最終的なゴールは、各事業部門が自走してクラウドを活用できる組織能力の獲得に置いてきました。 2020 年からは、AWS が伴走する形で、座学型のクラウド研修と実プロジェクトを題材にした OJT を組み合わせた集中投資型のプログラムを、シーズン制で複数回にわたり実施してきました。各シーズンでは数名規模のチームを並列に編成し、コニカミノルタ独自の DX ロール認定制度と紐付けて受講者のスキル変化を可視化することで、人財育成施策を経営層に KPI として説明できる形に整理しました。 このプログラムは、社内の DX 専門技術者数の急速な拡大とそれに伴う事業部門の多様な課題への対応の必要性から、2024 年度に新たな枠組みである「AWS Boost Camp!」へと進化しました。最大の特徴は、参加者が自部門の実プロジェクト ( 事業課題そのもの ) を題材として持ち込み、AWS のソリューションアーキテクト ( 以下、SA ) と Training and Certification ( 以下、T&C ) チームのインストラクター、そしてコニカミノルタの CCoE メンバーが三位一体で伴走する点です。これにより、研修中に設計したアーキテクチャや実装したプロトタイプが、そのまま事業部門の本番開発へ直結する構造が生まれます。人財育成だけでは予算を確保しづらいという事情を、事業課題の解決と同時に達成する形で解いた試みでもありました。 3. 事業課題解決型プログラム「AWS Boost Camp!」 3.1 プログラム概要 AWS Boost Camp! は、コニカミノルタの人財強化委員会傘下のソフト・ICT 部会を主管とし CCoE メンバーが運営に参画する形で実施しています。第 2 回 (2025 年度) は 2025 年 10 月にキックオフし、 2026 年 5 月の最終成果報告会までのおよそ半年間にわたって実施されました。 カリキュラムは、前半 3 ヶ月でアーキテクチャ設計、後半 3 ヶ月でプロトタイプ実装を進め、これに並行する形で AWS 認定資格取得を目指した自学自習を AWS Skill Builder や T&C インストラクターによる技術サポートを活用して支援する構造としています。各テーマには、AWS SA と CCoE メンバーが定例レビューおよびアーキテクチャ討議を行い、T&C のインストラクターが個別の学習プラン策定や認定試験対策、テーマ共通のオフィスアワー開催などにて支援する体制を組んでいます。 AWS Boost Camp! のカリキュラム構造。 3.2 AWS と コニカミノルタ社 CCoE の役割分担 AWS Boost Camp! の運営においては、 AWS とコニカミノルタ社 CCoE の役割分担を設計しています。 AWS 側は、SA によるアーキテクチャの議論やベストプラクティスの伝達、最新アップデートも踏まえたソリューションの提案 、T&C インストラクターによる認定試験対策・学習進捗のフォローを担います。一方、コニカミノルタ社 CCoE は、社内のセキュリティ・ネットワーク・運用ガイドラインとの整合を確認した上で、各テーマのアーキテクチャ設計にも参画し、社内事情を踏まえた現実解の提示と、プログラム終了後の自走を見据えた知見の社内蓄積を担います。 なおコニカミノルタの CCoE は固定の所属組織ではなく、各事業部門から有志が参画する組織横断のバーチャル組織です。発足当初は10名弱の規模でしたが、その後幅広い事業部門から有志が加わり、現在は 30 名近くにまで広がっています。 AWS Boost Camp! の運営に CCoE の一部が伴走者として参画することは、 CCoE 自体の運営力強化と次世代の AWS 推進人財の育成にもつながっています。 3.3 第 2 回 ( 2025 年度 ) の取り組みテーマ 本プログラムは 2024 年度の第 1 回から同じ枠組みで実施しています。クラウドを活用してどうシステムを構築するかという点は第 1 回・第 2 回に共通していますが、第 2 回ではそこに機械学習や生成 AI に関連したテーマが大半を占めるようになりました。 今回は、コニカミノルタの 4 つの事業領域から、それぞれ 1 テーマずつが取り組み対象として持ち込まれました。それぞれのテーマはいずれも、各事業部門が実際に推進している事業上の課題であり、プログラム終了後にそのまま本番開発へ繋がる前提で設計しています。 具体的な題材は、生産系データに関する AI SaaS の実現、研究開発部門における機械学習パイプラインの再構築、専門ドメイン向けデータ管理基盤、組織横断の生成 AI 活用基盤など、いずれも事業インパクトの大きい課題です。すでにクラウド上で PoC を進めているものもあれば、一から開発する新規プロジェクトもあり、進度はテーマによって様々でした。 4. 最終成果報告会の模様 2026 年 5 月 22 日、2025 年度 AWS Boost Camp! の最終成果報告会を開催しました。各テーマの参加者・テーマオーナー ( 参加者の上長にあたり、各テーマを持ち込んだ事業部門の責任者 ) ・ CCoE メンバー・運営事務局が一堂に会し、4 テーマの成果発表と質疑応答、フィードバックが交わされました。 4.1 テーマ全体の成果 最終成果報告会では、設計を語るだけでなく、必ず「動くもの」をプロトタイプとして開発しデモで示すことが達成基準となっています。各テーマの発表では、初期構想からプロトタイプ完成までの設計判断の過程と技術選定の理由、成果物のデモが共有されました。前提や制約が事業部門ごとに異なる中、Amazon が実践する顧客起点の開発手法である Working Backwards の考え方に基づいて「解くべき課題」を定義し、複数の選択肢を比較して現実解を選び取り、動作するプロトタイプへと結実させる過程は、座学だけでは得られない実践的なアーキテクト思考を養う機会となりました。 Amazon EC2 ベースで構築していた機械学習システムを、 コンテナ x Amazon SageMaker Pipelines を用いて MLOps ワークフローへと再構築した例。いずれのテーマも、 AWS マネージドサービスを組み合わせたエンドツーエンドの構成をもって最終発表に臨みました。 4 つのテーマを横断して、特に評価したいポイントが 3 つ浮かび上がりました。第一に、 Amazon SageMaker AI 、 Amazon Cognito 、 AWS Fargate 、 Amazon Bedrock など AWS の幅広いマネージドサービスを実践的に活用された点です。PoC では Amazon EC2 ベースだったプロジェクトも、マネージドサービスの意義や複数の選択肢のトレードオフを理解した上で設計に落とし込み、実装までを完遂しました。第二に、 AWS 認定試験に向けた学習と実プロジェクトでのアーキテクチャ設計・実装を並行して進められた点です。第 2 回では、プログラムを通じて 7 名が AWS SAA ( AWS Certified Solutions Architect – Associate) に新たに合格し、実務で触れた知識を体系的な学習で補強する学習サイクルが回りました。第三に、CCoE や関係部門との密な連携により、コニカミノルタ独自のポリシーやセキュリティ・ネットワーク観点を設計へ反映できた点です。 特筆すべきは、複数のチームから「AI コーディングエージェントを業務に取り入れる動き」が生まれたことです。 Kiro や Claude Code on Amazon Bedrock 、 Amazon Q Developer などを使いこなして従来の数十倍以上のスピードで開発を進められた経験は、参加者の発表でも強調されました。「一週間ほどを見込んでいたタスクが数時間で完了した」といった声からも、AI ネイティブ開発が現場で着実に浸透し始めていることがうかがえます。 4.2 参加者の声 参加者からは次のような声が寄せられました。 「 AWS のアーキテクトとの議論を通して、複数の選択肢からアーキテクチャを選択する際の考え方を学ぶことができた。」 「AWS には便利な選択肢が多いからこそ取捨選択しなければいけないことを実感した。最適なシステムの構築の重要性と難しさを実感した。」 「 Kiro を活用することで、これまでドキュメント調査に費やしていた時間を、本来の設計判断に充てられるようになった。開発のスピードが従来の数十倍になった実感がある。」 「 AI コーディングエージェントを使いこなすことで、ドキュメントの調査も開発も爆速になった。何より『自分が AWS でモノを作れる』という自信がついた。」 これらに共通するのは、「AWS の知識が増えた」というスキルアップにとどまらない、「クラウドでモノを作るうえでの判断軸」を獲得したという点であり、本プログラムが目指してきた「実践的に活かせる人財」の到達像と言えます。テーマオーナーや運営からも、AWS と CCoE の伴走により各テーマで実用に足る成果を形にできたと高く評価され、参加者が今後は各事業部門で先頭を切ってクラウド活用を主導することへの期待が寄せられました。 5. AI ネイティブ開発への移行に向けた今後の展望 2026 年現在、ソフトウェア開発のあり方そのものが大きく変容しつつあります。従来 AI はコード補完などで開発者を支援する役割が中心でしたが、近年では AI コーディングエージェントが自律的にコードを探索・編集・テストするようになりました。これに伴い、エンジニアの役割はコードを一行ずつ書くことから、解くべき課題を定義し、エージェントに与える仕様やルールを設計し、生成された成果の品質を高めながらレビューし、意思決定を下すことへと比重を移しつつあります。この潮流は、コニカミノルタが 2026 年 4 月に発表した中期経営計画「 Corporate Plan 2026-2028 」が掲げる「AI ネイティブ開発への移行」とも軌を一にしており、本プログラムが今後進化していくべき方向性も、この経営計画と密接に整合する形で検討しています。 私たちは、AI 時代だからこそ人を育てる重要性はむしろ高まっていると考えています。AI エージェントの出力の妥当性を見極めて意思決定につなげるには、クラウドやソフトウェア開発の基礎知識とアーキテクチャ設計の素養が欠かせず、その土台を備えた人が使いこなしてこそ、生産性と品質はともに高まるからです。 このような認識のもと、私たちは現在の AWS Boost Camp! のかたちが完成形だとは考えていません。技術や事業環境、参加者のスキルの変化に応じて、プログラムも柔軟に進化させる必要があります。第 3 回以降に向けては、AWS が提唱する AI-DLC ( AI-Driven Development Lifecycle ) の推進や、Claude Code や Kiro を活用した開発実践の組織的な組込み、CCoE メンバーがより主体的に伴走する設計など、複数の方向性を両社で議論しています。 私たちが見据えているのは、本プログラムを「修了して終わり」にしないことです。力をつけた参加者が、今度はクラウドに不慣れなメンバーを育てる側へ回り、各事業部門のクラウド活用を主導していく。こうして育成と実践のサイクルが自走的に回り続ける体制をつくることが、コニカミノルタが中期経営計画で掲げる持続的成長を、人財の面から支えることにつながると考えています。 中期経営計画「Corporate Plan 2026-2028」が掲げる人財ビジョン。 「すべての参加者にとって本プログラムが AWS への深い理解と AI ネイティブ開発への自信を得るための最良の機会となること」を目標に、コニカミノルタと AWS はこれからも対話と試行錯誤を続けていきます。 6. まとめ 最終成果報告会で見せた 4 テーマの成果は、 AWS のマネージドサービスを実践的に使いこなす力、認定試験を通じた体系的な知見、そして AI エージェントを駆使した開発スピードの劇的な向上が、各事業部門の現場で確実に獲得されたことを示しています。事業課題そのものを題材に持ち込む事業課題解決型へと本質をアップデートした AWS Boost Camp! は、コニカミノルタの中期経営計画が掲げる人財ビジョンを実現していく上で、その役割をますます大きくしていきます。 最後に、本プログラムを半年間にわたり全力で走り抜けてくださった参加者の皆様、テーマオーナーの皆様、運営事務局の皆様、そして CCoE メンバーの皆様に心から感謝を申し上げます。 執筆者 コニカミノルタ株式会社 Cloud CoE 吉田 宏樹 新田 祐士 ソフト・ICT 部会 五寳 匡郎 西村 有史 Amazon Web Services Japan ソリューションアーキテクト　森下 裕介