Teamsの返信漏れをClaudeに拾わせ、返信案まで書かせている話

この記事のポイント

• 私は全部署に関わる立場で、確認するチャネル・投稿が多く、見落としと返信漏れが起きていました。
• 平日の朝、業務チャットの投稿をClaudeに読ませ、返信漏れ・自分宛のタスク・重要事項をレポートにしています。
• 返信漏れには過去の返信の傾向と実例に合わせた返信案を付け、実際の返信との差で実例とルールを毎朝更新しています。
• 400件規模のチャネルから27件に絞り、セクション構成と判定ルールはファイルに書いて毎朝読ませています。
• 権限は委任アクセス許可のみで、本人が見られる範囲しか読めません。管理者同意が前提になります。
• 私と同等の返信案が書けるようになったら返信をbotに任せ、人が判断すべきことに集中できるようにしていく展望です。

要点サマリ

当社では社内の連絡も重要な決定の指示も大半が業務チャットに集まりますが、確認すべきチャネルと投稿が多く、見落としと返信漏れが発生していました。

その対策として、自分の側で止まっている項目を毎朝挙げさせる日次チェックレポートを運用しています。
返信漏れの各項目には、私の過去の返信の傾向と実例に寄せた返信案を付けています。
案は実際の返信と毎朝突き合わせ、その差で書き方を直しています。

この案が私と同等の水準になれば、単純な確認やフォローへの返信はbotに任せるつもりです。

用語解説

• Microsoft Graph API：Microsoft 365の各サービスが持つデータをプログラムから読み書きするための共通の窓口。今回はチャットの投稿を取得するために使っている。
• 返信スレッド：チャットの投稿にぶら下がる返信の連なり。一覧取得のAPIは親の投稿しか返さないため、返信は別に取得する必要がある。
• リアクション：投稿に付ける絵文字による反応。本文の返信を伴わず、リアクションだけで承認や受領が示されることが多い。
• MCP：AIが外部のサービスやデータへアクセスするための接続方式。今回はTeamsを読むための窓口として使っている。
• 委任アクセス許可：サインインした本人の権限の範囲でAPIを呼ぶ方式。アプリ自体に権限を与えるアプリケーション権限と異なり、本人が見られないものは読めない。
• 一致度：返信案と実際の返信がどれだけ似ているかを0〜1で表した値。1に近いほど、案がそのまま使えたことを示す。

返信漏れを仕組みで拾うことにした理由

当社の社内コミュニケーションは、その大部分が業務チャットのチャネル上で行われています。
案件依頼、部署間の相談、重要な決定の指示、周知連絡など、さまざまな情報のやり取りを全従業員がTeams上で行っています。

私は営業部・管理部・情報技術部の3部署すべてに関わる立場にあり、どの部署のチャネルも自分の担当範囲に入ります。参加しているチームは十数、チャネルは案件個別のものを含めて400件規模あります。

確認すべき量がこれだけあると、見落としと返信漏れが発生しやすくなります。アクティビティの一覧を片端から見ていく運用でしたが、途中で別の用件が挟まると返信を忘れてしまいます。

返信が滞ると、相手はいつ返事が来るか分からないまま待つことになります。督促が来てから気づくようでは遅く、督促する手間も相手に負わせています。

日次チェックレポートの仕組みと対象範囲の絞り込み

そこで、自分の側で止まっている案件が無いかを毎朝レポートさせることにしました。
具体的には平日の朝、業務チャットの投稿をClaudeに読ませ、返信漏れ・自分宛のタスク・重要事項をまとめたレポートをmd形式で出力します。

読み取りにはMicrosoft Graph APIを使い、指定したチャネルの親メッセージと返信スレッド、それぞれに付いたリアクションを取得します。

出典：List channel messages – Microsoft Graph v1.0 | Microsoft Learn

400件規模のチャネルを毎朝全件読むのは現実的ではありません。1か月分の投稿を調べ、自分への依頼・判断要求・重要な判断が実際に流れていたチャネルだけを残して27件に絞りました。およそ15分の1です。

判断の目安は、自分が投稿・返信しているチャネルかどうかです。読むだけのチャネルは案件情報を集約しているチャネルで拾えるため、個別には加えていません。

MCPの設定と必要な権限

