まず人で回す。AI には、一歩ずつ任せる

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

多くの会社は、AI から始めません。すでに紙の上で回っている仕事——依頼、確認、押印がふたつ、誰かが実際に手を動かす——と、誰も監査できない表計算の記録から始めます。そこで出る問いは「AI に最初に何を任せるか」ではなく、「いまの流れをそのまま載せて、任せるかどうかはあとで決められるか」です。

GembaOS の答えは「できます」で、しかもそれは特別なモードではありません。手順書の一歩一歩に「誰がやるか」が既定値つきで書いてあります。調査票は、役職を指定しなければ調査担当 AI のもの。申請内容は、役職が記入すると書かなければ GembaOS が記録から組み立てるもの。押印は必ず人か、会社が確認した自動ルール。実施は、役職が手で行うと書かなければ GembaOS がシステムを呼ぶもの。AI は、一歩を担える主体の一つです。

1. 人だけで回る「契約書の押印申請」

参照会社には、モデルの出番が一切ない業務が同梱されています。社員が契約書への社印を申請します。法務が契約台帳を読み、調査票を書きます——保険金請求の窓口で調査担当 AI が書くのと同じ様式で、GembaOS の照合も同じです。法務が入力した相手方と金額は台帳と突き合わされ、違えば誰が書いたものでも「相違」と印が付きます。運用責任者が押印し、金額が百万円を超えるか自動更新条項があれば財務責任者も押印します。それから法務が実物の社印を契約書に押し、押印台帳に記入し、台帳番号を添えて報告します。GembaOS は台帳をもう一度読み、表示された内容を記録します。

この経路を、製品が同梱設定から描いたもの：

決裁の前: 受付 (申請者) → 記録の読取り (GembaOS) → 調査要旨 (人) → 補正書類 (申請者) → 規程が決裁区分を選ぶ (GembaOS)

押印のあと: 実行前の再読取り (GembaOS) → 担当者が実施し、結果を報告 (人) → システムを読み直して照合 (GembaOS)

手作業の一歩を正直に保つ仕掛けは三つです。その操作は「誰も呼ばない」と宣言された操作集に属し、項目も機密区分もほかの操作集と同じように宣言されています。システムからも呼べる操作に人を指定した手順書は、GembaOS が読み込みを拒みます。役職は会社の承認者の役職のひとつで、依頼者は自分の依頼を自分で実施できません。そして読み直しの読取りが書かれていなければ、手順書の検証が「記録は本人の報告しか持たない」と告げます。

2. 人がやったとき、記録はどう見えるか

押印の連鎖は、ほかの窓口と同じように読めます。誰が、どの順で、どの事実の上に押印したか。そのあと、GembaOS による実行の代わりに、指定役職の担当者を待った記録、本人の名前で参照番号と証跡を添えた報告、その報告が一回だけ消費した許可証、そして読み直しの結果——承認内容どおりか、違うか、手順書が特に期待を置かなかったので読んで記録しただけか——が続きます。

「押印できなかった」という報告は、何も閉じません。許可証は無効になり、稟議は本人の理由を添えて差し戻され、案件は担当者のもとで待ちます。実行前の再読取りで世界が変わっていたと分かったときと、まったく同じ扱いです。

3. 同じ手順書のまま、一歩だけ AI に

契約書を AI に読ませて調査票の下書きを任せる準備ができたら、変更は手順書の一行と、その役職の指示書ひとつです。発行前の検証が新旧を比べ、「調査票の作成者が法務から AI になった」と一行で出します。承認の段階、手作業の実施、読み直しは変わらず、稟議書には法務の調査票に付いていたのと同じ「一致／相違」の印が、AI の調査票にも付きます。

移行の道筋はそれで全部です。まず、いま回している人たちの名前で流れをデジタル化し、記録を積む。あとで AI に任せる一歩ごとに、同じファイルへの変更として、別の人が承認します。

出典

• GembaOS 企業向けアーキテクチャ白書 公開版 §3.3（一歩一歩に誰がやるかを書く）。
• 同梱設定：config/playbooks/seal_request.yaml、config/capabilities/seal.yaml（誰も呼ばない操作集）、config/capabilities/contracts.yaml。