この記事は Google Play プロダクト マーケティング マネージャー、Lloyd Hightowerによる Google for Developers の記事 " Announcing the Winners of the Gemini API Developer Competition!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


5 月の  I/O で、Google は世界中の開発者のみなさんに Gemini API を活用した革新的なアプリの開発を呼びかけました。世界中の何千もの開発者の皆さんがこの呼びかけに応え、既存のアプリに AI を搭載した機能を追加し、可能性の限界を広げる AI のアプリを開発しました。

そして、みなさんが待ち望んでいた瞬間が訪れました：

Gemini API デベロッパー コンテストの受賞者を紹介します！日本からは 2 名の方が選出されました。

総合的なベスト アプリ : Jayu


AI 搭載のパーソナルアシスタント「Jayu」は、Gemini API とクリエイティブな開発の融合による可能性を実証しています。この革新的なアプリは、ウェブブラウザ、コードエディタ、音楽ストリーミング、ゲームなど、さまざまなアプリと統合されています。Jayu は、視覚情報を解釈することによって、アプリのインターフェースと直接対話してリアルタイムで翻訳する能力を持ち、Gemini API の力とその能力を最大限に引き出すクリエイターの卓越したスキルを同時に示します。Google にとって、Jayu は単なる受賞アプリではなく、AI が生活に統合され、働く未来の一端を垣間見ることができます。

影響力の大きいアプリ & ユーザー評価の高いアプリ : Vite Vere (Real Lives)


Vite Vere は、認知障害を持つ人びとが日常的なタスクをこなすためのパーソナライズされたガイダンスを提供することで、より自立することを支援します。このアプリが Gemini の視覚的理解と巧みなプロンプトを使用して、ユーザーがタスクを完了できるよう段階的な指示を提供することで、自立とスキル開発を促進している点に感銘を受けました。

最もクリエイティブなアプリ : Outdraw AI (日本) 


Outdraw は、創造性と AI のユニークな融合により、AI ならではのゲーム体験を可能にしました。このゲームは、ユーザーは人間には認識できて、AI の視覚理解では認識できない画像を描くという挑戦をユーザーに与えるゲームです。このアプリは、AI をコラボレーションパートナーから挑戦的な対戦相手に変えることで、クリエイティブな取り組みにおける AI の役割を再定義します。これは、AI の最も創造的な使用例の 1 つでした。

最も役立つアプリ & Flutter の最適な用途 : Prospera

Prospera は、革新的な Flutter アプリで、Gemini API を活用してリアルタイムの AI セールスコーチを構築しています。セールス会話の分析と即時のフィードバックやパフォーマンス レポートを提供することで、Prospera は　営業担当者がスキルを向上させることを可能にします。このアプリは、実用的なビジネス課題に対処し、プロとしての成長を促進する Gemini モデルの汎用性を示しています。Prospera の詳細と、アプリの選出理由については、Flutter ブログ (英語) をご覧ください。

ベスト Android アプリ : Gaze Link



Gaze Link は、重度の運動障害と言語障害を発症した筋萎縮性側索硬化症（ALS）の患者の力を引き出す可能性を秘めており、私たちに感銘を与えました。この Android アプリは、眼球追跡技術とGemini API を使用して、介護者の質問を理解し、患者から生成された単一単語に基づいて完全な文章の応答を正確に予測および生成します。Gaze Link の詳細については、Android Developer ブログ (英語) をご覧ください。

Firebase のベスト ユース : Trippy



Trippy は、Firebase と Gemini API を巧みに活用して、パーソナライズされた旅行計画体験を作り出すことで注目を集めました。このアプリは、Gemini の自然言語理解とレコメンド機能を活用して、ユーザーの好みをもとに目的地、アクティビティ、旅程を提案します。Trippy は、AI がどのように旅行計画を強化し、世界を探検するのをよりアクセスしやすく楽しいものにするかを示しています。Trippy の詳細については、Firebase ブログ (英語) をご覧ください。

ベスト ウェブ アプリ : Viddyscribe



ViddyScribe は、視覚障害者の方々がよりアクセスしやすくなるよう、動画に自動的に音声説明を追加するウェブ アプリです。このアプリは、Gemini モデルを使用して文脈的に正確な説明を生成し、視聴体験を妨げることなく動画にシームレスに統合します。ViddyScribe の詳細については、Chrome Developers ブログをご覧ください。

ベスト ゲームアプリ : Pen Apple



Pen Apple は、Gemini Flash モデル を巧みに活用して、ゲームプレイのインタラクションを迅速に解釈して実行するオンライン デッキ構築ゲームです。このゲームは、Gemini の自然言語処理能力を使用して、カードの効果を直接カード名から解釈します。これにより、最小限の開発努力で複雑で創造的なカードが可能になります。私たちは特に、Gemini API がゲームの背景設定、敵、ステージ、さらにはゲームの仕組みに統合される新しいカードの作成にも使用されている点にも感銘を受けました。

ARCore のベスト ユース: Everies (日本)

Everies は、Gemini API と ARCore を活用して、身の周りの物に命を吹き込みます。Gemini の視覚理解と高度なプロンプトを使用して、Everies は物ごとにユニークなスクリプトを作成し、ARCore を使用して顔の特徴を重ね合わせることで、革新的で楽しい方法で物に命を吹き込みます。

Gemini API で未来を構築する

これらのアプリは、さまざまな分野で画期的な問題を解決するための Gemini API の計り知れないな可能性を示しています。Google は、開発者の皆さんが Gemini の能力を活用して、今後さらにインパクトのある革新的なアプリを開発することを期待しています。Gemini を活用した開発を始めるには、Google AI Studio をご覧ください。

Reviewed by Tamao Imura - Developer Marketing Manager, Google Play














Google Cloud は、10 月 24 日 (木) にインフラエンジニアのためのイベント、「 Generative AI Summit Tokyo '24 Fall」を 開催します。

生成 AI はいよいよ「社会実装」へ移行しつつあります。

企業はますます生成 AI 技術を活用し、顧客体験の向上やプロセスの自動化、新しい製品やサービスの開発など、さまざまな分野での活動に取り組んでいます。生成 AI の技術革新は、競争力の向上やイノベーションの促進に貢献し、ビジネスの成長に寄与しています。

本イベントでは、「Gemini」、そして「Vertex AI」について、お客様の事例を中心に具体的な活用方法をご紹介します。これらのサービスは、ビジネスの成長やイノベーションを加速させるための非常に強力なツールです。実際の導入事例や成功事例を通じて、参加者の皆様に生成AIをどのように活用するか、その可能性を理解いただければと思います。

今回は現地会場参加者に抽選でオリジナル T シャツをプレゼントいたします。
（※ T シャツのプレゼントには諸条件がございます。詳細は Webサ イトをご覧ください）

ぜひ、 Generative AI Summit Tokyo '24 Fall にご参加ください。


■ 開催概要

日時 : 10 月 24 日（木）11:00 - 18:30

開催方法 : ハイブリッド（ベルサール渋谷ファースト / オンライン配信）

会場 : ベルサール渋谷ファースト

詳細・お申し込みはこちら 

※ プログラムは変更になる可能性がございます。最新の情報は上記 Web ページにてご確認ください。


【お問い合わせ】

Google Cloud イベント事務局

Email :  [email protected]

#gc_genai

レポートの生成と送信の仕組み。

Reporting API でモニタリングできるエラーには、次のようなものがあります。

モニタリングできるすべてのエラータイプについては、ユースケースとレポートタイプをご覧ください。

Reporting API は、HTTP レスポンス ヘッダーで有効化と設定を行います。つまり、ブラウザがレポートを送信するエンドポイントと、モニタリングするエラータイプを HTTP レスポンス ヘッダーで宣言します。ブラウザは、レポートのリストをペイロードとする POST リクエストによって、レポートをエンドポイントに送信します。

設定の例 :

# CSP 違反レポート、Document-Policy 違反レポート、非推奨レポートを受け取る設定の例
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
# CSP 違反と Document-Policy 違反を `main-endpoint` に送信する
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# 非推奨レポートは自動生成され、明示的なエンドポイントは必要ない。常に `default` エンドポイントに送信される

注 : "report-only" モードをサポートするポリシーもあります。このポリシーでは、レポートは送信されますが、実際の制限は適用されません。これは、ポリシーが効果的に機能しているかどうかを判断する際に役立ちます。

Chrome ユーザーは、DevTools の [Application] パネルから、ブラウザが生成するレポートを確認できます。

