ここまでのDevin観察日記のまとめ。なぜDevinは「破壊的」なのか？

Daiki Teramoto

今日は総集編ということで、Devinについて学んだことをまとめます。最近は飲み会でDevinと遊んだり、無茶振りばかりしていましたが、今回は真面目な考察です。ほぼ全て僕の主観で書いている（他の人から聞いた知見もある）のと、あくまで現時点のまとめであることにご注意ください。


Devinの基本

Devinはプログラマーを模したAIエージェントです。自分のShellとVSCodeとブラウザを持ち、ユーザーと対話しながら自律的にタスクをこなすことが出来ます。コードを読んで働いてくれるので、ちゃんと業務にも使えました。

料金は月額500ドル〜です。従量課金制で、ACUs と呼ばれるクレジットを消費します。500ドル課金すると250ACUs貰えて、それが無くなったら追加で購入するという形です。僕は今のところ３週間で500ACUs使いました。

DevinはGitHub Appsとしてインストールされます。おそらくGitHub側の制約により、以下のことは出来ません。

  • リポジトリを作成する

  • 他人のリポジトリにContributeする

プロンプトを自分でカスタマイズすることも可能で、Knowledgeという機能がそれです。Devinがミスをおかしたとき、それを指摘すれば、次回からはKnowledgeを読んでミスを回避してくれることもあります。この辺の流れは１日目の日記が分かりやすいです。

Devinと他のツールの違い

Devinと他のツールの違いを一言で言うと、「Devinは組織をスケーラブルにする」ということです。詳しく説明します。

比較対象としているツールは、CursorやRoo Clineです。これらはとても便利なツールなので、僕も使っています。要素技術としての "出来ること" ──例えばコードの読み書き、ファイル操作、ブラウザ操作など──は、Devinとさほど変わりません。それに何よりコスパに優れています。（Devin比）

しかしそれらは「ユーザーを拘束している」という点で、あくまでツールに過ぎません。ユーザーはモニターを監視し、手のひらをキーボードに置き、必要に応じて介入を行います。オートマチックにも出来ますが、ユーザーがコックピットから降りられる訳ではありません。

Devinは、使い方にもよりますが、操縦桿を完全に渡してしまうことが可能な存在です。Devinをツールではなくエンジニアと認め、多くの裁量を与えることで、組織をスケーラブルにすることが可能になると思います。その理由はこのあとのセクションで言及していきます。

Devinは必ずしも優秀ではない

Devinは必ずしも優秀なプログラマーではありません。うっかり違うFirebaseアプリにデプロイして全てを破壊してしまう事もあります。

これは内部のモデルに依存しています。公開はされていませんが、おそらくGPTか、Claudeか、Geminiか、あるいはそれらのLLMの組み合わせによって作られていると思います。

ご存知の通り、現在は世界規模のLLM開発競争が巻き起こっています。それを追い風に受けて、Devinも（他のAIツールも）賢くなっていくでしょう。OpenAI o1のような賢いモデルと統合されれば、こんなかわいらしいドジを踏むこともなくなっていくでしょう。

Devinとセキュリティ

セキュリティについても言及しておきます。８日目の日記にも書きましたが、改めて強調しておきます。

この一件から得られた教訓は「Devinに渡した鍵は漏れる」ということです

Devin観察日記 ８日目

Devinにいくら口を閉ざすよう躾けても根本的な解決にはなりません。つまりDevinのセキュリティは、この２つのアプローチの組み合わせになります。

  • そもそも機密情報を渡さない

  • サンドボックス環境を用意する

機密情報を渡さずに済むなら、それがベストプラクティスになるでしょう。例えば CI で十分にテストが出来るなら、Devinに秘密鍵を与える必要はほぼなく、Pull Requestと CI の中だけで作業が完結します。しかし、CI だけで品質を担保できる業務はそう多くないでしょう。

