その AI は何をしてよいのか — 稟議ルートの図を、設定から出す

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。

この記事で扱うのは、AI の PoC や実証実験が完了したあとに、監査部門や経営層から必ず突きつけられる問いです。「この AI エージェントは、結局のところ何を実行してよい権限を持っているのか。誰がそれに合意し、先月どのような変更が加えられたのか。」

資料と実物の乖離：静かに広がるセキュリティホール

多くの企業では、この問いに対して PowerPoint や Visio で描かれた業務フロー図を提出します。プロジェクト発足時にアーキテクトが図を描き、部門長が承認して社内文書管理システムに保管する。しかし運用の 9 か月の間に：

• 承認閾値が 8,000 円から 20,000 円へと微調整された；
• 繁忙期の一四半期だけ決裁者を 1 名追加し、そのまま戻し忘れた；
• 想定外の例外ケースを処理するため、エンジニアがコードに分岐を追加した。

保管された図面は一切更新されていません。

9 か月後、その図面が証明しているのは「初月に何をするつもりだったか」という過去の意図だけであり、現在の実態を何一つ証明できません。

これは文書管理の怠慢ではありません。システムの横で人手によって保守される図面は「2 つ目の正本」であり、IT 運用の歴史において、2 つ目の正本は常に破綻します。

動いている設定から出力する（Single Source of Truth）

GembaOS では、稟議ルートはコードの中に埋め込まれた場当たり的な条件式でも、静的なお絵描きでもありません。業務規約（プレイブック）における厳格な宣言です。どの条件が稟議書のどの決裁区分を選択し、誰が承認（押印）し、AI が不確実性を申告した際に誰へエスカレーションされ、書き込み直前に何を再照合するか。

この宣言こそが、GembaOS 実行基盤が本番で実際に評価・実行する対象です。 したがって、システムから直接ビジュアルな図面として出力できます。

以下は、参照用の便振替プレイブックの承認ルートを、設定ファイルから直接出力したものです：

決裁の前: 受付 (お客様) → 記録の読取り (AI) → 規程が決裁区分を選ぶ (GembaOS)

AI が判断をつけられないと申告した場合: 稟議に添えられ、その決裁区分の署名者より先に担当の決裁者が答える — 運賃規則が読み切れない → 収益管理 · 経路が同等とは言い切れない → 収益管理.

押印のあと: 実行前の再読取り (GembaOS) → 許可証による実行 (GembaOS)

同じ変更を、ツールに通すと:

$ gemba playbook diff <previous> flight_rebooking
LOOSER   rebook_route band 1: threshold 80 -> 200
STRICTER approvalRoutes.rebook_route: now forces a person: agent_recommends_otherwise
DATA     capabilities.knowledge__search: granted to SPECIALIST (ALLOW)
DATA     capabilities.knowledge__get: granted to SPECIALIST (ALLOW)

この生成された統制モデルには、3 つの重要な設計思想が反映されています：

1. 実行主体がルートの一部であること：各工程がモデルの番なのか、名前のある人間の押印なのか、あるいは GembaOS 実行基盤自身の処理なのかが明記されます。最後の 2 行が最も重要です。実データを再照合し、ワンタイム許可証のもとで書き込みを実行するのは GembaOS です。AI モデルは提案を行うのみで、実行権限は一切保持しません。
2. AI による不確実性の能動的申告：モデルは判断に迷った際、あらかじめ定義された一覧から「判断不能」を申告し、規約に従って人間の責任者へエスカレーションします。この申告を行ったモデルは、その区分の自動承認権を即座に失います。「分からない」と申告した主体が、裏で勝手に自己承認することは構造的に不可能です。
3. 条件式の厳密性：管理部門向けの表現と、監査向けの評価式は完全に 1 対 1 で対応します。ツールが自然言語化できない複雑な条件は、無理に意訳せずそのまま表示されます。

変更審査（CAB）が本当に必要とするもの：差分とリスクの方向性

静的な図面が答えるのは「いま何が動いているか」です。変更諮問委員会（CAB）や監査担当者が知りたいのは「何が変わり、どちらの方向へ動いたか」です。

GembaOS では、同じプレイブックの 2 つのバージョン（例：Git 上の変更前と現行版）を直接比較し、差分ごとに向きを自動算出します：

• LOOSER（緩和）：必要な承認人数が減った、あるいは AI が単独で処理できる金額や権限が拡大した；
• TIGHTER（厳格化）：承認ステップが増えた、あるいは自動処理の範囲が縮小した；
• DATA（データ参照範囲の変更）：特定の役割が閲覧できるフィールド範囲が変化した；
• UNPARSED：構造が大幅に書き換えられ、手動での精密レビューが必要。

この判定は人間が書いた主観的な説明文ではなく、承認ルールの論理包含関係から数学的に導かれます。「2 つの複雑なコードを読み比べて、どちらがより多くの抜け穴を生むかを人間の頭の中で推測する」という認知負荷と人的ミスを完全に排除します。

GembaOS が行わないこと（責任の所在）

GembaOS は宣言を正確に解析し、差分とリスクの向きを可視化します。

しかし、その変更が企業のビジネスとして妥当かどうか——例えば 20,000 円の返金が CS 責任者 1 名の決裁で十分か、運賃の例外を収益管理部門に割り当てることが適切か——を判断するのは、稟議書に名前が載る人間の責任です。

GembaOS の役割は、意思決定を行う人間が「自分が何に承認を与えようとしているのか」を最も低いコストで正確に把握できるようにし、監査人が「いつ何が変わったか」を完全に検証可能にすることです。

これこそが GembaOS の一貫した原則です。すべての行為に人間の名前を結びつける。AI が問題を発見して影響を計算し、人間がリスクを評価して最終決定を下す。