プロポーザル

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

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

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

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

昨今のWebアプリ開発において、Webブラウザは切っても切れない存在です。
このWebブラウザには、HTMLとCSSからテキストや画像を描画する「レンダリングエンジン」が含まれています。

これがどのような仕組みで動いているのか、その裏側についてはご存知でしょうか?

このトークでは、超ミニマムな簡易レンダリングエンジンをPHPで実装することで、レンダリングエンジンの大まかな仕組みの理解を目指します。
また今回のトークで用いた、サンプルコードを他言語で再実装する勉強法も合わせてご紹介します。

このトークを聞き、レンダリングエンジンの裏側を垣間見ることで、Webアプリ開発におけるブラウザからの新たな視点を獲得できるでしょう。

対象の方

Webブラウザの仕組みに興味がある方
PHPでなにか書きたいけど作りたいものがない方

このセッションでは、LaravelとInertia.jsを組み合わせたモダンなフルスタック開発について紹介します。
Inertia.jsは、ReactやVueなどのモダンなフロントエンド技術のメリットを活かしながら、サーバーサイドアプリケーションのシンプルさを維持するためのツールです。これにより、複雑なAPIやクライアント側の状態管理なしで、モダンでインタラクティブなウェブアプリケーションを構築できます。
ReactやVue、TypeScriptと組み合わせて使用する方法や、Inertia 2.0で導入された新機能（Prefetch, Deferred Props, Infinite Scrollingなど）、UIコンポーネントライブラリのshadcn/uiの活用法、ライブバリデーションを実現するPrecognitionについても説明します。
また、Laravel Wayfinderを用いて、Laravel側のRouteをフロントエンドからTypeScriptの型としてシームレスに呼び出す方法についても紹介します。

CPUやプログラムの実行といったコンピュータの"低レイヤ"を知るためにCコンパイラを作成するのはとても良いアイデアです。

Rui Ueyamaさんの「低レイヤを知りたい人のためのCコンパイラ作成入門」はまさにそんな目的で書かれていて、手順どおりに進めていくだけで演算、変数、関数やポインタなど十分にそれっぽいCコンパイラを作れます。

ですが、このドキュメント、C（言語）でCコンパイラを作っていて、それ自体はごく普通のことですがPHPerにとっては若干ハードルが高いんですよね…。
OK。それならPHPでやってみましょう。

このトークではRui Ueyamaさんのドキュメントに従いながらPHPでCコンパイラを作る方法を基礎から解説します。

・x86マシン語とプログラム実行の基礎知識
・最小限のコンパイラの実装
・ユニットテストを書きながらの1ステップずつの機能追加
・自作したコンパイラで自分自身をコンパイルする"セルフホスト"に向かう道

このトークを聞いた方がご自身でもPHPでCコンパイラを作成し、コンピュータの低レイヤを楽しめる様になることを願っています。

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の共有ライブラリを呼び出す方法
• この方法で想定されるユースケース (自社独自のロジックを複数プロジェクトで使い回すなど)の紹介

PHPではtry-catchによる例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？
過剰なエラーハンドリングや、catchしたけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも悪影響を及ぼします。

こうした課題へのヒントとして、Rustなどの言語で採用されているResult型の考え方を、PHPに応用するアプローチがあります。
Result型は、失敗を型として明示的に扱い、成功も失敗も返り値で表現する設計手法です。
これにより、「どこで何が失敗しうるか」「どこまでが関数の責務か」がコードから読み取れるようになり、処理の流れや責任が明快になります。

本トークでは、Result型によるエラーの設計方法や、例外との使い分けについて、以下の観点から実装例を交えて解説します：

• エラーの分類と責務の整理
• 例外との使い分け
• PHPでResult型を実装する方法

Result型を導入するかどうかに関わらず、エラーをどう設計するかを見直すヒントとして、この考え方を持ち帰っていただけると嬉しいです！

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

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

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

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

対象

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

