「脆弱性195件、Amazon Linux 2、膨大なデッドコード。これらを一掃するために必要なのは、緻密な計画か、それとも圧倒的な覚悟か。」

2025年、8日間という極限のスケジュールで1人のエンジニアが

• PHP 8.5, Laravel 12へのアップデート
• FrankenPHPの導入
• ECSへの移行
• Node.jsからBunへのリプレイス
  を強行しました。結果として待っていたのは、リリース直後から続く障害の嵐。Stripeの決済停止、メモリリーク、環境変数の欠落……。

このプロジェクトを見守っていた(行っちゃいましょう！とそそのかしてた)PdMの視点で、プロジェクトの全貌と、そこから得られた教訓を赤裸々に共有します。

特にフォーカスするのは、エンジニアが技術的挑戦を完遂するために必要な「PdMのコシの入った謝罪」のあり方です。特定の状況下では、完璧を求めて停滞するよりも、一時的な不具合を受け入れてでも爆速で進化する方が、トータルコストで勝る場合があります。

コシがあるプログラマになるぞ！！と想像してみると、研鑽やインプットが欠かせない気がしますよね。
インプットとして分かりやすい手段に、技術書やビジネス書といった実用書の読書があります。

「本を読みたいと思うものの、なかなか進まない」「これまでの人生で読書の習慣があまり無くて、苦手」なんて人もいるでしょう。
人間が処理できる情報量には限りがありますし、活字や座学に対する向き不向きといった特性は人それぞれに差があります。
とはいっても、手段の1つとして「本を読めるようにする」が使えたら、成長機会が広がる事は間違いありません。

昨年のPHPカンファレンス香川で「読書」に関連したLTをした際に、
ちらっと触れた「本の読み方」「一字一句読むことに拘らない、寧ろ読み流し方を覚える」という点に、
共感や驚きといった反応をいただきました。
そこで、このトークでは、
「本の読み進め方のスタイル」「読み流すとは・どうやるのか」について
簡単な演習のようなものを含みつつ、紹介します。

話すこと

• 本の読み方について考える: いくつかの読書のスタイルについて
• 精読・乱読・積読
• 本の出会い方・選び方

持ち帰れるもの

PHPカンファレンス香川2026が5月前半。
そこから、今年が終わるまでに6ヵ月半。
もし「1日に3冊」や「1週間で10冊」を読めるようになれば、
「今年あと50冊」は全く不可能ではないですよね。
(50っていうと、なんか凄くないですか？)

全くもって「たくさん読めばエラい」なんてことはありませんが、
「もしアナタがそれを望むなら、それができるようになる」というトークを目指します

ASTやオペコードなる単語を聞いたことはある(かも)・・・でも、良くわからないな！！という人に向けたトークです。

人間が読む「PHPで書かれたソースコード」は、最終的にはCPUに理解できるデータへと変換され実行されます。
その間に出てくるのが「AST(抽象構文木)」や「オペコード」です。

ソースコードは分かる。では、ASTやオペコードってどんな感じなの？？に触れてみましょう。

話すこと

• ソースコードがどう変換されていくのか？の全体的な流れ
• ASTってなんだ
• オペコードってなんだ
• ソースコード→AST→オペコードの対応・変換を見てみる
• ASTやオペコードに何がある(利点をもつ・便利)のか、何が無い(不十分、不便)か

※ このトークは、 PHPカンファレンス新潟2025で実施したワークショップの内容を土台に、「聴いて分かる」ように形式・内容をリメイクしたものになります。

プログラミングや設計には「抽象化が大事だな」と言ったり、言われたりする事が多くあります。
今でこそ私も「なるほど」と思えるようになったものの、プログラミングを始めての何年間かは「何が・なぜ、抽象？」とピンと来なくて聞き流して過ごしていました。

