Content last updated 2026-05-08

ユーザーに代わって変更とアクションを実行する

GitLab.com ユーザーに代わって変更を加えるかアクションを取るというリクエストへの対応のためのワークフロー

概要

このワークフローは、サポートチームが GitLab.com ユーザーに代わってアクションを実行する必要があるときのプロセスに焦点を当てています。

ユーザーに代わってアクションを実行する必要がある主な状況:

  1. プロジェクト／グループの変更
  2. アカウントアクセスのリクエスト
  3. メールアドレスの解放
  4. Enterprise ユーザーのプライマリーメール変更
  5. SCIM や SAML の構成ミスによりログインできないユーザーのアカウント変更

ユーザーアクションを最優先

「GitLab のあなたのプライベートリポジトリへのアクセス」に関するセキュリティポリシー に従い、可能な限りアクションは常にユーザー自身が行うべきです。

例えば、ユーザーは自分のプロジェクトを自分で削除すべきですが、すべての試行でエラーが発生し回避策がない場合は、サポートが 許可を得て 介入できます。

判断に迷う場合は、サポートマネージャーにレビューを依頼してください。

プロジェクト／グループの変更

サポートがトラブルシューティング目的などでプロジェクトやグループに対してアクションを取る必要がある場合、サポートは 2 つのことを行うべきです:

  1. ユーザーがグループの Owner またはプロジェクトの Maintainer であることを確認します。そうでない場合、Owner／Maintainer に連絡してもらうようユーザーに依頼します。
  2. アクションを取る許可を求めます。以下の 許可を求める セクションを参照してください。
  3. 将来的にサポートがアクションが取られたことを知る必要があるかもしれない場合は、グループの管理ページに Admin Note を追加することを検討します。

Owner／Maintainer が許可を提供したら、それが希望であれば元のリクエスターと作業を続行できます。

アカウントアクセスのリクエスト

ユーザーがアカウントへのアクセスを失った場合、まず他のすべてのオプション（SSH リカバリーコード、パスワードリセットなど）を尽くす必要があります。

未確認のアカウントの場合、サポートが通常取るアカウントアクションは メールタイプミスの修正 のみです。

確認済みアカウントに対していかなるアクションを取る前にも、アカウント所有権の確認 ワークフローを使用してアカウントオーナーを確認していることを確認してください。

所有権が確認できたら:

  1. 変更の許可を確認 します。
  2. ユーザーのアカウントに Admin Note を追加します。

例:

  • ユーザーアカウントに紐づいた ID の削除。これらの場合は ID も検証する必要があります。
  • セキュリティメールが何らかの理由で配信できない場合などに、有償ユーザーのアカウントへのセカンダリーメールアドレスの追加。

メールアドレスの解放

アカウントアクセスのリクエスト と同様に、ユーザーがアカウントへのアクセスを失い、そのアカウントの履歴に アクティビティがない 場合、ユーザーが新しいアカウントを作成するためにメールアドレスを解放することを検討できます。

このワークフローは、ユーザーがメールアドレスをアカウントに追加できないときにも使用できます。これは、そのメールが別のアカウントにあり、かつ 未検証である場合です。これは、ユーザーがシングルサインオン登録方法のいずれかを使用して誤ってアカウントを作成した、またはアカウントを作成したことを思い出せない場合によく発生します。

未検証／未確認のアカウントの詳細については、confirmation emails ワークフローを参照してください。

プライマリーおよびセカンダリーメールは、有償ユーザーに対してのみ、以下のいずれかのプロセスに従って解放できます。

未検証のセカンダリーメールアドレスの解放

  1. メールアドレスが未検証のセカンダリーメールアドレスであることを確認します。
  2. チケットリクエスターのメールが一致しない場合、お客様にセカンダリーメールからチケットにコメントするよう依頼してメール検証を行います。
  3. ユーザーがメールアドレスを所有していることを確認するために返信したら、アカウントからセカンダリーメールを削除します
  4. ユーザーのアカウントに Admin Note を追加します: 2024-01-30 | removed secondary unverified email address from the account [email protected]| https://gitlab.zendesk.com/agent/tickets/
  5. ユーザーに、メールアドレスが解放されたので新しいアカウントの作成に使用できると返信します。

