ClaudeとMCPを接続する：できることと許可することを分ける

業務上の責任でツールを分ける

顧客情報の参照、変更案の作成、変更の確定は異なる責任です。一つの操作で全てを行うより、必要な段階で確認できる境界を設ける方が、失敗の所在を追いやすくなります。

ツールの説明には用途、必要な入力、結果の意味、行えないことを含めます。名前が似ている操作が多い場合は、どの条件でどれを選ぶかが人にも説明できるか確認します。

認証情報と生成された引数を分離する

利用者の権限は、接続に使う認証やサーバー側の状態から判断します。ツールへ渡された組織IDを、そのまま権限の証明にしないようにします。対象の所属や利用範囲を実行時に照合することが必要です。

読み取りだけでも情報漏えいの影響があります。書き込みがないから無条件に広いデータへ接続してよいとは判断しません。必要な対象と項目に絞ります。

結果を次の判断へ使える形にする

大量の内部ログではなく、取得できた範囲、残る制約、次に必要な情報を返す設計を考えます。失敗時に空結果と区別できることも重要です。モデルが正しいツールを選べるかだけでなく、結果を誤って解釈しないかを評価します。

接続後の評価をツール単位で行う

ツールが一覧に現れ、正常な一回の呼び出しができても、用途に合うとは限りません。必要な操作を選べるか、似た操作を取り違えないか、引数が不足したときに確認できるかを試します。ツールの説明を直す前に、人にも選び分けが難しい一覧になっていないかを確認します。命名の工夫だけで曖昧な業務の境界を解決しようとしないことが重要です。

更新系ツールでは、モデルの意図と実際の対象を実行前に照合します。読み取りの結果が古い、同じ要求が再送された、対象の権限が変わったという例も評価へ含めます。接続する認証情報が強い場合は特に、アプリが許す対象と操作を限定し、不要な能力を一覧から外す方法を検討します。接続の簡単さと、運用の責任は別の判断です。

具体例で考える

架空の顧客管理ツールで、検索と住所更新を利用します。

検索：現在の利用者が読める顧客のみ返す。
更新候補：対象IDと変更箇所を提示。
確定：認可と必要な承認を確認後に実行。
結果：変更した項目と操作IDを返す。

ツール一覧を短くするために万能な更新窓口へ統合すると、承認や検証の境界が見えにくくなります。操作の数ではなく、責任を分けられるかで設計します。

確認課題と合格の目安

追加したいツールについて、用途、入力、認可、結果、失敗時の動作を記述してください。

• 接続と権限を区別している。
• 読み取りの対象範囲も限定している。
• 結果の意味を利用者が検証できる。