このトークは、そんな 「まだ自分の感覚として理解できていない」人を中心的なターゲット として、 「どうして良いのか」を整理 して提供することを目的としたものです。
「抽象」といってもInterfaceやAbstract Classに限らず、メソッドをどう定義するか・変数名はどうするか、といった考え方の土台となる視点を提供します。

主なキーワード

• 抽象: 情報を削ぎ落としたり切り出したりして、簡単にしたもの
• 具体: 抽象に対して、現実との繋ぎ込みのための内容や形を備えたもの
• 構造: 目的に対して機能と形式を備えたもの
• 名前: 「それは何なのか」を(抽象的に)したもの

なぜ、それらのキーワードが大事なのか

このトークでは、「抽象」と向き合うことが「理解を助ける、思考(努力)を楽にする」 ために大事である、という態度を中心に据えます。

自分的にHTTPSの中で一番のコシであるTLSをPHPで実装してみた話をします。

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

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

このトークでは、TLSの基本的な仕組みについて説明し、どのようにTLSを実装したか、そのプロセスと得られた知見についてお話しします。

話すこと

• TLSの仕組み
• PHPでの実装アプローチ
• 実装を通じて得た知見

生成AIは不確実です。
同じ入力でも揺らぎ、時にもっともらしい誤りを出力します。

多くの議論は「どうすればハルシネーションを減らせるか」に向かいます。

生成した結果の揺らぎはなくせるのか。
それとも、前提として受け入れるべきなのか。

しかし本質は、そこではないのではないでしょうか。

また、私たちはいま、何をもって「完成した」と言っているのでしょうか。

コードでしょうか。
実装の正確さでしょうか。
それとも、ある状態が満たされていることなのでしょうか。

そこで、ものごとを構造化することで、生成AIを組み込んでも揺らがない開発手法をお話します。

生成AIは流行かもしれません。
しかし品質の構造は不易です。

本発表ではPHPカンファレンス関西2025で好評をいただいた「階層化自動テスト」の発展形として、
レイヤ別に検証責務を固定し、複数視点から出力を判定する構造を、実際にPHPで検証した事例をもとに解説します。

AGIになっても崩れない、“コシ”のある開発手法をお見せします。

「一口目は最高だと思ったのに、気付けばデロデロでおいしくない……」

これはおいしくないうどんに出会ったときの感想ですが、芯の通っていないコードにも通ずる部分があります。

2026年、AIエージェントという「全自動うどん製造機」を手に入れた私たちは、かつてない速さでうどん……つまりコードを量産できるようになりました。
しかし、我々職人がきちんと芯を通さなければ、出来上がるのはコシのあるうどんではなく、歯応えのないスパゲッティです。

芯の通った設計と戦略は、ほどよい弾力、滑らかな口当たりとのどごし、そして食べ始めから食べ終わりまでおいしさをキープする「コシ」をシステムにもたらします。

AIに丸投げして「まずいスパゲッティ」を量産するのか、AIを相棒に「最後まで美味しいコシのあるうどん」を提供し続けるか。
うどんの聖地香川で、おいしいコードの打ち方、ゆで加減について一緒に考えてみませんか？

話すこと

• AI 時代においしいうどんを出し続けるための設計と戦略
• できたてだけじゃなく、時間が経ってもおいしいうどんの秘訣

「この変数、なんて名前にしよう…」
ソフトウェアエンジニアにとって命名は避けられない重大な意思決定のひとつです。

なぜ命名がそこまで重要なのでしょうか？
それは、命名が単に「ラベルを見つける作業」ではなく、「対象のスコープ（境界線）を定義する」ことだからではないでしょうか。

例えば、とりあえずItemと名付けられたクラス。
最初はただの「商品」を表すはずが、いつの間にか「在庫」や「配送」まで知識を吸い込み、巨大な“神クラス”になってしまった――そんな経験はありませんか？

本セッションでは、エンジニアであり大学で哲学を学ぶ社会人学生の私と一緒に、20世紀の天才哲学者ルートヴィヒ・ウィトゲンシュタインの思想をヒントに「命名」という難問を楽しく再考しましょう！

