トーク

「新しいクラスやメソッドが定義されたから、旧い方は廃止していきます！」
そんな時に、”Deprecated"を示しますよね。

PHPを使っていく上で、いくつかの方法があります。
「どうやって廃止したいか」によって、その良し悪しが変わるでしょう。
そう考えると、使える武器を整理して増やしておくのは、役に立つかも知れません。

このLTで、複数の”Deprecated"(&& ちょっと違うけど「禁止」をする)の術を紹介します

1. PHPDocの @deprecated tag
2. trigger_error / E_USER_DEPRECATED
3. \Deprecated アトリビュート
4. phpstan-deprecation-rules
5. class_alias と1〜2を組み合わせて新クラスへの移行を促すやつ
6. PHPUnitで --fail-on-deprecation を使う
7. disable_functions

PHP-TUIというフレームワークがありまして、
まだ "currently a work-in-progress" と書かれている通り開発途上ではありますが、
実にワクワクします。

最近ではClaude Codeも普及したり、「TUIアプリ」に触れている時間が増えたな〜という方も多いのではないでしょうか？
「コマンドライン」ベースではなく、ターミナル上に“画面UI”を作って、カーソルで操作したりするようなアプリです。
PHP-TUIは、そんな感じのやつを作るのを助けてくれます ───しかも、PHPで書ける！！！

遊んでみたくなりますよね？
PHPといえばComposerということで、「Composerを使うためのフロントエンド」なんていかがでしょうか。
「パッケージの一覧」メニューがあり、説明やインストール状況を簡単に確認できる。
Composerコマンドより直感的で、IDE等を起動するよりも手軽な、そんなTUIアプリを想像してください。

このLTでは、技術的な詳細はさておき、
フレームワークを理解するための概要(登場人物の紹介程度)を押さえつつ、
「実際にはどんな感じなのか」をデモ中心でお伝えします。

Rector、いい感じで強力なPHPのリファクタリングツールです。
「好きなルールで、めちゃくちゃコードを書き換えられる！！」という経験は、味わうと夢のような心地がします。

素晴らしいのは、「単なる置換では出来ない」もしくは「人知を超えた正規表現でも難しそう」な一括自動修正を、
十分に人間が理解可能なルール記述で サクサクと実現してくれることでしょう。

なぜ、そんな事が可能なのでしょうか？その裏にあるのは、テクノロジーです。
コードを「木構造(AST)」として解釈して、様々な「ルール」を適用していくことで、
置換対象の検出と置換の実行を進めます。

そこで役立つのが Visitorパターン です。
「木」という複雑な繋がりを渡り歩き、1つ1つの「地点」で外から与えられたロジックを適用していきます。
こうした作りが、「適用対象の構造自体や、渡り歩き方の実装には全く手を加えず、ただルールを付け外しできる」という拡張性をもたらします。

このトークでは、
「Rectorって凄いな、面白いな！」というワクワクと、
「ドンピシャでデザインパターンがハマると、こんなに気持ち良いのだな！」というドキドキをお届けします。

話すこと

• ごくごく簡単に「ASTってなんだ」
• Rectorの使い方、できること
• Visitorパターンの概要
• 上記を踏まえた「なぜRectorでVisitorパターンなのか」

想定対象

• Rectorってなんだろう？を知りたい人
• 「Visitorパターンが嬉しい場面」を見届けてみたい人

あなた自身やチームメンバーは、スーパーマンのように頼られる「ヒーロー」になっていませんか？

ここでいうヒーローとは、相談すれば即座に経験に裏打ちされた的確な答えが返ってきて、実装を頼めばすぐに動くものを出してくれ、トラブル時には主導的に解決してくれる、とても頼りになる存在です。
チームメンバーにとってヒーローは心強く、ヒーロー自身も周囲から認められ、頼られることで、気持ちよく働きがいを感じているでしょう。

しかし一方で、その振る舞いが、経験や学びをチームに蓄積させず、他者の成長機会を奪ってしまってはいないでしょうか。

人は「早く終わらせたい」という合理的な理由から、知っていそうな人、つまりヒーローに仕事を集めてしまいます。
その結果、チームとしての経験はヒーロー個人に集中し、ヒーローは指数関数的に成長していく一方で、他のメンバーは十分な経験を得られず、成長が阻害されていきます。

さらに、ヒーローはますます忙しくなり、周囲のマインドも「助けてもらって申し訳ない」から、やがて「いつもみたいに助けてくれるよね」へと変化していきます。
その過程で、自ら考えて学ぼうとする意欲は少しずつ失われていきます。
最終的に待っているのは、チームとしての衰弱です。

本トークでは、持続的なチームを構築するために「ヒーローをやめ、リーダーシップを始める」ための具体的なアプローチとして、

