LabHub

ブログ

Node.js & Bun & Deno バックエンドフレームワーク 2026 完全ガイド — Hono · Fastify · Express 5 · NestJS 11 · Elysia · tRPC · Encore TS · h3 · Effect 徹底解剖

2026-05-16 · 36 分で読めます · #nodejs#bun#deno#hono#fastify#express#nestjs#elysia#trpc#encore-ts#h3#backend#japanese

한국어English日本語

プロローグ — 「Node を知っていればバックエンドは終わり」の時代は終わった

2018年頃、誰かが「JavaScript でバックエンドを書く」と言えば、迷う余地なく Node.js + Express だった。2026年に同じ言葉を聞けば、最低でも7つは聞き返す。「ランタイムは? Node 22 LTS? 24? Bun? Deno? エッジ? オリジン? Hono? Fastify? ORM は Prisma? Drizzle? tRPC を挟む? Encore TS のようなインフラ一体型に行く? Effect まで使う?」答えによってアーキテクチャは完全に分岐する。

本稿は2026年5月時点における Node.js · Bun · Deno バックエンドフレームワークのエコシステムの地図を描く。ランタイムの違いからフレームワーク比較、ORM とバリデーションライブラリ、キューとワーカー、認証、ロギング、WebSocket、クラウドデプロイまで全体を見渡す。最後に Toss · Coupang · KakaoPay · Mercari · LINE Yahoo · DeNA · freee など韓国・日本企業の実採用事例をまとめる。

第1章 · 2026年 JavaScript ランタイム戦争の地形図

まずはランタイムそのもの。2026年には次の4つが同時に本番で動いている。

ランタイムエンジン強み弱み
Node.js 22 LTS / 24V8エコシステム、安定性、npm 互換性100%起動が遅い、コールドスタート
Bun 1.2+JSC (JavaScriptCore)速い起動、バンドラ・テスト内蔵一部ネイティブモジュールの互換性
Deno 2V8セキュリティ最優先、TS ネイティブ、標準ライブラリnpm 互換は互換にすぎない
Cloudflare WorkersV8 isolateコールドスタート ~0ms、グローバル分散一部 Node API 未対応、CPU 制限

その上に Vercel Edge Functions、Netlify Edge Functions (Deno)、AWS Lambda@Edge、Deno Deploy のようなサーバーレス・エッジ派生が加わる。唯一の正解はない。 ワークロード、チーム、コスト、コールドスタート感度がすべて違うからだ。

核心的な変化は2つ。1つ、エッジランタイムが本番の1級市民になった。Cloudflare Workers はグローバル320+ POP で V8 アイソレートを動かし、50ms TTFB を日常にする。2つ、Bun と Deno はもう実験ではない。Bun 1.2 は Vercel の一部インフラと Discord の一部サービスで本番稼働しており、Deno 2 は Netlify のエッジランタイムとして毎日数百億リクエストを処理する。

第2章 · Node.js 22 LTS / 24 — いまだデフォルト、しかし進化

2025年末に Node 22 が active LTS に落ち着き、Node 24 が current になったことで標準ラインナップが変わった。新たに入ったものをまとめると。

Node.js の強みはやはり npm パッケージ200万本との互換性 と 本番実績。Netflix · PayPal · LinkedIn · Uber · Walmart · Goldman Sachs · NASA がメインバックエンドに使っている。保守的なチームなら、Node 22 LTS は2027年4月までメンテされるので安全なデフォルト。

第3章 · Bun 1.2+ — JSC ベースの野心作

Bun は Jarred Sumner が作った JSC(Safari エンジン)ベースの JavaScript ランタイム + パッケージマネージャ + バンドラ + テストランナー + シェル。2024年に1.0が出て、2026年5月時点で1.2.x が安定チャネル。

Bun の魅力は明確。

弱点もはっきりしている。

いつ Bun を選ぶか: モノレポのビルド速度がボトルネックのとき、コールドスタートが重要なサーバーレスシナリオで Workers が合わないとき、Elysia のような Bun 最優先フレームワークを使いたいとき。

第4章 · Deno 2 — セキュリティ最優先、標準最優先

Ryan Dahl(Node の創始者)が Node への「後悔」を集めて作り直したランタイム。2024年の Deno 2.0 が大きな転換点になった — npm 互換が入ったからだ。

