Waldiumが人間とAIの両方に対応するブログプラットフォームを実現した方法

**タイトル: Waldiumがブログプラットフォームを人間とAIの両方に対応させる方法** Amrutha Gujjarは若い頃からソフトウェアを書いてきました。彼女を惹きつけたのは常に「構築する」という行為でした。製品ロジックを形作り、アーキテクチャを決定し、アイデアを実際のソフトウェアに変えることです。一方で、常に煩わしさの原因となっていたのが**インフラストラクチャ**周りでした。ポートの設定、**デプロイメント**設定、クラウド関連の問題などです。それらは常に、まさに最悪のタイミングで開発の勢いを削ぐものでした。 「構築自体に行き詰まることは一度もありませんでした」と彼女は言います。「問題は常に、その周囲にある**インフラストラクチャ**の摩擦でした。」 **インパクトの概要** * 単一のVercel**デプロイメント**から提供される500以上の顧客ブログ * 新規顧客がMCP**エンドポイント**をライブ状態にするまでの時間: **5分** * AIクエリの応答時間はグローバルで一貫して**50ms未満** * 顧客ごとの**デプロイメント**モデルと比較し、**インフラストラクチャ**コストを**45%削減** この煩わしさは、彼女がCTOのShivamとWaldiumを共同創業した際の設計原則となりました。この製品——企業向けにコンテンツリサーチと作成を自動化する**エージェンティックCMS**——は、その核心的な価値に集中し続ける必要がありました。**インフラストラクチャ**は「見えなく」なる必要があったのです。 それはほぼ実現しました。しかし、その理由を理解するには1年の歳月と、「ブログとは何か」についての新しい認識が必要でした。 **エージェントが読者層の一部となったとき** Waldiumは、ほとんどのコンテンツプラットフォームと同様、人間が読むためのブログを構築することから始まりました。しかし、Amruthaが気づき続けていたある変化が、ブログを「読む」主体を静かに変えつつありました。 「昨今、コンテンツを消費しているのは必ずしも人間とは限りません」と彼女は言います。「多くの場合、**エージェント**がコンテンツを消費しているのです。」 開発者や技術チームが、ブログコンテンツを自身のコーディング環境やClaude Desktop、ChatGPTに取り込み、実際に作業を行っているツール内でライブコンテキストとして利用し始めていました。ブラウザのタブもまだ利用されていましたが、もはや全てではありませんでした。それらの環境に持ち込めないコンテンツは、機会を逃していることになったのです。 この洞察が、Waldiumを適切な**プリミティブ**としての**MCP (Model Context Protocol)** へと導きました。もし全ての顧客ブログが独自のMCPサーバー**エンドポイント**を持てば、AIアシスタントは、誰も**ワークフロー**を離れることなく、そのコンテンツを直接検索、取得、対話できるようになります。開発者は、**エージェント**にブログアーカイブ全体から特定のコードスニペットを探すよう依頼し、まさに開発中の同じウィンドウで回答を得ることができるのです。 自身をマーケターとは考えていない技術系創業者にとって、これは全く新しい可能性を開くものでした。「**MCP**を利用できることで」とAmruthaは言います。「機能を開発しているのと同じ場所からブログ投稿を作成できるようになります。」 ビジョンは明確でした。問題は**インフラストラクチャ**でした。 **千のフロントページ、一つのコードベース** カスタムドメインにまたがる数百の顧客ブログをサポートすること自体、既に重要なエンジニアリング上の課題です。そこに、**サブドメイン**生成、**SSL証明書**、ライブインストールページを備えた独自ブランドのMCPサーバーを各ブログに付与しようとすれば、従来のアプローチはその重みに耐えきれず崩壊してしまいます。 WaldiumはAWS Amplifyで始めましたが、摩擦は絶え間ありませんでした。手動での接続が必要なGitHub Actions、複雑化する**デプロイメント**パイプライン、そして常に注意を**インフラストラクチャ**に向けざるを得ない全体モデル。彼らは早期にVercelへ移行しました。その違いは即座に現れました。 「開発者体験が非常にシームレスです」とAmruthaは言います。「チームが最も得意とする部分に集中できるようにしてくれます。」 特にWaldiumのMCP**インフラストラクチャ**における突破口となったのが、**Vercel Platforms**でした。単一の**Next.js**アプリケーションによって、チームは今、全ての顧客ブログ、全てのMCP**エンドポイント**、全てのカスタムドメインを、単一の統合された**デプロイメント**から提供しています。**Vercel Middleware**が動的にルーティングを処理するため、AI**エージェント**がクエリを送信すると、リクエストは自動的に適切な**テナント**に到達します。 **Vercel Domains API**は、カスタムドメインを数秒でプロビジョニングし、一切の手作業なしに**SSL証明書**を発行・更新します。WaldiumがMCP専用ホスティングツールを評価した際、**サブドメイン**の制限は比較になりませんでした。競合他社は数十件で上限に達していましたが、Vercelの上限は数万件です。 「スケールのことを心配せずに、スケールについて考えられるようになりました」とAmruthaは言います。 Shivamは、最も定着したものとしてこの全体的な認識モデルを挙げます。「今では非常にシンプルです。特定のgitブランチにプッシュし、プレビュー**デプロイメント**を取得し、本番**デプロイメント**を取得する。認証やデータベースともきれいに連携します。ただ、動作するのです。」アプリケーションと並行して配置され（別々のコンソールに分離されていない）NeonとUpstashによる統合ストレージ層は、チームに「システムの全部分を単一の画面で把握できる」環境をもたらしたと彼は言います。 結果はこうです。新規顧客がサインアップし、オンボーディング中に一意の**サブドメイン**が生成され、**サイトマップ**、**LLMs.txt**、**robots.txt**、MCPインストールページ、ライブMCP**エンドポイント**を、すべて**5分以内**に手に入れて去っていきます。 **数週間のリサーチから千の投稿へ** **インフラストラクチャ**の決定を真に試すのは、それが下流で何を可能にするかです。Waldiumの顧客にとって、MCP**エンドポイント**は以前は存在しなかった流通チャネルを開きました。彼らのコンテンツは、検索で発見可能であるだけでなく、AIアシスタント内で直接クエリ可能になったのです。 高度に技術的な教育コンテンツを公開する安全コンプライアンス企業、Sapra AIを例にとりましょう。以前は、コンテンツ更新の度にチームは数週間をかけた手動リサーチに直面し、誰かが数千ページに及ぶISO規格を読み込み、顧客に実際に役立つ部分を特定する必要がありました。 Waldiumでは、リサーチ**エージェント**のチームがこの作業を継続的に処理します。企業や業界のプロファイルを構築し、ニュース性のある動向にフラグを立て、従来のコンテンツチームでは到底及ばない量のコンテンツを生成します。Sapra AIは一ヶ月で1,000以上の投稿を生成しました。リサーチのタイムラインは数週間から数時間へと短縮されたのです。 Amruthaはこれを新たな必要条件と見ています。「以前、ビジネスを始める際にはランディングページが必要でした。今日、ビジネスを始めるなら、**LLM**が消費できる、自社に関するデータの**コーパス**を持たなければなりません。」Waldiumはその**コーパス**への最速の道を構築しており、**Vercel Platforms**は、その道を顧客ごとに一から再構築することなく、一度に数百の顧客に提供することを可能にしています。 「物事がどれほど良くなるかを一度知ってしまうと」とAmruthaは言います。「設計に対してそれほど意図的でない製品に戻るのは、本当に難しくなります。」彼女のチームはサーバーを管理していません。彼らは製品を**出荷**しているのです。 **Waldiumについて:** Waldiumは、企業向けにコンテンツリサーチと作成を自動化する**エージェンティックCMS**兼ブログホスティングプラットフォームです。すべての顧客に専用のMCP**エンドポイント**を提供することで、彼らのコンテンツはAIアシスタント内で直接アクセス可能になります。

Waldiumが人間とAIの両方に対応するブログプラットフォームを実現した方法

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト