賢いAIはデータで決まる – 製造現場におけるRAGとエンリッチデータの重要性 – 【AWS Summit 2026 – セッションレポート】

はじめに

想定読了時間：10分
要点だけ押さえたい場合は忙しい方用をお読みください。

今回、AWS Summit 2026 のセッション 「IND327 情報を集め、判断し、行動する時代へ：データ基盤・AI エージェント・エッジ AI で変わる製造現場」 を視聴しました。

賢いAIを使いたいとき、多くの人は、高性能なモデルや最新のモデルを使えばいいのではないか、と思うかもしれません。しかしこのセッションでは、AIを現場で活用するためのデータや仕組みに焦点が当てられていました。

データの質と流れが、AI の判断力を決める

特に製造業においては、同じセンサーの値でも、そこに「どの工場の・どの設備の・どの部品のデータなのか」という コンテキスト1 が付いているかどうかで、AIが出せる答えの質はまったく変わります。

本記事では、「AIが正しく判断するためには、データをどう整えるべきか」 という一点に絞って、以下の内容を整理します。

  • 生データとエンリッチデータの違い
  • 製造現場のマニュアル検索を成立させるRAGの工夫
  • AIエージェントを本番運用するための基盤 Amazon Bedrock AgentCore

本記事はAWS Summit 2026 の IND327 情報を集め、判断し、行動する時代へ：データ基盤・AI エージェント・エッジ AI で変わる製造現場の内容を元にした非公式の日本語要約であり、すべての著作権・知的財産権はAWSに帰属します。

忙しい方用

  • AIが「意味のある判断」をできるかは、モデルの性能よりデータのコンテキストで決まる。 センサーの生データ（センサーID・時刻・値・単位）だけでは、どの工場のどの設備の何のデータか分からず、AIは判断できない。生データをエンリッチデータにすることで、はじめてAIは正しいマニュアルを引き当て、適切な作業指示を作れるようになる。
  • RAGは「入れれば動く」ものではない。 数百〜数千ページある製造マニュアルでは、機械的な固定チャンキングだと安全警告や必要工具が欠落する危険がある。階層的チャンキング（小さな子チャンクで検索し、親チャンク＝手順書まるごとを返す）とメタデータフィルタリング（機器モデル・マニュアル種別・バージョンで絞り込む）が鍵。どちらも Amazon Bedrock Knowledge Bases の標準機能として設定だけで使える。
  • AIエージェントを現場で使い続けるには基盤が必要。 MCPで外部システムと連携し、Amazon Bedrock AgentCore（Runtime / Identity / Memory / Observability）で本番運用を支える。そして、リスクの高い判断には必ず人間を介在させる（Human in the Loop）。

1. セッション概要

項目 内容
セッションコード IND327
セッション名 情報を集め、判断し、行動する時代へ：データ基盤・AI エージェント・エッジ AI で変わる製造現場
スピーカー 深澤 真愛 氏（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）
想定レベル L300（中〜上級）
対象者 製造現場や産業用製品でのAI活用を検討しているがまだ着手できていない方、製造領域における生成AIの具体的な活用事例を知りたい方

セッションのアジェンダは以下の5つで構成されていました。

  1. AI時代に変わらない製造業における価値
  2. 新しいデータ基盤とAI活用の原則
  3. 実践：人間とAIの新しいワークフロー
  4. 次の可能性：Physical AI とエッジへの拡張
  5. まとめ：AI導入の指針と Next Step

本記事では、このうち2と3を中心に取り上げています。

1-1. 前提：製造現場が目指すゴール

セッションの冒頭で語られていたのは、AIの話ではなく「そもそも製造業が目指すべきゴールは何か」という問いでした。

産業用ロボット、大型ダンプトラック、製造装置、航空機エンジンなどのマシンが社会を支えており、「止めることなく、動かし続ける」 ことが大きなミッションである、と説明されていました。そして、マシンへの向き合い方は次のように進化していくと整理されていました。

