2026年10月08日

AI駆動開発導入の記録

MCP, AIエージェント, TDD, Claude Code, AI駆動開発

はじめに

私は現在所属しているプロジェクトにてアプリエンジニアとしてコードを書きながら、プロジェクトリーダーとしてエンジニアチームをまとめる役割を担っています。

最近は、Claude CodeをはじめとしたAIエージェントが台頭してきたこともあり、エンジニアの業務の在り方が大きく変わりつつあります。私が所属しているプロジェクトも、その渦中にある一つです。

業務にAIエージェントを導入した当初、プロジェクトにおける用途は、逐一プロンプトを書いてコードの実装を行うだけに留まっていました。ですが、時が経つにつれて用途はどんどん広がっていき、現在は、顧客からの問い合わせに対する調査作業や画面デザインの作成/修正、ドキュメントの作成までAIエージェントを使用して行うようになりました。AI駆動開発にも現在進行形で挑戦中です。

この記事では、プロンプトを書いてコードの実装を行うだけだった時期から現在に至るまでに行ってきた施策を紹介します。

使用しているツール

まず、前提条件として現在所属しているプロジェクトで使用しているツールについて紹介します。

バージョン管理：GitHub
タスク管理：Jira
ドキュメント管理：Confluence
デザイン：Figma
エディタ・統合開発環境：メンバーによって様々
- VSCode、LazyVim、Obsidianなどなど...
CLIツール：GitHub CLI、Atlassian CLI、AWS CLI
MCPサーバー：Atlassian MCP、Figma MCP
AIエージェント：Claude Code
プルリクエストの自動コードレビュー：Greptile

お客様からの後押しもあり、MCPサーバーやAIエージェントを積極的に使用しています。

プロジェクトではアジャイル開発を採用しており、Confluence上にユーザーストーリーが管理されています。

リポジトリに関しては、フロントエンド/バックエンド/インフラのマルチレポ構成を採用しています。

フェーズ1: プロンプトでの逐一指示

当社内でClaude Codeが導入されてしばらくは、プロンプトですべて指示を入力していました。

手入力で実装を行うより多少作業スピードは速くなりましたが、劇的に速くなったということはなく、作業品質にも多少の不安がありました。

フェーズ2: とりあえずSkillsとRulesを導入

Claude Codeを利用した開発作業を始めてからしばらくすると、SkillsやRulesといった技術が登場しました。そういうものがあるということは知っていたものの、日々の開発タスクに追われ、なかなか時間を確保できず、導入に踏み切るまでには多少のラグがありました。

そんな中、社内ではAI駆動開発をやろう！という機運が高まってきており、AIエージェントを利用した開発に関する情報を発信する方が出始めました。

そのこともあり、とりあえず流行りに乗ってSkillsとRulesを導入してみることとしました。

Skillsの導入

まずは、日々の作業の中で発生頻度が高く、かつ手順がある程度決まっているものからスキルの導入を進めました。

フロントエンド・バックエンドの両リポジトリに、作業ブランチの変更をレビューしてPRを作成するスキルと、Confluence上の要件とFigmaのデザインを分析してJiraの親チケット配下にサブタスクを起票するスキルの2つを追加したのが最初です。

その後、社内で整備されていた共通のスキルセットをそれぞれのリポジトリに適用し、一気に11個まで拡充しました。

このタイミングで、チケットの起票 → 実装 → PR作成 → レビュー → 指摘対応という開発サイクルの一連の流れが、スキルによって一通りカバーされた状態になりました。

Rulesの導入

スキルの拡充と前後して、Rulesも導入しました。

それまでは、コーディング規約や実装時の注意事項をすべてCLAUDE.mdに箇条書きで列挙していました。ですが、この形式では、AIに依頼している作業に関係のない情報も常に読み込まれるため、コンテキストを多く消費してしまっていました。

そこで、CLAUDE.mdに書いていた内容を .claude/rules/ 配下のファイルに分割して移設しました。各ルールファイルの先頭には globs(対象ファイルのパターン)や paths を指定し、必要なルールだけを読み込むようにしました。

フロントエンド：コーディング原則・コーディングスタイル・Reactベストプラクティスなど14ファイル
バックエンド：アーキテクチャ・コード設計原則・PHPコーディング規約など10ファイル

フェーズ3: コードを書くこと以外もAI駆動に

Figmaを用いたデザイン作業のAI駆動化

きっかけは、それまで別のメンバーが担当していたFigmaデザインの修正を自身が行った際に、相当の時間を要したことです。

私自身、Figmaを扱った経験はあまりなかったためデザイン作業でかなり苦戦しました。数回作業をしてみて、この作業を何回も行うのはしんどいと感じ、スキル化することに決めました。

Figma関連のスキルでは、以下の2つのMCPサーバーを採用しました。

Figmaの操作: Figmaが提供しているMCPサーバー
ユーザーストーリーの読み込み: Atlassian MCP

作成したスキルは以下の3つです。

/figma-create-instructions：ユーザーストーリーを参照し、現状のFigmaと照合した上で、デザイン編集用の指示書を生成するスキル。
/figma-create-section：/figma-create-instructions で作成した指示書に基づいて、Figmaに新規追加の画面デザインを作成するスキル。
/figma-edit-section：/figma-create-instructions で作成した指示書に基づいて、既存画面デザインを修正するスキル。指示書に記載されたFigmaリンクからデザインの編集を行う。

