本文へスキップ
AI-Papers

CognitionがDevinにGPT-6 Astraを統合、AIが自らテストして動作を証明

CognitionがDevinにGPT-6 Astraを統合、AIが自らテストして動作を証明
  • Cognitionが自律型ソフトウェアエンジニアDevinにGPT-6 Astraを組み込み、生成したコードを自らテストして結果を提示する運用を進めている
  • iPhoneゲームOtter Runの検証では、シミュレータ上の動作録画と、合格した項目や未検証の範囲を示すレポートを出力する
  • Cognitionは共同創業者Walden Yan氏の言葉として、人手でコードを読む量を減らしながら出荷量を増やせるとの見通しを示している

Devinが自らテストする

OpenAIは、Devinを開発するCognitionがGPT-6 Astraを製品全体に適用し、Devin自身が書いたコードをテストして結果を示す仕組みを構築していると公開しました。Devinは銀行のような大企業からスタートアップまで幅広く使われている自律型のソフトウェアエンジニアで、指示を受けて調査から実装、修正までを担います。

Cognitionが課題としていたのは、エージェントが書くコードの量が増えるほど、それを人間が確認する作業が追いつかなくなる点でした。共同創業者のWalden Yan氏は「Astraが大きく改善した点の1つは、自分の作業が期待どおりに動くことをテストし、証明する能力だ」と述べています。

つまり焦点は、コードを速く書くことではなく、書いたコードが動くという根拠を人間に渡すことに移っています。レビューの対象がコードの行そのものから、実行結果という成果物へと置き換わる構図です。

図1: Devinが自らテストし証拠を返すレビューの流れ
図1: Devinが自らテストし証拠を返すレビューの流れ

図1のように、実装からテスト、証拠の提示、人間のレビューまでが1つのループとして回ります。未検証の箇所が残った場合は、その情報がそのまま次の作業の入口になります。

ゲームを実機環境で検証

公開された例では、DevinがAstraを使ってiPhoneゲーム「Otter Run」をテストしています。出力されるのはシミュレータでゲームが動いている録画と、どの確認項目が通ったのか、どの範囲が未検証のまま残っているのかを記したレポートです。

録画はアプリの挙動そのものを示し、レポートはテストがカバーした範囲を文書化します。エンジニアはこの2つを突き合わせることで、ソフトウェアがどう動いているのかを確かめ、まだ手当てが必要な部分を把握できます。

サポート対応にも同じ発想が使われています。顧客から不具合のスクリーンショットが届いた際、それをAstra経由でDevinに渡すと、修正した上で結果を示すスクリーンショットが返ってくるため、Yan氏は顧客への返答が「かなり速くなった」と説明しています。

レビュー負荷という壁

AIコーディングエージェントの普及で繰り返し指摘されてきたのは、生成量が増えるほど人間のレビューが詰まるという点でした。エージェントが1日に何十件も変更を出しても、それを読んで判断できる人数は増えません。結果として、レビュー待ちの列が開発速度の上限を決めてしまいます。

Cognitionが狙っているのは、この上限をずらすことです。Devinがテストを書いて実行し、通った項目と通らなかった項目を提示できれば、エンジニアは差分を1行ずつ追うのではなく、検証結果の妥当性を見る形にレビューを移行できます。Yan氏は「時間の経過とともに、手作業で見るコードは減り、出荷量は増えると見込んでいる」と述べています。

ただし、この方式が機能するかどうかはテストの質に依存します。エージェントが自分に都合のよいテストだけを書けば、証拠は形だけのものになります。未検証の範囲を明示するレポートが出力に含まれているのは、その穴を人間が見つけられるようにするための設計と読めます。

適用範囲は製品全体へ

CognitionはGPT-6 Astraを単一の機能ではなく、製品ラインアップ全体に適用しています。Yan氏が挙げた対象は次のとおりです。

  • Devinの中核となるクラウド上のエージェント
  • コマンドラインから使うCLI製品
  • デスクトップ向け製品

OpenAIはGPT-6 Astraを金融領域などでも展開しており、OpenAIが金融特化ChatGPTを発表、GPT-6 Astraと金融データを統合でも触れたように、専門的な業務での検証能力が押し出されています。ソフトウェア開発では、その検証能力が「動作の証拠を残す」という形で現れたことになります。

開発現場への示唆

今回の発表には、レビュー時間の削減率のような数値は示されていません。示されているのは、テストと証拠の提示をエージェント側に寄せるという方向性と、それが実際の製品とサポート業務で動いているという事実です。

エージェントに開発を任せる範囲を広げたい組織にとって、判断の分かれ目は生成の精度よりも検証の扱いになりつつあります。どのような証拠があればレビューを省略できるのかを社内で定義しておくことが、こうした仕組みを取り入れる前提になるでしょう。

シェア:

投稿には GitHub アカウントが必要です。投稿内容は公開され、利用規約に反するものは予告なく削除します。