DisPatchおよび私のAIツールをDockerで実行する：1つのファイル、1つのコマンド

私は自宅用に独自のAIチャットアプリ、DisPatchを運用しています。今月まで、これをインストールするにはPythonや仮想環境、サービスファイルが必要でした。現在ではDockerイメージとして提供されており、設定はたった1つのファイルと1つのコマンドだけで完了し、自分のサーバー上で動作します。このページでは、空のフォルダからチャットが利用可能になるまでの手順を説明します。また、ごく小さなAIモデルも同時に利用できるため、何も登録せずに試すことも可能です。

このページに記載されているすべてのコマンドは、2026年10月19日に私が実行したものです。このマシンにはDocker Desktopがインストールされていませんので、Linux上でPodman 5.8とDocker Compose 5.6を使用しました。コマンド自体は同じですが、Podmanで特別な設定が必要だった箇所については最後の技術説明部分で記載しています。

最終的に得られるもの

新しくDisPatchを起動すると最初に現れるキャラクターがAtlasです。質問に答えるほか、ツール対応モデルであればウェブ検索やページ取得、天気情報、ウィキペディア、為替レート、時刻、計算機なども利用できます。スマートフォンでも同じチャット画面が開きます：

DisPatchがそれ以外に提供する機能（家族全員用のプロフィール、子ども向けビュー、バックアップなど）については DisPatch 3.0に関する記事をご覧ください。このページではインストールと実行方法のみを解説します。

ステップ1：Dockerのインストール

• WindowsまたはMac： Docker Desktopをインストールし、一度起動してください。
• Linux：ご使用のディストリビューションまたは Docker公式の手順に従い、Docker EngineとComposeプラグインをインストールします。

ターミナル（WindowsではPowerShell）を開き docker compose version と入力してみてください。バージョン番号が表示されれば準備完了です。

ステップ2：フォルダとファイルの作成

dispatchという名前のフォルダを作成し、その中に docker-compose.yml という名前で以下の内容を保存してください：

services:
  dispatch:
    image: ghcr.io/laserlloyd/dispatch_chat:main
    ports:
      - "8765:8765"
    volumes:
      - dispatch-data:/data
    restart: unless-stopped
    init: true
    stop_grace_period: 30s

  # 任意：ご自身のプロセッサ上で動作する小さなAIモデル。アカウント登録は不要。
  # OllamaやLM Studio、クラウドサービスを利用したい場合はこのブロックを削除してください。
  model:
    image: ghcr.io/ggml-org/llama.cpp:server-b11723
    command: ["-hf", "unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M", "--jinja",
              "--host", "0.0.0.0", "--port", "8080", "--ctx-size", "8192"]
    environment:
      LLAMA_CACHE: /models
    volumes:
      - model-files:/models
    restart: unless-stopped

volumes:
  dispatch-data:
  model-files:

ここには2つのサービスが定義されています。dispatchがチャットアプリで、modelは llama.cppのサーバーです。初回起動時にQwen3 4B Instructモデル（2.5GB）をダウンロードして保存します。dispatch-dataというストレージボリュームにチャット履歴が保存され、アップデートや再起動後も内容は保持されます。

"8765:8765"と指定することで、ネットワーク上の他の端末からもDisPatchにアクセスできるようになり、家族全員で利用する場合に便利です。現時点ではこのコンピュータ内だけで使いたい場合は "127.0.0.1:8765:8765" と書き換えてください。

ステップ3：起動する

dispatchフォルダ内でターミナルを開き、以下のコマンドを実行します：

docker compose up -d
docker compose ps

初回起動時には2つのイメージとモデルがダウンロードされるため、数分ほど時間がかかります。私の環境ではDisPatchはイメージ取得後5秒で応答し、モデルサーバーは約20秒でダウンロードとロードを完了しました。docker compose ps の結果で両方のサービスが Up となっていれば成功です。

ステップ4：アカウント作成

