Claude Code Slack連携とは？@メンション一言で要約・集計を返す非エンジニアの始め方

「あの集計、金曜までにお願いできますか」。そう打ち込んで、エンジニアの手が空くのを待つ。返ってくるのは翌週。その頃には数字の鮮度も、自分の集中も、とうに冷めている。この待ち時間に心当たりがあるチームリーダーは少なくないだろう。

その待ち時間を縮める導線が、2025年12月8日に生まれた。この日、AnthropicはClaude CodeをSlackから直接呼び出す機能をベータ版 (Research Preview) としてリリースした。Claude Code Slackは、SlackのメッセージからClaude Codeのコーディングセッションを起動し、集計や修正を会話の場で完結させる連携機能を指す。

仕組みは拍子抜けするほど素朴だ。Slack内のClaudeアプリが、投げられたメッセージをコーディング関連のタスクかどうか自動で判定する。コーディングタスクと判断すれば、claude.com/codeでリモートセッションを自動で立ち上げる。バグ報告のスレッドに一言添えるだけで、これまで人の手を待つしかなかった小さな修正が動き出す。

この変化の重みは、それ以前を知る人ほど分かる。Zennで統合機能を検証した技術ブロガーのkimkiyong氏は、変わった一点をこう書いている。

会話が作業の起点になり、kimkiyong氏のチームでは翌朝にエンジニアへ声をかける習慣そのものがなくなった。

入り口はもっと手前にもある。Anthropicのヘルプセンターによれば、任意のスレッドで@Claudeをメンションするだけで会話にClaudeが加わる「スレッド参加」が用意されている。Slackを離れずに操作が完結する設計だ。しかもClaudeが参照するのは、あなたがアクセスできる公開・非公開チャンネルのみ。公開スレッドでの応答案はまずプライベートで下書きされ、レビュー・編集・再生成を経てから共有される。操作の主導権は最後まで書き手の側に残る。

会話がそのまま作業の起点になる。依頼して待つ一段が、消える。

もっとも、「メッセージ1本ですべてが済む」とまでは言い切れない。Claude CodeのSlack呼び出しはまだベータ版で、環境によってはMCP (AIが外部ツールと連携する接続規格) やAPIキーの下準備が必要だ。この統合自体も2026年8月3日に新しい「Claude Tag」エクスペリエンスへ切り替わる予定だ。導入は、その前提を踏まえたうえで進めたい。

会社の業務データをSlack経由でAIに渡すことに不安があるなら、まず自分がアクセスできる非公開チャンネルで試す。応答案はプライベート下書きで確認してから共有すれば、社外に情報が出る前に必ず一度目を通せる。

では、Slack上のClaudeは実際に何を返してくれるのか。翌日のスケジュール抽出から、ファイル整形、議事録の整理まで、次章ではブログやスライドで実名で公表されている10のユースケースを一覧にする。そのどれが自分の「待ち時間」を消すのか、見比べてほしい。

毎日夕方、翌日の予定をカレンダーから拾い、抜けがないか確かめてから手帳に書き写す——この地味な15分を、DevelopersIO (クラスメソッド社の技術ブログ) に寄稿した非エンジニアの筆者は手放した。ClaudeのSlackとGoogleカレンダー連携を使い、翌日スケジュールを自動抽出して自分のDMに届けるタスクを組んだのだ。本人はその設定をこう振り返っている。

コードを一行も書かず、日々の転記が消えた。同じように「これは自分の業務だ」と指をさせるものが、実名で公表された使い方の中に必ずある。以下は、ブログ・スライド・技術記事で発信者がはっきりしている10のユースケースを、指示文の例と成功確認の目安まで含めて並べたものだ。自分の週次業務と照らしながら見てほしい。

1. 1翌日スケジュールのDM配信。hosomi氏(DevelopersIO)がSlackとGoogleカレンダー連携で実装済み。まずはClaudeの初期設定でSlackとカレンダーの連携を有効にし、「毎日夕方に、翌日のスケジュールをGoogleカレンダーから抽出してSlackのDMに送って」と依頼する。翌日の朝、自分のDMに前日夕方の通知が届いていれば成功だ。

