Claude Codeの上限に、Kimi K3という別経路をつくる｜LP制作で実測した費用とつまずき‼️

こんにちは！AIクリエイターのinstkoniです。

Claude Code を毎日仕事に使い倒している副業クリエイターで、並行してYoutubeでAI音楽チャンネル「異世界の音楽家 / AI Motion Musics」も運用しています。

【記事概要をPodcastでも聴けます‼️】

さて、Claude Codeを使い込んでいると、「今週の上限」がリセットを待たずにイベントボスのように唐突にやって来る日があります💦

あなたならどうしますか⁉️
僕ならその時の選択肢として下記があると思っています。

今回はその3つ目の道において、「Kimi K3」という中華製LLMで試した体験記事になります🎵

似たようなことは過去に下記の記事で行っていますので、気になる方は、ぜひご覧ください‼️

上限に当たった日に、急がない仕事を逃がす経路としては、検討する価値があると考えています。

もしかすると、「Proプランの方は、MAXにアップするまでもなくKimiのAPIを使うほうが選択肢として優先度が高くなるかも」しれません。

第１章：「5時間／週間上限」に当たったとき、あなたはどれを選ぶ⁉️

ここからは、上限に当たった瞬間に取れる行動を、使い方のパターン別に整理していきます。

🔵 上限を超えた先は、 ”基本的には” 従量課金の世界

ClaudeのPro／Maxでは、ClaudeとClaude Codeの利用量が「同じ上限に数えられます」。

チャットで使った分も、Claude Codeで使った分も、同じ財布から出ていくイメージです。上限は5時間ごとにリセットされます。

🟢 取れる行動は5つ

🟠 パターン別の選び方

どれを選ぶかは、「外部のAPIに出してよい仕事か」「いまのプラン」「どれくらい上限に当たるか」の3つで決まります👇

この記事は、主にDとEの方が「Kimiに切り出すか」を判断する材料です。

第２章：同じLPを、3モデルに作らせてみた‼️

ここからは、今回の実測の土台になった「LP制作」の比較を見ていきます。

🔵 同じ発注書で、3モデルに1回ずつ

題材は、僕のAI音楽MV「AIna004」の作品ページです。

前作AIna003のLPページをお手本にして、3モデルにまったく同じ発注書（BRIEF.md）を渡しました。

しばらくして出来上がったものを比較しました。
見本があれば、どのモデルも違いが出ないくらい精巧なものができます✨

同じ発注を各1回ずつ成功させて、Claudeで採点用の別エージェントをたてて社内の採点表で採点させてみました✨

結果はこちらです🎵

🟢 点数より、強みの違いが出た

🟠 3モデルとも、同じところでつまずいた

共通の欠点もありました。お手本のCSSをそのまま流用した見出しが、パソコンの画面幅で「オーバーヒー」と「ト」のように、単語の途中で折れていました。

モデルを替えても、お手本そのものの弱点は消えません。

そこで、この折れを直す仕事をあらためて3モデルに頼みました。
結果は第４章で紹介します。

この章のまとめです。

第３章：単価表では読めなかった、実費の逆転💰

ここからは、いちばん気になる費用の話です。

🔵 単価表だけ見ると、Sonnetのほうが安く見える

Kimi K3の公式価格は、100万トークンあたり、キャッシュヒットの入力0.30ドル、キャッシュミスの入力3.00ドル、出力15.00ドルです。

一方のSonnet 5は、入力2ドル、1時間キャッシュの書き込み4ドル、キャッシュの読み込み0.20ドル、出力10ドル。
入力も出力も、Sonnetのほうが安い項目が多いです。

🟢 完成した1本では、順番が入れ替わった。

ところが、第２章のLPを1本完成させた回で比べると、順番が入れ替わりました。

ここで比べているのは、両方の実際の請求額ではないです。

Claude Codeはサブスクで動かしたので、6.23ドルは「同じ量を標準のAPI単価で払ったら」の換算です。

逆転した理由は、「キャッシュ読み込み」です。

今回の仕事では、Sonnetのキャッシュの読み込みが約2,055万トークンまで膨らみました。

さらにClaude Codeは1時間キャッシュで書き込むので、その書き込みは入力単価の2倍で数えられます。

単価表が嘘ではなく、「仕事の中身によって、請求に変化がでる」ということです。

🟠 ただ・・・失敗した回まで数えると、Kimiのほうが高くついた

ただし、ここで「Kimiが安い」と終わらせるというのは少し誇張があるかもしれません。

実際にLPが完成するまでに、失敗と作り直しもありました👇

僕の雑な指示のせいだと思いますが、ここは他の方でも「あるある」かと思いますので、留意点として残しておきます。

長い仕事をいきなり渡さず、「先に小さく試して発注書を固める。」この順番を守れば、Kimi K3は十分に強いモデルだと感じました。

第４章：見出しの折れを直させたら、合格したのはKimiだけだった‼️

