AIエージェント時代の開発手法：AI駆動開発の考え方と実践ポイント

本記事では、AIを単なるコード補完ツールとしてではなく、開発プロセス全体に継続的に参加する「開発エージェント」として活用する開発手法を「AI駆動開発」と定義します。対象となるのは実装だけではなく、設計、テスト、レビュー、運用を含むソフトウェア開発ライフサイクル全体です。

AI駆動開発に対する期待

AI駆動開発に期待されているのは、単にコードを書く時間を短縮することだけではありません。企画、設計、実装、テスト、レビュー、運用といった開発ライフサイクル全体にAIを組み込み、開発の進め方そのものを変えていくことにあります。

従来のAIコーディング支援は、コード補完や関数生成など、エンジニアの作業を部分的に助けるものが中心でした。しかし近年は、AIがコードベースを読み取り、タスクの分解、実装、テスト実行、エラー調査、修正提案までを一連の流れとして担えるようになりつつあります。これにより、AIは単なる「補助ツール」ではなく、「共同開発パートナー」あるいは「自律的なチームメイト」として位置づけられ始めています。

特に期待されているのは、開発速度の向上だけでなく、属人化の解消や品質の標準化です。たとえば、障害対応や既存コードの調査のように、経験者の勘や暗黙知に依存しやすい作業でも、AIがログやコードを横断的に分析することで、対応プロセスを一定の品質で再現しやすくなります。

2024年以降、GitHub CopilotやCursorなどのAIコーディングツールが急速に普及しました。そして2025〜2026年にかけて、CLIベースのAIエージェントも台頭し、開発の進め方そのものが変わり始めています。これは、開発現場におけるAI活用が「AIに相談する」段階から「AIに仕事を渡す」段階へ進みつつあることを示しています。

つまりAI駆動開発とは、AIにコードを書かせる取り組みではなく、AIが安全かつ継続的に成果を出せるように、開発プロセスやチームの働き方を再設計する取り組みだといえます。

AI駆動開発の開発スタイル

AI駆動開発には、目的やAIに任せる範囲に応じていくつかの開発スタイルがあります。ここでは代表的なアプローチとして、Vibe Coding、Spec駆動開発、Agentic Codingを取り上げます。

Vibe Coding

「指示 → AIが生成 → レビュー → 修正」というシンプルなサイクルで進めるスタイルです。自然言語で要望を伝えるだけでコードを高速に生成できるため、プロトタイピングや小規模機能の実装では高い効果を発揮します。

一方で、仕様や設計の前提が十分に整理されていない場合、AIの出力が場当たり的になりやすく、長期運用では手戻りや整合性の維持が課題になることがあります。そのため、コード生成そのものよりも、「AIに何を伝えるか」「どの観点でレビューするか」といったコミュニケーション設計が重要になります。

Vibe Codingは「まず動かす」ことに強い一方、「継続的に保守する」ためには設計やルール整備を別途補強する必要があります。

Spec-Driven Development（Spec駆動開発）

仕様書や要件定義を起点に、AIに実装・テスト・ドキュメント生成を行わせるスタイルです。実装前に期待する振る舞いや制約を明文化するため、生成結果のぶれを抑えやすく、チームでの合意形成にも向いています。KiroのようなSpec駆動型のツールと相性がよいアプローチです。

Agentic Coding

AIエージェントにタスクの分解、実装、テスト、エラー調査、修正までを連続的に任せるスタイルです。単発のコード生成ではなく、AIがリポジトリ全体を読み取りながら自律的に作業を進める点に特徴があります。

たとえば、Issueや障害ログを起点に関連ファイルを調査し、原因を推定したうえで修正方針を立て、コードを編集し、テストやビルドを実行します。失敗した場合はエラーメッセージを読み取り、原因を再調査して追加修正を行い、最終的に変更内容や確認結果をまとめます。人間はすべての作業手順を細かく指示するのではなく、目的、制約、レビュー観点を与え、AIの実行結果を確認する役割に移っていきます。

このスタイルでは「段取りの工数」まで削減できるため、開発全体に与える効果は大きくなります。一方で、AIが自律的に動く範囲が広がるため、権限管理、テスト、レビュー、ロールバック手順などをあらかじめ整えておくことが重要です。

