エージェントのワークスペースを閉域網へ納品する：インストール後に確認すべきこと

コンテナが起動し、ログイン画面も開いた。ところが利用者の端末では添付ファイルを取得できず、エージェントのモデル呼び出しには外部接続が必要だった。再起動すると、保存したはずの設定も使えない。

閉域網への納品では、アプリの起動に加えて、データベース、オブジェクトストレージ、ライセンス、接続先のモデルやツールまで、それぞれの境界を確認する必要がある。受け入れ側が再確認できる証拠を残すと、納品後の運用責任も明確になる。

最初に、納品する範囲を決める

ワークスペースのセルフホストによって、共有レコード、文書、添付ファイル、レビューの仕組みをどこで動かすかを決められる。一方、接続したエージェントが使うモデルや外部ツールの配置は、別途設計と確認が必要になる。

まず、今回含めるコンポーネントと、隔離環境で利用する機能を一覧にする。外部依存ごとに、内部サービスへ置き換えるのか、許可された経路で接続するのか、機能を無効にするのかを決める。未決事項には確認担当者を置く。

ソブリンAIのラストワンマイルで扱う設計思想も、納品時には具体的な担当へ落とし込む。モデルの提供者、データベースの運用者、ブラウザーからの添付アクセスを確認する人、障害時に復元する人を定める。ワークスペースの導入後も、その責任は残る。

配置方式によって、持ち込むものが変わる

現行のオフラインインストール手順では、接続可能な環境でイメージを準備し、tarアーカイブとSHA-256チェックサムを作成する。転送先では整合性を確認してから、イメージを読み込む。

all-in-oneイメージにはPostgresとSeaweedFSが含まれる。Composeを選ぶ場合は、依存するイメージも用意するか、それらを取得できる内部レジストリが必要になる。アプリのイメージだけでは、完全隔離された環境の起動に必要なものが揃わない場合がある。

納品一覧には、承認済みのバージョンまたはダイジェスト、チェックサム、依存イメージ、配置設定、永続化先を記載する。実際のコマンドと対応バージョンは、最新の公式手順と採用リリースに合わせる。変化するlatestタグだけを、長期的な受け入れ基準にしない。

チェックサム一致は、転送したファイルの整合性を示す。起動結果は、その設定で動作したことを示す。両方を別の証拠として保存する。

画面と添付ファイルには、別の通信経路がある

ブラウザーからアプリへの要求と、添付ファイルへの要求は、異なる経路を通ることがある。サーバーからストレージへ接続できても、利用者の端末から返されたオブジェクトURLへアクセスできるとは限らない。

実際に使う閉域網内の端末でログインし、許可された確認用ファイルをアップロードする。その後ダウンロードし、内容を読めることまで確認する。ブラウザーがアクセスしたホスト名、プロトコル、ポート、証明書も確認対象にする。サーバー本体での試験だけでは、利用端末側の問題を見落としやすい。

設定リファレンスでは、APP_URLをブラウザーで実際に使うアドレスと一致させる。プロトコル、ホスト、ポートも含まれる。リバースプロキシでは元のホストとプロトコルを正しく転送する。アプリのアドレスやOriginの不一致はログインへ影響するため、オブジェクトストレージのアクセス先と分けて確認する。

「ログインできた」「アップロードできた」「取得したファイルを読めた」の三つを記録する。トップページの画面だけでは、添付経路の受け入れ確認にはならない。

オフラインのライセンス検証と、実行経路の隔離を分ける

インストール資料では、組み込まれた公開鍵を使ってライセンスをローカルで検証し、有効化のためのオンライン要求は不要と説明されている。実際のライセンスの範囲と有効期間は、ライセンス資料に照らして確認する。

これはワークスペースのライセンスに関する確認である。エージェントが使うモデルAPI、メールサービス、外部認証、第三者のツールには、それぞれ独自の接続要件がある。接続先を一覧化し、許可されたネットワーク境界と突き合わせる。

隔離中に利用できない機能は、想定どおりの制約として引き渡し資料へ書く。受け入れ側は、どの範囲で業務に使えるかを理解したうえで運用を始められる。

再起動と復元で、永続化を確認する

初回の書き込み成功は、その時点のインスタンスが書き込めたことを示す。受け入れ時には、再起動後もレコード、添付ファイル、設定、必要な認証情報を利用できるか確認する。

all-in-oneの設定資料では、生成された認証情報を/data/.credentialsへ保存し、バックアップするよう求めている。採用する配置方式に応じて、データベース、ストレージ、設定を含めた復元範囲を決める。

バックアップと復元の手順と組織の運用規定に従い、許可された別環境で復元を確認する。対象のレコードと添付ファイルを読めることまで確かめ、範囲と結果を残す。バックアップファイルがあることと、復元確認が済んだことは分けて記録する。

Busabaseの中で、知識の引き渡しを一巡させる

チームの説明はDoc、継続して更新する業務項目はBase、繰り返す手順はSkillに保存し、機密情報を除いた添付ファイルも一つ用意します。これは最小限の検収材料の提案です。文書、構造化レコード、再利用する手順、オブジェクトストレージをそれぞれ確認でき、特定の業界テンプレートを導入する必要はありません。

許可されたAgentに資料を読ませ、ChangeRequestで一件のレコード変更を提案させます。編集者が差分を確認して受け入れた後、正式レコードを再取得し、変更が現在の版に反映されたか確かめます。続いて受け入れ側の内網端末からDoc、レコード、Skill、添付を開き、再起動後にも同じ確認を行います。検収するのは、資料と変更履歴が納品したBusabaseインスタンスに残ることです。Agent、モデル、接続ツールのオフライン実行は、それぞれの構成で別途確認します。

双方が確認できる受け入れ表を作る

次は受け入れ項目の提案である。実際に実行してから、結果を記入する。

未達項目には担当者と再確認条件を決める。試験用資料は機密情報を除き、認証情報、ライセンスコード、ストレージの鍵を公開レポートへ載せない。

まず配置方式からコンポーネントと通信経路を列挙する。そのうえで、納品内容の一つひとつを再実行できる確認へ変える。何を納め、何を確認し、何を受け入れ側が運用するのかがわかる状態を目指す。