Quine とは、自分自身のソースコードと一致する文字列を出力するようなプログラムのことです。
PHP なら、

$ php a.php > output.txt

と実行したとき、output.txt と a.php が完全に一致するような a.php を「Quine」と呼びます。
一見すると不可能にすら思えますが、実のところほとんどの言語で簡単に書くことができます。

この記事では、基本的な Quine の書き方をいくつか説明した後、それを応用して更に面白い挙動をする Quine を書く方法について紹介します。

話すこと

• Quine とは
• Quine の作り方
• 応用 Quine
  • Quine アスキーアート
  • 変化する Quine

<?eval($s='printf("<?eval(\$s=%c%s%c);\n",39,$s,39);');

PHPerKaigi 2026 楽しかったですかーー！！！ ＼全員「はーーい！！」／

楽しかった思い出を残しつつ、学んだことを今後の成長に結びつけましょう！
このパンフレット記事では、PHPerKaigiを含むカンファレンスに参加したあとにすぐにでも行える、是非やって欲しい事を紹介します。

個人で

1. 発表を見返してみよう
2. ブログを書いてみよう

会社で

1. 同僚に発表をオススメしてみよう
2. 振り返り会をやってみよう

FrankenPHPをご存知でしょうか？（前回のPHPerKaigi 2025に参加された方はご存知かもしれません）

公式サイトによると "「Go」で書かれたモダンな「PHP」アプリサーバー" だそうです。
どういうことでしょう？？？

「CaddyにPHP実行環境を組み込んでいる」 ... あ、Caddy知ってる。

あ、そういえば私Goチョットヨメル。

ということで、FrankenPHPを全く知らない、PHPerなGopherがFrankenPHPソースコードリーディングをしていきます。
目標は「HTTPリクエストから$_POST までを読み解く」！！

果たしてPHPまで辿り着けるのか？（筆者が）苦手とするCgoの壁を超えることができるのか？

git clone https://github.com/php/frankenphp.git # ！！！

（注意：これはソースコードリーディング読み物です。いちソフトウェアエンジニアがどうやってコードを読み解いて目的を達成するのかを楽しむものとなります。FrankenPHPを正しく理解したい人は他のドキュメントを参照しましょう）

この現代でAIも盛んに使われる用になった中、「この言語じゃないとダメな理由」というのはかなり無くなってきてる気がします。

逆に言えば、言語の多様性がどんどん高まっている状況。
でもそうなってくると、出てくる一つの疑問「なんでPHPを使う必要があるのか？」
これを聞かれた時に「いや、それはね・・・」とかっこよく説明したいですよね。
欲を言えば、もうこれを見せるだけで終わらせられるような記事が欲しいですよね。

今回のPHPerKaigiのパンフレットはもれなく持ち帰りましょう。
そして、このパンフレットに書かれた記事を見せて「見てみて、こんなメリットがあるよ！」とプレゼンしましょう。
そのための記事を提供します。

PHPStanは簡単に使いはじめることができるツールですが、「きちんと」型をつけるのは案外簡単ではありません。
今回の記事では、これまで紹介してきたPHPStanの基礎知識を前提として、より具体的なプラクティスを紹介します。

PHPStanクイックガイド https://zenn.dev/pixiv/articles/7467448592862e
キミにも作れるPHPStan拡張 https://zenn.dev/pixiv/articles/1e6cade978808a
PHPStan 型付けマニュアル https://zenn.dev/pixiv/articles/09ae64aad4a2f6

古典的なPHPはCGIで実行されます。CGIはリクエスト毎にメモリを破棄するモデルとなっており、リクエスト間でのメモリ空間は独立しています。しかし、パフォーマンスに難があります。

Erlang VMもまた、リクエスト毎にメモリを破棄するという点では同じアプローチを取ります。Erlang VMではprocessと呼ばれる軽量なグリーンスレッドを用いて並列分散処理を行い、リクエスト毎にprocessを割り当てて実装するのが一般的です。
PHPのCGIとメモリ管理の考え方は共通していますが、Erlang VMは軽量なprocessにより高いパフォーマンスを実現しています。

Erlang VMは優れた処理系ですが、メジャーな言語であるErlangやElixirは動的型付け言語です。一方、最近v1に到達したGleamは、静的型付けかつシンプルな構文で、ErlangとJavaScriptにコンパイルできます。