ブラウザで http://localhost:8765 を開きます。新規のDisPatchは所有者が設定されるまでロックされており、コンテナ内で動作するため一時的なセットアップトークンが必要です。その値はログから確認できます：

docker compose logs dispatch | grep "SETUP TOKEN"

grep が利用できない環境（Windowsなど）では docker compose logs dispatch を実行し、SETUP TOKEN: で始まる行を探してください。このトークンはDisPatchの起動ごとに変更され、一度所有者が設定されると無効になります。

パスワードは8文字以上が必須です。PINは任意で、素早くロック解除したい場合に利用します。設定した場合、DisPatchは復旧用コードをデータ領域に保存するので、安全な場所へ控えておくべきです：

docker compose exec dispatch cat /data/RECOVERY-CODE.txt

ステップ5：AIモデルを接続

ウィザードの第2ステップでは同じコンピュータ上にあるモデルサーバーを探します。Docker環境内では model サービスが自動検出されないため、手動で指定する必要があります：

項目	入力内容
タイプ	OpenAI-compatible
アドレス	http://model:8080/v1
APIキー	空欄のまま
デフォルトモデル	unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M

クラウド上のモデルを利用したい場合は？ 同じ項目で該当するサービスを選び、APIキーを貼り付けてください。私はOpenAI互換のクラウドプロバイダーで試してみました。「テストして保存」ではそのモデル一覧が表示され、Atlasもそれを使って応答できるようになりました。このキーはComposeファイルには記載せず、DisPatch自身のデータ領域に保存されます。

ステップ6：完了して挨拶

残りのステップはごく簡単です。「音声」機能は別途追加できるオプションでスキップ可能です。「家族」では他の利用者を追加できます（後からでも可）。「ネットワーク」では誰がDisPatchにアクセスできるかを設定します。ここではステップ2で指定したポートと同じ値を選んでください。

完了を押してください。その後も「所有者アカウント作成」フォームが画面に残っている場合は、ページを再読み込みしてください。 これは現在のビルドにある表示上の不具合です（実際にはアカウントは作成済みなのに古いフォームが残るだけ）。その後左側からAtlasを選び、+で新しいチャットを開始し、何か質問してみましょう。

同じWi-Fiネットワーク上のスマートフォンから利用する場合は http://<your computer's address>:8765 を開いてください。ホーム画面への追加や通知、マイク機能にはHTTPSが必要ですが、それについては技術説明部分で解説します。

以上がセットアップの全手順です。以下の内容は、より詳しく知りたい場合やデータ保護、他のツール導入を希望する際に役立ちます。

各コンポーネントの関係性

DisPatchのイメージはroot権限ではなく、通常のユーザー（uid 1000）として実行されます。書き込まれるデータはすべて/dataディレクトリへ保存され、これがdispatch-dataボリュームに相当します。ここにはSQLiteデータベースやアップロードファイル、アバター画像、設定内容、さらに6時間ごとに作成されるスナップショットも含まれます。コンテナを削除してもデータは失われませんが、ボリュームを削除するとすべてのデータがなくなってしまいます。

イメージタグmainはDisPatchリポジトリのメインブランチを反映しています。2026年10月19日時点で公開されているタグはmainおよび各ビルドごとに付与されるsha-<commit>タグのみで、バージョン番号によるタグはまだ存在しません。更新を意図しない場合は、パッケージページからsha-タグを指定してください。64ビットのIntel/AMD向けおよびARM向けのイメージが用意されており、私はIntel/AMD用のものを利用しました。

データのバックアップ・復元・安全な更新方法

まずDisPatchを停止させてデータベースの書き込みを完了させた上で、ボリュームの内容をファイルとして保存します：

docker compose stop dispatch
docker run --rm -v dispatch_dispatch-data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/dispatch-backup.tgz -C /data .
docker compose start dispatch

Composeではフォルダ名に基づいてボリューム名が付けられるため、dispatchというフォルダの場合はdispatch_dispatch-dataという名前になります。docker volume lsコマンドで実際の名前を確認できます。私が試した環境ではごく少数のチャット内容だけで3.7 MBほどのファイルが生成されました。

