+ALPS and MCP diagram

はじめに

REST（REpresentational State Transfer）は、分散システムにおけるアーキテクチャスタイルとして2000年にRoy Fieldingによって定義され、その後Web API設計の標準的手法として広く採用されてきました。RESTの本質は、リソース指向アーキテクチャ、自己記述的なメッセージ、ハイパーメディアによる状態遷移の表現、統一されたインターフェースにあります。

Application-Level Profile Semantics（ALPS）は、REST APIのセマンティクス（意味）を定義するためのプロファイル記述形式です。ALPSはリソースやその操作の意味を明確に定義することで、APIの理解と利用を促進します。APIが「何を」表し、「どのように」操作できるのかという文脈情報を提供するのです。

一方、近年では大規模言語モデル（LLM）のような自然言語インターフェースを持つエージェントがアプリケーションと対話するユースケースが増えています。こうした背景の中で、RESTの原則とALPSによる意味定義は、APIを文脈付きで理解し操作するための構造として有効に機能します。

本稿では、ALPSとModel Context Protocol（MCP）を組み合わせることで、LLMとRESTリソースとの間にどのような対話モデルが構築できるかを検討します。

クライアントの進化とMCP

従来のWebアプリケーション設計では、「人間」（Webブラウザ、モバイルアプリ）および「機械」（APIクライアント）を主なクライアントとして想定していました。しかし、LLMの登場により、「AI」も新たなクライアントとして設計に含める必要が生じています。AIクライアントは自然言語を通じてアプリケーションと対話し、機能を呼び出すため、構造化されたインターフェースと明確なコンテキストの提供が求められます。

この要請に応える手段として、Model Context Protocol（MCP）が導入されました。MCPはアプリケーションの機能をLLMが理解・操作可能な形式で提供するためのプロトコルであり、RESTの設計原則と高い親和性を持ちます。

クライアントの進化:
├── 人間 (Web UI, モバイルアプリ)
├── 機械 (APIクライアント)
└── AI (LLM + MCP)

ALPSによる意味定義とMCPを組み合わせることで、単一のリソース設計で3種類のクライアントに対応できます。これにより、以下のような利点が得られます：

  • アダプターの重複実装の回避：Web用、API用、AI用といったクライアントごとの個別の処理分岐やデータ整形を行う必要がなくなります。
  • インターフェースの一貫性：HTTPメソッドとURIによる統一されたアクセスにより、仕様書やテストケースを共通化しやすくなります。
  • テストと運用の共通化：同じリソース設計に対して共通のユニットテストやモニタリング設定を適用でき、運用コストを低減します。

リソース設計とアフォーダンス

RESTに基づくリソースは、HTTPメソッドに基づいた統一インターフェースで設計されており、すべてのクライアントに対して同様のロジックを提供可能です。特にハイパーメディアの制約は、リソースが自身のアフォーダンス（可能な操作）を提示する重要な機能です。

{
  "id": "order-123",
  "status": "shipped",
  "total": 5000,
  "items": [ ... ],
  "_links": {
    "self": { "href": "/orders/123" },
    "doPayment": { "href": "/payments?order_id=123" },
    "doCancel": { "href": "/cancellations?order_id=123" },
    "doTracking": { "href": "/tracking?order_id=123" }
  }
}

このようにリンク関係（_links）を含めることで、リソースが提供する状態遷移（アフォーダンス）を明示できます。LLMにとっては「次に可能なアクション」を知るための指標となり、ユーザーとの対話において自然な提案を行うことが可能になります。

たとえば、上記リソースをMCPを通じてLLMに提供することで、LLMは次のような発話を生成できるようになります：

  • ステータスが “shipped” の場合：「配送状況を確認しますか？」
  • “pending” の場合：「お支払いを完了しますか？」
  • “processing” の場合：「注文をキャンセルしますか？」

これはAIをエージェントとして活用する時の強みになります。従来の”JSON API”は単にデータを受け取るだけで完結してしまいますが、ハイパーメディアAPIのMCP活用は『意味を受け取り、次の動作を促す』対話となります。

REST制約の有無が生む対話の差異：OpenAPI比較分析

設計哲学の根本的違い

OpenAPI仕様が「契約書」としての正確性を追求するのに対し、ALPS+MCPアプローチは「会話」を志向します。これは単なる技術的差異ではなく、AIをどう捉えるかという世界観の違いともいえます。

OpenAPIベースのシステムでは、AIはあらかじめ記憶した仕様の範囲内で応答します。一方、MCPが組み込まれたリソースは、各瞬間に可能な操作をリンクとして提示し続けることで、AIに「今この文脈でできること」を伝える生きた文法となります。

統一インターフェースがAIの学習負荷を軽減し、ハイパーメディアが会話の流れを自然に誘導し、自己記述性が各状態での文脈を保証します。

OpenAPIが都市の地図だとすると、RESTベースのMCPは街角毎に立つ親切な看板です。MCPは看板を読む旅行者（LLM）のためのガイドブックともいえるでしょう。利用者を導き、迷子が生まれにくい構造を実現します。

