まず押さえたい構成方針

推奨するのは、ゲートウェイを信頼できるVPSに置いたまま、外部からの接続は既存の信頼できる業務バックエンドで受ける構成です。不信な開発環境には限定した呼び出し権限を、小程序には業務に必要な機能だけを提供します。

最初からロードバランサーや複雑なネットワーク基盤を追加する必要はありません。ただし、通信経路を増やしても遅延がまったく発生しないとは言えません。実環境で測定して判断します。

現状の実装で確認すべき点

• 起動処理は、特に指定しない場合、ローカルホストだけでなく全ネットワークインターフェースで待ち受けます。信頼できるVPS上では、ゲートウェイをループバックアドレスに明示的にバインドし、インターネットから直接到達できないようにするのが推奨です。main.go
• 現在の主ルーターには呼び出し元の認証がなく、モデル一覧、統計、複数のチャット用パスも登録されています。クライアント側にキーを入力させるだけでは、入口の保護になりません。internal/api/chat.go
• 既存の認証ミドルウェアはGin向けですが、起動処理は標準HTTPルーターを使っており、確認された主ルートではそのミドルウェアが呼び出されていません。旧認証用の環境変数を設定するだけで、現在の入口が保護されるとは限りません。middlewares/auth.go main.go
• 既存の受付制御設定はローカル試験向けで、クライアントごとの上限をゼロにする指定もあります。複数ユーザー向けの本番用レート制限として、そのまま扱うべきではありません。internal/chatadmission/config.go internal/chatadmission/config.go

1. 不信な開発環境には、ゲートウェイではなく限定APIを

推奨する接続経路は次のとおりです。

不信な開発用VPS → HTTPSの開発用入口（信頼できる業務バックエンド）→ 私設経路 → 信頼できるVPS上のゲートウェイ

ソースコード、ビルド処理、ゲートウェイ、上流サービスの認証情報は、信頼できる環境から出しません。不信なVPSには接続先と開発専用の資格情報だけを置きます。

開発用入口で既存クライアントが必要とするチャット形式を受け付ける場合も、許可するメソッド、パス、モデルを絞り、統計・管理機能や任意の転送機能は公開しません。開発環境ごとに、取り消し可能で有効期間の短い資格情報を発行し、モデルの許可リスト、リクエストサイズ、同時実行数、累積予算を設定します。正式運用の資格情報とは分離します。

認証と予算の確認は、信頼できるバックエンド側で行う必要があります。不信な環境の設定ファイルやプログラムに、制限を守らせる前提は置けません。

ホストの管理者が信頼できないなら、その環境内の資格情報・リクエスト・レスポンスは読まれたり改変されたりする可能性があると考えます。有効期間の短い資格情報も盗難そのものを防ぐわけではなく、漏えい後の被害を抑える対策です。コンテナ化、バイナリ配布、難読化も、ホスト管理者から秘密を守る保証にはなりません。

つまり目指すのは、不信なVPSに盗めない主キーを持たせることではありません。主キーを渡さず、開発用の権限を取り消せるようにし、使える範囲と損失の上限を絞ることです。特に機密性の高い開発情報は、信頼できる環境に残します。

現在のように認証のないゲートウェイへ、不信なVPSからSSHトンネルで直接つなぐ構成も避けます。トンネルの認証情報が盗まれれば、制限を迂回されるおそれがあるためです。トンネルを使う場合も、接続先は制限付きの開発用入口に限定し、ゲートウェイ本体やほかの内部サービスには到達させません。

2. 小程序には汎用ゲートウェイではなく業務機能を提供

小程序からの接続は、次の経路に分けます。

小程序 → 信頼できる業務バックエンド（ログイン・利用枠・Agent処理）→ 私設経路 → ゲートウェイ → 上流モデル

微信の小程序ログインでは、クライアントが一時的なログインコードを取得してサーバーへ送り、サーバー側でユーザー識別情報と照合したうえで独自のログイン状態を発行します。session_keyはクライアントへ渡さないよう、公式ドキュメントでも説明されています。9

小程序から送るのは、職務内容や応募要件、必要な範囲の経歴情報などに限ります。ゲートウェイの主キーは持たせず、ユーザーが任意のモデル、システムプロンプト、ツールを選べる汎用チャット窓口にもなりません。

既存バックエンドには「個人の強みを整理する」といった用途別の業務APIを設け、モデル候補、プロンプト、利用可能な検索機能、出力形式をサーバー側で固定します。リクエスト本文に書かれたユーザーIDを信用せず、認証済みのログイン状態から利用者を特定し、タスク、会話履歴、利用枠をユーザーごとに管理します。

