トリセツ制作者のためのiiRDS実践ガイド
(2)器のラベル：「どんなドキュメント」で「どんなトピック」か？
前回の記事では、AIが「推測」で嘘をつくのを防ぎ、情報の正解をピンポイントで見つけ出す「確定検索」を実現するためのラベル（メタデータ）の重要性についてお伝えしました。今回は、iiRDS（IEC PAS 63485）が定義する膨大な語彙の中でも、最も基本的であり、かつDITAユーザーにとって馴染みの深い 「情報の器（ドキュメントとトピック）」 を分類するラベルについて解説します。
「文書全体」と「情報の最小単位」を定義する
iiRDSでは、マニュアルという「一冊の器」と、その中に含まれる「個別の記事（トピック）」の両方にラベルを貼ることで、AIやシステムが情報の階層と役割を正しく理解できるようにします。公式ガイドライン「Guide for the Standardized Use of iiRDS」では、実務で頻出する主要な語彙が厳選されています。まずはこれらを知ることで、既存のマニュアルをiiRDS対応へと引き上げる具体的なイメージが湧くはずです。
1. 文書全体のラベル（iiRDS Document Types）
まずは、マニュアル一冊が「そもそも何のための本か」を定義するラベルです。ガイドでは、以下の5つが主要な語彙として挙げられています。
| iiRDS語彙（Label） | 役割・対象 | 境界線のポイント（迷いやすい点） |
|---|---|---|
| OperatingInstructions | 一般的な「操作説明書」 | AdministratorGuide（専門家向け）とは明確に区別されます。 |
| MaintenanceInstructions | 保守・点検・清掃の手順書 | 修理だけでなく、日常的な「維持」活動も含まれます。 |
| AdministratorGuide | 管理者・IT担当者用ガイド | 一般ユーザーが触れないシステム構成や管理に特化したものです。 |
| AssemblyInstructions | 組み立て説明書 | 製品を物理的に組み上げるプロセスのみを指します。 |
| InstallationInstructions | 据付・設置ガイド | 物理的な設置や、システムへの組み込み手順を指します。 |
2. トピック単位のラベル（iiRDS Topic Types）
次に、細分化された各トピック（情報の断片）が「どんな疑問に答えるものか」を定義するラベルです。DITAを利用している方なら、見覚えのある名前が並んでいることに気づくはずです 。
| iiRDSトピック型 (Label) | 日本語訳 | 説明・役割 |
|---|---|---|
| GenericConcept | 概念 | 「これは何か」「なぜ必要か」という仕組みや背景を説明する。 |
| GenericTask | タスク | 「どうやって行うか」という具体的な操作手順を示す。 |
| GenericReference | 参照 | 仕様表やエラーコードなど、特定の値を「調べる」ための情報。 |
| GenericTroubleshooting | トラブル解決 | 「問題が起きた時にどう直すか」という、症状・原因・対策を示す。 |
| GenericForm | フォーム | サービスレポートなど、決まった入力項目を持つ情報。 |
| GenericLearning | 学習 | 学習目標やテストなど、教育を目的としたコンテンツ。 |
iiRDS公式ガイドの真骨頂：迷いを断ち切る境界線
iiRDSを実務に導入する際、現場で最も迷うのは「このトピックはTaskなのか、それともMaintenanceなのか？」といった分類の境界線です。
公式ガイドの「真骨頂」とも言えるのが、各語彙に用意されている 「何ではないか（What it is not）」 という解説です。 例えば、操作説明書（OperatingInstructions） の解説には、「管理者ガイド（AdministratorGuide）ではない」と明記されています。前者は「一般ユーザーが安全に使うため」のものであり、後者は「権限を持つ専門家がシステムを構成するため」のもの、という明確な定義があるため、迷わずにラベルを選択できます。
また、GenericTask（手順）と GenericTroubleshooting（トラブル解決）も明確に区別されます。単なる順次操作ではなく、「異常な状態」から「正常な状態」へ戻すための判断基準や原因の特定が含まれる場合は、後者を選択すべきです。この境界線を意識するだけで、AIに対しても「この情報はトラブル時のみ提示する」といった高度な制御（確定検索）を行わせるための強力なエビデンスになります。
自社マニュアルの「適合性」をチェックしてみませんか？
今回の記事で紹介した11個の語彙を使って、皆さんのマニュアルがiiRDSにどうマッピングできるか、まずは頭の中で「フィット感」を確かめてみてください。
- 器の判定（Step 1）
- 制作中のマニュアルは、上の5つの「ドキュメント型」のどれに最も近いですか？
- 複数の役割（例：操作と保守）が混ざっている場合、iiRDS化によって「ターゲット別の切り出し」ができる大きな改善ポイントになります。
- 情報の仕分け（Step 2）
- 目次を見ながら、各章が6つの「トピック型」のどれに該当するか当てはめてみましょう。
- 分類しにくい「雑多な情報の塊」がある場合、そこがAIにとっての「迷いどころ」になっている可能性があります。
- 「境界線」の再定義（Step 3）
- 公式ガイドの What it is not セクションを参考に、特に「Task」と「Troubleshooting」の定義が混同されていないか再確認してみてください。情報の役割がシャープに整理されるはずです。
テクニカルひとくちメモ
- ラベルと配信の連携：
iiRDSのラベルは、実際にパッケージングする際にRDF（リソース・ディスクリプション・フレームワーク）形式などで埋め込まれます。 - トピック型の柔軟性：
ドキュメント全体をOperatingInstructionsと定義したからといって、中のトピックすべてがTaskである必要はありません。操作マニュアルの中に、仕様表（Reference）や概念説明（Concept）が含まれるのは自然なことであり、iiRDSはそれをトピック単位で精密に識別します。
次回予告
次回からは、情報の「中身」をより詳細に定義する「情報主体（Information Subjects）」などのラベルについて詳しく見ていきます。
参考資料：iiRDSコンソーシアム公式ガイドライン
「Guide for the Standardized Use of iiRDS」について
本連載は、iiRDSコンソーシアムが2025年10月に公開したレポート 「Guide for the Standardized Use of iiRDS」 をベースに解説しています。
このレポートは、メタデータの定義だけでなく、「目的」「対象読者」「具体例」、そして「そのタグを使ってはいけないケース（What it is not）」までが網羅された、まさに実務者のためのバイブルです。 このような極めて実践的で価値の高いガイドラインをまとめ上げられたiiRDSコンソーシアムのワーキンググループ、およびコントリビューターの皆様に深く感謝申し上げます。
本連載で興味を持たれた方は、ぜひ以下の公式サイトからレポート（PDF）をダウンロードし、一次情報に触れてみてください。AI時代のメタデータ設計の強力な道標となるはずです。
