PicoClawモデルが見つからない404：モデルIDとAnthropicプロトコル

PicoClawでは、「model not found」と404は4種類の異なる障害であり、そのうちマシンの外部で発生するのは1つだけです。 3つはローカルで発生します。解決できないエイリアス、PicoClaw自身のWebバックエンドが返す404、未知のプロトコル文字列です。4つ目は上流404で、その本文がルートの誤りかモデルIDの誤りかを示します。まずエラーテキストを読むことで、タイプミスを直すためにプロトコルを切り替える事態を防げます。

このページでは、動作するmodel_listエントリーとキーをすでに持っていることを前提とします。セットアップ自体とPicoClawの料金については、PicoClawの料金とAPIセットアップで説明しています。以下はすべて、リリース済みタグv0.3.1で確認した内容です。リリースAPIでは、2026年9月21日時点の最新タグであり、2026年7月3日に公開されたことが確認されています。リポジトリへの最終プッシュは2026年9月17日だったため、mainはタグより先行しています。関係する場合はその旨を記載します。2026年10月1日時点でもv0.3.1が最新リリースであり、そのリリースバイナリをローカルの記録エンドポイントに対して実行し、意図的に無効なキーを使ってKunavoに対しても実行しました。その結果を以下に記録します。

4つの障害、1つの表現

したがって、リクエストがマシンの外へ出たかどうかを最初に確認する必要があり、文字列だけで判断できます。エイリアスの不一致は仮説ではなく、実際に報告された事例です。PicoClaw issue #958ではerror creating provider: model "llama3.2" not found in model_listが報告され、picoclaw statusによってOllamaエンドポイントに到達でき、モデルがllama3.2:latestとして存在することが示されました。2026年3月25日にリポジトリのstale-issue botによってクローズされました。このリポジトリでは、クローズされたissueにcompletedと付いていても修正済みを意味しない点に注意してください。同じbotが#1624を同じ文言でクローズしています。

ラッパーのテキストは、実際に実行されたプロトコルを示します

APIキーを使うanthropicとanthropic-messagesでは異なるプロバイダーが構築されるため、404のラッパーも異なります。つまり、エラー文字列自体が診断情報になります。

PicoClaw自身の404に関する助言が誤った方向へ導く理由

PicoClawのプロバイダーガイドは、「既存のanthropicプロトコルが404エラーを返す（エンドポイントがOpenAI互換形式をサポートしていないことを示す）」場合にanthropic-messagesへ移行するよう指示し、命名を確定させる注記として次を加えています。「anthropicプロトコルはOpenAI互換形式（/v1/chat/completions）を使用し、anthropic-messagesはAnthropicのネイティブ形式（/v1/messages）を使用します。」両方の引用を2026年9月21日にv0.3.1で再確認しました。

この助言はルート404には正しく、モデル404には誤りです。また、この助言は同じファイル内の表の294行下にあります。その表では、anthropic行のProtocol列にAnthropicと記載されており、逆のことを述べています。コードは分かりにくい形で矛盾を解消します。anthropicはauth_methodによって異なる2つのプロトコルです。 oauthまたはtokenの場合はネイティブAnthropic SDKプロバイダーを構築するため、表が正しくなります。APIキーの場合は、openaiとその一族が使うものと同じOpenAI互換プロバイダーにフォールスルーするため、注記が正しくなります。

2つの帰結が直接導かれます。openaiファミリーでは、https://api.kunavo.com/v1ではなくhttps://api.kunavo.comと記述するとhttps://api.kunavo.com/chat/completionsが組み立てられます。これは自分の設定が原因のルート404であり、最も一般的なものです。両方のAnthropicプロトコルでは/v1がどちらの場合も強制されるため、その間違いは起こりません。しかし同じ強制により、パスの末尾が/v1であってはならないゲートウェイは、これらのプロトコルでは表現できず、代わりにopenaiプロトコルを使う必要があります。PicoClaw自身の文書では、ベースが異なるバージョンセグメントで終わるベンダーに対して、この回避策を使っています。

未確定として扱うべき主張が1つあります。PicoClaw issue #269の唯一のコメントは、正しいエンドポイントが/v1/messagesであるため、Anthropicでは/v1/chat/completionsへのPOSTが404を返すと主張しています。しかしAnthropic自身の文書はこれと矛盾します。同文書は、base_urlをhttps://api.anthropic.com/v1/とするOpenAI SDK互換レイヤーを公開し、authorizationヘッダーを「Fully supported」としています（2026年9月21日確認）。一方で同じページ上で、このレイヤーは「ほとんどのユースケースにとって長期的または本番対応のソリューションとは見なされない」と注意しています。issue #269は2026年3月13日にクローズされ、クローズコメントはありません。issues APIに表示されるコメントは1件だけで、リポジトリとの関連付けがないアカウントによる上記の分析です。したがって、実際に何によって解決したのかは不明です。どちらの説明よりも、自分の404レスポンス本文を信頼してください。

