GNU socialという2008年に生まれたPHP製のX/Twitter系のマイクロブログ型の分散SNSのフリーソフトがある。いろんな歴史的経緯があって、元の著者の手を離れ、複数のメンテナーを転々として、最終的に見捨てられたプロジェクト。
誰にも相手にされず、PHP経験ゼロ、Webアプリ開発経験ゼロ、人なし、金なし、コネなし、スキルなし。ないないづくしで、あるのはハンデだけの絶望的状態。ただの1ユーザーだった私が、この状態から、ここ何年かかけて、最終的にプータロー (無職) になって、この子の自称責任者になった。
ここまでのGNU socialで世界を変える物語の一番重要な始まりの序章を話す。

テクニカルな話は一切ない。あるのは泥臭い話だけ。というか、小手先の技術はネットや対話AIにきいたほうが人より詳しくて正確なことが大半。そんなことよりもっとクリティカルで重要なことがある。何をするか？方向と戦略が全て。

掃いて捨てるほどいるPHP技術者、IT技術者、人間の一人として、自分が世界でやりたいこと、すべきことって何？世界で自分しか理解できていない状態で、サラリーマンとして、組織に所属していて、しがらみ、忖度、組織の論理にまみれた中で、責任取れない立場で、組織のいいなり状態で、本当にやりたいこと・すべきことを邪魔されずにできるのか？
華やかな世界、規範、キャリア、組織・業界・コミュニティー・仲間からの評価・共感。所詮他人が勝手に作った基準。寄付、スポンサー、支援。基準や周囲の共感、理解、土台前提。恵まれた「普通」だからできる。他人・環境依存で弱すぎる。自分しか理解できないのだからどうでもいい話。

誰の力も借りず一人で自立。何のしがらみもなく、誰にも邪魔・指図を受けない「無敵の人」。それがプータロー。
言うのは簡単だがはたしてどうやる？気になったあなたを会場で待ってる。

チームに途中参加し、初見のアプリケーションを前にして「これ、どこから読めばいいんだろう」と立ち止まった経験はありませんか？

私は、技術サポートという仕事柄、すでに稼働している PHP アプリケーションに関わる機会があります。
中には長い歴史を持ち、コード量も多く、当時の設計意図がドキュメントとして残されていないケースもあります。

現場に入ると、こうしたアプリケーションをキャッチアップしていくのですが、
その様子を見ているメンバーの方から「どのようにキャッチアップすれば良いですか？」という質問を受けることがしばしばあります。

重要なポイントを一つ挙げるなら、すべてを理解するのではなく、必要となる箇所を効率よく把握することです。

本セッションでは、特に日々既存のアプリケーションのキャッチアップに課題を感じている若手の方に向けて、
私自身が実際に意識している考え方や、見るポイント、活用している手段などを具体的にご紹介します。

チームで既存アプリケーションの知識をシェアする方法を模索されている方にも言語化のヒントとして持ち帰っていただけると嬉しいです。

あなたの担当するプロジェクト、変更が難しい「モンスター」になっていませんか？

機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎であるSOLID原則への理解不足や誤解にあるかもしれません。

SOLID原則はソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいるせいで理解が難しかったり、誤解が広まってしまっている面があります。

本トークでは、SOLID 原則に含まれる下記の5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。

• 単一責任の原則
• 開放閉鎖の原則
• リスコフの置換原則
• インターフェース分離の原則
• 依存性逆転の原則

このトークを聞けば、難しかったSOLID原則が「いつでも使える便利な武器」へと変わり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

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

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人
• SOLID 原則、理解しているけどどこまでやればいいのか悩んでいる人

deptrac、便利ですよね。
設定ファイルを書いて実行するだけで、アーキテクチャのルール違反を検出してくれる。神ツール。

内部では、一体どんなことが起きているのでしょうか？
考えてみると、私はdeptracのことを何も分かっていなかった──
依存関係をどう収集しているのか。グラフとしてどう表現しているのか。ルールチェックはどうやって…？
「こういう情報を集めて、上手く使っているんだろうな」と想像してみても、実装方法まではピンと来ません。

そして思ったのです。
自分で読んで作って、動かしてみよう！
そうすれば納得感が増すに違いありません。

今の時代、知らないコードを読むのにAIの力を借りないなんて、 嘘 ですよね！
少し前なら「読み解くハードルが高いぞ…」と感じていたものも、挑戦しやすくなりました。
今回は、その力を存分に借りながら、
「どういう技術要素が詰まっているのか」「どういう流れで処理していくのか」をひも解いて、
「deptracもどき」を動かすところまで進めます。

やること

• ステップバイステップで「コードリーディングと小さなコードの実装」を進める
  • 「中身を読む〜動かしてみる」までを、40分で追体験できるように
• deptracの基本的な機能（＝「依存先の解決」と「ルールチェック」）の実装

お届けすること

• 「実際にこんな感じでコードリーディングを進める」という雰囲気
• deptracの内部実装についての知識
• 自分にもできそうだな！という気配

対象者

• コーディング用AIを使いながら、複雑なコードを読むことにチャレンジしてみたい方
• 「雑に作って学ぶ」方式の勉強法が好き、または興味のある方