ウィトゲンシュタインの「私の言語の限界が、私の世界の限界を意味する」という言葉や、「言語ゲーム」の考え方は、DDD（ドメイン駆動設計）のユビキタス言語や境界づけられたコンテキストの話と深い親和性があると思います。

「哲学なんて難しそう…」という方もご安心ください。
学術的な話ではなく、明日の開発が少し楽しくなるような、エンジニア視点でのエッセンスをカジュアルにお話しします。

こんなこと話します

• 言語ゲームとしての命名： チーム内での「共通言語」の重要性について再発見する
• 「写像」としてのコード： 現実世界をどう切り取り、コードに落とし込むか
• ぶっちゃけ編：とはいえいきなり全部に全力投球はムリ！明日現場で使えるテクニックもお届け

「とりあえず」の命名を卒業し、言葉で世界の境界線を引く。
そんな「設計としての命名」の楽しさを、哲学の香りをちょっぴり漂わせながらお届けします。
セッションが終わる頃には、エディタに並ぶコードが昨日と少し違った景色に見えるかもしれません！

「AIに任せると人間が育たない」
その不安は、AIを単なる「手抜き道具」として使うからです。

AI生成コードは一見動きますが、
長年の運用で培われた設計思想やドメイン知識といった「コシ（芯）」が欠落しがちです。
それは将来の変更に耐えられない「伸びきったうどん」のようなものです。

この「コシ」を注入するには深い理解が必要ですが、
歴史あるサービスの重厚なコードを前に、新参者が即実践するのは困難です。
そこで私は、AIを「書く道具」ではなく「読むための専属メンター」として使い倒し、
この壁を突破しました。

本セッションでは、2011年のリリースから15年以上続くサービス（Chatwork）の、
10年選手である独自フレームワークや巨大なレガシーPHPと向き合う現場で私が実践している、
「AIに読ませて、人間が育つ」ための具体的な技術論をお話しします。

【主なトピック】

「読解」の高速化:
複雑怪奇なレガシーコードをClaude Codeに解説させ、ロジックの要点（出汁）を瞬時に掴む「AIリーディング」。

「作法」のコンテキスト化:
チーム独自の規約やレビュー指摘を CLAUDE.md に蓄積し、AIに「チームの流儀」を継続的に学習させる。
その設定ファイル自体が「生きた新人教育マニュアル」となり、人間も自然とルールを内面化するサイクル。

説明責任の徹底:
「AIが書きました」は禁句。人間が完全に腹落ちし、自分の言葉で説明できるまでPRを出さない「鉄の掟」とその効能。

AIは人間をダメにする甘やかし装置ではありません。
正しい使い方をすれば、経験の浅いエンジニアに「熟練の視座」を授ける、最高の教育エンジンになります。
AIという強力な「こね機」を使いこなし、私たち自身が最高の職人になるための生存戦略を共有します。

OAuth2は広く普及した認証基盤ですが、実際のWebアプリケーション開発においては「仕様通りに実装する」だけでは十分とは言えません。
外部API連携にOAuth2を導入する中で、次のような設計課題に直面しました。

• 有効期限のあるアクセストークンの管理
• リフレッシュトークンによる自動更新の設計
• 既存の別認証方式との共存
• 既存ユーザーに影響を与えない導入

本セッションでは、外部API連携にOAuth2を導入した実装経験をもとに、

• ユーザーに再認証を意識させないトークン更新戦略
• 認証方式を抽象化し共存可能にするアーキテクチャ
• 将来的な仕様変更にも耐えられる責務の切り分け

といった具体的な実装判断を共有し、実運用で折れない認証設計をどう構築するかを解説します。

Webアプリケーション開発におけるOAuth2の導入について、「仕様通りに実装する」だけではない、変更に強い「コシ」のある認証基盤の作り方を共有します。

