ゲームや対話エージェントからクリエイティブなブレインストーミングやコーディング ツールまで、人々のテクノロジーとの関わり方を変えるジェネレーティブ AI アプリケーションの新しい波が来ています。Google では、ジェネレーティブ AI を使った次世代のアプリケーションを簡単に作れる API やツールをすべてのデベロッパーに提供し、AI を身近なものにしたいと願っています。2023 年 3 月 14 日 (日本時間) 、私たちは、Google の大規模言語モデル（LLM）を簡単かつ安全に試すことができる新しいデベロッパー向けサービスである PaLM API を発表しました。この API と同時に、デベロッパーがすばやく簡単にプロトタイピングを開始できるツール、MakerSuite をリリースします。これらのツールは、プライベート プレビューを通じて一部のデベロッパーに提供される予定で、また近日中にウェイトリストも公開する予定です。
PaLM API を使って Google の大規模言語モデル（LLM）にアクセスする
PaLM API は、Google の大規模言語モデルを簡単に利用できる API です。コンテンツ生成やチャットに最適化された対話型モデルや、要約や分類などに最適化された汎用モデルにアクセスできます。まずはサイズや機能面で効率的なモデルを 2023 年 3 月 14 日より提供し、近日中に他のモデルやサイズも追加する予定です。
ジェネレーティブ AI モデルは、デベロッパーがすぐに使える強力な機能を備えています。さらに、個々の用途に応じてモデルのチューニングすることで、より良い性能が得られます。Maker Suite を使えば、デベロッパーがパラメータを効率的に調整する技術 (英語) を活用して、用途に合わせてチューニングされたモデルを作成できます。チューニングしたモデルをブラウザ上ですばやくテストし、繰り返し使用できます。
合成データでデータセットを拡張する
AI を使った開発には高品質なデータが欠かせませんが、すぐに利用できるデータだけでは学習に限界があるケースも少なくありません。MakerSuite では、少数のデータをサンプルとしてデータ拡張用のデータを合成し、新たに作成したデータセットの管理や操作が可能です。この合成データは、モデルのチューニングや評価など、さまざまなシーンで活用できます。
最先端の embedding（埋め込み）を生成する
LLM から得られる embedding は、セマンティック検索からレコメンデーション、分類まで、幅広い応用の可能性が見いだされており、いま大きな期待が寄せられています。PaLM API で生成された embedding を使えば、既存のデータや外部のデータソースを活用したジェネレーティブ AI アプリケーションの構築が可能になります。また、TensorFlow、Keras、JAX、その他のオープンソース ライブラリで構築されたアプリケーションで embedding を使用することも可能です。
責任と安全性を担保した構築
私たちは、Google の AI の基本方針 に従ってモデルを構築し、Responsible AI （責任ある AI）の基礎を提供します。デベロッパーが個々のアプリケーションにおいて責任と安全性の基準を定め遵守するには、それらをコントロールできることが重要です。Google のツールは、デベロッパーがそれぞれのアプリケーションやユースケースに応じて安全性の検証や調整するための簡単な手段を提供します。
ジェネレーティブ AI アプリケーションをスケールさせる
これらのデベロッパー ツールによって、ジェネレーティブ AI アプリケーションのプロトタイピングや構築を簡単に始められるのと同時に、サービスのスケーラビリティが必要になった場合の対応も容易です。PaLM API と MakerSuite は Google のクラウド基盤で提供されており、ホスティングやサービングのスケーラビリティについて心配する必要はありません。自分のアイデアをより大きな規模で展開したり、エンタープライズグレードのサポートや、セキュリティとコンプライアンス、サービスレベル合意（SLA）などが必要なケースでは、Google Cloud Vertex AI を活用し、エンタープライズ向け検索サービスや対話型 AI などの高度な機能の数々との組み合わせで、ジェネレーティブ AI モデルの機能を活用できます。
いまとてもエキサイティングな AI の潮流の中で、Google は、デベロッパーの皆さんの開発作業をより快適にするためのツールを作り続けたいと考えています。新しいデベロッパーを受け入れ、新機能を展開し、この技術をさらに広いデベロッパー コミュニティに提供していく予定です。また同時に、フィードバックに耳を傾け、学習し、デベロッパーが今いる環境でこれらのツールを最大限活用するために改善を続けていきます。
Quick Start Widget を使用すると、ユーザーは API キーを取得し、面倒なユーザーフローを経由することなく、サイトやアプリでマップを使用できます。ユーザーが最小限の負担で開始できるようにすることが、ユーザーの導入を促すうえで重要になります。新しいウィジェットでは、ユーザーは Google から API キーを確保するためにデベロッパーの提供する環境を離れる必要がなくなります。ユーザーにはアカウントやプロジェクトを設定する簡単かつ一連の手順が提供されます。なお、キーは自動的に作成され、保護されます。
この動画シリーズのパート 2（近日公開）では、アップデートを行う API 呼び出しでフィールド マスクを使う事例について紹介する予定です。また、いくつかの活用法や、読み取りとアップデートの両方の呼び出しにおけるフィールド マスクの使い方を説明する予定です。さらに、1 回の API 呼び出しで両方を使えることも紹介します。ご期待ください。
フィールド マスクを使って API ペイロードの部分的な応答を取得する方法の詳細については、Client Libraries のドキュメントのこちらのセクションをご覧ください。両方（読み取りおよびアップデート）のユースケースに関する総合的な記事については、Google Slides API ドキュメントのガイドをご覧ください。
私たちが開発用ドキュメントを公開する前に、すでにウォッチフェイスを作成していた開発者がいたことには大変関心させられましたが、非公式のやり方で Android Wear 向けのウォッチフェイスを作成していた場合には、公式 API へ移行してください。公式 API は統一されたユーザー体験をもたらすと同時に、Android Wear デバイスがアンビエントモードに入ったかどうかがわかったり、システム UI 要素の位置を調節したりといった機能をもたらします。また、Google Play のウォッチフェイス コレクションにフィーチャー掲載されるためには、新しい API の使用が必須となります。
ウォッチフェイスの配信
Android Wear 5.0 API 21 の OTA 方式でのロールアウトが完了したら、すぐに Google Play で配信中の対応アプリをアップデートすることを推奨します。ロールアウトの完了は、Google+ の Android Wear 開発者コミュニティで発表します。API 20 のデバイスでは API 21 を必要とするウォッチフェイスを表示できないため、ロールアウトの完了を待ってアップデートする必要があります。新しい API をインストールすると、ウォッチフェイスが表示されるようになりますが、ロールアウトが完了する前に wearable アプリをアップデートする場合には、OTA 配信を受ける前のユーザーがインストールに失敗しないように minSdkVersion を 20 に設定してください。ロールアウト完了後は、すみやかにウォッチフェイスを新しい API に移行してください。2015 年 1 月 31 日に、公式 API を用いていないウォッチフェイスのサポートを終了する予定です。
Google Play での Android Wear アプリ
Android Wear への配信に関するガイドラインに従っていただければ、アプリを Google Play 内の「Android Wear 向け」として申請できるようになりました。Wear アプリの品質チェックリストに準拠し、Google Play 内の Wear アプリとして承認されると、Android Wear デバイスのユーザーがアプリを見つけやすくなります。Android Wear レビューにオプトインするためには、Google Play デベロッパー コンソールの価格と配信のセクションをご覧ください。
あるレコードに対するユニーク ID であり、ドメイン名と、それにスラッシュとローカル ID が続く。ドメイン名はこのレコードに対して権限を持つホームレポジトリを示す。ローカル ID のフォーマットはホームレポジトリに任せられる。person_record_id が、そのアプリケーション自身と異なるドメインから始まっている場合、その record は他の source から得られたクローンであることを意味する。
entry_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
この record のコピーが保存された UTC 時刻。PFIF レポジトリは、record が追加時のこの値が単調増加することを保証しなければならない。それにより、クライアントは最後に受け取った entry_date 以降の entry_date をもつ record を要求することによってレポジトリのコピーを更新することができる。
author_name(string):
情報提供者のフルネーム。
author_email(string):
情報提供者のメールアドレス。
author_phone(string):
情報提供者の電話番号。
source_name(string):
この record のホームレポジトリの名前（情報元のサイト名）。
source_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
自由形式のテキストデータで、他の source から持ち込まれた静的なデータに使われます（他の source からインポートされた動的なデータは NOTE record に保存されるべきです）。短いフィールドは一行で、フィールド名、コロン、値で表現されます。長いフィールドは、フィールド名とコロンの行に続いてインデントされた文字列で表現されます。機械的な処理で他の形式から PFIF 形式に record が変換された場合は、"automated-pfif-author"フィールドが存在すべきです。このフィールドは PFIF を作成したプログラム名を表します。PFIF レポジトリから record がエクスポートされた場合には"automated-piff-author"フィールドは付加されません。人に対する自由形式テキストの説明も"description"のフィールド名でここに表されます。たとえば、自由形式文字列フィールドを持つ PFIF 以外のフォーマットから record を取得するプログラムは other フィールドを含み、それは次のようになるでしょう：
description:
Dark hair, in her late thirties.
Also goes by the names "Kate" or "Katie".
automated-pfif-author: ScrapeMatic 0.5
他のアプリケーションからインポートされたフィールドに対する名前はドメイン名とスラッシュを始めに付加されるべきです。例えば、ICRC record から生年月日がインポートされた場合は次のようになります：
（訳注：この例は PFIF 1.1 当時のもの。実際には PFIF 1.2には生年月日専用のフィールドが用意されています）
icrc.org/birthdate: 1976-02-26
sex(string):
探している人、見つかった人の身体的性別。female、male、 other の 3 つのうち 1 つで指定されます。性別不明の場合はこのフィールドを省略してください。
探している人、見つかった人の母国。大文字 2 文字の ISO 3166-1 country code で指定されます。
NOTE records
NOTE record はちょうどひとつの PERSON record に属します。ある PERSON record には任意の数の NOTE record が関連付けられます。すべての note はタイムスタンプと note の著者情報を持ちます。アプリケーションはタイムスタンプを、フィールドの最新情報を決定するのに使えます。ユーザーは著者情報をフィールドの信頼性を確かめるために使うことができます。
これらのフィールドは時間とともに変化する情報を保存します。これらのフィールドが NOTE record に現れたときは、この record はこれらのフィールドに対する新しい値を定めます。source_date フィールドは新しい値が効力を持つ日付を示します。例えば、最新の場所情報を表示したいアプリケーションは、last_known_location フィールドを持っていてるもののうち最新の source_data を持つ NOTE を参照すればいいことになります。
note_record_id(string):
この record のユニーク ID であり、ドメイン名にスラッシュ、ローカル ID が続きます。ドメイン名はこの record の権限を持つホームレポジトリの識別子です。ローカル ID のフォーマットはホームレポジトリに任されています。note_record_id がアプリケーションのドメインと異なったドメインから始まっている場合、この record は他の source からのクローンであることを意味します。
entry_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
この record のコピーが保存された UTC 時刻。PFIF レポジトリは、record が追加時のこの値が単調増加することを保証しなければなりません。それにより、クライアントは最後に受け取った entry_date 以降のentry_date をもつ record を要求することによってレポジトリのコピーを更新することができます。
author_name(string):
情報提供者のフルネーム。
author_email(string):
情報提供者の e-mail address。
author_phone(string):
情報提供者の電話番号。
source_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
この record がホームレポジトリ内で作成された時刻（情報元の投稿日）。ほとんどのケースで、note はこのフィールドでソートして表示されるべきでしょう。
found(boolean string, "true" or "false"):
行方不明者に連絡が取れた場合、会えた場合は"true", さもなくば"false"の値をとります。この note の text フィールドで、いつどこで連絡が取れたか、会えたかを説明するべきです。
email_of_found_person(string):
見つかった人の連絡先 e-mail です。このフィールドは人物が見つかった場合のみ存在します。この note の text フィールドでどのように連絡先情報が決定されたか説明するべきです。
phone_of_found_person(string):
見つかった人の連絡先電話番号です。このフィールドは人物が見つかった場合のみ存在します。この note の text フィールドでどのように連絡先情報が決定されたか説明するべきです。
last_known_location(string):
捜索されている人を最後に見かけた場所を述べた自由形式説明であり、市や都道府県など、できるだけ詳細に述べた情報です。この note の text フィールドはどのように所在地が決定されたか述べるべきです。
この NOTE record が関連づいている PERSON record の person_record_id です。
linked_person_record_id(string):
この NOTE record が、同一人物に対する重複 record であると主張している他の PERSON record のperson_record_id です。
ユーザーがある 2 つの PERSON record を重複だと示すときには、NOTE record をそれら両方の PERSON record に付加し、それぞれに linked_person_record_id フィールドを持たせ、相互に指し示します。これらの NOTE record はこれらを重複だと示した関係者を示す author_name フィールドを持ち、text フィールドに重複だと判断するにいたった理由を付加します。
Notes
String fields は non-ASCII character を含められます。
PFIF 1.2 では person 要素の外にトップレベルの note 要素を許します。正しい PFIF ドキュメントはひとつの pfif 要素からなり、それはひとつ以上の person か note 要素を持ちます。
note 要素が person 要素の外に現れる場合、note は person_record_id をもつ必要があります。それ以外の場合には person_record_id フィールドは任意ですが、存在する場合には note を含んでいる person の person_record_id と一致する必要があります。
person 要素の中では、 必須の person_record_id がはじめにくる必要があり、note 要素は最後に来る必要があります。note 要素の中では、note_record_id が最初に来る必要があり、もし存在するときには person_record_id がそれに続くべきです。残りのフィールドは任意の順番であらわれることができます。
