AIエージェントのコストを下げたいとき、あなたはまず何をしますか？
多くの人がプロンプトの圧縮から始めます。
指示を短くして、例を削る。
そして、システムプロンプトを磨き上げる。
私もそれが王道だと思っていました。
ところが先日、Redditのプロンプトエンジニアリング系コミュニティで興味深い投稿を見つけました。
この常識を揺さぶる内容です。
プロンプトを削っても効果が出なかった理由
投稿者は、複数のサイトから毎日データを取得するエージェントを運用していたそうです。
コスト削減のために、指示を絞りました。
例も減らしました。
さらに、システムプロンプトも圧縮しています。
しかし、得られた効果はごくわずかでした。
転機は、トークンの内訳を実際に確認したときに訪れます。
コストの主犯はプロンプトではありませんでした。
ナビゲーションだったのです。
具体的には、以下がトークンを大量に消費していました。
- DOMのダンプ
- スクリーンショット
- ボタンの位置をモデルが毎回推論しながら探す過程
しかも、そのボタンは前回の実行ですでに見つけていたはずのものです。
丁寧に最適化した指示文は、これらと比べれば誤差程度のトークン量にすぎなかったといいます。
繰り返しタスクにおいて、探索は知性ではなく無駄である
投稿者はこう気づきました。
繰り返し実行するタスクでは、探索は無駄なコストになる、と。
考えてみれば当然です。
モデルは毎朝、同じ6つの手順を「再発見」していました。
そして、その再発見のたびに料金が発生していたわけです。
賢いモデルに毎回考えさせること自体が、目的化していないでしょうか。
一度分かったことを何度も考え直させる。
これは、知性の使い方として明らかに非効率です。
解決策：探索を一度きりのコストに変える
では、どうしたか。
投稿者のアプローチはシンプルでした。
まず、サイトの探索は最初の一度だけ行います。
次に、その結果を名前付き引数を持つ呼び出し可能なコマンドにコンパイルします。
以降、モデルはページそのものを受け取りません。
構造化された出力だけを受け取るのです。
投稿ではwebcmdというツールを使ったと書かれていました。
Apache-2.0ライセンスで、npmでインストール可能とのことです。
ただし投稿者自身も、ツールよりパターンの方が重要だと強調しています。
副次効果：プロンプトが本来の仕事に戻る
個人的に面白いと感じたのは、この変更がプロンプトに与えた影響です。
ナビゲーションがコンテキストから消えると、プロンプトは本来のタスクだけを語れるようになります。
例えば、Cookieバナーの処理方法。
あるいは、セレクタが見つからないときの対処法。
そうした指示を書く必要がなくなるのです。
つまり、プロンプトの圧縮に悩む前に、やるべきことがあります。
そもそもプロンプトで扱うべきでない情報を追い出すこと。
この順番が正解でした。
コメント欄から得られた知見
この投稿には、示唆に富むコメントが付いていました。
あるコメントは、こう指摘しています。
決定論的なタスクを繰り返すなら、AIに自動化の作成を手伝わせるべきだ、と。
推論が必要な部分だけAIに任せます。
そして、それ以外は自動化に引き渡す。
この役割分担が肝だという意見です。
別のコメントは、スクリプト化がトークン削減の最も効果的な手法のひとつだと述べていました。
しかも、利点はコストだけではありません。
決定論的な部分は毎回同じように動きます。
そのため、出力の再現性も上がるのです。
エージェントに毎回任せていては、この安定性は得られません。
落とし穴：静かに壊れる
いい話ばかりではありません。
投稿者は、弱点も率直に共有していました。
コンパイルした経路は、サイト側が変更を加えた時点で古くなります。
厄介なのは、その壊れ方です。
エラーを出して止まるのではありません。
自信満々に間違うのです。
つまり、もっともらしい誤ったデータが返ってきます。
スキーマ検証を入れれば、データの形が変わったケースは検出できます。
しかし、形は正しいのに中身がゴミというケースは素通りしてしまう。
投稿者も、この問題への決定打はまだ見つけていないと書いていました。
導入する場合は、この「静かな劣化」を前提にしてください。
そのうえで、監視の仕組みを考えておくべきでしょう。
まとめ
今回のRedditの投稿から学べるのは、視点の転換です。
コンテキストの中身を圧縮するより、コンテキストから追い出せるものを探す。
その方が効く場合がある、ということです。
繰り返しタスクにおける探索は、一度きりのコストに変換できます。
探索結果をコマンド化すれば、モデルは推論すべき部分だけに集中できます。
そして、プロンプトも本来のタスク記述に戻ります。
結果として、トークン削減と出力の安定性の両方が手に入るわけです。
ただし、コンパイルした経路は静かに壊れます。
だからこそ、検証と監視をセットで設計してください。
あなたのエージェントにも、毎回同じことを再発見している処理が潜んでいないでしょうか。
トークンの内訳を一度眺めてみてください。
意外な主犯が見つかるかもしれません。
