9-3 Claude Code MCP で GitHub・Slack・データベースをつなぐ

このレッスンでわかること

前のレッスン（9-2）では、Notion・Google Drive というドキュメント系ツールの連携を学びました。第9章の締めくくりとなるこのレッスンでは、GitHub・Slack・データベース という、開発とコミュニケーションの中心にあるツールの連携を扱います。

「GitHub やデータベースはエンジニアのものでは？」と思うかもしれません。しかし MCP でつなぐと、専門知識がなくても日本語の指示でこれらのツールから情報を引き出せるようになります。むしろ 非エンジニアにこそ価値が大きい 領域です。

このレッスンで身につけるのは、次の3つです。

• GitHub・Slack・データベース連携でできることと、非エンジニアにとっての価値
• 複数の MCP を組み合わせたワークフローの作り方
• 権限設計の考え方（読み取り専用から始める段階的アプローチ）

接続の基本手順（追加 → 認証 → 動作確認）は 9-2 と共通です。このレッスンでは「つないで何をするか」に焦点を当てます。

GitHub 連携：開発の状況を日本語で把握する

GitHub は、ソフトウェア開発のタスク（Issue）や変更内容（PR：プルリクエスト）が集まる場所です。MCP でつなぐと、Claude Code がこれらを直接読み書きできます。

エンジニアであれば、Issue の作成や PR の確認を対話で進められるのが直接の価値です。

GitHub のこのリポジトリに、「ログイン画面の文言修正」という Issue を
作成してください。本文には修正前後の文言を表で入れてください。

一方、非エンジニアにとっての価値は 「開発の今」を翻訳してもらえる ことです。たとえば企画担当やマネージャーなら、こんな指示ができます。

このリポジトリで今週クローズされた Issue を一覧して、
何が完了したのかを非エンジニア向けの言葉で3行にまとめてください。

これまで「エンジニアに聞かないと分からなかった」進捗が、自分で・いつでも・日本語で確認できるようになります。開発チームへの「あれどうなってますか？」という割り込みも減り、双方にとってメリットがあります。

GitHub のつなぎ方

GitHub は公式が リモート型とローカル型の両方 を提供しており、選択肢がある珍しいサービスです。9-1 で学んだとおり、準備が軽いのはリモート型です。ターミナルに入力します。

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

追加したあと、対話画面で /mcp を実行すればブラウザが開いて OAuth で認証できます。この経路ならトークンを自分で管理する必要はありません。

OAuth が使えない環境では、PAT（Personal Access Token：個人用アクセストークン） を発行して渡します。PAT は次のページで発行します。

• https://github.com/settings/personal-access-tokens/new

発行時に「どのリポジトリに」「何を許可するか」を選べるので、必要なリポジトリだけ・読み取りだけに絞って発行してください。発行したトークンは接続情報に添えて渡します。

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_TOKEN"

ローカル型（Docker で起動する方式）も提供されています。Docker を扱える環境なら、こちらは GITHUB_READ_ONLY=true を指定するだけで、サーバー自体を読み取り専用にできます（リモート型では --read-only フラグが同じ役割を果たします）。「うっかり書き換える」経路を仕組みとして塞げるのが利点です。

docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN=YOUR_TOKEN \
  -e GITHUB_READ_ONLY=true \
  ghcr.io/github/github-mcp-server

なお、トークンをこのようにコマンドへ直接書くとシェルの履歴に残ります。継続的に使うなら、9-1 で学んだ環境変数（${GITHUB_TOKEN} の参照）に置き換えてください。

Slack 連携：流れていく情報を捕まえる

Slack の情報は流れが速く、「長いスレッドを後から追うのがつらい」「重要な決定がどこかのスレッドに埋もれている」という悩みは誰にでもあります。Slack の MCP 連携は、まさにここに効きます。

長いスレッドの要約

非エンジニアにとって、もっとも即効性のある使い方です。

Slack の #プロジェクトA チャンネルにある昨日の長いスレッドを読んで、
「結論」「未決事項」「自分宛ての依頼」の3つに分けてまとめてください。

