Cloudflare Workers 料金ガイド:Worker Previewsは無料か

Cloudflare Workers 料金を、Worker Previewsの無料枠、実行リクエスト、CPU、ビルド、ストレージ、Workers AI、Containers別に整理。100 Previewsと100 deploymentsの意味、Paidへ移る基準、5ブランチの試算を解説します。

Monday, September 28, 2026Omid Saffari
Cloudflare Workers 料金ガイド:Worker Previewsは無料か

Cloudflare Workers 料金を調べるとき、Worker Previewsは無料で使えるのでしょうか。答えは「はい」です。Workers Freeには、Workerごとに100件のPreviewと、Previewごとに100件のデプロイが含まれます。ただし、これでブランチテストが無制限になるわけではありません。動的実行、ビルド時間、ストレージ、AI推論、Containersには、それぞれ別の上限または料金があります。

Cloudflare Worker Previewsを使うと、同じWorkerの中でGitの各ブランチに本番環境に近い実行環境を用意できます。Cloudflare Workers 料金について、単に「$0」と答えるだけでは不十分です。Previewという環境オブジェクトはFreeで利用できますが、そのブランチが動かす各プラットフォーム製品の利用量は、これまでどおり予算に含める必要があります。

Cloudflare Worker Previewsは無料で使える?

はい、利用枠そのものは無料です。 Cloudflareが現在公開しているPreviewの上限では、FreeプランはWorkerごとに100件、Paidプランは500件のPreviewを利用でき、どちらのプランでも各Previewに100件のデプロイを保持できます。

ただし、この答えには明確な境界があります。Previewは環境オブジェクトであり、ランタイム、ストレージ、ビルド、モデル呼び出しを無料でまとめたパッケージではありません。Cloudflareの現行Workers料金ページによると、Freeアカウントの動的なWorkerリクエストは1日100,000件で、1回の呼び出しに使えるCPU時間は10ミリ秒です。Workers Paidは現在も1アカウントあたり月額$5からで、月間10 million件のリクエストと30 million CPUミリ秒を含み、それを超えると公開済みの超過料金が発生します。

現行のPreviewドキュメントと料金ドキュメントは、2026年9月28日に確認しました。どちらにもPreview固有の料金は掲載されていませんが、Previewでの実行が無制限になるとも、専用の利用枠が付くとも書かれていません。したがって、安全な予算の立て方は、Previewの利用枠は無料、各製品の既存メーターはそのままと考えることです。

2026年9月22日に何が変わったのか

Cloudflareは2026年9月22日にWorker Previewsをリリースし、各ブランチに専用の実行環境、固定のPreview URL、設定、オブザーバビリティ、状態を持たせられるようにしました。npx wrangler previewを実行すると、現在のブランチに対応するPreviewが作成または更新されます。

ビジネス上の意味は、根拠を得るまでのループが短くなることです。コーディングエージェントはブランチをデプロイし、リクエストを送り、ログとトレースを確認してコードを修正し、同じ共有可能なPreview URLを更新できます。しかも、本番へマージする前に一連の検証を完了できます。複数のエージェントやエンジニアが、1つの共有ステージングWorkerを順番待ちせず、並行して作業できるようになります。

各ブランチには、用途の異なる2種類のURLが用意されます。Preview URLは常に、そのブランチの最新デプロイを指します。一方、Deployment URLは特定のデプロイに固定されるため、レビューコメントやリグレッション比較を再現できます。

分離は実質的です。CloudflareはPreviewごとに専用のDurable Object名前空間とストレージを自動で用意します。独立したコンテナアプリとインスタンスをプロビジョニングすることも可能です。変数、シークレット、バインディングは本番と分けられ、ログとトレースもブランチ単位に限定されます。

これは従来のVersion URLより強力なワークフローですが、本番環境の完全な複製ではありません。一部のバインディングやトリガーは、現在も共有システムや本番システムに接続します。エージェントにどこまで権限を与えるかは、Preview URLの便利さではなく、この制約を基準に決めるべきです。

Worker Previewsの無料プランでできること

