Anthropic API利用者向け法的保護拡充の内容とは

2023年12月の発表で何が拡充されたか

Anthropicは2023年12月19日、商用規約(Commercial Terms of Service)を簡素化して著作権侵害への補償(indemnity)を拡充したことと、開発者向けの新しいMessages APIをベータ公開したことを同時に発表しました。それまでの契約は「サービス契約(services agreement)」と呼ばれており、この発表で商用規約という名称になりました。

著作権まわりの変更点は2つです。1つは、利用者がClaudeの出力に対する所有権を保持できること。もう1つは、許諾された利用や出力について著作権侵害の主張を受けた場合に、Anthropicが利用者を防御し、承認された和解や判決で生じる支払いを負担することです。

補償されるのはどんなときか

条文(現行の商用規約K.1)では、補償の対象は「第三者の知的財産権を侵害するという主張」です。発表文は著作権と書いていましたが、規約の文言は著作権に限りません。

条件は2つあります。

• 規約に沿った有償利用であること(Anthropicが訓練に使ったデータも、利用の一部として含まれます)
• 主張の中身が、その利用または、その利用から生じた出力に向けられていること

Anthropicが負うのは、防御と、裁判所の判決またはAnthropic承認済みの和解による支払いです。補償は第三者からの請求に対する唯一の救済で、責任制限の条項(L.3)は補償義務には適用されません。

補償をする側の契約主体は、利用者の居住地で決まります。EEA・スイス・英国に居住する利用者にはAnthropic Ireland, Limited、それ以外の地域ではAnthropic, PBCです。

「規約に沿った」の中身も押さえておく必要があります。D.2は、利用者が規約、Usage Policy(旧Acceptable Use Policy)、対応地域ポリシー、サービス固有の規約に従うことを求めています。補償を受ける前提に、ポリシー順守が入っているわけです。

補償が外れるのはどんなときか

除外されるのは、主張が上の6項目の事情から生じている限度に限られます。主張の一部だけが該当するなら、その部分だけが補償の外に出ます。加えて、補償を受ける側の詐欺・故意の不正・法令違反・規約違反に起因する主張も、補償義務の対象外です。

(b)は「Anthropic以外が提供する技術やコンテンツとの組み合わせ」と広く書かれています。Claudeの出力を自社のコードや素材と一体にして出す使い方が、この項目にどこまで触れるかは条文だけでは決まりません。個別の判断は、契約書を読む法務担当や弁護士の領分です。出力を製品に載せる前に、組み合わせ方を社内で一度書き出しておくと、その相談が速くなります。

利用者の側から見ると、補償は一方通行ではありません。K.2では、利用者もAnthropicを防御し、判決や承認済みの和解による支払いを負担します。対象は、利用者や利用者のユーザーが入力したデータに関する第三者の主張と、Usage Policy・サービス固有の規約・使用制限に違反した利用に関する主張です。

所有権の条項と「AS IS」は同じ規約に同居している

補償と並んで発表文が挙げたのが、出力の所有権です。現行の商用規約では、利用者は入力に対するすべての権利を保持し、出力を所有します。Anthropicは顧客コンテンツに対する権利を放棄し、サービスから得た顧客コンテンツでモデルを訓練することはできません。

一方、L.2の保証の否認では、サービスと出力は現状有姿で提供され、非侵害の黙示保証も含めて否認されています。つまり、Anthropicは「侵害しない」とは保証せず、侵害を主張された場合の防御と支払いで備えるという役割分担になっています。

この役割分担を支えるのが、責任制限との関係です。L.3.aは、損害賠償を直近12か月に利用者が支払った料金までに限り、逸失利益などの間接損害も除外しています。ただしL.3.bで、K条の補償義務はこの制限の外に置かれています。通常の損害賠償は料金の範囲に収まる一方、第三者からの知財の主張に対する防御と支払いは、その上限を受けません。

A.1は、サービスを自社の顧客やエンドユーザー向けの製品・サービスの動力に使う許諾を与えています。D.4は、競合する製品やサービスを作るための利用、競合するAIモデルの訓練、サービスの再販、リバースエンジニアリングを禁じています。補償の前提になる「規約に沿った利用」には、この使用制限も入ります。

A.2は、サードパーティ機能(第三者が提供する機能やコンテンツ)をサービスに含めず、Anthropicは責任を負わないと定めています。K.1の補償が「サービスの利用」に向けられていることと並べると、第三者の機能を経由した部分が補償の範囲に入るかは、条文を読み比べて判断する論点になります。

