Mt. Goxという名前を聞いたことがあるエンジニアは多いと思います。2014年に破綻した世界最大のビットコイン取引所で、流通量の70〜80%を扱っていたにもかかわらず、内部のホットウォレット管理の甘さとトランザクション展性（Transaction Malleability、取引IDを第三者が署名データの差し替えで改ざんできる仕組み）を突かれ、数十万BTCを失いました。
この事件は暗号資産業界の話ですが、AIコーディングツールやMCP（Model Context Protocol、AIエージェントが外部ツールやAPIを呼び出すための標準規格）を日常的に使っている開発者にとっても、構造的に似た落とし穴があります。本記事はAIエージェントにAPIキーやクラウド権限を渡して自動化を進めているエンジニア向けに、Mt. Goxの教訓を開発現場の文脈に置き換えて整理したものです。
何が起きるか：ホットウォレット的な権限管理のAI版
Mt. Goxの致命的な問題は、資産の大部分をインターネットに常時接続した「ホットウォレット」に置いていたことでした。本来は大部分を「コールドストレージ」（オフラインの保管）に退避させるのがベストプラクティスでしたが、それが徹底されていませんでした。
AIエージェント開発でこれに相当するのは、Claude CodeやCursor、あるいはMCPサーバー経由でAIに渡す認証情報の扱いです。本番環境のAPIキーやクラウドのフルアクセス権限を、そのままAIエージェントの実行コンテキストに置いてしまうケースがあります。
AIエージェントは与えられた権限の範囲内で、人間の承認を待たずに連続してコマンドを実行できます。権限が広すぎると、意図しないリソースの削除やデータの外部送信、誤った本番デプロイが一瞬で連鎖する可能性があります。これはMt. Goxのホットウォレットが常時オンラインだったことで攻撃対象になり続けたのと同じ構図です。
なぜ起きるか：原因を段階的に分解する
1. 利便性を優先した権限設計
AIエージェントに毎回スコープの狭いトークンを発行し直すのは手間がかかります。結果として、開発者は一度だけ広い権限のキーを.envファイルやMCPサーバーの設定に書いて使い回しがちです。
2. 監査ログと内部統制の欠如
Mt. Goxではずさんな会計処理と不透明な内部統制が、資産流出に数年気づけなかった遠因とされています。AI開発でも、エージェントがどのコマンドを実行し、どのファイルを変更したかのログを残していないプロジェクトでは、異常な挙動の発見が遅れます。
3. 生成コードのレビュー省略
AIが自動生成したコードやシェルスクリプトを、人間がレビューせずにそのまま実行してしまう運用もリスクの温床です。悪意ある外部入力やハルシネーション（AIが事実と異なる内容を生成する現象）によって、意図しないコマンドが紛れ込む可能性があります。
自分のプロジェクトが該当するか確認する方法
以下の観点で、現在使っているAIコーディングツールやMCP構成を見直せます。
.envや設定ファイルに本番用のAPIキーがそのまま書かれていないか、git log -p -- .envなどで過去のコミット履歴も含めて確認する- MCPサーバーの設定ファイル（例:
claude_desktop_config.jsonや各ツールのMCP設定）で、付与しているスコープが読み取り専用か書き込み可能かを確認する - クラウド側（AWS IAM、GCPのサービスアカウントなど）で、AIエージェント用に発行したクレデンシャルの権限ポリシーを一覧し、不要な
*（ワイルドカード）権限がないか洗い出す - CI/CDパイプラインでAIエージェントが実行したコマンドのログが残る設定になっているか確認する
# gitの履歴に過去コミットされた秘密情報が残っていないか検査する例
git log -p --all | grep -iE "api[_-]?key|secret|token" | head -n 20該当するキーワードがヒットした場合、過去のコミット履歴からシークレットを除去する作業（git filter-repoなどのツール利用）と、該当キーの失効・再発行が必要です。
対策の手順
ステップ1: 権限を最小化する
AIエージェントに渡す認証情報は、作業に必要な最小限のスコープに絞ります。たとえばGitHubのPersonal Access Tokenであれば、リポジトリ単位・読み取り専用のfine-grained tokenを発行し、書き込みが必要な操作だけ別途承認フローを挟む構成が現実的です。
ステップ2: 短命トークンへの切り替え
可能であれば、長期間有効なキーではなく、数時間〜数日で失効する短命トークンを使います。AWSであればSTS（Security Token Service）の一時認証情報、GCPであれば短命のOAuthトークンが該当します。
ステップ3: 実行前承認モードの活用
Claude CodeやCursorなどのツールには、ファイル変更やシェルコマンド実行の前に人間の承認を求めるモードがあります。本番に影響する操作だけでも、自動承認ではなく手動確認を挟む設定に切り替える価値があります。
ステップ4: 実行ログの記録と定期レビュー
AIエージェントが実行したコマンド履歴をファイルやログ基盤に残し、週次・月次で異常な操作がないか棚卸しします。Mt. Goxの教訓は「気づいた時には手遅れ」という点にあり、検知の仕組みを先回りで作ることが被害の最小化につながります。
ステップ5: 生成コードのレビュー徹底
AIが生成したスクリプトやインフラ変更（Terraformのコードなど）は、特にapplyやdeleteを伴う操作の前に必ず人間がdiffを確認します。レビューを飛ばす運用は、ホットウォレットを無防備に公開しているのと同じリスク構造です。
確認しておきたいポイント
Mt. Goxの破綻は、単一の脆弱性ではなく権限管理の甘さと内部統制の欠如が積み重なった結果でした。AIエージェントの運用でも同じ構図が起こり得ます。
- AIエージェントに渡しているAPIキーやクラウド権限のスコープを今すぐ一覧化してみること
- 長期間有効な広範囲キーを、短命かつ最小スコープのトークンに置き換えられないか検討すること
- 本番影響のある操作には、AIの自動実行ではなく人間の承認ステップを挟むこと
これらは一度設定すれば終わりではなく、プロジェクトの成長に合わせて定期的に棚卸しする運用が欠かせません。