はじめに

本記事では、AWS Summit のセッション「情報を集め、判断し、行動する時代へ：データ基盤・AI エージェント・エッジ AI で変わる製造現場」の内容を、製造業におけるAI活用という観点で整理します。
単なる要約ではなく、どのような課題認識があり、どんなアーキテクチャや考え方が提示されたのかを中心にまとめています。

忙しい方用

• 製造現場のAI活用は、業務の自動化ではなく、判断と行動を支える仕組みづくりが本質です。
• データは集めるだけでなく、コンテキストを持たせることが重要です。
• 既存のISA-95型アーキテクチャには限界があり、イベントドリブンかつ文脈付きのデータ設計が必要です。
• AIは一律ではなく、自動化 / AIアシスタント / AIエージェントを使い分ける必要があります。
• 製造業のRAGでは、正確性と完全性が特に重要です。
• 外部システム連携には MCP、現場側には AWS IoT Greengrass のような構成が有効です。
• 特に重要だと感じたのは、AI導入そのものよりも、現場のワークフローをどう再設計するかという視点でした。

セッション情報

項目	内容
セッション名	情報を集め、判断し、行動する時代へ：データ基盤・AI エージェント・エッジ AI で変わる製造現場
スライドURL	https://pages.awscloud.com/rs/112-TZM-766/images/R10_0625_IND327_v3.pdf
セッション動画URL	https://summitjapan.awslivestream.com/jpn-ind327/live/
テーマ	製造現場におけるデータ基盤、AIエージェント、エッジAI活用

セッションの主な内容

1. 製造業でAIを導入する目的

セッション冒頭では、製造業がAIに期待する価値として次の3点が整理されました。

• 揺らがないパフォーマンス
• 従業員のエンパワーメント
• スピードある実行

つまり、AIは現場の一部を置き換えるものではなく、
現場の安定稼働・知識継承・意思決定の迅速化を支える基盤として位置づけられていました。

2. 既存のデータアーキテクチャの限界

従来のISA-95に基づくピラミッド型アーキテクチャでは、上位層に行くほどデータの鮮度が落ち、文脈情報も不足しやすいという課題があります。
その結果、AIやアプリケーションが意味のある判断を行いにくくなります。

この課題に対して、セッションでは以下の方向性が示されました。

• イベントドリブンでデータを流す
• データにコンテキストを付与する
• どのシステムからでも必要な情報へ直接アクセスできる状態を作る

この考え方により、単なる監視ではなく、AIが情報を集めて判断し、次のアクションにつなげる構成が実現できると説明されていました。

3. AI活用には段階がある

AIの活用方法は一様ではなく、タスクの性質に応じて使い分ける必要があります。
セッションでは、AIの自律性を以下のような段階で整理していました。

1. 自動化
2. AIアシスタント
3. ゴール駆動型AIエージェント
4. 完全自律型マルチエージェントシステム

また、タスクの複雑性とリスクの2軸で考えるのが実践的だと説明されていました。
特に製造業では、安全性や説明可能性が重要であるため、すべてをAIに任せるのではなく、人間が介在すべき領域を明確に設計することが重要になります。

4. ワークフロー再設計の原則

AI導入にあたっての重要な原則として、以下の3点が挙げられました。

1. 既存プロセスをそのままAI化しない
2. 万能なAIはないため、タスクに応じて使い分ける
3. 導入して終わりではなく、継続的に改善する

この点は、PoC止まりで終わりやすいAIプロジェクトに対して、非常に示唆的でした。
AIは単機能のツールではなく、運用しながら改善していく前提の仕組みとして捉える必要があると感じました。

5. 現場保全ユースケース

具体例として、現場保全支援ワークフローが紹介されました。

流れは以下の通りです。

1. 設備異常を検知する
2. AIが設備のコンテキストを収集する
3. マニュアルやSOPを検索する
4. 作業指示を生成する
5. 現場作業員がタブレットやスマホで支援を受ける
6. 結果をフィードバックし、次回に活かす

このユースケースでは、AIが担うのは診断や情報収集であり、最終判断や現場投入の判断は人間が行う構成でした。
実運用を考えると、この役割分担は非常に現実的だと感じました。

6. データのエンリッチメントが鍵

