新機能：Chainguard Checks のご紹介
本ブログは「Chainguard」社で2026年10月14日に公開された「 Introducing Chainguard Checks 」の日本語翻訳です。
Chainguard Checks のご紹介
本日、私たちは Chainguard Checks をベータ版としてリリースします。これにより、開発者と AI エージェントは、時間のかかる CI を待つことなく、安全にコードをテストし、テストに失敗した場合、修正できるようになります。Checks は CI を、どこからでも呼び出せる高速なコミット前チェックに変えます。Chainguard Workspaces と組み合わせれば、エージェントと開発者は CI チェックを開発ループに直接取り込むことができ、待ち時間を削減してデリバリーを加速できます。
Chainguard では、エンジニアリングチームとともに数千もの自律型 AI エージェントを運用し、大規模にソフトウェアを継続的にビルド、パッチ適用、保守しています。その一環として、エージェントはループで動作します。コードを書き、テストを実行し、フィードバックに基づいて修正を洗練させていくのです。エージェントのイテレーションをひとつ残らず従来の GitHub Actions のキューに流していたことで、私たちのワークフローは破綻してしまいました。
従来の CI には、3 つの問題がありました。
- セットアップ時間とコンピュートリソースの浪費： パイプラインを実行するたびに、テストが走る前に同じパッケージや依存関係（
apt-get、npm ci、go mod downloadなど）を再ダウンロードしており、不要な時間とコンピュートリソースを消費していました。 - 推論中のコンテキストの喪失： フィードバックサイクルが長いため、結果を待つ間にエージェントの推論中のコンテキストが途切れ、バグ修正が遅くなり、トークンを大量に消費し、効率が大きく低下していました。
- 広範な攻撃対象領域： 長期間有効な機密情報と信頼できないコードの実行を同居させています。プロンプトインジェクションを受けたエージェントひとつ、あるいは悪意あるインストールスクリプトひとつで、メモリから静的なキーが流出しかねません。
遅い CI キューが開発スピードのボトルネックになることは許容できなかったため、私たちは安全な CI をツール呼び出しとして利用できるようにし、検証をシフトレフトすることで、自らこの問題を解決することにしました。このアプローチをお客様に紹介したところ、自分たちも使いたいという声が寄せられました。CI への展開は、ソフトウェアサプライチェーンを保護するうえで自然な次のステップだったため、同じ課題を抱えるデザインパートナーとの協業を開始しました。その一社が Cuscal です。同社のクラウドプラットフォーム担当シニアマネージャーである Brad McCoy 氏は、次のように述べています。
「オーストラリア全土の銀行、フィンテック企業、法人が、安全な資金移動のために Cuscal を頼りにしています。デジタル決済インフラを拡大するなかで、AI 活用に向けた高速で安全なワークフローをエンジニアに提供することは最優先事項です。CI に関しては、エージェントが従来のシステムの欠陥を浮き彫りにしています。機密情報への暗黙的なアクセスを与えてしまう破綻したセキュリティモデルから、コールドセットアップやコミット後の遅れた検証といった非効率まで、さまざまです。初期のデザインパートナーとして Chainguard と緊密に協力し、エンドツーエンドでソフトウェア開発の未来を形づくっていけることを楽しみにしています。」
それでは、Chainguard Checks の仕組みを詳しく見ていきましょう。
ランタイムアーキテクチャ：呼び出しからアテステーションまで
リポジトリを Chainguard Checks に移行するには、2 つの簡単なステップだけで済みます。
- Chainguard App をダウンロードしてインストールします。
- 宣言的な設定ファイル（
.chainguard/ci/workflow_name.yaml）をリポジトリのルートに追加します。このファイルは手動で書くこともできますし、chainctl develop migrateを実行して既存の CI ワークフローから自動生成することもできます。
.chainguard/ci/workflow_name.yaml
environment:
packages: [go~1.25, nodejs~22, postgres-17, docker] # Chainguard OS, apko-built
resources: {cpus: 8, memory: 16Gi}
warm: # snapshot point — everything below is pre-baked
- go mod download
- npm ci --prefix web
checks:
lint: golangci-lint run ./...
test: go test ./...
e2e: {run: make e2e, needs: [test]}
egress:
allow: [proxy.golang.org, registry.npmjs.org]
# everything else is denied. secrets: none — the proxy injects them in flight.
設定が完了すると、Chainguard Checks は 3 つのステージを経て実行を処理します。
ステージ 1：呼び出しとコンテキスト
GitHub Actions に対する長年の不満のひとつは、ローカルで使えないことです。変更をテストするには、試験的なコミットをプッシュし、リモートのキューを待ち、それを繰り返さなければなりません。
Checks はこの死角をなくします。開発者とエージェントは、chainctl CLI や Git の pre-commit フックから本番と同じ CI テストスイートを実行でき、問題があれば早い段階で発見できます。
Chainguard Workspace 内で実行する場合、このフィードバックループはシームレスです。エージェントはループ内のツール呼び出しとして Checks を直接呼び出します。テストの実行中、Workspace は判定結果を待つ間スナップショットに自動的に一時停止し、エージェントの推論コンテキスト、ファイルツリー、ウォームビルドキャッシュを保持したまま、コンピュートリソースを一切消費しません。
コミット後の検証については、Chainguard App が GitHub リポジトリと直接連携し、すべてのプッシュがマージ前にまったく同じ基準で検証されるようにします。
呼び出しがローカルのシェル、エージェントのサンドボックス、GitHub の Webhook のいずれから始まった場合でも、実行は Chainguard の堅牢化された環境に移ります。
ステージ 2：実行と分離
ワークフローの各ステップは、FIPS 準拠のツールチェーンを含む CVE ゼロの Chainguard パッケージから構築された、分離された microVM 内で起動します。microVM には必要な依存関係だけが事前に読み込まれており、ウォームスナップショットから起動するため、コールドセットアップの段階を省略できます。バックグラウンドの調整ループは、ロックファイルが変更されるたびにこれらのウォームスナップショットプールを継続的に再ビルドします。これにより、重いインストールのコストはコミット毎ではなく、依存関係ごとに一度だけ、バックグラウンドで支払われます。
起動が速いだけではありません。信頼できないコードを安全に実行できます。ネットワークトラフィックは、設定ファイルで定義された宣言的な egress（送信）ポリシーによって独立して制御されます。信頼できないコードや侵害された依存関係が、承認されていないエンドポイントへの不正な接続を試みた場合、プロキシは自動的にそのリクエストを拒否するか、microVM を破棄します。
さらに、microVM 環境ではディスク上にもメモリ上にも認証情報を保持しません。ワークフローのステップが外部サービスへの認証を必要とする場合、通信を仲介するホスト側のプロキシが、送信リクエストのヘッダーに一時的な認証情報を通信中に注入します。ディスク上に認証情報ファイルを必要とするツールには、代わりに短期間だけ有効な暗号化された代替値が渡されます。そのため、たとえ流出したとしても、使えるものは何もありません。
ステージ 3：判定とマージ
エージェントが一度で正解にたどり着くことはまれです。テストを通過させるまでに、何度もイテレーションが必要になることがよくあります。このフィードバックループを標準的な GitHub Actions のキューに対して回すと、壊れたコミットの履歴が積み上がり、パイプラインが詰まってしまいます。
Chainguard Workspaces と組み合わせれば、こうした失敗したイテレーションは閉じ込めておけます。Workspace は失敗したログをメモリに読み込んだ状態で即座に再開し、エージェントはコンテキストを再構築するための余分なトークンを消費することなく、次のイテレーションで軌道修正できます。合格判定が出たときにだけ、エージェントはループを抜けて、事前検証済みのプルリクエストを作成します。
チームは、これらの合格判定を直接検証するマージゲートを設定することもできます。これにより、リポジトリは検証済みのコードを認識し、冗長な CI 実行を安全にスキップしてコンピュートリソースを削減できます。
体験してみよう
ソフトウェアサプライチェーンを保護するには、デプロイするアーティファクトと、それをビルドする環境の両方を保護する必要があります。私たちはまず、コンテナイメージとパッケージをデフォルトで信頼できるものにすることから始めました。
Chainguard Checks によって、私たちはその同じモデルを実行環境そのものにまで拡張し、遅く脆弱な CI パイプラインを、高速で安全なコミット前のツール呼び出しに変えます。これにより、エージェントと開発者はコンテキストの中で即座にフィードバックを得られ、すべてのプルリクエストが最初からグリーンの状態で生まれます。
開発者とエージェントのための、高速でデフォルトで安全な CI がどのようなものか気になる方は、ぜひお試しください。Chainguard Checks は現在ベータ版として提供中で、毎月 500 時間を無料でご利用いただけます。
FAQ
なぜコンテナではなく microVM なのですか？
コンテナは、共有カーネル上のプロセス分離にすぎません。microVM は、ビルドステップごとに専用のカーネルを起動します。このハードウェアレベルの境界によって、信頼できないコードや侵害された依存関係がサンドボックスの外に到達したり、隣接するワークロードを覗き見たりすることを防ぎます。
既存の GitHub Actions ワークフローはどうなりますか？
ワークフローは手動で変換することもできますし、chainctl checks migrate コマンドが自動で作成するドラフトから始めることもできます。
独自のツールチェーンや特定のシステムパッケージにはどう対応しますか？
環境仕様は、Chainguard OS 上に構築された宣言的なパッケージリストを使って .chainguard/ci/demo.yaml で定義します。イメージは apko を使って組み立てられるため、ビルドに必要なツール、言語ランタイム、バックグラウンドサービス（PostgreSQL や Redis など）を正確に宣言できます。バックグラウンドのウォーマーが、コンテンツアドレス指定された再現可能な microVM のベースイメージをソースから直接ビルドするため、サプライチェーンを完全に可視化できます。
Chainguard Checks はローカルの pre-commit フックや IDE ツールで使えますか？
はい。Git の pre-commit フック、ターミナルのスクリプト、あるいは Claude Code のような AI コーディングツールに組み込むことができます。これにより、開発者やコーディングエージェントは、プルリクエストを作成する前に、マージゲートとまったく同じ判定を得ることができます。
Checks を使うには Chainguard Workspaces が必要ですか？
いいえ。Checks は単独で動作します。開発者は chainctl CLI や Git の pre-commit フックから実行でき、プルリクエストでは GitHub App を通じて利用でき、エージェントは Claude Code などのツールで MCP サーバーや SDK を介して CI を呼び出せます。どの経路でも、同じウォームで分離された microVM 内で同じチェックが実行され、同じ署名付きの判定結果が返されます。
Workspaces は、自律型エージェントのためのより緊密なフィードバックループを追加します。Workspace 内のエージェントが CI を呼び出すと、Workspace はスナップショットに一時停止するため、チェックの実行中はコンピュートを消費しません。その後、構造化された失敗ログが稼働中のセッションに直接注入された状態で再開するため、エージェントは完全なコンテキストとファイルの状態を保ったまま問題を修正できます。Checks はエージェントに偽ることのできない判定を与え、Workspaces はその判定に基づいて行動するための安全な場所を与えます。
Chainguard Checks はコンプライアンス要件に対応できますか？
Checks はコンプライアンスを念頭に置いて構築されています。環境は FIPS パッケージを含む Chainguard OS パッケージからビルドされ、すべての実行は、何が実行されたかを示す署名付きアテステーションを生成する、ハードウェアレベルで分離された microVM 内で行われます。特定の規制、データレジデンシー、フレームワークに関する要件がある場合は、当社チームとの打ち合わせをご予約ください。
Chainguard Checks の料金体系はどうなりますか？
Chainguard Checks は、消費したコンピュートリソースに基づいて課金されます。基盤となるアーキテクチャは、その消費を最小限に抑えるよう設計されています。
- ウォームスナップショット： 依存関係が microVM スナップショットに事前に組み込まれているため、課金対象となるセットアップ時間を削減できます。
- アテステーションによるゲーティング： 下流の CI は合格済みのコードを再実行しないため、GitHub Actions や従来の CI における高価なランナー時間を節約できます。
これらすべてによって、より高いセキュリティ、より速いフィードバック、そしてより低いコンピュートリソースが実現します。
クリエーションラインでは：
Chainguardの導入・運用の支援を行っております。お気軽にお問い合わせください。
