AIクライアントが呼び出すツール（MCPツール等）の引数に、呼び出し側モデルが実際には知り得ない値（実行環境のセッションID・会話IDなど）を必須として要求すると、モデルは処理を止めてユーザーへ聞き返すか、もっともらしい値を捏造して埋める。捏造は単なるノイズでは済まない。その値が重複防止・処理済み管理などの台帳のキーを兼ねている場合、偽エントリが台帳の意味を壊す。

判断基準

• 必須にする引数は「その呼び出し文脈でモデルが確実に取得できるか」で決める。クライアント種別によって知識範囲が違うなら、必須条件も種別ごとに変える（条件付き必須）。JSON Schema で表現しにくい条件付き必須は、handler 側の検証と description への明文化で握る。
• 出所を表す enum が台帳のキーや検索フィルタを兼ねる場合、新しいクライアントを既存値に相乗りさせない。値の分割単位は「ブランドの近さ」ではなく「その値をキーに参照する機構の意味」で決める（ローカルセッションファイルと突合する出所か、単なる会話クライアントか、など）。
• 汎用値（other 等）の追加は出所トレースの意味を薄めるため避け、必要になったクライアントを都度 enum に足す。
• enum はモデルがクライアント種別を自己認識できる粒度までしか分けない。web か desktop かをモデル自身が確実に区別できないなら、1値に集約する。

落とし穴

既存 enum の値に「通ってしまう」近縁クライアント（同ブランドの別クライアント）が最も危険。バリデーションは素通りし、捏造されたIDだけが台帳に蓄積する。まったく別ブランドのクライアントは enum で弾かれて顕在化するが、近縁クライアントは静かに汚染が進む。

検証

新しいクライアント種別からツールを呼び、(1) 必須不足による聞き返しが起きないこと、(2) 省略時に台帳へ記録されず既存の突合処理と干渉しないこと、(3) 既存クライアント経路の必須検証が維持されていること、の3点を確認する。