Claude Opus 5がDatabricksホストモデルとして登場したので試してみた

Posted at 2026-07-25

はじめに

2026年7月のリリースノートで、Anthropic Claude Opus 5がDatabricksホストのモデルとしてModel Servingでサポートされました。

Anthropicが2026年7月24日にリリースしたばかりのモデルが、Databricksのセキュリティ境界内でホストされるエンドポイントとして、追加の契約もAPIキー管理もなしに使えるようになりました。

実際に呼んでみたところ、レスポンスの受け取り方が従来のモデルと変わっていました。そのあたりも含めて書いていきます。

Claude Opus 5とは

Databricksのドキュメントでは、Opus 5は次のように説明されています。

Opusシリーズの系譜にあるハイブリッド推論モデルで、エージェンティックなコーディング、コードレビュー、長時間の自律作業にフォーカスしている
大規模なリファクタリングや機能のエンドツーエンド実装といった、複数ファイルにまたがる複雑なソフトウェアタスクを得意とする
高精度なバグ検出、マルチエージェントの協調に強い
100万トークンのコンテキストウィンドウを持ち、そのウィンドウ全体にわたって指示追従、ツール呼び出し、推論の品質を維持する

「100万トークン」という数字自体はOpus 4.6以降のOpus系ですでに提供されていました。Opus 5の説明で新しいのは、コンテキストの端まで品質が落ちないことが明示されている点です。

これは実務上わりと大きな違いです。長いコンテキストは「入る」だけでは意味がなく、そこに詰めたシステムプロンプトやツール定義が終盤まで効いてくれるかどうかが問題になります。数十ターン回したあとにツールの使い方を忘れる、最初に指定した出力フォーマットが崩れる、といった現象に心当たりのある方は多いと思います。エージェントを長く走らせるほど、この差は効いてきます。

エージェンティックコーディングと長時間の自律作業という方向性は、Databricks側の機能ともよく噛み合います。Genie Code、Databricks Assistant、Mosaic AI Agent Frameworkで組むカスタムエージェント。いずれも「長く走って、途中で人間に聞き返す回数が少ないほど価値が出る」ワークロードです。

Databricksホストモデルとして使う意味

Anthropicのモデルは、Anthropic API、Amazon Bedrock、Google Cloud、Microsoft Foundryからも使えます。そのうえでDatabricksホストを選ぶ理由は、モデルの性能そのものではなく、その周辺にあります。

セキュリティ境界の中で動く

このエンドポイントはDatabricksのセキュリティ境界内でホストされます。ドキュメントにも各モデルの説明の末尾に一文入っている、あの記述です。

地味な一文ですが、社内の審査を通す立場からすると重みが違います。「Anthropicにデータを送っています」と「Databricksの中で完結しています」では、レビューで聞かれることの数が変わります。データがDatabricksの外に出ていく経路を新たに作らずに済むこと、そのための例外申請やDPAの追加締結が要らないこと。このあたりが実際のコストです。

なお、Anthropicの利用ポリシーへの準拠は利用者側の責任とされている点は変わりません。社内展開の前に適用されるモデル規約を確認してください。

Unity AI Gatewayのガバナンスに乗る

Unity AI Gatewayを使っている環境では、Opus 5もモデルサービスとしてUnity Catalogの管理下に入ります。

アクセス制御: どのユーザーやグループがOpus 5を呼べるかを、Unity Catalogの権限モデルで制御できます。「Opusは特定チームのみ、Sonnetは全社」といった切り分けが、テーブルの権限管理と同じ枠組みでできます
使用量の追跡とレート制限: ユーザー単位、エンドポイント単位でのレート制限を設定できます。エージェント開発では、バグったループが一晩で予算を溶かすことが普通に起こるので、これは保険として重要です
推論テーブル: リクエストとレスポンスをDeltaテーブルに自動記録できます。あとから品質評価やデバッグに使えますし、監査への回答材料にもなります
ガードレール: PII検出や安全性フィルタをゲートウェイ層で適用できます。アプリケーションごとに実装する必要がありません

モデルが増えるたびに管理台帳が増えていくのではなく、既存の枠組みにそのまま乗る。この点が、複数モデルを並行運用している組織ではじわじわ効いてきます。

APIキーを配らなくてよい

pay-per-tokenのエンドポイントは、ワークスペースの認証情報でそのまま呼べます。Anthropicのアカウントを別途用意して、APIキーをシークレットスコープに入れて、部門ごとに請求を割り振って、という作業が丸ごと不要になります。

Foundation Model APIs pay-per-tokenでのクエリ実行

モデルの名前は2種類ある

最初に押さえておきたいのが呼び名の話です。同じClaude Opus 5に、2つの名前があります。

サービングエンドポイント名: databricks-claude-opus-5
モデルサービス名: system.ai.claude-opus-5 (Unity AI Gatewayの三層名前空間)

Unity AI Gatewayのモデルタブを開くと、Databricksホストのモデルが最初から一覧に並んでいます。自分で作成する必要はありません。Claude Opus 5も Created by: Databricks として登録されており、Location列が system.ai になっています。

筆者の環境ではLast modifiedが2026年7月24日 09:00でした。Anthropicのリリース当日です。

ここが最初のハマりどころです。 この2つは叩く経路が違います。databricks_openai の DatabricksOpenAI() はサービングエンドポイントを見にいくので、ここに system.ai.claude-opus-5 を渡すと404になります。

NotFoundError: Error code: 404 - {'error_code': 'ENDPOINT_NOT_FOUND', ...}

モデルサービス名で叩きたい場合は、素の OpenAI() クライアントに https://<workspace-url>/ai-gateway/mlflow/v1 を base_url として渡します。詳細はモデルサービスのクエリを参照してください。