50件続いたスレッドでも、戻ってきた要約を1分読めば追いつけます。長期休暇明けの「Slack 浦島太郎」状態の解消にも絶大な効果があります。

検索と通知

「あの件、どこのチャンネルで話したっけ」という検索も得意です。また、サーバーの権限設定によっては、作業完了の報告をチャンネルに送る、といった通知の使い方もできます（書き込みを伴うため、後述する権限設計とセットで考えてください）。

Slack のつなぎ方と、最初にぶつかる壁

Slack は公式が リモート型のみ（接続先は mcp.slack.com/mcp）を提供しています。2026年2月17日に正式版となり、プラグインとして導入するのが案内されている経路です。ターミナルに入力します。

claude plugin install slack

導入するとブラウザが開き、OAuth 2.0 でワークスペースへのアクセスを許可する画面が表示されます。ここまでは Notion と同じ流れです。

ただし、Slack には他のサービスにない前提があります。ワークスペース管理者による事前承認が必要です。つまり、個人の判断だけでは繋げない場合があります。承認されていないワークスペースでは、許可画面まで進んでも接続が成立しません。

これは実務で最初にぶつかる壁なので、先に手を打ってください。

• 自分が管理者でないなら、手を動かす前に管理者へ確認する。「Slack の MCP サーバーを利用したい」と伝えます
• 依頼するときは、何を読むために使うのか（例：自分が参加しているチャンネルのスレッド要約）と、書き込みが必要かを明記する。目的が具体的なほど承認は通りやすくなります
• 承認待ちの間は、GitHub や Notion など自分の判断で繋げるサービスで練習を進める

「コマンドが間違っているのでは」と何時間も調べた末に、原因が組織の承認設定だった——というのは、よくある時間の溶かし方です。繋がらない原因が自分の手元にあるとは限らないことを覚えておいてください。

データベース連携：「SQLが書けない」を乗り越える

社内の売上や顧客のデータは、多くの場合データベースに入っています。通常、ここからデータを取り出すには SQL という専用の言語が必要で、非エンジニアは「エンジニアに依頼して数日待つ」のが定番でした。

データベースの MCP サーバーをつなぐと、この依頼が日本語で済むようになります。

売上データベースに接続して、先月の商品カテゴリ別の売上合計を
多い順に教えてください。データの変更は一切しないでください。

Claude Code が裏側で SQL を組み立てて実行し、結果を表で返してくれます。「ちょっと数字を見たいだけ」のために誰かの手を止める必要がなくなるのです。

ただし、データベースは会社の基幹データそのものです。この用途では特に、読み取り専用の接続を使うことが必須 と考えてください。詳しくはこの後の権限設計の節で説明します。

複数 MCP の組み合わせ：ワークフローを作る

MCP の真価は、複数をつないだときに発揮されます。ツールをまたぐ一連の仕事を、1回の指示で頼めるようになるからです。

例1：週次報告の自動化（GitHub × Slack）

次の手順で週次報告を作ってください。
1. GitHub で今週クローズされた Issue と PR を一覧する
2. 非エンジニア向けの言葉で進捗サマリーを作る
3. 内容を私に見せて、OKを出したら Slack の #週次報告 に投稿する

例2：データに基づく報告書（データベース × Notion）

1. 売上データベースから先月の店舗別売上を取得する（読み取りのみ）
2. 前月比の増減をまとめた報告ドラフトを作る
3. ドラフトを私が確認したら、Notion の「月次報告」に新規ページとして保存する

どちらの例にも共通する大事な型があります。「外部に影響が出る一歩手前で、人間の確認を挟む」 ことです。Slack への投稿や Notion への保存は、チームの目に触れる行為です。3-1 で学んだ「続けて型」をここでも使い、「私が確認したら実行」という関所を必ず置いてください。

権限設計の考え方：読み取り専用から始める

第9章の最後に、もっとも重要な話をします。MCP を安全に使い続けるための 権限設計 です。

考え方はシンプルで、段階的に信頼を広げる ことに尽きます。

