「AI エンジニア」を名乗る Devin が登場して以来、「AI 自律エージェントは本当に実務で使えるのか」という問いを、多くの開発現場が抱えています。デモ動画では人間のように issue を読み、コードを書き、テストを通し、プルリクエストまで作る。しかし実案件に投入したとき、それがどこまで再現されるのかは別の話です。
私たち FIXIT は AI 駆動開発のクリエイティブスタジオとして、Devin・Claude Code・Cursor のエージェント機能を実タスクに組み込んで運用してきました。本記事では、自律エージェントに任せられる仕事と任せられない仕事の境界を、デモではなく実務の感覚から整理します。Devin の使い方を検討している方、ツール選定で迷っている方が、過剰な期待にも過度な懐疑にも振れずに判断できるよう、運用の勘所を残します。
結論|自律エージェントに任せられる仕事・任せられない仕事
先に結論を述べます。2025 年時点の AI 自律エージェントは、「明確に切り出され、成否を機械的に検証できるタスク」であれば実務で十分使えます。逆に「仕様が曖昧で、設計判断や本番影響を伴うタスク」では、人間の監督なしに任せると手戻りのほうが大きくなります。
つまり論点は「エージェントが優秀かどうか」ではなく、「そのタスクが自律実行に向いた形に分解されているか」です。同じ Devin でも、テストの整った小さなバグ修正を投げれば高い確率で完走しますし、要件が固まっていない新機能をまるごと投げれば破綻します。エージェントの性能差より、タスクの切り出し方とそれを検証する仕組みのほうが、結果を大きく左右します。
この前提に立つと、ツール選定の問いは「Devin と Claude Code、どちらが賢いか」ではなく、「自分たちのワークフローのどこに、どのエージェントを差し込むか」に変わります。エージェントに限らず AI コーディングツール全体を目的やチーム規模から選び分ける視点は AI コーディングツールの選び方 にまとめています。以下、その判断材料を順に見ていきます。
Devin とは|自律型 AI エージェントの位置づけ
Devin は Cognition Labs が「AI ソフトウェアエンジニア」として打ち出したプロダクトです。特徴は、人間が逐一指示を出さなくても、タスクを受け取ってから計画立案・コード編集・コマンド実行・ブラウザ操作・テスト実行までを一連の流れとして自分で進めようとする点にあります。専用のシェルやエディタ、ブラウザを内部に持ち、長時間のタスクを非同期で回せるよう設計されています。
ここで重要なのは「自律」の度合いです。AI コーディング支援は、大きく次のような段階に分けられます。
まずコード補完。これは GitHub Copilot が広めた領域で、書いている行の続きを提案します。次に対話型編集。Cursor や Claude Code のように、人間が指示しながらコードを書き換えていく段階です。そしてその先に、タスク単位を渡すと人間の常時監視なしに完走を目指す自律エージェントがあり、Devin はこの最も自律性の高い段階を狙っています。
ただし「自律性が高い=実務で優れている」ではありません。自律性が上がるほど、人間が介入できるポイントが減り、誤った方向に進んだときの手戻りが大きくなります。だからこそ、どこまで任せ、どこで人間が確認するかという設計が決定的に重要になります。AI 駆動開発そのものの考え方は AI 駆動開発とは何か で整理していますが、自律エージェントはその一部を担う構成要素と捉えるのが実態に近いです。
Claude Code・Cursor のエージェント機能との違い
Devin を「自律エージェント」とだけ説明すると、Claude Code や Cursor との違いが見えにくくなります。実際にはこの 3 つは、得意とする使い方が異なります。
Cursor は VS Code 派生のエディタで、補完とインライン編集、そして複数ファイルにまたがる編集を対話的に行うエージェント機能を備えています。人間がエディタの前に座り、コードを見ながら指示と確認を繰り返す作業に最も馴染みます。手元で「ここをこう直して」とテンポよく進めたい場面で強い選択肢です。
Claude Code はターミナル上で動くエージェントで、計画を立ててからファイルを横断的に変更し、コマンドを実行し、結果を見て修正するという流れを得意とします。リポジトリ全体を文脈として扱いやすく、まとまった粒度の変更を計画的に進めるのに向いています。プロジェクトの規約を CLAUDE.md に書いて文脈を渡す運用も含め、設計や規約の理解を要する作業との相性が良いです。3 ツールの違いと選び方は Claude Code・Cursor・GitHub Copilot の比較 でも詳しく扱っています。
Devin が他の 2 つと一線を画すのは、「人間が画面の前にいない時間」を前提にしている点です。Cursor も Claude Code も、基本は人間が指示と確認のループに入っています。一方 Devin は、Slack などからタスクを受け取り、クラウド上の自分の環境で非同期に作業を進め、完了したら結果を返すという働き方を想定しています。
この違いから、使い分けの軸が見えてきます。手元で対話しながら作るなら Cursor や Claude Code、明確に切り出した独立タスクを並列で投げるなら Devin のような自律エージェント、という整理です。多くの現場では二者択一ではなく、開発者個人の手元作業には Cursor や Claude Code、定型的に発生する独立タスクのバックグラウンド処理には自律エージェント、という併用が現実解になります。
実タスクで検証|タスク完了率と手戻りの実感値
ベンチマークの数値は参考になりますが、実務での体感とは必ずしも一致しません。私たちが実案件で自律エージェントを使った範囲で言えば、完了率はタスクの種類によって大きく振れます。平均値を出すこと自体にあまり意味がなく、「どの種類のタスクで成功し、どこで失敗するか」という分布を見るほうが運用判断に直結します。
体感として、テストが整っていて受け入れ基準が明確なタスクは高い確率で一発完走します。逆に、既存コードの暗黙の前提が多い領域や、仕様の解釈に幅があるタスクでは、表面的には動くものが返ってくるのに意図とずれている、という手戻りが目立ちました。この「動くけれど違う」状態は、レビューにかかる時間を読みにくくする厄介な失敗モードです。
ここで効いてくるのが、エージェントの出力を機械的に検証できるかどうかです。テストや型チェック、Lint が揃っている領域では、エージェントが自分で失敗に気づいて修正を回せるため、人間が確認する負荷が下がります。検証の土台がない領域にエージェントを投入すると、雰囲気で動くコードがそのまま積み上がり、後から品質を担保するコストが膨らみます。この点は vibe coding を本番でレビューした経験 とも通じる話で、検証可能性こそが自律実行の前提条件だと考えています。
向くタスク(定型・調査・テスト生成)
自律エージェントが力を発揮するのは、入力と期待される出力がはっきりしているタスクです。
調査系のタスクは相性が良い領域です。「この関数がどこから呼ばれているか」「この依存ライブラリを更新したときの影響範囲」といった、コードベースを横断して情報を集める作業は、人間がやると時間がかかる一方、正解の検証がしやすいため任せやすくなります。
既存仕様に沿ったテスト生成も向きます。実装済みの振る舞いに対してテストを追加する作業は、何が正しいかが既に存在するため、エージェントの出力を評価しやすいからです。定型的なリファクタリングや、明確に再現手順のあるバグ修正も同様で、受け入れ基準が「テストが通ること」に落ちている限り、自律実行の効果が出ます。依存パッケージの更新やボイラープレートの追加といった、判断より手数が支配的なタスクも得意です。
向かないタスク(仕様の曖昧な設計・本番影響大)
逆に任せると痛い目を見るのは、判断そのものが成果物になるタスクです。
仕様が固まっていない新機能の設計は、その典型です。何を作るべきかが曖昧なまま投げると、エージェントは「もっともらしい何か」を作りますが、それが本当に必要なものである保証はありません。曖昧さを解消するのは依然として人間の仕事であり、ここを飛ばすと後工程がすべて崩れます。
アーキテクチャに関わる判断や、複数チームの合意が必要な変更も向きません。トレードオフの評価には、コードに現れない組織やビジネスの文脈が絡むためです。そして本番影響が大きい変更、たとえばデータマイグレーションや課金まわり、認証・権限の変更は、たとえエージェントが正しく書けたとしても、人間が責任を持って確認する工程を省けません。失敗時の影響が大きいタスクは、自律性を意図的に下げ、人間のレビューを必須にするのが鉄則です。
人間協調設計|エージェントを安全に組み込む評価ハーネス
ここまでの整理から見えるのは、自律エージェントの価値は「エージェント単体の賢さ」ではなく「人間とエージェントをどう協調させる設計か」で決まる、ということです。私たちはこの設計の中核を評価ハーネスと呼んでいます。
評価ハーネスとは、エージェントの出力を機械的に検証できる土台のことです。具体的には、十分なカバレッジの自動テスト、CI による自動チェック、型チェックや Lint、そしてタスクごとの明確な受け入れ基準が含まれます。エージェントが自分の作業の成否を自分で判定できれば、失敗を自分で修正するループが回り、人間が確認する範囲を絞り込めます。
次に重要なのが、変更範囲を限定する仕組みです。エージェントに巨大な変更を一度に任せるとレビューが破綻するため、タスクを小さく切り、1 つのプルリクエストの差分を人間が無理なく読める大きさに保ちます。差分が小さいほど、レビューの精度は上がり、問題の切り分けも容易になります。
そしてワークフローそのものを、人間のレビューを前提に組みます。自律エージェントが作業を完走しても、本番へ反映する前に人間が確認するゲートを必ず置く。自律性を上げる領域と、人間の承認を必須にする領域を、タスクの本番影響度で線引きする。この線引きの設計こそが、エージェント運用の成否を分けます。私たちが実際に組んだエージェント運用の構成は AI エージェントによる運用自動化の事例 にまとめています。
受託・社内開発での現実的な使いどころ
最後に、実際の開発現場での落とし込み方を整理します。
社内開発であれば、まずは検証の土台が整っているリポジトリから始めるのが安全です。テストと CI が機能している領域で、調査・テスト追加・定型修正といった「向くタスク」に絞ってエージェントを導入し、効果と失敗モードを観察します。いきなり全社展開や全タスク委任を狙うのではなく、勝てるタスクで実績を作り、そこから自律性の範囲を少しずつ広げる。この段階的な拡大が、信頼の毀損を避けながら効果を積み上げる現実的な道筋です。
受託・クライアントワークでは、もう一段の配慮が要ります。クライアントの本番システムに対しては、誰が最終的な品質に責任を持つかが明確でなければなりません。エージェントが書いたコードであっても、レビューと受け入れの責任は人間が担う、という前提を共有したうえで、どのタスクをエージェントに任せ、どこを人間が握るかを設計します。自律エージェントは納期短縮と品質の両立に効きますが、それは検証の仕組みと人間の監督がセットになってはじめて成り立ちます。
裏を返せば、自律エージェントを安全に組み込むには、テスト・CI・受け入れ基準・レビューワークフローという「AI 駆動開発の地ならし」が先に必要だということです。ツールを入れれば速くなるのではなく、地ならしができている組織がツールで速くなる。この順序を取り違えないことが、Devin であれ Claude Code であれ、自律エージェントを実務で使いこなすための出発点になります。
FAQ|Devin はエンジニアを代替するか
自律型 AI エージェントの実用化は、ツールの性能だけでなく、それを支える評価ハーネスと人間協調設計をどう組むかにかかっています。FIXIT は AI 駆動開発のクリエイティブスタジオとして、評価ハーネスの設計から人間協調を前提としたエージェント運用までを、実プロジェクトで構築してきました。自律エージェントを自社の開発に安全に組み込みたい方は、実用 AI エージェント開発の事例とサービス → /services/ai-agent/ をご覧ください。