共同アカウントと権限を安全に準備する

この章で学ぶこと

• 1つのパスワードを共有せず、各メンバーを招待する
• サービスごとの「所有者」「開発者」「会計」の違いを理解する
• ログイン方法、二段階認証、退会時の権限削除を運用表にする

共有するのはパスワードではなく権限

サービス用の共通メールアドレスとパスワードを全員で使うと、誰が操作したか分からず、二段階認証や退会時の停止も難しくなります。原則は次の形です。

組織・代表者が所有するサービス
  ├─ 開発担当の個人アカウントを招待
  ├─ リリース担当の個人アカウントを招待
  ├─ 会計担当の個人アカウントを招待
  └─ 閲覧だけの人には閲覧権限

組織の所有者アカウントを用意する場合も、日常作業には使いません。復旧情報、二段階認証、請求先、規約同意を管理する少人数だけが扱う「緊急用の所有者」とし、普段は招待された各自のアカウントでログインします。

アカウント共有方法の一覧

ここでいう「共有」は、同じIDとパスワードを渡すことではなく、各メンバーのアカウントをサービスへ招待することです。「Androidアカウント」は、Androidアプリを配布するGoogle Play Consoleとして整理しています。

サービス	共有方法・設定場所	メンバーのログイン方法	権限の目安	主な注意点
Googleアカウント	アカウント自体は共有しない。各自が個人用または組織管理のGoogleアカウントを持ち、各サービスから招待する	各自のGoogleアカウントでログイン	サービスごとに個別設定	共通パスワード、共通の二段階認証、個人所有アカウントだけに依存しない
Firebase / Google Cloud	Firebase Consoleのプロジェクトの設定 > ユーザーと権限、またはGoogle Cloud IAMでメンバーを追加	招待されたGoogleアカウント。CLIはfirebase login、複数アカウントはfirebase login:addとfirebase login:use	閲覧者、Firebaseの製品別ロール、必要なカスタムロール。Ownerは少人数	開発用・本番用プロジェクトを分け、課金、IAM、本番データ、デプロイの権限を必要以上にまとめない
Google Play Console（Android配布）	Users and permissionsからGoogleアカウントを招待し、アカウント全体または対象アプリだけの権限を設定	招待されたGoogleアカウントでPlay Consoleへログイン	Account ownerは1人、Adminは少人数、通常はアプリ単位のUser権限	Android Studioやローカルビルドに共有ログインは不要。支払い設定などOwnerだけの操作がある。期限付きアクセスも利用する
Androidの署名鍵	アカウント招待ではなく、keystoreとパスワードを承認済みの秘密情報保管場所で管理する	releaseビルド担当またはCIだけが利用	利用者を限定し、読取記録を残す	Git、メール、チャット、生成AIへ渡さない。Play App Signingではアップロード鍵とGoogle Playのアプリ署名鍵を区別する
Apple Developer / App Store Connect	組織のAccount HolderまたはAdminがApp Store ConnectのUsers and AccessからApple Accountを招待し、役割・対象アプリを設定	各自のApple AccountでApp Store ConnectとXcodeへログイン	Account Holderは1人、Adminは少人数、App Manager、Developer、Financeなどを担当別に設定	Account HolderのApple Accountを共有しない。個人登録と組織登録では招待メンバーが利用できる範囲が異なる
iOSの証明書・API鍵	Xcodeの自動署名または管理手順を使う。App Store Connect API鍵はCIの秘密情報として限定管理する	招待されたApple Accountまたは専用CI認証	Certificates, Identifiers & Profilesへの権限を必要な人だけに付与	.p8、.p12、秘密鍵、証明書パスワードをGitや生成AIへ渡さない。不要な鍵は失効させる
AdMob	Settings > Users > Add userからGoogleアカウントを招待し、ロールとアクセス可能なアプリを設定	招待されたGoogleアカウントでAdMobへログイン	Administratorは少人数。広告担当には組み込み・カスタムロールと対象アプリだけを設定	AdMob本体と支払いプロファイルの権限は別。招待先が別のAdMobアカウントと関連している場合は制約を確認する
Google AdSense	Account > Access and authorization > User managementからGoogleアカウントを招待	招待されたGoogleアカウントでAdSenseへログイン	Administratorは少人数。通常利用者は必要なアクセスレベルだけ	アカウント所有者が最終責任を持つ。招待先が別のAdSenseアカウントと関連している場合は制約を確認する
Googleの支払いプロファイル	AdMob / AdSenseのPaymentsからManage payments usersを開き、会計担当を招待する	招待されたGoogleアカウントで支払い情報へアクセス	Admin、Full access、Read only、Email onlyなどを業務別に設定	組織プロファイルでのみ追加できる場合がある。銀行・税務情報へのアクセスを開発者権限と分離する

共有可否を短く整理すると

対象	チームでの扱い
サービスのプロジェクト・アプリ	各メンバーを招待して共有する
管理画面の閲覧・編集権限	役割と対象アプリを限定して共有する
所有者のパスワード、二段階認証コード	共有しない
Android keystore、Apple秘密鍵、API秘密鍵	必要な担当者・CIだけが秘密情報保管場所から利用する
FirebaseのProject ID、アプリID、広告ユニットID	用途を明記して設定として管理する。秘密鍵とは区別する
銀行、税務、売上情報	会計担当に限定し、開発者権限と分ける

最初に作るアクセス台帳

秘密値そのものではなく、管理場所と担当を記録します。

サービス	所有者	日常管理者	開発者	会計	復旧手順の保管場所
Firebase / Google Cloud	代表者	技術責任者	必要なロール	請求担当	チームの限定文書
Google Play Console	Account owner	Admin	アプリ単位	必要時のみ	同上
Apple Developer	Account Holder	Admin	Developer / App Manager	Finance	同上
AdMob	Administrator	広告担当	アプリ限定	Payments user	同上
AdSense	Administrator	Web広告担当	必要時のみ	Payments user	同上

