Grandream

公開: 2026.08.0511 min read

Cloudflareが「CI/CDをWorkflowsで動かす」新機能を発表｜YAMLではなくTypeScriptでCIを書く時代へ

AIエージェントの開発をご検討中ですか？ AIエージェント開発サービスを見る →

Cloudflareが2026年8月4日、公式ブログで「Run CI/CD for millions of repos — on your platform, on Cloudflare」と題した発表を行いました。コードの保存からビルド・テスト・デプロイまでを、すべてCloudflareのプラットフォーム上で完結させる構想の中核となる「CI SDK」の紹介です。

一見すると「CIサービスがまた1つ増えた」という話に見えますが、中身を読むと設計思想がかなり独特です。この記事では、発表の背景、アーキテクチャ、コード例、そしてLLMがビルド失敗を自動修正する「self-healing CI」まで、原文の内容を整理して解説します。

発表の要点

まず全体像を3行でまとめます。

Cloudflareのコード保存サービス Artifacts（プライベートベータ）に push されたコードをトリガーに、Cloudflare Workflows 上でCI/CDパイプラインを実行できるようになった
パイプラインはYAMLではなく TypeScript で書く。新提供の CI SDK がビルド実行・キャッシュ・デプロイのAPIを提供する
ビルド失敗時にLLMエージェントが原因を解析し、修正コミットを自動で push する self-healing CI のサンプルまで提示されている

対象として想定されているのは、個人開発者よりも「自社プラットフォーム上で顧客のコードを預かり、実行する企業」です。原文では、すでに複数のプラットフォーム企業がArtifacts上に数百万規模のリポジトリを保存していると述べられています。

背景：「誰もがプラットフォームを作っている」

Cloudflareはこの発表を「everyone is building a platform（誰もがプラットフォームを構築している）」という認識から始めています。

SaaS企業が顧客ごとのカスタムコードを預かって実行する、AIコーディングサービスが生成したアプリをホスティングする——こうした「他人のコードを預かって動かす」ビジネスが急増しており、そのたびに各社がコード保存・ビルド・デプロイの基盤を自前で組んでいます。

Cloudflareの答えは、この一式をマネージドで提供することです。

コンポーネント	役割
Artifacts	Git互換のコード保存・バージョン管理（プライベートベータ）
Workflows	CI/CDパイプラインのオーケストレーション（durable execution）
Sandbox（コンテナ）	ビルド・テストコマンドの隔離実行環境
R2	依存関係キャッシュ（環境スナップショット）の保存先
Workers AI + Agents	ビルド失敗を自動修復するLLMエージェント

ポイントは、CI専用のインフラを新設したのではなく、既存プロダクトの組み合わせでCIを実現していることです。その接着剤がCI SDKです。

設計思想：「CI/CDパイプラインは、ただのWorkflowである」

原文の核となる主張が「A CI/CD pipeline is just a Workflow」です。

CIパイプラインの実体は「順序と依存関係のあるステップ群を、失敗時のリトライ付きで実行するもの」であり、それはdurable execution（実行状態を永続化しながら進むワークフロー）そのものだ、という整理です。

この整理には実利があります。Workflowsの機能をCIがそのまま継承できるからです。

途中失敗しても進捗が消えない：あるステップが失敗しても、完了済みステップの結果は永続化されており、失敗地点からリトライされる。パイプライン全体のやり直しが不要
特定ステップからの再開：デバッグ時に任意のステップから再実行できる
可観測性：各ステップの実行状況をWorkflowsのダッシュボードでそのまま監視できる

GitHub ActionsなどYAMLベースのCIに対する不満として原文が挙げるのは「YAMLで定義するCI/CDはすぐに複雑化する」点です。条件分岐やループをYAMLの疑似構文で書く代わりに、TypeScriptの言語機能（if、try/catch、Promise.all）をそのまま使える、というのが売りになっています。

コードで見るCI SDK

実際のパイプライン定義を見ると設計が掴みやすいです。原文のコード例を引用します。

const deps: CiRunnerResult = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});

await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);

await deps.runner({
  name: 'deploy',
  command: 'bun wrangler deploy',
  cloudflareCredentials: {
    accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
  },
});

読み解くと、次の3点が特徴です。

1. 依存関係はコードの構造で表現する。 install の結果（deps）から後続の runner を生やすことで「installの環境を引き継いで実行する」ことを表し、Promise.all で lint・test・typecheck・build を並列実行しています。YAMLの needs: 記法に相当するものが、通常の非同期コードとして書けます。

