みなさん、こんにちは。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 ソリューションアーキテクト　森下 裕介  

こんにちは！製造業のお客様を中心に技術支援をしているソリューションアーキテクトの伊藤ジャッジです。だんだん梅雨らしい気候になってきましたね。この時期といえば今年も  AWS Summit Japan 2026  です！今年も IoT の展示の出展はもりだくさんで、 こちら のブログに概要を掲載しています。ぜひ遊びに来てください。このブログでは IoT 展示内の ロボットの遠隔テレオペレーションの ブースの展示について紹介します。 背景 2026 年のものづくり白書 には、政府主導の AI ロボティクス戦略がその中にありました。AI で賢くなったロボットが、これまで自動化が難しかった市場を広げる「フィジカル AI 時代」を見据えた戦略の発表となりました。政府主導のロボティクス推進方針が明確になったことはロボットを製造する側にも使う側にも喜ばしいことですが、一方で、AI の学習に必要なデータがなければ、どんなに性能の良いロボットでも、AI を使って期待した動作をしてもらうことができません。また、学習には高品質なデータが必要となります。幸いなことに日本の産業ロボットの製造業における活用は世界でも最高水準です。そのため、産業ロボットの動作データは潤沢に存在します。政府も日本の強みとして、産業用ロボット、部品・素材、高品質な現場データを土台に、「まず社会実装してデータを取り、モデルを改善し、他分野へ横展開」という循環を確立することを勝ち筋として、上述のものづくり白書で提案しています。 データが必要ということは理解できますが、このデータ収集において大きな壁があります。実は、ロボット開発では、センサー・モーター・カメラなど多数のハードウェアを組み合わせる必要があります。しかし今までは、ロボットメーカーごとにインターフェースが異なり、各社それぞれのロボット制御言語を使用してきました。そのため、ロボットを新規導入する際は、あるロボット向けに書いたソフトを別機種に移植することはできず、一から動作、通信制御、またはデータ連携を作り込むことになり、膨大な開発コストがかかっていました。この状態は各種ロボットが連携する将来を見据えたロボットの動作データの収集という観点では、障壁と言えるでしょう。 このサイロ化したロボット開発環境の問題を解決するため、ROS が登場しました。ROS（Robot Operating System）は、上記の課題を解決するオープンソースの共通フレームワークです。標準化された通信の仕組みとツール群を提供し、開発者はハードウェアの違いを意識せずにロボットの機能開発に集中できます。さらに、ROS2 の登場をきっかけに近年では産業用ロボットメーカーも ROS2 のサポートを発表する機会が増えてきました。 デモの内容 デモのタイトルにある「遠隔テレオペレーション」（テレオペ）とは、離れた場所にあるロボットや機械を、人間がリアルタイムに操作する技術です。オペレーターは手元のコントローラーやモニター映像を通じて現場の状況を把握し、ロボットに動作指示を送ります。ロボット側のカメラやセンサーの情報がネットワーク経由でオペレーターに返されることで、あたかも現場にいるかのように作業できます。この技術により危険な環境（災害現場、高所、有害物質のある場所）や、人がすぐに行けない遠隔地での作業を安全に行えています。 このテレオペのデモでは AWS の IoT サービスを利用し、 Web の UI を見ながらゲームコントローラーを操作することで、クラウド経由でロボットを操作します。 このデモで利用している実機のロボットは、世界中の生産現場でも利用されているセイコーエプソン株式会社製の高速・高精度な垂直多関節（6軸）ロボット( CX4-A601S )を利用しています。セイコーエプソン株式会社では自社のロボットに対応した ROS2 パッケージ を公開しており、デモでは ROS2 経由で操作しています。 このデモでは同時にデジタルツインとしての Amazon EC2 上で実行されている NVIDIA Isaac SIM にも情報が送られるため、カメラの映像だけではなく、シミュレーション環境上でもロボットの動作を確認することができます。 セイコーエプソン株式会社の ROS2 パッケージ では実機を利用せず、Rviz (3D 可視化ツール)で動かすモードも用意されているため、シミュレーション環境の中だけで動かすこともできます。それゆえ、ロボットの操作に不慣れな人でも安心して操作することが可能です。 このデモでは操作時のデータを rosbag 形式 (ROS2 上でやり取りされるメッセージを記録し、後で利用できる) に保存することも可能で、作成された rosbag は記録後にクラウドに保存されます。このデータを使うことで、クラウド上のシミュレーション環境で、同じ様に再現することもできます。また、保存された操作データは、Physical AI で利用される VLA（Vision-Language-Action）モデルの模倣学習データとして活用することができます。 今回のデモの全体の構成は下記となっています。 ぜひ、 6 月 25 日、26 日に幕張メッセで開催される AWS Summit に来場いただき、実際にご自身の手でコントローラーを操作 し、Physical AI の時代に必須となるロボット動作データ生成と収集を体験しに来てください！ デモは AWS Expo の AWS for Industries Zone に展示しています。 伊藤ジャッジ向子 (Ito, Judge Sakiko) 米国での開発者経験を経て、AWSのサポートに入社し、異動しエンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。趣味は山登り、クラッシックバレエと愛犬のお世話です。 Muhammad Fikko Fadjrimiratno（ふぃっこ） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 不動産・建設業界のお客様を中心に、AWS 利用をご支援しているソリューションアーキテクトです。好きな領域はロボットとIoTと機械学習であり、最近はロボット分野での生成AIの活用にチャレンジしています。趣味はフライトシミュレーター、冬はスノーボードです。 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。

　 みなさんこんにちは！ 猫や犬に癒されるより AI bou (相棒) に助けられる日々を送る Solutions Architect の高野です。一昨年、昨年と AWS Summit Japan でご好評いただいた Chaos Kitty が、今年はさらにパワーアップした「対戦モード」を引っさげて 4 回目の登場です！ 　 この記事では、2026 年の AWS Summit Japan の AWS Builders’ Fair で展示される「人間 vs AI 障害対応バトル – Chaos Kitty Challenge」についてご紹介します。今年のテーマは、システム運用保守業務における AI Agent の活用による効率化です。参加者と AI エージェントが同じ障害に同時に挑み、対戦を通じて AI Agent がインシデント対応をどのように効率化するかを体感できる体験型コンテンツとなっています。 　 AWS Summit Japan 2026 の開催期間は 2026 年 6 月 25 日 (水) と 26 日 (木) の 2 日間で、会場は幕張メッセになります。 本展示は両日ともご体験いただけます。 まだ AWS Summit Japan 2026 に登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Expo の AWS Builders’ Fair の中にあります。 Chaos Kitty とは？ 　 Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応を学ぶことができます。 　 2023 年の初登場 以来、 2024 年 、 2025 年 と 3 年連続で AWS Summit Japan に登場し、毎年パワーアップを重ねてきました。昨年は IoT 機器なしで利用可能な Web アプリケーション化や、 AWS Cloud Development Kit (AWS CDK) による Infrastructure as Code (IaC) 化を実施し、 AWS Samples として公開 しています。どなたでもご自身の AWS 環境にデプロイしてお試しいただけます。また、Amazon CloudWatch ダッシュボードや Amazon CloudWatch Application Signals を活用したモニタリングも組み込まれており、インシデント発生時の状況把握を体験いただけます。 新機能紹介: 対戦モード 　 4 回目となる今回は、 システム運用保守における AI Agent 活用 をテーマに、対戦モードを新たに追加しました。AI Agent がインシデント対応をどのように効率化するかを楽しみながら体感いただけるよう、参加者と AI が同じ障害に同時に挑むゲーム形式にしています。 図 1 : AWS Summit Tokyo 2026 版 Chaos Kitty 外観 図 2 : 障害注入対象の Web 3 層アプリケーション画面 対戦モードの概要 　 同じ障害が発生した 2 つの環境で、参加者と AI エージェントが同時に対応を開始します。人間の直感と経験 vs AI の分析力と速度 — リアルタイムで両者の対応プロセスが可視化され、どちらが早く正確に障害を解決できるかを競います。AI 時代のインシデント対応の未来を、対戦を通じて体感できるモードです。 　 日々システムを運用されている皆様であれば、障害発生時にログを追い、メトリクスを確認し、構成変更を洗い出し、根本原因を突き止めるまでの緊張感と難しさをよくご存知かと思います。その一連のプロセスを、AI Agent はどれほどの速さでこなすのか。そして、あなたは AI Agent に勝てるのか。今年は従来の Easy モード、Hard モードに加えて、上級者向けの Extreme モードも追加しています。長年の経験と勘で培ったインシデント対応力を、ぜひ AI にぶつけてみてください。勝っても負けても、AI 時代のシステム運用のあり方を肌で感じていただけるはずです。腕に自信のある方、お待ちしております！ 図 3 : 対戦モード初期画面 図 4 : ゲーム中画面 図 5 : 勝敗確定画面 (AI WIN) 図 6 : 結果画面 インシデント調査・分析用 AI Agent に AWS DevOps Agent を採用 　 対戦モードで参加者と競う AI Agent には、 AWS DevOps Agent を採用しています。 　 AWS DevOps Agent は、インシデント対応を自動化するフルマネージドサービスです。インシデントが発生すると、Amazon CloudWatch のメトリクス、ログ、トレース、さらにはデプロイ履歴や API 変更履歴など、複数のデータソースを横断的に分析し、根本原因の特定から修復アクションの提案までを自動で行います。人間のオンコールエンジニアが手動で相関分析に費やしていた時間を、数分レベルに短縮できるのが特徴です。 　 AWS DevOps Agent は API 経由で調査タスクの開始や状態取得ができるため、今回の Chaos Kitty ではアプリケーションから API を呼び出し、対戦モードの画面上に AI Agent の調査プロセスをリアルタイムで表示しています。参加者は、自分が手動で調査を進める横で、AI Agent がどのような手順で原因を特定していくかを目の前で確認できます。 　 また、AWS DevOps Agent が標準で提供する Web 画面 (DevOps Agent Space) もブースでご覧いただけます。実際の運用で AWS DevOps Agent をどのように活用できるかのイメージを掴んでいただけると思います。 図 7 : AWS DevOps Agent Space の画面 体験を通じて学べること 　 この対戦モードを通じて、以下のことを体感いただけます。 1. AI Agent がどのようにインシデントを調査・分析するか — AWS DevOps Agent の動作を目の前で確認できます 2. AIOps による迅速化の効果 — 手動対応と AI 支援対応の所要時間の差を実体験で理解できます 3. AI Agent を活用したインシデント対応の実践イメージ — 日々のシステム運用にどう活かせるかのヒントを得られます さいごに 　 今年の Chaos Kitty は、システム運用保守における AI Agent 活用をテーマに、対戦モードを通じてその効果を楽しみながら体感いただける内容になっています。AI Agent がインシデントをどのように調査・分析するのか、そして日々の運用業務にどう活かせるのか、ぜひブースで実際に体験してみてください。 　 AI に勝てた方も、負けてしまった方も、AI 時代のシステム運用のあり方について新たな気づきを持ち帰っていただければ幸いです。AWS Summit Japan 2026 の AWS Builders’ Fair で、皆様のご来場をお待ちしております！ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 高野 翔史 Chaos Kitty は AWS Japan ソリューションアーキテクトの服部 一成、堀 貴裕、佐々 拓也、津郷 光明、河角 修、黒木 琢央、高野 翔史が中心となって開発しております。

