AIコーディングエージェントを使っていて、料金にびっくりした経験はありませんか？
簡単なタスクを頼んだだけなのに、想像以上のコストがかかっていた。
そんな話をよく耳にします。
先日、Redditでこの問題に取り組んだ投稿を見つけました。
ある開発者が、自作のCLIエージェントを公開したのです。
このツールは、DeepSeekのプレフィックスキャッシュを前提に設計されています。
そのため、リポジトリ全体を解析させても、コストは約0.02〜0.03ドルで済むとのこと。
どんなツールなのか
投稿者が公開したのは、Python製のCLIエージェントです。
コーディングと一般的なPC作業の両方をこなします。
ライセンスはMITです。
そして、重い依存関係はありません。
面白いのは、最初からDeepSeekを軸に設計されている点です。
理由は2つあると投稿者は述べています。
1つは、最後の1行まで自分が理解できるエージェントが欲しかったから。
もう1つは、DeepSeekの料金体系が「良い意味で異常」だからです。
実際の数字も公開されていました。
対象は、投稿者自身のコードベースです。
規模は約7,000行のコードと、2,600行のテストスイート。
これに対して「全部読んで解析して」という処理を実行しました。
入力トークンは約47万に達します。
それでも、コストは0.02〜0.03ドル程度で収まったそうです。
なぜそんなに安いのか。
キャッシュヒット率が75〜80%に達しているからです。
秘密は「追記専用」の会話履歴
このコスト効率を支える仕組みは、意外なほど地味です。
投稿者自身も「退屈なトリックだが、効く」と表現していました。
会話履歴を追記専用にする。
これだけです。
DeepSeekのコンテキストキャッシュには、有効に働く条件があります。
プロンプトの先頭部分（プレフィックス）が一致していることです。
逆に言えば、履歴の途中を1箇所でも書き換えると、キャッシュは無効になります。
そして、全額を払い直す羽目になるのです。
コメント欄でも、この点に共感する声がありました。
途中を編集した瞬間に、プレフィックスが崩れる。
すると、フルプライスに戻ってしまう。
だからこそ、ツールの実行結果を書き換えずに追記し続けることが本質だという指摘です。
コンテキストの圧縮（コンパクション）も、この原則に従います。
要約を履歴の途中に差し込むのではなく、末尾に追記するのです。
具体的な仕組みについては、コメント欄で質問が出ていました。
投稿者の回答によると、要約の対象はコンテキスト全体です。
ただし、直近の2〜3メッセージは除きます。
そして、独立したLLM呼び出しで要約を作成します。
その要約は、システムプロンプトや固定メモリと一緒に配置されます。
この配置により、以降もキャッシュに乗り続けるわけです。
精度の低下は避けられません。
しかし、圧縮の閾値は設定ファイルで自由に調整できるとのことでした。
LLMを呼ぶ前に、決定論的な掃除をする
もう1つ興味深いのが、要約の前に走る「決定論的な刈り込み」です。
考えてみてください。
エージェントが同じファイルを2回読んだら、古い方の読み取り結果はもう不要ですよね。
ファイルを読んだ後に上書きした場合も同じです。
このツールは、そうした「確実に不要になった」ツール出力を機械的にスタブ化します。
LLMを呼ぶ必要はありません。
つまり、API料金ゼロでコンテキストの空きを確保できるわけです。
さらに、ツールの並列実行にも対応しています。
モデルが複数の読み取り専用ツールを一度に要求した場合、それらを同時に走らせるのです。
派手な機能ではありません。
しかし、地道な積み重ねがコストと速度の両方に効いてくる好例でしょう。
実用面での作り込み
エージェントとしての中身も紹介しておきます。
主な特徴は以下の通りです。
- 対話型のREPLに加えて、スクリプトから使えるワンショットモードを搭載
- エージェントは2種類（プロジェクトルート内に閉じたコーディング用と、マシン全体を扱う汎用）で、自動で使い分け
- セッションの記憶は、手で編集できるプレーンなMarkdownファイルとして保存
- 破壊的な操作には、差分プレビュー付きの承認ゲートが介入
- 無人実行にはコストの上限を設定可能
- オフラインテストは525本
開発はWindowsファーストで進められました。
cmdが複数行スクリプトを壊すためです。
そこで、PowerShell専用のツールまで用意されているそうです。
Linuxでも問題なく動きます。
ただし、macOSは未検証とのこと。
対応プロバイダは、DeepSeekとOpenAI互換のAPIです。
OpenAIでも動きます。
しかし、長時間セッションで同じ低コストは期待しないでほしいと投稿者は釘を刺していました。
制限も正直に開示されています。
メンテナは1人。Anthropicプロバイダは未対応です。
また、WebフェッチはJavaScriptをレンダリングしません。
コード内のコメントはイタリア語で書かれています。
ただし、これは意図的な選択です。
ユーザーとモデルが目にする部分は、すべて英語になっています。
コメント欄で起きた「公開レビュー」
この投稿で一番面白かったのは、実はコメント欄でした。
あるユーザーがコードを軽く眺めて、鋭い指摘を投げます。
DeepSeekのAPIには、推論の深さを指定するreasoning_effortパラメータがある。
しかし、このツールは思考モードを有効化するフラグしか送っていない。
つまり、最大レベルの推論をずっと使い損ねているのではないか、と。
投稿者の反応が痛快でした。
指摘は完全に正しかったのです。
プロジェクトを始めたのは、このパラメータの登場前でした。
そのため、古いAPI仕様の名残がそのまま残っていたのです。
しかも、調査の過程で潜在的な挙動まで発覚します。
高速モデルが、ひっそりと推論を続けていたのです。
投稿者はその日のうちに修正しました。
そして、推論の深さを設定ファイルで調整できるようにしています。
さらに、別のユーザーとのやり取りでは、もう1つの課題が見つかりました。
推論モードが、各ターンの最初のステップにしか適用されていなかったのです。
この点についても、投稿者は改善を約束しています。
オープンソースで公開した数時間後に、他人の目でバグと改善点が洗い出される。
公開レビューの価値を象徴する流れだと感じました。
個人プロジェクトが信頼を得る難しさ
一方で、厳しい意見も寄せられていました。
毎週のように、似たCLIエージェントが投稿される。
その中で、なぜこれを選ぶべきなのか。
既存の有名ツールには多数のコントリビューターがいて、リリースも頻繁です。
だから、個人の情熱プロジェクトを日常のワークフローに組み込むのはリスクが高い。
採用してほしいなら、性能とコストで圧倒する証拠を見せるべきだ。
そういう趣旨の指摘です。
再現可能なベンチマークを設計すべきだという提案もありました。
他のツールとの比較結果を、数字で示すべきだというのです。
なぜなら、人は証拠がなければ知名度の高いツールを選び続けるからです。
投稿者の返答には、個人開発者としての割り切りが表れていました。
巨大なコードベースと数十人の開発体制を持つツールを「圧倒」するつもりは、最初からない。
売り物ではなく、オープンソースとして公開しているだけだ。
その代わり、コードベースは約8,000行と小さい。
だから、誰でもすぐ読める。
フォークして、自分好みに改造することも簡単だ。
そこに価値を置いている、と。
大規模ツールの機能競争とは、別の軸で勝負する。
この姿勢は、個人開発のあり方として1つの答えだと思います。
「AIに書かせた」ことへの葛藤
もう1つ、印象的なやり取りがありました。
投稿者は正直に明かしています。
このツールの大部分は、ClaudeやGPTといった高性能モデルとの協働で書かれたものです。
自身はアーキテクチャの監督に徹しました。
そのため、手でコードを書いた量は多くありません。
中には、このツール自身に自分のコードをレビューさせた部分すらあるそうです。
これに対して、あるコメントが共感を呼びました。
この数ヶ月、自分もほとんどコードを打っていない。
AIに書かせて、レビューするだけになった。
スピードについていくには仕方ない。
しかし、自分のコーディングスキルが鈍っていくのが怖い、と。
投稿者も、同じ恐怖を抱えていると認めました。
その上で、自分なりの対策を語っています。
LLMが生成したものを、できる限り徹底的に読み込む。
そして、理解する。
それが緩和策だと。
ただし「自分のツールを使うときは、正直そのまま走らせることもある」と笑い混じりに付け加えていました。
この葛藤に、完璧な答えはまだありません。
しかし、生成されたコードを読んで理解する習慣が防波堤になる。
この感覚は、多くの開発者が共有できるのではないでしょうか。
まとめ
このReddit投稿から学べるポイントを整理します。
まず、キャッシュ設計はコスト構造を根本から変えます。
会話履歴を追記専用に保つ。
この地味な原則だけで、47万トークンの処理が数セントに収まりました。
エージェントを自作するなら、プレフィックスキャッシュを壊さない設計を最初から意識する価値があります。
次に、LLMを呼ばずに済む処理はLLMに任せないこと。
不要になったツール出力の刈り込みが好例です。
決定論的に判断できる部分を機械的に処理すれば、コストゼロでコンテキストを節約できます。
そして、早めの公開が開発を加速させるという事実です。
推論パラメータの見落としは、公開したからこそ発見されました。
公開しなければ、発見はもっと遅れていたはずです。
個人開発のエージェントが、大規模ツールに正面から挑む必要はありません。
小さくて読める。すぐ改造できる。
この価値は、それ自体が差別化になります。
AIエージェントの内部構造に興味があるなら、こうした小規模なオープンソース実装を読んでみましょう。
設計判断の1つ1つが、手の届く範囲に見えてくるはずです。
巨大なツールでは、なかなか追いきれない部分です。
