superglue を採用すべきか: 自然言語から統合ツールを生成する FSL ライセンスのエージェント基盤
superglue (YC W25) builds integrations and tools from natural language. Get production-grade tools for long tail and enterprise systems.
ひと目でわかる
- これは何?
- superglue は ERP や CRM など長尾のシステム接続を自然言語の記述から組み立てる TypeScript 製のエージェント基盤である。本稿は README とリポジトリ情報のみを根拠に、その仕組み、導入経路、ライセンス上の制約、向く用途と向かない用途を整理する。
- 誰に向いている?
- 採用を検討すべきなのは、Sage Intacct や NetSuite のような ERP 移行、あるいは CRM やチケッティングなど接続先が多く個別コネクタを維持しきれない立場のチームである。逆に、接続先が 2、3 個に固定されていて要件が安定している場合や、ライセンス条項を法務が読み切れないまま本番データを流したい場合は、独自の薄いコネクタのほうが総コストで勝つ可能性が高い。
- 商用利用できる?
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている?
- されています。最後のコミットは 27 日前です。
- 何の言語で書かれている?
- 主に TypeScript です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
superglue が埋めようとしているのは「コネクタの数だけ増える実装作業」という穴
統合の仕事が重いのは、API 仕様を読む時間よりも、接続先ごとに写経のような実装と保守が積み上がる点にある。README の比較表はこの構図を端的に示していて、Sage Intacct の移行では「Excel による手作業の変換、GL 履歴あたり 10〜15 回のクレンジング反復、1 プロジェクト 140 時間」が、superglue 側では「マッピングを平易な英語で記述し、185 アカウントを 1 時間未満で移行」に置き換わると説明されている。数値はいずれも README が提示する例であり、第三者が検証した値ではない。対象読者は、ERP や CRM の導入と移行を請け負う SI、社内に散在する SaaS をつなぐプラットフォーム担当、そして Claude などの AI 基盤に社内データを渡すための統制された経路を必要としているチームである。つまり汎用の iPaaS を探しているというより、接続先が多く、かつ一回ごとの要件が微妙に違うためにテンプレートが効きにくい領域を狙っている。
自然言語の記述がツールに変わるまで: README から読み取れる範囲
README は「あなたの会社の知識からシステムの動き方を学習する」と述べており、生成されたものを production-grade のツールとして位置づけている。対応範囲として、REST、GraphQL、SOAP、ファイルベース、データベースという接続方式が列挙され、ERP 会計、CRM、データベース、プロジェクト管理、通信、決済、EC、HR、DevOps、分析、広告、ファイル転送、チケッティング、CMS、認証、LLM、建設・調達といったカテゴリごとに製品名が並ぶ。ここで注意したいのは、この一覧が「すぐ動く既製コネクタのカタログ」なのか「エージェントが対象を理解できる範囲の例示」なのかが README からは判別できない点だ。OAuth2 と MCP がトピックに含まれ、api-connector や etl-automation という分類が付いていることから、認証を通したうえで呼び出しを組み立てる層だと推測できるが、生成物がどの形式で保存され、どのように再実行されるのかという実行モデルの説明は README には無い。アーキテクチャを評価するには docs.superglue.cloud を読む必要があり、本稿の材料だけではそこまで踏み込めない。
導入経路は 2 つ、クラウドとセルフホスト
README の Quick Start は分岐が明快である。Option 1 は app.superglue.cloud にサインアップして即座に構築を始める経路。Option 2 は「最大限の制御とカスタマイズ」のためにセルフホストする経路で、手順は docs.superglue.cloud/getting-started/setup#self-hosted に置かれている。配布物としては Docker Hub の superglueai/superglue イメージが README のバッジで示され、クライアント側は npm の @superglue/client が用意されている。したがって自前で動かす場合の起点は docker pull superglueai/superglue と npm install @superglue/client になるが、必要な環境変数、永続化のバックエンド、OAuth2 のコールバック設定といった具体的な設定キーは README には記載が無く、セットアップ用ドキュメントを参照するしかない。ここは README の弱点で、self-host を掲げながらその手前の情報が外部ドキュメントに完全に委ねられている。導入判断をするなら、まずこのページを開いて前提条件の一覧を確認するのが最初の作業になる。
FSL ライセンスという実務上の分岐点
README は「superglue is FSL licensed. The superglue client SDKs are MIT licensed.」と明記している。本体が Functional Source License、クライアント SDK が MIT という非対称である。一方でリポジトリのメタデータ上、ライセンス識別子は NOASSERTION と記録されており、自動判定ができていない。つまり条項の実体は LICENSE ファイルを直接読まないと確定しない。FSL は一般に、ソースは公開されているが競合する商用サービスとしての提供を一定期間制限し、その後により寛容なライセンスへ移行する形を取る。ただし本リポジトリの具体的な制限内容や移行時期は README からは分からないので、断定は避ける。実務的には、社内利用なのか、顧客に再配布するのか、superglue 自体を組み込んだ製品を売るのかで結論が変わる。ここは法務判断の領域であり、本稿が代弁できるものではない。少なくとも「オープンソースだから自由に使える」という前提で進めるのは危険で、MIT なのはクライアント SDK だけである。
向かない場面: 接続先が固定され、要件が動かないとき
この種のツールが割に合わなくなる条件ははっきりしている。接続先が 2、3 個に固定され、スキーマも頻繁には変わらず、呼び出しの順序も決まりきっている場合、自然言語からツールを生成する層は間に挟まる不確定要素でしかない。生成結果の妥当性を確認する工程が残るなら、最初から手で書いたほうが読みやすく、テストもしやすい。もう一点、README の比較表にある「140 時間が 1 時間未満に」といった数値は、あくまで同社が提示するシナリオであり、自社のデータ品質で同じ比率が出る保証はどこにも無い。移行対象のデータが汚いほど、クレンジングの反復はむしろ増える可能性がある。また、生成されたツールが本番で静かに壊れたときの検知手段について、README は何も述べていない。監視や再実行の設計は利用側の責任範囲だと考えるべきで、そこを軽視すると「速く作れたが壊れたことに気づかない」という結果になる。
比較対象としての Zapier と Airbyte: 何が違うのか
同じ「システムをつなぐ」領域でも、アプローチは分かれている。Zapier はトリガーとアクションの組を UI 上で選び、事前に用意されたアプリ連携の範囲内でフローを組む。接続先がカタログにあれば速いが、カタログに無いシステムや、フィールドの変換が込み入ったケースでは結局コードを書くことになる。Airbyte は ELT に寄っており、コネクタを介してデータを目的地へ複製することを主目的とする。変換や業務ロジックは複製後の世界で扱う。superglue はこのどちらとも起点が違い、コネクタを選ぶのではなく、やりたいことを自然言語で記述してツール自体を生成させる。README の Sage Intacct の例が「マッピングを平易な英語で記述する」と表現しているのはこの違いを突いている。ただし、Zapier や Airbyte が持つコネクタの網羅性や実績と、生成ベースのアプローチを同じ土俵で比べるのは難しい。前者は既知の組み合わせを速く処理することに最適化され、後者は未知の組み合わせをその場で作ることに賭けている。自社の接続先がカタログの内側にあるなら、生成に頼る理由は薄い。
保守コストと、リポジトリの更新状況から見えること
リポジトリはアーカイブされておらず、最終 push は 2026-08-19 と記録されている。ただし本稿の材料にはリリース情報が含まれておらず、バージョン番号や変更履歴を確認できない。したがって「活発に開発されている」と断定する根拠は無い。依存関係の更新頻度や破壊的変更の履歴は、採用前に自分で tags と releases を見て確認する項目になる。保守の観点で見落としやすいのは、生成されたツールの再生成コストである。自然言語の記述を書き換えれば出力も変わるため、手書きコードのように差分をレビューしにくい。生成物をバージョン管理下に置き、変更のたびに何が変わったかを追う運用を決めておかないと、半年後に誰も中身を説明できなくなる。ライセンス面では、本体が FSL、クライアント SDK が MIT という構成を前提に、社内利用の範囲を超える配布や再販の予定があるかどうかを先に確定させておきたい。条項の解釈は LICENSE ファイルと法務の領分である。
編集部の結論
採用を検討すべきなのは、Sage Intacct や NetSuite のような ERP 移行、あるいは CRM やチケッティングなど接続先が多く個別コネクタを維持しきれない立場のチームである。逆に、接続先が 2、3 個に固定されていて要件が安定している場合や、ライセンス条項を法務が読み切れないまま本番データを流したい場合は、独自の薄いコネクタのほうが総コストで勝つ可能性が高い。着手前に確認すべきは 3 点で、第一に LICENSE ファイルの実際の条項(リポジトリのメタデータは NOASSERTION、README は FSL としか書いていない)、第二に docs.superglue.cloud/getting-started/setup#self-hosted に記載されたセルフホスト構成が自分のネットワーク要件を満たすか、第三に @superglue/client が MIT である一方で本体はそうではないという非対称を自社の再配布ポリシーに通せるか、である。
コミュニティノート