AIエージェントの入口はMCPかCLIかAPIか？ 迷う前に押さえたいプロダクトの4層

AX（Agent Experience）入門：AIエージェントに使われるプロダクトの条件　第1回

AIエージェント時代のプロダクト構造（4層）

　では、「プロダクト全体を設計する」とは、具体的に何を指すのでしょうか。本連載では、これを次の4層構造として捉えます。

図2：AIエージェント時代のプロダクト構造

　一見すると、よくあるレイヤード構成に見えるかもしれません。しかしこの4層には、従来の「関心の分離」とは別の軸が通っています。変化の速度です。上の層ほど入れ替わりが速く、下の層ほど長く使われる傾向があります。つまり、層によって寿命が違います。この違いを踏まえているかどうかが、設計の分かれ目になります。

1. 利用する人・システム層（人間／エージェント）

　最上位にいるのは、プロダクトを使う側です。人間ユーザーだけでなく、AIエージェント、外部システム、社内自動化基盤など、複数の使い手が同じ能力を消費します。使い手が人間だけではなくなったことで、設計に求められる水準は一段上がりました。

　そしてこの層は、いまもっとも激しく変化しています。2年前、自律的にAPIを叩くエージェントを前提に設計していた組織はごく少数だったはずです。誰が使うのかという前提は、この数年で書き換わりました。

2. 玄関・接点層（MCP、CLI、SDK、Web）

　ここは使い手が最初に触れる入口（接点）です。MCP、CLI、SDK、Webは、用途ごとに最適化された玄関です。重要なのは、玄関そのものが価値を生むわけではなく、その先にある能力を届ける通り道だということです。どの入口から入っても、受け取れる内容と品質は同じでなければなりません。

　この層の寿命は短いと考えたほうが安全です。MCPは2024年に登場し、2025年末に標準化されました。数年後にどの規格が主流かを、いま確実に言い当てられる人はいないでしょう。接点は差し替えられる前提で設計するのが無難です。

3. 骨格・プロダクト層（API）

　接点の先にある中核がAPIです。ここでいうAPIは単なるHTTPの窓口ではありません。認証・認可、業務ルール、データアクセス、状態遷移、ワークフロー、イベント、監査記録まで含めた「能力の定義面」です。エージェント時代において、実質的なプロダクトの一貫性はこの層で決まります。

　そして上の2層とは対照的に、この層は動きにくくなります。理由は、扱っているものの抽象度です。接点層は、特定のプロトコルの仕様にそのまま対応する実装を持つため、規格が変われば書き換えが必要になります。一方この層が定義するのは「注文を作成する」「与信を確認する」という業務上の能力そのもので、どの規格で呼び出されるかとは切り離されています。だから接点が何に変わっても、定義の側は変わりません。

4. 土台・データ基盤層

　最下層には、能力の源泉となるデータと基盤があります。顧客、契約、注文などの業務データ、検索、権限、監査ログ、バックアップ、ガバナンス。

　骨格が整っていても、土台が曖昧なら再現性は生まれません。AXは接点や骨格の改善だけでは成立せず、土台まで含めてはじめて実現します。

　この層は、さらに変化しにくい部分です。何年も前に定義された顧客データが、現在も同じ意味で参照されている組織は珍しくないでしょう。一度データの定義に曖昧さや不整合が入り込むと、その問題は長期間にわたって残り続ける可能性があります。

　4層を「関心の分離」ではなく「変化速度の分離」として見ると、設計の優先順位が見えてきます。

　接点となる上位層は、将来の変化を前提に、差し替えやすく作ります。一方、APIやデータなどの下位層は、設計上の問題が長く残るため、長期利用を前提に慎重に作る必要があります。つまり、接点には変化への対応力を、骨格と土台には長期的な安定性を持たせることが重要です。

まとめと次回予告

　本稿では、AIエージェント時代の変化を「ソフトウェアのヘッドレス化」として捉え、プロダクトを4層（利用主体／接点／骨格／土台）で整理しました。そのうえで、上の層は入れ替わりが速く、下の層は長く使われるという、変化の速度の違いを示しました。

　接点は揺れやすくとも、能力の定義とデータは揺れてはならない。エージェントへの体験は接点で見せるものですが、それを支える実体は骨格と土台にあります。

　次回は、この体験をAXの条件として分解します。発見可能性、理解可能性、一貫性、安全性、回復可能性、検証可能性。それぞれの条件について、接点・骨格・土台の役割分担を具体化します。