APIキーをGASのコードへ直接書くと、コードを共有したときや、エラー画面を見せたときに一緒に渡してしまうことがあります。スクリプトプロパティへ分けて置けば、本文中にキーを埋め込まず、設定名から取り出す形にできます。
ただし、保存先を変えただけで秘密管理が終わるわけではありません。どのプロジェクトで使うキーか、誰がコードを編集できるか、何をログへ残すかも一緒に確認します。
保存場所の選択
GoogleのProperties Serviceの説明には、スクリプト、ユーザー、文書に対応する保存先が示されています。スクリプトプロパティは同じスクリプトで使う共通設定を保存する用途です。ユーザープロパティとは共有する範囲が異なります。
共通のサービスへ接続するキーを置く場合でも、プロジェクトの編集権限を持つ人を確認します。編集者がコードを書き換えられる環境で、「設定画面を見せていないからキーは読めない」とは考えないようにします。別の担当者に同じ権限を渡す必要があるかから決めます。
プロパティは文字列として保存されます。実行モードや件数を置く場合も、取得した値をそのまま真偽値や数値として扱わず、必要な型へ明示的に直します。たとえば文字列のfalseを、JavaScriptのfalseと同じつもりで判定しないことが大切です。
エディタで登録する項目
Apps Scriptの「プロジェクトの設定」を開き、スクリプトプロパティへ設定名と値を登録します。例ではSERVICE_API_KEYをキー用、SERVICE_BASE_URLを接続先用とします。実際の値はこの記事や共有シートへ書かず、各自の設定画面へ入力します。
| 設定名 | 用途 | 共有用READMEに書く内容 |
|---|---|---|
| SERVICE_API_KEY | 接続サービスのキー | 必須であることと登録先 |
| SERVICE_BASE_URL | APIの接続先 | テスト用と本番用の区別 |
| RUN_MODE | 試運転などの指定 | 使用できる値と既定の動き |
READMEへ載せるのは設定名と説明です。画面のスクリーンショットに値が映る場合は、その画像自体を共有しないようにします。キーの先頭だけを見せる運用も、どこまで必要かを考えてから決めます。
設定を読む関数
次は、設定がなければ処理を止める例です。Googleのサービスに接続する部分は実行していません。値を取得できたかだけを確認し、キーそのものは表示しない形にします。
function requireScriptSetting(name) {
const value = PropertiesService.getScriptProperties()
.getProperty(name);
if (value === null || value.trim() === '') {
throw new Error('設定がありません: ' + name);
}
return value;
}
function checkConfiguration() {
requireScriptSetting('SERVICE_API_KEY');
console.log('必須設定を確認しました');
}
キーがない状態で外部APIへ送ると、通信側の認証エラーから調べ始めることになります。先に設定名を確かめると、入力漏れとサービス側の問題を分けられます。エラー文に入れるのも値ではなく設定名までにします。
ログと例外処理の点検
getPropertiesで全設定をまとめて取得し、そのオブジェクトをconsole.logへ渡すと、キーまでログに出るおそれがあります。接続コードへ追加したデバッグ出力も見直してください。
通信エラーを記録するときは、ヘッダーやURLへ秘密が混ざっていないかを確認します。保存場所を分けていても、取り出した後にログへ書けば同じ問題が起きます。キーを取得する行、通信へ渡す行、失敗を記録する行を順に確認します。
キーを差し替えるとき
差し替えでは設定名を変えるのか、同じ名前の値を更新するのかを決めます。利用するコードがどちらを読むかを確認し、テスト用の接続で動作を確かめます。漏えいが疑われる場合の無効化や権限変更は、接続サービスの手順に従ってください。
担当交代の記録にはサービス名、設定名、管理者、更新日、動作を確かめた範囲を残します。キーの値を引き継ぎメモへ複製する必要はありません。使わなくなった設定も別の処理から参照されていないかを確認してから整理します。
キーの確認結果を管理する考え方はGemini APIキーの確認、GASのコード構成を整理する場合は関数とファイルの分割も参考になります。
