ゲーム開発を支えるワークロードID連携

こんにちは。運用基盤グループでビルドシステムの開発・運用を担当している会津です。

この記事では、ゲーム開発における自動化の仕組みづくりと、「マシンやサービス同士の連携をどう安全に行うか」という課題についてお話しします。また、この課題への我々の取り組みの中で、現在検証と開発を進めている最新情報について紹介します。

最初に、この記事で出てくる用語を簡単に説明しておきます。

用語	ざっくり言うと
ワークロード	人ではなく、マシン上で動いているプログラムやサービスのこと
ワークロードID	そのプログラムやサービスに割り当てられたID
短期トークン	一時的に使える「通行証」のようなもの。短期間(数分～数時間)で使えなくなる
認証キーファイル	サービスにアクセスするための「合鍵」が書かれたファイル。長期間有効なことが多く、コピーして持ち出せてしまう

1. なぜこの取り組みが大切なのか

ゲーム開発には、大まかに以下のような一連の流れがあります。

開発 → テスト → ビルド → 配布 → フィードバック

コロプラでは複数のゲームタイトルを並行して開発しており、この流れがタイトルごとに走っています。うまく自動化できると、良いものを早く作ることに直結します。

手作業で繋いでいる部分が多ければ、待ち時間が発生し、ミスも起きやすくなります。逆に、この流れが滑らかに自動で回るようになると、開発者は「ものを作る」ことに集中できるようになります。

つまり、これは単なる効率化の話ではなく、その会社で良いものを作るための再現性のある仕組みです。誰がやっても同じように動く基盤。これは大切なものだと考えています。

2. 自動化における課題

私たちが担当しているビルドシステムを例に、この自動化における連携の課題を具体的に見ていきます。

2.1. まずは具体例から ― 工夫しないとどうなるか

具体的にイメージしてみましょう。ある作業者が、例えば以下のような一連の自動処理を開始したとします。

① 作業者の作業が一区切りついて、PC上からビルド指示を出す
        ↓
② クラウドサービスで受け付ける
        ↓
③ 物理マシン上でゲーム空間内の自動テストを実行する
        ↓
④ 別のクラウド上のLinuxマシンとMacマシンでゲームデータを取得して並列ビルドする
        ↓
⑤ 社内の物理マシン（Windows）上でハードウェアキーを用いた暗号化処理をする
        ↓
⑥ 配信サービスや開発機に完成したゲームデータを配布する
        ↓
⑦ ダウンロードコンテンツをクラウドサービス上に配置する
        ↓
⑧ 通知サービスに報告する

このように、異なる環境のマシンやサービスをリレーのように渡り歩く処理の中で、「この処理を受け付けてよいか？」「この実行者にその権限はあるか？」といった判断が、各所で必要になります。

しかも、こうした処理は複数のゲームタイトルのプロジェクトで横断的に使えるよう、権限を適切に制御しつつ汎用的な仕組みが求められます。あるプロジェクトのビルド処理が、別のプロジェクトのデータに触れてしまってはいけません。

これを工夫せずに進めると、どうなるでしょうか。

そもそも設計が困難で、どのサービスとどう連携させるか、全体像を描くだけでも大変
サービスごとに認証キーファイルが必要になり、大量に発生して管理が追いつかなくなる
鍵ファイルは期限なしのものもあり、一度発行した鍵が有効なまま管理から漏れるリスクがある
外部から悪意をもって、こうした認証キーファイルを狙われるリスクがある

これは大変です。

2.2. なぜこんなに複雑になるのか ― 多様化の背景

先ほどの例で、PC・クラウド・物理マシン・Macなど、さまざまな環境が登場しました。なぜこれほど多様な環境が必要なのか、その背景を説明します。

2.2.1. 複数のOSや物理マシンとの連携

ゲームソフトは、さまざまなプラットフォーム向けに制作します。それぞれのプラットフォーム向けにゲームをビルドするには、特定のOSやハードウェアでなければ動かないツールが求められます。

このため、ビルド環境には特殊なハードウェアを搭載した物理マシンや、Windows・macOS・Linuxなど各種OSの環境が必要になります。

2.2.2. クラウドとの連携

開発の繁忙期や体制変更によって、ビルド処理の需要は急激に変化します。こうした波に対応するには、クラウドのオートスケーリング（負荷に応じてマシンの台数が自動的に増減する仕組み）が有効です。

また、関係会社や遠隔地の開発拠点、リモートワークなど、物理的なネットワークの制約に縛られずに利用できるメリットもあります。

2.2.3. 多様なサービスとの連携

ゲーム開発では、さまざまなデータを管理するためにいくつものサービスを使い分けます。

大きなバイナリデータ（テクスチャや3Dモデルなど）の管理に適したサービス
ソースコードの管理に適したサービス
社内ネットワークで自社運用するサービス

さらに、外部の便利なサービスや社内ツールをうまく連携させて、その恩恵を受けながら効率化することも重要です。

3. どう解決するか ― ワークロードID連携

ここで登場するのが、ワークロードID連携という考え方です。この項目は専門的な内容を含むため、概要だけ知りたい方はスキップしてもかまいません。

従来は、マシンやサービスに「合鍵のファイル」を配って認証していました。今回採用した仕組みでは、

「自分が何者であるか」をインフラ側が証明します。

