IPAが「至急の点検」を呼びかけ。アプリとAIのAPIキーを点検するスキルを公開します

IPA（情報処理推進機構）が、10月9日に「速やかに点検してください」という注意喚起を出しました。

国内で、不正アクセスによる情報漏えいの公表が相次いでいるためです。 これは、AIでアプリを作って公開している人にも関係のある話なんですよ。

とても大事な内容だったので、点検の手順を「スキル」にしました。 今日は、その中身と使い方を紹介します。スキルの全文も載せるので、コピーして使ってください。

📌 何が発表されたの？

何があった

IPAによると、最近、金融機関や通信事業者など、いろいろな会社から「不正アクセスで情報が漏れた」という公表が続いています。 特に、たくさんの個人情報を扱うネットのサービスが侵入され、データを盗まれる事案が相次いでいるそうです。

今のところ、特定の製品の弱点をねらった攻撃とは断定されていません。 公開しているアプリやサービス、アカウントが乗っ取られたことが入口になっているとみられています。

同じ時期に、国家サイバー統括室・経済産業省・金融庁・警察庁・個人情報保護委員会・JPCERT/CC（ジェイピーサート。セキュリティ事故の相談を受ける組織）も、そろって注意を呼びかけました。

国の機関が、そろって「至急」と言っているわけです。

点検してほしい3か所

• 公開しているアプリ：記録（ログ）に、エラーが急に増えるなど、いつもと違う動きがないか。まず直近1か月、次に3か月と広げて見る。更新していない部品がないか
• 使っている外部のサービス：クラウドやVPN（社外から社内につなぐ仕組み）まで全部洗い出し、ログイン元・時間・失敗の回数を見る。作った覚えのないアカウントや、消したはずなのに復活しているアカウントがないか
• 持っているデータ：いらない情報は持たない。何をどこに置いているかを正確に知る

おかしな所が見つかったら、すぐに「事故」として扱い、専門の会社に詳しく調べてもらうことを強くすすめています。

何が変わる

注意喚起は会社の経営者に向けたものです。 でも、AIでアプリを作って公開している個人や小さなお店も、やることは同じです。

JPCERT/CC の注意喚起には、実際に使われた手口も書かれています。 その中に、こんなものがありました。

• 公開しているスマホのアプリを分解して、裏で使っている「APIキー」を探し出す
• ほかの所で盗んだAPIキーを使って入りこむ
• 画面からは操作できない裏の入口を、直接たたいてアカウントを作る

APIキーは、AIなどのサービスを、プログラムから使うための「合言葉」のようなものです。 AIのサービスとつなぐアプリでも、サーバー側でAPIキーを使うことがあります。

この合言葉が漏れると、情報を盗まれるだけでなく、他人に勝手にAIを使われて、その請求が自分に来ることもあります。 使った分だけ払う仕組みなので、気づいたときには高額に…ということもありえます。

試すなら

小さな会社なら、まずIPAの「5分でできる！情報セキュリティ自社診断」が無料で使えます。 25の質問に答えるだけで、自社の対策がどのくらいできているかが分かります。

自分でアプリを作っている人は、次の章のスキルを使ってみてください。

出典：IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」（2026年10月9日）、JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開・9日更新）、IPA「中小企業の情報セキュリティ対策ガイドライン」

🛡️ 点検スキル「app-security」の中身

スキルって何？

スキルは、AIに渡しておく「仕事の手順書」です。 まとめておくと、AIが必要なときに読み込んで、そのとおりに動いてくれます。 ふつうの文章で書けるので、プログラミングはいりません。 （くわしくは調べ物のスキルの記事でも書きました）

今回の「app-security」は、アプリを作るとき、AIのAPIを足すとき、公開する前、それから今あるアプリを点検するときに使う手順書です。 中身は、大きく3つに分かれています。

1. IPAの点検をそのまま行う

IPAが挙げた点検を、アプリの作業に置きかえて入れました。

