サービスアカウントを使用してワークフローを自動化する

org および チーム スコープのサービスアカウントを使用して、自動化ワークフローや非対話型ワークフローを管理する

サービスアカウントは、人間ではないユーザー、またはマシンユーザーを表し、1つのチーム内のプロジェクト間、またはチーム間で一般的なタスクを自動的に実行できます。サービスアカウントは、CI/CDパイプライン、自動化されたトレーニングジョブ、その他のマシン間ワークフローに最適です。

このページでは、サービスアカウントで利用可能なスコープを説明し、作成方法と管理方法を順を追って示すとともに、本番オートメーションで安全に使用するためのベストプラクティスをまとめています。これは、自動化システム用の認証情報をプロビジョニングする組織およびチーム管理者を対象としています。

​

主なメリット

サービスアカウントの主な利点:

• ライセンスを消費しない: サービスアカウントはユーザーシートやライセンスを消費しません
• 専用のAPIキー: 自動化ワークフロー向けの安全な認証情報
• ユーザー属性の付与: 自動化されたrunを必要に応じて人間のユーザーに紐付けできます
• エンタープライズ対応: 大規模な本番自動化向けに構築されています
• 委任された操作: サービスアカウントは、作成元のユーザーまたは組織に代わって動作します

​

概要

サービスアカウントを使用すると、個人のユーザー認証情報やハードコードされた認証情報を使わずに、W&B のワークフローを安全に自動化できます。2 つのスコープで作成できます。

• Organization-scoped: 組織管理者が作成し、すべての Teams にアクセスできます。
• Team-scoped: チーム管理者が作成し、特定のチームのみにアクセスできます。

サービスアカウントのAPIキーを使うと、呼び出し元はサービスアカウントのスコープ内にあるプロジェクトに対して読み取りまたは書き込みを行えます。これにより、W&B Models での実験管理や、W&B Weave でトレースをログする自動化ワークフローを一元的に管理できます。

サービスアカウントは、次のような用途で役立ちます。

• CI/CD pipelines: GitHub Actions、GitLab CI、Jenkins からモデル トレーニング run を自動的にログする。
• Scheduled jobs: 夜間のモデル再トレーニング、定期的な評価 run、またはデータ検証ワークフロー。
• Production monitoring: 本番システムから推論メトリクスやモデル性能をログする。
• Jupyter notebooks: JupyterHub や Google Colab 環境内の共有ノートブック。
• Kubernetes jobs: Kubernetes クラスターで実行される自動化ワークフロー。
• Airflow/Prefect/Dagster: ML パイプラインのオーケストレーションツール。

サービスアカウントは、専用クラウド、Enterprise ライセンスを持つセルフマネージド インスタンス、および Multi-tenant Cloud のエンタープライズアカウントで利用できます。

​

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

オートメーションで複数のチームにまたがるプロジェクト全体の読み取りまたは書き込みが必要な場合は、組織スコープのサービスアカウントを使用します。組織スコープのサービスアカウントには、制限付きプロジェクトを除き、チームに関係なく、その組織内のすべてのプロジェクトに対する読み取りおよび書き込み権限があります。組織スコープのサービスアカウントが制限付きプロジェクトにアクセスするには、そのプロジェクトの管理者が当該サービスアカウントを明示的にプロジェクトへ追加する必要があります。

​

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

新しい組織スコープのサービスアカウントとAPIキーを作成するには、次の手順に従います。

1. W&B にログインし、ユーザープロフィールアイコンをクリックして、次のいずれかを行います。
   • 専用クラウド または セルフマネージド: Organization Dashboard をクリックし、次に Service Accounts をクリックします。
   • Multi-tenant Cloud: Service Accounts をクリックします。
2. Create service account をクリックします。
3. 名前を入力し、デフォルトのチームを選択します。
4. Create をクリックします。
5. 作成したサービスアカウントを探します。
6. action () メニューをクリックし、次に Create API key をクリックします。
7. APIキーの名前を入力し、Create をクリックします。
8. APIキーをコピーし、安全な場所に保管します。
9. Done をクリックします。

