Devinの精度が低いと感じたら見直す7点 指示文と設定でここまで変わります

Devinの精度が低いと感じたら見直す7点指示文と設定でここまで変わります

この記事のポイント 「Devinの精度が低い」と感じる場面の大半は、モデルの実力不足ではなく、渡している情報の不足で起きています。 効くのはゴール・制約・完了条件を分けて書くこと、リポジトリ固有の前提を覚えさせること、タスクを1本のプルリクエストに収まる大きさへ割ること。 この3つで結果が変わらないタスクは、そもそもDevin向きではありません。向き不向きの線引きまで表で整理しました。

朝イチで依頼したタスクが、夕方に見たら見当違いのファイルを触っていた。テストは通っているのに、求めていた挙動と違う。そんな日が続くと、月額を払う意味を疑いたくなります。

先に答えを出します。指示文の書き方と初期設定を直すだけで、体感の精度はかなり戻ります。

Devinの精度とは、依頼した内容に対して「そのまま取り込めるプルリクエストが返ってくる割合」のことです。コードが動くかどうかではありません。人間のレビュアーが手を入れずにマージできたか、その1点で測るのがいちばん実務に近い見方になります。

「Devinの精度が低い」と感じる原因は、たいてい指示文の側にあります

Devinの精度が低いと感じたら見直す7点 指示文と設定でここまで変わります 図2

依頼が失敗するとき、Devinは間違えているのではなく、足りない情報を自分で埋めています。その埋め方が人間の期待とズレる。これが精度低下の正体です。

人間の新人エンジニアに「ログイン画面を直しておいて」とだけ伝えたら、どうなるでしょうか。たぶん確認の質問が飛んできます。Devinはその確認をスキップして、もっともらしい前提を置いて走り出せてしまう。自律性の高さがそのまま裏目に出る瞬間です。

だから対処の方向はひとつ。判断の余地を減らすことに尽きます。

具体的には、次の3種類の情報を渡しているかを疑います。

  • ゴール: 何がどうなったら終わりか
  • 制約: 触ってよい範囲、使ってよいライブラリ、守るべき既存の作法
  • 完了条件: どのテストが通れば完了と見なすか

この3つのうちどれかが欠けたまま投げた依頼は、返ってくる成果物のばらつきが大きくなります。逆に3つ揃っていれば、同じタスクを何度投げても似た形の答えが返ってくる。再現性が上がる、という言い方が近いです。

指示文の粒度が結果を左右するのはコーディングに限りません。画像生成でも同じ構造の話になります。作風の指定を1行足すだけで出力が安定する例は、AIイラスト生成ツールの比較記事で扱っている生成条件の話とほぼ同じ理屈です。

精度が落ちるときによくある7パターン

Devinの精度が低いと感じたら見直す7点 指示文と設定でここまで変わります 図3

症状から原因を引き当てるための対応表です。「なんとなく質が低い」で止めず、どのパターンかを特定するところから始めます。

以下は、依頼が空振りしたときに実際にありがちな組み合わせを整理したものです。

#よくある症状実際の原因打ち手
1関係ないファイルを大量に変更する触ってよい範囲を伝えていない対象ディレクトリとファイルを明示する
2既存の書き方と違うコードを書くプロジェクトの作法を知らない参照すべき既存ファイルを1本指定する
3動くが要件と違う機能ができるゴールが動作ではなく手段で書かれている「誰が何をできる状態か」で書き直す
4途中で止まる、時間ばかり使うタスクが大きすぎる1プルリクエスト分に割る
5存在しない社内用語を勝手に解釈する用語の定義が共有されていないナレッジに用語集を登録する
6テストを書かない、または通すためだけの空テスト完了条件が「実装して」で終わっている通すべきテストを名指しする
7環境構築でつまずいて本題に入れないセットアップ手順が保存されていない環境の起動手順を先に固定する

