バイブコーディングのセキュリティリスクが、他人事ではなかった
実機作業はなし。GMO Flatt SecurityのCTOが解説したAIエージェントのセキュリティリスクに関する動画を見ていたら、自分の環境がそのままリスク事例として当てはまっていた。コスト0・30分以内で打てる対策を全部打った。
動画を見たら、全部自分ごとだった
—— 「バイブコーディングのリスク」は、どの程度リアルな話か？
GMO Flatt SecurityのCTOである米内貴志氏による動画を見た。テーマはAIエージェントを業務に使う際のセキュリティリスクだ。
動画が指摘したリスクを3つに整理すると：
1. 普段使い端末でエージェントを動かしている 自分のPCで直接Claude Codeを実行することは、重要な認証情報が置かれた環境と、インターネットに接続されたエージェントを直結させることと同じだ。不審なファイルを無作為にクリックするリスクと構造的に変わらない。
2. SaaSへの過剰権限付与 AIエージェントにクラウドサービスの強力な権限をそのまま渡すと、エージェントが意図せずデータを削除したり、外部にアクセス可能な状態にしてしまうリスクがある。
3. 隔離環境の欠如 エージェントが自動的にパッケージをダウンロードする際、攻撃者が仕掛けたマルウェアを取り込んでしまうケースが急増している。端末内のAPIキーや認証トークンが窃取される入口になる。
3つとも、今の自分の環境に当てはまっていた。
Mac miniを買えばいいのか？——違う
—— 「普段使い端末でエージェントを動かしている」を解決するには、別マシンを買うのが正解か？
動画では「AIエージェント専用のMac miniを用意する」という物理分離のアプローチが紹介されていた。正解の一つではある。ただし、今の自分のフェーズでは、それは最初の一手ではないという結論になった。
理由はシンプルだ。ハードウェアを変えても、設定を間違えれば同じリスクが移動するだけだ。 プロセスの設計が先で、ハードウェアは後だ。
物理分離が本当に必要になるのはこういうタイミングだ——クライアントの機密データを扱う案件が増えた時、外部から資金を受けた時、会社という組織に入って会社資産への責任が発生した時。今のフェーズ（ソロ・自社サービス中心）では、ソフトウェアとプロセスの改善で対応できる。
CLAUDE.mdが「ガイドライン」にすぎなかった
—— 権限設計はどこに書けば実際に機能するのか？
Claude Codeのプロジェクトには2つのファイルが存在する。
CLAUDE.md— エージェントへの指示書。人間が読むガイドライン。settings.local.json— 実際の権限制御ファイル。こちらが実行を管理する。
自分のCLAUDE.mdには「freee APIへの書き込みは実行前にユーザー承認を得ること」と書いていた。が、settings.local.jsonを確認したら、書き込み系のAPIが全部「自動実行OK」のリストに含まれていた。
CLAUDE.mdをどれだけ丁寧に書いても、settings.local.jsonが「全部OK」では意味がない。 実際の制御はsettings.local.jsonが担っている。
コスト0・30分でできた対応
—— 今すぐ打てる対策は何か？
やったことを順番に書く。
① CLAUDE.mdのPermissions設計
まず読み物としてのCLAUDE.mdを、権限の考え方で3層に整理した。
承認不要：読み取り系のAPI操作（データを取得するだけで変更しないもの）
要確認：書き込み・作成・削除系（実行前に内容を提示して承認を得る）
禁止：環境変数ファイルの内容出力、外部パッケージの無断インストール、対象外APIへのリクエスト
② settings.local.jsonの修正
CLAUDE.mdで「要確認」にしたはずの書き込み・削除系APIが、settings.local.jsonの自動実行リストに含まれていた。この2項目を削除した。これで書き込み操作はエージェントが実行前に確認を求めるようになる。
③ git init + .gitignore
adaptdesign-osディレクトリがGit未管理だった。今すぐgit initして、環境変数ファイルをgitignoreに登録した。これで「何が変更されたか」が追跡できるようになる。ログの代わりになる最低限の保険だ。
④ zsh履歴のタイムスタンプ設定
ターミナルのコマンド履歴にタイムスタンプを記録するよう設定した。コマンドの出力結果まではカバーできないが、「いつ何をしたか」の痕跡が残るようになった。
セキュリティは「あとからお金で解決できない」領域
R2R2Rの設計哲学に「精度より体験の成立を優先する。精度はあとからお金で解決できる」という言葉がある。
セキュリティはこの逆だ。事故が起きてから対処しようとしても、漏洩したデータは戻らない。freeeの経理データに何かあれば、それは過去の帳簿すべてに影響する。信頼の問題になった時点で、お金では取り戻せないものがある。
動画のメッセージはこうだった——「セキュリティを『足かせ』ではなく、安心してAIを使い倒すための『攻めの投資』として捉えること」。
速さと安全は両立できる。ただしプロセス設計が必要だ、ということだ。今日やった対応はどれも開発速度を下げない。書き込み操作の前に確認が入るだけだ。むしろエージェントが何をしているかが可視化されることで、信頼してタスクを渡せるようになる。
コスト0。所要時間30分以内。できる対応は全部打った。