Deno のデザイン原則。

  1. セキュリティ最優先 — 既定でファイル・ネットワーク・環境変数アクセスがブロック。--allow-net、--allow-read などで明示的に権限付与。
  2. TypeScript ネイティブ — トランスパイル不要で .ts を直接実行。
  3. 標準ライブラリ — @std/http、@std/fs、@std/crypto など検証済み標準。
  4. 単一実行ファイル — deno compile で自己完結バイナリを出力。
  5. JSR(JavaScript Registry)— TS 最優先のモジュールレジストリ。

2026年時点での Deno の本当の強みは Deno Deploy プラットフォームと Netlify Edge Functions(Deno ベース)で最もよく現れる。グローバル分散の V8 アイソレートに TypeScript をそのまま載せる体験は非常に滑らか。

弱点は npm パッケージ互換がよくできているとはいえ100%ではない こと、そして Express のような一部レガシーミドルウェアが Deno では曲芸が必要 なこと。代わりに Hono、Oak、Fresh のような Deno 親和フレームワークがしっかり定着している。

第5章 · Cloudflare Workers — エッジ V8 アイソレートの黄金期

Workers は Node や Bun のような「ランタイム」というより、実行モデル自体が違う。コンテナ上の Node プロセスではなく、V8 アイソレートをグローバル320+ POP で即座に立ち上げる。だからコールドスタートは事実上ゼロに収束する。

2026年 Workers エコシステムの中心。

制約もある。CPU 時間 50ms(無料プラン)/ 30s(有料)制限、Node API の部分対応(nodejs_compat フラグで互換 ON)、メモリ 128MB。重い ML 推論や長い trace 処理はできない。

Hono が事実上の標準 になった。Cloudflare 自身が Hono をワーカーデモと公式ドキュメントで使い、honojs/hono リポジトリにも Cloudflare 社員が contributor として参加している。

第6章 · Hono 4 — エッジ最優先、マルチランタイムの勝者

Hono(炎)は日本の Yusuke Wada が作ったフレームワーク。Cloudflare Workers、Deno、Bun、Node.js、Vercel、AWS Lambda、Fastly Compute@Edge で同じコードが動く ことが決定的な強み。

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello Hono!'))
app.get('/users/:id', (c) => {
  const id = c.req.param('id')
  return c.json({ id, name: 'Alice' })
})

export default app

特徴。

2026年の Hono は エッジ最優先フレームワークの事実上の標準。Cloudflare の公式デモ、Vercel のドキュメント、Deno Deploy のガイド、いずれも Hono を例示に使う。

第7章 · Fastify 5 — Node 最速の正統派

Hono がエッジの王なら、Node ランタイムでは Fastify 5 が性能チャンピオン。Express と同じミドルウェアモデルだが、はるかに速く型フレンドリー。

いつ Fastify を選ぶか: Node オリジンサーバでスループットが重要なとき、OpenAPI 自動生成が必要なとき(@fastify/swagger)、多数のマイクロサービスが小さな Fastify アプリで構成されるとき。

Coupang が Express から Fastify へ一部サービスを移行した事例が2024年のカンファレンスで紹介された。スループット40%向上、p99 レイテンシ30%減。

第8章 · Express 5 — 10年越しの GA、それでも生きている

Express 5.0 は2014年に最初のアルファが出てから、ほぼ10年後の2024年9月にようやく stable になった。5.1.x も2025年に続いた。

5.0 の主要な変更。

依然として 世界で最も使われている Node フレームワーク。ダウンロード数、依存パッケージ数、チュートリアル・講義・StackOverflow 回答数すべて1位。学習資料が無限にあるので、新人バックエンドの最初のプロジェクトとしては今も良い選択。

弱点は明確。性能面で Fastify · Hono に劣る、型サポートが別パッケージ(@types/express)必要、OpenAPI 自動化が別ライブラリ(express-openapi-validator)依存。新規本番で Express をあえて選ぶ理由は減ってきている。

第9章 · Koa.js — async ミドルウェアの元祖

TJ Holowaychuk(Express 原作者)が作った後継作。2026年時点で Koa 2.x が安定。async/await ミドルウェアを最初に綺麗に整えたフレームワーク。

import Koa from 'koa'

const app = new Koa()

