PHP カンファレンス 2025に参加してきました！

GitHub Copilot Agentとは、GitHub Copilot が提供するチャット形式のAIコーディング支援機能です。

会社で導入するにあたって、やるべきステップがわかりました。

新しいものを導入のときのハードルはかなりあると思います。
使いやすさ、作業効率の有無、導入後のメリット・デメリットを導入の際にイメージ出来ていないと、効果が出せずに終わってしまうかもしれません。

また、チームメンバーと共有するプロンプトを用意しておくというのもとても良いなと思いました。
メンバーによってプロンプトの内容、明確さにばらつきがあると、AIも的を得ない回答をしてしまうかもしれません。

ある程度、社内でプロンプトのレベル感を統一しておくことで、AIから期待通りの回答を得られやすくなるかもしれません。

GitHubのIssueやプルリクエストを作成するプロンプトは、あまりイメージが出来ませんでしたが、この点については勉強して有用なものであるか判断出来たらと思います。

try-catchは普段使っていますが、けっこう曖昧な使い方してました。

try で囲んだ処理内で、エラーが発生すると、例外がスローされ、catch 節でその例外を受け取り、例外処理を行うのが一般的な使い方です。

例外を「ビジネスエラー」と「技術的エラー」に分けて考えることが重要なポイントです。

具体的には、注文処理時の在庫切れ等のビジネスロジックで発生する失敗を「ビジネスエラー」、DBコネクション障害、ネットワーク障害などシステムレベルで発生する異常を「技術的エラー」として考えるということらしいです。

「ビジネスエラー」は、例外として扱わずに、成功時の処理結果と同じように考慮すべきということです。

この考え方に関連するResult型という仕組みがあり、Result型では、処理結果が「成功(OK)」か「失敗(Error)」のどちらかであることを表し、unwrapメソッドによって、成功時の値を取り出す操作が出来るようです。
失敗時に、unwrapを呼ぶと例外をスローされるため、失敗を明示的にすることができ、しかもcatchをたくさん書かずに、スマートに書けるということです

この考え方の理解がまだ追いついていないのもあり、今後の学習ポイントです。

LaravelでのXSSの対策で、bladeでの {{ $var }}は、内部的にhtmlspecialchars()が実行されてエスケープされますが、{{!! $var !!}}は、エスケープされないので、注意が必要。

ただし、 {{ $var }}の内部処理では、e関数[e()]が使われています。
e関数内部では、文字列が Htmlable かどうかを判定していて、Htmlable であれば toHtml() の結果を返す処理があるとのこと。

例えば、MarkdownのようにHTMLとして出力する場合、jsを含んだMarkdown文字列を引数に与え、{{ $var }}で出力した際、XSSが発生してしまうようです。
そのような場合は、Htmlableインスタンスでないかの確認する必要があります。

XSS対策は奥が深いと思いました！

PHPとGoでの違いの説明でしたが、展開が早すぎてついていけず…。

インターフェイスは苦手ですので、スライドを見直して、理解していきますっ(汗)

ReactNativeは知っていますが、「NativePHP」は初めて耳にしました！

PHPで、デスクトップアプリ、モバイルアプリが作れてしまうという画期的なもの。

NativePHPは、Laravelをベースに、Electronと連携して動作するフレームワークです。
（Electronとは、HTML、CSS、JavaScriptを利用して、MacとWindowsの両方で動くデスクトップアプリを作ることができる技術です。）

Laravelのコードを書くことができれば、作れてしまうととのことでハードルは低そうです。
実際に作るとしたら、デスクトップアプリよりもモバイルアプリとして作ったほうが、利用価値が高まりそうです。
NativePHPで作ったアプリをGoogle Play ストアやAPP storeに公開するためには、PWA化するなど、何らかの対応は必要かもしれませんが、公開が可能であれば、機能提供出来るので、メリットはありそうですね。

この登壇の中では、データベースに関わるところの説明が無かったので、やはりAPIを通じて、サーバー上のデータベースからjson形式でデータを受け取るという方式になるのでしょう。

「車輪の再発明」は絶対やめようということで、既に存在するライブラリは積極的に利用し、開発コストを下げる意味でも、composerを活用していくべきと思いました。

composerを利用していないプロジェクトがある理由として、「導入すると何らかの弊害があるのではないか」という不安から導入を拒むケースが多いとのこと。
確かにcomposerの仕組みを十分に理解していない立場からすると、手を出したくない気持ちはわかります。

また、composer.jsonをどのプロジェクトでも、同じパッケージを使うのではなく、取捨選択をして必要なものだけを利用するのが良いということは印象的でした。

普段は、dockerで環境構築していることが多く、最適なcomposer.jsonが既に含まれているので、あまり触る機会がありませんでしだか、積極的に使ってみようと思います。

この登壇を聞いてcomposerが怖くなくなったような気がしました

Inertia.jsとは、バックエンド（Laravel）とフロントエンドを橋渡しをする役割を持つライブラリです。

従来の SPA 開発では、APIを用意し、フロントエンド側で状態管理を行いながらデータを取得して描画する必要がありましたが、APIを作成することなく、Laravelのコントローラーから直接フロントエンドへデータを渡し、画面を描画出来るということです。

バックエンドとフロントエンドの役割を明確に分けつつ、API を挟む煩雑さを解消できるというがメリットであると感じました。

今後試してみたいと思った技術の一つです。

Composerが内部で行っている処理のお話で、パッケージの依存関係をどのように解決しているのか、概要はわかりました。

こんなことをしているんだなということが分かりました。

依存関係の解決は手動で行うととても難しいので、Composerの恩恵に感謝しつつ、あまり深く追求せず、開発に集中したほうが良さそうです…。

RLS（Row-Level Security）は、PostgreSQLのテーブル単位で、行レベルでのアクセスを制御できる機能です。

複数の会社（テナント）のデータが同一テーブルに格納されている場合、そのテーブルにRLSを設定すると、
クエリ実行時にユーザーに紐づくtenant_idなどの条件が自動的にWHERE句として付与され、他のテナントのデータが参照・更新できないように保護できるようです。

コスト面で、会社ごとにデータベースを用意出来ない場合に、この方法を利用することで、一つのデータベースだけで良いので、コスト減に繋がりそう。

複数の会社で共通して利用するマスタテーブルについては、会社情報に依存しないためRLSの設定を行う必要がなく、マスタデータを追加修正の際、運用管理の手間がかからなくて良いと思いました。