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

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

Anthropicは2023年12月19日、商用規約(Commercial Terms of Service)を簡素化して著作権侵害への補償(indemnity)を拡充したことと、開発者向けの新しいMessages APIをベータ公開したことを同時に発表しました。それまでの契約は「サービス利用規約」という名称でしたが、この発表を機に商用規約として整理され、Claude APIの顧客は2024年1月1日から、Amazon Bedrock経由の利用者は2024年1月2日から新しい条項が適用されました。

著作権まわりの変更点は、利用者がClaudeの出力に対する所有権を保持できるようにしたことと、authorized(許諾された)利用によって生じた出力が第三者の著作権を侵害すると主張された場合に、Anthropicが利用者を防御し、和解金や判決による支払いが生じればAnthropicが負担するとした点です。この防御・補償の枠組みは、企業がClaude APIを業務システムに組み込む際の法務リスクを引き下げる目的で導入されました。

Messages APIは何を解決するために生まれたか

同じ発表で公開されたのが、開発者向けの新しいMessages APIのベータ版です。それ以前のText Completions API(/v1/complete)では、プロンプトをHumanとAssistantのターン交代を示す文字列として自分で組み立てる必要がありました。ユーザー入力を動的に組み込んでプロンプトを構築する場面では、この文字列組み立てで些細な誤りが起きやすいという課題がありました。

Messages API(/v1/messages)は、この課題を構造化されたメッセージ配列で解決します。以前の形式と比較すると違いがはっきりします。

// 変更前: 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": "四半期の役員向けブリーフのテンプレートを作れますか?" }
  ]
}

役割ごとにオブジェクトを分けて配列で渡す形式に変わったことで、プロンプト構築時の文字列連結ミスをAPI側の構造で早期に検出しやすくなりました。発表文では、この構造化されたAPIを土台に、より高度な機能(堅牢な関数呼び出しなど)を今後Messages APIに追加していく方針も示されていました。

補償(indemnity)という仕組みの中身

著作権補償は、契約実務としては目新しいものではありませんが、生成AIの出力に対して適用する場合は独特の難しさを伴います。従来のソフトウェアライセンス契約では、提供者が渡すコードやコンテンツの範囲が明確なため、侵害が起きた場合の責任の所在も比較的はっきりしています。ところが生成AIの出力は、学習データ・プロンプト・モデルの推論過程が組み合わさって生まれるため、ある出力が誰の権利を侵害しているかを事前に見極めるのが難しいという性質があります。

Anthropicが導入した補償の枠組みは、この不確実性を利用者側に負わせず、authorized(許諾された)利用の範囲で生じた侵害の主張については自社が防御し、必要な支払いも負担するという形で応えたものです。「authorized」という限定が付いている点は見落とせません。利用ポリシーに反する使い方や、意図的に他者の著作物を模倣させるような使い方で生じた出力は、この補償の対象から外れる可能性があります。企業がAPIを業務に組み込む際は、この限定の範囲を理解したうえで利用規約に沿った運用をする必要があります。

Text Completions APIはなぜ問題だったか

発表文が指摘した「動的にプロンプトを構築する場面でのミス」は、具体的にはHumanとAssistantのターンを示す文字列(\n\nHuman: \n\nAssistant:)を、開発者自身が正しい位置に挿入する必要があった、という設計に起因します。ユーザー入力をそのままプロンプト文字列に埋め込むと、入力の中にたまたま\n\nHuman:に似た文字列が含まれていた場合、モデルが会話のターンを誤認識するリスクがありました。単純な文字列連結でプロンプトを組み立てるアプリケーションほど、この種のバグを踏みやすい構造だったといえます。

Messages APIがこの問題を解決できたのは、ターンの区切りをテキストではなくAPIのデータ構造(配列とroleフィールド)で表現するようにしたためです。ユーザー入力はcontentフィールドの値として扱われ、たとえその中に特殊な文字列が含まれていても、role構造そのものを壊すことはありません。プロンプトインジェクションの初期的な緩和策としても機能する設計変更だったと位置づけられ、後年のツール使用機能が同じデータ構造の上に積み重なっていく土台にもなりました。

この発表は現在のClaude APIにどうつながっているか

