主なエラーの現象

サブエージェントがgoogle-vertexプロバイダを使用しようとすると、Google SDKが初期化する前に認証リゾルバがブロックエラーをスローします：

Error: No API key found for provider "google-vertex". Auth store: .../auth-profiles.json
    at resolveApiKeyForProvider (auth-profiles.js:247:15)
    at async sessions_spawn (router.js:892:4)
    at async handleAgentRequest (gateway.js:214:9)

CLI再現手順

bash

Attempt to spawn a sub-agent with google-vertex provider

curl -X POST http://localhost:3000/v1/sessions/spawn
-H “Content-Type: application/json”
-d ‘{ “agent”: “sub-agent”, “provider”: “google-vertex”, “model”: “gemini-2.0-flash-001” }’

期待される動作と実際の動作

環境コンテキスト

• Platform: macOS 26.3 (arm64) / Linux
• OpenClaw Version: 2026.2.26
• SDK: @google/genai
• Auth Type: Google Application Default Credentials（サービスアカウント）

アーキテクチャ分析

1. 認証ゲートのアーキテクチャ

OpenClawは、リクエスト処理前にすべてのプロバイダに対してAPIキー検証を強制する、集中型認証リゾルバをresolveApiKeyForProvider()に実装しています：

// Simplified auth gate logic (auth-profiles.js)
function resolveApiKeyForProvider(provider, authStore) {
  // ... normalization logic ...
  
  if (authOverride !== void 0) {
    return { apiKey: authOverride, source: "manual-override", mode: "api-key" };
  }
  
  // Check auth store for stored credentials
  const stored = authStore[normalized];
  if (stored) {
    return parseStoredCredentials(stored);
  }
  
  // THE GATE: Blocks if no credentials found
  throw new Error(`No API key found for provider "${normalized}"...`);
}

2. Bedrock例外パターン

amazon-bedrockは、静的APIキーではなくAWS SDK認証（IAMロール、環境変数、EC2メタデータ）を使用するため、例外として認められています：

// auth-profiles.js (existing Bedrock exception)
if (authOverride === void 0 && normalized === "amazon-bedrock") {
  return resolveAwsSdkAuthInfo();  // Returns { mode: "aws-sdk" }
}

3. 欠落しているgoogle-vertex例外

Google Vertex AIは同一の認証パターン（Application Default Credentials）を使用しますが、対応する例外が欠落しています。解決チェーンは以下のように進行します：

resolveApiKeyForProvider("google-vertex")
  → normalized = "google-vertex"
  → authOverride = undefined
  → normalized !== "amazon-bedrock" (スキップ)
  → authStore["google-vertex"] = undefined (保存された認証情報なし)
  → throw Error("No API key found...")  ← ここでブロック

4. モデル選択における下流への影響

pi-embedded-*.jsのモード検証は、非APIキーモードの明示的なホワイトリスト化をさらに必要とします：

// model-selection.js (current restrictive check)
if (apiKeyInfo.mode !== "aws-sdk" && apiKeyInfo.mode !== "api-key") {
  throw new Error("Invalid auth mode for model selection...");
}
// google-vertex ADC mode ("adc") would also fail this check

5. SDK認証とプラットフォーム認証の不一致

@google/genaiSDKは以下から自動的に認証情報を解決するように設計されています：

• GOOGLE_APPLICATION_CREDENTIALS（サービスアカウントJSON）
• GOOGLE_CLOUD_PROJECT（プロジェクトID）
• GOOGLE_CLOUD_LOCATION（リージョン、例：us-central1）
• アタッチされたサービスアカウント（GCE、Cloud Runなど）

OpenClawのAPIキゲートはSDKがネイティブ認証を実行する前にリクエストを傍受し、不可能な要件を作り出しています。

前提条件

• Google ADCが適切に構成されていることを確認：

  # Check service account credentials exist
  ls -la $GOOGLE_APPLICATION_CREDENTIALS
  Verify gcloud auth (alternative)
  gcloud auth application-default login
  Test SDK can resolve credentials
  node -e “const {GoogleAuth} = require(‘google-auth-library’); new GoogleAuth().getClient()"

• 必要な環境変数を設定：

  export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"
  export GOOGLE_CLOUD_PROJECT="your-project-id"
  export GOOGLE_CLOUD_LOCATION="us-central1"

パッチ1：auth-profiles.js

場所：src/auth/auth-profiles.js（またはdist/同等物）

