AI-SYNC BRIDGE
System Architecture Overview
AIサイドパネルは、
どう動いているのか。
Chrome拡張機能がレガシー画面にサイドパネルを注入し、別プロセスのAI APIサーバーと
やり取りして応答を返すまでの流れを、細部を省いて大づかみに解説します。
AI-Sync Bridge ― Architecture Overview
01 ― 全体像
登場人物は4つ。ブラウザの中と外。
ブラウザの中では、レガシー画面とChrome拡張が注入したパネルが同じページに同居する。その外側に、無改造の既存システムと、別プロセスのAI APIサーバーが独立して立っている。
🖥 ① クライアント（ブラウザ）
レガシー画面
③現有システムがそのまま配信するHTML/JS。1行も改変しない。
🧩 ② Chrome拡張が注入したAIサイドパネル
同じページのDOMに追加されたUI。検索・チャット・入力支援を提供。
↓ 画面取得（HTTP・既存の通信そのまま）
↓ AI呼び出し（fetch・別オリジン）
🏢 ③ 現有システム（レガシー業務サーバー）
ERP／自動車ディーラーDMSなど既存Webシステム本体。DBもロジックも無改造。
🤖 ④ ai-api-server（AI APIサーバー）
別プロセスのFastAPIサービス。NL→SQL変換・要約・チャット等を担当し、AIプロバイダを呼び出す。
AI-Sync Bridge ― Architecture Overview
02 ― どうやって画面に入り込むか
1拡張が対象ページを見つけて、忍び込む。
Chrome拡張のmanifest.jsonには「どのURLに何を注入するか」が宣言されているだけ。サーバー側の変更は一切不要です。
対象ページを開くhost_permissions が許可した
オリジンのみ
→
content_scripts が自動注入document_idle のタイミング
→
shared/*.js + panel-*.js設定・DOM操作・各機能タブ
→
画面右下にAIボタン出現bootstrap.js が起動
AI-Sync Bridge ― Architecture Overview
03 ― サイドパネルの組み立て方
2パネルは自己登録、bootstrapが束ねる。
🧩 shared/config-base.js
どの業務システム(ERP／DMS)か、AI APIサーバーのURLはどこか、といった設定値を用意する。
📑 modules/panel-*.js
チャット・自然文検索・在庫・請求書など機能ごとに1ファイル。読み込まれると自分の描画関数を登録するだけの自己完結型。
🚀 modules/bootstrap.js
最後に実行される起点。共有のctxオブジェクト(API接続・DOMヘルパー等)を組み立て、登録済み全パネルをまとめてサイドバーとして起動する。
AI-Sync Bridge ― Architecture Overview
04 ― AIを呼び出す瞬間
3パネルの操作が、AI応答になって返ってくる。
検索・チャット・「AIで解釈する」ボタンなどの操作は、すべて同じ経路をたどります。
ユーザーがパネルを操作自然文検索/チャット/解釈ボタン
→
fetch で ai-api-server へ別オリジンのFastAPI
→
ルータ→サービス層NL→SQL変換・集計・要約
→
AIプロバイダを呼び出し差し替え可能な接続先
→
JSON応答をパネルに描画
AI-Sync Bridge ― Architecture Overview
05 ― AI APIサーバーとAIモデルの間
4プロバイダは差し替え可能。呼び出し側は違いを知らない。
AiProvider という抽象クラス1枚を挟むことで、chat_service・search_serviceなどの呼び出し側は「今どのAIモデルと話しているか」を意識せずに済みます。環境変数 AISB_AI_PROVIDER（mock/opencode/openai/gemini）ひとつで実体を切り替えます。
🧪 mock
APIキー未設定時や検証時のフォールバック。外部通信を一切行わず、決定論的な擬似応答・擬似埋め込みを返す。
☁️ openai / gemini
OpenAI Chat Completions(gpt-4o-mini)、Gemini generateContent(gemini-1.5-flash)をhttpxで直接呼び出すSaaS型API。
🖥 opencode（既定）
ローカル/自前運用のOpenCode CLIサーバー(既定 http://localhost:4096)。セッション方式でモデルを呼び分ける、標準の接続先。
AI-Sync Bridge ― Architecture Overview
06 ― OpenCodeサーバーとの実通信
1回の質問が、内部では3段階のHTTPになる。
既定プロバイダ opencode は単純な1本の/chatエンドポイントを持たない。使い捨てセッションを作って会話し、応答をparts配列から抽出する設計。
POST /session使い捨てセッションを作成
→
POST /session/{id}/messagemodel指定＋履歴を1本のpromptに
埋め込んで送信
→
parts[] からtext抽出type:"text" のpartを連結
→
info.error を確認HTTP200でも上流エラーは
ここに潜む
🛡 失敗しても画面は壊れない
タイムアウトやAPIエラーは例外を投げず、[opencode-error-fallback] ...のような文字列として返す設計。パネルは常にJSONで応答を受け取れる。
🖼 画像入力は別モデル指定
既定モデルは画像非対応なことが多いため、vision_model_idを別枠で持ち、画像はFilePart(data URL)として添付する。
AI-Sync Bridge ― Architecture Overview
07 ― 補足：拡張機能をインストールしなくても
同じパネルコードが、2つの経路で配信される。
panel-*.js 自体は環境に依存しないため、「どこに注入するか」だけを差し替えれば、拡張機能なしでも同じ機能を提供できます。
🧩 Chrome拡張機能
- ✓ブラウザの content_scripts が注入
- ✓利用者ごとにON/OFF可能
- ✓インストールが必要
🔌 サーバー埋め込み方式(aisb_embed)
- ✓サーバー側ミドルウェアがHTML応答の</body>直前にスクリプトを差し込む
- ✓拡張機能のインストール不要
- ✓管理画面から即座にON/OFF切替
AI-Sync Bridge ― Architecture Overview
08 ― ERP／DMS、2つの業務を1つのコードで
同じパネルが、業種ごとに語彙を切り替える。
パネルは ctx.INSTANCE(erp / dealer)を見て、表示ラベルやAI検索の例文を出し分けます。バックエンドは完全に別プロセス・別データベースとして分離されており、互いに影響しません。
ERPインスタンス
顧客・受注・仕入・売掛買掛など
製造業向けの語彙・データ
⇔
共通のパネルコード
ctx.INSTANCE で表示・例文を分岐
本体ロジックは1本化
⇔
DMSインスタンス
車両在庫・整備/車検・仕入先など
自動車販売向けの語彙・データ
AI-Sync Bridge ― Architecture Overview
Summary
3行でまとめると。
01無改造
レガシー側のコードは一切書き換えない。
02後付け注入
UIはChrome拡張、またはサーバー埋め込みの2経路で後から差し込む。
03AIは別プロセス
AI処理はai-api-serverに分離し、業務システム本体には触れない。
AI-Sync Bridge ― Architecture Overview