2026 年 8 月 21 日、 AWS Glue 6.0 の一般提供について発表しました。これにより、価格が以前の AWS Glue バージョンよりも 30% 低くなり、 Apache Iceberg v3 の機能が完全にサポートされるようになりました。AWS Glue 6.0 は、完全に近代化されたランタイム、Apache Spark 4.1、Python 3.12、および Scala 2.13 に基づいて構築されており、より高速なパフォーマンスを実現しています。 このリリースにより、AWS Glue は、完全にサーバーレスのマネージド型の Spark サービスで最も完全な Iceberg v3 実装を実現するとともに、ETL オーサリングを簡素化し、 PySpark のパフォーマンスを向上させ、1桁ミリ秒のレイテンシーでリアルタイムストリーミングを可能にする新機能も提供します。 AWS Glue 6.0 の新機能は何ですか AWS Glue 6.0 は、Iceberg 1.11.0 をベースに構築された完全なApache Iceberg v3仕様を提供します。主な特長は、シュレッダ処理をサポートする VARIANT データ型です。これにより、半構造化データ用の従来の文字列データ型の列と比較して、クエリの読み取りパフォーマンスが向上します。 VARIANT  のシュレッディングを使用すると、スキーマをフラット化しないで JSON、ログ、イベントデータを保存してクエリできます。これにより、スキーマが変更されたときに重複するデータコピーやカスタム解析コード、パイプラインが破損することがなくなります。この機能により、チームが半構造化データの大規模処理の方法が変わります。 Iceberg v3 のその他の機能には以下が含まれます。 幾何学と地理データタイプ : GIS分析、ロケーションインテリジェンス、および地理空間データパイプラインのネイティブ空間処理をマネージド Spark で直接有効にします。 ナノ秒精度のタイムスタンプ : 標準ミリ秒を超える精度を必要とする IoT センサーデータ、科学計算、および高頻度の金融ワークロードをサポートします。 未知の型処理 : パイプラインに障害が発生することなく、予期しないスキーマや、進化するスキーマを含むデータを処理できるため、上流のスキーマ変更に対する回復力が高まります。 AWS Glue 6.0 には、最新のランタイムエンジンである Spark 4.1 の最も重要なアップグレードも含まれています。 Spark 宣言型パイプライン : Spark 宣言型パイプラインでは、ETLオーサリングへのシンプルなアプローチが導入されています。データエンジニアは変換を宣言してデータをどのように表示するかを指定し、エンジンは実行順序と最適化を自動的に決定します。これにより、パイプライン開発の複雑さが軽減され、手動によるオーケストレーションのオーバーヘッドがなくなります。 アローネイティブ Python UDF と UDTF : AWS Glue 6.0 では、Python ユーザー定義関数 (UDF) とユーザー定義テーブル関数 (UDTF) の Arrow ネイティブ実行が導入されました。これにより、Python と JVM 間のシリアル化のオーバーヘッドがなくなり、複雑な変換での PySpark のパフォーマンスが向上します。 リアルタイムストリーミングモード : AWS Glue 6.0 では、ステートレスストリーミングのユースケース向けに、1桁ミリ秒のレイテンシーを実現するリアルタイムストリーミングモードが導入されています。Glue に最適化された実行機能を備えた Spark 4.1 のリアルタイムモードに基づいて構築されたこの機能は、リアルタイムのイベント処理、低遅延のデータ変換パイプライン、および時間に敏感なデータルーティングをサポートします。 AWS Glue 6.0 の開始方法 AWS Glue 6.0 を使用するのに、API を変更する必要はありません。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS Glue Studio 、 Amazon SageMaker Unified Studio 、および優先する IDE から create-job または update-job API で既存の --glue-version パラメーターを使って、新しいバージョンを選択することができます。 AWS Glue 6.0 ジョブを AWS Glue Studio コンソール で開始するには、[AWS Glueジョブ] を開き、 ジョブ詳細 タブで、バージョン Glue 6.0 – Spark 4.1、Scala 2、Python 3 をサポート を選択します。AWS Glue 6.0で新しい AWS Glue ジョブを作成することで、改善によるメリットを受けること、および既存の AWS Glue ジョブを移行することもできます。 AWS Glue 6.0 を AWS Glue Studio ノートブックで使用したり、Jupyter Notebook を介してインタラクティブセッションを開始したりするには、 %glue_version マジックで 6.0 を設定してください。 また、AWS Glue Studio の Spark アップグレードエージェント を使用して既存のジョブを Glue 6.0 にアップグレードしたり、既存の Glue ジョブの自動アップグレード機能を使用して自動的に Glue 6.0 にアップグレードしたりすることもできます。 詳細については、AWS ドキュメントの 「AWS Glue 6.0 バージョンの詳細」 および 「AWS Glue for Spark ジョブの AWS Glue バージョン 6.0 への移行」 を参照してください。 今すぐご利用いただけます AWS Glue 6.0 は現在、AWS Glue が運用されているすべての AWS リージョンで一般的に利用可能です。リージョンごとの提供状況や今後のロードマップについては、 リージョン別の AWS 提供機能 にアクセスしてください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 クローラー (データの検出) と抽出、変換、ロード (ETL) ジョブ (データの処理と読み込み) には、時間単位の料金を秒単位で請求します。AWS Glue データカタログの場合は、メタデータの保存とアクセスにシンプルな月額料金を支払う必要があります。最初の 100 万個のオブジェクトは無料で、最初の 100 万個のアクセスは無料です。詳細については、 AWS Glue 料金表ページ をご覧ください。 AWS Glue Studio コンソール でお試しいただいた後、 AWS re:Post for AWS Glue または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

