私は自分のサイトの上に別の一般的なCMSを追加したくありませんでした。私の経験では、その設定は常に摩擦を生み出します。私は製品の一部のように感じるmcp cmsが欲しかったのです。毎日戦わなければならない外部システムではなく。
この記事では、Next.js、Supabase、MCP、およびエージェントフローを使用してmcp cmsをどのように構築したかを説明します。アーキテクチャ、ツールレイヤー、管理ダッシュボード、コンテンツパイプラインについて説明し、システム全体が実際にどのように機能するかを示します。
なぜ一般的なヘッドレススタックを使用せずにMCP CMSを構築したのか
私はサイトとCMSを同じNext.jsアプリ内に構築しました。なぜなら、1つのコードベース、1つのデータモデル、1つの出版フローを望んだからです。私は十分に切り離されたスタックを使用してきたので、それらがどれほど早くメンテナンスの負債に変わるかを知っています。フロントエンド、CMS、オートメーションレイヤーが別々の場所にあると、すべての変更が必要以上に時間がかかります。
私のmcp cmsは、公開サイト、管理UI、APIルート、AIツールを1つの製品の境界内に保ちます。つまり、SEOメタデータ、ローカリゼーション、または記事のロジックを3つのシステムを飛び越えることなく変更できます。また、コンテンツが1つのツールに存在し、実際のロジックが別の場所に存在するという通常の「同期問題」を回避できます。
実際には、これによりより迅速な反復と壊れたエッジの減少が得られました。また、すべての書き込みアクションが同じレイヤーを通過するため、システムの観察が容易になりました。運用コンテンツシステムについての私の考え方に関する詳細は、Multi-Agent Content Pipeline in Next.js With Search Consoleの投稿でそのワークフローの研究側面を示しています。
システムの背後にあるコアアイデア
コアアイデアはシンプルです：CMSは製品のように振る舞うべきであり、フォームビルダーのようではありません。私は型付きコンテンツ、制御された書き込み、および監視を失うことなく迅速に公開できる自動化レイヤーを望んでいました。だからこそ、アーキテクチャを厳格に保ち、境界を明確にしました。
従来のCMSから変更した点
従来のCMSは通常、コンテンツ編集を製品のコードベースから分離します。それは柔軟に聞こえますが、サイトがよりカスタムになると、チームの作業が遅くなることがよくあります。私のmcp cmsはその分割を取り除きました。これにより、コンテンツ、SEO、およびワークフローのロジックを1つの場所で管理できるようになり、オーバーヘッドを減らしながらより大きな影響力を持つことができます。
MCP CMSがMCPを制御レイヤーとして使用する方法
最も重要な決定は、システムの中央にMCPを配置することでした。私はAI機能が1つのチャットウィンドウや1つのダッシュボードに閉じ込められることを望んでいませんでした。異なるクライアントから同じバックエンドルールと対話できる再利用可能なコマンドレイヤーが欲しかったのです。
そのため、スタンドアロンのMCPサーバーとアプリ内MCPルートの両方を構築しました。mcp cmsを通じて公開されるツールには、ブログCRUD、公開、SEO分析、記事生成、リサーチ、画像生成、サイトマップチェックが含まれます。言い換えれば、エージェントレイヤーは何をすべきかを推測しません。実際の状態を持つ実際のツールを呼び出します。
このアプローチは、Model Context Protocol specificationおよび私が内部システムを構築する方法に一致します：1つの契約、複数のクライアント、重複なし。また、管理ダッシュボード内や外部MCPクライアントから同じアクションを再利用するのが簡単になりました。
MCPを通じて公開したツール
ツールの表面は意図的に広範です。私はエージェントが有用な作業を行うことを望んでいました。単にチャットするだけではありません。
そのツール設計はmcp cmsのバックボーンです。それはシステムを構成可能に保ち、すべての操作を観察可能にします。
このアーキテクチャが実際の作業で重要な理由
私のウェブサイトやコンテンツシステムを構築する仕事の中で、最大のボトルネックはほとんどの場合、書き込みではありません。ボトルネックは調整です。MCPはその調整コストを削減します。なぜなら、同じアクションをダッシュボード、チャットインターフェース、または別のエージェントフローから呼び出すことができるからです。その結果、私はステップを繰り返す時間が少なくなり、出力を改善する時間が増えました。
管理ダッシュボードがMCP CMSを制御室に変える
私は管理エリアが退屈なCRUD画面のように感じてほしくありませんでした。私はそれを制御室として構築しました。ドラフト、翻訳、画像、SEO、公開のための投稿管理があり、AIワークフローを実行し、それらが動くのを観察できる運用レイヤーがあります。
ダッシュボード内では、MCPチャットはシステムの他の部分と同じコンテンツツールを公開します。私は投稿をリストし、ドラフトを検査し、SEO分析をトリガーし、リサーチを開始し、自然言語リクエストで完全なパイプラインを実行できます。重要な部分は、チャットが魔法ではないということです。それはmcp cmsの残りの部分が使用するのと同じ型付きアクションに基づいています。
その設計は実際に時間を節約します。私は新しいワークフローごとにインターフェースを再構築する必要がありません。私は別のツールや別の制御パスを公開するだけです。システムレベルでの自動化についての私の考え方を見たい場合は、How I Built My CMS With MCP and Agent Flowsがこのセットアップの周りのより広い記事です。
ダッシュボードからできること
ダッシュボードは、制御を失うことなく迅速に移動できるようにします。
なぜシンプルなエディタの代わりに制御室を使用するのか
シンプルなエディタは、書いて公開するだけで済む場合には機能します。しかし、私はもっと必要でした。私はワークフローを観察し、変更を承認し、モデルが軌道を外れたときに介入できる場所が欲しかったのです。それがmcp cmsの本当の価値です：それは私に運用上の制御を与え、単なるコンテンツ入力だけではありません。
MCP CMSエージェントフローが実際に機能する方法
エージェントフローは1つの巨大なプロンプトではありません。私はそれを段階に分けて、各ステップで品質を制御できるようにしています。それは重要です。なぜなら、コンテンツ作業は混沌としているからです。リサーチ、SEO、構造、編集はそれぞれ異なる推論を必要とします。
私が最も頻繁に使用するフローは次のとおりです：
私はこのフローを繰り返しテストしました。なぜなら、偽のデモパイプラインを望んでいなかったからです。私は、1つのステージが別のステージにフィードバックを押し戻すことができるシステムを望んでいました。そのフィードバックループは、mcp cmsが単一通過のライティングアシスタントよりも優れている理由の1つです。
なぜフローを段階に分けたのか
各ステージは異なる問題を解決します。リサーチは幻覚を減らします。SEOは構造を鋭くします。編集は品質を保護します。出版は最終出力をクリーンにします。それらのタスクを分割することで、システム全体がより信頼性が高く、時間とともに改善しやすくなります。
エージェントが漂流しないようにする方法
私は型付き入力、明示的出力、および品質チェックを使用してエージェントを短いリードで保ちます。それにより、曖昧なプロンプトチェーンよりも良い結果が得られます。また、失敗の診断が容易になり、製造作業に自動化を依存する際には重要です。
Search ConsoleがMCP CMSをより賢くする
システムの最も強力な部分の1つは、プロンプトだけに依存しないことです。私はSearch Consoleのデータをリサーチプロセスに組み込み、エージェントが仮定ではなく実際の需要信号から作業するようにしています。これにより、トピック選択ステップが改善され、実際にランク付けできるコンテンツを優先するのに役立ちます。
Search ConsoleレイヤーはSupabaseにスナップショットを保存し、キーワードの機会、低CTRページ、およびコンテンツのギャップを計算します。私はこれらの洞察をmcp cms内で使用して、リサーチとSEOの両方を導きます。つまり、システムは単に記事を生成しているわけではありません。より良い出版決定を下すのに役立っています。
Google自身のSearch Console documentationは、これが重要である理由を裏付けています：検索パフォーマンスデータは最適化を導くべきであり、直感だけではありません。この原則をパイプライン内で直接使用しています。
データレイヤーが私に与えるもの
なぜここでデータが直感を上回るのか
私はクリエイティブな作業が好きですが、コンテンツ戦略には証拠が必要です。Search Consoleの信号を使用すると、どのページが助けを必要としているか、どのトピックが新しい記事に値するかを確認できます。これにより、mcp cmsは静的な管理パネルよりもはるかに有用になります。
なぜ読み取りパスと書き込みパスを分けたのか
私は意図的にブログの読み取り側と書き込み側を分離しました。公開ページはコンテンツレイヤーを通じてのみ読み取り、管理アクションは変異レイヤーを通じて書き込みます。これにより、レンダリングが迅速で、出版が安全になります。
この分割は重要です。なぜなら、各側には異なる役割があるからです。読み取りレイヤーはキャッシング、メタデータ、およびクリーンなフォールバック動作を必要とします。書き込みレイヤーは認証、検証、および制御された変異を必要とします。mcp cmsでは、両方のレイヤーが同じ契約を共有していますが、決して混ざり合うことはありません。
その分離は、将来のインターフェースを追加しやすくします。別のダッシュボードを構築する場合や、別のMCPクライアントを接続する場合、システム全体を再設計する必要はありません。私は新しいツールを同じ書き込み境界に指し示すだけです。
この分離が保護するもの
なぜこの構造を好むのか
私はすべてがすべてに話しかけるシステムが失敗するのを見てきました。このアーキテクチャはそのリスクを減らします。それはmcp cmsに安定したコアを与え、製品を進化させやすく保ちます。
実際の結果と実用的なトレードオフ
最大の結果は、派手なダッシュボードではありませんでした。それは影響力です。私は今、アイデアからリサーチされたアウトライン、ドラフト、SEOレビューに移動でき、ツールの間を行き来する必要がありません。それは時間を節約し、コンテキストを保持します。
また、システムが何をしているのかをよりよく把握できます。私はパイプラインを観察し、エージェントの決定を検査し、必要に応じてフローを調整できます。それは生の自動化速度よりも重要です。良いmcp cmsは、あなたのプロセスを強化するべきであり、より不透明にするべきではありません。
ただし、トレードオフがあります。カスタムシステムは、既製のCMSよりも多くのエンジニアリング努力を必要とします。あなたはバグ、機能、およびメンテナンスを所有します。私にとって、そのコストは価値があります。なぜなら、ワークフローが私のサイトとコンテンツ戦略に合っているからです。
私が得たもの
私がまだ管理しなければならないもの
現在のコンテンツオペレーティングシステムについての考え方
このプロジェクトは、私のコンテンツインフラストラクチャに対する考え方を変えました。私はもはやCMSソフトウェアを投稿を保存する場所とは見ていません。私はそれをコンテンツの作成、レビュー、および出版のためのオペレーティングシステムとして見ています。このマインドセットの変化が、なぜこのmcp cmsが装飾的ではなく有用に感じるのかの理由です。
もしあなたが似たようなものを構築しているなら、まずワークフローから始めてください。それから書き込み境界を定義します。その後、自動化に値するアクションのためだけにMCPツールを追加します。その順序がシステムを健全に保ちます。
また、AIエージェント、Next.jsでのeコマースのスケーリング、および私のSEOダッシュボードに関する関連記事を読むことをお勧めします。これらの作品は、このセットアップの背後にある構成要素を説明し、どのようにそれらが接続されるかを示しています。
結論
この構築からの主な教訓はシンプルです：
私はこのmcp cmsを、影響力、より良い可視性、およびクリーンな出版フローを提供するために構築しました。もしあなたが自分自身のコンテンツシステムを設計しているなら、ワークフローから始め、それに基づいてツールを形作ってください。
もしよろしければ、上記の関連投稿を読んだり、自分のCMSをどのように構築するかについてコメントを残してください。