🧭 はじめに
AIによるコーディング支援が当たり前になりつつある今、開発の進め方そのものが変わり始めています。コード補完やレビュー支援にとどまらず、AIエージェントに一連の開発作業を任せる —— そんな「AI駆動開発」が現実的な選択肢になってきました。
本記事では、AI駆動開発とは何か、そして PLAY TECHNOLOGY が実際にどのような仕組みでAI駆動開発に取り組んでいるのかをご紹介します。
🤖 AI駆動開発とは
AI駆動開発（AI-Driven Development）とは、AIエージェントが開発プロセスの一部、あるいは大部分を主体的に担う開発手法です。従来は「人がコードを書く」ことが中心でしたが、AI駆動開発では人が「何を作るか（仕様・意図）」を定義し、AIが「どう作るか（実装・テスト）」を反復します。そして最後は人がレビューして承認する、という役割分担になります。
| 観点 | 従来の開発 | AI駆動開発 |
|---|---|---|
| 実装 | 人がコードを書く | AIが仕様に沿って実装 |
| テスト | 人が作成・実行 | AIが作成し、反復的に実行 |
| 人の役割 | 実装の中心 | 仕様定義・レビュー・承認 |
| 進め方 | 手作業が中心 | エージェントが自律的に反復 |
重要なのは、AIに丸投げするのではなく、人がゴールと制約を明確に定義し、要所でレビューする ことです。この設計があってこそ、品質とスピードを両立できます。
🛠️ PLAY TECHNOLOGY の AI駆動開発
PLAY TECHNOLOGY では、Issue 管理から実装・レビュー・デプロイまでを一気通貫でつなぐため、次の要素を組み合わせてAI駆動開発を実践しています。
| 要素 | 役割 |
|---|---|
| GitLab | Issue・マージリクエスト（PR）・リポジトリの管理 |
| n8n | ワークフローの自動化（トリガーとオーケストレーション） |
| AIエージェント | 処理の実行主体。n8n上に実装 |
| AIモデル | Deepseek などのモデルをAIエージェントに登録 |
| MCP（gitlab） | AIエージェントが GitLab を操作するための接続 |
| instructions | リポジトリに配置する実装仕様（AIへの指示） |
AI駆動開発の開発フロー。Issueを起点に、n8nとAIエージェントが実装・PR作成までを担います。
ポイントは、AIエージェントにAIモデルとMCP（gitlab）をあらかじめ登録しておく ことです。これにより、エージェントはモデルの推論力と、GitLab を操作する手段の両方を持ち、Issue の内容に応じて自律的に動けます。
🔄 開発フロー
実際の流れは、次のとおりです。起点はあくまで 人が作成する GitLab Issue で、そこから先を自動化しています。
👥 登場人物
| 名称 | 役割 |
|---|---|
| Issue作成者 |
|
| 開発者、テスター |
|
1. GitLab Issue を作成
まず、依頼内容を GitLab の Issue として起票します。何を実現したいのか、背景や制約をここに記載します。
ここが一番重要です。実装させたい機能をできる限り明確な指示を作成します。ただし実装のための指示は不要です。
特に UI に関する指示は細かめに記載したほうがより正確に実装します。
2. Issue 作成をトリガに n8n ワークフローを実行
Issue が作成されると、それをトリガとして n8nのワークフローが起動 します。人手を介さず、次の処理へ自動で進みます。
GitLab には Webhook 連携機能があります。これを使用して n8n の Webhookノードからワークフローを実行します。
3. AIエージェントで処理を実行
n8nに実装した AIエージェント が処理を実行します。エージェントには、あらかじめ AIモデル（Deepseekなど） と MCP（gitlab） が登録済みです。
必要な場合は他の MCP サーバを登録します。
4. プロンプトと instructions で仕様を指示
AIエージェントにはプロンプトを記載します。あわせて、 実装仕様はリポジトリに配置した instructions で指示 します。仕様をコードベースの近くに置くことで、エージェントが文脈を踏まえて判断できます。
ここは通常の AI コーディングと同じとなります。
5. 仕様を考えて、実装とテストを実施
エージェントは instructions とプロンプトをもとに 仕様を検討し、実装とテストを実施 します。実装とテストを反復しながら、要件を満たす状態に仕上げていきます。
n8n の AI エージェントのログを見るとよく分かるのですが、何度も AI モデルとやり取りして、目的のために反復処理を行います。
6. GitLab へ PRを作成・コミットし、通知
完了すると、GitLab へ Issue に紐づいたブランチを作成し、マージリクエスト（PR）を作成し、コミット します。PRの作成を契機に 通知 が飛び、関係者が状況を把握できます。
7. レビューと動作確認
Issue 作成者が PR の内容を確認 し、必要であれば実際に動作確認を行います。ここが人のレビュー工程であり、AIの成果物に対する品質のゲートになります。
UIの実装はまだ完全とは言えないため、VS Code でブランチをチェックアウトして動作確認を行い、微調整を行っていきます。
8. マージして検証サーバへデプロイ
問題なければ、通常の開発フローと同様に Issue作成者がPRを承認・マージ し、検証サーバへデプロイ します。
9. 依頼者が検証サーバで確認
最後に、依頼者が検証サーバで確認 し、問題がなければ Issueを確認（完了） とします。
Issue作成 → n8n → AIエージェント → 実装・テスト → PR → レビュー → マージ → デプロイ
この流れを自動でつなぐことで、人は 「仕様を考えること」 と 「レビューすること」 に集中できます。
💡 AI駆動開発を進めるためのポイント
AI駆動開発を安定して回すために、私たちが重視しているポイントを整理します。
-
仕様を明確に書く
instructions やプロンプトの質が、そのまま成果物の質に直結します。
指示に対する曖昧さを減らし、箇条書きでシンプルに書くことを心がけます。 -
人のレビューを必ず挟む
マージやデプロイの判断は人が行います。AI はあくまで実装を担い、最終的な責任は人が持ちます。
まだすべてをAIエージェントに任せられるわけではありませんが、多くの場合、原因はAIの性能ではなく 指示の曖昧さ にあります。
AIが理解しやすい明確な指示を心がけることで、人の手戻りを大きく減らせます。 -
トレーサビリティを確保する
必ずAIの処理に対してエビデンスを残すようにします。
Issue と PR とデプロイがひも付くため、「何のために、何をしたか」を追いやすくなります。 -
小さく始める
まずは定型作業や小さな改修から適用し、効果とリスクを確認しながら少しずつ範囲を広げていきます。
🔗 関連サービス・関連技術
🤝 おわりに
AI駆動開発は、AIに任せること自体が目的ではありません。人が仕様とレビューに集中し、定型の実装・テストはAIに任せる —— この役割分担によって、開発のスピードと品質を両立できます。
PLAY TECHNOLOGY では、AI駆動開発の仕組みづくりをはじめ、業務の自動化やシステム開発のご支援を行っています。「AIを開発に取り入れたいが、どこから始めればよいか分からない」という段階でも構いません。まずはお気軽にお問い合わせください。
