# DB接続経路についての申し送り（セキュリティ・4項目）

**作成: 2026-09-16 / 作成者: DFA Robotics**

---

> ## ★★本書の位置づけ（2026-09-16 更新）— ★本書は外部に送付しません★★★
>
> ★**送り方は「1通に統合する」に決まりました**★（ユーザー daichi 判断。2026-09-16）。
>
> | 項目 | 送付先 | 統合先 |
> |---|---|---|
> | ★項目1★（平文・接続元制限） | ★**TeamWorks 様へ送付**★ | ★`docs/handoff/TeamWorks確認事項_第9回_20260915.md` 12-2 / 12-3 / 12-4★ |
> | ★項目2★（コネクタの脆弱性） | ★★**外部に出しません**★★ | ★**DFA内製アプリの依存であり、解き方はDFA内部の判断**★。★ただし「TLS より先に経路を閉じるほうが効く」という**優先順の理由づけだけ**は、勧告ID・バージョン・依存関係を伏せたうえで統合版 12-3 に入れました★ |
> | ★項目3★（アカウント再発行） | ★**TeamWorks 様へ送付**★ | 同 ★12-5★ |
> | ★項目4★（本番構成の確認） | ★**TeamWorks 様へ送付**★ | 同 ★12-6（Q12-1〜Q12-6）★ |
>
> ★★したがって本書は、いまや★**内部記録**★です。★★
> ★**残る役割は次の2つです。**★
>
> 1. ★★**項目2 を DFA 内部で判断するための材料**★★（統合版には詳細を書いていないため、
>    ★勧告の内容・バージョン・依存関係の実測は本書にしか残っていません★ → §2）
> 2. ★統合版に載せた実測値・判断の★**根拠の控え**★（測定日・測定方法・出典 → §1-1、§3-1）
>
> ★**本文は当時のまま残してあります**★（削っておりません）。
> ★**ただし、外部向けの文面としては読まないでください。外部向けの正は統合版（第9回）です。**★
> ★**本書の §0-1 にある「宛先が未確定」という記述は、上記の決定により解決済みです**★（→ 付録 A-1 / A-2）。

## はじめに

★**本書はご依頼です。質問ではありません。**★

★**D-Watch のアプリケーション（DFA内製）を棚卸ししたところ、アプリのコードには
危険な箇所が1件も見つかりませんでした。**★
★**問題があるのはコードではなく、DBへ至る「経路」のほうです。**★
★**そして経路は、当方（DFA）のコードでは閉じられません。**★

そのため、★**当方で直せない4項目**★を本書にまとめ、正式にお渡しいたします。

本書の構成は次のとおりです。

| # | 内容 | 種別 | 宛先（★2026-09-16 に確定。§0-1★） |
|---|---|---|---|
| **0. 宛先と期限** | ★**期限は「ステージングに実データが入る前」です**★ | ★前提★ | — |
| **1. テストDBが公開IPに平文で開いています** | 実測つき | ★お願い★ | ★TeamWorks 様★（★統合版 12-2〜12-4 へ★） |
| **2. `mariadb` コネクタの既知の脆弱性（修正版を取り込めません）** | ★2026-09-16 に再実測★ | ★内部記録★ | ★★DFA内部の判断（外部には出しません）★★ |
| **3. 実在のDBユーザー名が Git 履歴に残っています** | 実測つき | ★お願い★ | ★TeamWorks 様（再発行）★（★統合版 12-5 へ★）＋DFA内部 |
| **4. 本番構成の確認（YES/NO でお答えいただけます）** | 質問 | 質問 | ★TeamWorks 様★（★統合版 12-6 へ★） |
| **5. DFA側でやったこと／やれないこと** | 前提の明示 | 参考 | — |

★**各節は【事実（実測）】【なぜ問題か】【誰が直せるか】【依頼したいこと】の4つで構成しています。**★
★**「事実」に書いたことは、すべて実測値か、実測記録の引用です。推測は「推測」と明示します。**★

> ★**本書に書いた値について**★
> ホスト名（`133.125.238.144`）とDBユーザー名（★2026-10-08 に資料から除いた。値は .env.local の DATABASE_USER★）は、★**すでに本リポジトリの
> 追跡済み文書に載っている値**★のため本書でも使用します（`docs/handoff/TeamWorks確認事項_第9回_20260915.md:58`
> / 同 `:748` ほか。★他4ファイル。§3-1 に一覧★★統合により行番号が移動しています（2026-09-16 実測）★）。
> ★**パスワードその他の認証情報は本書に一切書いていません**★（`CLAUDE.md` §9.3）。
> ★**実在の攻撃手順・再現コマンドも書いていません**★。

---

# 0. ★★宛先と期限★★

## 0-1. ★宛先は項目ごとに異なります（★2026-09-16 に確定しました★）★

