今週のAIエージェント事故ニュースを見て、まず自分の環境で3つだけ確認した。

• gh-aw の実行バージョン

• MCP Registry のバージョン

• BYOKキーの請求先

所要時間は12分。

結果、怖いのは脆弱性そのものより、自社で使っているか即答できない状態だった。

GitHub Agentic Workflows の billing 影響バグと、MCP Registry の未認証 SSRF(CVE-2026-44430)。どちらも「便利だから入れた」現場ほど、棚卸しが遅れる。怖い話で終わらせず、明日からでも自社の運用に当てて潰せる監査チェックに変換する。

📋 この記事でわかること

• ✅ 今週起きた2つのAIエージェント事故の中身(billing影響バグ/未認証SSRF)

• ✅ 「便利だから入れた」現場が一番危ない構造的理由

• ✅ 自社で動いているエージェントを30分で監査するチェック観点

• ✅ 事故ニュースを「ただの怖い話」で終わらせず、運用ガードレールに落とす考え方

• ✅ メンシ境界以降: 監査チェックリスト30項目 / 受託として売る時の納品コントラクト雛形 / 営業文ひな型

直近公開「AI副業で稼げない理由は、作る力じゃなく『届ける工程』がなかったから」の続編として、

「届けた先で事故らない運用」の話をする。

🔥 結論: いま、エージェントは「成果」より「事故らない運用」のほうが先に売れる

エージェントを業務に入れる需要は確かに増えた。だが現場で受託として通るのは、派手な自動化デモではなくて、「課金が読める / 権限が小さい / CVE が監視されている」 という地味な3点だ。

理由は単純で、AI 関連の事故は今、1件あたりの金額と説明責任が跳ね上がっている。

• 課金が読めない → 月次予算が立てられず継続が止まる

• 権限が強すぎる → 情シスとセキュリティで合議が止まる

• 「便利な統合」が増える → 攻撃面が広がって CVE で止まる

今週の2件は、この3つの停止要因をほぼ全部含んでいる。順に潰す。

📊 事故①: GitHub Agentic Workflows の billing 影響バグ

GitHub Agentic Workflows(gh-aw) では、0.68.4 から 0.71.3 までが billing に影響するバグで retired 扱いになっている。ここで大事なのは「いくら請求されたか」を想像で語ることではなく、retired 範囲が現場の .lock.yml や CI に残っていないかを確認することだ。

一次ソース: 🔗 https://github.com/github/gh-aw

どこが現場で危ないか

• CI 上で agent が自走するため、1イテレーションのコストが人間に見えない

• .lock.yml で engine / toolset を pin している場合、retired 範囲の version が固定されたまま稼働している

• BYOK でモデルキーを刺してる場合、請求の主体が誰か(GitHub 側か自社キーか)が曖昧になりやすい

公式には「billing に影響するバグ」とされている。だから現場で見るべきは、実際の請求額そのものより先に、どのバージョンが CI で動き、どのキー・どの予算枠に紐づいているかだ。

30分で潰せる観点

1. gh aw --version を記録

2. .lock.yml の engine pin / toolset pin を記録

3. retired 範囲 / 課金に影響する既知バグに該当しないか、Releases ページで照合

4. BYOK のキーがどの環境変数で、どの予算枠に紐付くかを 1 枚にまとめる

ここまで通せれば、少なくとも「どのエージェントが、どの請求枠で、どの retired 範囲にいるのか説明できない」状態は潰せる。

実際に照合するときは、gh aw --version だけでは足りない。.lock.yml、CI workflow の pin、BYOK の請求先まで同じ行に並べる。retired 範囲に入っているかどうかを、月末の請求書ではなく、今日の台帳で判断する。「知ってたら今日確認できた」は、いつも事後にくる。

⚠️ 事故②: MCP Registry CVE-2026-44430(未認証SSRF)

もう1件は MCP Registry 側で、HTTP namespace verification に未認証の SSRF(CWE-918)があり、v1.7.7 で修正されている。

一次ソース: 🔗 https://github.com/advisories/GHSA-r48c-v28r-pf6v 🔗 https://osv.dev/vulnerability/GHSA-r48c-v28r-pf6v 🔗 https://advisories.gitlab.com/golang/github.com/modelcontextprotocol/registry/CVE-2026-44430/ 🔗 https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.7

なぜ「便利な現場」ほど刺さるか

MCP Registry を内製で立てている現場は、たいてい「複数チームに MCP を配りたい」「MCP を社内マーケットプレイス化したい」みたいな、前向きな動機で導入している。動機が前向きな分、影響範囲が広い。

未認証 SSRF が刺さると、Registry が裏で叩ける内部 URL が外から強制的にプローブされる。クラウドメタデータエンドポイントに到達できる構成だと、認証情報や内部メタデータへのアクセスリスクが出る。実害の大きさは IMDS 設定、egress 制御、実行環境の権限に依存する。

