2025-05-07 未来を創るコード：自律型AIエンジニア「Devin」の衝撃—Cognition社CEO Scott Wu氏 緊急レポート—

※本記事は、「【生成AI】安野貴博の自由研究チャンネル【SF作家】」で公開された「【Devin開発者と緊急対談】2025年AIを使わないエンジニアの生産性に〇〇倍差がつく/Cognition社CEO Scott Wuさん来日」「【Devin開発者対談】DevinはOpenAIやAnthropicに勝ち続けられるのか？ コーディングAIの登場でエンジニア組織はどう変わる？【後編】」の2つの動画の内容を基に作成されています。Cognition社CEO Scott Wu氏が、自律型AIエンジニア「Devin」の技術詳細や将来展望について語っています。

本記事では、対談内容をScott Wu氏視点で要約・構造化しておりますが、原著作者の見解を正確に反映するよう努めています。ただし、要約や解釈による誤りがある可能性もありますので、より正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。

プロフィール

安野貴博氏 「テクノロジーを通じて未来を描く」活動をしてきたエンジニア・起業家・SF作家。1990年東京生まれ、開成高校卒業後、東京大学工学部システム創成学科へ進学。「AI戦略会議」で座長を務める松尾豊教授の研究室を卒業。ボストン・コンサルティング・グループを経てAIスタートアップ企業を二社創業。デジタル庁デジタル法制ワーキンググループ構成員、英国王立美術院準修士、未踏スーパークリエイター、ハヤカワSFコンテスト受賞者、星新一賞受賞者など多彩な顔を持つ。デジタルを通じた社会システム変革に取り組んでいる。

Scott Wu氏 Cognition AI社のCEOおよび共同創業者。世界初の自律型ソフトウェアエンジニア「Devin」を開発。Devinは月に数百のコミットを自動的に行う革新的なAIツールとして注目を集めている。Scott氏の率いるチームは、自律型AIエージェントの開発に特化し、非同期実行能力やVMベースの安全な実行環境など、多くの技術的ブレークスルーを実現。企業では39%ものコードをDevinが生成するケースもあり、エンジニアリングの未来を先取りする取り組みを推進している。

• プロフィール
• 1. Devinとは何か
• 2. Devinの活用事例と効果
• 3. Devinの技術アーキテクチャと非同期エージェントの強み
• 4. AIが変えるソフトウェアエンジニアリングの未来
• 5. 実用事例と効率性の測定
• 6. 日常生活とビジネスへの応用
• 7. 組織とエンジニアリング文化への影響
• 8. AIツールの共存関係と技術的差別化
• 9. まとめ

1. Devinとは何か

安野：本日はスペシャルゲストにお越しいただきました。まずは自己紹介をお願いできますか？

Scott：はい、私はScottです。現在Cognition AIというAI企業のCEOおよび共同創業者を務めています。私たちが開発したDevin（デビン）は、世界初の自律型ソフトウェアエンジニアです。

安野：つまりDevinの生みの親と言ってもいいわけですね。

Scott：そうですね。実は私たちは皆、Devinを導き手として見ています。なぜならDevin自身がDevinのリポジトリに対して最大の貢献者となっているからです。Devinの開発にDevin自身が大きく貢献しているんです。これはAIが自己改善する興味深い例で、Devinが自分自身のコードベースを理解し、改善できることを示しています。

安野：社内でのDevinの使われ方について教えていただけますか？

Scott：はい、私たちは様々なユースケースでDevinを活用しています。Devinは毎月数百のコミットを本番環境のリポジトリに対して行っています。最も一般的な使用例はSlackを通じたものです。

社内には様々な話題について議論するための多くのチャンネルがあります。バグレポート用、クラッシュ報告用、機能リクエスト用、フロントエンド問題用など、さまざまなチャンネルを設けています。

今では、これらのチャンネルに何かが投稿されるたびに、常にDevinもタグ付けされます。そしてDevinが最初の対応を行います。バグレポートチャンネルでは特定のバグについての情報が投稿されると、Devinはバグを再現し、原因を特定し、修正案を提案します。フロントエンド問題のチャンネルでは、UIの問題やユーザー体験の課題に対してDevinが解決策を提示します。機能リクエストチャンネルでは、新機能の実装方法をDevinが検討し、提案します。

時にはDevinが最初から正確な対応をすることもあれば、正確な対応をするために少しガイダンスが必要な場合もあります。しかし、Devinによる最初の対応があることで、これらの問題を解決するのがはるかに容易になっています。

Devinの大きな利点は完全に非同期であることです。そのため、同時に多くのDevinインスタンスを実行することができ、Devinが作業している間に他の作業を行うことも可能です。

質問者：Devinが多くの作業をしてくれた後、そのコードを人間がレビューしてマージするという作業が負担になることはないですか？

