トーク

このトークではAIエディタである「Cursor」を用いて、既存コードベースから仕様書を生成・整備する取り組みを紹介します。

私が実務で関わっている一部のプロジェクトでは、長年運用された独自のPHPフレームワークを採用しています。
しかし、ドキュメントは少なく、新規参入者が仕様をキャッチアップしづらい状況を課題に感じていました。

その課題に対して、実際にCursorを使って仕様書を作成した経験をもとに、メリットや実運用における課題、注意点についてお話しします。

主な内容：
・Cursorを使ってコードから仕様書を作成する方法、コツ
・AIエージェントによる仕様書作成のメリット、課題

こんな方におすすめ：
・コードが唯一のドキュメントという状況から抜け出したい方
・AIエディタである「Cursor」に興味がある方

カンファレンスのトークで魅力的に語られる、設計の工夫や実践的なテクニック、新しい技術・ツール、チームの取り組みや開発スタイル。
「こんな開発をしてみたい！」「この仕組み、自分のチームでも導入したい！」と気持ちが一気に高まり、現場に戻って何かを変えたくなった経験、ありませんか？

でも現場に戻ると――
・どうやって導入すればいいのかわからない
・他にも問題のある部分が多すぎて、導入できる気がしない
・そもそもチームに受け入れてもらえるか不安

といった理想と現実のギャップに葛藤することもあるかもしれません。

このトークでは、自分の興味や気づきを出発点に、まず1人で実践しながら理解を深め、その後チームメンバーを巻き込んでいき、少しずつ変化を広げていった経験を紹介します。

もちろんすべてを導入することはできませんし、するべきではありません。
その時の状況やチームの課題を認識し、何を取り入れ、どう伝えていくか戦略を練っていきましょう。

そうして重ねた小さな一歩一歩が、やがてチームの空気を少しずつ変え、開発がより楽しく感じられるようになるかもしれません。
そんな変化のプロセスをお届けします。

本トークでは、Androidエンジニアである私が、AIを活用しながらPHPでの開発タスクに取り組むようになったプロセスをご紹介します。
もともと自分自身がPHPを業務で扱ってみたいと思い、サーバーサイド業務に挑戦することにしました。はじめは戸惑いや苦労もありましたが、AIを効果的に活用することで学習をしタスクをこなせるようになった実体験をお話しします。
AIの活用による学習プロセス、具体的なPHPタスクをどのように解決していったかなど、実践的なノウハウを中心にお伝えします。また、異なる技術領域にチャレンジする際の考え方や、AIを使ったスキルアップの可能性についても触れます。

こんな方におすすめ：
バックエンド未経験のフロントエンド／モバイルエンジニア
新しい技術領域への挑戦方法を知りたい方

主な内容：
AndroidエンジニアがPHPタスクを担当することになった経緯
AIを活用したPHP学習と具体的な問題解決方法
技術スタックを広げる際のマインドセットと、AI活用による効率的なスキルアップ

本セッションでは、OpenAPIの定義ファイルを運用する際に静的解析やフォーマッターを導入する方法やメリットについてお話しします。

OpenAPI仕様は、RESTful APIの設計と記述に広く使用されており、APIの構造を明確にし、開発者間のコミュニケーションを改善します。しかし、スキーマ定義が複雑になると、エラーの発見や保守が困難になることがあります。これに対処するためには、静的解析ツールとフォーマッターを導入することで、コード品質を向上させ、一貫性を保つことができます。

本セッションでは、OpenAPIスキーマ定義に対して静的解析ツールとフォーマッターを導入し、以下の目標を達成する方法をお伝えします。

• スキーマ定義のエラーや不整合を早期に発見
• スキーマ定義のコード品質を向上
• 開発者間のコードスタイルの一貫性を確保
• メンテナンスの容易化

PHPerの方には、最近弊社はGoに移行しているんだけど、PHPの膨大な既存コードも捨てがたい、、、なんて思ったことはありませんか?
既存のPHPコードから、順次移行したGoを呼び出せればいいのにな、、、そう思う方も多いでしょう。

PHPにはFFI (Foreign Function Interface) という、「純粋なPHPでCの関数をコール」できる拡張があります。
実はこれを使えば、Cだけでなく、Goの共有ライブラリを(なんとか)呼び出すことができるのです!

このトークではPHPからGoの共有ライブラリを呼び出す方法と、その具体的な活用例について共有し、FFIの可能性に触れてみます。

話すこと

• PHPからGoの共有ライブラリを呼び出す方法
• この方法で想定されるユースケース (自社独自のロジックを複数プロジェクトで使い回すなど)の紹介

チャットでのコミュニケーションに苦手意識を感じていませんか？

COVID-19パンデミック以降、多くの企業でリモートワークが導入されました。
その結果、ここ数年「出社して対面でコミュニケーションしながら業務を進める」という経験がほとんどない層が増えてきたと思います。
今回これを「リモートワークネイティブ」と名付けてみました。私（2023年新卒）もその1人です。

