Azure ML Studioでジョブ自体は成功し、メトリクスも確認できるのに、Parallel Coordinates（並列座標）チャートだけ「Primary metric」や「Select columns」が反応しない。これは不具合ではなく、機能の前提条件が原因です。使える条件と設定手順、代替手段をまとめます。
発生している症状を整理
Azure Machine Learning（Azure ML）では、ジョブ画面の「Metrics」や「Charts」でさまざまな可視化ができます。ところが並列座標チャート（Parallel coordinates）だけ、次のような挙動になることがあります。
- パイプライン／実験ジョブは正常に完了し、ジョブ画面でメトリクス値も確認できる
- 散布図（Scatter）など他のチャートでは、メトリクスや列の選択ができる
- 一方、Parallel coordinates を追加すると「Primary metric（主指標）」をクリックしても何も起きない
- 「Select columns（列を選択）」をクリックしても何も起きない
| 確認ポイント | 期待する状態 | 今回の現象 |
|---|---|---|
| ジョブは成功しているか | Completed でエラーなし | 成功している |
| メトリクスは記録されているか | ジョブ詳細で metrics が見える | 見えている |
| 他チャートのドロップダウン | 列／メトリクスを選べる | 選べる |
| Parallel coordinates のドロップダウン | 主指標と軸（列）を選べる | クリックしても反応しない |
結論：Parallel coordinates は「スイープ（ハイパーパラメータチューニング）ジョブ専用」
Azure ML Studio の Parallel coordinates（並列座標）チャートは、ハイパーパラメータチューニング（スイープ）ジョブの結果を見比べるための可視化として実装されています。つまり、次のようなジョブでは前提を満たしません。
- 通常のトレーニングジョブ（単発の command job）
- パイプラインジョブ（pipeline job）の中で単純に学習を回しているだけ
- 自前で for ループしてパラメータを振り、MLflow にログを残しているだけ
これらのジョブでもメトリクスは保存できますが、Studio の並列座標は「スイープジョブとして登録された試行（Trial）群」を前提に、主指標や探索したハイパーパラメータ列を引っ張ってきます。そのためスイープ扱いになっていないジョブではドロップダウンが反応しない（または選択肢が出ない）という状態になります。
| ジョブの種類 | メトリクス表示 | Parallel coordinates | 備考 |
|---|---|---|---|
| 単発トレーニング（command job） | 〇 | × | 比較対象の試行が1つのため、並列座標の想定外 |
| パイプライン（pipeline job） | 〇 | ×（基本） | パイプライン全体のメトリクスは見えても、スイープの「試行群」として扱われない |
| 自前スイープ（ループ + MLflow ログ） | 〇 | × | MLflow に残っても、Azure ML のスイープメタデータがない |
| スイープ（Hyperparameter tuning / Sweep job） | 〇 | 〇 | Primary metric と探索パラメータが UI に連動する |
Parallel coordinates が得意なこと
並列座標は「複数の条件（ハイパーパラメータ）と結果（メトリクス）を同時に見比べる」ための可視化です。スイープと相性が良いのは、1本の線が 1 Trial を表し、線の集合として“どの設定が良かったか／悪かったか”を俯瞰できるからです。
- 学習率・正則化・バッチサイズなど、複数のハイパーパラメータの影響を一度に把握しやすい
- 「精度は上がるが学習時間も伸びる」など、トレードオフの傾向が見つけやすい
- 外れ値（極端に悪い Trial）を見つけて原因調査につなげやすい
逆に、Trial が1つしかない／探索したパラメータが定義されていない状態では、並列座標にする意味が薄く、UI も想定通りに動作しません。
なぜ「自前ループ + MLflowログ」では動かないのか
「MLflow にパラメータもメトリクスも記録しているのに、なぜ並列座標に出ないのか？」という疑問がよく出ます。ここで重要なのは、並列座標チャートが参照している情報が単なるメトリクス一覧ではない点です。
Parallel coordinates は概ね次の情報が揃っていることを前提にしています。
- 試行（Trial）が複数ある：同じ学習を異なるパラメータで何度も実行した集まり
- 探索したハイパーパラメータの定義：どのパラメータを、どの範囲（Choice / Uniform 等）で探索したか
- 最適化する目的（Objective）：Primary metric と最小化／最大化の方向
- Trial 単位のログ：各 Trial のパラメータとメトリクスが紐づいている
| やっていること | MLflow的には可能 | Azure ML Studio（Parallel coordinates）的には |
|---|---|---|
| for ループで複数回学習 | 〇 | ×（スイープとして認識されない） |
| mlflow.log_param / log_metric | 〇 | △（ログがあっても UI が参照する構造がないと使えない） |
| 親 run の下に子 run をネスト | 〇 | △〜×（ネスト＝スイープではない） |
自前ループの場合、MLflow で似た情報を残せますが、Azure ML の UI は「これはスイープジョブで、その下に Trial が並んでいる」というジョブ構造（メタデータ）を見て動きます。ジョブ種類がスイープとして登録されていないと、UI 側がデータを取りに行く先がなく、ドロップダウンが沈黙しやすい…というのが実態です。
並列座標チャートを使うために必要なこと
結論を実務に落とすと、やることはシンプルです。学習を Azure ML のスイープジョブとして実行するだけです。以下は「最短で動かす」ための手順です。
前提：学習処理をパラメータ化しておく
スイープは Trial ごとに引数を変えて学習を回します。まずは学習スクリプト（例：train.py）が、学習率やバッチサイズなどをコマンド引数で受け取れる状態にします。
- 例：
--learning_rate、--batch_size、--dropoutなど - Trial ごとに変えたいものは「引数」で受け取るのが基本
- メトリクスは Trial 内で
mlflow.log_metric()などで記録
探索戦略を選ぶ
スイープの戦略は「とにかく広く探す」「賢く絞り込む」など目的で使い分けます。迷ったらまずはランダムサーチ（random）から始め、当たりが見えてきたらベイズ最適化に切り替えるのが現実的です。
| 戦略 | 特徴 | 向いているケース |
|---|---|---|
| random | 指定範囲からランダムに試す | まず全体像を掴みたい／パラメータ数が多い |
| grid | 格子状に全組み合わせを試す | 候補が少ない／厳密に比較したい |
| bayesian | 過去結果から有望な領域を重点探索 | 試行回数を抑えつつ最適化したい |
スイープジョブとして送信する
Azure ML v2（CLI v2 / YAML）では、sweep ジョブを YAML で定義して実行するのが分かりやすいです。以下はイメージのサンプルです（ワークスペース名やパス、environment/compute の指定は環境に合わせて調整してください）。
# sweep-job.yml（例）
$schema: https://azuremlschemas.azureedge.net/latest/sweepJob.schema.json
type: sweep
display_name: train-sweep-example
experiment_name: my-experiment
# 最適化したい指標（Primary metricに対応）
objective:
goal: maximize
primary_metric: validation_accuracy
# 探索戦略
sampling_algorithm: random
# 試行回数など
limits:
max_total_trials: 20
max_concurrent_trials: 4
# Trialで実行する学習ジョブ
trial:
type: command
code: ./src
command: >
python train.py
--learning_rate ${{search_space.learning_rate}}
--batch_size ${{search_space.batch_size}}
--dropout ${{search_space.dropout}}
environment: azureml:AzureML-sklearn-1.0-ubuntu20.04-py38-cpu:1
compute: azureml:cpu-cluster
# 探索するハイパーパラメータ
search_space:
learning_rate:
type: uniform
min_value: 0.0001
max_value: 0.1
batch_size:
type: choice
values: [16, 32, 64, 128]
dropout:
type: uniform
min_value: 0.0
max_value: 0.5送信は次のような形になります。
az ml job create -f sweep-job.yml -g <resource-group> -w <workspace-name>ポイントは、YAML に type: sweep と objective.primary_metric と search_space が含まれていることです。これが Studio の Parallel coordinates に必要な「スイープとしての構造」を作ります。
Studioで並列座標チャートを表示する
スイープジョブを実行したら、Azure ML Studio（Azure ML Studio / Machine Learning Studio）のジョブ画面で次の操作をします。ジョブ詳細の中に「Trials」や「Child jobs」が見える場合は、スイープとして正しく作成できています。
| 操作 | 画面 | 補足 |
|---|---|---|
| スイープジョブを開く | Jobs | ジョブ種類が Sweep / Hyperparameter tuning になっているもの |
| チャート領域へ移動 | Charts / Visualizations | UI文言は環境で多少異なる |
| タイルを追加 | Add a tile（タイルを追加） | 右上またはチャート領域に表示されることが多い |
| Parallel Coordinates を選択 | 可視化の種類 | Scatter などと同じ並びにある |
| Primary metric を選ぶ | チャート設定 | objective.primary_metric が候補に出る |
| Select columns を選ぶ | チャート設定 | search_space のパラメータやログ列が候補に出る |
この状態であれば、「Primary metric」「Select columns」のドロップダウンが有効になり、並列座標チャートが描画されます。逆にここで反応しない場合は、ほとんどが「そもそもスイープジョブとして認識されていない」か「Trial が取れない」状態です。
ドロップダウンが反応しないときのチェックリスト
「スイープで出したはずなのに動かない」「動いたり動かなかったりする」という場合に備えて、現場で効く確認項目をまとめます。
| 症状 | よくある原因 | 確認・対処 |
|---|---|---|
| Parallel coordinates のドロップダウンが無反応 | ジョブ種類がスイープではない | ジョブ詳細で type / Job type を確認し、type: sweep で再実行 |
| 候補が空／少ない | objective.primary_metric が未設定、または Trial でメトリクスをログしていない | YAML の objective を設定し、train.py 内で validation_accuracy をログ |
| Trial はあるが線が少ない | 途中失敗の Trial が多い | compute の枯渇、データパス、依存関係を見直し、成功 Trial を増やす |
| パラメータが軸に出ない | search_space に定義していない／型が扱いにくい | 探索するものは必ず search_space に入れる。カテゴリ値は choice を使う |
| メトリクスは見えるが Trial と紐づかない | 親ジョブ側にだけログしている | 集計用の親処理ではなく、Trial の学習処理内でログする |
| UI の反応が不安定 | ブラウザ拡張・キャッシュ・企業プロキシの影響 | 別ブラウザ/シークレットで確認。広告ブロッカー等を一時停止 |
自前スイープを続けたい場合の代替案
事情があって Azure ML のスイープ機能に乗せ換えにくいケースもあります。たとえば、独自の探索ロジック（進化戦略、独自早期終了、外部サービス連携など）を持っている場合です。その場合は、Studio の Parallel coordinates にこだわるより、別の手段で並列座標プロットを作る方が早いことが多いです。
Python（pandas + plotly）で並列座標を作る
MLflow にログしているなら、MLflow の検索結果を DataFrame にして plotly で並列座標を描けます。Azure ML の UI に依存しないため、パイプラインでも自前ループでも同じ方法で再現できます。
import mlflow
import pandas as pd
import plotly.express as px
# 例：特定実験の run を取得（環境に合わせて検索条件を調整）
runs = mlflow.search_runs(
experiment_names=["my-experiment"],
filter_string="attributes.status = 'FINISHED'"
)
# パラメータ・メトリクス列を抽出（列名はログした名前に合わせる）
cols = [
"params.learning_rate",
"params.batch_size",
"params.dropout",
"metrics.validation_accuracy",
"metrics.validation_loss",
]
df = runs[cols].copy()
# 文字列になっている数値を数値に変換（必要に応じて）
for c in df.columns:
df[c] = pd.to_numeric(df[c], errors="ignore")
fig = px.parallel_coordinates(
df,
dimensions=cols,
color="metrics.validation_accuracy"
)
fig.show()運用上のコツは次の通りです。
- 並列座標は軸が多いと読みにくいので、まずは5〜8列程度に絞る
- カテゴリ値（optimizer など）は数値にエンコードするか、別の切り口（フィルタ）で扱う
- 欠損が多い列は一度外して、まず“描ける状態”を優先する
Power BI や他のBIツールで可視化する
チーム共有やダッシュボード化を重視するなら、メトリクスを CSV / Parquet に出して Power BI に取り込む運用も現実的です。並列座標に限らず、フィルタやスライサーで「条件を絞って比較」できるメリットがあります。
| 方法 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Notebookで plotly | 分析者が自分で掘る | 自由度が高い／すぐ試せる | 共有には工夫が必要 |
| Power BI | 組織で継続運用 | 共有・権限・更新が強い | 可視化要件に合わせた整形が必要 |
| 外部DB（ADXなど）に蓄積 | 大量実験を横断分析 | 検索性／集計性能が高い | データ設計・運用コストが増える |
スイープジョブ運用で差がつく実践ポイント
Parallel coordinates を「見える」状態にするだけならスイープジョブでOKですが、実際に役立つ可視化にするには、ログ設計が重要です。あとから比較しやすいように、次のポイントを意識すると失敗が減ります。
メトリクス名を固定し、目的指標を明確にする
- Primary metric にする名前（例：validation_accuracy）を最初に決め、コードでもYAMLでもブレさせない
- 「accuracy」「val_acc」「valid_acc」など似た名前を乱立させない
- 最適化方向（最大化／最小化）と整合する値をログする
Trialごとに必ずログが残るようにする
- 例外で落ちた Trial はメトリクスが欠けるため、並列座標がスカスカになる
- 学習開始直後に「設定値（ハイパーパラメータ）」をログしておくと、途中失敗でも原因追跡しやすい
- 再現性のために seed、データバージョン、前処理のフラグなどもログに含める
数値・カテゴリの扱いを整理する
- 並列座標は軸が数値として扱えると読みやすい
- カテゴリ（例：optimizer=adam/sgd）は choice で探索し、表示上は選択肢が分かるようにする
- 桁が大きく違う指標（loss と accuracy など）は、比較目的を分けてチャートを複数作る
よくある質問
パイプラインジョブで学習しているのですが、並列座標を使えますか？
パイプラインそのものは「工程のつながり」を表すためのジョブで、並列座標が期待している「スイープの試行群」とは別物です。並列座標を使いたい場合は、学習工程を command component に切り出し、そのコンポーネントをスイープジョブとして実行する形に寄せるのが基本です。
MLflow のネストラン（親 run の下に複数 run）なら、Studio の並列座標に出ますか？
ネストランで「それっぽい構造」を作れても、Azure ML Studio の Parallel coordinates は「Azure ML のスイープジョブとしてのメタデータ」を前提にするため、ネストランだけで同等に動くとは限りません。Studio 側の機能で完結させたいなら、スイープ機能を使うのが確実です。
なぜUIは表示されるのに、クリックしても反応しないのですか？
Parallel coordinates のタイル自体は追加できる一方で、内部的には「スイープジョブの Trial・探索パラメータ・目的指標」を参照して初めて選択肢が組み立てられます。前提が満たされない場合、候補が作れず、結果としてドロップダウンが反応しない（または空のまま）状態になりやすいです。
スイープジョブに移行すると何が変わりますか？
大きくは次の3点です。
- Trial が Azure ML 上で「公式に」管理され、比較しやすくなる
- 目的指標（Primary metric）を中心に最適化・ランキングができる
- Parallel coordinates を含むスイープ向けの可視化が使える
まとめ
Azure ML Studio の Parallel coordinates（並列座標）チャートは、メトリクスが存在するだけでは動きません。ハイパーパラメータチューニング（スイープ）ジョブ専用という前提があるため、通常ジョブや自前スイープではドロップダウンが反応しないケースが発生します。並列座標を使いたい場合は、学習をスイープジョブとして再構成し、objective と search_space を定義して実行するのが最短です。移行が難しい場合は、MLflow のログを活用して plotly や BI ツールで並列座標を作る運用に切り替えると、同じ目的をより確実に達成できます。
コメント