IronClaw のコンテキスト予算超過：4つのエラー、1つのハードコードされた数値

IronClawの「コンテキスト予算超過」は1つのエラーではありません。この文言を含む異なる4つのエラーバリアントがあり、そのいずれもモデルのコンテキストウィンドウではありません。また、設定ファイル、環境変数、CLIフラグのいずれでも、それらの背後にある数値は変更できません。予算はコンパイル時に組み込まれた128,000トークンで、20,000トークンの予備があります。これを圧迫する3つのレーン、つまりアイデンティティファイル、スキルスニペット、ツールスキーマは、その許容量の中に収められるのではなく、追加で積み重ねられます。これはこのページの仮説ではなく、IronClaw自身の未クローズの不具合報告に記載されている内容です。

名称が混同されやすいため、1点明確にしておきます。これはNEAR AIのRustエージェントランタイムであるgithub.com/nearai/ironclawです。この名称で商用検索の大半を占めるCorsairのゲーミングマウスでも、エージェントソフトウェアを販売しOpenClawとも比較している無関係なironclaw.techの企業でもありません。IronClawとOpenClawの比較で、その線引きを詳しく説明しています。以下のソースレベルの数値はすべて、2026年9月21日にGitHub contents APIを通じて、mainのコミットb0b999d時点のソースから読み取りました（コミット日は2026年9月10日）。このコミットは、2026年8月28日に公開されたironclaw-v1.4.0リリースタグより後のものです。2026年10月1日には、より新しいironclaw-v1.4.1リリースバイナリ（2026年9月29日公開。予算変更の記載がない、Google OAuthとWasmtime向けのパッチ）をローカルのテストエンドポイントに対して実行しました。その実行結果は以下に記録しており、そのバージョンに限定されます。一方、ソースの数値はコミットに限定されます。

確認している「コンテキスト予算超過」の種類

これはRustのthiserror表示文字列であり、ログとエラー詳細に現れるものです。正確な文言を読むと、どのレーンが失敗したかが分かります。

実際のモデルのオーバーフローについてユーザーに表示される内容には、これらの語は1つも含まれません。ホストが作成する失敗の表示文は、「The run failed because the model context was too large. Retry with a shorter request or start a new thread.」という固定文です。また、モデルゲートウェイがプロバイダー由来のエラーをマッピングした結果は「model request exceeded its context budget」です。注意点が2つあります。このページではエンドツーエンドの実行を追跡していないため、スキルレーンの失敗が最終的にどのユーザー向け文として表示されるかは確定していません。また、広く繰り返されている「Model request context exceeds the available input budget」という文字列はnearai/ironclawのどこにもありません。これは別のエージェントプロジェクトに属するものであり、このプロジェクトの診断には使用しないでください。

設定できない128,000

PromptContextTokenBudget は3つの定数を提供します。コンテキスト上限128,000トークン、20,000トークンの予約領域、メインループの最大出力値0です。表示可能なトランスクリプトは、上限から最後の2つのうち大きい方を引いた値であるため、108,000トークンとなります。これはファイル内のリテラル値ではなく、デフォルト値から算出した値です。3つ目の項目はテスト以外では割り当てられないため、予約領域は常に固定の20,000です。また、リポジトリ内でテスト以外に構築されるものはすべて単純な PromptContextTokenBudget::default() です。コンパクション戦略に1つ、ループドライバーホストの TextOnlyLoopHostConfig デフォルトに1つあります。異なる値を渡す ::new(…) 呼び出しはすべて #[cfg(test)] モジュール内にあります。

IronClaw自身のIssue #5739 は、タイトルでそのことを述べています。「モデルの context_length を無視し、設定による上書きもない、実効コンテキスト予算はハードコードされた128K」 — 2026年7月6日からオープンのままで、2026年9月21日現在も未解決です。ここから3つの落とし穴が生じます。

• budget.* キーはこの予算を設定するものではありません。 IronClawの 設定ページでは、「予算 — コスト管理」という見出しの下に budget.user_daily_usd、budget.pause_at とその関連項目が記載されており、エージェントの支出上限を設定するものとして説明されています。これらは金銭に関する設定です（そのうち2つの budget.overestimate_factor と budget.default_tz は、ドル金額ではなく、それぞれ乗数とタイムゾーンです）。どの階層のキーにも、コンテキスト上限、予約領域、アイデンティティコンテンツの上限、スキル予算を設定するものはありません。また、公開されている優先順位は「コンパイル済みデフォルト < config.toml < 環境変数 < CLIフラグ」です。そのため、存在しないキーはどこにも存在しません。
• PR #5790 は誤った手がかりです。 タイトルは「ホストファクトリによるプロンプトコンテキスト予算の上書き」を提示しています。APIでは2026年8月27日に merged: false としてクローズされています。
• 修正案はすべて提案段階です。 同じ20,000の予約領域を維持しながらモデルの公称ウィンドウの90%を使用する #8053、および #7976 と #5435 は、確認時点ですべてオープンでした。

