Superagentの料金と使い方【2026年11月】フレームワークからセキュリティSDKへの転換を追う

Superagentは、もともとオープンソースのAIエージェントフレームワークとして知られていましたが、2026年現在の公式サイトは「リポジトリとAIエージェントを守るセキュリティサービス」として運営されており、prompt injection対策やPII除去を行うセキュリティSDKと、GitHub連携のセキュリティワーカーが主製品になっています。開発元のsuperagent-aiは米国在籍のチームで、GitHubリポジトリはMITライセンスのまま更新が続いています。料金表示は公式と第三者メディアの間で割れているため、金額は仮置きせず、表示の現況から読み解く形で整理します。実機での操作は行っておらず、動作の実感は未検証です。

Superagentは本当にAIエージェントフレームワークなのか

• 旧フレームワークから転換した現在も、GitHubでの更新が続く現役プロジェクトであることが公式表示で確認できる
• guard、redact、scanを一つのSDKにまとめた構成で、実行時防御と事前診断を別ツールに分けずに済む
• TypeScriptとPythonの両方にSDKがあり、CLIとMCPサーバも公開されており、導入経路が複数用意されている
• MITライセンスを維持しており、コードを確認した上で自社環境に組み込む判断がしやすい
• 公開リポジトリ向けの利用が無料と明示され、OSSメンテナが低コストで試せる設計になっている
• 公式サイトでdotenvxのメンテナやCapchaseのエンジニアによる導入事例の言葉が確認できる

結論から言うと、2026年現在のSuperagentは、AIエージェントを「組み立てる」フレームワークではなく、AIアプリとエージェントを「守る」セキュリティ製品として提供されています。公式サイトの冒頭は「Keep your software secure」という表示で、リポジトリ、Webアプリ、エージェントの脆弱性を見つけて修正する方向性が打ち出されています。GitHubのリポジトリ説明も「open-source SDK for AI agent safety」へ書き換えられており、フレームワーク時代の案内は公式サイトから消えました。つまりSuperagentは消滅したのではなく、提供内容を転換した現役プロジェクトと読むのが正確です。

この転換を知らずに旧来の紹介記事だけを読むと、存在しない製品像と比較して予算を組む恐れがあります。逆に言えば、現行の製品像を正しく踏まえた上で評価すれば、guardrailsとセキュリティスキャンの二つの役割を一つのオープンソースSDKで賄える候補として、比較対象が絞りやすくなります。プロジェクトの現役性も、リポジトリの更新履歴で確認できる範囲では保たれています。

なぜフレームワーク時代の解説が今も流通し続けるのか

第三者レビューが明示する通り、古いディレクトリサイトや解説記事は、メモリやツール連携を備えたLLMアシスタント構築フレームワークとしてのSuperagentを取り上げています。この旧製品像は、公式サイトの現在の表示とは一致しません。調べる側が混乱する原因は、ここにあります。転換後のSuperagentを評価するなら、LangChainやcrewAIのようなオーケストレーション系の代替候補と比較するのは筋が悪く、guardrailsやセキュリティスキャン系のカテゴリで比べる方が実態に合います。

転換後のSuperagentは何をできるツールなのか

現在の中心製品は、セキュリティSDKと、GitHubに接続するセキュリティワーカーの二層です。SDK側は、guardが実行時のprompt injectionや危険なツール呼び出しを検知してブロックし、redactが個人情報や秘匿情報をテキストから自動で除去し、scanがリポジトリをAIエージェント向けの攻撃（リポジトリ汚染や悪意ある指示の混入）について診断します。レッドチームのシナリオ実行に相当するtest機能は、公式READMEで「Coming soon」と表示されており、公開当初から能力が確定しない旨を記しておきます。

guard機能はモデル選択の幅をどう確保しているのか

公式READMEは「OpenAI、Anthropic、Google、Groq、Bedrockなど、どのモデルでも動く」という位置付けを示し、加えてオープンウェイトのguardモデルを自社インフラで動かす選択肢を案内しています。第三者レビューの読み解きによれば、guardモデルは0.6Bから4B規模のGGUF形式で配布され、CPU推論でも50〜100ミリ秒程度の応答が可能とされ、外部APIへデータを送らずに検知を回す運用が想定されています。実際の検知精度やレイテンシは環境依存のため、この数字は公式表示の紹介にとどまるものであり、未検証です。

セキュリティワーカーは開発フローのどこに入るのか

