GASで自作ライブラリを作成してスクリプトを使い回す方法〜第3回　自作ライブラリの作成方法〜

さて、これまで2回にわけて外部ライブラリの使い方やメジャーな外部ライブラリの紹介をしてきました。

確認されたい方は、以下をどうぞ。

今回はついに自作ライブラリを作成して公開する方法についてです。

ライブラリ公開〜コンテナバインド vs スタンドアロン〜
コンテナバインドでのライブラリ公開の方法
1. コンテナバインド：ライブラリ公開のための基本の流れ
スタンドアロンでのライブラリ公開の方法
1. スタンドアロン：ライブラリ公開のための基本の流れ
まとめ

ライブラリ公開〜コンテナバインド vs スタンドアロン〜

さて、ライブラリ公開においては、当該ファイルがコンテナバインドかスタンドアロンかで方法が異なってきます。今回は、両方ともの方法を紹介していきたいと思います。

コンテナバインドでのライブラリ公開の方法

まずは、コンテナバインド（スプレッドシートやDocsに紐付けられたgsファイル）でのライブラリの公開方法です。

コンテナバインド：ライブラリ公開のための基本の流れ

ライブラリを公開するためには、基本以下の流れで作業を行います。

step1: 共通利用したい関数を.gsファイルで作成
step2: プロジェクトをcould platform プロジェクトに紐付ける
step3: 版を管理でバージョンを設定する
step4: ”実行可能APIとして導入”で公開する

利用するスクリプト側：ライブラリでスクリプトIDを追加する。その他はシリーズ第1回記事参照

簡単なスクリプトを作成して公開してみましょう。

ざっと以下の感じでフォルダ内に呼出先library1と呼出元library2を作成していきます。library2でlibrary1の関数を利用する形です。

folder-
       |--- library1.gs(呼び出される側の.gs)
       |--- library2.gs(呼び出す側の.gs)

step1: 共通利用したい関数を.gsファイルで作成

さて、まずは呼び出される側、library1を簡単に以下のように作ってみます。hello worldと文字列を返すだけの簡単な関数です。

#library1
function helloWorld() {
  return "hello world";
}

step2: プロジェクトをcould platformプロジェクトに紐付ける

さて、作成したプロジェクトをそのままライブラリとして公開できればいいのですが、実は少し前のGoogleさんのupdateの関係もあり、ライブラリ公開の際にはGCPのプロジェクトとの紐付けが必要になっています。

試しに、”公開”→”実行可能APIとして導入”と実行してみてください。以下のような注意文が表示されます。

ということで、まずはGCP側のプロジェクトとの紐付けをしていく必要があります。それでは、GCPに移動してプロジェクトの番号を確認していきます。以下のリンクから、GCPのコンソールに行ってください。

Cloud Computing Services | Google Cloud

Meet your business challenges head on with cloud computing services from Google, including data management, hybrid & multi-cloud, and AI & ML.

コンソールに遷移したら、以下の画像内の赤字で矢印つけたProjectNumberを使います。以下のリンクから

注：プロジェクトが一つもない方は、プロジェクトを立ち上げていただく必要があります。

上でメモしたプロジェクトナンバーを、”リソース”→”cloud platformのプロジェクト”を選択して、出てきた以下のようなウィンドウに入力して紐付けします。

プロジェクトを変更をクリックして紐付けが完了すれば、このステップは完了です。

OAuth同意画面の設定が必要となっている可能性があります。必要とのコメントが表示された場合、指示に従い作成してください

step3: 版を管理でバージョンを設定する

さて、そしてライブラリを公開する場合は、版管理（いわゆるバージョン管理）の概念も理解する必要があります。

第1回第2回でみてきたように、各ライブラリをインポートすると利用するバージョンを選択できましたね？覚えてない方は、過去記事をご参照ください。

自作のライブラリも更新に応じてバージョンを上げていくようにしましょう。その大前提としてバージョンの作り方を説明していきます。

これは、シンプルで”ファイル”→”版を管理”をクリックして、都度都度スクリプトを更新・追加したらバージョンを設定していきます。ちなみに、公開してもバージョンを更新していかない限り、外部から利用できるライブラリとしては内容が変わっていきません。

step4: ”実行可能APIとして導入”で公開する

ここまで設定が終わりましたら、”公開”→”実行可能APIとして導入”を選択すると、以下のようにバージョン・アクセス可能ユーザを選択して公開が可能になります。

アクセス可能な範囲は以下の3つで区分で設定可能です。

・自分のみ
・同一ドメイン内（企業内のイメージ）
・全員（一般公開のイメージ）

実行結果

以下のようなスクリプトを、library2に入れて実行してみます。

function myFunction() {
  Logger.log(library1.helloWorld());
}

実行結果は、library1のhelloWorld関数でreturnを文字列”hello world”としているので、logger.logに”hello world”と表示されます。

うまくいきましたね、なんて事のない文字列を返すだけのライブラリですが、これで自作ライブラリが作成・利用できました。

スタンドアロンでのライブラリ公開の方法

次にスタンドアロンでのライブラリ公開方法です。

スタンドアロン：ライブラリ公開のための基本の流れ

スタンドアロンでのライブラリを公開するためには、基本以下の流れで作業を行います。

step1: 共通利用したい関数を.gsファイルで作成
step2: 版を管理でバージョンを設定する
step3: ドライブから対象のファイルの共有設定を行う

利用するスクリプト側：ライブラリでスクリプトIDを追加する。その他はシリーズ第1回記事参照

スタンドアロンの場合、step1とstep2はコンテナバインドの場合と同様です。コンテナバインドと違うのは、GCPプロジェクトの紐付けが不要です。

step3については、シンプルにドライブから対象ファイルを選択して共有設定を実施すれば可能です。

まとめ

文字列を返すライブラリは基本意味があるとは言えませんが、ライブラリ自体は共通利用できそうな関数をまとめておくと非常に後々便利です。

ぜひ作ってチーム内でのコーディングを楽にしていきましょう。

次回は、ライブラリ公開時の注意事項として、active系のmethod利用で生じる問題点などを紹介していきます。