AIエージェントのために設計されたCMS

2026年のCMSに課すべきテストがあります。「全10言語の料金ページを更新する」というタスクをAIエージェントに与え、作業開始までにいくつのカスタム統合が必要か数えてみてください。ほとんどのホステッドシステムでは、APIクライアント、認証情報、ブラックボックス化されたスキーマ、そしてエージェントが壊さないことを祈るしかないサンドボックス環境が必要です。しかし、MDXファイルが詰まったリポジトリなら、答えはゼロです。エージェントはすでに、読み取り、grep、編集、diffといった必要なスキルをすべて備えています。

Scribeはこの特性を最大限に活かしています。エージェントがすでに得意としていることだけで、すべての操作が完結するCMSなのです。

読み取り: すべてはファイルの中に

Scribeプロジェクトを探索するエージェントには、全体像を把握するためのドキュメントは不要です。コンテンツタイプは1つの設定ファイルにあるZodスキーマであるため、すべてのドキュメントの構造をコードとして読み取れます。ドキュメントはファイル名がスラッグとなるMDXファイルです。翻訳データはその隣にあるSQLiteストアに保存されます。管理画面の裏に隠されたデータはありません。リポジトリがシステム全体であり、content/ディレクトリをgrepすれば、文字通りすべてを検索できます。

書き込み: 信頼ではなくガードレールを

エージェントの懸念点は、文章が書けないことではありません。気づきにくい形で壊れたデータを出力してしまうことです。Scribeの解決策は、人間に対するアプローチをさらに厳格に適用することです。

スキーマによる全ドキュメントの検証。 FrontmatterはコンテンツタイプのZodスキーマに従ってパースされる必要があります。存在しないフィールドを捏造したり、必須フィールドが欠けていたりすれば、本番環境ではなくscribe validateの段階で失敗します。
コンパイル必須の本文。 すべてのMDXの本文は検証時にコンパイルされるため、コンポーネントの構造や構文のエラーはビルド前に検出されます。
リンク切れを未然に防ぐ。 インラインのリレーショントークンは、タイプとスラッグでドキュメントを参照します。存在しないドキュメントを指すトークンがあれば検証エラーになります。つまり、エージェントがリンク切れのあるコンテンツを検証に通すことは物理的に不可能です。
無計画な削除の防止。 scribe deleteは事前にすべての参照関係を計算し、問題があれば操作をブロックします。ページを削除しようとするエージェントは、他にどのような影響があるかを正確に把握できます。

その結果、「エージェントにコンテンツ編集を任せる」ことの不安は解消されます。編集に失敗したとしても、テストの失敗と同じようにCLI上に赤いエラーメッセージが表示されるだけです。

レビュー: diffこそがインターフェース

すべての変更はコミットとして記録されるため、エージェントの作業もチームが普段行っているようにプルリクエストとしてレビューできます。確認用の個別の監査ログも、Gitと照合するためのCMSの履歴も必要ありません。英語のスナップショットには各翻訳の元データが記録されるため、AIによる翻訳であっても「このフランス語のテキストは、この日付に、このモデルを使って、あの英語のテキストから作成された」という来歴を確実に追跡できます。

ローカルのStudio機能は、人間による最終確認をサポートします。エージェントが変更した箇所をブラウズし、全ドキュメントを検索し、リンクや画像が解決された状態で本文をプレビューし、翻訳のカバー率を一目で確認できます。エージェントがファイルを編集し、人間がStudioで検証するのです。

AIで活用するだけでなく、AIへ配信する

エージェントがScribeで書き込みやすい理由は、AIシステムがあなたのサイトを読み取るのが簡単な理由と同じです。scribe export-staticを実行すると、ロケールごとのすべてのページがプレーンなMDXバージョンとして静的ディレクトリに出力されます。これはレンダリングされたHTMLよりも、LLMのクローラーや回答エンジンがはるかに処理しやすい、マークアップの少ないクリーンなテキストです。あなたのコンテンツは、パイプラインの入口と出口のどちらにおいてもAIにとって読みやすいものになります。

これは机上の空論ではありません

このサイト自体が実例です。変更履歴の統合、ドキュメントの再構築、そして今あなたが読んでいるこのコンテンツの保守作業のほとんどは、リポジトリ内でAIエージェントが実行し、scribe validateで検証され、人間がdiffとしてレビューしたものです。チームのために設計されたGitベースのモデルは、結果的にエージェントが求めていたものと完全に一致していました。

エージェントが保守をサポートするサイトを構築する場合は、セットアップガイドから始めて、エージェントにタスクを与えてみてください。彼らにとっても馴染みのあるワークフローだと感じるはずです。