AIの利用枠がすぐ減るので測ってみたら、「作業の締め」が一番重かった

AIエージェントのトークン消費をどう減らすか、という話を最近よく見る。トークンは、AIが読み書きする量の単位で、使った分だけ利用枠が減っていく。処理の組み方を変えて大きく減らした、利用枠が切り替わる時刻を工夫した、といった話だ。多くは、エージェントを何十、何百と並べて動かす人たちの話で、自分の使い方とは規模が違う。

自分は月額の利用枠の中で、1人分のAI秘書を毎日回している。朝の計画を立てる、1日の記録を残す、作業の終わりに片付けをする。その程度の使い方だ。それでも利用枠に当たったことはある。それ以来、高機能のモデルはなるべく使わないようにして、別のAIも併用して使う量を分散している。

枠の中で回す側にとって、重いというのは、待ち時間の長さと、枠が減る早さのことだ。

以前、毎朝読ませるタスク管理のファイルが膨らんだとき、測ってから直した話を書いた。今回はその2回目になる。重かったのは、朝ではなく終わりの処理だった。

前回のおさらい。測ったら、犯人が違った

前回は、毎朝の提案がおかしくなったのがきっかけだった。終わったタスクが溜まっているせいだと思って、掃除する前に大きさを測った。終わったタスクは全体の5パーセントほどしかなかった。重かったのは、進行中のタスクの下に積み上がった経緯のメモだった。置き場所を分けたら、約9万8千バイトから約2万5千バイトになった。

今回は重さを測る道具があった

いま使っているAIエージェントには、スキルと呼ばれる定型作業の指示書ごとに、直近7日間でどれだけトークンを使ったかを出す診断機能がある。それを走らせてみた。

一番重かったのは、作業の終わりに動かしている締めの処理(終了処理)で、7日間で約2,110万トークンだった。

終了処理が重くて毎回待ちきれずに止めていた、と以前書いた。その処理が、数字でも一番重いものとして出てきた。

数字を見て、まず驚いた。なんでこんなに、と思った。知らない間にこれだけ使われていたのなら、枠に当たっていたのもこれが一因だったのか、と思った。すぐに原因を調べたくなった。

考えてみれば、重くなる条件はそろっていた。終了処理は、1回の作業のまとまり(セッション)の最後に動く。そのときには、それまでのやりとりの履歴が一番膨らんでいる。そこへさらに、記録を残すために複数のファイルを読みに行く。

犯人はスキル本体ではなく、スキルが読みに行くファイルだった

測る前は、枠が減る原因として特定の処理を疑ってはいなかった。開発などいろいろな用途に使っていたから、そのぶん枠が減ったのだと思っていた。ふだんの使い方では、トークンを抑える工夫もしていた。前回と同じで、当たりが外れた。

原因を分けると2つあった。

– 終了処理という仕組みそのもの。さっき書いたとおり、履歴が一番膨らんだところで動く

– 終了処理が読みに行くファイルが大きかった。進行中のタスクの経緯メモが約205キロバイト、AIの失敗を記録しているファイルが約120キロバイトあった

終了処理の指示書そのものは約30キロバイトで、重さの主な原因ではなかった。

数字を読み違えかけた

途中で、数字の読み違いも起きかけた。

診断結果を読んだAIが、終了処理が7日間で140回動いている、1日20回のペースで、意図せず起動しているかもしれない、と報告してきた。ところが直後に、AI自身がその報告を取り消した。140回という数字の列には、7日間という区切りは付いていなかった。隣の列に付いていた7日間という注記を、そのまま借りて読んでいた。

そこで、数字が出て異常だと思ったら、原因を探しに行く前に、まず読み方が合っているかを確かめる。これをAIの運用ルールに足した。

削った順番は、ファイルが先で、スキルが後

手当ては、読みに行く先のファイルから始めた。

そのタスクの詳細は、いまどこまで進んだかだけを書くファイルに切り替えた。経緯の全文は別の場所へ移した。約205キロバイトが約4キロバイトになった。AIの失敗記録は、7月以前の28件を別の場所へ移した。約120キロバイトが約65キロバイトになった。どちらも消してはいない。置き場所を変えただけだ。

そのあとで、終了処理の指示書も削った。29.7キロバイトから19.0キロバイトにした。

– 起動時に済ませた確認は、終了時にやり直さない

– 変更履歴を管理する仕組みを入れていない場所では、そのためのコマンドを打たない

– 同じ注意書きが4か所に書いてあったのを、1か所にまとめる

軽くしても、残したかったものがある。外部へ送る前や、ファイルを削除・編集・移動する前に止まって確認する部分だ。書く前にその場で確かめる、保存を確かめてから保存したと言う、といった確認の手順も削らなかった。

軽くしたあと

軽くしたのは9月14日で、その日は、次回の終了処理で動きを確認する、と書いて終えた。

その後、軽くした終了処理はふつうに動いて、記録を残している。体感でも軽くなった。終わるまでの時間も、前より明らかに短くなったと感じる。正直ほっとした。一方で、一度作った仕組みも、ときどき測って見直さないといけないと思った。

ただ、軽くしたあとの2回目の診断はまだ走らせていない。何トークン減ったのかは、数字ではまだ分からない。

前回は、朝に読むものが重かった。今回は、最後に読むものが重かった。2回とも、主に削ったのはスキルではなく、スキルに読ませているファイルのほうだった。ファイルの中身は消さず、置き場所を変えただけだ。

共有フォルダや引き継ぎ資料でも、同じことが起こりえます。古いファイルが溜まっているせいだと思いがちですが、実際は、毎日開く資料に「これまでの経緯」が書き足され続けて、重く読みにくくなっていることがあります。自社ではどこが重いのか、測るところから整理したい方は、まずは無料相談でいまの状況をお聞かせください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

CAPTCHA


目次