app.use(async (ctx, next) => {
  const start = Date.now()
  await next()
  const ms = Date.now() - start
  ctx.set('X-Response-Time', `${ms}ms`)
})

app.use(async (ctx) => {
  ctx.body = 'Hello Koa'
})

app.listen(3000)

2026年時点での採用率は下がった。Hono · Fastify · Express 5 が似た抽象度を提供する中で、わざわざ Koa を新規に選ぶ理由は薄れた。ただし Strapi、Egg.js、Sails のようなメタフレームワークが Koa 上にあるので、間接利用者は依然として多い。

第10章 · NestJS 11 — Angular スタイルの依存性注入

NestJS は Kamil Mysliwiec が作ったエンタープライズ志向フレームワーク。Angular のデコレータ・モジュール・DI パターンをそのままバックエンドに持ち込んだ。2025年後半に v11 が安定化。

import { Controller, Get, Param, Module } from '@nestjs/common'

@Controller('users')
class UsersController {
  @Get(':id')
  findOne(@Param('id') id: string) {
    return { id, name: 'Alice' }
  }
}

@Module({ controllers: [UsersController] })
export class AppModule {}

特徴。

NestJS v11 の変更点。

いつ NestJS を選ぶか: チームが大きいとき、DI・テスト・ドキュメント自動化のようなエンタープライズ要件があるとき、モノレポで多数のマイクロサービスを回すとき。重すぎると感じるなら Hono · Fastify など軽量側のほうがよい。

第11章 · AdonisJS 6 — JavaScript 版 Laravel

Harminder Virk が作ったフルスタック MVC フレームワーク。Laravel のデザインをほぼそのまま引き継ぎ、2024年の v6 で ESM と TypeScript 最優先に再整備された。

特徴。

Hono · Fastify が「組み立て型」なら、AdonisJS は「完成品」。Laravel 出身の開発者が Node に来るときに最も馴染む選択。2026年もインド・東欧・南米コミュニティで活発。

第12章 · Elysia — Bun ネイティブ、end-to-end 型

Elysia は SaltyAom が作った Bun 最優先のフレームワーク。Bun 上で最高のスループットを出し、型推論が Hono よりも精密。

import { Elysia, t } from 'elysia'

const app = new Elysia()
  .get('/users/:id', ({ params }) => ({ id: params.id, name: 'Alice' }), {
    params: t.Object({ id: t.String() }),
  })
  .listen(3000)

export type App = typeof app

特徴。

弱点: Bun 依存。Node・Deno で直接は動かない。だから「Bun を使うなら Elysia、それ以外なら Hono」が2026年の通常結論。

第13章 · h3 / Nitro / UnJS — Vue/Nuxt のバックエンドエンジン

UnJS は Pooya Parsa が率いる Vue/Nuxt エコシステムのユニバーサルライブラリ集合。その中心に h3(HTTP フレームワーク)と Nitro(サーバエンジン)がある。

Nuxt 3·4 のサーバ部分は Nitro。SolidStart、Analog のような他のメタフレームワークも Nitro 上で動く。バックエンド単独で使いたい場合 も nitropack だけ持ち込んで使える。

魅力は 単一コードベースで全ランタイムをターゲット にできる点。弱点は Hono と比べて認知度と資料が少ないこと。

第14章 · Encore TS — インフラまでコードで

Encore は Marcus Kohlberg が始めたバックエンドフレームワーク + インフラ。宣言したリソースが自動でクラウドにプロビジョニングされる ことが、ほかのフレームワークとの決定的な違い。

import { api } from 'encore.dev/api'
import { SQLDatabase } from 'encore.dev/storage/sqldb'

const db = new SQLDatabase('users', { migrations: './migrations' })

export const getUser = api(
  { expose: true, method: 'GET', path: '/users/:id' },
  async ({ id }: { id: string }) => {
    const row = await db.queryRow`SELECT * FROM users WHERE id = ${id}`
    return row
  },
)

いつ Encore を選ぶか: DevOps 人員が不足する小さなチーム、インフラを標準化したいスタートアップ。弱点は lock-in の印象 と 細かいインフラ制御の不足。

第15章 · Effect — 関数型 TypeScript の野心

Effect-TS は Michael Arnaldi が率いる関数型 TS エコシステム。Scala の ZIO や Haskell の IO モナドの発想を TypeScript に持ち込んだ。