まず、Teamsを読むためのMCPの設定から着手しました。
同じ仕組みを作る場合に必要な権限設定を以下に示しています。

{
  "mcpServers": {
    "ms365-teams": {
      "command": "npx",
      "args": [
        "-y", "@softeria/ms-365-mcp-server",
        "--org-mode",
        "--preset", "teams",
        "--read-only",
        "--allowed-scopes",
        "Chat.Read ChatMessage.Read ChatMember.Read Team.ReadBasic.All Channel.ReadBasic.All ChannelMessage.Read.All"
      ],
      "env": {
        "MS365_MCP_CLIENT_ID": "(自社テナントに登録したアプリのID)",
        "MS365_MCP_TENANT_ID": "(自社テナントのID)"
      }
    }
  }
}

起動オプションの役割は4つです。

要求しているアクセス許可は6つです。

リアクションを読むための専用のアクセス許可はありません。投稿を取得すると、それに付いたリアクションも一緒に返ってきます。

押さえておくべき点が2つあります。

1. すべて委任アクセス許可です。
   アプリケーション権限ではないため、サインインした本人が見られる範囲しか読めません。
   本人が参加していないチームのチャネルは、対象リストに書いても取得できません。
   組織全体を横断して読む用途には、この構成は使えません。
2. 末尾に .All が付くものはテナント管理者の同意が必要です。
   Entra IDへのアプリ登録と管理者同意が前提になるため、情報システム部門との調整を先に済ませる必要があります。
   自分のアカウントだけでは完結しません。

読み取り専用にする手段を3層で重ねているのは、どれか1つが外れても書き込みに至らないようにするためです。

実装前に決めたレポートの仕様

手順を書き始める前に、何をどう載せるかを先に決めました。レポートのセクションは5つに固定しています。

該当が無いセクションも、消さずに「該当なし」と1行残させています。セクションごと消えると、読む側は該当が無かったのか読まれなかったのかを区別できないからです。

前提として、当社では「確認しました」という返事を本文で書く必要はなく、リアクションだけで済ませてよいことにしています。そのため、承認・受領・同意が”👍”だけで示され、返信が1件も付かないまま終わるスレッドが多くあります。

ただし、絵文字が付いていれば一律に完了とみなせるわけではありません。

判定ルールのうち、実運用で外せないのが次の3つです。いずれも「観測できた事実 ⇒ どう扱うか」の形で書いています。

• 自分がリアクションを付けている ⇒ 本人が見て了解した証拠になるため、返信漏れに含めない
• 依頼の宛先が自分以外で、自分は共有先としてメンションされているだけ ⇒ 自分の回答待ちではないため、含めない
• 決着しているかどうか確認できない ⇒ 迷ったら載せる。確認できないことを、報告を控える理由にしない

※「迷ったら載せる」は、決着済みの項目が混ざることを許す代わりに、見落としを減らすための指定です。

チャット上で確認できない事柄は断定させず、観測できる事実だけを書かせます。

実装内容

構成は、平日朝に起動する定期実行タスク1つと、それが読むファイル群です。新しくプログラムを書いたわけではなく、Claudeに渡す手順と対象範囲をファイルとして持たせただけです。

毎朝の処理は次の順で進みます。

1. 仕様と実例集を読む
2. 親メッセージ・返信スレッド・リアクションを取得する
3. 5セクションへ分類する
4. 返信漏れの各項目に返信案を書く
5. 前回までの返信案を実際の返信と照合し、実例集と書き方のルールを更新する
6. Teamsのディープリンク付きで出力し、状態を更新する

チャネル件数や判定条件を手順側に書き写さず、毎回リストのほうを基準として読ませています。

実行手順ファイルは自然言語で書いています。
抜粋すると次のような内容です。固有のIDやファイルパスは伏せています。

---
name: teams-daily-digest
description: 対象27チャネルの新規投稿と返信を読み、返信漏れ・本人のタスク・重要事項を
             Teamsリンク付きでレポート化する(平日8:50)
---

このセッションの目的は、Teamsの対象チャネルを読み、本人が確認すべき重要事項・本人の
タスク・返信漏れを1本のレポートにまとめること。ナレッジ化は行わない。

## Step 0: 仕様を読む

以下2ファイルを必ず読んでから作業を始める。対象チャネルの一覧・レポート仕様・
リンク形式・状態管理はすべてこの2ファイルに書かれている。