一方で、AI時代でも変わらない価値として次の3つが挙げられていました。

  • 揺らがないパフォーマンス：安定した結果を出し続ける
  • 従業員のエンパワーメント：より良い意思決定をより迅速に
    ナレッジを蓄積し新人を早期に戦力化する
  • スピードある実行：予測・提案・自己適応するオペレーション

1-2. なぜ「データを集めた先」に進めないのか

セッションでは、現代の工場はすでにセンシング2し、分析する力を持っていると説明されていました。環境が揃ってきているのにもかかわらず、「データを集めたけれど、その先に進めない」という声が多いそうです。その原因として、以下の3つの壁が挙げられていました。

壁 内容
データのサイロ化3 散在するデータ、見えない全体像
人材不足 熟練者が足りず、現場も手一杯で新しいことに着手できない
成果創出のボトルネック PoCから先に進めない（全社的な本番運用に至らない）

そして、この壁の根本原因はデータアーキテクチャにあると指摘されていました。ここから、その原因と対策を見ていきます。

2. 従来のデータ構造では、なぜAIが判断できないのか

セッションでは、製造データの構造を「従来型」と「目指す姿」で比較して説明していました。

2-1. 従来型：階層を1段ずつ上がるピラミッド構造

ISA-954で定義されたピラミッド構造では、データは下から上へ次のように流れます。

従来型：階層を1段ずつ上がる

各層は隣接する層とのみインターフェースを持ち、データは上位層の目的に合わせて抽象化されながら集約され、リクエスト／レスポンス方式で段階的に受け渡されていきます。この構造には2つの課題があると説明されていました。

課題 内容
課題1 上のレイヤーほどデータの鮮度が落ちる。鮮度の落ちたデータでは、より良い意思決定はできない
課題2 各層のデータではコンテキストが不十分で、AIやアプリケーションが意味のある判断をできない

この「上に行くほど鮮度が落ちる」という指摘は、伝言ゲームをイメージするとわかりやすいかと思います。要約されて上に伝わるうちに、判断に必要な細かい情報が落ちてしまうため、人間が最終的な意思決定をする前提なら成立していた構造が、AIに判断させようとした瞬間に足りなくなる、ということです。

2-2. 目指す姿：必要なデータに直接アクセスできる基盤

目指す姿：必要なデータに直接アクセスできる

セッションで示された「目指す姿」では、変えるべきことが2つあると説明されていました。

1. データの流れ方を変える
クライアント／サーバー方式（リクエスト・レスポンス）からイベントドリブン5に変え、どのレイヤーのデータもリアルタイムで更新できるようにする。

2. データの中身を変える
センサーの数値をそのまま流すのではなく、「どの工場の・どの設備の・何のデータなのか」というコンテキストを付与する。

そして、このポイントとして語られていたのが次の一文です。

どのシステムからでも、どのデータにも、いつでも直接アクセスできる状態を作る

この状態になると、アプリケーションやAIエージェントが必要な情報を自ら集め、判断できるようになる、という流れでした。

3. AIの判断を左右するのは「データの質」

ここからが本記事の中心テーマです。同じ値でも、付随する情報の有無でAIの判断がどう変わるのかを、生データとエンリッチデータの比較で見ていきます。

3-1. 生データとは何か

生データとは、センサーや機器から送られてきたまま、加工や情報の付加が行われていないデータのことです。測定した値そのものは含まれていますが、それが何を表すのかという説明は付いていません。

セッションでは、センサーから送られてくる生データの例が示されていました。

含まれているのは、センサーID・タイムスタンプ・値・単位の4つだけです。これに対する課題は、スライドに明確に書かれていました。

どの工場の、どの設備の、どの部品のデータなのか分からない ＝ 意味のある判断ができない