皆さん、ASN.1をご存知ですか？

ASN.1とはX.509証明書や電子署名などのデータ形式の定義に使われている抽象構文記法(Abstract Syntax Notation)です。
ASN.1で定義されたデータはPEM/DERなどの形式でエンコードされます。

証明書や秘密鍵などを作成する際のファイル形式としてPEMやDERといった文字を見たことがある方も多いのではないでしょうか。

「DERはバイナリ形式、PEMはそれをBase64エンコードしたテキスト形式」と説明されることもありますが、ではDERのバイナリデータがどのような形式になっているのか説明できますか？

私は最近「電子署名から内部に記載された情報(署名に使われた証明書の発行者情報や有効期限)を取り出したいな」「仕様を読めばライブラリなどを使わなくても独自実装でパースできるのでは」と思い、調べている内にASN.1の存在を知りました。

ASN.1のデータ定義とそれがどのようにエンコードされるかを理解すればバイナリから欲しい情報を取り出せるようになります。

このトークでは証明書からシリアル番号や発行者情報・有効期限などを取り出す実装を例とし、以下について発表します。

• ASN.1やそのエンコード方法(BER/DER)
• それを踏まえたBER/DER形式のデコードのPHPでの実装例
  • PHPでのバイナリのパース方法
  • バイト列の読み取り・管理
  • ビット演算を用いた特定ビットの判別や複数バイトで構成される値の読み取り

身近にある存在の仕組みを少し深堀りしてみると面白い世界が広がっています。

この発表を通して、色々な仕様に使われているASN.1の面白さ(とややこしさ)に触れてみましょう。

常に最新のセキュリティ更新を取り込み続けるためには、PHPのバージョンアップだけでなく、将来予定されているPHP 9の破壊的変更にも備えておく必要があります。

20年以上開発が続いている巨大なコードベースを持つプロダクトにおいて、使用している静的解析ツールの見直しを進めましたが、長い歴史の中で積み重なったコードとの互換性の課題や解析速度の問題に直面しました。移行作業を進める中でPhanのアップデートもあり、さらにPhanで見つかった一部の問題を自分たちでコントリビュートして解決しました。その結果、継続可能性と現実的な保守コストを踏まえ、引き続きPhanを使うという判断に至りました。

本トークでは、こうした検討と意思決定の過程を踏まえ、PHPのバージョンアップ時に発見した静的解析ツールの問題をOSSへのコントリビューションによって解決した事例や、個人的に注目している高速なMagoの検証例を通じて、巨大で歴史あるコードベースにおける静的解析ツールの効果的な活用法を考察します。

ActiveRecordは爆速開発を支える「手軽さ」の象徴ですが、プロジェクトの成長と共に「DB構造とロジックの密結合」という呪縛を生みます。本セッションでは、クリーンアーキテクチャの理想を掲げ、Laravel Eloquent（ActiveRecord）からDoctrine（DataMapper）への移行を試みる中で私たちが直面している、「手軽さと堅牢さの折り合い」についての葛藤を共有します。

移行の大きな動機は、インフラ層での「Eloquentモデルとドメインモデル」の二重管理による、泥臭い値の詰め直し（インピーダンスミスマッチ）を解消することにありました。DataMapperがマッピングを吸収することで、ドメインは純粋なPOPOとして振る舞い、開発者は「値の移し替え」という苦行から解放されるはずでした。

しかし、そこで待ち受けていたのは、一筋縄ではいかない設計の「コシ」でした。不変条件を守るための「イミュータブルな設計」を目指すと、DataMapperの核心である「Unit of Work（変更検知）」の仕組みと真っ向から衝突します。「手軽さを維持したいが、堅牢さも譲れない」。この両者の間で、私たちは今まさに最適なバランスを模索しています。

・EntityとValue Objectの役割分担をどう定義し直すべきか ・セッターを排しつつ、UoWとも共存できる「制御されたミュータビリティ」の探求 ・ドメインイベントを明示的に扱うことで、設計の透明性をどう確保するか