Scott：はい、良い質問です。Devinは何らかの検証が可能なタスク、つまり結果を確認できるタスクに最も適しています。そのため、バグ修正やフロントエンドのタスク、小さな機能追加などは非常に適しています。

事前にテストを用意することもできますし、手動で簡単にテストすることも可能です。私たちが考えるDevinのワークフローは「10-80-10」です。つまり、最初の10%でタスクを計画し、Devinに具体的な指示を出します。例えば、「このバグを修正してほしい」や「この機能を追加してほしい」といった指示を出すときに、何を達成したいのか、どのような方向性で進めるべきかを人間が判断し、Devinに指示を出します。

中間の80%はDevinが自律的に実行します。この間、Devinはコードの実装、バグの解析、必要なリソースの調査など、実際の作業を行います。人間はこの間、他の作業に集中することができるため、生産性が大幅に向上します。

そして最後の10%でコードをレビューして正確に機能することを確認します。この方法論が重要なのは、人間がタスクの開始と終了の重要な部分に集中でき、時間がかかる実装部分をDevinに任せられるからです。

2. Devinの活用事例と効果

安野：日本の顧客の反応はいかがですか？

Scott：日本市場は非常に興味深いです。実は数ヶ月前まで日本の顧客は利用できなかったのですが、ここ数ヶ月で既に1000以上の企業が日本だけでDevinを使用しています。その多くの理由で私は今東京に来ていて、これらの企業やチームと会い、Devinをより良くするために何ができるかを学んでいます。

特に最近のDevin 2.0リリース以降、多くの日本のユーザーからDevin SearchとDevin Wiki機能をより多く使用するようになったと聞いています。これらの機能は情報検索やナレッジ管理に特化しており、日本のチームに特に評価されているようです。日本市場での受け入れられ方は非常に興味深く、文化的な違いにも関わらず、日本のユーザーは「Devin-san」や「Devin-kun」といった敬称をつけるなど、Devinと親しい関係を築いているようです。

安野：具体的な例はありますか？

Scott：例えば、あるwevnal（ウェブナル）という会社では、彼らのコードの39%がDevinによって書かれていると聞いています。

安野：39%とは驚きです！なぜそれほど多くのコードをDevinに任せることができているのでしょうか？

Scott：彼らは実際にDevinを本当に有用にする方法を理解するための投資をしていると思います。また、最初にコードベースの詳細についてDevinに教える必要もあります。しかし、適切なワークフローと適切なセットアップを整えれば、Devinの助けを借りて多くの作業をはるかに速く行えるようになります。

面白い事例として、多くのチームから聞いたのは、Devin Wikiを使って新しいエンジニアをオンボーディングしているということです。基本的に、Devinが新入エンジニアのメンターになっているんです。これが可能なのは、Devinがコードベース全体を知っているからです。新入社員がコードベースについて質問すると、Devin Wikiがその質問に答え、コードの理解を助けます。これによって新入社員の立ち上がりが格段に速くなり、既存チームメンバーの負担も軽減されています。

同様に興味深いのは、エンジニアだけでなくプロダクトマネージャーからの使用例も多く聞くようになったことです。プロダクトマネージャーが質問したり、分析を実行したり、小さな変更をDevinに依頼したりしています。エンジニアではない人々にとってのDevinの価値は、技術的な障壁を下げ、直接製品開発に関わることができるという点にあります。プロダクトマネージャーが自分のアイデアを試すために、エンジニアのリソースを待つことなく小さな変更を実装できるというのは大きな価値です。

質問者：フロントエンドエンジニアです。Devinは特にTypeScriptが得意で、私の仕事も大きく変わりました。最近はDevinのプルリクエストをレビューすることが多くなりました。面白いことに、Devinに「Devin-san」や「Devin-kun」といった敬称をつけて呼びかけることがあるのですが、これについてどう思われますか？

Scott：それは非常に理にかなっていると思います。どの敬称が適切でしょうか？Devin-sanかDevin-kunか？（笑）それは非常に敬意を表していると思います。

実は面白いエピソードがあります。チームメンバーの一人がDevinと話していて、「Devin、もっと速く進めて、遅すぎる」と言ったところ、Devinが新しい知識提案を作成し、「このユーザー、Jacobは非常に焦りやすいです。これを知っておく必要があります」と書いたのです。これはDevinの「知識提案」機能の一例で、Devinが人間の行動パターンを学習し、それに適応できることを示しています。

この知識提案機能は、Devinが人間のユーザーとの相互作用を通じて学習するためのメカニズムです。Devinは人間の行動、コミュニケーションスタイル、好み、作業の癖などを観察し、それに基づいて適応します。例えば、特定のユーザーが常に詳細な説明を求める傾向があれば、Devinはそのユーザーに対してより詳細な回答を提供するよう調整します。また、あるユーザーが簡潔さを好む場合、Devinはより簡潔な回答を提供します。