★**本書を「誰に渡すか」は、項目ごとに違います。**★
★★**本節はもともと「一部が未確定」という状態で書かれていました。2026-09-16 のユーザー判断で
すべて確定しましたので、確定後の内容に書き直してあります。**★★

| # | 内容 | 宛先の候補 | 実測根拠 | 状態 |
|---|---|---|---|---|
| 1 | テストDBが公開IPに平文 | ★**TeamWorks 様**★ | ★★サーバーの契約・支払いは **DFA**、構築・保守は **TeamWorks 様**★★（ユーザー daichi 確認。2026-09-16）。★したがって実施を依頼する相手は TeamWorks 様★。参照用アカウントも TeamWorks 様からの受領（`docs/decisions.md` D-078 項1） | ★★確定★★（→ ★注1★） |
| 2 | `mariadb` コネクタの脆弱性 | ★**DFA内部の判断**★＋両者へ情報共有 | 依存関係は本リポジトリの `package.json:16`（`"@prisma/adapter-mariadb": "^7.10.0"`）。★DFA内製アプリの依存★ | ★確定★（ただし「どう解くか」はDFA判断＝★ユーザー判断待ち★） |
| 3 | DBユーザー名が Git 履歴に残存 | ★**TeamWorks 様（アカウント再発行）**★＋★DFA内部（再発防止）★ | 当該アカウントの発行元は TeamWorks 様（`docs/decisions.md` D-078 項1）。★発行元にしか再発行できません★。リポジトリは DFA 管理（実測 `gh repo view` → `DFARobotics/d-watch` / `PRIVATE`） | ★確定★ |
| 4 | 本番構成（VM＋DBアプライアンス）の確認 | ★**TeamWorks 様**★ | ★★本番のアプリサーバ（VM）も TeamWorks 様が用意される★★（ユーザー daichi 確認。2026-09-16）。DB側の構成を知っているのも TeamWorks 様（`docs/decisions.md:4703`） | ★宛先は確定★。★★ただし `docs/decisions.md` D-100 項5 との食い違いは**未解決**★★（→ ★注2★） |

### ★注1 — 項目1 の契約主体（★2026-09-16 に解決★）★

★★**テスト環境（`133.125.238.144:13306`）は、サーバーを契約し支払っているのが DFA、
構築・保守をしているのが TeamWorks 様です**★★（ユーザー daichi 確認。2026-09-16）。

- ★**実施（TLS 有効化・接続元IP制限・アカウント再発行）を依頼する相手は TeamWorks 様です**★
- ★★**「貴社にお渡しいただいたテスト環境」という従来の表現は事実と違うため、
  外部向けの文面では使いません**★★。★統合版（第9回 12-2）では「弊社が契約し、貴社に構築・保守を
  お願いしているサーバー」と書き直しました★

### ★★注2 — 項目4 には未解決の食い違いがあります（★内部向け★）★★

★ユーザー daichi は 2026-09-16 に「★**本番のアプリサーバ（VM）も TeamWorks が用意する**★」と
判断しました。★宛先はこれで確定です。★

★★ところが `docs/decisions.md` D-100 項5（`docs/decisions.md:4768`）は
「★DFA が構築するのはアプリ側（VM）なので、当方の作業には影響しない見込み★」と記録しています。★★

| 読み方 | 根拠 |
|---|---|
| ★A: TeamWorks 様が本番VMを用意する★ | ★ユーザー daichi の判断（2026-09-16）★ |
| ★B: DFA がアプリ側（VM）を構築する★ | ★`docs/decisions.md` D-100 項5（2026-09-10 の記録）★ |

★★**どちらが正しいかは未確定です。**★★
★**そのため統合版（第9回 12-6）では、これを断定せず「どちらが用意する想定か」自体を
1問（Q12-1）として立てました。**★
★★**「貴社が本番VMを用意される前提で」とは書いていません。**★★
★★A と B のどちらであっても、「VM と DB が同じ閉域に入れるか」は両者が突き合わせないと
決まりません。だからこそ YES / NO の確認という形を崩していません。★★

## 0-2. ★★期限 — ステージングに実データが入る前★★

★**これが期限です。日付ではなく、「イベント」で切ってあります。**★

### ★過ぎるとどうなるか★

| 時点 | 状態 | 作り直しのコスト |
|---|---|---|
| ★いま（テストデータのみ）★ | ★検証用のデータしか入っていません★ | ★★ほぼゼロ★★。アカウントを作り直しても、失うものがありません |
| ★ステージングに実データが入った後★ | ★★平文の経路を通った資格情報を前提に、運用が始まってしまいます★★ | ★★「作り直す」しか手がなくなります★★ |

★**具体的には、実データ投入後に同じことをやろうとすると、次が全部必要になります。**★