この3つは同じ軸で並ぶ排他的な分類ではありません。Vibe CodingとSpec駆動開発は、AIに渡す入力をどれだけ明文化するかという観点の違いです。一方、Agentic Codingは、AIエージェントがどれだけ自律的に作業を進めるかという実行形態の違いです。実際の開発では、状況に応じてこれらを組み合わせて利用します。

主要AI開発サービスの紹介

主要サービス比較

2025〜2026年にかけて、主要なAIコーディングツールは、AIエージェントによる自律的なコード生成・編集・テスト実行へ対応を広げつつあります。サービスごとの違いは、主にインターフェース、得意な開発スタイル、既存エコシステムとの統合にあります。

実際の開発現場では、単一のサービスに絞るのではなく、用途に応じて複数サービスを使い分けるケースも増えています。たとえば「構造化された設計はKiro、日常的な編集はCursor、GitHub上のIssueやPR連携はGitHub Copilot、クラウド上での並列タスク実行はCodex、大規模な変更タスクはClaude Code」といった使い分けも効果的です。

以降の具体的な設定例やファイル名は、主にClaude Codeをベースに説明します。ただし、Skills、MCP、Hooks、Memoryといった考え方は、他のAI開発エージェントを活用する際にも応用できます。

AI開発エージェントに共通する機能

• コードベース全体の理解: プロジェクト内のファイルを横断的に読み取り、構造や依存関係を把握
• ファイルの読み書き: 新規作成だけでなく、既存コードの編集も可能
• ターミナルコマンドの実行: テスト実行、ビルド、Git操作をAIが直接実行
• 反復的な問題解決: エラー発生時に自ら原因を調査し修正を試みる
• 計画モードやエージェント実行: 実装前に方針を整理し、合意形成後にコード変更や検証へ進む

AI開発エージェントを活用する仕組み

Skills ── 再利用可能なワークフロー

AI開発エージェントを効果的に使うには、定型作業を再利用可能なワークフローとして整備することが重要です。Claude Codeでは、このようなワークフローをSkillsとして定義できます。手順書やコマンドを用意しておくことで、毎回同じ説明をしなくても標準化されたプロセスを呼び出せます。

たとえば、以下のようなスキルを定義できます。

• /tech-daily: 技術ニュースの収集・翻訳・分類を自動化
• /pre-push-review: PR作成前に複数の観点（規約、セキュリティ、品質）で並列レビュー
• /update-coding-rule: PRコメントやフィードバックから自動でコーディングルールを更新

Skillsを活用することで、定型作業の手順を標準化し、担当者ごとのばらつきを抑えやすくなります。重要なのはLLMとスクリプトの責務分離です。決定的な処理（RSS取得やファイル操作など）はスクリプトに任せ、LLMには判断・生成のみを担当させることで、安定性と再現性を高められます。

MCP（Model Context Protocol）── 外部ツールとの連携

MCPは、AI開発エージェントと外部サービスを安全に連携させるプロトコルです。ブラウザ、データベース、デザインツール、ライブラリドキュメントなどと接続することで、AIの活動範囲を大幅に拡張できます。

通常、AIは与えられた会話やファイルの範囲でしか判断できません。MCPを使うと、AIが必要に応じてブラウザで画面を確認したり、データベースのスキーマを取得したり、ライブラリの最新ドキュメントを参照したりできます。これにより、人間が情報をコピーして貼り付ける作業を減らし、AIがより実務に近い文脈で判断できるようになります。

また、MCPは単なる情報取得だけでなく、外部ツールに対する操作にも使えます。たとえば、E2Eテストの実行、デザインデータの参照、データベース情報の取得などをAIのワークフローに組み込めます。一方で、AIが操作できる範囲が広がるため、接続先ごとの権限設定や、読み取り専用・書き込み可能の切り分けを明確にしておくことが重要です。

なお、外部サービスとの連携をすべてMCPで行う必要はありません。取得できる情報量が多いサービスや、手順が決まっている定型作業は、MCP経由だとトークン使用量が増えやすい場合があります。そのため、必要な情報だけを取得しやすいCLIやAPIをスクリプト化し、Skillsから呼び出すほうが適しているケースもあります。

代表的なMCP連携の例は以下の通りです。

MCP設定は.mcp.jsonに一元管理でき、チーム全体で共有可能です。チームで共通の接続先や権限を管理しておくことで、個人ごとの環境差を減らし、AIが参照できる情報源を標準化できます。