また、上記のスキルで作成したデザインの微調整を行う際には、Figmaが公式に提供している /figma-use スキルを利用しています。

Figma skills for MCP

導入した結果、かなりデザイン作業が楽になりました。作業時間を実測していないので、感覚値にはなってしまいますが、デザインに費やす時間は従来の3～5割程度で済むようになりました。

個人的にはこのデザイン作業のスキル化は成功でした。

フェーズ4: シングルテナントアプリケーションからマルチテナントアプリケーションへの移行をAI駆動開発で

直近、運用中のシングルテナントアプリケーションとは別の環境を構築し、マルチテナントアプリケーションに改修したものを稼働させようという計画が進行しています。

マルチテナントアプリケーション化に際しては、既存のAPIに対して同じような修正を入れていくケースが大半でした。そのため、プログラム修正前にマルチテナント化のためのRulesを作成し、AIに読ませることにしました。

最初にRulesで方針を決めておくことで、AIが行う修正作業の品質を一定にすることに加えて、(人間の)レビュアーへ「以降、こちらの内容で順次修正を行います」という方針を共有できました。

---
globs:
  - app/*/Http/Controllers/**/*.php
  - app/*/Http/Requests/**/*.php
  - app/Models/*.php
  - routes/**/*.php
  - database/migrations/**/*.php
---

# マルチテナント実装規約

## 1. クロステナントチェック（ミドルウェア）

...

## 2. コントローラーでのテナントID取得

...

## 3. ...

## 8. テスト

...
- クロステナントアクセス拒否のテストを必ず追加すること（他テナントのリソースIDを使用した場合に 404 が返ることを確認）

```php
// ✅ クロステナントアクセス拒否テストの例
#[Test]
public function checking_update_returns_404_when_belongs_to_other_tenant(): void
{
  ...
}
```

AIのためだけではなく、人間のためにも使えたRulesの例でした。

フェーズ5(現在): サブエージェントを用いた作業のAI駆動化、ループの設計

現在、私はループエンジニアリング(※1)の実践に向けて、スキル群の見直しを実施しています。

フェーズ2・3の施策を導入してから数か月が経過し、ハーネスエンジニアリング(※2)の運用がだいぶ根付きました。TDDを使った実装を行っていることもあり、目立つようなデグレはなく品質は安定しました。開発スピードは格段に上がりました。これまでであれば、長ければ数日を要すこともあったバグ修正の大半が、1日あれば初回のプルリクエスト作成まではできるようになりました。

一方で、私自身はプロジェクト内におけるプログラミング以外の作業やプロジェクト外の作業も徐々に増えており、プログラムを書く時間が減っていたため、思うようなパフォーマンスが出せずにいました。

そこで、私はハーネスエンジニアリングからもう一歩踏み込み、プロンプトを入力する回数を減らせるような開発フローを整えることとしました。プログラミング作業をもっとAIに任せることで、開発に対するパフォーマンスを上げつつ、それ以外の作業にももっと重心を置きたいというのが狙いです。

概要

現時点で整備しているバックエンドの開発フローは以下の通りです。

/loop-planning STAR-XXXX      実装計画の作成 → 実装計画レビューループ
      ↓ docs/plan/YYYYMMDD_STAR-XXXX_<タイトル>.md
/implement-issue STAR-XXXX    テスト計画 → テスト計画レビューループ → TDD実装 → コードレビューループ
      ↓ docs/test-plan/YYYYMMDD_STAR-XXXX_<タイトル>.md ＋ 実装コード
/create-pr                    PRの作成

上記開発フローでは、タスクの実行者・検証者をそれぞれサブエージェントとして用意しました。「成果物を作成する」「レビューする」「指摘を反映する」「再レビューする」という作業は、これらのサブエージェントが担当します。

実装計画・テスト計画・プログラム実装の各工程の検証者は、敵対的レビュー(※3)を行うよう設計しており、最低限の品質担保に役立っています。

ユーザーが直接起動する3つのスキルのうち、/implement-issue スキルが最も長い工程を担当しており、テスト計画では /loop-test-plan スキルが、実装後のコードレビューでは /loop-code-review スキルが動いています。

今後の展望

現状、プロンプトでコマンドを入力してスキルを起動していますが、今後は実装計画・テスト計画・実装・PR作成の4工程を自動で実行する仕組みを構築する予定です。

おわりに

今回は、プロンプトを書いてコードの実装を行うだけだった時期から現在に至るまでに行ってきた施策を紹介してきました。

AI駆動開発を導入した当初は、思ったほどAIを使うことの効果を感じられませんでしたが、今では品質を保ちつつ開発スピードを向上させることで、お客様により多くの成果をお届けできています。

ハーネスエンジニアリング、ループエンジニアリングが可能な開発環境を整えていくには、それなりに時間はかかりますが、かけた時間に応じた十分なリターンが得られると思っています。AI駆動開発、ぜひ試してみてください。

注釈

※1 ループエンジニアリング: AIエージェントに指示を出す仕組みを設計する開発手法。

※2 ハーネスエンジニアリング: AIエージェントが動作する環境を設計する開発手法。

※3 敵対的レビュー: 成果物の作成者以外の検証者が「この成果物には問題がある」ことを前提に検証を行うこと。

アジアクエスト株式会社では一緒に働いていただける方を募集しています。
興味のある方は以下のURLを御覧ください。

AI駆動開発導入の記録

目次

はじめに

使用しているツール

フェーズ1: プロンプトでの逐一指示