本記事ではGleamを用いてWebアプリケーションを実装し、PHPとErlang VMの類似点と相違点を実際に検証します。堅牢なメモリ管理や高度な並列処理など、Erlang VMの魅力を紹介していきます。

抽象構文木: ASTについて、「名前は聞いたことがあるけど、よく知らない」「ASTを使うことで、何が手に入るのかイメージが掴めていない」なんて人も、多いのではないでしょうか。

「ASTの世界」へ入門してみませんか？
この記事では、「木としてコードを扱うこと」を体感して、読者が「ASTの面白さや可能性にワクワクした！」になることを目指します。
定義や原理の解説よりも、「手を動かしながら、自分で何かを作ってみる」に重きを置いた、ハンズオン形式のアプローチをとります。

扱う内容は、「ASTを活用して、PHPのコードを生成する」です。
PHPでASTを扱うためのライブラリである、nikic/php-parserを利用して、「木を組み上げる」と「コードが出来る！！」を体験しましょう。
終わった時には、関数やクラス定義も、ループや条件分岐も、メソッドの呼び出しも、「全ては木になるんだ！」という気になれるはずです。普段のコードも、少し違った形に見えてくるかもしれません。

具体的な内容:

1. ごくごく簡単な「ASTとは何か」の説明
2. nikic/php-parserを動かしてみる・遊んでみる
3. ASTからコードを生成する

本文

「このプロジェクトはPHP 8.3、あっちは8.1、拡張モジュールも違う…」

複数プロジェクトを抱えるPHP開発者にとって、環境管理は悩ましい問題です。
Homebrewでバージョンを切り替えればグローバル環境が汚染され、Dockerを使えばオーバーヘッドでネイティブより動作が遅くなる。

本記事では、第三の選択肢としてパッケージマネージャ「Nix」を紹介します。

Nixは純粋関数型言語で設計されたパッケージマネージャで、「同じ入力からは常に同じ出力」という再現性を保証します。
仮想化を用いずにプロジェクト単位の完全な環境分離を実現し、ネイティブな実行速度を維持したまま、PHPバージョンや拡張モジュールをプロジェクトごとに宣言的に管理できます。

「開発環境構築のIaC(Infrastructure as Code)」を実現するNixで、チーム全員が同一環境で開発できる世界を体験してみませんか。

パンフレット記事に記載すること

• 命令的管理（Homebrew）と宣言的管理（Nix）のアプローチの違い
• Nix Flakesを用いた、PHPバージョン・拡張モジュールの具体的な定義手法
• direnvとの連携による、ディレクトリ移動だけで環境が切り替わるシームレスな開発体験
• Dockerとの比較と使い分けの指針
• etc...

あなたのPHPerKaigiは、今年で何回目ですか？
はじめてのドキドキ、2回目の成長した自分との再会、3回目からの“ただいま”感…。
もしかしたら、毎年皆勤賞で、すっかり“ホーム”になっている人もいるかもしれません。

私自身、PHPerKaigiだけでなく様々なカンファレンスに参加してきましたが、
いつも思うのは「最初にこれ知ってたら、もっと楽しめたのに！」という小さなヒントやコツの存在です。

そこで今回は、私が「最初に知りたかった！」と思った PHPerKaigi の楽しみ方のコツをパンフレットとしてお届けします！

こんなことを書きます！

• ワクワク前準備
• スポンサーブースの歩き方
• セッション＆フィードバックの楽しみ方
• 懇親会で広がる交流のヒント
• 「楽しかった」を広げるブログ術

もちろん、楽しみ方は人それぞれ。
この中からひとつでも「いいな」と感じるものがあれば、あなたのPHPerKaigiに少しだけ取り入れてみてください！！

はじめに

昨年、私はPHPerKaigi 2025のコードゴルフ企画に初参加し、決勝後の“非公式コードゴルフ”で決勝問題に挑んでランキング入りするほど熱中しました。この原体験から「この熱量は社内でも再現できる」と考え、社内向けCodeGolfの内製と運営を開始しました。半年以上の継続運営で見えてきたのは、PHPコードを安全に評価する難しさや、継続参加を生む問題設計といった、本質的ながら意外に複雑な論点でした。
本セッションではどのように社内コードゴルフサービスを構築したか、半年間で実際に出した問題も全部例示しつつ、どう運営をしてどんな反応を得られたかについて話します。