特徴。

import { Effect, pipe } from 'effect'

const getUser = (id: string) =>
  pipe(
    Effect.tryPromise(() => fetch(`/users/${id}`)),
    Effect.flatMap((res) => Effect.tryPromise(() => res.json())),
    Effect.retry({ times: 3 }),
    Effect.timeout('5 seconds'),
  )

学習曲線は急。だが 複雑な非同期ワークフロー(決済・orchestration・多数の外部 API 呼び出し)では、try/catch 地獄よりはるかに明瞭になる。2026年には目にする機会が増えているが、チーム全員が関数型に慣れている必要がある。

第16章 · tRPC 11 — エンドツーエンド型安全 RPC

tRPC は Alex / KATT が作った RPC フレームワーク。GraphQL の型安全性をスキーマなしで 達成するのが核心。

import { initTRPC } from '@trpc/server'
import { z } from 'zod'

const t = initTRPC.create()

export const appRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string() }))
    .query(({ input }) => ({ id: input.id, name: 'Alice' })),
})

export type AppRouter = typeof appRouter

クライアント側で AppRouter 型だけ import すれば呼び出しが完全に型安全。

Next.js / Nuxt モノレポでバックエンドとフロントを同時に書くとき に強力。他言語クライアントや外部公開 API には合わない — それは OpenAPI / GraphQL の領域。

第17章 · バリデーションライブラリ — Zod · Valibot · ArkType · TypeBox

API 入力バリデーションと型推論は2026年バックエンドの核心的な意思決定の1つ。

ライブラリモデル強み弱み
Zod 3.xobject-builderエコシステム1位、Hono · tRPC · Fastify 1級ツリーシェイキング弱、バンドルサイズ
Valibotモジュラーツリーシェイキング・バンドルサイズ約10倍小さいエコシステムは小さい
ArkType型表現推論が速く、TS-native な表現学習曲線
TypeBoxJSON Schema標準 JSON Schema を同時生成、Fastify のデフォルトAPI が冗長
Joiクラス成熟、hapi の標準型推論が弱い
YupクラスReact フォーム親和バックエンドでは縮小

デフォルトは依然として Zod。ただし、バンドルサイズが決定的なとき(エッジ · モバイル同期コード共有)は Valibot、性能が決定的なときは ArkType、OpenAPI 自動生成が重要なときは TypeBox。

第18章 · ORM 戦争 — Prisma 6 vs Drizzle 0.40

2025~2026年で最も熱い比較。2つの ORM は哲学が完全に違う。

Prisma 6。

Drizzle ORM 0.40。

いつ Prisma: 大きなモノレポ、MongoDB のような多様なバックエンド、マイグレーション自動化中心。いつ Drizzle: エッジデプロイ、Workers · Vercel · Neon · Turso、SQL に慣れたチーム。

ほかに Kysely(型安全 SQL ビルダ、最も薄い)、MikroORM 6(Unit of Work パターン、エンタープライズ)、TypeORM 0.3(デコレータベース、シェア低下)、Sequelize 6(レガシー)、Objection.js / Bookshelf / Knex(クエリビルダ + 軽量 ORM)も依然として活動中。

第19章 · API パターン — REST · GraphQL · tRPC · gRPC · OpenAPI

パターン強み弱み
REST + OpenAPI普遍性、キャッシュ、豊富なツールover-fetching、多段ラウンドトリップ
GraphQL単一エンドポイント、クライアント主導フェッチキャッシュが難しい、N+1、複雑
tRPCTS エンドツーエンド型、ボイラープレート少TS 限定、外部公開が難しい
gRPC + Protobuf双方向ストリーミング、多言語、効率的ブラウザから直接呼びにくい
JSON-RPCシンプル、メッセージキュー親和ツーリングが貧弱

2026年の実務トレンド: 外部公開 API は REST + OpenAPI、内部マイクロサービスは gRPC、モノレポフルスタックは tRPC、公開グラフ API は GraphQL、イベント/RPC は JSON-RPC または NATS。1つに統一しようとせず、境界ごとに合うものを選ぶ。

第20章 · ジョブキュー — BullMQ · Cloudflare Queues · Inngest

非同期ジョブ、再試行、バックオフ、スケジューリングが必要なところ。

BullMQ(Redis ベース)。