センサーから取得した生データだけでは、AIは意味のある判断ができません。
そのため、以下のようなコンテキストを付与するエンリッチメントが重要になります。

• 工場名
• 設備名
• 部品名
• センサー種別
• マシンモデル
• 位置情報

このコンテキストがあることで、AIは正しい文書を検索し、適切な作業指示を生成できます。

また、エンリッチメントの実施タイミングについては、次の3パターンが紹介されていました。

• 取り込み時
  データ収集時に即座に文脈を付与します。

• バッチ処理時
  まとめて後処理として付与します。

• クエリ時
  検索時に必要な文脈を動的に付与します。

ユースケースに応じて使い分けることで、コストとレイテンシのバランスを取ることができると説明されていました。

7. RAGは製造業では「正確さ」が重要

製造業のマニュアルは長大で、手順や安全情報の欠落が事故につながる可能性があります。
そのため、RAGを使う際には以下が重要になります。

• 階層的チャンキング
• メタデータフィルタリング

固定長のチャンクでは、手順や警告が分断される可能性があります。
一方で階層的チャンキングを使えば、検索は細かく、返却はまとまりのある完全な情報にできます。

また、機器モデルやバージョンなどのメタデータで絞り込むことで、似た文書の混入を防ぎ、正しい設備に対する正しい手順を返しやすくなります。

8. MCPとAIエージェントによる外部連携

現場保全では、マニュアル検索だけではなく、保全履歴参照やチケット発行など、外部システムとの連携も必要になります。
そこで活用されるのが MCP（Model Context Protocol） です。

MCPを使うことで、以下のような構成が取りやすくなります。

• MCPサーバー が外部システムへの接続口になる
• AIエージェント がそのツールを呼び出す
• 外部システム で保全履歴やチケット管理を実行する

加えて、Amazon Bedrock Agents のようなマネージド基盤を活用することで、ランタイム管理、認証、メモリ、可観測性などを含めた本番運用がしやすくなる点も紹介されました。

9. エッジAIとフィジカルAI

後半では、フィジカルAI の考え方が紹介されました。
これは、物理世界を知覚し、推論し、学習しながら自律的に行動するAIのことを指します。

ただし重要なのは、推論がクラウドであってもエッジであってもよいという点です。
ユースケースに応じて、次のような場合はエッジ推論が適しています。

• レイテンシーが重要
• 安全制御が必要
• プライバシー配慮が必要

AWS IoT Greengrass を使えば、クラウドで管理するソフトウェアやモデルをエッジへ安全に配信し、ローカルで実行できます。
これにより、クラウドとエッジをまたいだAI運用が可能になると説明されていました。

印象に残ったポイント

AI導入の目的は、既存業務の単純な置き換えではなく、現場の判断と行動を支える仕組みへの再設計にあると強く感じました。
また、データは単に集めるだけでは足りず、文脈を持たせることが実運用での鍵になります。

さらに、RAGやAIエージェントは万能ではなく、タスクの複雑性やリスクに応じた使い分けが必要です。
特に製造現場では、危険や影響範囲が大きい作業も多いため、AIと人間の役割分担を明確にした設計が現実的だと感じました。

まとめ

本セッションでは、製造現場のAI活用を「個別機能の導入」ではなく、
データ基盤・AIエージェント・エッジAIをつなげた現場ワークフローの再設計として捉える視点が示されました。

特に重要だったのは以下の点です。

• データにはコンテキストを持たせる
• AIは複雑性とリスクに応じて使い分ける
• RAGは正確性と完全性が重要
• 外部システム連携にはMCPが有効
• エッジとクラウドはユースケースに応じて使い分ける
• 安全性と説明可能性を担保する

製造現場でAIを本格活用するには、
「何をAI化するか」ではなく「どう現場を情報・判断・行動でつなぐか」 が本質だと感じました。

AIエージェント導入を検討している方へ

私たちナレッジコミュニケーションでは、構想の整理からナレッジ設計、認証連携、実装、運用改善まで、Amazon Bedrock をベースに、社内で使い続けられるAIエージェント体制をお手伝いいたします。

▼ AIエージェント導入・構築支援サービス | Amazon Bedrock

「何から始めればいいかわからない」という方もご相談は無料ですので、お気軽にお問い合わせください。