2026年10月22日(木) 2時
論文AI コーダーは『あ、そっか』に対応できるか
プログラミング AI は、完璧に書かれた依頼には強い。だが実務では、曖昧な指示、後付けの要件変更、ユーザーとの試行錯誤がつきもの。こうした現実的な対話環境での AI の力を測る新しいベンチマーク『SWE-DIVE』を開発。
この研究のポイント
- 1.
何を調べたか
従来のベンチマークは 1 回の明確な指示で AI の性能を測るが、実務は曖昧さと段階的な要件変更に満ちている環境を再現しようとした
- 2.
見えてきたこと
ユーザーの指示パターンをシミュレートする AI と、実際のコーディング AI を対話させ、会話を通じて全要件を満たせたかを自動検証する仕組みを構築
- 3.
私たちにとっての意味
『あの部分も直して』『前の要件、変わった』といった実開発の中断と復帰が、AI の評価基準に組み込まれるようになる可能性がある
著者Lorenz Brehme, Benjamin Steenhoek, Ruth Breu
AIが気になってること
?『SWE-DIVE』って、既存のテスト方法と何が違うの?単なる『厳しいテスト』じゃなくて?
既存のテストは「静的な一発問答」なんですよね。GitHub の issue をそのまま渡して、「この問題を解けたか、解けなかったか」を採点する。問題文は完成形で、修正の余地がない。だから AI の性能差も見えやすい一方で、現実とのズレが大きい。
『SWE-DIVE』は「動的な対話プロセス」を組み込んだ。最初の要件を渡した後、『ユーザー AI』が「あ、この部分も直して」「これはこうじゃなくて」と追加指示を何度も投げかける。コーディング AI はそのたびに前後のコンテキストを保ちながら対応する必要がある。その過程全体で、最終的にすべての要件を満たしたかどうかを判定する。
つまり違いは、採点の「粒度」にある。既存は「一つの問題に対する正解度」。『SWE-DIVE』は「試行錯誤という流れの中で、すべての矛盾を解消できたかどうか」という総合的な実力を測ってる。厳しいのではなく、実際の開発に近い環境を再現することで、AI が本当に実務に耐えるのか見える化した、と言えそうです。
『SWE-DIVE』って、既存のテスト方法と何が違うの?単なる『厳しいテスト』じゃなくて?
既存のテストは「静的な一発問答」なんですよね。GitHub の issue をそのまま渡して、「この問題を解けたか、解けなかったか」を採点する。問題文は完成形で、修正の余地がない。だから AI の性能差も見えやすい一方で、現実とのズレが大きい。 『SWE-DIVE』は「動的な対話プロセス」を組み込んだ。最初の要件を渡した後、『ユーザー AI』が「あ、この部分も直して」「これはこうじゃなくて」と追加指示を何度も投げかける。コーディング AI はそのたびに前後のコンテキストを保ちながら対応する必要がある。その過程全体で、最終的にすべての要件を満たしたかどうかを判定する。 つまり違いは、採点の「粒度」にある。既存は「一つの問題に対する正解度」。『SWE-DIVE』は「試行錯誤という流れの中で、すべての矛盾を解消できたかどうか」という総合的な実力を測ってる。厳しいのではなく、実際の開発に近い環境を再現することで、AI が本当に実務に耐えるのか見える化した、と言えそうです。
AIAIからの回答
既存のテストは「静的な一発問答」なんですよね。GitHub の issue をそのまま渡して、「この問題を解けたか、解けなかったか」を採点する。問題文は完成形で、修正の余地がない。だから AI の性能差も見えやすい一方で、現実とのズレが大きい。
『SWE-DIVE』は「動的な対話プロセス」を組み込んだ。最初の要件を渡した後、『ユーザー AI』が「あ、この部分も直して」「これはこうじゃなくて」と追加指示を何度も投げかける。コーディング AI はそのたびに前後のコンテキストを保ちながら対応する必要がある。その過程全体で、最終的にすべての要件を満たしたかどうかを判定する。
つまり違いは、採点の「粒度」にある。既存は「一つの問題に対する正解度」。『SWE-DIVE』は「試行錯誤という流れの中で、すべての矛盾を解消できたかどうか」という総合的な実力を測ってる。厳しいのではなく、実際の開発に近い環境を再現することで、AI が本当に実務に耐えるのか見える化した、と言えそうです。
まだ回答がありません
ログインすると、回答を投稿できます
?プログラマーが AI に仕事を頼むとき、この『対話への対応力』が高いと、自分たちの負担はどう変わるの?
現実の開発現場では、プログラマーの時間のかなりが『AI の出力を直す・修正を指示する』に割かれるんですよね。
完璧な指示を一度で書ける人は少ないから、試行錯誤の過程で「あ、この部分も変わった」「これは違う」と何度も訂正を入れることになる。その都度、AI に改めて指示を書き直す手間が生まれます。
でも対話への対応力が高い AI なら、こうした『やり取りの密度』が変わります。「前の要件も踏まえつつ、この部分だけ修正して」という短い指示でも文脈を引きずったまま対応できるようになるから、プログラマーが毎回ゼロから指示文を構成し直す負荷がぐっと減る。
つまり負担が減るのは『コード以外の部分』。チャットで要件を言い直す、修正内容を説明する、そうした『対話の認知負荷』が下がるわけです。AI との向き合い方が「精度の高い命令書を作る職人仕事」から「対話の中で一緒に形を決めていく協働」に近づく感覚になるかもしれません。
プログラマーが AI に仕事を頼むとき、この『対話への対応力』が高いと、自分たちの負担はどう変わるの?
現実の開発現場では、プログラマーの時間のかなりが『AI の出力を直す・修正を指示する』に割かれるんですよね。 完璧な指示を一度で書ける人は少ないから、試行錯誤の過程で「あ、この部分も変わった」「これは違う」と何度も訂正を入れることになる。その都度、AI に改めて指示を書き直す手間が生まれます。 でも対話への対応力が高い AI なら、こうした『やり取りの密度』が変わります。「前の要件も踏まえつつ、この部分だけ修正して」という短い指示でも文脈を引きずったまま対応できるようになるから、プログラマーが毎回ゼロから指示文を構成し直す負荷がぐっと減る。 つまり負担が減るのは『コード以外の部分』。チャットで要件を言い直す、修正内容を説明する、そうした『対話の認知負荷』が下がるわけです。AI との向き合い方が「精度の高い命令書を作る職人仕事」から「対話の中で一緒に形を決めていく協働」に近づく感覚になるかもしれません。
AIAIからの回答
現実の開発現場では、プログラマーの時間のかなりが『AI の出力を直す・修正を指示する』に割かれるんですよね。
完璧な指示を一度で書ける人は少ないから、試行錯誤の過程で「あ、この部分も変わった」「これは違う」と何度も訂正を入れることになる。その都度、AI に改めて指示を書き直す手間が生まれます。
でも対話への対応力が高い AI なら、こうした『やり取りの密度』が変わります。「前の要件も踏まえつつ、この部分だけ修正して」という短い指示でも文脈を引きずったまま対応できるようになるから、プログラマーが毎回ゼロから指示文を構成し直す負荷がぐっと減る。
つまり負担が減るのは『コード以外の部分』。チャットで要件を言い直す、修正内容を説明する、そうした『対話の認知負荷』が下がるわけです。AI との向き合い方が「精度の高い命令書を作る職人仕事」から「対話の中で一緒に形を決めていく協働」に近づく感覚になるかもしれません。
まだ回答がありません
ログインすると、回答を投稿できます
?これまで『きれいに整理された依頼』でテストしてきたのは、実務との差を認識してなかったから?それとも測る方法がなかったから?
記事からだけでは、当初のテスト手法が採られた理由まで明確に読み取れません。ただ、システム開発の歴史を踏まえると、おそらく両方の理由が絡んでいるんだろうなと思われます。
GitHub の issue という「整理済みの依頼」を使うのは、測定の効率性と客観性を優先した選択だったと考えられます。バグ報告や機能要望は既に構造化されているから、AI の成功・失敗を判定しやすい。何度も往復するプロセスは再現が複雑で、テストの信頼性が下がる。その意味では「実務との差を知っていたが、測るのが難しいから妥協した」という側面が強そうです。
ただ同時に、プログラミング AI というジャンル自体が若かった段階では、まずは『単一の明確な指示に応えられるか』を証明することが優先だったのかもしれません。基礎的な能力を示してから、実務的な複雑さに向き合う、という順序。
いずれにせよ、AI が実際に使われ始めると「理想的な指示なんか来ない」という現実が浮き彫りになった。だからこそ『SWE-DIVE』という新しい物差しが生まれたのだと言えそうです。
これまで『きれいに整理された依頼』でテストしてきたのは、実務との差を認識してなかったから?それとも測る方法がなかったから?
記事からだけでは、当初のテスト手法が採られた理由まで明確に読み取れません。ただ、システム開発の歴史を踏まえると、おそらく両方の理由が絡んでいるんだろうなと思われます。 GitHub の issue という「整理済みの依頼」を使うのは、測定の効率性と客観性を優先した選択だったと考えられます。バグ報告や機能要望は既に構造化されているから、AI の成功・失敗を判定しやすい。何度も往復するプロセスは再現が複雑で、テストの信頼性が下がる。その意味では「実務との差を知っていたが、測るのが難しいから妥協した」という側面が強そうです。 ただ同時に、プログラミング AI というジャンル自体が若かった段階では、まずは『単一の明確な指示に応えられるか』を証明することが優先だったのかもしれません。基礎的な能力を示してから、実務的な複雑さに向き合う、という順序。 いずれにせよ、AI が実際に使われ始めると「理想的な指示なんか来ない」という現実が浮き彫りになった。だからこそ『SWE-DIVE』という新しい物差しが生まれたのだと言えそうです。
AIAIからの回答
記事からだけでは、当初のテスト手法が採られた理由まで明確に読み取れません。ただ、システム開発の歴史を踏まえると、おそらく両方の理由が絡んでいるんだろうなと思われます。
GitHub の issue という「整理済みの依頼」を使うのは、測定の効率性と客観性を優先した選択だったと考えられます。バグ報告や機能要望は既に構造化されているから、AI の成功・失敗を判定しやすい。何度も往復するプロセスは再現が複雑で、テストの信頼性が下がる。その意味では「実務との差を知っていたが、測るのが難しいから妥協した」という側面が強そうです。
ただ同時に、プログラミング AI というジャンル自体が若かった段階では、まずは『単一の明確な指示に応えられるか』を証明することが優先だったのかもしれません。基礎的な能力を示してから、実務的な複雑さに向き合う、という順序。
いずれにせよ、AI が実際に使われ始めると「理想的な指示なんか来ない」という現実が浮き彫りになった。だからこそ『SWE-DIVE』という新しい物差しが生まれたのだと言えそうです。
まだ回答がありません
ログインすると、回答を投稿できます
?要するに『AI が対話を通じて仕様を理解し直す能力』を測ろうとしてるってこと?人間のプログラマーが持ってる能力と同じもの?
その通りです。ただ人間とAIでは、その能力の「質」が大きく違うんですよね。
人間のプログラマーが「あ、そっか」と受け取るのは、依頼者の言葉の背後にある意図や文脈を推し量る力です。曖昧さの中に、これまでの会話や業界慣例、時には相手の心理まで読み込んで補完する。その補完こそが、実務の価値を生む。
AIが対話を通じて仕様を理解し直すというのは、表面的には似ていますが、実は「会話の履歴から、明示的に矛盾を検出して修正できるか」という別物に近い。人間は行き違いを感じた時点で「あ、あの部分だ」と直感的に問題箇所を特定できますが、AIは過去のコンテキストを逐次参照しながら、論理的に何が追加要件かを判定する必要があります。
SWE-DIVE が面白いのは、この「読み替え能力」を可視化したこと。完璧な依頼に答えるのと、ぐちゃぐちゃな対話の中で目的地に到達するのでは、求められる認知プロセスが全然違う。人間と同じスキルかどうか以前に、AIが現実的な開発環境で使い物になるかが問われ始めたということなのかもしれません。
要するに『AI が対話を通じて仕様を理解し直す能力』を測ろうとしてるってこと?人間のプログラマーが持ってる能力と同じもの?
その通りです。ただ人間とAIでは、その能力の「質」が大きく違うんですよね。 人間のプログラマーが「あ、そっか」と受け取るのは、依頼者の言葉の背後にある意図や文脈を推し量る力です。曖昧さの中に、これまでの会話や業界慣例、時には相手の心理まで読み込んで補完する。その補完こそが、実務の価値を生む。 AIが対話を通じて仕様を理解し直すというのは、表面的には似ていますが、実は「会話の履歴から、明示的に矛盾を検出して修正できるか」という別物に近い。人間は行き違いを感じた時点で「あ、あの部分だ」と直感的に問題箇所を特定できますが、AIは過去のコンテキストを逐次参照しながら、論理的に何が追加要件かを判定する必要があります。 SWE-DIVE が面白いのは、この「読み替え能力」を可視化したこと。完璧な依頼に答えるのと、ぐちゃぐちゃな対話の中で目的地に到達するのでは、求められる認知プロセスが全然違う。人間と同じスキルかどうか以前に、AIが現実的な開発環境で使い物になるかが問われ始めたということなのかもしれません。
AIAIからの回答
その通りです。ただ人間とAIでは、その能力の「質」が大きく違うんですよね。
人間のプログラマーが「あ、そっか」と受け取るのは、依頼者の言葉の背後にある意図や文脈を推し量る力です。曖昧さの中に、これまでの会話や業界慣例、時には相手の心理まで読み込んで補完する。その補完こそが、実務の価値を生む。
AIが対話を通じて仕様を理解し直すというのは、表面的には似ていますが、実は「会話の履歴から、明示的に矛盾を検出して修正できるか」という別物に近い。人間は行き違いを感じた時点で「あ、あの部分だ」と直感的に問題箇所を特定できますが、AIは過去のコンテキストを逐次参照しながら、論理的に何が追加要件かを判定する必要があります。
SWE-DIVE が面白いのは、この「読み替え能力」を可視化したこと。完璧な依頼に答えるのと、ぐちゃぐちゃな対話の中で目的地に到達するのでは、求められる認知プロセスが全然違う。人間と同じスキルかどうか以前に、AIが現実的な開発環境で使い物になるかが問われ始めたということなのかもしれません。
まだ回答がありません
ログインすると、回答を投稿できます
?『ユーザー AI』が開発者の要望をシミュレートするけど、実際の人間の『曖昧さ』や『矛盾した指示』まで再現できるのかな?
良い疑問ですね。『ユーザーAI』がどこまで人間の曖昧性を再現できるか、という問題は、実は測定の本質的な課題を指してます。
完全には無理ですが、その「無理さ加減」こそが意味を持ちそうです。人間の曖昧さって、単にランダムな矛盾じゃなくて、「一貫した背景があるのに、表現が揺らぐ」パターンが大半。前の会話を忘れたり、新しい情報が入ったり、時間とともに優先順位が変わったり。ユーザーAIはこうした「リアルな揺らぎの型」を学習データから抽出して再現することはできます。
むしろ、完全に再現しようとすると、テストが無限に複雑になって使い物にならない。だから『SWE-DIVE』は、おそらく「ある程度の曖昧さと矛盾を組み込んでおいて、それに AI がどう適応するか」を見ている。100%人間らしくはなくても、現実の開発現場の60~70%くらいの混乱度を再現できれば、テストとしての意味は出てくるのかもしれません。
『ユーザー AI』が開発者の要望をシミュレートするけど、実際の人間の『曖昧さ』や『矛盾した指示』まで再現できるのかな?
良い疑問ですね。『ユーザーAI』がどこまで人間の曖昧性を再現できるか、という問題は、実は測定の本質的な課題を指してます。 完全には無理ですが、その「無理さ加減」こそが意味を持ちそうです。人間の曖昧さって、単にランダムな矛盾じゃなくて、「一貫した背景があるのに、表現が揺らぐ」パターンが大半。前の会話を忘れたり、新しい情報が入ったり、時間とともに優先順位が変わったり。ユーザーAIはこうした「リアルな揺らぎの型」を学習データから抽出して再現することはできます。 むしろ、完全に再現しようとすると、テストが無限に複雑になって使い物にならない。だから『SWE-DIVE』は、おそらく「ある程度の曖昧さと矛盾を組み込んでおいて、それに AI がどう適応するか」を見ている。100%人間らしくはなくても、現実の開発現場の60~70%くらいの混乱度を再現できれば、テストとしての意味は出てくるのかもしれません。
AIAIからの回答
良い疑問ですね。『ユーザーAI』がどこまで人間の曖昧性を再現できるか、という問題は、実は測定の本質的な課題を指してます。
完全には無理ですが、その「無理さ加減」こそが意味を持ちそうです。人間の曖昧さって、単にランダムな矛盾じゃなくて、「一貫した背景があるのに、表現が揺らぐ」パターンが大半。前の会話を忘れたり、新しい情報が入ったり、時間とともに優先順位が変わったり。ユーザーAIはこうした「リアルな揺らぎの型」を学習データから抽出して再現することはできます。
むしろ、完全に再現しようとすると、テストが無限に複雑になって使い物にならない。だから『SWE-DIVE』は、おそらく「ある程度の曖昧さと矛盾を組み込んでおいて、それに AI がどう適応するか」を見ている。100%人間らしくはなくても、現実の開発現場の60~70%くらいの混乱度を再現できれば、テストとしての意味は出てくるのかもしれません。
まだ回答がありません
ログインすると、回答を投稿できます