つまり、7つのうち5つは指示文の書き方、2つは環境側の設定で潰せます。ここから順に中身を見ていきます。

指示文は「ゴール・制約・完了条件」の3点で書く

Devinへの指示文（AIへの指示文のこと）は、自由記述の依頼メールではなく、チケットの体裁に寄せると精度が上がります。3つの箱を埋める作業だと思ってください。

ゴールの書き方にはコツがあります。手段ではなく状態で書く。「バリデーション関数を追加して」は手段、「未入力のまま送信するとフォーム下に赤字でエラーが出る状態にして」は状態です。状態で書くと、実装方法の選択肢が広がったまま、ゴールだけが固定されます。

制約は、書き忘れがいちばん痛い箱。

新しいライブラリを勝手に足されて依存関係が増えた、という事故はここで防げます。「既存の依存関係に新規パッケージを追加しない」「変更は src/features/auth/ 配下のみ」と書いておけば、レビューの負担が目に見えて減ります。

完了条件は、機械が判定できる形にするのが理想です。「npm test -- auth が全部通ること」のように書けば、Devinは自分でその判定を回せます。人間の主観でしか判定できない完了条件を渡すと、Devinは無限に自信を持てないまま作業を続けることになります。

そのまま使える指示文のひな形

# ゴール
（誰が）（何を）できる状態にする。現状は（今どうなっているか）。

# 触ってよい範囲
- 変更対象: src/xxx/ 配下のみ
- 参考にする既存実装: src/yyy/zzz.ts と同じ書き方に揃える
- 新規パッケージの追加は不可

# 完了条件
- `npm run test:xxx` が全て通る
- 既存のテストを1件も壊していない
- 変更点を3行以内で説明できる

# 不明点があれば
着手前に質問してください。推測で進めないでください。

最後の1行は地味に効きます。質問させる余地を明示的に作っておくと、暴走の手前で止まってくれる確率が上がります。

どこまで細かく書けば伝わる？指示文のビフォーアフター

細かく書くほど良い、という話ではありません。判断が分岐する場所だけを潰すのが正解です。

同じタスクを2通りの書き方で比べると、どこに情報を足すべきかが見えてきます。

要素精度が出にくい書き方直した書き方
ゴール検索機能を改善して検索結果が0件のとき、代替キーワードを3件提案する表示を出す
対象範囲（書いていない）src/features/search/ 配下のみ変更
作法いい感じに実装してsrc/features/filter/ と同じフック構成に揃える
完了条件動くようにしてnpm test -- search が通り、既存テストを壊さない
例外処理（書いていない）APIがタイムアウトした場合は既存のエラー表示を流用する
質問（書いていない）仕様が読み取れない箇所は着手前に質問する

つまり、右列は左列の3倍の文字数でもなく、分岐点に1行ずつ足しただけです。全部を書き尽くす必要はありません。

書きすぎの弊害もあります。実装手順を一行ずつ指定すると、途中で前提が崩れたときに立ち往生します。何をするかは細かく、どうやるかは粗く。この配分が実務では扱いやすいバランスになります。

リポジトリ側の設定を見直す（ナレッジとセットアップ）

指示文をいくら磨いても、毎回同じ前提を書くのは無駄です。リポジトリ固有の前提は、Devin側に覚えさせて使い回します。

Devinには、プロジェクト固有の知識を登録しておく仕組みと、開発環境の起動手順を保存しておく仕組みがあります。機能名や画面構成はアップデートで変わるため、正確な名称は公式ドキュメントで確認してください。役割だけ押さえておけば十分です。

登録しておくと効くのは、この4種類。

  • 社内用語の定義: 「案件」「枠」「配信」など、コード上の名前と日常語がズレている用語
  • やってはいけないこと: 本番DBを直接触らない、この設定ファイルは編集しない、など
  • ビルドと起動の手順: 環境変数の入れ方、依存関係の解決手順
  • レビューで毎回言われること: 命名規則、コミットメッセージの形式