1. 2過去メッセージ・スレッドの検索と要約。長い議論を追いかけ直す手間は、対象チャンネルで@Claudeに「このスレッドを3行で要約して」と頼むところから始まる。返ってきた要約を読んで、実際のやり取りの結論と食い違っていないかを自分の目で確認できれば、そのまま使ってよい。

1. 3顧客問い合わせへの返信案の下書き。npaka氏(note.com)は「重要なメッセージへの返信案を下書きしたり」という使い方を紹介している。返信に迷うメッセージのスレッドで@Claudeをメンションし、「この問い合わせへの返信案を作って」と頼む。プライベートな下書きとして返ってくるので、送信前に自分で文面を直せるかどうかが判断基準になる。

1. 4会話からのタスク抽出。議事録やブレストのスレッドから「誰が・いつまでに・何を」を切り出す作業は、対象スレッドで「担当と期限を表にして」と指示するのが入口だ。出てきた表の担当者名と期限が、実際の発言と一致しているかを見比べれば、精度を確認できる。

1. 5日報・週次レポートのドラフト作成。箇条書きのメモをClaudeに渡し、「このメモを既存フォーマットに沿った文章にして」と頼む。出てきた文章が普段の報告書の構成・トーンに近ければ、そのまま清書に回せる。

1. 6ファイル整形・データ整理。tama_san氏(note.com)はZoom録音のリネームや無音カット、KDP (Amazonの電子書籍出版サービス) 原稿のマージン調整とPDF整形を日常的にClaude Codeへ任せている。まずは「このフォルダの音声ファイルを、日付と内容が分かる名前にリネームして」など、繰り返している作業を1種類だけ言葉で書き出して試す。処理後のファイル名や体裁を実際に開いて確かめれば、次から任せられるかが分かる。

1. 7複数カレンダーの横断同期。同じくtama_san氏は、仕事用と個人用に加え、合計5アカウントに分かれていたGoogleカレンダーを、都度まとめて同期する仕組みを構築した。手動転記で漏れが出ていた経験がある人は、対象アカウントを列挙して「これらのカレンダーの予定を漏れなく同期して」と伝えるところから始めるとよい。翌週の予定が抜けなく反映されているかを見れば、成功したかどうかが分かる。

1. 8外部サービスとの連携によるカレンダー・メール操作。speakerdeck資料「Claude Coworkで非エンジニアも業務効率化しよう」は、Gmail・Google Calendar・ChromeなどとつながるコネクタをCoworkの機能として紹介している。アプリを切り替えず「来週の空き時間を探して、候補をメールの下書きにして」のように頼めば、Cowork上で予定確認と下書き作成が完結する。実際のカレンダーとメール下書きを開いて、提示された空き時間や文面に誤りがないかを確認する。

1. 9Slackのバグ報告からコード修正・Pull Request作成まで。Yusuke Sakai氏(KDDIアジャイル開発センター)はQiitaで、Slackのメッセージ内容をコンテキストにClaude CodeがGitHubリポジトリへアクセスして修正を行い、Pull Requestの提出まで進む流れを検証している。README整備やテスト追加のような小さな依頼を@Claudeへのメンションで出すのが入口だ。修正内容はPull Requestの差分として残るので、マージ前に必ず人の目で確認する。

1. 10チーム全員がSlackからコード調査を頼める社内ボット。クラスター株式会社のnkjzm氏は、Slackでボットをメンションするとn8n経由でClaude Code Actionが走り、調査結果がそのままスレッドに返る仕組みを技術ブログで公開した。9年続くサービスで「全仕様を把握している人がほとんどいない」状況への打ち手だという。まずは「この機能はどのコードで動いている?」と聞ける窓口チャンネルを1つ作るところからで、返ってきた回答を担当エンジニアが照合できれば成功だ。

すべてを一度に組もうとすると、どれも中途半端に終わる。まずは毎週必ず発生し、手順が言葉で説明できるものを1つだけ選ぶ。返信案やレポート作成のように、Claudeの出力を人が最後に確認できる作業から始めれば、失敗のコストも小さい。

自分の週次業務のどれか一つは、この一覧の中にある。

