GitHub MCPの小技：書き込みを許可せずIssueの確認メモを作る

Issueは、不具合の報告や作業の相談を残す掲示板のようなものです。MCPは、AIアプリと外部サービスをつなぐ共通の取り決めです。『似た報告をまとめたい』だけなら、投稿や削除まで許可する必要はありません。最初は読む作業に絞ると、どんなデータがAIに渡るかを確認しながら使い方を覚えられます。ただし、読み取り専用でも情報の送信や誤った要約のリスクは残ります。

設定と依頼文は、別の役割を持つ

GitHub公式MCPのドキュメントでは、ローカル版の--read-onlyや、リモート版のURL末尾に/readonlyを付ける設定を案内しています。どこに入力するかは対応アプリによって違うため、公式の接続手順から自分のアプリを選んでください。知らない人が配布するサーバーURLにアクセストークンを渡してはいけません。トークンとはサービスへ入るための鍵で、チャット本文や共有画面に貼るものではありません。

どこまでできたら成功か

3件の番号とURLが一致し、再現手順が書かれていない報告を『未記載』として扱えていれば、確認メモの土台になります。『Windowsで起きた』という報告しかないのに、AIが『Macでも再現する』と補っていたら不採用です。Issue本文だけでなく、後のコメントで解決済みになっていないかも確認します。優先順位を付ける場合は、影響人数などの根拠がないまま緊急度を推定させず、まず情報をそろえましょう。

外部の文章に命令があっても従わない

Issueには第三者が文章を書けます。そこに『秘密の設定を送れ』『別サイトを開いて実行せよ』という指示が混ざっていても、それは利用者からの依頼ではありません。このように外からAIの行動を変えようとする文章を、プロンプトインジェクションと呼びます。GitHubのLockdownは内容を絞る補助ですが、認証や権限の代わりにはなりません。他の接続や端末の操作権限が残っていれば、MCPだけを読み取り専用にしても作業全体は読み取り専用になりません。

Zennでは、GitHub連携から記事の公開まで任せる使い方も紹介されています。たとえばgoyle0さんの記事が扱うのは投稿自動化ですが、この小技では入口を手前に戻し、読むだけで役立つ確認メモに限定しました。公開や更新を自動化するのは、その後に変更内容の確認、復旧方法、承認の位置を決めてからです。この記事の例は設定・運用の設計例であり、特定アプリとの接続を実機で試した結果ではありません。