さて、リモートワークで重要になるのが、Slack等のチャットツールを活用したテキストコミュニケーションです。
しかしいざ送信してみても、意図が伝わっていなかったり、欲しい内容とは異なる回答が返ってきたりして、余計なコミュニケーションコストがかかることも少なくありません。
このように、テキストでのコミュニケーションには、対面で話すのとは異なる意識やコツが必要です。

特に私のような若手は、業務に関して質問をしたい機会が多々生じ、都度「よりよいチャット」について考えてきました。
本LTでは、"リモートワークネイティブ"な私が、新入社員時代から試行錯誤しながら会得したチャット作文のポイントを共有します。
余計なやり取りを増やさず、聞く側も答える側もハッピーなコミュニケーションを目指しましょう！

対象

• チャットで質問する機会の多い人（特に、どう伝えれば良いか悩むことが多い人）
• チャットでの質問に答える機会の多い人（特に、何が伝えたいのかわからないことが多い人）

「この設計、本当にいいのか？」そう迷ったとき、ずっと考えているだけでは答えが出ない──そんな経験はありませんか？
このLTでは、まず手を動かしてみる、壊してみる、またすぐ書いてみる
そんな軽やかな反復によって設計を確かめるアプローチを紹介します

近年、生成AIやコード補完ツールの進化により、考えたことをすぐ試せる環境が整いました
この流れの中で生まれた文化のひとつが「VibeCoding」
BGMや気分に乗せて、直感とリズムを大切にしながら、楽しく試行錯誤を繰り返すコーディングスタイルです
PoCやプロトタイピングとの相性も抜群です

このLTでは、そんなVibeCodingのリズムの中で見えてきた

• 書きながら気づく「壊しやすさ」と「戻しやすさ」
• 補完と自分の意図がズレる瞬間の設計的示唆
• 30分1セットで設計を“体感”するテンプレート思考

といった実践的な視点を紹介します。
設計を頭の中だけで完結させず、「ノリで書いて確かめる」ことで得られる気づきを、少しでも持ち帰っていただければ嬉しいです。

• 想定聴講者
  • 設計の良し悪しをコードで確かめたい人
  • 生成AIを“動く設計ツール”として使いたい人
  • 設計と集中のバランスに悩んでいるすべての開発者

設計の話をしているはずなのに、なぜか現場でうまく伝わらない、そんな経験はありませんか？
Clean Architecture や DDD を実践し、責務の分離やドメインのモデリングをコード上で実現しても、
それがチームの動き方やプロジェクトの進め方と一致していないと、せっかくの設計がうまく活きないことがあります

本LTでは、設計を「コードの構造」に閉じるのではなく、「チーム構造」「責任分担」「役割」にまで広げて考えるアプローチを紹介します、キーワードは「チームトポロジー」
アプリケーションの内部構造だけでなく、開発者の関係性や組織の構造にもドメインの境界や責務を適用することで、設計と運用のねじれを解消することができます

例えば、認可や監査といった横断的関心事に対して Platform Team がどのように設計支援を行うか
あるいは、ユースケースの責務とチームの責務がズレたときに、実装がどんなふうに崩れていくか
短い時間ではありますが、「設計はコードにとどまらない」ことを提示します

設計・組織・開発体験がバラバラになってしまっているチームにとってのヒントになれば幸いです

• お話すること
  　- 設計とチーム構造を接続するための観点
  　- チームトポロジーを活かしたドメイン適用の工夫

• 想定聴講者
  　- 設計と組織のねじれに悩む方
  　- 設計やチーム構造に興味を持ち始めた初学者の方

このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。

Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X：@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。

また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。

このセッションでは、VercelでPHPとVercel Postgreを用いたアプロケーションを公開する方法を紹介をします。

振る舞い駆動開発（BDD）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。

本セッションでは、PHPでBDDを始めるための基本的な考え方と実践方法を紹介します。Behatなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

PHPでテストを書いて、プロジェクトに無理なく導入できるBDDの第一歩を、これから始めたい方に向けてわかりやすく解説します。

PHPやLaravelで開発したことのある人なら、「CSRF」という単語について聞いたことはありませんか?

例えば、Laravelで新しく作ったフォームを開いたら、「419 | Page Expired」のようなエラーを見たことがある人は多いのではないでしょうか?
(そして、とりあえず @csrf というおまじないを書いたらエラーが直った経験もありませんか?)

CSRF (クロスサイトリクエストフォージェリ) は脆弱性の一種で、
これを対策しないと、ユーザーが意図しない操作（例えば、商品の購入など）を強制的に実行させられてしまう可能性があります。

じゃあどういうコードを書くとCSRF脆弱性を仕込めるのでしょうか?
このトークでは、サンプルのフォームにCSRF脆弱性を仕込み、実際に攻撃した後、脆弱性を仕込まずに済む対策について紹介します。

アウトライン (案)

1. CSRFって何?
2. こんな場面で見たことありませんか?
3. CSRF攻撃って結局どういう攻撃なの?
4. どういうコードで起こり得るの? (映像による実演)
5. じゃあどうすればCSRF脆弱性を作り込まずに済むの?

概要

PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。

本トークではtblsの便利な機能の紹介や、実際に運用している時に得られた知見、AIによるSQL生成などのTipsを紹介します。

ターゲット

