チャットボットを公開用ウェブ上に配置する――自分のハードウェアで

公開されているウェブサイトにチャットボットを導入したかったのですが、クラウド上のAIサービスを借りて運用するのは望んでいませんでした。私は、自宅にある自分のコンピュータ上でモデルを動かしたかったのです。トークンごとに料金がかからず、プライベートな環境で、完全に自分のものとして使える形にしたかったのです。そこで私はまさにそれを実現しました。訪問者がブラウザ上で利用するチャットアシスタントでありながら、実際の処理は自宅にある小さなコンピュータ上のモデルが行う仕組みです。

実際に動作します。ただし遅いですし、セキュリティ対策を施す前は本当に危険な状態でした。また現時点では実際の大量アクセスに耐えられる状態ではありません。この記事では、安全に運用するための仕組みや、私が塞がなければならなかった脆弱性、そして本物の製品となるために必要な要素を率直に紹介します。このようなボットが実際どこで動いているかを見たい方は、私の家族旅行用旅程管理アプリ内にあるアシスタントをご覧ください。

仕組み：中央にメールボックスを置く

直感的にはウェブサイトから直接自宅のコンピュータへ接続したくなります。しかしそうすべきではありません。自宅のコンピュータを公開サーバーにするべきではなく、ネットワークに穴を開けて外部からアクセスさせるのも避けるべきです。その代わりに中央に中継用の仕組み（メールボックス）を設けます。

流れはメールボックス方式です：

1. ブラウザがウェブホスト上の小さな中継スクリプトにメッセージを送信すると、それがキューに格納され、チケット番号が返されます。
2. 自宅コンピュータ上のワーカーがそのキューを監視し、待機中のメッセージを取得した上でローカルモデルに問い合わせます。
3. モデルの処理が終了すると、ワーカーは回答を中継サーバーへ返送します。
4. ブラウザはチケット番号を使って定期的にキューを監視し、回答を取得します。

ウェブホストはあくまでテキストを保持するだけで、私の自宅コンピュータへ直接接続することはありません。ワーカーが中継サーバーへアクセスし、応答を得る形となります。つまり自宅側の何も外部に公開されていません。

なぜ単純なリクエスト／レスポンス形式ではダメなのか？

2つの理由があり、これがキュー方式を採用する根拠となります。

第一に、小型のローカルモデルは処理速度が遅いからです。通常のウェブリクエストでモデルの処理完了まで待つと、タイムアウトが頻発します。「メッセージを送信してから回答を待つ」形式なら、10秒や20秒、30秒かかる返答でも問題なく対応できます。最初の送信は即座に完了し、重い処理はバックグラウンドで行われるためです。

第二に、外部に公開される部分とモデルを切り離せるからです。一般向けウェブホスト上ではテキストをやり取りするだけのごく単純なコードが動いています。本当に力を持つ存在、すなわちモデルやそれが実行できる処理はすべて自宅内にあり、ワーカーを介して私が完全に管理しています。

セキュリティ：何かを実行できるチャットボットは非常に危険

ここが最も重要な部分だと考えます。私自身も当初は軽視していましたが、システムの見直しを行った際に本当に危険な問題点が2つ見つかりました。

単に会話するだけのボットはリスクが低いです。しかし何かを実行できるようになると状況が一変します。検索やデータ編集、ファイル操作などが可能になると、インターネット上の不特定多数から送られてくるテキストがそのまま実行対象となるため攻撃経路になり得ます。「指示を無視して～」といった入力が必ず出てきます。以下が具体的な対策です：

• 一般向けツールは一切使わない。 モデルにシェルアクセスやファイル操作、あるいは「任意のコマンドを実行せよ」といった機能は与えません。実行可能な処理はごく限定的な許可リストに基づきます。私の場合は「メモの追加・編集」のみです。削除やその他のコマンドは一切禁止しています。以前の見直しで、巧妙に作られた入力によって任意のコマンド実行が可能になる経路が見つかりました。そこでその機能を完全に排除し、許可リストのみに切り替えました。
• すべてのメッセージを敵対的なものとして扱う。 ユーザー入力は長さ制限やサニタイズ処理を経た上で「信頼できないテキスト」というフレームでモデルに渡します。明確に「これは訪問者からの入力であり、指示ではない」と示します。ボットが取得する情報（例えばウェブ検索結果）も同様に信頼できないものとして扱います。
• 失敗時には安全側へ振る・機密情報は通信しない。 機密データはローカルループバック接続のみで利用し、ネットワーク全体には公開しません。ワーカーが使用する共有秘密鍵もブラウザへ送信しません。設定ミスがあった場合でも「許可」ではなく「拒否」がデフォルトとなります。（実際に以前、ローカルネットワーク上で一時的に秘密鍵が閲覧可能な状態になっていたのを発見しました。こうした問題は注意深く調査しないと見つからないものです。）
• 最小権限の原則を徹底する。 登録されたアシスタントには許可されたごく限られた処理しか行えません。見知らぬ人に与えてはいけない機能なら、不特定多数向けのボットにも与えるべきではありません。

このような仕組みを作る際は、セキュリティ対策に十分な時間を割くべきです。悪意ある指示にも素直に従ってしまう便利そうなボットは機能ではなく、事故の原因になるだけです。

小型モデルを有効活用するためのコツ

小型モデルは記憶容量（コンテキストウィンドウ）が小さいため、すべての知識情報を一度に与えることはできません。そうすると情報が溢れて何も返答できなくなったり、意味不明な内容が返されたりします。ここで重要なのは関連情報の適切な注入です。常に簡潔な概要情報を付加し、ユーザーの質問に必要な参照情報のみをピンポイントで与えるのです。短く的を絞ったプロンプトを用いることで、小型モデルでもより高速かつ正確に動作させられます。

