PONOS Advent Calendar 2025 23日目の記事です。
前回は@mon3612さんのドット絵を描きながらゲーム開発ができる Game Maker が楽しいでした。
はじめに
近年、AI搭載型コードエディタの進化は目覚ましく、その中でもCursorはエンジニアの生産性を劇的に向上させるツールとして確固たる地位を築いています。本記事では、一人のエンジニアとしてCursorをどのように実業務に組み込み、どのような恩恵を受けているか、具体的なユースケースを交えて解説します。
Cursorについて
CursorはVS Codeをフォークして開発されたAIエディタであり、IDEそのものがLLM（大規模言語モデル）と深く統合されている点が最大の特徴です。
IDEというとエンジニア・プログラマー専用のツールに聞こえてしまいますが、Cursorはざっくり言ってしまうと 「AI付きのメモ帳」 です。
そのため、案だしの壁打ちなどにも使用できるため、エンジニア・プログラマー問わず、幅広い職種の方が利用できます。
Cursorのメリット・好きなところ
-
コンテキスト理解の深さ:
@Codebaseを用いたリポジトリ全体のインデックス化により、ファイル間の依存関係を考慮した回答が得られる点。 - シームレスな体験: チャット、インライン編集、ターミナルが一体化しており、コンテキストスイッチのコストが極めて低い点。
- アップデートの速さ: Composer機能やMCP（Model Context Protocol）対応など、最新のAI技術が迅速に実用レベルで実装される開発スピード。
また、各社のLLMは既にモデルその物の差別化がされづらくなっており、価格競争が始まっていることかと思います。
CursorはAIエディタであるため、その競争とは別の場所で戦えているところに感心します。
※もちろんLLMの利用価格が値上がったり、使用できるリソースが減少してくると大打撃を受けそうですが・・。
業務活用その1 コーディング
もっとも基本でありながら、もっとも強力な活用法です。
1. コーディングの加速
単なる補完ではなく、関数全体の生成や、複雑なリファクタリングを概ね意図通りに実行してくれます。
既存のコード設計があれば、コンテキストとして与えることで準拠させることが可能です。
各LLMで出力されるコードにも違いがあるため、実装に迷った時は後述のマルチエージェント機能で比較検討することも可能です。
2. 仕様駆動開発（SDD）による要件定義・設計
成長中のドメインに新機能を追加する時に役立ちます。
リポジトリのdocsディレクトリ配下にそれぞれ以下のmdファイルを作成します。
- requirements.md: 要件定義書
- design.md: 設計書
- tasks.md: 実装計画書
各作成フェーズでは、必ず人間の目でレビューが必要となります。
作成後は、実装計画書の内容に沿ってLLMに実装を任せます。
小さなウォータフォール開発が繰り返し行われるイメージです。
実装計画書の作成時に、アジャイル・スクラムを意識したユーザーストーリーとしてタスクを分解すると、プロジェクトごとの開発手法に当てはめることも可能かと思います。
効果: 実装の漏れを防ぎ、設計意図とコードの乖離を最小限に抑えることが可能です。
3. コードレビューの実施
Pull Requestを出す前に、ローカルでCursorにレビューを依頼します。
私はカスタムコマンドでcode-review.mdを作成し、定義しています。
ただしLLMは延々と指摘をしてくる場合があります。
そのため、修正可否の判断は人間がする必要があります。
code-reviewコマンドの中身
## レビュー実行
上記でベースブランチと現在のブランチを確認した後、AIに以下を依頼：
- [ベースブランチ]と[現在のブランチ]のdiffを取得する
- 差分があるファイルを一覧出力する
- 以下のコードレビューチェックリストを使って、コードレビューを実施する
- **必須： コードレビューは現在の差分に対してのみ実施すること。変更がない既存の処理に対してはコードのレビューは実施しない**
- 修正するべきコードがある場合、具体的な修正案を修正前のコードと比較して知りたい
---
# プログラミング原則に基づくコードレビューチェックリスト
## 概要
プログラミングの基本原則に基づき、コードの品質、保守性、拡張性を網羅的かつ体系的に確保するためのコードレビューチェックリストです。
## レビューカテゴリ
### 1. 設計原則 (SOLID原則)
- **[ ] 単一責任の原則 (SRP):** クラスやモジュールは、単一の責任（目的）に集中しているか？
- **[ ] 関心の分離 (SoC):** ビジネスロジック、UI、データアクセスなどが適切に分離されているか？
- **[ ] 開放/閉鎖の原則 (OCP):** 新機能の追加や仕様変更の際に、既存コードの修正を最小限に抑えられる設計か？
- **[ ] リスコフの置換原則 (LSP):** サブクラスは親クラスの振る舞いを壊さずに置換可能か？
- **[ ] インターフェース分離の原則 (ISP):** クラスは、自身が利用しないメソッドを持つインターフェースに依存していないか？
- **[ ] 依存性逆転の原則 (DIP):** 具象クラスではなく、抽象（インターフェースや抽象クラス）に依存しているか？（依存性注入が適切か？）
### 2. シンプルさと重複排除 (KISS, YAGNI, DRY)
- **[ ] シンプルさ (KISS):** コードは不必要に複雑になっていないか？よりシンプルな解決策は存在しないか？
- **[ ] YAGNI原則:** 現時点で必要とされていない機能（過剰な設計）が実装されていないか？
- **[ ] 重複の排除 (DRY):** コードの重複（コピー＆ペースト）はないか？再利用可能な形に抽象化されているか？
- **[ ] マジックナンバー:** 設定値やマジックナンバーなどがハードコードされず、一元管理されているか？
### 3. 読みやすさ (Readability)
- **[ ] 命名:** 変数名、関数名、クラス名は具体的で分かりやすく、誤解を招く可能性がないか？（プロジェクトの規約遵守を含む）
- **[ ] 明瞭性:** 制御フローのネストは深すぎないか？（ガード節の活用など）条件式やループは脳内で変換不要なほど単純か？
- **[ ] 意図の表現:** 巨大な式は、意図を説明する変数（説明変数）を使って分割されているか？
- **[ ] 凝集度:** 関連するコードは近くにまとめられ、ファイル内の縦の距離が意識されているか？変数のスコープは最小限か？
### 4. テスト (Testing)
- **[ ] テストの有無:** 機能追加や修正に伴い、適切なテスト（ユニット、結合）が追加・更新されているか？
- **[ ] カバレッジ:** テストは正常系だけでなく、エッジケースや異常系もカバーしているか？
- **[ ] 正確性:** テストコード自体にロジックの問題や誤りはないか？
### 5. パフォーマンス (Performance)
- **[ ] 計算量:** ループやアルゴリズムが非効率的で、不必要な計算量になっていないか？
- **[ ] クエリ効率:** データベースアクセスにおいて、N+1問題や非効率なクエリが発生していないか？
- **[ ] リソース管理:** メモリリークや不要なリソースの専有がないか？
### 6. セキュリティ (Security)
- **[ ] 入力値の検証:** 外部からの入力（ユーザー入力、APIレスポンス等）は適切に検証・サニタイズされているか？
- **[ ] 機密情報の扱い:** パスワードやAPIキーなどの機密情報が、ログやコード中にハードコードされていないか？
- **[ ] 脆弱性:** 一般的な脆弱性（XSS, CSRF, SQLインジェクション等）に対する対策が講じられているか？
### 7. ドキュメンテーションとコメント (Documentation)
- **[ ] コメントの質:** コードから自明なこと（WHAT）ではなく、コードの背景や意図（WHY）がコメントされているか？
- **[ ] 陳腐化の防止:** 古くなったり、誤った情報を伝えたりするコメントは残っていないか？
- **[ ] 関連ドキュメント:** READMEやAPI仕様書など、関連するドキュメントの更新は必要ないか？
### 8. 全般的な品質 (General Quality)
- **[ ] エラーハンドリング:** 想定されるエラーが適切に捕捉され、堅牢なエラー処理が行われているか？
- **[ ] 依存関係管理:** 新たな外部ライブラリの追加は適切か？不要な依存関係は含まれていないか？
- **[ ] コーディング規約:** プロジェクトで定められたコーディング規約やスタイルガイドに従っているか？
---
## 結果の保存
レビュー結果はチャットへの出力に加え、必ず以下のパスにMarkdownファイルとして保存してください。
**必須： ユーザーからの指示がない限り、mdファイルは新規作成してください。**
- **保存先ディレクトリ:** `docs/reviews/` （存在しない場合は作成すること）
- **ファイル名:** `YYYY-MM-DD-code-review.md` （日付は日本時間の実行日）
- **内容:** 上記チェックリストおよび修正案を含む完全なレポート
業務活用その2 アジェンダ、議事録の作成
ドキュメント作成もCursor上で完結させます。
- アジェンダ作成: 実装予定のコードや既存の設計ドキュメントを参照し、技術会議のアジェンダを自動生成。
-
議事録: 箇条書きのメモから、決定事項、保留事項、Next Actionを構造化したドキュメントへ整形。
テキストエディタとしての基本性能が高いため、Markdownでの文書作成効率が非常に高いです。
それぞれカスタムコマンドで定義しています。
カスタムコマンドの内容にmdファイルを出力する際のフォーマットも定義しておくと、出力の内容にブレが生じません。
業務活用その3 ConfluenceにMCPでページを作成・参照
CursorはMCP (Model Context Protocol) をサポートしています。
これにより外部ツールとの連携が飛躍的に容易になります。
- 連携: MCPサーバーを介してConfluence APIと接続。
- 利点: エディタから離れることなく、既存の社内ドキュメントを「参照」しながらコードを書き、逆に実装内容を「仕様書としてConfluenceに書き出す」ことが可能です。情報の分断を防ぐ強力な武器になります。
現在は、atlassianのmcpがベータ版であることと、既存プロジェクトのドキュメントに破壊的変更を加えないために自身のスペースに限定的にページを作成しています。
少し手間ですが、その時点でConfluenceのフォーマットに則ったページになるため、他の箇所に手作業でコピーすることも可能です。
※Confluenceのmarkdownフォーマットは、cursorで作成できるmarkdownファイルとフォーマットが違い、そのままCursorの内容をコピペしても壊れます。統一してほしい・・・。
業務活用その4 課題解決案の壁打ち
技術選定やバグの原因調査において、優れた「思考のパートナー」となります。
やりたいことを雑多にmdファイルに書き出し、todoに落とし込んでいくプロセスで使用することもできます。
その際、リポジトリ内にメモがコンテキストとして貯まっていくため、自分自身では気づくことのできなかった点に気づいてくれたりします。
- メリット: 「A案とB案、どちらが今回のインフラ構成においてコスト効率が良いか？」といった多角的な議論が可能。
- 注意点: AIの回答が常に最新のクラウド仕様を反映しているとは限らないため、最終的な決定には公式ドキュメントの参照が不可欠です。
業務活用その5 リバースエンジニアリング
もっとも困難な「複雑なドメイン知識の理解」に威力を発揮します。
- 手法: 数千行に及ぶドキュメント不足のレガシーコードを読み込ませ、データフローやビジネスロジックの図解（Mermaid形式など）を生成させます。
- 結果: コードの背後にある意図を素早くキャッチアップでき、保守・リプレイスの工数を大幅に削減できます。
現在、私は扱えるメンバーが属人的になっていた社内ツールの新規改修に取り組んでいます。
その際、インプットとアウトプットのフォーマットを変更しない方針を取るために、既存ツールのリバースエンジニアリングをCursorで行い、複雑なドメイン知識のキャッチアップを迅速に行うことができました。
付録：Cursorを使いこなすための機能
1. Docs機能
任意のライブラリの公式ドキュメント（URL）を学習させる機能です。最新バージョンのAPI仕様に基づいた正確なコード生成に必須です。
2. カスタムスラッシュコマンド
よく使うプロンプト（例：/test で単体テスト生成）を登録し、定型作業を高速化します。
3. マルチエージェント機能
複数のモデルの特性を活かし、複雑なタスクを段階的に解かせることで、精度の高い成果物を得られます。
最近では、1つのプロンプトを並行で複数のLLMに投げ、回答を得る機能も追加されています。
4. ユーザールール (.cursorrules)
プロジェクト独自のコーディング規約や禁止事項を記述しておくことで、AIが常にプロジェクトの文脈に沿った回答をするように矯正できます。
おわりに
いかがでしたでしょうか？
今やCursorは、私の業務に欠かせないツールとなっています。
特にコンテキスト理解の深さが他を寄せ付けないほどに強力であると感じています。
繰り返しになりますがCursorは 「AI付きのメモ帳」 なので、幅広い職種の方が利用できます。
Cursorに興味を持った方がいればぜひご連絡ください。
ぜひCursorライフを一緒に楽しみましょう！
明日は@Portierさんの記事です。