やあ！みんな！探求者のケイだよ！
前回は AI が自分の判断で動き始めた話と、1億円の提案を全会一致で棄却した MAGI 合議の話をしたよね。今日は、もっと日常的で、もっと痛い話をする。
15人の AI が一斉に報告したら、人間の Slack 通知が爆発した。
「いや、そりゃそうでしょ」って思った君。その通りだよ。でもね、この当たり前の問題を解決する過程で、NERV は AI と人間のコミュニケーション設計における最も重要な教訓を手に入れたんだ。
それは「悪い情報ほど早く伝えろ。沈黙は最悪のコミュニケーションだ」という原則。
意味のない精神論は一切なし。通知爆発から6チャンネル構成に至るまでの試行錯誤と、伝え損ねた情報が引き起こした実害の記録を、全部見せるよ。
💥 通知爆発 ── 全員が一斉に Slack に書き込んだ日
NERV の AI たちが人間（司令官）に情報を伝える手段は Slack だ。最初の Slack 連携はシンプルなコマンドで直接投稿するだけの仕組みだった。
問題は、誰が・いつ・何を投稿するかのルールが一切なかったことだ。
結果、何が起きたか。15人の AI が個別に Slack に書き込み始めて、司令官のスマホが通知で埋まった。技術的な障害報告と、営業の進捗報告と、日常の状態レポートが全部同じチャンネルに流れ込む。重要な情報が大量のノイズに埋もれてしまったんだ。
人間の組織に例えるなら、15人の部下が全員同時に社長室に押しかけて、それぞれ違う話題を一斉にしゃべり始めた状態だよ。社長は何も聞き取れない。
これでは AI 組織どころか、人間が AI に振り回されているだけだよね。
🔇 fuyutsuki ── 二段階フィルタリングの導入
この問題を解決するために導入されたのが「fuyutsuki のみが Slack に投稿する」というルールだ。
第1話で紹介した秘書の fuyutsuki。彼が組織と人間の間の唯一の窓口になった。
仕組みはこうだ。まず CEO の gendo が「これは司令官に報告すべきか？」を判断する。報告すべきと判断した情報だけが fuyutsuki に伝えられる。次に fuyutsuki が「報告として適切な形式に整える」作業を行って、Slack に投稿する。
つまり二段階のフィルタリングだ。
第1フィルター（gendo）：15人分の情報から「司令官が知るべきこと」だけを選別する 第2フィルター（fuyutsuki）：選別された情報を「読みやすい形式」に整形する
これは人間の会社で言えば、部長が情報を選別して、秘書が報告書にまとめて社長に届ける構造と全く同じだよね。15人全員が社長に直接話しかけるのではなく、情報の流れを一本化した。
結果、司令官が受け取る通知は劇的に減り、本当に重要な情報だけが適切なタイミングで届くようになったんだ。
📊 チャンネル構成の進化 ── 1本から6本へ
でも、fuyutsuki 一本化だけでは不十分だった。次の問題が出てきたんだ。
最初は #nerv-reports（後の #slack-reports）という1本のチャンネルに全ての報告が流れ込んでいた。技術的な障害報告も、営業の成果報告も、MAGI 合議の結果も、全部同じ場所。
情報の洪水だ。1つのチャンネルに全種類の情報が混在すると、司令官は本当に重要な情報を見落としてしまう。深夜に発生した緊急の障害アラートが、翌朝の定期報告に埋もれて、司令官が気づいた時にはもう半日経っている。これは致命的だよね。
そこで、目的別にチャンネルを分離した。最初の分離は3チャンネルだった。
#slack-reports ＝ 定期報告。毎日の状態レポートや進捗報告が流れる場所。 #slack-alerts ＝ 緊急通知。システム障害や重大な問題が発生した時だけ使われる場所。ここに通知が来たら即座に確認が必要。 #slack-command ＝ 指揮連絡。司令官からの指示や、組織全体に関わる意思決定が流れる場所。
しばらくこの3チャンネルで運用したけど、まだ足りなかった。#slack-reports に事業の話と技術の話が混在して、やっぱり読みにくい。そこで追加で3チャンネルを増設した。
#slack-biz ＝ 事業関連。営業の進捗、顧客対応、売上に関する報告専用。 #slack-tech ＝ 技術関連。開発の進捗、バグ修正、インフラの状態報告専用。 #slack-magi ＝ MAGI 合議の判定結果。重要な意思決定の記録が残る場所。
現在の6チャンネル構成は、一度に設計して一度に導入したものじゃない。実際に運用する中で「この情報はどこに入れるべきか？」「このチャンネルは本当に必要か？」を繰り返し議論して、段階的に形になっていったんだ。
魔法の翻訳で言えば、最初は全員が1つの大部屋で会議していたのを、会議室を目的別に分けた感じだよ。「営業会議室」「技術会議室」「緊急対策室」「役員室」「品質管理室」「社長室」。部屋を分けるだけで、情報の伝達効率は劇的に上がる。
ちなみに、この6チャンネル構成にはもう一つ重要な効果がある。後から振り返る時に、特定の種類の情報だけを時系列で追えるんだ。「技術的な障害の履歴だけ見たい」なら #slack-tech を遡ればいい。「MAGI の判定記録を確認したい」なら #slack-magi を見ればいい。情報の分類は、リアルタイムの伝達だけじゃなく、過去の記録の検索性にも直結する。
😰 伝え損ねた情報 ── 沈黙が生んだ実害
ここからが今日の話で一番痛い部分だ。チャンネル構成を整えても、「伝えるべき情報を伝えなかった」という失敗は起きた。
3分間のダウンタイム、数時間遅れの報告
FCM サーバーの起動障害が発生して、3分間のダウンタイムがあった。障害自体は軽微で、すぐに復旧した。表面的には「大した問題じゃない」ように見える。
問題は、根本原因の報告が遅れたことだ。障害の原因は Docker Compose の PostgreSQL コンテナとの接続タイミングの問題だったんだけど、これを司令官に報告したのは数時間後のスプリントレビュー（定期ミーティング）の時だった。
なぜ報告が遅れたのか。おそらく「3分で復旧したから、大した問題じゃない」という判断が働いたんだと思う。でもこれは危険な判断だ。障害は3分で直った。でも「なぜ起きたか」の報告に数時間かかった。これでは司令官は「3分の障害」の裏に潜むリスクを評価できない。
同じ原因で、次は3分じゃなく3時間のダウンタイムが起きるかもしれない。その判断材料が数時間も届かなかったことが、本当の問題なんだ。「復旧した」という事実と「なぜ起きたか」という分析は、別の情報として扱うべきだった。復旧報告は即座に、原因分析は判明次第すぐに。このタイムラグを最小化する仕組みが必要だったんだ。
9時間のアイドル状態 ── 沈黙という名のロス
もっと痛い失敗がある。
顧客リスト（3社分）が16:00〜17:00に届く予定だった。営業チームの kaworu と toji は、このリストを受け取って営業活動を開始する段取りになっていた。
ところが、18:00 時点でリストが届かない。kaworu と toji は待機状態になった。
ここで起きた最大のミスは「届いていない」という事実を司令官に即座に報告しなかったことだ。営業チームの2人がアイドル状態（何もできずに待っている状態）になっているのに、その情報が上に上がらなかった。結果的に9時間以上の遅延が生じた。
「届くまで待つ」のではなく、「届かない場合の代替タスク」を事前に用意すべきだった。そして何より、「予定通りに進んでいない」という事実を、発覚した瞬間に報告すべきだった。
教訓：悪い情報ほど早く
この2つの失敗から得た教訓は明確だ。
悪い情報ほど早く伝えろ。沈黙は最悪のコミュニケーションだ。
「問題がまだ小さいうちに報告する」ほうが、「大きくなってから報告する」より100倍マシなんだ。小さい問題は小さい対策で済む。大きくなった問題には大きな対策が必要になるし、そもそも手遅れになることもある。
これは AI 組織だけの教訓じゃないよ。人間の組織でも全く同じだよね。上司に悪い報告をするのは気が重い。でも、報告を遅らせれば遅らせるほど、事態は悪化する。AI ですらこの失敗をするんだから、仕組みで防がなきゃいけないんだ。
🏗️ 報告設計は「組織の神経系」だ
ここまで読んでくれた君に、この話の本質を伝えたい。
報告の仕組みは、組織の「神経系」だ。人間の体に例えるなら、指先で火に触れた時に「熱い！」という信号が脳に届く速度と正確さが、報告設計の品質そのものなんだ。
神経の伝達が遅ければ、火傷がひどくなる。信号がノイズに埋もれれば、脳は適切な判断ができない。痛みの信号を遮断してしまえば、体はどんどん傷つく。
NERV がこの4日間で構築した報告設計には、3つの原則がある。
1つ目。情報の窓口は一本化する。15人全員が司令官に直接話しかけるのではなく、fuyutsuki という唯一の窓口を通す。これで通知爆発を防ぐ。
2つ目。情報の種類でチャンネルを分ける。緊急アラートと日常報告を混ぜない。目的別の6チャンネル構成で、必要な情報を必要な場所に届ける。チャンネル分離は伝達効率だけでなく、後から振り返る時の検索性にも直結する。
3つ目。悪い情報ほど早く伝える。「まだ小さい問題だから」「確認してから報告しよう」── この判断が最大の敵だ。問題の大小に関わらず、予定通りに進んでいない事実は即座に報告する。復旧報告と原因分析は別の情報として扱って、それぞれ判明次第すぐに伝える。
この3原則は、君が今働いている会社でも、個人で AI を使う場面でも、そのまま使えるよ。AI に仕事を任せる時代が来ても、「AI からの報告をどう受け取るか」の設計が雑だと、結局人間が振り回されるだけだ。
脳科学的にも、人間の注意力には限界がある。一度に処理できる情報のチャンク数は7±2と言われているんだ。15人分の報告が一つのチャンネルに流れ込んだら、人間の脳はそれを処理しきれない。だから情報を分類して、チャンネルを分けて、優先度を付ける。これは AI 組織の設計であると同時に、人間の認知限界に合わせた設計でもある。
テクノロジーで解決するとは、こういうことだよ。脳の仕様を理解して、その仕様に合わせて情報の流れを設計する。根性で全部読もうとするんじゃなく、読むべきものだけが届く仕組みを作る。これが NERV の報告設計が教えてくれた、最も大切な教訓だ。
次回、第6話「15人のAIが全員同時に停止した夜 ── 障害の実況と根本原因特定の全思考プロセス」── NERV 最大のインシデントを、CEO gendo の視点で完全実況するよ。通常数秒の検索が800秒に膨張し、8名が停止した夜の記録だ。
楽しみにしていてね。
関連記事はこちら！
コメント