たしかに「75.3℃」という数字だけを渡されても、それが正常なのか異常なのか、人間でも判断できません。AIも同様に、この情報だけでは「正しいマニュアルを探す」ことができないのです。

3-2. エンリッチデータとは何か

エンリッチデータとは、生データに対して、それが何を表すのかを説明する情報を追加したデータのことです。値は変えず、周辺の情報を足すことでAIが解釈できる状態にします。

そこで行うのが、データの拡充（エンリッチ）です。セッションで示されたエンリッチ後のデータは次のようなものでした。

値そのもの（75.3℃）は何も変わっていません。しかし、顧客名・拠点名・マシンのモデル名・コンポーネント名・センサー種別といったコンテキストが付与されたことで、状況がまったく違って見えます。ポイントは以下の通りです。

コンテキストが付与されることで、AIが意味のある判断をできる

セッションでは、「AIはこのコンテキストがあるからこそ、正しいマニュアルを検索し、適切な作業指示を生成するなど、意味のある判断ができる」と説明されていました。

これは当たり前のようですが、最も重要であり、最も忘れがちな部分でもあります。モデルを変えたわけでもなく、プロンプトを工夫したわけでもなく、単に渡すデータに情報を足しただけでAIの判断精度が変わります。「賢いAIを作るのはモデルではなくデータだった」というのは、ここに由来しています。

3-3. エンリッチはいつ・どうやって行うのか

「重要なのは分かったが、どう実現するのか」という疑問点には、データをエンリッチする3つのタイミングと対応するAWSサービスが紹介されていました。

タイミング 内容 紹介されていたサービス
リアルタイム / データ取り込み時 データが入ってきた瞬間にコンテキストを付与する Amazon ECS、AWS Lambda
バッチ / スケジュール 蓄積されたデータを定期的に一括でエンリッチする AWS Glue、Amazon EMR
クエリ時 / 横断検索 必要なときに必要なデータだけをエンリッチする Amazon Athena、AWS Lambda

また、設備データにコンテキストを付与する仕組みとして AWS IoT SiteWise も紹介されていました。

どのタイミング・どのサービスを選ぶかは、レイテンシー要件6・データ量・コストのバランスで決まり、すべてを同じ方法で行う必要はなく、ユースケースに応じて組み合わせるのが現実的だと説明されていました。

4. 整えたデータは現場でどう使われるのか

エンリッチされたデータが、実際にどう使われるのか。セッションでは「現場保全の支援」を例に、ワークフローが示されていました。

ここで注目したいのは、「コンテキスト収集」が異常検知の直後に来ている点です。異常を検知しただけでは何も判断できず、そこに保全履歴・設備メタデータ・時系列データという文脈を足すことで、はじめて次のステップ（マニュアル検索と作業指示の生成）に進めます。

そして最後にフィードバックのループがあるのも重要でした。日報などに入力された保全結果を戻すことで、次回の異常検知や対応の精度を上げていく、という設計です。

5. RAGによって「正しい情報」をAIに渡す

5-1. RAGとは

RAG（Retrieval-Augmented Generation）は、AIが生成を行う前に関連する情報を渡しておくことで、その情報に基づいた回答をしてくれる技術です。

AIが「自分が知っていること」だけで答えるのではなく、必要な資料をその場で調べてから答えるというイメージです。

現場保全のワークフローでは、AIが異常を検知した後に、ナレッジベースからSOP（標準作業手順書）やマニュアルを検索して、アラートと作業指示を生成していました。この「検索」の部分を担うのがRAGです。

5-2. RAGを入れたのにうまくいかない理由

実際には、「RAGを導入してみたけれど、正しい情報が検索できない、精度が出ない」という相談を多く受けるそうです。そして、その原因は製造業で扱うデータの特徴に大きく関係している、と説明されていました。

それは、製造業のマニュアルは数百ページ〜数千ページに及ぶことがあり、手順の順序や安全警告といった情報を正確に取得できないと、現場で危険な作業につながる可能性がある、という指摘です。

