はじめに
前半戦では、VS Code × GitHub Copilotで5人のAIエージェントによるデータサイエンスチームを作り、訪日外客数予測プロジェクトのPhase 1〜4を進めました。
前半戦の記事はこちらです。
AIエージェントと組んだら、データサイエンスプロジェクトはどう変わる？実験してみた（前半戦）
前半戦では、データ収集・クレンジング・EDAのような、泥臭くて時間がかかる作業をAIエージェントチームがかなりの速度で進めてくれると実感しました。ただし、Phase 4まではまだ「分析の準備」です。
本当に見たかったのは、その先でした。
- 特徴量を実装し、学習データを正しく作れるのか
- モデルの精度が悪かったとき、自分たちで原因を整理できるのか
- 改善案を提案し、条件を揃えて何パターンも検証できるのか
- 最終的に、毎月使える形まで持っていけるのか
後半戦では、Phase 5〜8を通じてここを検証しました。
後半戦で見えてきたのは、次の分担です。
AIエージェントが検証を回し、人間は結果を見て次の一手を決める
コード実装や集計に使う時間が減り、「結果を信じてよいか」「次に何を試すか」を考える時間が増えました。
この記事では、Phase 5〜8で実施したことをダイジェスト紹介しつつ、AIエージェントと一緒にモデル開発を進めると、人間の仕事がどう変わるかを中心に振り返ります。
Phase 5: 特徴量エンジニアリング
「特徴量を作って」で、地道な実装と検査まで終わる
Phase 5では、Phase 4 の特徴量と予測モデル設計を元に、特徴量生成を実施しました。
AIエージェントチームは実装に加え、次の作業まで進めました。
- 20か国、2003年以降のデータを再統合
- 為替、GDP、祝日、検索関心、直行便などの欠損方針を整理
- 23特徴量を共通ロジックで生成
- Train・Validation・TestをモデルA/B別に分割
- 学習時と推論時で特徴量計算がずれないことをテスト
- 0と欠損を区別
- 重複、無限値、期間、対象国、列定義を自動検査
- 特徴量定義書、欠損レポート、品質レビューを更新
特徴量開発は、式を書くこと以上に、列・欠損・期間の確認やデータ混入の防止、定義書の更新に時間がかかります。今回は細かな手順を指示しなくても、チームが作業を分解し、品質レビューまで成果物をそろえました。
重大なデータ品質事故を、AIエージェントチームが自律復旧した
Phase 5の後、最新データから分析データを作り直す過程で、重大な品質事故が発生しました。
- 「11月」という文字列が「1月」にも一致し、全年の1月・2月を11月・12月の値で上書き
- 0人だった月を欠損とみなして除外し、時系列ラグがずれる
- 韓国ウォンとインドネシアルピアの為替系列に100倍級の単位断層が混入
- 国名の部分一致で地域集計行を米国として扱い、正しい米国値を上書き
今回は、データ作成とは別の役割を持つエージェントが元データとの不整合を検知しました。問題共有後は各担当が影響範囲を確認し、修正と再検証まで自律的に進めました。
単独のAIエージェントは間違えることもあります。一方、AIエージェントチームが役割を分けて成果物を相互確認させることで、ミスの発見と復旧を速め、品質向上につながることがここでも確認できました。
Phase 6: ベースラインモデル構築
モデル構築から評価作業まで一瞬で揃ったが、精度がイマイチ
Phase 6では、LightGBMによるベースラインモデルを構築しました。
長期データを使うモデルAと、直行便特徴量を持つモデルBについて、1〜3か月先を別々に学習する合計6モデルです。
モデル構造と実験条件を確認して実行を指示すると、学習プログラムから評価、再現性確認まで一式が作成されました。
- LightGBM 6モデル
- 単純ベースライン2種
- R²、MAE、RMSE、MAPE、sMAPE、WAPE、方向性一致率
- 20か国×3予測期間の折れ線・差分グラフ60枚
- モデル比較図3枚
- 学習済みモデルの保存・再読込・同一予測確認
- 入力データとモデルのSHA256保存
- Testデータを使っていないことの監査
ところが、最初に作成されたモデルの精度はあまり高くありませんでした。
モデルAのMAPEは21.2〜23.8%、モデルBは22.1〜26.6%。特に韓国や中国などの大きな市場で、回復後の需要水準を大幅に過小予測していました。
「精度が良くないので問題を整理して」と依頼すると、単なる目標未達の報告ではなく、次の原因まで整理されました。
- 2019年以前の学習データと、2024〜2025年の需要構造が変わっている
- 木モデルは、学習時に存在しなかった高い人数水準への外挿が苦手
- モデルBは直行便特徴量を持つが、学習期間が短い不利の方が大きい
- 全体R²は高く見えるが、国の規模差に引っ張られている
- 国別MAPEとWAPEを併用しなければ、業務上の問題を見落とす
国別MAPEでどの国で誤差が大きいかを確認したり
国別に予実差を可視化したり
人間がモデルを作って精度が悪かった場合、そこから国別集計を追加し、予実グラフを作り、残差を確認し、原因仮説を文章にするだけでかなり時間がかかります。
AIが良い数字を出すことだけが価値ではありません。悪い結果を隠さず、判断できる形に変換することにも大きな価値がありました。
Phase 7: モデル改善
AIエージェントの真骨頂は「改善検証高速ループ」だった！
ここが、今回の実験で最もAIエージェントの恩恵を感じた工程でした。
私が「精度を改善したい」と伝えると、チームは改善候補を列挙し、比較の順番と採用条件を整理しました。
- S00: 共通評価・再現性基盤
- S01: 目的変数を訪日外客数から前年同月比へ変更
- S02: 直近水準との差分を予測
- S03: 学習期間をそろえた直行便特徴量のアブレーション
- S04: 長期モデルへ直行便特徴量を追加
- S05: 重点国へのサンプル重み
- S06: 新しい時点を重視する時間重み
- S07: ハイパーパラメータ最適化
さらに、検証ルールも固定しました。
- 1回の実験で変更するものは1つだけ
- 親シナリオと変更点を記録
- 入力データと設定を固定
- 学習・保存・再読込・推論再現性を確認
- 全体・予測期間別・20か国別に評価
- 改善だけでなく悪化と副作用も考察
- 採用・一部採用・棄却を記録
- 採用した変更だけを次へ引き継ぐ
この一連の作業が、1シナリオあたり体感15分程度で進み、物凄い勢いでアウトプットを量産していきます。
1シナリオは体感15分程度。条件の固定、再学習、集計、グラフ、実験ログ、再現性確認までを同じ形式で繰り返します。人間は比較結果を見て、次へ進むかを判断します。
AIが実験担当、人間が研究責任者に近い役割になる。
そんな感覚でした。
目的変数を変えただけで、大幅に改善
最も効果があったのは S01 シナリオでした。
ベースラインでは訪日外客数そのものを予測していましたが、S01では前年同月比を予測し、12か月前の実績から人数へ戻すというやり方です。
変更は目的変数だけですが、モデルAのMAPEは22.8%から16.4%へ改善し、方向性一致率は67.7%から78.3%へ上がりました。
[主要KPIの読み方]
[S00とS01の比較]
未知の人数水準を直接外挿する代わりに、相対的な変化を学習させる、Phase 6の問題に対して素直な改善策です。この案もチームが原因仮説から提案し、検証しました。
しかし、S01はMAPEこそ全6条件で改善したものの、それでもまだ過小予測の傾向が見受けられました。
大胆な改善案はAIエージェントチームからは出にくい
ここで私は、「テスト期間を広く残すことより、コロナ後・円安時代のデータも学習させた方が、過小予測の問題を解決できるのではないか」と提案し、データ期間の再設計の検討を依頼しました。
チームは初期に決めた期間分割を守り、コロナ後の需要回復や円安が進んだ時代のデータを十分に学習へ使えていませんでした。テストデータを残すことは重要ですが、今回はそのルール自体を見直す必要がありました。
指示を受けたチームは、3つのシナリオをすぐに再生成・再評価しました。データ期間を見直したS01では、主要KPIが目標内に収まり、精度改善を確認できました。
AIエージェントは、決められたルール内での改善と検証には強い一方、ルール自体を疑う大胆な提案は出しにくいようです。行き詰まったときに前提を問い直す役割は、まだ人間側に残ります。
また、AIエージェントチームが提案したシナリオを全て実施したわけではありません。
S03で直行便特徴量の純粋な効果を確認できなかったため、S04は中止しました。Validation結果に合わせた局所的な調整になりそうだったS05〜S07も、あえて実施しませんでした。
高速に検証できるからこそ、無駄なトークン消費や過適合を避けるため、人間側には止める判断も必要です。
「予測モデル自体をLLMにやらせたら？」実験
一般的な生成AIにも訪日外客数を予測させました。詳細は別記事にまとめます。
一部の国・条件ではLightGBMを上回り、正直かなり驚きました。
ただし、人数予測にはLightGBMの方が安定しているため、こちらを採用しました。
最終的な判断は、次のようになりました。
- LightGBMのS01は監査・比較用の暫定候補
- LLM単独の人数予測は不採用
- LLMはモデル間の乖離理由や外部リスクの候補提示に限定
- 数値計算と品質判定はPythonで固定
**LLMは得意なところだけに使い、数値の確定と検査は従来コードに任せる。**その責任分界までチームが設計したことが印象的でした。
Phase 8: モデル運用
モデルを作るだけでなく、「毎月回る形」まで持っていく
Phase 8では、改善したモデルを使って、毎月3か月先を予測するローカルアプリと月次パイプラインを構築しました。
「最新データを取り込み、予測し、説明付きで確認できるようにしたい」という要求から、AIエージェントチームが次の流れを設計・実装しました。
最終的な予測結果は、国・地域を切り替えて確認できるアプリへ反映します。
[ 予測時点：2026/04、対象国：韓国 ]
[ 予測時点：2026/06、対象国：オーストラリア ]
アプリには予測値だけでなく、背景・リスク・確認事項も表示します。業務担当者が次のアクションを決めるための材料まで、一つの運用フローにできました。
まとめと感想
前半戦で感じた可能性が、後半戦では具体的な作業スタイルになりました。
良かった点
1. 思いついた検証を、その場で試せる
「目的変数を前年比に変えたら？」といった案を、実装・評価・グラフ・報告まで含めて短時間で試せます。実装コストで諦めていた検証も実行できるようになりました。
2. 比較のための地味な作業を正確に繰り返す
同じ指標・国・期間・図表で比較し続けるのは意外と難しい作業です。手順をSkillsに固定すると、同じ形式で粘り強く繰り返してくれました。
3. コードだけでなく、評価資料と証跡も同時に残る
モデル、予測CSV、評価指標、国別グラフ、実験ログ、入力ハッシュ、PPTX、テストが同時に生成され、後から条件を追いやすくなりました。
課題・改善ポイント
1. 高速に回せるからこそ、実験を止める基準が必要
AIは次々と改善案を出せますが、Validationを見ながら調整を続けると過適合します。S04〜S07を中止したように、停止基準を先に決める必要があります。
2. AIエージェントチームにも、ドメイン知識は必要
国別需要の急変や、航空便・為替・渡航注意喚起の意味は、一般的なモデル知識だけでは解釈できません。
前半戦と同様、ドメイン知識をどのようにSkillsや参照資料へ落とすかは、引き続き重要な課題です。
3. 最終判断の責任は人間に残る
情報がそろっていても、自動的に正しい意思決定ができるわけではありません。利用目的によって必要な精度と確認手順は変わります。誰が、どの基準で利用を承認するかという最終責任は人間に残ります。
人間の仕事は「作る」から「判断する」へ
後半戦で最も強く感じたのは、AIエージェントの価値はモデルを1回作ることより、検証ループを高速かつ正確に回し続けることにあるという点です。特徴量生成から再実験まで、人間なら数日かかる作業を短時間で繰り返しました。
人間は結果を確認し、次の判断をします。
- このシナリオは採用
- これは効果がないので棄却
- この比較条件では判断できないので再検証
- これ以上の局所調整は過適合になるので中止
- 数値予測には使わず、理由候補だけに限定
- 精度が足りないので業務投入しない
手を動かす仕事が減り、判断する仕事の比重が上がったのだと思います。
判断材料がコード・データ・グラフ・評価表・監査ログとしてすぐに出てくるため、適切なガードレールとレビューがあれば、ビジネスパーソンや初学者も試したい仮説を検証しやすくなります。
前半戦では「AIと組んでデータサイエンスを進める世界は、すでに手の届くところにある」と書きました。
後半戦を終えた今は、もう一歩踏み込んで、次のように感じています。
AIエージェントは、データサイエンティストの代わりというより、検証速度を何倍にもする実験チームになり得る。
人間は何を知りたいかを考え、結果を疑い、次の一手を決める。AIは判断に必要な実験を何度でも回す。
この組み方が、AIエージェント時代のデータサイエンスプロジェクトの一つの形なのかもしれません。