AIで誰でもアプリが作れる時代の落とし穴 ― 認証情報をソースコードに書いてはいけない理由

はじめに

ChatGPT、Claude Code、Cursor、GitHub Copilotといった生成AIツールの登場によって、プログラミング経験がほとんどない人でもWebサービスやAIエージェントを作れる時代になりました。これは間違いなく良い変化だと思いますが、一方で「動けばいい」を優先するあまり、セキュリティ的に問題となるケースも増えてきています。

2026年5月1日、マネーフォワード社が発表した不正アクセス事案は、流出件数こそ370件と限定的でしたが、認証情報がソースコードに記載されていたことが原因のひとつとされています。これは特定の企業に固有の問題というより、他の企業でも起こりうる問題になります。本記事では、過去の類似事例も交えながら、「ソースコードに認証情報を書く」ことのリスクと、AI時代の開発で押さえておきたい認証情報管理のベストプラクティスを整理します。

2026年5月：マネーフォワード社で起きたこと

公式発表によれば、概要は以下の通りです。

公式発表では、認証情報の無効化、アカウント遮断、ソースコード内の認証キー再発行など、速やかな対応が取られたことが明記されています。誠実な情報開示と迅速な対応は本当に素晴らしいと思います。一方で、本件は「ソースコードに認証情報を記載していた」という、開発現場で最も避けるべきミスが起点になった可能性がございます。

他人事ではないです！ ― 過去のAPIキー流出事例

「ソースコードに認証情報を書く」というミスは、規模を問わず長年にわたって繰り返されてきた問題です。代表的な事例をいくつか紹介します。

事例1：個人開発者が一晩で数十万円〜数百万円の請求

最も身近な事例だと、個人開発者やスタートアップエンジニアがAWSのアクセスキーを誤ってGitHubの公開リポジトリにコミットしてしまうケースです。GitHubは世界中の数千万のリポジトリが集まる場所であり、APIキーやトークンを自動収集するボットが常時稼働しています。AWSのキーが公開されると、早ければ数分以内に検知され、第三者によって仮想通貨マイニングや大量のサーバー起動に使われてしまいます。

結果として、本人が気づくのは翌朝、AWSから「今月の請求額：50万円」のメールが届いて初めて、というケースが繰り返し報告されています。中には数百万円規模の請求が来た事例も少なくありません。

他の例だと最近だとAIのAPIキーの流出が増えています。

事例2：Uber社（2016年）― 5700万人の情報流出と1.48億ドルの和解金

世界的にも有名な事例が、配車サービスUberの情報流出インシデントです。同社のエンジニアが、GitHubの非公開リポジトリ内にAWSの認証情報を含めたコードをコミットしていたところ、攻撃者がそのリポジトリへのアクセスを取得。AWS上のデータベースから約5700万人分の利用者・ドライバー情報が窃取されました。

Uberはこの件を1年以上隠蔽していたことも問題視され、米連邦取引委員会（FTC）等との和解で約1.48億ドル（当時のレートで約160億円）を支払う事態となりました。「非公開リポジトリだから安全」とは言えないことを示す象徴的な事例です。

事例3：GitHub上で毎日数千件規模の認証情報が公開されている

セキュリティ研究者やセキュリティベンダーによる継続的な調査では、GitHub上の公開リポジトリだけで毎日数千件単位の認証情報が新たに公開されているという報告が出ています。中には大手企業やSaaSプロバイダーのアクセスキーが含まれていたケースもあり、この問題は決して個人開発者だけの話ではないことが分かります。

なぜAI時代に「認証情報漏えい」が増えやすいのか

AIアシスタントによって誰でもコードが書ける時代になりましたが、これにはセキュリティ面での負の側面もあります。

1. AIが「動くサンプル」としてハードコーディング例を生成しがち

AIに「APIを呼び出すコードを書いて」と頼むと、サンプルとして apiKey = "abc123..." のような形でAPIキーをコード内に書いた例が出てくることがあります。動作させるための最短距離としては正しいのですが、これをそのまま本番環境で使い続けてしまうケースが増えています。

2. 「動けばいい」マインドの罠

非エンジニア出身の方がAIで開発する際、「とにかくまず動かす」ことを優先しがちです。しかしWebアプリケーションは外部公開された瞬間からセキュリティリスクの対象となるため、初期段階で正しい認証情報管理を導入することが極めて重要です。

3. GitHubへのアップロードが「気軽」になっている

VS CodeやCursorなどのエディタからは、ボタン1つでGitHubにコードをアップロードできます。気軽になった分、「このファイルにAPIキーが入っていないか？」を確認するステップが省略されやすいのです。

そもそもGitHubとは

GitHub（ギットハブ）は、ソースコードを保管・共有・履歴管理するためのインターネット上のサービスです。世界中のソフトウェア開発者が利用しており、日本の主要IT企業はもちろん、官公庁・金融機関でも標準的に使われています。

GitHubには2種類のリポジトリ（コード置き場）があります。

