技術資料

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。このページは『GembaOS 企業向け技術資料』の公開閲覧版（文書番号 GEMBA-WP-2026-PUB、v1.17.1、2026 年 10 月 1 日）で、CISO、CTO、CIO、企業アーキテクト、リスク・コンプライアンス・監査の担当者に向けて書いています。

なぜ企業はエージェントを本番に入れられないのですか？

GembaOS の出発点は一つの観察です。ERP、本番データベース、特権ドメインへエージェントを入れられない理由はモデルの推論能力ではなく、リスク管理委員会の四つの問いに既存の仕組みが答えられないことにあります。

1. 権限の出所: エージェントの書き込みと設定変更の一つ一つを、誰が承認したのか。
2. 責任の所在: プロンプトインジェクションや幻覚で損失が出たとき、法的な責任者は誰か。
3. データの境界: 多段の推論の中で、エージェントは権限のない機微な項目をどこまで読んだのか。
4. 証拠: 何が、どの規則で、誰によって決まったのか。記録が後から書き換えられていないことを、監督当局や法務監査にどう示すか。

LLM ファイアウォールやシステムプロンプトは文章を扱い、API ゲートウェイは鍵と流量を確かめます。それだけでは、一つの業務行為についての企業の権限の連鎖——誰が決めてよいか、何が承認されたのか、実行する時点で事実がまだ成り立っているか——を表せません。エージェントが文章を出すだけの間は、リスクは読む人が負っていました。API を呼べるようになった瞬間、文章の層の防御では足りません。ファイアウォールを一度抜けられれば背後の API はすべて露出し、長期の認証情報を持つエージェントは自律的な計画の中で想定外の書き込みをします。

これらの問いは四つの層にまたがります。AI の検出、実行時のゲートウェイ、業務ワークフローの製品はそれぞれその一部を扱い、承認の手順や引数の制御を備えたものも少なくありません。下の表は、各層で GembaOS がどこに立つかを示します。

アーキテクチャの原則は何ですか？

GembaOS は暗黙の信頼を置きません。モデルの良識に頼らず、企業の権限規程、二人一組の確認、職務分掌、規制の基準を、機械が確定的に執行する規則に翻訳します。次の原則が基盤全体を貫きます。

• 厳格な代行権限: エージェントが社員の代わりに動くとき、有効な権限はエージェントの役割の権限、ログインした社員本人の権限、現在のプレイブックが宣言する境界の三つの共通部分です。社員が見られない財務データをエージェントが代わりに読むことはなく、社員が承認できない購買をエージェントが代わりに承認することもありません。これが代行実行です。
• 責任の空白を作らない: 誰も責任を負わない自律操作は存在しません。すべての作業票、参照、稟議書が、企業の IAM または SSO 上の自然人に結び付きます。
• データ境界はゲートウェイに: 権限のない項目と不要な文脈は業務機能ゲートウェイで切り落とされ、モデルの文脈に入りません。データベースの参照は列を宣言した読み取り専用ビューとパラメータ化されたプロシージャだけを通り、自由な SQL は受け付けません。
• 統制は AI に向ける、担当者に向けない: 自律エージェントには社員番号がなく、失うものもありません。だから四つの関門をすべて通します。一方、自分の権限とその資格で操作する管理者は別です——責任はすでにその人にあり、対象システムの監査ログにも名前が残っています。ここで GembaOS がするのは、順番待ちを作ることではなく記録を残すことです。稟議の決裁区分は、実行する本人が一度の署名で通せるものにできます。緊急の区分では順序が入れ替わり、先に実行し、直後にハードウェアキーと記入済みの理由を添えて、区分が指名した保安担当へ自動で通知されます。緊急時に立ちふさがる統制は、やがて迂回される統制です。
• モデルが替わっても権限は変わらない: 承認規程、業務契約、安全境界はモデルから独立しています。自社ホストのモデルをクラウドの最新モデルに替えても、その逆でも、誰が何をしてよいかは変わりません。ただし、その範囲の中でモデルがどう振る舞うか（品質やツールの選び方）は変わるため、シャドーリプレイとゴールデンテストが切り替え前に差異を示します。
• ベンダー側の変更は、驚きではなく審査案件になります: 連携インターフェース契約にはベンダーが返す応答の形が宣言されており、スケジュールされたプローブがベンダーのサンドボックスに「今も同じ形で返すか」を問い合わせます。実際に返ってきた形はそのまま変更候補となり、ガバナンスカーネルが自らの宣言（前提条件、項目一覧、稟議の条件）を照らし合わせて、何が動かなくなるか、それが沈黙のまま起きるかを表にします。審査は名前のある責任者の正式な権限のもとで起票され、ルートが定める押印を必要とします。設定されていない変数は「未実施」として記録され、「合格」にはなりません。受理後は修正作業がエンジニア個人の担当として割り当てられ、サンドボックス内で作成されたプルリクエストは、本人のアカウントでその人がレビューしてマージします。

四つのゲートの実行エンジンはどう動きますか？

GembaOS は、業務の状態を変えるすべての重要な操作を、ポリシー判定、押印チェーン、ワンタイム許可証、実行前の現況照合という四つのゲートに順に通します。

