Effective Instruction 条件・契約 Envelope

CANDIDATE_ID: ORPHAN-RESCUE-EA520-20261019-C1

Enterprise AIで「system instructionを設定した」という事実は、その指示が実行時にどのような優先順位で合成され、どの経路から干渉され、どの程度の確率で守られたかを証明しない。運用上必要なのは、宣言したinstruction bytesだけでなく、provider/model/API/runtime、role/priority、tool・RAG・memory等の注入経路、公開されている安全設定、評価条件を一つの有効命令契約として版管理し、変更時に回帰評価することである。

system/developer/user/retrieved instructionは、モデルに与えられる入力契約の一部である。しかし、その存在だけから「必ず従う」「下位instructionから上書きされない」「秘密として保持される」を導いてはならない。Google Gemini Enterprise Agent Platformのsystem-instruction guidanceはsystem instructionsがrequest全体へ適用される一方、jailbreakやleakを完全には防げない旨を明示している。したがって、instruction presenceはsecurity enforcementの証明ではない。

運用上は、少なくとも次を分離して記録する。 - declared instruction artifact: 組織が管理できるsystem/developer等の本文、hash、revision。 - composition contract: role/priority、連結順、retrieval/tool/memory等がどこへ挿入されるか。 - provider/runtime state: model/API/runtime、安全設定など外部に観測可能な実行条件。 - observed enforcement: conflict、prompt injection、tool/RAG/memory注入を含む評価結果。

providerが内部で追加するhidden policy/system textの完全なbytesは、providerが明示的に公開・readbackしない限りUNKNOWNである。モデル挙動から内容を逆算して正本化してはならない。また、hidden system promptは機密境界そのものでもない。JustAsk（arXiv:2601.21233）は商用モデルを含むblack-box system-prompt extractionを研究対象としており、少なくとも「system roleに置けば秘密になる」という一般化を否定する反証となる。

従って、監査記録では「組織が設定したinstruction」「providerが文書化したpriority/policy」「観測された挙動」「非公開でUNKNOWNな内部instruction」を別欄にする。

同じprompt本文でも、model revision、API/runtime、tool schema、retrieval構成、安全設定、memory injection、provider policyの変更により実効挙動は変化し得る。PCFI（arXiv:2603.18433）やPhishNChips（arXiv:2603.25056）は、role/priority-aware enforcementやprompt-model configurationがsecurity evaluationへ影響することを示す研究 evidence である。これらは普遍的な防御率を証明しないが、「prompt本文だけを固定しても実効契約は固定されない」という境界を支持する。

最低限、評価対象には provider / model ID / API or runtime revision / declared instruction hash / role composition / tool・RAG・memory経路 / exposed safety settings / evaluator / corpus / trial policy / timestamp を結び付ける。material change後は以前のPASSを自動継承しない。

通常ケースだけのgolden testでは不足する。少なくとも、下位roleからの上書き要求、retrieved content内の命令、tool result内の命令、memory由来instruction、長文での競合、拒否・許可境界、instructionの欠落・重複・順序変化をnegative fixtureとして持つ必要がある。

ただし、LLM出力は確率的であり、単発PASSは契約保証ではない。評価はtrial数、sampling条件、判定器、failure定義を固定し、許容閾値は用途のriskに応じて組織側が定める。研究benchmarkの成功率をそのまま本番SLAへ移植してはならない。

• system instructionが存在するため安全だと誤認し、retrieval/tool/memory経路からの競合instructionを評価しない。
• provider/model更新後も旧回帰結果を有効とみなす。
• hidden provider policyの内容を推測し、監査証拠として扱う。
• system promptの秘匿をアクセス制御やsecret managementの代替にする。
• 単発テストまたは一つのbenchmarkで「instruction遵守」を保証済みとする。
• evaluator自体が同一モデル・同一failure modeに依存し、失敗を見逃す。
• multilingual、長文、tool/RAG併用時の競合を評価対象から外す。

• 組織管理instructionをimmutable revisionとして保存し、hashを付与する。
• role/priorityとtool・RAG・memoryの挿入点を構成manifestに記録する。
• provider/model/API/runtimeと公開安全設定を評価receiptへ固定する。
• 正常系に加え、role conflict、retrieved prompt injection、tool-result injection、memory conflict、長文・多言語をriskに応じたnegative suiteへ含める。
• material changeを検出したら旧PASSを失効候補とし、再評価する。
• consequential actionではinstruction遵守だけに依存せず、tool側authorization、schema validation、approval、idempotency、readback等の外部controlを併用する。
• hidden provider stateがreadback不能ならUNKNOWNとして残し、観測可能なconfigurationとbehavioral evidenceで境界を明示する。

このcontrol modelは、system/developer instruction、RAG、tool、memory等を組み合わせるagent/LLM runtimeの変更管理と回帰評価に適用する。特定providerの内部priority実装やhidden policy bytesを共通仕様として一般化しない。provider文書はそのprovider/runtimeの契約証拠であり、研究論文は評価条件内の反証・failure evidenceである。

高リスク操作ではinstruction hierarchyは一つの防御層に過ぎず、IAM、policy enforcement point、tool authorization、approval、transaction/readback等を置き換えない。

• provider documentationは文書化された入力・設定境界を示すが、全てのjailbreak/injectionに対する完全なenforcementを保証しない。
• JustAsk等の研究は特定のモデル・手法・時点に依存し、全provider・全versionで同一の抽出可能性を証明しない。
• PCFI/PhishNChips等の研究結果は評価設定依存であり、本番環境の普遍的防御率ではない。
• provider内部policyの変更が常に外部へ明示的revision signalとして公開されるとは限らない。

• provider/runtimeがhidden policy変更をどの粒度で外部へ通知・readback可能にするか。
• provider横断で移植可能なeffective-instruction manifestの最小共通schema。
• multilingual・長文・複数tool/RAG/memory同時競合に対する用途別の十分なtrial設計。
• evaluator independenceをどの程度要求すれば監査上十分か。
• 実運用でinstruction-contract driftが直接事故へ結び付いた独立incidentの一般化可能な証拠。

「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instructionや未観測の内部policyは、公開された証拠がない限りUNKNOWNとする。instruction hierarchyは重要な制御層だが、consequential actionの外部authorizationやreadbackを代替しない。

• Google Gemini Enterprise Agent Platform — system instructions guidance（登録済みprovenance、2026-10-17再確認記録）。system instructionsのrequest-wide適用と、jailbreak/leakを完全には防げない境界。
• JustAsk, arXiv:2601.21233 — black-box system-prompt extraction study across commercial models。hidden promptを機密境界とみなす一般化へのcounterevidence。
• PCFI, arXiv:2603.18433 — role/priority-aware runtime enforcementの研究 evidence。評価条件外へ防御率を一般化しない。
• PhishNChips, arXiv:2603.25056 — prompt/model configurationとsecurity behaviorの研究 evidence。configuration-bound resultとして扱う。
• EA_REVISION_LEDGER EA-520-R1-20261013 の既存provenance/refresh記録（2026-10-17 03:45 JST）。

監査では、canonical topicがEffective Instruction Contract Envelopeから弱体化されていないこと、instruction presenceとenforcement/confidentialityを分離していること、provider固有事実と研究 evidenceを一般化していないこと、hidden policyをUNKNOWNとしていること、外部authorization等をinstructionで代替していないことを確認する。