部署20 × ロール4 × 「自分のデータだけ見せたい」。社内システムの厄介なアクセス要件に、Laravel アプリへ Casbin を組み込みながら挑んだ設計奮闘記です。ロール制御（RBAC）だけでは表現し切れない “所有者判定” を ABAC 的に補強しつつ、ポリシーマトリクス爆発を抑え、UI 工数を削減して MVP を最速リリースしたハイブリッド構成と実装ハックを 25 分で共有します。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Laravel の Gate／Policy では追いつかない複雑な権限制御に対し、オープンソースの Casbin を導入。しかしすぐに「ポリシー膨張」「継承の採用判断」「Eloquent 直渡しによる性能不確実性」という 3 つの壁にぶつかりました。試行錯誤の末にたどり着いたのが、RBAC ベースに ABAC 的“所有者判定”をアプリ層で補完するハイブリッド構成です。

本セッションでは、以下を具体コード付きで解説します。

・ 要件整理とモデル選定プロセス——ロールだけを捨てた決断
・ 落とし穴 Top3 と対処法
　・ ポリシー爆発：ドメイン分割＋ワイルドカードでポリシー圧縮、CSV→PHPUnit 自動生成テストも紹介
　・ 継承 (g) の採用判断：メリット・デメリットと PJ が不採用にした理由
　・ Eloquent 直渡し問題：N+1 回避のアプリ層 if 判定
・ ベンチ設計：middleware vs model‑level、QPS 実測のコツ
・ UI 後回しで MVP 切り出し——工数を半減させる分割術

権限管理に頭を悩ませている方、これから設計を任される方へ、実戦で使える指針と突破口をお届けします。

私が担当しているメール共有サービスのメールディーラーではE2Eテストを導入することで、一定以上の品質を担保することに成功しました。

E2Eテストを導入したことの効果やテストコードの実装やテストケースの作成で工夫しているポイントなど、
メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

メールディーラーは2001年にローンチしましたが、フレームワークを導入しておらず、
DBアクセスとHTMLの生成をひとつのプログラムで行っています。

内部構造のアーキテクチャもさることながら、プログラム構造の陳腐化がリリースを行うごとに進みました。
いわゆる「スパゲッティコード」が散在し、それらがサービスの品質にまで影響するようになりました。

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

その結果、コード全体の把握が難しくなり、修正前に十分な影響調査ができない状況が生まれました。
このような状況下で、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能で「画面が表示できなくなる」といった致命的な障害が発生しました。

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

通常の開発と並行して約3ヶ月という期間で273画面に対してテストコードを実装し、
導入後は「画面が表示できなくなる」といった致命的な不具合の発生を防止することができました。

限られた期間とリソースでどのようにして、当初の目標通りの成果を出すことができたか？をご説明いたします。
本セッションを通じてE2Eテストの導入や品質担保の参考になれば幸いです。

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

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

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

「クリーンアーキテクチャ」というものがやりたいのではない。クリーンなアーキテクチャをつくりたいのだ。
そんな思いから、このセッションは始まります。

丁寧につくりあげた設計の理念が、納期・チーム事情・歴史的経緯を前にして思いどおりに適用できないことは珍しくありません。

本セッションでは、特定の設計流派にとらわれることなく、万能レイヤー構成を追い求めるのでもなく「現場で選び取るための判断軸」にフォーカスします。

• どこまで追い求め、どこで割り切るかの基準
• チーム負荷を増やさずに設計方針を整理する考え方
• 現場の文化を壊すことなく改善を提案し、合意を得るための工夫

完成形の図面ではなく、変化し続けるプロダクトと向き合うための「ゆるい設計術」を提案します。

想定対象者: 中規模 PHP プロダクトで設計・リファクタリングに関わるエンジニア

PHP コードの正当性は、テストや静的解析によって保証するのが一般的です。

しかし実際には「このメソッド呼び出しが正しいことは、どのテストで保証されていたっけ？」と確認を要する場面や、静的解析ではカバーしきれないコード構造も現実には多く、必ずしも安心とは限りません。

このセッションでは、コード自身が自分のやろうとしていることの正当性をその場で保証する "Self-Validating Code" というアプローチを紹介します。

テストや静的解析を補完し「この処理は確かに正しい」とコードの内側で完結して確認できる仕組みが、開発体験をどう変えるかに注目してみましょう。

Laravel アプリケーションに導入した具体例をもとに「正当性の保証がコードの外部に散らばっている」煩雑さをどう減らせるか、それが Fail Fast や防御的プログラミングとどう違うのかも整理してお話しします。