APIキー全体が表示されるのは、作成時の一度だけです。ダイアログを閉じた後は、APIキー全体を再度表示できません。Settings に表示されるのはキーID (キーの先頭部分) のみです。APIキー全体を紛失した場合は、新しいAPIキーを作成する必要があります。

組織スコープのサービスアカウントは、組織内のすべてのチームが所有する非制限のプロジェクトにアクセスできる場合でも、デフォルトのチームが必要です。これは、モデル トレーニングや生成 AI アプリの環境で WANDB_ENTITY 変数が設定されていない場合に、ワークロードの失敗を防ぐためです。別のチームのプロジェクトで組織スコープのサービスアカウントを使用するには、WANDB_ENTITY 環境変数をそのチームに設定する必要があります。

​

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

最小権限の原則に従って、オートメーションの対象を単一のチームのプロジェクトに限定したい場合は、チームスコープのサービスアカウントを使用してください。チームスコープのサービスアカウントは、そのチーム内のすべてのプロジェクトに対して読み書きできます。ただし、そのチーム内の制限付きプロジェクトにはアクセスできません。チームスコープのサービスアカウントが制限付きプロジェクトにアクセスするには、そのプロジェクトの管理者が当該サービスアカウントを明示的にプロジェクトへ追加する必要があります。

​

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

新しいチームスコープのサービスアカウントとAPIキーを作成するには、次の手順に従います。

1. チームのSettingsで、Service Accounts をクリックします。
2. New Team Service Account をクリックします。
3. サービスアカウントの名を入力します。
4. Authentication Method を Generate API key (デフォルト) に設定します。Federated Identity を選択した場合、そのサービスアカウントはAPIキーを所有できません。
5. Create をクリックします。
6. 先ほど作成したサービスアカウントを検索します。
7. action () メニューをクリックし、Create API key をクリックします。
8. APIキーの名を入力し、Create をクリックします。
9. APIキーをコピーして、安全な場所に保管します。
10. Done をクリックします。

APIキー全体が表示されるのは、作成時の一度だけです。ダイアログを閉じた後は、APIキー全体を再度表示できません。Settings に表示されるのはキーID (キーの先頭部分) のみです。APIキー全体を紛失した場合は、新しいAPIキーを作成する必要があります。

​

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

サービスアカウントに紐づくAPIキーを作成するには、次の手順に従います。

1. チームまたは組織の設定で、Service Accounts タブにアクセスします。
2. 一覧からサービスアカウントを検索します。
3. action () メニューをクリックし、Create API key をクリックします。
4. APIキーの名を入力し、Create をクリックします。
5. 表示されたAPIキーをすぐにコピーして、安全な場所に保管します。
6. Done をクリックします。

異なる環境やワークフローに対応するため、1つのサービスアカウントに対して複数のAPIキーを作成できます。

APIキー全体が表示されるのは、作成時の一度だけです。ダイアログを閉じた後は、APIキー全体を再度表示できません。Settings に表示されるのはキーID (キーの先頭部分) のみです。APIキー全体を紛失した場合は、新しいAPIキーを作成する必要があります。

​

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

組織またはチームのサービスアカウントが所有するAPIキーを削除するには、次の手順を実行します。

1. 組織の設定に移動し、APIキーをクリックします。
2. 対象のAPIキーを探します。一覧には、組織およびチームのサービスアカウントが所有するすべてのAPIキーが表示されます。キー名またはIDで検索やフィルターを行え、任意の列で並べ替えることもできます。
3. 削除ボタンをクリックします。

チームスコープのサービスアカウントを使用するモデル トレーニングまたは生成 AI アプリの環境でチームを設定していない場合、モデルの run または Weave のトレースは、サービスアカウントの親チーム内の指定したプロジェクトにログされます。この場合、WANDB_USERNAME または WANDB_USER_EMAIL 変数を使用したユーザー属性の付与は、参照先のユーザーがサービスアカウントの親チームに属していない限り、機能しません。

