宮崎翼 
開発スピードの裏に潜む、セキュリティの落とし穴と今すぐできる対策
ビジネスの世界では今、開発スピードがこれまで以上に重要になっていますよね。
AIによるコーディング支援や、サッとアプリを作れる「バイブコーディング」は、もはやビジネスの強力な武器です。
でも、ちょっと待ってください。 そのスピードと引き換えに、会社の「信頼」を失うリスクが高まっているとしたら…？
最近、ある著名なエンジニアの方が警鐘を鳴らした事例があります。
数ヶ月で5件、延べ1万件近い個人情報漏洩を発見/報告
海外のアプリで、59.3 GBのユーザーの写真が自由に抜き取れる状態になっているとの報告
AIがタスク達成を優先してセキュリティを無視してしまったり、開発者のちょっとした知識不足が致命的な穴になってしまったり…。これ、実は開発の現場では「いつ起きてもおかしくない」問題なんです。
この記事では、開発に携わるすべての方が知っておくべき
「新しい時代のセキュリティ」について、私たちと一緒に考えていきたいと思います。
心構え：AIはあくまで「副操縦士」。責任の所在を曖昧にしない
AIがコードを書いてくれる。本当に便利な時代になりました。
その便利さから「AIが書いたから大丈夫」「ツールが全部やってくれる」なんて、無意識に責任を曖昧にしてしまっていませんか？
ここで一つ、大事な心構えをお伝えさせてください。
AIはあくまで優秀な「副操縦士」です。最終的にサービスの安全を担保し、その全責任を負うのは、コックピットに座る人間――すなわち「開発責任者」であり、その体制を築く「経営者」のあなたです。
この大原則を、チームの共通認識にすることから始めましょう。
あなたのアプリは大丈夫？見落とされがちな「DB設定」のワナ
今回、問題が表面化したきっかけは、Supabaseというデータベースサービスを利用しているAI開発者側の設定不備でした。
「Row Level Security (RLS)って何？」と思いますよね。 すごく簡単に言うと、「このデータは、この人に見せてOK」と一行ずつ設定できる、とても大事なセキュリティ機能です。ところが、この機能がデフォルトで「オフ」になっていることが多く、データベースが誰でも入れてしまう「鍵のかかっていない部屋」のような状態になっていたのです。
これはSupabaseだけの話ではありません。人気のFirebaseにも独自のセキュリティルールがあります。
大切なのは、どちらが良い・悪いではなく、それぞれのツールの特性をきちんと理解し、適切に「鍵をかける」作業を人間が行うこと。
AIに丸投げしてはいけない、まさにプロの腕の見せ所です。
比べてみよう：Supabase vs Firebase
| 項目 | Supabase | Firebase (Google) |
| データベース | PostgreSQL (SQL) | Cloud Firestore, Realtime Database (NoSQL) |
| 思想/アプローチ | オープンソースの組み合わせ | Google Cloud Platformとの統合 |
| セキュリティモデル | Row Level Security (RLS) をSQLで記述 | 独自のセキュリティルールをJSONライクな構文で記述 |
| データ構造 | リレーショナル（テーブル構造） | ドキュメント/JSON形式（柔軟） |
| クエリの複雑性 | SQLが使えるため複雑な検索や集計が得意 | 単純な読み書きに強いが、複雑な検索は苦手 |
| ホスティング | 公式クラウド or 自己ホスティング（セルフホスト）可能 | Google Cloud Platform上でのみ利用可能 |
| 学習コスト | SQL経験者にとっては学習コストが低い | 独自のルールやNoSQLの概念を学ぶ必要がある |
じゃあ、明日から何をすればいいの？具体的な3つのアクションプラン
経営者が今すぐ実行すべき、3つの具体的なアクション
では、具体的に何をすべきか。AppTalentHubは、以下の3つのアクションを強く推奨します。
1. 【人と組織の意識改革】「セキュリティは全員の仕事」という文化を醸成する
- 専門書籍による知識の標準化: 京平氏も推奨する**『安全なウェブアプリケーションの作り方』（通称：徳丸本）**を、開発に携わる全従業員の必読書としましょう。エンジニアだけでなく、企画担当者やディレクターも学ぶことで、組織全体のセキュリティリテラシーが向上します。
- 定期的な実践的トレーニングの実施: AI生成コード特有のリスクや、最新の攻撃手法をテーマにした研修を定期的に開催しましょう。外部の専門家を招聘し、自社のプロダクトに対する擬似的なハッキング（ペネトレーションテスト）を体験することも非常に有効です。
2. 【開発プロセスの刷新】信頼できるツールを「正しく」使う
- AIが書いたコードは「レビュー必須」を徹底する： AIは驚くほど優秀なアシスタントですが、時にセキュリティの観点が抜け落ちたコードを生成することがあります。「AIが書いたから大丈夫」は禁物。必ず人間の専門家がチェックするプロセスをルール化しましょう。
今回の脆弱性を報告したエンジニアが、Supabase RLS Checkerの一般公開を考え中のようです。 - 信頼できるツールを「正しく」使うことを意識する： これは、自前で全てを開発しない、という発想です。 例えば、BubbleやFlutterFlowといったノーコードツール。これらはセキュリティ基準も高く、マニュアルも完備されているため、きちんとマニュアルに沿って構築している限り、開発初期のサービスにおいては一定のセキュリティレベルが担保されます。もちろん、これは「完全」を意味するものではありません。サービスが大きくなるフェーズでは、改めて専門家によるレビューを入れることを計画しておきましょう。そして、免許証やクレジットカード情報といった最高レベルの機密情報は、最初からStripeのような専門サービスに任せるのが鉄則です。「餅は餅屋」の考え方で、信頼できる外部サービスを正しく組み合わせて使う。これも立派なセキュリティ戦略の一つです。
- 参考リンク（決済代行サービス例）:
3. 【データ管理の再定義】「もしも」に備えた設計を徹底する
- 情報の「置き場所」を分ける： すべての情報を同じ金庫に入れてはいけません。万が一、一つのサーバーが攻撃されても被害が最小限で済むように、データの機密レベルに応じて「置き場所」をきちんと分ける設計を心がけましょう。
最後に。セキュリティは「信頼」への投資です
セキュリティ対策って、売上に直接つながらないので、どうしても後回しにされがちですよね。
でも、考えてみてください。その対策は、お客様からの「信頼」や、これまで築き上げてきた「ブランド」を守るための、何よりも重要な**「未来への投資」**です。この投資を惜しんだばかりに、ある日突然すべてを失ってしまう。そんな事態だけは、絶対に避けたいはずです。
AI時代の真の競争力は、開発スピードと、それを支える「安全性」という両輪があってこそ生まれます。
私たちAppTalentHubは、皆さんがこの変化の時代を安心して駆け抜けられるよう、これからも情報提供を続けていきます。もし、セキュリティに強い開発チームづくりや、信頼できる専門家探しでお困りのことがあれば、いつでも気軽に声をかけてくださいね。