DevTools の [Application] パネルに表示されるレポートの例。

レポートのエンドポイントのデモでは、生成されたさまざまな違反がサーバーでどのように受信されるかを確認できます。

違反レポートの例

2024 å¹´ 3 月時点で、Chrome は Reporting API をサポートしており、Safari は一部をサポートしています。詳細については、ブラウザ サポートの表をご覧ください。


Google のアプローチ

Google は、セキュリティを大規模に向上できるという恩恵を受けています。Content Security Policy、Trusted Types、Fetch Metadata、Cross-Origin Opener Policy といったウェブ プラットフォームによる対策は、さまざまな Google プロダクトや無数の個々のサービスからあらゆる脆弱性を排除するために役立ちます。この点は、こちらのブログ投稿で詳しく説明しています。


セキュリティ ポリシーを大規模に導入する場合、エンジニアリング上の課題の 1 つとなるのが、新しい制限に準拠しておらず、制限が適用された場合に動作しなくなるコードを特定することです。この問題を解決するためによく使われる 4 つのステップがあります。
  1. ポリシーを report-only モード でロールアウトします（CSP report-only モードの例）。こうすると、ブラウザはクライアント側のコードを通常どおり実行するよう指示しつつ、ポリシーが適用された場合に違反となるイベントの情報を収集します。この情報は、レポートのエンドポイントに送信される違反レポートに集約されます。
  2. 違反レポートをトリアージし、ポリシーに準拠していないコードの場所にリンクします。たとえば、危険な API を使っていたり、ユーザーデータとコードが混在するパターンを使っていたりするため、セキュリティ ポリシーに準拠していないコードベースがあるかもしれません。
  3. 特定したコードをリファクタリングして準拠させます。たとえば、危険な API を安全なバージョンに置き換えたり、ユーザー入力をコードと混在させないようにしたりします。こうしたリファクタリングにより、危険なコーディング パターンが減り、コードベースのセキュリティ態勢が向上します。
  4. すべてのコードを特定し、リファクタリングが終わった段階で、report-only モード からポリシーを削除し、完全に適用します。通常のロールアウトでは、手順 1～3 を繰り返し、すべての違反レポートを確実にトリアージします。



Reporting API では、1 つのレポート エンドポイントと、複数のセキュリティ機能を表現する 1 つのスキーマを使ってこのサイクルを実行できます。そのため、ブラウザ、コードパス、ユーザータイプを問わずに、さまざまな機能のレポートを一元的に収集できます。

注 : ポリシーで禁止されているアクションを行おうとすると、違反レポートが生成されます。たとえば、あるページに CSP を設定しているにもかかわらず、CSP で許可されていないスクリプトを読み込もうとする場合です。Reporting API で生成されるレポートのほとんどは違反レポートですが、それがすべてではありません。その他のタイプには、非推奨レポートやクラッシュ レポートなどがあります。詳細については、ユースケースとレポートタイプをご覧ください。

残念ながら、違反レポートのストリームにはノイズが紛れ込むことがよくあります。その場合、準拠していないコードを見つけることが難しくなる可能性があります。たとえば、多くのブラウザ拡張機能、マルウェア、ウィルス対策ソフトウェア、開発ツールのユーザーは、DOM にサードパーティのコードを挿入したり、禁止された API を使ったりしています。挿入されるコードがポリシーに準拠していない場合、コードベースにリンクされていない対策不可能な違反レポートになる可能性があります。そのため、レポートのトリアージが困難になり、すべてのコードを確実に準拠させてから新しいポリシーを適用するのが難しくなります。

Google は長年にわたり、違反レポートを収集して活用し、それをまとめて 根本原因に集約するための多くの技術を開発してきました ここでは、デベロッパーが違反レポートのノイズを除外できる技術の中から、特に役立つ技術の概要を紹介します。


根本原因に注目する

ブラウザのタブが使われている間に、ポリシーに準拠していないコードが何度も実行されることはよくあります。それが発生するたびに、新しい違反レポートが作成され、キューイングされて、レポートのエンドポイントに送信されます。これが起きると、冗長な情報を含む大量のレポートができてしまいます。そこで、違反レポートをクラスタにグループ化することで、個々の違反を意識することなく、根本原因について考えることができます。根本原因の方が理解しやすいので、有効なリファクタリング方法を探す時間を短縮できます。

例を通して、違反がどのようにグループ化されるのかを確認してみましょう。たとえば、インライン JavaScript イベント ハンドラの使用を禁止する report-only の CSP が導入されているとします。違反レポートは、該当するハンドラのすべてのインスタンスについて作成され、次のフィールドが設定されます。

  • blockedURL ãƒ•ã‚£ãƒ¼ãƒ«ãƒ‰ã«ã¯、inline ãŒè¨­å®šã•ã‚Œã¾ã™。これは違反の種類を表します。
  • scriptSample ãƒ•ã‚£ãƒ¼ãƒ«ãƒ‰ã«ã¯、フィールド内のイベント ハンドラの内容の最初の数バイトが設定されます。
  • documentURL ãƒ•ã‚£ãƒ¼ãƒ«ãƒ‰ã«ã¯、現在のブラウザタブの URL が設定されます。

ほとんどの場合、この 3 つのフィールドで、特定の URL のインライン ハンドラを一意に識別できます。他のフィールドの値が異なる場合でも同様です。こういったことがよく起こるのは、トークンやタイムスタンプなどのランダムな値をページをまたいで使う場合です。前述のようなフィールドの値は、アプリケーションやフレームワークによって微妙に異なる場合があるため、レポート値をあいまい一致させることができれば、手間を省きつつ、違反をクラスタにグループ化して対策につなげることができます。必要に応じて、URL フィールドに既知のプレフィックスがある違反をグループ化することができます。たとえば、URL が chrome-extension、moz-extension、safari-extension ã§å§‹ã¾ã‚‹ã™ã¹ã¦ã®é•åã‚’グループ化すると、根本原因がコードベース以外のブラウザ拡張機能である違反を、高い信頼性で特定できます。

独自のグループ化戦略を策定すれば、トリアージが必要な違反報告の数を大幅に減らし、根本原因に注目することができます。通常は、関心のある種類の違反を一意に識別するフィールドを選び、そのフィールドを使って、特に重要な根本原因に優先順位をつけられるようにする必要があります。

 

環境情報を活用する

対策不可能な違反レポートと対策可能な違反レポートを区別するもう 1 つの方法が、環境情報です。このデータは、レポートのエンドポイントへのリクエストには含まれますが、違反レポート自体には含まれません。環境情報からクライアント設定におけるノイズ源を判別できる可能性があるので、トリアージに役立つかもしれません。

  • ユーザー エージェントまたはユーザー エージェント クライアント ヒント : ユーザー エージェントは、対策不可能な違反の大きな兆候です。たとえば、クローラ、ボット、一部のモバイルアプリなどは、サポート対象のブラウザ エンジンとは動作が異なり、カスタムのユーザー エージェントを使っているので、他では起きない違反が発生する可能性があります。それ以外にも、特定のブラウザでのみ発生する違反や、ナイトリー ビルドによる変更や新バージョンのブラウザによって発生する違反もあります。ユーザー エージェント情報がなければ、こういった違反を調査することは非常に困難になります。
  • 信頼できるユーザー : エンドポイントが違反の発生したドキュメントと same-site である場合、Reporting API がレポート エンドポイントに対して行うリクエストに利用可能な Cookie が添付されます。Cookie を取得すると、違反が起きたユーザーの種類を特定する際に役立ちます。対策すべき違反の多くは、会社の従業員やウェブサイト管理者など、信頼できるユーザーによるものであり、これらのユーザーが侵略的な拡張機能をインストールしたり、マルウェアに感染していたりすることはないでしょう。レポート エンドポイントから認証情報を取得できない場合は、まず信頼できるユーザーを対象に report-only ポリシーを設定してみましょう。そうすることで、対策すべき違反の基準を明確にしてから、ポリシーを一般公開することができます。
  • ユニーク ユーザー数 : 一般原則として、典型的な機能やコードパスのユーザーからは、ほぼ同じ違反が生成されるといえます。そのため、少数のユーザーでしか発生していない違反は除外候補とすることができます。つまり、アプリケーションのコードではなく、ユーザーの特定の設定が問題である可能性があるということです。「ユーザー数をカウントする」方法の 1 つは、違反を報告したユニーク IP アドレス数を記録することです。近似カウント アルゴリズムは使いやすく、特定の IP アドレスを追跡せずにこの情報を収集できます。たとえば、HyperLogLog アルゴリズムは、わずか数バイトで、信頼度高く、集合内のおおまかな一意の要素数を数えることができます。

