個人開発者のためのAI活用セキュリティ設計：3層構造でリスクを低減

AI時代のサイバー攻撃と個人開発者の課題

AI技術の普及により、サイバー攻撃の手法が変化しています。攻撃コードの生成や標的の調査、フィッシングメール作成などがAIによって低コスト化され、攻撃の質が向上しています。一方で、NoCodeツールやAIアシスタントの普及により、非エンジニアでも個人でサービスをリリースできるようになり、個人開発者の裾野が広がっています。技術的なバックグラウンドが少ない開発者はセキュリティ対策が後手に回りやすく、攻撃者にとっては格好の標的となり得ます。「自分は個人開発者だから小さい」という考えは通用しなくなってきています。

個人開発におけるセキュリティの難しさ

チーム開発には、プルリクエストによるコードレビューやCIによる自動チェックといったセーフティネットが存在します。しかし、個人開発ではコード作成からレビュー、デプロイまで全てを一人で行う必要があります。ユーザーのメールアドレスなどの個人情報を扱うサービスの場合、退会フローや認可ロジックの不備が情報漏洩につながる可能性があります。「完璧なセキュリティを実現してからリリースする」という考え方は現実的ではなく、セキュリティに完璧な到達点はないため、ゼロリスクを目指すと永遠にリリースできなくなります。そのため、「構造で守る」という方針が採られています。人間の注意力に頼るのではなく、仕組みとして自動的に防ぐ層を積み重ね、想定したリスクに対して明示的に対処した状態でリリースする基準が設けられています。

SaaSを活用したリスク分散と入口のガード

認証には特定のSaaS、データベースには別のSaaS、決済にはさらに別のSaaSを利用することで、セキュリティの責任を信頼できる外部サービスに分散させています。これにより、パスワードのハッシュ化やセッション管理、カード情報の保持、データベースの暗号化といった領域のリスクを低減できます。これらの機能を自前で実装すると、ミスが入り込む余地が増えるためです。ただし、SaaSに委譲できるのはそのサービスが提供する範囲内に限られます。自身のコードがサービスの「入口」となるため、Convexの関数における認可チェック、Webhookの検証、ユーザー退会時のデータ削除フローの実装などは自身で行う必要があります。SaaSを利用してリスクを分散しつつ、自身が書くコード、すなわち「入口」は自身でガードするという方針が基本となります。

セキュリティを確保する3層構造

第1層：機械的に防ぐ（hooksによる自動ガード）

最初に整備されたのは、「考えなくても守られる層」です。特定のツールにおけるhooksは、ツール実行の前後にシェルスクリプトを自動実行できる仕組みです。これにより、エージェントによる操作も人間による操作も同じルールでガードできます。

• シークレットの誤コミット防止: git commit の直前にステージされた差分をスキャンし、AWSアクセスキー、AnthropicのAPIキー、Stripeのキー、ConvexのDeployキー、GitHubトークンなど25種以上のシークレットパターンを検出した場合、コミットをブロックします。Python3が見つからない場合もコミットをブロックするfail-secure設計です。
• 環境変数の不正読み取り防止: Bash経由での `.env` ファイルの読み取りをブロックします。`settings.json` の deny ルールだけでは防げない迂回パターン（例: `source .env`、`head .env`）も検出対象に含まれます。
• 依存パッケージの脆弱性監査: `pnpm add` を実行するたびに `pnpm audit` を自動実行します。クリティカルな脆弱性が検出された場合はその場でブロックし、ロールバックコマンドを提示します。

これらのhooksはローカル環境でのみ機能します。ターミナル履歴やLLMへのコード貼り付けなど、hooks以外の経路からのシークレット漏洩には別途注意が必要です。

第2層：AIでレビューする（/security-review）

機械的な防御で既知の脆弱性を塞いだ後は、コードそのものをレビューする層です。特定のAIツールには `/security-review` という組み込みコマンドがあり、セキュリティ監査エージェントが現在のブランチの変更に対してセキュリティ観点のレビューを行います。レビュー範囲はOWASP Top 10やCWEに基づく脆弱性分類、依存パッケージの既知CVE、インジェクション、認証、アクセス制御、機密データ露出、XSSなど多岐にわたります。指摘はCWE番号、深刻度、対象ファイル、攻撃シナリオ、修正方針の形式で返されます。実装完了時や本番デプロイ前に手動で実行することで、自身では気づかなかった脆弱性を指摘してもらうことが可能です。ただし、「指摘がなかった＝安全」とは限らず、検出器の感度の範囲外の脆弱性が残っている可能性はあります。また、LLMの非決定性により、同じコードに対して複数回実行した場合に指摘内容が変わることがあり、結果の信頼性には注意が必要です。

第3層：AIを信じすぎない工夫（AI敵対的レビュー）

LLMの非決定性や、自身が知らないリスクをAIに聞けないという不安から、複数回実行とAI敵対的レビューの組み合わせが考えられています。

• 複数回実行とトリアージ: `/security-review` を複数回実行し、全ての指摘を収集します。指摘の頻度は優先度のヒントとして利用され、3回全てで指摘された内容は優先度が高く扱われます。1回だけ出た内容も必ず目を通して誤検知か否かを判断します。
• AI敵対的レビュー（構想段階）: 別のAIエージェントを「攻撃者」として用い、コードを攻撃者の視点でレビューさせるアプローチが構想されています。これにより、防御側の視点に偏りがちな開発に、攻撃者視点を強制的に取り入れることができます。これは本格的なペネトレーションテストの代替にはなりませんが、自身のコードレビューに限定して利用することが想定されています。

AI敵対的レビューはまだ構想段階であり、実際の効果は検証されていませんが、一人開発における視点の偏りを補うものとして期待されています。

まとめ

「完璧なセキュリティ」は個人開発者にとって現実的な目標ではありません。セキュリティに終点はないため、現実的な落としどころとして3層構造が採用されています。hooksによる機械的な自動ブロック、AIレビューによるコード起点の脆弱性補完、そしてAI敵対的レビューによる攻撃者視点の強制導入です。各層には限界がありますが、「何もしない」よりは確実にリスクを減らすことができます。セキュリティは設計に組み込むものであり、個人開発者だからこそ、一つ一つの仕組みを自身で理解しながら積み上げていくことが重要です。

出典: https://zenn.dev/yt8220/articles/ca06ae47d99903