誰でもDevinを安定して利用できる？Devinを使った開発工程の標準化を試してみた

はじめに

初めまして、株式会社dotDの大湯と申します！

敷居の高さからあまり馴染みがなかったDevinですが、今回業務の関係で使う機会ができましたので、Devinを初めて使う人にとってどうすれば気軽に利用できるかを検証してみました。

このような記事を書くのが初めてなので拙い文章で申し訳ございませんが、最後までお付き合いいただけますと幸いです！

想定読者

• Devinの使い方がいまいち分からない方（単一リポジトリに対してPR作成まで行います）
• Devinをチームに広げるために最低限の使い方を整理したい方
• 既存プロジェクトに対してDevinを利用したいと検討している方

目次

1. Devinとは
2. 開発工程の標準化とは
3. 検証方針と内容
4. 実施結果
5. まとめ
6. 感想・今後の方針

1. Devinとは

Devin（デビン）は、AIスタートアップ企業のCognition社が開発した、世界初の完全自律型AIソフトウェアエンジニアです。

従来のプログラミング支援AIがコードの提案や部分的な修正に留まっていたのに対し、Devinはソフトウェア開発の全工程を自律的に実行できる点が革新的です。

主な特徴

• 完全自律型開発能力

  • 自然言語の指示から設計、コーディング、テスト、バグ修正、デプロイまでを一貫して実行
  • エラーを自動検出し、修正を試行

• 統合開発環境

  • 独自のシェル、コードエディター、ブラウザを統合した仮想開発環境

• 学習・改善能力

  • ドキュメントを学習し、時間とともにパフォーマンスを向上
  • 既存コードの理解と拡張が可能

• リアルタイム連携

  • タスクの進捗報告とユーザーとのコミュニケーション
  • GitHubやSlackなどのツール連携

要約すると、「人のような振る舞いをするAI開発エージェント」 で、現状はジュニアレベルの開発者と同等の能力を持つとされています。

2. 開発工程の標準化とは

開発工程の標準化とは、特定のルール、手順、ツール、成果物などを決め、それらを組織全体で統一的に適用することを指します。

標準化の目的・効果

• 品質向上: 不具合の削減、一貫性の確保、テスト網羅性の向上
• 効率向上・コスト削減: 作業の属人化解消、無駄の排除
• 生産性の向上: 開発期間の短縮、開発者の負担軽減
• リスク管理の強化: 問題の早期発見、規制要件への準拠
• 組織能力の向上: 知識の共有と蓄積、継続的改善の促進

つまり、**「誰がやっても一定の品質と効率で開発が進むように、やり方を統一すること」**を目指す取り組みです。

3. 検証方針と内容

前提条件

• Gitで管理されている既存プロジェクト（単一リポジトリ、今回はbackend）
• DevinとGitツール（GitHub）が連携済み

検証する要望

今回は以下のような比較的簡単なAPIの追加開発を依頼します。

機能要望
自社製品一覧の製品データおよびその製品に紐づく部品の一覧をCSVファイルに出力する機能

詳細

• 指定の製品データの情報を取得
• 指定の製品データに含まれる全件の部品データの情報を取得
• インポート時に利用するフォーマットで出力
• 出力項目：インポートファイルと同じ+必要な項目（識別子、parts_id等）

制約事項

• 添付ファイルの出力は次フェーズ以降で検討
• エクスポート→インポートで発生するエラー(ユニークエラー)は許容する

検証の仮説

「Devinを使い慣れていない人に対して、一定の成果を安定して出してもらう」ことを目的として、以下2点を検証します：

1. 誰でも同じ運用で、同じ成果物を作成できること
2. 他プロジェクトにも展開できること

検証パターン

以下2パターンで検証を行います：

• パターン①: 要望 → 実装 → PR作成
• パターン②: 要望 → 要件定義・設計書作成 → 実装 → PR作成

パターン①：直接実装パターン

要望から実装・テスト・PR作成を一括で行う方法です。

ドキュメント構成

対象リポジトリのルートディレクトリに以下のファイル構造を配置：

documents/
├── Request.md      # 実現したい要望・機能
├── Readme.md       # 実行手順の指示書
└── devFlow.yaml    # 各ステップの具体的な指示

人が行う作業

1. Request.mdに実現したい要望を記載
2. 最初にReadme.mdを参照するように指示
3. 必要に応じて追加の指示を行い、PR作成まで見守る

主要なドキュメント内容

Readme.md（抜粋）

# AI駆動開発 手順書

**フロー**: 要望分析 → 実装・テスト → PR

## 実行手順

