Claude Code と Devin、どっちに任せる？相棒型と自律型の使い分け

「Jiraのこのチケット、調査して直してPRまで出しといて」

そう投げて昼ごはんを食べて戻ってきたら、PRが1本できていた——という体験を初めてしたとき、正直ゾッとしました。便利、の前に「これ、誰がレビューするんだ？」と。

僕はふだんClaude Codeを手元で動かしています。差分を一行ずつ見ながら直すのが好きだからです。でもDevinを触ってみて、AIエンジニアって一括りにできないな、と思い知りました。Claude Code と Devin は、たとえるなら隣に座る相棒と、席を外しても回す請負業者くらい性格が違う。だから「どっちが賢いか」で選ぶと、まあまあ後悔します。

この記事では、僕が両方を触って感じた性格の違いと、どっちにどの仕事を渡すか、料金の見方、そして「併用」の現実的なやり方を書きます。煽りなしで。料金やモデルはコロコロ変わるので、金額は必ず公式で確認してください。

この記事の要点

• Claude Code は「手元の相棒」。自分のリポジトリ・ターミナルで、差分を見ながら少しずつ直すのが得意。
• Devin は「自律する請負業者」。クラウド上でチケットを受け取り、人が見ていない時間も走り続ける。
• 選ぶ基準は賢さより、誰が途中で判断するか / どこにコードと秘密情報を置くか / 後から検証できるか。
• 料金は単位が違う。Claude Code はサブスク＋使った分、Devin は「働いた時間」課金（ACU）。金額は公式で確認。
• 一番強いのは併用。Claude Code で依頼書を整えて、Devin に渡すと事故が減る。

まず性格の違いから。相棒か、請負業者か

Claude Code は、Anthropic のエージェント型コーディングツールです。あなたの手元の環境——ローカルのリポジトリ、ターミナル、エディタ——に入り込んで、コードを読み、ファイルを編集し、テストを走らせ、失敗を見て直す。これを短いサイクルで繰り返します。公式のClaude Code overviewでも、コードベースを読んでファイルを編集し開発ツールと連携する道具として説明されています。

感覚としては、ターミナルの中にいるペアプログラマです。「この認証エラーの原因だけ調べて。テストはまだ走らせないで」と言えば方針を返す。「その方針で直して、関連テストだけ実行して」と言えば差分と結果を返す。途中でいつでも止められて、変なファイルを触ったらgit差分ですぐ気づける。主導権が常に自分にあるのが気持ちいい。

Devin は、Cognition の「AI software engineer（AIソフトウェアエンジニア）」です。公式のDevin docsでは、コードを書き、実行し、テストできる自律エージェントとして説明されています。違うのは置き場所。Devin はクラウド上に自分専用のワークスペース（シェル・エディタ・ブラウザ込み）を持ち、そこで仕事をします。

だからDevinの使い方は「渡して、待つ」。チケットを投げて、数十分後にドラフトPRや調査結果を受け取る。人が張り付かなくても進むのが最大の魅力で、最大の落とし穴でもあります。最初の指示が雑だと、数時間後に「方向は合ってるけど採用できないPR」が返ってくる。請負業者に曖昧な発注をすると揉めるのと同じです。

なぜ「どっちが上か」で比べると失敗するのか

両者は重なる部分もあります。Claude Code にもクラウド寄りの使い方（GitHub Actionsから@claudeで呼ぶなど）があるし、Devin にもCLIはある。だから「Claude Codeはローカル専用、Devinはクラウド専用」と固定して覚えるのは雑すぎます。

それでも主戦場は明確に違います。Claude Code は、自分がリポジトリ・テスト・レビュー判断を握ったままAIに実装を渡す場面。Devin は、チームのバックログや調査を一定時間まるごと委任する場面。「隣で見ながらやる仕事」か「あとで受け取る仕事」か——この一点で世界が分かれます。

もう一つ、コストの単位がそもそも違う。Claude Code は手元で小さく回すほどレビューコストを抑えやすい。Devin はクラウドで並列に放置できる反面、チケットが曖昧だと待ち時間・レビュー時間・やり直しが見えにくくなる。同じ物差しで「時給いくら」と比べようとすると、測る対象そのものを間違えます。

比較表：判断に効く7つの軸

軸	Claude Code	Devin	見るポイント
置き場所	手元のrepo・ターミナル・git差分	クラウドのワークスペース（CLIもあり）	既存のローカル環境をそのまま使いたいならClaude Code
自律の深さ	人のレビューと反復が前提	見ていない時間も走り続ける	放置時間を作りたいならDevin、細かく舵取りならClaude Code
関わり方	指示→差分→テスト→次の指示（短い周期）	投入→待機→レビュー→差し戻し（長い周期）	仕様が固いほどDevin、詰めながら進めるほどClaude Code
引き継ぎ	CLAUDE.md・検証メモ・git diffで残る	セッション・ドラフトPR・作業ログで残る	チームの引き継ぎ形式を先に決める
安全境界	ローカル権限・許可コマンドで絞れる	クラウド接続・repoアクセス・secrets管理の設計が要る	本番権限・顧客データは最初から分離
料金の形	サブスク＋利用量	働いた時間ベース（ACU）+プラン	金額は変動。並列数・やり直し率も込みで見る
得意な仕事	既存repo保守・テスト追加・軽いリファクタ・記事/ドキュメント	issue整理・調査・移行・バックログ消化・ドラフトPR	「人が隣にいる作業」か「受け取る作業」かで分ける

