ifttt と zapier を使い分ける、というか互いに出来ることと出来ないことを比較してみた

どっちがいいかな?
前回の記事で、Zapier を使ってRESTful なウェブサービスとの連携方法について書いてみましたが、ウェブサービスの連携と言えばifttt をその前から使っているので、二つのサービスの両方を使い続けるべきか、片一方にまとめて、必要があればコストも払ってもいい頃なのか?とか、思ってみましたので、ちょっと、そうすべきかどうか、タイトルのようなことをしつつ記事を書きながら考えてみたいと思います。 比較の仕方については、下記のような流れで進めたらちょうどいいのかな、と思っています。
では、どんな思考展開をしていくのやら。。。脳みそをお見せしているようで恥ずかしいのですが(笑)

ifttt と Zapier の同じところ

どちらのサービスも、
  1. あるウェブサービス(メールでも、ブログでも、SNS でも、サービスが監視可能なものであれば何でも)に特定の条件のことが発生(メールならば特定のメールアドレスからメールが送られたならば、とか、ブログならば新しい記事が追加されたら、とか、twitterならばお目当てのアイドルが新しいツィートをしたら、instagram で食べようとしているカレーの写真をアップしたら、などなど)したら (if this)
  2. それを受けて指定したウェブサービスなどでアクションを起こす(例えば、メールを着信したら重要なメールが届いたとメッセージを表示させたり、ブログが更新されたら内容をメールにして送って貰ったり、instagram に載せた自分でカレーの写真とコメントを facebook にもそのまま転記させる、など)ように設定する(then that)
特定の作業の自動化を図るツール、であることです。 両社に違いがあるとすれば
  • 扱えるウェブサービス(これを書いている2016年9月現在、ifttt は 358、Zapier はベータ版を含めて500以上)と
  • ウェブサービス間で流用できる情報、そして、
  • 上記の例では二つのウェブサービスをつなぐものでしたが、前回の記事でも示している通り、ifttt は二つだけ、Zapier は二つ以上繋ぐことが可能
  • ifttt は完全無料であり、Zapier はフリーミアムモデル(高機能を使いたい時は有料で)なのか
という点です。それぞれ見ていくとしましょう。

ifttt に出来て Zapier に出来ないこと

カバーしているウェブサービスの違いが大きく出るところです。例えば、今の天気を調べて私の好きな Pushover に表示させようとすると、ifttt であれば IFTTT Recipe: Morning weather report through Pushover connects weather to pushover
で、終わるところ、Zapier では、まず
  1. Schedule by Zapier で毎日朝6時に起動するというキッカーを設定し(とはいえ、週末は起動させない、という選択が出来るのは細かい)
  2. Weather by Zapier で天気を表示させたい場所を(緯度経度表示で!)指定して
  3. Pushover で 2で取得した情報を適宜レイアウトして表示する
という3ステップが必要になり(かつ有料サービスに依存することになり)ます。 同じことを株価や為替レートでやろうとすると、ifttt ならばあっさりと IFTTT Recipe: FX Market update on your smartphone connects stocks to if-notifications
 な感じであっさり出来るのですが、Zapier には為替や株価を取り出すウェブサービスが標準で設定されていないので、どこかのウェブサイトから拾ってくることになりそうなのですが、数字だけを切り出そうとすると結構手間なことになりそうです。 これ以外に、ifttt にあって Zapier にないウェブサービスといえば、IoT 系のもの。例えばWithings とか、私が最近買ったMISFIT や 以前使っていた Fitbit (Runkeeper はあるんだけど。。。)、もっとIoTしているlittleBits とか、大掛かりなところで(日本ではないだろうけど)GE Appliance 向けIoTサービスへの連動とか、このあたりはiftttの強いところのようです。

そうそう、YouTube でLike した動画をblogger.com の自分のブログに記事としてアップする、のは、ifttt でしか出来ません。blogger.com が zapier では使えないのに付け加えて、Youtube の Like を Zapier が拾うことが出来ないからです。

Zapier に出来て ifttt に出来ないこと

Zapier に出来て ifttt で出来ないこと、というと、例えば前回の記事でご紹介したような、3steps 以上の処理がまず挙げられます。逆に定時処理など簡単なはずな処理が3steps 以上必要になるのも、前述の通りでもありますが。。。
サービス間の情報の受け渡しについてはzapier の方が多くの情報を引き渡して使うことが可能です。例えばTwitter で新しいアカウントにフォローされたらそのフォロワーの名前を参照しながらフォロー感謝です、というツィートを自動的にさせようとする、とします。これはどちらでも可能ですが、ifttt ではトリガーとなったフォローしたユーザーの情報として、ユーザー名は使えますが、ユーザーIDを表記することが出来ません。ですので、
(ユーザー名)さん、フォローありがとうございます。
という普通のツィートを打つことが出来ます。他方、zapier ではユーザー名とユーザーIDと両方共取得・利用可能ですので、
@(ユーザーID) さん、フォロー感謝です!
のような、リツィートのようにフォローした人に感謝したよ、という半私的なツィートを打つことが可能です。まぁ、どちらも自動ツィートですから心がない、と言われればそれまでですし、この機能に限って言えば、Twitter のAPI経由でのツィートのルールに抵触する可能性があるので、後者については特に利用は気をつけたほうがよさそうです。