2. キャッシュは「環境スナップショット」。 cache: { inputs: ['package.json', 'bun.lock'] } を指定すると、installステップ実行後のサンドボックス環境のスナップショットがR2に保存されます。次回以降、指定ファイルのハッシュが変わっていなければinstallをスキップし、スナップショットから即座に後続ステップを開始できます。node_modulesのアーカイブを自分で保存・復元するタイプのキャッシュより一段抽象度が高い仕組みです。

3. デプロイまで一気通貫。 cloudflareCredentials を渡して wrangler deploy を実行すれば、テスト通過後のデプロイまで同じパイプラインで完結します。

トリガーはpushイベント

パイプラインの起動は、wrangler設定でArtifactsのpushイベントをWorkflowに紐付けます。

{
  "triggers": {
    "events": [
      {
        "type": "cf.artifacts.repo.pushed",
        "filter": {
          "namespace": "CI",
          "repoName": "my-repo"
        },
        "target": {
          "type": "workflow",
          "workflow_name": "ci-workflow"
        }
      }
    ]
  }
}

注目は filter の挙動で、repoName を省略すると namespace内の全リポジトリに同じパイプラインが適用されます。プラットフォーム企業が「顧客リポジトリ数百万件に共通のCIを一度だけ書いて配る」ことを想定した、マルチテナント前提の設計です。

Self-healing CI：ビルド失敗をLLMが自動修正する

発表の中で最も野心的なのが、CIの失敗をLLMエージェントが自動修復するサンプルです。仕組みは次の通りです。

CIステップの失敗を try/catch で捕捉する
Agents SDKの HealingAgent を継承したDurable Object（Healer）に、失敗情報（ログ・イベント・ベースブランチ）を渡す
エージェントがコンテナ内で原因を解析し、修正を加えたコミットを別ブランチにpushする
人間はマージ前にその修正をレビューして採否を決める

コードはこう書かれています（抜粋）。

export class Healer extends HealingAgent {
  getModel() {
    return '@cf/moonshotai/kimi-k2.7-code';
  }
}

} catch (failure) {
  if (!isCiRunnerFailure(failure)) {
    throw failure;
  }

  const healed = await step.do(
    'heal',
    { retries: { limit: 0, delay: 0 }, timeout: '5 hours' },
    async () => {
      const healer = await getAgentByName(this.env.HEALER, event.instanceId);
      using result = await healer.heal({
        failure: enrichFailure({ failure, event, baseBranch }),
        prompt: 'Fix every observed failure without weakening validation.',
      });
      const { branch, commit, steps } = result;
      return { branch, commit, steps };
    }
  );

  throw new CiRunFailedWithFix(failure, healed);
}

細部にいくつか示唆があります。

使用モデルは getModel() の差し替えだけで選べる（例ではWorkers AI経由のコーディング特化モデル）
修復ステップには タイムアウト5時間 が設定されており、「エージェントに長時間の自律作業をさせる」前提の設計
プロンプトが「バリデーションを弱めずにすべての失敗を修正せよ」となっている点は実務的で、LLMが「テストを消して通す」型のズルをすることへの対策が織り込まれている
修正は直接mainに入るのではなく、CiRunFailedWithFix としてCI自体は失敗扱いのまま、修正ブランチが人間のレビュー待ちになる

「AIが直したコードを無検証で本番に流す」のではなく、失敗の一次対応（原因調査と修正案作成）だけを自動化し、採否は人間が握るという距離感です。

GitHub Actionsとの使い分けをどう考えるか

「CIサービスがまた増えた」と受け取ると、この発表は誤読します。GitHub Actionsとこの仕組みは、同じ用途の競合というより使う立場が違う道具です。分水嶺は「CIを使うのか、CIを自分のプロダクトに組み込むのか」にあります。

GitHub Actionsは、開発チームが使う完成品です。コードがGitHubにあり、PRベースで開発する限り、トリガー・権限・レビュー・ステータスチェックがすべて統合済みで、これを再発明する理由はありません。

CloudflareのCI SDKは、CIを機能として提供したい側の部品です。原文が「millions of repos」やnamespace単位の一括適用を強調している通り、想定ユーザーは「顧客のコードを預かり、顧客の代わりにビルド・デプロイする事業者」。GitHub Actionsでこれをやろうとすると、顧客ごとのorg管理・runner費用・Workflowファイルの配布と更新という運用課題に突き当たります。CI SDKの本丸はそこです。