4つ目が特に効きます。人間のレビューで指摘した内容を、その場でナレッジに書き足す運用にしておくと、同じ指摘の再発が減っていきます。

環境構築の手順を保存する意味も大きい。Devinがセットアップで15分つまずくと、その分だけ本題に使える集中力（実際には実行時間と試行回数）が削られます。ここは一度固定してしまえば、以後ずっと効き続ける投資です。

社内のルールをAIに守らせる設計という意味では、社内監査業務のAIツール記事で扱っているチェック項目の作り方が参考になります。守らせたいルールを文章で置いておく、という発想は共通です。

タスクの切り方を変えると精度はどう変わる？

大きいタスクを1本で投げるほど、失敗したときの損失が大きくなります。切り方の基本は「1タスク = 1プルリクエスト = 人間が15分でレビューできる量」。

なぜこの大きさかというと、レビューできない量の変更は、実質的に検証されないまま取り込まれるからです。500行の差分が返ってきても、中身を読める人はほとんどいません。読まずにマージすれば、精度の問題は先送りされるだけ。

切り方の目安を、よくある依頼で並べてみます。

  • 悪い切り方: 「管理画面に新機能を追加して」（設計・DB・API・UI・テストが全部入り）
  • 良い切り方: ①DBのマイグレーションだけ ②APIエンドポイント1本 ③画面の表示だけ ④保存処理と4本に分ける

分けた各タスクは、前のタスクの成果物を前提にできます。①が終わってから②を投げれば、②の指示文は短くて済みます。

もうひとつ、並行して走らせられるタスクは同時に投げるのが効率的です。互いに同じファイルを触らないタスク同士なら、コンフリクトも起きません。ここを設計するのは人間の仕事になります。

ここまでの整理: 精度を上げる打ち手は3層あります。①指示文（ゴール・制約・完了条件）②環境（ナレッジとセットアップの保存）③タスクの大きさ（1プルリクエスト分に割る）。この順に見直すと、原因が特定しやすくなります。

着手前にDevinから質問させる、その仕込み方

Devinの質問の仕方が雑だと感じるなら、質問させるタイミングを指定していないケースがほとんどです。着手後の質問は手戻りになります。

有効なのは、実装の前にワンクッション挟ませる依頼の仕方です。

このタスクについて、実装はまだしないでください。
1. 変更が必要なファイルの一覧
2. 実装方針を3行で
3. 仕様が読み取れない点があれば質問

上記だけを返してください。方針にOKを出したら実装に入ります。

この「方針だけ先に出させる」やり方は、大きめのタスクほど元が取れます。方針の段階でズレていれば、その場で1行直せば済む。実装が終わってからズレに気づくと、丸ごとやり直しです。

質問への回答も、粒度を揃えると効きます。「たぶんこっちで」と曖昧に返すと、Devinは曖昧なまま進みます。判断を渡すなら「AとBならAで。理由は既存のCと揃えたいから」まで書く。理由を添えると、次の似た判断も同じ方向に寄ってくれます。

Slack連携を使っている場合、この往復がチャットで完結します。GitHub上のやり取りより気軽に差し込めるぶん、方針確認のクッションを挟むコストが下がる。連携を入れていないなら、ここは入れる価値があります。

テストとCIをDevinの「目」にする

Devinは自分で書いたコードを自分で検証できます。ただし、検証の基準を渡していなければ、通ることが自明なテストを書いて満足してしまいます。

だから完了条件には、既存のテストコマンドを名指しで書く。これだけで、成果物が「動くらしいコード」から「検証済みのコード」に変わります。

テストが整備されていないリポジトリでは、順番を変えるのがおすすめです。いきなり機能追加を頼まず、既存機能のテストを書かせるタスクから始める。テストが増えるほど、以後の依頼の精度判定が自動化されていきます。地味ですが、いちばん効く投資です。

