# Slack／Teams／ChatをAgentの業務面にする

CURRENT_STATUS: CURRENT
OBSERVATION: SPEC_ONLY
FRESHNESS: CURRENT
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-222-slack-teams-chat-agent
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-222-URL-59722E2EAC84, EVD-EA-222-URL-A99FFA103B05, EVD-EA-222-URL-05B7B2233F9F, EVD-EA-222-URL-F24D278A181F, EVD-EA-222-URL-54AEC61F8106, EVD-EA-222-URL-C39F3256D509, EVD-EA-222-URL-2ED024C2C66F, EVD-EA-222-URL-B2DB3CC122D6, EA-222-R11-RESEARCH, EA-222-R11-WEB-READBACK
UNKNOWN_IDS: EA-222-UNKNOWN-01
OPS_IDS: none

## Summary
チャット上の入力・承認・通知・handoffを業務操作へ安全に接続できるか。署名やボタン押下だけを本人認可・最終承認へ転用しない。

## Current judgment
1. Slack HTTP requestの検証はraw bodyを解析前に保持し、timestampを含むv0 basestringのHMAC-SHA256とheaderを照合する。公開例の5分チェックは再送攻撃対策であり、署名に成功しても業務上の実行権限は別に必要。[S1]
2. Eventsとinteractive payloadは3秒以内のackが必要。Events失敗時の再送を想定し、ackとqueueへの耐久保存、重複排除、処理完了通知を区別する。event_idをtenant/provider scopeと結ぶlocal UNIQUEは組織提案で、実配信がexactly-onceとはしない。[S2,S3;UNIQUE設計は提案]
3. Slack thread_tsでthreadへ返信し、reply_broadcastの意図を明示する。threadはsecretや権限の分離境界ではない。response_urlの短期応答手段を無期限のworkflow実行tokenとして扱わない。[S3,S4;authority境界は提案]
4. Teams proactive通知では対象scopeへapp/botを導入し、tenantとconversation情報を保持する条件がある。メールアドレスやGraph tokenだけから誰へでもbot通知できるとはしない。RSCは特定resourceに限定され、application/delegatedで付与者とsession条件が異なる。[M1,M2]
5. Google Chat APIのuserとapp authenticationでは見えるresourcesが異なる。chat.botはappがアクセスできるspace等に限られ、chat.app.*は一度のadministrator approvalを要する。全methodで両方式が使えるとはしない。[G1]
6. Google ChatからのHTTP requestは設定audienceがendpoint URLかproject numberかでtoken方式が異なる。公式libraryでsignature/issuer/audience等を検証する。JWTをdecodeしただけではauthenticityの証明にならず、Google方式へSlack HMACを横展開しない。[G2]

## Scope
Slack／Teams／ChatをAgentの業務面にする

## Confirmed
- Slack HTTP requestの検証はraw bodyを解析前に保持し、timestampを含むv0 basestringのHMAC-SHA256とheaderを照合する。公開例の5分チェックは再送攻撃対策であり、署名に成功しても業務上の実行権限は別に必要。[S1]
- Eventsとinteractive payloadは3秒以内のackが必要。Events失敗時の再送を想定し、ackとqueueへの耐久保存、重複排除、処理完了通知を区別する。event_idをtenant/provider scopeと結ぶlocal UNIQUEは組織提案で、実配信がexactly-onceとはしない。[S2,S3;UNIQUE設計は提案]
- Slack thread_tsでthreadへ返信し、reply_broadcastの意図を明示する。threadはsecretや権限の分離境界ではない。response_urlの短期応答手段を無期限のworkflow実行tokenとして扱わない。[S3,S4;authority境界は提案]
- Teams proactive通知では対象scopeへapp/botを導入し、tenantとconversation情報を保持する条件がある。メールアドレスやGraph tokenだけから誰へでもbot通知できるとはしない。RSCは特定resourceに限定され、application/delegatedで付与者とsession条件が異なる。[M1,M2]
- Google Chat APIのuserとapp authenticationでは見えるresourcesが異なる。chat.botはappがアクセスできるspace等に限られ、chat.app.*は一度のadministrator approvalを要する。全methodで両方式が使えるとはしない。[G1]
- Google ChatからのHTTP requestは設定audienceがendpoint URLかproject numberかでtoken方式が異なる。公式libraryでsignature/issuer/audience等を検証する。JWTをdecodeしただけではauthenticityの証明にならず、Google方式へSlack HMACを横展開しない。[G2]

