AI Agents 調査対象日 2025年9月1日最終更新 2026年10月11日

AIが書いたコードから、比較できる実験結果へ

読了目安 8分

GPT-5とLookerの接続、MLE-benchとRE-Benchの評価を比べ、コードが動くことと実験が妥当であることを区別する。需要予測の想定例で、データの意味、比較条件、採用判断を結び付ける。

結果を使えるか

予測の誤差が減っても、採用を決められないことがある

AIに需要予測の改善を頼むと、コードを書き換え、学習を実行し、「誤差が減りました」という結果を返した。ところが、前のモデルとは評価した期間が違う。新しい結果が良く見える理由は、予測方法が改善したからなのか、予測しやすい週だけを比べたからなのか。これは、実験を支援するエージェントを考えるための想定例だ。コードが動いたことだけでは、その結果を採用する根拠にならない。

8月のGPT-5 for developersは、コードの変更や道具の呼び出しを支える機能を発表した。 Looker MCP Serverは、定義済みの指標へAIから接続する方法を公開した。 MLE-benchやRE-Benchは、データや計算資源を使い、試して結果を比べる仕事を評価している。コード、データ、分析を一緒に扱う材料が増えているが、それぞれが証明する能力は異なる。

本稿の結論は、候補を作る能力を活用しながら、その候補を採用する判断の根拠を別に整えることだ。コード、データの意味、実行条件、結果、解釈を結び付ける。次の人が同じ条件で比べられる記録までを成果物にすると、良い結果だけでなく、改善しなかった実験も次の判断へ使える。

道具がつながる

コードを変える道具と、指標を読む道具を組み合わせる

GPT-5の開発者向け発表は、コードの修正や道具を使う作業を扱う。 custom toolsでは、道具の入力をJSONではなく文字列で渡し、開発者が文法による制約を加えられる。長いコードなどを道具へ渡す形式の選択肢だ。入力形式を扱いやすくすることと、実験の設計が正しいことは別の問題である。

8月9日のLooker MCP Serverの発表は、Lookerで業務の指標や計算式を定義したモデルへ、AIから問い合わせる仕組みを示す。指標や業務上の定義に沿って、LookerがSQLを生成する。 Gemini CLI、Claude Desktop、Cursorなどから利用する構成を説明している。開発に使う環境から、共通の定義を持つデータへ接続する道がある。

こうした道具を組み合わせれば、指標を調べ、原因の候補を作り、集計や予測のコードを修正する構成を考えられる。ただし、提供機能の組み合わせは、修正によって事業の結果が良くなるという計測ではない。どのデータから何を推測し、どの実験で確かめるかを、作業のつなぎ目で保つ必要がある。

実行と成績を分ける

MLE-benchは、提出できたことと良い予測を別々に測る

MLE-benchの初版は、Kaggleから選んだ75の競技を使い、データの準備、学習、実験、予測の提出を評価する。主な実験では一競技あたり最大24時間、一台のA10 GPUを与える。 o1-previewとAIDEの組み合わせを繰り返した平均では、提出が有効だった割合は82.8%、メダル相当の成績に達した割合は16.9%だった。これらは2024年の構成の結果で、GPT-5の機械学習実験の成績ではない。

提出形式を確認する道具は、形式が有効かを返し、予測性能の点数は返さない。この区別は、動くコードを作ることと、良い結果を作ることの間に検証が必要だと分かる例である。本稿の解釈では、予測値を正しい形式で出す工程と、比較する指標を改善する工程を、同じ成功へまとめるべきではない。

また、多くの課題は学習・テストの分割を作り直し、過去の競技の順位表と比較する。実際の事業への導入が成功した割合を測るものではない。競技で高い成績を得たという証拠を、別のデータや利用条件へそのまま持ち込まず、評価の対象を明示して読む必要がある。

研究の目的を読む

RE-Benchの課題は、速く動くだけでは満たせない

RE-Benchの初版は、七つの機械学習の研究・開発課題を評価する。たとえばOptimize LLM Foundryは、学習スクリプトの動作を変えずに実行時間を減らす課題だ。時間だけが短くなっても、必要な処理を省いて動作を変えれば、目的を満たしていない。論文は、採点で良く見える抜け道が、人の確認では課題のルールに反していた例も報告する。

