Devin活用を5ヶ月間やってみた結果を時系列順に振り返る

はじめに

弊社開発Tでは2025年6月あたりからDevinを導入し、5ヶ月ほど経ちました。
ようやくDevinの使い方が自分の中でなんとなくわかってきた感じがしてきたので、
この記事では、私（[e-mail] / @kenkenkengo）がDevinを触ってきた際の実際のデータに基づき、時系列で振り返りを行ったものとなっています。

対象期間: 2025年6月頭〜2025年10月末
分析対象: 9個のプロジェクト

※因みにこの記事内のデータは全てDevinの力を借りて算出しています。
※データは全て私とDevin間のデータであり、開発T全体のデータではありません

---

目次

1. Devin活用の進化タイムライン
2. フェーズ1: 初期実験期（2025年6月〜7月）
3. フェーズ2: イベント駆動開発期（2025年7月〜8月）
4. フェーズ3: PR活用本格化期（2025年9月）
5. フェーズ4: 成熟・体系化期（2025年10月〜現在）
6. 各進化ポイントを経て得たDevinの活用方法まとめ

---

Devin活用の進化タイムライン

全体統計

合計: 97 Devin PRs

フェーズ	期間	主要プロジェクト	Devin PR数	特徴
フェーズ1	2025年6月	Project D	1	初期実験
フェーズ2	2025年7月〜8月	Project F, G, H, I	27	短サイクルPR
フェーズ3	2025年9月	Project C, E	23	PR活用本格化
フェーズ4	2025年10月〜現在	Project A, B	46	成熟・体系化

プロジェクトマッピング

プロジェクト名	技術スタック	用途	開発期間
Project A	Rails 8 + Nuxt 3 + AWS IVS	WebRTC配信システム（IVS版）	2025年10月〜現在
Project B	Rails 8 + Nuxt 3 + SDK-B	WebRTC配信システム（SDK-B版）	2025年10月〜現在
Project C	NestJS + DDD + Vue 3	業務オペレーション支援システム	2025年9月〜現在
Project D	Next.js + TypeScript	デジタルサイネージ	2025年6月
Project E	サーバーレス + DynamoDB	来場者向け情報配信システム	2025年9月
Project F	React + AWS Cognito + DynamoDB	Q&Aサイネージ（SUMMER SONIC 2025）	2025年7月〜8月
Project G	React + Threads API + DynamoDB	投稿検閲システム（SUMMER SONIC 2025）	2025年8月
Project H	Next.js + TypeScript	ランディングページ（SUMMER SONIC 2025）	2025年8月
Project I	React + TypeScript	フォトブースアプリ（SUMMER SONIC 2025）	2025年8月

---

フェーズ1: 初期実験期（2025年6月〜7月）

概要

• 期間: 2025年6月〜7月（6月に試行開始、7月に初PR）
• 主要プロジェクト: Project D（デジタルサイネージ）
• Devin活用: 1 PR
• 特徴: 小規模な修正での実験

実際の活用事例

Project D - テキスト修正（PR #1）

日付: 2025年7月29日
内容: ノベルティ交換テキストメッセージの更新

使用したプロンプト:

「ノベルティ交換のテキストメッセージを更新してください」

学び:

• シンプルな修正から開始
• プロンプトが簡潔すぎて詳細が不明
• Devinに依頼する前に何のタスクを依頼すべきか考えすぎており、そもそもの試行回数が少なかったので統計データすらほとんどない状態だった

---

フェーズ2: イベント駆動開発期（2025年7月〜8月）

前期間ではDevin活用に関するデータの母数が少なすぎたので、とりあえずうまくいかなくても良いからタスクどんどん依頼するか〜といったマインドで取り組みました。
そうすると、ここから軌道に乗り始めました。
タスク依頼するとPRが勝手に出てくるのが思ったより楽で気持ちよくて体験が良いので、楽しさが芽生え始めてきたのです。

概要

• 期間: 2025年7月〜8月
• 主要プロジェクト: Project F, G, H, I（SummerSonic 2025イベントシステム群）
• Devin活用: 27 Devin PRs（全90 PRs中）
• 特徴: 短サイクルPRワークフロー（イベント期限に合わせた迅速な開発）

背景:
この時期のプロジェクトは、2025年8月に開催された「SUMMER SONIC 2025」で実際に使用されたプロダクト群です。Threads APIを活用したインタラクティブなデジタルサイネージシステムとして、来場者とアーティストをつなぐ体験を提供しました。

参考: SUMMER SONIC 2025にてThreads APIを活用したインタラクティブなデジタルサイネージを提供

短サイクルPRワークフローの特徴

特徴:

• 小さく頻度の高いPR（UI調整や小規模機能を1PRに）