公開試用を無料にする場合も、無制限にはしません。ユーザーごとの利用枠、タスクあたりのモデル呼び出し回数・ツール実行回数、入出力の上限、全体予算、緊急停止手段を用意します。複数段階のAgent処理では、各段階が同じタスク予算を消費する設計にします。キャンセル、タイムアウト、再試行も上限の対象にし、処理がループして呼び出しが膨らまないようにします。

バックエンドが複数のワーカープロセスで動く場合、利用枠の確保と精算は既存データベースのトランザクションで一元管理します。各プロセスが個別に予算を計算すると、全体上限を超えるおそれがあります。

小程序には既存のHTTPS業務ドメインを使えます。微信の通常のネットワーク通信では、利用するサーバードメインを事前に設定する必要があります。そのため、小程序向けにゲートウェイのドメインを別途公開する必要はありません。7

3. まずは既存のSSHトンネルを使い、遅延を測る

バックエンドとゲートウェイが同じ信頼できるホスト上にあるなら、まずはホスト内の接続を使います。別々のホストにある場合は、最初の段階では既存の常時接続SSHトンネルを再利用し、リクエストごとにトンネルを作り直さない構成にします。

SSHにはポート転送専用のアカウントを使い、転送先のポートを制限します。ゲートウェイはローカルアドレスで待ち受け、トンネルが切れた際に保護されていない公開経路へ切り替わらないようにします。認証を省略できるのは、制御された内部接続に限り、同じホスト上のほかのプロセスも信頼できる場合です。不信な環境からの接続には、独立した資格情報の検証が欠かせません。

既存トンネルが実測でボトルネックになった場合に限り、信頼できる2台の間でWireGuardを検討します。WireGuardはピアの鍵に基づく認証と暗号化を提供しますが、導入すれば必ず速くなるという意味ではありません。1216

新たな第三者の中継サービスやリバースプロキシを追加する必要はありません。バックエンドでは接続を再利用し、ストリーミング出力を適切に転送し、小程序の切断を処理中のタスクにも伝えます。

追加遅延の実測値は、ここに示された情報だけでは判断できません。バックエンドからゲートウェイまでの通信時間、最初の出力が返るまでの時間、タスク全体の所要時間を分けて計測し、中央値と高いパーセンタイルを比較します。中国本土からゲートウェイや上流サービスまでの実際の経路も、別途検証が必要です。

また、「高速モデル」という名前だけで選ぶのも避けます。現在の候補モデルのテストは、深いモード、高い推論レベル、詳細な出力という設定を維持したままで、実際の上流サービスの可用性や遅延を証明するものではありません。internal/upstream/studioglobal/registry_fast_models_test.go internal/upstream/studioglobal/registry_fast_models_test.go 亮点の最適化用には、既存の開発用プリセットを直接変更せず、軽量な業務向け設定を別に用意して実測します。

4. 小さく導入する手順と確認項目

1. ゲートウェイの待ち受け範囲を絞り、インターネットや不信な開発環境からバックエンドを迂回して直接アクセスできないことを確認する。
2. 信頼できるバックエンドに、権限と予算を分けた「開発用の限定呼び出し」と「小程序の業務用呼び出し」を設ける。
3. Agentの実行回数、利用枠の確保、キャンセル伝播、ストリーミング出力を実装し、全体予算にも上限を設ける。
4. 資格情報なし・取り消し済みの資格情報が拒否されること、開発用権限で管理機能にアクセスできないこと、上限到達で処理が止まること、ユーザー間で会話履歴が混ざらないことを確認する。複数段階の処理や再試行でもタスク予算を超えないことも検証する。
5. 少人数の試用で遅延を測定し、その結果を見てから通信方式やインスタンス構成の変更を判断する。

初期段階で扱わないことと、公開前に確認すること

この提案は設計上の助言であり、実装・デプロイ・テストを行った結果ではありません。負荷分散、サービスメッシュ、常設のAgent基盤も初期段階では対象外です。その代わり、単一インスタンスの障害や処理容量の上限は受け入れる必要があります。

上流サービスが一般向け試用を認めているか、個人の経歴情報が実際にどこへ送られるか、適用される要件は何かについては、ここにある情報だけでは判断できません。公開前に確認し、送信情報を必要最小限に絞り、履歴やログに履歴書の全文や認証情報を残さないようにします。

基本方針はシンプルです。ソースコードと主キーは信頼できる環境から出さず、開発環境には限定権限を、小程序には業務機能を提供する。 まず認証、予算、タスクの上限を整え、インフラの層を増やすのは必要性を確認してからにします。

