本ブログは ミツイワ株式会社 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 企業の DX 推進が加速する中、IT インフラの迅速な構築と安定運用は、ビジネスの成否を左右する重要な要素となっています。特に、新しいアプリケーションやサービスを導入する際、実行基盤の準備に時間がかかり、サービス開始までのリードタイムが長期化することは、多くの企業が直面する課題です。 従来のインフラ構築では、顧客からの問い合わせ内容の整理、要件定義、環境設計、構築作業、そして運用設定まで、多くの工程で人手を介する必要がありました。その結果、担当エンジニアの負担が大きく、品質のばらつきや属人化といった問題も発生していました。また、最新の IT サービスを導入するためには専門領域外の高度な学習が必要となり、技術の習得コストも課題となっていました。 今回ご紹介するのは、ミツイワ株式会社様が、Amazon Bedrockと AWS CloudFormation を活用して、インフラ構築プロセスを一気通貫で自動化した先進的な事例です。 ミツイワ株式会社様の状況と課題 ミツイワ株式会社様は、ICT サービス事業を核に、企業の情報システム導入から運用、さらには最先端の DX 推進まで、ICT ライフサイクル全体をサポートするワンストップソリューションを提供されています。マネージドサービスを通じて多くの企業の IT インフラを支えてきた同社ですが、急速な IT 技術の進化に伴い、以下のような課題に直面していました： リードタイムの長期化 顧客からの問い合わせが未整理のまま届き、内容確認と要件整理に多くの時間を要していた 業務課題を解決するために新たなアプリケーションを導入しようとしても、実行基盤の準備に時間がかかり、実際のサービス開始まで長期間を要していた 顧客ごとに異なる環境を手作業で構築するため、リードタイムの長期化と品質のばらつきが発生していた 品質維持と運用負荷 クラウド環境の構築依頼から完了まで、担当エンジニアの負担が大きく、本来注力すべき業務改善に時間が割けない状況であった 導入したアプリケーションや実行基盤の品質維持に多くの工数が割かれていた 運用設計の標準化が不十分で、属人化のリスクがあった 学習コストと属人化 最新の IT サービスを導入するために、専門領域外の高度な学習が必要となり、技術習得に時間がかかっていた 技術が属人化しやすく、担当者の異動や退職時に業務の継続性に懸念があった ミツイワ様はこれらの課題を解決するため、自社のマネージドサービスを進化させ、顧客の価値向上に繋げるべく、生成 AI と IaC を活用した次世代インフラ自動構築ソリューションの開発に至りました。 ソリューション ミツイワ株式会社様は、AWS の生成 AI サービスとマネージドサービスを最大限活用し、以下のようなアーキテクチャを構築しました： Amazon Bedrock による解析の自動化 顧客からの問い合わせ内容を Amazon Bedrock が自動で解析し、要件を構造化 解析結果に基づいて、最適な AWS CloudFormation テンプレートを自動選定 生成 AI の自然言語処理能力により、未整理の問い合わせでも適切に解釈し、必要な AWS リソースを特定 AWS CloudFormation によるコード管理 AWS のリソース構築や運用設計をあらかじめテンプレート化し、高い再現性と品質を確保 AWS CloudFormation により、インフラのプロビジョニングと設定を自動化し、手作業によるミスを排除 テンプレートのバージョン管理により、環境の変更履歴を追跡可能にし、必要に応じてロールバックを実現 サーバーレスな高速構成 AWS Lambda のサブプロセスで MCP サーバーを起動し、高速かつサーバーレスな構成を実現 ジョブ型非同期処理により、利用者が処理状況を追跡可能となり、ユーザーエクスペリエンスが向上 サーバー管理が不要なサーバーレスアーキテクチャにより、運用負荷を最小化 一気通貫の自動化フロー 本ソリューションは、以下のような一連のプロセスを人手を介さずに自動化します： 1. 問い合わせ受付: 顧客からの問い合わせを受付 2. 要件解析: Amazon Bedrock が問い合わせ内容を解析し、必要な AWS リソースを特定 3. テンプレート選定: 解析結果に基づき、最適な AWS CloudFormation テンプレートを自動選定 4. 環境構築: AWS CloudFormation により AWS 環境を自動構築 5. 初期設定: 運用に必要な初期設定を自動適用 6. 完了通知: 構築完了を利用者に通知 この自動化により、従来は数日から数週間かかっていたプロセスを、大幅に短縮することが可能になりました。 導入効果 AWS の生成 AI と IaC を活用した次世代インフラ自動構築ソリューションの導入により、以下の効果が得られました： リードタイムの大幅短縮 問い合わせの受付から基盤の準備、初期設定までを標準化・自動化し、サービスインまでの期間を大幅に短縮 AWS のサービスを使うことで短期間で依頼内容の整理から環境構築まで自動化され、ビジネスの俊敏性が向上 業務時間の再配分 構築・運用の自動化により、余剰となった時間を業務改善や新たな価値創出へ再配分することが可能に エンジニアが本来注力すべき業務に集中できるようになり、顧客への提供価値が向上 安定稼働と継続性の向上 運用設計をテンプレート化したことで学習コストと属人性を抑制 サポートセンターによる運用と合わせて、システムの安定稼働と継続運用性を向上 AWS CloudFormation によるコード管理により、環境の再現性が格段に向上し、品質のばらつきを解消 ユーザーエクスペリエンスの向上 ジョブ型非同期処理により、利用者が処理状況を追跡可能となり、透明性が向上 自動化により、迅速かつ正確なサービス提供が可能になり、顧客満足度が向上 お客様の声 Amazon Bedrock と AWS CloudFormation を組み合わせることで、インフラ構築の全自動化を実現できました。特に、AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成は、高速かつ運用負荷の少ないアーキテクチャを実現する上で非常に効果的でした。問い合わせ解析から AWS 環境構築までを一気通貫で自動化したことで、エンジニアの工数を大幅に削減し、本来注力すべき業務に集中できるようになりました。また、AWS CloudFormation によるテンプレート管理により、環境の再現性と品質が向上し、属人化のリスクも軽減されました。 今後の展望 ミツイワ株式会社様は今後、以下の取り組みを通じて、さらなる顧客価値の最大化を目指しています： ITSM 連携の強化 利用申請からサービスの提供、その後の設定変更の管理やインシデント管理に至るまで、自動化の範囲を拡大 IT サービスマネジメント（ITSM）ツールとの連携により、エンドツーエンドの自動化を実現 マルチアカウント展開 複数の AWS アカウントにまたがる環境構築を自動化し、大規模な組織での展開を支援 AWS Organizations と連携した、ガバナンスとセキュリティを考慮した自動構築を実現 継続的な改善 生成 AI の進化に合わせて、解析精度と自動化の範囲を継続的に拡大 顧客からのフィードバックを基に、テンプレートの拡充とプロセスの最適化を推進 まとめ 本事例は、Amazon Bedrock と AWS CloudFormation を組み合わせることで、インフラ構築プロセスの全自動化を実現した先進的な取り組みです。生成 AI による問い合わせ解析と、IaC による環境構築の自動化により、リードタイムの大幅短縮、品質の向上、そして属人化の解消を同時に達成しました。特に注目すべきは、AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成により、高速かつ運用負荷の少ないアーキテクチャを実現している点です。本事例が、インフラ構築の自動化や生成 AI の活用をご検討中のお客様の参考になれば幸いです。 ミツイワ株式会社（左から）： AWS技術監修：福園　智憲様 ソフトウェア開発担当：芳我 俊祐様 AWSインフラ担当：浅羽　瞬様（パーソル＆サーバーワークス株式会社よりプロジェクト参画） Amazon Web Services Japan 合同会社： アカウントマネージャー 植木 輝（右端） ソリューションアーキテクト 森 瞭輔（左端）

