本記事は「サーバーの環境構築で詰まったら、BobというAIに聞いてみよう」シリーズのシナリオ4（最終回）です。
DBのセットアップ、地味にハマりやすい
アプリケーションサーバーの次に待ち構えているのが、データベースの構築です。PostgreSQL や MySQL はドキュメントが充実しているように見えて、実際に動かしてみると地味にハマりポイントが多いんです。
よくあるパターン：
- インストールはできたのに サービスが起動しない
- ポートが競合 していてつながらない
- 初期設定後に 認証でハマる（pg_hba.conf 系）
- 設定ファイルを変更したら サービスが起動しなくなった
「PostgreSQLって難しいな……」ってなるのはだいたいこのフェーズですよね。
シナリオA：PostgreSQL のサービスが起動しない（Linux編）
Ubuntu 22.04 に PostgreSQL 15 をインストールしたものの、サービスが起動しないケースです。
$ sudo systemctl start postgresql
Job for postgresql.service failed because the control process exited with error code.
See "systemctl status postgresql.service" and "journalctl -xe" for details.
systemctl status を確認してみると……
$ sudo systemctl status postgresql.service
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: failed (Result: exit-code)
postgresql[1234]: Error: data directory "/var/lib/postgresql/15/main" has wrong ownership
Bobへの質問例
Ubuntu 22.04 に PostgreSQL 15 をインストールしましたが、サービスが起動しません。
systemctl status の出力は以下の通りです：
Error: data directory "/var/lib/postgresql/15/main" has wrong ownership
データディレクトリのオーナーが違うと言われています。どう解決すればよいですか？
Bobの回答例
データディレクトリのオーナーが
postgresユーザーになっていないのが原因です。現在のオーナーを確認：
ls -la /var/lib/postgresql/15/オーナーを修正：
sudo chown -R postgres:postgres /var/lib/postgresql/15/main sudo chmod 700 /var/lib/postgresql/15/mainデータディレクトリを初期化し直す場合（データが空の場合のみ）：
sudo -u postgres /usr/lib/postgresql/15/bin/pg_ctl initdb \ -D /var/lib/postgresql/15/main再起動して確認：
sudo systemctl start postgresql sudo systemctl status postgresql
シナリオB：PostgreSQL に接続できない（pg_hba.conf）
サービスは起動した。でも接続しようとすると……
$ psql -U myapp -d mydb -h localhost
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed:
FATAL: password authentication failed for user "myapp"
パスワードは合っているはずなのに！
Bobへの質問例
PostgreSQL 15 のサービスは起動しましたが、アプリケーションユーザー "myapp" で
接続しようとすると "FATAL: password authentication failed" になります。
パスワードは正しく設定されているはずです。
pg_hba.conf の設定が原因かもしれないと思っています。
Ubuntu 22.04 環境です。どこを確認すればよいですか？
Bobの回答例
pg_hba.confの認証設定が原因の可能性が高いです。設定ファイルの場所を確認：
sudo -u postgres psql -c "SHOW hba_file;" # 通常は /etc/postgresql/15/main/pg_hba.conf現在の設定を確認：
sudo cat /etc/postgresql/15/main/pg_hba.conf典型的な問題と修正例：
問題のある設定（認証方式が
peerやidentになっている）：# TYPE DATABASE USER ADDRESS METHOD host all all 127.0.0.1 identパスワード認証に変更：
# TYPE DATABASE USER ADDRESS METHOD host all all 127.0.0.1 scram-sha-256設定変更後にリロード：
sudo systemctl reload postgresqlユーザーのパスワードが正しく設定されているか確認：
sudo -u postgres psql postgres=# \password myapp # 新しいパスワードを入力
シナリオC：MySQL のポート競合（Windows編）
Windows Server 2022 に MySQL 8.0 をインストールしようとしたら……
Error 0: At line 232 in C:\Program Files\MySQL\MySQL Server 8.0\data\...
InnoDB: Unable to lock ./ibdata1 error: 11
あるいはサービス起動時に：
Windows could not start the MySQL80 service on Local Computer.
Error 1067: The process terminated unexpectedly.
Bobへの質問例
Windows Server 2022 に MySQL 8.0 をインストールしましたが、
サービスが起動しません。
イベントビューアに以下のエラーが出ています：
「InnoDB: Unable to lock ./ibdata1 error: 11」
また別のタイミングでは：
「Error 1067: The process terminated unexpectedly」
も発生しています。どう対処すればよいですか？
Bobの回答例
「ibdata1 をロックできない」エラーは、MySQLが既に別のプロセスで起動中か、前回の終了が正常でなかった場合に発生します。
手順1: MySQL プロセスが既に動いていないか確認
# タスクマネージャー または以下のコマンドで確認 Get-Process | Where-Object {$_.Name -like "mysql*"} # もし残っていれば停止 Stop-Process -Name "mysqld" -Force手順2: ポート 3306 が他のプロセスで使われていないか確認
netstat -ano | findstr :3306 # PIDが表示された場合、タスクマネージャーで該当プロセスを確認手順3: MySQL のデータディレクトリにあるロックファイルを削除
# デフォルトのデータディレクトリ cd "C:\ProgramData\MySQL\MySQL Server 8.0\Data" # ib_logfile0, ib_logfile1 が壊れている場合は削除（データは ibdata1 にある） # ※重要なデータがある場合は事前にバックアップ手順4: MySQL サービスを再起動
Restart-Service MySQL80それでも解決しない場合: MySQL の error log を確認してください。
# エラーログの場所を確認 # 通常: C:\ProgramData\MySQL\MySQL Server 8.0\Data\<hostname>.err Get-Content "C:\ProgramData\MySQL\MySQL Server 8.0\Data\*.err" -Tail 50
Bobにエラーログを丸ごと渡すのが最強
DBのトラブルは、エラーメッセージだけでなく ログファイルの内容 を一緒に渡すと、Bob の回答精度が格段に上がります。
# PostgreSQL のログ
sudo tail -100 /var/log/postgresql/postgresql-15-main.log
# MySQL のエラーログ（Linux）
sudo tail -100 /var/log/mysql/error.log
# MySQL のエラーログ（Windows）
Get-Content "C:\ProgramData\MySQL\MySQL Server 8.0\Data\*.err" -Tail 100
これを丸ごとコピーして Bob に貼り付け、「このログを見てエラーの原因を教えて」と一言添えるだけで、非常に精度の高いトラブルシューティングができます。
Bobを使うポイントまとめ
| ポイント | 内容 |
|---|---|
| ログファイルを丸ごと渡す | エラーメッセージだけでなくログ全体を見せると原因特定が速い |
| 設定ファイルを貼り付ける |
pg_hba.conf や my.cnf の内容を貼ると設定の誤りをすぐ指摘してもらえる |
| OS + DBバージョンを明記 | 同じDBでもバージョンによって挙動が違う |
| 「なぜこの設定が必要か」も聞く | 設定の意味を理解すると次のトラブルで応用できる |
シリーズのまとめ：Bob と一緒にサーバー構築を乗り越えよう
このシリーズでは、サーバー環境構築でよくある4つのシナリオで Bob を使う方法を紹介しました。
共通して言えることは：
- エラーメッセージはそのままコピペ（省略しない）
- OS・バージョン・ファイルパスなど環境情報を添える
- 解決できなくても諦めずに続けて質問する（会話を続けられる）
そして何より、最新のAIツールが使えないレガシー環境こそ、Bob IDEさえ動けば使える Bob の強みが光るということを覚えておいてください。
困ったときは気軽に Bob に投げてみましょう！
Bob を試してみたい方へ
🔗 IBM Bob 無料お試し版（30日間・40Bobcoin）