### Step 1: 開発実行
`devFlow-pattern1.yaml`の以下ステップを順次実行:
1. `requirement_analysis` - 要望分析
2. `implementation` - 実装とセルフレビュー
3. `test_creation_and_execution` - テスト作成・実行
4. `mock_and_docs_update` - モック・ドキュメント更新
5. `review_and_pr` - 最終確認とPR作成

## 品質保証のポイント

### Makefileを活用したテスト実行
- `make unit-test`: ユニットテストの実行
- `make integration-test`: 統合テストの実行（カバレッジ測定付き）
- `make coverage`: カバレッジレポートの表示

devFlow.yaml（主要ステップ抜粋）

name: "AI駆動開発"
description: "Makefileと連携した効率的な開発フロー"

steps:
- name: "requirement_analysis"
  prompt: >
    あなたはAIを活用したプログラミングの要件定義支援エキスパートとして、開発案件の要求分析を行います。
    利用者から共有された要件内容を体系的に整理し、必要に応じて追加の情報を求めながら、
    最終的には明瞭かつ簡潔な日本語の指示書を作成します。
    
    要望は"documents/Request.md"に保存されており、そこから要件を抽出します。
    作成したドキュメントは.md形式で"documents/requirements"に適当な名称で保存してください。

- name: "implementation"
  prompt: >
    要件分析に基づいて、実装とセルフレビューを行います。既存のGoプロジェクト構造に従って実装してください。
    
    ## 実装内容：
    - 使用するプログラミング言語: Go
    - フレームワーク: 既存プロジェクトのEcho framework
    - データベース設計: 既存のPostgreSQLスキーマに従う

パターン②：設計書経由パターン

要望から設計書作成を行った後、実装・テスト・PR作成を行う方法です。

ドキュメント構成

パターン①に加えて、設計書格納用のディレクトリを用意：

documents/
├── Request.md
├── Readme.md
├── devFlow.yaml
├── requirements/    # 要件定義書
├── design/         # 基本設計書
├── implementation/ # 詳細設計書
└── test/          # テスト仕様書

人が行う作業

1. Request.mdに実現したい要望を記載
2. 最初にReadme.mdを参照するように指示
3. 設計書完成後、PRを作成してレビューを実施
4. レビュー対応後、設計書を元に実装を指示
5. 必要に応じて追加の指示を行い、PR作成まで見守る

主要なドキュメント内容

Readme.md（抜粋）

# AI駆動開発 手順書

**フロー**: 要件定義 → 設計 → テスト仕様 → 実装・テスト → 品質確認 → PR

## 実行手順

### Step 1: 要件定義・設計フェーズ
1. `requirements_definition` - 要件定義
2. `api_design` - API設計  
3. `test_specification` - テスト仕様書作成

### Step 2: 実装・テストフェーズ
4. `implementation` - 実装
5. `test_implementation_and_execution` - テスト実装・実行
6. `comprehensive_review_and_pr` - 包括的レビューとPR作成

## 品質保証のポイント
- Makefileを活用したテスト実行
- モック・ドキュメント更新の自動化
- PR作成時の適切なテンプレート使用

devFlow.yaml（主要ステップ抜粋）

name: "AI駆動開発"
description: "要件・設計を重視した高品質開発フロー"

steps:
  - name: "requirements_definition"
    prompt: >
      要件定義支援エキスパートとして、要求分析を行い明瞭な指示書を作成します。
      documents/Request.mdから要件を抽出し、documents/requirementsに保存してください。

  - name: "api_design"  
    prompt: >
      要件定義をもとに、RESTful APIの詳細設計を行います。
      APIエンドポイント、HTTPメソッド、パラメータ、レスポンス形式等を設計し、
      documents/designに保存してください。

  - name: "implementation"
    prompt: >
      設計書に基づいてコードの実装を行います。
      既存コードベースとの整合性確認、段階的な実装、セルフレビューを実施してください。

4. 実施結果

1サイクル目：課題の洗い出し

まず事前準備なしで各パターンを実施し、課題を洗い出しました。

実施結果

共通の成果

• 各パターンとも要望に沿った形で既存リポジトリを解析し、最低限の出力処理を実装
• パターン①の方が実装力が高く、部品構造の繰り返し処理まで実装

共通の課題

• endpointが設定されておらず、動作確認不可
• クエリの項目名称が異なり、正しい値を抽出できない
• 環境構築がされておらず、自動テストが実行されない
• testファイルの配置場所がリポジトリ構造と異なる
• パターン②でGoのバージョンが変更される

パターン別の評価

