モダンPHPにおけるコーディング規約の標準：PER Coding Styleへの移行と自動化の解説

2026年5月14日

コーディング規約

PHPは誕生から長い年月を経て、Webアプリケーション開発における中心的な言語としての地位を確立してきました。

言語の進化に伴い、開発者が守るべきコードの書き方、すなわち「コーディング規約」もまた大きな変革の時を迎えています。

これまではPSR-12が長らく標準とされてきましたが、現在はより現代的な仕様を取り込んだ「PER Coding Style」へと主流が移り変わっています。

本記事では、なぜ今PER Coding Styleが重要なのか、そしてどのように自動化ツールを導入して品質を担保すべきかを詳しく解説します。

目次 [ close ]

PHPコーディング規約の変遷とPSRからPERへの移行

PHPの世界には、PHP-FIGというグループが策定してきたPSR（PHP Standard Recommendation）という標準仕様が存在します。

その中でもコードスタイルを定義したPSR-2やPSR-12は、世界中の開発者に広く採用されてきました。

しかし、PHPのリリースサイクルが早まり、属性や読み取り専用プロパティなどの新機能が次々と追加される中で、従来のPSRの仕組みでは追いつかなくなりました。

そこで登場したのが、PER（PHP Ecosystem Readiness）Coding Styleです。

PSR-12の限界とPERの誕生背景

PSR-12は2019年に策定されましたが、それ以降のPHP 8.0以降の劇的な進化を完全にはカバーできていませんでした。

PSRは一度承認されると内容を更新しない「不変のドキュメント」としての性質を持っていました。

それに対してPERは、言語の進化に合わせて継続的にアップデートされる「生きた規格」として設計されています。

現在はPSR-12の正式な後継として、PER Coding StyleがPHP-FIGによって推奨されています。

PER Coding Styleが目指すもの

PERの最大の特徴は、新しい構文に対するルールが即座に追加される点にあります。

例えば、コンストラクタのプロパティ昇格や、型宣言の和集合（Union Types）などの記述方法が明確に定義されています。

これにより、プロジェクトに関わる全員が迷うことなく、最新のPHP機能を最適な形で利用できるようになります。

また、ツール間の互換性を高め、エコシステム全体で一貫したスタイルを維持することも大きな目的の一つです。

PER Coding Styleで定義されている主な記述ルール

PERはPSR-12をベースにしつつ、モダンな機能を活用するためのルールを数多く追加しています。

ここでは、特に意識すべき重要なポイントをいくつか紹介します。

プロパティとメソッドの宣言

PHP 8.x以降で頻繁に使われるようになったreadonlyプロパティの配置などが厳格に定められています。

アクセス修飾子、型、プロパティ名の順序が整理され、視認性が大幅に向上しています。

PHP

<?php

namespace App\Services;

class UserRegistrationService
{
    // readonlyプロパティの記述例
    public function __construct(
        protected readonly string $apiToken,
        private readonly int $timeout = 30,
    ) {
    }
}

属性（Attributes）の配置

PHP 8.0で導入された属性についても、PERでは記述位置が指定されています。

クラスやメソッド、プロパティに対して属性を付与する場合、原則としてその要素の直前の行に記述します。

これにより、メタデータと実際のロジックを視覚的に分離しやすくなります。

PHP

<?php

class BlogPost
{
    #[Required]
    #[MaxLength(255)]
    public string $title;
}

型宣言と戻り値の扱い

共用型（Union Types）や交差型（Intersection Types）の記述におけるスペースの有無も定義されています。

基本的には型を区切る記号の前後にスペースを入れないスタイルが標準となっています。

また、戻り値の型の前には必ずコロンを置き、その前にスペースを1つ入れるというPSR-12からのルールも継承されています。

コーディング規約を導入するメリット

規約を導入することは、単に見た目を整えるだけではありません。

開発チーム全体に、計り知れない長期的なメリットをもたらします。

コードレビューの効率化

規約が統一されていないと、レビュー時に「インデントがずれている」「波括弧の位置が違う」といった本質的でない指摘が増えてしまいます。

規約を導入し自動化することで、レビュアーはロジックの正しさや設計の妥当性に集中できるようになります。

これは、開発サイクルのスピードアップに直結する重要な要素です。

メンテナンス性の向上

誰が書いても同じスタイルで構成されたコードは、後から読み直す際の認知負荷を下げます。

数ヶ月後に自分自身が読み返す場合や、新しくチームに加わったメンバーがコードを読む際、統一されたルールは大きな助けとなります。

「読みにくいコード」はバグの温床となりますが、規約の遵守はそのリスクを低減させます。

規約チェックと自動成形のツール選定

コーディング規約は、人間が手動でチェックするものではありません。

PHPのエコシステムには、規約を自動で検証・修正するための強力なツールが揃っています。

主要ツールの比較

現在、PHP開発で一般的に利用されている主要なツールを以下の表にまとめました。

ツール名	主な用途	特徴
PHP-CS-Fixer	自動修正（Fixer）	非常に強力な修正能力を持ち、PERにも対応。最も推奨される。
PHP_CodeSniffer	検知（Linter）	古くからある標準的なツール。検知に強く、多くのプリセットがある。
Laravel Pint	自動修正	PHP-CS-FixerをベースにしたLaravel向けのラッパーツール。設定が非常に楽。