段階	与える権限	できること	リスク
ステップ1	読み取りのみ	検索・要約・照会	低い
ステップ2	限定的な書き込み	下書き作成・特定チャンネルへの投稿	中
ステップ3	広い書き込み	ページ更新・Issue 操作など	高い

ポイントは3つです。

1. すべての連携を読み取り専用から始める。 検索と要約だけでも、MCP の価値の大半は得られます。書き込み権限は「読み取り運用に慣れて、必要性がはっきりしてから」で遅くありません。
2. 書き込みが必要になっても、範囲を絞る。 「Slack 全体に投稿できる」ではなく「#bot-test チャンネルだけに投稿できる」のように、影響範囲を限定します。データベースなら、管理者に依頼して読み取り専用の接続情報を発行してもらうのが理想です。
3. 定期的に棚卸しする。 使わなくなった MCP サーバーや権限は放置せず、claude mcp list で一覧して削除します。使っていない合鍵を回収するのと同じ、基本の安全管理です。

実際にどう絞るか（サービス別の手段）

「読み取り専用から始める」は、掛け声だけでは実現しません。サービスごとに どの手段で絞れるか が違います。

• GitHub：もっとも手段が揃っています。リモート型なら --read-only フラグ、ローカル型なら GITHUB_READ_ONLY=true で、サーバー自体を読み取り専用にできます。加えて PAT を発行する時点で、対象リポジトリと権限を絞れます。二重に絞れるので、迷ったらこの型を真似してください
• Slack：接続時の OAuth で許可したスコープの範囲に従います。許可画面で求められている内容を読み、書き込みが不要なら承認依頼の段階でその旨を伝えます
• Notion：連携（Integration）に共有したページだけが見える仕組みです。共有するページを限定することが、そのまま範囲の限定になります
• Google Drive：drive.readonly（読み取りのみ）と drive.file（そのアプリが扱ったファイルのみ）のスコープで絞れます
• データベース：管理者に依頼して、読み取り専用のユーザー・接続情報を発行してもらいます。アプリ側の設定ではなく、データベース側で書けなくしておくのがもっとも確実です

共通する考え方は、「気をつける」ではなく「できなくしておく」 です。人の注意力に頼る対策は、忙しい日に破れます。

なお、絞り方の細部は提供元の仕様変更で変わります。上記のフラグ名やスコープ名は、つなぐ前に各サーバーの公式ページで現行の値を確認してください。

4サービスのつなぎやすさ比較

第9章で扱った4つのサービスを、準備の重さで並べると次のようになります。どれから手をつけるか迷ったときの地図として使ってください。

サービス	型	認証	読み取り専用にできるか	事前に必要なもの	難易度
GitHub	リモート型／ローカル型の両方	OAuth または PAT	できる（--read-only / GITHUB_READ_ONLY=true）	URL のみ（OAuth の場合）	易しい
Notion	リモート型（推奨）	OAuth	共有するページを限定して絞る	URL のみ	易しい
Slack	リモート型のみ	OAuth 2.0	許可した OAuth スコープの範囲に従う	ワークスペース管理者の事前承認	ふつう
Google Drive	リモート型のみ（Developer Preview）	OAuth 2.0	できる（drive.readonly / drive.file）	自分で作る Google Cloud の OAuth Client	重い

易しい順は GitHub → Notion → Slack → Google Drive です。難易度を分けているのは機能の多さではなく、自分ひとりの判断で完結するかどうかです。GitHub と Notion は URL とブラウザ操作だけで閉じますが、Slack は他人（管理者）の承認が要り、Google Drive はクラウドの管理画面での構築作業が要ります。

最初の1本は GitHub か Notion を選び、「追加 → 認証 → 読み取りで動作確認」を通してください。型さえ体に入れば、残りは待ち時間と手続きの問題になります。

やってみよう

演習1：自分の仕事で「人に聞かないと分からない情報」を2つ挙げ、それが GitHub・Slack・データベースのどこにあるかを整理してみましょう。それが MCP 連携の最初の候補になります。

