はたらクラフト

現役エンジニアがアプリ開発で必ずやるセキュリティ対策5選

開発・運用の仕組み化

アプリのセキュリティ対策は、自分だけが使うアプリと、公開してほかの人も使うアプリで、やるべき内容がかなり違います。

ただし、どちらのアプリにも欠かせない対策があります。この記事では、ぼくが全アプリで必ずやっている5つのセキュリティ対策を、自社アプリの具体例とともに解説します。

本記事は、GitやGitHubの理解が前提です。まだの方は、先にGit・GitHubの初期設定と基本操作を解説した記事をご覧ください。

動画で見たい方はこちら。

対策1:権限は、読み書きと範囲の2つの観点で必要最小限にする

権限を読み取りだけに絞り、範囲も必要な分だけにすれば、奪われても被害が小さいことを示す図解

1つ目の対策は、アプリに与える権限を必要最小限にすることです。権限には、読み取り・書き込みそのものの許可と、読み書きできる範囲という2つの観点があります。

やりたいことが読み取りだけで済むなら、書き込み権限は与えません。書き込み権限は、データの書き換えや設定の変更までできる強力な権限だからです。

読み書きできる範囲も、やりたいことに必要な分だけに絞ります。

読み取り・書き込み自体の許可と、許可する範囲という2つの観点で権限を最小限にしておけば、万が一権限を奪われても、被害を最低限に抑えられます。

自社コンテンツ分析アプリでも権限を最小限に絞っている

権限の考え方を、ぼくの自社コンテンツ分析アプリで説明します。このアプリは、YouTubeやGoogle、Xなどの各媒体から、定期的にデータを取得します。

コンテンツ分析アプリの画面

データ取得の権限は、読み取りだけに絞っています。データを見て分析するのが目的なので、データを書き換える必要はないからです。

読み取る範囲も、分析に必要な情報だけです。たとえばWebサイトの分析データでは、予約と問い合わせは「予約 / 問い合わせ」の件数だけを読み、問い合わせ元のメールアドレスや問い合わせ内容は取得していません。

Webの分析データのページ一覧で、「予約 / 問い合わせ」の列に件数だけが並ぶ画面

分析に不要な情報を読まなければ、権限が流出しても、盗まれる情報を減らせます。

対策2:機密情報はGitHubに上げない

アプリ開発では、APIキー(外部サービスを使うための鍵)などの機密情報をよく扱います。機密情報をGitHubに上げると、不正利用されて自分のデータを盗まれたり、多額の請求につながったりします。

実際に、GitHubに上げたAPIキーを悪用され、5万5,444ドルを請求された事例もあります。

プライベートリポジトリでも、機密情報を上げてはいけない

プライベートリポジトリでも、消した機密情報は履歴に残り、将来の公開やGitHubの脆弱性で他人に見られてしまう流れの図解

GitHubでは、自分しか見られないプライベートリポジトリを作れます。プライベートなら機密情報を上げても問題ないと思うかもしれませんが、それもNGです。

今はプライベートでも、将来公開するかもしれないからです。公開前に機密情報を消しても、GitHubには過去の履歴が残るため、履歴を遡れば見えてしまいます。

すべての履歴から機密情報を消すのは、かなりの手間がかかります。それなら、プライベートリポジトリでも、最初から機密情報を上げないようにしておくべきです。

加えて、GitHub自体から機密情報が流出するリスクもあります。実際2026年には、GitHubでほかのユーザーのプライベートリポジトリまで読めてしまう脆弱性が見つかりました。

Betterleaksなら、機密情報のコミットを自動で止められる

コミット時にBetterleaksが機密情報の混入を判定し、混入なしなら完了、混入ありなら停止する流れ

GitやGitHubに機密情報を上げるのを防ぐなら、Betterleaksが便利です。コミットのときに機密情報が混ざっていないかを自動で判定し、混ざっていればコミットを止めてくれます。

過去の全コミットに機密情報が入っていないかも、一瞬でチェックできます。

Betterleaksは、有名なツールGitleaksの原作者が開発している後継プロジェクトです。無料で使えるので、これからアプリ開発で導入するならBetterleaksがおすすめです。