非アクティブなアカウントのメールアドレスの解放

アカウントのステータスと所有権の確認

ユーザーのアクティビティページを確認します:

  1. 任意のタイプの貢献（スニペット、プロジェクトやグループ内のコメントなど）に関連するアクティビティがアカウントに表示される場合、アカウント所有権の確認 ワークフローを使用して所有権を確認します。
  2. アカウントに アクティビティが表示されない 場合:
    1. ユーザーが追加しようとしているメールアドレスが別のアカウントに存在することを確認します。
    2. アカウントに アクティビティがなく、いかなるプロジェクトやグループのメンバーでもないことを確認します。さらに、以下が真であることを確認します:
    • ユーザーは未検証
    • ユーザーは一度もログインしていない
    • ユーザーにデータがない（グループまたはプロジェクトがない）
  3. アカウントが 検証済み であるかデータが存在する場合、メールが解放対象 でない ことを元のリクエスターに伝えます。必要であれば、アカウント削除をリクエスト できます。

メール解放の対象になる場合

  1. 該当する場合、新しいメールアドレスを CC としてチケットに追加し、追加したいメールアドレスからチケットに返信するようユーザーに依頼します。
  2. ユーザーがメールアドレスを所有していることを確認するために返信したら、メールアドレスを +release で更新します。例えば、メールアドレスが [email protected] の場合、アカウントのメールアドレスを [email protected] に更新します。
    • これは Admin アクセスまたは Chatops 経由 で実行できます
    • UI を通じて解放を行う場合、元のメールをセカンダリーメールのリストから削除する必要があります。 Chatops はこれを自動的に処理します。
  3. ユーザーのアカウントに Admin Note を追加します。
  4. お客様に、新しく解放されたメールアドレスをプライマリーアカウントに再度追加するよう案内します。
  5. この feature request にコメントすることを検討します

Enterprise ユーザーのプライマリーメールアドレスの変更

Enterprise ユーザーは プライマリーメールアドレスを未検証ドメインのメールに変更できません。Enterprise ユーザーは、検証済みドメインに従って組織が所有するメールアドレスにのみプライマリーメールを変更できます。Enterprise ユーザーまたはトップレベルグループのオーナーは、プライマリーメールアドレスの変更をリクエストするためにサポートに連絡できます。 プライマリーメールアドレスをグループドメイン検証の一部ではないメールに変更すると、ユーザーが切り離されます: ユーザーは Enterprise ユーザーではなくなります。

トップレベルグループオーナーからのリクエスト

Issue 412966 が実装されるまでは、トップレベルグループのオーナーは Enterprise ユーザーのプライマリーメールアドレスを変更できません。トップレベルグループのオーナーはサポートに 1 人以上の Enterprise ユーザーのプライマリーメールアドレスの変更をリクエストできます。

  1. アカウント認証マトリクス で適格性を確認します。

  2. アカウント所有権検証ワークフロー を使用して所有権を確認します。

  3. admin アカウントから Pages Domain API を使用して、新しいメールドメインが別のグループによって検証されているかを確認します。検証されている場合は、チケットに 内部ノート を追加します。

  4. マネージャーの承認を得て続行し、お客様に返答します:

    Greetings,

    Thank you, we were able to verify your identity as account owner.

    Could you please confirm that you would like us to change the enterprise user primary address from [email protected] to example@new-primary-email address? Replying in this ticket stating you provide permission will be sufficient.

    Important notice: Changing an enterprise user’s primary email to an email with a non-verified domain automatically disassociates them from their enterprise group. As a result of the change, your organization will not be able to manage the user account and GitLab Support will not intervene for any reason.

    If this domain is verified by another organization: Updating a user’s primary email address to an email with a domain that is verified by another organization can result in the user being claimed as an enterprise user of the other organization. If the organization has restricted authentication methods, the user may lose access to their account.

  5. UI と admin アカウントを使用して Enterprise ユーザーのプライマリーメールアドレスを更新し、ユーザーのアカウントに Admin Note を追加します。

  6. 変更するユーザー数が手動修正には実用的でない量の場合は、コンソールエスカレーションリクエスト を作成し、このスニペット を使用するよう依頼することを検討します。