1. ★DBアカウントの再発行★ → ★接続している側（当方のアプリ、TeamWorks 様のデータ収集処理・
   集計バッチ）を★**全部止めて**★差し替える必要があります★
2. ★TLS の有効化★ → ★★サーバ再起動を伴う可能性があり、夜間の清掃データ収集を止められません★★
   （D-Watch は★夜間に自動実行された清掃を翌朝確認する運用★です。`CLAUDE.md` §1）
3. ★接続元IPの制限★ → ★実データが流れている状態で絞ると、漏れた接続元から
   データ収集が止まります★

★★つまり「止める調整」が発生します。いまなら、その調整が要りません。★★

★**だからこそ、実データが入る前にお願いしております。**★

## 0-3. ★★4項目はいずれも、DFA のアプリコードでは直せません★★

★**前提としてお伝えします。**★

★2026-09-13 に当方のアプリコードを棚卸ししました（`docs/handoff/指示書AE_セキュリティ強化と仕上げ.md:30-37`）。
結果は次のとおりで、★**危険な箇所は1件も見つかっていません**★★。

| 調べたこと | 実測結果（2026-09-13） |
|---|---|
| 生SQL（`$queryRaw` / `$executeRaw` / `*Unsafe` / `Prisma.raw`） | ★アプリコードに1件も無い★（Prisma 生成物の型宣言のみ） |
| `orderBy` のカラム名 | ★固定リテラル1箇所だけ★（`orderBy: { reported_at: "desc" }`）。`sort` / `order` というクエリパラメータは存在しない |
| `take` / `skip` にユーザー入力 | ★渡している箇所は無い★ |
| エラーレスポンスへの内部情報 | ★`err.message` / スタックトレース / 接続文字列 / テーブル名を本文に載せている箇所は0件★ |
| DBへの書き込み | ★アプリコードに1件も無い★ |
| リポジトリ内の認証情報 | ★実在の値は無い★（`pw` / `s3cret` / `example.com` 等のダミーのみ） |

★★したがって本書の4項目は「アプリを直せば済む話」ではありません。★★
★★DB本体・ネットワーク・資格情報の発行はいずれも DFA のアプリ開発の担当範囲外です★★
（`CLAUDE.md` §2 の責任分界）。

---

# 1. ★★テストDBが公開IPに平文（TLS無効）で開いています★★

## 1-1. 【事実（実測）】

★**いつ・誰が・どう測ったか**★を明記します。

| 項目 | 内容 |
|---|---|
| ★対象★ | ★テスト環境 `133.125.238.144:13306` / DB `clean_watch`★（`docs/handoff/TeamWorks確認事項_第9回_20260915.md:58`） |
| ★サーバのバージョン★ | ★`VERSION() = 10.11.19-MariaDB-ubu2204`★（同 `:58`。★実測★） |
| ★測った人★ | ★DFA（本プロジェクトの作業者）★ |
| ★測った日★ | ★**2026-09-13**★（`docs/handoff.md:3669`。★「監督実測 2026-09-13」と明記★）／ ★2026-09-15 に第9回確認書へ転記し、2026-09-16 に同書 12-2 へ統合★（`docs/handoff/TeamWorks確認事項_第9回_20260915.md:744-748`） |
| ★測り方★ | ★TeamWorks 様から受領した**参照用アカウント**（`GRANT SELECT ON clean_watch.*` のみ。`docs/decisions.md` D-078 項1）でテスト環境に接続し、★サーバ変数を照会した★ |

★**実測値**★:

| 変数／設定 | 実測値 | 意味 |
|---|---|---|
| `have_ssl` | ★**`DISABLED`**★ | ★サーバが TLS を提供していません★ |
| `require_secure_transport` | ★**`OFF`**★ | ★暗号化されていない接続を、サーバが受け付けます★ |
| 参照用アカウントの接続元ホスト | ★**`参照用アカウント@%`**★ | ★`%` は「どこからでも」。接続元の制限がありません★ |

★出典★: `docs/handoff.md:3669`（4項目すべて）/ `docs/handoff/TeamWorks確認事項_第9回_20260915.md:744-748`
（`have_ssl` と `参照用アカウント@%`）/ `docs/handoff/指示書AE_セキュリティ強化と仕上げ.md:52` `:817`

> ★★本書の作成にあたり、テストDBへの再接続は行っていません（意図的です）★★。
> ★参照専用のアカウントではありますが、接続条件が現在も揃っているかが不明なため★、
> ★★上記は「2026-09-13 に実測された値の引用」です★★。
> ★★もし現時点で既にご対応済みでしたら、本節は読み飛ばしてください。★★

## 1-2. 【なぜ問題か】