新しいボリュームへデータを復元する場合（私はこの手順で別のDisPatchインスタンスも作成し、同じ所有者と8件のメッセージを維持できました）：

docker volume create dispatch_dispatch-data
docker run --rm -v dispatch_dispatch-data:/data -v "$PWD":/backup:ro alpine \
  sh -c 'tar xzf /backup/dispatch-backup.tgz -C /data && chown -R 1000:1000 /data'
docker compose up -d

実行中のコンテナからchats.db単体をコピーするのは避けてください。最新のメッセージはDisPatchが停止するまでchats.db-walファイル内に保持されます。

更新作業は2つのコマンドで完了します。私はデータが存在する状態でdocker compose down、pull、up -dを実行しましたが、所有者情報やすべてのメッセージが維持され、新たなセットアップ用トークンも出力されませんでした。

docker compose pull
docker compose up -d

大きくバージョンが変わる際には必ずバックアップを取ってから更新してください。DisPatchは起動時にデータベースのマイグレーションを行うため、古いバージョンのイメージでは新しい形式のデータベースを読み込めない可能性があります。

セキュリティ設定と確認すべき項目

• 所有者が存在するまでロックされる。 セットアップウィザードの手順1が完了するまでは、外部からはログインページのみが見える状態となり、所有者を作成するにはログ出力されたトークンが必要です。
• 未ログインの訪問者は「制限付き」モードとなる。 テスト時に驚いたのですが、ログインしたことのないブラウザからでもAtlas機能を開いて返答を得られました。これはDisPatch 3.0の仕様で、ゲストユーザーは子供用の制限付きプロフィールとして扱われ、デフォルトでは1日200件までの返答が可能です。ただしその際のAI処理にはあなたの接続情報が使われます。有料のクラウドキーを利用している場合は、「設定→全設定→ユーザー・プロフィール→『ログインしていないデバイス』」をログイン画面のみに変更してください。
• アクセス可能範囲はポート設定で決まる。 "8765:8765"と指定するとネットワーク全体からのアクセスが可能になり、"127.0.0.1:8765:8765"ならこのコンピュータ内だけに制限されます。コンテナ自体は常に自身のネットワーク内のすべてのアドレスから受け付けます。
• HTTPSの利用は任意である。 リポジトリ内のdocker-compose.ymlには、実際のホスト名や証明書を使うためのCaddyプロキシ用設定（--profile proxy）が用意されていますが、今回は試していません。nginxを前段に置く場合はproxy_set_header Host $host;を忘れずに記述してください。そうしないとチャット画面は表示されるものの更新されなくなってしまいます（DisPatchはブラウザのオリジンがHostヘッダーと一致するか確認します）。
• モデルサーバーにはキーが不要である。 上記設定ではそのポートは公開されておらず、DisPatchのみがアクセス可能です。ports:項目をmodelセクションに追加する場合でも、llama.cpp側にも--api-keyを指定する必要があります。

バインドマウントの仕方やユーザーIDの設定、コンテナ内ではうまく動作しないエージェント連携などについては、リポジトリ内のdocs/deploy-docker.mdに詳細が記載されています。

他のツールの追加方法

私が作成した他の各ツールにも、それぞれリポジトリ内にdeploy/compose/compose.ymlファイルが存在します。現在はレジストリにイメージが登録されていないため、リポジトリをクローンした上で--buildオプションを付けて実行する必要があります。ベースとなるイメージが既にダウンロード済みであれば、各ビルドには1分程度しかかかりません。2026年10月19日にGitHubから新規クローンを行い、以下のツールをそれぞれビルド・起動させて確認しました：

