databases

データベース：本番環境の設定と運用

単一ノードの開発環境から PCI 準拠の本番クラスターまで、データベースエンジンの設定、チューニング、スキーマ設計、移行、バックアップ、レビューを行います。障害に耐え、監査に合格する、正確で高性能かつ耐久性の高いデータベースを実現することが目的です。

対象バージョン（2026 年 10 月）：

• PostgreSQL 18.6（EOL 2030-11；2026 年 8 月 13 日リリース）、バックブランチ：17.11、16.15、15.19、14.24（EOL 2026-11-12 - 今すぐ 14 からのアップグレードを計画してください）；PostgreSQL 19 RC 1（2026-10-15）はテスト専用です
• MongoDB 9.0.2（新しいメジャーバージョン、2026-09-28 GA、EOL 2031-10）；8.0 系統 8.0.34（EOL 2029-10）；8.0.32 は CVE-2026-89099 を修正しており、8.0 系統でのセキュリティ上の最低バージョンです。高速リリース系統は Atlas 専用でサポート期間が短いため、バージョンを固定する前に最新情報を確認してください
• MariaDB 11.8.9（LTS、EOL 2028-06）、12.3.3（LTS、EOL 2029-06）；13.x のローリング GA は四半期ごとに提供され、各後継バージョンのリリース時に EOL となります。最新情報を確認してください
• MySQL 8.4.12（LTS；2026 年 8 月 18 日リリース）、9.7.3（9.7 LTS 系統；2026 年 8 月 18 日リリース）；イノベーション系統はサポート期間が短いため、最新情報を確認してください
• Redis 8.10.2；Valkey 9.1.2（9.0 系統では 9.0.6）- バージョンを固定する前に最新情報を確認してください
• SQL Server 2025 RTM + CU9（2026-09-15 リリース）
• PgBouncer 1.26.0（CVE-2026-19888/6668/6669 を修正）、Pgpool-II 4.7.3、ProxySQL 3.0.11（3.0.9 以降で CVE-2026-48772/48773 を修正；CVE-2026-48774 は 4.0 系統に影響し、4.0.9 で修正）

このスキルでは、状況に応じて次の分野を扱います：

• 設定 - エンジン設定、認証、TLS、チューニングパラメーター
• スキーマ設計 - インデックス戦略、パーティショニング、正規化、型の選択
• 移行 - エンジン間の移行、ダウンタイムなしの DDL、ORM 移行ツール
• 運用 - バックアップ／復元、レプリケーション、コネクションプーリング、監視
• パフォーマンス - クエリプランの分析、インデックスの最適化、バキューム／メンテナンス
• コンプライアンス - PCI-DSS 4.0 の暗号化、監査ログ、鍵管理、データマスキング
• Redis／Valkey の運用 - キャッシュまたは永続データの分類、メモリ／エビクション、永続化、 レプリケーション、ACL／TLS、ストリームの復旧

使用する場面

• データベースエンジンの設定（postgresql.conf、mongod.conf、my.cnf、MSSQL 設定）
• データベーススキーマの設計またはレビュー（インデックス、パーティショニング、型、制約）
• エンジン間の移行の計画または実行（MySQL -> PostgreSQL など）
• バックアップ／復元戦略と PITR の設定
• レプリケーションの設定（ストリーミング、論理、レプリカセット、GTID）
• コネクションプーリングのチューニング（PgBouncer、ProxySQL、アプリケーション側のプール）
• クエリパフォーマンスの分析（EXPLAIN、スロークエリログ、インデックスの使用状況）
• データベースレベルでの PCI-DSS 4.0 準拠（暗号化、監査ログ、アクセス制御）
• マネージドデータベースとセルフホストのどちらにするかの評価
• エンジン固有のメトリクスの公開と、データベース固有のヘルス情報やクエリシグナルの診断
• Redis または Valkey をキャッシュ、データストア、セッションストア、ストリームとして運用

使用しない場面

