ほとんどのアプリケーションは、なんらかのクライアント SDK または API URL を使用して記述されています。クライアント SDK と API URL は、特定の Looker API バージョンにバインドされています。Looker が新しい API バージョンに変更を加えても、アプリケーションは引き続き機能します。新しい Looker API バージョンを使用するようにクライアント SDK をアップグレードする（または API URL を変更する）まで、アプリケーションは他の API バージョンの変更による影響を受けません。
Looker が API を変更する仕組み
Looker API は、Looker API エンドポイントの安定性を確保し、アプリケーションの安定性を維持するように設計されています。
Looker にはさらに機能が追加されるとともに、それらの新しい機能にアクセスして管理するための Looker REST API も更新されています。Looker リリースごとに、新しい API 関数、パラメータ、レスポンス タイプのプロパティを現在のバージョンの Looker API に追加します。ほとんどの場合、API への追加は互換性を損なう変更にはならないため、API を基に構築された既存のアプリケーション コードに影響を与えることなく、既存バージョンの API を使用できます。既存のアプリケーション コードは、後続の Looker リリースで出現する新しい関数、パラメータ、機能を認識しない場合があります。
既存のアプリケーション コードとの互換性がない変更を API に加える場合は、それらの変更を新しい API バージョンにバンドルします。つまり、古い API バージョンは以前と同じように動作し、それと並行して、変更や更新を伴う新しい API バージョンが実行されます。1 つの Looker インスタンス内に複数の API バージョンが並行して存在できるため、新しい API バージョンにアップグレードするタイミングを選択できます。古いエンドポイントを呼び出すようにビルドされた既存のコードは、引き続き古いエンドポイントを呼び出します。新しいコードでは、最新の API バージョン レベルでエンドポイントの新しいバージョンが呼び出されます。
レスポンスの新しいプロパティ（レスポンスで不明なプロパティはコードによって無視されることが想定されるため、これは互換性を損なう変更とはみなされません。これは REST API コミュニティで一般的な方法です）
安定版の Looker API エンドポイントで新しいアーキテクチャや機能のために大幅な変更が必要な場合、既存の API エンドポイントが変更されないように、通常、変更は新しいエンドポイントに追加され、新しい API バージョンにバンドルされます。
API エンドポイントのフラグ
ほとんどの API エンドポイントは安定していると見なされるため、変更されることは想定されていません。Looker は、セキュリティ問題を解決するためなどの極端な場合を除き、安定したエンドポイントに対して互換性を損なう変更をリリースしません。
その他の API エンドポイントには、ベータ版または非推奨のフラグが付けられます。
ベータ版エンドポイントは現在開発中であり、今後変更される可能性があります。互換性を破る変更から保護されることはありません。ベータ版エンドポイントを使用する場合、Looker API への変更がアプリや開発サイクルを特に妨げるかどうかを考慮してください。ベータ版エンドポイントを使用する予定がある場合は、変更を認識できるように、Looker のリリースノートをご覧ください。
コンパイル済みの厳密に型指定された言語でアプリケーションが作成されている場合、既存のコードとは異なる新しい API バージョンでのパラメータ型やレスポンス型の構造変更は、コンパイル型チェックとコンパイラのエラー メッセージによりすぐにわかります。
アプリケーションが大まかに型指定された動的言語（JavaScript、Ruby、Python など）で作成されている場合、新しい API バージョンへの互換性を損なう変更によって影響を受けるアプリケーションの部分を特定するのが難しくなることがあります。これらのタイプの言語では、型の変更に関連する問題を見つけるためにランタイム単体テストが必要になる場合があります。
いずれの場合でも、Looker API の呼び出し（モック呼び出しではない）など、アプリケーション コードを実行する単体テストを用意することをおすすめします。
[[["わかりやすい","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-07-31 UTC。"],[],[],null,["# Looker API versioning\n\n| **Note:** As of Looker 22.4, the [Looker API 4.0 is generally available](/looker/docs/api-4-ga). In Looker 23.18, the [Looker API 3.1 has been removed](/looker/docs/api-3x-deprecation).\n\nMost applications are written using some form of a client SDK, or possibly an API URL. The client SDK and API URLs are bound to a specific Looker API version. Your application will continue to function even as Looker makes changes to new API versions. Your application won't be affected by changes in other API versions until you choose to upgrade your client SDK (or modify the API URL) to use the new Looker API version.\n\nHow Looker makes changes to the API\n-----------------------------------\n\nThe Looker API is architected to provide stability for Looker API endpoints, and therefore stability for your applications.\n\nAs we add more features and capabilities to Looker, we also update the Looker REST API to access or manage those new features. For each Looker release, we add new API functions, parameters, and response type properties to the current version of the Looker API. In most cases, additions to the API are not [breaking changes](#breaking_and_additive_changes), so we can keep the existing version of the API without affecting any existing application code that is built on the API. Your existing application code may simply be unaware of new functions, parameters, or features that appear in subsequent Looker releases.\n\nFor changes to the API that would break existing application code, we bundle those breaking changes into a new API version. This means that the old API version will continue to work the same as before, while a new API version runs alongside it with the changes and updates. Multiple API versions can exist side by side in a single Looker instance so that you can choose when to upgrade to the new API version. Your existing code that was built to call the old endpoint will continue to call the old endpoint. New code should call the new version of the endpoint in the most recent API version level.\n\nOne exception to this is for critical security issues. If we discover a critical security issue related to a particular part of the API, we will do whatever is necessary to mitigate that security issue as soon as possible, which may include disabling the vulnerable functionality until a proper solution is available).\n\nIf we need to retire a feature, function, or property to make way for a better implementation or solution, we normally leave the current API as it is, but mark the associated API endpoints as [\"deprecated\"](/looker/docs/api-versioning#deprecated_api_endpoints) to indicate that you should move away from the endpoint in your application code.\n\n### Breaking and additive changes to the API\n\nA *breaking* change is something that deletes or renames an existing artifact of an API endpoint. It might include:\n\n- Changing or deleting a parameter name or type\n- Adding a new required parameter\n- Changing the base URL\n- Changing or deleting an existing property in a response\n\nAn *additive* change, on the other hand, may be made to [stable](#stable_api_endpoints) endpoints. They might include:\n\n- New, optional parameters\n- New properties in responses (we do not consider this breaking because we assume that your code will ignore unknown properties in responses, which is common practice in the REST API community)\n\nIf a stable Looker API endpoint needs a significant change to move forward with new architecture or functionality, the change is usually added to a new endpoint and bundled into a new API version so that the existing API endpoint remains unchanged.\n\n\nFlags for API endpoints\n-----------------------\n\nMost API endpoints are considered *stable* , meaning they are not expected to change. Looker will not release [breaking changes](#breaking_and_additive_changes) to stable endpoints except in extreme cases, such as to fix a security problem.\n\nOther API endpoints may be flagged as *beta* or *deprecated*:\n\n- **Beta endpoints** are in active development and may change in the future. They are not protected from breaking changes. When using beta endpoints, consider whether a change to the Looker API would be particularly disruptive to your app or development cycle. Please read Looker's [release notes](https://discourse.looker.com/search?q=%23news%3Arelease%20order%3Alatest) if you plan to use a beta endpoint so that you will be aware of any changes.\n- **Deprecated endpoints** are endpoints that are still supported and can still be used at the moment, but will be deleted in a future release. Old code that uses a deprecated endpoint should be updated to stop using the deprecated endpoint. When a future release of Looker removes support for that endpoint, any code that is still using it will break. In most cases, a deprecated endpoint will be replaced by improved functionality. If you find that your application is using a deprecated function or property, it's a good idea to refactor your code to replace the deprecated element as soon as you can.\n\nBeta and deprecated endpoints are marked as such in the [API Explorer](/looker/docs/api-explorer) and in the [4.0 API Reference](/looker/docs/reference/looker-api/latest). Endpoints that aren't marked are considered stable.\n\n\nMigrating to a new API version\n------------------------------\n\nWhen you choose to upgrade your client SDK or API URL to a new API version, you will need to review your application code to see if you're relying on something that has changed with the new API version. Be sure to do the following:\n\n1. Search your application code for the updated function, value, and property names.\n2. Verify that your application code supports any changes in types (such as integer to string).\n3. Audit your code (see the [Auditing your code section](#auditing_your_code)).\n\n### Auditing your code\n\nFor some languages, breaking changes in the API can be discovered at build time as compile errors:\n\n- If your application is written in a compiled, strongly-typed language, structural changes to parameter or response types in a new API version that are at odds with your existing code should be readily apparent thanks to compile type checking and compiler error messages.\n- If your application is written in a loosely-typed dynamic language (such as JavaScript, Ruby, and Python), it may be harder to locate the parts of your application that will be affected by breaking changes in a new API version. These types of languages might require runtime unit tests to find any issues related to changes in types.\n\nIn all cases, the best practice is to have unit tests that exercise your application code, including calls to the Looker API (not mocked calls)."]]