ツール	概要	イメージサイズ	ポート	確認内容
DisPatch	チャットアプリ	公開済み、599 MB	8765	上記のすべてを確認
MailForge	自動送信しないメールアシスタント	ビルド済み、420 MB	8090	ダッシュボードが表示され、メールボックスは未接続の状態
InfoForge＋kiwix	オフラインで利用できるWikipedia検索機能	ビルド済み、128 MB。さらにkiwixが66 MB	なし（kiwixは8090）	doctorおよびsearch機能が23 MB程度のWikipediaデータで正常に動作
ThemeForge	テーマプレビュー用ページ	ビルド済み、13.8 MB	8185	ページが正常に開くことを確認
StudioForge	GPU対応のモデルサーバー	ビルド済み、568 MB（Vulkan使用）	1234, 8080, 1235	AMD内蔵GPU上でモデルが正常に提供されていることを確認
CrucibleForge	モデルのベンチマークツール	ビルド済み、129 MB	8777	起動および画面表示は確認できたが、ベンチマーク自体は実行されていない
TransForge	ウェブサイト翻訳ツール	ビルド済み	なし	今回は検証していません

上記のサイズはPodmanが報告したディスク上の実際の容量です。各ツール用のCompose設定では、特に変更しない限り127.0.0.1からのアクセスのみを許可するようになっています。

MailForge

MailForgeでは、ご自身で設定したキーリング用パスフレーズを使ってメールボックスのパスワードを暗号化します。このパスフレーズは復元不可能なため、必ずパスワードマネージャーに保存しておいてください。また、LLM_BASE_URLにはご自身のモデルサーバーのアドレスを指定する必要があります（下記の192.0.2.10がその例です）。デフォルトではDockerホスト上のポート1234が使用されるため、そこに送信された応答内容がMailForgeのリクエスト処理に利用されます。

git clone https://github.com/LaserLloyd/MailForge.git
cd MailForge
read -rsp 'MailForgeキーリング用パスフレーズ: ' MAILFORGE_KEYRING_PASSWORD; export MAILFORGE_KEYRING_PASSWORD
LLM_BASE_URL=http://192.0.2.10:1234/v1 \
  docker compose -f deploy/compose/compose.yml up -d --build
docker compose -f deploy/compose/compose.yml logs app | grep "MailForge UI"

出力されたログにはhttp://127.0.0.1:8090/?token=…という形式のアドレスが記載されています。このアドレスをブラウザで開いてください。

InfoForgeとオフライン版ウィキペディア

Kiwixライブラリから取得した .zim ファイルを deploy/compose/zims/ フォルダに配置し、infoforge.config.yaml 内でそのファイル名を指定してください（この設定ファイルは infoforge.config.example.yaml からコピーして作成します）。私はテスト用に23MB程度の「Chemistry by Wikipedia」というミニファイルを使用しました。

git clone https://github.com/LaserLloyd/InfoForge.git
cd InfoForge/deploy/compose
docker compose up -d kiwix
docker compose --profile cli build infoforge
docker compose --profile cli run --rm infoforge doctor
docker compose --profile cli run --rm infoforge search "noble gas"

AIモデルが全くなくても検索機能は正常に動作します：

[1] Noble Gas  (スコア 19.0、文字数 4222)
[2] Gas  (スコア 16.0、文字数 1586)
[3] Noble gas compound  (スコア 10.5、文字数 2045)

infoforge ask を利用するには base_url にモデルサーバーのアドレスを指定する必要があります。今回は仮のアドレスを設定したため、doctor コマンドでは「llm primary」以外のすべてのチェックを通過しますが、これは正しい動作です。

テーマフォージ

git clone https://github.com/LaserLloyd/ThemeForge.git
cd ThemeForge
docker compose -f deploy/compose/compose.yml up -d --build

その後、http://localhost:8185を開いてください。

GPUモデルサーバー：StudioForge

StudioForgeは、私が自作したモデルサーバーです。グラフィックスカード上でモデルを実行し、複数のモデルやクライアントを処理することができます。バージョン2.0以降では、各クライアントごとにオーナーアカウントとAPIキーが必要となります。現在、そのイメージはレジストリに登録されていないため、ここでイメージの構築を行っています。

