---
title: "実験管理とは？記録項目とrun設計・導入判断を実装目線で解説【2026年版】"
url: "https://www.issoh.co.jp/tech/details/16340/"
published: 2026-08-09
updated: 2026-10-21
categories: ["AI"]
publisher: "株式会社一創"
---

# 実験管理とは？記録項目とrun設計・導入判断を実装目線で解説【2026年版】

実験管理は、1回の学習実行に紐づくパラメータ・評価指標・成果物を機械可読な形で残し、数週間後の自分やチームの誰かが同じ結果に到達できる状態を保つ仕組みです。この記事では、記録すべき対象を5系統に分けて具体的な項目名まで落とし込み、runとexperimentをどの粒度で切るか、MLflow 3.15系で2つのストアをどう分離するかを実装目線で示します。表計算ソフトでの記録が実務上どこで破綻するか、逆に実験管理を入れない方が速い案件はどれかも、実験本数と担当者数という数字で線を引きます。製品ごとの機能比較や料金には踏み込みません。

## まとめ：実験管理の導入判断と最小構成で記録する5項目

結論から示します。実験管理で最初に固めるべきは、ツール選定ではなく記録項目の設計です。最小構成は、ハイパーパラメータ、評価指標、学習に使ったデータの識別子、コードのコミットハッシュ、実行環境のライブラリ版という5系統。この5つが揃っていれば、半年前のrunでも同じ数字を再現できます。逆にツールだけ導入して記録項目が場当たりだと、run数だけが積み上がって検索できないダッシュボードが残ります。

導入の判断は、実験本数と担当者数で決まります。目安は「週あたり10run以上」または「同じモデルに2名以上が触る」。どちらかを満たしたら記録の自動化に移り、どちらも満たさない単発のPoCなら、表計算ソフトの1シートで十分です。記録項目を増やしすぎて更新が止まる失敗のほうが、記録が足りない失敗より現場では多く見られます。