通常のブランチ運用なら、Freeプランでも十分な余裕があります。1つのWorkerに100件のPreview環境を置けて、各Previewは100件のデプロイを保持できます。Paidでは環境数が500件に増えますが、Previewごとのデプロイ履歴数は増えません。

プランWorkerごとのPreview数Previewごとのデプロイ数Workersランタイムの境界
Free100100100,000リクエスト/日、CPU 10ミリ秒/呼び出し
Paid500100$5/アカウント/月、月間10 millionリクエストと30 million CPUミリ秒を含む

これはそれぞれ別の指標です。1つのブランチを何度デプロイしても、使うPreview枠は1件のままで、デプロイ履歴だけが増えます。一方、複数のブランチでPreviewを1件ずつ動かせば、トラフィックがなくても複数のPreview枠を使います。

新旧のオブジェクト数を比べると違いがよく分かります。5つのブランチをWrangler環境で揃えるには、5つのWorkerを管理する必要がありました。Worker Previewsなら、同じ5つのブランチを1つのWorker配下の5つのPreviewオブジェクトとして扱えます。Freeの場合、アカウントの占有率は、100 Workerという上限の5%から、Worker上限の1%と、そのWorkerに割り当てられたPreview枠の5%へ変わります。使用量が枠内なら、どちらの構成でも公表されている基本料金は$0のままです。利点は実行コストの割引ではなく、分離が簡単になり、環境が乱立しにくくなることです。

Worker Previewsを使うには、Wrangler 4.135.0以降が必要です。重要なのはプロジェクトローカルのバージョンです。プロジェクトのコマンドが、古いローカル版を新しいグローバル版に黙って置き換えることはありません。古いリポジトリで「この機能は使えない」と誤診しやすいポイントです。

設定の境界にも注意が必要です。Previewは本番設定を継承しません。ブランチに適用されるのは、previewsブロックに宣言した内容と、Cloudflareが自動的に分離するリソースです。ブロックが空、または不完全だと、デプロイには成功しても、コードが必要とするリソースに接続できないPreviewができあがります。

Cloudflare Previewの上限:何から削除される?

Cloudflareは、どちらかのオブジェクト上限に達すると自動でクリーンアップします。Worker単位では、最後にデプロイされた時刻が最も古いPreviewが削除されます。1つのPreviewの中では、最も古いデプロイが削除されます。

つまり、同じPreviewへの101回目のデプロイは、履歴の保持に影響するイベントです。新しいデプロイを収めるため、最古のデプロイが消えます。最初の100回のビルドが無料だった、という意味ではありません。Workers Buildsでは、本番デプロイを作ったかPreviewデプロイを作ったかにかかわらず、ビルド時間が別に計測されます。

ブランチを頻繁に修正するエージェントにとって、常に最新デプロイを指す固定のPreview URLは引き続き便利です。リスクがあるのは、過去を調べるための履歴です。以前の障害を再現する必要があるチームは、そのデプロイが最古の項目になる前に、該当するDeployment URLとログを保存しておくべきです。

オブジェクトの自動削除だけでは、リソースのクリーンアップ方針として不十分です。Previewを削除すると、そのPreviewレコードとDurable Object名前空間は削除されますが、自動生成されたコンテナアプリが表示されたまま残る場合があるとCloudflareは警告しています。Containersを使った場合、ブランチ終了時のジョブはPreviewを削除したあと、Containerアプリケーションも確認する必要があります。

Cloudflare Workers 料金を決める4つの層

Cloudflare Worker Previewsには、Preview単位の料金項目が公表されていません。実際の請求は引き続き、Workerの実行、ビルド、バインドしたリソース、追加のコンピューティングまたはモデル製品という4つの層で考えます。

1. Workerの実行

Workers Freeでは、1アカウントあたり1日100,000件のリクエストが許可され、1回の呼び出しに使えるCPU時間は10ミリ秒です。静的アセットへのリクエストは無料かつ無制限で、リクエスト枠を消費するのはWorkerコードに到達するものです。そのため、静的ファイルを読み込むだけのブランチテストは安く見えても、APIを多用するテストは動的リクエスト枠を消費します。