• 決め方は二つだけ: 操作を決めるのは、名前のある人か、会社があらかじめ定め、社内の名前のある人が確認した自動ルールのどちらかです。人の押印がない区分は自動ルールとして宣言しなければ Playbook は読み込まれません。テンプレートに入っていた自動ルールは、御社の誰かが確認するまで効力を持たず、ルールを変えれば確認し直しになります。自動ルールで通った操作には、押印チェーンにどのルールの、どの版で、誰が確認したものかが残り、「課長承認」のようには記録されません。
• AI の押印は意見: AI の審査は、決める人の前に稟議を読み、理由を添えます。却下を勧めても稟議はそこで終わらず、決める人に回ります。区分に人が残っていないときは、AI の異議で経路が指定する人が呼ばれ、自動ルールでは通らなくなります。お客様に「お断り」が届くのは、名前のある人が却下したときだけです。システムによる受付拒否、モデルの障害、度重なる差し戻しは、人が引き取ります。
• 誰も判断していないものは、無人の区分を通らない: AI が提案せずシステムが記録どおりに補った申請と、誰の依頼でもなくルールでシステムが起票した作業票には、必ず人の押印が要ります。
• 四つのゲートが及ばないところ: 統制されるのは GembaOS を通る呼び出しだけです。読み直すのは Playbook が宣言した事実、または承認者が見た記録であって、世の中のすべての事実ではありません。GembaOS の外から書き込む者に対して古い書き込みを止められるのは、対象システム自身の版管理や条件付き書き込みだけで、GembaOS の対象ロックが順番をそろえるのは自分を通る書き込みに限られます。ワンタイム許可証は、システムをまたいで「ちょうど一回」を保証するものではありません。対象側の冪等性、書き込み後の読み戻し、応答のない書き込みの扱いは本番接続時の受け入れ確認の範囲で、受け入れ試験がこれらの場合を実行基盤に対して一つずつ確かめます。

承認者が不在のとき、別の人が判断すべきときはどうなりますか？

GembaOS は、押印待ちの稟議書をめぐる人の動き（回付、移送、上申、引き取り）を、理由付きの統制された操作として記録します。組織図は貴社の社員名簿から取り込みます。

• 厳しくなる方向にしか動かない: 四つの操作はいずれも押印ではありません。必要な押印を減らすことも、同じ稟議で一人が二つの役割を兼ねることもありません。
• すべてに理由を残す: どの操作も作業票のハッシュチェーン記録に事象として残ります。差戻しと却下にも理由が必要で、承認には備考を付けられます。
• 押印した人が責任を負う: 代理人、上申先、引き取った上長は、それぞれ自分のパスキーで押印します。押印チェーンには誰の代理かが残ります。
• 組織図は既存の台帳から: 上長、在籍状況、休暇は、貴社の ID プロバイダーや人事システムのエクスポートから取り込みます。GembaOS が持つのは、その上の統制ルールだけです。
• 代理規則: 金額の閾値、リスク、業務の種類で決められます。たとえば「限度以下は次席が代理」「契約条項に関わるものは先に法務へ回付」。規則に当てはまると、人が行ったときと同じ回付や代理の記録になります。
• 退職・異動時の権限の引き継ぎ: 新たな押印は割り当てません。押印待ちの稟議は、貴社の方針に従って在席する直近の上長へ移すか、割り当て待ちにします。持っていた代理は取り消します。進行中の作業票は取り消して再起票を促します。承認済みで未実行の操作は（許可証がまだ発行されていないものも含め）、決裁区分や機密区分に応じて許可証を無効にし、改めて稟議に回せます。退職者が担当していた処理は、在席する直近の上長か、その処理のもとの担当者に戻ります。
• チームの机: 上長は自分の机の隣で、部下に掛かっている押印待ち、期限超過、担当者不在、代理中、高リスクの案件を見て、人、部門、業務、期限、リスク、滞留時間で絞り込めます。
• 動いているエージェントにも、名前のある担当者が一人: 数時間から数日続く作業でも、担当者は常に一人です。既定では依頼した本人が担当です。閲覧できる人は実況で見られます。誰が見ているかは画面に出ますが、記録には残しません。エージェントに指示できるのは担当者だけで（補足、絞り込み、Playbook の範囲内での向け直し）、エージェントは次の手順でそれを読みます。指示で変わるのはエージェントが「試みること」で、「許されること」は変わりません。指示の文面も、外から届くメッセージと同じ注入検査を通ります。名前のある本人に結び付かないログインは、見ることはできても担当にはなれません。終業時、担当者は同僚に引き継ぎを打診し、相手が引き受けるまで担当は移りません。一日たっても引き受けられない打診は失効します。上長は会社の引き取り規則に従って引き取れます。保留・再開・キャンセルには、操作した人の名前と理由が残ります。どれも押印者を変えません。押印はルートが定める役割のままで、引き継ぎや引き取りで担当になった人は、通常の決裁区分ではその案件に押印できません。見ている人も、その処理についてアシスタントに聞けます。回答は本人の権限で作られ、本人にだけ表示されます。担当者はそれを自分の指示に使えます。
• 稟議書は業務の言葉から: 稟議書の最初の画面は「承認するとどうなるか」に答えます。効果と取り消せるかどうか、対象、金額、上限（照合時の数値付き）、許可証の有効期間と使用回数、実行前に何を照合し直すか、誰が実行するか。許可証の番号やハッシュなどの技術的な識別子は、監査用に折りたたんであります。システムが照合した項目と照合していない項目は分けて示します。どこからも採点されていないリスクを「合格」とは表示せず、申請理由が事実かどうか、添付ファイルに写っている内容は、システムが確認していないものとして明示し、押印する人の判断に委ねます。

