「ページ」という概念を分解する
ウェブサイトの1ページは、何でできているのか。
多くの CMS はこう答えます。「タイトルと、本文と、画像と、メタデータ」。WordPress なら wp_posts テーブルの1行。Notion ならブロックの縦積み。どちらも「ページ = コンテンツの入れ物」という前提に立っています。
この前提は、一見正しく見えます。しかし、ある問いを立てた瞬間に破綻します。
「同じ意味を、別の場所でも使いたい」
たとえば、あるブログ記事で「fail-closed とは、判断できないなら止まるという原則である」と説明したとします。この説明は、製品ページのアーキテクチャ解説にも、FAQ ページにも、営業資料にも、同じ文脈で必要になります。
WordPress ならコピー＆ペーストです。5箇所に同じ文章が散らばり、1箇所を修正しても残り4箇所は古いまま。Notion でもリンクドデータベースで部分的に対処できますが、構造的な解決ではありません。
問題の根源は「ページの中にコンテンツが閉じ込められている」ことです。
目次全 6 章
器と中身を分離する
OS iXanagi はこの問題を、構造的に解決します。
原則はひとつ。器（構造）と中身（意味）を完全に分離する。
「器」とは、ページ上のレイアウト構造のことです。ヒーローセクション、3カラムの特徴紹介、FAQ のアコーディオン、CTA バナー。これらは「意味をどう配置するか」のパターンであり、意味そのものではありません。OS iXanagi ではこれを Structure Object と呼びます。
「中身」とは、実際の意味内容のことです。説明文、知識、よくある質問、行動喚起。OS iXanagi ではこれを Meaning Object と呼びます。
そして両者を接続するのが Relation（関係）です。「この器に、この中身を、この役割で配置する」という明示的な接続。
器（Section）──関係（Relation）──→ 中身（Meaning Object）
この3つは常に独立しています。だから、同じ Meaning Object を異なる器に配置できる。同じ器に異なる Meaning Object を入れ替えられる。意味は一つ、配置は自由。
ブログ記事で見る具体例
この原則がブログ記事でどう機能するか。実際に見てみます。
記事「AIに知識を与えても、AIは統治されない」を OS iXanagi で構造化すると、まず器の階層ができます。
article_container（記事全体の器）
├── article_chapter（第1章の器）
├── article_chapter（第2章の器）
│ ├── article_section（第2章第1節の器）
│ ├── article_section（第2章第2節の器）
│ └── article_section（第2章第3節の器）
├── article_chapter（第3章の器）
└── cta_band（末尾の行動喚起の器）
これは入れ子構造です。article_container の中に article_chapter があり、その中に article_section がある。HTML の <article> → <section> → <section> に対応します。
しかし、ここには「意味」がまだ何もありません。あるのは空の器だけです。
次に、意味を器に接続します。
article_chapter「AIの三権分立」
│
├── labeled_by → 「AIの三権分立という発想」（copy — 章タイトル）
├── contains → 「fail-closed の定義」（knowledge — 再利用可能な知識）
└── text_block
└── labeled_by → 立法・行政・司法の説明（copy — 本文）
labeled_by は「この器の見出しを供給する」という関係です。contains は「この器の中身として配置する」という関係です。関係の型が明示されているから、AI もこの構造を正確に理解できます。
そして重要なのは、「fail-closed の定義」という Knowledge Object は、この記事のためだけに存在しているのではないということです。この同じオブジェクトが、製品ページの pillar_grid にも、FAQ ページの faq_list にも参照されます。器が変わっても、意味は同一のものです。
粒度の判断基準 — 何を独立させ、何をまとめるか
器と中身を分離すると、次の問いが生まれます。「どこまで細かく分けるのか？」
段落ごとに Meaning Object を作るのか。文ごとか。単語ごとか。答えは「意味の再利用境界で分ける」です。
判断基準は3つあります。
この記事以外でも参照されるか。 「fail-closed とは判断できないなら止まる原則である」は、サイト全体で繰り返し使われる知識です。独立した Knowledge Object にします。一方、「人間社会に置き換えてみてください」という導入の比喩は、この記事固有のストーリーテリングです。章単位の copy Object の中に含めます。
Knowledge App に登録すべき概念か。 企業全体の知識資産として管理されるべき概念なら、独立させます。「AI の三権分立：立法 = Knowledge App、行政 = Kernel、司法 = Obligation」は、この企業のコア思想です。記事に埋もれさせず、Knowledge Object として独立管理します。
日本語版と英語版で独立した構成が必要か。 Meaning Object を細かくしすぎると、locale adaptation（文化適応）の自由度が下がります。章単位の copy Object にしておけば、日本語と英語で異なるナラティブ構成が可能です。
この3基準で判断すれば、記事が100本になっても粒度で迷うことはありません。
なぜ CMS はこの構造を持たないのか
WordPress も Notion も Contentful も、「器と中身の分離」を部分的には実現しています。コンポーネント化、ブロックエディタ、参照フィールド。しかし、いずれも「ページの中にコンテンツがある」という前提を完全には捨てていません。
OS iXanagi が異なるのは、そもそもの設計思想が逆だからです。
従来の CMS は「ページ」を起点に設計しています。ページがあり、その中にコンテンツがある。コンテンツはページに従属します。
OS iXanagi は「意味」を起点に設計しています。Meaning Object がまず存在し、それが Route（URL）と Projection（描画設計）と Section（配置構造）によって、特定の場所に表出する。意味が先で、ページは後です。
この逆転があるから、同じ Knowledge Object「fail-closed の定義」を修正すれば、それを参照しているブログ記事も、製品ページも、FAQ ページも、すべてが一箇所の修正で更新されます。コピー＆ペーストは発生しません。意味の一貫性が構造的に保証されます。
器にもルールがある
器は自由に組み合わせられるわけではありません。
article_container の中に article_chapter は入りますが、article_chapter の中に article_container は入りません。text_block はどこにも子を持てません。これらのルールは、OS iXanagi のプラットフォーム層で定義されています。
入れ子可能かどうか（nestable）。最大深度はいくつか（max_depth）。どの子を許すか（allowed_children）。これらがすべて明示的に定義されているから、AI が記事構造を生成するときも「章の中に記事全体を入れる」といった構造破壊を起こしません。
これは1本目の記事で書いた「統治」の具体例でもあります。AI に「ブログ記事を書いて」と頼むとき、意味の構造にもルールがある。そのルールが enforce される。だから安全に自動化できる。
ページから意味へ — 設計の転換点
「ブログ記事を作る」
この一言を起点に、私たちが辿った思考は以下のようなものでした。
まず「専用テーブルを作るか、既存の構造で受け止めるか」を判断しました。答えは後者でした。ブログ記事は特別なものではなく、Route + Projection + Section + Meaning Object で表現できる、OS iXanagi にとっての「もう一つのページ」です。
次に「どの粒度で Meaning Object を切るか」を考えました。再利用境界で切る。Knowledge App に入る概念は独立させ、記事固有のナラティブは章単位でまとめる。
そして最後に「器の入れ子構造はどう制御するか」を確認しました。プラットフォーム定義で nestable / max_depth / allowed_children が決まっている。AI も人間もこのルールに従う。
この一連の思考プロセスそのものが、OS iXanagi の設計思想を体現しています。
機能から始めない。意味から始める。 ページを作るのではなく、意味を構造化する。 構造にはルールがあり、ルールは enforce される。
これが OS iXanagi の「器と中身の分離」です。
CloudEffects LLC — OS iXanagi: 意味を構造化する OS
