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

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

公開日

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

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

公開日
カテゴリー
Build
Pydantic AIとは?Python向けAIエージェントフレームワークの使い方

Pydantic AIとは?Python向けAIエージェントフレームワークの使い方

Pydantic AIは、型付きツールと検証済みの構造化出力を扱うPython向けAIエージェントフレームワークです。問い合わせ分類の実装例を通じて、依存性注入、モデルの切り替え、MCP、永続実行、評価の役割を解説。LangGraphやLangChain、APIの直接呼び出しとの使い分けも整理します。2026年10月17日Build
AIガードレールの設計と実装:チェック箇所・主要ツール・最小構成

AIガードレールの設計と実装:チェック箇所・主要ツール・最小構成

AIガードレールを、入力・取得データ・モデルの提案・ツール実行・出力の5つの境界で整理。返金リクエストを例に、コンテンツフィルターと権限確認、人による承認の違いを解説します。主要ツールの対応範囲と制約、小規模チームが始める6つの制御、Promptfooで確かめるテストケースまで、実装の判断に必要な要点をまとめます。2026年10月17日Build
ハルシネーションとは?LLMが誤る原因と誤回答を減らす実装

ハルシネーションとは?LLMが誤る原因と誤回答を減らす実装

LLMのハルシネーションは、架空の事実だけでなく、誤った数値や引用、ツール引数にも現れます。原因と実例を整理し、RAGによる根拠の取得、引用や値の検証、根拠が足りない場合の回答保留、Pythonの検証コード、評価テストまで解説。顧客への誤回答や誤操作を減らすために、小規模チームが取り組める実装手順を紹介します。2026年10月17日Build
システムプロンプトとは?役割・書き方・具体例と実用テンプレート

システムプロンプトとは?役割・書き方・具体例と実用テンプレート

システムプロンプトとは何か、ユーザープロンプトとどう使い分けるのかを解説します。Anthropic・OpenAI・Googleの指定方法や、役割・ルール・出力・ツール利用の書き方を整理。改善前後の例とコピーして使えるテンプレートに加え、権限制御の限界、会話を続ける際の注意点、運用で確認すべきケースも紹介します。2026年10月17日Build
function callingとは?LLMと外部ツールをつなぐ仕組みと実装

function callingとは?LLMと外部ツールをつなぐ仕組みと実装

function callingは、LLMの依頼をアプリケーションが検証・実行する仕組みです。注文状況の照会を題材に、ツール定義から結果の返却までをPythonで解説。OpenAI・Anthropic・Geminiの形式の違い、引数の検証とアクセス制御、構造化出力やMCPとの使い分けまで整理します。2026年10月17日Build
MCPとは?APIとの違いと、導入・併用を判断するポイント

MCPとは?APIとの違いと、導入・併用を判断するポイント

MCPとは何か、APIやREST APIとの違いを、チケット作成の例で解説します。ツールの検出、認証・認可、デプロイ、バージョン管理を比較し、ClaudeやChatGPTなどの接続要件も整理します。APIだけで十分な場合、MCPを追加する場合、併用する場合の判断基準と、権限や再試行のルールを共有する設計を紹介します。2026年10月17日Build
Hermes Agent レビュー:使い方・料金と業務導入の判断基準

Hermes Agent レビュー:使い方・料金と業務導入の判断基準

Hermes Agentは業務で使えるAIエージェントなのか。永続メモリ、再利用できるスキル、モデル選択、インストール方法、料金と運用上の制約を解説します。Claude CodeやCodexとの使い分け、権限管理、成果物あたりのコストを基に、導入する価値があるかを具体的に判断できます。2026年10月17日Build
Ollamaとllama.cppを比較:モデル管理・API・同時実行で選ぶ

Ollamaとllama.cppを比較:モデル管理・API・同時実行で選ぶ

Ollamaとllama.cppを、モデル管理、GGUFと量子化、API互換性、同時実行、GPU対応から比較します。手軽な運用か、推論サーバーの細かな制御か。開発用PCや社内サービスに合う選び方を、設定例と移行時の確認点を交えて解説します。Apple Siliconでの注意点やvLLMを検討する条件も整理します。2026年10月16日Build
ニュースレター

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

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