MCPの前に改めてAPIとSDKを学ぶ

「つながる世界」を実現する仕組みを理解する

mitsui

May 24, 2025

おはようございます。
web3リサーチャーのmitsuiです。

今日はweb3の基礎の基礎レポートということで「APIとSDKとMCP」について深堀します。

ぜひ最後までご覧ください！

1、APIの背景と誕生
2、APIの定義と種類
3、Web2時代のAPI活用と事例
4、web3時代のAPI活用と事例
5、SDKの背景と誕生
6、SDKの定義と特徴
7、web3時代のSDK活用例
8、まとめと後編へのつなぎ

🧵TL;DR

APIは、異なるソフトウェア同士をつなぐインターフェースとして登場し、Web2時代に“マッシュアップ”や“APIエコノミー”を生んだ。
RESTの普及により、データのやり取りがシンプル化され、Webサービスの連携や拡張が飛躍的に進んだ。
SDKは、APIを扱いやすくする開発者向けの“道具箱”であり、web3ではウォレット接続やマルチチェーン対応に必須の存在。
web3でもAPIとSDKは重要であり、後編ではそれらを土台にAIとブロックチェーンをつなぐMCPについて詳しく掘り下げていく。

はじめに：なぜAPIとSDKが注目されるのか

インターネットが普及し始めてから、私たちの生活は飛躍的に便利になりました。

SNSを通じて友人とつながり、ネット通販で世界中の商品を購入し、スマホのアプリを使って日々のタスクを効率化しています。そうしたサービス同士が連携して、さらに便利な世界をつくり上げる裏側では、「API」と「SDK」という仕組みが大きな役割を担っています。

一方で近年は、ブロックチェーンをはじめとするweb3と呼ばれる技術領域が注目を集めています。NFTやDeFiなど、これまでにない形の価値交換や金融サービスが誕生し、デジタル資産を扱う文化が広がってきました。こうしたweb3の世界でも、従来のWebサービスと同じく「データや機能を外部と連携する仕組み」が必要不可欠です。そこで活躍するのが、やはりAPIとSDKです。

今回の連載では、非技術者の方でも「なるほど、APIやSDKってそういう歴史があって、こういう仕組みなんだ」と腑に落ちるように、なるべく専門用語をかみ砕きながら解説していきます。

後編では、これらの土台の上に登場した新しい概念であるMCP（Model Context Protocol）について、背景や意義、技術的要素を深く掘り下げます。まずは「つながる世界」を支えるAPIとSDKの基礎を、一緒に見ていきましょう。

第1章：APIの背景と誕生

1-1. モノリシックからモジュール化への流れ

コンピュータがビジネスで本格的に使われ始めた当初、多くの企業システムは「モノリシック（一体型）」と呼ばれる構造をしていました。

要するに、1つの大きなプログラムにあらゆる機能が詰め込まれ、外部との連携をあまり想定していない状態です。この構造は新機能を追加・改修する際に大きな影響が出やすく、柔軟性に欠けるという課題がありました。

やがて、インターネットが普及し始めると、システム同士を連携させて新しい価値を生み出したいというニーズが高まります。

例えば、社内で使う在庫管理システムと、オンラインショップのカート機能を連携して、在庫数をリアルタイムに把握したい。あるいは地図サービスのデータを使って、自社の店舗情報をマップ上に表示したい。こうした要望に応える仕組みとして、「ソフトウェア間のインターフェース」を明確にする考え方が注目されました。

1-2. 初期の分散システム技術：CORBAやSOAP

APIが広く認知される以前、分散システム間の通信を可能にする技術としてCORBA（Common Object Request Broker Architecture）やSOAP（Simple Object Access Protocol）といった仕組みが登場しました。いずれも「リモートのプログラムを呼び出す」という点ではAPIと同様ですが、非常に複雑な設定や専用のツールが必要で、導入や運用のハードルが高かったのです。

