J2 環境一覧

1. 結論（30秒で）

J2 には 10 の環境がある。開発用（tokyo・osaka・rd）、確認用（staging・pre-prod）、本番、それに DAIKO 系統専用の staging と本番。
ホスト名は 3つの部品で読む：j2. はバイヤーポータル、bizhiway. はサプライヤー／プロバイダー／モール、api. は裏側の API。
ドメインが .com なら SSOL 系統、.jp なら DAIKO 系統（→ SSOL 系統と DAIKO 系統）。
顧客に見せる・顧客が触るのは staging と本番だけ。tokyo・osaka は開発チーム用。

2. 環境一覧

#	環境名	系統	用途	バイヤーポータル	サプライヤー／プロバイダー／モール	API	Git ブランチ	Jenkins
1	localhost	—	開発者の PC	`http://localhost:3101`	`http://localhost:3100`	`http://localhost`	作業ブランチ	—
2	rd	SSOL	R&D・試作（用途の詳細は未確認）	`j2.rd.jienie.com`	`bizhiway.rd.jienie.com`	`api.rd.jienie.com`	未確認（BRANCHING.md に記載なし）	未確認
3	tokyo	SSOL	開発（dev）。マージ後の最初の動作確認	`j2.tokyo.jienie.com`	`bizhiway.tokyo.jienie.com`	`api.tokyo.jienie.com`	`develop`	`tokyo/j2/`
4	osaka	SSOL	テスト（test）。QA が使う	`j2.osaka.jienie.com`	`bizhiway.osaka.jienie.com`	`api.osaka.jienie.com`	`osaka`	`osaka/j2/`
5	staging	SSOL	顧客受入・デモ・新人研修。最もよく使う環境	`j2.staging.jienie.com`	`bizhiway.staging.jienie.com`	`api.staging.jienie.com`	`staging-ssol`	`staging/j2/`
6	stg	SSOL	未確認（`.env.stg` が存在するが BRANCHING.md に記載なし。旧環境の可能性）	`j2.stg.jienie.com`	`bizhiway.stg.jienie.com`	`api.stg.jienie.com`	未確認	未確認
7	pre-prod	共通	本番前の最終確認。リリースごとに作り直す	`j2.pre-prod.jienie.com`	`bizhiway.pre-prod.jienie.com`	`api.pre-prod.jienie.com`	`release/YYYYMMDD`	`pre-prod/j2/`（BRANCH は毎回手入力）
8	production（SSOL 本番）	SSOL	SSOL 系統の顧客が実際に使う	`j2.jienie.cloud`（※）	`bizhiway.cloud`（※）	`api.jienie.cloud`（※）	`ssol`	`production/j2/`
9	daiko-staging	DAIKO	DAIKO 系統の顧客受入（D-ACT など）	`j2.staging.jienie.jp`	`bizhiway.staging.jienie.jp`	`api.staging.jienie.jp`	`staging-daiko`	`daiko-staging/j2/`
10	daiko-production	DAIKO	DAIKO 系統の本番（2026-07 時点で未構築、infrastructures/daiko.md）	`j2.jienie.jp`	`bizhiway.jienie.jp`	`api.jienie.jp`	`daiko`	`daiko-production/j2/`

※ SSOL 本番のホスト名は要確認。 バイヤーポータル側の .env.production は jienie.cloud / bizhiway.cloud、サプライヤー側の .env.production は api.jienie.com を指しており、食い違っている。実際に顧客が使っている URL を児嶋さんに確認する。

各環境にはモバイル用ホスト m.<環境>.jienie.com もある（VITE_MOBILE_URL）。

3. ホスト名の読み方

   j2   .  staging  .  jienie.com
  ─┬─      ───┬───      ────┬────
   │          │             └─ ドメイン：.com = SSOL 系統 ／ .jp = DAIKO 系統
   │          └─ 環境：rd / tokyo / osaka / staging / stg / pre-prod ／（本番は環境名なし）
   └─ 役割：j2 = バイヤーポータル ／ bizhiway = サプライヤー・プロバイダー・モール ／ api = API ／ m = モバイル

先頭	何が動いているか	ソースコード	主な画面（パス）
`j2.`	バイヤーポータル（依頼者・承認者・購買担当・経理・会社管理者）	`src-vbizhw`	`/eProcurement/Home`、`/eProcurement/Requester/…`、`/eProcurement/Purchaser/…`、`/eProcurement/Approver/…`、`/eProcurement/Settings/…`、`/eProcurement/CatalogMall/…`
`bizhiway.`	サプライヤーポータル・プロバイダー管理・カタログモール管理	`src-vbizhw-common`	`/eProcurement/Login`（サプライヤー）、`/supplier/manage/…`、`/supplier/registration`（新規サプライヤー登録）、`/management/…`（プロバイダーのサプライヤー管理）、`/MallMaster/…`、`/MallSupplier/…`、`/LogMessage/Dashboard`（ログ確認）
`api.`	API ゲートウェイ。人は開かない。外部カタログ連携の相手先が呼ぶ URL もここ	`src-jbizhw/service-gateway`	—
`m.`	モバイル画面	—	—

