コンテンツ移行ではなく「意味の移行」— WordPressのデータがOS iXanagiで生まれ変わる仕組み
WordPressのコンテンツをそのままコピーしても、OS iXanagiのメリットは得られません。必要なのはコンテンツの移行ではなく、コンテンツが持つ意味の構造化です。この違いを理解することが、移行を成功させる鍵です。本記事では、IT担当者・技術者向けに、WordPressのデータがどのようにOS iXanagiのMeaning Objectsに変換されるのか、技術的な詳細を解説します。
目次全 9 章
WordPressのデータ構造の実態 — wp_postsには何が入っているのか？
WordPressの中核となるテーブルはwp_postsです。このテーブルは非常にシンプルな設計で、ブログ投稿・固定ページ・カスタム投稿タイプ・メニュー項目・メディアアタッチメントなど、あらゆるコンテンツが1つのフラットなテーブルに格納されています。
主要なカラム構成は以下の通りです。
post_content: HTMLが入ったテキストフィールド（コンテンツの実体）post_type: 'post'/'page'/'product'などの種別post_status: 'publish'/'draft'/'private'などpost_meta: 別テーブルwp_postmetaにkey/value形式で格納される拡張データ
ここで重要な問題があります。post_contentには「製品説明」「ブログ記事の本文」「会社概要」「お客様の声」など、まったく異なる意味を持つコンテンツが同じ構造で保存されています。WordPressは「これは何のためのテキストか」を識別する仕組みを持っていません。
さらに、カスタムフィールド（ACFなど）はすべてwp_postmetaにkey/value形式で格納されます。「価格」「素材」「配達日数」といったビジネス上重要な情報が、汎用的なkey/valueとして保存されているため、その意味はWordPress外のアプリケーションからはわかりません。
「コンテンツ」と「意味」の違いとは何か？
この問いは移行全体を理解する上で最も重要です。
コンテンツ: 「当社の製品は競合他社より30%コスト削減できます。詳しくは営業チームまでお問い合わせください。」
この文章はWordPressのwp_posts.post_contentに格納されています。これは「テキスト」です。
意味: この同じ文章がOS iXanagiに移行されると、次のような意味構造を持ちます。
- Meaning Object type: Draft（本文コンテンツ）
- semantic_tag:
value_proposition（価値提案） - Domain: Financial, Demand
- locale: en（英語）, ja（日本語）
- Relation:
contextually_cites→ 競合比較データのKnowledge Object - Relation:
contains→ CTAオブジェクト（「営業チームに連絡する」）
AI Agentはこの意味構造を参照することで、「価値提案に関する質問には、このMeaning Objectの内容を根拠として答えられる」と理解できます。単なるテキストとしてのコンテンツを持っているだけでは、AI Agentはそれを業務に使えません。
WordPressの平均的なビジネスサイトには20〜50個のプラグインが導入されています（業界標準）。移行の最大の課題はプラグインの代替構築であることが、Focus Reactive 2026の調査で確認されています。しかし、より深い問題はプラグインそのものではなく、「プラグインが生成していたデータの意味がWordPressの外には伝わらない」という点にあります。OS iXanagiへの移行は、この問題を根本から解決する機会です。
WordPressのデータとOS iXanagiの対応関係はどうなっているのか？
以下の表で、WordPressの各データ要素がOS iXanagiでどう扱われるかを示します。
| WordPress | OS iXanagi |
|---|---|
| wp_posts（フラットなコンテンツ） | Meaning Objects（意味でタグ付けされたコンテンツ） |
| wp_postmeta（カスタムフィールド） | Knowledge Objects（構造化された知識） |
| カテゴリ・タグ（分類） | Relations + semantic_tags（意味的接続） |
| テンプレート・テーマ（表示方法） | Section Types + Projections（表示設計） |
| プラグイン機能（機能追加） | Pledge Sets（制御された機能実行） |
| ページURL（パスベース） | Routes + parent_of Relations（意味ベース） |
| コメント | Support Appでの問い合わせ管理 |
この表で最も重要な変換は「カテゴリ・タグ → Relations + semantic_tags」です。WordPressのカテゴリとタグは分類のための階層構造ですが、OS iXanagiのRelationsは「この記事がなぜこの知識と接続されているのか」という意味的な理由を持ちます。
parent_of（親子関係）・contains（包含）・labeled_by（ラベル付け）・contextually_cites（文脈引用）といったRelation Vocabularyを使うことで、コンテンツ間の接続が単なる分類から意味のあるグラフ構造へと変換されます。
このシリーズの記事#11「Content Link Graph」では、この意味的な接続がどのようにサイト全体の可視化と内部リンク設計に使われるかを詳しく解説しています。
Source PatternとAI Extractionによる意味抽出プロセスはどのように機能するのか？
OS iXanagiの移行において、WordPressのコンテンツはまず「Source」として取り込まれます。Source Patternは、すべての意味インポートの単一入口として設計されており、WordPressのエクスポートファイルも同じ経路で処理されます。
技術的なフローは以下の通りです。
WordPress XML Export (WXR)
↓
knowledge_sources（Sourceとして登録）
↓
knowledge_source_items（各投稿・ページがSource Itemとして保存）
↓
knowledge_extractions（AIが意味を抽出して候補生成）
↓
人間によるReview（Accept/Reject）
↓
knowledge_objects / website_meaning_objects（確定されたMeaning Objects）
AIのExtraction処理では、Source Itemの内容を解析して複数の抽出候補（knowledge_extractions）を生成します。各抽出候補には以下が含まれます。
extraction_type: knowledge（知識）/ content（コンテンツ）/ signal（シグナル）/ profile（プロフィール）などgroup_key: 意味単位のID（locale非依存。EN/JAの両行が同じgroup_keyを持つ）locale: en / jaconfidence: AIの確信度（0〜1.0）signal_meta_json: intent, knowledge_boundary, thesis_affinity, contradiction_refsなどのメタデータ
特に重要なのがgroup_keyとlocaleの組み合わせによるi18n管理です。英語の記事と日本語の記事が同じgroup_keyを持つことで、「意味的に同一のコンテンツのEN/JAバリアント」として管理されます。これはWordPressの多言語プラグイン（WPML等）とは根本的に異なる設計思想です。WPMLは「翻訳」として扱いますが、OS iXanagiは「同一の意味の locale adaptation」として扱います。
HITLレビュー — AIの抽出結果を人間が検証することはなぜ重要なのか？
AIによるExtraction処理は高精度ですが、完璧ではありません。特にビジネスの文脈や業界固有の知識が必要な判断では、人間のレビューが不可欠です。
OS iXanagiのHITL（Human-in-the-Loop）設計では、AIが生成した抽出候補（knowledge_extractions）を人間がAcceptまたはRejectする判断を経て初めて、Meaning Objectsとして確定されます。
よくある人間の修正パターンを具体例で示します。
例1: AIは「当社は業界で20年の実績を持ちます」を brand_claim（ブランド主張）として抽出しました。しかし担当者が確認すると、これは現在25年なので内容が古く、Rejectして新しいテキストで再登録します。
例2: AIはコンテンツから「返品ポリシーは30日間」というKnowledge Objectを抽出しましたが、実際には製品カテゴリによって異なる条件がある。担当者がapplicable_conditionsフィールドに条件を追記してからAcceptします。
例3: AIがFAQのQ&Aを2つの別々のKnowledge Objectとして抽出しましたが、担当者が見ると、これは1つのFAQオブジェクトとしてまとめるべき内容です。2件をRejectして、1件のFAQオブジェクトとして手動で登録します。
このレビュープロセスを経たMeaning Objectsは「人間が検証済みの知識」として高い信頼性を持ちます。AI Agentがこの知識を参照して業務を実行するとき、出力の品質は入力の知識品質に直接依存します。移行時のHITLレビューへの投資は、移行後のAI品質への投資です。
移行後のデータがAI Agentにどう使われるのか — Workflow連携の実際
移行が完了し、Meaning Objectsが確定した後、これらのオブジェクトはWorkflowを通じてAI Agentに参照されます。
ブログ記事生成（wf_blog_generator） AI AgentはKnowledge ObjectsとMeaning Objectsを参照して新しい記事のBriefを生成します。WordPressから移行された「製品の技術仕様」「顧客事例」「競合比較データ」がすべてKnowledge Objectsとして構造化されているため、Agentは「根拠のある」コンテンツを生成できます。ハルシネーション（AIの誤った生成）が構造的に抑制される理由はここにあります。
コンテンツ同期（wf_content_sync） Marketing AppからWebsite Appへのコンテンツ同期が自動化されます。WordPressでは手動だったコンテンツ更新の反映が、Workflow実行で全チャネルに一括適用されます。
知識ヘルスチェック（wf_knowledge_health） 定期的にKnowledge Objectsの鮮度と整合性をチェックします。WordPressでは誰も気づかないまま古い情報が残り続けますが、OS iXanagiでは期限切れのKnowledge Objectsが自動的にフラグされ、更新を促します。
カスタムフィールド・ACFのデータはどうなるのか？
これはIT担当者から最も多く寄せられる質問です。
ACFのカスタムフィールドはwp_postmetaにkey/value形式で保存されています。たとえば製品ページにacf_price、acf_material、acf_delivery_daysというカスタムフィールドがある場合、Migration Pipelineではこれらを以下のように処理します。
フラット値（テキスト・数値）: Meaning Objectsのstructure_json内にフィールドとして取り込まれます。または、Knowledge Objectsとして「製品仕様」の構造化知識として格納されます。
繰り返しフィールド・フレキシブルコンテンツ: ACFの繰り返しフィールドは、Step 4のMapping段階でSection TypesおよびRelationsに変換する設計が必要です。自動変換ではなく、IT担当者が意味的な対応関係を設計します。
リレーションフィールド（ACF Relationship）: オブジェクト間の接続はOS iXanagiのRelation Vocabularyで表現します。post_to_post形式のACF Relationshipは、referencesまたはcontainsなどのRelation typeとして再設計されます。
重要なのは、ACFのカスタムフィールドを「そのまま」OS iXanagiに移行しようとしないことです。カスタムフィールドの設計は往々にして「とりあえず作った」ものが多く、移行はそれを意味的に正しく再設計する機会です。
よくある質問（FAQ）
Q1: ACFのデータは完全に使えますか？ はい、使えます。ただし、自動的に1:1変換されるわけではありません。Step 4のMapping段階で、各ACFフィールドがOS iXanagiのどのオブジェクト種別・フィールドに対応するかを設計する作業が必要です。フラットな値フィールドは比較的簡単に移行できますが、繰り返しフィールドや条件分岐ロジックは再設計が必要になる場合があります。
Q2: WooCommerceはどうなりますか？
WooCommerceの商品データ（wc_products、wc_orders等）は、将来的にはOS iXanagi Commerce Appが対応予定です（現在開発最優先）。現時点では、WooCommerceの商品カタログと製品説明をMeaning Objectsとして移行することは可能ですが、EC機能（カート・決済）の移行はCommerce App完成後に対応します。
Q3: 移行後のコンテンツ編集はどうやるのですか？ 移行後のコンテンツ編集は、各App Console内のMeaning Objects編集画面から行います。WordPressのGutenbergエディタのようなビジュアルエディタではなく、構造化されたフォームベースのエディタです。マーケティング担当者はMarketing Console、Webサイト担当者はWebsite Consoleから、それぞれMeaning Objectsを編集します。AI Agentに自然言語で編集を指示することも可能です。
Q4: ステージング環境でのテストはできますか？ はい、Step 7のAuditまではステージング環境で完結します。本番WordPressサイトに影響を与えずに、移行後の全コンテンツをOS iXanagiのステージング環境で確認できます。
Q5: 移行後にWordPressに戻せますか？ Step 8（DNS切り替え）の前であれば、いつでもWordPressに戻せます。OS iXanagi側で作業を進めている間も、WordPressサイトは並行稼働しています。ただし、Step 8後にWordPressに戻す場合は、OS iXanagi側で加えた変更を手動でWordPressに反映する作業が必要になります。
移行は作業ではなく設計です
WordPressで積み上げてきたコンテンツ資産の価値を最大化するには、それを「意味」として構造化する必要があります。Source PatternとAI Extractionによる意味抽出プロセスは、その構造化を体系的に行うための仕組みです。
移行後、AI AgentはこのMeaning ObjectsとKnowledge Objectsを参照して、営業サポート・コンテンツ生成・ナレッジ管理などの業務を実行します。WordPressで積み上げたコンテンツの意味を構造化することで、初めてそのコンテンツがAI Agentの「業務知識」として使えるようになります。
移行後の具体的な変化については、このシリーズの記事#9「移行後の世界 — OS iXanagiに移行した後、何が変わるのか」をご参照ください。記事#7「8ステップMigration Pipeline」では、全体のプロセスと各ステップの目安期間を解説しています。
技術的な移行設計についてのご相談は、CloudEffectsにお問い合わせください。WordPressのACF設計からOS iXanagiへのMapping設計まで、技術的な移行計画の立案をご支援します。
Sources:
- Focus Reactive, "WordPress Migration Challenges Report," 2026
- 業界標準: WordPressプラグイン数の実態調査, 2025
- OS iXanagi Documentation: Source Pattern & Knowledge Extraction
- OS iXanagi Documentation: Meaning Objects & i18n Contract
- OS iXanagi Documentation: HITL Review Process
