ReadinessOpsGuide

Google Cloud版の検証経路では、EvidenceをAI処理より前にModel Armorで検査します。危険な入力はBLOCKし、モデルや後続Agentへ渡しません。

検査を通過したEvidenceから、新しいGoverned Revisionを作ります。前のRevisionは履歴に残し、比較、再現、rollbackができる状態を維持します。

Evidence Impactを先に確定し、再評価する境界、Agent、判断項目を限定します。影響範囲が曖昧なまま、すべてをモデルへ渡すことはしません。

Material driftが既存の安全根拠へ影響する場合、再評価より先に対象AgentをSUSPENDEDへ移します。SUSPENDEDは失敗や削除ではなく、再確認まで実行を止める統制状態です。

Revision ID、Evidence Impact、対象Agentのstatus、trace IDをそろえて確認します。ここで状態が揃わなければ、AIによる再評価へ進めません。

Governance、Value、Routingなどの観点を専門Agentへ分け、それぞれが同じEvidenceと対象範囲を参照して評価します。役割を分けても、実行権限は与えません。

専門Agentの結果を、変更点、根拠、リスク、推奨、未解決事項が分かるDecision Packへまとめます。結論だけではなく、判断に必要な差分を残します。

Decision Packの重要な主張をEvidenceへ照合します。根拠が欠ける内容は、確定事項としてHuman Reviewへ渡さず、未解決または再評価対象として示します。

検証を通過したDecision Packも、状態はREVIEW_REQUIREDです。AIは承認もPublicationも行わず、人の判断を待ちます。

AIは候補の生成、比較、根拠整理を担えます。一方、人の承認作成、正式状態のPublication、保護された実行は担いません。

人はaction、tool、data、impact、例外条件を確認し、Delegation Boundaryを狭めたり、人の確認へ戻したり、禁止へ変更したりします。

権限を持つ人が、対象Revisionを承認、差戻し、または拒否します。理由と未解決事項を記録し、後から同じ判断条件を再構成できるようにします。

ReadinessOpsでは、承認とPublicationを別の状態遷移として扱います。承認は提案内容を人が受け入れた記録です。Current Stateを変えるのは、対象Revisionを明示的にPublicationしたときだけです。

したがって、このStepの前後でCurrentは変わりません。

Evidenceから提案、差分、人の判断理由までを同じtrace IDへ接続します。Traceはログ一件ではなく、判断と状態遷移を追える一連の証跡です。

承認後もRevisionはNOT_PUBLISHEDとして保持されます。運用へ反映するか、いつ反映するかを、次の独立した判断としてPublicationへ渡します。

Publicationは、保存された人の承認とexact revisionの一致を検査してから実行します。別の版への差替えや、会話内容からの承認推定は行いません。

PublicationされたRevisionから、新しいACTIVE boundaryを作ります。旧版はSUPERSEDEDとして履歴に残し、実行Gateは新しいACTIVE版だけを参照します。

PublicationとAgentのREADY再開を別の状態遷移として扱います。必要な再検査が完了し、公開済み境界を参照できることを確認してから再開します。

Evidence、Revision、AI assessment、人の判断、Publication、ACTIVE boundaryを履歴としてつなぎます。次の変化もCurrentを上書きせず、この履歴から新しいRevisionを始めます。

GateはAgentのREADY、ACTIVE boundary、要求action、data、impactを決定論的に照合します。境界外のactionは、AgentがREADYでもDENIEDです。

Google Cloud版では、Analysis Identity Aからの保護実行を拒否します。分析能力と実行能力をIdentityレベルで分離し、promptやtool呼出しだけでは越えられない境界にします。

Executor Identity Bだけが保護実行へ到達できます。Identityが正しくても、GateはACTIVE boundaryとaction条件を再検証し、許可された範囲だけを実行します。

Evidence受領、検査、Revision、AI assessment、人の判断、Publication、Gate判定、実行結果へ同じtrace IDを引き継ぎます。重複要求は識別し、同じ処理を二重実行しません。

AIは提案し、人が判断し、Publicationが正式状態を定め、公開済み境界が実行を制御します。これがReadinessOpsの一連の運用設計です。

公開実装は、Vertex AI、Agent Development Kit、Agent Runtime、Agent Identity / Gateway / Registry、Model Armor、Cloud Run、Pub/Sub、Cloud Storage、Firestore、Cloud Build、Artifact Registry、Cloud Loggingを組み合わせています。

この一覧は構成事実であり、公式partnerや本番保証を意味しません。

公開READMEは、Evidence → Model Armor → governed Revision / Evidence Impact → specialist reassessment → Human Review → Explicit Publish → deterministic gate → Traceという経路を記録しています。

Guideはこの検証経路を説明し、未検証の本番運用を付け足しません。

検証済み動作には、pre-LLM BLOCK、Analysis IdentityのDENIED、境界外actionのDENIED、重複要求の無視、同一Revisionのretry、単一trace ID、Executor Bによる許可経路があります。

安全性は『通った』だけでなく、『止まるべき時に止まる』ことで確認します。

公開demoはsynthetic text evidenceを使用し、customer dataやPIIを含みません。汎用PDF pipelineとproduction enterprise connectorは対象外です。本番化には個社の認証・権限、保持、監視、tenant分離などの追加設計が必要です。

ソリファン公式サイト、Google Cloud版とSnowflake版の公開repository、AI Delegation BoundaryのWebMCP実装、ChromeとFirebaseの公式資料へ進めます。