しかし非公開リポジトリであっても、メンバーアカウントの侵害や認証情報の漏えいによって、第三者がアクセスできるようになるケースがあります。Uber事案がまさにこれに該当します。「Privateだから安全」という認識は危険です。

「ソースコードに認証情報を書く」何が問題なのか

ソースコード内に認証情報（APIキー、データベースパスワード、暗号鍵など）を記載する行為は、開発者の間では「ハードコーディング」と呼ばれ、原則として避けるべきとされています。理由は3つあります。

1. ソースコードは多くの目に触れる

GitHubに非公開リポジトリとしてアップロードしていても、メンバー全員、退職者の元アカウント、外部委託先、CI/CDサービスなど多数の経路からアクセスされます。一箇所でも侵害されると、すべての認証情報が第三者の手に渡ります。

2. Gitの履歴は「永久」に残る

Gitは変更履歴を記録する仕組みです。一度コミット（保存）した認証情報は、後から削除しても履歴を辿れば復元できてしまいます。流出に気づいてから慌てて削除しても、すでに見られた可能性は消えません。

3. ローテーション（定期更新）が困難

認証情報をコードに直書きすると、更新のたびにコード変更・デプロイが必要になります。結果として「とりあえず動いているから触らない」運用になりがちで、長期間同じ鍵が使われ続けるリスクが高まります。

正しい認証情報管理の方法

現代のWeb開発では、以下のような階層構造で認証情報を分離するのが標準です。

① ローカル開発環境

.env ファイル（環境変数を記載するテキストファイル）に書き、これを .gitignore に登録してGitHubにアップロードしないようにします。

② ステージング・本番環境

クラウドサービスの「シークレットマネージャー」を利用します。代表例は以下の通りです。

これらは認証情報を暗号化して保管し、必要なシステムに実行時にだけ読み込ませる仕組みです。アクセスログも残るため、誰がいつ参照したかを追跡できます。

③ ソースコードからの参照方法

ソースコードからは、環境変数経由で読み込みます。鍵そのものはコードに含まれません。

うっかり混入してしまったら？

人間が運用する以上、ミスはゼロにできません。検知・防止のための仕組みが用意されています。

GitHub Secret Scanning（無料）

GitHubには、コミットされたコードにAPIキーやトークンらしき文字列が含まれていた場合、自動で検知してアラートを出す機能が標準搭載されています。多くのプランで無料で有効化できるため、利用していない場合は今すぐ有効化することを推奨します。

プッシュ前の自動検査

gitleaks や trufflehog といったオープンソースツールを、pre-commitフック（コミット前に自動実行される仕組み）に組み込むことで、認証情報がGitに記録される前段階でブロックできます。　他にもCodexやClaude Codeにルールを書いておき、push前にチェックするようにする方法も入れるとさらに安全です。

もし漏えいが疑われたら

最も重要なのは、該当する認証情報を速やかに無効化（ローテーション）することです。コードの履歴から削除するよりも、漏れた可能性のある鍵を使えなくする方が優先です。マネーフォワード社の発表でも「認証情報の無効化、アカウント遮断、再発行」が対応として挙げられており、これは適切な対応です。

中小企業が今日からできる3ステップ

社内でWebシステムやSaaS連携の開発を行う、あるいは検討している企業がすぐに着手できることを3つに整理します。

ステップ1：.env と .gitignore の運用を徹底

新規プロジェクトを作る際、最初に .gitignore に .env を登録するルールを徹底します。テンプレートを社内で共有しておくと再発防止に有効です。ただ、Claude Codeなどを使っている場合は、.envに書くことも避けると良いです。

ステップ2：GitHub Secret Scanningを有効化など対策を

組織アカウントの設定画面で、Secret Scanningを全リポジトリ対象に有効化します。基本的に無料です。AIを使っていればCodexやClaude Codeにルールを書いておき、push前にチェックするようにする方法も入れるとさらに安全です。

ステップ3：本番環境の認証情報を見直す

過去に作ったリポジトリの中に認証情報が残っていないかを点検し、もし発見した場合は該当鍵を無効化した上で、シークレットマネージャー等への移行を検討します。Git履歴から削除する作業よりも、鍵の無効化が優先です。

おわりに

AIによって誰でもアプリ開発ができる時代になったことは、間違いなくポジティブな変化です。一方で、開発の入り口に立つ人が増えるほど、これまで「言われなくても身につけていた最低限のルール」が抜け落ちるケースが目立つようになっています。

ソースコードに認証情報を書かないこと、.gitignore を最初に設定すること。これらは技術的に難しい話ではなく、最初の一歩を踏み出すときに「知っているかどうか」だけの問題です。

本記事が、AI時代に新しく開発に取り組まれる方々や、社内でAIアプリ開発を進めようとしている経営者・IT責任者の方々のお役に立てば幸いです。

公式情報については、必ずマネーフォワード社の公式リリースをご確認ください。