グループに所属しているかもしれない／していないかもしれない Enterprise ユーザーからのリクエスト

Enterprise ユーザーは、GitLab サブスクリプションを購入した組織によって管理されるユーザーアカウントを持っています。これは、サポートがトップレベルグループのオーナーの 1 人からの明示的な許可なしにアクションを取らないことを意味します。

  1. admin アカウントから Pages Domain API を使用して、新しいメールドメインが別のグループによって検証されているかを確認します。検証されている場合は、チケットに 内部ノート を追加します。

  2. ユーザーに最初の応答を送信します:

    Greetings,

    Your account is an enterprise user account, enterprise users cannot modify their primary email address to an email with a non-verified domain. An enterprise user can only change their primary email to an email their organization owns as per its verified domains.

    Updating your primary email address to an email with a non-verified domain will automatically disassociate you from your enterprise group. If the new domain is verified by another organization and your account meets the criteria after the email change, it will be claimed as an enterprise user of the organization that owns the new domain.

    If you still wish to update your primary email address, please note it will require involvement of a top level group owner. Please let us know if you wish to proceed.

  3. 続行したいと回答した場合、アカウント所有権検証ワークフロー を使用して所有権を確認します。

  4. プライマリーメールが唯一の検証済みメールである場合は、続行するためにマネージャーの承認を求めます（メール交換リクエストの場合はこのステップをスキップします）。

  5. 成功した場合、Owner に連絡します:

  • チケットとユーザーを作成するための特定のワークフロー に従って、トップレベルグループのオーナーのメールアドレス（admin で見つかる）をリクエスターとして新しい Zendesk チケットを作成します

  • 新しいチケットが適切にルーティングされ、連絡したいエンドユーザーに正しい通知が送信されるよう、General::Outbound Contact Request マクロを適用します。

  • 以下のスニペットをコピーし、チケットを On-hold としてマークします:

    Hi,

    We’re contacting you because we’ve received a request from one of your enterprise users to modify their primary email address to an email address with a domain that is verified by another organization. This will disassociate the user from your organization.

    If this domain is verified by another organization: Updating a user’s primary email address to an email with a domain that is verified by another organization can result in the user being claimed as an enterprise user of the other organization. If the organization has restricted authentication methods, the user may lose access to their account.

    As you will lose any current and future administration of the user account following this change, we are asking for your permission.

    Replying in this ticket stating you provide permission will be sufficient.

  • リクエスターのチケットへのリンクを提供する内部コメントを作成します。

  • グループに複数のオーナーが含まれる場合、1 人のオーナー（できれば既存のサポート連絡先）をリクエスターとして選び、他のオーナーを CC します。5 人を超える場合は 5 人に制限します（https://gitlab.com/groups/<group_name>/-/group_members ページで Last activity が最も新しいオーナー、および／または Source としてリストされているオーナーを選べます）。

  1. リクエスターのチケット:

    • 上記で作成したチケットへの内部コメントを追加します。
    • 以下のスニペットでリクエスターに返答し、チケットを On-hold としてマークします。

    Hi,

    Thanks for verifying your account with us. We are now waiting for permission from your organization to release the account by updating your primary email address. We will keep you updated.

  2. オーナーの 1 人が承認した場合、該当する場合はセカンダリーと交換することで Enterprise ユーザーのプライマリーメールアドレスを更新します。

  3. ユーザーのアカウントに Admin Note を追加します。

アカウント所有権の変更

GitLab とビジネス関係を持つ会社から所有権の変更をリクエストできる条件は限定されています。詳細については GitLab の Ownership Dispute Policy を参照してください。

リクエストが成功した結果、ネームスペース内の新規または既存のユーザーに Owner 権限が付与され、必要に応じて他のユーザー権限を調整できるようになります。

有償グループのアカウント所有権変更リクエスト