PHP-CS-Fixerによる自動化

モダンPHP開発において、最も汎用性が高く強力なのがPHP-CS-Fixerです。

このツールはコードの不備を指摘するだけでなく、コマンド一つで規約通りに書き換えてくれます。

PER Coding Styleを適用するためには、設定ファイルでルールを指定するだけで完了します。

PHP-CS-Fixerの具体的な導入手順

それでは、実際にプロジェクトにPHP-CS-Fixerを導入し、PERを適用する手順を見ていきましょう。

ツールのインストール

Composerを使用して、開発用パッケージとしてインストールします。

Shell

composer require --dev friendsofphp/php-cs-fixer

設定ファイルの作成

プロジェクトのルートディレクトリに .php-cs-fixer.dist.php という名前で設定ファイルを作成します。

このファイルの中で、PERをベースとしたルールセットを定義します。

PHP

<?php

$finder = PhpCsFixer\Finder::create()
    ->in(__DIR__ . '/src')
    ->in(__DIR__ . '/tests');

$config = new PhpCsFixer\Config();
return $config->setRules([
    '@PER-CS' => true, // PER Coding Styleを適用
    'array_syntax' => ['syntax' => 'short'], // 配列は短縮構文を使用
    'ordered_imports' => ['sort_algorithm' => 'alpha'], // use句をアルファベット順に
    'no_unused_imports' => true, // 未使用のuse句を削除
])
    ->setFinder($finder);

実行と結果の確認

設定が完了したら、以下のコマンドを実行してコードを自動修正します。

Shell

vendor/bin/php-cs-fixer fix

実行後、規約に沿っていない箇所が自動的に書き換えられます。

実行結果

Loaded config from ".php-cs-fixer.dist.php".
Using cache file ".php-cs-fixer.cache".
Paths from configuration file have been used.
   1) src/User.php (braces_position, visibility_required)
   2) src/Controller/HomeController.php (no_unused_imports)

Fixed all files in 0.123 seconds, 12.000 MB memory used

CI/CDでの自動チェック体制の構築

ローカル環境での実行に加え、GitHub ActionsなどのCIツールで自動チェックを行うことが重要です。

これにより、規約違反のあるコードが共有リポジトリにマージされるのを未然に防ぐことができます。

GitHub Actionsの設定例

プルリクエストが作成された際に、PHP-CS-Fixerのドライラン（検証モード）を実行する設定です。

違反がある場合はエラーとして終了し、マージをブロックすることができます。

YAML

name: Check Coding Style

on: [push, pull_request]

jobs:
  php-cs-fixer:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'

      - name: Install dependencies
        run: composer install --prefer-dist --no-progress

      - name: Run PHP-CS-Fixer
        run: vendor/bin/php-cs-fixer fix --dry-run --diff

既存プロジェクトからの移行戦略

すでに運用されている大規模なプロジェクトで、いきなり全てのルールを適用するのはリスクが伴います。

段階的な移行を行うことで、業務への影響を最小限に抑えることができます。

ステップ1：現状の把握とルール選定

まずは --dry-run オプションを使用して、どの程度の修正が発生するかを把握します。

最初は @PSR12 などの緩やかなルールから始め、徐々に @PER-CS へとレベルを引き上げていくのが賢明です。

ステップ2：ディレクトリごとの適用

一括ですべてのファイルを修正するのではなく、ディレクトリ単位で順次適用していきます。

例えば、まずは src/Utils などの共通ライブラリから適用し、動作確認を行いながら範囲を広げます。

これにより、万が一自動修正による予期せぬ動作の変化（非常に稀ですが）があった際の影響範囲を限定できます。

ステップ3：コミットの分離

ロジックの修正とコーディング規約の適用は、必ず別のコミットとして分けて管理してください。

これらが混在すると、後から変更履歴を追跡することが非常に困難になります。

「Refactor: Apply PER Coding Style」といった明確なメッセージとともにコミットを行いましょう。

エディタとの連携でリアルタイムな修正を

開発の最終段階でツールを実行するのではなく、コードを書いているその瞬間に規約を意識することも大切です。

VS CodeやPhpStormなどの主要なエディタには、PHP-CS-Fixerと連携する拡張機能が存在します。

「ファイルを保存した瞬間に自動で規約通りにフォーマットする」設定を有効にすることで、開発者は規約を意識することなく、常に美しいコードを書き続けることができます。

まとめ

PHPのコーディング規約は、PSR-12からより柔軟でモダンなPER Coding Styleへと進化しました。

PERを採用することで、PHP 8.x以降の新しい構文を最大限に活用し、一貫性のあるコードベースを維持することが可能になります。

また、PHP-CS-Fixerなどのツールを導入し、CI/CDパイプラインに組み込むことで、規約のチェックを自動化し、チームの生産性を飛躍的に向上させることができます。

規約は単なる制約ではなく、チーム全体で高品質なソフトウェアを安定して提供するための「共通言語」です。

まだPSR-12以前のスタイルで開発を行っている場合は、この機会にぜひPER Coding Styleへの移行を検討してみてください。

未来の自分やチームメンバーのために、常に清潔で読みやすいコードを保つ習慣を身につけていきましょう。