見比べて気づくのは、主人公たちがエンジニアではないことだ。tama_san氏は普通のチャットAIとの違いをこう書く。

その「そこから先」を引き受けてくれるのが、Slack上のClaudeだ。一覧のどれか一つに指が止まったら、あとはそれを自分のSlackで動かす手順に落とすだけでいい。

一覧のどれかに指が止まった。次はそれを、今開いている Slack で動かす番だ。Anthropic のヘルプセンターは、Claude と Slack をつなぐ方法を 2 通り用意している。Claude を自分のワークスペースへ直接追加するか、Claude アプリ側で Slack コネクタ (Claude と外部サービスをつなぐ接続機能) を有効にするか。どちらから入っても、たどり着く先は同じ「@Claude を呼べる状態」だ。

まずはその状態を作るところから、順に手を動かす。

1. 1Claude アプリを開き、Slack コネクタを有効にする。あるいは Claude を自分の Slack ワークスペースへ追加する。この 2 通りのどちらでも統合は始まる。設定後、任意のチャンネルで @Claude と打って候補が出れば、接続は生きている。

1. 2要約したいスレッドで @Claude をメンションし、「このやり取りを 3 行で」と続ける。スレッド参加機能が働き、Slack を離れないまま要約が返る。DevelopersIO 寄稿者の hosomi 氏は、初期設定で Slack と Google カレンダーの連携が済んでいたため、最初のタスクにすぐ進めたと振り返っている。まずは連携済みかどうかを、設定画面で確かめておきたい。

1. 3返信に迷うメッセージのスレッドで @Claude に返信案を頼む。公開スレッドでの応答案の扱い (プライベート下書きからレビューを経て共有される流れ) は次章で詳しく触れるが、ここでも同じ設計が働くため、社外に出す前に必ず一度、自分の目を通す形になる。

1. 4毎日決まって発生する処理を、定期タスクとして登録する。hosomi 氏が実装した翌日スケジュールの DM 配信は、その代表例だ (詳細は前章参照)。設定できたら、翌日の夕方に DM が届くかを確認する。届けば、日々の転記はもう手放せる。

1. 5バグや修正の相談を、そのままスレッドに書く。Slack 内の Claude アプリはコーディング関連のタスクと判断すると claude.com/code でリモートセッションを自動で立ち上げるが、ここはまだベータ版 (Research Preview) のため、起動しないことも珍しくない。その場合は手動で Claude Code (Anthropic 社の AI コーディングツール) にタスクを渡す指示を添えれば、同等の作業を進められる。フォールバックの手順を最初から把握しておくと、自動起動の有無に左右されずにスムーズに動ける。

ここまでの 5 つは、上から順に難度が上がる設計になっている。要約と返信案は @Claude 一言で済むが、定期タスクとコーディングセッションは指示の書き方が結果を左右する。

@Claude の一言が要約になり、定期タスクになり、修正セッションになる。

いきなり定期タスクを組むと、抽出条件が曖昧なまま毎日ズレた DM が届き続ける。最初はスレッド要約や返信案など、出力をその場で確認できる操作で「指示の効き方」を体感してから、無人で回る定期タスクに進むと事故が少ない。

セットアップ手順そのものは、この 5 ステップで足りる。MCP Slack (Model Context Protocol による Slack 連携設定) の設定や API キーの下準備が要る場面もあるが、要約や返信案から始める限り、非エンジニアが今日その日に踏める一歩は @Claude と打つことだけだ。ただし、この手軽さが全員に等しく開かれているわけではない。

Claude Tag への切り替えを控えたベータ版という前提、業務データを AI に渡すことへの社内の抵抗——始める前に確かめておくべき線引きが、まだいくつか残っている。

「メッセージ 1 本で返ってくる」と社内で説明した翌週、部下が Slack に書いた修正依頼が、うんともすんとも言わなかった。この落とし穴は、Claude Code の Slack 呼び出しがまだベータ版 (Research Preview) であることを飛ばして紹介した瞬間に開く。正式版の時期は誰も答えられない。Slack 内の Claude アプリはメッセージがコーディングタスクかどうかを自動判定し、そうと判断すれば claude.com/code でセッションを立ち上げる。しかし、判定を外せば沈黙する。社内説明では「試験運用中の新機能」と一言添え、動かないときは手動で Claude Code にタスクを渡す指示に切り替える。この逃げ道を最初から共有しておけば、部下が固まることはなかった。

