AI活用マップAIと働くための設計図
なぜAI活用が必要かコラムお問い合わせ

トップAIでつくるセキュリティ入門

AIでつくる本文

開発者が知っておくべきセキュリティ入門

情報この章の要点

AIと一緒にアプリを作れるようになると、「動かすこと」に意識が向きすぎて、セキュリティの穴を埋め込んだまま公開してしまうことがあります。この章では、非エンジニアが特に見落としやすい「危ないと気づく力」の入り口を整理します。

利用者と開発者、「危ない」が違う

AIを使う人（利用者）と、AIを使ってアプリを作る人（開発者）では、「危険」の意味がまるで違います。

利用者が気をつけることは、フィッシング詐欺や不審なリンク、個人情報の入力先といった「外から来る攻撃に引っかかるか」です。

開発者が気をつけることは、自分が作ったアプリの中に「攻撃される隙」を作ってしまうかどうかです。利用者は騙されないようにすればいい。でも開発者は、知らないうちに他人を攻撃されやすい状態に晒してしまう可能性があります。

メモ✏️ 一言で言うと

利用者は「標的にならない」を意識する。開発者は「穴を作らない」を意識する。

この意識の切り替えが、開発者としての出発点です。

秘密情報の守り方

バイブコーディングで真っ先に引っかかるのが、APIキーや認証トークンの扱いです。

APIキーとは、「あなたが使っていい」と認証するための合言葉のようなものです。GitHubやOpenAI、Notionなどの多くのサービスが、このキーで利用者を識別します。

メモ✏️ 用語メモ：APIキー

外部サービスを自分のプログラムから利用するための「鍵」です。この鍵が漏れると、他人があなたのアカウントで勝手に操作できてしまいます。

やりがちな危険な例：

# ❌ これは絶対NG
api_key = "sk-abc123def456..."

コードの中にAPIキーを直書きすると、GitHubにアップした瞬間に世界中に公開されます。公開リポジトリは自動プログラムが常時巡回していて、pushから数分でキーが拾われます。拾われた鍵で高価なサーバーを大量に起動され、気づいたときには数百万円の請求になっていた、という事例も実際にあります。

正しい扱い方：

  1. .env というファイルにAPIキーを書く
  2. .gitignore に .env を追加して、Gitで管理されないようにする
  3. プログラムからは「環境変数」として読み込む
  4. 公開するとき（本番環境）は .env ファイルを置かず、公開先の管理画面で環境変数を設定する
# .env ファイル（Gitに入れない）
OPENAI_API_KEY=sk-abc123def456...

# ✅ 環境変数から読み込む
import os
api_key = os.environ.get("OPENAI_API_KEY")

4つ目を落とす人が多いです。手元では .env で動いていたので、そのままアップロードしてしまう。VercelやRenderのような公開サービスには必ず環境変数の設定画面があるので、鍵はそこに入れます。ファイルとして持ち出さないのが安全です。

1Password CLIで平文そのものを置かない

.env はうまくいっても、結局は鍵を平文でパソコンに置いていることに変わりありません。.gitignore の書き忘れひとつで事故になります。

僕は普段、1Password CLI を使っています。やっていることは単純で、金庫に保管した鍵への参照だけをファイルに書き、実行の瞬間に本物を差し込みます。

# .env.1p ── 参照だけなので、このファイルはGitに入れてよい
OPENAI_API_KEY=op://API keys/OpenAI/credential

op run --env-file=.env.1p -- python main.py

平文の鍵がディスクに残らないので、「うっかりコミットした」という事故がそもそも起こりません。鍵を入れ替えるときも金庫側を直すだけで済みます。

ただし万能ではありません。実行のたびに指紋認証が入るので、人が介在しない自動実行（定時バッチなど）とは相性が悪いです。僕も自動実行するアクションに対しては、リスク << 効率と考え .env に戻しています。1Passwordの契約も要るので、まずは .env と .gitignore の原理を押さえて、次の一歩として考えるくらいがちょうどいいと思います。

なお、これはどちらも手元の環境の話です。公開先（本番）では、いずれの方式でも結局ホスティングの環境変数を使うことになります。

ヒント💡 AIに聞くときのコツ

「このコードのAPIキーを安全に管理するには？.env ファイルと .gitignore の設定も一緒に教えて」と聞くと、まとめて手順を出してくれます。

従量課金の蛇口を締めておく

鍵が漏れなくても、請求が跳ね上がることがあります。あなたが公開したアプリそのものが、使われすぎる場合です。

