jpskill.com
🛠️ 開発・MCP コミュニティ

domain-cloud-native

クラウドネイティブなアプリケーション開発において、KubernetesやDockerなどの技術を活用し、マイクロサービスやサービスメッシュの構築、監視、デプロイメントなどを効率的に行うための支援をするSkill。

📜 元の英語説明(参考)

Use when building cloud-native apps. Keywords: kubernetes, k8s, docker, container, grpc, tonic, microservice, service mesh, observability, tracing, metrics, health check, cloud, deployment, 云原生, 微服务, 容器

🇯🇵 日本人クリエイター向け解説

一言でいうと

クラウドネイティブなアプリケーション開発において、KubernetesやDockerなどの技術を活用し、マイクロサービスやサービスメッシュの構築、監視、デプロイメントなどを効率的に行うための支援をするSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o domain-cloud-native.zip https://jpskill.com/download/9254.zip && unzip -o domain-cloud-native.zip && rm domain-cloud-native.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9254.zip -OutFile "$d\domain-cloud-native.zip"; Expand-Archive "$d\domain-cloud-native.zip" -DestinationPath $d -Force; ri "$d\domain-cloud-native.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して domain-cloud-native.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → domain-cloud-native フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Cloud-Native ドメイン

レイヤー 3: ドメイン制約

ドメイン制約 → 設計への影響

ドメインルール 設計制約 Rust の影響
12-Factor 環境からの設定 環境変数ベースの設定
可観測性 メトリクス + トレース tracing + opentelemetry
ヘルスチェック 生存性/準備性 専用のエンドポイント
グレースフルシャットダウン クリーンな終了 シグナルハンドリング
水平スケール ステートレスな設計 ローカルステートなし
コンテナフレンドリー 小さなバイナリ リリース最適化

重要な制約

ステートレスな設計

RULE: ローカルな永続ステートを持たない
WHY: Pod はいつでも強制終了/再スケジュールされる可能性がある
RUST: 外部ステート (Redis, DB), static mut は使用しない

グレースフルシャットダウン

RULE: SIGTERM を処理し、接続をドレインする
WHY: ダウンタイムなしのデプロイメント
RUST: tokio::signal + グレースフルシャットダウン

可観測性

RULE: すべてのリクエストは追跡可能でなければならない
WHY: 分散システムのデバッグ
RUST: tracing スパン, opentelemetry エクスポート

トレースダウン ↓

制約から設計へ (レイヤー 2):

"分散トレーシングが必要"
    ↓ m12-lifecycle: スパンのライフサイクル
    ↓ tracing + opentelemetry

"グレースフルシャットダウンが必要"
    ↓ m07-concurrency: シグナルハンドリング
    ↓ m12-lifecycle: 接続のドレイン

"ヘルスチェックが必要"
    ↓ domain-web: HTTP エンドポイント
    ↓ m06-error-handling: ヘルスステータス

主要なクレート

目的 クレート
gRPC tonic
Kubernetes kube, kube-runtime
Docker bollard
Tracing tracing, opentelemetry
メトリクス prometheus, metrics
設定 config, figment
ヘルス HTTP エンドポイント

デザインパターン

パターン 目的 実装
gRPC サービス サービスメッシュ tonic + tower
K8s オペレーター カスタムリソース kube-runtime Controller
可観測性 デバッグ tracing + OTEL
ヘルスチェック オーケストレーション /health, /ready
設定 12-factor 環境変数 + シークレット

コードパターン: グレースフルシャットダウン

use tokio::signal;

async fn run_server() -> anyhow::Result<()> {
    let app = Router::new()
        .route("/health", get(health))
        .route("/ready", get(ready));

    let addr = SocketAddr::from(([0, 0, 0, 0], 8080));

    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .with_graceful_shutdown(shutdown_signal())
        .await?;

    Ok(())
}

async fn shutdown_signal() {
    signal::ctrl_c().await.expect("failed to listen for ctrl+c");
    tracing::info!("shutdown signal received");
}

ヘルスチェックパターン

async fn health() -> StatusCode {
    StatusCode::OK
}

async fn ready(State(db): State<Arc<DbPool>>) -> StatusCode {
    match db.ping().await {
        Ok(_) => StatusCode::OK,
        Err(_) => StatusCode::SERVICE_UNAVAILABLE,
    }
}

