GembaOS
GembaOS の個別ケースと実機画面
各記録は一つの仕組みを掘り下げます。チーム全体の仕事のつながりは、一日のガイドからご覧ください。
GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。
GEMBAOS の実際の画面
申請から判断の記録まで。
導入シナリオごとに実機の画面を 1 本ずつ。流れを選び、承認待ちの稟議台、人の押印、実行、監査の再判定を順に追えます。
返金申請 1 件を、最初から最後まで。
返金申請 1 件を稟議の最初から最後まで追えます。承認待ちの稟議台、人の押印、返金の実行、そして監査の再判定です。
エージェントの押印は 3 つ揃いました。人の上長は判断の前に、機械照合済みの事実と「承認するとどうなるか」（効果、金額と上限、許可証の有効期間、実行前に照合し直す項目）を業務の言葉で確認します。
同じ稟議書の上で、申請の元になったやり取りが 1 クリックで開きます。顧客が書いた文面、受付が返した定型文、受付番号。チャット基盤から取り寄せたものではなく、作業票の記録から組み立てたものです。
上長がパスキーで押印。稟議書は 4 つの押印で保管され、1 回限りの許可証が発行されます。
保管された稟議書の全体です。承認者が見た全項目、4 つの押印とその理由、実行が消費する 1 回限りの許可証が並びます。
その許可証に基づいて返金が実行され、顧客に正式回答が届きます。全工程が封緘済みの時系列に残ります。
処理の事象ログの抜粋です。最初の数件と最後の数件を示します。エージェントの手番、ポリシー判定、業務機能の呼び出し、押印、許可証、実行がすべて順に記録され、各行にハッシュが付きます。
すべての判定を現行ポリシーで再判定。経路・規則チェーン・誰がどの段階で押印したかが記録に残ります。
CRM の案件はそのまま閉じる。 決裁の記録はこちらに残す。
エスカレーション中の案件を GembaOS からクローズします。上長は CRM の外で押印し、ホストは案件を読み直して一度だけ閉じ、決裁は案件のコメントとして書き戻されます。この画面の CRM は kintone です。
エスカレーション中の案件のクローズは CS 上長の前で止まります。稟議書には、担当者が見てよい項目に絞った案件の現状と、クローズ理由が並びます。
上長がパスキーで押印。稟議書は保管され、この案件・この理由に限った 1 回限りの許可証が発行されます。
ホストが案件を読み直し、承認者が見た内容と照合してから、許可証の下でクローズします。転記が決裁を案件のコメントとして書き戻します。
事象ログの抜粋です。最初の数件と最後の数件を示します。事前読取、稟議、押印、前提条件の照合、クローズ、案件へのコメントがすべて順に記録され、各行にハッシュが付きます。
判定を現行ポリシーで再判定。経路（エスカレーション中なので人）、規則チェーン、誰が押印したかが記録に残ります。
4 つのアカウント。押印は 1 回。 一覧は誰も打っていない。
名簿同期が社内側の退職処理を済ませ、アカウント停止の稟議を 1 通開き、IT 管理者が 1 回押印し、各アカウントはそれぞれの許可証で停止されます。人事側の誤記は自分の行だけで失敗し、他を止めません。
同期がエクスポートを取り込みました。4 名削除、4 名退職処理、そして開かれた一括処理——発起人は名簿同期、名義は情シス担当と記録されます。
1 通の稟議に全行が並び、各アカウントの変更前の状態が添えられます。誤記の ID は「記録を読めなかった行」として見えます。
IT 管理者が 1 回押印。アカウントごとに 1 枚、それぞれの引数に紐づいた許可証が 4 枚発行されます。
押印が一括処理を自動で再開します。3 件は停止、存在しない 1 件は単独で失敗して報告され、一括処理は続きます。
1 行を現行ポリシーで再判定。IT 管理者への経路、規則チェーン、押印が記録に残ります。
自分の言葉で説明する。 確かめてから依頼する。
従業員は社内依頼の画面で、必要なだけやり取りしながら用件を説明し、業務の判断は受付アシスタントに任せます。アシスタントは、その人が依頼できる業務のうちどれに当たるかと、本人の言葉を生かした依頼内容を提案します。提案はシステムが検査し、従業員が依頼するまで何も始まりません。この記録のアシスタントはデモ用の代役で、言語モデルではありません。
最初の文は、一次切り分けと手順書の調査の両方を頼んでいます。どちらの業務にも当たるため、アシスタントは両方を提案し、それぞれの根拠になった本人の言葉を示して、どちらかを尋ねます。作業票はまだありません。
「まずは切り分けを」の一言で決まります。提案は一つになり、依頼内容には前の発言も残ります。従業員は依頼内容を書き換えてから依頼することもできます。
受付票には業務、票番号、担当、次の一手が表示されます。審査済みの報告は同じ画面に届きます。
運用コンソールでは、メニューが用途別にまとまっています。対話記録の冒頭には依頼前の会話が並び、担当者は依頼の全体を読めます。
記録：本人の名前で添付された受付の会話、外部チケットとの連携、不足 3 件の記録、報告の審査と正式回答、完了。エージェントはログを読んだだけで、状態は何も変わっていません。
深夜のアラート。 手は「読む」だけ。
監視のアラートが、誰もいない時間に一次切り分けを起動します。エージェントはログを読むことしかできず、審査済みの報告が責任者に届きます。足りなかったものは不足台帳と、人の審定を待つナレッジ草案として残ります。
会議の決定を、 承認済みの議事録だけで動かす。
Teams の字幕を取り込むと、会議は閉じた記録として入ります。SCRIBE が議事録を起案し、主催者が担当者を書き入れて承認。宿題は承認済み議事録だけを出典に作業票になります。字幕に紛れ込んだ指示文は議事録に残りません。
請求を読むのはモデル、 決めるのは人。
調査担当（モデル）が届いた材料を読んで要旨を渡し、GembaOS が読み取った値をすべて請求記録と照合します。本人確認済みで指摘のない少額請求は規程のルールで決裁。記録と異なる領収書や大口の請求は人に回り、人は全ページではなく要旨を読みます。
受付時、調査担当が写真を分類します。傷害の請求には診療記録と領収書が必要なので、GembaOS が自ら申請者に依頼します。窓口の誰もまだ案件に触れていません。
書類が届き、調査担当が読み直しました。書類上の金額と受傷日はどちらも請求記録と一致。金額が即時処理の上限を超えるため、査定担当が起票します。
査定担当の稟議書は要旨から始まります。書類と記録の照合、書類はワンクリック、続いて承認で動くこと。
査定担当の押印後に保険金部長が開いた稟議書。前回閲覧以降の変化は所見「担保範囲内」の押印一つ。その下に残る決定ひとつと要旨。
要旨が止めた少額請求。診療所の領収書は ¥18,000、請求は ¥12,000。その行に「相違」が付き、即時処理にはならず査定担当が押印します。準備金は記録どおりの金額のままです。
台風の少額請求。請求書は記録と一致、申請者は確認済み、指摘なし。規程のルールが職務権限表の範囲内で決裁し、許可証のもとで準備金を計上して読み戻します。
実機の画面：見本データ、模擬押印
画面キャプチャの先へ。ご自身のテナントで検証。
完全隔離された専用サンドボックステナントを即座に起動し、実際の台帳記録、稟議起案、押印チェーンを一貫して体験いただけます。安全境界を意図的に検証することも可能です。承認完了後に注文内容の改ざんを試みても、実行直前にホスト環境が台帳を再照合し、不正な支払いを確実に阻止して差し戻します。テナントは他の訪問者から完全に隔離され、退出時に自動的に消去されます。
デモ環境のモデルはスクリプトに従って動作し、どのような指示にも従います。画面上で発生する拒否や差し戻しはすべて GembaOS の決定論的統制によるものであり、モデル側の自律的な振る舞いによるものではありません。
最終更新: · GembaOS v0.2