トーク

株式会社プログリットではLaravelをメインで利用し、さまざまな英語学習のアプリを開発しています。

近年、生成AIの登場によりこれまでは開発困難であったさまざまな機能が実現できるようになりました。
英語学習においては、ユーザに最適化されたフィードバックや、インタラクティブに変化するテーマやコンテンツなどを扱えるようになりました。
それによって、より効率的な学習体験を提供することが可能になり、新しい機能のアイデアがどんどんと生まれていきました。

しかしながら商用利用に当たっては、PHPの公式のSDKなかったりその他ライブラリが他の言語と比較して少ないなどいくつかの障壁がありました。
そこで我々は、これまでで開発した既存のリソースを活かしつつ、Pythonで書かれたAI関連の処理組み合わせるハイブリットなシステムを設計しました。

• AWS Lambda を利用したAIチャットボット開発と技術検証
• AWS Step Functions による添削システムとプロダクトへの組み込み
• FastAPI 統合で実現するAIネイティブな英会話アプリ開発

これまで開発した機能やプロジェクトの一部実例を踏まえしつつ、いかに生成AIを活用したアプリ開発を実現してきたのかご紹介させていただきたいと思います。

想定聴講者
・生成AIを活用した機能開発を行いたい
・PHPで構築された既存システムがある
・既存システムを活用しながら開発を行いたい

PHP 8.4では、BCMathにオブジェクトAPIの追加と処理の高速化という大きなアップデートが行われました。このトークでは、BCMathの処理速度向上について詳しく解説します。まず、従来のBCMathが「なぜ遅かったのか」を明らかにし、その問題点を具体的に説明します。その後、新しいコードの改善点や実装方法について詳しく説明します。普段PHPを使用する際には見えない部分であるメモリ管理やCPUの処理が主なテーマとなります。これにより、BCMathの内部動作への理解を深めていただける内容となっています。

2012年に日本初のふるさと納税ポータルサイトとして立ち上がった「ふるさとチョイス」は、最後のリニューアルを2018年3月に行い、そこから開発・運用を続けてきました。

リニューアル当時はPHP7.4 + FuelPHP1.8.2で構築されていましたが、言語のEOLに伴ってこの度PHP8.3 ＋ FuelPHP1.9-Dev へアップデートしましたため、
その時のつまづきポイントや苦労したところなどをお話させていただこうと思います。

PHPのバージョンアップはここ数年で実施している所も多く、目新しい構成や情報はそれほど多くないかもしれませんが、今後もアップデートを実施してく方の参考・助けになれば幸いです。

お持ち帰りポイント
・既存のリリースを止めずにバージョンアップを完遂させた方法と、想定通りに行かなかったポイント
・トラフィックの切り替え方法とその際の失敗パターン
・移行に伴って苦労したのはテンプレートエンジンでした（弊社はPHPTALを使用）

ふるさとチョイスの数字的特徴（2024年10月時点）
・PV：2億 / 月
・品の数：76万超
・利用自治体数：1700超
・決済種別：14種類

技術スタック
・PHP7.4
・FuelPHP1.8.2
・PHPTAL1.2.2
・MySQL5.6

ふるさとチョイス開発組織の特徴
・開発部門の人数： 80人
・リリースチケット件数：約25件/週

【会社紹介】
トラストバンクは、2012年に設立。第2創業期のITベンチャー企業です。
「ヒト」「モノ」「おカネ」「情報」を日本中に循環させ、地域の経済循環を生み出すことがビジョン「自立した持続可能な地域をつくる」の実現に繋がると考え、
ふるさと納税事業・パブリテック事業（自治体業務の生産性向上を促進）・地域通貨事業など、様々な事業を展開しています。

クイックには15年以上にわたり、社内の売り上げを支え続けてきた基盤システムが存在しました。
このシステムは、事業ドメインの変遷に合わせて不断に拡張され、事業の成長を支えてきました。
しかし、その結果として、巨大なモノリシックレポジトリ、仕様書の欠如、1ファイルに集約されたJavaScript、そして無数のマジックナンバーという問題があり
不具合の発生頻度増加、開発生産性の低下、追加開発の難易度上昇といった「技術的負債」が無視できない状況になっていました。

本トークでは、問題を安全に解決するための戦略と、fuelPHP（PHP version 7.3）からLaravel（PHP version 8.2）へのリプレイスを行いつつ
フロントはJavaScriptからReact/TypeScriptへ移行した事例についてお話します。

