AI による開発支援は、コード片の候補を提示する段階から、開発作業の一部を実際に進める段階へ移っている。以前の補完型の利用では、AI が出した候補を人間が読んで採用するだけで済む場面が多かった。しかし、AI がリポジトリを読み、依存関係を調べ、シェルを実行し、テストを回し、差分を作り、レビュー可能な形にまとめるようになると、問題の焦点は変わる。問われるのは「どの AI が賢いか」だけではなく、AI がどの環境で動き、どの権限を持ち、どの単位で作業を進め、どの時点で人間が止められるかである。
この変化には、少なくとも二段階の因果関係がある。第一に、基盤モデルのコード理解力と長文処理能力が上がったことで、AI は短い関数や設定例を返すだけでなく、既存のコードベース全体を参照しながら作業できるようになった。第二に、シェル、エディタ、Git、課題管理、継続的インテグレーション、外部ツール接続が AI の作業環境へ組み込まれたことで、AI の出力は文章やコード断片から、変更差分、実行結果、Pull Request に近い成果物へ変わった。能力が上がったから作業範囲が広がり、作業範囲が広がったから責任境界が問題になる。この順序を押さえないと、AI コーディングエージェントの比較は、表面的な機能一覧にとどまる。
ここでいう責任境界とは、法的責任だけを指す言葉ではない。開発作業の中で、仕様を読むのは誰か、変更範囲を決めるのは誰か、テスト失敗の意味を解釈するのは誰か、差分を採用するのは誰か、障害時に戻す判断をするのは誰か、という実務上の境界である。AI が作業を進めるほど、この境界は見えにくくなる。コードを書いたのは AI でも、それをマージするのは人間であり、運用環境に流れるのは組織の成果物である。したがって、AI に作業を任せることは、人間の判断が消えることではなく、人間の判断が前後や途中のどこに配置されるかが変わることを意味する。
この問いは、AI を使う前に人間が何を決めるべきかという既稿の問題意識とつながっている。AI の出力を有効に使うには、問いの切り方、判断軸、優先順位、任せない領域を先に定める必要がある。ソフトウェア開発では、この抽象的な問題がより具体的に現れる。仕様をどこまで固めるのか、変更範囲を誰が決めるのか、テスト結果をどう読むのか、レビューで何を確認するのか。AI コーディングエージェントを使うことは、開発者の手を速くするだけではなく、作業と判断の境界を引き直すことでもある[1]。
2026 年 7 月時点で、この構造を考えるうえで対照的な対象が Devin と Claude Code である。Devin は Cognition が「AI ソフトウェアエンジニア」として打ち出した製品であり、シェル、コードエディタ、ブラウザを備えた隔離された計算環境で、計画、実装、テスト、修正を進めるものとして説明されている[2]。この位置づけで重要なのは、Devin が単なるチャット欄ではなく、作業場を持つ点である。作業場を持つということは、ファイルを読み、コマンドを実行し、結果を観察し、次の操作へ進むという開発者に近い手順を AI 側へ移せることを意味する。
Devin の公式ドキュメントも、コードの作成、実行、テストを自律的に行い、Linear や Jira のチケット対応、機能実装、バグ再現と修正、社内ツール構築などを任せる対象として挙げている[3]。ここから見えるのは、Devin が「会話の相手」よりも「タスクの委任先」として設計されていることである。チケット、調査、修正、テスト、成果物の提出という流れに乗るほど、Devin の構造は機能しやすい。逆に言えば、渡す前のタスク記述が粗い場合、その曖昧さを AI が独自に解釈したまま作業を進める危険も生じる。
一方の Claude Code は、Anthropic の Claude を開発作業へ組み込む道具である。Claude 4 の発表時には、Claude Code が一般提供となり、ターミナル、IDE、SDK を通じて開発ワークフローへ入ることが示された[4]。ここで重要なのは、Claude Code が開発者の外側に別の作業場を作るというより、開発者が普段使う環境の中へ入る点である。ターミナルや IDE の中で AI が動くため、既存のファイル構成、ローカルの実行手順、開発者の確認、差分の読み取りと結びつきやすい。
公式ドキュメントでは、Claude Code はターミナル、VS Code、デスクトップアプリ、Web、JetBrains 系 IDE など複数の環境で利用でき、ファイル編集、コマンド実行、プロジェクト管理を開発者の作業場の中で行うものとして説明されている[5]。この設計では、AI は作業を丸ごと引き取るというより、人間が見ている場所で作業を進める。変更前に確認し、差分を読み、追加指示を出し、必要なら方針を変える。このような使い方では、人間の関与は減るのではなく、より高い粒度の判断へ移る。
したがって、Devin と Claude Code の比較では、同じ「AI コーディングエージェント」という呼び名の内側を分解する必要がある。Devin は、作業環境を切り出し、チケットに近い単位で AI に委任する方向へ寄っている。Claude Code は、開発者の既存環境に入り、対話と差分確認を通じて人間と併走する方向へ寄っている。両者の差は、単なる製品仕様の違いではなく、曖昧さをどこで処理し、人間がどの時点で判断を残すかという作業構造の違いである。
1. 比較の要点は、製品差ではなく作業構造の差にある
Devin と Claude Code は、どちらも AI コーディングエージェントと呼べる。ここでいうエージェントとは、人間の質問に一回だけ答える仕組みではなく、目的に向けて手順を組み立て、道具を使い、実行結果を見て次の操作を選ぶ仕組みである。開発作業では、この道具にリポジトリ、シェル、エディタ、テスト、Git、課題管理、外部サービスが含まれる。つまり、AI コーディングエージェントを比較するとは、モデルの返答品質だけを見ることではなく、AI がどの作業面に置かれ、どの道具を持ち、どの段階で人間の承認を受けるかを見ることである。
同じ呼び名を与えると、両者の差は見えにくくなる。たとえば、どちらもコードを読める、ファイルを編集できる、コマンドを実行できる、Git と関われる、と書くことはできる。しかし、その機能が置かれる場所は異なる。Devin では、AI が隔離された作業場を持ち、タスクを受けてから調査、実装、検証へ進む。Claude Code では、AI が開発者の作業場に入り、開発者が差分と実行結果を見ながら指示を重ねる。この差は、機能の有無ではなく、作業の渡し方と確認の仕方の差である。
| 観点 | Devin | Claude Code | 構造上の意味 |
|---|---|---|---|
| 作業環境 | 専用の隔離された計算環境で作業を進める。 | 開発者のローカル環境、ターミナル、IDE、CI 環境に入る。 | Devin は作業場を切り出す設計であり、Claude Code は既存の作業場を拡張する設計である。 |
| 作業の進め方 | タスクを渡し、AI が非同期に調査、実装、検証を進める。 | 開発者が対話しながら、差分確認と方針修正を挟んで進める。 | Devin は事前のタスク定義を重くし、Claude Code は途中の判断と修正を重くする。 |
| 人間の介入点 | 主にタスク投入前と成果物レビュー時に置かれる。 | ファイル変更、コマンド実行、差分確認、方針変更の途中に置かれる。 | Devin は前後の統制に向き、Claude Code は工程中の統制に向く。 |
| 失敗の形 | 仕様を誤解したまま、まとまった作業として進んでしまう危険がある。 | 確認が増えたり、対話の方向がぶれたりして、作業が細かく止まる危険がある。 | 委任型の失敗は後から大きく見つかりやすく、併走型の失敗は途中で小さく現れやすい。 |
この表から見える直接の違いは、Devin が「作業を渡す」構造を強く持ち、Claude Code が「作業中に関与する」構造を強く持つことである。さらに一段深く見ると、この違いは曖昧さの処理位置に由来する。作業を渡すには、事前に目的、制約、変更範囲、完了条件をある程度閉じる必要がある。作業中に関与するなら、最初からすべてを閉じなくても、実行結果や差分を見ながら判断を補える。つまり、Devin と Claude Code の違いは、自律性の大小というより、曖昧さを事前に処理するか、工程中に処理するかの違いである。
この違いは、生成 AI の競争軸がモデル単体から業務実装へ移るという既稿の整理とも重なる。モデルがどれだけ自然な文章やコードを出せるかだけでは、業務上の価値は決まらない。どのデータに接続し、どの権限を持ち、どのワークフローに入り、誰が確認し、どの形式で記録されるかが成果を左右する[6]。Devin と Claude Code の差も、この業務実装の差として読むと立体的になる。Devin は、チケット、作業環境、Pull Request、レビューという流れに AI を置く。Claude Code は、ターミナル、IDE、差分確認、コマンド実行、逐次指示という流れに AI を置く。どちらも AI を開発へ入れるが、入る場所が異なる。
この構造をさらに一般化すると、AI コーディングエージェントの比較で重要なのは、製品名ではなく作業成立条件である。作業成立条件とは、ある作業が実務として安全に、検証可能に、後から説明可能に進むための条件である。明確なチケット、再現手順、テスト、レビュー基準が揃っているなら、作業は委任しやすい。仕様が揺れており、既存コードの意図を読みながら変更範囲を決める必要があるなら、途中で人間が関与できる構造が必要になる。したがって、Devin と Claude Code の選択は、どちらの AI が優れているかという単純な比較ではなく、対象となる開発作業がどのような曖昧さを含み、その曖昧さをどの段階で処理できるかという判断になる。
ここで注意すべきなのは、委任型が高度で、併走型が未熟という序列ではないことである。明確に切り出された作業では、途中の確認を減らして非同期に進める方が効率的である。一方、設計判断や仕様解釈を含む作業では、途中で人間が関与できる方が安全である。第一段階では、タスクの性質が適した作業構造を決める。第二段階では、その作業構造が、必要な権限、確認点、レビュー方式、費用単位を決める。ここまで見ると、AI コーディングエージェントの導入は、単なるツール選定ではなく、開発プロセスの再設計であることが分かる。
2. 現時点の比較軸
Devin と Claude Code を比較するには、機能名だけを並べても足りない。シェルを使える、ファイルを編集できる、Git と連携できる、外部ツールに接続できる、といった項目は一見似ている。しかし、同じ機能名でも、その機能が置かれる作業環境、人間が介入する時点、成果物として確定される単位が違えば、実務上の意味は変わる。たとえば、同じ「ファイル編集」でも、隔離された作業環境で AI がまとまった差分を作る場合と、開発者の IDE 上で一つずつ確認しながら変更する場合では、失敗の見つかり方も、レビューの粒度も、作業を任せられる範囲も異なる。
この違いには、二段階の因果関係がある。第一に、実行環境が違うと、AI が参照できる情報、使える道具、到達できる範囲が変わる。第二に、その到達範囲が変わると、人間の承認、監査、レビュー、ロールバックの設計も変わる。したがって、比較軸は「何ができるか」だけではなく、「どこで動くか」「どの作業単位を引き受けるか」「どの時点で人間が判断するか」「失敗したときにどこで止まるか」まで含めて立てる必要がある。
ここで重要なのは、比較軸を製品機能の一覧ではなく、開発作業の構造として読むことである。実行環境は、AI と人間の責任境界を決める。動作モデルは、作業を事前に委任するのか、途中で調整するのかを決める。Git 連携は、成果物がどの単位でレビュー対象になるかを決める。安全設計は、事故を環境単位で抑えるのか、行為単位で止めるのかを決める。コスト構造は、AI に作業量を買うのか、開発者の作業時間に重なる支援能力を買うのかを示す。これらは別々の仕様ではなく、AI をどのような作業主体として開発過程に入れるかを示す一連の設計である。
| 観点 | Devin | Claude Code | 構造上の意味 |
|---|---|---|---|
| 位置づけ | AI ソフトウェアエンジニアとして、一定の作業単位を委任される存在として設計されている。 | 開発者の作業環境に入り、対話しながら実装、調査、修正を支援する道具として設計されている。 | Devin は作業の外部委任に近く、Claude Code は開発者の能力拡張に近い。 |
| 実行環境 | シェル、コードエディタ、ブラウザを備えた専用の計算環境で作業する。 | ターミナル、IDE、デスクトップ、Web、CI 環境など、開発者の既存環境に入る。 | Devin は作業場を切り出すことで委任しやすくし、Claude Code は既存環境へ入ることで文脈を読みやすくする。 |
| 動作モデル | タスクを渡して進めてもらい、結果を確認する非同期委任に向く。 | 差分を確認しながら進める同期的・対話的な併走に向く。 | Devin は事前のタスク定義を重くし、Claude Code は作業途中の判断と修正を重くする。 |
| Git 連携 | Pull Request の作成、レビューコメントへの応答、CI 結果の反映までをチームの開発フローに載せやすい。 | 差分確認、コミット、Pull Request 作成を支援できるが、人間が変更粒度を握りやすい。 | Devin は成果物をまとまったレビュー対象として出しやすく、Claude Code は変更を小さく刻んで確認しやすい。 |
| 安全設計 | 作業環境を切り出すことで、事故の範囲を環境単位で限定する発想が強い。 | 読み取り、編集、コマンド実行などの行為単位で許可を与える発想が強い。 | Devin は環境境界で止める設計に寄り、Claude Code は操作ごとの承認で止める設計に寄る。 |
| 得意な作業 | 依存関係更新、定型修正、移行、チケット処理、繰り返し作業の並列処理に向く。 | 既存コードの文脈理解、複数ファイルにまたがる修正、探索的な設計判断に向く。 | Devin は完了条件が明確な作業に向き、Claude Code は作業中に意味を確認する必要がある作業に向く。 |
| 失敗しやすい形 | 曖昧な指示を誤って解釈したまま、まとまった作業として完走する危険がある。 | 人間の確認が多くなり、承認疲れや漫然とした許可が起きる危険がある。 | Devin の失敗は後から大きく見つかりやすく、Claude Code の失敗は途中の判断疲れとして現れやすい。 |
| 費用感 | AI に作業量を委任して買う感覚に近い。 | 開発者の作業時間に重なる支援能力を買う感覚に近い。 | Devin は作業単位の費用対効果が問題になり、Claude Code は継続利用時の支援密度が問題になる。 |
Devin の公式サイトは、複雑な複数リポジトリのプロジェクトを持つ開発チーム向けであること、コード移行やリファクタリング、定期作業、障害調査、CI 失敗の修正などを用途として挙げている[7]。この説明から見えるのは、Devin が単発の補完機能ではなく、チーム内の作業単位を引き受ける方向に設計されていることである。ここでいう作業単位とは、単一の関数生成ではなく、課題管理上のチケット、調査すべき障害、修正すべき依存関係、移行すべきコード群のように、開始条件と完了条件を持つまとまりである。
この作業単位の違いは、導入効果にも直結する。第一に、タスクが明確に切り出されているほど、AI は独立して動きやすくなる。なぜなら、目的、制約、確認方法が先に与えられていれば、AI は実行結果をその条件に照らして評価できるからである。第二に、独立して動ける作業が多いほど、組織は AI を人間の横に置く補助道具ではなく、処理能力を増やす作業主体として扱いやすくなる。したがって、Devin の価値は、モデルの性能だけでなく、組織側がタスクをどれだけ明確に分解できるかに依存する。
Claude Code の比較軸は、別の方向から読む必要がある。Claude Code は開発者の環境に入り、差分を見ながら作業する構造を持つため、最初から完了条件を完全に閉じられない作業に向きやすい。たとえば、既存コードの責務分割を見直す場合、どの関数を移動するか、どの命名を残すか、テストの失敗が仕様変更によるものか実装ミスによるものかは、作業前にすべて決められないことが多い。このような場合、AI が途中で提案し、人間が差分を読み、必要に応じて方針を変えることに意味がある。
したがって、2026 年 7 月時点の比較軸は、単に「Devin は自律型、Claude Code は対話型」と要約するだけでは不十分である。自律型と対話型という言い方は入口としては有効だが、それだけでは、なぜ向く作業が違うのか、なぜ安全設計が違うのか、なぜ費用感が違うのかまで説明できない。より正確には、Devin は曖昧さを事前に処理してから委任する構造であり、Claude Code は曖昧さを作業中に処理しながら進める構造である。この違いが、実行環境、Git 連携、安全設計、タスク適性、コストのすべてに反映されている。
3. 実行環境は、責任境界を決める
実行環境は、AI コーディングエージェントの性格を決める最初の分岐である。ここでいう実行環境とは、単に AI がどの計算資源を使うかという意味ではない。どのファイルを読めるのか、どのコマンドを実行できるのか、どの認証情報に触れられるのか、どのネットワークや外部サービスへ到達できるのか、そして失敗したときに影響範囲をどこで止められるのかを含む。つまり、実行環境は、AI が作業できる範囲を決めると同時に、人間が責任を持って監督すべき範囲も決める。
この点で、Devin の大きな特徴は、作業場を AI 側に持つことである。Cognition の発表では、Devin はシェル、コードエディタ、ブラウザを備えた隔離された計算環境を持つと説明されている。これは、人間の開発者が使う基本的な道具一式を AI に与えながら、その作業場を人間のローカル環境や本番環境から切り離す設計である。作業に必要な道具を与えつつ、影響範囲を専用環境へ閉じ込める。ここに、Devin の委任型の性格が表れている。
この設計には、二段階の因果関係がある。第一に、AI が専用の作業場を持つことで、人間はタスクをまとまりとして渡しやすくなる。リポジトリを読み、コマンドを実行し、ブラウザで確認し、テスト結果を見て修正する一連の流れを、同じ環境の中で進められるからである。第二に、作業場が切り出されていることで、AI の試行錯誤が人間の通常環境や本番環境へ直接波及しにくくなる。つまり、作業場の独立性は、委任のしやすさと事故範囲の限定を同時に支える。
ただし、環境を切り出せば、それだけで安全になるわけではない。切り出された環境にも、リポジトリ、依存関係、認証情報、外部サービス、テストデータが入る。Devin にとっての環境構築は、人間の新しい開発者に開発機を渡すことに近い。公式ドキュメントも、リポジトリと開発環境の設定、環境変数、Secrets、Web サイトへのログイン、Playwright によるブラウザ利用などを扱っている[8]。ここから見えるのは、Devin を使うには、AI に作業させる環境を準備するだけでなく、その環境に何を入れ、何を入れないかを設計する必要があるということである。
| 観点 | Devin の実行環境 | 構造上の意味 |
|---|---|---|
| 作業場 | シェル、コードエディタ、ブラウザを備えた専用環境で作業する。 | AI に人間の開発者に近い道具を与え、タスクをまとまりとして進めやすくする。 |
| 隔離 | 人間のローカル環境や本番環境から切り離された場所で試行錯誤できる。 | 失敗の影響範囲を環境単位で限定しやすくする。 |
| 環境構築 | リポジトリ、依存関係、環境変数、認証情報、ブラウザ操作を設定する必要がある。 | AI にどこまで作業させるかは、環境に何を与えるかによって決まる。 |
| 責任境界 | AI が作業する場所と、人間がレビューする場所が分かれやすい。 | 委任しやすい一方で、事前のタスク定義と事後の成果物確認が重くなる。 |
Claude Code は逆方向の構造を持つ。Claude Code は、AI のために外側の作業場を用意するというより、開発者が普段使う作業場へ AI を入れる。ターミナル、IDE、デスクトップ、Web、CI 環境で動くということは、開発者が見ているファイル、実行しているコマンド、管理している差分、使っているツールの近くで AI が動くということである。これは、作業場を AI に渡すというより、作業場に AI を招き入れる構造である。
この構造にも、二段階の因果関係がある。第一に、AI が既存の開発環境に入ることで、プロジェクト固有の文脈を取り込みやすくなる。ローカルの設定、開発者が普段使う実行手順、既存のテスト方法、IDE 上の差分確認と結びつくためである。第二に、文脈に近づくほど、AI の操作は人間の実作業に近づく。ファイル編集やコマンド実行が開発者の環境内で起きるため、確認、許可、差分確認、取り消しの設計が重要になる。Claude Code の強みは文脈への近さにあるが、その近さは同時に、操作単位での統制を必要とする。
Claude Code の開発コンテナ文書は、コンテナ内でプロジェクトのファイル、依存関係、ツールを利用する構成を説明しており、既存の開発環境に閉じ込められた形で作業する選択肢も示している[9]。開発コンテナは、ローカル環境へ入り込む AI の利点と、隔離された環境で作業させる利点を折衷する仕組みと読める。開発者の環境に近い文脈を保ちながら、依存関係や実行範囲をコンテナ内に収めることで、AI の操作を管理しやすくする。
| 観点 | Claude Code の実行環境 | 構造上の意味 |
|---|---|---|
| 作業場 | 開発者のターミナル、IDE、デスクトップ、Web、CI 環境で動く。 | 人間が普段使う作業環境の中で、AI が調査、編集、実行を支援する。 |
| 文脈 | 既存のファイル構成、実行手順、差分確認、開発ツールに近い位置で作業する。 | プロジェクト固有の判断を、作業途中で人間が補いやすい。 |
| 隔離手段 | 必要に応じて開発コンテナなどを使い、作業範囲を閉じることができる。 | 既存環境への近さと、操作範囲の限定を両立させる設計が必要になる。 |
| 責任境界 | AI の操作が人間の作業場で起きるため、変更前確認や差分確認が重要になる。 | 人間は作業を委任するだけでなく、工程中の判断者として残る。 |
ここから、実行環境の違いは安全性の強弱だけでは説明できないことが分かる。Devin は、環境を切り出すことで委任しやすくなる。Claude Code は、既存環境に入ることで文脈を取り込みやすくなる。前者は、AI を外部化された作業主体として扱いやすい。後者は、AI を人間の作業過程に密着した協働者として扱いやすい。この違いは、どちらが安全かという単純な比較ではなく、どの種類の安全をどこで確保するかの違いである。
Devin 型では、責任境界は環境の外縁に引かれやすい。AI は専用環境の中で試行錯誤し、人間は成果物、差分、テスト結果、Pull Request を見て判断する。Claude Code 型では、責任境界は操作の節目に引かれやすい。AI がファイルを編集する前、コマンドを実行する前、差分を採用する前に、人間が確認する。第一段階では、実行環境が AI の作業範囲を決める。第二段階では、その作業範囲が人間の介入点を決める。したがって、実行環境とは単なる計算資源ではなく、人間と AI の責任境界を設計するための構造である。
4. 動作モデルは、曖昧さの処理位置を変える
動作モデルとは、AI が作業をどの時間軸で進め、人間がどの時点で関与するかを決める構造である。ここでは、AI がどれだけ自律的に見えるかだけが問題ではない。作業を始める前にどこまで条件を与える必要があるのか、作業中にどれだけ方向修正できるのか、作業後にどの粒度で結果を検証するのかが問題になる。Devin と Claude Code の違いは、この動作モデルの違いとして読むと分かりやすい。
Devin は、タスクを渡して進めてもらう非同期委任に向いている。Slack、Jira、Linear、GitHub などから作業を開始し、調査、実装、テスト、Pull Request までを一定の単位として進める。この構造では、人間は常に横に座って指示を出し続けるのではなく、作業前にタスクを定義し、作業後に結果をレビューする位置に移る。つまり、Devin は開発者の手元で逐次確認しながら使う道具というより、作業単位を受け取り、専用環境で進め、成果物を返す委任先として働く。
この非同期委任には、二段階の因果関係がある。第一に、人間が作業中の細かい判断から離れられるため、複数のタスクを並列に流しやすくなる。依存関係更新、CI 失敗の修正、既知の移行作業、再現手順のあるバグ修正のように、開始条件と完了条件が明確な作業では、この利点が大きい。第二に、人間が作業途中から離れるほど、最初に渡したタスク記述の質が成果物の質を強く規定する。目的、制約、変更範囲、優先順位、テスト方法が曖昧であれば、AI はその曖昧さを自分なりに補って進める。したがって、Devin 型の自律性は、作業前の仕様化能力に支えられている。
ここでいう仕様化とは、正式な仕様書を書くことだけではない。何を直すのか、何を変えてはいけないのか、どのテストを確認するのか、既存の挙動をどこまで保つのか、失敗時にどこで止めるのかを、作業前に AI が実行可能な条件として与えることである。人間同士の開発では、曖昧な指示でも途中の会話で補えることがある。しかし、非同期に委任する場合、その途中の補足が弱くなる。だからこそ、Devin に向く作業は、タスクとして閉じられる作業である。
Claude Code は、作業中のやり取りに向いている。ターミナルや IDE 上で、調査させ、差分を見て、指示を追加し、テスト結果を確認し、必要なら方針を変える。Claude Code の公式ドキュメントは、コードベース理解、バグ修正、テスト実行、Pull Request 作成などの一般的な作業フローを示しており、対話しながら開発作業を進める前提が強い[10]。これは、作業を始める前にすべてを閉じるのではなく、作業を進めながら理解を深める構造である。
Claude Code 型の併走にも、二段階の因果関係がある。第一に、AI が開発者の作業場に近い場所で動くため、途中の観察がしやすい。ファイルの差分、テストの失敗、コマンドの出力、変更範囲の広がりを見ながら、開発者はその場で指示を修正できる。第二に、途中で修正できるため、最初の指示が完全でなくても作業を始めやすい。既存コードの責務分割を調べる、壊れたテストの原因を切り分ける、複数ファイルにまたがる命名や構造を見直す、といった作業では、作業前には見えなかった論点が途中で現れる。このような作業では、対話的に進められること自体が安全性になる。
ただし、併走型は人間の負担を消すわけではない。むしろ、人間の負担は、作業前の仕様化から、作業途中の判断へ移る。差分が妥当か、テスト失敗をどう読むか、AI の修正方針が広がりすぎていないか、局所修正で済む問題を構造変更へ拡大していないかを見続ける必要がある。Claude Code は曖昧さを作業中に扱いやすいが、その分、人間には途中で判断を差し込む注意力が求められる。
| 観点 | Devin 型 | Claude Code 型 | 曖昧さの処理位置 |
|---|---|---|---|
| 作業開始 | タスクを定義してから渡す。 | 目的を伝え、調査や修正を進めながら条件を詰める。 | Devin 型では開始前の定義が重く、Claude Code 型では開始後の調整が重い。 |
| 人間の関与 | 作業前の指示と作業後のレビューに寄る。 | 作業中の差分確認、追加指示、方針修正に寄る。 | Devin 型では前後に判断が集まり、Claude Code 型では工程中に判断が分散する。 |
| 向く作業 | 完了条件、変更範囲、確認方法を事前に定義しやすい作業に向く。 | 作業中に論点が見つかり、差分を見ながら判断する作業に向く。 | Devin 型は閉じたタスクに強く、Claude Code 型は探索的なタスクに強い。 |
| 失敗の現れ方 | 誤った解釈のまま、まとまった成果物として返ってくる可能性がある。 | 確認回数が増え、作業が細かく止まり、承認が形式化する可能性がある。 | Devin 型は後で大きく崩れやすく、Claude Code 型は途中で判断疲れが起きやすい。 |
この違いは、曖昧さをどこで処理するかに直結する。Devin 型では、曖昧さは作業を渡す前にできるだけ潰しておく必要がある。完了条件、変更範囲、触ってよいファイル、優先順位、テストの通し方が曖昧なままだと、AI は自分なりの解釈で進める。Claude Code 型では、曖昧さを作業中に扱いやすい。途中で「その方針ではない」「その変更は広すぎる」「このテストだけ先に通す」と調整できる。つまり、Devin は曖昧さを前処理する設計であり、Claude Code は曖昧さを工程内で処理する設計である。
ここから、自律性という言葉の扱いにも注意が必要になる。自律性が高いほど人間の負担が消えるとは限らない。非同期で任せるには、事前の仕様化能力と事後のレビュー能力が強く求められる。併走しながら進めるには、途中で判断を差し込む注意力が求められる。両者は、人間の負担をなくしているのではなく、人間の負担を別の場所へ移している。第一段階では、動作モデルが人間の介入点を変える。第二段階では、その介入点の違いが、必要な能力を変える。Devin 型ではタスク分解とレビューが重要になり、Claude Code 型では差分読解と方向修正が重要になる。
したがって、動作モデルの比較は、単に「放置できるか」「対話が必要か」という利便性の比較ではない。より本質的には、開発作業に含まれる曖昧さを、事前に仕様として閉じるのか、作業中に観察しながら解くのかという違いである。開発作業には、最初から定義できる部分と、手を動かして初めて分かる部分が混在する。Devin と Claude Code の使い分けは、その混在をどの段階で処理するかを選ぶことに等しい。
5. Git と Pull Request は、成果物の確定位置を示す
Git 連携は、AI コーディングエージェントに付属する周辺機能ではない。Git は、ソフトウェア開発において、変更をどの単位で記録し、誰が確認し、どの段階で本流へ取り込むかを決める仕組みである。Pull Request は、その変更をチームのレビュー対象として提示する形式である。したがって、AI が Git や Pull Request にどう関与するかを見ると、AI が単にコード案を出す存在なのか、レビュー可能な成果物をまとめる存在なのかが見えてくる。
この点には、二段階の因果関係がある。第一に、AI がファイルを編集するだけなら、成果物の確定権はまだ人間の手元に強く残る。人間が差分を読み、不要な変更を落とし、コミットの粒度を決め、レビューへ出すかどうかを判断するからである。第二に、AI が Pull Request まで作るようになると、AI は変更案を出すだけでなく、「このまとまりをレビュー対象にできる」と宣言する位置に近づく。つまり、Git 連携の深さは、AI が開発過程のどこまでを成果物として整えるかを示している。
Devin の GitHub 連携は、Pull Request の作成、Pull Request コメントへの応答、リポジトリ内での共同作業を可能にする。公式ドキュメントは、Devin が開発チームの完全な貢献者として機能するようになると説明している[11]。この表現は、単なる自動補完やコード提案とは異なる位置づけを示している。Devin は、作業を進めた結果を、チームがレビューし、議論し、必要なら修正を求められる単位へまとめる。ここでは、AI はコード片の生成者ではなく、Pull Request という開発上の成果物を提出する作業主体に近い。
ただし、Pull Request を作れることは、変更の妥当性が保証されることを意味しない。むしろ、Pull Request としてまとまるからこそ、人間のレビュー責任は重くなる。第一に、AI が作った差分は、構文上は正しく、テストも一部通っているように見える場合がある。第二に、その状態でも、仕様解釈、変更範囲、既存設計との整合、運用上の副作用が誤っている可能性は残る。したがって、Devin 型の Git 連携では、AI が作業をまとめる能力と、人間がそのまとまりを分解して検証する能力が対になる。
Claude Code も GitHub Actions を通じて、Issue や Pull Request への言及からコード解析、Pull Request 作成、機能実装、バグ修正を行える。公式ドキュメントは、GitHub Actions 上で Claude Code を動かすことで、GitHub ワークフローに AI による自動化を入れられると説明している[12]。一方で、日常的な利用では、Claude Code はローカルのターミナルや IDE 上で差分を見ながら使われやすい。この場合、AI は Pull Request を完成品として出す前に、調査、修正案、テスト実行、差分整理を開発者と一緒に進める。
この構造では、成果物の確定位置が工程中へ寄る。開発者は、AI に調査させ、修正させ、差分を見て、変更が広がりすぎていれば戻し、コミットを小さく分け、必要な部分だけを採用できる。第一に、AI の作業が細かい差分として現れるため、誤りを途中で見つけやすい。第二に、その分、開発者は差分を読み続け、採用範囲を決め続ける必要がある。Claude Code 型では、Pull Request の前に、人間が成果物の形を刻んでいく余地が大きい。
| 観点 | Devin 型 | Claude Code 型 | 成果物の確定位置 |
|---|---|---|---|
| 変更のまとまり | タスク単位で作業を進め、まとまった差分として提示しやすい。 | 作業途中の差分を見ながら、開発者が採用範囲を調整しやすい。 | Devin 型では成果物が後段でまとまり、Claude Code 型では成果物が工程中で形成される。 |
| Pull Request | AI がレビュー対象となる Pull Request を作る位置に立ちやすい。 | AI は Pull Request 作成も支援できるが、日常利用では人間が差分とコミット粒度を握りやすい。 | Devin 型では AI が作業完了を宣言しやすく、Claude Code 型では人間が完了形を調整しやすい。 |
| レビュー | 人間は提出されたまとまりを、仕様、設計、テスト、影響範囲から検証する。 | 人間は作業中に差分を読み、必要に応じて方針や変更範囲を修正する。 | Devin 型では事後レビューが重くなり、Claude Code 型では途中レビューが重くなる。 |
| 失敗の現れ方 | まとまった Pull Request として返ってきた後に、仕様誤解や過剰変更が見つかることがある。 | 作業途中で差分が増えすぎたり、確認が細かくなりすぎたりすることがある。 | Devin 型では大きな単位で誤りを見つけやすく、Claude Code 型では小さな判断が積み重なりやすい。 |
ここから、両者の成果物の作り方が分かる。Devin は、まとまった作業単位を Pull Request として提示しやすい。Claude Code は、作業途中の差分を人間が刻みながら固めやすい。前者は、チケット駆動の開発に乗りやすい。後者は、探索的な修正や設計判断を含む作業に向く。違いは、Git に対応しているかどうかではなく、AI が変更をどの粒度でまとめ、人間がどの粒度で確認できるかにある。
この違いは、曖昧さの処理位置ともつながる。Devin 型では、タスクが Pull Request というまとまりへ変換されるため、作業前に完了条件を定義しておく意味が大きい。完了条件が曖昧なままだと、AI は自分なりの単位で差分をまとめてしまう。Claude Code 型では、Pull Request になる前の段階で差分を調整できるため、作業中に「ここまでで止める」「この修正は別に分ける」「この変更は採用しない」と判断しやすい。第一段階では、Git 連携の形が成果物の粒度を決める。第二段階では、その成果物の粒度が、人間のレビュー責任と曖昧さの処理方法を決める。
したがって、Git と Pull Request の比較は、開発フロー上の便利機能を比べる話ではない。AI がどの段階で作業完了を宣言し、人間がどの段階でその宣言を検証するかを比べる話である。Devin は、AI が作業をまとめて提出する力を強く持つ。Claude Code は、人間が作業途中で差分を読み、成果物の形を調整する余地を強く持つ。この差は、AI に作業を任せることと、AI の成果物を採用することが別の判断であることを示している。
6. 外部ツール接続は、業務実装の深さを決める
AI コーディングエージェントが開発現場で価値を持つには、コードだけを読めれば十分というわけではない。実際の開発作業では、Issue、チケット、設計書、ログ、監視結果、社内文書、クラウド環境、データベース、認証情報、CI 結果が互いに結びついている。バグ修正ひとつを見ても、コードだけを見て原因が分かるとは限らない。関連する Issue を読み、過去の Pull Request を確認し、失敗した CI のログを追い、監視画面のエラー傾向を見て、必要ならデータベースの状態を確認する。AI がどの道具に接続できるかは、AI がどこまで実際の開発作業に入り込めるかを決める。
この点には、二段階の因果関係がある。第一に、AI が参照できる情報源が増えるほど、作業の前提を取り違えにくくなる。コードだけを見て推測するのではなく、チケット、ログ、設計書、CI 結果を突き合わせられるからである。第二に、AI が実行できる道具が増えるほど、作業は提案から実行へ近づく。単に「こう直すべき」と述べるのではなく、実際にブランチを作り、テストを実行し、Pull Request を作り、レビューコメントへ応答できるようになる。情報源への接続は理解を深め、実行道具への接続は作業範囲を広げる。この二つが揃うことで、AI は文章生成やコード補完を超えて、業務フローの中で動く存在になる。
Devin の統合機能は、ソース管理、コミュニケーション、プロジェクト管理、MCP、Secrets Manager、API 統合に広がっている。公式ドキュメントは、GitHub、Slack、Jira のような直接統合だけでなく、MCP を通じて外部ツールやデータソースへ接続する仕組みも示している[13]。ここで重要なのは、Devin がコードを書く道具としてだけではなく、チームが使う業務道具の中へ作業主体として入るように設計されていることである。チケットを読み、リポジトリを操作し、必要な情報を取得し、成果物をレビュー可能な形にまとめる。これは、開発者が日常的に行っている作業導線を、AI 側にも与える設計である。
MCP は、この構造を理解するための重要な要素である。MCP は、AI が外部の道具やデータソースへ接続するための共通的な接続方式として位置づけられる。ここで重要なのは、MCP を単なる拡張機能として見ないことである。外部ツールへの接続方式が標準化されると、AI は個別のサービスごとに閉じた補助機能ではなく、複数の業務道具を横断して作業する仕組みに近づく。つまり、MCP は AI の作業範囲を広げるための技術であると同時に、AI がどの範囲へ到達できるかを設計するための権限境界でもある。
Claude Code も MCP を通じて外部ツールへ接続できる。Claude Code の MCP 文書は、ローカルやリモートの MCP サーバー、プロジェクトスコープの設定、OAuth、ツールの明示的な許可などを扱っている[14]。ここで注目すべきなのは、外部ツール接続が開発者の作業環境と結びついている点である。Claude Code は、ローカル環境や IDE の中で作業しながら、必要に応じて外部の情報源や道具へ接続できる。これにより、開発者は AI に調査させ、取得された情報を見て、次の変更方針を決めることができる。
| 観点 | Devin | Claude Code | 構造上の意味 |
|---|---|---|---|
| 接続の位置 | AI が委任された作業を進めるために、チームの業務道具へ接続する。 | 開発者の作業環境から、必要な外部ツールや情報源へ接続する。 | Devin は作業主体として業務フローへ入り、Claude Code は開発者の作業場を外部情報へ広げる。 |
| 情報源 | チケット、リポジトリ、コミュニケーション、プロジェクト管理、外部データソースを作業単位に結びつける。 | プロジェクトに必要なローカル情報、外部ツール、リモート接続先を対話的に参照する。 | 情報源の接続は、AI の判断材料を増やし、コードだけに基づく推測を減らす。 |
| 実行範囲 | 作業の開始から成果物提出までを、外部ツールと連動して進めやすい。 | 調査、修正、確認、追加指示を、開発者の判断を挟みながら進めやすい。 | 外部ツール接続は、AI の出力を提案から実行へ近づける。 |
| 権限境界 | AI に作業を任せるため、接続先と認証情報の範囲設計が重要になる。 | ツールごとの許可、プロジェクトスコープ、認証方式、明示的な承認が重要になる。 | 接続が増えるほど、能力だけでなく事故範囲も広がるため、権限設計が中核になる。 |
外部ツール接続は、便利な連携機能としてだけ見ると本質を見誤る。AI がチケットを読み、監視ログを調べ、Pull Request を作り、データベースに接続できるなら、それは開発者の作業導線を部分的に再現している。第一に、AI はコードの外側にある業務文脈を参照できるようになる。第二に、その文脈を使って、コード変更、検証、報告、レビュー対応へ進めるようになる。したがって、外部ツール接続の深さは、AI がどれだけ実務の作業過程に組み込まれているかを示す。
ただし、外部ツール接続が深くなるほど、リスクも同時に深くなる。AI がログを読めるだけなら、誤読による判断ミスが主な問題になる。AI がチケットを変更できるなら、誤った状態更新や不適切なコメントが問題になる。AI がデータベースやクラウド環境へ触れられるなら、データ破壊、権限逸脱、機密情報の露出、予期しない操作が問題になる。第一段階では、接続先が増えることで作業能力が増える。第二段階では、作業能力が増えることで、統制すべき事故範囲も広がる。能力の拡張と責任範囲の拡張は、同時に起きる。
このため、AI コーディングエージェントの導入では、外部ツール接続を「多ければよい」と評価してはならない。重要なのは、どの作業にどの接続が必要で、どの権限は不要かを分けることである。チケットを読む権限、コメントを書く権限、Pull Request を作る権限、CI を再実行する権限、シークレットへアクセスする権限、データベースを更新する権限は、それぞれ意味が違う。読むだけの接続と、状態を変える接続は区別しなければならない。参照できることと、実行できることは、同じ接続ではあっても責任の重さが異なる。
ここから、外部ツール接続は業務実装の深さを決めるという結論に至る。AI の能力は、モデル内部の推論能力だけで決まらない。どの情報源に接続され、どの道具を使え、どの権限を持ち、どの操作で人間の承認を必要とするかによって決まる。Devin は、AI を委任された作業主体として業務道具へ接続する方向に寄っている。Claude Code は、開発者の作業環境を AI と外部ツールで拡張する方向に寄っている。どちらの場合も、外部ツール接続は単なる便利機能ではなく、AI が実務の中でどこまで作業できるか、そして人間がどこで責任を保持するかを決める構造である。
7. 安全性は、環境で止めるか、行為ごとに止めるかに分かれる
AI がコードの候補を出すだけなら、誤りは主に差分の品質問題として扱える。人間が候補を読み、不要なら採用しなければよいからである。しかし、AI がファイルを編集し、コマンドを実行し、依存関係を変更し、外部サービスへ接続する段階に進むと、安全性は開発プロセスの中心問題になる。危険なのは、AI が間違えることそのものに限られない。間違えた判断が、実行権限と結びつき、ファイル、設定、データ、外部サービスの状態を変えられることが問題になる。
この危険には、二段階の因果関係がある。第一に、AI が触れる対象が広がるほど、誤りの影響範囲も広がる。コード生成の誤りはレビューで見つけられる可能性があるが、コマンド実行、依存関係更新、設定変更、外部サービス操作は、実行された時点で状態を変える。第二に、状態を変える操作が増えるほど、人間の確認は「正しそうなコードか」を読むだけでは足りなくなる。何を実行しようとしているのか、どのファイルを変えるのか、どの権限で動くのか、失敗した場合にどこまで戻せるのかを確認する必要が出てくる。したがって、安全性は、AI の出力品質ではなく、AI の到達範囲と停止点の設計として考える必要がある。
Devin の安全性は、作業環境を切り出す発想と相性がよい。AI は専用環境で作業し、調査、実装、テストを進め、結果を Pull Request などの形で人間に返す。この構造では、AI の試行錯誤を人間のローカル環境や本番環境から切り離しやすい。つまり、AI がどれだけ多くの手順を試しても、その作業が専用環境の内側に収まっていれば、事故の範囲を環境境界で限定しやすい。
ただし、環境を切り出すことは、危険を消すことではない。第一に、Devin の作業環境には、リポジトリ、依存関係、環境変数、Secrets、外部サービスへの接続設定が与えられることがある。第二に、それらの権限設定が広すぎれば、専用環境であっても、外部のリポジトリ、チケット、クラウド、認証情報へ影響が及ぶ。したがって、Devin 型の安全性は、サンドボックスの存在だけで成立するのではなく、どのリポジトリを接続するか、どの Secrets を渡すか、どの外部サービスへ到達させるかという環境設計に依存する。
Claude Code の安全性は、行為単位の許可に強く依存する。公式ドキュメントは、Claude Code が標準では読み取り専用の権限を使い、ファイル編集、テスト実行、コマンド実行など追加の行為には明示的な許可を求めると説明している。また、システムを変更しうる Bash コマンドには承認が必要であり、一部の読み取りコマンドは確認なしに実行できる[15]。これは、AI の作業場全体を大きく隔離するというより、AI が何かを実行しようとするたびに、その行為を止められるようにする設計である。
この行為単位の許可にも、二段階の因果関係がある。第一に、ファイル編集やコマンド実行の前に承認を挟めば、危険な操作を実行前に止められる。これは、AI が開発者の既存環境に近い場所で動く場合に重要である。第二に、承認が細かくなりすぎると、人間は内容を読まずに許可し始める。確認画面が多すぎると、一つ一つの意味を検証する負荷が高くなり、承認が実質的な判断ではなく操作習慣になる。行為単位の安全設計は、人間が意味のある確認をできる粒度で設計されなければならない。
| 観点 | Devin 型 | Claude Code 型 | 安全設計上の意味 |
|---|---|---|---|
| 停止点 | AI の作業場を専用環境として切り出し、影響範囲を環境単位で抑える。 | ファイル編集、コマンド実行、外部操作などを行為単位で承認する。 | Devin 型は環境境界で止め、Claude Code 型は操作境界で止める。 |
| 人間の確認 | 作業前の権限設計と、作業後の成果物レビューが重くなる。 | 作業途中の承認、差分確認、実行内容の判断が重くなる。 | Devin 型では前後の統制が重要になり、Claude Code 型では工程中の統制が重要になる。 |
| 主な危険 | 広すぎる環境権限や曖昧なタスクにより、誤った作業がまとまって進む危険がある。 | 確認疲れや自動許可の拡大により、危険な操作を実行前に止められない危険がある。 | Devin 型では環境設計の失敗が問題になり、Claude Code 型では承認設計の失敗が問題になる。 |
| 向く統制 | 接続するリポジトリ、Secrets、外部サービス、実行環境を事前に絞る統制に向く。 | コマンド、編集、外部操作ごとに許可範囲を分ける統制に向く。 | 安全性は、AI を止める場所と、人間が判断する粒度を合わせることで成立する。 |
行為単位の許可が万能ではない理由は、大規模言語モデルの危険が、単純な誤操作だけに限られないためである。OWASP は大規模言語モデルアプリケーションの危険として、プロンプトインジェクション、過剰な自律性、過信などを挙げている[16]。プロンプトインジェクションとは、外部文書、Web ページ、Issue、コメント、ログなどに含まれる文言が、AI への指示として作用してしまう危険である。開発現場では、AI が読む対象はコードだけではない。チケット、エラーログ、ドキュメント、レビューコメント、外部ページを読むため、そこに紛れた指示が AI の行動に影響する可能性がある。
NCSC も、プロンプトインジェクションでは指示とデータの境界が古典的な SQL インジェクションのようには分離されない点を強調している[17]。この指摘は、AI コーディングエージェントでは特に重要である。SQL インジェクションでは、入力をデータとして扱うか、命令として扱うかを技術的に分離する設計が取りやすい。一方、大規模言語モデルは、自然文の指示、説明、ログ、コメント、仕様、エラー文を同じ文脈の中で読み取る。第一段階では、AI が多様な情報を読めることが作業能力を高める。第二段階では、その同じ性質が、外部入力を誤って指示として解釈する危険を生む。
このため、安全設計は「AI を信じるか疑うか」という態度の問題ではない。要点は、どの境界で止めるかを決めることである。Devin 型では、AI の作業環境、接続先、認証情報、外部サービスの範囲を設計し、環境境界で事故範囲を絞る。Claude Code 型では、ファイル編集、コマンド実行、外部接続、差分採用の節目を設計し、行為境界で危険操作を止める。どちらの場合も、人間が確認すべき場所を明確にしないと、承認やレビューは形式的な手続きになる。
最終的に、安全性は AI の能力を抑えることではなく、AI の能力を実務で使える形に制御することである。AI が何もできなければ安全だが、価値も小さい。AI に広い権限を与えれば作業能力は上がるが、事故範囲も広がる。第一段階では、権限が能力を増やす。第二段階では、増えた能力に合わせて停止点、監査点、レビュー点を設計しなければならない。Devin と Claude Code の違いは、この停止点を環境に置くか、行為に置くかの違いである。
8. タスク適性は、作業名ではなく曖昧さの量で決まる
Devin と Claude Code の使い分けは、「バグ修正はどちら」「リファクタリングはどちら」といった作業名だけでは決まらない。同じバグ修正でも、再現手順、期待結果、影響範囲、確認すべきテストが明確なら、タスクとして切り出しやすい。逆に、バグのように見えて、実際には仕様の解釈、既存設計の意図、利用者に見せるべき挙動が揺れている場合は、途中で人間の判断が必要になる。作業名は同じでも、含まれる曖昧さの量が違えば、適した AI コーディングエージェントも変わる。
ここでいう曖昧さとは、単に指示文が分かりにくいという意味ではない。何を正しい結果とみなすのか、どこまで変更してよいのか、既存挙動をどこまで保つのか、テストが失敗したときに仕様を直すのか実装を直すのか、という判断が未確定である状態を指す。第一段階では、この曖昧さがタスクの完了条件を不安定にする。第二段階では、完了条件が不安定なまま AI に作業を渡すことで、AI が自分なりの前提を置き、その前提に沿って差分を作ってしまう。したがって、タスク適性を見るときは、作業名よりも、完了条件をどこまで定義できるかを見る必要がある。
Devin に寄せやすいのは、完了条件、変更範囲、確認方法を事前に定義しやすい作業である。たとえば、依存関係を指定バージョンへ上げ、既存テストを通し、失敗したテストを最小限修正する、といった作業は、目的と確認方法を比較的明確にできる。このような場合、AI が専用環境で調査、修正、テストを進め、結果を Pull Request として返す構造が機能しやすい。人間の役割は、タスク投入前に条件を定め、作業後に差分とテスト結果を検証する位置へ寄る。
Claude Code に寄せやすいのは、作業中に論点が現れる作業である。たとえば、既存コードの責務分離を見直す場合、どの関数を移すべきか、どの命名を残すべきか、既存の複雑さを温存するべきか解体するべきかは、作業前にすべて決められないことが多い。調査して初めて依存関係が見え、差分を作って初めて影響範囲が分かり、テストを実行して初めて設計上の前提が見える。このような作業では、AI に一気に任せるより、人間が差分を読みながら途中で方針を調整できる構造が向く。
| 作業の性質 | Devin に寄せやすい条件 | Claude Code に寄せやすい条件 | 判断の要点 |
|---|---|---|---|
| 依存関係更新 | 更新対象、許容バージョン、テスト手順、失敗時の戻し方が明確な場合に向く。 | 更新に伴って設計変更、互換性判断、段階的移行の方針決定が必要な場合に向く。 | 単なる更新なら委任しやすいが、互換性の意味を判断する必要があるなら併走が必要になる。 |
| バグ修正 | 再現手順、期待結果、該当範囲、確認すべきテストが明確な場合に向く。 | 原因調査の過程で、仕様解釈、設計意図、利用者影響の判断が必要になる場合に向く。 | 再現可能な不具合は委任しやすいが、何を正とするかが揺れる不具合は途中判断が必要になる。 |
| レガシー移行 | 移行規則が明確で、多数の類似変更を並列に処理できる場合に向く。 | 既存設計の意図を読み解きながら、移行方針自体を調整する場合に向く。 | 規則が決まった後の展開は委任しやすいが、規則を決める段階は人間の判断を残すべきである。 |
| テスト作成 | 入力、期待結果、対象関数、確認観点が定まっている場合に向く。 | 何を仕様として固定し、何を実装詳細として扱うかを考えながらテスト観点を設計する場合に向く。 | 既知の仕様をテストへ落とす作業は委任しやすいが、仕様を発見する作業は併走が必要になる。 |
| リファクタリング | 命名変更、単純な分割、機械的な移動のように規則が明確な場合に向く。 | 責務分離、依存関係整理、設計意図の再構成を含む場合に向く。 | 機械的な整理は委任しやすいが、構造の意味を変える整理は人間の設計判断を伴う。 |
| ドキュメント更新 | 実装差分に合わせて、既存手順や設定値を反映する場合に向く。 | 読者、運用手順、例外条件、設計意図を整理し直す必要がある場合に向く。 | 事実の反映は委任しやすいが、説明構造の再設計は併走が向く。 |
| 障害調査 | ログ、再現条件、対象範囲、確認手順が明確で、原因候補を絞り込める場合に向く。 | 症状が散発的で、運用判断、暫定対応、恒久対応の切り分けが必要な場合に向く。 | 調査手順が定まっているなら委任しやすいが、対応方針の優先順位を決める段階では人間の判断が必要になる。 |
この表から分かるのは、AI の向き不向きが作業名ではなく、完了条件の定義可能性に左右されるということである。依存関係更新でも、単純なバージョン更新なら Devin に寄せやすい。だが、更新によって設計変更や互換性判断が発生するなら Claude Code に寄せた方が安全になる。バグ修正でも、再現手順と期待結果が明確なら委任しやすい。だが、期待結果そのものが仕様判断を含むなら、途中で人間が判断できる構造が必要になる。
この違いには、さらに深い構造がある。タスクが閉じているとは、AI が作業結果を自分で確認できる条件が与えられているということである。テストが通ること、特定のエラーが消えること、特定の API 互換性を保つこと、差分範囲が指定されたディレクトリ内に収まることなどが、確認条件になる。第一段階では、確認条件があることで AI は作業結果を評価できる。第二段階では、評価できる作業ほど非同期に委任しやすくなる。したがって、Devin 型に向くかどうかは、AI が自分の作業を検証できる条件を人間が先に与えられるかにかかっている。
一方、タスクが作業中に形を変えるとは、作業結果を評価する基準そのものが途中で見つかるということである。既存設計の意図を読んだ結果、当初の修正方針が不適切だと分かることがある。テストを追加しようとして、そもそも仕様が文書化されていないことに気づくことがある。リファクタリングを始めて、依存関係の問題よりも責務分離の問題が本質だと分かることがある。このような場合、AI に作業を完走させるより、途中の発見を人間が読み取り、次の方針を決める必要がある。Claude Code 型に向くのは、この途中判断の余地が大きい作業である。
したがって、開発現場で重要なのは、AI に何をさせたいかを言う前に、その作業がどれだけ閉じているかを見ることである。閉じた作業なら、タスク定義、権限範囲、確認方法を明確にし、Devin 型の委任に寄せやすい。開いた作業なら、最初から結論を固定せず、調査、差分確認、方針変更を挟みながら Claude Code 型で進める方がよい。第一段階では、曖昧さの量が作業の閉じ方を決める。第二段階では、作業の閉じ方が、委任型と併走型のどちらに向くかを決める。
この整理は、AI コーディングエージェントの使い分けを単純化しすぎないために重要である。Devin は定型作業だけの道具ではなく、条件が明確なら複雑な作業も扱える。Claude Code は難しい作業専用の道具ではなく、単純作業でも開発者が細かく確認したい場合には有効である。違いは作業の難易度そのものではなく、作業を始める前にどこまで定義できるか、作業中にどれだけ判断が必要になるかである。AI の選択は、作業名の分類ではなく、曖昧さ、検証可能性、変更範囲、判断責任の配置によって決まる。
9. コスト構造は、何を買っているのかを映す
料金比較は、単純な安い高いで判断すると誤る。Devin と Claude Code は、費用が発生する単位も、その費用によって得られる価値も異なる。Devin は、AI に作業を委任し、その作業時間や作業量に対して費用を払う感覚に近い。Claude Code は、開発者が設計、調査、実装、レビューの途中で使う支援能力、つまり人間の作業時間に重なる併走能力に対して費用を払う感覚に近い。価格表の数字だけを見ると同じ開発支援サービスの比較に見えるが、実際には、買っているものの単位が違う。
この違いには、二段階の因果関係がある。第一に、AI がどの作業モデルで使われるかによって、消費される資源の意味が変わる。Devin 型では、AI がタスクを受け取り、専用環境で調査、実装、テスト、修正を進めるため、作業の実行量そのものが費用感に結びつきやすい。Claude Code 型では、開発者が作業中に AI を呼び出し、差分確認、原因調査、実装方針の検討、テスト実行の支援を受けるため、人間の作業密度を高める能力として費用が見えやすい。第二に、費用単位が違えば、費用対効果を測る指標も変わる。Devin では、どれだけ明確なタスクを委任できたかが重要になり、Claude Code では、開発者の判断や実装の質をどれだけ継続的に補助できたかが重要になる。
Devin の請求ドキュメントは、セルフサービスでは Free、Pro、Max、Teams の各プランと、含まれる利用枠およびオンデマンドクレジットによる課金を説明している。Enterprise では Agent Compute Unit、すなわち ACU による課金が使われると説明されている[18]。ACU は、Devin の作業量を測る単位として理解できる。ここで重要なのは、Devin の料金体系が、単に「AI を呼び出した回数」ではなく、AI が実際に作業を進める量と結びついている点である。価格ページの詳細は変動しうるため、実際の導入判断では公式価格ページを確認する必要がある[19]。
この課金構造は、Devin の委任型の性格と対応している。第一に、明確に切り出された作業を AI に渡せるほど、消費される作業量を成果物と対応させやすくなる。たとえば、依存関係更新、CI 失敗の修正、一定規則に基づく移行作業であれば、消費した作業量と得られた Pull Request を比較しやすい。第二に、曖昧なタスクを渡すほど、試行錯誤や誤解による消費が増え、費用対効果を読みにくくなる。つまり、Devin のコスト管理は、料金表を見るだけではなく、タスクをどれだけ明確に分解できるかに依存する。
Claude 側は、Free、Pro、Max などの利用プランがあり、サポートページでは Pro が月 20 ドル、Max 5x が月 100 ドル、Max 20x が月 200 ドルという個人向け価格が示されている[20]。公式価格ページも、Free、Pro、Max、Team、Enterprise と API 料金を並べている[21]。さらに、モデル別の API 価格はモデル更新に伴って変わる。たとえば Claude Sonnet 5 の発表では、2026 年 8 月 31 日までの導入価格と、その後の標準価格が示されている[22]。
Claude Code の費用感は、Devin とは異なる形で現れる。第一に、Claude Code は開発者の作業中に繰り返し使われるため、ひとつの成果物に対する費用だけでなく、日常的な開発速度、調査効率、差分確認、テスト作成、レビュー補助の積み重ねとして評価される。第二に、その積み重ねは、明確なチケット単位の成果物だけでは測りにくい。設計方針の整理が早くなる、既存コードの理解が進む、テスト観点が漏れにくくなる、差分の説明が容易になる、といった効果は、開発者の判断過程に入り込む。したがって、Claude Code の費用対効果は、単一タスクの完了数よりも、開発者の作業全体にどれだけ密度を加えるかで見る必要がある。
| 観点 | Devin | Claude Code | 費用対効果の見方 |
|---|---|---|---|
| 費用単位 | 作業量や稼働量に近い単位で評価されやすい。 | 開発者が作業中に使う利用枠や支援能力として評価されやすい。 | Devin は作業の委任量、Claude Code は日常作業への浸透度が重要になる。 |
| 価値の出方 | 明確なタスクを非同期に処理し、Pull Request などの成果物として返すことで価値が出る。 | 調査、実装、差分確認、テスト、レビューの途中で開発者の判断を補助することで価値が出る。 | Devin は成果物単位で測りやすく、Claude Code は作業過程への寄与として測る必要がある。 |
| 読みやすい場面 | 依存関係更新、定型修正、移行作業、CI 失敗修正のように完了条件が明確な場面で読みやすい。 | 既存コード理解、探索的修正、設計相談、レビュー補助のように人間の判断が続く場面で読みやすい。 | Devin は閉じたタスクで費用対効果を測りやすく、Claude Code は継続的な開発生産性で測りやすい。 |
| 読みにくい場面 | 曖昧なタスクを渡し、試行錯誤や解釈違いが増える場面では読みにくい。 | 利用頻度が散発的で、開発者の作業改善に結びついているか見えにくい場面では読みにくい。 | どちらも、使う作業の性質と費用単位が合っていないと、価格だけでは判断できない。 |
この違いは、料金表の違い以上の意味を持つ。Devin の費用対効果は、明確な作業をどれだけ並列に流せるかで読みやすくなる。Claude Code の費用対効果は、開発者が日常的にどれだけ設計、実装、調査、レビューの中で使えるかで決まる。前者は作業量を買う。後者は作業中の判断支援を買う。この区別をしないまま価格だけを見ると、導入判断を誤る。
さらに、コスト構造は組織側の成熟度も映す。Devin を有効に使うには、タスクを切り出し、完了条件を定め、AI に渡し、返ってきた成果物をレビューする流れが必要になる。つまり、チケット分解、レビュー基準、テスト整備が弱い組織では、作業量を買っても成果物の検証に苦労する。Claude Code を有効に使うには、開発者が AI の提案を読み、差分を検証し、必要な部分だけを採用する能力が必要になる。つまり、個々の開発者の判断力やコード読解力が弱い場合、併走能力を買っても、承認や採用が形式化する危険がある。
したがって、コスト比較は「月額いくらか」や「一回の利用が安いか」だけでは完結しない。第一段階では、料金体系が、その製品の作業モデルを反映する。第二段階では、その作業モデルが、組織や開発者に必要な能力を決める。Devin は、明確に切り出した作業を AI に委任する能力を買う構造である。Claude Code は、人間の作業中に判断、調査、実装、確認を補助する能力を買う構造である。何を買っているのかを見ないまま価格だけを比べても、実務上の費用対効果は判断できない。
10. MCP は、外部接続を標準化すると同時に、責任範囲を広げる
MCP、すなわち Model Context Protocol は、AI と外部システムをつなぐための標準である。Anthropic は、MCP を、データソースと AI ツールの間に安全な双方向接続を作るための開かれた標準として発表した[23]。公式ドキュメントも、MCP を AI アプリケーションと外部システムをつなぐ標準と説明し、ローカルファイル、データベース、検索エンジン、計算機、ワークフローなどへの接続例を挙げている[24]。ここで重要なのは、MCP が単なる追加機能ではなく、AI がどの情報源を読み、どの道具を使い、どの業務文脈へ入れるかを決める接続層であることだ。
AI コーディングエージェントにとって、外部接続は作業能力を大きく変える。コードだけを読む AI は、リポジトリ内のファイル、テスト、設定、履歴に基づいて判断する。これは有用だが、実際の開発作業のすべてではない。多くの不具合や変更要望は、Issue、チケット、設計資料、障害ログ、監視情報、顧客影響、運用手順、クラウド環境の状態と結びついている。MCP によってこれらへ接続できると、AI はコードだけでは見えない前提を参照できるようになる。つまり、MCP は AI の知識を増やすだけでなく、AI が作業として扱える現場文脈を広げる。
この効果には、二段階の因果関係がある。第一に、AI が外部情報を参照できるようになると、コード上の現象を業務上の文脈と照合しやすくなる。たとえば、失敗したテスト、障害チケット、監視ログ、関連する Pull Request を組み合わせれば、単なる構文エラーではなく、どの変更がどの利用者影響につながっているかを推測しやすくなる。第二に、AI が外部ツールを実行できるようになると、調査は提案にとどまらず、状態確認、レポート作成、チケット更新、ワークフロー実行へ進む。参照できる範囲が広がることで判断材料が増え、実行できる道具が増えることで作業範囲が広がる。この二つが結びつくと、AI は開発者の補助者から、業務フローの一部を担う存在へ近づく。
ただし、MCP が広げるのは能力だけではない。外部接続が増えるほど、責任範囲も広がる。AI がチケットを読めるなら、チケット内の記述を根拠として使う責任が生じる。AI がログを読めるなら、ログの意味を誤読したまま判断する危険がある。AI がデータベースを参照できるなら、機密情報や個人情報の取り扱いが問題になる。AI がクラウドやワークフローを操作できるなら、誤った操作が開発環境や運用環境の状態を変える可能性がある。第一段階では、接続が AI の作業能力を高める。第二段階では、高まった作業能力に応じて、監査、権限、停止点、レビューの設計が必要になる。
| 接続対象 | AI が得る能力 | 広がる責任範囲 | 設計上の要点 |
|---|---|---|---|
| チケット管理 | 要望、障害報告、再現手順、優先順位を参照できる。 | 曖昧な依頼や誤った記述を前提として作業を進める危険がある。 | 読み取り、コメント、状態変更の権限を分ける必要がある。 |
| 設計資料 | コードだけでは見えない設計意図や運用制約を参照できる。 | 古い資料や未承認の草稿を正しい前提として扱う危険がある。 | 信頼できる資料の範囲と鮮度を明確にする必要がある。 |
| ログ・監視 | 障害の発生時刻、頻度、影響範囲、関連エラーを調査できる。 | ログの相関を因果と誤認し、誤った修正方針へ進む危険がある。 | ログ参照は判断材料であり、原因確定には人間の検証を残す必要がある。 |
| データベース | 実データやスキーマを確認し、仕様理解や不具合調査に使える。 | 機密情報の露出、誤更新、不要な広範囲検索の危険がある。 | 原則として読み取り範囲を絞り、更新権限は慎重に分離する必要がある。 |
| クラウド・ワークフロー | デプロイ、ジョブ、CI、インフラ状態を確認または操作できる。 | 誤った実行により、環境状態や運用中サービスへ影響する危険がある。 | 参照、再実行、変更、削除を権限として分け、重要操作には承認を残す必要がある。 |
MCP は、Devin と Claude Code のどちらにも関係するが、意味の現れ方は異なる。Devin では、AI が委任された作業を進めるために、チケット、リポジトリ、外部データ、社内ツールへ接続する意味が強い。つまり、AI が作業主体として動く範囲を広げる。Claude Code では、開発者の作業環境にいる AI が、必要に応じて外部の情報源や道具へ接続する意味が強い。つまり、人間が見ている作業場に、外部文脈を呼び込む。どちらも外部接続を使うが、Devin は委任された作業の実行範囲を広げ、Claude Code は対話中の判断材料を増やす方向に働きやすい。
この違いを押さえると、MCP を導入すべきかどうかという問いは粗すぎることが分かる。重要なのは、どの MCP サーバーを、どの作業に、どの権限で使わせるかである。チケットを読むだけなら、AI は文脈を理解しやすくなる。チケットへコメントできるなら、AI は報告や確認依頼を行える。チケットの状態を変更できるなら、作業進捗や完了判断へ影響を及ぼす。データベースも同じで、スキーマを読む、限定されたデータを参照する、更新する、削除する、では責任の重さがまったく違う。MCP の設計では、接続先の種類だけでなく、読み取りと書き込み、参照と実行、調査と状態変更を分ける必要がある。
また、外部接続が標準化されると、接続の敷居は下がる。これは利点であると同時に、危険でもある。第一に、標準化によって、さまざまなツールを AI に接続しやすくなる。第二に、接続しやすくなるほど、必要性の低い権限まで与えてしまう可能性が高まる。開発者が手作業で接続を作る場合は、その都度、用途と権限を意識しやすい。標準化された接続が普及すると、導入は簡単になるが、権限設計を意識しないまま利用範囲が広がる危険がある。したがって、MCP の価値は、接続の容易さではなく、接続範囲を管理可能な形で設計できるかにかかっている。
ここから、MCP は外部接続を標準化すると同時に、責任範囲を広げるという結論が導かれる。AI が現実の開発作業に近づくには、コードの外側にある情報源と道具へ接続する必要がある。だが、接続が増えるほど、AI が参照する前提、実行する操作、変えられる状態も増える。第一段階では、MCP が AI の作業能力を拡張する。第二段階では、その拡張された能力が、権限、監査、承認、レビューの設計を要求する。MCP は便利な接続規格であるだけでなく、AI にどの業務文脈を触らせるかを決める責任設計の一部である。
11. ベンチマークは、実務適性の一部しか示さない
AI コーディングエージェントを比較するとき、SWE-bench や Terminal-Bench のような評価指標は重要である。SWE-bench Verified は、人間が確認した 500 件の課題を含むサブセットとして提供され、モデルやエージェントが実際のリポジトリ上の問題をどれだけ解決できるかを見る指標になっている[25]。Terminal-Bench は、ターミナル環境でソフトウェア工学、機械学習、セキュリティ、データ処理などの作業をどれだけ完了できるかを見る評価として提供されている[26]。これらは、AI が単なる文章生成ではなく、実際の開発作業に近い課題を解けるかを見るうえで有用である。
ただし、ベンチマークは実務適性の一部しか示さない。評価課題で高い成績を出すことと、ある組織の既存コード、権限、レビュー文化、デプロイ制約、暗黙知の中で安定して成果を出すことは同じではない。ベンチマークでは、課題、正解条件、評価方法が一定程度整えられている。実務では、課題文が不完全であり、関係者の理解が揃っておらず、テストが不足し、期待される変更範囲がコードからだけでは分からないことが多い。したがって、ベンチマークは能力の下限や比較材料にはなるが、導入後の安定性をそのまま保証するものではない。
この差には、二段階の因果関係がある。第一に、ベンチマークでは、評価対象が一定の形式へ整えられることで、AI は課題を解くための入力と確認条件を得やすくなる。問題文、リポジトリ、失敗するテスト、期待される修正の範囲が、評価のためにある程度整理されているからである。第二に、実務では、その整理自体が作業の一部になる。何が問題なのか、どこまで直すべきか、テストが何を保証しているのか、仕様と実装のどちらを変えるべきかを、人間と AI が作業中に見極める必要がある。つまり、ベンチマークが測るのは、整えられた課題を解く能力であり、実務では、課題を整える能力、権限を制御する能力、成果物をレビューする能力がさらに必要になる。
SWE-bench のような評価は、実際のリポジトリに基づく点で、単純なプログラミング問題より実務に近い。しかし、それでも組織固有の制約までは含まない。たとえば、ある修正がテストを通しても、社内の互換性方針に反することがある。ある依存関係更新が技術的には可能でも、運用チームの監視やリリース手順と合わないことがある。あるリファクタリングが局所的にはきれいでも、既存の保守担当者が理解している構造を過度に崩すことがある。このような判断は、ベンチマークの正答率だけでは評価しにくい。
| 観点 | ベンチマークで見えやすいもの | 実務で追加されるもの | 評価上の注意点 |
|---|---|---|---|
| 課題設定 | 問題文、対象リポジトリ、評価条件が一定の形式で与えられる。 | 問題の切り分け、仕様確認、関係者間の認識合わせが必要になる。 | 課題を解く能力と、課題を定義する能力は分けて見る必要がある。 |
| 正解条件 | テスト通過や期待出力によって、成功が比較的明確に判定される。 | 既存仕様、互換性、運用制約、顧客影響を含めて成功を判断する必要がある。 | テストが通ることは必要条件になりうるが、十分条件とは限らない。 |
| 作業環境 | 評価用の環境で、課題解決に必要な操作が定められている。 | 社内権限、認証情報、外部サービス、ネットワーク制約、CI/CD が絡む。 | 環境差によって、同じモデルでも成果が変わる可能性がある。 |
| 安全性 | 課題を完了できるかが主に評価される。 | 何を読めるか、何を実行できるか、どこで人間が承認するかが問題になる。 | 解ける能力と、安全に解かせる設計は別の評価軸である。 |
| 組織適合 | モデルやエージェントの一般的な解決能力を比較しやすい。 | レビュー文化、タスク分解、テスト整備、リリース手順との相性が成果を左右する。 | 高いベンチマーク成績が、そのまま組織内の導入効果を意味するわけではない。 |
Claude Code の設計空間を分析した研究は、Claude Code を、シェルコマンドを実行し、ファイルを編集し、外部サービスを呼び出せるエージェント型コーディングツールとして分析している。そのうえで、権限システム、文脈管理、MCP、プラグイン、スキル、フック、サブエージェントなど、モデル呼び出しの周辺に多くの設計要素があることを示している[27]。この指摘は、AI コーディングエージェントの性能を、モデル単体の能力として扱うことの限界を示している。実務上の成果は、モデルの推論能力だけでなく、どの情報を持たせるか、どの操作を許すか、どの段階で止めるか、どのように作業履歴を残すかによって決まる。
ここでも二段階の因果関係がある。第一に、エージェントが使える道具や文脈が増えるほど、解ける課題の範囲は広がる。シェル、ファイル編集、外部サービス、MCP、サブエージェントを使えれば、AI は単純なコード生成を超えて、調査、実装、検証、報告をつなげやすくなる。第二に、道具と文脈が増えるほど、制御すべき要素も増える。権限が広すぎれば危険な操作が可能になり、文脈が多すぎれば誤った情報や古い情報を根拠にする危険が出る。したがって、エージェントの性能は、能力の拡張と制御の設計を合わせて評価しなければならない。
Claude Code の自動許可に関する独立評価も、権限分類の難しさを示している。同研究は、危険な操作を止める仕組みが、曖昧な権限範囲や影響範囲を持つ作業では十分に機能しない場面があることを示している[28]。この点は、ベンチマークの点数だけでは見えにくい。AI が課題を解けることと、その課題を安全な権限範囲で解けることは違う。特に、ファイル編集、コマンド実行、外部サービス接続を伴う場合、評価すべきなのは解決率だけではなく、どの操作を許可し、どの操作を止め、どの操作を人間が確認したのかである。
Devin と Claude Code の比較でも、ベンチマークの読み方は変わる。Devin 型では、AI がまとまったタスクを完走できる能力が重要になるため、課題解決率は有力な参考になる。しかし、実務では、タスクをどれだけ明確に切り出せるか、返ってきた Pull Request をどれだけ検証できるかが追加で問われる。Claude Code 型では、モデルが複雑なコードを理解し、修正できる能力は重要である。しかし、それに加えて、開発者が途中で差分を読み、権限を許可し、方針を修正する作業過程が成果を左右する。したがって、同じベンチマーク成績でも、委任型と併走型では実務上の意味が変わる。
このため、ベンチマークは無視すべきものではないが、過大評価してもならない。第一段階では、ベンチマークは、モデルやエージェントが一定の課題を解けるかを見るための比較材料になる。第二段階では、実務導入において、権限設計、レビュー体制、タスク定義、外部ツール接続、運用制約を別に評価する必要がある。ベンチマークは能力の一部を測る。実務適性は、その能力をどの作業構造に置き、どの責任境界で使うかによって決まる。
したがって、AI コーディングエージェントを選ぶとき、ベンチマークの順位だけで判断するのは危うい。高い点数は、課題を解く能力の重要な証拠にはなる。しかし、その能力が自分たちのリポジトリ、権限管理、レビュー文化、テスト整備、開発フローに適合するかは別問題である。実務で必要なのは、ベンチマークを入口として使いながら、最終的には作業の曖昧さ、環境境界、行為許可、成果物レビュー、人間の判断責任まで含めて評価することである。
12. 曖昧さをどこで処理するかが、両者の核心である
ここまでの比較を一段抽象化すると、Devin と Claude Code の違いは、曖昧さをどこで処理するかに集約できる。Devin は、曖昧さを作業前にできるだけ処理してから渡すほど強い。Claude Code は、曖昧さを作業中に人間と AI のあいだで処理できるほど強い。実行環境、Git 連携、外部ツール接続、安全設計、コスト構造は、それぞれ別の論点に見える。しかし、それらはいずれも、曖昧な作業をどの段階で閉じるかという問題に接続している。
ここでいう曖昧さとは、文章表現が不明瞭であることだけではない。完了条件が定まっていないこと、変更範囲が切れていないこと、既存仕様と新しい要求の優先順位が決まっていないこと、テスト失敗の意味をどう読むべきかが決まっていないこと、どこまで設計を変えてよいかが決まっていないことを含む。第一段階では、この曖昧さが作業の進め方を不安定にする。第二段階では、その不安定さを AI が自分なりに補うことで、人間が意図していない成果物が作られる。したがって、AI に何を任せるかを考える前に、その作業に含まれる曖昧さがどこにあるかを見分ける必要がある。
Devin 型では、曖昧さは作業前に処理されるべきものとして扱われる。タスクを渡す前に、目的、制約、変更範囲、確認方法、失敗時の戻し方を定義する。これらが明確であれば、AI は専用環境で調査し、実装し、テストし、Pull Request として成果物を返しやすい。反対に、これらが曖昧なままだと、AI は不足している条件を推測で補う。推測が正しければ作業は進むが、推測が外れると、誤った前提に基づく差分がまとまって返ってくる。Devin の強さは、作業を渡せることにあるが、その前提には、渡す前に作業を閉じる力がある。
Claude Code 型では、曖昧さは作業中に処理されるものとして扱いやすい。最初に大まかな目的を与え、調査させ、差分を見て、テスト結果を確認し、途中で方針を修正する。ここでは、作業前にすべてを確定する必要はない。むしろ、既存コードを読ませた結果、当初の理解が違っていたと分かることがある。テストを実行した結果、問題は実装ではなく仕様にあると分かることがある。差分を見た結果、修正範囲が広がりすぎていると分かることがある。Claude Code の強さは、こうした途中の発見を人間が読み取り、次の指示へ反映できることにある。
| 観点 | Devin 型 | Claude Code 型 | 曖昧さの扱い |
|---|---|---|---|
| 処理時点 | 作業を渡す前に、目的、制約、完了条件をできるだけ定義する。 | 作業を進めながら、差分、実行結果、追加調査を見て条件を詰める。 | Devin 型は前処理に寄り、Claude Code 型は工程内処理に寄る。 |
| 人間の役割 | タスク分解、権限設計、完了条件設定、事後レビューが重くなる。 | 途中判断、差分読解、方針修正、採用範囲の制御が重くなる。 | どちらも人間の判断を消さず、判断を置く場所だけが変わる。 |
| 向く状況 | 作業対象、変更規則、テスト手順、失敗時の戻し方が明確な状況に向く。 | 作業中に設計意図、仕様解釈、影響範囲を確認する必要がある状況に向く。 | 閉じたタスクは委任しやすく、開いたタスクは併走しやすい。 |
| 主な失敗 | 曖昧な前提を AI が補完し、誤った解釈で作業を完走する。 | 判断点が増え、確認疲れや方針の揺れによって作業が散らばる。 | 前処理の不足と工程内判断の不足は、異なる形で失敗を生む。 |
依存関係更新を考えると、この違いは分かりやすい。対象ライブラリ、許容バージョン、テスト手順、失敗時の戻し方、影響範囲が明確なら、Devin に任せやすい。作業を環境に切り出し、更新し、テストし、Pull Request として返せるからである。第一段階では、更新対象と確認条件が明確であるため、AI は自分の作業結果を評価できる。第二段階では、評価できる作業であるため、人間は作業途中から離れ、返ってきた差分とテスト結果をレビューしやすくなる。
しかし、同じ依存関係更新でも、更新に伴って設計を変えるべきか、古い互換性を切るべきか、どの利用条件を優先するべきかが未確定なら、Claude Code と対話しながら進めた方がよい。この場合、曖昧さはコードの内側だけではなく、仕様、運用、顧客影響、将来の保守方針にまたがっている。第一段階では、依存関係の更新が、単なるバージョン変更ではなく設計判断を引き起こす。第二段階では、その設計判断を作業中に発見し、人間が採用可否を決める必要がある。ここでは、AI に作業を完走させるより、途中で差分と影響を見ながら判断する構造が向く。
この構造は、バグ修正でも同じである。再現手順、期待結果、原因範囲、確認すべきテストが明確なバグは委任しやすい。AI は再現し、原因を調べ、修正し、テストを通し、差分を返せる。しかし、原因を調べる過程で、そもそも期待結果の理解が揺れる場合は、併走が必要になる。たとえば、ある画面の表示が不具合に見えても、それが過去の仕様変更による意図的な挙動なのか、未整理の例外なのか、単なる実装ミスなのかは、コードだけでは決まらないことがある。この場合、AI が直すべきなのはコードか、テストか、仕様説明かを人間が判断しなければならない。
リファクタリングでも同じ構造が現れる。命名変更、単純な関数分割、規則が明確な移動であれば、Devin 型で委任しやすい。作業の規則と確認条件を与えれば、AI は多数の類似変更を進められる。一方、責務の切り方、依存関係の方向、抽象化の粒度、既存利用者への影響を考えるリファクタリングでは、Claude Code 型が向く。第一段階では、コードを整理する過程で、設計上の問題が見える。第二段階では、その問題をどこまで解くかを人間が決める必要がある。つまり、リファクタリングという作業名ではなく、機械的な整理なのか、設計判断を伴う整理なのかが分岐点になる。
ここから導かれる一般化は、AI コーディングエージェントの選定基準が、作業の難易度そのものではないということである。難しい作業でも、規則と確認条件が明確なら委任できることがある。簡単に見える作業でも、仕様や責任範囲が曖昧なら、途中で人間の判断が必要になる。第一段階では、曖昧さの量がタスクの閉じ方を決める。第二段階では、タスクの閉じ方が、委任型と併走型の適性を決める。したがって、判断すべきなのは、Devin と Claude Code のどちらが賢いかではなく、対象作業の曖昧さをどの段階で処理できるかである。
この観点は、組織の開発プロセスにも直結する。タスクを事前に切り出し、完了条件を定義し、テストとレビューで検証できる組織では、Devin 型の委任が機能しやすい。作業中に仕様を確認し、設計判断を積み重ね、差分を読みながら方向を変える組織では、Claude Code 型の併走が機能しやすい。どちらが優れているかではなく、組織がどこで曖昧さを処理しているかが問題になる。AI コーディングエージェントは、その組織の曖昧さ処理の場所を増幅する。事前に閉じられる組織では委任が進み、工程中に判断する組織では併走が進む。
したがって、選定基準は「どちらが賢いか」ではない。自分たちの開発プロセスが、曖昧さを事前に潰せる構造なのか、作業中に解く構造なのかである。AI に任せる前にタスクを閉じられる組織では、委任型が強い。作業中に設計判断を積み重ねる組織では、併走型が強い。Devin と Claude Code の比較は、最終的には製品比較ではなく、自分たちの開発作業がどこで曖昧さを処理しているかを可視化する作業である。
13. 作業を任せることと、判断を渡すことは違う
AI コーディングエージェントを使うとき、最も重要な区別は、作業の外部化と判断の明け渡しである。作業を外部化するとは、調査、実装、テスト、修正、差分整理の手間を AI に担わせることである。判断を明け渡すとは、変更の妥当性、仕様との一致、影響範囲、運用リスク、採用可否を十分に確認しないまま、AI の出力を組織の成果物として通すことである。この二つは似ているが、実務上はまったく違う。作業を任せることは効率化になりうるが、判断を渡すことは責任の空白を生む。
この違いには、二段階の因果関係がある。第一に、AI が調査や実装を担うことで、人間が直接手を動かす量は減る。これは、依存関係更新、テスト修正、既知の不具合対応、定型的な移行作業では大きな効果を持つ。第二に、手を動かす量が減るほど、人間は成果物の中身を見なくなりやすい。差分が自然に見え、テストが通り、説明文が整っていると、確認は形式化しやすい。ここで、作業の外部化が判断の外部化へ滑る。AI 導入で危険なのは、AI が作業することではなく、人間が採用判断をしたつもりになったまま、実際には AI の出力を通してしまうことである。
既稿では、AI の答えは生成された時点では素材であり、候補であり、仮説であると整理した。それを文書に入れる、コードに反映する、判断材料にする、他者へ説明する、組織の意思決定に使う段階で、人間の判断になる[29]。AI コーディングエージェントでも同じである。Devin が Pull Request を作っても、Claude Code が差分を提案しても、それは採用前の候補である。マージする、リリースする、運用環境へ流す、顧客影響のある変更として扱う段階で、人間と組織の責任が発生する。
この点は、AI が高性能になるほど見えにくくなる。生成物が自然で、テストも通り、差分も整理されていると、人間は確認を省きたくなる。しかし、テストが通ることと、仕様として正しいことは同じではない。差分が小さいことと、設計上安全であることも同じではない。Pull Request の説明が整っていることと、影響範囲が正しく把握されていることも同じではない。第一段階では、AI の出力品質が上がることで、人間は成果物を信頼しやすくなる。第二段階では、その信頼が過剰になることで、確認すべき論点が見落とされる。性能向上は安全性を高める場合もあるが、確認の省略を誘発する場合もある。
| 区別 | 作業の外部化 | 判断の明け渡し | 実務上の意味 |
|---|---|---|---|
| 対象 | 調査、実装、テスト、修正、差分整理を AI に担わせる。 | 仕様一致、設計妥当性、リスク、採用可否を確認しないまま AI の出力を通す。 | 前者は効率化になりうるが、後者は責任の所在を曖昧にする。 |
| 人間の役割 | タスクを定義し、権限を与え、成果物を検証する。 | AI が整えた成果物を、そのまま正しいものとして扱う。 | 人間の仕事は消えるのではなく、実装から採用判断へ移る。 |
| 主な危険 | タスク定義が粗いと、AI が誤った前提で作業を進める。 | レビューが形式化し、誤った差分が組織の成果物になる。 | 作業を任せるなら、判断を残す場所を明確にする必要がある。 |
| 必要な能力 | タスク分解、完了条件設定、検証手順の設計が必要になる。 | 差分読解、仕様確認、影響範囲評価、採用可否判断が弱いと起きやすい。 | AI 時代の開発者には、手を動かす能力だけでなく、採用判断の能力が求められる。 |
Devin 型では、この問題は事後レビューに集中しやすい。Devin はタスクを受け取り、専用環境で作業し、Pull Request のようなまとまった成果物を返す。この構造では、人間は作業途中の細かい判断から離れやすい。第一に、非同期委任によって、開発者は他の作業へ移れる。第二に、その結果として、返ってきた Pull Request をどれだけ精密にレビューできるかが成否を左右する。レビューが差分の外形確認だけになれば、AI が置いた前提、変更範囲、テストの意味、仕様との整合を見落とす危険がある。
Claude Code 型では、この問題は作業中の承認と採用判断に分散しやすい。Claude Code はターミナルや IDE の中で差分を作り、コマンドを提案し、ファイル編集を進める。この構造では、人間は途中で止められるが、その分、何度も判断を求められる。第一に、差分やコマンドが細かく提示されることで、危険な変更を早い段階で止めやすい。第二に、確認が増えることで、内容を読まずに許可する承認疲れが起きやすい。併走型では、人間が工程中に残るから安全なのではない。工程中の判断が実質的に機能して初めて安全になる。
NIST の AI リスク管理フレームワークは、AI の設計、開発、利用、評価に信頼性の考慮を組み込むための枠組みとして説明されている[30]。開発現場に引き寄せれば、これは、AI が作った差分をどの根拠で採用し、どのリスクを測り、どの責任者が承認するかという問題になる。信頼性は、AI が高性能であることだけからは生まれない。どの入力を根拠にしたのか、どのテストで確認したのか、どの権限で実行したのか、どの人間が採用を判断したのかが追えることによって生まれる。
ここから、レビューの意味も変わる。従来のレビューは、人間が書いたコードを別の人間が読む行為として理解されやすかった。AI コーディングエージェントのレビューでは、それに加えて、AI がどの前提を置いたのか、どの情報を参照したのか、どの範囲を変更したのか、どの操作を実行したのかを確認する必要がある。第一段階では、レビュー対象がコード差分から作業過程へ広がる。第二段階では、その作業過程を確認できるように、ログ、実行結果、テスト、チケット、Pull Request の説明を接続して残す必要が出る。AI に任せるほど、レビューは軽くなるのではなく、確認すべき対象が変わる。
したがって、作業を任せることと、判断を渡すことは分けなければならない。AI に調査させること、修正させること、テストを実行させること、Pull Request を作らせることは、開発作業を効率化しうる。しかし、仕様に合っているか、設計として受け入れられるか、運用上のリスクが許容できるか、組織の成果物として採用してよいかは、人間が判断しなければならない。第一段階では、AI によって作業が外部化される。第二段階では、外部化された作業を人間が採用するかどうかを判断する。AI コーディングエージェントの導入で重要なのは、この二段階を混同しないことである。
最終的に、AI コーディングエージェントは人間の責任を消すのではなく、責任の現れ方を変える。Devin では、作業前のタスク定義と作業後のレビューに責任が集まりやすい。Claude Code では、作業中の承認、差分読解、方針修正に責任が分散しやすい。どちらの場合も、AI が生成したものは、そのまま組織の判断ではない。人間が採用した時点で、組織の成果物になる。作業を任せるなら、判断をどこに残すかを同時に設計しなければならない。
14. 組織適合性は、ツール選定ではなく開発プロセスの自己診断である
Devin と Claude Code のどちらがよいかは、製品単体の優劣だけでは決まらない。組織の開発プロセスが、どのように作業を切り出し、どのように仕様を確認し、どのようにレビューし、どの段階で人間の判断を入れているかによって、適合するモデルは変わる。AI コーディングエージェントの選定は、外部の道具を選ぶ作業であると同時に、自分たちの開発プロセスがどのような構造を持っているかを確認する作業でもある。
この点には、二段階の因果関係がある。第一に、組織が作業を明確なタスクとして切り出せるほど、AI に非同期で委任しやすくなる。目的、完了条件、変更範囲、確認方法、レビュー基準がそろっていれば、AI は作業結果を一定の基準に照らして返せる。第二に、AI に委任された作業が増えるほど、組織側には事後レビュー、差分検証、テスト整備、権限管理の能力が求められる。つまり、Devin 型の導入効果は、AI 側の自律性だけでなく、組織側のタスク設計能力とレビュー能力に依存する。
チケットが明確に切られ、完了条件が定義され、レビュー観点が整い、CI が安定し、定型修正や移行作業が多い組織では、Devin 型の価値が出やすい。AI に渡す前に作業を閉じられるからである。このような組織では、依存関係更新、古い API の置換、同じ規則に基づく修正、CI 失敗の調査と修正、複数リポジトリにまたがる移行作業を、まとまった単位として AI に渡しやすい。人間は作業中の細部から離れ、返ってきた Pull Request、テスト結果、差分の妥当性を確認する位置に移る。
ただし、Devin 型が向く組織では、人間の仕事が消えるわけではない。第一に、AI に渡す前に、タスクを実行可能な形へ分解しなければならない。第二に、返ってきた成果物を、仕様、設計、テスト、運用影響の観点から検証しなければならない。ここが弱いと、AI が作った Pull Request は増えても、レビュー待ちが詰まり、誤った前提で進んだ差分を後から戻す作業が増える。委任型の効果は、作業を投げる力ではなく、作業を定義し、成果物を検証する力によって決まる。
一方、既存コードの暗黙知が多く、仕様が作業中に確認され、設計判断が頻繁に発生し、影響範囲を見ながら変更を刻む組織では、Claude Code 型の価値が出やすい。AI を横に置き、人間が途中で判断を差し込めるからである。この場合、AI は外部の委任先というより、設計と実装の思考を進めるための作業相手になる。開発者は、調査を依頼し、候補を出させ、差分を読み、必要な部分だけを採用し、方針が違えば途中で止める。
この併走型にも、二段階の因果関係がある。第一に、AI が開発者の作業環境に近い場所で動くことで、既存コードの文脈、ローカルの実行結果、差分、テスト失敗を見ながら作業を進められる。第二に、その文脈を人間が補えることで、仕様が未確定な作業でも、途中で方向修正しながら進められる。したがって、Claude Code 型の効果は、AI が自動で正解を出すことではなく、人間が途中の発見を読み取り、判断を積み重ねられることにある。
| 組織の状態 | 適合しやすいモデル | 理由 | 必要になる能力 |
|---|---|---|---|
| チケット分解が明確 | Devin 型 | 作業前に目的、完了条件、変更範囲を定義しやすく、非同期委任に載せやすい。 | タスク分解、完了条件設定、優先順位付けが必要になる。 |
| レビュー体制が強い | Devin 型 | AI がまとめた成果物を、人間が事後に検証し、必要な修正を指示できる。 | 差分読解、設計妥当性の確認、テスト結果の解釈が必要になる。 |
| CI が安定している | Devin 型 | AI が作業結果を自動テストで確認しやすく、完了条件を機械的に扱いやすい。 | 信頼できるテスト整備、失敗時の切り分け、誤検知への対応が必要になる。 |
| 定型作業が大量にある | Devin 型 | 同質の作業を並列に流すことで、作業量の削減効果が出やすい。 | 規則化、対象範囲の指定、戻し方の設計が必要になる。 |
| 仕様が流動的 | Claude Code 型 | 作業中に指示を追加し、差分を見ながら方針を変えられる。 | 途中判断、仕様確認、関係者への確認、採用範囲の制御が必要になる。 |
| 暗黙知が多い | Claude Code 型 | 人間が文脈を補いながら、AI の探索と修正を誘導できる。 | 既存設計の説明、過去経緯の補足、誤った推測の訂正が必要になる。 |
| 設計判断が中心である | Claude Code 型 | 正解を一括で委任するより、調査、比較、差分確認を通じて判断を積み重ねる作業に向く。 | 設計意図の言語化、代替案比較、影響範囲の評価が必要になる。 |
この表から分かるのは、Devin 型と Claude Code 型が、単に別の製品であるだけでなく、別の組織能力を要求するということである。Devin 型は、タスクを閉じる力がある組織で強い。Claude Code 型は、作業中に判断を重ねる力がある組織で強い。第一段階では、組織の作業構造が、AI に向く使い方を決める。第二段階では、AI の使い方が、組織の弱点を増幅する。タスク分解が弱い組織で委任型を使えば、曖昧な依頼がそのまま曖昧な成果物になる。差分を読めない組織で併走型を使えば、AI の提案を漫然と採用する危険が高まる。
既稿では、生成 AI が広がるほど、知識量そのものよりも、問いを設計し、出力を評価し、複数の情報を統合し、責任境界を明確にする力が差を作ると整理した[31]。AI コーディングエージェントでも同じである。差を作るのは、AI を導入しているかどうかだけではない。どの作業を切り出し、どの権限を与え、どのレビューで止め、どの判断を人間に残すかである。AI は、組織の判断力を代替するというより、組織の判断構造を露出させる。
このため、AI コーディングエージェントを選ぶ前に、組織は自分たちの開発プロセスを点検する必要がある。チケットは実行可能な粒度で書かれているか。完了条件は明確か。テストは信頼できるか。レビュー観点は共有されているか。AI に渡してよい認証情報と、渡してはいけない認証情報は分かれているか。ローカルで確認すべき差分と、自動化してよい差分は区別されているか。これらが曖昧なままでは、どのツールを導入しても、AI は既存プロセスの曖昧さをそのまま増幅する。
したがって、組織適合性は、ツール選定の後に考える補助項目ではない。むしろ、ツール選定そのものの前提である。Devin を選ぶことは、AI に渡せるタスクを明確に切り出し、返ってきた成果物をレビューする開発プロセスを強めることである。Claude Code を選ぶことは、開発者が作業中に AI と対話し、差分を読み、設計判断を言語化する開発プロセスを強めることである。どちらのモデルも、組織の作業構造と合えば強力に働く。合わなければ、AI の能力が高くても、曖昧な依頼、過剰な権限、形式的なレビュー、漫然とした承認が増える。
最終的に、Devin と Claude Code の選定は、外部の製品を選ぶ話であると同時に、自分たちの開発プロセスを診断する話である。作業を事前に閉じられる組織は、委任型の恩恵を受けやすい。作業中に判断を積み重ねる組織は、併走型の恩恵を受けやすい。どちらを選ぶかは、AI の性能差だけでは決まらない。自分たちがどこで曖昧さを処理し、どこで人間の判断を残し、どの単位で成果物を確定しているかによって決まる。
15. 結論――AI コーディングエージェントは、作業・判断・責任・曖昧さの配置を変える
Devin と Claude Code は、同じ AI コーディングエージェントという言葉でくくられる。しかし、両者の差は、製品機能の優劣ではなく、開発作業をどう配置するかの差である。Devin は、作業場を切り出し、タスクを渡し、専用環境で調査、実装、テストを進め、成果物をレビューする構造に強い。Claude Code は、開発者の作業場に入り、差分を見ながら、調査、修正、確認、方針変更を積み重ねる構造に強い。前者は委任された作業をまとめる方向へ寄り、後者は作業中の判断を支える方向へ寄る。
この違いは、単に非同期か同期か、自律型か対話型かという分類では足りない。第一に、実行環境が違うことで、AI が触れるファイル、コマンド、認証情報、外部サービスの範囲が変わる。第二に、その範囲が変わることで、人間がどこで止め、どこで確認し、どの単位で成果物を採用するかが変わる。Devin では、環境境界と事後レビューが重要になる。Claude Code では、操作ごとの承認、差分読解、途中の方針修正が重要になる。したがって、両者の比較は、機能一覧ではなく、責任境界と介入点の比較として読む必要がある。
中心にあるのは、曖昧さの処理位置である。Devin は、曖昧さを事前に処理できるほど有効になる。目的、変更範囲、完了条件、テスト手順、失敗時の戻し方が明確であれば、AI に作業を渡しやすい。Claude Code は、曖昧さを作業中に処理できるほど有効になる。既存コードの意図、仕様の解釈、修正範囲、設計上の妥当性が作業を進める中で見えてくる場合、人間が差分を読み、追加指示を出し、採用範囲を調整できる構造が強く働く。
このため、AI コーディングエージェントの選定は、どちらの AI が賢いかを比べることではない。開発組織が、自分たちの曖昧さをどこで扱っているかを見極めることである。タスクを事前に閉じられる組織では、委任型が機能しやすい。作業中に仕様や設計判断を積み重ねる組織では、併走型が機能しやすい。第一段階では、組織の作業構造が、AI に向く使い方を決める。第二段階では、AI の導入が、その組織の作業構造をさらに強める。タスク分解が強い組織では委任が進み、差分読解と設計判断が強い組織では併走が進む。
同時に、AI に作業を任せることと、AI に判断を渡すことは分けなければならない。AI に調査させること、コードを書かせること、テストを回させること、Pull Request を作らせることは、作業の外部化である。しかし、仕様として正しいか、設計上受け入れられるか、運用上のリスクが許容できるか、組織の成果物として採用してよいかは、人間が判断する領域である。AI が作った差分は、生成された時点では候補である。人間が採用した時点で、組織の成果物になる。
AI が強力になるほど、人間の役割は消えるのではなく移動する。手で書く量は減るかもしれない。しかし、問いを切ること、作業を閉じること、権限を設計すること、差分を読むこと、テスト結果を解釈すること、採用可否を判断すること、失敗時に戻せる状態を保つことは、むしろ重要になる。第一段階では、AI が実行を担うことで、人間の直接作業は減る。第二段階では、その実行結果を採用するかどうかを判断する責任が、人間の側により明確に残る。実行の自動化は、判断の不要化ではない。
Devin と Claude Code の比較から見えるのは、AI コーディングエージェントが、コードを書く道具にとどまらないということである。Devin は、作業を環境ごと切り出し、AI に委任する構造を強める。Claude Code は、開発者の作業環境の中で、AI と人間が判断を重ねる構造を強める。どちらも、開発における作業、判断、責任、曖昧さの配置を変える。したがって、AI コーディングエージェントを導入するとは、新しい開発支援ツールを追加することではなく、開発プロセスの中で何を AI に任せ、何を人間が保持し、どこで成果物として確定するのかを設計し直すことである。
参考文献
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- Cognition, Introducing Devin, the first AI software engineer（2024-03-12）. https://cognition.com/blog/introducing-devin
- Devin Docs, Devin の紹介. https://docs.devin.ai/ja/get-started/devin-intro
- Anthropic, Introducing Claude 4（2025-05-22）. https://www.anthropic.com/news/claude-4
- Claude Code Docs, Overview. https://code.claude.com/docs/en/overview
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
- Devin, The AI Software Engineer. https://devin.ai/
- Devin Docs, Classic configuration. https://docs.devin.ai/onboard-devin/repo-setup
- Claude Code Docs, Development containers. https://code.claude.com/docs/en/devcontainer
- Claude Code Docs, Common workflows. https://code.claude.com/docs/en/common-workflows
- Devin Docs, GitHub. https://docs.devin.ai/integrations/gh
- Claude Code Docs, Claude Code GitHub Actions. https://code.claude.com/docs/en/github-actions
- Devin Docs, Integrations Overview. https://docs.devin.ai/integrations/overview
- Claude Code Docs, Connect Claude Code to tools via MCP. https://code.claude.com/docs/en/mcp
- Claude Code Docs, Security. https://code.claude.com/docs/en/security
- OWASP, OWASP Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/
- NCSC, Prompt injection is not SQL injection (it may be worse)（2025-12-08）. https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
- Devin Docs, Billing. https://docs.devin.ai/admin/billing
- Devin, Plans and Pricing. https://devin.ai/pricing/
- Claude Support, Choose a Claude plan（2026-05-19）. https://support.claude.com/en/articles/11049762-choose-a-claude-plan
- Claude, Plans & Pricing. https://claude.com/pricing
- Anthropic, Introducing Claude Sonnet 5（2026-06-30）. https://www.anthropic.com/news/claude-sonnet-5
- Anthropic, Introducing the Model Context Protocol（2024-11-25）. https://www.anthropic.com/news/model-context-protocol
- Model Context Protocol, What is the Model Context Protocol (MCP)?. https://modelcontextprotocol.io/docs/getting-started/intro
- SWE-bench, SWE-bench Leaderboards. https://www.swebench.com/
- Terminal-Bench, Terminal-Bench. https://www.tbench.ai/
- Jiacheng Liu, Xiaohan Zhao, Xinyi Shang, Zhiqiang Shen, Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems（2026）. https://arxiv.org/abs/2604.14228
- Zimo Ji, Zongjie Li, Wenyuan Jiang, Yudong Gao, Shuai Wang, Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code’s Auto Mode（2026）. https://arxiv.org/abs/2604.04978
- id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
- NIST, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework
- id774, AI は思考設計格差を拡大する（2026-02-19）. https://blog.id774.net/entry/2026/02/19/3698/