1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

さくらのAI Engine を Claude Code に差して61分 — 「互換」の境界は3箇所で出た

1
Posted at

「OpenAI・Anthropic互換APIを無料で使おう!『さくらのAI Engine』3,000リクエスト使い切りチャレンジ」への参加記事です。

やったことは一行で書けます。普段 Claude Opus で回している自分のドキュメント運用に、モデルだけ preview/Kimi-K2.6 を差し込んで、同じ作業をさせた。 そして通らなかったところを、エラー文字列と実測値ごと持って帰りました。

「動きました!」で終わらせないために、この記事の数字はすべて その場のセッションログ(~/.claude/projects/<cwd>/<sessionId>.jsonl)を後から機械的に集計したものです。数え方は最後に書きます。

本記事の実測は 2026-08-25 に 1台の Windows マシンで走った 2 セッション分(n=1) です。モデルもプレビュー版なので、時期が変われば挙動は変わります。「私の環境ではこう出た」以上の主張はしません。

登場人物を先に決めておきます。 本記事の「」は筆者(人間)です。AI 側はモデル名で書き分けます——Claude Code(エージェント本体)、preview/Kimi-K2.6(今回差したモデル)、Claude Opus 5(普段使っているモデル。この記事のログ集計と下書きを担当)。誰がやったのかが混ざると、実測値の意味まで変わってしまうので。

先に結論

# 分かったこと
1 テキストだけのエージェント作業は普通に通った。 ローカルファイルの読み取り・BashGlob・日本語の指示追従は、10ターン連続で問題なし
2 サーバー側ツール(Web検索)は互換の外。 web_search_20250305 を投げると 400 input_schema Field required で弾かれる
3 画像・PDF の添付は通らない。 content が配列(画像ブロック)だと 400 Input should be a valid string
4 2 と 3 は「詰み」に直結する。 添付で 400 になった後、Claude Code の自動コンパクションも同じ 400 で失敗し、そのセッションは続行不能になった
5 プロンプトキャッシュが効かないcache_read_input_tokens が全ターン 0)。会話が伸びるほど毎ターン全文が入力として積み上がる
6 無償枠はリクエスト数(月3,000)なので、この使い方だと枠は全く減らない。 減るのは枠ではなく時間とトークンのほう

そして 2 と 3 は、公式ページに最初から書いてあるのです。

現時点では画像入力やマルチターン会話には対応していません
現在ご利用いただけるモデルは「preview/Kimi-K2.6」のみとなります
さくらのAI Engine より)

この記事の値打ちがあるとすれば、この一文が実運用でどういう形のエラーになって現れるかを、逐語で残したところだと思います。仕様の文と、画面に出るエラーは、見た目が全然違うので。

構成

接続設定(エンドポイントURL・アカウントトークンの形式)は公式マニュアルの記載に従ってください。本記事は接続後の挙動の話に絞ります。

読ませた対象は、私が普段 AI 駆動開発(AIDD)の運用に使っている Markdown 群です。1ファイルで 146KB/418行あるような、行儀の悪いドキュメントが並んでいます。長文コンテキストの実弾としては悪くない素材でした。

エージェントに与えたタスクは、たとえばこういうものです。

  • 作業ログの正本ファイルを読んで、次にやることを整理する
  • ~/.claude 配下を調べて、直前に落ちたセッションの原因を解析する
  • イベントページを読んで、記事の要件を確定する

つまり、「読む・探す・調べる」を人間の代わりにやらせるという、コーディングエージェントのごく普通の用途です。

実測値

セッションログから集計した値です(単位はトークン)。

項目 セッションA セッションB
時間帯(JST) 18:57:48 – 19:58:55(約61分) 19:59:50 – 20:07:37(約8分)
モデル preview/Kimi-K2.6 preview/Kimi-K2.6
応答したアシスタントターン 10 9
エラーで返ったターン 4 0
入力トークン合計 818,217 396,660
出力トークン合計 8,822 5,096
cache_read_input_tokens 合計 0 0
cache_creation_input_tokens 合計 0 0

2セッション合計で 入力 1,214,877/出力 13,918入力は出力の約87倍です。