- ★★`have_ssl = DISABLED` と `require_secure_transport = OFF` が重なると、
  接続は必ず平文になります★★。★クライアント側で「TLSを使う」と書いても、
  サーバが提供していないため暗号化されません★
- ★★接続元が `%`（どこからでも）なので、経路は公開IP上にあります★★
- ★この2つが重なると、★**DB接続の資格情報が経路上で保護されていない状態**★になります★
- ★★現在は検証用データのみのため実害はありません。問題になるのは実データが入った後です★★
  （→ §0-2 の期限）

## 1-3. 【誰が直せるか】

| 対応 | 直せる人 | 根拠 |
|---|---|---|
| TLS の有効化 | ★DBサーバの管理者★ | ★DB本体の運用は TeamWorks 様の担当領域★（`CLAUDE.md` §2「MySQLデータベース本体（設計・構築・運用）＝TeamWorks」） |
| 接続元IPの制限 | ★DBサーバ／ネットワークの管理者★ | 同上。★★サーバーの契約・支払いは DFA だが、構築・保守は TeamWorks 様のため、実施は TeamWorks 様★★（→ §0-1 注1） |
| パスワードの再発行 | ★アカウントの発行元＝TeamWorks 様★ | `docs/decisions.md` D-078 項1（受領元） |

★★いずれも DFA のアプリコードでは実施できません。★★

## 1-4. 【依頼したいこと】

★**実データを入れる前に、次の3点をご検討ください。**★

1. ★**接続元の制限**★ — ★`参照用アカウント@%` の `%` を、★**固定IP**★（または閉域ネットワーク内のみ）に絞ってください★
2. ★**TLS の有効化**★ — ★`have_ssl` を有効にし、可能であれば `require_secure_transport = ON` にしてください★
3. ★**パスワードの再発行**★ — ★§3 の理由により、★**本番で使う資格情報は新規に発行してください**★★

★**ご負担や副作用のご懸念があれば、その旨をお知らせください。当方で別の手を検討します。**★

> ★★**この3点は、2026-09-16 に第9回確認書へ統合しました**★★
> ★第9回確認書の初版（2026-09-15）では、末尾に「参考: テスト環境について（申し送り）」として
> 情報共有のみで記載していました★。★★その章を削除し、正式なお願いとして12章に書き直してあります★★
> （`docs/handoff/TeamWorks確認事項_第9回_20260915.md:703-900`。
> ★接続元の制限＝12-3 / TLS＝12-4 / アカウント再発行＝12-5★）。
> ★★**重複は残していません。外部に出る文面はそちらが正です。**★★
> ★★なお、統合版では★**接続元の制限（12-3）を TLS（12-4）より先**★に置いています★★
> （★理由は §2-2。ただし勧告ID・バージョン・依存関係は外部向けには書いていません★）。
>
> ★★第9回確認書を送付したという記録が `docs/decisions.md` に残っていません★★
> （`docs/handoff/セッション引き継ぎ_20260916.md:70-79`）。
> ★★統合版は1通として送りますので、初版の送付状況の確定は引き続き DFA 内部の宿題です★★。

---

# 2. ★★`mariadb` コネクタの既知の脆弱性 — 修正版を取り込めません★★

## 2-1. 【事実（実測）】★2026-09-16 に再実測しました★

★**古い記録の転記ではありません。本書の作成時（2026-09-16）に `npm audit --json` を実行し直しました。**★

```bash
npm audit --json
```

### ★実測結果（2026-09-16）★

| 項目 | 値 |
|---|---|
| 全体 | ★**8 vulnerabilities（moderate 1 / high 7）**★ |
| 2026-09-13 の記録との比較 | ★★件数・内訳とも**変化なし**★★（`docs/deploy.md` 7-4 の記録と一致） |
| `mariadb` の `fixAvailable` | ★★**`false`（= No fix available）のまま。変化ありません**★★ |
| 走査した依存 | prod 174 / dev 438 / optional 118（合計 649） |

### ★`mariadb` に報告されている勧告3件（★すべて同一パッケージ★）★

| 勧告ID | 深刻度 | CVSS v3.1 | CWE | 内容 | 影響バージョン |
|---|---|---|---|---|---|
| ★`GHSA-cqhc-2h57-wpxf`★ | ★**high**★ | ★7.5★（`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`） | CWE-295 / CWE-522 | ★★`ssl: true` を指定しても、MitM に**平文パスワードが漏れる**★★ | ★`>=3.4.0 <3.4.6`★ |
| `GHSA-42r5-vhpq-m858` | moderate | 5.9（`AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N`） | CWE-319 / CWE-522 | 機密情報の平文送信／資格情報の保護不足 | `>=3.4.0 <3.4.6` |
| `GHSA-g5xc-5w98-jfvm` | moderate | 6.5（`AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N`） | CWE-89 / CWE-116 | ★big5 / gbk / sjis / cp932 / gb18030 のクライアント文字セット下での SQL インジェクション★ | `>=3.4.0 <3.4.6` |

