「このシステムはAIだけで作りました」「マルチエージェントでコードも機能もレビューも全部自動化しています」。最近、こうした発信を目にする機会が増えました。AIエージェントを駆使して、驚くべきスピードでシステムを量産している人たちがいます。
確かに、多少設計が甘くてもAIを使いこなす人のほうが成果を出せるケースは増えています。これは事実であり、AIエージェントの威力を軽視するつもりはありません。
しかし、日々の開発でAIエージェントを使い込んでいる弊社の立場から、一つだけ率直に申し上げたいことがあります。それは「速く”壊れるもの”を作っているだけではないか」という問いです。
「速く作れた」と「良いものが作れた」は別の話
システムには、作った瞬間の完成度だけでなく、その後の変更への強さ、追加機能を加えたときの安定性、長期的に運用したときの保守コストといった、目に見えにくい品質があります。これらの品質は、AIに「速く作って」と指示するだけでは決して担保できません。
AIエージェントを使えば、これまで数週間かかっていた作業が数日で終わることがあります。しかしその成果物が、半年後・1年後に変更を加えようとした瞬間に破綻するような代物であれば、それは本当に「良いシステム」を作ったと言えるでしょうか。
私たちは、これを「速く壊れるものを作っている」状態だと考えています。そして、この状態に陥っている現場は、今この瞬間にも世の中にたくさん存在していると感じています。
弊社がモック開発で直面したこと
抽象的な話に聞こえるかもしれないので、弊社が実際に経験した話をご紹介します。
あるお客様向けに、システムのモックを制作したときのことです。モックといっても、Next.jsとSupabaseで構築した簡易システムで、実際に動作するレベルのものでした。AIエージェントを活用して、スピード重視でどんどん画面を量産していきました。
画面のレイアウトは、ほぼ同じパターンで構成されていました。上部にパンくずリストがあり、その下に検索部、中央に明細部、下にフッター。こういった共通の構造を持つ画面を、いくつも並行して作っていったのです。
最初のうちは問題ありませんでした。AIエージェントが次々と画面を生成してくれて、見た目の進捗は順調でした。しかし、お客様からのフィードバックを反映し始めたあたりから、雲行きが怪しくなってきました。「この画面はAパターンで、こちらはBパターンで」と分岐が増え、実装されたものの使われない残骸コードが散らばり始めたのです。
そして、致命的だったのは共通部分の修正です。「検索部のこの項目を全画面で変更したい」という依頼が来たとき、本来であれば一箇所を直せば全画面に反映されるべきものが、実際には各画面に似たようなコードが散在していたため、一つひとつ手で直す必要がありました。当然、修正漏れが発生しました。「あの画面だけ直っていない」ということが何度も起きたのです。
幸いモックだったので乗り切れましたが、もしこれが本番システムだったらと思うとぞっとします。まさに「速く壊れるものを作ってしまった」典型例でした。そして、これに近いことがAIエージェントを使った開発の現場で、今もあちこちで起きていると私たちは確信しています。
人間が保守しやすいコードは、AIも保守しやすい
この経験から私たちが学んだのは、「人間が保守しやすいコードは、AIにとっても保守しやすい」ということです。
逆もまた真なりで、人間にとって分かりにくい、散らかったコードは、AIにとっても扱いにくいコードです。共通化された美しいコードであれば、AIエージェントは一箇所を直すだけで修正を全体に反映できます。しかし、同じようなコードが複数箇所に散らばっていると、AIも修正対象を取りこぼします。私たちはこれを何度も経験しました。
興味深いのは、AIエージェントは現時点では「共通化しましょう」という提案を自発的にしてくれることがほとんどない、という点です。明確に共通化の指示や設計思想を与えない限り、似たようなコードを平気で量産していきます。こちらから「この部分は共通化すべきでは？」と問題提起すると、きちんと対応してくれるのですが、その問題提起ができるのは人間のほうなのです。
つまり、AIに速く”壊れないもの”を作らせるためには、人間がシステム全体を俯瞰して、どこが共通化できるのか、どこが分離されるべきなのかを判断し、適切に指示を出す必要があります。この判断力を持たないままAIに丸投げすれば、出来上がるのは——やはり「速く壊れるもの」なのです。
壊れないシステムを作るために必要なもの
では、速さを保ちながらも本当に良いシステムを作るには、何が必要なのか。弊社が日々の開発で重視している要素をお伝えします。
まず、ビジネスの設計と本質の理解です。そもそも、このシステムは何のために作るのか。お客様のどんな課題を解決するのか。ここが曖昧なまま開発を始めると、後から「やっぱりこうしたい」という方針転換が連発し、コードは継ぎ接ぎだらけになります。開発を始める前に、ビジネスの本質を言語化することが何よりも重要です。
次に、コードの質とテストの質です。共通化された美しいコードは、人間にとってもAIにとっても扱いやすく、変更への強さを生みます。そしてテストがしっかりしていれば、AIが生成したコードが本当に正しく動くかを客観的に担保できます。AIがどれだけ速くコードを書いても、テストが甘ければその品質は保証されません。
さらに、統一されたUI/UXです。画面ごとにバラバラな操作感のシステムは、お客様にとって使いづらいだけでなく、保守の観点からも悪夢です。統一されたデザインシステムやコンポーネント設計が、長期的な開発効率を支えます。
そして、ルール化です。弊社ではコーディング規約やレビューガイドラインの整備、設計ドキュメントのテンプレート化、AIエージェントへの指示ルールの策定など、チーム全体で品質を担保するためのルール作りを進めています。ルールが明文化されていれば、AIエージェントに対しても一貫した指示が出せますし、チームメンバー間でも品質の認識が揃います。
最後に、これらすべての土台として、ビジネスマインドと顧客志向が欠かせません。どれだけ技術的に優れたシステムを作っても、それがお客様のビジネスに役立たなければ意味がありません。AIエージェントを使えば、技術的には何でも作れるようになりつつあります。だからこそ、「何を作るべきか」「なぜそれを作るのか」という、ビジネスと顧客起点の判断力が、これまで以上に求められているのです。
たとえば、ネットワークの仕組みを理解しているエンジニアは、システム間の連携部分で起こりうるトラブルを事前に想定した設計ができます。プログラムが動く仕組みを理解しているエンジニアは、処理速度やメモリの観点から無理のない構造を描けます。これらは目には見えにくい力ですが、システムの信頼性や長期的な運用コストに直結します。
「実装力」とは、設計パターンやアーキテクチャの知識と、それを適切に使い分ける力のことです。わかりやすく言えば、「保守しやすく、変更に強いシステムをどう構造化するか」を判断する力です。
弊社では、コードレビューの場を単なるバグチェックではなく、設計判断を議論する場として活用しています。「なぜこの構造にしたのか」「将来この機能を拡張するとき、この設計で対応できるか」。こうした問いをレビューの中で繰り返すことで、チーム全体の設計力を底上げしています。AIが生成したコードであっても、この設計レビューのプロセスは変わりません。
終わりに
AIエージェントの登場によって、システムを作るスピードはかつてないほど上がりました。しかし、スピードだけを追い求めた結果、後から高いツケを払うことになるお客様が増えてしまっては、業界全体にとって不幸なことです。
弊社が目指しているのは、速さと品質を両立させたシステム開発です。AIエージェントの力を最大限に活用しながらも、ビジネスの本質、コードの質、テストの質、統一されたUI/UX、そしてチーム全体のルール化。これらすべてを揃えることで初めて、速く、保守しやすく、そしてお客様が本当に欲しいものを作ることができると信じています。
藤沢市で一番技術力の高いシステム会社を目指して、弊社は日々研鑽を積んでいます。システム開発や技術に関するご相談がございましたら、どんな小さなことでもお気軽にお問い合わせください。
