コンテンツを、ソフトウェアの中から取り戻す

最後にCMSを開いた場面を思い出してほしい。

書きたかったのは、何だっただろう。営業時間の変更か。新しいサービスの説明か。顧客へ伝えるべき大切な知らせか。

では、そのとき実際に考えていたのは何だっただろう。適切なメニューはどこか、どの編集ブロックを選ぶか、保存と公開はどう違うか、画像サイズはいくつか。伝えたい内容より先に、画面の都合を考えてはいなかっただろうか。

もし心当たりがあるなら、理由を一つ考えてみてほしい。CMSの設計が悪かったからだろうか。操作に慣れていなかったからだろうか。それとも、コンテンツをつくる行為と、特定のソフトウェアを操作する行為が、必要以上に結びついていたからだろうか。

この問いを、いったん答えの出ないまま残しておく。

長いあいだ、Webサイトを運営することはCMSを使うこととほとんど同義だった。文章を書き、画像を登録し、公開日時を決める。そのための画面があり、その背後にデータベースがあり、権限管理や履歴やプレビューがある。HTMLを直接扱わなくても更新できるという点で、CMSは確かに人を自由にした。専門家に依頼しなければ一文字も変えられなかった時代に、編集の力を利用者の側へ移したからである。

しかし、その自由には条件があった。利用者はコードを学ばなくてよい代わりに、そのCMSの考え方を学ばなければならなかった。

記事、固定ページ、ブロック、テンプレート、フィールド、プラグイン、公開状態。製品ごとに名前と振る舞いは異なり、画面構成も権限の仕組みも違う。一度覚えれば終わるわけでもない。バージョンが変われば画面が変わり、拡張機能が更新されれば挙動が変わる。製品の方針や価格が変われば、別の製品への移行が検討される。移行先では、また別の概念と操作を学ぶことになる。

コンテンツをつくるために、コンテンツとは直接関係のない学習が繰り返される。

この負担は、コンテンツプロバイダーにとって小さくない。書くこと、設計すること、撮ること、描くこと、伝えることに使われるはずの時間が、特定製品の操作へ振り向けられる。習熟は専門性として評価されることもあるが、その専門性は製品が変われば大きく減価する。コンテンツをつくる人が、いつのまにかCMSを操作する人になってしまう。

ユーザーも同じ負担から自由ではない。新しいCMSへの移行には、再契約、再教育、データ変換、デザインの再実装、権限の再設定が伴う。データを書き出せたとしても、それだけで以前と同じサイトや運用を再現できるとは限らない。記事は残っても、構造、見せ方、承認手順、公開方法、過去の判断理由が失われることがある。形式上はデータを所有していても、運用する能力までは所有していない。

問題は、あるCMSが古いか新しいかではない。特定のプログラミング言語が優れているか、不安定かということだけでもない。実行言語、CMS本体、データベース、プラグイン、テーマ、API、ホスティングが、それぞれ別の更新周期を持つ。その互換性を維持する仕事が、コンテンツ運用の前提として持ち込まれることが問題なのである。成熟した技術を使っていても、依存関係が重なれば、長期保守には複雑性と不確実性が生まれる。

この状況に対して、LLMの登場は一つの転機をもたらした。

これまで非技術者がコンテンツを扱うには、ソフトウェア側が用意した画面と項目を覚える必要があった。LLMは、その関係を反転できる。「営業時間を九時に変更してほしい」「この文章を、初めて読む人にも分かるように整えてほしい」と、人が自分の言葉で目的を伝えられるからである。人がソフトウェアの操作体系へ近づくのではなく、ソフトウェアが人の意図へ近づく可能性が生まれた。

ただし、LLMへCMSの管理画面を置き換えさせるだけでは、問題は解決しない。特定のLLMサービスがコンテンツ、会話履歴、ルール、公開権限を握れば、CMSへの依存がAIへの依存に置き換わるだけである。自然言語は学習コストを下げられるが、それ自体は所有権、可搬性、安全性を保証しない。