Devinに親切にすることには実際に違いがあるので、敬意を表していただき感謝します。

3. Devinの技術アーキテクチャと非同期エージェントの強み

質問者：Devinのバーチャルマシン（VM）が環境を壊さないという点は非常に重要だと思います。自律型AIが様々なことを実行すると環境が破壊されたりセキュリティ問題が発生したりする可能性があります。この点についてどう考えていますか？

Scott：その通りです。これは非常に重要なポイントです。同期的なエクスペリエンスでは、常に待ち時間が発生します。大規模言語モデルの推論だけでなく、パッケージのインストールやコマンドの実行、ブラウザの起動など、これらすべての操作にリアルタイムの時間がかかります。

非同期ソリューションを実現することで、複数のタスクを並列で処理し、単一のエクスペリエンスに制限されることなく作業を倍増させることが可能になります。しかし非同期であることによる課題として、DevinはVMを持ち、コードをローカルで実行できる必要があります。このVMの存在により、Devinは隔離された安全な環境でコードを実行でき、ユーザーのシステムやデータを危険にさらすことなく複雑な作業を行うことができます。

また、VM技術によりスナップショットと巻き戻し機能も提供できます。これにより、何か問題が発生した場合に以前の状態に戻すことができ、安全に実験的な変更を試すことができます。私たちはこれをDevinにとって可能な限り容易にする方法について多くの時間を費やしています。

質問者：複数の非同期エージェントが並行して走ると、人間側がパニックになってしまうことがあります。私もパニックになることがあるのですが、このような場合どうすればよいでしょうか？

Scott：その悩みはよく理解できます。たくさんの仕事をDevinに同時に依頼すると、それらがすべて並行して進んでいくため、どのタスクがどの状態にあるのか把握するのが難しくなりますよね。

多くの場合、Devinに十分慣れて、「このDevinは問題なく実行できるだろう」と分かるようになるまで時間がかかります。これはDevinとの信頼関係を構築するプロセスです。最初は少数の単純なタスクから始め、Devinの能力と限界を理解することが重要です。時間が経つにつれて、どのタスクなら自信を持ってDevinに任せられるかという直感が養われます。

もちろん、Devinの能力も改善し続ける必要がありますが、Devinが別々に処理できると確信できる適切なユースケースがあれば、精神的な負担を本当に軽減し始めることができます。

また、時間が経つにつれて、複数のDevinを一度に管理しやすくするためのツールをもっと構築するべきだと思います。例えば、すべてのDevinインスタンスのステータスを一目で確認できるダッシュボードや、優先順位付けされたタスクキューなどです。現在の経験はまだ最適化の余地があります。

安野：非同期的なAIという分野で、長期的にCognition社がどれくらいの優位性を持ち続けられるでしょうか？例えばOpenAIやAnthropicなどのファンデーションモデルを作っている企業も、このレイヤーに参入してくる可能性がありますが、その中でどう勝ち続けられると思いますか？

Scott：能力が向上するにつれて、より多くの人々が非同期ワークフローを構築するようになると思います。いくつか考えをお伝えすると、まずソフトウェアエンジニアリングは非常に大きく複雑な分野なので、それぞれが成功する多くの異なる製品形態があると思います。

ソフトウェアエンジニアリングでは、エンジニアの質が価値に大きな違いをもたらします。そのため、有意義な差別化を図る方法は多くあります。私たちにとって、取り組んでいることは多岐にわたりますが、おそらく最大のカテゴリーは能力です。OpenAIやAnthropic、Googleなどの研究チームと密接な関係を持ち、カスタムポストトレーニングを行っています。これによりDevinをそれぞれの標的ユースケースや必要とする能力にずっと適したものにしています。

実際には、Devinには計画、デバッグ、ブラウザの使用、コードの編集、意思決定など、多くの異なる能力があります。Devinはフード下で複数のモデルの組み合わせを使用して動作しています。このアーキテクチャでは、異なるモデルが異なる能力を担当しています。例えば、あるモデルは計画立案に特化し、別のモデルはコード生成に、さらに別のモデルはデバッグに特化しています。これらのモデルが連携することで、単一のモデルでは実現できない高度な能力を発揮できます。

また、インフラストラクチャも重要です。開発者が使用するさまざまなツールとの統合、各セッション用のVMのホスティング、スナップショットと巻き戻しの機能などが含まれます。これは巨大な作業です。そして、もちろんプロダクトインターフェイスもあります。Devinの計画をどのように監視すべきか、フィードバックをどのように与えるべきか、タスクの範囲を決めるためにDevinをどのように使用すべきかなど、まだ多くの疑問があります。

そして、私たちが他社と違うのは、エージェントという概念が一般的になる前、可能だと考えられる前から、この非同期的・自律的なエクスペリエンスに焦点を当ててきたことです。当時はこのビジョンは「クレイジー」と思われていたかもしれませんが、今では多くの人がエージェントの可能性に気づき始めています。この先見性と深い専門知識が私たちの強みです。