具体的には、SPIFFE（スピッフィー）というオープンな標準規格と、それを実装したSPIRE（スパイア）というソフトウェアを使っています。

仕組みをざっくり説明します。

SPIRE ServerとSPIRE Agentは、事前に安全な方法（Node Attestation）で信頼関係を構築する
SPIRE Agentはマシン上のプロセスの要求に応じ、SPIRE Serverの情報を元に、そのプロセスをチェック（Workload Attestation）し、有効期限の短いID（SPIFFE ID）の証明書を発行する
プロセスは、有効期限の短い証明書を「自分はこのIDです」と相手に証明できる
証明書は自動で更新（ローテーション）されるので、人が手動で鍵を入れ替える必要がない
サーバー・エージェント間は信頼関係を一定期間で失うため、バックグラウンドで自動的に再認証し、信頼関係を構築し直す

flowchart TD
    S["SPIRE Server<br>IDの発行・管理を行う中央サーバ"] --> AL["SPIRE Agent<br>（Linux）"]
    S --> AM["SPIRE Agent<br>（macOS）"]
    AL --> B["ビルド"]
    AM --> T["テスト"]

Windows、macOS、Linuxといった異なるOSのマシン間でも、同じ仕組みでIDを扱えるのがポイントです。また、主要なクラウドサービスや、Kubernetes、Dockerなどでも動作します。

しかし、この共通IDで直接連携できないサービス（例えばGitHubや既存の社内サービス）もあります。そこでToken Brokerという仲介の仕組みを構築しました。Token Broker ServerはSPIFFE IDを元にアクセス制御を行い、対象サービス向けの短期トークンを発行して橋渡しをします。各マシン上のプログラムは、専用のCLIツールやAPIでトークンを取得します。

sequenceDiagram
    participant P as プログラム
    participant TB as Token Broker Server
    participant E as 外部サービス
    P->>P: ① SPIFFE IDを取得
    P->>TB: ② IDを提示してトークンを要求
    TB->>TB: ③ SPIFFE IDを検証
    TB->>E: ④ 短期トークンを取得
    TB->>P: ⑤ トークンを返却
    P->>E: ⑥ 短期トークンでサービスにアクセス

短期トークンを直接発行できないサービスについては、処理を代行する機能を提供する仕組みも用意できると考えています。
また、Token Brokerとは別に、この認証の仕組みを利用して、OSもプラットフォームも異なるサービスを繋げる、連携のハブとなるような仕組みも作っています。

これにより、先ほどの「リレーのような処理」でも、全体として同じIDで識別できます。また、ファイルとして保存された秘密情報を削減できます。

4. 副産物 ― やってみたら得られたもの

ワークロードID連携の概念実証を進める中で、当初想定していなかった嬉しい副産物がいくつもありました。

4.1. 物理マシンから認証キーファイルを排除できた

物理マシンにはTPM（Trusted Platform Module）というセキュリティ用の部品が搭載されていることがあります。これはマザーボード上にあるチップで、秘密鍵を内部に閉じ込めて外部から取り出せなくする機能を持っています。

SPIREはこのTPMに対応しており、TPM内の情報と実行ユーザーなどの情報を掛け合わせてプログラムを識別できます。この仕組みを活用して、対応した装置については認証キーファイルを排除できました。

マシンを物理的に盗まなければ鍵は手に入りませんが、ネットワーク上のアクセス制限もかけているので、仮に盗んでも使えません。

「鍵ファイルの管理を頑張る」のではなく、「鍵ファイルが存在しない状態を作る」というアプローチが可能となりました。

4.2. Google Cloudの標準認証の裏側で連携できた

Google CloudにはADC（Application Default Credentials：アプリケーションのデフォルト認証情報）という仕組みがあります。Google Cloudの公式CLIツールや標準ライブラリは、この仕組みを使って自動的に認証情報を取得します。今回の取り組みでは、Workload Identity Federationを利用して、ADCの裏側でワークロードID連携が動く構成が実現できました。これにより、既存のGoogle Cloud CLIツールや標準ライブラリをそのまま利用できる仕組みになっています。

アプリケーション側から見ると今まで通りの認証に見えるので、既存のコードに手を加える必要がないのは嬉しいです。

4.3. AI-Agentにも転用できそう

最近、コーディングエージェントなどのAI-Agentの活用が広がっています。ここで気になるのが、「AI-Agentにどこまでの権限を与えるか」という問題です。

強い権限を持った個人のアカウントでAI-Agentを動かした場合、意図しない操作をしてしまうと大きな事故になりかねません。

SPIRE Agentをノードに配置し、そのUnixドメインソケットをコンテナから参照する方式（ノード上のエージェントとコンテナが通信路だけを共有する構成）で、Token Broker経由のサービス連携が動作しています。

flowchart TD
    subgraph host["ホスト環境"]
        SA["SPIRE Agent"]
        subgraph container["コンテナ（隔離環境）"]
            AI["AI-Agent"]
            OK["できること<br>・ID取得<br>・トークン要求"]
            NG["できないこと<br>・秘密鍵参照<br>・範囲外アクセス"]
        end
        SA <-->|"接続"| AI
    end

コンテナ内にAI-Agentを隔離し、持ち出し可能な認証キーファイルがゼロの環境で、指定したサービスの権限だけを与えることができます。エージェントが想定外の操作を試みても、権限の範囲外にはアクセスできません。