404がモデルIDの場合

PicoClaw issue #1624は、2026年3月16日に開かれ、2026年3月31日にクローズされました。"model": "anthropic/claude-sonnet-4.6"として設定されたドット付きClaude IDについて、正確なレスポンス本文を記録しています。Status: 404で、{"error":{"code":"not_found_error","message":"model: claude-sonnet-4.6 was not found. Did you mean claude-sonnet-4-6?"…が含まれています。タイトルと唯一のコメントは2026年9月21日にissues APIから再確認しました。コメントはstale botによるもので、issueはクローズされていますが、修正された証拠はありません。

「もしかして」のヒントが決め手です。これはリクエストを解析したエンドポイントからしか返らないため、ルートは機能しており、プロトコルを変更しても解決しません。PicoClawが表記を自動修正しない理由は、限定的で確認可能です。strings.ReplaceAll(model, ".", "-")はリポジトリ内に1回だけ存在し、pkg/providers/anthropic/provider.goの219行目です。これはOAuthおよびtokenパスで使われるSDKプロバイダーです。anthropic_messages/provider.goにもopenai_compat/provider.goにも含まれていません。両方の記述を2026年9月21日にv0.3.1で再確認し、このページに先立つ調査でも同日にmainから同じファイルを再取得して同じ結果になりました。2026年10月1日にv0.3.1バイナリを実行し、両方のAPIキーパスで確認しました。ドット付きIDは記述どおりエンドポイントに到達し、エンドポイント自身の404として返されました（v0.3.1の実行結果を参照）。書き換えがある唯一のパスであるOAuthおよびtokenパスは実行していません。

PicoClaw自身のファイルでも表記が食い違っています。provider_metadata.goは両方のAnthropicエントリーにハイフン付きIDを列挙し、プロバイダーガイドのanthropic例はドット付きIDを使い、anthropic-messagesはGetDefaultModelからドット付きのデフォルトを返します。これは#1624で拒否された表記と同じです。Anthropicのモデル概要に表示されるClaude API IDはすべてハイフンを使い、同ページではClaude Sonnet 4.6とClaude Opus 4.6を「Legacy models (still available)」に掲載しています。したがって、現在Anthropicで4.6 IDが404になる理由は廃止ではありません。これは1つの原因を排除するだけで、すべての原因を排除するものではありません。ハイフン付きIDでも、モデルを持たないゲートウェイでは拒否される可能性があります。READMEではなく、呼び出しているエンドポイントからIDをコピーしてください。

両方のエントリーを明示的に記述し、IDはハイフン付きのままにしてください。このファイルにキーは記述しません。PicoClawはキーを~/.picoclaw/.security.ymlから読み込みます。詳しくはセットアップガイドを参照してください。

{
  "agents": {
    "defaults": {
      "model_name": "kunavo-sonnet"
    }
  },
  "model_list": [
    {
      "model_name": "kunavo-sonnet",
      "provider": "openai",
      "model": "claude-sonnet-4-6",
      "api_base": "https://api.kunavo.com/v1"
    },
    {
      "model_name": "kunavo-sonnet-native",
      "provider": "anthropic-messages",
      "model": "claude-sonnet-4-6",
      "api_base": "https://api.kunavo.com"
    }
  ]
}

最初のエントリーでは、OpenAI互換ファミリーがapi_baseに/chat/completionsをそのまま連結するため、/v1自体を指定しています。2番目では意図的に省略し、anthropic-messagesではどちらの表記も同じベースに正規化されることを示しています。Kunavoの公開ベースURLは、チャット補完用にhttps://api.kunavo.com/v1、Messagesルート用にhttps://api.kunavo.com/v1/messagesです。2組のURL計算が一致することは、2組の文書にまたがる計算結果です。2026年10月1日には、両エントリーをv0.3.1からKunavoに対して、意図的に無効なキーで実行しました。openaiエントリーは/v1/chat/completionsに到達し、anthropic-messagesエントリーは/v1/messagesに到達し、それぞれKunavoの401を受け取りました。これはURLを証明するものであり、リクエストが完了したことを意味しません。このページではテスト済みの統合を主張していません。ベースURLに関する一般的な形式については、AnthropicのベースURL文書を参照してください。

