MCPとAPIの境界線：日本の業務システム56選から読み解くAI連携の現実

「CRMと会計ソフトを連携させたい」「AIエージェントに分析を任せたい」――現場のIT担当者が直面するこの手の要望は、往々にして『技術的な迷宮』への入り口となる。Google検索を叩けば、REST、SOAP、GraphQL、gRPC、そして最近話題のMCP（Model Context Protocol）といったアルファベットの羅列が溢れ出し、結局どれから手を付ければいいのか分からず、深夜のオフィスで頭を抱えることになる。これは単なる知識不足ではない。APIという言葉が、あまりにも広義で、かつ文脈によって全く異なる実装を指しているからだ。

今回、日本の業務システム56件を対象とした調査結果は、我々エンジニアにとって極めて示唆に富む現実を突きつけている。まず大前提として、MCPはAPIの代替品ではない。調査対象の14システムすべてが、MCPサーバーと同時に従来のAPIも提供していた。つまり、MCPは「APIの進化系」ではなく、AIエージェントがシステムを自律的に操作するための『インターフェースの共通化レイヤー』として位置づけるべきだ。現場のエンジニアが陥りがちな「MCPさえあればAPIの設計は不要」という誤解は、即座に捨てる必要がある。MCPはあくまでAIが機能一覧を動的に取得するための窓口であり、その裏側で動く認証やレート制限、データ整合性の担保といった泥臭いAPIの設計思想は、依然としてシステム連携の根幹を成しているからだ。

我々がまず着手すべきは、MCPという新しい玩具に飛びつくことではなく、相手のシステムが「何を公開しているか」という冷徹な事実確認である。APIの形式がRESTなのか、SOAPなのか、あるいはGraphQLなのか。それによって、開発者が書くべきコードの構造も、エラーハンドリングの戦略も、そして何より「AIにどこまで権限を委譲できるか」というセキュリティ設計の難易度も劇的に変わる。この調査が示す通り、APIの形式すら公開していないシステムが16件も存在するという事実は、日本の業務システムにおける「ブラックボックス化」の深刻さを物語っている。仕様書を読み解く力、あるいは問い合わせ窓口を叩く泥臭いコミュニケーション能力こそが、最新のAI技術を実務に落とし込むための最大の武器となるのだ。

MCPと既存のAPI規格を同じ土俵で比較すると、その設計思想の違いが鮮明になる。RESTはURL設計という「住所」に意味を持たせるが、MCPはJSON-RPC 2.0をベースに、単一のエンドポイントへメッセージを投げる。ここで重要なのは、MCPが持つ『実行時の機能一覧公開（tools/list）』という機能だ。従来のREST APIでは、OpenAPI定義書を人間が読み解き、エンドポイントを一つずつ実装する必要があった。しかしMCPでは、AIが自ら「何ができるか」を問い合わせ、その結果に基づいて動的に呼び出しを行う。これは、開発者が深夜にコードを書き換えてAPIの変更に追従する、あの悪夢のような運用から解放される可能性を秘めている。

しかし、技術的な懸念も拭えない。MCPの仕様には「ステートレスであること」が明記されているが、これは裏を返せば、複雑な業務フローを実装する際には、開発者側でセッション管理や状態遷移の設計をすべて引き受けなければならないことを意味する。また、認証についても注意が必要だ。リモート型MCPサーバーはOAuth 2.1を前提としているが、ローカル型では環境変数やAPIトークンに依存する。セキュリティの観点から見れば、資格情報をどこに置くか、そしてAIに渡す権限をどこまで絞れるかという「認可の粒度」が、システム全体の堅牢性を左右する。以下の表は、今回の調査で明らかになった各方式の特性を整理したものである。

この表から読み取れるのは、MCPが「AIによる自律的な操作」に特化している一方で、既存のAPIは「システム間連携」という堅実な目的のために最適化されているという事実だ。特にレート制限（回数制限）については、MCPであろうとRESTであろうと、設計上の義務であることに変わりはない。AIは人間よりも遥かに高速にAPIを叩く。429 Too Many Requestsエラーを頻発させ、本番環境をダウンさせるような事態を避けるためには、MCPの導入以前に、各APIのレート制限を正確に把握し、バックオフ戦略を実装するエンジニアリングの基本に立ち返る必要がある。

結局のところ、我々エンジニアが明日から取るべき行動は極めてシンプルだ。まず、自社が利用している、あるいは導入を検討している業務システムのAPI仕様を、先入観を捨てて徹底的に洗い出すこと。APIが存在しない、あるいは形式が不明なシステムに対して、MCPの導入を夢見るのは時間の無駄である。まずは「読み取り専用」のAPIがあるか、書き込み権限をOAuthで細かく制御できるか、レート制限の数値は公開されているか、という5つのチェックリストを埋めることから始めよ。この調査で明らかになったように、freeeやマネーフォワードのようにAPIを積極的に公開している企業であっても、その制限や仕様は千差万別だ。数値が非公開であれば、それは「設計できない」というリスクとして認識し、小さく試して429エラーを観測するしかない。

また、セキュリティに対する「思考停止」を戒めたい。「クラウドにデータを出すから危険」という総務の懸念に対し、ローカル型MCPサーバーなら安全だという短絡的な回答は、エンジニアとして不誠実だ。ローカル型であっても、AIモデルの提供者にデータが渡る事実は変わらない。重要なのは、資格情報の置き場所と、AIに渡す権限の範囲（スコープ）をいかに最小化するかという設計思想である。APIキーを1本渡して「何でもできる」状態にするのか、OAuthで「このアプリのこの操作だけ」と制限するのか。この設計の差が、将来的な情報漏洩事故を防ぐ防波堤となる。

最後に、読者諸君に問いたい。我々は、AIが勝手にAPIを叩いてくれる未来を夢見ているが、その裏側にある「APIの設計図」を、機械が読める形で整備し続けているだろうか？　もし貴方の書いたAPIが、OpenAPI定義書すら存在せず、ドキュメントも更新されていないスパゲッティコードの塊だとしたら、どんなに優れたAIエージェントも、そのシステムを正しく操作することはできない。AI時代のエンジニアリングとは、AIを使いこなすことではなく、AIが正しく理解し、安全に操作できる「クリーンなインターフェース」を構築することに他ならないのではないか。貴方のシステムは、AIが自律的に動くための準備ができているか？　それとも、AIが迷子になるような「負の遺産」を放置し続けているだろうか？