退職しても止まらない自動化の作り方【2026年11月】— API キー・トリガー・CI の名義を個人から外す4つの判断

「問い合わせの仕分けや月次の集計を自動化したが、作った担当者が辞めた翌月に止まった」。原因のほとんどは、プログラムの不具合ではなく、鍵やトリガーが個人の名義で作られていたことです。

この記事は、社内の自動化を Claude Code や Apps Script、GitHub Actions、Stripe で組む企業の情シス・業務改善の担当者向けに、「誰の名義で動かすか」を作る前に決めるための判断を整理したものです。各サービスの公式ドキュメントで確かめられる仕様だけを根拠にしています。退職が決まってからの消し漏れの手順は、退職・端末返却の手順書に分けて書きました。本記事は、その前段の「最初から止まらないように作る」側です。

読み終えると、自社の自動化を名義台帳に書き出し、新しく作るものに個人の鍵を使わない判断ができるようになります。

1. 鍵には「人に属する」「サービス用の身元に属する」「場所に属する」の3種類がある。 人に属する鍵は、その人が組織を離れると止まります。自動化は、人以外の名義で作ります。
2. Claude API は、共有や無人の処理にはサービスアカウントの鍵を使う。 公式ドキュメントは、個人キーは本人の開発用、CI や本番の処理にはサービスアカウントを、と明記しています。長期の秘密を置かずに済む Workload Identity Federation（WIF）も選べます。
3. GitHub 側は、個人アクセストークンではなく GitHub App か OIDC を使う。 個人アクセストークンは利用者に結び付き、その人がリソースへのアクセスを失うと無効になります。
4. Apps Script のトリガーは作成者のアカウントで動く。 個人の Google アカウントで作ったトリガーは、その人の退職と運命を共にします。部署用のアカウントで作るか、別の仕組みに移します。
5. Stripe は制限付きキーを用途ごとに切り、担当者の退職時に回す。 公式は、鍵を知る人が組織を離れたときの鍵の回転（ローテーション）を明示的に求めています。

自動化が使う認証情報は、「何に属しているか」で3つに分かれます。この分類を押さえると、サービスごとの違いが読みやすくなります。

「人に属する」鍵は、本人の開発や検証に使う限りでは便利です。問題は、それを無人で動く処理に埋め込むことです。Anthropic の公式ドキュメントは、共有した個人キーは「1人の人物として動き、その人が離れると壊れる」と書き、共有や自動化の処理にはサービスアカウントを作るよう勧めています。

※ 出典: Anthropic「Authentication」Key types（取得 2026-11）

「場所に属する」鍵は、人が離れても止まらない一方で、誰が使ったのかを後から追いにくいという弱点があります。Anthropic はワークスペースキーをレガシーと位置づけ、身元に紐づく鍵か WIF への置き換えを勧めています。

Claude API の鍵は、作るときに種類を選びます。種類によって「誰として動くか」と「いつ止まるか」が決まります。

※ 出典: Anthropic「Authentication」Key types（取得 2026-11）

Admin API の FAQ は、利用者を外したときの挙動を一文で整理しています。個人キーは利用者を組織から外すと止まり、サービスアカウントの鍵は作成者を外しても動き続け、ワークスペースキーも動き続けます。加えて、Claude Code ワークスペースの鍵は作成した本人に結び付き、その人を外すと止まるとあります。Claude Code を API 課金で配っている会社は、ここが退職時の落とし穴になります。

※ 出典: Anthropic「Admin API」FAQ: What happens to API keys when removing a user?（取得 2026-11）

サービスアカウントは、組織の中に作る人ではない名義です。公式の説明では、メールアドレスもパスワードも Console のログインも持たず、ワークスペースのメンバーとして追加したところで有効になります。鍵も連携トークンも、この名義に紐づけて発行します。「ワークスペースキーは認証情報そのもの、サービスアカウントは認証情報を持つ主体」という対比が、公式ドキュメントの言い方です。

※ 出典: Anthropic「Workload Identity Federation」Service accounts（取得 2026-11）

鍵の期限は作成時に選び、後から変えられません。Console では 3時間・1日・7日・30日のプリセット、任意の期間、または「期限なし」から選びます。組織に最長期限のポリシーがあると、「期限なし」は選べなくなります。期限が近づくと作成者にメールが届きますが、通知は作成者個人に届く点に注意が要ります。退職者が作った鍵の期限切れ通知は、誰にも読まれません。