はじめに 通信業界の主要 MNO 4 社（NTTドコモ、KDDI、ソフトバンク、楽天モバイル）に NTT、ソニーを加えた通信関連事業者の皆様、121 名 / 6 グループの方々が一堂に会したワークショップを、2026 年 4 月 23 日に AWS Startup Loft Tokyo で開催しました。テーマは、ネットワーク開発・運用を変える「カスタム AI エージェント」。本記事では、Autonomous Network 実現に向けた参考アーキテクチャ、NTTドコモ／NTTドコモビジネス両社の事例、Strands Agents・Amazon Bedrock AgentCore のハンズオン、そしてユースケース議論まで、当日の内容をレポートします。「自社のどの業務に、どう適用できるか」を考えるヒントとして、お役立ていただけますと幸いです。 ワークショップ参加者の集合写真 AWS ジャパンでは、こうしたテーマに向き合う場として 2025 年 11 月に「 通信ネットワーク運用向け AI エージェントワークショップ 」を開催し、参加された通信事業者の皆様から大きな反響をいただきました。今回はその第 2 回として、対象を ネットワーク開発・運用全般 に広げ、開発工程での AI エージェント活用も新たに取り上げました。 通信業界のネットワーク開発・運用では、より高品質で柔軟なサービスを継続的に提供するために、設計・構築・障害対応・改善といった多岐にわたる業務を効率化することが求められています。一方で、ネットワークの拡張や複雑化に従来のオペレーションだけで追従することは難しくなりつつあり、自動化・高度化・自律化の取り組みが加速しています。その実現手段の 1 つとして AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する業務ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった共通の課題があります。本ワークショップは、こうした課題に対して「学ぶ・知る・触る・議論する」を 1 日に凝縮した場を提供するものです。 アジェンダ 時間 セッション 登壇者 13:00–13:10 オープニング Yuki Miyazaki (AWS / SA) 13:10–14:15 セッション1：複雑な開発/運用業務でAIエージェントを活用しよう Yuki Miyazaki (AWS / SA) 13:10–14:15 事例登壇：AIとGitOpsを用いた5Gコアネットワークの設計構築自動化への取り組み NTTドコモ 宮本氏 13:10–14:15 事例登壇：ルータ統合型AIエージェントによるネットワーク開発の取り組み NTTドコモビジネス 門脇氏 14:30–16:00 セッション2：AWSで実現するカスタムAIエージェント（Strands Agents / Amazon Bedrock AgentCore ハンズオン） Atsushi Okamoto (AWS / SA), Yuta Tanaka (AWS / SA) 16:15–17:50 セッション3：ネットワーク開発運用エージェントを触ってみよう（ハンズオン＋ユースケース議論） Naohito Yoshikawa (AWS / SA) 17:50–18:00 クロージング Yuki Miyazaki (AWS / SA) 18:00–19:30 ネットワーキングパーティ — セッション1：複雑な開発/運用業務でAIエージェントを活用しよう 宮崎 友貴 Solutions Architect Autonomous Network 参考アーキテクチャ 本セッションでは、通信業界のオペレーションの標準化団体である TM Forum が定義する Autonomous Network （自律ネットワーク）の自律レベル L4/L5 の実現に向けて、AI エージェントとデータの活用が不可欠であることを解説しました。まず、AI エージェントが自律的な行動を行えるようになった基礎技術の変遷と、ネットワークの開発者や運用者に近い動きが実現可能であることを説明し、AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは AI エージェント × 自律的な判断に必要なデータであり、ネットワークのトポロジーや時系列データ、構成情報、設計書、手順書といったネットワークデータと AI エージェントを組み合わせることで、ネットワークの設計や構築、運用開始後の障害検知から根本原因分析といった複雑なオペレーションを自律的に行える仕組みが構築できることをお伝えしました。最後に、グローバルおよび国内の通信事業者における AI エージェントの活用事例をご紹介し、Autonomous Network が既に商用で実現しつつあることを参加者の皆様にお伝えしました。 本セッションの資料（PDF）をダウンロード 事例登壇：NTTドコモ 「AIとGitOpsを用いた5Gコアネットワークの設計・構築自動化への取り組み」 宮本 克真 氏 株式会社 NTTドコモ コアネットワークデザイン部 AI エージェントを使ったネットワーク設計構築自動化の事例として、株式会社 NTTドコモ コアネットワークデザイン部の宮本克真氏にご登壇いただきました。 NTTドコモでは、国内で初めて 5G コアネットワーク（5GC）を AWS 上に構築し、2026 年 2 月より商用サービスを開始 しています。従来の 5GC 設計・構築プロセスでは、膨大なマニュアルや仕様書の確認、多種の設定ファイル作成、煩雑な構築手順の実施に約 4〜6ヶ月を要し、需要増への迅速な追従が課題でした。 AI×GitOps による設計・構築の自動化 そこで AI エージェントと GitOps を組み合わせた設計・構築自動化を導入しました。AI エージェントがマニュアルや仕様書をナレッジベースとして参照し、インフラ設定・アプリ設定・5GC コンフィグなどの設定ファイルを自動生成します。生成されたファイルは Git で管理され、CI/CD パイプラインを通じて自動デプロイされます。アーキテクチャとしては Amazon Bedrock AgentCore 上のオーケストレータエージェントが、Git 担当・インフラ担当・アプリ担当・コンフィグ担当の各専門エージェントを統括する構成です。各エージェントは Strands Agents SDK で構築され、Amazon Bedrock Knowledge Base を MCP 経由で参照します。デモでは、オペレータが「5GC NF を構築して」と指示するだけで 5GC が構築される様子をご覧いただきました。 AI×GitOps の活用による効果 この取り組みにより設計から構築までのリードタイムを約 80% 短縮することに成功し、工数削減と共に人為ミスの低減にも繋がりました。今後は、試験自動化や保守・運用領域などへの拡大を目指しています。 事例登壇：NTTドコモビジネス「ルータ統合型AIエージェントによるネットワーク開発の取り組み」 門脇 伸明 氏 NTTドコモビジネス株式会社 ルータ連携 AI エージェントのネットワーク開発への活用事例として、NTTドコモビジネス株式会社の門脇氏にご登壇いただきました。同社では、映像伝送ネットワークサービスを提供しており、全国の専用線網にて数百台規模のルータを運用しています。従来、突発的なネットワーク設定変更（例：ファイアウォール強化）が必要な際には、エンジニアがマニュアルや仕様書を確認し、ルータの状態を手動で調査した上で設定を作成・検証し、さらにレポート資料を作成するまでに約 6 日を要していました。 AIエージェントによるルータ設定検討支援 そこで、ルータの MCP を活用してルータと直接連携する AI エージェントを導入しました。エンジニアが設定要件を自然言語で指示するだけで、AI エージェントがルータから必要な情報を自律的に収集し、既存の設定や環境に合わせてコンフィグを設計・生成します。さらに、コンフィグ投入後の動作確認やレポートの作成まで自動化することで、所要日数を 6 日から 1 日へと大幅に短縮しました。また、AI エージェントのメリットとして、自律的にルータから自動で必要情報を収集するため、ルータ情報をプロンプトで与えずにルータの専門知識さえあれば活用できる点と、AI エージェントの振る舞いの定義をコードではなく自然言語で記述できるため可読性が高く実装が容易である点が紹介されました。 AIエージェント開発環境 AWS の構成としては、社内のセキュリティ規約に基づき閉域接続（AWS コンソール以外はインターネット接続なし）で構築することで安全な AI エージェント運用を実現しています。今後は、試験自動化やメーカー問い合わせの自動化など、さらなる AI エージェント活用のユースケース拡大を目指します。 セッション2：AWSで実現するカスタムAIエージェント — Strands Agents と Amazon Bedrock AgentCore 本セッションの前半では、カスタム AI エージェントを「素早く構築する」ことと「安全に大規模運用する」ことの両方を実現する AWS のアプローチとして、 Strands Agents と Amazon Bedrock AgentCore を最新アップデートとともにご紹介しました。 岡本 篤志 Solutions Architect まず AI エージェントの構成要素を、推論を担うモデル・振る舞いを定義するプロンプト・外部システムと連携するツールの 3 つに整理した上で、これを本番稼働させるにはメモリ管理やオブザーバビリティ、セキュリティ、スケーラビリティなど多くの周辺機能の実装が必要になることを示しました。Strands Agents はこの「構築」の負担を大幅に軽減するオープンソース SDK であり、わずか数行のコードでエージェントを実装できます。MCP をはじめとする多様な接続方式による外部システム連携や、エージェント同士を組み合わせるマルチエージェント構成にも対応しています。さらに、複雑なマルチステップタスクにおける再現性や品質の一貫性を確保する仕組みとして Agent SOP （自然言語で記述するワークフロー定義）を紹介し、チーム間での知見共有と品質統一が可能であることをお伝えしました。 続いて、「大規模運用」を担う Amazon Bedrock AgentCore について解説しました。任意のフレームワークやモデルで構築したエージェントを本番環境にデプロイし、会話コンテキストの維持、アクセス制御、実行トレースの可視化、品質の継続的な評価まで、エンタープライズグレードの運用基盤を包括的に提供します。下図のように、通信ネットワーク運用の文脈では、ネットワーク機器や構成管理システムとのツール連携、インシデント対応ナレッジの長期記憶としての蓄積・活用が可能であり、ネットワーク運用の自律化に向けた基盤として特にフィットすることを示しました。 通信ネットワークにおける Amazon Bedrock AgentCore の価値 その後、Strands Agents と Amazon Bedrock AgentCore の両方の実装を体験できるワークショップを実施させていただきました。 田中 優多 Solutions Architect このワークショップでは、Strands Agents 及び Amazon Bedrock AgentCore の機能を最大限に活用した、包括的で本番環境に対応したカスタマーサポートエージェントを構築しました。単なるチャットボットではなく、複雑なカスタマーサービスのワークフローを処理し、複数の企業システムと連携し、同時に数千人の顧客にサービスを提供できるような高度なエージェントシステムです。 まずは、Strands Agents をローカル環境に実装することをご体験いただきました。幾つかの用途特化機能をツールとして定義 → 独自のデータをナレッジベースとして連携 → エージェントの役割を自然言語で定義といった簡易なステップで、AI エージェントを作成できることを確認しました。 Lab1 の構成 ただしこの状態のプロトタイプには、以下のような課題がある状態でした。 永続的なメモリがない — エージェントは過去の会話を忘れる スケーラビリティがない — ローカル開発環境でのみ実行 こうした課題を解決するソリューションとして、Amazon Bedrock AgentCore の実装へと進みました。数ある AgentCore モジュール群の中でも、 AgentCore Memory と AgentCore Runtime に焦点を当てて、コードベースでその設定やデプロイ方法をご体感頂きました。AgentCore Memory を実装することで、ユーザとのやり取りの記憶や好みの自動学習、長期間のコンテキスト維持が可能になります。そして AgentCore Runtime の活用により、常に変化する需要に合わせて自動的にスケールするサーバーレスソリューションが実現できます。数多くのフレームワーク、モデル、プロトコルをサポートし、開発者は最小限のコード変更でローカルプロトタイプを本番対応ソリューションに変換できます。 Lab4 の構成（〜Runtime 上へのデプロイまで） これらをお客様の手でカスタムで作り上げることにより、業務に即した実用性の高い AI エージェントが実装できることを、ご体感いただきました。 ワークショップ会場の様子 本セッションの資料（PDF）をダウンロード セッション3：ネットワーク開発運用エージェントを触ってみよう 吉川 直仁 Solutions Architect 前段のセッション2で学んだ Strands Agents と Amazon Bedrock AgentCore の知識を、通信ネットワークというドメインに当てはめるとどうなるか、を体感していただくのが本セッションの位置付けです。前回ワークショップでは保守運用業務にフォーカスしましたが、今回はそこに 開発・構築工程 のシナリオを 2 本追加し、参加者の皆様に「物理ネットワークの設計・開発者」「5G コアネットワークの設計・開発者」「ネットワーク保守運用者」の 3 つの立場を順に体験していただきました。 シナリオ① ネットワーク機器の設定、構築、検証 シナリオ ① は、複数台のルータから構成されるネットワークの Config 設定・接続確認・バグ検証の自動化です。実機の設定情報、大量のログ、仕様書を参照しながら対応する必要がある業務を、AI エージェント × ナレッジ（SOP）の組み合わせで実装します。 デモ動画：シナリオ ①（ネットワーク機器の設定・構築・検証） オペレータが「ネットワークの状態を確認して、疎通不可の原因を調査・修正してほしい」と自然言語で指示するだけで、AI エージェントが SOP に従って ① 構成情報の確認 → ② ヘルスチェック → ③ Config 修正 → ④ レポート作成までを自律的に実行する様子をご覧いただけます。 シナリオ② コアネットワークのパラメータ設計、構築 シナリオ ② は、5G コアネットワークのパラメータ設計とデプロイです。複数の NF（Network Function）から構成されるコアネットワーク網に対するネットワークスライス追加を、Strands Agents が IaC とパラメータを生成し、Git を介してインフラ（Amazon EC2）からその上で動くアプリ、さらにアプリのパラメータ設定までを一気通貫でデプロイする流れを体験していただきました。 デモ動画：シナリオ ②（コアネットワークのパラメータ設計・デプロイ） オペレータが「新しいネットワークスライスを追加してほしい」と自然言語で指示するだけで、AI エージェントが現在の構成を確認し、SOP に従って IaC とパラメータを生成、Git を介してインフラ（Amazon EC2）→アプリ→アプリのパラメータ設定までを一気通貫でデプロイする様子をご覧いただけます。 シナリオ ③ は前回ワークショップでもご紹介した、ネットワーク障害発生時のアラーム分析・切り分け・措置レコメンド・チケット起票です。今回はマルチエージェント構成を前回からアップデートして実演しました（構成の詳細は 前回ブログ をご参照ください）。 シナリオ ①／② デモアプリケーション構成図 シナリオ ①／② のデモアプリケーションは、Strands Agents で実装したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、AgentCore Memory（STM/LTM）と AgentCore Observability も統合した構成です。エージェントは利用者からの一つの指示に対し、ネットワーク機器の操作・IaC のデプロイ・Git への変更反映といった複数の外部アクションを自律的に組み合わせて実行し、本番運用を想定した記憶・観測の仕組みも合わせて体験いただけるようにしています。 通信業界における SOP とは？ 通信業界では、仕様書、詳細設計書、ベンダードキュメント、手順書、パラメータ設計規則など、独自フォーマットの大量のドキュメントが存在します。本ハンズオンではこれらを SOP（Standard Operating Procedure） という形式に標準化し、Markdown ファイルとして AI エージェントに与えることで、「人間も AI も同じ手順を読み、同じ成功基準で評価できる」状態を作り出しています。SOP の生成・評価・修正自体も AI エージェントで自動化でき、エラーの有無・ポリシー順守・効率性などを別の SOP 評価エージェントで自動チェックする運用も実演しました。 本セッションの資料（PDF）をダウンロード ユースケース議論ワークショップ ユースケース議論ワークショップの様子 セッション 3 のハンズオンを終えた後半 30 分は、参加者の皆様にご自身の業務に当てはめて考えていただくユースケース議論の時間としました。テーブルごとに AWS SA も加わり、模造紙と付箋を使って「AI エージェントに任せたい業務は何か」「任せるために必要なデータ・指示は何か」「自担当で導入するならどんなアーキテクチャになるか」の 3 つの問いを順に議論いただきました。 各テーブルから出てきたアーキテクチャ図と付箋を AWS 側で見渡して整理すると、参加企業・担当領域は様々であるにもかかわらず、いくつかの共通した観点が浮かび上がってきました。 1. 業務領域ごとに専門エージェントを切り出す発想は共通 多くのテーブルで、AI エージェントを 1 つの巨大な万能エージェントとして描くのではなく、業務領域ごとに専門エージェント（パラメータ設計／Config 設定／検証／監視／チケット起票など）を切り出す構成が描かれていました。配置の仕方はテーブルによって、上位のオーケストレータが束ねる階層型、業務フローに沿ったパイプライン型、業務ごとに独立した並列型と様々でしたが、「役割を分けて、それぞれに SOP を持たせる」という発想は多くのテーブルで共通していました。 2. 既存の社内ツール・データとどう接続するかが、最大の現実論点 多くのテーブルで挙がったのが「既存の社内ツールとの接続」です。チケット管理、ナレッジ共有、ログ分析、構成管理、コミュニケーション基盤、構成情報 DB ― 各社それぞれの現場で長く使われてきたツール群があり、AI エージェントをどう “そこ” に組み込むかが、ハンズオンを「自社で動くもの」にするための最大の現実論点として浮かび上がっていました。 3. AI に任せきれない判断ポイントの設計が、各社共通の論点になっていた SOP の切り替え判断、Human-in-the-loop による承認・エスカレポイント、検証環境から商用環境への段階的適用 ― 「AI エージェントに任せきれない判断をどう設計に組み込むか」が、開発・運用業務における AI エージェント活用の論点として、複数のテーブルで共通して議論されていました。あるテーブルのホワイトボードには、エスカレポイントに 赤字で「ココが課題」 と書き込まれた付箋が貼られており、本番運用を見据えたときの設計上の難所がここに集約されていることを象徴する一場面でした。 技術を学ぶだけで終わらせず、自社・自業務への適用イメージを「絵」として描き、共通の課題感を他社の方と共有するところまで踏み込めたことが、本セッションの大きな狙いでした。各テーブルで描かれたアーキテクチャや書き出された課題の数々は、AWS として今後の支援活動を組み立てる上で、非常に貴重なインプットとなりました。 参加者の声 「AWS のイベントにドコモ／KDDI／ソフトバンク／楽天／ソニーと多くのネットワーク事業者が揃っていることに驚いたし、AWS が通信業界に深く浸透していることを実感した。」 「具体的なイメージが湧く内容でよかったです。具体化に向けて引き続きご相談させていただければと思います。」 「AI エージェントを作るためのハンズオンが丁寧に作られていて短時間でも内容が理解できました。」 「出来上がった AI Agent を体験するよりも、作る過程で AWS を使うメリットをもっと体験したかった。」 「テスト環境を触れる期間がもう少し長いと、チームメンバーにも共有しやすい。」 おわりに 本記事では、「通信事業者向けカスタム AI エージェントワークショップ」についてレポートしました。事例登壇・ハンズオン・ユースケース議論を通じて、参加された皆様にとってカスタム AI エージェントの活用イメージが具体化される一日となっていれば幸いです。また、各テーブルでの議論や他社・他部署の方との交流を通じて、業界共通の課題感を共有する貴重な機会にもなったのではないかと考えております。ご参加頂いた皆様、本当にありがとうございました。本ワークショップを通じて得られた知見やフィードバックは、今後の AWS の支援活動にも活かしてまいります。ネットワーク開発・運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者紹介 宮崎 友貴 (Yuki Miyazaki) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 岡本 篤志 (Atsushi Okamoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 田中 優多 (Yuta Tanaka) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 吉川 直仁 (Naohito Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。

1. はじめに こんにちは、ソリューションアーキテクトの戸塚と中本と宇加治です。 AWS Summit Japan 2026 の AWS Builders’ Fair にて、パデルフォーム分析アプリを展示します。パデルを知らない方向けに簡単に説明すると、テニスとスカッシュを合わせたような、壁に囲まれた小さめコートで 2 対 2 のダブルスだけで行うラケットスポーツです。この展示は、テクノロジーでスポーツ体験を拡張し、競技者の感覚や経験だけでは捉えにくいフォームの違いを可視化する取り組みとして、多くの方に触っていただきたい内容となっています。 このブログでは、展示の概要、使用している技術スタック、AI 駆動の開発手法、そしてこのシステムが解決する課題と他インダストリーへの応用可能性についてご紹介します。エンジニアの方もたくさん参加されていると思うので、ぜひ技術的な観点からも楽しんでいただければ嬉しいです。 2. AWS Summit Japan 2026 について AWS Summit Japan 2026 は、2026年6月25日から26日まで幕張メッセで開催される、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。260 以上のセッションに加え、AWS Village、ワークショップ、Partner Solution Expo など多彩なコンテンツが用意されています。AWS Builders’ Fair エリアは、AWS エンジニアが自作した “遊べる” デモを体験しながら、AI・IoT・サーバーレスなどの活用事例を学べるハンズオン型の展示ゾーンとなっています。来場者は自由にブースを回り、生成AI・IoT・サーバーレスなどを組み合わせたインタラクティブなデモを、実際に触ったり遊んだりしながら体験できます。 3. パデフォーム分析アプリ展示概要 このアプリは、 Meta Quest （VR ヘッドセット）、 HaritoraX （モーションキャプチャデバイス）、カメラによる骨格推定技術（ MoveNet ）を組み合わせ、バーチャル空間でパデルの球出しを受けた際の動作を計測・分析する仕組みです。 単にスイングを記録するだけではなく、身体の各部位の動きやタイミングの差分をとらえ、トッププレーヤーのフォームと比較評価できるように設計しています。 3.1 体験の流れ VR 空間で球出しを受ける — Godot で構築された 3D 空間内でプレー リアルタイムモーションキャプチャ — HaritoraX + カメラで動作データを取得 フォーム分析 — DTW(Dynamic Time Wrapping) アルゴリズムでトッププレーヤーのフォームと比較　※ 結果表示 — 5 指標のスコアカード + 生成 AI によるアドバイス VR、Haritora、カメラの３つのソースを統合して、最終的に 5 つの指標として評価するように実装しています。 写真: VR 空間でプレーする体験者の様子 図: 5つの評価指標を算出するための各データソースの役割 ※骨格推定には OpenPose や MoveNet といったスポーツ動作分析の標準手法を使っています。時系列比較の DTW は、 Ba č i ćらが 2022 年の VISAPP でストローク分類に使用しています。プロとの比較は Stanford の Liu が 2025 年に DTW によるプロ対アマ比較 を行っています。フェーズ分割はバイオメカニクスの標準的なアプローチとなっています。 写真: リアルタイムモーションキャプチャのデータ確認画面 ゲームとして楽しめるだけでなく、トレーニングにもなる設計を目指しています。プレイヤーは VR 空間の中でさまざまなボール（レボテやコントラパレットを含む）に対応することになり、楽しみながらフォームの改善ポイントを発見できます。 3.3 トッププレーヤーの教師データ 事前計測には、パデルトッププレーヤーとして久留広平選手、内海信仁選手、瀧田瑞月選手、内海和心選手に AWS オフィスへお越しいただきました。計測で取得したデータは、すでにアプリ内の教師データとして実装されており、体験者は彼らのフォームとの差異を比較できるようになっています。 この仕組みの面白さは、単に「上手い・下手」を判定することではありません。トッププレーヤーの動作を基準にすることで、打点の入り方、身体の回旋、重心移動、準備動作の速さなど、普段は言語化しにくい技術要素を、比較可能な形で捉えられる点にあります。 また、コーチングや自己改善の文脈でも活用しやすいのが特徴です。感覚に頼りがちなフォーム指導に対して、再現性のある比較軸を持ち込めるため、競技経験者はもちろん、これから上達したいプレーヤーにとっても新しい学習体験になり得ます。 写真: 計測結果のスコアカード画面（数値化 + 生成 AI アドバイス） 3.4 トッププレーヤーからのコメント 教師データ計測に協力いただいた選手から、本システムを実際に使用した感想をいただきました。システムの可能性を評価する前向きなコメントに加え、今後の活用方法に関するアイデアも頂戴しました。 ■ 久留 広平選手(日本代表) コーチの視点では、フォームや身体の使い方を指導する際に選手がイメージしている動作と実際の動作に乖離が見られるケースがあり、そのような場面でデータに基づくフォーム分析を活用することで、効果的な指導につなげられると感じました。 ■ 内海 信仁選手(ベテラン日本代表) 日本は世界から30年のビハインドがあり、中東、東南アジアは英語が話せるアドバンテージでどんどん差を埋めていますが、日本はそれが出来ていません。それをテクノロジーで埋めていくというのは日本らしさがあってとても素晴らしいと感じました。 ■ 瀧田 瑞月選手(2018〜2023 日本代表 2025年 Jr 日本代表サブコーチ) 率直に、これからの可能性にとてもワクワクしました。パデルに限らず、エンターテインメントやコーチング、競技力向上など、さまざまなカテゴリーで活用できる可能性を感じました。今後どのように発展していくのか、とても楽しみです。 ■ 内海 和心選手(日本代表) 自分の足りないところやいいところを見つけてくれるところが面白いと感じました。プロと比べて何が劣っているかとか見つかるところが今後の成長に繋がりそうだと思いました。 4. システムアーキテクチャ 4.1 全体構成 この展示は、スポーツテック、XR、センシング、コンピュータビジョンを横断する実験でもあります。Meta Quest による没入的な体験、HaritoraX によるモーションキャプチャ、カメラベースの骨格推定による姿勢解析を組み合わせることで、単一センサーだけでは捉えきれないフォーム情報を多面的に扱えるようにしています。VR アプリ構築には、Unity や Unreal Engine なども候補にあがりましたが、今回は費用も極力抑えることを考え、完全無料でオープンソースの Godot を採用しました。Godot は、Python に似た独自の言語「GDScript」を使います。文法がシンプルで読みやすいため初心者でも学習しやすい設計になっています。もちろん C# や C++ も使うことができます。今回はこの GDScript 等を Kiro の力を活用することで、自然言語でのやりとりでこのような VR アプリのオブジェクトや VR 空間での挙動までもプログラミングしているので、GDScript の学習コストはかかりませんでした。 本システムは以下のコンポーネントで構成されています: 図: システム全体概要 レイヤー 技術 用途 VR / 3D 空間 Godot Engine VR空間内でのパデル球出しシミュレーション。自然言語（Kiro）で開発 VR デバイス Meta Quest VR ヘッドセットによる没入体験 モーションキャプチャ HaritoraX 身体トラッキング（全身の動きを取得） 骨格推定 MoveNet (TensorFlow Hub) カメラ映像からリアルタイム骨格推定（17 キーポイント） フロントエンド Tauri v2 + React + TypeScript + Vite デスクトップアプリ（結果表示・操作 UI） バックエンド バックエンド Python FastAPI + Uvicorn リアルタイム分析 API（WebSocket 対応） フォーム比較 DTW (Dynamic Time Warping) 時系列データの非線形マッチングによるフォーム比較 クラウド AWS CDK (ECS Fargate + ALB + S3 + DynamoDB) 評価処理のオフロード、スコア永続化、ランキング AI フィードバック Amazon Bedrock スコアに基づくパーソナライズされた改善アドバイス エッジ側で動くアプリケーションは AWS IoT Greengrass の OTA (Over the Air)アップデート を使ってアプリ配信をする仕組みをとっており、複数拠点にあるアプリを遠隔で更新できる様にしています。また計測後のフィードバックは骨格推定を含んだ動画も見れるようになっており、動画配信は Amazon CloudFront を活用してレイテンシーが抑えられる形にしています。 図: エッジ側を含めた AWS 構成 4.2 AI 駆動の 3D 開発: Kiro × Godot 今後、3D や VR の需要はさらに高まっていくと見られます。一方で、3D プログラミングは従来、空間座標やベクトル演算、物理エンジンの理解など専門性が高く、参入障壁が高い領域でした。 今回のプロジェクトでは、Godot Engine を使った 3D 空間のプログラミングを、Kiro（AI コーディングアシスタント）を用いた自然言語プログラミングで実施しています。たとえば「ボールを放物線で飛ばしてラケットの当たり判定を追加して」「壁に当たったらレボテ（跳ね返り）する物理を実装して」といった指示で、3D 空間の挙動や空間認識のロジックを実装できました。 これにより、3D/VR 開発の経験が浅いエンジニアでも、アイデアを素早くプロトタイピングし、スポーツシミュレーションのような複雑な 3D アプリケーションを構築できることを示しています。AI 駆動の開発が、従来は専門家の領域だった 3D プログラミングの民主化を進める一例と言えます。 4.3 モーションキャプチャデータ連携の技術的課題 本システムの開発で最も技術的に挑戦的だったのは、異なるモーションキャプチャソースからのデータ統合です。 具体的には以下の課題がありました: 座標系の統一: HaritoraX（慣性式）、Meta Quest（光学式）、MoveNet（画像ベース）はそれぞれ異なる座標系・スケールで動作データを出力します。これらを統一的な骨格表現に変換する必要がありました。 データ同期: デバイスごとにサンプリングレートが異なり（カメラ 30fps、HaritoraX 100Hz 等）、時刻同期とリサンプリングの仕組みが必要でした。 欠損補間: オクルージョン（身体の一部が隠れる）時のデータ欠損を、他デバイスのデータで補間する戦略を設計しました。 リアルタイム性: 分析結果を体験者にすぐフィードバックするため、WebSocket 経由でのストリーミング処理パイプラインを構築しました。 これらの課題に対して、Kinesis 経由でデータを送りつつ UNIX タイムの時間同期、骨格情報との相対位置によるキャリブレーションにより統合し、クラウドと連携して分析する — これはまさに AWS が得意とする領域です。 5. 今後の可能性 5.1 このアプリが解決する課題 スポーツの世界では、トップ選手の技術は見えているようで、細部まではなかなか共有されません。コーチングの現場でも、「もっと腰を回して」「タイミングが遅い」といったフィードバックは、指導者の主観に依存し、再現性に乏しいものでした。 本システムは以下の課題を解決します: フォーム指導の属人化: 感覚的な指導を定量データに置き換え、再現性のある比較軸を提供 上達実感の欠如: スコアの時系列推移を記録し、小さな改善も可視化 トップ選手の技術の暗黙知化: 動作データとして記録し、比較可能な形でアクセス可能に フィードバックの即時性: リアルタイム計測 → 即座にスコア表示、改善ポイントを AI が提示 エンゲージメントの低下: VR ゲームとして楽しみながらトレーニングできる体験設計 5.2 他インダストリーへの応用可能性 本システムのコアである「モーションキャプチャ × AI 比較分析 × リアルタイムフィードバック」は、パデルに限らず幅広い分野に応用可能だと考えています。以下にユースケースを示します。 インダストリー 応用例 期待効果 スポーツ全般 テニス、ゴルフ、野球のスイング分析、サッカーのキック分析 定量的なフォーム改善、怪我予防 リハビリ・ヘルスケア 理学療法での動作評価、リハビリ進捗の定量モニタリング 回復度の客観的評価、遠隔リハビリ 製造業 作業員の動作分析、熟練工の技能伝承 品質向上、教育期間短縮 エンターテインメント ダンスや演技のフォーム評価、モーションキャプチャ活用 パフォーマンス向上、ゲーミフィケーション フィットネス パーソナルトレーニングのフォームチェック、ヨガのポーズ評価 トレーナー不在時の自己改善 介護・高齢者支援 歩行分析、転倒リスク評価 早期異常検知、予防介護 技術的には、DTW による時系列比較は人間の動作全般に適用可能であり、教師データ（基準動作）を差し替えるだけで異なるドメインに展開できます。AWS のクラウドインフラ（AWS Lambda, Amazon S3, Amazon DynamoDB,Amazon Bedrock, AWS IoT Greengrass等）を活用することで、スケーラブルかつ低コストな運用が可能です。 5.3 今後の展望 今回の展示はデモでありながら、今後の展開余地が大きい取り組みでもあります。 プレーヤーごとの癖や成長過程の可視化 ショット別の比較分析（フォアハンド / バックハンド / ボレー / バンデッハ） レベル別の推奨フィードバック コーチとの振り返り支援（セッション動画 + スコアの共有） 「どのトッププレーヤーのフォームに近いか」のパーソナライズ分析 マルチスポーツ対応（テニス、バドミントン、ゴルフ等） 写真: 教師データとして協力いただいたパデルトッププレイヤーの皆様 6. ぜひ会場で体験してください AWS Summit Japan 2026 の AWS Builders’ Fair は、遊び心あふれるテクノロジー展示を実際に見て、触って、開発者と会話できる場です。パデルフォーム分析アプリも、スポーツとテクノロジーが交わる体験を、できるだけ直感的に楽しんでいただけるよう準備しています。 ブースでアプリを体験いただいた方には、Amazon Padel ステッカーを配布予定です。AWS Summit Japan 2026 に参加される方は、ぜひ Builders’ Fair に立ち寄って、トッププレーヤーとのフォーム比較を体験してみてください。 AWS Summit Japan 2026 公式サイト: https://aws.amazon.com/jp/summits/japan/ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 中本 翔太(Shota Nakamoto) ネットワークチームに所属するソリューションアーキテクトで、サービス業界のお客様を中心にご支援をしています。 宇加治 邦生(Housei Ukaji) サービス業界のお客様を中心にご支援をしています。好きな AWS サービスは Kiro CLI です。

2025 年 3 月に Amazon OpenSearch Service による検索ワークショップ（日本語版）のご紹介 という記事を公開し、OpenSearch の基本概念から AI を活用した検索までを学べる日本語ワークショップをご案内しました。 このたび、2 つの日本語版ワークショップが仲間入りいたしましたので、ご紹介いたします。 EC サイト検索ワークショップ ：架空の EC サイトを題材に、検索機能を全文検索からセマンティック検索、マルチモーダル検索、エージェント検索へと段階的に育てていくワークショップです。また、ユーザーの行動ログを使った品質計測、機械学習による最適化を体験いただける実験的なラボも付属しています。 OpenSearch Observability Stack ワークショップ ：OpenSearch を Observability のバックエンドとして使い、マイクロサービスの APM・ログ・メトリクスを横断しながら、Agentic AI も活用して障害の原因を調査するワークショップです。Agent Trace といった新しい OpenSearch の Observability 関連機能もお試しいただけます。 以降、2 つのワークショップの概要について説明してまいります。 EC サイト検索ワークショップ 架空の企業「AnyCompany」が運営する EC サイトを題材に、商品検索を少しずつ改善していくシナリオ形式のワークショップです。OpenSearch の全文検索の導入からスタートし、ファセットやセマンティック検索、エージェント検索に至るまで検索機能を段階的に進化させていきます。 FastAPI + htmx による EC サイト風の検索 UI が付属しており、機能追加によって検索結果がどのように変化していくかを実際に比較・確認しながら進めることが可能です。 本ラボは Amazon SageMaker Studio の JupyterLab 上でノートブックを順次実行しながら進めていきます。商品のマスター情報は Amazon Aurora PostgreSQL に、検索インデックスは Amazon OpenSearch Service に格納されています。各種 ML モデルへのアクセスは、OpenSearch の connector を経由して行われます。 主要なリソースは以下のとおりです。 リソース 用途 Amazon OpenSearch Service 検索エンジン Amazon Aurora Serverless v2 商品マスターデータ（PostgreSQL） Amazon SageMaker Studio ノートブック実行環境（JupyterLab） Amazon SageMaker AI Embedding モデルのホスティング Amazon Bedrock LLM の利用（Agentic Query） ワークショップの構成 本ワークショップは 2 つのトラックが存在します。トラック A のみでもお楽しみいただけますが、トラック B まで実行することでより検索に対する理解を深めることができます。 トラック A: 検索機能の改善 トラック A は機能の改善にフォーカスしています。4 つのラボで構成されています。 全文検索の導入: OpenSearch の全文検索を導入し、形態素解析器 Sudachi による日本語トークナイズ、複数フィールドをまたいで検索する multi_match 、関連度スコアによるランキングを実装します。検索エンジンがなぜ高速に全文検索できるのか、その心臓部にあたる転置インデックスの仕組みにも触れます。 セマンティック検索の導入: テキストの「意味」で探すセマンティック検索を導入します。OpenSearch 3.1 で追加された semantic フィールドを使えば、インジェストパイプラインを書かずにベクトル検索を実現できます。Embedding モデルには日本語特化の ruri-v3-310m（Apache 2.0）を SageMaker エンドポイントで利用し、BM25 とセマンティック検索を組み合わせたハイブリッド検索も体験します。 マルチモーダル検索の導入: テキストだけでなく、画像で商品を探す体験を追加します。「この写真に似た商品を探して」といったユースケースに応えるため、画像とテキストを同じベクトル空間にマッピングする CLIP（clip-japanese-base-v2）を使います。Ingest Pipeline の text_image_embedding プロセッサが投入時に画像を自動でベクトル化するので、テキストから画像を探す検索と、画像から似た画像を探す検索の両方を、1 つのベクトルフィールドだけで実現できます。 エージェント検索の導入: OpenSearch 3.2 で追加された Agentic Query を使い、自然言語で商品を検索できるようにします。ユーザーの質問を LLM が QueryDSL に変換し、思考の過程も含めた結果を出力します。Amazon Bedrock 上の Anthropic Claude モデルと組み合わせて、検索バーに軽量な Flow Agent（Claude Haiku 4.5）を、チャット UI にはメモリ機能をサポートした Conversational Agent（Claude Sonnet 4.6）を搭載し、その違いを比較します。 トラック B: 計測と改善 トラック B は計測と精度改善にフォーカスしています。3 つのラボで構成されています。 ユーザー行動ログの蓄積と分析: UBI（User Behavior Insights）は、検索クエリ・クリック・カート追加・購入といったユーザー行動を、標準スキーマで記録する仕組みです。本ワークショップではサンプルの行動データを使った分析を実際に体験します。 検索品質評価: UBI データを使って、検索品質を数値で評価します。Search Relevance Workbench（SRW）と呼ばれるツールを活用し、テキスト検索やハイブリッド検索等の各種検索手法がどのようなクエリで有効であるかを評価指標に基づいて分析します。人間による分析に加えて、MCP + Strands Agent を活用したエージェントによる分析も応用パートとして提供しています。 Learning to Rank: UBI データと SRW の判定セットを学習データに使い、XGBoost（LambdaMART）でモデルを学習します。そして、ハイブリッド検索で絞り込んだ上位を LTR で並べ替える 2 段階ランキングを構築します。特徴量は BM25 派生のものから始め、人気度や在庫といったビジネス特徴量、さらにユーザーのペルソナを段階的に組み込んでいきます。 OpenSearch Observability Stack ワークショップ OpenSearch Observability Stack は、OpenSearch と Prometheus をバックエンドとした、Observability プラットフォームです。Piped Processing Language (PPL) によるトレース・ログ・メトリクスの分析、ダッシュボード上での可視化、Agent Trace、アラートや異常検知といった機能を OpenSearch UI と呼ばれるダッシュボードを通じて利用することができます。Ask AI と呼ばれる機能を活用した AI によるインシデント分析も可能です。 このワークショップでは、16 のマイクロサービスで構成されている EC サイトで発生した問題を、OpenSearch Dashboards の Observability 機能と Agentic AI（AI アシスタント）を用いて調査を行いながら各機能についての理解を深めていく内容となっています。 OpenTelemetry Demo （EC サイトを模した 16 のマイクロサービス）を Amazon EKS 上にデプロイし、OpenTelemetry Collector が集めたトレース・ログ・メトリクスを Amazon OpenSearch Ingestion（OSIS）と Amazon Managed Service for Prometheus（AMP）に送り込む構成となっています。 OSS 版ではセルフホストが必要な部分を AWS マネージドサービスに置き換えているため、参加者はインフラの構築ではなく、Observability の体験そのものに集中できます。 ワークショップの流れ ラボは基本的に任意の個所から開始することが可能ですが、順番に進めることでよりスムーズに理解を深めることができます。 ラボ 1. Application Performance Monitoring による調査 Application Map でサービス間の依存関係とエラー率を一目で把握し、RED メトリクス（Rate, Errors, Duration）から問題のあるサービスを判定、関連するトレースやログを確認していきます。 ラボ 2. Ask AI によるサービス障害調査 OpenSearch Dashboards に組み込まれた Ask AI に、「直近で一番エラーの多いサービスは？」と自然言語で尋ねるところから始めます。Investigation Agent が、複数のデータソースを自律的に横断して根本原因の仮説を立て、その調査過程をノートブックとしてまとめる様子を見ることができます。 ラボ 3. Discover による分析 ログ・トレース・メトリクスを、PPL（Piped Processing Language）や PromQL を活用して横断的に掘り下げて分析します。 ラボ 4. Dashboard に集約する Discover で作成した Visualization を Dashboard に集約し、チームで共有できる運用ダッシュボードを構築します。 ラボ 5. 異常検知・アラート・Forecast OpenSearch の組み込み ML を使い、Anomaly Detection（Random Cut Forest）による異常検知、Alerting による通知、Forecasting による将来の予測を設定します。 その他のラボ 本ワークショップでは、他にも応用的なラボをいくつか提供しています。 例えば、Agent Trace と呼ばれる機能を活用して、Amazon Bedrock 上の Anthropic Claude を使った商品レコメンドエージェントが生成する gen_ai.* スパンを分析し、Agent の思考の流れ（Agent Graph）やトークン使用量の可視化などを体験することができます。 ワークショップの始め方 Workshop Studio にアクセスし、トップページから取り組みたいワークショップを選んでください。 各ワークショップには CloudFormation テンプレートが付属しており、ご自身の環境に必要な AWS リソースを簡単にデプロイすることが可能です。ご自身の AWS アカウントでも、AWS イベント会場で Workshop Studio が払い出す一時アカウントでも実施できます。 リソース展開後は、SageMaker Studio（JupyterLab）もしくは OpenSearch Dashboards にアクセスし、ノートブックや Workshop Studio サイトの手順に沿って学習を進めていきます。 なお、ご自身の AWS アカウントで実施する場合は、OpenSearch・Aurora・SageMaker・EKS などのリソース利用に応じた料金が発生します。ワークショップを終えたら、クリーンアップ手順に従ってリソースを削除してください。 まとめ 今回追加された二つのワークショップはいずれもユースケースに即した内容となっており、一連のラボを通して OpenSearch に関する最新の知見や活用イメージの把握に繋げることができます。 EC サイト検索ワークショップでは、検索機能を段階的に育て、その効果を計測し、機械学習で改善するまでの一連のサイクルを体験できます。OpenSearch Observability Stack ワークショップでは、検索エンジンとは違う一面、Observability のバックエンドとしての OpenSearch と、Agentic AI を取り入れた分析を体験することができます。 検索から Observability、そして AI Agent の活用まで、ハンズオンを通して OpenSearch の可能性に是非触れてみてください。 関連リンク Amazon OpenSearch Service Amazon OpenSearch Service Workshops [Japanese] 前回のブログ：Amazon OpenSearch Service による検索ワークショップ（日本語版）のご紹介 OpenSearch Observability Stack OpenTelemetry Demo ソリューションアーキテクト 榎本 貴之 (X: @tkykenmt )

2026 年 6 月 17 日、 ニューヨーク市で開催された AWS Summit では、AWS VP of Agentic AI である Swami Sivasubramanian が基調講演を行いました。 このイベントでの主な発表のまとめをご紹介したいと思います。 Amazon Bedrock AgentCore の新機能 Amazon Bedrock AgentCore に新機能を導入します。AI エージェントを組織、ウェブ、有料のナレッジにつなげたり、チームが本番環境で起きている問題を発見して修正できるようにしたり、エージェントの能力が向上するにつれてスケールできる制御を適用したりできるようになります。 これらの機能を組み合わせることで、より有能なエージェントを迅速に構築し、スケール可能な制御を使用してエージェントを管理し、継続的に改善することができます。詳細については、すべての新機能を網羅した ブログ記事 をご覧ください。 より高速で正確なエンタープライズ AI アプリケーションのための Amazon Bedrock Managed Knowledge Base のご紹介 – Bedrock のマネージドナレッジベースを使用してエンタープライズ RAG パイプラインを構築できます。ネイティブデータコネクター、自動マルチフォーマットデータ準備用のスマート解析、複雑な複数ステップのクエリ用のエージェンティックリトリーバーが提供され、これらはすべて AgentCore Gateway と統合されているため、開発者はインフラストラクチャ管理ではなくビジネス成果に集中できます。 Amazon Bedrock AgentCore でのウェブ検索の発表:AI エージェントに最新の正確なウェブ知識を身につけさせる – フルマネージド型のウェブ検索ツールを使用すると、エージェントはお客様の安全な AWS 環境からのデータ流出なしに、最新の引用ウェブ知識に基づいて回答を行うことができます。Bedrock AgentCore のエージェントに手動でウェブ検索を追加してインフラストラクチャを管理するのではなく、エージェントの構築に集中できます。 AWS WAF に AI トラフィック収益化機能が追加され、コンテンツ所有者による AI ボットへのコンテンツアクセス料金の請求が可能に – コンテンツプロバイダーやパブリッシャーは、コンテンツや API にアクセスする AI ボットとエージェントに請求する料金を調べ、計測し、支払いを回収する新しい Bot Control 機能を使用できます。AWS WAF では、そのアクセスの料金を設定したり、サードパーティープロバイダーを通じて支払いを受け付けたり、範囲を指定したアクセスをエッジで直接付与したりできるようになりました。 Amazon Bedrock AgentCore ハーネスを一般公開 – Bedrock AgentCore ハーネスを使用してエージェントのモデル、ツール、スキル、設定手順を定義することで、オーケストレーションループをコーディングすることなく、プロダクショングレードの AI エージェントを数分で構築して実行できます。 AI ベースのセキュリティツールの新機能 AWS Continuum のご紹介: マシンスピードのセキュリティ – コードの脆弱性に対応する AWS Continuum では、ゲーテッドプレビュー形式で環境全体から調査結果を取得し、ビジネスへの影響に基づいて優先順位を付け、悪用可能なものを証明し、お客様独自のプロセスで修正を行うことができます。 AWS セキュリティエージェント (現在は AWS Continuum の一部) が脅威モデリング、Kiro パワー、Claude Code プラグインなどを追加 – 新しい脅威モデリング (プレビュー) を生成すると、アプリケーションのコンテキスト全体を理解し、STRIDE フレームワークを使用して推奨される緩和策で脅威を特定できます。また、主要な Git プラットフォーム全体でプルリクエストコードスキャンと修復機能を利用したり、Kiro パワー、Claude Code プラグイン、MCP を介して IDE を統合したりすることもできます。これにより、開発者はコンテキストを切り替えることなくセキュリティレビューを実行して問題を解決できます。 AI ベースのアプリケーション構築の新機能 Kiro for iOSのご紹介 – Kiroは、ゲーテッドプレビューで利用できるネイティブ iOS アプリを発表しました。これは実際のエンジニアリング作業向けに構築されており、Kiro セッションをスマートフォンから直接開始、監視、操作できる新しい画面が開発者に提供されます。つまり、ノートパソコンを起動していなくても、セッションを開始したり、完了したら確認したり、差分を確認したり、変更を承認したりできます。 AWS DevOps エージェントが、本番前にコードの変更を評価するリリース管理機能を追加 – コード変更の新しいリリース準備状況レビューと自律リリーステストを利用できます。これらの新機能は、すべての変更を DevOps Agent に提供する自然言語標準に照らして検証し、本番環境と同様の環境で変更固有のテストを実行します。 AWS Transform で自律的に技術的負債を積極的に削減 – 継続的なモダナイズ – 継続的分析 (プレビュー) を使用して、設定可能なベースラインと照らし合わせてコードリポジトリを自動的にスキャンし、数週間ではなく数時間で結果を生成できます。検出結果を特定して優先順位を付けたら、影響を受けるリポジトリのプルリクエストを自動的に生成する自律的な修復を設定できます。 基調講演に加えて、今週は他にも重要な発表があります。 Amazon S3 アノテーション: 豊富でクエリ可能なコンテキストをオブジェクトに直接アタッチ – Amazon S3 ではアノテーションを使用して、最大 1 GB のリッチで変更可能かつクエリ可能なコンテキストをオブジェクトに直接アタッチできるようになりました。これは、個別のメタデータシステムを維持することなく大規模なデータを発見、理解、処理する必要のある AI エージェントや自律型ワークフロー向けに構築されています。 原文は こちら です。

AWS では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。そして、この AI-DLC を 3 日間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 5 月 18 日〜20 日、日立のオフィスにて「日立グループ合同 AI-DLC UG」を開催しました。本記事では、その開催レポートをお届けするとともに、ワークショップを企画・伴走した AWS Japan カスタマーソリューションズ マネージャー 早川 康平が、日立グループ社内で AI 駆動開発ワーキンググループの立ち上げを牽引されるキーマン、株式会社日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 チーフクラウドアーキテクト 早川 裕志 氏にお話を伺いました。 1. 日立グループ合同 AI-DLC Unicorn Gym 開催レポート 日立グループ合同 AI-DLC Unicorn Gym（2026 年 5 月 18〜20 日）。3 社・8 チーム・52 名が参加した 今回の合同開催に先立ち、2026 年 1 月には株式会社日立産業制御ソリューションズが AI-DLC Unicorn Gym に参加され、従来 3 人月規模の開発を、わずか 2 日間で動くものとして作り、AWS にデプロイするところまで完了させるという成果を出されています（詳細は こちらの記事 ）。この先行事例での手応えが、今回の日立グループ合同開催へとつながりました。 当日は、日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 事業主管 鈴木 肇 氏、AWS Japan エンタープライズ事業統括本部 Hitachi事業部本部長 吉井の開会の挨拶から始まりました。 今回の UG には、日立製作所、日立ハイテク、日立産業制御ソリューションズの 3 社・8 チーム・52 名にご参加いただきました。顧客向け Web ポータル、半導体製造向け検査支援ツールなど、各チームが実際の業務テーマを持ち寄りました。 各チームに AWS のメンバーが伴走し、実テーマの開発を進めた 開催後のアンケートでは、他社での UG 実績と比較しても非常に高い評価をいただきました。 全体満足度：5 点満点中 4.67 日立グループへの推奨意向：回答者の 100% が「ぜひ／強く薦めたい」 「AI-DLC は働き方を変える可能性がある」：回答者の 92% が肯定 開発工数の削減について、回答者の 90% が「70% 以上の削減」を、72% が「85% 以上の削減」を体感 回答者の 95% が、3 日間で「動作する成果物」に到達または部分到達 参加者からは「AI 駆動開発の威力に驚いた（推論プロセスの追跡や影響範囲の可視化）」「製造スピードが段違い」といった声が寄せられた一方、「Coding Agent の社内払い出しの簡素化」「大規模開発のプラクティス」「品質保証との両立」といった、本番適用に向けた改善の要望もいただきました。 この結果は、日立グループが掲げる成長エンジン「Lumada 3.0」をより高速に生み出すための開発手法の 1 つとして、AI-DLC の可能性を示すことができたものと考えています。 2. 推進キーマンインタビュー ここからは、AI-DLC UG にも参加され、日立グループ展開に向けた AI 駆動開発ワーキンググループの立ち上げを牽引される早川 裕志 氏と、今回の AI-DLC UG をリードした AWS Japan カスタマーソリューションズ マネージャー 早川 康平との対談をお届けします。 株式会社日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 チーフクラウドアーキテクト 早川 裕志 氏 アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションズ マネージャー 早川 康平 想像を超えた、社内の反響 早川 康平（AWS） では、お願いします。「早川対談」、ようやく実現しましたね。 早川 裕志（日立） 早川 × 早川、楽しみにしていました（笑）。 早川 康平（AWS） ブログにするときは、お二人が区別しやすいように工夫します（笑）。では、さっそく。第 1 回となる日立グループ合同 AI-DLC UG、開催後の反響はいかがでしたか。 早川 裕志（日立） 実は私どもでもアンケートを取らせていただいたのですが、満足度は 5 点満点で 4.7 を超えていました。社内で改善というと「2 割」「15%」といった数字が並ぶなかで、 開発工数が大幅に減ったという結果は劇的で、インパクトがすごかった 。一方で、数字が大きすぎたことで「小さなテーマだからそうなんでしょ」という声も生まれました。それをどう払拭していくか、というところに、むしろモチベーションが湧いてきた感覚です。 早川 康平（AWS） 先日、今回ご参加いただいたチームの本部長の方にもご報告したのですが、同じような反応をいただきました。「2 カ月の開発が 2 日になった、と聞いたが、本当なのか」と。ここは正直にお伝えしています。今回 UG で各チームが取り組んだのは、実際の業務テーマで動くものを作り、AWS にデプロイするところまでで、その速さは確かな成果です。ただ、それをお客様に提供する本番システムとして世に出すには、日立が積み上げてこられた品質保証の工程──テスト、承認、レビューなど──を通す必要があります。つまり 「動くものをデプロイするまでの速さ」と「本番リリースまでの工数」は別物 で、今回の数字は前者にあたります。だからこそ、その品質保証の工程まで織り込んだ「日立版 AI-DLC」にしていく必要がある、と考えています。 最大の壁は、技術ではなくマインドセット 早川 裕志（日立） 今回、参加者の多くが AI-DLC にとても前向きで、感銘を受けました。その一方で、「AI に仕事を奪われるのではないか」という、いわば積み重ねてきたアイデンティティへの不安を抱える人もいます。どんなにいいと思っていても、どこかに反発するラインがある。そこをどう越えるかは、トップダウンでもボトムアップでも、 技術だけでは解決できない問題だと感じています 。 早川 康平（AWS） 大事なのは発想の転換だと思っています。たとえば 10 人で 1 年かけて 1 つのプロダクトを作っていたなら、これからは同じ 10 人で 1 年に 10 プロダクト作ろう、と。リリースと改善のスピードを何倍にも上げていく。とくに AI 時代はあらゆるプレイヤーが一気に立ち上がる群雄割拠の世界です。これまでのリリーススピードのままでは、もう他社に太刀打ちできない。AI-DLC は、 人を減らすための手法ではなく、生み出す価値を増やしスピードを上げるための手法 です。そういうポジティブな方向に向けられたら、と思っています。 早川 裕志（日立） UG を見学していて、最初はみんなギクシャクしているなと感じました。でも、どこかで一気に盛り上がるラインがある。AI-DLC UG では、ビジネスサイド（PdM）とエンジニアが膝を突き合わせて、常に議論しながら一緒に意思決定していきます。「誰が何を、どう決めるか」というプロセスそのものが従来と変わるので、最初は慣れないんですね。でも、そのラインを越えると一気に変わります。その場で議論して決めたことが、すぐ目の前で形になっていく。 役割の壁を越えて一緒に作っている感覚 があって、見ていてもチームが生き生きしてくるのが分かりました。この協働の体験そのものが、何よりの価値だと思いました。 AI-DLC は「品質を犠牲にスピードを出す」手法ではない 早川 康平（AWS） ここはよく誤解されるところなので、この場でもはっきり言っておきたいのですが、AI-DLC を「品質を犠牲にして生産性を爆上げする手法」だと捉える方がとても多い。それは違います。 AI-DLC の本質は、人間が開発の主導権を握り続けること（Human-in-the-Loop）にあります 。AI が計画や実装の草案を担い、何を作るか・採用するかという重要な判断は人間が下す。だからこそ、AI が解釈した「それっぽいもの」ではなく、意図したとおりのものを、速く作れるのです。 では、どこで品質を担保するのか。AI-DLC では開発ステップを明確化し、工程ごとに人間の承認ゲートを設けます。AI が作るのはあくまで草案で、承認を経て初めて人間の成果物になる。速さのために品質を犠牲にしているわけではなく、 むしろ人間が要所を押さえることで、速さと品質を両立させる ──ここは正確にお伝えしていく必要があると考えています。 早川 裕志（日立） そこは私も強く共感するところです。今後、必ず「AI が生成するコードの品質はどうなんだ」という指摘が出てきます。ただ、これは「人間のほうが AI より品質が高い」という単純な話ではないんですよね。日立には、長年積み上げてきた品質保証のプロセスがあります。事業部によってそのかたちは違いますが、その積み重ねこそが私たちの強みです。AI に任せきりにするのではなく、 その品質保証のプロセスを AI-DLC の進め方そのものに織り込んでいく 。そこができて初めて、日立として安心して本番に使える、と言えるのだと思います。 早川 康平（AWS） おっしゃるとおりで、まさにそこが「日立版 AI-DLC」の肝になります。 「日立版 AI-DLC ワークフロー」を、各現場で育てる 早川 康平（AWS） そのために、日立版の AI-DLC ワークフローを作る必要があります。AWS が GitHub で公開している AI-DLC Workflows をベースに、まずは日立として最低限守るべきものを 1 つの「汎用版」として整える。 それを各事業部・グループ会社が Fork（複製）して、それぞれに合わせてカスタマイズしていく ──というのが現実的だと考えています。 早川 裕志（日立） 日立グループは幅広いんです。SIer としての顔もあれば、事業会社としての顔もある。金融、公共、鉄道……それぞれ品質基準がまったく違います。共通化できる「ベーシックなライン」は AI-DLC で一緒に作り、 最後のカスタマイズ（ラストワンマイル）は各現場が地道に埋めていく 。そのバランスが大事だと思っています。 日立 AI 駆動開発ワーキンググループの構想を語る 早川 裕志 氏 日立 AI 駆動開発ワーキンググループの立ち上げ 早川 康平（AWS） その推進母体として、日立社内に AI 駆動開発ワーキンググループを立ち上げる、と。 早川 裕志（日立） はい。詳細は今後発表していきますが、特定の事業部に閉じず、各 BU・グループ会社から広くメンバーを集めたいと考えています。AI-DLC を一緒にやりたいと言ってくれている熱意あるフロントのメンバー、そして品質保証の担当者を巻き込んで。「小さく始めて大きくする」とよく言いますが、私はむしろ 「広く、小さく」始めたい 。熱意のある人たちで、AI 駆動開発をグループ全体に広めていきましょう。やり方はいくつもありますが、そのなかでも最も有力なアプローチとして、AI-DLC を使って始めていく考えです。 もう「AI を活用するかどうか」を議論する時代は終わった と思っています。AI が当たり前になる時代です。AI の効果は複利で効きます。早くやらないと本当についていけなくなるし、早く動けば、その分だけ事業リターンも大きい。だからこそ、AWS さんには単に支援していただくというより、 日立グループのための AI 活用パートナーになってほしい 。ぜひ、ご一緒させてください。 3. AWS の今後の支援 日立グループの AI 駆動開発を、ともに前へ進めていく AWS は、日立グループの AI 活用パートナーとして、全力で支援してまいります。 まず認知を広げるために、今後日立グループ向けの AI イベントを毎月企画していきます。Coding Agent（Kiro、Claude Code）のハンズオン、AWS Ambassadors と連動した社内向けイベント、AI 活用事例の紹介などを予定しています。あわせて、人材育成の研修プログラムについても提案していきます。 認知の次は実践です。UG の定期開催で実プロジェクトへの適用を進め、日立版 AI-DLC ワークフローの策定にも並走します。日立グループの AI 活用を全力で支援し、日立が掲げる Lumada 3.0 の実現に向けたパートナーとして、これからもご一緒させていただきます。 早川 裕志 氏、本日はありがとうございました。 本記事は、2026 年 5 月 18〜20 日に開催した「日立グループ合同 AI-DLC Unicorn Gym」の開催レポート、および 2026 年 6 月 9 日に実施した開催後インタビューをもとに構成しました。 著者 早川 康平 アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションズ マネージャー。金融勘定系システムの PM、Web エンジニア、SaaS プロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任の CSM として、SaaS アプリケーション開発や AI 活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。

2026 年 6 月 16 日、 Amazon Simple Storage Service (Amazon S3) 向けの新しいメタデータ機能であるアノテーションを発表しました。これにより、大規模かつリッチなビジネスコンテキストをオブジェクトに直接アタッチできるようになります。オブジェクトごとに最大 1,000 個の名前付きアノテーションを保存できます。各アノテーションのサイズは最大 1 MB、合計でオブジェクトあたり最大 1 GB です。JSON、XML、YAML、プレーンテキストなど、柔軟な形式に対応しています。オブジェクトを書き換えることなく、いつでもアノテーションを変更または削除できるため、オブジェクトのコンテキストを常に最新の状態に保つことができます。 組織は、人間の介入なしにデータを検索および理解し、データに基づいてアクションを実行する必要がある AI エージェントや自律型ワークフローを構築しています。これらのエージェンティックワークフローをサポートするには、データとともに進化し、ペタバイト規模のオブジェクトにスケールでき、高コストの取得なしでクエリ可能な状態を維持できるメタデータが必要です。 S3 アノテーションを使用することで、AI が生成したトランスクリプト、コンテンツの評価、技術仕様などのコンテキストを、オブジェクトとともに保存できます。コンテキストは、コピー、レプリケーション、クロスリージョン転送中に自動的にオブジェクトとともに移動し、オブジェクトを削除すると S3 によって削除されます。 S3 Metadata を有効にすると、アノテーションは自動的にフルマネージドアノテーションテーブルに反映され、 Amazon Athena や他の分析エンジンでクエリできます。 一般的なユースケース アノテーションは、業界を問わず、複雑なメタデータの課題を解決します: メディア & エンターテイメント : 動画アセットで、トランスクリプト、コンテンツモデレーションの結果、字幕ファイル、ライセンスメタデータを個別のアノテーションとして追跡することで、複数のメディアアセット管理システムでメタデータを同期する必要がなくなります。 金融サービス : AI が生成した投資の要約と感情分析を調査ドキュメントにアタッチすることで、自律型調査エージェントが個別のメタデータデータベースを維持することなく、自然言語クエリを通じて関連データセットを検出できるようになります。 ライフサイエンス : 臨床試験データに、規制関連のステータス、患者コホートの詳細、承認履歴などのアノテーションを付加することで、Amazon S3 Glacier ストレージクラスにアーカイブされたデータについての完全なコンテキストに取得料金なしでアクセスできるようにしながら、コンプライアンス監査を迅速化できます。 アノテーションがメタデータに関する課題をどのように解決するか Amazon S3 は、オブジェクトを記述するための複数の方法を既にサポートしています。システム定義メタデータは、サイズやストレージクラスなどのプロパティをキャプチャします。オブジェクトタグは、アクセスコントロールやライフサイクル管理などの運用タスクをサポートします。ユーザー定義メタデータを使用すると、アップロード時に少量のカスタム情報を追加できます。 これらの機能はそれぞれの目的には適していますが、別途メタデータシステムを構築および維持することなく、よりリッチなコンテキストをアタッチする必要がある場合には限界があります。アノテーションは、根本的に異なる規模と柔軟性でメタデータ機能を提供することで、これらのニーズに対応します。10 個のイミュータブルなタグや 2 KB のヘッダーとは異なり、オブジェクトごとにミュータブルかつクエリ可能なコンテキストを提供します。 機能 最大サイズ ミュータブル? 最適な用途 システム定義メタデータ 固定 いいえ オブジェクトのプロパティ (サイズ、ストレージクラス、作成時刻) ユーザー定義メタデータ 2 KB いいえ (アップロード時に設定) 小規模な key-value ペア オブジェクトタグ 10 個のタグ、キー/値ごとに 128/256 文字 はい アクセスコントロール、ライフサイクルルール、コスト配分 アノテーション 1 GB (1,000 × 1 MB) はい リッチなビジネスコンテキスト (JSON、XML、YAML、プレーンテキスト) 現在、S3 オブジェクトを記述するメタデータは、多くの場合、別のデータベースまたはサイドカーファイルに格納されており、データストレージよりも高いコストがかかる可能性がある、複雑な同期ワークフローが必要となります。S3 Metadata アノテーションテーブルを有効にすると、このコンテキストは Amazon Athena を通じて大規模にクエリ可能になります。AI エージェントは、 S3 Tables MCP サーバー を使用して自然言語を通じてデータを検出できます。このサーバーは、AI モデルがアノテーションをクエリするための標準化されたインターフェイスを提供します。あらゆるストレージクラスのオブジェクトのアノテーションを、オブジェクトを復元したり、取得料金を支払ったりすることなくクエリできます。 アノテーションの開始方法 アノテーションの使用を開始するには、 AWS Identity and Access Management (IAM) ポリシーまたはバケットポリシーが、 s3:PutObjectAnnotation アクションと s3:GetObjectAnnotation アクションの許可を付与していることを確認してください。その後、 PutObjectAnnotation API を使用して、既存または新規の S3 オブジェクトにアノテーションを追加できます。 例えば、メディア企業は、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、技術仕様と AI が生成した要約を動画アセットにアタッチできます。 # 技術メタデータを含む JSON ファイルを作成します cat > mediainfo.json << 'EOF' {"codec":"H.265","resolution":"3840x2160","audio_tracks":8,"frame_rate":29.97} EOF # それをアノテーションとしてアタッチします aws s3api put-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name mediainfo \ --annotation-payload ./mediainfo.json # AI が生成したプレーンテキストの要約を、別のアノテーションとしてアタッチします echo "A 90-minute nature documentary covering wildlife migration patterns across three continents, featuring aerial footage and underwater sequences.Languages: English, Spanish, Portuguese." > ai_summary.txt aws s3api put-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name ai_summary \ --annotation-payload ./ai_summary.txt これらのコマンドは、2 つの別々のアノテーションを同じ動画オブジェクトにアタッチします。 mediainfo アノテーションには構造化された技術仕様が JSON 形式で格納され、 ai_summary アノテーションにはテキストの説明が格納されます。各アノテーションは一意の名前で識別され、それぞれを個別に読み取り、変更できます。各アノテーションの一意の名前により、異なるアノテーションを使用して、複数の同時実行エンリッチメントワークフローをサポートできます。例えば、あるチームが技術メタデータを追加し、別のチームがコンテンツ分類を追加するといった作業を、互いに干渉することなく行うことができます。 GetObjectAnnotation API を使用して特定のアノテーションを取得します。 aws s3api get-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name mediainfo \ ./mediainfo-output.json オブジェクトにアタッチされているすべてのアノテーションを表示するには、 ListObjectAnnotations API を使用します。 aws s3api list-object-annotations \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 特定のアノテーションが不要になった場合は、 DeleteObjectAnnotation API を使用して削除します。 aws s3api delete-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name mediainfo 既存のアノテーションは、同じアノテーション名を指定して PutObjectAnnotation API を再度呼び出すことで、いつでも更新できます。マルチパートアップロードを使用してアップロードされた大きなオブジェクトの場合、マルチパートアップロードの完了後に PutObjectAnnotation API を使用してアノテーションをアタッチします。 S3 Metadata テーブルを使用した、アノテーションの大規模なクエリ 個々のオブジェクトにアノテーションをアタッチすることは便利ですが、その真の力は、すべてのアノテーションを大規模にクエリする際に発揮されます。バケットで S3 Metadata のアノテーションテーブルを有効にすると、S3 は、アノテーションテーブルと呼ばれるフルマネージド Apache Iceberg テーブルにアノテーションを自動でインデックス化します。Amazon Athena または Iceberg 互換のエンジンを使用して、アノテーションテーブルをクエリできます。 アノテーションテーブルを有効にするには、S3 コンソールまたは CreateBucketMetadataConfiguration API を使用します。次の例では、変更追跡用のジャーナルテーブルを保持し、ライブインベントリテーブルを無効にしつつ、アノテーションテーブルを有効にした新しいメタデータ設定を作成します。 { "JournalTableConfiguration": { "RecordExpiration": { "Expiration": "DISABLED" } }, "InventoryTableConfiguration": { "ConfigurationState": "DISABLED" }, "AnnotationTableConfiguration": { "ConfigurationState": "ENABLED", "Role": "arn:aws:iam::123456789012:role/S3MetadataAnnotationRole" } } この設定により、S3 は、クエリ可能なテーブルのすべてのアノテーションを自動的にキャプチャします。適用されると、このバケット内のオブジェクトにアタッチしたアノテーションは、約 1 時間以内にテーブルに表示されます。 メタデータ設定が既にバケットに存在している場合は、 UpdateBucketMetadataAnnotationTableConfiguration API を使用します。 aws s3api update-bucket-metadata-annotation-table-configuration \ --bucket my-media-bucket \ --annotation-table-configuration '{"ConfigurationState":"ENABLED","Role":"arn:aws:iam::123456789012:role/S3MetadataAnnotationRole"}' 有効にすると、アノテーションは自動的にアノテーションテーブルに反映されます。ジャーナルテーブルはほぼリアルタイムで更新されますが、アノテーションテーブルは 1 時間以内に更新されます。事前定義済みのスキーマを必要とする従来のメタデータテーブルとは異なり、アノテーションテーブルは、記述した JSON、XML、または YAML 構造に自動的に適応します。各アノテーションはテーブルの行となり、その内容は [text_value] 列に格納されます。これにより、スキーマ移行なしで、すべてのアノテーションをクエリできます。 既にアノテーション付きオブジェクトが存在するバケットでアノテーションテーブルを有効にすると、S3 は、既存のアノテーションを自動的にテーブルにバックフィルします。バックフィルプロセスはバックグラウンドで実行され、オブジェクトの数によっては数時間から数日かかる場合があります。 例えば、Amazon Athena を利用してバケット全体で 8 個を超える音声トラックを含むすべての動画アセットを検索するには、次のクエリを使用します: SELECT DISTINCT bucket, object_key FROM "s3tablescatalog/aws-s3"."b_my_media_bucket"."annotation" WHERE name = 'mediainfo' AND CAST(json_extract_scalar(text_value, '$.audio_tracks') AS INTEGER) > 8 このクエリは、アノテーションテーブルをスキャンして mediainfo という名前のすべてのアノテーションを検索し、JSON コンテンツから [audio_tracks] フィールドを抽出して、カウントが 8 を超えるオブジェクトを返します。 あるいは、ジャーナルテーブルを通じて直近 24 時間以内に新しいアノテーションを受け取ったすべてのオブジェクトを検索するには、次のクエリを使用します: SELECT bucket, key, version_id, record_timestamp, annotation.name FROM "s3tablescatalog/aws-s3"."b_my_media_bucket"."journal" WHERE record_timestamp >= (current_date - interval '1' day) AND annotation.name IS NOT NULL AND record_type IN ('CREATE_ANNOTATION', 'DELETE_ANNOTATION') このクエリはジャーナルテーブルを使用して、アノテーションの変更をほぼリアルタイムで追跡します。これは、新規または削除されたアノテーションに対応するイベントドリブンのワークフローの構築に最適です。 また、 Amazon SageMaker Unified Studio または S3 Tables MCP サーバーを備えた任意の IDE でエージェントを使用して、自然言語でアノテーションによるオブジェクト検索を実行することもできます。例えば、「2023 年に公開されたスペイン語の字幕付き PG 指定映画をすべて検索してください」と指示すると、数秒で結果が返されます。接続されていない複数のシステムにクエリする場合には数時間かかるでしょう。 今すぐ始めましょう Amazon S3 アノテーションは、AWS 中国リージョンを含むすべての AWS リージョンで今すぐご利用いただけます。アノテーションテーブルは、S3 Metadata が利用可能なすべての AWS リージョンで利用可能です。 自律的にデータを検出する必要がある AI エージェントの構築、複雑なメタデータを持つペタバイト規模のメディアアセットの管理、アーカイブされたデータセットのコンプライアンスコンテキストの追跡のいずれを行う場合でも、アノテーションを使用することで、個別のシステムを管理することなく、リッチなメタデータをオブジェクトに直接アタッチできるスケールと柔軟性を活用できます。 アノテーションのストレージは、親オブジェクトが S3 Glacier または他のストレージクラスにある場合でも、常に S3 Standard 料金で課金されます。料金の詳細については、 Amazon S3 の料金ページ にアクセスしてください。 さらに詳しく知りたい場合や利用を開始するには、 Amazon S3 Metadata の概要ページ および Amazon S3 ドキュメント にアクセスしてください。フィードバックは、 AWS re:Post for S3 宛てに、または通常の AWS サポート担当者を通じてお寄せください。 Daniel Abib 原文は こちら です。

本記事は 2026 年 6 月 17 日に公開された Kyle Seaman による “ Introducing Kiro for iOS ” を翻訳したものです。 2026 年 6 月 17 日、本格的な開発業務に対応するネイティブ iOS アプリとして Kiro を提供開始します。これにより、開発者へ自分のスマートフォンから直接、Kiro セッションの起動、監視、軌道修正、対話を行える新たなインターフェースをご提供します。つまり、ノート PC を起動していなくても、セッションを開始し、完了したら戻って確認し、差分をレビューし、変更を承認するといった作業を、作業から離れずに行えるようになります。 リモートセッションが Kiro を使う標準的な方法になるにつれて、スマートフォンは仕事とつながり続ける自然な場所になります。Web セッションの延長線上にあるものとお考えください。短い確認を入れるだけでセッションを前に進められ、不要な手戻りを防ぎ、適切なコンテキストでエージェントが作業を進められるよう支援できます。選択できるモードは chat、spec、autonomous の 3 つです。質問するために短時間のチャットセッションを開く、要件を同期し続けるために仕様 (spec) 駆動のワークフローを継続する、タスクを完全に委譲するために autonomous セッションを開始するなど、いずれの場合も、電車の中やランチが届くのを待っている間に、ノート PC を一度も開くことなく行えるようになりました。 止まらないクラウドセッション アプリを開くと、Kiro はクラウドセッションのライブな状態を読み込み、アクティブなスレッド、承認、プロジェクトのコンテキストを横断して作業できるようにします。エージェントの応答はリアルタイムにストリーミング表示され、ツールの実行状況もインラインで表示されます。また、autonomous モードでは、計画からコードレビューまでの実行ステータスが、人間の介入なしに表示されます。エージェントはクラウド上で独立して動作するため、起動状態を保つデスクトップ、接続用の VPN、夜通し動かしておくマシンを必要とせず、常時稼働かつ常時アクセス可能です。 モバイルのために設計された差分表示 差分はファイルヘッダー付きのネイティブな差分カード（追加 / 削除）として描画されるため、小さな画面でもコードが読みやすく、全体をすばやく見渡せます。PR とコードレビューのステータスは、すべてのセッション行で一目で確認できます。レスポンシブな Web レイアウトはスマートフォンでコードを読むのに適した形ではないと分かっているからこそ、私たちはネイティブで作りました。 作業を開始して、後で確認する Kiro では、作業を委譲し、その場を離れ、PR として戻ってくることができるようになりました。仕様駆動のワークフローを継続すれば、Kiro が中断したところから引き継ぎます。あるいは、スマートフォンまたは Web から autonomous セッションを起動すれば、Kiro はクラウドサンドボックス内で独立して動作し、ファイルを調査してテストを実行します。Kiro が入力を必要とすると、いったん停止します。あなたはどこからでも応答して方向性を選べば、中断した地点から作業が再開されます。 同じエージェント、同じコンテキスト Kiro Web で開始したセッションは、同じ ID、同じ設定、同じモデルで自動的に表示されます。Google、GitHub、IAM、または Builder ID でサインインすれば、リポジトリ、認証情報、サンドボックスの状態がそのまま保持され、更新内容はリアルタイムでスマートフォンに表示されます。 単一のビューから、異なるリポジトリをまたいで動作する複数のセッションを管理し、プルリクエストを監視し、セッション単位でフロンティアモデルとオープンウェイトモデルから選択できます。すべてが Kiro から自動的に同期されるため、接点をまたいでも失われるものはありません。 新しいアイデアがふと浮かんだら、chat、spec、autonomous のいずれかのモードを選び、GitHub からリポジトリを接続し、モデルを選択してメッセージを送信するだけで、その場で直接セッションを作成できます。別のコンテキストウィンドウを持つ別アプリではなく、あなたについてくる 1 つのエージェントです。 はじめる Kiro の iOS は、Kiro Pro、Pro+、Pro Max、Power のお客様向けに提供いたします。 早期アクセスをリクエスト いただければ、順番にご案内します。Kiro CLI、Web、IDE で利用しているものと同じ ID でサインインでき、セッション、モデル設定、接続済みリポジトリが自動的に同期されます。iOS 26 以降が必要です。 翻訳は Solutions Architect の吉村 が担当いたしました。

大規模なデータ量を運用するうえで、運用面での重要な課題に直面します。Similarweb では Apache HBase でこれらの課題に直面し、 Amazon DynamoDB で解決策を見出しました。 Similarweb は、 Web サイトのトラフィック、アプリの利用状況、市場トレンドに関する AI 駆動のインサイト を提供するデジタルインテリジェンスプラットフォームであり、企業が競合をベンチマークし、成長戦略を最適化するのに役立ちます。 私たちは既存の Apache HBase インフラストラクチャでスケーラビリティと運用上の複雑さの問題が増大しており、より柔軟で効率的な代替案を模索することになりました。本記事では、データストレージを Apache HBase から DynamoDB へ移行した過程を紹介します。技術的な課題、移行アプローチ、データモデリング戦略、コスト最適化テクニック、そして得られた主なメリットについて議論します。DynamoDB へ移行することで、パフォーマンスとスケーラビリティが向上し、メンテナンス負荷が軽減され、チームはインフラ管理よりもイノベーションに注力できるようになりました。学んだ教訓と、この移行が業務オペレーションに与えた影響についても探っていきます。 背景 私たちの Web アプリケーションでは、ユーザーに大量のデータを提供するために堅牢なデータベースソリューションが必要です。そのソリューションは、データを効果的に保存し、迅速に取得し、ユーザーインターフェイスに結果を返す前に集計、グルーピング、ソートなどの操作を実行する必要があります。これを実現するため、データの性質とクエリパターンに基づいた 2 つのアプローチを採用し、Web アプリケーションを応答性が高くインタラクティブに保つよう設計しています。 最初のアプローチは、ユーザー入力に依存する動的クエリや、サイトグループのべき集合のデータを計算するような複雑な計算に関するものです。これは膨大な数の組み合わせとなり、事前計算は現実的ではありません。そのため、これらのクエリには Firebolt のようなクラウド分析データベース (OLAP システム) を使用しています。Firebolt は、JOIN、GROUP BY、その他の SQL ライクなクエリ操作を含む複雑なクエリパターンにも使用しています。これらのデータベースは、ETL ベースの事前集計に適さない大規模データセットのオンザフライ処理に優れています。 一方、2 つ目のアプローチでは、予測可能で事前計算可能なアクセスパターンを持つ機能について、DynamoDB のようなキーバリュー (KV) ストアを使用しています。定期的な ETL プロセスでデータを事前計算することにより、DynamoDB は集計情報への高速で簡素なアクセスを提供し、パフォーマンスとスケーラビリティのバランスを取りながらユーザーに応答性の高い体験を提供します。 トラフィックとエンゲージメントデータを取得するための要件 事前計算データの利用方法を示すために、プラットフォームの UI で表示している、Web サイトのトラフィックとエンゲージメントの経時的な推移という典型的なユースケースを見てみましょう。 図 1: Similarweb の Traffic and Engagement レポートでは、ユーザーは分析するサイト (1) を選択し、日付範囲 (2) を選び、世界全体または特定の国などの地理的範囲 (3) を設定できます。これらの選択を行うと、グラフには選択した期間における訪問数やユニークユーザーといった主要メトリクスが表示されます。 例えば example.com などの Web サイトの訪問統計を、サイト名、日付、国 (ISO コード)、訪問数といった詳細とともに保存しています。   Site Country (ISO) Date Visits TimeOnSite BounceRate … example.com 840 2026-01-22 7 15.2 7 example.com 840 2026-01-23 11 11.7 1 example.com 840 2026-01-24 3 20.3 4 example.com 840 2026-01-25 12 13.2 5 example.com 840 2026-01-26 9 19.1 7 アクセスパターンとしては、example.com の特定の日付範囲における全国の訪問データを取得したり、米国 (840) のような特定の国の訪問データをクエリしたりすることが考えられます。このシナリオでは、ETL プロセス中に日付、国、サイトの各組み合わせに対する訪問数を事前に計算して保存することで、これらの一般的なアクセスパターンに対して迅速な応答時間を実現しつつ、クエリ時の計算オーバーヘッドを最小限に抑えることができます。 これらの事前計算されたメトリクスは単純に見えますが、Similarweb の規模では、その背後にある書き込み負荷とクエリの多様性が既存の HBase クラスタを限界まで押し上げました。私たちのケースでは、データは継続的に書き込まれるのではなく、Spark ジョブを使用して日次、週次、月次といったスケジュールされた間隔で大規模なバッチで取り込まれます。 大規模スケールと柔軟なアクセス Similarweb のトラフィックとエンゲージメントデータセットは膨大で、合計 255 テラバイト (TB) を超えます。データを継続的に取り込むトランザクションアプリケーションとは異なり、私たちの分析パイプラインは大きなバーストで呼吸します。データを新鮮に保つため、 1 テーブルあたり約 70 億レコード を、数時間で完了させる必要があるタイトなスケジュールのバッチで取り込んでいます。 しかし、データを書き込むことは戦いの半分にすぎません。保存後、このデータは多様で複雑な読み取りパターンに対して即座に利用可能でなければなりません。ユーザーは単純なキー検索以上のことを行います。彼らは複数の次元でデータを切り分けて、競合をベンチマークし、トレンドを分析します。 次の図は、移行前のハイレベルなデータフローを示しています。 図 2 (移行前): 生のイベントはデータレイクに到達し、Spark ETL が日次集計を計算し、バルク書き込みで結果を HBase に保存します。.NET バックエンドはサイトと国のメトリクスをキー (および日付) で読み取り、Traffic and Engagement UI に提供します。すべての矢印はデータフローを表しています。 単純なキーバリュー検索を超えて 特定のフィルタリングパターンに対して 1 桁ミリ秒の読み取りを提供しながら、大規模な書き込みスパイクに対応できるデータベースソリューションが必要でした。具体的には、任意のサイトに対して以下の 4 つのアクセスパターンをサポートする必要がありました。 サイトレベルの集計: サイトの全トラフィックを取得。 SELECT * WHERE Site = {site} 特定の国の内訳: 特定の国にドリルダウン。 SELECT * WHERE Site = {site} AND Country = {country} 時系列トレンド: 特定の期間の履歴を取得。 SELECT * WHERE Site = {site} AND Date BETWEEN {start} AND {end} 複雑な組み合わせ: 国と日付範囲の両方でフィルタリング。 SELECT * WHERE Site = {site} AND Country = {country} AND Date BETWEEN {start} AND {end} これを達成するために、理想的なデータベースは以下の 4 つの厳格な基準を満たす必要がありました。 高い書き込みスループット: 数時間で数十億レコードを取り込む。 多用途なクエリサポート: テーブル全体をスキャンせずに、前述の次元ベースのクエリを処理。 パフォーマンスを保ったスケーラビリティ: ピーク書き込み時でも高い読み取りパフォーマンスを維持。 コストの透明性: 請求書で驚くのではなく、実行 前に コストを見積もれる予測可能な料金モデルを提供。 HBase が壁にぶつかった理由 HBase は長年にわたって私たちに役立ってきましたが、Similarweb の規模では、徐々に「使用するデータベース」から「運用するシステム」へと変化していきました。中核的な制限は生の能力ではありませんでした。それは、非常に大規模なバッチ書き込みと常時稼働の読み取りに対する厳しい期待を組み合わせた後に現れた運用リスクと不安定さでした。 1. RegionServer の不安定性がオンコール対応の原因に 繰り返し発生するインシデントの原因は、HBase の RegionServer がクラスタの他の部分と同期しなくなったり、ダウンしたりすることでした。RegionServer がドリフトしたり誤動作したりすると、ホストするリージョンの可用性とレイテンシに影響を与える可能性があります。回復が可能な場合でも、それは不安で時間がかかるものであり、頻繁に発生したため、実質的な運用負担となっていました。 2. ストレージとディスクのアップグレードが悪夢 大規模な HBase 環境におけるディスク管理とアップグレードは、常に非常に摩擦の大きいものでした。分散システムにおけるディスク変更は単独のイベントではありません。それはパフォーマンス、安定性、運用手順に波及します。ルーチンとなるべきインフラ作業がしばしば実質的なリスクを伴う複数ステップのメンテナンスに変わり、特に取り込みウィンドウや読み取り SLA を保護しようとしているときには厳しいものでした。 3. アーキテクチャの利点が私たちのアクセスパターンと一致しなかった HBase のワイドカラムモデルは、大きな行から列のサブセットを読み取るときに真価を発揮します。私たちの場合、アクセスパターンはしばしばキーに対するメトリクスの完全なセットを読み取ることを必要としていたため、システムの最も強力な設計上の利点を一貫して享受することなく、システムの運用コストを支払っていることになっていました。 4. データベースがピーク向けにサイジングされていたため高コスト テラバイト規模のバッチロードは短く激しい書き込みピークを生み出す一方で、製品は依然として高速で予測可能な読み取りを必要としていました。ピーク向けにサイジングされた常時稼働クラスタを維持することは、1 日のほとんどで実際に使用していないキャパシティに対して支払うことを意味していました。 これらの課題は単一の壊滅的な障害として現れたわけではありません。それらは累積する運用負荷として現れました。深夜の呼び出しが増え、クラスタの健全性に費やす時間が増え、ルーチンメンテナンスのリスクが増加しました。その複合化するオーバーヘッドが、フルマネージドな代替案を探すことを促しました。 DynamoDB がこれらの課題にどう対処するか DynamoDB により、以下が可能になりました。 クリティカルパスからクラスタ運用を排除。 DynamoDB では、リージョンサーバーをプロビジョニングする必要がなく、リバランスもなく、インフラ層でのキャパシティプランニングも手動で行う必要がありません。それにより、データベースの健全性に関連する日常的な運用作業と障害モードの数が直接削減されました。 永続的なオーバープロビジョニングなしでバッチ取り込み向けにスケール。 私たちの書き込みパターンは予測可能です。書き込むレコード数と完了までの時間ウィンドウがわかっています。DynamoDB ではキャパシティをダイヤルとして扱うことができます。取り込み実行の直前に プロビジョンド書き込みキャパシティユニット (WCU) を即座にスケールアップし、完了次第すぐにスケールダウンします。これにより、24 時間 365 日大規模なクラスタを稼働させ続けるのではなく、コストをバッチウィンドウに合わせることができました。 書き込みスパイク中も読み取りパフォーマンスを安定的に維持。 UI の背後にあるアクセスパターンは、主にキーベースの検索と日付範囲クエリです。DynamoDB のパーティション化されたアーキテクチャと、 パーティションキーとソートキー に対する Query 操作 により、テーブルが非常に大きく成長し、取り込みジョブが並列実行されている場合でも、これらの読み取りを一貫して低レイテンシで提供できます。 コスト動作を明示的かつ予測可能に。 DynamoDB のキャパシティとリクエストパターンが私たちのワークロードにきれいにマップされるため、レコード数、アイテムサイズ、予想されるクエリの形状から書き込みと読み取りのコストを見積もることができます。これにより、コストモデリングは事後的な驚きではなく、設計の一部となりました。 耐障害性とディザスタリカバリオプションの改善。 DynamoDB は、すぐに使えるマネージドバックアップとリカバリプリミティブを提供します。マルチリージョンのニーズに対しては、 DynamoDB Global Tables でリージョン間でデータをレプリケートできるため、読み取りをローカルで提供でき、リカバリは大規模クラスタを圧力下で再構築することに依存しません。 この基盤が整ったことで、私たちのワークロード固有の部分、つまり高スループットで効率的に取り込む方法と、低コストでアクセスパターンを満たすためのキーモデリングに集中できるようになりました。次の図は、移行後のデータフローを示しています。 図 3 (移行後) : 事前計算されたトラフィックとエンゲージメントメトリクスは、2 つのパスを通じて提供されます。予測可能で低レイテンシのアクセスのための DynamoDB に支えられたキーバリューレーンと、動的でアドホックなクエリのための Firebolt を使用する分析レーンです。.NET バックエンドはそれに応じてリクエストをルーティングします。歴史的に、レーン A は HBase を使用していました。それを DynamoDB に置き換えました。 データモデリング DynamoDB のパフォーマンスとコストのメリットを最大限に引き出すためには、実際のクエリパターンに基づいてデータモデルを設計することが重要でした。私たちの目標は、応答時間と読み取り/書き込みキャパシティ使用量の両方を最小化する効率的なアクセスパスを作成することでした。 Traffic and Engagement の例を再度見てみましょう。コアアクセスパターンには、日付範囲全体にわたるサイトの訪問データの取得と、オプションで国によるフィルタリングが含まれます。 単純なアプローチ: パーティションキー 最初のアプローチは、次のようなフラットでユニークなパーティションキーを作成することかもしれません。 PK = {site}_{country}_{date} Primary key Visits TimeOnSite BounceRate PK example.com_840_2026-01-21 4 24 12.31 1 か月分のデータ、例えば 2026 年 1 月の米国 (国コード 840) における example.com への訪問を取得するには、31 個の個別のキーを生成し、BatchGetItem リクエストを発行します。 example.com_840_2026-01-01 example.com_840_2026-01-02 ... example.com_840_2026-01-31 この設計は機能しますが、スケールでは非効率でコストがかかります。単一の BatchGetItem リクエスト内では、各アイテムの取得が個別の読み取り操作としてカウントされ、ペイロードサイズが小さくてもアイテムごとに 1 つの読み取りキャパシティユニットを消費します。 最適な設計: パーティションキーとソートキーを持つコンポジットキー よりスケーラブルなモデルでは、パーティションキーとソートキーを持つ コンポジットプライマリキー を使用します。 パーティションキー (PK): {site}_{country} ソートキー (SK): {date} Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 このセットアップでは、DynamoDB の効率的な Query API を使用して、日付範囲にわたるサイトと国のペアのすべてのレコードをクエリできます。 Query(PK="example.com_840", SK BETWEEN "2026-01-01" AND "2026-01-31") これにより API コールの数が減り、ソートキーに対する範囲クエリを使用することで読み取りコストが大幅に削減されます。 コスト比較: Query 対 BatchGetItem サイトと国の組み合わせごとに 500 日分のデータを取得し、各エントリが約 200 バイトであるユースケースを考えてみましょう。 注: RCU はアイテムサイズに応じて 4 KB チャンクでスケールします。結果整合性のある読み取りでは RCU が半分になります。 アプローチ 読み取り API RCU 計算 推定コスト フラット PK BatchGetItem 500 アイテム × 1 RCU = 500 RCU $0.065 コンポジット PK + SK Query 100 KB / 4 KB = 25 RCU $0.00325 節約: コンポジットキー設計を使用することで 20 倍以上安価 。 全世界のユースケース コンポジットキーモデル ( PK = {site}_{country} 、 SK = {date} ) は、サイト、国、日付範囲でフィルタリングされた一般的なクエリを効率的にサポートしますが、 全国にわたる訪問データをクエリ する必要がある場合に課題が生じます。例えば、example.com の全世界の訪問を、全期間または特定の日付範囲で取得する場合です。 SELECT * WHERE Site = 'example.com' SELECT * WHERE Site = 'example.com' AND Date BETWEEN '2026-01-01' AND '2026-01-31' 既存のスキーマでは、 国コードがパーティションキーに埋め込まれて おり、これはパーティション間で書き込みと読み取りの負荷を均等に分散するために不可欠です。しかしこれは、 データをクエリするには国を知る必要がある ことも意味し、グローバル集計のユースケースには望ましくありません。 シンプルですが非効率な解決策は、すべての国別パーティションにわたって Query API コールをファンアウト することです。 # ファンアウト Query: すべての国にわたるサイトの訪問を取得 results = [] for country in country_codes: # ~200 ISO 3166 コード pk = f"example.com_{country}" response = query( TableName='TrafficTable', KeyConditionExpression="PK = :pk AND SK BETWEEN :start AND :end", ExpressionAttributeValues={ ":pk": pk, ":start": "2026-01-01", ":end": "2026-01-31" } ) results.extend(response['Items']) # 国レベルのレコードを集計して単一の世界規模ビューにする worldwide = {} for item in results: date = item['SK'] visits = item['visits'] worldwide[date] = worldwide.get(date, 0) + visits # worldwide = {"2026-01-01": 148200, "2026-01-02": 136400, ...} 機能的には正しいものの、このアプローチにはいくつかの欠点があります。 高コスト : サイト/日付クエリごとに 200 以上の Query リクエスト。 増加したレイテンシ : 200 のクエリにわたって結果をクエリし集計することで、応答時間が大幅に増加する可能性があります。 BatchQueryItem なし : BatchGetItem とは異なり、複数の Query リクエストを単一の API コールにバッチ処理するネイティブな方法はありません。 運用オーバーヘッド : 200 以上の並列クエリの管理は、アプリケーションに負荷をかけ、スロットリングのリスクを増加させる可能性があります。 ファンアウトのコストと複雑さを発生させずに効率的なグローバルクエリをサポートするため、ETL プロセス中に特別な合成国コード (例: 999) を導入しました。実際には、ETL パイプラインの一環として集計された世界規模メトリクスを事前計算して保存し、専用の「グローバル」パーティションに書き込みます。これは、世界規模データに指定されたパーティションキー PK = {site}_999 を使用することで実現します。 Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 example.com_999 2026-01-23 33 17 16.5 これにより、 単一の Query リクエスト で世界規模データをクエリできます。 Query(PK="example.com_999", SK BETWEEN "2026-01-01" AND "2026-01-31") このようにして、読み取り時のパフォーマンスオーバーヘッドがなく、複数ではなく 1 つの Query リクエストを使用するためコストも削減されます。 もちろん、「999」アプローチにもコストがかかります。サイトと日付ごとに追加の世界規模ロールアップを計算する必要があるため ETL の複雑さが増し、サイト国レコードごとに追加のアイテムを永続化するためストレージも増えます。それでも、システムをエンドツーエンドで見ると、明らかな勝利です。読み取り時から書き込み時に作業をシフトし、200 以上のファンアウトクエリの必要性を排除し、アプリケーション側のオーケストレーションを減らし、一貫してより高速な世界規模読み取りを実現します。実際には、追加の ETL とストレージコストはクエリコストとレイテンシの節約によって上回られるため、ソリューション全体としてはより安価で高速になります。 次のセクションでは、初期データ移行と毎月のデータ取り込み中に時間とコストを節約するために、DynamoDB の機能をさらにどのように利用しているかを探ります。 DynamoDB への書き込み バッチ取り込みは私たちの分析パイプラインの心拍です。継続的なストリームではなく、Databricks 上で日次、週次、月次のスケジュールで ETL Spark ジョブをトリガーするスケジュールされた Apache Airflow Directed Acyclic Graphs (DAGs) に依存しており、それぞれが下流機能の鮮度要件に合わせて調整されています。すべての実行で、テーブルが読み取りトラフィックに対してできるだけ早く準備できるように、短い時間ウィンドウ内に DynamoDB に数十億のアイテム、しばしば数テラバイトをプッシュします。 DynamoDB は、異なるワークロードパターンに対応する 2 つの異なる キャパシティモード を提供しています。オンデマンドモードはサーバーレスで従量課金型のモデルで、トラフィック需要に合わせて自動的にスケールし、キャパシティプランニングは不要で、使用した分のみ支払います。一方、プロビジョンドモードでは、希望する読み取りと書き込みのスループットを事前に指定する必要があり、課金はこのプロビジョンされたキャパシティに基づいて行われます (完全に使用されたかどうかにかかわらず)。私たちのケースでは、書き込むレコードの総数と取り込みの時間ウィンドウが既にわかっているため、必要な書き込みキャパシティユニットを正確に計算して設定できます。これにより、スケジュールされたバッチロードに対しては、プロビジョンドモードのほうがオンデマンドよりも大幅にコスト効率が良くなります。 エンドツーエンドのバッチワークフロー Airflow がロードをスケジュール DAG パラメータには、テーブル名とソースから読み取る日付範囲が含まれます。 ジョブはピークの重複を避けるためにずらされます。 Databricks Spark が ETL を実行 Spark のパーティションは、並列処理を最大化するために DynamoDB のパーティションキーと整合します。 DynamoDB Connector for Apache Spark を使用しており、これは書き込みをバッチ化し、指数バックオフによるリトライロジックを処理します。 キャパシティはジャストインタイムでスケールアップ ターゲット DynamoDB テーブルへの最初の書き込みの前に、インフラスクリプトが UpdateTable を呼び出してテーブルのプロビジョンド書き込みキャパシティ、つまり書き込みキャパシティユニット (WCU) を計算されたピークまで引き上げます。スクリプトは、目標期間とレコード数に基づいてこのレベルを自動的に設定します。 データを並列に書き込み DynamoDB Connector for Apache Spark を使用し、プロビジョンドキャパシティに密接に整合したスループットでデータを書き込みます。通常、プロビジョンド書き込みキャパシティの約 1.1 倍を目標とし、リソースを十分に活用しつつ最適な利用率を達成するため、制御されたレベルのスロットリングを受け入れます。 キャパシティは自動的にスケールバックダウン ETL がすべてのレコードの書き込みを終えると、UpdateTable を再度呼び出してプロビジョンドキャパシティ書き込みレベルを下げる後続タスクをスケジュールします。 def run_etl(table_name, records_count, target_duration_hours=1): # ステップ 3 -- キャパシティをジャストインタイムで計算してスケールアップ desired_wcu = ceil(records_count / (target_duration_hours * 3600)) desired_wcu = clamp(desired_wcu, MIN_WCU, MAX_WCU) wait_until_table_is_active(table_name) current_wcu = describe_table(table_name).provisioned_write_capacity update_table(table_name, wcu=current_wcu + desired_wcu) # UpdateTable API wait_until_table_is_active(table_name) try: # ステップ 4 -- Spark DynamoDB Connector を介してデータを並列に書き込み spark.write(target_table=table_name, write_throughput_ratio=1.1) # プロビジョンド WCU の約 110% finally: # ステップ 5 -- キャパシティを自動的にスケールバックダウン update_table(table_name, wcu=current_wcu) # UpdateTable API wait_until_table_is_active(table_name) DynamoDB テーブルのプロビジョンドキャパシティを計算してスケールアップする Python 疑似コード Amazon Simple Storage Service (Amazon S3) からの Import Table を使用する DynamoDB への書き込みの時間とコストをさらに削減するため、HBase からの移行時および一部の定期的な書き込みに、 DynamoDB Import from S3 機能を使用して、Amazon Simple Storage Service (Amazon S3) から直接データをインポートしました。これにより、レコードごとの書き込みが不要になり、取り込み時に書き込みキャパシティユニットを消費することがなくなります。 メリット バルク取り込みで 最大 90% のコスト削減 。 ETL 取り込みのための Databricks コンピューティング使用が不要 。 ネイティブインポートによってリトライロジックが隠蔽され、運用オーバーヘッドが取り除かれた 簡素化された運用 。 従来の Spark ジョブと比較して より高速な取り込み 。 Import Table 機能は、アイテムごとの書き込み操作ではなく、取り込まれたデータの総量に基づいて課金されるため、特に私たちのケースのように小さなアイテムを持つ大きなテーブルを移行する場合、大幅なコスト削減を実現します。 S3 からのインポートワークフロー ETL 前の自動化の一環として、データは指定された S3 パスから読み取られ、Import from S3 機能でサポートされている DYNAMODB_JSON 形式に変換されます。 整形されたデータの S3 パスとテーブル定義を指定して ImportTable API を呼び出します。 モニタリングタスクがインポート完了まで進捗を追跡します。 期間ごとに別々のテーブルにデータを保存するタイミング DynamoDB の Import from S3 機能は、大規模なバックフィルにとってゲームチェンジャーですが、重要な制約があります。新しいテーブルにのみインポートできるという点です。その制限は、データセットが自然に時間でパーティション化されており、主に最近の期間でアクセスされる場合には機会となります。 月次のデータセットでは、意図的な設計を採用しました。月ごとに 1 つのテーブルを作成し、Import from S3 を使用してその月のデータをインポートし、データが古くなるにつれてそれらのテーブルのライフサイクルを管理します。 月次データに適している理由 このアプローチが特に月次ワークロードに適している理由は以下のとおりです。 バルクロードが離散的 : 各月のデータセットは通常完全なバッチとして生成されるため、インポートのクリーンな単位になります。 クエリ時の運用の簡素さ : アプリケーションは、コールドデータとホットデータを 1 つの大きなテーブルで混在させる代わりに、関連する期間テーブルにクエリをルーティングできます。 保存期間管理が簡単に : 古いアイテムを削除する代わりに、期限切れになったテーブル全体を削除できます。 コスト最適化が容易 : 古い月次テーブルは、アプリケーションロジックを変更することなく、年齢を重ねるにつれて Standard-IA テーブルクラス に移行でき、ストレージコストを削減できます。 実用的な命名規則によって自動化が容易になります。例: {table_name}_2026-01 。 エンドツーエンドの実行方法 各月について、データセットを生成し、サポートされているインポート形式の 1 つである DynamoDB JSON に変換し、新しい月次テーブルに ImportTable を実行します。 インポート後、不要になったテーブルを削除する保存期間ポリシーを適用します。 古くなった月次テーブルを Table Class Standard-IA に移行してストレージコストを節約します。 要求された日付範囲が複数の月にまたがる場合、API は関連する月次テーブルにわたってクエリをファンアウトし、結果をマージします。 期間ベースのテーブルを使用すべきでない場合 このパターンは強力ですが、万能ではありません。 日次のデータセット の場合、1 日ごとにテーブルを作成するとテーブル数が爆発し、不必要な運用オーバーヘッドが発生します。そのような場合は、単一の長期間有効なテーブルを維持し、標準的な取り込みパス (Spark 書き込み + プロビジョンドキャパシティスケーリング) を続けるほうが良いです。 経験則 期間が粗い (月次以上) で、データがバルクでロードされ、保存期間がテーブルレベルで強制できる場合は、 期間ごとに別々のテーブルを優先 してください。 期間が細かすぎる (日次) 場合、または同じ物理テーブルへの継続的な増分書き込みが必要な場合は、 単一のテーブルを優先 してください。 結論 本記事では、Similarweb が Apache HBase から DynamoDB に移行した経緯を紹介しました。この移行は、運用を簡素化し、効率的にスケールし、インフラオーバーヘッドを削減しながら、大規模に高速で信頼性の高いインサイトを提供し続ける必要性によって推進されました。 レガシーの HBase セットアップは強力ではありましたが、増大するバッチ取り込みワークフローと動的クエリ要件のニーズに応えるのに苦労していました。安定性、運用メンテナンス、スケーリングの限界などの課題が、よりモダンなサーバーレスの代替案を求めるきっかけになりました。 DynamoDB を採用することで、以下を達成しました。 インテリジェントな書き込みプロビジョニングを伴う ETL ジョブを使用した 高パフォーマンスなバッチ取り込み 。 大規模で多様なクエリパターンをサポートする 柔軟でコスト効率の高いデータモデリング 。 フルマネージドでサーバーレスな DynamoDB アーキテクチャによる 運用負担の削減 。 Amazon S3 から直接インポートすることによる 低い運用負担と高速な履歴データ移行 。 手動のクラスタ管理なしでの システム信頼性とスケーラビリティの向上 。 この移行は、データインフラのパフォーマンスと安定性を向上させ、エンジニアリングチームが機能の構築とイノベーションの推進に集中できるようにしました。DynamoDB は、私たちの分析パイプラインの強靭でコスト効率の高い基盤であることが証明されており、Similarweb がお客様にタイムリーで実行可能なデジタルインサイトを提供するというミッションを支えています。 本記事は 2026 年 06 月 16 日 に公開された “Similarweb’s migration from HBase to Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/similarwebs-migration-from-hbase-to-amazon-dynamodb/ 著者について Idan Lahav Idan はテルアビブを拠点とする Similarweb の R&D ディレクターです。バックエンドインフラ、プラットフォーム基盤、データエンジニアリングに深い専門知識を持ち、スケーラブルなデータパイプラインアーキテクチャの設計と、高スループットプラットフォームの複雑な課題の解決に注力しています。最近の HBase から DynamoDB への移行において、Idan は移行を可能にした基盤となるインフラ基盤の設計と管理を担当しました。 Leonid Koren Leonid は AWS のプリンシパル NoSQL ソリューションアーキテクトで、お客様が NoSQL データベースを使用して既存のアプリケーションをモダナイズし、新しいアプリケーションを設計するのを支援しています。AWS に入社する前は、2000 年代初頭からバックエンドシステムの設計と開発を行ってきました。

本ブログは 2026 年 6 月 17 日に公開された AWS Blog “ Introducing AWS Continuum: Security at machine speed ” を翻訳したものです。 AWS が確信していること AWS はエンタープライズセキュリティについて深く考え続けてきました。この 10 年間役立ってきた運用モデル、つまりテレメトリを収集して保存し、クエリを実行し、それらを監視するためのダッシュボードを構築するというアプローチは、もはや時代に追いついていません。AWS は、テレメトリを起点にコンテキストで意味づけし、推論を重ね、アクションへとつなげる新しい世界へ移行する必要があります。それは成果を生み出すアプローチです。最新のサイバーセキュリティ向けフロンティアモデルの登場により、この移行は一層急務となりました。Claude Mythos のようなモデルがソフトウェアの脆弱性を発見し、複雑な攻撃経路をマシンスピードで推論できるようになった結果、脆弱性のバックログが指数関数的に増加しているからです。 コードの脆弱性に対応する AWS Continuum のご紹介 本日 (2026 年 6 月 17 日)、AWS はコードの脆弱性に対応する AWS Continuum を発表します。現在限定プレビューでご利用いただけます。コードの脆弱性に対応する Continuum は、発見からアクションに至るまで、コードの脆弱性のライフサイクル全体にマシンスピードで対応します。お客様の環境を推論し、何が現実の問題なのかを見極め、解決へと導きます。Continuum はモデルに依存しない設計になっており、それぞれが最も得意とする領域で複数のフロンティアモデルを使用します。さらに、より新しく高性能なモデルが登場するたびに取り込めるよう構築されています。 Continuum は、AWS と Amazon.com 全体でセキュリティを運用してきた経験から得た教訓をもとに構築されています。さまざまな業界で事業を展開するビジネスを保護するには、汎用的なルールを一律に適用するのではなく、ビジネスコンテキストを理解するシステムが必要でした。 仕組み コードの脆弱性に対応する Continuum は、お客様の環境全体を推論します。ここで活用するコンテキストには、すでに Amazon Web Service (AWS) 内に存在する構造化データ (インフラストラクチャ、アクセス許可、ネットワークトポロジ、コード) と、組織の運用方法やリスクプロファイルを捉えた非構造化データ (ドキュメント、コミュニケーション、ビジネス上の優先事項) が含まれます。 コードの脆弱性に対応する Continuum は、次の 4 つの継続的なフェーズで動作します。 発見: セキュリティチームは脆弱性のバックログに取り組んでおり、多くのチームがすでにフロンティアモデルを使ってさらに多くの脆弱性を発見しています。Continuum は、まずその既存のバックログを取り込み、お客様の環境に対して独自の脆弱性スキャンを実行します。これにより、脆弱性とそれに関連する攻撃経路をより包括的に把握できます。 優先順位付け: Continuum はコンテキストを活用して、すべての検出結果を評価、強化、優先順位付けします。影響を受けるコンポーネントがデプロイされているか、到達可能か、本番環境の経路上にあるか、エクスプロイトされた場合のビジネスへの影響はどうか、といった観点で確認します。その結果、証拠に裏付けられた優先事項のリストが得られ、Continuum とお客様のチームは最も重要なことに集中できます。 検証: Continuum は検出結果を検証し、チームの時間を浪費する前に誤検出を明らかにします。脆弱性をお客様の環境に照らしてコンテキスト化したうえで、サンドボックス環境で実際に動作するエクスプロイトの例を構築し、問題の具体的で再現可能な証拠を提供します。 緩和と修復: Continuum は、検証済みの問題に対する既存の防御策を評価します。これには、ブロック型および代替コントロールと検出メカニズムが含まれます。次に、コードベース、コンテキスト、検出結果に関する理解に基づいて、ネットワークの変更、ポリシーの変更、またはコードパッチによる脆弱性の緩和または修復を推奨します。パッチの推奨は、脆弱性を確認したのと同じシステムを使って検証されます。また、可能な場合は影響範囲の可視化とロールバック経路も提供します。 これはほんの始まりにすぎません。AWS はコード (ファーストパーティおよびサードパーティ) から着手し、その後セキュリティの他の側面へと拡大していきます。 信頼は段階的に高まる Continuum は、人間が介在する learn モード (学習モード) から始まります。すべての推奨には、その背景にある推論が含まれています。お客様が信頼を高めるにつれて、Continuum を enforce モード (適用モード) へ引き上げることができ、お客様が定義したカテゴリやリスクプロファイルに基づいて、ますます自動化された修復を有効にできます。 Continuum の機能 コードの脆弱性に対応する Continuum に加えて、Continuum にはお客様がすでにご存知かもしれない機能も含まれています。 AWS Security Agent のペネトレーションテストとコードスキャンの機能は、Continuum for penetration testing および Continuum for code scanning (プレビュー) として Continuum の一部になりました。AWS はまた、Continuum for threat modeling もプレビューで提供開始します。これは、設計ドキュメントやソースコードから包括的な脅威モデルを自動生成し、STRIDE 形式で結果を出力する機能です。これらの機能は、発見、優先順位付け、検証、修復という、より広範な Continuum のループに供給される検出および分析のソースとして機能します。 使ってみる AWS は、金融サービス、自動車、テクノロジー業界のお客様と協力して AWS Continuum を形作ってきました。お客様からのフィードバックは、その方向性を裏付けるものでした。セキュリティチームは、信頼を獲得し、アクションを起こせるツールを求めています。 コードの脆弱性に対応する AWS Continuum は、限定プレビューでご利用いただけます。アクセスをリクエストするには、 AWS Continuum でサインアップしてください。 Chet Kapoor Chet は Amazon Web Services の Vice President of Search, Security, and Observability です。エンタープライズテクノロジーの分野で 20 年以上の経験を持ち、API やオープンソースからクラウドや AI に至るまで、業界で最も重要なプラットフォームの転換期において企業を率いてきました。急速な成長、変革、買収、IPO の時期を通じて、ビジネスの構築とスケーリングに携わってきました。Chet は、ビルダーとしての考え方、深い運用経験、そして強い顧客志向を持ち、組織が新しいテクノロジーを安全かつ大規模に導入できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2026 年 05 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Cost Optimization Hub AWS Cost Optimization Hub はコスト最適化の推進に役立つ機能で、組織内の全アカウント・全リージョンのコスト最適化の推奨事項を一元的に集約・表示し、推定削減額を確認できます。本セッションでは、AWS Cost Optimization Hub の概要や利用方法、よくあるご質問についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Cost Optimization Hub の概要・基本的な利⽤⽅法を知りたい⽅ AWS におけるコスト最適化を推進したい⽅ 本 BlackBelt で学習できること AWS におけるコスト最適化の課題と AWS Cost Optimization Hub の役割を理解する AWS Cost Optimization Hub の機能概要と基本的な利用方法を把握する 関連 AWS サービスとの使い分けについて知る スピーカー 西村 美由紀 テクニカルアカウントマネージャー Amazon EKS ネットワーキング Deep Dive シリーズ Amazon EKS を利用するためには、AWS（VPC）と Kubernetes の両方のネットワーク設定および要件を理解する必要があります。 本セミナーでは、EKS クラスターを構成するコントロールプレーンとデータプレーンのネットワーク設定・要件を整理して紹介することで、お客様の要件に適した構成を選択いただけるようになることを目的としています。 また、ネットワーキングアドオン（CoreDNS, kube-proxy, Amazon VPC CNI plugin）の紹介により、クラスター内の名前解決や Kubernetes ネットワークおよび Pod ネットワークの理解を深めることができます。 クラスターネットワーキング編 – 資料（ PDF ）  Kubernetes ネットワーキング編 – 資料（ PDF ） Pod ネットワーキング前編 – 資料（ PDF ） Pod ネットワーキング後編 – 資料（ PDF ）  対象者 Amazon EKS を利用している方、または利用を検討している方​ Amazon EKS のネットワーキングについて学びたい方​ 本 BlackBelt で学習できること Amazon EKS クラスターのネットワーク要件や設計ポイント 各ネットワーキングアドオン（CoreDNS, kube-proxy, Amazon VPC CNI plugin）の役割やアーキテクチャ スピーカー 原 雅貴 クラウドサポートエンジニア Amazon CloudWatch Part1 Observability の基本・メトリクス・アラーム編 Amazon CloudWatch の概要と Observability の基本、メトリクス・アラームについて解説します。これから AWS で監視を始める方向けに、オブザーバビリティの概念から CloudWatch 全体像、メトリクスの仕組み、アラーム設定のベストプラクティスまでを網羅的にご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS で監視・ Observability（可観測性）を始めたい方、Amazon CloudWatch の概要を把握したい方、メトリクスやアラームの基本を学びたい方 本 BlackBelt で学習できること 本セッションでは、オブザーバビリティ（可観測性）の基本概念と、AWS における監視の全体像を学ぶことができます。Amazon CloudWatch の機能一覧を俯瞰した上で、メトリクスの仕組み・ Metric Insights ・ Metric Math といった分析機能、CloudWatch Alarms によるアラーム設定のベストプラクティスや Alarm Recommendations の活用方法を解説します。 スピーカー 津和崎 美希 ソリューションアーキテクト AWS Elemental Media Services を利用した動画配信について（応用編 – 大規模配信イベント対応） AWS Elemental Media Services を利用した動画配信についての「応用編」として、100 万人規模の同時視聴者数を想定した大規模配信イベントを成功させるための設計判断と留意事項をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 基礎編を視聴済みで、AWS Elemental Media Services の基本機能や構成、動画配信全般の基本的な知識を有している方 同時視聴 100 万人規模が想定されるようなミッションクリティカルなライブ動画配信基盤の設計・構築に携わる方 高可用構成、スケール設計、大規模イベント運用の実践的な知識を身に付けたい方 本 BlackBelt で学習できること AWS Elemental Media Services を利用して、100 万人規模の同時視聴者数を想定した大規模配信イベントを成功させるための設計判断と留意事項を学ぶことができます。 スピーカー 石井　悠太 ソリューションアーキテクト NAB Show 2026 recap 世界最大の放送機器展 NAB Show 2026 で AWS が披露した 30 を超えるデモから注目トピックを厳選して解説します。AWS Elemental Inference によるリアルタイム縦動画変換、ハイライト自動抽出、MXL/TAMS によるクラウドネイティブ放送基盤、AWS Elemental MediaConnect Router によるライブ映像のクラウドルーティング、AI エージェントを活用したライブ配信障害の自律診断など、制作/配信/管理/収益化の4領域における最新技術を現地参加メンバーがお伝えします。 資料（ PDF ） | 動画（ YouTube ） 対象者 放送局/動画配信事業者/メディアテクノロジー企業で、クラウド移行や AI 活用による制作ワークフロー効率化を検討されている技術者・企画担当の方を対象としています。AWS のメディア系サービスの基本的な役割を理解されていると、より深くお楽しみいただけます。 本 BlackBelt で学習できること NAB Show 2026 での AWS 最新発表と放送・配信業界のトレンドを短時間で把握できます。AWS Elemental Inference や AWS Elemental MediaConnect Router など新サービスの技術詳細と採用事例、AI エージェントによるライブ障害診断や超低遅延配信といった次世代メディアワークフローの実装アプローチを学べます。 スピーカー 小南 英司 ソリューションアーキテクト Amazon Cognito 基礎編 Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションにユーザー認証、認可、ユーザー管理機能を簡単に追加できる認証サービスです。複雑な認証システムの構築や運用が不要になることから、多くのお客様のアプリケーション開発で採用頂いています。本セッションでは、Amazon Cognito を使用するユースケースや基本的な機能についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 アイデンティティ管理に AWS の利用を検討している方 Amazon Cognito でできることを理解されたい方 Cognito ユーザープールと ID プールの違いや使い方を理解されたい方 本 BlackBelt で学習できること アイデンティティ管理における Amazon Cognito の使い方を学習いただけます Amazon Cognito ユーザープールと ID プールの違いについて理解を深めていただけます Amazon Cognito の機能や認証フローを習得いただけます スピーカー 沼田 裕太郎 クラウドサポートエンジニア Amazon Cognito 実装編 Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションにユーザー認証、認可、ユーザー管理機能を簡単に追加できる認証サービスです。複雑な認証システムの構築や運用が不要になることから、多くのお客様のアプリケーション開発で採用頂いています。本セッションでは、Amazon Cognito ユーザープールの具体的な利用方法やユースケースについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 アイデンティティ管理に Amazon Cognito の利用を検討している方 Amazon Cognito ユーザープールでできることを理解されたい方 本 BlackBelt で学習できること アイデンティティ管理における Amazon Cognito ユーザープールの実践的な使い方を学習いただけます Amazon Cognito ユーザープールの機能や認証フローを習得いただけます スピーカー 谷 祐貴 クラウドサポートエンジニア Amazon Connect AI agents Connect assistant 基礎編 Amazon Connect AI agents は生成 AI を活用したカスタマーサービスアシスタントです。 本セミナーでは、人間のエージェントの対応を強化する コネクトアシスタント機能をご紹介します。) ぜひコンタクトセンターへの導入をご検討ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のお客様、パートナーの方 コンタクトセンター での AI 活用や業務効率化に関心のある方 スピーカー 杉野 喬生 クラウドサポートエンジニア Amazon Connect AI agents self-service 基礎編 Amazon Connect AI agents は生成 AI を活用したカスタマーサービスアシスタントです。 本セミナーでは、顧客からの問い合わせに AI エージェントが自律的に対応するセルフサービス機能をご紹介します。 ぜひコンタクトセンターへの導入をご検討ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 対象者： Amazon Connect ご利用中のお客様、パートナーの方 コンタクトセンター での AI 活用や業務効率化に関心のある方 本 BlackBelt で学習できること Amazon Connect の AI エージェントが自律的に対応するセルフサービス機能を使用したユースケースや機能の概要について スピーカー 中嶋桃香 クラウドサポートエンジニア Amazon Connect Cases Amazon Connect Cases は、顧客の問題を追跡し、エージェント間で協力してすばやく解決するための機能です。 顧客とのやり取りをエージェント間で確認し、必要なタスクの作成やケースの受け渡しができます。 本セミナーでは、コンタクトセンターにおけるケース管理の課題を解決する Cases の機能についてデモを交えて解説します。 https://youtu.be/ytost3jnHFw 資料（ PDF ） | 動画（ YouTube ） 対象者 カスタマーセンターのシステムを検討、実装する方 Amazon Connect を利用しているが、Cases はまだ利用していない方 本 BlackBelt で学習できること Amazon Connect Cases の機能、他の Connect 機能との組み合わせた顧客体験の実現方法 スピーカー 松本　和久 シニアソリューションアーキテクト Amazon Connect Tasks update Amazon Connect Tasks は、コンタクトセンターのエージェントに単一かつ柔軟な UI を提供することで、顧客の問題解決に必要なすべての作業を一つの画面で効率的に処理できる環境を実現します。 本セミナーでは前回 2022 年以降のアップデートと、新機能を活用して部門をまたいだ一貫性のある顧客サポートの実現についてデモを交えて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 カスタマーセンターのシステムを検討、実装する⽅ カスタマーセンターでの効率的なタスク管理を模索している方 Amazon Connect を利用しているが、Tasks はまだ利用していない⽅ 本 BlackBelt で学習できること Amazon Connect Tasks の機能、他の Connect 機能との組み合わせた顧客体験の実現方法 スピーカー 松本　和久 シニアソリューションアーキテクト