ビジネスアプリケーションプラットフォーム

Document AI: ドキュメント処理の要件に対応した統合 AI エージェント

Tue, 15 Nov 2022 04:00:00 +0000

※この投稿は米国時間 2022 年 11 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

このブログを Google ドキュメントに書きながら、私は、コミュニケーションやコラボレーション、ビジネスを行うために、私たちがデジタルドキュメントにどれだけ依存しているかを考えずにはいられません。それなのに、ドキュメント内にある大半のデータは相変わらず分析されないままの状態です。住宅ローンの申請や契約の処理など、顧客向けのワークフローで使われるドキュメントでも、企業はそれに含まれるデータの処理に苦慮することが少なくありません。組織全体の膨大な情報の中から適切なドキュメントを見つけるのさえ困難な場合もあります。このような問題を解決するために、ほとんどの組織は時間と人手を大量に必要とする手動プロセスに頼っています。いずれの手動プロセスも、ドキュメントワークフローの最前線にいる従業員にとって大きなストレスになっています。

こうした問題を踏まえ、私たちは 2020 年に Document AI をリリースしました。これは AI エージェントで、組織にとって特に困難なドキュメント自動化の問題に機械学習（ML）を適用できます。以来、住宅ローンの処理や調達など、業界固有のユースケース向けにデータを抽出する特殊なモデルを導入してきました。Google は、Cloud Next ‘22 で Document AI Workbench と Document AI ウェアハウスを発表し、組織によるドキュメント処理の簡素化と自動化を支援するという使命に向けて、注目すべき取り組みを続けています。それぞれの発表をダブルクリックしてみましょう。

Document AI Workbench によるカスタムドキュメント処理

Document AI Workbench を使用すると、ビジネスニーズごとにカスタム ML モデルを作成してドキュメントを処理し、高い精度で非構造化データを抽出できます。わかりやすいインターフェースにより、ML について専門的なスキルを持たないビジネスユーザーでも、モデルのトレーニングやアップトレーニングを開始できます。

さらに、組織が事前トレーニング済みモデルから転移学習を行い、たとえば新しいフィールドを含めることでモデルをさらに強化しようと考えた場合、ユーザーは「アップトレーニング」という機能によってそれを実現できます。アップトレーニング機能は、時間も人手も節約でき、ゼロから始める必要がないので、一般的ではあるものの複雑なユースケースの場合にとりわけ価値があります。請求書、注文書（PO）、契約書、W2、1099-R、給与明細、1040 といったドキュメントで事前トレーニング済みモデルをアップトレーニングすることで、精度の向上、新しい言語サポートの追加、スキーマのカスタマイズについて新たな可能性が開かれます。

Google は今後も事前トレーニング済みモデルへの投資を継続していきます。Next '22 では、請求書と経費の事前トレーニング済みモデルの更新を発表しました。この更新では、正規化と項目エンティティの検出が向上し、ID ドキュメントの偽造や改ざんを見つけるために設計された柔軟な API を使用した新しい ID 確認機能が改良されました。すでにサポートしている 12 の言語に加えて、請求書と経費のモデル全体で 5 つの新しい言語に対応しました。また、米国、EU、シンガポールのリージョンの他に、カナダとオーストラリアのリージョンでも利用できるようになりました。

Deloitte Consulting LLP のマネージングディレクターである Daan De Groodt 氏は、次のように話します。「（Document AI Workbench は）ドキュメント処理に大きな変革をもたらす可能性を秘めています。効果的な Google 機械学習モデルを活用してさまざまなテキストドキュメントやテキストフォームをアップトレーニングし、より望ましい精度を実現することで、クライアントの時間とリソースの利用効率を高められるようになったからです」。

ユーザーは、すでにさまざまなメリットを活用しています。Libeo は、Document AI を利用して、請求書パーサーを 1,600 件のドキュメントでアップトレーニングし、テストの精度を 75.6% から 83.9% に向上させました。「アップトレーニングのおかげで、現在、Document AI の成果は競合他社の成果を上回っており、長期的にモデルトレーニングの全体的な費用が約 20% 節約できることが見込まれます」と、Libeo の最高技術責任者である Pierre-Antoine Glandier 氏は話します。

Document AI ウェアハウスを使用した Google によるドキュメント検索

Document AI ウェアハウスにより、ドキュメントで Google のセマンティック検索を最大限に活用できるようになりました。Document AI ウェアハウスを使用すると、企業はドキュメントと、AI により抽出されたデータやメタデータを 1 つのプラットフォームで検索、保存、統制、管理できます。ユーザーは、Document AI ウェアハウスのシンプルかつ直感的でウェブアクセス可能なユーザーインターフェースを使って、ドキュメントを検索、表示、一括更新し、フォルダに整理することができます。エンタープライズ向けの堅牢な制御とガバナンス機能をもつ Document AI ウェアハウスは、ドキュメントレベルやフォルダレベルのアクセス権を持つユーザーを制御し、ドキュメントの表示、編集、管理（共有、削除）権限をユーザーやグループに割り当てます。Microsoft SharePoint、Amazon S3、IBM FileNet といった他のリポジトリからドキュメントの移行、同期、統合ができます。コンテンツと、抽出したメタデータやタグ付けしたメタデータを、インデックス登録のみ行うこともできます。

また、Google は今年末までに Document AI OCR と Form パーサーに多くの次世代プロダクトを追加、統合します。これには、ドキュメントの品質とセマンティクスに関する詳細な分析、ドキュメント OCR エクスペリエンスの統合、Form パーサーの対応言語の拡大、モデルのライフサイクル管理のための高度なツールの追加が含まれます。Google の DeepMind チームは、公共料金請求書や注文書用のドキュメント解析 ML モデルを、Document AI で従来必要とされていたよりも 50～70% 少ないトレーニングデータで作成できる新しい方法を開発しました。今後数か月以内に、この方法を Document AI Workbench に統合する予定です¹。

使ってみる

ドキュメントの自動化を簡素化する企業向けプラットフォームとして、Document AI の今後がとても楽しみです。ここで取り上げたすべての魅力的な開発について詳しくは、Next ’22 の私のセッションをご覧ください。いずれかのサービスを今すぐお試しいただくこともできます。

_{1. DeepMind は、公共料金請求書やさまざまなベンダーからの注文書などの Google 内部の何千ものドキュメントを使用して、この方法を開発し、評価しました。パフォーマンスは評価データセットによって異なります。}

- 言語および Document AI 担当プロダクト責任者 Sudheera Vanguri

Google Cloud を活用した PII の検索方法と保護方法

Tue, 13 Sep 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 9 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

BigQuery は今日の市場における代表的なデータウェアハウスソリューションであり、データに関する詳細な情報と高度な分析を必要とするお客様から高く評価されています。一般的な BigQuery のユースケースとして、多くの場合、個人を特定できる情報（PII）の保存と処理が含まれます。これらのデータは、Google Cloud 内で不正なアクセスや悪意あるアクセスから保護する必要があります。

BigQuery データから PII を検索して特定するプロセスは、そのほとんどを手作業による PII の検出と複製に依存しています。一般的な方法としては、PII に使用されている列を抽出して、アクセスが制限された別のテーブルにコピーする方法があります。ただし、このようにデータの余分なコピーを作成して手作業で PII を特定することで、ミスやその後のセキュリティイベントのリスクを高めてしまいます。

さらに、PII データのセキュリティは多くの場合、複数の規則によって義務付けられており、適切な安全保護対策を適用しないと、重い罰則が科される可能性があります。この問題に対処するために、お客様には、1) BigQuery で PII を識別し、2) そのデータにアクセス制御を自動的に実装して、不正なアクセスや悪用を防止するソリューションが必要です。

このブログでは、Google プロフェッショナルサービスにより開発された、Google Cloud DLP を活用してセンシティブデータを検査および分類するソリューションについて説明し、これらの分析情報を利用して BigQuery テーブル内のデータに自動的にタグ付けして保護するソリューションを提案します。

BigQuery 自動タグ付けソリューションの概要

Automatic DLP は、BigQuery 内の PII などのセンシティブデータを特定するのに役立ちます。組織は Automatic DLP を活用して、BigQuery データウェアハウス全体でセンシティブデータフィールドを含むテーブルを自動的に検索し、詳細な調査結果をコンソール（下の図 1 を参照）やデータポータルで、構造化された形式（BigQuery 結果テーブルなど）で報告できます。新しく作成されたテーブルや更新されたテーブルは、ユーザーが呼び出しやスケジュール設定をしなくても、バックグラウンドで自動的に検出、スキャン、分類できます。このようにして、センシティブデータを継続的に確認できます。

図 1: BigQuery におけるセンシティブデータフィールドの可視化

今回は、BigQuery 自動タグ付けソリューションという新しいオープンソースソリューションが、データのアクセス制御の自動化という第二の目標をどのように解決するのかを紹介します。このソリューションは、Automatic DLP の上位レイヤとして位置づけられ、列レベルのアクセス制御を自動的に実施して、ユーザー定義のデータ分類法（高機密性や低機密性など）と分野（マーケティング、財務、ERP システムなど）に基づいて、特定のセンシティブデータタイプへのアクセスを制御します。このソリューションは、PII へのアクセスが無制限な状態のリスクを最小限に抑え、列レベルまで適切なアクセス制御を適用したうえで、データのコピーが 1 つだけであることを保証するものです。

このソリューションのコードは、GitHub の GoogleCloudPlatform/bq-pii-classifier で公開されています。Google はこのコードを管理していませんが、このコードを実装する方法については、営業担当者経由で Google プロフェッショナルサービスチームまでお問い合わせください。

BigQuery と Data Catalog ポリシータグ（現在の Dataplex）にはいくつかの制限があり、このソリューションを実装する前に、お客様の組織で確実に機能するかを確認する必要があります。

分類とポリシータグはリージョン間で共有されない: 複数のリージョンにデータがある場合は、ポリシータグを適用するリージョンごとに分類を作成または複製する必要があります。
プロジェクトあたりの分類数は最大 40 個: ビジネス分野ごとに異なる分類が必要な場合、または複数のクラウドリージョンをサポートするためのレプリケーションがある場合、これらの分類はこの割り当てにカウントされます。
分類あたりのポリシータグは最大 100 個: Cloud DLP は、分類の infoType を最大 150 個サポートしますが、1 つのポリシー分類では、ネストされたカテゴリを含めて最大 100 個までしかサポートできません。100 以上のデータ型をサポートする必要がある場合、複数の分類に分割する必要があります。

ソリューションの概要

図 2: ソリューションのアーキテクチャの概要

このソリューションは、主に Dispatcher Requests トピック、Dispatcher サービス、BigQuery Policy Tagger Requests トピック、BigQuery Policy Tagger サービス、ロギングコンポーネントで構成されています。

Dispatcher Service は、BigQuery スコープがプロジェクト、データセット、テーブルの包含リストと除外リストとして表現されることを想定した Cloud Run サービスです。この Dispatcher サービスは、Automatic DLP データプロファイルにクエリを実行して、スコープ内のテーブルにデータプロファイルが生成されているかどうかを確認します。これらのテーブルでは、テーブルごとに 1 つのリクエストを「BigQuery Policy Tagger Requests」Pub/Sub トピックにパブリッシュします。このトピックは、BigQuery 列のタグ付けオペレーションのレート制限を有効にし、バックオフによる自動再試行を適用します。

また、「BigQuery Policy Tagger」サービスも、BigQuery テーブルの DLP スキャン結果の情報を受け取る Cloud Run サービスです。このサービスは、各列の最終的な InfoType を決定し、InfoType - ポリシータグのマッピングで定義されている適切なポリシータグを適用します。INFO_TYPE が 1 つのみ選択され、関数により関連するポリシータグが割り当てられます。

最終的に、すべての Cloud Run サービスは、ログシンクによって BigQuery にエクスポートされる構造化ログを保持します。Cloud Run の呼び出しチェーンのモニタリングやデバッグ、列へのタグ付けアクションに役立つ BigQuery ビューが複数用意されています。

デプロイについて

このソリューションは、デプロイ後に 2 つの異なる方法で使用できます。

[オプション 1] Automatic DLP トリガーによる即時タグ付け:

図 3: デプロイオプション 1 - Automatic DLP トリガーによる自動タグ付けと検査

Automatic DLP は、検査ジョブが完了するたびに Pub/Sub 通知を送信するように構成されています。Pub/Sub 通知にはリソース名が含まれており、それが Tagger サービスを直接トリガーします。

[オプション 2] スケジュール設定されたタグ付け:

図 4: デプロイオプション 2 - スケジュール設定されたタグ付けと検査

このシナリオでは、BigQuery スコープを表すペイロードを使用してスケジュールに基づいて Dispatcher サービスが呼び出され、Automatic DLP によって検査されたテーブルが一覧表示されて、テーブルごとにタグ付けリクエストが作成されます。Cloud Scheduler（または任意のオーケストレーションツール）を使用して Dispatcher サービスを呼び出せます。ソリューションが VPC-SC 境界内にデプロイされている場合は、VPC-SC をサポートする他のスケジューラー（Composer やカスタムアプリなど）を使用する必要があります。

さらに、複数の Cloud Scheduler / Trigger を定義して、同じタグ付けスケジュール（毎日または毎月など）を持つプロジェクト / データセット / テーブルをグループ化できます。

Automatic DLP の詳細については、Google のウェブページをご覧ください。BQ 分類器の詳細については、GitHub のオープンソースプロジェクト: GoogleCloudPlatform/bq-pii-classifier をご覧いただき、ぜひ今すぐお試しください。

- 戦略的クラウドエンジニア Karim Wadie
- EMEA セキュリティプラクティス責任者 Nikhiel Sawhney

Apigee API 管理への従量課金制の導入

Tue, 06 Sep 2022 00:20:00 +0000

※この投稿は米国時間 2022 年 8 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

Apigee は、組織で API の構築、運用、管理、収益化を行うための Google Cloud の API 管理プラットフォームです。Apigee は世界中の各業界のお客様からも高く評価されており、API プログラムの構築とスケーリングに使用されています。

一部の組織では確立した API ファースト戦略がとられている一方で、モダナイゼーション戦略に今なお取り組んでいる組織もあります。組織内部でも、さまざまなチームが異なるユースケースや API 管理方法を使用していることが多く見受けられます。Google とお客様の対話の中で、このように多様化しているワークロードに機能や料金を適合させる必要があるという声が多く寄せられるようになりました。

今回、従量課金制の料金モデルを導入して、お客様が費用を柔軟に管理しつつ Apigee の API 管理機能を活用できるようにしました。本日から、従量課金制で Apigee をご利用いただけます。この新しい料金モデルは、既存のサブスクリプションプランや無料評価機能を補完するものとして提供されます。

