Secrets管理
SNS投稿APIを使う前のGitHub Secrets管理
YouTube、TikTok、Instagram、XのAPIを検討する場合、最初に考えるべきなのは投稿コードではなく認証情報をどこに置くかです。
APIキー、OAuthトークン、SNSパスワードを公開リポジトリやAIへの指示文に直書きしないでください。
守ること
- GitHubにAPIキーを直書きしない。
- 公開リポジトリにトークンを置かない。
- CodexやCopilotに秘密情報の実値を貼らない。
- GitHub Actionsで使う場合はSecretsを使う。
- 漏えいした可能性があるトークンはローテーションする。
SNS APIで特に注意するもの
- OAuth client secret
- refresh token
- access token
- API key
- Webhook secret
なぜ「コードより先に認証情報の置き場所」なのか
SNS自動投稿の開発で実際に起きる事故は、投稿ロジックのバグよりも「トークンの漏えい」が圧倒的に深刻です。投稿コードのバグは直せば済みますが、公開リポジトリにOAuthトークンをcommitしてしまうと、そのSNSアカウントの投稿権限・場合によってはDM閲覧権限まで第三者に渡ります。ボットは公開リポジトリを常時スキャンしており、漏えいから悪用までの時間は分単位です。だから「まず置き場所、コードはその後」という順番になります。
具体的な設計はシンプルです。ローカル開発では認証情報を.envファイルに置き、.gitignoreで除外します。GitHub Actionsで自動投稿する場合は、リポジトリのSettings→Secretsに登録し、workflowから環境変数として参照します。コード側には「環境変数から読む」処理だけを書き、実値はどこにも書きません。
トークン種別ごとの漏えい時の影響と対処
| 種類 | 漏れると何ができてしまうか | 漏えい時の対処 |
|---|---|---|
| OAuth client secret | あなたのアプリになりすまして認証フローを実行される | 開発者コンソールでsecret再生成 |
| refresh token | 長期間にわたりaccess tokenを再発行され続ける | アプリ連携の解除→再認証 |
| access token | 有効期限内の投稿・読み取り操作 | 失効を待たずrevoke |
| Webhook secret | 偽のイベント通知を注入される | secretを再設定し旧値を無効化 |
共通する鉄則は「リポジトリから削除しても履歴に残るため、混入に気づいたら削除ではなく無効化・再発行で対応する」ことです。SNSアカウント本体のパスワード変更もあわせて検討してください。