違反をソースコードにマッピングする（高度な内容）

違反のタイプによっては、source_file ãƒ•ã‚£ãƒ¼ãƒ«ãƒ‰ã¾ãŸã¯ãã‚Œã¨åŒç­‰ã®ãƒ•ã‚£ãƒ¼ãƒ«ãƒ‰ãŒå«ã¾ã‚Œã¾ã™。このフィールドは、違反の原因となった JavaScript ファイルを表し、通常は行番号と列番号が付いています。これらの 3 ビットデータは高品質の信号であり、リファクタリングが必要なコードの行を直接指すことができます。

ただし、コンパイルや最小化のために、ブラウザがフェッチしたソースファイルがコードベースに直接マッピングできなくなることもよくあります。その場合は、JavaScript ソースマップを使って、デプロイされたファイルとオーサリングされたファイルの間で行番号と列番号をマッピングするとよいでしょう。すると、違反レポートがソースコードの行に直接変換されるので、非常に対策しやすいレポート グループと根本原因が生成されます。

 

独自のソリューションを確立する

Reporting API は、セキュリティ違反、非推奨の API 呼び出し、ブラウザの介入などのブラウザ側イベントを、イベントごとに指定されたエンドポイントに送信します。ただし、前のセクションで説明したように、そのレポートから実際の問題を抽出するには、データ処理システムが必要です。


幸いなことに、さまざまな方法で必要なアーキテクチャを設定できるようになっており、オープンソースのプロダクトもあります。必要なシステムの基本的な要素は次のとおりです。
  • API エンドポイント : HTTP リクエストを受け取り、JSON 形式でレポートを処理するウェブサーバー
  • ストレージ : 受け取ったレポートやパイプラインで処理したレポートを格納するストレージ サーバー
  • データ パイプライン : ノイズを除去し、必要なメタデータを抽出して集約するパイプライン
  • データ視覚化ツール : 処理したレポートから知見を得るためのツール

以上の各コンポーネントのソリューションは、パブリック クラウド プラットフォーム、SaaS サービス、オープンソース ソフトウェアとして利用できます。詳細については、代替ソリューションのセクションをご覧ください。また、次のセクションでは、サンプル アプリケーションの概要を説明します。

 

サンプル アプリケーション : Reporting API プロセッサ

ブラウザからレポートを受け取る方法と、受け取ったレポートを処理する方法を理解できるように、小さなサンプル アプリケーションを作成しました。このアプリケーションで、ブラウザが送信したレポートからウェブ アプリケーションのセキュリティ問題を抽出するために必要なプロセスを示します。具体的には、以下のプロセスになります。

  • レポートのストレージへの保存
  • ノイズ リダクションとデータ集約
  • 処理済みのレポートデータの可視化
このサンプルでは、Google Cloud を使っていますが、各コンポーネントはお好みのテクノロジーに置き換えることができます。サンプル アプリケーションの概要を次の図に示します。



緑色のボックスは、独自に実装する必要があるコンポーネントです。 フォワーダ（forwarder） はシンプルなウェブサーバーであり、JSON 形式のレポートを受け取り、それを Bigtable 用のスキーマに変換します。 ビームコレクタ（beam-collector） はシンプルな Apache Beam パイプラインであり、ノイズの多いレポートをフィルタリングし、関連するレポートを集約して、CSV ファイルとして保存します。この 2 つのコンポーネントは、Reporting API からのレポートを有効利用するうえで重要な役割を果たしています。


実際に試す

これは実際に実行できるサンプル アプリケーションなので、すべてのコンポーネントを Google Cloud プロジェクトにデプロイし、自分で仕組みを確認することができます。サンプル システムを設定するための詳細な前提条件と手順は、README.md ファイルに記載されています。

 

代替ソリューション

ここで共有したオープンソース ソリューション以外にも、Reporting API を簡単に使えるようにするツールがいくつも用意されています。次のようなものがあります。

  • report-uri や uriports などのレポート収集サービス
  • Sentry や Datadog などのアプリケーション エラー モニタリング プラットフォーム

代替案を選択する際は、価格だけでなく、次の点を考慮するようにしましょう。
  • アプリケーションの URL をサードパーティのレポート収集ツールに渡しても構わないでしょうか？ブラウザが URL から機密情報を取り除いたとしても、機密情報はこのように漏洩する可能性があります。アプリケーションにとってリスクが高すぎると思われる場合は、独自のレポート エンドポイントを運用してください。
  • 収集ツールは、必要なすべてのレポートタイプをサポートしていますか？たとえば、すべてのレポート エンドポイント ソリューションが COOP/COEP 違反レポートをサポートしているわけではありません。

まとめ

この記事では、ウェブ デベロッパーが Reporting API を使ってクライアント側の問題を収集する方法と、収集したレポートから実際の問題を抽出する際の課題について説明しました。また、その課題を解決するために Google がどのようにレポートをフィルタリングして処理しているかを説明し、同様のソリューションを実現する際に利用できるオープンソース プロジェクトを紹介しました。この情報が役立ち、Reporting API を活用するデベロッパーが増え、結果としてウェブサイトの安全性と持続可能性が向上することを願っています。


学習リソース



Reviewed by Eiji Kitamura - Developer Relations Team


今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディング フットプリント（建物の外形情報）の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。

ランドマークの表示によりすばやく現在地を把握することが可能に

ウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。

サンパウロ（å·¦）とローマ（右）のランドマーク

このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイル エディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。


ビルディング フットプリントへの切り替えで地図機能をシンプルに

場合によっては、シンプルな地図のほうが便利なときもあります。高い建物が密集している都市では、高い建物を 3D で表示するとユーザーにはわかりづらくなる場合があります。そのため、建物の 3D 表示の他に、スタイル エディタのオプションとしてビルディング フットプリント機能を追加しました。ビルディング フットプリントにより、基本的な地図のバランスや構成が大きく変更されるため、建物が 3D 表示された複雑な地図を必要としないユースケースにも対応できます。

ビルディング フットプリント

ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディング フットプリントを有効にするには、スタイル エディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。

スタイル エディタのメニューで [Landscape] から [Human-made] を選択し、ビルディング フットプリントを有効にした地図。


業界別に最適化された地図のスタイルでは、ランドマークとビルディング フットプリントに加えて詳細なストリート マップも使用可能

Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディング フットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイル エディタで機能をオフにします。

また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリート マップが利用可能になります。この機能は、2020 å¹´ 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリート マップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。


詳細なストリート マップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリート マップ機能を完全導入できるようこの取り組みを続けています。

ランドマークとビルディング フットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディング フットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。

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



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


はじめてみよう Google Cloud ハンズオン セミナー 機械学習編 をオンラインにて開催いたします。

機械学習の実運用基盤の構築では「MLOps」と呼ばれる機械学習に固有のさまざまな課題が生じます。このハンズオンでは、AI Platform Pipelines の使い方を解説し、AI Platform における MLOps 環境の構築方法を紹介します。

このハンズオンでは Google Cloud のカスタマー エンジニアの解説を聞きながらハンズオンを進めるだけでなく、不明点をチャットツールを通じて質問することができます。

Google Cloud プロダクトに興味のある方、知識を増やしたい方はぜひご参加ください。

参加登録受付中：http://goo.gle/gcblog_homlops



————————————————————

開催概要

名　称　はじめてみよう Google Cloud ハンズオン セミナー 機械学習編
日　程　2021 å¹´ 4 月 9 日（金）
対　象　Google Cloud Platform を利用したことがあり、機械学習や、
                ãã®ç’°å¢ƒã®æ§‹ç¯‰ã«èˆˆå‘³ã®ã‚るエンジニア
参加費　無料（事前登録制）
登　録　http://goo.gle/gcblog_homlops

————————————————————




Google Cloud Japan は 2 月 3 日 （æ°´）、2 月 10 日 （æ°´）、3 月 17 日 （æ°´）の 3 週にわたって Google Cloud App Modernization OnAir を開催いたします。

