AI時代のマニュアル制作—AIが使える情報構造をどう作るか – Arkanos Insights

AIを使ってマニュアルからFAQを作る。社内の問い合わせに答える。複数の資料を横断して、必要な情報を探す。こうした活用を考えるとき、まずAIの性能や検索の仕組みに目が向きがちです。

しかし、その前に考えたいことがあります。AIが参照する情報は、「何について書かれた、いつの、どの版の情報か」を判別できる状態になっているでしょうか。

正しい文章でも、対象を取り違えれば誤答になる

ある操作について、旧モデルと新モデルで手順が異なるとします。どちらのマニュアルにも正しい説明が書かれていても、AIが旧モデルの手順を新モデルの利用者に案内すれば、回答は間違いです。

製品マニュアルには、型式、仕様、販売地域、言語、版など、情報の適用範囲があります。自動車なら車種や年式、家電なら型番の違いなどが分かりやすい例でしょう。AIに文章を検索させる際にも、こうした区別を保つ必要があります。

また、用語が揺れていたり、一つの説明に複数の条件が混在していたりすると、必要な箇所を探すこと自体も難しくなります。FAQ生成や問い合わせ対応に使うなら、文章の分かりやすさに加え、情報の粒度や前提条件も見直したいところです。

検索用に分割した情報を、元のマニュアルへ戻せるか

AI検索では、マニュアルを章やTopicなどの単位に分けて取り込むことがあります。そのとき本文だけを切り出すと、元のマニュアルでは分かっていた適用範囲や版、公開ページとの対応が失われるかもしれません。

回答に使った文章について、「どの製品・仕様に適用される、どの版の、どの箇所か」をたどれるでしょうか。さらに、その箇所を利用者が開けるページへ案内できるでしょうか。

図で重要なのは、AI検索用データと公開ページが、同じ内容を指していると確認できることです。ただし、識別子とURLを結べば十分というわけでもありません。AI検索用データの本文が、公開マニュアルと同じ適用条件で出力されているかも確かめる必要があります。

メタデータは、誰がどこで付けるのか

DITAでマニュアルを制作する場合、Bookmapには、そのマニュアルに適用される製品や仕様、版などの情報を持たせられます。一方、本文を構成するTopicは、複数のマニュアルから参照して流用することがあります。

たとえば、同じ操作説明のTopicを複数の製品マニュアルで使う場合、特定の製品名をTopicに直接持たせると、ほかのマニュアルで流用しにくくなります。マニュアルごとの適用情報を、共有Topicの編集者に毎回入力させる方法も、管理が複雑になりそうです。

そこで、Bookmapが持つ適用情報を出力時に取得し、そのBookmapから参照されたTopicの本文や識別子と組み合わせて、AI検索用データに付与する方法が考えられます。同じTopicでも、どのマニュアルから出力されたかによって、異なる適用情報を持つ検索用データとして扱う考え方です。元のTopicに製品ごとの情報を重複して入力する必要はありません。

もちろん、これは一つの設計案です。Topic内に条件分岐があれば、Bookmapの情報を一律に付けるだけでは、実際に出力された本文の適用範囲を表せない場合もあります。どの情報をBookmapやTopicで管理し、出力時にどう組み合わせるかは、AI開発側と制作・変換側で一緒に検討する必要があるでしょう。

入力ルールを決めたあと、運用を続けられるか

AI検索用データに必要なメタデータを列挙することと、それを制作現場で維持することは別の話です。項目を増やすたびに編集者や制作会社へ入力を依頼すれば、工数が増え、改訂時の更新漏れも起こりやすくなります。

そこで、まずは情報の出どころと、確認が必要な箇所を分けて考えたいところです。

情報	元になる場所・付け方	人が確認すること
マニュアルの製品・仕様・言語	Bookmapや制作管理システムから出力時に引き継ぐ	Bookmapの適用範囲が正しいか
版・公開状態	リリース管理情報から引き継ぐ	旧版をいつ通常検索から外すか
Topic ID・公開URL	変換処理で対応付ける	リンクが該当箇所を開くか
Topic内の条件分岐	出力条件に従って処理する	出力された本文と適用範囲が一致するか
説明の前提条件や例外	執筆時に内容を判断して記述する	切り出して読んでも誤解されないか

自動で付与できる情報でも、元情報の正しさまで自動で保証されるわけではありません。Bookmapの適用範囲が誤っていれば、そこから生成した検索用データにも誤りが広がります。一方、説明の例外条件のように、内容を理解しなければ判断できないことまで変換処理に任せるのも難しいでしょう。

編集者は何を判断し、制作管理側は何を確定し、変換処理では何を付与・検証するのか。入力作業だけでなく、確認と改訂の責任まで割り振って初めて、運用できるルールになります。

また、AIのために条件属性や記述ルールを変更する場合、影響はAI用データだけにとどまりません。既存のWebやPDF、多言語版の出力がどう変わるかも確認が必要です。

訂正した情報が、AIの回答にも反映されるか

たとえば、2026年8月にマニュアルの初版を公開し、誤記を訂正した２版を10月に公開したとします。２版のTopicを正しく修正しても、AIが初版と２版の両方を検索できる状態なら、訂正前の記述が回答に使われる可能性があります。

では、改訂時に何を更新すればよいのでしょうか。Topicの本文に加えて、Bookmapや制作管理側にある版・公開状態の情報も正しくなっているか。２版から生成したAI検索用データが、正しい適用情報と根拠リンクを持っているか。そして、初版を通常の回答対象から外せているか。これらは別々に確認する必要があります。

初版を履歴として残す業務もあるでしょう。その場合も、通常の利用者への回答では２版だけを参照し、過去版を明示的に指定した場合に限って初版を探せるようにする、といった区別が考えられます。

マニュアルを訂正したことと、AIが訂正後の情報だけを回答に使うことは、同じではありません。 公開・改訂の流れと、AIの検索対象を切り替える流れを、どうつなぐかが問われます。

小さく試し、回答と制作の両方を評価する

最初からマニュアル全体の設計を変えるより、対象を絞ったPoCから始めてはどうでしょうか。複数のマニュアルで流用するTopicや、条件によって出力内容が変わるTopicを選び、AI検索用データと既存のWeb・PDFなどを出力して比べます。

その際は、AIが答えられるかだけでなく、対象違いの情報を混ぜないか、回答の根拠を正しい公開ページで示せるか、既存の出力に影響がないかを確認します。さらに、Topicの誤記を修正して次の版を公開するところまで試せば、版情報の更新、旧版の除外、編集現場の負荷も見えてきます。

期待した回答が得られなかった場合も、検索や回答生成の問題なのか、元情報の構造や適用条件の問題なのかを切り分けられます。制作側とAI開発側が一緒に結果を見ることが大切です。

AIによる回答は、利用者が情報を探す手間を減らします。ただ、その手軽さを支えるには、回答の元になる情報を正しく作り、どの情報を回答に使ってよいかを改訂後も管理し続けることが必要です。

AIを導入すると決めたなら、情報設計と改訂運用は後回しにできません。マニュアルを「人が読むもの」として公開するだけでなく、「AIがどの情報を参照してよいか」まで含めて、制作側と開発側で考える必要があるのではないでしょうか。