みなさんこんにちは！アクセルラボでプラットフォーム開発・AI推進を担当している山本です。
前編では、cc-sdd による仕様策定（Phase 1）と Claude Code による実装（Phase 2）について解説しました。後編では、AI が書いたコードの品質をどう担保するか — ガードレールの構築（Phase 3）と開発全体の所感をお届けします。
Phase 3: ガードレールの構築
ここが一番伝えたいポイントです。AI がコードを書く速度は速いですが、人間がレビューするより速くコードが生成されるので、手動レビューだけでは追いつきません。
Lefthook — コミット時の自動検証
Lefthook は Go 製の Git hooks マネージャーです。設定はシンプルです。
# lefthook.yml pre-commit: parallel: true jobs: - name: lint glob: "**/*.{ts,tsx}" run: mise exec -- bun run lint - name: format glob: "**/*.{ts,tsx,json}" run: mise exec -- bun run format:check - name: typecheck run: mise exec -- bun run typecheck pre-push: jobs: - name: test run: mise exec -- bun run test
pre-commit で lint・format・typecheck を並列実行し、pre-push でテストを実行します。
これが AI 開発で特に効くのは、Claude Code が git commit するタイミングで自動的にチェックが走るからです。AI がコードを書いて、そのままコミットしようとしても、lint エラーや型エラーがあれば弾かれます。Claude Code はエラーを見て自動修正し、再コミットします。
つまり、人間が介在しなくても品質の最低ラインが保たれる仕組みです。
実際にガードレールが効いた例
ある機能の実装で、外部 SDK のベンダーファイル（minified JS + Wasm）をプロジェクトに配置した際、Lefthook の pre-commit が走りました。
🥊 lint ❯ ⚠ eslint(constructor-super): Expected to call `super()`. ⚠ eslint(no-unused-expressions): Expected expression to be used Found 4536 warnings and 0 errors. exit status 1 🥊 format ❯ Format issues found in above 7 files. exit status 1
ベンダーファイルの minified コードに対して oxlint が 4536 件の警告を出し、コミットが止まりました。Claude Code はこのエラーを検知し、lint/format コマンドにベンダーファイルの除外パターンを自動的に追加して解決しました。
{ "lint": "oxlint --deny-warnings --ignore-pattern 'packages/frontend/public/**' packages/", "format:check": "oxfmt --check \"packages/**\" \"!packages/**/public/**\"" }
人間が見なくても、ガードレールが問題を検知し、AI が自律的に修正する。これが理想のフローです。
GitHub Actions — CI でダブルチェック
Lefthook はローカルの検証ですが、PR 作成時には GitHub Actions でも同じチェックを実行します。
# .github/workflows/ci.yml jobs: lint-format: # oxlint + oxfmt typecheck: # tsc --noEmit (全パッケージ) test: # vitest run
3ジョブを並列実行し、全て通らないとマージできません。Lefthook をスキップしてしまった場合のセーフティネットです。
Devin Review — AI による PR 自動レビュー
Devin の Review 機能を GitHub に連携しています。PR を作成すると、Devin が自動でコードレビューを行い、型安全性の問題・エラーハンドリングの不足・命名の一貫性などを指摘してくれます。
人間のレビュアーが見る前に AI が一次レビューを済ませてくれるので、レビューの負荷が大きく下がりました。特に、Claude Code が生成したコードを別の AI（Devin）がレビューするという構造は、AI 同士のクロスチェックとして機能します。人間は Devin の指摘を踏まえた上で、ビジネスロジックやアーキテクチャの妥当性に集中できます。
実際にこのプロジェクトで Devin Review が検出した指摘の例です。
- 🔴 型ガードの論理演算子ミス:
||（OR）で書かれた条件が&&（AND）であるべきだった。条件が緩すぎて、必須フィールドが undefined のまま後続処理に流れる可能性があった - 🔴 Lambda タイムアウト設定の矛盾: Lambda のタイムアウト（60秒）が API Gateway の上限（29秒）を超えており、必ず 504 エラーになる設定だった
- 🟡 画像リサイズ処理の Promise が永遠に解決しない:
onerrorハンドラが未設定で、画像読み込み失敗時に Promise が永久にハングする - 🟡 ドキュメントと実装の乖離: コードを大幅に変更したのに CLAUDE.md のアーキテクチャ図が更新されていない
特に Lambda タイムアウトの指摘は、デプロイして初めて気づくタイプのバグなので、PR 段階で検出できたのは大きかったです。Devin は指摘するだけでなく、修正を反映したコミットを検知すると「✅ Resolved」と自動で解決マークを付けてくれるので、対応漏れも防げます。
PR テンプレート — AI 利用の透明性
## AI Usage <!-- AI（Claude Code等）を使用した場合、どの部分で活用したかを記載 -->
PR テンプレートに「AI Usage」セクションを設けて、AI がどの部分を書いたかを明記するルールにしています。レビュアーがどこを重点的に見るべきか判断しやすくなります。
ガードレール構成まとめ
入口のガードレール（コードを書く前）
- cc-sdd（仕様書） → 「何を作るか」を制約
- CLAUDE.md → 「どう作るか」を制約
出口のガードレール（コードを書いた後）
- Lefthook（pre-commit） → lint / format / typecheck を自動検証
- Lefthook（pre-push） → テストを自動実行
- GitHub Actions（CI） → PR時にダブルチェック
- Devin Review → AI による PR 自動レビュー（AI同士のクロスチェック）
- PRテンプレート → AI利用の透明性を確保
入口（仕様）と出口（検証）の両方でガードレールを設けることで、AI の生産性を最大化しつつ品質を維持できます。
開発してみての所感
よかったこと
- 初速が速い: cc-sdd の仕様書があることで、Claude Code が最初から的確なコードを書いてくれた
- 手戻りが少ない: 要件の Acceptance Criteria があるので「これで合ってる？」の確認が減った
- ガードレールが自動修正を誘発: Lefthook のエラーを見て Claude Code が自分で直すので、人間の介入が最小限
- CLAUDE.md が資産になる: AI のための指示書が、チームの開発ドキュメントとしても機能する
注意点
- cc-sdd の仕様書は人間が確認すべき: AI が生成した要件定義をそのまま信じると、スコープが広がりすぎることがある
- CLAUDE.md のメンテナンス: プロジェクトが進むにつれルールが増えるので、定期的な整理が必要
- ベンダーファイルの扱い: 外部 SDK の minified コードは lint 対象から除外する設定を事前にしておく
おわりに
「AI にコードを書かせる」というと、プロンプトの工夫に注目が集まりがちですが、実際にプロダクション品質のコードを AI で書くには 仕様で制約し、自動検証で品質を担保する仕組みの方が重要だと感じました。
cc-sdd + Claude Code + Lefthook + Devin Review というスタックは、AI コーディング時代の開発基盤として汎用的に使えると思います。ぜひ試してみてください。
本ブログを読んでいただきありがとうございます。 もし内容にご興味を持っていただけましたら、以下よりお気軽にお問い合わせ・ご応募ください。
アクセルラボでは採用を強化しています。 私たちの技術やビジョンに共感し、スマートホームの未来を共に創っていきたい方のご応募をお待ちしています。 👉お問い合わせ - アクセルラボ採用情報
