Claude Codeでマイクロサービス開発｜設計・実装・運用の実践ガイド

⚡ 3秒でわかる！この記事のポイント

Claude Codeはマイクロサービスの境界設計・API定義・通信パターン実装を一気通貫で支援
ドメイン分析からサービス分割、gRPC/REST API生成までをプロンプト一発で自動化
SES現場で増加するマイクロサービス案件に即戦力で対応するスキルが身につく

「モノリスからマイクロサービスへの移行プロジェクトにアサインされたが、どこから手をつけていいかわからない」「サービス間通信の設計パターンが多すぎて、最適な選択ができない」——SES現場でこうした悩みを抱えるエンジニアは少なくありません。

2026年現在、マイクロサービスアーキテクチャはSES案件の主流になっています。金融・EC・SaaS業界を中心に、モノリスからの移行案件や新規マイクロサービス構築案件が急増しており、これらのスキルを持つエンジニアの単価は平均15〜20%高い傾向にあります。

本記事では、Claude Codeを活用してマイクロサービス開発を効率的に進める方法を、設計から実装・運用まで体系的に解説します。

マイクロサービス開発でClaude Codeが活きる理由

マイクロサービス開発には「設計の複雑さ」「大量のボイラープレートコード」「サービス間通信の実装」という3つの大きなハードルがあります。Claude Codeは、これらすべてを劇的に効率化できるツールです。

従来のマイクロサービス開発の課題

課題	具体的な問題	工数への影響
サービス境界の設計	ドメイン分析が属人的で手戻りが多い	+30〜50%
ボイラープレート	各サービスの雛形・設定ファイル作成	1サービスあたり2〜3日
API設計	OpenAPI/gRPC定義の整合性維持	継続的なコスト
テスト	サービス間の結合テスト設計	テスト工数全体の40%
インフラ	Dockerfile・K8sマニフェスト管理	運用コストの大部分

Claude Codeによる解決アプローチ

Claude Codeの強みは、コードベース全体を理解した上で横断的な設計判断ができる点です。CLAUDE.mdにアーキテクチャ方針を定義しておけば、一貫した設計思想でコード生成・レビューを行ってくれます。

# CLAUDE.md（マイクロサービスプロジェクト用）

## アーキテクチャ方針
- サービス間通信: 同期はgRPC、非同期はKafka
- API Gateway: Kong
- サービスメッシュ: Istio
- データベース: サービスごとに独立（Database per Service）
- 認証: JWT + OAuth2.0（共通認証サービス経由）

## コーディング規約
- 各サービスはClean Architectureに従う
- エラーハンドリングは共通ライブラリを使用
- ログフォーマットはJSON構造化ログ

実践①：ドメイン分析とサービス分割

マイクロサービス設計の最初のステップは、ドメインの分析とサービス境界の決定です。Claude Codeを使えば、既存コードベースからドメインを自動分析できます。

既存モノリスの分析

# モノリスのコードベースをClaude Codeで分析
claude "このプロジェクトのドメインモデルを分析して、マイクロサービスに分割する
提案をしてください。以下の観点で分析してください：
1. ビジネスドメインの境界（Bounded Context）
2. データの所有権（どのドメインがどのデータを持つべきか）
3. 依存関係の方向性
4. 分割の優先順位（結合度が低いものから段階的に）"

Claude Codeは、コード内のimport文・関数呼び出し・データモデルの依存関係を自動で読み取り、ドメイン境界の提案を行います。

分割提案の具体例

ECサイトのモノリスを分析した場合、Claude Codeは以下のような分割を提案します：

📦 推奨サービス分割
├── user-service/        # ユーザー管理・認証
│   ├── 所有データ: users, profiles, addresses
│   └── 外部API: 認証(JWT発行), プロフィール参照
├── product-service/     # 商品カタログ
│   ├── 所有データ: products, categories, inventory
│   └── 外部API: 商品検索, 在庫照会
├── order-service/       # 注文処理
│   ├── 所有データ: orders, order_items
│   └── 外部API: 注文作成, 注文状況照会
├── payment-service/     # 決済処理
│   ├── 所有データ: payments, refunds
│   └── 外部API: 決済実行, 返金処理
└── notification-service/ # 通知
    ├── 所有データ: notification_logs
    └── 外部API: メール送信, プッシュ通知

