Nitricとは？対応クラウド・導入手順とv1.28の変更点、CDKTF終了の影響

Nitric（ナイトリック）は、アプリケーションコードの中で宣言したリソースからクラウドのインフラ構成とIAMポリシーを生成する、オープンソースのフレームワークです。bucket('assets') のようにバケットやAPI、キューを宣言しておくと、デプロイ時にNitricがその宣言を集め、選んだプロバイダー経由でAWS・Microsoft Azure・Google Cloudの実サービスへ割り当てます。英単語の nitric は「窒素を含む」「硝酸の」という意味の形容詞で、硝酸（nitric acid）や一酸化窒素（nitric oxide）といった語で目にすることが多いですが、本記事が扱うのは nitrictech/nitric のクラウド開発フレームワークです。内容は2026年11月1日時点の公式ドキュメントのソース（mdx）と、GitHub・npm・PyPIの実データで確認しています（リポジトリ由来の日付はUTC）。

まとめ

• Nitricは「Infrastructure from Code」型のフレームワーク。IaCを置き換えるのではなく、コード上の宣言をPulumiまたはTerraformのIaCへ変換する層として動く。
• SDKはNode.js・Python・GoがFull Support、DartがExperimental、C#とJVMはv0 Support（公式ドキュメントの表記）。
• 対応クラウドはAWS・Azure・Google Cloud。ただしWebSocketsはAWSにしか実装がなく、AzureのBatchは「Coming soon」のまま。
• デプロイの実行系はPulumi版とTerraform版の2系統。Terraform版の土台であるCDKTFは2025年12月10日にアーカイブされ、公式docsもPreview扱い。本番はPulumi版を選ぶ。
• 本体は2026年10月16〜17日にv1.27.7〜v1.28.4の8リリースを出した。中身はAWS向けの修正と、大きなスタック向けの resource-resolver: tagging の追加。一方でCLIとSDKは2025年から新版が出ていない。

Nitricの仕組み：リソース宣言からのインフラ・IAM生成

IaCツールとの役割分担

公式ドキュメントの「Why Nitric」は、TerraformやCloudFormation、Pulumiを「システム側から見たアプローチ（system out）」と呼んでいます。クラウドが何を提供し、各リソースにどんな設定項目があるかを起点に構成を書く方式です。Nitricは逆の「開発者側から見たアプローチ（developer in）」を掲げ、アプリケーションが必要とする振る舞いからIaCを導きます。

両者は排他ではありません。Nitricが呼び出すのはプラグイン（Provider）で、Pulumiでデプロイまで実行するタイプと、Terraformコードを生成して実行は利用者に任せるタイプがあります。どちらも既存のIaCの上に載るレイヤーなので、Pulumiとは？読み方・Terraformとの違い・料金と使い方をCLI 3.273で解説で扱っているIaCツールの知識はそのまま使えます。

コード内でのリソース宣言とアクセス権指定

import { api, bucket } from '@nitric/sdk'

// 読み書き削除の権限つきでバケットを宣言
const assets = bucket('assets').allow('read', 'write', 'delete')

const main = api('main')

main.get('/hello/:name', async (ctx) => {
  const { name } = ctx.req.params
  ctx.res.body = `Hello ${name}`
  return ctx
})

