こんにちは、kickflowでCTOを務めている小林です。
kickflowでは、プロダクト開発の効率化と品質向上を目指して、常に新しい技術やツールを積極的に検証・導入しています。その一環として、最近注目を集めているAIコーディングツールのClineを約1ヶ月間、実際の開発業務で集中的に利用してみました。
本記事では、Clineを様々なプロジェクトで試した結果、どのようなことが可能になり、逆にどのような課題が見えてきたのか、そしてAIコーディングツールを効果的に活用するためのTipsについて、kickflowの開発現場からのリアルな声をお届けします。
Clineとは
Clineは、AIを活用してソフトウェア開発の様々なタスクを支援するVSCodeプラグインです。コード生成、リファクタリング、テスト作成、ドキュメント作成、技術的な相談など、幅広い用途で利用できます。VSCodeと連携し、ファイルやディレクトリ構造、ターミナルの出力などを認識しながら、より文脈に沿ったサポートを提供してくれる点が特徴です。
利用環境
今回、Clineを以下の2つの異なるタイプのプロジェクトで試してみました。
- kickflow本体の開発:
- 比較的規模の大きい既存プロダクト
- バックエンド: Ruby on Rails
- フロントエンド: Nuxt（言語はTypeScript）
- UIフレームワーク: Vuetifyをラップした独自ライブラリ
- 社内用ツールの新規開発:
- 比較的小規模な新規プロダクト
- バックエンド: NestJS（言語はTypeScript）
- フロントエンド: Next.js（言語はTypeScript）
- UIフレームワーク: shadcn/ui
主に利用したAIモデルは以下の通りです。タスクの複雑さや求める精度に応じて使い分けました。
Clineでできたこと
爆速で新規開発できる
まず驚いたのは、NestJS + Next.js + shadcn/ui というモダンな技術スタックを用いた新規開発における生産性の向上です。
- 基本的なCRUD機能の実装: スキーマ定義からAPIエンドポイント、フロントエンドのコンポーネント作成まで、大まかな指示を与えるだけで、かなりの部分を自動生成してくれました。
- 定型的なコード生成: 大きな失敗はなく、複雑なロジックの実装の際に細かいミスをしたり、可読性の低いコードを書くときがあるものの、人間が都度レビューし、簡単な指示で軌道修正できる範囲でした。
- 外部サービスやライブラリの利用: 例えば、Elasticsearchを使ったベクトル検索の実装や、それを利用するためのNestJSのコードなども、基本的な部分は問題なく生成できました。
TypeScriptの型情報や、NestJS、Next.jsといったフレームワークの規約がしっかりしていること、そしてAIがこれらの技術に関する学習データを豊富に持っていることが、高い生産性につながっていると考えられます。
既存プロダクト（kickflow）開発での部分的な活用
一方、Rails + Nuxt + 独自UIフレームワークで構成されるkickflow本体の開発においては、まだ限定的な活用にとどまっています。
- 得意なタスク:
- RSpecによるテストコード生成: 既存のテストコードのパターンを学習し、コントローラーやサービスのテストを網羅的に作成できます。
- OpenAPI (YAML) の記述: APIの仕様変更に伴うドキュメント更新など、定型的な作業は得意なようです。
- 苦手なタスク:
- 複雑なビジネスロジックの実装: 規模が大きいアプリケーションだと既存機能の仕様や設計をAIが十分に理解できないと、複雑なビジネスロジックの実装は難しいようです。
- 独自UIフレームワークを利用したフロントエンド開発: これについては後述します。
共通して便利だったこと
- 設計相談: 新機能のアーキテクチャや、既存コードの改善点について壁打ち相手として非常に役立ちました。「こういう要件だけど、どういう設計が良いか？」「このコード、もっと効率的に書けないか？」といった相談に、多様な選択肢や考慮事項を提示してくれます。
- 技術選定の補助: 新しいライブラリやツールを導入する際、そのメリット・デメリット、類似ツールとの比較などを素早くリストアップしてくれます。ただし、AIの提案を鵜呑みにせず、必ず自分で公式ドキュメントを確認したり、実際に試したりして裏付けを取ることが重要です。AIは時として古い情報や誤った情報を提供することがあります。
- テストやLintエラーの解消: VitestやESLintでエラーが発生すると、ターミナルに出力されたエラーログをそのままコピペしてClineを動かすことで、Clineがいい感じにエラーを修正してくれます。
Clineでできなかったこと・課題
1ヶ月間 Cline を使い込む中で、現状のAIコーディングツールが抱える課題や限界も見えてきました。
ファイルサイズと複雑性の壁
- 巨大なファイルの扱いは苦手: 体感として、1000行を超えるような巨大なファイルを一度に扱わせるのは、どのLLMを使用しても困難でした。ファイルの行数が300行程度から怪しくなり始め、RSpecの
contextに対応するendを書き忘れたり、同じような処理やコメントを重複して記述したりといったミスが頻発するようになります。 - リファクタリングの限界: ファイルが大きくなると、全体を見通したリファクタリングも難しくなります。人間と同じで、巨大なファイルやクラスはAIも得意ではないようです。
動作確認が不安定
Clineはターミナル操作やブラウザを起動しての動作確認も可能ですが、挙動が不安定で人間が確認した方が早いケースが多かったです。ターミナルに関してはエラーが出ているのに気づかずに次の作業に進んだり、ブラウザ操作も基本的な要素のクリックで何度も失敗するなどしていました。結局Clineにはコーディングやレビューだけやってもらい、動作確認は自分でやるという進め方に落ち着きました。
独自UIフレームワークの理解不足
kickflowでは、Vuetifyを薄くラップした独自のUIコンポーネントライブラリを使用しています。Clineはこの独自ライブラリの仕様や使い方を正確に理解できず、コンポーネントのpropsを正しく指定できないことが多々ありました。
これは、AIが学習データとして持っていない情報（社内ライブラリの仕様など）に基づいてコードを生成する必要がある場合に共通する課題と考えられます。Ubieさんの記事 で言及されているような、デザインシステムや独自ライブラリの情報をAIが理解できる形で提供する仕組み（MCPサーバーなど）が必要になるのかもしれません。
Rubyライブラリの知識不足
RailsやRSpecといったメジャーなライブラリであれば問題ありませんが、GitHubのスター数が数百程度のRubyライブラリについては、その使い方を正しく理解していないケースが見られました。結局、人間がGitHubのREADMEやexamplesを確認して実装することが多かったです。
静的型付け言語との差
TypeScriptのような静的型付け言語の場合、AIが明らかに型に合わないコードを生成しても、トランスパイルエラーや型チェッカーによって早期に検知され、AI自身が修正を試みることができます。
一方、Rubyのような動的型付け言語では、実際にRSpecを実行してみるまでAIがエラーに気付いてくれません。これにより、手戻りが大きくなる可能性があります。
新しい技術への追随が苦手
React Server Componentsのような登場して間もない技術や、まだベストプラクティスが確立されていない技術については、AIもまだ十分に学習できておらず、最適なコードを生成できない場合があります。また、GCPのAI関連のSDKのように、多数のライブラリが乱立しており、人間でもどれを使うべきか迷うようなものについては、AIも適切な選択が難しいようです。
Clineを使いこなすためのTips
これらの経験を通して、ClineのようなAIコーディングツールを効果的に活用するためのいくつかのTipsが見えてきました。
1. ルールを整備する（最重要）
AIにコードを書かせる上で最も重要なのは、明確な指示とルールを与えることです。期待通りのコードを出力させるためには、「こういう場合はこう書いてほしい」「この書き方はしないでほしい」といったルールを .clinerules 以下にマークダウン形式で記述し、Clineに読み込ませることが非常に効果的です。
以下はkickflowで使用している .clinerules の一例です。
# コーディング規約 - 簡潔で完璧なコードのみを記述してください。 - 怠けるな、コードを省略するな。 - パブリックなクラスや関数には、YARDやJSDoc形式のコメントを必ず記述してください。 - DRY 原則を守ってください。 - SOLID 原則を守ってください。 - KISS 原則を守ってください。 - YAGNI 原則を守ってください。 - 継承よりもコンポジションを優先してください。 - カスタムの指示に従うことを誓います - コードの変更に伴うドキュメントの更新を怠らないでください。 - ビジネスロジックには単体テストを書いてください。 - 脆弱性を含むコードは書かないでください。 - スケーラビリティを考慮してください。
意図と違うコードが生成された場合は、その都度ルールに追記していくことで、徐々にAIの出力精度を高めることができます。
2. タスクを細かく分割する
前述の通り、AIは一度に大量のコードを扱ったり、複雑なタスクを実行したりするのが苦手です。大きな機能を実装する場合は、以下のようにタスクを細かく分割して依頼するのが効果的です。
- モデル（データ構造）の定義
- データベースマイグレーションの作成
- 基本的なCRUD処理を行うサービスクラスの実装
- サービスクラスに対応するコントローラー（APIエンドポイント）の実装
- ユニットテストの作成
- フロントエンドのデータ取得処理の実装
- UIコンポーネントの実装
タスクが長くなりそうな場合は、より長いコンテキストウィンドウを持つ Gemini 2.5 を使うなども検討します。
3. プロジェクトの関するドキュメントを与える
プロジェクト内に docs ディレクトリを作成し、ここにプロジェクトの概要、アーキテクチャ、コーディング規約、利用している独自ライブラリの仕様などを記述しておきます。AIにそれらを参照するように指示してからタスクを開始すると、よりプロジェクトの文脈に合ったコードを生成してくれるようになります。コードと仕様書・設計書を近くに置くことが重要です。
4. メモリバンクの活用（今回は未使用）
Clineには メモリバンク という、タスクを横断してAIに記憶させておきたい情報を記述する機能があります。今回は docs ディレクトリに必要な情報を集約したためメモリバンクは使用しませんでしたが、複数のタスクにまたがる作業を依頼したい場合はメモリバンクを活用するか、作業進捗を記録した progress.md みたいなファイルを作成することも効果的かもしれません。
5. AIによるリファクタリングを促す
AIは指示しない限り、積極的にリファクタリングを行いません。むしろ、後方互換性を過度に維持しようとして、既存のコードに処理を追加していく傾向があり、結果としてコードが複雑化してしまうことがあります。
リファクタリングせずに機能が追加されていった結果、コード行数が300行を超えるようなファイルができてしまうとAIが扱いにくくなるため、「AIに実装を指示 → AIにリファクタリングを指示 → AIに実装を指示 → ...」というサイクルを意識的に回すことが、コードの品質を保つ上で重要になります。
6. AIの作業中は下手に手を出さない
AIがタスクを実行中に、人間が同じファイルを編集すると、AIがその差分をうまく認識できず、人間が行った変更を元に戻してしまったり、予期せぬコンフリクトが発生したりすることがあります。基本的にはAIにタスクを任せ、完了するまで待つのが安全です。もし途中でどうしても編集が必要になった場合は、編集後にどのような変更を加えたかをAIに伝えることで、混乱を最小限に抑えられます。
AIコーディングツールの普及による影響の考察
今回の検証を通して、AIコーディングツールの活用は、今後のソフトウェア開発のあり方に少なからず影響を与えるだろうと感じました。
「AIに寄せた」技術選定の可能性
Ruby + Nuxt + 独自フレームワークのkickflow開発と、NestJS + Next.js + shadcn/ui の新規開発では、AIによる開発支援の精度に大きな差がありました（もちろん、プロジェクトの規模やコードベースの複雑さも影響しています）。
今後、AIコーディングツールの活用を前提とするならば、以下のような特徴を持つ技術スタックが有利になる可能性があります。
- 静的型付け言語: 型情報がAIのコード理解と生成精度を高める。（例: TypeScript）
- AIの学習データが豊富な言語・フレームワーク: より多くの開発者に使われており、Web上に情報が多いもの。（例: Python, JavaScript/TypeScript など）
- AIが利用しやすいエコシステム: 各種AIモデルを呼び出すための公式SDKが提供されている言語。（例: Python, TypeScript）
これらの条件を満たす TypeScript は、今後ますますその重要性を増していくのではないかと感じています。
今後の展望
今回の検証結果を受け、kickflowではAIコーディングツールのさらなる活用を推進しています。
- 社内展開: 先日、社内エンジニア、QAエンジニア、CRE（Customer Reliability Engineer）向けにClineのデモンストレーションを行い、希望者全員にAPIキーを配布しました。各チームでRSpecの生成やドキュメント作成、E2Eテストの自動作成など、様々な用途で活用が始まっているようです。
- 他のツールの検証: Cline以外にも、有望なAIコーディングツールが登場しています。今後は以下のツールについても検証を進め、kickflowの開発プロセスに最適なものを見つけていきたいと考えています。
- Cursor: AIファーストなコードエディタとして定番。
- Windsurf: JetBrains IDE（RubyMineなど）でも利用可能なAIコーディングツール。
- Roo Code: Clineからフォークした、より多機能で柔軟性の高いツール。
- GitHub Copilot: すでに導入しておりエージェントモードも試しましたが、現時点ではClineほどの開発体験は得られていません。GitHubネイティブの強みを活かした今後の進化に期待しています。
おわりに
AIコーディングツール Cline を1ヶ月間集中的に利用し、その可能性と限界、そして効果的な活用方法について、kickflowでの実例を交えながらご紹介しました。
AIはまだ万能ではなく、特に独自性の高いコードベースや新しい技術領域においては課題も残りますが、ルール整備やタスク分割といった工夫次第で、開発プロセスを大幅に効率化できるポテンシャルを秘めていることは間違いありません。今後もkickflowでは、AIをはじめとする新しい技術を積極的に取り入れ、より良いプロダクト開発を目指していきます。
kickflowでは、このような新しい技術の検証・導入に積極的に取り組み、開発プロセスを改善していくことに興味があるエンジニアを募集しています！