30分で潰せる観点

1. 自社/クライアントの Registry バージョン確認(Go module / Docker tag / 監視ダッシュボード)

2. >= 1.7.7 でなければ即パッチ計画

3. HTTP verification(/v0/auth/http, /v0.1/auth/http)を使う構成なら優先度を上げる

4. egress 制御(メタデータエンドポイントへの outbound 遮断)が入っているか確認

「Registry を入れていない」と思っている現場でも、Docker compose の依存に紛れているケースがあるので、Image レイヤーまで掘る。

アドバイザリ上は、v1.7.7 で HTTP namespace verification の SSRF 経路が修正されている。だから現場では、Registry のバージョン確認と、メタデータエンドポイントへの outbound 遮断をセットで見る。「うちは HTTPS だから SSRF は来ない」という現場ほど、outbound 制御が入っていない。壊れ方を想像できた後に直すと、差がそこで出る。

🤔 2件に共通する「現場が止まる構造」

両方とも、技術的には「バージョンを上げろ」で終わる話。だが、現場では止まる。

止まる理由は3つに集約される:

• 誰が監視するか決まっていない: CVE 一次ソースを毎週見ているのは情シスじゃなく、AI を入れた本人だけ

• 影響範囲が説明できない: 「で、うちは何台に影響するの?」に即答できないと、上長判断が止まる

• 直した後の再発防止が宿題: パッチを当てて終わりにすると、3ヶ月後にまた同じ穴で詰む

ここを テンプレ化 して、「監査→修正→運用ガードレール」を 1 セットで納品できる人は、現場に対して圧倒的に強い。逆に「便利な PoC を作って渡す」だけの人は、ここで一気に弱くなる。

💡 ニュースを「読んで終わり」にしない読み方

月曜朝にリリースノートを読んで、午後には .lock.yml と CI workflow を grep して照合した。夕方に Slack へ「今週の2件、影響有無は確認済み。未確認の箇所は台帳に残した」と1行流した。所要時間 12 分。ログが残る。

翌日「お前の環境どうだった?」と聞かれた時に、「14:03 に確認済み、問題なし」 と答えられる人と、「たぶん大丈夫」で返す人がいる。次に相談されるのは、たぶん前者だ。

「読んだ → 手元で当てた → チェック表に1行足した」まで毎回やる。これだけで、ニュースが証拠束に変わる。

📂 俺が実際に使っている運用ガードレール用 md(抜粋)

事故ニュースが出たときに更新するため、実ファイルとして docs/AI_AGENT_OPERATION_GUARDRAILS.md に置いた。冒頭部分をそのまま貼る。完全版はメンシ側。

# AI Agent Operation Guardrails

Last reviewed: 2026-05-18

## 2026-05-18 Check Log

Sources:
- GitHub Agentic Workflows: https://github.com/github/gh-aw
- MCP Registry CVE-2026-44430: https://github.com/advisories/GHSA-r48c-v28r-pf6v
- MCP Registry v1.7.7: https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.7

## Immediate Checks

1. Is any gh-aw version in the retired 0.68.4 to 0.71.3 range?
2. Is MCP Registry >= 1.7.7?
3. Can the billing owner for each BYOK key be explained in one line?
4. Is outbound access to 169.254.169.254 and private ranges blocked or explicitly owned?
5. Can agent tool calls be traced for at least 30 days?

このファイルを実際に置いておくと、事故が出た時の動き出しが30分速くなる。受託で動いている時は、その30分が単価に直接効く。

このファイルを見せながら「御社の環境に同じ粒度で30分当てさせてください」が、受託の最初の接点になる。凝ったデモより「毎週更新している実物ログ」の方が話が早い。AI受託は、技術力より「不安を減らす証拠束」を持っている方が強い。

まず無料でここだけ見てください。

1. gh-aw / workflow engine / Registry のバージョンを即答できるか

2. retired / patched version に該当しないか

3. BYOK キーの請求先を説明できるか

4. 169.254.169.254 への outbound を遮断しているか

5. agent の tool call ログを30日以上追えるか

ここまでが無料部で出せる最小チェック。完全版30項目はメンシ側に置く。

🌟 最後に

AI を業務に入れている現場は、もう「成果が出るか」のフェーズじゃない。「出した成果を、事故らせずに続けられるか」のフェーズに入っている。同じ系統の事故は、今後も出る前提で運用した方がいい。

あなたの手元で動いているエージェント、gh aw --version と Registry のバージョン、今日言えますか⁉

言えなかったなら、今日のうちに台帳へ書く。そこから監査は始まる。

スキいただきいつもありがとうございます。書く励みになります！

🔒 ここから先はメンバーシップ限定です。