数週間かかる案件は、どうやって一枚の稟議にまとまりますか？

保険金請求は、数週間にわたり、添付が十数点になり、査定、医療審査、法務をまたぐことがあります。GembaOS は、こうした案件を稟議書ではなく作業票の上で扱います。

• 作業票は長く、稟議書は短く: 受付の後、案件は担当者を待って止まります。担当者は申請者に書類を依頼します（種類は決められた一覧から、期限付き、回数の上限あり）。申請者は作業票ページでファイルと一言を添えて返します。期限切れは記録され、その後は Playbook の設定に従います（既定では担当者が判断）。書類がそろって初めて稟議を起票します。案件全体で稟議書は一枚、押印も一巡です。
• 申請者は見られて、確認できて、書き換えられない: 申告内容は記録から描画します（本人の言葉、ファイル、対象、受付日時）。申請者は「確認」するか「どこが違うか」を書くだけで、訂正は記録に追記され、元の申告は変わりません。確認はハッシュで固定され、稟議書には「申請者が何日にこの申告を確認した」と載ります。
• 回付先の所見はデータ: 医療審査や法務など回付先の役割は、Playbook が定める一覧から所見を一つ選んで押印します。所見は押印チェーンに入り、次の押印者は所見を含めた内容に押印します。
• 所見が次の一手を決める: Playbook は所見ごとに、決められた一覧から一つの動作を定めます。別の役割がすぐ後に押印する、担当者へ差し戻す、差し戻したうえで申請者に指定の書類を依頼する、のいずれかです。承認者が選ぶのは所見だけで、その後の動きは Playbook が決めます。
• 前回からの変化: 稟議書は閲覧者ごとに前回どこまで見たかを覚えています。戻ってきた人には、まず変化（待った日数、その間の押印と所見、新しいファイル、書類依頼の回数、訂正、確認）を示し、次に「残る決定はひとつ」を示します。押印待ちの役割、Playbook がその役割に書いた問い、未決の最新の所見です。押印の対象そのものは変わりません。
• 事実は Playbook から導く: 事故日や購入日からの日数、書類依頼の回数、ファイル数、申請者の確認の有無などを、その役割がもともと見られる値から、貴社の営業日カレンダーで計算します。決裁区分や代理規則から参照できます。Playbook に自由な式は書かず、個人の代理規則は引き続きフォームで設定します。
• 案件をメールだけで完結できる: メールで届いた案件では、記録した申告内容を確認コード付きで申請者に送ります。コードを返信すれば確認、それ以外の返信は訂正として記録します。書類の依頼もその都度メールで送り、申請者はファイルを添付して返信するだけです。
• エージェントも書類を依頼できるが、伝えるのは種類だけ: Playbook で有効にすると、担当エージェントは一覧にある書類を申請者に依頼できます。申請者に届くのは必要な書類の種類だけで、エージェントの理由は担当者にだけ届きます。新しく届いた画像は、まず受付側で一度だけ説明され、他のエージェントはその説明だけを見ます。
• 読むのはモデル、決めるのは人: 案件の Playbook は調査担当を宣言できます。調査担当はモデルで、申告、添付、回答済みの追加書類、Playbook が読ませる記録を読み、署名する人に型の決まった要旨を渡します。書類から読んだ値、経緯、一覧の種類の論点（約款の条項は記録のとおりに引用）、不足書類、相談先です。さらに、できる参謀のように推奨を出します。どの結果を勧めるか、理由を三つまで（条項の引用は他と同じく条文と照合）、検討した別の選択肢とその帰結、リスクです。稟議書では推奨を「AI の意見（決めるのはあなた）」として別枠で示し、承認しようとしている内容と一致しているかどうかも示します。金額は提案せず、押印もしません。推奨はリスクフラグを上げる方向にしか働かず、実行する内容を変えることはありません。推奨が既定の結果と違えば即時処理は閉じ、人が決めます。記録に対応項目がある値は GembaOS がすべて照合し「一致」「相違」を付け、記録にない条項はその旨を示します。相違・論点・要旨の欠落はリスクフラグとなり、経路に人を加える方向にしか働きません。
• 少額で指摘のない案件の即時処理: Playbook は、申請者が申告を確認した少額の案件を規程のルール（御社が確認したもの）で決裁させることができます。ただしテナントの職務権限表の範囲内で、要旨を含めて何も指摘がないときに限ります。それ以外の案件は担当者のもとに残り、理由が記録されます。調査担当を置かない案件は、これまでどおり実行基盤だけで受け付けて起票します。
• 必要書類はランタイムが依頼: 案件の Playbook は、案件に必要な書類を記録の項目（請求の区分など）ごとに定められます。調査担当はファイルを書類の種類に分けるだけで、GembaOS が各ファイルを案件に実際にあるファイルと照らし、足りない書類を数えます。必要書類の不足はリスクフラグです。Playbook で有効にすると、足りない種類の依頼は GembaOS が自ら出します。受付時と回答のたびに、Playbook の回数上限の範囲で、期限前に一度督促します。書類が届かないときは Playbook の設定に従います。担当者が判断する、指定の役割に回付する、書類不備で終了する（支払可否の判断ではない）、または不支払を押印する人に諮る、のいずれかです。期限切れだけで不支払が実行されることはありません。
• 引用した条項には条文の語句を添える: 案件が引用できる条項の一覧（約款の免責条項など）を Playbook が定める場合、その条文を返す読取りも併せて定められます。条項を引く論点は条文の語句を引用することになり、GembaOS は引用を、調査担当自身の読取りが返したその条項の本文と照合します。条文にある語句か、条文にない語句か、そもそも引用がないかを用紙に明記し、最初の一つ以外はリスクフラグです。引用の横には条文の全文を印刷し、引用した一文に印を付けます。照合が示すのは語句が条文のものであることまでで、条項が論点を支えるかどうかは人の判断のままです。
• お客様が読む文面は型文。文ごとに言い換えを許可できる: 作業票の正式回答は会社が書いた型文で、どの型文を出すかは記録に基づいてランタイムが決めます。モデルは関与しません。Playbook で文を指定すれば、その一文だけを平易に言い換えることを許可できます。言い換えるモデルに渡すのはその一文だけで、案件も記録も見せません。書かれた原稿は出る前に照合します。型文にない数字と、長すぎる原稿は GembaOS 自身が差し戻します。さらに別のモデルが原稿を型文と読み比べ（結論が同じか、事実を足していないか、約束をしていないか、指示を加えていないか、この件から出ていないか）、破られた項目の id だけを返します。文章は返しません。通らなかった原稿は型文に戻すか、破られた id だけを伝えて一度だけ書き直し、それでも通らなければ型文に戻します。作業票には言い換えである旨を示し、元の型文をその場で開けるようにします。お客様自身が確かめられます。正式回答には決まった内容（返金額など）を書きます。お断りの場合に引用するのは押印した人が自分で書いた理由だけで、AI の審査や担当エージェントの言葉はお客様に渡りません。
• お客様からの再度の問い合わせは、まずご本人の作業票へ: お客様が再び連絡してきたとき（新しいチャットでも）、アシスタントはそのお客様自身の作業票にある確認済みの事実をもとに、用件が進捗の確認か、書類の追加か、新しい依頼か、人との対応かを判断します。進捗の確認にはその場で答え、作業票を重ねて作りません。回答に出る数字はすべて事実の中になければならず、さらに別の審査モデルが新たな約束、決定の変更、理由の創作、範囲を超えた開示がないかを確かめ、通らなければ型文に戻します。異議、例外、補償、法的な主張、お客様の権利に関わる変更は、その作業票の責任者の机に届くタスクとなり、責任者が書いた回答が本人の名前でお客様の作業票に届きます。
• 五つの案件窓口を標準搭載: 保険金請求、購買例外（申請者は社員）、保証交換、会社秘書の登記事項変更（顧客企業の取締役・秘書・登記住所・重要支配者の変更。届出期限と顧客確認を事実として扱う）、不適合品の処置（品質技術者が保留中のロットについて特採・手直し・廃却・返品を申請）です。申請者が案件を開けるのは自分の記録だけで、他人の請求番号、製造番号、購買依頼番号、変更申請番号、不適合報告番号は存在しないものとして扱います。どの窓口にも調査担当がつき、記録と添付（写真を含む）を読み、主要な値を照合し、論点を挙げ、理由を添えて推奨します。保証交換では写真から故障か誤用かを見分け、不適合品では特採・手直し・廃却を比べます。押印する人と決裁のルールは変わりません。
• 押印したものが、そのまま実行される: 案件で何をするかは、申請者が指定した記録の項目（変更の種類と届出様式、提案処置）で決まり、押印者が選ぶものではありません。実行の直前に記録を読み直し、押印の後に書き換えられていれば稟議は差し戻され、何も実行されません。