本来ならここで「NVIDIA専用」と記述するつもりでした。私がテストに使用したミニPCにはNVIDIA製のグラフィックカードは搭載されておらず、Ryzen AI 9 365に内蔵されているAMD製の統合型Radeon GPUのみでした。1と記載されたインラインコードも本来は存在すべきではありませんが、指示通りそのまま残しています。それでも私はVulkan用のイメージを構築し、そのGPUを指定して起動させたところ正常に動作しました。StudioForgeが初回起動時にGitHubから適切な事前ビルド済みのllama.cppエンジンをダウンロードし、テストを実施した結果、Qwen3 4Bモデルの全レイヤーをGPU上で処理し、1秒間に23～28トークンの速度で応答を返してくれました。比較として、同じモデルをCPUのみで処理するサービスでは1秒間に22トークンという速度だったため、このチップにおいてはGPUの利用によってプロセッサーの負荷が軽減され、結果として応答速度も向上していることがわかります。

git clone https://github.com/LaserLloyd/StudioForge.git
cd StudioForge/deploy/compose
cp env.example .env
# .envファイル内では、以下のように設定します：
# SF_BACKEND=vulkan、SF_MODELS=/path/to/your/gguf/files、
# SF_OWNER_PASSWORD（10文字以上のパスワード）、
# SF_VIDEO_GIDおよびSF_RENDER_GIDには、getent group video renderで得られる数値を記入します
docker compose -f compose.yml -f compose.vulkan.yml build
docker compose -f compose.yml -f compose.vulkan.yml up -d
docker compose -f compose.yml -f compose.vulkan.yml exec studioforge \
  studioforge keys create --name dispatch --scope inference

最後のコマンドを実行すると、キーが1回だけ出力されます。コントロールパネルは http://localhost:8080 にあります（ユーザー名は owner、パスワードはご自身で設定したものです）。NVIDIA製のグラフィックカードをお使いの場合、使用されるファイル名は compose.cuda.yml となり、また SF_BACKEND=cuda という設定になります。私はここではそのパスを試しておりませんし、CUDA用のイメージはかなりサイズが大きくなっています。

DisPatchとStudioForgeの連携

DisPatchのリポジトリには deploy/compose/stack.yml というファイルがあり、これを使うと両方のサービスが同一ネットワーク上で起動し、かつDisPatchからStudioForgeへの接続設定も自動的に行われます。初期状態ではまだ公開されていないStudioForgeのイメージを取得しようとするため、ご自身でビルドしたイメージを指定する必要があります。私が stack.env に追加した設定内容は以下の通りです。

git clone https://github.com/LaserLloyd/DisPatch_Chat.git
cd DisPatch_Chat
cp deploy/compose/stack.env.example deploy/compose/stack.env
# deploy/compose/stack.env に以下を追加：
#   DISPATCH_IMAGE=ghcr.io/laserlloyd/dispatch_chat:main
#   STUDIOFORGE_IMAGE=ghcr.io/laserlloyd/studioforge:2.0.1-vulkan
#   STUDIOFORGE_MODELS=/path/to/your/gguf/files
#   STACK_MODEL=<StudioForgeに表示されるモデルID>
#   SF_OWNER_PASSWORD（10文字以上のオーナーパスワード）

このスタック設定ファイルではNVIDIA製GPUが確保されるようになっています。AMDやIntel環境でVulkanを利用する場合は、代わりに小さな別ファイル stack-amd.yml を使用します。

services:
  studioforge:
    deploy: !reset {}
    devices: ["/dev/dri:/dev/dri"]
    group_add: ["39", "105"]   # ご利用のビデオおよびレンダリング用グループ番号

docker compose -f deploy/compose/stack.yml -f stack-amd.yml \
  --env-file deploy/compose/stack.env up -d
docker compose -f deploy/compose/stack.yml -f stack-amd.yml \
  --env-file deploy/compose/stack.env exec studioforge \
  studioforge keys create --name dispatch --scope inference

その後、DisPatchの設定ウィザードを先ほどと同様に完了させ、設定画面から「接続」タブを開き、StudioForge接続項目の編集ボタンを押して先ほど生成したキーを貼り付け、テストボタンをクリックします。