したがって、LLMが可能にしたのは「新しい万能CMS」ではない。コンテンツの正本と編集の入口を分離し、入口を交換可能にすることである。LLMはその入口の一つになれる。この分離があるからこそ、CMSの画面を捨てても、利用者へコードの学習を押し戻さずに済む。

そこで必要になるのは、より優れたCMSを選ぶことではない。CMSが中心にある構造そのものを変えることである。

正本を製品の外へ出す

新しい構造では、コンテンツの正本をCMSのデータベースに置かない。文章、構造化データ、画像、デザイン原則、品質基準、判断の文脈を、顧客が所有するリポジトリの中へ標準形式で置く。

文章はMarkdown、構造化された値はJSONやYAML、表はCSV、画像は一般的な画像形式で保持できる。コンテンツの構造は公開されたスキーマで定義する。どれも特定製品を契約しなければ読めない形式ではない。人が直接読むことができ、一般的な道具で処理でき、別のシステムへ渡すことができる。

顧客所有のコンテンツ・リポジトリ
├─ content/        本文・構造化データ
├─ assets/         画像・図版・権利情報
├─ design/         デザイン原則
├─ schemas/        コンテンツ構造
├─ policies/       安全・品質・事業ルール
├─ context/        目的・読者・判断理由
├─ operations/     公開・復旧・退出手順
└─ audit/          判断と操作の記録

Webサイトは、この正本から生成される表現の一つになる。APIも検索インデックスもプレビューも同じである。それらは重要だが、失えば再生成できる派生物であり、コンテンツそのものではない。

ここで起きる変化は、保存場所の変更にとどまらない。何がコンテンツで、何が製品なのかという主従関係が逆転する。

これまでは、コンテンツがCMSの中に置かれていた。これからは、編集画面や公開システムがコンテンツの周囲に置かれる。

コンテンツは製品の中に置かない。製品をコンテンツの周囲に交換可能な形で置く。

ここまでに書いたことの強度を区別しておきたい。

CMSごとに操作体系が異なること、製品や拡張機能に更新があること、移行時に再設定や再実装が生じることは観察できる事実である。そこから「製品への依存がコンテンツ運用の負担になる」と考えるのは解釈である。そして「その依存を解消すべきだ」というのは、本構想が採る価値判断である。

三つは同じではない。すべてのCMS利用者が同じ負担を感じていると確認したわけではないし、CMSを外せば必ず運用が改善することを実証したわけでもない。本稿が提示するのは、現時点では設計仮説である。この仮説が正しいかどうかは、実際の運用で、学習時間、変更時間、事故率、復旧時間、担当者交代時の負担がどう変わるかによって検証されなければならない。

編集画面をなくすのではなく、その支配をなくす

CMSを中心から外すことは、非技術者にコードを書かせることではない。編集画面、入力フォーム、メディア選択、プレビューといった支援機能はこれからも必要である。

変えるのは、それらの機能とコンテンツの所有を切り離すことである。

営業時間だけを変更する簡単なフォームがあってよい。文章を書くための洗練されたエディタがあってよい。コンテンツプロバイダーがファイルを直接編集してもよい。先に見たように、ユーザーがLLMへ「来月から営業時間を九時に変更して」と依頼してもよい。外部システムからAPIを通して変更してもよい。

ただし、どの入口もコンテンツを独占しない。それぞれは標準的な変更案をつくり、同じ検証、プレビュー、承認、記録の経路へ渡す。

自然言語 ─────┐
簡易フォーム ─┤
文章エディタ ─┼→ 変更案 → 分類 → 検証 → 確認 → 正本 → 公開
直接編集 ─────┤
外部API ──────┘

ある編集製品が終了しても、コンテンツ移行は発生しない。正本はもともと製品の外にあるからである。必要なのは、新しい入口を同じ正本へ接続することだけになる。

