GCPでVertex AIを使ってAIコーディングエージェントの認証をセキュアでポータブルに管理してみる

こんにちは、機械学習エンジニア / CTOの大垣です。このブログはAI・機械学習チームブログリレー 11日目の記事です。前日は池嶋さんによる「先週何したっけ？」をゼロに：Obsidian + Claude Codeを業務アシスタントに - エムスリーテックブログでした。後段にAI活用があることで結果的にメモ習慣も改善されるなぁと思いました。

さて、本日もAI活用の記事ですが、社内、特にAIコーディングエージェントから利用するときの認証の話をしようかなと思います。みなさんの会社ではAIコーディングエージェントの認証管理どうしていますか？

エムスリーでは、Gemini、Copilot、Devin、Cline、Roo Code、Claude Code、JetBrains AIなどコーディングへのAI活用がかなり幅広く行われています。 DevinやCopilot、JetBrains AIなどLLMモデルの利用料金を内包するタイプのアプリケーションもありますが、ClineやRoo CodeなどLLMモデルは別途用意して利用できるタイプのアプリケーションも多いです。後者のタイプのアプリケーションについては特に、ある程度統一的な認証方法を用意しておくと新たに使い始めるためのリードタイムが少なくなり、エンジニアのツール利用試行錯誤が早くなるので良いですよね。この目的で、エムスリーではある程度GCP Vertex AIを利用して統一的に管理しています。

📑 目次

GCPに乗ることで、認証の煩雑さを回避している一例として事例共有できればと思います。特にエムスリーではGoogle Workspaceを利用しているので、Google グループに対して権限を付与すれば、ローカルでの(あるいはGAS経由でも)認証のための鍵を意識して管理させる必要がないのが大きなメリットです。

今回採用した、GCP Vertex AIを利用することの良し悪しは以下です。

◎ 認証情報がgcloudコマンドで管理されるため、各個人が認証を意識する必要がなくセキュアでポータブル
◎ 社内ライブラリを作った場合も認証系はgcloudで管理されているため意識せず使えてポータブル
○ 権限の付与・剥奪をGoogle グループの管理に統一して行える
○ 社内アプリケーションとしてデプロイした場合もOAuthを利用して認証するので、ログから容易にどの個人が利用しているかがわかり管理上ありがたい
△ もちろんtokenを各自が作成可能にして、各自ローカルで設定して使ってもらう方法と比べると、管理側は多少仕組みの理解と準備は必要になるが、ユーザー側では手順が減り楽・利用が進むというメリットが大きいので採用

※ 今回はGCPをメインに話してますが、初動でChatGPTをAPIで利用し始めたのもあり、OpenAI Platformも全面利用してますし、プロダクトではServiceAccountに権限を付けてAWS Bedrockを利用することも多いです。現時点でClaude4を国内リージョンで使えるのもBedrockを選択する理由になっています。比較してVertex AIに決めきったというより、あくまでも各個人で認証するプロダクトではいまGCP Vertex AIを多用している、という形です。各方式良さがありますし、プロダクトやチーム特性で決めるべきで、どの方式かを全社で縛る必要はないと考えてます。

プロジェクトを作成してユーザーに権限を付与するまでの楽楽認証

GCP Project側

さて、GCP側で認証周りを持ってくれるので楽と書きましたが、管理側も最小限用意しなきゃいけないのはTerraformで書くと次のコードくらいです *1。エムスリーでは、利用量などが明確になりますし、既存のGCP Project相乗りではなくAIエージェント専用のProjectを作ってます。

terraform {
  backend "gcs" {
    bucket = "<Terraform用GCS>"
  }
}

provider "google" {
  project = "<プロジェクト名>"
}

data "google_project" "current" {}

resource "google_project_iam_member" "vertex_ai_user" {
  project = data.google_project.current.project_id
  role    = "roles/aiplatform.user"
  member  = "group:<LLMの利用権限を付与したいユーザー全員が入っているGoogle グループ>"
}

resource "google_project_service" "vertex_ai" {
  service            = "aiplatform.googleapis.com"
  disable_on_destroy = true
}

ユーザー側

GCPユーザーの皆様は馴染んでいるでしょうが、次のコマンドをシェルで実行するのみで ~/.config/gcloud/などに認証情報が作成されるため、あとは各AIエージェントが用意しているVertex AIの利用手段に任せればよいです。

gcloud auth login
gcloud auth application-default login

Claude Codeを使う場合の設定

