Skip to content

やわPHP カタPHP

公開日:

香川県高松市玉藻公園内 披雲閣で開催された『PHPカンファレンス香川2026』でレギュラーセッション(30分)として発表しました。

Download PDF

スライドテキスト

Page 1

やわPHP カタPHP

Al Dente PHP: Finding the Perfect Resilience

pixiv Inc.
USAMI Kenta

2026-05-09 #phpconkagawa

香川県高松市 玉藻公園内 披雲閣

Page 2

お前誰よ

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

Page 3

PHP界隈で型の話を
始めて10年くらい

Page 4

Page 5

レガシープロジェクトの
ウィークポイントは
圧倒的な「未定義挙動」

Page 6

型… ドキュメント…
設計意図…
あらゆる情報が足りない

Page 7

せめて型を固めておけば
静的型付き言語に

移植

しやすくなるのでは…?

Page 8

そろそろ現実が見えてきた

🗓🫠

Page 9

今回のお題

Page 10

型で消耗しないように

Page 11

今回は具体的な
tipsより
考えの話がメイン

Page 12

…………

Page 13

202x年
世界は生成AIの炎に
包まれた!

Page 14

あらゆるコードが生成され
テストは自動化され
すべてのコーディングが
駆逐されたかに見えた

Page 15

だがプログラマは
死滅していなかった!

Page 16

世紀末救世主伝説

<?php

Page 17

……

Page 18

ほんとうに?

Page 19

もう墓穴に足をつっこんでる

自覚がないだけでは?

🪦

Page 20

PHPStan Lv.maxで
消耗してませんか?

Page 21

生成AIによる開発は
1年前とは信じられない
ほど前進した

Page 22

2025年2月

Page 23

大規模言語モデル
生成AI万歳!

Page 24

業務時間中ほとんど
コードを書いていない
という話も珍しくない

Page 25

人間が書かないなら
別に良い言語が あるのでは…?

Page 26

かっこいい言語には
枚挙に暇がない

Page 27

世界には良い言語はいっぱいある

Rust…

C#…

PowerShell…

JavaScript…

Common Lisp…

Java…

Ruby…

F#…

TypeScript…

Python…

Haskell…

Go…

Swift…

Kotlin…

Java…

Smalltalk…

Clojure…

Scheme…

Page 28

今後使うべき
プログラミング言語
#とは

Page 29

言語選択の 重要な要素

Page 30

実行速度が速い?
簡単に書ける?

Page 31

いままでは採用が
開発のボトルネック

Page 32

○○言語を書ける
人が採用市場にいない

Page 33

PHPを書ける人は 割とあちこちに居る

Page 34

書けるがキャリアアップの ためにPHP案件を好んで 請ける人が減ってる…?

Page 35

AIエージェントの力を
借りれば別に詳しくなくても
メンテできる時代に
なってしまった…

Page 36

2025年2月

Page 37

Page 38

mametterさんの実験

  • https://github.com/mame/ai-coding-lang-bench
  • 簡易Gitの仕様書と受け入れテストを用意してClaudeCodeに生成させる
  • 生成させるコードはv1とv2というマイルストーンに分ける
    • SPEC-v1: 基本機能(init, add, commit, log)
    • SPEC-v2: 拡張機能(status, diff, checkout, reset)
  • Ruby, Pythonはプレーン、型あり版を別に計測する

Page 39

mametterさんの結果考察

  • Ruby, Python, JavaScriptの群(型なし)は安定して低コスト
  • Go, Rust, Javaの群も平均すると低コストだが、最悪の場合に上ぶれ
  • Ruby, Pythonの型付き+TypeScriptは、型なしよりも安定しない
  • そのほかの言語は分散が大きく、うまく行く場合と最悪の差が大きい

Page 40

厳密な計測はできてないが
PHP/PHPStanも
似た傾向を示している

Page 41

型は全部捨てろ!
PHPStanやめろ!

Page 42

これが21世紀の

AIファースト開発

😇

Page 43

Page 44

……

Page 45

これでよかったの
だろうか…

Page 46

そもそもPHPは
どんな場面で
使われてきたのか

Page 47

私見

Page 48

重厚長大な
コンパイル言語
IDEのアンチテーゼ

Page 49

LL言語を使えば
シンプルなエディタで
サクサク書けるよ!

