Cowork議事録配布を承認ゲート付きで複数チャネルへ回す手順

議事録の作成(要約・タスク化)はClaude議事録の実践プロンプトで扱っています。そちらはSlack単一チャネルへの自動送信までが範囲です。この記事は、作成済みの議事録をSlack・Gmail・Chatworkへ、内容確認の承認ステップを挟んで配布する「配布フェーズ」を扱います。

先に結論を書きます。確認ゲートを決めるのは承認モードだけではなく、コネクタのツールごとの権限(Always allow / Needs approval / Blocked)との組み合わせです。Slack・Gmailはコネクタ一覧から接続でき、Chatworkだけは自前でホスティングするカスタムコネクタが要ります。

配布を始める前に確認しておくこと

Coworkは有料プラン(Pro・Max・Team・Enterprise)で使えます。議事録の配布はCoworkのタスクとして動くので、まずここが前提になります。

そのうえで、指示を出す前に次の3点を済ませておきます。

• 配布先のSlackワークスペースとGmailアカウントをコネクタとして接続する
• 個人設定で承認モードを選べる状態か確かめる
• Chatworkまで含めるなら、カスタムコネクタを用意する(後述)

Team・Enterpriseでは、組織設定が個人設定より優先される場面があります。個人の画面だけ見て「動くはず」と判断すると、同僚の環境では挙動が違うことがあります。

確認ゲートを決めるのはモードとツール権限の掛け合わせ

Coworkには、Claudeが操作の前に人へ確認するかどうかを決める承認モードが3つあります。手動承認(Manually approve)・自動承認(Automatically approve)・承認スキップ(Skip all approvals)です。新しい画面では、メッセージ欄の権限設定にAutoとManual(既定)の2つだけが表示されることがあります。

見落としやすいのは、コネクタの各ツールに別の権限が付いている点です。権限はAlways allow・Needs approval・Blockedの3段階で、モードとの掛け合わせで実際の挙動が決まります。

この表から2つのことが読み取れます。

1つ目は、手動承認でも、権限がAlways allowのツールは確認なしで動くことです。Slackへの投稿ツールを一度「常に許可」にすると、モードを手動承認にしたままでも議事録は黙って投稿されます。配布前に必ず止めたいなら、投稿・メール作成のツールをNeeds approvalにしておきます。

2つ目は、自動承認では書き込み系を止めるかどうかをClaudeが判断することです。ここで人の確認が入る保証はありません。承認スキップでは、この判断すら働かず、指示した内容がそのまま実行されます。

Blockedは全モードで拒否です。議事録の配布先に使わせたくないチャネルや宛先のツールがあるなら、モードに頼らずツール側で止められます。

Cowork自身の安全ガイドも、送信のように取り消しにくい操作や、機密性の高いアカウントに触れるタスクでは手動承認に切り替えるよう挙げています。Slackへの投稿は、まさにこの「メッセージ送信」にあたります。

Slack・Gmailはコネクタ一覧から接続して配布できる

SlackとGmailは、コネクタ一覧から接続できます。議事録ファイルを要約し、要点とネクストアクションを両チャネルへ回す指示文は次の形にまとめられます。

Meeting notes/2026-09-12.docxの議事録を要約し、要点3つとネクストアクションを箇条書きにしてください。
要約をSlackの#project-updatesチャンネルへ投稿する下書きと、件名「会議メモ 9/12」でのGmail下書きを両方用意してください。
実際の投稿・送信は、私が内容を確認してから許可します。

最終行の「確認してから許可します」はClaudeへのお願いにすぎません。実際に止めるのは前節のツール権限です。指示文だけでは確認ゲートは成立しない、と覚えておくと取り違えません。

流れは次の4段階になります。

議事録ファイルがパソコン上のフォルダにある場合、もう1つ条件があります。Coworkのタスクはクラウド上で動き(Enterpriseではクラウド実行は既定でオフで、Ownerが有効にします)、手元のファイルにはClaude Desktopアプリ経由で触れます。アプリを閉じてもパソコンがスリープしても、セッション自体は動き続けます。ただしローカルファイルやブラウザを使うタスクは、アプリを開いたままにしておく必要があります。夜間や外出中に配布を回すときは、この点に注意します。Pro・Maxでは2026年10月6日から、新しいタスクがクラウドで動き、設定 > 一般 の「Only on your computer」は無くなります(開始済みのタスクは手元に残ります)。

Slack連携の基本設定はCoworkのSlack連携ワークフローにまとめています。要点の数を3つ程度に絞る指定を添えると、確認する側の負担も減ります。

Chatworkはカスタムコネクタとして自前で接続する

Slack・Gmailはコネクタ一覧から接続できます。Chatworkはコネクタ一覧に載っていないため、Cowork単体では接続ボタン1つとはいきません。

一方で、Chatwork自身がMCPサーバーを配布しています。@chatwork/mcp-server はChatwork API v2の操作を31個のツールとして公開しています。メッセージ投稿の post_room_message とタスク作成の create_room_task に加え、メッセージの一覧・更新・削除やメンバー管理も備えます。議事録の要点をルームに投稿し、ネクストアクションをタスクとして切る用途には機能面で足ります。

問題は接続の経路です。サーバーの既定は、パソコン上で起動するstdioという方式です。READMEの設定例も、Claude Desktopの claude_desktop_config.json やClaude Codeの claude mcp add を使っています。ところがCoworkは、この設定ファイル経由のローカルMCPサーバーを使えません。