PHP採点基盤で直面した課題

提出コードを隔離実行しつつ無限ループや負荷暴走を防ぎ、公平性を保つ必要がありますが、実際には、「どこまで自由に動かせるべきか」や「安全性をどう確保するか」といった複数の論点が絡み合いました。本セッションではこうした“考えるべきポイント”を整理して紹介します。

問題設計とAI活用で見えたこと

継続参加の鍵は「短く書ける余地」「適度な難易度」「5〜10分で試せる小粒さ」の両立でした。AIに大量生成させることで良い題材の基準が明確になり、PHPの仕様がゴルフ的おもしろさにどう寄与するかも見えてきました。これらを踏まえ、問題設計の観点を紹介します。

運営から得た学び

ランク制によるレベル差吸収、忙しい時期でも取り組める構成、技術的対話が自然に生まれる環境づくりなど、CodeGolfは遊びを超え、組織の技術文化を育てる取り組みになり得ると分かりました。

想定聴講者

• コード実行基盤・サンドボックス設計に関心のある方
• 技術企画や勉強会を推進するエンジニアの方
• AIを教材作成に活用したい方
• CodeGolfを学習文化として活用したい方

PHP を使った Web アプリケーション開発において、多くの場合はサーバーサイドとクライアントサイドで実装が分離されるでしょう。

それらの結節点として、API 仕様を拠り所とするスキーマ駆動開発は

• サーバーサイドとクライアントサイドで独立して開発できる
• 仕様の認識齟齬を防げる
• 型安全に開発できる

といった観点から強力な手法となり得ます。

一方で仕組みを十分に整えないとその恩恵に与れないまま、煩雑さだけを導入してしまうことにもなりかねません。

このトークではスキーマ駆動開発の実践例のひとつとして Symfony と NelmioApiDocBundle の組み合わせを取り上げて

• NelmioApiDocBundle でできること
• 使う上での設定や周辺の設計
• 具体的な API の実装
• NelmioApiDocBundle でできないこと、他の選択肢と比較しての弱み

を解説します。

弊社の主要な検索機能では、Laravel Eloquentを用いたRDS上の検索クエリにおいて、複数テーブルのJOINや複雑なクエリ構造が検索パフォーマンスに影響を及ぼしていました。特に、利用頻度の高いクエリがレイテンシー増加の主因となっていたため、その改善策としてOpenSearchを導入しました。

導入後、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。
また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。

Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。
これらの経験を基に、検索機能改善の実例を紹介します。

このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。

MVC フレームワークが普及してから約20年。Web アプリケーション開発において「層」を分けることは当たり前の「お作法」になりました。

その効果は「関心の分離」というキーワードでよく語られます。しかし、あなたの現場ではその言葉の意味が正しく理解されているでしょうか。そこで分離したい「関心」とは一体なんなのでしょうか。

意味を理解しないまま、フレームワークや流行のアーキテクチャの表層だけをなぞり、雰囲気で「層」を分けていると、次のような事態に陥ります。

• Controller から Repository へデータを右から左へ流すだけの「土管」Service
• DB のスキーマ変更が、なぜかフロントエンドの修正にまで波及してしまう
• ビジネスロジックがあちこちに分散し、調査に時間がかかる

これでは「層」を分ける恩恵を受けられないどころか、コードを複雑化させ、開発速度を落とす無駄なコストが増えるだけです。「層」の分割は、その意図を正しく理解し、適切な「抽象化」によって本当の「関心の分離」を実現することで、初めてその効果を発揮します。

本セッションでは、形骸化しがちなレイヤー設計に意味を取り戻すための考え方を解説します。

こんな人に向けて話します

• なんとなくルールに従って層を分けているけど、面倒なだけに感じている
• 層を分ける理由をきちんと言語化し、後輩にもっと丁寧に説明したい

「このエンドポイント、なんか遅いんだよね」

勘と経験でコードを眺め、怪しそうな箇所を修正する
本番にデプロイして「速くなった気がする」で終わる
あの言葉がよぎります。「推測するな、計測せよ」

