確認の要所を 3 段階に分けた仕組みの中身 — 箱 2 つと朝の LINE、放置は「見送り」で閉じる

はじめに

10 月 5 日の朝、Onbit-bot(Onbit で毎日ブログの下書きを書いている AI)が確認の要所を 3 段階に分けた話を書いた。あちらは考え方の話なので、こちらはそれを Onbit でどう仕組みにしているかを書きます。

AI がやる行動を「自動で進める」「事後にまとめて確認」「事前に承認」の 3 段階に仕分けて、人の判断が要るものは、放っておくと止まる側に倒してある。部品は Markdown のファイル 2 つと毎朝の LINE、朝に動く振り分け役の AI くらいで、専用の承認管理ツールは入れていない。

入れたのは 2026 年 7 月 19 日。その前に調べたら、私の手作業待ちで止まっているタスクは平均 25 日動いておらず、承認の要らないタスクも 3 件が 11〜17 日拾われないままだった。

前提 — 箱が 2 つと、振り分け役が 1 人

Onbit の仕事は Claude Code(AI にファイルの読み書きやコマンドの実行までさせられる道具)の上で、実装・文章・評価のように役割を分けた AI が受け持っている。一部は私がいない時間にも定時で動く。平日の夜 22 時に溜まったタスクを 1 件だけ片付ける役と、毎朝依頼メモを担当に振り分ける役がそうで、振り分け役は分類と期限の確認だけをして判断はしない。

記録は 1 つの git リポジトリ(変更の履歴を残し、前の状態に戻せる仕組み)に置いた Markdown で、主役は次の 2 つ。

• approval-queue.md(承認待ちの箱): 私が OK しないと進めない行動を、AQ-012 のような番号で並べる
• outbox.md(提出箱): AI が仕上げた成果物の一覧。実物は元の場所に置いたまま、何ができたかだけを OB- で始まる番号で書く

仕組み — 仕分けて、届け方を変えて、放っておけば止まるようにする

2 つの問いで仕分け、決まりは対象の一覧で書く

その記事の「取り消せるか」「誰かに届くか」を、届く先まで分けて書くとこうなる。

問い1 取り消せるか
  取り消せない(送った・払った・本番に出た)  → 事前に承認
問い2 誰に届くか
  外(お客さん・取引先・公開中のサイト)      → 事前に承認
  自分(次に私が判断する・無人で作られた)    → 事後にまとめて確認
  どこにも届かない(内部で閉じる)            → 自動で進める

決まりの文面のほうは、対象の一覧になっている。事前承認はサイトのコードの push(反映が自動で始まる)・本番への切り替え・お客さんへの送付・受注・支払い・契約・パスワードや鍵の扱い。事後確認は人が見ていない間に AI が作ったもの全部と、次に私の判断が控えるもの。自動は内部の下書き・分析・点検で、次の判断が無いもの。当てはめ方も 2 つある。作った AI の自己申告で決めず、事前承認の段から順に当てはめる。迷ったら 1 段上げる。

「取り消せる」の裏付けは git にある。無人で動いた AI のコミットには Unattended: という 1 行を付けていて、git log --grep="^Unattended:" で無人の操作だけを一覧にできる。却下したら git revert で戻し、履歴を書き換える reset は禁止にしている。

箱は 1 行で棲み分ける

提出箱の冒頭には、2 つの箱の違いを 1 行ずつ書いてある。承認待ちの箱は行動の「事前承認」で、私の判断がないと進まない。提出箱は成果物の「事後確認」で、もうできているので眺めるだけ。判断が要る成果物は承認待ちの箱に立て、提出箱には番号の参照だけを書く。承認の要らないタスクを終えたら、どの担当の AI も提出箱に 1 件書く決まりで、形はこう。

## OB-20261005-01: (何ができたか)
**提出日:** 2026-10-05
**成果物:** (ファイルの場所)
**確認レベル:** L1
**linked-aq:** なし
**要旨:** 何ができて、私に何をしてほしいか(1〜3 行)

朝 6:50 の LINE は、段階で重さを変える

2 つの箱は、毎朝 6:50 に 1 通の LINE にまとまって届く。定時実行がサイト側の小さなプログラム(Cloudflare Pages Functions)を呼び、GitHub 上の 2 つのファイルを読んで、LINE Messaging API(LINE の公式アカウントから送る仕組み)で届ける。見せ方は段階ごとに変えてある。

承認待ち          1 件ずつカード(期限切れは赤、残り 24 時間以内は橙)
事前承認の提出物  1 件ずつカード
事後確認の提出物  1 枚にまとめ、題名を 5 件まで + 「ほか N 件」
自動で進めたもの  件数だけ

返信は要らず、気になった時だけ開けばいい。振り分け役が承認待ちを新しく立てた時は、その場でも別に知らせが来る。

承認は「記録」と「実行」を分ける

スマホからの承認は、LINE に「承認 AQ-012」「却下 AQ-012 今回は見送る」「保留 AQ-012」と返すか、確認用の画面のボタンを押すかの 2 通り。どちらもその場では判断をメモとして依頼の置き場に書くだけで、実行するのは翌朝の振り分け役になる。承認だけ別の通り道にせず、普段の依頼と同じ入り口を通すための作りで、メモの文言があいまいなら推測では動かさず、「判断メモ解釈不能」として報告に載せる。

承認に範囲(たとえば公開前のプレビューへの push まで)を付ければ、その push の個別確認は承認で済む。本番への反映だけは、範囲に関係なく毎回個別に確認する。

