トリセツ制作者のためのiiRDS実践ガイド
(5)行動のラベル：「誰が」「どれくらい時間をかけて」やるのか？
これまで、情報の役割（第2回）、主題（第3回）、そして場所と時間（第4回）という、情報そのものを定義するラベルについて解説してきました。しかし、マニュアルの究極の目的は「読者に正しく行動してもらうこと」にあります。
同じ「メンテナンス手順」でも、熟練のエンジニアが必要とする情報と、初めて製品に触れるユーザーが求める情報は異なります。また、現場のマネージャーにとっては「その作業にどれくらいの時間がかかるのか」という付帯情報も極めて重要です。
第5回では、情報の「利用者」や「作業の背景」を定義する 「ファンクショナル・メタデータ（Functional Metadata）」 の活用術を紐解きます。
「人」と「状況」に寄り添うファンクショナル・メタデータ
ファンクショナル・メタデータとは、その名の通り「機能的・実用的」な付加情報のことです。これを活用することで、AIや配信システムは「誰に」「どんな状況で」その情報を提示すべきかを判断できるようになります。
公式ガイド「Guide for the Standardized Use of iiRDS」では、特に以下の3つの軸が重要視されています。
1. 誰がやるのか：資格と役割（Qualification / Role）
作業者のスキルレベルや職種を定義します。
- Role（役割）: サービス技術者、オペレーター、管理者など。
- Skill Level（スキルレベル）: 初級、中級、熟練者など。
これらをラベル付けすることで、「新人オペレーターには詳細な図解入りの手順を、熟練技術者には要点のみのチェックリストを提示する」といった、ユーザー属性に応じたダイナミックな情報の出し分けが可能になります。
2. どれくらいかかるのか：想定時間（PlanningTime）
作業にかかる見積もり時間（WorkingTime）を定義します。
- WorkingTime（作業時間）: 「5分」「2時間」など。
工場の稼働計画を立てる際、AIが「このメンテナンスには2時間かかります。今の休止時間内に完了可能です」とアドバイスできるのは、このラベルがあるからです。
3. 何を使うのか：道具と予備部品（Tool / SparePart）
作業に必要な持ち物を定義します。
- Tool（工具）: トルクレンチ、専用診断ソフトなど。
- SparePart（予備部品）: 交換用フィルター、Oリングなど。
作業現場に到着してから「道具が足りない」と気づくロスをなくし、AIが「出発前にこれらを準備してください」とナビゲートするための重要なデータになります。
公式ガイドの真骨頂：「Action」と「Event」の境界線
実務で非常に迷いやすいのが、「何が起きたか（Event）」と「何をするか（Action）」の使い分けです。公式ガイドの What it is not セクションではここを鮮やかに整理しています。
- GenericEvent（イベント）: 「エラーコード E01 が表示された」「異音がする」といった、情報の 「トリガー（きっかけ）」 を指します。
- GenericAction（アクション）: 「清掃する」「交換する」「校正する」といった、情報の 「目的となる動作」 を指します。
この2つを明確に区別してラベル付けすることで、AIは「異音（イベント）が発生した」というユーザーの訴えに対し、「それは清掃（アクション）が必要なタイミングですね」と、文脈を正確に繋いで回答できるようになります。
「行動のラベル」がマニュアルのUXを変える
ファンクショナル・メタデータは、単なる情報の整理術ではありません。
「今、目の前のユーザーが、どんな道具を持って、何分で作業を終えたいのか」という現場のリアリティに、マニュアルを適応させるための仕組みです。
これらを付与することで、マニュアルは単なる「読み物」から、ユーザーの行動を最適化する「パーソナルなアシスタント」へと進化します。
自社マニュアルを、改めて「ユーザーの視点」で見直してみませんか？
今回のラベルを使って、皆さんのマニュアルが「誰の、どんな行動」を想定しているか、セルフチェックしてみましょう。
- ペルソナのマッピング
- 各トピックは、具体的に「誰（Role）」に向けて書かれていますか？ 複数の役割が混在して、読みづらくなっていないでしょうか。
- 作業時間の見積もり
- 手順の冒頭に「想定作業時間」を記載できるトピックはありますか？ もしあれば、それを
PlanningTimeとしてラベル化する準備をしてみましょう。
- 手順の冒頭に「想定作業時間」を記載できるトピックはありますか？ もしあれば、それを
- トリガーの整理
- ユーザーがその情報を探す「きっかけ（Event）」は何ですか？ エラーコードや症状を、AIが認識しやすい形で整理できているか確認してみてください。
テクニカルひとくちメモ
- iirds:FunctionalMetadata クラス: iiRDSのRDF構造では、これらは
iirds:FunctionalMetadataというクラスの下にまとめられています。 - 拡張性:
Qualification（資格）などは、各国の公的資格や社内規定のスキルレベルに合わせて、名前空間（my:など）を使い分けることで柔軟に拡張可能です。
次回予告：
これまで5回にわたり、iiRDSの主要なラベルとその設計思想を学んできました。しかし、皆さんの頭には一つの大きな疑問が浮かんでいるはずです。
「これ、全部手作業でタグ付けしなきゃいけないの？」
最終回となる第6回では、この膨大な作業を効率化する 「生成AIを活用した自動タグ付け」 の可能性と、これからのTC（テクニカルコミュニケーター）に求められる役割についてお話しします。未来のトリセツ制作の姿を、一緒に覗いてみましょう。
参考資料：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時代のメタデータ設計の強力な道標となるはずです。