そこで紹介されていたのが、技術マニュアルのための2種類のRAG技術です。

  • データチャンキング：大きなマニュアルを検索しやすい小さなセグメントに分割する
  • メタデータフィルタリング：機器モデル・マニュアル種別・バージョンなどのラベルを付与してデータを拡充する

5-3. 固定チャンキングでは安全情報が欠落する

RAGでは、マニュアルをそのままLLMに渡すことはできないため、チャンクと呼ばれる小さな塊に分割し、それぞれをベクトル化7して、質問文と意味的に近いチャンクを検索します。

最もシンプルなのが固定チャンキングで、ページ数や文字数など決まったサイズで機械的に分割する方法です。しかし、製造業のマニュアルではこれが問題になります。セッションでは、「ブームシリンダーの油圧ホースの交換方法は？」という質問例で説明されていました。

固定サイズで分割すると、意味的に近いチャンクはヒットするものの、以下が欠落してしまいます。

  • ❌ 安全上の警告（前のチャンクにある）
  • ❌ 作業仕様（次のチャンクにある）
  • ❌ 必要工具と部品リスト

つまり、安全に関する情報が欠落した状態で作業指示が生成されるリスクがあるということです。

5-4. 階層的チャンキングで手順書ごと取得する

これを解決するのが階層的チャンキングです。

考え方はシンプルで、

  • 検索には小さな子チャンクを使う
  • 結果として返すのは、その子チャンクを含む親チャンク全体（＝手順書のまとまり）

という方式です。

セッションで示された例では、「油圧ホース交換」で検索すると該当する子チャンクにヒットしますが、返されるのは以下を含む完全な手順書でした。

これなら、安全警告や手順の順序が欠落することはありません。そして、この階層的チャンキングは Amazon Bedrock Knowledge Bases の標準機能として組み込まれており、設定で選択するだけで利用できる（複雑な実装は不要）と説明されていました。

5-5. メタデータフィルタリングで正しい機器を特定する

もう一つの工夫がメタデータフィルタリングです。これは「正しい機器のマニュアルをどう特定するか」という精度の問題への対策です。

セッションでは、「AnyCompany Manufacturing Product-101 の油圧オイルの種類とシステム圧力の仕様は？」という質問例が使われていました。

意味検索（ベクトル検索）だけの場合：

正しいサービスマニュアルは取得できるものの、同時に似た製品のマニュアルも引っかかってしまいます。

スライドではこの課題を、「誤った情報の利用により、不適切な診断、安全事故、誤った発注につながる」 と表現していました。

メタデータフィルタリングを利用した場合：

ドキュメントに機器モデル・マニュアル種別・バージョンといったメタデータを付与しておき、検索時に model = "AnyCompany Manufacturing Product-101" のようにフィルタリングします。その結果、対象機器に関する正しい情報だけがヒットするようになります。

こちらも同様に、Amazon Bedrock Knowledge Bases の標準機能として搭載されており、設定で選択するだけで利用できると説明されていました。

RAGについては、社内データを検索してAIに渡す役割だけでなく、検索対象のデータをどう分割し、どうラベル付けしておくかがRAGの成否を決めるということを実感できる良い例だったと思います。ここでも結局、データ側の準備が結果を左右しているという点で、エンリッチデータの話とまったく同じ構造になっています。

6. AIエージェントをOT/ITシステムに接続する

データの質が整い、マニュアルから正確な情報を取得できるようになった次のステップとして、「AIが実際に外部システムとどう接続するか」が説明されていました。セッションでは、シンプルな構成から段階的に説明されていたので、その流れをそのまま整理します。

6-1. Step 1：RAGの基本形

ナレッジベースを元にレスポンスを返す、RAGの基本形です。

6-2. Step 2：MCPで外部システムにつなぐ

