LLMから呼ばれるアプリをMCPファーストで設計する3原則 This article proposes three principles for designing applications that are invoked by LLMs…
- LLMがMCP経由で呼び出すアプリを設計する際の3原則を提示する記事。
- ツールの粒度、エラー設計、状態管理という観点から、人間向けUIではなくLLMを一級ユーザーとして扱う設計思想の重要性を解説している。
English summary
- This article proposes three principles for designing applications that are invoked by LLMs through MCP, focusing on tool granularity, error design, and state management to treat LLMs as first-class users rather than building human-facing UIs.
AIエージェントの普及に伴い、アプリケーションが人間ではなくLLMから呼び出される前提で設計される機会が増えている。本記事は、Model Context Protocol (MCP) を前提に据えた「MCPファースト」設計の指針として、3つの原則を提示している。
第一の論点はツールの粒度である。LLMが理解しやすいよう、ツールは単一責任に近い形で切り出し、引数や戻り値のスキーマを明確に定義することが望ましいとされる。粒度が細かすぎるとLLMが組み合わせに苦労し、粗すぎると意図しない副作用を生むため、ユースケースを起点としたバランスが鍵となる。
第二はエラー設計である。LLMは曖昧なエラーメッセージから自律的に回復しようとするため、構造化された原因情報や次に取るべきアクションのヒントを返す設計が有効と見られる。HTTPステータスのみではなく、自然言語の説明を併記することでリトライやプロンプト修正の精度が上がる可能性がある。
ツールの粒度、エラー設計、状態管理という観点から、人間向けUIではなくLLMを一級ユーザーとして扱う設計思想の重要性を解説している。
第三は状態管理である。MCPサーバーはステートレスに近い前提で扱われがちだが、規制業務SaaSのような領域ではセッションや承認フローを保持する必要がある。著者は冪等性キーや明示的なトランザクションIDの導入を示唆している。
MCPはAnthropicが2024年末に公開したプロトコルで、OpenAIやGoogleの一部実装でも採用が進んでいる。LangChainのToolやOpenAI Function Callingと比較して、サーバー側で機能を提供しクライアント横断で再利用できる点が特徴である。今後はLLM向けのAPI設計論として、REST/GraphQLに続く第三の潮流となる可能性がある。
As AI agents become more widespread, applications are increasingly designed to be invoked by LLMs rather than humans. This article proposes three guiding principles for what the author calls MCP-first design, where the Model Context Protocol is treated as the primary interface rather than a graphical UI.
The first principle concerns tool granularity. Tools exposed via MCP should follow something close to a single-responsibility shape, with clearly defined argument and return schemas. If granularity is too fine, the LLM struggles to compose calls correctly; if too coarse, side effects become unpredictable. The author argues that designers should start from concrete user journeys and decompose them into tools that an LLM can reason about without ambiguity.
The second principle is error design. Unlike traditional clients, LLMs attempt to recover from errors autonomously by re-prompting or retrying, so structured error payloads that include the cause and a suggested next action are far more useful than bare HTTP status codes. Including a natural-language explanation alongside machine-readable fields likely improves recovery rates, although the optimal format is still being explored across the ecosystem.
The third principle is state management. MCP servers are often treated as roughly stateless, but in domains such as regulatory SaaS, where approval flows and audit trails matter, some session or transactional state is unavoidable. The author suggests using idempotency keys and explicit transaction IDs so that an LLM agent can safely retry without producing duplicate side effects.
For context, MCP was introduced by Anthropic in late 2024 and has since seen adoption in parts of the OpenAI and Google tooling ecosystems. Compared with LangChain Tools or OpenAI function calling, MCP's distinguishing feature is that capabilities are provided server-side and can be reused across multiple clients, much like a USB standard for AI tools. If this trend continues, MCP-oriented API design may emerge as a third paradigm alongside REST and GraphQL, specifically tuned for LLM consumers. It remains to be seen how conventions for authentication, observability, and versioning will mature, but treating the LLM as a first-class user appears to be a durable design stance.
本ページの本文・要約は AI による自動生成です。正確性は元記事 (zenn.dev) をご確認ください。