Google Cloud App Modernization OnAir では、Google Cloud のエンジニアが、モダンなアプリケーション開発で利用可能な Google Cloud のサービスや、コンテナ、Kubernetes を利用した開発手法、マイクロサービス アーキテクチャの採用、CI/CD パイプラインの構築、DevOps の実践方法、SRE の考え方、アプリケーション セキュリティ、デザインパターンなどをご紹介いたします。 既に Google Cloud についてご存知のお客様、これから利用を検討しているお客様、ぜひご視聴ください。

この Google Cloud App Modernization OnAir は、一度ご登録いただくと、3 週間分のセッションを追加登録なしでご視聴いただけます。配信当日はライブでの Q&A も行いますので、ぜひご参加ください。

また、今回 App Modernization OnAir 放送開始キャンペーンを実施しております。

参加ご登録者の中から抽選で 10 名様に Kubernetes パーカーをプレゼントいたします。

（全配信終了後に送付いたします）

事前お申込み受付中：http://goo.gle/devrelblog

開催概要

名　称　『App Modernization OnAir』

日　程　毎週 水曜日（3 連続開催） 2021 å¹´ 2 月 3 日（æ°´）、2 月 10 日 （æ°´）、2 月 17 日 （æ°´）

対　象　開発エンジニア、インフラエンジニア、運用エンジニア

参加費　無料（事前登録制）

登　録　http://goo.gle/devrelblog

Posted by Takuo Suzuki - Developer Relations Team



あらゆるアプリーケーション、サービスで、AI を活用し新たな価値を創造することが重要な時代になってきています。そこで、Google は、データ サイエンティスト、アプリケーション開発者向けに、最新の Google Cloud AI や、機械学習サービスの活用例などを紹介する 「Google Developers ML Summit」をオンラインで開催します。


TensorFlow、Cloud AI などの活用事例、機械学習モデルの開発や利用、また、データ サイエンティスト / 機械学習エンジニアを繋げるプラットフォーム「Kaggle」 についてご紹介します。


合わせてスピーカーを募集しています。奮ってご応募ください。（締切 : 10 月 19 日（月）9:00 AM）


■ 日程
2020 å¹´ 12 月 3 日（木） （アプリ開発）
2020 å¹´ 12 月 4 日（金） （クラウド、データ サイエンス）
※ 時間は変更になる場合があります。


■ 詳細・お申し込みはこちら
http://goo.gle/mlsummit-b1


■ プログラム
10 月末公開予定




Posted by Takuo Suzuki - Developer Relations Team


Data Analytics

Location Intelligence 
位置情報を活用したデータ分析プラットフォーム
こちらのデモでは食品の配達ゲームを通して、Google Maps Platform の機能をご体感いただくことができます。ゲーム画面上に表示される複数の配達先に、どのようなルートを選択すれば効率よく配達できるかを競い合います。

AI

Explore Cloud TPU
Google が開発した AI プロセッサのアーキテクチャ
Google が開発した AI プロセッサ「Cloud TPU」のメカニズムを学べるデモです。CPU、GPU、そして TPU のアーキテクチャの違いや、TPU が GPU より優れた費用対効果を実現できる理由を理解できます。また、TPU で構成された AI スーパーコンピュータ「Cloud TPU Pod」のテクノロジーや応用分野を解説しています。
PA!GO powered by Edge TPU 
PA!GO は、パナソニックが Google の機械学習技術を活用して開発する、子どものための新しい知育デバイスのコンセプトモデルです。PA!GO を家の外に持ち出して、草や花、動物や虫など、外の世界で出会ったさまざまなモノを内蔵カメラで撮ると、AI がそれらが何かを音声で教えてくれます。PA!GO の実装には、Google の機械学習ライブラリ TensorFlow と AI プロセッサ Edge TPU によるオンデバイスでの画像認識や、Google ナレッジグラフによるモノの情報探索が利用されています。（協力会社：パナソニック株式会社)

Workplace Transformation 

Reimagine Workstyle with AI
G Suite と Chromebook、Hangouts Meet ハードウェア と Jamboard が、時も場所も選ばず、セキュアで効率的なクラウドコラボレーションを実現。AI 技術がもたらすスマートワークをぜひ体験してください。ミニセッションも開催します。

Security

Cloud Armor Fortified Castle
Cloud Armor をご利用いただくことで、外部からの有害な攻撃を防ぐことができます。Web サイトを城に見立て、そこに攻撃を仕掛けてくる忍者や侍を、Cloud Armor を使って簡単に守れる様子をゲーム感覚で体験できるブースです。

Migration & Modernization

Hybrid & Multi-Cloud City
Anthos や Kubernates について詳しくない方でも、スクリーン上に構築された仮想都市を通じて、ハイブリッドなコンテナ環境、構成管理、Service Mesh の構築など、Anthos の概念を体験しながら理解できます。

AppDev & DevOps

Life of Your Code with Cloud Run
コンテナ化したアプリケーションを、Cloud Build でビルドし Cloud Run にデプロイする一連の CI/CD ワークフローをインタラクティブに体験できます。
DevOps with Google Cloud
デジタル時代を生き抜くためのビジネスを創出する際、DevOps を行うことによるメリットは大いにあります。本ブースでは DevOps による効果と GCP を使った実装方法をデモを通じてお伝えします。


ぜひ、上記をご参考に、Google Cloud Next ’19 in Tokyo の体験エリア Expo にお越しいただければ幸いです。会場で皆さまにお会いできますのを、Google Cloud 社員一同楽しみにしております。

イベント申し込み & セッション登録



イベント概要

イベント名： Google Cloud Next ’19 in Tokyo
ウェブサイト：https://cloud.withgoogle.com/next/tokyo
日程： 2019 å¹´ 7 月 30 日（火）・7 月 31 日（æ°´）・ 8 月 1 日（木）
時間：
7 月 30 日（火）
Bootcamp（有料） 9:00 / 13:00 〜 18:00（予定）
DevDay　10:00 〜 18:00（予定）
7 月 31 日（æ°´）
開場　8:30 （予定）
基調講演　9:30 〜 11:30 （予定）
セッション　12:00 ~ 21:00（予定）
8 月 1 日（木）
開場　8:30 （予定）
　　　 基調講演　9:30 〜 11:30 （予定）
　　　 セッション　12:00 〜 18:00（予定）
Next '19 in Tokyo Night　 18:30 〜 20:30（予定）
会場： ザ・プリンス パークタワー東京 および東京プリンスホテル

注意事項
※本カンファレンスは、Google Cloud の製品・サービス導入を検討されているエンドユーザー企業、団体、教育機関、政府自治体向けのイベントです。
※十分な座席数をご用意しておりますが、定員を超えた場合、エンドユーザー企業様優先の抽選とさせていただきます。
※イベントの当日登録は承ることが出来ません。前もってご登録くださいますよう、お願いいたします。
※ご不明な点は、FAQ をご確認ください。
————————————————————

お問い合わせ先
Google Cloud Next Tokyo 運営事務局
[email protected]



Google では現在、オンライン学習プラットフォーム QWIKLABS を用いて GCP を無料で学ぶことができる Cloud Study Jams という学習プログラムを開催しています。

これは、GCP（Google Cloud Platform）について勉強したい方がいつでも自主的に学習できるセルフペースのオンライン学習プログラムですが、『一人でやっていてもなかなか学習が進まない』という方に向けて、今回特別に、GCP のユーザー会である GCP User Group（GCPUG）が、このキャンペーンを使った「春一番 GCP」と題した勉強会を全国各地で実施してくれることになりました。

日程はどの会場も 3 月 2 日の午後です。会場での参加を希望される方は、各勉強会に申し込むのとは別に、Cloud Study Jams のプログラムに登録し、前もって無料のクーポンをお受け取りください。各イベントの詳細とお申し込み先は、イベント概要のリンクからご覧ください。

今回 GCPUG で企画されている勉強会は 3 月 2 日のみですが、学習自体は Qwiklabs のクーポン有効期間内（配布から約3ヶ月）であれば無料で進めていただくことができます。


イベント概要


[湘南] GCPUG Shonan 春一番GCP
場所: FG-Space https://goo.gl/maps/RMyMCc9H6Fy
募集人数: 12名
主催: GCPUG Shonan
申し込みサイト: https://gcpug-shonan.connpass.com/event/121621/


[奈良] GCPUG in Nara ～クラウドサーバGCPを無料で実際に使ってみる～【特別版】
場所: 奈良県生駒郡斑鳩町興留１０丁目６番４３号 いかるがホール（２F第４研修室）
募集人数: 47名
主催: GCPUG奈良
申し込みサイト https://gcpug-nara.connpass.com/event/121618/


