私はAIの専門家ではありません。
3日前まで、エージェントという言葉の意味もよく分かっていませんでした。それでも、複数のAIに仕事を分担させて24時間動かす構成を作ることはできました。
そして、3日間で8回、自分の間違いを訂正しました。
この記事は、うまくいった話ではありません。初心者が何につまずくかの記録です。動くコードも出します。
1日目 ― 「動かす」の前に「止まる」を考えていなかった
最初にやったのは、データを集める処理を動かすことでした。動きました。数時間かかる処理です。
問題は、それが途中で止まったときに誰も気づかないことでした。
私は画面を見ていました。見ていない間に止まったら? そのときは、次に画面を開いたときに気づきます。それが何時間後かは、運次第です。
ここで最初の間違いをしました。生死を2値で考えたことです。
最初の実装 動いている / 止まっている
実際には3つ目があります。「分からない」です。
# 生死は3値で持つ。**不明を死に丸めない**
def state(job, now):
if pid_alive(job.pid):
return "RUNNING"
if job.progress_age is None: # 進捗の出所が読めない
return "UNKNOWN" # ← **ここを DEAD にしない**
if job.progress_age > job.stall_sec:
return "STALLED"
return "NOT_RUNNING"
「分からない」を「死んでいる」に丸めると、生きている処理を殺しにいきます。
逆に「生きている」に丸めると、死んだまま何時間も気づきません。
3つ目を持つだけで、両方が防げます。
進捗の出所は、ジョブ自身に宣言させる
見張りを作って、すぐ次の間違いをしました。
ログファイルの更新時刻で「進んでいるか」を判定したのです。
ところが、ログではなくデータベースに書く処理がありました。ログは静かなままです。
3時間無音に見えて、実際は正常に動いていました。
# ジョブごとに「進んでいる証拠がどこに出るか」を宣言させる
jobs:
- id: collect
progress: {kind: file_mtime, path: logs/collect.log}
stall_sec: 1800
- id: probe
progress: {kind: sqlite, path: data/live.db, column: started_at}
stall_sec: 900
宣言できないジョブは登録させないことにしました。
「どこを見れば進捗が分かるか」を書けないものは、そもそも見張れません。
2日目 ― 複数に分けたら、誰が何をしているか分からなくなった
作業を分担させました。データ収集、分析、検証。速くなりました。
同時に、「いま何が動いていて、何が終わったか」が分からなくなりました。
チャットの履歴をさかのぼって確認する。それ自体が作業になっていきます。
このあたりで、AIを増やすほど自分の仕事が増えるという奇妙な状態に気づきます。
答えは単純でした。状態を会話ではなくファイルに置く。
会話に置く その会話を開いた人しか知らない。**閉じたら消える**
ファイルに置く 20分ごとに動く小さなプログラムが読める。**文脈が要らない**
3日目 ― 費用を測ってみたら、桁が違った
ふと、どれだけ使っているのかを調べました。
セッションの長さ 17時間
ターン数 469
読み直したトークン 108,575,962
→ 1ターンあたり 231,505
1回のやりとりごとに、23万トークン。
会話が長くなるほど、AIは毎回それまでの全部を読み返します。知らないうちに、1歩の値段が上がり続けていました。
もっと意外だったのはこちらです。
別のAIに作業を投げた場合 1回あたり 3,372 トークン
自分の会話で進めた場合 1ターン 231,505 トークン
約69分の1でした。
私は逆に思っていました。「AIを増やすと高くなる」と。だから自分で抱え込んでいた。
その日の作業の85%は、投げるべきものでした。
トークンを減らしたいなら、最初に見るのはプロンプトの長さではありません。セッションの寿命です。
監視を止めたら、その1時間後に対象が死んだ
長時間動く処理に、見張りをつけていました。
その処理を止めようとする過程で、私は先に見張りのほうを止めました。
1時間後、処理は別の理由で異常終了しました。誰も気づきませんでした。
13:25 異常終了
14:21 「進んでる?」と聞かれて、はじめて発覚
→ **57分間、何も動いていなかった**
止めたい対象こそ、止まった瞬間を知る必要がある。
当たり前のことですが、その場では分かりませんでした。
いま見張りは機械が持っています。人もAIも持ちません。
人が見張る その人が止めた瞬間、見る目が消える
AIが見張る 費用がかかり、しかも会話が長くなるほど高くなる
機械が見張る 20分ごとに動く小さなプログラム。**費用はゼロ**
AIは、古い記録を疑わない
3日間で3回、同じことが起きました。
自分が前に書いたメモが古くなっていて、AIがそれを現在の状況として読んで、正しく推論して、間違った結論に着く。
AIは書かれていることを信じます。疑いません。
だから記録が古いだけで、そこから先の判断が全部ずれます。しかも一見もっともらしいので、気づきにくい。
対処は、記録と実物を機械が突き合わせることでした。
# 記録が「公開済み」と言っている記事が、本当に公開されているか
for rec in published_records():
live = fetch_title(rec["url"]) # 実物を取りに行く
if live != rec["title"]:
print("記録と実物が食い違う:", rec["file"], "|", rec["title"], "≠", live)
生成物ではなく、記録のほうが先に古くなります。
後日談 ― 自分の「できました」を数えてみた
ここまでの間違いには共通点があります。どれも「対処済み」と自分で記録していました。
そこで、「できました」と言った回数そのものを数える台帳を作りました。
要点はひとつです。申告した時点で「どうすれば嘘だと分かるか」を書かせる。
$ python claims.py add --by 自分 --kind done \
--claim "記事を公開した" \
--check "APIの一覧に当該記事が含まれる" # ← これが無いと登録できない
$ python claims.py add --by 自分 --kind done --claim "テスト" --check ""
却下: --check（どうすれば嘘だと分かるか）が空。
**反証条件を書けない申告は、申告として数えない。**
初日の結果です。
申告 6件（真3 / 偽1 / 未検証2）
的中率 75% 確かめたもののうち本当だった割合
検証率 67% そもそも誰かが確かめた割合
偽が1件出ました。「記事を公開した」と記録した直後、反証条件どおりに機械が確認したら、
実際には公開されていませんでした（投稿数の制限に当たって拒否されていた）。
私はそれを知らずに「公開しました」と報告する寸前でした。
**検証率のほうが大事だと思っています。**的中率だけを見ると、
「確かめやすいことしか確かめていない」状態を見逃します。
**この数字は上界です。**台帳に載るのは捕まった誤りだけなので、本当の誤り率はこれ以上あります。
同時に1つしか使えないものが、24時間運用の上限を決めた
複数を並列に動かそうとして、すぐ詰まりました。同時に1つしか使えない資源があったからです。
外部への接続、台帳への書き込み、公開。これらは並列にできません。
逆に言うと、それ以外は何本でも同時に動かせます。
排他 接続 / 台帳への書き込み / 公開 → 常に1本
それ以外 調べる・書く・検証する → 何本でも同時
役割で分けるのをやめて、資源で分けることにしました。
「調査担当」「実装担当」と分けても、両方が同じ接続を使うなら並列度は1のままです。
実際、同じ資源を使う3つの部門を1つに統合しました。分けても速くならなかったからです。
ロックはファイル1つで足ります。
# 誰が握っているかと、そのプロセスが生きているかを見る
lock = read_lock() # {"pid": 1234, "owner": "collect"}
if lock and pid_alive(lock["pid"]):
skip("%s が使用中" % lock["owner"]) # **絶対に起動しない**
**「ロックファイルがある」だけでは足りません。**握っていたプロセスが死んでいると、
ロックだけが残ります。pidの生死まで見ないと、永久に起動できなくなります。
使い回そうとして、初めて分かったこと
3日目に作った見張りを、別の作業でも使おうとしました。動きませんでした。
中を見たら、最初のプロジェクトの実パスが直接書かれていました。
ロックファイルの場所、データベースの場所、判定に使う条件。
書いてあったもの C:\...\session.lock / C:/.../live.db / 特定の条件名
起きたこと 別の作業では、**存在しないパスを見に行った**
厄介なのは、それでも動いてしまうことです。
ファイルが無ければ「進捗が読めない」となり、「分からない」が「止まっている」に化けます。
最初に3値にしておいたのに、設定が間違っていれば意味がありません。
道具の側に、特定の作業の事情を1つも持たせない。
パスも資源名も条件も、外の設定ファイルから渡すようにしました。
道具 仕組みだけを持つ。**固有の値はゼロ**
設定 プロジェクトごとに1ファイル。**無ければその機能は黙って無効**
「どの設定で動いているか」が1行で出るようにもしました。
それが分からない状態が、いちばん危ないと思ったからです。
3日で分かったこと
1 会話が長いほど高い。**作業の区切りで切る**
2 任せたほうが安い。自分で抱えると桁が変わる
3 見張りは機械が持つ。人が持つと、人が止めた瞬間に消える
4 AIは記録を疑わない。だから記録を機械が点検する
5 並列度を決めるのは役割ではなく資源。**同じ資源なら分けても速くならない**
6 道具に固有のパスを埋めない。**使い回そうとした日に必ず気づく**
7 「できました」は測れる。**測るには反証条件を先に書かせる**
7つとも、始める前には想像していませんでした。
AIは速く作ります。問題は、作ったものが正しいかを確かめる側が追いつかないことでした。
だから私は、確かめるほうを機械にしました。
作るのはAI、確かめるのは機械、決めるのは人。
初心者が3日でたどり着いたのは、この分け方ひとつです。
次は、この申告の台帳を続けた結果を書きます。件数が増えたときに的中率がどう動くか、
そして測っていること自体が申告を変えてしまうかを測ります。
この連載は、実際に測った数字だけで書いています。
同じことを試す人の役に立ちそうなら、ストックしておいてください。
この連載
AIエージェントを実際に回して、かかった費用と壊れた箇所を測って書いています。推測は書きません。実測値だけです。
- Claude Code のトークン使用量を実測したら1ターン23万 ― 節約に効いたのは「セッションを切る」だった
https://qiita.com/manabu49-ai/items/2598a30d5140e4445ab6 - 57分間、死んだジョブを誰も見ていなかった ― AIエージェントの見張りを機械に渡す
https://qiita.com/manabu49-ai/items/5c7506c94b5be58c040e - AIに100通り試させたら、効果ゼロなのに5個が「有意」だった
https://qiita.com/manabu49-ai/items/397a018948e1ab7ef29e - 仕様書は2日前から手元にあった ― 読まずに実装した対処が、データを永久に失う設計だった
https://qiita.com/manabu49-ai/items/9b947604d3dc4958fa36 - Qiitaで何が読まれるかを3,478本から探した ― 106通り掃いて、残ったのは6つだけだった
https://qiita.com/manabu49-ai/items/d78a5aeaecf8d7f3f20b - 本記事 ― AIを触り始めて3日で24時間動くものを作った ― そして8回間違えた
番外 ― Claude のモデル提供終了、猶予は告知から約60日 ― 過去9回を数えて、手元を検査するスクリプトを書いた
https://qiita.com/manabu49-ai/items/bc2a7be2a6ee4ceb6185
**無料記事は結論まで全部書きます。**出し惜しみはしません。