• 使っていない公開の入口や管理画面、いらないアカウントが残っていないか
• ログをどこまで取っていて、何日残るか。いつもと違う動きがないか
• 更新していない部品に、知られた弱点がないか
• 管理者が2段階のログイン（多要素認証）を使っているか。権限は必要な分だけか
• 画面でボタンを隠すだけで、裏では誰でも操作できる…になっていないか

2. APIキーが漏れていないか

ここからは、IPAの記事には無い、私が足した点検です。 JPCERT/CC の「キーを探し出す」手口にもつながる所です。

• お金のかかる合言葉は、サーバーに置く：画面のプログラム（HTMLやブラウザで動く JavaScript）や、URLに入れない
• 隠しても、昔の記録に残っている：合言葉を書いたファイルを後から隠しても、過去の保存記録（Git の履歴）や公開したファイルには残っていることがある
• 見えても大丈夫なキーと分ける：Firebase の設定キーのように、もともと公開して使うキーもある。見つかっただけで「漏れた」と決めつけない
• 確かめるために、勝手に使わない：キーが生きているかを試すために、有料のAPIを呼ばない。報告にもキーの値を書かない

3. 「API破産」を防ぐ

API破産は、AIのAPIが止まらずに使われ続けて、思わぬ額を請求されることです。 スキルでは、「お知らせ」と「止める」を必ず分けて確かめます。

たとえば Google Cloud の予算のお知らせ（通知だけの予算）は、金額を超えるとメールが来ますが、請求を自動では止めません。 メールが来る設定があるだけで、安心してしまいがちなんですよね。

• サービス側：本当に止まる上限があるか。前払いでも、残高を自動で足す設定（自動チャージ）があると払い続ける
• アプリ側：1人あたり・全体の回数の上限を、AIを呼ぶ前にサーバーで判定しているか
• 1回の大きさ：回数だけでなく、1回で使う量（文章の長さ・画像の枚数・使うモデル）にも上限があるか
• 自動の処理：失敗したときの「やり直し」が、延々と続く作りになっていないか
• 止まるか試す：上限を超えたら、有料のAPIを呼ぶ前に断れるか。本物ではなく、低い上限やまねの相手で試す

結果の出し方

点検の結果は、1つずつ「確認済み」「要修正」「未確認」「対象外」の4つに分けて出します。 どのファイルや設定を見てそう判断したかも、一緒に書きます。

大事にしたのは、「見つからなかった」を「安全」と言わないことです。 見られなかった管理画面は「未確認」のまま残します。 お知らせのメールしか無いのに「上限を設定済み」とは書きません。

📦 スキルの全文と使い方

スキルの全文

スキルは、下の文章がすべてです。 ボタンを押すとまるごとコピーできるので、そのまま貼って使ってください。無料です。

---
name: app-security
description: アプリ開発・API連携の追加・公開前、およびセキュリティ点検の依頼時に、IPAの注意喚起に基づく認証・権限・ログ・データの確認と、APIキー漏えい・課金暴走の防止を行います。既存アプリの監査では確認できた証拠と未確認事項を分けて報告します。
---

# アプリのセキュリティとAPI費用の点検

## 使い方
新規開発では設計と実装に対策を組み込み、API追加・公開前に関連項目を確認する。既存アプリでは対象フォルダ・公開先・クラウドプロジェクト・課金主体を特定する。全アプリ監査の依頼がなければ無関係なアプリまで変更しない。
IPA由来の点検と、ユーザー要望によるAPI費用対策を区別する。出典と更新確認は、末尾の「出典と仕様確認」を参照する。

## 作業範囲と優先順位
- 新規開発では使う機能に必要な対策を設計・実装に組み込む。部分修正では変更した入口と影響先を点検し、全体監査は依頼された場合に行う。関係のない変更のたびに全項目の監査を繰り返さない。
- 最初に「守るデータ・課金資源」「誰がアクセスできるべきか」「外部入力の入口」「サーバー・外部サービス間の境界」を短く整理し、該当する項目を選ぶ。対象外には理由を付ける。
- 指摘には状態とは別に優先度を付ける。実際の漏えい・不正利用や、公開された秘密キー、誰でも他人のデータや課金APIへ到達できる経路は緊急対応。悪用の条件がそろう重大な欠陥は公開前の修正対象。その他は影響・悪用条件に応じて優先する。未確認という理由だけで安全・危険を断定しない。
- 重大な欠陥を発見したら、網羅的な点検の終了を待たず、値を伏せて対象・影響・必要な対応を報告し、許可範囲内の修正・検証を進める。

