Nitricとは？対応クラウド・導入手順とCDKTF終了の影響

Nitric（ナイトリック）は、アプリケーションコードの中で宣言したリソースから、クラウドのインフラ構成とIAMポリシーを生成するオープンソースのフレームワークです。バケットやAPI、キューを bucket('assets') のように宣言しておくと、デプロイ時にNitricがその宣言を集約し、選択したプロバイダー経由でAWS・Microsoft Azure・Google Cloudの実サービスへ割り当てます。なお英単語の nitric は硝酸（nitric acid）や一酸化窒素（nitric oxide）を指しますが、本記事が扱うのは nitrictech/nitric のクラウド開発フレームワークです。以下は2026年7月28日時点の公式ドキュメント原文とGitHub・npmの実データに基づいて整理しています（リポジトリ由来の日付は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のみ実装、BatchはAzureが「Coming soon」と穴がある。
• デプロイ実行系はPulumi版とTerraform版の2系統。Terraform版は基盤のCDKTFが2025年12月10日にアーカイブされており、公式docsでもPreview扱い。本番はPulumi版が無難。
• リポジトリの更新頻度は2025年後半から鈍化している（main最終コミットは2026年2月4日）。採用するなら自社でフォーク保守できる体制が前提。

以降は仕組み、対応クラウド表、Pulumi版とTerraform版の分岐、導入コマンド、採用可否の順に、公式docs原文と実測値で確認します。

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

IaCツールとの役割分担

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

両者は排他ではありません。Nitricが呼び出すのはプラグイン（Provider）で、Pulumiで直接デプロイまで実行するタイプと、Terraformコードを生成して実行は利用者に委ねるタイプの2種類があります。いずれも既存のIaC運用に対する上位レイヤーなので、Pulumiとは？読み方・対応言語・Terraformとの違い・料金を実例で解説で扱うような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
})