[滋賀] 春一番GCP～初心者が無料でGoogle Cloud Platformに触れてみる～
場所: 滋賀県草津市大路1-15-39 カフェバル フィオーレ
募集人数: 15名
主催: GCPUG滋賀
申し込みサイト:　https://gcpug-shiga.connpass.com/event/121824/


[名古屋] GCPUG Nagoya 春一番GCP
場所: 愛知県名古屋市中区錦1-17-13 MYCAFE錦通店
募集人数: 5名
主催: GCPUG名古屋
申し込みサイト: https://gcpug-nagoya.connpass.com/event/121931

[岡山] GCPUG Okayama 春一番GCP
場所: 岡山県玉野市宇野1-38-1天満屋ハピータウン・メルカ２階 第二研修室
募集人数: 8名
主催: GCPUG岡山
申し込みサイト: https://gcpug-okayama.connpass.com/event/122198/


また、お近くに会場がない方には、オンラインでの参加をいただけるよう、現在準備中です。参加方法に関しましては、キャンペーンにお申し込みいただいている皆さまにお知らせいたしますので、オンライン参加をご希望の場合には、Cloud Study Jamsのサイトからキャンペーンにお申し込みください。

皆さまのご参加をお待ちしております。




Posted by Takuo Suzuki - Developer Relations Team


今年は、参加される方々の興味関心のある分野によりフォーカスするために、セッションのカテゴリ数を大幅に増やします。イベントの詳細およびイベント登録については、4 月頃にご案内させていただく予定ですので、どうぞお楽しみに。なお今年も、G Suite や Google Cloud Platform (GCP) の活用にまつわる専門的知見やナレッジを、セッションの場で共有してくださる方を募集します。セッションスピーカーを希望される方は、こちらからご応募ください。（応募期間： 2019 å¹´ 3 月 15 日（金）まで）

イベント概要

イベント名： Google Cloud Next ’19 in Tokyo
ウェブサイト：https://cloud.withgoogle.com/next/tokyo
日程： 2019 å¹´ 7 月 31 日（æ°´）・ 8 月 1 日（木）
開場： 8:30 （予定）
基調講演： 9:30 〜 11:30 （予定）
セッション： 12:00 〜 18:00（予定）
会場： ã‚¶・プリンス パークタワー東京 ãŠã‚ˆã³æ±äº¬ãƒ—リンスホテル

セッションスピーカー募集

対象：G Suite や Google Cloud Platform (GCP) の活用にまつわる専門的知見やナレッジをセッションの場で共有してくださる方
応募期間： 2019 å¹´ 3 月 15 日（金）まで
応募先はこちら
※ 画面が、英語表記になった場合は、右上の言語設定ボタン*で Japanese を選択すると、日本語表記に変更できます。
*

最新情報を受け取る

Next ’19 の最新情報は、こちらのページの『最新情報を受け取る』ボタンからご登録いただくと、随時お受け取りいただけます。Google Cloud 製品の最新情報なども併せてお送りしますので、ぜひご登録ください。

今年も、会場で皆様にお会いできるのを、楽しみにしております。



お問い合わせ先
Google Cloud Next Tokyo 運営事務局
[email protected]



Cloud IoT Core クライアント ライブラリ

Cloud IoT Core クライアント ライブラリは、Android Things デベロッパーがわずか数行のコードで使い始めることができるように設計されました。認証、セキュリティ、エラー処理、オフライン操作のベスト プラクティスが実装されており、ネットワーク、スレッド、メッセージ ハンドリングの処理を行ってくれます。

Cloud IoT Core は承認済み端末を追跡する端末レジストリを管理し、各端末は公開鍵を使ってサーバー認証を行います。Android Things では、ハードウェアのサポートによって暗号鍵マテリアルを確実に保護する Android Keystore など、IoT アプリの保護に役立つ多くの機能が提供されています。クライアント ライブラリは RSA 鍵と ECC 鍵の両方をサポートし、Cloud IoT Core での認証に利用できる JSON Web Token（JWT）の生成を実装します。

接続を確立できた端末は、テレメトリー データをテレメトリー トピック内の 1 つまたは複数のバケットにパブリッシュできるほか、個々の端末状態トピックに対して内部状態を報告できます。端末の状態は、ソフトウェアのバージョンや動作しているセンサーの数などの情報を格納することを想定しています。テレメトリー メッセージは、実際のセンサーの測定値など、端末からのその他すべてのデータが対象です。端末は、Cloud IoT Core がパブリッシュする 構成変更をサブスクライブすることもできます。

現実世界の IoT 端末は質の悪い無線条件で動作しているので、クライアント ライブラリは、エラー処理や、イベントのキャッシュと再送信を幅広くサポートしています。オフライン動作をカスタマイズしたいデベロッパーのために、ライブラリのキューをカスタマイズしたり置き換えたりすることもできます。これにより、保存するイベントや、オンラインに戻ったときに送信するイベントの順番などを細かく制御することが可能です。

Android Things を使った端末のプロビジョニングと認証


Cloud IoT Core クライアント ライブラリは、Android Things を使った端末のプロビジョニングや認証の全体像の一部です。この点の詳細については、Google I/O 2018 のプレゼンテーション動画をご覧ください。




サンプルコード

Cloud IoT Core クライアント ライブラリは簡単に使ってみることができます。Android Things プロジェクトの build.gradle ファイルに次の行を追加するだけです。 
implementation 'com.google.android.things:cloud-iot-core:1.0.0'

このライブラリは、ご自分でビルドしたい方のために、オープンソースとして GitHub で公開されています。さらに、Android Things でセンサーハブを実現する方法を示すサンプルも公開しています。これは、接続されているセンサーからデータを収集し、それを Google Cloud IoT Pub/Sub トピックにパブリッシュするものです。

独自のコードでクライアント ライブラリを使うのも簡単です。次の Kotlin の例は、プロジェクトに基づいて新しい構成とクライアントを作成する方法を示しています。 
var configuration = IotCoreConfiguration.Builder().
                         .setProjectId("my-gcp-project")
                         .setRegistry("my-device-registry", "us-central1")
                         .setDeviceId("my-device-id")
                         .setKeyPair(keyPairObject)
                         .build()

var iotCoreClient = IotCoreClient.Builder()
              .setIotCoreConfiguration(configuration)
              .setOnConfigurationListener(onConfigurationListener)
              .setConnectionCallback(connectionCallback)
              .build()

iotCoreClient.connect()

続いて、次の Kotlin の例では、テレメトリー情報や端末の状態をパブリッシュしています。 
private fun publishTelemetry(temperature: Float, humidity: Float) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"temperature" : $temperature,
        |"humidity": $humidity
        |}""".trimMargin().toByteArray()
    val event = TelemetryEvent(examplePayload, topicSubpath, TelemetryEvent.QOS_AT_LEAST_ONCE)
    iotCoreClient.publishTelemetry(event)
}

private fun publishDeviceState(telemetryFrequency: Int, enabledSensors: Array<String>) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"telemetryFrequency": $telemetryFrequency,
        |"enabledSensors": ${enabledSensors.contentToString()}
        |}""".trimMargin().toByteArray()
    iotCoreClient.publishDeviceState(examplePayload)
}


参考資料

Android Things 開発の詳細については、デベロッパー サイトをご覧ください。Cloud IoT Core を使ってみるための詳しい情報については、情報ページやドキュメントをご覧ください。ぜひ Google+ の Google's IoT Developers Community に参加して、皆さんが Android Things や Cloud IoT Core で開発しているものについて教えてください。



Reviewed by Takuo Suzuki - Developer Relations Team


Google Cloud は、2018 å¹´ 9 月 19 日 (æ°´) 、20 日 (木) の 2 日間、 Google の基幹イベント Google Cloud Next '18 in Tokyo を開催します。今年の Next は『クラウドの最先端を体験する』をテーマに、昨年からさらに規模を拡大して、東京プリンスホテル、ザ・プリンスパークタワー東京の 2 会場を使用して実施する予定です。

さまざまな IT の専門家、技術者、経営者、そして Google のエキスパートたちと出会い、課題解決に向けたアイデアを共有しませんか？ 機械学習やセキュリティのエキスパートから、最先端の技術を学びませんか？

なお今年は、G Suite および Google Cloud Platform の活用を通して得た専門的知見や新たなナレッジを、セッションの場で共有してくださる方を募集します。応募期間は、2018 å¹´ 3 月 7 日（æ°´）～ 2018 å¹´ 4 月 16 日（月）までとなりますので、セッションスピーカーを希望される方はこちらから応募をお願いします。