まず押さえたい構成方針

推奨するのは、ゲートウェイを信頼できるVPSに置いたまま、外部からの接続は既存の信頼できる業務バックエンドで受ける構成です。不信な開発環境には限定した呼び出し権限を、小程序には業務に必要な機能だけを提供します。

最初からロードバランサーや複雑なネットワーク基盤を追加する必要はありません。ただし、通信経路を増やしても遅延がまったく発生しないとは言えません。実環境で測定して判断します。

現状の実装で確認すべき点

• 起動処理は、特に指定しない場合、ローカルホストだけでなく全ネットワークインターフェースで待ち受けます。信頼できるVPS上では、ゲートウェイをループバックアドレスに明示的にバインドし、インターネットから直接到達できないようにするのが推奨です。main.go
• 現在の主ルーターには呼び出し元の認証がなく、モデル一覧、統計、複数のチャット用パスも登録されています。クライアント側にキーを入力させるだけでは、入口の保護になりません。internal/api/chat.go
• 既存の認証ミドルウェアはGin向けですが、起動処理は標準HTTPルーターを使っており、確認された主ルートではそのミドルウェアが呼び出されていません。旧認証用の環境変数を設定するだけで、現在の入口が保護されるとは限りません。middlewares/auth.go main.go
• 既存の受付制御設定はローカル試験向けで、クライアントごとの上限をゼロにする指定もあります。複数ユーザー向けの本番用レート制限として、そのまま扱うべきではありません。internal/chatadmission/config.go internal/chatadmission/config.go

1. 不信な開発環境には、ゲートウェイではなく限定APIを

推奨する接続経路は次のとおりです。

不信な開発用VPS → HTTPSの開発用入口（信頼できる業務バックエンド）→ 私設経路 → 信頼できるVPS上のゲートウェイ

ソースコード、ビルド処理、ゲートウェイ、上流サービスの認証情報は、信頼できる環境から出しません。不信なVPSには接続先と開発専用の資格情報だけを置きます。

開発用入口で既存クライアントが必要とするチャット形式を受け付ける場合も、許可するメソッド、パス、モデルを絞り、統計・管理機能や任意の転送機能は公開しません。開発環境ごとに、取り消し可能で有効期間の短い資格情報を発行し、モデルの許可リスト、リクエストサイズ、同時実行数、累積予算を設定します。正式運用の資格情報とは分離します。

認証と予算の確認は、信頼できるバックエンド側で行う必要があります。不信な環境の設定ファイルやプログラムに、制限を守らせる前提は置けません。

ホストの管理者が信頼できないなら、その環境内の資格情報・リクエスト・レスポンスは読まれたり改変されたりする可能性があると考えます。有効期間の短い資格情報も盗難そのものを防ぐわけではなく、漏えい後の被害を抑える対策です。コンテナ化、バイナリ配布、難読化も、ホスト管理者から秘密を守る保証にはなりません。

つまり目指すのは、不信なVPSに盗めない主キーを持たせることではありません。主キーを渡さず、開発用の権限を取り消せるようにし、使える範囲と損失の上限を絞ることです。特に機密性の高い開発情報は、信頼できる環境に残します。

現在のように認証のないゲートウェイへ、不信なVPSからSSHトンネルで直接つなぐ構成も避けます。トンネルの認証情報が盗まれれば、制限を迂回されるおそれがあるためです。トンネルを使う場合も、接続先は制限付きの開発用入口に限定し、ゲートウェイ本体やほかの内部サービスには到達させません。

2. 小程序には汎用ゲートウェイではなく業務機能を提供

小程序からの接続は、次の経路に分けます。

小程序 → 信頼できる業務バックエンド（ログイン・利用枠・Agent処理）→ 私設経路 → ゲートウェイ → 上流モデル

微信の小程序ログインでは、クライアントが一時的なログインコードを取得してサーバーへ送り、サーバー側でユーザー識別情報と照合したうえで独自のログイン状態を発行します。session_keyはクライアントへ渡さないよう、公式ドキュメントでも説明されています。9

小程序から送るのは、職務内容や応募要件、必要な範囲の経歴情報などに限ります。ゲートウェイの主キーは持たせず、ユーザーが任意のモデル、システムプロンプト、ツールを選べる汎用チャット窓口にもなりません。

既存バックエンドには「個人の強みを整理する」といった用途別の業務APIを設け、モデル候補、プロンプト、利用可能な検索機能、出力形式をサーバー側で固定します。リクエスト本文に書かれたユーザーIDを信用せず、認証済みのログイン状態から利用者を特定し、タスク、会話履歴、利用枠をユーザーごとに管理します。

