【Devin】タスクは細かく与えましょう。じゃぁ、どのくらい？

はじめに

みなさんこんにちは。インプルの岩崎です。

みなさん、AIエージェント使ってますか！？　弊社でもAIエージェントのDevinが導入され、勉強会の開催準備やDevinの実力調査など、色々と進めている最中です。前回も、Devinの苦手をたくさんやらせてみる記事を作りましたので、限界を知りたい方はぜひご覧ください笑。

【Devin】苦手なことを依頼してみるとどうなるの？

...

ramble.impl.co.jp

2025.06.26

さて今回は・・・？

今回のテーマは、”Devinにタスクを与える時どの程度までタスクを細かく分解すればいいか？” です。
公式ドキュメントでも、指示の出し方として、GoodパターンとBadパターンを示してくれています。

Good vs. Bad Instructions - Devin Docs

What works and what doesn't

docs.devin.ai

曖昧な指示ではなく、タスクを細かく分割して詳細に指示をしなければいけない、というのは前回の記事でも結論として少し触れたと思います。では、細かく分解して指示を出す時に、どの程度細かくして指示を出せばいいのでしょうか。

タスクの細かさ

細かく分解する、と言っても、分解しなければいけないのは２つあると考えています。まず１つ目に、みなさんが想像する一つの完成物（タスク）に対してどれだけ細かくパーツや動作ごとに指示を出すかです。

前回の検証でも、「仕様なしで社内向け日報投稿ツールを作らせてみる」ということをさせましたが、Devinは特に聞き返すことなく、平均点なツールを作ってきました。なので、これにオリジナルな機能を追加するためには、タスクを分解して指示を出す必要があります。

でも、1パーツごとに分解したり、15分程度のタスクに分解したりすればいいので、一度Devinを使ったことがある人なら、感覚で何となくわかりそうです。

issueの細かさ

続いて、もう一つの細かさは、指示を出すときにどれだけ細かく指示を出すかです。ここでは、わかりやすく全体像をタスク、個々の指示をissueということにしましょう。つまり、issueの細かさですね。

例えば、ただパーツを作るだけでも、使用技術やDB、API設計やフロントエンド構成など、さまざまな実装における指示があると思います。これももちろん細かく書くに越したことはないのですが、どの程度まで書く必要があるのでしょうか。

最低限の細かさのissue

では、issueにはどのような内容をいれるのがベストなのでしょうか。
chatGPTに聞いてみると、以下のように表にして返答してくれました。たくさんだぁ・・・汗。

項目名	内容	なぜ必要か（根拠）
技術要件（Tech Requirements）	使用すべきAPI、ライブラリ、言語・フレームワークなど（例：React + TypeScript、fetch、OpenWeatherMap API）	Devinは複数の選択肢を持つため、使用技術を明記しないと勝手に選択してしまう。これにより不要な外部ライブラリ導入やプロジェクト構成の不一致が起きる。
前提条件（Preconditions）	すでに実装済みのUI・状態・機能など（例：「SearchBarコンポーネントは存在している」）	Devinは既存コードを前提とした実装も可能だが、黙っていると「一から作ろう」とすることがある。不要なUI作成を避けるためにも前提は明記する。
実装要件（Implementation Requirements）	実装すべき関数、ファイル構成、関数名、戻り値の型、非同期処理の方法など（例：fetchWeather(cityName: string) を src/api/weather.ts に作成）	Devinは「自由に構成を組む」ことができるが、チーム開発において保守性や責務分離が重要な場合、構造レベルでのガイドが必要。関数設計や責任分離の指示がないとUIにロジックが混在する傾向がある。
UI/UX要件（User Feedback & UX Expectations）	エラー時のメッセージ内容、ローディング状態、UI表記（例：「都市が見つかりません」などの日本語表示）	Devinは基本的に「動く」ものを作るが、ユーザー体験まで気を配らないことが多い。とくにローカライズや文言指定がないと英語のままになる。プロダクト品質を意識するなら必須。
セキュリティ要件（Security Guidelines）	APIキーの.env管理、ハードコード禁止など	Devinは「短期的に動かす」には優れるが、APIキーなどの秘匿情報をうっかりハードコードすることもある。明示的にセキュリティポリシーを書くことで、正しく.env管理を導入できる。
API仕様（API Specification）	使用するエンドポイント、クエリパラメータ、unitsやlangなどの指定（例：units=metric, lang=ja）	DevinはAPIドキュメントを自動で読むこともできるが、「何を渡して何を受け取るべきか」を明記することで、期待とずれたパラメータ指定やレスポンス処理のミスを防げる。
型定義（Type Interface Expectations）	使用するデータの型（例：WeatherData型）	TypeScriptで開発する場合、型が適切に定義されているかが品質の肝。型がなければDevinはanyを多用してしまうこともあるため、型の定義は明示しておくと安心。
エラーケースの扱い（Error Handling Expectations）	存在しない都市・APIキーエラー・ネットワーク障害などの扱い	Devinは「成功パス」中心に組む傾向がある。異常系を明示しないと、UIがクラッシュしたり、無限ロードになったりする可能性があるため、具体的に書くのが安全。
最終確認事項（Definition of Done）	正常系・異常系を含めた完了判定条件（例：「東京とロンドンで天気表示でき、間違った都市でエラーが出る」）	Devinは「何をもって完成とするか」が曖昧なままだと、途中で止まる or 余計な作業を続ける可能性がある。完了基準を明記することで、明確なゴールを示せる。
テスト条件（Test Scenarios）	人間がどう動作確認すべきか（例：3都市で天気表示→エラー→APIキー誤りも試す）	Devinは自動テストを書けるが、手動確認も前提としたテストチェックリストがあると、安心してレビューできる。また、Devin自身もテストコードを用意しやすくなる。