本記事は 2026 年 2 月 26 日 に公開された「 Improving order history search using semantic search with Amazon OpenSearch Service 」を翻訳したものです。 Amazon で買い物をしたことがあれば、 注文履歴 を使ったことがあるでしょう。この機能は 1995 年まで遡る注文履歴を保持しており、すべての購入を追跡・管理できます。注文履歴の検索機能では、検索バーにキーワードを入力して過去の購入品を見つけられます。商品を見つけるだけでなく、同じ商品や類似商品を簡単に再購入でき、時間と手間を節約できます。 Rufus や Alexa など、Amazon のショッピング体験を支えるさまざまな機能が注文履歴検索を活用し、過去の購入品を見つける手助けをしています。そのため、注文履歴検索には過去の購入品をできるだけ正確かつ迅速に見つける能力が求められます。 本記事では、Your Orders チームが Amazon OpenSearch Service と Amazon SageMaker を使い、既存のレキシカル検索システムにセマンティック検索機能を導入して注文履歴検索を改善した方法を紹介します。 レキシカル検索の限界 注文履歴検索では、 レキシカルマッチング を使って、検索キーワードの少なくとも 1 つの単語に一致する商品を顧客の注文履歴全体から取得しています。たとえば「orange juice」と検索すると、オレンジジュースだけでなく、過去に注文した生のオレンジや他のフルーツジュースも取得されます。レキシカルマッチングは検索キーワードに正確に一致する商品の 再現率 は高いものの、この例の「health drinks」のような関連キーワードや汎用的なキーワードではうまく機能しません。 Amazon の AI ショッピングアシスタント Rufus の登場以来、効率的で充実したショッピング体験を求める顧客が増え、Rufus で過去の購入品を検索するケースも増えています。「Show me healthy drinks」のように、「kombucha」「green tea」「protein shakes」といった長く正確な用語を気にせず検索できるようになりました。検索体験が会話的で意図ベースになり、商品をより直感的に見つけられるようになっています。Rufus が「Show me the healthy drinks I bought last year」のような注文履歴検索に同じ直感的な体験で応えるには、基盤となる注文履歴データストア (Your Orders) に、従来のレキシカルマッチングを超えて検索キーワードの意味を理解する セマンティック検索 機能が必要です。 セマンティック検索の実装における課題 この規模でセマンティック検索を実装するにあたり、次の技術的課題がありました。 スケール – 世界中の顧客の注文履歴に対応する数十億件のレコードでセマンティック検索を有効にする必要がありました。 ゼロダウンタイム – バックエンドでセマンティック検索を導入する変更を行う間も、システムの可用性を 100% 維持する必要がありました。 検索品質の低下防止 – セマンティック検索は検索品質の向上が目的ですが、逆効果になるケースもあります。たとえば、顧客が商品名を正確に覚えていてその名前に一致する商品だけを見つけたい場合、類似商品も表示すると結果が混雑し、目的の商品を見つけにくくなります。同様に、注文 ID のように固有の意味を持たない識別子で検索する場合、セマンティック検索は機能しません。このようなシナリオではレキシカル検索のみを使用します。 ソリューション概要 セマンティック検索は 大規模言語モデル (LLM) を基盤としています。LLM は主に人間の言語で学習されており、学習済みの言語のテキストを受け取り、入力テキストの長さに関係なく固定長のエンベディングベクトルを出力するように適応できます。エンベディングベクトルは入力テキストの意味を捉えるよう設計されており、意味的に類似した 2 つのテキストは、それぞれのエンベディングベクトルの コサイン類似度 が高くなります。注文履歴のセマンティック検索では、エンベディング生成と類似度計算の対象となる入力テキストは、顧客の検索フレーズと購入済み商品の商品テキストです。 ソリューションは 2 つのパートに分かれます。 大規模リクエスト処理に向けたスケーラビリティとレジリエンシーの向上 – セマンティック検索を実装する前に、増加する計算負荷に対応できるインフラストラクチャを確保する必要があり、 セルベースアーキテクチャ を採用しました。すべてのユースケースで必要ではありませんが、リクエスト量やデータ量が非常に大きいシステムでは、セマンティック検索のようなリソース集約型機能の実装前に大きな効果を発揮します。 セマンティック検索の実装 – まず利用可能なエンベディングモデルを評価し、 Amazon Bedrock のオフライン評価機能でさまざまなモデルをテストしました。モデルを選定した後、エンベディングベクトル生成のインフラストラクチャを構築しました。 システムのスケーラビリティとレジリエンシーの向上 スケーラビリティとレジリエンシーの向上には、 セルベースアーキテクチャ の設計パターンを採用しました。セルベースの設計では、システムを同一の小さな自己完結型のチャンク (セル) に分割し、各セルがシステム全体のトラフィックの一部のみを処理します。次の図は、注文履歴検索のセルベース設計の概要を示しています。 各セルは定義された顧客のサブセットを担当します。セル間で顧客リクエストを処理するための通信は不要です。各顧客はセルに割り当てられ、その顧客からのリクエストはすべて該当セルにルーティングされます。各セルの OpenSearch Service ドメインは、担当する顧客のサブセットのデータのみを保持します。セル数 (N) とセル間のデータ分散はビジネスユースケースに依存しますが、データとトラフィックをできるだけ均等に分散させることが目標です。 ルーティングロジックはユースケースに応じてシンプルにも高度にもできます。セル割り当て値はリクエストごとにランタイムで計算するか、一度計算して Amazon DynamoDB などのキャッシュや永続データストアに書き込み、以降のリクエストで参照する方法があります。注文履歴検索では、ロジックがシンプルで高速だったため、リクエストごとにランタイムで実行しました。永続データストアからセル割り当てを参照する方法は、一部のセルが時間とともに「重く」なるリスクがある場合に特に有効です。その場合、パーティショニングロジックを変更する代わりに、データストア内の特定キーのセル割り当て値を上書きするだけで、重いセルのデータを再分散できます。パーティショニングロジックの変更はすべてのセルのデータ分散に影響する可能性があります。 システムの負荷が増加した場合、セル数を増やして追加トラフィックに対応できます。セル数を増やさなくても、負荷の高いセルから軽いセルにキーを再割り当てすることで、既存の N セル間でデータを再分散し、負荷をより均等に分散させてインフラストラクチャをより効率的に活用できます。 セルベースアーキテクチャはシステムのレジリエンシー向上にも役立ちます。たとえば、1 つのセルが失われた場合、キャパシティの低下は 100% ではなく 1/N にとどまります。さらに、パーティショニングキーを 2 つ以上のセルに割り当てて複数のセルに書き込むことで、キャパシティ低下をさらに抑えられます。この場合、単一セルの喪失がデータ損失につながることはありません。 セマンティック検索の実装 注文履歴検索にセマンティック検索を実装するには、いくつかの重要な判断と技術的ステップが必要でした。まず利用可能なエンベディングモデルを評価し、Amazon Bedrock のオフライン評価機能でさまざまなモデルをビジネスドメインの要件に照らしてテストしました。この評価でユースケースに最適なモデルを特定し、選定後にエンベディングベクトル生成のインフラストラクチャを構築しました。エンベディングモデルをコンテナ化して Amazon Elastic Container Registry (Amazon ECR) に登録し、SageMaker 推論エンドポイントにデプロイして大規模なベクトル計算を処理しました。 検索インフラストラクチャには、セマンティック検索機能の実装に OpenSearch Service を選択しました。OpenSearch Service は、必要なベクトルストレージと、ユーザーに関連性の高い結果を提供する検索アルゴリズムの両方を備えていました。 最大の課題の 1 つは、既存の注文でセマンティック検索をサポートするために過去のデータを更新することでした。 AWS Step Functions でワークフローをオーケストレーションし、 AWS Lambda 関数でレガシーデータのベクトル生成を処理するデータ処理パイプラインを構築し、対象のすべてのレコードでセマンティック検索を提供できるようにしました。 次の図は、アーキテクチャの概要を示しています。 モデルの評価と選定 注文履歴検索では、Amazon 固有のデータで学習されたエンベディングモデルを使用しています。ドメイン固有の学習は、生成されるエンベディングベクトルがビジネスコンテキストで適切に機能し、質の高い結果を返すために不可欠です。 候補モデルの評価には、Amazon Bedrock 上の Anthropic Claude を使った LLM-as-a-judge 手法を採用しました。Anthropic Claude に、顧客の注文履歴から匿名化された商品テキストと検索フレーズを含むプロンプトを与え、関連性に基づいて商品をフィルタリングおよびランク付けしました。この結果を比較用のグラウンドトゥルースとして使用しました。 モデルの評価には標準的なランキング指標を使用しました。 Normalized Discounted Cumulative Gain (NDCG) – 理想的な順序に対するランキング品質を測定 Mean Reciprocal Rank (MRR) – 最初の関連アイテムの位置を考慮 Precision – 取得結果の精度を評価 Recall – すべての関連アイテムを取得する能力を評価 このプロセスにより最適なモデルを決定しました。 検索戦略: 顧客スコープの包括的検索 注文履歴検索には 2 つの重要な要件があります。 リクエスト元の顧客の注文履歴のみを検索する – ある顧客の注文履歴の商品が別の顧客の検索結果に表示されてはなりません。 その顧客の履歴をすべて検索する – 検索アルゴリズムが何らかの理由で評価しなかったために、顧客の検索フレーズに関連する商品が表示されないことがあってはなりません。 このアプローチでは、OpenSearch Service を使って検索クエリを発行した顧客のすべての商品を取得し、検索フレーズに対する各商品の関連性スコアを計算し、スコア順にソートして上位 K 件の結果を返します。各顧客に対して包括的な結果カバレッジを提供します。 OpenSearch Service によるベクトルストレージ 効率的なベクトルストレージと検索のために、OpenSearch Service の 2 つの機能を使用しました。 knn_vector データ型 – エンベディングベクトルを格納するための組み込みサポート。既存のドメインでもインデックスの再作成なしにこのフィールド型を追加でき、すべてのレコードに対する正確な kNN 検索が可能です。ほとんどの顧客のレコード数は正確な kNN でスケールできる範囲だったため、近似 kNN は不要でした。 スクリプトスコアリング – Painless スクリプトがサーバーサイドでベクトル類似度を計算し、クライアントの複雑さを軽減しつつ低レイテンシーを維持します。 ハイブリッド検索 ハイブリッド検索とは、レキシカル検索とセマンティック検索の結果を組み合わせ、それぞれの強みを活かすことです。OpenSearch Service のハイブリッドクエリ機能により、クライアントは単一のリクエストで両方のクエリタイプを指定でき、ハイブリッド検索の実装が簡素化されます。OpenSearch Service は両方のクエリを並列実行し、結果をマージし、サブクエリの関連性スコアを正規化し、指定されたソート順 (デフォルトは関連性スコア) で結果をソートしてからクライアントに返します。 両方の検索タイプの利点を活用できます。たとえば、顧客が orderId で検索する場合のように、検索フレーズに意味的な意味があまりないシナリオがあります。セマンティック検索はこのようなケースには適しておらず、キーワードマッチングが最適です。 ハイブリッド検索機能により、注文履歴検索の実装工数と潜在的なレイテンシー増加を抑えられました。 過去のデータの更新 インフラストラクチャのセットアップ後、新しく取り込まれるレコードは関連するエンベディングベクトルとともに永続化され、セマンティック検索をサポートします。しかし、顧客が検索する際は通常、以前に購入した商品を検索します。そのため、古いレコードにエンベディングがなければ、顧客体験の改善にはつながりません。バックフィルの方法はデータ規模に依存します。 潜在的な顧客影響を最小化するリリース 最後のステップは、問題発生時の影響を最小限に抑えながらクライアントに変更をリリースすることでした。具体的には以下の方法を採用しました。 セマンティック検索フローで一時的な問題が発生した場合、リクエスト全体を失敗させるのではなく、レキシカルのみの検索にフォールバックするよう実装する。セマンティック検索が実行されなくても、空の結果ではなくレキシカル検索の結果をクライアントに返せるようにする。 デフォルトの動作をレキシカルのみの検索とし、セマンティック検索機能が必要なクライアントはリクエストに追加フラグを渡す必要があるようにゲーティングする。これにより、該当リクエストのみでセマンティックまたはハイブリッドフローが実行される。 初期期間中は新しいフローをフィーチャーフラグの背後に配置し、重大な問題が検出された場合に完全にオフにできるようにする。 顧客体験の改善例 Rufus が注文履歴を照会して顧客の質問に答えた例を紹介します。 次のスクリーンショットは、「sustainable utensils」のクエリで木製スプーンが検出される例と、タイトルの説明に「charger」というキーワードがないウォールコネクターを含むさまざまな種類の充電器が検出される例を示しています。 次のスクリーンショットは、タイトルの説明にクエリキーワードが含まれていなくても、セマンティック検索が関連する結果を検出する例を示しています。 セマンティック検索機能の導入により、Rufus が関連商品を取得して顧客に表示できるようになりました。導入前は、こうしたクエリに対して結果を返せませんでした。 ビジネスへの影響 主なビジネス成果は以下のとおりです。 顧客体験の改善 – クエリの再現率が 10% 向上し、関連する結果を返す検索の割合が増加しました。また、過去の注文の検索に関するカスタマーサービスへの問い合わせも減少しました。 パートナー連携の成功 – Alexa と Rufus の自然言語処理能力が強化され、注文履歴クエリの解釈精度が向上しました。パートナーチームによるリランキングや後処理の必要性も軽減されました。クエリ成功率は 20% 向上し、より多くの顧客検索が少なくとも 1 つの関連商品を返すようになりました。また、結果カバレッジが 48% 向上し、レキシカル検索では見逃されていた関連する一致をセマンティック検索が一貫して検出するようになりました。 まとめ 本記事では、Amazon の注文履歴検索をセマンティック検索機能に対応させた方法を紹介しました。既存インフラストラクチャの制約の中で最先端の AI 技術を活用し、機能アップグレード中もサービスの中断を回避して SLA を維持するソリューションを開発しました。実装にはバックフィルも含まれ、通常の取り込み速度の数倍のレートで数十億のドキュメントを処理し、過去に購入された商品のエンベディングベクトルを計算しました。慎重なエンジニアリングが求められましたが、極端な負荷下でも OpenSearch Service のレジリエンシーを活用して対応しました。 この基盤を活かして、検索技術を継続的に進化させられます。エンベディングベクトルのフレームワークに改良モデルを組み込めるほか、パーソナライゼーションやマルチモーダル検索など新機能への拡張にも対応できます。 Exact k-NN search の手順に従って、正確な k-NN 検索を今すぐ始められます。OpenSearch クラスターのマネージドソリューションをお探しの場合は、 Amazon OpenSearch Service をご確認ください。 著者について Shwetabh Shwetabh は、Amazon のシニアソフトウェアエンジニアで、分散システムと機械学習に関心があります。仕事以外では、技術的な深掘りや示唆に富むノンフィクションを好む読書家です。 Harshavardhan Miryala Harshavardhan は、Amazon のソフトウェアエンジニアで、機械学習、特に情報検索と分散コンピューティングに関心があります。仕事以外では、ラケットスポーツやサッカー観戦を楽しんでいます。 Ayush Kumar Ayush は、Amazon のテックリーダーで、14 年以上の経験を持つビルダーです。Your Orders Search プロダクトをリードしています。余暇にはクリケット観戦や幼い子どもとの遊びを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

