たいていのソフトウェアは、何が変わったかを覚えています。ある変更がなぜ許されたのか、それを誰が、あるいは何が決めたのか、その判断がどんな根拠に立っていたのかを覚えているソフトウェアは、はるかに少ないのです。まさにこの隙間で、信頼は静かに損なわれていきます。運用チームはたいてい「いまの状態はどうなっているか」には答えられますが、「どうやってここに至ったのかを見せてほしい、そして我々にその権限があったことを証明してほしい」にはしばしば答えられません。
Threada は、その二つ目の問いに常に答えられるように作られています。統制された操作はすべて、レシートを残します。
レシートに実際に含まれるもの
レシートはログ行ではありません。ログ行は「何かが起きた」と言うだけです。レシートは、後になって判断を再構成し、弁護できるだけのことを語ります。Threada では、統制された操作は次を記録します。
- アクター。 人間のオペレーターか AI の参加者かを、区別されたアクターイベントとして記録します。エージェントの承認が人のものになりすますことは決してありません。
- 入力。 WorkItem、そこから抽出された実体、依頼者の身元、そして依頼が届いた発生元チャネル。
- 根拠。 引用、検索のトレース、そして — 文脈が不十分だった場合には — 明示的なフォールバック理由。引用か記録されたフォールバック理由のいずれかがなければ、Work は作成できません。
- ポリシー。 どのポリシーセットが、どのバージョンで有効だったか、そしてそれがテナント全体に適用されたのか、それとも絞り込まれた pack、ワークフロー、チャネル、依頼者グループに適用されたのか。
- 結果。 操作が提案、承認、却下、実行、成功、失敗のいずれであったか — それが触れた外部レコードへの戻りリンクとともに。
これらのフィールドをまとめて読めば、ひとつの手順について弁護に耐えうる説明が得られます。WorkItem のライフサイクル全体にわたって読めば、その完全な履歴が得られます。
後付けの機能ではなく、既定としての監査可能性
たいていのシステムでは、監査を後で足したくなるものです。まず機能を出荷し、顧客が SOC 2 の証跡を求めたり規制当局がやってきたりしたら、それをログで包む、というわけです。この順序は逆です。後から足された監査は常に部分的です。判断が下されたその瞬間に文脈を担うよう、システムが一度も求められていないからです。
Threada はこの順序を逆転させます。ランタイムは、意味のある遷移ごとに構造化イベントを発行します — work_item_created、approval_requested、approval_decided、action_proposed、action_executed、fallback_triggered — 作業を行うという行為そのものが、それを記録する行為と同一だからです。「監査をオンにする」という別個の手順はありません。作業が記録の外で起きる瞬間が、そもそも存在しないからです。
このモデルは記録とレシートのモデルだ、と言うとき、私たちが意味しているのはこのことです。記録は、あなたが生成するレポートではありません。それは作業を正しく行ったことの残滓なのです。
レシートがチームの動き方をなぜ変えるのか
レシートは、四半期末の監査人にとって有用です。けれどもその、より静かな価値は、ありふれた火曜日のただ中にいるオペレーターのためにあります。
すべての操作がその根拠とポリシー上の拠り所を携えるとき、三つのことが容易になります。
- レビューが速く、正直になる。 承認者は文脈を記憶から再構成したり、元の依頼を知るために依頼者を追いかけたりする必要がありません。根拠は操作のすぐ隣にあります。確信度、可逆性、明瞭さが判断の地点で見えるので、レビュアーは速さだけでなくレビューしやすさのために最適化します。
- 取り消しが安全になる。 レシートがポリシーのバージョンと入力を名指しているため、操作を巻き戻すことは定義された手続きであり、考古学のプロジェクトではありません。あなたは何を取り消そうとしているのか、そしてなぜそれが行われたのかを分かっています。
- 説明責任が敵対的でなくなる。 記録がおのずと組み上がるとき、「これを承認したのは誰か」は告発ではなく — ただのフィールドです。構築者、承認者、ガバナンスの各役割の間の職務分掌は強制され、可視であるため、説明責任の問いは、誰かが尋ねる前にすでに答えられています。
リスクの高い作業は人間の手に、記録の上に残る
レシートは、すべてが自動化されていることを意味しません。すべてが説明責任を負えることを意味します。リスクの高い自動化は、明示的なヒューマン・イン・ザ・ループの段階を踏みます — 提案され、次に承認され、次に実行へ — そしてポリシーが明示的に許可する場合にのみ自動実行されます。ある操作がそれらのどの経路をたどったかを、レシートが記録します。自動化と承認は対立していません。どちらも痕跡を残す手順にすぎないのです。
その結果が、監査人にも新任のオペレーターにも同じ自信をもって手渡せるシステムです。監査人は統制が保たれたことを見ます。オペレーターは、前の担当者が目の前の案件をどう扱ったかを見ます。両者は同じレシートを読んでいるのです。
これが Threada の根底にある賭けです。判断がなぜ許されたのかを捉えるのに最も安上がりな時は、あなたがそれを下すその瞬間であること。そして、決して記録の外で作業しないチームこそ、いつでも二つ目の問いに答えられるチームだということ。