AIエージェントに開発環境を触らせるようになってから、「このキー、まだ生きてたのか」と気づく回数が明らかに増えました。
エージェントに何かをやらせるたびに、OAuth連携を増やし、APIキーを発行し、サービスアカウントに権限を足す。ひとつひとつはその瞬間に必要な作業なんですが、必要でなくなったタイミングで権限が自動的に消えることはありません。理由が消えても権限は残る。この非対称性が、そのまま放置リスクになります。
この記事では、私が定期的にやっている権限・認証情報の棚卸し手順をチェックリストとしてまとめます。特別なツールは使わず、設定画面とターミナルだけでできる範囲の話です。
1. 「前に確認したから大丈夫」を根拠にしない
棚卸しでいちばん事故りやすいのが、記憶を根拠にすることです。
「先月見たときはこの権限だけだったはず」は、その時点では正しくても今も正しいとは限りません。設定は、他のツールとの連携、サービス側の仕様変更、自分以外の操作によって静かに変わります。特にクラウドのIAMまわりは、あるロールを付けた副作用で別の権限が芋づるで付いてくることがあり、記憶と実態がずれやすい。
- 権限一覧は必ずその場で今の画面（またはAPI）を開いて確認する。前回のスクショやメモで済ませない
- 「たしかこうだった」という言葉が自分の口から出たら、それが確認すべきサイン
- 確認した日付をどこかに残し、次回「前回いつ何を見たか」を辿れるようにする
GCPなら現況の取得はコマンドで済みます。
# プロジェクトのIAMバインディングを一覧
gcloud projects get-iam-policy "$PROJECT_ID" --format=json
# サービスアカウントに紐づく鍵の一覧（発行日が見える）
gcloud iam service-accounts keys list --iam-account="$SA_EMAIL"
画面をスクロールして目視するより、こうしてテキストに落として差分を取るほうが確実です。前回の出力をファイルに残しておけば、次回は diff するだけで済みます。
2. 権限を洗い出し、「今使っている機能」と突き合わせる
次にやるのは、付与済みの権限を全部並べて、それぞれが今も実際に使われている機能に対応しているかを1件ずつ確認する作業です。
- 連携中のアプリ・APIキー・アクセストークンを一覧化する（「連携済みアプリ」「認証済みデバイス」といった項目を全部開く）
- 各権限について「これは今どの処理で使っているか」を具体的に答えられるか自問する
- 答えられない／「昔は使っていた」ものは、削除・縮小の候補としてリストに残す
ここで見るべきは有無だけではなく範囲です。読み取りだけで足りるのに書き込みや削除まで許可されている、というケースは驚くほどよくあります。連携そのものが必要かどうかと、その連携に与えている権限の広さが妥当かどうかは、別の問いとして扱ってください。
3. 同じ権限を複数の経路で持っていないか
棚卸しで最も見落としやすいのが、同じ実効権限を複数の経路から重複して持っているケースです。
- 直接付与したロール
- グループ／継承（組織 → フォルダ → プロジェクト）経由で降ってきている権限
- 別ツールとの連携が内部で持っているトークン
- 昔の仕組みから引き継がれ、そのまま残っている設定
プロジェクトレベルのバインディングだけを剥がして安心したのに、組織レベルの継承がまだ生きていた——というのは、実際に踏むまでなかなか想像できません。
- 「この権限を消せば安全」と結論する前に、同じ効果を持つ別経路がないか横断的に確認する
- 直接の設定画面だけでなく、連携先ツールの管理画面・引き継ぎ元のアカウント設定もあわせて見る
- 1経路を取り消したら、別経路から実際にアクセスできなくなったかを確認する
権限は「点」ではなく「経路の集合」として扱う、という意識が要ります。
4. 使っていない古いAPIキー・トークンを整理する
権限とセットで見るべきなのが、認証情報そのものです。古いキーやトークンは、その機能を使わなくなった後も有効なまま残りがちです。
- 発行済みのキー・トークンを一覧化し、発行目的と最終利用日（分かる範囲で）を確認する
- 「今は使っていない」ものは、必要性を再確認したうえで無効化・削除する
- 用途が思い出せないキーは、安全側に倒して無効化を検討する。残すメリットより漏えい時のリスクのほうが大きい
- 新しいキーを発行するときは、古いキーの無効化とセットで行う習慣をつける
使われていない認証情報は、何の仕事もしないまま「もし漏れたら」というリスクだけを静かに抱え続けます。使っていないなら、存在しないほうが安全です。
リポジトリ側の混入チェックも一緒にやっておくと安心できます。
# 追跡対象ファイルに鍵ファイルが紛れ込んでいないか
git ls-files | grep -Ei '\.(pem|key|p12)$|credentials|secret'
# 過去のコミットに含まれていないか（履歴も見る）
git log --all --diff-filter=A --name-only --pretty=format: | sort -u | grep -Ei 'credentials|secret|\.key$'
.gitignore に書いてあるから大丈夫、と思っていたファイルが、.gitignore を書く前のコミットに残っていることがあります。
5. 変更したら、反映されたかを後で必ず確認する
権限を取り消した・縮小した・キーを無効化した。その直後は「操作した」というログだけで安心しがちですが、それが意図通り効いているかは別途確認が必要です。
- 設定変更の反映には時間がかかることがある。すぐ見て「まだ古いまま」と誤判定し、二重に変更してしまわないよう、時間を置いてから再確認する
- 連携先やクライアント側にキャッシュが残り、しばらく古い権限のまま動き続けることがある
- 実際にその機能を叩いてみて、想定通り失敗する（または制限された範囲でしか動かない） ことを確認する
- 「変更した」ログと「反映を確認した」ログは別物として、両方残す
たとえば鍵を消したのなら、その鍵で認証が通らなくなったことまで見て初めて確認完了です。
gcloud auth activate-service-account --key-file=./old-key.json
# ↑ これだけでは検証にならない。鍵JSONをローカルで読んで保存するだけなので、
# すでに削除・失効した鍵でも成功する。実際にトークン発行まで試して初めて確認できる
gcloud auth print-access-token # 失効済みならここでエラーになる
「設定を変えたこと」と「その設定が効いていること」の間には、思ったより距離があります。ここを省くと、変更したつもりで何も変わっていない状態に気づけません。
6. 頻度を決めて習慣化する
ここまでの手順は、思い立ったときにやるだけでは続きません。権限は日々少しずつ増えるものなので、棚卸しも間隔を決めて回す前提で組む必要があります。
- 頻度を先に決める（月1回、四半期に1回など、扱う権限の重要度に応じて調整）
- カレンダーやタスク管理に組み込み、「気が向いたら」ではなく「決まったタイミングで必ず」実施されるようにする
- 毎回同じ順番で回す（洗い出し → 突き合わせ → 重複経路 → 古い認証情報 → 反映確認）
- 気づいたことを毎回1〜2行でいいので記録しておく。次回「前回どうだったか」を探す手間が消える
前述の gcloud ... --format=json の出力を日付付きでコミットしておくと、棚卸しが「読む作業」から「差分を見る作業」に変わって、かなり軽くなります。
まとめ
| チェック項目 | やること |
|---|---|
| 記憶に頼らない | 前回の記憶ではなく、その都度いまの設定を取得して確認する |
| 洗い出しと突き合わせ | 付与済み権限を一覧化し、実際に使っている機能と1件ずつ照合する |
| 重複経路の確認 | 直接付与・継承・連携経由などで同じ権限を重複して持っていないか見る |
| 古い認証情報の整理 | 使っていないAPIキー・トークンは残さず無効化・削除する |
| 反映確認 | 変更ログで満足せず、時間を置いて実際に効いているか確かめる |
| 頻度を決めて習慣化 | 気づいたときではなく、決めた間隔で定期的に回す |
権限まわりは、一度整えたら終わりではなく、放っておけば必ず実態とずれていく類の設定です。定期的に見直すこと自体を作業の一部として組み込んでおくと、大きな問題になる前の小さな違和感の段階で手を打てます。