Devinが動かない5大原因と対処法チェックリスト (2026年版)

Devinとは、セッションごとに独立した仮想マシンを立ち上げ、その中でシェル・エディタ・ブラウザを操作してコードを書き、GitHubにプルリクエストとして成果物を届ける自律型のAIソフトウェアエンジニアです。そして「Devinが動かない」とは、Devin本体の故障ではなく、セッションの起動・環境構築・GitHub権限・Slack連携・ACU残量のいずれかが原因で作業が前に進まなくなった状態を指す症状の総称です。

昨日まで普通にPRを作ってくれていたのに、今日はセッションを投げても沈黙。ログを開いても赤い文字は無く、ただ進んでいない。この状態、9割は「Devinの故障」ではなく設定と権限とクレジットのどれかです。

順番に潰せば、たいていは30分以内に原因が判明します。

最初の60秒でやること

沈黙したセッションを眺め続けても情報は増えません。触るべき場所は3つだけです。

1. セッションのワークログを最下部まで開く（進行中なのか、待機で止まっているのか）
2. 使用量（ACU）の残を確認する
3. Settingsの環境構築（blueprints） が最新の方式で保存されているか見る

この3つで切り分けられなかったケースは、GitHub側の権限かSlack側の設定に寄っています。どちらもDevinの画面ではなく、連携先の管理画面を見ないと分かりません。ここを見ずに再実行を繰り返すのが、一番時間を溶かすパターン。

「Devinが動かない」は5種類に分かれます

同じ「動かない」でも、対処法は症状ごとに完全に別物です。まずは自分がどれに当たるかを決めてください。

以下は、報告される症状を発生箇所ごとに整理したものです。

つまり、①④は数分で戻せて、②③は設定作業、⑤は使い方そのものの調整という切り分けになります。ここから1つずつ掘ります。

セッションが始まらない・途中で止まるのはなぜ？

Devinはセッションごとに独立した仮想マシンを立ち上げ、その中でシェル・エディタ・ブラウザを動かします。つまり「起動しない」は、コードの問題ではなくマシンの確保に失敗しているということ。

ここで確認する順番はこうなります。

• ブラウザのタブを閉じても実行は続くので、別タブで開き直して状態を見る
• 同時に走らせているセッション数を減らす
• 数分待ってから新規セッションを1本だけ作って再現するか見る

再現しないなら一時的な混雑です。再現するなら次の環境構築の項へ進んでください。

地味に多いのが、sleep状態を「止まっている」と誤認しているケース。Devinは待機や休止の状態でも使用量の扱いが定義されていて、公式の請求ドキュメントには、アイドル時やsleep時に消費がどう計測されるかの説明があります。つまり「動いていないように見えて課金対象の状態」が存在します。放置したセッションを畳む習慣は、それだけでコスト対策になります。

止まっているのかスリープなのか。ここを見誤ると、無い原因を探し続けることになります。

環境構築（Setup）の失敗が2026年に増えた理由

2026年に入って質問が急増したのがここです。原因は仕様変更。

公式ドキュメントの更新履歴によると、Classic environment setupは2026年6月30日をもって廃止され、すべての組織が宣言的構成（blueprints）へ移行することになりました。classic machine configurationは2026年7月31日まで読み取り専用の参照としては残りますが、実行系としては使えません。

去年セットアップしたまま放置していたリポジトリは、ここで静かに動かなくなります。エラーメッセージが「環境が古い」と親切に教えてくれるとは限らないのが厄介なところ。

環境構築でつまずいたときの確認項目を並べます。

つまり、環境構築の失敗の大半は「暗黙の前提をローカルから持ち込んでいる」ことが原因です。Devinの仮想マシンは毎回まっさらなので、あなたのMacに入っている前提は一切効きません。

Secretsについてもう一点。Enterpriseの管理者はEnterpriseレベルでSecretsを管理でき、それが配下のすべての組織へ自動的に共有される仕組みが用意されています。ただしこれは宣言的な環境設定を使っているユーザー向けの機能として提供が始まったものです。組織が大きいほど、ここの移行漏れがそのまま「特定チームだけDevinが動かない」に化けます。