アクション：Bedrock例外の後にgoogle-vertexのADCパススルーを追加。

修正前

if (authOverride === void 0 && normalized === "amazon-bedrock") {
  return resolveAwsSdkAuthInfo();
}
// ... rest of resolver

修正後

if (authOverride === void 0 && normalized === "amazon-bedrock") {
  return resolveAwsSdkAuthInfo();
}

// Google Vertex AI ADC passthrough
if (authOverride === void 0 && normalized === "google-vertex") {
  return {
    apiKey: "adc-passthrough",
    source: "google-adc",
    mode: "adc"
  };
}
// ... rest of resolver

パッチ2：model-selection.js

場所：src/model-selection/model-selection.js

アクション：受け入れ可能モードリストに"adc"を追加。

修正前

if (apiKeyInfo.mode !== "aws-sdk" && apiKeyInfo.mode !== "api-key") {
  throw new Error("Invalid authentication mode for model selection...");
}

修正後

if (apiKeyInfo.mode !== "aws-sdk" && apiKeyInfo.mode !== "api-key" && apiKeyInfo.mode !== "adc") {
  throw new Error("Invalid authentication mode for model selection...");
}

パッチ3：pi-embedded-*.js（ゲートウェイモードチェック）

場所：src/gateway/pi-embedded.jsまたは同等物

アクション：ゲートウェイ認証チェックでADCモードが受け入れられることを確認。

修正前

if (apiKeyInfo.mode !== "aws-sdk" && apiKeyInfo.mode !== "adc") {
  throw new AuthenticationError("Unsupported auth mode");
}

修正後

// Verify GOOGLE_* environment variables are present for ADC providers
if (apiKeyInfo.mode === "adc") {
  if (!process.env.GOOGLE_CLOUD_PROJECT) {
    throw new AuthenticationError("GOOGLE_CLOUD_PROJECT not set for ADC authentication");
  }
  if (!process.env.GOOGLE_CLOUD_LOCATION) {
    throw new AuthenticationError("GOOGLE_CLOUD_LOCATION not set for ADC authentication");
  }
}

代替手段：コンフィグレーションベースの修正

ソースファイルにパッチを当てたくない場合は、openclaw.config.jsに追加します：

module.exports = {
  providers: {
    "google-vertex": {
      authStrategy: "adc",
      envVars: ["GOOGLE_CLOUD_PROJECT", "GOOGLE_CLOUD_LOCATION"]
    }
  }
};

手順1：認証リゾルバがADCモードを返すことを確認

bash

Start a Node REPL in the OpenClaw context

node -e " const { resolveApiKeyForProvider } = require(’./dist/auth/auth-profiles.js’); const result = resolveApiKeyForProvider(‘google-vertex’, {}); console.log(JSON.stringify(result, null, 2)); "

期待される出力：

json { “apiKey”: “adc-passthrough”, “source”: “google-adc”, “mode”: “adc” }

手順2：サブエージェントのスポーンが動作することを確認

bash

Set environment variables

export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json” export GOOGLE_CLOUD_PROJECT=“your-project-id” export GOOGLE_CLOUD_LOCATION=“us-central1”

Test sub-agent spawn via CLI

openclaw agents spawn
–provider google-vertex
–model gemini-2.0-flash-001
–session-id test-session-001

期待される出力：

[INFO] Spawning sub-agent with google-vertex provider [INFO] Auth mode: adc (Google ADC passthrough) [INFO] Sub-agent spawned successfully: agent-abc123

手順3：実際のVertex API呼び出しを確認

javascript // test-vertex-adc.js const { VertexAI } = require(’@google-cloud/vertexai’);

async function test() { const vertex = new VertexAI({ project: process.env.GOOGLE_CLOUD_PROJECT, location: process.env.GOOGLE_CLOUD_LOCATION, });

const model = vertex.getGenerativeModel({ model: ‘gemini-2.0-flash-001’ }); const result = await model.generateContent(‘Hello, testing ADC auth.’); console.log(‘Response:’, result.response.text()); }

test().catch(console.error);

bash node test-vertex-adc.js

期待される出力：

Response: Hello! I’m ready to help you test…

手順4：APIキーファイルが不要であることを確認

bash

Confirm auth-profiles.json does NOT need google-vertex entry

cat ~/.openclaw/auth-profiles.json | jq ‘.[“google-vertex”]’

Expected: null (no entry needed)

手順5：Sessions APIでの統合テスト

bash

Create session with google-vertex sub-agent

