※この記事は、2026年4月にZennにて記事にしているものですが、訪日外客数データを使ったデータ分析シリーズとしてQiitaにもアップします（後半戦をQiita側にアップする都合で）
はじめに
近年、生成 AI の進化は目覚ましく、その波はデータサイエンス領域にも確実に広がっています
では、生成 AI はデータサイエンスの仕事をどこまで代替・拡張できるのでしょうか
機械学習モデルそのものの数理計算やアルゴリズム処理は、依然として従来の手法に依存しています
しかし一方で、データ前処理・特徴量生成・推論結果の解釈といった “モデル前後の工程” においては、生成 AI の活用により生産性と品質の両面で大きな向上が期待できます
本記事は、同僚の Qiita 記事「AI エージェントだけでスクラムを回してみた」に着想を得て、データサイエンス版にトライしたものです
すなわち、 複数のAIエージェントと組んでデータサイエンスチームを作り、実際の機械学習プロジェクトを一緒に進めたらどうなるのか を検証し、その結果と気づきを率直にまとめます
この記事は、データサイエンス PJ 前半戦（Phase1-4）です
AI エージェントのデータサイエンスチーム
このチームのコンセプトとして、データサイエンスの専門知識を持たないビジネスパーソンやデータサイエンティスト初学者が、 AIエージェントチームに専門的な分析・実装を任せることで、自分のやりたい分析を実現できるという世界を目指し ており、
最初に指示して後はAIに丸投げではなく、依頼者とAIエージェントチームが対話しながら、追加作業が必要か、次のPhaseに進んでよいか確認しながら進めていくスタイルを想定しています
プロジェクト成果物の定義
GitHub Copilotのカスタムインストラクションを使って、PJの進め方、成果物や格納場所を定義します
データサイエンス開発工程
筆者のデータサイエンス経験とAIと相談しながら 9工程を定義しました
工程毎にAIエージェントチームの成果物を確認しながら進めていくスタイルです
| フェーズ | 工程 | 主な成果物 |
|---|---|---|
| Phase 1 | ビジネス理解・仮説定義 | ビジネス要件定義書・分析仮説リスト・KPI／評価指標定義 |
| Phase 2 | データ棚卸し・取得 | データカタログ（データ一覧・定義）・データ取得スクリプト・生データ（Rawデータ） |
| Phase 3 | データ理解・基礎分析 | EDAノートブック・データプロファイル（統計情報）・相関分析結果・可視化レポート |
| Phase 4 | モデル設計 | モデル設計書（アルゴリズム選定理由含む）・特徴量定義（初版）・中間報告資料（PPT） |
| Phase 5 | 特徴量エンジニアリング | 特徴量定義書（詳細版）・特徴量生成スクリプト／パイプライン |
| Phase 6 | ベースラインモデル構築 | ベースラインモデル・評価指標（Accuracy, RMSE等）・初期評価結果 |
| Phase 7 | モデル改善（反復） | 改善モデル（複数パターン）・実験ログ（ハイパーパラメータ、結果）・比較評価結果 |
| Phase 8 | モデル運用 | デプロイ設計書（アーキテクチャ）・モニタリング設計（精度・データドリフト）・運用プロセス定義 |
AI エージェントのロール定義
それぞれ専門知識を持つ5人の AI エージェントがチームを構成し、データサイエンス PJ を横断的に連携します
相互レビューを通じて多角的な視点で検討を深め、品質と意思決定の精度向上を目指します
先人のアイデアを受け継ぎ、愛着がわくようにAIエージェント達に名前をつけたが、作業ログや議事録に名前だけが表示され、りょうたって何の人だっけ？と混乱したので、MLEりょうたとロールもわかるように記載してもらったけど、MLEでいいじゃんと名前をつけたことをちょっと後悔していたり。。。
GitHub Copilotのカスタムエージェントを使って各AIがロールを遂行できるようにします
作成したカスタムエージェントは以下の5ファイルです
オーケストレーションリーダー：たろう のロール定義
データサイエンティスト：みか のロール定義
スキル定義
Skillsは、AIエージェントチームがデータサイエンスプロジェクトを自律的に遂行するための手順・役割分担を定義したワークフロー定義ファイルです
どのエージェントがどんな役割で、どんな観点を大事にタスクに取り組むのかを定義します
いざ、プロジェクトスタート！
分析テーマ
今回の分析テーマは、筆者の過去Qiita記事でも題材にさせて頂いた 訪日外客数データ を使った 訪日外客数予測 （毎月の各国からの訪日外客数を予測するモデルを作りたい）をテーマにします
Phase1: ビジネス理解・仮説定義
VS Code × Github Copilot チャットウィンドウから
team-request スキルを使って、明示的にAIエージェントチームに依頼をかけます
すると早速、オーケストレーションリーダーのたろうが、要件詳細をヒアリングしてくるので、依頼者が回答します
伝えた情報から丁寧に依頼書を整理してくれました
パワポの報告書もお願いと伝えたのでそれも快く？引き受けてくれました
依頼書をもとに、チームで協力して Phase1 完了！ （体感10分弱）
OL たろうがこの工程でやったこと、成果物をわかりすく報告してくれます
データソース調査とかPhase2に先回りして幅広く調査・整理してくれた印象です
Phase 2: データ棚卸し・取得
Phase2 の着手許可を求めてくるので、「はい」と許可して Phase2 に入ります
暫くデータサイエンスチームが作業後（体感30分）、OL たろうが完了報告をしてきました
データ棚卸リスト（data_source_inventory.csv）を確認すると、いい感じの外的要因データをリストアップしていて、なかなかセンスありです
これが1人のAIエージェントが単独でリストアップしたのではなく、チーム内でデータソース選定会議を開いて、それぞれのロール視点でディスカッションして選定しているところが、なんとも甲斐甲斐しく頼もしいのです
そして、ただデータソースを収集するだけではなく、後続のデータ分析目的に合わせて、データクレンジングもやってくれています
その PG(Python) まで成果物になっていて感動です！
この訪日外客数データソースは Excel 表データで、年毎シート別の構成になっており、
途中 (2019年→2020年)でセルレイアウトが微妙に変わったり、国名表記ゆれがあったりしていて、Power BI でクレンジングしていた時は結構大変だったクセありデータなのだけど、DE しんじ AIエージェントが難なくPG化していますちょっと PythonPG 覗いてみると、月ヘッダー検出と国名正規化はかなり汎用的に作られていて感心です
逆に、年の見つけ方だけは「2026まで」と決め打ちが入っていて、2027年以降で落ちる可能性があるのでモデル運用観点ではここは見直した方がよさそうなポイントですね
後続Phaseで修正でもいいけど、最初からそのあたりも考慮されたPGになるようにSkills定義に記載追加検討しようと思いました
追加作業リクエスト
さて、良さそうに見えたデータ棚卸リストですが、依頼者的には少し残念なところがあったようです
「国際線就航データ」がリストアップされるも、入手困難という理由で不採用になっていたことです
少しこの分野のドメイン知識を持っている（という設定）の依頼者は
国交省ページのちょっと深いところに 国際線就航状況の公開データ があることを知っており、これが使えないかと取得調査をデータサインエスチームに追加依頼しました
本当は BDE さなえ からチームに提案してほしいところだけど、ドメイン知識不足かな。。
しばしの初期調査後とチーム選定会議の結果報告があり、今すぐ取得・加工に着手するかどうか？確認され、今すぐ着手を指示します
DEしんじ が、国際線就航状況データの取得＆クレンジング処理、やり遂げてくれました！
この国際線就航状況データは、もし人間に取得作業依頼させるとしたら、依頼を躊躇うくらい取得作業が面倒くさいデータで、手作り感あるExcel表で列名も毎年微妙にちがったり、国名の表記ゆれも結構あり、データクレンジングが辛いデータなんですが、
DE しんじの手にかかれば、秒で処理実装し、データクレンジングPG(Python）とクレンジング済みデータを作り上げてくれました👏👏👏
データはこちら、そうそうこれこれ！ 年月、国名、便数/週 があれば、特徴量に使えます
国際線就航状況データは一旦△仮採用扱いで、Phase3へ進みます
実はこの DE しんじファインプレーに落ち着く前、事件が起こっていましたがそれは後段で。。。
Phase 3: データ理解（ビジネス理解）・基礎集計
Phase3に入ります。最初のターンで、たくさんのEDA分析レポートを色々作ってくれました
しかし、EDAレポートからの考察整理が足りない気がするので追加依頼します
AIエージェント達が作ってくれた EDA レポート例
COVID回復率 2019vs2025 レポートと回復遅延している国の原因考察
データサイエンスチームに無理言って収集してもらった 国際線就航データは、やはり有用な特徴量になりそうです
直行便数と訪日客数は最も強い相関！！ 依頼者勝ち誇ります
追加作業リクエスト
EDAサマリレポートは、ビジネスオーナーの依頼者としてはとても興味深く、気になる点がどんどん出てきて、2回追加依頼をしました
Google Trends EDAの発見
為替レートの国別ラグ分析の発見
ものすごい勢いで 32 本の EDA グラフとサマリをまとめてくれました
内容も的を得ていてとても良いです
この Phase では、依頼者からの指摘・追加依頼 ⇒ データサイエンスチームによる再分析作業の繰り返しにより、有用な特徴量を作り出す重要な発見に繋がり、分析アウトプットの品質が向上しました
依頼者もドメイン知識がそれなりにある設定ですが、本来は BDE さなえにチームへ情報インプットして AI エージェント達だけで発見・整理してほしいところです
やはりロール定義だけでなく、ビジネスドメイン知識をスキル定義しないと厳しいのかなと課題を感じました
AIエージェント達だけで自律的にディスカッションを繰り返してくれて、勝手に精度・品質向上できるようになるといいなと感じました
Phase4: 予測モデル設計
Phase4に入ります。EDAで得た発見を活かして、予測モデルと特徴量の設計をしてくれたようです
確かに、EDAとデータ取得時タイムラグを考慮して、特徴量ロジックを考えてくれているようです
非常に良い設計だと感じました
モデル設計書を読むと、「2段階モデリング戦略」という興味深い記載があったので、データサイエンスチームにつっこんで確認してみます
なるほど、予測理由の説明力を重視しているこのプロジェクト要件にフィットした設計にしてくれているんですね
このデータをよく知っている筆者も、この発想には至らず、とても興味深いと感じました
中間報告書まとめ（体感10分弱）
依頼者がついでに依頼したタスクのため、報告書のまとめ詳細はスキル定義していないのと、依頼者のイメージに合わせて構成してほしかったので、ちょっと細かく指示します
そして、データサイエンスチームが作成してくれた中間報告書のプレゼン動画（7分半）がこちらです
データサイエンティスト：みか がプレゼンしたような中間報告動画ですが、M365 Copilot の動画作成エージェントを使って中間報告PPTから作りましたAIエージェント データ捏造事件👀
実は、Phase2内で、国際線就航状況データが利用対象外となっていたのを見て、チームに再検討をお願いした際に事件が起きました
依頼者からのリクエストになんとか応えようと思ったのか、色々加工処理された意図の不明なデータが出てきたため、どのように作成したのか説明してもらったところ、AIエージェントが 主観に基づいて生成したデータであると説明してきました
「主観で数字を作った…？」と思わず驚きました
データサイエンスチームとしてありえない行為だと厳しく追及しました
すると、データサイエンスチームへの依頼ではないといった趣旨の回答が返ってきてしまい…
（依頼者としては、さすがに看過できない状況でした…）
この後、Copilot エージェントがロールバックを走らせて捏造データ作成工程は消えましたが、
なるほど、GitHub Copilot チャットウィンドウでマルチターンで会話しているため、AI データサイエンスチームに依頼しているつもりが、いつのまにか GitHub Copilot のチャットエージェントとのやり取りに切り替わってしまっていたようです
この事件を反省に
team-request というスキルを作成し、明示的にこのスキルを実行して依頼することで、必ずAIデータサイエンスチームに作業させるというルールに修正しました
また、「 データ捏造は絶対にやってはいけない行為で堅く禁ず 」と Copilot エージェントが Skills に定義を追加させていましたが、データサイエンスチームがやったんじゃないからな！おまえが勝手にやったことだぞ！と思いつつも、データサイエンスでは常識過ぎてそんなことをルールに書くという発想もなかったけど、確かに必要だなと記載を許可しました
まとめと感想
今回の実験を通じて、人間（依頼者＋筆者）は手を動かさず、依頼と成果物の確認のみで、データサイエンスプロジェクトを一定程度回せることを実証できました
AIエージェントによるデータサイエンスチームの可能性を感じるとともに、実運用に向けた課題も明らかになりました
良かった点
まず何より、AIエージェントチームのポテンシャルの高さには純粋に驚かされました
複数の専門ロールが連携しながら分析・実装を進めていく様子は、人間のチームに近い動きを再現できており、「任せることで成果が出る」感覚を強く得られました
特に印象的だったのは、以下のような ”泥臭くて時間がかかる作業”の高速化 です。
- データクレンジング処理の設計・実装
- 特徴量候補の洗い出しと有効性検証
- ラグや移動平均などのパラメータ探索
- 再現性のあるコードとデータの同時提示
これらを ほぼリアルタイムで実行し、成果物として整理してくれる 点は、実務において非常に価値が高く、データサイエンスプロジェクトの 生産性を大きく引き上げる 可能性を感じました
また、「専門的な分析・実装はAIに任せ、自分はやりたい分析や意思決定に集中する」 という働き方は、十分に現実的なものになりつつあると実感しました
課題・改善ポイント
一方で、実用化に向けてはいくつか明確な課題も見えてきました
1. ビジネスドメイン知識の扱い
今回最も大きく感じたのは、 ビジネスドメイン知識をどうスキルとして定義・注入するか という点です
ロールとして「ビジネスドメインエキスパート」を用意しても、実際の知識が伴わなければ、適切な示唆や提案は生まれません
これは現実のプロジェクトでも同様で、
- 特定の人の頭の中にしかない暗黙知
- 経験に依存した判断ロジック（いわゆる“匠の技”）
といった要素を、いかに言語化・構造化するかが重要になります
今後は、
- 過去ドキュメント
- ナレッジベース
- Work IQ (メール/会議/ファイル/Teamsチャット/人間関係/業務活動履歴等の職場データ）
などから、ドメイン知識を抽出し、 AIエージェントのスキルとして体系化するアプローチ が鍵になりそうです
2. マルチターン対話による品質劣化
もう一つの課題は、対話が長くなるにつれてアウトプットの品質が徐々に粗くなる問題です
いわゆるLLMあるあるですが、
- 対応の抜け・漏れ
- 前提の考慮漏れ
- 作業の粒度が荒くなる
といった現象が見られました
今回のようにエージェントチームで複数工程をまたぐ場合は、
- フェーズごとの明確な区切り
- 成果物レビューの強制ポイント
- コンテキストの再定義（リフレッシュ）
など、オーケストレーション設計での制御が重要になると感じました
さいごに
課題もありますが、今回の検証だけでも、「AIと組んでデータサイエンスを進める」世界はすでに十分手の届くところにある という手応えを得ることができました
今後も検証を続け、後半戦や改善版についても記事として公開していく予定です
引き続き、AIエージェントとのデータサイエンスの可能性を探っていきたいと思います