4万人以上が使うSlack、15万以上のチャンネルのログをどう収集する？

はじめに

こんにちは、ドコモ・テクノロジの神崎です。

本記事は、2025年9月10日に開催されたNTTグループ社員向けの技術交流イベント「NTT Engineers' Festa 2025」で発表した内容を元に再構成したものです。

私たちの会社はNTTドコモの機能分担子会社で、私はNTTドコモのCCoE（Cloud Center of Excellence）チームのメンバーとして、ドコモグループ全体のクラウド活用を推進する業務に携わっています。

NTTドコモのCCoEは、クラウド利用のベストプラクティスを展開するだけではなく、Slackをはじめとする開発体験を向上させるSaaSやの3rd Party製品を共通基盤としてグループ会社向けに提供しています。その結果、提供しているSaaSなどの利用者数はのべ90,000人を超え、特にSlackは、アクティブユーザー46,000人以上、チャンネル数は152,000を超える巨大な規模に拡大しました。

このような大規模環境では、インシデント対応やコンプライアンス順守のために、迅速かつ正確なログ活用が必要です。従来は、ログの抽出依頼時に個別対応しており、属人化しやすく、膨大なログを効率的に扱う仕組みがありませんでした。

この課題を解決するために、CCoEチームは、明確なガバナンスルールを整備し、AWS上に自動化されたログ統合基盤を構築しました。本記事では、そのアーキテクチャと技術的なポイントについて説明します。

まずはルールから

技術的な解決策を導入する前に、まずログ抽出に関するルールとフローを整備しました。

ユーザー自身で解決できる仕組み

基本方針として、CCoEが対応するのはガバナンスが強く求められる案件のみとしました。具体的には、インシデントやコンプライアンスに関わる、管理者権限でなければアクセスできない情報（削除・編集されたメッセージ、自分がアクセスできないチャンネルのログなど）の抽出依頼です。

それ以外の、各プロジェクトで抽出可能なログについては、Slack APIの利用ガイドラインを作成・公開し、ユーザー自身で対応できる仕組みを整えています。

厳格な承認フローとプライバシー保護

CCoEが対応するログ抽出には、権限の濫用を防ぐための仕組みを導入しています。

多重承認フロー

依頼は管理職や組織のコンプライアンス担当に限定し、情報セキュリティ部門やコンプライアンス部門などの事前承認を必須としています
役割の明確化

依頼受付とシステム担当者の役割を明確に分離し、単独でのログ抽出を防ぎます。
プライバシー保護

ログへのアクセスは必要最低限のメンバーに限定し、アクセス履歴をすべて取得することで透明性を担保しています。
ログ管理の全体構成

全体アーキテクチャ

今回構築したログ統合基盤は、インフラ管理が不要でスケーラビリティに優れたサーバレスアーキテクチャを採用しています。

Amazon EventBridge：日次で処理を起動するトリガーです
AWS Step Functions：複雑なワークフローの全体の制御と並列処理をするオーケストレーションサービスです
AWS Lambda：Slack APIの呼び出しや取得したログの整形などの処理を実行します
Amazon S3：取得したログや、処理が失敗した際の情報の格納先です
Amazon Athena：S3に保存されたログを直接クエリーできる分析サービスです

Step Functionsによる自動化ワークフロー

日次での大規模ログ収集は、単純なスクリプトでは実現できない複雑な要件を伴います。そのため、全体の処理をAWS Step Functionsのステートマシンとして構築しました。

⚡ 大規模な並列処理の実現

15万以上のSlackチャンネルに対し、メッセージ取得処理を同時に実行し、収集時間を大幅に短縮できます。
⏱長時間処理の安定実行

Lambda単体では困難な長時間処理を、ステートマシン内で分割実行することで実現できます。
🔗疎結合なコンポーネント設計

各処理を独立したパーツとして構築しているため、アプリケーションの管理や変更が容易です。
🔄再利用性と拡張性

パーツ化されたコンポーネントは、他のログ取得基盤を構築する際にも容易に再利用できます。

Step Functions分散マップによる並列処理

この基盤における技術的な課題は、15万以上のSlackチャンネルからどう効率的かつ安定的にログを収集するかでした。この要件を実現するために、AWS Step Functionsを採用しました。

実行履歴クォーターを分散マップで回避

Step Functionsには、ひとつのワークフローの実行履歴が25,000までという上限があります。通常のマップ機能で15万チャンネルを処理すると、個々の処理がすべて親ワークフローの履歴を消費するため、この上限に達してしまいます。