サードパーティ製エンドポイントについては、仕組みをさらに一段掘り下げる必要があり、そこが決定的な点です。ModelMetadata.context_length は Option 型であり、LlmProvider トレイトのデフォルト実装は None を返します — 「デフォルトではサイズ情報なしでモデル名を返す」 — また、汎用OpenAI互換アダプターはオーバーライドを定義していないため、このデフォルトを継承します。したがって、カスタムエンドポイントはウィンドウサイズを一切通知しません。IronClawは、モデルが100万トークン対応でも32,000トークン対応でも、トランスクリプト用に108,000トークンを見込みます。また、#8053が読み取ろうとするのは、まさにこの経路では一度も設定されないフィールドです。このエンドポイントの設定方法については IronClawカスタムAPI設定 を参照してください。このページでは予算を扱います。

予算に触れずにプロンプトを埋めるレーン

IronClawのオープンな機能強化Issue #8057 は、2026年9月3日に起票され、確認時点でもオープンでした。ベンダー自身の言葉で仕組みを説明しています。プロンプト予算は「トランスクリプト のサイズだけを決める」一方、アイデンティティコンテンツ、スキルとメモリのスニペット、チャンネルコンテキスト、ツールスキーマは「トランスクリプトの許容量を減らさずにその上へ組み立てられるため、プロバイダーが受け取るリクエストが、ループが遵守していると考える予算を超える可能性がある」とされています。これは出荷済み動作のドキュメントではなく欠陥報告ですが、各レーンが個別には規則どおりに見えるのに、サイズ超過で実行が失敗する理由はここにあります。

ツールレーンは測定可能であり、IronClawは測定しています。93個のツールからなる合成フィクスチャに対するコミット済みベンチマークでは、22個のツールを提示した状態で、推定スキーマトークン数が21,355から3,843へ減少したと記録されています。削減率は82.0%で、リポジトリ内では2.0ポイントの変動許容値と50.0%の下限によって検証されています。これらの数値はテストファイルから読み取ったもので、ここで実行して生成したものではありません。リリース済みバイナリの測定ペイロードは 上のセクションにあり、構成も異なります。93個のツールからなるフィクスチャではなく、デフォルトのツールセットです。これらはフィクスチャに対するIronClaw内部の文字数ベースの推定値として扱ってください。あなたのツールプロンプトの値ではなく、プロバイダーのトークナイザーによるカウントでもありません。ここから確実に読み取れるのは全体的な傾向です。プログレッシブ開示によってスキーマの大部分は除去されますが、どの設定でも除去できない数千トークン規模の下限が残ります。27個のコアツール名はすべての開示モードで提示されるためです。

リリース済み1.4.1バイナリの動作

2026年10月1日、チェックサム検証済みの ironclaw-v1.4.1 リリースバイナリを、一時コンテナ内で実行しました。[llm.default] スロットを openai_compatible プロバイダーに設定し、各リクエストを記録するローカルテストサーバーを指定しました。ironclaw repl を通じて、実行ごとに短いメッセージを1件送信しました。

したがって、リリース済みビルドでは下限が実在します。どの開示モードでも26未満のスキーマは送信されず、IronClaw独自の1トークンあたり4文字という推定では、35,703バイトはあなたの入力が1語も入る前におよそ8,900トークンに相当します。さらにシステムメッセージとアイデンティティメッセージによって約24,000バイトが加わります。これはバイト数に基づく算術であり、プロバイダーのトークン数ではありません。以下で説明するタイプミスの危険性は推測ではなく確認済みです。true は off とまったく同じペイロードを生成し、ツールプロンプトをほぼ倍増させましたが、画面上にはそのことを示すものが何もありませんでした。

ハード予算の制限は、ソースの記述どおりに作動しました。約380,000文字のメッセージはエンドポイントに送信されましたが、約460,000文字のメッセージは、1トークンあたり4文字換算で108,000トークンを超えるため、マシンから外へ出ませんでした。REPLが出力したのは、ステージ Prompt、種別 BudgetExceeded、概要 accepted task exceeds the prompt context token budget を示す警告ログ行だけでした。設定にも環境にも、この予算の境界を変更する設定は見つかりませんでした。スキルレーンのエラー、実モデルのオーバーフロー、Kunavo経由のリクエストは実行していません。

