Salesforceのパスワードを変えたら、連携が8箇所いっせいに止まった

この記事は Zenn に投稿したものの再掲です。
https://zenn.dev/reona777/articles/salesforce-credential-rotation

教育系の事業所で現場の運営をしています。エンジニアではありません。2026年の春から Claude Code で社内ツールを作り始めて、5か月で6本を本番稼働させました。

前の記事では、Salesforce を外から自動化して踏んだスキーマ側の話を書きました。

今回は同じ Salesforce でも運用の話です。パスワードを1回変えただけで、連携している自動化が8箇所いっせいに止まりました。

先に結論を書きます。認証情報は「1箇所にある」つもりで運用していました。実際には8箇所に配ってありました。 作るときは1本ずつ足していくので、散らばっていることに気づく機会がありません。気づくのは、変えるときです。

前提：パスワードを変えるとトークンも変わる

Salesforce に API でログインするときは、パスワードにセキュリティトークンを繋げて送ります。ここが最初の落とし穴でした。

パスワードを変更すると、セキュリティトークンもリセットされます。 新しいパスワードと古いトークンの組み合わせでは通りません。

なので、パスワードを配って回っても直りません。パスワードとトークンは必ずセットで配る必要があります。

そして、うちの環境ではパスワードがセキュリティポリシーで定期的に強制変更されます。つまりこれは一度きりの事故ではなく、これから何度も来る作業です。

症状は分かりやすくて、全系統がいっせいに INVALID_LOGIN になります。 逆に言えば「急に Salesforce 連携が全部動かなくなった」と言われたら、まずこれを疑えばいい、ということでもあります。

数えたら8箇所あった

止まったものを追いかけて、配布先を全部書き出しました。

1. ローカルのスクリプト群が読む .env
2. 別プロジェクトのローカル .env
3. GitHub Actions の Secrets
4. Vercel の環境変数
   5〜7. Google Apps Script のスクリプトプロパティ（3プロジェクト）
5. 共用PCに置いた実行ファイル用の、暗号化された資格情報ファイル

8箇所です。 そして、これを事前に一覧で持っていませんでした。

理由ははっきりしていて、作るときは1本ずつ足したからです。「今日はこのツールを作る、認証情報を置く」を8回やっただけで、その時点ではどれも自然な作業でした。散らばりは、足しているあいだは可視化されません。

反映のされ方が、場所ごとに違った

配るだけなら8箇所でも作業量の問題です。実際に時間を取られたのは、同じ「環境変数を更新する」が、場所によって意味が違ったことでした。

GitHub Secrets は書けるが読めない

設定はできますが、入っている値を後から確認できません（write-only です）。なので「今どの値が入っているか」を見て差分を取る、という確認ができません。上書きしたあと、実際に動かして確かめるしかありませんでした。

Vercel は差し替えただけでは反映されない

環境変数を新しい値に直しても、すでに動いているサイトはそのままです。 環境変数はデプロイに紐づいているので、Redeploy して初めて効きます。ここは「直したのに直らない」で一度止まりました。

前に書いた記事で「直したのに古いまま」というAndroidのアイコンの話をしましたが、構造は同じです。更新したものと、動いているものが別という形は何度も出てきます。

Google Apps Script はアカウントを間違えると別の画面に飛ぶ

複数の Google アカウントを使い分けていると、スクリプトの設定画面のURLにアカウント番号が入ります。ここを間違えると、GASのエラーではなく Drive の「アクセス権が必要です」 に飛ばされます。

これが地味に厄介で、権限が無いのか、アカウントが違うのか、URLが間違っているのかが画面から区別できません。 プロジェクトごとにどのアカウントで開くかをメモしておくしかありませんでした。

暗号化した資格情報は、別のPCへコピーしても無意味

共用PCで動かしている印刷用のスクリプトは、資格情報を Windows の DPAPI で暗号化して置いてあります。これは暗号化した本人のアカウントでしか復号できません。 つまりファイルを作り直すには、そのPCで、そのユーザーとして、セットアップを再実行する必要があります。

手元から配って終わり、にはなりませんでした。

キー名が揃っていなかった

これは自分で撒いた種です。同じ値を指すキーの名前が、場所によって違っていました。

ローカルの .env       SF_TOKEN
GitHub Actions        SF_SECURITY_TOKEN

作った時期が違うだけの、意味のない差です。ただしこのせいで、一括置換のスクリプトを書いて全部に流す、ということができません。 ローカルで別プロジェクトのコードを回すときにも読み替えが要ります。

同じものには同じ名前を付ける。 シリーズで何度も書いている話が、ここでも同じ形で出てきました。

検証の順序を決めたのが、いちばん効いた

8箇所を直すとき、最初はやみくもに配っていました。途中で止めて、順序を固定しました。

