トーク

概要

PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。

本トークではtblsの便利な機能の紹介や、実際に運用している時に得られた知見、AIによるSQL生成などのTipsを紹介します。

ターゲット

• ドキュメントの自動生成やCIによる運用改善に興味のある方
• チーム内でのスキーマ共有・認知コストを下げたいと考えている方

概要

2025年現在、生成AI関連のソフトウェアは次々と登場しており、PHPerとしてもこの波に乗り遅れるわけにはいきません。
業務効率化や開発生産性の向上を目指すうえで、AIの活用はもはや無視できない選択肢となっています。

とはいえ、AIまわりのトレンドは変化が激しく、2週間もあれば新しい技術やサービスが登場するような状況です。
何から手を付けていいのかわからず、情報収集に疲れてしまっている方も多いのではないでしょうか。

本登壇では、ChatGPTのような有名サービスから、話題にならないツールまで、幅広く紹介します。
実際の事例を交えながら、「PHPerが今、AIとどう向き合うべきか」を具体的にお伝えします。

ターゲット

• AIに興味はあるけれど、何から始めればいいか迷っている方
• 最新ツールを業務に取り入れて、開発を効率化したいと考えている方

概要

Laravel開発でおなじみのコレクション操作、その裏側に潜む「yield」の力を最大限に引き出すのがLazyCollectionです。

本トークでは、PHPのyield構文の動作原理を紐解きつつ、なぜLazyCollectionが高速でメモリ効率が良いのか、Collectionとの違いについて内部の仕組みを追いながら丁寧に解説します。
また、実際に現場で使われているユースケースやテクニックについても紹介します。

ターゲット

• 大規模なデータを扱っている人
• ライブラリや処理系の実装から理解をしたい人

近年、データベースのパスワードを定期的に更新することをセキュリティ要件として課す組織が増えています。
しかし、対象となるデータベースが多くなるほど手動での更新作業は難しくなります。

AWS Secrets Manager の自動ローテーション機能を使えば運用を自動化できますが、シークレットをキャッシュする仕組みを組み込む際、PHP アプリケーション側の実装が煩雑になりやすいという課題があります。
本セッションでは、この問題を解決するために、PHP から Secrets Manager の交代ユーザー方式を利用して安全かつ効率的にパスワードローテーションを行う実装パターンを紹介します。

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しいのですが近年のコンピュータの高速化はすべてキャッシュによるものと言っても過言ではないぐらいキャッシュは重要な技術です。

このトークでは「なぜキャッシュメモリは速いのか」の説明から、なぜキャッシュが必須の存在なのか、そしてキャッシュが引き起こすCPUの脆弱性について初心者の方にもわかりやすくご説明します。

コンピュータアーキテクチャの勉強、というよりはキャッシュを取り巻くハートウォーミングストーリーを聴きに来るつもりでいらしてください。きっと「CPU脆弱性って言っても思ったより難しくないな」「おもしろいな」と思って頂けると思います。

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

私はEM2年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後の成長にあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションではそのような状況に対応するため、繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

PHPは基本的にシングルスレッドで動作します。そのため、並列処理は得意ではありません。
外部APIを複数叩くようなWebアプリケーションを作ろうと思った場合、1つずつ外部APIのレスポンスを待っていたのでは、処理完了に時間がかかりすぎてしまいます。

PHP製のHTTPクライアントライブラリであるGuzzleでは、非同期リクエストがサポートされており、複数のHTTPリクエストを同時に投げることができます。

並列処理が苦手なはずのPHPで、なぜそんなことが可能なのでしょうか？
このセッションではGuzzleのソースコードを紐解きながら、非同期リクエストがどのように実現されているのか、Guzzleに何ができて何ができないのかを見ていきます。

PHP8へのメジャーアップデートに挑戦した際、PHPUnitのメジャーアップデート対応など、久しぶりにPHPを触るにしては越えるべきハードルが複数ありました。
ハードルを越えるためにCursor / Claudeを活用して調査や試行錯誤を試みた際の経験を紹介します。

私が担当しているメール共有サービスのメールディーラーは2001年にローンチしましたが、
プログラム構造の陳腐化がリリースを行うごとに進み、いわゆる「スパゲッティコード」が散在し、
それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能が動作しなくなる致命的な障害が発生しました。

これらの対策としてE2Eテストを導入しそれを自動化しました。

E2Eテストを導入したことで、致命的な障害が防げたか？など得られた効果や
テストコードの実装やテストケースの作成における工夫ポイントなど、可能な限り具体的に説明いたします。

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

開発に当たり、メールディーラーで初めてβ版をコンテナで構築し、
お客様にご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減や負荷分散を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSやコンテナは新しい技術ではありませんが、メールディーラーは全機能が一つのサーバに実装されており、
WebサーバとDBがひとつのサーバに集約されているため、導入には苦労しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
可能な限り事例を交えて説明いたします。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先では、PHPを使ったアプリケーションを開発、運用していました。
ただ、チームの状況を見てみると鳴り響くアラートの対応に疲弊していました。
異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• 問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• 調査から対応するまでのリードタイムが長い

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• アラート対応が属人化しないようなアプリケーション設計、チーム作りをしたい方