AI を一切使わない業務でも始められますか？

はい。しかもそれは特別なモードではありません。手順書の一歩一歩に「誰がやるか」——人、AI、GembaOS 自身、会社が確認した自動ルール——が既定値つきで書いてあります。AI は一歩を担える主体の一つであって、手順書の前提ではありません。

• 調査票は人が書いてもよい：案件窓口で調査担当 AI が書く様式と同じで、記録との照合も同じです。人が書いた内容は本人の名前で記録され、GembaOS は人自身の言葉を審査しません。
• 申請内容は人が記入してもよい：記入した項目は AI と同じ規則で確認されます（記録の値を超えない、記録が示す選択肢の中から）。稟議書には記入者が明記され、記入者はその稟議に押印できません。
• 実施は人が手で行ってもよい：押印がそろって許可証が出ると、GembaOS は何も呼びません。作業票は指定役職の担当者を待ち、担当者は自分のログインでそのシステムで作業し、手順書が求める証跡を添えて自分の名前で「実施した」と報告します。報告が許可証を一回だけ消費します。手順書に読取りが書かれていれば GembaOS がシステムを読み直し、承認内容どおりか、または読んで記録した旨を記します。書かれていなければ、記録は「本人の報告のみ」と明記します。「実施できなかった」という報告は稟議を差し戻します。
• 人が実施する操作も操作集の操作：項目・機密区分・項目単位の規則を持ち、「誰も呼ばない」と宣言されます。システムからも呼べる操作に人を指定した手順書を、GembaOS は読み込みません。
• 経路図はどの一歩も担い手のレーンに描き、一歩を人から AI へ（またはその逆へ）移す発行は、変更点の一覧に一行で出ます。

