メインコンテンツへスキップ
サービスアカウントは、人間ではなくマシンとして動作するユーザーを表し、チーム内の複数のプロジェクト間やチームをまたいで共通のタスクを自動的に実行できます。サービスアカウントは、CI/CD パイプライン、自動化された学習ジョブ、その他のマシン間ワークフローに最適です。

主なメリット

サービスアカウントの主な利点:
  • ライセンスを消費しない: サービスアカウントはユーザーシートやライセンスを消費しません
  • 専用のAPIキー: 自動化されたワークフロー向けの安全な認証情報
  • ユーザー帰属: 自動化された run を人間のユーザーに紐付けることが可能です
  • エンタープライズ対応: 本番環境での大規模な自動化のために設計されています
  • 委任された操作: サービスアカウントは、それを作成したユーザーまたは組織に代わって操作を実行します

概要

Service account は、個人のユーザー認証情報やハードコードされた認証情報を使用せずに、W&B のワークフローを自動化するための安全な方法を提供します。Service account は 2 つのスコープで作成できます:
  • Organization スコープ: 組織管理者が作成し、すべてのチームへのアクセス権を持つ
  • Team スコープ: チーム管理者が作成し、特定のチームのみにアクセスが制限される
Service account の APIキー によって、呼び出し元はその Service account のスコープ内のプロジェクトに対して読み取りまたは書き込みを行うことができます。これにより、W&B Models での実験トラッキング用の自動ワークフローや、W&B Weave でのトレースのログ記録を一元的に管理できます。 Service account は次のような用途で特に有用です:
  • CI/CD パイプライン: GitHub Actions、GitLab CI、Jenkins からモデル学習の run を自動的にログする
  • スケジュールされたジョブ: 毎晩のモデル再学習、定期的な評価 run、あるいはデータ検証ワークフロー
  • 本番監視: 本番システムから推論メトリクスやモデル性能をログする
  • Jupyter ノートブック: JupyterHub や Google Colab 環境で共有されるノートブック
  • Kubernetes ジョブ: K8s クラスターで実行される自動ワークフロー
  • Airflow/Prefect/Dagster: ML パイプラインのオーケストレーションツール
Service account は、Dedicated Cloud、エンタープライズライセンスを持つ Self-Managed インスタンス、および Multi-tenant Cloud のエンタープライズアカウントで利用できます。

組織スコープのサービスアカウント

組織スコープのサービスアカウントは、チームに関係なく、その組織内のすべてのプロジェクト(制限付きプロジェクト を除く)に対して読み取りおよび書き込み権限を持ちます。組織スコープのサービスアカウントが制限付きプロジェクトへアクセスできるようにするには、そのプロジェクトの管理者が明示的にサービスアカウントをそのプロジェクトに追加する必要があります。

組織スコープのサービスアカウントを作成する

組織スコープの新しいサービスアカウントとAPIキーを作成するには、次の手順に従います。
  1. W&B にログインし、ユーザープロファイルアイコンをクリックしてから、次を実行します。
    • Dedicated Cloud または Self-Managed の場合: Organization Dashboard をクリックし、Service Accounts をクリックします。
    • Multi-tenant Cloud の場合: Service Accounts をクリックします。
  2. Create service account をクリックします。
  3. 名前を入力し、デフォルトのチームを選択します。
  4. Create をクリックします。
  5. 作成したばかりのサービスアカウントを探します。
  6. アクションメニュー(...)をクリックし、Create API key をクリックします。
  7. APIキーの名前を入力し、Create をクリックします。
  8. APIキーをコピーして、安全な場所に保管します。
  9. Done をクリックします。
完全なAPIキーは作成時に一度だけ表示されます。ダイアログを閉じると、完全なAPIキーを再度表示することはできません。設定で表示されるのは、キーID(キーの先頭部分)のみです。完全なAPIキーを紛失した場合は、新しいAPIキーを作成する必要があります。
組織スコープのサービスアカウントは、組織内のすべてのチームが所有する、制限されていないプロジェクトへアクセスできますが、デフォルトチームの指定が必須です。これは、モデル学習や生成 AI アプリ向けのワークロードで、WANDB_ENTITY 変数が環境に設定されていない場合に処理が失敗するのを防ぐためです。別のチームのプロジェクトに対して組織スコープのサービスアカウントを使用するには、WANDB_ENTITY 環境変数をそのチームを指す値に設定する必要があります。

チームスコープのサービスアカウント

チームスコープのサービスアカウントは、そのチーム内のすべてのプロジェクトに対して読み取りおよび書き込みを行うことができますが、そのチーム内の制限付きプロジェクトは例外です。チームスコープのサービスアカウントが制限付きプロジェクトにアクセスするには、そのプロジェクトの管理者がサービスアカウントを明示的にそのプロジェクトに追加する必要があります。

チームスコープのサービスアカウントを作成する

チームスコープの新しいサービスアカウントとAPIキーを作成するには、次の手順を実行します。
  1. チームの設定で Service Accounts をクリックします。
  2. New Team Service Account をクリックします。
  3. サービスアカウントの名前を入力します。
  4. Authentication Method をデフォルトの Generate API key に設定します。Federated Identity を選択した場合、そのサービスアカウントはAPIキーを所有できません。
  5. Create をクリックします。
  6. 作成したサービスアカウントを探します。
  7. アクションメニュー(...)をクリックし、Create API key をクリックします。
  8. APIキーの名前を入力し、Create をクリックします。
  9. APIキーをコピーして、安全な場所に保管します。
  10. Done をクリックします。
