よくあるご質問

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

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

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

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

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

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

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

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

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

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

LangGraph や Dify、CRM ベンダー製のエージェントは、同じゲートウェイを通して GembaOS を呼びます。自前のエージェントを持たない組織向けにエージェントループも同梱していますが、統制の経路はそれに依存しません。

実行は拒否されます。GembaOS はすべての一次性許可証を、承認済み引数のハッシュ（argsHash）に紐づけて発行します。異なる引数での呼び出しは許可証と一致せず、実行されず、不一致は作業票に記録されます。

許可証は一回限りで、有効期限もあります。承認済みの操作を実行すると許可証は消費され、同じ許可証での二度目の試みは同様に拒否されます。

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

指示文の混入が疑われる内容は、作業票に型付きの懸念として記録されます。ホストはそれをリスクの印に変え、印の付いた操作はエージェントの提案にかかわらず人へ回ります。画像は取り込み時に再エンコードされ、プレイブックとモデル設定の両方が許す場合にのみモデルへ渡ります。

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

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