...
この記事は Bob Hancock による Google Ads Developer Blog の記事 "Call Ads Replace Call Only Ads in the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Ads API v8 で、Call Only AdsCall Ads に置き換わります。AdWords API v201809 と Google Ads API v6 と v7 では、引き続き Call Only Ads を作成できますが、v8 を利用して新しい Call Ads を使うことをお勧めします。

Call Only Ads は、今後も 2022 年 4 月 27 日の AdWords API の提供終了まで利用できます。

v8 より前の Call Only Ads は、ユーザーに電話機能のみを提供します。ユーザーと広告主からは、この広告から直接ウェブサイトに移動できる機能の需要がございました。Call Ads に final URL が追加されたことで、電話を主な(ヘッドライン)アクションとして使いつつ、電話する前や電話する代わりに、広告主のウェブサイトに移動する手段も提供できるようになります。

必要になる作業
  • 新しい Call Ads を作るには、広告タイプで CallOnlyAd の代わりに CallAd を使います。
  • 広告を作る際に使われた ad.type にかかわらず既存の広告の情報を取得したい場合は、ad.type = 'CALL_AD' で絞り込みます。たとえば、Google Ads API で次のクエリを実行すると、
        SELECT ad_group_ad.ad.call_ad.country_code,
               ad_group_ad.ad.call_ad.phone_number
        FROM ad_group_ad
        WHERE ad_group_ad.ad.type = 'CALL_AD'
    CALL_ONLY_ADCALL_AD で作られた広告が返されます。
変更内容
追加項目
ad_group_ad.ad.final_urls ここにウェブサイトの URL を指定します。
path1 広告に表示する URL に追加して表示できるテキストの最初の部分です。
path2 広告に表示する URL に追加して表示できるテキストの 2 つ目の部分です。この項目は、path1 を設定した場合のみ設定できます。
削除項目
ad.display_url Call Only Ads の display_url を削除しました。
広告に表示される URL は、
ad_group.ad.final_urls (提供された場合)か
phone_number_verification_url
ad_group.ad.final_urls が空欄の場合)となります。
加えて、path1path2 で指定した追加テキストが表示されます。
項目の検証
phone_number_verification_url ad_group.ad.final_urls が空の場合、この項目が必須になります。

AdWords API レポート : AdWords API では変更はありません。

Google Ads API レポート : Google Ads API では、以下の新しい項目をクエリに含めることができるようになります。

サポートを受ける場所

Call Ads について疑問に思うことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


...
この記事は Google Open Source Security チーム、Oliver Chang、Go チーム、Russ Cox による Google Online Security Blog の記事 "Announcing a unified vulnerability schema for open source" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google はここ数か月の間に、さまざまな側面からオープンソース セキュリティを強化するため、いくつかの取り組みを始めました。その重点領域の 1 つに、広範な手作業をすることなく、既知のセキュリティ脆弱性を特定し、それに対応する方法を改善することがあります。セキュリティ脆弱性に優先順位を付けて対応するには、正確な共通データ形式が欠かせません。特に、影響が及ぶ依存性にリスクを伝える場合にはそれが当てはまります。これにより、自動化が簡単になり、オープンソース ソフトウェアの利用者は、影響を受けるときに通知を受け取ったり、できる限り早くセキュリティの修正をしたりできるようになります。

2 月には、オープンソース ソフトウェアのデベロッパーとユーザーが脆弱性の優先順位付けの自動化や改善を行えるように、Open Source Vulnerabilities(OSV)データベースをリリースしました。この最初の取り組みは、OSS-Fuzz プロジェクトによる数千の脆弱性のデータセットを使用して行われました。OSV を実現して数百の重要なオープンソース プロジェクトに正確な脆弱性データを伝えることで、この形式の成功と実用性が証明され、プロジェクトの改善に役立つフィードバックが得られました。たとえば、Cloud API キー要件を取り下げたことで、多くのユーザーがさらに簡単にデータベースを使えるようになりました。コミュニティの反応からも、この取り組みをさらに進めることへの幅広い関心が感じられました。