Cloudflare Queues。

Inngest(durable workflow 専門)。

ほかに Hatchet(self-hostable durable workflow、Postgres ベース)、Trigger.dev(ワーカーベース + UI)、Temporal(他言語と併用するとき)— 詳細比較は別記事参照。

第21章 · 認証 — Auth.js v5 · Lucia v3 · better-auth

OAuth、JWT、セッション。2026年の風景。

選択基準: フルスタックモノレポなら Auth.js または better-auth、バックエンド単独で明示的セッションが必要なら Lucia、運用負担を外注したいなら Clerk/WorkOS。

第22章 · テスト — Vitest · Jest 30 · node test · Bun test · Playwright

ツール強み
VitestVite ネイティブ、watch モード速い、Jest 互換 API
Jest 30最も成熟、資料豊富、強力なモック
node test依存なし、CI が速い
Bun testBun 上で最速
PlaywrightE2E、ブラウザ自動化

2026年の新規プロジェクトでは Vitest がデフォルト になった。CI 環境では node test も使われる頻度が増えてきている。E2E は Playwright が事実上の標準(Cypress 比でマルチブラウザ · より速い)。

第23章 · ロギング — Pino · Winston · Bunyan

Node バックエンドロギングの3大巨頭。

2026年の通常選択: 新規プロジェクトなら Pino、多様な外部 sink が必要なら Winston。その上に OpenTelemetry で分散トレーシング。

第24章 · WebSocket — ws · uWebSockets.js · Socket.io · Hono WS

ライブラリ強みいつ
ws最もシンプル、RFC6455 直接低レベル WS、独自プロトコル
uWebSockets.js最速(C++ バインディング)数十万同時接続
Socket.io 4.8room · ack · 再接続 · pub-sub アダプタクライアントも同じライブラリ
Hono WebSocketWorkers · Bun · Node マルチランタイムエッジで WS
Bun.serve WSBun ネイティブ高速Bun 専用

Discord は約1億同時接続を Elixir + Rust で処理しつつ、一部 API は Node + Socket.io ベース。uWebSockets.js は一部の取引所 · ゲーム会社で使われる。

第25章 · クラウドデプロイ — Vercel · Workers · Lambda · Render · Railway · Fly.io

2026年バックエンドデプロイの選択肢。

いつ何を選ぶか。

第26章 · ミドルティアとマイナーフレームワーク

頻度は低くてもドメインでは強いもの。

このいずれかを新規に選ぶことは稀だが、メンテコードで遭遇しうる ので、名前と立ち位置は覚えておくと助かる。

第27章 · モニタリング · 観測性 — OpenTelemetry · Sentry · Datadog · Grafana

2026年バックエンド観測スタック。

Node バックエンドなら @opentelemetry/sdk-node で自動 instrumentation を仕込み、Sentry でエラーを受け、Grafana や Datadog に forward するパターンが一般的。

第28章 · セキュリティ — Helmet · CSRF · Rate limit · CORS

加えて OWASP Top 10(SQL injection · XSS · 認証欠陥 · セキュリティ misconfig など)をコードレビューチェックリストに。2026年でも、間抜けな事故はほぼ OWASP に書かれている。

第29章 · 韓国企業の採用事例 — Toss · Coupang · KakaoPay · Karrot

Toss。決済バックエンドの一部で Node + Hono の組み合わせ。グローバル分散決済 API のエッジルーティングに Cloudflare Workers + Hono を使うと、2025年の Toss Tech Conference で公開。Slack · 社内ツールのバックエンドは Node + Fastify。

Coupang。フルフィルメント一部 API を Express → Fastify に移行。2024年カンファレンス発表によるとスループット約40%向上、p99 レイテンシ約30%減。検索の一部インデキシングワーカーは BullMQ + Node。

KakaoPay。バックエンドの多くは Spring Boot だが、一部 BFF(Backend for Frontend)は Node + NestJS。tRPC パターンでフロントとの結合を減らした。

Karrot(당근마켓)。チャット · 通知などリアルタイム領域で Node + Socket.io を使用。最近は一部ワーカーを Bun で実験。

Line Games · Kakao Games · Nexon。ゲームメタ API の一部で Node を使用。WebSocket は uWebSockets.js や自社 C++ サーバと併用。

