近年、量子コンピュータの実用化に向けた開発が急速に進展しています。
その一方で、量子コンピュータの進化はRSAや楕円曲線暗号といった公開鍵暗号技術の危殆化を意味します。

これに対抗する技術が「耐量子計算機暗号（Post-Quantum Cryptography: PQC）」です。

2024年8月、NIST（米国国立標準技術研究所）は長年の選定プロジェクトを経て、PQCの最初の標準規格（FIPS 203, 204, 205）を正式に発表しました。日本国内でも政府機関が2035年への移行目標を掲げるなど、PQCは実装・運用のフェーズへと大きくシフトしています。

本セッションでは、PQCの基礎知識から、その中心技術である「格子暗号」の仕組みや特徴にフォーカスして解説します。 さらに、AWS、Google Cloud、Azureといった主要クラウドベンダーの対応状況や、PHPエコシステムにおけるPQCの対応状況についても取り上げます。

今すぐにコードを書き換える必要はないですが、PQCは近い将来には当たり前となる技術です。このトークをきっかけに興味を持ってもらえれば幸いです。

【トークのアジェンダ】
・PQCの現状
　　・量子コンピュータの脅威（ショアのアルゴリズム）とHNDL攻撃（Harvest Now, Decrypt Later）のリスク
　　・NIST標準化（FIPS 203, 204, 205）について
・PQC（とくに格子暗号）の特徴について
　　・主要なPQCの紹介（格子暗号、同種写像暗号、符号ベース暗号、多変数多項式暗号、暗号学的ハッシュ関数）
　　・格子暗号の簡単な仕組みや特徴
・各クラウドベンダーやPHPでの対応状況
　　・AWS、Microsoft Azure、Google Cloud の状況
　　・PHP での検討状況

サービスに途中から参加すると、最初の頃はコードとドメインがどのように積み上がってきたのかを追いかけるところから始まります。私が担当しているユーザー領域も、サービスの成長に合わせて機能が増え、その結果としてバリデーションや判定処理がいくつかの層に分散していました。本セッションでは、これらを読み解きながら整理していったプロセスを紹介します。

まず、散在していたユーザーまわりのバリデーションをドメインサービスに集約し、どのような処理をドメイン側で扱うべきかをチームで合意できるよう、簡単なマニフェストを用意しました。また、利用者ごとのケーパビリティを導入し、エンドポイント単位でアクセス制御を行うことで、コントローラへの細かな分岐を避けられるようにしました。

さらに、DB のインデックス追加を安全に進めるために、GitHub Actions から実行できる “alterguard” を開発し、作業手順を極力シンプルにしながら pt-osc を併用できる環境を整えました。これにより、ユーザー領域以外の改善も継続的に進められるようになりました。

成長中のプロダクトに後から加わった立場として、どのようにドメインを理解し、どこから整えていったのか。その具体的な進め方をお話しします。

本セッションでは、「大量のショップが同時刻にセール予約をすると開始遅延や未開始が発生する」という課題に対して、「計測→可視化→ボトルネック特定→個別改善→再計測」というループを元にパフォーマンスの改善をした実践を共有します。

まず New Relic のダッシュボードでCPU・レイテンシ・処理件数を可視化し、遅延要因を特定しました。打ち手は、SNS Publish のバルク化、Active Record での N+1 の一部処理の切り出し、重いセールグループを処理するプロセスごとの負荷の平準化などです。

この改善を実施したことにより、開発環境でおおむね 40% の速度改善に成功。2025年のブラックフライデーでも 10 万商品のセールをインシデントなく完了しました。

ユーザーが直面しているペインを解消するために、技術でプロダクトを泥臭く改善する大切さと華々しい成果だけではなく、根本解決のためにはまだやれることがあるという現場のリアルもお伝えします。

いつでも気軽に、本格的なスパゲッティを手に入れたいと考えていませんか？
次のようなコードを、得る方法を構築しましょう。

• 関数やメソッドを用いたコードの構造化を行わない
• フロー制御はgoto演算子によって行われる
  • gotoでのジャンプを行う場合のみif文を用いる

あなたがいつものようにPHPで書いたコードを材料として、
まるで「レンジでチン！で食品を温める」ように、スパゲッティコードを手に入れる。
そんな「夢の無限スパゲッティ製造機」があったら、どうでしょうか？

構造も制御も低レベルな表現力しか持たない世界に転生させ、その後に再びPHPの世界に蘇らせることができれば、
PHPで作られたスパゲッティの製造が可能です！
本トークでは、ネイティブなスパゲッティを作成してみなさんにお届けします

話すこと

「PHPで書かれたコード → opcodeに変換 → 再度PHPに変換」を行い、「通常のコード」 と見比べていきます。

1. スパゲッティコードの定義と、目指す世界の共有
   • 「スパゲッティ」の要件
   • 「夢の無限スパゲッティ製造機」とは何か
2. opcodeの基礎的な知識と読み方
   • 文法や語彙
3. 夢の無限スパゲッティ製造機の解説とデモ
   • 入力/出力の結果の共有
   • 実装の解説
4. PHPで「真のスパゲッティを目指す」ことの困難性
   • "キレイなgoto" と "ワイルドなgoto"、など

話さないこと

例外処理の実現など、一部のPHPの機能については割愛します
(つまり、どんなコードにも利用できるものではなく、対応する内容には制限があります)