GitLab の Ownership Dispute Policy に従い、アカウント所有権変更リクエストは、グループの唯一のオーナーが会社を退職し、会社の権限のある代表者がコントロールを取り戻そうとする場合に開始されます。このプロセスは最後の手段であるべきで、まずセルフサービスのオプションを検討する必要があり、有償プランの GitLab.com グループに適用されます。

リクエストを受け取った場合、以下を確認します:

  1. 現在の有償サブスクリプションがネームスペースに適用されている。
  2. 唯一のオーナーのプライマリーメールアドレスが会社のドメインと一致する。
  3. リクエスターが GitLab.com アカウントを持つ。通常、このユーザーはすでにメンバーですが Owner ではありません。

リクエスターがすべてのセルフサービスのオプションを使い切ったことを確認します:

  • 既存のオーナーのアカウントが 2FA を有効化していない場合、リクエスターに既存のオーナーのアカウントにパスワードリセットを発行し、アカウントをクレームする よう提案します。
  • 既存のオーナーのアカウントが 2FA を有効化している場合、リクエスターに既存のオーナーに連絡して、リクエスターがアクセスを取り戻して アカウントをクレームする ためにワンタイムパスワード、バックアップコード、プライベート ssh キーを既存のオーナーから提供してもらうよう提案します。

セルフサービスのオプションが実行可能でない場合、以下の手順に従います:

  1. 可能であればアカウントオーナーまたはアカウントマネージャーを CC に追加して、Support::SaaS::Gitlab.com::Account Ownership Change Request (Self-Service Not Possible) マクロ を使用します。
  2. リクエストされたドキュメントを受け取ったら、すべての必要な情報が含まれていることを確認します。そうでない場合は、リクエスターにフォローアップして未解決の情報を取得します。必要な情報が取得できたら、慎重に次の手順に従います。
  3. リクエストを評価して以下の基準が満たされているかを確認します:
    1. セルフサービスのオプションが提案されたが実行可能でない。
    2. リクエストされたドキュメントが完全かつ正確に記入されており、適切なレターヘッドにある。
    3. 既存のオーナーが過去 90 日間アクティブでない。
    4. リクエスターが既存のオーナーと同じ顧客メールドメインのメールアドレスを使用している。
    5. リクエスターがグループ内ですでに Maintainer ロールを持つ。
    6. 独立したオンライン検索分析が、提供された情報を裏付ける（既存のオーナーがもはやお客様のために働いていない、リクエスターと署名者が組織で持つロールと役職、リクエスターと既存のオーナーの間の内部紛争の兆候がない、など）。
  4. すべての基準が満たされている場合: リクエスターを Owner ロールに昇格させます。
  5. いずれかの基準が満たされていない場合:
    1. Legal and Compliance プロジェクト で Group Owner Change issue を新規作成します。
    2. Issue へのリンクを Zendesk チケットに追加します。
    3. Legal::General マクロ を使ってリクエスターに返信し、チケットを「On-Hold」に設定します。On-Hold チケットがオープンに戻った後（4 日後）に返信を受け取らない場合、#legal Slack チャンネル で連絡します。
    4. Legal から承認を受け取った後、リクエスターを Owner ロールに昇格させます。
  6. グループの管理ページに Admin note を追加します。

リクエスターを Owner ロールに昇格させる方法

  1. GitLab Admin Account を使用して、リクエスターの「Namespace - Group - Members」セクションに移動します。
  2. 名前またはメールアドレスでメンバーを検索し、Max role 列でリクエスターのロールを Owner に変更します。
  3. リクエスターがグループのメンバーでない場合は、右上の Invite members ボタンを押し、リクエスターのメールアドレスを入力し、ロールを Owner に設定します。Invite ボタンを押して変更を保存します。

トラブルシューティングのための許可はどうやって与えられるか？

サポートチームは、Issue の解決に必要でない限り、いかなるプライベート情報も閲覧しません。通常、Issue は 「GitLab のあなたのプライベートリポジトリへのアクセス」に関するセキュリティポリシー で概説されているように、トラブルシューティング目的でアカウント保有者（ユーザー向け）またはネームスペースの有効なメンバー（プロジェクトとグループ向け）によってサポートチケット経由で提出されます。