はじめに CIU (CyberAgent group Infrastructure Unit) の ...

はじめに 2026年6月25日（木）・26日（金）の2日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されました。 AWS Expo エリア内の AWS Industries Zone では、流通小売・消費財・飲食業界向けブースとして「AI エージェントが業務の主役になる日」をテーマに6つのデモと2社のお客様事例を展示しました（ 事前告知ブログ ）。本ブログでは、そのうちサプライチェーン領域の展示「AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決」にフォーカスし、デモの技術的な仕組み、来場いただいたお客様の反応、そして「今日から始められる」次のステップをご紹介します。 デモで展示した内容 デモのコンセプト 台風による広域配送停止、ドライバー不足、SNS でのバイラル化による需要急増、そして石油由来製品の調達難。サプライチェーンの現場では、いつ「想定外」が起きてもおかしくありません。商品そのものだけでなく包装資材やプラスチック容器など、石油由来の原材料に依存する消費財メーカーにとって、調達コストの急変動は今まさにリアルな脅威です。従来、こうした外乱への対応は担当者の経験に依存し、検知から実行まで数時間〜数日を要していました。 本デモでは、「AI エージェントが外乱を検知し、影響を分析し、代替案を探索・提示し、人間が承認したうえで実行と通知までを一気通貫で行う」この一連のオペレーションを、ライブで実演しました。お客様の業種に合わせて、小売シナリオ（店舗の在庫不足に対する最適な振替ルートの提案）と消費財シナリオ（原材料供給停止時の代替サプライヤー探索）の2パターンをご覧いただきました。 図1: デモ画面。上部: AI エージェントの提案に対し、人間が承認・拒否を実施した結果、判断によって守ることができた売り上げ高と回避された遅延違約金を表示。下部: AI が作成した先方へのメールや発注書のドラフトなどを表示 システム構成 図2: サプライチェーン危機対応デモのシステム構成図 本デモのアーキテクチャは以下の要素で構成されています。 レイヤー サービス / コンポーネント 役割 フロントエンド Amazon S3 + Amazon CloudFront + AWS WAF + Amazon Cognito ユーザー認証とWebアプリ配信 リアルタイム通信 AWS AppSync Events AI の思考プロセス (Chain of Thought) やツールの呼び出しをリアルタイムにストリーミング可視化 エージェント基盤 Amazon Bedrock AgentCore Runtime + Strands Agents SDK マルチエージェントのオーケストレーションと実行 データアクセス MCP サーバー（各シナリオごとに6つ、計12種類のツール） 遅延出荷取得、在庫インパクト計算、財務インパクト計算、転送オーダー作成など データストア Amazon Aurora DSQL サプライチェーンデータの格納（在庫、出荷、サプライヤー、BOM等） 安全性 Amazon Bedrock Guardrails エージェントの出力に対するガードレール適用 セッション管理 Amazon S3 Human-in-the-Loop の承認状態を保持 全体の流れはシンプルです。ユーザーはフロントエンドから指示を出し、その指示をエージェント基盤上のマルチエージェントが受け取ります。各エージェントは MCP サーバーを介して Amazon Aurora DSQL 上のサプライチェーンデータ（在庫・出荷・サプライヤー・BOM など）にアクセスし、分析や提案を行います。そして、エージェントの出力には Amazon Bedrock Guardrails を適用し、安全性を最優先に担保しています。 このアーキテクチャで特に工夫したポイントが2つあります。 工夫ポイント① 人間による承認の必須化（Human-in-the-Loop） 本デモでは、AI エージェントがどれだけ優れた分析や提案を行っても、人間の明示的な承認なしには転送オーダーやワークオーダーの発行といった実行系のアクションを一切実行できない設計としています。これは「AI が勝手に発注してしまう」「意図しない振替が走る」といった現場の懸念に正面から応えるものです。 技術的には、Strands Agents SDK の Interrupt 機能を活用しています。Supervisor Agent が実行サブエージェントを呼び出す直前で Hook がセッションを一時停止（Interrupt）し、フロントエンドに承認リクエストを送信します。ユーザーが承認すればセッションを再開して実行サブエージェントを呼び出し、却下すればその呼び出しはスキップされ、対象の発注や振替アクションは実行されません。会話コンテキストは Amazon S3 上のセッションマネージャーに永続化されるため、中断・再開が可能です。なお、Supervisor Agent のプロンプトには「実行エージェントを必ず呼び出し、”pending approval” と書いてスキップすることは禁止」と明記し、AI がこの承認フローをバイパスしないよう制御しています。 工夫ポイント② 思考プロセスの可視化（Chain of Thought） AWS AppSync Events による WebSocket 通信では、今どのステップを実行中か、何を分析しているかといった AI エージェントの思考プロセスをリアルタイムにフロントエンドへストリーミングし、可視化しています。デモではこの思考プロセスのログをリアルタイムに表示することで、承認を求められた際に「なぜこの提案に至ったか」の根拠が見える状態を作り、来場者の皆さまにも納得感を持ってデモの流れを追っていただくことができました。 マルチエージェント設計 本デモでは、1つの Supervisor Agent（サプライチェーン管理エージェント）が全体のオーケストレーションを担い、4つのサブエージェントに作業を委譲する構成を採っています。 Retail シナリオ: 在庫移動分析サブエージェント — 振替元候補の探索と実現可能性の評価（分析のみ） 転送オーダー実行サブエージェント — 承認された振替の実行（実行のみ） CPG シナリオ: 代替サプライヤー探索サブエージェント — リードタイムが最短の代替を優先的に探索（分析のみ） ワークオーダー実行サブエージェント — 承認された発注の実行（実行のみ） 「分析」と「実行」を明確に分離している点がポイントです。分析エージェントは実行すべきアクション（推奨案）を生成するだけで、実際のオーダー作成は行いません。実行エージェントは、分析エージェントが提案したアクションを忠実に実行します。この分離により、Human-in-the-Loop の承認ステップを自然に挟み込むことができます。 プロンプト設計 本デモで最も多くご質問いただいたのが「AI にどうやって業界固有の制約を守らせているのか」という点です。答えは、判断ロジックをコードではなくプロンプトとデータで定義していることにあります。 ワークフローの明示的な定義 Supervisor Agent のプロンプトには、7つのステップが明確に定義されています: ステップ1: 遅延出荷の取得 ステップ2: 在庫インパクト計算 & プロモーションデータ取得（並列実行） ステップ3: 在庫移動オプション評価（並列実行） ステップ4: 財務インパクト計算（並列実行） ステップ5: 転送オーダー実行（並列実行） ステップ6: 通知生成（メール + チャット） ステップ7: サマリー 各ステップで呼び出すツール、入出力のフォーマット、並列実行のルールが具体的に記述されています。 並列実行の指示 パフォーマンスを最大化するため、独立したツール呼び出しを同一ターンで並列実行するよう明示的に指示しています: ## CRITICAL PERFORMANCE RULE — PARALLEL TOOL CALLS You MUST call independent tools in the SAME response turn so they execute concurrently. - Steps 2 and 3 are independent — call retail_calculate_inventory_impact AND get_promotion_data for ALL shipments in ONE turn. これは「互いに依存しないツールは、同じ応答ターン内でまとめて呼び出して並列実行せよ」という指示です。例に挙がっている在庫インパクト計算（retail_calculate_inventory_impact）とプロモーションデータ取得（get_promotion_data）のように、独立した処理を1度のターンで同時に走らせることで、逐次実行に比べて待ち時間を短縮しています。 業界固有制約のプロンプト化 小売・消費財業界でよくある制約条件を、プロンプト内のルールとして記述しています: コールドチェーン対応 — 温度区分（常温/冷蔵/冷凍）に合わない輸送候補を除外 賞味期限管理 — 賞味期限に対し、リードタイムが短すぎる候補を除外 コスト閾値警告 — 代替サプライヤーのコストが20%以上高い場合に警告フラグを付与 使用期限チェック — 在庫の使用期限が30日以内の場合は新規調達を優先 これらはすべてプロンプト上のルール記述とデータベースのカラムの組み合わせで実現しており、ハードコーディングは行っていません。つまり、開発者でなくても業務担当者が自然言語のプロンプトを通してルールを記述し、改善していくことが可能です。 デモを通してお客様にお伝えしたこと 既存システムへの外付けアプローチ AI を業務に取り入れるには、既存システムの大がかりな刷新が必要だと思われがちです。しかし本デモでお見せしたのは、既存の資産を活かすアプローチでした。既存のデータ（在庫・出荷・サプライヤー情報）をそのまま活用し、MCP サーバー経由でエージェントに接続するだけで、AI がシミュレーションを実行できます。既存のシステムを置き換える必要はなく、AI による分析の仕組みを「外付け」できることがこのアーキテクチャの強みです。 段階的に上げられる自動化レベル 本デモでは「AI エージェントによる自動化レベル」を5段階で定義し、レベル 1〜3 を実演しました: レベル AI に任せること 概要 1 シミュレーション データ読み取り・分析のみ。BCP訓練に活用 2 アクションプラン作成 通知・発注書を自動生成。人間が確認して実行 3 承認付き自動実行 AI が提案→人間が承認→実行。財務インパクト事前表示 4 ルールベース自動実行 ポリシー（金額閾値等）で自動承認 5 学習型自動実行 過去の承認パターンを学習し自動判断 ただし、レベル 5 が必ずしもゴールではありません。業務特性やリスク許容度に応じて最適なレベルを柔軟に選べるのがこの設計の強みで、「まずは レベル 1 のシミュレーションから始める」というのが、私たちがこのブースでのデモを通してお伝えしたかったことです。レベル 1 は既存データを AI に与えて業務影響を分析するだけなので、実業務のプロセスを変更せずに今日からでも始められます。「もし明日、台風で広域配送が5日間停止したら？」といった問いを既存データに投げかけ、避難訓練のように繰り返すことで対応プロセスの練度を上げ、効果を実感してから次のレベルに進めば良いのです。 来場いただいたお客様の反応 2日間のブース展示を通じて、多くのお客様と対話させていただきました。展示員の振り返りからいくつかの共通テーマが浮かび上がりました。 BCP 訓練という普遍的な課題 「サプライチェーンの混乱を、AI と人が即座に解決する」がこのブースのメッセージですが、いざという時に即応するには日頃の備えが欠かせず、本デモではその備えをシミュレーションから小さく始められることをお見せしました。ブースを訪れたお客様のほぼ全員が、その備えとなる危機管理や BCP 訓練を「やりたいがリソースや手段がなくてできていない」とおっしゃっていました。大雪や台風など実際に困っている企業様からは「これまで担当者が各所に何本も電話をかけて対応していた。AI が初動を担ってくれるだけでもありがたい」という声をいただきました。危機対応は業種や規模を問わず共通の悩みであり、既存の業務を止めずに試せる手軽さへの共感とともに、AI エージェントへの期待の高さを肌で感じました。 AI エージェント活用の具体的なイメージ 「AI エージェント」という言葉は浸透しつつある一方、具体的に何ができるのか、自社ではどう使えるのかをイメージできていないお客様が多くいらっしゃいました。エージェントの思考プロセスを可視化し、Human-in-the-Loop で人間が介在するポイントを示したことで、「具体的なイメージが湧いた」「エージェントの処理を見て初めて理解できた」というフィードバックを多くいただきました。 データ整備の課題への気づき 興味深いことに、本デモをきっかけに「自社には AI に渡せる整理されたデータがない」と気づかれるお客様が少なくありませんでした。データが正規化されていない、必要な情報が構造化されたDBに入っていない、といった課題です。しかし実際には、フォーマットの異なる Excel ファイルが散在しているような状態でも、AI は人間が思う以上にデータを理解・整理し、人が気づきにくいインサイトまで引き出してくれます。完璧なデータ基盤が整うのを待つ必要はなく、まずは今あるデータから始めて AI と壁打ちしながら、ワークロードの成長と並行して育てていけばよい。この考え方に共感いただけたケースも多くありました。 AgentCore のモジュラー性への評価 Amazon Bedrock AgentCore 自体をまだ触ったことがないお客様が大半でしたが、機能がモジュラーな部品として提供されている点に好意的な反応をいただきました。たとえば、さまざまな認証・認可を統合管理してくれる Amazon Bedrock AgentCore Identity や、エージェントに短期・長期の記憶を持たせる Amazon Bedrock AgentCore Memory といった部品です。特に、既存の REST API や Lambda 関数をマネージドで MCP 化してくれる Amazon Bedrock AgentCore Gateway には「すばらしい」という声が上がりました。すぐに使いたい、アセットはあるか、という質問も複数いただき、そうしたお客様には後述のハンズオンワークショップをご案内しました。 導入コストへの反応 「一回のシミュレーションでどのくらいコストがかかるのか」という質問に対しては、本デモの構成では1回あたり数百円程度でシミュレーションを実行できることをお伝えすると、想像より安いと好意的に受け止められました。 Amazon Bedrock や Amazon Bedrock AgentCore の従量課金モデルなら固定費用や初期投資なしで始められる点も、大きな安心材料になるとの反応をいただきました。「使っていない間も費用が発生するのではないか」という懸念に対しても、サーバーレスで使った分だけの課金となり、待機コストを気にせず導入できる点をご評価いただきました。コストのハードルが低いことは、まず小さく試して効果を確かめたいというニーズにも合致します。 リアルタイムなデータ連携の重要性 有事の際には代替先に各社から注文が集中するため、AI が判断に使う情報にリアルタイムでアクセスできることが重要だという、現場ならではの指摘もいただきました。だからこそ、AI が MCP サーバー経由でリアルタイムにデータを取得し、瞬時に選択肢を提示できることに価値があります。人間だけで動くよりも早く初動を打てることこそが、AI エージェントを危機対応に活用する最大のメリットです。 — これらのご意見を通じて改めて感じたのは、サプライチェーンの領域は個社ごとに商流・物流の構造や制約が異なり、画一的なソリューションでは対応しきれない複雑さがあるということです。自社の業務に合ったエージェントの在り方を見極めるには、実際に手を動かして仕組みを理解することが近道です。次のセクションでは、本デモと同じシナリオを題材にしたハンズオンワークショップをご紹介します。 おすすめのはじめ方 ハンズオンワークショップ 本デモとよく似たサプライチェーンのシナリオを題材に、Amazon Bedrock AgentCore を段階的に学べるハンズオンワークショップ「 Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 」を公開しています。Jupyter ノートブック形式で、約65分で実施できます。 ワークショップでは、Strands Agents SDK を使ったカスタムツールの作成から始まり、それらのツールを AgentCore Gateway にデプロイして複数エージェント間で共有する方法、MCP サーバーを介したデータベース接続、AgentCore Runtime への本番エージェントのデプロイ、そして React フロントエンドとの統合までを一通り体験できます。プロトタイプとして手元で動かしたエージェントを、システムの残りの部分を変更せずに本番グレードの基盤へ移行する流れを掴むことができます。 マネージドサービス Amazon Connect Decisions 「自社でエージェントを一から構築するのではなく、すぐに使えるサプライチェーン計画ソリューションが欲しい」というお客様には、 Amazon Connect Decisions をご紹介します。Amazon Connect Decisions は、次世代のサプライチェーン計画・インテリジェンスソリューションです。需要予測、供給計画、異常検知といった領域で AI チームメイト（AI エージェント）がチームの一員として稼働し、需要シグナルの統合からコンセンサス予測の生成、業務制約を考慮した供給計画の立案、オペレーションの継続的な監視と問題解決までを支援します。自社の業務手順やルールに適応し、担当者の判断から学習して継続的に改善していくため、導入初日から実用的な推奨を得られる点が特長です。 おわりに AWS Summit Japan 2026 の会場でお話しさせていただいた皆さま、ありがとうございました。2日間を通じて強く感じたのは、サプライチェーンの危機対応は「やりたいけれど手が付けられていない」普遍的なテーマであり、AI エージェントがその最初の一歩を後押しできるということです。ご来場いただけなかった皆さまも、本ブログでご紹介したワークショップや資料をぜひお試しください。ご質問やワークショップ、本デモに関するご相談がありましたら、ぜひ AWS の担当者までお気軽にご相談ください。皆さまの現場で AI エージェントが動き始めることを楽しみにしています。 参考リンク AWS Summit Japan 2026 事前告知ブログ — 流通小売・消費財・飲食業界向けブースのご案内 ハンズオンワークショップ — Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 Amazon Bedrock AgentCore Amazon Connect Decisions 著者 吉田 英史 は、東海地方を中心に小売・消費財業界のお客様を支援しているアマゾンウェブサービスのソリューションアーキテクトです。身の回りの生活に欠かせない様々なビジネスをクラウドで加速するお手伝いができることを、何より嬉しく感じています。