Proofigとの新たな提携を発表!詳細はこちら
日々、AIによって書かれるコードが増え続けている。GoogleのCEOサンダー・ピチャイによれば、2024年末時点でGoogleのコードの25%以上がAIによって書かれているという。 ロビンフッドのCEOは、同社がリリースするコードの大半が現在AIによって書かれていると述べています。「バイブコーディング」(アンドレイ・カーパシーのツイートで広まった用語)という概念が一般用語として定着しつつあります。これは、コーディングの「感覚」に完全に身を任せ、AIに主導権を握らせてコードを書かせることを意味します。
Cursor、Lovable、Replitといったスタートアップは、コーディングへの参入障壁を取り除こうとしている。つまり、プログラミングを始めるのが非常に簡単になり、社内の誰もがPythonやReactの知識がなくてもコードを作成したり、本格的なウェブサイトやアプリを構築したりできるようになるのだ。
2025年StackOverflow開発者調査は、この傾向がいかに広範に浸透しているかを明らかにしている。開発者の84%が開発ワークフローでAIツールを使用中または使用予定であり、プロ開発者の51%が毎日AIツールを利用している。これは業界全体でコードが書かれる方法に大きな変化が起きていることを示している。
しかし、この調査はAI支援開発時代における成長の痛みを明らかにしている。開発者の52%がAIツールが生産性にプラスの影響を与えたと報告する一方で、AIツールに対する肯定的な評価は2025年に70%以上から60%に低下した。AI生成ツールとの初期の探索段階における蜜月期を経て、開発者は現在ではそれらに対してより中立的な見方をしているようだ。
不満の原因は示唆に富む:開発者の66%が「ほぼ正しいが完全ではないAIソリューション」に苛立ち、45%がAI生成コードのデバッグに予想以上の時間を要していると感じている。AIツールの出力を「非常に信頼している」開発者はわずか3%で、46%がAIツールの精度を積極的に疑っている。
これは興味深い逆説を生み出している:開発者はコード作成にAIをますます依存している一方で、その生成結果を完全に信頼していない。調査が指摘するように、開発者の75%は「AIの回答を信頼できない」場合に依然として人間に助けを求め、自らを「品質と正確性の最終的な判断者」と位置付けている。サイモン・ウィリソンによれば、彼は「出荷予定のプロジェクトでは、一行ずつ確認しない限りAI生成コードを使用しない」という。幻覚リスクに加え、チャットボットの「好意的に応答したい」という性質が、実際には使用不可能なアイデアを「機能する」と誤認させる恐れがある。これはコード編集技術を持たない開発者にとって特に深刻な問題だ。「組み込みの問題を抱えたソフトウェアを生み出すリスクがある」と彼は指摘する。
AI生成コードは今後も存在し続けるが、コードが人間によって書かれたものであることを確認することが依然として意味を持つ場面は確かに存在する。
採用プロセスにおいて、ソフトウェア開発者を採用する際には、プログラマーがAIの支援なしに高品質なコードを完全に記述できる能力を有しているかどうかを評価することが重要です。さらに、業務においてAI生成またはAI支援による欠陥のあるコードを効果的にデバッグ・診断できるよう、コードに対する理解度を評価することも同様に重要です。
教育においては、AIの支援なしにプログラミングを教えることが重要です。 AI支援に依存しすぎると、学生は基礎概念を見逃し、成功するソフトウェアエンジニアに必要なスキル習得を回避してしまう。StackOverflow開発者調査が示唆するように、これらの学生は就職後もAI支援を利用できる可能性が高いが、確固たる基礎がなければ、AIが生成した誤ったコードを修正できず、そもそも何が間違っているのかさえ理解できないだろう。
コンプライアンスとセキュリティ。多くのコンプライアンス枠組みでは、AI生成コードは幻覚やバグの可能性があるため、より高いリスクとみなされています。重要なライセンスと著作権の考慮事項もあります——AIモデルは意図せず互換性のないライセンスのコードを複製し、コンプライアンス違反を引き起こす可能性があります。さらに、AI生成コードが専有物と見なせるか、著作権の対象となり得るかについては未解決の問題が残されています。
コードの由来と追跡。AI導入前は、git blameのようなツールで各コード行の作者や変更理由を容易に追跡できた。AIが大量のコードを生成する現在、開発者が各行の背景や意図を記憶することは困難になっている。 AI生成コードを検知・追跡できることは、コードの保守、デバッグ、リソース管理に役立ちます。CTOやエンジニアリングリーダーはこの情報を活用し、様々なAIモデルの有効性を評価し、チームが最適なツールを使用していることを確認できます。
全体として、PangramはAI生成コードの大半を保守的に検出できる。特にコードが40行を超える場合にその傾向が強い。Pangramが保守的である理由は、人間が書いたコードをAI生成と誤判定することは稀だが、AI生成コードの約8%を見逃し、人間が書いたものと誤って予測するためである。
すべてのコードスニペットを分析する際、パングラムはAI生成コードの約20%を検出できません。これは、短いAIコードスニペットの大半が人間のコードと区別がつかない定型文であるか、あるいは検出に十分な特徴を持たないためです。
| メートル法 | スコア |
|---|---|
| 精度 | 96.2% (22,128/22,997) |
| 偽陽性率 | 0.3% (39/13,178) |
| 偽陰性率 | 8.5% (830/9,819) |
| メートル法 | スコア |
|---|---|
| 精度 | 89.4% (41,395/46,319) |
| 偽陽性率 | 0.4% (99/25,652) |
| 偽陰性率 | 23.3% (4,825/20,667) |
この分析にはGitHubデータセットを使用します。AIコードについては、単純な二段階の合成ミラーリング段階を採用します:
データセットの作成には、GPT-4o、Claude Sonnet、Llama 405b、Mistral 7B、Gemini 1.5 Flash、Gemini 1.5 Proを使用しています。
AI生成コードはAI生成文章よりも検出が困難である。なぜなら自由度が著しく低いからだ:プログラマーが選択する恣意的な文体上の選択肢は、作家に比べて少ない。 私たちが観察した偽陰性事例では、多くのファイルが創造性や柔軟性の余地をほとんど持たないことが確認されています。例えば定型的な自動生成コードや設定ファイルなどが該当します。C言語やアセンブリ言語、コンパイラコードといった低レベル言語も構文が非常に厳格であるため、コードがAI生成であるかどうかを判断できる手がかりが少なくなります。
AI生成コードの兆候を探している場合、以下の方法をお勧めします: