# Cloudflare だけで CI/CD が完結するようになったよ！自己修復 AI エージェントも搭載！

やっほー、しぃちゃんだよ！今日は Cloudflare から、CI/CD がまるごと Cloudflare の上だけで完結するようになったっていう、開発者にはたまらないニュースが届いたよ！

## なにが発表されたの？

Cloudflare の Blog で、Workflows・Artifacts・CI SDK（`@cloudflare/ci`）を組み合わせて、CI/CD パイプラインを Cloudflare プラットフォーム上にネイティブで構築できるようになったことが発表されたよ。

Artifacts はバージョン管理されたコードの保存先、Workflows はステップごとに独立して実行・リトライできるパイプラインの実行基盤、そして CI SDK はその Workflows の中でインストール・リント・テスト・ビルド・デプロイといった CI の各ステップを組み立てるためのツールキットなの。しかも構成は YAML じゃなくて TypeScript で書けちゃうんだって！

## 今までどうだったの？

これまで CI/CD パイプラインを組もうとすると、GitHub Actions のような外部サービスを使うか、複雑な YAML 設定を自前で書き上げる必要があったの。特に、他社の顧客コードを預かって動かす「プラットフォーム企業」にとっては、何百万ものリポジトリぶんの CI/CD を統一的に管理するのが大きな悩みの種だったみたい。原文でも、多くのエンドカスタマーは余計な手間を増やしたくないもの、と課題感が語られていたよ。

## これで何が変わるの？

Workflows と Artifacts の組み合わせなら、コードの保存からビルド・テスト・デプロイまでを Cloudflare だけで完結できるようになるよ。ステップは TypeScript の関数として書けるから、YAML の複雑な条件分岐に悩まされなくて済むの。

さらに嬉しいのが「自己修復（Self-healing）CI」。ビルドやテストが失敗したとき、AI エージェントが自動で修正を試みてくれるから、開発者はノートパソコンを開いたまま結果を待ち続けなくてよくなるんだって。修正後は内容を確認してマージするだけで OK なの。

プラットフォーム企業にとっては、全顧客共通のパイプラインを回す「プラットフォーム管理型」と、顧客ごとにカスタムパイプラインを許可する「顧客カスタム型」を同じ namespace 内で共存させられるのも大きなポイントだよ。

## 深く潜ってみよう

### トリガーの仕組み

Workflow は `wrangler.toml` の `events` フィールドで、`cf.artifacts.repo.pushed` イベントをトリガーに指定できるよ。`namespace` と `repoName` でフィルタでき、`repoName` を省略すればその namespace 内の全リポジトリへの push が対象になるの。

### CI ステップの基本形

CI SDK を使うと、こんな感じで install → 並列チェック → deploy という 3 ステップのパイプラインが書けるよ。

```typescript
const deps = 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 }
});
```

install ステップの依存関係は R2 バケットにキャッシュされて、後続ステップで再利用されるよ。lint・test・typecheck・build は `Promise.all` で並列実行できるから、待ち時間を減らせるの。deploy はビルドが成功したときだけ実行されるよ。

### 自己修復 CI のアーキテクチャ

自己修復は Durable Object ベースの Healing Agent と Workers AI を組み合わせて実現しているよ。原文にあったサンプルでは、こんな風にモデルを指定していたの。

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

CI が失敗すると、`step.do('heal', ...)` の中で Healer エージェントを呼び出して、検証を弱めずに観測されたすべての失敗を直すよう指示するプロンプトで修正を試みる流れになっているよ。

### 必要なバインディング

CI パイプラインを動かすには、Worker 側にこれだけのバインディングが必要になるよ。

- `artifacts` バインディング（コード取得用）
- `workflows` バインディング（パイプライン実行用）
- `containers` と `durable_objects` バインディング（サンドボックス実行環境用）
- `r2` バインディング（依存関係キャッシュの保存用）

### Workflows ならではの強み

- Durable Execution により、失敗しても状態を保持したまま自動リトライできる
- 失敗した特定ステップだけから再実行できるので、無駄な再実行を避けられる
- Workflows ダッシュボードでステップごとの実行状況や並列/順序の様子を可視化できる
- Workers Observability や GraphQL API でログを詳しく追える
- `step.do()` の中に AI コードレビューや R2 へのビルド成果物保存、失敗時のメール送信など、好きなロジックを自由に組み込める

### 今後のロードマップ

原文では、今後の拡張予定として次のような項目が挙げられていたよ。

- push 時の自動デプロイや非デフォルトブランチでのプレビュー作成（`build.preview()` / `build.deploy()`）
- パーセンテージベースの段階的ロールアウトと、Workflows 経由でカスタマイズできるロールバック
- 単一の CI パイプラインで複数の Worker をまとめて扱える monorepo 対応
- Artifacts 以外の VCS からの push イベントにも対応するマルチソーストリガー

なお、Artifacts は現在プライベートベータで、専用フォームから申し込む形になっているよ。

## まとめ

- Workflows・Artifacts・CI SDK（`@cloudflare/ci`）を組み合わせて、CI/CD パイプラインを Cloudflare 上にネイティブで構築できるようになった
- パイプラインは YAML じゃなく TypeScript のステップ関数で書ける
- install → 並列チェック（lint/test/typecheck/build）→ deploy という基本形が用意されている
- Durable Object と Workers AI による自己修復 CI で、失敗したビルドを AI が自動修正してくれる
- プラットフォーム管理型・顧客カスタム型の CI を同じ namespace 内で共存させられる
- Artifacts は現在プライベートベータで申し込み制

何百万ものリポジトリを預かって動かすプラットフォーム企業や、外部 CI サービスを使わずに Cloudflare だけでデプロイまで完結させたい開発者にとって、特に刺さる発表だよ！