MCP対応だけでは足りない: AI agent時代のSaaS/API設計
AIエージェントにAPIを使わせる時代には、MCP対応だけでなく、権限、監査、課金、破ってはいけない業務ルール、agent-ready API設計が必要になります。
MCP対応は入口であって、設計の終点ではない
MCPは、AIエージェントが外部ツールやデータへアクセスするための強い標準になりつつあります。Claude Code、Cursor、Gemini CLI、各種IDEやデスクトップクライアントがMCPを入口として使うことで、ツール公開の方法はかなり整理されました。
一方で、AI agent API design や MCP governance の文脈では、接続できることよりも、誤用しにくく、監査でき、課金できるoperationとして公開できることが重要になります。
ただし、SaaSや業務APIをAI agentに使わせるとき、MCP serverを作るだけでは足りません。問題はプロトコルではなく、どの業務operationをagentに任せてよいのか、誰の権限で実行するのか、どこまでが課金対象か、失敗したときに誰が説明できるのかです。
人間向けAPIとagent-ready APIの違い
| 観点 | 人間開発者向けAPI | agent-ready API |
|---|---|---|
| 利用者 | 開発者がドキュメントを読んで呼ぶ | AI agentがschemaと説明を読んで呼ぶ |
| 単位 | CRUD endpointが中心 | 業務operationが中心 |
| 説明 | 人間向けドキュメント | モデルが誤用しにくいtool description |
| 権限 | ユーザー/APIキー単位 | user、agent、workspace、customer、operation単位 |
| 監査 | アクセスログ中心 | 誰が、どのagentで、何を、なぜ実行したか |
| 課金 | 人間またはアプリ単位 | agent実行、顧客、operation、usage単位 |
| 安全性 | 入力バリデーション中心 | 破ってはいけない業務不変条件を明示する |
agent-ready APIでは、単にendpointをMCP toolに変換するだけでは危険です。AIが誤って呼んでも壊れない粒度、取り消し可能性、dry-run、承認、差分確認、監査ログが必要になります。
MCP時代にSaaSの価値はUIからoperationへ移る
従来のSaaSは、どれだけ使いやすい画面を提供できるかが競争軸でした。しかしAI agentが業務の中間オペレーターになると、価値の中心はUIだけではなく、業務データ、権限、監査、不変条件、APIとして呼べるoperationへ移ります。
AI native appの設計では、人間が直接見るUIと、AIが正しく読み、判断し、実行するためのインターフェースを分けて考える必要があります。人間には確認と意味づけを渡し、AIには構造化された状態、操作可能なAPI、エラー、差分、権限境界を渡します。
| 公開するもの | 理由 |
|---|---|
| 業務operation | agentが実行すべき単位はCRUDではなく仕事の単位だから |
| 状態と差分 | agentが現在地と変更内容を理解する必要があるから |
| 権限境界 | できること、できないこと、承認が必要なことを明示するため |
| 監査ログ | あとから誰が何をしたか説明するため |
| usage / billing情報 | agentが顧客ごとにどれだけ使ったか測るため |
| human approval point | AIだけで進めてはいけない境界を作るため |
Contextbergがこの話に関係する理由
ContextbergはSaaS/API課金基盤ではありません。しかし、AI agent時代に必要になる『誰が、どのagentで、何を、なぜ実行したか』という作業履歴の層を扱っています。これはagent-ready APIやMCP governanceの前段にある観測レイヤーです。
個人開発では、Claude CodeやCodexに前回の作業文脈を渡すことが価値になります。チームや企業では、それがagent audit log、multi-agent governance、AI work observabilityに広がります。MCP対応だけでは足りない理由は、まさにこの観測と説明責任が必要になるからです。