従量課金制で小規模でもパワフルに始める

新しい従量課金制料金モデルは高い柔軟性を備えており、組織は以下を行えるようになります。

事前契約なしで Apigee を活用: 事前購入や事前契約をせずにすぐに利用できます。
費用面の柔軟性と管理性を維持: 費用を抑えつつ、変化し続けるニーズに適応できます。使用量に基づいて、従量課金制での自動スケーリングを継続、またはサブスクリプションティアへの切り替えを行うか判断できます。
自由なテストを実現: API 管理のユースケースはそれぞれ異なります。従量課金制では長期契約がなくても Apigee を活用して、新しいユースケースを試すことができます。

従量課金制の仕組みも他の Google Cloud の課金制と同様に、ライセンス契約や事前購入をしなくても開始できます。従量課金制料金モデルでは次の項目の使用量に対してのみ課金されます。

Apigee ゲートウェイノード: API トラフィックは、1 分あたりに使用される Apigee ゲートウェイノード（API トラフィックを処理する環境の単位）の数に基づいて課金されます。プロビジョニングするすべてのノードに毎分課金され、1 分を最低単位として請求されます。
API 分析: 1 月あたりに分析された API リクエストの総数に対して課金されます。API リクエストは、成功したものもしなかったものも、Apigee 分析で処理されます。分析データの保存期間は 3 か月です。
ネットワークの使用量: ネットワーク（IP アドレス、下り（外向き）ネットワーク、転送ルールなど）は、使用状況に応じて課金されます。

従量課金制が適しているユースケース

Apigee では、3 つの料金モデルをご用意しています。

評価プラン: Apigee の機能を 60 日間無料で利用可能
サブスクリプションプラン: API ニーズが予測可能でボリュームが多い場合。標準、企業、Enterprise Plus の 3 つをご用意
従量課金制: 開始費用なし

サブスクリプションプランは特定期間のワークロードが予測可能なユースケースに適しています。従量課金制は、高価値ワークロードで小規模に開始する場合に最適です。以下は、従量課金制の適したユースケースの例です。

使用パターンが固まってからサブスクリプションモデルを選択する場合
API プログラムを高価値、少ボリュームの API ユースケースで開始して、後で変更する場合
Google Cloud インフラストラクチャ上に構築されたアプリケーションを管理、保護する場合
サービスを中断することなく少しずつ移行またはモダナイズする場合

次のステップ

新しいアプリケーションの構築、最新のアーキテクチャの採用、新しいエクスペリエンスの創出に際して API に頼る動きがあらゆる組織で強くなっています。このような変革の中、Apigee の従量課金制は柔軟性を提供するもので、組織は小規模から開始して API 管理ニーズに合わせてシームレスにスケーリングできます。

Apigee の従量課金制の利用を開始するには、コンソールに移動します。または、こちらから無料版をご利用いただけます。

Apigee API 管理の従量課金制の詳細については、ドキュメントと料金計算ツールをご確認ください。比較やその他の情報については、料金ページをご覧ください。

- Google Cloud プロダクト担当ディレクター Vikas Anand

Looker とデータポータルで BI の 2 つの要素を同時に実現する

Fri, 15 Apr 2022 02:00:00 +0000

※この投稿は米国時間 2022 年 4 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

今日のデータの世界では、企業は、ユーザーにわかりやすい形で分析情報を提供するために、多くのシナリオを検討する必要があります。一方では、ミッションクリティカルなビジネス機能に情報を提供するために、信頼性の高い、統制のとれたレポートを提供する必要があり、もう一方では、幅広いユーザーが自分で答えを見つけられるように、アジャイルなセルフサービスを提供する必要があります。

データドリブン型企業は、関連するデータへのアクセスを民主化し、ビジネスユーザーが迅速に答えを得られるようにしたいと考えています。ここでトレードオフとなるのはガバナンスです。信頼できる唯一の情報源の共有、データアクセスのきめ細かなコントロール、安全な集中ストレージを維持するのは簡単ではありません。スピードや利便性は、信頼や安心と対立します。企業は、組織内のすべてのユーザー（技術系、非技術系を問わず）が簡単に使用でき、かつリアルタイムで指標を管理できる BI ソリューションを求めています。

このたび、Google は、Looker とデータポータルの統合に向けた最初のマイルストーンを発表しました。これにより、セルフサービス型とガバナー型双方の BI の統合エクスペリエンスの実現が一歩近づきました。ユーザーは、データポータルのインターフェース内の Looker から管理されたデータにアクセスしてインポートし、ビジュアライゼーションやダッシュボードを構築して、セルフサービスで詳細な分析を行えるようになります。

この Looker とデータポータルの統合で、ユーザーは Google Cloud BI の完全な統合ソリューションを利用できるようになります。ビジネスユーザーはこれまで以上に力を発揮し、データリーダーは組織が必要とする信頼性と安全性を維持できます。

セルフサービス型とガバナー型 BI を組み合わせることで、企業はデータドリブンのより良い意思決定を行うことができるようになります。

Looker とデータポータルのより良いコンビネーション

Looker は、ビジネスインテリジェンスと分析のための最新のエンタープライズプラットフォームです。Looker を利用することで、ビジネスのあらゆる要素にフィットするデータリッチな環境を構築できるようになります。データポータルは、使い勝手の良いセルフサービス型の BI ソリューションで、500 以上のデータセットに対してアドホックなレポート作成、分析、わかりやすいデータ表示を可能にします。

Looker とデータポータルは、補完的に利用することができます。Looker とデータポータルを組み合わせ、2 つのプロダクトの長所と幅広い BI および分析機能を統合することで、データ活用の方法を再定義する絶好の機会が生まれます。

統合はどのように行われますか？

プロダクト間の最初の統合では、ユーザーはデータポータルから直接 Looker のセマンティックモデルにアクセスできるようになります。分析したいデータを取り入れ、他の利用可能なデータソースと接続して、データポータル内で簡単に確認してビジュアリゼーションを構築できます。この統合は、ガバナンスの 3 つの原則に沿うように行われます。

データへのアクセスには、Looker のユーザーインターフェースを使用する際と同様の、Looker のセキュリティ機能が適用されます。
Looker は、今後もお客様のデータへの単一アクセスポイントとして機能します。
管理者は、データポータルと Looker を同時に管理できる完全なアクセス権をもつことになります。

プロダクトを統合する方法

これは、この 2 つのプロダクトをより近づけるためのロードマップの第一段階です。Looker のセマンティックモデルでは、指標を一元的に定義して幅広く利用でき、すべてのデータが「コピーをもたない」というバージョンの信頼性を確保できます。この統合により、Looker のセマンティックモデルをデータポータルのレポート内で使用できるようになり、一つのツールでアドホックデータとガバメントデータの両方を利用したレポートを作成できるようになります。ガバメントデータの保護と、ガバメントデータと非ガバメントデータの両方を分析できるセルフサービスソリューションという、両方の長所を併せ持つことになります。

今回の発表では、以下のユースケースがサポートされます。

Looker で管理されたデータを、データポータルでカスタマイズ可能かつ有益なダッシュボードやレポートに変換。
Looker で管理されたデータを、データポータルで 500 以上のデータソースの利用可能なデータとミックスし、新しい分析情報をアジャイルに生成。
データポータルで、スプレッドシート、csv ファイル、他のクラウドソースからの非ガバナンスデータを分析し、素早くプロトタイピング。
チームメンバーや社外ユーザーとのリアルタイムの共同編集でダッシュボードを作成。

利用可能になる時期

Looker 用のデータポータルコネクタは、現在プレビュー版です。お試しになりたい方は、フォームに記入して送信してください。

次のステップ

今回の統合は、Looker とデータポータルをより密接に連携させるための取り組みの、ほんの始まりに過ぎません。今後のリリースでは、2 つのプロダクト間でよりシームレスなユーザーエクスペリエンスを実現できる機能を追加していく予定です。今後数か月間の新機能の展開にご期待ください。2 つのプロダクトの統合については、随時お知らせしていきます。

- アウトバウンドプロダクトマネージャー、Ani Jain
- プロダクトマネージャー、Andrew Becker

Google Cloud で予測市場を作成する

Tue, 14 Dec 2021 03:00:00 +0000

※この投稿は米国時間 2021 年 12 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

予測分析は長い間、革新的な企業が戦略的優位性を獲得するための情報源となってきました。高い業績を上げている企業は、将来の結果をより正確に予測し、未知の出来事に対する計画を立て、製品の機会や顧客機会を見つけるために、強力な予測分析を使用しています。

予測分析における課題の一つは、予測の精度を上げるために行う過去のデータの生成です。非常に重要な質問であっても、利用できるデータが少なく、機械学習モデルのトレーニングが困難な場合も少なくありません（例: COVID-19（新型コロナウイルス感染症）によってサプライチェーンはどのような影響を受けているか、新しいテクノロジーにはどのような効果があるか）。

予測分析のお客様は、従業員、パートナー、ベンダーの判断に頼ることでそのギャップを埋めているのが現状です。そこで Google は考えました。どうすれば予測分析はより厳密なものになるでしょうか。Google の集合知を予測モデルで機械学習と組み合わせたらどうなるでしょうか。

2020 年、パンデミックにより先行きの見えない状況に直面した Google 社員の一グループは、これを Google Cloud で試すために内部的な予測市場を立ち上げました。Google は 2005 年から 2007 年にかけて初めて予測市場を実行し、有望な結果を残しました。現在のチームには、2005 年にはなかった 2 つの強みがありました。Google に参加できる多くの人材がいることと、Google Cloud 上にプラットフォームを構築できることです。

構造化と設計を繰り返し、1 万人以上の Google 社員から寄せられた 175,000 件以上の予測を分析しました。今回はその中で、COVID-19 や、エンジニアリングマイルストーン、新しいテクノロジーのトレンドなど、難易度の高い分野で正確な予測を生成するのに役立った設計パターンとテクノロジーをご紹介します。

予測市場を構造化する方法

予測市場の背後にある分析情報の中核は、適切な人にインセンティブを与えて正確な予測をさせることで、どの個人よりも正確なコンセンサス予測を生成することです。

たとえば、「2022 年に金利が上昇するか」という質問について予測するとします。顧客行動の予測や、さらにはマクロ経済の動向の予測を行う ML モデルがすでにあるかもしれません。しかし、この種のイベント予測には、組織内の人材の知識と判断を活用する必要があります。

このような質問について未来を正確に予測することは非常に困難です。その一方で、ついつい単純な答えに飛びつきたくなってしまいますし、反対に誰も知り得ないと悲嘆するのも簡単です。しかし実際には、正しい構造を使用すれば組織は驚くべき精度を達成できることが、予測市場や予測トーナメントによって実証されています。

Google はこれまでの経験に基づき、組織から正確な予測を引き出すための 5 つの基本原則を導き出しました。順を追って説明します。

1. 適切な UI を用意することで、きめ細かい正確な予測が表現しやすくなる。

ほとんどの質問は、確率（下の例を参照）、日付（「金利はいつ上昇するか」）、または数値（「来年の金利はいくらになるか」）の予測として提起できます。これらを予測するにあたり、2 つの方法を選べるようにしました。（a）ワンクリックで、現在のコンセンサスよりも確率 / 日付 / 数値が低いか高いかを予測する方法、そして（b）具体的な予測を範囲で示す方法です。

例として次のような確率の市場を考えてみましょう。

上部の UI から、確率がコンセンサスの範囲を下回っていると思うか、上回っていると思うかを素早く指定できます。また、確率の範囲を設定することで、よりきめ細かい予測の指定が可能になります。この際、確率が水準内に収まるかどうかの確信の度合いを下限と上限で個別に指定することができます。

全員が同じことを予想できるよう、解決の条件を厳密に設定することに特に注意を払ってください。正確な予測は、質問が正確に定義されて初めて可能になります。新しい質問の提案を確認するために組織から管理者を任命し、ソースデータと期間が正しく選択されるようにします。

2. 組織からスペシャリストを選出してインセンティブを与え、豊富な知見に基づいて質問に対する予測を行ってもらう。

他の予測市場と同様、Google のインセンティブシステムにもオプション市場との類似があります。予測を「bid（売値）」と「ask（買値）」に変換し、確率、数値、日付を「price（価格）」と解釈、信頼度を「volume（数量）」と解釈します。アプリケーションブローカーは、対立する bid と ask を最適な price でマッチさせます。次の疑似コードで示されるように、取引が行われると、当事者間に契約が成立します。

