📚 連載「AI前提の組織を"組む"」第1回 / 全5回

連載「AI前提の組織を"組む"」第1回。

AI エージェントに仕事を任せると、詰まったときに黙って落ちる。人間の部下なら「できませんでした」と報告するが、エージェントは失敗を自己申告しない。依頼が途中で消えても、しばらく誰も気づかない。本連載は、AI が人間の組織に入っていくときの設計を、再現可能な床として一段ずつ組んでいく（題材は完全に一般化し、特定の実装には触れない）。第1回の破れはこれだ。依頼が「黙って消える」のを、どう構造で禁じるか。

結論を先に置く。「ちゃんと報告する」を心がけに頼ってはいけない。発行された全依頼が「提出・差し戻し・破棄」のいずれかで必ず終端することを、機械が判定できる床にする。順に、破れ・古典・設計で辿る。

失敗は、見張っていない経路で起きる

分散した主体が協調する系では、失敗は見えないところで起きる。Leslie Lamport が 1987 年のメールに残した一句が、その性質を突いている。

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable

分散システムとは、存在すら知らなかった計算機の故障が、自分の計算機を使えなくしてしまうもののことだ（Leslie Lamport, "distribution" email, 1987）。複数の AI エージェントが動く組織も、これと同じ構造を持つ。失敗は、あなたが見張っていない経路で、静かに起きる。

さらに厄介なのは、失敗が「エラー」として立ち上がらないことだ。ストレージの世界には、この静けさを名指す言葉がある。検出されないデータ破損、いわゆる沈黙のデータ破損（silent data corruption）だ。その危うさは、こう説明される。

results in the most dangerous errors as there is no indication that the data is incorrect

（沈黙のデータ破損は）データが誤っているという兆候が一切ないため、最も危険な誤りをもたらす（"Data corruption", Wikipedia）。依頼が黙って消えるのは、これの運用版だ。消えたこと自体が、何の兆候も出さない。だから「気づいたら対処する」では遅い。気づく手がかりが、そもそも発生しない。

誤った状態で走り続けるより、止まる

この「兆候を出さない失敗」への古典的な答えは、止まることだった。フォールトトレラント計算の設計は、故障を隠して走り続けるのでなく、被害が見える前に停止する主体を土台に置く。Schlichting と Schneider が 1983 年に定式化した fail-stop プロセッサは、内部故障に対して自動的に停止し、しかもその故障の影響が外へ可視になる前に停止する。誤った状態のまま走り続けて被害を広げるのでなく、影響が漏れる前に止まる、という思想だ。

Jim Gray は 1985 年に、同じ発想をソフトウェアモジュールの設計原則として述べた。モジュールは fail-fast であるべきで、正しく機能するか、さもなくば故障を検出し、失敗を通知して動作を止めるか、のどちらかであるべきだ、と。この「報告して止まる」を、フォールトトレランスの一般論はこう要約している。

a fail-fast component is designed to report at the first point of failure, rather than generating reports when downstream components fail

fail-fast な部品は、下流の部品が失敗してから報告を出すのでなく、最初の失敗地点で報告するように設計される（Wikipedia「Fault tolerance」）。ここで大事なのは、「stop（止まる）」の前に「report（報告する）」がある点だ。「黙って落ちる」の反対は「黙って止まる」ではなく、「止まったことを報告して止まる」である。

起きたことは、消せない形で残す

止まったことを報告しても、その報告が後から消えては意味がない。近年の公開インフラは、この「消せなさ」を追記のみ（append-only）の監査ログとして設計している。

providing publicly auditable, append-only, untrusted logs of all issued certificates

発行されたすべての証明書について、公開監査が可能で、追記のみで、信頼を前提としないログを提供する（RFC 6962, "Certificate Transparency", 2013）。追記のみとは、いったん書いたものを後から書き換えも削除もできない構造のことだ。だから「後で消えた」を、ログ側から検出できる。組織の依頼も同じで、起きたこと（依頼の発行・提出・差し戻し・破棄）を追記のみの台帳に残せば、「終わっていない依頼」を後から機械的に見つけられる。

設計 — 全依頼が「必ず終端する」床

三つを一つの床にまとめる。心がけでなく、満たさなければ赤くなる条件にする。

1. 終端イベントの強制。 発行された全依頼は、{提出 | 差し戻し | 破棄} のいずれかで必ず閉じる。期限を過ぎて「開いたまま」の依頼の数がゼロであること、を機械判定する。期限超過を黙って放置せず、その時点で人へ差し戻す（fail-fast の「報告して止まる」を、依頼の期限側に適用する）。

2. fail-closed な観測。 観測は執行を証明しない。監視できていない経路（台帳を経由しない直接の書き込みなど）が残るなら、守れている側でなく「対象外」の側に倒して、正直にそう書く（判断に迷ったら安全側へ倒すこの倒し方を fail-closed と呼ぶ）。「見えている範囲で消失ゼロ」を「消失ゼロ」と言い換えない（Lamport の言う、見張っていない計算機の故障を数えない過ちを繰り返さない）。床の主張は、執行できる範囲に正直に限定する。

3. 仕込んだ消失を、必ず捕まえる。 沈黙は兆候を出さないのだから、兆候を人工的に作って検出器を試す。わざと「黙って消える依頼」を一つ仕込み、検出器がそれを毎回必ず捕まえることを、常時確認する。床が緑を返すことだけを見ても、床が本当に効いているかは分からないからだ。この「仕込んで捕まえる」を床一般の見分け方へ広げる話は、第3回で正面から扱う。

この床が緑である限り、依頼は黙って消えない。消えれば床が赤くなり、消えたことが兆候になる。「ちゃんと報告する」という心がけは、ここで「外せない条件」に翻訳された。

次回は、複数の AI が同じ資源を取り合ったときの裁定を扱う。役職や地位で解くと人間組織の密輸になる。機械・判例・人の三段で、どう解くか。

出典

本稿の引用はすべて一次資料と逐語照合（verify_article 通過）のうえ掲載しています（2026-07-12 検証）。

[1] https://lamport.azurewebsites.net/pubs/distributed-system.txt
[2] https://en.wikipedia.org/wiki/Data_corruption
[3] https://en.wikipedia.org/wiki/Fault_tolerance
[4] https://www.rfc-editor.org/rfc/rfc6962.txt

連載「AI前提の組織を"組む"」の前後

→ 第2回: もめ事を「偉い方」で解かない — 機械・判例・人の三段