これは「データを書き出せる」という従来の可搬性より強い。書き出しは、退出時に初めて製品の外へ出る行為である。ここで目指すのは、平時から製品の外に正本があり、そもそも脱出作業を必要としない状態である。

二つの状態を比べてみよう。

一方では、記事をCMSから標準形式で書き出せる。ただし、公開画面、コンテンツ間の関係、権限、承認、過去の判断は別に再構築しなければならない。もう一方では、標準ファイル、構造、ルール、文脈、運用手順が平時から製品の外にある。編集画面を替えても、それらは動かない。

どちらも「データを持ち出せる」と表現できる。しかし、同じ可搬性だろうか。

前者が運ぶのは保存された内容である。後者が運ぼうとするのは、内容を理解し、変更し、公開し、戻す能力である。本構想では、前者をデータの可搬性、後者を運用能力の可搬性として区別する。

コンテンツプロバイダーを、操作担当者から解放する

この変化によって、コンテンツプロバイダーの仕事はCMSの操作から、意味と表現の設計へ戻る。

何を誰に伝えるのか。どの順序なら理解できるのか。どの言葉がその組織らしいのか。どの写真を使い、どの表現を避けるのか。情報をどの単位に分ければ、Webサイトだけでなく、メール、SNS、紙面、音声にも展開できるのか。

これらは特定製品の画面配置とは無関係である。そして、製品が変わっても価値を失わない。

コンテンツプロバイダーは、品質ルールを提案する。ブランドトーン、デザイン原則、アクセシビリティ、情報設計、出典と著作権の扱い。それらを人が読める文書と、可能な範囲で検証できるルールとして残す。制作された文章や画像だけでなく、「なぜこの表現にしたのか」という判断の文脈も正本の一部になる。

これにより、コンテンツプロバイダー自身も交換可能になる。交代によって個性や品質が変わることはある。しかし、新しい担当者は過去の意図を読み、どこを継承し、どこを変えるかを判断できる。引き継ぎは、前任者の記憶や善意だけに依存しなくなる。

交換可能であることは、専門家の価値を下げない。むしろ、囲い込みではなく、表現の質と判断の質によって選ばれる状態をつくる。

ベンダーの価値を、囲い込みから運用品質へ移す

ベンダーの仕事も変わる。

従来のベンダーは、CMSを選び、コンテンツモデルを構築し、テーマやテンプレートを実装し、CMSでは扱えない変更を請け負ってきた。この構造では、ベンダーだけが理解している設定や公開経路が増えるほど、顧客は離れにくくなる。意図しなくても、技術的な複雑性が継続契約を支えることがある。

新しい構造でベンダーがつくるのは、コンテンツを閉じ込める器ではない。変更を安全に通すためのルールとロジックである。

ベンダーは、変更の危険度を分類し、構造やリンクや表示を検証し、プレビューを生成し、高リスク変更を権限者の承認へ送る。誰が何を判断したかを記録し、問題があれば顧客自身でも以前の版へ戻せる状態を保つ。編集クライアントや公開基盤を交換しても、この運用原則を再現できるようにする。

したがって、ベンダーの競争力は「当社がいなければ動かない」ことではなくなる。

• 変更をどれだけ正確に分類できるか
• 誤りを公開前にどれだけ発見できるか
• プレビューまでの時間をどれだけ短くできるか
• 事故からどれだけ早く復旧できるか
• 監査記録をどれだけ理解しやすくできるか
• 別のベンダーへの交代をどれだけ滑らかにできるか

退出を難しくすることで得ていた優位は、退出可能な状態でも選ばれるだけの運用品質へ置き換わる。

ユーザーは、管理画面ではなく運用能力を所有する

ユーザーがCMSの管理者アカウントを持っていても、それだけで自立しているとは限らない。設定の意味を理解できず、公開にベンダーだけが持つ資格情報が必要で、別の環境にサイトを再現できなければ、所有は名目的なものにとどまる。

新しい構造でユーザーが所有するのは、コンテンツデータだけではない。

