HTMLが20年前に解いた問題を、あなたの組織はまだ解いていない

2000年代初頭、検索エンジンは困っていた。<div class="title">と書いてあっても、それがページの主題なのか広告の見出しなのか判断できなかった。テキストが多いページが「情報が豊富」だと誤解された。HTMLは視覚的なレイアウトのために設計されており、意味（セマンティクス）を持っていなかった。

この問題を解いたのがHTMLのセマンティックタグだ。<header>はページの導入部であることを宣言する。<article>は独立したコンテンツの単位であることを示す。<section>は意味のある章の区切りを作る。見た目ではなく、「これは何か」を機械に伝える構造が生まれた。

重要なのは、この変化の本質だ。セマンティックHTMLは、コンテンツを増やしたのではなく、既存のコンテンツに「意味の型」を与えた。

セマンティックHTMLでも足りなかった。「著者は誰か」「公開日はいつか」「これはレビューか、ハウツーか、商品情報か」——HTMLのタグ体系ではこれを表現する語彙が不足していた。

そこで登場したのがJSON-LD（Linked Data）だ。Schema.orgが定義する語彙を使い、ページの持つ意味をJSON形式で機械に伝える。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "author": {
    "@type": "Person",
    "name": "Koshiro Nakagami"
  },
  "datePublished": "2026-05-02",
  "headline": "記事のタイトル"
}

これは単なるメタデータではない。これはオントロジーだ。 Schema.orgが定義するBlogPosting、Person、Organizationは、概念と概念の関係を記述する語彙体系——すなわちオントロジーの語彙を使って、個別のページに意味を付与している。

@type: "BlogPosting"は「このコンテンツはブログ記事というカテゴリに属する」という宣言だ。authorは人物との関係を示す。publisherは組織との関係を示す。グラフ構造で意味が連鎖している。

Googleがリッチスニペット（星評価・FAQ表示・パンくずリスト）を検索結果に表示できるのは、この構造のおかげだ。機械は推測するのをやめ、構造を読むようになった。

20年のWeb進化が証明した設計原則がある。

原則1：意味は宣言しなければ伝わらない

<div class="important">は人間には通じるが機械には通じない。<h1>は通じる。JSON-LDの"@type": "FAQPage"は通じる。明示的な宣言だけが機械可読な意味を生む。

原則2：関係の型が意味を完成させる

「著者」と「ページ」の関係はauthorプロパティで型付けされる。「組織」と「ロゴ」の関係はlogoプロパティで型付けされる。型のない関係は機械にとって存在しないのと同じだ。

原則3：構造は後付けできない

構造を持たないコンテンツの山に後からタグを付けることは、書き終わった本に章番号を付け直すようなものだ。コンテンツを作る時点から、意味構造を設計する必要がある。

これらの原則は、Webに限った話ではない。

あなたの組織には、知識がある。製品の使い方を誰よりも知っているサポートスタッフ。市場の動きを体感しているセールス担当。ブランドの一貫性を守るためのルールを頭に入れているマーケター。

しかし、その知識に「タグ」はあるか？

「これは顧客対応のルールだ」「これは競合との差別化ポイントだ」「これはブランドの禁止ワードだ」——そういった意味の型付けがされているか？

おそらく答えはノーだ。多くの組織で、知識は以下のいずれかの形で存在している。

• Slackのチャンネルに散らばったメッセージ
• 誰かのドライブにある名前のないドキュメント
• ベテラン社員の記憶
• 更新が止まった社内Wiki

これは2000年代初頭のWebと同じ状態だ。コンテンツはあるが、機械が読める意味構造がない。

OS iXanagiはこの問題に対する答えとして設計されている。

WebがJSON-LDのために@typeやauthorやpublisherの語彙を持つように、OS iXanagiは組織知識のための意味語彙を持つ。それが7つのCore Domainだ。

Core Domain	意味の範疇
Demand	顧客の意図・問題・ニーズ
Commitment	戦略的立場・仮説・方針
Fulfillment	実行構造・ルーティング・配信
Value	提供価値・オファー
Financial	財務的コンテキスト
Relationship	ブランド・企業・顧客の関係
Insight	学習・成長・検証

「この知識はDemand Domainに属する」と宣言することは、HTMLで<article>と書くことと構造的に同じだ。それは「この意味オブジェクトは何か」を機械に伝える。

さらに、OS iXanagiは関係の型も持つ。parent_of、contains、derived_from、contextually_cites——これらはJSON-LDのauthorやpublisherと同じ役割を果たす。意味オブジェクト同士の関係を型付けすることで、知識がグラフとして連鎖する。

実際に対応を見ると、両者の設計思想が同一であることがわかる。

HTMLの概念	OS iXanagiの概念
<article>	Meaning Object（Draft, Knowledge, FAQ）
<section>	Section（意味の容器）
<header>	Brief（記事の導入・戦略的前提）
@type: "BlogPosting"	semantic_tags: ["copy"]
@type: "FAQPage"	semantic_tags: ["question"]
author プロパティ	derived_from リレーション
breadcrumb リスト	parent_of 関係チェーン
canonical URL	group_key（locale非依存の意味の同一性）

特に重要なのはcanonicalとOS iXanagiのgroup_keyの対応だ。

HTMLのcanonicalタグは「日本語版と英語版は同一の概念を表す異なる表現だ」と宣言する。OS iXanagiのgroup_keyは同じことを意味する——group_keyは言語を超えた「意味の同一性」を表す識別子だ。同じ概念を日本語と英語で記述した2つのMeaning Objectは、同一のgroup_keyを持ち、知識グラフの中で1つのノードとして扱われる。

なぜ今、これが重要なのか。

Googleのクローラーが「意味構造のないHTML」を読めなかったように、AIエージェントは「意味構造のない組織知識」を正確に活用できない。

AIに「このブランドの禁止ワードは何か」と聞いて正確な答えが返ってくるためには、禁止ワードが「Brand ProfileのRelationship Domainに属する制約オブジェクト」として構造化されている必要がある。AIに「競合との差別化ポイントを踏まえてコピーを書いて」と指示するためには、差別化ポイントがCommitment DomainのStrategic Thesisとして登録されている必要がある。

OS iXanagiのKnowledge Engineは、この「機械可読な組織知識」の単一の真実（Source of Truth）として機能する。Marketing AppがコピーをWebsiteに送る時も、Support AppがFAQを更新する時も、AIエージェントがコンテンツを生成する時も、全員が同じontology_dbにある意味オブジェクトを参照する。

これがCompound Intelligenceの核心だ。知識が構造化されるほど、全てのAIアクションの品質が上がる。Web版のJSON-LDが「一度構造化すればGoogleがリッチスニペットを表示してくれる」という恩恵をもたらしたように、OS iXanagiで「一度構造化された知識」は全てのAppsとAIエージェントを同時に賢くする。

HTMLのセマンティックマークアップは、技術者が自分たちのために作ったものではなかった。検索エンジンというAIが組織のコンテンツを正確に理解できるように、人間側が構造を与える作業だった。

その作業を「Webページ」の次元に留めたままでいる必要はない。顧客への応答方法、製品の差別化ポイント、ブランドの声のトーン——これら全てが今や、AIエージェントに処理される対象だ。構造がなければ、AIは推測するしかない。そして推測するAIは、あなたの組織が20年かけて蓄積した文脈を毎回ゼロから作り直す。

JSONが@type: "BlogPosting"と宣言するように、あなたの組織は「これは何の知識か」を宣言できているか。その答えが組織のAI対応力の全てを決める。