現場保全では、保全履歴の参照や作業オーダーの作成など、外部システムとの連携が必要になります。そこで導入されるのが MCP（Model Context Protocol） です。MCPサーバーがツール・リソース・プロンプトという形で外部システムへのアクセスを提供し、LLMがそれを呼び出します。

6-3. Step 3：エージェントを追加する

さらにエージェントを追加すると、MCPホストがクライアントとして複数のMCPサーバーを束ね、エージェントが目標に向けて自律的にツールを選択・実行できるようになります。

役割
RAG 必要な情報を検索してAIに渡す仕組み
AIエージェント 情報収集・判断・行動（ツール実行）までを担う仕組み

RAGはAIエージェントの「情報を集める」部分を支える技術であり、両者はイコールではないことに注意が必要です。

6-4. Step 4：Amazon Bedrock AgentCore で本番運用する

そして、この構成を本番環境で安定して運用するために必要になるのが基盤です。セッションでは、AIエージェントを本番運用するには次の要素が必要になると説明されていました。

  • Runtime：ランタイム管理
  • Identity：認証
  • Memory：メモリ
  • Observability：可観測性

これらをマネージドサービスとして提供するのが Amazon Bedrock AgentCore です。エージェント運用を本番環境で行うための基盤としてAgentCoreを利用することで、エージェントの開発者はビジネスロジックに集中できるという説明でした。

ここで押さえておきたいのは、AgentCoreはAIエージェントそのものではなく、AIエージェントを動かし続けるための土台だということです。

そして、MCPを介して IT/OTシステムと連携し、AWS IoT SiteWise のエンリッチ機能でメタデータを付与されたデータをもとに異常の原因を特定し、メンテナンス依頼を作成して技術者を手配する、といったことが可能になると説明されていました。

7. ここまでの要素をつなぐ全体アーキテクチャ

セッションでは、ここまでの技術要素を1枚にまとめた保全支援システムの全体像も紹介されていました。多くのサービス名が並びますが、構成は3つの要素で整理されていました。

レイヤー 役割 登場していた主なサービス
エッジ8 現場の設備からデータを収集する AWS IoT Greengrass、AWS IoT SiteWise Edge
データ取り込みと保存 データを受け取り、コンテキストを付与（エンリッチ）して保存する AWS IoT Core、AWS IoT SiteWise、Amazon S3、各種データベース
AI / ML
（エージェント）		 エージェントの実行基盤。ナレッジベース検索とOT/IT連携を担う Amazon Bedrock AgentCore、ナレッジベース、MCP

個々のサービス名を覚えることよりも、次の点を意識するのが重要だと説明されていました。

データのエンリッチ、RAG、MCPによるシステム接続などが、エッジからクラウドまで一貫したアーキテクチャとしてつながっているか

AWSのサービス名が並んだ構成図を見ると困惑してしまう人も多いかと思います。ただ「エッジで集める → 途中でコンテキストを付ける → AIが使う」という3段階で捉えると、それぞれのサービスがどこの役割なのか整理しやすくなると思います。

8. デモ：建設機械の保全支援

セッションでは、実際に動くデモも紹介されていました。設定は「東京周辺の現場に20台のショベルカーを保有・稼働している」というユースケースです。

課題として挙げられていたこと

  • 情報が分散していて稼働状況が把握できない
  • 故障対応が熟練者頼みになっている
  • 結果として、復旧に時間と人手がかかる

デモで示されていた流れ

  1. 稼働の可視化：ダッシュボードで20台の状態をリアルタイムに表示。19台は正常だが、1台が異常状態であることが確認できる
  2. 詳細確認：マシン一覧で各センサー値を確認すると、該当のショベルカーはエンジン温度が異常に高く、エンジン回転数が0（停止）になっている
  3. 自動アラート：AIエージェントが異常状態を検知し、アラートを自動起票
  4. AIによる分析：アラートから「分析」を実行すると、その設備のテレメトリデータを収集し、関連ドキュメントを検索。現在の状態と対応策を作業指示として生成
  5. チケット起票：チケットサービスもMCP経由で接続されているため、分析結果を見てそのままチケットを作成し、作業員を派遣できる
  6. 現場での支援：現場作業員はタブレットやスマートフォンからAIアシスタントに質問し、エンジン温度異常への対応手順を教えてもらえる

