対象読者

• 共有レンタルサーバーや Docker 化されていない環境で php.ini を触れない
• .htaccess を増やしたくない
• ひとまず 1 ファイルに追記してサクッと動かしたい フェーズの開発者

ざっくり要点

• set_include_path() を 1 行書くだけ でインクルードパスは動的に追加できる。
• パス連結は PATH_SEPARATOR 定数を使えば OS 依存 (: と ;) を忘れても OK。
• 同じことは ini_set('include_path', …) でも出来るが、区切り文字を手書きするぶん “ミス増幅装置”。
• 規模が大きくなるか、だれかとコードを共有するなら Composer オートローダ にすぐ移行しよう。

include_path とは？

PHP が require / include / spl_autoload_* を解決するときに検索する 検索ディレクトリのリスト。もともとは php.ini の include_path ディレクティブで設定される。

• メリット : 毎回フルパスを書く必要がない
• デメリット : 可視性が低く、プロセス全体に影響する（＝副作用が大きい）

覚えておきたい指針 — 小規模なら便利、大規模なら危険。

スクリプトから変更する 3 つの方法

Composer がある今、実務で include_path を増やすシーンはかなり減った。とはいえ “昔の CMS” や “とりあえずのスクリプト” ではまだ生きている技術なので、最低限の安全策は知っておくとトラブルシュートに役立つ。

set_include_path() の実装例

<?php
// 追加したいディレクトリを変数化
$extraPath = __DIR__ . '/lib';

// 既存の include_path に安全に連結して再設定
set_include_path(
    get_include_path() . PATH_SEPARATOR . $extraPath
);

• __DIR__ で常に 絶対パス化 してから連結すると移植性が高い。
• PATH_SEPARATOR を使えば Windows (;) / Unix (:) の差異を吸収できる。

ワンポイント — 複数追加したい場合は変数に配列で持ち、implode(PATH_SEPARATOR, $paths) でまとめると可読性が上がる。

ini_set() と何が違う？

ini_set() でも動くが、呼び出しは次のようになりがち。

ini_set('include_path', get_include_path() . ':' . $extraPath);

• 区切り文字を手書きするので OS 混在案件だとバグ源。
• ini_set() は **その他 ini 値を動的に変える“危ない道”**も開きがちで、レビュー時の脳内負荷が増える。

少しでも迷うなら set_include_path() を選ぶのが無難。

ベストプラクティス（2025 年版）

1. プロジェクト規模 > 個人スクリプト なら Composer へ。composer dump-autoload -o 一発でクラス探索は終了。
2. それでも include_path が要るなら エントリポイント 1 箇所に閉じ込める（グローバル副作用の可視化）。
3. パスは 絶対パス + realpath() で正規化。相対パスはデプロイ先差異で地雷化しやすい。
4. 追加パスが増えすぎると I/O が増え性能劣化。10 本超えたら autoload へ切り替えを検討。

まとめ

include_path の動的変更は「短期的な便利さ」と「長期的な負債」のトレードオフ。

• 一時的な小スクリプト → set_include_path() で済む
• 継続運用・チーム開発 → Composer autoload + 名前空間へ段階移行

“昔の便利 hack” を いつ・どこで止めるか を設計に刻むと、あとで苦しまなくて済みます。

サンプルコード — 最小オレオレ autoloader

<?php
spl_autoload_register(function ($class) {
    $path = __DIR__ . '/lib/' . strtr($class, '\\', '/') . '.php';
    if (file_exists($path)) require $path;
});

将来的にはこの 10 行を composer.json の autoload セクションに置き換えるだけで、本格運用への橋渡しが完了します。

FAQ