完全なAPIキーは作成時に一度だけ表示されます。ダイアログを閉じると、完全なAPIキーを再度表示することはできません。設定で表示されるのは、キーID(キーの先頭部分)のみです。完全なAPIキーを紛失した場合は、新しいAPIキーを作成する必要があります。

サービスアカウントの API キーを追加作成する

サービスアカウントが所有するAPIキーを作成するには、次の手順を実行します。
  1. チームまたは組織の設定の Service Accounts タブに移動します。
  2. 一覧から対象のサービスアカウントを探します。
  3. アクションメニュー(...)をクリックし、Create API key をクリックします。
  4. APIキーの名前を入力し、Create をクリックします。
  5. 表示されたAPIキーをすぐにコピーして、安全な場所に保管します。
  6. Done をクリックします。
異なる環境やワークフローをサポートするために、1つのサービスアカウントに対して複数のAPIキーを作成できます。
完全なAPIキーは作成時に一度だけ表示されます。ダイアログを閉じると、完全なAPIキーを再度表示することはできません。設定で表示されるのは、キーID(キーの先頭部分)のみです。完全なAPIキーを紛失した場合は、新しいAPIキーを作成する必要があります。

サービスアカウントの API キーを削除する

組織またはチームのサービスアカウントに属する APIキー を削除するには、次の手順に従います。
  1. Organization settings に移動し、API Keys をクリックします。
  2. 対象の APIキー を探します。リストには、組織およびチームのサービスアカウントに属するすべての APIキー が含まれます。キー名または ID で検索やフィルターができ、任意の列でソートできます。
  3. Delete ボタンをクリックします。
チームスコープのサービスアカウントを使用するモデル学習または生成AIアプリケーション環境でチームを構成しない場合、モデルの run や Weave の trace は、そのサービスアカウントの親チーム内にある指定されたプロジェクトにログされます。このような場合、参照されるユーザーがそのサービスアカウントの親チームに所属していない限り、WANDB_USERNAMEWANDB_USER_EMAIL 変数を使ったユーザーの紐付けは 機能しません
チームスコープのサービスアカウントは、親チームとは異なるチームにある チームスコープまたは制限スコープのプロジェクト には run をログできませんが、別のチーム内にある可視性が Open のプロジェクトには run をログできます。

外部サービスアカウント

組み込みのサービスアカウントに加えて、W&B は JSON Web Token (JWT) を発行できるアイデンティティプロバイダ (IdP) との Identity federation を利用し、W&B SDK および CLI から使用できるチーム単位の外部サービスアカウントもサポートしています。

ベストプラクティス

組織内でサービスアカウントを安全かつ効率的に利用するために、次の推奨事項に従ってください。
  • シークレットマネージャーを使用する: サービスアカウントのAPIキーは、プレーンテキストの設定ファイルではなく、AWS Secrets Manager、HashiCorp Vault、Azure Key Vault などの安全なシークレット管理システムに保存します。
  • 最小権限の原則: 必要なプロジェクトへのアクセスに限定するために、可能な場合は組織スコープのアカウントではなく、チームスコープのサービスアカウントを作成します。
  • ユースケースごとに固有のサービスアカウント: 監査性を高め、きめ細かなアクセス制御を可能にするために、異なる自動化ワークフローごとに個別のサービスアカウントを作成します(例: CI/CD 用とスケジュールされた再学習用で分ける)。
  • 定期的な監査: アクティブなサービスアカウントを定期的に確認し、使用されていないものは削除します。監査ログを確認してサービスアカウントのアクティビティをモニタリングします。
  • APIキーの安全な取り扱い:
    • APIキーをバージョン管理にコミットしない
    • 環境変数を使ってアプリケーションにキーを渡す
    • 誤って漏えいした場合はキーをローテーションする
  • 命名規則: サービスアカウントの目的が分かる説明的な名前を使用します:
    • 良い例: ci-model-training, nightly-eval-pipeline, prod-inference-monitor
    • 避ける例: service-account-1, test-sa, temp
  • ユーザーの紐付け: 複数のチームメンバーが同じ自動化ワークフローを利用する場合は、各runを誰がトリガーしたかを追跡するために WANDB_USERNAME または WANDB_USER_EMAIL を設定します:
    export WANDB_API_KEY="<service_account_key>"
    export WANDB_USERNAME="john.doe@company.com"
    
  • 環境設定: チームスコープのサービスアカウントでは、runが正しいチームにログされるよう、必ず WANDB_ENTITY を設定します:
    export WANDB_ENTITY="ml-team"
    export WANDB_PROJECT="production-models"
    
  • エラー処理: サービスアカウントの認証情報に関する問題を素早く特定できるよう、認証失敗に対する適切なエラー処理とアラートを実装します。
  • ドキュメント化: 次の内容を文書化して維持します:
    • どのサービスアカウントが存在し、それぞれの目的は何か
    • 各サービスアカウントをどのシステム/ワークフローが利用しているか
    • 各アカウントに責任を持つチームの連絡先情報

トラブルシューティング

よくある問題とその解決策:
  • “Unauthorized” エラー: APIキーが正しく設定されていることと、サービスアカウントに対象プロジェクトへのアクセス権があることを確認してください
  • Runs が表示されない: WANDB_ENTITY が正しいチーム名に設定されていることを確認してください
  • ユーザーの紐付けが機能しない: WANDB_USERNAME で指定したユーザーがチームのメンバーであることを確認してください
  • 制限付きプロジェクトへのアクセス拒否: 制限付きプロジェクトのアクセスリストにサービスアカウントを明示的に追加してください