ここで説明されていた重要なポイントが、役割分担です。これによって、複雑なタスクである現場保全を効率的に進められるようになる、という整理でした。

異常の検知と分析に必要な情報の収集はAIが行うが、現場の作業員を派遣するかどうかの判断は人間が行うこと

9. どの業務をAIに任せるか：複雑性 × リスクで考える

デモを見ると、「どの業務からAIに任せればいいのか」という線引きが気になると思います。セッションでは、その判断軸も示されていました。

前提として、AIシステムには自律性（Agency）のグラデーションがあると整理されていました。人間の監視が多い「支援（生成AIアシスタント）」や「自動化（ルールベースシステム）」から、高い自律性を持つ「エージェント型AIシステム（ゴール駆動型エージェント、完全自律型システム）」まで、連続的に並んでいるという説明です。そのうえで、これらを 複雑性 × リスク の2軸に配置し直したものが示されていました。

リスク：低 リスク：高
複雑性：高 エージェント型システム 支援
複雑性：低 自動化 協働

そして、ワークフロー再設計の基本原則として次の3つが挙げられていました。

  • 既存プロセスを単にAI化しない（人間＋AI前提でワークフローそのものを組み直す）
  • すべてを解決する万能ツールはない（領域ごとに適した手段を組み合わせる）
  • 継続的改善のための新しいベースラインを設ける（導入して終わりにしない）

AIエージェントは高い自律性側の選択肢のひとつであって、常に目指すべきゴールではないという点も押さえておきたいポイントでした。

10. AI導入で忘れてはならない3つの指針

セッションの終盤では、製造現場でAIを導入する上での指針が3つ挙げられていました。これは製造業に限らず、AIエージェントを扱うすべての場面で重要だと感じたので、そのまま紹介します。

1. 重要なワークロードには人間を介在させる
監視、ガードレール9、エスカレーション10をワークロードに組み込み、AIはルール内での実行に留める。危険やリスクを伴うタスクには常に人間の判断を組み込み、AIが想定外のことを行わないようにする。

2. 説明可能性と信頼のための設計
「なぜその判断が行われたのか」「なぜそれが実行されたのか」をログとして取得・保存し、意思決定を監査・理解可能にする。安全・規制領域では不可欠。

3. もしものときに安全へ切り替えられるようにする
通信断やAIの誤判断に備えて、予備の処理や人による確認に切り替えられるよう設計する。

11. 補足：Physical AI とエッジ／クラウドの使い分け

セッション後半で扱われていた Physical AI についても簡単に触れておきます。

Physical AI とは、「機械がセンシング・判断・物理的な操作を通じて、現実世界とインタラクションすることを可能にする」というコンセプトのAIです。

ここで注意点として強調されていたのが、Physical AI ＝ エッジAI11 ではないということでした。Physical AIはあくまでコンセプトであり、AI推論を行う場所はクラウドでもエッジでも構いません。前述の保全支援デモも、エッジで情報を収集してクラウドで推論し、現場作業員の行動を変えているという意味では Physical AI と言えるかもしれない、と説明されていました。

そのうえで、エッジAIを利用する3つの理由が挙げられていました。

理由 内容
レイテンシー6が動作を左右する場合 カメラやロボティクスの制御では、わずかな遅延が動きの精度に直結する
安全や制御に関わる場合 緊急停止や異常検知のような安全に関する判断は、ネットワーク遅延に依存してはいけない
プライバシーが重要な場合 カメラ映像や個人に紐づくセンサーデータなど、クラウドに送らずデバイス内で完結させたい場合

