Claude Codeの自社製品への組み込み条件 — 改変禁止と利用者ごとの認証

Claude Codeを自社のサービスやホスト型サンドボックスにプリインストールして提供するには、Commercial Termsへの同意が前提になります。そのうえで守る条件は2つあります。バイナリを改変しないこと、そして利用料を事業者が肩代わりせず、エンド利用者が自分の認証情報で使うことです。名称とロゴにも制限があります。

この記事は、Claude Codeを製品に同梱する開発者・事業者の立場から、条件を作業単位に落とします。契約条項そのものの読み方はClaude Commercial Termsのチェックポイント、利用者側の商用利用の可否はClaude商用利用の可否と生成物の権利にあります。

組み込みの前提 — どの規約が適用されるか

Claude Codeの利用は、Team・Enterprise・APIの利用者ならCommercial Terms of Service、Free・Pro・Maxの利用者ならConsumer Terms of Serviceに服します。Amazon BedrockやGoogle CloudのAgent Platform経由で使う場合も、既存の商用契約がClaude Codeの利用に適用されます。個別に別の合意をしていれば、その合意が優先します。

製品への組み込みは、この延長で別の扱いになります。法務ページによれば、Claude Codeをプリインストールする、あるいはホスト型サンドボックスなどのエージェント基盤で実行するには、Commercial Termsに同意し、以下の条件を満たす必要があります。

Claude Codeがどの経路でアクセスされても、適用されるのはAnthropicの標準規約です。自社プラットフォームを挟んだからといって、別の条件に切り替わることはありません。

バイナリを改変しない — 認証手段も含めて

1つ目の条件は、Claude Codeのバイナリを改変しないことです。公開された状態のままインストールして動かします。

ここで見落としやすいのは、認証手段への手入れも改変にあたる点です。Claude Codeに組み込まれた認証方法を、取り除く、無効にする、制限することは認められていません。対象には、Claudeアカウントでのサインインと、利用者自身のAPIキーの両方が含まれます。

つまり、製品に載せるときに「うちはAPIキー方式だけ残したい」「ログイン画面を隠したい」とバイナリや同梱物を加工する設計は、条件から外れます。判断に迷うのは、設定ファイルでの制御や、起動スクリプトでの環境変数の渡し方です。この点が条件の言う改変にあたるかどうかは、法務ページに記載がありません。設定で認証を絞りたい場合は、Anthropicの営業窓口に確認する流れになります。

利用料を肩代わりしない — 再販と仲介の線引き

2つ目の条件は、お金の流れに関するものです。事業者が、エンド利用者に代わってClaudeの利用料を負担したり、再販したり、仲介したりすることは認められていません。

エンド利用者は、次のいずれかの認証情報で自分自身が認証します。

• 自分のAnthropic APIキー
• 自分のClaudeサブスクリプションの認証情報
• サードパーティ推論プロバイダーの認証情報(Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry)

この利用は、利用者自身がAnthropicと結んだ契約に直接請求されます。サードパーティ推論プロバイダー経由なら、そのプロバイダーとの契約に請求されます。

認めている鍵の渡し方

同じ法務ページには、禁止の裏返しとして認められる範囲も書かれています。顧客が自分のAPIキーやプロバイダーの認証情報を、開発環境、シークレット管理、マシンイメージに設定して、顧客自身の許可された利用者に使わせることは制限されていません。条件は、その利用が鍵の持ち主に請求され、再販も仲介もされないことです。

さらに、エンド利用者が自分のClaudeサブスクリプションで無改変のClaude Codeにサインインすることも妨げられません。プラットフォームがClaude Codeをホストしている場合も同じです。

整理すると、次のようになります。

下の2行は、法務ページの文言を製品設計に当てはめた読みです。個別の構成が条件に触れるかは、規約の原文とAnthropicへの確認で決めることになります。

利用者の鍵を環境に渡す例

利用者ごとのAPIキーを使う構成なら、コンテナ起動時に利用者の鍵を環境変数で渡すのが最も単純です。Claude CodeはANTHROPIC_API_KEYが設定されていれば、それをAPIアクセスに使います。

docker run --rm -it \
  -e ANTHROPIC_API_KEY="$END_USER_API_KEY" \
  your-sandbox-image claude -p "このリポジトリの概要を説明して"

ここでEND_USER_API_KEYに入れるのは、そのエンド利用者自身が発行した鍵です。事業者の鍵を全員に共通で入れると、先の表の「肩代わり・仲介」の行になります。

鍵をローテーションする基盤なら、apiKeyHelper設定でスクリプトに鍵を返させる方法もあります。ボールトから短命のトークンを取る用途が想定されています。ここでも、スクリプトが返すのは利用者本人の鍵という前提は変わりません。

