developersIO
Obsidian × Claude Code で相棒を作る — Slack 連携と安全設計

Obsidian × Claude Code で相棒を作る — Slack 連携と安全設計

Claude Code に Slack を繋ぐとき、AI に何をさせて何を禁じるかを設計した記録です。allow / ask / deny の3層に仕分ける判断基準と、CLAUDE.md では実行を止められず settings.json の permissions だけが強制力を持つという違いを、実際の設定とあわせて紹介します。
Claude CodeObsidianModel Context Protocol (MCP)生成AISlack
2026.08.24

はじめに

クラスメソッドオペレーションズの林です。

前回の記事では、Obsidian に Claude Code を繋いで Kanban を読み書きできるところまでを紹介しました。最後に「安全設計の話は次回で」と書いたので、今回はその続きになります。

ここからは外部サービスとの連携が出てきます。
繋いだ先で AI が何をしていいか、何をしてはいけないかを、あらかじめ設計しておく話です。

窮屈な話に聞こえるかもしれませんが、お仕事をお願いするときと同じで、境界がはっきりしているほうがお互いに動きやすいという気づきがありました。

Slack 連携を題材にしますが、考え方は他のサービスにもそのまま使えます。

Slack を繋ぐ理由

私が Slack を繋いだ目的はシンプルで、業務の状況を Obsidian の Kanban に反映するための情報源として使いたかったからです。

「あのチャンネルで誰かが言ってたな…タスクに入れておこう」とか、「先週のスレッドの結論を踏まえて考えたい」といった場面で、毎度 Slack を開いて検索して、コピーして貼って…という手間を減らしたいという思いがありました。

Claude Code には MCP（Model Context Protocol）で外部サービスを繋ぐ仕組みがあります。前回 Obsidian を繋いだのと同じ要領で、Slack の MCP コネクタを追加すると、チャンネルやスレッドの読み取りができるようになります。

ただ、先に一つ補足しておきますと、会社の Slack を AI ツールに繋ぐこと自体が、組織のルールに関わる話です。
私の場合は社内のルールに則った上で進めました。もし、お仕事で使用される場合は、同じことを試す前に、自社の規定をご確認ください。

Claude Code で /mcp を開き、claude.ai Slack のツール一覧を表示したところ。18 個のツールが並んでいる

繋いだ直後の「何でもできる」問題

注意したいのは、MCP を繋いだ直後は読み取りも書き込みも一通りできてしまう点です。

メッセージの検索やスレッドの読み取りはもちろん、メッセージの送信、予約投稿、canvas の作成、下書きの作成まで。書き込み系のツールもひととおり揃っていますから、「ちょっと情報を見たいだけ」のつもりで繋いだのに、思わぬ事故につながるリスクがあります。

正確に言うと、書き込み系がいきなり実行されるわけではなく… Claude Code の場合、実行前に「許可しますか？」と聞いてくる仕組みがあります。ただ、どこまで止まってくれるのか分からず、これだけでは安心できませんでした。

作業に集中しているときの承認ダイアログは、中身をよく読まずに押してしまったり、Enterキーに触れてしまった…マウスでクリックしてしまった…など、不可抗力による実行も考えられます。

読み取りのたびに聞かれていては、なおさら流れ作業になります。止まるかどうかが最後は自分の注意力次第、という状態です。

個人で試しているだけならまだしも、社内の Slack ワークスペースとなれば、話が違います。顧客名や案件情報、他のメンバーの個人情報も流れてきます。

使う前に「ルール」を決める必要がありました。

3層ガードレールという考え方

そこで、ツールの権限を3つの層に分けて設計しました。

層 意味 例
allow（常に許可） 確認なしで実行できる メッセージ検索、チャンネル読み取り
ask（毎回確認） 実行前に承認ダイアログが出る メッセージ送信、リアクション追加
deny（完全禁止） AI からはツールごと見えなくなる。実行不可 予約投稿、canvas 新規作成、下書き作成

分類の判断基準

どの層に入れるかは、3つの観点で決めました。

1. 取り消せるか
読み取りは何度やっても状態を変えないので、allow にしています。
メッセージ送信は送った後に削除できますが、相手にはもう通知が届いています。取り消せるとは言いにくいので、ask にしました。

