データサイエンティストのワークフローにおけるAI活用：自動化すべき作業と絶対に任せてはならない作業

Copilotに初めてカラム名を幻覚されたとき、モデルはそのまま学習を続けました。Pull requestはcustomer_idを、右側のテーブルに存在しないcustomer_uuidというカラムに結合しようとしていました。Pandasはお馴染みの振る舞いをしました。すべての行にNaNをサイレントに生成し、エラーも出さず、結合は「成功」しました。下流のモデルも問題なくフィットしました。検証用のAUCも正常に見えました。私が気づいたのは3日後、特定のコホートが出力から消えた理由をステークホルダーに尋ねられてからでした。

この失敗パターンについて警告してくれる人は誰もいません。AI支援型データサイエンスのマーケティングは、モデルがクリーンなサンプルデータに対して完璧なpd.mergeを書くデモで溢れています。実際の失敗パターンはサイレントです。コードは動き、結果は妥当に見え、バグはチャートを発表した後に浮かび上がります。

そこで、これらのツールを毎日約18ヶ月使い続けた後に私が引いたラインを、誇大広告にも反射的な拒否にも疲れた現役データサイエンティスト向けに書きます。どちらの極端も間違いです。モデル品質を落とさずに速く出荷できる中間地点があります。このガイドはそれを具体的に説明しようとするものです。

なぜ今これが重要なのか（そして「データサイエンスにおけるAI」コンテンツの多くが混乱している理由）

「データサイエンスにおけるAI」と言うとき、人々が意味する全く異なる2つのことがあり、それを混同すると支離滅裂なアドバイスが生まれます。

1つ目はワークフロー加速ツールとしてのAIです。既存のデータサイエンスの仕事のための、定型コード、EDAスクリプト、docstring、スライド草稿など。これがIDEのCopilot、Cursor、Claudeのやることです。仕事はモデルを構築して説明すること。AIはより速いタイプライターです。

2つ目はLLMを活用したアプリケーションの構築です。RAGシステム、エージェントパイプライン、生成出力の評価ハーネスなど。これは別の仕事です。スキルは重なります（統計は依然として必要ですし、評価についても考える必要があります）が、失敗パターン、ツールチェーン、日々の作業はXGBoostモデルの学習とは異なります。

リーダーシップが「ワークフローにAIを追加して」と言う場合、通常は1つ目を意味します。「AIフィーチャーを構築して」と言う場合は通常2つ目です。この2つを分けないと、解約予測の問題にRAGパターンを適用して四半期を無駄にするか、XGBoostの直感でチャットボットをリリースしてevalがなぜ機能しないか悩むことになります。

このガイドの残りは主に1つ目についてです。2つ目に関するセクションも後半にあります。

AIが本当に役立つ場面（毎日使う）

AIに毎日ファーストドラフトを書かせ、軽くレビューする場面を挙げます。

定型コード。 Pandasのリシェイプ（pivot、melt、groupbyチェーン）は何百回も書いてきたもの。SklearnのPipelineとColumnTransformerのスキャフォールディング。Matplotlibのサブプロットグリッド。構造が固定されていてカラム名だけが変わる機械的な作業。CursorかCopilotは90%の確率で正しく書きます。残りの10%の間違いも、出力がどう見えるべきか分かっているので素早く発見できます。

EDAスクリプト。 最初の分布プロット、null数、相関ヒートマップ、カテゴリカル変数のvalue counts。「このデータセットの形を把握する」ためのパス。AIはパターンが定型的で出力が視覚的なため、何か変なものがあればすぐ気づけます。第2パスのEDAは自分で書きます。本当の思考が起きるのはそこだからです。

Docstringと型ヒント。 関数が何をするか分かっていて、ドキュメント化するだけのとき。関数をハイライトして「numpyスタイルのdocstringを例付きで書いて」とプロンプトし、レビューします。実際のコードベースでモジュールごとに20分節約できます。

スライド草稿とステークホルダー向けサマリー。 最初の草稿のみ。モデルが何をして結果がどうだったかについての箇条書きを書き、「ML専門外の聴衆向けの3枚のスライドに変換して」とClaudeに依頼します。その後、約60%を書き直します。ファーストドラフトは退屈な部分（構造、遷移、繰り返しによる強調）です。書き直しが実際に重要な部分を加える作業です。

文献レビューのサマリー。 5本の論文アブストラクトを貼り付けて「イベントストリームデータからの顧客解約予測に関連するものはどれで、各論文の核心的な手法は何か？」と尋ねます。出力はトリアージリストです。その後、実際に読む必要がある論文を読みます。これは要約であり解釈ではありません。論文3がトランスフォーマーを使っているとサマリーが言えば確認できます。