Page 50

Perl Python
Ruby PHP

Page 51

型宣言?
そんな機能ないよ?

Page 52

型なんて変数名見れば
わかるだろ…
常識的に考えて

Page 53

スクリプト言語!
アジャイル!

Page 54

そういう時代も
ありました

Page 55

現実は甘くない…

Page 56

2006年のPHP特集誌

Page 57

Page 58

正直つっこみどころ
だらけだが…

Page 59

われわれは20年後の
技術を使いこなす
チート未来人である

Page 60

この記事が
示唆するものは多い

Page 61

欲しかったのは
ガードレール

Page 62

「ありえない」状態を
食い止めるのが
ガードレール

Page 63

動的解析

実行してみて
エラーが出ないか

Page 64

静的解析

コードを分析して
怪しいところがないか

Page 65

ユニットテスト

vs
型チェック

Page 66

「ありえない」状態を
どちらかで食い止めたい

Page 67

「ありえない」状態は
すみやかにしばく

Page 68

過去の定説

型なし言語は
静的検査と相性が悪い

Page 69

型がついている
#とは

Page 70

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

Page 71

型チェッカー

int

int

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

引数ok

引数ok

int

Page 72

PHP処理系はそういう チェックをしないので
「型なし」と呼ばれる

Page 73

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

Page 74

mixed

型チェッカー

string欲しいんだけど…

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

このキーあるの…?

?array|int|float|string|bool

Page 75

つまり

Page 76

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

Page 77

だが… 今は違う!
ギュッ

Page 78

TypeScript
PHPStan

Page 79

単なる
「型書けるようにした版」
ではない

Page 80

型理論
計算機科学の結晶

Page 81

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

Page 82

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

Page 83

むかしのことを
思い出してみよう

Page 84

型なんて変数名見れば
わかるだろ…
常識的に考えて

Page 85

ちっちゃいスクリプト /書き捨てのコードを
書く分には
型なんていらなかった

Page 86

型はコードの規模が
長大になると効く

Page 87

「型なんていらない」の
サイズの閾値が
大きく変わってしまった

Page 88

コード生成ベンチマークは
仕様と受け入れテストが 最初からゴールまで明確

Page 89

型なしRubyの
生成コストが低いのは
非常に理にかなっている

Page 90

生成する段階では
型はいらないというのは
非常に理にかなってる

Page 91

最近ふわっと考えてる仮説
生成されたコードに ガードレールとして
追加で型を敷設する方が
効率がいい?

Page 92

さらなる仮説
コード上に書く型は
型宣言だけに留めた方が
トークン効率が 良いのでは…?

Page 93

このあたりの話題は
もうちょっと探究したい ので、そのうちどこかで

Page 94

ともあれ
普通にコードを書けば 自然に型がついている
状況が理想

Page 95

さて

Page 96

大規模言語モデル

Page 97

得意不得意が
はっきりしている

Page 98

決定論的な処理は
苦手だし
圧倒的に非効率

Page 99

決定論的

=
入力に対して答えが
定められる問題

Page 100

計算はAIに直接
返答させるのではなく コード生成させて実行

Page 101

生成AIにスペースや
改行位置を細かく指示 するのは圧倒的非効率

Page 102

フォーマッターを実行して
常に同じスタイルに
整形されるようにする

Page 103

非決定的な問題を
決定的な土俵に持ち込む

Page 104

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

Page 105

型推論は典型的な
決定論的な計算

Page 106

型のことは
型チェッカーに
やらせる

Page 107

静的解析ツール いろいろある

  • Phan
  • PHPStan
  • Psalm
  • Mago

Page 108

拡張を書きましょう

Page 109

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

Page 110

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

Page 111

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

Page 112

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

Page 113

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

Page 114

やるなら今

Page 115

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

Page 116

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

Page 117

コードに@varを
書いてる場合ではない

Page 118

理想的な変数名は
名前から内容が
自然に想像できて
期待に反しない

Page 119

コードは少ないほど
見通しがよくなる

Page 120

見通しがよいコードほど 人間もAIも理解しやすい

Page 121

ややこしい構造や 紛らわしい名前は
人間もAIも混乱する

Page 122

リーダブルコードが輝く時代

Page 123

蘇鉄の間

Page 124

桐の間