流石にこれを全て書くのは大変ですね。もちろん、これらの項目を入れることは必要に応じて求められると思いますが、毎回書くのは大変そうです。そこで、社内ですでにDevinを使用している人や、他社さんでの使用事例を調べてみると、次の４つが重要になってくるのではないか、とたどり着きました。

技術要件（Tech Stack / Tools）

ここでは、どの言語・フレームワーク・ライブラリ・APIを使うかを、まとめる項目になります。例として、React + TypeScript、OpenWeatherMap API、fetch などですね。

技術スタックが曖昧だと、DevinはVueを使ったり、axiosを勝手に導入したりすることがあります。前回の検証でも、とにかく標準的なツールを使って平均点を目指していましたね。明示することでプロジェクトと整合性を保つことができます。

前提（Preconditions）

ここでは、すでに存在するコンポーネント、APIキーの有無など、前提条件を教えてあげる必要があります。例えば、「SearchBarコンポーネントは実装済み」「.envは設定済み」などを指示してあげるといいですね。

Devinは、AIエージェントですが、何がどこまでできているのか、前後関係を明確にする必要があります。すべてを自分で組もうとする傾向があるため、既存実装を教えておかないと、無駄なUI・処理が再作成される可能性があります。

実装要件（Implementation Requirements）

ここでは、実装すべき関数・処理・型などの構造を指示しましょう。例えば、fetchWeather(cityName: string) を作る、src/api/weather.tsに配置、async/await使用、などですね。

Devinは「設計も含めて自由に実装」できてしまうため、構造を与えないと責務分離が崩れた一枚岩コードになる危険があります。

完了基準（Definition of Done）

何ができていれば「完了」とみなすか、Devinが終わりました！と言える基準を明確に作ってあげましょう。例えば、「東京とロンドンで天気が表示され、存在しない都市ではエラーメッセージが出る」のようなものですね。

完了基準がないと、Devinは動くところで中断してしまったり、逆に余計な作業（UIの装飾やコード分割）を続けてしまう可能性があります。

最低限のissueで指示を出してみよう！

それでは、上記4つの項目を使って、指示を出してみます。ですが、今回の記事のテーマは、細かさ！　4つの項目も、どれだけ細かく書く必要があるのかも追ってみましょう。
issueをそれぞれ書いて実験する前に、chatGPTにテンプレを作ってもらいました。みなさんも書く際はこちらを参考にどうぞ！

## 🔧 技術要件
- 使用API: OpenWeatherMap
- 技術: React + TypeScript、fetch 使用（axios禁止）

## 🔗 前提
- 都市名入力UIは SearchBar コンポーネントとして実装済み
- .env に有効な API キーが設定されている

## 🛠️ 実装要件
- `fetchWeather(cityName: string)` を `src/api/weather.ts` に実装
- async/await 使用。エラー処理も含める
- 表示項目：気温、天気説明、アイコン