ここからは、第２章で見つかった「見出しの折れ」を、3モデルにコードで直してもらった結果です。

🔵 直してもらったのは、LPのコード

対象は、第２章でSonnet 5が作ったLPの index.html 1枚です。このファイルの中に、ページの骨組み（HTML）、見た目の指定（CSS）、動きの処理（JavaScript）が全部入っています。

折れていた原因は、このあたりのコードでした👇

/* 見出しを入れる枠（横幅は最大560px） */
.hero .in{ width:min(560px,92vw); padding:0 clamp(20px,5vw,64px); }
/* 見出しの文字（最大64px） */
.hero h1{ font-size:clamp(34px,6.4vw,64px); }

<!-- 見出しの中身（手で改行を入れていた） -->
<h1>熱帯夜の<br>オーバーヒート</h1>

見出しの枠は横幅が最大560px。
左右の余白を引くと、文字を置ける幅は430pxほどしかありません。

そこに64pxの大きな文字で7文字の「オーバーヒート」を置くと、最後の「ト」だけが次の行に落ちます。

しかも「熱帯夜の」のあとに手で改行（<br>）を入れていたので、題名を変えると改行位置がずれてしまう作りでした。

🟢 頼んだことと、合否の決め方

3モデルには同じファイルを渡して、次の4つを頼みました。

合否は、走らせる前に固定した判定テストで機械的に決めました。

画面の幅6通り×題名5通り（元の題名と、差し替え4つ）×ブラウザ2種類で、カタカナの途中で改行していないか、見出しがはみ出していないか、書体と大きさを保っているか、ほかの節を変えていないかを確かめます。

🟠 3モデルは、コードのどこを変えたか

3モデルとも、「CSSで枠を少し広げる」ところまでは同じでした。違ったのは「どこで改行させるか」を決めるJavaScriptの書き方です👇

Opus 5とSonnet 5は、ブラウザに入っている「日本語を単語に区切る機能」（Intl.Segmenter）で題名を単語に分け、単語と単語の間に「ここなら改行してよい」という印（<wbr>）を入れました。Sonnet 5のコードはこうです。

const seg=new Intl.Segmenter('ja',{granularity:'word'});
for(const s of seg.segment(h1.textContent)){
  frag.appendChild(document.createElement('wbr'));  // 単語と単語の間に「改行してよい」印
  frag.appendChild(document.createTextNode(s.segment));
}

Opus 5はこれに加えて、1単語でも枠に入りきらないときは文字を小さくする処理も書いています（69行と、3モデルでいちばん多く書き換えました）。

Kimi K3は発想が逆でした。

CSSで「日本語の途中では改行させない」（keep-all）と指定し、Chromeにしかない「文節で改行する」指定（auto-phrase）は、対応しているブラウザでだけ効くように書き分けています。

.hero .in{ width:min(640px,94vw); padding:0 clamp(20px,4vw,44px); }
.hero h1{ word-break:keep-all; overflow-wrap:normal; }
@supports (word-break:auto-phrase){
  .hero h1{ word-break:auto-phrase; }
}

そのうえで、JavaScriptで枠からはみ出したときだけ、文字を少しずつ小さくする処理を足しました。

function fitHeroTitle(){
  heroTitle.style.fontSize='';                 // まず元の大きさに戻す
  let fs=parseFloat(getComputedStyle(heroTitle).fontSize);
  // 枠からはみ出している間だけ、少しずつ文字を小さくする（最小18px）
  for(let i=0;i<30 && heroTitle.scrollWidth>heroTitle.clientWidth+1 && fs>18;i++){
    fs=Math.max(18, fs*(heroTitle.clientWidth-1)/heroTitle.scrollWidth);
    heroTitle.style.fontSize=fs+'px';
  }
}
fitHeroTitle();
addEventListener('resize',fitHeroTitle);            // 画面幅が変わったら測り直す
document.fonts.ready.then(fitHeroTitle);           // 書体の読み込み後にも測り直す

🟣 結果：合格したのは、Kimi K3だけ

Kimi K3は7分35秒で完走し、実費は1.36ドル。

判定テストもすべて合格しました。Opus 5は30往復の上限で途中終了（直したファイルは保存されていたので判定にかけています）、Sonnet 5は完走したものの不合格。費用はAPI換算で11.37ドルと3.47ドルです。

Opus 5とSonnet 5も、元の題名「熱帯夜のオーバーヒート」はきちんと直せています。落ちたのは他のタイトルでも再現ができる「汎用性」という観点でした。

各1回ずつの結果で、判定テストを書いたのも、LPを採点したのもClaudeです。

第５章：Kimi For CodingとOpen Platformを混ぜると、最初から詰まる💦

ここからは、実際にKimiをClaude Codeへつなぐときの手順と注意点です。

🔵 入口は2つ。先にどちらを使うか決める

いちばん混乱したのは、名前がよく似た2つの入口です。
Open PlatformのKimi APIと、会員向けのKimi Code（Kimi For Coding）は、別の製品として扱われています。