似た対象との住み分けも軽く。手元のCLIツール同士の比較はClaude Code vs Gemini CLI、結局どっち？、エディタ補完との違いはClaude Code と GitHub Copilot、結局どっち？にまとめてあります。Devin は「自律実行」という別カテゴリなので、この記事で扱います。

料金の考え方（金額は断定しない）

ここは正直に。両者の料金は形が違いすぎて、単純比較が一番ダメなところです。

Claude Code は基本的にサブスク＋使った分のモデルです。手元で小さなタスクを回すぶんには見通しが立てやすい。ただし長いセッションを何度も回すと利用量も人の確認時間も増えます。

Devin は**「働いた時間」課金**が特徴です。Cognitionは ACU（Agent Compute Unit）という単位を使っていて、ざっくり1 ACU ≒ Devinが実働15分くらい、という考え方です。月額プランに一定のACUが含まれ、超えたぶんは従量、というイメージ。並列でガンガン任せられる反面、放置＝課金なので、雑なチケットを大量投入すると請求が膨らみます。

大事なのは、料金プランの数字だけ見ても本当のコストは出ないということ。AIエージェントは「1回の回答」ではなく「調査→編集→実行→失敗→再実行」を繰り返します。だから、セッション数・並列数・人のレビュー時間・やり直し率まで足して初めて比較になる。具体的な金額はDevin公式の料金ページとAnthropic公式で、自分の使い方に当てて確認してください（どちらもよく改定されます）。

具体的にどう使い分けるか（4つの場面）

1. ソロ開発者の日常メンテ → Claude Code

個人開発や小さなSaaSで、依存更新・lint修正・テスト追加・README整備を回すなら、まずClaude Code。作業範囲を1つのissueや1ディレクトリに絞って、差分を見ながら進めます。

コツは「全部直して」ではなく「この3ファイルだけ読んで、落ちてるテストの原因を説明してから最小修正を提案して」と頼むこと。手元の文脈を使えるので、実装→テスト→git diff確認まで短いループにできます。

2. 溜まったissueの一次処理 → Devin

未整理のissueやバグ報告が山積みなら、Devinの出番。再現手順を探す、関連コードを読む、影響範囲をまとめる、ドラフトPRまで作る——どれも人がまとまった時間を取りにくい作業です。

ただしチケット本文が曖昧だと確実に失敗します。「期待結果」「再現手順」「対象ブランチ」「触っていい範囲」「完了条件」「レビュー担当」を必ず入れる。発注書だと思って書くと精度が上がります。

3. でかいレガシーへの新人オンボーディング → まずClaude Code、調査が広いならDevin

巨大なrepoに新メンバーが入るとき、いきなり実装をAIに任せるより、まずコードマップを作る。Claude Codeに「課金処理の入口・主要な型・テスト・外部API接続を一覧化して」と頼むと、手元のrepoに合った調査メモができます。

調査対象が大きく、ドキュメントや外部サービスもまたぐならDevin。ただし初回は読み取り中心にして、PR作成やsecrets利用は許可しない。オンボーディングの最大の落とし穴は「AIが書いた説明を人が信じすぎること」です。参照ファイルと行番号、実行コマンド、未確認事項を必ず残させます。

4. 試作からPRまで → 併用が効く

新機能の試作からPRまでを短くしたいなら、役割分担です。Claude Codeで要件を小さな設計メモとチェックリストに落とし、必要ならDevinに「この範囲でドラフトPRを作って」と渡す。返ってきたPRはClaude Codeでレビュー観点を固定して読み直し、最後は人が判断する。チームでの型はClaude Codeチームハンドオフルールにつなげられます。

ここで大事なのは、AI同士を競わせるより同じ完了条件を共有させること。UI変更ならスクショ、API変更なら契約テスト、記事変更ならリンクとCTA確認を必須にします。

僕がやらかした失敗3つ

正直に書きます。最初は両方で事故りました。

ひとつ目は、Devinに丸投げしたこと。 「認証まわり改善して」とだけ投げたら、2時間後に巨大なPRが返ってきて、半分は不要なリファクタでした。請負業者に「いい感じにして」と言ったのと同じ。完了条件と禁止事項を1行も書かなかった僕が悪い。今は依頼書テンプレなしには投げません。

ふたつ目は、自律出力を鵜呑みにしたこと。 「テストを追加しました」「CI相当を確認しました」と書いてあっても、実際は対象外のテストだけ走らせていた、というのが普通にあります。レビューでは説明文ではなく、実行したコマンド・ログ・差分・残リスクを見る。これに切り替えてから手戻りが激減しました。