イベント開発の特性:

• 厳しい納期（SUMMER SONIC 2025イベント向け）
• 複数ステージ・複数画面の並行開発

Project F（Q&Aサイネージ）- 14 Devin PRs

主要なDevin PR:

PR #33: Threads認証システム移行

• DynamoDBトークンストレージへの移行

PR #37, #38: マルチステージ対応

• Pacific、Mountainなど各4ステージ画面追加

PR #40: 時間指定機能

• since/until パラメータによる投稿フィルタリング

使用したプロンプトパターン:

「Marine/Sonic/Pacific/Mountain各ステージ専用の画面を追加してください。
各画面は異なる解像度に対応する必要があります：
- Marine: 〇〇x〇〇px
- Sonic: 〇〇x〇〇px
- Pacific: 〇〇x〇〇px
- Mountain: 〇〇x〇〇px

Project G（投稿検閲システム）- 6 Devin PRs

主要なDevin PR:

PR #10, #14: 認証システム移行

• DynamoDBトークンベース認証への移行

PR #11, #12: キーワード選択UI & ページネーション

• 管理画面の投稿一覧ページネーション実装

PR #28: パーマリンク機能

• 単一投稿ページの実装

Project H（ランディングページ）- 6 Devin PRs

主要なDevin PR:

PR #3: Powered by フッター追加

• フッター追加

PR #6, #7: ASK ME ANYTHING & IN OUT CAMERAセクション

• 各セクションのステップ説明実装

PR #8, #10: デザイン調整

• SP表示の改行削除など細かい調整

Project I（フォトブースアプリ）- 1 Devin PR

主要なDevin PR:

PR #16: テーマカラー & overscroll修正

• モバイルブラウザのテーマカラーとoverscroll動作の修正

この時期の進化ポイント

• 文言修正などの簡単な修正タスクはDevinを活用できることがわかってきた
• 一つ出来上がった機能を横展開するタスクはDevinを活用できることがわかってきた
  • 各ステージ画面デザインの横展開
• リポジトリを跨いだ横展開タスクでDevinを活用できることがわかってきた
  • 一つのアプリの管理画面デザインや機能を別のアプリへ横展開
• 少し複雑なタスクの依頼もやってみる機会が増えた（DynamoDBトークンベース認証への移行など）
• 何も無い状態から新規機能開発をするようなタスクにおいてはDevinを活用し辛いことがわかってきた

---

フェーズ3: PR活用本格化期（2025年9月）

本期間は横展開系のタスクは少なかったのですが、業務系システム制作を行う期間だった事もあり、バグ修正系のタスクが多かったです。こちらもとりあえずDevinに依頼するか〜のマインドでやると、いい感じにDevinが実装してくれたりしたので、試行回数がまた増えた期間となりました。

概要

• 期間: 2025年9月
• 主要プロジェクト: Project C（業務オペレーション支援システム）、Project E（来場者向け情報配信システム）
• Devin活用: 23 PR
• 特徴: PRワークフローの本格採用、複雑なビジネスロジック

Project C（業務オペレーション支援システム）- 21 PR

重要なPR事例

PR #391: 属性重複表示のグルーピング不整合
日付: 2025年9月25日

使用したプロンプト:

「管理画面で同じ属性値が重複して表示される問題を修正してください。
特定の条件を選択すると、同じ属性値が複数回表示されます。

以下を確認してください：
1. フロントエンドのグループ化ロジック
2. バックエンドAPIの返却データ
3. フロントエンドでの重複排除処理

破壊的変更になる可能性があるので、影響範囲をPR説明に詳細に記載してください。」

PR #447: ワークフロー完了後の画面遷移見直し
日付: 2025年10月1日
内容: ORDERS_VIEWからVERIFY_VIEWへの遷移変更

使用したプロンプト:

「ワークフロー完了後の画面遷移を変更してください。
現在: ORDERS_VIEW（次ステップ画面）
変更後: VERIFY_VIEW（確認番号入力画面）

テスト追加の本格化

PR #373: テスト追加
日付: 2025年9月24日〜25日

使用したプロンプト:

「管理画面のテストを追加してください。
以下のテストケースを含めてください：
1. 時刻境界（JST深夜/ゼロ埋め）のテスト
2. CSVエスケープの境界値テスト
3. ExportProductCsvUsecaseのテスト

Project E（来場者向け情報配信システム）- 2 PR

PR #23: localStorageからDynamoDBへの移行
日付: 2025年7月30日

使用したプロンプト:

「初回アクセス検出の実装をlocalStorageからDynamoDBに移行してください。

現在の問題：
1. ユーザーがブラウザデータをクリアすると初回扱いになる
2. 異なるブラウザ・デバイスで初回扱いになる
3. サーバー側でアクセス履歴を管理できない

