AIで自動化を作れる時代に、iPaaSに任せたいもの

運用支援チームのryuyaです。

生成AIに処理内容を伝えれば、コードや設定の下書きが出てくる。業務自動化を作るハードルは、ここ数年で明らかに下がりました。SaaS同士をつなぐ処理をAIに書かせて、クラウドで動かす。以前なら「エンジニアに頼む案件」だったものが、手元で試せる範囲に入ってきています。

そこで出てくるのが、この疑問です。

「AIがコードを書いてくれるなら、MakeのようなiPaaSはもう要らないのでは？」

結論を先に書くと、AIが大きく下げたのは自動化を「作る」ハードルです。作った自動化を業務として動かし続けるには、資格情報の管理、権限、実行履歴、脆弱性への対応、引き継ぎといった仕事が残ります。AIはこれらの作業の一部も手伝ってくれますが、要件に合っているかを判断し、運用し続ける責任までは引き受けません。自分たちで作れば、これらは自分たちで持つことになります。iPaaSの価値は、この運用に必要な共通機能をまとめて製品として提供し、自分たちで設計・維持する範囲を減らしてくれる点にある。それがこの記事の立場です。当社はMakeの導入支援を行っており、社内の業務自動化にも長くMakeを使ってきました。いまはその一部をAWS上でも動かしています。その経験から、なぜそう考えるのかを書いていきます。

作るハードルは、確かに下がった

まず、AIで作れるようになったこと自体は素直に認めたいところです。

ここで言うハードルは、コードの量や作業時間のことではありません。「自分たちにコードで自動化を作れるか」という入口の話です。

以前は、SaaSをつなぐ処理をコードで動かそうとすると、言語の文法、各SaaSのAPI仕様、クラウド側の設定を一通り知っている人が必要でした。だから多くの組織では、「エンジニアに頼むほどではない業務の自動化」はiPaaSで作る、という分担になっていました。ノーコードで作れることが、iPaaSを選ぶ大きな理由だったわけです。

いまは、「申請フォームの内容を受け取り、条件を確認して、担当者にSlackで通知する」といった処理をAIに伝えれば、関数のコードと配置のためのテンプレートの下書きが出てきます。API仕様を最初からすべて読み込まなくても、試作に着手しやすくなりました。本番で使うには仕様と動作の確認が要りますが、入口は確かに広がっています。「コードが書けないからiPaaS」という選び方は、以前ほど自明ではなくなっています。

つまり「AIで作れる」は本当です。問題は、AIが書いたコードのうち業務ロジック以外の部分、つまり資格情報の置き場所、再試行、二重実行の防止、ログの保持期間、権限、アラームといった部分を、誰が理解し、持ち続けるかです。

自前で動かすと、管理範囲はどこまで広がるか

クラウドサービスの責任分担は、よくIaaS、PaaS、SaaSの順に、利用者が管理する層が狭くなっていく図で説明されます。この整理に大まかに当てはめると、Lambdaのようなサーバーレスの実行環境はPaaS（FaaS）、MakeのようなiPaaSはSaaSにあたります。

どちらも、OSやランタイムといった実行基盤の多くは事業者が管理します。違うのは、自動化に必要な接続、認証、実行履歴、失敗の通知が統合された形で提供される範囲と、利用者が部品を組み合わせて設計・設定する範囲です。iPaaSで利用者が管理するのは、フロー、接続、権限、データです。自前でLambdaを動かすと、コードと依存ライブラリ、資格情報の置き場所、実行権限、ログの保持、失敗の検知の設計までが利用者側に来ます。AIはこれらの下書きも出してくれますが、設定が自分たちの要件に合っているかは、読める人が確認しなければ分かりません。

社内でAWS上で動かしている自動化でも、処理の書き換えとは別に、認証、通知、引き継ぎの設計が必要になりました。