みっつ目は、secretsを広く渡したこと。 便利だからとDevinにrepoアクセスと環境変数をまとめて渡したら、ヒヤッとしました。本番DB・課金設定・メール送信・deploy権限をAIセッションに広く渡すと、便利さより事故リスクが上回ります。今は最初read-only・dev環境・テスト用secretsから。安全だと分かった操作だけ後から格上げします。Claude Code側の権限の絞り方はClaude Code 権限設定リファレンスに細かく書きました。

コピペで使える：壊さない検証ループ

どっちのAIに任せた変更でも、最後は機械で検証するのが一番です。下は破壊的な操作を含まない確認用のbashループ。npm run lintやnpm testが無いrepoでは、その行を自分の検証コマンドに置き換えてください。

#!/usr/bin/env bash
set -euo pipefail

# AIに任せた変更を「説明」ではなく「結果」で確かめるループ
commands=(
  "npm run lint"
  "npm test -- --runInBand"
  "npm run build"
)

for cmd in "${commands[@]}"; do
  echo "==> $cmd"
  bash -lc "$cmd"
done

# 余分な空白や衝突マーカーが混ざっていないか
echo "==> git diff --check"
git diff --check

# 変更ファイルが想定の範囲に収まっているか
echo "==> changed files"
git diff --stat

これをAIに渡すときは「失敗したら直す前に原因を説明して」「コマンドを足すなら理由を書いて」と添えます。自由なシェルを渡すほど速くなりますが、deploy・削除・secrets表示・外部送信だけは別扱いにしておくと、夜中にヒヤッとする回数が減ります。

依頼そのものを固めたいときは、こんなブリーフをそのまま使えます。Devinへ渡すなら特に、完了条件と禁止事項を省かないこと。

## 変更依頼ブリーフ

ゴール:
- （ユーザーから見て何がどう変わるか）

文脈:
- リポジトリ / ブランチ:
- 関連issue / チケット:

範囲:
- 読んでよい:
- 編集してよい:
- 触るな:

制約:
- 公開APIは明示要求がない限り変えない
- 依存追加は理由を書いてから
- 本番secrets・本番DB・課金設定・deploy先に触れない

検証:
- 実行するコマンド:
- 実行できない場合は理由と最も安全な代替を書く
- 最終報告に「変更ファイル・テスト結果・残リスク」を含める

引き継ぎ:
- ドラフトPRかパッチ要約を出す
- レビュー注意点とロールバック手順を添える

よくある質問

Q. Claude Code と Devin、初心者はどっちから？ A. Claude Code です。手元で差分を見ながら進められるので、AIが何をやったか目で追える。良い依頼・悪い依頼の感覚をここで掴んでから、Devinのような自律型に進むと判断を誤りにくいです。

Q. Devin は本当に人が見ていなくても大丈夫？ A. 仕様が固いタスクなら、かなり走ります。ただし完了条件が曖昧なプロダクト判断、顧客別の例外、法務・セキュリティ判断、本番deployは人の判断を残すべき。最初は読み取り・調査・テスト作成・ドラフトPRに絞って、成功率とレビュー時間を測るのが安全です。

Q. 料金はどっちが安い？ A. 使い方次第で逆転するので断定できません。Claude Codeはサブスク＋利用量、DevinはACU（実働時間）課金。雑な大量投入はDevinが高くつき、長セッションの乱発はClaude Codeの利用量を押し上げます。金額はDevin公式とAnthropic公式で最新を確認してください。

Q. 結局どっちか1つに絞るべき？ A. 絞らなくていいです。むしろ併用が一番強い。Claude Codeで依頼書と完了条件を整え、自律で回せる塊だけDevinに渡す。返ってきた成果物をClaude Codeでレビューする、という流れが現実的です。

Q. Claude Code vs Gemini CLI や Copilot との比較は？ A. それらは対象が違います。手元のCLI比較はvs Gemini CLI、エディタ補完との違いはvs GitHub Copilotへ。本記事は「自律実行型」のDevinとの対比に絞っています。

実際に両方触ってみた結果

両方を1か月ほど使って、僕の結論はシンプルになりました。「強いAIを選ぶ」より「検証できる依頼に分解する」ほうが成果に直結する。

Claude Codeは、手元で主導権を握ったまま小さく速く回すのに最高でした。記事の差分、コードフェンス、内部リンク、CTA、検証コマンドの確認みたいに、透明性が効く作業で安定します。Devinは、雑に投げると事故りますが、依頼書をちゃんと書いて読み取り中心で渡すと、自分が他の作業をしている間に下調べを進めてくれる頼もしさがありました。

決め手は自律度の高さではなく、レビューできる形で仕事を終わらせる運用でした。Claude CodeでもDevinでも、最後に価値を決めるのはそこです。

まずはClaude Codeで小さな検証ループを1つ作ってみてください。良い仕様・悪い仕様・検証メモの感覚が手に入ると、Devinのような自律ツールを試すときも怖くなくなります。型からそろえたいなら教材一覧、チームで一気に整えるなら研修・導入相談が近道です。