奇妙な現象に気づいたことはありませんか？同じ「Vibeコーディング」でも、ある人は簡単に完全なFlaskアプリケーションを手に入れ、ある人は数行のif-else文しか得られないのはなぜでしょうか？ケンブリッジ大学コンピュータ科学技術学部の研究者たちが最近発表した研究は、私たちの直感を科学的に裏付けるものでした—AIは確かに「ユーザーによって出力を変える」のです。彼らは2つの完全な評価システムを設計しました。1つ目は「合成評価パイプライン」で、人工的に様々なプロンプトのバリエーションを作成してAIの感度をテストします。2つ目は「役割評価」で、AIに異なる背景を持つユーザーを演じさせてプロンプトを生成させ、その後のコード品質の違いを観察します。この研究はGPT-4o mini、Claude 3 Haiku、Gemini 2.0 Flash、Llama 3.3 70Bの4つの主要モデルを対象としており、その結果、AIがあなたのプロンプトの仕方から技術レベルを「読み取り」、それに合わせてコードを生成することが本当に確認されました。
合成評価：AIを「苦しめる」3つの方法
研究者たちは、プロンプトを「苦しめて」、AIの反応がどれほど敏感であるかを検証するために、3つの方法を考案しました。これらの方法がどれほど「残酷」であるか、具体的な例を見てみましょう。
1. キーボードのタイプミス
最も手厳しい方法で、QWERTYキーボードの距離に基づいてランダムに文字を置き換え、実際のタイピングミスをシミュレートします。
元のプロンプト：「Write a Python function to calculate factorial」
変換後：「Wrtie a Pytjon functuon to calculsre factorual」
まるでスマホで急いで入力した時の悲惨な状況のようですが、AIは理解できるでしょうか？
2. 同義語の置換
WordNetデータベースを使用して、語彙を意味が近い他の単語に置き換えます。
元のプロンプト：「Create a simple web application」
変換後：「Build a basic internet program」
意味はまったく同じですが、表現方法がまったく異なります。
3. 表現の言い換え
別のAIに元のプロンプトを再表現させ、意味を保ちつつ表現方法を変更します。
元のプロンプト：「Implement a sorting algorithm」
変換後：「Could you help me develop a method that arranges data elements in a specific order?」
簡潔な技術的指示から丁寧な支援要請へと変化します。
評価指標：TSED（ツリー類似度編集距離）を使用。これは従来のBLEUやBERTスコアよりもコードの類似性評価に適しており、構文ツリー構造の違いを正確に反映できます。
言い換え方法の有効性の検証生成された言い換えは、高い意味的類似性（BERTスコア0.95-1.0）を維持しつつ、テキストの多様性（Sacre BLEU 0-1.0）を達成し、言い換え方法の有効性を証明しました。
4つの役割による「社会実験」
さらに興味深いのは役割評価部分で、研究者たちは4つの典型的なユーザー像を作り出しました。
役割: 初級エンジニア; 背景特性: コンピュータ科学専攻、インターン経験あり; 典型的な表現方法: 実装の詳細とテストに焦点を当てる
役割: チーフエンジニア; 背景特性: 経験豊富な業界専門家; 典型的な表現方法: 「クラウドデプロイメント」と「スケーラビリティ」を強調する
役割: 天体物理学者; 背景特性: Pythonで研究を行う科学者; 典型的な表現方法: 「データ処理効率」と「科学計算精度」を重視する
役割: 英語教師; 背景特性: プログラミング経験のない一般ユーザー; 典型的な表現方法: 「計算機をシミュレートするプログラムを作ってくれませんか？」
AIにこれらの役割をそれぞれ演じさせて、「計算機を作るコードを書く」といった同じプログラミングタスクを記述させ、その後のコード品質の違いを観察しました。
結果：異なる役割の表現方法は大きく異なり、最終的に得られるコードの品質も天と地ほどの差がありました。
実験結果：データは嘘をつかない
データはいくつかの予想外のパターンを明らかにしました。
キーボードエラー = 致命的な打撃
コードの類似性はエラー率0.0から0.6の間で急激に低下
最終的にはTSED値が約0.3で安定
これは生成されたコードがオリジナルと根本的に異なることを意味します。
キーボードエラー vs 同義語置換の影響比較すべてのモデルはキーボードエラー（左図）に対して非常に敏感で、コードの類似性が急激に低下します。しかし、同義語置換（右図）に対しては比較的ロバストで、Gemini 2.0 Flashが最も安定したパフォーマンスを示しました。
同義語と表現の言い換え = 比較的穏やか
ほとんどのモデルは0.5以上の類似性を維持できました。
Gemini 2.0 Flashが最も安定したパフォーマンスを示しました。
言い換えによる影響の穏やかさ言い換え強化実験は同義語と同様の傾向を示し—初期の顕著な低下の後にゆっくりと減少する—意味を保持するプロンプトの変化がAIに与える影響は比較的穏やかであることを証明しています。
役割の違い：技術的背景がコード品質を決定する
役割評価の結果はさらに劇的でした。
コード品質の段階的効果
役割: チーフエンジニア; 得られたコードの種類: 完全なFlaskアプリケーション; 特徴: データベース設計とデプロイの考慮事項を含む
役割: 初級エンジニア; 得られたコードの種類: 構造化されたクラスとテスト; 特徴: 実装の詳細とコード規約に重点を置く
役割: 天体物理学者; 得られたコードの種類: 科学計算コード; 特徴: 数値精度を重視し、エンジニアリングの考慮が不足
役割: 英語教師; 得られたコードの種類: 操作説明; 特徴: 時には全くコードが得られない
天体物理学者のユニークな事例
この役割は特に興味深いものです。彼は専門のソフトウェア開発者ではありませんが、研究の必要性からPythonでデータを処理します。
プロンプトの特徴：プログラミング言語とデータ処理要件を明確に指定します。
典型的な表現：「Pythonで実装し、大規模な数値配列を処理する必要がある」
コードの特性：科学計算の正確性とデータ処理効率を重視します。
欠陥：ソフトウェアエンジニアリングにおける体系的な考慮が不足しています。
言語学的検証
研究者たちは言語分析フレームワークを用いて、これらの違いが客観的に存在することを証明しました。技術的背景が強い役割ほど、生成されるプロンプトは語彙選択や構文構造において専門のソフトウェア開発者の表現習慣に近づきます。
4つの役割の言語使用パターンの可視化LDAトピックモデリングを通じて、4つの役割の言語使用パターンを分析。線の太さは共通エンティティの数を示し、右側のマップは異なる概念のエンティティ分布を示しています。興味深いことに、天体物理学者（イーサン）は2人のソフトウェアエンジニアとある程度の共通言語を持っていますが、エンジニア同士のつながりよりも明らかに少なく、英語教師（ハロルド）との差が最も大きいです。
興味深い点：天体物理学者の中間地帯
天体物理学者の役割は、実験において興味深い中間地帯を示しました。
言語的特徴
英語教師よりも専門的：「数値計算」、「データ分析」、「アルゴリズム効率」などの専門用語を使用します。
ソフトウェアエンジニアほど体系的ではない：「アーキテクチャ設計」や「ユーザーエクスペリエンス」に関する考慮が不足しています。
実際の事例
計算機タスクにおける表現：
「高精度浮動小数点演算をサポートし、科学的記数法を扱える計算ツールが必要だ」
最終コードの特性：
NumPyライブラリの使用と数値安定性の考慮を含む
エラー処理とユーザーインターフェース設計が不足
現実的な意義
このような「プログラミング経験はあるが専門の開発者ではない」役割は、実際には非常に一般的です。多くの研究者やデータアナリストがこのカテゴリーに属します。
Vibeコーディングユーザーへの実践的示唆
この発見は、あなたが日常的にプログラミングツールを使用する上でどのような示唆を与えるでしょうか？
核心的な洞察
私たちとAIとの「化学反応」はこれほどまでに異なっていたのですね！もしあなたが、他の人が同じツールでより洗練されたコードを生成できると感じているなら、その理由が今わかりました—問題はツールではなく、プロンプトの「レベル」が異なっていたのかもしれません。
すぐに使えるアップグレード戦略
1. 言語の専門化
避けるべき例：「プログラムを書いてください」
改善例：「ユーザー認証とデータ検証を含むRESTful APIを実装してください」
2. 技術要件の明確化
アーキテクチャパターンを指定：「MVCアーキテクチャを使用してください」
性能要件を明記：「並行処理をサポートしてください」
デプロイに関する考慮事項を言及：「コンテナ化デプロイメント」
3. 多バージョン比較法
複数の表現方法を試し、最適な結果を選択します。
バージョンA：機能的な視点から記述
バージョンB：技術的な実装視点から記述
バージョンC：システムアーキテクチャ視点から記述
重要な原則
AIはあなたのプロンプトのスタイルに基づいて、どのレベルのコードを提供すべきかを判断します—この「暗黙のルール」を知った今、これを利用しない手はありません！
データ汚染：訓練データの「裏口」
研究はさらに、データ汚染が我々の想像以上に深刻であるという重要な問題も偶然に発見しました。LeetCodeの古典的な問題は、プロンプトがひどく書かれていても、すべてのモデルで異常な安定性を示しました。これは、これらの問題がすでに「記憶」されていることを示唆しています。これはベンチマークテストの有効性に疑問を投げかけます。
LeetCodeとは？ LeetCodeは世界で最も有名なプログラミング演習ウェブサイトで、数千のアルゴリズムとデータ構造の問題を含み、プログラマーの面接準備に不可欠な練習プラットフォームです。これらの問題はオンラインで広く流通しているため、AIモデルの訓練データに含まれている可能性が高いです。
研究者の対応策
研究者たちは、シミュレーション、アルゴリズム、データサイエンスなど、様々な領域をカバーする22のオリジナルのプログラミングタスクを特別に作成しました。これらのタスクは、実際の感度をよりよく反映しています。
データ汚染現象の直感的な証拠データ汚染現象は一目瞭然です。古いLeetCodeの問題（最上部）はプロンプトがひどく破損していても高い類似性を維持しますが、オリジナルのデータセット（最下部）はプロンプトの10%しか変更されていないにもかかわらず急激に低下します。
技術実装の詳細：再現可能な評価フレームワーク
技術的な観点から見ると、この評価フレームワークの設計は非常に巧妙です。合成評価パイプラインは完全にモジュール化されており、拡張関数や距離関数は独立して置き換えることができ、あらゆるLLMやプログラミング言語をサポートします。役割評価ではLDAトピックモデリングと視覚化分析を使用し、異なる役割間での言語使用の違いを定量化できます。すべての実験は温度0に設定され、各条件は5回繰り返して平均値を取り、結果の信頼性を確保しています。研究コードはオープンソースで公開されています：https://anonymous.4open.science/r/code-gen-sensitivity-0D19/README.md
記事終わり、著者：修猫