Cursor, Devin を実務で使っていたら、コードを書ける時間の贅沢さに気づいた話
友人たちと続けている勉強会で開発AIツールの比較の座談会に登壇することになったので、いまの自分の開発AIツールの使い方をメモがてらまとめてみました。
日進月歩で開発AIツールの機能、ツール間やアプリケーションとの連携、ツール自体の登場などが進んでいるので、あくまで執筆時点での私の開発AIツールの使い方です。
自分自身も2週間前もすれば、使う機能、連携の仕方、開発プロセスのいずれかには大きな変化がある状況なので、明日には言ってることが違うかもしれません。
📌 開発AIツールを使う環境
どの開発AIツールが使用できるかや、有効に使えるかは、
組織環境、開発対象、開発プロセス、コードの状況、もともとの開発スタイル、データセキュリティの整備状況等で大きく変わると思っています。
比較的小規模で、適切なセキュリティチェックと設定をすれば開発AIツールやMCP連携を自由に使える時の自分の使い方をメモしていきます。
各種静的解析、単体テスト、デプロイメントパイプラインの整備は整備されている環境を想定しています。
開発でよく使用しているAIサービス
Cursor のエージェントモードの活用
- 基本的には Claude 3.7 Sonnet でエージェントモードを利用し実装を進める
- Cursor と MCP で Github や Google Tasks などを連携
- 実験的に Claude 3.7 Sonnet Max モードでの設計などプランニングをさせている
Devin の活用
- Slack から指示出して Devin を利用しています
- VSCode 拡張はあまり使いこなせてないです
- Devin 1.5 も出て使い方変わる可能性もあるかもです
- ほどほどに Knowledge をためていってます
- 使い方、使い分けは後述してみます
📌 開発AIツールの現時点での利用方法
五月雨に書いていきます。
コード理解を助けるドキュメントの整備
基本的には、ジュニアのエンジニアがこのコードベースを見た時にほしい情報を整備しようと考えながらドキュメントを整備していきます。
結果的にあとで Cursor のコンテキストにわたす時に効いてくるので積極的に整理していきます。
以下のような流れで作ることが多いです。
- コードの内容で理解できてない部分があれば Cursor の Ask Mode とかでどんどん聞いていく。
- 技術の概念が理解しきれてない場合には、公式ドキュメント読む + ChatGPT Deep Research などでまとめた概念を咀嚼して、自分の脳内に展開する。
- Cursor の Agent Mode (Claude 3.7 Sonnet)で該当するファイルやディレクトリなどコンテキストにわたして下書きを作成。
- 細かい部分は修正して完成。
例えば、こんなドキュメントを書いたり、集めたりしています。/docs の配下にまとめることが多いです。
- 事業の企画書
- 利用している技術スタック
- インフラ構成図
- CI/CDの仕組み
- アプリケーションアーキテクチャや設計思想
- 認証認可の仕組み
- このコードでのテストの考え方
Cursor の Project Rules の整備
あんまりたくさん書いてはないです。もっと改善していきたいです。
.cursor/rules に .mdx ファイルを作っていきます。
例えば web, backend のあるモノレポだと、 web.mdx, backend.mdx に加えてコードレビュー用の code_rexiew.mdx とかを書いてます。
内容は基本的な指針、使用している技術ごとの守ってほしい規則、このコードにおける特有のライブラリの使い方などを書いてます。
アプリケーション設計まとめファイルの整備
どれだけ効いてるかわからないのですが、meta-app-architecture.yaml みたいなファイルを作成してディレクトリのルートに置いてます。
アプリケーションアーキテクチャ、ディレクトリ構造、命名指針などを記述したファイルを書いてます。
Devin や Cursor エージェントモードで、コードの全体像の提供を容易にする目的です。
「meta-app-architecture.yaml を読んでコード構造を把握した上で、、、、」のようにとりあえずこのファイル指定しておけば、全体像は伝わるなと。
Cursor Agent Mode でまず作らせて修正し、その後は何かあるたびに Devin や Cursor に修正させてます。
# 技術スタック
tech_stack:
web:
- "Next.js v15"
- "React v19"
- "Shadcn UI"
- "Radix UI"
- "Tailwind CSS"
- "Clerk"
- "Vercel AI SDK"
backend:
- "Hono"
- "Drizzle"
- "PostgreSQL"
- "Clerk"
# アプリケーションのディレクトリ構造定義
root:
apps:
web: # Next.jsフロントエンド
src:
app: # Next.js App Router
(auth): # グループルート：認証関連
- $PAGE_NAME: # ページ名
- page.tsx: # ページコンポーネント
- loading.tsx: # ローディングコンポーネント
- error.tsx: # エラーコンポーネント
(default): # グループルート： デフォルト
...
api: # APIルート
...
components: # UIコンポーネント
ui: # 基本UIコンポーネント（shadcn）
$FEATURE_NAME: # 機能別コンポーネント
...
features: # 機能に関するコード
$FEATURE_NAME: # 機能名
- hooks: # カスタムフック
- utils: # ヘルパー関数
- components: # UIコンポーネント
- fetcher: # データフェッチ関数
- types: # 型定義
config: # 設定ファイル
...
backend: # Honoバックエンド
src:
routes: # APIルート
default: # デフォルトルート
$API_NAME: # APIディレクトリ
- $API_NAME.ts: # メインルーターファイル
- $API_NAME.test.ts: # テスト
- $API_NAME.request.ts: # リクエストスキーマ
- $API_NAME.response.ts: # レスポンススキーマ
admin: # 管理者用ルート
...
middlewares: # ミドルウェア
$MIDDLEWARE_NAME: # ミドルウェア名
...
drizzle: # Drizzle ORM
migrations: # マイグレーション
server.ts: # Standalone 用のサーバーエントリーポイント
index.ts: # バンドルされたサーバーエントリーポイント
drizzle.config.ts: # Drizzle設定
...
docs: # ドキュメント
architecture: # アーキテクチャ設計
plan: # サービス企画
specification: # 仕様書
development: # 開発手順
pnpm-workspace.yaml: # pnpm workspace設定
package.json: # パッケージ設定
turbo.json: # Turborepo設定
...
# 各ディレクトリの役割説明
directory_purposes:
...
# 命名規則
naming_conventions:
directories:
...
files:
...
# 重要な設計原則
design_principles:
...
# コーディング規約
coding_conventions:
...
# パフォーマンス最適化戦略
performance_optimization:
...
Cursor Notepad でのプロンプト管理
よく使うプロンプトがでてきたら Cursor の Notepad 機能に貼っておきます。
例: テストコードの作成指示プロンプト
Project Rules との使い分けは、自分用で、更新頻度高く、短いものを Notepad に入れています(正直なんとなく)
コードを読ませつつ Github Issue 作成
Cursor と Github を MCP で連携して Issue 作成しています。
-
Issue のタネをつくる
- Issue 作成前に、事業上の週次ゴールから Issue の候補をメモ書き程度に作成
- Issue 候補を Cursor エージェントモードに入力、アプリケーションアーキテクチャ等の情報を参照させ、Issue の候補出しを依頼
-
Issue のリッチ化
- Cursor と GitHub を連携させ、コードベースの該当箇所も参照させながら Issue を作成
- リッチな Issue 作成しておくと、後での指示出しが容易になっている気はします。
PR の下書き作成
Cursor と Github を MCP で連携して Pull Request の説明文を充実させています。
PR を雑に Draft で作成しておいて、後から説明文を書かせています。
Devin への依頼
Slack から Devin を利用しています。
基本は公式のガイドラインにそって使うように心がけてます。公式にある
「十分な時間と状況があれば、ジュニア エンジニアでもこれを理解できるだろうか?」
の基準はわかりやすいです。
ガイドラインも加味して補足的ですが Devin によく任せるのは以下のようなものです。
もっと細かく判断軸ありそうな気もしますが、さっと出せるものだけ。
現時点では Devin を使うと PR のレビューまつりがあるので、適用範囲を絞って使っている感覚があります。
- コードを書いてもらう
- 参考となるサンプルにできる実装がある
- 修正範囲が大きくないと予測できる
- レビューがすばやくできそうと感じる
- コード以外を書いてもらう
- あまり手直しが必要なさそうなドキュメント
- レビュー等の無視しても問題ないコメント
API のエンドポイント追加など繰り返しの作業が見込めるものは、開発手順を /docs 以下に書かせて使用しています。
サンプルにできる実装がある場合は、かなりいい頻度で PR をマージできています。
Devin へのメッセージも Cursor を使って書こともあれば、短く指示を出すこともあります。
一次レビューをしてもらうの助かってます。
レビューの指針を書いたドキュメントを .cursor/rules/code_review.mdc などに配備して、Devin に参考にしてもらいつつレビューコメントをもらいます。
5ACU(Agent Compute Unit)を超えないくらいのタスクをどんどん投げ込んでいく感じに使ってます。
わりと投機的に使用してて、うまくいかなかった PR はバッサリ捨ててゼロから指示を直していくこともあります。
👀 Devin API を使用して CI に組み込んで実施もいいなと思っています。ぜひ試してみたいです。
👀 とても参考にしています。
概念、言葉、メカニズムの理解を更新する
指示してがうまくコードが実装されないときは、自分の理解や前提のずれがあることも多々あります。
- ナレッジカットオフ以降の技術の概念や、ベストプラクティスの変更を伝えられていない
- その技術が使っている言葉とは少しずれた言葉遣いをしている
- 通常の組み合わせとは異なる技術の組み合わせ方をしいている
こういう時には、Deep Research で最新の情報の概要掴んだり、公式ドキュメント読んだり、Claude 3.7 Sonnet と対話しながら概念、言葉、メカニズムの理解をそろえたりして、指示しなおすとすっと実装できることもあります。
ほとんどのケースで自分よりコードを書くのがうまい存在なので、自分がボトルネックにならないようにしたいものです。
📌 雑記
ボトルネックと注目していること
欲が出るもので、もっとAIに任せる範囲を増やしたいという気持ちがつのります。
いまのプロセスの中でボトルネックに感じてるのは例えば
- 人間が AI に指示を出すまでのリードタイム
- サンプルとなる実装の提供
- PRのレビューとがマージできる状態かのジャッジ
- より多い人数で開発する際の一部のセキュリティの設定(とくにMCP連携するツールの権限まわり)
- 細かい指示出しのついやす時間
- より大きな事業目標と Issue レベルの整合性の調整
なんとなくですが、ここを解消しうる次のようなものには注目しています。
- (より長い時間かかるタスクを完了できる)新しいモデルやエージェント
- AI の作業完了をフックにしたイベント発行
- AI に渡すタスクリストの仕組み
- 複数開発タスク実行時の結果シミュレーションとシナリオ作り
- セキュリティ設定、認可に関連する自動プロビジョニング
- MCPの[Smapling](https://modelcontextprotocol.io/docs/concepts/sampling)のプロトコルに対応した実装
- PR の自動レビュー
- E2Eテスト作成のさらなる自動化
広く横断すること
種々のアーキテクチャーを決める時に、技術要因だけで決定できることはほぼゼロです。
ビジネス目標、いま投下できるリソース、関わる人にかかるインセンティブ、事業領域の構造、リスク許容度、すでにあるシステムとの関連性、セキュリティなどなどその他のたくさんの要因を加味して、設計しアーキテクチャーを決めていくことが多いと思います。
より AI にコードを書いてもらう量が増え、ツール横断で作業をこなしてもらう中で、
こういったより広い範囲の要素から、どこを、どのくらい重要なものとして指示を与えるのかという調整を都度していくゲームになるのだなと感じています。
贅沢な時間
いまの実装する流れをざっくりみれば次のような感じです。
- Cursor + Github を MCP 連携し作成してもらった Issue をもとに
- サンプルになる実装を Cursor で開発しながら
- PR の説明を Cursor に修正してもらい
- 出来上がった PR を Devin に一次レビューしてもらい
- 別の開発指示を Devin に指示をだし
- きりのいいところで Devin の PR をレビューし
- チームメンバーの PR(Devin が一次レビュー後) に追加でコメントし
- 知見、方針、設計などを Cursor と一緒にドキュメントにまとめ
- さらに Cursor と MCP 連携を増やして Agent の対応範囲を増やし
- 新しい Cursor の機能を試しながら
- よりよいモデルにさらにおおくのことをやってもらうのを楽しみにする
正直、開発AIツールがない状態はもう想像できないです。
より大事な部分に注力し、より良い開発ができ、より良い価値を早く届けられるようになっている実感があり、手放すことができなくなっています。
また開発AIツールを使わず、自分がゼロからすべてのコードを書くということは費用対効果が合わなくなってきていると思っています。
そして コードの詳細をほとんど見ない日もそう遠くないと思っています。
クラウドプロバイダーがでてきて生のコンピューティングリソースが(ある程度)隠蔽されたように、AIの発展がコードを隠蔽することになります。
現時点でも
- どの環境で、だれと、どのAIを、どのようにコラボしやすくするか
- どの限られたコード、ドキュメント、設計に自分の時間を投下するか
を設計することのウェイトが大きくなってきていると感じます。
そんな状況で、それでもいま自分でコードを書いたほうがいいと判断できた時は、贅沢な時間を楽しもうと感じるようになりました。
「価値出すスピードを早められる」「開発時も楽しさが増す」というバフがかかりやすい状態なので、この感覚を楽しみつつ、このお祭りのような過渡期を全力でチームメンバー、友人たちを含めみなで楽しんでいきたいなと思います。
Discussion