データサイエンス・分析

W&B入門2026|ML実験を8行のコードで記録・可視化する全手順

読了時間: 約13分

ML実験の管理をスプレッドシートで続けている開発者は、2026年の今でも少なくない。「learning_rate=0.001のときのlossいくつだっけ」とファイル名をgrepした経験があるなら、Weights & Biases(W&B)の導入で作業が根本から変わる。

W&BはML実験のログ記録・可視化・ハイパーパラメータ探索・モデル管理を1つのプラットフォームに集約したSaaS。筆者も半年前に個人プロジェクトで導入したが、最初の実験ログがダッシュボードに表示された瞬間、TensorBoardのlogdir管理には二度と戻れなくなった。実験の「記録帳」であり「地図」であり「倉庫番」でもある。コードを先に動かしてから全体像を掴む順序で進める。

1. 10行で動かすクイックスタート

説明は後回し。まず動かす。

pip install wandb
wandb login   # ブラウザが開く → APIキーをコピペ

アカウントはwandb.aiでGitHub連携すれば30秒で作れる。APIキーはSettings画面に表示される文字列をターミナルに貼るだけ。

import wandb
import random

with wandb.init(project="first-experiment", config={"lr": 0.01, "epochs": 20}) as run:
    for epoch in range(20):
        loss = 1.0 / (epoch + 1) + random.uniform(-0.05, 0.05)
        acc = 1 - loss + random.uniform(-0.02, 0.02)
        run.log({"loss": loss, "accuracy": acc})

8行。wandb.aiのダッシュボード上にlossとaccuracyのグラフが即座に生える。ブラウザを開いてプロジェクトページに飛ぶと、epoch進行に合わせてリアルタイムに線が伸びていく。TensorBoardのようにlogdirを指定してサーバーを立てる手間がない。コードを走らせた瞬間から可視化が始まる。

with文を使う理由

with wandb.init(...) as run: で囲むと、ブロック終了時に自動でrun.finish()が走る。Jupyter Notebookでカーネルを途中で止めてもrunが宙ぶらりんにならない。wandb.init()を裸で呼ぶ書き方も見かけるが、閉じ忘れのトラブルが多い。with文を標準にしておくのが無難。

2. ダッシュボードの読み方

コードを実行すると、ターミナルにURLが1行表示される。ダッシュボードへの直リンクだ。クリックするとブラウザに遷移する。

画面左にrun一覧。中央にグラフエリア。右にサマリーパネル。初期状態ではlossとaccuracyの折れ線グラフが自動生成されている。run.log()に渡したキー名がそのままグラフのタイトルになる仕組みだ。

実験を1回走らせるたびにrunが1行増え、ハイパーパラメータとメトリクスが自動で記録される。3日後に「あのときのlr=0.001の結果どうだっけ」と記憶を掘り返す必要がない。ダッシュボードを開けば、全runが時系列で並んでいる。これがW&Bを「実験ノートの電子版」と呼ぶ所以だ。

ログに流せるデータ型

スカラー値だけではない。画像、動画、音声、3Dオブジェクト、テーブル、matplotlibの図まで流し込める。

# 画像をログ
run.log({"generated": wandb.Image(img_array, caption="epoch 10")})

# matplotlibの図をそのまま
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
ax.plot(history)
run.log({"learning_curve": fig})

# テーブル(予測結果の比較などに)
table = wandb.Table(columns=["input", "pred", "label"],
                    data=[["猫の画像", "cat", "cat"], ["犬の画像", "dog", "cat"]])
run.log({"predictions": table})

物体検出モデルのデバッグで特に重宝する。bounding boxがずれているとき、数値を眺めても原因はわからない。画像をepochごとに記録しておけば「epoch 5からboxが右にずれ始めた」と一目でわかる。厄介なのは、この手のバグはlossの値だけ見ていると「順調に下がっている」ように見える点だ。画像ログがなければ気づけない。実際にW&Bの画像ログで検出精度のバグを発見できたケースは少なくない。

3. Sweepsでハイパーパラメータ自動探索

