不変条件・絞り込み・安全条件を「守られているはず」で済ませない。最適化するのは「呼び出し側が間違えても破れない強制」、避けるのは「型宣言・フロントの暗黙ルール・プロンプトや呼び出し規律の遵守を信頼境界に置くこと」。守りたい条件は、最も内側で確実に効く機構（サーバ側の検証・正規化、クエリ条件、出力の区切り、明示的な値の組み立て）に落とす。

判断基準

• 型や契約は宣言であって強制ではない。構造的部分型では宣言にないフィールドが素通りして実送信される、ゆるい入力境界が厳格な内部型へ不正値を流して汎用エラーに潰れる、といった乖離が起きる。送る内容は型に宣言し、必要な値だけを明示的に組み立て、境界で内部型に合わせて正規化・厳格化する。
• フロントの暗黙ルール（空なら全体、等）に状態の意味を委ねない。中間状態は API 直叩きや別クライアント、既存不正値から生じるので、サーバ側で正規化して不正値・中間状態にも耐えさせる。
• クライアント側の検証だけに頼らず、同じ条件をサーバ側にも置く多層防御にする。入力品質ゲートはクライアント差に左右されないようサーバ側へ寄せ、hard error・warning・正規化提案に段階を分ける。
• AI や LLM に渡すツール結果へ外部由来データを区切りなく連結しない。「データであって指示ではない」区切りで囲み、認可スコープでの多層防御も併用する。プロンプト遵守を安全境界にしない。

例外・限界

内側強制はコストを伴う（クエリ条件の追加、正規化処理）。真に公開で誰でも読める対象など、強制が不要な範囲は分けて考える。ただし「公開だから何でも自由」と混同しない。

検証

呼び出し側の遵守を外した状態（フィルタを渡さない、不正値・中間状態を直接送る、宣言にないフィールドを混ぜる、注入文言を含む外部データを通す）で、内側の機構が条件を維持し拒否・正規化するかを確認する。

根拠（synthesize 元）

• 392 MCP サーバーの品質改善は入力品質ゲートを先に固める
• 492 MCP/ツールのレスポンスに外部由来データを埋め込む時はプロンプトインジェクションを区切る
• 532 TS の余剰プロパティ検査は変数渡しでは効かず未宣言フィールドが暗黙送信される
• 547 ゆるい入力境界と厳格な内部型の不一致は unmarshal 失敗を汎用エラーに隠す