PHPの「型」はどこまで戦えるか

PHPの「型」は

どこまで戦えるか

Can PHP Types Still Compete?

Pushing the Limits of Static Analysis.

pixiv Inc.

USAMI Kenta

2026-10-03 #phpcon_ehime PHPカンファレンス愛媛 @愛媛大学 城北キャンパス

みなさまはPHPの無限の可能性が好きですか？

問題です

PHPの型についての質問で正しいものは？(全4問)

1. PHPは型なし言語である

2. PHPには型宣言がある

3. PHPに書く型は実行時に保証されない

4. PHPは静的型付きである

正しいものは？ (複数回答可能)

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

お前誰よ

• うさみけんた (@tadsan) / Zonu.EXE / にゃんだーすわん
• ピクシブ株式会社 Platform Div > WebTechnology Team PHPer
• 2012年末から現職、APIとかCIとかいろいろなところを見つめてきました
• 最近チームが再編されてインフラっぽい仕事もしてます
• Emacs PHP Modeを開発しています (2017年-)
• プログラミング言語にちょっとこだわりのある素人 (spcamp2010)

さて

型がついている#とは

型推論規則に従ってすべての項に矛盾なく型が割り当てられた状態

…ですが何か？

よくわからん

覚えておいてほしい用語

型付け

(Typing)

型付き

(Typed)

型チェッカー

$a = 3;$b = 2;$c = pow($a, $b);

型チェッカー

int

$a = 3;

$b = 2;

$c = pow($a, $b);

型チェッカー

int

int

$a = 3;

$b = 2;

$c = pow($a, $b);

型チェッカー

int

int

$a = 3;

$b = 2;

$c = pow($a, $b);

引数ok

型チェッカー

int

int

$a = 3;

$b = 2;

$c = pow($a, $b);

引数ok

引数ok

型チェッカー

int

int

$a = 3;

$b = 2;

$c = pow($a, $b);

引数ok

引数ok

int

型付け(typing) vs 型付き(typed)

• プログラムを検査して、項(≒ 式, expression)のとりうる状態を

分類するのが型付け(typing)。型を明示しなくても項の種類を特定する具体的な手続きが型推論(type inference)。

• 実行時に値の型チェックを行なうことを、

便宜的に動的型付け(dynamic typing)と呼ぶこともある

• 静的な型付けによってとりうる状態が定まったプログラムのことを

「型付き(typed)」と呼ぶ

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

健全性

(Soundness)

静的解析が通れば実行時に(型に関する)エラーは起こらないという性質

いわゆる「型安全」(type safety)

• 健全性(Soundness)と同じ意味
• 濫用されがちな用語だが、概ね型に関する記述に矛盾がないことを保証でき

るようになっていることを表わしている

• 「健全性がある」 実行したときに、型に関するエラーが起こらないといえる
• 「健全性がない」 実行してみたときに、エラーが起こりかねない
• C言語全般、Javaの「ぬるぽ」、TypeScriptのany/asや配列など

言語が静的か動的かとは[独自研究]

• ある言語の仕様または標準的な処理系によって構造が事前に検証されている

ことが前提になっている言語が静的(型付き)

• 事前検証が前提ではなく、実行時(run-time)に構造が決定されるのが動的
• 一般的にはコンパイラ vs インタプリタに一致するが、必ずしもそうではない
• 静的言語にも多かれ少なかれ動的な機能が存在し、グラデーションは大きい
• 動的言語でもPHP, Python, Ruby, JavaScriptで動的要素が全然違う

TypeScriptにとっての型

• 型宣言をもとに型チェックを行なって、分析情報を報告
• 実行時には型情報は何も残らない
• JavaScriptにコンパイル ≒ 型定義の部分をひっぺがして実行
• Node.js 25.2ではType Strippingで直接実行できるようになった
• 実際にはTypeScript enum など別のコード生成をする機能もある
• 型がついたコードは実行時にはエラーが出ないでほしい(願望)

ファクトチェック

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

型理論から見たPHPインタプリタ

• 型が合わない（Ill-typed）コードであっても、エラーとして弾かれず、

正当なプログラム（構文木）として受理される → 実行時エラー

• 関数は型宣言に拘らず、任意の値を返そうとすることができる
• プロパティは型宣言に拘らず、任意の値を代入しようとすることができる
• ローカル変数に型宣言はなく、任意の型の値を代入可能
• オペコードコンパイラは実行前にプログラムの健全性を「証明」しない

実行時のインタプリタの振る舞い

• PHP処理系(ZendVM)内では、zval構造体に型タグを保持している
• 常に is_int() のような関数で型を識別できる
• 型宣言と反した値が渡されると、キャストまたは実行時エラーが起こる
• いわゆる「強い型付け」であり、実行時に型がとり違えられることはない
• RTTI(実行時型情報)は型理論における(静的な)型ではない
• 言語セマンティクスとしては型なしだが、JITは静的型情報を活用する

ここまでのまとめ

PHPインタプリタは型なしである

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

