Forem: Akira

MCPサーバーテストプレイブック：Apidogを活用した手動・自動テスト

Akira — Mon, 11 May 2026 08:53:19 +0000

「Ableton Live MCP」のShow HN投稿が今週初め、118ポイントと78件のコメントを獲得しました。Model Context Protocol（MCP）は、Anthropic専用の実験から、1年足らずでエージェント統合の事実上のレイヤーへ広がりました。今では、Claude Desktop、Cursor、独自エージェントから外部ツール・リソース・プロンプトを呼び出すための実装対象として扱われています。

今すぐApidogを試す

一方で、MCPサーバーのテスト方法はまだ整っていません。stdio経由でJSON-RPCを手動実行する方法は「hello world」には十分ですが、ツールが12個、プロンプトが3個、外部API依存があるサーバーではすぐに破綻します。

この記事では、MCPサーバーを手動で検証し、その後 Apidog で自動テスト化する手順をまとめます。目的は、MCPサーバーを通常のAPIと同じように、契約、モック、回帰テスト付きで出荷できる状態にすることです。

より広いエージェント設計の文脈から来ている場合は、agents.mdガイドも合わせて読むと、MCPサーバーの契約をチームで共有しやすくなります。

TL;DR

MCP はAnthropicのModel Context Protocolであり、stdioまたはHTTP上のJSON-RPC 2.0として動作します。
主なプリミティブは、ツール、リソース、プロンプトです。
MCPサーバーのテストでは、主に initialize、tools/list、tools/call、resources/read、prompts/get の応答を検証します。
最初はMCP Inspectorやstdioで手動確認し、ワイヤーレベルのリクエスト・レスポンスを把握します。
次に Apidog にJSON-RPCリクエストを保存し、JSONPathアサーション、モック、CI実行を追加します。
外部API依存はApidogのモックサーバーで置き換え、CIを高速かつ決定論的にします。
リクエストコレクション、モック、CIランナーをまとめて使う場合は、Apidogをダウンロードしてください。

MCPの正体を短く整理する

Model Context Protocol仕様は、AIクライアントと外部機能をつなぐJSON-RPC 2.0ベースのプロトコルです。

クライアントには、たとえば次のようなものがあります。

Claude Desktop
Cursor
独自のAIエージェント
MCP対応IDEや開発ツール

MCPクライアントはサーバーを起動し、最初に initialize ハンドシェイクを実行します。その後、ツール、リソース、プロンプトに対してJSON-RPC呼び出しを行います。

テストで特に重要なのは次の呼び出しです。

メソッド	目的
`initialize`	プロトコルバージョンと機能のネゴシエーション
`tools/list`	公開ツールと入力スキーマの一覧取得
`tools/call`	ツールの実行
`resources/list`	読み取り可能なリソース一覧の取得
`resources/read`	URI指定リソースの読み取り
`prompts/list`	プロンプトテンプレート一覧の取得
`prompts/get`	プロンプトテンプレートのレンダリング

トランスポートは主に2種類です。

stdio：stdin/stdoutで改行区切りのJSON-RPCフレームをやり取りする
HTTP：通常は POST / とSSEを使ってストリーミングする

ローカルMCPサーバーはstdio、リモートMCPサーバーはHTTPを使うことが多いです。

MCPでは、tools/list のレスポンス形状が壊れるだけで、Claude DesktopやCursorなど複数のクライアントが同時にツールを認識できなくなります。したがって、MCPサーバーは通常のAPIと同じく契約テストが必要です。

MCPサーバーでテストすべき項目

堅牢なMCPサーバーテストでは、少なくとも次の6領域を確認します。

1. プロトコル準拠

initialize が正しい protocolVersion を返すか確認します。

例：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2026-04-01",
    "capabilities": {
      "tools": {},
      "resources": {},
      "prompts": {}
    },
    "serverInfo": {
      "name": "example-mcp-server",
      "version": "1.0.0"
    }
  }
}

確認ポイント：

protocolVersion が期待値と一致する
実際に対応している機能だけを capabilities に出している
serverInfo.name と serverInfo.version が存在する

2. スキーマの正確性

tools/list 内の各ツールに、正しい inputSchema があるか確認します。

見るべき項目：

name が一意である
description が空ではない
inputSchema が有効なJSON Schemaである
必須引数が required に入っている
型が実装と一致している

悪い例：

{
  "name": "get_weather",
  "description": "",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": {}
    }
  }
}

改善例：

{
  "name": "get_weather",
  "description": "指定した都市の現在の天気を取得します。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "天気を取得する都市名。例: Tokyo"
      }
    },
    "required": ["city"]
  }
}

3. ツールの動作

tools/call が期待通りのコンテンツブロックを返すか確認します。

成功時の例：

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tokyo: 24°C, cloudy"
      }
    ]
  }
}

確認ポイント：

content が配列である
各ブロックに type がある
text、image、resource などの型が仕様に沿っている
成功時に isError: true が付いていない

4. ツールのエラー処理

MCPでは、ツール実行時の失敗はJSON-RPCエラーではなく、通常の結果として返します。

推奨されるエラー例：

{
  "jsonrpc": "2.0",
  "id": 43,
  "result": {
    "isError": true,
    "content": [
      {
        "type": "text",
        "text": "city is required"
      }
    ]
  }
}

避けるべき例：

{
  "jsonrpc": "2.0",
  "id": 43,
  "error": {
    "code": -32602,
    "message": "city is required"
  }
}

JSON-RPCエラーは、プロトコルレベルの失敗を示します。ツール内部の入力エラーや外部APIエラーに使うと、クライアントが接続を閉じる場合があります。

5. リソースアクセス

resources/list で返したURIが、resources/read で実際に読めるか確認します。

確認ポイント：

URIが安定している
resources/read が同じURIを解決できる
ページネーションがある場合、2ページ目以降も読める
存在しないURIに対して適切なエラーを返す

6. プロンプトのレンダリング

prompts/get が正しい messages 配列を返すか確認します。

確認ポイント：

messages が配列である
各メッセージに role と content がある
引数が正しい位置に展開される
必須引数が不足した場合にエラーになる

stdioでMCPサーバーを手動テストする

まずは自動化せず、MCPサーバーがワイヤーレベルで何を返すか確認します。

まだサーバーを作っていない場合は、PythonまたはTypeScriptで公式MCP SDKクイックスタートを使って最小構成を作成します。

MCP Inspectorで起動確認する

npx @modelcontextprotocol/inspector node your-server.js

MCP Inspectorは、MCPサーバーと通信するローカルWeb UIを起動します。

ここで確認すること：

サーバーが起動する
initialize が成功する
tools/list が表示される
各ツールを手動実行できる
エラー時のレスポンス形状が正しい

生のstdioでJSON-RPCを送る

Inspectorで問題がなければ、次は生のJSON-RPCを送ります。

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-04-01","capabilities":{}}}' | node your-server.js

次に、tools/list を送ります。

echo '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' | node your-server.js

ツール呼び出しの例：

echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"Tokyo"}}}' | node your-server.js

この段階で、次のリクエスト・レスポンスを保存しておきます。

initialize
tools/list
主要ツールの正常系 tools/call
主要ツールの異常系 tools/call
resources/list
resources/read
prompts/list
prompts/get

これらが、後で Apidog に登録する契約テストの元になります。

手動テストからApidogでの自動化へ移行する

手動テストは、初期の形状バグを見つけるには有効です。しかし、次のような状態になったら自動化が必要です。

ツール数が増えてきた
外部API依存がある
PRごとに回帰確認したい
tools/list のスキーマ変更を検知したい
Claude Desktopで毎回手動確認するのが遅い

基本パターンは次の通りです。

手動で取得したJSON-RPCリクエストをApidogに保存する
各レスポンスにJSONPathアサーションを追加する
外部APIをモックする
CIでスイートを実行する

1. MCPサーバー用のApidogプロジェクトを作成する

Apidogで新しいプロジェクトを作成します。

HTTP MCPサーバーの場合は、ベースURLにMCPサーバーのHTTPエンドポイントを設定します。

例：

http://localhost:3000

stdioのみのMCPサーバーの場合は、テスト用に薄いHTTPラッパーを用意します。公式Inspectorを使うか、HTTPで受け取ったJSON-RPCをstdioに転送する小さなNode.jsスクリプトを使います。

たとえば、テスト用ラッパーの構成は次のようになります。

Apidog
  -> HTTP POST /rpc
    -> wrapper.js
      -> stdio
        -> your-server.js

非HTTPバックエンドをHTTP経由でテストする考え方は、2026年のPostmanなしのAPIテストでも同じです。

2. 標準リクエストを保存する

Apidogに、MCPの主要メソッドをリクエストとして保存します。

最低限、次を登録します。

initialize
tools/list
tools/call 正常系
tools/call 異常系
resources/list
resources/read
prompts/list
prompts/get

tools/call のリクエストボディ例：

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Tokyo"
    }
  }
}

異常系も必ず保存します。

{
  "jsonrpc": "2.0",
  "id": 43,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {}
  }
}

3. JSONPathアサーションを追加する

自動テストで重要なのは、リクエストを送ることではなく、レスポンスの契約を検証することです。

`initialize` のアサーション例

確認項目：

$.result.protocolVersion が期待値と一致する
$.result.capabilities が存在する
$.result.serverInfo.name が存在する

例：

$.result.protocolVersion == "2026-04-01"
$.result.capabilities exists
$.result.serverInfo.name exists

`tools/list` のアサーション例

確認項目：

$.result.tools が存在する
$.result.tools が空でない
各ツールに name がある
各ツールに description がある
各ツールに inputSchema がある

例：

$.result.tools exists
$.result.tools.length > 0
$.result.tools[0].name exists
$.result.tools[0].description exists
$.result.tools[0].inputSchema exists

ツール数が固定されている場合は、件数も検証できます。

$.result.tools.length == 10

`tools/call` 正常系のアサーション例

確認項目：

$.result.content が配列である
$.result.content[0].type が期待値と一致する
$.result.isError が存在しない、または false

例：

$.result.content exists
$.result.content[0].type == "text"
$.result.isError != true

`tools/call` 異常系のアサーション例

確認項目：

$.result.isError が true
エラーメッセージが存在する
JSON-RPCの error ではなく result として返る

例：

$.result.isError == true
$.result.content[0].text exists
$.error not exists

エラーメッセージの完全一致は避け、安定したエラーコードや正規表現で検証する方が安全です。

4. アップストリームAPIをモックする

多くのMCPサーバーは、外部APIをラップします。

例：

天気API
GitHub
Linear
Notion
社内データベース
インシデント管理API

CIで毎回ライブAPIを呼ぶと、次の問題が起きます。

レート制限に引っかかる
ネットワーク障害でテストが落ちる
テスト結果がデータ状態に依存する
外部API利用コストが増える

この部分はApidogのモックサーバーで置き換えます。

手順：

Apidogで外部APIのエンドポイントを定義する
レスポンス例を登録する
モックサーバーを起動する
テスト時だけMCPサーバーの外部API URLをモックURLに向ける
本番実行時は実APIのURLに戻す

設定例：

# CI
WEATHER_API_BASE_URL=https://mock.apidog.com/project/xxx

# production
WEATHER_API_BASE_URL=https://api.weather.example.com

モックを使うことで、MCPサーバーのテストは次のようになります。

外部ネットワークに依存しない
数秒で終わる
毎回同じ結果になる
スキーマ回帰を早期に検知できる

モックを使った契約優先のワークフローは、契約優先のAPI開発でも詳しく説明しています。

5. CIでMCPテストスイートを実行する

ApidogプロジェクトはCLIランナーで実行できます。apidog run は保存済みリクエストを実行し、アサーションを評価し、失敗時に非ゼロで終了します。

GitHub Actionsの最小構成例：

name: MCP server tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci

      - name: Start MCP HTTP wrapper
        run: node test/wrapper.js &

      - name: Run Apidog suite
        run: npx apidog run --project-id $APIDOG_PROJECT --env ci
        env:
          APIDOG_PROJECT: ${{ secrets.APIDOG_PROJECT }}
          APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}

これで、すべてのpushとpull requestでMCP契約テストが実行されます。

tools/list のスキーマ変更、必須引数の欠落、ツールのエラー形式の崩れは、リリース前に検知できます。

良いMCPテストカバレッジの目安

Apidog でMCPサーバーをテストする場合、現実的なスイートは次の構成になります。

initialize：1件
tools/list：1件
各ツールの tools/call：2〜4件
- 正常系
- 必須引数不足
- 型不正
- 外部APIエラー
各リソースファミリーの resources/list：1件
各リソースファミリーの resources/read：1件
各プロンプトの prompts/list：1件
各プロンプトの prompts/get：1件

たとえば、次のMCPサーバーを考えます。

ツール：10個
リソース：3種類
プロンプト：4個

この場合、テストスイートはおおよそ50〜70リクエストになります。モックサーバーを使えば、ローカルでもCIでも短時間で実行できます。

MCPサーバーテストでよくある間違い

`initialize` を省略する

一部のMCPサーバーは、initialize のタイミングでツールレジストリや設定を初期化します。

そのため、いきなり tools/list を呼ぶと落ちる場合があります。

必ず次の順序でテストします。