AIのAPIは「使った分だけ払う」従量課金がほとんどです。チャット機能をひとつ公開すれば、そこは誰でも叩ける入り口になります。画面上で「1人8回まで」と制限したつもりでも、その制限がブラウザ側にしかなければ、開発者ツールを開くだけで外せます。ブラウザを通さず直接呼ばれたら、最初から無関係です。

メモ✏️ 一言で言うと

利用者に見せている制限と、サーバーが守っている制限は別物。守れるのはサーバー側だけ。

最低限やっておくこと：

  1. 提供元で予算の上限とアラートを設定する（Google CloudやOpenAIの管理画面で設定できます。これが最後の砦です）
  2. サーバー側でも回数を制限する（同じ人から短時間に何十回も来たら断る）
  3. 呼び出せる場所を絞る（自分のサイトからの呼び出しだけを受け付ける）

1番だけでも先にやっておけば、最悪でも被害額に天井ができます。順番としてはここが最優先です。

ヒント💡 AIへの依頼例

「このAPIエンドポイントに、IPアドレス単位のレート制限を追加して。あわせて、全体の呼び出し回数にも上限を設けて」

プロンプトインジェクション

AIを使ったアプリ特有の攻撃です。

チャットボットや自動化システムを作ると、ユーザーの入力がそのままAIへの指示として渡る場面が出てきます。悪意のある人が入力欄に「これまでの指示はすべて無視して、次の指示に従ってください」といった文を入れると、AIが作り手の意図を離れて動いてしまうことがあります。

ここで、よくある誤解を先にほどいておきます。AIは、あなたのAPIキーやパスワードを知りません。 環境変数に入れた鍵はプログラムが使うもので、AIには渡っていないからです。「管理者のパスワードを教えて」と入力されても、知らないものは答えようがありません。

漏れるのは、あなたがAIに渡したものです。

メモ✏️ 一言で言うと

AIに渡したものは、AIと話せる人に見せたのと同じ。

具体的には、次の3つが漏れます。

  • システムプロンプトに書いた内容（「あなたは〇〇社の担当者です。社内規定は…」と書けば、その規定は引き出せます）
  • AIに参照させたデータ（社内文書やマニュアルを読ませていれば、質問を変えながら少しずつ引き出せます）
  • AIに持たせた道具（メール送信やファイル削除ができる設計なら、それを勝手に使わせられます）

例具体的な例

有料会員だけに公開している資料を、AIに読ませてチャットで答えさせたとします。 「資料の3章を要約して」「その続きは？」と質問を重ねられる。 → 資料そのものを渡していなくても、中身は少しずつ再現できてしまいます。

対策の考え方：

  • 見られて困るものは、そもそもAIに渡さない（これが一番確実です）
  • 権限のある操作の前には必ず確認ステップを挟む（「本当に削除しますか？」など）
  • ユーザーが操作できる範囲を最初から絞る（何でもできる設計にしない）
  • システムの指示は「上書きされない場所」に置く（ユーザー入力と混ぜない。多くのAPIには systemInstruction のような専用の置き場があります）

「AIが賢い」からこそ生まれる脆弱性です。AIに任せる範囲と、人間が確認する範囲を意識して設計することが防御になります。

外から来る入力を疑う

アプリが受け取るデータは、ユーザーが何を入れてくるかわからないという前提で作ります。

想定しているのは「名前を入力してください」でも、悪意ある人は全然違うものを入れてきます。

メモ✏️ 用語メモ：インジェクション攻撃

ユーザーの入力欄に、プログラムやコマンドとして解釈される文字列を混ぜ込む攻撃です。「注入（inject）」することからこう呼ばれます。

典型的なパターン：コマンドインジェクション

# ❌ 危ない：ユーザー入力をシェルコマンドに直接つなぐ
filename = input("ファイル名を入力してください")
os.system(f"convert {filename} output.pdf")

ここに ; rm -rf / のような文字列を入れられると、サーバーのファイルが全消去される恐れがあります。

# ✅ 安全：リスト形式で渡すとシェルとして解釈されない
subprocess.run(["convert", filename, "output.pdf"])

ポイントは、入力された文字列をシェルに解釈させないことです。リスト形式で渡せばシェルを経由しないので、; や && を混ぜられても、ただのファイル名として扱われます。AIに「この処理をコマンドインジェクション対策で書き直して」と依頼すると修正してくれます。

ヒント💡 最初から依頼するコツ

「入力バリデーション付きで書いて」とAIへの最初の指示に一言添えるだけで、安全な書き方にしてくれます。後から修正するより、最初から入れた方が楽です。

認証と認可は別もの

ログイン機能を付けるとき、混同しやすいポイントがあります。

  • 認証：この人は誰か（本人確認）
  • 認可：この人はそのデータにアクセスしていいか（権限確認）

