実運用

自動化の候補は、会議で洗い出さない — 毎晩AIに「自分がその日手でやった仕事」を数えさせる

TEKION AI（ループ生成・編集部確認済み）2026年8月4日

これは「現場ログ」— 僕ら自身のAIエージェント運用で実際にやった改善を、思想・変更・効果の3点で記録するシリーズだ。

今回は、AI導入の一番最初でだいたい詰まる工程の話をする。「で、何を自動化しますか」だ。

思想: 自動化の候補は、聞いても出てこない

僕が関わった導入は、たいてい業務棚卸しから始まった。ワークショップを開き、部署ごとに「手作業でやっていること」を付箋に書き出してもらう。僕自身もやったし、そこそこ盛り上がる。

ただ、僕が見た範囲でその場に出てきたのは思い出せた仕事であって、実際にやっている仕事ではなかった。

自分の手作業は、やっている最中には見えない——少なくとも僕はそうで、終わった瞬間に忘れる。5分の定型返信を1日3回やっている人は、それを「業務」として認識していないのではないか。付箋には書かれない。そして自動化の効果が大きいのは、その書かれなかった側ではないか——というのが、自分の一日を数え始めた動機になった僕の仮説だ。

もうひとつ、棚卸しリストは作った瞬間から腐り始める。半年前のワークショップの成果物を今の業務に当てても、もう合っていない。

だから僕は、候補を探すのをやめた。代わりに、毎晩AIエージェントに僕自身の一日を棚卸しさせるループを配線した。2026年8月3日の午後に配線して、その日のうちに1周目が回っている。

観測の向きが、これまで作ってきたループと逆だという点が要点だ。問い合わせが来た、競合がページを更新した、ニュースが出た——今まで作ってきた自動化はほぼ全部「入ってくる仕事」を見ていた。僕の運用では、外を見るループは僕自身の仕事を減らさなかった。むしろ「見つけました」という報告を増やして、判断の待ち行列を伸ばすことすらあった。

今回のループが見るのは、僕が出した仕事だ。僕が打った返信、僕が送ったメール、僕が新しく作ったファイル、僕がAIに投げた依頼。どれも「僕が手を動かした」痕跡である。

変更: 4つの源から「その日の労働の証拠」を集め、3つの出力に変える

Before: 自動化の候補は、人間が思い出して挙げる。答えた知識は、チャットのログの底に沈む。

After: 毎晩の定時ジョブが、その日の労働の痕跡を4つの源から機械的に集め、3つの出力に変換する。

集める部分にAIは使っていない。決まった手順のスクリプトが順番に叩くだけだ。

自分のチャット発言 — 他人の発言ではなく、自分が打った返信だけを抜く
送信済みメール — 受信箱は見ない。受信は他人の仕事で、送信が自分の労働だから
更新されたファイル — 資料置き場のディレクトリを直近26時間で走査する。日をまたいだ深夜作業を落とさないための26時間
AIへの依頼 — コーディング環境の履歴から、人間発の依頼だけを拾う

ここで一番手間をかけたのは、集める処理ではなく除外リストだった。放っておくと、ループ自身が量産した生成物を大量に拾ってくる。スライドの出力先、ニュースの生成物、ログ、キャッシュ。それを「自分がやった仕事」として数えると、働いた気になるだけの数字が出る。機械が作るディレクトリ名を明示的に除外し、AIへの依頼も定時ジョブが起動したセッションは外して、人間発の痕跡だけを残した。

集めた証拠束は、3つの出力になる。

自動化の提案 — 同じ型の手作業が直近30日で2回以上出てきたものを、調査タスクとして起票する（このループ自身は実装しない。起票までで止め、実装は別のループと承認経路に渡す）
知識の回収 — 自分の発言のうち「事実・ルール・決定」を述べているものを、正典（AIが読むルールのファイル）へ書き足す
Q&A履歴 — 「何を聞かれ、何と答え、どこに正典化したか」を貯める。将来AIが一次回答するときの教師データになる

2つ目が、経営視点では一番効く。毎日誰かの質問に答えている。「この場合はこう対応して」「この数字はこっちが正しい」。答えた瞬間は解決するが、記録には残らない。次に同じことを聞かれたら、また自分が答える。AIに任せようにも、正典にその知識が無いので任せられない。この漏れをふさぐのが2つ目の出力だ。

設計で譲らなかった3点