• チームのマインドをどのように変えていくか
• ヒーロー個人の知を、どのようにチームの知へ移転していくか
• その変化を進めるうえでのマネジメント層へのアプローチ

について紹介します。

PHP8.0からFiberという機能が追加されました。

基本的にPHPは同期処理を扱いますが、Fiberという機能を使うことで非同期処理的なことを扱うことができます。
そんなFiberについて、皆さんと共有できればと思います。

皆さんDatabaseのIndexはよく業務でも利用していると思います。
ただ、そのIndex、前任者やAI Agentが付けているからとあまり考えずに設定していたりしていませんか？

本トークではMySQLおよびPostgreSQLに絞って、インデックスの付き方やよくあるIndexの間違いなどを皆さんと共有できればと思います。

本トークで話す内容
・採用されているIndexについて
・インデックスの種類について
・よくあるインデックスの間違い

本トークの対象者
・Databaseのインデックスを雰囲気で触れている方や知らない人

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

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

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

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

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

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

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

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

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

私たちは大きな時代の節目にいます。これまで半世紀以上にわたって続いてきたコーディングのあり方が、大きく変わろうとしています。AIによる開発支援は急速に高度化していますが、そのポテンシャルを最大限に引き出すための開発ワークフローやアーキテクチャには、まだ大きな進化の余地が残されています。 AIエージェントが本質的に力を発揮できる、開発ワークフローそのものの再設計が必要です。

本セッションでは、登壇者が開発してきた app-state-diagram（ALPS）, xdebug-mcp, SemanticLogger の3つのソフトウェアを通じて、AIエージェントと本質的に協働するための設計・実装手法「Semantic Build for Agents」を紹介します。

app-state-diagram（ALPS）はアプリケーションの語彙・構造・状態遷移をプロトコル非依存で定義し、設計時の意味を外部化します。xdebug-mcpは実行トレースやプロファイルといった実行時の事実をAIが直接扱える形で提供します。SemanticLoggerは intent→event→result を JSON Schema とリンクで表現し、なぜその結果になったのかを機械可読に証明します。

これらに共通するのは、人間向け説明ではなく スキーマ・ID・URIによって意味を運搬する設計思想です。本セッションでは、仕様・実装・実行結果をセマンティクスで接続するアーキテクチャと、その実践から得られた知見を共有します。

CIのテストに時間がかかって困る…
時間がかかっていそうなテストの修正や、XDebug無効化などの対策は試したが思ったように短くならない

そんな経験はないでしょうか？

闇雲にテストを修正するのはもう終わりです！

PHPUnitのフック機能を使って、個別のテストにかかっている時間を計測し、それに基づいた改善でテスト時間を約30パーセント削減した事例をお話します。

テストも「推測するな、計測せよ」で改善しましょう

プロダクト開発をしていて、他社のシステムを参考に作ることはないでしょうか？

そんな時、特許権について調べられているでしょうか？（特許権以外にも、実用新案権、意匠権、商標権、著作権などの権利もあります）

他社の特許権を侵害すると、自社製品の販売差し止めや損害賠償請求に発展する場合もあります。

一方で、特許は「発明の保護及び利用を図ることにより、発明を奨励し、もつて産業の発達に寄与することを目的とする」制度でもあります。

ビジネス・プロダクトを守りつつ、公開されている知識をプロダクト作りに活かすために、特許調査について知ってみませんか？

このトークでは、ある仮説を提案します。

技術的負債の、「利率」にあたる部分は開発規模の増加によって見かけ上増える

プロダクトの開発で機能とソースコードが変更されると貸借対照表の借方に新機能によって得られる価値(正味現在価値)が入り、貸方に技術的負債が入ると捉えられます。
この、貸方に入る技術的負債が通常の負債とは異なる性質を持つと言うのが、この仮説の骨子です。

トークでは、貸借対照表や正味現在価値などの用語についても解説を加えます。

この仮説を通して、各チームで
・どの技術的負債をいつどのように解消するか
・個別カスタマイズをすべきかをどう判断するか
・リファクタリングをどのように計画するか
などについて議論を深めるきっかけにしていただくことを目指します。

会計の知識をインストールして、技術的負債というワードに輪郭を与えましょう。

ISUCONをご存知ですか？「いい感じにスピードアップコンテスト」の略で、Webサービスの性能向上を競う技術イベントです。インフラ、アプリケーション、データベースと幅広いスキルが求められ、参加者からは「難しいけど楽しい」という声をよく聞きます。

私もISUCONに興味を持ちながらも、「自分にできるだろうか？」と二の足を踏んでいました。そこで思いついたのが「社内ISUCON」の開催です。本家に挑戦する前に、まずは社内で仲間を集め、一緒にスキルアップしようという作戦です。

