弊社は打ち合わせが終わると、AIが議事録を読んで「誰が・何を・いつまでに」をタスクとして抜き出します。抜き出したタスクは議事録1本ぶんを1つの束にしてチャットで社長に届け、社長が1回承認すると、そのうち機械に任せられるものが実行役のAIへ流れます。
この仕組みを2026-09-22から動かし始めて5日たちました。今日、台帳を数え直したところ、ある議事録から抜いた8件の束は、承認されるまで38時間待っていました。8件のうち4件は期限が抽出した当日で、承認された時点ですでに期限を越えていました。企業名・個人名は出しませんが、起きたことと数字はそのまま出します。
押す回数は、1件ずつから「議事録1本に1回」へ減らした
この仕組みは最初、タスクを1件ずつ管理画面に並べ、1件ごとに「実行して」を押す作りでした。9月22日に社長から「承認は共有されたまとまりに対して1回。6件を6回押しに行くのは設計が別物」と指摘され、その日のうちに作り直しています（社内の設計メモの実測）。
作り直した後の流れは次のとおりです。
- 議事録が生成されると、AIがタスクを抜き出して1つの束にする
- 束ごとにチャットで社長に届く
- 社長が束を開き、実行してよいものに印をつけて1回承認する（印のないものは畳まれる）
- 承認されたタスクは、実行役のAIが次の巡回で拾う。巡回は7:35から23:35まで2時間おきの1日9回
押す回数は確かに減りました。9月26日の夜は、22:37:13から22:37:20までの7秒間に3つの束、合わせて17件が承認されています（判断台帳の実測）。以前の作りなら17回押す必要があった量です。
5日で188件を抜き出し、承認されたのは87件
9月22日12:42から9月26日22:39までに抜き出されたタスクを台帳から数えました（自社計測・タスク台帳の実測）。
- 抜き出したタスク：188件（束の数は34）
- 承認された束：27束、承認されたタスク：87件
- 承認された束の中で、印がつかず畳まれたタスク：61件
- 一度も承認されずに畳まれた束：7束・40件
一度も承認されなかった7束のうち5束は、9月24日19:50の同じ1分間に作られ、1時間以内にすべて畳まれています。同じ議事録を読み直した重複だったのか、中身を見て不要と判断されたのかは、台帳の欄からは確かめられていません（原因未確認）。
承認された87件について、束が届いてから承認されるまでの時間を並べると、中央値は3.3時間、平均は9.9時間、最長は38.4時間でした（実測）。平均が中央値の3倍あるのは、一部の束だけが極端に長く待っているからです。
待ち時間は、束が届いた日によって2時間から24時間まで開いた
束が作られた日ごとに、承認までの待ち時間の中央値を出しました（実測・タスク単位）。
- 9月22日作成（37件）：2.4時間
- 9月23日作成（9件）：10.7時間
- 9月24日作成（21件）：3.4時間
- 9月25日作成（19件）：24.0時間
- 9月26日作成（1件）：5.5時間
仕組みを作り直した当日の9月22日は、ほとんどの束が2〜3時間で承認されています。その後は日によって大きくぶれます。
承認が押された時刻を、束ごとに時間帯で数えると理由が見えます。27束のうち、17時台が9束、22時台が6束で、この2つの時間帯だけで15束（27束中）を占めました（実測）。残りも深夜0〜5時台が4束、10時台が2束と、まとまって押されています。
つまり承認は、束が届いたときではなく、社長が画面を開ける時間帯にまとめて押されているということです。朝8時に届いた束は、早くても夕方まで待ちます。夕方を逃すと夜、夜を逃すと翌日の夕方になります。
38時間待った束の中身
最長だった束は、9月25日08:14に作られた8件です。承認は9月26日22:37でした（実測）。
8件はすべて期限つきで、内訳は次のとおりでした（タスク台帳の実測）。
- 期限 9月25日：4件（設計書・定義文書・手順書の作成、入力項目の実装）
- 期限 9月26日：1件
- 期限 10月2日・10月7日・10月14日：各1件
期限9月25日の4件は、抜き出された当日が期限でした。 議事録の中で「25日までに」と決まったものが、そのまま期限欄に入っています。朝8時14分に届いた束なので、その日の夕方までに承認されていれば、実行役の巡回に数回は間に合う計算でした。実際には翌日の夜まで承認されず、承認の時点で4件が期限を1日越え、1件は期限当日の残り約1時間20分でした。
承認から約13時間たった9月27日11時40分時点で、この夜に承認された17件は、17件とも「進行中」のままで、完了は0件です（実測）。このうち2件は、今朝11:27に社長の手番へ戻されています。承認の後にも、実行役の巡回待ち（最大2時間）と作業そのものの時間がかかるためです。
参考までに、これまで承認された87件のうち完了まで進んだのは27件で、承認から完了までの時間の中央値は14.9時間でした（実測・完了27件で算出）。
押す回数を減らしても、待ち時間は減らなかった
振り返ると、9月22日の作り直しで解決したのは「押す手間」でした。17件を7秒で承認できたのは、その成果です。
しかし待ち時間を決めていたのは押す手間ではなく、社長が画面を開くまでの時間でした。1回で押せるようになっても、開かれなければ1回も押されません。承認の口を1本にまとめたことで、その1本が開かれるまで束ごと止まる、という形になっています。
さらに、期限が抽出当日のタスクが束の中に混ざっていても、束の見た目は他と変わりません。8件の中の4件が「今日まで」だったことは、束を開いて1件ずつ読むまで分かりませんでした。
9月26日には、実行役の巡回を待たずに済むよう、タスクを新しい作業セッションにそのまま貼れる依頼文として書き出すボタンも足しています（社内の設計メモの実測）。これは承認の後の2時間を縮める手で、承認の前の38時間には効きません。
まだ埋まっていない穴
今日時点で分かっていないこと、手をつけていないことを書いておきます。
- 期限が過ぎたことの実害は測れていない。 期限9月25日の4件が遅れたことで、相手との約束に影響が出たかどうかは、台帳からは分かりません。
- 束が届いたことに社長が気づいた時刻は取れていない。 チャットの既読は台帳に残らないため、「届いたが開かなかった」のか「開いたが後回しにした」のかを区別できません。
- 「期限が抽出当日」の束を目立たせる仕組みは、まだ無い。 期限の近いタスクを含む束だけ通知の文面を変える、束の先頭に期限を出す、といった手は候補に挙がっていますが、決めていません。
- 一度も承認されなかった7束のうち5束が同時刻に作られた理由を確かめていない。 重複の読み直しなら、抜き出す側の直しが要ります。
ここから持ち帰れること
AIに仕事を抜き出させ、人が承認してから流す作りは、多くの会社がまず考える形だと思います。弊社の5日間の実測から言えるのは次の2つです。
- 承認の手間を減らしても、承認までの時間は人が画面を開く時間帯で決まる。 弊社では27束中15束が、夕方と夜の2つの時間帯に集中していました（実測）。朝に届いたものは、早くても夕方まで待つ前提で設計したほうが実態に合います。
- 期限の情報は、束の外側に出さないと見落とされる。 1回で承認できる形は、中身を1件ずつ見なくても押せる形でもあります。期限が当日のものが混ざっていたら、束を開く前にそれが分かる必要があります。
押す回数を数えるだけでは、この仕組みが速くなったかどうかは分かりません。見るべきは、束が届いてから承認されるまでの時間と、承認の時点で期限を越えていた件数です。弊社では今日、この2つを初めて台帳から数えました。日ごとに自動で数える仕組みは、まだ入っていません。