公開試用を無料にする場合も、無制限にはしません。ユーザーごとの利用枠、タスクあたりのモデル呼び出し回数・ツール実行回数、入出力の上限、全体予算、緊急停止手段を用意します。複数段階のAgent処理では、各段階が同じタスク予算を消費する設計にします。キャンセル、タイムアウト、再試行も上限の対象にし、処理がループして呼び出しが膨らまないようにします。

バックエンドが複数のワーカープロセスで動く場合、利用枠の確保と精算は既存データベースのトランザクションで一元管理します。各プロセスが個別に予算を計算すると、全体上限を超えるおそれがあります。

小程序には既存のHTTPS業務ドメインを使えます。微信の通常のネットワーク通信では、利用するサーバードメインを事前に設定する必要があります。そのため、小程序向けにゲートウェイのドメインを別途公開する必要はありません。7

3. まずは既存のSSHトンネルを使い、遅延を測る

バックエンドとゲートウェイが同じ信頼できるホスト上にあるなら、まずはホスト内の接続を使います。別々のホストにある場合は、最初の段階では既存の常時接続SSHトンネルを再利用し、リクエストごとにトンネルを作り直さない構成にします。

SSHにはポート転送専用のアカウントを使い、転送先のポートを制限します。ゲートウェイはローカルアドレスで待ち受け、トンネルが切れた際に保護されていない公開経路へ切り替わらないようにします。認証を省略できるのは、制御された内部接続に限り、同じホスト上のほかのプロセスも信頼できる場合です。不信な環境からの接続には、独立した資格情報の検証が欠かせません。

既存トンネルが実測でボトルネックになった場合に限り、信頼できる2台の間でWireGuardを検討します。WireGuardはピアの鍵に基づく認証と暗号化を提供しますが、導入すれば必ず速くなるという意味ではありません。1216

新たな第三者の中継サービスやリバースプロキシを追加する必要はありません。バックエンドでは接続を再利用し、ストリーミング出力を適切に転送し、小程序の切断を処理中のタスクにも伝えます。

追加遅延の実測値は、ここに示された情報だけでは判断できません。バックエンドからゲートウェイまでの通信時間、最初の出力が返るまでの時間、タスク全体の所要時間を分けて計測し、中央値と高いパーセンタイルを比較します。中国本土からゲートウェイや上流サービスまでの実際の経路も、別途検証が必要です。

また、「高速モデル」という名前だけで選ぶのも避けます。現在の候補モデルのテストは、深いモード、高い推論レベル、詳細な出力という設定を維持したままで、実際の上流サービスの可用性や遅延を証明するものではありません。internal/upstream/studioglobal/registry_fast_models_test.go internal/upstream/studioglobal/registry_fast_models_test.go 亮点の最適化用には、既存の開発用プリセットを直接変更せず、軽量な業務向け設定を別に用意して実測します。

4. 小さく導入する手順と確認項目

1. ゲートウェイの待ち受け範囲を絞り、インターネットや不信な開発環境からバックエンドを迂回して直接アクセスできないことを確認する。
2. 信頼できるバックエンドに、権限と予算を分けた「開発用の限定呼び出し」と「小程序の業務用呼び出し」を設ける。
3. Agentの実行回数、利用枠の確保、キャンセル伝播、ストリーミング出力を実装し、全体予算にも上限を設ける。
4. 資格情報なし・取り消し済みの資格情報が拒否されること、開発用権限で管理機能にアクセスできないこと、上限到達で処理が止まること、ユーザー間で会話履歴が混ざらないことを確認する。複数段階の処理や再試行でもタスク予算を超えないことも検証する。
5. 少人数の試用で遅延を測定し、その結果を見てから通信方式やインスタンス構成の変更を判断する。

初期段階で扱わないことと、公開前に確認すること

この提案は設計上の助言であり、実装・デプロイ・テストを行った結果ではありません。負荷分散、サービスメッシュ、常設のAgent基盤も初期段階では対象外です。その代わり、単一インスタンスの障害や処理容量の上限は受け入れる必要があります。

上流サービスが一般向け試用を認めているか、個人の経歴情報が実際にどこへ送られるか、適用される要件は何かについては、ここにある情報だけでは判断できません。公開前に確認し、送信情報を必要最小限に絞り、履歴やログに履歴書の全文や認証情報を残さないようにします。

基本方針はシンプルです。ソースコードと主キーは信頼できる環境から出さず、開発環境には限定権限を、小程序には業務機能を提供する。 まず認証、予算、タスクの上限を整え、インフラの層を増やすのは必要性を確認してからにします。