PHPと型宣言

• 引数などのデータ型を表わす手段としてコメントにPHPDocを書く文化
• PHP 5.xで関数／メソッドのパラメータに「型ヒント」が書けるようになった
• array, callable, クラス名, インターフェイス名だけを書けた
• PHP 7.0で正式に「型宣言」としてスカラー型宣言と戻り値型が記述可能に
• PHP 8.0以降でユニオン型宣言などが機能追加

型宣言がない関数(PHP5)

function add($a, $b) {return $a + $b;}

スカラー型宣言(PHP7)

function add(int $a, int $b): int {return $a + $b;}

スカラー型宣言(PHP7)

int + intって本当にintなの？

function add(int $a, int $b): int {return $a + $b;}

広い値をとるにはfloatが必要

function add(float $a, float $b): float {return $a + $b;}

広い値をとるにはfloatが必要

ひとつの解決策ではあるが… 不必要にfloatを強制するのか

function add(float $a, float $b): float {return $a + $b;}

PHPDocの型注釈(アノテーション)

/*** @param int|float $a* @param int|float $b* @return int|float*/function add($a, $b) {return $a + $b;}

PHPDocの型注釈(アノテーション)

あえて型宣言を省略する

/*** @param int|float $a* @param int|float $b* @return int|float*/function add($a, $b) {return $a + $b;}

ユニオン型宣言 (PHP8.0)

function add(int|float $a, int|float $b): int|float {return $a + $b;}

PHPの型宣言の特徴