AWS Lambdaは、小規模かつシンプルな設計が推奨されていますが、実際には複数の事業ドメインをマイクロサービスとして分割し、継続的な機能追加や変更が求められるケースが増えています
こうした構成では、特定の関数がSQSやEventBridgeに直接依存するなど局所的な実装が積み重なり、DTOの定義が乱れることでフロントエンドへの影響も無視できません

本セッションでは、Lambda上でClean Architectureを実践し、変更容易性と構造の一貫性を保つ手法を具体例を交えて紹介
ユースケース層とドメイン層をLambdaの制約に依存させず、インフラ層のみ非同期処理・初期化の制約に最適化することで、依存逆転の原則と明確な責務分離を実現
Adapterパターンを用いたイベント抽象化や、JSON Schemaを活用したDTO設計による型整合性の維持など、具体的な実践ノウハウもお届けします

Lambdaの制約を超える長時間処理についてAWS Fargateへ基盤を切り替え、設計を維持したまま柔軟に基盤を選択する方法もご紹介します

Lambdaだからこそ、変更に強い設計が必要です
複数サービス、UIと連携するマイクロサービスにおいて、基盤と設計が協調したアーキテクチャ構築のヒントを学びましょう

• お話すること

  • Lambda上で実践するClean Architectureの具体構成
  • Adapter実装でLambdaの非同期・初期化制約を乗り切る方法
  • DTO設計によるフロントエンド・API間の型整合性担保

• 想定聴講者

  • Lambdaやサーバレス環境でClean Architectureを実践したい方
  • マイクロサービス設計で拡張性と柔軟性を確保したい方
  • UI/API間の連携設計に課題を感じている方

この設計、本当に正しいのかな…？そんな迷いに出会ったとき、どうしますか？
本セッションでは、「とりあえず書いてみる」「すぐに壊してまた作る」という軽やかなプロトタイピングスタイル＝VibeCodingを通して、設計を具体的なコードで試し、磨き上げる方法を共有します

VibeCodingは、一見直感的で自由にコードを書くように見えますが、実は『何度も作り直して設計の輪郭を探る』ことを積極的に肯定した開発スタイルです
生成AIや補完ツールとテンポよく対話しながらコードを書くことで、頭の中の設計と実際のコードとのギャップを素早く埋め、設計が実際にどう動くのかをリアルタイムで検証できます

セッションでは、VibeCodingによって得られた具体的な知見を共有します
『壊しやすい構造』『変更を戻しやすい設計単位』『生成AIと開発者の思考のギャップ』など、具体的な観点から、短時間で設計を試し、評価し、改善するサイクルの構築法をお伝えします

議論やドキュメントだけで設計を詰めるのではなく、『まずコードを書いて試し、壊してまた考える』という積極的な開発姿勢を後押しし、設計に迷いなく取り組む方法を掴んでいただきます

お話すること
　- VibeCodingの定義と設計への応用
　- 生成AIを用いたプロトタイピングと考察ループの構築
　- 書きやすさ・壊しやすさ・戻しやすさから設計を掘り下げる視点

想定聴講者
　- 設計の妥当性に迷う方
　- プロトタイピングで設計検証を繰り返したい方
　- 生成AIと共に“考えるように書きたい”すべての開発者

Clean Architectureを使えば変更に強いソフトウェアが作れる、アプリケーションの寿命を時代の進歩に合わせて更新し、ビジネスに価値を届け続ける
そんな理想を夢見て、Clean Architecture を導入した、または導入したいと考える方は多いのではないでしょうか

ユースケース層まで丁寧に分離したつもりでも、実際には DB 依存が思わぬ場所に残り、「この設計は本当に変更に耐えられるのか」と不安になる瞬間があります
Clean Architecture は理想的だと言われますが、いざ大きな変更が発生したときに本当に価値を発揮するのか、設計原則の“手応え”を確かめたいと思ったことはありませんか

本セッションではその疑問を検証するために、Laravel のアプリケーションを設計ごと Symfony へ移行するプロセスを可視化します
対象とするのは 2 種類のユースケース：①ドメイン層が純粋に保たれているロジック、②Eloquent 依存が進んだロジック、それぞれの移行過程を比較し、前者では構成と DI の置換だけで動作し、後者では Repository 抽象の導入など、追加のリファクタが必要になることを示します
その過程を示し比較することで設計が継承できる / できない境界線を感覚ではなく、コードで理解します