参照会社には人だけで回る業務——契約書の押印申請——が同梱されています。法務担当が契約書を読んで調査票を書き、運用責任者と財務責任者が押印し、法務が手で押印して台帳番号を報告し、GembaOS が台帳を読み直します。あとから一歩を AI に任せるのは、同じ手順書への一回の発行です。GembaOS はワークフローツールの代替ではありません。売り物は四つのゲートと記録であり、人はもともとその中の主体の一つです。

データ・成果物・監査記録はどう統制されますか？

GembaOS はすべての記録に機密区分、業務ドメイン、データ所在地の印を付け、作業票の事象を追記専用のハッシュチェーンで保持します。

• 成果物の機密区分: エージェントが起草するコード変更と報告書は、統制された成果物として管理されます。変更差分セットは触れたファイルの最も高い機密区分を引き継ぎます。成果物がサンドボックスを出る操作（マージ、提出、社外送信）は統制対象の操作であり、同じポリシー判定と押印を通ります。
• 会議室とナレッジの境界: 会議の生の記録がそのまま指示になることはありません。書記エージェントだけが議事録を起案し、主催者が承認して初めて作業票になります。閲覧権限のない機密文書への問い合わせには「存在しない」と答え、本当に存在しない場合と区別がつかないため、探りを入れることができません。
• 会議室のアシスタントは、質問した人として働く: 会議にいる誰でもアシスタントに質問でき、アシスタントは質問者本人の権限で情報を読みます。読んだ記録は質問者本人の記録に残ります。会議の発言だけで答えられる回答は、誰が質問したかを添えて会議に出ます。質問者の権限で読んだ情報を使った回答は本人にだけ見える下書きになり、本人がそのまま、または書き直して自分の名前で送るか、破棄します。アシスタントに会議のどこまでを見せるかは引き続き主催者が決め、会議室で承認や実行が行われることはありません。
• 会議のアクションアイテムは、ふさわしい業務へ: 議事録が確定すると、アクションアイテムごとに、担当者が起票できる業務の中からアシスタントが一つを提案します。起票する人が確認するか選び直してから起票され、担当者が起票できない業務は拒否されます。
• ハッシュチェーン監査記録: 作業票のすべての事象は追記され、暗号学的なハッシュチェーンで連結されます。改変、削除、順序の入れ替えは連鎖を壊し、完全性はいつでも検証できます。連鎖は記録が書き換えられたことを示しますが、保存領域をすべて握る者が連鎖全体を作り直すことまでは防げません。そのために貴社の WORM 媒体や外部のアンカーを使います。記録は通常のファイルで、法的証拠や否認防止の要件に応じて企業が選ぶ WORM 媒体に置けます。GembaOS 自体は WORM ストレージを同梱しません。監査再生は記録済みの判定を現行ポリシーで再実行します。モデルや外部システムを再実行するものではありません。
• 決裁ルートは図に出せる、版と版で比べられる: プレイブックが宣言した決裁ルートは図として出力できます。実装と法務には識別子とカーネルがそのまま評価する条件で、ルートに同意する業務側にはコンソールと同じ言葉で——同じ一つの図の二通りの読み方であり、どちらも設定から生成したものであって、描いたものではありません。図が実際の動きと黙って食い違うことがない、ということです。各段階には担当が付きます。モデルか、名前のある人か、GembaOS 自身か。実行するのは GembaOS で、押印の後に記録を読み直してから行います。二つの版は比較でき、差分ごとに向きが付きます——人が減る（あるいは規程が単独で通せる範囲が広がる）、その逆、役割に見える範囲が変わる——ので、変更の稟議は向きが書かれた状態で回ります。

既存のシステムとエージェントはどう接続しますか？

GembaOS はモジュール化されたアダプターで既存システムを統制対象の機能として包み、何も書き直しません。既存の AI アシスタントやエージェント基盤とは双方向の MCP で相互運用します。

オンラインモールの参考 Playbook では、同じ考え方を価格に当てはめています。値下げ幅で押印者が決まります。小幅な調整はそのまま通り（稟議書は記録に残ります）、2 割引までは店舗の責任者、それより大きい値引きは資金の責任者も押印します。価格を書き込む前に出品を読み直し、押印の後に自動価格改定ツールが価格を動かしていれば、稟議は差し戻されます。

