まず、ユーザーがプラグインに期待することを洗い出します。プラグインの名前、説明、スキル、ツール、既存のプロダクトとの連携は、いずれもユーザーの期待につながります。実装はそれらの期待に応えるものにするか、対応しない場合は明確な理由を持たせる必要があります。
この作業を通じて、プラグインに何を含めるかを決めます。
- 指示、例、同梱リソースによってモデルがワークフローを進められる場合は、 スキル を追加します。
- ワークフローに最新のデータ、認証、実行を制御できるツール、または自分で運用するインフラストラクチャで動くコードが必要な場合は、 MCP サーバー を追加します。
- 視覚的な操作によってワークフローの一部が大きく改善される場合に限り、 MCP サーバーに UI を追加します。
ユーザーの期待を起点にした検討
プラグインをインストールしたものの、ドキュメントは読んでいないユーザーを想像してください。そのユーザーは、どのようなことをプラグインに依頼できると考えるでしょうか。
次の情報をもとに、想定されるリクエストを集めます。
- ユーザーがすでにプロダクトやサービスで行っているタスク
- ユーザーインタビュー、サポートへの問い合わせ、検索クエリ、機能リクエスト
- プロダクト、データ、ワークフローについてユーザーがよく使う言葉
- ツール間でデータをコピーする必要がある既存の代替手順
- プラグインの名前、掲載情報、スクリーンショット、開始用プロンプト
プラグイン名を指定する直接的なリクエストと、目的を伝える間接的なリクエストの両方を含めます。たとえば、プロジェクト管理プラグインでは、「自分の Acme のローンチ用ボードを見せて」と「ローンチを妨げているものは何ですか？」の両方に対応する必要があるかもしれません。
現在の API で実現できるワークフローだけにアイデアを絞らないでください。まず、ユーザーが期待することを把握します。そのうえで、安全かつ確実に対応できることと照らし合わせます。
ユースケース一覧の作成
ユースケースごとに、次の項目を記録します。
| 項目 | 検討する問い |
|---|---|
| ユーザーの目的 | ユーザーは何を達成しようとしていますか？ |
| リクエストの例 | 直接的、または間接的に、どのような表現で依頼するでしょうか？ |
| 期待される結果 | どのような結果が得られれば、やり取りが成功したと言えますか？ |
| 必要なコンテキスト | どのような情報、アカウントへのアクセス、事前の状態が必要ですか？ |
| プラグインの機能 | スキルで対応できますか、それとも MCP ツールが必要ですか？ |
| 安全上の制約 | データの公開、状態の変更、金銭の支出、他者への影響が生じる可能性はありますか？ |
| 対応方針 | 初期バージョンで対応しますか、先送りにしますか、それとも意図的に対象外としますか？ |
同じ目的を持つリクエストをまとめます。「自分の未完了タスクを一覧にして」「今日は何をする必要がありますか？」「期限切れの作業を見せて」は、互いに無関係な 3 つの機能ではなく、フィルターが異なる 1 つのタスク確認ユースケースとして扱えるかもしれません。
対応範囲の確認
ユーザーの期待を一つずつ、提案したプラグインの機能と照らし合わせて確認します。
- 対応するすべてのユースケースで、リクエストから有用な結果を得るまでの流れが完結していることを確認します。
- 不足しているスキル、ツール、データ、権限や、考慮していないエラー状態を洗い出します。
- 技術的な操作を提供するだけで、ユーザーにとって明確な目的を達成できないツールがないかを確認します。
- 書き込み操作に適切な認可と確認が含まれていることを検証します。
- プラグインが、できないことを説明し、有用な次のステップを提案できることを確認します。
期待されるワークフローのごく一部にしか対応していないのに、幅広い機能を備えているかのように示すべきではありません。プロジェクトを作成できても、一覧表示、詳細確認、更新ができない場合は、不足している機能を追加するか、プラグインがうたう対応範囲を狭めます。
意図的に対象外とする事項の文書化
考えられるすべてのリクエストに対応する必要はありません。ただし、重要なものを対象外とする場合には、それぞれに次のような妥当な理由が必要です。
- その操作によって、安全性やプライバシーに関する許容できないリスクが生じます。
- 基盤となるプロダクトや API が、その操作に安定して対応できません。
- ワークフローに必要な権限を、プラグインでは検証できません。
- プラグインがアクセスできない情報がなければ、結果が誤解を招くものになります。
- そのユースケースは初回リリースの対象外であり、プラグインの掲載情報にもその旨を明示しています。
これらの判断を記録します。その内容は、スキルの対応範囲、ツールの説明、リクエストを拒否する際の振る舞い、テストケース、公開する掲載文に反映する必要があります。
ユースケースに基づく実装方針の決定
対応するユースケースごとに、目的を達成できる最小限の実装を選びます。
- 繰り返し使う指示やリソースを提供するには、 スキルを構築します。
- 最新のデータや実行を制御できる操作を提供するには、 MCP サーバーを構築します。
- ユーザーが構造化された情報を詳しく調べる、比較する、編集する、確認する、または情報間を移動する必要がある場合は、 MCP サーバーに UI を追加します。
ユースケース一覧をテスト計画として活用します。直接的なリクエスト、間接的なリクエスト、エッジケース、対象範囲外のリクエストについて代表例を追加し、完成したプラグインがそれぞれに対して意図どおりに動作することを検証します。
プラグインに最新のデータや実行を制御できる操作が必要な場合は、 ツールの定義に進んでください。