書いたその場で、正しさを信じられる。そんなコードを書くためのヒントをお届けするセッションです。

配属されたPHPプロダクトは、次につくる機能が決まっていませんでした。

私が担当することになったプロダクトは、立ち上げ時に想定していた機能をつくりきった状態でした。
しかし、ビジネスチームのメンバは他のタスクに追われ、次の開発方向性をなかなか決められず、小さなバグ修正や軽微改善のタスクばかりが提案される危険がありました。
そのため、次の一手をビジネスチームと一緒に考えることになりました。しかし、今までの開発チームはビジネスサイドからの要求を実装することがメインの仕事であり、主体的に開発の方向性を考えられるようになるためには、開発フローやいくつか"仕掛け"が必要でした。

このトークでは、ビジネスチームに頼っていた開発チームを、主体的に動けるチームに変えるために行ったことについてお話しします。

「PHPってWebサーバー上で動くもの」——そんな常識をNativePHPは打ち破ります。
2025 年 4 月に正式リリースされた NativePHP for desktop について解説していきます。

Electron やTauri のようなクロスプラットフォームなデスクトップアプリが主流になる中、
私たちが普段使っている PHP でも実現できる時代が来ました。

NativePHP を使えば、PHP でデスクトップアプリが作れちゃうらしい！
そんな知らせを聞いて、手を動かさない PHPer はいない！
実際にデスクトップアプリを作成して、見えてきた魅力や気づき、課題について率直にお話しします。

Web の外へと飛び出した PHP の勇姿を、ぜひ見届けてください。
「PHP もまだまだやれる！」

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

概要

時は2025年、AIエージェント元年と言われるこの世の中では「人よりもAIが仕事ができる」という噂が囁かれる事態となりました。
ですが、果たして本当にそうなのか。AIは人並みに仕事してくれるのか？我々のような老練のPHPerが立場を危うくするほど驚異的なものなのか？

本セッションでは、自律型AIエージェントプログラマー「Devin」について実際に使ってみた感触と、PJメンバーとしての有用性についてお話します。
今みなさんが気になってるホットなAIエージェントの話題をPHPer的な視点から掘り下げます。

トピックとしては以下です

• コードのクオリティーについて
• 仕様をどこまで理解してくれるのか
• Unit Testとかも書いてくれるの？
• リーダブルコードを考慮して書いてくれるのか
• PHPのVersionは考慮してくれるのか
• 結論、有用なのか否か

対象者

• PHPer
• AIに興味がある人
• AIに焦燥感を抱いてる人、大丈夫でしょうと高をくくってる人
• Devinについて情報収集してる人

得られるもの

• AIエージェントはどんな仕事をしてくれるのか
• AIエージェントへの指示（プロンプト）の効果的な与え方はどうすれば良いのか
• 自社で導入する時に評価できる・できないポイントがどこにあるか

名前の似た機能の実装を集約して、複数のドメインと機能でテーブルとAPIを共有する。

この設計アイディアによって、弊社機能の立ち上げは部分的には加速しましたが、サービスの成長に伴い高いコストをもたらしました。
この設計アイディアを社内では「汎用テーブル・API」と呼んでいます。

本トークでは、「汎用テーブル・API」がどのようなコストをもたらしたか、ドメインと機能の境界に沿ってテーブルとAPIを分割するまでの道のりを具体例を交えてお話しします。

以下の内容をお話しします。

• 「汎用テーブル・API」とは何か、どのようなコストを発生させているか
• ドメインと機能の境界に沿って分割するまでの具体的な手順

対象者:

• バックエンドの技術負債に向き合っている方
• DBテーブルのデータ移行に興味のある方

Agenda

1. What is DDD x Clean Architecture?
2. What kind of systems is it suitable for?
3. How was the actual implementation in Laravel?
   • What steps were taken to introduce it?
   • What kind of structure was used for the implementation?
   • Good points and bad points

※この資料の内容で話します！日本語版に直すのも可能です。
https://speakerdeck.com/bumptakayuki/laravel-x-clean-architecture

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試してきました。
2025年、AI時代に入って、世間のPHPerの皆さんもコード生成を始めていると思いますが、単に自然言語でプロンプトを投げては生成ガチャを引くだけになっていませんか？
私は、作業ログを読み込ませたりコンテクストの与え方を工夫するよりも、AIとPHPを組み合わせて利用することで「退屈な仕事」はPHPに任せてガチャの範囲を狭め、より効率的にコード生成を行えるのではないか、という仮説に基づいて実験をしています。その結果を報告します。