環境の話は、ローカル開発でも同じ形でつまずきます。GPU環境の構築で消耗した経験がある人なら、ComfyUIとStable Diffusionの構築比較の記事は「バージョン固定を怠るとどこで壊れるか」の生きた見本として読めます。

GitHubにPRが出てこないときのチェックリスト

Devinの成果物はプルリクエストとして届くのが基本です。GitHubと連携すると、Devinがリポジトリにアクセスして変更提案を作り、人間がレビューしてマージする流れになります。

だから「作業完了と言っているのにPRが無い」は、ほぼ権限の問題。

• GitHub Appが対象リポジトリに対してインストールされているか（Organization全体ではなくリポジトリ単位で制限していないか）
• 書き込み権限とPull Request作成権限が付いているか
• 対象ブランチにブランチ保護がかかっていて、そもそもpushを弾いていないか
• SAML SSOを有効にしている組織で、認可（Authorize）が切れていないか

4つ目が曲者です。SSOの認可は期限切れで静かに無効になります。エラーが出るのはDevin側ではなくGitHub API側なので、ワークログには「push failed」程度しか残らないことがあります。

心当たりが無いのにある日突然PRが出なくなったら、まずSSO認可の期限を疑ってください。

Slackでメンションしても反応しないのは何が原因？

Slack連携を入れると、チャンネル上でDevinにメンションして作業を頼んだり、進捗報告を受け取ったりできます。裏を返せば、Slack側の状態が悪いと何も起きません。

反応しないときの確認は3点です。

• Devinアプリがそのチャンネルに招待されているか（プライベートチャンネルは特に漏れやすい）
• ワークスペースの管理者がアプリを制限していないか
• メンション先が正しいか（似た名前のBotを叩いていないか）

2026年のアップデートで、Devinがセッション中にSlackを操作した場合、メッセージ送信・リアクション追加・チャンネル読み取りといった操作が、専用のSlackアイコンとアクション詳細つきでワークログと進行状況UIに表示されるようになりました。逆に言えば、ワークログにSlackのアイコンが1つも出ていないなら、Devinはそもそもチャンネルを見に行けていません。

見えないものを推測しなくてよくなったのは、地味に効く改善です。

クレジット（ACU）切れは静かに止まる

ここが最も「原因不明」に化けやすいポイント。

Devinの課金は、セルフサービスのプラン（Free / Pro / Max / Teams）では付属の利用枠とオンデマンドクレジットの組み合わせで請求されます。Enterpriseの場合はAgent Compute Units（ACU）単位で、注文書に定めた単価に基づく請求です。

つまりACUは「Devinが働いた量」を測る単位。枠を使い切れば当然止まります。

つまり、個人や小チームで「今日から急に動かない」なら月次の枠を使い切った可能性が高く、大企業なら管理者側でACU表示や配分の設定が変わった可能性があります。Enterprise管理者向けにはACU表示の制御機能も用意されているため、メンバーの画面から残量が見えなくなっているケースも起こり得ます。

消費を抑えるコツは公式の請求ドキュメントにまとまっています。実務上効くのは次の3つ。

• 終わったセッションを畳む（放置しない）
• 1セッションに1タスクだけ渡す
• 調査だけの用途はDevinに投げない

3つ目は本気でおすすめです。「このエラーは何が原因か」を調べるだけなら、仮想マシンを丸ごと立ち上げる必要はありません。出典つきで調べたいならFeloの使い方をまとめた記事が参考になります。検索AIに調べさせてから、確定した作業だけDevinに渡す。この分業でACUの減りが目に見えて変わります。

ここまでの整理: 起動しない＝混雑かスリープの誤認、環境構築で落ちる＝2026年6月30日の仕様変更と暗黙の前提、PRが出ない＝GitHub権限とSSO認可、Slack無反応＝チャンネル招待。ここまでが「設定で直る」領域です。ここから先は使い方の話になります。

動いてはいるのに成果物が的外れなときは？

エラーは出ない。PRも来る。でも中身が頼んだ内容と違う。これは技術トラブルではなく、指示の設計ミスです。

