Claudeのツール引数を検証する：型・対象・権限の三つの境界

利用者の識別情報を生成させない

誰の権限で操作するかは、ログイン情報やサーバー側のセッションから決めます。モデルにuser_idを自由に選ばせて、その値だけで認可する設計は避けます。対象IDを引数として受け取る場合も、その利用者の範囲に属するかを実行前に調べます。

スキーマによる型検証は有用ですが、認可の代替ではありません。日付の前後関係や注文状態による制約など、業務データを参照しなければ判断できない条件もあります。

危険な操作を一つの万能ツールへ集めない

任意のURLやSQLを受け取る万能な窓口より、必要な操作と対象を限定する方が検証しやすくなります。読み取りと更新、試算と確定を分けると、どの段階で確認が必要かも明確になります。

ツール名を細かく増やせば良いわけでもありません。同じ目的の操作が大量にあると選択を難しくするため、業務上の責任の境界に合わせて設計します。

実行直前に状態を照合する

モデルが読み取った時点から、注文の状態が変わることがあります。確認済みの取消候補でも、発送済みに変わっていれば実行条件は異なります。対象の版や状態を確認し、古い前提で書き込まないようにします。

認可と状態の確認を実行直前にも行う

読み取り時に更新可能だった対象が、操作の直前に別の状態へ変わることがあります。引数の検証を一度通しただけで、古い状態のまま書き込まないようにします。対象の所有範囲、状態、版を更新条件へ含めるなど、保存先の機能に合わせて競合を検出します。これはモデルの注意力に期待する問題ではなく、業務処理の境界として扱います。

拒否した理由を利用者へ返すときも、詳細な対象情報を公開してよいかを確認します。他人の対象が存在すること自体を明かしたくない用途では、内部の診断情報と外部の案内を分けます。安全な失敗とは単に更新しないことだけでなく、拒否の説明から不要な情報が漏れないことも含みます。正常な利用者の復旧経路も併せて設計します。

具体例で考える

架空の注文取消候補が正しいJSONで返りましたが、別の利用者の注文を指しています。

入力検証：order_idの形式は正しい。
対象検証：注文は存在する。
認可検証：現在の利用者の注文ではない。
結論：取消を実行しない。

最初の二段階を通っても安全とは言えません。エラーの返し方でも、他人の注文の詳細を漏らさないようにします。認可失敗をモデルへ詳細説明することより、処理を確実に拒否することが優先されます。

確認課題と合格の目安

一つの更新操作に、型は正しいが拒否すべき入力と、状態変化で拒否すべきケースを作ってください。

• 利用者を生成引数だけで識別しない。
• 対象の所有範囲を検証できる。
• 読取時点と実行時点の状態差を扱える。