実現方法としては AWS IoT Greengrass が紹介されていました。クラウドの機能をエッジデバイスに拡張するサービスで、クラウドで管理しているソフトウェアやモデルを、工場のエッジデバイスへ安全にデプロイしてローカル実行できるようにします。

事例としては、米国 Agility Robotics のヒューマノイドロボット「Digit」が挙げられていました。倉庫・物流現場でコンテナ搬送を自律実行しており、クラウド上のGPU（EC2 G6）で数万の並列シミュレーションによりモデルを学習し、ロボット本体でリアルタイム制御を行っているとのことです。ここで強調されていたのが継続改善のループです。一度モデルをデプロイして終わりではなく、クラウドからモデルを更新・配信するパイプラインがあるからこそ、実験と改善を続けられるという点でした。

まとめ

最後に、セッションのまとめとして示されていた3点を紹介します。テーマは 「止めない、を実現するために ── 情報を集め、判断し、行動する」 です。

1. データの質と流れが、AIの判断力を決める
コンテキストを付与し、どこからでもアクセスできる基盤をつくる。
2. 単なる既存業務の置き換えではなく、ワークフローを再設計する
既存プロセスを単にAI化せず、複雑性とリスクの2軸で任せ方を選ぶ。自律性はリスクに応じて設計し、重要な判断には人が介在する。
3. AI推論はエッジとクラウドを使い分ける
即応性・安全・プライバシーはエッジ、学習・大規模処理はクラウドで使い分ける。

参考文献

セッション関連資料

AWS公式情報

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

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

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

https://www.knowledgecommunication.jp/product/ai-agent-amazon-bedrock.html

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

※本記事はセッション内容を元にした個人の理解と要約であり、詳細や最新の仕様は必ずAWS公式ドキュメントをご確認ください。

最後までお読みいただき、ありがとうございました。

  1. AIが返答を組み立てるために参照する背景情報や文脈のこと、ユーザーの質問文・対話履歴・システム設定・外部から読み込ませた資料なども含まれる ↩

  2. センサー、コネクティビティ、映像データ、アナリティクスなど ↩

  3. 開発、設計、調達、製造、営業といった各工程のデータが、それぞれのシステムや部門内に閉じ込められ、会社全体でつながらずに孤立している状態 ↩

  4. 企業のビジネスシステム（IT）と工場の制御システム（OT）を統合するための国際標準規格（IEC 62264） ↩

  5. ユーザーがチャット画面で毎回指示を出すのではなく、システム上の特定の出来事（イベント）をきっかけに自動で生成AIが動き出す仕組み ↩

  6. 機器にデータ転送を要求してからその結果が返ってくるまでのタイムラグ（反応速度）のこと ↩ ↩2

  7. 文章や画像などのデータをAIが理解できる「数値の羅列（ベクトル）」に変換する技術 ↩

  8. スマートフォン・監視カメラ・自動車などの端末機器、デバイスのこと ↩

  9. ユーザーとAI（人工知能）の間に立ち、情報のやり取りをリアルタイムで監視・制御して安全性を保つ仕組みや技術 ↩

  10. AI（チャットボットやAIエージェント）が自分の判断や知識では対応できない問題に直面した際、処理を人間の有人オペレーターや上位の専門部署へ自動または手動で引き継ぐ仕組み ↩

  11. スマートフォン、監視カメラ、自動車などの端末機器（エッジデバイス）の内部で直接AI処理を行う仕組み ↩

この記事を書いた人

aws-recipe-user

記事一覧

Related posts:

AWS 【AWS基礎】EFSの基本を5分で理解する
AWS AWS Transit Gateway にざっくり触れる【初心者】
AWS Amazon Connectの使い方[丁寧に解説してみた]
AWS 【AWSサポート問い合わせ術】問い合わせの際に気を付けること