2026年5月26日（火）・27日（水）の2日間、Laravel Live Japan 2026 に参加してきました。

キーワードは3つ。「Strict（厳格さ）」「Laravel Way」「職人技」 です。

---

DAY 1（5月26日）

① 厳格さは、AIへの「思いやり」だった｜Strict AI Engineering（Nuno Maduro 氏）

いきなり考え方をひっくり返されたセッションでした。

静的解析やLinterで「厳格なルール」を敷くこと。これって、ともすると「人間の自由を縛る、めんどくさいもの」に見えがちですよね。でも Nuno 氏のメッセージはこうでした。

AIと開発する時代だからこそ、厳格なルールには意味がある。 なぜなら、そのルールは自分たちのコードだけでなく、**AIが生成するコードの品質まで底上げしてくれる**から。

ライブデモで紹介された「武器」たちが具体的で、すぐ試したくなるものばかりでした。

• Model::shouldBeStrict() でN+1問題などを早期に検知する
• DB::prohibitDestructiveCommands() で破壊的なコマンドを未然に防ぐ
• declare(strict_types=1) は必ず設定する
• 「型はAIの最良の友」。PHPStanで静的解析を効かせる（型がしっかりしていればPHPDocも要らない）
• Modelには @property-read、Controllerは final readonly / Form Request を徹底
• テストパイプラインこそ、コードとAIの「ガードレール」になる
• composer scripts にlintコマンドを集約（rector / pint --parallel / npm run lint）
• pest --parallel --coverage --exactly=100.0。AI生成コードにはカバレッジ100%を要求する