6 月頃を目処に、イベント登録を開始する予定です。こちらのページの、『最新情報を受け取る』ボタンからご登録いただくと、Next ’18 や Google Cloud 製品の最新情報などを随時お受け取りいただけます。


イベント名： Google Cloud Next '18 in Tokyo
公式ハッシュタグ： #GoogleNext18
日　　程： 2018 å¹´ 9 月 19 日（æ°´）・20 日（木）
開　　å ´： 8:30 （予定）
基調講演： 9:30 〜 11:30 （予定）
セッション： 12:00 〜 18:30（予定）
会　　å ´： ザ・プリンス パークタワー東京
　　　　　〒105-8563 東京都港区芝公園 4 - 8 - 1
　　　　　東京プリンスホテル
　　　　　〒105-8560 東京都港区芝公園３丁目３−１

お問い合わせ先
Google Cloud Next Tokyo '18 運営事務局
[email protected]


Posted by Takuo Suzuki - Developer Relations Team



Google Cloud では、ゲーム・アプリ業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆さまを対象に、11 月 22 日（æ°´）18 : 30 より「第 2 回 Google Cloud INSIDE Games & Apps 」を開催します。

第 1 部 セッションパートでは、“データアナリティクス” ã‚’テーマに、より実践的なデータ分析基盤を構築する技術を、事例を通してゲストスピーカーの方々にご紹介いただきます。また Google 社員から、データ分析に関連するプロダクトを解説します。

第 2 部は、Google 社員や同じ業界で働く参加者と交流を深めていただく懇親会を予定しています。ぜひ、ご参加ください。

《 開催概要 》

  • 名 称：第 2 回 Google Cloud INSIDE Games & Apps
  • 会 期： 2017 å¹´ 11 月 22 日（æ°´）18 : 30 - 22 : 00 
  • 会 å ´：グーグル本社
    　　　〒106‐­6108 東京都港区六本木6-11-10 六本木ヒルズ森タワー
  • スピーカー
    • 株式会社プレイド エンジニア 牧野 祐己 氏
    • 株式会社リクルートライフスタイル データエンジニア 南谷 和毅 氏
    • Google Cloud カスタマーエンジニア 
  • プログラム： 無料（事前登録制）
    • 18 : 30 受付開始
    • 19 : 05 - 19 : 40 セッション1 
    • 19 : 40 - 20 : 15 セッション2
    • 20 : 15 - 20 : 50 セッション3
    • 休憩
    • 21 : 15 - 22 : 00 懇親会
  • 主 催： グーグル・クラウド・ジャパン合同会社
  • 定員：200 名

《 お申し込み 》
https://goo.gl/GEdxMi
こちらのリンクからお申し込みください。
※ お申込み締め切り： 2017 å¹´ 11 月 13 日 ( 月 ) 15 : 00 まで
※ 競合他社様からのお申し込みはお断りさせていただくことがございます。
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ お申し込み多数の場合は抽選を行います。参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。


Posted by Takuo Suzuki - Developer Relations Team



クラウドは、おそらく3者ともなかったら今、起業できなかった、事業を進められないところもあると思うんですけれども。あ、ちょっとこれ会場に聞いてみよう。今、自分でまだパブリッククラウドを使っていないっていう。でも手を挙げにくいか。

玉川憲氏（以下、玉川）：いない。手を挙げにくいですよね。

及川：使ってる方、手を挙げてもらっていいですか？

（会場挙手）

及川：これどうですか？　野鳥の会の玉川さん。

岡田陽介氏（以下、岡田）：（笑）。

玉川：そうですね、76.8パーセントぐらいが手をあげてますね（笑）。

及川：なるほど。ありがとうございます。なにかの理由があってできないとか推測できるところもあるので、そういった不安なところに対してどうアドバイスするか。クラウドを含め、今後の技術予測みたいなところでなにかお話しすることがあれば聞きたいんですけれども。
ちょっとふわっとした質問かもしれないですけど。まあ、クラウドで不安だという人にはどう言われますか？　だいたい不安な要素ってあれですよね……なんなの？

玉川：いや、私が某クラウドをやっていた2010年には、本当にそういう意見が多かったんですよね。大企業の中のIT予算とかでも、パックマンモデルって言われたんですけど、「8割が保守のためで、新規に使えるのなんて2割だから、もちろんクラウドは使うんだけど、ほとんど使わないよ」という話だったんです。でも、最近だいぶ変わりましたよね。
保守に使うのをできるだけ下げて新しいことをやっていかないと、どれだけ大企業であっても生き残っていけない。それが、ここ7年ぐらいの世界の変化なのかなと思っています。
そうなったときに、現時点で日本でも、……なんていうんでしょう。SORACOMはある意味、クラウドのモバイルなんですけど、「クラウドだから使いません」はほとんど聞かなくなったと思うので。もう本当に、不可避な流れのメインストリームに乗ったのかなと思っています。

ですので今、単純にめんどくさくて手を挙げていない人もいたと思うんですけど、もし使っていない人がいたら、その……とくにGoogle Cloudを使ってみたほうがいいと思います（笑）。

どのクラウドでもいいと思うんですけど、パブリッククラウドでメガクラウドといわれるものはどれも使いやすいですし、ものすごくいいので、ぜひ使ってみていただければなと思いますね。

「ないもの」を心配しがちな日本人

及川：そうですね。ちょっとじゃあ岡田さんと芳賀さんに聞きたいんですけれども。そうは言っても、マルチクラウドをしてなくて、どこかの1社のパブリッククラウドにいってたら、可用性とか、ダウンの時間はすごい短いかもしれない。でも、ダウンしたときが心配だったりとかってあるじゃないですか。

そこらへん、自分たちがパブリッククラウドを使うときにどう考えられたか、なにか今、対処ってされているのかを聞きたいんですけれども。

芳賀洋行氏（以下、芳賀）：対処ですよね？　まあ「そんなもんだ」ぐらいですよね。私が始めた時ってSaaSのサービスを使ってバックエンドを組んだんですけど。始めてだいたい3ヶ月後になくなるって発表がありまして。それはそんなもんだと思って「じゃあ乗せ替えるか」みたいな。



結局、止めないで乗せ替えなきゃいけないんですけど。別にめんどくさいだけで「まあそんなもんだ」「結局スケーラビリティも上がったし、コストも安くなったから、まあいいか。いいチャンスだった」みたいな、そんなもんですね。

及川：それはサービスのシャットダウンですよね。サービス自身のダウンタイムみたいなところって心配したりはしました？

芳賀：ああ……。でも、そんなにないですよ。

及川：ないです。ないのを心配する人が、日本人では多いんですよ。

芳賀：自社で持っていたほうが危ない気しますけれどもね。ダウンタイム……ありましたっけ？　でも、この間の……どこだっけあれは？　どこかでS3が火災になったときはドッキリしましたけど、あれだって分散されていれば問題ないわけなんで。

及川：要するに、分散は普通にしておきましょうって話ですよね。

芳賀：そうですね。「めんどくさいからやらない」となると、それはリスクあるかもしれないですけど。きっちりやっていればいいと思います。

及川：ベストプラクティスはいっぱいあるから、それはきっちりやりましょう、という。

芳賀：そうですね。

及川：岡田さんは、なにか付け足しとかあります？

岡田：そういった意味では、1つのデータセンターに依存するのはまずいので、単純にエリア分散しましょうねというところですね。
あと、我々はよくIoT的にやってるんですけど、エッジ側のデバイスから送らせたりするんですね。なにがいいかというと、最悪ダウンしてても、そこで保留されていたりするので、落ちてもとくに問題にならない。
とくにつながらなくなっても「つながらないよ」って言うんですけど、つながるようになったらまた再度通信を開始してくれる。そういった「どういうハンドリングプロセスを取るか」という、そのエンジニアリングのプロセスでけっこう解決できるところは多いなと思ったりしますね。

コードを書く→世界に価値を提供する、のサイクルを楽しめる

及川：なるほど。わかりました。ありがとうございます。このセッション自身は、前が押したのであと14分あると私の時計では言ってるんですが。とても個人的なことで、私は10時55分の飛行機に乗らなきゃいけないというのがあるので。ちょっと早めに終わらせていただきたいんですけれども（笑）。