Hooks ── イベント駆動の自動化

Hooksは、AIエージェントの内部イベント（ファイル編集時、コマンド実行前後、セッション開始時など）に対して、シェルコマンドや追加指示を差し込む仕組みです。

LinterやFormatterのように決定論的に検証できる処理は、AIに判断させるよりも外部ツールに任せるほうが適しています。トークン使用量を抑えられるだけでなく、実行結果の再現性やパフォーマンスの面でも安定しやすくなります。

• PostToolUse: AI出力後にフォーマッター自動実行
• PreToolUse: リンター設定ファイルの編集をブロック
• Stop: 作業完了時に通知を送信

これにより、AIが出力するたびに自動で品質チェックが走り、コーディング規約違反をリアルタイムで修正できます。

Memory ── セッションを超えるコンテキスト継承

LLMは本質的にステートレスです。セッションが変わるたびに「初めまして」の状態に戻るため、前回の議論や意思決定がリセットされてしまいます。メモリ機能やプロジェクトドキュメントは、この課題を解決するための仕組みです。

メモリは`MEMORY.md`をインデックスとして、プロジェクト固有の情報をファイルベースで永続化する仕組みです。以下のような情報を保存できます。

• ユーザー情報: 開発者の役割や専門領域、好みの開発スタイル
• フィードバック: 「テストではDBをモックしない」「PRは1つにまとめる」といった過去の指示・修正
• プロジェクト情報: 進行中の施策や期限、技術的な意思決定の背景
• リファレンス: 外部ツールやダッシュボードの所在情報

メモリの最大の価値は、同じ説明を二度としなくてよくなる点です。「このプロジェクトではPrismaを使っている」「テストはVitest」といったコンテキストが自動的に引き継がれることで、セッション開始直後から精度の高い出力が得られます。ハーネスエンジニアリングにおいても、メモリはセッション間の一貫性を担保する重要な層として位置づけられています。

AI駆動開発のメリットと注意点

メリット

• 開発速度の向上: コード生成、調査、テスト、修正の一部をAIに任せることで、実装や検証のサイクルを短縮できる
• コード品質の標準化: ハーネス（後述）により、経験に依存しない一定水準の実装を実現
• レビュー負荷の軽減: 機械的チェックをAIの一次レビューで完結させ、人間は本質的な設計議論に集中
• 学習コストの削減: 未経験の言語やフレームワークでもAIのサポートで短期間キャッチアップが可能

注意点

• AIの出力を鵜呑みにしない: 特にビジネスロジックやセキュリティに関わる部分は、エンジニア自身による入念なレビューが不可欠
• コンテキストウィンドウの制限: 会話履歴が蓄積すると応答品質が低下。`/clear`や`/compact`で適切に管理が必要
• セキュリティ設計が先: 権限管理、許可/拒否ルールの細分化、秘密情報へのアクセス制限を事前に構築
• コスト管理: API従量課金やサブスクリプション（Max $100〜$200/月等）など料金体系を把握し、LLMとスクリプトの責務分離でトークン消費を最適化

AIエージェントを安全に運用するハーネスエンジニアリング

ハーネスエンジニアリングとは

2026年2月、HashiCorp共同創業者のMitchell Hashimotoが「ハーネスエンジニアリング」という用語を提唱しました。「エージェントがミスを犯すたびに、そのミスが二度と起こらないようにシステムを設計する」という考え方です。その後、Martin Fowlerのサイトで「Agent = Model + Harness」という枠組みが体系化され、ハーネス（馬具）が馬の走行を制御するように、AIエージェントの行動を事前にガイドし、事後にセンサーで検証するという、より広い概念へと発展しました。

従来のCLAUDE.mdはあくまで「お願い」に過ぎず、違反検知や持続性がありませんでした。ハーネスエンジニアリングは、これを実行・検証・記憶を統合したシステムへと進化させます。Fowlerはガイドをフィードフォワード制御（AGENTS.mdやコーディング規約による事前規制）、センサーをフィードバック制御（linterやテストによる事後検証）と整理しています。

※ ハーネスエンジニアリングはまだ新しい概念であり、論者によって定義の範囲に幅があります。本記事ではMartin Fowlerらの体系的な整理に基づき解説します。

指示と制御を設計するポイント

Claude Codeでは、AIエージェントに指示を出したり、行動を制御したりできるポイントがいくつかあります。それぞれのポイントに次のような役割を持たせることで、AIがプロジェクトの文脈に沿って動きやすくなります。

