はじめに

前半戦では、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エージェント時代のデータサイエンスプロジェクトの一つの形なのかもしれません。