> ★**CVE番号について**★: ★`npm audit --json` の出力に CVE 番号は含まれていませんでした★
> （勧告ごとに GHSA ID と URL のみ）。★**推測で CVE を補わないため、GHSA ID のまま記載しています**★。

### ★★`No fix available` の理由が分かりました（2026-09-13 の記録より一歩踏み込んだ実測）★★

| 実測 | 値 | 出典 |
|---|---|---|
| インストール済みの `mariadb` | ★**3.4.5**★（★脆弱★） | `node_modules/mariadb/package.json` |
| 上流で修正された版 | ★**3.4.6 以降**★（勧告の `range` が `<3.4.6`）。★**最新は `3.5.4`**★ | `npm view mariadb version`（2026-09-16 実測） |
| ★`@prisma/adapter-mariadb@7.10.0` の依存指定★ | ★★**`"mariadb": "3.4.5"`（キャレット無しの完全固定）**★★ | `node_modules/@prisma/adapter-mariadb/package.json` |

★★つまり「修正版は上流に存在するのに、アダプタが脆弱版をピン留めしているため取り込めない」★★
という状態です。

★**これは 2026-09-13 の記録（`docs/deploy.md` 7-4「上げても直りません」）の書き方より
正確な表現です。**★
★上げられないのは★**当方の都合ではなく、`@prisma/adapter-mariadb` の依存指定が原因**★です★。

### ★SQLインジェクション勧告（`GHSA-g5xc-5w98-jfvm`）は該当しません（★再確認済み★）★

```bash
grep -n "charset\|collation" .env.example .env.production.example lib/db/prisma.ts
# → ヒット0件（2026-09-16 実測。2026-09-13 と同じ）
```

- ★`DATABASE_URL` のひな型にクエリ文字列がありません★
- ★`lib/db/prisma.ts` にも `charset` / `collation` の指定がありません★（同ファイルに `ssl` の指定も0件）
- ★★したがって既定（utf8mb4）で動作し、勧告の条件（big5 等）に当たりません★★
- ★**本番の `DATABASE_URL` に `charset=` / `collation=` を足す場合は、この勧告を先に読んでください**★

> ★参考: 本節の実行では `npm audit fix` を一切かけていません（`--force` なしも含む）★。
> ★`package-lock.json` に差分が無いことを `git status` で確認済みです★。

## 2-2. 【なぜ問題か】

★★ここが本書で最も重要な点です。★★

★**`GHSA-cqhc-2h57-wpxf` は「`ssl: true` を指定しても平文パスワードが漏れる」という勧告です。**★

★**つまり、§1 の TLS を有効化していただいても、このコネクタを使っている限り
資格情報が保護されない可能性が残ります。**★

★そして修正版（3.4.6 以降）は、★**アダプタ側の依存指定が変わらない限り取り込めません**★★。

★★帰結: 「アプリ側で `ssl: true` を足す」では解決しません。★★
★★経路そのものを閉じる（固定IP／閉域ネットワーク）ほうを優先していただきたい、というのが
本項の依頼です。★★

★なお `lib/db/prisma.ts` には★**意図的に TLS の指定を入れていません**★★。
★上記の理由で、アプリ側の設定では解決にならないと判断したためです★
（`docs/handoff.md:3692-3694`）。

## 2-3. 【誰が直せるか】

| 対応 | 直せる人 | 備考 |
|---|---|---|
| ★経路を閉じる（固定IP／閉域）★ | ★TeamWorks 様／インフラ担当★ | ★★これが本命です★★（→ §1-4、§4） |
| アダプタの依存を上げる | ★上流（Prisma）★ | ★DFA では変えられません★ |
| ★アダプタを使わない構成に変える★ | ★DFA内部の判断★ | ★★影響が大きく、ユーザー（daichi）の判断が要ります★★（→ §2-4 の注） |
| `npm audit fix --force` | ★実行しません★ | ★`prisma@6.19.3` へのダウングレード（破壊的変更）が走ります★ |

## 2-4. 【依頼したいこと】

1. ★**TLS を有効にしても、このコネクタでは資格情報が保護されない可能性があることを前提に
   ご検討ください**★
2. ★★**経路そのものを閉じること（固定IP／内部ネットワーク）を優先していただきたい**★★

> ★★DFA内部の判断待ち（ユーザー daichi 宛）★★
> ★上流が `mariadb` のピン留めを上げるまで待つのか、それとも別のアダプタ構成を検討するのか★は、
> ★**DFA 側で決める話**★です。★本書では「経路を閉じる」依頼だけを外部に出し、
> 構成変更の是非は判断待ちとして残します★。

---

