{
  "format": "agent-article-v0",
  "article_id": "EA-520",
  "canonical_url": "/tools/ea-520-effective-instruction-contract-envelope",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EA-520-CURRENT-APPROVAL",
    "EA-520-CURRENT-BODY-READBACK"
  ],
  "unknown_ids": [
    "EA-520-UNKNOWN-01"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-18",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "ORPHAN-RESCUE-EA520-20261019-C1",
    "BODY-SHA256:1cfa36a878692265d731223ad22ccefaf6bce5e0b6f0536ab5ceca79ec3edd2f"
  ],
  "article_sources": [
    {
      "id": "EA-520-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "ORPHAN-RESCUE-EA520-20261019-C1"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-520&revision_id=EA-520-R1-20261013&candidate_id=ORPHAN-RESCUE-EA520-20261019-C1",
        "EA-520-R1-20261013"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-520-CURRENT-BODY-READBACK",
      "evidence_class": "IMPL",
      "title": "現行本文の収録照合",
      "supports": [
        "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。"
      ],
      "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。",
      "checked_at": "2026-10-19",
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "BODY-SHA256:1cfa36a878692265d731223ad22ccefaf6bce5e0b6f0536ab5ceca79ec3edd2f"
      ],
      "supporting_locators": [
        "content/staging/EA-520.md",
        "1cfa36a878692265d731223ad22ccefaf6bce5e0b6f0536ab5ceca79ec3edd2f",
        "EA-520-R1-20261013"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "要点と前提",
      "text": "CANDIDATE_ID: ORPHAN-RESCUE-EA520-20261019-C1"
    },
    {
      "heading": "要旨",
      "text": "Enterprise AIで「system instructionを設定した」という事実は、その指示が実行時にどのような優先順位で合成され、どの経路から干渉され、どの程度の確率で守られたかを証明しない。運用上必要なのは、宣言したinstruction bytesだけでなく、provider/model/API/runtime、role/priority、tool・RAG・memory等の注入経路、公開されている安全設定、評価条件を一つの有効命令契約として版管理し、変更時に回帰評価することである。"
    },
    {
      "heading": "主要claim",
      "text": "### 1. 宣言されたinstructionと実効的なenforcementは別物である\n\n\nsystem/developer/user/retrieved instructionは、モデルに与えられる入力契約の一部である。しかし、その存在だけから「必ず従う」「下位instructionから上書きされない」「秘密として保持される」を導いてはならない。Google Gemini Enterprise Agent Platformのsystem-instruction guidanceはsystem instructionsがrequest全体へ適用される一方、jailbreakやleakを完全には防げない旨を明示している。したがって、instruction presenceはsecurity enforcementの証明ではない。\n\n\n運用上は、少なくとも次を分離して記録する。\n- declared instruction artifact: 組織が管理できるsystem/developer等の本文、hash、revision。\n- composition contract: role/priority、連結順、retrieval/tool/memory等がどこへ挿入されるか。\n- provider/runtime state: model/API/runtime、安全設定など外部に観測可能な実行条件。\n- observed enforcement: conflict、prompt injection、tool/RAG/memory注入を含む評価結果。\n\n\n### 2. hidden provider instructionを「既知の正本」として扱わない\n\n\nproviderが内部で追加するhidden policy/system textの完全なbytesは、providerが明示的に公開・readbackしない限りUNKNOWNである。モデル挙動から内容を逆算して正本化してはならない。また、hidden system promptは機密境界そのものでもない。JustAsk（arXiv:2601.21233）は商用モデルを含むblack-box system-prompt extractionを研究対象としており、少なくとも「system roleに置けば秘密になる」という一般化を否定する反証となる。\n\n\n従って、監査記録では「組織が設定したinstruction」「providerが文書化したpriority/policy」「観測された挙動」「非公開でUNKNOWNな内部instruction」を別欄にする。\n\n\n### 3. instruction contractはprovider/model/runtimeまで含めてversion bindingする\n\n\n同じ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本文だけを固定しても実効契約は固定されない」という境界を支持する。\n\n\n最低限、評価対象には 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を自動継承しない。\n\n\n### 4. regression testはinstruction hierarchyの衝突を含める\n\n\n通常ケースだけのgolden testでは不足する。少なくとも、下位roleからの上書き要求、retrieved content内の命令、tool result内の命令、memory由来instruction、長文での競合、拒否・許可境界、instructionの欠落・重複・順序変化をnegative fixtureとして持つ必要がある。\n\n\nただし、LLM出力は確率的であり、単発PASSは契約保証ではない。評価はtrial数、sampling条件、判定器、failure定義を固定し、許容閾値は用途のriskに応じて組織側が定める。研究benchmarkの成功率をそのまま本番SLAへ移植してはならない。"
    },
    {
      "heading": "failure modes",
      "text": "- system instructionが存在するため安全だと誤認し、retrieval/tool/memory経路からの競合instructionを評価しない。\n- provider/model更新後も旧回帰結果を有効とみなす。\n- hidden provider policyの内容を推測し、監査証拠として扱う。\n- system promptの秘匿をアクセス制御やsecret managementの代替にする。\n- 単発テストまたは一つのbenchmarkで「instruction遵守」を保証済みとする。\n- evaluator自体が同一モデル・同一failure modeに依存し、失敗を見逃す。\n- multilingual、長文、tool/RAG併用時の競合を評価対象から外す。"
    },
    {
      "heading": "control / implementation implication",
      "text": "1. 組織管理instructionをimmutable revisionとして保存し、hashを付与する。\n2. role/priorityとtool・RAG・memoryの挿入点を構成manifestに記録する。\n3. provider/model/API/runtimeと公開安全設定を評価receiptへ固定する。\n4. 正常系に加え、role conflict、retrieved prompt injection、tool-result injection、memory conflict、長文・多言語をriskに応じたnegative suiteへ含める。\n5. material changeを検出したら旧PASSを失効候補とし、再評価する。\n6. consequential actionではinstruction遵守だけに依存せず、tool側authorization、schema validation、approval、idempotency、readback等の外部controlを併用する。\n7. hidden provider stateがreadback不能ならUNKNOWNとして残し、観測可能なconfigurationとbehavioral evidenceで境界を明示する。"
    },
    {
      "heading": "適用境界",
      "text": "このcontrol modelは、system/developer instruction、RAG、tool、memory等を組み合わせるagent/LLM runtimeの変更管理と回帰評価に適用する。特定providerの内部priority実装やhidden policy bytesを共通仕様として一般化しない。provider文書はそのprovider/runtimeの契約証拠であり、研究論文は評価条件内の反証・failure evidenceである。\n\n\n高リスク操作ではinstruction hierarchyは一つの防御層に過ぎず、IAM、policy enforcement point、tool authorization、approval、transaction/readback等を置き換えない。"
    },
    {
      "heading": "counterevidence / limitations",
      "text": "- provider documentationは文書化された入力・設定境界を示すが、全てのjailbreak/injectionに対する完全なenforcementを保証しない。\n- JustAsk等の研究は特定のモデル・手法・時点に依存し、全provider・全versionで同一の抽出可能性を証明しない。\n- PCFI/PhishNChips等の研究結果は評価設定依存であり、本番環境の普遍的防御率ではない。\n- provider内部policyの変更が常に外部へ明示的revision signalとして公開されるとは限らない。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- provider/runtimeがhidden policy変更をどの粒度で外部へ通知・readback可能にするか。\n- provider横断で移植可能なeffective-instruction manifestの最小共通schema。\n- multilingual・長文・複数tool/RAG/memory同時競合に対する用途別の十分なtrial設計。\n- evaluator independenceをどの程度要求すれば監査上十分か。\n- 実運用でinstruction-contract driftが直接事故へ結び付いた独立incidentの一般化可能な証拠。"
    },
    {
      "heading": "SAFE_WORDING",
      "text": "「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instructionや未観測の内部policyは、公開された証拠がない限りUNKNOWNとする。instruction hierarchyは重要な制御層だが、consequential actionの外部authorizationやreadbackを代替しない。"
    },
    {
      "heading": "source / provenance locator",
      "text": "- Google Gemini Enterprise Agent Platform — system instructions guidance（登録済みprovenance、2026-10-17再確認記録）。system instructionsのrequest-wide適用と、jailbreak/leakを完全には防げない境界。\n- JustAsk, arXiv:2601.21233 — black-box system-prompt extraction study across commercial models。hidden promptを機密境界とみなす一般化へのcounterevidence。\n- PCFI, arXiv:2603.18433 — role/priority-aware runtime enforcementの研究 evidence。評価条件外へ防御率を一般化しない。\n- PhishNChips, arXiv:2603.25056 — prompt/model configurationとsecurity behaviorの研究 evidence。configuration-bound resultとして扱う。\n- EA_REVISION_LEDGER EA-520-R1-20261013 の既存provenance/refresh記録（2026-10-17 03:45 JST）。"
    },
    {
      "heading": "監査観点",
      "text": "監査では、canonical topicがEffective Instruction Contract Envelopeから弱体化されていないこと、instruction presenceとenforcement/confidentialityを分離していること、provider固有事実と研究 evidenceを一般化していないこと、hidden policyをUNKNOWNとしていること、外部authorization等をinstructionで代替していないことを確認する。"
    }
  ],
  "human_url": "/tools/ea-520-effective-instruction-contract-envelope",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-520-effective-instruction-contract-envelope",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-520-effective-instruction-contract-envelope"
}