本セッションでは、現在進行系で理想のアーキテクチャと選定技術の「相性」にどう折り合いをつけ、チームで納得感のある設計を言語化してきた内容を紹介します。「手軽さ」と「堅牢さ」。その間で揺れ動きながら、長く愛されるシステムのための「最高のコシ」を共に考えてみませんか。

全国各地で開催されているPHP系のカンファレンス。
それぞれの地域には、異なった「空気」や「こだわり」があります。

PHPコミュニティは技術だけでなく、人の熱量や思想によって形作られています。
本セッションでは、各地のPHPイベント主催者・実行委員長を招き、表側には見えにくい部分＝「コシ」の作り方に焦点を当てます。

あまり語っていないような「実行委員長の裏側」を掘り下げます:

• 何を大事にしているのか
• 譲れないこだわり・細部へのこだわりは何か
• 他地域のカンファレンスにどんな魅力を感じているか
• 今後行われるカンファレンスの"みどころ"を勝手に語る

参加者は以下のようなエッセンスを持ち帰れます:

• PHPコミュニティの雰囲気がわかる
• 各地域イベントの違いが見える
• 「魅力づくり」の彩色の幅を知る
• 主催者の“コシ”を感じられる

深夜メンテ。
まれであれば遠足気分（？）で楽しかったりしますが、頻繁にあると生活リズムを崩してしまいますし、不慣れな作業なら「もし未知のトラブルに遭遇してサービスを長時間ダウンさせてしまったら・・・」など、不安も尽きません。

本トークでは主にWebアプリケーションのメンテナンスを日中にやるための交渉術や、ユーザー影響を抑えて日中に行うためのテクニックについてご紹介します。

想定観客

• 深夜メンテをしたくない、部下・同僚にさせたくない人

お話しすること

• 深夜メンテをしない合意形成のポイント (お気持ち、リスク、賃金など)
• 落としてはいけない機能と時間を明らかにする
• 後方互換性の確保、並走

JetBrainsのMPSは、外部DSL(ドメイン固有言語)を作成するためのIDEです。
DSLの文法自体を定義し、それをターゲット言語に変換するための仕組みを用意できます。
つまり、「独自の使いやすい文法で書いてもらって、PHPのコードに変換する」ことが可能です。

DSLの利用は、あなたのチームの開発の効率を高めるかも知れません。
余計なことが出来ない・無駄なことを考えなくて良いように、「必要なことにだけ集中する」ための強力なガードレールとして機能します。

必ずしも「独自の文法」を利用する必要はなく、JSONやYAMLを利用したり、あるいはPHPの文法の範疇で書かれた内容でも、多くの場合は事足りるでしょう。
とはいえ、「もっと良い方法」の引き出しがあるに越したことはありません。例えば、非開発者とのコラボレーションの手助けにもなりえます。
(・・・一度はやってみたくなりませんか？)

そして、MPSは普段使っているようなIDEとはかなり様子が違った、
悪く言えばクセが強い、よく言えばクセになるようなIDEです。
公式ドキュメントの表現を借りると、
「テキスト形式を避けることによって他の多くの言語ワークベンチとは一線を画しています。あなたのプログラムは常に AST で表されます。」
と記述されています。ちょっと面白そうだな、と感じませんか？
この独自の世界観を、ちょっと体験できるようなトークをします。

話すこと

「素朴なDSLの作成」を題材としてウォークスルー的に追体験しつつ、MPSとその基本的な概念について紹介します。
今後ふとした時にちょっと便利な武器になるかもしれない、そんな知識を持ち帰ってください。

あなたも Laravel 用のパッケージ（composerライブラリ）を作って公開しませんか？

実際に作成したパッケージを例に、アセットの公開、config や migration の活用、オーバーライド可能な view など、開発者にとって使いやすいライブラリを作るための勘所をご紹介します。