CORBA
企業の大規模システム間連携に使われた標準規格ですが、オブジェクト指向の概念を重厚に取り入れていたため、運用には専門技術者の知識と大掛かりなサーバ構成が必要でした。
SOAP
XMLというマークアップ言語を使った通信プロトコル。標準化が進んだ反面、メッセージフォーマットが冗長になりがちで、開発者にとって扱いが難しい面もありました。

こうした技術は企業の基幹システムや金融機関などで利用されていましたが、一般のWebサービスにはなかなか広がりませんでした。より簡単で軽量な仕組みが望まれていたのです。

1-3. RESTの誕生と普及

そこで2000年代前半に登場したのが、REST（Representational State Transfer）という考え方です。これはHTTPというWebの標準プロトコルをそのまま使い、「GET」「POST」「PUT」「DELETE」などシンプルなメソッドでデータを操作しよう、という発想でした。複雑な規格に頼らず、軽量なテキスト形式（JSONやXML）でデータをやり取りできる点が受け入れられ、徐々に世の中のWebサービスがRESTスタイルのAPIを提供し始めたのです。

Google Maps API
開発者が地図を自分のサイトに埋め込んだり、地図上に独自のマーカーを表示したりできるようになった。その結果、飲食店検索や不動産情報などと組み合わせた新たなサービス（マッシュアップ）がブームを巻き起こす。
Twitter API
ツイートの読み書きを外部アプリから行えるようになり、周辺サービスが多数登場。まとめサイトや分析ツールなどが生まれ、Twitter自体のユーザー体験も向上。

このように、「APIを公開することで、外部の開発者や企業が自分たちのサービスを拡張し、新しいビジネスを作り出す」という流れが一気に加速。いわゆる「APIエコノミー」と呼ばれる市場が形づくられました。

第2章：APIの定義と種類

2-1. APIとは何か

API（Application Programming Interface）とは、直訳すると「アプリケーションのためのインターフェース」です。プログラム同士が「どんなリクエスト（要求）を送れば、どんなレスポンス（応答）が返ってくるか」を約束事として定義したもの、と言えます。

非技術者向けに例えるなら、レストランのメニューと注文システムのようなものです。

お客さんが「〇〇をください」という注文（リクエスト）をすると
レストラン側が注文を受け、料理（レスポンス）を提供する

このとき、客は「何を注文すればどんなものが返ってくるか」を知っている必要がありますし、レストラン側も「注文票をこう書いてもらえれば、これを出す」という約束を定めている。まさにAPIは、この“やり取り”のルールを機械同士で行うための取り決めなのです。

2-2. APIの主な種類

APIには、大きく分けて次のような種類があります。

REST API
- HTTPメソッド（GET/POST/PUT/DELETEなど）を使い、JSONやXML形式でデータをやり取りする
- 一番広く普及しており、Webサービス同士の連携に多用される
GraphQL
- Facebook（現Meta）が提唱したクエリ言語。必要なデータだけを取得できる利点がある
- RESTに比べて柔軟なデータ取得が可能だが、導入や設計にノウハウが必要
gRPC
- Googleが中心となって開発した高速通信プロトコル。Protocol Buffersというバイナリ形式を使う
- 大規模マイクロサービス間での高速連携などに用いられる
WebSocket
- サーバとクライアントが常時接続を維持し、リアルタイムで双方向通信ができる
- チャットアプリやゲーム、取引所の注文板など、即時性が求められる場面で活躍

web3の文脈でも、上記のREST APIやWebSocketを使ってブロックチェーンノードやデータインデックスサービスへアクセスするケースが多いです。

第3章：Web2時代のAPI活用と事例

3-1. マッシュアップ文化の広がり

前述のとおり、2000年代後半から2010年代にかけて、Google、Twitter、Facebook、Amazon、楽天など多数の企業がAPIを公開し、“マッシュアップ”と呼ばれる新サービスが次々に生まれました。