SaaS側の製品群は、GitHub Appを通じて開発フローに接続します。プルリクエストが開かれた瞬間に新規コードを診断するPRセキュリティ、依存関係の更新を定期的に生成して評価する依存関係更新、配布物に対して敵対的な検証を行うレッドチーム、エージェントが読み込む材料を信頼できるか採る判断をするコンテキストguardrails、実行時に危険な動きを監視・遮断するランタイムguardrailsが、それぞれ独立したワーカーとして案内されています。検知結果はチェックランやPRコメントとして届き、修正はレビュー可能なプルリクエストの形で提案されるため、開発者は普段使うレビュー画面のまま対応できます。これが公式の謳い文句である「セキュリティ作業を独立したダッシュボードに閉じ込めない」構造です。

公式サイトには、dotenvxのメンテナが「エージェントが脆弱性を連結して攻撃経路を見つけ、修正まで行った」という趣旨の言葉と、Capchaseのエンジニアが「完璧ではないが実質的なguardrailsがある」と述べる事例が掲載されています。これらは公式に引用された声である以上、宣伝色を差し引いて読む必要がありますが、転換後の製品が実際のプロダクトで使われている証左としては有効な材料です。顧客名は第三者レビューでもFirecrawlやMastraなどが挙げられており、AIツール開発者を中心とした利用層が読み取れます。

導入はどの手順で進むのか、公式の3ステップを読み解く

公式サイトは導入を3ステップで案内しています。アカウント作成とリポジトリ接続、キー管理、チーム招待が最初の工程で、続いてGitHub Appをインストールすれば、プルリクエストごとにマージ前のチェックが走るようになります。最後の工程はMCPサーバの追加で、コーディングエージェントから診断やレッドチームを実行できるようにするものです。公式は「新しい習慣を3つだけ」という表現で案内しており、既存の開発プロセスに後付けできる構成を売りにしています。

GitHub Appで何が自動化されるのか

GitHub Appの接続後は、発見がチェックランとPRコメントの形で届くと公式が説明しています。つまり、セキュリティ担当がレポートを読み上げて共有するのではなく、レビューの場に自動で検査結果が現れる設計です。ワンクリックで修正候補のプルリクエストが作られる案内もあり、対応の初速を上げる構造になっています。検査の誤検知がレビューの速度を落とすリスクはあるため、導入初期は検査対象の範囲を狭く始めて調整するのが現実的です。

無料で始める場合の現実的な範囲はどこまでか

公開リポジトリであれば全製品が無償と公式が案内しているため、OSSプロジェクトのメンテナは全機能を試せます。プライベートリポジトリでは料金制度の表示が割れているため、手始めにSDKのguardとredactをアプリ側に組み込み、検知の挙動を確かめるのが費用面で安全な入口です。SDKはMITライセンスで公開されているため、コードを読んでから判断できることも、小規模チームにとってのメリットになります。

導入の当事者は、アプリを書く開発者と、リポジトリの設定を握るプラットフォーム担当に分かれます。SDKのguardとredactは前者の作業、GitHub Appの導入と権限の設定は後者の作業です。片方だけが進めると、検査は動いても修正の担当が決まらないままになります。作業の境界を最初に決めておくのが安全です。小さなチームで一人が両方を担う場合も、設定の変更履歴だけは残る形にしておくと、後から検査範囲を見直すときに迷いません。費用の見積もりを依頼する際は、検査の対象をアプリとリポジトリのどちらに置くかも伝えると、提示される範囲がぶれません。

料金が読みにくい理由は、公開リポジトリの無償利用とプライベートリポジトリの課金が同じ料金ページに混在している箇所にあります。自社のリポジトリがどちらに当たるかを先に確定しないと、表示されている数字の意味が定まりません。契約の前に、接続するリポジトリの数、検査を走らせる頻度、レッドチームの実行予定の三つを書き出し、その前提で見積もりを依頼する流れが確実です。監視側のAgentOpsと役割を分ける構成なら、防御の範囲だけを契約の対象にできるため、費用の比較も単純になります。

Superagentの料金は本当にいくらなのか、表示の割れを整理する

• 公式表示と第三者メディアで料金制度の記述が割れており、費用の見通しが立ちにくい
• 旧フレームワーク時代の解説記事が今も流通し、調べた情報が現在の製品と食い違うリスクが高い
• レッドチーム相当のtest機能は公開予定と表示されており、実力が確定していない
• レッドチームレポートの消費単位が大きいとされる場合、小規模チームでは回しにくい料金構造になる恐れがある
• 転換後の製品としての第三者レビューがまだ少なく、導入判断の参考情報が十分に蓄積されていない