この度、OSV をいくつかの主要なオープンソース エコシステムに展開するための新たなマイルストーンをお知らせします。その対象となるのは、GoRustPythonDWF です。この展開により、4 つの重要な脆弱性データベースが 1 つに集約されるので、ソフトウェア デベロッパーが影響を受けるセキュリティ問題を追跡したり、それに対応したりする処理が改善されます。この取り組みは、最近の国家サイバーセキュリティ向上に関する米国大統領令とも一致します。この大統領令では、国家インフラストラクチャを強固にするため、脅威情報を共有するにあたっての障壁を取り除く必要性が強調されています。今回の共有脆弱性データベースの展開は、すべてのユーザーにとってより安全なオープンソース環境の構築に向けた重要な一歩です。
 
脆弱性を正確に記述するシンプルな統合スキーマ

オープンソース開発と同じように、オープンソース脆弱性データベースも分散モデルに従っており、多くのエコシステムや組織が独自のデータベースを作成しています。それぞれが独自のフォーマットで脆弱性を記述しているので、複数のデータベースの脆弱性を追跡するクライアントは、それぞれのデータベースをまったく別々に扱う必要があります。そのため、データベース間で脆弱性を共有するのも困難です。

Google Open Source Security チームと Go チーム、そして幅広いオープンソース コミュニティは、脆弱性を記述するシンプルな脆弱性交換スキーマを開発しています。これは、オープンソース エコシステム向けに一から設計されたものです。数か月前にこのスキーマに着手した後、パブリック フィードバックをリクエストし、たくさんのコメントをいただきました。その意見を反映した結果が、現在のスキーマです。

{

        "id": string,

        "modified": string,

        "published": string,

        "withdrawn": string,

        "aliases": [ string ],

        "related": [ string ],

        "package": {

                "ecosystem": string,

                "name": string,

                "purl": string,

        },

        "summary": string,

        "details": string,

        "affects": [ {

                "ranges": [ {

                        "type": string,

                        "repo": string,

                        "introduced": string,

                        "fixed": string

                } ],

                "versions": [ string ]

        } ],

        "references": [ {

                "type": string,

                "url": string

        } ],

        "ecosystem_specific": { see spec },

        "database_specific": { see spec },

}



この新しい脆弱性スキーマでは、オープンソースで脆弱性を管理するうえで、いくつかの重要な問題に対処することを目指しています。以下を満たす既存の標準形式は存在しないことがわかっています。

  • 実際のオープンソース パッケージ エコシステムのネーミングやバージョニングのスキームに厳密に一致するバージョン指定を強制する。たとえば、CPE などの既存のメカニズムでは、CVE などの脆弱性と、パッケージ マネージャーのパッケージ名や一連のバージョンを自動的に照合することは困難。
  • どんなオープンソース エコシステムの脆弱性も記述でき、エコシステムの独自ロジックがなくても処理できる。
  • 自動システムにも人間にも使いやすい。

このスキーマが、すべての脆弱性データベースをエクスポートできる形式の定義となることを期待しています。一元的に利用できる形式があるということは、脆弱性データベース、オープンソース ユーザー、セキュリティ研究者が簡単にツールを共有し、オープンソース全体の脆弱性情報を利用できるということです。つまり、誰でもオープンソースの脆弱性を完全に把握でき、簡単に自動化も行えるので、検知や修正にかかる時間も短くなります。

現状


脆弱性スキーマの仕様は何度かの反復を経ており、最終版に近づくにあたって、さらなるフィードバックを求めています。現在、たくさんのパブリックな脆弱性データベースがこの形式でエクスポートできるようになっており、さらに多くのデータベースで作業が進行中です。
OSV サービスもこれらすべての脆弱性データベースの集約をしており、ウェブ UI から参照できます。同じ既存 API を使い、コマンド 1 つで照会することもできます。

  curl -X POST -d \

      '{"commit": "a46c08c533cfdf10260e74e2c03fa84a13b6c456"}' \

      "https://api.osv.dev/v1/query"

    

  curl -X POST -d \

      '{"version": "2.4.1", "package": {"name": "jinja2", "ecosystem": "PyPI"}}' \

      "https://api.osv.dev/v1/query"



