LAF（LEGAREA AI Framework）は、当社が開発したAI駆動開発フレームワークです。
GPTやClaudeといった大規模言語モデルは、それ自体は「頭脳」にすぎません。LAFは、そこに開発工程ごとの役割を与えます。要件定義、設計、データベース設計、実装、テスト、レビュー。6つの専門AIが、ひとつのチームとして開発を進めます。
そのAIに組み込んでいるのは、技術だけではありません。当社がこれまでの開発で積み上げてきた経験と品質基準を、設計やレビューの判断に反映させています。案件を終えるたびに知見が増え、次の開発はさらに速く、正確になります。フレームワーク自体が進化し続ける構造です。
LAFは、受託開発サービス「JustFit」の土台として使われています。最初の1ヶ月でプロトタイプを無料で開発し、実物を見てから契約を判断していただく。この進め方が成立するのは、LAFがあるからです。
基盤の開発には、3名体制で約半年を要しました。2026年4月より提供を開始しています。
システム開発の発注は、長く高い失敗率にさらされてきました。米Standish Groupの調査では、システム開発プロジェクトの成功率は約31%にとどまります。国内でも、日本情報システム・ユーザー協会の調査によれば、500人月以上のプロジェクトで予算を守れた割合は58.9%、工期を守れた割合は49.3%でした。
多くの開発が、予算超過・納期遅延・品質不足のいずれかに陥っています。背景にあるのは、発注する側が置かれる構造です。完成するまで実物が見えない。業務の内容が開発側に伝わらない。見積もりは高く、追加費用がふくらんでいく。
この構造を変えるには、順番を入れ替えるしかありません。契約してから作るのではなく、先に作ってから契約を判断してもらう。当社の受託開発サービス「JustFit」は、最初の1ヶ月でプロトタイプを無料で開発し、実物を見てからご判断いただく形をとっています。
ただし、この進め方には前提があります。1ヶ月で動くものを出せること。そして、無料だから品質はそれなりだ、とならないこと。この2つが成り立たなければ、約束そのものが守れません。
LAFは、そのために作りました。大規模言語モデルに開発工程ごとの役割を与え、要件定義・設計・データベース設計・実装・テスト・レビューの6つの専門AIがチームとして動きます。人が担うのは、要件の整理と品質の判断です。
さらに、案件を終えるたびに知見がLAFに追加されます。先に聞いておけば手戻りが減った、という気づきが蓄積されるため、次の案件では同じ確認を先回りして行えます。フレームワーク自体が、回るたびに賢くなる構造です。
システム開発の進め方は、長く同じ形をとってきました。まず何を作るかを話し合い、仕様を文書にまとめ、費用と期間を見積もり、契約を結ぶ。そこから開発が始まり、完成したものが納品される。
この順番には、ひとつ避けがたい問題があります。実物が現れるのが、最後だということです。
発注する側は、まだ存在しないシステムについて、何が必要かを先に決めるよう求められます。使ったことのないものを、言葉だけで想像して決める。仕様書に書かれた文章を読み、これで合っていますかと確認される。合っているかどうかは、本当のところ誰にも分かりません。
そして開発が終わり、実物に触れて初めて気づきます。ここはこうしてほしかった、この画面は違う、この操作は現場で回らない。
その時点で、費用はすでに使われています。工程を戻せば追加の費用が発生し、納期も延びます。あるいは、違和感を抱えたまま運用を始めることになります。
数字にも表れています。米Standish Groupの調査では、システム開発プロジェクトの成功率は約31%です。国内でも、日本情報システム・ユーザー協会の調査によれば、500人月以上のプロジェクトで予算を守れた割合は58.9%、工期を守れた割合は49.3%でした。半数近くが、予算か工期のどちらかを守れていません。
これは、発注する側の理解が足りないからではありません。開発する側の能力が低いからでもありません。実物を見ないまま決めさせる進め方が、そもそも無理を抱えているということです。
長らく、この無理は発注する側が引き受けてきました。高くても、遅れても、思ったものと違っても、そういうものだと。
解決の方向は、はっきりしていました。実物を見てから判断できればよいのです。
そこで当社は、順番を入れ替えました。受託開発サービス「JustFit」では、最初の1ヶ月でプロトタイプを開発します。費用はいただきません。実際に動くものに触れていただき、そのうえで契約するかどうかをご判断いただきます。気に入らなければ、費用は0円です。
この形であれば、先ほどの問題は起こりません。言葉で伝えきれなかったことは、実物を触れば分かります。使ってみて初めて分かる「これじゃない」は、無料の期間のうちに何度でも直せます。費用と仕様を先に固める必要がないため、追加費用の交渉も発生しません。
ただし、この進め方には前提があります。
ひとつは、速さです。1ヶ月で動くものを出せなければ、そもそも約束が成り立ちません。
もうひとつは、品質です。無料でお試しと言えば、それなりのものが出てくるのだろうと受け取られます。実際にそうであれば、実物を見ても判断の材料になりません。プロトタイプは、事業の可否を確かめるためのものです。動くだけのものでは意味がないのです。
そして3つ目は、この2つを毎回、どの案件でも成立させることです。一度できたということではなく、常にできる状態でなければ、サービスとして掲げられません。
さらに、契約後の形も同じ前提を必要とします。JustFitでは、契約後は毎月ひとつの機能追加を月額に含めています。納品して終わりではなく、業務の変化に合わせて育て続ける形です。これは、人月商売とは違う構造です。開発にかかる手間が減り続けなければ、成り立ちません。
速く、確かに、毎回。この3つを同時に満たす方法が必要でした。
それがLAFです。
GPTやClaudeといった大規模言語モデルは、それ自体は「頭脳」にすぎません。優秀ではありますが、何をどの順番で考えるべきかまでは決まっていません。そのまま開発に使えば、毎回その場の判断で進むことになります。
LAFは、この頭脳に開発工程ごとの役割を与えています。
要件定義AI、設計AI、データベース設計AI、実装AI、テストAI、レビューAI。6つの専門AIが、それぞれの工程を担当し、ひとつのチームとして開発を進めます。
人が担うのは、要件の整理と、設計、そして品質の判断です。AIが実装と開発工程の効率化を担い、人が最終的な品質を保証する。この役割分担が、LAFの基本の形です。
工程を分けたことで、変わったことがあります。
ひとつは、開発の進め方が毎回同じになったことです。どの案件でも、同じ工程を同じ順番で通ります。担当した人によって進め方が変わるということがなくなり、属人的な開発事故が起こりにくくなりました。
もうひとつは、当社の基準をAIの判断に組み込めるようになったことです。設計やレビューの工程では、当社がこれまでの開発で積み上げてきた経験と品質基準に基づいて、提案とチェックを行います。汎用の大規模言語モデルが一般論として出す答えではなく、当社の判断が反映された答えが返ります。
そして、この基準は固定されたものではありません。
案件をひとつ終えるたびに、気づきが生まれます。ここは先に聞いておけば手戻りが減った、この確認は早い段階で必要だった。こうした気づきを、知見としてLAFに追加していきます。
次の案件では、その確認が最初から行われます。要件の漏れは、誰かが気をつけることではなく、仕組みが先回りして聞くことで防がれます。
案件を重ねるほど、LAFは速く、正確になります。フレームワーク自体が育っていく構造です。
LAFの基盤を作り上げるまでには、3名体制で約半年を要しました。
時間がかかったのは、開発工程をどう分けるかという設計に手間をかけたためです。どの工程をAIに担わせ、どこから先を人が見るのか。役割を分けすぎれば受け渡しの手間が増え、分けなければ工程ごとの品質が保てません。この線引きを決めるのに、相応の検討が必要でした。
2026年4月より、LAFの提供を開始しています。現在は、受託開発サービス「JustFit」の開発基盤としてフル活用しています。
そして今も、これまでの開発で得た知見をLAFに学習させ続けています。当社がこれまで手がけてきた案件から、どういう確認を先にしておけばよかったか、どこで手戻りが起きやすいかを整理し、順次組み込んでいる段階です。
あわせて、開発の各工程をAIで支援するツール群の拡充も進めています。第一弾として、要件定義を支援する「LAF Console（Requirement Agent）」を実装しました。今後も、工程ごとの支援を順次追加していく予定です。
LAFは、完成して終わる種類のものではありません。案件をこなすたびに知見が増え、次の開発がより速く、より正確になる。その積み重ねが、そのままお客様に返っていきます。
新しいことに挑戦する方が、開発費用や「作ってみないと分からない」という壁に悩まされることなく、一歩を踏み出せるように。LAFは、そのための土台です。
Contact
お問い合わせ