導入は、Claude Codeなどに次のように指示するだけです。

Betterleaksを導入して、コミット時に機密情報をチェックするようにして

対策3:AIに機密情報を読ませず、危険なコマンドを実行させない

3つ目の対策は、AIエージェントに機密情報を読ませないことと、危険なコマンドを実行させないことです。

機密情報は、dotenvxで暗号化するか、1Passwordで管理する

.envの機密情報をdotenvxで暗号化するか1Passwordで管理してアプリとAIに使わせる流れの図解

APIキーなどのアプリの機密情報は、.env のような環境変数ファイルに置くのが一般的です。しかし、このファイルをAIに読ませると、機密情報が流出する危険があります。

そこで、環境変数ファイルをdotenvxで暗号化するか、機密情報を1Passwordで管理し、アプリやAIには1Password経由で使わせるのが一般的です。

dotenvxは無料、1Passwordは個人プランの年払いで月3.99ドルです(2026年11月10日時点)。

ぼくは、アプリの機密情報を1Passwordに入れています。具体的な方法は、AIエージェントに機密情報を見せない1Passwordの活用法を解説した記事をご覧ください。

危険なコマンドは、指示ではなく設定で禁止する

AIへの指示では危険なコマンドが素通りするが、Claude Code本体の設定なら止められる対比

AIが危険なコマンドを実行できないよう、設定しておくことも重要です。たとえばClaude Codeでは、settings.json というファイルで、コマンドの実行の許可・確認・禁止を設定できます。

  • allow:確認なしで実行してよいコマンド
  • additionalDirectories:プロジェクト外で読み取りを許可するフォルダ
  • ask:実行前に承認を求めるコマンド
  • deny:実行を禁止するコマンド

Claude Codeのsettings.jsonで、allow・additionalDirectories・ask・denyの各設定と、それぞれの意味を示す注釈

AIへの指示やスキル、CLAUDE.md などで、やってはいけないことを伝える方法もありますが、指示が守られる保証はありません。

settings.json などの設定は、AIではなくClaude Code自体の挙動を制御するため、AIに無視される心配がありません。

設定の土台は、Claude Codeなどに次のように指示するだけで作れます。

セキュリティ的に危険なコマンドは拒否または承認を求めるよう設定して

あとは使いながら、「このコマンドは拒否にしていたけど、使う場面が多いから承認に変える」のように微調整していきます。

今回はClaude Codeを例にしましたが、CodexのルールやAntigravityの権限設定のように、ほかのAIエージェントにも同様の設定があります。

対策4:依存ライブラリは、間接依存まで自動で更新する

アプリが使うライブラリの先にある間接依存のライブラリまで古いままだと、脆弱性が残ったままアプリが動き続けることを示す図

アプリは、ライブラリと呼ばれるさまざまな部品を組み合わせて作られています。プログラミング言語や環境によって違いますが、ライブラリの管理によく使われるのが package.json というファイルです。

package.json の dependencies には、アプリで使うライブラリの名前とバージョンが並んでいます。

package.jsonのdependenciesに、アプリで使うライブラリの名前とバージョンが並ぶ画面

さらに pnpm-lock.yaml というファイルでは、package.json のライブラリが依存しているライブラリのバージョンまで管理しています。依存の依存、つまり間接依存のライブラリです。

画面の yargs のように、ライブラリごとに、依存するライブラリとバージョンが並びます。ぼくのアプリでは、pnpm-lock.yaml が7,000行以上あります。

pnpm-lock.yamlで、ライブラリが依存するライブラリのバージョンが並び、行番号が7,000を超えている画面

ライブラリは、間接依存も含めて、新しいバージョンが出たら更新しなければいけません。古いまま使っていると、脆弱性が残ったままアプリを動かし続けることになるからです。

更新を放置するほど、セキュリティのリスクは高まります。

大規模なアプリやGitHub Actionsの自動テストなどを動かしていると、依存ライブラリはほかのファイルにもたくさん定義されます。これらを手作業で更新するのは、数が多すぎて不可能です。

