AI開発でユーザーの判断軸が効いた1日 — Claude × Copilot と作るインフラの現実

AI (Claude) と Copilot と一緒に 1 日開発作業をして、何度も自分が引き戻した場面を振り返る。

AI が全部やってくれるわけではないし、かといって AI は飾りでもない。ちょうど中間の、「人間の判断軸 × AI の実行速度 × 複数視点のレビュー」の三層構成で品質が決まる、というのが実感できた 1 日だった。

この日やっていた作業の概要

この日は、AWS 上のマイクロサービス基盤を対象に、以下の作業を進めていた。

• ECS Blue/Green デプロイの設計と Terraform 実装 — dev/stg/prod すべての環境に展開できる共通テンプレートの構築。AWS CodeDeploy を使ったダウンタイムゼロのデプロイ方式を採用。
• GitHub Actions CI パイプラインの整備 — Terraform の plan/apply を自動化し、PR ごとに差分レビューができる仕組みの構築。
• Claude Code スキルの設計 — blue/green 運用（deploy / rollback / terminate-blue）を 1 つのスキルにまとめる設計作業。
• 既存アプリ（LP）の構成整合 — 他サービスと統一した構成を維持しつつ、不要な変更を避けるための方針整理。

これらを Claude と対話しながら進める中で、Claude が誤った方向に走るたびに自分が正しく軌道修正した、という場面が 1 日で 7 回あった。

今日、Claude を正しく引き戻した場面

今日 1 日だけでも、Claude がサボったり走りすぎたりしたところを自分が正しく引き戻した場面がいくつもあった。

1. rolling update に寄せようとしたのを「本番を見越せ」と却下

ECS への blue/green deploy をどう実現するか、最初 Claude は「ECS rolling update で検証する」と提案してきた。しかし今作っているのは dev 環境だけでなく stg/prod にも展開する前提のテンプレートだ。本番ワークロードで数十秒のダウンタイムを許容するなんてあり得ないので却下。CodeDeploy ECS Blue/Green を採用する判断に切り替えた。

dev 環境だから妥協しても OK、という判断は「本番で効いてくる運用軸」を持っていないと出てこない。

2. CI の偽グリーンを「SUCCESS を鵜呑みにするな」で発見

terraform plan | tee plan_output.txt というシェルが GitHub Actions の job 定義にあった。set -o pipefail がないと、右側の tee の exit code (0) が使われてしまい、左の terraform plan が validation エラーで失敗していても job は SUCCESS を返す。

実際に一度これで偽グリーンをすり抜けそうになり、「CI が SUCCESS でも実ログを目視しろ」というルールを作った。set -euo pipefail + shell: bash を徹底するというべし/べからずに反映。

3. スキル設計で 4 分散 → 1 統合への戻し

blue/green 運用スキルを設計するとき、Claude は最初「preflight / deploy / rollback / terminate-blue の 4 つに分散するのが良い」と提案してきた。でもそれは「1 つのデプロイのライフサイクルを跨いで連続的に使う概念」なので、1 スキルにサブコマンド方式でまとめた方が自然。slot 節約にもなる。これも戻した。

4. /api/inquiry 削除の 2 段階の暴走

LP リポジトリにある legacy 気味の API エンドポイントについて、Claude は 2 段階で暴走した。

• 第1段階: 「fixu-lp は DB 接続自体を削除する方が正しい」
• 第2段階: 「WRITE は不要、/api/inquiry は legacy 削除候補」

どちらも訂正した。正しくは:

• LP は SEO と未登録ユーザー向けに DB READ が必要
• 統計情報や未登録ユーザーからの問い合わせ（営業リード情報）で DB WRITE も完全否定はできない
• 何より LP 独自の構成を作る労力は避けたい。他アプリと同じ構成のままにする

この「個別最適化より uniformity を優先する」という原則は、横展開を見据えたテンプレート化で特に効いてくる。

5. 作業開始時のアラインメント不足を指摘

blue/green 実装を開始するとき、Claude はすぐに実装に走ろうとした。結果、サブセッション側で rolling update を提案してきて、やり直し。「設計判断が多いタスクでは、10-15 分のアラインメント会議を先に挟んで 6-8 個の論点を詰めてから走る」というルールにした。

6. SSM 化と M1 の矛盾を先回りで察知

GitHub Environments に手動で変数を設定する作業（M1）を計画していたが、次のマイルストーンで AWS Secrets Manager / SSM Parameter Store への一元化も予定している。M1 を先にやると、その設定は SSM 化のタイミングで削除される → 二度手間。Claude は気づいていなかったが、指摘したら「確かにその通り」と plan を見直してくれた。

7. uniformity > optimization の原則提示

上記の LP 構成の話にも通じるが、「この repo だけ特別扱い」を作ると運用が破綻する。最適化より統一性を優先するという原則を明示したら、Claude の提案が全体的に筋の通ったものに変わった。

これらに共通する構造

どれも「エンジニアリングの Why」や「運用で効いてくる判断軸」を持っていないと出てこない指摘だった。Claude はコードや手順を回せても、「何故そうするのか」「将来どうなるのか」の軸は人間から提供してもらって初めて正しく動ける、というのが正直なところ。

Copilot レビューも効いている

今日の作業では、GitHub Copilot が PR に対して 4 ラウンド以上のレビューを出してくれた。Copilot 自身も前後矛盾したり（-lock=false を追加しろと言った次のラウンドで「-lock=false は危険」と言い換える等）、的外れな指摘をしたりする。

それでも、複数の視点でクロスチェックが入ることで、single AI の盲点がかなり潰せる。人間レビューだけ、AI レビューだけ、のどちらにもない強さがある。

今日潰せたもの:

• jq の二重クォートで JSON 不正になる罠
• Terraform の length(null) / trimspace(null) が短絡評価されない罠
• ALB listener rule に host_header 条件がなく他サービスに吸い込まれるリスク
• ECS service の ignore_changes に desired_count がない

どれも Copilot が拾ってきた。自分と Claude の 2 者だけでは見落としていた可能性が高い。

今後のスタンス

Claude に期待する振る舞い（メモリに蓄積中）:

• 過信せず、不確かなところは「確信できない」と正直に言う
• 走る前にアラインメントを取る（この日の反省を受けて）
• ユーザーの判断軸を尊重し、AI の提案を絶対化しない
• エラーや矛盾を隠さず早めに上げる
• メモリに学びを蓄積して次回以降に反映する

まとめ

AI-assisted development の現実的な姿は、「AI が全部やる」でも「AI は補助」でもなく、「人間の判断軸 × AI の実行速度 × Copilot の多視点レビュー」の三層構成で品質が決まる。

今日はそれを 1 日分の実体験として強く実感した。