Workers Paidは1アカウントあたり月額$5からです。月間10 million件のリクエストと30 million CPUミリ秒を含み、超過分はリクエスト1 million件ごとに$0.30、CPU 1 millionミリ秒ごとに$0.02です。PaidではHTTP呼び出しのCPU上限がデフォルト30秒で、最大5分まで設定できます。

Freeの10ミリ秒という上限は、最初の壁になりがちです。リクエスト数を減らしても、この制約は解消しません。送信するリクエストが数件だけのテストスイートでも、1回の動的呼び出しに毎回10ミリ秒を超えるCPU時間が必要なら失敗します。

プラットフォーム全体を判断する際は、Cloudflareレビューで、月額$5のWorkersアカウントプランと、ドメイン単位のCloudflareアプリケーションプラン、その他の製品メーターを分けて解説しています。

2. Workers Builds

Workers Buildsの上限と料金では、Freeアカウントに月3,000分のビルド時間、同時ビルド1件、タイムアウト20分が提供されます。Paidには6,000分が含まれ、超過分は1分あたり$0.005です。同時ビルドは6件に増え、タイムアウトは同じです。エージェントが生成するブランチが増えると、Previewオブジェクト数に余裕があっても、同時実行数やビルド時間の上限に達する可能性があります。

したがって、「Previewごとに100件のデプロイ」を「ビルド100回分が含まれる」と読み替えてはいけません。前者は保持されるデプロイ履歴で、後者はCIのコンピューティング使用量です。

3. ストレージとバインドしたリソース

KV、D1、R2、Queues、Vectorize、Hyperdriveなどのバインディングには、それぞれ固有のリソースIDと利用メーターがあります。2つのPreviewが同じD1データベースやR2バケットにバインドされていれば、データも共有します。分離するには別のリソースが必要で、そのリソースには該当製品の料金体系がそのまま適用されます。

規模感を示すと、R2には月10 GB-monthのストレージ、1 million件のClass Aオペレーション、10 million件のClass Bオペレーションが含まれます。それを超えるStandardストレージは1 GB-monthあたり$0.015、Class Aは1 million件あたり$4.50、Class Bは1 million件あたり$0.36です。D1 Freeには、1日あたり5 million行の読み取りと100,000行の書き込み、合計5 GBのストレージが含まれます。D1のFree上限に関する分析では、Previewオブジェクトに空きがあっても、共有ステージングデータベースが可用性の境界になり得る理由を解説しています。

KVには、さらに別の日次枠があります。Freeでは読み取り100,000件、書き込み1,000件、削除1,000件、リスト要求1,000件で、保存容量は1 GBです。名前空間へデータを投入したり、消去したりするテストは、読み取り専用のスモークテストよりもはるかに早くこの枠を消費します。

4. AI推論とContainers

Workers AI 料金では、FreeとPaidの両方に、1日10,000 Neuronsが無料で付与されます。Paidでは、その枠を超えた使用量に対し、1,000 Neuronsあたり$0.011がかかります。モデルを呼び出すブランチテストでは、Workerへのリクエストと、そこから発生する推論という2つの処理に予算を割く必要があります。外部のコーディングエージェントのサブスクリプションやモデルAPIは別ベンダーの請求であり、Previewの利用枠には含まれません。

Container料金には、Free向けのContainer利用枠は記載されていません。Workers Paidには月25 GiB-hoursのメモリ、375 vCPU-minutes、200 GB-hoursのディスクが含まれ、超過料金はそれぞれ別です。ContainerのトラフィックではWorkersとDurable Objectsも使うため、自動的に分離されたPreview用Containerであっても、単一メーターの製品ではありません。

5つのアクティブブランチでかかるWorker Previewのコスト

分かりやすい試算表は、プラン名ではなくワークロードから作ります。5つのアクティブブランチがあり、それぞれ1日200件の動的なテストリクエストを受けると仮定します。5つのPreviewオブジェクト全体では、1日1,000件です。