• 提供方向: 既存システムを標準の MCP ツールとして包み、社内で使っている Claude Code、Copilot、Cursor から呼べるようにします。呼び出しのたびに四つのゲートを通ります。
• 組み込みエージェントは Playbook で宣言: 自社のエージェントを持たない場合、GembaOS の顧客対応エージェントはコードではなく Playbook で宣言します。受付が確認する記録、担当が読む記録、担当が提案してよい項目、提案値をその記録に照らす規則（一致する、超えない、記録が挙げる値のいずれか、別の提案項目に対して記録が示す値と一致する）を書きます。モデルに見せるツールはこの宣言から生成され、規則に合わない値はモデルに差し戻され、稟議書には載りません。実行は押印の後に基盤が行い、モデルはその経路にいません。参考 Playbook は返金と航空便の振替の二つで、振替では選んだ便の差額が押印者を決めます。担当エージェントはまず承認済みナレッジで規程を調べ、お客様が実際に書いた文面を読み、実行すべき・実行すべきでない・人が判断すべき、のいずれかの推奨を添えて提出します。返金できる範囲を超えた提案には範囲を伝えて出し直させます。推奨が自分の提案と食い違えば、人の押印がない区分は閉じます。
• 外部のコーディング支援（任意）: 自社ですでにコーディングエージェントを運用している場合、修正の草案をそれに書かせられます。接続は役割ではなく能力として行います。役割は押印できますが、能力は押印できません。見えるのは修正方針で宣言したファイルだけで、読み取りの経路はモデルと同じです（秘密情報のパスは従来どおり拒否されます）。コマンドの実行権も許可証も持ちません。出力は修正案のテキスト一つだけで、その後は他の変更と同じ検証・CI・稟議の経路を通ります。実行は企業自社のネットワーク内なので、ソースコードはテナントの外に出ません。これは外部システムの呼び出しであり、CRM を REST で呼ぶのと同じ位置づけです。その草案に至った内部の過程は再現の範囲に入りません。記録に残るのは入力と出力のハッシュだけで、これを有効にする Playbook はそのことを明記します。
• 受け入れ方向（BYOA）: LangGraph や Dify などで作った既存のエージェントは、ツールの接続先を GembaOS のゲートウェイに向けるだけで、編成コードを変えずに稟議と許可証の保護を得ます。

SOP が整う前に始められますか？

GembaOS の不足台帳は、完全な手順書がなくても安全に始めるための仕組みです。エージェントは未定義の手順や境界に出会うと、不足を報告するだけで越権しません。

1. エージェントが未定義の手順や境界に当たると、不足と提案草案を記録し、推測しません。
2. 台帳は同種の不足をまとめ、定期的に担当部門の責任者の机へ回します。
3. 責任者が審定台でパスキーを使って審査し、承認された手順は統制されたナレッジライブラリに入り、不足は閉じます。

こうして日々の運用の中で、エージェントが散在する暗黙知を構造化された規程資産に変えていきます。

会社の仕事の進め方を言葉で説明して、そこから規則を作れますか？

作れます。GembaOS の規則には三つの入口があります。事前に自分で設計する（設定ファイルを直接書く、または内蔵文書を外部のコーディング支援ツールに渡す）、コンソールで組織設計アシスタントに仕事の進め方を言葉で説明する、または会社が指定したブラウザアプリで仕事を一度やってみせる方法です。どの入口からもルール公開の下書きができ、同じ検査と別の人の承認を通ります。実演は観察記録であり、それだけでは会社の規則になりません。規則の責任者が文言を確認する必要があります。ブラウザ記録機能は試作段階で、クリックを再実行しません。

1. 空の状態から始まります。 新しい会社には GembaOS 自身の安全の下限と言語パックだけが入り、承認者・責任者・職務権限表はすべて空です。後になって「実は GembaOS が決めた値だった」と分かる既定値は置きません。導入チェックリストが、いまの設定から次にやることを導きます。
2. 変更のすべてに本人の言葉があります。 アシスタントは内蔵文書と現在の設定を読んでから下書きを作ります。変更するファイルごとに、管理者の発言をそのまま引用した根拠が必要で、GembaOS はその文が本当に管理者の発言にあるかを照合し、なければ下書きを作りません。施行日にも本人の言葉が要ります。
3. その場で検査されます。 下書きはすぐに組み上げられ、版の繰り上げ、以前より緩和される点、組織の変更（承認者、チーム、職務権限表、各担当が使える操作、誰がどのデータを見られるか）と影響範囲が一行ずつ示されます。
4. 承認するのは人です。 アシスタントは公開できず、自分のモデル設定や管理者の設定も変えられません。下書きは管理者が提出し、別の人が承認します。施行日を決めることもでき、承認は先に済ませ、当日に GembaOS が自動で公開します。
5. 少しずつ整えていけます。 不正対応チームを置く、サポート担当には支払いのデータを見せない、来月から自動で進める上限を上げる、といった後からの追加も、それぞれ新しい下書きになり、違いとその向きが同じように示されます。

あわせて、管理者の発言・アシスタントの回答（実際のモデルの記録、または意図的に不正な振る舞いをさせた回答）・満たすべき性質を組にした場面試験を用意しています。性質はモデルの説明文ではなく、GembaOS が下書きを実際に組み上げた結果から読み取り、オフラインで何度でも再実行できます。

実際に仕事をしている人が、書き起こす代わりにやってみせることはできますか？