サポートチームメンバーは、リクエストで明示的に言及されていないページの情報を見ることがありますが、レビューの範囲は問題を解決するために必要な最小限のアクセスに制限されます。

サポートチームは、リクエスターが以下に当てはまる場合にのみリクエスターからのアクションを受け付けます:

  • ネームスペースのメンバーである。
  • サポートが調査する必要がある問題を持つ。
  • ネームスペースへのリンクを提供する。
    • このリンクは初期フォーム提出またはチケットへの返信から提供できます。

私たちは、Issue を調査する際に関連するビューとログに焦点を当てるため、ユーザーが特定のリンクを提供することを期待しています。例えば、CI/CD エラーを調査するリクエストには、関連するジョブログ、パイプライン、および／または CI YAML ファイルへのリンクを含める必要があります。

ユーザーデータをダウンロードする必要がある場合（リポジトリのクローンなど）、または機密情報を明らかにする必要がある場合（CI/CD 変数 など）、トラブルシューティングをさらに進めるためには、続行する前に 明示的な許可 が必要です。再現目的でダウンロードされたユーザーデータは、Issue が解決された時点で削除する必要があります。例えば、zd-dl-wiper ツール を使って削除できます。

許可を求める

いかなるアクションを取る前にも、必要なアクションを取るための明示的な許可をリクエストしてください。混乱がないようにできるだけ具体的にしてください。

ユーザーから許可が確認されたら、進めることができます。

サンプルフレーズ:

Could you please provide permission for Support to … ?

または

Could you please confirm that you would like us to … ?

例:

Could you please provide permission for Support to re-run one or more pipelines in project xyz to investigate the issue you’ve described? Replying in this ticket stating you provide permission will be sufficient.

Could you please provide permission for our Support Engineers to look at the CI/CD variables in the project so that we confirm they are correct? Replying in this ticket stating you provide permission will be sufficient.

Could you please confirm that you would like us to exchange your primary address [email protected] and secondary address [email protected] on your account? Replying in this ticket stating you provide permission will be sufficient.

なりすまし

ユーザーへのなりすましは別のアカウントとしてアクションを実行することとみなされます。なりすましは、なりすまされたユーザーの Current sign-in IP と Current sign-in at を更新します。

ユーザーになりすますとき、管理者アカウントは SIRTbot アプリから、なりすましが正当なアクションだったかを確認するための Slack メッセージを受け取ります。

なりすましのアクションは サブスクリプション契約の機密性条項 に準拠しています。

SCIM や SAML の構成ミスによりログインできないユーザーのアカウント変更

ユーザーが IdP によって再プロビジョニングされるためにユーザー名を変更したりアカウントを削除するためにサポートに連絡してきた場合、まず常にセルフサービスのオプションに戻してください:

セルフサービスのオプション

  • パスワードリセットを使ってユーザー名／パスワードで認証し、ユーザーがセルフサービス削除を使用するか、ユーザー名を自分で変更できるようにします。
  • または、トークン化された GitLab シングルサインオン URL を使ってグループに直接ログインすることで、ユーザーの既存のアカウントを SAML ID にリンクし、アカウントを削除しないようにします。

パスワードリセットが受信されない場合

トップレベルグループで 「Disable password authentication for enterprise users」 オプションが有効化されているためにユーザーがセルフサービスできない場合、以下の手順に従ってください:

  1. トップレベルグループで「Disable password authentication for enterprise users」が有効になっていることを確認します。
  2. オーナーにグループでこのオプションを一時的に無効化するよう依頼して、ユーザーがアクセスを取り戻せるようにします。
  3. オーナーが拒否した場合は、アカウント所有権の確認 ワークフローに進みます（Enterprise ユーザーアカウントの変更については、所有権検証はトップレベルグループのオーナーが行う必要があります）。
  4. 検証が成功した後、アカウントへの変更を加える許可を求めます。削除リクエストの場合、コントリビューションを含むユーザー削除は 有償ネームスペースの Issue とマージリクエストの削除につながる可能性がある ため、シンプル削除（ユーザーのみ）を行います。
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License