code_block: <ListValue: [StructValue([('code', 'def process_bid(event, bid):\r\n """Trades a bid against the best priced asks."""\r\n unfilled_bid_volume = volume\r\n for ask in _get_asks_by_increasing_price(event):\r\n # 次の ask price が bid price より高いか、この bid で\r\n # 約定した場合、それ以上の取引は行われません。\r\n if unfilled_bid_volume == 0 or ask.price > bid.price: \r\n break\r\n\r\n # この ask が残りの volume の約定に必要な値より大きい場合、\r\n # 残りを取引します\r\n if ask.volume > unfilled_bid_volume:\r\n ask.volume -= unfilled_bid_volume\r\n _execute_trade(event, bid, ask)\r\n break\r\n\r\n # そうでない場合は、この bid で ask のすべての volume を取引します。\r\n unfilled_bid_volume -= ask_volume\r\n ask.mark_filled()\r\n _execute_trade(event, bid, ask)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdd16513b50>)])]>

金融市場が注文を効率的にマッチさせることでコンセンサス価格を見つけるのと同様に、予測市場は予測を効率的にマッチさせることでコンセンサス予測を見つけます。これにより、予測者のインセンティブが最大化され、よりよい予測を行うことで市場を修正する機会を生み出します。現実の世界で更新が行われて問題が解決すると、取引された契約一つ一つで、一方の当事者がインセンティブを得ます。同時に、双方ともにその経験から学ぶことができます。

3. 継続的な予測をサポートすることで、新しい情報が入ってきたときにコンセンサス予測がリアルタイムに更新されるようにする。

予測分析でとりわけ問題となるのは、新しい情報がどの時点でも表面化する可能性があることです。bid と ask として解釈された予測の傾向は、時間の経過とともに、参加者全員のコンセンサスを表すようになります。bid-ask スプレッド（取引相手が見つかっていない時点の bid と ask の値）をグラフ化することで、コンセンサスの進化を確認できます。

これは、COVID-19 に関連する確率（0～100%）の質問に対するコンセンサス予測の例です。青い線は bid の最高値、赤い線は ask の最低値を表しています。イベントが 9 か月間にわたって展開されるにつれ、確率が最低 10% から最高 90% まで変動しているのが確認できます。

4. 予測者へのパフォーマンスに関するフィードバックで、予測精度の長期的な改善を促す。

質問が解決したら、ユーザーに結果を通知するだけでなく、パフォーマンスを状況に合わせて分析できます。たとえば、そのカテゴリ、または現四半期でどのくらいの成果を上げているでしょうか。トップの予測者と比べてどうでしょうか。

好成績の予測者へのインセンティブとして、リーダーボードやバッジを付与するだけでなく、市場コンセンサスへの影響力が強まるよう、その人の予測の信頼性を高めます。次第に予測者は、より正確に予測できるトピックに魅力を感じるようになり、結果的に市場全体の予測精度も向上します。

職場で使用する他の多くのスキルと同様に、予測も時間をかけて改善させていくものです。インセンティブとフィードバックが適切に構造に組み込まれていれば、個人レベルでも市場全体でも精度の向上が期待できます。ここで重要なのは、より短い時間軸で質問を設定することです。「来年の新しいサービスの採用率はどうなるか」を問うのではなく、次の四半期の採用率を予測することから始め、それを反復します。

Google の内部予測市場に寄せられた、確率に関する最初の 200 の質問。質問に対する答えが得られる 6 か月前、3 か月前、2 か月前、1 か月前、1 週間前に集計した Google 社員のコンセンサスの確率（0～10%、10～20% など）を基準に質問をグループ化し、実際に起こったことと比較します。

青い線は完全な精度を表しています。つまり、10% の確率で起こると予測されたイベントが、10% の確率で実際に起こるということです。赤い線は市場コンセンサスの予測を表しています。非常に難易度の高い質問であっても、市場はかなり正確です。

5. 市場予測を機械学習と総合的に扱う

予測市場は、過去のデータが十分でなく、機械学習だけに頼ることができない場合に、そのギャップを埋めることができます。戦略的な意思決定に役立つデータはある程度持っているものの、正しい選択を判断できるほど十分ではないというのはよく見受けられる状況です。たとえば、あるプラットフォームにはお客様の消費行動に関する十分な時系列データがあるが、リリース前の新しいプラットフォームにはまだ何もないかもしれません。

予測市場と機械学習を総合的に利用する方法は 2 つあります。1 つ目の方法は、予測市場の出力をより大規模な予測分析システムの入力として使用する方法です。入力用のデータは、時系列データに対して機械学習の推論を実行することでも引き出すことができます。2 つ目の方法は、機械学習システムをマーケットメーカーとして追加し、ベースラインとなる bid-ask スプレッドと流動性を提供することで、正確な予測に対するインセンティブを高める方法です。

Google Cloud 上でプラットフォームを設計する

Google Cloud Platform（GCP）を活用することで、Google は少人数のチームで 1 年以内にプラットフォーム全体を構築し、何千人ものユーザーにスケーリングできました。堅牢なプラットフォームを非常に短期間でプロトタイプ化、構築、拡張するために使用した GCP ツールを具体的にご紹介します。

サーバーレスをプラットフォームの主軸として使用しました。App Engine を使用し、さらに取引のバックエンドを実装するために Cloud Run と Cloud Functions でもテストを行っています。

サーバーレスは優れたツールキットで、アプリケーションをビルドしてから、Compute Engine 上で使用するセルフマネージドのバックエンドの種類を決定できます。デプロイ、バージョニング、リソースのスケーリングに追加のコードを記述する必要がないため、バックエンドのアーキテクチャの柔軟性が確保されます。

Cloud Scheduler と Cloud Tasks はサーバーレスアーキテクチャをうまく補完し、成績優秀者へのバッジ付与のような定期ジョブや、市場の解決や分析の計算といった長時間にわたるバックグラウンドタスクの実行が容易になります。
Cloud Firestore は Datastore モードで実行し、アプリケーションデータベースとして利用します。スケーラブルな NoSQL クラウドデータベースなので、フロントエンドを柔軟性に作成でき、新しい機能を設計してビルドしてもすぐにスキーマを更新できます。また、複雑な階層構造のデータもサポートしています。今回のケースでは、bid、ask、取引済みポジションをマーケットエンティティの子として保存することで、データのクエリを迅速かつ簡単に実行できるようにしました。

データポータルを使用することで、たとえば、時間の経過に伴う市場全体のトレンドを可視化するなど、予測結果から得られる分析情報をダッシュボード化できます。Looker を使用すれば、市場予測と既存の予測分析を集約して、どちらか一方だけでは生成できない優れた分析情報を生み出すことができます。
分析向けの BigQuery や機械学習向けの BigQuery ML への簡単なエクスポートにも対応しており、人間のコンセンサスをアルゴリズムで絞り込むことができます。そのデータを基に GCP の Vertex AI の機能で予測モデルをトレーニングすれば（ほとんどコードを記述する必要はありません）、難しい戦略的な質問に対しても、人間と機械の推論を最良の形で組み合わせることができます。

Dataflow では、バックアップからの復元など、データストアでの大規模なバッチ処理を、マネージドプロセスとして実行できます。

予測市場の運営面でも、さまざまな基本的な GCP ツールを使用しています。使用したもの:

Logs Explorer を使用して、クエリがタイムアウトしたときや、内部 API で問題が発生したときなど、厄介な状況でのデバッグを実行しました。
Cloud Profiler と Cloud Trace は、非同期でよい Cloud Firestore クエリの不必要な同期実行といったスケーリングのボトルネックを早期に特定するのに役立ちました。
Cloud Error Reporting により、エラーのモニタリングの構成、根本的な問題への素早いアプローチ、より頻繁に発生しているエラーの特定が容易になりました。

使ってみる

予測分析を一つ上のレベルに引き上げ、組織の知恵を存分に活用する準備はできましたか。Google Cloud を利用したこのようなプラットフォームの構築についてさらに説明をお受けになりたい場合は、こちらのフォームにご自身の情報をご記入ください。

- シニアソフトウェアエンジニア Dan Schwarz

- 製造担当主要アカウントディレクター Lindsay Taylor

Forrester、Google AppSheet を自社開発向けのローコードプラットフォームのリーダーに選出

Mon, 08 Nov 2021 10:00:00 +0000

※この投稿は米国時間 2021 年 11 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

業界をリードするグローバルな調査および顧問企業 Forrester Research が最近リリースしたレポート「Forrester Wave™: Low-code Platforms for Business Developers」（2021 年第 4 四半期）において、Google AppSheet がリーダーに選出されたことをご報告いたします。この成果は、業務アプリによって解決可能な課題に最前線で取り組み、自社開発を担っている皆様の貴重なコミュニティによる功績といえるでしょう。AppSheet を使用して数百万個ものアプリを作成しただけでなく、コラボレーション型のアプローチにより、時間と人材を節約するためのカスタムソリューションを構築するあらゆるユーザーを支援するという、Google の使命をさらに推進してくださいました。

AppSheet は、プロダクトビジョンと計画的な機能強化の基準において最高の評価を獲得しました。Forrester のレポートでは次のように説明されています。

「AI を活用したシチズンデベロップメントに対する AppSheet のビジョンは独自性があり、Google に特に適しています。この巨大テクノロジー企業の豊富な資金とエコシステムの恩恵により、AppSheet は市場開拓、市場における認知度、プロダクトのロードマップにおいて優位に立っています。」

「AppSheet のプロセス自動化と AI の機能は業界の先端を行くものです。このプラットフォームが提供するクリーンで直感的なモデリング環境は、長期にわたるプロセスと、トリガーによる自動化の両方に適しています。また、ドキュメントの取り込みのような便利で実用的な AI サービスも提供しています」とも評されています。

Carrefour Property、Carmila、Globe Telecom、American Electric Power、Singapore Press Holdings（SPH）のような数多くの大手企業や、あらゆる業界の何千もの組織のお客様が、自社開発のパートナーとして AppSheet を選んでくださっています。こうしたお客様のお役に立てていること、そして Forrester Wave™: Low-code Platforms for Business Developers のリーダーに選ばれたことを光栄に思います。今後もお客様のデジタルトランスフォーメーションを支援する革新的な取り組みを続けていきたいと考えています。レポートの全文はこちらからダウンロードできます（メールアドレスをご入力ください）。AppSheet について詳しくは、ウェブサイトをご覧ください。

- Google Cloud ビジネスアプリケーションプラットフォーム、プロダクト担当責任者、Vikas Anand

API で通信事業エコシステムの価値を創造: STC のデジタルトランスフォーメーション

Fri, 05 Nov 2021 05:00:00 +0000

※この投稿は米国時間 2021 年 10 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回は、STC の技術および運用担当シニアバイスプレジデントの Haitham AlFaraj 氏と、アプリケーション担当バイスプレジデントの Yazeed Alfaris 氏に加え、アプリケーション計画・統制担当 GM の Faisal Alhatlani 氏にお話を伺いました。STC は同名でビジネスを展開しており、1998 年以来サウジアラビアとその周辺地域における通信業界を牽引しています。STC がデジタルトランスフォーメーション戦略の一環として API を使用してビジネスを拡張し、パートナーやお客様とより効果的に連携している方法をご紹介します。

通信事業会社の世界は変わり続けています。今や、人、情報、サービスがかつてないほどつながり、事実上すべてのサービスをオンデマンドですぐに使用できることが期待されるデジタル時代となっています。STC はすでに中東の通信業界のリーダーであるとはいえ、競争の激しい分野でトップの座を維持するには、成長を続け、価値ある体験をお客様に提供する必要があります。

私たちは将来に備えて 4 本柱の戦略を導入し、サウジビジョン 2030 に対応しています。当社の「DARE」戦略は、STC のデジタル化、コアアセットのパフォーマンスの加速、世界標準でのカスタマーエクスペリエンスの刷新、規模と範囲の拡大という目標を中心として構築されています。若者や起業家向けのデジタルプラットフォームとなり、強力なエコシステムを構築することで、サウジアラビアのさまざまな日常活動をモダナイズするように努めています。

デジタルトランスフォーメーションは、こうした各柱の芯となるものです。私たちは、デジタル化による成長、変化、進化を図るあらゆる方法を検討し、API が変革に不可欠であることを認識しました。ビジネスのあらゆるレベルで API を導入することで、組織内外の利用者に向けてデジタルサービスの安全性とアクセスを強化し、パートナーエコシステムとの連携を効率化して、新しいカスタマーサービスを迅速に提供できます。

全社的に API を導入

API の可能性を最大限に発揮できるように、社内グループでも API ファースト戦略の推進を開始しました。冗長になる可能性のある使い捨て機能やポイントツーポイント統合を数多く作成するのではなく、社内チーム、パートナー、他の STC Group の子会社が再利用できるプロダクトとして API を構築するようチームに指示しました。すでにさまざまなユースケースで 100 を超える API プロダクトを導入しており、拡大を続けています。

自社 API プロダクトのセキュリティ、ランタイムガバナンス、シームレスなオンボーディングエクスペリエンスに関する API プログラム要件の増加に応じられる、、堅牢かつスケーラブルで柔軟な API 管理ソリューションが必要でした。当社のデジタルアーキテクチャにとって重要なコンポーネントとなるため、その選択は容易ではありませんでした。包括的な評価プロセスを経て、いくつものソリューションを調べました。

最終的に、当社は Google Cloud の Apigee API 管理プラットフォームを選びました。Apigee は強力なセキュリティと機能を備えているうえ、プラットフォームが非常に使いやすい点を高く評価しています。実装以来、Apigee から強力なサポートとソートリーダーシップが提供されているため、正しい選択をしたという確信がいっそう強まりました。

Apigee は、サービスプロバイダが IT と運用のアジリティを改善し、顧客中心主義をさらに進めることを目的とした TM FORUM Open API への参加など、革新的なデジタルトランスフォーメーションイニシアチブへの参画を可能にすることで、私たちの API プログラムを成功に導いてくれました。

API プログラムの成功は API トラフィック量にも表れています。子会社による使用から、API トラフィック量は 2020 年第 1 四半期から 2021 年第 1 四半期にかけて 300% 以上増大しました。

デベロッパーの成功を優先

API を使用し、STC のお客様に新しいサービスを提供するのはデベロッパーです。そのため、デベロッパーは API ファーストの考え方を成功させる鍵となります。デベロッパーが API を利用して成果を収めるには、一元化されたデベロッパーポータルを通じたシームレスなセルフサービスのオンボーディングエクスペリエンスを構築することが重要であると私たちは考えています。API デベロッパーポータルがあれば、デジタルアセットとそれが提供する価値の全体像を把握できるだけでなく、API 導入を加速し、API を見つけやすくすることもできます。

この方向に舵を切るために、STC は Apigee を活用する統合 API デベロッパーポータルを作成しました。Apigee デベロッパーポータルは非常にシンプルで、迅速かつ簡単にオンボーディングでき、デベロッパーは API についての確認やテスト、簡単な登録をすべて 1 か所で行うことができます。セルフサービスを利用できると、大企業と連携しているか、独立してアプリを作成しているかに関係なく、デベロッパーコミュニティのより多くのメンバーが当社の API を探索することができます。これにより、さらに多様なサービスや大きな価値がお客様にもたらされます。

デベロッパーポータルはすでにリリースされており、数十人の内部デベロッパーがオンボーディングしています。主要なイニシアチブを推進する内部 API をリリースし、パートナーエコシステム向けの API もいくつかリリースしました。一般公開すれば、デベロッパーと API の数が大幅に増加すると予想されます。Apigee によって、当社のシステムを引き続き拡大し、すべてのユーザーに優れたエクスペリエンスを提供できると確信しています。

新しいカスタマーサービスの提供

パートナー向けにリリースした最初の API の一つは、キャリア決済（DCB）API です。これにより、STC のお客様は STC の請求書を通じてパートナーサービスの料金を支払うことができます。パートナーごとに独自の統合を作成する必要がなくなり、パートナーは DCB API を使用して接続することができます。そのため、Netflix、Apple、Microsoft、Amazon などの新しいパートナーを記録的な速さでオンボーディングできました。お客様はこうした新しいサービスに非常に肯定的な反応を示し、登録は着実に増加しています。

また、STC Pay の開始に必要な API の作成と提供の管理にも Apigee を使用しました。STC Pay は、STC Group の安全なデジタルウォレットソリューションです。Apigee を実装する前は、このソリューションを実行するための基盤を作成するまで 1 年近くかかったかもしれません。しかし、API ファースト戦略と強力な API 管理機能を実装することで、わずか 3 か月で STC Pay の提供を開始できました。この結果は、API が新しいビジネスを開拓し、STC のリーチを拡大するのにどれほど有効かを示しています。

デジタル化の未来に向けて

私たちは現在、API を使用して STC アセットを収益化し、新しい収益源を生み出す方法を理解するため、複数のビジネスユニットと協力しています。また、STC Kuwait や STC Bahrain など、STC Group 全体の子会社まで API 管理を拡大する予定です。これにより、API を通じたコラボレーションと共有の可能性が広がります。

現在の API 管理プログラムは、当然ながら連携 API プラットフォームへと進化しており、複数のビジネスセグメントにサービスを提供しています。組織内で API の導入が増えるにつれ、サーバー間の通信ではなく、公開 API や、モバイルアプリ、スタンドアロンアプリとの接続に注目が集まることが予想されます。こうしたイニシアチブにより、API のセキュリティがかつてないほど重要になっていくと考えています。

STC では、デジタルトランスフォーメーションに引き続き重点を置くことは、自社の成長に良い影響を及ぼすと考えています。API を使用して自社、パートナー、お客様に対し価値を創出するうえで役立つ API 管理は、今後も変革において重要な役割を果たしていくでしょう。

STC などの他の多くの企業によって、API と Apigee API 管理がどのように使用されているのかの詳細については、Telecom State of the API Economy 2021 レポートをお読みください。

- STC 技術および運用担当シニアバイスプレジデント Haitham AlFaraj

- STC アプリケーション担当バイスプレジデント Yazeed Alfaris

Apigee を使用したアプリケーションと API の保護のベストプラクティス

Tue, 26 Oct 2021 09:00:00 +0000

※この投稿は米国時間 2021 年 10 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

世界中の企業で、お客様、従業員、パートナーからのデジタルエクスペリエンスに対する需要が急増しています。このような企業の多くでは、何百というビジネスアプリケーションがプライベートクラウドやパブリッククラウドでホストされていて、地域、チャネル（ウェブ、モバイル、API、VPN、クラウドサービス）、タイムゾーンを越えてユーザー（お客様、パートナー、従業員）とやり取りしています。

このような需要の高まりを受けて、企業はサイバー攻撃に対する技術インフラストラクチャの強化を迫られています。米国連邦捜査局によると、2020 年に報告された米国企業へのサイバー攻撃の件数は、前年比 69% 増となりました。ウェブや API への攻撃を防ぐことはできませんが、軽減することはできます。最近の調査によると、組織の 55% が少なくとも毎月 DDoS 攻撃を受けているとのことです。

多くの企業がオムニチャネルエクスペリエンスを構築するためにデジタルトランスフォーメーションを加速させていますが、すべてのチャネルにおいてセキュリティとプライバシーを最重要事項として捉える必要があります。この目標を達成するには、企業が新しい脅威に対してほぼリアルタイムで防止、検出、対応できるようにする堅牢なセキュリティアーキテクチャと、組織的なポリシーの適用モデルを実装することが何よりも求められます。言うのは簡単ですが、このようなシステムの実装は非常に困難です。

アプリケーションと API を保護するためのベストプラクティス

組織がこのような課題に対処できるように、Google は最近、「Apigee を使用したアプリケーションと API の保護のベストプラクティス」を公開しました。この中で、Apigee API 管理、Google Cloud Armor 、reCAPTCHA Enterprise 、Cloud CDN を使用して、アプリケーションや API を保護するためのベストプラクティスやアプローチについて説明しています。

このようなベストプラクティスには、バックエンド API を保護するためのプロキシレイヤとしての Apigee、ウェブアプリケーションファイアウォール（WAF）としての Google Cloud Armor、キャッシュ保存のための Cloud CDN の使用と、Google Cloud のソリューションによる包括的なウェブアプリと API の保護が含まれます。

Apigee をプロキシレイヤとして使用する

このパターンでは、Apigee は、すぐに利用可能な機能を使用してバックエンド API を安全に保護できるファサードレイヤになります。

Apigee は、すべての API に一貫して適用できる豊富なセキュリティ機能を提供します。この機能は、リクエストを異なるバックエンドにルーティングするために使用することができ、移行作業にも役立ちます。

Apigee と併用し Google Cloud Armor を WAF レイヤとして使用する

セキュリティフットプリントを増やすために、簡単に Google Cloud Armor を有効にし、Apigee と併用できます。Google Cloud Armor は、ウェブアプリケーションファイアウォール（WAF）機能を提供し、分散型サービス拒否攻撃（DDoS）の防止に役立ちます。また、OWASP トップ 10 に記載されているリスクによるアプリケーションへの脅威を軽減します。Google Cloud Armor でルールを構成する方法の詳細については、Google Cloud Armor の入門ガイドを参照していただくか、Apigee と Google Cloud Armor に関するブログ投稿をご覧ください。

キャッシュ保存に Cloud CDN を使用

Cloud CDN（コンテンツ配信ネットワーク）を使用することで、Google のグローバルネットワークを利用してユーザーにより近い場所でコンテンツを提供し、ウェブサイトやアプリケーションのレスポンス時間を短縮できます。また、Cloud CDN はキャッシュ機能を備えていて、非常に速いレスポンスを提供します。キャッシュからレスポンスを返し、トラフィックの急増に対応することで、バックエンドの保護に役立ちます。また、ウェブサーバーの負荷、コンピューティング、ネットワーク使用量を最小限に抑えるのにも役立ちます。このアーキテクチャを実装するには、Apigee のトラフィックを処理するロードバランサで Cloud CDN を有効にする必要があります。詳細については、こちらのブログ投稿をご覧ください。

包括的なウェブアプリと API の保護（WAAP）

セキュリティプロファイルをさらに強化するために、WAAP を使用することもできます。WAAP は、Google Cloud Armor、reCAPTCHA Enterprise、Apigee を統合して、DDoS 攻撃と bot からシステムを保護します。また、ウェブアプリケーションファイアウォール（WAF）や API の保護も提供しています。

ウェブサイトやモバイルアプリケーションから API 呼び出しを行う企業でのユースケースには WAAP を推奨します。reCAPTCHA ライブラリを読み込み、reCAPTCHA トークンを生成してリクエスト作成時に一緒に送信するよう、アプリケーションを設定できます。WAAP の詳細については、こちらのブログ投稿をご確認いただくかこちらのホワイトペーパーをご覧ください。

次のステップ

デジタルトランスフォーメーションを加速させる組織が増えるにつれて、システムやビジネスチャネルでデジタルでのやり取りへの依存度が高まり、高度なセキュリティと保護の必要性もますます増大しています。脅威からの保護と可視性を向上させながら、迅速かつ効率的にサービスを提供できるよう組織をサポートするアーキテクチャを構築することが最も重要です。

「Apigee を使用したアプリケーションと API の保護のベストプラクティス」のクラウドアーキテクチャパターンを使ってみる。
Cloud アーキテクチャセンターで Google Cloud における OWASP トップ 10 緩和策について参照し、Apigee やその他の GCP プロダクトが OWASP トップ 10 の攻撃を緩和させる方法を確認する。
動画で Apigee と Cloud Armor で API セキュリティを強化するを見る。
6 つのセキュリティ上の脅威から API を保護する方法について動画を見る。
Apigee コミュニティで閲覧し、質問をする。
GitHub の Apigee リポジトリを確認する。

- テクニカルソリューションコンサルタント Sai Saran Vaidy

非営利団体の New Incentives をノーコードで支援

Tue, 19 Oct 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 10 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

世界中の人々が新しい働き方やコラボレーション方法に適応し続ける中で、2019 年には 10 年先と思われていた多くのトレンドが、今日の成功の青写真として定着しました。

私たちは、性能、使いやすさ、セキュリティ、ガバナンスを損なうことなく、アジャイル開発を可能にするテクノロジーへの需要の高まりを目の当たりにしてきました。ソリューションが過度に官僚主義的なプロセスで束縛され、基幹業務の担当者が実際の進行には何ら影響を与えることができない。そのような状態は企業にとってあってはならないことです。一方で、個々のチームが開発するソリューションは、チームが独自のアプリやサービスを作成する際に発生しがちな「シャドー IT」のリスクをまったく伴わず、かつ管理しやすく安全である必要があります。

企業がこの問題に積極的に対処できるよう、パンデミックに立ち向かうノーコードアプリ制作者に向けて、Google Cloud のノーコード開発プラットフォームである AppSheet への特別なアクセス権を提供してきました。Google のこの取り組みは 2021 年 12 月 31 日まで継続されます。ナイジェリアで主に活動する NGO 団体、New Incentives は、AppSheet を活用して有意義な結果を達成した組織の最たる例です。

予防接種の活動を通して乳幼児死亡率の改善を目指す非営利団体 New Incentives は、2015 年にノーコード開発を開始しました。グローバルチームのニーズと、地方で頻繁に行われる業務とのバランスをとるために、IT チームは柔軟性と応答性を兼ね備えたソリューションを必要としていました。経費アプリなどのプロジェクトは、早い段階でノーコードの道を切り開くのに役立ちました。技術的人材と非技術的人材を組み合わせつつ、個々のチームが実験的に開発を行うのと同時に IT 部門がガバナンス要件を維持できるようなツールを活用することで、重要なアプリケーションを従来よりも迅速に開発できることを実証しました。

Svetha Janumpalli 氏は次のように語ります。「この取り組みは、私たちのニーズに合わせてエコシステム全体を構築するようなものです。多層的な承認を行い、膨大な興味深いコンテキスト情報を取得することで、不正行為を特定できるようになります。たとえば誰かが経費を確認する場合、到着しづらく移動も困難な地域では、どこに向かっていて、どこで業務を行うのかを知るうえで、Google マップでの経路確認は非常に重要です。これにより、人々が実際に予定通り行動しているかなどの確認ができます。」

パンデミック以前、この非営利団体のノーコードアプリへのニーズは、供給品の追跡や経費、データの取り込みなどの内部プロセスに集中していました。新型コロナウイルスが出現し始めたとき、New Incentives は自分たちの予防接種プログラムを継続できるか確信を持てませんでした。

「これは大きな問題になる、私たちはどうしたらいいのだろう、と早い段階から考えていました。私たちは基本的に、（子どもたちが病気の予防接種を受けるための方法を体系化することで）クラウドを結成する組織です。そのため、早い段階で、優れた緩和策を先取りし、政府関係者（コミュニティパートナー）に対して緩和策に真剣に取り組んでいることをアピールしなければ、継続できないことがわかっていました。AppSheet のおかげでスピーディにこれらのアプリを導入、イテレーションして、情報を共有することができました」と Janumpalli 氏は言います。

パンデミックが進行するにつれ、New Incentives のリーダーたちは、外部コミュニティとのコミュニケーションがますます重要になってきたことから、社内のニーズに加えて外部のニーズにも AppSheet のアプリを使って対応できることに気付きました。「アプリはポータブルオフィスのようなものです」と Janumpalli 氏は述べています。

COVID-19（新型コロナウイルス感染症）の蔓延を防ぎつつ、継続的な使命を果たすためには、組織がコミュニティとの開かれた対話を行い、各地域の固有のニーズを理解し、それに応える必要がありました。New Incentives チームは、チームメンバーがコミュニティからデータを収集して、そのデータを迅速に評価し、変更を加えることができるアプリを構築することで、状況が変化してもサービスを提供する相手と足並みを揃え続けることが可能だと実感しました。

「インターネットがつながらないことがあります。スマートフォンでさえ通信が困難な場合もあります。AppSheet により、アプリユーザーがアプリから情報を適切に取得できます。そして、誰がいつそのデータを必要としているのか、適切な意思決定を下せるよう、データの供給をプログラムすることも可能です。」

New Incentives は、コミュニティファーストの考えに基づき、地元のメンバーから現場の情報を収集して、それらをコミュニティと組織、両方の上層に還元する活動を始めました。これにより、困難な時期に信頼関係を築くことができただけでなく、アプリのイテレーションを迅速に行い、必要な変更を現場で素早く実装することができるようになりました。「コミュニティメンバーからのフィードバックを受けて、文字通り 1 週間以内にその情報を確認して改善できます。1 年も待つ必要はありません。」

このようなコミュニティとの対話から生まれたソリューションの一つが、2 時間ごとのモニタリングアプリでした。「私たちのプログラムは予防接種の需要を高めるものですが、混雑の増加によるリスクは避けなければなりませんでした。そのため、消毒や手洗い、「社会的距離」措置など、さまざまな新しい慣習を導入しなければなりませんでした。2 時間ごとのモニタリングアプリを導入したところ、非常に便利だったため、今後新型コロナウイルスとは関係なく、プロセスの一部として維持することになりました」と Janumpalli 氏は言います。

新型コロナウイルスは現在も猛威を振るっていますが、New Incentives は、その問題解決に向けて発揮した対応力から、混乱を最小限に抑えつつミッションを継続する可能性を見出しました。この非営利団体は、地域での完全予防接種率の倍増（25% から 54% に増加）に貢献してきましたが、新型コロナウイルスはこれらの取り組みをも危険にさらしています。

Janumpalli 氏は語ります。「私たちは健康を取り扱う組織です。表面的な対策の導入はしたくありません。もし、このようなリアルタイムの情報がなければ、業務を継続しても問題ないという確信が持てなかったと思います。きっと、多くの場面で情報不足によりリスクの許容範囲を超え、より頻繁に業務停止を余儀なくされていたでしょう。」

また、このようにも付け加えました。「他の人々にもぜひ知っていただきたいのは、AppSheet があらゆる面で役に立つということです。データの収集だけでなく、そのデータをどのように管理するか、そのデータをどのようにチームのプロセスに統合するか、そのデータをどのようにレビューするか、そのデータからどのように実用的な分析情報を得るか、といったことに役立ちます。つまり、私たちにとって Appsheet は、実際に人々に変化をもたらすデータそのものであり、マネージャーが必要なすべての情報を取得してチームに対して適切な指導を行い、リーダーシップを発揮するためには不可欠な存在なのです。」

New Incentives は予防接種の取り組みを継続しており、2020 年には月平均 5,800 人だったプログラムへの新規参加児童が、今年の 6 月だけで 27,000 人にまで増加しました。AppSheet のリアルタイムの柔軟性と同組織の革新的な組織文化を組み合わせることで、同じ小規模なチームでも、新型コロナウイルスをはじめとする今後拡大する多様なニーズに対応できることを示しています。

コード不要のイノベーションを無料で開始。

- プロダクトマーケティングマネージャー Jennifer Cadence

Apigee Integration の発表: データとアプリケーションをつなぐ API ファーストのアプローチ

Tue, 05 Oct 2021 09:00:00 +0000

※この投稿は米国時間 2021 年 9 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

世界中の企業が革新を起こすのに苦戦している理由は、データやアプリケーションがサイロ化されていたり、切断されていたり、簡単にアクセスできなかったりすることです。本日、Google Cloud は、Apigee Integration の一般提供開始を発表します。これは、企業が既存のデータやアプリケーションを簡単に接続して、新しい体験を可能にするアクセスしやすい API として提供するソリューションです。

Google Cloud の Apigee は、業界をリードするフルライフサイクルの API 管理プラットフォームであり、企業間やクラウド間でアプリケーションやデータを接続する API の管理と公開設定を提供します。Apigee Integration のリリースで、Google Cloud は API 管理とインテグレーションそれぞれの良いところをインテグレーションプラットフォームにまとめました。このプラットフォームはクラウドネイティブアーキテクチャの原則を活用しており、企業の IT チームは業務をスケーリングし、開発者の生産性を向上させ、市場投入までの時間を短縮できます。

データとアプリケーションは、デジタルエクスペリエンスを実現するものです。しかし、世界中の多くの企業では、データやアプリケーションがサイロ化され、さまざまなオンプレミスやクラウドサーバーの中に埋もれてしまい、社内の開発者やパートナーが簡単にアクセスできない状態になっています。この課題のために開発期間が数週間から数か月も長くかかり、デジタルトランスフォーメーションの取り組みが遅れてしまいます。インテグレーションおよび API 管理ソリューションは、デベロッパーがデータとアプリケーションをシームレスに接続し、それらを簡単に利用できる API として提供することで、この課題に対処します。

Constellation Research、バイスプレジデント兼プリンシパルアナリストの Holger Mueller 氏によると、「世界中の企業は、ビジネスの成長を達成することに重点を置きながら、拡大し続ける顧客の要求に応えるために、デジタルトランスフォーメーションの取り組みを急がなければなりませんでした。インテグレーションと API 戦略を成功させることは、デジタル戦略の成功における重要なコンポーネントです。データとアプリケーションをつなぐインフラストラクチャを構築し、社内外のデベロッパーが API を介してアクセスできるようにしている企業は、イノベーションと成長において業界をリードする可能性が高くなります。今後、企業は、断片的なデータやアプリケーションをインテグレーションし、それらをマネージド API として表面化させることで、重要な接続性の課題に対処できることが重要です。」

Google Cloud のインテグレーションへのアプローチは、お客様や現場の従業員、パートナーが必要とするデジタル体験を導き出し、さらにデータやサービスのカスタマイズを実現して、必要なインパクトを与えることができるものです。この「API ファースト」のアプローチは、API が一連の特定のビジネス要件に対応するエンドプロダクトであることを意味します。そのため、API の設計と開発は、バックエンドのデータやインフラストラクチャの構成よりも先に行われます。今回のリリースにより、Apigee は、企業の IT チームがデータ接続の課題に関連するリスクを軽減することで、イノベーションのスピードを加速させることができるようになります。

Apigee Integration は、10 月 6 日より Apigee のお客様に一般提供される予定です。備えている機能は以下のとおりです。

ソリューションが統一されているので、デベロッパーは既存のアプリケーションを接続するだけでなく、同じインターフェース内で API を構築し、管理することが可能。
Salesforce、Cloud SQL（MySQL、PostgreSQL）、Cloud Pub/Sub、BigQuery へのコネクタを提供。サードパーティのアプリケーションやデータベースに対応したコネクタも近日中に追加予定。
必要なループ処理、並列実行、データマッピング、条件付きルーティング、手動承認、イベントベースのトリガーなどのユースケースを可能にする高度なインテグレーションパターン。

ATB Financial は、API ファーストのインテグレーションアプローチを活用してデジタルトランスフォーメーションに取り組んでいる数多くの Apigee のお客様の一社です。同社の技術戦略およびアーキテクチャ担当バイスプレジデントである Innes Holman 氏は次のように述べています。「当社のエンタープライズアプリケーションを、従業員、パートナー、顧客向けのソリューションに接続するには、セキュリティやデータの互換性など、多くの要素を協調させる必要があります。Apigee Integration と API Management を使って、ATB Financial のデジタル体験のサポートに必要な多数のデータとアプリケーションを接続、保護、管理することで、API インテグレーションアプローチを促進することを計画しています。」

詳しくは、このページをご覧ください。

また、Google Cloud は企業のデベロッパーやアーキテクトが、他のテクノロジやプロセスと一緒に API 管理を簡単に活用できるように、豊富な機能を継続的に追加しています。Apigee の以下のアップデートをお知らせします。

ソフトウェア開発ライフサイクルツール: Apigee は、デベロッパーが既存の SDLC ツールやプロセスを使用して Apigee API を作成、変更、テスト、本番環境にデプロイするための柔軟性を高める機能を追加しています。これには、VS コード用の Google Cloud Code プラグインの拡張機能、GIT ベースのリポジトリとのインテグレーション、アーカイブのバンドルとデプロイメントのための CLI が含まれます。詳しくはこちらをご覧ください。
会話型 AI インテグレーションのためのネイティブポリシー: 会話型 AI ソリューションの迅速なデプロイメントを可能にするために、Apigee には DialogFlow と接続するためのポリシーが最初から用意されています。これらの機能は一般提供されており、ユーザーは DialogFlow のリクエストを解析し、レスポンスを設定し、DialogFlow が取得したパラメータを検証できます。この機能の詳細については、この動画をご覧ください。
GraphQL のサポート: データに関するより多くのユースケースをサポートするために、Apigee は GraphQL API をネイティブにサポートしています。デベロッパーは、API の製品化、API トラフィックの制限、ポータルへの公開、ボット攻撃に対するセキュリティ、モニタリング、収益化など、すべての REST API 管理機能を GraphQL API に拡張できます。詳しくはこちらをご覧ください。

Next ‘21 では、Apigee を次のデジタルトランスフォーメーションイニシアチブに活用する方法について、プロダクトリーダーやお客様の声を聞くことができます。

- Google Cloud ビジネスアプリケーションプラットフォーム担当バイスプレジデント兼ゼネラルマネージャーAmit Zavery

API ファーストのアプローチが持続可能な資源管理を促進している Veolia の事例

Wed, 22 Sep 2021 12:00:00 +0000

※この投稿は米国時間 2021 年 9 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

水、廃棄物、電力管理について考えるとき、パイプ、ワイヤ、ケーブル、廃棄物のリサイクルを思い浮かべるかもしれません。しかし、Veolia Group が実証しているように、より高度なクラウド技術もますます重要になっています。

特に API と API 管理は Veolia の技術戦略の基礎として重要性を増しており、Google Cloud の API 管理プラットフォームである Apigeeは、「Veolia のデータの中枢神経系」（Pascal Dalla-Torre 氏、Veolia グループ CTO）としての機能を果たしています。

API と API 管理は、全社にわたるユースケースの基盤をなしており、その範囲は、パイプと廃棄物のリサイクルのモダナイゼーション管理から、新たな収益源の発見や、ビジネス部門間の提携および外部との提携をより効果的に行う方法の実現にまで及びます。そして、成果が生まれています。Dalla-Torre 氏によると、API のおかげで 2021 年上半期にチームが提携するパートナーの数が前期から 2 倍増加し、40 以上となりました。

52 か国のビジネスと地方自治体にサービスを提供している Veolia にとって、API は目新しいものではありません。同社は、IT のモダナイゼーションなどのタスクで長年 API を使用しています。こうしたタスクでは、API の本来の用途からは外れるものの、各種レガシーシステムを相互運用させるのに API を利用してきました。しかし、このような統合プロジェクトはオーダーメイドで 1 度限りのことが多く、Veolia は単にシステムを接続する以上のことを行いたいと考えていました。

内部クライアント間で共有される標準化された API をビルドおよび管理することで、Dalla-Torre 氏のチームは、こうしたビジネスユニットが地方自治体などの顧客により良いサービスを提供できるようにしています。この場合、一元化された API の働きがないと、内部デベロッパー間で作業の重複や妨害が容易に生じかねません。異なるビジネスユニットが、既存の API を再利用するのではなく冗長的に新しい API を作成したり、異なるデータ構造とアプローチを使用して、システムの上に API をビルドしたりすることも考えられます。この場合、API 同士が競合してさまざまなプロジェクトの「信頼できる情報源」となろうとします。管理された API プラットフォームによりこうした問題が解決され、データと機能への一貫したアクセスが内部デベロッパーに提供されます。デベロッパーは、これらを細かく組み合わせて、新たなアプリや顧客向けサービスを開発します。

Pascal Dalla-Torre 氏によると、同社が Apigee に投資して以来、「開発速度が非常に速まった」とのことです。また、従来は数年かかったプロジェクトが、今や数か月、数週間、数日間に短縮されたということも付け加えています。

API へのこうしたよりアジャイルなアプローチと、クラウドのデータ分析技術により、Veolia は設備メンテナンスの向上などを行えるようになりました。Dalla-Torre 氏は次のように語っています。「複数の焼却炉を一斉に停止すると、費用がかさみます。しかし、API 経由でデータソースを解析サービスに接続することで、メンテナンスのニーズをより正確に予測できます。システム全体をオフにして手動で物理インフラストラクチャを点検するのではなく、サービスが必要な可能性が最も高いエリアに焦点を当てることができます。その間、残りのシステムは稼働させておけます。」

もう 1 つの例は、この API ファーストのアプローチのもと構築された最初の重要なプロジェクトの 1 つでもある、水管理デベロッパーポータルです。大規模な地方自治体などの顧客は、水消費、水漏れ、水質などの変数の重要なデータに接続された Veolia API にこのポータルからアクセスできます。このようなデジタルアセットを利用できるため、顧客は独自のプロジェクトのために新たなデジタルエクスペリエンスを構築できます。たとえば、水の使用量を把握できるようにするアプリや、水質や水漏れの可能性をモニタリングするサービスなどです。水管理ポータルから得たベストプラクティスを活かし、Veolia は企業全体で API ファーストのアプローチを採用しました。そして、2021 年の最初のわずか 5 か月で、これらの API へのトラフィックは 4 倍になりました。

このモデルでは、API は本質的にデベロッパー向けの製品であり、他のデジタル製品と同様に、Dalla-Torre 氏のチームがセキュリティの確保、使用状況からの学習、反復処理、ベストプラクティスの確立を行えるように管理する必要があります。「API をスケーリング、保護、測定して、最高のエクスペリエンスを顧客とパートナーに提供するために必要なツールが手に入りました」と、同氏は語っています。

「Apigee により、優れたカスタマーエクスペリエンスを迅速かつ簡単に提供できるようになります。バックエンド IT の複雑さを取り除き、一貫性と安全性のもと、顧客に情報とデータを素早く提供できるようにします」と Pascal Dalla-Torre 氏は語っています。

さらに、Veolia が内部で使用しているのと同じ API プラットフォームを、顧客、パートナー、その他のサードパーティが利用でき、企業の内外でデジタルアセットにおける革新の複数の道筋が作られています。サードパーティが Veolia のデータと機能を独自の API と組み合わせられるようにすることで、企業は、独自のプロジェクトまたはパートナーのプロジェクトのいずれにおいても、収益を生み出すサービスにデジタルアセットが活用される方法を増やすための機会を広げています。

Dalla-Torre 氏は、「API により、Veolia は新たな革新の機会をもたらす、新たなエコシステムとパートナーにアクセスできるようになります」と語っています。

内外部のデベロッパーが、新しいアプリケーションの構築に必要なデータとサービスに安全にアクセスできるようにする、API のエコシステムを作成することで、Veolia は、単に技術を使用することと、技術ファーストの組織となることの違いを実証しています。

Veolia などの他の多くの企業によって、API と Apigee API 管理がどのように使用されているのかの詳細については、The State of the API Economy 2021 レポートをお読みください。

-シニアプロダクトマネージャー David Feuer

API ファーストアプローチがアプリケーションの統合に最適と言える理由

Thu, 09 Sep 2021 10:00:00 +0000

※この投稿は米国時間 2021 年 9 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

現代の顧客志向の環境で競争優位性を獲得するために、企業にはこれまでにないアジリティが求められています。商品とサービスの製品化までの時間は、年単位から日単位へと劇的に短くなりました。IT チームにはすばやい初動と反応、継続的なイノベーションを盛り込んだビジネス戦略を可能にする土台作りが求められます。

こうしたデジタルトランスフォーメーションとは、単に最新のテクノロジーを取り入れることだけでなく、効率と生産性の改善、エンゲージメントと成長の促進、そして究極的にはお客様、パートナー、従業員の生活の向上のために、既存のデータとサービスを最大限に活用することです。既存のデータとサービスがテクノロジーに組み込まれ、API で簡単にアクセスできるようになると、その後の道筋が明確になります。つまり、新しいテクノロジーやマネージドサービス、エコシステム、サポートを駆使して企業価値を一層拡大できる土台が整うのです。

現代の組織が直面する問題は、レガシーデータやレガシーシステムだけではありません。ビジネスのニーズを満たし、革新的なサービスをお客様に提供するためのクラウドアプリケーションがあまりに多種多様であるという問題もあります。

そうしたデータの管理、ソースの接続、アプリケーションの統合を行い、開発のためにそれらを使いやすい API に集約することは、あらゆる IT 組織にとって極めて重要な課題です。

アウトサイドインで考える API 設計

これまで IT 組織の多くは、この課題を「インサイドアウト」手法で解決することばかり考えていました。つまり、まずインテグレーションレイヤから始め、次にフローの構築、最後に API の開発という流れです。しかし、この手法は非効率的で、モデルが「公開」された段階で問題点が明らかになるという根本的な欠陥があり、デベロッパーなど API 利用者のビジネスユースケースに合わせた設計になっていませんでした。Google の首脳陣は、こうしたデータ、接続、統合はすべて「最低限必要な初期設備」であると結論付けています。したがって、このビジネス価値に関し、ビジネス上の主な関係者の意見をあえて求めることはありません。

主な問題は公開ではなく、データ、サービス、システムをどのように活用すれば、デジタルのバリューチェーン全体によい影響を与えられるかという点です。利用者数や売上の拡大、複数の事業分野での費用削減、製品化までの時間の短縮、カスタマーサポートに費やされる時間の削減といった目標はどれも、現実に手が届くものになりえます。システムを中途半端に公開するのではなく、使いやすい API を公開することは、こうした一連の改善の出発点となります。API の設計はほぼ例外なくアウトサイドイン手法であり、かつ、ビジネス目標達成に向けてその API を実際に使用するチームの視点で行われます。

API ファーストの統合を採用する

開発のペースを加速させるため、企業の IT チームは統合に API ファーストアプローチを採用し、システムのデータ構造ではなく、利用者のユースケースから取り掛かるべきです。

アウトサイドイン手法の概念は、お客様に共感し、お客様の見地に立って物事を考えることが習慣になっているプロダクトマネージャーにとっては馴染みのあるものでしょう。もしチームにプロダクトオーナーがいるなら、データを使ったどのような機能が必要なのかをその人たちが決定できる環境を整えてください。

適切なテクノロジーを選んで API の効果を最大限に高める

API ファーストの戦略は、API をミドルウェアとしてではなく、デベロッパーに力を与え、パートナーシップ構築を可能にし、イノベーションを加速するソフトウェア製品として扱います。このことは、API が作成後に忘れ去られることの多い統合ファーストの運用とは大きく異なります。

API を持つことは方程式の一部にすぎません。企業が貴重なデジタルアセットを外部ユーザーと共有する場合は、API 管理ツールで以下を行う必要があります。

認証や認可などのセキュリティ保護を適用する
悪意のある攻撃からアセットを保護する
デジタルサービスをモニタリングして可用性と高パフォーマンスを確保する
アセットの使用状況を測定、追跡する

適切なツールを導入することで、API で卓越したビジネスチャンスを開拓できます。これこそが、すべての企業が API ファーストを希望する理由です。

Google Cloud を使用した API 管理について詳しくは、ウェブサイトをご覧ください。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

API を利用したアプリケーションのイノベーションで優位に立つ

Thu, 05 Aug 2021 05:00:00 +0000

※この投稿は米国時間 2021 年 7 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

現代のテクノロジーに精通したユーザーは、デジタルファーストで、接続された、シームレスなビジネスインタラクションを求めています。そしてビジネスは、急速に変化する顧客の期待に応え続けるだけでなく、収益性を維持することも求められています。このバランスをとるには、ビジネスのあらゆる側面において持続可能なイノベーションを活用する必要があります。

迅速なイノベーションを実現するのは簡単ではありません。従来のシステムを管理しなければならない場合、スキルを持ったリソースが不足している場合、ビジネスの運営でサイロが発生している場合は、特に難しくなります。

そこで役立つのが、アプリケーションプログラミングインターフェース（API）です。API を活用することで、アプリケーションのイノベーションを極めて高速に実現できるようになります。API は、デジタルエクスペリエンスの提供を簡単にし、サイロ化された部門とシステムをつなぎ、投資から真のビジネス価値を引き出すための基盤を築く構成要素のようなものです。

API が大規模なアプリのイノベーションに対応するしくみ

API はほんの数行のコードだとお考えかもしれませんが、今日のデジタル時代におけるアプリのイノベーションを促進するにあたり大きな役割を果たします。

この数行のコードにより、開発者は異なるシステムにあるデータと機能にアクセスして、そうしたデジタルアセットをモジュール式構成要素に変えて、企業が新たな挑戦に取り組んだり購入者の購買行動の違う部分をつなぎ合わせたりできるようにします。社内部署間のつながりであれ、社外のタブレット、パソコン、スマートウォッチなどの無数のデバイス、パートナー事業者、マーケットプレイス、データ分析ツールへのつながりであれ、社外の開発者コミュニティへのつながりであれ、相互に接続しあうことが API が作られた本来の目的です。

再利用と開発者の消費を意識して設計および管理された API ならば、デジタルアセットを組み合わせて、ユーザーのための魅力的で独特でカスタマイズされたエクスペリエンスを作り出すことで、ビジネスの大規模なイノベーションを促進します。例として、接触のない商品受け取り、チャネル間でのポイントの収集と利用、ショッピング行動に基づいた商品のおすすめの取得があります。加えて、API にはさらなるメリットがあります。価値のあるアセットを API としてパッケージにして収益化すれば、店舗で売られている他の商品と同様に販売できます。つまり、特に人気で価値のあるデータやサービスがある場合に、外部者が興味を持ちアクセス権を購入する確率が高いということです。

API プログラムをビルドして拡張するには、Google Cloud の Apigee のような API 管理プラットフォームが鍵となります。API は、ビジネスの最も価値が高い多くのシステムへのアクセスポイントであるため、アクセスの管理、使用状況の把握、パフォーマンスの維持、セキュリティの継続的な強化が必要です。Apigee は API を 1 か所で管理するので、ライフサイクル全体で API を設計、反復、デプロイ、保護、分析、拡張できます。

ここでご説明するイノベーションは、抽象的なコンセプトではありません。10 年前に登場した、空の雲のように手で触れられない空想上の存在であるかのような印象を受ける「クラウド」という名のテクノロジーが、実際には写真を保存できる場所を提供しているのと同じことです。わかりやすくするため、API を利用したアプリケーションのイノベーションを 3 段階に分けてご説明します。

カスタマイズされたエクスペリエンスを大規模に一貫して提供する

企業の規模を問わず、API を使用すると、カスタマイズされたエクスペリエンスを構築して顧客に提供できるようになります。API ファーストのアーキテクチャにより、開発者がカスタマイズ可能なエクスペリエンスを構築する方法が簡素化されるため、新しい商品やサービスの製品化までの時間を短縮します。コールセンター向けに、顧客のプロフィールに基づいて新商品をおすすめする API を構築した場合を考えてみましょう。この API は当初の目的を満たすだけでなく、モバイルデバイス、アプリ、音声アプリなどの他の場所やテクノロジーにも埋め込み可能です。API により構築の効率性と速度が高まれば、これらのエクスペリエンスもよりカスタマイズされ、調節可能で、一貫したものになります。

強力なデジタルビジネスエコシステムを構築する

API を社外のパートナーと安全に共有することで、イノベーションの価値を広げる、幅広いエコシステムの戦略が生まれます。第三者が API を利用できるようにすることで、デジタルアセットを活用するイノベーターの数を増やすことができ、社内のみのイノベーションでは開発できなかったかもしれない、新規顧客と新しいユースケースが生まれる可能性があります。同様に、データと機能を第三者の API と組み合わせることで、貴社とパートナーは単独の場合よりも多くの価値を共同で生み出すことができます。たとえばパートナーは、貴社独自のデータに API としてアクセスし、自社の専門知識に合わせてそれを安全に活用できるため、貴社単独では実現できなかった顧客のエクスペリエンスを作り出せるかもしれません。

API を開発者、パートナー、顧客と接続して安全に共有し、さらにはパッケージ化して販売でき、他社との統合を深めながら収益源を成長させることが可能です。API の所有者として誰に何を共有するかを管理できるため、適切なパートナーが自由にデータを利用してイノベーションを起こせるようにしながら、セキュリティを確保できます。

データによりイノベーションを促進する

優れたデジタルエクスペリエンスがユーザーに提供され、API がビジネスエコシステム全体をけん引するようになると、API 管理機能を使用して API の使用状況データを測定および分析し、イノベーションを最適化してサイクル上で何度も反復できるようになります。API では、目的のデータの分析情報をシンプルかつセキュアにサプライヤー、ユーザー、パートナーと共有できるため、イノベーションをさらに強化できます。言い換えれば、API はデータとデータ、データとユーザーをつなげるだけでなく、確立されたデータの集約および分析ツールをビジネスに提供できるということです。データを活用したイノベーションにより、ビジネスにおいてさらに情報に基づいたデータドリブンの意思決定を行い、API とそれによって築かれたつながりから最大限の価値を引き出せるようになります。

これから始める方にうってつけのリソース

あらゆるビジネスがイノベーションに必要な知識とツールをご利用になれるよう、Google Cloud は、API を利用したアプリケーションのイノベーションの 3 つの柱をベースに拡張されたシリーズをリリースします。イノベーションに取り組む準備ができたら、シリーズ最初のアプリケーションイノベーションのウェブセミナーをご覧ください。

-Apigee プロダクトマーケティングマネージャー Manoj Gunti

-Apigee アソシエイトプロダクトマーケティングマネージャー Maria Snaider

UCLA: API で築く高等教育機関テクノロジーの未来

Mon, 19 Jul 2021 03:00:00 +0000

※この投稿は米国時間 2021 年 7 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

あなたがある大学で働いているとします。大学で学部の経費を使う場合は、毎回いくつかの手順を踏む必要があるため、支払いに時間がかかります。あるいは学生であるなら、自分の成績表を確認して必要なクラスを見つけて登録したいと考えるでしょう。ところが、各種手続きが別々のアプリやウェブサイトに分散していて、情報が矛盾している場合もあります。現代の消費者が企業に対して手間のかからない魅力的なデジタルエクスペリエンスを期待しているのと同様、現代の学生も高等教育機関に対して同じようにわかりやすくスムーズなエクスペリエンスを期待しています。

次に、あなたがある大学の IT スタッフで、古いプロセスをデジタルエクスペリエンスに移行しなければならないとしましょう。プロジェクト単位でのカスタム統合は避けたいと考えています。つまり、教員が何かを購入する、学生がクラスの情報を必要としているなど、新しいユースケースごとに異なる統合は行いません。必要なのは、新たな用途に対して開発者が繰り返し、簡単かつスケーラブルに利用できるデータと機能です。また、これらのシステムを利用できるだけでは十分でありません。さまざまな関係者が問題なく見つけることができ、トラフィックの急増に耐え、シンプルに一括管理できるうえ、セキュリティの確保も簡単でなければなりません。

これはまさに、カリフォルニア大学ロサンゼルス校（UCLA）の IT チームが直面した課題です。同校は長年、その優れた IT を称賛されてきましたが、テクノロジーの進化が止まることはありません。学生、スタッフ、保護者の期待に迅速かつ俊敏に対応するために、UCLA はアプリおよびデジタルサービス構築に際して最新の API ファーストアプローチを必要としていました。

UCLA のエンタープライズ統合担当プログラムマネージャーである Curtis Fornadley 氏によれば、多くの大企業と同様、大学にもレガシーシステムが数多くあり、最新のアプリケーションに対して使用しなければならないことがあるそうです。

「UCLA のチームは以前、SOAP サービス向けの自前のゲートウェイで、エンタープライズサービスバスを実行していました」と Fornadley 氏は説明します。「しかし SOAP ベースのサービスはスケーリングが難しく、こうしたサービスを管理するにはサービスのロックダウンが必要になることが頻繁にありました。これは、データと機能を開発者にとって使いやすいものにしたいという私たちの思いと相容れない状況でした。」

現代の API ファーストのアーキテクチャは分散したチーム全体にスケーリングできるよう設計されているため、管理者がガバナンスとセキュリティに対応する一方で、開発者は必要なリソースを簡単に利用して迅速に作業を進めることができます。UCLA でのこのようなアーキテクチャの導入の必要性を認識した Fornadley 氏は、包括的な API プログラム提案書を作成しました。これが Google Cloud の API 管理プラットフォームである Apigee の導入につながり、そのビジョンは現実のものとなりました。

「大学のすべての人々がもっと効率的に新しいソリューションを開発できるようにする API 管理ツールが必要でした」と Fornadley 氏は言います。

このビジョンの根幹を成すのは、Ascend 財務管理システムと学生情報システムの開発です。前者は UCLA が使用する財務システムの API を拡張したもので、さまざまな学部の開発者が安全でスケーラブルなセルフサービス機能を介して API にアクセスできます。また、学生情報システムに組み込まれた API により、キャンパスで使用されるさまざまな UCLA アプリケーションから学生の成績、財務記録、個人情報にリアルタイムでアクセスできます。これら 2 つのプロジェクトだけでも、API の数、そしてそれらの API を利用するアプリケーションの数は膨大なものとなり、サービスのオンライン化の維持、使用状況のモニタリング、アクセスの認証のために総合的な管理が必要になります。

大学内の開発者とパートナーの双方から見て、キャンパス全体を対象とした API プログラムがなければ、API エクスペリエンスが分断されてしまうことでこの取り組みの成功は難しくなったことでしょう。UCLA は現在 200 を超える API を管理しており、開発者がセルフサービス方式のポータルを使用して必要なサービスを探し利用するハブアンドスポークモデルを構築しています。キャンパス全体を対象とする、連携のとれた API ガバナンスを確立できたため、関係者全員に一貫性のあるエクスペリエンスがもたらされ、開発者がアプリケーションを開発する際には信頼できる単一情報源のデータを利用できるようになりました。

UCLA の API プログラムはまだ拡大中ですが、多くの成果がその効果を物語っています。キャンパスでの Apigee の呼び出し回数は 2020 年の 100 万回から、2021 年には 1,100 万回（現時点）にまで増加しています。自前のゲートウェイから Apigee への全 API の移行は今月にも完了し、今年末までの呼び出しは 4,900 万回以上になると見込まれています。

また、このプログラムは今後の数え切れないイノベーションの基盤ともなります。たとえば、API の使用状況をモニタリングして分析することで、興味深い目的やよくある用途に使われているサービスを把握でき、将来の投資の判断に役立ちます。また、進化を続ける脅威から API を保護するための知見を得ることもできます。さらに、UCLA は API によって多数のデータストア間サイロを解消し、クラウド内のサービスに接続できるようにすることで、これらのデータストアを有効活用しています。そして何よりも、API はパートナーと UCLA の連携を容易にし、迅速かつシンプルなコラボレーションとサービス共有を実現しています。

Apigee の無料トライアルと企業にもたらすメリットについてはこちらをクリックしてください。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

リモートワーク、オフィスワーク、ハイブリッドも、コード不要のアプリで簡単に管理

Tue, 06 Jul 2021 04:00:00 +0000

※この投稿は米国時間 2021 年 6 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

オフィス業務の再開が進んでいますが、ビジネスはこれまでの 1 つの慣習を維持しているわけではありません。多くの企業が、従業員の勤務時間を自宅とオフィスに分けるハイブリッドモデルを採用しています。100% リモートワークにしている企業や、従業員全員をオフィスに戻してデジタル化により重点を置いている企業もあります。

どのモデルを採用するにせよ、一つ確かなことは、組織がよりスマートで効果的な作業を行うことができるようにするためには、テクノロジーがこれまで以上に重要な役割を果たすということです。特に、企業は特定のビジネスニーズに合わせてカスタマイズできるテクノロジーを必要としています。たとえば、小売店のマネージャーが衛生管理を改善する方法を必要としている場合や、オフィスの従業員がデスク予約を管理するためのアプリを作成する必要がある場合などです。

Google Workspace では、AppSheet を使用したカスタムアプリの構築や自動化など、必要な作業をすべて 1 か所にまとめて実行できます。Google Cloud のコード不要の開発プラットフォームである AppSheet を使用すると、プログラミング経験のない従業員でも、カスタムアプリの構築や自動化を通じて時間と人材を節約できます。

AppSheet を使用したソリューションの構築は、従来のコーディングよりも簡単かつ迅速に行うことができます。AppSheet は、Google の機械学習の専門知識を活用することで、アイデアからソリューションへの移行を加速させ、今日の状況に求められるスピードとアジリティに適合できるようビジネスを支援します。この記事では、AppSheet を使用して、ビジネスニーズの変化に対応するためにカスタムソリューションを作成する方法についてご説明します。代表的な例として、多くのビジネスが直面しているユースケース（会議室やその他のオフィスリソースの予約と管理）に焦点を当てます。ただし、このプロセスは店頭受取用アプリからインシデントレポートのアプリまで、さまざまな用途に簡単に適用できます。

アプリを使用して簡素化と一元化を実現する

最初に考慮すべきことは、カスタムインターフェースを通じてソリューションを管理することが最適であるかどうかです。検査や在庫追跡などのプロセスを簡素化する場合や、リソースポータルやイベントカレンダーなどの情報を一元化する場合は、カスタムアプリケーションを作成することが最適な選択肢です。

このサンプルアプリでは、バックエンドデータを保持するための簡単な Google スプレッドシートを作成しました。データ量が急激に増加しないことがわかっている場合、特にオフィスやユーザーグループでまずパイロット運用を実施する場合、Google スプレッドシートは理想的なバックエンドデータソースになります。必要に応じて、データはスケーラブルな Google Cloud SQL データベース、その他のデータベースにいつでもシームレスに切り替えることができます。

このサンプルアプリには、さまざまな建物、部屋、チェックポイント、人（役職を含む）を管理するためのワークシートがいくつか含まれています。

[ツール] > [AppSheet] > [アプリを作成] を選択すると、AppSheet で直接アプリケーションを作成できます。

アプリを作成すると、接続したデータの概要、データの各要素の相互関係、ユーザーに表示されるビュー、アプリのライブインタラクティブプレビューが表示されます。アプリの調整は、直感的に操作できます。たとえば、キーワードを入力すると、AppSheet にさらにカスタマイズできる適切な機能オプションが表示されます。住所や場所のデータがある場合は、自動的にマップビューに変換されるので、そこからさらにカスタマイズできます。

Google のオフィス管理アプリを使用すると、ビル管理者と清掃者は機器、消毒スケジュール、メンテナンス情報を管理するための機能を利用できます。また、従業員が稼働率を確認したり、デスクや機器を安全に予約したりするためのビューも利用可能です。

アプリでオフィスを開いてから部屋を開くと、その部屋のフロアプランと、部屋内のスペースおよび機器の使用・予約状況が概要として表示されます。

ユーザーは、イントラネットでフォームやページを検索したり、仕事用のコンピュータにログオンしたりしなくても、アプリでスペースや機器を予約できます。予約は AppSheet の自動化ルーティンであり、トリガーされると事前構成されたアクションを実行します。

上述のスクリーンショットに示すように、アプリのボタンを押す、QR コードをスキャンする、RFC タグをタップするなどしてアクションをトリガーすると、アクションによって「予約者」列と「予約場所」列が現在のユーザーとタイムスタンプに設定されます。

自動化で効率化を図る

最近、AppSheet Automation の一般提供が開始されました。この機能を使用すると、繰り返し発生するタスクを削減し、プロセスをさらに効率化することができます。

この例では、ユーザーが使用後にデスクやリソースを空き状態にするのを頻繁に忘れてしまうという課題に直面する可能性があります。つまり、管理者が使用中のデスクやリソースをすべて空き状態にするまで、それらのデスクやリソースは使用中のままになります。しかし、デスクやリソースをすぐに空き状態にしないことも重要です。次のユーザーが利用する前に、まず清掃して消毒する必要があるためです。

AppSheet Automation を使用すると、4 時間以上使用中になっているすべてのリソースが定期的にチェックされ、それらを再予約するか、清掃して空き状態にするように促す通知がユーザーに送信することで、この課題を解決できます。ユーザーから回答がない場合は、自動化によってリソースの清掃がトリガーされ、その後リソースは空き状態になります。

上述のプロセスを繰り返し発生するイベントとして構成し、ユーザー入力（または入力不足）に基づいて通知を送信してアクションをトリガーする bot を作成できます。

複数の役職に合わせて最適化する

1 人のユーザーのためにアプリを作成することと、複数のタイプのユーザーのニーズに合うアプリを作成することには大きな違いがあります。AppSheet では 1 つのアプリに複数の役割を盛り込めるため、この種の複雑さに対応できます。

たとえば、Google のオフィス管理アプリでは、オフィス管理者は特定のビューとダッシュボードを表示でき、オフィス内の従業員は自分のビューと機能を前面と中央に表示できます。これにより、1 つのアプリですべてのタイプのユーザーのタスクを自動化できます。

同様に、AppSheet Automation を使用すると、データのリアルタイムの変更に簡単に対応する、ユーザーのグループに通知を送信する、アプリとユーザー間で共有されるデータを使用して追加のワークフローを開始するといったことが可能です。たとえば、あるグループが重要な会議を行うために会議スペースを急遽予約する必要がある場合、複数のユーザーグループ全体に影響が及ぶ場合があります。これらすべての更新とインタラクションを自動化できるため、結果的に多くの時間と労力を節約できます。

AppSheet は、QR コード、NFC、Bluetooth センサーの統合など、高度な機能もサポートしています。これにより、ユーザーは場所やワークスペースにチェックインすることができ、オフィス内の支障のない移動とコラボレーションを支援するタスクがさらに効率化されます。

ミッションクリティカルなソリューションを迅速に提供する

今までは、この記事でご紹介しているアプリを構築するのであれば、中央データストア、特定のユーザーグループへの配信、管理機能とダッシュボード機能、NFC や画像キャプチャのためのスマートフォンセンサーの統合が必要になっていたはずです。また、大規模な実装プロジェクトとコード作成の専門家チームも必要になっていたでしょう。

しかし、AppSheet ではコードを使用しないため、数か月、数年もの時間を費やすことなく、数時間または数日でこれらの要件を効果的に設計し、実装できます。変更を加える場合は、新しいバージョンをユーザーに push するなど、任意のブラウザで即座に行うことができます。AppSheet では、あらゆるナレッジワーカーがアプリの構築とデジタル自動化を行えます。堅牢なセキュリティとガバナンス制御も備わっているため、従業員をオフィス勤務に戻すための管理を行う際に IT セキュリティが疎かになってしまうこともありません。

AppSheet.com で、無料の back-to-the-office アプリをぜひお試しください。また、サンプルアプリを検索してコピーすることもできます。

-ソリューションエンジニア Tyler Ayers

DueDil が Apigee API 優先のアプローチを活用して大規模なデータ分析を提供している方法

Thu, 03 Jun 2021 03:00:00 +0000

※この投稿は米国時間 2021 年 5 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

名前が示すように、DueDil はデューデリジェンスサービスを提供します。大手金融サービス企業 / 成長著しいテクノロジー関連企業 / 保険会社を対象に提供する DueDil のサービス範囲は、顧客固有のリスクの評価と選択から、顧客オンボーディングおよびリアルタイムリスクモニタリングまで、多岐にわたります。2009 年に設立された DueDil は、400 を超えるクライアントの 3,000 人超の企業ユーザーを支援しており、これらユーザーがそれぞれの取引相手をただ理解するだけでなく、規制要件を遵守したうえでより効率的に把握できるようサポートしています。

デューデリジェンスサービスは近年発展を遂げてきました。それを支えているのは、新しい規制と新しいテクノロジーです。旧来のシステムやプロセスの多くが最近まで、ペンと紙によるワークフローや、労力のかかるスプレッドシート作業に依存してきましたが、今や新たな規制とテクノロジーの双方によって、それが置き換えられています。DueDil では、このテクノロジー変革によって、手作業のプロセスを自動化に置き換える機会が生まれたことを認識したうえで、同時にもう一つの新たな機会にも着目しました。それは、データを単に処理するだけでなく、異なる IT システムの情報をつないでデータドリブンの分析情報を生成し大規模に提供することによって、データを有効化する機会です。

この機会を活用するため、DueDil は、企業間の約 3 億の接続をマッピングするプラットフォーム、Business Information Graph（B.I.G）を構築しました。数十億ものデータポイントを取り込み、1 日に数回更新される B.I.G では、不正行為のリスクなど、ビジネス上の関係について固有の分析情報が提供されます。B.I.G. の有効性はその結果からも一目瞭然です。DueDil の顧客の中では、パートナーのオンボーディングが最大 80% 迅速化し、リスク検証のスピードが最大 18 倍増し、手作業でのポートフォリオチェックに要していた時間を最大 80% 削減するなどの成果が出ています。

このような変革すべてを生み出すパワーの源はどこにあるのでしょうか？その答えは、アプリケーションプログラミングインターフェース（API）にあります。

「市場展開の観点から言えば、当社の製品は API です」と、DueDil の COO、Denis Dorval 氏は最近行われたウェブキャストで述べ、顧客が B.I.G. のリソースを直接自分で活用し、それをベースに DueDil の API で独自のニーズに合わせたビルドができることを説明していました。

迅速、安全、スケーラブルな API を提供する API 管理プラットフォームの選択

DueDil では、より優れた分析情報と効率性アップにつながる B2B エコシステムを接続するという同社のビジョンを実現するために、いくつかの明確な基準を満たすことのできるクラウドプロバイダを探しました。当時 DueDil が必要としていたのは、社内デベロッパーが数種類のシステムを活用して新たなユースケースやプロセス自動化を実現するための API と、顧客に提供する製品化された API のためのロバストな管理システムでした。数十億ものデータポイントを高速処理する高度な分析と豊富な処理力に加え、そのすべてを支えるエンタープライズクラスのセキュリティ、スケーラビリティ、アジリティが必要でした。また同社では、プロバイダの切り替えに伴ってユーザーエクスペリエンスが損なわれてしまうことを避けるため、円滑な移行を優先課題としていました。

DueDil のエンジニアリングマネージャーである Robert Cicero 氏は、次のように述べています。「Google Cloud の Apigee API 管理プラットフォームの安定感と、そのサービスの力強さは、際立っていました。」

また、「Apigee は回復力の高いアジャイルなプラットフォームで、API を迅速、安全、大規模にビルドするという当社のニーズを満たしています」と説明し、Apigee の API セキュリティ防御ツールおよびポリシーの多くが追加設定なしですぐに利用できることを評価しました。たとえば、Apigee の JSON 脅威検出ポリシー、カスタムポリシー、認証 / 認可プロセスは、瞬時にデプロイできるため、レイテンシを最小限に抑えることができます。つまり DueDil では、セキュリティ上の脅威がネットワークに侵入する前にそれを阻止しながら、サービス遅延のリスクを回避できるようになりました。

現在、DueDil には、ビジネスデューデリジェンスを推進する社内サービスが 5 つあり、すべて Apigee 経由で公開されています。また、Apigee の収益化機能も使用して、API の利用を後押ししています。しかし、DueDil の市場展開戦略はペースが速くクライアント重視であるため、同社が Apigee を使用する最大の目的は、クライアント向けに API を迅速にプロトタイピングして、特定の API の表示と動作の把握を可能とすることにあります。これにより、DueDil とそのパートナーや顧客は、バックエンドシステムの構築に時間を取られることなく、分析情報から価値を生み出すことにより多くの時間を割くことができます。

また、Apigee によって、BigQuery、Google データポータル、Google Cloud Storage といった他の Google Cloud サービスとも、簡単に接続できるようになります。Apigee はシステムの中枢神経の役割を果たし、システムを接続してプロセスを自動化する機能だけでなく、パートナーと顧客による B.I.G. サービスの使用状況に関する分析情報と可視性を DueDil に提供します。

Cicero 氏はさらにこう付け加えています。「Apigee への移行はシームレスで、API 管理プロバイダを Apigee に切り替えたことを誰にも気づかれませんでした。それが最大のメリットであったのは間違いありません。」

API を活用して、セキュリティおよびガバナンスのポリシーを適用しながらセルフサービスを提供

今後に向けて DueDil は、Apigee を活用して、スタッフとクライアントにより多くの権限、可視性、機会を提供し、IT 部門に頼ったり長い承認プロセスを延々と待ったりすることなくセルフサービス方式でアプリを作成し編集できるようにする計画を立てています。API を利用して B.I.G. やその他の機能を会社全体でより多くのチームに公開することで、DueDil では、動きをさらに速めてイノベーションプロセスに関与する人材を増やすことが可能になるでしょう。Apigee API 管理機能を活用している DueDil は、Cloud Functions、Cloud Pub/Sub など、その他の Google Cloud プロダクトおよびサービスも詳しく調べて試してみる意向です。

Cicero 氏は次のように述べています。「最終的には、企業がデューデリジェンスに取り組むやり方は、会社ごとに若干異なっています。DueDil にとっては、多様化したビジネスに対して構成可能かつ動的な環境を提供できる唯一の方法は、順応性のあるプラットフォームを使用するか否かにかかっています。Apigee により、DueDil はさまざまな企業のためにサービスを創造し提供するうえで必要となるアジリティを手に入れることができました。」

Google Cloud は現在、銀行、資本市場、保険、決済のあらゆる場面で世界的に利用されており、困難な課題の解決に役立っています。優れた可視性、管理性でどこからでも API を設計、保護、分析、スケールできる Google Cloud Apigee API 管理についての詳細は、こちらをクリックしてください。Apigee API 管理を無料で試すには、こちらをクリックしてください。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

4 つの簡単なステップでノーコードアプリのための完璧なスプレッドシートを作成

Tue, 18 May 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 4 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

Google がアプリを作成する主な目的の一つは、さまざまな状況でアクセスできる有用かつ実用的なデータの実現です。通常、多くのエンジニアリング作業が必要となるこのタスクですが、ノーコードアプリ開発を活用すれば、コーディング経験がなくてもごくありふれたデータリポジトリ、すなわちスプレッドシートや Google スプレッドシートからアプリを作成できます。

例えば、現場でデータを手書きで記録し、後で Google スプレッドシートに入力する従業員の作業を、アプリに入力したデータをクラウド上のスプレッドシートに自動的に同期するノーコードアプリで簡略化できます。また、スプレッドシートのメンテナンスをアプリで行うようにすれば、多くの基幹業務を大幅に効率化できます。同様に、技術者でない従業員が多くの IT リソースを必要とせずにこうしたアプリを作成できるようになれば、まったく新しい方法で多くの企業がイノベーションを加速できます。

これを実現するための手順は、スプレッドシートを準備するだけと非常にシンプルです。あとは Google Cloud の AppSheet のようなノーコードアプリプラットフォームで用意したスプレッドシートを取り込むと生成される便利なプロトタイプを元に、アプリを完成させることができます。ただしコーディング不要とはいえ、優れたノーコードアプリを作成するには、しっかりと設計されたデータ構造が重要です。この投稿では、AppSheet を使用してアプリケーションを効果的に構築するために必要なデータソースの基本的な準備を Google スプレッドシートでご説明します。

ここから、ノーコードアプリのプロトタイピングプロセスの負担軽減、アプリの管理とメンテナンスの簡素化、効率的な処理が可能なデータ構造の作成のための 4 つのステップをご紹介します。

ステップ 1: わかりやすいテーブルレイアウトを使用する

Google スプレッドシートでレイアウトを始める前に、以下の質問について考えてみましょう。

アプリに何をさせますか？
その機能を実現するために、どのようなデータが必要ですか？
アプリのユーザーがアクセスする必要があるのはどのようなデータですか？

必要なデータを前述の質問で絞り込んだら、Google スプレッドシートの列やテーブルでそのデータをキャプチャする必要があります。列をグループ化してテーブルを作成する際は、最もシンプルに概念をグループ化する方法を考えます。例えば、食料品店向けの在庫管理アプリを作る場合、例 1 のように商品カテゴリごとに個別のテーブルを作成するスキーマでは、非常に多くのテーブルを作成し、個別の管理と更新が必要になるため非効率です。一方、例 2 ではすべての在庫アイテムを 1 つのテーブルに収め、単一の列で商品カテゴリを指定してあり、解決方法として優れています。

重要なポイント: テーブルが多すぎると、アプリの変更やメンテナンスが困難になるだけでなく、同期に時間がかかったり障害が発生したりする可能性も高まるため、テーブルをシンプルに保つことが重要です。

ステップ 2: データの名前とフォーマットはシンプルかつ一貫性を持ったものにする

列とテーブルには、短くわかりやすい名前を付け、長い名前、特殊文字を使用した名前、数字の文字列を使用した名前は避けましょう。

できれば、データソース間で列の命名およびフォーマットの規則を統一します。アプリが複数のスプレッドシートからデータを取得する場合、スプレッドシートの名前と書式を統一する必要があるためです。こうしたガイドラインに沿うことでデータが理解しやすくなり、プロトタイプアプリが適切にデータを解釈できるようになるとともに、アプリ内で式を使用しやすくなります。

ステップ 3: 列をカテゴリに、行をエントリに使用する

AppSheet アプリに追加したデータは、新しい行としてシートに入力されます。行がエントリに、列がカテゴリ（エントリの種類）になるよう、スプレッドシートを均一に構成することが重要です。理解を深めるために、以下の 3 つの例をご覧ください。

例 1 - 反転した在庫テーブル

1 つ目は望ましい構造を反転した例です。データのヘッダーを縦一列に表示し、在庫アイテムを列として追加しています。この配置では AppSheet が新しい行を追加できず、前のセクションの「実用性に欠けるテーブルレイアウト」に近いものになります。

例 2 - 構造が分断されている在庫テーブル

2 つ目のスプレッドシートには、計算機として使用される部分が含まれています。この部分がスプレッドシートの構造を分断しているため、新しい行を追加できません。テーブルは、全体として一貫性のある構造を保ち、ヘッダー列とそれに続くデータ行のみで構成する必要があります。テーブル内に計算機のように全体の構造を分断する部分が含まれる場合は、例 3 のように分断部分を元々のテーブル構造に統合するか、別のテーブルとして独立させる必要があります。

例 3 - 計算部分を統合したテーブル

重要なポイント: 重複はデータ構造上の落とし穴であり、注意が必要です。複数のテーブルで大きなデータブロックが重複している場合、データ構造の効率性が低く、アプリの同期に余計な時間がかかっている可能性があります。

ステップ 4: キー列を追加する

テーブルには、各データ行の一意の識別子となるキー列を含める必要があります。データの種類によっては、意図しなくてもすべての行に不変かつ一意な列が含まれる場合があります。このような一意キーの好例として挙げられるのが製品の ASIN や SKU で、2 つの製品が同じ番号を持つことはありません。同様に、2 人の個人が同じものを持つことがない従業員番号やメールアドレスも良い一意キーと言えます。データにこのプロパティがない場合は、AppSheet エディタで UNIQUEID() 関数を使用してプロパティを簡単に生成できます。詳しい情報については、キーに関するヘルプドキュメントをご覧ください。

初めてのノーコードアプリを作成しましょう

前述のステップに沿ってデータを構造化したら、データから強力なノーコードアプリを作成する準備は完了です。まず、準備したデータを含むスプレッドシートを開き、[ツール] > [AppSheet] > [アプリを作成] の順にクリックします。AppSheet で自動的にデータを読み込み、スプレッドシートのデータをノーコードアプリに変換して、効率性を飛躍的に高めることができます。

このトピックについてさらに詳しい情報が必要な場合は、AppSheet のスプレッドシートのベストプラクティスに関する記事とこちらのウェブセミナーをご覧ください。サンプルアプリのライブラリで、ノーコードでの開発を早速始めましょう。アプリ作成に関してご不明な点がございましたら、ヘルプ記事をご確認いただくか、AppSheet コミュニティにご質問をお寄せください。

技術に精通したクリエイターの皆様が作成した数々のアプリから大いに刺激を受けています。今後もさらなる新作を心待ちにしています。

AppSheet を使用する準備ができたらさっそく使ってみましょう。

-ソリューションコンサルタント H.J. Amaro

AppSheet Automation で自動化する方法

Fri, 14 May 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 4 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

AppSheet Automation の一般提供が開始されました。この記事では、初めての自動 bot を、1 行もコードを記述することなく開発する方法をご紹介します。

この簡単なチュートリアルでは、AppSheet Automation でプロセスを自動化する方法を、新入社員オンボーディングのユースケースを題材にしてご説明します。このフレームワークは、データソースに新しいエントリが追加されたときにメールを自動生成する他のさまざまなユースケースにも応用できます。たとえば、副業ブログに新しい購読者を勧誘したり、最近の作業指示書をリクエストするメールをスケジュールしたりできます。

始める前に、自動化を適用するアプリが必要になります。ご自分ですでに開発済みのアプリ、あるいはこちらのサンプルアプリをご利用いただけます（[Copy and customize] オプションを選択してから、アプリ名を選択してください）。

アプリケーション内の任意のプロセス（ここでは、新入社員のオンボーディング）を自動化するには、次の 3 つの簡単なステップを行います。

bot を作成する
イベントとプロセスを設定する
bot をテストする

これらのコンポーネントの詳細と連携の仕組みについて説明した動画も以下にご紹介します。

ステップ 1: bot を作成する

新しい bot を作成する手順は以下のとおりです。

1. AppSheet の UI で、左側のメニューから [Automation] を選択し、[Bots] タブに移動して [+ New Bot] をクリックします。

2. ダイアログボックスに「employee send email」（社員メール送信）と入力すると、おすすめの bot が下の画像のように表示されます。

3. 上でハイライト表示されている提案 [When a new New Employees record is created, send an email] を選択します（適切な提案が見つからない場合は [Create a custom bot] をクリックして動画の指示に沿って手動作成します）。

4. 以上で bot が実装され、その動作を設定できるようになります。メールが正しい宛先に送信されるように設定を一部調整しましょう。

ステップ 2: イベントとプロセスを設定する

bot はイベント（きっかけとなる事象）とプロセス（実行すべき一連の作業）の 2 つの主要コンポーネントで構成されます。

イベント:

1. イベントをクリックすると、その定義が右側の設定ペインに表示されます。

2. それが下のように表示されたら、次のステップに進めます。

プロセス:

1. プロセスの [Send an email] ステップをクリックすると、その定義が右側の設定ペインに表示されます。

2. 設定ペイン下部の [Go to: Task] リンクをクリックして、タスクの定義を開きます。

3. プラットフォームの表現力をフル活用して、テンプレートを使用するなどしてメールの内容をカスタマイズおよびフォーマットできます。その他のタスク設定については、下表を参照してください。

タスクは次のようになります。

4. [Save] をクリックして、すべての変更を保存します。

5. 次は、いよいよアプリをデプロイします。画面左上の青色の [Not Deployed] アイコンをクリックし、デプロイウィザードの指示に沿ってアプリをデプロイします。それにより、アプリの状態が以下のように緑色の [Deployed] 表示に切り替わります。

6. 以上で bot の構成がすべて完了しました。

ステップ 3: bot の動作を確認する

bot が完成したら、実際に作動させてみましょう。

1. 右側のペインの左上にあるモバイルデバイスアイコンをクリックして、[New Employees] を表示します（代わりに、左側のメニューから [UX] → メインのビュー → [New Employees] に進むこともできます）。

2. 大きな青色の [+] アイコンをクリックして、新入社員のレコードを作成します。社員の詳細を追加（必ず自分に届くメールアドレスを追加してください）→ [Save] をクリック → 新しいレコードが自動的に同期されます（同期されない場合は、右上の赤いアイコンをクリックして同期を実行します）。

3. 前のステップで入力したメールアドレスにウェルカムメールが届きます。

注 - この bot は、アプリを通じた新入社員の追加だけでなく、基底となるシートでデータが直接更新された場合にもメールを送信するように構成できます。そのためには、AppSheet が外部のイベントに対して正しく構成されていることを確認してください。そのプロセスはこちらの動画でご確認いただけます。

これで、初めての bot 開発を 1 行もコードを記述せずに完了し、実際に動作することを確認できました。あとはアプリケーションが確実にデプロイされてさえいれば、bot が必要な作業を行ってくれるので、節約された時間を有効にお使いいただけます。自動 bot の作成に関してご不明な点がございましたら、ヘルプ記事をご確認いただくか、AppSheet コミュニティにご質問をお寄せください。

この機会に、ぜひ AppSheet Automation をお試しください。使ってみる

-ビジネスアプリケーションプラットフォーム部門 AppSheet 担当プロダクトマネージャー Prithpal Bhogill

パート 2: ハッカソンはもはやプログラマーだけのものではない

ビジネス アプリケーション プラットフォーム

Document AI: ドキュメント処理の要件に対応した統合 AI エージェント

Document AI Workbench によるカスタム ドキュメント処理

Document AI ウェアハウスを使用した Google によるドキュメント検索

使ってみる

Google Cloud を活用した PII の検索方法と保護方法

BigQuery 自動タグ付けソリューションの概要

ソリューションの概要

デプロイについて

[オプション 1] Automatic DLP トリガーによる即時タグ付け:

[オプション 2] スケジュール設定されたタグ付け:

DLP を使用した BigQuery の自動データリスク管理

Apigee API 管理への従量課金制の導入

従量課金制で小規模でもパワフルに始める

従量課金制が適しているユースケース

次のステップ

最新の Google Cloud サービスとしてデータポータルをご紹介

実施理由

お客様へのメリット

変更されない点

Looker とデータポータルで BI の 2 つの要素を同時に実現する

Looker とデータポータルで BI の 2 つの要素を同時に実現する

Looker とデータポータルのより良いコンビネーション

統合はどのように行われますか？

プロダクトを統合する方法

利用可能になる時期

次のステップ

あらゆるワークロードをデータ制限なく誰にでも提供できる、革新的な Data Cloud を発表

Google Cloud で予測市場を作成する

予測市場を構造化する方法

使ってみる

Forrester、Google AppSheet を自社開発向けのローコード プラットフォームのリーダーに選出

API で通信事業エコシステムの価値を創造: STC のデジタル トランスフォーメーション

全社的に API を導入

デベロッパーの成功を優先

新しいカスタマー サービスの提供

デジタル化の未来に向けて

API を利用したアプリケーションのイノベーションで優位に立つ

Apigee を使用したアプリケーションと API の保護のベスト プラクティス

Apigee をプロキシレイヤとして使用する

Apigee と併用し Google Cloud Armor を WAF レイヤとして使用する

キャッシュ保存に Cloud CDN を使用

包括的なウェブアプリと API の保護（WAAP）

次のステップ

Google Cloud で脅威や不正行為からのウェブアプリと API の保護を強化する

非営利団体の New Incentives をノーコードで支援

Apigee Integration の発表: データとアプリケーションをつなぐ API ファーストのアプローチ

今こそデジタル エクセレンスの実現を - Apigee X のご紹介

API ファーストのアプローチが持続可能な資源管理を促進している Veolia の事例

API ファースト アプローチがアプリケーションの統合に最適と言える理由

アウトサイドインで考える API 設計

API ファーストの統合を採用する

適切なテクノロジーを選んで API の効果を最大限に高める

API を利用したアプリケーションのイノベーションで優位に立つ

API を利用したアプリケーションのイノベーションで優位に立つ

API が大規模なアプリのイノベーションに対応するしくみ

これから始める方にうってつけのリソース

UCLA: API で築く高等教育機関テクノロジーの未来

今こそデジタル エクセレンスの実現を - Apigee X のご紹介

リモートワーク、オフィスワーク、ハイブリッドも、コード不要のアプリで簡単に管理

アプリを使用して簡素化と一元化を実現する

自動化で効率化を図る

複数の役職に合わせて最適化する

ミッション クリティカルなソリューションを迅速に提供する

DueDil が Apigee API 優先のアプローチを活用して大規模なデータ分析を提供している方法

迅速、安全、スケーラブルな API を提供する API 管理プラットフォームの選択

API を活用して、セキュリティおよびガバナンスのポリシーを適用しながらセルフサービスを提供

4 つの簡単なステップでノーコード アプリのための完璧なスプレッドシートを作成

ステップ 1: わかりやすいテーブル レイアウトを使用する

ステップ 2: データの名前とフォーマットはシンプルかつ一貫性を持ったものにする

ステップ 3: 列をカテゴリに、行をエントリに使用する

ステップ 4: キー列を追加する

初めてのノーコード アプリを作成しましょう

AppSheet Automation で自動化する方法

ステップ 1: bot を作成する

ステップ 2: イベントとプロセスを設定する

ステップ 3: bot の動作を確認する

パート 2: ハッカソンはもはやプログラマーだけのものではない

ビジネスアプリケーションプラットフォーム

Document AI Workbench によるカスタムドキュメント処理

Forrester、Google AppSheet を自社開発向けのローコードプラットフォームのリーダーに選出

API で通信事業エコシステムの価値を創造: STC のデジタルトランスフォーメーション

新しいカスタマーサービスの提供

Apigee を使用したアプリケーションと API の保護のベストプラクティス

今こそデジタルエクセレンスの実現を - Apigee X のご紹介

API ファーストアプローチがアプリケーションの統合に最適と言える理由

今こそデジタルエクセレンスの実現を - Apigee X のご紹介

ミッションクリティカルなソリューションを迅速に提供する

4 つの簡単なステップでノーコードアプリのための完璧なスプレッドシートを作成

ステップ 1: わかりやすいテーブルレイアウトを使用する

初めてのノーコードアプリを作成しましょう