Claude CodeくんももちろんVertex AIの認証に対応しているので、~/.claude/settings.json に次を追加するだけです。

{
  "env": {
    "CLAUDE_CODE_USE_VERTEX": "true",
    "CLOUD_ML_REGION": "us-east5",
    "ANTHROPIC_VERTEX_PROJECT_ID": "<GCPプロジェクト名>"
  }
}

Clineを利用する場合の設定

Clineくんも同様に、設定画面から設定するだけです。

利用量も楽楽確認

ここまでで利用に関してはOKです。ところで、認証が必ずユーザーのgoogleアカウントと紐づけとなるので、追加の嬉しさとして、ユーザーごとの利用量がメールアドレスと紐づいて調べやすいというのもあります。

これは非常にありがたい機能なので、先程のTerraformにAuditのリソースを追加することで監査ログをONにします。

resource "google_project_iam_audit_config" "vertex_ai_audit" {
  project = data.google_project.current.project_id
  service = "aiplatform.googleapis.com"

  audit_log_config {
    log_type = "DATA_READ"
  }

  audit_log_config {
    log_type = "DATA_WRITE"
  }
}

Cloud Loggingでresource.labels.service="aiplatform.googleapis.com" を見ると、次のようしっかりログされていることがわかりますね。

誰が、どのツールでどのモデルを読んでいるかが記録されているので、色々分析できそうです。このログをBigQueryにexportすることで分析に進めそうですね。

ログ分析用のダッシュボードも作っておく

さて、分析をBigQueryで進めても良いんですが、Cloud Monitoringのカスタム指標+ダッシュボードでサクッと可視化もできるので、エムスリーではこちらも設定しています。新しく作った指標のダッシュボードになるので、設定以降のログしかダッシュボードにでてこないのが残念ですが、次の手順でサクッと作れるのでやっておくと良いと思います。

ログベースの指標を作る

さっき生ログを眺めて見つけた3つの要素(ユーザー、ツール、モデル)をラベルとして出力する指標を作ります。

user_email,model_name,user_agentを出力できるように作った新しい指標。model_nameはprotoPayload.resourceNameから./models/(.)の正規表現で取り出すようにしている

ダッシュボードにグラフを作成する

先ほど作った指標を元にダッシュボードにグラフを作成していきます。ちなみに溜まった分からしかグラフは作れないので、1時間くらい待ってから作ったほうがわかりやすいです。

これらのダッシュボードからわかることですが、例えば2週間ウィンドウで見ると最大利用ユーザーは4万回呼び出していて、10営業日なので1日4000回利用していることになります。数字にするとすごい。平均して毎日使ってる人もいれば、特定の一日で集中して利用する人もいます。また、116人のユニークユーザーがいることがわかりますが、エムスリーのエンジニアは現在120人程度*2なのでほぼ全ユーザーが利用してることになります。

最後に、AIエージェントとモデルの分布を見てみると、Claude CodeからのClaude 3.5 Haikuの呼び出しが一番多いのがわかります。急激に利用者が増えました。次に多いsge/JSやNye/JSはClineからの利用のようです*3。ただしユーザー数が違うのか、ヘビーユーザーがClaude Codeを使ってるのかはまだわからないのでもう少し分析してみたいですね。

面白い使われ方も楽楽連携

さて、ここまでで個人のローカルからのAIエージェントの利用動向を見てきましたが、Vertex AIでの利用を設定したことで、次のような個人のAIエージェントではない面白い使われ方もでてきたので共有します。

Workload Identity FederationによりCIからAIレビュアーとしてClaude Codeを起動

下記の記事で詳しく書いたように、エムスリーではすでに、Workload Identity Federationの仕組みを使って、gitlabからGCP/AWSへの認証を秘密情報を新たにもたせずに行っています。今回のVertex AIも同様で、gitlab-ciからVertex AIの各呼び出しが行えます。この仕組みを使って、Merge RequestのレビューをClaude Codeで行うtemplateが作られており、各チームのファーストレビュアーとしてとても盛んに使われてます。

秘匿情報を持たない良さを表すエピソードとして、このレビュアーボットを1チームで使い始めたら、翌日にはgitlab-ciのincludeの仕組みを使って*4、ほぼ全チームに即座にAIレビュアーが設定されました。今回の仕組みでチームごとの特殊な認証を持たないし、Claude Codeはレポジトリを認識してくれるので、CIの定義をincludeするだけで全く設定なしでもある程度動くからです*5 *6。安全であることもですが、ポータブルであることの良さが強いです。