Coworkのカスタムコネクタは、Anthropicのクラウドから、インターネット越しにMCPサーバーへ接続する仕組みだからです。Cowork・Claude Desktop・claude.aiのどれから使っても同じで、サーバーはAnthropicのIPアドレスから到達できる場所に置きます。社内ネットワークの中にあるなら、ファイアウォールでAnthropicのIP範囲を許可する必要があります。

幸い、@chatwork/mcp-server にはHTTPで待ち受けるモードがあります。npmパッケージをそのまま登録する経路こそありませんが、ホスティングさえすればCoworkから使えます。

HTTPモードで起動しただけでは、外から届きません。READMEによると、既定の待ち受けは 127.0.0.1 のループバックだけです。Host ヘッダの許可リスト(--allowed-hosts)も、localhost,127.0.0.1,[::1] が既定です。外から届くようにするには、待ち受けアドレス(--host)を外向きのインターフェースにし、--allowed-hosts に公開するホスト名を加えます。許可リストが照合するのはホスト名だけで、ポート番号を書いても無視される仕様です。

登録の手順は次のとおりです。

注意点が2つあります。Team・Enterpriseでは、同じコネクタを使う全員が同じ資格情報でChatworkに届きます。投稿できるルームを絞ったトークンを使うと、誤配布の範囲を限れます。

もう1つは承認です。Team・Enterpriseの組織設定「Allow "Always allow" for connector tools」は既定でオフです。オフの間は、書き込み系ツールの「Allow for all tasks」がグレーアウトします。読み取り専用として扱われるのは、コネクタ側が読み取り専用と注釈を付けたツールだけです。カスタムコネクタの多くはツールに注釈を付けないため、Chatworkへの投稿やタスク作成は、すべてタスクごとに承認を求められることになります。配布前の確認ゲートとしては、むしろ都合のよい挙動です。

リモートMCPサーバーを自作する手順はCoworkカスタムコネクタ自作ガイドにあります。Claude Codeからローカルで使うだけなら、stdioのままで足ります。登録はClaude Codeの claude mcp add でできます。

複数部署で使うときは組織設定が個人設定に勝つ

議事録配布を組織全体の運用に広げると、個人のモード選択だけでは決まりません。Team・Enterpriseでは、管理者がOrganization settingsのCoworkで、2つの許可を切り替えられます。

• 「Automatically approve」モードを、メンバーが選べるかどうか(既定はオン。オフにすると、モードの選択肢から消える)
• 書き込み系コネクタツールで、承認を省く「Always allow」を認めるかどうか(既定はオフ)

2つ目がオフの組織では、Slack投稿やGmail作成のツールを個人側で「常に許可」にしていても、保存済みの設定は効かず、メンバーはタスクごとに承認します。組織設定なので、部署ごとには分けられません。他社や他部署のメンバーが同じタスクを動かしたとき、確認が出る・出ないで食い違う原因はここにあります。展開前に、この2つの設定値を管理者に聞いておくと防げます。

部門ごとの設計判断はCowork Approval Gatesの設計に詳しくあります。

よくあるつまずき

• Manualにしたのに黙って投稿された: 原因はAlways allowのツールです。Needs approvalに戻せば止まります
• 承認待ちのまま止まっていることに気づかない: 複数チャネルへの配布では、ツールごとに許可を求められます。Slackだけ許可して、Gmailが承認待ちのまま残る、という形になりがちです。最後に各チャネルへ届いたかを見ます
• 自動承認なら安全だと思い込む: 自動承認で止まるかどうかはClaudeの判断です。メッセージ送信のように取り消しにくい操作は、手動承認に切り替える選択肢があります
• 配布先ごとの粒度指定を忘れる: 「要約を配布してください」とだけ書くと、Slackとメールに同じ分量の文章が届きます。粒度は配布先ごとに書き分けます

議事録の内容によって配布範囲を絞る

すべての議事録を同じ構成で配布する必要はありません。人事評価や契約金額に触れる議事録と、進捗共有だけの議事録では、届けてよい相手が違います。指示文で「このチャネルには要点のみ、このチャネルには全文」と粒度を変えておくと、配布そのものが情報の絞り込みも兼ねます。

絞り込みを指示文だけに頼らない方法もあります。全文を出したくないチャネルのツールをBlockedにしておけば、モードを問わず投稿が拒否されます。

Coworkのタスクは、Anthropicのクラウド上の分離された一時環境で動き、セッションが終わると環境ごと破棄されます。ただしこの分離は、Claudeが実行するコードからパソコンとネットワークを守るためのものです。付与した権限を通じて読み書きできる範囲は変わりません。投稿・送信した内容は、宛先にそのまま残ります。配布範囲の判断は、実行環境の分離とは別に、宛先ごとに人が決めます。

また、Claudeが誤った宛先や内容で配布しても、その責任は利用者にあります。Cowork自身の安全ガイドは、公開したコンテンツや送信したメッセージについて、利用者がClaudeの行動に責任を負うと明記しています。

まとめ

展開前に先に確かめるのは、組織設定の「Always allow」の可否です。ここがオフなら個人の「常に許可」は効かず、確認ゲートは組織側で既に固まっています。Chatworkを加えるときは、MCPサーバーをHTTPモードで公開できるかどうかが最初の関門です。作成から配布まで通しで整えるときは、議事録作成のプロンプトと組み合わせます。