CLAUDE.mdでの設計方針共有

分析結果を受けて、CLAUDE.mdに設計方針を明文化します：

## サービス分割方針
- user-service: 認証・認可の中核。JWTトークン発行を担当
- product-service: 商品情報のSingle Source of Truth
- order-service: Sagaパターンで分散トランザクションを管理
- payment-service: 外部決済APIとの連携。冪等性を保証
- notification-service: イベント駆動で非同期処理

実践②：サービスのスキャフォールディング

サービス分割が決まったら、各サービスの雛形を生成します。Claude Codeのマルチファイル編集能力を活かせる場面です。

一括スキャフォールディング

claude "order-serviceのスキャフォールディングを作成してください。
要件：
- 言語: Go 1.22
- フレームワーク: Echo v4
- アーキテクチャ: Clean Architecture（domain/usecase/interface/infrastructure）
- データベース: PostgreSQL（sqlcでクエリ生成）
- API: gRPC + REST（gRPC-Gateway）
- テスト: testify + mockgen
- Docker: マルチステージビルド
- CI: GitHub Actionsワークフロー"

Claude Codeは以下のようなディレクトリ構造を一括生成します：

order-service/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── domain/
│   │   ├── order.go          # エンティティ
│   │   ├── repository.go     # リポジトリインターフェース
│   │   └── event.go          # ドメインイベント
│   ├── usecase/
│   │   ├── create_order.go   # 注文作成ユースケース
│   │   └── get_order.go      # 注文照会ユースケース
│   ├── interface/
│   │   ├── grpc/
│   │   │   └── handler.go    # gRPCハンドラ
│   │   └── rest/
│   │       └── handler.go    # RESTハンドラ
│   └── infrastructure/
│       ├── persistence/
│       │   └── postgres.go   # PostgreSQL実装
│       └── messaging/
│           └── kafka.go      # Kafkaプロデューサー
├── proto/
│   └── order/
│       └── order.proto
├── db/
│   ├── migrations/
│   └── queries/
├── Dockerfile
├── docker-compose.yml
└── .github/
    └── workflows/
        └── ci.yml

gRPC定義の自動生成

claude "order-serviceのgRPC定義を作成してください。
対象メソッド:
- CreateOrder: 注文作成（冪等性キー付き）
- GetOrder: 注文照会
- ListOrders: 注文一覧（ページネーション対応）
- UpdateOrderStatus: ステータス更新（状態遷移バリデーション付き）
- CancelOrder: 注文キャンセル（キャンセル可能条件チェック付き）"

生成されるprotoファイル：

syntax = "proto3";

package order.v1;

import "google/protobuf/timestamp.proto";

service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc ListOrders(ListOrdersRequest) returns (ListOrdersResponse);
  rpc UpdateOrderStatus(UpdateOrderStatusRequest) returns (Order);
  rpc CancelOrder(CancelOrderRequest) returns (Order);
}

message CreateOrderRequest {
  string idempotency_key = 1;
  string user_id = 2;
  repeated OrderItem items = 3;
  ShippingAddress shipping_address = 4;
}

message Order {
  string id = 1;
  string user_id = 2;
  OrderStatus status = 3;
  repeated OrderItem items = 4;
  int64 total_amount = 5;
  google.protobuf.Timestamp created_at = 6;
  google.protobuf.Timestamp updated_at = 7;
}

enum OrderStatus {
  ORDER_STATUS_UNSPECIFIED = 0;
  ORDER_STATUS_PENDING = 1;
  ORDER_STATUS_CONFIRMED = 2;
  ORDER_STATUS_PROCESSING = 3;
  ORDER_STATUS_SHIPPED = 4;
  ORDER_STATUS_DELIVERED = 5;
  ORDER_STATUS_CANCELLED = 6;
}

実践③：サービス間通信の実装

マイクロサービスの最大の技術的課題は、サービス間通信の設計と実装です。Claude Codeは通信パターンの選択から実装まで一貫してサポートします。

同期通信（gRPC）