このすべてに共通するパターン：AIは「正しい」がどう見えるか既に分かっている部分で優れています。だから間違いを発見できます。AIは考える代替物ではなく、入力の加速装置です。

AIが破綻する場面（絶対に委任しない）

AIに触れさせない部分と、各理由を説明します。

因果推論。 交絡因子、選択バイアス、識別戦略、回帰係数が因果的な意味を持つかどうか。LLMは差分の差分設計が必要な問いに喜んで傾向スコアモデルを書きます。AIはデータ生成プロセスを知りません。どの変数が処置後変数かを知りません。「コントロールグループ」がアウトカムで選択されていることを知りません。自信たっぷりの誤った因果主張は主張がないより悪く、AIはこの点で特に自信たっぷりに間違えます。

モデリングの意思決定。 どのアルゴリズムを使うか、どの損失関数を使うか、どの検証スキームを使うか、リーケージをどう扱うか。これらはビジネスコンテキスト、データの形状、モデルの用途に依存する判断です。Copilotはランダムフォレストが学習データに最も多く登場するためランダムフォレストを何にでも提案します。あなたの問題に、すべての交差検証スキームを破る時系列リーケージがあること、前向き連鎖スキーム以外は使えないことを知らないのです。これらの判断は自分で下す必要があります。

特徴量の解釈。 SHAP値がこのビジネスコンテキストで何を意味するか。AIはSHAPプロットを生成できます。SHAP値が抽象的に何であるかを説明できます。「在籍期間のSHAP値が高い」が在籍期間が因果的に重要であることを意味するのか、それとも測定していない別の何かの代理変数であることを意味するのかを判断できません。それにはビジネスを知ることが必要です。

ビジネスのフレーミング。 「モデルはこのセグメントの解約確率が0.73と言っている」を「$50K超のアカウントの更新ケイデンスを変えるべきだ」に翻訳すること。これは意思決定の翻訳であり、間違えるとデータサイエンスの信頼性を失います。LLMはあなたの会社のリスク許容度を知りません。どのステークホルダーがデータワークに懐疑的でより多くの証拠が必要かを知りません。前回同様の介入を提案したとき失敗したことを知りません。

簡潔に言えば：AIは何に対しては問題ありません。なぜとだから何には絶対に使わないでください。

実際に機能するツールスタック

ほとんどを試した後、2026年の現役データサイエンティストとして落ち着いたスタックです。

コードにはCursor。 より優れたLLM統合を持つVS Codeです。Composerフィーチャー（マルチファイル変更を説明して編集案を提案させる）は、3ファイルにわたる特徴量パイプラインのリファクタリングに本当に役立ちます。定型作業では自動補完をオンにして、ロジックを考えるときはオフにします。モード切り替えが重要です。

コードレビューにはClaude（または相当品）。 PRを開く前に、「スタイルではなく正確性についてレビューして。カラム参照、オフバイワンエラー、リーケージ、非推奨API、null処理のエッジケースに注目して」というプロンプトでdiffをClaudeに貼り付けます。バグを見つけます。常にではありませんが、続けるだけの価値があります。締め切り前の夜11時に使える第二の目です。

ノートブック内蔵AI（Hex Magic、Deepnote AI）は短いリードで。 EDAパスには最適です。「すべての数値カラムの分布を表示して」または「0.7以上の相関を見つけて」。最終的な分析は書かせません。制約は、生成されたものはすべてラップトップを離れる前にクリーンなノートブックで再実行され、生成されたSQLは一行一行読むというルールです。利便性は本物ですが、信頼は有界です。

1つのツールより2つのツールの組み合わせが優れている理由：それぞれが異なる盲点を持っているからです。Cursorはローカルコンテキスト（作業中のファイル）には優れていますが、データが実際にどう見えるかの理解は苦手です。Claudeは高レベルの推論（「これは意味をなすか？」）には優れていますが、IDEのコンテキストがありません。ノートブックツールはデータの素早い確認には優れていますが、使い捨てコードを書く傾向があります。異なる仕事には異なるツールが必要です。3つすべてを中途半端にこなす1つのツールではなく。

「LLMが分析を書いた」という罠

ジュニアとミドルレベルのデータサイエンティストで最もよく見られる失敗パターンで、知っているはずのシニアデータサイエンティストにも増えています。