# 3. ★★実在のDBユーザー名が Git の履歴に残っています★★

## 3-1. 【事実（実測）】

### ★経緯（コミットを実測しました）★

| コミット | 日付 | 内容 |
|---|---|---|
| ★`a5502ac`★ | ★2026-09-09★ | `feat: 指示書M 段階2 ローカルDBへfixturesを投入するシードを作る`。★この中の `lib/db/__tests__/local-guard.test.ts` に、実在のDBユーザー名が2箇所含まれていました★（`:23` / `:53`） |
| ★`c832891`★ | ★2026-09-10★ | `fix: テストから実在のDBユーザー名を除去する`。★`testuser` に置換して除去済み（3行の置換）★ |

★実測コマンド★: `git show --stat c832891` / `git show --stat a5502ac` /
`git grep -n "<DATABASE_USER の値>" a5502ac -- lib/db/__tests__/local-guard.test.ts`

### ★★現在の状態★★

- ★★`a5502ac` は現在も参照でき、当該の値が読めます★★（上記 `git grep` で2件ヒット）
- ★**履歴は書き換えていません**★。★`c832891` のコミットメッセージに理由が明記されています★:
  > 「★履歴は書き換えない★。コミット a5502ac に残るが、パスワードは含まれておらず、
  > force push は禁止（CLAUDE.md §6-5）で並行セッションも動いているため。」
- ★★`a5502ac` に含まれていたのは**ユーザー名のみ**で、パスワードは架空の値（`pw` / `s3cret`）です★★
  （ホスト名も `example.com` のダミー）
- ★リポジトリの可視性★: ★**`DFARobotics/d-watch` / `PRIVATE`**★（実測 `gh repo view --json visibility`。2026-09-16）

### ★現時点で DBユーザー名を含む追跡済みファイル（2026-09-16 実測。★2026-10-08 に全件から除いた★）★

★実測コマンド★: `git grep -n "<DATABASE_USER の値>"`

| # | ファイル | 行 |
|---|---|---|
| 1 | `docs/handoff/TeamWorks確認事項_第9回_20260915.md` | ★`:748` / `:770` / `:805`★（★統合により3箇所に増えました。2026-09-16 実測★） |
| 2 | `docs/handoff/pdf/check_teamworks_qa9_pdf.py` | `:672` / `:736` |
| 3 | `docs/handoff/pdf/make_teamworks_qa9_pdf.py` | `:474` |
| 4 | `docs/handoff/セッション引き継ぎ_20260916.md` | `:87` |
| 5 | `docs/handoff/指示書AE_セキュリティ強化と仕上げ.md` | `:52` / `:817` |

★★合計5ファイル。いずれも `docs/` 配下の文書で、アプリのコード（`lib/` `app/` `components/` `prisma/`）には
1件もありません★★。★本書（`docs/handoff/セキュリティ申し送り_20260916.md`）を加えると6ファイルになります★。

> ★★注意: これは「4件」ではなく「5件」でした★★（本書作成時の実測）。
> ★`.py` 2件は第9回確認書のPDF生成／検査スクリプトです★。

### ★★2026-09-16 に同種の再発が1件あり、コミット前に止まっています★★

★`d792067`（`fix(db): 部品変数での接続を足し、実在のDBユーザー名をコードから外す`。2026-09-16）★の
コミットメッセージより:

> 「あわせて、作業中に置いていた user の既定値(実在のDBユーザー名)を外した。
> CLAUDE.md §9.3『認証情報を絶対にコミットしない』に反するうえ、同じ値は
> 2026-09-10 の c832891『テストから実在のDBユーザー名を除去する』でわざわざコードから消したもの。」

★★つまり「同じ値が、同じ理由で、2回コードに入りかけました」★★
（★1回目はコミットされ、2回目はコミット前に除去★）。
★これは「注意して運用する」では止まらない類の問題だ、という実測上の裏付けです★。

## 3-2. 【なぜ問題か】

- ★★Git の履歴は、除去のコミットを積んでも消えません★★。
  ★「いま `git grep` して出ない」＝「漏れていない」ではありません★（`docs/deploy.md` 7-3）
- ★リポジトリは PRIVATE ですが、★**アクセス権を持つ全員が履歴を読めます**★★
- ★★さらに、この参照用アカウントの認証情報は**平文でチャットに貼られています**★★
  （`docs/decisions.md` D-078「セキュリティ上の申し送り」）。★会話ログにも残っています★
- ★★ユーザー名が既知である以上、§1 の `参照用アカウント@%`（どこからでも接続可）と組み合わさると
  推測の手間が減ります★★

## 3-3. 【誰が直せるか】

