概要

GMO Flatt Security で日々 Web アプリケーションの脆弱性診断に従事する私が、PHP アプリケーションを題材に「攻撃者が脆弱性を見つける瞬間」と「開発者ができる対策ポイント」を紹介します。古くからあるCTFなどでも使われるようなテクニックから、最新のテクニックまで、再現デモとその対策方法を持ち帰っていただきます。

対象者

• PHP などで開発中のエンジニア
• バグバウンティや脆弱性診断に興味をもつ学生・研究者

本セッションから持ち帰れるもの

• PHPで構築されたアプリケーションの特有の脆弱性とその対策方法について
• 実務で役立つチェックリスト

WordPressは柔軟で世界シェアNo.1のCMSであり、適切な運用をすれば安全に活用できます。
しかし、「すべてをWordPressで完結させる」ことにこだわりすぎると、運用負荷が増したり、セキュリティリスクが分散しにくくなることもあります。
本セッションでは、PHPの視点からWordPressのセキュリティ対策を考え、スマートな分散アーキテクチャを提案します。

✔ WordPressはセキュリティ対策を組み込める優れたCMS
✔ プラグインを活用したセキュリティ強化の工夫
✔ サイト全体の安全性を高める分散型アーキテクチャ
✔ ID管理・アクセス制御・WAFなどを適切に組み合わせる方法
✔ WordPressのシンプルな運用を維持しながら、セキュリティを高める手法

「WordPressだからこそできる」安全な運用設計を具体的な事例とともに紹介し、無理なくセキュリティ対策を強化するためのヒントを提供します。WordPressの利便性を最大限に活かしながら、安全で快適な運用を目指しましょう！

"Small is beautiful（小さいものは美しい）"
"Do one thing well（一つのことを、うまくやれ）"

これらはUnix哲学でも有名な格言で、ソフトウェアエンジニアなら聞いたことくらいはあるでしょう
小さく保つために「分割統治」をし、小さな単位で処理をするのはプログラムの基本です

ですが、本当にそうでしょうか？

このトークでは小さく分割することそのものが目的化した時に起こりうる問題に目を向けることで、

「オブジェクト指向完全に理解した！」
「クリーンアーキテクチャ最高！」

と叫びがちな初級者〜中級者がハマりやすい設計の罠について理解していきます

あなたの設計は本当に大丈夫？

現代のPHP開発は、Laravelなどのフレームワーク活用、複数のAPI連携、非同期処理、
JavaScriptやCSSを駆使した動的なユーザーインターフェースの実装など、私たちが担保すべき品質の範囲は広がる一方です。
しかし、これらの要素が複雑に絡み合うことで、予期せぬバグや機能の不具合が発生しやすい状況も生まれています。

そんなPHP開発者の皆さんに向けて、「Playwright」をご紹介します。
Playwrightは、実際のウェブブラウザをプログラムで操作し、ユーザーが行うような操作を自動で実行することで、
アプリケーション全体の動作をテストできる強力なツールです。
レンダリングされたHTML、CSSの適用結果、そしてJavaScriptの動作まで含めて、ユーザーが実際に体験する環境でのテストを実現します。

本セッションでは、まずPlaywrightがどのようなE2Eテストの世界を実現するのか、その基本的な機能と特徴、効率的なテスト設計、CI/CDパイプラインで自動テストまで紹介します。
明日から、手動テストを自動テストに置き換えてみましょう！

リモートワークから出社への回帰が増える中、我々には再び「コミュニケーション」について考えさせられる機会が訪れています。

「コミュニケーション」というと、言葉と言葉での会話や、チャットでのやり取りなどが思い浮かぶかと思いますが、本質はそれだけではありません。
事象や価値観などを伝えるためには、文字や言葉以外の伝え方や文章の残し方など、組織としての文化も密接に関わってきます。
つまり、「どう話すか」や「どう書くか」だけではなく、「どう受け止められるか」「どう残るか」にも配慮した設計が必要なのです。

このトークでは、私が日々の業務で意識している「ちょっとした工夫」や「しくじりから学んだこと」をベースに、エンジニアとして、またチームの一員としてどのようにコミュニケーションと向き合うべきかを紹介します。
「もっと伝えやすく」「もっと伝わりやすく」を模索している方、あるいは「最近チーム内のすれ違いが気になるな…」という方に、少しでもヒントになる話ができればと思います。

私がYAGNIという言葉に初めて出会ったのは、まだ経験が浅い頃でした。
そのときは、ただ求められていない機能は実装しないように気をつければ、自然と避けられるものだと思っていたのです。

そしてその後、実際に現場で様々なコードを見て、色んな苦労と開発の経験を重ねれば重ねるほど、もっと良い設計を、綺麗なコードを求めていくようになります。
色んなアーキテクチャや設計手法や考え方に触れると試したくなりますよね。新規で開発できるとなると尚更です。