claude "order-serviceからproduct-serviceへのgRPC呼び出しを実装してください。
要件:
- 在庫確認API呼び出し
- リトライ（3回、exponential backoff）
- サーキットブレーカー（gobreaker使用）
- タイムアウト: 3秒
- OpenTelemetryトレーシング対応"

Claude Codeが生成するクライアントコード：

package client

import (
    "context"
    "time"

    "github.com/sony/gobreaker"
    "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
    "google.golang.org/grpc"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"

    pb "github.com/example/product-service/proto/product/v1"
)

type ProductClient struct {
    client pb.ProductServiceClient
    cb     *gobreaker.CircuitBreaker
}

func NewProductClient(addr string) (*ProductClient, error) {
    conn, err := grpc.NewClient(addr,
        grpc.WithStatsHandler(otelgrpc.NewClientHandler()),
        grpc.WithDefaultServiceConfig(`{
            "methodConfig": [{
                "name": [{"service": "product.v1.ProductService"}],
                "retryPolicy": {
                    "maxAttempts": 3,
                    "initialBackoff": "0.1s",
                    "maxBackoff": "1s",
                    "backoffMultiplier": 2,
                    "retryableStatusCodes": ["UNAVAILABLE","DEADLINE_EXCEEDED"]
                }
            }]
        }`),
    )
    if err != nil {
        return nil, err
    }

    cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
        Name:        "product-service",
        MaxRequests: 3,
        Interval:    10 * time.Second,
        Timeout:     30 * time.Second,
        ReadyToTrip: func(counts gobreaker.Counts) bool {
            return counts.ConsecutiveFailures > 5
        },
    })

    return &ProductClient{
        client: pb.NewProductServiceClient(conn),
        cb:     cb,
    }, nil
}

func (c *ProductClient) CheckInventory(ctx context.Context, productID string, quantity int32) (bool, error) {
    ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel()

    result, err := c.cb.Execute(func() (interface{}, error) {
        resp, err := c.client.CheckInventory(ctx, &pb.CheckInventoryRequest{
            ProductId: productID,
            Quantity:  quantity,
        })
        if err != nil {
            st, ok := status.FromError(err)
            if ok && st.Code() == codes.Unavailable {
                return nil, err // サーキットブレーカーに伝播
            }
            return nil, err
        }
        return resp.Available, nil
    })
    if err != nil {
        return false, err
    }
    return result.(bool), nil
}

非同期通信（イベント駆動）

claude "注文確定時にKafkaイベントを発行し、payment-serviceとnotification-serviceが
消費する仕組みを実装してください。
要件:
- イベントスキーマ: CloudEvents v1.0準拠
- Exactly-once semantics（Kafkaトランザクション使用）
- Dead Letter Queue対応
- スキーマバリデーション（Avro/JSON Schema）"

Claude Codeマイクロサービス開発のアーキテクチャ全体図

Sagaパターンの実装

分散トランザクションが必要な場合、Claude CodeにSagaパターンの実装を依頼できます：

claude "注文処理のSagaオーケストレーターを実装してください。
ステップ:
1. 在庫予約（product-service）
2. 決済実行（payment-service）
3. 注文確定（order-service）
4. 通知送信（notification-service）
各ステップの補償トランザクション（ロールバック）も実装してください。"

package saga

type OrderSaga struct {
    productClient      ProductClient
    paymentClient      PaymentClient
    orderRepo          OrderRepository
    notificationClient NotificationClient
}

type SagaStep struct {
    Name       string
    Execute    func(ctx context.Context) error
    Compensate func(ctx context.Context) error
}