リトライは修正にならず、1つのタイプミスが状況を悪化させる

デフォルトの復旧戦略は、コンテキストオーバーフローを反復単位で 正確に1回、ShrinkContext の変更を伴ってリトライし、その後中止します。ベンダー独自のテスト名は model_context_overflow_compacts_once_then_aborts と second_model_context_overflow_aborts_without_another_compaction です。したがって、同じサイズ超過リクエストでリトライしても成功しません。規模の参考として、同じ戦略のデフォルトでは max_model_availability_attempts: 12 と max_attempts_per_class: 2 が許可されています。この種別には単一のShrinkContext試行が適用されます。

コンパクションも、それより前には救済になりません。トリガーしきい値は同じ108,000であるため、トランスクリプトがそこに達する前にコンパクションを強制するものはありません。強制コンパクションと復旧コンパクションはサーキットブレーカーを迂回するため、これはリトライ前にサイズ超過したプロンプトを縮小するループ唯一の方法です。代替戦略には注意が必要です。2026年7月3日からオープンのIssue #5582 は、ActiveTaskPreservingCompactionStrategy がオーバーフローフラグを決して読み取らないと報告しています。特定のデプロイでどの戦略が選択されるかは、ここでは追跡していません。

何より先に確認する価値のある設定上の危険があります。プログレッシブツール開示は REBORN_TOOL_DISCLOSURE から読み取られ、off | compact | signatures | namespaces | bridged を受け付け、未設定または空の場合は namespaces がデフォルトになります。その他の空でない値（タイプミス、古い true、または on）はすべて、通知なく Off に解決されます。同じファイルではこれを「対照群：認可されたすべてのスキーマを提示する」と説明しています。UTF-8以外の値も同じ結果になります。唯一のシグナルは tracing::debug! のログ行で、ツールプロンプトが大幅に大きくなります。綴りを推測せず、変数の設定を解除してください。

現在実際に変更できること

コンテキスト予算、コンパクション、またはこれら4つのエラーを扱う公開済みIronClawドキュメントページはありません。そのため、以下の手段はドキュメントとコードが共同で裏付けるものであり、ベンダー公認の解決策ではありません。

スキルコンテキストの負荷を減らす、文書化された唯一の手段は環境変数ではなく設定フラグです。IronClawの スキルページでは、[skills] の下に設定するよう記載されており、キーワードとタグによる有効化、および明示的な $my-skill メンションでもスキルが注入されると説明されています。

[skills]
# Documented lever: stops regex auto-activation from loading full skill
# context. Keyword/tag activation and $my-skill mentions still inject skills.
regex_activation_enabled = false

さらに3つありますが、それぞれ制限があります。同じドキュメントページによると、スキルの max_context_tokens フロントマター・フィールドのデフォルトは2000です。ただし、そこに小さい値を書いても大きなスキルは縮小されません。本文の推定値が宣言値の2倍を超えると、セレクターは「実際の推定値を使用」とログに記録し、測定されたサイズを計上します。リアクティブルーチンは allowed_tools を通じてツールの範囲を絞れますが、これはそのルーチンに限定され、対話ターンには適用されません。また、ファイルツールは ALLOW_LOCAL_TOOLS=true の場合を除いて無効です。IronClawのファイルツールドキュメントでは、ホスト環境や共有環境での「意図しないファイルシステムアクセスを防ぐため」、デフォルトで無効と説明されています。無効のままにすれば、プロンプト内のスキーマが1組減ります。これら3つはいずれも128,000を変更しません。

最後に、古い数値を前提に計画しないでください。Issue #7485 は、108,000トークンの予算がASCIIコンテンツでは「実質的に約54k実トークン」であり、コンパクションが「約2倍早く」発生すると報告しました。これは2つあるトークン推定器の一方で二重カウントが発生していたためです。PR #7502 で両者が統合され、2026年8月11日にマージされました。GitHubのcompare APIによると、マージコミットは v1.3.0 と v1.4.0 のタグ内、および main 内にあります。v1.2.0 と v1.1.0 との比較は「diverged」を返すため、それを含む最初のリリースは確定していません。v1.3.0以降と記載してください。現在の単一の推定器は、ASCIIを1トークンあたり4文字、3バイトの非ASCII文字をおよそ1.5トークンとして計上します。つまり、CJKの多いトランスクリプトは英語よりはるかに速く108,000を消費します。

コンテキスト上限まで使った場合の1ターンあたりのコストと、最も有利な経路