演習2：（Slack 連携を用意できる方向け）読み取り権限だけで Slack をつなぎ、最近の長いスレッドを1つ選んで「結論・未決事項・自分宛ての依頼の3つに分けて要約して」と頼んでみましょう。

演習3：例1・例2を参考に、自分の業務での「複数ツールをまたぐワークフロー」を1つ、手順の箇条書きとして書いてみましょう。その際、「私が確認したら実行」という関所をどこに置くかを必ず含めてください。

まとめ

• GitHub 連携は、開発の進捗を日本語で把握・整理できる。非エンジニアが「開発の今」を自分で確認できる価値が大きい
• Slack 連携は、長いスレッドの要約や埋もれた議論の検索に効く。休暇明けのキャッチアップにも有効
• データベース連携は、SQL を書けなくても日本語でデータを照会できる。ただし読み取り専用接続が必須
• 複数の MCP を組み合わせると、ツールをまたぐワークフローを1回の指示で頼める
• 外部に影響が出る操作（投稿・保存・更新）の前には、必ず人間の確認を挟む
• 権限設計は「読み取り専用から始める → 必要な分だけ範囲を絞って広げる → 定期的に棚卸しする」の段階的アプローチで考える
• 絞り方はサービスごとに手段が違う。GitHub は --read-only / GITHUB_READ_ONLY=true と PAT の発行範囲で二重に絞れる。「気をつける」ではなく「できなくしておく」を選ぶ
• Slack はリモート型のみで、接続にワークスペース管理者の事前承認が必要。個人の判断だけでは繋げないことがあるため、手を動かす前に確認する
• つなぎやすさは GitHub → Notion → Slack → Google Drive の順。分かれ目は機能ではなく、自分ひとりの判断で完結するかどうか

理解度チェック

Q1. 非エンジニアが GitHub の MCP 連携から得られる価値として、本レッスンの内容にもっとも合うものはどれでしょう？

1. プログラミング言語を自動的に習得できる
2. 開発の進捗（完了した Issue など）を日本語で自分で確認できる
3. エンジニアの仕事をすべて代行できる
4. GitHub の利用料金が無料になる

解答を見る

正解: 2

GitHub を MCP でつなぐと、Issue や PR の状況を Claude Code が読み取り、非エンジニア向けの言葉に「翻訳」して伝えてくれます。これまでエンジニアに聞かないと分からなかった開発の進捗を、自分で・日本語で確認できるのが大きな価値です。

Q2. MCP の権限設計として、もっとも適切な進め方はどれでしょう？

1. 最初からすべての権限を許可し、問題が起きたら絞る
2. 読み取り専用から始め、必要になったら範囲を絞って書き込み権限を広げる
3. 権限のことは考えず、動けばよしとする
4. 書き込み権限だけを先に与え、読み取りは後から許可する

解答を見る

正解: 2

権限設計の基本は「段階的に信頼を広げる」ことです。読み取り専用でも検索・要約・照会という MCP の価値の大半は得られます。書き込みが必要になったら、特定のチャンネルだけ・下書き作成だけ、のように影響範囲を絞って広げ、使わなくなった権限は定期的に棚卸しして削除しましょう。

Q3. Slack の MCP サーバーを個人で追加しようとしたところ、認証画面まで進んだのに接続できません。まず疑うべきこととして、もっとも適切なものはどれでしょう？

1. コマンドのタイプミス以外に原因はないので、何度も打ち直す
2. ワークスペース管理者による事前承認が済んでいない可能性がある
3. Slack はローカル型なので、Docker を先に入れる必要がある
4. Slack は MCP に対応していないので、接続はできない

解答を見る

正解: 2

Slack の MCP サーバーは OAuth 2.0 で認証しますが、ワークスペース管理者の事前承認が前提になっています。承認されていないワークスペースでは、許可画面まで進んでも接続が成立しません。原因が自分の手元ではなく組織側の設定にあるケースで、コマンドを打ち直しても解決しません。管理者に用途（何を読むために使うか、書き込みが必要か）を添えて依頼してください。なお Slack はリモート型のみの提供で、Docker は不要です（選択肢3）。