1. はじめに
こんにちは、コーポレートシステム部（以降CorpS）関西支店勤務の松本です。
部門について簡単に紹介させていただきます。私が所属するのはCorpSという部門で、いわゆる情報システム部門（情シス）です。 部のミッションとして掲げているのが「EXをシンプルにする」というものです。EXとはEmployee Experience（従業員体験）のことです。 私が所属するチームではSlack・AWSを中心に様々なSaaSをつなぎながら、社内の「面倒な定常業務」を自動化する仕組みづくりをしています。
今回は、Slackのログをもとに、個人ごとの週報を自動生成する「週報アプリ」を作った話です。 Slackなどのチャットツールで業務をし振り返りを行うと、下記のようなペインが生まれます。
- 「どのチャンネルに何が書いてあったか覚えていない…」
- 「この人、今週なにしてたんだっけ？を追うのもつらい…」
これらをログから“事実ベース”で週報を起こすことで少しでも楽にしよう、という試みです。
2. 背景・課題
2-1. 「今週なにやった？」が見えない問題
この週報アプリを作る前、私の所属するチームでも部署全体としても決まった形式で週報を書く習慣がありませんでした。 週例のミーティングなどで「今週あったこと」をNotionにまとめ、口頭で報告していましたが、これには以下のような課題がありました。
- 報告のために、毎回Slackを読み返して記憶を辿る必要がある
- 他のメンバーが具体的にどんな活動をしているのかが見えづらい
- 個人単位のログはあっても、部門全体で横並びに見る場所がない
一方、実際のコミュニケーションは基本的にSlackで行われます。
- 技術的な議論
- 障害対応の経緯
- プロジェクトのちょっとした相談
など、ほとんどがSlackのスレッドに流れていきます。 この結果、手作業で情報を拾おうとすると、以下のようなギャップが生まれます。
- 週報を書こうとしても、どこで何が起きていたかの生の文脈を追うのが大変
- 「今週この人なにしてた？」を知るには、Slackをチャンネル横断で遡る必要がある
- 部長・マネージャー視点で、チーム全体の“今週のトピック”をざっと掴むのが大変
これらの課題を解決するため情報の集約先として、Notion上の「週報データベース」 を選択しました。検証の結果 「最終的なアウトプットをNotion DBに格納することでNotion AIで処理・活用しやすい」 という理由から採用した構成です。
2-2. 手作り週報の限界
「じゃあSlackを遡って、自分でまとめればいいのでは？」という話になります。 実際にやってみると：
- Slackの投稿を検索して調べる or APIで対象の人が関連する情報を手元に落とす
- LLMでざっくりまとめるツールをローカルで実行
まではいいのですが、運用に乗せるには次のような問題がありました。
- チャンネル数が多いと、モデルによってはサマリの質が安定しない
- Notionへの書き込みも含めて、1 人分の週報ごとに手作業が多い
- SlackからエクスポートしたZipを個人のローカルで処理したくない
※Slackのエクスポート機能はWorkspace単位でデータをエクスポートできる機能があります。エクスポート管理者、Orgオーナー／管理者、ワークスペースオーナー／管理者などの権限で実行可能です。権限が強く様々なデータが閲覧可能になるので運用には注意が必要です。
Notion AIだけでなんとかならないか？も検証しましたが、検証当時のNotion AIでは
- 期間・対象ユーザーを指定しても、関係ない人のログまで拾ってしまう
- 出力が不安定
という状況で、 「だったら、Slack側でログをしっかり構造化してから週報を作ろう」 という方針に振り切りました。
（Notion AIも日々進化しているため、現在では実現可能なことも増えているかもしれません。ただ、AIに渡すコンテキストを適切に制御するアプローチは、精度と安定性を担保する上で依然として重要だと考えています。）
3. 作ったもの／取り組みの概要
3-1. 週報アプリでやりたいこと
この週報アプリで狙っているのは、ざっくり言うと次の3つです。
- Slackのパブリックチャンネルのログを人単位でまとめる
- 週ごとに「誰がどのチャンネルで何をしていたか」を拾う
- Bedrock（Claude Sonnet 4.5）にサマリを任せつつ、Notionに週報ページとして保存
3-2. 全体アーキテクチャ（図解）
アーキテクチャはこんな感じです。
具体的な処理の流れは以下の通りです：
- SlackからエクスポートされたZipをS3に置く
- 前処理Lambda がZipを展開してDuckDBファイルとして保存
- 前処理Lambda がメッセージをSQSに投げる
- 週報生成Lambda がSQS経由で呼ばれ、DuckDBから該当ユーザーのログを引いてくる
- BedrockのClaude Sonnet 4.5 に「この週の活動を、エンジニア向けに週報にまとめて」とお願い
- Notion API経由で、週報DBにページを作成
これにより、Slackのログ収集からNotionへの週報生成までのパイプラインが確立されました。Slackからのエクスポートデータの処理、LLMによる要約、Notion へのページ作成といった一連の工程が自動化され、手動オペレーションはほとんど不要になりました。
4. 技術的なポイント
4-1. Slackエクスポート → DuckDBで“検索しやすいログ”に
Slackのエクスポートは、チャンネル × 日付 × JSONファイルという構造で落ちてきます。
このままだと、
- 「特定ユーザーの、1 週間分のログを全部出して」
- 「リアクションの数も一緒に見たい」
といったクエリが書きづらいので、DuckDBに詰め替えています。
ここで 「分析のためのSQLite」 とも呼ばれるDuckDBを採用した理由は主に3点です。
- 列指向で集計が高速: 分析に必要な「列」だけを読み込むため、大量のログから特定ユーザー分を抽出する処理が高速
- サーバーレスとの相性が良い: 1つのファイルとして扱えるためDBサーバー不要。S3上のファイルをLambdaから直接読み書きできる
- JSON の扱いが手軽: ネストしたJSONもSQLで直感的にクエリできる
イメージとしては、Slackのエクスポートデータ（JSON）を、集計しやすい形に整形してテーブル化しています。
補足：AthenaではなくDuckDBにした理由
「S3上のデータをSQLで分析するならAmazon Athenaで良いのでは？」という考え方もありますが、今回は以下の理由からあえてDuckDBを採用しました。
- ユースケースの適合性: Slackからエクスポートしたデータは毎回新しく読み直す運用が前提で、再利用の予定も少ないため、Lambdaのメモリ内で完結するDuckDBがシンプルかつ高速で適しています。
- スモールスタート: 最初からデータ基盤（Glue/Athena）を構築すると構成が重くなるため、まずはアプリ内で完結させ、将来的に規模が拡大した段階でAthenaへの移行を検討するスタンスとしています。
週報生成Lambdaでは処理の概要としては、対象ユーザーの 1 週間分のメッセージを抽出し、それに対するリアクション数を集計・結合するというものです。
これにより、「いつ・どのチャンネルで・どんな発言をし・どんな反応があったか」を時系列で並べた、LLMが解釈しやすいデータセットを生成しています。
4-2. SQSでユーザー単位にバラして処理
週報は「人単位」で独立しているので、SQSキューにユーザー単位のジョブとして投げています。 これにより、処理を非同期に実行して安定性を高めています。
また、Bedrockのレートリミット等で失敗した場合は指数バックオフでリトライし、それでも失敗した時はSQSのリトライ機能を利用し実行を行い、運用負荷を下げる工夫をしています。
4-3. Bedrockに“週報ライター”をやってもらう
DuckDBで取ってきたログを、そのまま人間が読める形にするのは大変なので、ここでBedrockのClaude Sonnet 4.5の出番です。
- モデルは Claude Sonnet 4.5（Bedrock 経由）
- 社内の情報セキュリティ専門部署との協議の上、データを国内リージョンに留める必要があったため、Bedrockの国内リージョン固定の推論プロファイルを採用しています。
実際のプロンプトでは、以下のように出力フォーマットや制約事項を厳密に指定しています。
出力要件: 1) 「今週のハイライト」（要点）。各項目は1〜2文。 2) 「決定事項/合意事項」— あれば箇条書き 3) 「未完了のTODO」— 推定できるものを箇条書き 4) 「リスク/懸念・ブロッカー」— あれば箇条書き 5) 「データで見る活動」— メッセージ数や応答傾向など 厳守する注意: - @メンションは原文通り出力 - 単一メッセージの項目: message_link を必ず使用 - 複数メッセージをまとめる項目: thread_link を使用 - 主観的コメント・提案・問いかけ・呼びかけは禁止 - 無いセクションは見出しごと省略（「該当なし」と書かない）
ポイントは、「何を書いてほしいか」だけでなく「何を書いてはいけないか（主観的コメントなど）」も具体的に指定しているところです。
これにより、ログの事実からは離れすぎず、かつリンク付きで一次情報にすぐ飛べる実用的な週報を生成しています。
4-4. Notionへの書き込みと重複チェック
最終的にはNotion APIを使って、生成されたサマリを週報DBにページとして作成します。
この際、同一ユーザー・同一期間のページが既に存在する場合は作成をスキップすることで、処理の冪等性（べきとうせい・Idempotency）を担保し、リトライ時の二重登録を防いでいます。
4-5. 運用コストについて
コスト面ではBedrockの利用料が最も大きな割合を占めますが、対象ユーザー 60名程度で月額 5,000円程度（数ドル/週）で運用できています。
国内リージョンに閉じた Bedrock (Claude) は少し料金も嵩むので、コストをさらに抑えたい場合はClaude Haiku 4.5や他モデルも選択肢に入るかと思います。
5. 得られた成果
現状フィードバックをもらいながらブラッシュアップしている状態ですが、現時点でもいくつか手応えが見えています。
5-1. 手作業の削減
- Slackエクスポートの前処理をLambdaに載せたことで、ローカルでZipをいじる作業は不要になりました
- 週報生成フローをSQS＋Lambdaに分解したことで、Bedrockのレートリミットを考慮しつつ、並列分散処理によって対象ユーザーが増えても安定して実行できる構成になりました
- Notionへのページ作成も自動化され、「Slackを遡って週報を書く」時間はかなり減りました
上記の構成により「毎週ゼロから文章を書く」よりはだいぶ気が楽になります。
5-2. 可視化のしやすさ
プロジェクトページやタスクから見えるログを踏まえると、こんな良さが出てきています。
- 部長・マネージャー視点
- 誰がどのチャンネルの議論に関わっているかが俯瞰しやすい
- リスクや詰まりポイントの気配を、週報ベースで追いやすくなる
- メンバー視点
- 自分が関わったスレッドやチャンネルが週報で整理されるので、「なんとなく忙しかった週」を振り返りやすい
- Slack のログから自動で要約されるので、評価など「とりあえずAIに下書きしてもらう」ところから始められる
6. 今後の展望
週報アプリをここからもう一歩進めたい方向としては：
- 目標 と実際の活動ログを紐付け、評価の記入を楽にする
- CorpSの目標・プロジェクトDBと週報DBをつなぐことで、目標に対する実績をスムーズに振り返れるようにしたい
- データ分析によるリスク検出・トピック抽出の半自動化
- Notion AI等を活用して、週報データから「リスクの予兆」や「チーム横断的なトピック」を半自動的に抽出する仕組みを作りたい
- Slackのエクスポートの自動化
- Data Access APIが出てきているのでそちらを利用した、エクスポートを利用しない方法も考えられる
- Enterprise環境では定期的なエクスポートがサポートされていないため手動で行なっています。Discovery APIを使えば自動化の可能性もあるので今後検証していきたい
このあたりを次のステップとして考えています。
部内での展開が進み、本ワークフローを下敷きにNotion AIで評価入力を効率化する動きが出てきました。 AIに扱いやすい構造化データを整えておくことで、評価・振り返り・ナレッジ共有などの二次利用が加速します。
7. おわりに
今回紹介した週報アプリは、
- Slack上のやり取りという“生ログ”を
- AWS（Lambda／SQS／S3／Bedrock）で処理して
- Notion上の週報DBに“読みやすい形”で返す
という、コーポレートエンジニアリングならではの「業務改善の仕組みづくり」の一例だと思っています。
複数のSaaSとクラウドを組み合わせて社内向けの仕組みを作るのが好きな方や、普段使っているSlackやNotionを活用して業務フローを改善することに興味を持たれた方は、ぜひお気軽にカジュアル面談にご応募ください。私自身は関西勤務ですが、拠点に関わらず柔軟に働ける環境です。一緒に業務改善に取り組める方をお待ちしています。
