JSON Templates for Developers — Ready-to-Use Examples for APIs, Config & DevOps

Browse practical JSON templates for REST APIs, configuration files, database schemas, and cloud infrastructure. Copy, customize, and use in your projects. 18 templates with real-world examples.

JSONTech チームMarch 25, 20269 min

なぜJSONテンプレートを使用するのか？

すべての開発者は、APIレスポンスエンベロープ、tsconfig.json、Docker Composeファイルなど、同じJSON構造を何度も書いたことがあるでしょう。毎回、以前のプロジェクトからコピーするか（正しいことを願って）、最初から書くか（微妙なミスを引き起こす）になります。

テンプレートはそのサイクルを排除します。実績のある構造から始めることで、4つの具体的な利点があります：

時間を節約。 空のファイルの問題をスキップします。テンプレートを使用すると、作業の興味深い部分に早く到達できます。
一貫性を確保。 組織内のすべてのサービスが同じAPIエンベロープを返すと、消費者は10個のレスポンスハンドラーではなく、1つのレスポンスハンドラーを書くことができます。
エラーを減少。 Kubernetesマニフェストで必須フィールドを忘れると、デプロイメントが停止する可能性があります。テンプレートには、通常忘れてしまうフィールドが含まれています。
迅速なオンボーディング。 新しいチームメンバーはテンプレートを読み、プロダクションデータから逆エンジニアリングする代わりに、期待される構造をすぐに理解できます。

以下のテンプレートは、現代の開発で最も一般的なJSON構造をカバーしています。それぞれは、テンプレートライブラリで利用可能で、ワンクリックでコピーできます。

APIレスポンステンプレート

採用できる最も影響力のあるJSONテンプレートは、一貫したAPIレスポンスエンベロープです。すべてのエンドポイントがアドホックな形状を返すのではなく、成功時にdata、失敗時にerror、リクエストトレーシングとページネーションのためにmetaを持つ標準のラッパーを定義します。

ページネーションAPIレスポンス

以下は、エンベロープパターンに従った実際のページネーションレスポンスです：

{
  "data": [
    { "id": "usr_abc123", "name": "アリス・ジョンソン", "role": "admin" },
    { "id": "usr_def456", "name": "ボブ・スミス", "role": "member" }
  ],
  "meta": {
    "total": 84,
    "page": 2,
    "per_page": 20,
    "total_pages": 5,
    "request_id": "req_9f3b7a"
  }
}

この構造により、クライアントはmetaからページネーションコントロールをレンダリングでき、推測する必要がありません。request_idはサポートチケットのデバッグを簡単にします — ログを検索するだけです。

完全なテンプレートを参照： REST API成功レスポンス、REST APIエラーレスポンス、ページネーションレスポンス。

設定ファイルテンプレート

設定ファイルは、ほとんどのJSONエラーが静かに発生する場所です。tsconfig.jsonの間違ったコンパイラオプションはクラッシュしません — ただ微妙に間違った出力を生成します。検証済みのテンプレートから始めることで、それを回避できます。

TypeScript設定

Next.jsプロジェクト用の最小限ですが生産準備が整ったtsconfig.json：