Google Maps × 不動産検索
物件情報に対応する地図を自動生成し、周辺環境や最寄り駅を一目でわかるようにした。ユーザーはスムーズに物件探しができるようになった。
Twitter × まとめサイト
TwitterのAPIを用いて特定のハッシュタグがついたツイートを取得・分析し、トレンドをまとめる。これがブログやニュースサイトと連動し、Twitter自体のユーザーベース拡大にも貢献。
ECサイト × 決済API
PayPalやStripeといったオンライン決済APIを組み込むことで、小規模EC事業者がクレジットカード決済を簡単に導入。これにより個人商店やクリエイターがグローバルに商品を販売できるようになった。

こうしたAPI連携によって、従来は考えられなかったビジネスモデルが次々と実現し、“APIエコノミー”という言葉が生まれたのです。

3-2. 企業におけるAPI活用のメリット

企業にとってのAPI活用メリットは、大きく次の2つに分類できます。

自社サービスの拡張・効率化
- 社内システム同士をAPIでつなぐことで、重複開発を防ぎ、機能を再利用しやすくなる。
- 顧客データや在庫情報を一元管理し、複数のフロントサービス（Webサイトやモバイルアプリ）で活用可能に。
外部デベロッパーとの連携による価値創出
- 自社のコアデータや機能をAPIとして公開することで、社外の開発者が新しいアプリやサービスを作ってくれる。
- その結果、利用者が増え、データがさらに充実し、エコシステム全体の価値が高まる。

例えば、地図サービスを持つGoogleは自前でアプリケーションを開発するだけでなく、APIを公開して世界中の開発者に利用してもらうことで地図関連のイノベーションを飛躍的に増やしました。

企業同士のAPI連携が進むほど、それぞれのサービスが補完関係を築き、ユーザーにとっての利便性が高まる、まさに「ウィンウィン」の関係が生まれるわけです。

第4章：web3時代のAPI活用と事例

4-1. web3におけるAPIの重要性

ブロックチェーンは「分散型の台帳」として、誰でもネットワークに参加できる開かれた仕組みです。しかし、実際にブロックチェーンのデータを扱うには特殊な「ノードソフトウェア」を起動し、自分で同期を続ける必要がありました。これは専門知識やリソースが必要で、個人レベルではハードルが高いのが現実です。

そこで登場したのが、InfuraやAlchemyといった「ノードプロバイダ」が提供するAPIです。

彼らは常に最新のブロック情報を保持するノードを運用し、外部の開発者はそのAPIを呼び出すだけでブロックチェーンデータを簡単に取得・送信できるようになりました。これはweb3を普及させるうえで非常に大きな役割を果たしています。

4-2. 具体的なweb3 API活用例

NFTマーケットプレイスの価格取得
- OpenSeaやRaribleなど、NFTを扱うプラットフォームはAPIを公開しており、各NFTの価格や取引履歴、メタデータを取得できる。
- これにより、ウォレットアプリやポートフォリオ管理サービスが“ユーザーが持つNFTの最新価格”を自動表示することが可能に。
DeFiプロトコルの情報取得
- Aave、CompoundなどのレンディングプロトコルはAPI経由で利率や預け入れ残高などを取得できる。
- 価格比較サイトや一括管理ダッシュボードがリアルタイムにユーザーの資産状況を把握し、最適な運用先を提案できるようになる。
ウォレット接続（RPC）
- ブラウザウォレットやスマホウォレットは、RPC（Remote Procedure Call）を介してブロックチェーンにトランザクションを送る。
- 開発者はInfuraやAlchemyなどのRPCエンドポイントを利用することで、自分でノードを立ち上げなくともユーザーが行うトランザクションをブロックチェーンへ送信可能。

4-3. web3 APIの課題と展望

ただし、web3におけるAPI活用には独自の課題も存在します。

