【ITニュース解説】The message that mentioned finance and tagged nobody

ビジネスチャットツールが広く普及した現代において、チーム内のコミュニケーションは飛躍的に効率化された。しかし、その手軽さゆえに、重要な情報伝達がスムーズに行われないという問題も発生している。例えば、あるプロジェクトの議論中に「この件は経理部にも確認すべきだ」といった発言があったとする。だが、そのメッセージを見た誰もが、実際に経理部のメンバーを直接タグ付けしたり、経理部の専用チャネルに情報を転送したりしないまま、会話が別の話題へ流れてしまうケースがある。その結果、数週間後には経理部が全く知らない間に、重要な契約が承認され、後になって大きな問題として発覚するといった事態に発展してしまうのだ。

これは、チャットツール自体の機能が不十分なのではない。メッセージは確かに投稿され、後から検索すれば見つけることも可能である。真の問題は、本来その情報を知るべき人が、実際に情報を伝えられていないこと、そして、チーム名が言及されたことと、実際にそのチームが巻き込まれたことの間のギャップを、誰も監視できていなかった点にある。

このような情報伝達の課題を解決しようとするとき、まず考えられるのが、特定のキーワードに反応してアラートを出すというシンプルな方法だ。例えば、「finance（経理）」という単語が含まれるメッセージがあれば、自動的に経理部に通知を送る、といった仕組みである。しかし、この方法は現実的ではない。なぜなら、「finance」という単語は、組織の統制や承認といった重要な文脈だけでなく、「資金調達」や「予算」など、経理部への特別なアクションを必要としない様々な文脈で頻繁に登場するからだ。もしこのような単純なキーワードマッチングで通知を送ると、すぐにノイズだらけの通知チャネルができあがり、誰もその通知を読まなくなってしまうだろう。さらに、本当に経理部の関与が必要なメッセージの中に、たまたま「finance」という単語が含まれていないケースもあり得る。

そこで、単なるキーワードではなく、メッセージの「構造」に着目した解決策が求められる。Slackのようなチャットツールでは、チャネルを参照する際、単なるテキストとして「#finance」と書かれるだけでなく、内部的には「<#C01ABCDEF|finance>」のように、特定のチャネルIDを含む形式で表現される。これは、単に「finance」という言葉をメッセージに含んだ場合と、「finance」という名前のチャネルを明示的に指し示した場合とを明確に区別できる構造化された情報である。このチャネル参照のデータは、たとえ誰もそのチャネルをタグ付けしなかったとしても、メッセージのイベントペイロードとしてシステム内に保持されている。つまり、システムは既に「『finance』という言葉が言及された」ことと「『finance』チャネルが参照されたが、誰も呼び込まれなかった」ことの違いを認識しているのだ。この貴重なコンテキスト情報が、これまで活用されずに見過ごされてきたのである。

この構造情報を活用し、キーワードではなくチャネル参照を解析するボットを開発することで、問題を解決できる。ボットはメッセージの中から、特定のチャネルが参照されているが、そのチャネルのメンバーが明示的にタグ付けされていない、という特定のパターンを検出する。例えば、経理部や法務部といった、組織のガバナンス（統制）に関わる重要なチャネルが参照されているメッセージで、かつ誰もそのチャネルを通知していない場合に、ボットがその情報を収集し、関係者が確認できる場所へ集約するのだ。これにより、キーワードマッチングでは不可能だった、正確なコンテキストに基づいた情報の検出が可能となる。

このボットを設計する上では、いくつかの重要な判断がなされた。まず、ボットが監視すべきチャネルの「カバレッジ（範囲）」をどう確保するかだ。通常、ボットを導入する際は、管理者が手動で監視対象のチャネルにボットを追加する必要がある。しかし、この方法では、新しいチャネルが作成されるたびに、管理者がボットの追加を忘れ、監視の漏れが生じるリスクがある。これを防ぐため、このボットは起動時にSlackのAPIを利用して全ての公開チャネルを自動的にリストアップし、それら全てに参加する。さらに、Slackのchannel_createdというイベントを監視し、新しい公開チャネルが作成されるたびに自動で参加する仕組みも導入した。これにより、管理者の手間をかけずに、常に全ての公開チャネルを漏れなく監視することが可能となる。