概要

Laravel Octaneは、Laravelアプリケーションを更に高速化させるためのパッケージです。
SwooleやRoadRunnerに加え、Caddy WebサーバーやFrankenPHPもサポートされ、モダンな構成が容易に導入できるようになりました。
しかし、単に「導入すれば速くなる」という理解だけでは、メモリリークやステート汚染といった、便利さの裏に隠されている落とし穴にハマってしまうかもしれません。
本セッションでは、特にLaravel OctaneのFrankenPHPドライバにフォーカスし、
octane:frankenphp コマンドが実行されたその裏側で何が起きているのか、ソースコードレベルで内部実装を紐解いていきます。

話すこと

1. ZTS（Zend Thread Safety）とワーカープロセス
   GoルーチンとPHPスレッドの連携
2. Bootstrapとリクエストのライフサイクル
   アプリの起動とリクエストごとのクリーンアップ処理
3. Octane Cache / Tables の実装と制約
   スレッド間共有メモリの仕組み
4. Octane導入によるパフォーマンス検証
   導入前後でのベンチマーク比較

アプリケーションを運用していると、外部サービスの遅延や内部の重い処理が原因で応答速度が不安定になることがあります。
私自身、サービス間の連携やドメインイベントの実装に取り組む中で、メインフローが時間のかかる処理と密結合していることが、遅延や障害につながるケースを経験しました。

こうした状況では、時間のかかる処理をメインフローから切り離し、QueueやPubSubなどメッセージングを使って非同期で実行するアプローチが有効な場合があります。
これにより応答速度が安定し、メイン処理と周辺処理を分離することで、変更に強い構造を作りやすくなります。

一方で、非同期化には同期処理では現れにくい落とし穴があります。
整合性のズレ、処理順序の乱れ、重複実行など...
適切な対処をせずに導入すると、期待した改善よりも複雑さが増すケースもありました。

本セッションでは、メッセージングによる非同期化を進める際に押さえておきたいポイントを、次の観点から整理して解説します。

• なぜメッセージングによる非同期処理を行うのか
• 非同期処理特有の落とし穴と対策
• 非同期処理をどのように切り分けるのか

イベント駆動アーキテクチャなどメッセージング導入について議論のきっかけになると嬉しいです！

DIコンテナは、Dependency Injection（依存の注入）を利用してクラス間の依存関係の解決を行ってくれます。
具体的には、オブジェクト生成時やメソッド呼び出し時に渡す引数を自動的に生成してくれるなどの機能を有します。
LaravelやSymfonyなど、最近のWebアプリケーションフレームワークの多くにもこの機能が組み込まれているので、普段使っているという人も多いのではないでしょうか。

Autowire機能を持つDIコンテナの場合、コンストラクタやメソッドに型宣言を書いてさえおけば、引数を増やしたり入れ替えたりしても柔軟に動作してくれます。
『これはまるで「魔法」だ』とDIコンテナを知った当時に感じたのを覚えています。

とはいえ、DIコンテナもただのプログラムです。実際には魔法などではなく、PHPのコードとして実装されているのです。

このセッションでは、Autowire機能がどのように実装されているのかを紐解きます。その上で、Autowireによるコンストラクタインジェクション機能を持つDIコンテナを実装してみます。
DIコンテナの裏側を理解し、普段ブラックボックスになっているフレームワークの動作の一端を覗いてみましょう。

話すこと

• DIコンテナのAutowire機能の実装に必要な技術
• Autowire機能を持つシンプルなDIコンテナの実装方法

話さないこと

• DIを用いたソフトウェア設計について（依存関係逆転の原則など）
• 特定のDIコンテナライブラリの詳細な使い方

ウェブアプリケーションの品質担保は重要課題です。しかし、2001年にローンチされた弊社のメール共有サービス「メールディーラー」のようなレガシープロダクトはより深刻です。

フレームワークを持たず、DBアクセスとHTML生成が単一プログラム内で混在する「スパゲッティコード」が構造を陳腐化させました。
このためコード全体の把握が困難になり、修正前の十分な影響調査ができない状態を生み出しました 。

実際、新機能リリース直後に改修していないはずの機能で「画面が表示できなくなる」という致命的な障害が発生。
この「意図せぬ機能破壊」に対し、理想は大規模リファクタリングでしたが、現実的なコストと期間ではありませんでした。

そこで私たちは、リスクを抑えつつ最低限の品質を担保する戦略的な選択として、E2Eテストの導入を決断しました。

本トークでは、私がテクニカルリーダーとして主導した、限られたリソース（3ヶ月）でのE2Eテスト導入戦略を公開します。

・複雑な内部構造を持つレガシーシステムに対し、テスト対象のスコープを切り出し、導入の投資対効果を最大化した手法。
・テストコード実装とテストケース作成において、スパゲッティコード特有の難しさをどのように克服し、273画面のカバー率を達成したか。
・導入後に「致命的な不具合の発生ゼロ」という具体的な成果をどのように勝ち取ったか。

本セッションは、レガシーシステムの品質改善に取り組むエンジニアに向けた、実践的な E2E テスト導入事例の共有です。
困難な環境下でのテスト戦略策定方法と、既存プロダクトへの段階的な導入テクニックと、
開発チーム全体に客観的な安心感をもたらすための確かな知見を持ち帰ってください。