分散型の精神との矛盾
- ノードプロバイダに依存しすぎると、本来の「分散型ネットワーク」という理念が損なわれる恐れもある。
トランザクションのセキュリティ
- 単なるデータ取得ではなく、トークン送金などの資産移動を伴うため、APIキーの管理や認証がより重要となる。
複数チェーン対応
- Ethereumだけでなく、PolygonやBSCなど様々なチェーンが乱立しているため、チェーンごとにAPI仕様やRPCエンドポイントが異なる。

今後は、こうした課題を解決しながら、より多くのユーザーや開発者がweb3アプリケーションを利用しやすくするためのAPI設計が重要になっていくでしょう。

第5章：SDKの背景と誕生

5-1. ソフトウェア開発キットの原点

SDK（Software Development Kit）は、文字通り「ソフトウェアを開発するための道具一式」です。

コンピュータゲームの世界では、昔からゲーム機本体を生産する企業（任天堂やソニーなど）が、ゲーム開発者向けに専用SDKを提供してきました。これは、ゲームを作るうえで必要となるライブラリやツール、ドキュメントがセットになっており、開発効率を高める目的があります。

モバイルアプリの世界でも、iOS SDKやAndroid SDKが用意されています。これらはアプリを動かすための基本的なAPI（カメラやGPSへのアクセスなど）やサンプルコード、統合開発環境（IDE）の支援ツールなどが含まれており、初心者から上級者まで幅広い開発者を支援してきました。

5-2. SDKが求められる理由

単に「機能を呼び出すAPI」を用意するだけでは、開発者は認証の仕方やエラー処理の書き方などを自分でイチから実装しなければならず、学習コストが高くなります。そこで企業やプロダクトチームは、開発者が“すぐに使い始められる”ようにSDKを準備するのです。

ライブラリ（Library）
よく使う関数や機能をまとめたもの。開発者が呼び出すだけで、複雑な処理を簡単に行える。
ツールやCLI（Command Line Interface）
テストやデバッグ、ビルドなどを補助する実行ツール。コマンド操作でアプリの構築やデプロイができる。
サンプルコードやドキュメント
開発者が最初に導入する際、具体的なコード例があると学びやすい。

これらをセットにしたものがSDKです。開発者は複雑なロジックを一から理解しなくても、SDKをインストールしてサンプルコードを少し書き換えるだけで最低限の機能が動くため、学習のハードルが下がります。

第6章：SDKの定義と特徴

6-1. SDKの定義

改めて整理すると、SDKとは「特定のプラットフォームやサービスの機能を開発者に提供するための、ツール・ライブラリ・ガイドライン・サポート文書などの一式」です。

APIだけであれば、サービスへの接続はできても、適切なパラメータの設定やエラー時の対応策などは開発者自身が調べる必要があります。一方、SDKはこうした部分まで含めて“道具箱”を提供してくれるイメージです。

6-2. SDKがもたらすメリット

導入が簡単
- 開発環境のセットアップや認証設定などを簡単なステップで行える
バグが減る
- 多くの利用者によってテストされ、安定性が保証されているライブラリを利用できる
機能拡張が容易
- プラグインやアドオンなど拡張機能を備えている場合、開発者が自分のプロジェクトに合わせてカスタマイズできる
ドキュメントとサポート
- 公式ドキュメントやコミュニティフォーラム、サンプルコードなどが充実しており、問題解決しやすい

6-3. 注意点：SDKのバージョンと依存関係

SDKは便利な反面、以下の点に注意が必要です。

バージョンアップに伴う互換性
- 新しいバージョンが出ると、一部の関数やクラスが変更・廃止される可能性がある
- 自分のアプリが使っている古いバージョンとの互換性をどう保つか、計画的に管理する必要あり
依存ライブラリのセキュリティリスク
- SDK内で利用している外部ライブラリが脆弱性を抱えている場合、思わぬセキュリティリスクを招く可能性がある

企業やコミュニティが公式に提供するSDKを利用する際は、サポート期間やアップデート方針を確認しておくと安心です。

第7章：web3時代のSDK活用例

