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