本トークでは、弁護士ドットコム株式会社でより良いプロダクトの開発を目指して、 情報設計というキーワードを中心に約 5 年ほど取り組んできたことについてご紹介します。

具体的には、Application-Level Profile Semantics(ALPS) というアプリケーションの操作や語彙を記述するテキストフォーマットを活用した、情報を中心としたチーム開発の事例やAI開発ツールの活用事例についてお話します。
また、組織・プロダクトを跨いだメンバーで取り組んでいる、社内ワークショップ活動を通じた啓蒙活動についてもお話します。

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

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

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

kubellでは日々100万人以上のユーザーが「Chatwork」にログインし、アプリケーションを利用しています。
このセッションでは、「Chatwork」の認証基盤をAuth0へ移行し、運用を行っている実際のプロセスを詳しく紹介します。
Auth0への移行方法とPHPでの実装における工夫について具体的に解説します。
また、ログデータを活用した異常検知やビジネス分析の手法についても触れ、データを活用したアプローチについても紹介します。

"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 対多の状況における伝える技術に焦点を当ててお話しします。

ターゲット

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

聞いた方に渡したいもの

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

アウトライン

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

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

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

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

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

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

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

このトークでは、自分の興味や気づきを出発点に、まず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の運用をシンプルに保ち、専門サービスを活かす戦略

私のマネジメントする開発チームでは、GitHub Agentを活用した開発フローを取り入れており、今では「なくてはならない戦力」として定着しています。

とはいえ、導入当初からうまく活用できていたわけではありません。
「AIに任せたが期待通りのアウトプットは出なかった」などを中心に、いくつか悩みもありました。

本トークでは、実際の現場で行ってきた試行錯誤のプロセスをもとに、エージェントAIとの「共進化」の過程を振り返ります。
再現性のあるTipsを重視しつつ、以下のような観点から、「開発にAIを溶け込ませるために必要な視点」について掘り下げていきます。
・エージェントAIを活用する際の基本的な姿勢
・導入初期にまず取り組むべきこと
・開発業務で効果的に使うための準備と工夫
・開発以外の周辺業務での活用事例（例：PRレビュー補助、ドキュメントやSQL作成）

「とりあえず使ってみた」から一歩進み、エージェントAIをツールとして活用するには何が必要か？
そのリアルな知見と、成功も失敗も含めた経験談をお届けします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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