PR30技術の地図
層、成熟度、日本語情報から候補を探し、個別レコードへ進みます。
30 technologies / one relational map
名前ではなく、スタック上の位置から読む。
技術名を知るだけでは、採用判断に必要な「どこに置くか」は分かりません。30件を役割、境界、上下左右の関係、成熟度、日本語情報の密度、未確認事項へ分解し、隣の技術まで辿れる地図にします。
FIRST ANSWER
最初に層、次に関係、最後に時点を読む。
同じ「開発基盤」でも、Linux、PostgreSQL、Kubernetes、OpenTelemetry、MCPは置き換え関係ではありません。この図鑑は総合順位を作らず、担当する層と接続先を先に示します。成熟度と日本語情報の評価は2026-08-18時点の編集判断であり、製品の優劣ではありません。
LAYER MAP
30件が担当する主な層
- OS・カーネル1
- データ4
- デリバリー自動化3
- ランタイム・コンテナ1
- オーケストレーション1
- Infrastructure as Code2
- オブザーバビリティ4
- ネットワーク1
- プラットフォームエンジニアリング2
- 耐久ワークフロー3
- 開発者API2
- 認証・アクセス1
- AIモデルサービング1
- エージェント実行3
- 統合プロトコル1
READING ROUTES
三つの入口
LinuxからHelmまで
OS、コンテナ、オーケストレーション、パッケージ管理を下層から順に読みます。
Terraform / OpenTofu
共通起点を持つ二つを固定軸で比較し、未知を別セルに残します。
ADMITTED RECORDS
公式情報を直接確認した30件
OS・カーネル
Linux
kernel.orgはLinuxをUnix系OSのカーネルとして説明し、完成したLinuxシステムであるディストリビューションとは別のものだと案内している。図鑑では配布形態とカーネル責務を混同しない。
- 成熟度
- Modern Core
- 日本語情報
- unknown
データ
PostgreSQL
公式DocumentationページはCurrentを含む複数版のオンラインマニュアルとアーカイブを分けて提示している。ページでは版を省略せず、対象版と確認日を同時に記録する。
- 成熟度
- Modern Core
- 日本語情報
- C
デリバリー自動化
Ansible
公式の保守文書はcommunity packageとansible-coreでversioning、内容、保守対象が異なると明記している。Ansibleという名前だけで単一の版や保守期間を表さない。
- 成熟度
- Modern Core
- 日本語情報
- unknown
ランタイム・コンテナ
Docker
Docker公式DocsはGet started、Guides、Manuals、CLI/API referenceをまとめ、Docker製品の利用者向け入口を構成している。上流Mobyの開発者向け説明とは読者目的が異なる。
- 成熟度
- Modern Core
- 日本語情報
- C
オーケストレーション
Kubernetes
公式DocsはKubernetesをcontainerized workloadsとservicesの管理を自動化するためのportableなオープンソースシステムとして案内する。図鑑では単なるコンテナ実行器ではなく、調整層として扱う。
- 成熟度
- Modern Core
- 日本語情報
- C
デリバリー自動化
Helm
Helm公式DocsとrepositoryはHelmをKubernetes package managerとして位置付ける。図鑑ではクラスタを直接置き換える実行層ではなく、アプリケーション配布を記述する層として扱う。
- 成熟度
- Modern Core
- 日本語情報
- unknown
Infrastructure as Code
Terraform
HashiCorp公式DocsはTerraformをInfrastructure as Codeとして案内し、APIを安全かつ予測可能にcreate/change/improveする宣言的設定を中心に説明する。対象resourceやproviderの差を省略しない。
- 成熟度
- Modern Core
- 日本語情報
- unknown
デリバリー自動化
Argo CD
Argo CD公式DocsはArgo CDをKubernetes向けのdeclarative GitOps continuous delivery toolと定義する。図鑑では一般CIやクラスタ本体と混同せず、CDとdesired stateの制御面として置く。
- 成熟度
- Rising
- 日本語情報
- unknown
オブザーバビリティ
Prometheus
Prometheus公式repositoryはPrometheusをmonitoring system and time series databaseと説明する。図鑑ではメトリクス収集・保存・queryの責務を、ダッシュボード表示の責務と分けて記録する。
- 成熟度
- Modern Core
- 日本語情報
- unknown
オブザーバビリティ
Grafana
Grafana公式repositoryはmetrics、logs、tracesを複数のデータソースから可視化するplatformとして説明する。図鑑ではPrometheusやPostgreSQLをGrafana本体の保存層とは扱わない。
- 成熟度
- Modern Core
- 日本語情報
- unknown
オブザーバビリティ
OpenTelemetry
公式docsはOpenTelemetryをvendor-neutralなopen source observability frameworkと説明し、traces、metrics、logsなどの生成・収集・exportを担うと整理している。バックエンド製品の代替ではなく、計測と送信の境界を揃える層として読める。
- 成熟度
- Rising
- 日本語情報
- C
ネットワーク
Cilium
公式docsはKubernetes Networking、Network Policy、kube-proxyなしの構成、互換性とトラブルシュートを独立した領域として持つ。Ciliumを単なる高速ネットワークではなく、clusterの通信制御面として読む手掛かりになる。
- 成熟度
- Rising
- 日本語情報
- unknown
Infrastructure as Code
OpenTofu
公式docsはconfiguration language、CLI、state、plan/applyを別の入口として示している。OpenTofuを単なるTerraformの名前替えとしてではなく、宣言的な構成をstateと計画実行へつなぐtoolchainとして整理できる。
- 成熟度
- Rising
- 日本語情報
- unknown
プラットフォームエンジニアリング
Backstage
Backstage公式の説明はSoftware Catalog、Software Templates、TechDocs、plugins、search、identity integrationを組み合わせる枠組みとして読める。単一の完成品の機能表ではなく、組織が自分のcatalogとgolden pathを構成する基盤である。
- 成熟度
- Rising
- 日本語情報
- unknown
プラットフォームエンジニアリング
Crossplane
CrossplaneはKubernetesのAPIとcontroller modelを使い、cloud resourceや組織向けplatform APIを宣言的に管理する枠組みとして整理できる。実行clusterそのものと、そこから外部resourceを制御する責務を分けて読む必要がある。
- 成熟度
- Rising
- 日本語情報
- unknown
耐久ワークフロー
Temporal
Temporalの公式blogは現在の記事領域としてDurable Executionとworkflowを掲げる。読者はキュー製品と混同せず、workflow state、activity、retry、timer、signal、versioningを長時間処理の実行モデルとして切り分けて読む。
- 成熟度
- Rising
- 日本語情報
- unknown
開発者API
Supabase
公式repositoryはSupabaseをPostgres development platformと説明し、web、mobile、AI applications向けのdedicated Postgresを掲げる。Auth、Storage、Realtime、APIを周辺機能として見ることで、単体databaseとbackend platformの境界を比較できる。
- 成熟度
- Rising
- 日本語情報
- unknown
データ
Neon
公式repositoryの説明はstorageとcomputeを分け、autoscaling、database branching、scale to zeroを可能にするserverless Postgresとして整理している。従来型Postgresの単一instanceだけでなく、開発単位の複製と実行を読む軸が追加される。
- 成熟度
- Rising
- 日本語情報
- unknown
開発者API
Resend
公式docsはResendをdevelopers向けemail APIと説明し、開始には自分のdomainをverifyしAPI keyを用意する必要があると示す。API呼び出しの簡単さと、DNS・reputation・abuse対応の責務は別の運用境界である。
- 成熟度
- Rising
- 日本語情報
- unknown
認証・アクセス
Clerk
公式docsはClerkをauthenticationとuser managementのためのserviceとして示し、複数のauthentication strategiesでuserを識別しbackendへのauthenticated requestを支えると説明する。login UIだけでなく、session、organization、B2B identityの境界を分けて読む必要がある。
- 成熟度
- Rising
- 日本語情報
- unknown
データ
Upstash
公式導入資料はUpstash RedisをRedis互換のデータベースとして説明し、永続化、バックアップ、リージョン選択などmanaged service側の責務を示している。
- 成熟度
- Watch
- 日本語情報
- unknown
耐久ワークフロー
Trigger.dev
公式docsはTrigger.devを、plain async codeでreliable workflowsを記述するopen source background jobs frameworkとして説明している。
- 成熟度
- Rising
- 日本語情報
- unknown
オブザーバビリティ
Langfuse
公式docsはLangfuseをopen-source AI engineering platformとし、trace、cost、latency、session、agent graphなどLLM applicationの観測対象を列挙している。
- 成熟度
- Rising
- 日本語情報
- A
AIモデルサービング
vLLM
公式docsはvLLMをモデル推論のserving engineとして、Hugging Face model連携、high-throughput serving、parallelism、streamingを列挙する。
- 成熟度
- Rising
- 日本語情報
- unknown
エージェント実行
E2B
公式repositoryはE2BをAI-generated codeをsecure isolated sandboxesで実行するopen-source infrastructureとして説明し、JS/Python SDKを入口にしている。
- 成熟度
- Rising
- 日本語情報
- unknown
エージェント実行
Modal
公式docsはModalを、インフラを意識せずcompute-intensive applicationsを動かすserverless cloudとして位置付け、LLM、batch、job queueなどを例示する。
- 成熟度
- Watch
- 日本語情報
- unknown
耐久ワークフロー
Restate
公式docsはRestateをAI agents、workflows、backend servicesをdurable processesへ変えるlightweight runtimeと説明している。
- 成熟度
- Rising
- 日本語情報
- unknown
統合プロトコル
MCP
公式docsはMCPをclientsとserversがtoolやdataへ接続するopen protocolとして説明し、serverをdata/toolの公開面、clientを利用側として分ける。
- 成熟度
- Rising
- 日本語情報
- B
データ
Turso
公式docsはTurso DatabaseをSQLite compatibleとして説明し、local reads/writesとcloud push/pull syncを別機能として案内している。
- 成熟度
- Rising
- 日本語情報
- unknown
エージェント実行
agent-sandbox
公式repositoryはagent-sandboxをisolated、stateful、singleton workloadsの管理基盤とし、AI agent runtimesやuntrusted code実行を用途に挙げる。
- 成熟度
- Watch
- 日本語情報
- unknown
INTERPRETATION BOUNDARY
UNKNOWNは「機能がない」ではない。
今回のbounded searchで確定できなかった値、矛盾した値、関係不足は、そのまま未確認・競合・relation gapとして表示します。ベンダーの主張を市場全体の事実へ変えず、コミュニティ情報をcurrent versionやlicenseの証明に使いません。