注意（出典の食い違い）： ソースコードの環境変数名は VITE_BHW_URL＝bizhiway.*、VITE_COMMON_URL＝j2.* で、名前だけ見ると逆に読める。実際の画面パス（バイヤーポータルのコードが bhwUrl + "/supplier/manage" へ遷移する等）と、ステージングで使われている URL の記録（ユーザーロール、外部カタログのベンダー別設定）から上表のとおりと判断した。

このほか demo.staging.jienie.com、demo.jienie.com、staging.jienie.com（先頭なし）、osaka.jienie.com、tokyo.jienie.com が D-ACT 資料などに登場する。デモ用会社グループ向けの別ホストと推定されるが 用途は未確認（discrepancy-log #2）。

4. 環境の流れ（コードがどう進むか）

flowchart LR
    F["作業ブランチ<br/>feature/NNNN（master から）<br/>bugfix/NNNN（本番ブランチから）"]
    F -->|マージ| T["tokyo（dev）<br/>develop"]
    F -->|マージ| O["osaka（test）<br/>osaka"]
    F -->|マージ| S1["staging（SSOL）<br/>staging-ssol"]
    S1 -->|ブランチごと| S2["daiko-staging<br/>staging-daiko"]
    F -->|マージ| R["pre-prod<br/>release/YYYYMMDD"]
    R -->|リリース時に master へ| M["master<br/>（どこにもデプロイしない）"]
    M -->|同じ時点| P1["SSOL 本番<br/>ssol：すぐデプロイ"]
    M -->|同じ時点| P2["DAIKO 本番<br/>daiko：DAIKO の予定日まで保留"]

覚えておくこと（詳細は開発リポジトリのブランチ運用ルール BRANCHING.md）：

環境は鎖ではない。 tokyo → osaka → staging → 本番と順に上がっていくのではなく、作業ブランチを 各環境に個別にマージする。
daiko-staging だけは例外。 作業ブランチではなく staging-ssol をまるごと取り込む。だから DAIKO 系統は SSOL 系統より少し遅れる。
本番は2つ同時に更新されるが、公開時期が違う。 SSOL はリリース当日、DAIKO は DAIKO 側の予定日。
環境ブランチを直接編集しない。 修正はすべて作業ブランチで行う。

5. 誰がどの環境を使うか

立場	主に使う環境	やること
開発者	localhost → tokyo → osaka	実装・単体確認・QA 依頼
QA	osaka、staging	テスト実行、リリース前確認
PM／BrSE	staging（SSOL・DAIKO）、pre-prod	顧客受入の準備、デモ、仕様確認、研修
営業・CS	staging	デモ、問い合わせの再現
顧客	staging（受入）、本番	受入テスト、実業務
外部カタログ連携の相手先	staging、本番の `api.`	連携テスト（→ infrastructures/）

6. インフラの全体像（非エンジニア向け）

要素	何か	覚えておくこと
クラウド	AWS	ファイルは S3 に保存
実行基盤	Kubernetes（namespace `j2`）	16 のサービスが動く。障害時は開発チームが対応
リージョン	東京 + 大阪	`system-architecture.md` は「大阪 = 災害対策（DR）」、`BRANCHING.md` は「osaka = テスト環境」と書いており、両立するのか要確認
データベース	PostgreSQL ×4（`j2_master`、`j2_buyer_group`、`j2_supplier`、`catalogmall`）	SSOL と DAIKO は別のデータベース。片方のデータはもう片方から見えない
顧客固有の変種	Lion 向けサービス（`service-buyer-order-lion` など）	SSOL 系統のみ。専用 DB `j2_buyer_group_jienie_lion`
ログ確認	`/LogMessage/Dashboard`（プロバイダー権限）	外部 API 連携のログは「API タブ → type: External API」

構成図：specification/00-overview/system-architecture、j2-system-graph.html

7. 未確認事項

#	項目	確認先
1	SSOL 本番の正しいホスト名（`.cloud` か `.com` か）	児嶋さん／開発リーダー
2	`rd`・`stg` 環境の現在の用途と稼働状況	開発リーダー
3	`demo.staging.jienie.com` 等、先頭が役割名でないホストの用途	開発リーダー
4	大阪リージョンの位置づけ（DR かテストか両方か）	開発リーダー
5	DAIKO 本番の構築状況（2026-07 時点で未構築）	児嶋さん