ここからがW&Bの本領。手動でlrを0.01, 0.001, 0.0001と試して結果をメモする作業、もう不要だ。

Sweepsは探索戦略・パラメータ範囲・最適化目標をYAML風の辞書で定義するだけで勝手に回るハイパーパラメータ探索機能。イメージとしては、Optunaのような探索エンジンとW&Bのログ基盤が一体化したもの。

sweep_config = {
    "method": "bayes",
    "metric": {"name": "val_loss", "goal": "minimize"},
    "parameters": {
        "learning_rate": {
            "distribution": "log_uniform_values",
            "min": 1e-5,
            "max": 1e-1
        },
        "batch_size": {"values": [16, 32, 64, 128]},
        "optimizer": {"values": ["adam", "sgd", "adamw"]},
    },
    "early_terminate": {
        "type": "hyperband",
        "min_iter": 3
    }
}

sweep_id = wandb.sweep(sweep_config, project="sweep-demo")

methodは3択。

  • grid -- 全組み合わせを総当たり。パラメータが3個以下なら有効だが、それ以上は組み合わせ爆発する
  • random -- ランダムサンプリング。gridよりはるかに効率的で、研究でも「randomで十分」という結果がある
  • bayes -- 過去の結果からガウス過程で次の候補を推定。探索回数が20-50回程度に限られるときに真価を発揮

early_terminateにHyperbandを指定すると、序盤のlossが悪いrunを自動で打ち切る。20回のSweepで15回を途中終了し、有望な5回にGPU時間を集中させる動きになる。

def train():
    with wandb.init() as run:
        config = run.config
        model = build_model(config.learning_rate, config.optimizer)
        for epoch in range(50):
            loss = train_one_epoch(model, config.batch_size)
            run.log({"val_loss": loss})

wandb.agent(sweep_id, function=train, count=20)

wandb.agent()を呼ぶと、W&Bサーバー側が次のパラメータ組み合わせを決めてtrain関数に渡す。複数マシンで並列に走らせたい場合は、各マシンで同じsweep_idに対してwandb.agent()を呼ぶだけでよい。サーバーが重複を排除して割り振る。

4. Artifactsでデータとモデルを管理する

Gitはコードの倉庫としては優秀だが、学習データやモデルの重みファイルには向いていない。数GBのバイナリをcommitするとリポジトリが破綻する。ArtifactsはこのGitの弱点を埋める機能だ。データセット・モデル・設定ファイルをバージョン付きで保存し、「どの実験がどのデータで学習したか」の系譜を追跡する。

# データセットをArtifactとして保存
artifact = wandb.Artifact("training-data", type="dataset",
                          description="前処理済み v2",
                          metadata={"rows": 50000, "source": "BigQuery"})
artifact.add_dir("data/processed/")
run.log_artifact(artifact)
# 別のrunで取得して使う
artifact = run.use_artifact("training-data:latest")
data_dir = artifact.download()

:latestは最新バージョンを指すエイリアス。:v3で特定バージョンを固定することもできる。「本番モデルはどのバージョンのデータで学習したか」を遡れる状態が、コード2行で手に入る。

Model Registryとの連携

学習済みモデルをArtifactとして保存した後、Model Registryにリンクすると「production」「staging」といったエイリアスを付けられる。本番環境から"image-classifier:production"を引くだけで承認済みモデルが取れる仕組みだ。

model_artifact = wandb.Artifact("resnet50-classifier", type="model")
model_artifact.add_file("checkpoints/best_model.pt")
run.log_artifact(model_artifact)

run.link_artifact(model_artifact,
                  target_path="wandb-registry-model/image-classifier",
                  aliases=["production", "v4"])

Slackで「productionのモデルどれだっけ?」と聞く必要がなくなる。地味だが、チーム開発ではこの「聞かなくて済む」仕組みが一番効く。W&Bを使い始めて惜しいと感じたのは、もっと早く導入しなかったことだ。最初の3ヶ月間の実験ログが手元に残っていない。

5. 料金プラン

