会話型アクションのサポートは 2023 年 6 月 13 日に終了しました。詳細については、
会話型アクションの廃止をご覧ください。
Package google.rpc
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ステータス
Status 型は、REST API や RPC API など、さまざまなプログラミング環境に適した論理エラーモデルを定義します。gRPC により使用されます。エラーモデルは次の属性を付与するように設計されています。
- 多くのユーザーにとって使いやすく、わかりやすいこと。
- 柔軟で予期しないニーズに対応できる。
概要
Status メッセージには、エラーコード、エラー メッセージ、エラーの詳細の 3 種類のデータが含まれます。エラーコードは、google.rpc.Code の列挙値であることが必要ですが、必要に応じて追加のエラーコードを受け入れることもできます。エラー メッセージは、デベロッパーがエラーを理解して解決できるよう、デベロッパー向けの英語によるメッセージにする必要があります。understandunderstandユーザー向けのローカライズされたエラー メッセージが必要な場合は、エラーの詳細にローカライズされたメッセージを入れるか、クライアントでローカライズします。オプションのエラーの詳細には、エラーに関する任意の情報を含めることができます。パッケージ google.rpc には、一般的なエラー条件に使用できる事前定義されたエラー詳細タイプのセットがあります。
言語マッピング
Status メッセージはエラーモデルの論理表現ですが、必ずしも実際の送信形式ではありません。Status メッセージが別のクライアント ライブラリと別のワイヤ プロトコルで公開されている場合は、異なる方法でマッピングできます。たとえば、Java では例外にマッピングされるものが、C ではエラーコードにマッピングされる可能性が高くなります。
他の使用例
エラーモデルと Status メッセージは、API の有無にかかわらず、さまざまな環境で使用でき、異なる環境で一貫したデベロッパー エクスペリエンスを提供します。
このエラーモデルの使用例には、次のようなものがあります。
部分的エラー。サービスがクライアントに部分的なエラーを返す必要がある場合は、部分的なエラーを示すために通常のレスポンスに Status を埋め込むことができます。
ワークフロー エラー。通常のワークフローには複数のステップがあります。各ステップに、エラー報告用の Status メッセージを含めることができます。
一括オペレーション。クライアントで一括リクエストと一括レスポンスを使用する場合は、各エラーのサブレスポンスに 1 つずつ、一括レスポンスの中で Status メッセージを直接使用する必要があります。
非同期操作。API 呼び出しでレスポンスに非同期オペレーションの結果を埋め込む場合、オペレーションのステータスは Status メッセージを使用して直接表す必要があります。
Logging です。いくつかの API エラーがログに保存されている場合は、セキュリティまたはプライバシー上の理由で必要な除去を行った後に、メッセージ Status を直接使用できます。
| フィールド |
code |
int32
ステータス コード。google.rpc.Code の列挙値になります。
|
message |
string
デベロッパー向けのエラー メッセージ。英語で記述します。ユーザー向けのエラー メッセージは、ローカライズして google.rpc.Status.details フィールドで送信するか、クライアントでローカライズする必要があります。
|
details[] |
Any
エラーの詳細を保持するメッセージのリスト。API が使用する共通のメッセージ タイプのセットがあります。
|
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-26 UTC。
[null,null,["最終更新日 2025-07-26 UTC。"],[[["\u003cp\u003eThe \u003ccode\u003eStatus\u003c/code\u003e type defines a consistent and flexible error model suitable for various programming environments, including REST APIs and RPC APIs.\u003c/p\u003e\n"],["\u003cp\u003eIt provides three key pieces of information: an error code using \u003ccode\u003egoogle.rpc.Code\u003c/code\u003e, a developer-facing English error message, and optional error details for context.\u003c/p\u003e\n"],["\u003cp\u003eWhile logically represented by the \u003ccode\u003eStatus\u003c/code\u003e message, its actual implementation may vary across languages and wire protocols.\u003c/p\u003e\n"],["\u003cp\u003eThis error model can be utilized in diverse scenarios beyond APIs to ensure a uniform developer experience, including partial errors, workflow errors, batch operations, and asynchronous operations.\u003c/p\u003e\n"]]],["The `Status` message defines an error model with three data pieces: `code`, `message`, and `details`. The `code` is an error code, `message` is a developer-facing English error message, and `details` contains additional error information. This model can be used for partial, workflow, batch, and asynchronous operations and in logging. It is designed for simplicity and flexibility and is adaptable across different programming environments and API types, with a mapping system that can change based on implementation.\n"],null,["# Package google.rpc\n\nIndex\n-----\n\n- [Status](/assistant/sdk/reference/rpc/google.rpc#google.rpc.Status) (message)\n\nStatus\n------\n\nThe `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). The error model is designed to be:\n\n- Simple to use and understand for most users\n- Flexible enough to meet unexpected needs\n\n#### Overview\n\nThe `Status` message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of `google.rpc.Code`, but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers *understand* and *resolve* the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package `google.rpc` that can be used for common error conditions.\n\n#### Language mapping\n\nThe `Status` message is the logical representation of the error model, but it is not necessarily the actual wire format. When the `Status` message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C.\n\n#### Other uses\n\nThe error model and the `Status` message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments.\n\nExample uses of this error model include:\n\n- Partial errors. If a service needs to return partial errors to the client, it may embed the `Status` in the normal response to indicate the partial errors.\n\n- Workflow errors. A typical workflow has multiple steps. Each step may have a `Status` message for error reporting.\n\n- Batch operations. If a client uses batch request and batch response, the `Status` message should be used directly inside batch response, one for each error sub-response.\n\n- Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the `Status` message.\n\n- Logging. If some API errors are stored in logs, the message `Status` could be used directly after any stripping needed for security/privacy reasons.\n\n| Fields ||\n|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `code` | `int32` The status code, which should be an enum value of `google.rpc.Code`. |\n| `message` | `string` A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details](/assistant/sdk/reference/rpc/google.rpc#google.rpc.Status.FIELDS.repeated.google.protobuf.Any.google.rpc.Status.details) field, or localized by the client. |\n| `details[]` | [Any](https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#google.protobuf.Any) A list of messages that carry the error details. There is a common set of message types for APIs to use. |"]]