一般にフレームワークは「便利なツール」として捉えられますが、設計者の視点では、フレームワークの本質は「設計原則にしたがった制約（Constraint）」です。

本セッションでは、登壇者が設計・実装してきた複数のフレームワーク（AOP, DI, REST, 独自ドメイン基盤など）を題材に、これらを「アプリケーション制約」としてどのように機能するか、その効能を考察します。

具体的には以下の3つの視点から「制約」を紐解きます。

依存と関心の制約（DI/AOP）： コードの構造を縛ることで、変更耐性とテスト容易性をどう担保するか。

Web標準の制約（HTTP/REST）： アーキテクチャを標準に準拠させることで、キャッシュやスケーラビリティをどう「自動的」に獲得するか。

ドメインの制約（Temporal Model）： ドメインを静的なデータではなく「時間的変化」として制約することで、AI生成時代におけるモデルの整合性をどう保証するか。

特に、AIによるコード生成が当たり前になる時代において、「何（How）をAIに任せ、何（What）を人間が厳格に定義すべきか」の境界線は、この「制約の設計」にあります。

情報設計（ALPS）から実装へと段階的に制約を与えていく手法を例に、自律的なソフトウェアを構築するための指針を提示します。結論はシンプルです。

「どうでもいいことは流行に従い、重大なことは標準に従い、ドメインのことは自らドメインフレームワークを設計し実装する」

「AIコーディングエージェントを導入すれば開発が加速する」

そう期待して導入したものの、現実は違いました
人によって生成されるコードの品質がバラバラ、アーキテクチャの一貫性が保てない、レビューコストは減るどころか増える一方、これがチーム開発の現実でした

「なんかいい感じにして」で動くのがVibe Codingです。楽しいし確かに動くコードは出てきます。しかし毎日AIガチャを引き続ける日々となり、チーム開発で再現性が出ません
必要なのは【理論】でした

そこでAWSが提唱するAI-DLC（AI-Driven Development Life Cycle）を導入しました
「AIが実行し、人間が監視する」という原則のもと、AIが参照・模倣できる設計資産を整備することで、ドキュメントを「人間が読むもの」から「AIが従うもの」へと再定義します。
Vibeに頼らない、感覚に逃げない、理論で設計し、理論でAIを導く
これらの対策により、誰が使っても一貫したコードが生まれる仕組みを構築し、レビュー指摘の大幅な削減とオンボーディング期間の短縮を実現しました

本セッションでは、AI-DLCを現場で実践するための具体的な手法をお伝えします。
AIコーディングはやればやるほど奥深く興味深いものになります。
ぜひこの機会に理論を軸にしたAIコーディングを実践して、本当に解決したい課題に集中しましょう！

• 想定する聴講者
  • AIコーディングエージェントを導入したが成果が安定しない方
  • AI-DLCを知らない方、導入してみたい方
  • Vibe Codingに限界を感じている方

「CQRSは大規模で複雑なシステム向けのパターンである」

これが一般的な認識です
AWS公式ドキュメントでも「シンプルなCRUDアプリケーションには推奨しない」と明記されています
ではシンプルなシステムにCQRSを選ぶ理由はあるのか、答えはサーバーレスアーキテクチャにありました

Lambda、DynamoDB、DynamoDB Streamsを組み合わせることで、CQRSの複雑さを吸収しながらメリットだけを享受できます
pay-per-useの課金モデルにより、小規模でもコスト負担なく読み書き分離の恩恵を受けられる
将来のスケーラビリティを考慮しつつ、現在は低コストで開始できる設計を実現します
これがシンプルなシステムにCQRSを選ぶ理由です

本セッションではDynamoDBをイベントストアとして活用した実装、Streamsによるリアルタイム同期、冪等性の担保、最終整合性との向き合い方、SQSとDead Letter Queueを用いたエラーハンドリングまで、実際の実装方法について解説します。

シンプルだからCQRSは不要、ではない
シンプルだからこそ、サーバーレスでCQRSを低コストに始められる
その選択肢を持ち帰ってください

• 想定する聴講者
  • CQRSに興味がある人
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでコスト効率と将来の拡張性を両立したい方

国内のPHPコミュニティは、今も活発です。
しかし、10年以上PHPerとして現場を見てきた立場から申し上げると、参加者の年齢分布が静かに、確実に、変わりつつあるのを感じます。
若手の新規参入が減り、このまま放置すれば、PHPという文化そのものがゆるやかに縮んでいく未来を危惧しています（・・・言い過ぎ？）

本トークでは、コミュニティの高齢化が「気のせい」でなく構造的に起きている現象であることを、実例や現場感覚を交えて整理します。なぜ若手がPHPを選ばないのか。なぜ企業も新人をPHPで育てなくなってきたのか。技術面だけでなく、採用市場・教育環境・コミュニティ文化といった複数の視点から“本当の原因”を紐解きます。

その上で、みなさんが今日から現場で実行できる具体的なアクションを提示します。
「あとは現場の人が頑張りましょう」みたいな投げっぱなしの話ではなく、個人・企業・コミュニティのそれぞれができる実践できる施策を聞いて下さい。

