このページでは、アプリケーション開発者向けに、Google API と Google Cloud API の使用のトラブルシューティング方法の概要を説明します。
背景
Google API は、Google サービスによって提供されるネットワーク API です。アプリケーションは、さまざまな環境から JSON HTTP と gRPC を介して Google API にアクセスできます。デベロッパーには、Google が提供するクライアント ライブラリをアプリケーションで使用することをおすすめします。これらのライブラリは、認証やリストのページ分割などの一般的な定型ロジックを実装し、開発のオーバーヘッドやよくある間違いを大幅に削減します。
Google API を初めて使用する場合は、スタートガイドのページに沿って、アプリケーションの準備手順を完了する必要があります。まず、curl -v コマンドを使用して、使用する Google API にテスト リクエストを送信する必要があります。コードを記述せずに Google API を試すことができます。多くの場合、実際のアプリケーション開発を開始する前に多くの問題を解決できます。
Google API では、リクエスト数、エラー、レイテンシ、リクエストとレスポンスのサイズなど、API の使用に関する一般的な側面を対象とする無料の API 指標を提供しています。アプリケーションとロケーションに関するきめ細かいディメンションが提供されます。デベロッパーは、異常な API 使用を発見し、潜在的な根本原因を特定できます。たとえば、エラーが 400 を超えると、最近更新されたアプリケーションに論理的なバグがあるか、リクエストとレスポンスのサイズが大きくなり、アプリケーションの性能が落ちる可能性があることを意味します。
セキュリティとプライバシーを保護するため、Google API は通常、アプリケーション デベロッパーに API ログを提供しません。アプリケーション デベロッパーがクライアント側で API エラーを記録することを強くおすすめします。エラーは、ローカル ストレージまたは Cloud Logging API などのリモート ロギング API に記録できます。
ログには通常、エラー メッセージやエラーの詳細など、指標よりも詳細なエラーに関する情報が含まれます。これは非常に有益で、API エラーのトラブルシューティングに必要になることがよくあります。デベロッパーが API の使用に関する問題に気付いた場合、ログをクエリしてエラー メッセージとエラーの詳細を確認し、その情報を使用してエラーを解決したり、サポートに問い合わせたりできます。
Cloud Audit Logs
セキュリティ上重要なアクティビティの場合、Google Cloud プロダクトはアクティビティに関する詳細情報を含む監査ログを生成することがあります。Google Cloud API の使用状況のトラブルシューティングに役立つ情報が提供されます。たとえば、VPC Service Control のドライラン機能では、管理者向けに今後のポリシー変更を評価する監査ログが生成されます。
[[["わかりやすい","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-09-04 UTC。"],[[["\u003cp\u003eThis guide helps application developers troubleshoot their use of Google APIs and Google Cloud APIs.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing \u003ccode\u003ecurl -v\u003c/code\u003e for initial testing of Google APIs is recommended to identify and resolve issues before application development.\u003c/p\u003e\n"],["\u003cp\u003eGoogle APIs offer metrics for monitoring API usage, providing insights into request counts, errors, latencies, and data sizes to help discover and address abnormal usage.\u003c/p\u003e\n"],["\u003cp\u003eClient-side logging of API errors is highly encouraged for security and privacy and is essential for detailed troubleshooting, as Google APIs generally do not provide server-side logs to developers.\u003c/p\u003e\n"],["\u003cp\u003eUnderstanding API error codes, messages, and details is key to effectively resolving issues, with error codes enabling high-level error handling and messages and details aiding in diagnosing application logic flaws.\u003c/p\u003e\n"]]],[],null,["# Troubleshooting API usage\n\nThis page provides application developers an overview of how to troubleshoot\ntheir usage of Google APIs and Google Cloud APIs.\n\nBackground\n----------\n\nGoogle APIs are networked APIs provided by Google services. Applications\ncan access Google APIs via JSON HTTP and gRPC from different environments.\nWe recommend developers to use Google-provided client libraries in their\napplications. These libraries implement common boilerplate logic, such as\nauthentication and list pagination, which greatly reduce development\noverhead and common mistakes.\n\nFor more information, see\n[Client Libraries Explained](/apis/docs/client-libraries-explained)\n\nGetting started\n---------------\n\nIf you are new to Google APIs, you should follow the\n[Getting Started](/apis/docs/getting-started) page to complete the\npreparation steps for your application. You should first use the `curl -v`\ncommand to send test requests to Google APIs that you want to use.\nIt lets you experiment with Google APIs without writing any code.\nYou can often resolve many issues before you start real application\ndevelopment.\n\nFor more information, see [Getting Started](/apis/docs/getting-started).\n\nTroubleshooting using metrics\n-----------------------------\n\nGoogle APIs provide free API metrics that cover common aspects of API usage,\nincluding request counts, errors, latencies, request and response sizes. They\nprovide fine-grained dimensions in terms of applications and locations.\nDevelopers can discover abnormal API usage, and identify potential\nroot causes. For example, higher 400 errors can mean a recently\nupdated application has some logical bugs, or higher request and response\nsizes can cause slower application performance.\n\nFor more information, see [Monitoring API usage](/apis/docs/monitoring).\n\nTroubleshooting using logs\n--------------------------\n\nFor security and privacy reasons, Google APIs generally don't provide API logs\nto application developers. We highly recommend application developers log\nAPI errors on the client side. You can either log the errors to a local storage\nor to a remote logging API, such as [Cloud Logging API](/logging).\n\nLogs typically contain more information about errors than metrics, such as\nerror messages and error details. They are extremely useful and often\nnecessary to troubleshoot API errors. When developers notice any issue\nwith their API usage, they can query the logs to find error messages and\nerror details, and use the information to resolve the errors or contact\nthe support.\n\n### Cloud Audit Logs\n\nFor security sensitive activities, Google Cloud products may generate audit\nlogs that contain detailed information of the activities. They are a great\nsource of information for troubleshooting your usage of Google Cloud APIs.\nFor example, [VPC Service Controls](/vpc-service-controls) dry run feature\ngenerates audit logs for administrators to evaluate the upcoming policy changes.\n\nFor more information, see [Cloud Audit Logs](/logging/docs/audit).\n\nResolving errors\n----------------\n\nIf you have issues with your Google API usage and you have found the\ncorresponding metrics and logs, you can follow API Design Guide\n[Errors](/apis/design/errors) page to resolve the errors.\n\nIn general, each API error has 3 pieces of information: error code, error\nmessage, and error details:\n\n- The error code lets applications handle the error at the higher level, such as retry after `503` errors or re-authenticate users after `401` errors.\n- The error message lets application developers understand the error and\n fix their application logic.\n\n | **Warning:** Do not code against the error messages; they are subject to change without notice.\n- The error details contain additional information the applications can use\n to handle the error programmatically.\n\nFor more information, see the [Errors](/apis/design/errors) page."]]
