AI Tools 2026年6月11日

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

GitHub の Issue/PR 操作、Slack の長いスレッド要約、データベースへの日本語での問い合わせなど、開発・コミュニケーション系の MCP 活用例を紹介。複数 MCP を組み合わせたワークフローと権限設計の考え方も解説します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

長いスレッドの要約

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

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

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

検索と通知

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

データベース連携:「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 で学んだ「続けて型」をここでも使い、「私が確認したら実行」という関所を必ず置いてください。

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

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

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

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

ポイントは3つです。

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

なお、各サーバーでどのような権限の絞り方ができるかは提供元によって異なります。設定の細部は、必ず各サーバーの公式手順を確認してください。

やってみよう

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

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

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

まとめ

  • GitHub 連携は、開発の進捗を日本語で把握・整理できる。非エンジニアが「開発の今」を自分で確認できる価値が大きい
  • Slack 連携は、長いスレッドの要約や埋もれた議論の検索に効く。休暇明けのキャッチアップにも有効
  • データベース連携は、SQL を書けなくても日本語でデータを照会できる。ただし読み取り専用接続が必須
  • 複数の MCP を組み合わせると、ツールをまたぐワークフローを1回の指示で頼める
  • 外部に影響が出る操作(投稿・保存・更新)の前には、必ず人間の確認を挟む
  • 権限設計は「読み取り専用から始める → 必要な分だけ範囲を絞って広げる → 定期的に棚卸しする」の段階的アプローチで考える

理解度チェック

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

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

正解: 2

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

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

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

正解: 2

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