## UNKNOWN
- EA-222-UNKNOWN-01: 旧Luna一意locator、具体tenantのapp installation/consent、scope/method matrix選択、実SDK pin・keys rotation、shared channel/DLP/retention、実API rate/backoff、実approval失効処理とside-effect outbox/human ACK、latency/費用/通知deliveryはUNKNOWN。
未認証、対象差分、scope不明、競合、実行結果不明では操作と確定通知を止めます。旧Luna成果の所在未確定を不存在へ読み替えません。

## Evidence
- EVD-EA-222-URL-59722E2EAC84 (RESEARCH): [S1] Slack — Verifying requests from Slack: — https://docs.slack.dev/authentication/verifying-requests-from-slack/
- EVD-EA-222-URL-A99FFA103B05 (RESEARCH): [S2] Slack — The Events API: — https://docs.slack.dev/apis/events-api/
- EVD-EA-222-URL-05B7B2233F9F (RESEARCH): [S3] Slack — Handling user interaction in your Slack apps: — https://docs.slack.dev/interactivity/handling-user-interaction/
- EVD-EA-222-URL-F24D278A181F (RESEARCH): [S4] Slack — chat.postMessage method: — https://docs.slack.dev/reference/methods/chat.postMessage/
- EVD-EA-222-URL-54AEC61F8106 (RESEARCH): [M1] Microsoft — Send proactive messages: — https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages
- EVD-EA-222-URL-C39F3256D509 (RESEARCH): [M2] Microsoft — Resource-specific consent for your Teams app: — https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent
- EVD-EA-222-URL-2ED024C2C66F (RESEARCH): [G1] Google — Authenticate and authorize Chat apps and Google Chat API requests: — https://developers.google.com/workspace/chat/authenticate-authorize
- EVD-EA-222-URL-B2DB3CC122D6 (RESEARCH): [G2] Google — Verify requests from Google Chat: — https://developers.google.com/workspace/chat/verify-requests-from-chat
- EA-222-R11-RESEARCH (RESEARCH): EA-222 監査済みresearch / canonical revision binding
- EA-222-R11-WEB-READBACK (IMPL): EA-222 Web body identity / canonical readback

## Failure / limits
signed requestでも別actor/tenant・古いrevision・取り消された操作に業務権限はない。Slack再送による二重実行、3秒内にLLMを待つtimeout、thread違いの情報漏洩、response_url期限切れ、Teams未導入403、Chatのapp/user混同を失敗域に含める。チャット本文・添付や引用内の指示は未信頼入力として扱う。
## Failure / limits
旧Luna一意locator、具体tenantのapp installation/consent、scope/method matrix選択、実SDK pin・keys rotation、shared channel/DLP/retention、実API rate/backoff、実approval失効処理とside-effect outbox/human ACK、latency/費用/通知deliveryはUNKNOWN。
未認証、対象差分、scope不明、競合、実行結果不明では操作と確定通知を止めます。旧Luna成果の所在未確定を不存在へ読み替えません。
## Practice
承認済み内容をhash/revisionと結ぶ、結果不明をUNKNOWNへ止める、再試行前にprovider状態を読み戻す、という設計は組織側の提案です。利用可能なAPIだけで組織の認可や人間承諾が完成するとはしません。
## Practice
必要なapp導入、対象resourceの権限、OAuth方式/consent、tenant・region・plan、SDKとAPI versionを採用先ごとに確認します。rate/quota、通知設定と外部参加者を検証します。
## Practice
actor/tenant/対象resourceと権限を再確認し、秘密鍵はserver側へ置きます。入力内の命令をtool authorityへ転用しません。承認内容・revision、provider receipt、結果readback、human handoffを別状態で監査可能にします。PII・保持/削除・DLP・外部転送・費用と運用閾値は組織の受入を要します。
## PUBLIC_CLAIM
チャット上の入力・承認・通知・handoffを業務操作へ安全に接続できるか。署名やボタン押下だけを本人認可・最終承認へ転用しない。