この例から実験支援へ引き継ぎたいのは、改善する指標と、変えてはいけない条件を一緒に定める考え方だ。予測の誤差を減らす実験でも、必要な期間を除外したり、予測する時点には分からない情報を使ったりすれば、同じ課題を解いたことにならない。採点が良いという説明を、その条件へ戻して読む必要がある。

RE-Benchも、明確な目的を持つ短い課題が、何か月も続く研究の全体を覆うとはしていない。研究の問いや評価指標を選ぶことと、与えられた課題を改善することは異なる。実験を速く回せる能力を、研究の目的まで自動で正しく決める能力へ広げて評価しないことが重要になる。

データの意味を保つ

同じ「売上」でも、期間や対象をそろえて読む

Lookerのように指標の定義を共有する仕組みは、担当者ごとに別の集計式を作る問題を抑えるための選択肢になる。しかし、定義された指標を取得できても、比較する対象や、差の原因まで同じになるわけではない。利用者がその値から何を判断したいかを、データの取得と結び付ける必要がある。

ここでは、店舗の売上を比べる想定例を考える。注文した日と売上が確定した日、返品を含めるか、どの店舗を対象にするかが違えば、同じ名前の表でも結論は変わり得る。取得した指標の定義、期間、絞り込み条件を記録すれば、コードを修正した後にも、同じ問いを比較したか調べられる。

データの変化と、原因の説明も分けたい。売上が増えたという集計から、キャンペーンが増加を引き起こしたと自動で結論付けることはできない。季節や店舗の構成など、別の説明も考える必要がある。エージェントが原因の候補を出すなら、観測した差と、まだ確かめていない仮説を分けて残す。

予測を公平に比べる

需要予測の実験では、予測する時点へ条件を戻す

冒頭の需要予測を設計するなら、いつまでのデータで、どの先の期間を予測するかを先に決める。たとえば、前週の同じ曜日の売上を使う単純な基準と、候補のモデルを同じ期間で比べる。予測を作る時点では未知の実売上を、候補だけの入力へ加えない。これは本稿の比較案で、特定企業の運用実績ではない。

欠損値の扱い、特徴量、学習と検証の期間、評価指標、計算時間の上限を、結果とともに保存する。たとえば平均絶対誤差で比べるなら、予測と実績の差の大きさを、同じ対象と期間で計算する。平均が改善しても、忙しい日や一部の店舗で悪化していないかを調べる。発注へ使うなら、平均の改善だけで採用を決めるとは限らない。

売り切れた商品の販売数も、欲しかった人の数をそのまま表すとは限らない。観測した売上と、推定したい需要の違いを説明せずに学習すると、良い点数でも利用したい判断とはずれる可能性がある。 AIがデータを処理できるかに加え、目的に対して何を測れているかを人が検討する必要がある。

結果を引き継ぐ

改善しなかった実験も、理由が分かれば次の仕事に使える

実験の成果物には、コードの版、データの取得条件、依存関係、モデルの設定、計算資源、結果を結び付ける。乱数を使う処理ではその設定も残すが、乱数の設定だけで同じ結果が必ず再現するとは扱わない。環境や実行条件による変動が残るなら、再実行の差を確認する。別の人が結果を読み、必要な検証を続けられる記録が重要になる。

候補が基準より悪かった場合も、試した条件を残せば、次に同じ案を再び試すべきか判断できる。どこで悪化したのか、時間や資源を増やす余地があるのかを説明する。失敗した実行と、正常に実行して改善しなかった結果も区別する。後者を消して良い結果だけを残すと、実験の全体を読めなくなる。

採用の判断では、予測の成績に加え、費用、必要な更新頻度、悪化した対象への影響、追加検証を考える。これは本稿の判断案であり、公開資料で自動採用の成果が証明されたという主張ではない。エージェントには候補の作成と比較の記録を任せ、人が結論を確かめるための材料を整える構成から始められる。

判断できる成果物