プロポーザル

近年、AI開発現場に深く浸透し、私たちの生産性を飛躍的に向上させています。
非エンジニアでもAIの助けを借りて開発に挑戦できる、まさに革新的な時代が到来しました。

​しかし、その便利さの裏には"予測不能な『AIの嘘』“という大きなリスクが潜んでいます。

​本セッションでは、私が実際に直面したAIの『嘘』、具体的には「AIが期待とは異なる出力を生成し、結果的にデバッグに膨大な時間を要した」経験について、実例を交えながらご紹介します。

​AIの『嘘』に引っかからないためのポイントを、5分という短い時間でポイントを凝縮してお伝えします。
この発表が、AIをより賢く、安全に使いこなすためのヒントとなれば幸いです。

「協働」とは、複数の主体が目標を共有し、共に力を合わせて活動することを指します。
単なる「分業」や「協力」ではなく、立場や役割が異なる人たちが一緒に価値をつくりあげていく営みです。

エンジニアリングはコードを書いて終わりではありません。
サービスを設計する人、営業やサポートを担う人、エンドユーザの声を聞く人、──様々な立場の人たちが関わって初めて、プロダクトは価値を発揮できます。
しかし現実には、部署や部門の壁に阻まれ、うまく連携できないことも少なくありません。

実際の現場では、こんなことが起こりがちです。

• お互いの事情を押し付け合ってしまう
• 言葉がすれ違い、不満や陰口に発展してしまう
• 結果として「協働」ではなく「対立」になってしまう

でも、本来エンジニアリングは「他部署とともに価値をつくる営み」であり、協働がうまくいくとチームもプロダクトもぐんと強くなります。
私はこの「協働」のあり方こそ、これからのエンジニアにとって大切なテーマだと感じています。

今回のトークでは、私自身が他部署と一緒にプロジェクトを進めるなかで学んだことをベースに、

• 部門の壁を越えていくためのマインドセット
• 協働をスムーズにするための具体的な働きかけ
• 「これはやってはいけない」失敗例
  をご紹介します。

また、PHPカンファレンス香川2025のテーマ「手軽さ」にちなみ、“美味しいうどんを手軽に作るプロセス”をメタファーにしながら語ります。
協働は大げさに構えるものではなく、ちょっとした工夫や自然体のやり取りから始められる。
まるで「手軽に作れるのに驚くほど美味しい一杯のうどん」のように。

このトークでは、少しでも他部署とのコミュニケーションに悩むエンジニアが減ることを願い、他部署と働いているエンジニアがもっと「手軽に」協働できる方法をお話しします。

このトークは

• AST(抽象構文木)はコンパイラにとって便利なものだが、それ以外にも便利に使える
• ASTって何だろう？を知って、その便利な活用例も知ろう

モチベーション

phperの皆さんは、アルファベットや数字に記号などなどをファイル上に並べていきますよね。
私達が直接的に生産するのは、ただの「文字の羅列」に過ぎません。
これを文法の枠組みに則って解釈することで、文や句と行った構造が手に入るのです。
例えば class Hoge{} と書かれていれば、「1つのクラスが定義されていて、そのクラスはHogeという名を持つ」といった具合です。

ASTの主な利用者はコンパイラでしょう。
人間が読み書きしやすい文字の羅列を、機械のための表現に変換する過程で現れます。

そして、「字句レベルではない、構造化されたレベルでコードを扱える」ことが、
コンパイラ以外にも色々な可能性をもたらします。
より抽象的な理解や操作が容易になり、色々な作業やコード品質の担保をお手軽なものにしてくれるのです。

そんなASTについて、「確かに面白いね！」と感じる人を増やしたいトークです

話すこと

• 基本的なASTの説明
• ASTを活用した便利ツールの解説(出来ること、使い方、仕組み)
  • rector/rector
  • ajthinking/archetype

対象(難易度)

• 「ASTって何だろう？」と感じる人や「聞いたことはあるけど、具体的には知らないな」という人
• 「ASTを利用したツールを使ったことはあるが、その内部にある仕組みまでは知らないな」という人

Symfonyは“フレームワークを作るためのフレームワーク”と呼ばれ、Laravelのコアにも採用されています。
そのため、初心者向けの導入説明や上級者向けの抽象概念を獲得するための解説などの知見を聞く機会が多くあります。