パターン：モデリングを終え、結果テーブルがある。それをChatGPTに貼り付け「主要な発見をサマライズして」と依頼する。自信を持って、明確に、よく構造化されたナラティブが出てくる。軽く編集してレポートに貼り付けリリース。

問題は、LLMがデータサイエンスの結論がどう聞こえるかにパターンマッチングしているのであって、あなたのデータが実際に示すことに対してではないことです。「モデルは強力な予測パフォーマンスを示し、特徴量の重要度は顧客エンゲージメントが主要ドライバーであることを示唆している」といったことを言います。その文は構造的に正しくまったく偽である可能性があります。モデルはリーケージした特徴量でのみ良い性能を出しているかもしれません。「顧客エンゲージメント」はターゲットとほぼ重複しているために重要度が高いだけかもしれません。

これはp値ハッキングの現代版です。p値ハッキングは十分な検索を通じてデータに合うストーリーを見つけることでした。LLM分析の罠は、それが真実かどうか確認せずにデータに合わせたストーリーを書いてもらうことです。ストーリーは妥当で、文章はクリーンで、基礎となる主張は間違っています。

落とし穴にはまったかどうかの判断方法：サマリーの各文章を支持する具体的な数字を、一行ずつ結果の中で指し示すことができなければ、罠にはまっています。修正方法は自分で分析を書き、次にLLMに明確性のための編集を依頼することです。自分が書いた草稿を編集することは、数字からドラフトを生成することと根本的に異なります。最終的な文字数が同じでも。

AIとMLと、LLMアプリの構築

チームの会話でこの混乱が絶えないため、簡単に整理します。

データサイエンティストがCopilotを使って解約モデルを構築するのは、AI支援IDEでクラシカルMLを行うことです。モデルはXGBoostまたはニューラルネット。評価はAUC、キャリブレーション、ビジネスへの影響。デプロイはバッチスコアリングジョブまたはリアルタイムAPI。失敗パターンはリーケージ、モデルドリフト、誤較正です。

データサイエンティストがRAGシステムまたはLLMエージェントを構築するのは別の作業です。「モデル」は学習していないファウンデーションモデルです。評価はAUCではなく定性的またはLLMジャッジベース。デプロイはプロンプトテンプレート、検索インデックス、ガードレールを持つサービスです。失敗パターンはハルシネーション、プロンプトインジェクション、コスト暴走です。

どちらも正当な作業です。どちらもデータサイエンティストの仕事になりえます。しかし同じスキルではなく、前者で優れたシニアデータサイエンティストが、十分な経験を積むまでは後者では凡庸かもしれません。リーダーシップが「製品にAIを追加して」と言ったとき、どちらを意味するか尋ねてください。分からない場合、それが最初の会話であり、コーディングタスクではありません。

ACE Frameworkのオプションタグ付け

チームがACE Framework（Ingest、Analyze、Predict、Generate、Execute）を使用している場合、クラシカルなデータサイエンスの作業のほとんどはAnalyzeとPredictに位置します。LLMアプリの構築はGenerateにあります。これは単なる用語ではありません。スコープが広がるときに押し返す方法です。PMが「解約モデルに生成AIフィーチャーを追加できますか」と尋ねたとき、「解約モデルはPredictケイパビリティです。説明しているのはGenerateケイパビリティであり、異なる評価を持つ別のシステムです。別々にスコープしましょう」と言えます。フレームワークは既に知っている境界に言葉を与えます。

30日間の導入計画

最初からやり直す場合、またはジュニアデータサイエンティストをAI支援の仕事に慣れさせる場合に実行する計画です。

Week 1：定型コードとdocstringのみ。 Cursorをインストールし、Claudeアカウントを設定します。機械的なタスク（pandasのリシェイプ、sklearnパイプライン）のコード補完と、既に書いた関数のdocstring作成にのみ使います。提案が間違っていたたびにメモを取ります（テキストファイルで十分）。週末までに、自分のコードベース固有の失敗パターンの例が約20個得られるはずです。これはキャリブレーションデータです。ツールをいつ信頼し、いつ無視するかを教えてくれます。

Week 2：EDA支援を追加。 EDAがどう見えるべきかを既に知っている完了済みプロジェクトを1つ選びます。AI支援でEDAパスを再実行し、元の作業と比較します。AIが見逃したこと（コンテキストに依存するもの、例えば「この変数は正常に見えるが実際には未来からのリーク」）と、自分より速く発見したことに注目します。週末までに、AI EDAが有用な場合とそうでない場合の成文化されたルールを持つべきです。