キーも接続先も別なので、片方で発行したキーをもう片方に向けてもつながりません。

📚Open PlatformのKimi APIを使う場合👇

📚Kimi Code（定額）を使う場合👇

🟢 設定を書くのは settings.json

設定は、Claude Codeの settings.json の env という欄に書きます。

すべてのプロジェクトで使うなら、ホームフォルダの下にあるこのファイルです👇

特定のプロジェクトだけKimiに切り替えたいときは、そのプロジェクトの中の .claude/settings.local.json に書く方法もあります。

こちらは自分専用の設定なので、Gitにコミットしない前提のファイルです。

同じ場所の .claude/settings.json はチームで共有する設定なので、APIキーは書かないでください。

Open Platformの場合は、こう書きます（値はすべてダミーです）。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.moonshot.ai/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_MOONSHOT_API_KEY",
    "ANTHROPIC_MODEL": "kimi-k3[1m]"
  }
}

Kimi Codeの場合は、接続先とキーの欄の名前が変わります。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.kimi.com/coding/",
    "ANTHROPIC_API_KEY": "YOUR_KIMI_CODE_API_KEY",
    "ANTHROPIC_MODEL": "k3-256k"
  }
}

どちらも、公式ガイドの例をもとにしています。バージョンやガイドの更新で変わることがあるので、コピーする前に必ず最新のドキュメントを開いてください。

🟠 書いたら、古い設定を消してから再起動

もう1つ詰まりやすいのが、「前に設定した値が残っている」ことです。

シェルの設定ファイル（~/.zshrc など）や、デスクトップアプリ側に ANTHROPIC_ で始まる古い設定が残っていると、settings.json に書いた内容より優先されてしまうことがあります。

僕の環境でも、デスクトップアプリから引き継いだ接続先が勝っていました。古い設定を消してから、Claude Codeを再起動してください。

ちなみに kimi-k3[1m] の [1m] は「100万トークンの文脈」の印で、Claude Codeが読み取ったうえで、送るときには外すようです。

実際に中継のログを見ると、送られているのは kimi-k3 というモデル名でした👇

🔴Kimiをつないだら、チャットの返事ではなくログで確かめる

設定できたら、次は「本当にKimiにつながったか」を確かめます。ここで僕は、3回見誤りました。

設定が完了して、エージェント動作はしているように見えた。

計算の答え、確認用の合言葉、それらしい答えが返ってきた。どれも「動いている感」はあったのに、中継のログを見ると、Kimiへのリクエストは0件でした。

正しい返事は、どこにつながっているかの証拠にはならないんです。外部モデルとの接続時に確かめるのは、この3つだけでした👇

🟣 身を守るためのルールをちゃんと守りましょうね

最終章：上限の外に、もう一本だけ道をつくる‼️

最後に、ここまでの結果を、実際の使い方に落とし込んで締めくくります。

🟣 個人的な見解と今後の使い方

僕は、Kimi K3をClaude Codeの上限の日に作業を止めないための別経路として使っていきます。

すべてを切り替えるのではなく、まずは急がない独立した仕事を、サブエージェントに切り出すところから始めます。

実際に使ってみて、ワーカーとしてAPIで使うなら、Kimi K3はかなりアリだと感じました。日本語の文章も悪くありません。

一方で、Claudeの全面代替とは思っていません。本線の判断や締切が近い仕事はClaudeで進め、検証とレビューの手順を用意できる仕事だけを、別の予算枠へ逃がす。この役割分担が、いまの僕にはいちばん現実的です。

🔵 渡すなら、仕事の種類で振り分ける

第１章のDとEの方が実際にKimiを使うときは、全部を一気に切り替えず、仕事の種類で分けるのがおすすめです👇

ここでいう「渡せる仕事」は、失敗しても気づけて、やり直せる仕事です。

渡す前に、最初は小さな仕事で使ってよい上限額を決める、誰がチェックするかを決める、それから長い仕事を渡す。この順番を守れば、月の出費も読みやすくなります🎵

🟢 今回の比較検証でわかったこと

つまり、Kimi K3は「Claudeより安い代わりのモデル」ではありません。使い方しだいで安くも高くもなる、もう一本の道です。

接続は返事で判断せずにログで確かめる、APIキーは慎重に扱う、最初は小さな仕事で試す。この3つを守れるなら、上限に当たった日の心強い逃げ道になります。

次に上限の警告が出たら、まず仕事を分けてみてください。

待つべき本線なのか、usage creditsで続けるべきなのか、小さく試した別経路へ逃がせる仕事なのか。

その判断ができるだけで、上限は「制作が止まる合図」ではなくなります‼️

最後までお読みいただき、ありがとうございます‼️

さて、あなたは第１章のA〜Fのどのパターンでしたか⁉️
ぜひ、コメントであなたの意見を聞かせてください‼️

この記事が少しでも「役に立った！」と思っていただけたら、「スキ」を押していただけると、次の記事を書く大きな励みになります‼️