プルリクエストのレビュー側にも手当てがあります。Devinには、複雑なプルリクエストを読み解くためのDevin Reviewが用意されていて、関連する変更をまとまりごとに整理したり、コピーされたコードを検出したりできます。差分が大きくなりがちな自動生成のコードとは相性のいい機能です。

とはいえ、レビュー支援が入っても最終判断は人間の側に残ります。ここを機械に丸投げした瞬間、精度の議論そのものが成立しなくなります。

それでも精度が上がらないときは何を疑う？

指示文も環境も直したのに変わらない。そのときは上から順に切り分けます。感覚で判断せず、確認する順番を固定するのが早道です。

以下の順番で1つずつ潰していくと、原因がどの層にあるかが絞り込めます。

順番確認すること見るもの直らないときの次の一手
1指示文にゴール・制約・完了条件が揃っているか依頼文そのもの3点セットのひな形に書き直して再依頼
2タスクが1プルリクエストに収まる大きさか変更ファイル数と差分の行数3〜4本に分割して順に依頼
3環境構築で時間を使っていないか作業ログの序盤セットアップ手順を保存し直す
4前提となる社内知識を渡しているかナレッジの登録内容用語集と禁止事項を追加
5参照させる既存実装を指定しているか生成コードの書き方の癖手本になるファイルを1本指定
6完了条件を機械が判定できるかテストコマンドの有無通すべきテスト名を明記
7そもそもDevin向きのタスクかタスクの性質別のツールか人間に戻す

つまり、1から6まで潰しても改善しない依頼は、7番の問題である可能性が高いということです。

Devinが向くタスク・向かないタスク

道具の適性を無視した使い方は、指示文をどう磨いても報われません。線引きをはっきりさせておきます。

タスクの型ごとに、適性と代替案を並べました。

タスクの型Devinの適性補足と代わりの選択肢
仕様が固まった機能追加高いいちばん得意な領域。積み残しの消化に向く
定型的な改修（ライブラリ更新、命名の統一）高い範囲指定さえ明確なら安定する
テストの追加高い対象を絞れば量産できる。以後の精度判定にも効く
バグ修正（再現手順あり）中〜高い再現手順がないと調査で迷走する
性能改善・原因調査中程度原因の候補を複数出す使い方が現実的
設計判断を含む新規開発低い人間が方針を決めてから分割して渡す
暗黙知だらけの既存コード大改造低いCursor や Claude Code で人間が伴走する方が速い
数行の修正低い依頼文を書く時間の方が長い。手で直す方が早い

つまり、「仕様が固まっていて、量がある」タスクが本領。逆に「考えるところから一緒にやってほしい」用途では、対話しながら書けるツールの方が噛み合います。

性能改善や原因調査のような、候補を広く集める作業では、リサーチ系AIとの併用が効きます。検索結果を整理させる使い方はFeloの活用記事で扱っている進め方が近く、調査と実装で道具を分ける発想は覚えておいて損がありません。

料金プランと精度の折り合いはどう考える？

公式の料金ページでは、Free、Pro、Max、Teams、Enterpriseの区分が案内されています（2026年5月確認時点）。金額は改定されるため、判断の前に公式ページで確認してください。

コスト面の考え方はシンプルです。Devinは、常に依頼を入れ続けられるチームでこそ元が取れる。手が空いている時間が長いほど、単価は実質的に上がります。

判断の基準を3つに絞ると、こうなります。

  • 仕様が固まった積み残しタスクが、常時10本以上あるか
  • プルリクエストをレビューする人が確保できているか
  • テストがある程度整備されているか（またはこれから整備する意思があるか）

3つとも当てはまるなら、投資として妥当な範囲です。ひとつも当てはまらないなら、個人向けの月額が安いコーディング支援ツールから始める方が、費用対効果は明らかに上。ここは見栄を張らない方が賢明です。

無料枠がある以上、まずは自分のリポジトリで数本試すのが確実な判断材料になります。他社の成功事例より、自分のコードベースでの成功率の方がはるかに参考になります。