本トークでは、社内ISUCONを企画・準備・運営した経験から得たノウハウをお伝えします。

【お話しする内容】
・なぜ社内ISUCONを開催しようと思ったのか
・問題の選定・環境構築のポイント
・参加者募集と当日運営で気をつけたこと
・開催してみて得られた学びと反省点
・次のステップ：本家ISUCONへの挑戦に向けて

このトークが、皆さんの職場でも社内ISUCONを開催するきっかけになれば嬉しいです。

※注意：本プロポーザル提出時点では、社内ISUCONは企画・準備段階です。登壇時には実施完了予定ですが、進捗状況により共有できる内容の範囲が変わる可能性があります。
現時点でスケジュール、取り組む課題までが決まっています。

divだけあればフロントなんてちょちょいのちょいですが、意味のあるHTML書いてみませんか？

AIが発展してきている今、あなたのサイトで情報を得ているのは人間だけじゃなくなっています。
divだけで構築されたサイトはAIが正しく認識できない可能性もあります。

意味のあるHTML（セマンティックHTML）をおさらいして、AIにも人間にも優しいwebサイトを目指してみましょう！

Laravel×Inertia.js構成のSPAで、CSVから5,000件のデータを取得し複数テーブルを参照して表示する処理を実装した結果、ユーザーは真っ白な画面を十数分待つことになってしまいました。

まずEloquentのlazyById()で1,000件ずつ分割処理を試みましたが、すべての処理完了まで画面表示できず、5分待たされます。次にInertia.jsのlazyプロパティを導入したところ、初回表示が短縮され、重い処理は後から非同期で読み込まれるようになり、ユーザー体験は大きく改善しました。

さらにlazyに関して調査を進めると、Inertia.js v2.0で追加された「Deferred Props」という機能に出会いました。実際に導入してみると、lazyよりもパフォーマンスが向上し、コードもシンプルになりました。しかし、なぜDeferredの方が優れているのでしょうか。

本セッションでは、lazy propsとDeferred Propsの違いを内部実装から読み解きます。具体的には、HTTPリクエストの発生タイミング、サーバーサイドでのデータ解決の仕組み、なぜDeferredの方がパフォーマンスが良いのかを、LaravelとInertia.jsのコードベースを追いながら解説します。そして最後に、実践的な使い分けパターンをお伝えします。

このトークは、Inertia.jsを使っているけど遅延読み込み機能を使ったことがない方、v2.0の新機能が気になる方、大量データ表示で困っている方、「なぜ速くなるのか」を理解したい方に是非聞いていただきたいセッションです。

Feature Toggle を使って開発していますか？
Feature Toggle を使って開発をした後使わなくなったトグルを削除していますか？

このトークでは Feature Toggle を導入してから削除するまでどのように運用するといいか話します。

Feature Toggle は開発終わったら削除しようね！

このトークに技術の話はほとんど出てきません。ハウツーでもありません。
プログラミングと出会って25年、ようやくたどり着いた気づきを共有したいです。

技術が好きですか？
もうイヤになりそうなこと、ありませんか？

ぼくはずっと、ある選択をし続けてきました。意識してやっていたわけじゃない。
振り返ってみたら、そうなっていた。
それに気づいたときふと、改めてPHPの生みの親、Rasmus Lerdorfの言葉を読み直し…この気づきは間違いじゃなかったと思えました。

こんな人に聞いてほしいです。

• 新しい技術を追わなきゃと焦っている
• 周りについていくのがやっとで自信がない
• キラキラしたエンジニアにはなれないと思っている

すぐに何かを解決するものではありません。それでも「自分だけじゃない」と少しでも安心してもらえたら。

もしかしたら、ぼくが、ぼくたちがRasmusだ。

近年、PHPには多くの意欲的な言語機能が追加され、ますますコーディングしやすくなっています。
筆者はLispをはじめ、「関数型」と分類されるプログラミング言語について関心を持って取り組んでいますが、それでもPHPと関数型言語には大きな隔たりがあります。

このトークでは、関数型的な観点からの近年のPHPの構文の変化と、それでも関数型言語と見なすには何が足りないのかについて騙ります。

合わせて読みたい： (読まなくていい)

• Lispは関数型言語(ではない) by うさみけんた | トーク | 関数型まつり2025 #fp_matsuri - fortee.jp

「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に興味がある人
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでコスト効率と将来の拡張性を両立したい方

世は大酸化時代！
昨今、さまざまな言語のためのツールチェーンをRustで書き直すムーブメントがあります。

PHPにもMagoというプロジェクトがあり、非常に高品質かつ高機能な製品が既に実用レベルに達しています。
この記事ではMagoの機能について既存の各種フォーマッター・静的解析ツールとの違いを紹介します。