締めの言葉、「STRICT TYPING, STRICT DEFAULTS, STRICT PATTERNS, STRONG TESTING PIPELINE」がとにかく象徴的でした。これらを丸ごとまとめた [Essentials](https://laravel-news.com/laravel-essentials) パッケージも紹介されています。

> 一番の学びは、「AIに気持ちよくコードを書いてもらうために、まず人間が制約を整える」という発想の転換。`shouldBeStrict()` あたりは、帰ってすぐ試したくなりました。

② モックとスタブ、ちゃんと使い分けられていますか？（うたまる あすみ 氏）

テストダブルの話です。なんとなく雰囲気で使い分けていたところを、きれいに言語化してもらえました。

• Mock = imitation and assertion（依存先を「正しく呼べているか」を検証する）
• Stub = imitation only（固定の値を返してくれる、ただの部品）

線引きの基準として刺さったのが、**"What you assert is what you care about"** という一言。検証したいものだけをassertする、というシンプルな原則です。モックを使いすぎると、ちょっとした変更ですぐ壊れる「Fragile Test（壊れやすいテスト）」になってしまう、という指摘にもうなずくばかりでした。

「テストとコード、どっちを先に書くか」問題については「半々」とのこと。ただ、**テストケース名だけ先に書く**と、仕様の見通しがぐっと良くなるそうです。

> 「assertしたいかどうか」でモックとスタブを分ける。この整理が本当に明快でした。「仕様が浮かび上がるテスト」、意識していきます。

③ 大規模リアルタイム分析の裏側｜Inside Nightwatch（Jess Archer 氏）

Laravelの監視サービス「Nightwatch」が、どうやって大量のデータをさばいているのか。その舞台裏を覗けるセッションでした。

データはこんな流れで運ばれていきます。

> アプリ（Laravel → Nightwatch Agent）→ Ingest Endpoint → Kafka → ClickPipes → ClickHouse

主役は ClickHouse。列指向の分析用データベース（OSS）で、INSERTは追記方式。最新データを正しく取るには FINAL が必要、というクセも紹介されていました。Laravel向けドライバ [laravel-clickhouse](https://laravel-news.com/laravel-clickhouse-a-full-featured-clickhouse-driver-for-laravel) もあるそうです。

> OLTP（業務処理）とOLAP（分析）では、そもそもDBの構造からして別物。構造をちゃんと理解して、適切な絞り込みをかければ、検索はしっかり速くなる。当たり前のようで、改めて腹落ちした学びでした。

④ Laravelアプリは、なぜ壊れるのか？（武田 憲太郎 氏）

Railsに "Rails Way" があるように、実はLaravelにも明確な設計思想 "Laravel Way" があります。

ところが、それを体系的にまとめた本がない。だから誤解が広まってしまう。そんな問題提起から始まる、熱のこもったセッションでした。

• 生成AIは「生成」は得意。でも「捨てる・シンプルにする」のは苦手
• php artisan make:* など、**Laravelが用意してくれた仕組みに素直に乗る**ことが大事
• Laravel Wayに従えば、人にもAIにも扱いやすい構造になる。**"DO THINGS THE LARAVEL WAY."**

関連資料として、武田氏の「[私の愛したLaravel レールを超えたその先へ](https://speakerdeck.com/kentaroutakeda/si-noai-sitalaravel-reruwochao-etasonoxian-he)」も挙げられていました。

> ①の Nuno 氏の「Strict」とはまた違う角度からの「AI時代の心得」。Laravelの設計思想に対する自分の解像度を、もっと上げたいと感じました。

⑤ 仕事を「技芸」として捉え直す｜AI時代の仕事技芸論（倉貫 義人 氏）

正直に言うと、2日間でいちばん心を動かされたのがこのセッションでした。

仕事を「労働」ではなく「技芸（Arts & Crafts）」として捉え直そう、という内容です。

• 内発的動機づけ：難易度と自分のスキルがちょうど釣り合うとき、人は「面白い」と感じる
• ソニックガーデン社が「あえて無くしたもの」：売上目標、管理職、評価制度、指示命令、オフィス、勤務時間……
• 大事にしているのはセルフマネジメント（外から圧をかけると、かえって品質も速度も落ちる）
• 徒弟制度のような育成のなかで、「良し悪しを見極める力」が育つ
• AIは、技術と芸術を結びつける道具。「AI＋自分」なら、分業よりも一気通貫のほうが効率的
  

そして、いちばん刺さった言葉がこれです。

審美眼が真実。審美眼を持つプログラマが、これからの時代に求められる。

> プロダクトを「自分の作品」として捉える。そんな内発的な動機を、社内のあちこちに仕掛けていきたいと思いました。同時に、「他人の内発的動機にどう向き合うか」を考えるきっかけにもなりました。

⑥ Keynote: Laravel Updates（Taylor Otwell 氏）

そして真打ち、Laravelの生みの親によるキーノートです。エコシステム最新アップデートが一気に語られました。

• Laravel Boost：アプリを検査して、AI向けのinstructionファイルを生成。Laravel 11/12なら、Update SkillでアップデートをAIが自動実行
• AI SDK：AI機能を組み込むためのSDK。トークン消費量を dump で確認できたり、Sub Agentsに対応していたり
• Laravel Cloud / Private Cloud：公式のPaaS（いわば "Laravel版 Vercel"）。gitブランチと連動して動く（例：mainブランチ＝本番）
  

> Laravelが「AIと開発すること」を大前提に、エコシステム全体を作り変えにいっている。それがひしひしと伝わるキーノートでした。まずは Laravel Boost、触ってみます。

---

DAY 2（5月27日）

⑦ PHPで、ネイティブアプリを｜Laravel and the Future of Native Apps（Simon Hamp 氏、Shane Rosenthal 氏）

「PHP / Laravelで、モバイルネイティブアプリを作る」。聞いた瞬間「えっ、どうやって？」となる、Native PHP の紹介です。

PHPもLaravelも、もともとはWebにフォーカスした技術。モバイルから見れば、Webは「サーバー」という遠い別世界です。その距離を、[Native PHP](https://nativephp.com/) はこんな仕組みで一気に縮めます。

• PHP on the phone：ARM64向けにクロスコンパイルし、libphp.soをアプリに埋め込む
• The persistent Runtime：Laravelを一度だけ起動して、全リクエストをそこに流す
• The Bridge：PHPがOSと会話する仕組み（JSON in, JSON out）
• Native UI：Bladeがツリーを記述し、フラットバッファがネイティブ描画する

> Bladeでネイティブ UIが描けるなら、Laravelでモバイルアプリを作るハードルは一気に下がります。まずは簡単なアプリから、自分で作ってみたくなりました。

⑧ "モダンなモノリス"、再考｜The Modern Monolith, Revisited（Joe Tannenbaum 氏）

Laravelとモダンフロント（React / Vue）を、Inertia.jsでシームレスにつなぐ。それをライブコーディングで見せてくれるセッションでした。

Laravel＋Vue/Reactを素朴に組み合わせると、いろいろツラいことが起きます。CORS、認証の複雑さ、2つのコードベース、そしてAPI drift（フロントとバックの仕様のズレ）。

これを Inertia がまとめて解決してくれます。

• CORSなし
• Laravelの認証はそのまま使える
• コードベースは1つ（One Codebase）
• API driftが起きない（No API Drift）

「サーバこそが情報の源。それ以外はクライアント側に閉じ込める」という考え方が軸です。Inertia v3 ＋ Laravel Wayfinder を使えば、PHPとTypeScriptが型安全につながった「フロントからバックエンドまでのモノリス」が実現できる、とのこと。

> 「モダンなモノリス」の魅力を、堂々と提示してくれる内容でした。シンプルな開発体験が好きな自分としては、新規開発でぜひ試したい構成です。

⑨ 技術的負債と、正しく付き合う（河瀨 翔吾 氏）

「技術的負債」という言葉、なんとなく使っていませんか。それを改めて言語化し、AI時代の付き合い方を考えるセッションでした。

技術的負債とは、ソフトウェアの「変更しやすさ」を下げてしまう、あらゆる要素のこと。散らかったコード、頼りないドキュメント、放置されたライブラリ、足りない自動テスト……どれも心当たりがあります。

そして、ここが大事なところ。

> AIはスピードを優先するぶん、品質低下を招くこともある。 作業量が読めず、かえって時間がかかることさえある。

じゃあどうコントロールするか。自動テスト→リファクタリングの流れ、依存ライブラリを選んだ理由を明確にしておくこと、コードの共同所有、背景をコメントに残すこと、腐敗防止層（ACL）……といった手段が紹介されました。**AIは負債を増やす要因にも、負債解消の強力なパートナーにもなる。要は「制御できるか」次第**、という諸刃の剣の話です。

> いちばん刺さったのは、「各イテレーションに、改善の余白をあらかじめ含めて、それを文化にする」という考え方。開発のなかに「品質向上やリファクタリングも当然含める」という発想、自社にも取り入れたいです。

⑩ Value Objectで、コードを"防弾"にする（Harris Raftopoulos 氏）

メールアドレスや金額を「ただの文字列」「ただの数値」として扱う。これ、扱うたびに障害の火種を増やしているかもしれません。

プリミティブ型に頼らず、Value Object で解決しよう、という提案です。

ポイントは、「型エラーがゼロでも、それだけでは足りない」という前提。Value Objectには、こんなルールがあります。

• イミュータブル：`final readonly` で、後から変えられないようにする
• 自己検証：値そのものがバリデーションを持っている
• 値による等価性：参照が違っても、中身が同じなら「等しい」とみなす
• ビジネス概念を含む：ドメイン固有のルールを、値の中に閉じ込める
  

「いつ作るべきか」の目安も明快でした。同じバリデーションが2箇所以上に出てきたとき。片方に紐づく値があるとき（緯度と経度のような）。書式や表記のルールがあるとき。逆に、値に対する短い固定処理だけなら enum で十分、という線引きも。

> プリミティブ依存は、プログラム上は問題なくても、知らないうちに問題を生む。DDDの導入はLaravelのディレクトリ構成に手を入れるので慎重に判断したいですが、「意味のある値」として実装する大切さは、しっかり復習しておきたいです。

⑪ 楽しかっただけのコミュニティが、今の私を作っていた（向平 琴未〔ことみん〕氏）

技術セッションとはまた違う、でも深く考えさせられる一本でした。

> すぐ近くにあるコミュニティも、当たり前に存在し続けるとは限らない。

カンファレンスに参加する意味そのものを、問い直す内容です。

• コミュニティは「自分の見ている世界が、広がる場所」
• 日本には特色あるPHPコミュニティがたくさんあって、大事にしているものもそれぞれ違う
• 自分から周りを巻き込んでいくことが、コミュニティが続いていくことにつながる
  

> たくさんの人がいてくれるから、コミュニティは今日も成り立っている。その感謝を持つことの大切さと、「学ばせてもらう側として、自分に何ができるか」を考えるきっかけになりました。

⑫ パネルディスカッション：Laravel × VoidZero｜Web開発の未来を語る

2日間の締めくくり。いちばん印象に残ったのは、この一節です。

AIに頼りすぎると、AI Slop（AIによる質の低い生成物）を簡単に生み出してしまう。

本当に必要なのは「人が考え」「人が体験し」「人が調べて」「人が直す」こと。

そのなかでAIを使うのは、良いアイディアだ。

> 2日間ずっと語られてきた「AIと人間の役割分担」を、これ以上ないくらい端的に言い表してくれた言葉でした。