これは測定されたタスクコストでも請求上限でもなく、説明用のトークン計算です。最大負荷の1ターンを想定します。トランスクリプトは上限の108,000トークン、アイデンティティのコンテキストは8,000トークン、スキルコンテキストは4,000トークン（セレクターのデフォルト予算。構成されたランタイムで6,000を設定している場合は、これが増加します）、さらに上記の記録済みベンチマークでモデルに提示されたツールスキーマは3,843トークンです。合計で 123,843 推定入力トークンとなり、さらに 2,000 出力トークン が加わります。これらは合成フィクスチャに対するIronClaw独自の推定値であるため、実際のプロバイダーのトークナイザーによる値とは一致しません。料金は100万トークンあたりの最新の Kunavoカタログ 価格です。

最後の列がこのセクションの要点です。REBORN_TOOL_DISCLOSURE の入力ミスにより、17,512 推定入力トークンが すべての ターンに追加されます。Claude Sonnet 4.6 では、他の条件が変わる前から、それだけで1ターンあたり $0.037 の追加費用となり、常時稼働のエージェントは1日に何度もターンを実行します。もう1つ読み取れるのは、これを回避するために長いコンテキストのモデルへ料金を払っても効果がないということです。IronClawはモデルに関係なく独自の数値まで入力を組み立てるため、追加のコンテキストウィンドウには利点がない一方、123,843 トークンすべてに高い単価が適用されます。これらの金額を予算として扱う前に、自分の1日あたりのターン数を掛けてください。

ホスティングプランの行は、2026年9月21日に ironclaw.com から読み取りました。ironclaw.com/pricing はHTTP 404を返すため、プランはホームページにあります。3つのカードすべての上にある見出しは「最大130Mトークン/月でTrusted Execution Environmentに最大5つのエージェントを起動」です。5エージェントはPro+の上限なので、この見出しは個別カードの上限ではなく最上位プランの上限を示しています。また、130Mトークンという数値はどのカードにも表示されていません。含まれるクレジットが何トークンに相当するか、使い切った場合に何が起きるかは公開されておらず、ここでは推測していません。

Kunavoは埋め込み、テキスト読み上げ、音声認識のモデルを提供していないため、設定内の検索または音声処理のステップでは外部プロバイダーを呼び出す必要があります。

試してから請求額を確認する

IronClawの接続先をOpenAI互換ゲートウェイにする場合、Kunavoのchat-completionsエンドポイントは、プロバイダーID openai_compatibleが想定する形式に合致します。これは双方のドキュメントから読み取れるプロトコル上の一致です。上記の10月1日の実行ではKunavoではなくローカルのテストサーバーを使用したため、Kunavoは互換性があるとは主張していません。動作する接続経路を利用可能な状態に保ち、範囲を限定したタスクを1つ実行して、IronClawが独自の計算で表示するコストではなく、アカウントに記録された使用量と照合してください。Kunavoのカタログ記載額は請求額の上限ではなく下限です。上流プロバイダーから料金が報告された場合、請求額は、カタログ上のコストと、上流プロバイダーのコストに適用されるマークアップ係数を掛けた金額のうち、高い方になります。最低チャージ額はプリペイドクレジットで$10です。これは入金額の下限であり、タスク料金やサブスクリプションではありません。請求の詳細を確認し、キーの利用資金をチャージする準備ができたらアカウントを作成してください。関連する選択肢については、AIコスト最適化で完了したタスクあたりのコストの測定を解説しています。また、PicoClawとZeroClawでは、同様にループの長さがコストを調整する要因となる、2つの兄弟ランタイムを取り上げています。

よくある質問

2026年10月1日に実行：ローカルテストサーバーに対して ironclaw-v1.4.1 リリースバイナリを実行し、上記の開示テーブルと予算プローブを確認しました。同日、#5739、#8053、#8057、#7976、#5435のIssue状態を再確認し、すべてオープンでした。2026年9月21日に確認済みです。ソース定数、エラー文字列、復旧戦略、トークン推定器、開示モード、ベンチマークのベースラインは、GitHub contents APIを通じてnearai/ironclawの main ブランチのコミット b0b999d から読み取りました。Issueとプルリクエストの状態はGitHub issues APIから、スキル、設定、ストレージ、ファイルツールのページはdocs.ironclaw.comから、プランカードはironclaw.comから直接取得しました。v1.4.0リリースタグはチェックアウトしておらず、IronClawインスタンスも実行していません。リポジトリ内のテストも実行しておらず、4つのエラーのいずれも発生を再現していません。KunavoもIronClawをランタイムテストしていません。Kunavoのトークン単価は最新カタログから取得し、すべてのドル金額は説明用のトークン計算です。