脆弱性データベースのメンテナンスの自動化


質の高い脆弱性データを作るのも困難な作業です。OSV ではすでに自動化が行われていますが、それに加えて、脆弱性データベースをメンテナンスするための自動化ツールを構築し、そのツールをコミュニティの Python アドバイザリ データベース作成に役立てました。この自動処理では、既存のフィードを受け取り、パッケージと正確に照合し、検証済みの正確なバージョン範囲を含むエントリを生成します。人間の介入は最低限にとどめられています。このツールは、既存の脆弱性データベースが存在しないエコシステムや、継続的なデータベースのメンテナンスがほとんどサポートされていないエコシステムにも展開する予定です。


参加する


この形式についてフィードバックを提供し、この形式を採用してくれた、すべてのオープンソース デベロッパーに感謝します。今後もオープンソース コミュニティと連携し、さらに開発を進めるとともに、すべてのエコシステムに広く採用を促してゆきたいと思います。この形式の採用に興味がある方は、公開仕様へのフィードバックをお願いいたします。

Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Fei Xiang による Google Ads Developer Blog の記事 "Deprecating Url Performance Report and Automatic Placements Performance Report in the AdWords API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

アップデート(6 月 21 日): サポート終了日が延長され、2021 年 9 月 13 日になりました。

2021 年 9 月 13 日をもって、AdWords APIURL パフォーマンス レポート自動プレースメント パフォーマンス レポートのサポートを終了します。サポートが終了すると、この 2 つのレポートは AdWords API で空の結果を返します。

引き続き 2 つのレポートにアクセスしたい場合は、Google Ads API に移行して次のビューを使用してください。
  • URL パフォーマンス レポートには、Google Ads API の detail_placement_view を使用
  • 自動プレースメント パフォーマンス レポートには、Google Ads API の group_placement_view を使用
Google Ads API へのレポートの移行については、レポート移行ガイドをご覧ください。

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


この記事はデベロッパー アドボケート、Charles Maxson による Google Developers Blog の記事 "Add dialogs and slash commands to your Google Workspace Chat bots" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

独自のカスタム Google Chat ボットの開発は、ユーザーやチームが直接、または Chat で共同作業するコンテキストの中で、ソリューションやサービスと連携できる優れた方法です。具体的には、Chat ボットをグループの会話で使ってワークフローを効率化したり、ディスカッションの流れの中で操作をサポートしたり、リアルタイムに情報や通知を提供したりできます。Chat ボットはダイレクト メッセージでも利用できます。これは、ワークフローや個人の生産性を最適化する新たな方法で、プロジェクトのタスクを管理する、活動時間を報告するなどの用途があります。ボットのユースケースは多岐にわたるため、時間とともに増え続けている Chat ユーザーに対して一貫してアプローチでき、ユーザーが作業やチャットをしている場所で直接活用できます。

カスタム Chat ボットの具体的なユースケースが決まった後、非常に重要なことは、ボット自身をどう設計するかです。直感的で使いやすいボットは利用される可能性が高く、忠実なフォロワーの増加にもつながります。スムーズでないもの、親しみにくいもの、わかりにくく使い方が複雑なものは、たとえバックエンドが優れていたとしても、「ユーザーを惹きつける」ツールになる可能性は低くなります。エンゲージメントが高く、なくてはならない Google Chat ボットの作成を支援するため、Chat ボット フレームワークに 2 つの機能を追加しました。これにより、これまで以上に高度なボット体験を構築できるようになります。

Google Chat ボットにスラッシュ コマンドを(再)導入する

Chat ボットのユーザビリティを強化するために活用できる最初の新機能が、スラッシュ コマンドです。数か月前にリリースされたスラッシュ コマンドを使用すれば、ボットの主な機能を見つけて実行するための視覚的なガイドをユーザーに提供し、ユーザーが Chat ボットとやり取りする方法を簡素化できます。スラッシュ コマンドの導入前に作成されたボットでは、ユーザーはボットが提供する機能を学習してから、ボットを呼び出してコマンドを正しく入力し、実行する必要がありました。しかしスラッシュ コマンドの登場により、ユーザーは Chat ボットをすばやく最大限に活用できるようになりました。

