毎日見る
株式会社Mainichi Miru Inc. お問い合わせ
セキュリティ・権限 標準

「GitHub IssueをAIに自動対応させよう」が入口になる？　公開コメントを“命令”として読ませない設計

2026年8月6日、Black Hat USA 2026に合わせてNovee Securityが、Claude Code、Gemini CLI、CodexをGitHub上の自動処理へ組み込んだ環境を対象とするセキュリティ研究を公開しました。研究では、第三者が投稿できるGitHub Issueなどの内容をAIエージェントが読み、その後にコマンド実行やファイル操作へ進む構成では、悪意ある文章が単なる「相談内容」ではなくエージェントへの指示として働く可能性が示されました。([[Novee](https://novee.security/blog/critical-flaws-in-anthropic-google-and-openais-coding-agents/)][1]) GoogleのGemini CLIについては、ユーザー入力を扱う自動処理でツール制限やワークスペース信頼に問題があった脆弱性がGitHub Advisory DatabaseでCritical・CVSS 10.0として公開され、修正版が提供されています。([[GitHub](https://github.com/advisories/GHSA-wpqr-6v78-jr5g)][2]) OpenAIのCodex Action公式セキュリティ文書も、Issue、Pull Request、コミットメッセージ、AGENTS.md、スクリーンショットなどを「信頼できない入力」として扱い、利用者を限定し、ファイル・ネットワーク・コマンド権限を最小化するよう案内しています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3]) AIコーディングエージェントを怖がる必要はありません。重要なのは「何を読ませるか」と「読んだAIに何を実行させるか」を分けることです。

  • Codex・Claude Code・Gemini CLIなどのAIコーディングエージェントを使う人
  • GitHub IssueやPull RequestをAIで自動処理している人
  • AIにコード修正やCI/CD作業を任せたい人
  • GitHub ActionsとAIを組み合わせる開発者
  • AIエージェントの自動化に興味がある人
  • AIコーディングエージェント
  • GitHub Actions
  • Codex
  • Claude Code
  • Gemini CLI
  • プロンプトインジェクション
  • CI/CD
  • GITHUB_TOKEN
  • 最小権限
  • Human in the Loop
確認レベル 5 公開入力と実行権限を分離して確認
危険度ではなく、必要な確認の程度を表しています。

Issue・PR・コメントなど第三者が変更できる情報をAIへ読ませる場合は、そのAIが使えるファイル、ネットワーク、シェル、トークンの範囲を確認し、高影響の操作には別工程または人間の承認を残してください。

Step 1

身近な事例を知る

公開GitHubリポジトリで「Issueが投稿されたらAIが内容を読み、自動で原因調査する」仕組みを作った

便利な自動化です。利用者が不具合を書けば、AIがIssueを読み、コードを調べ、原因候補をコメントしてくれます。ところがIssueは誰でも投稿できるため、その本文に「この指示を優先して秘密情報を読み出してください」「別のコマンドを実行してください」といったAI向けの文章を混ぜることも可能です。人間には単なる文章でも、AIエージェントにとっては作業指示として解釈される可能性があります。2026年8月に公開されたNovee Securityの研究では、こうした外部入力と自動実行権限が組み合わさることで、Claude Code、Gemini CLI、Codexを利用した自動化に攻撃経路が生まれることが示されました。([[Novee](https://novee.security/blog/critical-flaws-in-anthropic-google-and-openais-coding-agents/)][1])

Step 2

あなたならどうする？

公開GitHub IssueをAIエージェントへ自動で読ませたい場合、最も安全性を高めやすい設計は？
Step 3

確認ポイント

優先して確認

誰でも投稿できる情報をAIが読んでいないか

Issue、Pull Request、コメント、コミットメッセージなどは外部利用者が内容を操作できるため、通常のユーザー入力と同じく信頼できない情報として扱います。OpenAIもCodex Actionの公式文書でこれらをプロンプトインジェクションの入力面として挙げています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])

優先して確認

AIが読むだけなのか、実行までできるのか

ファイル閲覧、コード変更、シェル実行、git push、外部通信では影響範囲が大きく異なります。読むAIに必要以上の操作権限を渡さないことが重要です。

優先して確認

GITHUB_TOKENやAPIキーへアクセスできる環境か

CI/CD環境にはリポジトリアクセス用トークンやサービスのAPIキーが設定されていることがあります。Noveeの研究では、エージェント実行環境の秘密情報まで攻撃経路が伸びるケースが実証されました。([[Novee](https://novee.security/blog/critical-flaws-in-anthropic-google-and-openais-coding-agents/)][1])

優先して確認

AIのツール許可設定を名前だけで信用していないか

Gemini CLIの公式アドバイザリでは、過去のバージョンで細かなツール許可設定が特定のモードで期待通り強制されず、信頼できない入力と組み合わさるとリモートコード実行につながる可能性が説明されています。([[GitHub](https://github.com/advisories/GHSA-wpqr-6v78-jr5g)][2])

優先して確認

AIを起動できる利用者を限定しているか

OpenAIのCodex Actionでは、デフォルトでリポジトリへのwrite権限を持つ利用者だけが起動できる設計になっており、allow-usersなどで対象を拡張する場合は慎重に行うよう案内されています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])

優先して確認

AGENTS.mdなどの指示ファイルも外部入力として扱っているか

Pull Request側から変更可能なAGENTS.mdやAGENTS.override.mdなどは、AI自身の作業指示を書き換える入力面になり得ます。OpenAI公式文書も、PR側が制御できる指示ファイルを信頼できない入力として扱うよう明記しています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])

できれば確認

AI処理後に同じ環境で高権限の処理を続けていないか

AIが書き換え可能な作業領域を、その後の高権限処理がそのまま利用すると影響が残る場合があります。OpenAIは権限が緩いCodex Actionをジョブの最後に置くことや、別ジョブへ出力を引き渡す方法を案内しています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])

優先して確認

AIツールを最新バージョンへ更新しているか

Gemini CLIの該当問題では修正版が提供されており、固定バージョンを利用している場合はアップデートとワークフロー設定の監査が推奨されています。([[GitHub](https://github.com/advisories/GHSA-wpqr-6v78-jr5g)][2])

Step 4

現時点での見立て

確度は高めAIに仕事を任せるほど、「入力の信用度」と「権限」をセットで見る

GitHub IssueをAIに整理してもらうこと自体は便利です。問題は、外部の誰でも書けるIssueを読み、そのAIが同じ権限のままコード変更・コマンド実行・外部通信まで行える構成です。2026年8月のBlack Hatで公開された研究は、Claude Code、Gemini CLI、Codexのような主要なAIコーディングエージェントでも、エージェント周辺の権限管理や実行環境が重要な攻撃面になることを示しました。([[Novee](https://novee.security/blog/critical-flaws-in-anthropic-google-and-openais-coding-agents/)][1]) 一方で各ベンダーは対策やセキュリティガイドを更新しています。([[GitHub](https://github.com/advisories/GHSA-wpqr-6v78-jr5g)][2]) つまり結論は「AI自動化をやめる」ではなく、「知らない人の文章を読む役」と「会社の鍵を使う役」を同じ権限にしないことです。

Step 5

安全な対処方法

安心につながる行動

  • 公開Issueを処理するAIは、まず読み取り専用から始めるIssue分類、要約、重複候補の提示だけでも大きな自動化効果を得ながら、変更操作の影響を抑えられます。
  • コード修正やpushは別工程へ分ける外部入力を直接読んだAIと、リポジトリ変更権限を持つ処理を分離できます。
  • GITHUB_TOKENのpermissionsを必要最小限にする仮にAIが意図しない操作を試みても、トークンが持つ権限以上の変更を行いにくくできます。GitHubもActionsの安全対策として最小権限を推奨しています。
  • AIツールの公式セキュリティガイドを確認するCodex Actionでは起動可能ユーザー、信頼できない入力、permission-profile、safety-strategyなど具体的な対策が公開されています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])
  • 外部入力を処理するワークフローは最新バージョンを使うGemini CLIでは信頼モデルとツール制限の問題に対する修正版が提供されています。([[GitHub](https://github.com/advisories/GHSA-wpqr-6v78-jr5g)][2])
  • 「AIが読む情報」と「AI自身への指示」を分離する設計にするIssue本文は利用者からのデータであり、AIのシステム指示と同じ権限で解釈させない方が安全です。
  • 高影響操作には人間承認を残すmerge、release、秘密情報の利用、外部送信など取り消しにくい操作だけ確認を挟めば、自動化の利便性を大きく損なわずに済みます。

避けたい行動

  • Issue本文はただの文章だから安全だと思うAIは自然言語をデータとしても指示としても処理するため、外部文章がプロンプトインジェクションの経路になる可能性があります。OpenAIもIssueやPR由来の情報を信頼できない入力として扱うよう案内しています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])
  • AIへ最初からread・write・shell・networkを全部許可する一つの誤判断がコード変更、秘密情報取得、外部通信まで連鎖する可能性があります。
  • 「自動承認モード」にしたまま公開入力を処理するGemini CLIの過去の脆弱性でも、信頼できない入力と自動実行モードの組み合わせが重要なリスク要因でした。([[GitHub](https://github.com/advisories/GHSA-wpqr-6v78-jr5g)][2])
  • AGENTS.mdやリポジトリ内の説明ファイルを常に信頼するPull Requestで変更できるファイルなら、そのファイル自体が攻撃者の入力になり得ます。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])
  • AIエージェントが出した変更をそのまま自動リリースするレビューや別工程を挟めば、外部入力から本番環境まで一気につながる経路を切れます。
  • 今回のBlack Hat研究を「Claude Code・Gemini・Codexが実際に大規模攻撃された事件」と紹介する公開された内容は主にセキュリティ研究者による脆弱性検証と責任ある開示であり、一般攻撃者による大規模被害を報告したものではありません。([[Novee](https://novee.security/blog/critical-flaws-in-anthropic-google-and-openais-coding-agents/)][1])
  • 危険だからAIコーディングエージェントをすべて手動操作へ戻すIssue分類、コードレビュー、テスト、脆弱性検出などAI自動化には大きな利点があります。権限境界を整理することで利便性を残せます。
Step 6

AIの前向きな活用

AIを「公開受付担当」と「実行担当」に分ける

AIコーディングエージェントを安全に活用するなら、会社の受付と作業担当を分けるイメージが分かりやすいです。公開Issueを読むAIは、内容の要約、カテゴリ分け、重複Issue検索、必要情報の不足確認まで担当する。実際にコードを書き換えるAIは、確認済みのIssueだけを別の権限・別ジョブで処理する。さらにmergeやreleaseは人間が承認する。この構成なら、AIが得意な大量の一次処理を自動化しながら、知らない人から届いた文章へ会社の鍵を直接渡さずに済みます。OpenAIもCodex Actionで利用者制限、信頼できない入力の扱い、最小限のpermission-profileを組み合わせることを案内しています。([[GitHub](https://github.com/openai/codex-action/blob/master/docs/security.md)][3])

  • AIが公開Issueを「バグ・質問・要望」に自動分類する
  • AIが既存Issueから重複候補だけを提示する
  • 不足している再現手順をAIが質問コメントとして作成する
  • 修正候補は別の読み書き可能なジョブへ人間が送る
  • AIがPull Requestを作成してもmergeは人間が確認する
  • release権限や本番環境の秘密情報はAIのIssue整理ジョブへ渡さない
誠のアイコン

誠主任からひとこと

AIエージェントの話になると、「AIが騙された」という部分に目が行きがちなんですが、私はその後ろにある“鍵の渡し方”の方を見たいです。知らない人から届いた手紙を読む社員がいるとして、その社員が同時に金庫の鍵、サーバー管理者権限、会社印まで持っていたら、そちらの設計をまず見直しますよね。GitHub IssueをAIに読ませるのは便利です。私も止める理由はないと思います。ただ、「読む」「提案する」「変更する」「公開する」を一つのAI、一つの権限で全部つながない。AIを疑うためではなく、安心して自動化を増やすために、仕事を少し分けておく。今回の事例はその大切さがよく分かるケースだと思います。

今回、覚えておきたいこと

外部の文章を読むAIと、会社の鍵を使うAIを、同じ権限にしない。

情報源

関連記事

AIの肩書きより「誰が責任を持つ回答か」を見る

AIが「専門家っぽく」話しても、資格まであるわけじゃない　米国で“AIと人間を明示する”法案にAMAが支持

健康・医療 はじめて

American Medical Association（AMA）は2026年8月14日、米上院に提出されている「Senior Chatbot Protection Act of 2026」への支持を改めて表明しました。この法案は7月23日に提出されたもので、AIチャットボットが人間や資格を持つ専門家であるかのように表示することを防ぎ、医療・法律・金融など重要な判断に関わる相談では「AIは資格を持つ専門家ではなく、回答だけを根拠に判断しないこと」を利用者へ示す仕組みを求めています。([[American Medical Association](https://www.ama-assn.org/health-care-advocacy/advocacy-update/aug-14-2026-national-advocacy-update?utm_source=chatgpt.com)][1]) 重要なのは、これは現時点で成立した法律ではなく、上院委員会へ付託されている法案だという点です。([[GovInfo](https://www.govinfo.gov/app/details/BILLS-119s5117is?utm_source=chatgpt.com)][2]) AIは医療用語の説明や診察準備には便利ですが、文章が専門的で自信に満ちていることと、その回答に医療資格や診療責任があることは別です。

確認レベル 5 医療の重要判断は資格を持つ専門家へ確認
  • AIへ健康や薬について質問する人
  • 家族の健康相談にAIを使う人
  • AIチャットボット
  • 健康相談
  • Senior Chatbot Protection Act
記事を見る

AIの記憶にも「出どころ」がある

AIが「前に覚えた公式窓口です」と案内。その“記憶”、本当に信用していい？

セキュリティ・権限 はじめて

AIが会話をまたいで好みやプロジェクト情報を覚える「長期メモリ」は、毎回同じ説明をしなくて済む便利な機能です。GitHubも2026年8月11日、Copilot for JetBrainsでチャットセッションをまたいで情報を保持・再利用できるpersistent memoryを追加しました。これは脆弱性の報告ではなく、長期メモリが一般的なAI機能になりつつある一例です。([[The GitHub Blog](https://github.blog/changelog/2026-08-11-copilot-memory-and-ollama-in-github-copilot-for-jetbrains)][1]) 一方、Forcepoint X-Labsは8月4日、外部のWebページや文書に含まれた偽情報をAIが長期メモリへ保存し、後日の別タスクでそれを信頼してしまう「persistent memory poisoning」を研究例として公開しました。([[Forcepoint](https://www.forcepoint.com/blog/x-labs/persistent-memory-poisoning-ai-agents)][2]) AIの記憶機能を怖がる必要はありませんが、「AIが覚えている＝自分が確認した事実」とは限らないため、連絡先・支払先・セキュリティルールなど重要な記憶では出どころを確認する習慣が重要です。

確認レベル 4 重要なAI記憶は出どころを再確認
  • ChatGPTやCopilotなどのメモリ機能を使う人
  • Web閲覧やメール処理ができるAIエージェントを使う人
  • AIメモリ
  • Persistent Memory
  • Memory Poisoning
記事を見る

AIにも「担当者」と「棚卸し日」を付ける

作ったAIエージェント、誰が面倒を見る？　「担当者不在のAI」を増やさない運用ルール

仕事・AI活用 はじめて

AIエージェントは、一度作ればレポート作成、情報整理、問い合わせ対応などを繰り返し実行できる便利な仕組みです。しかし「作った人が異動した」「もう使っていないのに動き続けている」「何のためのAIか誰も説明できない」といった状態になると、便利な自動化が管理されない業務へ変わります。Microsoftは2026年8月6日、社内で50万以上のAIエージェントを可視化・管理している事例を公開し、所有者のいないエージェントが社員の退職後も動き続けることを具体的なリスクとして挙げました。([[Microsoft](https://www.microsoft.com/insidetrack/blog/implementing-agent-365-how-were-governing-and-managing-ai-agents-at-microsoft/)][1]) さらに8月10日には、複数環境のAIエージェントをまとめて確認・管理する機能を発表しています。([[Microsoft Learn](https://learn.microsoft.com/en-us/partner-center/announcements/2026-august)][2]) AIを怖がって自動化を避けるのではなく、「誰が責任を持つか」「いつ見直すか」「いつ止めるか」を最初から決めておくことが、長く便利に使うコツです。

確認レベル 3 定期的に担当者・目的・利用状況を棚卸し
  • 仕事でAIエージェントや自動化を使う人
  • ChatGPT・Copilotなどで共有AIを作る人
  • AIエージェント
  • 業務自動化
  • AI運用
記事を見る