• コンテンツと素材
• コンテンツの構造
• ブランドと品質のルール
• 過去の判断理由
• 変更と承認の記録
• 公開と復旧の手順
• ベンダーとコンテンツプロバイダーを交代する権利

つまり、ユーザーは完成物だけでなく、それを継続的につくり、直し、公開し、戻す能力を所有する。

これは、すべてをユーザー自身に作業させるという意味ではない。ユーザーは専門家へ委任できる。重要なのは、委任が譲渡にならないことである。運用を任せても、最終的な管理権と退出権はユーザーの側に残る。

三者の関係を組み替える

この構造には、ベンダー、コンテンツプロバイダー、ユーザーという三つの主体がいる。

ユーザーは、目的を定め、事実を提供し、ルールを採択し、公開を最終承認する。コンテンツとアカウントと成果物を所有する。

コンテンツプロバイダーは、目的を表現へ変換する。文章、デザイン、情報構造をつくり、品質上の判断とその理由を残す。

ベンダーは、合意されたルールを実行可能なロジックへ変換する。変更を安全に運び、検証し、記録し、復旧可能にする。

三者のうち、誰か一者がルールの意味、実装、検証、承認を独占してはならない。品質ルールはコンテンツプロバイダーが提案し、ユーザーが採択し、ベンダーが検証可能な形へ実装する。安全ルールはベンダーが提案・実装するが、ユーザーがその採択と例外に関する最終権限を持つ。事業上の判断はユーザーが行い、専門家は予見できる危険を説明する。

この分離は、責任逃れのためではない。事故が起きたときに、どの判断、どの表現、どの機構で防げたのかを明らかにするためである。

だからこそ、LLMを新しいCMSにしない

前半で述べたように、自然言語でコンテンツを変更できることは、人を製品固有の操作学習から解放する。しかし、その利便性が大きいからこそ、LLMを新しい中央システムにすれば、ロックインは形を変えて残る。

特定のモデルだけが理解できる指示、特定サービスにしか残らない会話履歴、事業者側から読めない判断、モデルが直接握る公開資格情報。これらは、CMSデータベースと同じように正本と運用能力を囲い込む可能性がある。

LLMは責任主体でも正本でもない。三者が利用できる交換可能な操作クライアントの一つである。LLMが生成した変更も、人が直接行った変更も、フォームから送られた変更も、同じ検証と承認の経路を通る。モデルを交換しても、コンテンツ、ルール、文脈、履歴は残る。

CMSをなくした場所に、AIによる新しいCMSを建ててはならない。

CMSを使い続けるという、強い反論

ここまでの主張に対して、もっとも強い反論は明快である。

CMSは、保存、編集、権限、履歴、プレビュー、公開を一体として提供するからこそ役に立つ。それらを分解すれば、利用者は複数の道具を組み合わせ、接続し、保守しなければならない。標準ファイルを正本にしても、非技術者がGitやMarkdownを扱えなければ自立したことにはならない。交換可能性を高めるために、日常の使いやすさと運用の安定を犠牲にするなら、本末転倒ではないか。

この反論は正しい。少なくとも、無視してよい反論ではない。

一体型CMSは、責任範囲が明確で、導入が速く、定型的な更新に適している。十分にデータを書き出せ、信頼できる運営主体があり、利用期間が限定され、移行の必要性が低いなら、CMSを使い続けるほうが合理的な場合がある。短期間のキャンペーンサイトや、構造が固定された小規模サイトに、本構想の全要素を導入する必要はない。

したがって、本稿の結論は「すべてのCMSを直ちに廃止すべきだ」ではない。

長く使われ、複数の専門家が関わり、組織の記憶となり、供給者を交代する必要があるコンテンツについては、特定製品を正本にし続けるコストを見直すべきだ、という主張である。