initialize
tools/list
tools/call
resources/*
prompts/*

エラーメッセージを完全一致で検証する

エラーテキストは変更されやすいため、完全一致は壊れやすいです。

避けたい例：

$.result.content[0].text == "city is required"

より安定した例：

$.result.isError == true
$.result.content[0].text contains "city"

可能であれば、ツール側で安定したエラーコードを含める設計にします。

モックと本番レスポンスが乖離する

モックが実APIと違う形状を返していると、テストは成功しても本番で壊れます。

対策：

リリースごとに実APIレスポンスからモックを更新する
重要な外部APIは契約テストを別途持つ
モックフィクスチャをレビュー対象にする

ストリーミングをテストしない

HTTP MCPサーバーはSSEでツール結果をストリーミングすることがあります。

確認ポイント：

SSEを有効にしたリクエストでテストする
組み立て後の結果に対してアサーションする
タイムアウトや途中切断も確認する

Apidogは保存済みリクエストでSSEを扱えます。HTTP MCPサーバーをテストする場合は、リクエスト設定でストリーミングを有効にしてください。

並行実行をテストしない

MCPクライアントは、エージェントループ内で複数の tools/call を並行実行することがあります。

単一リクエストでは成功しても、共有状態やキャッシュが原因で本番だけ壊れるケースがあります。

確認すべきこと：

同じツールを同時に複数回呼ぶ
異なるツールを同時に呼ぶ
外部APIモックに遅延を入れる
タイムアウト時の挙動を見る

プロトコルエラーとツールエラーを混同する

MCPでは、プロトコルレベルの失敗とツール実行の失敗を分けます。

JSON-RPCエラー：不正なメソッド、無効なJSON-RPC、プロトコル違反
isError: true：ツール実行時の入力エラー、外部APIエラー、業務エラー

これを混同すると、Claude Desktopなどのクライアントが接続を閉じる場合があります。同様の契約バグについては、APIプラットフォームの契約優先開発でも扱っています。

実世界のユースケース

社内インシデント管理MCPサーバー

あるチームは、社内インシデント管理API用のMCPサーバーを構築しました。

Apidogで tools/list の形状にアサーションを追加したところ、1週間で3件の回帰を検出しました。いずれも、Claude Desktopを使うエンジニア全員に壊れたツール定義が配布される可能性がある変更でした。

Notion用オープンソースMCPサーバー

Notion向けMCPサーバーを公開している開発者は、Apidogモックを使ってCI中のNotion API呼び出しを置き換えています。

結果：

Notionのレート制限に依存しない
すべてのPRでテストが走る
コントリビューターがNotion APIキーを持つ必要がない
テストが数秒で完了する

複数MCPサーバーを運用するプラットフォームチーム

14個の内部MCPサーバーを運用するチームでは、各サーバーの契約を共有Apidogワークスペースに置いています。

新しいMCPサーバーはベーステストスイートを継承し、レビュー担当者はマージ前にスキーマ差分を確認できます。

特に tools/list のアサーションにより、引数名変更による大規模なクライアント影響を事前に検知できました。

実装チェックリスト

MCPサーバーのテストを始めるなら、次の順で進めるのが実用的です。

MCP Inspectorでサーバーを起動する
initialize が成功することを確認する
tools/list のレスポンスを保存する
各ツールの正常系 tools/call を実行する
各ツールの異常系 tools/call を実行する
resources/* と prompts/* を確認する
ApidogにJSON-RPCリクエストを登録する
JSONPathアサーションを追加する
外部APIをApidogモックに置き換える
CIで apidog run を実行する

結論

MCPは急速に普及しましたが、テスト方法はまだ手動中心です。しかし、MCPサーバーはJSON-RPC APIです。REST APIと同じように、契約、モック、CIによる回帰テストを持つべきです。

要点は次の5つです。

MCPサーバーはJSON-RPC APIとして扱う
最初はMCP Inspectorとstdioで手動確認する
手動で得たリクエストを Apidog に保存する
initialize、tools/list、tools/call、resources/read、prompts/get にアサーションを追加する
外部APIは Apidog のモックで置き換え、CIを安定させる

次のステップはシンプルです。Apidog でプロジェクトを作成し、手動でキャプチャした tools/list のリクエストを貼り付け、JSONPathアサーションを1つ追加してください。そこから、MCPサーバーの契約テストを段階的に拡張できます。

よくある質問

MCPとは何ですか？

MCP（Model Context Protocol）は、AIクライアントが外部ツール、リソース、プロンプトを呼び出すためのAnthropicのオープン仕様です。stdioまたはストリーミング可能なHTTP上でJSON-RPC 2.0として動作します。

MCPの完全な仕様は modelcontextprotocol.io で公開されています。

HTTPラッパーなしでMCPサーバーをテストできますか？

手動テストなら可能です。公式MCPインスペクターはstdioと直接通信できます。

ただし、Apidog で自動テストする場合は、CI中だけstdioを薄いHTTPラッパーで包む構成が実用的です。本番トラフィックは引き続きstdioのままで問題ありません。

MCPサーバーが呼び出す外部APIはどうモックしますか？

Apidogプロジェクトで外部APIエンドポイントをモックとして定義します。テスト中はMCPサーバーの設定をモックURLに向け、本番では実URLに切り替えます。

同じパターンは QAエンジニア向けのAPIテストツールでも説明しています。

ツール結果のストリーミングはどうテストしますか？

HTTP MCPサーバーはSSEでツール結果をストリーミングすることがあります。Apidogの保存済みリクエストでSSEを有効にし、組み立て後の結果に対してアサーションを実行します。

プロトコルバージョンはテストすべきですか？

はい。initialize の protocolVersion は必ず固定してアサーションしてください。ここがずれると、クライアントとの互換性問題がサイレントに発生します。

実際のClaude Desktopに対してテストすべきですか？

はい。リリース前のスモークテストとしては有効です。

ただし、Claude Desktopを回帰テストの中心に置くべきではありません。手動で遅く、非決定論的だからです。回帰テストは Apidog で自動化し、Claude Desktopは最終確認に使うのが実用的です。

実際のMCPサーバー実装はどこで見られますか？

公式MCPサーバーリポジトリに、ファイルシステム、GitHub、Slack、Postgresなどのリファレンス実装があります。ツール定義、入力スキーマ、エラー処理を見ると、良いMCPサーバーの形状を理解しやすくなります。

Maigretとは何か：壊れないOSINTスキャナー

Akira — Mon, 11 May 2026 06:09:14 +0000

ほとんどのOSINTツールは、ウェブサイトのURL構造変更、エンドポイント移動、CAPTCHA強化によってすぐに古くなります。Maigretは例外です。3,000以上のサイトに対応し、Pythonパッケージ、Telegramボット、Web UIを提供しながら、長期間メンテナンスされ続けています。この記事では、Maigretの実装パターンを分解し、壊れにくいスキャナーやAPIテスト設計にどう応用できるかを解説します。

今すぐApidogを試す

このガイドは、単に「ユーザー名を検索する方法」ではなく、エンジニア向けにMaigretの設計を読むためのものです。Maigretが何をしているのか、合法的な調査・セキュリティ用途は何か、数千サイトにスケールする仕組みは何か、そしてシグネチャデータベース、ドリフト検出、再帰的検証といった考え方を、日々のAPIテストやApidogでの検証にどう転用できるかを扱います。

まだ読んでいない場合は、2026年版 PostmanなしのAPIテストも参考になります。この記事では、パターンマッチングやドリフト検出をAPIテストの文脈で扱っています。

要約（TL;DR）

Maigretは、ユーザー名を入力すると3,000以上のサイトで公開アカウントをチェックし、プロフィール情報を抽出します。
中核は、バージョン管理されたサイトシグネチャデータベースです。
検出は単純なHTTPステータスコードではなく、存在文字列、不在文字列、正規表現、ヘッダー、タグなどの複数シグナルで行われます。
正当な用途には、OSINT調査、アカウント回復、行方不明者捜索、ブランド悪用監視、承認済みレッドチーム活動があります。
個人の同意なしに使用すると、ハラスメントやストーキングに該当する可能性があります。
Maigretの設計パターンは、APIテストにもそのまま応用できます。シグネチャ駆動、多信号アサーション、定期リプレイ、ドリフト検出は、ApidogでのAPI検証にも有効です。

Maigretとは何か、そして何ではないか

Maigretは、soxojによってメンテナンスされているMITライセンスのPythonツールです。READMEでは「3,000以上のサイトからユーザー名で個人の情報を収集する」と説明されています。

基本的な使い方は次のような流れです。

pip install maigret
maigret username

Maigretはサイトデータベースを参照し、対象ユーザー名が各サイトに存在するかを確認し、見つかった公開プロフィールから情報を抽出してレポートを生成します。

重要な前提は3つあります。

1つ目は、Maigretが扱うのは公開データのみだということです。ログイン、認証情報の悪用、APIキーの利用は行いません。匿名アクセスで見えるプロフィールページがあれば読み取り、見えなければ「見つからない」または「不明」と判断します。

2つ目は、正当な調査の文脈で使われていることです。調査報道、行方不明者捜索、詐欺対策、ブランド保護、承認済みレッドチーム活動などで利用されています。

3つ目は、悪用可能性があることです。本人の同意なく個人を追跡する目的で実行すると、倫理的にも法的にも問題になります。この記事では、人をターゲットにする手順ではなく、ツール設計とAPIテストに応用できる実装パターンに焦点を当てます。

サイトシグネチャデータベース

Maigretの中心は、サイトごとのシグネチャデータベースです。各エントリは、スキャナーが次の判断を行えるだけの情報を持っています。

対象サイトでユーザー名をどうURLに埋め込むか
アカウントが存在する場合、ページに何が表示されるか
アカウントが存在しない場合、ページに何が表示されるか
公開プロフィールからどの情報を抽出できるか
レート制限やCAPTCHAの可能性があるか

このデータベースはJSON形式で管理され、リポジトリでバージョン管理されています。Maigretは実行時にGitHubから更新を取得できるため、サイト側の変更に追従しやすくなっています。

APIテストでも同じ考え方が使えます。各エンドポイントには、次のような「シグネチャ」があります。

{
  "endpoint": "GET /users/{id}",
  "expectedStatus": 200,
  "requiredFields": ["id", "name", "email"],
  "forbiddenFields": ["password"],
  "requiredHeaders": ["content-type"]
}

エンドポイントが増えるほど、チェックをコードに直接書くより、データとして管理した方が保守しやすくなります。コントラクトファーストAPI開発やMCPサーバーテストプレイブックでも同じ発想が使われます。

Maigretが「見つかった」と「見つからない」を判定する方法

単純なスキャナーなら、次のようにHTTP GETしてステータスコードだけを見ます。

https://example.com/user/<username>

しかし実際のサイトでは、存在しないユーザーでも200 OKを返すことがあります。たとえば、次のようなケースです。

「そのユーザーはいません」というページを200で返す
ホームページへフォールバックする
CAPTCHAページを返す
キャッシュされた汎用ページを返す

そのため、Maigretはステータスコードだけでは判断しません。サイトシグネチャには、より具体的なルールが含まれます。

urlMain
url
presenseStrs
absenceStrs
ユーザー名抽出用の正規表現
カスタムヘッダー
カテゴリタグ
国タグ

判定イメージは次のようになります。

def is_found(response_text, presence_strs, absence_strs):
    has_required_signals = all(s in response_text for s in presence_strs)
    has_absence_signals = any(s in response_text for s in absence_strs)

    return has_required_signals and not has_absence_signals

「見つかった」と判断するには、存在を示す文字列が揃っており、不在を示す文字列が含まれていない必要があります。それ以外は「不明」として扱い、手動確認の余地を残します。

これはAPIテストでも重要です。200 OKだけでは不十分です。レスポンス本文、ヘッダー、エラー形式まで検証する必要があります。

Apidogでは、1つのリクエストに対してステータスコード、レスポンスボディ、ヘッダーなどのアサーションを設定できます。これは、MaigretのpresenseStrsとabsenceStrsをAPIテストに置き換えたものです。

再帰的検索と情報抽出

Maigretはアカウントを見つけると、公開プロフィールから追加情報を抽出します。

対象になり得る情報は次のようなものです。

別のユーザー名
実名
メールアドレス
電話番号
外部リンク
他サービスのプロフィールURL

抽出ルールもサイトごとに定義されます。GitHub、LinkedIn、Instagramではプロフィール構造が異なるため、同じ抽出ロジックでは不十分です。

さらにMaigretは、抽出した識別子を再度検索に使うことがあります。これにより、1つのユーザー名から関連アカウントをたどる再帰的な探索が可能になります。

APIテストでもこの考え方は使えます。たとえば、あるレスポンスに未文書化フィールドが含まれていた場合、それを無視せず、関連エンドポイントやダウンストリーム処理の検証に使います。

例：

{
  "id": "user_123",
  "name": "Alice",
  "billingProfileId": "bp_789"
}

billingProfileIdが仕様書にないなら、次を確認します。

このフィールドは意図されたものか
関連する請求APIに存在するか
公開してよい情報か
テストケースに追加すべきか

Maigretの再帰的検索は、APIテストにおける「レスポンスから次の検証対象を発見する」パターンとして応用できます。

CAPTCHAとレート制限の処理

Maigretは、CAPTCHAやレート制限を完全に突破するツールではありません。レスポンスの形状から検出し、必要に応じて処理を切り替えます。

主な戦略は次のとおりです。

User-Agentのローテーション
サイトごとのリトライヘッダーの尊重
モバイル版または簡易ドメインへのフォールバック
サイトが許可する場合のTorまたはI2P経由ルーティング

ただし、サイトが強力な自動化防止策を導入している場合、Maigretは「CAPTCHA検出」と記録し、手動確認を促します。敵対的に防御を突破するのではなく、公開アクセスとして許される範囲で動作します。

APIテストでも同じ姿勢が必要です。レート制限に遭遇したら、突破しようとするのではなく、検出してバックオフします。

例：

if (response.status === 429) {
  const retryAfter = response.headers.get("Retry-After");
  console.log(`Rate limited. Retry after: ${retryAfter} seconds`);
}

テストランナーがレート制限を無視してリクエストを投げ続けると、チームのIPがブロックされる可能性があります。Maigretのように、制限を信号として扱い、適切に停止または待機する設計が安全です。

シグネチャのドリフト問題

3,000以上のサイトに対応するデータベースは、更新され続けて初めて価値があります。サイトは次のように変化します。

プロフィールページのHTMLを変更する
URLパターンを変更する
CAPTCHAを追加する
買収やブランド変更でドメインが変わる
存在・不在メッセージの文言が変わる

古いシグネチャは、偽陰性または偽陽性を生みます。

Maigretはこれに対して複数のレイヤーで対応しています。

GitHubリポジトリからの自動更新
コミュニティによるプルリクエスト
手動更新用の--updateフラグ
既知の存在ユーザー名に対する検証ハーネス

重要なのは、既知の存在ユーザー名を使ってシグネチャがまだ機能しているかを確認する点です。これはAPIテストの回帰テストと同じです。

APIでは、既知の良好なレスポンスを保存し、定期的にライブエンドポイントへリプレイします。

保存済みフィクスチャ
        ↓
定期実行
        ↓
現在のレスポンスと比較
        ↓
差分があればドリフトとして通知

Apidogでも、エンドポイントごとに期待レスポンスやアサーションを定義し、継続的に検証できます。DeepSeek V4 APIガイドでは、特定ベンダーAPIを検証する際の考え方も扱っています。

オプションのAI要約モード

Maigretには--aiフラグがあります。これは、OpenAI互換のLLMエンドポイントを使って、生の検索結果を短い調査要約に変換する機能です。APIキーはユーザーが用意します。

重要なのは、LLMが判定を行わないことです。

ユーザー名が存在するかどうかは、ルールベースで判定する
LLMは、その結果を読みやすく要約する
判断ロジックと文章生成を分離する

これはAPI監視でも良い設計です。

決定論的なアサーション
        ↓
合否判定
        ↓
実行ログ
        ↓
LLMによる要約
        ↓
Slackやレポートに投稿

LLMをテストの判定者にするのではなく、後処理器として使う方が安定します。コンピューター利用 vs 構造化APIでも、構造化されたルールを先に置く重要性を説明しています。

正当なユースケース

Maigretの使用が明確に適切な場面は限られます。

自分のアカウント回復

過去に使っていたユーザー名から、古い公開アカウントを探します。プライバシー監査やデジタルフットプリント整理に役立ちます。
ブランド悪用監視

企業名、製品名、サービス名を使ったなりすましアカウントを検出します。
行方不明者捜索

家族の同意や関係機関との連携のもと、公開情報を確認します。単独行動は調査を妨げる可能性があります。
承認されたレッドチーム活動

契約範囲内で、組織の公開攻撃対象領域を把握します。
調査報道

編集上・法的な審査のもとで、詐欺、公人の不正行為、組織犯罪などを調査します。

一方で、次の用途は不適切です。

好奇心で見知らぬ人を調べる
元パートナーを追跡する
同意のない個人データセットを作る
ハラスメント目的で使う

ツールが公開情報だけを扱うとしても、使い方によっては法的・倫理的な境界を越えます。

APIテストに適用できるMaigretのパターン

MaigretからAPIテストに直接転用できるパターンは5つあります。

1. チェックをコードではなくシグネチャとして管理する

エンドポイントごとの期待値を、テストコードに埋め込むのではなくデータとして管理します。

{
  "name": "Get user profile",
  "method": "GET",
  "path": "/users/{id}",
  "expect": {
    "status": 200,
    "requiredJsonPaths": ["$.id", "$.name", "$.email"],
    "forbiddenJsonPaths": ["$.password"]
  }
}

これにより、新しいエンドポイントや外部ベンダーAPIを追加しやすくなります。

2. ステータスコードだけで判定しない

200 OKは成功の一部でしかありません。

最低限、次を組み合わせて確認します。

ステータスコード
レスポンスボディの必須フィールド
含まれてはいけないフィールド
エラー形式
Content-Type
認証・認可ヘッダー

3. シグネチャを継続的に更新する

API仕様は変化します。人間が気づく前にテストが検出できるよう、アサーションや仕様を同期・更新できる状態にします。

PostmanなしのAPIテストでも、このワークフローを扱っています。

4. ドリフト検出を定期実行する

既知の良好なフィクスチャを保存し、定期的に実行します。差分が出たら、APIの破壊的変更や仕様外変更として検知します。

5. LLMは判定ではなくレポート生成に使う

合否判定は決定論的なルールで行います。LLMは、実行結果を人間が読みやすい形に要約するために使います。

この分離により、テスト結果の信頼性を保ちながら、レポートの可読性を上げられます。

Maigret実行時の一般的な落とし穴

Maigretを試すエンジニアは、次の点に注意してください。

-aなしで完全スキャンだと思い込む デフォルトでは上位サイト中心のスキャンになります。ロングテールまで調べる場合は-aを使います。

  maigret username -a

タグを無視する --tagsでカテゴリや国を絞り込めます。対象地域に応じてタグを指定しないと、重要なサイトを見落とす可能性があります。

  maigret username --tags jp

更新をスキップする 古いシグネチャは誤判定の原因になります。本格的な調査前には更新します。

  maigret --update

Torブロックをユーザー情報として解釈する

一部サイトはTor出口ノードをブロックします。これは対象ユーザーの存在有無とは関係ありません。
抽出フィールドを証拠として扱う

Maigretはページに公開されている情報を抽出します。ページ自体が偽装されている可能性もあります。結果は証拠ではなく、調査の手がかりとして扱うべきです。

実際のユースケース

あるセキュリティコンサルティング会社では、レッドチーム活動のスコープ確認時にMaigretを使い、クライアントの公開攻撃対象領域を把握しています。出力はキックオフレポートに含められ、調査開始前の共通認識を作るために使われます。

フリーランスの詐欺調査官は、--aiフラグを使って3,000サイトのスキャン結果を短い概要にまとめ、非技術系クライアント向けのレポートにしています。検索と判定は決定論的に行い、LLMは読みやすさを補助します。

あるエンジニアリングチームは、Maigretと同じ設計思想を内部APIテストに応用しています。シグネチャデータベース、定期リプレイ、ドリフト検出を使い、200以上のマイクロサービスのAPI仕様変更を検出しています。実装にはApidogを使っていますが、考え方はMaigretと同じです。

結論

Maigretは、変化し続ける外部サイトに対して、壊れにくい検出ルールをどう管理するかを示す良い実例です。OSINTを実施しないエンジニアにとっても、その設計は学ぶ価値があります。

特に重要なのは次の5点です。

Maigretは、バージョン管理されたシグネチャデータベースで3,000以上のサイトを扱う
単純なステータスコードではなく、複数シグナルで判定する
長期運用ではドリフト検出が不可欠
LLMは判定ではなく後処理に使う
同じパターンはApidogでのAPIテストにも応用できる

次にやることはシンプルです。Maigretのサイトデータベース形式を読み、次に自分のAPIエンドポイントを同じ視点で整理してください。各エンドポイントに対して、ステータスコード、必須フィールド、不在であるべきフィールド、ヘッダー、既知の良好なレスポンスを定義します。

ベンダーが深夜にフィールド名を変更したとき、ユーザーより先にテストスイートが検知できれば、その設計は成功です。

よくある質問

Maigretは合法的に使用できますか？

管轄区域と対象によります。自分自身、自分が所有するアカウント、書面で許可を得た企業、または承認された調査報道の一部として使う場合は、一般的に問題になりにくいです。一方で、同意のない個人に対して使うと、ストーキングやハラスメント関連の法律に抵触する可能性があります。

MaigretはPythonなしで動作しますか？

公式パッケージはPython 3.10+向けです。作者は、手軽な検索用のTelegramボットや、ローカルインストールを避けたいユーザー向けのCloud Shell設定も提供しています。

3,000サイトという主張はどの程度正確ですか？

リポジトリ内のサイトデータベースには3,000以上のエントリがあります。ただし、すべてが常に有効とは限りません。自動更新とコミュニティのメンテナンスにより、動作するサブセットが更新され続けています。

AIモードは何をしますか？

--aiフラグは、OpenAI互換のLLMを使って決定論的な検索結果を読みやすい要約に変換します。検索や判定そのものを変更するものではありません。APIキーはユーザーが用意します。

MaigretをCIで使えますか？

OSINT調査そのものは対話的な作業であり、CI向きではありません。ただし、Maigretが使っている設計パターン、つまりシグネチャデータベース、ドリフト検出、定期リプレイは、APIテストのCIパイプラインに向いています。Apidogでも同様の考え方を実装できます。

Sherlockとは何が違いますか？

Sherlockはより古く、よりシンプルなユーザー名検索ツールです。Maigretは、情報抽出、再帰検索、CAPTCHA処理、AI要約モード、より豊富なサイトデータベースを追加しています。どちらもMITライセンスで、OSINTツール設計を学ぶ上で参考になります。

古いシグネチャはどこに報告すればよいですか？

MaigretリポジトリのGitHub issueまたはプルリクエストで報告できます。コミュニティによる更新が、サイトデータベースの鮮度を保つ重要な仕組みです。

Claude Code 無効なcustom3pエンタープライズ構成エラーの修正方法

Akira — Mon, 11 May 2026 03:28:51 +0000

Claude CodeをDeepSeek V4、OpenRouter、またはその他のサードパーティモデルプロバイダーに接続すると、Invalid custom3p enterprise configというエラーが出ることがあります。このエラーはドキュメント上で分かりにくく、Claude Codeが公式にサポートしているサードパーティプロバイダー設定でも発生します。

今すぐApidogを試す

この記事では、custom3pの意味、設定が失敗する主な原因、そしてOpenRouter、LiteLLM、ローカルvLLMなどで動かすための修正手順を実装ベースで整理します。

まとめ

Invalid custom3p enterprise configは、Claude Codeがサードパーティプロバイダー設定を検証できないときに出るエラーです。

custom3pは、ANTHROPIC_BASE_URLで指定されたAnthropic以外のAPIエンドポイントに対するClaude Code内部のラベルです。

よくある原因は次のとおりです。

ANTHROPIC_BASE_URLの末尾に余計な/v1がある
ANTHROPIC_API_KEYとANTHROPIC_AUTH_TOKENを取り違えている
~/.claude/settings.jsonが不正なJSONになっている
新規インストールでオンボーディングが完了していない
ゲートウェイが必要なヘッダーを転送していない
Team / Enterpriseの管理ポリシーと競合している

まずはベースURLから確認してください。多くのケースでは、/v1を削除するだけで解決します。

「custom3p」とは何か

Claude Codeはリクエストを以下のいずれかのモードでルーティングします。

モード	トリガー方法
Anthropic API（デフォルト）	オーバーライド設定なし
Amazon Bedrock	`CLAUDE_CODE_USE_BEDROCK=1`
Google Vertex AI	`CLAUDE_CODE_USE_VERTEX=1`
Microsoft Foundry	`CLAUDE_CODE_USE_FOUNDRY=1`
カスタムサードパーティ	`ANTHROPIC_BASE_URL`がAnthropic以外を指す場合

最後の「カスタムサードパーティ」がcustom3pです。

ANTHROPIC_BASE_URLがLiteLLM、OpenRouter、ローカルvLLM、企業内ゲートウェイなどを指している場合、Claude Codeはその設定をcustom3pとして扱い、最初のAPI呼び出し前に検証します。

この検証に失敗すると、次のエラーが出ます。

Invalid custom3p enterprise config

これは設定検証エラーであり、ポリシーブロックではありません。設定を直せば解決できます。

なぜ今このエラーが増えているのか

2026年4月、AnthropicはClaude CodeクライアントIDを偽装してClaude Pro / Maxのサブスクリプションアクセスを取得していたサードパーティagenticツールをブロックしました。OpenClawのようにClaude Codeセッションを独自バックエンド経由でルーティングしていたツールは影響を受けました。

ただし、この記事で扱う問題はそれとは別です。

その後、開発者はClaude Codeの公式サードパーティプロバイダーサポートを使い、OpenRouterやLiteLLMなどのバックエンドにルーティングし始めました。Redditでは、Claude CodeのエージェントループをOpenRouter経由でDeepSeek V4 Proに切り替える例も共有されています。出力100万トークンあたり$0.87とAnthropicの$15を比較すると、約17倍のコスト差があります。

問題は、Claude Codeの公式サードパーティプロバイダーサポートには正しいエンタープライズ設定が必要なことです。1つでも項目を間違えると、Invalid custom3p enterprise configが発生します。

根本原因1：`ANTHROPIC_BASE_URL`の末尾に`/v1`がある

最も多い原因です。

Claude Codeは、設定したベースURLに自動で/v1/messagesを追加します。そのため、ベースURLにすでに/v1が含まれていると、最終的なパスが次のようになります。

/v1/v1/messages

この場合、ゲートウェイは多くの場合404を返します。

誤った例

export ANTHROPIC_BASE_URL="https://api.openrouter.ai/api/v1"

export ANTHROPIC_BASE_URL="https://litellm.yourcompany.com/v1"

正しい例

export ANTHROPIC_BASE_URL="https://api.openrouter.ai/api"

export ANTHROPIC_BASE_URL="https://litellm.yourcompany.com"

実際の到達URLを確認する

Claude Codeが呼び出すURLと同じ形式でテストします。

curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  "${ANTHROPIC_BASE_URL}/v1/messages" \
  -d '{"model":"claude-sonnet-4-6","max_tokens":1,"messages":[{"role":"user","content":"hi"}]}'

判定の目安は次のとおりです。

200：エンドポイントに到達できている
400：リクエスト内容は不正だが、エンドポイント自体は存在する
404：URL構造が間違っている可能性が高い

404なら、まずANTHROPIC_BASE_URLから/v1を削除してください。

根本原因2：認証情報の環境変数が違う

Claude Codeは認証方式に応じて2種類の環境変数を使います。

変数	送信形式	主な用途
`ANTHROPIC_API_KEY`	`x-api-key`ヘッダー	APIキー認証を想定するAnthropic互換ゲートウェイ
`ANTHROPIC_AUTH_TOKEN`	`Authorization: Bearer`ヘッダー	OAuth形式のゲートウェイ、LiteLLM、多くのOpenRouter設定

OpenRouterはBearerトークンを想定します。

export ANTHROPIC_AUTH_TOKEN="sk-or-your-openrouter-key"
export ANTHROPIC_BASE_URL="https://openrouter.ai/api"

OpenRouterでANTHROPIC_API_KEYを使うと、x-api-keyヘッダーが送信されます。OpenRouter側がそのヘッダーを認証に使わない場合、認証に失敗し、Claude Codeは無効なエンタープライズ設定として扱います。

LiteLLMの場合は次のようにします。

export ANTHROPIC_AUTH_TOKEN="sk-litellm-your-virtual-key"
export ANTHROPIC_BASE_URL="https://your-litellm-server:4000"

DeepSeekゲートウェイやAPIキーで動かすローカルvLLMサーバーでは、次のようにANTHROPIC_API_KEYを使う構成もあります。

export ANTHROPIC_API_KEY="your-key-here"
export ANTHROPIC_BASE_URL="https://your-vllm-server"

使用しているゲートウェイがどのヘッダーを期待しているかを必ず確認してください。

根本原因3：`settings.json`が不正なJSONになっている

環境変数ではなく~/.claude/settings.jsonで設定している場合、JSONの構文エラーでも検証に失敗します。

よくあるミス：末尾カンマ

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-your-key",
  }
}

JSONでは最後の要素にカンマを付けられません。

よくあるミス：スマートクォート

ドキュメントやWordからコピーした文字列に、通常の"ではない引用符が混ざることがあります。

{
  "env": {
    “ANTHROPIC_BASE_URL”: “https://openrouter.ai/api”
  }
}

正しい形式

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-your-openrouter-key"
  }
}

起動前にJSONを検証する

Pythonで確認します。

python3 -c "import json, os; json.load(open(os.path.expanduser('~/.claude/settings.json')))" && echo "Valid JSON"

jqでも確認できます。

jq . ~/.claude/settings.json

ここでパースエラーが出る場合、Claude Codeは設定を読み込めません。

根本原因4：新規インストールでオンボーディングが完了していない

Claude Codeは、settings.jsonからエンタープライズ設定を読み込む前に、~/.claude.jsonのhasCompletedOnboarding: trueを確認します。

新規インストールでこのフラグがない場合、Claude Codeはオンボーディングモードとして扱い、settings.jsonの設定を読み込まないことがあります。

現在の状態を確認します。

cat ~/.claude.json | python3 -m json.tool 2>/dev/null | grep hasCompletedOnboarding

キーが存在しない、またはfalseの場合は、次のように設定します。

{
  "hasCompletedOnboarding": true,
  "primaryApiKey": "sk-placeholder"
}

primaryApiKeyはプレースホルダーです。実際の認証はsettings.jsonまたは環境変数で上書きされます。フォーマットチェックを通すため、sk-で始まる任意の値を設定します。

保存後、Claude Codeを再起動してください。

根本原因5：ゲートウェイが必要なヘッダーを転送していない

Claude Codeの検証では、機能ハンドシェイクのために複数のヘッダーを送信します。ゲートウェイやプロキシがそれらを削除すると、Claude Codeが期待するレスポンスと一致せず、Invalid custom3p enterprise configになります。

転送すべき主なヘッダーは次のとおりです。

anthropic-beta
anthropic-version
X-Claude-Code-Session-Id

LiteLLMではv1.82.9以降、通常はデフォルトで動作します。

nginxなどのカスタムプロキシを使っている場合は、明示的に転送してください。

location /v1/ {
  proxy_pass http://backend;
  proxy_set_header anthropic-beta $http_anthropic_beta;
  proxy_set_header anthropic-version $http_anthropic_version;
  proxy_set_header X-Claude-Code-Session-Id $http_x_claude_code_session_id;
}

ゲートウェイ側でベータヘッダーを転送できない場合は、Claude Code起動前に次を設定します。

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1

これにより、Claude Codeはベータヘッダーを必要とする機能をスキップします。一部の実験的機能は使えなくなりますが、コアのエージェントループは動作します。

根本原因6：エンタープライズポリシーと競合している

TeamまたはEnterpriseプランで管理者が管理設定を配布している場合、その設定はローカルの~/.claude/settings.jsonや環境変数より優先されます。

たとえば、次のような管理ポリシーがあると、ローカル設定が正しくてもエラーになります。

使用可能モデルが制限されている
カスタムベースURLがブロックされている
特定のゲートウェイドメインが許可されていない

管理設定の有無を確認します。

ls ~/.claude/managed-settings.json 2>/dev/null && echo "管理設定が見つかりました"

Claude Code内でも確認できます。

/status

「管理設定」が有効な場合、管理者に次のいずれかを依頼します。

ゲートウェイドメインを許可されたベースURLに追加する
ゲートウェイのモデルIDを含むavailableModelsを設定する
カスタムベースURL制限から対象ユーザーを除外する

自分で管理するエンタープライズデプロイメントでは、管理設定はmacOSなら次のようなパスに配置されます。

/Library/Application Support/ClaudeCode/managed-settings.json

Windows / Linuxでは同等の管理設定パスを確認してください。

完全な動作構成例

Claude Code + OpenRouter（DeepSeek V4 Pro）

OpenRouterはAnthropic互換APIを公開しています。DeepSeek V4 ProでClaude Codeのエージェントループを動かす場合は、~/.claude/settings.jsonを次のように設定します。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-your-openrouter-key",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek/deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek/deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek/deepseek-v4-pro"
  }
}

ベースURLを変更しても、Claude Codeはデフォルトではclaude-sonnet-4-6を要求します。そのため、OpenRouterでDeepSeekに固定したい場合はモデル名のオーバーライドが必要です。

OpenRouterはツール呼び出しに関するAnthropicのストリーミング仕様を完全には実装していません。一部のケースでは、関数呼び出しの引数が空で届く可能性があります。主要なエージェントループは動作しますが、複雑なマルチツールチェーンでは注意してください。

互換性の更新は、OpenRouterのClaude Code統合ドキュメントを確認してください。

Claude Code + LiteLLM（任意のプロバイダー）

LiteLLMはClaude Code向けの互換性が高いゲートウェイです。ヘッダー転送を処理し、OpenAI、Anthropic、Vertex、Bedrock、Hugging Faceモデルへのルーティングをサポートします。

LiteLLMのconfig.yaml例です。

model_list:
  - model_name: claude-sonnet-4-6
    litellm_params:
      model: deepseek/deepseek-v4
      api_key: "sk-your-deepseek-key"
  - model_name: claude-opus-4-7
    litellm_params:
      model: deepseek/deepseek-v4-pro
      api_key: "sk-your-deepseek-key"

Claude Code側の~/.claude/settings.jsonは次のようにします。

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:4000",
    "ANTHROPIC_AUTH_TOKEN": "sk-litellm-your-key"
  }
}

この構成では、Claude Codeはclaude-sonnet-4-6を送信します。LiteLLMがそのモデル名を受け取り、DeepSeek V4へルーティングします。そのため、Claude Code側でモデル名をオーバーライドする必要はありません。

Claude Code + ローカルvLLM

ローカル推論では、vLLMをAnthropic互換モードで起動します。

python -m vllm.entrypoints.openai.api_server \
  --model deepseek-ai/DeepSeek-V3 \
  --dtype auto \
  --api-key local-key \
  --port 8000

Claude Code側を設定します。

export ANTHROPIC_BASE_URL="http://localhost:8000"
export ANTHROPIC_API_KEY="local-key"
export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-ai/DeepSeek-V3"

エラーをデバッグする

上記を修正しても解決しない場合は、デバッグログを有効にします。

claude --debug 2>&1 | head -100

確認するポイントは次のとおりです。

Sending request to:：実際に呼び出しているURL
Response status:：ゲートウェイからのHTTPステータス
enterprise config error:：内部検証メッセージ

ゲートウェイ側を確認する場合は、Claude Codeに近いリクエストをcurlで送ります。

curl -v -X POST "${ANTHROPIC_BASE_URL}/v1/messages" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${ANTHROPIC_AUTH_TOKEN}" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: max-tokens-3-5-sonnet-2024-07-15" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 10,
    "messages": [{"role": "user", "content": "hi"}]
  }'

有効なゲートウェイなら、メッセージ構造を含む200が返ります。

401、403、422が返る場合は、Claude Codeではなくゲートウェイ側の認証またはリクエスト形式の問題です。

ApidogでAPIをテストする

サードパーティプロバイダー統合をデバッグする場合、Apidogを使うと、LLMゲートウェイを通過するリクエストとレスポンスを確認しやすくなります。

/v1/messagesエンドポイント用のコレクションを作成し、動作するリクエストテンプレートを保存しておくと、Claude Codeを毎回起動し直さずにプロバイダー間の挙動を比較できます。

Apidogで次のように設定します。

ゲートウェイURLを指す新しいコレクションを作成する
anthropic-versionをコレクションレベル変数にする
anthropic-betaをコレクションレベル変数にする
Authorizationをコレクションレベル変数にする
/v1/messagesへのPOSTリクエストを保存する
ゲートウェイを切り替えるときは変数だけ変更する

これは、Invalid custom3p enterprise configを引き起こすヘッダー転送問題の切り分けに役立ちます。Claude Code側の設定を疑う前に、ゲートウェイがどのヘッダーを受け取り、どのヘッダーをバックエンドへ転送しているかを確認できます。

知っておくべきClaude Code関連設定

ベータヘッダー依存を無効にする

一部のエンタープライズゲートウェイはカスタムヘッダーを転送できません。その場合は次を設定します。

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1

これにより、エンタープライズ設定の検証からベータ機能ハンドシェイクが外れます。エージェントループは引き続き動作しますが、ベータヘッダーに依存する機能は使えなくなります。

ゲートウェイ検出機能付きモデルピッカー

Claude Code v2.1.129以降では、ゲートウェイのモデルリストから/modelピッカーを自動設定できます。

export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1

Claude Codeは起動時にゲートウェイの/v1/modelsエンドポイントをクエリし、検出したモデルをピッカーに追加します。

ただし、追加されるのはclaudeまたはanthropicで始まるIDを持つモデルのみです。DeepSeekのようなモデルを使う場合は、ANTHROPIC_DEFAULT_SONNET_MODELで手動固定してください。

カスタムモデルピッカーエントリ

単一のカスタムモデルを/modelピッカーに追加するには、次を設定します。

export ANTHROPIC_CUSTOM_MODEL_OPTION="deepseek/deepseek-v4-pro"
export ANTHROPIC_CUSTOM_MODEL_OPTION_NAME="DeepSeek V4 Pro"
export ANTHROPIC_CUSTOM_MODEL_OPTION_DESCRIPTION="Claude Opusより17倍安価"

これは/modelピッカーの下部に表示されます。セッション中にゲートウェイモデルとデフォルトのClaudeモデルを切り替えやすくなります。

よくある質問

Claude Codeでサードパーティプロバイダーを使うことはAnthropicの規約違反ですか？

いいえ。

Anthropicは、Bedrock、Vertex AI、Foundry、およびカスタムゲートウェイ経由のルーティングに関するANTHROPIC_BASE_URLパターンを文書化し、公式にサポートしています。

2026年4月にブロックされたのは、Claude CodeクライアントIDを偽装してAnthropic自身のAPIにサブスクリプション料金でアクセスしようとしたサードパーティツールです。

自分のAPIキーでOpenRouterや独自ゲートウェイを使う構成とは別の問題です。

Claude CodeのエージェントループはDeepSeek V4 Proで動作しますか？

コアのループは動作します。

たとえば次の操作です。

ファイル編集
シェルコマンド実行
複数ステップのタスク実行

一方、サードパーティプロバイダー経由では次の機能が動作しない場合があります。

MCPサーバーツール
画像 / ビジョン入力

これらが必要な場合は、Anthropic APIまたはBedrock / Vertexを使う必要があります。

エンタープライズプランではないのに、なぜ「エンタープライズ設定」と表示されるのですか？

Claude Codeは、サブスクリプションの種類に関係なく、サードパーティプロバイダー設定を「エンタープライズ設定」と呼びます。

これはコード上のラベルであり、プラン制限ではありません。無料またはProの個人開発者でも、カスタムサードパーティプロバイダーを設定できます。

セッション中にAnthropicとサードパーティプロバイダーを切り替えられますか？

同じセッション内ではできません。

ベースURLは起動時に読み込まれます。切り替えるには、Claude Codeを終了し、環境変数または設定ファイルを変更してから新しいセッションを開始してください。

DeepClaudeは、--backend dsや--backend anthropicのようなCLIフラグでこの切り替えをラップしています。

ゲートウェイが企業ファイアウォールの背後にあります。プロキシ設定は使えますか？

はい。起動前にHTTPS_PROXYを設定します。

export HTTPS_PROXY="http://your-proxy:8080"
export ANTHROPIC_BASE_URL="https://your-internal-gateway"

企業プロキシによるTLSインターセプトがある場合は、CA証明書も指定します。

export NODE_EXTRA_CA_CERTS="/path/to/corporate-ca-bundle.pem"

curlテストは通るのにClaude Codeではエラーになります。何が違いますか？

Claude Codeは、単純なcurlでは再現されないプリフライト検証リクエストを行います。

--debug付きでClaude Codeを起動し、実際のプリフライトリクエストを確認してください。

よくある差分は次のとおりです。

anthropic-betaヘッダー
X-Claude-Code-Session-Idヘッダー
検証リクエストのJSONボディ形式
モデル名の違い
認証ヘッダー形式の違い

結論

Invalid custom3p enterprise configは、設定検証エラーです。ポリシーブロックではありません。

確認順は次のとおりです。

ANTHROPIC_BASE_URLから余計な/v1を削除する
ANTHROPIC_AUTH_TOKENとANTHROPIC_API_KEYの使い分けを確認する
~/.claude/settings.jsonをJSONとして検証する
新規インストールではhasCompletedOnboardingを確認する
ゲートウェイが必要なヘッダーを転送しているか確認する
管理ポリシーと競合していないか確認する

設定が正しく検証されると、Claude Codeのエージェントループは選択したバックエンド経由で実行できます。OpenRouterまたはLiteLLM経由のDeepSeek V4 Proは、多くのClaude Codeユースケースを低コストでカバーできます。

主な制限はMCPツールとビジョン入力です。これらが必要な場合は、Anthropic API、Bedrock、またはVertexを使用してください。

Gemini API 無制限無料利用

Akira — Sat, 09 May 2026 06:59:55 +0000

GoogleのGeminiファミリーは、大量ワークロード向けの費用対効果が高いフロンティアモデルラインです。ただし、無料の公開アプリ、サイドプロジェクト、ハッカソン用途でも、エンドポイントを数千人が使い始めるとAPI料金はすぐに増えます。Puter.jsを使うと、Google APIキーなしでGemini 2.5 Pro、Gemini 2.5 Flash、Gemini 2.0 Flash、Gemini 3 Flash Preview、Gemma 2/3/4ファミリーをブラウザから呼び出せます。課金は開発者ではなくエンドユーザーのPuterアカウント側で処理されるため、開発者側は無料で使えます。

今すぐApidogを試す

要するに

Puter.jsを使うと、Google APIキー、Google Cloudプロジェクト、バックエンドサーバーなしでGemini/Gemmaモデルを呼び出せます。
サポートされるGeminiには、2.5 Pro、2.5 Flash、2.5 Flash Lite、2.0 Flash、2.0 Flash Lite、3 Flash Previewなどがあります。
サポートされるGemmaには、複数サイズのGemma 2、3、4があります。
実装は<script>タグ1つとputer.ai.chat()だけです。
ストリーミング、画像入力、温度調整、マルチターン会話をブラウザで扱えます。
エンドユーザーがPuterアカウント経由で使用料を負担するため、開発者側のAPIキー管理や請求リスクを避けられます。
公式Gemini APIとPuterの比較・移行検証には、Apidogを使うと整理しやすくなります。

「無料無制限」の仕組み

Puter.jsはLLMの課金モデルを反転させます。

通常は開発者がGoogle AI Studioキーを持ち、すべてのトークンコストを負担します。一方、PuterではエンドユーザーがPuterにサインインし、そのユーザーの残高から利用分が処理されます。新規Puterアカウントにはスタータークレジットが付与され、必要に応じてユーザーがチャージできます。

開発者側の実装上のメリットは次の通りです。

Google Cloudプロジェクトが不要
Google AI Studioキーが不要
APIキーの漏洩対策やローテーションが不要
開発者側の利用上限管理が不要
ユーザー数に応じて利用枠が分散される
Googleへの直接課金を持たずにGeminiを組み込める

ただし、Puterはブラウザファーストです。ログイン済みユーザーセッションを前提にするため、cron、バッチ、Webhookなどのバックエンド処理には向きません。

ステップ1: Puter.jsをインストールする

静的HTMLならCDNを1行追加します。

<script src="https://js.puter.com/v2/"></script>

これでブラウザからputerオブジェクトを使えます。

バンドルされたアプリで使う場合はnpmからインストールします。

npm install @heyputer/puter.js

import { puter } from '@heyputer/puter.js';

ステップ2: モデルを選ぶ

用途ごとにモデルを切り替えます。

モデルID	使用する場面
`google/gemini-2.5-pro`	深い推論、複雑な分析、長文コンテキストタスク
`google/gemini-2.5-flash`	日常的なデフォルト。速度、品質、コストのバランスが良い
`google/gemini-2.5-flash-lite`	大量分類、タグ付け、軽量Q&A
`google/gemini-2.0-flash`	安定したベースラインとして使いたい場合
`google/gemini-3-flash-preview`	最新プレビューを試したい場合
`google/gemma-3-27b-it`	オープンGemmaの命令チューニング済みモデルを使いたい場合
`google/gemma-4-31b-it`	より大きなGemmaモデルを試したい場合

多くのアプリでは、まずgoogle/gemini-2.5-flashをデフォルトにします。

推奨の切り替え方は次の通りです。

const MODEL = {
  default: 'google/gemini-2.5-flash',
  reasoning: 'google/gemini-2.5-pro',
  cheap: 'google/gemini-2.5-flash-lite',
};

通常のチャット: google/gemini-2.5-flash
難しい推論: google/gemini-2.5-pro
大量の分類・タグ付け: google/gemini-2.5-flash-lite

ステップ3: Geminiと会話する

最小構成は次の通りです。

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>
  <script>
    puter.ai.chat(
      "Explain machine learning in three sentences",
      { model: 'google/gemini-2.5-flash' }
    ).then(response => {
      puter.print(response);
    });
  </script>
</body>
</html>

このHTMLをブラウザで開くと、PuterがGemini呼び出しを処理します。ユーザーがPuterにサインインしていない場合は、初回実行時にサインインまたはアカウント作成の流れになります。

APIキー、環境変数、バックエンドサーバーは不要です。

ステップ4: UIに組み込む

実際のアプリでは、入力欄と出力領域を用意して呼び出します。

<!DOCTYPE html>
<html>
<body>
  <textarea id="prompt" rows="5" cols="60">
日本語で、REST APIとGraphQLの違いを説明してください。
  </textarea>
  <br />
  <button id="send">送信</button>
  <pre id="output"></pre>

  <script src="https://js.puter.com/v2/"></script>
  <script>
    const promptEl = document.getElementById('prompt');
    const outputEl = document.getElementById('output');
    const sendBtn = document.getElementById('send');

    sendBtn.addEventListener('click', async () => {
      outputEl.textContent = '生成中...';

      try {
        const response = await puter.ai.chat(promptEl.value, {
          model: 'google/gemini-2.5-flash',
        });

        outputEl.textContent = response;
      } catch (error) {
        outputEl.textContent = `Error: ${error.message}`;
      }
    });
  </script>
</body>
</html>

最初はこの形で動作確認し、その後にReact、Vue、Svelteなどへ移植すると実装しやすくなります。

ステップ5: 応答をストリーミングする

チャットUIや長文回答では、ストリーミングを有効にします。

const response = await puter.ai.chat(
  "Explain photosynthesis in detail",
  {
    model: 'google/gemini-2.5-flash',
    stream: true,
  }
);

for await (const part of response) {
  if (part?.text) {
    outputDiv.innerHTML += part.text;
  }
}

part.textには応答の断片が入ります。UIに順次追加すれば、ユーザーは回答がリアルタイムに生成される様子を見られます。

HTMLに組み込むと次のようになります。

<div id="output"></div>

<script>
  async function streamAnswer() {
    const outputDiv = document.getElementById('output');
    outputDiv.innerHTML = '';

    const response = await puter.ai.chat(
      "Geminiをブラウザアプリに組み込む手順を説明してください。",
      {
        model: 'google/gemini-2.5-flash',
        stream: true,
      }
    );

    for await (const part of response) {
      if (part?.text) {
        outputDiv.innerHTML += part.text;
      }
    }
  }

  streamAnswer();
</script>

ステップ6: 画像入力を使う

Geminiの強みの1つはマルチモーダル入力です。画像URLを渡すと、画像の内容を説明させたり、画像に関する質問をしたりできます。

puter.ai.chat(
  "What do you see in this image? Describe colors, objects, and mood.",
  "https://assets.puter.site/doge.jpeg",
  { model: 'google/gemini-2.5-flash' }
).then(response => {
  puter.print(response);
});

主なユースケースは次の通りです。

代替テキスト生成
ビジュアルQA
スクリーンショット分析
OCR補助
アクセシビリティツール
商品画像のタグ付け
図やチャートの説明

自然画像や図の理解ではGeminiは強力です。ただし、テキストが非常に密集したスクリーンショットでは、GPT-5.xの方が有利な場合があります。

ステップ7: 温度を調整する

temperatureを指定すると、出力のランダム性を調整できます。

const response = await puter.ai.chat(
  'Write a creative short story about a robot chef',
  {
    model: 'google/gemini-2.5-flash',
    temperature: 0.2,
  }
);

目安は次の通りです。

用途	temperature
事実ベースの回答	`0.0`〜`0.3`
JSONや分類など構造化出力	`0.0`〜`0.2`
通常のチャット	`0.5`〜`0.7`
クリエイティブライティング	`0.7`〜`1.0`

Gemini Flashでは、一般的なチャット用途なら0.7前後から試すとよいです。

ステップ8: マルチターン会話を実装する

会話履歴はメッセージ配列として渡します。

const messages = [
  { role: 'user', content: 'I am building a Next.js app with Postgres.' },
  { role: 'assistant', content: 'Got it. What do you need help with?' },
  { role: 'user', content: 'How should I structure migrations?' },
];

const response = await puter.ai.chat(messages, {
  model: 'google/gemini-2.5-pro',
});

console.log(response);

実装では、ユーザー発話とアシスタント応答を配列に追加していきます。

const messages = [];

async function sendMessage(userInput) {
  messages.push({
    role: 'user',
    content: userInput,
  });

  const response = await puter.ai.chat(messages, {
    model: 'google/gemini-2.5-flash',
  });

  messages.push({
    role: 'assistant',
    content: response,
  });

  return response;
}

Geminiは渡された履歴全体を読み取り、会話の文脈を維持します。

同じプロンプトでGeminiを他のモデルと比較する

Puterは主要なLLMを単一のインターフェースで扱えます。ユースケースに合うモデルを見つけるには、同じプロンプトを複数モデルに投げて比較します。

const models = [
  'google/gemini-2.5-flash',
  'claude-sonnet-4-6',
  'gpt-5.5',
  'x-ai/grok-4.3',
];

const prompt = "Refactor this React component to use hooks: ...";

for (const model of models) {
  const start = performance.now();

  const response = await puter.ai.chat(prompt, { model });

  const elapsed = performance.now() - start;

  console.log(`${model}: ${elapsed.toFixed(0)}ms`);
  console.log(response);
  console.log('---');
}

比較時は、少なくとも次の項目を記録します。

レイテンシー
回答品質
コードの正確性
指示追従性
日本語品質
長文での安定性
ユーザーにとって許容できる応答時間

傾向として、Gemini Flashはレイテンシー面で使いやすく、Sonnetはコーディング品質、GPT-5.5は長文生成、Grok 4.3はコスト面で比較対象になります。最終的には、実際のプロンプトでベンチマークしてください。

得られるものと得られないもの

Puter経由で得られるもの:

Gemini 2.5/2.0/3 Flash系モデル
Gemini 2.5 Pro
Open Gemmaファミリー
マルチターン会話
ストリーミング応答
画像URL入力
温度、最大トークン数、システムプロンプト
ブラウザベースの本番アプリで使える実行パス

Puterのバージョンや公開状況によっては得られない可能性があるもの:

Geminiでのネイティブ関数呼び出し
コード実行ツール
Google検索による根拠付け
Geminiの最大200万トークンの長文コンテキスト
ブラウザセッションなしのサーバーサイド実行
Google側レート制限の直接的な可視化

コード実行、検索グラウンディング、長大コンテキストが必要なエージェント型ワークフローでは、公式Google AI Studio APIの方が適しています。

一般的なチャット、Q&A、コンテンツ生成、画像理解、プロトタイプでは、Puterで十分に始められます。

Puterと公式Gemini APIの使い分け

Puterを使うべきケース

無料の公開アプリを出したい
APIキー漏洩や高額請求のリスクを避けたい
Google Cloudプロジェクトを作りたくない
静的サイトでGeminiを使いたい
ハッカソンやプロトタイプを高速に作りたい
ブラウザ拡張機能にLLMを組み込みたい
ユーザーがPuterへのサインインを許容できる

公式Gemini APIを使うべきケース

cron、バッチ、Webhookなどサーバーサイド呼び出しが必要
コード実行が必要
Google検索による根拠付けが必要
最大200万トークンのフルコンテキストが必要
Googleとの直接契約やコンプライアンス要件がある
独自データセットでファインチューニングしたい
ユーザーにPuterサインインを要求できない

Gemini 3 Flashの単独ウォークスルーは、Gemini 3 Flash Preview APIの利用方法を参照してください。

Apidogで統合テストを整理する

Puterの呼び出しはブラウザ内で実行されるため、通常のバックエンド用APIテストランナーからそのままスクリプト化するのは難しいです。

実装時は次の流れにすると整理しやすくなります。

Puterスクリプトを含む小さな静的ページを作る
プロンプトやモデル名をクエリパラメータで渡せるようにする
公式APIへ移行する可能性がある場合は、ApidogでGoogle Gemini APIのリクエストを別環境として管理する
puter-prototypeとgemini-prodを分けて、同じ仕様を比較できるようにする

例:

puter-prototype: Puterページをホストするlocalhost URL
gemini-prod: https://generativelanguage.googleapis.com/v1

Apidogをダウンロードし、Puterプロトタイプと公式Gemini APIを別環境として管理しておくと、移行時に比較しやすくなります。

より広範なAPIテストパターンは、QAエンジニア向けAPIテストツールも参考になります。

Puter経由で使える他のLLMパス

同じユーザー課金モデルは、他の主要LLMにも適用されます。

無料無制限のClaude APIを入手（Anthropic Opus、Sonnet、Haiku）
無料無制限のGPT-5.5 APIを入手（OpenAIの全カタログ）
Grok 4.3を無料で使う方法（xAI）
無料無制限のDeepSeek APIを入手

Puterでは、model文字列を切り替えるだけでプロバイダーも切り替えられます。

await puter.ai.chat("Summarize this text", {
  model: 'google/gemini-2.5-flash',
});

await puter.ai.chat("Summarize this text", {
  model: 'gpt-5.5',
});

FAQ

これは本当に無制限ですか？

開発者側から見ると無制限です。エンドユーザーはPuterアカウントの残高に応じて利用します。新規アカウントにはスタータークレジットが付与され、必要に応じてユーザーがチャージできます。

GoogleアカウントやGoogle Cloudプロジェクトは必要ですか？

不要です。PuterがGoogleとの接続を処理します。開発者がGoogle APIキーを扱う必要はありません。

本番環境で使えますか？

ブラウザベースのアプリであれば使えます。重要なのは、ユーザーがPuterへのサインインを許容できるかどうかです。

Puter経由のGeminiは公式APIと同じですか？

Puterはユーザーの代わりにGoogleのAPIを呼び出します。モデルの基本的な動作は変わりません。ただし、Puterを経由する分、レイテンシーがわずかに増える可能性があります。

Geminiの200万トークンコンテキストは使えますか？

Puterは現在、すべてのモデルバリアントで200万トークン上限を完全に公開しているわけではありません。非常に長いコンテキストが必要な場合は、公式Google AI Studio APIを選ぶべきです。多くのユースケースは20万トークンを大きく下回るため、その範囲ではPuterで対応できます。

Discordボットやバックエンドサービスで使えますか？

Puterはブラウザファーストで、ユーザーセッションを前提とします。Discordボット、cron、バックエンドサービスでは、公式Gemini APIを直接使う方が適しています。

どのモデルをデフォルトにすべきですか？

まずはgoogle/gemini-2.5-flashです。速度、品質、コストのバランスが良く、多くのプロンプトに対応できます。

通常用途: google/gemini-2.5-flash
難しい推論: google/gemini-2.5-pro
大量分類: google/gemini-2.5-flash-lite

画像生成はサポートされていますか？

Puterは現在、OpenAIのgpt-image-2およびDALL-Eバリアントを介した画像生成を公開しており、Imagenではありません。画像生成パスについては、無料無制限のGPT-5.5 APIを入手を参照してください。

まとめ

Puter.jsを使うと、Google CloudのセットアップなしでGeminiをブラウザアプリに組み込めます。最小実装は、CDNスクリプトを読み込み、puter.ai.chat()を呼び出すだけです。

まずは次の構成から始めるのが実用的です。

const response = await puter.ai.chat("あなたのプロンプト", {
  model: 'google/gemini-2.5-flash',
});

無料公開アプリ、静的サイト、ハッカソン、プロトタイプでは、PuterはAPIキーなしでGeminiを試すためのシンプルな選択肢です。

一方で、サーバーサイド実行、ファインチューニング、コード実行、検索グラウンディング、最大200万トークンの長文コンテキストが必要な場合は、公式Google AI Studio APIを使うべきです。

Apidogで公式APIリクエストを整理しつつ、Puterプロトタイプと比較すれば、実装段階でどちらを採用すべきか判断しやすくなります。

無料GPT-5.5 API使い放題 & 全OpenAIモデル利用

Akira — Sat, 09 May 2026 02:35:27 +0000

OpenAIのGPT-5.5は有料APIとして提供され、入力100万トークンあたり5ドル、出力100万トークンあたり30ドルがかかります。サイドプロジェクト、ハッカソン、無料公開アプリでは、このコストが実装前の障壁になります。Puter.jsを使うと、OpenAIキーなしでGPT-5.5、GPT-5.5 Pro、GPT-5.x系、GPT-Image-2、DALL-E、OpenAI TTSをブラウザから呼び出せます。課金は開発者ではなく、Puterにサインインしたエンドユーザー側で処理されます。

今すぐApidogを試す

TL;DR

Puter.jsを使うと、APIキー、OpenAIアカウント、サーバーなしでOpenAIモデルをブラウザから呼び出せます。
対応テキストモデルには、gpt-5.5、gpt-5.5-pro、gpt-5.4、gpt-5、gpt-5-mini、o1、o3、gpt-4.1、gpt-4o、チャット/Codex系バリアントが含まれます。
画像生成: gpt-image-2、gpt-image-1.5、dall-e-3。
TTS: gpt-4o-mini-tts、tts-1、tts-1-hd。
最小構成は<script>タグ1つとputer.ai.chat()だけです。
ストリーミング、関数呼び出し、画像入力、画像生成、TTSをブラウザで実装できます。
エンドユーザーはPuterアカウントから自身の使用量を支払います。
移行判断には、ApidogでPuter版と公式OpenAI API版のプロンプトを比較してください。

「無料無制限」の仕組み

Puter.jsは、LLM利用時の課金主体を開発者からエンドユーザーに移します。開発者がOpenAI APIキーを保持して全トークン費用を負担する代わりに、ユーザーがPuterにサインインし、そのユーザーのPuter残高から呼び出しが課金されます。

開発者側のメリットは次の3つです。

OpenAIアカウントやAPIキーを管理しなくてよい

リポジトリへのキー混入、キー漏洩、ローテーション対応を避けられます。
開発者単位の利用上限を気にしにくい

各ユーザーが自身のPuterアカウントで実行します。
請求リスクを抑えられる

公開アプリで予期せぬOpenAI請求が発生する構成を避けられます。

ただし、Puter.jsはブラウザファーストです。ログイン済みユーザーセッションを前提とするため、Node.jsのバックエンドスクリプトやcronジョブで使う用途には向きません。サーバーサイド実行が必要な場合は、公式OpenAI APIを使うのが適切です。

ステップ1: インストール

CDN版なら、HTMLに1行追加するだけです。

<script src="https://js.puter.com/v2/"></script>

バンドル済みアプリではNPM版を使えます。

npm install @heyputer/puter.js

import { puter } from '@heyputer/puter.js';

CDN版は、静的HTML、ハッカソン用プロトタイプ、静的サイト、ブラウザ拡張機能に向いています。NPM版は、ビルド環境やTypeScriptを使うアプリで扱いやすい選択肢です。

ステップ2: モデルを選択する

PuterはGPT-5.x系と既存OpenAIモデルを公開しています。用途ごとの選択例は次の通りです。

モデルID	使用場面
`gpt-5.5-pro`	高度な推論、コーディングエージェント、複雑な分析
`gpt-5.5`	日常的なチャット、品質とコストのバランス
`gpt-5.4-nano`	高速・低コストな分類や大量テキスト処理
`gpt-5.4-mini`	チャットUI向けのミドルティア
`gpt-5.3-codex`	コード生成・コード解析
`o3`	複雑な推論チェーン
`o1-pro`	エージェントによる多段階プランニング
`gpt-4.1`, `gpt-4o`, `gpt-4o-mini`	安定したベースライン

画像生成:

gpt-image-2: 最新、鮮明な出力、高速。
gpt-image-1.5 / gpt-image-1 / dall-e-3 / dall-e-2: 古いが安定した選択肢。

テキスト読み上げ:

gpt-4o-mini-tts: 最新の自然な音声。
tts-1, tts-1-hd: クラシックなTTS、低レイテンシー用途。

ステップ3: GPT-5.5に応答させる

最小構成のチャット呼び出しです。

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>
  <script>
    puter.ai.chat(
      "WebSocketsについて3文で説明してください。",
      { model: "gpt-5.5" }
    ).then(response => {
      puter.print(response);
    });
  </script>
</body>
</html>

このHTMLをブラウザで開くと、Puterが呼び出しを処理します。ユーザーは必要に応じてPuterにサインインし、応答がページに表示されます。APIキー、環境変数、サーバーは不要です。

ステップ4: 応答をストリーミングする

チャットUIや長文生成では、stream: trueを使って逐次表示します。

const response = await puter.ai.chat(
  "相対性理論について詳しく説明してください。",
  { model: "gpt-5.5", stream: true }
);

for await (const part of response) {
  puter.print(part?.text);
}

part.textをUIのメッセージバブルに追記すれば、ユーザーには回答がリアルタイムに生成されているように見えます。

ステップ5: ビジョン、画像入力を使う

第2引数に画像URLを渡すと、モデルに画像を読み取らせて質問できます。

puter.ai.chat(
  "この画像に何が見えますか？色、オブジェクト、雰囲気を説明してください。",
  "https://assets.puter.site/doge.jpeg",
  { model: "gpt-5.5" }
).then(response => {
  puter.print(response);
});

用途例:

altテキスト生成
ビジュアルQA
スクリーンショット分析
OCR
アクセシビリティ支援

ステップ6: 画像を生成する

puter.ai.txt2img()は、生成済み画像を含む<img>要素を返します。

puter.ai.txt2img(
  "未来的な夜の都市景観、シネマティック、ネオン、雨。",
  { model: "gpt-image-2" }
).then(imageElement => {
  document.body.appendChild(imageElement);
});

画像生成の費用は、ユーザーのPuterアカウント残高から支払われます。無料公開の画像ジェネレーターやプロトタイプを作る場合、開発者側でOpenAI請求を抱えない構成にできます。

ステップ7: テキスト読み上げを実装する

OpenAI TTSはtxt2speech()から呼び出せます。戻り値は音声を含む<audio>要素です。

puter.ai.txt2speech(
  "おかえりなさい。あなたのアカウント残高は$1,247.50です。",
  { provider: "openai", model: "gpt-4o-mini-tts" }
).then(audio => {
  audio.setAttribute("controls", "");
  document.body.appendChild(audio);
});

使用例:

音声プロンプト
アプリ内ナレーション
ポッドキャストイントロ
アクセシビリティ向け読み上げ

ステップ8: 関数呼び出しを使う

関数呼び出しは、OpenAI形式に近い形でツールを宣言します。

const tools = [{
  type: "function",
  function: {
    name: "get_weather",
    description: "都市の現在の天気を取得します。",
    parameters: {
      type: "object",
      properties: {
        city: { type: "string" }
      },
      required: ["city"],
    },
  },
}];

const response = await puter.ai.chat(
  "東京の現在の天気は？",
  { model: "gpt-5.5", tools }
);

const toolCalls = response.message.tool_calls;

if (toolCalls?.length) {
  // ここで実際の関数を実行し、結果をモデルに返す
  console.log(
    toolCalls[0].function.name,
    toolCalls[0].function.arguments
  );
}

既存のOpenAI向けツール定義がある場合、近い形式で再利用できます。本番環境でツール駆動型フローを検証する場合は、ApidogでのMCPサーバーテストも参考になります。

ステップ9: temperatureとmax_tokensを調整する

標準的なOpenAIパラメータは、オプションオブジェクトに渡します。

const response = await puter.ai.chat(
  "火星について教えてください。",
  {
    model: "gpt-5.5",
    temperature: 0.2,
    max_tokens: 200,
  }
);

目安:

事実ベースの回答: temperature: 0.0〜0.3
創造的な文章: temperature: 0.7〜1.0
コスト制御: max_tokensで出力上限を設定

公開アプリでは、max_tokensを設定してユーザー側の消費を予測しやすくするのが実用的です。

提供されるものと、されない可能性があるもの

Puter経由のGPT-5.5アクセスは便利ですが、公式OpenAI APIの全機能をそのまま置き換えるものではありません。

提供されるもの:

GPT-5.5、GPT-5.5 Pro、GPT-5.4系、Codex系バリアント
GPT-4.1、GPT-4o、o1、o3などの既存OpenAIモデル
GPT-Image-2およびDALL-Eによる画像生成
gpt-4o-mini-ttsを含むOpenAI TTS
ストリーミング
ビジョン入力
関数呼び出し
temperature
max_tokens

提供されない可能性があるもの:

Responses API
プロンプトキャッシュによるコスト最適化
Files API
ブラウザセッションなしのサーバーサイド利用
OpenAIからの直接のレートリミットヘッダー
OpenAIの構造化出力モードやJSONスキーマ強制

本格的なサーバーサイド本番フローには、公式OpenAI APIが適しています。一方、ブラウザアプリ、サイドプロジェクト、公開ツール、静的サイトではPuterが実装しやすい選択肢です。

Puterと公式OpenAI APIの使い分け

Puterを使う場合

無料公開アプリをリリースしたい
開発者側の課金リスクを避けたい
OpenAI APIキーを管理したくない
静的サイト、ハッカソン、ブラウザ拡張機能でAI機能を使いたい
ユーザーがPuterサインインを許容できる

公式OpenAI APIを使う場合

cron、Webhook、バッチ処理などサーバーサイド呼び出しが必要
プロンプトキャッシュでコストを最適化したい
Responses API、Files、構造化出力が必要
コンプライアンス上の契約関係が必要
ユーザーに外部サインインを要求できない

多くのプロジェクトでは、まずPuterでプロトタイプを作り、制限に当たった段階で公式APIへ移行する流れが現実的です。メッセージ形式が近いため、移行作業も比較的シンプルです。

有料の本番環境セットアップについては、GPT-5.5 APIの使用方法を参照してください。

Apidogで統合テストを整理する

Puterの呼び出しはブラウザ内で発生するため、バックエンドのテストランナーから直接実行する構成には向きません。実装時は次のように分けると管理しやすくなります。

Puterスクリプトを含む小さな静的ページを作る。
プロンプトやモデル名をクエリパラメータで渡せるようにする。
将来移行する可能性のある公式OpenAI APIのリクエストをApidogで定義する。
Puter検証用とOpenAI本番用を、同じApidogコレクション内の別環境として管理する。

Apidogをダウンロードし、次のような環境を作成します。

puter-prototype: Puterページをホストするlocalhost URL
openai-prod: https://api.openai.com/v1

これにより、プロトタイプから本番移行する際も、同じコレクションをベースに検証できます。より広いAPIテスト設計については、QAエンジニア向けのAPIテストツールを参照してください。

FAQ

これは本当に無制限ですか？

開発者側から見ると無制限です。エンドユーザーは自身のPuterアカウント残高を使います。新規アカウントには初期クレジットが付与され、必要に応じてユーザーがチャージします。

OpenAIアカウントは必要ですか？

いいえ。OpenAIとの接続はPuter側が処理します。開発者がOpenAI APIキーを扱う必要はありません。

本番環境で使えますか？

ブラウザベースのアプリであれば使えます。判断ポイントは、ユーザーがPuterにサインインすることを許容できるかどうかです。

Puter経由のGPT-5.5は公式APIと同じ性能ですか？

Puterはユーザーの代理として公式OpenAI APIを呼び出します。追加ホップによりレイテンシーが少し増える可能性はありますが、モデルの動作自体は変わりません。

プロンプトキャッシュは使えますか？

Puterは現在、OpenAIのプロンプトキャッシュの価格管理機能を公開していません。大きな固定システムプロンプトを使い、キャッシュ割引が重要な場合は公式APIを使ってください。

バックエンドサービスで使えますか？

きれいには使えません。Puterはブラウザファーストで、ユーザーセッションを前提とします。バックエンドサービスでは公式OpenAI APIを使うべきです。無料のサーバーサイド選択肢については、GPT-5.5 APIを無料で使う方法を参照してください。

どのモデルをデフォルトにすべきですか？

日常的な推論にはgpt-5.5、大量分類にはgpt-5.4-nano、複雑な推論にはgpt-5.5-pro、長い推論チェーンにはo3が候補です。

ユーザーに高額な料金がかかりますか？

多くのチャット用途では、1セッションあたり数セント程度に収まるケースが一般的です。ただし画像生成は相対的に高くなります。max_tokensを設定し、不要な生成呼び出しを避けてください。

Puterで画像を生成できますか？

はい。txt2img()でgpt-image-2またはDALL-Eを使えます。画像生成費用はユーザーのPuter残高から支払われます。公式の有料APIガイドは、GPT-Image-2 APIの使用方法を参照してください。

まとめ

Puter.jsを使うと、ブラウザベースのアプリにGPT-5.5、画像生成、TTS、ストリーミング、関数呼び出しを短いコードで組み込めます。開発者はOpenAIキーを持たず、エンドユーザーのPuterアカウントで利用量が処理されます。

サーバーサイド処理、プロンプトキャッシュ、Responses API、Files API、厳密な構造化出力が必要な場合は、公式OpenAI APIを選んでください。プロトタイプ、ハッカソン、無料公開アプリ、静的サイトではPuterが実装しやすい選択肢です。

Apidogでリクエストを整理し、Puter版と公式API版を比較して、プロジェクトに合う実装パスを選びましょう。

無料無制限 Claude Opus 4.7 API 入手

Akira — Sat, 09 May 2026 02:28:46 +0000

AnthropicのClaudeファミリーは、本格的なコーディング、エージェント的な作業、長文コンテキストの推論に強いクローズドソースモデルラインであり、API価格にもそれが反映されています。Sonnetは100万トークンあたり3ドル/15ドル、Opusはそれ以上です。サイドプロジェクトやプロトタイプでは、このコストが導入前のブレーキになりがちです。Puter.jsを使うと、AnthropicキーなしでClaudeのラインアップ（Opus 4.7、Sonnet 4.6、Haiku 4.5、その他のバリアント）をブラウザから利用でき、課金は開発者ではなくエンドユーザー側のPuterアカウントに紐づきます。

今すぐApidogを試す

このガイドでは、Puter.jsでClaudeを呼び出すためのセットアップ、モデルID、実装コード、ストリーミング、複数ターン会話、公開前に確認すべき制約を順に説明します。

TL;DR

Puter.jsを使うと、APIキーなし、Anthropicへの直接課金なし、サーバーなしでClaudeファミリーをブラウザから呼び出せます。
エンドユーザーはPuterアカウントで自身の使用量をまかないます。開発者側でAnthropicキーを管理する必要はありません。
サポートされるモデル: Opus 4.7, Opus 4.6, Opus 4.6 Fast, Opus 4.5, Opus 4.1, Opus 4, Sonnet 4.6, Sonnet 4.5, Sonnet 4, Haiku 4.5。
最小構成は、1つの<script>タグとputer.ai.chat()の呼び出しだけです。
ストリーミング、システムプロンプト、複数ターンの会話に対応しています。
ベンチマークする場合は、ApidogでPuter経由のClaudeと公式Anthropic APIに対して同じプロンプトを実行すると比較しやすくなります。

「無料無制限」の仕組み

Puter.jsは、ブラウザで動作するサーバーレスのクラウドおよびAIライブラリです。

通常は開発者がAnthropic APIキーを保持し、利用量に応じて課金されます。一方、Puter.jsではエンドユーザーがPuterにサインインし、そのPuterアカウントの残高からAPI呼び出しの料金が処理されます。新規Puterアカウントにはスタートアップクレジットが付与され、必要に応じてユーザーがチャージできます。

開発者側の実装上のメリットは次の通りです。

APIキーをリポジトリに置かなくてよい

キー漏洩、ローテーション、プロジェクトごとのキー管理を避けられます。
開発者側で使用量を負担しない

各ユーザーが自身のPuterアカウントで実行するため、開発者のAnthropic請求に利用量が集中しません。
Anthropicとの直接契約が不要

Puterが仲介するため、Anthropicキーなしで利用できます。

ただし、Puter.jsはブラウザファーストです。ログイン済みユーザーセッションを前提とするため、バックエンドのPythonスクリプト、cron、Discordボットなどから直接使う用途には向きません。その場合は公式Anthropic APIを使う方が適しています。

ステップ1: Puter.jsを読み込む

静的HTMLやプロトタイプでは、HTMLに次のタグを追加するだけです。

<script src="https://js.puter.com/v2/"></script>

ビルドステップは不要です。npm install、APIキー設定、サーバー実装も必要ありません。

Vite、Webpack、Next.jsなどのバンドル環境で使う場合は、NPMパッケージも利用できます。

npm install @heyputer/puter.js

import { puter } from '@heyputer/puter.js';

最小検証ならCDNタグが最速です。既存のフロントエンドアプリに組み込む場合はNPMインポートを使うと管理しやすくなります。

ステップ2: Claudeモデルを選ぶ

PuterはClaudeの複数モデルを公開しています。モデルIDはAnthropicの命名規則に近い形式です。

モデルID	使用する場面
`claude-opus-4-7`	最新のフラッグシップ。深い推論、複雑なエージェント的作業
`claude-opus-4-6`	以前のフラッグシップ。強力なコーディング用途
`claude-opus-4.6-fast`	低レイテンシーのOpusバリアント
`claude-opus-4-5`	プロダクションエージェント向けの安定した選択肢
`claude-opus-4-1`	レガシーな安定版。挙動を読みやすい
`claude-opus-4`	Opus 4のベースライン
`claude-sonnet-4-6`	日常利用のデフォルト候補。品質と速度のバランスがよい
`claude-sonnet-4-5`	以前のSonnet。多くのタスクで十分に実用的
`claude-sonnet-4`	Sonnet 4のベースライン
`claude-haiku-4-5`	高速・低コスト。分類や軽量タスク向け

最初は次のように選ぶと実装しやすいです。

通常のチャット、Q&A、コード補助: claude-sonnet-4-6
高速な分類、大量処理: claude-haiku-4-5
長文推論、複雑なコードレビュー、多段階計画: claude-opus-4-7

ステップ3: 最小コードでClaudeを呼び出す

まずはHTMLファイル1つで動作確認します。

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>

  <script>
    puter.ai.chat(
      "Explain quantum computing in simple terms",
      { model: 'claude-sonnet-4-6' }
    ).then(response => {
      puter.print(response.message.content[0].text);
    });
  </script>
</body>
</html>

このファイルをブラウザで開くと、PuterがAPI呼び出しを処理します。ユーザーは必要に応じてPuterにサインイン、または初回実行時に無料アカウントを作成します。

レスポンスはAnthropicのメッセージAPIに近い構造です。プレーンテキストを読む場合は、通常次のフィールドを参照します。

response.message.content[0].text

複数のコンテンツブロックが返る可能性がある場合は、配列として処理します。

for (const block of response.message.content) {
  if (block.type === 'text') {
    console.log(block.text);
  }
}

ステップ4: 応答をストリーミングする

長い回答では、完了まで待ってから表示すると遅く感じられます。stream: trueを指定し、for awaitでチャンクを処理します。

const response = await puter.ai.chat(
  "Write a detailed essay on the impact of artificial intelligence on society",
  {
    model: 'claude-sonnet-4-6',
    stream: true
  }
);

for await (const part of response) {
  puter.print(part?.text);
}

チャットUIに組み込む場合は、各part.textを既存のメッセージ要素に追記します。

const output = document.querySelector('#assistant-message');

for await (const part of response) {
  if (part?.text) {
    output.textContent += part.text;
  }
}

これで、ユーザーは回答がリアルタイムに生成されているように感じられます。

ステップ5: 複数ターンの会話を実装する

単発の文字列ではなく、メッセージ配列を渡すと会話履歴を維持できます。各メッセージはroleとcontentを持ちます。

const messages = [
  { role: 'user', content: 'I am building a Next.js app with Postgres.' },
  { role: 'assistant', content: 'Got it. What do you need help with?' },
  { role: 'user', content: 'How should I structure the migrations folder?' },
];

const response = await puter.ai.chat(messages, {
  model: 'claude-opus-4-7',
});

console.log(response.message.content[0].text);

実際のチャットUIでは、ユーザー入力とアシスタント応答を同じ配列に追加してから、次のリクエストで再送します。

const messages = [];

async function sendMessage(userText) {
  messages.push({ role: 'user', content: userText });

  const response = await puter.ai.chat(messages, {
    model: 'claude-sonnet-4-6',
  });

  const assistantText = response.message.content[0].text;

  messages.push({
    role: 'assistant',
    content: assistantText,
  });

  return assistantText;
}

Claudeは渡されたトランスクリプト全体を参照して、文脈を維持します。

ステップ6: システムプロンプトを設定する

出力形式、ペルソナ、制約はシステムメッセージで定義します。

const messages = [
  {
    role: 'system',
    content: 'You are a senior backend engineer. Reply in numbered bullets, never more than five.'
  },
  {
    role: 'user',
    content: 'How do I prevent SQL injection in a Node app?'
  },
];

const response = await puter.ai.chat(messages, {
  model: 'claude-sonnet-4-6'
});

console.log(response.message.content[0].text);

システムプロンプトは、次のような制御に向いています。

回答の粒度
出力フォーマット
禁止事項
口調
役割設定
コード例の有無

例として、日本語で短く回答させたい場合は次のようにします。

const messages = [
  {
    role: 'system',
    content: 'あなたは経験豊富なWebエンジニアです。回答は日本語で、実装手順を中心に簡潔に説明してください。'
  },
  {
    role: 'user',
    content: 'Expressで認証ミドルウェアを設計する方法を教えてください。'
  },
];

同じプロンプトでモデルを比較する

ユースケースに合うモデルを選ぶには、同じプロンプトを複数モデルに投げて、速度と出力品質を比較します。

const models = [
  'claude-haiku-4-5',
  'claude-sonnet-4-6',
  'claude-opus-4-7'
];

const prompt = "Refactor this React component to use hooks: ...";

for (const model of models) {
  const start = performance.now();

  const response = await puter.ai.chat(prompt, { model });

  const elapsed = performance.now() - start;

  console.log(`${model}: ${elapsed.toFixed(0)}ms`);
  console.log(response.message.content[0].text);
  console.log('---');
}

比較時は、少なくとも次の観点を記録すると判断しやすくなります。

初回応答までの時間
完了までの時間
コードの正確性
指示への追従
回答の冗長さ
失敗時の挙動

一般的には、軽い分類や要約はHaiku、日常的な実装支援はSonnet、複雑な推論やレビューはOpusから試すとよいです。

ApidogでPuterの無料パスと公式Anthropic APIを比較する場合は、両プロバイダーを同じコレクション内に保持し、環境を切り替えて同じプロンプトを実行します。

得られるものと得られないもの

Puter経由でClaudeを使うと、ブラウザアプリに素早くAI機能を組み込めます。ただし、公式APIのすべての機能を同じ粒度で制御できるわけではありません。

得られるもの:

Claudeモデルのカタログ
複数ターン会話
システムプロンプト
ストリーミング応答
ブラウザからの直接呼び出し
開発者側のAnthropic APIキー不要
開発者側の課金負担なし

得られない可能性があるもの（Puterのバージョンに依存）:

ネイティブのツール使用 / 関数呼び出し
ビジョン入力（画像添付）
Anthropicのプロンプトキャッシュによるコスト制御
ブラウザコンテキストなしでのサーバーサイド利用
Anthropicのレート制限ヘッダーなどの直接的な可視性

詳細なツール使用ワークフローが必要な場合は、公式Anthropic APIまたはApidogでのMCPサーバーテストのような構成の方が制御しやすくなります。

一方、一般的なチャットボット、Q&Aアプリ、コンテンツ生成、学習用プロトタイプであれば、Puter.jsの機能で十分なケースが多いです。

Puterと公式Anthropic APIの使い分け

Puterを使うべき場合

無料の公開アプリをリリースし、開発者側の課金負担を避けたい。
プロトタイプ段階で、Anthropicの請求設定をまだ行いたくない。
静的サイト、ハッカソンプロジェクト、ブラウザ拡張機能にClaudeを組み込みたい。
サーバーを立てずにフロントエンドだけで試したい。
ユーザーがPuterへのサインインを許容できる。

公式Anthropic APIを使うべき場合

cronジョブ、APIエンドポイント、バッチ処理などサーバーサイド実行が必要。
安定した長いシステムプロンプトに対してプロンプトキャッシュを使いたい。
高度なツール使用、ビジョン入力、Files APIなどが必要。
コンプライアンスや契約面でAnthropicとの直接関係が必要。
ユーザーにPuterサインインを要求できない。

多くのプロジェクトでは、最初にPuterでプロトタイプを作り、制約に当たった段階で公式APIへ移行する流れが現実的です。メッセージ形式が近いため、移行時の設計変更を抑えやすくなります。

GPT系APIの同等機能については、GPT-5.5 APIの使用方法も参照してください。

Apidogで連携テストする

Puterの呼び出しはブラウザで実行されるため、一般的なバックエンドAPIテストランナーから直接同じ形で叩くことはできません。実装時は、次のように分けて検証すると扱いやすくなります。

Puterスクリプトを含む小さな静的ページを作る。
プロンプトをクエリパラメータや入力欄から渡せるようにする。
公式Anthropic APIへ移行する可能性がある場合は、ApidogでAnthropic APIのリクエストも定義する。
Puter用とAnthropic用を別環境として管理する。
同じプロンプトで速度、出力、失敗時の挙動を比較する。

Apidogをダウンロードし、例えば次の2つの環境を作成します。

puter-prototype

Puterページをホストするlocalhost URL
anthropic-prod

https://api.anthropic.com/v1

Puterでプロトタイプを作り、必要になったら公式APIに移行する場合でも、同じプロンプトセットを使って比較できます。

FAQ

これは本当に無制限ですか？隠れた上限はありますか？

開発者側から見ると無制限です。エンドユーザーは自身のPuterアカウントの残高を使用します。新規アカウントにはスタートアップクレジットが付与され、必要に応じてユーザーがチャージします。

Anthropicに登録する必要はありますか？

いいえ。PuterがAnthropicとの関係を処理します。開発者がAnthropic APIキーを扱う必要はありません。

本番環境で使えますか？

ブラウザベースのアプリであれば使用できます。確認すべきポイントは、ユーザーがPuterへのサインインを許容できるかどうかです。

Puter経由のClaudeは公式APIと同じように動作しますか？

Puterはユーザーに代わってClaudeを呼び出します。追加の経路があるため、レイテンシーが変わる可能性はあります。モデル選定や出力品質は、実際のプロンプトで比較するのが安全です。

Claudeのプロンプトキャッシュは使えますか？

Puterは現在、Anthropicのプロンプトキャッシュの料金制御を直接公開していない可能性があります。安定した長いシステムプロンプトがあり、キャッシュ割引を前提にしたい場合は公式APIを検討してください。

Discordボットやバックエンドサービスで使えますか？

Puterはブラウザファーストで、ユーザーセッションを前提とします。バックエンドサービス、Bot、cron、バッチ処理には公式Anthropic APIの方が適しています。

どのモデルをデフォルトにすべきですか？

まずはclaude-sonnet-4-6が扱いやすいです。より深い推論が必要ならclaude-opus-4-7、大量の軽量処理ならclaude-haiku-4-5を試します。

ユーザーに高額請求が発生しますか？

チャットスタイルの一般的な利用であれば、使用量は比較的小さくなりやすいです。ただし、長文コンテキストや大量実行では消費が増えるため、アプリ側でプロンプト長や実行頻度を制御する設計が重要です。

まとめ

Puter.jsを使うと、Anthropic APIキーを管理せずに、ブラウザベースのアプリへClaudeを組み込めます。実装はシンプルです。

<script src="https://js.puter.com/v2/"></script>を追加する。
モデルIDを選ぶ。
puter.ai.chat()を呼び出す。
必要に応じてストリーミング、会話履歴、システムプロンプトを追加する。

サーバーサイド処理、プロンプトキャッシュ、高度なツール使用、厳密なコンプライアンス要件がある場合は、公式Anthropic APIを使う方が適しています。

一方で、プロトタイプ、無料公開アプリ、ハッカソン、サイドプロジェクト、静的サイトでは、Puter.jsは導入コストの低い選択肢です。

Apidogで同じプロンプトを管理し、Puter経由と公式APIを比較して、アプリに合う実装方針を選びましょう。

Grok 4.3を無料で使う方法：2026年、4つの有効な手段

Akira — Sat, 09 May 2026 02:24:58 +0000

Grok 4.3は、2026年5月時点でのxAIの主力モデルです。1Mトークンのコンテキストウィンドウ、ネイティブ動画入力、100万トークンあたり$1.25/$2.50の価格設定が特徴ですが、プロトタイプ、学習、サイドプロジェクトであれば、次の3つの経路で無料利用を始められます。xAIコンソールのプロモーションクレジット、Puter.jsのユーザー支払いモデル、そしてgrok.com / Xの無料チャットUIです。

今すぐApidogを試す

この記事では、それぞれの経路について、アカウント設定、実装例、API呼び出し、導入前に確認すべき制約を実装ベースで整理します。有料APIの詳細は「Grok 4.3 APIの利用方法」、音声版は「Grok Voiceを無料で利用する方法」を参照してください。

TL;DR

Grok 4.3への無料パスは3つ: xAIコンソールのプロモーションクレジット、Puter.js、grok.com / XチャットUI。
開発者向けに最も実装しやすいのはPuter.js: エンドユーザーが利用料を負担するため、開発者側でAPIキーや請求を管理しません。
API統合の検証にはxAIコンソール: 新規アカウントのプロモーションクレジットで、実際のAPIサーフェスを試せます。
コード不要ならgrok.com / X: 1日のメッセージ制限はありますが、API実装なしで試せます。
Puter.jsのモデルIDは x-ai/grok-4.3、xAI直接利用のモデルIDは grok-4.3。
Apidogを使うと、xAI直接利用とOpenRouterのリクエストを同じスキーマで比較できます。

パス1: xAIコンソールのプロモーションクレジット

実際のGrok 4.3 APIを試したい場合は、xAIコンソールから始めるのが最短です。プロダクションと同じAPI形式で検証できます。

ステップ1: xAIコンソールにサインアップする

console.x.ai にアクセスし、アカウントを作成します。サインインはXアカウント経由で行われます。X側で求められる認証以外に、追加のメール認証は不要です。

ステップ2: Billingでクレジットを確認する

xAIは、新規アカウント向けに無料クレジットを付与するプロモーションを実施することがあります。金額や対象期間は変わるため、サインアップ後に Billing タブを確認してください。

過去には、Grok 4.1 FastやAgent Tools APIなど、特定モデルや機能に対する無料利用プロモーションも提供されています。通常、このクレジットは自動更新されないため、プロトタイプ検証用として使うのが現実的です。

ステップ3: APIキーを環境変数に設定する

export XAI_API_KEY="xai-..."

ステップ4: Chat Completions APIを呼び出す

xAIのエンドポイントはOpenAI互換です。

curl https://api.x.ai/v1/chat/completions \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-4.3",
    "messages": [
      {
        "role": "user",
        "content": "Explain prompt caching in three sentences."
      }
    ],
    "reasoning_effort": "low"
  }'

プロトタイプ段階では、まず reasoning_effort を low にします。medium や high は推論コストが増え、無料クレジットを早く消費します。

長所と短所

長所	短所
実際のプロダクションAPIサーフェスを試せる	クレジットは有限
1Mコンテキスト、動画入力、関数呼び出しを検証できる	プロモーション条件は変更される
有料プラン移行時のコード変更が少ない	無料枠内でしか使えない

推奨: 本番APIの挙動を確認したい場合は、xAIコンソールから始めてください。完全なリクエストスキーマは「Grok 4.3 APIの利用方法」で確認できます。

パス2: Puter.js（ユーザー支払い、開発者無料）

公開WebアプリにGrok 4.3を組み込みたい場合、Puter.jsは最も実装しやすい無料パスです。開発者ではなく、エンドユーザーのPuterアカウントに利用料が紐づきます。

仕組み

Puter.jsは、Grok、GPT、Claude、Gemini、DeepSeekなどのLLMをブラウザから呼び出せるJavaScriptクライアントです。

通常のAPI連携では、開発者がAPIキーを管理し、利用料を支払います。一方、Puter.jsでは、エンドユーザーが自身のPuterアカウントで利用料を負担します。そのため、開発者は請求設定やAPIキー配布を管理せずに、無料ツールやサイドプロジェクトを公開できます。

ステップ1: Puter.jsを読み込む

HTMLに次のscriptタグを追加します。

<script src="https://js.puter.com/v2/"></script>

APIキーは不要です。開発者側でPuterアカウントを作成する必要もありません。

ステップ2: Grok 4.3を呼び出す

puter.ai.chat() にモデルID x-ai/grok-4.3 を指定します。

<script src="https://js.puter.com/v2/"></script>

<script>
  puter.ai.chat(
    "Summarize the trade-offs between SQLite and Postgres in three bullets.",
    { model: "x-ai/grok-4.3" }
  ).then((response) => {
    document.body.innerText = response.message.content;
  });
</script>

ユーザーが初めて実行すると、Puterはサインインまたは無料アカウント作成を求めます。その後のAI利用は、ユーザー自身のPuter残高から消費されます。

ステップ3: ストリーミングを使う

ストリーミングレスポンスも利用できます。

const stream = await puter.ai.chat(
  "Walk me through migrating a React app to Next.js.",
  {
    model: "x-ai/grok-4.3",
    stream: true,
    reasoning_effort: "medium",
  }
);

for await (const chunk of stream) {
  process.stdout.write(chunk?.text || "");
}

ブラウザUIに表示する場合は、process.stdout.write の代わりにDOMを更新します。

const output = document.querySelector("#output");

for await (const chunk of stream) {
  output.textContent += chunk?.text || "";
}

長所と短所

長所	短所
開発者の費用が継続的に0ドル	ユーザーはPuterにサインインする必要がある
リポジトリにAPIキーを置かなくてよい	バックエンド専用処理には向かない
複数LLMを同じ形式で扱える	xAI直接利用よりレイテンシが増える場合がある
公開Webアプリに組み込みやすい	ブラウザコンテキストが前提

推奨: 公開Webアプリ、無料ツール、サイドプロジェクト、課金管理を持ちたくないプロダクトではPuter.jsが有効です。一方、社内バッチ、Discordボット、サーバーサイド自動化など、ユーザーがブラウザで直接実行しない用途には向きません。

関連する無料APIパターンは「DeepSeek V4 APIを無料で利用する方法」および「GPT-5.5 APIを無料で利用する方法」も参照してください。

パス3: grok.comとXアプリ

コードから呼び出す必要がなく、Grok 4.3と会話できればよい場合は、チャットUIを使います。

grok.com: Xアカウントでサインインして使うWebチャット。
Xアプリ: モバイルアプリまたはWebアプリのGrokタブから利用。

無料ユーザーには1日のメッセージクォータがあります。クォータは24時間ごとにリセットされます。

このパスはAPIではないため、スクリプト化やアプリへの組み込みはできません。用途は次のようなケースです。

単発の調査質問
API実装前のプロンプト検証
モデルの応答傾向の確認
Grokが対象タスクに合うかの事前評価

grok.com の無料プランでは、デフォルトでより小さなGrokバリアント（現在はGrok 4.1）が使われます。Xのプレミアムサブスクリプションでは、チャットUI上でGrok 4.3がアンロックされ、より高いクォータが提供されます。

パス4: OpenRouter（安価だがGrok 4.3は無料ではない）

OpenRouterは、複数のモデルプロバイダーを1つのAPIキーと共通インターフェースで扱えるゲートウェイです。

OpenRouter経由のGrok 4.3は、xAI直接利用と同じく100万トークンあたり$1.25/$2.50なので無料ではありません。ただし、OpenRouterでは一部のGrokモデルに対して、無料バリアント（例: grok-4-fast:free）が提供されています。

Grok 4.3そのものが必要な場合は、上記3つのパスを使います。Grok系の出力を無料で試したいだけなら、OpenRouterの無料モデルを検討できます。

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "x-ai/grok-4-fast:free",
    "messages": [
      {
        "role": "user",
        "content": "Hello!"
      }
    ]
  }'

OpenRouterは、同じキーでDeepSeekや他のオープンモデルを試す用途にも使えます。

4つのパスの比較

パス	開発者にとってのコスト	エンドユーザーにとってのコスト	最適な用途
xAIコンソール（クレジット）	$0（クレジット内）	該当なし	APIプロトタイプ、本番APIの学習
Puter.js	継続的に$0	セッションあたり数セント	公開Webアプリ、無料ツール、サイドプロジェクト
grok.com / X	$0	$0（クォータあり）	非開発者、単発質問、プロンプト検証
OpenRouter無料モデル	$0	該当なし	Grok 4.3に限定しない無料のGrok系出力

ApidogでxAIとOpenRouterのリクエストを比較する

複数プロバイダーで同じモデル系統を使う場合は、同一リクエストを保存し、ベースURLとモデルIDだけを切り替えて比較すると検証が速くなります。

セットアップ例

Apidogで新しい環境を作成する。
環境変数を追加する。
- XAI_API_KEY
- OPENROUTER_API_KEY
- BASE_URL
xAI用の環境を作成する。
- BASE_URL=https://api.x.ai/v1
OpenRouter用の環境を作成する。
- BASE_URL=https://openrouter.ai/api/v1
Chat Completions用のリクエストを1つ作成する。
環境を切り替えて、レスポンス、トークン数、レイテンシを比較する。

Apidogをダウンロードして、新しいコレクションを作成してください。xAIとOpenRouterはいずれもOpenAI Chat Completionsスキーマに対応しているため、モデル文字列を除けばリクエストボディをほぼ同じにできます。

クロスプロバイダーテストの詳細は「QAエンジニア向けAPIテストツール」を参照してください。

無料利用で注意すべき制約

無料パスを使う場合、次の制約を前提に設計してください。

1. レート制限が厳しい

コンソールクレジットは、無制限のスループットを意味しません。大量テストでは、クレジットを使い切る前に429エラーに到達する可能性があります。

実装時は、リトライとバックオフを入れてください。

async function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function callWithRetry(fn, retries = 3) {
  for (let i = 0; i < retries; i++) {
    try {
      return await fn();
    } catch (error) {
      if (error.status !== 429 || i === retries - 1) {
        throw error;
      }

      await sleep(1000 * Math.pow(2, i));
    }
  }
}

2. プロンプトキャッシングの効果を体感しにくい

Grok 4.3のプロンプトキャッシングは、100万トークンあたり$0.20で利用できる重要機能です。ただし、数十回程度のプロトタイプでは、キャッシュによるコスト削減は見えにくいです。

長いシステムプロンプトを繰り返し使う本番運用で効果が出ます。

3. サポートは限定的

無料コンソールアカウントでは、サポートはベストエフォートです。本番障害やSLAが必要な場合は、有料プランを前提にしてください。

有料プランに移行するタイミング

次のいずれかに当てはまる場合は、無料パスから有料利用への移行を検討します。

継続的なスループットが必要
- 週に複数回レート制限に到達する。
長い固定プロンプトを繰り返し使う
- 5万トークン以上の安定したシステムプロンプトがあり、キャッシングの恩恵を受けられる。
コンプライアンス要件がある
- SOC 2監査証跡、BAA、地域データレジデンシーなどが必要。

移行自体はシンプルです。OpenRouterではベースURLを切り替え、xAIコンソールではAPIキーや課金設定を更新します。OpenAI互換スキーマを維持していれば、アプリケーションコードの変更は最小限で済みます。

よくある質問

Grok 4.3は本当に無料ですか？

xAIコンソールでは、自動更新されないプロモーションクレジットによるトライアルです。Puter.jsでは、開発者にとっては構造的に無料です。利用料はユーザー側に紐づきます。grok.com では、無料の1日メッセージクォータがあります。

Grok 4.3をPythonやNode.jsのバックエンドから無料で使えますか？

はい。xAIコンソールの無料クレジットが残っている間は可能です。クレジットを使い切った後は、有料プランに移行するか、Puter.jsのようなユーザー支払いモデルに切り替える必要があります。

Puter.jsはNode.jsでも動作しますか？

Puter.jsはブラウザ優先です。ユーザー支払いモデルも、ブラウザ上でユーザーに認証を引き渡す設計です。バックエンド専用用途では、xAIコンソールのクレジットを使うのが現実的です。

PuterでGrok 4.3を使うモデルIDは何ですか？

x-ai/grok-4.3 です。PuterのLLMカタログでは、同じプロバイダー/モデル形式を使います。

無料クレジットで関数呼び出しや動画入力も使えますか？

はい。コンソールクレジットは、Grok 4.3の機能に対して通常の使用量として適用されます。1Mコンテキスト、関数呼び出し、動画入力、推論の労力を試せます。ただし、動画入力はコンテキストを大きく消費するため、トークン使用量に注意してください。

Grok Voiceの無料プランとは何が違いますか？

Grok Voiceはコンソール上で構造的に無料です（1分あたりの料金なし）。Grok 4.3テキストはクレジットで賄われます。詳しくは「Grok Voiceを無料で利用する方法」を参照してください。

無料のGrok 4.3 miniはありますか？

まだありません。xAIは4.3ライン向けの別ミニSKUをリリースしていません。近い選択肢は、OpenRouterの grok-4-fast:free です。ただし、これはGrok 4.3そのものではなく、より小さく高速なGrok 4バリアントです。

まとめ

Grok 4.3を無料で試す合法的なパスは3つあります。

本番APIに近い形で検証するなら xAIコンソール
公開Webアプリに組み込むなら Puter.js
コード不要で試すだけなら grok.com / X

Grok 4.3そのものが必要ない場合は、OpenRouterの無料Grok系モデルも選択肢になります。Grok 4.3を有料で使う場合でも、価格は100万トークンあたり$1.25/$2.50なので、サイドプロジェクトでも試しやすい水準です。

完全な有料APIチュートリアルは「Grok 4.3 APIの利用方法」、OpenAIとの比較は「Grok Voice vs GPT-Realtime」を参照してください。

Apidogでリクエストを一度作成し、ベースURLとモデルIDを切り替えれば、無料クレジット、OpenRouter、将来の有料運用まで同じ検証フローで扱えます。

Grok 4.3 API の使い方

Akira — Fri, 08 May 2026 07:41:17 +0000

xAIはGrok 4.3を段階的に展開しました。2026年4月17日にベータ版、4月30日にAPIアクセス、5月6日に一般提供が開始されています。主な変更点は、1,000,000トークンのコンテキストウィンドウ、Grokシリーズ初のネイティブビデオ入力、常時稼働の推論機能、Grok 4.20比で約40%の価格引き下げです。8つのレガシーGrokモデルは5月15日に廃止されるため、grok-3またはgrok-4系を使っている場合は、早めにgrok-4.3へ移行してください。

今すぐApidogを試す

この記事では、コードからGrok 4.3を呼び出す実装手順をまとめます。エンドポイント、認証、OpenAI互換のbase_url、reasoning_effort、ビデオ入力、関数呼び出し、そしてApidogでのテスト方法を扱います。

同じリリースの音声側については、Grok Voiceを無料で使う方法をご覧ください。OpenAIの主力音声モデルとの比較については、Grok Voice vs GPT-Realtimeをご覧ください。

要点

Grok 4.3は2026年5月6日にGAとなりました。
8つのレガシーモデルは2026年5月15日に廃止されます。
価格は入力100万トークンあたり1.25ドル、出力100万トークンあたり2.50ドル、キャッシュ入力は100万トークンあたり0.20ドルです。
Grok 4.20と比較して約40%の値下げです。
コンテキストウィンドウは100万トークンです。
Grokシリーズ初のネイティブビデオ入力をサポートします。
推論エフォートはlow / medium / highです。デフォルトはmediumです。
エンドポイントはhttps://api.x.ai/v1/chat/completionsです。
OpenAI互換のChat Completions形式で呼び出せます。
標準ティアのスループットは約159トークン/秒です。
Artificial Analysisのインテリジェンス指数は53で、146モデル中10位です。
Apidogを使うと、推論設定を変数化し、GrokとOpenAI互換モードの両方で同じリクエストを再生できます。

Grok 4.3で何が変わったか

Grok 4.3で実装時に影響が大きい変更は次の5つです。

1. 価格が下がった

Grok 4.20と比較して、入力は37.5%減、出力は58.3%減です。キャッシュされた入力は100万トークンあたり0.20ドルなので、長いシステムプロンプトや固定コンテキストを繰り返し使う構成ではコストを抑えやすくなります。

2. コンテキストが100万トークンになった

Grok 4.20の256kから、Grok 4.3では100万トークンに拡張されています。中規模のコードベース、長い契約書、決算説明会の全文などを1回のプロンプトに含めやすくなります。

3. ビデオURLを直接渡せる

Grokシリーズでは初めて、ネイティブビデオ入力に対応しました。アプリ側でキーフレームを手動抽出しなくても、ビデオURLをコンテンツブロックに含めて推論できます。

4. 推論が常時有効になった

Grok 4.3はすべてのリクエストでベースラインの推論ステップを実行します。reasoning_effortで深さを調整できますが、推論なしのモードにはなりません。

5. エージェント用途が改善された

Grok 4.20と比較してGDPval-AAで300 Eloポイント向上しています。ツール選択、多段階ワークフロー、ツールエラーからの回復など、エージェント実装で重要な挙動が改善されています。

前提条件

最初のリクエストを送る前に、次を用意します。

console.x.aiのxAIコンソールアカウント
APIキーを発行できる有料ティア
OpenAI SDKまたはxAI SDK
リクエストを保存・再実行できるAPIクライアント

APIキーは環境変数に入れておきます。

export XAI_API_KEY="xai-..."

Pythonサンプルを動かす場合は、必要に応じてSDKをインストールします。

pip install openai

エンドポイントと認証

Grok 4.3はOpenAI互換のChat Completionsインターフェースで呼び出します。

POST https://api.x.ai/v1/chat/completions

認証はBearerトークンです。

Authorization: Bearer $XAI_API_KEY
Content-Type: application/json

OpenAI SDKを使う場合は、base_urlをxAIのURLに変更します。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Summarize the trade-offs of GraphQL vs REST in three bullets."
        }
    ],
    reasoning_effort="medium",
)

print(response.choices[0].message.content)

既存のOpenAI SDKベースの実装では、主な変更点は次の2つです。

base_url = "https://api.x.ai/v1"
model = "grok-4.3"

リクエストパラメータ

Grok 4.3でよく使うパラメータは次の通りです。

パラメータ	タイプ	値	備考
`model`	string	`grok-4.3`	必須。
`messages`	array	OpenAIメッセージ形式	必須。`role: system / user / assistant`をサポートします。
`reasoning_effort`	string	`low`, `medium`, `high`	オプション。デフォルトは`medium`です。
`max_tokens`	int	1–32768	出力トークン数を制限します。
`temperature`	float	0.0–2.0	デフォルトは1.0です。
`top_p`	float	0.0–1.0	核サンプリング。
`stream`	bool	true / false	trueの場合、サーバー送信イベントでストリーミングします。
`tools`	array	OpenAIツール形式	関数呼び出しに使います。
`tool_choice`	string / object	`auto`, `none`, または特定のツール	OpenAI互換の指定方式です。
`response_format`	object	`{ type: "json_object" }`	構造化出力に使います。
`seed`	int	任意	`temperature: 0`と組み合わせて再現性を高めます。

最小のcurlリクエストは次の通りです。

curl https://api.x.ai/v1/chat/completions \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-4.3",
    "messages": [
      {
        "role": "system",
        "content": "You are a senior backend engineer."
      },
      {
        "role": "user",
        "content": "Review this query plan and flag the bottleneck."
      }
    ],
    "reasoning_effort": "high"
  }'

応答はOpenAI互換形式です。本文はchoices[].message.contentから取得します。

content = response.choices[0].message.content

利用量はusageで確認します。

usage = response.usage

print(usage.prompt_tokens)
print(usage.completion_tokens)
print(usage.total_tokens)

応答には、prompt_tokens、completion_tokens、reasoning_tokens、total_tokensの内訳が含まれます。

推論エフォートの選び方

reasoning_effortは、レイテンシ、出力トークン数、推論の深さに影響します。

`low`

分類、要約、ルール抽出、単純なQ&Aに使います。

{
  "reasoning_effort": "low"
}

レスポンスを速く返したいが、最低限の推論は維持したい場合に向いています。

`medium`

デフォルトです。カスタマーサポート、関数呼び出し、データ分析、単一ステップのツール利用など、一般的な本番トラフィックに使います。

{
  "reasoning_effort": "medium"
}

迷った場合はmediumから始めます。

`high`

多段階エージェント、長いコードレビュー、複雑な数学、計画が必要なタスクに使います。

{
  "reasoning_effort": "high"
}

精度を優先する代わりに、レイテンシとトークン消費が増えます。

Grok 4.3では推論が常時有効です。lowを指定しても推論は完全には無効になりません。低コスト・低レイテンシに寄せたい場合はlowを使い、推論そのものをゼロにする前提の設計は避けてください。

関数呼び出し

Grok 4.3ではOpenAI互換の関数呼び出し形式をそのまま使えます。

次の例では、ユーザーIDからユーザー情報を取得するlookup_userツールを定義します。

tools = [
    {
        "type": "function",
        "function": {
            "name": "lookup_user",
            "description": "Look up a user by ID.",
            "parameters": {
                "type": "object",
                "properties": {
                    "user_id": {
                        "type": "string"
                    }
                },
                "required": ["user_id"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Find user u_42 and tell me their last login."
        }
    ],
    tools=tools,
    reasoning_effort="medium",
)

tool_calls = response.choices[0].message.tool_calls
print(tool_calls)

実装フローは次の通りです。

toolsで呼び出し可能な関数を宣言する
モデルがtool_callsを返す
アプリ側で実際の関数を実行する
結果をtoolロールのメッセージとしてモデルに返す
最終回答を生成する

ツール実行後のメッセージ例です。

messages = [
    {
        "role": "user",
        "content": "Find user u_42 and tell me their last login."
    },
    response.choices[0].message,
    {
        "role": "tool",
        "tool_call_id": tool_calls[0].id,
        "content": '{"user_id":"u_42","last_login":"2026-05-01T10:30:00Z"}'
    }
]

final_response = client.chat.completions.create(
    model="grok-4.3",
    messages=messages,
    tools=tools,
)

print(final_response.choices[0].message.content)

GDPval-AAにおける300 Eloポイントの向上は、ツール選択や多段階処理で特に効きます。ツールフローを検証する場合は、ApidogでのMCPサーバーテストも参考になります。

ビデオ入力

Grok 4.3はネイティブビデオ入力をサポートします。ビデオURLは、messages[].contentの配列にvideo_urlとして渡します。

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Describe what happens in this clip and flag any anomalies."
                },
                {
                    "type": "video_url",
                    "video_url": {
                        "url": "https://example.com/clip.mp4"
                    }
                },
            ],
        }
    ],
)

print(response.choices[0].message.content)

ビデオ入力で注意する点は次の通りです。

ビデオは入力トークンとしてカウントされます。
長いクリップはコンテキストとコストを大きく消費します。
コストが重要な場合は、送信前にトリミングまたはダウンサンプリングします。
モデルがフレームをネイティブに推論するため、手動のキーフレーム抽出は必須ではありません。

100万トークンコンテキストの使いどころ

100万トークンのコンテキストは、単なるベンチマーク用ではなく、実装上も使いやすい機能です。

代表的なユースケースは次の通りです。

コードベース全体のレビュー

変更差分、関連ファイル、ログ、リント結果をまとめて渡し、レビューさせます。

以下をレビューしてください。

1. Git diff
2. 変更された全ファイル
3. テストログ
4. lint結果

観点:
- バグ
- セキュリティ
- パフォーマンス
- 後方互換性

長文ドキュメントQ&A

契約書、仕様書、議事録などをそのまま渡し、特定の質問に答えさせます。

以下の契約書を読み、解約条項、責任制限、更新条件を要約してください。
不明点がある場合は、該当箇所を引用してください。

長期会話履歴

エージェントの会話履歴を長く保持し、パーソナライズされた応答に使います。

キャッシュ入力は100万トークンあたり0.20ドルです。たとえば、安定した40万トークンのシステムプロンプトを使う場合、新規入力として毎回送るより、キャッシュされた呼び出しのほうが大幅に安くなります。

レガシーGrokモデルからの移行

8つのレガシーGrokモデルは2026年5月15日午後12時（PT）に廃止されます。該当モデルを本番環境で使っている場合は、期限までにmodelをgrok-4.3へ切り替えてください。

基本的なリクエスト形式は変わらないため、多くの呼び出しはモデル名の変更だけで動作します。

- model="grok-4.20"
+ model="grok-4.3"

移行時に確認すべき点は2つです。

1. `reasoning_effort`

一部のレガシーモデルではreasoning_effortを使っていなかった可能性があります。Grok 4.3は常に推論を実行するため、以前の高速な非推論パスと同じレイテンシを期待しないでください。

低レイテンシに寄せる場合は、まずlowで検証します。

response = client.chat.completions.create(
    model="grok-4.3",
    messages=messages,
    reasoning_effort="low",
)

2. 出力形式

Grok 4.3はGrok 4.20よりも構造化された出力を返す傾向があります。正規表現で強く後処理している場合は、切り替え前に実データで再テストしてください。

OpenAIライン全体の価格比較については、GPT-5.5の価格設定を、推論モデルの比較については、GPT-5.5 APIの使用方法をご覧ください。

ApidogでGrok 4.3をテストする

Grok 4.3を自分のユースケースで検証するには、同じプロンプトを複数設定で比較できる形にしておくと便利です。

手順は次の通りです。

Apidogで環境を作成する
XAI_API_KEYを環境変数として保存する
BASE_URLにhttps://api.x.ai/v1を設定する
reasoning_effortがlowのリクエストを作る
同じリクエストを複製してmediumとhighを作る
3つを実行する
応答内容、レイテンシ、usage.reasoning_tokensを比較する
OpenAI互換API向けの別バリアントを作り、同じ入力でモデル比較する

リクエストURLは次のように変数化できます。

{{BASE_URL}}/chat/completions

ヘッダーは次の通りです。

Authorization: Bearer {{XAI_API_KEY}}
Content-Type: application/json

ボディ例です。

{
  "model": "grok-4.3",
  "messages": [
    {
      "role": "system",
      "content": "You are a senior backend engineer."
    },
    {
      "role": "user",
      "content": "Review this API design and identify risks."
    }
  ],
  "reasoning_effort": "{{REASONING_EFFORT}}"
}

REASONING_EFFORTを環境変数またはリクエスト変数にしておくと、low、medium、highの比較が簡単になります。

比較を実行するには、Apidogをダウンロードしてください。プロバイダーを切り替えても同じコレクションを使い回せるため、Grok 4.3と他のOpenAI互換モデルを同じ条件で比較できます。

より広いAPIテスト戦略については、QAエンジニアのためのAPIテストツールをご覧ください。

レート制限

xAIコンソールのティア制限は、ティア1の1分あたり数千リクエストから、エンタープライズティアの数十万リクエストまで変化します。具体的な数値は変動するため、実装前にコンソールダッシュボードを確認してください。

xAIが公開している159トークン/秒のスループットは、集計値ではなくストリームごとの出力速度です。同時リクエスト数は、契約ティアの制限内でスケールします。

レート制限に達した場合、APIは429を返します。retry-afterヘッダーを見て、指数バックオフで再試行します。

import time
from openai import RateLimitError

for attempt in range(5):
    try:
        response = client.chat.completions.create(
            model="grok-4.3",
            messages=messages,
        )
        break
    except RateLimitError as e:
        wait = min(2 ** attempt, 30)
        time.sleep(wait)

本番環境では、次の対策を入れておくと安全です。

リクエストキューを使う
同時実行数を制御する
429をメトリクス化する
retry-afterを尊重する
長い入力はキャッシュする
max_tokensを明示して出力上限を制御する

よくある質問

Grok 4.3はOpenAI SDKで使えますか？

はい。Chat CompletionsについてはOpenAI互換です。OpenAI SDKを使い、base_urlとmodelを変更します。

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)

Responses APIをサポートしていますか？

現在、xAIのインターフェースはChat Completionsです。Responses APIはOpenAI専用です。

実際のコンテキスト制限はどのくらいですか？

1,000,000トークンです。ただし、長い入力は費用が増えるため、安定したプロンプトは積極的にキャッシュしてください。

常時稼働の推論機能はレイテンシに影響しますか？

はい。非推論モデルと比較すると、最初のトークンのレイテンシはやや高くなります。一方で、Grok 4.3は約159トークン/秒でストリーミングされるため、エンドツーエンドの応答時間は競争力があります。

精度を重視するワークロードでは、このトレードオフは受け入れやすいはずです。

Grok 4.3をGrok Voiceと組み合わせて使えますか？

はい。音声エージェントであるgrok-voice-think-fast-1.0は、推論時に内部でGrok 4.3を呼び出します。TTSやSTTプリミティブ上に構築した音声ループから、Grok 4.3を直接呼び出すこともできます。

5月15日以降、古いGrok 3 / Grok 4への呼び出しはどうなりますか？

410エラー、つまりモデル廃止エラーで失敗します。期限までにgrok-4.3へ移行してください。

Grok 4.3は画像入力をサポートしていますか？

はい。新しいビデオ入力と並行して画像入力もサポートします。OpenAIと同じ形式で、コンテンツブロックに画像URLを渡します。

まとめ

Grok 4.3は、価格、コンテキスト長、推論機能、ビデオ入力の面で大きく更新されたモデルです。OpenAI互換のChat Completions形式で呼び出せるため、既存のOpenAI SDKベースの実装では、主にbase_urlとmodelを変更するだけで移行できます。

最短の検証手順は、Apidogでlow、medium、highの3つの推論バリアントを作り、実際のプロンプトでレイテンシ、出力品質、推論トークン数を比較することです。

レガシーGrokモデルを使っている場合は、5月15日までにgrok-4.3へ移行してください。

2026年おすすめ音声モデル：Grok Voice vs GPT-Realtime 徹底比較

Akira — Fri, 08 May 2026 07:34:17 +0000

xAIがGrok Voiceを、OpenAIがGPT-Realtime-2を同じ週に展開したことで、2026年に音声モデルを選ぶ開発者には2つの現実的な主力候補があります。どちらも推論機能付きの音声対音声モデルで、WebSocket経由で動作し、ツール利用をサポートし、人間らしい抑揚で応答します。選定では、レイテンシ、価格、音声カタログ、推論の深さ、SIP・画像入力・音声クローニングの要否を具体的に比較してください。個別の導入手順は「GPT-Realtime-2の使い方」と「Grok Voiceを無料で使う方法」を参照できます。負荷下でWebSocketセッションを検証する場合は、Apidogを使うと比較テストを組みやすくなります。

今すぐApidogを試す

要約

Grok Voice (grok-voice-think-fast-1.0) は、レイテンシ、無料コンソールアクセス、音声カタログ、音声クローニングで優位です。
GPT-Realtime-2 は、推論の深さ、128kコンテキストウィンドウ、画像入力、ネイティブSIP、MCPで優位です。
有料利用の価格は大きく異なります。GPT-Realtime-2は音声入力が100万オーディオトークンあたり$32、音声出力が$64です。Grok Voiceはコンソール上では音声の分単位課金がなく、Grok 4.3の推論に対して100万トークンあたり$1.25/$2.50を支払います。
大量利用、低レイテンシ、音声クローニングが必要なアプリではGrok Voiceを優先します。
複雑な推論、マルチモーダル音声エージェント、SIPベースのコールセンターではGPT-Realtime-2を優先します。
ApidogでWebSocketテストを一度作成すれば、URLを切り替えて両モデルを比較できます。

2つのモデルを1つの表で比較

機能	Grok Voice (`grok-voice-think-fast-1.0`)	GPT-Realtime-2
最初の音声出力までの時間	1秒未満（xAIの主張: 最も近い競合より約5倍速い）	`low` 推論では1秒未満、`high` / `xhigh` ではより遅い
推論レベル	low / medium / high（Grok 4.3が基盤）	minimal / low / medium / high / xhigh
基盤となる知能	Grok 4.3（知能指数 53）	GPT-5クラス
コンテキストウィンドウ	1,000,000トークン（Grok 4.3）	128,000トークン
プリセット音声	80以上（Eve、Ara、Rex、Sal、Leoの5つの音声エージェントペルソナ）	10（新しく2つ: Cedar、Marin。8つは再調整済み）
言語（TTS）	28	公式には非公開
言語（STT）	25	GPT-Realtimeから継承
音声クローニング	あり。1分サンプル、2分未満のトレーニング	なし
画像入力	なし（テキスト + 音声のみ）	あり（写真、スクリーンショット）
リモートMCPサーバー	ツール利用は可能。ネイティブMCPは宣伝されていない	あり（APIがMCPツールを実行）
ネイティブSIP / 電話発信	自前のSIPプロバイダーを使用	あり（`?call_id={call_id}` エンドポイント）
オーディオ形式	PCM16、MP3、μ-law	PCM16、G.711 μ-law、A-law
料金モデル	音声についてはコンソールで無料。Grok 4.3の推論のみ課金（$1.25/$2.50/1M）	入力オーディオ1Mあたり$32、出力オーディオ1Mあたり$64、テキスト1Mあたり$4/$24
コンプライアンス	SOC 2 Type II、HIPAA準拠（BAA）、GDPR	SOC 2、GDPR（OpenAI Enterpriseに準拠）

レイテンシで選ぶならGrok Voice

xAIは、grok-voice-think-fast-1.0について「最も近い競合より約5倍速い」と主張しています。この倍率はxAI自身のベンチマークに基づくため、そのまま採用するのではなく自分のワークロードで測定してください。

ただし、方向性としてはGrok Voiceが低レイテンシ寄りです。Grokの最初の音声出力までの時間は1秒を大きく下回り、GPT-Realtime-2は推論レベルに応じておおむね800ms〜1500msの範囲に収まります。

実装時は、最低限以下を計測します。

- WebSocket接続開始時刻
- ユーザー音声送信完了時刻
- 最初の音声チャンク受信時刻
- 応答完了時刻
- 推論レベル
- 使用トークン数

電話やライブ会話では、600msと1200msの差が体感品質に直結します。ユーザーが「自然に会話できる」と感じるか、「ボットが考え込んでいる」と感じるかを分ける要素です。

推奨: 消費者向け音声アプリ、音声チャット、リアルタイム応答が重要なUXでは、まずGrok Voiceを検証してください。

価格設定は課金単位から比較する

両者は課金の形が異なるため、単純なモデル単価だけでは比較できません。

GPT-Realtime-2

GPT-Realtime-2は音声をトークンとして課金します。

音声入力:  $32 / 1M audio tokens
音声出力:  $64 / 1M audio tokens
テキスト:  $4 / $24 / 1M tokens

1秒の音声は約50トークンです。均衡の取れたターン制の5分間会話では、約30,000トークン、つまり音声I/Oで約$1.50を消費します。安定したシステムプロンプトでは、キャッシュ入力によりコストを下げられます。

Grok Voice

Grok Voiceは、xAIコンソール上ではTTS、STT、音声エージェント、カスタム音声に対して分単位または音声トークン単位の課金がありません。課金対象はGrok 4.3の推論です。

推論入力: $1.25 / 1M tokens
推論出力: $2.50 / 1M tokens

同じ5分間通話では、推論トークンは音声トークンより約1桁少なくなりやすいため、$0.10未満に収まる可能性があります。

推奨: 1日あたり10,000分以上の大量利用を想定する場合は、Grok Voiceの単位経済を先に検証してください。営業電話や規制対象サポートなど少量・高リスクのフローでは、価格差より推論品質を優先します。

Grok 4.3の価格については「Grok 4.3 APIの使い方」、OpenAIの価格については「GPT-5.5の価格設定」も参照してください。

推論の深さで選ぶならGPT-Realtime-2

GPT-Realtime-2は、OpenAIが「GPT-5クラス」と説明する音声対音声モデルです。Big Bench Audioでは96.6%、Audio MultiChallengeでは48.5%を記録しています。minimalからxhighまで5段階の推論レベルを指定できるため、リクエストごとにレイテンシと品質を調整できます。

実装では、ユースケースごとに推論レベルを固定せず、ルーティングするのが現実的です。

function selectReasoningLevel(intent) {
  if (intent === "faq" || intent === "simple_status_check") {
    return "low";
  }

  if (intent === "sales_call" || intent === "workflow_dispatch") {
    return "medium";
  }

  if (intent === "regulated_support" || intent === "multi_tool_reasoning") {
    return "high";
  }

  return "low";
}

Grok VoiceはGrok 4.3を基盤にしています。Grok 4.3はArtificial Analysisで知能指数53を達成し、146モデル中10位にランクインしました。エージェントタスクに強い一方、公開ベンチマーク上の音声対音声推論ではGPT-Realtime-2が優勢です。

推奨: エージェントが意図の明確化、多数のツール選択、長い会話履歴に基づく判断を行う場合は、GPT-Realtime-2を優先してください。FAQや定型スクリプト中心なら、Grok Voiceの低レイテンシが勝つ場面が多くなります。

音声カタログで選ぶ

Grokは28言語にわたる80以上のプリセット音声を提供します。音声エージェントではEve、Ara、Rex、Sal、Leoの5つのペルソナを使い、TTSではより広いライブラリから選択できます。さらに、音声クローニングにも対応しています。

GPT-Realtime-2は合計10音声です。Realtime API向けの新しいCedar、Marinに加え、alloy、ash、ballad、coral、echo、sage、shimmer、verseの8音声が再調整されています。音声数は少ないですが、一貫したオーディオスタックと予測しやすい抑揚制御が強みです。

推奨:

ブランド音声、地域アクセント、キャラクター音声が必要: Grok Voice
少数の高品質音声で一貫性を重視: GPT-Realtime-2

音声クローニングが必要ならGrok Voice

xAIのカスタム音声は、約1分のクリアなスピーチから音声をクローンし、2分以内にvoice_idを返します。同じvoice_idはTTSエンドポイントと音声エージェントの両方で使えます。

OpenAIは現在、Realtime APIで音声クローニングを公開していません。

推奨: カスタムブランド音声やキャラクター音声が要件に含まれるなら、Grok Voiceを選んでください。

画像入力が必要ならGPT-Realtime-2

GPT-Realtime-2は、テキスト、音声、画像を入力として受け取れます。ユーザーのターンにスクリーンショットや写真を添付し、エージェントに内容を説明させながら会話を継続できます。

代表的なユースケースは以下です。

- フィールドサポート
- 音声駆動QA
- アクセシビリティ向けナレーション
- 画面共有中のトラブルシューティング

Grok Voiceは現在、テキストと音声のみです。

推奨: エージェントがユーザーの画面や写真を理解する必要があるなら、GPT-Realtime-2を選んでください。

OpenAIのビジョンスタックについては「GPT-Image-2 APIの使い方」も参照できます。

SIPおよび電話統合

OpenAIのRealtime APIはネイティブSIPをサポートしています。SIPトランクをOpenAIのゲートウェイに向け、インバウンドコールでは次のようなWebSocketセッションを開きます。

wss://api.openai.com/v1/realtime?call_id={call_id}

この構成では、独自のSIPブリッジ層を省略できます。

一方、Grok Voiceは電話向けにμ-law出力をサポートしていますが、Twilio、Telnyx、PlivoなどのSIPプロバイダーとブリッジは自分で実装する必要があります。

ユーザー電話
  -> SIPプロバイダー
  -> 自前ブリッジ
  -> Grok Voice WebSocket
  -> 自前ブリッジ
  -> SIPプロバイダー
  -> ユーザー電話

推奨: コールセンターエージェントを短期間で構築し、SIP統合の実装量を減らしたい場合はGPT-Realtime-2が適しています。

MCPとツール利用

どちらのモデルも関数呼び出しをサポートします。違いはMCPの扱いです。

GPT-Realtime-2 はリモートMCPサーバーをネイティブにサポートします。サーバーURLとツール許可リストを設定すると、Realtime APIがMCPツール呼び出しを実行します。
Grok Voice は関数呼び出しをサポートし、組み込みのweb_searchツールを持ちます。ただし、MCPは第一級プリミティブとしては宣伝されていません。

ツール数が少ない場合は通常の関数呼び出しで十分です。

const tools = [
  {
    name: "get_order_status",
    description: "注文IDから配送状況を取得する",
    parameters: {
      type: "object",
      properties: {
        order_id: { type: "string" }
      },
      required: ["order_id"]
    }
  }
];

一方、銀行、保険、社内業務エージェントのように50以上のツールを横断する場合は、MCP統合が重要になります。音声エージェントのホットパスで自前サーバーを往復させずにツールをディスパッチできるためです。

MCPサーバー単体の検証については「ApidogでのMCPサーバーテスト」を参照してください。

ユースケース別の選び方

消費者向け音声アプリ、大量利用、低レイテンシ重視: Grok Voice
音声クローニングが必要: Grok Voice
10言語以上の多言語TTS: Grok Voice
スクリーンショットや写真を理解する音声エージェント: GPT-Realtime-2
SIPを使うコールセンター: GPT-Realtime-2
50以上のツールを持つ多段階推論エージェント: GPT-Realtime-2（MCP）
長文コンテキスト会話: GPT-Realtime-2。ただし1Mコンテキストを活用でき、音声トークンコストを許容できるならGrok 4.3も検討
最も安価な本番環境音声エージェント: コンソール版Grok Voice
ベンチマーク重視の高精度推論: xhigh推論を使うGPT-Realtime-2

導入前に両方をテストする手順

最初にどちらかを決め打ちするより、同じ会話フィクスチャを使って1週間比較する方が安全です。

1. フィクスチャ会話を作る

10ターン程度の会話を用意します。最低限、以下を含めます。

- 1つのツール呼び出し
- 1つの曖昧さ解消
- 1つの長い回答
- 実ユーザー音声の録音
- 中断または言い直し

2. WebSocketリクエストを一度だけ作る

ApidogでWebSocketリクエスト、JSONメッセージシーケンス、環境変数を設定します。

XAI_API_KEY
OPENAI_API_KEY

3. 実行ごとにURLを切り替える

Grok Voice:

wss://api.x.ai/v1/realtime?model=grok-voice-think-fast-1.0

GPT-Realtime-2:

wss://api.openai.com/v1/realtime?model=gpt-realtime-2

4. 同じ指標を記録する

比較では、主観評価だけでなく数値を残します。

- first_audio_latency_ms
- total_response_time_ms
- interruption_recovery_time_ms
- input_audio_tokens
- output_audio_tokens
- reasoning_tokens
- estimated_cost
- tool_call_success_rate
- human_rating

5. 結果をバージョン管理する

Apidogのコレクション形式はポータブルです。比較用のリクエスト、環境変数、レスポンス例をリポジトリに置けば、チーム内で再現できます。

FAQ

同じアプリで両方のモデルを使い、ランタイムでルーティングできますか？

できます。どちらも近いイベント形状で動作します。軽い意図分類器を前段に置き、カジュアルな用途はGrok Voice、複雑な推論やツール利用はGPT-Realtime-2へ送る構成が現実的です。

非英語の音声品質はどちらが良いですか？

Grokは言語カバレッジで優位です。80以上の音声とTTSで28言語を提供します。ただし、両方が対応する言語では実際の品質差が小さい場合もあるため、対象言語ごとに録音サンプルで評価してください。

GPT-Realtime-2は一般的なワークロードに対して高い価格を払う価値がありますか？

FAQ応答中心のカスタマーサポートなら、必ずしも価値があるとは限りません。CRMを読み込み、複数ツールをディスパッチし、中断から回復しながら会話を継続する営業エージェントでは、推論品質の差に価値があります。

どちらかのモデルで有名人の実際の音声をクローニングできますか？

できません。どちらのベンダーも、音声クローニングは同意されたサンプルに限定しています。許可なく有名人をクローニングすることは、両プラットフォームの利用規約に違反します。

後から一方からもう一方へ移行するにはどうすればよいですか？

イベント名やsession.updateペイロードは異なりますが、会話の構造は近いです。主な作業は、セッション設定、イベントハンドラ、ツール呼び出し部分の差し替えです。Apidogでテスト用コレクションを作っておくと、移行時に比較しやすくなります。

まとめ

Grok VoiceとGPT-Realtime-2の間に、すべてのケースで正しい選択はありません。判断軸は、レイテンシ、価格、音声カタログ、推論の深さ、SIP・MCP・画像入力などの統合要件です。

低レイテンシの消費者向け音声アプリを作るなら、Grok Voiceを先に検証してください。画像を理解し、50個以上のツールを扱い、SIPブリッジなしで電話対応するマルチモーダル音声エージェントを作るなら、GPT-Realtime-2を選ぶ方が実装しやすくなります。

迷う場合は、ApidogでWebSocketテストを一度作り、同じ会話フィクスチャで両方を1週間測定してください。最終判断は、推測ではなくレイテンシ、成功率、コストのデータで行うべきです。

Grok Voiceを無料で使う方法: コンソール設定、声のクローン、リアルタイム音声エージェント

Akira — Fri, 08 May 2026 07:29:58 +0000

xAIはGrok 4.3のリリースに合わせてGrok Voiceを公開しました。開発者にとって重要なのは、xAI Consoleから音声機能を無料で試せる点です。TTS、STT、リアルタイムボイスエージェント、カスタムボイスクローンを使えます。課金対象になるのは、エージェントが推論時に消費するGrok 4.3の基盤トークンです。このガイドでは、APIキー取得、音声選択、WebSocket接続、TTS呼び出し、そしてApidogでの検証手順までを実装ベースで説明します。補足として、Grok 4.3 APIガイドとGroK Voice対GPT-Realtimeも参照できます。

今すぐApidogを試す

要約

Grok VoiceはxAI Console（console.x.ai）から無料で利用できます。TTS、STT、ボイスエージェント、カスタムボイスに対して、1分あたりまたはトークンあたりの音声課金はありません。
フラッグシップモデルはgrok-voice-think-fast-1.0です。最初の音声までの時間は1秒未満で、xAIは最も近い競合製品より約5倍高速と説明しています。
28言語で80以上のプリセット音声を利用できます。ボイスエージェント向けにはEve、Ara、Rex、Sal、Leoの5つの組み込みペルソナがあります。
約1分間の音声からカスタム音声をクローンできます。2分未満で利用可能なvoice_idが返されます。
WebSocketエンドポイントは次のとおりです。

wss://api.x.ai/v1/realtime?model=grok-voice-think-fast-1.0

TTS、STT、カスタムボイスは同じAPIサーフェスで扱えます。
WebSocketセッションの再生、比較、デバッグにはApidogを使うと効率的です。

Grok Voiceが無料で提供するもの

xAI ConsoleでAPIキーを発行すると、音声機能を追加料金なしで試せます。まずconsole.x.aiにサインインし、キーを作成します。

利用できる主な機能は次の4つです。

ボイスエージェント：リアルタイムの音声対話。ツール利用、サーバーサイド音声活動検出、ターンテーキングを扱えます。
テキスト読み上げ（TTS）：28言語、80以上のプリセット音声。MP3または電話向けμ-lawで出力できます。
音声認識（STT）：25入力言語のストリーミングおよびバッチ転写。単語レベルのタイムスタンプと話者分離を利用できます。
カスタムボイス：短い音声サンプルから声をクローンし、返されたvoice_idをTTSとボイスエージェントで再利用できます。

注意点は、ボイスエージェントが推論にGrok 4.3を使う場合、その基盤トークン使用量はコンソールクレジットの対象になることです。プロトタイプ検証には無料クレジットを使えますが、本番利用ではプラン確認が必要です。

ステップ1：コンソールキーを取得する

console.x.aiにアクセスし、Xアカウントでサインインします。API Keysページから、voiceとchatスコープを有効にしたキーを作成します。

ローカル開発では環境変数に設定します。

export XAI_API_KEY="xai-..."

ブラウザアプリやモバイルアプリなど、クライアントに親キーを置けない場合は、サーバー側で一時トークンを発行します。コンソール設定または/v1/realtime/sessionsエンドポイントを使い、短命なトークンをクライアントに渡します。

実装方針は次のとおりです。

サーバーでXAI_API_KEYを保持する。
クライアントがセッション開始を要求する。
サーバーが一時トークンを発行する。
クライアントは一時トークンでWebSocketに接続する。
親キーはサーバー外へ出さない。

ステップ2：音声を選択する

Grok Voiceでは、プリセット音声またはカスタム音声を使います。

プリセット音声を使う

ボイスエージェントには5つの名前付きペルソナがあります。

Eve：女性、エネルギッシュ。明るいサポートフロー向け。
Ara：女性、温かい。一般的なアシスタント向け。
Rex：男性、自信がある。セールススクリプト向け。
Sal：ニュートラル、滑らか。ナレーションや長文読み上げ向け。
Leo：男性、権威的。コンプライアンスやフォーマルな案内向け。

TTS APIでは、より大きなプリセットライブラリを使えます。28言語、80以上の音声をvoiceパラメーターで指定します。

カスタムボイスを作成する

単一話者による約1分間のきれいなWAVファイルを用意します。ノイズ、BGM、複数話者は避けます。

curl https://api.x.ai/v1/custom-voices \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -F "name=narrator-jane" \
  -F "language=en" \
  -F "audio=@sample.wav"

成功するとvoice_idが返ります。このIDはTTSとボイスエージェントの両方で使えます。

参照クリップの最大長は120秒ですが、長さよりも品質が重要です。静かな部屋で、一定の音量、単一話者、ワンテイクで録音してください。

ステップ3：WebSocket経由でGrokに話させる

ボイスエージェントはWebSocketセッションとして動作します。接続後にセッション設定を送り、入力音声を追加し、サーバーから返る音声イベントを処理します。

最小構成のNode.jsクライアントは次のようになります。

import WebSocket from "ws";

const ws = new WebSocket(
  "wss://api.x.ai/v1/realtime?model=grok-voice-think-fast-1.0",
  {
    headers: {
      Authorization: `Bearer ${process.env.XAI_API_KEY}`,
    },
  }
);

ws.on("open", () => {
  ws.send(JSON.stringify({
    type: "session.update",
    session: {
      voice: "ara",
      instructions: "You are a friendly support agent. Keep replies under two sentences.",
      input_audio_format: "pcm16",
      output_audio_format: "pcm16",
      turn_detection: {
        type: "server_vad",
      },
    },
  }));
});

ws.on("message", (raw) => {
  const event = JSON.parse(raw.toString());

  if (event.type === "response.audio.delta") {
    process.stdout.write(Buffer.from(event.delta, "base64"));
  }

  if (event.type === "response.audio.done") {
    console.error("response completed");
  }
});

ユーザー音声は、base64エンコードしたPCM16フレームをinput_audio_buffer.appendイベントで送信します。

概念的には次の流れです。

ws.send(JSON.stringify({
  type: "input_audio_buffer.append",
  audio: base64Pcm16Chunk,
}));

サーバーは主に次のイベントを返します。

response.audio.delta：音声チャンク
response.audio.done：音声応答の完了
response.function_call_arguments.done：ツール呼び出し引数の確定
error：エラー

ブラウザやデスクトップアプリでは24 kHz PCM16をデフォルトにすると扱いやすいです。電話システムにブリッジする場合はμ-lawを検討します。

ステップ4：ツール使用を追加する

ボイスエージェントは関数呼び出しをサポートしています。これにより、会話中に注文検索、予約確認、ユーザー情報取得などの社内APIを呼び出せます。

セッション設定でツールを宣言します。

ws.send(JSON.stringify({
  type: "session.update",
  session: {
    tools: [
      {
        type: "function",
        name: "lookup_order",
        description: "Look up the status of a customer order by order number.",
        parameters: {
          type: "object",
          properties: {
            order_id: {
              type: "string",
            },
          },
          required: ["order_id"],
        },
      },
    ],
  },
}));

モデルがツールを呼び出す場合、response.function_call_arguments.doneイベントを発行します。アプリ側では次の処理を行います。

イベントから関数名と引数を取り出す。
自分のAPIまたはDBを呼び出す。
結果をconversation.item.createで返す。
モデルが会話を再開し、音声で回答する。

ツール結果を返す例です。

ws.send(JSON.stringify({
  type: "conversation.item.create",
  item: {
    type: "function_call_output",
    call_id: event.call_id,
    output: JSON.stringify({
      status: "shipped",
      eta: "Friday",
    }),
  },
}));

組み込みのweb_searchツールも利用できます。独自の検索レイヤーを実装せずに、新しい情報を使って回答を補強したい場合に有効です。

ステップ5：エージェントなしでTTSを使用する

会話エージェントが不要で、アプリ内アナウンス、音声プロンプト、ポッドキャストイントロなどの読み上げだけが必要な場合は、RESTのTTSエンドポイントを使います。

curl https://api.x.ai/v1/tts \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-tts-1",
    "voice": "ara",
    "input": "Welcome back to your account. Your last login was Tuesday at 3pm.",
    "format": "mp3"
  }' \
  --output greeting.mp3

出力フォーマットは次のように使い分けます。

mp3：アプリ、Web、ナレーション向け
mulaw：8 kHz、電話回線向け

TTSエンドポイントは同期式です。WebSocketセッションを作成する必要はなく、レスポンスとして音声バイトが返ります。

ステップ6：Apidogで全フローをテストする

WebSocket APIはステートフルなため、ターミナルだけで検証するとイベントの追跡が難しくなります。Apidogを使うと、WebSocketメッセージを保存、再生、比較できます。

検証手順は次のとおりです。

新しいWebSocketリクエストを作成する。
URLに次を設定する。

wss://api.x.ai/v1/realtime?model=grok-voice-think-fast-1.0

環境変数にXAI_API_KEYを保存する。
Authorizationヘッダーを設定する。

Authorization: Bearer {{XAI_API_KEY}}

送信メッセージとしてsession.updateを保存する。
フィクスチャ音声をinput_audio_buffer.appendとして送る。
response.createを送信して応答を開始する。
返ってくるイベントをツリーで確認する。
音声、プロンプト、ツール定義を変えて再実行し、結果を比較する。

Apidogをダウンロードすれば、TTSとSTTのRESTリクエストも同じプロジェクトで管理できます。ステートフルAPIのテスト設計については、QAエンジニア向けのAPIテストツールも参考になります。

無料枠の制限

xAI Consoleでは音声機能自体に1分あたりまたはトークンあたりの料金はありません。ただし、開発時に意識すべき制限があります。

レート制限：悪用防止のため、各エンドポイントには1分あたりのリクエスト上限があります。開発やデモには十分ですが、本番負荷テストでは上限に注意してください。
カスタム音声クォータ：1アカウントが保持できるカスタム音声クローン数には上限があります。不要な音声を削除してスロットを空けられます。
推論トークン：ボイスエージェントがGrok 4.3で推論する場合、コンソールクレジットの対象になります。無料クレジットはプロトタイプ向けであり、本番では有料プランの確認が必要です。

レート制限に当たる場合は、リクエストのバッチ化、リトライ間隔の調整、有料ティアへの移行を検討します。APIの呼び出し形式は変わらず、主に上限が変わります。

音声を比較する

本番投入前に、同じテキストを複数の音声で読み上げて比較します。音声ごとにトーンの解釈が異なるため、短いテストセットを用意するとミスマッチを早く見つけられます。

最低限、次の3種類を試してください。

2文の挨拶
確認フレーズ（例：「承知いたしました、すべて設定済みです」）
数字、日付、コンマを含む長い文

さらに、同じプロンプトを次の3つの指示で読み上げると、イントネーションの差を確認できます。

落ち着いて
通常
緊急

Grokのプリセット音声は、ベンチマークした多くのTTSエンジンよりもこの変化を扱いやすいですが、本番前には必ずユースケースごとに聴取テストを行ってください。

FAQ

APIは本当に無料ですか？隠れた上限はありますか？

音声機能（TTS、STT、ボイスエージェント、カスタムボイス）には、コンソール上で1分あたりまたはトークンあたりの音声課金はありません。ただし、ボイスエージェントが使う基盤推論モデルはコンソールクレジットの対象です。無料クレジットはプロトタイピングには十分ですが、本番利用ではプラン確認が必要です。

X（Twitter）アカウントは必要ですか？

はい。xAI ConsoleへのサインインにはXアカウントを使用します。

ブラウザからGrok Voiceを使用できますか？

はい。一時トークンを使えば可能です。サーバー側で/v1/realtime/sessionsから短命なトークンを発行し、そのトークンをブラウザに渡してWebSocket接続します。親APIキーはサーバー外に出しません。

どのような音質を期待できますか？

TTS出力は高音質MP3または8 kHz μ-lawです。ボイスエージェントは内部で24 kHz PCM16を使用します。音質は主要な商用TTSエンジンと同等であり、レイテンシーが大きな差別化要因です。

電話回線で動作しますか？

はい。μ-law出力はSIPおよびPSTNブリッジで一般的なフォーマットです。ただし、SIPプロバイダーは別途必要です。xAIは現在、独自のSIPゲートウェイを提供していません。

他のツールと比較してクローン品質はどうですか？

クローン品質は、音声の長さより参照オーディオの品質に強く依存します。静かな部屋で録音したきれいな60秒のサンプルは、ノイズの多い120秒のサンプルより良い結果になりやすいです。生成されたvoice_idは、再クローンなしでTTSとボイスエージェントの両方に使えます。

Grok VoiceをゲームのAIキャラクターに使用できますか？

はい。TTSエンドポイントはランタイム生成に使えます。カスタムボイスを使えば、キャラクターごとに異なる声を持たせられます。長いセリフではレイテンシーに注意し、必要に応じてテキストをチャンク化して生成します。

まとめ

Grok Voiceは、リアルタイムボイスエージェントを試すための実装しやすい選択肢です。xAI Consoleでは音声機能自体に1分あたりの料金がなく、プリセット音声、TTS、STT、カスタムボイス、WebSocketベースの会話セッションを一通り検証できます。

最短の検証手順は次のとおりです。

xAI ConsoleでAPIキーを作る。
grok-voice-think-fast-1.0にWebSocket接続する。
session.updateで音声と指示を設定する。
サンプル音声を送って応答イベントを確認する。
Apidogでセッションを保存し、音声やプロンプトを変えて比較する。

Grok 4.3の推論APIと組み合わせる場合は、Grok 4.3 APIガイドを参照してください。OpenAIのスタックと比較したい場合は、Grok Voice vs GPT-Realtimeが参考になります。

GPT-Realtime-2とは？APIの使い方

Akira — Fri, 08 May 2026 07:23:57 +0000

OpenAIは2026年11月6日に新世代の音声モデルを発表しました。中心となるのは、GPT-5クラスの推論、128,000トークンのコンテキストウィンドウ、回答品質とレイテンシを調整できる推論エフォートを備えた音声対音声モデル「GPT-Realtime-2」です。既存のRealtime APIサーフェス上で動作するため、すでに gpt-realtime を使っている場合は、モデルIDの変更と一部フィールド追加で移行できます。

今すぐApidogを試す

この記事では、GPT-Realtime-2の変更点、料金、WebSocket/SIPでの呼び出し方法、そして毎回音声を録音し直さずにRealtimeセッションを再生・比較できるよう、Apidogを使ったテスト手順をまとめます。

OpenAIの2026年モデルライン全体を把握したい場合は、GPT-5.5とはを参照してください。マルチモーダルな兄弟モデルについては、GPT-Image-2 APIの使用方法も参考になります。

TL;DR

GPT-Realtime-2は、OpenAIの主力音声対音声モデルです。
GPT-5クラスの推論、128kコンテキスト、最大32k出力トークンを備えています。
音声料金は、入力100万トークンあたり $32、出力100万トークンあたり $64 です。キャッシュ済み入力は $0.40/100万トークンです。
新音声は Cedar と Marin。どちらもRealtime API専用です。
推論エフォートは minimal、low、medium、high、xhigh の5段階です。デフォルトはレイテンシ優先の low です。
WebSocketでは wss://api.openai.com/v1/realtime?model=gpt-realtime-2 に接続します。
SIPでは着信通話をRealtimeセッションに接続できます。
同時リリースとして、ライブ翻訳用の GPT-Realtime-Translate と、ストリーミングSTT用の GPT-Realtime-Whisper があります。
Apidogを使うと、WebSocketセッションのスクリプト化、フレームのキャプチャ、実行間の比較ができます。

GPT-Realtime-2とは？

GPT-Realtime-2は、音声を入力し、音声を出力するエンドツーエンドの音声対音声モデルです。

従来のように、

STT → LLM → TTS

という3段パイプラインを組むのではなく、モデルが以下を一度に処理します。

音声入力の理解
文字起こし相当の処理
推論
ツール選択
音声生成

gpt-realtime が置き換えた旧来のパイプラインを、GPT-Realtime-2ではより強力な推論コアで拡張しています。

GPT-Realtime-2は、入力としてテキスト、音声、画像を受け取り、出力としてテキストと音声を返します。今回の重要な追加点は画像入力です。

たとえば、ライブ会話中にユーザーがスクリーンショットを送信し、音声で「このエラーは何ですか？」と質問できます。モデルは画面内容を見たうえで、音声で回答を継続できます。

主な仕様は次のとおりです。

属性	値
モデルID	`gpt-realtime-2`
コンテキストウィンドウ	128,000トークン
最大出力	32,000トークン
入力モダリティ	テキスト、音声、画像
出力モダリティ	テキスト、音声
知識カットオフ	2024年9月30日
推論レベル	`minimal`, `low`, `medium`, `high`, `xhigh`
関数呼び出し	あり
リモートMCPサーバー	あり
画像入力	あり
SIP電話発信	あり

gpt-realtimeからの変更点

gpt-realtime-1.5 と比較すると、GPT-Realtime-2では音声理解と指示追従性が改善されています。

Big Bench Audio（音声インテリジェンス）: 81.4% → 96.6%
Audio MultiChallenge（指示の追従性）: 34.7% → 48.5%

これらのスコアは high および xhigh 推論で記録されています。本番環境のデフォルトはレイテンシ優先の low なので、実運用では品質と応答速度のバランスを見ながら調整します。

実装上、特に重要な変更は次の4つです。

1. プレアンブル

モデルは、本回答の前に短いフィラーを発話できます。

例:

確認します。
少しお待ちください。
それでは見てみます。

これにより、ツール実行や推論中の無音時間をユーザーに感じさせにくくなります。

2. 音声ナレーション付きの並列ツール呼び出し

モデルは複数の関数を並列に呼び出しながら、処理状況を音声で説明できます。

例:

残高と直近の取引を確認しています。

これにより、ツール実行中に2〜3秒沈黙するような体験を避けやすくなります。

3. 回復性能の向上

曖昧な発話、途中で遮られた発話、部分的に失敗したターンを、会話全体をリセットせずに処理しやすくなっています。

4. ドメインごとのトーン制御

長いセッションでも、専門用語や話し方の一貫性を保ちやすくなっています。また、会話中に「もっとゆっくり」「フォーマルに」「カジュアルに」といった表現調整を要求できます。

コンテキストは32kから128kトークンに拡張されました。銀行業務、カスタマーサポート、チュータリングなど、長時間の音声セッションを扱うユースケースで特に有効です。

料金

GPT-Realtime-2はトークン単位で課金されます。テキスト、音声、画像で料金が異なります。

トークンタイプ	入力	キャッシュ済み入力	出力
テキスト	$4.00 / 100万	$0.40 / 100万	$24.00 / 100万
音声	$32.00 / 100万	$0.40 / 100万	$64.00 / 100万
画像	$5.00 / 100万	$0.50 / 100万	該当なし

キャッシュ済み入力は、繰り返し使うコンテキストのコストを大きく下げます。安定したシステムプロンプト、共通FAQ、再利用されるドキュメントを持つエージェントでは、キャッシュを活用する設計にしておくべきです。

OpenAIラインの他モデルとの比較は、GPT-5.5の料金を参照してください。

コンパニオンモデルは分単位で課金されます。

GPT-Realtime-Translate: $0.034/分。70の入力言語と13の出力言語に対応。
GPT-Realtime-Whisper: $0.017/分。ライブキャプションや連続文字起こし向けのストリーミング音声認識。

選び方はシンプルです。

やりたいこと	選ぶモデル
音声で会話し、推論し、ツールも使う	GPT-Realtime-2
ライブ多言語通訳	GPT-Realtime-Translate
文字起こしのみ	GPT-Realtime-Whisper

エンドポイントと認証

GPT-Realtime-2は複数のAPIサーフェスで公開されています。

POST https://api.openai.com/v1/chat/completions
POST https://api.openai.com/v1/responses
WSS  wss://api.openai.com/v1/realtime?model=gpt-realtime-2
WSS  wss://api.openai.com/v1/realtime?call_id={call_id}   # SIP用
POST https://api.openai.com/v1/realtime/translations
POST https://api.openai.com/v1/realtime/transcription_sessions

音声エージェントを実装する場合は、通常WebSocketエンドポイントを使います。

認証ヘッダーは次のとおりです。

Authorization: Bearer $OPENAI_API_KEY
OpenAI-Beta: realtime=v1

まず環境変数を設定します。

export OPENAI_API_KEY="sk-proj-..."

WebSocket経由で接続する

最小構成のNode.jsクライアントは次のようになります。

import WebSocket from "ws";

const ws = new WebSocket(
  "wss://api.openai.com/v1/realtime?model=gpt-realtime-2",
  {
    headers: {
      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
      "OpenAI-Beta": "realtime=v1",
    },
  }
);

ws.on("open", () => {
  ws.send(JSON.stringify({
    type: "session.update",
    session: {
      voice: "cedar",
      instructions: "あなたはフィンテックアプリのフレンドリーなサポートエージェントです。",
      input_audio_format: "pcm16",
      output_audio_format: "pcm16",
      turn_detection: { type: "server_vad" },
      reasoning: { effort: "low" },
    },
  }));
});

ws.on("message", (raw) => {
  const event = JSON.parse(raw.toString());

  if (event.type === "response.audio.delta") {
    // base64 PCM16オーディオチャンク。
    // 実運用ではスピーカー、ブラウザ、または音声ストリームへ渡す。
    process.stdout.write(Buffer.from(event.delta, "base64"));
  }
});

Realtime APIはイベント駆動です。

基本フローは次のようになります。

WebSocketに接続する
session.update で音声、プロンプト、音声フォーマット、VAD、推論エフォートを設定する
ユーザー音声を input_audio_buffer.append で送る
必要に応じて response.create を送る
サーバーから response.audio.delta を受け取り、再生する

24 kHzのPCM16は安全なデフォルトです。電話システムにブリッジする場合は、G.711 mu-lawおよびA-lawも重要です。

Pythonで実装する場合、openai SDK >= 2.1.0 の realtime クライアントで同じイベント名を扱えます。RealtimeサーフェスとResponses APIを比較したい場合は、GPT-5.5 APIの使用方法を参照してください。

音声

このリリースでは2つの新しい音声が追加されています。

Cedar: 暖かい中音域の男性声。一般的なエージェントのデフォルトに向いています。
Marin: 明るくクリアな女性声。翻訳やアナウンスに向いています。

どちらもRealtime API専用です。

既存の8つの音声も引き続き利用できます。

alloy
ash
ballad
coral
echo
sage
shimmer
verse

セッション中に音声を切り替える場合は、voice を含む session.update を再送します。

ws.send(JSON.stringify({
  type: "session.update",
  session: {
    voice: "marin",
  },
}));

画像入力

GPT-Realtime-2では、任意のユーザーターンに画像を添付できます。

たとえば、スクリーンショットを送って「このエラーは何を意味しますか？」と聞く場合は次のようにします。

ws.send(JSON.stringify({
  type: "conversation.item.create",
  item: {
    type: "message",
    role: "user",
    content: [
      {
        type: "input_image",
        image_url: "https://example.com/screenshot.png",
      },
      {
        type: "input_text",
        text: "このエラーは何を意味しますか？",
      },
    ],
  },
}));

ws.send(JSON.stringify({ type: "response.create" }));

実装しやすいユースケースは次のとおりです。

音声駆動QA: テスターが壊れたUIのスクリーンショットを送り、エージェントが問題を音声で説明する。
フィールドサポート: 技術者が配線盤の写真を共有し、エージェントが診断手順を案内する。
アクセシビリティ: サポート通話中に、ユーザー画面をスクリーンリーダーのように説明する。

画像モデル全体については、GPT-Image-2 APIの使用方法を参照してください。

関数呼び出しとMCP

GPT-Realtime-2は、標準の関数ツールとリモートMCPサーバーの両方を同じセッションで扱えます。

標準の関数呼び出しは、チャット補完と同じ考え方です。

session.update でツールを宣言する
モデルが response.function_call_arguments.delta を発行する
クライアント側で関数を実行する
conversation.item.create で function_call_output を返す

GPT-Realtime-2では、複数の関数を並列に呼び出しながら、音声で進行状況を説明できます。

リモートMCPサーバーを使う場合は、MCP URLと許可するツールをセッションに設定します。

ws.send(JSON.stringify({
  type: "session.update",
  session: {
    tools: [{
      type: "mcp",
      server_url: "https://mcp.example.com/sse",
      allowed_tools: [
        "lookup_account",
        "list_transactions",
      ],
    }],
  },
}));

MCPを使うと、クライアント側で関数呼び出しのイベントループをすべて処理する必要がなくなります。音声エージェントが多数のツールを持つ場合でも、応答性を保ちやすくなります。

音声エージェントに組み込む前にMCPサーバーを検証する場合は、ApidogでのMCPサーバーテストの手順が参考になります。

SIP電話発信

GPT-Realtime-2は、実際の電話通話にも接続できます。

SIPトランクをOpenAIのSIPゲートウェイに向けると、着信通話に対して次のWebSocketセッションを開きます。

wss://api.openai.com/v1/realtime?call_id={call_id}

モデルはG.711 mu-lawおよびA-lawを直接受け付けるため、ブリッジ側で必ずしもトランスコードする必要はありません。

これは、ブラウザデモではなくコールセンター向け音声エージェントを構築する場合に重要です。電話エージェントの多くは、実際にはツールディスパッチが中心です。並列ツール呼び出しやMCPと組み合わせることで、通話中に必要なデータ取得と回答をまとめて実装できます。

推論レベル

推論レベルは、レイテンシと回答品質のバランスを調整する設定です。

レベル	ユースケース	おおよそのレイテンシコスト
`minimal`	単一ターンのYes/No回答	なし
`low`	デフォルト。日常的なサポートとチャット	小
`medium`	曖昧さの解消、複雑なツールディスパッチ	中
`high`	多段階推論、音声によるコードレビュー	高
`xhigh`	ベンチマーク、難しい分析質問	最高

本番導入時は、まず low から始めるのが現実的です。

reasoning: { effort: "low" }

品質不足を計測できた場合のみ、medium、high、xhigh に上げます。high 以上では、ユーザーが通話中に待ち時間を感じる可能性があります。

ApidogでRealtime APIをテストする

WebSocket APIは状態を持つため、ターミナルだけでデバッグすると再現性が下がります。Apidogを使うと、Realtimeセッションを保存・再生・比較できます。

実装時の基本手順は次のとおりです。

新しいWebSocketリクエストを作成する
URLに wss://api.openai.com/v1/realtime?model=gpt-realtime-2 を設定する
認証にBearerトークンを設定する
OpenAI-Beta: realtime=v1 ヘッダーを追加する
session.update、input_audio_buffer.append、response.create のJSONメッセージを順番に登録する
単一接続に対して再生する
サーバーイベントをツリーで確認する
推論エフォートや音声を変えて、実行結果を比較する

Apidogをダウンロードしたら、HTTP APIと同じように環境変数を管理できます。

例:

OPENAI_API_KEY=sk-proj-...
voice=cedar
reasoning_effort=low

比較対象として別の高速マルチモーダルモデルも確認したい場合は、Gemini 3 Flash Preview APIの使用方法を参照してください。

FAQ

どのモデルIDを渡せばよいですか？

gpt-realtime-2 です。

ロールバックが必要な場合、以前のモデルは gpt-realtime として利用可能です。軽量版として gpt-realtime-2-mini もライブです。

出力音声が再生されている間に入力音声をストリーミングできますか？

はい。Realtime APIはデフォルトでサーバーサイドの音声活動検出（VAD）を使います。

ユーザーが話し始めると、モデルは発話を停止できます。VADを無効にして、クライアント側で会話境界を制御することもできます。

128kのコンテキストには音声トークンも含まれますか？

はい。音声もトークン化されます。

フォーマットにもよりますが、1秒の音声は約50トークンです。長いサポート通話は、長いテキストチャットよりも早くコンテキストを消費する可能性があります。

ファインチューニングはサポートされていますか？

まだです。

モデルカードによると、GPT-Realtime-2はまだファインチューニング、予測出力、チャット補完におけるテキストストリーミングをサポートしていません。Realtimeエンドポイントは本質的に音声をストリーミングします。

TTSを接続したGPT-5.5と何が違いますか？

GPT-Realtime-2は、音声を直接理解するエンドツーエンドの音声モデルです。

TTS付きのテキストモデルでは、ユーザーのトーン、ためらい、強調などを扱いにくくなります。ユーザーが「何を言ったか」だけでなく「どう話したか」に反応する必要があるなら、GPT-Realtime-2が適しています。

純粋なテキスト推論には、GPT-5.5 APIの使用方法を参照してください。

どのレート制限が適用されますか？

ティア1は毎分40,000トークンから始まり、ティア5では15M TPMまでスケールします。レート制限はモデルごとなので、既存のGPT-5クォータは引き継がれません。

まとめ

GPT-Realtime-2は、音声エージェントとテキストエージェントの差を縮めるモデルです。128kコンテキスト、GPT-5クラスの推論、画像入力、ネイティブMCP、SIPサポートにより、電話を受け、スクリーンショットを見て、リモートツールを呼び出し、会話の失敗から回復する音声エージェントをWebSocketベースで構築できます。

本番導入では、まず次の流れがおすすめです。

ApidogでWebSocketセッションをスクリプト化する
session.update の設定を固定する
ツールリストを確定する
low 推論から開始する
品質差を計測できた場合だけ推論レベルを上げる

音声トークンの料金は入力 $32/100万、出力 $64/100万です。安定したシステムプロンプトや再利用コンテキストがある場合は、キャッシュ済み入力を活用してコストを抑える設計にしておきましょう。

2026年おすすめローカルLLM

Akira — Fri, 08 May 2026 06:39:30 +0000

2026年にローカルLLMを選ぶときは、「どのモデルが最強か」ではなく、VRAM、レイテンシー、用途（コーディング、推論、多言語、ビジョン、ツール呼び出し）から逆算するのが実装上の近道です。この記事では、ローカルで動かす価値のあるLLMを選び、Ollama / vLLM / LM StudioでOpenAI互換APIとして公開し、Apidogでテスト・リプレイ・モックする手順まで整理します。

今すぐApidogを試す

要点

2026年における「最高の」ローカルLLMは、VRAM予算、レイテンシー目標、ユースケースによって変わります。
24GB GPUでは、Qwen 3.6 32BとDeepSeek V4 Flashが有力なオールラウンダーです。
8GB以下のGPUでは、Gemma 4 9BとLlama 5.1 8Bが扱いやすい選択肢です。
推論またはコーディング重視なら、量子化されたDeepSeek V4 ProまたはGLM 5が候補になります。
OllamaまたはLM Studioを使うと、OpenAI互換のHTTPエンドポイントとして公開できます。
公開したローカルエンドポイントは、ホスト型APIと同じようにApidogでテストできます。
Apidogを使うと、ホスト型LLMのトークン予算を消費せずに、ローカルモデルのトラフィックをモック、リプレイ、ベンチマークできます。

すでにDeepSeek V4に絞って検証している場合は、DeepSeek V4ローカルインストールガイドとDeepSeek V4概要も参考になります。

2026年にローカルLLMが再び重要になる理由

数年前まで、ローカルLLMは「品質が低いが安い」選択肢でした。現在は状況が変わっています。オープンウェイトモデルはホスト型GPT-4クラスのシステムに近づき、推論、コーディング、分類、抽出、ツール呼び出しでは実用上十分な精度を出せるケースが増えています。

もう一つの変化はハードウェアです。24GBのコンシューマーGPUで32Bクラスの4ビット量子化モデルを実行でき、64GB以上のユニファイドメモリを搭載したMacでも実用的なローカル推論が可能です。

ローカルLLMを採用する主な理由は次のとおりです。

データを外部APIに送信したくない
推論コストを固定化したい
ベンダーロックインを避けたい
CIや開発環境で決定論的にLLM APIをテストしたい
モデルのバージョンや量子化方式を自分たちで制御したい

ただし、モデルが動くだけでは不十分です。本番アプリケーションでは、ローカルモデルもHTTP APIとして扱い、リクエスト形式、レスポンス形式、ツール呼び出し、ストリーミング、エラー時の挙動を検証する必要があります。

モデル選定の基準

このリストは、単純なリーダーボード順位ではなく、実装しやすさを重視して選んでいます。

確認した観点は次のとおりです。

商用利用を許可するライセンスまたはコミュニティライセンスであること
2026年時点でメンテナンスが継続していること
Ollama、vLLM、LM StudioのいずれかでOpenAI互換APIとして公開できること
推論、コード、多言語、ビジョン、長文コンテキスト、ツール呼び出しのいずれかに強みがあること
一般的な開発者が入手できるハードウェアで実行可能な構成があること

比較には、LMSYSアリーナとHugging Face Open LLM Leaderboardも参照しています。

2026年に実行する価値のあるローカルLLM

1. DeepSeek V4 Pro

DeepSeek V4 Proは、DeepSeek V4リリースのフラッグシップです。Hugging Faceでは4ビットGGUFやAWQとして入手可能です。

完全なモデルは大規模で、ローカル実行には高いメモリ要件があります。Q4量子化でも、80GB H100のペア、または192GBユニファイドメモリ級のMac Studio M3 Ultraのような環境が必要になります。

多くのチームにとって、V4 Proを直接ローカル運用するのは現実的ではありません。ただし、蒸留モデルや小型バリアントが推論能力を引き継いでいるため、V4系を評価する価値はあります。

完全なモデルをOpenAI互換エンドポイント経由で使う方法は、DeepSeek V4 APIの使用方法で解説されています。

向いている用途

推論重視のエージェント
大規模なローカル検証環境
Mac Studio M3 Ultraまたは複数GPU環境を持つチーム

必要ハードウェアの目安

192GBユニファイドメモリ
または80GB GPU 2基

入手先

Hugging FaceのDeepSeek V4 Pro GGUF

2. DeepSeek V4 Flash

DeepSeek V4 Flashは、より現実的にローカル運用しやすいV4バリアントです。合計284B、アクティブ13Bの構成で、4ビット量子化では24GB VRAMに収まります。

多くのチームが実際に試すなら、まずV4 Flashから始めるのが現実的です。推論、RAG、コーディング補助、社内エージェントの検証に使いやすいモデルです。

Ollamaでのセットアップは、DeepSeek V4ローカルインストールガイドで詳しく説明されています。

向いている用途

汎用ローカルエージェント
コーディングアシスタント
RAGの回答生成
推論を含む業務ワークフロー

必要ハードウェアの目安

Q4: 24GB VRAM
Q3: 16GB VRAMでも実行可能だが品質低下あり

実行例

ollama pull deepseek-v4-flash
ollama serve

入手先

ollama pull deepseek-v4-flash
Hugging Face GGUF

3. Qwen 3.6

Qwen 3.6は、多言語、構造化出力、ツール呼び出しのバランスが良いモデルです。特に中国語、日本語、韓国語、アラビア語など、英語以外を扱うプロダクトでは有力な候補になります。

Qwen 3.6 32Bは、Q4量子化で24GB VRAMに収まり、ツール呼び出し形式もOpenAI互換のワークフローに合わせやすいです。

向いている用途

多言語プロダクト
日本語を含むチャットボット
構造化出力
ツール呼び出し
コストと品質のバランスが必要なAPI

必要ハードウェアの目安

Q4: 24GB VRAM

実行例

ollama pull qwen3.6:32b
ollama serve

入手先

ollama pull qwen3.6:32b
Hugging FaceのQwen 3.6

4. GLM 5.1

GLM 5.1は、ツール呼び出し、構造化抽出、JSONモードのようなワークロードに向いています。

GLM 5.1は、オープンモデルの中でもツール呼び出し系のベンチマークで強く、エージェントワークフローやスキーマに沿った出力を必要とする処理で選択肢になります。

向いている用途

ツール呼び出しエージェント
構造化データ抽出
JSONスキーマに沿った応答生成
分類タスク
業務フローの自動化

ローカルLLMをOpenAI互換APIとして公開する

モデルを選んだら、次はアプリケーションから呼び出せるHTTP APIとして公開します。

2026年時点で実装しやすい選択肢は次の3つです。

Ollama

最も簡単に始められる方法です。

ollama serve

Ollamaは次のURLでOpenAI互換エンドポイントを公開します。

http://localhost:11434/v1

既存コードがOpenAI SDKを使っている場合、base_urlを差し替えるだけでローカルモデルを呼び出せます。

vLLM

本番環境や高スループット用途ではvLLMが候補になります。

vLLMは連続バッチ処理をサポートし、低レイテンシーと高スループットが必要なAPIサーバーに向いています。

一般的には次のようなOpenAI互換エンドポイントを公開します。

http://localhost:8000/v1

LM Studio

LM StudioはGUIでモデルを管理したい個人開発者に向いています。

設定画面でローカルサーバーを有効化すると、HTTPエンドポイントとしてモデルを呼び出せます。

このパターンについては、DeepSeek V4を無料で使う方法でも説明されています。

PythonからローカルLLMを呼び出す

OllamaをOpenAI互換APIとして使う最小構成です。

from openai import OpenAI

client = OpenAI(
    api_key="ollama",  # Ollamaでは任意の文字列でよい
    base_url="http://localhost:11434/v1",
)

resp = client.chat.completions.create(
    model="qwen3.6:32b",
    messages=[
        {
            "role": "user",
            "content": "MoEと高密度モデルの3つの違いを要約してください。"
        }
    ],
    temperature=0.3,
)

print(resp.choices[0].message.content)

モデルを差し替える場合は、modelだけを変更します。

model="deepseek-v4-flash"

または、小型モデルを使う場合は次のように変更します。

model="llama5.1:8b"

アプリケーション側では、次の2つを環境変数にしておくと切り替えが簡単です。

LLM_BASE_URL=http://localhost:11434/v1
LLM_MODEL=qwen3.6:32b

ApidogでローカルLLMをテストする

ローカルLLMで重要なのは、モデルの品質だけではありません。リクエストとレスポンスを再現可能に検証できることです。

OllamaやvLLMが落ちた場合、原因調査は自分たちの責任になります。GPUのOOM、ドライバークラッシュ、モデルロード失敗、ストリーミング中断、ツール呼び出し形式の差分などを確認する必要があります。

curlだけで運用すると、次の作業が面倒になります。

同じプロンプトを複数モデルに投げる
temperatureやmax_tokensを変えて再実行する
ストリーミングレスポンスを比較する
CI用にレスポンスをモックする
チームでリクエスト仕様を共有する

Apidogを使うと、OllamaやvLLMのエンドポイントを通常のAPIとして扱えます。

1. リクエストコレクションを作成する

Apidogで次のようなPOSTリクエストを作成します。

POST http://localhost:11434/v1/chat/completions
Content-Type: application/json
Authorization: Bearer ollama

リクエストボディ例:

{
  "model": "qwen3.6:32b",
  "messages": [
    {
      "role": "system",
      "content": "あなたは簡潔に回答する技術アシスタントです。"
    },
    {
      "role": "user",
      "content": "MoEモデルのメリットを3つ挙げてください。"
    }
  ],
  "temperature": 0.3,
  "max_tokens": 512
}

モデルごとに次のパラメータを保存しておくと、差し替え時の検証が楽になります。

model
messages
temperature
max_tokens
stream
tools
tool_choice

2. モデル間で同じプロンプトをリプレイする

同じリクエストを次のモデルに対して実行します。

{
  "model": "qwen3.6:32b"
}

{
  "model": "deepseek-v4-flash"
}

{
  "model": "llama5.1:8b"
}

Apidog上でレスポンスを比較すれば、モデル変更による出力の差分を確認できます。

特に確認すべき点は次のとおりです。

JSONが壊れていないか
ツール呼び出し形式が期待どおりか
回答が長すぎないか
日本語の品質が落ちていないか
エラー時のレスポンス形式がアプリ側で処理できるか

3. CI用にエンドポイントをモックする

CIで毎回ローカルLLMを起動すると、テストが不安定になります。

理由は次のとおりです。

GPUがCI環境にない
モデルロードに時間がかかる
OOMで失敗する
ストリーミング結果が毎回微妙に変わる

ApidogでローカルLLMエンドポイントをモックすれば、アプリケーション側のテストはGPUに依存しません。

たとえば、次のようなレスポンスを固定できます。

{
  "id": "chatcmpl-local-mock",
  "object": "chat.completion",
  "created": 1760000000,
  "model": "qwen3.6:32b",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "MoEモデルのメリットは、計算効率、スケーラビリティ、専門化された推論能力です。"
      },
      "finish_reason": "stop"
    }
  ]
}

4. スループットをベンチマークする

量子化方式を変えた場合は、必ずベンチマークします。

比較対象の例:

Q3
Q4
Q5
8Bモデル
32Bモデル
Ollama
vLLM

見るべき指標は次のとおりです。

初回トークンまでの時間
総レイテンシー
1秒あたりのトークン数
エラー率
長文コンテキスト時のVRAM使用量

5. チーム向けにAPI仕様を文書化する

ローカルLLMも本番APIと同じように仕様化します。

ApidogプロジェクトからOpenAPI 3.1をエクスポートすれば、チームメイトは次の点をすぐ確認できます。

どのURLを呼ぶか
どのモデル名を使うか
必須パラメータは何か
ストリーミングの有無
エラー時のレスポンス形式
ツール呼び出しのJSONスキーマ

同じワークフローは、Postmanの代替としてのApidogでも説明されています。

ローカルLLM実装時のよくある間違い

GPUに収まる最大モデルを選ぶ

最大モデルが常に最良とは限りません。

たとえば、Q3の32Bモデルより、Q5の14Bモデルの方が安定して良い結果を出す場合があります。4ビットを超える領域では、パラメータ数だけでなく量子化品質も重要です。

コンテキスト長のVRAM消費を忘れる

長いコンテキストを使うと、KVキャッシュがVRAMを消費します。

32Bモデルで32Kトークンのコンテキストを使う場合、Q4でも追加で数GBのVRAMが必要になります。モデルがロードできても、長文入力でOOMになることがあります。

出所不明のファインチューンを使う

Hugging Face上の任意のファインチューンをそのまま本番に入れるのは避けるべきです。

最低限、次を確認します。

元モデルのカード
ライセンス
作者の信頼性
ダウンロード数
変更内容
セーフティやシステムプロンプトへの影響

悪意あるファインチューンは現実的なリスクです。

モックレイヤーを用意しない

ローカルモデルは落ちます。

GPUドライバーがクラッシュする
プロセスがOOMで終了する
モデルロードに失敗する
GPUがサーマルスロットリングする
ストリーミングが途中で切れる

CIや単体テストが実モデルに直接依存すると不安定になります。Apidogでエンドポイントをモックすれば、テストをハードウェアの状態から切り離せます。

ツール呼び出し形式の差を無視する

Llama 5.1、Qwen 3.6、DeepSeek V4はいずれもツール呼び出しをサポートしますが、出力されるJSON形式には差があります。

本番でモデルを差し替える前に、次を必ず検証してください。

tool_callsの構造
argumentsが文字列かJSONオブジェクトか
スキーマ違反時の挙動
複数ツール呼び出し時の順序
ストリーミング時の差分出力

実世界でのユースケース

カスタマーサポートエージェント

カスタマーサポートエージェントを運用するスタートアップは、単一の4090でGPT-5.5からQwen 3.6 32Bに移行しました。

レイテンシーは800ミリ秒未満に保たれ、月間の推論費用は9,400ドルから0ドルに減少しました。CIではApidogモックを使い、LLMレスポンスに依存するテストを安定化しています。

音声アシスタント

音声アシスタントを開発する個人開発者は、16GBのユニファイドメモリを搭載したM2 ProでGemma 4 9Bを実行しています。

マルチトークン予測のドラフターにより、1秒あたり60トークンの生成が可能で、会話体験を損なわない速度を実現しています。

フィンテックの要約バッチ

フィンテックの研究チームは、規制当局への提出書類を夜間にバッチ要約するため、2台の4090でDeepSeek V4 Flashを実行しています。

要約あたりのコストは、電気代とサーバーメンテナンス時間に限定されます。

実装手順のまとめ

ローカルLLMを導入する場合は、次の順番で進めると失敗しにくいです。

1. ハードウェアからモデルを決める

目安:

ハードウェア	候補
8GB以下	Gemma 4 9B、Llama 5.1 8B
16GB	小型モデル、Q3量子化モデル
24GB	Qwen 3.6 32B、DeepSeek V4 Flash
64GB以上	大きめのMoEモデル
192GB級	DeepSeek V4 Pro級の検証

2. Ollamaで起動する

ollama pull qwen3.6:32b
ollama serve

3. OpenAI SDKから呼び出す

from openai import OpenAI

client = OpenAI(
    api_key="local",
    base_url="http://localhost:11434/v1",
)

response = client.chat.completions.create(
    model="qwen3.6:32b",
    messages=[
        {"role": "user", "content": "このAPIレスポンスを要約してください。"}
    ],
)

print(response.choices[0].message.content)

4. Apidogで同じリクエストを保存する

Apidogに次のエンドポイントを登録します。

POST http://localhost:11434/v1/chat/completions

モデルごとのリクエストを保存し、変更時にリプレイします。

5. CIではモックを使う

本番と同じレスポンス形式をApidogでモックし、GPUなしでもテストが通るようにします。

6. 本番切り替え前に比較する

次を比較します。

ホスト型API
Qwen
DeepSeek
Llama
Gemma
GLM

同じプロンプトを投げ、レスポンス差分、レイテンシー、失敗率を確認します。

まとめ

2026年のローカルLLM選びでは、モデル名だけでなく、VRAM、レイテンシー、量子化方式、ツール呼び出し、テスト方法まで含めて設計する必要があります。

実用上の選び方は次のとおりです。

24GB GPUなら、Qwen 3.6 32BまたはDeepSeek V4 Flash
小型ハードウェアなら、Llama 5.1 8BまたはGemma 4 9B
ツール呼び出し中心なら、GLM 5系
推論重視で大規模環境があるなら、DeepSeek V4 Pro
APIとして運用するなら、Ollama / vLLM / LM StudioでOpenAI互換エンドポイントにする
リクエストの保存、リプレイ、モック、ベンチマークにはApidogを使う

次のステップはシンプルです。

ollama pull qwen3.6:32b
ollama serve

その後、Apidogを次のURLに向けます。

http://localhost:11434/v1

これで、ホスト型LLMと同じ形式でローカルLLMをテスト、リプレイ、ベンチマークできます。

よくある質問

2026年に24GB GPUに最適なローカルLLMは何ですか？

多くのワークロードでは、Q4のQwen 3.6 32BまたはQ4のDeepSeek V4 Flashです。

多言語やツール呼び出しが多い場合はQwen、推論やコーディングを重視する場合はDeepSeek V4 Flashを検討してください。DeepSeek V4のローカル実行については、DeepSeek V4ローカルガイドも参考になります。

MacでローカルLLMを実行できますか？

はい。16GB以上のユニファイドメモリを搭載したAppleシリコンでは、Llama 5.1 8BやGemma 4 9Bを実行できます。

192GBのM3 Ultra級であれば、Q4のDeepSeek V4 Proのような大規模モデルも検証対象になります。OllamaまたはLM Studioを使うと始めやすいです。

OpenAIをテストするのと同じ方法でローカルLLMをテストするには？

OpenAI互換クライアントとApidogプロジェクトのbase_urlをローカルサービスURLに向けます。

Ollamaの場合:

http://localhost:11434/v1

vLLMの場合:

http://localhost:8000/v1

リクエスト形式はOpenAI Chat Completionsと同じで、ベースURLとモデル名だけを変更します。

ローカルLLMの品質は本当にホスト型と同等ですか？

推論、コーディング、分類、抽出、ツール呼び出しでは、上位のオープンモデルがホスト型モデルに近い品質を出すケースがあります。

一方で、ビジョン、長文コンテキストのドキュメントQA、クリエイティブライティングでは、ホスト型モデルが依然として有利な場面があります。

コストはどうなりますか？

4090 GPUでDeepSeek V4 Flashを動かす場合、主な変動費は電気代です。ホスト型APIでは、同じボリュームで月額数百ドルから数千ドルになることがあります。

損益分岐点はワークロードによりますが、月あたり約500万トークンが一つの目安になります。

本番アプリをホスト型とローカル型の間で切り替えるには？

OpenAIクライアントを維持し、次の2つを差し替えます。

base_url
model

切り替え前には、リプレイツールで同じリクエストを実行し、レスポンス差分を確認してください。この考え方は、Postmanを使わないAPIテストでも説明されています。

最新のリーダーボードはどこで見られますか？

次の2つを確認してください。

それぞれ測定している観点が異なるため、両方を見て判断するのがおすすめです。

Forem: Akira

MCPサーバーテストプレイブック：Apidogを活用した手動・自動テスト

TL;DR

MCPの正体を短く整理する

MCPサーバーでテストすべき項目

1. プロトコル準拠

2. スキーマの正確性

3. ツールの動作

4. ツールのエラー処理

5. リソースアクセス

6. プロンプトのレンダリング

stdioでMCPサーバーを手動テストする

MCP Inspectorで起動確認する

生のstdioでJSON-RPCを送る

手動テストからApidogでの自動化へ移行する

1. MCPサーバー用のApidogプロジェクトを作成する

2. 標準リクエストを保存する

3. JSONPathアサーションを追加する

initialize のアサーション例

tools/list のアサーション例

tools/call 正常系のアサーション例

tools/call 異常系のアサーション例

4. アップストリームAPIをモックする

5. CIでMCPテストスイートを実行する

良いMCPテストカバレッジの目安

MCPサーバーテストでよくある間違い

initialize を省略する

エラーメッセージを完全一致で検証する

モックと本番レスポンスが乖離する

ストリーミングをテストしない

並行実行をテストしない

プロトコルエラーとツールエラーを混同する

実世界のユースケース

社内インシデント管理MCPサーバー

Notion用オープンソースMCPサーバー

複数MCPサーバーを運用するプラットフォームチーム

実装チェックリスト

結論

よくある質問

MCPとは何ですか？

HTTPラッパーなしでMCPサーバーをテストできますか？

MCPサーバーが呼び出す外部APIはどうモックしますか？

ツール結果のストリーミングはどうテストしますか？

プロトコルバージョンはテストすべきですか？

実際のClaude Desktopに対してテストすべきですか？

実際のMCPサーバー実装はどこで見られますか？

Maigretとは何か：壊れないOSINTスキャナー

要約（TL;DR）

Maigretとは何か、そして何ではないか

サイトシグネチャデータベース

Maigretが「見つかった」と「見つからない」を判定する方法

再帰的検索と情報抽出

CAPTCHAとレート制限の処理

シグネチャのドリフト問題

オプションのAI要約モード

正当なユースケース

APIテストに適用できるMaigretのパターン

1. チェックをコードではなくシグネチャとして管理する

2. ステータスコードだけで判定しない

3. シグネチャを継続的に更新する

4. ドリフト検出を定期実行する

5. LLMは判定ではなくレポート生成に使う

Maigret実行時の一般的な落とし穴

実際のユースケース

結論

よくある質問

Claude Code 無効なcustom3pエンタープライズ構成エラーの修正方法

まとめ

「custom3p」とは何か

なぜ今このエラーが増えているのか

根本原因1：ANTHROPIC_BASE_URLの末尾に/v1がある

誤った例

正しい例

実際の到達URLを確認する

根本原因2：認証情報の環境変数が違う

根本原因3：settings.jsonが不正なJSONになっている

よくあるミス：末尾カンマ

よくあるミス：スマートクォート

正しい形式

起動前にJSONを検証する

`initialize` のアサーション例

`tools/list` のアサーション例

`tools/call` 正常系のアサーション例

`tools/call` 異常系のアサーション例

`initialize` を省略する

根本原因1：`ANTHROPIC_BASE_URL`の末尾に`/v1`がある

根本原因3：`settings.json`が不正なJSONになっている

無料無制限 Claude Opus 4.7 API 入手