具体的には以下のトピックについてお話させて頂きます。

• 実現可能性を高めるスケジューリングと決め事
• 開発環境の技術選定とその選定理由
• Inertia.jsによるLaravelとReactの親和性向上
• 基本的なアーキテクチャ設計のアプローチ
• 安全なリプレイスのために行った対応策
• リプレイスの具体的な成果

技術的負債を抱える皆様にとって役立つ情報を提供できれば幸いです。
ぜひ、このセッションを通じて、皆様のプロジェクトの成功につながるヒントを得ていただければと思います。

文字コードがEUC-JPのソースコード編集で直面した問題とその解消法に着いて話します。

話すこと

• なぜソース編集しただけで文字化けが起こるのか
• git diff をちゃんと見よう
• pre-commit hookで安心を得よう

CQRSは、読み取り操作と書き込み操作を分離することでシステムの効率性を向上させる設計パターンです
本来は大規模で複雑なシステム設計で用いられることが多いですが、あえて小規模・シンプルなケースでCQRSを採用した場合、その真価をどのように引き出すことができるのでしょうか？

このセッションではAWSのサーバーレスアーキテクチャを活用することで問題解決に取り組みます
複雑さを抑えつつ柔軟性と拡張性、コストメリットと実装コストのバランスを考え小規模システムにおける適用の意義について考察します

具体的には、DynamoDBをデータストアとして活用し、DynamoDB StreamsやAWS Lambdaを組み合わせることで効率的なデータ同期を実現します
またAPI Gatewayを使用したデータ提供やAWS X-Rayを用いたモニタリングによる運用の最適化も触れ、シンプルなユースケースでも長期的なコストメリットを享受できる設計が可能になります

さらにシステム設計における現実的な課題として、データ同期の遅延や書き込み負荷の増加についても触れ、
最終整合性の採用やSQSによるリクエストのバッファリングなどの解決策を提示し、生成AIを用いた学習コストの低減についても触れます

AWSを活用したCQRSの実装例を通じて、シンプルなケースでも有効な設計手法を学び、シンプルなシナリオでもCQRSを採用する意義を再発見しましょう！

• 対象者

  • CQRSに興味があるエンジニア
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでのコスト効率を追求したい開発者

• 想定学習成果

  • CQRSの基本的な考え方とサーバーレスを利用した実装方法を理解
  • 小規模システムにおけるCQRS導入の具体的メリットと課題を把握

CQRSは、読み取り操作と書き込み操作を分離することでシステムの効率性を向上させる設計パターンです
本来は大規模で複雑なシステム設計で用いられることが多いですが、あえて小規模・シンプルなケースでCQRSを採用した場合、その真価をどのように引き出すことができるのでしょうか？

このセッションではAWSのサーバーレスアーキテクチャを活用することで問題解決に取り組みます
複雑さを抑えつつ柔軟性と拡張性、コストメリットと実装コストのバランスを考え小規模システムにおける適用の実装例を提示を行います

具体的には、DynamoDBをデータストアとして活用し、DynamoDB StreamsやAWS Lambdaを組み合わせることで効率的なデータ同期を実現します
またAPI Gatewayを使用したデータ提供やAWS X-Rayを用いたモニタリングによる運用の最適化も触れ、シンプルなユースケースでも長期的なコストメリットを享受できる設計が可能になります

AWSを活用したCQRSの実装例を通じて、シンプルなケースでも有効な設計手法を学び、シンプルなシナリオでもCQRSを採用する意義を再発見しましょう！

• 対象者

  • CQRSに興味があるエンジニア
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでのコスト効率を追求したい開発者

• 想定学習成果

  • CQRSの基本的な考え方とサーバーレスを利用した実装方法を理解
  • 小規模システムにおけるCQRS導入の具体的メリットと課題を把握

• 話さないこと

  • 課題に対する細かな解説と考察内容
  • 実装に対する細かな解説（GitHubでのソースコード解説を用意します）

Laravelのoptional()関数を使ったことはあるでしょうか？
Nullである可能性のあるオブジェクトに対してoptional関数を用いることで、nullでない時はオブジェクトの動きをさせ、nullの時はnullを返させることができるようになります。