もう1つ、技術者の方が興味を持つと思われる質問を。基本的にはやっぱり、皆さんがエンジニアで創業者の方なので、技術というところを入れておきながら、もう少し技術から離れたところを聞きたいなと思っているんですね。

1つは、3人とも起業するのが目的じゃなかったのかなって勝手に推測してるんです。なにかやりたいってことがあり、それで起業という選択肢を取ったのかなと思うんですけれども。違うなら違うと言っていいですよ、芳賀さん（笑）。

まあ、わかんないです。そこらへんちょっと教えてほしいんです。起業の経緯というところです。どうしよう。じゃあ芳賀さんからお願いしていいですか。

芳賀：僕からですか。僕、ちょっと起業の経緯はけっこう違うというか……。

及川：知ってます。だから振りました（笑）。

芳賀：僕はどちらかというと、個人でVRアプリを作ってまして。これがけっこうウケちゃいまして。それで最初にドバイとかのお客さんから「困っちゃってる。VR作れない」って、僕のほうに依頼が来て、一時期ドバイのアプリを全部僕が作ってたんですよね。
そのあといくつかVRアプリ作ってたら、気がついたらVRの動画再生プレイヤーがGoogleさんが出している動画プレイヤーよりも一時期、ランキングが上になっちゃってですね。気がついたら、先頭集団にいまして。
「これは起業したほうがいいかな」ということで、投資家さんを回ったら「じゃあ投資します」って話が決まりまして。そこから「会社ないんだっけ？」っていう話になりました。なので、会社を作るのはプロダクトより後でしたね。

及川：それっておもしろい話で。プロダクトをそのまま成長させたいとか続けたいときに資金をもらう必要があり、資金をもらうためには法人が必要だったから、法人化するために起業しました。

芳賀：おっしゃるとおりです。

及川：なので、さっき私が話したみたいに、もともと起業がゴールなわけではなくて、プロダクトのグロースがゴールであり、そのためのステップとして起業があった、と。

芳賀：そうですね。本当にシンプルなモチベーションでした。エンジニアとして、机に座って何時間コードを書いて、世界に価値を提供してよろこんでもらえる。このサイクルを楽しめる。しかも、自分たちが好きなようにというか、それがまず楽しいですし。それに僕としてはあまりほかにやることもなかったというか、起業を止めるものはとくになかったので、大丈夫でした。

及川：いや、芳賀さんの話を聞くと、人生ね、肩の力が抜けるというか（笑）。普通にやりたいことへ突き進んで、きちっと評価されていったならばこういう結果になるみたいなところがあって。違いますか？

芳賀：そんな感じだと思います。

及川：勝手に印象づけちゃいました。

芳賀：ありがとうございます。

「売るために起業したけど、やっぱり売れないぞ」

及川：岡田さんいかがですか。どういう経緯で起業されたか。先ほど自己紹介でもちょっと言われてましたけどね。

岡田：そうですね。そういった意味だと、私はシリコンバレーへ行ったときにそういうものに出会って。日本に戻って、共同創業メンバーと何人かでディープラーニングをカタカタやってみたんですね。当時はCPUしかなかったので、「1回学習スタートしたら1週間はPCに触れません」みたいな時もあったんですけど。



そういうかたちでやったらけっこううまくいって、「ああ、すごいこれ、いいかたちでできたね」「じゃあここまでうまくできたんだから、これ売ろう」「売るためには会社あったほうがいいよね」という感じで会社作ったみたいのが経緯ですね。
ただ、これには裏話があって。当時2012年の9月に創業してるんですけど。本当にディープラーニングが売れなくて。

2012å¹´9月にディープラーニングと言って反応する方はゼロなんですよね、基本的に。Google Japanの方でもほぼいなかったのぐらいのレベル感で、けっこう苦しかったんです。2013å¹´、14、15、16ぐらいにだいぶ流れがきて、伸びたんですけど。

なので、我々は最初にディープラーニングがあって、「売るために起業したけど、やっぱり売れないぞ」となって。売るためにバーティカルで、小売業やって、ソリューションを出した。そして今、ようやくプラットフォーム事業も進めている。だから、かなり違和感があるんですけど。

やっぱり、そういう意味では「やりたかったことがあるので起業した」というのは、まったく同じかなと思います。

やりたい技術ありきの起業

及川：技術に惚れ込んだという感じなんですよね。なるほど。わかりました。玉川さん、いかがですか？

玉川：そうですね、私もどちらかというと、起業をしたくて起業したというよりも、もともとクラウドのビジネスをやっていて、「こういうプラットフォームビジネスってすばらしいな」と思っていたんですね。なぜかというと、それがあることでいろんな人をモチベートできて、新しいチャレンジを促すというようなプラットフォームビジネスがいいなと思っていたからです。

某クラウドの立ち上げを日本でやってたときに、2014年だったと思うんですけど、アメリカに出張してた時でした。今一緒にやってるCTOの安川（健太）と一緒に飲んでいて、そういう通信プラットフォームをクラウドの上で作れるんじゃないかと盛り上がって。
出張してたので、当時寝れなくて。時差ボケがいつも激しいので。それで仮想のリリースノートを、その夜、寝れなかったので書いたんですね。こういう通信プラットフォームを書きました。そのまま寝て、朝起きてそのプレスリリースを見ると、「これいけるんじゃないか」と思ったのがきっかけですね。なので、飲みが始まりということですね。

及川：今、プレスリリースという話が出たんですけど、Amazonさんって、プロダクトの企画ってプレスリリースから書くんですよね。

玉川：A社はそうですね。

及川：ですよね。気を遣ってますね（笑）。

（会場笑）

私、プロダクトマネージャーをやっていて、それでいろいろな会社からアドバイスしてほしいと言われると「プレスリリースから書くといいらしいぜ」と言ってるんですけども。それはそのA社さんから教えてもらいました。

目指すゴールへのより良い道としてIPOもしくは事業売却を選ぶ

ちょっと時間も限られているので、なんの話を聞こうかなと思ってるんですが。1つだけ、ここに書いてないけど、私が3人にどうしても聞きたいことがあるんですよ。もう手を挙げるだけでいいですよ。

今後の展開を、いわゆるスタートアップのイグジットを聞きたいなと思っています。ただ、みなさんがみなさん起業家を目指してるわけじゃなかったり、なまめかしい話も多いと思うので、手を挙げるだけでいいんです。

イグジットで、IPOで上場を目指してるのは当然あると思います。もう1つは事業売却があると思うんですね。

みなさんがそうかどうかは別にして、例えば1つ、Googleに買われたいというのはもしかしたらスタートアップのゴールとしてあるかもしれないですけれども、日本で買われたいなと思うような会社ってありますか？　会社名は言わなくていいですから。……手を挙げろってこれ難しいですね。みんな力ましちゃいますよね。どうでしょう？

玉川：手を挙げると語弊があるので、ちょっとひと言。



ソラコムに関して言うと、もともとそういう経緯で通信プラットフォームを提供したいと思って。しかも、「日本発でグローバル」が僕らのミッションでありパッションであるので、そういう意味でいったときに、IPOであれイグジットであれ、そのグローバルプラットフォームの実現するよりよい道を選ぶと考えています。

起業家精神を持ったテクノロジストの重要性

及川：わかりました。その次の質問にちょっと関わるんですけれども、正直、私は日本ではITがすごい強くて、エンジニアが入りたい会社がゼロとは言わないですが、あまりまだ多くなくって、だんだん増えてきているところが喜ばしいなと思ってるんですね。

なので、みなさんになってほしいなと思うので。みなさんは今後日本で、元気なスタートアップだったり、優秀なスタートアップだったら買収したいと思うことはあると思うし、あってほしいなと思います。

もしそうだとしたら、どんなスタートアップにそういった魅力を感じるかを教えてほしいなと思うんですけれども。意見がある方。

岡田：そういった意味ですと、我々の会社はけっこうめずらしくて、テクノプレナーシップというのをすごい言っています。これがなにかというと、テクノロジストとアントレプレナーの造語なんですよね。

起業家精神を持ったテクノロジスト、技術者みたいなことを我々は言ってるんですけど。この両方が重要かなと思っているんです。テクノロジストだけだと、日本で儲からない。でも、すごく技術力あるベンチャー企業ってけっこうあったりすると思いますし、逆パターンもけっこう大きいと思うんですよね。

