🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）
この記事にぜひ いいね（LGTM） していただけると励みになります 🙌
はじめに
挑発的なタイトルですみません。でも、Devin for Terminal（devin CLI）を使い始めた人の多くが、**「優秀なAIに雑に丸投げして、出てきた差分の多さに疲れる」**という同じ壁にぶつかります。私もそうでした。
ここで意識を変える必要があります。Devin は 「3分で記憶を失う、超優秀だが文脈を持たない新人」 だと思ってください。能力は高い。でも、こちらが文脈と段取りを設計してあげないと、平気で斜め上に走ります。
この記事では、ありがちな 7つの「間違った使い方」 と、その直し方を挙げます。すべて実機（devin 2026.5.x）と公式ドキュメントで確認した機能だけで構成しています。
ミス①：Rules（作法ファイル）を盛りすぎている
最初にやりがちなのが、プロジェクトの作法を書く Rules に、あれもこれもと詰め込むことです。「コーディング規約」「ディレクトリ構成」「過去のトラブル全部」……。
気持ちは分かりますが、Rules は毎回読まれる固定コストです。膨らむほどノイズが増え、肝心の指示が埋もれます。
直し方：Rules は最小限。手順は Skills に切り出す。
- Rules … 「常に守ってほしい少数の原則」だけ
-
Skills … 「特定の作業のときだけ呼び出す手順書」（
SKILL.md）
「リリース手順」「特定APIの叩き方」のようなたまにしか使わない知識は、常時読ませる Rules ではなく Skills に置く。こうすると、必要なときだけ文脈に載るので、普段の会話が軽くなります。
私の Rules も、気づけば過去のトラブル対応のメモで膨れ上がっていました。半分くらいを Skills に逃がしたら、普段の応答が明らかに素直になった——というのが、この見直しを勧める一番の理由です。
詳しくは別記事「Rules・Skills・Plugins でプロジェクトの作法を覚えさせる」で掘り下げています。
ミス②：1つの指示に複数の作業を詰め込んでいる
「このバグ直して、ついでにテスト書いて、リファクタもして、ドキュメントも更新して」——気持ちはわかります。でも、これは人間の新人にやってもエラーが出る頼み方です。
文脈が混ざり、AIの注意が分散し、レビューしづらい巨大な差分が返ってきます。
直し方：Subagents で責務を分ける。
Devin for Terminal は、Subagents（.devin/agents/<profile>/AGENT.md）で役割の違うエージェントを定義できます。
「実装する係」「レビューする係」「調査する係」を分けると、各エージェントの文脈がクリーンに保たれます。1つの会話に全部を背負わせない。これだけで結果が安定します。
実際の書き方は「Subagents 実践：reviewer と researcher を書く」を参照してください。
ミス③：実装の途中で /compact を打っている
Devin は会話が長くなると、文脈を要約圧縮する コンパクション を行います。これを手動で起動するのが /compact です。
ここでありがちなのが、実装が佳境のときに「重くなってきたから」と /compact を打ってしまうこと。要約の過程で、まさに今必要な細かい文脈が削られ、AIが「あれ、何やってたんだっけ」状態になります。
直し方：圧縮は「区切り」でだけ。状態は /context で見る。
-
/context… 今のコンテキスト使用量を確認する -
/compact… 圧縮を強制する（タスクの切れ目で） -
/clear（/new）… 会話履歴を消して新しいセッションを開始
実装の途中ではなく、1タスク終わった区切りで /compact または /clear する。そして「何を・なぜ・どう進めるか」という計画は、会話の記憶に頼らずファイルに残す。AIの短期記憶を信用しない、が鉄則です。
実は私も、リファクタの佳境で何気なく /compact を打ってしまったことがあります。直前まで握っていた「どのファイルをどう直すか」の細部が要約で飛び、Devinが急に的外れな変更を始めて青ざめました。それ以来、圧縮はタスクの切れ目でしか打たないと決めています。
ミス④：MCPサーバーを「全部盛り」で常時接続している
便利だからと、使うかどうか分からない MCP サーバーまで片っ端から繋いでいませんか。MCP は接続するほどツール定義が文脈を食い、AIの選択肢を無駄に増やします。
直し方：必要なものだけ。不要なものは disable で切る。
Devin for Terminal は、MCP サーバーを消さずに無効化できます。
| コマンド | 内容 |
|---|---|
devin mcp list |
設定済みサーバーの一覧 |
devin mcp disable <name> |
削除せず無効化 |
devin mcp enable <name> |
無効化したものを有効化 |
「普段は最小構成。GitHub操作をする日だけ enable する」——このくらい絞って運用するほうが、AIの精度も体感も上がります。盛るのは簡単、削るのは勇気、です。
ミス⑤：設計まで丸投げしている
いちばん根が深いのがこれです。「いい感じに認証機能を作って」と設計ごと投げる。返ってくるのは"それっぽい何か"で、結局やり直しになります。
AIは実装は速いですが、あなたのプロダクトの意図や制約は知りません。設計は、文脈を一番持っている人間が握るべき領域です。
直し方：/plan・/ask で「合意してから実装」する。
Devin for Terminal には、コードを書かない読み取り専用のモードがあります。
| モード | 役割 | コードを書くか |
|---|---|---|
/ask <質問> |
既存コードの理解・質問（ワンショット） | 書かない |
/plan |
実装前の計画・設計（読み取り専用） | 書かない（提案のみ） |
/normal |
通常の実装 | 書く |
/ask で現状を理解し、/plan で方針を出させ、人間が方針に合意してから /normal で実装に進む。「丸投げして暴走させる」のではなく「方針だけ握って実装は任せる」。この距離感が事故を減らします。
私も最初は「いい感じにやって」で丸投げしていましたが、返ってくるのは惜しい別物ばかりで、結局自分で書き直していました。/plan で方針を先に出させる癖をつけてから、手戻りが目に見えて減ったのを実感しています。
この進め方は「いきなり書かせない：/plan・/ask で安全に進める」で詳述しています。
ミス⑥：レビューを人間がサボっている
AIが書いたコードを、ろくに読まずにマージしていませんか。「動いてるからヨシ」を続けると、誰も理解していないコードベースが静かに育ちます。
直し方：diffを小さく保ち、レビューを仕組みにする。
- diffを小さく：ミス②のとおりタスクを分割すれば、レビューしやすい単位になる
- 専任のレビュー役：ミス②の reviewer Subagent に一次レビューさせ、人間は要点だけ確認
-
危険操作はHooksで機械的に止める：
PreToolUseフックでrm -rfやpush --forceを自動ブロック
AIに任せるほど、人間のレビュー責任はむしろ重くなる。ここを仕組みで支えるのが、安全に速く回すコツです。
Hooksの設計は「Hooks で『危ないコマンド』を自動で止める」を参照してください。
ミス⑦：同じセッションを延々と使い続けている
朝から晩まで、1つのセッションであれもこれも。これも典型的なアンチパターンです。前のタスクの文脈が残り続け、AIが過去に引きずられて精度が落ちます。
直し方：タスク完了でセッションを切り替える。
| 操作 | 用途 |
|---|---|
/clear（/new） |
履歴を消して新セッション開始 |
devin -c / --continue
|
直近セッションを再開（続きをやりたいときだけ） |
devin -r <ID> / --resume
|
特定セッションを再開 |
/fork [step] |
元を汚さず分岐して別案を試す |
基本は「1タスク = 1セッション」。終わったら /clear。続きが必要なときだけ -c / -r で戻る。「これは賭けだな」という実装の前は /fork で分岐して、失敗しても元の会話を無傷に保つ。
私自身、朝に始めたセッションを夕方まで引きずって、関係ないはずの前タスクの話を蒸し返されたことが何度もあります。今は1タスク終わるごとに /clear、と機械的に切るようにしてから、その手の「引きずり」がほぼ消えました。
そして繰り返しますが、文脈はセッションではなくファイルに残す。セッションは使い捨て、知識はリポジトリに、です。
セッション操作の詳細は「会話を巻き戻し・分岐して試行錯誤する」にまとめています。
まとめ：7つのミスと直し方
| # | 間違った使い方 | 直し方 |
|---|---|---|
| ① | Rules を盛りすぎ | 最小限に。手順は Skills へ |
| ② | 1指示に複数タスク | Subagents で責務分離 |
| ③ | 実装途中で /compact
|
区切りでだけ。/context で監視、計画はファイルへ |
| ④ | MCP 全部盛り | 必要分だけ。devin mcp disable で切る |
| ⑤ | 設計まで丸投げ |
/plan・/ask で合意してから実装 |
| ⑥ | レビューをサボる | diffを小さく＋reviewer Subagent＋Hooks |
| ⑦ | 同一セッション長期使用 |
/clear で切替、/fork で分岐、文脈はファイルへ |
すべてに共通するのは、「コードを書かせる道具」から「タスクを委任する相手」への意識転換です。Devin は優秀ですが、文脈を持たない新人でもある。段取りとガードレールを設計してあげれば、その能力は一気に活きます。
「全部おまかせ」をやめて、「方針は握る・実装は任せる・検証は仕組みで」。これだけで、Devin との開発体験はまるで別物になります。気になったミスから1つずつ、手元の devin で直してみてください。