Run it byと自前で作る場合の違い、そしてMCPエリシテーションとの違い

ひとことで言うと

フォームのあるページとデータベースのテーブルなら、半日で作れます。でも、見知らぬ相手に安心して送れるリンクで、どんなスキーマでもスマートフォンできれいに表示し、両側で検証し、期限切れになり、リマインドし、Webhookに署名して再送する、となると、数週間かかります。しかも、その後は自分で保守し続けることになります。MCPエリシテーションは別の道具です。すでにチャットにいる人に尋ねるものです。

「自前で作る」ことに含まれるもの

• 任意のスキーマに対応する描画処理:日付、enum、配列、同意ボックス、セクション、スライダー、モバイルレイアウト、再読み込みしても残る下書き。
• 2回の検証:相手のためにブラウザで、そして手作りのPOSTをすり抜けさせないようにサーバーで。
• 安全に共有できるリンク:推測できないトークン、1人に1つ、有効期限、早期のクローズ、リンクが無効になったときのわかりやすいページ。
• 配信:署名付きWebhook、バックオフ付きの再送、Webhookが失敗したときに回答を読み取る手段。
• フォローアップ:まだ回答していない人の把握、迷惑にならないリマインダー、承認のためのメールコード。
• 不正利用への対策:レート制限、公開リンクのボット判定、パスワードやカード番号を求めるフォームの拒否。エージェントが作るフォームのリンクは、フィッシングに悪用されやすいからです。
• 保持期間:回答を予定どおりに削除する仕組みと、回答する人まで対象にしたプライバシーポリシー。

どれも単体では難しくありません。でも全部まとめると1つのプロダクトになり、それは、あなたが作ろうとしていたものではありません。

自前で作るのが正解なとき

• データを特定のリージョンや自社のインフラ内に置く必要がある。Run it byはUS-Eastの1リージョンにデータを保存し、EU内のみでの保存にはまだ対応していません。
• SOC 2やHIPAAなどの認証が今すぐ必要。当サービスにはまだありません。
• フォームがプロダクトの中核で、完全に独自のUIが必要。

MCPエリシテーションは、チャットの中の相手に聞く

Model Context Protocolにはエリシテーションという機能があります。セッションの途中で、MCPサーバーがクライアントに頼んで、ユーザーに小さなフォームを表示してもらう仕組みです。必要な相手が、いまエージェントを使っている本人なら、これが適した道具です。

意図的にシンプルにできています。スキーマは文字列・数値・真偽値・enumだけのフラットなオブジェクトで、回答は承認・却下・キャンセルのいずれかです。サーバーがパスワードやキーを尋ねるために使ってはならないことになっています。新しい版の仕様では、ユーザーを外部ページに案内するURLモードも加わりました。対応状況はクライアントによって異なるので、お使いのクライアントのドキュメントで確認してください。

エリシテーションとRun it by

多くのエージェントは両方が必要です。ユーザーに手早く尋ねるにはエリシテーション、ほかの誰かから回答をもらう必要があるときはリンク。後者を試すには、Claude CodeやCodexからコマンド1つでMCPサーバーを追加してください。手順はドキュメントにあります。