AI時代に問われる「開発の本質」と自動化への思想

株式会社フライルの山下裕一朗と申します。本日は、AI駆動開発を実現するためのアーキテクチャと取り組みというテーマで、弊社が実施していることをご共有できればと考えております。今回は、人間がやるべきことを見極めるということと、それ以外を完全自動化することを目指すためにどうするか、ということをお話しします。

最近のAIツールを振り返ってみると、進化が非常に目覚ましい世界です。私の場合、壁打ちや相談にはGeminiやChatGPT、DeepWikiを使用し、実装にはCursorやVIBE-KANBAN、Clineなどを使っています。コードレビューにもClineを使ったりしつつ、横断でMCPを活用しています。

ソフトウェアエンジニアベンチマークの最新結果を見ると、Gemini3.5 Proは74.20%というスコアを叩き出しており、これほどコーディングが得意なAIを使わずに開発するのは、もう時代遅れなのかもしれません。AIにほとんどの実装を任せられる状況に近づいている感覚は、皆さんも持っているのではないでしょうか。

エリック・エヴァンスが提唱する、ソフトウェア開発の核心

一方で、開発作業のすべてをAIに任せられるようになったのかという問いに対しては、私はNOだと考えています。

エリック・エヴァンスの『ドメイン駆動設計』には、「ソフトウェア開発の複雑さの核心は、自動化しようとしている対象領域そのものが持つ本質的な複雑さにある」と書かれています。この複雑さを紐解くことこそが、ソフトウェア開発の中心だということではないでしょうか。そして、その中で人間がやるべきことは何なのか、それ以外をどう自動化できるのかを考えていきます。

AIをフル活用したドメイン理解・実装フロー

###ドメイン理解は、人と人との対話が重要

私は弊社でソフトウェアエンジニアをしており、SvelteのコアチームメンバーとしてコンパイラやESLint関連のツールを担当しています。

今回はソフトウェア開発を、「ドメインを理解する」「要件定義・設計をする」「実装する」という3つのフェーズに分けてお話しします。今回は、ドメイン理解と実装のフェーズにフォーカスします。

ドメイン理解とは、ソフトウェア開発とは何かしらの業務を自動化したり高度化したりすることです。

例えば自社では、VoCと呼ばれる顧客データをAIやソフトウェアで活用する仕組みを開発しています。コールセンターのオペレーターが受電後にラベル付けや要約を行い、そのログがSalesforceに登録され、製品部門が分析してレポートを作成するというワークフローがあります。

このプロセスには入力負荷の高さや品質の属人化、膨大なデータへの対応限界といった課題があります。こうした状況や歴史的経緯を詳細に紐解くプロセスは、顧客との対話を通じてのみ理解できることであり、インターネットに情報がないためAIで自動化することは不可能です。ただし、ドメイン理解を促進するための一般的な知識を補填するためにAIを活用するのは非常に有効です。

実装フローでもAIエージェントを駆使

続いて、実装のパートについてお話しします。弊社の実装フローは、方針を検討し、実装し、レビューするという流れです。方針検討では既存コードを前提に、ChatGPT、Gemini、Cline、DeepWiki、Cursorを使っています。

DeepWikiはコードベースの詳細を正確に教えてくれるため、弊社では実装の詳細を解説するマークダウンをすべて廃止し、DeepWiki一本で運用しており、オンボーディングでも活躍しています。Cursor Agentを使えば、複数のモデルで並行して実装方針を考え、いいとこ取りをすることも可能です。

実装自体はCursorやVIBE-KANBAN、Clineが担当します。VIBE-KANBANはタスクを追加するとAIが実装してプルリクエストまで作成してくれるツールで、複数のタスクを並走させて夜間にバグ修正を任せるといった使い方が可能です。

秩序を維持する、品質ゲートとテスト戦略

静的検査パイプラインとAGENTS.mdによる自律的制御

しかし、AIにただコードを書かせると無秩序になり、メンテナンス不能になる「VIBEコーディングあるある」の問題が発生します。

これを乗り越えるために、弊社ではTypeScriptやESLintなどのツールを通じてコードの秩序を維持し、意図しないリグレッションを防いでいます。具体的には、フォーマット、型検査、静的検査、不要コードの検査、パッケージ設定の検査というパイプラインを運用しています。

不要コードの検査にはKnipを使い、AIが不必要に残したコードを自動検出しています。また、これらをGitHub Actionsで実行するだけでなく、AGENTS.mdを通じてAIにもこれらの品質ゲートをパスするように指示しています。

変更耐性を確保する「モックなし」のテストアーキテクチャ

静的検査についてはESLintを最大限活用しており、現在ではJavaScript以外のVueやSvelte、SQLなども検査対象にしています。

弊社ではHonoを使用していますが、リクエストデータを直接取得せずに特定の関数を経由させるルールや、エラーハンドリングを強制するルールなど、50個以上の自社独自ルールを運用しています。こうしたルールの実装は難しそうに思えますが、現代ではLLMがほとんどのルールを実装してくれるため、静的検査の堅牢な仕組みは誰でも構築できます。

リグレッションを防ぐためにはテストが重要ですが、メンテナンス工数の爆発を防ぐためにテストアーキテクチャを設計しています。バックエンドのAPIテストは、データベースの初期データを宣言的に定義し、実行後にロールバックする仕組みを構築しており、ほとんどをモックなしの結合テストで行っています。

変更頻度の低い外部インターフェースに対して結合テストを行うことで変更耐性が得られ、LLMによる大胆なリファクタリングも可能になります。実際、データ構造を抜本的に書き換える大きな変更を行った際も、このテストアーキテクチャのおかげで本番リリース後のバグ報告はゼロでした。

なおレビューのフェーズでは、CodexやCline、CrowdCode Security Reviewerなどのツールを使っています。特にCodexはクリティカルな指摘を的確にしてくれるため、導入を強くお勧めします。

まとめ

今後も当社では、開発におけるAI活用を進めてまいります。人間がすべきことを見極め、それ以外の実装や検証は徹底的に自動化を目指しましょう。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。