まずローカルの1箇所だけ直して、そこから1本クエリを投げる。

from sf_login import sf
sf.query_all("SELECT Id FROM (対象) LIMIT 1")

ここが通れば、値そのものが正しいと確定します。 以降は「配るだけ」の作業になります。

これをやらないと、どこかで失敗したときに 「値が間違っているのか、その場所への配り方が間違っているのか」が切り分けられません。 実際、Vercel の Redeploy 忘れは「値が違うのでは」と疑って30分溶かしました。順序を決めてからは、疑う先が1つに絞られます。

確認の順序を決めるというのは、原因の候補を1つずつ潰せる形に並べ替えることでした。

副作用なしで確認できる入口を、各所に作った

もう1つやったのが、「動かして確かめる」を安全にすることです。

本番の自動化で疎通確認をすると、通知が飛んだりレコードが作られたりします。確認のために本番を1回動かす、という状態はまずいので、各所に読むだけの入口を用意しました。

• 一方はログインして件数を数えるだけの関数。レコードを作らない
• もう一方は集計と通知本文をログに出すだけの dry run。投稿しない
• GitHub Actions のワークフローは dry_run を付きで手動実行。ログイン失敗なら終了コードを立てて failure になるので、緑か赤かだけ見れば分かる

ここで1つ、前の記事と繋がる注意があります。この確認は「0件」でも成功です。 対象が0件の日はログに「0件取得」と出ますが、それはログインが成功して結果が0件だっただけで、異常ではありません。

つまり、確認したいのは件数ではなくログインが通ったことのほうです。ここを取り違えると、成功しているのに失敗と読んだり、その逆をやったりします。

AIに頼めなかった部分

シリーズで一貫して同じ結論に着いています。今回も同じでした。

認証情報の更新をAIに頼むこと自体はできます。ファイルの書き換えも、CLIでのSecrets設定も、問題なくやってくれます。

ただし、「どこに配ってあるか」はコードの中に書いていません。

GitHub Secrets も、Vercel の環境変数も、GAS のスクリプトプロパティも、リポジトリを全部読んでも出てきません。 参照している側のコードには SF_TOKEN と書いてあるだけで、その値がどこから来るのかは実行環境の話です。共用PCの暗号化ファイルに至っては、そもそもリポジトリの外にあります。

AIが持っていないのは手順ではなく、配布先の地図でした。 そしてこれは、実際に一度全部止めてみるまで、自分も持っていませんでした。

手順書にした

繰り返し来ると分かっているので、次に同じことが起きたときに上から順になぞるだけの手順書を残しました。書いたのは配布先の一覧と、それぞれの反映のさせ方と、確認コマンドです。

そして手順書の1行目を「まずローカルを直して1本クエリを投げる」にしました。 これが通るまで他の7箇所に触らない、という順序そのものが、いちばん再現したかったものだからです。

いま数えると、実質9箇所目が増えています。増えたこと自体は問題ではありません。増えたときに一覧へ足す場所がある、という状態になったのが今回の成果でした。

最後に

作っているあいだは、認証情報が散らばっていく実感がまったくありませんでした。1本ずつ足していたので、毎回「1箇所置いた」だけです。

足し算は気づかないうちに進んで、変更のときに一括で請求されます。 今回は8箇所で済みましたが、これが20箇所になってからだと、たぶん一日では終わりませんでした。

同じことをやっている人がいたら、止まる前に一度、配布先を数えてみるのをおすすめします。 数えるだけなら30分で終わります。

ほかに作ったものは GitHub に置いています。

書いている人

エンジニアではありません。勤務先の業務ツールを Claude Code で作って運用していて、作ったものと、壊れたときに直した話を書いています。

Claude Code の実務運用については X（@KouritsuONI）でも書いています。スプレッドシート・GAS・LINE・Salesforce まわりの業務自動化について、ご相談は X のDMからどうぞ。

この記事のシリーズ

Claude Code の実務運用について、順に9本書いています。

1. 非エンジニアがClaude Codeで社内ツールを6本 本番稼働させるまでにやったこと
2. AIに作らせたツールが本番で壊れた5つの原因と、直し方
3. Claude CodeにCONTEXT.mdとSPEC.mdとADRを書かせると、途中で破綻しなくなる
4. Claude Codeのスラッシュコマンドには、手順ではなく踏んだ罠を書く
5. Claude Codeのメモリに53本ためて分かった、書く価値のある事実とない事実
6. 実行は成功、でも誰にも届いていない。無言で失敗する自動化に気づく仕掛け
7. Salesforceの項目は「ある」と「使える」が別だった。外から自動化して踏んだ6つ
8. Salesforceのパスワードを変えたら、連携が8箇所いっせいに止まった（この記事）
9. Salesforceのログインが2027年6月に廃止される。自動化10本を調べたら、直す場所は1つではなかった