• Kubernetes へのデータベースのデプロイ（StatefulSets、PVC、オペレーター）- kubernetes を使用してください
• IaC によるマネージドデータベース（RDS、Cloud SQL、Atlas）のプロビジョニング - terraform を使用してください
• データベースコンテナ向けの Docker Compose - docker を使用してください
• データベース関連の Ansible プレイブックとロール - ansible を使用してください
• アプリケーションレベルのデータベースのバグ（N+1、トランザクションの誤用、ORM の落とし穴）- code-review を使用してください
• SQL インジェクションの検出、コード内の接続文字列のシークレット - security-audit を使用してください
• 移行を実行する CI/CD パイプライン - ci-cd を使用してください
• サービス間のテレメトリパイプライン、ダッシュボード、アラートルーティング、SLO - observability を使用してください
• その他の非リレーショナルエンジン（Cassandra、DynamoDB、ClickHouse など）- 関連するプラットフォームスキルまたは一般的なガイダンスを使用してください

---

AI セルフチェック

AI ツールは、データベースに関する同じ間違いを繰り返し生成します。生成した SQL、スキーマ、移行、設定を返す前に、次のリストに照らして確認してください：

マイグレーション

• バージョン管理されたマイグレーションでは、予期しないスキーマドリフトを検出します。意図的に再実行可能な操作に限り、ガードを使用します
• NOT NULL 列の追加には DEFAULT 値を含めます（または、NULL 許容列を追加してデータをバックフィルした後、NOT NULL に変更する2段階の手順を使用します）
• 書き込みが行われる PostgreSQL でインデックスを構築する際は、サポートされている場合に限り、トランザクションブロックの外で CONCURRENTLY を使用します。失敗後は無効なインデックスがないか確認します
• 大規模なテーブル変更は、単一のトランザクションではなく、バッチで実行します（ロックのエスカレーション、OOM のリスク）
• マイグレーションには後方互換性があります（新しいスキーマに対して、古いアプリのバージョンも引き続き実行できます）
• ユーザーの明示的な確認なしに DROP TABLE または DROP DATABASE を実行しません
• マイグレーションランナーは適用済みバージョンを記録します。再実行可能な運用スクリプトは、収束し、既存のオブジェクトを検証します
• 復旧手順をテストします。安全な場合はダウンマイグレーションを行い、元に戻すとデータが失われる場合は、前進修正または復元の手順を文書化します
• PG の enum の変更には、トランザクションの外で ALTER TYPE ... ADD VALUE を使用します（PG 12 以降ではトランザクション内でも実行できますが、そのトランザクションがコミットされるまで新しい値は使用できません。値をすぐに使用するには、単独で実行します）

スキーマ

• 新しいタイムスタンプ列には、timestamptz（PG）、DATETIME2（MSSQL）、DATETIME（MySQL。TIMESTAMP には2038年問題があります）を使用します
• MySQL では文字セットに utf8mb4（3バイトのみの utf8 ではなく）、PG では UTF8 を使用します
• PG 10 以降では、識別列に SERIAL ではなく GENERATED ALWAYS AS IDENTITY を使用します（バイパス不可）
• 外部キーには、明示的な ON DELETE の動作を指定します（エンジンのデフォルトに依存しないでください）
• すべての外部キー列にインデックスを作成します（MySQL InnoDB とは異なり、PG では自動作成されません）
• 複合インデックスの列順は、等価条件の列を先、範囲条件の列を最後にし、選択性の高い順にします

設定

• pg_hba.conf では trust または md5 認証を使用しません（scram-sha-256 を使用します）
• MySQL の sql_mode に STRICT_TRANS_TABLES を含めます（データの暗黙の切り捨てを防ぎます）
• 「利用可能」にするだけでなく、すべての接続で TLS を必須にします
• max_connections はデフォルトのままにせず、実際のワークロードに合わせて設定します
• パスワード認証には最新のハッシュ方式を使用します（PG では SCRAM-SHA-256、MySQL では caching_sha2_password）
• 設定ファイルにデフォルトまたはサンプルのパスワードを含めません

一括操作