Week 3：コードレビューループ。 開くすべてのPRに対して、まずコードレビュープロンプト付きでdiffをClaudeに貼り付けます。ログを取ります。Claudeから有用なコメントが得られたPRの数は？ チームのレビュアーが見逃すであろうバグをClaudeが発見した数は？ 誤検知の数は？ 1週間後には、このループを続ける価値があるかどうかの感覚が得られます。私には価値がありましたが、キャリブレーションはチームごとに異なります。

Week 4：チームの「AIを使う場所・使わない場所」ドキュメントを書く。 1ページ。AIがデフォルトのツールであるタスクをリスト。AIが禁止されているタスクをリスト。AIは許可されているが、すべての出力がマージ前に人のレビューを受けるタスクをリスト。マネージャーからの承認を得ます。書き留める目的は会話を強制することであり、それが存在を知らなかった不一致を表面化させます。

よくある落とし穴

本番環境での爆発頻度順に整理した短いリストです。

1. 幻覚されたカラム名の信頼。AI生成コードで参照されるカラムが実際にデータフレームに存在することを常に確認してください。df.columns.tolist()があなたの味方です。
2. 第2の意見なしにモデルの推奨を受け入れること。Copilotが「ここではランダムフォレストを使って」と言ったとき、なぜかを自問し、Claudeに別途その選択を批判させます。不一致は情報です。
3. AIにエグゼクティブサマリーを書かせること。既に説明しました。しないでください。
4. 因果主張にLLMを使うこと。自信を持って答えを出します。その答えは真実と相関がありません。
5. プロンプトのコンテキストウィンドウがデータフレームを切り詰めることを忘れること。50行のサンプルを貼り付けて「外れ値パターンはあるか」と尋ねると、LLMは50行しか見えません。長い裾については知りません。全データに対してアドバイスが間違います。
6. プロジェクトをまたいで同じプロンプトを再調整せずに使うこと。あなたのコードベースには慣習があります。汎用コードレビュープロンプトはチーム固有のパターンを検出しません。

テンプレートとツール

実用的なスターターキットです。

• Cursor rules fileデータサイエンス用。 Cursorにチームの慣習を伝えます。使用しているsklearnのバージョン、Pandasではなくpolarsを使うこと（またはその逆）、すべての特徴量にリーケージコメントが必要なこと。
• Claudeコードレビュープロンプトテンプレート。 「このdiffをレビューして：カラム参照の正確性、リーケージ、非推奨API、nullのエッジケース、コードベースの残りとの一貫性。スタイルについてはコメントしないで。」
• AI使用ポリシーの1ページ。 チームが同意する文字通り1ページのGoogleドキュメント。3列：タスク、AIは許可？、レビューは必要？ チームチャンネルに貼り付けてください。
• EDA検証チェックリスト。 AIがEDAを生成したとき：nullを正しくカウントしたか？ 10,000の固有値を持つカテゴリカル変数に気づいたか？ タイムゾーンの問題がある日付カラムに気づいたか？ これらを見逃した場合、残りの出力は疑わしいです。

これが機能しているかどうかの測定

重要度順に3つのシグナルがあります。

1. 新しいデータセットで最初のモデルに至る時間が目に見えて短縮される。 ジュニアデータサイエンティストがベースラインモデルに3日かかっていて今は1日で済むなら、それが求める成果です。時間が短縮していなければ、本当に役立つ部分にAIを使っていません。
2. 「カラムが間違っている」または「非推奨API」に関するPRレビューのコメントがゼロになる。 これらは簡単なバグです。まだ表れているなら、Week 3のコードレビューループが検出していません。
3. チームに書かれたポリシーがあり、それを参照している。 存在するドキュメントだけでなく、PRや設計レビューで引用されるドキュメント。「セクション3のポリシーのため、これにはAIを使わない」が境界が実在するマーカーです。

これらすべてより重要なネガティブシグナル：チームの誰もLLMが書いた分析を自分の作業としてリリースしていないこと。いずれ起きます。そのとき問題はAIポリシーではなく信頼性であり、修正はツール変更ではなく会話です。

「AIが速く出荷するのを助ける」と「AIが誤った分析を自分の名前でリリースした」の境界線は、マーケティングが示すより薄いです。明確に境界を引き、書き留め、ツールが変わるたびに四半期ごとに見直してください。

関連ガイド

• データサイエンティスト職務記述書
• 初めての本番MLパイプライン構築
• データサイエンティストのステークホルダーコミュニケーション
• 因果推論と予測モデリング