企業AIのデモが期待どおりに答えても、それだけで本番の業務結果まで信頼できるとは限りません。モデルが正しい判断を出した後に、処理が失われたり、二重に実行されたり、後から理由を追えなくなったりするからです。

2026年8月9日に公開された『The Enterprise AI Trust Stack』は、この問題をOWNS、CALM、ORBITという3つの層に分けました。問われているのは、モデルの賢さだけではなく、どこに構築するか、基盤が責任を担えるか、実行結果を回復・説明できるかです。

では、3つの名前を覚えるだけで終わらせず、設計レビューや運用判断にどう落とし込めばよいのでしょうか。公式のリスク管理資料と分散システムの実装パターンを重ね、具体的な返金エージェントを例に考えます。

モデルの判断が正しくても、業務結果は壊れうる

たとえば、AIエージェントが返金申請を規約どおり承認したとします。ところが、承認記録を書いた直後にプロセスが停止して送金要求が失われれば、判断は正しくても顧客には返金されません。逆にタイムアウト後の再試行で送金が二重になれば、やはり信頼できる結果とはいえません。

ここでは「モデルが何を決めたか」と「業務システムが何を実行したか」の間に溝があります。さらに、その基盤を長期に維持できるか、規制やコストの変化に対応できるかという判断は、実行コードだけでは解けません。

OWNS・CALM・ORBITが役立つのは、この異なる高度の問題を一つの万能チェックリストへ押し込まず、順番のある問いとして分離する点です。

OWNS・CALM・ORBITは「選ぶ→備える→動かす」を分ける

3層は製品スタックではなく、意思決定の進み方を表す提案です。一次ソースで示された役割をまとめると、次のようになります。

層	主な担当領域	答える問い	見る要素
OWNS	戦略・ガバナンス	ここに構築すべきか	所有と経済性、人材・エコシステム・継続性、リスクと規制への対応、AI向けの拡張性
CALM	アーキテクチャ・基盤準備	選んだ基盤は責任を担えるか	Changeability、Assurance、Leverage、Measurability
ORBIT	エンジニアリング・実行	本番条件でも結果を信頼できるか	Outbox First、Rate & Shared State、バックグラウンド実行、初日からの冪等性、すべての追跡

OWNSで長期の依存や出口を考えても、変更しにくく証拠を測れない基盤ならCALMで止まります。CALMで統制可能な基盤を用意しても、リクエスト切断や再試行で副作用が壊れるならORBITで止まります。前の層は次の層を自動的に保証しない、と分かります。

逆に、ORBITのパターンを丁寧に実装しても、そもそも組織が維持できない基盤を選んでいれば、信頼性の高いコードで長期的な問題を固定化しかねません。だから「どのパターンを使うか」より先に、「今はどの問いを解いているか」をそろえる必要があります。

NIST AI RMFと重ねると、3層を規格と誤解せずに使える

OWNS・CALM・ORBITは著者が提案する診断の語彙であり、公的な認証規格ではありません。より広いリスク管理の基準線としては、NISTが2023年1月26日に公開した任意利用のNIST AI Risk Management Framework 1.0があります。NISTは2024年7月26日に生成AI向けプロファイルも公開しており、2026年8月10日時点ではAI RMF 1.0の改訂を進めています。

AI RMF Coreは活動をGovern、Map、Measure、Manageに整理します。ただし、その活動は一方向のチェックリストでも固定順でもなく、AIシステムのライフサイクルを通じて継続・反復するものとされています。ガバナンスを技術設計や運用から切り離さない点は、3層の間を別チームの別会話にしないという問題意識と重なります。

一方で、両者を一対一に対応させるのは適切ではありません。AI RMFはリスクを管理するための成果と活動を広く定義し、OWNS・CALM・ORBITは「戦略→準備→実行」のどこで話が途切れているかを探しやすくします。前者を基準線、後者を会話と診断の補助線として使うのが素直です。

返金エージェントでORBITを具体的な処理へ落とす

冒頭の返金エージェントへ戻りましょう。これは一次ソースにある実装例ではなく、ORBITの意図を分散システムへ置き換えた例です。

1. モデルの判断にdecision_idを与え、入力の参照、適用したポリシー、判断結果を記録します。これが後続処理を説明する起点です。
2. 返金を実行する意図をoutboxへ書き、判断記録と同じデータベーストランザクションで確定します。PostgreSQL 18の用語集が示すとおり、トランザクションは複数の操作を全成功または全失敗の一単位として扱います。
3. バックグラウンドワーカーがoutboxを読み、共有されたレート制限や実行状態を見て外部決済APIを呼びます。AWSのTransactional outbox patternは、データ更新とイベント通知の二重書き込みを避ける一方、メッセージが重複しうるため受信側を冪等にする必要があると説明しています。
4. decision_id、outboxイベント、外部API呼び出しを同じトレースへ関連付けます。OpenTelemetryの分散トレーシングでは、複数サービスを通る要求をspanの連なりとして追えるため、単独のログより実行経路を復元しやすくなります。

この流れなら、HTTPリクエストが切れても返金の意図は残り、同じイベントが再配信されても一つの業務結果へ収束させられます。障害後には、どの判断がどの実行を生んだかも追跡できます。ORBITの5原則は、個別の流行技術より、この失敗境界を設計対象にするための観点だと読めます。

ただし、outboxテーブル、ワーカー、冪等性記録、トレース保管には書き込み量と運用対象が増えるトレードオフがあります。すべてのAI機能へ同じ重さで適用するのではなく、金銭、権限変更、外部通知など、失敗時の影響と再実行の難しさが大きい処理から厚くするのが現実的です。

導入は3層すべてではなく、最初に止まる問いから始める

3層を新しい成熟度モデルとして一括導入すると、また部門別のチェック項目が増えるだけになりがちです。実務では、現在の意思決定に合わせて入口を変えた方が使いやすくなります。

• 新しいデータ・AI基盤を選ぶ段階なら、OWNSで利用拡大時の費用、人材の継続性、規制変更時の選択肢、移行可能性を意思決定記録へ残します。
• 本番投入前なら、CALMで変更手順、統制の証拠、チームが再利用できる基盤能力、品質や費用を測る指標が実際にそろうか試します。
• ワークフローを実装する段階なら、ORBITで「DB確定直後の停止」「重複配信」「クライアント切断」「外部APIのタイムアウト」を再現し、結果とトレースを見ます。

最初の「いいえ」が見つかった層を、次の投資対象にします。一次ソースも、すべてのシステムへすべてのパターンを初日から適用するのではなく、重大なAI施策が3つの問いへ最終的に答えられることを求めています。

なお、OWNS・CALM・ORBITには公開された採点式、合格点、認証制度、参照実装は示されていません。レビュー結果を合格バッジに変えるのではなく、未回答の問いと必要な証拠を見つける道具として扱うのが安全です。

信頼はモデルの外側まで説明できる結果で決まる

企業AIを信頼できるかという冒頭の問いには、モデル評価だけでは答えられません。構築先を選んだ根拠が残り、基盤が変化と統制を担え、実行が停止や重複から回復し、結果まで追跡できて初めて、組織は業務上の判断材料を持てます。

OWNSは「ここでよいか」、CALMは「責任を担えるか」、ORBITは「本番で結果を守れるか」を問い直します。実務上の意味は、3つの略語を導入することではなく、AIの信頼をモデルの内側だけに閉じず、戦略から副作用まで切れ目なく証拠へ変えることにあります。

出典

• Title: Vibhor Kumar: The Enterprise AI Trust Stack: How OWNS, CALM, and ORBIT Fit Together
• URL: https://postgr.es/p/9rR