予算項目計算試算結果
Previewオブジェクト5ブランチ × 1 PreviewFreeの100枠中5件、つまり5%
動的なPreviewリクエスト/日5 × 2001,000
Freeの日次リクエスト枠に占める割合1,000 ÷ 100,0001%
他のトラフィックを除いたFreeの残り枠(試算)100,000 - 1,00099,000/日
30日間のPreviewトラフィック1,000 × 3030,000リクエスト
Paidの付属リクエスト枠に占める割合30,000 ÷ 10,000,0000.3%

FreeではPreview数に余裕があり、この試算上のトラフィックも小さい水準です。ただし、アカウントに1日99,000件の動的リクエスト枠が残るのは、ほかに枠を使うものが何もない場合に限ります。本番トラフィック、ほかのWorker、5つのブランチ環境をすべて運用試算に入れる必要があります。

ここでは、根拠の性質を明記しておく必要があります。Cloudflareは1日100,000件のリクエストをアカウントプランの上限と呼んでおり、PreviewではWorkerの実際のバージョンが稼働します。一方、Previewのトラフィックが同じメーターから差し引かれるとは、Previewのドキュメントに明記されていません。そのため、アカウントの利用状況を実測するか、Cloudflareが明言するまでは、Previewのリクエストにもアカウント共通メーターを当てはめるのが保守的な予算仮定です。

今回の検証では、Cloudflareアカウントの認証情報、Workerプロジェクト、プロジェクトローカルのWranglerを利用できませんでした。使い捨てのPreviewはデプロイしておらず、使用量の変化も測定していません。利用枠についての答えは情報源で検証済みですが、この試算表はモデルです。

5つのブランチPreviewが試算上のアカウント共通メーターへ流れ、Builds、ストレージ、AI利用は別のゲートを通るアーキテクチャコストモデル
共通のWorkerメーターを試算し、接続する製品の料金を個別に計算します

Paidでは、このブランチワークロードだけでリクエスト超過料金は発生しませんが、アカウントには月額$5の最低料金がかかります。CPUと接続した製品によっては、結論が変わります。同じテスト密度でFreeの100 Preview枠をすべて使うと、1日20,000件となり、試算上の日次枠の20%です。Paidの500枠をすべて使うと、30日間で3 million件となり、月間付属リクエストの30%です。どちらの単純化した例でも、リクエスト枠より先にPreviewオブジェクトの上限へ達します。本番トラフィックを加えると、この順序は逆転する可能性があります。

開発者・運用担当・購入判断者への影響

開発者が得るのは並列の実環境検証であり、自動的なリソース安全性ではない

開発者は、アクティブな各ブランチに固定URLと、分離されたDurable Objectの状態を用意できます。これにより、1人のエンジニアによるデプロイで別のエンジニアのレビュー環境が無効になる、共有ステージング上の衝突をなくせます。コーディングエージェントも、curl、ブラウザチェック、ログ、トレースを実行する具体的な対象を得られます。

壁になるのは設定です。コードが分離されても、D1、KV、R2が自動で分離されるわけではありません。2つのPreviewが同じIDを使えば、リソースも共有します。安全なデフォルトは、専用の非本番リソース、または破棄可能なデータだけを置く、意図的に共有したステージングリソースです。

運用担当は共通予算とクリーンアップ経路を管理する

運用担当は、アクティブなPreviewオブジェクト数、Previewごとの保持デプロイ数、動的なWorker使用量、接続製品の使用量という4つの数字を分けて追跡するべきです。1つのダッシュボード合計値だけでは、この4項目すべてを説明できません。

クリーンアップ処理は、プルリクエストの自動化に組み込みます。ブランチを閉じたらPreviewを削除します。Containersを使った場合は、自動生成されたコンテナアプリケーションが残っていないか確認します。インシデント調査に必要なDeployment URLやトレースは、履歴から削除される前に保存します。

購入判断では、超える境界を明確にする

「Preview」という言葉が有料機能らしく聞こえるから、という理由でPaidを購入してはいけません。1つのWorkerで同時に100件を超えるPreviewが必要、動的トラフィックと本番トラフィックの合計が1日100,000リクエストに近づく、1回の呼び出しに10ミリ秒を超えるCPU時間が必要、またはContainerが1つでも必要という、Freeの具体的な境界を超えたときに購入します。

