1つのコード、2つの形に。AI ツール開発の二重手間をなくす

MCP って何？API との違いは？

MCP は Claude や他の AI が外部ツールを使うための通信プロトコル。API との違いは、相手が「人間か AI か」なんです。 API は HTTP リクエスト・レスポンス。ブラウザから、スマホアプリから、人間が操作する何かから呼ばれることを想定している。だから URL があったり、JSON をやり取りしたり、エラーメッセージも人間向け。 MCP は人間を経由しない。AI エージェントが直接、「こういうツールが欲しい」と要求する形になってる。背景には AI がどう使うかという流儀がある。たとえば「このツールの説明」「パラメータの型と制約」「戻り値の形式」。AI が自動でこれらを理解して、自分で必要かどうか判断して呼び出す。 同じロジック（たとえば「メール送信」）でも、API 形式だと「POST /send-email に JSON を投げる」という書き方。MCP 形式だと「send-email というツール定義」になる。見た目は全く違う。だから開発者は両方を保守する羽目になっていたわけです。HarnessAPI は「ロジックは 1 つ書いて、両形式で自動変換しちゃおう」という発想に見えます。

ChatGPT とか Claude を仕事で使ってる一般ユーザーにとって、このフレームワークが存在することで何が変わるの？

一般ユーザー視点では、直接的には何も変わらないんですよね。HarnessAPI はあくまで「開発者の裏側の話」です。ただ、その意味を考えると見えてくることがあります。 AI ツール開発が楽になるということは、いま「手間だから作られていないツール」が増える可能性があるということ。たとえば、社内の業務システムに ChatGPT を繋ぎたいけど、API とMCP の両方対応が面倒で放置していた案件。こういった小さく実用的なツールが、ハードルが下がることで実装されやすくなる。結果として、あなたが使う AI が「より自社に最適化された、ニッチなツール群」に繋がるようになる可能性がある。 逆に言えば、いま ChatGPT や Claude が「できることの限界」には、開発者側の「手間」が隠れていたわけです。その手間が 74% 削減されるなら、その分、より多くの業務ツール化が進むと考えてもおかしくない。仕事で使う AI の使い勝手が、目に見えない形で少しずつ良くなっていくかもしれません。

なぜこれまで、同じロジックを 2 回書き直す必要があったの？技術的に避けられないものだったの？

API と MCP って、もともと全く別の用途で作られた仕様だったんですよね。API は「インターネット経由で誰でもアクセスするもの」、MCP は「AI エージェント専用の通信方式」という感じで。だから仕様書も異なり、パラメータの渡し方も、レスポンスの形式も違う。開発者が共通部分を抽出する仕組みがなかったから、「同じ機能だけど、2 つの言語で書き直す」みたいな事態が起きていた。 技術的に避けられなかったというより、「誰も統一フレームワークを作ってなかった」というのが正しいのかもしれません。それぞれのエコシステムが独立して発展しちゃったから。でも考えてみると、この問題は「型定義」を一つ中心に据えれば、あとは自動生成で何とかなりそう。そこに目をつけたのが HarnessAPI ということなんでしょう。必然的な二重手間じゃなく、ツール化の遅れだったわけです。

これって『同じ仕事を複数の形式で繰り返さなきゃいけない』という、ソフトウェア開発全般にありがちな問題の一つなの？

ソフトウェア開発全般の問題というより、AI ツール化という新しい領域だからこそ顕著になった問題に見えます。 従来、ウェブアプリケーションなら一つの実装方法で済みました。API として一度書けば、フロントエンドもモバイルアプリも、その API を呼ぶだけ。形式は統一されていた。 ところが AI が登場したことで、ツールの「使われ方」が一気に増えてしまった。ChatGPT に使わせるには MCP の形式が必要。一方、ユーザーが直接呼び出すには HTTP API が便利。同じ「ツールとしてのロジック」なのに、外側の形式が二重に存在する。 HarnessAPI が問題を解くのは、この形式の重複を「自動化」で吸収しているわけです。なるほど。 実は似た構造は昔からもあります。同じビジネスロジックを、Web UI と API と CLI で並行実装するとか。でも今回は、AI という「新しい顧客」が突然現れたから、既存の実装との両立を強いられた。その対応が遅れた領域だからこそ、フレームワークが出てくる隙間があったのかもしれません。

フレームワークが自動化することで開発が楽になる一方で、『わざわざ 2 回書く』ことで気づいてた問題や工夫が、見落とされるようになる危険性はないの？

興味深い危険性を指摘していますね。ただ、現場的には逆かもしれません。 いま開発者が「同じロジックを 2 回書く」ときって、1 回目と 2 回目で微妙に実装が違ったり、API の仕様とMCP の仕様の差分を処理するために工夫を加えたりしています。その工夫の多くは「本来は不要な対応」なんです。2 つの形式の違いに対応するための機械的な手作業。 HarnessAPI が自動生成することで失うのは、そうした「余計な工夫」です。逆に、自動生成する仕組み自体が、2 つの形式の齟齬を最初から排除している。手書きで気づく問題より、仕様の矛盾そのものを消してしまう方が根本的な解決と言えるかもしれません。 本当に危ないのは逆側で、フレームワークの抽象度が高すぎて、実際には API と MCP で必要な細かい仕様の違い（レスポンス形式の細部、エラーハンドリング、タイムアウト）が隠れてしまうケースですね。自動化のツケが後で出てくる可能性はありそうです。