Apps Script と App Maker、どちらを使う？ 適切なアプリ作成ツールの選び方

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

G Suite の優れた点の 1 つはアプリケーション構築時にオプションを柔軟に選択できることですが、これに関して私たちは開発者の方からこんな質問をよく受けます ―― 「アプリケーションを構築する際に、Apps Script と App Maker のどちらを使えばよいのか？」

Apps Script と App Maker はデプロイ プラットフォームが共通です。違う点よりも似ている点のほうが多いかもしれません。どちらもカスタム ビジネス アプリケーションをすばやく作成できます。また、同じインフラストラクチャを利用し、G Suite のスキルを応用できます。

しかし、両者には明確な違いがあります。Apps Script の強みは、G Suite アプリケーション（Gmail、Google ドライブ、ドキュメント、スプレッドシートなど）と連携するアプリケーションを作成できることにあります。それに対して比較的新しい App Maker のほうは、Apps Script と同じ強みを持つだけでなく、G Suite の枠組みを超えたアプリケーションの作成にも使用できます。G Suite アプリケーションとは別の独立したユーザー インターフェースをデザインしたり、独自のデータ モデルを宣言的に設計したりすることが可能です。

こうした 2 つの選択肢があるのは良いことです。以下では、アプリケーションを作成する際に、Apps Script と App Maker のどちらを使うかを決めるうえで考慮すべき重要なポイントについて説明します。

考慮点 1 : アプリケーションを組織外でも実行する必要があるか

たとえば App Maker を使用するときは、アプリケーションのすべてのユーザーがこのプロダクトにアクセスでき、同じドメインに属している必要があります。アプリケーションをクロスドメインで動作させる必要がある場合や、組織外のユーザーに使用を許可する場合は、App Maker は使えません。

また、App Maker で作成されるアプリケーションは、データ ストレージとして Cloud SQL を使用するものがほとんどであることを考慮しなければなりません。Cloud SQL にアクセスできない場合や、このデータベース サービスを実装することを望まない場合は、必然的に Apps Script を選ぶことになります。

重要指針 : 外部ユーザーやクロスドメイン ユーザー向けのアプリケーションを作成する場合は Apps Script を選びましょう。

考慮点 2 : どのような作り方に快適さを感じるか、どのコーディング言語を好むか

開発者にとっては、App Maker のほうが習得に少し時間がかかります。アプリケーションを動かすにあたって事前にやるべきことも少し多くなります。リレーショナル データ モデルを操作したり、ユーザー インターフェースをゼロからレイアウトしたりといった具合です。それに対して Apps Script は、機能の多くをホスト アプリケーションに依存しており、大抵の場合、プロトタイプをよりすばやく、より柔軟に作成できます。

前述したように、Apps Script と App Maker は似ている点が多々あります。プログラミング言語とランタイムも同じであり、それは Google Apps Script です。これは大きな利点です。相互にスキル（と一部のコード）を転用できるので、プログラミング スキルや言語に基づいて選択するのであれば、基本的にどちらを選んでも差し支えないからです。

なお、この記事のテーマからは外れますが、両ツールにはほかにも、配布、バージョン管理、開発者エクスペリエンスといった違いがあります。しかし、それらは著しいものではなく、選択をより大きく左右するものでもありません。

重要指針 : あなた自身の快適さに基づいて選びましょう。Apps Script を選択すると、アプリケーションの高度な機能の多くを、G Suite アプリケーションを利用して実現できます。これに対し App Maker では、アプリケーション全体の作り方を完全にコントロールできます。コーディングに関しては、甲乙はつけられません。どちらも Apps Script を使用するからです。

考慮点 3 : ユーザーにどんなエクスペリエンスを提供したいか

たとえば、営業に関するコミュニケーションがすべて電子メールで行われる環境向けに、営業支援のアプリケーションを作成する場合は、Gmail 内でコンパニオン アプリケーションとして機能するものを作りたくなります。しかし、調達プロセスを管理するアプリケーションを作ろうとしているときに、ユーザーがこのタスクに G Suite アプリケーションを使っていない場合や、社内で認可されていない G Suite アプリケーションを使っている場合は、スタンドアロン エクスペリエンスを構築するのが最善です。

簡単な経験則は、「Apps Script は、Gmail や Google スプレッドシート、ドキュメント、スライドといったホスト アプリケーションと緊密に連携するコンパニオン アプリケーション向けに設計されており、それを踏まえて選択を行う」というものです。こうしたコンパニオン アプリケーションは、ドキュメントに組み込まれたアプリケーションとして、あるいは G Suite アドオンとしてデプロイできます。そのためユーザーは、仕事のコンテキストの中で（つまり、タブを切り替えることなく）、ホスト アプリケーションの優れたメリットを活用できます。

App Maker を使用すると、当然のことながら、独自のユーザー エクスペリエンスをゼロから設計でき、ユーザー インターフェースとしてデザインしたものにユーザーを誘導するというコントロールされた環境を実現できます（G Suite API を使うことで、ユーザーが Gmail、Google カレンダー、ドライブなどを利用できるようにすることも可能です）。

重要指針 : G Suite のコンテキストで動作するコンパニオン アプリケーションを作成するときは Apps Script を、スタンドアロン ソリューション アプリケーションを作成するときは App Maker を選びましょう。

考慮点 4 : アプリケーションのデータ要件はどのようなものか

これとは対照的に、Apps Script では、独自のデータ管理機能を作成するか、データを Google スプレッドシートで保存する必要があります。後者の方法は、データ要件が極めて単純なアプリケーションには有効ですが、ごくシンプルな CRUD 型アプリケーションを作成する場合でも、App Maker のほうが望ましい選択肢でしょう。

重要指針 : データ要件が高度なアプリケーションでは App Maker を選びましょう。

考慮点 5 : どんなユーザー インターフェースを実装したいか

一方、Apps Script の UI “キャンバス” は、単に背景として使用されている G Suite アプリケーションです。ユーザーが環境を簡単に認識でき、そのおかげで UI を直感的に操作できるため、これは最適な方法です。また Apps Script では、アプリケーションのルック＆フィールに関するカスタマイズの多くをコードを書かずに行えるため、開発者は UI に関する作業をより簡単に開始できます。たとえば、Google スプレッドシートのセルをユーザー入力を集めるために使用したり、条件付き書式設定やデータ検証によってスタイルを設定したりすることが可能です（Apps Script を 1 行も書かずに）。ユーザーとアプリケーションのやりとりを大幅にカスタマイズする必要がある場合は、G Suite ホスト アプリケーションの枠内でカスタム ダイアログやメニュー、サイドバーの UI を Apps Script で拡張できます。

重要指針 : 独自性の高い DIY UI を目指す場合は App Maker を、G Suite をアプリケーションの背景として使用する場合は Apps Script を選びましょう。

まとめ

• Apps Script と App Maker は同じ技術基盤に基づいており、スキルやコードを相互に転用できます。
• Google スプレッドシートを使用すると、シンプルなアプリケーション シナリオのロジックを処理する Apps Script コード によってデータを表示、保存できます。App Maker を Cloud SQL と組み合わせれば、より複雑なデータ要件とカスタム UI ニーズに対応できます。
• Apps Script は、G Suite 内で機能するコンパニオン アプリケーションの作成に適しています。スタンドアロン アプリケーションをゼロから作成する場合は App Maker の出番です。
• 要約 : まずユーザー エクスペリエンスについて考え、目指すエクスペリエンスを実現できる技術を選ぶようにしてください。