この記事は「make Advent Calendar 2024」13日目の記事です。
このアドベントカレンダーについて
このアドベントカレンダーは25日間でIPaaS製品の「make」について使い方や、実践を学べる連続ブログ企画です。
「おかしん」「ばるす」「たにあん」の3名がリレー形式でお届けします。
25日間のスケジュールは以下の通りです。
| 日付 | 内容 | 担当 |
| 12/1 | 話題のIPaaS製品「make」とは | おかしん |
| 12/2 | makeで作ってみたScenario紹介 | ばるす |
| 12/3 | make 基本操作編 機能紹介：Organization | たにあん |
| 12/4 | make 基本操作編 機能紹介：Scenario、Template | おかしん |
| 12/5 | make 基本操作編 機能紹介：Connections | ばるす |
| 12/6 | make 基本操作編 機能紹介：Webhooks | たにあん |
| 12/7 | make 基本操作編 機能紹介：DataStores、DataStructures | おかしん |
| 12/8 | make 基本操作編 機能紹介：Devices | ばるす |
| 12/9 | make 基本操作編 機能紹介：Functions | たにあん |
| 12/10 | make 基本操作編 機能紹介：CustomApps | おかしん |
| 12/11 | make 基本操作編 機能紹介：Flow Control,Tools,Text parser | ばるす |
| 12/12 | make ドキュメント動線の話：ResourceHub | たにあん |
| 12/13 | make 検証：Make Bridge | おかしん |
| 12/14 | make 検証：Make REST API | ばるす |
| 12/15 | make 検証：AI Search | たにあん |
| 12/16 | make Community Hub：Overview | おかしん |
| 12/17 | make Community Hub：Academy Courses,Blog Articles | ばるす |
| 12/18 | make Community Hub：Showcase,CustomApps | たにあん |
| 12/19 | makeの管理運用の話：Github連携 | おかしん |
| 12/20 | makeの管理運用の話：実行ログと再実行と停止中リクエスト滞留 | ばるす |
| 12/21 | makeの管理運用の話：Connection権限管理 | たにあん |
| 12/22 | makeで作ってみた事例：（未定） | おかしん |
| 12/23 | makeで作ってみた事例：（未定） | ばるす |
| 12/24 | makeで作ってみた事例：（未定） | たにあん |
| 12/25 | makeの総論を語る | ばるす |
はじめに
makeのもっとも新しい機能である「Make Bridge」を解説していこうと思いますが、残念ながら検証できる環境が整わなかった為、公式ドキュメントから抜粋して解説するにとどめます。
「Make Bridge」とは、アプリケーションのコードに組み込んで、外部サービスとの連携部分をMakeにやらせることができる機能です。
ざっくり解説
ドキュメントを読んだ内容をすごーくざっくり説明すると、
- あらかじめmakeでBridge用のテンプレートを作る（etc Slackに対して何かメッセージを送り、スプレッドシートに記録するような処理）
- アプリケーションのコードにmakeのBridgeに対してリクエストを送るような処理を組み込む
- アプリケーションのエンドユーザーはアプリケーションを利用している途中で、makeに飛ばされてmakeのUIでテンプレートの未入力部分を設定して自動化を構築できる
- Slackのチャンネルやメッセージ、スプレッドシートやシート・列を指定する、など
少し詳しく解説
Make アカウントを準備する
Make Bridge を利用するには、Make 組織内にサービスユーザーアカウントをセットアップし、API キーを取得し、ユーザーに必要なサンドボックス化（ユーザーレベルまたはチームレベル）を準備する必要があります。
Make Bridge プランが付与された Make アカウントが必要です。（Teamプラン以上が必要です）
ただし、自分が試した限りでは、エンタープライズプランの環境において後述の「Bridgeテンプレート」を作成する導線がありませんでした。まだベータ段階なので、何か手続きが必要なのかもしれません（Make社に問い合わせ中です）
サービスユーザーアカウントの設定
Bridge用のサービスユーザーアカウントを作成します。ざっくり解説で、エンドユーザーがシナリオを作成できると書きましたが、この際にどのユーザーの権限で行うか、ということです。自分が普段使っているアカウントで作成することもできますが、公式としてはサービスユーザーアカウントを作成することを推奨しています。
個人的にはBridgeごとにチームもしっかりわけておいた方が良いと思います。（Bridgeを作成するアプリケーション単位でチームもサービスユーザーアカウントも分けた方がよいはずです）
ちなみにMakeはユーザー数は無制限なので、ここで作成するユーザーが増えたとて費用はかわりません。ただし、エンタープライズプランにおいて、SSOを設定している場合は悩ましいところです。
なので、そもそもこのサービスユーザーアカウントを作成することを推奨している方針が個人的には微妙だと思ってます。
サービスユーザーアカウントを作成する手順：
- Make にログインし、サービスユーザーアカウントを作成した組織を選択します。
- 「Users」タブで「+ Invite a new user」をクリックします。
- このアカウントの Email を入力します。
- このアカウントの Name を入力します（例：「Service User」）。
- Role で「Admin」を選択します。
- 必要に応じてノートを追加します（任意）。
- 「Save」をクリックします。
上記からわかるように、「Admin」の権限が必要なので、共有「Admin」アカウントをいくつも作ることにならざるを得ないので、管理が悩ましいです。上記は公式のドキュメントに書いてある手順ですが、Makeの権限の構造上、Teamの「Admin」があれば良いはずです。MakeはTeam単位で完全に環境が切り離されているので、Organization単位の「Admin」は必要無いと考えています（試せていないので、正確ではないかもしれません）
サービスユーザーアカウントの API キー取得
サービスユーザーアカウントでAPIキーを作成します。
API キーの作成手順：
- サービスユーザーアカウントの資格情報で Make にログインします。
- 左サイドバー下部の「Profile アイコン > Profile」をクリックします。
- 「API Access」タブで「Add token」をクリックします。
- このトークンの用途を識別するための「Label」を入力します。
- 必要なスコープ（Scopes）を選択します：
- Actions
- Working with connections:
- connections:read
- connections:write
- Working with webhooks:
- hooks:read
- hooks:write
- Rendering the forms in the flow:
- imt-forms:read
- Working with keys:
- keys:read
- keys:write
- Reading organization details, checking permissions and licenses:
- organizations:read
- Working with scenarios:
- scenarios:read
- scenarios:write
- Managing teams:
- teams:read
- teams:write
- Working with templates:
- templates:read
- templates:write
- Retrieving data of the System User:
- user:read
- Working with the instancing flows:
- instances:read
- instances:write
- 「Save」をクリックします。
- 新規キーがこのプロフィールの「API Access」ダッシュボードに表示されます。API キーをコピーし、安全な場所に保管してください。再表示はできません。
この API キーを使用することで、アプリケーションから Make API への呼び出しは、サービスユーザー名義で認証されます。
インテグレーションテンプレートの作成
Make アカウントの準備が完了したら、次はインテグレーションテンプレートの構築に移ります。ここで作成したBridge用のシナリオテンプレートは、アプリケーション内で統合ウィザードを通じてエンドユーザーに提供され、エンドユーザーはこのウィザード上でシナリオを完成できます。Bridgeテンプレートで「Use in Wizard」をチェックしたフィールドは、エンドユーザーに統合ウィザード上で表示されます。
Bridge 用インテグレーションテンプレートは、通常のテンプレート作成プロセスと似ていますが、Bridge 統合テンプレートは別途保存されます。
Bridgeテンプレート作成手順：
- Make アカウントにログインし、左サイドバーの「Templates」をクリック後、「+ Create a new Bridge template」をクリックします。
- 必要なアプリや機能を組み合わせてインテグレーションテンプレートを構築します。「Use in Wizard」をマークしたフィールドは、ユーザーの統合ウィザードに表示されます。現時点では、データストアやデータ構造はサポートされていません。アプリやモジュールの使用方法については Make ヘルプセンターをご参照ください。
- インテグレーションテンプレートに名前を付け、[Save] アイコンをクリックします。
- 「Show wizard」をクリックして、インテグレーションテンプレートをテストし、ユーザーが体験する統合ウィザードを確認します。
- テンプレートを最終調整・テストしたら、「Make instanceable」をクリックします。これでテンプレートが Bridge で使用可能になります。
- 表示された「Instanceable ID」を控え、「OK」をクリックします。
インテグレーションテンプレートは組織内に保管され、Templates ページの「Bridge Templates」から確認できます。これらのテンプレートは、ユーザーの Make ロールに応じて利用可能になります。
とのことなのですが、私の環境では「+ Create a new Bridge template」が表示されませんでした。以下のコミュニティの投稿でも同じ事象が発生しているようなので、問い合わせ中です。ベータということもあってかあまりにも情報が少なすぎてさっぱりわかりませんでした。
Make Bridge を統合する
Bridgeテンプレートが完成したら、そのテンプレートからフローを初期化するために、Make Bridge をアプリケーションコード内に統合します。以下の2つのオプションがあります。
- Make API を使用
- Make SDK を使用
この際、以下が必要となります。
- teamId
- templateId
- サービスユーザーの API キー
teamId は、対象となるユーザーのチームダッシュボードの URL から確認できます。
URL パターン: https://{makeZone}/{teamId}/team/dashboard
> 例: https://www.eu2.make.com/15467/team/dashboard という URL から、teamId は 15467 と判別できます。
これらを使用してサーバーから publicUrl を取得し、この URL をユーザーに渡すことで、ユーザーは統合ウィザードを開き、自動化を作成できます。
自動化の有効化
ユーザーが統合ウィザードを完了すると、その自動化はシナリオとして保存されます。セットアップ時にシナリオをデフォルトで有効化することもできますが、そうしなかった場合は、統合フローが完了した後に自動化を有効化する必要があります。
フロー完了を確認する方法は2つあります。
window.open()でフローを新規タブで開いた場合：タブが閉じた時点でフロー完了と見なせます。ただし、ユーザーが途中でタブを閉じた場合も誤検出する可能性があります。redirectUriパラメータを使ってフローを初期化した場合：ユーザーがリダイレクトされた時点でフロー完了が確実です。（こちらを推奨）
フロー完了を確認後、Make API または Make SDK を使用して自動化（シナリオ）を有効化できます。
対象チームで保存されているシナリオを確認し、有効化を確認してください。
この際、シナリオはサービスユーザーアカウントが属するチームに保存されるようです。つまり1つのBridgeテンプレートを組み込んだアプリケーションを複数のユーザーが利用して自動化を保存すると、いくつもシナリオが作成されることになります。
チームごとわけておくべき、と書いたのはそれが理由です。
ちなみサービスユーザーアカウントはエンドユーザーが作成したシナリオを直接Makeにログインして弄ることができてしまいます
さいごに
ごらんの通り、アプリケーションに組み込んだとて、エラーハンドリングも大変そうですし、自分が開発者だったらあまり使いたくはない機能かなという感想を持ちました。そもそもアプリケーション作っていて、APIが提供されているサービスにインテグレーションしたいならそのままコードかけば良いと思うんですよね。
ユーザー側でインテグレーションを若干カスタマイズできるという点については良いと思いますが。
正直近い将来なくなる機能かなと思ってます。
おわり