チームスコープのサービスアカウントは、親チームとは異なるチーム内のチームスコープまたは制限付きスコープのプロジェクトに run をログすることはできませんが、別のチーム内の Open 可視性プロジェクトには run をログできます。

​

外部サービスアカウント

W&B ネイティブの APIキー を管理する代わりに、独自のアイデンティティプロバイダを通じて認証情報を発行したい場合は、外部サービスアカウントを使用します。組み込みのサービスアカウントに加えて、W&B は、JWT (JSON Web Token) を発行できる identity provider (IdP) を使用した アイデンティティ フェデレーション により、W&B SDK と CLI でチームスコープの外部サービスアカウントもサポートしています。

​

ベストプラクティス

必要なサービスアカウントを作成したら、組織内でサービスアカウントを安全かつ効率的に使用するために、以下の推奨事項に従ってください。

• シークレットマネージャーを使用する: サービスアカウントのAPIキーは、プレーンテキストの設定ファイルではなく、安全なシークレット管理システム (例: AWS Secrets Manager、HashiCorp Vault、Azure Key Vault) に保存してください。

• 最小権限の原則: アクセスを必要な project のみに制限するため、可能であれば組織スコープのアカウントではなく、チームスコープのサービスアカウントを作成してください。

• ユースケースごとに固有のサービスアカウントを使用する: 監査しやすくし、きめ細かなアクセス制御を可能にするため、オートメーションワークフローごとに個別のサービスアカウントを作成してください (例: CI/CD 用に 1 つ、定期的な再トレーニング用に別の 1 つ) 。

• 定期的な監査: アクティブなサービスアカウントを定期的に確認し、不要になったものは削除してください。監査ログを確認して、サービスアカウントのアクティビティを監視してください。

• 安全なAPIキーの処理:

  • APIキーをバージョン管理にコミットしないでください。
  • キーは環境変数を使ってアプリケーションに渡してください。
  • 誤って公開してしまった場合は、キーをローテーションしてください。

• 命名規則: サービスアカウントの用途が分かる説明的な名前を使用してください:

  • 良い例: ci-model-training, nightly-eval-pipeline, prod-inference-monitor
  • 避ける例: service-account-1, test-sa, temp

• ユーザー属性の付与: 複数のチームメンバーが同じオートメーションワークフローを使用する場合は、WANDB_USERNAME または WANDB_USER_EMAIL を設定して、各 run を誰がトリガーしたかをトラッキングしてください:

  export WANDB_API_KEY="[SERVICE_ACCOUNT_KEY]"
  export WANDB_USERNAME="[e-mail]"
  

• 環境設定: チームスコープのサービスアカウントでは、Runs が正しいチームにログされるよう、必ず WANDB_ENTITY を設定してください:

  export WANDB_ENTITY="ml-team"
  export WANDB_PROJECT="production-models"
  

• エラー処理: サービスアカウント認証情報に関する問題をすばやく特定できるよう、認証失敗に対する適切なエラー処理とアラートを実装してください。

• ドキュメント: 次の内容を文書化して維持してください:

  • どのサービスアカウントが存在し、それぞれの用途は何か。
  • 各サービスアカウントをどのシステムまたはワークフローが使用しているか。
  • 各アカウントの担当チームの連絡先情報。

​

トラブルシューティング

サービスアカウントが想定どおりに動作しない場合は、以下のよくある問題と解決策を確認してください:

• 「Unauthorized」エラー: APIキーが正しく設定されており、サービスアカウントに対象プロジェクトへのアクセス権があることを確認します。
• Runs が表示されない: WANDB_ENTITY に正しいチーム名が設定されていることを確認します。
• ユーザー属性の付与が機能しない: WANDB_USERNAME で指定したユーザーがチームのメンバーであることを確認します。
• 制限付きプロジェクトへのアクセスが拒否される: 制限付きプロジェクトのアクセスリストにサービスアカウントを明示的に追加します。