できます。ただし、いまはブラウザで動く業務アプリケーションの仕事に限ります。規則を書く、言葉で説明する、に加えて、GembaOS には三つ目の入口があります。担当者がいつもどおりに仕事を一度やってみせ、それを責任者のいる規則に整える手伝いを GembaOS がする、というものです。仕事を観察して流れを起こすこと自体は珍しくありません。GembaOS が作ったのは、記録のあとの部分です。実演はそれだけでは規則にならず、その規則に責任を持つ人が確認して初めて規則になります。動いている会社に届くのも、ほかと同じ検査と別の人の承認を通るルール公開の下書きとしてだけです。記事「一度やってみせる」で、参照用の受注画面を使って順にたどれます。

1. 記録してよい範囲は、会社が宣言します。 担当者はコンソールで「この作業を教える」を選び、作業の名前を付け、会社が宣言したアプリケーションの一覧から記録するものを選びます（自分で足すことはできません）。会社は、値を一切記録しない項目を宣言することもできます。GembaOS は、一度だけ使えて二時間で失効する記録用コードを発行します。
2. 見るだけで、操作はできない記録ツールです。 ブラウザの拡張機能が、選ばれたアプリケーションの画面だけで、担当者が画面上で行ったことを記録します。開いた画面、ラベルとともに表示された内容、使った部品、入力した値です。パスワード欄と、画面がカード情報や一回限りの確認コードと示している欄の値は記録せず、Cookie、ブラウザに保存されたデータ、通信の中身、クリップボードにも触れません。クリック、入力、画面遷移をする機能は持っていません。選ばれたアプリケーションの外に出たとき、一時停止したときは、「記録していない」という空白の区間だけが残り、内容は残りません。送る前に担当者が一つずつ確認し、どれでも削除でき、送るか破棄するかを決めます。それまで、ブラウザの外には何も出ません。届いた記録は、GembaOS が記録ツールを信用せず、会社の宣言と改めて照合します。
3. 記録が示すのは「画面に表示されたこと」です。 「観察されたこと」としてハッシュ付きで保管し、システムが実際に何をしたかは主張しません。「送信済み」と表示された画面は、入金済みを意味しません。記録の中身は作業票のイベントチェーンの外に置き、チェーンには出どころ・時刻・件数・ハッシュだけを残します。送信後も、担当者は記録を取り下げられます。そこから作った版も消え、確認済みの規則は残ります。会社は保管日数を設定でき、既定では取り下げるまで保管します。
4. 「理解した業務の流れ」。 担当者のアシスタントが記録をデータとして読み、業務の手順（それぞれ記録された操作に根拠があります）、まだ分からないことを添えた規則の候補、最大三つの質問を出します。質問は、誤った支払いにつながるもの、人が決めるべきものの順です。GembaOS は、記録に根拠のないものを捨て、別のシステムへ書き込む手順はそのシステムがつながるまで人が行うものと明記し、画面の数字を自分で数えます。規則が「説明あり」になるのは、担当者自身の回答を引用したときだけです。「分かりません」「一度きりの例外です」も回答です。アシスタントが受け取るのは、会社のデータの上限と、モデルに認められたデータの範囲で許される内容だけです。モデルがつながっていなければ、画面ごとに手順を区切る代替処理がそのことを示し、手順と規則は担当者が自分で書きます。
5. 規則は実演した人のものではなく、責任者のものです。 確認されるまで規則は候補です。会社はアプリケーションごとに、その規則に責任を持つ役職（返金なら CS 責任者など）を指定でき、指定がなければ実演した人の直属の上司が確認します。自分の実演から作られた規則を、自分で確認することはできません。確認はその時の文言に対して有効で、一字でも直せば未確認に戻ります。責任者が確認を取り消すと、その規則に基づく公開の下書きは、承認も公開もできません。
6. 確認済みの規則から、ルール公開の下書きへ。 組織設計アシスタントは、一つの実演記録にある確認済みの規則を、確認時にまだ分からなかったこと・記録に残る未解決のことと合わせて受け取り、下書きの根拠として引用できます。承認する人には「責任者が実演記録で確認した規則」と、確認した人の名前と役職が示されます。アシスタントは、実演の各手順の行き先も示します。会社にある操作、押印、確認済みの規則、まだつながっていないシステム、あるいは人です。GembaOS は、合う行き先だけを受け入れます。システムを変更する手順は、承認経路を通る操作にしか置けないので、実演から生まれた書き込みが押印なしに動くことはありません。それ以外は、理由を添えて人の手に残ります。
7. 承認する人が見るもの。 公開の画面は、変更が動かす経路ごとに、前と後を並べて描きます。変更される業務の宣言済みの事例を、下書きのファイルで試行することもできます。本番のシステムに届かない環境で、モデルは台本どおりに答える代替、外部のシステムはテストデータで答えます。さらに、下書きを起案した人でも実演した人でもない二人目から、保留事例を受け取ります。候補の規則と現行の規則で並べて判定し、規則の条件が分ける場合（上限以下、ちょうど上限、上限超え、注意の印が付いたかどうか）のうち、事例が届いたもの・届いていないものを一覧にします。事例を出したあとでファイルが変われば、その事例はもう「見ていない事例」には数えません。承認は二人目の人が行い、公開は GembaOS が行います。
8. 一つの仕事を複数人で実演できます。 記録を開いた人が、ほかの人（最大十人）を指名します。各自が自分のコードで記録し、取り下げられるのは自分の記録だけです。アシスタントには「一人目、二人目」とだけ伝え、誰かは伝えません。記録の違いは、その人の癖かもしれないからです。この人たちは、規則の確認も、保留事例の提出もできません。