PostgreSQLにはRow Level Securityがありますが、PHPを使った開発プロジェクトではほぼ使われていないのではないでしょうか。
Row Level Securityを使ってLaravelでアプリケーションを開発するにあたって、私はEloquent ORMとDoctrine ORM両方でコードを書いてみて、開発者体験を比較検討してDoctrineを選択しました。どういう判断でDoctrineを選んだか、2年半に渡って実際に開発に使ってみてどうなったかを共有します。

• Row Level Securityとはどんなものか
• EloquentでRow Level Securityを扱う方法の解説
• DoctrineでRow Level Securityを扱う方法の解説
• Eloquent vs Doctrine そして結論

「HowじゃなくてWhyで考えよう！」なんてセリフを良く聞きますね。
その一方で、設計について聞くと「○○設計を踏まえていて〜」と返答をもらうことも、しばしば。

ローカル変数の命名1つをとっても、フレームワークやインフラストラクチャの選定にしたって、
一気通貫の「なぜ設計をするのか」「どんなものが必要なのか」の考え方があるはずです。

それが「トレードオフを見極め、織り込み、決定する」ことです。
これこそが「設計行為である」という立場からトークをします。

抽象的で、広いスコープに届くような話を、なるべく具体的で卑近な例を取り上げながら説明していきます。

話すこと

「Why」としての設計

• ソフトウェア開発の最終目的である「品質」 = ユーザーにとっての価値実現
• 求めるべき品質を可能な限り摩擦ゼロで実装する支えが「設計」

取り上げる話題の例

• 「テストしやすくする」時に、何を天秤にかけているのか
• 「YAGNIだ、だからやめよう」は何を捨てているのか・拾っているのか
• ベテランに聞いてみました！ "「設計的な判断をする」時に、何を考えていますか？"

ソフトウェア開発をやっていると、実に様々な「○○駆動」に出会います。
ドメイン駆動、ユースケース駆動、テスト駆動・・・

開発や設計の進め方だったり、考え方だったりについては、「駆動」以外にも似たような単語がありますね。
オブジェクト指向などの「指向」、ユーザー志向などの「志向」、人間中心デザインなどの「中心」、モバイルファーストなどの「ファースト」、etc。

その中にあってTDDやDDDなどは、どうして「駆動/ドリブン」なのか？を考えたことがありますか。
一歩留まって考えると、ただ「○○を最初にやること」ではないはずだ、と気付くはずです。
私は、この言葉を使う時、中核には「フィードバックを得やすくする」「あるべき姿の探索を推進する」ための仕掛けである！という主張が眠っているものと捉えています。

更に一歩踏み込んで、「なぜ、そうした仕掛けが必要なのか？」も考えてみましょう。
その答えは、「人間として、プログラミングを少しでも楽にするため」だと私は捉えています。

複雑で難しい問題を解く時、「できるところから始める」と進みやすくなります。
高度で曖昧な問題に取り組む時、「間違いに気づいて修正ができる」と正解に近づきやすくなります。
つまり、「認知負荷がキャパシティを超えないようにチャンクする」「適切なタイミングでフィードバックを得る」「軌道修正をする」を組み合わせることで、人間の問題解決能力が高まるのです。
「○○駆動」とは、正にこうした「人間が進むための杖」となるべきものでしょう。

このトークで話すこと

• 色々な「○○駆動」は、人間に楽をさせるための道具である
• どうやって楽をするか？に向き合うことが、プログラミングの能力に磨きをかける

このトークで話さないこと

• 特定の「○○駆動」についての解説や宣伝

一般的に「理系の専門職」と言われるプログラミングのお仕事について、
「実は国語力がとても大事だ！」という主張。
皆さんも、しばしば耳にした事があるのではないでしょうか？

多くは、「文章や会話の中から、要求を掴む」「表現すべきことを、構造化して記述する」といった点についての言及です。
なぜ、これらを「国語力」というのでしょうか？
あるいは、他にも要素があるのでしょうか？

例えば、「大学入試科目・現代文」の解き方をトレーニングすることで、職業プログラマーが学べる事とは──
もし、必要な能力が身につくのであれば、取り入れていきたいですよね。

そんなチャレンジをしてみましょう。

やること

• 「現代文(主に入試現代文)」の参考書で、どんなことが述べられているかを調べる
• 実業務と照らし合わせて、関連しそうなケイパビリティを紐解く

聴き手に提供すること

• 改めて「業務で求められる能力(のいち側面)」について分析し、言語化する
• 得意な人には自覚的な「強み」として、苦手な人には「鍛え方」「着目ポイント」として、国語力について考える機会にする

Composerで「パッケージを入れる」とは何なのか？について考えてみてください。

