まれにある深夜メンテは遠足気分(?)で楽しかったりしますが、頻繁にあると生活リズムを崩してしまいますし「もし未知のトラブルに遭遇して長時間サービスをダウンさせてしまったら・・・」などの心配も尽きません。

本トークではメンテナンスを日中にやるための交渉術や実現するためのテクニックについてご紹介します。

想定観客

• 深夜メンテをしたくない、部下・同僚にさせたくない人

お話しすること

• 深夜メンテをしない合意形成
  • 希望を伝え続ける、起きたトラブルをダシに使う、お金の話をする
• 日中にメンテをするための考え方とテクニック
  • 影響範囲とリスクを明らかにする、障害を避けるべき時間を明らかにする、ダウンタイムを許容する、ロールバックに備える、後方互換性を確保する

AIをプロダクトに組み込んだとき、従来なかった壁にぶつかりました。実行する度に結果が揺れる非決定論的な出力に対して、どうテストすればよいのか。完全一致を求める従来のアサーションは使えず、人の目での検証には時間がかかり、バリエーションが増えるたびにデグレチェックが困難になるという問題です。

このトークでは、スプレッドシートへの出力が期待通りかどうかを検証するというケーススタディを取り上げます。一方はAIが出力するシート、もう一方は期待値（正解）を示すシートです。出力が予測できないためプログラマティックに検証できません。一方で、AIに検証を丸投げすると精度に不安があります。AIとプログラムの強みを組み合わせることで比較精度の安定と、不一致セルのハイライトのような検証利便性の向上も実現しました。

ケーススタディを通じて、LLMと向き合う際の発想について整理することも目指します。

PHP アプリケーション開発において、Xdebug + IDE によるデバッグ実行を利用している方も多いでしょう。

ブレイクポイントを設定して、そこでアプリケーション実行を停止し、変数の内容を見ながらステップ実行で処理を追いかけていく作業はアプリケーションを理解する上で大いに役立つものです。

一方、便利そうな機能だと認識していても設定につまづいて敬遠している方もいるかもしれません。
デバッグ設定では、PHP(Xdebug) と IDE 双方の設定が必要であり、さらに昨今では PHP(Xdebug) は Docker コンテナで実行しているケースも多いので設定に難しさを感じる場面もあるかもしれません。

デバッグ実行は、Xdebug と IDE の間で行われる通信によって成り立っています。
この通信がどのように行われているか、またそれぞれの役割を知ることで設定のどこでつまづいているかを理解しやすくなります。

なにより、日頃便利に使っている機能がどのような仕組みで実現されているかを知ることは楽しいものです！

本セッションでは、Xdebug の内部動作や IDE との通信に焦点を当てて、どのような仕組みでデバッグ実行が実現しているかを見てみましょう。

クラウドインフラコストを成果報酬型で削減してきたDELTAが新たにPHP/Rubyを第一弾としてバージョンアップの代行を始めました。
コンセプトとしては生成AIを活用して、半自動的にVersionUpができる状態を目指していますが、サービス黎明期の今は1プロジェクトずつ、手作業で泥臭く調査や検証、実行を重ねています。
今回は数あるプロジェクトの中でも、CakePHPの2系を最新バージョンまでアップデートする道のりについて語ります

取り上げる内容

• バージョンアップにおける生成AIの利用方法
• テストのカバレッジが低いアプリケーションのバージョンアップ方法
• (特に)Cake2からCake3へのバージョンアップ時の変更点の多さ
• Cakeのドキュメントのあいまいさと突破した方法
• AIを使って効率化（PRの高速化）を果たしてもレビューで詰まってしまい、プロジェクト自体のアウトカム生産性が高まらない際に実施した方法
• お客さんへ新しいバージョンのお作法やメソッドの変更などの共有

想定

• PHPで構成されたアプリケーションを開発しているエンジニア
• バージョンアップに向き合っている / まだ機会に遭遇していないが、具体実例から準備すべきこと・事前検討すべきことに興味関心がある方