実際の量がまだ上限に達していなくても、リスクへの対応としてPaidを選ぶのが合理的な場合もあります。顧客向けサービスのチームなら、5つのブランチテストが試算上の日次枠の1%しか使わなくても、Freeの日次上限より、月間利用枠と超過請求がある方を選ぶ可能性があります。

今から変えるべきこと

複数のエンジニアやエージェントが、変更可能な1つのステージングWorkerを順番に使っているなら、今すぐ対応する価値があります。ブランチ検証をPreviewsへ移し、非本番リソースの方針を定め、ブランチ終了時のクリーンアップをCIに組み込んでください。このリリースは、調整作業のボトルネックを直接解消します。

アプリケーションが複数Worker間のサービスバインディング、Queueコンシューマー、Cron Triggers、本番ルート、自動分離されたWorkflowsに依存するなら、待つべきです。現時点では、これらの経路はPreviewの中だけで完結しません。HTTP向けの部分はPreviewでもテストできますが、システム全体の分離を証明することはできません。

プロジェクトがすでに別の仕組みでブランチごとの固定環境を使っている場合や、Workerが静的で、変更をローカルテストとデプロイバージョンの確認だけで十分にカバーできている場合は、影響はほとんどありません。新しいオブジェクトは、存在するだけでは価値を生みません。

100 Previews、10ミリ秒、1日100,000リクエストを確認してFreeかPaidかを選ぶアーキテクチャ判断フロー
オブジェクト、CPU、リクエスト、Containerのいずれかの境界を超えると、選ぶプランが変わります

判断基準は明快です。オブジェクト数、呼び出しごとのCPU、試算上のアカウントトラフィック、必要な製品のすべてが枠内ならFreeを維持します。どれか1つでも運用上重要な境界を超えたらPaidへ移ります。リクエスト数だけが分岐点ではありません。

過大評価されている点

今回のリリースの説明は、分離されたブランチ用Workerとして捉えるなら的確です。しかし、Cloudflareアプリケーション全体の分離コピーだと受け取るのは行き過ぎです。

  • Previewからサービスバインディングを使うと、接続先Workerの本番デプロイが呼び出されます。複数Workerを通るリクエスト経路が、ブランチ同士で自動的に対応するわけではありません。
  • Workflowバインディングは、すでにデプロイされているWorkflowを使います。Cloudflareがブランチ専用のWorkflowを作ることはありません。
  • PreviewからQueueへメッセージを送ることはできますが、PreviewをQueueコンシューマーにはできません。本番Queueへ接続すると、そのテストメッセージを本番側が処理する可能性があります。
  • Cron Triggersと本番ルートの接続先は、引き続き本番です。
  • KV、D1、R2など複数のリソースが分離されるのは、別のリソースIDをバインドした場合だけです。
  • Preview URLはデフォルトで公開されます。workers.dev形式にはX-Robots-Tag: noindexが付与されますが、未公開の作業内容を非公開にする必要がある場合、カスタムドメインのPreviewはCloudflare Accessで保護するべきです。
  • Container対応は限定的で、Previewを削除しても、自動生成されたアプリが別途クリーンアップされるまで表示されたまま残る場合があります。

エージェントにとって、これは例外的なケースではありません。「エージェントが自分のブランチをテストできる」と「エージェントが本番に触れられない」の違いです。現在のリソース分離マトリクスは、任意のセットアップ資料ではなく、権限を決める文書として扱うべきです。

金銭面にも、もう1つ誇張されやすい点があります。Freeで100件のPreviewを使えるからといって、完全なステージング環境100個をすべて無料で使えるわけではありません。Cloudflareが1つのWorkerにその数のPreviewオブジェクトを置くことを許可している、という意味です。予算を決めるのは、その背後にあるリソースです。

利用枠を確認したらセットアップガイドへ

利用枠の確認に必要なのは、次の4つの質問だけです。

  1. アカウントはWorkers FreeとPaidのどちらですか?
  2. このWorkerですでにアクティブなPreviewはいくつありますか?
  3. 本番とほかのWorkerは、アカウントのリクエスト枠とCPU予算をどれだけ使っていますか?
  4. プロジェクトで固定しているWranglerは4.135.0以降ですか?

