ホットリロード

PRX はほとんどの設定変更のホットリロードをサポートしています。config.toml（または config.d/ 内の任意のフラグメント）を編集すると、変更は数秒以内に検出・適用されます -- 再起動は不要です。

仕組み

PRX はライブ設定更新に 3 層のメカニズムを使用しています：

1. ファイルウォッチャー -- notify ファイルシステムウォッチャーが設定ディレクトリ（config.toml と config.d/ ツリー全体の両方）の書き込みイベントを監視します。

2. デバウンス -- イベントは 1 秒のウィンドウでデバウンスされ、連続する高速な書き込み（例: 書き込み後にリネームするエディター）を統合します。

3. アトミックスワップ -- 変更を検出すると、PRX は：

   • 新しい設定の SHA-256 フィンガープリントを計算
   • 前回の既知のフィンガープリントと比較（同一の場合はスキップ）
   • 新しい TOML を Config 構造体にパース
   • 成功時: ArcSwap を介して新しい設定をアトミックに公開（ロックフリー）
   • 失敗時: 前の設定を保持し、警告をログに記録

SharedConfig 型（Arc<ArcSwap<Config>>）は、設定を読み取るすべてのコンポーネントが、競合ゼロで一貫性のあるスナップショットを取得することを保証します。リーダーは .load_full() を呼び出して Arc<Config> スナップショットを取得し、使用中に設定がスワップされても有効性が保たれます。

ホットリロード可能な項目

以下の変更は即座に反映されます（約 1 秒以内）：

カテゴリ	例
プロバイダー設定	default_provider, default_model, default_temperature, api_key, api_url
チャネル設定	Telegram の allowed_users、Discord の mention_only、Slack の channel_id など
メモリ設定	backend, auto_save, embedding_provider、保持期間
ルーター設定	enabled、重み（alpha/beta/gamma/delta/epsilon）、Automix 閾値
セキュリティ設定	サンドボックスバックエンド、リソース制限、監査設定
自律性設定	スコープルール、自律性レベル
MCP 設定	サーバー定義、タイムアウト、ツール許可リスト
Web 検索設定	enabled, provider, max_results
ブラウザ設定	enabled, allowed_domains
Xin 設定	enabled, interval_minutes、タスク制限
コスト設定	daily_limit_usd, monthly_limit_usd、料金
信頼性設定	max_retries, fallback_providers
可観測性設定	backend、OTLP エンドポイント
プロキシ設定	プロキシ URL、no-proxy リスト、スコープ

再起動が必要な項目

少数の設定は起動時にバインドされ、ランタイムで変更できません：

設定	理由
[gateway] host	TCP リスナーは起動時に 1 回バインドされる
[gateway] port	TCP リスナーは起動時に 1 回バインドされる
[tunnel] 設定	トンネル接続は起動時に確立される
チャネルボットトークン	ボット接続（Telegram ロングポーリング、Discord ゲートウェイ、Slack ソケット）は 1 回初期化される

これらの設定では、PRX デーモンを再起動する必要があります：

# systemd サービスとして実行している場合
sudo systemctl restart openprx

# フォアグラウンドで実行している場合
# Ctrl+C で停止し、再度起動
prx

CLI リロードコマンド

ファイルを編集せずに設定の手動リロードをトリガーできます：

prx config reload

これはファイルウォッチャーが変更を検出するのと同等です。設定ファイルを再読み込み・再パースし、ライブ設定をアトミックにスワップします。以下の場合に便利です：

• ファイルを変更したがウォッチャーがイベントを見逃した場合（稀）
• 環境変数の更新後にリロードを強制したい場合
• 設定変更をスクリプト化している場合

エラーハンドリング

新しい設定ファイルにエラーが含まれている場合：

• TOML 構文エラー -- パーサーがファイルを拒否します。前の設定が保持されます。パースエラーの詳細を含む警告がログに記録されます。
• 無効なフィールド値 -- バリデーションが confidence_threshold > 1.0 や Automix 有効時の空の premium_model_id などの問題を検出します。前の設定が保持されます。
• ファイルの欠落 -- config.toml が削除された場合、ウォッチャーはエラーをログに記録しますが、メモリ内の設定は引き続き動作します。

すべてのエラーケースで、PRX は最後の正常な設定で動作を継続します。データの損失やサービスの中断は発生しません。

リロードの監視

HotReloadManager はリロード成功ごとにインクリメントされる単調な reload_version カウンターを保持しています。ゲートウェイのステータスエンドポイントで現在のバージョンを確認できます：

curl http://localhost:16830/api/status

レスポンスには現在のリロード回数が含まれ、変更が適用されたことを確認できます。

分割ファイルのリロード

分割設定ファイル（config.d/*.toml）を使用する場合、ウォッチャーは config.d/ ディレクトリ全体を再帰的に監視します。任意の .toml フラグメントへの変更は、すべての設定の完全な再マージとリロードをトリガーします。つまり：

• config.d/channels.toml を編集すると、設定全体がリロードされます（チャネルだけではない）
• フラグメントファイルの追加や削除はリロードをトリガーします
• マージ順序はファイル名のアルファベット順で、フラグメントが config.toml より優先されます