会話型アクションのサポートは 2023 年 6 月 13 日に終了しました。詳細については、
会話型アクションの廃止をご覧ください。
プライバシーとセキュリティに関するベスト プラクティス
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ここでは、プロジェクトで Google Assistant API を使用するデベロッパー向けのセキュリティとプライバシーのガイドラインをいくつか紹介します。
API とアプリケーションの認可
Google Assistant API を使用するアプリケーションには、Google の認証サーバーでアプリケーションを識別する認証情報が必要です。通常、これらの認証情報はダウンロードした client_secret_<client-id>.json ファイルに保存されます。このファイルは必ず、自分のアプリだけがアクセスできる場所に保管してください。
アプリは、Google アカウントへのアクセス権を付与するようユーザーに求める場合があります。許可されている場合、アプリケーションはそのユーザーのアクセス トークンをリクエストできます。これらのトークンには有効期限がありますが、更新は可能です。
デバイス上の更新トークンを保護しないと、セキュリティ上の重大なリスクが生じます。アプリが次の条件を満たしていることを確認します。
- 更新トークンを安全な場所に保存します。
- デバイスからトークンを簡単に消去できる手段を提供します。たとえば、トークンをクリアする「ログアウト」ボタン（アプリに UI がある場合）や、ユーザーが実行できるコマンドライン スクリプトを提供します。
- Google アカウントへのアクセスの許可を取り消すことができる旨をユーザーに知らせます。これにより、更新トークンが取り消されます。アプリケーションを再度使用するには、ユーザーがアクセスを再承認する必要があります。
デバイスの使用が終了したら、デバイスからすべてのトークンを消去する必要があります。
詳しくは、OAuth 2.0 を使用して Google API にアクセスするをご覧ください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-26 UTC。
[null,null,["最終更新日 2025-07-26 UTC。"],[[["\u003cp\u003eApplications using the Google Assistant API require authorization credentials, typically stored in a \u003ccode\u003eclient_secret_<client-id>.json\u003c/code\u003e file, which should be kept secure.\u003c/p\u003e\n"],["\u003cp\u003eUser granted access allows applications to request access tokens that expire but can be refreshed; however, unprotected refresh tokens pose a security risk and should be stored securely with options for users to clear them.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers should inform users about the ability to deauthorize access to their Google account through Google's permissions page, which revokes the refresh token and requires re-authorization for further application use.\u003c/p\u003e\n"]]],["Applications using the Google Assistant API require authorization credentials, typically stored in a `client_secret` file, which should be securely stored. Applications may obtain user-specific access tokens, which can be refreshed. Refresh tokens must be securely stored, and applications should allow users to clear them, such as through a \"Sign out\" feature or a command line. Users should be informed that they can deauthorize application access, and all tokens should be cleared when a device is no longer used.\n"],null,["# Best Practices for Privacy and Security\n\nHere are some security and privacy guidelines for developers using the Google\nAssistant API in their projects.\n\nAPI and application authorization\n---------------------------------\n\nAny application that uses the Google Assistant API must have authorization\ncredentials that identify the application to Google's authentication server.\nTypically, these credentials are stored in a downloaded `client_secret_\u003cclient-id\u003e.json`\nfile. Make sure to store this file in a location that only your application\ncan access.\n\nYour application may prompt the user to grant it access to their Google account.\nIf granted, your application can request an access token for that user. These\ntokens expire, but can be refreshed.\n\nUnprotected refresh tokens on a device pose a significant security risk. Make\nsure your application:\n\n- Stores the refresh tokens in a secure place.\n- Provides an easy way to clear tokens from the device. For example, provide a \"Sign out\" button that clears a token (if the application has a UI) or a command line script that the user can execute.\n- Informs users that they can [deauthorize access](https://myaccount.google.com/permissions) to their Google account. This revokes the refresh token; to use the application again, the user would need to re-authorize access.\n\nWhen you are done using the device permanently, you should clear all of the\ntokens from it.\n\nFor more information, see [Using OAuth 2.0 to Access Google APIs](https://developers.google.com/identity/protocols/OAuth2)."]]