| 対応 | 直せる人 | 可否 |
|---|---|---|
| ★Git 履歴の書き換え（force push）★ | — | ★★**禁止です。実施しません**★★（`CLAUDE.md` §6-5「PRはもう1人がレビューしてからmainにマージ」／`c832891` のコミットメッセージに理由あり。★並行セッションが動いているため★） |
| ★★アカウント／パスワードの再発行★★ | ★**発行元＝TeamWorks 様**★ | ★★これが現実的な解です★★ |
| 今後の混入防止 | DFA内部 | ★`d792067` で既定値を外し、未設定なら落ちるようにしました★ |

## 3-4. 【依頼したいこと】

★★**本番接続に使うアカウントは、履歴に入った値とは別のものを新規発行してください。**★★

- ★★**ユーザー名・パスワードとも**★★お願いします（★ユーザー名が既知のためです★）
- ★履歴の書き換えはお願いしていません★。★当方では実施できないため、
  ★**「発行し直す」ほうで解いていただきたい**★というお願いです★
- ★タイミングは §0-2 のとおり、★**ステージングに実データが入る前**★です★

---

# 4. ★★本番構成の確認 — YES / NO でお答えいただけます★★

## 4-1. 【事実（実測）】

★当方の理解と、その根拠は次のとおりです★。

| # | 当方の理解 | 根拠 | 確認の有無 |
|---|---|---|---|
| 1 | 本番のDBは ★MariaDB 10.11★ | ★TeamWorks 様のご回答（2026-09-10）★「本番サーバはMariaDBです」（`docs/decisions.md:4702-4705`） | ★★確認済み★★ |
| 2 | DBは ★さくらインターネットのデータベースアプライアンス★ | 同ご回答「さくらインターネットのデータベースアプライアンスはPostgreSQLかMariaDBなので」（`docs/decisions.md:4703`） | ★★確認済み★★ |
| 3 | アプリは ★さくらのクラウド VM★（Node.js 常駐が必要なため。レンタルサーバ不可） | ★DFA側の決定★（`docs/decisions.md` D-003 / `CLAUDE.md` §3） | ★DFA内部で決定★ |
| 4 | ★★「アプリ＝VM」「DB＝アプライアンス」という**別サービスの組み合わせ**である★★ | ★上記2・3からの**読み取り**★ | ★★**未確認**★★ |
| 5 | ★★VM と DB が**同一ネットワークで閉域接続**される★★ | ★`docs/decisions.md` D-003「さくらのクラウド上のVM 1台。DBと同一ネットワークで閉域接続」★ | ★★**未確認**★★（★DFA側の想定であり、裏取りしていません★） |

★★未確認なのは 4 と 5 です。★★

★`docs/decisions.md` D-100 項5 に、その旨が明記されています★:

> ★「つまり『アプリは VM、DB はアプライアンス』という構成と読める★が、★★明示の確認は
> 取れていない★★。★回答文はエンジン選定の理由として述べられただけで、構成を説明したものではない★」

★★すなわち、TeamWorks 様のご回答は「なぜ MariaDB なのか」の説明であり、
「本番の構成はこうなります」という説明ではありませんでした。当方が読み取っただけです。★★

## 4-2. 【なぜ問題か】

- ★★§1 と §2 の解き方（＝「経路を閉じる」）が成立するかどうかが、この構成にかかっています★★
- ★VM と DB が同一の閉域ネットワークに入れるなら★ → ★★§1・§2 は「初めから起きない」★★
- ★もし公開IP越しに接続する構成なら★ → ★★§1・§2 がそのまま本番に持ち越されます★★
- ★★当方は「閉じた構成になる見込み」と考えていますが、これは**推測**です★★。
  ★推測のまま本番に進むと、§0-2 の「作り直し」に直結します★

## 4-3. 【誰が直せるか】

★★これは「直す」ではなく「確認する」項目です★★。→ ★宛先は §0-1 のとおり両論併記です★。

## 4-4. 【依頼したいこと】★★以下の5問に YES / NO でお答えください★★

| # | 質問 | 回答欄 |
|---|---|---|
| ★Q1★ | ★本番のDBは、さくらインターネットの★**データベースアプライアンス**★（＝VM上に自前で構築した MariaDB ではない）で間違いないでしょうか | ★YES / NO★ |
| ★Q2★ | ★本番のアプリ（Node.js）は、★**さくらのクラウドの VM**★ に載せる想定で間違いないでしょうか | ★YES / NO★ |
| ★Q3★ | ★★その VM と DBアプライアンスは、**同一の閉域ネットワーク（プライベート接続）で結べます**でしょうか★★ | ★YES / NO★ |
| ★Q4★ | ★Q3 が YES の場合、★**DB側で公開IPからの接続を完全に閉じることは可能**★でしょうか | ★YES / NO / 条件つき★ |
| ★Q5★ | ★Q3 が NO の場合（公開IP越しの接続になる場合）、★**TLS を有効にできます**★でしょうか | ★YES / NO / 該当なし★ |