## 点検の進め方
- 対象の AGENTS.md・CLAUDE.md・HANDOVER.md（あれば）、構成、公開経路、利用API、データ、認証、運用者を把握する。古い記録を現在の設定の証拠にしない。
- ローカルコード、配信物、Gitの追跡状態・履歴、デプロイ設定、管理画面または読み取りAPIを、必要な範囲で調べる。秘密を含みうる検索は一致内容を表示せず、パス・行番号・分類のみ出す。ログや履歴も同様に扱う。
- 各項目を「確認済み／要修正／未確認／対象外」で記録する。証拠のファイルと行番号、設定の参照場所、確認日時、対象環境を添える。コードだけで本番設定を確認済みにしない。見つからないことを漏えいがない証明にしない。
- 実装の修正が依頼範囲なら、必要な変更と安全な検証まで進める。課金停止、キー失効、権限剥奪など稼働を止めうる本番変更は影響と対象を具体化し、既存の許可範囲を確認して実施する。

## IPAに基づく確認
- 公開アプリと外部サービスを棚卸しし、使っていない公開口、管理画面、不要アカウントを確認する。
- ログは直近1か月から、必要に応じ3か月へ広げる。取得範囲、保持期間、調査担当、ログイン失敗・IP・時間・エラー等の平時との差、アカウント追加・復活を確認する。
- 未適用パッチ・依存関係の既知脆弱性を公式情報で確認し、更新の影響を検証する。
- 管理者の多要素認証、サーバーでの認証・オブジェクト単位の認可、DB/Storageのルール、最小権限、API連携の権限を確認する。画面で隠すだけの権限制御は不可。
- 保有データを必要最小限にし、保管場所、暗号化、アクセスログ、保存・削除方針を確認する。委託先・連絡経路も把握する。
- 異常なログや未知のアカウントがあればインシデントとして扱う。ログ等を保全し、影響範囲を整理、必要な封じ込めと専門家への詳細調査を提案する。証拠を消す操作を避ける。

## 機能に応じた追加確認
以下はアプリの構成に応じた追加点検であり、上記IPA記事の直接の記載として扱わない。適用する仕様や対策は対象技術の公式資料で確認する。
- Web入力・DB操作：入力の型・長さ・許可値をサーバーで制限し、SQL等はパラメーター化する。ユーザー入力のHTML表示やDOM操作では実行可能な内容の扱いを確認する。
- Cookie認証：Cookie属性、セッションの期限・失効、状態を変えるリクエストのCSRF対策を確認する。ログアウト後や権限変更後の操作も対象にする。
- ファイル・URL取込：ファイルの実体・サイズ・保存先・取得権限を確認する。サーバーによるURL取得では内部ネットワークやメタデータへの到達、リダイレクト先を確認する。
- Webhook：送信元の署名等の検証、時刻・再送への対応、同じイベントによる二重処理を確認する。
- AI連携：外部文書やモデル出力を権限の根拠にしない。ツール実行、データ取得、課金操作はサーバーで認可・上限判定し、モデルに渡す秘密と個人情報を必要最小限にする。

## APIキー漏えいの確認
- 課金権限を持つ秘密キーはサーバー側のSecret管理または保護した環境変数に置く。HTML、ブラウザJS、公開環境変数（NEXT_PUBLIC_ / VITE_ 等）、ソースマップ、モバイル配布物、URL、ログ、エラー応答、共有資料に入っていないか確認する。
- .env をGit追跡していないか、.gitignore、過去のコミット、CIログ、ビルド成果物、公開配信物を確認する。.gitignoreへの追加だけで過去の漏えいが解消したと判定しない。
- 公開前提のFirebase設定キー等は秘密キーと区別し、API制限、認証、DB/Storageルール、必要なApp Check等を確認する。公開可能キーが見つかっただけで漏えいと断定しない。
- プロジェクト・環境・用途ごとのキー分離、最小権限、対応APIや接続元の制限、不要キー、失効・ローテーション手順を確認する。
- 漏えいの疑いは値を再掲せず、該当箇所と必要な失効・再発行・利用履歴調査を示す。キーが有効かを試すための有料API呼び出しを勝手に行わない。