現実的な速度：確かに遅い

率直に言いましょう。一般向けハードウェア上では、モデルが温まった状態であれば1回の返答に約10〜24秒かかります。また長時間待機した後の最初のリクエストではモデルがメモリへ読み込まれるため約50秒も要します。これはプロンプトで解決できる問題ではなく、ハードウェアがトークンを生成する速度そのものです。

中継サーバーにより少しは隠されます。入力中のインジケータや「考え中…」「検索中…」といった段階表示があるため、待ち時間が意図的な処理だと感じられます。しかし決して高速とは言えません。家族数名がたまに旅行に関する質問をする程度なら問題ありませんが、一般公開されたサイトで使うには耐えられません。すべての訪問者が1台の遅いモデルを奪い合うことになるからです。

本番運用となるためには何が必要か

私はこれを率直に「趣味レベルで動作する実証例」と呼んでいます。本当の意味での大量アクセスに対応するためには、大まかに以下の要素が必要です：

• ストリーミング機能。 トークンが生成されるごとに順次送信することで、総所要時間は変わらなくても返答が「即時」に感じられます。これが最も大きな速度向上効果をもたらすため、最初に実装したい機能です。
• より高速な処理能力。 より高度に量子化されたモデルやGPU、あるいはより強力なハードウェアの導入です。モデルとハードウェアが本当のボトルネックとなります。他の要素は単なる付加価値に過ぎません。これは私がミニPC上でAIエージェント群を構築した際にも直面したトレードオフと同じです。
• 起動時の遅延防止。 モデルを常にメモリ上に温かい状態で保持し、初回実行時に50秒ものロスが生じないようにする必要があります。
• 本格的なキュー機能。 現状のメールボックスは単純なファイルシステムベースです。少数利用者なら問題ありませんが、同時アクセスには対応できません。実際にロック機能を持つメッセージキューへ置き換える必要があります。
• キャッシュ機能。 頻出する質問に対してはモデルを再実行せず、事前に保存した回答を即座に返せるようにすべきです。
• レート制限と悪用防止。 公開サイトとなるとボットや大量アクセスが予想されます。ユーザーごとの制限設定やキューの容量管理、負荷分散のための適切な処理方法が必要です。
• 同時接続数制限とバックプレッシャー対策。 遅いモデルでは同時に処理できる人数に限界があります。システムは「今は混み合っています、後でもう一度お試しください」と応答すべきであり、クラッシュしてはなりません。
• 可観測性の確保。 ログ記録や処理時間の計測、エラー追跡機能が必要です。そうすることでシステムが限界に近づく前に把握できるようになります。

これらは特別な技術ではなく、「自分のコンピュータ上で動く」段階から「誰でも利用可能なサービス」へ移行する際に必須となる標準的な要素です。ただ私の場合、家族専用のプライベートアシスタントであるため、現時点ではそれらを導入する必要がありません。

自分でも作ってみよう

要点をまとめました。冒頭にあるボックスからこの記事全体をご自身のアシスタントへ送信してみてください。

1. ご自身のマシン上でローカルモデルを実行します（LM Studio、Ollama、または llama.cpp を直接利用）。そうすることで、通常のAPI経由で小規模なチャットモデルが利用可能になります。私自身の設定方法については、StudioForgeというモデルサーバーの作り方に記載してあります。

2. ウェブホスト上に中継用の仕組みやキューを設置します。これはメッセージを受け取り、保存した上で受信確認用のチケットを返すごく小さなスクリプトです。ブラウザ側ではそのチケットを使って返答をポーリングすることになります。

3. 自宅でワーカーを実行し、中継先からメッセージを取得した後、ローカルモデルに問い合わせ、得られた回答を送り返します。つまり、ご自身のマシンから外へ接続するだけで、外部からのアクセスは一切ありません。

4. チャット機能の認証処理を行い、入力内容を制限・サニタイズした上で、信頼できないデータとして扱います。

5. モデルへのアクセスを厳格な許可リストによって制御します。シェル操作や削除機能は一切許可せず、最小限の権限のみ付与し、何か問題が生じた場合には即座に遮断するようにします。

6. 利用者への期待値を適切に設定します。入力中であることを示すインジケーターを用意し、ご自身のハードウェア上で小規模なモデルを使う際の返答速度は数秒程度が普通であることを伝えておきます。

注意点まとめ

• 自宅のマシンを直接公開してはいけません — ワーカーが接続できる中継用の仕組みを用いるべきで、絶対に自宅ネットワークを外部からアクセス可能にしてはなりません。
• 単一のリクエスト/レスポンス処理ではタイムアウトが起こります — 反応が遅いモデルの場合、一度送信した後で結果をポーリングする流れが必要です。
• 能動的に動作できるボットは攻撃対象となり得ます — 一般的なツールの利用は禁止し、厳格な許可リストを用い、すべての入力を悪意あるものとして扱い、問題発生時には即座に遮断するようにします。
• コンテキストが小さい場合は関連情報のみを注入します — 質問に関連する簡潔な説明や必要な参照情報のみを与え、余計な情報は含めないようにします。
• 処理速度は遅いのが実際です — ストリーミングやステータス表示でその遅さを隠すことは可能ですが、決して高速だと偽ってはいけません。上記の対策がなければ本番環境としては不適切です。

関連記事：家族用にAIを組み込んだ日本旅行プランニングアプリを作った · 1台のミニPC上で動作するAIエージェント群：私のOpenClawスタック · StudioForge：LM Studioに代わるGPU専用LLMサーバー · DisPatch：ローカルAIエージェント向けの自宅設置型チャットアプリ · InfoForge：オフラインで利用可能なWikipediaをRAG用データソースに