そして 1 セッション内での入力の伸びがこれ。

ターン 入力トークン
1 40,997
2 41,099
3 88,876
10 96,189

3ターン目で倍増しているのは、そこで 146KB のファイルを1本読ませたからです。以降はその中身を毎ターン再送し続けていることが数字から読めます。キャッシュが 0 なので、当然そうなります。

実際に溶けたところがこれです。さくらのクラウドのコントロールパネルの利用量グラフ(当月・preview/Kimi-K2.6)。8月25日にだけ棒が立っています。

image.png

グラフの読み方は、青が入力トークン(左軸・最大300万)、オレンジがリクエスト数(右軸・最大80)、ピンクが出力トークンです。出力(ピンク)は、この縮尺だとほぼ見えません。入力と出力の桁が2つ違うというのが、エージェント利用の形をそのまま表しています。

ダッシュボードとの差について。 グラフ上の同日の値は、入力トークンが約250万・リクエスト数が約75本でした。セッションログから説明できるのは入力の約半分・リクエストの約1/4です。差分は、エラーで落ちたリクエスト・WebFetch が内部で呼ぶ小型モデル・自動コンパクションの試行などが候補ですが、内訳は特定できていません。断定は避けます。

通ったこと

拍子抜けするくらい普通に動いた部分から書きます。

  • ローカルファイルの読み書きRead / Glob / Bash)。ツール呼び出しのフォーマットは崩れませんでした
  • 日本語の指示追従。「この後にキャプチャを送るので一旦待って」のような、手順を制御する指示にもきちんと従いました
  • 長文の読解。146KB のファイルを読ませて要点を答えさせる分には破綻しませんでした
  • 複数ツールの並列呼び出し。1ターンで Bash 3本+WebFetch 1本を同時に投げる、という Claude Code の使い方にも追随しました

体感の遅さについては、私は最初 effort を最大にして走らせて「応答が遅すぎる」と判断し、途中で1段落として使いました。これは設定の問題であってモデルの限界ではありません。

通らなかったこと(ここからが本題)

1. サーバー側ツール(Web検索)は互換の外

Claude Code が Web 検索を投げた瞬間、これが返りました。

API Error: 400 1 validation error:
  {'type': 'missing', 'loc': ('body', 'tools', 0, 'input_schema'), 'msg': 'Field required',
   'input': {'max_uses': 8, 'name': 'web_search', 'type': 'web_search_20250305'}}

読み解くとこうです。Anthropic の Web 検索は type: "web_search_20250305" というサーバー側ツールで、クライアントは input_schema を持たない特殊な定義を送ります。互換エンドポイント側はそれを普通のクライアントツールとして検証するので、「input_schema が無い」と怒られる。

「Messages API 互換」は、tools の中身まで互換とは限らない。 サーバー側ツール(Web検索・コード実行など)は、互換 API では別物として扱う必要があります。

WebFetch のほうは 400 ではなく、こう返りました。

No response from model

これが3回。エラーですらないので、エージェントは「応答しない」以上のことが分からず、同じ URL を手を変えて取りに行って、その分のトークンを溶かしました。

2. 画像・PDF の添付は通らない

イベントページが取れないので、私はページを PDF にして添付しました。返ってきたのがこれです(base64 は省略)。

API Error: 400 2 validation errors:
  {'type': 'string_type', 'loc': ('body', 'messages', 21, 'content', 'str'),
   'msg': 'Input should be a valid string',
   'input': [{'source': {'data': 'JVBERi0xLjQ...'}}]}

messages[21].content文字列であるべき、と言われています。Anthropic の Messages API では content に「テキストブロック+画像ブロック」の配列を渡せますが、互換エンドポイントは配列形式(=マルチモーダル入力)を受け付けない、という意味になります。

これが公式の「画像入力には対応していません」の実体です。仕様書の一文としては穏やかですが、現場では 400 で会話が止まります

3. そして詰む

ここが一番の学びでした。添付が 400 で弾かれた後、次のターンでこれが出ます。

Prompt is too long · automatic compaction failed: API Error: 400 2 validation errors:…

