命名・登録済み
各アクション — refund.issue、payout.send、close.case — は、キー、入力スキーマ（必須キー）、riskLevel、requiresApproval フラグを持つレジストリのエントリです。
Action Fabric
エージェントに実際の行動を — 実際のリスクは負わせずに。
エージェントが取りうるすべてのアクションは、第一級の統制対象オブジェクトです。リスク階層と承認ポリシーを備えた名前付きアクションに加え、dry-run → propose → approve/deny → execute → compensate を各ステップの証跡パックとともに記録する、変更不能な呼び出し台帳が付きます。
dry-run → propose → approve/deny → execute → compensate · フェイルクローズ
Action Fabric
ドライラン›
240ドルの返金
リスク: 低 · 証跡
提案済み›
ケース #4471 をクローズ
リスク: 中 · 証跡
承認待ち›
5,000ドルの支払い
リスク: 高 · 証跡
実行済み
顧客にメール送信
リスク: 低 · 証跡
actions ▸ ドライラン → 提案 → 承認 → 実行 → 補償
統制対象オブジェクトとしてのアクション
ツール呼び出しは願望にすぎない。統制されたアクションには説明責任がある。
統制されていないエージェントはツールを直接呼び出します — リスク階層も、承認も、何が実行されどう取り消すかの記録もありません。Cortex では、すべてのアクションがリスクレベルと承認ポリシーとともに登録され、すべての呼び出しが追記専用の台帳に記録されます。高リスクのアクションと承認必須のアクションは、管理者が承認するまで決して実行されず、拒否されたアクションは一切実行されません。
リスク階層付き
riskLevel: high または requiresApproval が指定された呼び出しは pending_approval へ送られ、低リスクのアクションは即時に実行されます。リスクは期待ではなく、アクションが持つ属性です。
改変不能な記録
ドライラン、提案、承認、却下、実行、補償のすべてが cortex_action_invocations に追記されます — 監査人にそのまま渡せる証跡です。
取り消し可能
rollbackKey を宣言すれば、実行済みのアクションはいつでも補償できます — ランタイムが補償アクションを実行し、元のアクションを compensated としてマークします。
解決する課題
エージェントが書き込めるようになった瞬間、リスクの性質が変わる。
読み取り専用のエージェントは簡単です。リスクが生じるのは、エージェントが返金を実行し、案件をクローズし、支払いを送るときです。意図と結果の間にファブリックがなければ、副作用をモデルに委ねることになります — 5,000ドルの支払いに承認ゲートはなく、何が実行されたかの記録もなく、取り消す手段もありません。Action Fabric は、提案と副作用の間に既定拒否のガバナンス層を置きます。
高リスクのアクションは pending_approval へ — 自動実行はされませんdeny → denied として記録され、実行エンジンは呼ばれませんcompensate → 宣言済みの rollbackKey が実行済みアクションを取り消し
ライフサイクル
提案から証明可能な結果へ — そして元に戻すまで。
すべての呼び出しは、同じ5状態のライフサイクルをたどります。各遷移は証跡パックとともに台帳へ追記されるため、どの副作用についても事後に全経緯を再構成できます。
- 01
ドライラン
アクションの必須キー・スキーマに対して入力を検証します。副作用は一切発生しません — 何かが起きる前に、呼び出しの形式が正しいことを確かめる安全なリハーサルです。
- 02
提案
アクションを実際に投入します。riskLevel: high または requiresApproval のアクションは pending_approval に入り、それ以外はポリシーの下で即時に実行されます。
- 03
承認 / 却下
管理者のみ、AdminGuard で保護されます。承認すると統制実行エンジンが動き、却下すると理由とともに denied が記録され、実行エンジンは一度も呼ばれません。
- 04
実行
統制実行エンジンは ActionExecuted または ActionFailed（P4 イベント）を発行します。P7 アダプター規則により、明示的に許可されない限りモックは本番に入りません。
- 05
補償
管理者のみ。アクションが rollbackKey を宣言していれば、ランタイムが補償アクションを実行し、元のアクションを compensated としてマークします — 監査可能でクリーンな取り消しです。
来歴
すべてのアクションは、依頼した人まで遡れる。
ファブリックの中身
レジストリ、台帳、エグゼキューター、そしてその間のゲート。
アクションレジストリ
- 名前付きのアクションキー
- 入力スキーマ（必須キー）
- riskLevel: low / med / high
- requiresApproval フラグ
- 任意の rollbackKey
呼び出し台帳
- 追記専用の呼び出し記録
- ステップごとの証跡パック
- dry-run → … → compensate の各状態
- テナント単位に限定した読み取り
- 監査人にそのまま渡せる証跡
承認インボックス
- pending_approval のキュー
- approve / deny は管理者のみ
- 却下理由を記録
- AdminGuard で保護
- テナントはプリンシパルから取得
統制実行エンジン
- 既定で決定論的
- ActionExecuted / ActionFailed (P4)
- P7 アダプター規則
- ライブドライバーは ACTION_EXECUTOR_MODE の背後
- 有効化しない限り実システムには触れない
オントロジー・スコープ
- propose 時の任意の objectId
- オブジェクトの型を解決
- 許可アクションの強制
- 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- オブジェクトと型を証跡に記録
補償処理
- rollbackKey の宣言
- 補償アクションを実行
- 元のアクションを compensated に更新
- 監査され、管理者限定の取り消し
- 取り消し可能な副作用
主張ではなく、証明を
既定は拒否。台帳がレシート。
同じファブリックが6つの率直な結果をどう扱うかをご覧ください — 問題のない実行、高リスクによる保留、実行に至らない管理者の拒否、補償によるロールバック、そしてオントロジーのスコープ外として即座にブロックされたアクション。各行は、それぞれの証跡パックを持つ追記専用の台帳エントリです。
- 高リスクのアクション → 管理者が承認するまで pending_approval
- 却下されたアクション → denied として記録され、実行エンジンは呼ばれない
- オブジェクトの型が不正 → 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- rollbackKey を持つ実行済みアクション → きれいに compensated
呼び出し台帳
dry-run
refund.issue · input { amount: 240 } · schema ok
validpropose
payout.send · riskLevel: high → pending_approval
pending_approvalapprove
payout.send · admin: risk-ops@northwind → executed
executeddeny
close.case · reason: 査定担当者のレビューが必要
denied · 実行されずexecute
email.customer · riskLevel: low → ActionExecuted (P4)
executedcompensate
refund.issue · rollbackKey → refund.void → compensated
compensatedpropose
delete.record · objectId: Claim/4471
403 ACTION_NOT_PERMITTED_FOR_OBJECTactions ▸ 追記専用 · 各ステップに証跡パック · approve / deny / compensate は管理者限定
5呼び出しごとのライフサイクル状態
100%台帳に記録される呼び出しの割合
403型が不正な場合は ACTION_NOT_PERMITTED_FOR_OBJECT
0実行エンジンに到達する却下済みアクション
Action Fabric
ドライラン›
240ドルの返金
リスク: 低 · 証跡
提案済み›
ケース #4471 をクローズ
リスク: 中 · 証跡
承認待ち›
5,000ドルの支払い
リスク: 高 · 証跡
実行済み
顧客にメール送信
リスク: 低 · 証跡
actions ▸ ドライラン → 提案 → 承認 → 実行 → 補償
オントロジーにスコープされたアクション
アクションが許されるのは、触れてよいオブジェクトの上だけ。
propose に objectId を渡すと、ランタイムがオントロジーオブジェクトの型を解決し、actionPermittedForObject(allowedActions, key) を適用します。型の許可リストが空であればどのアクションも許可され、空でない場合はアクションキーが含まれていなければ提案はブロックされます。オブジェクトとその型は呼び出しの証跡に書き込まれ、ontology-service に到達できない場合はフェイルオープン（ログに記録）となるため、ガバナンスが障害の原因になることはありません。
- 型の allowedActions が空 → すべてのアクションを許可
- リストが空でない場合、アクションキーが含まれていなければ拒否
- ブロックコード: 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- 監査証跡のために evidence.ontologyObject に記録
ランタイム全体と連携
アクションは自らを統制しない — 統制するのはプラットフォーム。
Action Fabric は、アイデンティティ・ポリシー・監督・台帳と同じフェイルクローズなランタイムの内側にあります。各スポークをたどってください。
Policy-as-Code
allow / deny / require_approval のルールを作成し — 例：amountUsd ≥ 5000 → require_approval — 本番投入の前にシミュレーションできます。
監督モード
5 つの自律モードが、エージェントが単独で実行できる範囲を決めます — リスクゲートは下限であり、オーバーサイトは締める方向にしか動かせません。
Trust Ledger
実行されたすべてのアクションは、署名済みでオフライン検証できるレシートとともに、改ざん検知可能な監査証跡へハッシュチェーンされます。
オントロジー
オブジェクト・プロパティ・アクションの権限が、アクションに統制されたビジネス上の意味を与えます — 上記の objectId スコープもここから来ます。
Agent IAM
エージェントは、許可リスト化されたアクションを持つ統制されたアイデンティティです — エージェントは自らのアイデンティティが認めるアクションしか提案できません。
Control Tower
すべてのアクション呼び出しをライブで監視し、エージェント群を一時停止し、ガバナンスレポートをワンクリックで書き出せます。
セキュリティとコンプライアンス
エンタープライズのセキュリティレビューを見据えた設計。
管理者に限定された承認、既定拒否の実行、追記専用の証跡、そしてモックを本番から締め出す P7 アダプタールール — 監査人がすでに用いるフレームワークにマッピングされています。
SOC 2ISO 27001ISO 42001HIPAAGDPREU AI ActNIST AI RMFFINRA
エージェントに手を与える — そして手綱も。
すべてのエージェントのアクションを、統制されたライフサイクルの下に置く。dry-run、承認、実行、ロールバック、そして各ステップの完全な証跡。