想定聴講者

• センシティブな値を扱うシステムの開発をしている人
• テストだけでは挙動の担保に不安で、リファクタリングに踏み切れない人

話すこと

• 安全にリファクタリングする方法
• テスト以外で挙動が変わらないことを担保する方法

説明

私たちの会計システムには、取り扱いを誤ると大きな問題につながる金額などのセンシティブな値が存在します。
これらのコードのリファクタリングは安易に手を加えるには不安があり、例えテストがあってもなかなか手をつけられません。

本セッションでは、私が実際に行った"安全な"リファクタリングの手順とその方法についてお話します。

WordPressはPHPで動作するOSSの1つで、多くのウェブサイトにて現在も利活用されています。しかし多様化するウェブサイトの要件に対応するため、プラグインやfunctions.phpへのコード追加による複雑なカスタマイズが施され、保守性が悪化しているケースも少なくありません。

「コンテンツを快適に発信できる場所」というCMS本来の力を活かしつつ、アップデートの手間やアプリケーションの複雑化による負荷増加などを回避するための方法として、「クラウドサービスへのオフロード」を提案します。

セッションでは、AWSやCloudflareなどのサービスが持つフルマネージドな機能を活用し、大規模なウェブサイトの構成をシンプルかつアップデートしやすい形にする方法を、「サイト内検索」「検索エンジン最適化」「アクセス集中対策のトレードオフ」の3点から紹介します。

純粋関数(pure function)という言葉を聞いたことはありますか？ 簡単にいうと、同じ引数を渡せば必ず同じ結果を返す関数のことで、しばしば数学的な関数とも説明されます。

同じ引数で同じ結果ということは確実な再現性があるということで、「純粋」の概念を知って純粋と不純な処理を切り分けられれば、コードを見通しよく、テストしやすいコードにすることもできます。

言葉をトークでは「純粋」および「副作用」という概念について学び、コードを改善するための手掛かりを学びます。

開発が終わってしまったテストフレームワークをリプレイスした事例を元に、技術的負債にどうやって戦ったのかを紹介します。

トーク内容（予定）

• 具体的な課題
  • 開発終了したフレームワークがもたらしていた具体的な課題（メンテナンスコスト、実行速度、新機能への追従困難など）
• 立てた戦略
  • 段階的移行か一括移行か、手動か自動か
• リファクタリングツールの検討
  • rector の紹介
• 得られた成果

最近弊社ではmcpというワードをちらほら見かけます。
そうだ、phpでmcpを作ってみよう！
でも、phpにはmcpのsdkがありません！！😨

mcpとはなんぞや？から、どういうことをすればmcpができるのか？

※まだ何も着手していないので、どこまで紹介できるかわかりませんが
全力でphp&mcpについて紹介したいと思います！

本トークでは、障害対応が特定のメンバーに集中していた状態を見直し、チームで対応できる体制を構築するために取り組んだ内容を紹介します。

私たちは、レガシーな PHP アプリケーションを日々運用しています。
その中で、障害対応が属人化し、特定の人に負担が偏ることが課題となっていました。

この課題に対して以下のような取り組みを行いました。

• 障害対応の予行練習
• 障害振り返り会の実施
• PagerDuty を用いたローテーション制の導入

これらの取り組みにより、障害対応の対応手順やナレッジがチーム内に共有され、属人化から脱却しつつあります。
似たような課題を抱える方にとって、何かしらのヒントになれば嬉しく思います。

私のチームが運用するPHPサービスは、全てがEC2で動作し、オートスケーリングにも対応していないレガシーな構成です。
さらに、Laravel・Zend Framework・Yiiという3種類のフレームワークが共存し、構成は複雑を極めています。
TerraformによるIaC導入を進めた私は、社内勉強会中に操作を誤り、本番環境を壊してしまい、サービスが一時停止する事態に。
このトークでは、構成管理が属人化したPHP環境にIaCを導入する中での失敗と学び、環境差異や大量のバッチ処理など泥臭い現場で起きた苦労、そして再発防止に向けた取り組みを共有します。
理想と現実のギャップに悩むPHPerの、生々しい挑戦の記録です。

Laravel 11/12に移行して「Handlerクラスがなくなった！どう構成すべき？」と悩んだ方も多いはず。
例外処理の責任の境界が曖昧になっていませんか？
本セッションでは、例外設計・分類・キャッチの責任を明確にし、保守しやすく壊れにくいLaravelアプリケーションの作り方を紹介します。

扱う具体例:
例外をどこでthrowし、どこでキャッチするかを整理する方法
Laravel 11でExceptionHandler相当をサービスごとに定義し、モジュール単位で対応
例外が増えてきたときの管理方法
CIで異常系テストを実行し、例外が正しく処理されているかを確認する仕組み

このセッションで得られること:
各層でのエラー処理の役割を整理し、例外を分類する方法
Laravel 11/12のエラーハンドリング設計のポイント
「例外が増えても怖くない」CI/CDとテストで品質を保つ方法