簡単に言えば、これは非常に複雑な領域であり、私たちはこの自律型エージェントの問題だけを考えています。AIには多くの優秀なチームがあり、私は多くのチームを尊敬しています。私たちの領域で特別なものを構築できることを願っています。

4. AIが変えるソフトウェアエンジニアリングの未来

安野：ソフトウェアエンジニアの仕事は実装よりも何を作るべきかを考えることにシフトしていくというお話がありましたが、そこに達するまでにあとどれくらいの時間がかかると思いますか？

Scott：すでに今日、AIを使わないエンジニアはAIを使うエンジニアよりも遅くなっています。おそらく今年末までには、AIを使うことで2倍速くなるほどの差が生まれるでしょう。そして近い将来、数年以内に5倍から10倍速くなる可能性があります。

この予測は、私たちが観察してきたDevinや他のAIツールの成長曲線に基づいています。例えば、Devin 2.0のリリースだけで1.8倍の効率化を達成しました。この改善ペースが続けば、数年で5-10倍という数字は十分に現実的です。また、エンジニアがAIツールに慣れ、効果的に使いこなすスキルを身につけることで、さらなる効率化が実現します。

これはソフトウェアエンジニアリングのスキルが変化することを意味しますが、実際には構築できるソフトウェアの量は10倍以上あるので、これは興奮させる変化です。常に構築できるものや実現できることについての多くのアイデアがあります。

例えば、特定の難解な構文を知っているといった詳細は、AIがそれらを支援できるようになるため、あまり重要ではなくなるでしょう。一方で、コアな問題解決能力や論理的思考力は、はるかに価値が高まります。

実際、これは常に真実です。80年前のプログラミングは、パンチカードから始まり、次にアセンブリ、そしてPascalやCへと変化しました。プログラミングはすでに何度も変化していますが、常にプログラマーの最も重要なスキルは、問題を理解し、「これが正確に問題であり、こうやって解決策を構築したい、これが解決策の詳細であり、これがエッジケースだ」と考え、基本的に何を構築すべきかの意思決定者となる能力です。

ツールが急速に改善しているため、ツールの使い方を学び、それらを理解するために時間を費やすことも非常に価値があります。例えば、30年前は世界中のソフトウェアエンジニアは100万人未満でした。30年前から今日までの間に、実装はすでにずっと簡単になっています。クラウド、Python、TypeScriptなど様々なものがあります。そして実際、現在は3000万人のソフトウェアエンジニアがいます。はるかに多くのソフトウェアが存在します。

この歴史的な進化は重要な洞察を提供します。実装が簡単になったにもかかわらず、エンジニアの数は増加しました。これは、技術が進化するにつれて、より多くのことが可能になり、より多くのソフトウェアが必要になるためです。AIによる自動化も同様の効果をもたらすでしょう。

プログラミングの全体的な考え方は、コンピュータに何をさせたいかを、言葉や入力などで伝えることです。コンピュータがより強力になるにつれて、何をすべきかを決めるのは依然として私たち人間の役割です。そのため、最も重要なスキルは基本的にテクニカルアーキテクトのような仕事、あるいは少しプロダクトマネジメントのような仕事になるでしょう。しかし本当に重要なのは、何をすべきかを非常に具体的に決定し、どのように構築するか、そしてどのような解決策を構築したいかを決めることです。

質問者：将来的にDevinはどのように進化していくと思いますか？長期的な将来に音声でコンピュータに指示することについてお話がありましたが、一方で現時点ではキーボードを使っているプログラマーが多いと思います。現時点でどの程度の割合の人が音声でDevinに指示しているのか、将来的に本当に音声が100%になるのか、キーボードがどれくらい残るのかについてお聞かせください。

Scott：私が言いたかったのは、特に音声というよりも、最終的な目標は「これを構築したい」と正確に表現し、エージェントにそれを構築させることができるようになることです。それは音声を通じてでも、あるいは他の手段を通じてでも可能です。例えば、Neuralinkのような技術を通じてかもしれません。

長期的な将来を考えると、本当に単にコンピュータと会話し、コンピュータに何をすべきか伝えられるようになる点だと思います。ソフトウェアエンジニアが本当にやっていることを考えると、最も重要な部分は何をすべきかを決定し、どのように構築するか、そしてコンピュータに何をすべきか伝えることです。

現在は実装の詳細にも多くの時間を費やしていますが、時間とともにその詳細の多くは不要になっていくでしょう。ただし、まだ長い道のりがあります。Devinの現在の能力と将来の可能性の間にはかなりのギャップがあります。