• コードごとに declare(strict_types=1); が宣言できる
• 引数とデータ型の種類を厳密にチェックしてTypeErrorを出す
• デフォルト(無宣言)では、 add("1", "2”) を add(1, 2) としてキャスト
• add(“a”, “b”) のような数値ではない文字列はTypeErrorになり安心
• add((int) $a, (int) $b); のようなコードとは安全性のレベルが違う

ここまでのまとめ

PHPに型宣言はある

型宣言された型は口約束ではなく実効性がある

型理論としては型なしだががんばって動作確認するなら実用上ほぼ型付きと認められなくもなくなってきた

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

PHPDocに型を書く文化もある

PHPDocの型注釈(アノテーション)

/*** @param int|float $a* @param int|float $b* @return int|float*/function add($a, $b) {return $a + $b;}

PHPDocの型注釈(アノテーション)

あえて型宣言を省略する

/*** @param int|float $a* @param int|float $b* @return int|float*/function add($a, $b) {return $a + $b;}

いろんなところから湧き出す

型の特定できないデータ

arrayは無限の可能性を秘める

(悪い意味で)

扱う対象が複数になったのに

型に反映されない

型宣言にarrayとしか書かないと

• メソッドに何を渡せばいいのかわからない
• どんな形式の配列を渡しても動くという関数は決して多くない
• 標準関数の count() のようなユーティリティが多め
• プロパティにも何が入ってるのかわからない
• 従来のLaravelは @var array まみれだった
• Laravel 9.xのコードベースでは配列の内部構造に型がついている

配列はひとつ！じゃない！！

• ユーザＩＤがならんだリスト ［123, 456］
• ユーザIDと名前の対応表 [123 => '野比のび太', 234 => '源静香']
• ユーザを表す構造体 ['id' => 123, 'name' => '野比のび太']
• ユーザを表す構造体がならんだリスト

[['id' => 123, 'name' => '野比のび太'],['id' => 234, 'name' => '源静香'],]

配列はひとつ！じゃない！！

list<int>

• ユーザＩＤがならんだリスト ［123, 456］
• ユーザIDと名前の対応表 [123 => '野比のび太', 234 => '源静香']
• ユーザを表す構造体 ['id' => 123, 'name' => '野比のび太']
• ユーザを表す構造体がならんだリスト

[['id' => 123, 'name' => '野比のび太'],['id' => 234, 'name' => '源静香'],]

配列はひとつ！じゃない！！

list<int>

array<int,string>

• ユーザＩＤがならんだリスト ［123, 456］
• ユーザIDと名前の対応表 [123 => '野比のび太', 234 => '源静香']
• ユーザを表す構造体 ['id' => 123, 'name' => '野比のび太']
• ユーザを表す構造体がならんだリスト

[['id' => 123, 'name' => '野比のび太'],['id' => 234, 'name' => '源静香'],]

配列はひとつ！じゃない！！

list<int>

array<int,string>

array{id:int, name:string}

• ユーザＩＤがならんだリスト ［123, 456］
• ユーザIDと名前の対応表 [123 => '野比のび太', 234 => '源静香']
• ユーザを表す構造体 ['id' => 123, 'name' => '野比のび太']
• ユーザを表す構造体がならんだリスト

[['id' => 123, 'name' => '野比のび太'],['id' => 234, 'name' => '源静香'],]

配列はひとつ！じゃない！！

list<int>

array<int,string>

array{id:int, name:string}

• ユーザＩＤがならんだリスト ［123, 456］
• ユーザIDと名前の対応表 [123 => '野比のび太', 234 => '源静香']
• ユーザを表す構造体 ['id' => 123, 'name' => '野比のび太']
• ユーザを表す構造体がならんだリスト

[['id' => 123, 'name' => '野比のび太'],['id' => 234, 'name' => '源静香'],]

list<array{id:int, name:string}>

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

PHPの組み込みの型機能ではどんなに型推論しても静的に型が定まらない

無限の可能性を秘めたarrayを放置するとコード全体のエントロピーが増大しプロジェクトは熱的死を迎える

漸進的型付け

56

型チェックをしたとしても実用的な推論結果にならない(こともある)

PHPStan

$a = ‘foo’;$b = rand() === 1 ? ‘foo’ : ‘bar’;$c = $a + $b;

'foo'PHPStan

$a = ‘foo’;

$b = rand() === 1 ? ‘foo’ : ‘bar’;

$c = $a + $b;

PHPStan

'foo''foo'

$a = ‘foo’;

$b = rand() === 1 ? ‘foo’ : ‘bar’;

$c = $a + $b;

PHPStan

'foo''foo''bar'

$a = ‘foo’;

$b = rand() === 1 ? ‘foo’ : ‘bar’;

$c = $a + $b;

PHPStan

'foo''foo''bar'

$a = ‘foo’;

$b = rand() === 1 ? ‘foo’ : ‘bar’;

$c = $a + $b;

PHPStan

'foo''foo''bar'

$a = ‘foo’;

$b = rand() === 1 ? ‘foo’ : ‘bar’;

$c = $a + $b;

'foo'|'bar'

PHPStan

'foo''foo'

'bar'

$a = ‘foo’;

$b = rand() === 1 ? ‘foo’ : ‘bar’;

$c = $a + $b;

'foo'|'bar'

'foofoo'|'foobar'

PHPStan

$a = 1;$b = 2;$c = $a + $b;

PHPStan

int(1)

$a = 1;

$b = 2;

$c = $a + $b;

PHPStan

int(1)

int(2)

$a = 1;

$b = 2;

$c = $a + $b;

PHPStan

int(1)

int(2)

int(3)

$a = 1;

$b = 2;

$c = $a + $b;

型チェッカー

$json = $_POST['json'];$a = json_decode($json);var_dump($a[‘name']);

mixed型チェッカー

$json = $_POST['json'];

$a = json_decode($json);

var_dump($a[‘name']);

mixed

string欲しいんだけど…型チェッカー

$json = $_POST['json'];

$a = json_decode($json);

var_dump($a[‘name']);

mixed

string欲しいんだけど…型チェッカー

$json = $_POST['json'];

$a = json_decode($json);

var_dump($a[‘name']);

?array|int|float|string|bool

mixed

string欲しいんだけど…型チェッカー

$json = $_POST['json'];

$a = json_decode($json);

var_dump($a[‘name']);

?array|int|float|string|boolこのキーあるの…？

つまり

つまり

そのため動的言語ではテストの重要性が高かった

型は「ありうる」状態を記述する言語

適切に推論できればテストを書くまでもなく変なコードが炙りだせる

パラメータを厳しくするより戻り値を適切に

戻り値が適切に記述されていれば呼び出し側で型をつける必要はない

PHPStanは普通にコードを書いて警告が増加しないレベルが適正

複雑な型を書きまくるのが型付けではない

PHPコードの@returnが足りていない

💡型を書きまくるSKILLを書こう

特にarray-shapeを書きまくる必要が生じる

そこからレベルを上げるには拡張で解決したい

たぶんあんまりよくない

型推論ロジックを記述できる

理屈上は任意の項に型をつけられる

お使いのAIさんと相談しながらサクっと作れる時代になった

やるなら今

LLMにとってプログラミング言語と人間の言語は同列

流暢なコードは効率よく処理しやすい

エントロピーを下げて人とAIに優しい予測可能なコードを育てよう

まとめ

正しいものは？ (複数回答可能)

1. PHPは型なし言語である2. PHPには型宣言がある3. PHPに書く型は実行時に保証されない4. PHPは静的型付きである

正しいものは？ (複数回答可能)

✅ PHPは型なし言語である

✅ PHPには型宣言がある

✅ PHPに書く型は実行時に保証されない

✅ PHPは静的型付きである

考え方によってはすべて正しい

PHPが静的型付きと言える条件

• 静的解析やユニットテストなどのCIチェックした上でデプロイされている
• PHPStan, Psalm, Phan, Magoなど… Lv.maxかどうかは問わない
• ユニットテストで十分なカバレッジのテストが網羅されている
• ツールの種類×プロジェクトが静的に信頼に足る状況にできるかが大きい
• 静的型付きの言語を使っていても本番で健全性がないコードにできる
• PHPは動的言語の中では実行時バリデーションのお蔭で問題が隠れない

AI時代にPHPを使うメンタルモデルについては香川で話した

今度新潟ではちょっと違う形の話をします