Traces・Metrics・Logsの3つのシグナルを収集することで、パフォーマンス改善の景色が一変しました
Tracesでリクエストの流れを可視化し、どのスパンで時間がかかっているか特定する
Metricsでp95/p99レイテンシ、スループット、エラーレートを継続的に監視する
Logsでトレースと紐づけた詳細なコンテキストを取得する
3つのシグナルを相関させることで、ボトルネックの特定から改善効果の検証まで、データに基づいた意思決定ができるようになりました

本セッションでは、PHPアプリケーションに対してテレメトリーシグナルを活用したパフォーマンス改善の具体的な手法をお伝えします
サンプリング戦略、属性設計、Collector構成など、本番運用で直面する課題と解決策も紹介します

勘と経験に頼らず、シグナルが導く改善を始めましょう

• 想定する聴講者
  • パフォーマンス改善を勘と経験で行っている方
  • Observabilityに興味があるがどこから始めればいいかわからない方

PHPerとして働いていると、普段の開発の中や役割が変わるタイミングなど、さまざまなシーンで「思うようにできていない」「期待に応えられていないのでは」と不安を抱く場面は少なくありません。
タスクの優先順位、仕様変更、レビュー文化、ステークホルダー調整など──“自分ではコントロールしきれないこと”は日常の中に多く存在します。

私自身、プログラマからマネージャーへと役割が変わる過程で、無力感や焦りに振り回される時期がありました。
そんな中で助けになったのが「コントロールの三分法」という考え方です。
物事を「コントロールできること」「影響を及ぼせること」「まったくできないこと」に分けて捉えることで、不安な状況でも少しずつ前に進めるようになった感覚があります。

このトークでは、不安や焦りを抱えたときにどのように自分と向き合い、考え方を整えていったのかを共有します。
キャリアステージや役職に関係なく、エンジニアは常に不確実性の中で仕事をしています。
このセッションが、どんな立場の方にとっても「今の状況をどう捉え、どこから前に進むか」を考えるきっかけになれば嬉しいです。

Symfonyは“フレームワークを作るためのフレームワーク”と呼ばれ、Laravelのコアにも採用されています。
そのため、初心者向けの導入説明や上級者向けの抽象概念を獲得するための解説などの知見を聞く機会が多くあります。

また、PHP 5.4で導入されたtrait(特性)も便利な仕組みである一方で、「知ってはいるが、どう活用していいか分からない」という人が多いのではないでしょうか。

本トークでは、Symfonyの拡張しやすい仕組みとtraitの相性に注目し、ストレージアクセスモデル、フォームバリデーション、ページ描画といった領域で、少ないコードで手軽に拡張・調整する実践例を紹介します。
また、trait導入によるインターフェース統一による不具合防止、Doctrineエンティティ、フォームバリデーションや描画の定義の一貫性や安全かつ手軽な変更を実現する方法についても解説します。
そして、これらの事例を足がかりに、traitパターンをアプリ全体に横展開することでチーム開発における安心感と長期運用に耐える拡張性を手軽に実現できることをお伝えします。

このトークで得られる知見

• Symfonyの設計思想に沿ったtraitの活用パターン
• モデルやフォームを少ないコードで手軽かつ安全に変化させる技法
• traitを「どんな場面で選ぶべきか」という実務的な判断基準

このトークの対象者

• Symfonyを日常的に利用している方、または興味を持っている方
• PHPでtraitを知ってはいるが、実務でどう活用すればよいか悩んでいる方
• Symfonyやtraitの活用を通じて、アプリケーション開発を効率化したい方

このトークで扱わない内容

• Symfonyの基本的な使い方

OpenTelemetryプロジェクトはPHP向けにもゼロコード計装を提供しており、アプリケーションのコードを変更せずにトレースなどのシグナルを生成することができます。これにより、手軽にオブザーバビリティを導入することが可能です。しかし、これはPHP8.0以降でなければ動きません。

前半では、OpenTelemetryのゼロコード計装の仕組みを紹介し、なぜこれがPHP8.0以降でなければ動かないのかを明らかにします。具体的には、Zend Engineに新しく追加されたObserver APIの話をします。