なので、これが2つともマッチしてる会社がたぶんGoogleだったり某A社だったりすると思ってまして。そういった会社が日本から生まれるといいなと思ってたりします。そうやってテクノプレナーシップを社内で育てて、逆にそういった人たちが卒業していって、次なるスタートアップを作っていってくれることもすごいウェルカムだなと思ってます。

逆にそういったことを、今日はこの場に学生さんたちもいらしてると思うんですけど、少しでも聞いて、「なるほどな」と思って。そういった気持ちになっていただければ、すごいうれしいなとは思ってます。

やりたい技術に起業家精神が加わっただけ

及川：はい。芳賀さん、どうぞ。

芳賀：一応僕もMBAを取っているので、実際に事業を始めるとなると、本当に勝たなきゃいけないんですよね。グローバルでやっちゃうと世界中の人がいわゆる競合になるわけで。しかも、1社か2社ぐらいしか残らないという厳しい状況になります。

勝つための資源として、どうしても手に入れなきゃいけないコンポーネントがあります。それが買収でしか手に入らないといったら、それはもう選択肢がないんですよね。それがどこの会社かどこの国かはあまり大きな問題ではないとは思います。いいものを、僕たちが前に進んでちゃんとやっていくのに必要なものを、それを手に入れるというかたちにはなると思います。

及川：じゃあ、希少価値を生むぐらい、技術なり製品の魅力を高めていく。

芳賀：そうですね。もちろんそれは逆も言えることで。我々がそういうピースになったときには、そういった選択肢も出てくるんじゃないかなとは思っています。

及川：なるほど。わかりました。

玉川：私も芳賀さんと近くて。実はもうソラコム、買収はまだしてないんですけど、出資というのは行っていて。例えば、通信の中でも最近LPWAということで、Low Power Wide Area Network、省電力の広域通信のエリアが非常に注目されているんですけど。

その中の1つのテクノロジーでLoRaWANと呼ばれるテクノロジーがあります。そこに関してはM2Bという会社に出資をして、非常に高いテクノロジーを持っているので、そこと一緒になってLoRaWANの事業に展開する。

今年2月からLoRaWANの事業を始めているので、実は日本発のLoRaWANの商用化をやったんですけど。こういったようなかたちで、テクノロジーを持っている会社と一緒にやるのは非常にいいやり方だなと思っています。

及川：なるほど。やはりテクノロジーありき。あと岡田さんの話でいうと、起業家精神というところがそこに加わると、企業としても個人としても魅力があるでしょっていう話ですね。わかりました。

パッションを追いかけ続けた結果、今がある

あと4分ぐらいになってきましたので、最後、ちょっと締めのかたちで。最後に書いてあるエンジニア創業者として起業してよかったこと・苦労したことっていう質問があります。



先ほどのGoogleのAndroid、Boot CampだとかMachine Learningでみんな覚えさせてるみたいなところで。先ほど玉川さんの会社の紹介にもあったと思いますけど、やっぱりエンジニアリング的なみたいなものがあると思いますね。

なので、エンジニアの人たち、もしくはエンジニアではなかったとしても、会場の人たちに、今後のメッセージみたいなところを少し言ってほしいなと思うんですね。要は、エンジニア創業者から今日の参加者への言葉というところでまとめてもらえればと思います。どなたからいいでしょうか。じゃあ玉川さんからでいいですか？

玉川：そうですねえ、けっこう難しいテーマだと思うんですけど（笑）。
私自身、エンジニアとしてやってきて、リサーチャー、エンジニア、それからコンサルティング、エバンジェリストみたいな感じです。振り返ってみると、結局はパッションがあるところに一生懸命に力を注いでいって、VRやって、ウェアラブルやって、それでアジャイルやって、クラウドやって、1周してIoTに戻ってきたみたいな感じになり、結果的に会社を作っていることになっているので。狙ってたわけじゃないんですけど、結局はエンジニアあがりの創業者というかたちになりました。

非常に自分の人生としてはよかったかなと思っていて。connecting the dotsじゃないですけど、振り返ってみて初めてわかるんです。

僕の場合はパッションを追っかけてたらそうなったので、みなさんにぜひ自分のパッションを追っかけてほしいなと思います。

このイベントってInevitable、……そこの本の最初でも書いてあるんですけれども、テクノロジーってもう止まらないです。これはもう絶対にInevitableなので、そのテクノロジーの進化から逃げようと思ったって、エンジニアは絶対逃げられないと思うんですよね。なので、逃げるよりかは目を見開いてじっくり見て、自分のパッションがあるところを選んで使っていけばいいんじゃないかと思います。

私自身はそうしてきて、今非常にハッピーで、優れたチームメンバーに恵まれて、毎日楽しくやっております。ぜひ少しでも多くの日本のエンジニアにそういう道を選んでほしいなと思っています。

興味あるものの中から「のめり込めるもの」が見つかる

及川：ありがとうございます。岡田さん、お願いします。

岡田：私はどちらかというと、エンジニアもやりつつ、もともとデザイナーでご飯を食べてた時もあったり、いろんなことをやってきたんですね。なので、玉川さんと一緒かなと思うんですけど。その時その時にやってきたことが今、すべて糧になっているなと思ってまして。

会社をやっていると、どの部署が重要だとかあまりないと思ってるんですよね。全部重要なんですよね。なので、その重要性をちゃんと理解した上で、そこのバランスをとって経営ができているところに関しては、私はすごいよかったなと思っています。

逆に私自身が苦労してるところでいうと、首を突っ込んじゃう人なので、なるべく首を突っ込まないように、現場に任せていきたいなと思ってはいるんですけれども。

そういった面も含めて、逆に知ってるからこそメンバーを尊重できるじゃないですけど。「ここ大変だよね」と一緒に走っていけるところはすごいあるかなと思っていますね。

結論なんですけど、エンジニアの方だからこそ、エンジニアリングにもちろん興味持つのはぜんぜんいいと思うんですけど、いろんなことに興味を持っていろんなことに全力投球していく。なにか1つ「これだ！」みたいなものが見つかって。それにどんどんのめり込んでいけばすごい成功していけるのかなと、私は信じて進んでいます。

及川：ありがとうございます。じゃあ最後、芳賀さん。

芳賀：ありがとうございます。エンジニア経営者でよかったこととしては、そもそもInstaVRを作ったのは、ドバイにアプリを作るのがめんどくさくて、楽したくて会社を作ったんですよね。

実際に経営してると死ぬほどめんどくさいことがいっぱいある。めちゃくちゃ探すんですよ、エンジニアなので。人を雇うよりも「これSaaSになにかないの？」って。探すところは圧倒的な効率化につながってます。

あと、特許とか論文とかけっこうちゃんと読んじゃってるので。そうすると「そもそもここ特許取れてるから、やったって大丈夫だよね」と、事業選定とかで無駄な道をいかないとかは、エンジニアならではあるかなと思っています。

エンジニアじゃないところ、例えば経営論だったり、財務資料を読めたり、あとリーダーシップだったり。僕はY Combinatorのスタートアップスクールに1回行ったことがあるんですけど、Instagramの経営者もぜんぜんできてなくて。「いや、でもそれは訓練だよ」と、あそこのパートの人は言い切ってる。訓練しないからできないだけ。

なので、そこは恐れずに、訓練が足りてないだけだから。訓練……いわゆるコードを書いてない人と一緒で、訓練してないだけなので。そこはそんなものだと思って気にせず、起業していただければなと思っています。

及川：どうもありがとうございます。要は、やはりそれに対してパッションを持てるかというところだったり、いろんなものを経験したり。connecting dotsは、我々の会話の中でもよく出てくると思うんですけれども。どこかで長いキャリアのなかで、活かされてくることもある。

あとは、本当にひたすら必要だったら勉強していけばいい。どの年齢になっても同じだなというところなので。

テクノロジーに対しての可能性を信じている方が今日、会場に集まってると思いますので、こういった熱意ですとか、継続した勉強を続けていく。人口減少云々はありますけれども、技術でそこらへんを解決していくというような未来を考えていけたらいいかなということでまとめさせていただきます。
どうもありがとうございました。

いかがでしたでしょうか？　今後このようなテーマでの議論を定期的に開催していく予定です。


次回イベント開催のお知らせ
「Inevitable ja Night - インターネットの次にくるもの Presented by Google Cloud」
第2回 AI とビジネスに起こる不可避な流れ
日時 : 11 月 14 日 (火) 19 : 00 - 21 : 00
定員 : 200名
主催 : グーグル合同会社

Posted by Takuo Suzuki - Developer Relations Team