Infrastructure as Code（IaC）とは、インフラ構築をコードや設定ファイルで定義し、再現性や自動化を実現するプラクティスです。IaC によって運用コストの削減やヒューマンエラーの防止といったメリットを得られる一方、導入初期の教育コストや特定メンバーへの依存といった課題も指摘されています。

私たちの組織では、2023年9月に既存サービスの稼働環境を見直した際に、AWS CloudFormation を用いて IaC を導入しました。導入からおよそ2年が経った現在も保守運用しています。

本セッションでは、はじめに IaC に関しての一般的な考え方やメリット・デメリットを解説します。続いて、私たちのチームでの導入に際しての実践内容や切り替えてからの運用の経過について共有します。最後に、IaC を導入してからのチームでの工夫や出てきた課題について紹介します。

IaC 導入での課題を感じられている方だけでなく、IaC 未導入の方や馴染みのない方にも、私たちの実体験から得た知見がヒントとなれば幸いです。

LaravelのQueueは便利ですが、Queueワーカーが裏でどのように動いているのかを知らない人も多いと思います。

ワーカーが内部で何をしているかが分かると、詰まり・遅延・失敗の原因に当たりを付けやすくなり、運用やデバッグがしやすくなります。

このトークでは、ライブコーディングを中心に、LaravelのQueueワーカーをゼロから（ただし必要最小限に簡素化して）実装しながら、php artisan queue:work が実際に何をしているのかを順番に解説します。

「Queueは使っているけれど中身はよく分からない」という人が、処理の流れを自分の言葉で説明でき、トラブル時に切り分けの視点を持てるようになることがゴールです。

近年、量子コンピュータの実用化に向けた開発が急速に進展しています。
その一方で、量子コンピュータの進化は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 での検討状況

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を検討していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き / 得られること

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩 Agent Skills という光
• まとめ

概要

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導入によるパフォーマンス検証
   導入前後でのベンチマーク比較

できるエンジニアは高額の報酬をもらって当たり前、と思っていませんか。
エンジニアは能力の差が大きいので、報酬の幅も大きいと言われています。
ところで、「能力」とは何でしょうか。技術力？本当にそれだけでしょうか。

本トークでは、一般的に受け入れられている能力主義の考え方を批判的に見直し、
概論にとどまらず、現在エンジニアが置かれている状況を整理していきます。
その上で、エンジニアとそのチームにとってより好ましい考え方、ふるまい方を探求します。

気が付けばいつの間にか「能力」にとらわれすぎていませんか。
新たな視点を提供することで、すこしでも解きほぐすお手伝いができたらうれしいです。

Rector、いい感じで強力なPHPのリファクタリングツールです。
「好きなルールで、めちゃくちゃコードを書き換えられる！！」という経験は、味わうと夢のような心地がします。

素晴らしいのは、「単なる置換では出来ない」もしくは「人知を超えた正規表現でも難しそう」な一括自動修正を、
十分に人間が理解可能なルール記述で サクサクと実現してくれることでしょう。

なぜ、そんな事が可能なのでしょうか？その裏にあるのは、テクノロジーです。
コードを「木構造(AST)」として解釈して、様々な「ルール」を適用していくことで、
置換対象の検出と置換の実行を進めます。

そこで役立つのが Visitorパターン です。
「木」という複雑な繋がりを渡り歩き、1つ1つの「地点」で外から与えられたロジックを適用していきます。
こうした作りが、「適用対象の構造自体や、渡り歩き方の実装には全く手を加えず、ただルールを付け外しできる」という拡張性をもたらします。

このトークでは、
「Rectorって凄いな、面白いな！」というワクワクと、
「ドンピシャでデザインパターンがハマると、こんなに気持ち良いのだな！」というドキドキをお届けします。

話すこと

• ごくごく簡単に「ASTってなんだ」
• Rectorの使い方、できること
• Visitorパターンの概要
• 上記を踏まえた「なぜRectorでVisitorパターンなのか」

想定対象

