情報が増えたときの整理を考える—シソーラス・タクソノミー・オントロジー

要点 呼び方の揺れにはシソーラス、置き場所の迷いにはタクソノミーが役立ちます 複数の情報がどう関係するかまで扱うなら、オントロジーを検討できます すべてを整えず、目の前の困りごとに合う方法から小さく始められます Slackで共有された仕様を探し、Notionの議事録とFigmaの画面を見比べ、GitHubのIssueで変更の経緯をたどる。情報は揃っているのに、呼び方や置き場所が違うだけで確認に時間がかかることがあります。そんな状況を整理する手がかりとして、シソーラス・タクソノミー・オントロジーという3つの考え方を眺めてみます。 情報の量だけでなく、整理の基準にも目を向ける 情報過多というと、保存する量を減らすことに目が向きがちです。ただ、同じものが違う名前で呼ばれ、保存場所が人によって変わり、情報同士の関係も見えにくいことが負担になっている場合があります。 同じ「ユーザー」という言葉でも、仕様書ではサービスの利用者、データモデルではログイン済みのアカウントを指しているかもしれません。反対に、「モーダル」「ダイアログ」「ポップアップ」のように、違う言葉で同じ画面を指していることもあります。認識を揃えないまま設計と実装が進み、後から齟齬が分かって仕様変更になった経験もあるかもしれません。 言葉と分類と関係を整理することは、情報を探しやすくするだけでなく、こうした手戻りを減らす助けにもなりそうです。3つの考え方は、それぞれ次の役割を担います。 シソーラス：言葉を揃える タクソノミー：置き場所を決める オントロジー：意味のつながりを記述する シソーラス：呼び方を揃える シソーラスは、言葉同士の関係を整理した語彙集です。同じ意味の言葉を代表語にまとめるほか、上位語・下位語や関連語も記録します。 たとえば、チーム内で同じUIを「ダイアログ」「モーダル」と呼んでいるなら、代表語を一つ決め、もう一方を同義語として結び付けられます。「オーバーレイ」を上位語、「ドロワー」を関連語として扱うこともできます。仕様書とデザインシステムで表記が違っていても、同じ情報へたどり着きやすくなるでしょう。 タグの表記揺れを抑えたいときや、社内検索で資料の取りこぼしを減らしたいときに使いやすい方法です。よく使うUI用語を一覧にして、代表語・同義語・関連語を記録するだけでも、小さなシソーラスになります。 教育文献データベースのERICでは、シソーラスの統制語を各文献に付与しています。「Indexing」には同じ検索先へ導く語や上位語、関連語がまとめられ、表現が異なる文献も共通の語彙から探せます（ ERIC Thesaurus ）。 タクソノミー：置き場所を決める タクソノミーは、情報を一定の基準で分類し、主に階層として整理する仕組みです。たとえばデザインシステムなら、「基礎」の下に「色」「余白」「文字」、「コンポーネント」の下に「入力」「ナビゲーション」「フィードバック」を置く、といった構造が考えられます。 上位の分類から下位へたどれるため、情報の全体像を見渡しやすくなります。ドキュメント、社内Wiki、デザインシステムなど、共通の置き場所を用意したい場面に向いています。 一方で、複数の軸を一つの階層へ押し込むと、迷いが生まれることもあります。「エラー表示付きの入力フォーム」は、「入力」と「フィードバック」のどちらにも置けそうです。この場合は主となる分類軸を一つ選び、ほかの軸をタグで補う方法もあります。 Google Merchant Centerでは、商品を「Apparel & Accessories > Clothing > Outerwear」のように、大きな分類から具体的な分類へ配置します。独自の商品名でも共通の階層に対応させることで、商品群の整理や広告運用の軸として使えます（ Google Merchant Centerの商品データ仕様 ）。 オントロジー：意味のつながりを記述する オントロジーは、ある領域に存在するものの種類、性質、関係、必要に応じて制約を明示したモデルです。単に「近い言葉」「同じカテゴリ」として結ぶだけでなく、何と何が、どのような意味で関係しているかを表します。 たとえば、「機能」「画面」「コンポーネント」「API」「Issue」という種類を定義し、「画面は機能を提供する」「画面はコンポーネントを使う」「機能はAPIに依存する」「Issueは機能を変更する」といった関係を記述できます。すると、「このAPIの変更で影響を受ける画面と関連Issue」のような、複数の関係をたどる問いにも答えやすくなります。 Schema.orgには「Person」「Event」「Product」などの型と属性が定義されています。Webページの情報を意味のある