## API破産を防ぐ確認
「通知」と「停止」を必ず分ける。
- 提供元側：課金の有無、予算の種類、実際の停止上限、クォータの数値・単位・期間・適用範囲、前払い残高、自動チャージ、超過課金、上限変更権限を確認する。サービスごとの現在の公式仕様と実設定を照合する。
- アプリ側：ユーザー別とプロジェクト全体の回数・費用枠をサーバーで判定する。全インスタンスで共有する原子的な利用枠の予約、並列実行による超過、日付のタイムゾーン・リセット、障害時に無制限許可しない動作を確認する。ブラウザのカウンターやプロセスメモリだけを全体上限にしない。
- 1回の最大入力・出力トークン、画像数・解像度、ファイルサイズ、モデルの許可リスト、同時実行数、タイムアウト、再試行回数・バックオフ、ジョブの重複防止を確認する。クライアント指定で高額モデルや上限を自由に変更させない。
- 課金APIの入口に認証・認可と濫用対策を置く。キーを隠していても、誰でも呼べる代理APIは請求を発生させる。CORSだけをアクセス制御としない。
- 利用記録、異常通知、手動停止スイッチ、残高・予算枠不足時の拒否を確認する。拒否が有料API呼び出しより前に行われることをモックや低いテスト枠で検証する。
- RPM等は速度の制限であり月額の上限ではない。最大単価・出力量・回数から費用を見積もり、AI以外のDB読取、ストレージ、転送量、Cloud Run、定期実行も別枠で確認する。
- 課金集計の遅延や実行中リクエストで超過しうるため「絶対に追加請求されない」と断言しない。通知のみ・停止未検証なら「上限設定済み」と報告しない。

## 対策の検証
- 変更した対策は、正常な操作が通ることと、不正な操作が拒否されることの両方で確認する。認可では未ログイン、一般ユーザー、別ユーザーのデータへのアクセスを、該当する範囲で検証する。
- 費用枠は枠不足、並列要求、再試行、利用枠管理の障害時を対象にする。有料APIはモックに置き換え、拒否された操作では呼び出しが発生しないことを確認する。予約した枠の確定・解放・期限切れを確認し、タイムアウトしただけで提供元の課金が取り消されたと扱わない。
- 本番への侵入試行、大量アクセス、実データの破壊や高額なAPI呼び出しは通常の点検に含めない。ローカルや隔離した検証環境・テストデータを優先する。本番の設定を読めない場合は、コード上の結果と本番の未確認を分ける。

## 完了報告
対象・環境・調査範囲を示し、指摘ごとに「状態／優先度／証拠／影響と悪用条件／修正または次の確認／検証結果」を簡潔に記録する。修正した場合は変更箇所を添える。APIキー漏えい防止と課金停止上限はそれぞれ独立して判定する。特定できない対象やアクセスできない管理画面は未確認として残し、確認手段と、未確認によって残る公開判断上の制約を示す。実施範囲を超えて「安全」「脆弱性なし」と保証しない。

## 出典と仕様確認
確認日：2026-10-15。以下はいずれも【一次】公式情報。

- IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」（公開2026-10-09）
  https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html
  公開アプリ、外部サービス、ログ、アカウント、パッチ、保有データ、権限と認証、連携管理、組織・委託先への対応の根拠。特定製品の脆弱性を狙った攻撃とは断定されていない。
- Google Cloud: Create, edit, or delete budgets and budget alerts
  https://docs.cloud.google.com/billing/docs/how-to/budgets
  alerts-only budgetは通知であり自動停止しない。現在の文書には対応サービス向けspend cap budgetへの案内もあるため、Google Cloudの予算は全部通知だけ、と一括で断言しない。対象サービスと実設定を確認する。
