最終承認を引き受けるのは、なぜ人間なのか
実行担当の AI は「手を動かすだけ」でいいという話をしました。その次に、実行担当とは独立した監査担当が「問題を炙り出す」という役割を担います。
では、最後の「進める」「止める」という判断は、誰が出すのでしょうか。
それが三権のうちの最後のピース、承認担当です。この仕組みでは、承認担当は人間が引き受けます。
承認担当とは何か
承認担当の仕事は、「進めてよい」という意思決定をすることです。
実行担当が作業を終え、監査担当が確認をした後、最後に「これで GO」と引き受けるのが承認担当です。
この役を人間に置いているのには、理由があります。
AI は実行できます。監査もできます。ただ、「この判断の責任は自分にある」と引き受ける主体は、今のところ人間にしかできません。誰かが責任を負う必要があるとき、その所在を明確にしておくための設計として、承認担当は人間が担います。
「人間が見ないと信用できないから」という話ではありません。「誰が責任を持つか」を構造として残すために、人間がその役に立つ、ということです。
なぜ最終的な GO は人間が出すのか
実行と監査をどれだけ精度高く設計しても、「進める」という判断には、引き受ける主体が必要です。
ここで重要になるのが「不可逆な行為」（一度やったら取り消せない操作）との向き合い方です。
たとえば、記事を公開する、ファイルを削除する、外部サービスに何かを送信する。こうした操作は、実行した後から「なかったことにしてほしい」と言っても、そう簡単にはいきません。取り消せない以上、実行前に「本当に進めるのか」を確認する関所が必要になります。
その関所に立つのが、承認担当の人間です。
実行担当と監査担当が AI であるがゆえに、不可逆な操作の手前で「人間が確認した」という事実を作ることができます。それは記録にも残ります。何かあったときに「なぜその判断をしたのか」を説明できる根拠になります。
逆に言うと、可逆で小さな操作（やり直しが効く、影響範囲が小さい作業）まで全部人間が確認するのは現実的ではありません。軽い作業を毎回止めて確認していると、全体の流れが詰まります。
だから、人間の確認を「不可逆・重要」なものに絞ります。可逆で軽い作業は AI 側に任せる。その強弱をつけることで、承認担当の集中力が本当に必要な場面に向きます。これが実際に回すときのコツです。
承認担当は何をして、何をしないか
承認担当が「する」ことは、基本的に「進める／止める」の判断です。
細部の実装には踏み込みません。「こういう仕組みにすればよかったのでは」という後からの設計変更を、承認のタイミングで持ち込むと、プロセスが崩れます。承認は「ここまでのプロセスを経た結果として、進めるかどうか」を決める行為です。設計に戻りたいときは、承認の前に戻る必要があります。
もうひとつ意識していることがあります。承認をひとりで完結させない、という考え方です。
不可逆で重い判断は、視点がひとつだと見落としが出やすい。別の人間が同じ内容を見ると、気づかなかった問題が浮かぶことがあります。「ひとりで決め切らない」という構造が、特に大きな意思決定では効きます。深掘りは別の機会に譲りますが、この仕組みでも不可逆な操作には二者確認を挟んでいます。
さらに、承認の判断は記録に残します。「なぜ GO を出したか」を書いておく。これが文書主義（意思決定の根拠をテキストで残す考え方）とつながっています。承認は気分や流れではなく、説明可能な行為として残る必要があります。あとから見返せる記録があることで、同じ構造の判断が次に来たとき、過去の判断を参照できます。
三役が噛み合って、初めて動く
実行（AI）が作業を完遂し、監査（AI）が問題を炙り出し、承認（人間）が進むかどうかを引き受ける。この三役が別々の担当に分かれていることで、それぞれが自分の仕事に集中できます。
「誰かが何かをやったとき、誰が確認していて、誰が責任を負っているか」が構造として見えている状態。それがこの仕組みの目指していることです。
三役が一体になっていると、作業と監査と承認が同じ場所で起きます。何か問題があっても、どこで何が起きたのかが追いにくい。三つを分けることで、問題が起きたときに「どこのレイヤーで起きたのか」が見えやすくなります。
実際に動かしてみると、この構造の恩恵は「問題が起きたとき」ではなく「何も起きていない日常」でじわじわ感じます。毎回の作業が記録として積み上がり、誰が何を判断したかが残っていく。それが二週間、一か月と続くと、仕組みへの信頼が少しずつ育ちます。
三権分立の三役はここまでです。