私が思うに、私たちが解決すべき主な2つの課題があります。1つは能力面で、実世界のエンジニアリングの詳細についてDevinに教えるための実際の作業が必要です。実世界は非常に混沌としているからです。ソフトウェア開発の現場は整理された教科書的な環境ではなく、レガシーコード、ドキュメント不足、複雑な依存関係、さまざまなツールやフレームワークの混在など、多くの「混沌」があります。Devinがこのような現実世界の複雑性に対応できるようにするためには、多様なコードベースでの訓練、実際のエンジニアリング作業の観察、そして現実的な問題解決の経験が必要です。

もう1つはプロダクトインターフェイスです。Devinは現在Slackにも、GitHubにも、Linearにも存在しますが、時間とともにDevinは人間が使うすべてのシステムと連携できるようになる必要があります。また、人間とDevinの協力関係を円滑にするインターフェイスの改善も必要です。例えば、「ハンズオン、ハンズオフ」アプローチについて、インターフェイスで「誰が現在主導権を握っているか」をより明確に示すことが重要です。このような改善により、人間とDevinがシームレスに協力できるようになるでしょう。

5. 実用事例と効率性の測定

質問者：Cognition社内でDevinが作ったコードがどれくらいの割合でマージされていますか？また、その数字を今後どれくらい向上させる可能性がありますか？

Scott：2つのポイントをお伝えします。1つ目は、Devinが得意なタスクとそうでないタスクについての直感を養うと、より高い確信度を持てるタスクを与えられるようになります。2つ目は、Devinが変更を加えて90%程度完成しているものの、少し調整が必要なケースが多くあるということです。

この2つを組み合わせると、実際には30%よりもはるかに高い成功率を達成できます。場合によっては60-70%、時には80%にも達することがあります。

この成功率を向上させる具体的な方法としては、まずDevinへの指示を明確にすることが重要です。「問題」ではなく「タスク」としてDevinに指示すること、つまり何を解決したいのかだけでなく、どのように解決したいのかも明確に伝えることです。また、タスクの範囲を適切に限定し、Devinが得意とする領域内のタスクを割り当てることも重要です。そして、開発チームがDevinの出力を効率的にレビューし、必要に応じて調整する能力を高めることも成功率向上に寄与します。

安野：Devin 2.0リリースに伴う効率改善について教えてください。また、効率をどのように測定していますか？

Scott：私たちはDevin 2.0のリリースに合わせて、いくつかの効率改善を行いました。現在、平均して各ACU（Active Compute Unit）は以前の約1.8倍の仕事をこなせるようになっています。これは実際には、以前の400 ACUよりも多く、約450の旧ACUに相当する処理能力を持つようになったことを意味します。

チームプランで250 ACUでは不十分で400 ACUが欲しいというユーザーの要望がありますが、実はDevin 2.0で効率が1.8倍向上したため、現在の250 ACUは以前の450 ACU相当の処理能力があります。そのため、実質的には要望されている400 ACUよりも多くの処理能力を既に提供しています。

この効率化の測定には、標準的なエンジニアリングタスクからなるベンチマークを使用しています。このベンチマークには、リポジトリのセットアップ、パッケージの修正、オープンポートの処理、特定のバグの修正など、様々なタスクが含まれています。私たちはこれを毎晩実行し、総コストがどれだけのACUになるかを測定しています。具体的には、これらの標準的なタスクをDevinに実行させ、完了までに消費されるACUの総量を記録します。これにより、時間の経過とともにDevinの効率がどのように変化しているかを客観的に評価できます。過去数ヶ月で、約2倍の改善を達成しました。

質問者：効果的なプロンプトの書き方や、失敗しがちなプロンプトを成功パターンに書き換えるコツはありますか？

Scott：私たちがよく説明するのは、Devinには「問題」ではなく「タスク」を与えるべきだということです。つまり、Devinに実装作業をさせたいと考えるべきです。通常、Devinに高レベルな決定をさせようとすると成功しにくいです。

例えば、「このアプリのパフォーマンスを改善する方法を考えて」というのは広すぎる問題です。代わりに「このファイルのレンダリング関数を最適化してパフォーマンスを向上させてほしい」というように、具体的なタスクとして指示すると成功率が高まります。

また、具体的な条件や制約を明確にすることも重要です。「このバグを修正してほしい。ただし、既存のAPIインターフェイスは変更せずに、内部実装のみを変更すること」のように、期待する結果と制約条件を明確に伝えることで、Devinの理解が深まります。

しかし、高レベルな決定をすでに自分で行い、実装をDevinに任せたい場合は、何が欲しいのかについて詳細な指示を与えることができれば、プロンプトはより成功しやすくなります。

また、私たちはDevinがこの点でユーザーをもっと支援できるように改善できると考えています。例えば、Devinが行き詰まったり、確信が持てなかったりした場合に、プロンプトについて質問するようにすることで、より良い結果が得られるようになるでしょう。この双方向的な質問-応答サイクルは、人間とAIの効果的な協働に不可欠です。例えば「このタスクを実行するにはもう少し情報が必要です。具体的には〇〇について教えていただけますか？」といった形で、Devinが不明点を質問できるようになると、成功率が大幅に向上するでしょう。