curl -X POST http://localhost:3000/v1/sessions
-H “Content-Type: application/json”
-d ‘{ “agentType”: “sub-agent”, “provider”: “google-vertex”, “model”: “gemini-2.0-flash-001” }’

Verify response does NOT contain auth error

Expected: 200 OK with session object

1. 環境変数の欠落

症状：SDKがサイレントに失敗するか、不可解な認証情報エラーをスロー。

• GOOGLE_CLOUD_PROJECT — すべてのVertex AI呼び出しに必須
• GOOGLE_CLOUD_LOCATION — 必須（例：us-central1、europe-west4）
• GOOGLE_APPLICATION_CREDENTIALS — ローカル開発には必須；GCPインフラではオプション

修正：.envファイルまたはデプロイメントコンフィグに追加：

GOOGLE_CLOUD_PROJECT=my-gcp-project
GOOGLE_CLOUD_LOCATION=us-central1
GOOGLE_APPLICATION_CREDENTIALS=/secrets/service-account.json

2. 期限切れまたは無効なサービスアカウント認証情報

症状：Error: Unable to read credential fileまたはPERMISSION_DENIED

bash

Verify service account key is valid

cat $GOOGLE_APPLICATION_CREDENTIALS | jq ‘.type’ # Should output “service_account”

Check service account has Vertex AI permissions

gcloud projects get-iam-policy $GOOGLE_CLOUD_PROJECT
–filter=“bindings.members:serviceAccount:YOUR-SA@PROJECT.iam.gserviceaccount.com”

3. プロバイダ名の正規化の誤り

症状：認証ゲートは通過するが、SDKがUNKNOWN_PROVIDERで失敗。

OpenClawはプロバイダ名をケバブケースに正規化します。以下を使用していることを確認：

• google-vertex（正しい）
• ❌ google_vertex（間違い）
• ❌ GoogleVertexAI（間違い）
• ❌ vertex-ai（間違い - これは別のパプロバイダ）

4. APIキー認証とADC認証の混在

症状：サブエージェントは動作するが、誤った認証情報を使用（ユーザーのAPIキーとサービスアカウント）。

GOOGLE_API_KEY環境変数が設定されていると、@google/genaiSDKがADCよりそれを優先する可能性があります。純粋なADC使用の場合：

bash unset GOOGLE_API_KEY

5. Dockerコンテナ環境

症状：ローカルでは動作するが、DockerではADC resolution failedで失敗。

Docker内で実行する場合：

• サービスアカウントJSONをマウント：

  docker run -v /path/to/service-account.json:/secrets/sa.json \
        -e GOOGLE_APPLICATION_CREDENTIALS=/secrets/sa.json \
        my-openclaw-image

• またはGCPワークロードアイデンティティを使用してDockerを実行：

  docker run --device /dev/sdb ...  # セキュリティ上の理由からお勧めしません

6. リージョンの不一致

症状：INVALID_ARGUMENT: Region 'us-central1' is not supported for model 'gemini-2.0-flash-001'

お使いのリージョンでのモデル可用性を確認：

gcloud ai models list --region us-central1

• NO_API_KEY_FOUND

  任意のプロバイダの認証情報が設定されていない場合の一般的なエラー。auth-profiles.jsonが空または破損している場合に任意のプロバイダに影響する可能性がある。

• AUTH_MODE_UNSUPPORTED

  認証モードがホワイトリストにない場合にmodel-selection.jsによってスローされる。ADCパススルーパッチ適用後でもpi-embedded-*.jsが更新されていない場合に発生。

• AWS_SDK_AUTH_FAILED

  Google Vertexの問題と類似したBedrock用のエラー。AWS認証情報がない、または期限切れで、適切なIAMロール構成なしでamazon-bedrockを使用する場合に発生。

• GOOGLE_ADC_RESOLUTION_FAILED

  Google ADCが有効な認証情報を見つけられない場合の基盤となるSDKエラー。これはOpenClawの認証ゲートが通過した後、表面化する必要があることを示し、パススルーが動作しているが基盤となるADC設定が壊れていることを意味する。

• SESSION_SPAWN_AUTH_BLOCKED

  認証リゾルバがスをスローした場合のsessions_spawnハンドラーからのエラー。特定のエラーメッセージは「No API key found for provider 'google-vertex'」を示す。

• INVALID_AUTH_MODE_TRANSITION

  ランタイムでapi-keyからadcへの認証モード遷移が許可されない高セキュリティ構成で発生。

исторический контекст