Claude Code は文脈が溢れると自動コンパクション(会話を要約して圧縮する)を走らせます。ところがその要約リクエストは、エラーになったメッセージを含む会話全体を送るので、同じ 400 で失敗する

結果、

  • 文脈は溢れている(=そのままでは送れない)
  • 圧縮しようとすると 400(=圧縮もできない)

という状態になり、そのセッションは続行不能になりました。回復手段は「セッションを捨てて新しく始める」だけです。実際、私はそうしました(「実測値」の表のセッションB がそれです)。

⇒ ⭐ 単発の失敗より、失敗が回復手段そのものを壊す形のほうが痛い。 互換 API を長時間のエージェント運用に使うなら、ここは事前に知っておく価値があります。

公式の記載と、実測の対応表

公式の記載 実測で現れた形
画像入力には対応していません 400 {'type': 'string_type', 'loc': ('body','messages',N,'content','str')}
マルチターン会話には対応していません テキストのみなら10ターン通った。(後述)
現在ご利用いただけるモデルは preview/Kimi-K2.6 のみ Claude Code の /model 表示も preview/Kimi-K2.6 (effort: high)
無償枠は1ヶ月あたり3,000リクエスト 61分回して消えたリクエストは十数本。枠は全く減らない

「マルチターン会話には対応していません」については、実測のほうが少し違う顔を見せました。テキストだけのやり取りなら、10ターン・入力9.6万トークンまでは普通に通っています。 なので体感としては「拒否される」ではなく「保証されない」に近い。ただし保証されていない以上、長い会話で急に壊れても文句は言えない——実際、壊れたのは会話が伸びた後でした。

ここは私の解釈です([Judgment])。公式が非対応と書いている以上、通ったことを根拠に「使える」と読み替えるべきではありません。 私の観測は「今日のこの回はここまで通った」までです。

コスト構造の話 — 枠は減らないが、トークンは積む

このイベントは「3,000リクエスト使い切りチャレンジ」です。私はむしろ、使い切れないことのほうに驚きました。

  • 61分のエージェント作業で消えたリクエスト: 十数本
  • そのとき投げた入力トークン: 81.8万

コーディングエージェントは「1リクエストがやたら重い」使い方をします。会話の全履歴+ファイルの中身+ツール定義を、毎ターン丸ごと送るからです。しかもプロンプトキャッシュが効かない(実測で cache_read_input_tokens が全ターン 0)ので、同じ 146KB を何度も何度も送り直す

使い方 リクエスト数 1リクエストあたりの入力
チャットボット的な単発利用 多い 小さい
コーディングエージェント 少ない 極端に大きい

「月3,000リクエスト無償」という枠は、エージェント用途に対しては実質的にほぼ無制限に見えます。逆に言えば、枠を使い切りたいなら単発のリクエストを大量に投げる使い方のほうが向いている。今回の私の使い方は、イベントの趣旨からするとかなり効率の悪い枠の減らし方でした(そのぶん、互換の境界はよく見えました)。

じゃあ、どう使うのが良さそうか

今回の実測から言える範囲で、向き・不向きを書きます。

向いていそう

  • ローカルで完結する読解・要約・変換(ファイルを読んで整理する、ログを解析する)
  • ツール定義が少ない、短い単発のタスク
  • 「壊れても捨てられる」使い捨てセッション

現状きつい

  • Web 検索・Web 取得を伴う調査(サーバー側ツールが通らない)
  • スクリーンショットや PDF を投げる作業(画像入力が通らない)
  • 何時間も続ける長丁場のエージェント作業(キャッシュ無し+コンパクション不能)

私の運用で言えば、「調べもの」を任せるのは今は無理で、「手元のファイルを読ませる」なら十分実用、という切り分けになりました。無償枠でここまで試せるのは、正直かなりありがたいです。

おまけ: 「復元できません」と答えたその隣に、答えはあった

最後に、私が一番おもしろかった観測を。

セッションが 400 で詰んだあと、私は新しいセッションを立てて(もちろんモデルは同じ preview/Kimi-K2.6)、こう聞きました。「~/.claude を読んで、さっき落ちたセッションを解析できるか?」

