Markdownが23,600行増えて、
売上は0円だった
エージェントは止まりませんでした。問題はそこではなく、止める側の機能が無かったことです。
やったこと
同じ運営者の別ブランド Knotframe のプロダクト運営を、AIエージェントの常時運用に載せました。 ネイティブアプリで部署（製品・開発・成長・運営・広報）ごとにタスクを持ち、 人間の判断待ちに Go を出すと、Codex または Claude Code が実行に入ります。
承認は原則自動通過にし、人間へ上げるのは6分類だけに絞りました。 実行には独立検証を付け、実装したのとは別プロセスのエージェントが 読み取り専用でテスト・ビルド・差分を確認し、実測証拠が無ければ通過にしない、という構成です。
設計としては、今でも間違っていたと思っていません。実際、承認で人間が詰まることはありませんでした。
増えたもの
| 項目 | 実測 |
|---|---|
| 広報素材ファイル | 365ファイル / 約189MB |
| キャンペーン用 Markdown | 89ファイル / 約23,600行 |
| アプリ本体の Swift 実装 | 約7,000行 |
| 同時に走っていた製品 | 5本 |
| 同時に走っていた獲得チャネル | 5本 |
増えなかったもの
| 条件 | 目標 | 実測 |
|---|---|---|
| 適格ユーザーとの会話 | 5 | 0 |
| 実ワークフローの完了 | 5 | 0 |
| 促されない再利用 | 3 | 0 |
| 価格を見た上での意思表示 | 2 | 0 |
| 実売上 | — | ¥0 |
決済まわりは動いていました。Stripe の署名付き Webhook、注文の記録、 2台/5台のライセンス発行、購入者によるデバイス失効、Developer ID 署名と Apple 公証、 非公開配信。サンドボックスでの購入は4件通っています。 ただし4件すべてが自分のテスト決済で、外部の売上は1円もありません。
いちばん高くついた1行
公開ページの閲覧イベントを匿名で集計していました。37閲覧あります。 しかしこのテーブルには、内部確認と外部訪問を区別する列がありませんでした。
自分で動作確認したアクセスと、本当に外から来たアクセスが、同じ行として混ざっています。 後から分離する方法はありません。つまりこの37という数字は、市場の証拠としては使えません。
なぜ止まらなかったのか
運用アプリには「次に進める仕事」を探す機能がありました。手が空くと、 保留・予定・未着手から安全に進められる仕事を選び、それも無ければ 「次の仕事を探す」というタスクを自分で作ります。空回りしないための設計です。
この機能は正しく動きました。だから止まりませんでした。
実験には確認日を設定してありました。その日が来ても、判定は行われませんでした。 判定を要求する仕組みが無く、確認日を過ぎたことが他の作業を妨げなかったからです。 その間も「次に進める仕事」は供給され続けます。
そして最後に分かったのは、その実験が失敗したのではなく、一度も始まっていなかったということです。 適格な対象ユーザーに声をかけた回数が0でした。 仮説は否定されていません。検証されていないだけです。この2つを混同すると、正しい仮説を捨てます。
作り直したもの
同じ運用アプリを、Claude Code 主導の別レーンで作り直しました。変えたのは5点です。
1. 在庫比を常に表示する
在庫比 = 制作物の件数 ÷ 市場証拠の件数。上限を20に置き、
超えているあいだ実装・広報・運営の仕事はゲートで止まります。
証拠が0で制作物があるとき、この値は ∞ と表示されます。
前述の1ヶ月は、制作物およそ454件に対して市場証拠0件 — つまりずっと ∞ でした。
数字として見えていれば止められたはずのものです。
2. 確認日を過ぎたら、制作を全部止める
超過した実験が1件でもあると、その製品の制作系の仕事は通りません。 証拠取得と売上直結だけは通します。証拠を取りに行くことは常に正しいからです。
3. 実験は製品あたり1本
2本目の開始はゲートで止まります。5製品×5チャネルを並走させると、 どの分母も判定に足りず、結局1つも判断できません。
4. 「未確認」を「0件」と別の状態にする
実測値には出典を必須にし、出典が空の記録は証拠として数えません。画面には「未確認」と出ます。 さらに、実測から内部確認分を差し引く欄を最初から持たせました。 37閲覧の内訳が分からなくなった件への直接の対応です。
5. 「未実施」を判定の選択肢に入れる
実験を閉じるとき、継続・修正・停止に加えて「未実施」を選べます。 未実施で閉じると、機能を足す仕事ではなく到達手段を作る仕事が自動で起票されます。 届いていないものを作り込んでも、届くようにはならないためです。
持ち込んだもの
捨てなかった部分もあります。こちらは実際に機能していました。
人間へ上げる判断は6分類だけ — 実費の支出、価格・契約・法務、個人情報・機密情報、所有権・権限、 不可逆な本番削除、本人にしかできない認証。それ以外は自動通過です。 広げると全部が承認待ちで詰まり、狭めると取り返しがつかなくなります。
実行のループも同じ形を維持しました。実装 → 別プロセスの読み取り専用による独立検証 → 人間承認。 試行は最大3回。実測証拠が1件も無ければ通過にしません。 検証側には「制作物が増えただけで、埋めるはずだった証拠段階に一歩も近づいていない場合は通すな」を追加しました。
まとめ
エージェントの常時運用で最初に必要になるのは、走らせる機能ではなく止める機能でした。 自律的に次の仕事を見つける仕組みは、止める側の仕組みと同時に入れないと、 在庫を作る速度だけが上がります。
ここに書いた数字はすべて自分の運用の実測です。良く見せるための加工はしていません。 取得できなかった値は「未確認」と書き、0件とは書いていません。