• パターン①: 製品の部品構造まで繰り返し処理を実装し、高い実装力を発揮
• パターン②: ドキュメントは期待通りだが、実装がドキュメントの設計に未達

2サイクル目：事前準備と再実施

1サイクル目で洗い出した課題に対して、以下の事前準備を実施しました。

対策内容

Devinのknowledge機能で以下を登録

• CFPCの環境構築指示
• テーブル情報をリポジトリ内のCREATE文から確認する指示
• testファイルの置き場所指示
• プロファイルを変更しないよう指示

各パターンのドキュメント調整

• 課題に基づきReadme.md、devFlow.yamlを修正

パターン①の評価結果

実施手順

1. 初回チャット開始：環境構築とReadme.mdに従った実装を指示
2. endpointの仕様をfrontendと合わせるよう変更依頼
3. 自動テストが実行されない場合に実行を指示

評価

Good

• CSV出力機能の主要処理が実装完了
• 部品データの繰り返し取得処理も実装
• 共通課題をほぼクリア：
  • testファイルが指定場所に配置
  • APIエンドポイントの定義完了
  • 環境構築後にmake integration-test実行
  • SQLクエリのフィールド名が概ね正しく設定

Bad

• クエリにテーブル名未指定、存在しない項目の取得試行、値の空文字・ハードコーディングにより500エラー発生
• コードベース実装のため、不具合調査に比較的労力が必要

パターン②の評価結果

実施手順

1. 初回チャット開始：環境構築とReadme.mdに従った設計を指示
2. 1回目のPR作成で設計書をレビュー・改善
3. 設計書完成後、これを元に忠実な実装を指示し、2回目のPR作成

評価

Good

• 設計書が意図通りであれば仕様通りの実装を確認
• 3テーブル利用において、テーブル名確認後に適切なモデル名を命名
• 各設計書が適切に記載され、レビューが実施しやすい

Bad

• 一部の値を正常に取得できない
• 出力ヘッダが意図と異なる実装（設計書段階で確認可能だったがレビュアーの確認不足）
• testファイルが指示と異なる場所に配置
• プロファイルの変更が発生

5. まとめ

検証結果

• 事前準備の効果: 1サイクル目で洗い出した課題への対応により、不具合発生率を大幅に抑制
• 仕組み化の必要性: プロンプトのみでは対応困難な課題があり、ワークフロー等での防止策が必要
• パターン比較:
  • パターン②は正確な処理を実装し、不具合を比較的抑えることができる
  • パターン①はレビュー不要で簡単に叩き台を作成するのに適している
• レビューの負荷軽減: パターン②では設計書を自然言語で確認でき、レビューの敷居と負荷が軽減
• 目的達成: 要件のハンドリング・レビューは人が行う必要があるが、主な実装の大半はDevinで実行可能

よって既存プロジェクトに導入するには用途にもよりますが、今回の検証テーマである「Devinを使った開発工程の標準化」と照らし合わせると、パターン②（要望→設計書→実装→PR作成）が適しているのではないかと考えられます！

今回提案した手法は「documentsディレクトリをテンプレートとして作成し、既存プロジェクトにポン付けするだけで利用することができる」というものなので、一度型を作ってしまえば他プロジェクトへ流用することも容易にできるのではないかと思います。

またknowledge suggestions機能により、対象プロジェクトに対してDevinがさらに最適化されることが期待できるため、試行回数を増やしてより良いフィードバックを提供することが重要です！

6. 感想・今後の方針

今回は「Devinを使った開発工程の標準化」をテーマに、誰でもDevinを使いこなす最初の一歩とすることを目指して取り組んでみました。

事前準備は少し大変かもしれませんが、今回提示したパターンを軸として、必要なプロンプトも生成AIを利用して用意することで、既存プロジェクトへの導入も可能になるのではないかと思います。

今後の方針

以下の仕組みを導入することで、さらなる効率化を進められるのではないかと考えています。

• CI/CD連携: 自動テストのCI/CD実行、および失敗時のDevin通知処理
• AIレビュー: AIレビューエージェントの導入
• 複数リポジトリ対応: 複数リポジトリ間の整合性を保ちながらの機能開発・不具合修正
• ローカル環境対応: documentsをリポジトリに配置するだけで、ファイルにアクセスできるAIツールでも同様の成果を得られる可能性

Devinを様々なタスクで継続的に使用し、チーム全体の開発効率向上に貢献していきたいと思います！

---

最後までお読みいただき、ありがとうございました！
この記事が皆様のDevin導入の参考になれば幸いです🙇‍♂️