メッセージングプラットフォームはどれも、自前の API を作ります。独自のキー、独自の Webhook の形式、独自のエラーの考え方です。そのうち 5 つをひとつの製品の裏に置くと、チームは、ロゴだけが同じ 5 つの連携を保守することになります。私たちは逆の道を選びました。
どこでも同じもの
- キー。X-API-KEY ヘッダーに入れた 1 つの API キーで、LinkedIn API、Inbox API、WhatsApp API、Discord API、X API に届きます。組織を決めるのはキーで、何を指定してよいかを決めるのは組織です。
- 境界。組織のものではないものはすべて 404 を返します。403 ではありません。推測した ID からは何も分かりません。
- エラー。JSON の形は 1 つで、{"type":"errors/<code>","status":<n>,"detail":"..."} です。detail は人に見せる前提で書かれています。
- Webhook。エンドポイントの仕組みは 1 つで、署名の方法も同じ。LinkedIn API のイベントも各チャネルのイベントも、同じように届けます。
- プラン。シートは、いちばん多いもので数え、サブスクリプションも 30 日の試用も 1 つです。
AI エージェントが得るもの
MCP サーバーとは、ツールの一覧と、それらがどう振る舞うかについての約束です。どのチャネルも同じ約束を守るので、ひとつの AI エージェントが 5 つの方言を覚えずにすべてを扱えます。/mcp のオールインワンのエージェントはすべてのツールを持ち、各チャネルのエージェント(/inbox/mcp、/whatsapp/mcp、/discord/mcp、/x/mcp)は自分のチャネルのツールだけを持ちます。ひとつのチャネルだけに触れさせたいアシスタント向けです。
同じエージェントは、Claude でも、ChatGPT でも、MCP に対応するほかのものでも、そしてプロジェクトルームの中でも動きます。ルームでは、人が各呼び出しとその答えを、起きるそばから見られます。
これだけのことの代償は、チャネルが少しだけそのチャネルらしさを失うことです。プラットフォームごとの癖は残っていて、各リファレンスがそれを示しています。ただ、すべて同じ入口の向こうにあるだけです。
よくある質問
アシスタントには、オールインワンのエージェントと、ひとつのチャネルのエージェントのどちらを渡すべきですか？
ひとつのチャネルだけに触れさせたいなら、そのチャネルのものを。WhatsApp に答えるアシスタントが LinkedIn のツールを持つ理由はありません。オールインワンのエージェントは、自分で一緒に作業するアシスタント向けです。
ひとつの Webhook エンドポイントで、すべてのチャネルのイベントを受けられますか？
はい。LinkedIn API と各チャネルのイベントをまとめて、受けたいものを指定して 1 回登録し、そのすべてで同じ署名を確認してください。