{
  "compilerOptions": {
    "target": "ES2017",
    "lib": ["dom", "dom.iterable", "esnext"],
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "jsx": "preserve",
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

ここでの重要な選択肢： strict: trueは早期に型エラーをキャッチし、moduleResolution: "bundler"は現代のバンドラーと整合します。また、@/*パスエイリアスはインポートをクリーンに保ちます。

設定テンプレート： package.json、tsconfig.json、ESLint設定。

データベーススキーマテンプレート

開発データベースをシードする場合でも、MongoDBのドキュメント構造を定義する場合でも、テンプレートを持つことで、チームはアプリケーションコードの最初の行の前にフィールド名、型、デフォルト値に合意できます。

MongoDBユーザードキュメント

{
  "_id": "ObjectId('66a1b2c3d4e5f6a7b8c9d0e1')",
  "email": "alice@example.com",
  "profile": {
    "firstName": "アリス",
    "lastName": "ジョンソン",
    "avatar": "https://cdn.example.com/avatars/alice.jpg"
  },
  "roles": ["admin", "editor"],
  "settings": { "theme": "dark", "locale": "ja-JP" },
  "createdAt": "2026-01-15T09:30:00Z",
  "updatedAt": "2026-03-20T14:22:00Z"
}

この構造は、関連するフィールドをprofileとsettingsの下にネストし、効率的なインデックス作成のためにトップレベルのドキュメントを十分にフラットに保ちながら、論理的に関連するデータをグループ化します。

データベーステンプレート： MongoDBスキーマ、Prismaシードデータ。

DevOps & クラウドテンプレート

インフラストラクチャコードファイルは、最もエラーが発生しやすいJSONの一部です。KubernetesマニフェストやCloudFormationテンプレートのフィールドが欠けていると、プロダクションでのみ表面化する静かな失敗を引き起こす可能性があります。テンプレートは、既知の良好な出発点を提供します。

Kubernetesデプロイメント

JSON形式の簡略化されたKubernetesデプロイメントマニフェスト：

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "web-api",
    "labels": { "app": "web-api", "env": "production" }
  },
  "spec": {
    "replicas": 3,
    "selector": { "matchLabels": { "app": "web-api" } },
    "template": {
      "metadata": { "labels": { "app": "web-api" } },
      "spec": {
        "containers": [{
          "name": "web-api",
          "image": "registry.example.com/web-api:1.4.2",
          "ports": [{ "containerPort": 8080 }],
          "resources": {
            "requests": { "cpu": "250m", "memory": "256Mi" },
            "limits": { "cpu": "500m", "memory": "512Mi" }
          }
        }]
      }
    }
  }
}

リソースのリクエストと制限はデフォルトで含まれています — これをスキップすることは、共有クラスターでのノイジー隣人問題の主な原因です。ラベルは標準のapp / envの規約に従っているため、セレクターやネットワークポリシーがすぐに機能します。

インフラストラクチャテンプレート： Docker Compose、Kubernetesデプロイメント、GitHub Actionsワークフロー。

JWTペイロードテンプレート

JSON Webトークンは、JSONペイロードとしてクレームを運びます。標準のクレームを正しく設定することは重要です — expクレームが欠けているとトークンは決して期限切れにならず、間違ったissは検証を壊します。

{
  "sub": "usr_abc123",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "exp": 1774648800,
  "iat": 1774645200,
  "nbf": 1774645200,
  "roles": ["admin", "editor"],
  "email": "alice@example.com"
}

登録されたクレーム（sub、iss、aud、exp、iat、nbf）は、RFC 7519に従います。rolesやemailのようなカスタムクレームは、トークンサイズを小さく保つために短い名前を使用する必要があります — JWTはHTTPヘッダーで送信されるため、バイト数が重要です。

完全なテンプレートを参照： JWTペイロード。

テンプレートをカスタマイズする方法

テンプレートは出発点であり、完成品ではありません。以下は、任意のテンプレートをプロジェクトに適応させるための実用的なワークフローです：

最も近いテンプレートから始める。 使用ケースに最も近いものを選択します。ページネーションレスポンステンプレートは、一般的な成功レスポンスよりも検索エンドポイントの出発点として適しています。
フィールドをリネームおよび追加。 プレースホルダー値を実際のフィールド名に変更します。アプリケーションに必要なドメイン固有のフィールドを追加します。適用されないフィールドは削除します。
結果を検証。 修正したJSONをJSONバリデーターに貼り付けて、構文エラーをキャッチします — 手動で編集する際にトレーリングカンマや欠落した引用符を簡単に導入することがあります。
可読性のためにフォーマット。 JSONフォーマッターを通して実行し、コードベースにコミットしたりチームと共有したりする前に、一貫したインデントを確保します。
スキーマでロックダウン。 APIレスポンスのような重要な構造については、将来の変更が自動的に検証されるようにJSONスキーマを定義します。

すべてのテンプレートを閲覧

このガイドの例はほんの一部です。私たちのテンプレートライブラリには、API、設定、データベース、認証、クラウドインフラストラクチャをカバーする18の使えるテンプレートが含まれており、それぞれにフィールドごとの説明とクリップボードへのコピーサポートがあります。

完全なコレクションを閲覧： JSONテンプレートライブラリを訪れて、スタックに合ったテンプレートを見つけてください。任意のテンプレートをワンクリックでコピーし、カスタマイズし、JSONフォーマッターで結果を検証します。