既存システム接続：アダプター、接続の要件、GembaOS の置き場所

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。オーケストレーションのフレームワークでもモデル通信のゲートウェイでもないため、多くの構成では既存のものを置き換えるのではなく、その隣に足す形になります。

システムのつなぎ方

既存システムは、アダプターによって統制下の操作の集まりとして包まれます。システム側は何も書き直さず、モデルが認証情報を持つこともありません。モデルにできるのは操作の提案だけで、実行するのはポリシー判定と、業務手順書が求める場合は人の押印を経た後の GembaOS です。

操作を呼び出せるのは、業務手順書がその操作を許可している場合だけです。どの手順書にも使われていない接続は台帳に載っていても、どのエージェントからも届きません。

本番接続の前に各接続が示すこと

コンソールの「接続」画面は、外部システムごとにリンク材料を示します。必要な変数の名前とそれぞれの設定有無で、値は表示しません。あわせて、記録から読んだ稼働状態、手順書が許した範囲、取引先の契約監視、資格情報の指紋とローテーション日を表示します。

各接続には本番接続チェックリストが付きます。各項目は設定と記録が判定し、手で印を付ける項目はありません。

• 変数が揃っている
• モックではなく実システムが応答している
• 取引先の契約を監視している
• 統制下の呼出しが記録上にある
• 業務手順書がその操作を許可している
• 書き込む手順書すべてに責任者がいる
• 書き込み操作票に未整備がない
• ローテーション方針がある
• データの行き先が宣言されている

手順書が許可する本番の書き込み一件ごとに、設定から読み出した操作票が六つの問いに答えます。

1. 誰が呼ぶか：ロール、責任者、実行者、誰の認証情報か。
2. 何を読めるか。
3. いつ人が押印するか：判定、各帯の押印、必ず人が判断する信号、決裁権限表が求める人数。
4. 承認済みの引数をどう縛るか：一回限りの許可証、書き込み前に何を読み直すか、範囲、冪等キーを誰が埋めるか。
5. 失敗の種類ごとに何が起きるか。
6. 対象システム自体が何を保証するか：版または条件付き書き込み、読み戻し、重複の印。

設定が空白のまま答える問いは「未整備」として示し、対象システム側の限界は「注記」として示します。備わっていない機能を備わっていると書くことはありません。

接続の準備としてご用意いただくもの

試行導入では、第 3〜4 週に対象システムを 2〜3 件接続します。システムごとに次のものが揃っていると、上の操作票を埋めやすくなります。

• 対象システムの検証環境またはサンドボックスのアカウント
• インターフェースの記述：OpenAPI 仕様、電文レイアウト、ファイルレイアウトのいずれか
• 操作に必要な最小限の権限だけを持つサービスアカウント（貴社の環境内で保管）
• 読むだけの操作と書き込む操作の区別、書き込みごとの責任者
• 条件付き書き込み、書き込み後の読み戻し、重複の印に対応しているか。書き込み前に GembaOS が何を読み直すか、再試行が二重実行にならない仕組みを、この答えで決めます

既存の AI アシスタントとエージェント基盤

GembaOS は既存の AI アシスタントやエージェント基盤と、双方向の MCP で連携します。外向きには、既存システムが標準の MCP ツールになり、社内の Claude Code、Copilot、Cursor から呼び出せます。どの呼出しも同じ統制を通ります。内向きには、LangGraph や Dify などで作ったエージェントがツールの接続先を GembaOS のゲートウェイに向けるだけで、オーケストレーションのコードを変えずに稟議と許可証が加わります。以下の記事では、接続の境目がどこにあるかを、その基盤自身が使っている言葉で説明します。