Hakaru Lab ｜ 公開: 2026-09-06 ｜ 検証記事
対象読者：複数のAIエージェントを自動で並列起動する運用を、すでに行っている実務担当者に加え、これから始めたい方、または導入を判断するために情報収集をしている個人・チームの担当者。
3行要点
・当ラボは、複数のAIエージェントを自動で並列起動する運用で2026年8月に生じた三つの波のトークン消費を、購入記録・当機のローカル実測ログ・当時の運用記録から検証した。直近2日間で約13.8億トークン(ローカル実測)を消費していたことが分かった。原因は複数の要因が重なったことで、詳細は②で述べる。
・複数のAIエージェントを自動で並列運用している実務担当者と、これから始めたい、または導入を判断するために情報収集をしている個人・チームの担当者が、自分の運用に同じ抜け穴がないか照らし合わせる判断材料になる。
・確定している金銭的事実は、Max(20倍)定額プランの週次上限を当該週の初日午前中に使い果たし、当ラボとして初めてクレジットの前払い購入を行ったことであり、追加購入の累計$1,760にはその後の意図した検証作業での消費も含まれるため消費事象そのものの金額とは区別できない。結論は2026-08-31時点の検証にもとづく。
検証の前提
・検証日：2026-08-31
・利害関係：本記事に広告リンクはありません
うまくいった話より、うまくいかなかった話の方が、他の人の役に立つことがあります。本記事では当ラボ自身の運用そのものを検証対象にし、8月にかけて起きた三つの波を、購入記録・当機のローカル実測・当時の運用記録から裏取りしなおしました。固有の製品名やチーム内部の呼び方は伏せていますが、消費量の数字と、そこから作った仕組みの中身は、実際の記録のまま載せています。
開示方針
当ラボは、読者の判断に必要な事実・根拠・不確実性を、確認できた範囲で開示します。実測・運用者の観察・推定を区別し、証拠の強さを超えて断定しません。安全・契約・プライバシーに関わる情報は一般化または非公開とし、省略が結論に影響する場合は明記します。誤りが判明した場合は訂正履歴を残します。
複数のAIエージェントを自動で並列起動する、当ラボの情報収集の運用で、8月にかけて規模の異なるトークン消費が三度ありました。当ラボではこれを第1波・第2波・第3波と呼んでいます。波ごとに裏付けとなる証拠の種類が異なるため、以下では波ごとに何で確認できているかを明記します。
第1波(7月下旬〜8月初旬)——証拠：購入記録(領収書)と当時の運用記録。トークン量そのものは実測不能。
確定して言えるのは、Max(20倍)の週次定額プランの週次上限を、当該週の初日午前中にはすでに使い果たしていたことです。当ラボはこの時、初めて追加のクレジットを前払いで購入しました。この期間に行った追加購入は合計3回・税込$1,760(領収書で確認)ですが、この金額にはその後の意図した検証作業などでの消費分も含まれており、第1波の消費そのものに起因する金額として切り分けることはできません。当時のワークフロー実行ログはローカル集計ツールの保持期間(約30日)を超えており、本記事の裏取り作業を行った時点(2026-08-31)ではすでに消失していたため、第1波で実際に何トークン消費していたかは実測値として提示できません。
今回の核心の教訓
証拠は30日で消える——測りたくなった時にはもう遅いということです。日次で記録する仕組みを先に作っておくしかありません。この教訓は、本記事の裏取り作業そのものが実演する形になりました(④で詳述します)。
第2波(8/11-12)——証拠：当機のローカル実測。
当ラボの作業機で稼働しているローカル集計ツール(ccusage。コーディングエージェントCLIのトークン使用量とコストをローカルログから分析するツールです)の記録によると、8/11・8/12の2日間で合計およそ13.8億トークンを消費していました。API単価換算(実際の請求額ではなく、トークン量に単価を掛けた推定値)ではおよそ$1,500相当にあたります。直前の実測4日間(8/6・8/8〜8/10)の平均は1日あたり約7,150万トークンで、第2波の2日間はその約19倍の規模でした(同じ日次ログからの算出)。三つの波のうち、実測で確認できている消費量としては最大です。ログは当ラボの作業機1台分のみが対象で、他の環境での利用は含まれていません。
第3波(8/17)——証拠：既存のワークフロー実行記録。
モデルを指定しないまま起動したワークフロー3本が、合計で約2.4Mトークン(57.3万+140万+47.2万トークン)を消費しました。内訳を見ると、ある1本は7体、別の1本は10体のAIエージェントを並列で起動していました。量そのものは小さく、同日全体の消費量(日次ログで確認できる約1.6億トークン)のごく一部です。ただし、この3本はモデル未指定のまま並列実行するとどうなるかを具体的に示す事象になり、④で述べる規律の確立に直接つながりました。この日はちょうど、後述するモデル等級規則の導入作業が進んでいた最中(8/15〜8/20)でもあり、規律がまだ行き渡っていなかった穴が可視化された形です。
実際に確認できる最大の消費は第2波にあり、約2.4Mは氷山の一角、規律確立のきっかけとなった診断的な事象という位置づけが正確です（訂正履歴を参照）。
三つの波に共通する原因は一つではなく、次の3条件が重なって起きたと当ラボは特定しています。第3波(8/17の3本)は量こそ小さいものの、この3条件がもっとも診断しやすい形で表面化した事象でした。
モデルを指定しないまま、複数のエージェントを並列実行した。 使用するAIモデルを個別に指定しなかった場合、システムは既定でもっとも高性能なモデルを選びます。ツール側からすれば、指定がなければ品質を優先して高性能なモデルを選ぶのは自然な設計です。高性能なモデルは判断や設計のような難しい仕事に向いていますが、ファイルの列挙や集計のような機械的な作業に使うとコストに見合いません。第3波では、機械的な作業を担当するはずのエージェントも含めて、ほぼすべてが最上位モデルで動いていました。しかもモデルのグレードだけでなく、AIが思考に使う量(処理の深さ。エフォートと呼ばれます)も既定のまま重い設定で動いており、1体あたりの消費が大きく膨らんだうえで、それが並列に何体も重なった格好です。厳密な倍率は記録から再現できていないため、ここでは方向性のみを記します。
定期実行と多段階のワークフローが重なっていた。 一つのエージェントが別のエージェントを呼び出す多段階の構成と、決まった時間に自動で起動する定期実行を組み合わせていたため、想定より多くのエージェントが同じ日に連鎖して立ち上がりました。一段ごとの消費量は小さく見えても、段数とエージェント数を掛け合わせると、全体としては大きな消費になります。個々の設定を見ているだけでは、全体の規模には気づきにくい構造でした。
消費量の可視化が事後だった。 ワークフローが実行されている間、その時点での消費量を確認する手段がなく、気づいたときには、すでに大半のトークンを使い終えていました。走らせてから初めて規模がわかる、という順序になっていたことが、被害を大きくしました。第1波で使用ログが週次リセット翌日昼にはすでに枯渇していたのも、第2波で2日間の消費に途中で気づけなかったのも、同じ構造です。途中で気づいて止められる仕組みがあれば、同じ設定ミスがあっても、ここまでの消費にはならなかったはずです。
確認できた3つの要因とは別に、運用者の記憶にもとづく観察も残っています。当初はログでの裏付けが取れていませんでしたが、今回の裏取りで、当時の逐語記録に符合する記載が見つかりました。ただし、消費量そのものへの定量的な寄与は、引き続き確認できていません。
【運用者の観察(当時の逐語記録に符合・定量的寄与は未確認)】
承認待ちの確認が反復し、回答が得られるまで処理が続いたと運用者は認識しています。この認識は、7/28の承認待ち一括レビューシート運用開始と、8/11の逐語記録に符合する記載があり、単なる記憶ではなく当時の記録に裏付けがあります。8/11は第2波の初日と重なりますが、これは時期の一致であり、量的な因果関係を示すものではありません。類似事象では回答が保持されず再回答も生じました。今回の消費量との因果・寄与量は確認できていません。
いずれの波でも、消費量が判明した時点で行ったのは単純な対応です。動いていたワークフローを止め、新しい起動を保留にしました。原因の分析や設計の見直しをしている間は新規のワークフロー実行や多段階の処理を追加で走らせないようにし、状況を悪化させないことを優先しました。保留の間に行ったのは、どの作業をどこまで進めていたかの棚卸しと、次に同じ規模の消費が起きうる箇所の洗い出しだけです。この段階では根本原因への対処はまだ何もしておらず、出血を止めただけです。実際の再発防止の設計は、波ごとに時間差を置いて進みました。次の④で、実装した時期を分けて記載します。
止血のあとに取り組んだのは、同じ構造の失敗を繰り返さないための仕組み作りです。逐語記録とNotion正本で確認できている実装の流れは、次のとおりです。
無人運転時に承認待ちの状態へ入った場合はそこで呼び出しを止め、通知は1回だけ送って一定時間内に応答がなければ処理を打ち切る、また質問と回答をタスクID・質問IDで保存して同じ質問を繰り返さない、という設計は、この時期に方針としては決定しましたが、実装はまだ運用ルールの段階にとどまっていました。②で触れた「回答が保持されず再回答が発生する」事象の再発を防ぐ狙いです。
無人運転時の承認停止・回答の永続化、起動前の機械検査は、方針としては維持していますが、この時点でもまだ実装していません。状態は次節の表にまとめます。
④で挙げた対策の多くは、運用ルール・プロンプトの書き方という「意図」のレベルの変更です。意図をルールとして定めるだけでは、書き忘れや例外対応によって守られない場面が残ります。当ラボでは、AIエージェントを設計どおりに動かす仕組みを、次の5段階に分けて考えています。
当ラボは完成を宣言せず、確かめては直す運営を続けています。以下の表は2026-08-31時点のスナップショットであり、実装が進み次第更新します。指示文に「上限」と書いてあるだけの状態は、ここでは「上限」と呼びません。
| 段階 | 仕組み | 状態 | 備考 |
|---|---|---|---|
| 1. 意図を決める | プロンプト規約(モデル/エフォートの明示を義務化) | 実装済み(運用ルール) | 7/28の一括レビューシートから8/20のモデル等級規則まで、段階的に文書化した。人が守る前提であり機械的な強制力はまだない |
| 2. 起動前に検査する | エージェント起動前の機械検査(モデル指定漏れで起動拒否) | 未実装 | 現状は目視レビューに依存している |
| 3. 実行中に強制する | 実行中の強制上限 | 部分的 | 利用している基盤側のワークフロー予算機構に依存。当ラボ独自の停止器は未実装 |
| 4. 承認点を設計する | 承認待ちの状態永続化・同一質問の抑止 | 未実装 | 方針は決定済みだが実装はまだ運用ルールの段階。7/28の一括レビューシートは軽減策であり、無人運転時の自動停止・回答の永続化そのものではない |
| 5. 事後に実測を記録する | 日次トークン台帳 | 実装済み(2026-08-31〜) | 毎朝、直近14日分を冪等に記録(既存より小さい値では上書きしない)。ログの自動ローテーションによる消失を防ぐ設計で、本記事の裏取りでログ消失に直面したことが実装の直接の契機 |
このほか、本記事のような公開コンテンツについては、禁止語や開示表記を検査する記事リンター(禁止語・開示検査)を実装済みで、公開前に毎回実行しています。ただしこれはAIエージェントのトークン消費を止める仕組みではなく、記事の内容を検査する別の仕組みです。
実装済みなのは1段階目と5段階目、部分的なのは3段階目、2段階目と4段階目は未実装です。これを隠さずに書くこと自体が、今回の記事で当ラボが誠実さの基準として置いているものです。
現在、当ラボの定期的な情報収集は四つの層に分けて動かしています。まず、更新情報の取得そのものはAIを使わない仕組み(RSS/Atomやサイトマップの更新日時、公開APIの定期取得など)で行います。次に、取得した情報から重複や無関係な内容を、決定的な処理(URLや本文のハッシュ値——内容から機械的に作る固有の識別値——による重複照合や、更新差分の検出など)でふるいにかけます。ここまではAIを一切使いません。意味のある変化が見つかったときだけ、条件を満たすもっとも安価なモデルに要約を任せます。そして、実際に採用する候補になったものだけ、別のモデル・別の視点で独立に検証します。
```mermaid
flowchart TD
A["収集層<br/>RSS/Atom・サイトマップ更新日時・公開API<br/>(AI不使用)"] --> B["ふるい分け層<br/>ハッシュ照合・更新差分検出<br/>(決定的処理・AI不使用)"]
B -->|意味のある変化のみ| C["要約層<br/>条件を満たす最も安価なモデル"]
C -->|採用候補のみ| D["検証層<br/>別モデル・別視点で独立に検証"]
D --> E["人が採否を判断"]
```
図：現在の情報収集の四層構成(模式図。実際のツール名・システム構成は一般化しています)。
図の代替説明：収集層とふるい分け層はAIを使わない決定的な処理で常時稼働する。意味のある変化が見つかったときだけ、要約層(安価なモデル)が動く。採用候補になったものだけ検証層(別モデルによる独立検証)に進み、最後に人が採否を判断する。
この四層は、それぞれ別のタイミングで動く点も意識して設計しています。収集とふるい分けは一定の間隔で機械的に回り続け、要約は意味のある変化があったときだけ、最終的な採否の判断は人が見るタイミングでまとめて行う、という具合に、機械が動く頻度と人が判断する頻度をあえてそろえていません。
この構成にしてから、変化のない期間はAIのトークン消費がほぼ発生しなくなりました。AIが動くのは、確認する価値のある変化が実際に見つかったときだけです。あわせて、どの層でどれだけ消費したかを引き続き記録しており、想定より消費が増えている層があれば、そこだけを見直す運用にしています。
AIエージェントを複数並列で動かす運用を検討している方向けに、当ラボが今回の経験から作ったチェックリストです。
一つでも当てはまらない項目があれば、次にワークフローを組む前に見直す価値があります。
このチェックリストの拡張版と、当ラボが実際に使っている道具の一般化版（記事リンター・校閲ルール集・トークン日次台帳スクリプト・launchd雛形）は、GitHubで公開しています：hakarulab/lab-tools（MITライセンス・各部品に「実測済み／試験中」の状態ラベルつき。更新は不定期で、Issueへの応答は保証していません）。
採用(当ラボの決定)： ④で挙げた「当時実装したこと」(承認待ちの一括レビューシート・トークン最小化方針・モデル等級規則・起動前の上限設定・実測ログの運用・変化駆動の定期実行への切り替え・多層防御のチェックリスト)は、当ラボの運用にすでに採用済みです。今回(2026-08-31)実装した日次トークン台帳も、採用済みに追加します。無人運転時の承認停止・回答の永続化、起動前の機械検査は、方針として決定していますが、上表のとおり実装は未完了で、実際の運用への反映はまだ行っていません。実装が完了し実測で確認できた時点で、この記事に追記します。次回の見直し時点は、次回の週次KPI確認時とします。
推奨(読者への助言)： 複数のAIエージェントを自動で並列起動する運用をすでに行っている実務担当者、およびこれから始めたい、または導入を判断するために情報収集をしている個人・チームの担当者には、⑥のチェックリストで自分の運用を照らし合わせることをおすすめします。とりわけ、消費ログの保持期限を確認し、期限が切れる前に日次で記録し直す仕組みを持つことを勧めます——今回の裏取りで、当ラボ自身がこの抜け穴に直面したためです。基準日は本記事の検証日(2026-08-31)時点の内容です。
方法： 本記事は、当ラボの購入記録(領収書)・当機のローカル実測ログ・当時の運用記録および逐語記録にもとづく事後の内部検証です。固有の製品名・チーム内部の呼び方は一般化しています。数値は当時の記録および当機で実行した実測に残っている値のみを記載しています。
方法論版： 記事執筆標準 v2(複数のAIに同じ問いを出し、意見を突き合わせてまとめた版)を適用。
未確認事項：
訂正履歴：
今後、事実関係の追加確認が取れ次第、この欄に追記します。
出典：
Hakaru Labの調査・執筆・検証は、複数のAIによる分業で行っています。本記事は、その運用のなかで実際に起きた失敗と対応を、当ラボの実測記録に基づいて振り返ったものです。方針の決定と最終的な確認は、運営側の人間が担っています。