AIエージェントとしての可能性

リソースのアフォーダンスとALPSによるセマンティクスを組み合わせることで、LLMは単なる情報検索や操作実行を超えた、エージェントとしての機能を獲得します。

エージェントとしてのLLMは、ユーザーの意図を理解し、現在の状況に適したアクションを選択・実行できます。たとえば注文情報を確認した後、そのステータスに応じた次のステップ（支払い、キャンセル、配送追跡など）を自然に提案できます。これは単なるAPI呼び出しではなく、目的志向の対話の実現です。

データが会話を止めるのに対し、意味は会話を継続させます。これはまさにREST設計の本質、アフォーダンスの提供とそれを選択することによってアプリケーション状態とリソース状態の変化というRESTの制約が、AIとの対話という新たな分野で活かされた例といえるでしょう。

A2A（Application‑to‑Application AI）との親和性

2025年4月に Google から発表された A2A（Application‑to‑Application AI）は、アプリケーション同士が AI を介して直接やり取りするための新しいプロトコルです。ALPS＋MCP が「意味を橋渡しする」アプローチを提供するのに対し、A2A はその上で「アプリ間のリアルタイム対話」を可能にします。

今後は、MCP によるハイパーメディア的ガイドラインと A2A の双方向連携を組み合わせることで、より自律的・シームレスな AI エージェントの協調動作が実現できるでしょう。

データから意味へ：ALPSによるセマンティクス定義

ALPSは、2013年にMike Amundsenらによって提唱された、APIのセマンティクス（意味）を定義するための標準化されたプロファイル記述形式です。それ自体はデータ交換フォーマットではなく、APIの意味構造を記述するメタ情報であり、REST APIの「意味的インターフェース」という長年の課題に応えるものとして登場しました。

ALPSとMCPの関係性を明確にすると、「ALPSはAPIの意味を記述する『辞書』であり、MCPはその辞書を使ってLLMと対話するための『会話ルール』」といえるでしょう。

ALPSが提供する主な価値は以下の通りです：

  1. セマンティック層の確立 - APIの技術的実装と意味的構造を分離し、ドメイン固有の語彙と操作を明確に定義
  2. 操作の性質の明示 - safe（読み取り専用）、idempotent（何度実行しても同じ結果）、unsafe（状態変更）といった操作の本質的性質を伝達
  3. 意味的一貫性の確保 - 複数のAPIやバージョン間で共通の語彙を使用し、一貫性のある理解を促進
  4. マシンリーダブルなドキュメント - 人間だけでなく機械（LLM含む）も理解できる形式でAPIの意味を記述

ALPSにより、RESTのAPIは単なるデータ交換のインターフェースを超え、意味とコンテキストを持つ対話へと進化します。LLMにとって、この意味層は自然言語からAPIの機能を理解・操作するための橋渡しとなります。

詳細な仕様や実装例については、ALPS-ASDサイトやRFC6906 Profile仕様を参照してください。

RESTの抽象とLLMとの親和性

RESTの特徴である抽象的制約（リソース指向、ハイパーメディア、自己記述的メッセージ、統一インターフェース）は、LLMのようなステートレスで文脈依存なクライアントにとっても極めて有効です。これらの原則は、LLMにとってAPIを「学びやすく」「操作しやすい」構造に変換します。

  • リソース指向：LLMが操作対象をエンティティとして理解可能
  • ハイパーメディア：可能な操作がリンクとして提示され、対話が誘導される
  • 自己記述的メッセージ：やり取りに必要な情報をメッセージ内に包含
  • 統一インターフェース：学習したパターンをあらゆるリソースに適用可能

このように、RESTの抽象は想定していなかった利用者（LLM）に対しても自然に対応できる設計として評価できるでしょう。

未来への示唆：制約の力とAPIの未来

ALPSとMCPの組み合わせは、RESTの持つ抽象的な設計力と、AIによる対話的API操作を統合する新たな枠組みです。特別な拡張をせずとも、RESTの原則とALPSによる意味定義は、LLMによる文脈理解と意図推論に必要な要素をすでに備えています。

自己記述性やハイパーメディアによるナビゲーションは、本来スケーラブルで疎結合な分散システムのために設計されたものでしたが、AIによる操作可能性という観点からも注目すべき特性と言えるのではないでしょうか。

ALPSとMCPの組み合わせが示すのは、技術標準の本当の価値は特定の問題解決ではなく、未知の問題に対処できる「思考の枠組み」を提供するということです。2000年のREST、2013年のALPS、そして現代2025年のMCPは、時代を超えて継承される設計思想の連鎖です。

『優れた制約はまだ出会っていない問題を既に解決している』—RESTとALPSの歴史は、この言葉を体現するものです。2000年に設計されたRESTの原則と、そのセマンティクスを定義するALPSは、当時存在すらしなかったLLMとの対話という課題に対して、驚くほど自然に対応できる普遍的な価値を持っています。

ストーリー

この記事の技術コンセプトを理解するたためのコンセプトストーリー 2030: 意味の時代を用意してます。お読みください。