• 一括挿入はチャンクに分割します。上限のない配列を単一の INSERT ... VALUES 文に渡してはいけません
• チャンクサイズは floor(max_host_parameters / columns_per_row) で計算します。ホストパラメーターの上限は、PostgreSQL が 65,535、MySQL が 65,535、SQLite が 32,766（デフォルトの SQLITE_MAX_VARIABLE_NUMBER）、MSSQL が 2,100 です
• アプリが複数のバックエンドを対象とする場合、サポートするすべてのエンジンのうち、最も低い上限を使ってチャンクサイズを決めます
• 原子性が重要な場合、チャンク化した書き込みは1つのトランザクション内で行います（全件置換の DELETE + INSERT では常に必須です）。それ以外の場合は、実行失敗後に再開できるよう、各チャンクを冪等にします
• 行数が安全なチャンクしきい値を超えた際に、複数回の挿入呼び出しが行われることをテストで検証します

全般

• すべての SQL で、パラメーター化クエリまたはプリペアドステートメントを使用します（文字列連結は使用しません）
• 接続プールの設定値は、すべてのアプリインスタンスを合計しても max_connections を超えないようにします
• バックアップ戦略は、実際に復元してテストします（復元テストのないバックアップは、戦略ではなく希望にすぎません）
• シークレット（パスワード、接続文字列）は、設定ファイルではなく、環境変数またはシークレットマネージャー経由で注入します
• エンジン／バージョンを確認：SQL 構文、インデックスオプション、レプリケーションに関するアドバイスが、指定されたエンジンとメジャーバージョンに合致していることを確認します
• データ損失につながる操作を保護：マイグレーション、削除、インデックスの再構築、フェイルオーバーには、バックアップ、ドライラン、ロールバック、またはメンテナンス時間帯に関するガイダンスを含めます
• 横断的なエージェントの衛生管理を適用します。references/agent-hygiene.md を参照してください

---

ベストプラクティス

• 本番データとは分離された復元先で復元訓練を実施し、アプリケーションの読み書き、整合性、暗号化キーへのアクセス、PITR の境界を検証します。復旧にかかった時間とデータ損失を RTO/RPO と照らし合わせて測定し、稼働中のデータを上書きすることなく、元のバックアップ、確認項目、クリーンアップを記録します。
• クエリの形状やレイテンシーが異なる場合は、オンライン、バックグラウンド、分析の各ワークロードを分離します。

ワークフロー

Step 1: ドメインを特定する

リクエストに基づいて判断します。

• 「PostgreSQL を設定する／設定を調整する」 -> 設定
• 「スキーマを設計する／インデックスをレビューする」 -> スキーマ設計
• 「X から Y に移行する／カラムを追加する」 -> 移行
• 「バックアップ／レプリケーション／プーリングを設定する」 -> 運用
• 「このクエリが遅い／最適化する」 -> パフォーマンス
• 「PCI 監査／データベースを暗号化する」 -> コンプライアンス
• 「このスキーマ／設定をレビューする」 -> 本番環境チェックリストを適用 + AI によるセルフチェック

Step 2: 要件を収集する

SQL や設定を書く前に、以下を確認します。ユーザーから指定がない場合は、示されている妥当なデフォルト値を使用します。

• エンジンとバージョン - バージョンによって動作が大きく異なります。デフォルト：最新の安定版（上記の対象バージョンを参照）。
• デプロイモデル - セルフホスト（ベアメタル、VM、コンテナー、K8s）かマネージド（RDS、Cloud SQL、Atlas）か。デフォルト：文脈から別の指定がない限り、セルフホストを想定します。
• ワークロードの種類 - OLTP（小規模なトランザクションが多数）か OLAP（大規模なクエリが少数）か、または混在か。デフォルト：OLTP。
• データ量 - 行数、テーブルサイズ、増加率。デフォルト：中規模（1～100GB）。不明な場合は、増加を見越して最適化します。
• コンプライアンス - PCI-DSS CDE か、HIPAA か。データ分類は何か。デフォルト：コンプライアンスの適用範囲外（ただし、セキュリティのベースラインは適用します）。
• HA 要件 - RTO/RPO の目標、マルチ AZ、読み取りレプリカ。デフォルト：PITR を備えた単一ノード。
• 既存のインフラストラクチャ - すでに稼働しているもの、使用中の ORM／ドライバー。アクセス可能であれば、コードベースを調査します。