AIツールの選定基準そのものを整理したいときは、Meta AIの解説記事のような個別ツールの機能比較より、自社の運用条件から逆算する方が失敗しません。

AI PICKS編集部の判定

Devinの精度に不満がある人の大半は、道具ではなく渡し方でつまずいています。ゴール・制約・完了条件の3点を書き分け、1プルリクエスト分に割って投げるだけで、体感は別物になります。ここを試さずに「精度が低い」と結論づけるのは、正直もったいない。

一方で、万能ではありません。設計判断を含む仕事、暗黙知が多いコードの大改造は、いまも人間が方針を決めてから渡すのが現実的です。ここを任せようとして失望している例が本当に多い。

判定としては、仕様が固まったタスクが常時溜まっているチームには重宝する、それ以外には正直イマイチ。個人開発者や、仕事の大半が試行錯誤で構成されているチームなら、対話しながら書けるツールの方が噛み合います。

導入するなら、初月はテスト整備とナレッジ登録に投資してください。この土台がないまま本番タスクを投げても、精度の議論は感覚論から抜け出せません。逆に土台さえ作れば、以後の依頼はずっと安定します。

よくある質問（FAQ）

Q. Devinの精度が低いのは、モデルが古いからですか？

その可能性は低めです。同じ環境でも、指示文を3点セットに書き直しただけで結果が変わるケースが多く、原因は渡す情報の量と構造にあることがほとんど。モデルを疑う前に、切り分け表の1から6を試してください。

Q. 日本語で指示を出すと精度が落ちますか？

日本語そのものが問題になることは少ないです。落ちるのは、社内用語や省略表現が混ざったとき。「案件」「枠」のようにコード上の名前と日常語がズレている言葉は、ナレッジに定義を登録しておくと安定します。

Q. 質問の仕方で気をつけることは何ですか？

判断を渡すときに理由を添えることです。「AとBならA」だけでなく「既存のCと揃えたいからA」まで書くと、次の似た判断でも同じ方向に寄ってくれます。曖昧に返すと、曖昧なまま実装が進みます。

Q. 1回の依頼はどれくらいの大きさが適切ですか？

人間が15分でレビューできる差分に収まる量が目安です。それ以上になると、返ってきた成果物を誰も読めず、検証されないままマージされます。大きいタスクは4本前後に割ってから順に投げてください。

Q. テストがないリポジトリでも使えますか？

使えますが、精度の判定ができません。おすすめは、機能追加の前に既存機能のテストを書かせるタスクから始めること。テストが増えるほど、以後の依頼の完了条件を機械が判定できるようになります。

Q. 他のAIコーディングツールと併用すべきですか？

併用が現実的です。仕様が固まった量のあるタスクはDevin、試行錯誤しながら書く作業はCursorやClaude Code、といった分担が噛み合います。1本に絞ろうとすると、どちらの得意分野も活かせません。

Q. 生成されたコードのレビューはどこまで必要ですか？

差分の意図を説明できる状態まで、人間が読む必要があります。Devin Reviewのようなレビュー支援機能は差分の整理を助けてくれますが、取り込む判断そのものは人間側に残ります。ここを省くと、精度の問題が本番まで先送りされるだけです。

Q. 導入して何日で判断すべきですか？

最低でも2週間は見てください。初週はナレッジ登録とセットアップの調整で終わることが多く、成果が出るのは土台が整ってから。初日の1本で判断すると、ほぼ確実に過小評価になります。

あわせて見たいツール・カテゴリ

Devinの検討と並行して見ておくと、選択の精度が上がる面々です。

次に読むならこれ: 生成AIへの指示の出し方をもっと突き詰めたいなら、ComfyUIとStable Diffusionの比較記事がおすすめです。同じモデルでも設定と指示の組み方で出力が変わる構造が、コーディング以外の題材で具体的に見えます。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。