１．はじめに：マニュアルを「死蔵」から「活用」の資産へ
5月号の検証において、私たちは一つの大きなマイルストーンに到達しました。未構造なマニュアル（V0）をiiRDSの思想に基づいて再構成し、AIが文脈を見失わないための「RAG最適化データ（V3）」という鉄壁の検証基盤が完成しました。AIに事実（ファクト）を正しく読ませるインフラが整ったいま、いよいよ情報の「活用」というエキサイティングなフェーズへと舵を切ります。その核心となるテーマが、ユーザーの状況に応じた情報の「パーソナライズ（動的デリバリー）」です。
情報過多がもたらす顧客体験の毀損と安全性のリスク
現代の製品利用者は、常に凄まじい情報過多の波にさらされています。特にB2Bの産業用機器や多機能な製品においては、全機種・全オプションの情報を一冊に網羅した、いわゆる「全部入りマニュアル」をユーザーに提供せざるを得ないのがこれまでの常識でした。しかし、この妥協がユーザーに強いる負担は決して小さくありません。
自分が購入していない製品や、自社のラインには搭載されていないオプションの記述が大量に並ぶマニュアルは、ユーザーを混乱に陥れる元凶となります。必要な情報を探すために分厚いドキュメントを彷徨わせることは、顧客体験（CX）を著しく損ないます。
さらに深刻なのは、これが単なる利便性の問題に留まらず、「実害を伴う安全上のリスク」に直結する点です。ユーザーが自分に関係のない他機種や旧仕様の手順を自社のものと誤認して操作してしまったらどうなるでしょうか。製品の致命的な故障を引き起こすだけでなく、感電や薬液リークといった、利用者の生命を脅かす危険な状態を発生させかねません。
フィールドサービスの現場が直面する「誤認」と「PLリスク」
そしてこのリスクは、一般のユーザー（購入者）だけに留まりません。製品のライフサイクルを支える「フィールドサービスの現場（保守・点検）」においてこそ、この問題はより生々しい脅威になり得ます。
複雑極まる産業用機器のメンテナンス現場では、工場のメンテナンス担当者や自社のサービス技術者が、過酷なタイムリミットの中で作業を行っています。彼らが手にするマニュアルが「全部入り」であるとき、機種ごとの微細なスペックの違いや、オプションの有無による手順の分岐を見誤るリスクが上がります。
プロフェッショナルによる一瞬の「誤認」は、ラインの復旧を遅らせる莫大なダウンタイム損失を招くだけでなく、最悪の場合、重大な労働災害を引き起こしかねません。これはメーカー側から見れば、製造物責任（PLリスク）を根底から揺るがす決定的な火種です。「必要な人へ、必要な時に、必要な情報だけを届ける」ということは、単なるCX向上の施策ではなく、企業の安全ガバナンスにおける最重要命題なのです。
「あなた専用」をその場で編み出す動的デリバリーへ
だからこそいま、求められているのは、利用者の状況（所有している機種、搭載オプション、本人のスキルセットや作業権限）に合わせて、関係のないノイズを完璧に排除した「あなた専用の製品利用者用情報」をピンポイントで届ける仕組みです。
これまでは型番ごとに何百冊ものマニュアルを人間が作り分けるしかありませんでしたが、データに「規律」さえあれば、AIがその場で瞬時にパーソナライズされた情報をデリバリーしてくれる世界が実現します。
本号では、私たちが5月号で構築したV3データを「思考のプロトタイプ」として活用し、このパーソナライズという価値を削り出すための実証実験をレポートします。
しかし、情報の「活用」へ踏み出した私たちの前に、生成AIの構造的な脆さと、情報設計（IA）における深遠なパラドックスに直面することになりました。
２．前提整理：検証のベースとなる「V3（RAG最適化データ）」の構造
パーソナライズ実験の結果をお伝えする前に、まずはその検証のベースとなるデータ基盤「V3：RAG最適化データ」の構造を整理しておきます。5月号を未読の方や、設計・開発の現場から新しく本連載に参加された読者の皆さまに向けて、なぜこのデータ構造が「AIに読ませるための現時点での最適解」と呼ばれているのか、その設計思想を解説します。
一言で言えば、V3とは、AIが迷わず最短距離で確実な正解を提示できるよう情報をチューニングした「AEO（回答エンジン最適化）アーキテクチャ」です。完璧な規格準拠という「管理のための美学」をいったん横に置き、AIという不確実な使い手に、情報をいかに「安全なユニット（荷物）」としてパッキングして渡すかに焦点を当てています。
このデータ構造は、画像に示されている通り、以下の3つの方針で構築しています。
1. 機種ごとの完全なコンポーネント化（バリアントによる隔離）
V3データの最大の特徴は、1つのトピック（情報の最小単位）の中に複数機種の情報を絶対に混在させないという徹底した「引き算の設計」にあります。標準モデル（SP-X100）と耐薬品モデル（SP-X200）の情報は、トピック単位で物理的に完全に隔離されています。これにより、AIが特定の機種について検索した際、他機種のデータが「ノイズ」としてヒットするのを防ぎ、回答に圧倒的なキレ味をもたらします。
2. 住所（Location）の焼き込み
従来のPDFをそのままAIに読み込ませるRAG（検索拡張生成）では、AIがマニュアルの「断片」を拾い上げた際、それが何章のどの部分に書かれている記述なのかを見失う「文脈の断片化」が多発していました。 V3では、すべてのトピックの見出しに【第3章 フィルターエレメントの交換 ＞ 準備するもの (SP-X100)】というように、物理的な階層情報（パンくずリスト）を強制的にマージしています。情報自体にその「居場所（住所）」を焼き込むことで、断片化された状態からでもAIが100%文脈を復元できるように設計しています。
3. 安全文脈の強制統合
マニュアル作成において、安全警告を手順とは別の章に独立して記載することは一般的です。しかしAIにとっては、手順だけを拾い上げた瞬間に安全警告を読み飛ばす致命的なハルシネーション（誤読）の引き金になります。V3では、手順トピックの冒頭に「感電の危険」や「残留圧力」といった安全警告を物理的に結合（非正規化）しました。手順を取得した瞬間に、必ず「安全の護符」がセットで付いてくる構造をデータ側で担保しているのです。
【実践】V3データを生成する最適化プロンプト
このAIの回答精度を最大化することを狙った戦略的にパッキングしたV3データは、元情報から以下のプロンプト（指示書）を用いて構造化データを自動生成しました。
【AEOデータ構造化プロンプト（要約版）】
- コンポーネントの隔離:
見出し単位ではなく「意味の塊」で分割せよ。特に特定機種（SP-X100、SP-X200）に限定される記述は完全に独立したチャンク（トピック）として切り出すこと。- 階層の強制付与:
すべてのチャンクの見出し冒頭に、元のドキュメントのツリー構造に基づくパンくずリスト（例：【第3章 > …】）を必ず焼き込め。- 安全情報の強制マージ:
独立している警告メッセージ（感電、ケミカルリスク等）を、関連する作業手順（Task）の冒層に物理的に結合して一体化させよ。
【生成結果】生成されたV3データ（抜粋）
このプロンプトによって自動分解・パッキングされ、5月号の品質監査をパーフェクトで通過した実際のV3データの一部が以下です:
Markdown
Identity: Topic-002
TopicType: iirds:GenericReference
InformationSubject: iirds:GenericTechnicalData
ProductVariant: [SP-X100]
【第3章 フィルターエレメントの交換 > 準備するもの (SP-X100)】
作業には以下の工具と交換部品が必要です。作業前に準備してください。
|**品目名**|**規格・品番**|**備考**|
|---|---|---|
|交換用フィルター|FLT-X100 (標準)|モデルに合ったものを用意|
|Oリング|OR-S25|新品に交換してください|
|六角レンチ|5mm|ハウジング固定用|
|トルクレンチ|設定範囲 10-20 N・m|締め付け管理用|
---
Identity: Topic-004
TopicType: iirds:GenericTask
ProductVariant: [SP-X100]
【第3章 フィルターエレメントの交換 > 交換手順 (SP-X100)】
警告
感電の危険: 作業を始める前に、必ず主電源を切り、電源プラグをコンセントから抜いてください。
残留圧力: ポンプ内部には高圧が残留している場合があります。ドレンバルブを開放し、圧力が完全に抜けたことを確認してから作業を行ってください。
以下の手順に従って交換を行ってください。
[ハウジングの取り外し] 5mmの六角レンチを使用して、フィルターハウジング下部の4本のボルトを緩めます...（後略）
ご覧の通り、機種ごとにトピックが分かれ、見出しにはパンくずリストが付き、手順の冒頭には警告が美しく焼き込まれています。この「最強のデータセット」を手に、私たちは意気揚々と情報の「利活用（パーソナライズ）」の実証実験へと足を踏み入れました。
しかし、この完璧に見えた構造こそが、次なるフェーズで牙を剥くことになるのです。
３．実務における要件：複雑な「立場」と「仕様」をどう制御するか
私たちが実務で扱う製品利用者用情報（Information for Use）の現場は、本連載で題材にしているシンプルなSP-Xシリーズとは比較にならないほど、複雑で緻密な要件に満ちています。製品のライフサイクルに伴って発生する定期メンテナンス、トラブルシューティング、さらには法的な規制や安全規格に基づく「有資格者による実施の限定」など、記述すべき細かい点が無数に存在するからです。
iiRDSが備える「標準メタデータ」と「独自拡張」のポテンシャル
こうした実務の複雑な要件をデジタルに管理・制御するために設計された国際標準規格が「iiRDS」です。iiRDSには、マニュアルの国際規格であるIEC/IEEE 82079-1の思想に基づいた、豊富な標準メタデータ（語彙）があらかじめ装備されています。例えば、情報の対象者を定義する FunctionalRole（オペレーター、サービス技術者など）や、製品のバリアントを識別する ProductVariant などがこれに該当します。
しかし、iiRDSの真の強みはそれだけではありません。標準の語彙（メタデータ）をベースにしつつ、各メーカーの製品特性や業務フローに合わせて「独自にメタデータを拡張・定義できる仕組み（拡張性）」を備えている点にあります。自社製品固有の特殊なオプション構成や、特定の国家資格、社内ライセンスといった要件であっても、iiRDSの構造を破ることなく、シームレスにデータへ焼き込むことができます。
「パーソナライズ」とは、情報を求める立場（コンテクスト）に沿うこと
このメタデータによって実現する「パーソナライズ」の本質とは、単に情報をオシャレに出し分けることではありません。「情報を求める『立場（コンテクスト）』に完全に寄り添い、その瞬間、その人にとって適切な情報だけを届けること」です。
実務における「立場」の代表例として、以下のような異なるパーソナルな視点（コンテクスト）が挙げられます。
- 製品利用者（エンドユーザー／一般オペレーター）の立場
日常的な操作や、資格を必要としない軽微な清掃・点検手順を求めています。彼らにとって必要なのは、専門用語を排除した平易な記述であり、同時に「ここから先は触れてはならない」という安全上の境界線（エスカレーション基準）です。 - メンテナンス担当（有資格者／サービス技術者）の立場
特殊な工具の使用や、内部コンポーネントの分解・調整など、高度で危険を伴う作業手順を求めています。彼らに必要なのは、詳細な仕様値、図面、エラーコード別の回路図であり、オペレーター向けの初歩的な操作説明はむしろノイズになります。
伝わる情報を設計するために：もう一つの決定的な項目「仕様との掛け合わせ」
ここで、実務をより強固に統治するために見落としてはならない決定的なポイントがあります。それは、人間の「立場（ロール）」と、製品の「仕様（バリアント・オプション）」は、常にクロス（掛け合わせ）で発生するという事実です。
現場では、「サービス技術者」という立場であっても、「標準モデル（SP-X100）」を触っているのか、「耐薬品モデル（SP-X200）」を触っているのか、あるいは「特定のオプション製品」が搭載されているのかによって、準備すべき工具も、安全警告の重みも完全に変わります。
「誰が（Subject）」×「どの仕様を（Object）」という直交する2つの条件に対して、矛盾なく、ピンポイントで正しい情報だけを抽出する。これが、AI時代のマニュアル（AEOデータ基盤）に課された究極の実務要件なのです。
では、私たちが5月号で完成させた「最強のV3データ」は、この「立場×仕様」という複数の条件を掛け合わせた高度な要求に対して、どのように振る舞うのでしょうか。いよいよ運命の実証実験へと進みます。
４．実験：属性の掛け合わせに挑む「高度なパーソナライズ・テスト」
データ側に施された「機種ごとのコンポーネント化」と「パンくずリスト（住所）の焼き込み」により、5月号の検証で驚異的な正答率を叩き出したV3データ。このデータセットを使い、第3章で定義した実務の過酷な要求 ――「立場（ロール）× 仕様（仕様・属性）」を掛け合わせたパーソナライズが、一般的なAI（ベースRAG環境）へのクエリ制御だけでどこまで実現できるかの検証に挑みます。実験では、２章で示したV3データ（資料２）をGoogle NotebookLMに投入し、クエリを実行しました。
テストするのは、単一のキーワード検索では絶対に到達できない、複数の条件を論理的に掛け合わせる「高度なパーソナライズ・クエリ」です。実務における「有資格者が、特定モデルの作業を安全に行うための事前準備」を想定した、以下のクエリをAIに投入しました。
クエリに仕掛けられた「直交する条件」の罠
この短い質問には、AIの推論能力とデータの構造を厳しく見定めるための「属性の掛け合わせ」が仕掛けられています。
元データであるV3データ（資料２）を見れば分かる通り、SP-X200の交換に必要な品目には「交換用フィルター（FLT-X200）」「Oリング（OR-S25）」「5mmの六角レンチ」「トルクレンチ」「セラミック製スパナ」などが並んでいます。しかし、この中から「安全のために（Safety）」という条件を満たす「消耗品（Supply）」、すなわち薬液ハザードを防ぐための『耐薬品手袋』や『保護メガネ』、そして交換用の『Oリング』だけをピンポイントで仕分け、正確に抽出できるかどうかがこの実験の焦点です。
５．衝撃の結果：なぜ「最強のV3」は沈黙したのか？
実験の結果は、私たちの予想を裏切る、極めて衝撃的なものでした。 5月号であれほど高精度な回答を出力し、ハルシネーションを力強くねじ伏せていたはずのV3データ（9チャンク）が、この質問に対してシステムは回答できませんでした。まさかのフリーズ（沈黙）を選択したのです。
「完璧にチューニングしたはずのV3データで、なぜAIは正解を抽出できなかったのか」。テクニカル・ポストモーテム（事後解析）によって浮かび上がったのは、情報設計の領域における致命的な構造矛盾、すなわち「インピーダンス・ミスマッチ」の罠でした。
V3が抱えていた「構造的な矛盾」の解剖
V3データが敗北した原因は、ベクトル検索でAIが文脈を見失わないようにするために施した、あの「戦略的パッキング（情報の物理的結合）」そのものにありました。
- V3の設計（パッキング）： V3は、AIが手順を読み飛ばさないよう、「安全警告（Safety）」と「作業手順（Task）」を物理的に1つのチャンク（Topic-005など）の中に結合（非正規化）していました。これは、言葉の近似値を多次元空間上で探すベクトル検索において、文脈を保護するための現時点でのベストプラクティスでした。
- クエリが求めた論理（直交性）： しかし、今回のパーソナライズ・クエリがAIに要求したのは、「安全」かつ「消耗品」という、大きな塊から特定の属性だけを綺麗にハサミで切り出すような、高度な論理的切り分け（直交性）でした。
【V3データの物理構造】
［ ひとつの大きなチャンク ］
┣ 安全警告（耐薬品手袋・保護メガネ）
┗ 作業手順（六角レンチでボルトを緩める…）
▲ 物理的に強固に結合されている
【クエリが求めた論理演算】
「安全」 × 「消耗品」 だけをピンポイントで抽出せよ
❌ AIは大きな塊から属性を分離できず、推論エンジンが迷走（フリーズ）
高度な絞り込み（パーソナライズ）の要求が「論理的な切り分け」を求めているのに対し、データ側は検索のために「物理的に結合（パッキング）」されている。このデータ構造と要求される論理の致命的なズレ（インピーダンス・ミスマッチ）は、AIの推論エンジンを激しく迷走させ、最終的に「回答不可」という最悪のフリーズを招いたのです。
DITA/CCMS導入企業への警鐘：その「注記」がAIの推論を破壊する
この実験結果（高度なパーソナライズでのフリーズ）が示唆するものは、単に「実験用データが動かなかった」というレベルの不具合ではありません。すでにDITAやCCMSを導入し、先進的にトピック指向ライティングを実践している企業にこそ、極めて重大なパラドックスを突きつけています。
コンポーネント管理が徹底されている現場であっても、1つのトピック（仕様や手順の最小単位）を覗いてみると、人間が読むための「※ただし、〇〇型番の場合は〜」「例外として、寒冷地仕様では〜」といった例外ルールや人間向けの注記が同じテキストの塊の中に同居しているケースは日常茶飯事です。
人間が読む分には、前後の文脈から「自分には関係ない例外だな」と自然に読み飛ばすことができます。しかし、そのように塊となっているデータをそのままRAGに投入すると、AIは高確率で条件を混同し、ハルシネーション（情報の越境）を起こす温床になります。さらに最悪なのは、今回の実験のように「特定の型番の、特定の例外だけを抽出せよ」という高度な掛け合わせ演算を命じられた瞬間、AIは塊の中から属性を分離できなくなり、完全にフリーズしてしまうという事実です。
「目的」が変われば、昨日の最適解は今日の障害物になる
ここで私たちが直視しなければならないのは、「パッケージング（情報をまとめること）は、目的によっては最適解になるが、状況が変われば推論の障害（ゴミ）にしかならない」という情報設計の冷徹な現実です。
- 単なる文脈の保護を目的とする場合（V3）：
言葉の近似値を探す不完全なベクトル空間において、AIに文脈を見失わせないためには、安全警告や前提条件を手順に物理的に結合するパッケージング（非正規化）が間違いなく最適解でした。 - 高度な利活用（パーソナライズ）を目的とする場合（V4へ）：
しかし、ユーザーの「立場」や「仕様」に合わせて、1,000ページから必要な10ページだけをピンポイントで出し分けるという目的においては、その物理的な結合こそがAIの思考を縛る「足枷」へと反転します。
情報が1つの塊にパッキングされている限り、AIはその中の特定の属性だけを論理的に選別することができません。昨日の「文脈を守るための美しいお弁当箱（V3）」は、高度なパーソナライズという次なる戦場においては、情報の純度を汚染するノイズの塊へと姿を変えてしまうのです。
６．結論：住所（Location）から関係性（Logic）へ
ベクトル検索を支えるために施したパッケージング（V3）を、私たちは今、自らの手で解体しなければならない局面に立たされています。
AIにハルシネーションを起こさせず、かつフリーズもさせずに、ユーザーの立場に完全に寄り添った「あなた専用マニュアル」を動的にデリバリーする。この情報活用のゴールを達成するための黄金律は、極めてシンプルなものでした。
「コンテンツの物理的な粒度は、抽出したい属性の粒度と1対1で一致していなければならない。」
データ構造が物理的に結合されているならば、AIの高度な論理演算は機能しません。ならば、取るべき道は一つです。人間向けの注記や例外ルール、安全警告といったすべての情報要素を極限まで分離・独立させ、1つのトピックには1つの属性しか存在させないレベルまで徹底的に純化する。これこそが、本連載が次なるステージとして提示する「iiRDS Atomic Data（情報の原子化）」への原点回帰の正体です。
バラバラに砕かれた「原子」をどう統治するのか
しかし、ここで設計・開発のプロフェッショナルである読者の皆さまは、当然の疑問を抱かれるはずです。 「情報をそこまでバラバラの原子に砕いてしまったら、それこそAIは行間を読めなくなり、文脈を見失って砂漠で迷子になるのではないか？」
その通りです。ただ原子化しただけでは、RAGは機能しません。 だからこそ、バラバラになった「点（アトミック・データ）」を、絶対に外れない強固な「線（論理のレール）」で繋ぎ合わせるための新しいインフラが必要になります。
次号（8月号）では、欧州がインダストリー4.0の核心として策定した最新のAI向け規格「DIN SPEC 91526」をベースに、情報の「住所（Location）」による管理を卒業し、確信的な「繋がり（Graph）」によってAIの挙動を100%制御する「V4：ナレッジグラフ・アーキテクチャ」の実証レポートをお送りします。
ベクトルの確率論（曖昧な引力）を、グラフの論理（構造的インターロック）がいかにしてねじ伏せ、製造業が求める「絶対に嘘をつかない、安全に沈黙できるAI」を創り出すのか。マニュアルの定義そのものを変える旅路を、どうぞ楽しみにお待ちください。
＜終わりー 情報の「活用」が牙を剥く―パーソナライズの壁と情報の原子化＞