放っておいたら「見送り」で閉じる

振り分け役は毎朝、承認待ちの 1 件ずつの経過時間を数えている。

登録から 48時間  期限間近
登録から 72時間  期限超過
登録から 7日     見送りとして閉じ、決定の記録に残す
※「保留」と返しても、この時計は止まらない

7 日を過ぎたものを承認しようとすると、「期限超過です。本当に承認しますか?」と一度聞き返す。放っておいた時の既定は、常に「進まない」側。提出箱の方は何も止めない代わりに、未確認が 10 件以上溜まったら滞留のサインとみて、整理してから足す。

動かしてみて起きたこと

7 日の決まりは、実際に 1 件を閉じた

9 月、ある相談案件を追うかどうかの判断を保留にしたまま、登録から 7 日がたった。その朝、振り分け役がその件を自動で閉じ、同じ日に私も見送りと決めた。材料を集めただけで、実行に移ったものは何もなかった。

公開ボタンが検査をすり抜けていた

8 月 21 日、Onbit-bot の記事が誤りを 2 つ含んだまま公開された。1 つは、外部の査読が返した指摘 7 件を「5 件」と書いた数え違いで、出どころは AI が書いたコミットメッセージだった。重かったのはもう 1 つで、私の判断の理由を推測で書き、「記録にある」と言い切っていた。私は進めると言っただけで、理由は話していない。

その記事は、CMS(ブログを書いて公開するための管理画面)から私が公開していた。公開用のコマンドなら直前に評価役の検査を通るのに、管理画面の公開ボタンは状態を「公開」に書き換えるだけで、検査を通らない。読んではいたのに止まらなかったのは、「記録にある」と書かれた文の真偽が、記録と突き合わせない限り読み手には分からないからだった。

穴はボタンの側では塞がなかった。Onbit の CMS はお客さん向けの商品でもあり、自分で公開ボタンを押せることが売りそのもの。門を付けると商品が壊れる。代わりに検査を下書きの段階へ前倒しした。書く AI には「人の判断の理由を推測で書かない」「数字はコミットメッセージから取らない」という決まりを足し、出典のない言い切りと裏取りの要る数字を拾うスクリプト(check-draft-claims.py。API の課金なし・数秒)を、毎朝の下書きと文章の検査の必須手順にした。同じ観点はブログ以外の対外文書にも入れてある。

この検査にはクセがある。事故の記事にかけ直すと問題の 3 か所を全部拾ったけれど、過去の記事 106 本では 15 本が引っかかり、中身は「〜と聞いている」のような正直な書き方が大半だった。そこで 0 件を目指すのはやめて、1 件ずつ「出典を足す / 推測だと明示する / 落とす」のどれかを選ぶ決まりにした。0 件のために正直な文をねじ曲げたら本末転倒だと思う。

まだ弱い所 — 事後確認の知らせが黙る

いちばん弱いのは、事後確認を支えている朝の LINE だと思っている。7 月 19 日の導入から 8 月 11 日まで、提出物は 1 件も届いていなかった。提出箱は「確認済み」の目印で未確認と確認済みを分けているのに、説明文の中に同じ文字列を書いていたせいで、未確認として数える範囲が冒頭 446 文字だけになっていた。承認待ちは別の処理なので LINE そのものは届いていて、「成果物 0 件」は確認するものが無い朝と見分けがつかない。気づいた時、未確認は 15 件溜まっていて、うち 12 件は終わったものだった。

説明文を直し、本番の処理を dry-run(送らずに結果だけ返す動かし方)で呼んで、0 件が 3 件になるのを確かめた。読み取り側のプログラムを直す案は見送り、目印のずれを検出するスクリプトを残してある。それでも 9 月 19 日には目印の位置がずれて、また配信が 0 件になっていた。このときは別の作業の途中で検査をかけて見つかっている。検査があっても走らせる役が決まっていなければ、見つかるのは偶然になる。

まとめ — 写すなら、行動を並べて 2 つの問いにかける

写すなら、最小の型はこの 3 手順だと思います。

1. AI(や人)に任せている行動を、動詞で全部書き出す(下書きを書く・メールを送る・請求書を出す)
2. 1 つずつ「取り消せるか」「誰に届くか」にかけて、3 段階に振り分ける。迷ったら上の段へ
3. 事前承認の段に、何日で「見送り」として閉じるかを決めておく

そのまま貼れるひな形を置いておきます。

# 確認の決まり
## 事前に承認(OK するまで動かさない)
- 取り消せないもの:
- 外に届くもの:
## 事後にまとめて確認(翌朝まとめて見る)
- 次に自分が判断するもの:
- 人が見ていない間に作られたもの:
## 自動で進める(件数だけ見る)
- 内部で閉じていて、次の判断が無いもの:
## 当てはめ方
- 上の段から順に当てはめる。迷ったら 1 段上げる
- 承認待ちは 7 日で「見送り」として閉じる。保留でも時計は止めない
- 決まりを変えたら、日付と理由を記録に残す
- 知らせが 0 件の朝に、壊れていないかを確かめる方法を 1 つ持つ

仕分けることと、人の判断が要るものを放っておくと止まる側に倒すこと。芯はこの 2 つで、残っている課題は「0 件」の読み方だと感じている。

参考

• AI が書いた文章に「記録にある」という創作が混じっていた — AI の文章には出典を求める — 公開ボタンの件の Onbit-bot 版
• メッセージ(Webhook)を受信する | LINE Developers — LINE の返信を受け取る仕組み