ラピットくん 
ノーコード／ローコード／生成AIの普及で、社内の業務アプリを「外注しなくても作れる」場面が一気に増えました。BubbleやFlutterFlow、最近ではClaude CodeやCursorで、社員が直接アプリを書いてしまう。バックエンドとしてFirebaseを使うのも、もう特別な選択ではありません。
その流れの中で、私が現場で何度か遭遇しているのが、こういう場面です。
クライアント企業のFirebaseプロジェクトに、外部の開発者として招待してもらおうとしたら、「組織のポリシーによって制限されています」というエラーで弾かれる。クライアントが普段Google Workspaceの設定を任せている制作会社に問い合わせると、こう返ってきます。
「うちはGoogle Workspaceの担当なので、Firebaseは御社で設定してください」
一方、クライアント側はFirebaseプロジェクト自体は作ったものの、権限まわりは触ったことがなく、「メンバーを追加すればいいんじゃないですか？」で止まってしまう。結果、開発委託先・制作会社・クライアントの三者が、それぞれ「自分の領域ではない」と感じたまま、案件が動かなくなる。
これは私にはIT現場の大きな『溝』に見えています。制作会社の方は、本当によくやっていらっしゃると思います。Workspaceの設定・運用は専門領域で、その範囲を真摯に守っているからこその「うちの担当外です」という回答です。ただAI時代に入って、アプリが現場で生まれるようになった今、ここにもう一言、解決策に踏み込める制作会社の価値が一段上がっています。同時に、クライアント側も「Firebaseを作って終わり」ではなく、自分が契約しているGoogleの資産が、どこからどこまで地続きになっているのかを理解する力が必要になっていく、というのが私の見立てです。
本記事では、まずGoogle Workspace・Firebase・Google Cloudの関係を整理し、そのうえでどう解決していくかに絞って書きます。
整理：Google Workspace × Firebase × Google Cloud の関係
3つの製品名が並ぶと混乱しやすいのですが、構造はシンプルです。役割で分けると次のようになります。
- Google Workspace ＝ メール・アカウント・カレンダー・ドライブを扱う「会社のID基盤」
- Google Cloud（GCP） ＝ サーバー・データベース・ストレージなどクラウドリソースを動かす「クラウド基盤」
- Firebase ＝ Google Cloudの上に乗っている、アプリ開発向けに使いやすくパッケージ化された「アプリ向けスイート」
そして決定的なのは、この3つが同じ「組織」=Workspaceドメインの下に並んでいる、ということです。階層で書くと以下のようになります。
- Google Workspaceドメイン（例:
example.co.jp）- Google Cloud 組織（同じ
example.co.jp）- GCPプロジェクト ＝ Firebaseプロジェクト
- Google Cloud 組織（同じ
つまりWorkspaceは「メールとカレンダーの担当」ではなく、その下に並ぶクラウド全体の根っこ（組織）を握っているレイヤーです。Firebaseで「外部メンバー招待が弾かれる」というエラーは、この組織レベルで効いているポリシー（iam.allowedPolicyMemberDomains ／共有先のドメインを制限）が原因で、Workspace特権管理者の権限から地続きで編集できます。
iam.allowedPolicyMemberDomains の編集が可能になる。すべて「地続き」で繋がっている。「Firebaseは御社で」と言われた瞬間に多くの人が見落とすのが、この根っこの構造です。Firebase単体で完結する話ではなく、契約しているWorkspaceドメインを基準にすべてが組み上がっている──ここを共通認識にできるだけで、IT溝は半分ぐらい埋まります。
該当URL: https://console.firebase.google.com/project/_/settings/iam（
_ はプロジェクトIDに置換）どう解決するか：4ステップで通せる
構造が見えると、解決の道筋もシンプルです。Workspace特権管理者（あるいはその権限を付与されたアカウント）で、以下の4ステップを順に踏みます。
ステップ1：該当ポリシーを開く（が、編集ボタンが押せない）
該当URL: https://console.cloud.google.com/iam-admin/orgpolicies/iam-allowedPolicyMemberDomains
エラーの原因となっている組織ポリシー「共有先のドメインを制限（iam.allowedPolicyMemberDomains）」の詳細を開きます。プロジェクトの管理者（オーナー）として入っていても、右上の「ポリシーを管理」ボタンはグレーアウトして押せません。「管理者のはずなのに編集できない」と詰まる方が多いのがここです。
ステップ2：組織レベルのIAMで「組織ポリシー管理者」ロールを付与する
ここがGCPの仕様で最もハマる箇所です。「組織ポリシー管理者」は、プロジェクトレベルのIAM画面では選択肢に出てきません。プロジェクト単位で「組織ポリシー」と検索しても、出てくるのは「組織ポリシー閲覧者」だけです。閲覧者では編集できないので、「いくら検索しても管理者の方が出ない」と止まる方が非常に多いです。
組織ポリシーは「組織が出すもの」なので、付与も組織レベルでしか受け付けない仕様です。正しい付与手順は以下です。
- リソース マネージャーを開き、一番上に表示されている組織（例:
example.co.jp）を選択する - その状態でIAMページへ。URLに
?organizationId=XXXXXXXXXXが付いていれば組織レベルになっている - 「アクセスを許可」をクリック → プリンシパル欄にロール付与対象のメールアドレス（多くの場合は自分自身）を入力
- 「ロールを割り当てる」のプルダウンに「組織ポリシー」と入れると、今度は「組織ポリシー管理者」が選択肢に出てくる。「組織管理者」もセットで追加して保存
組織レベルのIAM画面そのものが開けない場合は、ご自身に「組織のオーナー」相当の権限が組織レベルに付いていません。Workspace特権管理者でログインし直すか、別の特権管理者から自分に「組織管理者」ロールを付与してもらうのが先になります。
ステップ3：ポリシーを編集して許可ドメインを追加する
該当URL: https://console.cloud.google.com/iam-admin/orgpolicies/iam-allowedPolicyMemberDomains（再度開く）
ステップ2でロール付与が完了したら、もう一度同じポリシー詳細を開きます。今度は右上の「ポリシーを管理」ボタンが押せる状態になっているはずです。クリックして編集モードに入ります。
C0xxxxxxxx 形式）またはドメインを入れて保存。編集パターンは2通りです。
- （1）一時的に「すべて許可」にする：短期作業向け。招待完了後にすぐ元に戻す
- （2）特定の顧客ID／ドメインを許可リストに恒久追加：継続的に共同開発するなら推奨。招待される側のWorkspace管理コンソールのアカウント設定で確認できる
C0xxxxxxxx形式の顧客IDを入れる
ステップ4：Firebase Consoleで再度「メンバーを追加」
該当URL: https://console.firebase.google.com/project/_/settings/iam
ポリシー変更が反映されるまで数十秒〜数分待ち、Firebase Consoleで再度「メンバーを追加」を実行します。今度は通ります。外部ドメインのアカウントがロールとともにプロジェクトに追加され、Firebase / GCP の各リソースにアクセスできる状態になります。
もし「一時的にすべて許可」のパターンを採った場合は、招待完了後すぐにポリシーを元に戻すのを忘れずに。「ルールを削除 → 親のポリシーから継承」を選び直すと、組織全体の制約が復活します。セキュリティ事故の温床になりやすいので、クローズ手順を必ず作業フローに含めます。
この溝を双方が一歩ずつ越える、というのが私の主張です
4ステップを書いてきましたが、私が一番言いたかったのは、手順そのものではありません。冒頭で書いた「IT溝」の話に戻ります。
Workspaceを担当している制作会社にとって、この4ステップは決して「手を出せない領域」ではありません。Workspace特権管理者の権限から地続きで到達できる作業です。ロールの付与・剥奪を一時的に行う運用さえ整えれば、Workspace本体と同じ感覚で扱えます。「Firebaseは管轄外」と一度で線を引かず、「組織ポリシーの一時開放で対応できますよ」ともう一言踏み込める制作会社の価値は、AI時代に明確に跳ね上がります。
そしてクライアント側も、Firebaseを使う以上、自分が契約しているGoogleの資産がどう積み上がっているかを一定以上は理解しておく必要があります。最低限、次の3点だけでも頭に入っていると、AI時代に増える共同開発の場面で止まらなくなります。
- 自社のGoogle Workspaceが誰の名義で契約され、特権管理者は誰か（自社内なのか、外部制作会社なのか）
- Workspaceは「メール・カレンダーの担当」ではなく、Google Cloud・Firebaseまで含めたクラウド全体の根っこを握っていること
- 外部メンバーを招待する場面が来たら、まずWorkspace担当者に投げる（依頼テンプレは下に置きました）
制作会社が「もう一言」、クライアントが「一定の理解」。この2つが双方で揃ったときに初めて、AI時代の現場アプリ開発は本来のスピードで動きます。逆に、どちらか片方が止まると、案件はそのまま止まります。私はこの溝を、双方が一歩ずつ越えていけるテーマだと考えています。
依頼の文面テンプレ（クライアント→制作会社）
クライアント側から制作会社に依頼するときの文面は、以下くらいの粒度があれば十分です。テンプレとしてご自由にお使いください。
弊社の開発委託先（◯◯株式会社、ドメイン:
dev.example.com）のアカウントを、当社のFirebaseプロジェクトに「編集者」として招待したいです。試したところ「組織のポリシーによって制限されています」というエラーで弾かれました。GCPの組織ポリシー
iam.allowedPolicyMemberDomains（共有先のドメインを制限）が原因と思われます。以下のいずれかの作業をお願いできますか？
- 一時的に組織レベルの当該ポリシーを「すべて許可」に編集し、招待完了後に元に戻す
- 招待先のドメイン（または顧客ID
C0xxxxxxxx）をホワイトリストとして恒久的に追加する作業に必要なGCPロールは「組織管理者」「組織ポリシー管理者」の2つです。組織ポリシー管理者は組織レベルのIAMでしか付与できない点にご注意ください。Google Workspace特権管理者の権限から付与可能です。
返信の文面テンプレ（制作会社→クライアント）
逆方向、つまり制作会社がクライアントに返信するときの文面も並べておきます。業務範囲がGoogle Workspace本体だけ、ということ自体は何も悪いことではありません。ただ、AI時代に入ってFirebase周りの相談が増えてきた今、いきなり「弊社の業務範囲外です」と返すよりも、なぜそうなっているか・どこまでなら踏み込めるか・誰に頼めばいいかを一言添える方が、クライアントから見た御社の価値はずいぶん変わります。
以下、「できません」ではなく「もう一歩踏み込む」返信のテンプレ案です。社内の対応スタンスに合わせて、選択肢を増減してご利用ください。
◯◯様
ご依頼ありがとうございます。Firebaseプロジェクトへの外部メンバー招待の件、承りました。
ご認識のとおり、Firebaseは弊社の主たる管理範囲（Google Workspace）の外側にあるGoogle Cloud Platform（GCP）のサービスです。ただし、今回お困りの「組織のポリシーによって制限されています」というエラーは、Workspaceの組織配下にあるGCPの組織ポリシー（
iam.allowedPolicyMemberDomains／共有先のドメインを制限）が原因で発生しています。このポリシーは、弊社が管理しているGoogle Workspace特権管理者の権限から地続きで編集できる範囲にあります。弊社で対応可能な選択肢を3つお伝えします。
【選択肢A】弊社で組織ポリシーを一時的に開放（推奨）
- 弊社のWorkspace特権管理者から、GCPの「組織管理者」「組織ポリシー管理者」ロールを一時的に貴社のご担当アカウントに付与
- 貴社（または開発委託先）側で組織ポリシーを編集し、招待を完了
- 招待完了後、弊社でロールを剥奪し、ポリシーを元の制約に戻す
- 想定作業時間: 約30分／費用: ◯◯円
【選択肢B】特定ドメインのホワイトリスト化（恒久対応）
- 招待先のドメイン（または顧客ID
C0xxxxxxxx）を、組織ポリシーのホワイトリストとして恒久的に追加- 以降、同じドメインのアカウントは追加作業なしで招待可能になります
- 想定作業時間: 約1時間／費用: ◯◯円
【選択肢C】GCP専門パートナーのご紹介
- 今後Firebase / GCPの設計・運用まで本格化される場合は、弊社の業務範囲を超えますので、提携するGCP専門パートナーをご紹介します
ご都合のよい選択肢を教えていただければ、すぐに着手いたします。なお、Workspace組織ポリシーは設定次第でセキュリティ事故の温床になりやすいため、選択肢Aの場合は招待完了後に必ずポリシーを元の状態に戻す手順を作業フローに含めて運用いたします。
よろしくお願いいたします。
ポイントは、「Firebaseは管轄外」で終わらせず、(1)なぜそうなっているか／(2)弊社で踏み込める範囲／(3)範囲を超える場合の紹介先の3点を1通の中に並べることです。これだけで、クライアントから見た御社の立ち位置は「Workspaceの設定担当」から「Google周りの相談窓口」に上がります。
返信の文面テンプレ（制作会社→クライアント・スコープ外として丁寧にお返事する版）
もう一つ、こちらは「どうしてもWorkspace本体の業務範囲を超えない」と決めている制作会社向けの返信テンプレ案です。GCP／Firebaseの設計や運用には踏み込まない、と明確に線を引きたい場合でも、いきなり「業務範囲外です」で終わらせるのは惜しい。なぜそうなっているか・クライアントが次にどう動けばよいかを一言添えてあげると、御社のスコープを維持したまま、関係はむしろ深まります。
◯◯様
ご依頼いただきありがとうございます。Firebaseプロジェクトへの外部メンバー招待の件、承知いたしました。
結論として、弊社の業務範囲はGoogle Workspace本体（メール・アカウント・カレンダー・ドライブ等）までとさせていただいており、Firebase ／ Google Cloud Platform（GCP）の組織ポリシー編集やIAMロール設計は、弊社のサポート対象外となっております。誠に申し訳ございません。
ただ、今回のエラーは弊社が管理しているWorkspaceドメインと地続きの設定が関係しているため、解決の道筋だけ簡単にお伝えします。
■ エラーの正体
「組織のポリシーによって制限されています」というFirebaseのエラーは、GCPの組織ポリシーiam.allowedPolicyMemberDomains（共有先のドメインを制限）が原因です。デフォルトで、自社ドメインのアカウントしかIAMロールに追加できない設定になっています。■ 解決に必要な権限
このポリシーを編集できるのは、GCPの「組織ポリシー管理者（Organization Policy Administrator）」ロールを持つアカウントだけです。プロジェクトレベルのIAMでは付与できず、組織レベルのIAMで付与する必要があります。■ 次に取るとよい行動（3つの選択肢）
- GCP／Firebaseを専門に扱うパートナーへ別途ご依頼いただく（必要であれば、弊社が知る範囲でご紹介可能です）
- 貴社内のエンジニアまたは開発委託先に対応を依頼する（弊社のWorkspace特権管理者ロールから、組織レベルのIAM編集権限のみを一時的に貴社のご担当アカウントに付与することは可能です。お申し出ください）
- 本件の構造と4ステップの解決手順を解説した記事を、ご参考までにお送りいたします：Firebaseの権限は誰の担当か——AIで増える依頼とWorkspaceベンダーが踏み込める範囲
弊社の業務範囲外となり恐縮ですが、上記のいずれかでご対応が進めば幸いです。Workspace本体に関するご相談は引き続き承っておりますので、何かありましたらお声がけください。
よろしくお願いいたします。
このメールがなぜ「親切」かというと、業務範囲を明確に守りつつも、(1)エラーの正体／(2)権限の所在／(3)次に取れる選択肢の3点をきちんと書き添えているからです。特に選択肢2は、Workspace特権管理者の権限から「組織レベルIAMの編集権限だけ」を一時的に貸し出す形なので、Workspace本体の業務範囲を超えずに、貴社の窓口価値だけは残せます。「うちはWorkspaceまで」を貫きながら、クライアントに残せる最後の親切として使ってみてください。
関連コンソールへのリンク
本記事で登場した管理画面の入口を、操作順に並べておきます。
Firebase Console
- Firebase Console トップ
- プロジェクト設定 → ユーザーと権限（ステップ1の起点／ステップ4の通過点）
Google Cloud Console（GCP）
- リソース マネージャー（ステップ2の入口）
- IAM（ステップ2の本番）
- 組織のポリシー一覧
- 共有先のドメインを制限（詳細／編集）（ステップ1・ステップ3）
Google Workspace 管理コンソール
まとめ
- AIで現場のアプリ開発が当たり前になり、Firebaseが中小企業にも近づいた
- Google Workspace ＝ ID基盤、Google Cloud ＝ クラウド基盤、Firebase ＝ アプリ向けスイート。3つは同じ組織（=Workspaceドメイン）の下に並んでいる
- Firebaseの外部招待エラーは、組織レベルの
iam.allowedPolicyMemberDomainsが原因。Workspace特権管理者の権限から地続きで編集できる - 解決は4ステップ：(1)ポリシーを開く →(2)組織レベルIAMで「組織ポリシー管理者」を付与 →(3)ポリシーを編集 →(4)Firebaseで再度メンバー追加
- 「組織ポリシー管理者」は組織レベルのIAMでしか付与できない。プロジェクトレベルでは選択肢に出ない
- 制作会社は「Firebaseは管轄外」で止めず、もう一言踏み込む価値が大きい時代
- クライアントも「Workspaceがクラウド全体の根っこ」と理解しておく必要がある
- この溝を双方が一歩ずつ越えていく、というのがAI時代の共同開発の前提
最後に：AIで中小企業がクラウドを触る時代に
本記事を書いた一番の理由は、ここから先、AIの普及で「中小企業が自社でデータベースやクラウドリソースを触る」場面がますます増えていくと確信しているからです。生成AIが社員ひとり一人にアプリ開発の手段を渡し、Firebaseや他のクラウドサービスが、ごく当たり前にビジネスの現場に入り込んでいきます。
そのとき、Workspaceを任されている制作会社も、Firebaseを作ったクライアントも、それぞれがスコープを一方的に主張してしまうと、案件は止まり、信頼は静かに削れていきます。「うちはここまで」「こっちもそこまでは分からない」が両側で起きると、間に立つ外部開発者・社員が一番割を食う、という構図が繰り返されます。
逆に、双方がほんの一歩ずつ踏み出して、構造の共通認識と「次にどう動くか」のテンプレを持っているだけで、AI時代の現場アプリ開発は本来のスピードで動きはじめます。本記事はそのための小さな共通言語をつくりたくて書きました。制作会社にも、クライアントにも、それぞれの立場でお役立ていただければ幸いです。