要約や返信案なら @Claude のメンションだけで足りる。しかし、「メッセージ 1 本で全部いける」と鵜呑みにして外部システム連携まで一気に頼むと、そこで止まる。ここが前提条件のいちばん誤解されやすい線引きだ。MCP を導入すれば、Claude は Salesforce や freee といった外部システムへ自律的にアクセスでき、毎回ログインする手間は消える (sora-michi 編集部)。裏を返せば、MCP や API キーの下準備が要る領域は @Claude 一発では届かない。代わりに、連携の要らない要約・DM 配信から始め、外部システムを絡める処理は準備が済んでから足す。段を分ければ、最初の一歩でつまずかない。

セキュリティを問われたときに効くのが、参照範囲の設計だ。Slack 上の Claude が読むのは、あなたがアクセスできる公開・非公開チャンネルのみ。npaka 氏 (note.com 技術ブロガー) は、この設計をこう書いている。

この二段構えが、上司への安全性の説明の土台になる。

「参照範囲がチャンネル限定だから学習にも使われない」と混同すると事故る。参照範囲と学習利用は別の話であり、会話データの学習利用はプランで扱いが異なるため、自分の契約プランの規約を一度読んで確かめる。

もっとも、線引きを整えても越えられない壁がある。経営幹部の 99% が 2025 年に AI 投資を計画する一方で、デスクワーカーの約半数 (48%) は AI 利用を上司に打ち明けられずにいる。理由は、不正だと感じる、能力が低いと見られる、怠け者だと見られる、という三つの恐れだ (Slack 調査)。業務データを AI に渡すこと自体に慎重な声も現場には根強い。だからこそ、あなたが手放せる範囲から小さく始めて実績を見せることが、この温度差を埋める最短距離になる。

見えない範囲を勝手に読まず、共有前に必ず自分の目が入る。

その安心材料を握ったまま、次は自分のチームの外へどう広げるかを考える番だ。

自部署でひとつ回り始めると、次に気になるのは「隣の島でも同じことが起きるのか」という点だ。答えの手がかりを、実名と実数で残した会社がある。ただし、これはClaude Code Slackの実績ではない。ISP事業を手がける朝日ネットが、Slack AIを導入して1か月半の効果を社内ブログで公開したものだ。プロダクトは異なるが、「隣の部署に横展開した効果を実名で開示した」という事例が乏しいため、規模感をつかむ材料として参照する。

同社が集めたのは、有効回答約350件——全Slack利用者の約8割にあたる回答だ。数字が薄いアンケートではない。集計すると、削減時間は週あたり805時間に達した。年換算では38,640時間になる計算だが、この数字はあくまで社内アンケートの自己申告を単純に積み上げたもので、外部監査や第三者検証を経てはいない。何人分の稼働に相当するかは、前提となる年間労働時間の置き方次第で結果が変わるため、ここでは踏み込まない。上司に効果を説明するなら、「うちと同じ規模のISP1社が、Slack AIの社内調査でこう報告した」という前提で伝えたほうが、後で数字の出どころを問われて困らない。

内訳を見ると、効果の出どころがはっきりする。同社は「5分以上〜120分以上」の削減を実感した利用者を「強く効果を感じている層」として集計した。

長い議論を短くまとめる、音声の会議を文字に落とす、埋もれた情報を掘り出す——毎日発生する「読む・探す・書き起こす」の3つに、削減時間が集中している。特別な自動化ではなく、誰の一日にもある地味な作業だ。だからこそ、横展開が効く。

削減時間が集中したのは、読む・探す・書き起こす。誰の一日にもある作業だ。

同じ発想をClaude Code Slackに移すとき、実際につまずくのは機能の善し悪しではなく、「どの順で広げるか」「誰が使っていいと判断するか」「動かなかったときにどう戻すか」という運用の設計だ。3つの論点に分けて考えたい。

