Cline で AI 主導開発を体験して分かったこと
👋 はじめに
AI エージェント「Cline」を使って、実際に 1 つのアプリケーションを開発してみました。私はもともとフルスタックエンジニアですが、現在はソフトウェア開発が本業ではなく、限られた時間の中でアプリを作ることに常に工夫が求められています。なので、短期間で実用的なプロトタイプを構築する方法には強い関心がありました。
この記事では、そのような状況で Cline を使いながら感じたこと、工夫したことを、「忙しいけれどアプリ開発を本気でやりたい人」 に向けて共有します。
📊 開発プロセス全体像
今回採用した開発プロセスは、人間と AI エージェントの役割分担を明確にしたものです。まず私が画面モック、ユーザーストーリー、ER 図といった概要レベルのドキュメントを作成し、それを元に Cline が詳細な仕様書の作成からコーディングまでを自動実行する流れになります。
このアプローチが理想通りに機能すれば、開発者は高レベルな設計に集中し、実装の詳細は Cline に任せることで大幅な効率化が期待できます。
具体的に行ったプロセスは以下の通りです。
🤔 なぜ Cline を使おうと思ったのか
理由はシンプルで、「流行っていたから」でもありますが、それ以上に
- 普段はアプリケーション開発が本業ではない
- ドキュメントをじっくり調べたり設計に時間を割けない
という状況の中で、Copilot では不可能だった開発のオートメーションが Cline ならできるのでは？という期待があったからです。
同じようなツールで有名なのが Cursor ですが、Cline のほうが VSCode に慣れた自分には合っていると思ったのも理由の一つです。
🛠️ 作ったアプリケーションの概要
-
目的：RAG（Retrieval-Augmented Generation）の精度や効果を改善するための Web アプリ
-
内容：RAG の挙動や構成を可視化・操作する統合コンソール的なもの
-
技術構成：
- React（フロントエンド）
- Java / Spring Boot（バックエンド）
- Amazon DynamoDB（データベース層）
-
アーキテクチャ：PoC レベルだが、実用を見据えてレイヤードアーキテクチャを採用
🎯 Cline を使って良かったこと・苦労したこと
良かったこと
以前は GitHub Copilot を使っていましたが、
- 断片的なコードしか生成できず、オートメーションはできない
という限界がありました。Cline はそこが違いました。
- アプリケーション全体の構造を理解した上で、どんどん自動でコードを生成してくれる
これは本当に期待通りでした。
苦労したこと
もちろん課題も多かったです。
-
最初は多くの人と同じく Memory Bank に頼っていた
-
しかし Memory Bank だけでは、全体の制約や整合性をコントロールできない
-
そこで Cline Rules を整備し始めたが、
- Cline Rules ファイルが肥大化
- トークンコストが高騰
- メンテナンスが困難
この辺は「便利さ」と「運用負荷」のトレードオフだと感じました。
💡 工夫したポイント
1. Cline Rules のリファクタリングを実施
肥大化した Cline Rules を整理するため、以下のようなリファクタリングを行いました：
- 情報の重複排除
- 情報の矛盾解決
- 冗長な文章の圧縮
- ルールと手順の分割
これらの作業はすべて Cline 自身に依頼すればうまくいきました。LLM の得意分野である「自然言語の理解と生成」を活用しました。
2. Cline Workflows の導入で整理された工程管理
最近になって、Cline Rules の中に Cline Workflows を定義できるようになりました。
これにより、以下の 2 つの概念を明確に分離できるようになりました：
- 抽象的な設計思想（Cline Rules）と
- 具体的な出力の流れ（Cline Workflows）
この分離により、Rules の肥大化を防ぎ、メンテナンス性がさらに向上しました。
3. 初期設計より、変更に強い体制を先に整える
プロジェクト初期の段階で、技術スタックや UI デザインを完全に描ききるのは難しいです。
それよりも
- 変更があったときに安全に回せる Cline Workflows や運用方針
を先に決めておくほうが、結果的に開発効率が上がると感じました。
4. 設計変更する前提で構築
プログラムのリファクタリングは Cline の得意分野であることがわかりました。例えば、初期実装でベタ書きしていた認証・認可ロジックを、後から Spring Security ベースに切り替えることなどは、造作もなくできました。
そのため、最初からあまり完璧を求めず、設計を後から見直すことを前提にした開発を行いました。
5. プロンプトを最小化し、Cline Workflows に全てを込める
都度プロンプトで調整すると成果物のトンマナ（語調や構成、粒度）がブレてしまうことから、基本的にはプロンプトを避け、
Cline Workflows 内にすべての指示を明記する運用にシフトしました。
- すでに存在する成果物のスタイルや命名規則を尊重せよ
- 書きすぎない、既存構造を壊さない
など、やってほしくないことも明確に指示し、一貫した出力が得られるようになりました。
📋 Cline Workflows の具体例
フェーズ 1：構造化仕様書の生成
- ER 図などの視覚的なデータモデルから、DB 仕様書（DBML 形式）を生成
- 画面モックとユーザーストーリーから、UI 仕様書（構造化 Markdown 形式）を生成
- 上記 2 つの仕様書から、API 仕様書（OpenAPI 形式）を生成
この順序は仕様間の依存関係を意識して設計しました。
フェーズ 2：実装コードの生成
- DB 仕様書から、DynamoDB スキーマ（JSON）を生成
- API 仕様書から、バックエンドコード（Spring Boot）を生成
- UI 仕様書と API 仕様書から、フロントエンドコード（React）を生成
この順序は、各フェーズで生成物が次のフェーズの入力となるように設計しました。
📐 ルール設計の実例
Cline への指示を明確にするため、以下の 4 つにルールを分割：
- ディレクトリ構造（生成物の配置と命名規則）
- セキュリティスタンダード（CORS, 認証など）
- テックスタック指定（例：React18, Zustand4, Spring Boot 3.2）
- 依存ライブラリのバージョン制限（生成精度の安定化）
これらは Cline に一貫性ある出力をさせる上で非常に有効でした。
✨ 成功のポイントと再現性
今回の構成は、他のプロジェクトでもそのまま使える汎用性を意識して設計しました。
- Cline Workflows と Cline Rules の構成は再利用しやすい形にテンプレート化
- 設計変更も Cline を使えば安全かつ高速に可能（LLM 自体に変更依頼）
- 開発の初期段階でワークフローを整備しておくと後が楽になる
さらに、仕様書を極力オープンな仕様（DBML, OpenAPI, Markdown など）で記述することで、以下のようなメリットも得られた：
- 外部のチームやシステムによる自動テスト（API のモンキーテストや UI の E2E テスト）を設計段階から想定可能
- これらの外部テストはそれ自体が 1 つの独立したシステムに相当する規模になるため、開発とテストをプロジェクト単位で分離する設計が自然と可能になった
- システム処理しやすい仕様書を媒介することによって、他のプロジェクトとの連携も自動化・効率化できる
💰 コスト・運用面の現実的な話
Cline のような生成系 AI を本格活用するには、コストの問題が避けて通れません。
- 個人では金額も厳しいし、社内で予算を通すのも大変
私のチームでは以下のように対応しました：
- Amazon Bedrock 経由で Claude を Cline のエンジンとして利用
- チームで固定予算を AWS に確保
- AWS の予算アラートでチーム単位の消費管理を実施
これである程度 Cline を自由に使える雰囲気が作れました。
🚀 感想
Cline を使いこなすには、Cline Rules や Cline Workflows の設計力が肝になります。でもこれをゼロから毎回作るのは大変でした。
- 具体的な設計事例（Cline Rules, Cline Workflows）が共有される記事やテンプレ
- 成果物ベースで「こんな構成だと動くよ」という知見の集積
そういったものが共有・再利用できるコラボレーション文化やエコシステムが、今後もっと育っていってほしいと思いました。
🏁 さいごに
Cline を使うことで、時間のない中でも一貫性のあるアプリケーションが開発できました。一方で、コスト・メンテ性・運用フローの整備など、「導入して終わり」ではない現実も見えてきました。
それでも、Copilot の時代では考えられなかったレベルの開発支援ができることは間違いありません。これから使ってみたい人の参考になれば幸いです。
個人的に、次は CLI 系の AI エージェントを使って同様のアプリケーション開発に挑戦してみたいと考えています。
💻 ソースコード
（公開準備中）
Discussion