トーク

Webプログラミングに欠かせない「正規表現」。でも、なんとなく 「怖い」「よくわからない」 と思っていませんか？
本セッションでは、業務で出そうな易しめの問題から、書いたら地雷なアンチパターン問題まで、全5問のクイズ形式で楽しく学びます！

動機:

1. 正規表現のシンプルな仕組みを伝えたい
2. 「魔法の道具」ではないことを実感してほしい
   • 通常の言語と「同様に」、関心を詰めこめば、それだけメンテナンスが厳しくなる
3. 複雑な正規表現を避けるための現実的な方法を紹介したい
   • 過去の発表で紹介した内容 (https://zenn.dev/shundeveloper/articles/e6405c323c555a) やライブラリなど

対象者:

1. 正規表現が「なんとなく怖い」プログラマー -> 楽しく学びを提供します！
2. 正規表現が大好きなツワモノ -> 目指せ全問正解!!

参照：

• https://zenn.dev/shundeveloper/articles/e6405c323c555a
• https://zenn.dev/shundeveloper/articles/8f74aa69ed9702
• https://zenn.dev/shundeveloper/articles/b5cc85b4d1e7eb

2025年はPHPが公開されてから30周年のようです。おめでたい年ですね。
私は15年以上Webアプリケーションエンジニアとして働いてきたのですが、
これまでPHPでコードを書く機会は経験はありませんでした。
そんな私ですが、PHPが30周年を迎えた今年、転職を機にPHPを使うことになりました。

私はマジメな性格なので、PHPを使うからには、しっかりと基礎を学びたいと思っていました。
そこで、まずはPHPの思想や基礎を学ぶために、PHP1.0から履修することにしました。

PHP1.0の環境を作るのはそれなりに大変でしたが、なんとか環境を用意し、公開当時のPHPをブラウザで表示することができました。
これにより、当時のPHPで実現されていたことや、思想、そして少しのC言語(？)を学ぶことができました。
このような充実感はありつつも、最近のPHPにつながる実務的な知識は身につかなかったので、まだまだ精進が必要です。
ただ、PHP1.0を動かすこと自体は面白い経験だったので、このカンファレンスを良い機会に、この経験をみなさんに共有したいと思いました。

本トークの内容や対象者については、以下のように考えています。

内容

• PHP1.0を実行する環境の作り方
• PHP1.0でのWebページを作り方
• Webページの表示イメージ

対象者

• PHP経験者(初級者〜上級者、レベルを問わないかと思います)
• PHP1.0を知らない方はどなたでも
• C言語の経験者(？？？)

深い話に踏み込むつもりは無く、気軽にどなたでもお聞きいただける内容にしたいと思っています。

対象者

• Laravelを使用している開発者（初級〜中級）
• コード品質向上に関心のあるPHPエンジニア
• 静的解析をこれから導入したいと考えているチーム

セッション概要

型エラーや未定義変数のアクセスなど、実行前にコードの問題を発見できる静的解析ツールは、モダンPHP開発の必須ツールとなっています。本LTでは、Laravel向け静的解析ツール「Larastan」の導入から実践的な活用方法までを5分間で簡潔に解説します。Eloquentモデルやファサードなど、Laravel特有の型安全性課題に対する解決策を中心に、明日から使える実践的なテクニックをお伝えします。

MCP（Model Context Protocol）の仕様が 2025/03/26 に更新され、MCP サーバをステートレスな HTTP サーバとして実装可能になりました。

そうなったら我々 PHPer のフィールドですね？

本トークでは MCP サーバの仕様を説明しながら、フレームワークも Composer さえも使わない、非常に小さな PHP 実装例を紹介します。

このトークで扱う内容

• MCP とは何か？
• MCP サーバの仕様
• Streamable HTTP Transport による MCP サーバの実装例

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

LLM、生成 AI、 MCP といったものに関する

• 具体的な活用事例
• すぐに役に立つ知識

Laravelを使って何か試したいときってあります。自分もあります。試すにあたってLaravelのdocker-composeを自分で書くのも良いですしどこかから拾ってくることもあるでしょう。しかし、毎回同じことしてると飽きてきます。そしてエンジニアというものは新しいものに挑戦してみたくなります。

今回はFrankenとPHPというちょっと変わったアプリサーバーを使ってLaravelを動かしてみようという話しです。
Webサーバー不要な構成が可能なのか、そしていつもと違う構成でも今まで通り動かせるのか、動かせないのかを紹介します。

話す内容
・ざっとFrankenPHPの概要
・FrankenPHPでLaravelを動かす
・FrankenPHPで動くLaravelプロジェクトが今まで通り使えるのか、使えないのか

皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか？僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマは主にPHPやReactなど、日々の学びや実践で得た知見です。

「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。

お話しする内容：
• どんな内容の記事を書いたのか（例：PHPのTipsなど）
• 毎日投稿して感じたメリット（知識の定着、反応がもらえる楽しさなど）
• デメリットや大変だったこと（ネタ切れ、モチベ維持など）
• 投稿を通して得られた成長
• やってみて感じた素直な感想

アウトプットって実際どうなの？毎日投稿ってどうやるの？といった疑問に、僕なりの答えを届けられたらと思います。
「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！

「パフォーマンス調査をしたら凄まじい数のクエリが発行されていた」という経験、ありませんか？
私自身、重いバッチの調査でRDSのPerformance Insightsを見てひっくり返ったことがあります。

これが有名な「N+1問題」ですが、バッチやCSV出力といった大きめのデータ処理で陥りやすい問題の代表例かと思います。
その一因として、Laravel標準のORMであるEloquentでは、リレーション取得をループすることで意図せず大量のクエリが発行されてしまうことが挙げられます。

一方で対策は比較的簡単で、withメソッドを使用してEagerロードさせることで、リレーションデータも1回のクエリで取得することができます。
しかし、安易に「親データの取得時にwithメソッドを呼び出せば解決」と考えていると、思わぬ罠に嵌まる可能性があります。

本LTでは私の失敗を出発点として、Eagerロードさせる上での注意点からEloquentのリレーションの仕組みまでお話しします。

トピック

• N+1問題とEagerロード
• 動的プロパティ（$user->posts）とリレーションメソッド（$user->posts()）

PHPに出会ってまもなく遭遇した奇妙なコード「$$」
まるで変数名が意思を持ち、少し不思議な動きを見せるその子は可変変数と呼ばれます。
本LTでは、可変変数について「変数名が踊り出す」とは一体どういうことなのか、PHP初心者の目線で簡単な例を通して、その基本的な仕組みを紐解きます。
便利な機能にも落とし穴はつきものです。可変変数を使うと、なぜコードが分かりにくくなってしまうのか、本当に使い所はないのか？について発表します！

対象者
・PHP初心者
・変数という概念は理解しているが、可変変数についてはまだ知らない方
・可変変数の使い所がわからない方

昨今のWebサービス運用において、セキュリティ対策の重要性は増しています。特にPHPで構築されたアプリケーションでは、ユーザーからの入力値処理やファイル操作に関連する脆弱性が問題となりやすく、実際に悪用される事例も少なくありません。

私たちは昨年、社内で大規模なペネトレーションテストを実施し、多数のPHPアプリケーションに潜むセキュリティ上のリスクを明らかにしました。その中で特に影響度の高い以下の3つの脆弱性に対して具体的な対応を行いました。

• ローカルファイルインクルージョン
• 認可制御の不備
• ディレクトリトラバーサル

本セッションでは、これらの脆弱性に対し、具体的にどのようなPHPコードの修正・設計変更を行い、リスクを根本から排除したかを詳細に解説します。認可制御に関する実践的な実装パターンや、安全なファイル操作のベストプラクティスについても触れ、現場のPHP開発者が自らのサービスで即座に活用できる具体的ノウハウを共有します。

セッションを通じて、PHPアプリケーションのセキュリティレベルを高め、実際の攻撃を未然に防ぐための効果的な対応策を持ち帰っていただけることを目的としています。

DB負荷問題に直面した時、インデックス、クエリチューニング、キャッシュ… 私たちは反射的に技術的な解決策を探しがちです。
しかし、本LTでは「ちょっと待ってください！その負荷、本当に技術だけで解決すべき問題ですか？」と問いかけます。
私たちがアプリのタイムライン機能で経験した、深刻なDB負荷との戦い。
そこで見出したのは、技術的な複雑化に頼るのではなく、「仕様そのものを見直す」という、シンプルかつ強力な解決策でした。

本トークでは以下の内容をお話します

• なぜ私たちが技術的対策の前に「仕様変更」に踏み切ったのか
• その結果、いかにDB負荷を劇的に削減できたのか（嬉しいことにUXも向上しました！）
• 仕様変更という負荷対策のアプローチについて

対象者:

• DB負荷をはじめとするパフォーマンス問題に悩むWebアプリケーションエンジニア
• 要件定義や仕様策定の段階からパフォーマンスを意識したい方
• プロダクトの持続可能性とユーザー体験の両立を目指すプロダクトマネージャー

DB負荷対策の引き出しに、技術的アプローチと並ぶ選択肢として「仕様変更」を加えることの有効性を、具体的な事例と共にご紹介します。