• Rectorってなんだろう？を知りたい人
• 「Visitorパターンが嬉しい場面」を見届けてみたい人

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？コメントを書いておかないと何の条件分岐かわからなくなっていませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
Specificationパターンを使うことで、条件分岐に人間可読な名前をつけることができます。名前をつけるだけで、人間は物事を認識しやすくなりますし、覚えやすくなります。
まず名付けの大切さを日常生活や簡単なPHPコードの事例から解説し、その後にSpecificationパターンを使った実装・リファクタの実例をサンプルコードを共有しながら紹介します。

皆さんDatabaseのIndexはよく業務でも利用していると思います。
ただ、そのIndex、前任者やAI Agentが付けているからとあまり考えずに設定していたりしていませんか？

本トークではMySQLおよびPostgreSQLに絞って、インデックスの付き方やよくあるIndexの間違いなどを皆さんと共有できればと思います。

本トークで話す内容
・採用されているIndexについて
・インデックスの種類について
・よくあるインデックスの間違い

本トークの対象者
・Databaseのインデックスを雰囲気で触れている方や知らない人

私たちは大きな時代の節目にいます。これまで半世紀以上にわたって続いてきたコーディングのあり方が、大きく変わろうとしています。AIによる開発支援は急速に高度化していますが、そのポテンシャルを最大限に引き出すための開発ワークフローやアーキテクチャには、まだ大きな進化の余地が残されています。 AIエージェントが本質的に力を発揮できる、開発ワークフローそのものの再設計が必要です。

本セッションでは、登壇者が開発してきた app-state-diagram（ALPS）, xdebug-mcp, SemanticLogger の3つのソフトウェアを通じて、AIエージェントと本質的に協働するための設計・実装手法「Semantic Build for Agents」を紹介します。

app-state-diagram（ALPS）はアプリケーションの語彙・構造・状態遷移をプロトコル非依存で定義し、設計時の意味を外部化します。xdebug-mcpは実行トレースやプロファイルといった実行時の事実をAIが直接扱える形で提供します。SemanticLoggerは intent→event→result を JSON Schema とリンクで表現し、なぜその結果になったのかを機械可読に証明します。

これらに共通するのは、人間向け説明ではなく スキーマ・ID・URIによって意味を運搬する設計思想です。本セッションでは、仕様・実装・実行結果をセマンティクスで接続するアーキテクチャと、その実践から得られた知見を共有します。

プロダクト開発をしていて、他社のシステムを参考に作ることはないでしょうか？

そんな時、特許権について調べられているでしょうか？（特許権以外にも、実用新案権、意匠権、商標権、著作権などの権利もあります）

他社の特許権を侵害すると、自社製品の販売差し止めや損害賠償請求に発展する場合もあります。

一方で、特許は「発明の保護及び利用を図ることにより、発明を奨励し、もつて産業の発達に寄与することを目的とする」制度でもあります。

ビジネス・プロダクトを守りつつ、公開されている知識をプロダクト作りに活かすために、特許調査について知ってみませんか？

このトークでは、ある仮説を提案します。

技術的負債の、「利率」にあたる部分は開発規模の増加によって見かけ上増える

プロダクトの開発で機能とソースコードが変更されると貸借対照表の借方に新機能によって得られる価値(正味現在価値)が入り、貸方に技術的負債が入ると捉えられます。
この、貸方に入る技術的負債が通常の負債とは異なる性質を持つと言うのが、この仮説の骨子です。

トークでは、貸借対照表や正味現在価値などの用語についても解説を加えます。

この仮説を通して、各チームで
・どの技術的負債をいつどのように解消するか
・個別カスタマイズをすべきかをどう判断するか
・リファクタリングをどのように計画するか
などについて議論を深めるきっかけにしていただくことを目指します。

会計の知識をインストールして、技術的負債というワードに輪郭を与えましょう。

Observabilityにおけるアプリケーションのパフォーマンス監視において、APM（Application Performance Monitoring）は不可欠な存在です。
しかし、これらのツールが「内部でどのように動作しているか?」を理解している開発者は多くありません。