Step 3: 構築する

以下のドメイン別セクションに従います。完了前に、必ず本番環境チェックリストと AI によるセルフチェックを適用します。

構築前に references/build-patterns.md を読みます。ここには、クエリ最適化（PostgreSQL、MySQL、MongoDB の実行計画）、ロックとデッドロックの診断、PgBouncer のサイジング、移行の安全性に関するクイックスタートパターンに加え、破壊的な操作や本番環境を変更する操作の前に必須となるチェックリストが記載されています。

Step 4: 検証する

まずクライアントを検出します（command -v psql mongosh mysql sqlcmd）。クライアントが見つからない場合は確認済みとせず、報告すべき不足事項として扱います。確認に失敗した場合は、設定、クエリ、または移行を修正し、Step 3 に戻ります。破壊的な操作に失敗した場合は停止して再計画し、決して即興で二度目の操作を行わないでください。

# PostgreSQL
psql -c "SHOW config_file;"                    # verify config location
pg_isready -h localhost                         # connection check
psql -c "SELECT * FROM pg_hba_file_rules;"     # verify pg_hba.conf
psql -c "EXPLAIN (ANALYZE, BUFFERS) <query>;"  # query plan analysis

# MongoDB
mongosh --eval "db.adminCommand({getCmdLineOpts: 1})"  # verify config
mongosh --eval "rs.status()"                            # replica set health
mongosh --eval "db.collection.explain('executionStats').find({})"

# MySQL / MariaDB
mysql -e "SELECT @@sql_mode;"                  # verify strict mode
mysql -e "SHOW VARIABLES LIKE 'innodb%';"      # InnoDB settings
mysql -e "EXPLAIN FORMAT=TREE <query>;"        # query plan (MySQL 8.0+)

# MSSQL
sqlcmd -Q "SELECT @@VERSION;"
sqlcmd -Q "DBCC CHECKDB ('dbname') WITH NO_INFOMSGS;"  # integrity check

---

エンジンの振り分け

• PostgreSQL：SCRAM、プーラー、WAL または論理レプリケーション、pg_stat_statements、慎重なバキューム戦略
• MongoDB：レプリカセットの健全性、スキーマ検証、oplog のサイジング、ファンアウトを招くドキュメントパターンの回避
• MySQL/MariaDB：厳格モード、utf8mb4、GTID または Galera の選択、MySQL と MariaDB の違いの把握
• MSSQL：メモリ制限、TempDB のレイアウト、Query Store、バックアップおよび復元の徹底
• Redis/Valkey：キャッシュと永続データの分類、メモリ／エビクションの安全性、永続化、レプリケーション、ACL/TLS、ストリームコンシューマーの復旧。references/redis-valkey.md を読みます。

---

スキーマ、移行、パフォーマンス

• ダウンタイムなしでスキーマを変更するには、expand-contract を優先します。
• 複合インデックスの順序は、引き続き等価条件、ソート、範囲条件の順にします。
• テナント分離方式は慎重に選択します。PCI の対象となる共有スキーマの設計は、特に入念に精査する必要があります。
• クエリプランのレビューとモニタリングは、緊急時だけでなく通常の運用業務として扱います。
• LEFT JOIN の意味を損なう WHERE 句に注意します（外部テーブルの絞り込みによって INNER JOIN に変わります。フィルターを ON 句に移すか、サブクエリを使用します）。

メジャーバージョンのアップグレード

PostgreSQL のメジャーバージョンをアップグレードする前に、方式の選択（pg_upgrade、論理レプリケーション、ダンプ／リストア）、ダウンタイムゼロの手順書、ロールバック、注意点について、references/version-upgrades.md を読んでください。

