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日