Clean Architecture がなぜ必要か、そのためにどれだけの実装コストがかかるのか、そして構造を超えて設計を継承する方法を一緒に学びましょう

• お話すること
  • Clean Architectureが変更に強いか設計ごと移行して検証
  • ドメイン層の純度による移行の難しさとリファクタの観点を紹介
• 想定聴講者
  • Clean ArchitectureやDDDに関心がある方
  • 設計を再利用・継承したい方

Clean ArchitectureやDDDを導入するPHPチームが増えていますが、多くの現場で「設計がコード内だけに閉じ込められた」状態になっています
せっかく設計を綺麗にしても、デプロイが属人化して変更が難しく、テスト環境が不安定で、プレビュー環境も整備されていなければ、設計のメリットは現場に十分浸透しません

本セッションでは、PHPプロジェクトにPlatform Engineeringを適用し、コード外の「設計支援」を実践する方法を紹介します
設計の再利用性や責任分離を高めるCI/CDパイプライン、テスト自動化、プレビュー環境の構築、モノレポ管理など、具体的な仕組みを共有します

チームトポロジーの『Enabling Team』『Platform Team』『Stream-Aligned Team』をベースに、
Platform Teamが単なるインフラ担当を超え、「コード外から設計思想を現実化する戦略的なパートナー」になる方法をお伝えします

お話すること
　- チームトポロジーに基づく設計支援の構造
　- Platform Teamが設計再利用や責務分離を支える仕組み（CI/CD、テスト自動化）
　- プレビュー環境・モノレポ管理による設計体験の向上

想定聴講者
　- PHP開発チームの設計力を基盤面から支援したい方

• 設計と組織構造の関係に興味がある方
• Platform Engineeringを取り入れたいSRE・DevOps系エンジニア

「この設計、本当にいいのか？」そう迷ったとき、ずっと考えているだけでは答えが出ない──そんな経験はありませんか？
このLTでは、まず手を動かしてみる、壊してみる、またすぐ書いてみる
そんな軽やかな反復によって設計を確かめるアプローチを紹介します

近年、生成AIやコード補完ツールの進化により、考えたことをすぐ試せる環境が整いました
この流れの中で生まれた文化のひとつが「VibeCoding」
BGMや気分に乗せて、直感とリズムを大切にしながら、楽しく試行錯誤を繰り返すコーディングスタイルです
PoCやプロトタイピングとの相性も抜群です

このLTでは、そんなVibeCodingのリズムの中で見えてきた

• 書きながら気づく「壊しやすさ」と「戻しやすさ」
• 補完と自分の意図がズレる瞬間の設計的示唆
• 30分1セットで設計を“体感”するテンプレート思考

といった実践的な視点を紹介します。
設計を頭の中だけで完結させず、「ノリで書いて確かめる」ことで得られる気づきを、少しでも持ち帰っていただければ嬉しいです。

• 想定聴講者
  • 設計の良し悪しをコードで確かめたい人
  • 生成AIを“動く設計ツール”として使いたい人
  • 設計と集中のバランスに悩んでいるすべての開発者

設計の話をしているはずなのに、なぜか現場でうまく伝わらない、そんな経験はありませんか？
Clean Architecture や DDD を実践し、責務の分離やドメインのモデリングをコード上で実現しても、
それがチームの動き方やプロジェクトの進め方と一致していないと、せっかくの設計がうまく活きないことがあります

本LTでは、設計を「コードの構造」に閉じるのではなく、「チーム構造」「責任分担」「役割」にまで広げて考えるアプローチを紹介します、キーワードは「チームトポロジー」
アプリケーションの内部構造だけでなく、開発者の関係性や組織の構造にもドメインの境界や責務を適用することで、設計と運用のねじれを解消することができます

例えば、認可や監査といった横断的関心事に対して Platform Team がどのように設計支援を行うか
あるいは、ユースケースの責務とチームの責務がズレたときに、実装がどんなふうに崩れていくか
短い時間ではありますが、「設計はコードにとどまらない」ことを提示します