料金については、この記事を書く上で最大の難所が公式と第三者メディアの表示の割れでした。公式サイトの現在の表示は「公開リポジトリは無料、プライベートリポジトリは接続リポジトリごとに年10,000ドル（年払い）」という単価制です。一方、2026年10月前後の第三者メディア2源は、クレジット制の料金表（Freeが月100クレジット、月499ドルで500クレジット、月1,499ドルで2,000クレジット、月3,999ドルで6,000クレジット、年払いで2割増しのクレジット）を一致して報じています。数字の一致する2源は第三者側にありますが、公式表示と矛盾するため、本稿は金額を断定せず、両方の表示を並べて提示するにとどめます。購入判断では公式サイトの料金表を確認してください。

クレジット制が正しいとすれば費用の重い箇所はどこか

第三者レビューの記載によれば、クレジットの消費単位はPR診断が1回1クレジット、コンテキストguardrailsの判定も1項目1クレジットである一方、レッドチームの1レポートが500クレジットとされています。この単位が正しければ、Freeの月100クレジットではレッドチームのレポートが月1件作れない計算になり、「診断は連続的に回し、レッドチームは四半期ごと」という予算の置き方がレビューの筆者から提案されていました。消費単位の数字は1源のみの情報であるため、鵜呑みにせず、導入検討時に公式へ確認すべきです。

年払いと月払いでは何が変わるのか

第三者報道のクレジット制が現行なら、年払いの選択でクレジットが2割増しになり、費用は前払いされると案内されています。請求は米ドル建てで、日本円の請求額は為替で変動します。税の扱いは今回参照した表示からは確認できませんでした。転換期の製品は料金制度も動きやすい段階にあるため、月払いで開始して消費パターンを測り、年払いへの移行は実測データの後で決めるのが安全です。

旧フレームワークと新しいセキュリティSDK、どちらの話をしているのか見分ける方法

Superagentに関する資料を読むとき、最初に確認すべきは資料がどちらの製品像を語っているかです。メモリやツール呼び出し、RAGアシスタントの構築手順を説明しているなら旧フレームワークの話で、prompt injectionの遮断やPII除去、リポジトリ診断を語っているなら現在のSDKの話です。公式ドキュメントのドメインがdocs.superagent.shであることも併せて確認すると、誤った資料に当たる事故は減らせます。GitHubリポジトリのREADME冒頭が現在の製品説明であることも、判断材料になります。

日付の確認には、リポジトリの更新履歴が役立ちます。第三者情報の記録では、このリポジトリの最終更新は2026年8月下旬に確認されており、CLIやMCPサーバのバージョン更新も同年8月に続いていました。つまり「転換はしたが停滞はしていない」のが現況であり、評価の対象は更新の有無ではなく、転換後の製品が自社の要件に合うかへ移ります。資料の新旧を確認する作業は、このツールの調査では読み込みと同じだけの時間を割く価値があります。

旧フレームワークを使っていたプロジェクトはどうすればよいか

旧フレームワークで構築を進めていた場合、公式サイトからは案内が消えている以上、その構成を本番に載せることはサポートの面で割に合いません。オーケストレーションの代替はLangChainやcrewAI、エージェントの記憶層ならMem0など、現行の選択肢が豊富です。一方で、旧来の用途に近い形でもSuperagent SDKのredactやguardは応用でき、アシスタントの入出力にセキュリティ層を挟む構成なら、転換後の製品がそのまま役に立ちます。切り替えの方針は「オーケストレーションは別ツールへ、防御層はSuperagentへ」と分けるのが現実的な整理です。

MCPサーバを使う使い方は何が新しいのか

現在のSuperagentは、MCPサーバを通じてコーディングエージェントと接続する構成を公式に案内しています。エージェントが検知結果を入手し、構造化された報告を返すこの循環が、第三者レビューが最も評価する仕掛けです。単に脆弱性を列挙して終わるスキャナと違い、発見から修正の提案、コーディングエージェントによる処理までが一続きのワークフローになります。接続先として公式表示ではGitHub、Cursor、Claude Code、Codexなどが挙げられており、AIネイティブな開発体制を前提とした設計であることが読み取れます。

guardrails系の競合と比べたときの強みと弱みはどこか

転換後のSuperagentの競合は、LLMアプリのguardrails専業ツールや、コードのセキュリティスキャン製品です。公式READMEが自ら「MITライセンスのオープンソース」と自認する通り、コードの透明性を求める層には届きやすい位置にあります。オープンウェイトのguardモデルによる自社インフラ運用が可能なことも、外部送信を避けたい要件との相性を良くしています。一方で、検知精度の第三者ベンチマークは今回確認できず、製品の実力の裏付けは事例の言葉と公式表示に依存しているのが現況です。

