AIが書いたコードが「動く」ことと「使える」ことは別の話
ChatGPTやClaudeに「このCSVを集計して」と依頼すると、見た目のきれいなpandasコードが数秒で返ってくる。試しに動かすと、確かに動く。問題はそこから先だ。
実務データに当てた瞬間、「やたら遅い・メモリが膨らむ・結果がなぜか合わない」という事態が起きる。エラーが出るわけでもないので気づきにくい。これが「静かな地雷」と呼ばれる所以だ。
Zennに投稿されたエンジニアの記事が、このテーマを丁寧に整理していたので紹介したい。
3つの地雷：何が起きているのか
記事では、AI生成pandasコードに混入しやすい問題を3種類に分類している。
① iterrows / apply による行ループ
AIは「やりたいこと」を素直にコードに翻訳するため、ベクトル化APIが存在する場面でも iterrows を返すことがある。100万行のデータで計測すると、apply は数秒かかる一方、後述する numpy.select を使ったベクトル化では数十ミリ秒オーダーで完了する。10万行を超えると「体感で数十倍の差」と記事は表現している。
② dtypeの暗黙変換
read_csv 直後にNaNが1つでも混入すると、整数IDが float64 に変換される。AIはこの挙動を踏まえずに後段で == 比較やJSON書き出しを行うため、「IDが小数になっている」「JOINキーが一致しない」といった事故が起きる。データを見ないと気づけない類の問題だ。
③ merge時の重複爆発
how="left" で左テーブルの結合キーに対して右テーブルに複数行が存在すると、左の行が複製されて行数が想定の数倍に膨らむ。AIは「とりあえずmergeした」コードを返すため、結合前後の行数をチェックするアサートを仕込んでいないと検知できない。
具体的な対処法：ベクトル化とsafe_merge
記事では2つの実装パターンが紹介されている。
numpy.selectへの書き換え
条件分岐を含む apply ループは、numpy.select でベクトル化できる。たとえば、スコアに応じてS/A/B/Cのグレードを付与する処理なら、条件リストと選択肢リストを渡すだけで100万行を数十ミリ秒で処理できる。AIが apply を返してきたら、まず条件分岐をベクトル演算に展開できないか確認するのが基本方針だ。
safe_mergeヘルパー
結合前後の整合性を担保するためのヘルパー関数の実装例も示されている。右側テーブルのキー重複を事前検出してエラーを投げる処理と、左右のキー列の dtype 不一致を検知する処理を組み合わせたものだ。「結合の前後で必ず確認する」処理をテンプレート化することで、AI生成コードの静かな事故を発火点で止める思想に基づいている。
ここからは見方の話：この問題が示す構造的な課題
この記事が取り上げている問題は、実は「AIの精度」の話ではない。AIが生成するコードの検証コストをだれが・どこで・どう負担するか、という構造的な問いだ。
AIコーディング支援が普及するにつれて、コードを書くコストは下がった。しかし、生成されたコードが実務データで正しく動くかを検証するコストは下がっていない。むしろ、「動くように見えるコードが増える」分、見落としのリスクは上がっている面もある。
iterrowsの問題にしても、dtypeの問題にしても、小規模なサンプルデータで動かしている分には顕在化しない。本番データの規模や汚れ具合が初めて踏み台になる。これはAIの問題というより、「動作確認」と「実務検証」を混同しているワークフローの問題だと見たほうが正確だ。
AI生成コードを使うかどうかではなく、AI生成コードを前提とした検証レイヤーを設計に組み込むかどうか——そこが今の現場の分岐点になっている。
実務的な示唆：何をどの順番で疑うか
AI生成のpandasコードをレビューするとき、個人的には以下の順で疑うのが効率的だと思っている。
- 行ループ系のコードがないか（
iterrows、applyを含む関数定義） - mergeの直後に行数アサートがあるか（ない場合は重複爆発の可能性）
- 結合キーのdtypeが揃っているか（特にCSV読み込み直後のID列）
この3点をチェックリスト化してコードレビューに組み込むだけで、AI生成コードの地雷踏み率はかなり下がる。safe_merge のようなユーティリティ関数を共通ライブラリに置いておく発想も、チームで使うなら現実的な対策だ。
「AI活用で開発速度を上げる」と「品質基準を下げない」は両立できる。ただしそのためには、速度向上の恩恵を受ける部分と、検証の手を抜かない部分を意識的に分けておく必要がある。曖昧にしたまま進めると、後者が前者に飲み込まれていく。