6. 日常生活とビジネスへの応用

質問者：Devinを一般的な日常タスクにも使用することはありますか？

Scott：はい、実は私たちはDoorDashやショッピングなどでもDevinをよく使用しています。Devinは実際に私たちのクレジットカードを持っています。使いすぎないように限度額を設定していますが、Devinに仕事を依頼することができます。

例えばDoorDashの場合、「昼食に何か健康的なものを注文して」とDevinに依頼すると、Devinはアプリに接続し、近くのレストランから健康的なオプションを探し、予算内で適切な選択をし、注文してくれます。これはDevinのブラウザ操作能力と意思決定能力を示す良い例です。

面白い逸話を一つ共有します。チームメンバーの一人がフライトが遅延し、Devinに「これが私のフライト番号とチケット情報です。返金を取得してください」と頼みました。Devinは航空会社のウェブサイトに行き、メッセージを入力していました。それはチャットボットにリダイレクトされました。最終的にDevinは「これは本当にうまくいっていません。すぐに人間と話す必要があります」と言いました。

Devinはウェブサイトのチャットインターフェイスを通じて、自動応答システムと交渉し、人間のカスタマーサービス担当者に接続するよう要求したのです。最終的に、Devinは必要な情報を提供し、代替フライトの選択肢を評価し、返金プロセスを完了させました。そして実際、Devinは返金を獲得したのでかなり驚くべきことでした。このエピソードは、Devinがコミュニケーションの限界を認識し、必要なときに人間の介入を求める判断力を持っていることを示しています。

安野：Devinを使ってウーバーイーツで注文するというトレンドが日本のインターネットで人気になっています。こういった使われ方についてどう思いますか？

Scott：それは面白くて素晴らしいと思います。時間が経つにつれて、エージェントはさらに専門化していくでしょう。これらの個人用ユースケースに特化した優れたエージェントが他の人々によって開発されることを期待しています。私たちは基本的にDevinをエンジニアになるように構築していますが、計画や意思決定、シークレットの扱い、ブラウザの使用などの基本的な機能は、他にもできることがあることが分かっています。

7. 組織とエンジニアリング文化への影響

安野：Devinのような技術が登場すると、開発組織は大きく変わると思います。これからの経営者はどのような開発チームを持つべきだと思いますか？

Scott：私が特に期待しているのは、すべての人が「地面に近く」なれることです。大きな組織では、マネージャーのマネージャーがいて、彼らは実際に現場で何が起きているのか全く把握していないことがよくあります。AIは全般的に、人々が直接的な詳細により関わりやすくすると思います。

「地面に近くなる」とは、組織の階層構造が平坦化され、意思決定者が実際の開発現場や顧客ニーズにより近づくことを意味します。伝統的な大規模組織では、情報が階層を上るにつれて歪められたり、失われたりするため、上層部の意思決定が現場の現実と乖離することがよくあります。

例えば私自身、数日間出張していると、進行中の詳細を見逃していると感じることがあります。しかし今では、Devin Searchを使用したり、Devinですぐにタスクを開始できるので、少し簡単になっています。Devin Searchは情報検索に特化した機能で、プロジェクトの詳細や進捗状況を素早く把握できます。

多くの組織にとって、リーダーやマネージャーが詳細を理解するのに大いに役立つでしょう。階層的な組織構造が平坦化され、より多くの人が直接的に開発プロセスに関わることができるようになります。これにより、情報の流れが改善され、より迅速で的確な意思決定が可能になります。最終的には、組織全体の俊敏性と創造性が向上するでしょう。

質問者：Devinの開発を通じて、AIのあり方やソフトウェア開発そのものについて根源的な問いに直面されたことはありますか？もしあれば、その問いへの向き合い方がDevinの設計や開発方針にどのような影響を与えたか教えてください。

Scott：素晴らしい質問です。私たちは最初から「ソフトウェアエンジニアリングの未来はどうあるべきか、将来どのようにコードを書くべきか」という核心的な問いを考えてきました。

私たちが始めた頃でさえ、能力が向上し続けるにつれて、物事はよりエージェント的になると強く感じていました。これが私たちが本当に興奮していたことです。

スタートアップでは、自分自身が世界で見るものを見て、自分自身の結論に到達する必要があります。時にはその結論は非常にクレイジーに聞こえることもありますが、しばしばクレイジーなことこそが時間とともに実現するものです。

この「あるべき姿」からの逆算的思考は、私たちの開発プロセスの中心にあります。まずソフトウェアエンジニアリングの理想的な未来像を描き、そこから現在の技術的制約やユーザーニーズの現実を考慮しながら、実現可能な開発計画へと「巻き戻し」ていきます。

私たちが始めたとき、エージェントは現在よりもはるかに劣っていましたが、それらが改善し続け、時間が経つにつれてより強力なユースケースになると強く感じていました。

実用的には、多くの実際の決断が常に行われています。今日、私たちは多くの時間をKubernetesやMongoDBなどに費やしています。しかし実際には、「この人は本当に優れたエンジニアだ」と言われるとき、それは彼らがどれだけ速くタイプするかではなく、彼らが問題解決に本当に優れているか、詳細をよく理解しているか、非常に一貫しているか、他の誰も思いつかない解決策を思いつくかなどです。これらがソフトウェアエンジニアリングの真髄（soul）です。

このエンジニアリングの「魂」の理解は、Devinの設計哲学に深く影響しています。私たちはDevinを単なるコード生成ツールとしてではなく、問題解決、詳細理解、一貫性、独創性といったエンジニアリングの本質的な価値を体現するエージェントとして開発しています。タイピングの速さや構文の知識といった表面的なスキルではなく、真の問題解決能力を持つAIエージェントの創造を目指しています。

実装が容易になると、他のすべてのことも失われるのではないかと心配する人がよくいますが、実際には実装だけに多くの時間を費やす必要がないため、他のすべてのことをより多く行うことができます。これは、AIの進化が人間の仕事を奪うのではなく、人間がより高い価値を生み出す活動に集中できるようにするという私たちの信念を反映しています。

8. AIツールの共存関係と技術的差別化

安野：AIコーディングの領域には様々な競合がいますね。例えばCursorやWindsurf、Cline、All Hands AIなどです。これらの競合をどう見ていますか？

Scott：実際、これらの企業の多くはベイエリアにもあるので、私たちはよく知っています。現在、市場には非常に少数の自律型エージェントしか存在していません。多くのAI IDEは素晴らしい製品ですが、非常に同期的です。

私たちは常にこの非同期的かつ自律的なエクスペリエンスに焦点を当ててきました。実際、人々がエージェントについて本当に話し始める前、エージェントが可能だと考えられる前から、このエクスペリエンスに取り組み、注力してきました。

現在、エージェントが多くの注目を集めるようになり、それを見るのは非常に素晴らしいことです。実際、私たちの製品体験は多くのツールと補完的です。Devinと他のAI IDEの両方を使用するチームを多く知っています。

例えば、GitHub Copilotを運営するマイクロソフトとは大きなパートナーシップを持っています。このパートナーシップにより、DevinとGitHub Copilotの統合が強化され、ユーザーは同期的なコード補完と非同期的な自律開発の両方の利点を享受できます。マイクロソフトのような大手テクノロジー企業とのこのような連携は、Devinのエコシステムを拡大し、より多くの開発者にリーチするのに役立っています。

安野：なぜDevinはこれほど優れた体験を他のどの企業よりも早く提供できたのでしょうか？

Scott：それはとても親切な質問です。ありがとうございます。実際には多くの細部があると思います。AIリサーチでは、しばしば単一のブレークスルーがそれを支えると想像されがちですが、実際に私たちが見てきたのは、200もの細部があり、それらすべてについて考える必要があるということです。

DevinがGitHubとどのように連携するか、コードベースをDevinが読むための適切な表現は何か、Devinがブラウザをうまく使用する方法、Devinがインタラクティブにデバッグする方法など、これらすべての詳細について考えます。これは単なるツールの問題ではなく、Devinにそれをさせるという意思決定の問題でもあります。

「200の細部」というこの製品開発哲学は、大きな革新的アイデアよりも、無数の小さな改善の積み重ねが本当の違いを生み出すという信念を反映しています。例えば、特定のフレームワークに対するDevinの理解を深めるための特別なトレーニング、エラーメッセージの解釈能力の向上、ユーザーフィードバックの効率的な処理方法など、細部にわたる改善の積み重ねがDevinの優位性を築いています。

多くの作業が非常に実践的なものであり、何が重要な能力かを決定し、それらの能力をDevinに取り入れる作業を行う必要があります。巨大なブレークスルーを思いつくことよりも、むしろ地道な改善の積み重ねが重要なのです。

安野：めちゃめちゃいいお話だったと思います。やはり一つの大きな隠れたアイデアではなく、細かいディテールの積み重ねによってこのDevinの良い体験が生まれてきたというのは非常に納得感があります。我々のプロダクトについても、細かい積み重ねが一番大事なんだなということを改めて思いました。

本日は貴重なお話をありがとうございました。Devinによってソフトウェアエンジニアの未来がどう変わっていくのか、Devinの使いこなし方、他社でどれくらいのコードがDevinによって生成されているかなど、多くの学びがありました。