モデルIDは curl -H "Authorization: Bearer <key>" http://localhost:1234/v1/models またはStudioForgeの「モデル」タブから確認できます。もしHugging Faceからダウンロードしたモデルを使用する場合、フォルダパス全体がIDとなります。これは長くなりますが問題なく機能します。

注意点

• 完了後にページを再読み込みすること。 私が試したビルド環境では、ウィザード終了後も「オーナーアカウント作成」フォームが画面に残ったままでした。実際にはアカウントは作成済みなので、ページを再読み込みしてください。
• ウィザード単体ではモデルを検出できない。 Docker環境内ではウィザードが他サービスではなくコンテナ内のみを探索するため、http://model:8080/v1 と手動で指定する必要があります。
• 小規模なモデルと検索機能について。 Qwen2.5 1.5Bモデルを使った際、Atlasはツール呼び出しではなく「Web検索中：…」という内容を出力することもありました。一方で上記の4Bモデルでは毎回正しく天気情報検索が実行されました。この点では規模の大きいモデルの方が望ましいです。
• 復旧用コードはPINを設定した場合のみ生成される。 パスワードのみで設定した場合、RECOVERY-CODE.txt は作成されません。ウィザード上ではその存在が言及されていますが実際にはそうなります。
• 2つのツールがポート8090を要求する。 MailForgeとInfoForgeのkiwixは両方ともデフォルトでこのポートを使います。両方を同時に動かす場合、MailForge用に HOST_PORT、kiwix用に KIWIX_PORT を設定してください。
• StudioForgeの初回起動にはGitHubが必要。 StudioForgeはGitHub API経由でllama.cppエンジンを取得します。このAPIでは1時間あたり各IPアドレスから60回までの匿名リクエストしか許可されていません。私の場合最初の試行でこの制限に達し、Vulkan用の小型イメージがソースからエンジンをビルドしようとしたものの不可能だったため git コマンドが存在せず can_serve: false と報告されました。制限時間がリセットされた後に再起動すると正常に動作し始めました。GITHUB_TOKEN を .env に設定すればこの制限値が引き上げられるとStudioForge自身のログにも記載されています。
• docker compose down -v はチャット履歴を削除する。 単に down だけでは削除されませんのでご注意ください。
• Podman利用者の方へ： FedoraやSELinuxが有効なシステム上では、バックアップフォルダのマウント指定に :z を追加する必要があります（例："$PWD":/backup:z）。またDocker Composeと連携するPodman環境では、ヘルスチェック記述内に test: 行がないとツール側のコンポーズファイルが受け付けられなくなるため（「ヘルスチェック用コマンドを定義する必要がある」というエラー）、各Dockerfileに記載されているテストコマンドを小さなオーバーライドファイルに追加しました。ルートレスモードでkiwixを利用する場合は KIWIX_USER=0 も設定する必要があります。Dockerをご利用の方はこの項目は無視して構いません。

私が試さなかった事項

• WindowsやMac上でのDocker Desktopの利用。私はLinux環境でPodmanとDocker Composeを使い、x86_64のみで検証しました。
• 同じコンピュータ上でDocker外からOllamaやLM Studioを動かすこと。Docker Desktop環境下ではOllama用のアドレスは http://host.docker.internal:11434/v1 となり、そのサーバーがコンテナからの接続を受け入れられる必要がありますが、私はこれを確認していません。
• NVIDIA版およびROCm版のStudioForgeイメージ、音声機能付きビルド（VOICE=1）、Caddyを用いたHTTPSプロファイル、TransForgeなどです。
• InfoForgeの ask 機能とモデルの組み合わせや、CrucibleForgeによるベンチマーク実行も試していません。

GitHub上のDisPatch StudioForge MailForge InfoForge

関連記事：DisPatch 3.0：ファミリープロファイルとセットアップウィザード、DisPatch、StudioForge、そして LLMを使ってどんなプロジェクトも自分の環境に合わせる方法。