• 導入順序は、確認の手間が軽い作業から。805時間の内訳が「まとめ」「議事録」「検索」という、人が最後に読んで終われる作業に集中していたように、他部署への展開も、要約や下書きのような「間違っていてもすぐ気づける」業務から始めるほうが定着しやすい。外部システム連携を伴う自動化は、その部署が最初のユースケースに慣れてから回す。

• 承認は、部署のリーダーが最初の1件を見て判断する形にする。全社一斉に解禁するのではなく、隣の部署のリーダーに具体的な使用例を1つ見せ、「この業務なら試してよい」という線引きを本人にさせる。朝日ネットの集計が「全利用者の約8割」という高い回答率で成立したのも、現場ごとに実感を持って使われていたからだ。トップダウンで広げるより、部署単位の小さな合意を積み重ねるほうが実態に近い数字が残る。

• 失敗時の戻し方は、事前に一言決めておく。Claude Code Slackはまだベータ版であり、判定が外れれば反応が返らないことがある。横展開した先の部署でこれが起きると、「使えない」という印象だけが残ってしまう。「動かないときは手動でClaude Codeにタスクを渡す」という代替導線を、展開時のセットで案内しておけば、つまずきが定着を妨げない。

どれも共通するのは、人が最後に出力を確認できる作業を起点にする、という一点だ。805時間の山が「読む・探す・書き起こす」に立ったのと同じように、横展開も、確認の効く軽い作業から積み上げ、承認と戻し方をセットで持たせるほうが崩れにくい。まずは隣の部署のリーダーに、動いている1つの使用例を見せるところから始めればいい。

明日の夕方、まず1つだけ試してほしい。翌日の予定を Slack の DM に届けてもらうか、長いスレッドを 3 行に要約させるか——このどちらかなら、Claude が誤っても手作業に戻るだけで、何も壊れない。Claude Code Slack のはじめ方は、いちばん安く失敗できる場所から入るのが鉄則だ。

なぜこの 2 つなのか。それは、要約と DM 配信が、参照範囲もレビュー導線もあなたの目の届く範囲に収まるからだ。要約なら @Claude に「このやり取りを 3 行で」と頼むだけで済む。返ってきた内容を読んで違えば、そのまま無視すればいい。DM 配信も、自分だけが届くため、他人の目に触れる前に自分で精度を確かめられる。

この 2 つを 1 週間ほど続けてみて、要約の精度に大きな違和感がなければ、次の段階に進む合図だ。返信案の下書きを @Claude に任せる、あるいは会話からタスクを抽出してもらう——公開の場に近づくぶんリスクは上がるが、「読んで捨てる」練習が済んでいれば、下書きを確認してから送る習慣はすでに身についている。逆に、要約がたびたび的外れなら、無理に段階を進めず、しばらく同じ 2 つの使い方にとどまるほうがいい。

いきなり公開チャンネルの返信案から始めると、下書き確認の習慣が身につく前に事故りやすい。自分の DM で届く配信や要約で「読んで捨てる」練習を先に済ませておく。

外部システムを絡めた自動化は、その先の話だ。設定ミスが起きたとき、原因の切り分けが複雑になるため、非エンジニアの最初の一歩としては重すぎる。手作業に戻れる範囲から始めて、確認しながら少しずつ手放していく——この順番を守ることが、無理なく定着させるコツだ。

それでも、潮目は変わりつつある。上と現場のあいだの温度差を埋めるのは、大げさな導入計画ではない。「翌日の予定が DM で届いて、日々の転記が消えた」という、あなた自身の小さな実績だ。

コードを書けない人が、コードを書けるようになる話ではない。言葉で頼める同僚が、Slack の中に一人増えた——そういう話だ。今日の帰りぎわ、要約したいスレッドを開いて @Claude と打ってみる。そこから先は、あなたの週次業務が教えてくれる。

- Anthropic「Slack での Claude Code」(公式ドキュメント) - Yusuke Sakai「Slack から Claude Code に直接コード修正を依頼してみた」(Qiita) - nkjzm「n8nとClaude Code Actionで、Slackからのコード調査を依頼できるワークフローを実現する」(Cluster Tech Blog)