プラン 料金 ストレージ 主な用途
Free $0 100GB 個人の実験管理。パブリックプロジェクト無制限
Team $50/ユーザー/月 1TB プライベートプロジェクト、RBAC、チーム共有
Enterprise 要問い合わせ カスタム オンプレ/専用クラウド、SSO/SAML、SLA

個人ならFreeプランで十分すぎる。100GBのストレージはメトリクスのログだけなら数年分持つ。モデルの重みファイル(数百MB〜数GB)をArtifactsに入れ始めると消費が早まるが、個人利用なら余裕がある。

W&BのTeamプランの$50/月/人はJetBrains IDEのサブスクと同程度。5人チームで月$250。高いか安いかはML実験のカオス具合による。「先週のあの実験の設定ファイルどこ」というやり取りが週3回以上あるなら、W&Bの導入で元は取れる。

6. MLflow vs W&B

ML実験管理の二大勢力。どちらを選ぶかはチームの制約で決まる。

観点 W&B MLflow
ホスティング SaaS(クラウドにデータ送信) セルフホスト(自社サーバーで完結)
セットアップ pip install wandb のみ トラッキングサーバーの構築が必要
ダッシュボード 洗練されたUI。インタラクティブ 機能的だが見た目は質素
HP探索 Sweeps内蔵 Optuna等と外部連携
データの行き先 W&Bクラウド 自社サーバー内
コスト Free〜$50/月/人 OSS無料(サーバー運用費は別途)

自分ならこう使い分ける。個人のサイドプロジェクトやKaggleならW&B一択。セットアップゼロの恩恵は大きい。一方、医療データや社内機密を扱い「データを外部に出せない」制約があるならMLflow。

迷うのは「チームで使う商用プロジェクト」のケース。W&BのTeamプランに$50/月/人を払うか、MLflowのサーバーを自前で立てるか。サーバー管理にリソースを割けるMLOpsエンジニアがチームにいるならMLflowも選択肢に入る。いないなら、SaaSに任せたほうがMLエンジニアは実験に集中できる。

7. よくある質問

Q. 無料で使えるか?

使える。Freeプランでストレージ100GB、パブリックプロジェクト無制限。

Q. PyTorch以外のフレームワークでも動くか?

TensorFlow/Keras、PyTorch Lightning、Hugging Face Transformers、scikit-learn、XGBoost、LightGBMなど主要フレームワークとの統合が揃っている。PyTorch LightningならWandbLoggerをTrainerに渡すだけ。scikit-learnならwandb.sklearn.plot_classifier()で混同行列やROC曲線まで自動生成される。フレームワーク側がW&Bを意識せず、W&B側がフレームワークに合わせる設計なので、既存コードへの変更は最小限で済む。

Q. オフラインで使えるか?

wandb.init(mode="offline")で使える。後からwandb syncでアップロード。

Q. TensorBoardから移行する手間は?

既存のPyTorchやTensorFlowのコードwandb.init()run.log()を数行足すだけ。TensorBoard用のSummaryWriterと併用もできるため、段階的に移行しながら比較検証するのが現実的な進め方になる。

Q. データのプライバシーは大丈夫か?

Free/TeamプランのデータはW&Bクラウド(AWS上)に保存される。SOC 2 Type II認証取得済み。外部送信が許されない場合はEnterprise向けのオンプレミスデプロイか、MLflowでのセルフホストが現実的な代替案。

8. まとめ

W&Bの核はrun.log()の1行にある。ML実験を記録し、ブラウザで即座に可視化する。コード8行で動くクイックスタートのハードルの低さと、Sweeps・Artifacts・Model Registryまで揃った機能の幅を両立している。この両方を持つツールは他にない。

Pythonの基礎が身についていてMLモデルの学習経験が1回でもあるなら、導入は早いほうがよい。実験ログが溜まるほどW&Bの価値は上がる。逆に「1回学習して終わり」のケースではオーバースペック。判断基準は「同じモデルのハイパーパラメータを2回以上変えて試すかどうか」だ。

pip install wandbとクイックスタートのコードで1回動かしてみるのが最短の判断材料になる。ダッシュボードに自分の実験グラフが表示されたとき、スプレッドシート管理には戻れなくなる。