クラウドのIAMユーザーのアクセスキーの最終利用日を毎週取得し、長く使われていないキーの持ち主に確認を送って、無効化の候補をまとめる

処理の起点を決める

毎週月曜の朝8時に、Schedule Trigger で動かします。 Schedule Trigger はワークフローのタイムゾーンを使い、無ければインスタンスのタイムゾーンを使います。セルフホストの既定は America/New York なので、ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動きません。

月1回ではなく週1回にしているのは、確認の追いかけのためです。 新しく90日を超えるキーは月に数十本でも、返事の無い確認を1週間で拾い直せば、聞く相手の変更が月をまたがずに済みます。 週ごとに、新しく拾ったキーへの確認と、期限の過ぎた確認の催促を同じ実行で行います。

持ち主の回答は、確認を送った別の実行が受け取ります。月曜の実行は送るところまでで終わり、回答は届いた時点で記録に書かれます。

入力データを集める

質を決めるのは、タグと社員名簿です。 タグが無ければ、エージェントはユーザー名と使われ方から推し量るしかなく、推し量った持ち主に確認を送ることになります。 推し量りで送った確認は、相手に「心当たりが無い」と返されて1週間を失います。

認証情報レポートには、アクセスキーIDが載りません。 載るのは1本目・2本目という番号と状態だけです。無効化には ID が要るので、候補になったユーザーについて別にキーの一覧を取ります。

データの取得方法を決める

レポートは、作成の依頼と取得の2回に分けて呼びます。 HTTP Request ノードで、IAMのAPIの GenerateCredentialReport を呼んだあと、GetCredentialReport で取ります。レポートは4時間に1回まで作られ、4時間以内に作られたものがあれば、それが返ります。 週1回の実行なら、毎回新しいレポートになります。

取得したときにまだ作成中なら、ReportInProgress が返ります。 Wait ノードで数十秒待ってから取り直し、3回続けば「取得できず」として記録します。レポートが古くなっていれば ReportExpired、無ければ ReportNotPresent が返るので、どちらも作成の依頼からやり直します。

返ってくるレポートは Base64 で符号化されたCSVです。 IAMのAPIの応答はXMLなので、XML ノードで JSON にし、Content を Convert to File の Move Base64 String to File でCSVのファイルにして、Extract From File の Extract From CSV で行に分けます。1行が1ユーザーで、2本のキーが同じ行に並びます。 ここでキーごとの行に組み替えます。

タグは ListUserTags、キーの一覧は ListAccessKeys、最終利用は GetAccessKeyLastUsed で取ります。 これらはエージェントが道具として呼ぶサブワークフローにします。ListUserTags は既定で100件まで返し、IsTruncated が true なら Marker で続きを取ります。

AIへ渡す前に整形する

1. キーごとの行に組み替える … レポートの1行を、アクセスキー1とアクセスキー2の2行に分けます。状態が無効（access_key_N_active が FALSE）のキーは対象から外します
2. 日付の種類を分ける … 最終利用日時が日付なら「最後に使われた日」、N/A なら「一度も使われていない」と分けます。一度も使われていないキーは、作成日時から何日たったかで見ます
3. 90日の判定をする … 最後に使われた日、または作成日時から90日を超えたものを拾います
4. 3本目以降を持つユーザーを分ける … additional_credentials_info に値があるユーザーは、キーの一覧を別に取り、すべてのキーで同じ判定をします
5. 確認の記録と突き合わせる … アカウントID、ユーザー名、キーの番号で記録を引き、新しく拾ったもの、確認中のもの、回答済みのもの、除外の届けがあるものに分けます
6. 除外を外す … 「年1回の処理で使う」と回答があり、次の確認日を記録したキーは、その日まで渡しません

2番目を省くと、作ったばかりのキーまで拾います。 レポートでは、一度も使われていないキーの最終利用日時は N/A になります。N/A をそのまま「古い」と扱うと、先週作ったキーに確認が飛びます。

AIに処理させる

させるのは、キーごとに「誰に聞くか」を決め、確認の文面を作り、回答が来たら無効化の候補とその理由をまとめることです。

手順4の聞く相手は、次の順で決めさせます。 タグの持ち主が在籍していれば本人、退職・休職していれば名簿の上長、タグが無くチームのタグだけあればチームのチャンネル、どれも無ければ情報システムが自分で調べる（investigate）。手がかりの無いキーを、それらしい人に送らせないためです。

手順6の無効化の道具には、n8n の人の確認をはさみます。 AI Agent の道具の接続口で Human review を設定し、承認の経路を Slack にします。承認されれば、AIが指定した入力のまま道具が動き、却下されれば動かずにエージェントへ却下が伝わります。

4行目がいちばん起きやすい失敗です。 催促を2回しても返事が無いと、エージェントは「不要と判断」と書きたがります。返事が無いキーは、聞く相手を上長に替えるか、情報システムへ回すかのどちらかにさせます。

指示内容を固定する

あなたはSaaS企業の情報システム部で、長く使われていないAWSの
アクセスキーについて、持ち主を探して確認し、無効化の候補を
まとめる担当です。道具で確かめた事実だけで判断してください。

【入力】
- キー：{account_id} / {user_name} / キー{key_no}
- 作成日時・最終利用日時・最終利用のサービス：{usage}
- 確認の状態：{status}（new / waiting / answered）

【使える道具】
- get_user_tags：アカウントIDとユーザー名で、タグを返す
- get_employee：メールアドレスで、在籍・所属・上長を返す
- get_history：アカウントIDとユーザー名で、過去の確認を返す
- get_key_usage：キーIDの一覧と最終利用を返す
- deactivate_key：キーを無効化する（担当者の承認が要る）