optional関数を使って実装していたある日、ふと「どのようにして動いているのか」が気になりました。
調べてみると、Null Objectパターンというものを使って実装されていることがわかりました。

このトークでは、簡単なNullオブジェクトを自作することで、optionalがどのように実現されているのかを見ていきます。

話すこと

• optional関数の説明
• Nullオブジェクトの実装方法
• Nullsafe operatorとの比較

php-fpm は PHPアプリケーション の実行環境として広く利用されていますが、その内部処理についてご存知でしょうか。

PHP プログラマから見ると、php-fpm はランタイムですが、php-fpm 自身は単に C 言語で実装されたアプリケーションにすぎません。これは我々が日頃から実装している PHP アプリケーションと領域や抽象度は異なりますが、一つのアプリケーションであるという点は同じです。

ただ、php-fpm ではより低いレイヤを扱っています。これは PHP アプリケーションレベルでは隠蔽されている処理が実装されているともいえます。普段、PHP コードを書くだけであればこうした底レイヤを意識する必要はありません。しかし、こうした下のレイヤがどのように動作しているのかを知ることはより深く PHP とそして自らが書いた PHP コードの挙動を理解することができます。そして、何より自分が書いたコードが内部でどのような仕組みで動いしているのかを知ることは楽しいものです！

本セッションでは、一歩レイヤを下りて、php-fpm がリクエスト受信から PHP アプリケーションを実行してレスポンスを返すまでの流れを内部実装やデバッガを元に追いかけてみましょう。

opentelemetry 拡張では任意の関数やメソッドをフックして、実行前後に PHP コードを差し込むことができます。つまり、DB への SQL 文発行や外部 API 呼び出しなどの実行をフックして計測コードを追加して計測を行っています。この機能は自動計装で有効であり、いくつかの自動計装パッケージではこの機能が利用されています。

PHP は内部の主要な関数が関数ポインタとなっているので、内部処理を差し替える、いわば内部動作をハックすることでこうした機能は実現可能でしたopentelemetry 拡張ではどのような仕組みで動いているのだろうと調査したところ、PHP 8 から追加されている Observer API （通称）で実現されていることが分かりました。Observer API を利用することで内部関数を差し替える事なく、関数やメソッドをフックする処理を追加できるようになっています。

この仕組みは PHP 内部で実装されているものなので、PHP コードから直接利用することはできません。つまり、独自に PHP 拡張を実装するか、opentelemetery 拡張のようにすでに実装されているものを通じて利用することになります。実は、opentelemetry 拡張以外にも Datadog の PHP 拡張である dd-trace では Observer API が利用されており、間接的に利用している人もいるかもしれません。

このセッションでは、PHP の Observer API という興味深い機能に焦点を当てて、その動きや PHP 内部の実装を見ていきます。

Web アプリケーションのセキュリティ設計において、特定のユーザーに対してどの操作を許可するかという認可の設計は欠かせない要素です。近年では、マイクロサービスやゼロトラストの考え方が普及し、サーバー間の認可を含むより複雑な機能が求められています。

このような複雑な認可を効果的に管理する方法の一つとして、認可ロジックをアプリケーションから分離し、外部化して再利用可能なポリシー言語で定義する手法があります。AWS IAM はこのようなポリシー言語の一例ですが、AWS に限定されない一般用途にも Open Policy Agent (OPA) が広く知られています。

本セッションでは、認可の課題に対する新たなキラーソリューションとして、Cedar を紹介します。Cedar は AWS によって開発されたポリシー言語で、Amazon Verified Permissions としてマネージドサービスが提供されているほか、AWS 以外の環境でも使用可能な OSS としても公開されています。

OPA と比較した Cedar の顕著な特徴は、大量のルールを定義した場合のパフォーマンスにあります。このパフォーマンスは、一度評価された条件を部分的にキャッシュし再利用する仕組みにより実現されており、そのキャッシュ戦略の正当性は数学的に厳密に証明されています。このように、Cedarは高度な理論が実際のプロダクトに価値を提供する興味深い事例といえるでしょう。

Cedar は 2024 年に論文が発表されたばかりであり、理論的な詳細に関する日本語情報はほとんど存在しません。そのため、本セッションでは参加者が認可エンジンの内部機構と特性を深く理解し、実際のアプリケーションのセキュリティ設計に役立てられることを目指して、Cedar に対して応用と理論の両面から Deep Dive します。