エンジン間の型マッピング、ORM のマイグレーションツール、大規模なマイグレーションパターンの詳細については、references/migration-patterns.md を読んでください。

---

プーリング、バックアップ、プラットフォームの選択

• バックアップの適切な運用には、リストアテスト、暗号化、保持期間の上限、バックアップの鮮度の監視が必要です。
• マネージドデータベースは運用負荷を軽減しますが、共同責任やコンプライアンスのレビューが不要になるわけではありません。
• セルフホスト型データベースでは、HA、パッチ適用、運用負荷を代償に制御性を得られます。

---

本番環境チェックリスト

すべてのエンジン

• 認証に最新のハッシュ方式（SCRAM-SHA-256、caching_sha2_password、証明書認証）を使用している
• すべての接続で TLS を必須にしている（「利用可能」なだけでは不十分）
• デフォルトのパスワード、trust 認証、パスワードなしのアクセスを使用していない
• データベースの前段にコネクションプール（PgBouncer、ProxySQL、またはアプリケーション側）を配置している
• max_connections をデフォルト値ではなく、実際のワークロードに合わせて設定している
• バックアップ戦略を導入し、テストし、監視している
• リストア手順を文書化し、テストしている（少なくとも毎月）
• 監視を導入している（接続数、クエリパフォーマンス、レプリケーション遅延、ディスク使用量）
• 適切なしきい値でスロークエリのログ記録を有効にしている
• 不要または未使用のインデックスを特定し、削除している
• 文字エンコーディングが正しい（MySQL では utf8mb4、PG では UTF8）

レビュー、設定、本番環境への変更を完了する前に、PostgreSQL、MySQL/MariaDB、MongoDB、MSSQL のエンジン固有のチェックと、PCI-DSS 4.0 のコンプライアンスチェックについて、references/production-checklist.md を読んでください。CVE のパッチ適用基準は最低限のものです。最新のリリースについては、先頭にある 対象バージョン ブロックを使用してください。

---

参考ファイル

• references/config-templates.md - エンジン、pg_hba、ロール、または PgBouncer の設定を記述する際に読んでください
• references/backup-patterns.md - バックアップ、リストア、PITR、または保持期間を変更する前に読んでください
• references/migration-patterns.md - エンジン間の移行、型マッピング、ORM ツール、大規模テーブルの DDL について読んでください
• references/redis-valkey.md - Redis または Valkey にデータ、セッション、ストリームを保存する場合は必ず読んでください
• references/version-upgrades.md - PostgreSQL のメジャーバージョンをアップグレードする前に読んでください
• references/build-patterns.md - Step 3 でクエリ、ロック、プーラー、マイグレーションの安全性に関するパターンについて、また破壊的な操作を行う前に読んでください
• references/production-checklist.md - エンジン固有のチェックと PCI-DSS 4.0 のチェックについて、「すべてのエンジン」チェックリストと併せて読んでください

---

出力仕様

仕様の全文については、references/output-contract.md を参照してください。

• スキル名： DATABASES
• 成果物カテゴリ： audits
• モード： 条件付き。既存のリポジトリの内容を分析、レビュー、監査、改善するために呼び出された場合は、references/output-contract.md のレポートの分量とエビデンスに関するルールに従い、成果物を docs/local/audits/databases/<YYYY-MM-DD>-<slug>.md に書き込んでください。質問への回答、概念の説明、新しい成果物の作成、コンテンツの生成のために呼び出された場合は、仕様に従わず自由に回答してください。
• 重大度の尺度： P0 | P1 | P2 | P3 | info（共通仕様を参照。監査／レビューのモードでのみ使用）

関連スキル

