PHPに未来はあるのか php2shellがあったが
PHPに未来はあるのか
php2shellによってまさかの総理大臣まで巻き込んで、その翌日にはマスコミがめっちゃ騒いでましたね。今回はそんなPHPに未来はあるのかというのをぼく視点で見ていこうかと思います。
まず、リソースの話
はじめに話さなきゃならないのは、PHPのリソースの話だと思います。PHP Foundationでは、2026年10月25日現在、セキュリティに精通している人材を欲しています。また、その財団の現在のメインミッションはセキュリティになっています。
それにもかかわらずphp2shellがAIによって見つかっているので、リソースはセキュリティという非機能要件ですら足りないという自体なわけです。
もちろんながら、新機能などの目を引くものにはリソースが割けられないし、仮に新機能を作ったとしても、新機能のセキュリティを見ていかなければならず、更に財団のリソースはなくなっていきます。
ぼくは何をしているのか
PHPの主にCJK(Chinese, Japanese, Koreanの頭文字)を中心とした文字コード拡張の、mbstringという拡張のメンテナーをやらせていただいています。mbstring自体はUnicodeをベースにしているため、一応全世界の文字を扱うことができますが、制限もあります。
ただ、長年のメンテナンスと最近の大規模オーバーホールによってバグが少なく、高速に動く拡張であると思います。
mbstringとgrapheme関数
その一方で、mbstringの機能拡張は、mb_trim関数とmb_ucfirst関数を最後に新機能が作れていません。理由としては、mbstringがUnicodeを1コードポイントで扱うということにあって、本当のUnicodeは複数コードポイントを扱えるという点にあります。
そして、その複数のコードポイントを扱えるという関数群がgrapheme関数です。グラフィムとかグラフェムとか言ってます。日本語では書記素クラスターといいます。
これを使うと、例えば家族（👨👨👦👦）の絵文字があったときに、バックスペースをしたときに一人ずつ減っていくとかいうことがなく正しく処理ができます。絵文字の他にもたとえばト゚（アイヌ語でトゥの表現）などの濁音、半濁音を分割するときもgrapheme関数を使うと正しく処理ができます。
そういった関数が最近では好まれていて、grapheme関数を提案することが多くなりました。したがってmbstringが提案しづらくなっていて難しいと感じています。
なぜUnicodeなのか
どうしてぼくがUnicodeに重点的に置いているのかというと、mbstringを重点的に見てたのもありますが、他の言語より将来のUnicode対応に先手を打っておきたいというのが思惑としてあります。なお、一番Unicodeの対応が進んでいるというか素晴らしいと評価されるのはSwiftだと思います。理由はStringがデフォルトで書記素クラスター単位だからです。
日本の事情
日本では、Unicode 16.0にて文字情報基盤の成果が反映されました。これによって、ある程度日本の漢字は網羅されるようになりました。しかしながら、まだ雪の字のヨの部分の真ん中の棒が長いなどの字に対応しておらず、その漢字を使っている人は雪の字に「縮退」されています。なお、行政のシステムでは、ちゃんとその字の形が収録されているとなっています。
その「縮退」元つまり雪のヨの部分の真ん中が長いとか、そういう収録しきっていない部分を現在では行政事務標準文字（MJ+）として収録しようとしている、というふうに認識しています。これができると全国共通でそのヨの真ん中が長い雪の漢字など、細かな字体も収録されるはずです。
というように、おそらくこれからもPHP問わずUnicodeは無限に広がりを見せているようにみえるため、Unicodeに重点を置いているわけであります。
更にちょっと話をそらすと、人によってUnicodeの解釈は異なります。例えば、漢字統合、みなさんがよく言う中華フォントといいわれるHan Unification(CJK統合漢字)があるのに、先程話した文字情報基盤や行政事務標準文字のような細かな字体のこだわりにこだわったりと、ある人から見たら矛盾しているとも見えますし、ある人から見たら統合されているのはルールだから合っていると見えます（なおぼくは前者側です）。
これからはどうなる？
まず、プログラミング言語のPHPとしては、最初に話した通り、セキュリティに重点を置いており、大きな改善はボランティアベースになってしまっているし、改善が発生したらそれもセキュリティを見ていかなければならないというふうに見ています。
なので、いわゆるモダンな言語の方を見るとかたや型安全とか、非同期処理とか、まあぼくもしらないモダンな機能を積んだ言語が好まれていることも知っています。知っていますが、お話した通りの開発リソース的にも、みなさんが抱いているイメージ的にも、多分変えられないのがPHPでしょう。
しかしながら、今回の騒動で良くも悪くもたくさんのシステムがPHPで動いていることがわかり、それが止まったことで混乱もしました。影の下で支えていくことになるのかなと思います。
では、AIの台頭でプログラミング言語が統一されるとか、そういう方向だとどうでしょう。ぼくは人々が何を欲しているのかによるとも思っていて、それをすべて満たすプログラミング言語は銀の弾丸であるとも思うので結局不可能ではないかとも感じています。ぼくがUnicodeに備えて置かなければいけないだろうと思っているのと同様に、皆思っていることは違います。広がることはあれど縮まることは考えにくいです。
ただ、システムをリプレイスしました、結果としてPHPから他の言語に移りました、とか、今回のPHPの脆弱性を受けてAIで作り直しました、結果として他の言語に移りましたとなってもそれは良いことであり、ネガティブには思っていません。
PHPは個人的には文字列に強い言語なのかなと思っています。確かに、今回の件ではメモリ安全の話（longjmpの類）でしたが、本来はメモリを意識するということはしにくい言語であるはずです（memory_limitとかあるけど）。
これからも、ある程度Webを支えていく言語であるとは思います。