インフラ専用の設定ファイルはなく、リソースと権限はSDKの bucket()・api()・.allow() でコードの中に宣言します。Nitricはこの宣言から、「assetsという名前のバケットが要る」「このサービスはそのバケットをread・write・deleteする」「mainというAPIのGETルートがこの関数を呼ぶ」という3つの要求を読み取ります。任意の業務コードを解析して必要なインフラを推測するわけではありません。デプロイ時にはこの要求がProviderへ渡り、AWSならS3バケット、API Gateway、Lambda関数と、それらを結ぶIAMポリシーに展開されます。nitric.yaml に match: services/*.ts のようなパターンを書くと、一致したファイルがそれぞれ独立したコンテナとして扱われます。

対応言語とSDKごとの成熟度

公式リファレンスの言語一覧（reference/languages.mdx）は、言語ごとにサポートの段階を明記しています。どの言語でも同じように使えるわけではないので、採用を検討するときに最初に見る表です。最新版は各パッケージレジストリ、最終pushはGitHub APIの pushed_at を2026年11月1日に取得した値です。

SDKとNitricのランタイムはgRPCとProtocol Buffersで通信するため、理屈の上ではほかの言語も追加できます。ただし表のとおり実装の進み具合には大きな差があり、C#とJVMのリファレンスはv0系しかありません。Pythonはリポジトリへのpushが2025年9月まで続いた一方、PyPIの nitric パッケージは2024年12月4日の1.2.4が最新です。pipで入る版とmainブランチの中身がずれている可能性があるので、Pythonで使うならリリースノートと差分を確かめてから版を固定してください。JavaやKotlinの本番案件でNitricを前提にするのは勧めません。

対応クラウドと割り当てられるマネージドサービス

Nitricのリソースがどのマネージドサービスに変換されるかは、公式docsのProvider一覧に表があります。PulumiとTerraformのどちらのProviderでも、既定で使うサービスは同じです。

「CLI内蔵」はdocsで Custom と書かれている箇所で、Nitric CLIに同梱された実装（APIゲートウェイなら gateway.go）が担当します。「コードを変えずにクラウドを乗り換えられる」という説明は、この表が埋まっている範囲でしか成り立ちません。WebSocketsはAWSにしか実装がなく、AzureとGoogle Cloudでは同じコードが動きません。AzureはBatchも未提供です。マルチクラウドを前提に設計するなら、使う予定のリソースが3クラウド分そろっているかを最初に確かめてください。Nitricが対応していないサービスは、各クラウドのSDKをアプリケーションコードから直接呼べます（その部分だけクラウドへの依存が残ります）。

デプロイ実行系の選択：Pulumi版とTerraform版

2系統のプロバイダーとスタックファイル

デプロイ先はスタックファイル（nitric.[スタックID].yaml）で指定します。公式ドキュメントの例では、プラグイン名とバージョンを次のように書きます。

# Pulumi版（AWS）の例。Terraform版にするときは provider を nitric/[email protected] に書き換える
provider: nitric/[email protected]
region: us-east-1

1つのスタックファイルに書くProviderは1つだけです。docsのバージョン表記はページごとに 1.1.1 や @latest と揺れています。実際にはリリース済みの最新版（2026年10月17日公開のv1.28.4）を明示するか @latest を指定します。チームで使うなら、版を固定して更新は意図して行うほうが安全です。

Pulumi版では、NitricがPulumi Automation API経由でデプロイまで実行します。Pulumi Cloudの利用は任意で、ステートの保存先として使いたいときだけ pulumi login します。Terraform版は「IaCを生成するProvider」で、nitric up を実行すると cdktf.out ディレクトリにTerraformコードが出力され、そこから terraform init、plan、apply を自分で実行します。生成物をリポジトリで管理するなら、Terraformコーディング規約とterraform fmtの使い方｜公式スタイルガイド準拠の命名・コメント・CI強制の命名やディレクトリ構成のルールと合わせて方針を決めておくと、運用が崩れにくくなります。

Terraform版採用時のCDKTF終了リスク

NitricのTerraform Providerは、CDK for Terraform（CDKTF）で作られています。そのCDKTFは、HashiCorp（IBM傘下）が2025年12月10日に提供を終え、GitHubリポジトリをアーカイブしました。READMEには、その日以降は保守も開発も行わず、互換性の対応を含めて修正や改善は行わないと書かれています。ライセンスはMPLのままなので使い続けることはできますが、上流の更新は止まっています。CDKTFそのものの移行先の選び方はCDK for Terraform（CDKTF）とは？提供終了後の移行判断を解説にまとめています。

Nitric公式ドキュメントも、Terraform Providerを3クラウドともPreview扱いにしており、本番に適用する前に生成されたTerraformをレビューするか、Pulumi版を使うよう勧めています。CDKTFがNode.jsに依存するため、Terraform版ではTerraform CLIに加えてNode.jsも必要です。本番運用の既定はPulumi版にしてください。Terraform版を選ぶなら、生成された cdktf.out を成果物としてレビュー・保存しておきます。HashiCorpが案内する cdktf synth --hcl は元のCDKTFプロジェクト（ソースコード）からHCLを出力するコマンドで、Nitricの出力物だけから実行できるものではありません。将来CDKTFの層を外す場合は、生成済みのTerraformを引き継ぐ前提で手順を検証してください。なお2026年10月のv1.28.1でもTerraform版のAWS Provider（awstf）に修正が入っており、Nitric側の保守はまだ続いています。

インストールからデプロイまでの手順

CLIのインストールとプロジェクト作成

# macOS
brew install nitrictech/tap/nitric

# Windows
scoop bucket add nitric https://github.com/nitrictech/scoop-bucket.git
scoop install nitric

# Linux
curl -L "https://nitric.io/install?version=latest" | bash

# テンプレートからプロジェクトを作成（ts, js, py, go, dart のスターターを選択）
nitric new hello-world ts-starter
cd hello-world
npm install   # Pythonのスターターなら uv sync

共通の前提ツールはGit、Docker、Docker Buildxです。これに加えて、選んだ言語の実行環境（TypeScriptならNode.js、Pythonならuv）が必要で、Pulumi版のProviderでデプロイするにはPulumi CLIも必須です。Linuxでは、root以外のユーザーでDockerを実行できるようDockerのpost-installation手順まで済ませておく必要があります。生成されるプロジェクトは services/ と nitric.yaml が中心で、Pythonのテンプレートは依存管理に既定で uv を使います（pipenv版のテンプレートも別にあります）。

ローカル実行とエミュレーションの中身

nitric start はコードをコンテナ化せずに起動し、APIやWebSocketのゲートウェイ、スケジュール実行、バケットやキーバリューストアのランタイムAPIをローカルでエミュレートします。中身は前の表のとおり、ストレージがSeaweedFS、キーバリューがBoltDB、SQLがDockerコンテナで、マネージドサービスそのものではありません。レイテンシやサービス固有の制限はローカルでは再現されないと考えてください。コンテナで動かしたいときは nitric run を使いますが、公式ドキュメントによれば、WindowsやmacOSでは仮想マシンを経由するぶん起動が遅くなることがあります。

起動するとローカルダッシュボードのURLが表示され、構成図の自動表示、API呼び出し用のHTTPクライアント、バッチジョブの投入、SQLの実行とマイグレーション、スケジュールの手動実行、トピックへのメッセージ発行をブラウザから行えます。HTTPSで確かめたいときは nitric start --https-preview で自己署名証明書を使えますが、公式ドキュメントでは実験的機能とされています。

スタック作成とデプロイ

nitric stack new   # プロバイダーを選んでスタックファイルを作成
nitric up          # ビルドしてデプロイ（Terraform版はIaCを生成するところまで）
nitric down        # 環境を削除。Pulumi版など直接デプロイするProviderのみ

クラウド側の認証情報は各Providerの前提に従います。docsにあるとおり nitric down は直接デプロイするProviderでしか使えず、Terraform版では terraform destroy など自分のIaCツール側で破棄します。Pulumi版なら nitric up が差分を検出して更新するので、2回目以降も同じコマンドで反映できます。

AWSでのリソース検出方式（v1.28.0のresource-resolver）

AWS Providerでリソースが増えてきたら、v1.28.0（2026年10月17日）で入ったスタック設定 resource-resolver を確認してください。リソースの多いスタックで、デプロイ後に実行時エラーを避けるための設定です。

AWSにデプロイしたLambda関数は、実行時に同じスタックのバケットやトピック、シークレットのARNを知る必要があります。Pulumi版のAWS Providerは、これらの対応表をJSONにまとめてSSM Parameter Storeの /nitric/<スタックID>/resource-index に保存し、ランタイムがそれを読みます。ところがSSMのパラメータ値には、Standard階層で4KB、Advanced階層で8KBの上限があります。機能を追加したプルリクエスト#913には、トピック22・シークレット14・バケット7・キーバリューストア6のスタックで索引が約9KBになり、上限を超えた例が載っています。

# nitric.aws.yaml（スタックファイル）
provider: nitric/[email protected]
region: us-east-2
# 既定は ssm。tagging にするとSSMの索引を作らない
resource-resolver: tagging

tagging にすると、ProviderはSSMの索引を作らず、Lambdaに環境変数 NITRIC_AWS_RESOURCE_RESOLVER=tagging を渡します。ランタイムはAWS Resource Groups Tagging APIで、デプロイ時に付けた x-nitric-<スタックID>-name などのタグからリソースを探します。プルリクエストの説明によれば、必要な tag:GetResources の権限はもともとLambdaとBatchのロールに付与されており、Google CloudとAzureのProviderは最初からタグ（ラベル）で探す方式です。設定キーはPulumi版（aws）とTerraform版（awstf）の両方のドキュメントに載っています。

判断の目安は単純です。v1.27.9以降はSSMの階層が自動で上がるので、8KBに収まる規模なら既定のssmのままで動きます。トピックやシークレットが数十個に増え、索引が8KBに近づくスタックでは、最初からtaggingにしておくほうが安全です。既存のスタックで切り替えるときは、本番の前に検証用スタックで nitric up を実行し、全リソースに呼び出せることを確かめてください。

IAMポリシーの自動生成という実利

NitricはIAMポリシーも宣言から生成します。公式ドキュメントは権限を「暗黙（Implied Access）」と「明示（Requested Access）」に分けています。暗黙の権限は、APIルートのハンドラやトピックのサブスクライバーのように、つないだ時点で必要になる呼び出し許可です。AWSでSNSからLambdaを起動するには、サブスクリプションごとに lambda:InvokeFunction を許可するリソースベースポリシーが必要ですが、topic.subscribe() と書けばNitricが生成します。

バケットやキューへのアクセスのように用途が自明でないものは、既定では権限なしとして扱われます。前のコード例のように .allow('read', 'write', 'delete') と書いた範囲だけが、デプロイ先のクラウドに合わせたポリシーに変換されます。トピックとサブスクリプションは作ったのに権限だけ抜けていてイベントが届かない、というよくある事故をコードの構造で防げます。

Encoreとの違い（Infrastructure from Codeの他の選択肢）

コードからインフラを導く考え方はNitricだけのものではありません。OSSのディレクトリサイトopenalternative.coでNitricの類似プロジェクトとして挙がっているのが Encore です。どちらもSDKでリソースを宣言し、ローカルで一通り動かしてからクラウドへ出す点は同じですが、デプロイを誰が実行するかが違います。

EncoreのREADMEは、フレームワーク・CLI・ランタイムなど開発と自前ホスティングに必要な部分をオープンソースとし、AWSやGoogle Cloudへの自動構築を担うマネージドのデプロイ基盤は任意の商用サービスだと説明しています。基盤を使わない場合は encore build docker でイメージを作り、インフラはTerraformやPulumiで自分で用意します。外部のサービスに頼らずクラウドのリソースまで自動で作りたいならNitric、Azureが不要で開発の勢いとコミュニティの大きさを重視するならEncore、というのが選び分けの軸です。設定ファイルにインフラを書くデプロイ専用のツールとの違いは、Serverless Frameworkとは？v4の料金・使い方・Python対応と無料の代替oslsまで【2026年10月】と比べると分かりやすくなります。

採用を判断する基準

向く案件と避けるべき案件

向いているのは、新しいクラウドネイティブのバックエンドを小さなチームで立ち上げる案件です。IaCの専任がいないがIAMは最小権限で組みたい、ローカルで動作を確かめてから同じコードをデプロイしたい、という要件にはよく合います。将来のクラウド移行に備えてAPI・ストレージ・メッセージングだけで組む設計なら、抽象化の恩恵も受けられます。

避けるべきなのは、既存のTerraformモジュールが多い組織、AzureやGoogle CloudでWebSocketsを使う予定がある案件、AzureでBatchを使う予定がある案件、SLA付きの商用サポートが調達の条件に入っている案件です。Nitricの導入はIaCの置き換えではなく1レイヤーの追加なので、既存資産が多いほど二重管理のコストが上回ります。デプロイ手順をそろえたいだけなら、抽象化の層を増やす必要はありません。AWSを中心にインフラの設計と構築をまとめて外部に任せたい場合は、弊社のインフラ構築（AWS・Google Cloud・Azure）の支援でIaCの選定から構築までご相談いただけます。

プロジェクトの活動状況とベンダーの動き

2026年11月1日時点で、nitrictech/nitric はApache-2.0のOSSでスターは2,020です。2026年2月4日のv1.27.6のあと8か月リリースが止まっていましたが、10月16日から17日にかけてv1.27.7からv1.28.4までの8リリースが出ました。中身はAWS向けの修正（Lambdaゲートウェイの複数値レスポンスヘッダー、SSMの上限対策）、resource-resolver の追加、Goの依存関係のセキュリティ更新、Go 1.27.2でのビルドです。一方、CLIは別リポジトリで最新がv1.61.1（2025年10月8日）のまま、npmのNode.js SDKも2025年7月17日の1.4.2が最新です。本体の保守は続いていますが、CLIとSDKの新版は1年近く出ていません。

運営元は米国のNitric Inc.（GitHubのorganizationは nitrictech）です。nitric.ioのトップページは、ホスティング製品「Suga」と、AIエージェントと人が共同作業するためのOSS「Sugabots」を紹介する内容に変わり、フレームワークへの入口はフッターのドキュメントとGitHubだけになりました。少なくともトップページの訴求は、フレームワークからホスティング製品へ移っています。公式FAQは、フレームワークが合わなくなったら別のIaCへ移ることになるとしたうえで、Nitric本体とCLIはGoで書かれPulumiのGo Providerを使っているので、生成済みのプロビジョニングコードを引き継げる可能性があると説明しています。基幹システムに使うなら、自社でフォークして保守できる体制を前提にしてください。

よくある質問

Nitricの読み方は？

英語の発音は /ˈnaɪtrɪk/ で、日本語では「ナイトリック」と書かれます。公式サイトやドキュメントに日本語の読み仮名はありません。検索するときは「nitric フレームワーク」「nitric infrastructure from code」のように語を足すと、硝酸（nitric acid）や一酸化窒素（nitric oxide）の結果と混ざりにくくなります。

無料で使えますか。ライセンスは？

フレームワーク本体もCLIもApache-2.0のオープンソースで、利用料はかかりません。かかるのはデプロイ先クラウドの利用料です。Pulumi版はPulumi Automation APIを使うので、別途ワークスペースを作る必要はありません。Pulumi Cloudをステートの保存先に使うかどうかも任意で、使う場合は pulumi login でログインし、PULUMI_ACCESS_TOKEN を環境変数で渡します。Terraform版にはTerraform CLIの実行環境が別に要ります。

ローカルでテストするのにクラウドへのデプロイは必要ですか？

不要です。nitric start がAPIゲートウェイ、ストレージ、キーバリューストア、スケジュールなどをローカルでエミュレートし、ダッシュボードから構成図の確認、APIの呼び出し、SQLの実行、トピックへの発行まで試せます。ただし中身はSeaweedFSやBoltDB、Dockerコンテナなので、マネージドサービス固有の制限やレイテンシ、IAMの拒否まではローカルで再現されません。権限まわりは実際のクラウドにデプロイして確かめます。

Nitricが対応していないクラウドサービスを使いたい場合は？

公式FAQのとおり、そのサービスだけアプリケーションコードから各クラウドのSDK（AWS SDKやAzure SDKなど）で直接呼び出せます。その部分はクラウドに依存しますが、API・ストレージ・メッセージングをNitricのAPIで書いておけば影響を一部に閉じ込められます。恒久的に対応させたい場合は、既存のProviderを拡張する方法と、Providerを新しく作る方法が公式に用意されています。後者はGo以外の言語でも作れます。

モノレポで使えますか？

使えます。公式には2通りが案内されています。1つはカスタムランタイムの機能でDockerビルドのコンテキストを変える方法、もう1つは nitric.yaml をリポジトリのルートに置く方法です。前者はサービスごとにDockerfileとビルドコンテキストを指定できるので、パッケージが分かれたモノレポでも各サービスの依存だけをイメージに含められます。

関連記事

• Pulumiとは？読み方・Terraformとの違い・料金と使い方をCLI 3.273で解説
• CDK for Terraform（CDKTF）とは？提供終了後の移行判断を解説
• Serverless Frameworkとは？v4の料金・使い方・Python対応と無料の代替oslsまで【2026年10月】
• HCP Terraformとは？旧Terraform Cloudの料金・無料枠500リソースと自前運用との違い
• Terraformコーディング規約とterraform fmtの使い方｜公式スタイルガイド準拠の命名・コメント・CI強制