この記事では、サービングエンドポイント名 databricks-claude-opus-5 で統一します。

AI Playgroundで試す

まずはAI Playgroundで挙動を見るのが手軽です。サイドバーから Playground を開き、モデルのドロップダウンからClaude Opus 5を選択します。

複数モデルを横に並べて同じプロンプトを投げられるので、Opus 4.8やSonnet 5との比較にはPlaygroundが一番速いです。

OpenAIクライアントから呼ぶ

基盤モデルAPIはOpenAI互換なので、既存のコードをほぼそのまま流用できます。まずはクライアントライブラリをインストールします。

%pip install -U databricks-openai
dbutils.library.restartPython()

パッケージ名はハイフン、import名はアンダースコアです。dbutils.library.restartPython() を実行しないとimportが通らないので、セットで実行してください。

from databricks_openai import DatabricksOpenAI

client = DatabricksOpenAI()

response = client.chat.completions.create(
    model="databricks-claude-opus-5",
    messages=[
        {
            "role": "system",
            "content": "あなたはデータエンジニアリングに詳しいアシスタントです。",
        },
        {
            "role": "user",
            "content": "Delta Lakeのliquid clusteringとpartitioningの使い分けを教えてください。",
        },
    ],
    max_tokens=2048,
)

print(response.choices[0].message.content)

これで呼び出しは成功します。ただし、出力を見ると期待したものが返ってきません。

signature という長大なbase64文字列が並んでいます。ここからが本題です。

reasoningモデルとしてのクエリ

拡張思考はデフォルトで有効

Opus 5は、何も指定しなくても拡張思考が有効になっています。 extra_body で thinking を渡す必要はありません。

その結果、message.content が文字列ではなくブロックの配列で返ってきます。中身を確認してみます。

for b in response.choices[0].message.content:
    print(b["type"], list(b.keys()))

reasoning ['type', 'summary']
text ['type', 'text']

reasoning ブロックと text ブロックの2つが返っています。先ほどの出力で見えていた署名は、reasoning ブロックの中身でした。

回答本文の取り出し方

type で絞り込んで取り出します。

content = response.choices[0].message.content

answer = next(b["text"] for b in content if b["type"] == "text")
print(answer)

これで期待していた回答が得られます。

思考の要約は返ってこない

reasoning ブロックの中身は summary キーだけで、その実体は次のようになっています。

{'type': 'summary_text', 'text': '', 'signature': 'CAIS6hMKcAgQEAEYAipA8VYOD9si...'}

text は空文字で、signature に暗号化された思考が入っています。Opus 5は思考の要約を返しません。

これは注意が必要です。Databricksの推論モデルのクエリのドキュメントには、思考サマリーを取り出すサンプルとして次のような書き方が載っています。

reasoning = msg.content[0]["summary"][0]["text"]

Opus 5でこれを実行しても、空文字が返るだけです。エラーにはならないので気づきにくく、「思考が空で返ってくる」と悩むことになります。

移行時に壊れるコード

ここまでの挙動から、既存コードへの影響が見えてきます。

# Opus 4.8などでは文字列。Opus 5では配列
text = response.choices[0].message.content

モデル名の文字列を差し替えるだけの移行では、このコードが壊れます。 しかもエラーは出ません。文字列を期待していた箇所に配列が入るので、後続の処理で文字列結合や正規表現が想定外の動きをしたり、そのままDBに書き込まれたりします。

エラーで落ちてくれるなら気づけますが、「動くけれど中身が違う」という壊れ方なので、本番投入後に発覚する可能性があります。移行前に message.content を文字列として扱っている箇所を洗い出しておくことをおすすめします。

なお、初回の呼び出しには35秒ほどかかりました。思考している時間です。レイテンシが重要な用途では、この点も評価に含める必要があります。

Sonnet 4は10月9日にリタイア

新モデルの話とセットで見ておきたいのが、旧モデルの終了予定です。Anthropic Claude Sonnet 4は2026年10月9日にリタイアします。推奨される移行先はClaude Sonnet 4.6です。

自社のノートブック、ジョブ、エージェントで databricks-claude-sonnet-4 を参照している箇所がないか、いまのうちに棚卸ししておくことをおすすめします。エンドポイント名がハードコードされているケースは想像以上に多く、リタイア当日に本番のジョブが落ちてから気づく、というのが典型的な失敗パターンです。

そして先ほど見た通り、移行は文字列の置換だけでは終わりません。Opus 5に乗り換えるならレスポンス構造の変更に対応する必要がありますし、Claude Sonnet 5では temperature、top_p、top_k がサポートされておらず、これらを含むリクエストは400エラーを返します。移行先ごとに挙動を確認してください。

リタイア予定の一覧は非推奨および廃止されたモデルで確認できます。四半期に一度は見る習慣をつけておくと安全です。

まとめ

Claude Opus 5をDatabricksから呼んでみて分かったことをまとめます。

エンドポイント名は databricks-claude-opus-5。DatabricksOpenAI() でそのまま呼べる
Unity AI Gatewayでは system.ai.claude-opus-5 として見えるが、こちらは別経路。DatabricksOpenAI() に渡すと404になる
拡張思考はデフォルトで有効。extra_body での指定は不要
message.content は文字列ではなくブロックの配列。type が text のブロックから本文を取り出す
思考の要約は返ってこない。summary_text の text は空で、signature に暗号化された思考が入る
モデル名を差し替えるだけの移行では、message.content を文字列として扱っているコードがエラーなしで壊れる

一番の収穫は、レスポンス構造の変更に気づけたことでした。新しいモデルが出ると「差し替えれば良くなる」と考えがちですが、まず小さく呼んで返り値を確認する、という手順を飛ばさない方が良さそうです。