Devinは人間と同じように環境構築を行うことができます。ブラウザを使って動作確認を行うことも可能です。しかし、機密情報が絡む場合──例えば開発環境にも認証が必須だったり、開発環境がSaaSに依存していたり、依存モジュールがPrivate Registryに置いてあったり──などの要件がある場合、Devin専用のサンドボックス環境を用意する必要が出てくると思います。

近い将来にも少し言及しておくと、サプライチェーン攻撃のリスクは急速に増大すると思われます。これはDevin（プログラマー）に限らず、むしろ管理職や総合職向けのAIエージェントが標的になるでしょう。利便性と安全性が天秤に掛けられ、IT部門は頭を抱えることでしょう。

Devinとマネジメント

Devinは与えられた指示をもとに計画を立てて実行します。このとき、チームに暗黙的かつ自明でないルールが存在すると、衝突が発生します。例えば：

  • 不必要な依存モジュールを追加してはならない。（正当な理由とチームの了承が必要だ。サプライチェーン攻撃のリスクもある）

  • １つのPull Requestに２つ以上の目的を混ぜてはならない。差分は少ない方が好まれる。（レビューする側の負担もちょっとは考えてくれ）

  • WebサービスのURLやCLIツールのコマンドを勝手に変えてはならない。（ユーザーが怒るよ）

  • 運用中のサービスをみだりに変更してはならない。（インシデントだろ）

一定のキャリアを積んだプログラマーであれば当然と思われるかも知れません。しかし敢えて言いますが、これらのルールは非自明です。世界中の開発チームにはそれぞれのルールがあり、さらに時と場合によってはルールから逸脱した振る舞いが求められます。Devinはそれを文脈なしで理解できるほど優秀ではありません。

とはいえ、すべてを明文化することも現実的ではないですよね。そこで発想を変えて、「Devinに権限移譲してもいい仕事は何だろうか？」と考えてみます。プロトタイプ開発やマニュアル整備などがいいかも知れません。Devinは仕事を選り好みしないので、人間がやりたくない仕事が良いでしょう。

Devinの特性を理解した上で、チームとして全体最適を考える必要があります。でないと、楽しい機能開発はDevinがしているのに、貴重で高給な人間のプログラマーがデバッグ要員になっている、なんていう笑えなない事態になってしまいます。僕はなりました。

つまり、Devinのマネジメントは人間のそれと非常に似通っているのです。結局のところ、仕事をさせる＝裁量を与えることなので、裁量を与えずに大きな仕事を任せるとハレーションが起きやすかったり、マイクロマネジメントが必要になってしまいます。Devinを活躍させるには良いマネージャーが必要なのです。

Devinはマネージャーにとって都合がよすぎる

最後に僕が一番「破壊的だ」と思っている理由を紹介します。先述した通りDevinは優秀なプログラマーとは言い難いです。しかしマネージャーにとって都合のよい特徴に溢れているのです。

  • 気を遣わなくていい

  • 24時間365日勤務可能

  • 雇用リスクがゼロ（仕事がなければ給料はタダ）

  • 社会保険・雇用保険の加入義務なし

  • 並列でいくらでもタスクを積める

  • 問題が起きた時のトレーサビリティが高い

  • すべての行動が時系列のログで蓄積しているので、生産性を測りやすい


雑感

このことに年末気付いたとき、正直言うと気が滅入りました。自分がマネージャーの立場に立ったとき、面倒で偏屈な自分よりも、いずれ都合の良いDevinを選ぶようになることが明白に思えたからです。

そこでもう振り切って、コードが書けることにアイデンティティを持つことをやめようと思いました。レベル１０のプログラマーのジョブを育てるより、レベル１の「Devinのマネージャー」で最初からやり直す方が楽しそうな道に思えたからです。ちょうど３０歳、人生リスタートするには丁度いいでしょう。などと考えながら、このDevin観察日記を書いているのでした。


追記

ついにDevinの紹介キャンペーンが始まりました！🎉
以下のリンクからDevinを契約すると、+100 ACUs ($200) が貰えます。会社で契約する方も、個人で契約する方も、お得なのでぜひご利用ください。

（HackforPlayというのは私の会社の名前です）

いいなと思ったら応援しよう！