- Google Cloud: Cloud Quotas overview
  https://docs.cloud.google.com/docs/quotas/overview
  クォータの対象・単位・範囲を確認する入口。回数やリソースの上限をそのまま金額上限として扱わない。
- Google AI: Using Gemini API keys
  https://ai.google.dev/gemini-api/docs/api-key
  秘密キーの保護、クライアントへの埋め込みを避ける根拠。

API費用対策の詳細はユーザーの追加要望に基づく実装・監査方針であり、IPA記事の直接の記載として扱わない。提供元やサービスを特定してから、その時点の公式仕様を再確認する。

貼る場所

• ふだんのチャット（Claude・ChatGPT・Gemini）：会話の最初に全文を貼って、「この手順で点検して」と続ける。点検したいコードや設定も、秘密キー・パスワード・個人情報を伏せて一緒に渡す
• Claude Code：ホームフォルダの .claude/skills/ に app-security というフォルダを作り、その中に SKILL.md というファイルを作って全文を貼る。以後は必要なときに自動で読み込まれる
• Codex（OpenAI）：同じく、ホームフォルダの .agents/skills/app-security/SKILL.md に貼る

頼み方

スキルとして入れたあとは、アプリのフォルダを開いた状態で、こんなふうに頼みます。

app-security で、このアプリのAPIキーの置き場所と、使いすぎを止める上限を点検して。

全文は長いな…という方は、まず次の短い文を貼るだけでも、考え方は伝わります。

このアプリを点検してください。お金のかかるAPIキーが、画面のプログラム・URL・Gitの履歴・公開したファイルに入っていないかを調べてください。キーの値は表示しないでください。また、APIの使いすぎを「お知らせするだけ」の設定と「本当に止まる」設定を分けて、止まる上限があるかを確かめてください。結果は「確認済み・要修正・未確認・対象外」に分け、判断の根拠にしたファイルや設定を書いてください。確かめられなかったことは「未確認」と書いてください。

出典：Google Cloud「予算と予算アラートの作成」（英語）、OpenAI「Codex Skills」（英語）

🖥️ スキルの中身を、読みやすいHTMLにしてもらいました

ここまでのスキルは、AIが読むための手順書です。人が読むには長いので、要点が分かるHTMLの資料にもしてもらいました。

さらに、文字の大きさや余白を調整して、最初に押さえたい3つを先頭に置きました。スマホでは、横に長い表も1項目ずつ縦に読める形にしています。

📝 使ったのは「HTMLファースト式」の考え方

こうした資料づくりの手順をまとめたのが、「html-first-docs」というスキルです。まずHTMLで内容を整理し、読みながら直してから、必要なら印刷用のレイアウトやPDF・パワーポイントに進めます。

今回は、ブラウザで読むHTMLの段階まで。「見出しを大きく」「説明を短く」「スマホでも読みやすく」と、ふつうの言葉で直していけます。

この点検スキルの内容を、初めて読む人にも分かるHTMLにしてください。最初に要点を置き、本文の文字を大きめにして、見出しと余白に差をつけてください。スマホでも横にスクロールせず読める形にしてください。

この頼み方を、そのままコピーして使っても大丈夫です。点検をするスキルと、その内容を人に伝える資料づくりのスキルを、組み合わせて使っています。

HTMLで資料を作る手順は、HTML資料づくりを紹介した記事と、「HTMLファースト式」の教材を紹介した記事にもまとめています。

💬 今日のひとこと

私も10月のはじめに、自分のアプリでお金のかかる所を棚卸ししました。 そのとき気づいたのが、「予算を超えたらメールで知らせる」設定は、請求を止めてはくれない、ということでした。

AIのおかげで、アプリは誰でも作れるようになりました。 でも、作れることと、守れることは別なんですよね。

今回のスキルで点検しても、「未確認」がいくつも残ると思います。 それで大丈夫です。どこが分かっていないかが分かるだけでも、一歩前に進んでいます。