いまできないこと。実演で扱えるのはブラウザで動くアプリケーションで、記録ツールは試作段階のブラウザ拡張機能です。デスクトップアプリケーションはまだ記録できません。実演は担当者の経験であって、権限ではありません。一回の記録が会社の規則になることはなく、ある人がシステムで何をできたかが、別の人への許可になることもありません。操作を再生して自動でクリックする仕組みはなく、書き込みは、そのシステムが統制対象の操作としてつながるまで人が行います。実演から作った手順をエージェントに実行させることは、この範囲に含まれません。記録は会社自身のストレージに、ファイル権限を絞って保管されます。会社が自分で持つ鍵で、これらのファイルを暗号化して保管することもできます（設定したときだけ有効で、鍵はデータと一緒には置きません）。ほかのデータの保存時の暗号化は、会社のディスク暗号化に依存します。試行で確かめるのは GembaOS の判定であって、モデルの読み取りではありません。保留事例が覆うのは規則に書かれた条件で、通貨、返金済みの履歴、二重の送信は、宣言済みの事例で確かめます。すでにモデルの提供元へ送られた内容は、その提供元の保管条件に従います。

管理者は日々どう運用しますか？

四つのゲートは「この行為をしてよいか」に答えます。管理者はそれに加えて毎週、会社にどんなエージェントがあるか、何と繋がっているか、ルール変更で何が起きるか、リスクはどこにあるか、資格情報は何日使っているかに答えなければなりません。GembaOS はその問いごとにコンソール画面を用意しました。どれも一覧として保持するのではなく設定と記録から導出され、どの数字も上方に丸めません。記事管理者が見る六つの画面が、そのうち六つを画像とともにたどります。

社外の規則が変わったとき、社内のどこに響きますか？

法令、グループの方針、取引先の約款、価格表——社外で公表された文書が変わったとき、会社が答えるべきは「何が変わったか」ではなく、「どの業務に響くか、自社に適用されるか、誰が何を直すか」です。GembaOS はこれをいくつかの汎用の部品に分け、どの種類の社外文書も同じ道を通します。

• 監視する情報源: ナレッジの情報源にはフォルダも https のページも使え、どの情報源にも「監視」の印を付けられます。スキャンで文書の新規作成や書き換え、承認済み本文の変化が見つかると、GembaOS は社内の信号を出します。その信号の宣言が、どの業務を誰の名義で起票するか、同じ文書は一日一件までかを決めます。ページは本文だけを取り出し、ファイルと同じくまず下書きになり、審定の前に変更が効力を持つことはありません。
• GembaOS は自分の設定を読む: 読み取り専用の操作が三つあります。業務ごとの説明と各手順の担い手（AI を使わない業務も含む）、ある文書や操作集を参照している業務、承認済み本文と審定待ちの改訂の行単位の差分です。どれも GembaOS 自身の宣言から計算した表で、モデルは関わりません。
• 調査担当はその表に縛られる: AI が差分とすべての業務の説明を読み、影響を受ける業務を挙げます。GembaOS の参照表が下限で、その文書を参照する業務を漏らせば「相違」、存在しない業務を挙げても「相違」となり、相違があれば自動の区分はすべて閉じます。差分の行数や変わった章も同じように照合します。
• 名前のある決定を決定台帳へ: コンプライアンスの責任者が適用の有無を押印し（必要なら先に法務へ回付）、決定は汎用の決定台帳に記録されます。押印時に見た改訂のハッシュで固定し、書き込む前に GembaOS がもう一度読み直します。同じ決定の重複は拒否し、考えを改めるときは記録を直すのではなく新しい稟議を起こします。
• 影響する業務ごとに起票: 影響を受ける業務には、その業務の責任者に宛てたルール変更のタスクが一件ずつ届きます。タスクは人だけで進めることもできます。責任者が直し方を書き、コンプライアンスが押印し、情報システムが公開として反映して公開番号を報告し、GembaOS がその業務の説明を読み戻します。作業票には、情報源の文書、影響審査、決定台帳の記録、各タスクという連なりが並びます。

参照テナントの「法令・規程変更の影響審査」は、こうした手順書の一つです。独自のコードはなく、設定と四つの言語の文言だけでできています。グループの方針や価格表なら、別の手順書を書けば済みます。

統制はどの基準に対応しますか？

GembaOS は、国内外の主要なサイバーセキュリティ、AI、金融規制の基準が求める統制項目を、実装済みの仕組みに対応付けています。この対応は当社の自己評価であり、監査法人の監修は受けていません。2026 年 10 月 1 日時点で GembaOS は SOC 2、ISO 27001、ISO 42001 などの第三者認証を取得していません。当社が提供するのは設計と検証結果で、評価は貴社とその監査人が行います。

6 週間の試行導入はどう進みますか？

GembaOS は標準化した 6 週間の道筋で、組織の摩擦を最小にして業務価値を確かめます。これが先行導入パートナーのプログラムです。

用語は言語をまたいでどう対応しますか？

GembaOS のコンソール、ポリシー、文書はどの言語でも同じ核となる用語を使います。用語集が各語を一度だけ定義します。

関連: セキュリティと導入形態、用語集、よくあるご質問。