ゲートウェイが意図的に404を返す場合もあり、それはPicoClawのバグではありません。Kunavoは一時停止中のモデルに対して404を返し、本文にモデルと代わりに使用すべき置換モデルを示し、/v1/modelsから一時停止中のモデルを除外します。どのモデルが一時停止されるかは変わるため、特定の名前ではなく、そのメッセージの形式に合わせてください。Kunavoはembedding、text-to-speech、speech-to-textモデルも提供していません。そのため、それらのいずれかを指定するmodel_listエントリーは、どのプロトコルを選んでも404になります。そのエントリーを別のプロバイダーに向け、Kunavoキーではチャットエントリーだけを使用してください。

v0.3.1の実行結果

2026年10月1日、リリース自身のchecksumsファイルと照合してチェックサムを検証したv0.3.1リリースバイナリを、使い捨てコンテナ内で、model_listエントリーを1つずつ指定してpicoclaw agent -mを実行しました。エンドポイントは当時のKunavoのルーティングと同様に動作するローカル記録サーバーでした。/v1/*がAPIで、その他のパスはHTML 404ページを返しました（Kunavoは現在、それらのパスに修正方法を示すJSON 404を返します。Kunavoの行を参照してください）。また、claude-sonnet-5とclaude-sonnet-4-6は認識しますが、ドット付きIDは認識しません。最後の3行では実際のapi.kunavo.comを使い、意図的に無効なキーを指定したため、そこで課金は発生していません。

この実行によって、ソースの読解だけでは予測にとどまった2点が確定しました。エラーラッパーは実際に実行されたプロバイダーを示すため、そこからプロトコルを読み取って安全です。また、ドット付きIDは両方のAPIキーパスで変更されずに送信されるため、ドット付きIDを引用する「model not found」は、プロトコルを切り替えるのではなく、IDの表記を直すことで解決します。対象外なのは、OAuthおよびtokenパス、ランチャーのWeb UI、ストリーミング、Kunavoを通じて完了したリクエストです。Kunavoの行では意図的に無効なキーを使用しました。

最短の確認順序

1. マシンの外へ何か出ましたか？ HTTPステータスなしでnot found in model_listを含むターミナルエラーはローカルのものです。agents.defaults.model_nameをmodel_nameエントリーと同じにして、そこで止めてください。
2. localhost からのものでしたか？ PicoClaw の Web UI でデフォルトモデルを選択中にブラウザーで表示される 404 は、PicoClaw 自身のバックエンドが提供する同じ不一致です。モデル API は関与していません。
3. どのプロバイダーが実行しましたか？ ラッパーテキストを上の表と照合してください。ラッパーが設定したと思っているプロトコルと一致しない場合、providerフィールドまたはモデルプレフィックスが想定と異なります。
4. ルートの 404 ですか、それともモデルの 404 ですか？ モデル名を含む本文、特に did you mean というヒントがある場合はモデルの 404 です。ID を修正してください。HTML ページ、空の本文、または汎用的な not-found はルートの 404 です。他のことをする前に、表から組み立てられた URL を再導出してください。
5. エンドポイントが提供しているものを確認します。 PicoClaw はどちらの Anthropic プロトコルでもこれを実行できません。どちらのカタログエントリにも fetch フラグが設定されていないためです。ゲートウェイ自身の /v1/models に対して curl を使用するか、同じゲートウェイを一時的に openai プロトコルに向けてください。プロバイダー間でモデルが見つからないではその方法を、Anthropic 404 モデルが見つからないでは ID 自体に問題があるケースを扱っています。
6. ここで初めてプロトコルを変更します。しかも、手順 4 でルートの 404 だと判定された場合だけです。ワイヤーフォーマットではなく認証ヘッダーが障害になっている場合は、認証トークンと API キーの違いでその分岐を説明しています。
7. 通常のチャットターンではなく、1 回のツールラウンドで再検証します。 単純なメッセージに応答する設定でも、最初のツール呼び出しで失敗することがあります。そのため、修正を確認するために使う限定タスクには、ツール呼び出しを 1 つ含めてください。

プロトコルの選択によって生じるコスト

最大のコスト上の影響はプロンプトキャッシュであり、設定ではなく構造によるものです。PicoClaw v0.3.1 では、キャッシュブレークポイントを出力するコードは pkg/providers/anthropic/provider.go にのみ存在し、OAuth とトークンのパスからのみ到達します。API キーを使う、通常の自分のキーを持ち込むケースでは、どちらの Anthropic プロトコルも cache_control を送信しません。Anthropic 自身の互換レイヤーに対しては、そのドキュメントが「プロンプトキャッシュはサポートされていませんが、Anthropic SDK ではサポートされています」と明記しているため、影響がさらに重なります。OpenAI 形式の呼び出し元に対してゲートウェイがブレークポイントを挿入する場合は、ゲートウェイ側で節約が回復します。Kunavo の キャッシュに関するドキュメントは、これを行うこと、そして対象が /v1/chat/completions または /v1/responses を介して到達する Claude モデルであることを正確に示しています。同じページには、cache_control がネイティブ Messages ルートでは変換されずにそのまま通過するとあります。したがって、anthropic-messages エントリはどちら側からもブレークポイントを取得せず、以下の 2 列目は openai プロトコルのエントリのみを説明しています。他のゲートウェイがブレークポイントを挿入するかどうかは確認しておらず、これらのいずれも PicoClaw 内部から観測したものではありません。

ここでの価値は、測定されたタスクコストでも請求額の上限でもなく、説明用のトークン計算です。1 回のエージェントターンが 10 回のツールラウンドで構成され、各ラウンドで同じ 20,000 トークンのプレフィックス（システムプロンプト、ツールスキーマ、そこまでのトランスクリプト）を再送し、1,000 個の新しい入力トークンを追加し、600 個の出力トークンを返すと仮定します。これらの比率は説明のための仮定です。1 列目では各ラウンドの入力を全額のレートで請求し、2 列目では 2 ラウンド目以降、繰り返されるプレフィックスをキャッシュ読み取りレートで請求します。レートは 100 万トークンあたりのKunavo カタログの最新価格です。

これらの仮定では、Claude Sonnet 4.6は同じ作業に対して$0.504から$0.164に変わります。2 列目は楽観的な値として読んでください。キャッシュ書き込みは独自のレートで請求され、どちらの方向にもモデル化されていません。また、ラウンドごとにプレフィックスが変化する場合、キャッシュヒットには一度もなりません。いずれも予算として扱う前に、1 日あたりのターン数を掛けてください。

その間、2 つの請求を分けて考えてください。PicoClaw 自体は無料です。リポジトリは MIT ライセンスで提供されており、購入が必要なものによって、Anthropic の 2 つのプロトコルを含むどのプロトコルも制限されていません。継続的に発生するコストは、プロバイダーのレートによるモデルトークンです。Kunavo のカタログ金額は上限ではなく請求下限です。アップストリームが料金を報告すると、請求額はカタログコストと、適用されるマークアップを掛けたアップストリームコストの大きい方になります。前払いクレジットの最低チャージ額は$10です。これはタスク料金やサブスクリプションではなく、資金投入の最低額です。請求の詳細を参照してください。

直接ベンダー、ゲートウェイ、サブスクリプション、またはローカル

ルートではなくランタイムを選んでいますか？PicoClaw と OpenClaw の比較では、デプロイ形態を比較しています。ゲートウェイを選び、キーに資金を投入したい場合は、Kunavo アカウントを作成してから、ツール呼び出しを含む限定タスクを 1 つ送信し、アカウントに実際に記録された料金を確認してください。

よくある質問

2026 年 9 月 21 日に確認。今回のタスクではタグ v0.3.1 で再検証しました。プロバイダーガイドのプロトコル注記と Anthropic ベンダー行、factory_provider.go の anthropic ブランチとデフォルトアーム、NormalizeBaseURL、anthropic-messages の URL、ヘッダー、404 文字列、openai_compat の URL 連結と Bearer ヘッダー、HTTP リクエスト前の 3 つの「not found in model_list」文字列、Web バックエンドの 404、ドットからハイフンへの置換が 1 箇所だけ存在すること、プロバイダーオプション表の SupportsFetch 列、docs/operations/troubleshooting.md の OpenRouter 例を確認しました。さらに、リリース API（v0.3.1、2026 年 7 月 3 日公開）と、Issue #1624、#958、#269 のタイトル、状態、日付、コメントも確認しました。Anthropic の OpenAI-SDK 互換性ページも同日に読みました。2026 年 10 月 1 日に実行：コンテナ内の v0.3.1 リリースバイナリをローカルの記録エンドポイントに対して、また無効なキーを使用して Kunavo に対して実行し、上の表のすべての行を確認しました。未検証：調査で差分を比較したファイル以外の main 上のすべて、Issue #269 がクローズされた理由、OAuth とトークンのパス、Kunavo 経由で完了したリクエスト。Kunavo のトークンレートは最新カタログから取得しており、ここに示すすべてのドル額は説明用のトークン計算です。