• code-review - アプリケーションレベルのデータベースのバグパターン（トランザクションの誤用、NULL の処理、ORM の N+1 問題、型変換）について、databases.md のリファレンスがあります。このスキルではエンジンの構成と運用を扱い、code-review ではアプリケーションによるデータベースの使用方法を扱います。
• security-audit - アプリケーションコードにおける SQL インジェクションの検出と認証情報のスキャン
• kubernetes - K8s でのデータベースのデプロイ（StatefulSets、オペレーター、PVC）
• terraform - マネージドデータベースのプロビジョニング（RDS、Cloud SQL、Atlas）
• docker - Docker Compose でのデータベースコンテナー
• ansible - データベースサーバーの構成管理
• ci-cd - マイグレーションを実行する CI/CD パイプライン（CI でのスキーマ実行、マイグレーションのゲート制御、ロールバックの自動化）
• observability - サービス横断のテレメトリーパイプライン、ダッシュボード、アラートルーティング、SLO。 このスキルでは、データベース固有のメトリクス、エンジンの健全性、クエリ診断を扱います。
• message-queues - ブローカーの配信契約、再試行、デッドレター、順序、再生。この スキルでは、Redis/Valkey エンジンの構成とストリームデータの安全性を扱います。

---

ルール

1. リストアテストをしていないバックアップは、バックアップではありません。 毎月リストアテストを実施してください。手順を文書化してください。
2. pg_hba.conf で trust 認証を使用しないでください。 開発環境でも、Docker でも、どこでも使用しないでください。scram-sha-256 を使用してください。
3. PostgreSQL にはコネクションプーラーを使用してください。 PG の接続ごとにプロセスを生成するモデルは、プーラーなしではスケールしません。具体的な理由がない限り、PgBouncer を使用してください。
4. PostgreSQL では外部キーにインデックスを設定してください。 PG は自動作成しません。外部キーのインデックスがないと、JOIN や連鎖 DELETE でシーケンシャルスキャンが発生します。
5. MySQL では常に utf8mb4 を使用してください。 utf8 は実際には 3 バイトのみで、絵文字や多くの CJK 文字を保存できません。
6. PostgreSQL では常に timestamptz を使用してください。 タイムゾーンを指定しない timestamp はタイムゾーンを保存しないため、サーバーのタイムゾーンが変わると問題が発生します。
7. ディスクレベルの暗号化だけでは PCI-DSS 4.0 の要件を満たしません。 要件 3.5.1.2 では、TDE、列レベル、またはアプリケーション層の暗号化が必要です。
8. MongoBleed（CVE-2025-14847）に対するパッチを適用してください。 セルフホストの MongoDB < 8.0.17 / 7.0.28 / 6.0.27 は、認証なしで積極的に悪用されています。
9. MongoDB の圧縮 DoS（CVE-2026-25611）に対するパッチを適用してください。 細工した OP_COMPRESSED メッセージによる、認証前の DoS です。デフォルト設定（3.6 以降で圧縮が有効）も影響を受けます。8.0.18+ / 8.2.4+ / 7.0.29+ で修正されています。
10. PgBouncer にパッチを適用してください。 PgBouncer < 1.25.1（CVE-2025-12819）では、track_extra_parameters に search_path が含まれ、かつ auth_user が設定されている場合（どちらもデフォルトではない設定）、認証されていないユーザーによる SQL 実行が可能になることがあります。2026 年 5 月の 1.25.2 リリースでは、さらに複数の修正が追加されています（CVE-2026-6664/6665/6666/6667：整数オーバーフロー、SCRAM、null 参照、KILL_CLIENT の認可）。2026 年 9 月の 1.26.0 リリースでは、CVE-2026-19888（nonce を含まない SCRAM client-final-message による、認証不要のクラッシュ）、CVE-2026-6668（デフォルトの max_packet_size におけるパケットバッファーのオーバーフローによる認証前のハング）、CVE-2026-6669（上限のないサーバー SCRAM イテレーション）が修正されています。修正に伴うリスクは低いため、1.26.0+ にアップグレードしてください。
11. 承認済みの正確なコマンドなしで、破壊的なコマンドを実行しないでください。 削除、破壊的なリストア、フェイルオーバー、バックエンドの終了は、確認済みの対象に対して、承認されたテキストどおりにのみ実行してください。