ツールはMLflowから始めるのが手堅い選択です。保存先はファイルシステムから後で移せます。判断者向けの全体像は[MLOpsの運用体制と導入判断](https://www.issoh.co.jp/column/details/2939/)で整理しています。

## 実験管理の定義と守備範囲｜学習ジョブの記録が担うMLOps工程の切り分け

実験管理という言葉は、experiment tracking の訳語として機械学習の文脈で使われます。対象は学習ジョブに限定され、モデルを本番へ出したあとの工程は別の仕組みが受け持つ領域です。この境界を曖昧にしたまま導入すると、責任範囲の重複した設計になります。

### 実験管理が扱う対象｜1回の学習実行を再現可能な単位で残す記録範囲

MLflowの公式ドキュメントは、Trackingの記録対象を parameters・code versions・metrics・output files のメタデータ、Models、Datasets、Tags、System Tags と整理しています。噛み砕くと、入力（何を渡したか）・処理（どのコードで動かしたか）・出力（どんな数字と成果物が出たか）の3点を、1回の実行単位で束ねる作業です。

この単位をrunと呼びます。1runは1つの学習実行に対応し、開始時刻・終了時刻・実行ユーザー・ステータスが自動で付きます。学習を10回試したら10run。ここで「10回の平均値だけ残す」といった集約をすると、あとから条件を切り分けられなくなります。生のrunを残し、集約はダッシュボード側でやる。この順序を崩さないでください。

### モデルレジストリ・モデル監視との責任分担｜学習の前後で引く境界線

実験管理の下流には2つの工程があります。学習が終わって「このrunのモデルを本番へ出す」と決めた瞬間からはモデルレジストリの領分で、版番号・承認者・ステージが管理対象になります。設計の勘所は[モデルレジストリの版管理と本番昇格](https://www.issoh.co.jp/tech/details/16082/)にまとめました。

本番稼働後の劣化検知はさらに別です。入力分布のずれや精度低下を測る話は[ドリフト検知の指標としきい値設計](https://www.issoh.co.jp/tech/details/16338/)が扱います。3工程の分担を一文で言うなら、実験管理は「作る過程を残す」、レジストリは「出すものを決める」、監視は「出したあとを見る」。MLflow 3系ではログ済みモデルに固有のモデルIDが割り当てられ、実験管理側のrunとレジストリ側の登録モデルが同じIDで追跡できるようになりました。

### 表計算ソフトの記録が破綻する条件｜実験本数と担当者数のしきい値

スプレッドシートでの記録は、実験本数が少ないうちは機能します。破綻の引き金になるのは、記録漏れではなく突合不能です。具体的には次の3つが同時に起きたとき。

- 1週間の学習実行が10回を超え、手入力が実行に追いつかなくなる
- 担当者が2名以上になり、列の意味と単位の解釈がずれる
- ハイパーパラメータの探索を自動化し、1回のジョブで数十runが生成される

3つ目が入った時点で手入力は成立しません。探索ジョブは人間が待っていない時間に数十件のrunを吐き出すからです。週10runは担当者1名が日次で2回まわす水準で、多くのチームが最初に踏む線になります。

## 再現性が壊れる4つの断層｜コード・データ・環境・乱数の記録漏れ対策

「同じスクリプトを流したのに数字が合わない」という相談の原因は、ほぼ4つに分類できます。パラメータの記録漏れではなく、パラメータ以外の変数が記録から抜けていることが真因です。

### コードと乱数シードの固定｜git commitとseedを記録する具体的な項目

コードの版は、ファイル名でもブランチ名でもなくコミットハッシュで残します。MLflowはシステムタグとして `mlflow.source.git.commit` と `mlflow.source.git.branch`、実行スクリプトの `mlflow.source.name`、実行者の `mlflow.user` を自動で付与する仕様です。git管理下から実行するだけで、この4つは手を動かさずに残ります。

乱数シードは自動では残りません。データ分割・重み初期化・シャッフル・ドロップアウトと、乱数を使う箇所はフレームワーク内に散らばっています。単一のseed値をパラメータとして明示的に記録し、各ライブラリの乱数生成器へ渡す関数を学習コードの入口に1つ置いてください。GPUでの畳み込み演算は決定的動作を明示しない限り実行ごとに微差が出るため、シードだけで完全一致を期待しないこと。小数点以下3桁で一致すれば実務上は再現とみなす、といった許容幅をチームで決めておきます。

### データ版の記録｜学習に使った行の範囲と抽出条件を残す2つの方法

再現不能の最大の原因はデータです。同じSQLを流しても、テーブルは日々更新されます。対処は2通り。

1つ目は、抽出条件そのものを記録する方法。抽出日時、WHERE句の条件、対象期間、行数、主要カラムの統計量をパラメータとして残します。既存のデータ基盤に手を入れずに始められる軽量な方式です。MLflowには入力データセットを記録する `log_input` があり、Datasetsとして扱えます。

2つ目は、データそのものに版を付ける方法。DVCはgitと同じ操作感でデータファイルの版を管理し、実体をオブジェクトストレージへ逃がします。PyPI表示の最新は3.67.1、対応はPython 3.9以上（2026年8月時点）。学習用の特徴量を組織横断で共有する段階まで来ているなら、[特徴量ストアの二層構成と導入判断](https://www.issoh.co.jp/tech/details/16334/)が扱う仕組みのほうが管理コストは下がります。判断基準は単純で、データ量が数GB以下で1チーム完結ならDVC、複数チームが同じ特徴量を参照するなら特徴量ストア側です。データ側に版を付ける方式そのものの構造差と選び方は、[データバージョニングの方式別設計と選定基準](https://www.issoh.co.jp/tech/details/16342/)で整理しています。

### 実行環境の記録｜ライブラリ版とGPU構成が結果を変える場面の対処

ライブラリの版差は数値に効きます。勾配ブースティング系は既定のハイパーパラメータがマイナー版で変わることがあり、同じ設定値を渡したつもりで別の学習をしている状態が起こり得ます。ロックファイルの内容か、少なくとも主要ライブラリの版番号をrunのタグとして残してください。

コンテナで学習を回しているなら、MLflowのシステムタグ `mlflow.docker.image.name` にイメージ名が記録されます。イメージタグを latest のまま運用すると、同じ名前で中身が入れ替わって記録の意味が失われます。ダイジェスト付きの参照か、日付入りのタグを使うこと。GPU構成も記録対象で、CUDAの版と搭載GPU名が変われば、決定的動作を指定していない限り数値の微差は避けられません。

## 記録項目の設計指針｜params・metrics・artifacts・tagsの粒度と命名

MLflowの記録APIは `log_param`・`log_metric`・`log_artifact`・`set_tag`・`log_input` と、それぞれの複数形版が用意されています。APIの数は少なく、迷うのは「どれに何を入れるか」の設計です。

### paramsとmetricsの切り分け｜実行前に決まる値と実行後に出る値

判定基準は時制で決まります。実行前に決まっている値がparams、実行の結果として出てきた値がmetrics。学習率・木の深さ・エポック数・データ分割比率はparams、精度・損失・AUC・学習時間はmetricsです。

この切り分けを守る理由は、検索の挙動が違うからです。paramsは文字列として保存され完全一致で絞り込む対象、metricsは数値として保存され大小比較とソートの対象になります。学習率をmetricsに入れてしまうと条件で絞れず、精度をparamsに入れると上位10件を並べられません。metricsは時系列でも記録でき、`log_metric` のstep引数に64ビット整数を渡せばエポックごとの学習曲線が残ります。損失は最終値だけでなくstep付きで残してください。過学習の発生点は最終値からは読めません。

### artifactsに残す成果物｜モデル本体と評価図表の保存範囲の決め方

artifactsはファイルの置き場です。モデルの重み、混同行列やROC曲線の画像、予測結果のCSV、特徴量重要度の表が該当します。判断に使った図表は残す。中間生成物は残さない。この2行で足ります。

容量の見積もりを最初にやってください。深層学習モデルは1runあたり数百MBに達することがあり、探索ジョブで数十run生成すれば1回で数十GBです。保存期間を決めずに走らせるとストレージ費用が想定を超えます。実務では「上位10runのモデル本体だけ残し、残りはmetricsと図表のみ」という運用に落ち着くことが多く、これを最初から規則にしておくと後始末が減ります。

### tagsによる検索性の担保｜後から絞り込むための命名規則の作り方

tagsは後付けの分類ラベルです。paramsと違い実行後にも書き換えられるため、「本番候補」「再現確認済み」といった運用上の状態を持たせられます。MLflowは `mlflow.note.content` というシステムタグでrunへのメモも保持します。

命名規則は最初に3つだけ決めてください。区切り文字（アンダースコアかドットか）、接頭辞の体系（案件名や課題名を先頭に置くか）、値の語彙（真偽値を true と false に統一するか yes と no にするか）。この3つが揃わないまま数百runが溜まると、絞り込みのたびに表記ゆれを手で吸収することになります。1人で回している時期に決めておくのが結局いちばん安く済みます。

## runとexperimentの階層設計｜1実験1runで比較可能性を保つ運用規則

MLflowはrunの上位にexperimentという入れ物を持ちます。この2階層をどう切るかで、半年後の検索性が決まります。

### run粒度の基準｜交差検証と探索ジョブをnested runで束ねる設計

原則は「1回の学習実行＝1run」です。判断が割れるのは交差検証とハイパーパラメータ探索の2つ。5分割の交差検証を1runにまとめると分割ごとのばらつきが見えず、5runに分けると探索全体の比較がしにくくなります。

解決策は入れ子です。MLflowは `start_run` のnested引数で親子関係を作れ、子runにはシステムタグ `mlflow.parentRunId` が入ります。親runに5分割の平均と標準偏差、子runに各分割の値を置く。探索ジョブも同じ形で、親に探索設定、子に試行ごとの結果を残します。試行予算の決め方と打ち切りの設計は[ハイパーパラメータ探索の手法と打ち切り設計](https://www.issoh.co.jp/tech/details/16351/)にまとめています。この形にしておくと、ダッシュボードの一覧は親runだけで見渡せて、掘り下げたいときだけ子を開けます。

### experimentの切り方｜課題単位で分けて横断比較を壊さない基準

experimentは予測課題の単位で切ります。「解約予測」「需要予測」のように、目的変数と評価指標が同じものを1つにまとめる。これを月単位やモデル種別で切ると、同じ課題の結果が複数の入れ物に分散して横断比較ができなくなります。

担当者ごとに切るのも避けてください。属人化を減らすために入れた仕組みが、担当者名で分断されては本末転倒です。人・時期・モデル種別といった軸は、experimentではなくtagsで表現する。experimentは課題、tagsはそれ以外の切り口。この2行を規約に書いておけば運用は揺れません。

### 自動記録と手動記録の使い分け｜autologで漏れる項目の補い方

MLflowの `autolog` は、対応ライブラリの学習呼び出しをフックしてパラメータと指標を自動で記録します。公式が挙げる対応は Scikit-learn・XGBoost・LightGBM・PyTorch・Keras・TensorFlow・Spark ほか。1行入れるだけで記録が始まるため、導入初日はこれで足ります。

ただしautologが拾うのはライブラリの内部で見える値だけです。前処理のパラメータ、データ抽出条件、乱数シード、業務側の評価指標（想定削減コストなど）は対象外で、明示的に記録する必要があります。実務での型は「autologで土台を作り、抜けた項目を手動で足す」の二段構え。最初から手動で全部書こうとすると記述量が増え、記録が更新されなくなる原因になります。

## MLflow 3.15系での実装手順｜2つのストア構成とサーバ分離の判断

MLflowはPyPI表示の最新が3.15.1（2026年8月時点）。導入で押さえるのはAPIの使い方より、保存先の構成です。ここを個人検証のまま共有環境に持ち込むと、後から移行工数が発生します。

### backend storeとartifact store分離｜個人検証から共有環境へ移行

MLflowの保存先は2つに分かれています。公式ドキュメントの整理では、Backend Store が run のID・パラメータ・指標といったメタデータを永続化し、ファイルシステム型またはデータベース型を選択可能です。Artifact Store はモデルの重み・画像・Parquetファイルなど大容量のファイルを保持し、既定はローカル、S3やAzure Blob Storageにも対応します。

| 段階    | backend store | artifact store | 移行の手間       |
| ----- | ------------- | -------------- | ----------- |
| 個人検証  | ローカルファイル      | ローカルディスク       | —           |
| チーム共有 | PostgreSQL    | S3等のストレージ      | run履歴の移送が必要 |
| 全社基盤  | マネージドDB       | ストレージ＋権限設計     | 認証基盤との接続    |

チーム共有の段階へ進むタイミングで、追跡サーバを学習実行マシンから切り離します。学習用インスタンスは止めたり作り直したりする対象なので、記録が同居していると停止と同時に履歴が消えます。2人目が触り始めた時点で分離するのが実務上の分岐点です。

### 記録の実装順序｜既存の学習コードに5行で組み込む導入ステップ

既存コードへの組み込みは、次の順序で進めると手戻りがありません。

1. 追跡サーバのURIとexperiment名を学習スクリプトの先頭で指定する
2. autologを有効化し、学習の呼び出しを実行ブロックで囲む
3. ダッシュボードでrunが1件記録されたことを確認する
4. 前処理パラメータと乱数シードを手動で追記する
5. 評価図表と業務指標をartifactsとmetricsに足す

手順3までで一度止めて、記録が残ることを目で確かめてください。ここを飛ばして5まで書いてから動かすと、記録されない原因がコードの問題かサーバ接続の問題か切り分けられなくなります。所要は既存スクリプト1本あたり半日程度。学習コードの構造には手を入れません。

### ツール選定の分岐｜OSS自前運用とホスト型サービスのコスト比較

MLflowを自前で運用するか、ホスト型のサービスを契約するかは、人件費とサーバ費の比較で決まる問題です。自前運用はサーバ費だけなら小さく収まる一方、DBのバックアップ・版上げ・認証の維持が担当者の作業として残ります。ホスト型はシート課金とストレージ課金が乗る代わりに、その作業が消えます。

製品ごとの守備範囲と料金は[Weights & Biasesの実験管理と料金体系](https://www.issoh.co.jp/tech/details/16077/)と、製品横断で選定基準を整理した[MLOpsツール比較と最小構成の指針](https://www.issoh.co.jp/tech/details/15341/)で扱っています。判断の目安を1つ挙げるなら、インフラ運用の専任者がいない5名以下のチームなら、自前運用の維持工数は想定より重くなります。

## 実験管理を導入すべき条件と見送る場面｜記録が負債に変わる境界

ここは言い切ります。実験管理はすべての機械学習案件に必要な仕組みではありません。

### 導入してよい3条件｜実験本数・担当者数・再現要求の具体的な水準

次のいずれかを満たしたら導入してください。週あたりの学習実行が10回を超えたとき。同じモデルに2名以上が触るとき。契約や監査で学習条件の説明責任が生じるとき。3つ目は金融・医療・公共の案件で実際に発生し、「なぜこのモデルを選んだか」を後から示せる記録が要求されます。

見落とされやすいのは、条件を満たしているのに導入されていない状態です。1名でも週20run回していれば記憶では追えません。機械学習モデルの受託開発では、記録設計を初期構築の一部として組み込みます。仕組みの相談は[機械学習モデル開発の相談窓口](https://www.issoh.co.jp/service/ai/machine-learning/)から受け付けています。

### 見送ってよい場面｜1回限りの検証と分析レポートで終わる案件の条件

見送ってよい類型は2つあります。1つは、実現可能性を確かめるだけで終わり、モデルを継続運用しないPoC。数式が回ることを示すのが目的で、成果物はレポートです。ここに追跡サーバを立てるのは過剰投資で、ノートブックの実行結果を残せば足ります。

もう1つは、モデルが単発の分析手段でしかない案件。「今年のデータで一度だけ要因分析する」といった仕事は、再学習も再現要求も発生しません。この2類型で実験管理を入れると、記録を維持する作業だけが残ります。判断は「3か月後に同じモデルをもう一度学習し直す可能性があるか」で切ってください。可能性がゼロなら入れない。

### 導入時の失敗パターン｜記録項目を増やしすぎて更新が止まる運用例

現場で最も多い失敗は、記録が足りないことではありません。初期設計で記録項目を30個並べ、手動記載の負担に耐えられず3か月で誰も更新しなくなる。半端に古い記録は、記録がない状態より判断を誤らせます。

回避策は、手動記録を5項目以内から始めることです。autologで自動化できる範囲は自動に任せ、手で書くのは前処理条件・データ抽出条件・乱数シード・業務指標・実験の意図メモに絞る。3か月運用して足りない項目が明確になってから足せば、増やした分は使われます。

## よくある質問

実験管理の導入検討で実際に寄せられる質問を5つ挙げます。

### 実験管理ツールを入れずに表計算ソフトで続けるとどうなりますか？

実験本数が少ないうちは問題なく回ります。破綻するのは、ハイパーパラメータ探索を自動化した時点です。1回のジョブで数十runが生成されるため、手入力が追いつきません。週10run未満・1名体制であれば、表計算ソフトの1シートで十分機能します。判断は人数ではなく実行本数で行ってください。

### MLflowとホスト型サービスはどちらを選べばよいですか？

まずMLflowをローカルで動かし、記録項目の設計を固めることを勧めます。この段階で必要な項目が見えてから、自前運用を続けるかホスト型へ移るかを判断すれば、選定のやり直しが起きません。分岐の目安は、インフラ運用の専任者がいるかどうかです。

### 実験管理とモデルレジストリは何が違うのですか？

対象とする時点が違います。実験管理は学習の過程を記録する仕組みで、失敗したrunも含めてすべてを残します。モデルレジストリは、その中から本番へ出すモデルを選び、版番号と承認状態を管理する仕組みです。実験管理には数百のrunがあり、レジストリに登録されるのはそのうち数件。MLflow 3系ではログ済みモデルに固有のIDが付き、両者を同じIDで追跡できます。

### 記録した実験データはどのくらいの期間保存すべきですか？

メタデータと成果物で分けて考えます。パラメータと指標はテキストなので容量が小さく、案件が続く限り残して差し支えありません。容量を圧迫するのはartifactsで、深層学習のモデル重みは1runあたり数百MBに達します。監査要件がある案件では、契約で定めた保存年限に合わせてください。

### 学習コードを大きく書き換える必要はありますか？

ありません。autologを1行有効にし、学習の呼び出しを実行ブロックで囲むところから始められます。書き換えが必要になるのは、乱数シードを1か所に集約する場合くらいです。この作業自体が再現性の改善につながるため、実験管理の導入と合わせて済ませるのが効率的です。

## 関連記事

- [モデルレジストリとは？版管理と本番昇格](https://www.issoh.co.jp/tech/details/16082/)：学習後にモデルを選ぶ工程です。
- [モデルモニタリングとは？ドリフト検知](https://www.issoh.co.jp/tech/details/16338/)：本番稼働後の劣化を測ります。
- [特徴量ストアとは？二層構成と導入判断](https://www.issoh.co.jp/tech/details/16334/)：特徴量の版と鮮度を管理します。
- [Weights & Biasesとは？仕組みと料金](https://www.issoh.co.jp/tech/details/16077/)：ホスト型製品の詳細を扱います。
- [MLOpsツール比較｜選定基準と最小構成](https://www.issoh.co.jp/tech/details/15341/)：製品横断の選び方を整理しています。
- [交差検証とは？分割手法とリーク対策](https://www.issoh.co.jp/tech/details/16353/)：記録すべき分割条件を整理します。
- [Optunaとは？v5.0の既定TPE変更と枝刈り](https://www.issoh.co.jp/tech/details/18671/)：探索の試行履歴を残す道具を扱います。

---

出典: [実験管理とは？記録項目とrun設計・導入判断を実装目線で解説【2026年版】](<https://www.issoh.co.jp/tech/details/16340/>)（株式会社一創）