すべて枠内なら、設定とデプロイにはCloudflareのWorker Previews公式セットアップガイドを使ってください。コストの確認は分けて行い、エージェントがブランチを作り始める前に、バインドする全リソース、ビルド経路、モデル呼び出し、Containerを一覧にします。

Cloudflare Worker Previewsのよくある質問

Cloudflare Workersは無料で使えますか?

はい。Workers Freeは$0で、1日100,000件の動的なWorkerリクエストが含まれ、Workerごとに最大100件のPreviewを利用できます。ただし、1回の呼び出しには10ミリ秒のCPU上限があり、接続する製品にはそれぞれ別の利用枠があります。

Cloudflare Workerの料金はいくらですか?

Workers Freeは$0です。Workers Paidは1アカウントあたり月額$5からで、月間10 million件のリクエストと30 million CPUミリ秒を含み、その後は公開済みの超過料金がかかります。Previewには、別途公表された基本料金はありません。

無料でCloudflare Workerをいくつ使えますか?

Workers Freeでは、1アカウントにつき100件のWorkerを利用できます。これはWorker Previewsの上限とは別で、Freeでは各Workerの配下に100件のPreviewを置けます。

Cloudflare Workers AI 料金はいくらですか?

Workers AIには、1日10,000 Neuronsの無料枠があります。Workers Paidでは、この日次枠を超えた使用量に対して、1,000 Neuronsあたり$0.011がかかります。

Cloudflare Workers AIは無料ですか?

Workers AIには、Workers FreeとWorkers Paidの両方で1日10,000 Neuronsの無料枠があります。Freeアカウントは上限で停止し、Paidアカウントは超過分を1,000 Neuronsあたり$0.011で継続利用できます。

Cloudflareの最大の競合はどこですか?

Cloudflareのネットワーク、セキュリティ、コンピューティング、ストレージ、開発者向け製品のすべてに共通する競合は1社に絞れません。会社全体を1つの製品として捉えず、置き換えたいレイヤーごとに比較してください。

Cloudflareが下落しているのはなぜですか?

この質問は曖昧で、答えが時間とともに変わります。株価、サービス状況、トラフィック、あるいは別の指標を指す可能性があります。どの意味であっても、2026年9月28日にCloudflareの現行ドキュメントで確認したWorker Previewsの上限は変わりません。

Cloudflareはロシア企業ですか?

いいえ。Cloudflareの会社概要には、本社がSan Franciscoにあり、Cloudflare, Inc.はNETの銘柄コードでNew York Stock Exchangeに上場していると記載されています。

FBIはなぜCloudflareを使うのですか?

この記事はFBIがCloudflareを利用していることを立証しておらず、同機関のベンダー構成について何も主張していません。この質問は、文書で確認できるWorker Previewsの利用枠や使用上限とは無関係です。

月曜日にまずやること

まず5つのブランチを用意し、各ブランチの動的なテストリクエストを1日200件に制限します。その結果となる1日1,000件のリクエストを、予算上はアカウント共通メーターを使うという仮定として明記します。請求情報へアクセスできるようになったら、試行の前後でアカウントのリクエスト使用量を記録してください。差分がモデルと一致すれば試算表を使い続け、一致しなければ仮定を実測値に置き換えます。

同時に、previewsブロック内の全バインディングを棚卸しします。それぞれを自動分離、専用テストリソース、意図的に共有、本番に接続のいずれかに分類してください。本番に接続する項目すべてに明確な理由が記載されるまで、エージェントにデプロイさせてはいけません。

次のインフラリリースも、予算と運用判断に落とし込みませんか? ニュースレターに登録。

最終更新
2026年9月28日
カテゴリー
Build

Googleでこのサイトを優先する

omidsaffari.comをGoogle検索の優先ソースに追加

omidsaffari.comを優先ソースに設定すると、GoogleがTop Stories・AI Overviews・AI Modeであなたのために優先表示します。

