私は現在所属しているプロジェクトにてアプリエンジニアとしてコードを書きながら、プロジェクトリーダーとしてエンジニアチームをまとめる役割を担っています。
最近は、Claude CodeをはじめとしたAIエージェントが台頭してきたこともあり、エンジニアの業務の在り方が大きく変わりつつあります。私が所属しているプロジェクトも、その渦中にある一つです。
業務にAIエージェントを導入した当初、プロジェクトにおける用途は、逐一プロンプトを書いてコードの実装を行うだけに留まっていました。ですが、時が経つにつれて用途はどんどん広がっていき、現在は、顧客からの問い合わせに対する調査作業や画面デザインの作成/修正、ドキュメントの作成までAIエージェントを使用して行うようになりました。AI駆動開発にも現在進行形で挑戦中です。
この記事では、プロンプトを書いてコードの実装を行うだけだった時期から現在に至るまでに行ってきた施策を紹介します。
まず、前提条件として現在所属しているプロジェクトで使用しているツールについて紹介します。
お客様からの後押しもあり、MCPサーバーやAIエージェントを積極的に使用しています。
プロジェクトではアジャイル開発を採用しており、Confluence上にユーザーストーリーが管理されています。
リポジトリに関しては、フロントエンド/バックエンド/インフラのマルチレポ構成を採用しています。
当社内でClaude Codeが導入されてしばらくは、プロンプトですべて指示を入力していました。
手入力で実装を行うより多少作業スピードは速くなりましたが、劇的に速くなったということはなく、作業品質にも多少の不安がありました。
Claude Codeを利用した開発作業を始めてからしばらくすると、SkillsやRulesといった技術が登場しました。そういうものがあるということは知っていたものの、日々の開発タスクに追われ、なかなか時間を確保できず、導入に踏み切るまでには多少のラグがありました。
そんな中、社内ではAI駆動開発をやろう！という機運が高まってきており、AIエージェントを利用した開発に関する情報を発信する方が出始めました。
そのこともあり、とりあえず流行りに乗ってSkillsとRulesを導入してみることとしました。
まずは、日々の作業の中で発生頻度が高く、かつ手順がある程度決まっているものからスキルの導入を進めました。
フロントエンド・バックエンドの両リポジトリに、作業ブランチの変更をレビューしてPRを作成するスキルと、Confluence上の要件とFigmaのデザインを分析してJiraの親チケット配下にサブタスクを起票するスキルの2つを追加したのが最初です。
その後、社内で整備されていた共通のスキルセットをそれぞれのリポジトリに適用し、一気に11個まで拡充しました。
このタイミングで、チケットの起票 → 実装 → PR作成 → レビュー → 指摘対応という開発サイクルの一連の流れが、スキルによって一通りカバーされた状態になりました。
スキルの拡充と前後して、Rulesも導入しました。
それまでは、コーディング規約や実装時の注意事項をすべてCLAUDE.mdに箇条書きで列挙していました。ですが、この形式では、AIに依頼している作業に関係のない情報も常に読み込まれるため、コンテキストを多く消費してしまっていました。
そこで、CLAUDE.mdに書いていた内容を .claude/rules/ 配下のファイルに分割して移設しました。各ルールファイルの先頭には globs(対象ファイルのパターン)や paths を指定し、必要なルールだけを読み込むようにしました。
きっかけは、それまで別のメンバーが担当していたFigmaデザインの修正を自身が行った際に、相当の時間を要したことです。
私自身、Figmaを扱った経験はあまりなかったためデザイン作業でかなり苦戦しました。数回作業をしてみて、この作業を何回も行うのはしんどいと感じ、スキル化することに決めました。
Figma関連のスキルでは、以下の2つのMCPサーバーを採用しました。
作成したスキルは以下の3つです。
/figma-create-instructions：ユーザーストーリーを参照し、現状のFigmaと照合した上で、デザイン編集用の指示書を生成するスキル。/figma-create-section：/figma-create-instructions で作成した指示書に基づいて、Figmaに新規追加の画面デザインを作成するスキル。/figma-edit-section：/figma-create-instructions で作成した指示書に基づいて、既存画面デザインを修正するスキル。指示書に記載されたFigmaリンクからデザインの編集を行う。また、上記のスキルで作成したデザインの微調整を行う際には、Figmaが公式に提供している /figma-use スキルを利用しています。
導入した結果、かなりデザイン作業が楽になりました。作業時間を実測していないので、感覚値にはなってしまいますが、デザインに費やす時間は従来の3～5割程度で済むようになりました。
個人的にはこのデザイン作業のスキル化は成功でした。
直近、運用中のシングルテナントアプリケーションとは別の環境を構築し、マルチテナントアプリケーションに改修したものを稼働させようという計画が進行しています。
マルチテナントアプリケーション化に際しては、既存の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の例でした。
現在、私はループエンジニアリング(※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 敵対的レビュー: 成果物の作成者以外の検証者が「この成果物には問題がある」ことを前提に検証を行うこと。