既存のコードベースでバグに遭遇したとき、「どこから手をつければいいのか」「修正が他の部分に影響しないか」といった不安を感じたことはありませんか。Devin を活用すれば、バグの再現から原因特定、最小限の修正、そして回帰テストまでを一連のプロンプトで効率的に進められます。本記事では、Devin を使った実践的なバグ修正フローを、具体的なプロンプト例とともにご紹介します。

背景

AI 駆動の開発支援ツール Devin

Devin は、自律的にコードを読み書きし、ターミナル操作やブラウザ操作まで行える次世代の AI ソフトウェアエンジニアです。単なるコード補完ツールではなく、開発者が指示した目標に向かって自律的にタスクを遂行できます。

従来のバグ修正プロセスの課題

従来、バグ修正は以下のような手順で行われてきました。

• Issue 報告の確認: ユーザーや開発者からの報告内容を読み解く
• ローカル環境での再現: 報告された条件を再現するための環境構築
• デバッグ作業: ログ出力やブレークポイントを使った原因特定
• 修正コードの実装: 影響範囲を考慮しながらのコーディング
• テストの実行: 修正箇所と関連機能の動作確認

この一連の流れは、経験豊富な開発者でも数時間から数日を要することがあります。特に大規模なコードベースでは、影響範囲の特定だけで多大な時間がかかるでしょう。

下図は、従来のバグ修正フローを示しています。

mermaidCopy codeflowchart TD
  report["バグ報告"] --> reproduce["再現作業"]
  reproduce --> debug["デバッグ作業"]
  debug --> identify["原因特定"]
  identify --> fix["修正実装"]
  fix --> test["テスト実行"]
  test --> review["レビュー"]
  review --> done["完了"]

各ステップで人手による調査・判断が必要になり、時間とコストがかかります。

課題

バグ修正における 3 つの障壁

バグ修正を効率化する上で、以下の 3 つの課題が立ちはだかります。

1. 再現条件の特定に時間がかかる

バグ報告が曖昧だったり、環境依存の問題だったりすると、再現するまでに多くの試行錯誤が必要です。特定の入力値や操作順序でのみ発生するバグは、再現条件を見つけるだけで数時間を要することもあります。

2. 根本原因の特定が困難

再現できても、どのモジュールやファイルが原因なのかを突き止めるのは簡単ではありません。コールスタックが深かったり、複数のファイルにまたがる処理だったりすると、原因箇所の特定に時間がかかるでしょう。

3. 修正による副作用のリスク

修正したコードが他の機能に影響を与えないか、慎重な確認が求められます。回帰テストを手動で行うのは手間がかかり、テストケースの漏れが発生しやすくなります。

下図は、バグ修正における課題の関係性を示しています。

mermaidCopy codeflowchart LR
  bugReport["バグ報告<br/>（曖昧な情報）"] --> reproduce["再現困難"]
  reproduce --> time1["時間消費"]
  identify["原因特定<br/>（複雑な依存関係）"] --> time2["時間消費"]
  fix["修正実装"] --> sideEffect["副作用リスク"]
  sideEffect --> regression["回帰バグ"]
  time1 --> cost["開発コスト増"]
  time2 --> cost
  regression --> cost

これらの課題が重なることで、バグ修正の工数が肥大化し、開発スピードが低下してしまいます。

解決策

Devin による自律的バグ修正フロー

Devin を活用すれば、以下の 4 ステップで効率的にバグを修正できます。

ステップ 1: バグの再現

まず Devin にバグの再現を依頼しますね。具体的なプロンプトは次のようになります。

プロンプト例（再現フェーズ）

textCopy code以下のバグを再現してください：

Issue: ユーザー登録時にメールアドレスのバリデーションエラーが表示されない

再現手順:
1. `/signup` ページにアクセス
2. 不正なメールアドレス（例: `invalid-email`）を入力
3. 送信ボタンをクリック

期待される動作: バリデーションエラーメッセージが表示される
実際の動作: エラーメッセージが表示されず、送信が進んでしまう

環境:
- Node.js 18.x
- Next.js 14.x
- React Hook Form 7.x