ユーザーがメッセージ行に “/” と入力するだけで、そのルームやダイレクト メッセージでボットによって提供されているすべての機能が一覧表示され、目的の機能を選択して実行できます。スラッシュ コマンドは、スタンドアロンで呼び出したり(例 : /help)、パラメータとしてテキストを追加したりできます(例 : /new_task review project doc)。このパラメータは、機能が呼び出されたときに処理できます。ボット コマンドをさらに見つけやすくするため、ユーザーが / 以降を入力すると、スラッシュ コマンドのリストがそれに一致するもので絞り込まれます(例 : "/h" と入力すると、H で始まるすべてのコマンドを表示)。ルームにたくさんのボットが追加され、スラッシュ コマンドを利用できるボットが増えると、この機能は便利になります。さらに、スラッシュ コマンドの UI には各コマンドの説明(最大 50 文字)が直接表示されるため、学習しなくても簡単に推測できます。

Google Chat の slashbot の実装例

デベロッパーとして、スラッシュ コマンドは簡単に実装でき、優れたボット体験を提供するうえで欠かせないものだと言えるでしょう。実際、すでに Google Chat ボットを構築してデプロイしているなら、ボットのアップデート リリースでスラッシュ コマンドを含めるように変更する作業は、十分すぎるほど価値があります。

