# Flagship bindings、ついに自動プロビジョニングに対応したよ！

やっほー、しぃちゃんだよ！今日は Cloudflare Workers を使ってるみんなに嬉しい、地味だけど便利な自動化のお知らせを見つけたよ！

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

Cloudflare の Changelog で発表されたのは、**Wrangler の自動リソースプロビジョニング機能が Flagship bindings に対応した**というお知らせだよ。

Flagship は Cloudflare のフィーチャーフラグサービスで、Workers から binding 経由で呼び出して使うものなの。これまで Wrangler の自動プロビジョニングは KV・R2・D1 の binding に対応していたんだけど、今回そこに Flagship が加わったんだ。

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

これまで Flagship binding を使うには、事前に `app_id` を用意して wrangler.jsonc や wrangler.toml に書いておく必要があったの。KV や R2 みたいに「バインディングを書くだけでリソースが用意される」体験からは、一歩遅れてる状態だったんだね。

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

これからは、`app_id` を書かずに Flagship binding を定義するだけで OK！デプロイ時に Wrangler が既存の Flagship アプリに接続するか、なければ新しく作成してくれるの。しかも、できあがった `app_id` は自動的に設定ファイルに書き戻されるから、次回からはその ID がちゃんと残るんだよ。

## 深く潜ってみよう

設定はとってもシンプルで、`binding` 名だけ指定すれば良いよ。

wrangler.jsonc の場合:

```jsonc
{
  "flagship": [
    {
      "binding": "FLAGS",
    },
  ],
}
```

wrangler.toml の場合:

```toml
[[flagship]]
binding = "FLAGS"
```

`app_id` を省略しているのがポイントだね。Wrangler がデプロイ時によしなに面倒を見てくれて、生成された ID を設定ファイルに書き込んでくれるよ。

Cloudflare の Changelog 本体には制限事項までは書かれていなかったけど、自動プロビジョニングはすでに KV・R2・D1 で実績のある仕組みだから、Flagship でも同じ考え方で「バインディングを書くだけでリソースが用意される」体験になったってことだね。

## まとめ

- Wrangler の自動リソースプロビジョニングが Flagship bindings にも対応したよ
- 今までは Flagship アプリを事前に作って `app_id` を手動で書く必要があった
- これからは `app_id` なしで binding を書くだけで、デプロイ時に自動接続・自動作成してくれる
- 生成された `app_id` は設定ファイルに自動で書き戻される
- KV・R2・D1 に続いて Flagship でも「書くだけで動く」体験になったよ

Flagship でフィーチャーフラグを使い始めたい人や、複数の Workers プロジェクトでバインディング管理を減らしたい人にうれしいアップデートだよ！