設計・組織・開発体験がバラバラになってしまっているチームにとってのヒントになれば幸いです

• お話すること
  　- 設計とチーム構造を接続するための観点
  　- チームトポロジーを活かしたドメイン適用の工夫

• 想定聴講者
  　- 設計と組織のねじれに悩む方
  　- 設計やチーム構造に興味を持ち始めた初学者の方

このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。

Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X：@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。

また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。

このセッションでは、VercelでPHPとVercel Postgreを用いたアプロケーションを公開する方法を紹介をします。

振る舞い駆動開発（BDD）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。

本セッションでは、PHPでBDDを始めるための基本的な考え方と実践方法を紹介します。Behatなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

PHPでテストを書いて、プロジェクトに無理なく導入できるBDDの第一歩を、これから始めたい方に向けてわかりやすく解説します。

「抽象化していますか？」ーー抽象化と聞くと、設計やモデリングをイメージするかもしれません。他にも、interface のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

本セッションでは、抽象化（と具体化）という考え方を整理し、設計や言語機能だけでなく、物事の理解や共有、課題解決、トラブルシューティングといった開発現場の広い場面でも活用できる「思考の技術」として具体的な例とともに紹介します。

「使える思考のツール」として抽象化を一緒に見ていきましょう。

「抽象化していますか？」ーー抽象化と聞くと、設計やモデリングをイメージするかもしれません。他にも、interface のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

本セッションでは、抽象化（と具体化）という考え方を整理し、設計や言語機能だけでなく、物事の理解や共有、課題解決、トラブルシューティングといった開発現場の広い場面でも活用できる「思考の技術」として具体的な例とともに紹介します。

「使える思考のツール」として抽象化を一緒に見ていきましょう。

私は主にPHPを書いてきたエンジニアですが、業務でGoを触る機会が増えています。
その中で、最も大きな衝撃を受け、書く上で一番苦労したのが「インターフェイス」の実装方法と思想の違いでした。
（PHPでimplementsに慣れた私にとって、Goの暗黙的に満たすインターフェイスは衝撃的でした）

このセッションでは、私なりの理解を基に、PHPとGoのインターフェイスの仕組みを比較しながら、それぞれの思想、メリット・デメリットをサンプルコードを交えて解説します。
PHPエンジニアがGoを書く上で躓くであろう最初のハードルを乗り越えるきっかけをお届けします。

PHPエンジニアでGoも書いてみたいなと思っている方、PHPとGoのインターフェイスの違いに興味がある方におすすめです!

話すこと

• 明示的な実装（PHP）と暗黙的な実装（Go）の違い
• PHPとGoそれぞれのコード例を交えた実装方法の解説
• PHPとGoのインターフェイスの置き場所の違い
  • 例）RepositoryのインターフェイスはPHPではDomain層、Goでは実装近くに置きがちなのはなぜか、など

話さないこと

• PHPとGoの基本的な文法
• PHPとGoの深い設計思想

PHPやLaravelで開発したことのある人なら、「CSRF」という単語について聞いたことはありませんか?

例えば、Laravelで新しく作ったフォームを開いたら、「419 | Page Expired」のようなエラーを見たことがある人は多いのではないでしょうか?
(そして、とりあえず @csrf というおまじないを書いたらエラーが直った経験もありませんか?)

CSRF (クロスサイトリクエストフォージェリ) は脆弱性の一種で、
これを対策しないと、ユーザーが意図しない操作（例えば、商品の購入など）を強制的に実行させられてしまう可能性があります。

じゃあどういうコードを書くとCSRF脆弱性を仕込めるのでしょうか?
このトークでは、サンプルのフォームにCSRF脆弱性を仕込み、実際に攻撃した後、脆弱性を仕込まずに済む対策について紹介します。

アウトライン (案)

1. CSRFって何?
2. こんな場面で見たことありませんか?
3. CSRF攻撃って結局どういう攻撃なの?
4. どういうコードで起こり得るの? (映像による実演)
5. じゃあどうすればCSRF脆弱性を作り込まずに済むの?