軸ごとの比較

軸	GitHub Actions	Cloudflare CI（Workflows）
記述	YAML	TypeScript（言語機能をそのまま使える）
失敗時の再開	job単位の再実行（ステップ途中の状態は消える）	durable execution。完了済みステップを保持し失敗地点から再開
キャッシュ	`actions/cache` でパスを自分で保存・復元	環境スナップショットをR2へ。installごとスキップ
実行環境	Linux/macOS/Windows、self-hosted runner	コンテナ（Sandbox）。OSマトリクスは現状期待できない
エコシステム	Marketplaceに膨大なaction資産、事実上の業界標準	ほぼゼロ。SDKのAPIが全て
マルチテナント	不向き（org/repo単位の設計）	前提（1パイプラインを全リポジトリへ一括適用）
トリガー元	GitHub上のあらゆるイベント	Artifactsへのpushのみ
成熟度・料金	GA・料金体系確立	プライベートベータ・料金未公表

使い分けの目安

GitHub Actionsを使い続けるべきケース

通常のチーム開発。コードがGitHubにあり、PR・ブランチ保護・ステータスチェックと一体で回している
macOS/Windowsビルドが要る（モバイル・デスクトップアプリ）
Marketplaceの既存action資産に依存している

Cloudflare側が刺さるケース

顧客コードを預かるプラットフォーム事業（SaaSのカスタムコード実行、サイトビルダー、AIコード生成サービス）。CIを「自社機能」として数千〜数百万リポジトリに配れる
AIエージェントの「生成→検証→自動修復」ループを回す基盤。self-healingのような長時間（例では5時間タイムアウト）の自律修復は、Actionsのjob時間制限とステートレスな実行モデルでは組みにくい
デプロイ先がWorkersで、Cloudflare内で完結させたいチーム（ただし単純な「push→Workersデプロイ」だけなら既存のWorkers Buildsで足りる）

注意点

コードがArtifactsにあることが前提で、GitHubのリポジトリを直接トリガーにはできない。一般チームには現状、乗り換え動線自体がない
Artifactsはプライベートベータ（申請制）で料金未公表。事業基盤に据える判断はまだ時期尚早
「YAMLよりTypeScriptが楽」は事実だが、それ単体では移行理由として弱い。Actionsの辛さの大半はYAMLではなくデバッグ性とエコシステム依存にあり、そこはどちらも銀の弾丸ではない

競合として意識すべき相手は、GitHub Actionsそのものというより、各プラットフォーム企業が自前で組んできた社内ビルドパイプラインです。一般の開発チームにとっては「今すぐ乗り換える対象ではないが、自分たちが使うSaaSの裏側がこれになっていく」タイプの発表と捉えるのが正確です。

まとめ

Cloudflareが、Artifacts（コード保存）へのpushをトリガーにWorkflows上でCI/CDを実行する仕組みとCI SDKを発表した
パイプラインはYAMLではなくTypeScriptで記述し、並列実行・条件分岐・エラー処理を言語機能でそのまま書ける
durable executionにより、失敗時も完了済みステップの結果が保持され、途中から再開できる
キャッシュはサンドボックス環境のスナップショットをR2に保存する方式で、依存インストールを丸ごとスキップできる
ビルド失敗をLLMエージェントが解析し修正コミットをpushする「self-healing CI」を提示。ただし修正の採否は人間がレビューする設計
GitHub Actionsとの関係は「開発チームの道具 vs プラットフォーム構築者の部品」。通常のチーム開発はActions継続、顧客コードを預かる事業者やAI修復ループを組む基盤ではCloudflare側が刺さる
Artifactsはプライベートベータ・料金未公表。一般チームの乗り換え先というより、CIを組み込みたいプラットフォーム構築者向けの布石

「CI/CDパイプラインはただのWorkflowである」という整理は、CIを特別なインフラではなく汎用のdurable executionに還元する動きとして、GitHub Actions一強の構図に一石を投じるものです。AIエージェントによるコード生成が増えるほど「生成→検証→自動修復」のループを回す基盤の需要は高まるため、その受け皿を狙った発表と読むのが良さそうです。

出典：Run CI/CD for millions of repos — on your platform, on Cloudflare（Cloudflare公式ブログ・2026年8月4日）

CSエージェントで顧客対応を自動化しませんか？

デモ・無料相談・資料請求を承っています。

デモをみる無料相談する資料請求する