PHPで大量データを扱う際、コードが正しく動いていても、パフォーマンスの低下が発生し、ユーザーの離脱につながったりすることがあります。
本トークでは、私たちのプロジェクトで直面した「strposによる文字列検索が原因で処理が30秒以上かかった」事例をもとに、計算量の重要性とパフォーマンス最適化についてお話しします。

問題の背景は、数千件の文字列を1件ずつ、約1万件の集合と照合する処理でした。
文字列の部分一致のチェックをstrposで実装していましたが、線形検索（O(n)）のため、1回の検索がミリ秒単位でも、繰り返し処理が積み重なり、最終的には数十秒に達しました。
処理の遅延が原因でタイムアウトが発生し、ユーザーが機能を使えない危機に直面しました。

解決策として、array_flipとarray_key_existsを用いて、検索処理をハッシュベース（O(1)）に変更することで、処理時間を30秒から約6秒に短縮しました。
この経験を通じて、パフォーマンス問題を解決するには計算量の意識が不可欠であると学びました。

このように、1回の処理がわずか1ミリ秒遅延しただけであっても、大規模データでは致命的な影響を与える可能性があること、計算量や計算時間が特に大事になってくることを学びました。
このようなパフォーマンス改善は、ユーザー体験を向上させ、機能の価値を最大化するための重要なステップです。
ユーザーが快適に使える環境を提供するため、私たちエンジニアが取り組むべき課題を一緒に考えてみませんか？

「とりあえず削除フラグ」という言葉を、耳にしたことがある方は多いかと思います。
削除フラグは、データを物理的に削除せず、論理的に削除された状態を示す方法で、一般的にデータベース設計で使用されます。
これはデータベースのテーブル設計におけるアンチパターンとして、数多くの技術書で取り上げられているものです。
一般に、論理削除の実装方法としてフラグをテーブルに持たせるのは推奨されていません。論理削除を本当に採用すべきかどうかを慎重に検討するべきです。

それはそうなんですが、アンチパターンって実際に踏み抜いてみないと何でダメなのかわかりにくくないですか？
今回私は、既存のテーブルにあった削除フラグを安易に利用してしまい、想定外の箇所でもトラブルが発生し、改めて削除フラグの利用は慎重にしたほうがいいんだな、と
痛みを伴いつつも理解したので、みなさんには擬似的な痛みだけで済むように何が起こるのか、どんな状況だったか、どうすればよかったのか？などを説明します。

現在、我々のプロダクトではDDD（ドメイン駆動設計）とレイヤードアーキテクチャを採用しています。
しかしメンバー変更や技術的制約などの背景から、コントローラにビジネスロジックが散らばる・重複判定がDBのキー制約に依存しているなどの課題が発生しています。
これにより、コードの凝集性が損なわれ、責務が不明確になり、保守性や拡張性の低下を招いていました。

本トークでは、「ビジネスルールのうちどこまでをドメインモデルで担保すべきか？」という問いを中心に以下のポイントをお話します。

• ビジネスルールが散らばることでDRYやSOLID原則に反してしまい、結果起こり得るリスクと影響
• ドメインモデルに担保させるべき責務の境界線はどこまでか
• 責務を整理し、ドメインモデルを中心とした設計を再構築するための”Package By Feature”などの具体的なアプローチ

このセッションを通じて、ドメインルール整理の重要性を理解し、設計上の責務分担を考える時の具体的な指針を共有し、皆様のプロジェクトに役立てていただければ幸いです。

概要

私たちのチームが手がけるLaravelで構築されたサービスは、Layered Architectureを採用しており技術ごとにクラスやフォルダを分けていました。
6年以上運用されているこのサービスでは、アプリケーションの拡大に伴いディレクトリ構造が複雑化し、新機能追加時に複数のレイヤーにまたがる変更が必要となるなど、コード修正の困難化や影響範囲の肥大化といった課題に直面していました。

この課題を解決するために、私たちは機能ごとにクラスやフォルダを分離する考え"Package by Feature"という設計手法を採用しました。
本トークでは、術ごとの分離ではなく、機能ごとにコードを分離することで得られるメリットと、その実践例を実際の適用事例を通して共有します。

話す内容