後半では、それでもPHP7.4でもトレースを労力少なくOpenTelemetryで計装したい！というニーズにお応えして2つの手法を提案し比較します。すでに公開されているOpenTelemetry eBPF Instrumentationを使った手法と、PHP8向けのOpenTelemetryゼロコード計装のインタフェースに倣って私が自作したextensionを用いる手法です。後者についてはその実現方法や、生成AIを活用したextension実装の進め方についても紹介します。

本セッションを聞くことで、アプリケーションの内部状態を観測可能にするオブザーバビリティを実現する裏側の仕組みを知ることができます。また、すでにサポートが切れているPHP7系から8系にアップグレードしたい開発者が、アップグレードによって影響があるかどうかを知るために7系のうちから必要なオブザーバビリティを担保するための手法について知ることができます。

パフォーマンスチューニングはあらゆるWebアプリにおける重要な関心事です。クエリ最適化、計算量削減、キャッシュ活用など、その手法は多岐に渡ります。しかし、それらの多くは「特定の箇所」を速くするアプローチに留まります。

一方、Webアプリケーションには例外なく、すべてのリクエストに必ず登場する要素があります。—「接続」 です。

• ブラウザ → CDN
• CDN → ロードバランサ
• ロードバランサ → Webサーバ
• Webサーバ → アプリケーションプロキシ
• アプリケーション → データベース / キャッシュ / ストレージ / 外部API

HTTP、TCP、Unixソケット、DB、キャッシュ… 技術は異なっても、接続は必ず発生します。接続の最適化は、特定部位ではなく「全体」を速くする改善点 となり得ます。

本トークでは、

• エッジ最適化（CDN / Keep-Alive / 圧縮 / TLSハンドシェイク）
• Webサーバチューニング（コネクション管理、ソケット、プロセス管理）
• DB接続の最適化（持続接続、接続プール、TLS、パラメータ）

これら、全く別の話題に見える領域を横断し、そこに共通する 接続の基本原理 を解説します。設定例と計測手法を交えながら、点と点を結ぶ「その一瞬」を制する考え方を提示します。

局所最適化を超え、サービス全体のパフォーマンスを左右する「最後の一手」をその手中に。

想定対象者:

• Webアプリの性能をもう一段階引き上げたい、アプリケーションエンジニア
• アプリケーションの性能改善に取り組む、インフラエンジニア
• 「接続」という低レイヤに入門したい、あらゆるエンジニア

サイボウズの Garoon は PHP と MySQL を利用した大規模グループウェアです。
2002 年にパッケージ版の提供を開始し、2011 年からはクラウド版もリリース。
今ではパッケージ版とクラウド版を合わせて 300 万以上のユーザーが利用しています。
しかし、長年支えてきたクラウドの VM ベースの基盤は、運用やスケールの面で限界が見え始めていました。

Garoon チームは、2022 年に Kubernetes（k8s）を軸とした新しいクラウド基盤への移行プロジェクトをスタート。
足掛け4年、2025 年についに全面移行を実現しました。
本セッションでは、Garoon という“巨大に動き続けるレガシー”を、どうやってコンテナ基盤へ移行したのかをドキュメンタリー形式でお話しします。

• なぜ k8s への移行が必要だったのか（VM 運用の限界）
• PHP + Nginx アプリをコンテナ化するための設計判断
• 非同期ジョブシステムを安全に k8s へ移行するための工夫
• “基本は止まらない k8s” で、あえて停止メンテナンスを可能にした技術的アプローチ
• カナリアリリースによる安全でユーザーに気付かれない移行戦略
• 4 年にわたる長期プロジェクトを率いるためのマネジメントとチームづくり
• 移行直前の育休と、チームメンバーに支えられたプロジェクト運営

技術的にも、プロジェクト運営的にも、みなさまに少しでも参考になればと思います。

TLSは、HTTPSなどで普段使用する際に暗号化を担っている技術ですが、私自身、「HTTPSの裏側でいい感じに暗号化してくれるやつ！」くらいの漠然とした理解しか持っていませんでした。

そこで、TLSを理解するために、TLSプロトコルを実装することに挑戦しました。

このトークでは、TLSの基本的な仕組みについて説明し、どのようにTLSを実装したか、そのプロセスについてお話しします。
また、実装を通じて得られた学びや、ソケット通信に触れることの楽しさについても共有します。

話すこと

TLSの仕組み
PHPでどのように実装したか
得られた学び・ソケット通信に触れる楽しさ