{
  "apiKeyHelper": "/usr/local/bin/fetch-user-key.sh"
}

Claude Codeは、複数の認証情報があると決まった順序で1つを選びます。クラウドプロバイダーの変数、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、apiKeyHelper、CLAUDE_CODE_OAUTH_TOKEN、各種プロファイル、/loginによるサブスクリプションの順です。事業者側の鍵がイメージの環境に残っていると、利用者のサインインより先に選ばれます(対話モードでは、初回に鍵を使うかの確認が出ます)。イメージに鍵を焼き込まない運用は、規約対応と事故防止の両方に効きます。選ばれている認証は/statusで確かめられます。

Claude.aiログインの組み込みは別問題

法務ページの認証の節は、OAuth認証を、Free・Pro・Max・Team・Enterpriseの購入者向けで、Claude Codeなどの通常利用を支えるものと位置づけています。製品やサービスを作る開発者には、Claude ConsoleまたはサポートされるクラウドプロバイダーのAPIキー認証を使うよう求めています。Agent SDKを使う場合も同じです。

禁止されている点は3つです。

• サードパーティ開発者が自分のアプリにClaude.aiログインを提供すること
• Free・Pro・Maxのプラン認証情報で、利用者の代わりにリクエストを中継すること
• Claude.aiの認証情報やセッショントークンを収集・保存・仲介すること(サインインはAnthropic自身のフローで完結させる)

先に見た「利用者が無改変のClaude Codeに自分のサブスクでサインインする」ことと、「自社アプリがClaude.aiログインを組み込む」ことは別物です。前者は利用者とAnthropicの間で完結しますが、後者は事業者のアプリが認証を仲介します。製品の画面にログインフォームを作り、そこで受けた情報でClaudeを呼ぶ設計は、後者に入ります。

実装中にOAuth not supported系の401が出る場合の切り分けは、「OAuth not supported」401エラーの原因と対処にあります。チーム内で認証方式をそろえたい場合はClaude Codeのチーム認証の設定が参考になります。

規約への強制措置については、法務ページに「事前通知なく措置を取ることがある」との記載があります。上限がサブスクリプション向けの通常利用を前提にしていることも、同じページに書かれています。

名称とロゴ — 書いてよい言い方と禁止される言い方

3つ目は表示の話です。製品の説明に使える表現と、使えない表現が分かれています。

上記以外の名称・ロゴの使い方は、Trademark Guidelinesに従い、Anthropicの書面による許可が必要です。日本の事業者がサービス名を決める段階で効いてくるのは、「Claude Code」を冠した製品名の可否です。製品名に入れる案は、この規約の文言では不可になります。

Agent SDKで作る場合は表示ルールが違う

Claude Codeそのものを同梱するのではなく、Agent SDKでエージェントを作って製品に載せる選択肢もあります。Agent SDKの利用もCommercial Termsの下にあり、自社の顧客やエンド利用者に提供する製品を動かす場合も同じです。

名称の扱いは、Claude Codeを同梱する場合とは異なります。

Agent SDKの概要ページは、自社製品が独自のブランドを保ち、Claude CodeやAnthropicの製品のように見えてはならないとも述べています。さらに、事前の承認がない限り、Claude.aiログインやレート制限をサードパーティが自社製品として提供することは認められていません。

SDK側の運用設計はAgent SDKを本番にホストする設計に、コンテナやマルチテナント分離の論点があります。

組み込み前の確認リスト

規約の読みを、実装前のチェックに落とすと次の順になります。

どれか1つでも判断がつかない場合の窓口は、法務ページ自身が営業窓口(contact sales)としています。構成が規約の想定から外れていることが多い、たとえば利用者の鍵を事業者が預かって管理する形は、設計を固める前に問い合わせる価値があります。

条件の全体像

3つの条件は、見た目が違っても同じ考え方でつながっています。Claude Codeは「Anthropicが出したまま、利用者が自分の資格で使う」ことが前提で、事業者はその入れ物を提供する役です。バイナリ無改変は認証の入口を残すため、利用者ごとの認証は請求先を利用者に残すため、名称の制限は提携関係を誤認させないための条件と読めます。

この前提に沿った設計なら、環境変数やシークレット管理での鍵の注入は規約の範囲で行えます。逆に、事業者が窓口や鍵を一本化して利用者の手前に立つ設計は、先に挙げた条件のどれかに触れやすくなります。AUPにあたる利用目的の制限は別の層にあり、AnthropicのAcceptable Use Policyで禁止用途が整理されています。