本記事は 2025/10/10 に公開された “ Transform Supply Chain Logistics with Agentic AI ” を翻訳したものです。 AI はあらゆるサプライチェーンプロセスを変革する可能性があります。予測分析、モノのインターネット（IoT）、機械学習（ML）などの既存技術は、サプライチェーンの効率性と可視性を向上させましたが、組織は依然として重大な課題に直面しています。今日のサプライチェーン実務者は、地政学的緊張から自然災害に至るまでの複雑なシナリオに対応しながら、複数のシステムに散在するデータを管理しなければなりません。これらの課題は、大きなビジネスインパクトを生み出します。例えば、複雑な組立品で 1 つの締結部品(ボルト・ナット等)が欠けているだけで、納品が数週間遅れ、重大な財務損失と顧客体験の低下を招きます。他のすべてのプロセスが完璧に機能していてもです。エージェンティック AI（サプライチェーンエージェント）は、これらの根強い課題を解決できるでしょうか？このブログでは、Amazon Web Services（AWS）プロフェッショナルサービス（ProServe）が、組織が本番運用可能なレベルのエージェンティック AI ソリューションを実装し、サプライチェーン業務変革をどのように支援しているかを説明します。 サプライチェーンにおけるビジネス価値の機会 生成 AI は、サプライチェーンに大きな影響を与えると考えられています。マッキンゼーによると、サプライチェーンの総コストは運用コストの 3〜4%分、全産業合計で 2,900 億ドルから 5,500 億ドル削減可能とされています。この可能性により、EY（アーンスト・アンド・ヤング） はサプライチェーン組織の 40% が生成 AI 技術に投資していると指摘しています。これは、企業が生成 AI の価値を認識しており、アーリーアダプターがこの技術をサプライチェーンプロセスの中核に採用し始めていることを示しています。 生成 AI は、以下のようなビジネス成果を生み出す可能性があります： 関連する洞察や文書を速く見つけ、サプライチェーン専門家の時間を定型業務から解放し、労働生産性を向上させます。 原材料の状態の可視化と基礎データへの信頼性により過剰在庫を削減し、緊急配送や航空輸送の回数を減らします。 処理の自動化と自動生成される推奨事項により意思決定プロセスを最適化し、専門知識の活用、管理業務、ステークホルダーとの調整を効率化します。 エージェンティック AI システムが協力して複雑なタスクを解決 エージェンティック AI システムとは、独立して動作し、相互作用し、動的な環境で自律的な決定を下すデジタルシステムを指します。これらのシステムは、複数のエージェントを調整し、他の AI システムと通信してタスクを効率的に遂行し、複雑な問題解決と自動化を可能にします。生成 AI はエージェンティック AI システムとエージェントの基盤を提供し、AWS では顧客は Amazon Bedrock AgentCore を利用します。論理ベースの推論と文脈理解を通じて、エージェントはアクションを計画し、他のエージェントと協力し、タスクを効率的に実行し、人間の論理と推論を模倣します。サプライチェーン実務者がしばしば複数のシステムや部門横断的なチームやパートナーを扱うため、AI エージェントを使用することで、組織はより効率的になり、価値を生み出すことができます。 モデルベース、目標ベース、学習ベース、自律型、LLM、エージェンティックエージェントなど、異なるタスクを完了するためのエージェントタイプが増えています。これらのエージェントは、異なる機能を持ち、協力して目的の結果を達成します。例えば、顧客が納品を迅速化することを要求したとします。1 つのエージェントが納品のステータスを確認し、別のエージェントが在庫を確認します。さらに、別のエージェントが迅速化テーブルとコストを確認し、最後のエージェントはすべての情報に基づいて次の推奨アクションをまとめます。これらのエージェンティック機能は、複数のデータソースを組み合わせて、内外の顧客体験を向上させます。さらに、情報をまとめて推奨を行うだけでなく、組織が許可すれば、エージェントがシステム上のデータを更新することができます。 物流における AI エージェント 物流はリアルタイムでのステータス更新の必要性、絶えず変化するビジネス環境、そして異なる形式の複数のシステムとデータソースが存在するため、課題に溢れています。多くの企業は、アラートとプロアクティブなモニタリングでこれらの課題を解決していますが、これらのアラートには文脈情報が不足し、潜在的な解決策を提供せず、問題を 1 か所で解決する事ができません。 ガイドラインとして、AI エージェント（メイン）は物流エージェント、在庫エージェント、補充エージェント、調達エージェントなどの焦点を絞ったペルソナを持つことが推奨されます。これらのエージェントは共通の目標に向かって協力します。AI エージェントチームが協力して作業する様子を図 1 に示します。焦点を絞ったペルソナは、エンドユーザーがエージェント（メイン）の担当タスクを理解しやすくします。また、ユーザーデータアクセスを制限し、エージェントが処理する必要があるデータの量を減らします。特に物流では、倉庫、品質、文書生成、補充、関税/規制コンプライアンス、調達/契約、内部・外部の顧客体験など、様々なタイプのエージェントのユースケースがあります。焦点を絞ったペルソナを定義した後、次のステップは、エージェントが解決するべき問題とデータへのアクセス方法を定義することです。以下では、物流エージェントに焦点を当てます。 図 1: 協力して作業する AI エージェントチーム AWS ProServe が A*STAR 向けに物流エージェントを作成 2024 年 9 月、AWS はシンガポール貿易産業省（MTI）と科学技術研究庁（A*STAR）が設立した 製造セクター AI センター・オブ・エクセレンス （AIMfg）の立ち上げに参加しました。これはシンガポールの国家 AI 戦略 2.0 の一環です。このコラボレーションの最初の取り組みは「物流の未来」の探求に焦点を当てており、AWS ProServe は Amazon Bedrock を活用した物流エージェントを開発しました。 先進再製造技術センター （ARTC）は A*STAR 内の研究機関です。このセンターは航空宇宙、陸上輸送、消費財、バイオメディカル製造、エネルギーの 5 つの主要分野にわたる 96 のコンソーシアムメンバーで構成されています。この組織は、次の 4 つの戦略的テーマで研究開発を推進しています： 次世代製造プロセス 自律型製造 ネットゼロ製造（脱炭素製造） 強靭なバリューチェーン Industry 5.0 の人間中心的、持続可能、強靭な生産を重視する A*STAR ARTC は、プラントチームにエージェンティック AI を提供しています。これにより、仮想 AI エージェントが以下のような機会を創出します： 計画、実行、サプライヤー協業にわたる 組織の知識を集約 し、それを組織の業務 DNA に組み込む 目標駆動型の意思決定を行い、フィードバックループを通じて自己改善し、文脈の認識を維持することで、 自律的に運用する 。 AWS ProServe と共同で、A*STAR ARTC は物流の専門家とデータ分析者向けにカスタマイズされた AI エージェントを開発しました。このインテリジェントシステムにより、サプライチェーンの実務者は以下の項目を実現することができます： リアルタイムデータを集約・統合 します。ERP（基幹業務システム）、TMS（輸送管理システム）、WMS（倉庫管理システム）、顧客向けポータルからデータを収集します。 内部および外部の問い合わせに対して即時かつ正確な回答 を提供します。これにより、手動での検索と照合の作業負荷を最大 50％ 削減します。 緊急配送コストを総物流費用の 3〜5％削減 し、逸失収益を軽減します。また、納品から配送までのサイクルを短縮します。 手戻り作業を最小化することで計画担当者の 生産性を向上させ 、例外管理、ネットワーク最適化、戦略的サプライヤー連携に集中できるようにします。 迅速で透明性の高い更新情報と予測到着時刻（ETA）のインサイトを通じて、 顧客満足度を向上 させます。 一時的な効率向上を超えて、この AI 駆動型アプローチは堅牢なデータ戦略を支え、キャパシティプランニングからアフターサービスまでのオペレーションバリューチェーン全体にわたり、物流をスマートで情報に基づく意思決定を促進する触媒として位置づけられます。 物流エージェントの構築アプローチと結果 AWS ProServe チームと A*STAR は協力して、エージェントが解決すべき複数の問題やタスクを定義しました。例えば、出荷最新の情報や影響を受ける発注書のアラートなどです。サプライチェーンの専門家は、自然言語と会話型 AI を使用してデータと対話します。これにより、問い合わせに対して変更、キャンセル、推奨を行うことができます。チームが様々な問題やタスクを定義した後、Amazon Bedrock やその他の AWS サービスを利用して物流エージェントを構築しました。 ビデオ 1：AI エージェント – 問題の定義から実行まで ビデオ 1 に示されているように、物流エージェントの導入により、チームは複数のソース（天気、出荷状況など）からより速く最新の情報を取得し、実行可能な対策についての洞察を得て、問い合わせに対する標準的な回答を受け取ることができます。例えば、ユーザーが発注書の更新を要求し、自然言語で質問を入力します。AI エージェントは質問を理解し、適切なデータソースを識別します。これには、構造化または非構造化データの分析が含まれます。これには、ERP システムや Excel スプレッドシートなどの内部データソース、または港湾のウェブサイトや航空貨物運送業者へのアプリケーション・プログラミング・インターフェース（API）接続などの外部ソースが含まれます。次に、AI エージェントは関連データにアクセスし、自然言語処理を使用して質問に答え、正確な回答を提供します。データ接続とエージェントのセットアップがどのように設定されているかの可視化については、図 2 を参照してください。 図 2：内外のデータへのアクセスを持つエージェントセットアップの例 要約すると、ロジスティクスアナリストは手動で情報を検索し、洞察を導き出したりする必要がなくなり、より戦略的なタスクに集中できるようになりました。これは一つの例ですが、サプライチェーン全体で適用可能な例は多くあり、生成 AI とサプライチェーンエージェントが組織の運営方法を変革しています。AI エージェントは洞察を即座に導き出し、エンドカスタマーの問い合わせに数秒で回答し、セルフサービスの問い合わせを可能にし、カスタマーエクスペリエンスの向上に役立ちます。 まとめ エージェンティック AI 機能は、物流の実務者が日々の業務を遂行し、エンドカスタマーエクスペリエンスを向上させる方法を変革しています。物流 AI エージェントにより、サプライチェーンチームは自然言語で対話し、組織のコンテキストを理解し、適切なデータソースを自動的に識別し、AI 推論を利用して結論を導き出したり、次の最善のアクションを推奨したりすることができます。ビジネス価値を基礎とする取り組みにより、サプライチェーンのあらゆる機能において、生産性の向上、収益の増加、速度の向上、コストの削減、無駄の排除につながる機会があります。エンドカスタマーの要求がさらに厳しくなる中で、この分野のリーダーは、価値を早期に得て、競争優位性に変えることができるでしょう。 この技術を導入する企業は、ビジネス価値をより早く実現し、すぐに競争優位性を獲得できます。AWS のお客様は、Amazon Bedrock サービス群やその他の利用可能なサービスで、今日から構築を始めることができます。変革の旅を加速させたいお客様は、 AWS プロフェッショナルサービス のアカウントエグゼクティブまたは AWS アカウントマネージャーにお問い合わせください。 物流エージェントの初期構築に貢献した Sam Gordon、さらなる開発と継続的なサポートを提供した Annie Naveh、追加のサポートとガイダンスを提供した Emily O’Kelly に特別な感謝を申し上げます。 翻訳は、ソリューションアーキテクトの山本が担当しました。 <!-- '"` --> Joe Pazak Joe Pazak は、アジア太平洋・日本（APJ）のエンドツーエンドのサプライチェーンとデジタルトランスフォーメーションを支援する責任者です。Joe は、需要計画、供給計画、生成 AI、高度な分析、物流、調達をカバーする複数の業界との大規模な変革プロジェクトから、深いサプライチェーンの専門知識をもたらします。彼は顧客を支援することを熱望しており、次世代のサプライチェーンツールとテクノロジーに移行するにつれて、大きなアイデアを考えるよう促します。Joe はシドニーを拠点としています。 Dr. Manuel Baeuml Dr. Manuel Baeuml は、ASEAN の AWS 製造・小売プラクティスをリードしています。Manuel は、スマート製造、顧客体験、サプライチェーンに注目し、製造および小売企業が重要なデジタル機能の定義・構想・実装を支援しています。過去 15 年間、Manuel はアジア太平洋とヨーロッパの業界リーダーと働いてきました。Manuel はシンガポールを拠点としています。