DNPが語る「AI Readyデータ」がエージェント時代の土台になる理由

AIエージェントの導入では、「どのLLMを使うか」「どのエージェント製品を選ぶか」が話題になりやすい。だが、AI Agent Day 2026 Summerで大日本印刷（DNP）の和田剛氏が扱った中心論点は、モデル選定ではない。AIエージェントを実務で動かすために、企業データをどのようにAIが理解できる形へ変えるかである。

イベントの公式説明でも、このセッションは「AIエージェント×AI-Ready Dataが挑む業務プロセスの最適化」と題され、生成AIツールの個別最適から、AI Readyなデータを使う業務プロセスの全体最適へ進むことをテーマにしている。AI Agent Day 2026 Summerの公式プログラムも、AIエージェントを機能させるデータ基盤を主題としている。

これは、前のセッションで扱われたAI Ready基盤と同じ問題意識である。AIエージェントがPoCで止まる原因は、モデルが十分に賢くないからだけではない。必要な情報が見つからない。文書の意味や版が分からない。現行の在庫・発注・センサー値につながらない。誰がどこまで実行を許可するか決まっていない。こうしたデータと運用の欠落が、本番利用を止める。

DNPは、印刷・出版で培ったレイアウト解析・構造化・編集の知見を、生成AIが使える情報を作る技術へ広げている。同社のドキュメント構造化AIサービスは、非構造化文書を生成AIが理解・活用しやすい構造化データへ変換する「AI-Ready Data」を掲げる。

本稿では、製品紹介ではなく、IT技術者が設計すべきデータアーキテクチャとして読み解く。

AIエージェントのPoCが止まる本当の理由

PoCではAIが回答を作れたのに、本番導入へ進まない。現場が使わなくなる。精度が安定しない。部門ごとに似たAIが増え、どれが正しいか分からなくなる。こうした問題を、LLM性能、プロンプト、モデル選定だけで説明することはできない。

AIエージェントは、文章を答えるだけでなく、社内文書を検索し、手順を参照し、ERPや在庫DBを読み、計算し、見積・発注・連絡などの後続処理へつなぐ。前提となるデータが読めず、意味が曖昧で、現在の状態を取得できず、権限と停止条件がなければ、エージェントは安全に業務を完了できない。

言い換えれば、AIエージェントの失敗はしばしば「AIが読めないデータ」の問題である。

人が理解できる文書と、AIが使える情報構造は違う

企業にはWord、PDF、Excel、PowerPoint、図面、フローチャート、写真付き手順書などが大量にある。人は見出し、表、図、注釈、矢印、レイアウトを一目で読み取り、情報の親子関係や順序を補完できる。

しかし、見た目のレイアウトと、機械が扱える情報構造は別物だ。

たとえば組織図では、人は位置関係から親子関係や階層を読み取る。図面では、丸数字の部品番号と別ページの部品表を対応付ける。手順書では、写真、注意書き、本文、表の順番から、作業の前後関係と例外条件を理解する。

PDFや画像のままでは、AIがその関係を安定して扱えるとは限らない。DNPのサービスも、文書レイアウトと表組の構造を認識し、生成AIが使いやすい構造化データへ変換することを機能として示している。DNPの公式説明には、複雑な図表や結合表についてはAIだけで完結させず、人手で最終確認するハイブリッド対応も記載されている。

重要なのは、OCRで文字を取り出すだけでは足りないということだ。AIが必要とするのは、文字列ではなく、意味と関係を持つ情報である。

AI Readyデータとは、RAG投入前の「情報設計」である

AI Readyデータは、PDFをそのままRAGへ入れることではない。企業文書を、AIが検索、比較、推論、根拠提示に使える情報構造へ変換することである。

講演では、AI Readyデータ化に必要な処理を次の四つの観点で整理していた。

1. レイアウト構造解析

見出し、本文、表、図、注釈、脚注を区別し、「どこからどこまでが一つの意味か」を抽出する。表は単なる文字の並びではなく、行、列、見出し、単位、注記を持つデータとして扱う。

2. 意味付け

図、写真、表、段落が何を表すかを付ける。たとえば「油圧配管図」「交換対象部品」「部品一覧」「安全上の注意」「暫定対策」といった意味を持たせる。これがないと、検索は似た語を含む文書を返すだけになり、業務上必要な情報へ届きにくい。

3. 意味単位でのチャンク最適化

固定長で500文字、1000文字と切るだけでは、手順、表、条件、例外、注意書きが途中で分断される。見出し、段落、表、図の関係を保ち、回答に必要な文脈を失わない単位で切る必要がある。

