2026/5/26・27に東京・立川ステージガーデンで開催された、Laravel Live Japanの参加レポートです。

Laravel Live Japanとは

Laravel Live Japanは、日本初のLaravel公式コミュニティカンファレンスです。 日本のPHPコミュニティは盛んだが国外と切り離されている、そのエネルギーをグローバルなコミュニティと繋げたい、という主催者のRyuta Hamasakiさんの思いから開催されました。 最前線で活躍する国内外の開発者が登壇し、また会場にも500名を超える世界中の開発者が参加しました。

参加のきっかけ

エンジニア会でイベントの紹介があったときにセッション一覧を見たところ、うたまる あすみさんの「PHPUnit でモックとスタブを使いこなす」というセッションが目に止まりました。ちょうど業務でPHPUnitに苦戦していた時期だったため、業務に活かせると感じ、参加に至りました！

会場・セッションの様子

想像以上に国外の方が多く英語での登壇が多かったですが、画面に精度の高い同時翻訳が表示されていたおかげで内容を追うことができ、海外エンジニアのプレゼンを生で聞くという良い機会になりました。また、日本人スピーカーも英語で話す方も多くいました。

登壇内容もLaravelだけ、PHPにとどまらず、どんな言語のプロダクトでも活用できそうな内容ばかりでした。

トークの感想

PHPUnitでモックとスタブを使いこなす

うたまる あすみさんによる、PHPUnitにおけるモックとスタブ、そしてテストのベストプラクティスをテーマにしたセッションです。先述の通り、最も注目していたトークでした。

すべて本物を使うと不安定になる、だからこそテストダブルが必要

💡テストダブルとは
テスト対象が依存しているコンポーネントを置き換える代用品の総称（モック、スタブなど）

以前のプロジェクトでも、DIを使わない古いコードが残っていてテストダブルが使えず、overloadで無理やり偽物に置き換える必要があり、そのせいでテストの実行順によっては結果が変わるなど不安定になっていたため、これには思い当たる節がありました。

モックとスタブを目的によって適切に使い分けること

モックはアサーション(メソッドが呼ばれたか検証)とイミテーション(決まった値を返す)
スタブはイミテーション(決まった値を返す)の機能を持つ。

モックだけでイミテーションを表現することはできるが、適切に使い分けるべき・仕様を表現しているテストコードを書くべきというのが全体的な主張でした。

そもそもモック・スタブの理解が曖昧だったため、整理する良い機会となりました。

• 「メソッドが呼ばれたこと」が仕様として重要 ＋ 戻り値もセットしたい→モック
• 戻り値だけセットできればよい→スタブ

// ❌モックなのに日時を返しているだけ or メソッドの検証がされていない
$this->eventMock->method('getStartDate')->willReturn('2026-01-01 10:00:00');

// ✅スタブとして使う
$this->eventStub->method('getStartDate')->willReturn('2026-01-01 10:00:00');

// ✅メソッドが呼ばれることが仕様の1つなので、getStartDate()が呼ばれたことを検証する
$this->eventMock->expects($this->once())->method('getStartDate')->willReturn('2026-01-01 10:00:00');

テストで邪魔になる・影響を与えてしまうものだけをテストダブルにすること

基本的には本物のオブジェクトを使用し、テストに影響を与えるもの（特定の戻り値が必要なもの・副作用があるもの）だけをテストダブルに置き換えることが重要とのこと。

依存関係が複雑なクラスだと、テストすべきところがどこかわからなくなりがちなので、テスト対象は何かを見極めることは大切だと改めて感じました。

昔、モックした内容をテストしているケースもあったため、テスト対象そのものをテストダブルにしてしまっていないかも意識していきたいと思います。

実装前にテスト設計を行うこと

アフタートークの中で、「プロダクトコードを先に書くか、テストコードを先に書くか」という話題で、登壇者のあすみさんが、「実装前にどんなテストケースが必要かを洗い出している」ということを話していました。

そもそもTDD（テスト駆動開発）という手法を知らなかったため、これは目から鱗な内容でした。 プロダクトコードをしっかり実装してからテストを書くということが当たり前と考えていましたが、この仕様では正常系・異常系は何か、どういうテストが欲しいかを実装前に考えることで、網羅性のあるテストコードが書けると感じました。

また、AIにテストコードを生成させる場合でも、既存のテストコードをもとに学習して書いていくため、常にコードを丁寧に書いておくことが全体の品質につながると実感しました。

全体を通して

国内外のエンジニアの登壇を聞き、全体を通して感じたことは、ほとんどのエンジニアが、AIのためのコードの一貫性を重視しているということです。 型を厳格にしたりリンターで整備したりすることで基本形を守っていれば、AIも迷わず高品質なアウトプットを引き出せる、という考え方が、どのエンジニアにもある印象でした。

AIが既存の実装をベースにコードを書いているというのは強く感じていることだったので、AIを活用した開発を効率化していくためにも、今書いているコードは適切か、他と揃っているか意識しながら開発することの大切さを改めて認識しました。

一方で、AIが全て行い自分の理解が追いつかない理解負債も課題の一つなので、AIが生成したコードも読み込み、何をしているか把握することも引き続き心がけていきます。

イベント参加後の取り組み

現在1から開発しているサービスにおいて、AIにコード生成を迷わせないためのコードの一貫性と、適切なテストダブルを用いたテストの整備に取り組んでいます。 基盤構築の段階からこれらをしっかり固めることが今後のAI駆動開発・運用に大きく関わると考え、重要視して進めています。

Instructionsの整備

• コード・テストコード・ロガーの書き方などを、具体的な使用例を添えて記載
• 依存性注入、テストダブルについての内容を充実
• 決まり事が決まったらすぐにinstructionsに記載

リンター・フォーマッターの整備

• 仕様書時点から選定、構築開始段階でルール整備し、コードの書き方を統一

レビューにおける実装統一性の重視

• それぞれの実装にバラつきがないかを注視してレビュー