手順:
1. ローカル環境でアプリケーションを起動
2. 上記の手順を実行
3. 再現できたらスクリーンショットとログを取得
4. 再現できない場合は、その旨を報告

このプロンプトには以下の要素が含まれています。

• 明確な再現手順: ステップごとの操作を番号付きで記載
• 期待値と実際の動作: 何が問題なのかを明示
• 環境情報: バージョンや使用ライブラリを指定
• Devin への指示: 具体的なアクションを列挙

ステップ 2: 原因の特定

再現が確認できたら、次は原因特定を依頼します。

プロンプト例（原因特定フェーズ）

textCopy codeバグの原因を特定してください：

再現されたバグ: メールアドレスのバリデーションエラーが表示されない

調査方針:
1. バリデーションロジックが実装されているファイルを特定
2. フォーム送信時の処理フローを追跡
3. エラーハンドリングの実装を確認
4. 関連するReact Hook Formの設定を確認

出力してほしい情報:
- 問題のあるファイル名と行番号
- 現在の実装コード（該当部分）
- なぜエラーが表示されないのか（根本原因）
- 影響範囲（他の機能への影響）

このプロンプトのポイントは次の通りです。

• 調査の方針を明示: Devin が何を調べるべきかを具体化
• 求める出力を指定: 必要な情報を漏れなく取得
• 影響範囲の確認: 修正による副作用を事前に把握

ステップ 3: 最小限の修正

原因が特定できたら、最小限のコード変更で修正を実装します。

プロンプト例（修正フェーズ）

textCopy code以下の原則に従って修正を実装してください：

最小変更の原則:
- 特定された原因箇所のみを修正
- 既存のコードスタイルを維持
- リファクタリングは含めない
- 他の機能に影響を与えない

修正手順:
1. 該当ファイルを開く
2. 問題のある実装を修正
3. 修正内容をコメントで説明
4. 変更差分を表示

修正後の確認:
- 修正したコードが意図通り動作するか
- TypeScriptのエラーが出ないか
- Lintエラーが発生しないか

最小限の修正に留めることで、以下のメリットが得られます。

• レビューの効率化: 変更箇所が少ないため、レビュアーの負担が軽減される
• デバッグの容易性: 問題が再発した場合、原因を特定しやすい
• リスクの低減: 予期しない副作用が発生する可能性が減る

ステップ 4: 回帰テストの実行

最後に、修正による影響がないことを確認するテストを実行します。

プロンプト例（テストフェーズ）

textCopy code以下のテスト計画を実行してください：

修正箇所のテスト:
1. 不正なメールアドレスでエラーが表示されることを確認
2. 正常なメールアドレスで送信が成功することを確認
3. 空欄でのバリデーションエラーを確認

回帰テスト:
1. ログイン機能（メールアドレス入力あり）
2. パスワードリセット機能（メールアドレス入力あり）
3. プロフィール更新機能（メールアドレス変更）

テスト実行方法:
- 手動テスト: 上記の操作を実際に行う
- 自動テスト: `yarn test` を実行し、既存テストが通ることを確認
- E2Eテスト: `yarn test:e2e` を実行（もし存在すれば）

報告内容:
- 各テストの結果（成功/失敗）
- 失敗した場合のエラーメッセージ
- スクリーンショット（UIの確認が必要な場合）

回帰テストを体系的に実行することで、修正の品質を担保できます。

下図は、Devin を使った 4 ステップのバグ修正フローを示しています。

mermaidCopy codeflowchart TD
  start["バグ報告"] --> step1["ステップ1:<br/>再現プロンプト"]
  step1 --> reproduce["Devinが再現作業"]
  reproduce --> step2["ステップ2:<br/>原因特定プロンプト"]
  step2 --> identify["Devinが原因特定"]
  identify --> step3["ステップ3:<br/>修正プロンプト"]
  step3 --> fix["Devinが最小修正"]
  fix --> step4["ステップ4:<br/>テストプロンプト"]
  step4 --> test["Devinがテスト実行"]
  test --> complete["修正完了"]

各ステップで Devin に明確な指示を与えることで、効率的かつ安全にバグ修正を進められるでしょう。

具体例

実際のバグ修正ケース：Next.js フォームのバリデーション