選定の場面では、防御をアプリ内に組み込むか、開発フロー側に置くかという配置の判断も必要になります。SDKのguardはアプリの入出力に挟む防御で、GitHub連携のワーカーはマージ前のコードに働く防御です。両方が同じ理念の下で設計されている一方、対象とするリスクが違うため、自社の脅威モデルに近い側から優先して導入する順番を決めるのが筋です。外部のユーザー入力が直接モデルへ渡るアプリならSDKを、エージェントが大量のコード変更を生む体制ならワーカー側を、それぞれ初手にします。

AgentOpsとは役割がどう違うのか

AgentOpsはエージェントが何をしたかを記録して再生する監視の役割で、Superagentは危険な入力や動きを検知して防御する役割です。エージェント運用では両者は前後工程の関係になり、記録と防御を一つの製品で満たす選択肢は限られるため、「監視はAgentOps、防御はSuperagent」と分担する構成は自然な組み合わせになります。反対に、両方の要件が薄い段階であれば、どちらも無料枠の範囲で様子を確かめてから予算を付ける判断ができます。

スキャナ系製品と比べたときの違いはどこか

従来型のセキュリティスキャナは、定期的な検査の結果をレポートで届けるのが普通です。Superagentは検査を開発フローに常駐させ、発見をチェックランやPRコメント、修正のプルリクエストに変換する構造を差別化としています。CVEやアドバイザリの記述の所有権を開発側が持つと公式が案内していることも、スキャナが発見者として名乗りを上げる形との違いです。この設計が実務でどれほど負担を減らすかは、導入事例の読解以上の検証ができていないため、未検証の箇所として記しておきます。

Superagentが向く人、向かない人を転換後の製品像で切り分ける

向いているのは、コーディングエージェントを日常的に使い、マージ前にコードが自動で検査される体制を求める開発チームです。公開リポジトリを運営するOSSメンテナにとっては、公式が無償で全製品を使えると案内しているため、コストゼロで防御層を試せる数少ない選択肢になります。prompt injectionやPII漏れへの対策を、アプリ側のSDKと開発フロー側の両方で重ねたいチームも相性が良いでしょう。

導入を見送る方がよいケースはどれか

反対に、次のケースでは見送り判断が合理的です。第一に、エージェントのオーケストレーション基盤を探している場合で、これは旧製品像を期待することになり、crewAIやLangChainなどの現行選択肢へ向かうべきです。第二に、料金の確定が契約の前提になる場合で、公式と第三者の表示が割れている以上、確定額が出るまでは契約を進めない方が安全です。第三に、レッドチーム実行が主目的の場合で、該当機能は公開予定と表示されており、着手可能な時期の確約が取れない限り依存できません。

導入判断はどの順番で進めるのが筋か

順路としては、公開リポジトリまたは無料枠でSDKのguardとredactをアプリに組み込み、検知の挙動と誤検知の量を自社データで確かめるのが最初の一歩です。その後でGitHub Appを接続し、PR単位の診断が開発の流れを阻害しないかを1〜2週間観察します。料金の交渉はこの観察の後です。旧フレームワークの資料を参照する際は必ず日付を確認し、過去の製品像に基づく判断をしないことが、このツールに限っては最重要の注意になります。

旧フレームワークで組んだアシスタントを残したい場合、移行先は用途で分かれます。文書検索を伴う構成ならLlamaIndex、実行時の防御だけを引き継ぎたいならSDKのguardという切り分けです。検知の専業と比べたいときはLakeraのような選択肢が参考になります。複数の防御を重ねると遅れと費用が積み上がるため、どの層で止めるかを決めてから製品を選ぶ順番が、結果として安く収まります。移行の是非は、残したい機能が防御なのか生成の連携なのかで決まります。前者ならSDKの導入だけで足り、後者なら別の基盤を選び直す作業が残ります。

体制面での補足もあります。セキュリティワーカーの提案する修正プルリクエストは、最終的に人間がレビューして承認する設計が公式に説明されており、重要な変更が自動マージされる仕様ではありません。AIの提案量が増える現代の開発では、レビューの受け口を誰が担うかが運用の成否を分けます。検査を増やす前に、レビューのキャパシティと週次の変更量を突き合わせておくと、導入後の詰まりを避けやすくなります。

よくある質問（FAQ）

まとめ

出典：AI Agent Store「Superagent」（2026年10月9日）／ClaudeWave「superagent」（2026年6月10日）