1. 読み取り許可リスト — 読み取り可否の基準。とくに運用ルール5(禁止データは記録しない)と
   7(返信スレッドを必ず読む)
2. 対象リスト — 対象チャネルの表(件数は表が基準)、レポート仕様、リンク形式、状態管理

## Step 2: 返信スレッドを必ず読む

**親メッセージだけで「未返信」「停滞」と判定することは禁止。** 当社のTeams運用では
判断・回答・完了報告がほぼ返信側に集中する。

## Step 2.5: リアクションを必ず確認する

**返信本文だけで「未回答」と判定することも禁止。** 当社では承認・受領・同意が
リアクション(👍等)だけで示され、返信が1件も付かないまま完結するスレッドが多数ある。

- リアクションを付けたのが本人であれば、本人は確認済み。返信漏れに計上しない。
- 依頼の宛先が本人以外で、その宛先本人がリアクションを付けている場合も、本人はメンションに
  よる共有先にすぎないため返信漏れに計上しない。

## 禁止事項

- 対象表に無いチャネル、および許可リストで除外されているチャネル・チャットを読まない。
- Teamsへの投稿・返信を行わない(読み取り専用だが、意図としても書き込みは行わない)。
- チャネルの「ファイル」タブ・共有ファイルサーバーへアクセスしない。

手順の側に「返信スレッドを読む」「リアクションを確認する」を独立したStepとして置いているのは、当社では判断と完了報告が返信側とリアクション側に寄るからです。親メッセージだけを読む ⇒ 回答済みのものが未回答として並ぶ、という関係になります。

状態ファイルを持たせているのは、経過日数を出すためです。どれから手を付けるかは、内容よりも滞留している日数で決まることが多いと思います。

出力されたレポート

実際に出てくるレポートは次のような形です。日付・件名・発言者はすべて架空のものに差し替えた、形式を示すためのサンプルです。

# Teams日次チェックレポート 2026-06-08(月)

対象期間: 2026-06-05 09:00 〜 2026-06-08 09:00 / 対象チャネル: 27件

期間内の新規投稿は9チャネル・9件(うちBot通知1件、システムイベント3件)。

## 1. 返信漏れ

- **社内研修の実施日 — 候補2案のどちらにするか** — ○○チーム > General / 最終発言: 部長(06-05 17:42)(経過1日)
  本人が挙げた2案に対し、どちらでも都合が付くと返信されています。実施日の確定で止まっています。
  返信案: 6/24で確定とします。会場の手配と参加者への周知をお願いします。
  (実際の返信と自動照合します)
  [Teamsで開く](...)

- **来期の目標値の前提確認** — ○○チーム > 案件情報 / 最終発言: マネジャー(06-03 11:20)(経過3日)
  本人宛のメンションあり。数値の前提について確認を求められていますが、返信・リアクションとも付いていません。
  返信案: 判断が必要。前提にしている数値の出所を確認します。「前年実績ベースですか、受注見込みを含めた数字ですか。」
  (実際の返信と自動照合します)
  [Teamsで開く](...)

## 2. 本人のタスク・期限

- **勤怠入力 — 本日より管理部が集計開始** — ○○チーム > General / 最終発言: 管理部担当(06-05 15:09)
  入力期限は06-05(金)。「まだの方は本日中に対応を」との連絡が営業部宛に出ています。
  本人は元投稿に👍済みですが、営業部への一斉連絡のため本人自身の対応要否は要確認。
  [Teamsで開く](...)

- **月次締め処理の完了期限 06-12(金)** — ○○チーム > General / 最終発言: 本人(05-25 15:07)
  本人が管理部へ指示済み。上記の集計開始がその前提工程にあたります。
  [Teamsで開く](...)

## 3. 重要事項

- **06-17(水)の定例会議は中止確定** — ○○チーム > General / 最終発言: 役員(06-05 10:58)
  延期なしで中止。2日分のみの報告になるため、翌週に6営業日分をまとめて報告する方針。
  [Teamsで開く](...)

## 4. チャット上で本人の発言が最後のもの

- **社内備品の管理区分の件** — ○○チーム > General / 本人(06-01 16:44)「割り振りに違和感はないです」(経過7日)
  チャット上は本人の発言で止まっています。翌日に別のチャネルで方針が実務担当へ展開されており、
  実質的に決着していると読めます。
  [Teamsで開く](...)