特に効果的なのは「やらないこと」の明記です。「自動ファイル整理禁止」「既存のテストファイルを削除しない」など、明確な境界線を設けることで、AIの意図しない余計な改善が劇的に減少します。

段階的な導入方法

ハーネスの導入において「完璧なシステムを先に構築する必要はない」という考え方が広まっています。推奨される導入ステップは以下の通りです。

1. Day 1: CLAUDE.mdに技術スタック・規約を記述（30分で開始）
2. Week 1〜2: 繰り返し説明している作業をスキル化
3. Week 2〜4: ルール違反パターンを検知するフックを追加
4. 継続: 同じ違反が3回発生したら、ルール強度を1段階上昇

重要なのは「開発とハーネス整備を区別せず、同じタスク内で完結させる」こと。この考え方により、ハーネスは開発と並行して自然に育っていきます。

導入事例：FlashRepair ── AIによる障害対応の自動化

BeeXでは、AI駆動開発の実践としてFlashRepairという障害対応自動化の仕組みを構築し、Microsoft AI Tour Tokyo 2026にて出展しました。

課題：属人的な障害対応プロセス

多くの開発現場では、アプリケーション障害が発生した際の対応プロセスに構造的な課題を抱えています。

• 時間: ログ調査から原因特定、コード修正までに時間を要する
• 品質: 修正内容が担当者のスキルに依存し、品質にばらつきが生じる
• 体制: 時間帯に依存した対応体制のため、常時対応が困難

これらの課題は、対応プロセスが人手中心であることに起因しています。

解決策：Claude Codeを活用したAI自動化

BeeXが開発したFlashRepairは、Claude Codeを活用し、障害検知後の一連の対応プロセスをAIで自動化するソリューションです。

具体的には、以下のプロセスをAIが自律的に実行します。

1. ログ解析: 障害発生時のログをAIが自動で収集・分析
2. 原因特定: ログの内容とコードベースを照合し、障害の根本原因を特定
3. 修正コード生成: 原因に基づいた修正コードを自動生成
4. PR作成: 修正内容をプルリクエストとして自動作成

人間はレビューと最終判断に集中できるようになり、障害対応の構造そのものが変わります。

ソリューション開発でのAI駆動開発の実践

FlashRepairは、開発プロセス自体にもAI駆動開発を取り入れて構築しました。まずSpec駆動開発の考え方を取り入れ、ソリューションの目的、対象とする障害対応プロセス、AIに任せる範囲、人間が判断すべき範囲を整理しました。実装に入る前に、ログ解析、原因特定、修正案生成、PR作成といった一連の流れを仕様として明文化することで、AIが目指すべきゴールと制約を明確にしました。

そのうえで、実装フェーズではAgentic Codingを実践しました。Claude Codeにリポジトリの構造や既存コードを調査させ、必要な機能の分解、実装、テストを連続的に進めさせました。さらに、開発中のFlashRepair自身を使ってエラー発生時の調査と修正を行い、実際の障害対応に近い流れで精度を高めながらコードを改善しました。人間はすべての作業手順を逐一指示するのではなく、仕様の妥当性、修正方針、最終的な品質を確認する役割に集中しました。

このように、仕様を先に固めるSpec駆動開発と、AIエージェントに実装作業を自律的に進めさせるAgentic Codingを組み合わせることで、短期間でソリューションを形にしながら、実装内容の一貫性も保ちやすくなります。

導入効果

まとめ

AI駆動開発は、単なるコード生成の効率化ではなく、開発ワークフロー全体の再設計です。エンジニアに求められるスキルも変化しており、「AIが安全に動作できる環境設計」「レビュー観点の言語化」「ワークフローの構造化」が新たな評価軸として重要性を増しています。

AI開発エージェントは、Skills・MCP・Hooks・Memoryといった仕組みにより、単なるチャットボットではなく、プロジェクトの文脈に沿って作業する開発パートナーとして活用できます。そして、ハーネスエンジニアリングの考え方を取り入れることで、AIの出力品質を「お願い」ではなく「構造」で守れるようになります。

まずはプロジェクトの前提情報や開発ルールを整理し、痛みを感じたところからSkillsやHooksを追加していく。この段階的なアプローチが、AI駆動開発を成功させる鍵です。