「仕事ごとのベストツール」アプローチの問題点
どのECビジネスも、最終的には同じ構成スタックに行き着きます：
- Shopify：ストアフロントと受注
- HubSpot（または同等のもの）：CRM
- ShipStation または Bosta：配送
- Zendesk：カスタマーサポート
- WhatsApp Business API：メッセージング
- 在庫用のスプレッドシート（など）
各ツール自体はどれも問題ありません。しかし、AIエージェントにビジネス運用を管理させようとすると、すぐに壁にぶつかります。
エージェントには次のようなことが必要になります：
- 今日の注文の一覧を取得する（Shopify API）
- 顧客がVIPかどうか確認する（HubSpot API）
- 在庫の利用可能状況を確認する（倉庫システム — おそらくスプレッドシート？）
- 配送ラベルを作成する（ShipStation API）
- 追跡情報とともに顧客へメッセージを送る（WhatsApp API）
- やり取りを記録する（HubSpot APIへ）
これが5種類の異なる認証設定、5種類の異なるAPIスキーマ、5種類の異なるレート制限、そして5種類の異なる失敗パターン——シンプルなワークフロー一つのために必要です。
私たちはこれを解決するために Nexus を作りました。そしてそれを単一のMCPサーバー経由で公開しました。
MCPとは何か、なぜ重要なのか？
MCP（Model Context Protocol）は、Anthropicによるオープン標準で、AIエージェントが外部システムと、構造化されたツールベースの方法で通信できるようにします。
エージェントが生のHTTPリクエストを書いてJSONレスポンスを解析するのではなく、tools — 型付きの入力と出力を持つ名前付き関数 — を呼び出します。エージェントは、どのツールが存在し、何をするのか、そして何が返ってくるのかを理解しています。
実際の違いは次の通りです：
MCP以前： エージェントが fetch('https://api.shopify.com/v1/orders?...') を書き、レスポンスを解析して注文を抽出し、CRMデータ用の別のAPIを呼び出し、両者を関連付けようとします。おそらくエッジケースで失敗します。
MCPの場合： エージェントが nexus_get_order({ order_id: "ORD-2026-001" }) を呼び出し、顧客情報、注文ステータス、明細（ラインアイテム）、配送状況、支払い情報などを含む完全なオブジェクトを1回の呼び出しで受け取ります。
13個のツール、1つのサーバー
NexusのMCPサーバーは、5つの機能領域にまたがって13個のツールを公開しています：
Contacts（CRM）
-
nexus_list_contacts— 検索付きのページネーションされた連絡先リスト -
nexus_get_contact— 顧客360：履歴、注文、セグメント -
nexus_create_contact— 重複排除（デデュープ）による保護付きで作成 -
nexus_update_contact— 詳細とジャーニーステージを更新
Orders
-
nexus_list_orders— ステータス、顧客、日付でフィルタ -
nexus_get_order— 明細（ラインアイテム）とタイムライン付きの完全な注文 -
nexus_create_order— 明細（ラインアイテム）付きで注文を作成 -
nexus_update_order_status— ライフサイクルを通じてステータスを移動
Inventory
-
nexus_list_inventory— 商品とバリアントを閲覧 -
nexus_check_stock— 指定した倉庫での在庫状況を確認
Messaging
-
nexus_list_conversations— WhatsApp、FB、IGにまたがる統合インボックス -
nexus_send_message— 1回の呼び出しで任意のチャネルから送信
Search
-
nexus_search— 連絡先、注文、在庫に対するグローバル検索
1つの登録、1つの認証、1つの接続
これを作る過程で私たちが最も驚いたのは、既存のMCP設定にはどれほど摩擦（手間）が存在するかです。
私が見てきたすべてのMCPサーバーでは、人間が次を行う必要があります：
- アカウントを手作業で作成する
- 開発者設定へ移動する
- APIキーを生成する
- それらをエージェントの設定にコピーする
これは開発者向けのセットアップなら問題ありません。しかし、自律的に動くはずのエージェントにとっては致命的な障害（ディールブレーカー）です。
私たちは最初から Nexus にエージェントの自己登録を組み込みました。エージェントは：
POST /agent-register
{
"agent_name": "My Assistant",
"agent_platform": "claude",
"owner_email": "owner@company.com",
"organization_name": "My Company"
}
そして、すぐにAPIキーが返ってきます。メール認証は不要。CAPTCHAも不要。人間が介在する仕組みもありません。
そこからは、認証の呼び出しが1回、MCP接続が1回で済み、エージェントは運用スタック全体にアクセスできます。
ビジネスモデルのイノベーション
私が最も面白いと思うのはここです：エージェントが成長チャネルになったという点です。
無料プランは意図的に読み取り専用です。エージェントは探索して、連絡先を読み、注文を閲覧し、在庫を確認できますが、実行（行動）はできません。
エージェントが書き込みを必要とする瞬間——注文を作成する、メッセージを送る、連絡先を更新する——そのときは Starter（$99/月）以上が必要になります。
これにより、自然なコンバージョンファネルが生まれます：
- エージェントが無料プランで自己登録する
- エージェントが価値を実証する（データを読み取り、洞察を生成する）
- 人間がアップグレードして、エージェントに実行権限を与える
- エージェントはより多くできる→より価値が増える→サブスクリプションがより定着する
コールドコールなし。デモなし。エージェントが自分自身を売り込みます。
スタック
どのようにこれを作ったか気になる方のために：
- Database： Supabase（PostgreSQL）。143テーブル、マルチテナントRLS
- Edge Functions： DenoベースのSupabase Edge Functions（約117関数）
- MCP Transport： Streamable HTTP（MCP protocol 2025-03-26）
- Auth： APIキー交換から得られる短命（short-lived）のJWT
-
Discovery：
.well-known/mcp.json+llms.txt（ルートドメイン）
MCPサーバー本体は、単一のSupabase Edge Functionです。すべてのツール呼び出しを受け取り、内部ハンドラへルーティングして、構造化されたレスポンスを返します。別サーバーを維持する必要はありません。
使ってみる
完全なシステムは現在稼働しており、エージェントからアクセス可能です：
- Docs： nexus-docs.aiforstartups.io
- MCPディスカバリー： nexus.aiforstartups.io/.well-known/mcp.json
- エージェントのクイックスタート： nexus-docs.aiforstartups.io/api/ai-agents-mcp
AiForStartupsが作成。カイロで制作。