★**NO や「条件つき」の場合は、差し支えなければ理由を1行だけ添えていただけると助かります。**★
★**当方はそれを前提に、§1・§2 の依頼内容を組み直します。**★

---

# 5. ★DFA側でやったこと／やれないこと★

★**「丸投げではありません」という説明のために書いています。**★

| | 内容 | 出典 |
|---|---|---|
| ★やったこと★ | ★生SQL禁止の ESLint ルール化★ | D-122 / `docs/handoff.md` 追記42 |
| | ★パスパラメータ検証の全体一致化★ | D-123 |
| | ★`settings/advice` の PATCH に長さ上限★ | D-124 |
| | ★CSVの数式インジェクション対策★ | D-125 |
| | ★本番前セキュリティ確認チェックリスト（8項目）★ | `docs/deploy.md` 7節 |
| | ★セキュリティヘッダは nginx 側へ申し送り★ | D-126 / `docs/deploy.md` 4-4 |
| | ★`npm audit` を検証手順に組み込み、結果をそのまま記録★ | `docs/deploy.md` 7-4 |
| | ★DBユーザー名の既定値をコードから除去し、未設定なら落ちるようにした★ | `d792067`（2026-09-16） |
| ★★やれないこと★★ | ★★本書の4項目★★ | ★DB本体・ネットワーク・資格情報の発行は、いずれも DFA のアプリ開発の担当範囲外★（`CLAUDE.md` §2） |

---

## おわりに

★**本書の4項目は、いずれも「いまなら安く直る」ものです。**★
★**実データが入った後では、同じことに運用停止の調整が必要になります。**★

★**まずは §4 の Q1〜Q5（YES / NO）だけでも先にお答えいただけますと、
§1 と §2 の依頼内容を確定できます。**★

★**ご負担や副作用のご懸念があれば、その旨をお知らせください。当方で別の手を検討します。**★

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

---

## ★付録: DFA 内部で確定すること（★2026-09-16 更新★）★

★★この付録は社内向けです。★★
★**本書は送付しないことになりましたので（→ 冒頭「本書の位置づけ」）、本付録は「統合版（第9回）を送る前に確定すること」の一覧に読み替えてください。**★

| # | 確定すべきこと | なぜ | 状態 |
|---|---|---|---|
| A-1 | ★項目1 の宛先★ — テスト環境の契約主体 | ★★**解決しました**★★ — ★サーバーの契約・支払いは **DFA**、構築・保守は **TeamWorks 様**★（ユーザー daichi 確認。2026-09-16）。★実施の依頼先は TeamWorks 様★。★★「貴社にお渡しいただいたテスト環境」という表現は事実と違うため使わない★★（→ §0-1 注1） | ★★**解決済み**★★。★統合版 12-2 に反映済み★ |
| A-2 | ★項目4 の宛先★ | ★★**TeamWorks 様宛で送ります**★★（★本番のアプリサーバ（VM）も TeamWorks 様が用意される、というユーザー daichi の判断。2026-09-16★） | ★宛先は確定★。★★ただし `docs/decisions.md` D-100 項5（「DFA が構築するのはアプリ側（VM）」）との食い違いは**未解決**★★（→ §0-1 注2）。★そのため統合版 12-6 では断定を避け、Q12-1 で「どちらが用意するか」自体を1問として立てた★ |
| A-3 | ★項目2 の解き方★ — 上流のピン留め解消を待つか、アダプタ構成を見直すか | ★影響が大きい。外部に出す話ではなく DFA の設計判断★（§2-4 の注）。★★**外部には出さないことが確定したため、判断の材料は本書 §2 にしか残っていません**★★ | ★★ユーザー（daichi）判断待ち★★ |
| A-4 | ★★第9回確認書（初版 2026-09-15）の送付状況★★ | ★`docs/decisions.md` に送付記録が1行も無い★（`docs/handoff/セッション引き継ぎ_20260916.md:70-79`）。★★初版を送付済みであれば、統合版は「改訂版」として送る旨を添える必要があります★★ | ★★先に確定すること★★ |
| A-5 | ★統合版・本書に `133.125.238.144` / DBユーザー名を残すか★ | ★`docs/handoff/指示書AE_セキュリティ強化と仕上げ.md:827-829`（2-8-4「書かないこと」）は「実在のホスト名・IP・ユーザー名を書くな」としている★。★一方この2つは既に追跡済み文書（第9回確認書など5ファイル）に載っており、本書ではユーザー指示により記載した★。★パスワードは一切書いていない★。★★統合版（第9回 12-2 / 12-3 / 12-5）にも同じ2つが載っています★★ | ★★方針の食い違いあり。判断待ち★★ |