「AIの利用料金は、そのうち10億トークン単位で表示されるのではないか」
海外の掲示板Redditで、こんな投稿が話題になっていました。
投稿者は、DeepSeekのAPIで数十億トークンを消費した利用実績を公開しています。
そこに多くのユーザーが実体験を持ち寄りました。
その結果、興味深い議論が展開されています。
10億トークンあたり約24ドルという世界
投稿の趣旨はシンプルです。
DeepSeekの価格は、あまりに安い。
だから、料金の単位を「100万トークンあたり」ではなく「10億トークンあたり」で表示する最初のAIラボになれるのではないか。
そんな半分冗談、半分本気の指摘でした。
コメント欄では、ある人が実際に計算しています。
投稿者の利用実績から換算すると、10億トークンあたり約23.79ドルだったそうです。
なぜ、ここまで安くなるのでしょうか。
投稿者自身が理由を説明していました。
- もともとの単価が低い
- サーバー側のキャッシュがほぼ完璧に効く
- キャッシュ済み入力の価格が極端に安い
この3つが組み合わさった結果です。
別のユーザーからは、こんな報告もありました。
コーディング用途なら、v4 Flashで入力の96〜98%がキャッシュヒットするそうです。
コーディングエージェントは、同じコンテキストを何度も送信します。
だから、キャッシュとの相性が抜群に良いわけです。
「安い」は本当に安いのか
ただし、議論は「DeepSeek最高！」で終わりませんでした。
むしろ、ここからが本題です。
最初に釘を刺したコメントが印象的でした。
10億トークンを消費すること自体は、誰にでもできる。
問題は、そのトークンが効率的に使われたのかどうか。
それとも、力任せの試行錯誤で浪費されたのか。
そこが問われるべきだ、という指摘です。
これに対して、投稿者は正直に認めています。
トークンの大半は、エージェントの挙動に関する研究に費やされたそうです。
つまり、仮説の検証です。
そして、ブレイクスルーはまだ得られていない、と。
コスト論争は、さらに白熱します。
あるユーザーは、Claudeで計画を立てさせてDeepSeekに実装させる構成を試しました。
すると、ガードレールをきちんと設定すれば、Claude Sonnetの数十倍安く済んだと主張しています。
Claudeでは、50ドルを使って14フェーズ中2フェーズしか進みませんでした。
しかし、DeepSeekに切り替えたところ、1フェーズあたり0.22〜0.35ドル程度で済んだそうです。
一方で、真っ向から反論する人もいました。
安いモデルは、バグを埋め込むことがある。
エッジケースを見逃すこともある。
そもそも、目標を達成できないケースも見てきた、と。
1ドルと30分をかけて、動かないものを作る。
それなら、最初から賢いモデルにお金を払う方が客観的に得だという主張です。
請求書の数字だけを見ていないか。
時間と成果物の価値を無視していないか。
そんな問いかけでした。
この反論を補強するコメントも秀逸でした。
「DeepSeekはどんな状況でも安い」という意見に対して、こう返したのです。
それは、タスクを完遂できる場合の話だ。
ランダムな文字列生成器は、DeepSeekよりさらに安い。
しかし、仕事が終わらないなら意味がない、と。
つまり、トークン単価の比較だけでは何も分かりません。
あなたが評価すべきなのは、成果物1つあたりの総コストです。
そこには、失敗のやり直しも含まれます。
さらに、あなた自身の時間も含まれるのです。
非エンジニアの成功事例
とはいえ、安さが武器になる場面は確実にあります。
スレッドには、説得力のある体験談が投稿されていました。
その人は、プログラマーではありません。
職場で使う古いシステムを置き換えるのが目的でした。
そこで、Claudeに設計と計画を任せます。
そして、実装作業の大半をDeepSeekに振り分けました。
過去半年で作った3つのデータベースのデータ統合も含む案件です。
結果は、どうだったか。
約4億トークンを消費して、動くシステムが手に入りました。
かかった費用は、6ドルと月額20ドルのClaudeサブスクリプションだけ。
作業期間は、通常勤務の1週間足らずでした。
プログラマーを雇う余裕のない組織にとって、これは大きな意味を持ちます。
役割分担が鍵だったのでしょう。
設計や計画には、高性能なモデルを使う。
物量が必要な実装には、安価なモデルを使う。
この使い分けが、コストと品質のバランスを取る現実解になっています。
サブスクリプションかAPIか
もう一つ、実用的な論点がありました。
定額プランとAPI従量課金、どちらが得かという問題です。
月20ドルで、理論上1.7Bトークンまで使える定額サービスがあります。
そちらの方が安い、という指摘がありました。
これに対して、投稿者はこう返しています。
それは、5時間ごとのローリングウィンドウを常に使い切った場合の理論値にすぎない。
そういう時間制限に縛られる使い方は、ストレスが大きい。
自分の利用は波が激しい。
だから、上限を気にせず使えるAPIの方が合っている、と。
これは、あなたの使い方次第で答えが変わる話です。
毎日コンスタントに使うなら、定額プランが有利になります。
しかし、集中して使う日と全く使わない日が分かれるなら、APIの方が気楽でしょう。
キャッシュの誤解とリポジトリ整備
技術的に学びの多いやり取りも紹介しておきます。
「このエージェントツールは、キャッシュヒット率がすごい」という報告がありました。
これに対して、投稿者が訂正を入れています。
ちなみに、この投稿者は効率特化のOSSコーディングエージェントを開発しているそうです。
訂正の内容はこうです。
キャッシュヒットは、エージェントの機能ではない。
サーバー側のキャッシュ基盤の性質だ、と。
エージェントにできるのは、キャッシュを邪魔しないことだけです。
例えば、システムプロンプトに変化しやすいデータを書き込むとします。
すると、キャッシュは壊れます。
良いエージェントとは、余計なことをしないエージェントなのです。
もう一つ、実践的なアドバイスもありました。
リポジトリをAIがアクセスしやすい形に整える。
そこに時間を使うべきだ、というものです。
コードがどう連携しているか、あなたは翌日も覚えているかもしれません。
しかし、モデルは覚えていません。
毎回ゼロから文脈を再構築させるのか。
それとも、構造を辿りやすい形にしておくのか。
この差が、トークン消費に直結します。
まとめ
このRedditスレッドから見えてくるものがあります。
AI利用コストの評価軸が、変わりつつあるという現実です。
トークン単価は、劇的に下がりました。
10億トークンあたり20ドル台という水準は、少し前なら考えられなかった数字です。
個人が月に数十億トークンを消費する時代が、すでに始まっています。
しかし、単価の安さだけを見ていると判断を誤ります。
安いモデルが仕事を完遂できなければ、どうなるか。
費やした時間もお金も、無駄になるからです。
逆に、計画は高性能モデルに任せる。
実装は安価なモデルに任せる。
この分業が機能すれば、驚くほど低コストで成果を出せます。
請求書の金額ではなく、成果物あたりの総コストで考える。
この視点を持てるかどうかが、これからのAI活用の分かれ目になりそうです。