Chat ボットにスラッシュ コマンドを追加するには、Hangouts Chat API 設定ページ(例 : https://console.cloud.google.com/apis/api/chat.googleapis.com/hangouts-chat?project=<?yourprojectname?>)でコマンドを登録する必要があります。スラッシュ コマンドのセクションがあり、そこでユーザーに表示する名前と説明、そして重要なコマンド ID の一意の識別子(1-1000 の整数)を設定できます。この識別子は、後ほどコードでイベントを処理する際に必要になります。

スラッシュ コマンドの編集例

ユーザーがスラッシュ コマンドを使ってボットを呼び出すと、ボットに送信されるメッセージに slashCommand フィールドが追加され、ボットがスラッシュ コマンドによって呼び出されたことがわかります。なお、ユーザーが / コマンドを使わずに @ メンションによって名前で直接ボットを呼び出せる点は変わりません。これは違いを見分けるうえで役立ちます。メッセージには、呼び出されたコマンドに対応する commandId も含まれます。これはボットの設定ページで指定した内容に基づいているため、ユーザーが実行をリクエストしたコマンドはそこから識別できます。さらに、メッセージにはイベントに関するアノテーションも含まれます。ユーザーが引数を指定した場合は、コマンド テキスト自体を解析した結果である argumentText も含まれます。

{
  ...
  "message": {
    "slashCommand": {
      "commandId": 4
    },
    "annotations": [
      {
        "length": 6,
        "slashCommand": {
          "type": "INVOKE",
          "commandId": 4,
          "bot": {
            "type": "BOT",
            "displayName": "Slashbot"
          },
          "commandName": "/debug"
        },
        "type": "SLASH_COMMAND"
      }
    ],
    ...
    "argumentText": " show code",
    "text": "/debug show code",
    ...
}

次に示す簡単な例では、ユーザーがスラッシュ コマンドを起動したかどうかを判断し、そうであればコマンド ID からリクエストされたコマンドを判別して実行しています。

function onMessage(event) {

  if (event.message.slashCommand) {

    switch (event.message.slashCommand.commandId) {
      case 1: // Command Id 1
        return { 'text': 'You called commandId 1' }

      case 2: // Command Id 2
        return { 'text': 'You called commandId 2' }

      case 3: // Help
        return { 'text': 'You asked for help'  }

    }
  }
}

Google Chat ボットにダイアログを導入する

2 つ目の Google Chat ボットの新機能は、ダイアログです。これは Chat ボット フレームワークに導入されたまったく新しい機能で、信頼できる構造化された方法で入力やパラメータを取得するユーザー インターフェースの開発を可能にします。これにより、ユーザーがボットのコマンドを入力するプロセスを簡素化、効率化できるので、ボットのユーザビリティが大きく前進します。ダイアログを使うと、ユーザーは視覚的に入力を促されます。これは、自然言語の入力でボットのコマンドをラップし、ボットが解読できる正しい構文が入力されることを期待する方法とは異なります。

デベロッパーは、ユーザーに指定してもらう必要があるコマンドの入力に対して、正確に動作するように目的を絞り込んだ UI を設計できます。引数を解析してユーザーの意図を論理的に推測する必要はありません。つまり、ダイアログは Chat ボットが対処できるソリューションのパターンとユースケースの種類を大きく拡張します。そのため、ユーザーにもデベロッパーにも、真に高度で実りある体験を実現できます。

Slashbot プロジェクト通知

内部的には、Chat ボットのダイアログは前述のスラッシュ コマンドと既存の Google Workspace アドオンの Card フレームワークを組み合わせて利用し、ダイアログの作成と処理をしています。この機能を使うには、ダイアログを起動するスラッシュ コマンドを作成し、次に示すように、スラッシュ コマンド設定プロセスで [Slash command triggers a dialog] の設定を true に指定します。

[Slash command triggers a dialog] 設定を有効化する例

[Slash Command to trigger a dialog] を設定すると、それが呼び出されたときに onMessage イベントが送信される点は変わりませんが、そこにダイアログのリクエストを表す新しい詳細情報が追加されます。このイベントを処理するには、先ほどの例の非ダイアログのスラッシュ コマンドと commandId を使い、switch でユーザーがリクエストしたコマンドを判別します。

ダイアログに実際に描画する要素を設計する際は、Google Workspace アドオンCard ベース フレームワークを使います。新世代の Google Workspace アドオンを構築したことがある方なら、この部分はおなじみであるはずです。ウィジェットを作成し、ヘッダーやセクションを追加し、イベントなどを作成します。実は、Chat ボットでアドオン UI を再利用したり共有したりすることもできます。ただし現在は、ボットで利用できるのは軽量な一部の要素である点に注意してください。Cards を使うことで、ボット用に一貫性のある最新のユーザー インターフェースを構築でき、タグや CSS の管理など、低レベルの詳細に悩む必要はなくなります。Cards の詳細はこちらをご覧ください。アドオンや Chat ボットでさらに簡単に Cards ベースのインターフェースを作成できるように、GWAO Card Builder ツールも導入しました。これを使うと、ドラッグアンドドロップのビジュアル デザイナーで開発作業を加速できます。

Cards のウィジェットができたら、呼び出されたときにそれをダイアログとして表示するために、次に示すスタブのように、action_response で DIALOG タイプを指定する必要があります。

{
  "action_response": {
  "type": "DIALOG",
  "dialog_action": {
    "dialog": {
      "body": {
        "sections": [
          {
           "widgets": [
             {
               "textInput": {
                 "label": "Email",
                 "type": "SINGLE_LINE",
                 "name": "fieldEmail",
                 "hintText": "Add others using a comma separator",
...

これで動作するダイアログができるので、あとはダイアログを表示した後のユーザー イベントを処理するだけです。ここでも、アドオンで Cards を扱う際のイベント処理と同じ方法を使います。ボットは、DialogEventType が SUBMIT_DIALOG に設定された CARD_CLICKED タイプのイベントを受け取ります。actionMethodName 値から、ユーザーがリクエストを処理するためにクリックした要素がわかります。下の例では、'assign' です。レスポンスには、ダイアログから返されたユーザー指定の入力である詳細情報 formInputs が含まれているので、それをソリューションのニーズに応じて処理します。

{ dialogEventType: 'SUBMIT_DIALOG',
  type: 'CARD_CLICKED',
  action: { actionMethodName: 'assign' },
  ...
  common: 
   { hostApp: 'CHAT',
     formInputs: 
      { 'whotochoose-dropdown': [Object],
        whotochoose: [Object],
        email: [Object] },
     invokedFunction: 'assign' },
  isDialogEvent: true }

ボットがタスクの処理を終えると、2 つの方法のどちらかでユーザーに応答できます。1 つ目の方法は、単純な確認応答(OK)のレスポンスです。これにより、アクションが正常に処理されてダイアログが閉じられたことを伝えます。

{
    "action_response": {
      "type": "DIALOG",
      "dialog_action": {
        "action_status": "OK",
...

もう 1 つの方法は、別のダイアログによる応答です。新しいダイアログや変更したダイアログでフォローアップできるので、複雑な入力シナリオや条件付きの入力シナリオに便利です。これは、ActionResponse で最初にダイアログ カードを使ってダイアログを呼び出したときと同じように実現します。

{
  "action_response": {
  "type": "DIALOG",
  "dialog_action": {
    "dialog": {
...

次のステップ

Google Workspace Chat ボットの構築を始めたい方や、スラッシュ コマンドやダイアログを既存の Chat ボットに追加したい方は、以下のリソースをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Chrome OS リリース TPM リード、Marina Kazatcker による Chromium Blog の記事 "Changes to Chrome OS’s release cycle" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先日、2021 年第 3 四半期の Chrome 94 から、新しいマイルストーンが 4 週間ごとにリリースされることをお知らせしました。さらに今回は、Chrome OS のリリース スケジュールを調整する計画についてお知らせします。

Chrome OS の重要な柱であるセキュリティ、安定性、スピード、シンプルさを維持しつつ、ユーザーに早く新機能を提供するため、第 4 四半期の M96 より、Chrome OS の安定版チャンネルは 4 週間周期に移行します。また、企業や教育機関のユーザー向けに、Chrome OS では M96 までに、アップデート周期が 6 か月の新しいチャンネルも導入します。詳しい情報は、近日中にお知らせします。

Chrome が 4 週間ごとのリリースに移行する M94 と、M96 の間のギャップを埋めるため、Chrome OS は M95 をスキップします(マイルストーン個別の詳細については、更新版の Chrome スケジュール ページをご覧ください)。

次の 10 年を見据えた今回の変更は、ユーザーの作業をサポートし、さらに便利で安全な体験を提供し続けるために必要な進化を Chrome OS にもたらすものです。

Reviewed by Eiji Kitamura - Developer Relations Team


この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Google Maps Platform JavaScript API and Promises" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


四半期毎のリリースで更新された Maps JavaScript API のバージョン 3.45 並びに、Weekly リリースの最新バージョンにおいても、非同期メソッドの既存のコールバック パターンに加えて、Promise もサポートされるようになりました。Promise は便利な構文による複雑さの軽減や深く入れ子になったコールバックの排除など、多くの利点をもたらします。今回の Promise の追加は、TypeScript のサポートMaps JavaScript API の動的な読み込みといった、Maps JavaScript API で最新の JavaScript プログラミング手法やパターンをサポートするうえでの、大きな取り組みの一環となります。 


以下の例で示すように、Promise の便利な機能の一つである、async / await を使用することができます。この機能を利用すると、API 呼び出しが成功せず、Promise が拒否された場合に例外が発生します。


const app = async () => {

  const elevationService = google.maps.ElevationService();

  const locations = [{lat: 27.986065, lng:86.922623}];

 

  const response = await 

elevationService.getElevationForLocation({locations});

  console.log(response.results);

};

 

app();


次のパターンは、Promise オブジェクトの then、catch、finally メソッドを使用するもので、エラー処理を改善します。ここでは、catch メソッドが明示されていて、catch なしで Promise が拒否された場合には、未処理の promise 拒否イベントがグローバル スコープに送信されます。

const elevationService = google.maps.ElevationService();

const locations = [{lat: 27.986065, lng:86.922623}];

 

const promise = 

elevationService.getElevationForLocation({locations});

 

promise

    .then((response) => {

      console.log(response.results);

    })

    .catch((error) => {

      console.log(error);

    });

    .finally(() => {

      console.log('done');

    });

最後に、以下の例は、既存のコールバック パターンの使用法を示しています。今後、新しい非同期メソッドは Promise のみをサポートする可能性がありますが、コールバックは引き続きサポートされる予定です。

const elevationService = google.maps.ElevationService();

const locations = [{lat: 27.986065, lng:86.922623}];

 

const callback = (results, status) => {

  if (status === 'OK') {

    console.log(results);

  } else {

    // このケースを処理する

  }

};

 

elevationService.getElevationForLocation({locations}, 

callback);


Promise をサポートしている機能の一覧については、Maps JavaScript API の Promise のドキュメントをご覧ください。こちらの内容は、今後の機能拡張に合わせて更新されますので、定期的に確認することをおすすめします。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Team 

...

Google IO での新アシスタント ツールのヘッダー

この記事は Rebecca Nathenson (Google Assistant Developer Platform プロダクト ディレクター ) による Google Developers Blog の記事 "New for I/O: Assistant tools and features for Android apps and Smart Displays" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今回の I/O では、Android アプリに Google アシスタントをさらに簡単に導入し、スマート ディスプレイでエンゲージメントを高めるコンテンツを作成するために役立つ、新しいプロダクトを発表しました。

新しい Android API でアシスタント開発が簡単に

App Actions を使うと、Android アプリに Google アシスタントを簡単に導入し、乗りものの予約からソーシャル メディア投稿まで、あらゆるユーザーの要求に応えることができます。MyFitnessPal や Twitter などの企業は、すでに App Actions を使い、声だけでユーザーの要求に応えています。Android Studio では、組み込みインテントをアプリの特定の機能や操作にマッピングすることで、App Actions を有効化できます。以下で紹介するのは、音声クエリや提案によって、ユーザーが簡単にコンテンツを操作できる新しい方法です。


Capabilities でアシスタントの組み込みインテントのサポートを強化

Capabilities は、新しいフレームワーク API で、現在ベータ版として利用できます。これを使うと、組み込みインテントで定義されている共通タスクのサポートが可能となります。インテントのカタログにある組み込みリクエストを活用すると、アプリ内の特定のアクティビティを直接開く方法をユーザーに提供できます。

たとえば、Yahoo Finance アプリでは、Capabilities を使ってユーザーが「OK Google, Yahoo Finance で Verizon の株価を見せて」と言うだけで Verizon の株価ページを直接開けるようになっています。同じように、Snapchat ユーザーも、「OK Google, スニーカーのスナップを送って」と話すだけでフィルタを追加して友達に送ることができます。


Android 12 のショートカットでアプリを見つけやすく

アプリ ショートカットは、Android で一般的なタスクを自動化する方法として、すでによく使われています。Android 12 の新しいショートカット用 API のおかげで、アプリがサポートしているすべてのアシスタントへの要求が見つけやすくなりました。Android ショートカットを作成すれば、自動的にアシスタント ショートカット ギャラリーに表示されるので、ユーザーは「OK Google、ショートカット」と言うだけで、個人の音声コマンドをアプリに設定できます。

アシスタントからのショートカットが表示されている 3 台のスマートフォン

Google アシスタントは皆さんのアプリを使うように促すよう、関連するショートカットも提案できます。たとえば、eBay アプリを使うと、ユーザーの画面に「入札を表示」ショートカットを作成する提案が表示されます。

さらに、Google Shortcuts Integration ライブラリも公開しました。これを使うと、Shortcuts Jetpack モジュールによってプッシュされたショートカットを特定し、関連する音声クエリをアシスタントで管理できるようになります。Google アシスタントが関連するショートカットをユーザーに提案してくれるので、皆さんのアプリを使ってもらえるようになります。


ウィジェットを使ってアシスタントから即座に回答や更新を受け取る(近日公開)

Android 12 の改善により、Capabilities API を使って特定の組み込みインテントをウィジェットにマッピングすることで、ウィジェットでコンテンツをすぐに見つけられるようになります。また、今後は車の運転に最適化されたウィジェットを Android Auto でも簡単に使えるようにする予定です。この方法でアシスタントを組み込むと、同じウィジェットで単発の回答、すばやい更新、複数ステップのインタラクションを実現できます。

たとえば、Dunkin のウィジェット実装では、「OK Google、Dunkin で再注文して」と話しかけると、以前に注文したドリンクを選んで再注文できます。Strava のウィジェットでは、「OK Google、Strava でマイルをチェック」と話しかけると、1 週間の走行距離をトラッキングし、ロック画面に表示できます。

1 週間の走行距離を表示する Strava ウィジェット

スマート ディスプレイで高品質な会話型アクションを構築する

昨年は、Actions BuilderActions SDK、そしてデベロッパーとユーザー双方のエクスペリエンスを改善する新しい組み込みインテントなど、スマート ディスプレイ向けのアシスタント プラットフォームに数多くの改善を加えました。ここでお知らせするのは、スマート ディスプレイの会話型アクションをさらに充実させるため、近日中にロールアウトされる改善点です。


デベロッパー エクスペリエンスを改善する新機能

インタラクティブ描画キャンバスは、HTML、CSS、JavaScript などのウェブのテクノロジーを使って、タッチや音声でコントロールするアシスタント用のゲームやストーリーを構築する際に役立ちます。CoolGames、Zynga、GC Turbo などの企業は、すでに描画キャンバスを使ってスマート ディスプレイ用ゲームを構築しています

この機能をリリースしてから、ウェブコードでコアロジックを実装する方がシンプルで高速だというすばらしいフィードバックをデベロッパーからいただいています。これを実現するため、近日中に Interactive Canvas API からテキスト読み上げ(TTS)、自然言語理解(NLU)、ストレージ API にアクセスできるようにして、デベロッパーがクライアント側コードからこれらの機能をトリガーできるようにします。この API により、経験豊富なウェブ デベロッパーがおなじみの開発フローを利用して、さらに応答性の高い描画キャンバス アクションを作れるようになります。

また、アクションをリリースする選択肢も増やす予定です。近日中に、Actions Console で段階的リリースを管理できるようにします。たとえば、ある国で最初にリリースしてから後でさらに拡大したり、一部のユーザーにだけリリースしてから徐々にロールアウトしたりできるようになります。


スマート ディスプレイでのユーザー エクスペリエンスの改善

スマート ディスプレイで視覚表現を強化する改善も行われています。たとえば、固定ヘッダーを削除してデバイスの全画面を活用することで、ユーザーに臨場感あふれる体験を提供できます。

インタラクティブ描画キャンバスによってスマート ディスプレイでタッチ インターフェースのカスタマイズが可能になる前は、デバイスの画面のどこかをタップして TTS の再生を停止する簡単な方法を提供していました。しかし、スマート ディスプレイでマルチモーダルなエクスペリエンスが増えるにつれて、ユーザーがディスプレイをタップしている間も TTS の再生を継続することが重要になるユースケースが登場しています。そこで、アクションで TTS を継続できるようにするオプションを近日中に提供する予定です。

さらに、Media API を更新して長時間のメディア セッションをサポートしています。これにより、特定の時間から再生を開始する、以前のセッションが停止したところから再開する、メディアの再生状況に応じて会話に応答する、といったことができるようになります。


音声による取引が簡単に

皆様が Google のプラットフォームでビジネスを構築するために必要なツールを用意することがいかに重要であるかは理解しています。昨年 10 月、シームレスな音声ベースとディスプレイベースの収益化機能を簡単に追加できるようにすることをお知らせしました。オンデバイス CVC とクレジット カードの入力が、まもなくスマート ディスプレイで利用できるようになります。この 2 つの機能によって、オンデバイス取引がはるかに簡単になり、ユーザーをモバイル デバイスにリダイレクトする必要がなくなります。

これらの新機能を活用して、モバイルでも自宅でも、エンゲージメントの高い体験を構築し、多くのユーザーに簡単に使っていただけることを期待しています。YouTube の Google I/O でテクニカル セッションやワークショップなどを確認し、早速 App Actions会話型アクションを始めましょう!


Reviewed by Johan Euphrosine - Developer Relations team