経理 AIツール7選:会計事務所の業務別おすすめを徹底比較

経理 AIツール7選:会計事務所の業務別おすすめを徹底比較

経理 AIツールを会計事務所の業務別に比較。証憑処理のDext、帳簿レビューのXenett、エージェント型記帳のTruewindなど7製品を、料金、連携、レビュー手順、障害時の責任まで検証します。3人・10顧客法人の想定と30件のテスト手順を使い、承認済み成果物1件あたりの総コストで選ぶ方法を解説します。2026年9月28日Build
Claude Code アカウント切り替え完全ガイド:Janusの使い方

Claude Code アカウント切り替え完全ガイド:Janusの使い方

Claude Code アカウント切り替えをJanusで安全に行う手順を解説。Macへの導入、2つのアカウントの保存、切り替え後の再起動、メールアドレスと/usageによる確認、使用量表示の鮮度、認証情報を扱う際の注意点まで、実務で使い始める前に確認すべきポイントを順に整理します。2026年9月28日Build
Copilot CLIで始めるCopilot Managed Runtime:社内アプリ開発ガイド

Copilot CLIで始めるCopilot Managed Runtime:社内アプリ開発ガイド

Copilot CLIでCopilot Managed Runtimeを使い、社内業務アプリをローカル開発からGit、ホステッドプレビュー、本番デプロイへ進める手順を解説。必要なテナント設定、ライセンス、コネクタポリシー、ビルドの挙動、導入コスト、適したユースケースをパブリックプレビュー時点の制約とともに整理します。2026年9月27日Build
GPT-6のprompt cachingを安定させる設計と診断

GPT-6のprompt cachingを安定させる設計と診断

GPT-6のprompt cachingを実運用で効かせるために、安定したプレフィックス設計、キャッシュヒットの診断、明示的ブレークポイントの使い分けを解説します。GPT-6 Solの実測値から、ツール変更でコストが跳ねる理由、設定更新でキャッシュを維持する方法、CIで回帰を検知する手順まで整理します。2026年9月27日Build
Copilot Studio 料金でわかるManaged Runtimeの費用構造

Copilot Studio 料金でわかるManaged Runtimeの費用構造

Copilot Studio 料金を起点に、Copilot Managed Runtimeの構築、起動、API呼び出し、ホスティング、AIサービス、ライセンスを分けて試算します。Power Apps Premium、従量課金、容量パック、P3の損益分岐点と、公開資料だけでは確定できない費用まで整理しました。2026年9月26日Build
n8n AIエージェントはワークフローと何が違う?実測で選び方を検証

n8n AIエージェントはワークフローと何が違う?実測で選び方を検証

n8n AIエージェントと従来のワークフローを、同じサポート業務で実測比較。30回の実行、20件の完了、モデル呼び出し数、料金、セッション、承認機能を検証し、会話に判断を任せる場面と固定手順を残す場面、移行前に知るべきPreviewの制約、本番での安全な設計までわかりやすく整理します。2026年9月26日Build
OpenRouter 料金を検証:Jev Routerは本当に無料なのか

OpenRouter 料金を検証:Jev Routerは本当に無料なのか

OpenRouter 料金ページでJev Routerは$0と表示されていますが、選択モデルの推論まで含むセッション総額が無料とは限りません。usage.cost、生成ログ、Activityの照合方法と、$1以内の4リクエストで実コストを安全に確かめる手順を、公開情報と具体的な計算例から整理します。2026年9月26日Build
Claude プラグイン公開の実務ガイド:申請・審査・運用まで

Claude プラグイン公開の実務ガイド:申請・審査・運用まで

Claude プラグインをGitHubから公開ディレクトリへ登録する流れを実務目線で解説。申請主体の決め方、plugin.jsonとREADMEの準備、ローカル検証、ポータル審査、MCPコネクタの別申請、公開後のアップデートと利用分析まで、つまずきやすい要点を順にわかりやすく整理します。2026年9月26日Build
ニュースレター

毎週日曜、一通の手紙。動くシステムの話。感想戦ではなく。

週刊。スパムなし。いつでも解除できます。