TeamWorks 様 ご依頼: ステージングサーバーへの D-Watch の設置

作成: 2026-10-07 / 作成者: DFA Robotics

いつもお世話になっております。 弊社で開発中の監視画面（D-Watch）を、貴社に構築・保守をお願いしているステージングサーバーに、Docker のコンテナとして設置していただきたく、ご依頼申し上げます。本書だけで作業いただけるよう、必要なものと注意点をまとめました。 選択肢（A / B / C …）のある設問は、記号だけでご回答いただければ結構です。設問とお願いの一覧は10章にございます。

1. 依頼の概要

目的は、弊社の関係者が社外からも実データで画面を確認できるようにすることです（本番の公開ではなく、検証のための一時的な運用です）。 425bd96 より後のコミットは文書の更新だけですので、develop の最新でも構いません。

2. 必要なもの

npm run seed:local は弊社の開発用です。実行しないでください。

3. Docker で動かすときの注意点

• ベースイメージ: Node.js 22.12 以上が必要です（Prisma 7 の要件）。node:24-slim（Debian 系）をおすすめします。alpine（musl）は、sharp 等のネイティブモジュールでつまずくことがあるため避けてください。
• npx prisma generate はイメージのビルドの中で実行してください。 生成物はリポジトリに含めておらず、npm ci でも作られないため、省くとビルドが失敗します。
• .env.local をイメージに入れないでください。 レイヤーに資格情報が残ります。環境変数は起動時に env_file / environment で渡してください。.dockerignore では .env*・node_modules・.next・data を除いてください。
• 環境変数はビルド時ではなく起動時に読まれます。 1つのイメージを、環境変数だけ変えて使えます（サンプルデータの設定でビルドしたものを USE_FIXTURES=false で起動し、ステージングDBのデータが出ることを弊社で確認済みです）。環境変数を変えたときは、コンテナの再起動だけで結構です。
• data/settings/ は永続ボリュームとして、ディレクトリごとマウントしてください。 ファイル1つずつのバインドマウントは使えません（保存のとき、一時ファイルに書いてから名前を変えて置き換えるため、失敗します）。コンテナを実行するユーザーが、そこに書き込めるようにしてください。画面から変更する運用設定（アドバイス文・表示件数・D-Sデバイスのメモ）を保存しており、作り直しても消えないようにする必要があります。
• ポートは 127.0.0.1:3000:3000 で公開してください。 3000:3000 にすると、Docker が公開したポートは ufw 等のファイアウォールを通らないため、3000 番がインターネットに開いてしまいます。
• nginx の前後に別のプロキシ（Traefik 等）を挟む場合は、お知らせください。 将来 IP 制限を入れるときの設定（プロキシの段数）に関わります。その場合も X-Forwarded-For は追記にしてください（6章）。
• npm run check:env（4章）は tsx（開発用の依存）を使います。 開発用の依存を省いたイメージでは動きませんので、ビルド段階のイメージ等、開発用の依存が残っているもので実行してください。
• ログは標準出力に1行1件の JSON で出します（docker logs で見られます）。ローテーション（max-size / max-file 等）を設定してください。
• ビルドにはメモリが 1〜2GB ほど要る見込みです（目安です。測定はしておりません）。
• コンテナのタイムゾーンは UTC のままで結構です（アプリの中で日本時間に換算しております）。

Q1. Dockerfile と compose ファイルは、どちらが用意しますか

いまのリポジトリには、Dockerfile・compose ファイル・.dockerignore はございません。

4. 環境変数

起動時にコンテナへ渡してください（3章）。値は本書には書いておりません。 合言葉は5章、DB の接続情報は貴社でお持ちのものをお使いください。

• DATABASE_URL のパスワードに % や @ が含まれる場合は、URL エンコードが必要です（@ は %40、% は %25）。@ を含む場合は DATABASE_USER / DATABASE_PASSWORD の併用をおすすめします（URL がうまく読めなかった例がございます。DATABASE_URL も検査のために設定してください）。
• 更新用アカウントについて: アプリが DB に書き込むのは、対応状況を記録する4カラム（status / comment / responded_at / resolved_at）だけです。更新用アカウントの権限（robot_error_reports と control_error_histories のこの4カラム）の範囲内で、現時点では robot_error_reports だけです。2つとも空なら参照用アカウントで書き込むため、その権限が無いと対応状況の保存だけが失敗します（閲覧には影響しません）。
• 設定したら、同じ環境変数で NODE_ENV=production npm run check:env を実行してください（3章の tsx の注意をご覧ください）。ERROR が1件も無く、USE_FIXTURES の WARN が出ないことをご確認ください（NODE_ENV=production を付けないと「開発機」として検査され、USE_FIXTURES を確認しません）。この検査は値を出力しませんので、結果をそのままお送りいただけます。

5. 合言葉（AUTH_TOKEN）

ログインに使う共有の合言葉です。開発用とは別の、32文字以上の乱数にしてください（総当たりで当たらない長さにするためです）。 URL と同じメールやチャットで送らないでください。 URL と合言葉が一緒に漏れると、誰でもログインできてしまうためです。

Q2. 合言葉は、どちらで作成しますか

6. 公開まわり

設定例（nginx。証明書の設定は省いております）:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Q3. 公開に使う URL（ドメイン）と証明書は、どのようにされますか

7. リポジトリの取得方法

Q4. アプリのコードは、どの方法で取得されますか

8. 動作確認のお願いとご連絡

1. ブラウザで公開URLを開き、ログイン画面が出ることを確認する。
2. 合言葉でログインし、ダッシュボードが表示されることを確認する。
3. 「施設ロボットマスタ」画面に、ステージングDBの施設（店舗と本社）が出ることを確認する。
4. 社外から http://（サーバーのアドレス）:3000 に直接つながらないことを確認する。

起動の目安は、ログの app.start の1行です。対応状況の保存（DB への書き込み）は実データが書き換わりますので、弊社で確認いたします。

作業が終わりましたら、公開URLと完了のご連絡（check:env の結果を添えて）をお願いいたします。エラーがあった場合は、その内容とログの抜粋をお送りください（ログに合言葉やパスワードは出ない作りですが、念のためご確認ください）。

9. ご承知おきいただきたいこと

• 今回は検証のための一時的な運用で、認証は共有の合言葉だけです。接続元の IP 制限も、ログインの試行回数の制限もまだございませんが、弊社で承知のうえでの判断です。
• リリース前に、接続元の制限（またはそれに代わる守り）と試行回数の制限を弊社で追加し、DB の接続元の制限や暗号化も貴社にご相談いたします。
• develop は開発に合わせて更新されますので、今後も何度か載せ替え（再設置）をお願いすることになります。

Q5. 載せ替え（再設置）は、どのようにご依頼すればよろしいでしょうか

10. ご回答のお願い

以上です。ご確認のほど、よろしくお願いいたします。