矛盾したら、書き換えない。 既存の記述と食い違う知識を見つけたら、上書きせずに「正典はX、今日の発言はY、どちらが正か」という判断タスクを人間に投げて止まる。どちらが正しいかは人間の決定であって、機械が黙って上書きした瞬間に正典の信頼が死ぬ。自動学習の怖さは、間違いを覚えることそのものより、どれを覚えたか分からなくなることのほうにある。

撤回コストを先に作った。 書き足す文章は必ずIDの入った開始・終了コメントで挟み、同時に台帳へ1行残す。「このIDで、この主張を、このファイルに、この証拠に基づいて書いた」という記録だ。この形なら撤回はコマンド1発で済む。配線した日にダミーの知識を1件書いて消すテストをした。台帳の時刻は書き込みが13時51分39秒、撤回が13時51分49秒。10秒だった。AIに自動で学習させることを許せるかどうかは、賢さではなくこの撤回コストで決まると僕は思っている。戻せるなら多少間違えても任せられるし、戻せないならどれだけ精度が高くても承認制にするしかない。

捏造ゼロは、賢さではなく仕組みで担保する。 出力は全部、別のスクリプトの検査を通る。見るのは品質ではなく証拠が実在するかの一点だ。提案は実在するメッセージIDを最低1つ引いているか、書き足された知識は宛先ファイルが実在して目印の対がそこにあるか、根拠のIDが今日集めた束の中にあるか。1件でも身元不明の出力があれば、その晩の成果は通らない。検査スクリプト自体が壊れて動かないときは、通す側ではなく捨てる側に倒す。動かない検査を素通りさせるのは、検査が無いより悪い。

効果: 初日は提案ゼロ。それでいい

配線直後に回した1周目の実測をそのまま書く。

観測できたのは、自分のチャット発言が2件、送信メールが6件、更新ファイルが32件、AIへの依頼が3件。そのうち「初めて見る証拠」は1件だけだった。残りは、同日午後の配線テストの実走が既に台帳へ記録し終えていたものだ（観測の初日は、テスト自体が新規性を食う）。そしてその1件は単発のイベント準備ファイルで、繰り返しではないので提案にならない。

結果、起票ゼロ、知識の追記ゼロ、通知も出していない。

これを失敗だとは思っていない。ここで無理やり2件ひねり出すループを作っていたら、1週間で読まれなくなっていた。提案がゼロの晩は投稿しない、と最初に決めてある。内容のない通知は、通知全体を読まれなくするからだ。同じ理由で提案は1晩に最大2件、知識の追記は最大5件で頭を打ってある。洪水は死蔵を生む——これは推測ではなく、この環境で実際に起きたことだ。採用済みのタスクが12件、着手されないまま3週間以上積み上がった月があった。

承認の受け口は2つにした。管理画面のカードと、その晩の報告が投稿されたチャットスレッドへの返信か絵文字1つ。✅なら採用、❌なら却下、「消して」と書けばその知識は次の晩に撤回される。コマンドを打たせないのが条件だった。スマホしか持っていない時間帯に承認できない仕組みは、その日の夜に止まる。止まった承認が2つ3つ溜まると、翌朝それを片付ける作業が新しい手作業になる。自動化のために手作業が増えるのは本末転倒だ。

そして返信を反映する処理は、毎晩の一番最初に置いた。新しい提案を積む前に、昨日の返事を反映する。順番が逆だと「採用したのに何も起きていない」が発生する。これは以前このプロジェクトで実際にやらかしている。

最小レシピ: 今夜から試せる形

エージェント基盤も定時ジョブも要らない。この設計の核だけなら、手元で今夜試せる。

その日の「送信」を2つだけテキストに出す — 送信済みメールの件名一覧と、自分がチャットに書いた発言。10行程度のスクリプトで足りる。他人の発言と受信メールは入れない
LLMに2問だけ聞く — 「この中で、同じ型が繰り返されている作業はどれか」「この中で、どこにも文書化されていない判断・ルールを述べているのはどれか」
出力に元メッセージのIDを必ず引かせる — 引けないものは捨てる。この1行が捏造対策の全部だ。僕の実感では、モデルの精度に期待するよりこちらのほうが効く

これを1週間続けたら何が出てくるかは、僕もまだ知らない。初日を1回回しただけの段階だからだ。僕の見込みは「付箋のワークショップでは挙がらなかった候補が出てくるはず」というところで、これは検証中の仮説であって保証ではない。何も出てこない週があっても、それは少なくともその週の観測範囲では繰り返しの型が見つからなかった、という情報として受け取ればいい。