比較
CRACIとRunsOnの比較
RunsOnは、固定のライセンス料で、使い捨てのGitHub Actionsランナーを自社のAWSアカウントに配置します。CRACIは、各ビルドが取得したものを記録し、エグレスポリシーを適用するマネージドランナー上でGitHub Actionsのジョブを実行します。
更新日
結論
RunsOnは、ランナー群の保守の手間なく使えるセルフホスト型GitHub Actionsランナーです。CloudFormationスタックまたはTerraformモジュールを1つ使ってAWSアカウントにデプロイすると、以降はジョブごとに任意のタイプの新しいEC2インスタンスが割り当てられ、AWSが原価でコンピュートを請求します。自社のクラウドアカウント内でランナーを動かし、とりわけスポットインスタンスでコンピュート費用を最小限に抑えたいなら、RunsOnに勝るものはなかなかありません。
CRACIは、サプライチェーンセキュリティをネイティブに扱うCIです。GitHub Actions互換のマネージドランナーであり、セキュリティは後付けのツールではなくランナーの一部です。CRACIはビルドが取得したすべての外部依存関係を記録し、ビルドネットワークにエグレスポリシーを適用し、その記録をSBOM、脆弱性の監視、エビデンスに変換します。どちらの製品もジョブを実行するランナーを置き換えるため、選ぶのはどちらか一方です。
一覧比較
| 機能 | CRACI | RunsOn |
|---|---|---|
| 製品の概要 | サプライチェーンセキュリティを組み込んだマネージドGitHub Actionsランナー。 | 自社のAWSアカウントにデプロイするセルフホスト型GitHub Actionsランナー。 |
| セットアップ | CRACI GitHub Appをインストールし、runs-on: craciを設定。 | CloudFormationスタックまたはTerraformモジュールを1つデプロイし、runs-onラベルを変更。 |
| ジョブの実行場所 | ジョブごとに1台の分離されたVM。CRACIが欧州のベアメタルインフラで管理。 | ジョブごとに新しいEC2インスタンス。自社のAWSアカウントとVPC内。 |
| 自社クラウドアカウントでのランナー | Enterprise向けの顧客ホスト型ランナーをロードマップに掲載 | スタック全体が自社のAWSアカウントで稼働 |
| 観測した依存関係からのビルド時SBOM | 全ジョブ、完全性の状態付き、キャッシュされたパッケージも含む | ドキュメント記載の機能にはなし |
| ビルドネットワークのエグレスポリシー | デフォルト拒否または許可、ジョブ前に検証、フェイルクローズ | StepSecurity Harden-Runner経由。StepSecurityのエンタープライズライセンスが必要 |
| 脆弱性の監視 | 監視対象のSBOMを再評価 | ドキュメント記載の機能にはなし |
| CRAのエビデンスとレポート | CycloneDXまたはSPDXのSBOM、APIによる記録、CRA通知の内容の準備に対応。レポートのエクスポートはなし | ドキュメント記載の機能にはなし |
| Linuxランナー | x86-64とARM64、1〜32 vCPU | x64とarm64、アカウントで起動できる任意のEC2インスタンスタイプ |
| Windowsランナー | 現時点ではLinuxのみ | x64上のWindows Server 2022と2025 |
| macOSランナー | 現時点ではLinuxのみ | macOSのジョブはGitHubホステッドランナーのまま |
| キャッシュ | GitHub Actionsキャッシュ、ローカル・リモート・バインドマウントのレイヤーキャッシュ | VPC内のS3キャッシュ、Dockerレイヤーキャッシュ、EBSとEFSのボリューム |
| 固定の送信元IP | 固定のエグレスIPレンジ | Elastic IP付きNATゲートウェイ経由、AWSの請求に計上 |
| 料金モデル | 2 vCPU 1分あたり$0.004、秒単位で計測。月額料金なし。 | 年額固定ライセンス約$348(€300)から、加えてコンピュート分のAWS料金(2026年9月時点)。 |
- 対応
- 一部対応
- 非対応
- ロードマップに掲載
RunsOnが優れている点
自社のアカウント、自社のデータ。コントロールプレーン、ランナーVM、S3キャッシュ、ログはすべて自社のAWSアカウント内にあり、RunsOn自体のデータフローはライセンスの検証、テレメトリー、サポートに限られます。セキュリティレビューで「第三者が自社のコードとシークレットを実行する」ことが問題になるチームにとって、RunsOnはまさにその答えとして作られています。CRACIのランナーは現在マネージド型で、顧客ホスト型ランナーはEnterprise向けにロードマップに掲載されています。
任意のインスタンスを、ジョブごとに1台。runs-onラベルでマシンを選べるため、ジョブごとに大型のコンピュート最適化インスタンス、GPU、ローカルNVMeストレージ、Windowsを指定できます。すべてのジョブに新しいEC2インスタンスが割り当てられ、終了時に破棄されます。RunsOnによれば、ジョブは通常約30秒で開始し、ウォームプールを使えば6秒未満です。
コスト。RunsOnはAWSのコンピュートに上乗せをせず、年額約$348(€300)からの固定ライセンス料を課金します。RunsOnは、結果としてGitHubホステッドランナーより7〜12倍安くなるとしています。オンデマンドへの自動フォールバック付きのスポットインスタンスを使えば、費用はさらに下がります。これらはRunsOnが示す数字であり、実際の金額はインスタンス構成とリージョンで決まります。
キャッシュと可観測性。VPC内のS3ベースのキャッシュがGitHubのキャッシュを容量上限なしで置き換え、Dockerレイヤーキャッシュも組み込まれています。EBSのスティッキーディスクとEFSの共有ボリュームで、ジョブ間で状態を保持できます。ジョブごとのメトリクスとコストレポートは、CloudWatchとOpenTelemetryに送られます。
セキュリティアドオン。StepSecurity Harden-Runnerとの統合により、エグレスの監視とフィルタリング、そしてビルド中のソースコード改ざんの検出が加わります。StepSecurityのエンタープライズライセンスが必要です。
料金とサイズ
| 機能 | CRACI | RunsOn |
|---|---|---|
| Linux x64、2 vCPU | 1分あたり$0.004、RAM 6 GB | スポット(m7i-flex.large)で1分あたり約$0.0009(RunsOnが掲載するus-east-1の価格) |
| Linux ARM64、2 vCPU | 1分あたり$0.004、RAM 6 GB | スポット(m8g.large)で1分あたり約$0.0010(RunsOnが掲載するus-east-1の価格) |
| コンピュートの請求元 | CRACI、秒単位(最も近い秒に丸め) | AWS、秒単位、RunsOnの上乗せなし。スポットまたはオンデマンド |
| 固定料金 | なし | 法人1社あたり年額約$348(Starter)、$1,044(Growth)、$2,088(Scale)、$4,176(Enterprise)(€300〜€3,600) |
| 無料での利用 | スタートアッププログラム:10万分以上の無料ビルド時間と手厚いオンボーディング | 公開での謝辞表示を条件に非商用利用は無料。15日間のトライアル |
| その他のコスト | ビルド時間:1 vCPU 1分あたり$0.002 | AWSのネットワーク、ストレージ、固定IP用のNATゲートウェイ。スタックの運用とアップグレードにかかる時間 |
コンピュートだけで見れば、スポットインスタンスでのRunsOnは、CRACIの2 vCPU 1分あたり$0.004のごく一部のコストで済みます。ただし、比較は1分あたりの料金だけではありません。RunsOnでは、ライセンス料に加えて、固定IP用のNATゲートウェイなどランナー周辺のAWSサービスの費用もかかり、アップグレード、AWSのクォータ、インシデント対応を含め、スタックは自社チームが担います。CRACIは秒単位で計測される1分あたりの単一料金で、月額料金はなく、インフラの運用はCRACIが行います。最新の条件はCRACIの料金を、より広い観点でのトレードオフはマネージドランナーとセルフホストランナーの比較をご覧ください。
速度については、CRACIは高速なハードウェア、短いキュー待ち時間、キャッシュにより、GitHubホステッドランナーの約2倍の速さでビルドを実行します。RunsOnの速度は選択したインスタンスタイプによります。両者を直接比較するベンチマークは実施していません。
CRACIの違い
ビルドが取得したものの記録
各ジョブの実行中、パッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットといったパッケージソースへの通信を記録します。依存関係のエビデンスはCIキャッシュと一緒に引き継がれるため、キャッシュから復元されたパッケージもカウントされます。これには、インストールフックやビルドスクリプトがダウンロードするコードやベースイメージのレイヤーなど、どのロックファイルにも記載されない隠れた依存関係も含まれます。すべてのジョブが、ジョブごと・キャッシュごとの完全性の状態を備えたCycloneDXまたはSPDXのSBOMを生成します。
ビルドがアクセスできる範囲の制御
セキュリティグループはRunsOnのランナーがどのネットワークにアクセスできるかを決めますが、ジョブがどのパッケージレジストリを使うべきかは把握していません。CRACIのエグレスポリシーはそれを把握しています。デフォルト拒否またはデフォルト許可、24種類の組み込みソフトウェアソースプリセット、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、HTTPSとSSH経由のGitに対応した型付きのカスタムソース、そして明示的なTLS、TCP、UDP、ICMPのルールを備えています。ポリシーはジョブの開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。ポリシーはビルドに必要なものだけを許可するため、誰も見たことのない攻撃であっても、ビルドに不要なホストへの情報流出をブロックします。
RunsOn上のHarden-Runnerが一歩先を行く点もあります。ビルド中のソースファイルの改変も監視しますが、CRACIはこれを行いません。
来歴と監視
APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名せず、SLSAレベルも主張していません。ビルドやリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを継続的に再評価します。
2つの異なるセキュリティの問い
RunsOnは「自社のコード、シークレット、ランナーの状態を誰が保持しているか?」という問いに、すべてを自社のAWSアカウントにとどめることで答えます。CRACIが答えるのは別の問いです。「このビルドは何を取り込み、どこに接続したか?」CRACIはすべてのジョブを専用の分離されたVMで実行し、お客様のソースコードを保存せず、ISO 27001認証を取得しています。監査人、顧客、そしてCyber Resilience Actが求めるのは、この2つ目の問いへの答えです。
デモを予約して、お客様自身のワークフローのSBOM、ネットワークトレース、来歴をご確認ください。
どちらが適しているか
RunsOnが適しているケース
- ランナーを自社のAWSアカウント内で、VPCのリソースと並べて実行する必要がある。
- コンピュート費用の最小化を最も重視し、AWSでスタックを運用することに抵抗がない。
- Windowsランナー、GPUインスタンス、特定のEC2インスタンスタイプが今すぐ必要である。
- プロジェクトが非商用であり、RunsOnを無料で利用できる。
CRACIが適しているケース
- 各リリースに何が含まれたかを、ビルドそのものから示す必要があるソフトウェアを出荷している。
- 追加のライセンスなしで、フェイルクローズで動作するポリシーにより、ビルドがアクセスできる範囲を制限したい。
- すべてのワークフローにツールを追加することなく、出荷したものを監視したい。
- CIインフラを自社で運用せず、欧州のインフラでビルドしたい。
CRACIを選ぶことで手放すもの。自社のAWSアカウント内のランナー(Enterprise向けにロードマップに掲載)、Windowsランナー(同じくロードマップに掲載)、そして最小のコンピュート費用です。得られるのは、パイプラインに別のスキャナーを追加しなくてもセキュリティとコンプライアンスに活用できるビルドの記録であり、それを自ら運用する必要のないインフラ上で得られます。
Cyber Resilience Actへの対応
EUのCyber Resilience Actは、製造業者に対し、各リリースに何が含まれているかを把握し、その脆弱性に対処することを求めています。報告義務は2026年9月から、全面適用は2027年12月からです。セルフホスト型ランナーはそれ自体ではこのエビデンスを生成しないため、ワークフローにSBOMツールやスキャンツールを追加することになります。CRACIはビルドの記録からエビデンスを生成し、SBOMをCycloneDXまたはSPDXでエクスポートします。企業がより広範なCRAコンプライアンスのプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスの、かなりの部分を自動化します。
RunsOnからの移行
CRACIが置き換えるのはランナーであり、GitHub Actionsではありません。ワークフローとGitHubのUIはそのままで、ジョブのラベルがruns-on: craciになります。ジョブではDocker Engine、Buildx、Compose v2、GitHub互換のUbuntu 24.04イメージ、x86-64でのネステッド仮想化を利用できます。詳しくはCI/CD連携とビルド時のSBOM生成をご覧ください。スタートアップはスタートアッププログラムにお申し込みいただけます。
キャッシュ、OIDCの信頼ポリシー、IP許可リスト、フォールバックについては、GitHub Actionsのランナープロバイダーを切り替える方法をお読みください。
RunsOnとCRACIに関するよくあるご質問
料金、ホスティング、プラットフォーム、セキュリティについて、各ベンダーの公開情報に基づいてお答えします
RunsOnとは何ですか?
RunsOnは、セルフホスト型のGitHub Actionsランナーを製品として提供するものです。CloudFormationスタックまたはTerraformモジュールを1つ自社のAWSアカウントにデプロイすると、RunsOnがジョブごとに新しいEC2インスタンスを起動し、ジョブの終了時に破棄します。ランナー、キャッシュ、ログ、認証情報は自社のAWSアカウント内にとどまります。2023年に、フランスのレンヌを拠点とするCyril Rohr氏が創業しました。
RunsOnの料金はいくらですか?
2026年9月時点で、RunsOnは法人ごとに年額固定のライセンス料を課金しています。月に起動するランナー数に応じて、Starterは年額約$348(€300)から、Growthは約$1,044(€900)、Scaleは約$2,088(€1,800)、Enterpriseは約$4,176(€3,600)です。コンピュートはAWSが秒単位で直接請求し、RunsOnの上乗せはありません。RunsOnは、us-east-1の2 vCPU x64スポットインスタンスを1分あたり約$0.0009と掲載しています。非商用利用は無料で、15日間のトライアルがあります。
RunsOnはCRACIより安いですか?
コンピュートについては安く、スポットインスタンスでは大きな差があります。CRACIは2 vCPU 1分あたり$0.004ですが、RunsOn経由の2 vCPUスポットインスタンスはus-east-1で1分あたり約$0.0009で、これにライセンス料が加わります。総額にはAWSのネットワークとストレージ、スタックの運用にかかる時間も含まれます。CRACIがランナーに加えるのはビルドの記録です。すべてのジョブのSBOM、エグレスポリシー、来歴データ、脆弱性の監視を提供します。
RunsOnはSBOMやビルドの来歴を生成しますか?
ドキュメントに記載された機能にはありません。RunsOnは、自社のAWSアカウントにおけるコンピュート、キャッシュ、コスト、可観測性に注力しています。CRACIは、キャッシュから復元されたパッケージを含め、すべてのジョブが取得するパッケージを記録し、完全性の状態付きのCycloneDXまたはSPDXのSBOMを生成します。APIはSBOM、ネットワークトレース、来歴を返します。
RunsOnでビルドがネットワーク上でアクセスできる範囲を制限できますか?
RunsOnのランナーは自社のVPC内に置かれるため、AWSのセキュリティグループとルーティングが適用され、固定のエグレスIPはNATゲートウェイから提供されます。ジョブ内でのエグレスフィルタリングについては、RunsOnはStepSecurity Harden-Runnerと統合しています。Harden-Runnerは各ジョブの外向き通信のベースラインを作成し、それを許可リストとして適用できますが、RunsOnで使うにはStepSecurityのエンタープライズライセンスが必要です。CRACIはランナー自体でエグレスポリシーを適用します。デフォルト拒否またはデフォルト許可、24種類の組み込みソフトウェアソースプリセットを備え、ジョブの開始前に検証され、フェイルクローズで動作します。
CRACIを自社のAWSアカウントで実行できますか?
現時点ではできません。CRACIのランナーは欧州のインフラ上のマネージド型で、顧客ホスト型ランナーはEnterpriseプラン向けにロードマップに掲載されています。自社のAWSアカウント内でのランナー運用が必須要件であれば、RunsOnはまさにそのために作られています。
CRACIはWindowsやmacOSのランナーに対応していますか?
CRACIは現在、x86-64とARM64のLinuxで動作し、WindowsとmacOSはロードマップに掲載されています。RunsOnはWindows Server 2022と2025、GPUインスタンスを提供していますが、RunsOnでもmacOSのジョブはGitHubホステッドランナーのままです。
乗り換えるにはGitHub Actionsのワークフローを書き直す必要がありますか?
いいえ。どちらの製品も置き換えるのはランナーであり、GitHub Actionsではありません。ワークフロー、トリガー、GitHubのUIはそのままで、CRACIではジョブのラベルがruns-on: craciになります。