次に、ボットとSlack間の通信方式の選択である。一般的なSlack連携では、「Webhook」という方式が用いられることが多い。これは、ボットがインターネット上に公開されたHTTPSエンドポイント（URL）を持ち、Slackがそのエンドポイントへイベント情報をHTTPリクエストとして送信する仕組みだ。この方式の場合、ボット側で公開されたエンドポイントのセキュリティ対策や監視、常に稼働させておくための運用が必須となる。しかし、このボットでは「Socket Mode」という方式を採用した。Socket Modeでは、通信の方向が逆転し、ボット側からSlackに対してアウトバウンドの接続を開き、Slackはその接続を通じてボットへイベント情報をプッシュする。これにより、ボット側でインターネットに公開されたHTTPエンドポイントを持つ必要がなくなり、組織内部のメッセージを扱う上で外部に新たな攻撃の入り口を設けるリスクを低減できる。

ただし、このSocket Modeの採用は、システムの「デプロイ」（実際にシステムを稼働させる環境に配置すること）の際に、予期せぬ課題を生んだ。Socket Modeのボットは、インバウンドのHTTPリクエストを受け取らないため、HTTPポートをバインド（特定のポート番号で通信を待ち受ける設定）しない。ところが、ボットが稼働するホスティングプラットフォームは、サービスが正常に起動しているかを判断するために、HTTPポートがバインドされ、ヘルスチェックと呼ばれるHTTPリクエストに応答することを期待していたのだ。ポートをバインドしないボットは、プラットフォームからは起動に失敗したプロセスのように見えてしまい、自動的に停止させられてしまう。

この問題を解決するために、「サイドカー」という手法が用いられた。これは、ボット本体と同じプロセス内で、ごく最小限のHTTPサーバーを立ち上げるというものだ。このHTTPサーバーの唯一の仕事は、プラットフォームからのヘルスチェックのリクエストに応答し、「ボットは動いているよ」と正常な状態を伝えることだけである。数行のコードで実装されるこのサイドカーは、プロダクトとしての機能には全く貢献しないが、これがないとボットは安定して稼働し続けることができない。これは、システムエンジニアが学ぶべき重要な教訓であり、アーキテクチャ図には通常描かれないが、実際のデプロイではホスティングプラットフォームの要件を満たすためのこのような付帯的な要素が、システムの安定稼働を左右することが多々あると理解しておくべきだろう。

また、ボットに与える権限（スコープ）も、意図的に最小限に絞り込まれた。具体的には、channels:join（チャネルに参加する）、channels:history（チャネルの履歴を読み取る）、chat:write（メッセージを書き込む）という三つの権限のみが与えられた。これは公開チャネルに限定され、特定のユーザーになりすまして発言したり、プライベートな会話にアクセスしたりする権限は一切ない。ガバナンスを向上させるためのツール自体が、厳格に管理可能でなければならないという考えに基づき、必要な最小限の権限のみを与えることで、セキュリティリスクを最小化し、将来的なセキュリティレビューにも対応できるように設計されている。

このボットの導入により、これまで誰かの記憶や注意に頼っていた経理関連の重要な言及が、確実に一元化された場所で、周囲の文脈情報とともに集約されるようになった。情報の監視という、人間が行うには負荷が高く、見落としがちな作業が、多忙になったり休暇を取ったりすることのないシステムへと移行したのである。この事例から得られるより広い教訓は、自動化をどこに配置すべきかということだ。このシステムは、特別な設定を必要とせず、新しいチャネルにも自動的に適応し、ワークスペースの誰も発言の仕方を変える必要がない。このようなシステムが理想的に機能している状態とは、チームメンバーがその存在すら意識しないほど、自然に機能している状態を指す。そして、その価値は、高額なコストを伴う予期せぬ問題が発生しないこと、つまり「問題の不在」によって証明される。この「問題の不在」を理由に、システムの構築を正当化することは難しい場合もあるが、その裏側では組織にとって非常に大きな価値を生み出しているのだ。