• ドキュメントの自動生成やCIによる運用改善に興味のある方
• チーム内でのスキーマ共有・認知コストを下げたいと考えている方

PDOオブジェクトを利用してデータベースアクセスを実装している旧来のPHPプロダクトが抱える課題、具体的には「クエリー記述の煩雑さ」と「SQLインジェクション脆弱性への懸念」に対し、既存の処理との互換性を考慮しつつ、段階的にクエリービルダーを導入することでこれらの問題を解決した方法についてご紹介します。

PHPのロゴがどんなデザインか、皆さんは即座に思い浮かべられますか？
「たしか楕円…」「青と紫の中間色？」「あれ、今のロゴって何代目？」「というか背景色あったっけ？」などなど、さまざまな疑問が頭をよぎるかもしれませんね。

このトークでは、PHP公式ドキュメントを眺めながら最新の正しいロゴとその使い方を隅々まで確認していきます。
さらに、せっかくの機会なのでPHPで書かれている公式ドキュメントのソースコードも、少し覗いてみたいと思います。

PHPを始めたばかりの方にも、長年PHPと向き合ってきたガチ勢の方にも新たな発見がある…かも？しれません！！
このトークが終わる頃には「PHPのロゴを使いたくなってウズウズしちゃう！！！」そう感じていただける時間をお届けできたら幸いです。

Slackでの通知があまりに多すぎて、本当に必要な重要なメッセージが埋もれてしまう問題に直面したことはありませんか？
「@channelだらけでミュートしたくなってしまい、結局重要な通知を見逃してしまった」とか、「通知は届いていたのに、誰も対応できかった」なんて経験はありませんか？

このLTでは、Slackの通知設定を見直し、必要な情報だけが確実に目に入るように改善した方法について紹介します。
どんな方法で通知の過剰を整理し、チーム内の重要なアクションを促進したのか、実際の改善事例とともにお話しします。
これからSlack通知で迷わず、必要な情報を効率的に受け取るためのヒントとなれば幸いです。

あと1年でデータ件数10億件間近…そうなればテーブル変更したくても怖くて触れない…！

そんな状況から始まった打刻テーブル移行のハイライトを5分で語ります。（DBはMySQLです）
・ 更新パラメータ追加に伴うログ検証
・ 参照切り替えのシャドーテスト的アプローチ
・ βリリースを活用した影響調査

動いているAPIを動いたまま内側のテーブルをすげ替えるために行った工夫にをお話しします。
本LTがみなさまのシステム改善やレガシーシステムの移行の一助になれば幸いです。

開発を進めていくと、「このAPIってどんなリクエスト/レスポンスをするんだろう」「こんなAPIがあったんだ」となることよくありますよね？
特に外部公開を目的としないプロダクトではAPIドキュメントを書かないので、さらに謎のAPIが生まれたり、コードを読まないといけなくなります。
このような苦労があるものの、いざ0から作るのは大変です。

今回上記の課題を解決するために、dedoc/scrambleというライブラリの紹介ができればと思います。
Laravelで作られたプロダクトであれば、設定なしでOpenAPI記法でのjsonをエクスポートできちゃいます。

本LTは下記聴講者が対象です。

・APIドキュメントを作りたいけど、0から作るのは面倒
・LaravelでよいAPIドキュメント生成ツールを知りたい方

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

PHPの標準関数やクラスで絶対日時を扱う時に利用するのが、strtotime や DateTime(Immutable)です。
引数には、どんな値が使えましたっけ？

どうしても『おしゃれ』に書きたい！そんな時には、色々な指定方法を知っておくと有利です。
どうやって知ればいいでしょう？PHPのことはPHPに聞くのが1番簡単そうですよね。

PHPについての信頼できるソースとして、php-srcを訪ねてみましょう。
構文解析の定義ファイルを読むことで、利用可能な形式を把握できます。

どこにあるファイルを、どのように読むべきかを知り、実際に使える値(とその調べ方)を知るLTです。

PHPで利用できる例

※ 2025年5月3日に実行すると、全て同じ値になります

<?php
strtotime('today');
strtotime('midnight');
strtotime('noon - 12 hours');
strtotime('3 days ago 00:00:00 + 72 hour');
strtotime('Sat.');
strtotime('00:00:00');
strtotime('00:00');
strtotime('2025-05-03');
strtotime('05/03/25');
strtotime('2025-W18-6');
strtotime('2025.123');

型定義が不完全、変更の副作用も予想しきれない、リファクタしたいけどリスクが読めない――そんなレガシーなPHPモノリスと日々向き合う中で、私たちのチームでは本番環境でユーザーに影響なく検証ができる「シャドーテスト」というお作法を実践しています。

このLTでは、

本番と同じリクエスト・入力を使って新旧ロジックを同時に実行し、
結果の差分を検証する
というアプローチを紹介します。

「テストコードは書きづらい」「型がないから静的検証も弱い」そんな環境でも、実行して確かめることで安全にリファクタや置き換えが進められます。実際にどのように組み込んでいるか、実施してどういうところが良かったか、5分でさくっと共有します。

レガシーPHPと戦う皆さんの一助になれば幸いです！