1. Agent開発とは
Agent開発とは、AI開発ツール（GitHub Copilot / Claude Code / Amazon Q Developer等）を使って、コード生成・調査・テスト作成・リファクタリングなど幅広い作業をAIに委ねる開発手法です。ただし、Agentは指示の質に強く依存します。
Agent開発が効果を発揮する条件
- 要件・設計・DB定義などのドキュメントがmdファイルとして整備されている
- 要件が定まっており、確認すべき論点が明確である
- 広く浅く調べてから狭く深く掘る段階的な進め方を維持できる
- AIの役割と人の役割の境界が明確になっている
2. 工程の全体像
製造は最初から詳細設計や実装に入るのではなく、段階的に材料を作りながら進めます。
全体フロー
工程ごとの判断の重点
| 工程 | 判断の重点 | 次への引き渡し |
|---|---|---|
| 初回調査 | 影響箇所を起点に機能経路を粗く整理する | 詳細化調査のたたき台 |
| 詳細化調査 | 機能名・使われ方の情報を足して粒度を上げる | 詳細設計の材料 |
| 詳細設計 | 修正が成立するために一式揃えるべき対象を経路全体で明確にする | 実装判断と管理表の起点 |
| 実装準備 | 工数管理より修正漏れ防止の粒度を優先した管理体制を作る | 実装とレビューの起点 |
| 実装 | チェック表の粒度で進捗と確認を同一の流れで管理する | テスト対象 |
| テスト設計 | 調査・設計の内容をテスト観点に変換する | テスト処理実装の材料 |
| テスト実装・実行 | NGを収束のシグナルとして扱い、現象と発生箇所を切り分けて対処する | NG原因調査・再実行 |
| NG対応 | 考慮事項の不足か処理の誤りかを切り分け、対応したうえで再実行する | 収束判断 |
| 横断確認 | セッションを変えて成果物全体を俯瞰し、工程またぎの矛盾・漏れを確認する | 問題があれば前工程に戻る |
3. 基本方針4原則
AIは指示の粒度と情報の与え方によって出力の精度が大きく変わります。以下の4点を基本方針として意識してください。
3.1 大きい単位で丸投げしない
AIに対していきなり大きな単位で依頼すると、何を基準に整理すべきかがぶれやすくなります。たとえば「機能追加対応」であれば以下のように段階的に扱います。
- 実装対象のヒントを与え、使用経路を整理した資料を作る
- その資料を元に、類似機能・既存処理を参考に影響範囲を調査する
- その上で、詳細設計として必要な情報に落とし込む
- さらに、修正対象やテスト観点につながる粒度まで整理する
3.2 指示の前提を明確にする
「何をしてほしいか」だけを伝えると、不明事項が多すぎてあいまいさが残りやすくなります。最低限以下を明記してください。
| ルール | 内容 |
|---|---|
| 今何をするかを明示する | 「こういうことをしたい、今はこれをする」を最初に添える |
| 使う情報を特定する | 何を参照させるかを明示し、不要な情報との混在を避ける |
| やること・やらないことを明記する | 想定外の補完や変更をさせないために、範囲を明示する |
| 今のフェーズを明確にする | 調査なのか、詳細設計なのか、テスト観点抽出なのかを最初に添える |
3.3 不明点を推測で埋めさせない
開発工程では、推測で埋められた内容がそのまま調査結果・設計内容・テスト観点に混ざると、後続工程での誤りの原因になります。以下の方針を前提として与えてください。
- 不明点は推測で埋めない
- あいまい事項を残したまま進めない
- 判断に必要な情報が不足している場合は確認を求める
3.4 確認質問は選択式にさせる
AIから利用者へ確認を返す場合、自由記述での質問は回答側の表現ゆれや認識差異が生じやすくなります。選択式で質問するよう指定する運用を行ってください。
- 利用者とAIの認識差異を抑えやすい
- 回答の粒度を揃えやすい
- AIが必要な情報だけを取得しやすい
- 会話の論点がずれにくい
4. AIと人の役割分担
AIの役割と人の役割を明確に分けることが重要です。この境界を崩さないことが品質維持の鍵です。
| AIの役割 | 人の役割 |
|---|---|
| 修正対象の整理・見える化 | 実装の実施・判断 |
| 修正点を行単位で管理できる資料の作成 | 進捗と確認の管理 |
| 設計・テスト観点の補完 | レビューとクローズ |
| 影響範囲の調査・整理 | 変更の妥当性と品質を担保 |
| テストケースの生成・実行 | テスト観点の妥当性判断 |
| 直接の処理変更は担当しない | 最終的な変更判断を持つ |
5. 各工程で意識する観点
5.1 影響範囲調査で意識すること
調査の出発点では、まず影響の全体像を広く浅く把握し、その後に論点を絞って深掘りします。
- 値の入口（画面入力、連携入力、取込など）
- 値の中間処理（保持、変換、計算、判定など）
- 値の出口（保存、表示、外部連携、出力など）
| 観点 | 考え方 |
|---|---|
| 受け口 | 入力経路に抜けがないかを確認する |
| 保持 | 保持、複製、再表示の整合を確認する |
| 計算 | 計算、判定、条件分岐への波及を確認する |
| 連携 | 機能間や外部連携への受け渡しを確認する |
| 類似性 | 類似ロジックと同一観点で比較し漏れを防ぐ |
5.2 設計整理で意識すること
影響範囲の結果は、後工程がそのまま使える粒度へ整理することを重視します。単なる列挙ではなく、判断と作業につながる形に落とし込みます。
| 観点 | 考え方 |
|---|---|
| 一式整合 | 部分修正ではなく、経路全体で整合を取る |
| 漏れ防止 | 漏れやすい箇所を独立した確認項目にする |
| 計算対称性 | 同じ意味の計算は経路間で対称性を保つ |
| 後段独立 | 再表示、出力、連携を入口修正と切り分けて確認する |
| 依存順序 | 前提条件が満たされる順で検討を進める |
5.3 実装フェーズとの切り分けで意識すること
AIは調査・整理・観点補完を担い、人は変更判断と品質責任を担うという境界を崩さないことが重要です。
5.4 テスト設計・実行で意識すること
テストは「確認作業」というよりも、設計と実装の妥当性を収束させる工程として扱います。
- 調査結果と設計情報からテスト観点を明確化する
- 観点をテストケースへ落とし込んで実行する
- NGの現象と原因を切り分ける
- 不足観点または処理内容を見直す
- 再実行して収束を確認する
| 観点 | 考え方 |
|---|---|
| 静的確認だけで終わらせない | 定義の存在だけでなく実際の挙動を確認する |
| 利用経路で確認する | 入口から出口まで一連の経路で確認する |
| 部分最適で終わらせない | 局所的な成立を全体成立とみなさない |
| 未確認を残さない | 未確認項目を明示し、完了条件をそろえる |
| 原因を切り分ける | 現象、発生条件、原因を分けて整理する |
5.5 工程横断確認で意識すること
各工程を個別に閉じるだけでなく、成果物同士の整合を横断的に確認します。
- 設計書と実装した処理の整合
- テスト仕様書とテスト処理の整合
- 設計書とテスト仕様書の整合
- 工程をまたいだ矛盾・漏れの確認
6. 適用条件と限界
この進め方が機能しやすいのは、以下の条件がそろっている場合です。
- 詳細設計、テーブル定義、既存仕様などのドキュメント類がそろっていて、AIに与える判断材料がある
- 要件が定まり、確認すべき論点が明確である
- まず広く浅く調べ、必要箇所を狭く深く掘る段階的な進め方を維持できる
前提情報がある程度そろった状態で、広く浅い探索から狭く深い検討へ段階的に移る運用と相性がよいケースで有効に機能します。
まとめ：特に有効だったポイント
- 命令は大きな単位で丸投げせず、小さな単位で指示する
- 内容は浅いところから始め、段階的に深掘りして調査する
- やらないでほしいことよりも、今やってほしいことと使う情報を明確にする
- 不明点を推測で埋めさせず、必ず確認させる
- AIと人間の認識ブレを減らすため、確認形式は選択式にする
- 実装は人間の判断を残し、AIは調査・整理・確認を中心に使う
- 製造後に成果物を横断して整合性を確認する
7. 経済効果・ROI試算と具体例
本章の4原則・9工程フローは、理論だけでは価値が伝わりにくいものです。 この章では、実際の現場で得られた工数削減効果と、 現場で即使えるプロンプト例、そして 失敗事例（反面教師）を具体的に提示します。
7.1 工数削減ROI試算（3業種モデルケース）
以下の数値は、私が本業（30万ステップVBシステム→ASP.NET Coreマイグレーション）および 個人プロジェクト（AIに21,000行/2日で書かせた株式自動売買システム）で 実測した工数削減効果を、典型的な開発現場にあてはめた試算です。
業種別サマリー（Web開発 / SIer / 社内SE）
業種・現場特性によって、AI Agent 開発で得られる削減率は異なります。 以下は代表的な3業種での試算例です。
| 業種 | 主要業務 | 削減率レンジ（例） | 初期投資（例） | ペイバック期間（例） |
|---|---|---|---|---|
| Web開発（受託） | API実装・画面実装・テスト | 30〜50%（定型実装ほど高い） | ツール月額 3,000〜6,000円／人 + 学習3人日 | 約 1〜2ヶ月 |
| SIer（中〜大規模） | 既存システム保守・影響調査・マイグレーション | 40〜60%（調査工程で特に高い） | ツール月額 6,000〜12,000円／人 + 社内ガイドライン整備 10人日 | 約 2〜3ヶ月 |
| 社内SE（事業会社） | 業務システム改修・ドキュメント整備・問合せ対応 | 20〜40%（業務知識が暗黙知化していると下振れ） | ツール月額 3,000〜6,000円／人 + mdドキュメント整備 15人日 | 約 3〜5ヶ月 |
※ 上記数字はすべて例示です。特に社内SEは「業務知識の形式知化」の進度でペイバックが大きく変わります。 CLAUDE.md / project_info.md など mdファイル外部メモリを整備した後に本運用へ移行することを推奨します。
ケース1: 既存システムの影響範囲調査（保守開発）
- 旧来手法： grep・IDE検索・ドキュメント読込みで 5日間（約225,000円）
- 本ガイドの手法： AIに広く浅く調査させ、狭く深く追う運用で 1.5日間（約67,500円）
- 削減： 3.5日 = 約157,500円/案件
- 年10件対応する技術者なら： 年間 約157万円の工数削減
ケース2: API新規実装（新規開発）
- 旧来手法： 要件整理→設計→実装→テストで 7日間（約315,000円）
- 本ガイドの手法： 質問フェーズ→詳細設計→段階実装で 3日間（約135,000円）
- 削減： 4日 = 約180,000円/案件
- 月2本実装する現場なら： 月 約36万円の工数削減
ケース3: レガシー→モダン移行（マイグレーション）
- 旧来手法： VB6 1万行のASP.NET Core移行に約3ヶ月（約900万円）
- 本ガイドの手法： AIと段階協調で約1.5ヶ月（約450万円）
- 削減： 1.5ヶ月 = 約450万円/案件
- 29,800円のプレミアム版の元を取るラインは、削減 5時間分に相当します。
7.2 Overview レベルで使える代表プロンプト5例
Chapter 01 は「AI Agent 開発の全体像」を扱う章なので、ここでは 読者が本章を読んだ直後に試せる判断・説得・設計系プロンプトを 5つ掲載します。実装工程向けの詳細プロンプトは Chapter 08 プロンプト集に収録しています。
想定読者: 「自分のプロジェクトにAI Agent を入れるべきか」「社内にどう提案するか」を これから判断する立場の方（開発者・リーダー・社内SE）。
プロンプト例1: 自プロジェクトのAI Agent化 診断プロンプト
# 目的: 自分が今担当しているプロジェクトに、AI Agent 開発を導入すべきかを診断する
# フェーズ: 導入判断（実装前の事前評価）
以下の観点で、私のプロジェクトを A/B/C の3段階で評価してください。
推測で埋めず、情報が不足している観点は「情報不足」と明示してください。
【私のプロジェクト情報】
- 言語/FW: （例：C#/ASP.NET Core）
- 規模: （例：30万ステップ、10人チーム、保守5年目）
- ドキュメント: （例：基本設計書あり、DB定義書あり、業務フロー図なし）
- 既存AIツール利用: （例：GitHub Copilot を2名が個人利用）
【診断観点】
1. mdファイルによる外部メモリ整備度（A: 十分 / B: 部分的 / C: ほぼなし）
2. 要件の確定度（A: 確定 / B: 一部変動 / C: 頻繁に変動）
3. 調査→設計→実装の段階的進行の維持可能性（A/B/C）
4. レビュー体制（A/B/C）
5. 業務知識の形式知化の進度（A/B/C）
【出力形式】
- 各観点の評価と、その根拠（私が提示した情報のどこを見たか）
- 総合判定（導入推奨 / 条件付き導入 / 導入時期尚早）
- 条件付き導入の場合は、先に着手すべき準備タスクを最大5個ポイント: 自分の環境を書き出す形式にしてあるので、コピペで埋めて AI に渡せる。 「情報不足」を明示させる指示で、推測排除（4原則の3つめ）を徹底しています。
プロンプト例2: AI導入 社内稟議書ドラフト作成プロンプト
# 目的: AI Agent 開発ツール導入の社内稟議書をドラフト作成する
# フェーズ: 導入提案（判断後の社内合意形成）
以下の情報から、稟議書のドラフトを作成してください。
根拠のない効果の誇張は避け、数字はすべて「見込み」「試算」と明記してください。
【導入対象】
- ツール名: （例：GitHub Copilot Business / Claude Pro / Amazon Q Developer）
- 対象人数: （例：開発部 8名）
- 月額費用: （例：@3,000円 × 8名 = 24,000円/月）
【期待効果（見込み）】
- 定型実装の削減率: （例：30〜50%と試算）
- 年間工数削減見込み: （例：人日換算で◯◯日、金額換算で◯◯円）
- 根拠: （例：直近3ヶ月の作業ログ分析 / ベンダー公開資料）
【リスクと対策】
- 情報漏洩リスク → 対策：（例：エンタープライズ版利用、プロンプト送信範囲の社内規程化）
- 品質バラつき → 対策：（例：CLAUDE.md 共通化、プロンプト雛形の社内配布）
- ROI が出ない場合の撤退条件 → （例：3ヶ月目に削減率が目標の50%未満なら再評価）
【出力形式】
- 件名
- 目的（3行以内）
- 現状と課題
- 導入案（コスト / 期間 / 責任者）
- 期待効果（数字はすべて「見込み」明記）
- リスクと対策
- 撤退条件
- 決裁区分の目安ポイント: 誇張を避ける指示と「撤退条件」を必ず含めることで、稟議の通過率が上がります。 失敗事例4（後述）の「ROIを追跡せず半年後に判断できない」を構造的に防ぐ設計です。
プロンプト例3: 影響範囲調査（段階的粒度化）
# 対象: UserService.cs の getUser() メソッド
# フェーズ: 調査のみ（実装は別タスク）
1. まず @UserService.cs を読み、getUser() の呼び出し元を列挙してください
→ 浅く広く: 呼び出し元のファイル名と行番号だけ、推測せずに
2. リストアップ後、「呼び出し元の中で戻り値の null チェックをしていない箇所」を
私に次の確認として提示してください（候補形式で、A/B/C選択式で）
3. 私が選択した候補について、初めて掘り下げ調査をしてください
→ 狭く深く: その関数の前後50行と、関連する設定値ポイント: 段階を明示し、各段階でAIに「選択肢を出させて人が決める」型にしている。 一度に全部やらせず、人間が制御点を持ち続ける設計です。
プロンプト例4: 新規実装の質問フェーズ（推測排除）
# 対象: 新規API /api/orders/{id}/cancel の実装
# フェーズ: 設計確定前の質問フェーズ
以下の仕様書を読み、実装に必要だが記載されていない情報を
**質問の形で** 列挙してください。
仕様書: @docs/order_cancel_spec.md
ルール:
- 推測で埋めて進めない
- 質問は最大10個まで、重要度順に
- 各質問は「A/B/C の選択式」で答えられる形にする
- 「例: キャンセル後の返金処理は同期/非同期/別キュー投入 のどれですか」
- 質問リストだけ提示し、実装には着手しないポイント: 仕様の抜けを「質問」として可視化させる。AIの想像で勝手に実装させない。 この1手間で後工程の手戻りが激減します。
プロンプト例5: 実装後の成果物横断確認（整合性チェック）
# 対象: OrderController と OrderService の新規実装完了後の整合性確認
# フェーズ: 横断確認（新規セッション推奨）
新規の Claude Code セッションで、以下を確認してください:
1. @OrderController.cs と @OrderService.cs の間で、
- 引数の型が一致しているか
- null ハンドリング方針が一貫しているか
- 例外クラスが統一されているか
2. @docs/order_cancel_spec.md の仕様と、実装された処理フローが
- 順序として一致しているか
- 境界条件（タイムアウト・重複要求）が仕様通りか
3. 不整合を発見したら、箇条書きで「ファイル:行番号 + 説明」の形で報告
→ 修正は別タスク、ここでは指摘のみポイント: 実装したセッションとは別セッションで確認する。 同じセッションの中で「作った本人」にレビューさせるとバイアスが残るため。
7.3 失敗事例5つ（反面教師）
本ガイドの原則を守らなかった結果、従来手法より工数が増えた・導入自体が頓挫したケースを紹介します。 AIを使えば必ず速くなる、というのは誤解です。 使い方を誤ると、手戻りで倍以上の時間を失うことや、導入プロジェクト自体が消える事例があります。
※ 以下の事例は、私の周辺（本業・個人・DM相談）で見聞きしたものを再構成した、 業界リアリティを保った典型パターンです。特定の会社・人物を指すものではありません。
失敗事例1: 丸投げによる巨大な手戻り
「このディレクトリ配下の全ファイルを読んで、バグを全部直して」という単一プロンプトで丸投げ。
結果：
AIが勝手に影響範囲を広げて関係ない箇所まで書き換え、テストが50件破損。 原因特定と手戻りに 2日 を要した。
学び： 大きな単位の丸投げは、AI活用の最悪のアンチパターンです。 必ず「対象ファイルの列挙」「調査→提案→実装」の段階に分けて指示します。
失敗事例2: 推測で埋めさせた設計ミス
仕様が曖昧なまま「良い感じに実装して」と指示。 AIは善意で推測して実装したが、その推測が業務要件と食い違っていた。
結果：
コードは動いたが、お客様のレビューで「そもそも要件が違う」と全面やり直し。 1週間分の実装が無駄になった。
学び： 不明点は必ず「質問フェーズ」として分離し、 人間が確定してから実装に入る。推測で動かないこと自体が価値です。
失敗事例3: 同一セッションでの自己レビュー盲点
実装したセッションの中で「このコードをレビューして」と同じAIに依頼。
結果：
AIは自分が書いたコードを「問題なし」と判定した。 本番投入後、本来気付くべき境界バグが発生し、夜間対応となった。
学び： レビューは必ず新規セッションで、しかも
「元の仕様書」と「実装されたコード」の両方を改めて読ませる形で行います。
バイアスのかからない目が必要です。
どう防げたか： 別セッションで「仕様書＋実装コード」を渡し、
「このコードが仕様を満たしているか」ではなく「このコードと仕様の差分を列挙せよ」と指示する。
失敗事例4: 役員の一声で全員配布 → 3ヶ月後ライセンス停止
役員が外部セミナーで感化され「うちも全開発者に Copilot を配れ」と指示。 導入目的・効果測定・運用ルールを決めないまま、30名分のライセンスを一括契約。
結果：
利用率は 3ヶ月で 20% を切り、「効果が見えない」という理由でライセンスを全停止。 残った開発者からは「せっかく使いこなし始めたのに」と不満が出て、現場の士気も下がった。 再導入の声が上がっても「前回やってダメだった」で通らなくなった。
なぜ失敗したか： 導入判断に 測定可能な成功条件（削減率・利用率・撤退条件）が
設定されていなかった。感情論で導入し、感情論で停止した典型パターン。
どう防げたか： 本章 7.2 の「稟議書ドラフト作成プロンプト」を使い、
撤退条件と測定指標を稟議段階で文書化する。
小さく始めて（パイロット 3〜5名 × 2ヶ月）、測定してから全体展開する。
失敗事例5: ROI を月次追跡せず、半年後に投資判断できない
導入時は効果を期待して契約したが、日々の使用状況・削減工数の記録を誰も取らず、 半年後の契約更新タイミングで「結局いくら得したのか」を誰も答えられない状態に。
結果：
経理から「費用対効果の説明」を求められたが根拠資料が作れず、 「来期は予算削減対象」扱いに。現場は効果を実感していたのに、数字で示せなかったため失った。
なぜ失敗したか： 運用に入った瞬間、ROI追跡が「誰のタスクでもない」状態になった。
効果を感じているのは個々人の肌感覚だけで、組織として積算されていなかった。
どう防げたか：
導入月から「月次 AI活用レポート」を1人の担当（社内SEやリード）に寄せる。
最低限「利用人数」「主な用途3件」「時間削減の肌感（例：2〜3人日/月）」を 1ページ A4 で残すだけでも効果がある。
完璧な計測より、継続できる軽量計測を優先。
失敗事例 1〜3 は 現場オペレーションのアンチパターン（4原則違反）、 失敗事例 4〜5 は 導入・運用ガバナンスのアンチパターンです。 前者は「守らないと遅くなる」、後者は「測らないと消える」という共通構造があります。 AI Agent 開発の成否は、現場の使い方と、組織としての測定・継続の両輪で決まります。
後続の章（02 新規開発、03 保守開発、04 言語別実践、05 AI開発ツール、 08 プロンプト集、09 ハンズオン）では、これらの原則を具体的な現場シーンに 落とし込んだテンプレートとプロンプトを提供します。