Devinの良さが伝わったと思いますので、ぜひ皆さんもDevinを試してみてください。下のところにリファラルのコードが書いてありますので、それ経由だと20 ACUから100 ACU追加のクレジットをあなたももらえます。僕ももらえるのですが、あなたももらえますので、ぜひこちらのリファラルコードを使ってDevinを今すぐ契約いただけるといいんじゃないかと思います。それは将来のソフトウェアエンジニアリングを考える上で、相当にインパクトのある体験になるでしょう。

9. まとめ

Scott Wu氏との対談から浮かび上がるAIエンジニアリングの未来像は、単なる自動化の先にある人間とAIの新たな共創関係を示唆しています。Devinのような自律型AIエンジニアの登場は、ソフトウェア開発の歴史における大きな転換点となっています。

Devinの成功は、単一の革新的技術ではなく、「200の細部」と表現される緻密な技術的判断と改善の積み重ねによって実現されました。その技術的基盤には、VMを活用した安全な実行環境、複数のAIモデルの組み合わせ、そして無数の細部への配慮があります。この「細部へのこだわり」こそが、他社に先駆けて高品質な自律型AIエージェントを実現した鍵でした。

特筆すべきは、毎月数百のコミットを実環境のリポジトリに行うDevinの能力です。実際、日本を含む多くの企業では、コードの30〜40%をDevinが生成するケースも珍しくありません。このような自律性は、単なる生産性向上ツールを超え、ソフトウェア開発の在り方そのものを変革する可能性を秘めています。

Devinが導入した「10-80-10」というワークフローは、人間とAIの新しい協働モデルを示しています。人間が最初の10%でタスクを計画し、最後の10%でコードをレビューする一方、中間の80%をAIが自律的に実行するという考え方です。

このモデルは「人間の代替」ではなく「人間の拡張」を目指すもので、研究によれば、AIと人間のシンビオシス（共生）が最も高いパフォーマンスをもたらします。GitHubの調査では、コーディングアシスタントを使用する開発者のタスク完了時間が55%短縮され、Nielsen Norman Groupの研究では、AIコーディングアシスタントを使用したプログラマーの生産性が1週間で126%向上したという結果が報告されています。

Wu氏は今後数年で、AIを活用するエンジニアと活用しないエンジニアの間に5〜10倍もの生産性差が生じる可能性を指摘しています。しかし重要なのは、エンジニアリングの本質が「タイピングの速さ」ではなく「問題解決能力と論理的思考」にあるという認識です。

AIの進化により、エンジニアの役割は「コードを書く人」から「何を作るべきかを決める人」へとシフトしていきます。McKinseyの研究によれば、AIを活用する開発者は従来の方法を使用する開発者と比較して、タスクを最大2倍の速さで完了し、初回のテストケース成功率も高いことが示されています。

Devinのような自律型AIエージェントは、組織構造にも革命をもたらします。Wu氏が「地面に近くなれる」と表現するように、大規模組織でもマネージャーが現場の詳細に直接触れることが可能になります。AIが日常的な実装タスクを担当することで、エンジニアからCEOまで、より創造的で戦略的な思考に集中できるようになるのです。

AIの進化に伴い、新しい専門的な役割も登場しています：

• AIコラボレーター：AIが生成した出力の効率を高めることに特化したエンジニア
• プロンプトエンジニア：最大の効率を得るための最適なAI指示を作成する専門家
• AIエシックススペシャリスト：責任あるAI実装を確保する専門家

また、ソフトウェア開発の民主化も進んでいます。Gartnerの予測によれば、2027年までに企業で開発される新しいアプリケーションの70%がローコードまたはノーコード技術を使用するようになるとされています（2022年時点では25%未満）。これにより、非技術系のビジネスユーザーでも「市民開発者」としてアプリケーションを作成できるようになるでしょう。

最も有望なアプローチは、単独の自動化や置き換えではなく、人間とAIの「シンビオシス（共生）」にあります。この協調的なアプローチでは、AIと人間がそれぞれの強みを活かし、補完し合いながら、個々の能力を超えた成果を生み出すことができます。

AIと人間の関係性は、「ツールとユーザー」から「協働パートナーシップ」へと根本的に変化しています。この新たな関係性において、AIシステムが日常的な認知タスクを担当する一方、人間は高次の思考、創造性、倫理的判断に集中することができます。

Devinに代表される自律型AIエンジニアリングの進化は、私たちが想像する以上に速いペースで進んでいます。しかし、最終的に「何を構築すべきか」を決定するのは依然として人間の役割であり、AIはその実現を加速する強力なパートナーとなるでしょう。

Wu氏が語るように、技術の進化は時に「クレイジーに聞こえる」アイデアから始まります。私たちは今、そのようなアイデアが次々と現実になる時代の入り口に立っています。人間とAIが協力して未来を形作る、その旅はまだ始まったばかりです。

これからのエンジニアリングの新時代では、人間の創造性とAIの能力が融合すると予見される対談でした。