また、PHP 5.4で導入されたtrait(特性)も便利な仕組みである一方で、「知ってはいるが、どう活用していいか分からない」という人が多いのではないでしょうか。

本トークでは、Symfonyの拡張しやすい仕組みとtraitの相性に注目し、ストレージアクセスモデル、フォームバリデーション、ページ描画といった領域で、少ないコードで手軽に拡張・調整する実践例を紹介します。
また、trait導入によるインターフェース統一による不具合防止、Doctrineエンティティ、フォームバリデーションや描画の定義の一貫性や安全かつ手軽な変更を実現する方法についても解説します。
そして、これらの事例を足がかりに、traitパターンをアプリ全体に横展開することでチーム開発における安心感と長期運用に耐える拡張性を手軽に実現できることをお伝えします。

このトークで得られる知見

• Symfonyの設計思想に沿ったtraitの活用パターン
• モデルやフォームを少ないコードで手軽かつ安全に変化させる技法
• traitを「どんな場面で選ぶべきか」という実務的な判断基準

このトークの対象者

• Symfonyを日常的に利用している方、または興味を持っている方
• PHPでtraitを知ってはいるが、実務でどう活用すればよいか悩んでいる方
• Symfonyやtraitの活用を通じて、アプリケーション開発を効率化したい方

このトークで扱わない内容

• Symfonyの基本的な使い方

日々の仕事や人間関係の中で、ふと傷ついた「言葉」って、案外ずっと心に残りませんか？
「言われてムカついた」「何気ない一言で凹んだ」
そういったモヤモヤを、トイレに流してスッキリする
Webサービスを作りました。

個人で気楽に作成し、Qiitaに記事を投稿したところ、想像以上に多くの人に使用してもらい、反響をうむ結果となりました。

このLTでは、

　・「心のトイレ」とはなんなのか
　・「心のトイレ」というアイデアをどのようにだしたか（筋トレが関係ある！？）
　・使用した技術と工夫
　・Qiitaに書いたことで得られた反響
　・個人開発の魅力や楽しさ

といったことをお話しします。

仕事と違い、個人開発は本当に気楽で最高です。
「ぱっと作って、すっとリリース」。
思いついたアイデアを、自分の好きなように形にできる楽しさをお伝えします。

そして、このLTをきっかけに、個人開発に挑戦する仲間が一人でも増えたら嬉しいです。

皆さんは、記事を書いたりLTをしたりといった「アウトプット」をしていますか？
僕はちょうど1年前まで、ほとんど何もしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。テーマはPHPやReactなど。学びの延長線上でアウトプットしました。

このLTでは、「アウトプット経験ゼロ」だった僕が、どのように気楽に始めて続けられたのか、そしてそこから得られた気づきをお話しします。

内容
• 投稿して感じられた小さなメリット
• ネタ切れやモチベ低下の乗り越えかた
• アウトプットを通じて自然と得られた成長
• 思いがけずバズった記事
• 工夫したこと

記事を投稿するのは最初は勇気がいると思います。
ただ実は、アウトプットは日々の学びを手軽に書き残すだけでも始められます。

このLTで「ちょっと書いてみようかな」と思ってもらえるきっかになれば嬉しいです！

2025年ももうすぐ終わろうとしていますが
お兄さんお姉さんだけでなく、おじいちゃんもおばちゃんお隣さんも、皆でMCPサーバーに夢中になった1年でしたね

Symfonyユーザーのために、symfony/mcp-bundle というbundleがあります。
これを使うと、簡単に

• Server-Sent Eventsを喋るための何か
• AIエージェントにToolを提供するための何か

を用意できます。

これって、普段のWebアプリケーション開発で、
「FWがやってくれる部分に任せて、やり取りする中身だけを気にしておけば、プロトコルやemitのタイミングなんて意識しなくてOKだよね」
って感覚に似ています。
触ってみると、「いつもPSR-7でやり取りしていた内容が、別のRequest/Responseに詰め込まれるだけだな！」という気持ちになれますよ

このLTでは、サンプルのWebアプリケーションを用意した上で、
「mcp-bundleを使ったら、Symfonyアプリケーションが簡単にMCPサーバーになった！」
という様子をお見せします。