ここでは、Next.js アプリケーションにおける実際のバグ修正プロセスを、Devin との対話を交えながら解説します。

ケースの概要

#	項目	内容
1	バグ内容	メールアドレスのバリデーションエラーが表示されない
2	影響範囲	ユーザー登録フォーム
3	使用技術	Next.js 14.x, React Hook Form 7.x, Zod
4	修正時間	約 30 分（Devin 使用）

フェーズ 1: 再現作業

まず、Devin に以下のプロンプトを送信しました。

textCopy code以下のバグを再現してください：

Issue: ユーザー登録フォームでメールアドレスのバリデーションエラーが表示されない

再現手順:
1. `yarn dev` でアプリを起動
2. http://localhost:3000/signup にアクセス
3. Email欄に `invalid-email` と入力
4. Password欄に `password123` と入力
5. Submit ボタンをクリック

期待動作: "有効なメールアドレスを入力してください" というエラーが表示される
実際の動作: エラーが表示されず、API呼び出しが実行される

Devin の応答は以下の通りでした。

textCopy codeバグを再現しました。

スクリーンショット: [signup-error.png]

確認事項:
- Email欄に `invalid-email` を入力
- Submit ボタンクリック後、エラーメッセージが表示されない
- ブラウザのコンソールに以下のエラーログ：
  POST /api/signup 400 (Bad Request)

次のステップ: 原因特定に進みますか？

再現が確認できたため、次のフェーズへ進みます。

フェーズ 2: 原因特定

続いて、原因特定のプロンプトを送信しました。

textCopy codeバグの原因を特定してください：

調査対象:
1. `src/app/signup/page.tsx` - フォームコンポーネント
2. `src/lib/validation.ts` - バリデーションスキーマ
3. React Hook Formの設定

調査内容:
- zodスキーマが正しく定義されているか
- React Hook FormのresolverにzodResolverが設定されているか
- エラー表示のコンポーネントが実装されているか

出力:
- 問題のあるファイルと行番号
- 現在のコード
- 根本原因の説明

Devin は以下の情報を返してきました。

textCopy code原因を特定しました。

問題のファイル: src/app/signup/page.tsx

該当コード（38-42行目）:

typescriptCopy codeconst form = useForm({
  defaultValues: {
    email: '',
    password: '',
  },
});

textCopy code根本原因:
React Hook FormのuseFormに `resolver` オプションが設定されていません。
そのため、zodスキーマによるバリデーションが実行されていません。

影響範囲:
- ユーザー登録フォームのみ
- ログインフォームは正常に動作（resolverが設定済み）

原因が明確になったので、修正フェーズへ進みます。

フェーズ 3: 最小修正の実装

修正プロンプトを送信しました。

textCopy code以下の方針で修正してください：

修正内容:
- `useForm` に `resolver: zodResolver(signupSchema)` を追加
- `zodResolver` を `@hookform/resolvers/zod` からインポート
- `signupSchema` を `@/lib/validation` からインポート

注意事項:
- 既存のdefaultValuesは維持
- コードスタイルは周辺コードに合わせる
- 不要なリファクタリングは行わない

Devin が実装した修正内容は以下の通りです。

インポート文の追加

