はじめに
CyberACE で「CoBi（Co-Growth Bot with AI）」、新規サービスの開発をしている kazz_ogawa と申します。
近年、LLMベースの開発支援ツール（例：GitHub Copilot など）の進化により、開発の進め方自体が変わってきました。
本記事では、筆者が実務で複数のツールを試しながら得た結果を共有します。
本記事でわかること
- 開発アクティビティの変化
- ツール遍歴（Cursor → Claude Code → Kiro）
- 開発体験の変化
開発アクティビティの変化
まず、直近の私の開発アクティビティ変化を可視化しました。
対象期間は 2025/04–2025/08（うち 5月末〜7月中旬は設計・調査・検証が中心だったため除外）。
集計方法は「アクティビティがある日」に限定して1日平均を算出しています。
lockやmockファイルは除外してカウントしています。
| Cursor使用時 | Claude Code + Kiro使用時 |
|---|---|
 |
 |
アクティビティがある日に絞って平均を出しています。
母数はCursor期:17日, Claude+Kiro期:20日です。
| 指標 | Cursor使用時 | Claude Code + Kiro使用時 |
|---|---|---|
| コミット数/day | 2.53 | 3.30 |
| PRマージ数/day | 0.65 | 1.00 |
| コード追加行数/day | 378.53 | 626.80 |
| コード削除行数/day | 174.06 | 185.20 |
| ファイル修正数/day | 9.06 | 14.50 |
コミット数+約30%、PRマージ数+約50%ほど増え、活動量が増加した傾向が確認できました。
LLMベースの開発支援ツール遍歴：Cursor → Claude Code → Kiro
Cursorからなぜ乗り換えたのか
社内制度の活用により、Claude Codeを経費で試せる環境が整いました。子会社でも恩恵を受けることができ、働きやすい環境だと感じています。
Claude CodeのPlan Modeを使ってから、生産性が大きく向上しました。
Plan Modeでは、issueの解決の道筋を最初に決めてから実装できます。設計方針や考慮不足な点を一緒に考えることができるため、Vibe Codingと比較して手戻りが大きく減りました。
Plan Modeの上位互換、Kiro
Claude Codeを使い慣れてきたタイミングで出たのがKiroでした。
Kiroは仕様駆動開発を行うことができます。
Plan Modeよりも細かく要件と仕様を明文化してから実装を始めます。
KiroのSpecsを使うことで下記3つのファイルを生成することができます。
requirements.md
要件定義書。達成したい概要からエラーハンドリングまでをあらかじめ文章化します。考慮が足りていない部分や懸念事項があればこの時点で洗い出すことができます。
例:
# 要件定義書
## 概要
指定されたIDで1件のデータを取得するAPIエンドポイントを作成します。このエンドポイントは管理画面で詳細情報を表示する際に使用されます。
## 要件
### 要件1
**ユーザーストーリー:** 特定のXXXの詳細情報を取得したいので、IDを指定してXXXのデータを1件取得できるAPIが必要です。
#### 受入基準
1. WHEN 有効なXXXのIDがリクエストされた場合 THEN システムは該当するXXXのデータを返却する
2. WHEN 存在しないIDがリクエストされた場合 THEN システムはNotFoundエラーを返却する
3. WHEN 無効なIDフォーマットがリクエストされた場合 THEN システムはBadRequestエラーを返却する
4. WHEN 認証されていないユーザーからのリクエストの場合 THEN システムはUnauthorizedエラーを返却する
### 要件2
...
design.md
設計書。実装を踏まえたドメインやアーキテクチャを文章化します。
既存のアーキテクチャに沿った命名規則、実装を考えてくれます。
例:
# 設計書
## 概要
Firestoreから指定されたIDで1件のXXXデータを取得するAPIエンドポイント `/v1/GetXXXById` を実装します。このエンドポイントは既存のAPIと同じアーキテクチャパターンに従い、認証、エラーハンドリング、ログ出力を含む完全な実装を提供します。
## アーキテクチャ
### レイヤー構成
HTTP Request → Handler → Usecase → Repository → Firestore
↓
HTTP Response ← Handler ← Usecase ← Repository ← Firestore
### 既存パターンとの一貫性
- **HTTPメソッド**: POST（既存APIとの一貫性のため）
- **認証**: AuthMiddleware使用
- **エラーハンドリング**: 既存の共通エラーハンドリング方針に従う
- **レスポンス形式**: protobuf使用
- **ログ出力**: 既存のログ出力方針に従う
## コンポーネントとインターフェース
### 1. Protocol Buffers定義
...
### 2. Handler層
...
### 3. Usecase層
...
tasks.md
実装計画書。実装をタスク粒度に分割し、1つずつタスクを取り組むように指示を出すことができます。
例:
# 実装計画
⚡️Start Task
- [ ] 1. Protocol Buffers定義の追加
- proto/app/app.proto にXXXByIdのrpc定義を追加
- XXXRequestとXXXResponseメッセージを定義
- protobufファイルからGoコードを生成
- _要件: 1.2, 2.1, 2.3_
- [ ] 2. Usecase層の実装
...
Kiroで特に使い勝手が良いと感じた点は次のとおりです。
- ⚡️Start Taskをワンクリックでタスク開始
- 提案されたスクリプトを実行前に修正できる
- 間違いがあれば再度指示して修正できる
現在は
- Kiro：issue解決や新規機能の実装（要件→設計→実装の一連）
- Claude Code CLI：リファクタや小さな修正
と使い分けています。
開発体験の変化
LLMベースの開発支援ツールが担当できる領域が広がり、人間の主戦場は「課題の把握」と「レビュー」になりました。今まで以上に注力する必要があります。
実態はこう
おわりに
LLMベースの開発支援ツールが担える範囲は、これからも確実に広がります。だからこそ重要になるのは次の二点です。
1. たくさんの生成物を適切にレビューする
なんとなく良さそう、でレビューを通してしまうと、そのコードをベースに低品質の生成物が生成され、負の循環になってしまいます。(コードの重複、ネストが深い、責務が大きい、..etc)
業務ドメイン、使用言語の作法、プロジェクトのアーキテクチャ、インフラ構成、CI/CD の流れといった基礎を押さえておく必要があります。
2. 触って学び、知見を共有する
LLMベースの開発支援ツールを使えば使うほど、都合よくなんでも解決できるわけではないことがわかります。
積極的に使える環境を選び（あるいは作り）、導入して、トライアンドエラーを繰り返し、体験を共有し、チームのナレッジを醸成させることも大切です。
CyberACEでは開発AIエージェント導入費用のサポート以外にも、CyberACE独自の補助として書籍補助もあるため、上記2点に取り組む環境は揃っています。
もし、この環境でインターンをしてみたい！と思ってくださる方がいましたら、ぜひエントリーをご検討ください。
株式会社CyberACEのテックブログです。開発チームが日々の業務で得た技術的な学びや知見を発信します。主な技術スタック: TypeScript, Go, React, Next.js, AWS, GCP cyberace.co.jp
Discussion