第30章 · 日本企業の採用事例 — Mercari · LINE Yahoo · DeNA · freee

Mercari。Hono を作った Yusuke Wada は Cloudflare へ加わる前にメルカリで働いていた。Mercari Shops の一部バックエンドは Hono + Cloudflare Workers。グローバル決済ルーティングと画像処理のエッジ化に Workers を使用。

LINE Yahoo。メインバックエンドは Kotlin · Java だが、一部統合 BFF や LINE ノベルのような新規サービスで Node + NestJS。一部広告システムバックエンドで Bun を実験。

DeNA。モバイルゲームバックエンドの一部で Node。チャット・イベント処理に Socket.io。

freee。会計 SaaS の一部 API で Node + Fastify。OpenAPI 自動生成のため Fastify + TypeBox の組み合わせ。

Cybozu · CyberAgent · Recruit。社内ツールの多くで Node + NestJS または Hono。Recruit は一部広告システムで Bun を試験中。

第31章 · 新規プロジェクトの意思決定ツリー

「どれを使うか」を助ける意思決定ツリー。

  1. フルスタックモノレポ(Next/Nuxt)? → tRPC + Hono/Fastify + Zod + Drizzle。
  2. エッジ最優先 API? → Cloudflare Workers + Hono + Drizzle + D1/Turso。
  3. エンタープライズ、大きなチーム、DI 必須? → NestJS 11 + Fastify アダプタ + Prisma 6 + Class Validator。
  4. Bun を採用中? → Elysia + TypeBox + Drizzle。
  5. Laravel 出身? → AdonisJS 6。
  6. インフラまで自動化? → Encore TS。
  7. 複雑な非同期ワークフロー? → Effect + Hono。
  8. レガシー Express のメンテ? → Express 5 にアップグレード、Fastify への段階移行を検討。

これはガイドラインに過ぎず、チームの慣熟度が最大の変数。「最高のツール」などはない。チームが速く書けて、デバッグできるツールが最高のツール。

第32章 · アンチパターン — よく見る失敗

第33章 · 性能ベンチマークの罠

「TechEmpower スコア」だけで決めてはいけない、というのが2026年の合意。

ベンチマークは参考にとどめ、自分のワークロードで負荷テスト(k6 · autocannon · oha) するのが真実に近い。

第34章 · 学習ロードマップ

すでに Node がある程度書ける前提。

  1. Hono を1週間で: Workers 無料プランに Hono + D1 で Todo API を立ち上げる。
  2. Fastify を2週間で: Postgres + Drizzle + Zod で小さな SaaS API + OpenAPI 自動生成。
  3. NestJS を1か月で: 本1冊(公式 docs か Ariel Weinberger 講座)+ 小さなマイクロサービスデモ。
  4. tRPC を1週間で: Next.js モノレポに tRPC でフルスタック CRUD。
  5. Effect を2か月で: 関数型入門が必要ならさらに長く。

面接の定番 — イベントループ、バックプレッシャ、クラスタ · worker_threads、stream API、CommonJS vs ESM、N+1 問題と dataloader、GraphQL N+1 緩和、JWT vs セッション、rate limit アルゴリズム(token bucket、sliding window)。

第35章 · まとめ — 正解はないが、良い問いはある

2026年の JavaScript バックエンドの風景は「Node + Express」時代よりずっと複雑になったが、それは選択肢が増えたからであり、進歩が遅れたわけではない。エッジコンピューティングが本番になり、型安全性がデフォルトになり、インフラがコードになり、コールドスタートが0に近づいた。

次のプロジェクトを始めるとき、「どのフレームワークが熱いか」ではなく、まずこの問いを。

  1. どこで動くか? エッジか、オリジンか、両方か?
  2. 誰が書くか? 関数型が扱えるチームか、デコレータに慣れているか?
  3. 外部公開するか? するなら OpenAPI · REST。
  4. クライアントは誰が書くか? 同じモノレポなら tRPC、他言語なら gRPC/REST。
  5. 運用は誰がやるか? DevOps が不足なら Vercel · Railway · Encore。
  6. 半年後に後悔しないか? 「トレンド」より「メンテ人口」。

良いバックエンドは良いフレームワークからは生まれない。良い問い から生まれる。

参考資料 (References)

コメント

まだコメントはありません。

ログインするとコメントできます