よくあるご質問

はい。不足台帳が、未定義の手順や曖昧な境界を記録します。エージェントは草案を作成できますが、業務規程として採用する前に、責任者が確認・承認します。

不足が記録されても、エージェントの権限は一切広がりません。人が承認するまで、どのエージェントもその草案を引用できず、不足に当たった作業票は台帳に書かれた責任者を待ちます。

いいえ。Gateway 方式で既存エージェントを接続できます。対応するツール呼び出しや MCP 接続を GembaOS 経由に変更します。具体的なインターフェースとアダプターの要件は、デモの場で確認します。

エージェントの制御ロジックはそのままです。変わるのは、重要なツール呼び出しが業務システムへ直接届かなくなること。呼び出しは業務機能ゲートウェイに届き、ポリシーで判定され、必要な場合は人の押印を待ちます。

低リスクの参照や規程の限度内にある操作は、自動で通過できます。高額返金や本番の特権操作など、社内規程で承認が必要な処理だけを責任者へ回します。

経路を決めるのはポリシーであり、エージェントではありません。決裁限度内の返金はエージェントの押印で通り、同じ返金でも限度を超えれば財務責任者への稟議書になります。どちらの経路も同じ形式で記録されます。

はい。オンプレミスまたは自社 VPC と、自社ホストモデルで構成できます。クラウドモデルや外部システムを利用する場合は別途データ経路が生じるため、必要に応じた項目のマスキングを含めて構成を検討します。

テナントごと、プレイブックごとに「どの区分のモデル提供者にどのデータを見せてよいか」の上限を設定できます。自社ホストモデルと SaaS モデルを、役割ではなくデータの機密度で使い分けられます。

当社アーキテクトが伴走します。設定期間は IT・情シスの窓口担当者、シャドーモードでは業務の承認責任者の参加を想定しています。工数は連携対象により異なるため、パイロットの範囲とともに合意します。

いいえ。GembaOS は統制の実行基盤であり、オーケストレーションの基盤ではありません。操作を許可してよいか、誰が承認すべきかを判定し、許可証のもとで一度だけ実行します。エージェントがどう考え、どう計画するかは、開発基盤側の役割です。

LangGraph や Dify、CRM ベンダー製のエージェントは、同じゲートウェイを通して GembaOS を呼びます。統制の経路は、どの基盤で作ったエージェントでも同じです。

実行は止まります。業務システムを呼ぶ直前に、ガバナンスカーネルが現実の状態を読み直し、押印した人が見た事実と照合します。照合対象の項目が動いていれば実行せず、許可証を無効にし、変化を記録したうえで作業票を判断に戻します。

引数そのものも同じ考え方で守ります。ワンタイム許可証は承認済み引数のハッシュ（argsHash）に紐づくため、異なる引数での呼び出しは一致せず実行されません。上限値は、その値を持つシステムから書き込み直前に読み直します。許可証には有効期限があり、時間が経ちすぎた承認は何も許可しません。

ありません。許可証は一回限りで、書き込みの冪等キーはエージェントではなくガバナンスカーネルが稟議書と作業票から生成します。再試行・再送・再起動が起きても、二件目の書き込みではなく同じ一件として着地します。

承認済みの操作が走っている間、対象の記録は他の承認済み操作に対して押さえられます。あわせて各アダプターが、同時変更にどう備えるか（版番号、条件付き書き込み、対象記録のロック）を宣言します。

外部の内容はデータとして扱い、権限の根拠にはしません。メール、チャット、ログ行、画像に埋め込まれた指示文が権限を与えることはありません。操作を許可する判断は、モデルの外側にあるポリシーが行うからです。

指示文の混入が疑われる内容は、作業票に不審な入力として印が付きます。印の付いた操作は、エージェントの提案にかかわらず人へ回ります。画像がモデルに渡るのは、プレイブックが許す場合だけです。

対応アダプターのあるモデルなら、自社ホストでもクラウドでも使えます。権限判定・許可証・監査記録はモデルの外側にあるため、規程を変えずにモデルを差し替えられます。シャドー再実行とゴールデンテストで、切り替え前に新モデルの挙動を確認できます。

自社管理のサーバー上で動く、専用データディレクトリを持つ単一の Linux バイナリです。コンソールは TLS または既存のリバースプロキシ配下で提供し、業務システムへはアダプター（REST、ファイル、SQL、相互 TLS 経由のワーカー）で接続します。稼働に外部サービスは必要ありません。

対象が異なります。データの出入りを守る製品は、どのデータをどの AI に渡してよいかを決めます。GembaOS は、AI エージェントが提案した操作を実行してよいか、誰が押印するかを決め、許可証のもとで一回だけ実行します。両者は併用できます。

GembaOS にも項目単位の閲覧規則と送出上限はありますが、残す記録は稟議書です。照合済みの事実、引数そのもの、押印、そして再生できる事象の連鎖です。

稟議を持つ人は、別の役割に回付する（先に法務が契約条項を確認する）、同等以上の権限を持つ役割へ移送する、上長に上申する、のいずれかができます。上長は部下が押印待ちの稟議を引き取れます。どの操作も理由が必要で記録に残り、必要な押印を減らすことはありません。

不在時は、社員名簿から取り込んだ組織図の上の代理規則（金額による振り分けなど）が働きます。退職時は、押印待ちの稟議が在席する直近の上長へ移るか割り当て待ちになり、持っていた代理は終了します。上長はチームの机で、担当者不在の稟議を含め、部下に掛かっている案件を確認できます。

playbook が許可すれば可能です。ただし種類で求めるだけです。診療記録、領収書、見積など、playbook が定める選択肢から選び、申請者には必要な書類と期限が届きます。エージェントの理由は案件の担当者が読みます。

依頼はそれぞれ期限と回数上限のある補正依頼として作業票に残ります。期限切れは記録され、案件が自動で閉じることはありません。解説記事「書類の督促をエージェントに任せるには」と保険金請求のシナリオをご覧ください。

はい。補正依頼、申請者の確認、各部署への照会は作業票の上で進み、稟議書は書類が揃ったときに一度だけ起票されます。経路上の各人は所見を付けて一度押印します。

稟議書に戻ってきた人には、前回閲覧以降の変化と残る決定ひとつが示されます。所見によって書類の追加や担当者への差し戻しとなった場合も、同じ稟議書が再提出されます。