## ✅ 完了基準
- 正常な都市名では天気が取得・表示される
- 存在しない都市では「都市が見つかりません」と表示
- APIキーはハードコードされていない

実験では、都市名を入力してダミーの天気データを表示できるReactアプリです。これに対して「OpenWeatherMap APIを使ってリアルな天気情報を取得する」機能をDevinに実装させました。

細かさには３つの段階を設け、それぞれ曖昧・普通・詳細の３パターンでissueを与えました。

パターン	指示の粒度	特徴
曖昧パターン	超ざっくり	要件だけを簡潔に指示
普通パターン	中レベル	技術方針や構成も指定
詳細パターン	高精度	API仕様・設計方針・検証方法まで記載

曖昧バージョン

それでは最初に曖昧バージョンです。issueは以下のような形で、曖昧に出しました笑

作業中の様子は割愛しますが、結果は公平にジャッチしてもらうため、今回もchatGPTにお願いしました！　PRの内容を読み込ませて判定してもらいます。さて、どうでしょうか？

結果概要：

• App.tsx にロジックを直接記述
• APIキーの管理が曖昧、エラー処理も限定的
• ローディング状態やUX配慮も少なめ
  → 偶然「動く」けど拡張性ゼロ。保守には向かない。

GitHub - iwasakiterukazuimpl/devin_whether at 02-02

Contribute to iwasakiterukazuimpl/devin_whether development by creating an account on GitHub.

github.com

結構辛口評価ですね。偶然と捉えるのか、前回の検証結果のように平均点を狙ってきたのか・・・。

普通バージョン

続いて、普通バージョンです。ちょっとしっかりissueを書いてみました。

結果概要：

• fetchWeather関数を作成し、実装は正確
• エラー処理（404/401）やローディング状態も実装
• ただし、APIロジックがUI層に混在しがち
  → 実務水準。最小限の構造化はできている。

GitHub - iwasakiterukazuimpl/devin_whether at 02-03

Contribute to iwasakiterukazuimpl/devin_whether development by creating an account on GitHub.

github.com

ちょっとは良くなりましたね！
でも、UIがさっきと変わってないですね笑。Devinはどんどん学習をするので、もしかしたら直近でやった先ほどのissueにちょっと引っ張られているのかもしれませんね。

詳細バージョン

最後に、詳細バージョンです。ここまで書いてこの通りに作ってこなかったら逆に大変ですね笑

結果概要：

• APIロジックを src/api/weather.ts に分離
• TypeScript型定義、fetchラッパー関数、丁寧なエラーハンドリング
• .env 経由でセキュアにキーを管理
• UI/UXも考慮され、「都市が見つかりません」などの日本語表示も対応
  → プロレベルの設計・保守性・完成度。チーム開発でもそのまま使えるレベル。

GitHub - iwasakiterukazuimpl/devin_whether at 02-04

Contribute to iwasakiterukazuimpl/devin_whether development by creating an account on GitHub.

github.com

流石に詳細に書いただけあって、しっかりと作れていますね。やっぱり先ほどと同じUI笑。
今回はUIについての指示を出せていないので、あまり目に見える変化がわかりづらかったと思います。

まとめ

最終的なまとめとして、chatGPTに表にしてもらったところ、以下のようになりました。

やはり、Devinは詳細に書けば書くほどしっかりとした成果を出してきてくれます。タスクを分割することも大切ですが、issueを詳細に書くことが、今回の検証から大切さが分かったのではないでしょうか？

評価観点	曖昧パターン	普通パターン	詳細パターン
✅ 仕様理解	❌ 不十分	✅ 概ね正確	✅ 完璧
🔁 保守性	❌ 低い	⚠️ 普通	✅ 高い
🧱 構造設計	❌ UI直書き	⚠️ 分離やや不足	✅ モジュール設計
🧪 テスト視点	❌ 弱い	✅ 一通り網羅	✅ UXまで含む
💬 エラー対応	❌ 弱い	✅ 一通り実装	✅ 状況別に丁寧
🎯 実務適性	❌ 初学者レベル	🟡 中堅レベル	🟢 プロダクション水準

今回もご覧いただき、ありがとうございました！
ぱっと見でわかりづらい検証になってしまいましたが、みなさんもissueをしっかりと書いて、Devinをフル活用していきましょう！