Renovateなら、更新のPRを決まった頻度で自動で作ってくれる

Renovateが週1回PRを自動作成しGitHub Actionsがテストを自動実行し、人は通過を確認してマージするだけの流れ

そこで使うのが、ライブラリを自動で更新するツールのRenovateとDependabotです。

Renovateは、1週間に1回など自分が決めた頻度で、依存ライブラリを更新するPRを自動で作ってくれます。PRとはプルリクエストの略で、コードの変更をアプリに取り込む前に確認するための画面です。

RenovateがPRを自動で作成し、更新するライブラリとバージョンの表と、毎週月曜6時前に作成する設定が書かれたPRの画面

ぼくは毎日PRが作られるのは面倒なので、Renovateが作るPRは週1回にしています。

人がやるのは、PRでGitHub Actionsのテストが通っていることを確かめ、マージするだけです。テストが通っていれば、ライブラリを更新してもアプリが壊れていないと判断できるからです。

PRの「Checks」タブで、ci / test-lintとci / smokeのテストがすべて通過した画面

緊急度の高い脆弱性は、Dependabotですぐに更新する

通常の更新はRenovateで週1回、緊急の脆弱性はDependabotで即時に対応する2段の流れ

ただし、緊急度の高い脆弱性は、週1回の更新を待たずに、すぐに対応しなければいけません。そこで、脆弱性の更新は、Dependabotで即時に行われるよう設定しています。

Renovateは無料、DependabotはGitHubの全プランで無料で使えます。設定方法は、アプリ開発の最初にやるべきセキュリティ設定を解説した記事をご覧ください。

対策5:AIを使う攻撃には、AIによるセキュリティ監査で備える

AIで安く大量に攻撃してくる相手に対し、AIによる監査で弱点を先に見つける対策

最近は情報漏洩が相次いでいて、大きな原因は、攻撃者がAIを使って安く大量に攻撃できるようになったことです。AIを活用した攻撃が前年比89%増えたという調査もあります。

だからこそ、サービスを提供する側も、AIを使って守る必要があります。AIを使ったセキュリティ監査の有名なツールは、次の3つです。

どれもプラグイン・スキル自体は無料で、監査にはClaude CodeやCodexの利用枠を使います。

ぼくは、Cloudflareのセキュリティ監査スキルを使っています。最も網羅的かつ徹底的に、アプリ全体を監査してくれる実感があるからです。

使い方は、Cloudflare公式のセキュリティ監査スキルの使い方を解説した記事をご覧ください。

攻撃者がAIでアプリの弱点をついてくる以上、守る側もAIを使わないと対策は間に合いません。

まとめの前に、お知らせを。

業務のAI活用の個別サポートや、研修・システム開発などのお仕事は、公式LINEからお問い合わせください。相談は無料です。

記事の内容やその他のご質問も、公式LINEで回答しています。

はたらクラフト公式LINELINElin.ee

無料メルマガで実務で使えるAI活用を毎日配信中。1分で登録できます。

超実践AI論Substacktaichiaiworker.substack.com

まとめ:5つのセキュリティ対策で、効率的かつ安全にアプリを運用する

この記事の要点は次の5つです。

  • 権限は、読み書きの許可と範囲の2つの観点で必要最小限に絞る
  • Betterleaksで、Gitに機密情報が入るのを自動で防ぐ
  • AIに機密情報を読ませないようdotenvxや1Passwordで管理し、実行できるコマンドは設定ファイルで縛る
  • 依存ライブラリはRenovateとDependabotで自動更新し、脆弱性を残さない
  • AIによるセキュリティ監査をする。おすすめはCloudflareのセキュリティ監査スキル

ぜひあなたのアプリでも、まだやっていない対策があれば取り入れてください。多少手間はかかりますが、ほとんどの対応はAIに任せれば楽にできます。

この記事をシェア

無料30分相談で、困りごとをお聞かせください

お困りごとや業務内容をうかがい、最も費用対効果が高い解決策をご提案します。事前準備は不要で、オンライン・電話・対面に対応しています。