※ 出典: Anthropic「Authentication」Key expiration（取得 2026-11）

Workload Identity Federation（WIF）は、GitHub Actions・AWS・Google Cloud・Kubernetes などが発行する短命の身元トークンを、Anthropic の短命なアクセストークンに交換する仕組みです。公式ドキュメントの表現では、「作る・配る・回す sk-ant-api... の文字列が存在しない」状態になります。発行されるトークンの寿命はルール側で決め、既定は 3,600 秒、ウィザードの初期値は 600 秒です。

※ 出典: Anthropic「Workload Identity Federation」（取得 2026-11）

GitHub Actions から使う場合、GitHub が発行する身元トークンはおよそ 5 分で期限切れになり、連携ルールはリポジトリ・ブランチ・環境名で絞れます。公式は、組織全体に一致する緩い条件を置くと、フォークからのプルリクエストでもトークンが取れてしまうと警告しています。ルールは、本番ブランチや承認付きの環境に限定して書きます。

※ 出典: Anthropic「Use WIF with GitHub Actions」（取得 2026-11）

設定には組織の admin・owner・primary owner のいずれかの役割が必要です。導入前に、Console の役割を誰が持っているかを確かめます。

Claude Code を GitHub Actions で動かす場合、認証は API キーか、claude setup-token で作る OAuth トークンのどちらかです。OAuth トークンは有効期間1年で、生成した人の契約（サブスクリプション）に結び付きます。公式ドキュメントは、組織でリポジトリをまたいで共有する秘密情報には、OAuth トークンではなく Claude Console の API キーを使うよう書いています。理由はまさに、トークンが「claude setup-token を実行した人」の契約に紐づくからです。

※ 出典: Claude Code「Authentication」Generate a long-lived token（取得 2026-11）／Claude Code「GitHub Actions」Set up for an organization（取得 2026-11）

同じページには、もう1つ見落としやすい注意があります。GitHub の Secret を削除しても、そこに入っていた鍵は有効なままです。鍵を本当に引退させるには、Claude Console 側で鍵を削除する必要があります。

GitHub Actions での権限と費用の決め方は、Claude Code を GitHub Actions で動かすに書いています。鍵を Claude Code のプロセスに見せない方法は、サンドボックスの mask で隠す鍵が扱っています。

自動化が GitHub のリポジトリを読み書きする場合、「GitHub 側の名義」も決める必要があります。

※ 出典: GitHub Docs「Managing your personal access tokens」（取得 2026-11）／GitHub Docs「Deciding when to build a GitHub App」（取得 2026-11）

GitHub の公式ドキュメントは、個人アクセストークンは利用者に結び付き、その利用者がリソースへのアクセスを失うと無効になると書いています。一方で GitHub App は「組織にインストールされたアプリは利用者に依存しない」「最初にインストールした人が組織を離れてもインストールされたまま残る」とあり、トークンも短命です。退職の影響を受けない名義として、公式が勧めているのは GitHub App です。

OIDC は、GitHub Actions のジョブがクラウド事業者から短命のアクセストークンを受け取る仕組みです。公式は「クラウドの秘密情報を GitHub に長期の Secret として複製しなくてよい」「トークンは1つのジョブの間だけ有効で、自動的に失効する」と説明しています。前節の Anthropic の WIF は、この OIDC トークンを Claude API 向けに交換するものです。

※ 出典: GitHub Docs「OpenID Connect」（取得 2026-11）

実務では、「Claude Code が GitHub に書き込む名義」と「Claude Code が Anthropic に認証する名義」を分けて決めます。前者は Claude GitHub App か自社の GitHub App、後者はサービスアカウントの鍵か WIF、という組み合わせにすると、どちらも個人に依存しません。

Gmail の仕分けやスプレッドシートの集計を Google Apps Script で自動化している会社は多いはずです。ここに、見落とされがちな仕様があります。公式ドキュメントは「インストール型トリガーは常に、それを作成した人のアカウントで実行される」と明記しています。同僚がファイルを開いたときに動くトリガーでも、作成者のアカウントで動き、送信されるメールは作成者のアドレスから出ます。

※ 出典: Google「Installable Triggers」（取得 2026-11）

つまり、個人の Google アカウントで作ったトリガーは、その人のアカウントと運命を共にします。公式ページは、作成者がアクセスを失ったときの挙動を直接は書いていませんが、Google Workspace の管理者ヘルプは、削除した利用者の復元は 20日以内で、本人だけが所有し移管しなかったデータは完全に削除されると説明しています。ドライブのファイルは管理者が別の利用者に移管できますが、トリガーの移管は案内されていません。

