ソフトウェア開発の現場では、AIを活用した開発支援ツールへの注目が年々高まっています。
（たぶん）1年ほど前はCursorを使っているエンジニアも今ほどは少なく、OpenAI DevDayでデモを行なったOpenAIのエンジニアがCursorをエディタとして利用していたことが話題になったのを覚えています。
そして、2024年12月についにリリースされた「Devin」は、AIチームメイトの名の通り、まるでチームの一員として自律的に動く点が特徴とされています。
弊社も検証のためにDevinをトライアルしていますが、新人エンジニアを育成するように少しずつタスクを与え、フィードバックを繰り返していくうちに、Devinがどんどん機能してくれるようになる――そんな“育成ゲーム”のような手応えを感じています。
本記事では、月500ドルという導入コストを見合う形で活用するにはどうすればいいのか、Devinを少しでもオンボーディング・活躍してもらうために、1週間でデフォルトの利用制限を超過するほどには使い込んでみての、絶賛試行錯誤中の取り組みや“2025年1月時点”で思うことを共有します。
Devinについて
Devinの概要はUbieさんのテックブログ記事が詳しいです。
とても簡潔にまとめると、AIソフトウェアエンジニアと謳っていた通り、ソフトウェア開発のタスクを自律的に行なってくれるAIエージェントなサービスです。
Slack上でやり取りも出来ますし、PRにコメントをしたら勝手にフィードバックを受け取って、修正してくれたりもします。
コンテキストを適切に与え、適切に制限する
Devinが正しくタスクを遂行するためには、タスク自体の要件に加えて、特にプロジェクト全体の情報や固有の設計意図、ルールをしっかりと共有する必要があります。
一方で、過剰な情報を与えすぎると誤解の原因にもなるため、必要な情報のみを明確に伝えつつ、不要な情報は制限するのがポイントだと感じています。
適切なコンテキストの提供と同時に、コンテキストの制限も、Devinと上手く働くためのコツだと捉えています。
（制限はまだ手探りで、まだ上手い方法・仕組みは考え切れてはいません。）
Devinに合わせたタスク分割と事前準備
Devinの公式ドキュメントでも「タスク分割」が言及されており、明確な要件やテスト方法の提示、ジュニアレベルのタスクに分割してあげると成果物の精度が上がりやすいと明言されています。
https://docs.devin.ai/learn-about-devin/prompting
私は下記のような準備を行なった上で、Devinに指示していましたが、逆に言うとこれ以上に深く事前準備はしないことが多かったです（本当はここもDevinと一緒に上手く協働したい）
-
（必要に応じて）Perplexity / DeepResearhで情報収集
- 関連する既存実装や事例を探しておく
-
CursorでAlloy/UMLなども用いて要件定義・モデリング
- テキストだけでなく、大まかなドメイン構造やクラス構成を図示してみる
-
o1 proで構造化・レビュー
- フォーマットやテンプレに合わせて、加工・整形してもらったり、ツッコミを入れさせてみたり
他にも要件定義に特化したAIツールの活用や、典型的な“軽めなタスク”をPlaybook機能でテンプレート化してしまうのも効果はあるでしょう。
それこそ人間がテストケース/コードを事前に書いて、Devinにテストを通過させるようにコードを書かせるスタイルの“TDD“ みたいなペアプロ?も実現できそうです。
タスク分割の具体的なtipsに関しては、Prompting Adviceとして公式にドキュメント化されています。
︎（筆者は散々遊び倒した後に、ドキュメントの存在に気づきました）
基本構造
| 要素 | 説明 | 例 |
|---|---|---|
| What | 達成したいタスクの具体的な説明 | "Java 7からJava 8へのプロジェクトのアップグレード" |
| How | タスク実行時の制約や方針 | "非推奨のJava 7 APIを特定し、Java 8の同等機能に置き換える" |
| Result | 期待される結果や確認方法 | "テストスイートが全て成功し、Java 8設定でビルドが通ること" |
それ以外にもタスク選定、進捗確認のコツなどが提示されています。
| 観点 | ポイント |
|---|---|
| タスク選定 | ・自動検証可能な明確な成功基準 ・ジュニアエンジニアレベルの適度の複雑さと明確な境界 ・同様の変更を複数回適用するような反復的な要素 ・参考にできる既存の例やパターン |
| 進捗確認 | ・テストスイート実行や特定の検証基準の達成 ・検証可能なステップへの分割とチェックポイント設定 ・データ検証例：「500行以上、必要なカラムの存在」 ・API検証例：「ステータス200、必須フィールドの存在」 |
| 協働のコツ | ・複雑なタスクは小さく分割し、必要に応じて複数セッションに ・具体的な指示と必要なリソースの明示 ・繰り返しタスクはPlaybookとして再利用可能に ・チームメイトと同様の対話的なコミュニケーション |
形式手法（Alloy）で仕様をドキュメント化する
複雑なドメインモデルの仕様は、どうしても抜け漏れや変更が生じやすいもの。そこでAlloyという形式手法を用いて仕様を明確に定義し、Devinに参照させるようにしています。
Alloyを使うと、制約条件や仕様を形式的に表現できるため、コードを生成するAIにとって“外せないルール”を明確に示すことが可能になります。
実装やテストコードの自動生成の際に「Alloyで定義したルールを守ってほしい」と指示を追加するだけで、“ドキュメント×Devin” の連携がスムーズになる印象です。
形式手法（Alloy）については、弊社大平の記事をご参照ください（私も大平さんの記事でAlloyを知りました）
Alloyを活用した実務フローの例
-
1. ドメインモデルをAlloyで定義してdocsディレクトリに格納
仕様の抜け漏れや変更が発生しがちな箇所も、Alloyの制約で明確化。 -
2. Devinに対し“Alloyの仕様を守る”よう依頼
新たに実装するクラスやテストコードを生成させる際、Alloyのルールを参照させる。 -
3. テスト失敗や不整合が発生したらAlloyに立ち返って修正
もしDevinが間違ったコードを出力した場合でも、Alloyの仕様を見直して指示を再送すると、より正しい修正が得られやすい。
実際、ドメインモデルやユースケースクラスをDevinに読み込ませ、「まずAlloyで仕様を考えてから開発を進めてほしい」 と指示すると、重複実装や誤解が大幅に減ったように感じています（主観）
もちろん100%完璧ではありませんが、事前の仕様定義を厳密にしておくことで、コード生成に活かしやすくなるのは確かであり、一つのHowとして試しています。
（新規クラスを作る際にまずAlloyで仕様を考えさせるだけでなく、既存コードを読ませて、Alloy自体もDevinに生成させたりも）
Alloyではなく、UMLなどでも良いと思います。
（Alloyは制約を厳密に表現するのが得意らしく、シンプルにAlloyもキャッチアップしたかったからと言う理由で試してみている）
他にもコードコメントを工夫することで、Devinに良い感じに参照させる余地はありそうですが、こちらはまだ全然試せていません。
アーキテクチャ・モデリングの設計ドキュメントの参照
Devinが適切な実装を行うには、プロジェクトのアーキテクチャ思想やモデリング方針を理解していることも欠かせません。そこでREADME.mdやdocs/design/ディレクトリなどに、次のような形で設計ドキュメントを明確に整備しました。
src/
├── docs/
│ ├── architecture/
│ │ └── auth.md # 認証システムの設計概要
│ └── adr/
│ └── 0023-auth-strategy.md # 認証方式の設計判断
│ └── alloy/ # Alloyで定義した仕様ルール
└── README.md # プロジェクト全体の設計思想
実際、オニオンアーキテクチャの採用理由やレイヤーの責務、ドメインモデルの詳細やコンポーネント間の依存関係などをきちんと文書化してからは、素の状態のDevinと比べて、「○○Service」クラスを乱立されることが激減しました。
もちろん、どこまでアーキテクチャへの理解を深めてくれたのかは計測しづらいですが、少なくともドキュメントの充実がDevinのアウトプットを洗練させたのは確かだと感じています。
- オニオンアーキテクチャの概要や各レイヤーの責務
- ドメインモデルの詳細設計
- クラス間の依存関係
- 主要なパターンや禁止事項（例：特定のレイヤーで外部依存を持たない etc.）
こうした情報をまとめたり、Playbookで 「Devinに参照させる → 実装のたびに再度参照して確認」 のサイクルを回すことで、徐々にコードの一貫性が保たれるようになった印象です。
ADRにも地味に期待していて、「なぜこの設計を選択したのか」という判断の背景を記録しておくと、ADRに反した実装が生まれそうなタイミングでDevinが検知して、設計の意図を踏まえた上でコード生成してくれるだろうと期待しています。
まだ未挑戦ですが、RepomixのようなツールでコードファイルをまとめたものをDevinに渡す形も試したいなーとかも考えています。
Playbookによる作業の標準化
ドキュメントを充実させ、毎回Devinに目を通してもらうだけでも一定の効果はありますが、頻出する作業パターンを「Playbook」として定義することで、さらに統一された流れを作ることができます。
フローや制約を持たせるほうが、結果的に安定するケースも多いと感じているため、まだPlaybookをフル活用できているわけではありませんが、「Knowledge／Playbookを戦略的に運用する」 ことは、Devinを使いこなすうえで重要そうだと感じています。
次のような作業手順をPlaybookとしてまとめるイメージです。
-
新機能追加時の手順
- 仕様のAlloyでの定義
- ADR（Architecture Decision Record）の作成
- インターフェースの設計
- テストの実装
- 実装の完了
-
バグ修正時の手順
- 再現手順の確認
- テストケースの追加
- 修正の実装
- 関連箇所の影響確認
最終的には、「Alloyで仕様を明確化 → Alloyをもとにテストケースをレビュー or テストを自動生成」 といった形で、ドキュメントや仕組みを相互に連動させながら“良い感じのサイクル”を回していきたいと考えています。
ディレクトリ構成・ファイル命名規則を厳密に固める
Devinが必要なファイルを見つけられずに重複作成してしまうケースがしばしばありました。
たとえば「domain層にレポジトリのインターフェースがあり、infra層で実装クラスを定義する」というルールを伝えても、ファイル名のパターンが曖昧だと、Devinが同じようなクラスを何度も作ってしまっていました。
そこで、ディレクトリ構成やファイル命名規則を厳格に決め、ドキュメント化してDevinに参照させるという方法を取り入れています。たとえばインターフェースのファイル名は_interface、実装クラスは_implといったサフィックスを付けるように統一したところ、余分なクラスの生成が大幅に減少しました。
- 例：インターフェースは
xx_interfaceの接尾辞で統一 - 例：実装クラスは
xx_impl.tsのように_implで統一
こうした命名規則をREADMEやdocs等に記載し、Devinに見せるだけでも、「どこに何があるのか」を判断しやすくなると感じています。
（Devinのknowledgeで覚えさせても良い。ドキュメントのメンテナンスや違反チェックが自動で回せたら尚良し、Devinでも可）
事前に情報を渡さなければ、ドメインではなく、model、repositoryなどの技術単位でディレクトリ/ファイルを作成しがちという特徴を感じるので、それでよければ「オニオンアーキテクチャを採用しています」と一言伝えるだけでも、そこそこの構造でコードを出力してくれますが、明確なファイル名・ディレクトリ名のパターンを与えると、さらに無駄が減る印象です。
-
素のDevinが書きがちな例：
-
domain/model/-
repository/← レポジトリのインターフェースを配置xxx_interface
-
infra/-
repository/← レポジトリの実装クラスを配置
-
application/presentation/
-
成果物のレビュー容易性を高める
Devinをそれなりの粒度のタスクを任せると、一度に何千行もの変更を含むPRを提出してくることがあります。
そこまで大きなPRが出てくるのは、「タスクの分割が十分ではない」という課題の表れでもあるのですが、人間のPRレビューに支障が出るのは事実です。
実際、大抵の場合で筆者の環境では3～5セッションを同時に走らせていたため、それぞれ数千行規模のPRを大量にチェックすることになり、正直げんなりしてしまいました。
PRの変更行数を200行にしてもらう
この状況を緩和するために、まず試したのがPRを細かく分割してもらうことです。
これは「開発生産性向上」「サイクルタイムの短縮」の一般的なTipsとしても知られていますが、当たり前かもしれませんが、Devinとの協働においても有効だと感じました。
たとえば、次のような制約を設けています。
- PRの変更行数は200行程度を目安
- 単一の責務に関する変更に限定
- 依存関係の少ない箇所から段階的に実装
これに加えて、前述のようにオニオンアーキテクチャの採用やファイル命名規則、ドキュメント整備などと組み合わせることで、Devinがドメイン層→アプリケーション層→インフラ層といった順序で実装を細かく切り出し、段階的にPRを投げてくれるようになりました。
結果的に、レビューのハードルが一気に下がり、コードを追うコストも大幅に減りました。
もちろん、PRが小分けになった分数自体は増えるため、今度は「DevinからのPRが多すぎる」という感情がまた生まれたのですが、総合的には効率が良いのでお陰でDevinのPRレビューがかなり楽になりました。
Devinをフル稼働させた際のボトルネックの一つは人間によるレビューになることは想像に難くないので、Devinの成果物のレビュー容易性を高め、レビュワーの負荷を下げることは重要な観点となる気がしています。
（そもそもDevinに与えるタスクの粒度を人間側でコントロールするのが基本ではあります）
ちなみにテキストで指示するだけでたまに大きすぎる変更を投げてきますが、CIでdiff行数チェックを入れるとおそらく勝手にフィードバックを受けてPR分割してくれると思います。
DevinにADR書いてもらう
Devinがコードを生成するだけでなく、「なぜそう実装したか」という背景や選択理由を言語化させるために、ADR（Architecture Decision Record）の形でまとめさせる取り組みを行っています。
実際にはADRとは異なるフォーマットで生成しているものもあり、ADRに限定する必要もないですが、要するに 「変更理由・設計判断をPRに含める」 という運用だけでも、レビューのしやすさが変わると感じました。
とりわけ、今回は新規リポジトリ・新しい言語/フレームワークを採用していたので、ライブラリを追加するタイミングも多く、選定基準や他の選択肢との比較などはADRのテンプレートを使わせることで情報を体系的に整理しやすくなります。
（あくまでガイド・初稿であり、ハルシネーションやファクトチェックが必要ですが）
狙いとしては:
- 設計意図の言語化
- 「このライブラリ・設計を導入した理由」「トレードオフは何か」 をDevinに書かせることで、 コードレビュー時に「なぜこれを採用したのか」が一目でわかる
- Devin自身も意図を反映しやすくなり、生成時の精度が上がる（気がする）
- 理由の明文化が精度を高める
- よく言われるように、「AIに理由を出力させると精度も高まる」という効果を期待
- たとえ却下することになっても、議論のベースとして残しておくことで、後から「どうしてこの判断に至ったのか」を振り返りやすく
このように、Devinに理由や背景をアウトプットさせることで、コードだけでは拾えない設計意図が自然と共有され、レビューの容易性が上がりました。
また中長期的には、Devinにもこれら過去の背景情報を参照することでもっとコンテキストを理解した修正や提案を行ってくれるようにならないか？を期待しています。
レビュー基準の明確化とDevinの自己改善サイクル
Devinが生成するPRの品質を一定に保ち、かつレビューを効率化するため、CIチェックの拡充とDevin向けガイドラインの整備を進めています。
DevinがReflection（振り返り）と自己修正を完結的に行える環境を作り、人間のレビュー負荷を最低限に抑えることが理想像です。
-
チェックリストによる自己レビュー
- DevinがPRを提出する段階で、設定されたチェックリストを自動的に参照し、テンプレ上の要件（命名規則やアーキテクチャの依存ルールなど）を満たしているかを自己チェックします。
-
CI結果の確認と自動修正
- テストやLint、静的解析などのCIが失敗した場合、Devinはその原因を推測し、可能な範囲で自動修正を試みます。
- そのため、実行時間等のコストが許す限りチェックを増やしても良いのではと考えています
- 適応度関数のような使い方もできそう
-
アーキテクチャ違反の検出と改善
- 依存方向やレイヤー越しの呼び出しに問題がないか、自動ツール（例：dependency-cruiserやArcUnitなど）でチェックすることで、違反を検知したらDevinが自動的に修正案をPRし直してくれます。
このように、チェック → 修正 → リトライを繰り返せる仕組みを用意しておくと、Devinがある程度の“自己完結的な改善サイクル”を回しやすくなります。
（Devinのクレジットに該当するACUの消費は当然増加します...🫠）
最終的なレビューは人間が行うものの、Devinが事前に可能な限りの修正を試みることで、レビュー工数を大幅に削減できるのはメリットであるため、CIチェック等を充実させる方針はワークするかもしれません。
（このチェック項目・内容自体もADRの順守案を元にDevinに考えさせたり、実装させたりして遊んでいます）
チェックリストの活用
以下のようなチェックリストを組み込み、Devinに毎回セルフレビューと必要な修正を促す運用を試みています。
テキストベースでは厳密なチェックが難しい場面もありますが、それでもDevinは“満たしていない項目”を自動的に探し、再修正を試みてくれます。
今までの場合は、テキストベースでチェックを自動で走らせるなど実現のハードルが高かっため、個人的には結構活用の余地の存在を考えています。
ライブラリ等で実現が難しいもの、もしくはもっとふわっとした要件の実現をする上でも、テキストベースでのチェックリストはかなり面白さを感じています。
（適応度関数みたいなことが出来ると良いですね）
## セルフレビューチェックリスト（例）
### アーキテクチャ・設計
- [ ] オニオンアーキテクチャの依存方向は遵守されているか
- `dependency-cruiser`の結果を確認
- 違反がある場合は自動で修正
- [ ] ドメインモデルは外部依存を持っていないか
- [ ] インターフェースの変更は最小限に抑えられているか
### 品質とテスト
- [ ] 変更は単一の責務に留まっているか（目安200行以内）
- 超過している場合は自動で分割を提案
- [ ] テストカバレッジは80%以上か
- 不足している場合は自動でテストを追加
- [ ] 新しい型定義は適切か
- [ ] 既存のテストは全て成功しているか
- 失敗している場合は原因を分析し修正
### ドキュメントとナレッジ
- [ ] 関連するADRがある場合は更新ADRを追加したか
- [ ] 設計判断の理由は文書化したか
- [ ] 発見した新しいパターンはKnowledgeに追加したか
このようにCIやチェックリストを整備しておくと、PRレビューの早い段階でDevinが自動的に問題点を洗い出し、最初の段階で解消を図ろうとしてくれます。
結果として、人間によるレビューを始める前の 「確認・修正の下ごしらえ」 が進み、最終的なレビュー工数の削減につなげたいという意図です。
まだまだ試行錯誤の途中ではありますが、Devinへの“ガードレール”として機能するチェックリストやドキュメントの充実は、「Devinと上手く働くための重要なタスク」 になるかもしれません。
所感
Devinを使い始めて、「想像以上に楽だし、想像以上に奥が深い」 というのが率直な感想です。
何よりDevinに指示して、その間に別のタスクをこなし、気づいたらDevin側からSlackメッセージが来て、Devinへの指示出し・確認に戻る非同期な体験は想像以上に変化が起きそうな予感を感じさせます。
現時点でも任せられるタスクはいくつもあり、将来的に精度がさらに高まれば、DevinのようなAIエージェントが当たり前になった開発組織やプロセスには、さまざまな新しい可能性が広がりそうです。
実際、マイクロソフトCEOのサティア・ナデラ氏は、こうしたAIエージェントが自律的に行動し、人間に代わって業務を遂行する未来を 「Agentic World」 と呼んでいます。
Microsoft Ignite 2024の基調講演でも、「ユーザーがCopilotを通じて指示を出すだけで、舞台裏ではAIエージェントが複数連携し、あらゆる業務をサポートしてくれる世界が来る」 と語っていました。
実際に私も、Devinのタブを5つ以上同時に開いてあちこちで指示を出しながら作業を進めていたとき、「自分の代わりに動いてくれるAIエージェントと一緒に仕事をしている」 という、まさにAgentic World的な世界観を垣間見た気がします。
もちろん、まだ発展途上な面があるのは事実です。要望を明示しなかったことで余計な変更が入り込んだり、ドメイン知識の不足から的外れな提案が返ってくることもあります。
「AIエージェントがすべてを自動化してくれるから、人間は何もしなくていい」という状況はまだ先でしょうし、むしろAIエージェントが上手く動くために必要なプロセスやアーキテクチャの設計、そしてコードレベルの整備などで忙しくなりそうな気もします。
（Devin単体で考えても適切なガイドやルール、制約の中でタスクをこなさせる、そのガイドやルールを継続的にアップデートしていくアプローチが求められるのではないでしょうか）
それでも、こうしたAIエージェントがさらに普及していけば、開発現場はこれまでとは異なる新しいプロセスへと移行していくのだろうと想像します。
制約・ルールの中での自律性
Devinのことは、「適切な制約の中での自律的な判断」を行うエージェントだと捉えるべきでしょう。
「完全な自由度を持つ」のではなく、「与えられた制約の中で最適な判断をする」という方向性を取っており、制約やルールを与えるための仕組みとしてknowledgeやPlaybookなどの機能も備えています。
事前に大枠のフローやガードレールを人間が定義するほうが、業務においては安定しやすく、Devinの場合も、knowledgeやPlaybookなどで守るべきルールなどを記憶・理解しているからこそ、自律的に動ける部分が効果的に機能しているのだと感じます。
- 制約やルールは「自律性の敵」ではなく、むしろ「効果的な自律のための枠組み」として機能する
- 人間からの明示的なルール提供と、エージェント自身による学習・適用の組み合わせが重要
- 段階的な学習と改善のプロセスが、安定した自律動作につながる
Devinのための形式知、Devinによる形式知
Devinを活用するためには、“OJTのように、Devinにワークフローやドキュメントを少しずつ理解させる” というプロセスが必要だと思っています。
そのため、ドメイン知識やアーキテクチャなどのドキュメントを整備しなければならず、一定そこのコストはかかってしまうかもしれません。
しかし、そのひと手間を大きなメリットに出来ないか？と考えています。
DevinのためにドキュメントやADR（Architecture Decision Record）の整備が進めば、チーム全体の形式知が増え、開発プロセス自体がより明瞭になるからです。
究極的には、「Devinのために形式知を用意する」 ことで、Devinがさらに 「人間にとっても有用な形式知を生産」 できると素晴らしいなと考えています。
たとえば、Devinが既存のドキュメントや実装をベースに、ドメインモデルを参照して新しい実装やテストを作成し、そこに付随するドキュメント更新まで自律的に行ってくれるようになれば、AIエージェントとエンジニアが相互に知識を高め合う好循環が生まれるのではないかと妄想しています。
-
ドキュメントのギャップ検出と補完
- 既存ADRや仕様書などをDevinが参照し、実装やテストから「未更新のドキュメント部分」「不整合のある内容」を洗い出し、自動的に修正候補や追記案を提案する。
-
既存仕様変更に伴うテストコードの自動追加
- ドメインモデルやAlloy仕様の変更をDevinが検知し、必要になるテストケースを自動生成。また、関連ドキュメントに「変更時の注意点」を追記してくれる。
-
リファクタ時の依存関係マップ更新
- 「クラス構造を整理する」「責務分割をやり直す」といったリファクタに際し、Devinが全体の依存関係図や設計ルールを照合し、変更後のマップや関連ドキュメントを更新する。
-
ヘルプセンター・FAQドキュメントへの自動追記
- 新機能や変更点に応じて、Devinが「ユーザー向けFAQ」の改訂や「ヘルプセンタードキュメント」の追記案をまとめ、初稿を用意。
上記パターンはあくまで一例ですし、もっと良い何かがありそうですが、頭の中にあるのは、Devinが「人間から与えられた形式知」を活かして、さらに「新たな形式知」を作り出すというサイクルを生み出すことです。
AIエージェントとエンジニアが相互補完的に知識を高め合うことで、Devinも含めたチーム全体のドキュメントや仕様が同時に整備されていくというサイクルを生み出すきっかけになることを祈っています。
（一方で情報やコンテキストが多すぎることによる不都合は起きる可能性があるため、見直しや断捨離についても考える必要はありそうです）
短期/長期コンテキスト
エージェントにおいてメモリはコアコンポーネントの一つですが、Devinにおいてもそれは同じです。
今まで紹介した取り組みの大部分は、短期的なメモリやコンテキスト取得のコントロールはDevin自体に委ねて、基本的にはプロジェクト全体の方針などの少し長期的なコンテキスト情報の整備でした。
もしかしたらもう少し短期的な、目先のタスクにより必要なもの。という観点でもコンテキスト整備ができたら、もっとDevinをワークさせられるかもしれません。
（Playbookあたりは短期的なタスクのための情報に再利用性を持たせた仕組みの認識）
例えば、プロジェクト・ドメイン・タスク単位で情報を整理することもできそうです。
-
プロジェクト全体の制約
- アーキテクチャ設計や命名規則など、プロジェクト共通のルール
- リポジトリ全体で一貫性を保つための基盤となる制約
-
ドメイン固有の制約
- 特定の業務領域に関するルールやデータの制約
-
タスク固有の制約
- 個別の実装要件や品質基準
コンテキスト整備の評価は難しい
ここまで、「AIエージェントにコンテキスト（ドキュメントや設計意図）をしっかり伝えることが重要」という話をしてきました。しかし、実際には 「どの情報が本当に効果的だったのか」「コンテキストを与えることで、どれほど改善につながったのか」 を定量的に評価するのは難しいと感じています
例えば、
- 「Alloyで仕様を定義しておいた結果、Devinの生成コードにどの程度ポジティブな影響があったのか」
- 「オニオンアーキテクチャのドキュメントを読ませたことで、重複実装や無駄なクラスが何割減ったのか」
- 「命名規則やディレクトリ構成を厳格にしたことで、レビュー工数がどれほど削減されたのか」
といった疑問を立てても、なかなか正確な検証をやり切ることはイメージできません。
実際のところ、多くの変数が絡んでくるため、「ドキュメント整備のおかげか、たまたまDevin側で精度が改善されたのか」 すら区別しづらい面があります。
本格的に行うなら、比較的計測しやすい指標（たとえば、PRレビューでの修正回数や、同様のエラーの再発率、チャットで指示し直す頻度など）を設定し、見ていくことはありえるかもしれませんが、それを行うコスト自体も決して小さくはないため、今は「そこまで厳密さを求めなくてもいい」という判断にしています。
結局のところ、ドキュメント整備の効果を定量的に評価しにくいのは、現実世界ともよく似ています。
ドキュメント整備の成果を完全に数値化するのは難しいですが、ルールやドキュメントがあるほど新人エンジニアの混乱が減るのと同様、Devinにも最低限のガイドを与えればトラブルは抑えられるというのが、今のところの感覚的結論です。
今後、エージェント活用がより進む中で、分析ツールや比較実験といった手法やプラクティスが整えば、もう少し客観的にコンテキスト整備の価値を測れるようになるかもしれません。現時点では、「それでも整備を進めたほうが“やらないよりはいい”」 という半ば経験則的なアプローチで進めているのが実情です。
複数セッションを並行させる
Devinを“フル稼働”させて、一度に3〜5つのセッションを走らせると、「機能Aのリファクタ」「機能Bのテストコード拡充」「ドキュメント更新」「CIパイプライン修正」など、ある程度独立したタスクを同時並行で進めることができます。
人間は各セッションが進んでいる間に、別の仕事やレビュー作業を行えるにも関わらず、複数のタスクが進捗しているという夢の世界です。
（さすがに指示・レビューに追われる感じにはなります、後々）
同じファイルを触っている場合など、コンフリクトが発生したときには最悪なので、「作業範囲を明確にする」「依存関係の少ないタスクから進める」「コンフリクトしそうな変更は同時に走らせない」 など、現時点ではタスクを適切に分割・頭の中でイメージができる必要はあります。
チェックリストをテキストベースで自動修正させる
「PRチェックリストを用意して、Devinがそれに従ってセルフレビューを行い、自動修正を試みる」という仕組みは、テキストベース で処理できる点が面白いと感じています。
もともとこうしたチェックリストは、人間が読んで自分で「OK／NG」を判断するためのものですが、Devinに丸ごと読ませ、未達成項目を自動的に修正してもらうことで、レビュー前の段階で改善が進むのは大きなメリットです。
- 静的解析ツールやLintツールでは拾いにくい“ふわっとした要件” をテキストチェックリストとして書ける
- テキストチェックリストの「これを満たしていない」箇所をDevinが文脈的に推測し、PRを改変する
- 人間がレビューの段階で「どうしても曖昧な箇所」を発見した場合も、次回以降はDevinのチェックリスト自体を修正し、学習させることが可能
Devin自体にもKnowledgeという機能がありますが、AIエージェント（実質はLLM）の“テキスト解析力”をガードレールに活用する考え方は、活用の余地を感じています。
PCいらずの開発
地味に嬉しいのは、リビングや移動時間中でもスマホのSlack操作だけでDevinに“ちょっとした修正”を依頼できる点です。
ちょっとした画面修正やリファクタであれば、わざわざPCを開くことなくそのままDevinがPRを更新してくれますし、スマホで十分完結します。
さらに、CIが落ちた場合も「CIが失敗しているから直して」と細かく言わなくても、Devinが自動的に修正を試みてくれるので、Slackからの一言だけで“勝手にタスクが進んでいく”感覚を得られました。
その他
大したTipsでもないのですが、今回の検証では機能開発だけでなく、“人的リソースの制約で後回しになりがちなタスク”を優先的にDevinに任せてみる方針を考えていました。
- ドキュメンテーションの整備
- CI/CDの改善・最適化
- リファクタリング
- 静的チェックやテストコードの作成
これらのタスクは「うまく作ってくれたらラッキー」くらいの気持ちで依頼していたため、Devinが微妙なPRを出してきても、ある程度は温かい目で見守れたのはもしかしたら利点だったかもしれません。
期待値調整は大事ですね。
また、弊社では開発組織でライブラリのアップデートを定期的にまとめて行う時間を確保しているのですが、同様の仕組みでDevinに任せたいタスクを収集・開発を事前にさせておき、定期的にDevinのPRをレビューする会などを試してみたいなと思っています。
つい後回しになりがちなタスクも、Devinを活用して定期的に回せるようになれば、AIエージェントが下準備をしてくれるおかげで効率的に進められたら、文字通り儲けものだな〜とか考えています。
まとめ
まだ本格活用に向けて試行錯誤している所ですが、DevinのようなAIチームメイトとの協働が、開発プロセス全体を見直す良い契機になりそうです。
- タスクを小さく分割し、必要なコンテキストだけを与える
- 最初から、特にプロジェクト全体・固有のコンテキストを整備する
- AlloyやADRなどでドメイン知識・設計意図を文書化し、Devinに参照させる
- PR行数の制限やチェックリストを導入し、Devinが自己改善できるサイクルを整える
- “AIにとって把握しやすい形”を考えるAIフレンドリなーアーキテクチャ・プロセスの重要性
こうした仕組みを積み重ねることで、Devinのアウトプット品質とレビュー効率の両方が向上したように感じます。
まさに 新人エンジニアを育成するようにガイドやルール、制約を適切に設定し、少しずつ成長を促す 、コンテキストは整備・参照可能にしつつ、細かく軌道修正をかけながら進めるアプローチがベターと言うそれはそうだろうという結論です。
今後は、Devinと他のAI開発ツールを組み合わせた活用や、より大規模なリポジトリでの運用に取り組みたいと考えています。
個人的には兎にも角にもドキュメンテーションに活用したい気持ちは強いです。
例えば、エンジニアが1日1時間かけて行っていたドキュメント整備をDevinが代替してくれれば、月にエンジニア工数20時間分、仮に1時間あたり3000円 だとしても、500ドルの投資は十分ペイできる可能性があります。
（開発チーム全体で考えたら、1日1時間程度はソースコードの情報が必要なドキュメンテーションを行ってるでしょう、きっと）
サティア・ナデラ氏が言うように、「従業員1人とCopilot1人がいれば、1000人のエージェントを持つことができる」 時代は思っているより近くまで来ているのかもしれません。
今回は以上です！
Discussion