Runable 完全ガイド 2026｜AI エージェント開発プラットフォームの本命を徹底解説
AI Beat（エーアイビート）編集部です。
「自社の AI エージェントを、PoC で止めずに本番運用までもっていきたい」。2026年に入り、ここ半年で最も多く聞くようになった相談です。Vercel AI SDK で素早く動かしてみたものの、運用に必要なログ、再実行、人間の承認、スケジュール、権限分離まで一気に詰めようとすると、自前で組むコストが急に重くなる。エージェント開発の現場は、いまその「PoC から本番」のあいだの谷を渡るフェーズに入っています。
その谷を最短距離で埋める候補として、編集部が注目しているのが Runable（runable.com）です。Runbook と呼ばれる手順テンプレートを中心に、ブラウザ・デスクトップ・モバイルの自動化、ツール接続、人間のフィードバックループ、スケジュール、ワークフロー保存をひとまとめにした AI エージェントプラットフォームで、2026年に入って急速に評価を上げています。
ただし、いま市場に出ている AI エージェント基盤は Runable だけではありません。Vercel AI SDK、Mastra、LangGraph、CrewAI、AutoGen といった顔ぶれが並び、それぞれ思想も得意領域も違います。編集部としては「どれが最強か」ではなく「どの局面でどれを選ぶべきか」を整理するのが、いちばん読者の役に立つと考えました。
この記事でわかることは次の5点です。Runable というプラットフォームの輪郭、コア機能の中身、Vercel AI SDK や Mastra など競合との比較、ユースケース別の推奨プラットフォーム、そして料金とセルフホストの可否です。AI Beat 編集部の見解と FAQ も添えています。
Runable とは｜2026年時点の事業構造とポジション
Runable とは、Runbook と呼ばれる再利用可能な手順テンプレートを中心に、AI エージェントが「ブラウザ・デスクトップ・モバイル上の任意のデジタルタスク」を自動実行できるよう設計された AI エージェントプラットフォームです。自然言語で「何を達成したいか」を記述するだけで、UI 自動化、API 呼び出し、コード実行、スケジュール、人間からのフィードバック取得までを 1 つのワークフロー内で扱えます。
Runable が出てきた背景
2024年から2025年にかけて、Vercel AI SDK や OpenAI Agents SDK のような「ライブラリ」型の選択肢は出そろいました。一方で、本番運用に必要な観測性、永続メモリ、スケジューラ、再実行、承認フローまでを一気通貫で提供する「プラットフォーム」型のサービスは、まだ群雄割拠の状態にあります。Runable はこの後者、つまり「フレームワークを書かずに本番エージェントを回すための SaaS」というレイヤーで頭角を現しました。
コアコンセプト「Runbook」
Runbook は、Runable における中心的な抽象です。エージェントに任せたい業務を、目的・前提条件・使うツール・成功基準・ロールバック手順までを含めて 1 つのテンプレートにまとめておきます。同じ Runbook を別の入力で呼び出せば、同じ品質の実行が再現できる、という発想で、SRE 文化のランブックを AI エージェント向けに拡張したものと理解すると見通しが良くなります。
創業と現在のチーム
Runable の運営チームは、開発者向け SaaS とブラウザ自動化の両方にバックグラウンドを持つメンバーで構成されています。LinkedIn の Runable 公式ページでも、AI エージェント・ブラウザ自動化・MCP（Model Context Protocol）周りを得意とするエンジニアの採用を継続的に進めていることが確認できます。具体的なシリーズや調達総額は同社公式が随時更新しているため、最新情報は公式サイトで確認するのが確実です。
取り扱うタスクの幅
Runable は「ブラウザ自動化」だけのツールではありません。AI Agent Store の Runable プロファイルによると、ミーティング準備、リサーチ、データ分析、ドキュメント作成、簡易な Web アプリ生成、プレゼン資料・レポート・ポッドキャストの自動生成までを 1 つのプラットフォームで扱えます。
コア機能｜Runbook・自律実行・観測性・デプロイ
Runable のコア機能は、ざっくり 4 つに分けて整理すると把握しやすいです。Runbook 中心のワークフロー設計、自律実行エンジン、観測性、そしてデプロイです。ここから順に見ていきます。
ワークフロー設計（Runbook と Plan）
Runable のワークフローは、Runbook と Plan の 2 段階で構築します。Runbook が「やりたいこと」のテンプレートだとすると、Plan は実際の入力に対してエージェントが立てる実行計画です。Plan の段階では、どのツールをどの順番で呼ぶか、どこで人間の承認を挟むか、失敗時にどう戻すかが明示されます。これにより、ブラックボックスになりがちなエージェント挙動が「人が読める実行計画」として可視化されます。
自律実行（ブラウザ・デスクトップ・API・コード）
実行レイヤーでは、ブラウザ操作、ネイティブデスクトップ制御、API 呼び出し、Python / JavaScript コード実行、スケジュール起動が同列に扱われます。SaaS の管理画面を操作するスクレイピング型タスクと、社内 API を叩く統合タスク、データ整形のためのスクリプトを 1 つの Runbook の中で連結できるのが大きな強みです。
観測性（トレース・コスト・成功率）
Runable はエージェント実行のトレースを標準で蓄積します。各ステップで使ったモデル、呼び出したツール、トークン消費、実行時間、成功・失敗の理由までが Runbook 単位で集計され、後から「なぜ失敗したか」を追跡できる構造です。ここは LangGraph や LangSmith のようなアプローチに近く、本番運用を前提にしたエージェント開発では必須の機能です。
デプロイとスケジュール
Runable で組んだエージェントは、UI から「公開」するだけで、Web ダッシュボード、Slack、Zapier 連携、外部 API、Cron スケジュールから呼び出せる状態になります。社内ユーザーが Slack に「営業日報を集計しておいて」と書けば、その背後で Runbook が動くといった構成を、ほぼコードレスで組めます。
機能サマリー（一覧）
| カテゴリ | 主な機能 |
|---|---|
| ワークフロー | Runbook テンプレート、Plan 可視化、ブランチ実行 |
| 実行環境 | ブラウザ自動化、デスクトップ操作、API、コード実行、Cron |
| 観測性 | トレース、トークン・コスト集計、成功率ダッシュボード |
| 連携 | Slack、Zapier、Webhook、MCP サーバー、Email |
| ガバナンス | 人間の承認ステップ、権限分離、監査ログ |
編集部で実際にトライアル環境を触ってみた限りでは、Runbook を 1 つ組み立てるのに必要な学習時間は、Vercel AI SDK のサンプルを動かすのと同程度の感覚でした。むしろ「観測ダッシュボードと承認ステップ」が最初から組み込まれている分、本番想定のエージェントを最短距離で立ち上げる目的では学習効率が良いと感じています。
対 Vercel AI SDK 比較｜ライブラリ vs プラットフォーム
エージェント開発で最初に名前が挙がる選択肢が Vercel AI SDK です。実装の軽さと React / Svelte / Vue へのストリーミング統合の良さから、TypeScript 圏では事実上の標準になりつつあります。Runable との関係は、競合というより「補完」と捉えるのが正確です。
Vercel AI SDK の強み
Vercel AI SDK は、Speakeasy のフレームワーク比較でも指摘されているとおり、シンプルなエージェント、UI ストリーミング、ツール呼び出しのエルゴノミクスを最小コードで実現できる点に強みがあります。チャット UI の実装、サーバーサイドの tool-calling、stopWhen のような中断条件まで、ライブラリとして極めて軽量です。
Vercel AI SDK の限界
一方で、Vercel AI SDK 単体では、長時間の実行、再試行ポリシー、永続メモリ、観測ダッシュボード、スケジュール、承認フローまでは面倒を見ません。これらを自前でラップして本番運用に持ち込むコストは、結局のところ別レイヤーで発生します。
Runable との位置づけの違い
| 観点 | Vercel AI SDK | Runable |
|---|---|---|
| レイヤー | ライブラリ（コードに埋め込む） | プラットフォーム（ホストされた SaaS） |
| 得意領域 | Web アプリ内のチャット・ツール呼び出し | 業務オペレーション全般の自律実行 |
| UI | 自前で実装（Next.js / Svelte / Vue） | Runable ダッシュボード + Slack / Zapier |
| 観測性 | 外部ツール（Langfuse 等）と組み合わせ | 標準搭載 |
| スケジュール | 自前 Cron / Workers | 標準搭載 |
| 学習コスト | 低（数時間で動く） | 低〜中（Runbook の概念に慣れる必要） |
結論｜どう住み分けるか
Web アプリ内に「チャット UI + ちょっとしたツール呼び出し」を組み込むだけなら Vercel AI SDK で十分です。一方、複数のシステムを横断する業務オペレーション、夜間バッチ、人間の承認、複数ユーザーが共有して使うエージェントを目指すなら、Runable のようなプラットフォーム型を上に重ねた方が運用工数を抑えられます。ChatGPT・Claude・Gemini のモデル比較記事でも触れたとおり、モデル選定とプラットフォーム選定は別軸で考える必要があります。
対 Mastra / LangGraph 比較｜TypeScript 圏と Python 圏
エージェント開発の本格派フレームワークとして名前が挙がるのが Mastra と LangGraph です。Runable はこの 2 つとどう違うのか。TypeScript 圏と Python 圏でそれぞれ整理します。
Mastra との比較（TypeScript 圏）
Mastra は、Vercel AI SDK の上に「ワークフローグラフ・永続メモリ・評価フレームワーク・MCP サポート」を載せた TypeScript 製フレームワークです。Mastra 公式ブログでも明言されているとおり、Mastra は AI SDK の競合ではなく、その上に乗るレイヤーとして設計されています。
Runable と Mastra は同じ「プラットフォーム的なレイヤー」を狙いますが、提供形態が異なります。Mastra はライブラリ + セルフホスト（Vercel / Cloudflare Workers / Netlify への deploy が想定）、Runable はマネージド SaaS が中心です。コードを所有したいチームには Mastra、運用工数を最小化したいチームには Runable、という住み分けが基本になります。
LangGraph との比較（Python 圏）
LangGraph は、LangChain 社が提供する Python 製のグラフベースエージェントフレームワークで、長時間の実行、ヒューマンインザループ、Time-travel デバッグなど「制御性」と「耐久性」に振った設計が特徴です。本番カスタマーサポートのような長期運用エージェントに強みがあります。
Runable と LangGraph は、思想的にはむしろ近い距離にあります。両者とも「エージェントは状態を持ち、長期に動く」という前提を取り、観測ダッシュボードやヒューマンインザループを標準機能化しています。違うのは、LangGraph がフレームワーク + LangSmith というエコシステム選択を要求するのに対し、Runable はそれらを一体型で提供する点です。
三者を並べた比較表
| 観点 | Mastra | LangGraph | Runable |
|---|---|---|---|
| 言語 | TypeScript | Python | 言語非依存（GUI 中心） |
| 提供形態 | OSS フレームワーク | OSS フレームワーク | マネージド SaaS |
| 得意領域 | Web アプリ統合エージェント | 長時間・耐久性重視のエージェント | 業務オペレーションの自動化 |
| 観測性 | 標準 + 外部連携 | LangSmith 連携が前提 | 標準搭載 |
| セルフホスト | 容易（Vercel 等） | 容易（コンテナ） | 限定的（要相談） |
| 学習コスト | 中 | 中〜高 | 低〜中 |
編集部の所見
実装力が十分にあるチームほど Mastra や LangGraph を選び、運用人員が薄いチームほど Runable のようなマネージド SaaS が機能する印象です。Claude Sonnet 4.5 徹底解説で触れたように、モデル側の進化が速い時期は、フレームワークを薄く保ち、モデル切り替えを容易にしておくのがプロダクト運用の鉄則です。Runable はこの「モデル中立」をマネージド側で担保している点が、地味ながら大きな利点だと感じます。
対 CrewAI / AutoGen 比較｜マルチエージェントの思想差
複数のエージェントを協調させる「マルチエージェント」領域では、CrewAI と Microsoft AutoGen が代表格です。Runable とはアプローチが大きく違うので、ここを整理しておきます。
CrewAI の思想（ロール駆動）
CrewAI は、エージェントに「役割（Role）・目的（Goal）・経歴（Backstory）・委譲（Delegation）」をプリミティブとして与えるフレームワークです。Chanl のフレームワーク比較でも、CrewAI はマルチエージェントのプロトタイピングに最適とされています。
AutoGen の思想（会話駆動）
AutoGen は、エージェント同士の「会話」を中心に置く設計です。エージェントを LLM 側のロールとして並べ、会話の中で計画と分業を進めていきます。研究開発・実験フェーズに強く、長期運用には別の仕組みが必要というのが、業界の通説に近い評価です。
Runable の思想（Runbook 駆動）
Runable は、マルチエージェントを前面に出さず、Runbook を中心に置きます。複数のサブエージェントが必要な場合は、Runbook の中で「このステップは別の Runbook を呼ぶ」という入れ子構造で表現します。会話やロールではなく「業務手順」を主役にしているため、業務オペレーション側からの読みやすさは Runable が一段上です。
三者の使い分け
|
「マルチエージェント＝かっこいい」と「マルチエージェント＝必要」を混同しないことが重要です。実務では、Runbook ベースで単一エージェントが堅実に動く構成のほうが、コスト・観測性・障害対応の面で勝るケースが大半です。
ユースケース別 推奨プラットフォーム
ここまでの整理を踏まえ、典型的なユースケースごとに、どのプラットフォームを第一候補にすべきかを並べます。Runable がベストなケースだけでなく、「ここは別のものを使ったほうがいい」も率直に書きます。
1. Web アプリにチャット + ツール呼び出しを組み込みたい
第一候補は Vercel AI SDK です。Next.js / SvelteKit / Nuxt に直結する SDK で、UI ストリーミング・tool-calling・履歴管理が最短距離で組めます。Runable をここに使うのは、過剰な選択になりがちです。
2. TypeScript 製の本番エージェントを自社コードで持ちたい
第一候補は Mastra です。Vercel AI SDK の上に永続メモリ・ワークフロー・評価が乗っているため、自社実装の延長で本番品質に到達できます。GitHub にコードを残し、自社のリポジトリで管理したいチームに合います。
3. 長時間・多段階のサポートエージェントを Python で運用したい
第一候補は LangGraph です。LangSmith と組み合わせれば、ヒューマンインザループ、Time-travel デバッグ、再実行までをフレームワーク側で吸収できます。長期サポート系の業務エージェントに最も向きます。
4. 業務オペレーション（営業日報・契約処理・データ整形）を自動化したい
第一候補は Runable です。Runbook で業務手順をそのまま記述でき、Slack / Email / スケジュールから呼び出しても、観測ダッシュボード上に履歴が残ります。Claude Opus 4.7 のような長文・推論系モデルを Runbook の主役として使い、ツール呼び出しを Runable 側に任せる構成が現状のスイートスポットです。
5. 研究開発・マルチエージェントの実験を回したい
第一候補は AutoGen、第二候補が CrewAI です。Runable は本番運用寄りで、研究フェーズの自由度を求める用途には少し重く感じる場面があります。
6. ノーコード寄りのチームが業務 Bot を作りたい
第一候補は Runable です。Runbook が「業務マニュアルの延長」として読めるため、エンジニア以外のメンバーが要件を持ち込んでもキャッチボールしやすいのが利点です。これは Mastra や LangGraph では難しい運用です。
推奨マトリクス（早見表）
| ユースケース | 第一候補 | 第二候補 |
|---|---|---|
| Web チャット + tool-calling | Vercel AI SDK | Mastra |
| TS 製本番エージェント | Mastra | Vercel AI SDK |
| 長時間サポートエージェント | LangGraph | Runable |
| 業務オペレーション自動化 | Runable | Mastra + 自社運用 |
| マルチエージェント研究 | AutoGen | CrewAI |
| ノーコード寄りチーム | Runable | Zapier + AI Actions |
料金とセルフホスト可否
料金とセルフホストは、エンタープライズ採用の意思決定で必ず聞かれる論点です。ここは公式サイトの情報を中心に、2026年4月時点での編集部の理解を整理します。
公開されている料金プラン
Runable は無料トライアルから始められる SaaS で、有料プランは個人・チーム・エンタープライズの段階構造を持ちます。opentools.ai の Runable レビューなどサードパーティの紹介でも、無料枠 + 月額制という構成が共通して言及されています。具体的な金額は変動するため、契約前には必ず公式サイトで最新情報を確認してください。
課金の主な軸
- 実行回数。Runbook の起動 1 回ごとにカウントされるのが基本
- トークン消費。利用するモデルに応じて従量課金
- シート数。チームで共有する場合のユーザー数
- 連携数・スケジュール本数。Slack / Zapier 連携やスケジュール起動の上限
セルフホストはどこまで可能か
2026年4月時点では、Runable は基本的に SaaS 提供であり、フルセルフホスト版は標準では公開されていません。エンタープライズ契約の中で「VPC 専有・専用デプロイ」をオプションとして提供する形が中心です。完全なオンプレミス運用が必須の組織には、現時点では Mastra や LangGraph をベースに自社実装する方が現実的です。
競合プラットフォームとの比較
| 製品 | 提供形態 | 無料枠 | セルフホスト |
|---|---|---|---|
| Runable | マネージド SaaS | あり | 限定的（要相談） |
| Vercel AI SDK | OSS ライブラリ | 無料 | 実装次第で完全可 |
| Mastra | OSS フレームワーク | 無料 | 完全可 |
| LangGraph | OSS + LangSmith | 無料 + LangSmith 有料 | OSS 部分は完全可 |
| CrewAI | OSS + Cloud | 無料 + Cloud 有料 | OSS は完全可 |
ここでもう一点。Hermes OS の試算によると、永続的に動く AI エージェントを自前で運用するコストは、トラフィックや常駐ホストの構成次第で月額数十ドル〜数百ドルに膨らみます。Runable のようなマネージド SaaS は、この「インフラを自分で抱えない」分のコストをライセンス料に置き換えていると理解すると、価格比較がやりやすくなります。
AI Beat 編集部の見解｜Runable は何を解いているのか
ここまで整理したうえで、編集部としての見解を率直に書きます。
Runable が本当に解いているのは「PoC から本番への谷」
エージェント開発の現場でいちばん苦しいのは、最初のプロトタイプではなく、本番運用に持ち込む過程です。スケジュール、観測、再実行、人間の承認、コスト把握、権限分離。これらを 1 つずつ自前で組み上げていくと、簡単に半年が溶けます。Runable はこの「PoC から本番への谷」をプラットフォームとして埋めにいっているのが本質的価値です。
Runable 一択ではない、むしろ Vercel AI SDK / Mastra との併用が現実解
注意したいのは、Runable が「フレームワーク選定の終着駅」ではない点です。Web アプリ内のチャット UI は Vercel AI SDK で組み、TypeScript 製の独自ロジックは Mastra に閉じ込め、社内オペレーションだけ Runable に寄せる、という三層構成も十分にあり得ます。一枚岩で揃える必要はなく、レイヤーごとに最適解を選んだほうが、長期的な乗り換えコストも下げられます。
日本企業が今、Runable を検討すべき 2 つの問い
|
この 2 つに即答できる組織なら、Runable のような実行プラットフォームを入れて、最初の 1〜2 業務だけでも Runbook 化していく価値は十分にあります。即答できない場合、まず社内マニュアルの言語化と、AI に許す権限境界の議論を先に進めるべきです。プラットフォームの選定は、その後でも遅くありません。
中堅・スタートアップはどう向き合うか
ライセンス費用と運用負荷のバランスで、編集部としては「最初の 1 業務は Runable で素早く立ち上げ、効果が見えたら Mastra 等で内製化を検討する」二段構えを推奨します。マネージド SaaS で時間を買い、見えてきたコア業務だけ自社コードに巻き取る。これが 2026年時点の現実的な進め方だと考えています。
まとめ｜Runable は「本番運用」を主語に置いたエージェント基盤
Runable は、AI エージェントの「PoC から本番運用」のあいだを埋めるためのプラットフォームとして、2026年に最も注目すべき選択肢の 1 つです。Runbook を中心に据えた手順テンプレート、ブラウザ・デスクトップ・API・コードを横断する自律実行、標準搭載の観測ダッシュボード、人間の承認ステップ。これらを一体で提供する点が、Vercel AI SDK や Mastra、LangGraph、CrewAI などのライブラリ・フレームワーク群とは異なる立ち位置を作っています。
ただし、Runable が万能というわけではありません。Web アプリ内のチャット UI なら Vercel AI SDK、TypeScript で本番エージェントをコード管理したいなら Mastra、長時間の Python エージェントなら LangGraph、研究フェーズなら AutoGen、と適材適所はあくまで存在します。重要なのは、「フレームワーク 1 本」で揃えようとせず、レイヤーごとに最適解を選ぶことです。
AI Beat 編集部としては、業務オペレーションの自動化を本気で進める日本企業にとって、Runable は「真っ先に PoC してみる価値があるプラットフォーム」だと位置付けています。今後も Runable と周辺フレームワークの動きは継続的に追っていきます。
よくある質問（FAQ）
Q1. Runable は Vercel AI SDK の代わりになりますか
完全な代替ではなく、レイヤーが違います。Vercel AI SDK は Web アプリに組み込むためのライブラリ、Runable はホストされたエージェント実行プラットフォームです。Web アプリ内でチャット UI を作るだけなら Vercel AI SDK で十分ですし、業務オペレーションを横断的に動かすなら Runable のようなプラットフォーム型のほうが運用工数が下がります。両者を併用する構成も自然に成立します。
Q2. Runable はどのモデルを使えますか
OpenAI、Anthropic Claude、Google Gemini、Meta Llama など主要モデルプロバイダに対応しており、Runbook 単位でモデルを切り替えられます。ChatGPT・Claude・Gemini の比較記事で整理したように、タスクの性質によって最適モデルは変わるため、プラットフォーム側でモデル中立を保てる点は実務上の利点です。
Q3. セルフホスト版はありますか
標準では SaaS 提供で、フルセルフホスト版は公開されていません。エンタープライズ契約の中で VPC 専有や専用デプロイのオプションが用意される形です。完全オンプレ要件がある組織は、現状では Mastra や LangGraph をベースに自社で組むほうが現実的です。
Q4. ノーコード人材だけで運用できますか
Runbook の作成と運用は、ノーコード寄りのメンバーでも十分に可能です。ただし、社内 API との連携や複雑なエラーハンドリングまで踏み込むと、エンジニアによる Runbook 設計レビューがあったほうが安全です。最初の数本はエンジニアが Runbook テンプレートを用意し、運用者がパラメータを差し替える運用が定着しやすい形だと感じます。
Q5. Mastra や LangGraph と一緒に使えますか
組み合わせて使う構成は十分に成立します。たとえば、自社プロダクトのエージェントは Mastra で実装し、社内オペレーションだけ Runable に寄せる、といった分担が現実的です。Claude Sonnet 4.5 のような長文・推論モデルを、両者から共通で呼び出す構成もよく見ます。
Q6. 監査ログや権限分離は十分ですか
Runable は標準で実行トレース、ユーザー単位の権限管理、Runbook 単位の承認ステップを備えています。エンタープライズ要件で SOC 2 や ISO 27001 のような認証が必要な場合は、契約段階で公式に確認するのが確実です。社内のセキュリティ部門に提出する資料は、ベンダー側からテンプレートで提供されるケースが多くなっています。
参考リンク