しかし次第に以下のような問題がちらほら見えるようになりました。
・一見きれいに見えるけれど、機能やアプリの規模に対して、理解するのに時間がかかるコード
・拡張を意図して書かれたものの、結局拡張されなかったり、しまいには使われなくなってしまったコード
・開発速度が遅くなってしまっている

そうです。私はYAGNIに反するコードを書いてしまう罠にハマっていたのです。

このトークでは、「気づいたらYAGNIに反していた」自分の経験を通して、
なぜそうなってしまったのか、どんな思考や状況がそれを引き起こしてしまったのかを振り返ります。

そして、プロダクトの性質やシステムのレイヤー・チームの目標や開発の指針と照らし合わせながら、より「ちょうどいいYAGNI」との付き合い方について、一緒に模索していきましょう。

多くの機能が長年にわたり運用されてきたPHPベースの独自フレームワーク上で構築されているプロダクトでは、当時の要件や技術スタックに基づいた設計が、現代の開発観点から見て様々な制約となる場面が少なくありません。

OSSフレームワークへの移行が選択肢として取れない状況下で、既存の独自フレームワークを活かしながら、いかに開発体験をモダンに近づけていくか。本セッションでは、その現実的な選択と具体的な手法をご紹介します。

以下のような具体的な取り組みを中心に解説します。

• PSR準拠コードとの共存を実現する拡張レイヤーの設計
  • 既存の独自フレームワークの上に薄いレイヤーを重ねることで、PSR-7/15に準拠したミドルウェアやハンドラを導入可能な構造を構築
• リファクタリングを先送りしつつ、設計改善を進めるアーキテクチャ戦略
  • ヘキサゴナルアーキテクチャの導入により、既存コードへの依存を抑えながら新機能をクリーンに追加していくアプローチの紹介
• Controller粒度の振る舞いを検証可能なFeature Test基盤の整備
  • LaravelやSymfonyのようなテスト基盤を模倣し、リファクタリング耐性を向上するための自動テストを構築可能にする手法
• OpenAPIを活用したスキーマ駆動開発と開発支援ツールの内製化
  • OpenAPIスキーマをもとに、雛形コードを生成するスキャフォールディングツールの作り方
  • フロントエンド／バックエンドでスキーマを共有するための仕組み
• OpenAPIスキーマベースのバリデーション導入とパフォーマンスへの対策
  • 実運用を通じて見えてきた課題と、性能劣化を抑えながらスキーマバリデーションを有効活用するための具体的な改善手法を共有

このトークではAIエディタである「Cursor」を用いて、既存コードベースから仕様書を生成・整備する取り組みを紹介します。

私が実務で関わっている一部のプロジェクトでは、長年運用された独自のPHPフレームワークを採用しています。
しかし、ドキュメントは少なく、新規参入者が仕様をキャッチアップしづらい状況を課題に感じていました。

その課題に対して、実際にCursorを使って仕様書を作成した経験をもとに、メリットや実運用における課題、注意点についてお話しします。

主な内容：
・Cursorを使ってコードから仕様書を作成する方法、コツ
・AIエージェントによる仕様書作成のメリット、課題

こんな方におすすめ：
・コードが唯一のドキュメントという状況から抜け出したい方
・AIエディタである「Cursor」に興味がある方

システムが誰かに使われて初めて価値を発揮するように、ひとりひとりの持つ知識や技術も誰かに伝わってこそ価値が生まれると考えています。AI が急速に進歩するいま、これまでの知識や技術は少しずつ価値を失っていくことでしょう。
そうなった時に何が大切になるのか。伝える技術なのではないかと私は思うのです。
カンファレンスや社内勉強会、チームメンバーに対して情報の伝達だけではなく、心の芯まで届き、行動を変容させる衝動を喚起する力が、人と働く上でこれまで以上に強く意味を持つと考えています。

このトークでは主に1 対多の状況における伝える技術に焦点を当ててお話しします。

ターゲット

• 技術に重きを置いて生きてきた方
• 人前で話すことに不安を感じている方

聞いた方に渡したいもの

• 人に何かを使える際に必要な技術
• それを実行する勇気

アウトライン

• 語られた道理が目新しいのではない。だが、人は思い出させてもらうとき力を得る。
• 価値を生むのは所有ではなく共有。
• あなたはなぜそこにいるのか。
• 心の底から信じていることだけを言葉にする。
• 聞き手と歩調を合わせる。
• 音、色、動作で感情の波と思考を支配する。
• 事実やデータだけでは足りない。
• 最初の一歩を示す。

カンファレンスのトークで魅力的に語られる、設計の工夫や実践的なテクニック、新しい技術・ツール、チームの取り組みや開発スタイル。
「こんな開発をしてみたい！」「この仕組み、自分のチームでも導入したい！」と気持ちが一気に高まり、現場に戻って何かを変えたくなった経験、ありませんか？