最低でも管理者を2人にし、1人の退職や端末故障で更新不能にならないようにします。一方で、全員をOwnerやAdminにはしません。

GoogleアカウントとFirebase

メンバーを追加する

FirebaseプロジェクトはGoogle Cloud IAMの権限を使います。Firebase Consoleのプロジェクト設定にある「ユーザーと権限」、またはGoogle Cloud ConsoleのIAMからメンバーを追加し、役割を割り当てます。

• 閲覧だけならViewer系の役割から始める。
• Firebaseの開発作業には、必要なFirebaseの定義済みロールを選ぶ。
• Owner、Editorのような広い基本ロールを習慣で配らない。
• 課金、IAM変更、本番データ閲覧は開発権限と分ける。

Firebaseの権限は役割に含まれる権限の集合です。Firebase IAMの公式一覧で、実行したい操作に必要な権限を確認してください。

Firebase CLIへログインする

招待を受けた自分のGoogleアカウントで認証します。

firebase login
firebase projects:list

PCで複数のGoogleアカウントを使う場合は、CLIのアカウントを明示します。

firebase login:add
firebase login:list
firebase login:use
firebase projects:list

プロジェクトの切り替えはアカウントの切り替えとは別です。

firebase use
firebase use --add
firebase deploy --only hosting --project YOUR_PROJECT_ID

実行前に、firebase login:list、firebase use、コマンドの--projectを確認します。Firebase CLI公式リファレンス

CIでは個人のログイン状態をコピーせず、サービスが推奨するWorkload Identityや専用のサービスアカウントを使い、権限と有効期限を限定します。秘密鍵JSONをリポジトリへ保存してはいけません。

Google Play Console（Android配布）

Androidアプリをローカルでビルドするだけなら、Play Consoleの共有ログインは不要です。ストア登録、テスト配信、公開、統計の閲覧にPlay Consoleを使います。

Account ownerまたは権限のあるAdminが「Users and permissions」から各自のGoogleアカウントを招待します。

• Account ownerは最初に登録した1人で、支払い設定など所有者だけの操作があります。
• Adminは利用者招待や権限管理ができますが、全アプリまたは特定アプリに範囲を限定できます。
• Userには、リリース、ストア情報、統計など必要な権限だけを付けます。
• 一時参加者にはアクセス期限を設定します。

招待されたメールアドレスと同じGoogleアカウントでPlay Consoleへログインします。詳しい区分はPlay Consoleのユーザーと権限を確認してください。

Apple DeveloperとApp Store Connect

iOSの開発・配布では、各自が自分のApple Accountを使います。組織としてApple Developer Programへ登録したチームでは、Account HolderまたはAdminがApp Store Connectの「Users and Access」から招待し、役割と対象アプリを設定します。

• Account Holderは1人で、契約同意、更新、重要な支払い変更を担当します。
• Adminは利用者や多くの設定を管理できます。
• App Managerは対象アプリのストア情報やリリースを管理します。
• Developerはビルドやテストに必要な範囲を担当します。
• Finance、Marketing、Customer Supportは業務に応じて分けます。

組織登録では、必要に応じて「Certificates, Identifiers & Profiles」へのアクセスも付けます。個人登録でApp Store Connectへ利用者を追加した場合、Apple Developer Programのチームメンバーと同じ範囲にはならない点に注意してください。Appleの役割一覧

招待を受けた人はApple Accountで承認し、MacのXcodeでSettings > Accountsから同じアカウントを追加します。プロジェクトのSigning & Capabilitiesでは、正しいTeamとBundle IDを選びます。Account HolderのApple AccountをXcodeへ共有登録しません。

AdMobとAdSense

AdMob

AdMobの管理者がSettings > Users > Add userからGoogleアカウントを招待し、組み込みロールまたはカスタムロールと、アクセスできるアプリを設定します。招待されるGoogleアカウントは、別の有効なAdMobアカウントに関連付けられないなどの制約があります。AdMobのユーザー追加

広告アカウントへのアクセスと、支払いプロファイルへのアクセスは別です。組織の支払いプロファイルでは会計担当をPayments userとして追加し、権限と受け取るメールを設定します。

AdSense

AdSenseの管理者がAccount > Access and authorization > User managementから招待します。招待されるGoogleアカウントは別のAdSenseアカウントとの関連に制約があります。支払い情報は組織の支払いプロファイルで別途管理します。AdSenseのユーザー追加

AdMobは主にAndroid・iOSアプリ、AdSenseはWebサイト向けです。同じアプリの全プラットフォームへ同じSDKや広告IDを入れるものではありません。

ログインと秘密情報のルール

1. 各自のアカウントでログインし、二段階認証を有効にする。
2. 復旧コードは承認されたパスワード管理サービスなどへ保管する。
3. 署名鍵、API秘密鍵、証明書の書き出しファイルはGitへ入れない。
4. 本番操作の前に、アカウント、プロジェクト、アプリID、請求先を声に出せる形で確認する。
5. 退会当日に権限を削除し、共有された鍵があればローテーションする。
6. 四半期ごとに利用者一覧、Admin、支払い通知先を棚卸しする。

やってみよう

1. チームのアクセス台帳を作り、空欄を明らかにする。
2. Firebaseへ閲覧者を1人招待し、その人のアカウントでfirebase projects:listを確認する。
3. 本番へ変更できる人、契約へ同意できる人、売上を見られる人を分けて書く。
4. 退会者が出た場合のチェックリストを作る。