接続と権限。 iPaaSでSalesforceなどのSaaSと連携するときは、画面からOAuthで認可するのが一般的で、多くの場合、その接続は認可した人のアカウントとその権限で動きます。AWSから無人で動かす場合はこの前提が使えないため、人に紐づかない形で処理そのものを認証する方式に切り替え、実行用の専用アカウントを用意する構成も検討しています。論点は、APIを呼ぶコードが書けるかではなく、どの主体にどこまでの権限を与え、資格情報をどこに置いて誰が管理するかです。iPaaSでは認可した人の権限に任せていた部分を、接続先ごとに設計し直しています。

脆弱性。 Lambdaでは、サポート中のマネージドランタイムに対してAWSがセキュリティ更新を提供し、標準の設定では自動で適用します。一方、関数のコードや同梱した依存ライブラリの更新、サポート終了を迎えるランタイムからの移行は利用者の責任です。コンテナイメージで配置する場合は、更新されたベースイメージを使った再ビルド・再デプロイも必要になります。参考：AWS Lambdaの責任共有モデル サーバーレスだから管理するものがない、というわけではありません。当社では自社クラウド環境のリスクをWizで確認し、検出した問題の対応を担当者へ依頼する運用を行っていますが、検出できることと修正が終わることは別です。誰が確認し、どの問題から対応し、修正後の動作をどう確かめるかまで決めておく必要があります。

通知と引き継ぎ。 iPaaSでは、失敗の通知も実行履歴も製品の画面にまとまっています。自前で動かすと、エラーをどこへ、どの形で知らせるかを自分たちで決め、自動化が増えるごとに個別に持つか共通化するかを考えることになります。引き継ぎも同じです。何の業務を支え、どこから起動され、失敗したら何を確認するのか。コードがあることと、引き継げることは同じではありません。AIに説明文を作ってもらえても、それが実際の業務や構成と一致しているかを確認し、変更後も保つ責任は残ります。

iPaaSは、この層の共通機能を製品として提供している

iPaaSは、異なるアプリケーションやデータをつなぐ連携基盤です。Makeでは、SaaSへの接続、データ変換、条件分岐、スケジュール実行などを、視覚的なシナリオとして構築できます。

この価値を「プログラミングをしなくても自動化できること」だけで説明すると、AIで作れる時代には話が狭くなります。前節の表で見たように、Makeが提供しているのは組み立て画面だけではありません。接続と資格情報の保管、実行履歴、エラーハンドリング、そしてアクセス制御です。当社のMake紹介でも、Makeをゼロトラスト環境の中で運用する業務効率化レイヤと位置づけ、Oktaとのシングルサインオンとアカウントのプロビジョニング連携で、誰がMakeにアクセスできるかとアカウントのライフサイクルを管理する構成を説明しています。

つまり、iPaaSの利用料に含まれているのは、コードを書かなくてよいことだけではありません。前節の表の右列の多くを、自分たちで用意しなくてよいことです。

コードへ移した実践者の記録でも、Zapierが本当に先行しているのは「管理された資格情報、リトライ、午前3時にどのステップが落ちたかを教えてくれる実行履歴」といった地味な部分だとし、「それは本物の配管であり、エージェントは無料ではくれない」と述べています。参考：Codex vs Zapier (2026)（Chris Alarcon、2026-07-24公開、2026-08-14更新。抄訳）

ただし、iPaaSでもガバナンスは自動では完成しない

iPaaSに任せれば済む、という話でもありません。当社のブログには、Makeを自分たちで運用する中で見えた限界の記録が複数あります。

失敗の検知。 Makeのエラーはメールで通知されますが、当社ではSlackで把握したかったため、モジュールごとのエラーハンドラに加えて、Makeの通知APIを参照してSlackへ流す別のシナリオを作りました。外部サービス側の障害で実行前の接続確認に失敗すると、シナリオ自体が実行されず、エラーハンドラだけでは拾えなかったためです。2025年12月時点の当社の検証では、Enterpriseプランの監査ログに残るシナリオの停止や削除は、ユーザーが実行したものに限られていました。参考：makeのエラー通知をSlackへ

