Devin は Cognition の自律型コーディングエージェントであり、2024 年 3 月に Cognition によって「最初の AI ソフトウェアエンジニア」として発表された（初の AI ソフトウェアエンジニア Devin の紹介）。エージェント型ソフトウェアエンジニアリング：基盤となる柱と研究ロードマップ では、Google の Google Jules、OpenAI の Codex、Anthropic の Claude Code と並んで、同論文の SE 自律性レベル（SE1.0–SE5.0） の階層におけるゴール・エージェント型（レベル 3、SE3.0）の能力を目指すエージェントの例として論じられている。すなわち、明確に定義された技術的目標（例:「キャッシュ層を追加する」）を受け取り、自ら考案した、あるいは人間の指示を受けた多段階の計画を、コード、ドキュメント、その他の不可欠なプロジェクト成果物にまたがって実行する能力である。
メルカリでこれを運用するチームは、より実務的な言葉で、自律的にコードを調査し、コードを書き、プルリクエストを提出できるサービスとして説明しており、組織レベルで運用するにはいくつかの管理上の課題が伴うと指摘している（セキュアな Devin 管理によるメルカリでの AI 活用の実現）。弥生のチームは、このエージェントについて報告している複数の用途の 1 つとして、プルリクエストのレビュアーとしての利用を説明している（AIコードレビューの理想と現実 ─ Devinをチームに導入して気づいたこと）。
機能
Cognition の発表記事は、エージェントの作業環境を説明している。Devin はサンドボックス化された計算環境の中でシェル、コードエディタ、ブラウザを備えており、Cognition は、数千の判断を要する複雑なエンジニアリングタスクを計画・実行できる能力を、長期的な推論と計画の進歩によるものとしている。同記事は自律性と並んで協働も強調している。Devin は進捗をリアルタイムで報告し、フィードバックを受け付け、必要に応じて設計上の選択をユーザーとともに検討する。また、エンジニアと並んで開発することも、エンジニアがレビューするためにタスクを単独で完了させることもできると説明されている。発表時点では、ウェイトリストを通じたアーリーアクセスでのみ提供されていた。
論文は、Devin が利用する DeepWiki を、永続的メモリ機能の初期の例として挙げている。これによりエージェントは、複数のタスクにまたがって自身のドキュメントと意思決定ログを構築・参照でき、継続性が生まれ、過去の誤りを繰り返すのを防ぐのに役立つ。論文はこの例を、自らが提案する AI Teammate Lifecycle Engineering（ATLE） の活動の動機付けに用いている。
メルカリの記述は、運用者が向き合う実行モデルを説明している。Devin はセッションごとに独立した仮想マシンを起動するため、初期状態では GitHub などのソースコード管理サービスへの権限しか持たず、クラウド環境やチケット管理サービスに接続するには API キーなどの認証情報を個別に設定する必要がある。同記事はまた、Organization 内のメンバーがセッション内のファイルシステムとシェルにアクセスできること、そして Devin は AI エージェントとして与えられた API キーを自由に使えることも記録しており、この 2 つの性質を、認証情報を慎重に扱わなければならない理由としている。
この記述にはいくつかのプロダクトの構成要素が登場する。Devin Knowledge は、Devin における Agent Skills と同様に機能するものとして説明されている。Devin MCP は、エージェントが Devin にアクセスするためのインターフェースであり、API キーを必要とする。Devin Wiki は、Devin MCP を通じてリポジトリの内容の取得と自然言語検索を可能にする。ソースコードの調査をこれに委ねる理由として同記事が挙げるのは、AI エージェントが直接ソースコードを探索すると大量のコンテキストを消費し、委譲によってそれを削減できるという点である。
弥生の記述は、無人での利用に関わる 2 つの挙動を付け加えている。Devin は AGENTS.md を自動的に参照すると報告しており、そこにプロジェクト固有のルールとコンテキストを記録しておくとより精度の高いレビューが得られる理由としてこれを挙げている。同チームは、セットアップコマンド、コードスタイルとテストのガイドライン、プロジェクト構成、ワークフローに関するメモをそこに記載している。また、レビューセッションをプログラムから作成する方法も説明している。Devin API の sessions エンドポイントに対して、呼び出し側が組み立てたプロンプトを含む認証済みの POST を送ると、Devin が指摘事項をプルリクエストへのコメントとして投稿する。同チームは、セッションの起動が当初は遅く、それが 2 つの点で改善したと別々に述べている。エージェントが時間とともにプロジェクトを学習したこと、そしてプロジェクト情報をレビュープロンプトと AGENTS.md に事前に定義したことである。ただし最初のセッションは遅いままだった。これは 1 チームの観察であり、公表された特性ではない。
弥生の記事は、Devin Review という新しい機能にも触れている。そこでは、Web アプリケーションとして提供される包括的なコードレビュープラットフォームで、差分の整理とバグ検出の機能を備えたものとして説明されている。同チームは執筆時点で、これを API 駆動のアプローチと比較していなかった。
ベンダー自身による評価
Cognition の Devin の 2025 年人事評価：職場で働くエージェントの 18 か月から得た学び は、発表から 18 か月後に公開されたもので、エージェントがどこで良い成果を出し、どこでそうでないかについてのベンダー自身の説明であり、エンジニアの人事評価という体裁をとっている。同記事によれば、Devin はコードベースの理解ではシニアレベルだが実行ではジュニアレベルであるため、従来のエンジニアリングのコンピテンシーマトリクスに照らして Devin を位置付けるのは難しかったという。
実行面について Cognition は、Devin が最も力を発揮するのは、要件が事前に明確で成果が検証可能な、ジュニアエンジニアなら 4〜8 時間かかるようなタスクであり、並列に無制限に実行できるため、静的解析ツールが指摘した脆弱性の解消、言語やフレームワークの移行、ユニットテストの作成、小さなチケットの完了といった作業に適していると述べている。これとは別に、既存のコードが Devin の複製・修正すべき明確なパターンを提供するブラウンフィールドの機能開発についても説明している。移行については、各リポジトリの更新方法の指示を Devin が得れば、Devin の一群がすべてのリポジトリで並列に実行できるとしている。テスト生成については、人間がユニットテストのプレイブックを書き、Devin の一群がテストを書き、その後コードオーナーがすべてのロジックがテストされているかを確認する。Cognition はプルリクエストのレビューにおける役割を、明白な問題を見つける一次レビューに限定しており、コード品質は単純には検証できないため人間によるレビューが依然として必要だと述べている。
理解面については、同記事は、Devin が DeepWiki を通じて大規模なコードベースを文書化し、チャットインターフェース（AskDevin）を通じてエンジニアの計画作りを支援する様子を説明している。AskDevin は、アーキテクチャ図を用いてシステムを説明し、依存関係を洗い出し、破壊的変更を指摘し、人間と AI のどちらが取り組むべきかを推奨できる。
同記事は改善すべき点を 3 つ挙げている。Devin は曖昧なプロジェクトを自らの判断だけで最初から最後まで独力でやり遂げることはできず、ビジュアルデザイン、コンポーネント構造、カラーコード、余白の値といった具体的な指定を必要とする。事前に明確なスコープが与えられた場合はうまく対応するが、タスク開始後に追加の指示を与えられると通常は成果が悪化するため、同記事は、作業を事前にスコープ設定し、Devin を「マネジメント」する方法を学ぶ責任をエンジニアの側により多く求めている。そして、Slack、Teams、Jira で協働はできるものの、部下やステークホルダーを管理することはできない。これらは Cognition による自社製品の特徴付けである。
エンタープライズ管理
メルカリの記事は、Devin の管理機能について本 Wiki が持つ最も詳しい記述であり、ベンダーではなく運用者の立場から書かれている。Enterprise プランでは、Core プランや Team プランのように単一の Organization を共有するのではなく、複数の Organization を Enterprise の管理レイヤーを通じて一元的に管理する。同チームがこのプランを選んだ決め手となった機能は、Okta による SSO、監査ログ、権限管理、チームごとの環境分離であった。
管理機能は 2 つの API バージョンを通じて提供されている。同記事は v3 を最新の Enterprise 管理 API と説明しており、Enterprise と Organization の両方のレベルで Members、Roles、Secrets、Knowledge を管理でき、詳細なリクエスト・レスポンス仕様を備えた REST API として文書化されている。同記事によれば、Devin は 2025 年後半に v3 をリリースし、2026 年 1 月に Secret 管理を追加した。同チームは自動化を v3 の上に構築し、v2 API は API キー管理のためだけに使用した。v2 では複数の Organization にまたがって API キーの作成、取得、削除ができる。同チームは v3 の Enterprise Audit Logs エンドポイントを使用しており、v2 のエンドポイントとはページネーションがある点で異なるという。
同記事は、執筆時点でプロダクトが提供していなかった 3 つの点を挙げており、同チームはそれぞれを回避するための仕組みを構築する必要があった。公式の Terraform プロバイダーが存在しないため、Terraform Plugin Framework を使って独自に作成した。Devin は API キーの有効期限管理を標準機能として提供していないため、そのままでは長期間有効なキーが各 Organization に残り続けうる。そして Devin には Workload Identity Federation と連携するための OIDC トークン発行機能がないため、Google Cloud へのアクセスにはサービスアカウントキーが必要になる。利用量は ACU（Agent Compute Unit）の上限によって制限され、同チームは想定外のコスト超過を防ぐため、Organization ごと・セッションごとに上限を設定している。同記事の全体的な評価は、v3 API にはすでに Enterprise 管理に必要なエンドポイントが揃っている一方、標準機能でカバーされない管理要件は独自ツールで補う必要があった、というものである。
導入とエコシステム
メルカリ は Enterprise プランで社内の複数チームに展開し、各チームの情報が分離されるようチームや目的ごとに Organization を割り当てており、同記事の時点で多数のユーザーを抱える 10 を超える Organization を運用していた。これは 1 社の導入事例であり、それを管理するチーム自身が報告したものである。
弥生チームの導入は異なる形をとる。Devin はレビュアーとして GitHub Actions に組み込まれ、プルリクエストがオープン、更新、再オープンされたときに起動し、ドラフトとフォークは除外する条件が設けられ、リポジトリにコミットされたレビュー観点ファイルに基づいて動作する。この記述は利点と同じくらい具体的に限界も報告している。プロジェクトのコンテキストの把握が不十分なために的外れな指摘が生じること、そしてプロジェクトが意図的に許容している事項に対する誤検知である。同記事は、問題ではないと判断したケースを記録する場所として Knowledge 機能を挙げ、同じ指摘が繰り返し上がらないようにする意向を示している。この意向はチームの方向性として述べられたものであり、確立した実践としてではない。