4. ナレッジ連携

企業の知識は一文書で完結しない。設計書、部品表、保守手順、故障履歴、FAQ、製品マスターは相互に関係する。文書間のリンク、対象製品、版、部品コード、改定日、責任部門を保持して初めて、AIは関連情報をたどれる。

この四つは、ベクトルDBの設定ではなくデータモデルの設計課題である。AIの回答品質は、投入するモデルより前に、情報をどの粒度・関係・状態で持たせたかによって大きく左右される。

非構造化文書を、業務で使えるデータへ変換する

製造業では特に、図面、Excel方眼紙、手書き注釈、フローチャート、写真入り手順書のように、視覚的なレイアウトに意味が埋め込まれた資料が多い。

たとえば図面の丸数字「①」「②」「③」と、別ページの部品一覧を人が対応付けるように、AIにも次の関係を明示する必要がある。

図面上の部品番号
  → 部品表の正式名称・型番
  → 対象機種・改定版
  → 保守手順・注意事項
  → 故障履歴・交換実績

ここまで構造化されて初めて、「部品①の交換条件と、同じ症状の過去対応を示して」といった質問へ、根拠のある回答を作りやすくなる。

すべての文書を完全自動で構造化できるとは限らない。DNPも、元データの問題、複雑なフローチャート、結合表のようなケースでは、人の最終チェックを組み合わせるとしている。高リスク業務では、構造化前後の品質評価、抽出不能な文書の扱い、修正ワークフローを最初から設計すべきである。

RAGだけでは、今この瞬間の判断を完了できない

RAGが得意なのは、過去のマニュアル、FAQ、設計書、故障履歴など、蓄積された知識を根拠付きで参照することだ。しかし、AIエージェントが実際に行動するには、在庫、発注状況、センサー値、生産計画、ERP、MES、PLMなどの現在値も必要になる。

講演で紹介された海外工場のストライキの例では、ニュースから事象を把握し、RAGで代替部品候補を検索し、ERPから現時点の在庫を取得し、不足数を計算して発注判断へ進む流れが示された。

これは一般化すると、次のアーキテクチャになる。

過去の知識: マニュアル・設計書・FAQ・対応履歴
         ↓ RAG
現在の事実: ERP・MES・PLM・在庫DB・IoT・受発注
         ↓ API / MCP / SQL
業務ルール: 権限・予算・発注条件・承認条件
         ↓ ワークフロー
AIの提案 → 人間の確認または条件付き実行

RAGだけでは現在の在庫を知らず、ERPだけでは代替可否や手順の根拠を説明できない。エージェントに必要なのは、過去の知識と現在の事実を、業務ルールの中で結び付けることだ。

MCPは接続技術であって、データ品質や権限の解決策ではない

MCPを使えば、ERP、PLM、在庫DB、文書管理などをAIから利用しやすくなる。だが、MCPを採用しただけで、情報が正しくなったり、権限問題が解決したりするわけではない。

MCPの認可仕様は、サーバーがユーザーデータや管理操作を扱う場合に認可を必要とし、アクセス・トークンを検証することを求める。MCPの認可仕様を踏まえ、接続設計では次を確認する。

接続先データの正本と更新責任者は誰か
利用者とエージェントは、何を読み、何を書き換えられるか
読み取り、発注、価格変更、メール送信を別々に認可できるか
入力値、実行回数、金額、タイムアウトを制限できるか
参照データ、ツール呼び出し、判断、承認、結果を追跡できるか

MCPは接続レイヤーである。AI Readyデータ、最小権限、監査、承認、停止・復旧を含むアウターハーネスを設計して初めて、企業業務へ安全に使える。

Human in the Loopは、誤った前提を直してくれるとは限らない

AIエージェントの安全策として、Human in the Loopがよく挙げられる。しかし、人が最後に承認すれば安全になるわけではない。

たとえば、AIが交換部品を誤って特定したまま、見積作成、発注準備、承認依頼まで進めたとする。承認者は金額、納期、予算だけを見て、部品特定の前提自体を検証しないかもしれない。

AIエージェントでは、一回の誤認識が後続タスクへ伝播する。

部品特定の誤り
  ↓
見積・発注候補の誤り
  ↓
承認者が金額だけ確認
  ↓
納期遅延・誤発注・生産停止のリスク

したがって、安全設計は最後の承認画面から始めてはいけない。構造化の品質、検索根拠、対象機種や版の照合、業務ルール、承認者が見るべき根拠を、前段から設計する必要がある。