でも現場に戻ると――
・どうやって導入すればいいのかわからない
・他にも問題のある部分が多すぎて、導入できる気がしない
・そもそもチームに受け入れてもらえるか不安

といった理想と現実のギャップに葛藤することもあるかもしれません。

このトークでは、自分の興味や気づきを出発点に、まず1人で実践しながら理解を深め、その後チームメンバーを巻き込んでいき、少しずつ変化を広げていった経験を紹介します。

もちろんすべてを導入することはできませんし、するべきではありません。
その時の状況やチームの課題を認識し、何を取り入れ、どう伝えていくか戦略を練っていきましょう。

そうして重ねた小さな一歩一歩が、やがてチームの空気を少しずつ変え、開発がより楽しく感じられるようになるかもしれません。
そんな変化のプロセスをお届けします。

本トークでは、Androidエンジニアである私が、AIを活用しながらPHPでの開発タスクに取り組むようになったプロセスをご紹介します。
もともと自分自身がPHPを業務で扱ってみたいと思い、サーバーサイド業務に挑戦することにしました。はじめは戸惑いや苦労もありましたが、AIを効果的に活用することで学習をしタスクをこなせるようになった実体験をお話しします。
AIの活用による学習プロセス、具体的なPHPタスクをどのように解決していったかなど、実践的なノウハウを中心にお伝えします。また、異なる技術領域にチャレンジする際の考え方や、AIを使ったスキルアップの可能性についても触れます。

こんな方におすすめ：
バックエンド未経験のフロントエンド／モバイルエンジニア
新しい技術領域への挑戦方法を知りたい方

主な内容：
AndroidエンジニアがPHPタスクを担当することになった経緯
AIを活用したPHP学習と具体的な問題解決方法
技術スタックを広げる際のマインドセットと、AI活用による効率的なスキルアップ

WordPressはPHPベースのCMSですが、セキュリティ対策をすべてWordPress内部に依存するのは非効率的です。
本セッションでは、WordPressが抱えるセキュリティ課題をPHPの視点から考察し、分散型セキュリティアーキテクチャのメリットを解説します。
特に、PHPを活用してWordPress外のセキュリティレイヤーと連携する手法に焦点を当て、より安全かつ柔軟な運用戦略を提案します。

主なポイント
✅ WordPressのセキュリティの限界とPHPが担える役割
✅ 「WordPressだけで完結させない」分散型アプローチ
✅ PHPで外部システムと統合する方法（ID管理、WAF、アクセス制御など）
✅ 実装例：PHPによるJWT認証・RBACの組み込み
✅ WordPressの運用をシンプルに保ち、専門サービスを活かす戦略

Webアプリケーションのフロントエンド、気がつけばこんな課題に直面していませんか？

・フォーマッタ/静的解析の未導入による保守性・堅牢性の低下
・アセットのビルド/最適化がされていない
・テストコードの欠如
・脆弱性や不具合の温床となる古いライブラリ
・エラー検知の仕組みがない

解決策としての大規模リプレイスは不確実性が高く、時間やコストなど大きなリスクを伴います。

本トークではMPA（マルチページアプリケーション）におけるJavaScriptを題材に、段階的に、そして無理なくフロントエンドを良い感じにするための技術をご紹介します。具体的には、Viteによるビルドや開発体験の向上、Nodeモジュールを使ったバージョン管理、Vitestによるテスト実装、TypeScriptを使った型付け、BiomeによるフォーマットやLint、Sentryによるエラー管理、などモダンなフロントエンド開発に不可欠な要素についてお話します。

このトークが、フロントエンドの持続可能な改善への第一歩を踏み出すための、具体的で実践的な道標となれば幸いです。

商品数が数万件を超えるような大規模ECサイトにおいて、ショップのトップページのパフォーマンスは顧客体験や売上に直結する重要課題です。特に大量の商品一覧を取得するMySQLクエリでは、ソートや一時テーブルの利用が増え、処理速度が著しく低下するケースが頻発します。

本セッションでは、PHP製ECサイトにおいてショップトップページのパフォーマンスを改善した具体的な取り組みを紹介します。パフォーマンス問題の特定にあたり、NewRelicのクエリ分析機能を活用し、具体的なボトルネックを明らかにしました。その分析結果を基に、MySQLクエリの設計を抜本的に見直し、インデックスの効果的な利用やクエリ構造の最適化、無駄な並び替え処理の排除などを行いました。

結果として、ショップトップページのクエリレスポンスタイムは従来の1/3以下に短縮され、サイト全体の表示速度が改善されました。

トークを通じて、NewRelicによる問題の特定から実際のMySQLクエリ改善方法までを分かりやすく解説し、参加者が自身のプロジェクトでもすぐに活かせるノウハウを提供します。

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。
でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、
システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。
それぞれの特徴を活かした設計方法をお話します。