## 5. 参考

- (省略)

2番目の項目には「本人自身の対応要否は要確認」と書かれており、断定させていません。
4番目は別のチャネルを見れば決着していると読める件ですが、それでも項目としては残しています。

落とすかどうかは読む側が決めます。

返信漏れに返信案を付ける

返信漏れの各項目には、上のサンプルのように返信案を1つ付けています。
案は、Teamsの過去7年分のやり取りから私自身の返信約1.2万件を分析し、その傾向に合わせて書かせています。

傾向の数字だけでは言い回しまでは寄らないため、案を書く前に、私の実際の返信を「相手の発言と私の返信」の対で集めた実例集も読ませています。
相手の発言は、メンションと表示名を伏せて保存しています。
保持するのは最大40件で、短い了解だけの返信は4件まで、1スレッドからは2件までに制限し、判断の型が偏らないようにしています。

案がどうだったかは、私が実際に投稿した返信と突き合わせて判定させています。翌朝以降に同じスレッドを読み直し、私の返信が見つかれば一致度を出したうえで、案と実際の返信の差を記録します。

当初は評価欄に私が記入する方式でしたが、最初の2件とも理由が空欄のままで、改善に使えませんでした。実際の返信を正解とすれば、私が何も書かなくても、案に何が足りなかったかが差として残ります。

突き合わせの結果は、次の2つの形で翌朝以降の案に反映させます。

※AIのモデル自体を追加で学習させているわけではなく、実例とルールを毎朝読ませて書き方を寄せています。

差から分かったことの例です。

• 作業完了の報告に対し、案は状況を問う形だったが、私は問わずに次の作業を指示していた
• ただし、私の質問に相手が答えた場面では、私は受け止めて閉じるだけだった ⇒ 「問わずに指示する」は、相手の作業の起点になる場面に限って当てはめる
• 返信が要らない受領連絡にまで案を出していた ⇒ 案を書く前に、返信が必要かどうかを判定する

案はレポートに載せるだけで、Teamsへは投稿しません。件数が貯まって精度を測れるまでは、自動返信には進めない方針です。

返信案を使った今後の展望

私と同等の返信案が書けるようになったら、私のbotを作成して、それに簡易な返信を任せたいと考えています。
私はbotが返した結果をまとめて読み、問題があるところだけを別途フォローします。

私にしか決められない項目には今も案を書かせておらず、bot化した後もそこは私が返します。

AIで代替できる部分はAIに任せ、空いた時間はAIにはできないことに使います。

• チャットに残らないオフラインの情報を踏まえた判断
• 顔色や様子の変化に気づいて声をかけること
• お客様と直接会って話すこと

AIに任せた分の時間をこうしたことに充てられれば、世の中は今より少し豊かになると思います。

FAQ

Q1：今の構成のまま、botに返信させることはできますか？

A：できません。
今の構成は、権限・ツール・運用の3層で読み取り専用にしており、投稿用のアクセス許可を要求していないからです。bot化する段階で、投稿用のアクセス許可の追加と情報システム部門との調整が必要になります。3層の読み取り専用のうち、どこまでを外すかもその時点で決めます。

Q2：botが誤った返信をした場合はどうしますか？

A：まとめて読む段階で私が気づき、訂正の返信を入れます。
誤った返信と私の訂正の差は、今の返信案と同じく実例集と書き方のルールの更新に使えます。

まとめ

業務チャットの投稿を毎朝Claudeに読ませ、返信漏れ・自分宛のタスク・重要事項を1本のレポートにまとめています。400件規模のチャネルのうち27件を対象とし、セクション構成と判定ルールはファイルに書いて毎朝読ませています。返信漏れには私の返信に寄せた案を付け、実際の返信との差で毎朝直しています。

AIに任せられることは任せ、人は人にしかできないことに時間を使います。

関連ページ

Claude Codeのmodsで残タスクやメール、Teamsの返信漏れをダッシュボードに組み込む – アサミ情報システム株式会社｜GIS/3D/CityGML

AIに住所クレンジングを依頼してわかった、プロンプト設計のコツと限界 – アサミ情報システム株式会社｜GIS/3D/CityGML