モデルは ~/.claude/sessions/*.json を見つけ、中身がメタデータだけであることを確認し、こう結論しました。

session-env も空でした。(中略)実際のメッセージ履歴は VSCode の内部ストレージ(SQLite等)にあります。そのため、このファイルシステム上のファイルだけから「どのファイルを読んで・何を生成しようとしてエラーになったか」は復元できません

これは誤りでした。 会話の全文は ~/.claude/projects/<cwd をエンコードしたディレクトリ名>/<sessionId>.jsonl に、1行1イベントの JSON Lines でそのまま残っています。この記事の数字は、全部そこから採ったものです。

ここで言いたいのは「Kimi-K2.6 が劣る」ではありません(探索が1箇所届かなかっただけで、sessions/*.json の判断自体は正しい)。言いたいのはこちらです。

⇒ ⭐ AI が「できません」と結論したとき、それは「探した範囲には無かった」であって「無い」ではない。 適用範囲を確かめるのは、いつでも人間側の仕事として残ります。今回はたまたま、その教訓を、その教訓を実演した当のログから拾い上げるという形になりました。

計測方法(再現用)

数字の出どころを書いておきます。Claude Code のセッションログはこの場所にあります。

~/.claude/projects/<cwd をエンコードしたディレクトリ名>/<sessionId>.jsonl

1行1イベントの JSON Lines で、typeassistant の行に message.usageinput_tokens / output_tokens / cache_read_input_tokens / cache_creation_input_tokens)と message.model が入っています。集計は Claude Opus 5 に PowerShell を書かせて実行させました(本記事の数字はすべてこの出力です)。

count-usage.ps1
$o = Get-Content $path | ForEach-Object { try { $_ | ConvertFrom-Json } catch {} }
$u = $o | Where-Object { $_.type -eq 'assistant' -and $_.message.usage }

# モデル別のターン数
$o | Where-Object { $_.type -eq 'assistant' } |
     ForEach-Object { $_.message.model } | Group-Object

# 入力・出力・キャッシュの合計
($u | ForEach-Object { [int]$_.message.usage.input_tokens })            | Measure-Object -Sum
($u | ForEach-Object { [int]$_.message.usage.output_tokens })           | Measure-Object -Sum
($u | ForEach-Object { [int]$_.message.usage.cache_read_input_tokens }) | Measure-Object -Sum

エラーになったターンは message.model<synthetic> になり、本文にエラー文字列がそのまま入ります。この記事に引用した 400 の逐語は、すべてこの行から採ったものです。

セッションログはそれが生成されたマシンにしか無く、既定では一定期間で自動削除されます。他マシンから同じ数字は出せません。実測を残したいなら、そのマシンで、消える前に集計してください。

まとめ

  • さくらのAI Engine の Anthropic 互換 API は、Claude Code から普通に使えた。 テキストのエージェント作業は10ターン通った
  • ただし「互換」の境界は3箇所ではっきり出た——サーバー側ツール(Web検索)/画像・PDF 入力/長い会話の圧縮
  • 一番痛いのは3つ目。エラーが自動コンパクションを巻き込んで、セッションが回復不能になる
  • 公式は最初から「画像入力とマルチターン会話には非対応」と書いている。 私が持ち帰ったのは、その一文がどんなエラー文字列として現れるかという翻訳です
  • 無償枠3,000リクエストは、エージェント用途では減らない。 減るのはトークンと時間のほう

プレビュー版のモデルに、実運用のドキュメントを丸ごと投げつけるという乱暴な使い方をしましたが、壊れ方まで含めて無償枠で観測できたのは収穫でした。仕様書の一文を、自分の環境のエラー文字列に翻訳しておくと、次に同じ壁に当たったとき5分で判断できます。

この記事の作り方について。 本文の下書きは Claude Opus 5 に書かせています。ただし数値はすべてセッションログから機械的に集計したもので、何を載せ何を落とすかの判断は筆者が行いました。AI に書かせるほど、採否を決める回数のほうが増える——というのが、今回もそうでした。


参考

1
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?