秘密情報の直書き。 認証情報を安全に預ける接続機構があっても、手っ取り早さからHTTPリクエストのヘッダーにトークンを書いてしまう。作った本人が異動や退職をして、誰も中身を把握していない。フロー定義をエクスポートできるiPaaSであれば、LLMで秘密情報の直書きを検知するスキャナを作り、ISMSなどの定期点検に組み込むといった運用も可能です。参考：ノーコード自動化（iPaaS）に直書きされた秘密情報をLLMで一括検知する

接続アカウントの権限。 多くのiPaaSの使い方では、接続アカウントをフロー間で共有して動かします。利用者ごとの権限で動かしたい場面では、この構成が制約になります。Airbyteの解説も、共有の接続資格情報で動かす構成と、AIエージェントに必要なユーザー単位のアクセス制御との差を指摘しています。競合領域のベンダーによる評価ですが、利用者の権限と接続アカウントの権限を混同しない、という確認点は有用です。参考：Airbyte「Integration Platform As a Service: What It Is and Where It Falls Short for AI Agents」

つまり、「ノーコードだから属人化しない」「画面で見えるから誰でも保守できる」とは言えません。iPaaSの価値は、ガバナンスの仕事を不要にすることではなく、共通機能の上で運用を揃えやすくすることにあります。監視と棚卸しは、どちらを選んでも自分たちの仕事として残ります。

どちらを選ぶか。守り続ける体制があるかで決める

ここまでを踏まえて、判断の軸を整理します。

最初に確認するのは、体制の話です。依存ライブラリの更新、設定不備の検出、権限の見直しを継続的に回せる仕組みと人がいるか。止まったときに誰が直すのか、その人は今いるのか。ここが揃っていなければ、自前で持つ選択肢は取りません。他の利点を比べる前の話です。

次に、業務部門の担当者がエンジニアを介さずに自分で変更する必要があるかを見ます。あるならiPaaSを有力候補にします。コードにすると、安全に変更してテストし、リリースできる体制が別に必要になります。実行履歴や監査ログの保持要件も、この段階で確認しておきます。どちらの基盤でも満たせない部分は、追加の実装や運用として見込みます。

この二つを通過してから、向き不向きを見ます。

当社がAWS上で動かしている自動化も、既存の仕組みと担当者を前提にしています。クラウド環境の脆弱性や設定不備を継続的に確認する仕組みがあり、権限や認証を設計して運用できるエンジニアがいる。この前提がなければ、自前で持つ選択は勧めません。同じ判断が読者の組織にそのまま当てはまるとは言えません。

iPaaSを試作専用と考える必要もありません。要件と体制に合っているなら、そのまま本番基盤として使い続ければよい。AWSへ移すこと自体を、自動化の「成長」や「卒業」と捉えなくてもよいと思います。

なお、この記事では移行前後の工数や総コストを定量比較していません。AWSへ移せば必ず安くなる、あるいはiPaaSの方が必ず運用しやすい、と結論づけるものではありません。

おわりに――作れるかより、守り続けられるか

AIが下げたのは、自動化を「作る」ハードルでした。コードが書けるかどうかは、iPaaSを選ぶ理由として以前ほど決定的ではなくなっています。一方で、動かし続けるための仕事は残ります。iPaaSでは、資格情報の保管や実行履歴といった共通機能の多くが製品として提供されます。それでも、接続先の権限設計、失敗時の対応、業務の引き継ぎは利用者側に残ります。自前で動かすなら、共通機能の部分まで自分たちの手元に来ます。AIはその下書きも手伝ってくれますが、責任は引き受けてくれません。

iPaaSを「コードが書けない人のための道具」として評価するのは、もったいないと思います。見るべきなのは、接続、権限、実行、監視、変更、引き継ぎまで含めて、どれだけの仕事を共通の仕組みに任せ、自分たちで設計・維持する範囲をどこまで減らせるかです。自前の運用基盤を維持する体制が限られるなら、iPaaSで管理範囲を減らす。維持できる体制があるなら、自前で持つ選択肢も開ける。どちらを選んでも、業務側で運用に責任を持つ人は必要です。

「何で作れるか」ではなく、「誰が、どう守り続けるか」。iPaaSを選ぶ理由も、AWSへ移す理由も、そこから考えたいと思います。