難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！

本セッションでは、OpenAPIの定義ファイルを運用する際に静的解析やフォーマッターを導入する方法やメリットについてお話しします。

OpenAPI仕様は、RESTful APIの設計と記述に広く使用されており、APIの構造を明確にし、開発者間のコミュニケーションを改善します。しかし、スキーマ定義が複雑になると、エラーの発見や保守が困難になることがあります。これに対処するためには、静的解析ツールとフォーマッターを導入することで、コード品質を向上させ、一貫性を保つことができます。

本セッションでは、OpenAPIスキーマ定義に対して静的解析ツールとフォーマッターを導入し、以下の目標を達成する方法をお伝えします。

• スキーマ定義のエラーや不整合を早期に発見
• スキーマ定義のコード品質を向上
• 開発者間のコードスタイルの一貫性を確保
• メンテナンスの容易化

本セッションでは、OpenAPIの定義ファイルを運用する際に静的解析やフォーマッターを導入する方法やメリットについてお話しします。

OpenAPI仕様は、RESTful APIの設計と記述に広く使用されており、APIの構造を明確にし、開発者間のコミュニケーションを改善します。しかし、スキーマ定義が複雑になると、エラーの発見や保守が困難になることがあります。これに対処するためには、静的解析ツールとフォーマッターを導入することで、コード品質を向上させ、一貫性を保つことができます。

本セッションでは、OpenAPIスキーマ定義に対して静的解析ツールとフォーマッターを導入し、以下の目標を達成する方法をお伝えします。

• スキーマ定義のエラーや不整合を早期に発見
• スキーマ定義のコード品質を向上
• 開発者間のコードスタイルの一貫性を確保
• メンテナンスの容易化

Webサービスを立ち上げるなら、多くの場合に実装する「認証認可」機能。
たくさんのネット記事には、OIDC?, OAuth?などの用語が並び、初めて関わる人にとっては難しく感じることでしょう。

自前実装するのは労力もかかるし、セキュリティホールを作り込まないかも心配、、、
いい感じのManaged Serviceを使って楽に実装できないか、、

Amazon Cognitoを使えば、基本的な認証認可はもちろん、SMSによるパスワードレスログインなどを「安価に」実装できます。

このトークでは、(OAuth/OIDCなど)認証認可の基礎について解説した後、筆者が実際に関わったPHP x Cognitoの実装について、知見を余す所なくお伝えします。

このトークで話すこと

• 認証認可の概要
• Cognitoを使ってPHPアプリケーションに認証認可機能を追加する方法

PHPerの方には、最近弊社はGoに移行しているんだけど、PHPの膨大な既存コードも捨てがたい、、、なんて思ったことはありませんか?
既存のPHPコードから、順次移行したGoを呼び出せればいいのにな、、、そう思う方も多いでしょう。

PHPにはFFI (Foreign Function Interface) という、「純粋なPHPでCの関数をコール」できる拡張があります。
実はこれを使えば、Cだけでなく、Goの共有ライブラリを(なんとか)呼び出すことができるのです!

このトークではPHPからGoの共有ライブラリを呼び出す方法と、その具体的な活用例について共有し、FFIの可能性に触れてみます。

話すこと

• PHPからGoの共有ライブラリを呼び出す方法
• この方法で想定されるユースケース (自社独自のロジックを複数プロジェクトで使い回すなど)の紹介

チャットでのコミュニケーションに苦手意識を感じていませんか？

COVID-19パンデミック以降、多くの企業でリモートワークが導入されました。
その結果、ここ数年「出社して対面でコミュニケーションしながら業務を進める」という経験がほとんどない層が増えてきたと思います。
今回これを「リモートワークネイティブ」と名付けてみました。私（2023年新卒）もその1人です。

さて、リモートワークで重要になるのが、Slack等のチャットツールを活用したテキストコミュニケーションです。
しかしいざ送信してみても、意図が伝わっていなかったり、欲しい内容とは異なる回答が返ってきたりして、余計なコミュニケーションコストがかかることも少なくありません。
このように、テキストでのコミュニケーションには、対面で話すのとは異なる意識やコツが必要です。

特に私のような若手は、業務に関して質問をしたい機会が多々生じ、都度「よりよいチャット」について考えてきました。
本LTでは、"リモートワークネイティブ"な私が、新入社員時代から試行錯誤しながら会得したチャット作文のポイントを共有します。
余計なやり取りを増やさず、聞く側も答える側もハッピーなコミュニケーションを目指しましょう！

対象

• チャットで質問する機会の多い人（特に、どう伝えれば良いか悩むことが多い人）
• チャットでの質問に答える機会の多い人（特に、何が伝えたいのかわからないことが多い人）