REST APIからMCPサーバーへ、10分で移行

REST APIがあるなら、MCPサーバーの90%はもう持っている。これは誰も教えてくれないことだ。

エンドポイントはそのままツールになる。リクエストスキーマはそのまま入力スキーマになる。レスポンスの形はそのまま出力型になる。対応関係はほとんど恥ずかしいくらい直接的だ。

POST /users/create？それはcreate_userツールだ。GET /orders/:id？それはget_orderだ。パラメータの型、バリデーションルール、エラーの形式 — すべてもう書いてある。OpenAPIの仕様も含めれば、おそらく二回書いている。

唯一足りないのは翻訳レイヤーだ。そして — ここが落とし穴になる — 良い説明文だ。「description: ユーザーを作成します」ではない。LLMが実際に推論できる説明文だ。この違いは、君が思っている以上に重要だ。

MCPツールはRESTエンドポイントにほぼ1:1で対応する。これは偶然ではない。どちらも根本的に同じ問いに答えている：このサービスは何ができて、どうやって頼めばいいのか？

スキーマの変換は機械的だ。JSON Schemaが入って、JSON Schemaが出る。必須フィールドは必須のまま。Enumはenumのまま。ネストされたオブジェクトはネストされたまま。目を細めれば、MCPツール定義はエルゴノミクスが改善されたOpenAPIオペレーションに見える。

変換を自動化することもできる。我々は自動化した。構造的なマッピングは解決済みの問題だ。考える必要はない。

考える必要があるのは、構造が捉えきれないすべてのことだ。暗黙の契約。順序の依存関係。「このエンドポイントを呼ぶ前にあのエンドポイントを呼ぶな」というチームの頭の中にだけある知識。それが本当の翻訳作業だ。

ここで大半の移行が失敗する。そして、予想とは違う理由でだ。

エンドポイント名をコピーして、OpenAPIスペックからスキーマを生成して、デプロイする。すべて素晴らしく見える。ツール定義はきれいだ。型は正しい。生産性を感じる。

するとLLMがupdate_userを呼ぶべきところでcreate_userを呼ぶ。なぜか？両方の説明文が「ユーザーデータを管理する」と書いてあるからだ。URLパスを読んで違いを理解する開発者のために書いた説明文だ。LLMはURLパスを読まない。説明文を読む。

説明文は曖昧さがなく、具体的で、システムを一度も見たことがなく今後も見ることのない読者のために書かれている必要がある。「提供されたメールアドレスとパスワードで新しいユーザーアカウントを作成する。生成されたIDを持つ作成済みユーザーオブジェクトを返す。メールアドレスが既に登録されている場合は失敗する。」これがLLMが使える説明文だ。

これが移行の本当に大変な仕事だ。配管工事ではなく — 命名だ。

ここにショートカットがある。SmeltSecをOpenAPIスペックかGitHubリポジトリに向ける。それだけだ。それが出発点だ。

エンドポイントを読み取り、ルート構造と既存のドキュメントから意図を推測し、適切なスキーマを持つMCPツールを生成し、LLMが実際にパースできる説明文を書く。そしてツールポイズニングのベクターや過度に寛容な入力スキーマを検出するセキュリティスキャンを実行する。

タイトルの10分は大盤振る舞いだ。ほとんどのリポジトリは60秒もかからない。ボトルネックは生成ではない — 出力をレビューして、説明文が各ツールの動作を正確に捉えているかを判断する君自身だ。

これをすべて手作業でやることもできる。週末を丸々使うだろう。スキーマは正しくできて、説明文は間違える。良い説明文を書くことは、ほとんどのバックエンドエンジニアが開発する必要がなかったスキルだからだ。これは退屈だが重要な仕事で、ツールが処理すべきものだ。

MCPへの変換で驚くのは、変換そのものではない。その後に起きることだ。

APIに突然、予想していなかった新しい消費者が現れる。AIエージェントがテストしたことのない方法でツールを呼び始める。まったく無関係なサービスの他のツールと君のツールを組み合わせる — カレンダーツールが君の決済ツールを呼び、それが通知ツールを呼ぶ。すべてワークフローを自力で解明したLLMが指揮している。

もうAPIを構築しているのではない。エコシステムに貢献しているのだ。ツールは、設計していないし予測もできないシステムの構成要素になる。

統合の全面をコントロールすることに慣れているなら、これは居心地が悪い。だが、これが何を意味するか気づけば興奮する：サービスが想像もできなかった方法で有用になり、会うことのないユーザーに使われ、存在すら知らなかった問題を解決している。

これが切り替える本当の理由だ。MCPがより新しいとかトレンドだからではない。君の仕事をもっと大きな世界で意味のあるものにするからだ。