※ 出典: Google Workspace 管理者ヘルプ「組織から利用者を削除または除外する」（取得 2026-11）

割り当て（クォータ）も利用者単位です。トリガーは1利用者・1スクリプトあたり 20 個まで、トリガーの合計実行時間は Google Workspace アカウントで1日 6 時間、一般アカウントで1日 90 分です。部署用のアカウントにトリガーを集めると、この上限を1つのアカウントで消費します。集約する前に、合計の実行時間を見積もります。

※ 出典: Google「Quotas for Google Services」（取得 2026-11）

1. 部署用の Google アカウントでトリガーを作り直す。 送信メールの差出人もそのアカウントになるので、署名や返信先を部署のものに整えます。パスワードと2段階認証の管理は、個人の端末に置かず、情シスが保管します。
2. トリガーの一覧を定期的に取る。 公式ページのとおり、ある利用者は他の利用者が入れたトリガーを見られません。各担当者に script.google.com の「マイトリガー」を確認してもらい、台帳に写します。
3. Apps Script から外へ出す。 無人で確実に動かしたい処理は、サービスアカウントの鍵や WIF で認証する別の実行環境に移す選択もあります。問い合わせの仕分けを Apps Script と Claude で組む具体的な流れは、問い合わせメールの一次仕分けに書きました。

決済から納品メールまでを自動化している会社は、Stripe の鍵の名義も確かめます。Stripe の公式ドキュメントは、すべての権限を持つシークレットキー（sk_）を新しい用途に使うことを勧めず、権限を絞った**制限付きキー（rk_）**への移行を推奨しています。制限付きキーはいくつでも作れるので、「納品メールを送る処理」「月次の集計を取る処理」のように用途ごとに分けられます。

※ 出典: Stripe「API keys」Key types（取得 2026-11）

名義の観点で重要なのは、Stripe が「鍵の回転」を求める場面に、鍵にアクセスできるチームメンバーが組織を離れたときを明示的に含めていることです。ダッシュボードで回転すると、新旧の鍵が最長 7日間は両方動くので、止めずに差し替えられます。旧鍵のリクエストログがゼロになったのを確かめてから失効させる、という手順も公式に書かれています。

※ 出典: Stripe「API keys」Rotate an API key（取得 2026-11）／Stripe「Best practices for managing secret API keys」（取得 2026-11）

Stripe の鍵は「場所に属する」型なので、退職で自動的に止まることはありません。だからこそ、退職者が鍵の値を知っていた可能性がある時点で回すのが、公式の求める運用です。合わせて、アクセスポリシーで鍵が使える IP アドレスや国を絞っておくと、持ち出された鍵が外から使われたときに遮断と通知が働きます。

AI エージェントに Stripe を操作させる場合は、制限付きキーを「エージェント用」として作る選択肢があります。公式は、エージェント用と印を付けた鍵には承認ルールが自動で適用され、返金や入金設定の変更のような操作は指定した人の承認を待つと説明しています。Webhook の署名検証と冪等化の設計は、Stripe 決済から納品メールまでを自動化するに書いています。

4つの判断を社内で共有するには、自動化ごとに「誰の名義で、どの鍵で、いつ止まるか」を1行にした台帳が要ります。次の表をそのままスプレッドシートに写して使えます。

鍵の値は台帳に書きません。 台帳に書くのは種類と識別名だけで、値はシークレットマネージャーか環境変数に置きます。Stripe の公式も、鍵の値はコードや設定ファイルに置かず、保管場所の名前をメモに残すよう案内しています。

社内で名義と鍵の置き場を決めてから自動化を組む手順は、企業向けの有料の実務書にもまとめています。

印刷して、着手前に担当者と情シスで一緒に確認してください。