func (s *OrderSaga) Execute(ctx context.Context, order *Order) error {
    steps := []SagaStep{
        {
            Name: "reserve_inventory",
            Execute: func(ctx context.Context) error {
                return s.productClient.ReserveInventory(ctx, order.Items)
            },
            Compensate: func(ctx context.Context) error {
                return s.productClient.ReleaseInventory(ctx, order.Items)
            },
        },
        {
            Name: "process_payment",
            Execute: func(ctx context.Context) error {
                return s.paymentClient.Charge(ctx, order.UserID, order.TotalAmount)
            },
            Compensate: func(ctx context.Context) error {
                return s.paymentClient.Refund(ctx, order.UserID, order.TotalAmount)
            },
        },
        {
            Name: "confirm_order",
            Execute: func(ctx context.Context) error {
                return s.orderRepo.UpdateStatus(ctx, order.ID, OrderStatusConfirmed)
            },
            Compensate: func(ctx context.Context) error {
                return s.orderRepo.UpdateStatus(ctx, order.ID, OrderStatusCancelled)
            },
        },
        {
            Name: "send_notification",
            Execute: func(ctx context.Context) error {
                return s.notificationClient.SendOrderConfirmation(ctx, order)
            },
            Compensate: func(ctx context.Context) error {
                return nil // 通知は補償不要
            },
        },
    }

    var completed []SagaStep
    for _, step := range steps {
        if err := step.Execute(ctx); err != nil {
            // 補償トランザクション実行（逆順）
            for i := len(completed) - 1; i >= 0; i-- {
                if compErr := completed[i].Compensate(ctx); compErr != nil {
                    log.Error("compensation failed",
                        "step", completed[i].Name,
                        "error", compErr,
                    )
                }
            }
            return fmt.Errorf("saga failed at step %s: %w", step.Name, err)
        }
        completed = append(completed, step)
    }
    return nil
}

実践④：テスト戦略

マイクロサービスのテストは、単体テスト・統合テスト・契約テスト・E2Eテストと多層になります。Claude Codeはこれらすべてのテストコード生成を支援します。

契約テスト（Pact）

claude "order-serviceとproduct-service間のPact契約テストを作成してください。
テスト対象:
- CheckInventory API
- ReserveInventory API
Consumer側（order-service）とProvider側（product-service）の両方を生成"

統合テストの自動生成

claude "order-serviceの統合テストを作成してください。
要件:
- testcontainersでPostgreSQLとKafkaを起動
- テストデータはファクトリパターンで生成
- 並列実行対応（テスト間でデータが干渉しない設計）
- カバレッジ80%以上を目標"

実践⑤：可観測性（Observability）の実装

マイクロサービスの運用で最も重要なのは可観測性です。Claude Codeを使えば、OpenTelemetryベースの計装を効率的に実装できます。

分散トレーシング

claude "全サービスにOpenTelemetryの分散トレーシングを導入してください。
要件:
- gRPCインターセプターで自動計装
- Kafkaメッセージにトレースコンテキストを伝播
- カスタムスパンでビジネスロジックの処理時間を計測
- Jaegerにエクスポート"

メトリクス・ログ統合

claude "Prometheus用のカスタムメトリクスを各サービスに追加してください。
メトリクス:
- リクエストレイテンシ（p50/p95/p99）
- エラーレート（ステータスコード別）
- サーキットブレーカーの状態
- Kafkaコンシューマーのラグ
- ビジネスメトリクス（注文数/決済額/在庫回転率）"

SES案件でマイクロサービススキルを活かすポイント

需要の高いスキルセット

2026年のSES市場では、以下のマイクロサービス関連スキルが特に高単価で取引されています：

スキル	月単価目安	需要動向
gRPC + Protocol Buffers	75〜90万円	急増
Kubernetes + サービスメッシュ	80〜100万円	高止まり
イベント駆動（Kafka/EventBridge）	70〜85万円	急増
分散トレーシング（OpenTelemetry）	75〜90万円	増加
DDD + CQRS/Event Sourcing	80〜95万円	増加

面談でのアピールポイント

Claude Codeを使ったマイクロサービス開発の経験は、以下の形でアピールできます：

設計力：「AIツールを活用してドメイン分析を効率化し、適切なサービス境界を設計した経験があります」
実装力：「サービス間通信のパターン（同期gRPC・非同期Kafka）を状況に応じて使い分けています」
品質意識：「契約テスト・統合テストを含む多層テスト戦略で品質を担保しています」

まとめ

Claude Codeを活用することで、マイクロサービス開発の「設計→実装→テスト→運用」全工程を大幅に効率化できます。

特にSESエンジニアにとっては、マイクロサービスのスキルセットは単価アップの重要な武器です。Claude Codeで学習コストを下げながら、実践的なスキルを身につけましょう。