• 多くのパッケージにおいて、その他の様々なパッケージへの依存を持っています。
• 単純なパッケージ名だけでなく、各々が要求し許容するバージョン指定の範囲も、実に様々です。
• そして、その「その他の様々なパッケージ」もまた、その他の様々なパッケージへの依存を持っています。

・・・一体どうやって、こんなに複雑な仕事を達成しているのでしょう？
このトークでは、2つの観点から「どんな工夫をしているか」を解剖していきます。

提供する主な話題

1. Composerが複雑な「パッケージの組み合わせ」を解くための手続きとは？
   1. 「Pool」の最適化とは？
   2. SAT Solver、 2-Watched Literal Schemaといった概念についてざっくりと
2. メモリ節約のためのPHP的な工夫
   1. 各所で活躍するSPLデータ構造や実装に見られる構造面での工夫、おもむろに現れるgc_disable() 等

このトークで得られる体験

• 普段使っているツールが内部で「どんなエレガントな問題解決をしているか」に触れる
• PHPアプリケーションのいて大量・複雑なデータを扱う上での生きた例を垣間見る

対象者・扱うこと

• Composerの基本的な使い方を理解している方の方が望ましいです
• Composer全体の仕組みやパッケージ取得方法についての詳しい解説は行いません
  • ピンポイントで「パッケージとバージョンをどうやって決定しているのか」の話になります
  • ツールとしてのComopserの便利さ・使い方を紹介するトークではありません
• 数学・計算機科学的な踏み込んだ解説は範疇外です

PHPのsocket拡張を利用するとsocketプログラミングができ、通信プロトコルもPHPで実装できます。
さらに、RAW socketという機能を使うとTCP/IPプロトコルもPHPで実装可能です。

今回のセッションでは、

• PHPのsocketプログラミングの基本
• TCPプロトコルの実装
• IPプロトコルの実装
• tcpdump, netstatによるデバッグ
  の話を通して、はまりポイントやプロトコル実装の楽しさを共有したいと思います。

プロトコルは仕様が決まっていて、その仕様を見てひたすら実装し、最終的にはサーバやクライアントと通信できるようになります。この通信できた時の喜びは非常に大きく、かつ大変勉強になります。通信できるまでの過程も含めて楽しさが伝えられたらと思います。

本トークでは、チームの協働によって生み出されたイベントストーミング図を実際の動作するコードへと変換する手法を紹介します。

イベントストーミングとは、ドメインイベントを中心に据えたワークショップ形式のモデリング手法で、付箋やポストイットを使って、ビジネスプロセスの流れを視覚的に表現していくものです。
ドメイン駆動設計の原則に基づいたシステム開発を実現する上で、開発者とドメインエキスパートの協働を支える効果的な手法として注目されています。

これまで、イベントストーミングのワークショップを行うことで、ビジネスプロセスの理解を深め、チーム間の認識を統一するといったことは成功させてきました。
しかしながら、その成果物を具体的なソフトウェア実装へ昇華させる段階でつまづくことがあります。

そこで、このトークではイベントストーミングで可視化された知識の宝庫を、どのように実装へ導くのかということをテーマに、具体的なアプローチを解説します。
ビジネスドメインの本質を損なうことなく、いかにモデルをコードに落とし込むか、そのプロセスと実践的なテクニックを共有していきます。
また想定コードは先進的なアーキテクチャでなく、一般的な Web サービスを想定としたコードとします。

理論と実装の間に存在するギャップを埋め、モデル図をコードへ落とし込む方法論を学びたい開発者、設計者、プロジェクトリーダーにとって価値ある内容となっています。

◆お話しすること
・イベントストーミング図からPHPコードへの変換手法
・イベントストーミング図を構成する要素の簡単な説明
・ドメインモデルのコード表現
◆話さないこと
・イベントストーミングワークショップの具体的な進め方
・ファシリテーション手法

皆さんもここ数年、会社のいたるところで「自動化」を聞きますよね。
必ずと言ってもいいほど、「こういった処理を自動化したいんだけど、詳しいだろうからやってくれない？」みたいなこと起きませんか？
（場合によっては、「なんか動かないから直して！！」もあると思います）

ただし、言われたものをそのまま「自動化」をすると、「思ってたのと違う」「実はこういうことがしたかったんだよね」「コストかかりすぎない？」となることも多いと思います。

本トークでは、実際にあった「自動化」の例を取り上げながら、考えるべきこと、ヒアリングの仕方などを話していきます。

対象の読者

• よく事業部・営業部などに依頼をされることがある人
• 社内にあるあるフローを自動化をしたいと考えている人