クライアントの推論能力を借りて思考を伴うタスクを実装できる samplingや
human in the loopとしての elicitationは面白いな〜と思っているので、よければそこだけでも見てみてください。
1. コンセプト
昨今、アプリケーション開発に変化が生じています。（toBの例で考えます。）
「ドメインエキスパートの熟練知識をシステムに写す」という面は変わっていませんが、「非定型・非決定論的判断」「実行を伴う知恵寄りの知識」のような"熟練知(Expertise)"を含め、実装に写すことができる範囲が大きく拡大しています。
従来的には 機械的（ルールベース）知識 -> プログラミング言語（ドメインモデル）という"写し"がメインだったかと思います。
上記はAI Agentの例ですが、熟練知を MCP Serverとして実装するパターンについても自分なりの考えが蓄積されたので、我流のデザインパターンということでまとめようと思います。
2. パターン
「熟練知」(Expertise)を MCPで提供していく際のオレオレパターンを紹介します。
まず、説明に使用するお題を提示します。
お題（実装対象の熟練知）について
「WRAP プロセス による質の高い意思決定」という、"熟練知"を MCP Server に写していくことを例とします。
WRAP プロセスとは:
-
チップ＆ダン・ハースの『Decisive（邦題：決定力！ 正解を導く4つのプロセス）』にて提唱される、重要な決断の質を上げるための4段階フレームワークと付随するテクニック群のこと
購入した書籍に対する自分の理解を元にしたプロンプトから生成 - より具体をクイックに把握にしたい場合は、こちらをご参照に
- WRAPプロセス全体ではなく、「W」"Widen Optins"全体と「P」の一部のプラクティス（trip wire）を実装範囲とします。
サンプル MCP Server の概要
サンプルコードの全体を公開しています。以降の解説では、具体的な関連箇所のリンクを貼っていきます。 また、npmにも公開しているので、以下で使用可能です。（samplingとelicitationも使っているので、vscodeでないとフルに使用できません）
"decisive": {
"command": "npx",
"args": [
"-y",
"mcp-decisive"
]
}
利用の流れとしては。以下のようになります。（細かくてすみません！）
公開しているエントリポイントは以下です
prompt
- /identify-the-issue
- 課題の背景等のヒアリング -> 課題設定セッションを開始するプロンプトです
- /widen-options
- WRAPプロセスの「W」の一連のプロセスを開始するプロンプトです
tool
- define_issue
- 課題を登録し、Serverに状態を永続化します（ローカルにjsonを置くだけ）
- register_options
- 各ステップでブラッシュアップした、選択肢を登録します。
- 次に行うべきステップの実行プロンプトを返します。
- 選択肢が6つ以上になった場合、elicitationを使いユーザーに落とす選択肢を決めてもらいます
- get_current_status
- 現在の課題・選択肢・WRAPの進行状態 を確認します
- reset
- リセットします
sampling
- make-tripwire
- 各選択肢に対する「撤退基準」を検討します
- クライアント側の推論能力を借りてタスクを実行します（sampling）
では、お題に沿ってパターンを見ていきましょう！
1. Kickoff Prompt パターン — profileを注入しつつ、仕事を開始する
WRAPプロセスを開始するにあたり、汎用的なAgentに対象の「熟練知」に通底するマインドセットやコア知識を注入するための prompt を、Server から提供します。
同時にこれは、特定のワークフローを開始するトリガープロンプトにもなります。
Claude Desktop
呼び出し時に変数も注入可能です。
実装対象となる知識:
- Profile/Role
- マインドセット/コア原則
- 経験的な段取り方
関連するMCP仕様
- prompt
WRAPの熟練知 -> MCP Serverへのmapの実例
WRAPプロセスの開始前に、そもそもの課題設定を行う会話セッションのトリガーとして実装しています。（WRAPプロセスそのものとは、会話トランザクションを切っています）
変数を受け取り、テンプレートに流し込んで、それをクライアントに返しています。
同様に、Widen-Optionを開始するpromptも実装しています。
また、WRAPプロセスの最初のフェーズである「Widen Options」を開始するトリガーも提供しています。
オレオレ度
- 低: ユーザが明示的に開始するワークフローの契機としてpromptを提供するのは、prompt
の通常の使用方法です
2. Role in Description パターン — 特定の操作に人格と期待値を設定する
特定のアクションに対して、実行前にマインドセットや原則・制約を認知させたい時に。
事前条件も記述可能だが、強制力は高くはない。
Cursor
実装対象となる知識:
- Profile/Role
- マインドセット/コア原則
関連するMCP仕様
- tool
WRAPの熟練知 -> MCP Serverへのmapの実例
オプション（選択肢）を考え、追加編集していく際の原則を注入している。
description用のプロンプトを書き、Serverに登録します。
オレオレ度
- 高:
- tool call 前に description は認識しており意味はあると思うが、強制力はそこまで高くはない。
- 注意点として、長すぎると状態的にコンテキストを圧迫することになるだろう。（対処として、使わないときはtool offにしておく）
3. Expert Toolbox — toolは APIラッパーではなく、手順
エキスパートがよくやる思考操作/行動の内面化されたパターン。定石的な手順であり、「道具箱」。
「実行を伴う知識」であり、これが実装されると基本的に保存データの操作や、外部へのエフェクトを伴う（APIコールなど）。
要はタスク/業務操作であり、tool use。
Claude Desktop
実装対象となる知識:
- 行動・思考パターン/道具箱
関連するMCP仕様
- tool
WRAPの熟練知 -> MCP Serverへのmapの実例
質の高い選択肢を幅だしするための、具体的なプラクティスの実行を伴った「選択肢の追加」という操作を tool として提供している。
toolとしては「選択肢の追加」と一般化しているが、実際には、"Widen-Options"のフェーズにおける、ラダリング/類推/バニシング・テスト などの各プラクティスが「実際のアクション」に該当する.
「選択肢の追加」をtoolとして実装しています。
また、実ロジックはドメイン層に書いています。これは従来的な考え方と同様に、mcpという技術的詳細に依存しない純粋関数群を配置しています。
（ほぼvibe-codingなので綺麗ではないですが。）
オレオレ度
- 低: mcp toolは、単なるAPIラッパーに留まらないと考える
4. Workflow State パターン — 状態と順序制約を Server で管理
動的な段取りを、サーバ側で持つ状態と遷移条件で型化する。
プロンプトで段取りを指定することに比べて、確実に手順を守らせることができる。（コンテキストが積み重なって当初指定した手順が忘れられても）。
また、ワークフローの型化は行いつつも、Agentの判断で手戻りしたり、順番を変えたりする余地を残すこともできる。（ガードレールを伴うインターリーブ的な段取り）
要は行動計画でありプランニングの型の指定。
Claude Desktop
実装対象となる知識:
- 経験的な段取り方
- 思考・行動履歴の短期記憶/ワーキングメモリ
関連するMCP仕様
- tool
WRAPの熟練知 -> MCP Serverへのmapの実例
WRAPプロセスそれ自体、今回の範囲では特に、"Widen-Options"フェーズで行うべきことをワークフロー化している。
Agentは、確実に全てのプラクティスを実行し、遷移条件に違反して手順を飛ばすことができなくなっている。
初期選択肢案出 -> ラダリング -> 類推 -> バニシング・テスト -> チェックリストによる最終評価
状態遷移制約を実装しています
状態は、簡易的にローカルにjsonを保存するようにしています。
オレオレ度
- 低: mcp server側で、強制力の高い「レール」を提供できる
補足
関連して、思考・行動履歴（イベント）の積み重ねを保存しておいて、自己参照したりできてもいいかもしれない。（簡易的なMemory）
5. Response Next Action パターン — 次の一手まで返す
tool call のレスポンスとして、データに加え「次にAgentが行うべきアクション」のプロンプトを返す。
予め「手順プロンプト」を与えていても、コンテキストが重なる中で薄れてしまうことに対して、この手法では直後に自分が行うべき手順を Agent が確実に認識できる。
実用的には、前掲の「Workflow State」と組み合わせ、現在のワークフロー状態に応じた「Next
Action」を返すことができる。
vscode
実装対象となる知識:
- 経験的な段取り方
- 行動・思考パターン/道具箱
関連するMCP仕様
- tool
- prompt
- 自律作業の中でAgentが自発的に、提供された /prompt を呼んでその指示通りに次の行動をとることがあることは観測している（claude desktopにて）。しかし、現在の MCP の仕様上は、prompt はユーザが駆動するものという思想であると思われる
WRAPの熟練知 -> MCP Serverへのmapの実例
現在の進行度に応じて次に行うべきプラクティスが書かれたプロンプト + jsonデータを返却している。
オレオレ度
- 中: これは sampling が使えるクライアントが少ない過渡期のハックのような気もする。１つのタスク定義のリターンとして次のタスク定義を書く、というのも、１つのタスク=１つのsampling として提供できれば必要性が半減するかも。
6. Response for Reflection パターン — act直後に自己評価／行動修正を誘発する
tool call のレスポンスとして、データに加え「内省すべき自己評価チェックリスト」のプロンプトを返す。
自己の成果物が指定の品質に満たない場合の再行動や、行動の結果が予想外だった場合の計画修正のためのプロンプトを、ジャストインタイムに返す。
vscode
実装対象となる知識:
- 勘所による判断/行動修正
関連するMCP仕様
- tool
- prompt
WRAPの熟練知 -> MCP Serverへのmapの実例
"Widen-Options"フェーズの最終段階で、「選択肢の質」に対する最終チェックリストを受け取ることになり、自己レビューを促される。
オレオレ度
- 中: タスクとその評価観点を１つの tool に凝集して提供できるのはいいと思う。（自己評価、にはなるが）
7. Reasoning Offload パターン — “脳”はクライアントから借りる
MCP Server はそれ自体にはあくまで、従来的なロジックやAPIコールしか書けない。
"脳"（推論能力）を持たないため、根本的に「自由な思考力を持った主体でないと行えないタスク」を実装できない（MCP ServerからLLMコールすることはできるが、課金体系やAPIキー管理などの煩雑性が伴う）
しかし、“sampling” でクライアントに「脳」を借り、”自由な思考を伴ったアクション”すらも MCP Server 側で提供可能となる！
vscode
実装対象となる知識:
- 行動・思考パターン/道具箱
- "実行を伴う知識"を実装できる！
関連するMCP仕様
- sampling
WRAPの熟練知 -> MCP Serverへのmapの実例
WRAPのプラクティスである、"tripwire"を samplingで提供しています。
（選択肢に対する「撤退基準」を実行前に設定することで、サンクコストで退却できないまま茹でガエルになることを防ぐ手法）
toolとして「撤退基準を考える」というタスクを公開することはできない（裏で別のLLMをcallしない限り）。
ここでsamplingを用いることで、ユーザ側（クライアント側）のLLM資源を借りて推論を行うことができるため、Server提供側は非常に楽に「知恵を伴う実行」を実装・公開することができる。
テンプレートの変数に現在の状態を流し込んだプロンプトをクライアントに返している。
それに対しクライアントが返した生成文章を、サーバ側で受け取り処理を継続、最終的なリターンをクライアントに返す。
オレオレ度
- 低:
- sampling はめっちゃ面白いと思う。しかし、記事公開当初（2025/9月）は、メジャーなクライアントではvscodeしか対応していない（Claude Desktop...？セキュリティ上の懸念などだろうか？）
- 主要どころが対応したらまた一段と MCP のユースケースが広がる、強力な仕様だと感じる
8. Human in the loop パターン — 要所で人が介入する
仕事が遂行される中で、「そこは人の判断や価値観、あるいは責任を介入させたい」というシーンに、Server側から人間の入力を求めることができる。
vscode
もちろん、テキスト入力等もできる。Server側は定型データを要求できる。
実装対象となる知識:
- 段取り
- Human in the loop を実装できる！
関連するMCP仕様
- elicitation
WRAPの熟練知 -> MCP Serverへのmapの実例
選択肢は3〜5個まで、というルールがある。しかしregister-optionsには、6個以上の選択肢の登録を試みることができる。
Agentが6個以上の選択肢の登録を試みた場合、 elicitation が発動し、クライアントで「落とす選択肢」をユーザに指定させる。
これはつまり、「どの選択肢を落とすか」は人間が価値観や状況を元に決定すべきだ、という考えを実装している。
toolのhandlerの中に、elicitationを求める処理を書くことができる。
オレオレ度
- 低:
- elicitation を Human in the loop のために使うのは通常の使用方法
- elicitation もめっちゃ面白いと思うし、主要クライアントが対応したら一段と MCP のユースケースが広がる、その２だと思う。（Claude Desktopくん！）
9. Mechanical Rules パターン — 機械的判断／事実情報は従来と同様に実装
「選択肢は3〜5個まで」のようなルールベースロジックは、従来通りServerの中でプログラミング言語により決定的ロジックとして実装する。
システムの従来的な部分。
実装対象となる知識:
- 機械的な判断/ルール
- 事実的な情報
関連するMCP仕様
- tool
- resource
- 静的な情報・事実（画像等のメディア含む）は resource で取得可能だろう
WRAPの熟練知 -> MCP Serverへのmapの実例
- ルールベースロジックのプログラミング言語による実装
- 不変条件や値域、情報構造の型による表現
オレオレ度
- 正直パターンでもなんでもないです
以上です！読んでいただきありがとうございました。
ちなみに...
CLAUDE.mdを各所に仕込んだ vibe-ready な mcp serverのテンプレも公開してますのでよければ使ってみてください（local mcp serverを想定）
Discussion