本セッションでは、OpenTelemetry PHP SDKを使用して、シンプルなAPMツールをゼロから自作します。
トレース、メトリクス、ログの3つのシグナルを収集・可視化する過程を通じて、APMの仕組みとOpenTelemetryの設計思想を深く理解することを目指します。商用のAPMツールを「なんとなく使っている」状態から、「仕組みを理解して使いこなす」状態へステップアップしていきましょう!

【セッションの対象者】
・APMを使っているが仕組みを理解したいエンジニア
・Observabilityに興味があるエンジニア

【このセッションで得られること】
APMが内部で何をしているか?の理解
OpenTelemetry SDKの活用方法について

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

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

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

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

本トークでは、経営学のノウハウをいくつか取り上げ、エンジニアの実務でどう活かせるか、具体的なシーンとともに紹介します。

私はCTOになったことをきっかけに、約1年前からMBA（経営学修士）プログラムで学んでいます。
現在はCTOを退任しましたが、今も続けています。
単純に「便利だ」と実感しているからです。

学んでみて気づいたのは、エンジニアリングと経営学のアプローチが似ているということでした。
問題を構造化し、制約の中で最適解を探し、仮説を立てて検証する。
フレームワークで思考を整理し、他者と共有可能にする。
違いは明確な答えがあるかないかです。
エンジニアにとって経営学は馴染みやすく、実務へ接続も難しくありません。

具体的な効果を挙げると、たとえば経営会議では、なぜ経営陣がそのような判断をするのか、その思考プロセスを理解できるようになりました。
また、メンバーとの1on1やメンバーが上程する際のフォローも理論を背景にして行えます。
よりエンジニアリングの文脈であれば、ドメイン駆動設計のサブドメイン等に対する解像度、技術的負債の返済優先度、イノベーションの進め方などのエンジニアリングの判断にもビジネス視点が自然と入るようになりました。
私個人の話でいえば、クリティカルシンキングやファシリテーション、ネゴシエーション等の知識は、レビュー、設計議論、ステークホルダーとの調整等、さまざまな場面に直結するスキルで、もっと早く知りたかったと感じています。

トークの中で紹介するノウハウは、MBAプログラムに通わずとも関連書物を紐解けば習得・活用できるものです。
エンジニアと経営学、その共通点から学びやすさを、そして活用法から相性のよさを感じていただき、皆様のキャリアを広げる新たな要素にしていただけることを目指します。

20000以上のテストケース数を誇るWebアプリについて、2025年5月時点で9並列で約11分かかっていたCIを最終的には5分で終わるように改善しました。また、高速化を終えた後、コスト最適化という面での改善も実施しました。その過程で苦労したことや乗り越えたことなどを事細かに紹介します。

アピールポイント

• CI高速化において、ただお金で殴れば早くなる (例えば並列数を増やすなど) ではなく、コスト最適化も両立させることができたという話をします。

話す予定のトピック

• テスト高速化で実施したこと
  • ボトルネックの計測 (Workflowの時間を計測、プロファイラを利用した分析)
  • 並列実行の最適化 (ジョブ・プロセス毎のテスト時間均一化含む)
  • テストデータの改善 (Factoryの見直しや不要なデータ作成の削減)
  • MySQLの最適化 (tmpfs、my.cnf最適化、ダンプのキャッシュ)
  • Flakyテストへの愚直な対応
• コスト削減に向けて実施したこと
  • サードパーティマネージドランナーの調査
  • 物理マシンを購入し、セルフホステッドランナーとして活用
  • セルフホステッドランナーが落ちた際のフォールバック方法の検討
  • ubuntu-latestをubuntu-slimやself-hostedに置き換え
  • GitHub Actionsの課金体系を理解し、1秒で終わるジョブも1分として切り上げられるため、Jobの見直し
• 「委員会」を通じた改善
  • 私個人の力で全てを実施したのではなく、「委員会」という会社の取り組みの一環として実施
  • https://blog.smartbank.co.jp/entry/2025/07/02/committee-system-introduction