MCPとは？生成AIの文脈と状態を設計する仕組み｜MCP入門 2.1

2.1 MCPの定義と役割

生成AIが登場して以来、私たちは“プロンプト”を工夫することでモデルをうまく制御しようとしてきました。 たとえば、「です・ます調で答えてください」「要点を3つにまとめてください」「あなたは◯◯の専門家です」などの指示は、プロンプトエンジニアリングの一部です。

しかし、実際のアプリケーションや業務でAIを活用しようとすると、こうした都度的な工夫だけでは限界が見えてきます。 状況は刻一刻と変わり、ユーザーは複数存在し、前後関係や履歴をまたいで処理しなければならない。 このとき必要なのは、プロンプトの「一貫性」と「再現性」、そして「状態管理」です。

そこで登場するのが、Model Context Protocol（MCP）という考え方です。 MCPは、単なるプロンプトのテンプレートではなく、モデルと人間・システムがやり取りする際の「文脈と状態の設計図」だと考えるとよいでしょう。

MCPとは何か？

ここで定義する Model Context Protocol（MCP） とは、 以下のようにまとめられます：

モデルが一貫した出力を生成するために必要な文脈・状態・指示・履歴を、構造化された方法で定義・管理・再現するための設計フレームワーク

言い換えれば、MCPとは「AIと対話する前に整えておくべき“空気”や“前提”を、再利用可能なプロトコルとして設計する」ことです。

なぜ“プロトコル”と呼ぶのか？

通信の世界で「プロトコル」とは、異なるシステムが円滑に情報をやり取りするための“共通の約束事”を指します。 同じように、人間とAI（モデル）という異質な存在が、正しく理解し合うためには「文脈の渡し方」にもルールが必要です。

そのルールを明示的に定義し、誰が読んでも・どんなモデルでも同じように文脈を理解できるようにする—— これが「プロトコル化」の目的です。

MCPがプロトコルであるからこそ、次のような恩恵が得られます：

• 文脈を定型化することで、再現性のあるテストができる
• 複数モデル（GPT, Claude, Geminiなど）への移植が容易になる
• ユーザー・タスクごとの文脈をプログラムで切り替えられる
• 人間のエンジニアがモデルの振る舞いを予測・制御しやすくなる

MCPの構成要素（基本ブロック）

MCPは一枚岩の仕様ではなく、複数の要素で構成されます。代表的な要素は以下の通りです：

• System Instruction： モデルの立場・口調・目的を定義する
• Session Memory： セッション内の履歴・状態（圧縮含む）
• External Context： ベクターストアやユーザープロファイル等の外部情報
• User Prompt： 今回の入力に対応する直接的な命令や質問
• Control Markers： 出力フォーマット、制約条件、終了条件など

これらをどう構成し、どの順番でプロンプトに統合するか。 これがMCP設計の技術的核心です。

どこまでが設計者の責任か？

ここで重要な問いがあります。 「AIが賢く振る舞うために、どこまで人間が設計しなければならないのか？」

答えはこうです： モデルは万能ではなく、“渡された文脈”の中だけで推論する。 よって、「どんな文脈を渡すか」はすべて設計者の責任です。

モデルに任せる部分と、設計者が制御すべき部分を明確に分ける。 これこそがMCPの思想であり、設計の根幹です。

MCPの定義と意義が明らかになったところで、次はそれが従来の「プロンプトエンジニアリング」とどう異なるのかを探っていきます。 なぜ“命令を書く”だけでは不十分なのか？ 状態を設計するとはどういうことか？ 次のセクションではその違いを具体的に比較していきます。 → 2.2 従来のプロンプト設計との違いへ進む