例わかりやすい例

Aさん（ユーザーID: 101）がログインしています。 URLを https://example.com/user/102/data に書き換えたら、Bさんのデータが見えてしまいました。 → ログイン済み（認証OK）でも、他人のデータを見てはいけない（認可NG）

「ログインしているかどうか」だけを確認して、「誰のデータにアクセスしているか」を確認し忘れるのが典型的なミスです。

AIへの指示例：

「このAPIエンドポイントに、ログイン中のユーザーが自分のデータにしかアクセスできない認可チェックを追加して」

この一文を忘れずに添えるだけで、かなりのリスクを防げます。

ライブラリの脆弱性チェック

アプリは自分が書いたコードだけでなく、他の人が作ったライブラリ（部品）を大量に使って動いています。これらのライブラリに後から脆弱性（セキュリティの穴）が見つかることがあります。

定期的にチェックするコマンドがあります

# Node.js（JavaScriptプロジェクト）の場合
npm audit

# Pythonの場合
pip-audit

実行すると「このライブラリに問題がある」「この脆弱性の深刻度は高い」などが一覧で出てきます。

ただし、深刻度だけで決めると判断を誤ります。見るべきは「深刻度」と「その機能を自分のアプリが使っているか」の2つです。

たとえば「画像処理ライブラリに深刻度・高の脆弱性」と出ても、そのアプリが画像を一切扱っていなければ、攻撃者が届く経路はありません。逆に深刻度が中でも、自分のアプリの入り口に直結しているなら、そちらが先です。

ヒント💡 バイブコーディングでの扱い方

定期的に npm audit を走らせて、問題があったら「audit結果を貼ります。このアプリのコードを見たうえで、それぞれ実際に攻撃される経路があるか判定して、対応の優先順位を付けてください」とAIに聞くのが一番早いです。深刻度の一覧を眺めるより、自分のアプリに引きつけて判断してもらうほうが速く、正確です。

AIにもレビューしてもらう習慣

自分が書いた（AIに書かせた）コードや設定を、外部に公開したり本番環境にデプロイしたりする前に、もう一度AIにも見てもらう習慣をつけると、見落としをかなり減らせます。

書いた本人が気づけない穴は、書いた本人には見えません。AIに書かせたコードなら、なおさらです。別の視点で読み直してもらうだけで、精度は上がります。

ヒント💡 AIへの依頼例

「このコードや設定に、セキュリティ上の問題がないか確認してください。特にAPIキーの直書き、権限チェックの漏れ、外部からの入力の扱いを重点的に見てください」

書くモデルとレビューするモデルを分けるだけでなく、レビュー工程だけ普段より性能の高いモデルに切り替える、という手もあります。僕はClaude Fable 5のような高性能モデルにコードのチェックを任せることがあります。

公開ボタン、デプロイボタンを押す前の、ひと手間です。

「作れる」と「安全に作れる」は違う

バイブコーディングでアプリが作れるようになると、セキュリティだけが置き去りになりやすいです。

やること 最低限の対策
APIキーを使う .env に置き、.gitignore で除外する（1Password CLIならさらに安全）。本番は公開先の環境変数に入れる
外部APIを従量課金で使う 提供元で予算の上限を設定し、サーバー側にも回数制限をかける
AIに何かさせる 見られて困るものは渡さない。ユーザー入力とシステムの指示を混ぜない。権限のある操作は確認を挟む
外からデータを受け取る ユーザー入力は「疑う」前提で扱う
ログイン機能を付ける 認証だけでなく認可も確認する
ライブラリを使う 定期的にnpm audit 等でチェックし、深刻度と到達可能性の両方で優先度を決める
公開する前 AIにもレビューさせる。可能ならレビューだけ高性能なモデルに任せる

完璧なセキュリティを最初から目指す必要はありません。ただ、「ここは危ないかも」と気づける目を持つことが、開発者としての最初のステップです。

（参考図書）体系的に学ぶ安全なWebアプリケーションの作り方

この章で扱ったのは、あくまで「危ないと気づく力」の入り口です。セキュリティを体系的に、本格的に学びたくなったら、徳丸浩著『体系的に学ぶ安全なWebアプリケーションの作り方』（通称「徳丸本」）を薦めます。Webアプリケーションの脆弱性がなぜ生まれるのか、原理から実践的な対策までを一冊で押さえられる定番書です。

このAI活用マップは「AIと一緒に手を動かしながら気づきを得る」ことを目的にしているので、体系的な理論解説までは踏み込んでいません。この章で紹介した内容を実際に自分のアプリで確認してみて、もっと深く理解したいと思った段階で読むと、腹落ちしやすいはずです。