Devin 2.0で導入されたInteractive Planningは、エージェントがコードベースを分析して計画を提案する仕組みです。つまり着手前に計画を人間が直せるということ。ここを飛ばして「よしなにやって」と投げると、Devinは自分の解釈で走り出します。

的外れを減らす書き方は、この4点に集約されます。

• 変更してよいファイル・ディレクトリを明示する
• 完了条件を「テストが通ること」など検証可能な形で書く
• やってほしくないこと（依存追加の禁止など）を1行入れる
• 提案された計画を必ず読んで、違うなら着手前に直す

特に3つ目。禁止事項を書かないと、勝手にライブラリを足して差分が膨らみます。レビュー不能なPRほど萎えるものはありません。

大きな機能を一発で頼まないのも鉄則です。人間の新人に渡す粒度と同じで、1セッション1タスク。これはコスト面でも効きます。

日本語の指示は精度に影響する？

日本語で指示すること自体は問題ありません。ドキュメントにも日本語ページが用意されています。

ただし、精度が落ちるのは日本語だからではなく、日本語で書くと指示が曖昧になりがちだからです。「いい感じにリファクタして」は日本語でも英語でも失敗します。

実務的な折衷案はこれ。

• 背景・意図の説明は日本語で丁寧に
• ファイルパス・関数名・コマンドは原文のまま
• 完了条件は箇条書きで、日本語でも構わないので検証可能に書く

自然言語の指示設計そのものに慣れたいなら、汎用のAIアシスタントで練習しておくと転用が効きます。指示の分解の仕方はMeta AIの使い方ガイドでも触れている考え方と共通しています。

症状別・対処の早見表

ここまでの内容を、現場で開いて使える形にまとめます。

つまり、上4行は設定作業で確実に戻せる領域、下3行は運用ルールで再発を防ぐ領域という住み分けになります。

30分でやる切り分け手順

原因の見当がまったく付かないときは、この順番で機械的に潰してください。推測より順番です。

1. 0〜5分: 使用量とACU残を確認。ゼロなら終了、枠を足す
2. 5〜10分: 新規セッションで「READMEを読んで要約して」だけ実行。これが通れば実行環境は生きている
3. 10〜20分: 同じリポジトリで環境構築だけ走らせる。ここで落ちればblueprintsの問題で確定
4. 20〜25分: 空コミットでPRを1本作らせる。出なければGitHub権限の問題
5. 25〜30分: Slackから同じ依頼を投げる。反応が無ければSlack連携の問題

手順2が通って手順3で落ちるなら、直すべきは構成ファイルだけ。範囲が確定するだけで作業は一気に楽になります。

再発防止としては、環境構築の定義をリポジトリ側で管理して、変更をレビュー対象に含めるのが有効です。ツール設定を個人の管理画面に閉じ込めると、担当者が抜けた瞬間に誰も直せなくなります。この手の「属人化した設定を棚卸しする」話は、社内監査向けAIツールの記事で扱っている考え方がそのまま使えます。

直らないときに乗り換えを検討する基準

正直に言うと、Devinが向いていない作業を無理に投げ続けているケースもあります。

Devinの強みは、独立した仮想マシンの中で人間の手を離れて完結できること。いわゆる投げっぱなしのタスク向きです。逆に、手元のコードを対話しながら少しずつ直す作業では、ローカル環境で動く道具のほうが速くて安いのが実情です。

つまり、コストと制御の細かさを取るならローカル型、放置できることを取るならDevin。この軸で選べば失敗しません。並べて検討したいならAIコーディングツールのランキングが早いです。

AI PICKS編集部の判定

Devinの「動かない」報告のうち、本当にDevin側の不具合と言えるものは体感で1割あるかどうか。残りは設定・権限・クレジットで、しかもその大半が2026年6月30日のClassic environment setup廃止に紐づく移行漏れです。ここを片付けずに再実行を繰り返している人が多すぎます。

道具としての評価は、はっきり分かれます。投げっぱなしにできる自律性は破格で、独立した仮想マシンで完結する設計は他に代えが効きません。一方で、対話しながら細かく直したい人には正直イマイチ。ACU課金の性質上、試行錯誤の回数がそのままコストになるからです。