Zapier のサービスで特徴的なのは、前回の記事で紹介したように、Zapier に対してRESTfull なウェブサービスなどと連携出来る webhooks や javascript やPython で書かれたコードを走らせたり、Zapier の Chrome Extension にあるボタンをクリックすると起動させたり(これは ifttt の Do ボタンに触発されてますね)、果ては SMTP / IMAP を使うなど、サーバーを持って、かつそれなりの権限がないと出来ないようなプログラム的なことが Zapier で可能になっています。これは個人的には使い勝手が悪い、というか分かりづらいGoogle Cloud Platform より全然使い勝手がいいかな、と個人的には思っています。

Zapier で使えるけれども ifttt で使えないウェブサービス、といえば、その数の差から100以上は優にあるわけですが、その中で、Google 関連だけで見ても、ifttt は

  • Google Contact と 
  • Google Drive、
  • Google Calendar、そして、
  • 日本では見ない Google Glass 

だけですが、 Zapier は

  • Google Contact
  • Google Drive
  • Google Calendar
  • Google Glass は当然にあり、その他にも
  • Google Cloud Print
  • Google Forms
  • Google Docs
  • Google Tasks
  • Google Sheets

と結構幅が広がっています。Microsoft 関連で言えば ifttt では全く取り扱いがないのに、Zapier では Microsoft Dynamic CRM と Azure Web Apps とが既に連携可能です。

その他、Paypal や個人的に止められないクラウドストレージの一つであるSugarSync 、日本で言うところのMoney Forward  のようなクラウド会計システムである Quickbooks といった、特殊なものが使えるのも Zapierだけです。

費用対効果でみてみちゃう?

ただより高いものはない、とは言いますが、この点で言えば、ifttt はかなりの太っ腹です。ウェブ連携のプログラムをいくらでも常時スタンバイさせて15分ごとにモニターさせていても、無料なのです。その意味では、どうやってこのサービスから収益を得て維持させようとしているのか謎で、2年前にそこそこのサイズのVC 投資を受けている、というところまではわかっているので、当面は潰れないし潰せない、と踏んでいますが。。。

Zapier はその意味では収益性を前面に出してきています。見事なフリーミアムモデルでして、無料ですと、2 Steps "Zap" が5つまで、トリガーの監視は15分ごとで一ヶ月で100回までの起動可能、APIが落ちていた時のリトライもなければ、SalesForce.com のようなプレミアムなウェブサービスへの連動は不可、となっています。月 20米ドル/年 220米ドルで、スタンバイ可能な Zap 数は 20に増え、かつプレミアムなウェブサービスへの連動可能と3以上の step のが可能、一ヶ月の間の起動可能回数は1,000回とだいぶ安心できるレベルになり、月額50米ドル / 年額550米ドルで監視頻度は 5分に一回、月内の起動可能回数も 3,000回、スタンバイ可能なZap数も 50となる以上に、もしAPIが落ちていた時に起動したものの再トライも勝手にやってくる、というかなり至れり尽くせり、な状態になります。

上記を考えた時に、普通に生活していて日々のルーティンの自動化を考える時に、月20米ドルを払ってまで、前回の記事のようなRESTFul な API 的なウェブサービスとの連動を multi-steps な処理を使ってすることがあるか、したいか、というところが一つのポイントになります。年額 22,000円程度を払うと思うと、一台サーバーをホスティング出来て、自分であれこれAPIを叩くようなPython を書ける人ならばもっと安く仕上がるのも事実です。でも、かなり整理されたインターフェースでプログラムの知識をほとんど持たなくともウェブサービス間の情報連携が出来ると思うと。。。個人的には払えるかな、と。

まとめ

個人的には、ifttt で出来ることで zapierで出来ないことをやっていたり、逆に zapier で出来るけど ifttt で出来ないことをやっているので、併用する他はないのだな、と思ったのですが、もしブログの環境を Wordpress に変えたら世界が変わるかな、とか色々と思うところもあるので、この辺りは今後もtry-and-error でいくような気がしています。

0 件のコメント:

Copyrights Emichanproduction, 1996 - 2011. Powered by Blogger.