コンセプト: P-T-Rモデル

Prime Style MCPのアーキテクチャは、「プロンプト」「ツール」「リソース」という3つの要素から構成されています。私たちはこれをP-T-Rモデルと呼んでいます。

この3要素がどのように連携するのかを理解することは、MCPの動作原理を把握し、機能を最大限に活用する上で非常に重要です。

（ここに正式な図を挿入）

上図のように、ユーザーのリクエストはまずプロンプトによって解釈され、ツールやリソースの助けを借りながら処理され、最終的な応答が生成されます。

1. プロンプト (Prompts) - 思考の司令塔

役割: ワークフローの定義と実行

プロンプトはP-T-Rモデルの司令塔です。ユーザーから受け取ったリクエスト（目的）を解釈し、その目的を達成するための思考プロセス（ワークフロー）を定義します。

プロンプトは、LLMに対する指示書そのものであり、どのようなステップで、何を考慮し、どのような形式で出力すべきかを詳細に記述します。

例: リファクタリング戦略プロンプト

1. ユーザーから「コードベースの概要」と「問題点」を受け取る。
2. LLMに対し、「ストラングラーパターンなどのデザインパターンを考慮し、段階的な移行計画を立てる」よう指示する。
3. 出力形式として、「優先順位付けされた改善項目のリスト」を要求する。

プロンプトは、他のツールやリソースを呼び出すこともできます。

2. ツール (Tools) - 具体的な処理の実行役

役割: 補助的なタスクの自動化

ツールは、プロンプトの思考プロセスを補助するための、具体的な処理を実行するコンポーネントです。人間が手作業で行うと手間がかかる、あるいは間違いやすい定型的なタスクを自動化します。

ツールはプロンプトから呼び出されることもあれば、ユーザーが直接利用することもできます。

例:

• code_analyzerツール: ソースコードの複雑度（Cyclomatic Complexity）を計算する。品質レビュープロンプトが、レビュー対象のコードの複雑さを客観的に評価するために内部で呼び出す。
• linter_config_generatorツール: 指定された言語用のLinter設定ファイルを生成する。プロジェクトセットアップのワークフローで利用される。

ツールは、プロンプトが抽象的な「思考」に集中できるように、具体的な「作業」を肩代わりする役割を担います。

3. リソース (Resources) - 参照される知識ベース

役割: 専門知識やデータの提供

リソースは、プロンプトやツールが参照する静的な知識ベースです。ベストプラクティス、デザインパターンカタログ、チェックリスト、チーム内のルールなど、専門的な情報や規約を格納します。

リソースは、プロンプトの応答品質や一貫性を高めるために利用されます。

例:

• design_patternsリソース: GoFのデザインパターンの一覧と解説。アーキテクチャ設計プロンプトが、適切なパターンを提案するために参照する。
• security_checklistリソース: OWASP Top 10に基づくセキュリティチェック項目。品質レビュープロンプトが、セキュリティ観点でのレビューを行う際に参照する。

リソースを分離しておくことで、知識の更新（例: 新しいデザインパターンの追加）をプロンプトのロジックから独立して行うことができます。

P-T-Rモデルの連携フロー

典型的な連携フローは以下のようになります。

1. ユーザーがMCPにリクエストを送信する。（例: 「このPRをレビューして」）
2. プロンプト（品質レビュー）がリクエストを受け取り、ワークフローを開始する。
3. プロンプトは、まずツール（code_analyzer）を呼び出して、コードの技術的な評価を行う。
4. 次に、プロンプトはリソース（security_checklist）を参照し、セキュリティ観点のチェック項目を取得する。
5. プロンプトは、3と4の結果を統合し、最終的なレビューコメント案を生成してユーザーに返却する。

このように、P-T-Rモデルは、思考（プロンプト）、作業（ツール）、知識（リソース） を明確に分離し、それぞれを連携させることで、柔軟かつ強力な専門家システムを構築しているのです。