Messages APIは、その後Text Completions APIを置き換える形で標準のAPIエンドポイントになりました。発表当時「今後追加予定」とされていた堅牢な関数呼び出しの機能は、現在のツール使用(tool use)機能として実装されています。ベータとして始まった2023年12月から、Messages APIはAnthropicのAPI基盤の中核として定着した形です。ツール使用は、その後さらに複数ツールの同時呼び出しや大量ツール定義の効率的な扱いへと発展しており、この広がりはAnthropic Advanced Tool Use — Claudeが大量ツールを扱う3つの新ベータにまとめています。

著作権補償の枠組みも、現在の商用規約に受け継がれています。ただし補償には例外があり、出力に含まれる特許発明を実施した場合や、出力を商標として取引に使った場合などは対象外とされています。この例外の範囲は2023年12月の発表文には含まれておらず、その後の商用規約の改訂を通じて明文化されたものです。商用利用の範囲や生成物の権利について、プラン別の違いも含めて詳しく確認したい場合はClaude商用利用の可否・生成物の権利・データ学習のオプトアウトをプラン別に確認するにまとめています。

商用規約という名称への変更が意味すること

発表文では、それまでの契約が「サービス利用規約(Terms of Service)」から「商用規約(Commercial Terms of Service)」という名称に変わったことにも触れています。単なる呼称の変更に見えますが、この名称変更は、Anthropicの契約体系が消費者向けと商用向けで別々に整備される方向へ進んでいたことを示す動きでもあります。現在のAnthropicは、個人が使うConsumer Terms(消費者向け利用規約)と、企業が使うCommercial Terms(商用規約)を明確に分けて運用しており、この区分の原型は2023年12月の名称変更にまでさかのぼれます。

契約を分けることで、Anthropicは消費者向けと商用向けでデータの扱いや保証の水準を独立に設計できるようになりました。実際、消費者向けの規約は個人ユーザー保護の観点から改定が重ねられており、商用規約は企業のコンプライアンス要件に応える形で著作権補償などの条項を積み上げています。契約体系を分離した初期の一歩が、2023年12月の名称変更でした。

なぜこのタイミングでの発表だったのか

2023年後半は、生成AIの出力が第三者の著作権を侵害するリスクをめぐる議論が業界全体で強まっていた時期です。企業がAIをプロダクトや業務プロセスに組み込む際、著作権侵害の法的リスクをどちらが負うのかは導入判断を左右する要素になります。Anthropicが補償条項を明確化したのは、企業顧客がClaude APIを安心して採用できるようにするための実務的な対応と見ることができます。

同時にMessages APIを公開した点も、単なる開発者体験の改善にとどまりません。構造化されたメッセージ形式は、その後のツール使用やマルチターンの会話管理、システムプロンプトの分離といった機能を追加していくための土台になりました。移行する開発者にとっての実作業は、prompt文字列にmax_tokens_to_sampleを渡す呼び出しを、messages配列にmax_tokensを渡す呼び出しに書き換えることです。パラメータ名の変更だけでなく、\n\nHuman: \n\nAssistant:という文字列を自前で挿入していた箇所をrole: "user" role: "assistant"のオブジェクトに置き換える作業も伴うため、複数ターンの会話を組み立てるコードほど書き換える行数が多くなります。ターン数が多いチャットボットや、動的にプロンプトを生成するバッチ処理ほど、文字列連結のロジックそのものを配列組み立てのロジックに作り直す必要がありました。契約変更とAPI変更を同じ発表に載せたことで、法務担当者は補償条項の確認を、開発チームは/v1/completeから/v1/messagesへのエンドポイント移行を、同じ発表文を起点に並行して進められました。

まとめ

2023年12月19日の発表は、著作権補償を含む商用規約の整備とMessages APIのベータ公開という2つの柱で構成されていました。著作権補償の枠組みは現在の商用規約に受け継がれ、Messages APIはその後Text Completions APIに代わる標準のエンドポイントとして定着しています。当時ベータだった機能が今どう発展しているかを踏まえると、この発表はClaude APIの現在の姿を形作った転換点のひとつです。法務面の補償拡充と開発者体験の刷新を同時に打ち出した構成は、企業導入を後押しする発表でした。