• 機能単位でコードを分離するアプローチの概要とその目的
• 技術単位での分離との比較による利点
• 機能単位でコードを分離することで、他の部分への影響がどのように最小限に抑えられ、テストやデプロイまでがどれほどスムーズになったか
• 直面した具体的な課題と、それに対する解決策
• 複数の"Feature"間でデータやロジックを共有する必要がある場合の具体的な対処法と実例

本トークを通じて、よりスケーラブルで保守性の高いコードベースを構築するための手がかりを共有できたら幸いです。

PHP開発者の皆さん、普段から使用しているvar_dumpやvar_exportの関数について、内部でどのように動作しているのかを考えたことはありますか。
このトークでは、これらの関数の違いを簡単に紹介しながら、PHPのソースコードをC言語でどのように実装しているかを一緒に読み解いていきます。

var_dumpとvar_exportは、あらゆる変数を扱える強力なツールです。これらを詳しく読むことで、PHPの型や変数がどのように動作しているのかを深く理解することができます。
具体的には、php-srcのvar.cファイルやZendのマクロ関数を順に追いながら、PHPの細かい仕様について紐解いていきます。

このセッションは、php-srcのソースコードリーディングを初めて体験したい方や、過去に挑戦したことがあるけれども細部まで追ったことがない方を対象にしています。
このトークを通じて、PHPの詳細な仕様を理解するために「php-srcを直接読みに行く」という選択肢が広がることを願っています。

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則には、「英語の文法」にヒントが隠されているかも...?
英語文法の基本ルールに着目することで、設計原則を詳しく知らなくても、シンプルで明確な設計を行うための手がかりを得られるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• ソフトウェア設計に詳しくはないが興味を持っている方
• 設計の原理や手法が多くてなかなか手を出せずにいる方

PHPは型安全性の向上を目指して進化していますが、ジェネリクスを直接サポートしていないため、柔軟性と安全性を両立するには工夫が必要です。その解決策のひとつが、PHPDocの@templateタグを活用してジェネリクスを再現する方法です。

このセッションでは、PHPDocの@templateタグを活用してOption型を実装する具体的な手法をお伝えします。
Option型は、Rustなどの言語で採用されている設計で、値の存在（Some）と不在（None）を型で表現します。

これをPHPに応用することで、次のようなメリットを得られます：

• 型安全性の向上によりバグのリスクを軽減
• nullチェックの削減でコードの可読性を向上
• 設計が明確になり保守性が向上

本トークを通じて、PHPDocを活用した型安全性の向上方法を学び、実際の開発に役立てていただければと思います。
PHPDocで型システムを最大限に活用しましょう！

デザインシステムって「ルールの塊」や「UIライブラリ」みたいなイメージを持ちます。でも実際は、それだけではありません。デザインシステムの本質は、 運用を含む仕組み にあります。

たとえば、デザインレビューを通じて品質を保ったり、デザイナーとエンジニアでフィードバックをし合いながら改善を続けたり、変更があったときにガイドラインやドキュメントを更新して全員が迷わないようにしたり。これらの運用があってこそ、デザインシステムは単なるルールやライブラリから「使えるシステム」に進化していきます。

このセッションではプロジェクトでデザインシステムを立ち上げた経験を元に「どう作るか」「どう運用するか」をエンジニア視点でのポイントを紹介します。

組織によっては、フロントエンドの専門エンジニアがいないケースも多く、バックエンドエンジニアがフロントエンドを兼任することがあるかと思います。そのような組織においては、フロントエンド領域における技術的課題が溜まりがちではないでしょうか。

私が所属していたチームでもそのような課題を抱えていました。特にフロントエンドのテストが非常に乏しく、ちょっとした変更のたびにマニュアルでのテストが必要な状態でした。

このトークでは、バックエンドを主担当としてきた私が、フロントエンドテストの拡充するために行った取り組みを紹介したいと思います。主に以下のお話を考えています。

• フロントエンドテストのキャッチアップをどのように行ったか。
• リファクタリングを容易にするために、関数単位のユニットテストよりも、コンポーネント単位のユニットテストを重視。
• フィーチャー開発の手を止めずに実現した、朝の30分活動でのテストコード追加。
• チームメンバーに浸透させるために行ったハンズオンや、AIコードエディタ(Cursor)によるテストコード生成。

このトークを通じて、バックエンドエンジニアでもフロントエンドテストを充実させることが可能であることを示し、参加者の組織におけるテスト拡充の一助となれば嬉しいです。