2. 影響が広がるか
予約投稿は、実行されるのが時間差です。送った本人が気づかないまま投稿されてしまう。影響範囲が読めないので deny にしました。

3. 意図しない使われ方をしないか
canvas の新規作成は、ナレッジを Obsidian に集約する方針と矛盾します。
AI が良かれと思って Slack 側にも情報を書いてしまうと、どっちが正なのか分からなくなるということもあり、deny にしました。

settings.json で強制する

ここが今回いちばん伝えたいところです。

前回、CLAUDE.md にルールを書く話をしました。
「確認なしに既存カードを削除しない」のような運用ルールは、CLAUDE.md に書けば Claude Code は従ってくれます。

ただし、CLAUDE.md は技術的に実行を止める仕組みではありません。

CLAUDE.md はあくまで「お願い」です。指示として最優先で読んでくれますし、私の環境でこれを破られたことは今のところありません。
ただ、守られる保証がどこにもない。文脈の解釈次第で、禁止したはずの操作が通ってしまう可能性はゼロではありません。

実行を止められるのは、settings.json の permissions だけです。
公式ドキュメントより引用します。

"Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows." https://code.claude.com/docs/en/permissions

権限設定には評価順があり、deny はどの設定ファイルに書いてあっても最優先で評価されます。deny に入っているツールは、承認ダイアログすら出ません。

deny の実例

ユーザー設定（~/.claude/settings.json）に、こう書いています。Slack に関係するものを中心に抜粋しました。

なお、ここに出てくる mcp__claude_ai_Slack__ という名称は、claude.ai の Slack コネクタを繋いだ場合のものです。同じ Slack でも繋ぎ方が違えば、この名称も変わりますので、必ずご自身の環境で /mcp を実行し、確認してください。

{
  "permissions": {
    "deny": [
      "mcp__claude_ai_Slack__slack_schedule_message",
      "mcp__claude_ai_Slack__slack_create_canvas",
      "mcp__claude_ai_Slack__slack_send_message_draft",
      "Read(//**/.env*)",
      "Edit(//**/.env*)",
      "Write(//**/.env*)",
      "Read(//**/credentials*)",
      "Bash(rm *)"
    ]
  }
}

Slack の予約投稿・canvas 作成・下書き作成を deny にしています。
ついでに .env ファイルや認証情報ファイルの読み書きも deny にしているのは、Slack 以外の作業で、うっかり読まれたくないからです。

allow の実例

プロジェクト設定（.claude/settings.json）には、読み取り系を allow で列挙しています。こちらも一部を抜粋しています。

{
  "permissions": {
    "allow": [
      "mcp__claude_ai_Slack__slack_read_channel",
      "mcp__claude_ai_Slack__slack_read_thread",
      "mcp__claude_ai_Slack__slack_search_public",
      "mcp__claude_ai_Slack__slack_search_public_and_private",
      "mcp__claude_ai_Slack__slack_search_channels",
      "mcp__claude_ai_Slack__slack_search_users",
      "mcp__claude_ai_Slack__slack_list_channel_members",
      "mcp__claude_ai_Slack__slack_get_reactions"
    ]
  }
}

allow に入れたツールは承認ダイアログが出ないので、会話の流れでスムーズに情報を取ってきてくれます。
読み取りにいちいち「許可しますか？」と聞かれると、テンポが崩れてしまうので、私の場合は allow にしています。

確認の回数が減ると、本当に確認すべきときにちゃんと画面を読むようになります。先ほど触れた「流れ作業で押してしまう」問題は、聞かれる回数を減らすことでかなり軽くなります。

ask は書かなくても効く

メッセージ送信やリアクション追加は、deny にも allow にも書いていません。
Claude Code はデフォルトで MCP ツールの実行前に承認ダイアログを出すので、どちらにも書かなければ自動的に ask（毎回確認）になります。これは私の環境で確認した挙動です。

なお、ルールの評価順そのものは公式ドキュメントに明記されています。

"Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome" https://code.claude.com/docs/en/permissions

つまり、設計としてやることは2つだけです。

  • 絶対にやらせないものを deny に入れる
  • 確認なしで通していいものを allow に入れる

残りは何もしなくても毎回確認になります。