• □ この自動化は、誰かが退職しても動き続ける必要があるか（必要なら人の名義は使わない）
• □ Claude API の鍵は、個人キーではなくサービスアカウントの鍵か WIF か
• □ 鍵の期限は、組織の最長期限ポリシーに合っているか。期限切れの通知は作成者個人にだけ届くと理解しているか
• □ Claude Code を CI で動かす場合、共有の秘密情報は OAuth トークンではなく API キーか WIF か
• □ GitHub への書き込みは、個人アクセストークンではなく GitHub App か OIDC か
• □ Apps Script のトリガーは、個人ではなく部署用のアカウントで作っているか。合計の実行時間の上限を見積もったか
• □ Stripe の鍵は制限付きキーで、用途ごとに分かれているか。アクセスポリシーを付けたか
• □ 鍵の値は、シークレットマネージャーか環境変数だけに置いているか（ソースコード・チャット・メールに無いか）
• □ 名義台帳に1行を追加したか（名義・鍵の識別名・止まる条件・担当の役割）
• □ 鍵を引退させる手順（Secret の削除だけでなく発行元での削除）を台帳の「退職時の処置」に書いたか

1. 「動いているから」と個人キーを放置した。 退職の日に止まり、原因が鍵だと分かるまでに時間がかかる。鍵は作った時点で名義を選ぶものなので、後から「サービスアカウントに変える」には差し替えが必要になります。差し替えの手順は Anthropic の公式ドキュメントに5段階で載っています。
2. GitHub の Secret を消して「鍵を無効化した」と思った。 Secret の削除は鍵そのものを無効にしません。発行元の Console で鍵を削除するまで、どこかに写された鍵は使えます。
3. claude setup-token のトークンを組織の Secret に置いた。 トークンは実行した人の契約に結び付きます。その人が契約から外れると、組織の全リポジトリの Claude Code が止まります。
4. Apps Script のトリガーを「共有ドライブに置いたから大丈夫」と考えた。 ファイルの場所と、トリガーが動くアカウントは別です。トリガーは作成者のアカウントで動きます。
5. Stripe のシークレットキーを複数の処理で使い回した。 1つの処理の担当者が辞めるたびに全処理の鍵を回す必要が出て、回転が後回しになります。用途ごとの制限付きキーなら、影響範囲が1つの処理に収まります。

作り直す必要はありません。Claude API の場合、公式ドキュメントに差し替えの手順が載っています。管理者がサービスアカウントを作ってワークスペースに追加し、その名義で鍵を作り、環境変数やシークレットマネージャーの値を差し替え、リクエストが通ることを確かめてから古い鍵を削除します。コードは変えず、鍵の置き場だけを変えます。

※ 出典: Anthropic「Authentication」Replacing workspace API keys（取得 2026-11）

公式の FAQ は、サービスアカウントの鍵はサービスアカウント自体をアーカイブしたときに止まり、作成した利用者を組織から外しても動き続けると書いています。逆に、個人キーは本人を外した時点で止まります。退職時に止めたいのか、動かし続けたいのかを、作るときに名義で選ぶことになります。

トリガーは作成者のアカウントで動くので、個人ではなく部署用のアカウントで作ると、退職の影響は受けにくくなります。ただし、そのアカウントの認証情報の管理と、送信メールの差出人がそのアカウントになることは別に決める必要があります。合計の実行時間の上限も、そのアカウント1つで消費します。

公式ドキュメントは、組織で共有する秘密情報には OAuth トークンではなく API キーを使うよう書いています。OAuth トークンは、生成した人の契約に結び付くためです。長期の秘密を置かない方法として、GitHub の OIDC トークンを Claude API のアクセストークンに交換する Workload Identity Federation も用意されています。

まず、社内で動いている自動化を名義台帳に書き出してください。1行目を埋めるだけで、「人に属する鍵」で動いているものが見えてきます。次に、新しく作るものから、Claude API はサービスアカウントの鍵、GitHub は GitHub App、Apps Script は部署用アカウント、Stripe は用途別の制限付きキーに切り替えます。

鍵の名義の整理から、Claude Code の社内ルール、CI での無人実行の設計までをまとめて進めたい場合は、お問い合わせから現状をお知らせください。Claude の法人導入の全体像はClaude 導入支援に、自動化を含む支援の範囲はサービス一覧にまとめています。

• 2026-11-15: 初版公開

• Claude Code を使っていた社員の退職・端末返却の手順書 — 退職が決まってからの消し漏れ防止。本記事の後段
• Claude Code を GitHub Actions で動かす — 認証・権限・費用の上限
• Claude Code に API キーを見せずに使わせる — サンドボックスで鍵を隠す
• 問い合わせメールの一次仕分けを Apps Script と Claude で自動化 — トリガーで動く仕分けの実装
• Stripe 決済から納品メールまでを自動化する — Webhook の署名検証と冪等化
• Claude Code の法人導入ガイド — 管理者が先に決める設定配布・権限・監査