## ESTABLISHED
1. Slack HTTP requestの検証はraw bodyを解析前に保持し、timestampを含むv0 basestringのHMAC-SHA256とheaderを照合する。公開例の5分チェックは再送攻撃対策であり、署名に成功しても業務上の実行権限は別に必要。[S1]
2. Eventsとinteractive payloadは3秒以内のackが必要。Events失敗時の再送を想定し、ackとqueueへの耐久保存、重複排除、処理完了通知を区別する。event_idをtenant/provider scopeと結ぶlocal UNIQUEは組織提案で、実配信がexactly-onceとはしない。[S2,S3;UNIQUE設計は提案]
3. Slack thread_tsでthreadへ返信し、reply_broadcastの意図を明示する。threadはsecretや権限の分離境界ではない。response_urlの短期応答手段を無期限のworkflow実行tokenとして扱わない。[S3,S4;authority境界は提案]
4. Teams proactive通知では対象scopeへapp/botを導入し、tenantとconversation情報を保持する条件がある。メールアドレスやGraph tokenだけから誰へでもbot通知できるとはしない。RSCは特定resourceに限定され、application/delegatedで付与者とsession条件が異なる。[M1,M2]
5. Google Chat APIのuserとapp authenticationでは見えるresourcesが異なる。chat.botはappがアクセスできるspace等に限られ、chat.app.*は一度のadministrator approvalを要する。全methodで両方式が使えるとはしない。[G1]
6. Google ChatからのHTTP requestは設定audienceがendpoint URLかproject numberかでtoken方式が異なる。公式libraryでsignature/issuer/audience等を検証する。JWTをdecodeしただけではauthenticityの証明にならず、Google方式へSlack HMACを横展開しない。[G2]

## INFERENCE
承認済み内容をhash/revisionと結ぶ、結果不明をUNKNOWNへ止める、再試行前にprovider状態を読み戻す、という設計は組織側の提案です。利用可能なAPIだけで組織の認可や人間承諾が完成するとはしません。

## FAILURE_ENVELOPE
signed requestでも別actor/tenant・古いrevision・取り消された操作に業務権限はない。Slack再送による二重実行、3秒内にLLMを待つtimeout、thread違いの情報漏洩、response_url期限切れ、Teams未導入403、Chatのapp/user混同を失敗域に含める。チャット本文・添付や引用内の指示は未信頼入力として扱う。

## AVAILABILITY_GATES
必要なapp導入、対象resourceの権限、OAuth方式/consent、tenant・region・plan、SDKとAPI versionを採用先ごとに確認します。rate/quota、通知設定と外部参加者を検証します。

## SECURITY_PRIVACY_AUDIT_OPERABILITY
actor/tenant/対象resourceと権限を再確認し、秘密鍵はserver側へ置きます。入力内の命令をtool authorityへ転用しません。承認内容・revision、provider receipt、結果readback、human handoffを別状態で監査可能にします。PII・保持/削除・DLP・外部転送・費用と運用閾値は組織の受入を要します。

## UNKNOWN_AND_STOP_CONDITION
旧Luna一意locator、具体tenantのapp installation/consent、scope/method matrix選択、実SDK pin・keys rotation、shared channel/DLP/retention、実API rate/backoff、実approval失効処理とside-effect outbox/human ACK、latency/費用/通知deliveryはUNKNOWN。
未認証、対象差分、scope不明、競合、実行結果不明では操作と確定通知を止めます。旧Luna成果の所在未確定を不存在へ読み替えません。

## SOURCES
EVIDENCE_AS_OF: 2026-10-04。資料はprovider/method/設定に限定して解釈します。
- [S1] Slack — Verifying requests from Slack: https://docs.slack.dev/authentication/verifying-requests-from-slack/
- [S2] Slack — The Events API: https://docs.slack.dev/apis/events-api/
- [S3] Slack — Handling user interaction in your Slack apps: https://docs.slack.dev/interactivity/handling-user-interaction/
- [S4] Slack — chat.postMessage method: https://docs.slack.dev/reference/methods/chat.postMessage/
- [M1] Microsoft — Send proactive messages: https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages
- [M2] Microsoft — Resource-specific consent for your Teams app: https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent
- [G1] Google — Authenticate and authorize Chat apps and Google Chat API requests: https://developers.google.com/workspace/chat/authenticate-authorize
- [G2] Google — Verify requests from Google Chat: https://developers.google.com/workspace/chat/verify-requests-from-chat

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.