この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。
PRのレビュー依頼が来るたび、Slackで通知を受け取ってGitHubを開き、差分を確認してコメントを書く——その往復に時間を取られていないか。Claude CodeとSlackを連携させれば、レビューの依頼から結果の確認、修正指示のやり取りまでをSlack上で進められる。どこまで頼むだけで済み、どこで人が判断すべきか。Windows 11環境で試した結果をまとめる。
この記事で確かめること
Claude CodeとSlackを連携させ、PRレビューの依頼・実行・結果確認・追加確認の流れをどこまでSlack上で進められるかを検証する。
検証の前提は次のとおり。Windows 11環境で、ターミナルからClaude Codeを利用する。Slack上では公式のClaude Slack App（@Claudeメンション経由）を主軸に進める。レビュー対象は架空のPRで、diff行数は数十行程度の中規模を想定する。
前提：Slack連携の3つのルート
Claude CodeとSlackをつなぐ方法は大きく3つに分かれる。
- Webhook通知：GitHubなどのイベントをSlackに一方向で送る仕組み。「PRが作成されました」という通知は届くが、レビューの依頼や結果のやり取りはできない。導入は一番簡単だが、できることは通知の受け取りだけだ
- MCPサーバー経由：SlackのMCPサーバーを使い、Claude CodeからSlack APIを操作する手法。双方向のやり取りは可能だが、サーバーの設定やトークンの管理が複雑で、初心者にはハードルが高い
- 公式Claude Slack App：Slack上で
@Claudeにメンションするかスラッシュコマンドを使い、直接対話する公式ルート。設定手順が公式に用意されており、レビュー依頼から結果の受け取りまでSlack上で完結する
今回の検証では、公式Claude Slack Appを主軸に進める。レビュー依頼から進捗確認、結果の受け取りまではSlack上で進めやすく、Windows環境でもブラウザ経由で設定できるためだ。
| ルート | できること | できないこと | 設定の難易度 |
|---|---|---|---|
| Webhook通知 | イベントの片方向通知 | レビュー依頼・結果のやり取り | 低 |
| MCPサーバー | 双方向のメッセージ送受信 | 初心者には設定が複雑 | 高 |
| 公式Slack App | レビュー依頼・結果確認・修正指示 | セキュリティ判断は人 | 中 |
Step 1：最初の依頼——Slackからレビューを頼む
Slackのチャンネルで@Claudeにメンションしてレビューを依頼する。実際に送った依頼文は次のとおり。
@Claude このPRをレビューしてください。
https://github.com/example-org/sample-app/pull/42
レビュー観点：
- エラーハンドリングが適切か
- 変数名の意図が読み取れるか
- テストケースの過不足
PRの差分URLを依頼文に含めたのは、差分全体を読み込ませるためだ。GitHub連携と対象リポジトリの認証が済んでいれば、PRのURLを依頼文に含めることで@Claudeが対象を判断しやすくなる。レビュー観点を3つ書き添えたのは、「何について見てほしいか」を明示した方が指摘の的確さが増すためだ。
Windows環境特有の操作はない。ブラウザでSlackを開き、チャンネルに投稿するだけ。
Step 2：最初の結果——レビューはどう返ってきたか
今回の小さな例では、しばらくして@Claudeからスレッド内に返信が届いた。初回出力の一部を引用する。
PR #42 のレビュー結果です。
1. processOrder() 内の try-catch ブロックで、
catch 節が汎用的な Error のみを捕捉しています。
ネットワークエラーとバリデーションエラーを
分けて処理すると、エラーの原因が追跡しやすくなります。
2. 変数名 'd' がループ内で使われていますが、
'discount' の方が意図が伝わりやすいです。
3. テストケースは正常系が3件ありますが、
エラー発生時のテストが1件のみです。
ネットワークタイムアウトや無効な入力の
テストを追加するとカバレッジが上がります。
良かった点：変数名の指摘は的確で、具体的な改善案（d → discount）が提示されていた。テストケースの過不足についても、足りない観点が具体的に示された。
足りなかった点：依頼文に「エラーハンドリング」と書いたのに、セキュリティに関わる入力値のサニタイズには触れていなかった。またprocessOrder()のビジネスロジック自体の妥当性（割引の計算順序など）には言及がなく、コードの表面的な読み取りにとどまった。
人が確認したポイントは、指摘の正確性そのものだ。変数名の改善案は妥当だったが、エラーハンドリングの提案が「今回のPRの範囲で適切か」はコードの文脈を知らないと判断できない。
Step 3：修正指示——Slack上でどう伝えたか
初回のレビューに対し、同じスレッドで修正指示を出した。依頼文は次のとおり。
レビューありがとうございます。追加で確認をお願いします。
1. セキュリティ観点：processOrder() の引数に対する
入力値のチェック、いわゆるサニタイズが漏れていませんか？
2. ビジネスロジック：割引の計算順序が仕様通りか
確認してください。仕様では「税計算前に割引を適用」です。
修正指示の狙いは2点。1点目はセキュリティ観点の追加で、初回レビューで触れられなかった入力値の検証を明示的に求めた。2点目はビジネスロジックの確認で、割引の計算順序というプロジェクト固有のルールを提示した。
指示はスレッド返信で出した。文脈が引き継がれるため、新しいメンションを立てるより前後の流れが分かりやすい。
Step 4：修正後の結果——何が変わったか
修正指示への返信は、セキュリティ観点について次のように変わった。
セキュリティ観点を追加確認しました。
processOrder() の引数 orderId と quantity について：
- orderId: 数値以外の入力に対するガードがありません。
parseInt() の結果を isNaN() で検証すると安全です。
- quantity: 負の数のチェックが漏れています。
quantity > 0 の前提条件を明示的にチェックする
必要があります。
改善された点：引数ごとの具体的な検証方法が提示され、サニタイズの抜けが指摘できた。parseInt()とisNaN()の組み合わせなど、実装に直結する提案が出た。
まだ足りなかった点：ビジネスロジック（割引の計算順序）については、「仕様通りか」の判断ではなく「計算式を確認しました」という読み取りにとどまった。プロジェクト固有の仕様と実装の整合性を判定するには、仕様書を@Claudeに共有するか、依頼文により詳細な前提を書く必要がある。
つまり、コードの表面的な不具合は@Claudeだけで拾えるが、ビジネス要件との照合には前提情報をこちらから提供する必要がある。
Step 5：どこまで頼むだけでできたか
検証結果を3段階で整理する。
比較的任せやすい：レビュー依頼の出し方（PRのURLと観点を書いてメンションするだけ）、変数名やコードスタイルの指摘、テストケースの過不足の指摘。依頼文に観点を書けば的確に拾ってくれる。
条件付きで使える：エラーハンドリングの指摘、セキュリティ観点のレビュー。依頼文で観点を明示すれば拾えるが、明示しないと見落とす。コンテキストの深さに依存する。
必ず人が確認すべき：セキュリティの最終判断（サニタイズの提案を採用するか）、ビジネスロジックの妥当性（仕様との整合性）、権限の承認（PRをマージしてよいか）。@Claudeは指摘を出すが、採用するかどうかは人が判断する。
やり取りの回数は、初回依頼→初回結果→修正指示→修正後結果の計4回。冒頭で「レビューの依頼から修正指示のやり取りまで」と約束した範囲は、すべてSlack上で完結した。
DispatchとChannelsで自動化する
ここまでは手動で@Claudeにメンションしてレビューを依頼した。PR作成時の自動レビューまで進めたい場合は、Slack App単体ではなく、Claude CodeのCode Review、GitHub Actions、またはRoutinesのGitHubイベントトリガーを検討する方が自然だ。
Channelsは、外部イベントやチャットからの入力を、起動中のClaude Codeセッションに届けるための研究プレビュー機能だ。Slackへのレビュー結果通知を簡単に設定する機能ではないため、この記事では詳しい手順には踏み込まない。
なお、PR作成時の自動レビューまで行いたい場合は、Slack Appの設定だけで完結するとは限らない。Claude CodeのCode Review、GitHub Actions、Routinesなど、目的に合った自動化ルートを別途選ぶ必要がある。自動化の範囲を広げたいならClaude Codeにプラグインを入れて機能を増やすことで、さらに高度なワークフローも組めるようになる。
Windows環境での注意点として、ブラウザでSlack Appの管理画面を開く際、Chromium系ブラウザ（ChromeやEdge）を使うと設定画面の表示が安定する。管理画面はSlackのワークスペース設定内にあるApp管理から辿れる。なお、ターミナル画面の見方を把握しておくと、Claude Code側での動作確認もしやすくなる。
この検証の振り返り
依頼文の書き方のコツ：PRの差分URLを含めること、レビュー観点を3〜5個程度書き添えること。観点を書かないと表面的な指摘に留まる。セキュリティ観点を求めるなら「セキュリティ観点で確認して」と明示する。
向いている人：Slackを開発フローのハブにしているチーム。PRのレビュー依頼や結果の確認をSlack上で一元管理したい場合に向く。レビュー業務が多く、定型的な指摘の負担を減らしたい人にも合う。自動化を進めるなら、権限モードの設定も事前に確認しておくとスムーズだ。
向かない人：セキュリティ要件が厳しいプロジェクトでは、レビュー結果の最終判断をすべて人が行う必要があり、かえって手間が増える可能性がある。数百行を超える大規模PRを頻繁に出す場合、コンテキストが深すぎて@Claudeの指摘が的外れになることがある。
検証データの特性：今回は架空の数十行規模のPRで検証した。大規模なPRや複数ファイルにまたがる変更では、結果が異なる可能性がある。
やり取りは4回で、レビューの依頼から修正指示までSlack上で完結した。ただしセキュリティの判断とビジネスロジックの妥当性は人が確認している。
次に試すなら
まずは自分のリポジトリで小さなPR（10〜30行程度）を使い、@Claudeにレビューを依頼してみる。差分URLとレビュー観点を書いた依頼文を送るだけで、初回のレビュー結果が返ってくる。
依頼文のコツを掴んだら、DispatchとChannelsの自動化設定に進む。PR作成時に自動でレビューが走り、結果がチャンネルに通知される仕組みが動くと、レビューの抜け漏れが減る。
環境やバージョンによっては、さらに進められる可能性がある。公式Appの機能拡張や、MCPサーバー経由での双方向連携も今後の選択肢に入る。
まとめ
SlackからClaude Codeにレビューを依頼し、結果を受け取り、修正指示を出すまでは頼むだけで進められた。セキュリティ判断とビジネスロジックの妥当性は人が確認する必要があるが、定型的な指摘の負担は減る。まずは小さなPRで試して、どこまで任せられるか手応えを掴むのがいい。
今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。