だから判定はこうなります。Devinは「仕様が固まったタスクをまとめて渡す係」として使うなら一択。探索的な作業は別の道具に持たせるべきです。この線引きをせずに全部Devinに投げている組織ほど、「動かない」と「高い」を同時に抱えています。

そして環境構築の定義だけは、面倒でも最初に正しく作ってください。ここが雑なままだと、この記事のチェックリストを何度も往復することになります。

よくある質問（FAQ）

Q. Devinが急に動かなくなりました。何から見ればいいですか？

使用量とACU残です。クレジット切れは目立つエラーを出さずに止まるため、原因不明に見えやすい症状の代表格。残量に問題が無ければ、新規セッションで軽いタスクを1本流して実行環境が生きているか確認してください。

Q. 環境構築（setup）が毎回失敗します

2026年6月30日でClassic environment setupが廃止され、宣言的構成（blueprints）へ全面移行しました。古い方式の設定が残っていると失敗します。classic machine configurationは2026年7月31日まで読み取り専用で参照できるので、中身を見ながら書き直すのが現実的です。

Q. 作業は完了しているのにGitHubにPRがありません

GitHub Appの権限を確認してください。リポジトリ単位のインストール漏れ、書き込み権限の不足、ブランチ保護、そしてSAML SSOの認可切れ。この4つで説明が付くことがほとんどです。

Q. Slackでメンションしても無視されます

Devinアプリがそのチャンネルに招待されているか確認してください。プライベートチャンネルで漏れやすい部分です。Devinがセッション中にSlackを操作すると、ワークログに専用アイコンつきで表示されます。表示が一切無いなら、チャンネルを読めていない証拠です。

Q. ACUの消費を減らすコツはありますか？

終わったセッションを畳むこと、1セッションに1タスクしか渡さないこと、調査だけの用途を別の道具に逃がすことの3つ。アイドル時やsleep時の消費の扱いは公式の請求ドキュメントに明記されているので、運用ルールを作る前に一度読んでおくと無駄が減ります。

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

日本語自体は問題ありません。落ちるのは指示が曖昧になったときです。ファイルパスや関数名は原文のまま書き、完了条件を検証可能な形にすれば、日本語のままでも結果は安定します。

Q. エラーは出ないのに成果物が的外れです

Interactive Planningで提案される計画を、着手前に読んで直してください。計画を素通りさせると解釈のズレがそのまま実装されます。変更してよい範囲と、やってほしくないことを1行ずつ書き添えるだけでも精度が変わります。

Q. Devinの代わりになるツールはありますか？

用途次第です。手元で対話しながら直したいならClaude CodeやCursor、既存のエディタを変えたくないならGitHub Copilot。投げっぱなしにできる自律性が要らないなら、ローカル型のほうが安く済みます。

次に読むならこれ。 Devinを諦めて手元で作業する方向に振るなら、AIコーディングツールのカテゴリ一覧から自分の開発スタイルに合う1本を選ぶのが早道です。エージェント型とエディタ内蔵型で運用コストがまるで違うので、乗り換え前に必ず比べてください。

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

• Devin — 独立した仮想マシンで作業を完結させる自律型エージェント。本記事の主役です
• Claude Code — ローカル環境で動くタイプ。細かい制御が効きます
• Cursor — エディタ一体型。対話しながら直したい人向け
• Codex CLI — ターミナルで完結させたい人の選択肢
• AIコーディングツールカテゴリ — 開発支援ツールを横断で確認できます
• AIエージェントランキング — 自律型エージェント全般の比較に
• AIエージェントカテゴリ — コーディング以外の自律エージェントも探せます

Webサービスを作り切るところまでDevinに任せるなら、素材の用意も並行して必要になります。挿絵やアイコンを外注せずに揃えたい場合はAIイラスト生成ツールのまとめが使えます。

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

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

• Devin — 公式サイト（AI PICKSの詳細）
• Cursor — 公式サイト（AI PICKSの詳細）
• Claude Code — 公式サイト（AI PICKSの詳細）
• GitHub Copilot — 公式サイト（AI PICKSの詳細）
• Windsurf — 公式サイト（AI PICKSの詳細）