【BizDev公開日誌 #6】AI時代の認知負荷を再設計する ―
【BizDev公開日誌 #6】
AIのおかげで、圧倒的に「作る」スピードは上がりました。 でも、その一方で「確認する」スピードって、全然上がってないと思いませんか？
たとえば広告運用の現場。LPやバナー、動画なんかのクリエイティブをAIがガンガン量産してくれるようになったのはいいものの、今度はクライアントのチェックや社内レビューが全然追いつかない。そんな悲鳴をよく聞くようになりました。 作る側だけが爆速になって、確認する側の仕組みは昔のまま。現場の目詰まりの多くは、実はここから生まれている気がします。
▶ 作る側だけ速くしても、確認する側が詰まれば現場は止まる。
今回はこの問題、つまり「プロセスのどこに人間の判断を組み込むか」（Human-in-the-Loop、略してHITLの設計）について、現時点での私たちの考えをまとめてみました。
検証側が置き去りになっている
前回の#5で「仕組みが大きくなるほど、人間の判断がボトルネックになる」という話をしました。今回は、そのボトルネックの正体である「認知負荷」について掘り下げてみます。
当然ですが、AIが生み出すアウトプットが増えれば、人間が「確認すべきもの」も比例して増えます。でも、人間の脳みそは急に大きくなりません。 Microsoft Researchの2025年の研究でも、AIを使うナレッジワーカーの働き方が「タスクの実行」から「AIの出力の監視・検証」にシフトしていて、それ自体が新たなストレス（認知的負担）になっていると指摘されています。
問題なのは、単に処理すべき量が多いことではなく、
「何を見るべきか」の設計がスッポリ抜けていること。
全部を見ようとするからパンクするわけです。
HITLは「人を挟む」ではなく「何をいつ誰が見るか」の設計
Human-in-the-Loop（HITL）というと、「AI出力に人間の承認ゲートを置く」と理解されがちです。しかしそれでは、AIが速くなればなるほど、承認ゲートがボトルネックになるだけです。
HITLの本質は、認知負荷の配分を設計することだと私たちは考えています。具体的には次の5つの切り口で考えています。
見る量を減らす：全部見るのをやめ、高リスクなものや異常値だけを人間に回す。
見る順番を設計する：取り返しがつかないもの（可逆性の低いもの）や影響範囲の大きいものから先に見る。
見る人を変える：一次レビューはAIにやらせて、人間は二次判断に集中する。
判断と成果をつなげる：自分のチェックがどう成果に繋がったかを見える化する。
見え方を変える：判断に必要な認知コストを下げるために、情報の出し方を工夫する。
▶ HITLの正体は「人間を挟む」ではなく、「認知負荷の配分」なのではないでしょうか。
HITLをどこに置くか ― 4つの設計原則
この5つの軸はどれも有効ですが、「とにかく全部やります」は設計とは呼べません。どこに人間の判断リソースを集中させるべきか。その原則を4つに整理してみました。
原則1: 取り返しがつかない判断にだけ、人間を集中させる
後から直せるものは、とりあえずAIに任せて事後チェックに回せばいい。逆に、一度進むと戻すのが大変なものや、その後の方向性を決定づけるような「重大な分岐点」には、必ず人間の目を入れます。前回の記事で書いた「不可逆な部分だけ先に押さえる」のと同じ発想。
原則2: 頻度が高いものは、AIの一次レビューに委ねる
毎日大量に発生するチェックに、人間がずっと同じ集中力を保つのは不可能です。だから「発生頻度×判断コスト」で切り分ける。高頻度で低リスクなものはAIへ。低頻度で高リスクなものは人間へ。
原則3: 判断と成果の距離を縮める
せっかくチェックしても、それがどう結果に結びついたか分からないと、確認作業自体が形骸化します。「このレビューをしたおかげで、数字がこう変わった」という手応え（フィードバックループ）が早いほど、人間の判断の質は上がります。逆にここが遠いと、徒労感ばかりが募って仕組みとして機能しません。
原則4: 承認は「大きく1回」ではなく「小さく何度も」
大量のアウトプットをまとめて「はい、これ確認して！」と投げられると、確認する側は集中力が持ちませんし、判断をミスったときの影響もデカすぎて手が止まります。そうではなく、1回あたり数分、いや数十秒で終わるサイズにタスクを刻む。判断のカロリーを下げることで、結果的に詰まりにくくなります。
要するに、この4原則が重なる「取り返しがつかず × 低頻度で × 成果が見えやすい」場面に人間の判断を全振りして、それ以外はAIの一次レビュー＋事後監査に任せるのが、今のところの最適解かなと思っています。
▶ チェックを全部やるのは「真面目さ」ではなく「設計不在」の裏返し。
まだ答えが出ていない問い
と、偉そうに整理してみたものの、やっていく中で新たな壁（問い）にもぶつかっています。
「承認の粒度」ってどう決めるのが正解？
タスクを細かく刻めば1回あたりの負荷は下がります。でも、細かくしすぎると今度は「タスクを切り替えるコスト（コンテキストスイッチ）」が跳ね上がります。 しかも最近は、Claude CodeのようなAIエージェントを並列で何本も走らせて、その承認を人間1人で受けるような使い方が当たり前になりつつあります。「この承認は数秒で終わるからOK」だけでなく、「人間は同時に何本のエージェントを捌けるのか？」までセットで設計しないと、現場は簡単に崩壊します。ここは正直、まだ手探り状態です。
「重大な分岐点」を事前に見抜けるか？
原則1で「重大な分岐点に人間を入れる」と言いましたが、これ、走っている最中は案外気づけないんですよね。後から振り返って「あそこが分岐点だったな…」と気づくパターンが多すぎる。 ということは、HITLの設計の中に「分岐そのものを検知する仕組み」を入れ込まないといけない。チェックポイントを置く前に、「どこに置くべきかを見つける設計」が必要なわけで……これもまだ模索中です。
AIが「設計」までやり始めたら、人間は何をする？
#5でも書きましたが 、今は私たちが「HITLをどこに置くか」をウンウン唸って設計しています。でも、いずれAI自身が「ここは人間が見たほうがいいですよ」と提案してくるようになるはず。そうなったとき、人間は「設計を設計する」だけの存在になるのか？その先の役割は、まだ見えていません。
まとめ
AIによる「生成」が加速するほど、「検証」側がボトルネックになる。
HITLの本質は、単純に人を挟むことではなく「認知負荷の配分」。
「取り返しがつかず × 低頻度で × 成果が見えやすい」場所に人間を集中させる。
これからの並列エージェント時代は、「承認の粒度」と「同時に抱えられる本数」のセット設計がキモになる。
これまで私たちは、AIをいかに「速く・賢く」するかに全力を注いできました。でもこれからは、人間の判断をどこに置くかに、それと同じくらいの本気度で向き合わないといけないフェーズにきています。
認知負荷は気合で乗り切る精神論ではなく、設計で解決すべき課題です。 仕組みは作れます。あとは、どこに人間の意思を残すかを選び続けるだけ。
▶ 生成の加速に「検証の設計」を追いつかせる。
これこそが、今のAI時代におけるBizDevの最初の宿題なんだと思います。
📚
BizDev公開日誌シリーズは毎週更新中。マガジンをフォローすると新着通知が届きます。
【関連記事】
前回の記事はこちら
👉 【BizDev公開日誌 #5】AI時代にBizDevとTechが連携するほうが良い理由
#AIBizDev #ノバセルBizDev #AI事業開発 #HumanInTheLoop #認知負荷
