こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。
AIエージェントを活用し、自然言語による指示を中心にコーディングする手法が注目を集めています。特にゼロからコードを書く場面では、その効果の高さは多くの現場で実感されているのではないでしょうか？
私たちもこの可能性に注目し、AIコードエディター「Cursor」をフルタイムの開発チームメンバー全員に導入。日々の開発でAIエージェントの活用を積極的に進めています。
一方で、既に運用中のサービスを開発しているチームにとっては、既存コードの文脈を理解させた上でどう活用するかが大きなテーマとなります。本記事では、そうした既存コードのコンテキストを踏まえたAI活用の実践について紹介します。
開発チームの前提と課題
私の所属する開発チームはAI議事録ツール「ACES Meet」を開発しています。このプロダクトは数年にわたって積み上げられてきたコードベースがあり、以下のような課題が存在しています。
「今後はこのスタイルで書こう」といった最新ルールは決めているものの、古い実装が残っていることで新しいメンバーが迷ったり、AIが非推奨の実装を参考にしてしまうことがありました。
このような背景から、「AIと人間が同じルールを理解・適用しながら開発する」という共通基盤の必要性が強くなってきたのです。
AIエージェント活用の方向性
以前はGitHub Copilotを使っていましたが、プロンプトに多くの補足や説明を付け加えないと意図通りに動いてくれず、AIにコーディングを任せるには手間が大きい印象でした。
AIコードエディター「Cursor」はリポジトリ全体を事前スキャンし、AIがコードベースの文脈を把握した状態でサジェストや修正を行えるため、期待通りのアウトプットを得やすくなりました。また、特定のファイルを“参照”として明示的に渡せる操作性も非常に優れており、ガードレール付きのAI活用が現実的になりました。
この環境を活かし、私たちは以下の2つを重点的に進めています
- コーディングルールの整備と活用
- 古いコードのリファクタリングをAIエージェントで効率化する
実践①：コーディングルールの整備と活用
最初に取り組んだのは、開発チーム内で使用するコーディングルールの整理と明文化です。私が主に領域とするフロントエンドにおいては、以下のようなルールをまず明文化しました。
コーディングルールの具体例
たとえば、Next.js（App Router構成）で新しいページを追加する場合、以下のようなルールと実装方法定めています。
# Pageの実装方法 ページのエントリーポイントとなるpage.tsxの実装方法について記載します。 ## ディレクトリ構成 app ├── (authed) // 要認証画面 │ ├── initial-settings │ │ ├── page.tsx │ │ ├── styles.module.scss │ │ └── usePage.ts ├── (authless) // 認証不要画面 ├── layout.tsx ## 各ファイルの役割 - `page.tsx` - Mustで必要なエントリーポイントのtsxファイル - `styles.module.scss` - page.tsxにスタイルを当てるためのSCSSファイル - `usePage.ts` - page.tsxで使うuseStateやuseCallbackなどロジックを配置するtsファイル ## 作成手順 例えば、`src/app/(authed)` 配下に新しく`watchlists` というページを新規作成したい場合、以下の手順で実装します。 1. ディレクトリだけをまずは作る 1. `src/app/(authed)/watchlists` 2. このディレクトリの相対パスをコピー 3. ページの雛形実装コマンドを実行 1. `npm run generate:page` 2. 1つ目の質問で `src/app/(authed)/watchlists` をペースト AIエージェントが実行する場合は、バックグラウンド処理を介さないよう以下の手順で実行してください。 1. ディレクトリだけをまずは作る 1. `src/app/(authed)/watchlists` 2. ページの雛形実装コマンドを実行 1. `npm run generate:page:ai --path="src/app/(authed)/watchlists"`
フロントエンドではscaffdogというライブラリを使っており、ページの雛形を1コマンドで生成できるようにしています。
このようなドキュメントをAIに渡すことで、「ルールに沿ってこの箇所を書き換えてください」といった明確な指示が可能になり、AIの出力の一貫性を高めることができます。また、scaffdogコマンドの実行で作成される雛形がガードレールとなり、不要なファイル分割を回避することができます。
実践②：古いコードのリファクタリングをAIエージェントで効率化する
コーディングルールを整備した後は、人間もAIもミスリードの原因となる古いコードを、最新のコーディングルールに基づいて修正させる取り組みを進めました。
従来であれば「リファクタリング週間」などの名目で人手によって地道に修正していた作業を、AIエージェントを使って継続的かつ効率的に行えるようになりました。
私はよく以下のステップでリファクタリングしています。
- まず「何をどのように修正するのか？」というゴールとステップを明確にする
- AIエージェントにコーディングルールを渡しつつ、1ステップずつ期待結果を出力できるか確認する
- 期待通りでない場合は、プロンプトをチューニングする
- 成功した修正指示をテンプレート化し、1箇所を一気通貫で修正させる
- 修正対象を範囲指定し、一括でリファクタリングさせる
プロンプトの具体例
以前は、__tests__ディレクトリに分離してテストを書くルールでしたが、コードジャンプが必要で実装とテストの行き来が面倒といった課題がありました。最新のルールでは、xxx.test.ts のように実装と同じ階層に置くように変更しました。ですが新メンバーやAIが古いルールに倣ってしまうケースがあり、最新のルールに全実装を揃えたいと考えていました。
最終的なプロンプトは以下のようになります。
ユニットテストを実装と同階層に配置するリファクタリングを行います。 まず私に移動対象のディレクトリを質問してください。 そのディレクトリに複数のテストファイルがある場合は、1ファイルずつ下記のステップをすべて実行し、完了後に次のファイルに進んでください。 1. ユニットテストが対象とする実装をsrc/xxx/yyyから探してください 2. @unit-test.mdを参考に、実装と同階層に移行してください 3. 実装ファイルとテストファイルの両方のimportの定義を、@import.mdを参考に修正してください 4. `npm run typecheck` を実行し、エラーしないことを確認してください 5. 移動したユニットテストを実行しテストが通ることを確認してください 6. `npm run check` でフォーマット後、Gitでコミットしてください
ポイントはコーディングルールのドキュメントを参照させることで、プロンプトの具体記述を省けることです。指示実行後はしばらく放置し、適当なところでPR作成 → レビューすれば完了です。Cursorは通常の課金では25 Callで止まってしまうため、プロンプトが組み上がった後は従量課金でひたすら実行し続けるタイプと相性が良いと思います。
また、途中で静的解析やLint/Formatを挟むことでミスがある場合はAIエージェント自身が修正を試みます。細かく挟む際には、BiomeやVitestのように高速に実行できるツールを選定しておくと効率的です。
このようにして、AIに“回し続けるリファクタリング”を任せ、人間はレビューと承認に集中するという体制を整えました。
AI導入の成果と今後の展望
こうした取り組みを通じて、開発体制に以下のような変化が生まれました。
- コーディングルールというガードレールを軸に、AIと人が同じルールを守れる状態に
- タイミングを選ぶ必要があった古いコード修正を、気軽に一括でリファクタリング可能に
- AIにコードベースのコンテキストを踏まえて、狙った出力をさせるナレッジが蓄積
AIが守りやすいルールは同時に人間も守りやすいため、これまで新しいメンバーが入るたびに、「どこを参考にすればわからない」という課題が解決に向かいました。 また、リファクタリングのほとんどはAIに任せることができるため、従来の「リファクタリング週間」などは新しい技術や開発手法を試す、といった別の時間に充てることができます。
今後はここまでのナレッジを活かして、以下の3点に注力していきます：
- 新機能開発の最適化：仕様書＋ルールをAIに与えて、期待通りの新実装を生成するプロセスを確立
- ルールとドキュメントのアップデートの自動化：AIにとって理解しやすい構造・命名に合わせて、ルール自体も最適化し、更新もAIに任せていく
- 他領域への展開：フロントエンドで得た知見をバックエンドやその他の開発領域にも水平展開
まとめ
ここまで、既存コードのコンテキストが複雑に混在する現場で、AIエージェントを活用した開発効率化の取り組みをご紹介しました。日進月歩でAIエージェントも進化するため、ご紹介した内容ももう古いかもしれません。
テックリードだけでなく、現場のエンジニア1人1人が日々活用方法を試しながらチームに展開することが重要と考えていますし、そこにきちんとコストを投下できる環境です。ACES Meetの開発チームだけでなく、全事業部のエンジニアへのCursor配布や、全社エンジニア横断でAI活用LT会なども行っています！
本記事を通じてACES Meetの開発チームにご興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！
ACESの採用情報はこちら↓