反対に、標準ファイルを正本にしても、実際には特定ベンダーしかビルドできない、独自スキーマを解釈できない、LLMがなければ編集できない、顧客自身では復旧できないのであれば、この構想は成立していない。CMSという名前を外しただけで、依存先をGit、フレームワーク、ベンダー、LLMへ移したにすぎない。

自由には、新しい仕事が伴う

この構造は、すべてを簡単にする魔法ではない。CMSが一体で提供していた能力を分解する以上、それらを明示的に組み立てる必要がある。

標準形式を選び、スキーマを定義し、非技術者のための操作面を用意する。プレビュー、権限、承認、公開、復旧を設計する。技術とコンテンツ双方の文脈を維持し、定期的に別環境への復元を試す。三者の合意形成にも時間がかかる。

小さく、更新が少なく、構造変更もなく、短期間だけ使うサイトなら、この仕組みは過剰かもしれない。一体型のサービスへ任せるほうが合理的な場合もある。

それでも、長く使われるコンテンツ、複数の専門家が関わるコンテンツ、組織の記憶になるコンテンツにとって、この追加コストには意味がある。それは移行のたびに同じ知識を失い、同じ再構築を繰り返す費用を、平時の可搬性と明示的な運用へ振り替える投資だからである。

この投資が妥当かを判断するには、自分のコンテンツについて次を確かめる必要がある。

• そのコンテンツは、現在の製品より長く使われるか
• 担当者やベンダーが交代したとき、何が失われるか
• データを書き出すだけで、同じ品質の運用を再開できるか
• 一週間、現在のCMSへアクセスできなければ、何が止まるか
• 交換可能性のために、平時どこまで費用を負担できるか

答えによっては、CMSを使い続ける判断もあり得る。重要なのは、その選択が惰性ではなく、依存の利益と費用を比較した判断になることである。

変わるのは、ソフトウェアではなく主権である

この構想は、CMSをファイルへ置き換えるだけの技術提案ではない。

第一に、製品中心の運用から、コンテンツ中心の運用へ変える。どのCMSを使うかではなく、コンテンツがどのように所有され、変更され、検証され、引き継がれるかを先に決める。

第二に、データの可搬性から、生産能力の可搬性へ進める。文章や画像を書き出せるだけでなく、別の人と別の道具が、その意味と品質を理解し、安全に変更、公開、復旧できるようにする。

第三に、制限による安全から、検証可能な自由へ移る。決められた入力欄だけを触れる安全性ではなく、より自由な変更を、分類、プレビュー、検証、承認、版管理によって扱う。

第四に、製品操作への習熟から、持ち運べる専門性へ戻す。コンテンツプロバイダーは特定CMSの操作ではなく、意味、表現、構造、品質によって価値を発揮する。ベンダーは囲い込みではなく、安全性と運用品質によって選ばれる。ユーザーは管理画面のアカウントではなく、コンテンツを運用する能力を所有する。

ここで取り戻されるのは、ファイルだけではない。誰が目的を決め、誰が表現をつくり、誰が道具を整え、誰が交代を決められるのかという主権である。

CMSは人をコードから解放した。その歴史的役割を否定する必要はない。次に必要なのは、人をCMSからも解放することである。

ユーザーが目的と資産を所有する。

コンテンツプロバイダーが意味と表現を育てる。

ベンダーがその仕事を安全、可搬、検証可能にする。

そして、どの道具もコンテンツそのものを所有しない。

冒頭で考えた、CMSを開いたときの経験へ戻ろう。

操作に迷った理由について、最初に立てた仮説は今も同じだろうか。問題は単に画面が分かりにくかったことだったのか。それとも、伝える仕事が、製品を操作する仕事の内側に置かれていたことだったのか。

この構想を自分の言葉で一文にするなら、どう表すだろう。

そして明日、現在のCMS、ベンダー、LLMが使えなくなったとしても、自分たちのコンテンツを理解し、変更し、公開し、戻すことができるだろうか。

その問いに答えるとき、所有しているのが単なるデータなのか、それとも運用する能力なのかが見えてくる。