よくある間違い

間違い ドメイン違反 修正
ローカルファイルステート ステートレスではない 外部ストレージ
SIGTERM を処理しない 強制終了 グレースフルシャットダウン
トレーシングがない デバッグできない tracing スパン
静的な設定 12-factor ではない 環境変数

レイヤー 1 へのトレース

制約 レイヤー 2 パターン レイヤー 1 実装
ステートレス 外部ステート Arc<Client> for external
グレースフルシャットダウン シグナルハンドリング tokio::signal
トレーシング スパンのライフサイクル tracing + OTEL
ヘルスチェック HTTP エンドポイント 専用のルート

関連スキル

いつ 参照
非同期パターン m07-concurrency
HTTP エンドポイント domain-web
エラーハンドリング m13-domain-error
リソースライフサイクル m12-lifecycle
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Cloud-Native Domain

Layer 3: Domain Constraints

Domain Constraints → Design Implications

Domain Rule Design Constraint Rust Implication
12-Factor Config from env Environment-based config
Observability Metrics + traces tracing + opentelemetry
Health checks Liveness/readiness Dedicated endpoints
Graceful shutdown Clean termination Signal handling
Horizontal scale Stateless design No local state
Container-friendly Small binaries Release optimization

Critical Constraints

Stateless Design

RULE: No local persistent state
WHY: Pods can be killed/rescheduled anytime
RUST: External state (Redis, DB), no static mut

Graceful Shutdown

RULE: Handle SIGTERM, drain connections
WHY: Zero-downtime deployments
RUST: tokio::signal + graceful shutdown

Observability

RULE: Every request must be traceable
WHY: Debugging distributed systems
RUST: tracing spans, opentelemetry export

Trace Down ↓

From constraints to design (Layer 2):

"Need distributed tracing"
    ↓ m12-lifecycle: Span lifecycle
    ↓ tracing + opentelemetry

"Need graceful shutdown"
    ↓ m07-concurrency: Signal handling
    ↓ m12-lifecycle: Connection draining

"Need health checks"
    ↓ domain-web: HTTP endpoints
    ↓ m06-error-handling: Health status

Key Crates

Purpose Crate
gRPC tonic
Kubernetes kube, kube-runtime
Docker bollard
Tracing tracing, opentelemetry
Metrics prometheus, metrics
Config config, figment
Health HTTP endpoints

Design Patterns

Pattern Purpose Implementation
gRPC services Service mesh tonic + tower
K8s operators Custom resources kube-runtime Controller
Observability Debugging tracing + OTEL
Health checks Orchestration /health, /ready
Config 12-factor Env vars + secrets

Code Pattern: Graceful Shutdown

use tokio::signal;

async fn run_server() -> anyhow::Result<()> {
    let app = Router::new()
        .route("/health", get(health))
        .route("/ready", get(ready));

    let addr = SocketAddr::from(([0, 0, 0, 0], 8080));

    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .with_graceful_shutdown(shutdown_signal())
        .await?;

    Ok(())
}

async fn shutdown_signal() {
    signal::ctrl_c().await.expect("failed to listen for ctrl+c");
    tracing::info!("shutdown signal received");
}

Health Check Pattern

async fn health() -> StatusCode {
    StatusCode::OK
}

async fn ready(State(db): State<Arc<DbPool>>) -> StatusCode {
    match db.ping().await {
        Ok(_) => StatusCode::OK,
        Err(_) => StatusCode::SERVICE_UNAVAILABLE,
    }
}

Common Mistakes

Mistake Domain Violation Fix
Local file state Not stateless External storage
No SIGTERM handling Hard kills Graceful shutdown
No tracing Can't debug tracing spans
Static config Not 12-factor Env vars

Trace to Layer 1

Constraint Layer 2 Pattern Layer 1 Implementation
Stateless External state Arc<Client> for external
Graceful shutdown Signal handling tokio::signal
Tracing Span lifecycle tracing + OTEL
Health checks HTTP endpoints Dedicated routes

Related Skills

When See
Async patterns m07-concurrency
HTTP endpoints domain-web
Error handling m13-domain-error
Resource lifecycle m12-lifecycle