MLプロジェクトでAIコーディングツールをどう使うか。Cursor、Claude Code、GitHub Copilotといったツールが普及した今、この問いは学習者にとって切実だ。Sourceに投稿された質問は、その迷いを正確に言語化している。

AIに「全部やらせる」は最悪手である

プロンプト：MLプロジェクトをAIで爆速開発する正しいワークフロー：vibe-codingの設計思想（記事内画像）

問いの選択肢の筆頭に「完全な要件を与えてAIにプロジェクトを丸ごと作らせる」がある。これは最も避けるべき手順だ。理由は単純。MLプロジェクトの品質はアーキテクチャ設計とデータパイプラインの判断に依存する。そこをAIに委ねると、動くが理解できないコードが生まれる。学習目的ならなおさら致命的だ。

MLプロジェクトには固有の構造がある。データ収集→EDA→前処理→特徴量エンジニアリング→モデル選択→学習→評価→デプロイ。各ステージで人間が下すべき判断が存在する。「どのモデルを選ぶか」「どの特徴量が意味を持つか」「評価指標は何を使うか」。これらをAIに丸投げすると、プロジェクトは動くが、なぜ動くかを説明できない状態になる。

投稿者自身がその危険を認識している点は重要だ。「MLをAIで置き換えようとしているのではない。概念は別途学んでいる。AIを使って速く、かつ構造的に正しいプロジェクトを作りたい」。この姿勢が正しい出発点だ。

責任分担の原則：人間が設計し、AIが実装する

実践的なワークフローの骨格はシンプルだ。

人間が担う領域：
- プロジェクトのアーキテクチャ設計
- パイプラインの全体構造の定義
- モデル選択の判断
- 評価指標の設定
- デバッグ時の仮説立案

AIに委ねてよい領域：
- データクリーニングのボイラープレート
- EDAの可視化コード
- 前処理の実装
- 定型的なモデル学習コード
- コードレビューと改善提案

この分担は「AIをジュニアエンジニアとして扱う」という考え方に近い。仕様を与え、実装させ、レビューする。判断はシニアである人間が下す。

プロンプトの粒度も重要だ。「MLプロジェクトを作って」という指示は最悪だ。「pandasを使ってCSVを読み込み、欠損値を中央値で補完し、カテゴリ変数をone-hot encodingする前処理関数を書け」という指示が正しい。スコープを絞るほど出力品質は上がる。

python
# 悪いプロンプトが生む曖昧なコード（概念例）
def preprocess(df):
# AIが「なんとなく」書いた前処理
df = df.fillna(0) # なぜ0なのか根拠なし
return df

良いプロンプトが生む意図のあるコード（概念例） def preprocess(df, numeric_cols, categorical_cols): df[numeric_cols] = df[numeric_cols].fillna(df[numeric_cols].median()) df = pd.get_dummies(df, columns=categorical_cols) return df

プロンプトに「なぜその処理をするか」の文脈を含めると、AIは意図に沿ったコードを生成する可能性が高まる。

コンテキスト管理とデバッグの戦略

投稿者が問う「1つの長い会話を使うか、ステージごとに分けるか」という問いは、実務でも議論になる点だ。

原則として、ステージごとにコンテキストを分けることを推奨する。理由は2つ。第一に、長いコンテキストはAIの注意が分散し、初期の指示が薄れる。第二に、ステージが独立していると、問題の切り分けが容易になる。

推奨する構造はこうだ。

セッション1: データ探索・EDA
セッション2: 前処理パイプライン
セッション3: モデル学習・評価
セッション4: コードレビュー・リファクタリング

各セッションの冒頭に「このプロジェクトの概要」「前のステージで決定した仕様」を簡潔に渡す。これがコンテキストの継続性を保つ最小コストの方法だ。

デバッグについては、AIが生成したコードのエラーをそのままAIに渡すだけでは不十分だ。「エラーメッセージ」「該当コード」「期待する動作」「試した対処」の4点をセットで渡す。これにより、AIは問題の文脈を正確に把握し、的確な修正を提案できる可能性が高まる。

デバッグプロンプトの構造 エラー: ValueError: Input contains NaN 該当コード: [コードを貼る] 期待する動作: 前処理後にNaNが存在しない状態 試した対処: fillna(0)を追加したが同じエラーが出る

この構造でプロンプトを書くと、曖昧な「エラーが出ました」より質の高い回答が返ってくる可能性がある。

結論：AIは実装の速度を上げる道具であり、設計の代替ではない

MLプロジェクトにおけるAI活用の本質は「判断の外注」ではなく「実装の加速」だ。アーキテクチャを自分で設計し、AIに実装させ、出力をレビューする。このサイクルを回すことで、学習速度と開発速度を同時に上げることができると考えられる。

投稿者の問いに戻る。最も重要な選択肢は「まずアーキテクチャ・パイプラインを自分で設計し、その後AIに各ステージを実装させる」だ。AIにレビューさせることも有効だが、それは最後の仕上げに過ぎない。

再現したい読者へ。次のMLプロジェクトを始める前に、紙でパイプラインの全体図を書け。その図が完成してから、初めてAIにプロンプトを投げる。この順序を守るだけで、生成されるコードの構造品質は大きく変わるはずだ。

関連リンク

  • Cursor（AI コードエディタ）：VS Code ベースのAI統合型コードエディタで、MLプロジェクトのコード生成・補完・デバッグを支援する。
  • Claude Code（Anthropic）：ターミナル・IDE・ブラウザで動作するAgentic コーディングツールで、コードベース全体を理解しながらファイル編集やコマンド実行をこなす。
  • GitHub Copilot：GitHubが提供するAIペアプログラマーで、インライン補完からエージェントモードによるタスク自動実行まで開発フロー全体を支援する。