Amazon Web Services ブログ
【開催報告】AWS Summit Japan 2025 物流業界向けブース展示 「倉庫 x OCR x 生成 AI エージェント」
6月 24 日と 25 日の 2 日間にわたり、幕張メッセにおいて 14 回目となる AWS Summit Japan が開催され、会場では約 3 万人の方々にご参加いただきました。本イベントでは 90 のセッションと 174 のブース展示が行われ、AWS の最新情報が共有されました。
物流業担当チームでは「倉庫 x OCR x 生成 AI エージェント」と題したデモ展示を行いました。この展示は物流業のみならず、製造業や小売業など倉庫業務に関心をもつ多くの方々にご来場いただき、生成AIによる OCR 読み取りの高精度さや生成AI エージェントを活用した業務高度化について大きな反響をいただきました。本ブログでは、展示内容とそれに使用されたサービスやアーキテクチャについて解説いたします。
背景：物流業界の課題
物流業界では、倉庫における手書き帳票処理が大きな課題となっています。作業スタッフの負担増大により、配送遅延や間違いが多発しており、業務効率化が急務となっています。このような状況を踏まえ、「生成AI を基幹システムとどう連携させるか」「生成AI をどのように業務改善に活用するか」という課題に対する一つの解決策として、今回のデモを企画しました。
デモの全体像
今回のデモでは、倉庫内の手書き帳票業務を対象に、生成AIを活用した OCR 機能とシステム連携による業務効率化ソリューションを紹介しました。以下がその主な特徴です。
1. 生成AIによる高精度な帳票読み取り（OCR）
- さまざまな帳票レイアウトや手書き文字も高精度で認識
- 事前に帳票テンプレートを登録・学習させる必要がなく、初見の帳票でも構造を理解して情報を抽出
- Anthropic Claude 3.7 Sonnet を活用した高度なテキスト認識能力
2. 生成AIエージェントによる自律的なシステム連携
- 帳票から読み取った情報をもとに、必要な処理を自律的に判断
- 抽出情報に基づき、適切なシステムと連携する処理を実行
- Anthropic Claude 3.5 Haiku を活用したインテリジェントなワークフロー制御
アーキテクチャ構成
デモのアーキテクチャは以下のような構成になっています。
- データ取得：ハンディターミナル/タブレットで撮影した帳票イメージをAmazon S3 に保存
- OCR 処理：AWS Lambdaが起動し、Amazon Bedrock 上の Anthropic Claude 3.7 Sonnet を呼び出して帳票をデジタル化し、抽出されたデータを Amazon DynamoDB に保存
- システム連携：Amazon Bedrock上の生成AIエージェント（Anthropic Claude 3.5 Haiku）が Amazon DynamoDB の情報を読み取り、連携先の基幹システムを適切に呼び出し
- 情報可視化：基幹システムの情報を BI として Amazon QuickSight で可視化
このシステムにより、手書き帳票のデジタル化から基幹システムとの連携までをシームレスに実現しています。また、Amazon API Gateway、Amazon Cognito、Amazon QuickSightなども活用し、セキュアで使いやすいインターフェースを提供しています。
デモのシナリオを順を追って説明します。
①データ取得
倉庫内の作業員がハンディターミナルやタブレットを使用してデモアプリケーションから手書き帳票を撮影します。
撮影された画像データは、Amazon API Gatewayを経由してAmazon S3バケットに保存されます。作業員は特別な訓練なしに、簡単な操作で帳票をデジタル化するプロセスを開始できます。これにより、従来は手作業で行っていた帳票の仕分けや管理作業が大幅に効率化されます。
②OCR処理
生成AI以前の従来の OCR でも画像からデジタルなテキストデータを抽出することは可能でしたが、そのテキストに意味的な解釈を加えるためにはアプリケーション側の工夫が必要でした。例えば、今回の例のように帳票を扱うようなOCRシステムを構築する場合、帳票のテンプレートごとにどこにどのようなデータがあるかという意味的な解釈をシステムに組み込む必要があるため、帳票数が増えるとシステム管理にかかる工数が増大する問題がありました。
生成AIを活用することでこの問題を大幅に軽減できます。Amazon Bedrock にはテキストに加えて画像や音声をインプット情報として処理できるマルチモーダルな生成AIモデルがあります。こうしたモデルに対して、以下のようなプロンプトを画像とともに与えることで、高度なOCR処理を実現できます。
あなたは倉庫管理システムのOCR専門アシスタントです。この画像を分析し、発注指示書かどうかを判定し、情報を抽出して下さい。
## 判定基準
発注指示書の特徴：
- 依頼者情報（名前、住所、電話番号）
- 出荷先情報（名前、住所）
- 商品リスト（品番、品名、数量）
- 「発注」「出荷指示」「納品」等のキーワード
## 出力形式
### 発注指示書の場合
以下のJSON形式で出力（説明文は不要）：
json
{
"sender_name": "依頼者名",
"sender_address": "依頼者住所",
"sender_phone": "依頼者電話番号",
"recipient_name": "出荷先名",
"recipient_address": "出荷先住所",
"notes": "備考・特記事項",
"shipment_items": [
{
"product_code": "品番",
"product_name": "品名",
"item_count": 数量（数値`）`
}
]
}
### 発注指示書でない場合
json
{
"document_type": "other",
"content": "読み取った内容をマークダウン形式で記載"
}
## 注意事項
- 情報が不明・読み取れない場合は空文字列（""）またはnullを使用
- 数量は必ず数値型で出力
- 日付は可能な限りYYYY-MM-DD形式に変換
- 曖昧な文字は文脈から推測して補完
- JSONの構文エラーがないよう注意
画像を分析して適切な形式で出力してください。
今回のデモ展示では Amazon S3 に帳票画像が保存されると、AWS Lambda がトリガーされ上記のようなプロンプトを使った OCR 処理が開始されます。今回はモデルとして Anthropic Claude 3.7 Sonnet を使用しています。参考までにサンプルのインプットと出力結果を以下に示します。
{
"sender_name": "クイックファッション",
"sender_address": "141-0021 東京都品川区上大崎4丁目 5-10",
"sender_phone": "012-3456-7890",
"recipient_name": "クイックファッション墨田倉庫",
"recipient_address": "130-0025 東京都墨田区千歳1丁目 5-17",
"notes": "第一希望: 5月27日 16時～18時\n第二希望: 5月28日 18時～20時",
"shipment_items": [
{
"product_code": "A-10606",
"product_name": "コンフォートスニーカー",
"item_count": 35
},
{
"product_code": "G-05011",
"product_name": "クロップドワイドパンツ",
"item_count": 20
},
{
"product_code": "F-20221",
"product_name": "くつろぎスウェット",
"item_count": 45
}
]
}
{
"sender_name": "セカンドモータース",
"sender_address": "〒272-0127 千葉県市川市塩浜2丁目 13-1",
"sender_phone": "012-3456-7890",
"recipient_name": "セカンドモーターズ 新砂倉庫",
"recipient_address": "〒136-0075 東京都江東区新砂3丁目 2-9",
"notes": "",
"shipment_items": [
{
"product_code": "B-101",
"product_name": "エクストリームグリップ",
"item_count": 63
},
{
"product_code": "F-001",
"product_name": "冬タイヤセット1",
"item_count": 25
},
{
"product_code": "F-001",
"product_name": "冬タイヤセット1",
"item_count": 20
},
{
"product_code": "C-0101",
"product_name": "Navi Pro",
"item_count": 22
}
]
}
上記のサンプル画像を比較していただくと、テンプレートが全く異なることがわかります。この異なるテンプレートに対して、単一のプロンプトで想定通りのテキストを抽出できています。最初から倉庫管理システムに登録するために必要なデータ形式として出力されている点も運用上効率的です。
ブース対応の中でコストと認識精度に関する質問を多く頂きました。コストに関しては上記サンプルを OCR した際のInputトークンが 1,900、Output トークンが 400 でした。2025 年 7 月現在の米国リージョンの Anthropic Claude 3.5 Sonnet の単価 で計算すると0.0117 USDとなり、為替にもよりますが1回のOCRあたり1～2円程度のコストになります。
精度に関しては、上記サンプルで確認できる通り撮影状況が良ければ手書き文字であっても高精度で認識が可能です。一方で撮影状況や手書き文字自体によって思うような精度が出ないケースもあり、100 %に近い精度が求められるケースではそのまま導入することは難しい場合もあります。そのような場合には、前処理で OCR 処理がしやすいように画像を加工したり、OCR 処理後のデータを人目で確認させるような Human in the loop の設計とすることで、全体としての認識精度向上に取り組むことができます。今回のデモでは取得したデータをそのまま Amazon DynamoDB に保存しています。
③システム連携
Amazon DynamoDB に保存された構造化データは、Amazon Bedrock 上の生成AI エージェントによって処理されます。この生成AIエージェントは、抽出された情報を分析し、どのような処理が必要かを自律的に判断します。最終回答が得られるまでReasoning (考察) + Acting (実行)と繰り返す手法を React と呼びます。この React の具体例として、商品の出荷指示であれば在庫管理システムへの連携、返品処理であれば返品管理システムへの連携など、適切な基幹システムを自動的に選択して必要な API を呼び出すといったことができます。
また、Amazon Bedrock のエージェント機能には Multi-agent collaboration があり、エージェントは他のコラボレーターエージェントにタスクを委任できます。具体的には、Supervisor エージェントがまずタスクを処理し、その後各社専用エージェントにタスクを委任することで、異なる基幹システムに対して適切なデータ形式で情報を連携させることが可能です。今回のデモでは OCR 処理した商品情報を Amazon Aurora に登録する AWS Lambda 処理を呼び出しています。
このインテリジェントなシステム連携により、従来は人間が判断して手作業で行っていた複数システム間の連携作業が自動化され、処理時間の短縮とヒューマンエラーの削減を実現します。
④情報可視化
倉庫側の在庫や出荷状況を確認する仕組みとして Amazon QuickSight を利用しています。Amazon QuickSight は様々な業界やユースケースで利用可能なビジネスインテリジェンスツールです。デモでは商品毎の在庫数等をダッシュボードで表現しました。Amazon QuickSight はマルチデバイスに対応しているため、常設のモニタに KPI を投影したり、倉庫内を頻繁に移動する社員がモバイルデバイスで状況を確認したりと、幅広い活用が可能です。このようにダッシュボードを利用し、在庫切れリスクの早期発見、適正在庫数の維持、需要予測と備蓄計画の立案に活用いただけます。
また、Amazon QuickSight の大きな魅力はデータソースの選択肢が豊富なことです。AWS サービスである Amazon S3 や Amazon Redshift はもちろん、リレーショナルデータベースの Oracle や PostgreSQL、SaaS のデータプラットフォームである Snowflake など、様々なデータソースをサポートしています。今回は WMS の リレーショナルデータベースである Amazon Aurora をデータソースとして参照し、データベース内の入庫情報と出庫情報を基に、リアルタイムで在庫状況をダッシュボード上に表示しています。
期待される効果
このソリューションを導入することで、以下のような効果が期待できます。
- 業務効率の大幅な向上：手書き帳票の処理時間短縮と人的ミスの削減
- システム連携の自動化：生成AIエージェントによる適切なシステム連携の自動判断
- 柔軟な対応力：様々な帳票フォーマットに対応可能な OCR 能力
- 導入の容易さ：テンプレート登録不要で、すぐに活用可能
補足：Amazon Q Developer
デモアプリケーションは、すべて Amazon Q Developer を活用して開発されました。従来のアプリケーション開発では、設計から実装まで多くの手作業によるコーディングが必要でしたが、今回のデモアプリケーションでは開発プロセスそのものも生成AIを活用して効率化しています。
Amazon Q Developer は、コード生成、コード変換、バグ修正、コードレビューなどの機能を提供する開発者向けの生成AIアシスタントです。今回のデモアプリケーション開発では、以下のような形で活用しました。
- アーキテクチャ設計支援: システム要件から最適なAWSサービス構成を提案
- コード自動生成: AWS Lambda 関数、API Gateway 設定、DynamoDB 操作など、必要なコンポーネントのコードを自然言語による指示から生成
- プロンプトエンジニアリング: OCR 処理やエージェント連携のための最適なプロンプトを設計・改善
- デバッグ支援: 開発中に発生した問題の迅速な特定と修正案の提示・改修
これにより、従来であれば数週間かかるような開発工程が数日で完了し、開発者はビジネスロジックの設計や全体アーキテクチャの最適化に集中することができました。また、生成AI を活用したアプリケーション開発の経験が少ないチームメンバーでも、Amazon Q Developer のガイダンスに従うことで、高品質なコードを短時間で実装することができました。
このように、今回のデモは「生成AI による業務効率化」を示すだけでなく、「生成AI による開発効率化」も同時に実証する取り組みとなりました。物流業同様にソフトウェア開発も人手不足が深刻化しており、開発コストも高騰しています。このような状況で継続的な物流DXを推進するためにAmazon Q Developerを有効に活用することで、開発者の生産性向上と、より複雑な業務課題に対応するソリューションの迅速な開発が可能になります。
まとめ
AWS Summit Japan 2025 で展示した「倉庫 x OCR x 生成 AI エージェント」は、物流業界が抱える手書き帳票処理の課題に対して、生成AIを活用した革新的な解決策を提案しています。生成AI を OCR として活用するだけでなく、システム連携のインテリジェンスとしても活用することで、業務プロセス全体の効率化を実現します。
物流業界は2024 年問題をはじめとする様々な課題に直面していますが、今回のデモで示したように、生成AI の活用によって、デジタルに詳しくない作業員でも簡単に業務を遂行できるようになり、生産性の向上が期待できます。物流が抱える課題の解決に向けて、生成AI の活用を検討してみてはいかがでしょうか。
このブログは、ソリューションアーキテクト 横山、宇加治、山本、駒野 が担当しました。