Claude Code × Ollamaのコンテキスト上限を整理する — 1Mモデルが200kに縮む3つの原因と解法

Claude Code と Ollama を組み合わせると、1Mコンテキストのはずのクラウドモデルが200kで勝手に圧縮される。公式の案内どおり [1m] をモデル名に付けると、今度は ollama launch が「invalid model name」で起動すらしない。原因は1つではなく、1Mという値を決めるレイヤーが3つあり、それぞれが別の場所で値を決めている。起動時に出る警告は、未知のモデルIDに対してClaude Codeが200kを仮定していることを示す。解決策は、CLAUDE_CODE_MAX_CONTEXT_TOKENS=1048576 をaliasに足す1行だ。ollama show で確認すると、glm-5.3:cloud のcontext lengthは1048576と申告されている。 この問題の正体が面白い。Claude Code側には最初から2本の道が用意されていたのに、[1m] の記法はランチャーの名前検証で弾かれ、環境変数だけが子プロセスに継承されて届く。公式の記法が抽象化レイヤーを1枚挟んだ瞬間に上層へ届かなくなる、典型的な罠である。「公式どおりにやったのに動かない」の正体は、設定の書き間違いではなく経路の違いだ。モデルは1Mの能力を持っているのに、エージェント側の仮定で5分の1に縮められている。その状態を警告を読み流して見逃すのが、一番怖い。だからこそ、設定の数字は記事の言葉ではなく、ドキュメントの定義と起動時の表示で確かめるべきだ。 用途ごとに設定は使い分けられる。上限を宣言する環境変数、圧縮の発火位置を決める CLAUDE_CODE_AUTO_COMPACT_WINDOW、上限の判断をAPIのエラーに任せてエラーが出てから圧縮に入る設定などがある。逆方向の問題として、8kから32k程度のローカルモデルもClaude Codeからは200kと見なされ、実際の上限を超えるリクエストを投げてしまう。CLAUDE_CODE_MAX_CONTEXT_TOKENS の本来の主用途はこちらだという。 中小企業の実務では、社内でモデルを繋ぎ替えるとき、そのモデルの上限が本当にいくつかを最初に確かめるべきだ。起動時の警告を読み流すと、高性能なモデルを小さな枠で使い続けるか、逆に上限を超えてエラーに悩まされる。数字は宣伝文句ではなく、起動時の表示と実測で確かめる。