@dyoshikawaです。
先月、社長にお願いしてZennチームに試験的にDevinを導入することができました。
導入して約1ヶ月ほど経ったので、Devin含むAIコーディングエージェントの活用や課題、そして生成AI時代におけるエンジニアの役割について思うところを書いてみようと思います。
Devinとは
自律性の高いAIコーディングエージェントです。Cognition社（Devin開発元）いわく「最初のAIソフトウェアエンジニア」。
AIモデルが独立した動作環境（Linuxサーバ）、コーディングエディタ（VSCode。拡張機能も入れられる）、ブラウザを持っており、それらを自由に操作する権限を与えられていることが新規性だと思っています。
かなり話題になっており、Zennにも毎日のようにDevinに関する記事が執筆されています。
Devinに懐疑的な見方もある
（特に海外の一部ユーザーの間などで）Devinのタスク遂行力に懐疑的な見方もあります。
これなどはかなり痛烈なコメントですね 🤔
評判だけ見てもよくわからないので、Zennコードベースに導入してみる
TODO Appのような典型アプリの0→1開発をさせても、コーディングAIの性能は図りづらいと思っています。このような試みには「学習済みの公開実装を丸写ししてるのでは？」という指摘が付きまといます。
この点、一定以上の規模があり、かつクローズドな既存コードベースの拡張に本当に使えるのか？が私の関心事でした。
そこで実際にZennの本番コードベースに導入してみることにしました。これが手っ取り早いでしょう 💪
約1ヶ月導入した結果
Devinを導入して約1ヶ月が経過しました。結論から言うと、使い方を見極めればかなり有用だと思いました。今後も使いたいです。
一方で、要件を伝えて実装を丸投げしてもあまりうまくいきませんでした。CopilotやCursor、Clineなどのエディタに統合されたAIコーディングツールと同様、実装まで踏み込んだ指示が必要という印象です。
総評として、「AIソフトウェアエンジニア」という言葉から受ける（私の）期待値には及ばない部分がありつつも、Cursor AgentやClineの延長、サンドボックス環境で動作するさらに自律的なツールとして高評価に値すると思っています。
成果としては、10営業日で約30個のDevinによるPRをマージしました。PRの数で生産性を測ることの是非はあると思いますが、自分は1営業日あたり1〜2PR作成という感じだったので、マージに至るPR作成のペースが非常に速くなったことは確かです。また、とある新機能の7〜8割以上はDevinによるコーディングで実装できたといったことも成果として挙げられます。
AIコーディングエージェントを使うポイント
Devinに限らない、AIコーディングエージェントを使う際のポイントになると思った点を紹介します。
タスクを分割して依頼する
1つ目は、とにかくタスクを細かく分割して依頼することです。
AIコーディングではコンテキストが長くなるほどLLMの出力精度が低下していきます。
Devinそのものではありませんが、OpenHands（OpenDevin）のドキュメントでも、
Agents do exceptionally well at "greenfield" tasks (tasks where they don't need any context about an existing codebase) and they can just start from scratch.
日本語訳: エージェントは「グリーンフィールド」タスク（既存のコードベースに関する文脈を必要とせず、ゼロから始められるタスク）において非常に優れた性能を発揮します。
と書いてあったりします。
海外開発者のSteve Sewell氏の「Why AI is making software dev skills more valuable, not less（日本語訳: なぜAIがソフトウェア開発スキルをより価値あるものにしているのか、価値を下げているのではない理由）」というYoutube動画に出てくる「pit of death」という概念もとてもわかりやすかったので紹介します。pit of deathは日本語で「死の落とし穴」のような意味になります。
内容から少し抜粋して紹介します。
AIにコーディングさせていると、いずれpit of death（エラーから抜け出せない、同じ失敗を繰り返す、etc・・・）が訪れます。これを復帰させるには、人間の開発者の手による修正が必要です。
pit of deathが訪れる
pitから復帰させると、大抵の場合、そう進まないうちに次のpitにハマります。そしてアプリケーションが複雑になるほど、pitの間隔は短くなっていき、より開発者の介入が必要になります。
アプリケーションが複雑になるにつれ、pitの間隔が短くなっていく
AIコーディングで上記のような経験をした人は多いのではないでしょうか。
逆に言えば、
- タスクのスコープを狭める
- 1つのタスクあたりのステップ数を少なくする
を意識することで、pit of deathに陥らずにタスクを完遂させられることになります 👍
また、タスクを小さくすると自動的にPRも小さくなるので、レビューの見落としやマージの恐怖感が軽減されます（やってみてわかったのですが、100%AIが書いたPRを本番稼働コードベースにマージするのは結構怖さがありました）。
作業に必要な情報を可能な限り加える
- 生じている課題とその解決策（なぜこれをやるのか、実現したい仕様）
- 実装方針（やること）
- 修正対象ファイルのパス
- 実装の参考にすべきファイルのパス
やるべきことはすでにエンジニアの頭の中にあって、それをAIにやらせるイメージです。
グローバルだったり再利用可能な背景情報は .{任意のツール}rules や、DevinならKnowledgeに設定しておくことでコンテキストのDRY化を実現します。
今のところ以下のようなKnowledgeを設定しています。
- Lint・型チェック・自動テストの実行ガイド
- バックエンド開発ガイド
- ActiveRecordモデルのMermaid ER図（ZennのバックエンドはRuby on Railsです）
- PR作成時のルール
テストコードは必須レベル
最後は、テストコードの存在です。必須レベルだと思います。
テストコードがないとAIが自律的にフィードバックサイクルを回すことが難しくなります。一応、ブラウザを使った手動テストをDevinに指示することもできますが、不安定なのと、消費コスト的にも見合わない可能性が高いと考えており、あまり使っていません。
Lintや型チェックといった静的テストもあった方が良いでしょう。
現状ZennチームDevin活用はバックエンド開発に寄っていて、それはフロントエンドのテストコードが少ないことが一因としてありそうです。今後、それこそDevinの力も借りてテストを拡充していきたいですね。
Devin特有の強み
AIコーディングエージェント系のプロダクトの中でも、特にDevinを気に入っている点を紹介します。
クラウド上のサンドボックス環境で動作する
Devinの大きな強みの1つは、AIにコマンドを実行させることへの安心感だと思います。確かに、どんどんコマンドを実行する自律的なAgentという点では、Cursor AgentやClineもすでにその機能を満たしていますが、セキュリティ的な非機能要件を満たすことが難しいと考えています。
また、タスクごとに環境が完全に独立しており、並列作業が可能であることも大きな強みです。これは特に、DBのマイグレーション実行状況の差異など、Stateが伴うバックエンドの開発タスクを並列に進める際に非常に便利です。ローカル端末上での開発だと、
- ブランチAはカラムaの追加を含んでいる
- ブランチBはカラムbの変更を含んでいる
といった場合に、ブランチを行き来するたびにマイグレーションのロールバックを実行する必要がありますが、Devinを使うとよりシームレスにタスク間を移動して作業ができます。
Slack連携
Slack連携時の使い心地がとても良いです。タスクの依頼から通知を受け取るまでの流れが非常にスムーズで、シームレスな使用感があります。
チームメンバーとAIとの会話を自然に共有できるのも良いと感じます。
安い（！？）
「Devin高いのでは？ 🤔」という向きもあるかと思います。
DevinはACUという単位で課金されます。
ドキュメントによると、1ACU=15分作業に相当、そして1ACU=$2です。
そうするとDevinの時給は$8になります。
ClineやOpenHands（OpenDevin）上でClaude Sonnet 3.7をフルに使用すると、1時間あたり$20〜$30かかると言われています。
これらと比較すると、時間あたり単価はDevinの方が安いといえると思います。
手前味噌ですがこちらの記事も併せてご参照ください。
現状のDevinに感じた課題
Devinにさらなる改善を期待したい部分もあります。
ひとつはKnowledgeがDevin WebアプリのUI上で管理されることです。
他の .*rules 系ファイルとある程度管理を一元化するためにGitHubリポジトリ上で管理できると嬉しいなと思います。
もうひとつは成果物への課題感です。導入当初は変更を指示していない箇所も自己判断で修正することが頻繁にありました。その対策として以下のようなKnowledgeを記述しています。
## コードの変更範囲
原則として、指示された内容以外は追加・変更しないでください。
例えば、「記事作成APIの修正を依頼した場合に、記事作成APIに加えて記事取得APIのコードも修正する」といったことは推奨されません。
明示的に依頼した内容にのみ取り組んでください。
また、ループの中でクエリを発行するようなN+1問題を引き起こすコードを出力する場合もありました。この場合は人間のレビューで修正とその方針を指示する必要があります。
上記より、現状はコードを理解できない人が扱うのは難しいと思います。
また、指示自体はコンパクトに収まるようなものでも、広範にファイルを跨ぐタスクは難しいと感じました。特に向いてそうなのに意外と向いていないと思ったのは 「ライブラリのバージョンアップ」系のタスク です。これらは多数のファイルを見ないといけないので、コンテキストが膨らんで出力の精度が落ちてくるのだと推測しています。また、知識のカットオフ日を超えた知識（ライブラリの最新版のAPI）を要求されるという点もあるかもしれません。
生成AI時代におけるエンジニアの役割
未来は誰にもわからないことを承知の上、Devinの使用を通して、生成AI時代に（ソフトウェア）エンジニアの仕事がどうなっていくかのIn my opinionを書いてみます。
コードの読み書きができるエンジニアの価値は？
コードの読み書きができるエンジニアの価値はどうなっていくでしょうか。
私の予想としては、プログラミング言語でコーディングできる開発者は Expert of Expert（専門家の中の専門家） になるのではと思いました。
現在、一般的なエンジニアにとって必須（Must have）のスキルは、高レベルなプログラミング言語を使ったコーディング能力だと考えています（必ずしもそうではないですが、話を簡略化するために仮定します）。基本的なコーディングスキルを備えた開発者をExpertと位置付けた場合、そこからさらに特定分野の知識・知見を深めた開発者はExpert of Expertとなり、それを自身の強みとして確立していきます。エンジニアは人間という集合の中ではすでに専門家ですが、エンジニアの集合においてはさらに深い専門知識を身につけないとなかなか専門家と呼ばれづらいところがあると思います。エンジニアの中でもさらに固有の知識を持った人が「専門家」としてフロントエンドエンジニアやバックエンドエンジニア、セキュリティエンジニアと呼ばれたりします（と思います）。
この点、将来的に一般的なエンジニアにとって必須のスキルはAIコーディングへとシフトしていくのではないかと思います。一方でその場合、プログラミング言語を使ったコーディングスキルは、「プログラミング言語のコードが読み書きできる開発者」のExpert of Expertとして、その価値は今後も残るのではないでしょうか。AIにより生産性のブーストを受けつつ、AIの出力を自らのスキルで微調整できるということが重要になっていくはずです（つまり、また覚えることが増える 😇）。
AIコーディングは実質的に自然言語を用いたプログラミングと言えると思いますが、依然としてプログラミング言語には表現の厳密性において原理的に揺るがない優位性があるように思います。そのため、チーム内にプログラミング言語の読み書きができる人材は引き続き必要になるはずです。例えば、ガベージコレクション言語が広く普及している現在でも、低レイヤーの知識を持つエンジニアが根が深いパフォーマンス課題をプロファイラで分析して解決するといったケースがあります。コードが読める開発者も、未来のAIコーディング時代にはそういった役割になっていくのではないかなと思っています。
ジュニアエンジニアが要らなくなる？育たなくなる？
生成AIについてXなどでよく見る懸念として、ジュニアエンジニアが不要になったり、育つ機会がなくなるのではないか？という議論があります。
私の予想としては別にそんなことはないだろうと思っています。
AIコーディング以前の世界観でジュニアエンジニアを定義してもあまり意味はないように思います。前提が変わったとすれば、AIがある前提でジュニアエンジニアは業務遂行し、育っていくのではないかと。
例えば、私は2017年頃にプログラミングを学び始めました。Railsチュートリアルを雰囲気でなぞってなんとなくWebアプリケーションは作れるようになりましたが、フレームワーク背後の知識は何も理解していませんでした。必要に応じてログインの仕組みやDBのインデックスについて深ぼっていった記憶があります。
低レイヤーからボトムアップで学ばないと身につかないということはなくて、私のように高レイヤーから入って開発業務をしている人も多いと思います。AIコーディングについても同様ではないでしょうか。
AIとの対話でより高速に学べるようになるなど、むしろポジティブな側面の方が強いように感じます。
まとめ
まとめです。
DevinをZennの開発に導入し、使い方を見極めればかなり有用なツールだと感じました。
一方で、万能ではなく課題もあります。あくまで「エンジニアの」生産性を上げるツールだと感じました。
生成AI時代におけるエンジニアの役割については、将来AIコーディングの精度がさらに向上してもなお、プログラミング言語の読み書きができるエンジニアはExpert of Expertとして価値は残っていくのではないかと考えています。また、ジュニアエンジニアの育成についても、AIがある前提で新しい形で進んでいくのではないかと個人的な予測をしました。
今後もDevinの活用について続報できればと思います。
Discussion
とても参考になりました。