もう1つ、D.3には利用者側の義務があります。出力が自社の用途に適するかを評価し、事実の記述は独自に確認しなければ信頼できないことを、自社のユーザーにも知らせる必要があります。補償は誤情報の責任まで肩代わりするものではありません。商用利用の可否や生成物の権利をプラン別に見たい場合はClaude商用利用の可否・生成物の権利・データ学習のオプトアウトをプラン別に確認するが参考になります。

Messages APIは何を変えたか

同じ発表で公開されたMessages APIのベータ版は、プロンプト構築のミスを開発中に捕まえやすくする目的でした。旧Text Completions API(/v1/complete)では、HumanとAssistantのターンを示す文字列を自分で連結する必要がありました。動的に組み立てるプロンプトでは、この連結で細かな誤りが起きやすかったのです。

発表文のコード例は次のとおりです。

// 変更前: POST https://api.anthropic.com/v1/complete
{
  "model": "claude-2.1",
  "max_tokens_to_sample": 1024,
  "prompt": "\n\nHuman: Hello, world\n\nAssistant: Hi, I'm Claude!\n\nHuman: 四半期の役員向けブリーフのテンプレートを作れますか?\n\nAssistant:"
}

// 変更後: POST https://api.anthropic.com/v1/messages
{
  "model": "claude-2.1",
  "max_tokens": 1024,
  "messages": [
    { "role": "user", "content": "Hello, world" },
    { "role": "assistant", "content": "Hi, I'm Claude!" },
    { "role": "user", "content": "四半期の役員向けブリーフのテンプレートを作れますか?" }
  ]
}

書き換えるのは3点です。prompt文字列がmessages配列に、max_tokens_to_sampleがmax_tokensに、\n\nHuman:と\n\nAssistant:の自前挿入がroleフィールドに変わります。ターンの区切りをテキストではなく配列の構造で持つので、文字列連結の誤りが入り込む場所が減ります。

移行で気づきにくいのは、Messages APIがステートレスな点です。会話履歴は毎回すべて送ります。過去のassistantターンは、実際にClaudeが返したものでなくても構いません。履歴を自前で保存していないコードは、配列の元になる履歴の持ち方から決める必要があります。

もう1点が、応答の書き出しをあらかじめ置くprefillです。最後のassistantメッセージにあたる使い方で、Claude 4.6以降のモデルとClaude Mythos Previewでは、prefillを付けたリクエストが400エラーになります。代替として、構造化出力かシステムプロンプトでの指示が案内されています。旧形式のコードにこの種の書き出しがある場合は、移行と同時に見直す対象です。

発表のあとMessages APIはどうなったか

現在のAPIリファレンスでは、Text Completionsは「legacy」と明記されています。Messages APIへの移行が推奨され、今後のモデルや機能はText Completionsと互換にならないと書かれています。リファレンスは、移行の手引きとしてMessages APIの利用ガイドへのリンクも載せています。発表文が「近く提供する」としていた堅牢な関数呼び出しは、ツール使用(tool use)としてMessages API上で提供されています。ツール使用のその後の広がりはAnthropic Advanced Tool Use — Claudeが大量ツールを扱う3つの機能にまとめています。

法務担当と開発チームが同じ発表から始められた理由

契約とAPIを同じ日に出したことで、読み手ごとに見るべき箇所が分かれました。法務担当は、K条の補償範囲とD.2のポリシー順守を、自社の使い方と突き合わせます。開発チームは、/v1/completeを呼んでいる箇所を洗い出し、書き換えを入れます。

2つの作業は独立しています。K.1の条件にエンドポイントの指定はなく、問われるのは有償利用であることと規約への適合です。旧APIを使い続けているチームも、Messages APIに移ったチームも、同じ商用規約の下にいます。

ただし、Amazon Bedrock経由の利用者の条項は別文書です。発表文は、Bedrock版の商用規約を別に案内しています。Bedrockで使うチームは、直接契約の商用規約ではなく、そちらの条文で補償の範囲を読む必要があります。

まとめ

補償の有無は、出力をどう使うかで決まります。Text CompletionsかMessages APIかは条件に入っていません。Messages APIへの書き換えは、legacyになったAPIを使い続けるかという、補償とは別の判断です。