本プロポーザルは保護者が代理で応募しますが、登壇は15歳の息子が行います。

高校受験が終わりゲーム時間が増えました。
友人たちとマインクラフトをいつでもプレイできる共通のワールドが必要となりましたが、24時間使えるワールドを作るには月1000円のサービス料金が必要であきらめました。
その時、父親から自宅のラズベリーパイを使えば同じことができるよ！と言われて構築を始めました。
この発表では、自力でJavaのマイクラサーバーをラズベリーパイに構築する過程と、そこで起きた問題や解決策をお話しします。

次のような話をする予定です

• マインクラフトとは
• マインクラフトサーバーとは
• 私のスキル（中学3年までに学校で学習する内容)
• ラズベリーパイとは
• マイクラサーバーのインストール
• 自宅サーバの注意点
• ネットワークの話

以前、ふとしたことから興味を持ち、「ローカル環境でSSL/TLS証明書を発行して警告表示を出さないようにするアレコレ」という登壇をしたのですが、
この登壇をきっかけに openssl コマンド以外でSSL/TLS証明書を発行する様々なOSS実装があることを知りました。

そこで思ったわけです。「PHPにはOpenSSL関数が準備されているので、PHPでSSL/TLS証明書を発行することができるのでは？」と。
ということで、カンファレンス当日までに「PHPでSSL/TLS証明書の発行ができるのか」を検証し、発表してみようと思います。

この発表を通して、以下のようなキーワードに触れる予定です。

• CSR
• ルート証明書
• 中間証明書
• サーバー証明書
• 自己署名証明書
• CA
• CRL
• openssl コマンドの使い方

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

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

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

話すこと

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

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

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

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

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

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

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

2025年12月にReact2Shellという脆弱性が発見されました。
これはReact.jsの脆弱性で"安全でないデシリアライゼーション"により任意コードが実行されるというものでした。

"安全でないデシリアライゼーション"は我々PHP界でもphpMyAdminやJoomla!, Drupalなど多くのOSSで脆弱性の原因になってきました。

本トークではデシリアライゼーションとは何か、そして"安全でないデシリアライゼーション"とは何か、どうしてそれが脆弱性につながるのかを解説します。

デシリアライゼーションは強力なプログラミングテクニックです。本トークを聞いた方が安心してデシリアライゼーションを使ったコードを書けるようになることを願っています。

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

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

想定観客

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

お話しすること

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

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

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

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

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

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

人口が多ければ，エンジニアや技術好きの人もそれに伴って多くなりますが，地方はそうはいきません．人数が少なくなれば，開催頻度の減少，ネタや話題の枯渇，わかりやすい集まる意味の薄れなどから，コミュニティや勉強会の存在価値に疑問を抱くこともあるかと思います．そうした停滞の状況を「足踏みしている」とネガティブに捉え，虚しさに襲われることはありませんか．また，勉強会等をはじめる前から，そうした徒労がイメージできてしまい，回避するために一歩が踏み出せずにいませんか．
　
そうした停滞の時期を「充電」と呼ぶこともありますが，単なるエネルギーの回復だけではありません．この「足踏み」の期間には，「充電」という語では補いきれない，ポジティブな変化も含まれています．これら「足踏み」がコミュニティにもたらすポジティブな変化を，うどんの「コシ」にあやかって，コミュニティの「コシ」と呼ぶことにします．
　
おいしいうどんに出会うために，必要不可欠な工程の「足踏み」ですが，「足踏み」の最中にうどんの美味しさを感じることはできません．しかし，この工程を経て「コシ」を与えられたうどんは，よい口当たりや歯ざわりをはじめとした豊かな食味を手に入れます．
　
地域の技術コミュニティについても同様に，花形のイベントや刺激的な取り組みだけでなく，停滞の意味で「足踏み」と呼ばれてしまうような活動があるからこそ「コシ」が生まれます．人が集まろうが集まるまいが，日常的な取り組みや地味でも大切な取り組みを続けることで，そのコミュニティの独自の価値観や取り組み姿勢を形成します．
　
本トークセッションでは，活動歴満 13 年をむかえる北海道旭川市のゆるい勉強会，活動歴満 12 年となる北海道富良野市の FuraIT を例に，いわゆる勉強会の常識の外にある，自分たちのためのコミュニティを，どのように作ってきたかをふりかえります．

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

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

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

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

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

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

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

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

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

PHPは長く使われてきたプログラミング言語で、Webの非常に多くの場面で活用されてきました。
PHPの代替となる数多くの言語やフレームワークも提案されているなか、PHP自身やフレームワーク、エコシステムも絶えず改善され、ビジネスで使い続けられるだけの言語としての強度を保っています。

しかしながら、ツールの導入や「型」に囚われすぎ、痛めつけられることで、開発が硬直化することもままあるのではないでしょうか。

このトークでは、ともすればAIの方がうまくPHPを書いてくれる現在において、自我を持って、楽しく自信をもってコシのあるPHPを書くための考え方についてお話しいたします。

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

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

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

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

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

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

こんなこと話します

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

話すこと

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

SREの文化として「プロダクションミーティング」と呼ばれるミーティングがあります。これは定期的に開催され、サービスの安定運用のためにメトリクスや運用状況を確認する場です。
私の所属する会社でも、同様の目的で「パフォーマンスミーティング（パフォミ）」と呼ばれるミーティングを実施していました。

"株式会社スマートバンクでは、サーバーサイド全員で、2週間に1回のパフォーマンスミーティング（パフォミ） を実施しており、全てのサーバーのメトリクスを確認しています。"
https://blog.smartbank.co.jp/entry/2024/12/26/152742

しかし、組織やプロダクトの成長とともに参加メンバーが増え、次第にアジェンダは形骸化し、このミーティングの目的も曖昧になっていきました。
サービスの信頼性を高め、プロダクトの成長を支えるために、私たちはこのミーティングを改めて見直すことにしました。

このセッションでは、形骸化したプロダクションミーティングに改めて「コシ」を据え、定義や目的から見直していった取り組みと、その現在地点について紹介します。
同様にプロダクションミーティングや運用ミーティングの形骸化に悩んでいるチームにとって、見直しのヒントになる内容を共有します。

このセッションで話す予定の話題

• プロダクションミーティングの定義から見直し
• 他社事例を集めてわかったこと
• 我々のプロダクションミーティングの目的やアジェンダの見直し
• 社内向けのAIエージェントとNew Relic MCPを組み合わせてパフォーマンス分析に活用している話
• いくつか出てきた課題とその改善や、改善サイクルの進め方

同様に、プロダクションミーティングや運用ミーティングの形骸化に悩んでいるチームにとって、見直しのヒントとなる実践を共有します。