はじめに

最近、Claude Codeを使う時間が増えるにつれて、いくつかの運用上の課題が見えてきた。コンテキストが膨らむ問題、テストケースの品質を一定に保つ難しさ、そしてローカル開発環境のコスト問題。今回はこの3つについて、実際に手を動かして試した結果をまとめてみる。

1. tmuxのタブ分割でClaude Codeのコンテキストを制御する

Claude Codeを使い込んでいると、必ず「コンテキストが重くなってきたな」という瞬間が来る。実装・レビュー・調査・定型業務をひとつのセッションでこなしていると応答精度が落ち、/compactが走ると直前の文脈が要約に丸まってしまう。

tmuxのウィンドウ（タブ）ごとに役割を分けるアプローチを試してみた。

ウィンドウ1: 実装タスク専用のClaude Codeセッション
ウィンドウ2: コードレビュー専用
ウィンドウ3: 調査・リサーチ専用
ウィンドウ4: リファクタリング専用

実際に動かしてみると、セッション間の「情報の橋渡し」をどうするかが肝だった。実装セッションで決めたAPI設計の要点を中間ファイルに書き出して、レビューセッションに渡す方法が一番素直に機能した。

# 実装セッションで設計メモを出力
cat > /tmp/design_notes.md << 'EOF'
## API設計メモ
- エンドポイント: POST /api/users
- 認証: JWT Bearer
- バリデーション: zodスキーマで統一
EOF

# レビューセッションで参照
claude "design_notes.mdの設計方針を踏まえてコードレビューしてください"

ハマったのは、実装セッションでコミットしたものをレビューセッションが知らない状態になること。セッション切り替え時にgit fetch --pruneを習慣にすることで解消した。コンテキストウィンドウの節約効果は体感できて、特に長時間セッションで応答の精度が保たれる感覚がある。

2. 「7人の意地悪なQA」でテストケースの観点を型化する

テストケースをAIに書かせること自体はもう当たり前になった。問題は「毎回同じ観点で同じ品質を維持すること」で、担当者が変わるたびにテストの粒度がバラつくのが悩みだった。

Claude Codeのシステムプロンプトに「役割の異なるQAエンジニア7人」を仕込んで、それぞれの視点でテストケースをレビューさせる手法を試してみた。自分で組み立てたプロンプトの骨格はこんな感じ：

あなたは以下の7人のQAエンジニアとして、テストケースの観点漏れを指摘してください：

1. 境界値オタク: 境界値・異常値・ゼロ値・マイナス値のケースを執拗に探す
2. セキュリティ番長: SQLインジェクション・XSS・認証回避を常に疑う
3. 並行処理マニア: 同時アクセス・レースコンディション・タイムアウトを重点チェック
4. データ整合性厳格派: DBの整合性・外部キー・トランザクション境界をツッコむ
5. UI/UX懐疑論者: ユーザーが絶対やらないだろう操作を必ずやろうとする
6. 環境差異探偵: 本番と検証環境の差・タイムゾーン・OS差異を疑う
7. 回帰テスト番人: 「以前のバグ修正で壊れてないか」を常に確認する

これを使ってECサイトの在庫管理APIのテストケースを作ったら、これまで見落としていた「在庫数が同時に0になるケース（並行処理マニアが発見）」と「タイムゾーンをまたいだ在庫予約の日付ズレ（環境差異探偵が発見）」が出てきた。QA担当がいないプロジェクトでも観点を一定に保てるようになったのが地味に大きい。

3. LocalStack有料化 → MiniStack + Terraformへの乗り換え

2026年3月のLocalStack Community Edition廃止は結構な衝撃だった。個人開発でterraform applyのたびに実AWSを叩くのが怖くて使い続けていたので、代替を探す必要に迫られた。

MiniStackはS3・DynamoDB・Lambda・SQSの基本操作なら問題なく動く。Terraformとの繋ぎ込みはendpoint設定だけで済む。

# MiniStack起動
pip install ministack && ministack start

# terraform/providers.tf
locals {
  is_local = var.environment == "local"
}

provider "aws" {
  region = "ap-northeast-1"

  dynamic "endpoints" {
    for_each = local.is_local ? [1] : []
    content {
      s3       = "http://localhost:4566"
      dynamodb = "http://localhost:4566"
      lambda   = "http://localhost:4566"
    }
  }

  skip_credentials_validation = local.is_local
  skip_metadata_api_check     = local.is_local
  access_key                  = local.is_local ? "test" : null
  secret_key                  = local.is_local ? "test" : null
}

試してみてわかったのは、S3のPre-signed URLの挙動がLocalStackと微妙に違うこと。この部分だけはモック関数を別途書く必要があった。Lambdaのコールドスタート挙動はローカルでは再現されないので、パフォーマンステストは引き続き実AWSでやる割り切りが必要。「完全な代替」ではなく「Terraformの構文確認とユニットレベルの動作確認用」として割り切ると使いやすい。

まとめ

今週特に実感したのは、AIツールを「どう使うか設計する」フェーズに入ってきているということ。Claude Codeはコンテキスト管理を意識しないと精度が落ちる。テストケース生成も、ペルソナを設計することで品質が安定する。ローカル開発環境も、ツールの変化に合わせた見直しが必要になっている。

「とりあえずAIに投げる」から「AIとどう協働するか設計する」への移行が、今の開発現場で起きていると思う。