typescriptCopy codeimport { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { signupSchema } from '@/lib/validation';

インポート文では、必要なモジュールを追加しています。

useForm の修正

typescriptCopy codeconst form = useForm({
  resolver: zodResolver(signupSchema), // zodバリデーションを有効化
  defaultValues: {
    email: '',
    password: '',
  },
});

resolver オプションを追加することで、zod スキーマによるバリデーションが実行されるようになります。

エラー表示の実装確認

typescriptCopy code{
  form.formState.errors.email && (
    <p className='text-red-500 text-sm mt-1'>
      {form.formState.errors.email.message}
    </p>
  );
}

エラーメッセージを表示するコンポーネントはすでに実装されていたため、追加の変更は不要でした。

修正内容の差分は以下の通りです。

diffCopy code+ import { zodResolver } from '@hookform/resolvers/zod'
+ import { signupSchema } from '@/lib/validation'

  const form = useForm({
+   resolver: zodResolver(signupSchema),
    defaultValues: {
      email: '',
      password: '',
    },
  })

わずか 3 行の追加で、バリデーション機能が有効になります。

フェーズ 4: 回帰テストの実行

最後に、テストプロンプトを送信しました。

textCopy code以下のテストを実行してください：

修正箇所のテスト:
1. `invalid-email` を入力して、エラーメッセージが表示されることを確認
2. `test@example.com` を入力して、エラーが表示されないことを確認
3. 空欄で送信して、エラーメッセージが表示されることを確認

回帰テスト:
1. ログインページ（/login）で同様のバリデーションが動作することを確認
2. 既存のユニットテストを実行: `yarn test`
3. 型チェックを実行: `yarn type-check`

各テストの結果をスクリーンショット付きで報告してください。

Devin のテスト結果は以下の通りでした。

#	テスト項目	結果	備考
1	不正なメール入力	✓ 成功	"有効なメールアドレスを入力してください"と表示
2	正常なメール入力	✓ 成功	エラーなし、送信が進む
3	空欄で送信	✓ 成功	"メールアドレスは必須です"と表示
4	ログインページ	✓ 成功	バリデーション正常動作
5	ユニットテスト	✓ 成功	全テストパス（20/20）
6	型チェック	✓ 成功	エラーなし

全てのテストが成功し、回帰バグが発生していないことが確認できました。

下図は、今回のバグ修正フローの全体像を示しています。

mermaidCopy codesequenceDiagram
  participant Dev as 開発者
  participant Devin as Devin
  participant App as アプリ

  Dev->>Devin: 再現プロンプト送信
  Devin->>App: ローカル起動・操作
  App->>Devin: バグ再現を確認
  Devin->>Dev: 再現報告（スクリーンショット）

  Dev->>Devin: 原因特定プロンプト送信
  Devin->>App: コード調査
  App->>Devin: 問題箇所を特定
  Devin->>Dev: 原因報告（ファイル・行番号）

  Dev->>Devin: 修正プロンプト送信
  Devin->>App: コード修正
  Devin->>Dev: 修正完了報告（差分表示）

  Dev->>Devin: テストプロンプト送信
  Devin->>App: テスト実行
  App->>Devin: テスト結果
  Devin->>Dev: テスト報告（全て成功）

このように、開発者はプロンプトを送るだけで、Devin が自律的に作業を進めてくれます。

修正時間の比較

従来の手動修正と Devin 使用時の所要時間を比較してみましょう。

#	作業内容	手動修正	Devin 使用
1	環境構築・起動	5 分	2 分
2	バグ再現	10 分	3 分
3	原因特定	30 分	5 分
4	修正実装	15 分	3 分
5	テスト実行	20 分	7 分
6	レビュー準備	10 分	3 分
-	合計	90 分	23 分

Devin を使用することで、約 4 分の 1 の時間で修正を完了できました。特に原因特定フェーズでの時間短縮効果が顕著です。

まとめ

Devin を活用したバグ修正フローは、以下の 4 つのステップで構成されます。

1. 再現プロンプト: バグの再現手順と期待動作を明確に指示する 2. 原因特定プロンプト: 調査範囲と出力内容を具体的に指定する 3. 修正プロンプト: 最小変更の原則に従った修正方針を伝える 4. テストプロンプト: 修正箇所と回帰テストの計画を提示する

各ステップで明確なプロンプトを用意することで、Devin は自律的かつ効率的に作業を進めてくれます。従来 90 分かかっていた修正作業が 23 分で完了するなど、大幅な時間短縮が可能になるでしょう。

また、最小限の修正に留めることで、レビューの負担軽減や副作用のリスク低減にもつながります。Devin は単なるコード補完ツールではなく、開発プロセス全体を効率化するパートナーとして機能するのです。

バグ修正に時間がかかっている方は、ぜひこの一連のプロンプトを参考に、Devin を活用してみてください。適切なプロンプト設計により、より高速で安全なバグ修正が実現できますよ。

関連リンク

• Devin 公式サイト
• React Hook Form 公式ドキュメント
• Zod 公式ドキュメント
• Next.js 公式ドキュメント
• TypeScript 公式サイト