ここで書いているのはアプリケーションのロジックだけですが、Nitricは「assetsという名前のバケットが必要」「このサービスはそのバケットに read/write/delete する」「mainというAPIのGETルートがこの関数を呼ぶ」という3つの要求を同時に読み取ります。デプロイ時にはこの集合がProviderへ渡り、S3バケットとAPI Gateway、Lambda関数、それらを結ぶIAMポリシーへ展開されます。nitric.yaml に match: services/*.ts のようなパターンを書いておくと、一致したファイルがそれぞれ独立したコンテナとして扱われます。

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

公式リファレンスは言語ごとに support レベルを明示しています。どの言語でも同じように使えるわけではないため、採用検討では最初に確認すべき表です。最終push日はGitHub APIの pushed_at の実測値です。

SDKとNitric ServerはgRPCとProtocol Buffersで通信するため、原理上は他言語の追加も可能です。ただし表のとおり実装の温度差は大きく、C#とJVMは公式リファレンスでもv0系のみ。JVM SDKは2024年6月18日を最後に更新が止まっています。npmの @nitric/sdk は2026年7月28日時点で latest が 1.4.2（2025年7月17日公開）です。JavaやKotlinの本番案件でNitricを前提にするのは推奨できません。

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

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

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

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

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

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

# Pulumi版（AWS）
provider: nitric/[email protected]
region: us-east-1

# Terraform版（AWS）
provider: nitric/[email protected]
region: us-east-1

バージョン部分はdocsのページごとに 1.1.1 や @latest と表記が揺れているので、実際にはリリース済みの最新版（プロバイダーのリリースは2026年2月4日の v1.27.6 が最新）か @latest を指定します。Pulumi版はNitricがPulumi Automation API経由で直接デプロイまで実行し、Pulumi Cloudの利用は任意です（ステートバックエンドとして使いたい場合だけ pulumi login します）。Terraform版は「IaCを生成するProvider」で、nitric up の結果として cdktf.out ディレクトリにTerraformコードが出力され、そこから terraform init／plan／apply を自分で回します。生成物の管理方針はTerraformコーディング規約（スタイルガイド）｜fmt・命名規則・ディレクトリ構成の統一ルールで扱う命名やディレクトリ構成のルールと合わせて決めておくと、運用が破綻しにくくなります。

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

NitricのTerraform ProviderはCDK for Terraform（CDKTF）で実装されています。そのCDKTFは、HashiCorp（IBM傘下）が2025年12月10日にサンセットしてGitHubリポジトリをアーカイブ済みです。READMEには「その日以降は保守も開発も行わない」「互換性対応を含め、修正や改善は行われない」と明記され、理由も「大規模な製品市場適合を見出せなかったため」と書かれています。ライセンスはMPLのままなので利用は続けられますが、上流の更新は止まりました。

Nitric公式ドキュメントも、Terraform Providerは3クラウドとも Preview 扱いで、「本番環境へ適用する前に生成されたTerraformをレビューすること、あるいはPulumi版を使うこと」を推奨しています。本番運用の既定はPulumi版にすべきです。Terraform版を選ぶなら、生成された cdktf.out を成果物としてレビュー・保存し、将来CDKTF層を外せるよう cdktf synth --hcl でHCLへ落とす手順まで検証しておくべきです。IaCの実行基盤側の選定はHCP Terraformとは？旧Terraform Cloud（名称変更）の機能・料金とHCPでの位置づけを解説も併せて確認してください。

導入からデプロイまでの手順（CLI導入・ローカル実行・スタック作成）

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

前提ツールは Git・Docker・Docker Buildx の3点で、Linuxでは非rootユーザーで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の前提に従います。Terraform版はTerraform CLIに加えて、CDKTFがNode.jsに依存するためNode.jsのインストールも必要です。またdocsが明記しているとおり nitric down は直接デプロイ型のProviderでしか使えず、Terraform版では terraform destroy など自分のIaCツール側で破棄します。Pulumi版であれば nitric up が差分を検出して更新するので、2回目以降も同じコマンドで反映できます。

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

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

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

採用を判断する基準

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

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

避けるべきなのは、既存のTerraformモジュール資産が大きい組織、AzureやGCPでWebSocketsやBatchを使う予定がある案件、そしてSLA付きの商用サポートが調達要件に入る案件です。Nitricの導入はIaCの置き換えではなく1レイヤーの追加であり、既存資産が厚いほど二重管理のコストが上回ります。似た領域のツールと比べると、Serverless Frameworkとは？v4の料金・使い方・無料の代替まで【2026年最新】で扱うようなデプロイ特化ツールは設定ファイルにインフラ定義を書くのに対し、Nitricはアプリケーションコード側の宣言を情報源にします。デプロイ手順の共通化だけが目的なら、抽象化層を増やす必要はありません。

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

採用前にリポジトリの状態も見てください。2026年7月28日時点で、nitrictech/nitric はApache-2.0のOSSでスターは約2,000、最新リリースは v1.27.6（2026年2月4日）、mainブランチの最終コミットも同日です。CLIは別リポジトリで最新リリースが v1.61.1（2025年10月8日）、2026年3月に出されたプルリクエストは未マージのまま残っています。開発が止まったと断定する材料ではありませんが、更新の間隔は2025年後半から明確に開いています。

運営元は米国のNitric Inc.（GitHub organizationは nitrictech）で、公式サイトのフッターは「© 2026 Nitric Inc.」です。そのnitric.ioは現在、即時デプロイ型のホスティング製品「Suga」を前面に打ち出しており、同社の主力がOSSフレームワークからホスティングサービスへ移りつつあることが読み取れます。公式FAQも「フレームワークが合わなくなったら別のIaCを選んで移行することになる」と述べたうえで、Nitric本体とCLIがGoで書かれPulumiのGo Providerを使っているため、生成済みのプロビジョニングコードを引き継げる可能性がある、と説明しています。基幹に据えるなら、自社でフォークして保守できる体制を前提条件にすべきです。

よくある質問

Nitricの読み方は？

英語の発音は /ˈnaɪtrɪk/ で、日本語では「ナイトリック」と表記されます。公式サイトやドキュメントに日本語の読み仮名の記載はありません。運営元は米国のNitric Inc.、GitHub organizationは nitrictech で、リポジトリ本体は nitrictech/nitric です。検索時は「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との違い・料金を実例で解説
• Serverless Frameworkとは？v4の料金・使い方・無料の代替まで【2026年最新】
• HCP Terraformとは？旧Terraform Cloud（名称変更）の機能・料金とHCPでの位置づけを解説
• Terraformコーディング規約（スタイルガイド）｜fmt・命名規則・ディレクトリ構成の統一ルール