ちなみに、ask は承認ダイアログが出ますが、deny は何も出ません。

この記事に deny の「ブロックされました」という画面を載せようとして、撮れないことに気づきました。
deny に入れたツールは、AI に渡されるツール一覧から取り除かれます。つまり AI から見ると、そのツールは最初から存在しない。実行しようとして止められるのではなく、実行しようという発想自体が生まれません。だから画面に何も出ない。

ただし、これはツール名まるごとを deny にした場合の話です。Bash(rm *) や Read(//**/.env*) のように引数まで指定した deny は、ツール自体は一覧に残ります。Bash も Read も使えるままで、その条件に当てはまる呼び出しだけが実行時に止まります。

拒否の様子が撮れないのは、deny が弱いからではなく、強いからでした。

モード次第で、確認は素通りします

ここまでの話には前提があります。Claude Code をどのモードで使っているか、です。

Claude Code には、承認を 毎回聞かずに進めるモード があります。

ローカルで完結する作業なら便利ですが、社外サービスに繋いだ状態だと話が変わります。さらに Pro / Max / Team のプランでは、自分で緩めた覚えがなくても、設定を書いていなければ、このモードで起動します。

先ほどの「ask は書かなくても効く」が、ここで裏目に出ます。書かずに ask になっていたものは、このモードでは確認なしで通ります。逆に、明示的に ask として書いたツールは、どのモードでも自動承認されません。

絶対に確認を挟みたいものは、書かずに済ませず ask に明示しておく。
これが確実です。

そこで、ユーザー設定でモード自体を使えなくしています。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

なお、私は defaultMode を acceptEdits（ファイル編集の自動承認）にしています。Vault のファイルを何度も書き換える使い方なので、ここは緩和しています。

ただし acceptEdits の自動承認は、ローカルで完結する操作に限られます。MCP ツールの実行は対象外なので、Slack への送信は ask のまま、実行前に必ず確認が入ります。

ここは設定を見直すまで正確に理解していなかったのですが、acceptEdits が自動承認するのはファイル編集だけではありません。mkdir、touch、mv、cp、rm、rmdir、sed といったファイル操作コマンドも対象です（作業ディレクトリの配下に限られ、重要なパスを対象にした rm は止まります）。

rm まで確認なしで通るのは怖いので、先ほどの deny にも Bash(rm *) を記載して塞いでいます。

編集の自動承認なので、シェルスクリプトのようなファイルも書き換えられます。書き換えたものを実行するには Bash など別の権限が要るので普通はそこで止まりますが、フックのように Claude Code が自動で実行するファイルは例外です。気になる場合は Edit(//**/*.sh) を deny に足しておくと安全です。

deny 自体は、どのモードでも破られません。
破られるのは「書かずに ask になっていた」場合です。禁止リストを作ることと、確認を飛ばす道を塞ぐことはセットです。

CLAUDE.md との使い分け

では CLAUDE.md には何を書くのか。
私の場合、CLAUDE.md には「方針の表明」を書いています。

### Claude が Slack に対して**絶対にやらない**こと
- メッセージの予約投稿
- canvas の新規作成
- メッセージ下書きの作成

settings.json の deny と同じ内容ですが、これは冗長ではありません。

  • settings.json → 技術的に実行を止める（強制力）
  • CLAUDE.md → なぜ止めているかを AI に伝える（意図の共有）

deny だけだと「なぜか使えない」で終わりますが、CLAUDE.md にも書いておくと、AI が「この操作は方針として禁止されている」と理解した上で代替案を考えてくれます。

実際に予約投稿を頼んでみると、こう返ってきました。

Claude Code に Slack の予約投稿を依頼したところ、CLAUDE.md の運用ルールを根拠に断り、代わりに文面を用意して自分で予約する方法を提案している画面

理由を挙げたうえで、代わりの進め方まで出してくれています。

ただし、この場面は「CLAUDE.md だけが止めた」わけではありません。予約投稿は deny にも入れてあるので、AI から見ればツール自体が存在しない状態です。

それでも「できません」で終わらず、理由を説明して代わりの進め方まで出せているのは、CLAUDE.md になぜ禁止なのかを書いてあるからです。

deny は実行を止める。CLAUDE.md は理由を伝える。
役割が違うので、両方に書いておく意味があります。

同じ型を Backlog にも適用する

この3層の考え方は、他のサービスにも使い回せます。

社内のプロジェクト管理ツール Backlog を MCP で繋いだときも、まったく同じ型で設計しました。

  • allow（35件）… 課題・コメント・PR・Wiki の読み取りと検索
  • deny（3件）… 課題の削除、プロジェクトの削除、バージョンの削除
  • ask（20件）… 課題の追加・更新、コメント追加、PR 操作など

ask は書かなくても効きますが、どのツールがどの層かを棚卸しした記録として明示的に並べています。

「読み取りは自由、削除は完全禁止、書き込みは毎回確認」。
Slack のときとまったく同じ判断フレームです。

型が決まっていると、新しいサービスを繋ぐときに迷いません。
ツールの一覧を見て、3つに仕分けるだけです。

この型が使いやすいのは、業務利用ならではだと思っています。
仕事では「やっていいこと・ダメなこと」の線引きが組織のルールとしてはっきりしているので、3層への仕分けも自然にできます。個人利用だと扱う話題がバラバラで、禁止リストを設計する動機自体が薄くなりがちです。

とはいえ、個人で使う場合でも .env や認証情報の deny は効きます。
サービスを繋いでいなくても、AI にファイルを読ませる以上は同じ話なので、そこだけ先に入れておくのがおすすめです。

監査ログを残す

もうひとつ、接続時にやっておいて良かったのが 「監査ログ」 です。

Slack を繋いだとき、接続日・接続範囲・各ツールの権限設定を .claude/audit/ に記録しました。

.claude/audit/2026-05-20_slack-connector.md

中身は、いつ繋いだか、どのツールを allow / ask / deny にしたか、解除する条件は何か、といった事実の記録です。

大げさに聞こえるかもしれませんが、やることは Markdown ファイルにメモを残すだけです。
後から「なんでこのツールが deny なんだっけ？」となったときに、判断の経緯が残っていると助かります。

まとめ

今回やったことは3つです。

  1. Slack を繋いで「何でもできる」状態を確認した
    書き込みも、確認さえ押せば通ってしまう
  2. 3層ガードレール（allow / ask / deny）を設計した
    取り消せるか・影響が広がるか・意図しない使い方をしないか
  3. settings.json で deny を強制し、CLAUDE.md で意図を共有した
    片方だけでは足りないということ

前回は「人が決めること・AI に任せること」を分けるところで終わりました。
今回はその続きとして、「AI にさせないこと」を設計で決めるという話でした。

CLAUDE.md に「やるな」と書くだけでは、お願いにとどまります。
本当に止めたいものは settings.json の deny に入れる。
これで、ようやく「任せる」が成り立ちます。

設計する前は、Slack を繋いだまま作業するのが、少々怖い部分がありました。
いまは読み取りを全部任せていますし、承認を求められたときはちゃんと画面を読むようになりました。制限を決めたぶんだけ、任せられる範囲が広がったという実感があります。

相棒に鍵を全部渡す必要はなく、どの鍵を渡すかを決めておけば、渡した分は気持ちよく任せられます。

なお、今回書いた設定は「私の環境ではこうした」という一例です。
どこまで許可してどこから禁止にするかは、会社の方針や扱う情報によって変わります。実際に組む前に、自社の規定を確認してください。

次回は、バックアップと暗号化の話を書く予定です。こちらも保管場所や暗号化の扱いが社内規定に関わる領域なので、同じく確認したうえでの話になります。

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 採用サイト をぜひご覧ください。
※2026年1月 アノテーション株式会社から社名変更を行いました。

Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

この記事をシェアする

AI白書

関連記事

Obsidian × Claude Code で相棒を作る — MCP 接続から Kanban 運用まで
th7
2026.07.02
ベータ機能の「Claude Tag」を整理してみた
三山 祐輝 (みゃん)
2026.07.31
Coworkに「社内Slackで美味しかった店を探して」とお願いしたら、便利だけどちょっと怖かった話
たいさ
2026.03.04
Claude Code で Google カレンダーの予定を読み込み日報を作って Slack に投稿する
emi
2026.07.13