話す内容

• 若手がPHPを避ける心理的・構造的ハードルの正体
• 「モダンPHP」を若者に届く形で伝え直す方法
• 初学者にPHPを選んでもらうための教育デザイン
• 企業が採用・研修でやめるべきこと、すぐ始められること
• コミュニティが若手を迎え入れるための環境づくり
• ベテランPHPerが持つ「邪悪な常識」の正体とアップデート手法

「高齢化しているらしいから危機感を持ちましょう」ではもうちょっと止められない状況にあります。
私のトークを聞き終わって、みなさんが会場を出たその瞬間から、何か行動を変えられるようにすることを目的にしています。

念の為にいうと、PHPの言語自体はさすがに廃れないと思っています。
ただし、何もしなければ静かに活気は失われていきます。
会場の皆さんと一緒に、PHPの未来を“作る側”へ回りましょう。

本トークはPHPカンファレンス福岡2025で発表した「Node.jsに頼らずにFrankenPHPでリアルタイムWeb通信を実現する
」（30分）をベースに、動作デモの充実させ、Socket通信やプロセス分離の説明を厚くアップデートしたものです。

概要

従来のPHP環境は1リクエスト1プロセスのモデルであり、長時間接続を維持するソケット通信とは相性が悪く、
リアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
しかしFrankenPHPの登場で取れる選択肢が増えてきました。
この課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは実際に動作するアプリケーションの動作デモを交えながら、Socket通信の様子やプロセス分離の様子を可視化し、解説します。

話すこと

• FrankenPHP (Mercure) を使った実装デモと、PHPスタックのみで完結するメリット
• PHPにおける常時接続の難しさと、ポーリング等の従来構成の限界
• Server-Sent Events(SSE) と WebSocketのソケット通信の基礎と違い
• 通信方向の違いによる技術選定のポイント
• PHPランタイムと通信プロセスのプロセス分離

話さないこと

• Mercure（Hub）の技術詳細
• スケーラビリティ、耐障害性等の非機能要件

概要

PHP8以降、match式の登場に代表される関数型言語の取り込みが進み、マルチパラダイムへと進化してきています。
さらにパイプ演算子の導入により、コーディング体験が大きく変わる局面に来ています。
一時変数の命名に掛かるコストや、多用による可読性の低下によるメンテナンス難易度の上昇、
array_mapに代表される配列操作の深いネストや、Collectionでの型情報がないメソッドチェーンに苦労された方も多いでしょう。
本セッションではパイプ演算子を中心にこのような問題を解決し、
より宣言的でわかりやすいコードを書くための手助けをしつつ、マルチパラダイムに向かうPHPについてお話しします。
オブジェクト指向設計に関数型言語の要素が加わることで、どのように設計の幅が広がり、どのようにコードが変化するのか。
そしてそれらにパイプ演算子がどう関わるのかを、具体的なコード例を交えて解説します。

話すこと

• パイプ演算子の基礎と仕様。従来の記述（ネスト・一時変数）との比較
• パイプ演算子がもたらす可読性と型安全性のメリット
• Enum・match式・パイプ演算子を組み合わせた宣言的なコードの実装例
• RFCも含めた、PHPのマルチパラダイムなコード設計

話さないこと

• パイプ演算子の内部実装
• 厳密な関数型プログラミング理論
• 他の言語との詳細な機能比較

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

コードを書く時に、「文法」って無視できないですよね。
巨大な存在すぎて、「何かそういうもの」「所与のものとして、そう在る」と思ってしまっているフシはありませんか？
しかし、プログラミング言語もソフトウェアです。
私たちが業務や趣味で書いているものと同様に、「仕様があり、それを実装している」に過ぎません。つまり、文法も「仕様に対する実装」と言えるのです。

「最初からある」から「そういうものに見える」のなら、視点を変えるために逆のアプローチを取るのが効くことでしょう。
自分で作るのです！文法を、実装してみましょう。

このトークでは、ドメイン固有言語(DSL)の自作を通じて、「プログラミング言語と文法の関係」に光を当てます。
最後には、文法が「そういうもの」から「仕様と実装があるだけ」と感じられるようになるでしょう。

話すこと

最終的にPHPに変換される、小さなDSLを作成します。
その過程で、「ソースコード(つまり、ただの文字列！)」→「語句に分解された集まり」→「語句同士の連なりである文(構文)」へと変換される手続きと、そこに必要な登場人物を追いかけていきましょう。
字句解析・構文解析といった概念のざっくりとした理解と、文法や言語仕様を読み解くための基礎知識を提供します。

話さないこと

字句解析・構文解析の理論や実装パターンについての網羅的な解説は行いません。「流れを体感する」ことを優先します。
(構文解析器の生成にはパーサージェネレータを利用し、実装における詳細なアルゴリズムは本トークで扱いません。）

代わりに、参考にした書籍等の紹介を発表資料と一緒に展開します。

想定するターゲット

• 言語やパーサーを自作した経験はないが、興味はある方
• YAML、SQL、正規表現などを日常的に使っているが、「作る側」の視点を持ったことがない方