チームで実験を行いました：
私たち各自が、Cursorに対して複数回、PayPal APIをEC（eコマース）アプリに組み込むよう依頼しました。
以下は、すべての試行を通した結果です：
- 試行の13%で、廃止予定のPayPal SDKが読み込まれた
- 試行の87%で、廃止予定のPayPalドキュメントに基づくAPI呼び出しが生成された
- 試行の0%で、現在の公式PayPal Server SDKが使用された
注目すべきポイントがあります。PayPalは、自社のAPI向けに公式のAPIドキュメントとSDKを提供しています。それでもAIはそれらを一度も使いませんでした。代わりに、ブログ記事、Stack Overflowの回答、そして古い学習データ（PayPalは非常に有名なAPIなので）を寄せ集めてコードを組み立てたのです。
これはPayPal固有の問題ではありません。世の中には無数のAPIがあります。ドキュメントは変わります。SDKは進化します。新しいAPIバージョンも登場します。
AIアシスタントがWeb検索やモデルの記憶だけでAPI統合を試みると、誤りはほぼ避けられません。開発者は、そもそもAIを使うことで節約できた時間よりも、AIの出力をデバッグする時間に多くを費やしてしまいます。
How we solved this problem
私たちはContext Pluginsを構築しました。OpenAPIの仕様が与えられれば、SDKを生成し、MCPサーバーを用意して、AIのコーディングアシスタントに構造化されたAPIコンテキストを公開します。
これにより、古い学習データやGitHubからかき集めたコードに頼るのではなく、SDKドキュメントやAPI統合パターンを含む包括的で最新のAPIコンテキストが、Cursorのようなツールから参照できるようになります。
仕組みは次のとおりです：
- API提供者がOpenAPIの仕様をAPIMaticにアップロードする
- 私たちが複数のプログラミング言語で高品質なSDKを生成する
- LLM向けに最適化した、言語固有のSDKコンテキストを公開するツールとプロンプトを備えたMCPサーバーを生成する
- 開発者がMCPサーバーをIDE（Cursor、Claude Code、またはGitHub Copilot）にインストールする
開発者がAPI統合を依頼すると、コーディングアシスタントがMCPサーバーに問い合わせ、必要なコンテキスト（認証フロー、統合パターン、最新のSDKバージョン、SDKインターフェース）を取得し、当て推量ではなく公式SDKを使ってコードを生成します。
途中で得られた重要な洞察は次のとおりです：
OpenAPIの仕様やAPI Referenceドキュメントだけでは、AIエージェントに十分なコンテキストになりません。 それらはエンドポイント/操作とスキーマを説明しますが、AIはそれでも認証の扱い、ページネーション、エラーハンドリングをどうするかを推測し、そのすべてを動作するコードに変換しなければなりません。これは推測の長い鎖であり、追加のステップが増えるほど、失敗する可能性が増えます。
SDKとSDKコンテキストは、その鎖を短くします。複雑さの大部分はライブラリにすでに包み込まれているため、モデルは統合をゼロから作り上げるのではなく、どのメソッドを呼び出し、どのように組み合わせるべきかを把握できます。
The benchmarks
私たちは、実運用の2つの.NETアプリケーションで、4つの統制実験を行いました。nopCommerce（成熟したECプラットフォーム）とeShop（Microsoftの.NET参照アプリ）です。
同じIDEとモデルで、Context Pluginsの有無を変えて同一のタスクを実行しました。
Aggregate results across all 4 experiments:
| 指標 | プラグインなし | プラグインあり | 改善 |
|---|---|---|---|
| エラー | 平均16 | 平均1.5 | ↓ 91% |
| 必要なプロンプト数 | 平均34 | 平均15.5 | ↓ 54% |
| 消費トークン数 | 平均57M | 平均20M | ↓ 65% |
| 手動修正 | 平均2.75 | 0 | ↓ 100% |
What went wrong without the plugin (real examples):
-
SDKクラスが存在しないと“幻覚”した—エージェントは
OAuthAuthorizationControllerがSDK内にないと判断し、独自の置き換えを作成した - 推測による29件以上のコンパイルエラー（モデルの形、列挙型、名前空間など）
-
セキュリティ脆弱性—URLインジェクションにより、IDの不一致があっても注文を取得可能にした；
?paid=1というクエリパラメータが誤って決済承認を引き起こした - 廃止予定のSDKバージョンを選択—v2.0.0を使うよう指示されていたにもかかわらず
- Web検索のAPI知識に依存したときの33%の“幻覚”率
What happened with the plugin:
- すべての実験で“幻覚”はゼロ
- 生成されたコードに必要な手動修正はゼロ
- エージェントがコードを書く前に、MCPツール呼び出しで知識を事前に検証した
- 4回の実験のうち3回で、最初の試行からコンパイルが通った
- eShopの統合における200行以上の手動HTTPボイラープレートを削減
- AIは平均で統合を2倍の速さで完了した
詳細な実験ログ付きの全文のケーススタディはこちら： Context Plugins Case Study
Try it yourself
プロダクトのショーケースで、いくつかのAPI向けにContext Pluginsを公開しています。最も早く試す方法はこちらです：
Try the Context Plugins Showcase
APIを選んで（PayPal、Twilio、Stripe、Google Maps、Spotify、Slack、Adyenなど）、IDEにMCPサーバーをインストールし、構築を始めてください。
What we learned from developers trying this
私たちのベンチマークと初期のユーザーテストから、いくつかのパターンが見えてきました：
信頼は“根拠（grounding）”に従ってついてくる。 モデルがSDKのメソッド名やライブラリのドキュメントを、目に見える形で参照している場合、AIの出力に対する開発者の安心感は大きくなります。Web検索や学習データをつぎはぎしているように見える場合とは対照的です。アウトプットの正しさと同じくらい、コンテキストの出どころが重要です。
返却形式: {"translated": "翻訳されたHTML"}「二重責任」問題は実際にあります。 AIエージェントが、API の調査 と統合の実装を同時に行わなければならない場合、どちらの品質も低下します。コンテキストプラグインはそれらの関心事を分離します——MCPサーバーが権威あるAPI知識を提供し、エージェントがコーディングを担当します。この分業は一貫してより良い結果を生み出します。
開発者はすでに、この問題への解決策をいろいろ工夫して実現しています。 開発者は、自分でスキルや AGENT.md ファイルを書いて、AIエージェントが使用するAPIに対して正しい統合コードを書けるようにしようとします。これは試行錯誤を伴い、APIが進化するのに合わせてローカルのコンテキストを継続的に更新する必要があります。
ぜひコミュニティの皆さんの声を聞きたいです：
- 遭遇した最悪の、AI生成によるAPI統合のバグは何ですか？ 障害パターンを収集して、コンテキストのカバー範囲を改善しています。ゾッとするような話も大歓迎です。
- コーディング支援ツールのために、現在どのようにAPIコンテキストを扱っていますか？ AGENTS.md ファイルですか？ カスタムMCPサーバーですか？ それとも別の方法でしょうか？