7-1. ウォレット連携SDK

web3領域で代表的なSDKとしては、Ethereum系のものが挙げられます。

たとえば「ethers.js」「web3.js」と呼ばれるJavaScriptライブラリは、Webアプリケーション上でウォレット接続やスマートコントラクト呼び出しを簡単に行えるようにするものです。

ethers.jsの例
- ブラウザウォレットであるMetaMaskなどとの連携がスムーズ
- ABI（Application Binary Interface）というスマートコントラクトの呼び出し仕様を読み込み、関数を呼ぶコードを自動生成してくれる
- トランザクションの作成、送信、署名、結果の取得といった一連の流れがわかりやすくまとめられている

こうしたSDKが存在しない場合、開発者はブロックチェーンノードへの生のRPC呼び出しを自力で行い、データを解析し、ウォレットの署名を組み合わせるといった工程を1から実装しなければなりません。SDKがあることで、非エンジニアにも「ウォレットを使ってトークンを送るって、こういう仕組みなのか」と直感的に把握しやすくなるメリットがあります。

7-2. マルチチェーンSDK

Ethereum以外にもSolanaやPolkadot、BSC、Polygonなど、多くのブロックチェーンが存在します。それぞれが独自のRPC仕様やトランザクション形式を持っているため、本来ならチェーンごとに別のSDKを覚えなければなりません。

しかし、近年は「マルチチェーン対応のSDK」も登場しており、1つのAPIセットで複数のチェーンを跨いで操作できるようにしている事例があります。

例えば「Moralis」は、複数チェーンに対応したデータ取得APIとSDKを提供しており、NFTのメタデータや取引履歴をチェーン横断的に管理するサービスを作りやすくしてくれます。これにより、ユーザーがどのチェーンのNFTを持っていても同じUIで表示できる、マルチチェーンウォレットを実装できるわけです。

7-3. 分析・インデックス向けSDK

ブロックチェーン上のトランザクション情報は膨大かつ構造が複雑です。そこで、特定のデータを検索しやすい形にまとめた「インデックスサービス」が登場しました。

その代表例が「The Graph」です。The Graphは「サブグラフ」と呼ばれる独自形式でデータを整理し、GraphQLを通じてアプリケーションが欲しい情報だけを簡単に取得できるようにしています。

The GraphのSDKやCLIを使えば、開発者は自分が興味を持つコントラクトやイベントだけを追跡・インデックス化し、クエリを高速に実行できる。
ユーザーとしては、複雑なブロックチェーンデータを直接見る必要なく、シンプルなAPIリクエストで必要なデータが手に入る。

こうしたデータインデックス系のSDKは、ウォレットやNFTマーケット、DeFiプロトコルなどと組み合わせて活用され、より高度な分析やダッシュボード表示を可能にしています。

第8章：まとめと後編へのつなぎ

ここまで、APIとSDKの背景・誕生・活用例などを概観してきました。ポイントを整理すると、次のようになります。

APIは、ソフトウェア同士がやり取りをするための「取り決め」
- 初期の分散システム技術（CORBAやSOAP）は導入が難しかったが、よりシンプルなRESTが普及し大衆化
- Web2ではマッシュアップやAPIエコノミーが盛んに
- web3ではノードアクセスやNFT価格取得など、ブロックチェーンと外部をつなぐ橋渡し役
SDKは、APIを中心とした「道具箱」
- 元々はゲーム機やOS開発向けにライブラリやツールをまとめたのが原点
- web3ではウォレット連携やコントラクト呼び出しを簡単にするSDKが多く提供され、開発効率を大幅に向上
web3におけるAPI・SDKの課題と可能性
- 真の分散性を保ちつつ利便性を高めるために、ノード依存や複数チェーン対応などの課題をどう解決するかが鍵
- 分散型アプリ開発者のみならず、Web2企業もブロックチェーン連携の入口としてAPI・SDKを利用しやすい環境が整いつつある