実装方針：
- フロントエンドのlocalStorageロジックを削除
- バックエンドにcheckIfFirstAccess()関数を追加
- DynamoDBにユーザーIDとアクセス履歴を保存
- 初回アクセス判定をサーバー側で実行」

この時期の進化ポイント

• 前期間とは違い、バグ修正タスクを依頼する回数が増えてきた
• テストコード作成も依頼し、品質保証を一部Devinに任せる意識が芽生えてきた

---

フェーズ4: 成熟・体系化期（2025年10月〜現在）

成熟は言い過ぎだと思うのですが、Devinが書いてくれた文言なのでそのまま使用することにします。

この期間の開発は、2つのリポジトリ間でデザイン・主要機能の同期を図るというタスクがメインでした。片方の新リポジトリは本番運用したことがなかったので、旧リポジトリも新リポジトリに合わせておく事でいざという時のリスク管理をしておくのが目的です。

これまでの経験から、リポジトリ横断タスクはDevinの得意とするところだとわかっていたので比較的スピーディに開発する事ができました。

概要

• 期間: 2025年10月〜現在
• 主要プロジェクト: Project A（WebRTC配信 - IVS版）、Project B（WebRTC配信 - SDK-B版）間において、デザインや主要機能に差分が無くなるよう同期する
• Devin活用: 46 PR
• 特徴: ドキュメント重視、コードレビュー、体系的な改善

Project A（WebRTC配信 - IVS版）- 12 PR

ドキュメント作成の体系化

PR #134: 切断パターンのドキュメント化
日付: 2025年10月19日
内容: 1,118行の詳細ドキュメント作成

使用したプロンプト:

「WebRTC配信システムの切断パターンと接続ルールに関する
包括的なドキュメントを作成してください。

以下の項目を含めてください：
1. 切断パターンの分類と対処法
2. 接続ルールと制限事項
3. VIPユーザーの特別扱い
4. エラーハンドリングの方針
5. 実装箇所のファイルパスと行番号

既存のコードを詳細に分析し、実装に基づいた正確な
ドキュメントを作成してください。」

PR #100: WebSocket over HTTP localhost
日付: 2025年10月15日

使用したプロンプト:

「ローカル開発環境でActionCableを使用する際、ngrokを経由する必要があり
開発効率が低下しています。

