環境グループは、1 つ以上のホスト名を持つ環境のグループです。ホスト名は、環境グループ内の任意の環境にデプロイされた API プロキシの呼び出しに使用される URL の一部です。
API プロキシ
API プロキシは、受信リクエストとバックエンド サービスの間のインターフェースです。プロキシ エンティティには、クライアントからのリクエストとバックエンドからのレスポンスを処理する際に Apigee が実行する手順とポリシーが含まれます。
API プロダクト
API を公開するためのエンティティ。API プロダクトは、外部の開発者が使用できるようにデベロッパー ポータルに公開されます。API プロダクトは、1 つ以上の公開 API にアクセスするためのインターフェースを提供します。インターフェース（OpenAPI 仕様を使用して記述できます）には、1 つ以上の API プロキシによって処理される 1 つ以上の API リクエストの組み合わせを含めることができます。
API プロダクトは、組織内のユーザーが作成します。その際、各 API プロダクトに任意のメタデータを追加できます。よく使用されるタイプのメタデータの 1 つでサービスプランを定義できます。このサービスプランでは、API 呼び出しのアクセス制限の指定、セキュリティ要件の規定、モニタリングと分析の許可、追加機能の提供を行えます。
API プロダクトの分析用のデータは、Apigee により収集されます。
API プロバイダ
API プロキシとプロダクトを作成および管理する個人またはエンティティ。これらの公開された API には、クライアントのアプリ開発者がアクセスします。
アプリ開発者
組織には、組織が定義した API（API プロダクトとして公開）を使用するアプリを構築する 1 人以上の開発者が属します。開発者は API を使用しますが、組織内で API の作成などのアクションは行えません。
開発者は、組織に登録された後、アプリを登録して API にアクセスするための API キーなどのクライアント認証情報を受け取る必要があります。API プロバイダとして、組織内の開発者を追加、更新、削除する方法をご自身で決定する必要があります。UI を使用して手動で追加する方法、ウェブサイトで登録するためのデベロッパー ポータルを作成する方法、または Apigee API を使用して独自の登録メカニズムを定義して実装する方法のいずれかを選択できます。
Apigee アプリ（またはアプリ）
API を使用するクライアント アプリは、Apigee 開発者が 1 つ以上作成します。
認証情報のチェックを必要とする API（API キーや OAuth トークンなど）を呼び出すクライアント アプリケーションを作成する開発者は、まず組織でのアプリ登録を作成する必要があります。アプリを登録すると、クライアント アプリケーションが API を呼び出す際に使用する必要がある API キー、キーとシークレットのペア、その他の認証情報が開発者に提供されます。
すべてのアプリが組織に登録されているため、アプリと API の使用に関する分析情報は Apigee でモニタリングおよび収集できます。
Apigee は、シンプル API キー、Two-legged OAuth、3-legged OAuth など、さまざまな種類の認証をサポートしています。
API プロバイダが認証メカニズムとして API キー検証を指定している場合、クライアント アプリケーションは API へのリクエストごとに API キーを渡す必要があります。そのキーが有効な場合、Apigee はリクエストを許可します。または、API プロバイダが認証メカニズムとして OAuth トークン検証を指定している場合、クライアント アプリケーションはまず OAuth トークンを取得してから、API に対するすべてのリクエストでそのトークンを渡す必要があります。そのトークンが有効な場合、Apigee はリクエストを許可します。他のカスタム認証スキームが使用される可能性があります。
API プロバイダは、開発者が自分のアプリを登録する方法を定める必要があります。各アプリ登録には、1 つ以上のキーまたは認証情報が関連付けられます。開発者がデベロッパー ポータルを介して独自のアプリケーションを登録できるようにした場合、開発者は、便利なセルフサービス エクスペリエンスを介して、API へのアクセスに必要なキーまたは認証情報を取得できます。
開発者は、アプリの登録時に単独の API プロダクトにアクセスするか、複数の API プロダクトにアクセスするかを選択できます。開発者のアプリでアプリに関連付けられているすべての API プロダクトにアクセスするには、同じキーまたは認証情報を使用します。
キーを取り消して開発者のアプリが API にアクセスできないようにすることは、いつでも（開発者によるアプリの登録済み表現が組織内に存在する場合も）可能です。また、開発者を取り消すこともできます。この場合は、対象の開発者に登録されているアプリのすべての認証情報が使用できなくなります。取り消しは元に戻すことができます。Apigee がアプリ認証情報を作成するときに有効期限を指定すると、開発者は特定の期間後に新しいキーまたは認証情報を取得する必要があります。
Apigee ユーザー
Apigee ユーザーは、組織の API チームの構成し、そのチームに、管理者、API プロキシおよび API プロダクトの作成者など、分析や他の統計情報をモニタリングするユーザーを含めることができます。エンドユーザーは Apigee 開発者が構築したアプリを使用するユーザーです。このドキュメントで「ユーザー」と表記した場合、通常は Apigee ユーザーを指します。
管理者はユーザーを組織に追加できます。
ユーザーに応じて、ロールやアクセス権限を変えられます。たとえば、一部のユーザーを組織管理者として定義し、組織とその構成要素を変更する権限を持たせる一方で、別のユーザーには API プロキシや API 製品を作成する権限を与えつつ、他のユーザーを変更する権限を与えないようにできます。
ユーザーは複数の組織のメンバーになることができます。たとえば、社内で同一の人物がすべての API プロキシと API プロダクトを構築しており、そのため全部の組織のメンバーである場合でも、会社は Apigee でさまざまな開発者コミュニティをサポートするための複数の組織を定義できます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-28 UTC。"],[[["\u003cp\u003eApigee organizations are top-level containers for API proxies and resources, distinct from Google Cloud organizations but mapped to a single Google Cloud project with a shared name.\u003c/p\u003e\n"],["\u003cp\u003eThere are two types of Apigee organizations: paid (production) organizations with full scalability and evaluation (eval) organizations, which are temporary and time-limited.\u003c/p\u003e\n"],["\u003cp\u003eAn Apigee organization's structure contains components such as environments, API proxies, API products, API providers, app developers, and apps, all managed within the organization's framework.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers subscription and pay-as-you-go pricing models, with entitlements and billing based on environments, API calls, and proxy deployments, and also allowing users to be members of multiple organizations.\u003c/p\u003e\n"],["\u003cp\u003eApigee users within an organization can have various roles, from administrators to API creators, and end-users access APIs through apps built by Apigee developers.\u003c/p\u003e\n"]]],[],null,["# Understanding organizations\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nAn organization is the top-level container in Apigee. The Apigee organization\ncontains all your API proxies and related resources. While the rest of this topic goes into\nmore depth about organizations, here are a few practical points:\n\n- An Apigee organization is distinct from and subsidiary to a Google Cloud organization. When you create an organization for Apigee X or Apigee hybrid, it maps to exactly one Google Cloud *project*, and the Apigee organization and Google Cloud project share a name. Not all Google Cloud projects have an associated Apigee organization.\n- Where the Apigee documentation uses the term \"organization,\" it specifically refers to an Apigee organization. The Apigee documentation uses the phrase \"Google Cloud organization\" to refer to the alternative.\n- Once created, you cannot rename an Apigee organization.\n- Your Apigee organization name is shown as the project in the URL for the Apigee section of [the Google Cloud console.](https://console.cloud.google.com/apigee/overview) For example: \n\n ```\n https://console.cloud.google.com/apigee/overview?project=ORG_ID\n ```\n- When you invoke REST calls to the Apigee API, the organization identifier is a required part of the path. For example, the following `curl` request returns a list of all API proxies in an organization using the [organizations API](/apigee/docs/reference/apis/apigee/rest/v1/organizations): \n\n ```\n curl https://apigee.googleapis.com/v1/organizations/ORG_ID/apis\n ```\n- While you may have created only one organization, you can be authorized in other organizations as a user or administrator with specific permissions. In the cloud console, you can switch to a different organization as described in [Switching between\n your organizations](/apigee/docs/api-platform/get-started/switch-org).\n\n**Note:** This video was recorded with a previous version of the Apigee UI; however, the concepts are still valid. \n**Video:** Watch a short video to learn how organizations support a\nmulti-tenancy architecture for API management. \n\nOrganization types\n------------------\n\nThere are two types of organizations:\n\n- **Paid:** A permanent organization with full scalability. Also known as a\n *production* organization. Paid organizations include those created as part of a Subscription or a Pay-as-you-go\n Apigee pricing model.\n\n- **Evaluation:** A temporary, self-service organization for testing\n Apigee. Sometimes referred to as *eval orgs*, these organizations are time-limited and\n lack the scalability and flexibility of production organizations.\n\n\nSee also [Compare eval and paid organizations](/apigee/docs/api-platform/get-started/compare-paid-eval).\n\n#### Evaluation organization lifespan\n\nEvaluation organizations have a limited lifespan:\n\n1. **Day 0:** Create the evaluation organization.\n2. **Day 30:** Google sends you an email notification warning of the upcoming expiration.\n3. **Day 60:** Google deletes the evaluation organization.\n\nApigee Organizations within the Google Cloud hierarchy\n------------------------------------------------------\n\nThe following diagram shows the relationship between Apigee organizations and environments,\nand Google Cloud projects and folders.\n\nComponents within an organization\n---------------------------------\n\nThe following image shows the major components of the Apigee organizational model.\nThis model defines how your APIs, API products, apps, and app developers are all related within\nApigee.\n\nThis model does not show all of the features of Apigee, but it is meant to show you that the\norganization is the root of a deployment.\n\nThe following table describes the components of the organizational model in more detail:\n\nAdditional components of Apigee that are not shown are the API keys and OAuth tokens.\n\nApigee supports different types of authentication, such as a simple API key,\ntwo-legged OAuth, three-legged OAuth, and others.\n\nIf the API provider specifies API key verification as the authorization mechanism, the\nclient application must pass an API key with every request to your APIs. If\nthat key is valid, Apigee allows the request. Alternatively, if the API\nprovider specifies OAuth token verification as the authorization mechanism, the client\napplication must first obtain an OAuth token, and then pass that token with\nevery request to your APIs. If that token is valid, Apigee allows the\nrequest. Other custom authorization schemes are possible.\n\nAs an API provider, you must define a way for developers to register their apps. Each\napp registration will have one or more keys or credentials associated to it. If you\nallow developers to register their own applications via a developer portal, the developer\ncan retrieve the key or credential required to access your APIs, via a convenient,\nself-service experience.\n\nAt the time of app registration, developers can choose to access a single API\nproduct or multiple API products. A developer's app uses the same key/credential to access\nall API products associated with the app.\n\nAt any time, you can revoke the key so that the developer's app no longer has access\nto your APIs (even though the registered representation of the developer's app still\nexists in your organization). Or, you can revoke a developer, in which case all of the credentials\nfor any apps registered for that developer become inoperable. Revocation is reversible.\nAt the time Apigee creates the app credential,\nyou can specify an expiry so that the\ndeveloper must obtain a new key or credential after a specific time.\n\nApigee users\n------------\n\nApigee users make up the organization's API team,\nwhich can include people such as administrators, API proxy and API product creators,\nor users monitoring analytics and other statistics. End-users are people who use the\napps that Apigee developers build. In most cases, this documentation uses the term \"user\"\nto refer to an Apigee user.\n\nAdministrators can add users to an organization.\n\nDifferent users can have different roles and access privileges. For example, define\nsome users as Organization Administrators and Operations Administrators with privileges\nto modify the organization and its components, and define other users with permissions to\ncreate API proxies and API products, but without the privileges to modify other\nusers.\n\nUsers can be members of multiple organizations. For example, your company might define\nmultiple organizations on Apigee to support different developer communities, even\nthough internally, the same people build all of the API proxies and API products and are\ntherefore members of all of your organizations.\n\nYou don't have to create an Apigee organization to be a user. An administrator\ncan add you to an existing organization.\n\nIn the Google Cloud console, go to the Apigee page.\n\n[Go to Apigee](https://console.cloud.google.com//apigee)\n\n\u003cbr /\u003e\n\nEntitlements and billing\n------------------------\n\nWhether the paid organization uses a **Subscription** or **Pay-as-you-go**\npricing model, the items that are metered for billing purposes are:\nenvironments, API calls, and proxy deployments.\n\nSubscription plans allow you to pre-pay for entitlements, in exchange for significant\ndiscounts. Subscription plans make sense at higher consumption volumes - where there are larger\nnumbers of environments, a high volume of API calls, or a large number of API proxies under\nmanagement by Apigee. Under the Pay-as-you-go model, you pay only for the resources you use, but\nyou do not enjoy volume discounts.\n\n### Subscription entitlements\n\nFor more details, see [Subscription entitlements](/apigee/docs/api-platform/reference/subscription-entitlements).\n\n\n### Pay-as-you-go entitlements\n\nFor more details, see [Pay-as-you-go entitlements](/apigee/docs/api-platform/reference/pay-as-you-go-entitlements)."]]