この制約を回避し、大規模な並列処理を実現するために分散マップ(Distributed Map)を採用しました。

分散マップは、処理対象のアイテムリストをS3から直接読み込むことができます。今回の基盤では、処理対象の全チャンネルリストをS3に配置し、分散マップがそのリストをデータソースとして読み込むように設計しました。

各チャンネルに対してメッセージ取得用のLambda関数を同時に実行最大60並列で同時に実行し、収集時間を大幅に短縮しています。

分散マップが実行履歴の上限を回避できる理由は、通常のマップ機能との仕組みの違いにあります。

通常マップ機能の場合

全ての並列処理が親ワークフローの実行履歴を消費するため、15万チャンネルの処理では上限に達してしまいます。
分散マップの場合

各並列処理が子ワークフローとして実行されるため、親ワークフローの履歴を消費しません。

S3を活用したワークフロー設計のコツ

Step Functionsで並列処理や分岐を伴う複雑なワークフローを構築する場合は、状態やパラメータの管理が重要となります。ワークフローをより確実で安定したものにするために、S3をログの格納先だけではなく、状態管理のハブとしても活用しています。

進捗をS3に保存

各処理（ステート）間でデータを直接渡すのではなく、処理の進捗や結果を一度S3に保存します。こうすることで、途中で処理が中断しても、S3のデータから処理を復旧することが可能となります。
大規模な入力データをS3で管理

分散マップで並列処理の対象となる大量のチャンネルリストもS3に配置しています。これにより、Step Functionsの入力ペイロードサイズを気にすることなく、柔軟に大規模な並列処理を実行できます。
復旧のためのエラーログ

処理が失敗した際には、原因の究明に役立つエラー情報をS3に格納するようにしています。これにより原因分析と修正後の再実行をサポートします。

Amazon Athenaによるログ分析基盤

ログは収集するだけでは意味がありません。インシデント発生時に膨大なログの中から必要な情報を抽出できる仕組みが必要です。

私たちは、S3上のログを直接クエリーできるAmazon Athenaをログ分析基盤として採用しました。クエリの高速化とコスト削減のため、まずS3にログを年月日ごとに分割されたHIVE形式で保存します。その上でAthenaのテーブル定義でパーティション射影を定義しています。これにより、Athenaはクエリ実行時にスキャンするデータ量を最小限に抑えることができ、高速化とコスト削減を実現しています。

CREATE EXTERNAL TABLE discovery_conversations_history ( 
　ok boolean, 
　messages array<struct<...>>, 
　-- メッセージ内容などを格納
　...
) 
PARTITIONED BY (year int, month int, day int) 
LOCATION 's3://slack-message-logs/messages/' 
TBLPROPERTIES ( 
 'projection.enabled' = 'true', 
 'projection.year.range' = '2022,2032', 
 -- month, dayの範囲も同様に設定-- 
 'storage.location.template' =  's3://.../year=${year}/month=${month}/day=${day}/' 
);

導入効果と今後の展望

収集実績とコスト

本基盤は安定稼働しており、例として2025年8月1日の1日だけで、合計約2.2GB、37万個以上のオブジェクトをS3に格納しました。

収集したログの主な内訳は以下の通りです。

AWS利用料の内訳を見ると、Step Functionsが61.6%と最も大きな割合を占めています。これは、Step Functionsが状態遷移ごとに課金され、分散マップではイテレーション（繰り返し処理）ごとに課金が発生するためです。これは、コストはかかりますが、それに見合うオーケストレーション機能を活用できるため、費用対効果の高い選択だと判断しています。

今後の展開

このSlackで構築したログ管理の仕組みは、現在JIRAやConfluenceなど他の共通基盤へも展開を進めています。Step Functionsで処理がパーツ化されているため、効率的に応用することが可能です。

今後は、これらの共通基盤のログ基盤を連携させ、サービスを横断したログ追跡を実現し、調査をさらに効率化することを目指しています。

まとめ

私たちは、大規模に利用しているSlack環境のログ管理という課題に対し、ルール整備とAWS Step Functionsを中心としたサーバレスアーキテクチャで自動化された安定した仕組みを構築しました。これにより、運用効率とガバナンスを両立させ、大規模なデータを安定的に収集・分析できる基盤を実現しました。

このログ統合管理の取り組みを通じて、ドコモグループ全体のDX推進を支えて行きます。