問題: レビューの「点」と本番の「線」のズレ

コードレビューは 1 つのプルリクエストの中で起きる。

  • ファイル A が変わった → ファイル A をレビュー
  • ファイル B が変わった → ファイル B をレビュー

でも本番は複数の変更が同時に動く。 ファイル A の変更とファイル B の変更が相互作用する。あるいは、3 週間前にマージされた機能と今日の変更が干渉する。レビューは個別の変更を見るので、この相互作用を検出しづらい。

もう 1 つの問題：レビューは「過去」を見ない。 昨日マージされたコードは完璧だった。だが今日、ライブラリがアップデートされたら、そのコードが脆弱性を持つようになるかもしれない。

レビューの瞬間では「正しかった」ことが、翌日には「危ない」になり得る。

解決: 運用の中に「継続的な品質確保」を組み込む

/schedule を使って定期的に自動実行される確認フローを作る。

パターン 1: 毎晩の統合テスト

毎晩 2:00 に実行:
1. main ブランチの全テストを実行
2. 本番環境相当の設定でビルド
3. パフォーマンス測定（P99 レイテンシ）
4. 脆弱性スキャン（既知の脆弱ライブラリ）

なぜ必要か。PR レビューの時点では「テストが成功した」。だが、複数の PR が同時にマージされると、統合時点で初めて問題が出る場合がある。また、ライブラリの自動アップデート（Dependabot など）が入った時点で、既知の脆弱性が新たに検出される可能性がある。

パターン 2: 週次のコンプライアンスチェック

毎週金曜 9:00 に実行:
1. ログ出力がチームのポリシーに合っているか
2. 機密データ（パスワード、トークン）がリポジトリに混ざってないか
3. 古い依存ライブラリが使われてないか
4. テストカバレッジが基準を満たしているか

なぜ必要か。個々の PR では「このコミットはポリシー違反していない」と判定される。だが累積すると、チーム全体として基準が緩んでいく。定期確認することで、ドリフトを早期に検出する。

パターン 3: 月次の設計監査

毎月第一月曜に実行:
1. 各モジュールの責務が明確か確認
2. 循環依存がないか検証
3. 過度に複雑な関数がないか抽出
4. 未使用コードが増えていないか検査

なぜ必要か。機能追加の時には「この機能だけの観点でいい設計か」が見られる。だが、3 ヶ月、半年と経つと、技術的負債が堆積する。一度に監査するのではなく、継続的に「設計の健全性」を測定する。

実装パターン: /schedule と /loop の組み合わせ

基本形: 定期実行

/schedule 毎日 02:00 実行:
  npm run test:integration
  npm run build:production
  npm run security:audit

各タスクは独立している。結果はレポートとして Slack に送信、または JSON ファイルとして記録される。

応用形: 長時間実行エージェント

単純な「実行してレポート」では気づかない問題がある。例えば：

  • パフォーマンス低下の累積 — 個々の PR では「10% 遅くなるだけ」だったが、10 個マージされると 50% 遅くなる
  • エッジケースの発見 — 通常のテストでは出ない、特定の条件下でのみ起きる問題

これらには /loop で長時間実行するエージェントが必要。

/schedule 毎週日曜 実行:
  /loop 負荷テスト (複数シナリオを 1 時間かけて実行)
    - 正常系: 1000 req/sec
    - スパイク: 5000 req/sec
    - 回復: 1000 req/sec に戻す

結果: メモリリークがあれば、1 時間の実行で検出される。個々の短時間テストでは見逃す。

チームの中での役割分担

誰が何を見る

PR レビュアー（人間）: その変更が「今この瞬間、コードとして正しいか」

毎日のチェック（自動）: 複数の変更が一緒に動くとき、問題が出るか

週次監査（自動）: ポリシーやスタンダードが保たれているか

月次監査（自動）: 設計としての健全性は崩れていないか

警告が来た時のアクション

例えば、金曜の定期チェックで「テストカバレッジが 80% から 75% に低下」という警告が来た。

人間が見るべきことは：

  • 「なぜ下がったのか」を判定する
  • 「下がるのは許容範囲か」を決める
  • 「新しい基準を設けるべきか」を検討する

ツールが自動実行した「測定」は情報。人間が下す「判断」は経営。

よくある質問

Q: 毎日レビュー会議をやるのと、自動チェックの違いは?

毎日会議は「人間の時間をたくさん使う」。自動チェックは「機械が休まず働く」。

例えば、セキュリティをレビューするために月 1 回 2 時間の会議をやるなら、自動チェックで「毎日 5 分で走る」方が効率的。人間は「自動チェックで引っかかった、重要そうな案件だけ」を深掘りする。

Q: 誤検知が多かったら?

多い。自動チェックは最初、ノイズだらけになる可能性がある。その時は「何が誤検知か」を 2-3 週間かけて分類して、ルールを調整する。これもまた「運用」。

Q: 本番環境で何かが起きた時は?

自動チェックはあくまで「事前確保」。本番で問題が起きたら、即座に対応する。その後、「なぜ自動チェックで検出できなかったか」を分析して、チェック内容に追加する。フィードバックループ。

最後に: 「品質」は瞬間ではなく、継続

PR レビューは「このコード、今いいか」を判定する場。

運用監視は「このコードベース、ずっといい状態を保てているか」を監視する場。

両方が必要。

片方だけでは：

  • レビューだけ → 本番での相互作用を見落とす、ライブラリ脆弱性を後から見つける
  • 運用監視だけ → 新規コードの設計が悪くても気づかない、負債が内部に溜まる

/schedule と /loop を組み合わせて「継続的な品質確保の仕組み」を作る。それがチーム全体の信頼度を上げる。

レビューは「点」。運用は「線」。線が結ぶものが、本当の品質。