1. はじめに
IBM Cloud Pak for Data as a Service（以下、CP4DaaS）や watsonx as a Service を運用・自動化していくと、「人に紐づかない認証主体」が必要になる場面が出てきます。スケジュール実行されるデプロイメント・ジョブ、外部システムからの API 呼び出し、退職者のアカウント削除に左右されない常時稼働の連携処理などです。
こうした用途で鍵になるのが、IBM Cloud の IAM で作成・管理する サービスID と、watsonx / CP4DaaS 側で利用する タスク認証情報（Task Credential） です。
本記事では、サービスID（および サービスID の API キー）、ユーザー API キー、タスク認証情報の3つを整理し、それぞれの違いと、CP4DaaS / watsonx as a Service における具体的な活用方法を解説します。対象読者は IBM Cloud / CP4DaaS / watsonx を運用・自動化する IT 技術者で、これらの基本知識があることを前提とします。
本記事の内容は IBM 公式ドキュメントを参照して記述しています。仕様は更新される可能性があるため、実装前に末尾の参考リンクから最新情報を確認してください。
2. 用語の整理
最初に、混同しやすい3つの認証要素を整理します。
| 用語 | 何か | 作成・管理する場所 | 紐づく対象 |
|---|---|---|---|
| ユーザー API キー | 個々のユーザーに紐づく IBM Cloud API キー | IBM Cloud IAM（APIキー） | 個人ユーザー |
| サービスID | アプリケーションやサービス向けの、ユーザーに紐づかない ID | IBM Cloud IAM（サービスID） | サービスID（人ではない） |
| サービスID の API キー | サービスID に対して発行する API キー | IBM Cloud IAM（サービスID 配下） | サービスID |
| タスク認証情報 | 長時間・非同期ジョブ用に Vault に保管される API キー | watsonx / CP4DaaS のプロファイル、または REST API | ユーザー または サービスID |
ポイントは、サービスID は「人ではない認証主体」 であり、タスク認証情報は「watsonx / CP4DaaS が長時間ジョブを継続実行するために保管しておく API キー」 だという点です。両者は別レイヤーの概念であり、サービスID の API キーをタスク認証情報として登録する、という関係になります。
3. サービスID とは
サービスID は、IBM Cloud の外部にあるアプリケーションやサービスに、IBM Cloud のサービスへのアクセスを許可するための ID です。最大の特徴は、特定のユーザーに紐づかない ことです。
ユーザーが組織を離れてアカウントが削除されても サービスID は残るため、アプリケーションや連携処理は稼働し続けられます。これは、個人のユーザー API キーで自動化を組んだ場合に発生しがちな「担当者の退職でジョブが止まる」という問題を回避できることを意味します。
サービスID には IAM アクセスポリシーを割り当てられ、アクセスグループに追加することもできます。また、1つの サービスID に対して複数の API キーを発行できます。
サービスID が使用できる機能
サービスID は、主に「人の操作を介さない自動化・連携」で力を発揮します。CP4DaaS / watsonx as a Service の文脈では、代表的に次のことができます。
- IAM アクセスポリシーの割り当て、アクセスグループへの追加によるアクセス制御
- サービスID 配下での API キーの発行（複数発行可能）
- プロジェクト／デプロイメント・スペースへのコラボレーターとしての登録（ビューアー / エディター / 管理者 のロール付与）
- REST API や Python ライブラリーによる認証（サービスID の API キーで IAM トークンを取得）
- タスク認証情報としての登録による、デプロイメント・ジョブやスケジュール・ジョブの継続実行
- 外部システムからの定常的・自動的なサービス呼び出し
サービスID が使用できない／強い制約のある機能
一方で、サービスID は「人」ではないため、ユーザー個人を前提とした操作には使えない、あるいは制約があります。
- IBM Cloud コンソールや watsonx の UI へのインタラクティブなログインはできません。 サービスID は対話的なサインインを行う主体ではありません
- タスク認証情報を UI から作成できません。 ユーザーであればプロファイル画面（ユーザーAPI鍵 タブ）からタスク認証情報を作成できますが、サービスID の場合は UI 経路が使えず、REST API（cURL）でタスク認証情報を登録する必要があります（後述）
- UI 上での対話的な操作（ノートブックの手動実行、画面操作を伴う作業）の主体にはなれません。 あくまでバックグラウンドの認証主体です
- サービスID をプロジェクト／デプロイメント・スペースに追加する操作自体は、操作者側に IAM Identity Service の Operator ロール が必要です（サービスID を検索・追加できる権限）
4. ユーザー API キーと サービスID の API キーの違い
自動化を組むとき、「個人のユーザー API キーを使うか、サービスID の API キーを使うか」は重要な設計判断です。両者を比較します。
| 観点 | ユーザー API キー | サービスID の API キー |
|---|---|---|
| 紐づく対象 | 個々のユーザー | サービスID（人に紐づかない） |
| 退職・アカウント削除時 | キーは無効化され、ジョブが停止し得る | サービスID が残るため継続稼働できる |
| 権限の範囲 | そのユーザーが持つすべての権限を継承しがち | サービスID に付与したポリシー分だけに絞り込める（最小権限を設計しやすい） |
| 監査・追跡 | 個人の操作と区別しにくい | 自動化専用の主体として識別・追跡しやすい |
| キーの本数 | ユーザーごとに複数発行可能 | サービスID ごとに複数発行可能 |
| 主な用途 | 個人の対話的・暫定的な利用 | アプリケーション連携、常時稼働の自動化 |
| UI でのタスク認証情報作成 | 可能 | 不可（REST API で登録） |
実運用では、自動化・本番連携には サービスID の API キーを使う ことが推奨されます。理由は、（1）担当者の異動・退職に影響されない、（2）必要最小限の権限だけを サービスID に付与でき、ガバナンス上の事故を抑えられる、（3）自動化専用の主体として監査しやすい、という3点です。
逆に、個人が一時的に検証で使う、あるいは個人のワークスペース内だけで完結する用途であれば、ユーザー API キーで十分です。
5. タスク認証情報とは
タスク認証情報は、IBM Cloud サービス へのリクエストを認証するために Vault に安全に保管される、API キーをベースとした認証情報 です。watsonx / CP4DaaS では、IBM Cloud API キーがタスク認証情報として使われます。
タスク認証情報の役割は、長時間・非同期のワークロードに API キーを供給すること です。代表例は次のようなものです。
- スケジュール・ジョブの中断のない継続実行
- デプロイメント・ジョブの実行
- 基盤モデルのチューニングなど、長時間を要する処理
重要な性質を整理します。
- タスク認証情報は、製品とプログラムから対話するとき（API を直接叩くとき）には使いません。 あくまで UI 起点の長時間ジョブを裏で回すための仕組みです。
- ユーザーの場合、1つの IBM Cloud アカウントにつき、ユーザーごとに保管できるタスク認証情報は1つ です。既存の IBM Cloud API キーを指定するか、新規に生成できます。
- サービスが操作にタスク認証情報を必要とする場合、API キー（既存または新規生成）の入力を求められます。
- サービス管理者は、不要になったタスク認証情報を失効させる運用方針を定める責任があります。
ユーザーのタスク認証情報の作成（UI）
ユーザー自身のタスク認証情報は UI から作成できます。
- いずれかの画面でアバターをクリックし、プロファイルと設定 を開きます
- ユーザーAPI鍵 タブを開きます。既存キーがあれば表示され、なければ 作成 で作成できます
キーの再生成は ローテート、削除は削除アイコンから行います。
6. サービスID のタスク認証情報を作成する（REST API）
前述のとおり、サービスID の場合は UI からタスク認証情報を作成できません。 REST API（cURL）で /v1/task_credentials に対して登録する必要があります。これは、サービスID を使ってデプロイメントやデプロイメント・ジョブを作成・実行するために必要な手順です。
まず、サービスID の API キーから IAM アクセストークンを取得します。
API_KEY="<Your Service ID API key>"
ACCESS_TOKEN=$(curl -X POST "https://iam.cloud.ibm.com/identity/token?grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey=${API_KEY}" | jq -r .access_token)
次に、取得したトークンを使ってタスク認証情報を作成します。<Cloud provider endpoint URL> は利用しているデータセンター（リージョン）のエンドポイントに置き換えてください。
東京の場合はapi.jp-tok.dataplatform.cloud.ibm.comです。
curl -X POST "https://<Cloud provider endpoint URL>/v1/task_credentials" \
-H "accept: application/json" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "SERVICE_ID_TASK_CREDENTIALS",
"type": "iam_api_key",
"secret": {
"api_key": "'"${API_KEY}"'"
}
}'
注意: タスク認証情報を作成した後、データ同期のため、失敗したジョブやデプロイメントを再実行する前に 15〜20 分ほど待つことが推奨されています（念のための措置）。
参考までに、Python ライブラリー（ibm_watsonx_ai）では、通常ユーザー向けにタスク認証情報を扱うメソッドが用意されています。
# タスク認証情報の作成
task_credentials_details = client.task_credentials.store()
# 一覧（返却される asset_id がタスク認証情報の ID）
client.task_credentials.list()
# 削除
client.task_credentials.delete(task_credentials_id)
ibm-watsonx-ai Pythonライブラリーを使用してタスク認証情報の作成、一覧、削除を行うノートブックを作成していますので参考にしてください。
7. 実運用上の典型パターン
ここまでの内容を踏まえ、サービスID を使ってデプロイメント・ジョブやスケジュール・ジョブを自動化する際の典型的な流れを示します。大きく3ステップです。
① サービスID を作成する
IBM Cloud の IAM で サービスID を作成します。自動化専用の主体として、目的が分かる名前を付け、必要最小限の IAM アクセスポリシー（対象サービス・対象リソースに限定）を割り当てます。あわせて、認証に使う サービスID の API キー を発行し、安全に保管します。
API キーは作成時にしか取得・ダウンロードできません。必ずその場で控えてください。
② 該当プロジェクト／デプロイメント・スペースにコラボレーターとして登録する
作成した サービスID を、対象の プロジェクト または デプロイメント・スペース にコラボレーターとして追加します。
- 対象のプロジェクト／デプロイメント・スペースで 管理 タブの アクセス制御 を開きます
- コラボレーターの追加 をクリックし、サービスIDの追加 を選択します
- サービスIDの検索 で対象の サービスID を検索して選択します
- ロール（ビューアー / エディター / 管理者）を選び、追加 で追加します
ジョブの実行やアセットの操作を伴う場合は、用途に応じて エディター 以上のロールが必要になります。最小権限の原則に従い、必要なロールに絞って付与してください。なお、この追加操作を行う側には IAM Identity Service の Operator ロールが必要です。
③ サービスID 用のタスク認証情報を作成する
最後に、前章の REST API 手順で サービスID 用のタスク認証情報を作成します。これにより、サービスID が起動するデプロイメント・ジョブやスケジュール・ジョブが、中断なく長時間実行できるようになります。
この3ステップを踏むことで、「人に紐づかない サービスID が、適切な権限でプロジェクト／デプロイメント・スペースにアクセスし、長時間ジョブを継続実行できる」 状態が完成します。担当者の異動・退職に影響されない、堅牢な自動化基盤になります。
8. まとめ
本記事では、IBM Cloud の サービスID を CP4DaaS / watsonx as a Service で活用するための基本概念と手順を整理しました。要点は次のとおりです。
- サービスID は人に紐づかない認証主体であり、自動化・外部連携・常時稼働の処理に適しています。一方で、UI への対話的ログインや、UI からのタスク認証情報作成はできません
- ユーザー API キー は個人に紐づくため手軽ですが、退職・異動でジョブが止まるリスクがあります。本番の自動化には、最小権限を設計でき監査しやすい サービスID の API キー を使うことが推奨されます
- タスク認証情報 は、UI 起点の長時間・非同期ジョブを継続実行するために Vault に保管される API キーです。ユーザーは UI から作成できますが、サービスID では REST API での登録が必要です
- 実運用では、① サービスID 作成 → ② プロジェクト／デプロイメント・スペースへコラボレーター登録 → ③ サービスID 用タスク認証情報の作成 という3ステップで、堅牢な自動化基盤を構築できます
権限設計（最小権限）、API キーの安全な保管、不要になったタスク認証情報の失効方針までを含めて運用ルールを定めておくことが、安全で継続的な運用の鍵になります。
参考リンク
おことわり
このサイトの掲載内容は私自身の見解であり、必ずしも所属会社の立場、戦略、意見を代表するものではありません。 記事は執筆時点の情報を元に書いているため、必ずしも最新情報であるとはかぎりません。 記事の内容の正確性には責任を負いません。自己責任で実行してください。