特に高リスク操作では、承認者に「何を承認するのか」を明示する。金額だけではなく、根拠文書、対象部品、適用条件、AIの確信度、不確実性、差分、影響範囲を確認できるようにする。

権限委譲の本体は、AIに何をさせるかではなく、誰が責任を負うかである

講演では、条件を満たせば一定金額以下の部品を自動発注するような、AIへの権限委譲と「エージェントコマース」の可能性にも言及された。これは便利な自動化の話である前に、権限と監査の話だ。

自動発注を許可するなら、少なくとも次を定義する。

誰が、どの条件で、どの上限まで権限を委譲したか
AIが参照した在庫、価格、需要、契約条件は何か
どの業務ルールと例外判定を通ったか
どのモデル・プロンプト・ツール版で実行したか
誰が承認し、誰が事後責任を持つか
誤発注時にどう止め、取り消し、原因を調べるか

AIの行動権限を増やすほど、監査証跡、予算上限、異常検知、取消可能性、責任分界は重要になる。これは将来の機能ではなく、今からデータとワークフローに埋め込むべき運用要件である。

IT技術者が実装するAI Readyデータ・パイプライン

AIエージェント向けのデータ基盤は、次の流れで設計できる。

段階	実装すること	確認すべきこと
収集	PDF、Word、Excel、PowerPoint、図面、画像、業務DBを集める	正本、所有者、利用目的、保持期間を決めたか
構造化	OCR、レイアウト、表、図、見出し、注釈を抽出する	人手補正が必要な文書を判別できるか
意味付け	製品、部品、工程、版、状態、責任者、機密区分を付ける	用語・マスター・オントロジーを統一したか
関係付け	設計書、部品表、手順、履歴、FAQを結ぶ	リンク切れ、改定、廃止を追跡できるか
インデックス	全文、ベクトル、メタデータ、権限を登録する	文書単位・チャンク単位でアクセス制御できるか
提供	RAG、API、MCP、BI、業務画面へ出す	根拠、版、更新日時を利用者へ示せるか
運用	評価、訂正、再構造化、監査、削除を回す	誤回答をデータのどこまで戻って修正できるか

このパイプラインに、ERPやMESなどのリアルタイムデータ連携と、承認・実行・ログのワークフローを組み合わせる。AIエージェントは、データ活用基盤の上に載るアプリケーションであり、基盤を省略して成立するものではない。

RAG導入前に確認するチェックリスト

文書とデータ

正式文書、下書き、旧版、廃止文書を区別できるか
図、表、注釈、ページ間の関係を失わずに構造化できるか
製品、部品、工程、顧客、案件などのキーで文書を結べるか
文書の責任者、改定日、有効期限、機密区分を持たせたか
構造化品質を抽出精度だけでなく、業務での検索・回答品質で評価したか

エージェントとリアルタイム連携

過去知識と現在値を、どのシステムから取得するか分けたか
現在値の取得時刻、失敗時の扱い、キャッシュ条件を決めたか
RAGの回答とERP・MESの数値が矛盾した時に停止できるか
参照、計算、更新、外部送信を別の権限として管理したか

ガバナンスと評価

回答の根拠、参照版、ツール呼び出し、承認、実行結果を記録できるか
高リスク操作で、人が判断に必要な根拠を見られるか
誤った前提が下流へ伝わるケースを評価シナリオに入れたか
実行上限、予算上限、タイムアウト、停止・ロールバックを実装したか
モデル、プロンプト、構造化ルールの変更後に再評価できるか

まとめ: 競争力になるのは、AIが理解できる形へ自社情報を変える力である

AIエージェント時代の競争力は、どのモデルをいち早く契約するかだけでは決まらない。同じモデルは競合企業も使える。一方、自社が長年蓄積してきた図面、マニュアル、手順書、業務記録、故障履歴、判断基準、リアルタイム業務データは、その企業にしかない。

差が付くのは、それらをAIが誤解なく利用できる形へ再構成できるかどうかだ。

情報構造を抽出し、意味と関係を付ける
版、鮮度、正本、権限を管理する
RAGの過去知識と、ERP・MESなどの現在値を結ぶ
誤った前提が後続業務へ伝わらないよう、根拠・承認・停止を設計する
行動権限を委譲するなら、監査と責任分界を残す

AI Readyとは、AIを導入済みであることではない。AIが正しい情報を使い、正しい権限で判断し、根拠を示し、人間が検証・訂正できる状態である。

モデルの進化が速いほど、企業が長期的に投資すべき対象は、特定のAI製品ではない。AIが企業の知識と現在の業務を安全に理解し、行動につなげられるデータアーキテクチャそのものである。

作成日: 2026年7月23日