Laravel Boostとは|AIに任せても品質が落ちない開発の仕組み
Laravel Boostとは|AIに任せても品質が落ちない開発の仕組み
「AIがプログラムを書いてくれる時代になった」という話を、あちこちで耳にされていると思います。実際、私たちのような開発会社の現場でも、AIにコードを書かせることはすでに当たり前になりました。
一方で、システムを発注する側の経営者の方からは、こんな不安の声もいただきます。「AIに書かせたシステムって、大丈夫なんですか」「安く早くできるのはいいけれど、後で誰も直せなくなるのでは」——もっともな心配だと思います。私自身、同じ心配をしています。
そんな中で、私たちが開発の中核に据えているフレームワーク「Laravel(ララベル)」に、Laravel Boost(ララベル・ブースト)という公式ツールが登場しました。ひとことで言えば、「AIに、そのアプリのことを正しく理解させてからコードを書かせる」ための仕組みです。今回は、このLaravel Boostを、技術の細かい話ではなく「発注する側にとって何が変わるのか」という視点で整理してみます。
なぜ「AIに書かせたシステム」は保守できなくなるのか
まず、AIにそのままシステムを書かせると何が起きるのかを整理します。問題は「AIの頭が悪い」ことではありません。AIが、あなたの会社のシステムのことを何も知らないまま書いていることにあります。
1. それらしく動くが、作法から外れたコードになる
Laravelには「こう書くのが標準」という作法があります。ところがAIは、世の中に大量にある古いPHPの書き方も学習しています。何も指示しなければ、10年前の書き方と今の書き方が混ざった、つぎはぎのコードが出てきます。動くには動くので、発注側からは違いが見えません。問題が出るのは、数年後に機能追加や担当者交代が発生したときです。
2. AIは、そのアプリの中身を見ずに書いている
顧客テーブルにどんな項目があるのか、どの画面がどの処理につながっているのか、直近でどんなエラーが出ているのか。人間の技術者なら当然確認してから手を動かす情報を、AIは(教えなければ)知りません。結果として、実在しない項目名を使った処理や、既存の仕組みと二重になった処理を平気で書いてしまいます。
3. バージョンのズレに気づかない
Laravelは年1回のペースでメジャーバージョンが上がります(最新のLaravel 13は2026年3月17日リリース)。AIが学習した時点の情報と、実際に使っているバージョンがズレていると、「昔は正しかったが今は使えない書き方」を自信たっぷりに提案してきます。これは実務では地味に厄介で、原因究明に時間を取られます。
つまり、AI活用でつまずく原因の多くは「AIに与える前提情報が足りていない」ことに集約されます。Laravel Boostは、ここを仕組みで埋めにいったツールです。
Laravel Boostとは何か
Laravel Boostは、Laravelの開発元が公式に提供している開発支援パッケージです。2025年8月13日に正式公開され、オープンソース(MITライセンス)として無償で公開されています。その後も更新が続いており、2026年1月26日には設計を刷新したバージョン2.0が、直近では2026年9月7日にv2.7.1が公開されました。GitHubのスター数は約3,600と、公式ツールとして順調に定着しつつある状況です。
導入は、開発者がコマンドを2つ実行するだけです。
composer require laravel/boost --dev
php artisan boost:install
注目していただきたいのは、1行目の末尾にある --dev です。これは「開発中だけ使う道具であり、本番環境には入れない」という指定です。後述しますが、ここは発注側としても押さえておくと安心なポイントです。
Laravel Boostがやってくれることは、大きく4つに分かれます。
| 仕組み | 役割 |
|---|---|
| MCPサーバー | AIが、開発中のアプリ自体を調べられるようにする(DB構造・ログ・設定など) |
| AIガイドライン | Laravelの標準的な書き方を、AIに最初から守らせる |
| エージェントスキル | 必要になった場面でだけ、詳しい実装ノウハウを読み込ませる |
| プロジェクトルール | そのシステム固有の約束事を記録し、次回以降のAIにも引き継ぐ |
AIに「このアプリのこと」を調べさせる
Laravel Boostは、AIがアプリの内部を調べるための道具一式を提供します。公式ドキュメントで公開されている道具は次のとおりです。
| できること | 内容 |
|---|---|
| アプリ情報の取得 | PHP・Laravelのバージョン、使用中のデータベース、導入パッケージ、データモデルの一覧 |
| データベース構造の確認 | テーブル・項目の定義、接続設定の確認 |
| データベースへの照会 | 実際のデータを問い合わせて動作を確かめる |
| エラーとログの確認 | 直近のエラー、アプリのログ、ブラウザ側のエラーを読む |
| 公式ドキュメント検索 | 使用中のバージョンに対応した正しい書き方を調べる |
| ルールの記録 | 決まったことを、プロジェクトのルールとして書き残す |
要するに、AIが「推測で書く」のをやめて、「確認してから書く」ようになります。人間の技術者が現場で当たり前にやっていることを、AIにもさせるということです。
Laravelの作法を教える(ガイドラインとスキル)
Laravel Boostは、Laravel本体はもちろん、よく一緒に使われる周辺技術(画面まわりのLivewireやInertia、Tailwind CSS、テスト用のPestなど)について、「こう書くのが正しい」という指示書をAIに渡します。しかも各パッケージのバージョンごとに用意されているため、「うちのシステムのバージョンではこう書く」という精度で効いてきます。
バージョン2.0からは、この指示書が常時読ませるもの(ガイドライン)と、必要な場面でだけ読ませるもの(スキル)に分けられました。AIが一度に扱える情報量には上限があり、全部を最初から読ませると肝心の指示が薄まってしまうためです。地味ですが、実務での精度に効く改善でした。
そのシステム固有の約束事を蓄積する
個人的に、発注側にとって一番価値があると思っているのがこの機能です。
どんなシステムにも、ドキュメントに書ききれない固有の約束事があります。「金額は必ず整数(円)で持つ」「この処理は必ず既存の共通クラスを経由する」といった類のものです。従来こうした知識は担当技術者の頭の中にあり、担当が変わると失われました。
Laravel BoostではAIに「これを覚えておいて」と伝えると、プロジェクト内の .ai/rules というフォルダにルールとして書き出され、ソースコードと一緒にバージョン管理されます。そして次回以降、そのファイルを触る作業のときだけ自動的に読み込まれます。さらに、既存のシステムから「実際にどういう書き方で統一されているか」をAIに調べさせて、ルールとして起こす機能もあります。
つまり、これまで属人化していた暗黙のルールが、システムに付属する資産として残るということです。これは、発注側が引き継ぎリスクを下げるうえで無視できない変化だと考えています。
17,000件超の公式情報を、正しいバージョンで引く
Laravel Boostには、Laravelとその周辺技術に関する17,000件を超える情報を検索できる仕組みが付いています。AIは、うろ覚えの記憶で答えるのではなく、使用中のバージョンに合った公式情報を検索してから書きます。前述した「バージョンのズレ」の問題への直接的な回答です。
導入するかどうか、3つの選択肢を公平に比べる
「公式ツールだから入れるべき」と言い切るつもりはありません。開発の進め方には3つの選択肢があり、それぞれに向き不向きがあります。
| 進め方 | 向いている場面 | 注意点 |
|---|---|---|
| AIを使わず、人が全部書く | 規模が小さい/要件が特殊で前例がない | コストと時間はかかる。品質が担当者の腕次第という点は昔から変わらない |
| 汎用のAIをそのまま使う | 試作品、使い捨てのツール、単発の調査 | 作法のばらつきと事実誤認が起きやすい。長く使うシステムには不向き |
| Laravel Boostのような枠組みを整えて使う | 長く使う業務システム、機能追加が続くシステム | 導入・整備の手間はかかる。AIの成果物を検証できる技術者がいて初めて機能する |
誤解のないように申し上げると、Laravel Boostは「AIが勝手に良いシステムを作ってくれる魔法」ではありません。AIの当て推量を減らし、間違いを起こしにくくする道具です。設計の判断と最終的な品質責任は、これまでどおり人間の技術者側にあります。
発注する側が確認しておきたい4つのこと
ここからは、システム開発を外部に依頼する立場で、押さえておくと良いと思う点をまとめます。
1.「AIを使っているか」ではなく「どう検証しているか」を聞く
今後、AIを一切使わない開発会社はほぼなくなります。ですから「AIを使っていますか」と聞いてもあまり意味がありません。聞くべきは「AIが書いたコードを、どうやって確認していますか」です。テストをどう書いているか、レビューを誰がしているか。ここに答えられない相手には、不安が残ります。
私は1988年から2017年まで、日立グループのIT企業でシステム開発をしていました。当時はAIなどありませんでしたが、大規模開発の品質を支えていたのは、突き詰めれば「守るべき書き方を文書で決めておくこと」と「必ず他人が目を通すこと」の2つでした。コーディング規約とレビューです。Laravel Boostがやっているのは、その規約側をAIにも読める形で整備することであり、レビューの必要性を消すものではありません。技術は変わりましたが、品質の作り方の原則は驚くほど変わっていない、というのが率直な感想です。
2. 成果物が自社の資産として残るかを確認する
先ほどのプロジェクトルールのように、開発の過程で決まった約束事がソースコードと一緒に残る形になっているか。そしてソース一式を納品時に受け取れるか。将来、別の会社に引き継ぐ可能性を考えると、ここは契約の段階で確認しておく価値があります。
3. セキュリティ上の線引きを確認する
Laravel BoostはAIがデータベースを参照できる道具を含むため、扱いには線引きが必要です。公式でも開発用(--dev)パッケージと位置づけられており、本番サーバーには入れないのが大前提です。また、2026年8月に公開されたv2.6.0では、AIがデータベースに問い合わせる際、データベース側で強制的に読み取り専用となるよう変更されました。安全側に倒す改善が継続して入っています。
発注側としては、「本番の顧客データが入った環境でAIツールを動かしていないか」を確認しておけば十分だと思います。当社では、AIに触れさせるのは開発環境とテスト用データに限っています。
4. 費用と納期に、そのまま跳ね返るとは限らない
「AIを使うなら安くなるはず」と言われることがありますが、正直に申し上げると、単純に半額になるようなものではありません。速くなるのは主に実装の工程で、要件を詰める打ち合わせ、設計の判断、テスト、レビューの手間は減らないからです。むしろ、出てくるコードの量が増える分、レビューの比重は上がります。
効果が出やすいのは、同じような画面や処理が数多くある業務システムや、長く使いながら機能追加を重ねていくシステムです。相場観としては、AI活用は「見積を大幅に下げる要素」ではなく「同じ予算で品質と対応スピードを上げる要素」と捉えていただくのが実態に近いと思います。
当社の取り組みと関連する実績
当社では、業務システムの開発をAlmaLinux+Laravel+MariaDBという標準構成に統一しています。理由はWebシステム開発の標準構成とは|当社がAlmaLinux+Laravelで作る理由やLaravelでWebシステムを開発するメリット|保守できるシステムを作るで詳しく書いていますが、構成を揃えておくことは、AI活用の面でも効いてきます。Laravel Boostのような公式の仕組みがそのまま使え、案件をまたいでノウハウが蓄積できるからです。
決まった約束事を残しながら開発を進めるという考え方については、ゼロから作らないシステム開発|品質を作り込んだ共通ベースという考え方にもまとめています。
実際の開発事例としては、製造・エネルギー分野の水素発生装置の遠隔制御・監視システムや、月面探査車の疑似運転体験IoTシステムなどがあります。いずれも要件定義から運用まで一貫してお手伝いした案件です。
まとめ
Laravel Boostは、Laravelの開発元が公式に用意した、AIにきちんとした仕事をさせるための仕組みです。ポイントを整理します。
- AI活用の失敗の多くは「AIが前提情報を知らないまま書く」ことに起因する
- Laravel Boostは、AIにアプリの構造・作法・公式情報を確認させてから書かせる仕組み
- プロジェクト固有の約束事がソースと一緒に残るため、引き継ぎのリスクが下がる
- ただし魔法ではなく、レビューと設計の判断は人間の仕事のまま
- 発注時は「AIを使うか」より「どう検証しているか」「成果物が資産として残るか」を確認する
AIによって開発のやり方は確実に変わりましたが、「作った後に長く使えるか」を決めるのは、結局のところ作り方の規律です。私は日立グループでの約30年で、そこで手を抜いたシステムがどうなるかを見てきました。だからこそ、AIを使うほど土台を固めておくべきだと考えています。
これからシステムを作る方も、すでにあるシステムの引き継ぎに不安がある方も、まずは現状をお聞かせいただければと思います。何を作るか決まっていない段階でのご相談も歓迎です。
これまでの開発事例は 制作実績 でご紹介しています。