【聞く相手の決め方】
1. owner タグの人が在籍していれば owner
2. owner が退職・休職なら、名簿の上長を manager
3. owner タグが無く team タグがあれば team
4. どれも無ければ investigate（送らない）

【厳守事項】
- タグや名簿で確かめられない人を持ち主として扱わないでください。
  ユーザー名から人の名前を推し量らないでください。
- 返事が無いことを「不要」とみなさないでください。
  催促が2回を超えたら、聞く相手を替えるか investigate に
  してください。
- deactivate_key は、回答が「止めてよい」で、最終利用から
  90日を超えているキーにだけ使ってください。
  却下されたら、理由を記録し、もう一度呼ばないでください。
- キーを削除しないでください。削除の道具はありません。
- 確認の文面には、アカウント名、ユーザー名、最後に使われた日と
  サービス、回答の期限を書いてください。キーIDは末尾4文字だけ。
- 分からない項目は「不明」と書いてください。

「ユーザー名から人の名前を推し量らない」を明記しないと、tanaka-test を田中さんのキーとして扱います。 社内に田中さんは何人もいます。禁じるのは、名前の一致を根拠にすることそのものです。

「却下されたら、もう一度呼ばない」も明記します。 却下を受けたエージェントは、理由を変えて同じ道具を呼び直すことがあります。担当者に同じ承認が何度も届くと、承認そのものが流し見になります。

出力形式を固定する

Structured Output Parser で、次の形のJSONを受け取ります。

{
  "account_id": "123456789012",
  "user_name": "ci-deploy",
  "key_no": 1,
  "key_id_suffix": "7QXA",
  "last_used": "2026-05-02",
  "last_used_service": "s3",
  "never_used": false,
  "owner": {
    "email": "",
    "source": "tag | none",
    "employment": "active | left | leave | unknown"
  },
  "ask_to": "owner | manager | team | investigate",
  "ask_to_email": "",
  "message_draft": "",
  "answer": "stop_ok | still_used | no_answer | not_asked",
  "proposal": "deactivate | keep | ask_again | investigate",
  "reason": "",
  "needs_human": false
}

1つ目の理由は、ask_to と owner.source で、送る前に根拠が分かることです。 タグから決めたのか、手がかりが無かったのかが項目に出るので、investigate のものだけを担当者が先に片付けられます。

2つ目は、answer と proposal を分けて持てることです。 回答は持ち主の言葉、提案はエージェントの判断です。「止めてよい」と返ってきても、先週使われていれば ask_again にする、といった食い違いが一覧で見えます。

3つ目は、キーIDを末尾4文字だけにしていることです。 無効化の道具は、ワークフローの側で記録から完全なIDを引いて渡します。Slackの文面にIDの全体が残りません。

システムへ連携する

Slack で承認を受けるには、n8n が公開されたHTTPSで届く場所にある必要があります。 Slack のアプリで Interactivity を有効にし、Request URL を https://<n8nのホスト>/webhook-waiting-slack にして、署名のシークレットを認証情報に入れます。Restrict Who Can Approve に情報システムの2名だけを入れます。 空のままだと、メッセージを見られる人なら誰でも承認できます。

Capture Who Responded を有効にすると、誰が承認したかが出力に残ります。 無効化の記録には、この承認者を必ず書きます。

人が確認する

人が見るのは、proposal が deactivate と investigate のもの、needs_human が立ったものです。 keep と ask_again は件数を流し見ます。

1. investigate を先に見る … 持ち主の手がかりが無いキーです。最後に使われたサービスとリージョンから、どのシステムのキーかを自分で調べます
2. deactivate の根拠を確かめる … 回答者が持ち主本人か上長か、最終利用が90日を超えているかを見ます
3. 無効化を承認する … Slack に届く承認の依頼で、道具の名前と入力（アカウント、ユーザー、キーの末尾）を確かめて承認します
4. 無効化から1か月後に削除を決める … 何も止まらなかったことを確かめ、削除は担当者が自分で行います

2番目で、回答者が上長だったものは特に丁寧に見ます。 上長は、部下が作ったキーの使われ方を知らないことが多く、「たぶん要らない」で止めてよいと答えがちです。

目標は、60件をならして1件8分です。 investigate は30分近くかかり、keep は数十秒で終わります。

例外に対処する

3行目を黙って飛ばすと、そのアカウントだけ見回りが止まります。 ロールの信頼ポリシーが変えられた、アカウントが組織から外れた、という理由で起きます。取れなかったアカウントは、件数が0件のときでも毎回の通知に出します。

8行目と9行目のために、無効化と削除を分けています。 UpdateAccessKey は状態を Active と Inactive の間で変える操作なので、無効化なら戻せます。

記録を残す

• 実行の日時と、アカウントごとのレポートの作成日時（GeneratedTime）と取得の結果
• 拾ったキーと、拾った理由（最終利用日、または一度も使われていないこと）
• エージェントの入力と、道具の呼び出しの記録（どのタグ、どの名簿の行を見たか）
• 送った確認の文面、送り先、送った日時、催促の回数
• 回答と回答者、proposal と reason
• 無効化の承認者と承認の日時、無効化の実行の結果

3つ目は、聞く相手の決め方を見直すために残します。 Tools Agent の Return Intermediate Steps を有効にすると、途中の手順を出力に含められます。

最後の行は、監査のときに問われる記録です。 誰の判断で、いつ、どのキーを止めたかが、Slack の承認と結び付いて残ります。