現在の問題：
- ActionCableがWebSocket (wss://)を要求
- ngrokを使用してHTTPSトンネルを作成する必要
- 毎回ngrokを起動し、URLを環境変数に設定する手間

Project B（WebRTC配信 - SDK-B版）- 34 PR

クリティカル問題の発見と修正

PR #33: VIPサムネイル表示バグ
日付: 2025年10月20日

使用したプロンプト:

「VIPユーザーのサムネイル表示に関する問題を修正してください。

問題：
1. VIPユーザーのサムネイルが一般セクションに表示される
2. VIPサムネイルを「選択済み」にすると一般セクションに移動する

Project Aの実装を参考にしてください。
特にhandleMetadataUpdate関数でのVIP保持ロジックを確認してください。

この時期の特徴

1. ドキュメント重視

   • 1,000行超の詳細ドキュメント
   • 実装に基づいた正確な記述
   • ファイルパスと行番号の明記

2. リポジトリ比較

   • Project AとProject Bの実装差分を活用
   • 類似実装からの学習
   • 一貫性の確保

この時期の進化ポイント

• リポジトリ間の同期（横展開）が目的のため、ほとんどのタスクをDevinに任せることができた
  • ローカルでAIを使用してリポジトリを跨いで開発するよりも、効率良く開発を進めることができた実感があった
  • 依頼するタスクの内容によっては並列実行で依頼し、複数人の部下とやりとりするかの如くPRのマージまで導く事ができたものもあった
• リポジトリ間のSDKの違いによる実装上の仕組みの違いをDevinに認識させた上でドキュメントの整備を行えたので、より精度を高めることができた

---

DevinセッションでのPR分析

概要

フェーズ4（2025年10月〜現在）では、Devinを活用したPR分析の実施も行いました。
GitHub上のPR欄をDevinとの会話で汚したくなかったので、あくまでDevinセッション内でPR分析を行う形とし、好き勝手Devinと会話して問題や質問事項を深掘りしていくスタイルとしました。
そうすると、クリティカルな問題を見つけやすくなったのと、根拠ある情報を仕入れやすくなったので、記載していきたいと思います。

クリティカル問題の判定基準

クリティカルと判定される問題の特徴:

1. 影響範囲が広い - 複数のユーザー、複数の機能に影響する
2. 再現性の難度が高い - 特定の条件下でのみ発生する
3. 運用リスクがある - 接続数制限、パフォーマンス劣化、セキュリティリスク
4. CI/Lint/TypeCheckを通過 - 静的チェックでは検出できない実行時の問題
5. データ整合性に影響 - 状態遷移、メタデータ更新、ドメインルール違反

問題発見のパターン分析

DevinセッションでのPR分析から、問題発見が確認された例をいくつか記載します。
これらの観点でDevinに仕事をさせると良いのかもしれませんね。
※ソースコードの中身まで具体的には見せられず抽象的な内容で申し訳ありません

パターン1: データ契約（DTO、API仕様）の不整合

特徴: バックエンドとフロントエンド間のデータ契約（DTO、API仕様）の不整合

Devinの分析テクニック:

• バックエンドのAPIレスポンス形式とフロントエンドの期待値を比較
• DTOの型定義とフロントエンドの使用箇所を横断的に確認
• データフローを追跡し、変換・グループ化ロジックの配置を検証

決め手となるシグナル:

• フロントエンドで複雑なデータ変換を実行している
• バックエンドのAPIが「生データ」を返している
• 同じ変換ロジックが複数箇所に重複している

パターン2: 状態同期・メタデータ更新の不整合

特徴: 複数コンポーネント間での状態管理、メタデータ更新時の整合性問題

Devinの分析テクニック:

• メタデータ更新イベントの伝播経路を追跡
• DOM操作とクラス管理の整合性を確認
• 状態遷移時の条件分岐を網羅的にチェック

決め手となるシグナル:

• メタデータ更新時にクラス属性が失われる
• 特定の状態遷移で要素が意図しない場所に移動する
• VIP/一般などの区分が保持されない

パターン3: インフラ・環境設定のドリフト

特徴: 開発環境と本番環境の設定差異、環境依存の動作問題

Devinの分析テクニック:

• 環境別設定ファイル（development.rb、production.rb）を比較
• フロントエンドとバックエンドの環境変数を横断確認
• 開発ワークフローの効率性を評価

決め手となるシグナル:

• ngrokなどの外部ツール依存
• WebSocket接続でHTTPS必須になっている
• 環境変数の設定が不統一

パターン4: セキュリティ・アーキテクチャ設計

特徴: クライアント側での状態管理の信頼性問題、アーキテクチャレベルの判断

Devinの分析テクニック:

• データの永続化場所（localStorage vs サーバー側DB）を評価
• ユーザーデータの信頼性要件を確認
• クライアント側とサーバー側の責務分離を検証

決め手となるシグナル:

• localStorageに重要なビジネスロジックの状態を保存
• ブラウザデータクリアで動作が変わる
• 異なるデバイス間で状態が同期されない

パターン5: ドメイン不変条件違反

特徴: ビジネスルール、状態遷移、集約ルールの整合性問題

Devinの分析テクニック:

• @rule-/@flow-アノテーションからドメインルールを抽出
• 状態遷移図を作成し、許可されない遷移を特定
• ビジネスロジックの配置（フロントエンド vs バックエンド）を評価

決め手となるシグナル:

• 画面遷移が不自然
• 状態の組み合わせが矛盾
• ドメインルールがコード内に散在

この時期の進化ポイント

• PRを手元にpullしてから動作確認したりAIと会話してレビューする時間がすぐに取れない時が多いので、Devinセッション上でDevinと会話して、すぐにクリティカルな問題を見つける動きができるようになった
• 複数のPRを跨いだ分析を行うことが可能なのと、過去のPRも自動で参照して回答をくれたりするので、以前よりも根拠となる情報を仕入れやすくなった
• GithubCopilotよりも多くの問題点を一気に出してくれる傾向にあることがわかった（※あくまで2025年10月末時点です）

---

各進化ポイントを経て得たDevinの活用方法まとめ

• 既存の資産をベースにした修正や横展開のタスクで力を発揮する
  • 機能・デザインの横展開
    • 一つ完成した機能や画面デザインを横展開する作業
    • リポジトリを跨いだ横展開も得意（例：Aアプリの管理画面機能をBアプリへ移植）
• PRレビューの前にDevinでPR分析を行いクリティカルな問題を発見し、会話して色々調査しながら根拠となる情報を仕入れる
• 逆に0から何かを作り上げる際は、ローカルでClaudeCodeなどのAIとやりとりした方が効率良い

最後に

今はDevinが私の相棒になりつつあります。
とりあえず良い回答が返って来たら良いか〜くらいのテンションで依頼すると、意外と時間の無駄にならないものですよ。
本記事を読んでいただいた皆様に、もっとDevin使ってみようかなと思ってもらえると私としては嬉しいです。