【ITニュース解説】Your CLAUDE.md is full of wishes: 7 rungs that make a rule stick

システムエンジニアとしてプロジェクトを進める中で、私たちは様々な「ルール」を設定する。たとえば、「絶対に本番環境に直接コミットしない」「テストで本番データは使わない」といったものだ。これらのルールは、過去に何か問題が起こった経験から生まれた、非常に大切な教訓が詰まっている。しかし、残念ながらこれらのルールが、ただの「願い事」になってしまい、誰も守っていない状況がしばしば発生する。

なぜルールが守られなくなってしまうのだろうか。その答えは、「そのルールが破られたときに、本当に何か問題が発覚するか？」という点にある。もしルールが破られても、誰も気づかなかったり、システムが何の反応も示さなかったりするならば、それは実質的に守る必要のない「願い事」と変わらない。プログラミングの現場では、ルールが文字として書かれていても、その裏に機械的なチェックがなければ、時間の経過とともに忘れ去られ、違反が頻発するようになる傾向がある。

これは筆者の実験でも裏付けられている。自身のプロジェクトで設定したルールを調べたところ、機械的なチェックによって違反が検出されるルールは、何千回もの操作の中で一度も破られなかった。しかし、人間の記憶やレビューに頼るだけのルールは、30%から45%もの高い確率で破られていたのだ。しかも、時間の経過とともに順守率が低下していく傾向も見られた。この結果は、人間の記憶や意識だけに依存したルールがいかに脆いかを示している。

では、どうすればルールを「願い事」ではなく、確実に守られるものにできるのだろうか。その鍵は、ルールを「システム的に守らせる仕組み」に移行させることにある。この仕組みは「ガード」と呼ばれるが、単純にガードを追加するだけでは不十分で、そのガードにも「段階（Rung）」がある。ルールの性質に応じて、適切な段階のガードを導入することが重要だ。

ガードには大きく分けて、違反を「不可能にする」段階と、違反を「検出する」段階がある。より高い段階のガードほど、ルールの順守を確実にする。

最初の3つの段階は、そもそも違反を「不可能にする」仕組みだ。

1. 再生（Regeneration）: 特定のファイルが手作業で編集されることを禁止するルールがあるとする。しかし、もしそのファイルがシステムによって自動生成されるものならば、手動で変更しても次のビルドやデプロイの際に上書きされて消えてしまう。この場合、手動での変更は「持続しない」ため、ルールは自然と守られる。たとえば、APIの仕様書からクライアントコードを自動生成する場合などがこれに当たる。ルールを強制する特別な仕組みがなくても、変更が消えてしまうので誰も手を出さなくなる。

2. アクションのブロック（Blocked at the action）: 特定の危険な操作を、それが実行される前にシステムがブロックする仕組みだ。例えば、「絶対にmaster（またはmain）ブランチに直接コミットやプッシュしない」というルールがあるとする。Gitには、特定のブランチへの直接プッシュを拒否する「ブランチ保護」機能がある。また、自作のスクリプトでGitコマンドをフックし、特定のコマンドを検出したら実行を拒否することもできる。これにより、意図しない操作が物理的に不可能になる。

3. コンパイルの拒否（Will not compile）: プログラミング言語の特性を利用し、不正なコードの書き方を「文法的に間違っている」状態にしてしまう方法だ。例えば、「ファイルパスは文字列を連結して作ってはいけない」というルールがあるとする。もし、ファイルパスを受け取る関数が、文字列ではなく「安全なパス型」を要求するように設計されていれば、不適切な方法で生成されたパスは型エラーとなり、プログラムがコンパイルできなくなる。コンパイルエラーはプログラムが実行される前に発見されるため、非常に強力なガードとなる。

これら3つの段階は、ルールが破られること自体をシステムが物理的、または論理的に不可能にする。

次の段階は、違反を「検出する」仕組みだが、より早期に、より確実に発見できるものから順に並ぶ。

4. ASTガード（AST guard）: コードの構文解析木（Abstract Syntax Tree: AST）を解析し、特定の構造的なパターンが存在しないことを検証するテストだ。例えば、「データベースへの書き込みは全てリポジトリパターンを経由する」というルールがあったとする。このルールを、特定のハンドラーが直接データベースドライバーを呼び出していないかをASTを解析してチェックするテストを作成することで、検出できる。単なる文字列検索とは異なり、リファクタリングや変数名変更にも強く、より信頼性の高いチェックが可能だ。これは通常、CI/CDパイプライン（コードがコミットされた後、自動的にテストやビルドを行う仕組み）で実行される。

5. クロスアーティファクトガード（Cross-artifact guard）: 複数の異なる設定ファイルやコード間で、矛盾がないかをチェックするテストだ。例えば、「コードで定義されている全ての環境フラグが、デプロイ設定ファイルにも正しく宣言されていること」というルールがあるとする。コードとデプロイ設定という、それぞれ独立したファイルの内容を比較し、不一致があればエラーを出す。これも通常、CI/CDパイプラインで実行され、設定ミスによる本番環境でのトラブルを未然に防ぐ。

6. ランタイム検出器（Runtime detector）: プログラムが実際に実行されている最中に、特定の条件を検出してログに出力したり、アラートを上げたりする仕組みだ。これは、テスト環境では再現が難しい、本番環境特有のデータや状況に依存するルールをチェックする際に有効だ。例えば、「キャッシュミスの処理とキャッシュエラーの処理を同じにしてはならない」というルールのような、プログラムの「意図」に関わる部分は、実行時の振る舞いを観察することでしか検出できない場合がある。しかし、これは問題が「発生した後」に気づくことになるため、より上位のガードよりは優先度が低い。

そして、最も低い、機械的なチェックが困難な段階がこれだ。

7. 常に読み込まれる場所に書かれている（Written where it always loads）: 意味や意図に関わるルールなど、機械的なチェックが非常に難しいものだ。例えば、「キャッシュミスの処理とキャッシュエラーの処理は意図が異なるため、同じにしてはならない」といったルールは、コードの構文や構造では判別しづらい。このようなルールは、ドキュメントやコメントとしてコードの近くに記述するしかない。これはあくまで人間の注意に依存するため、最も順守率が低い傾向にある。

システムエンジニアを目指す皆さんが、これらの知識を自身のプロジェクトに活かすためには、まず自分のプロジェクトで設定されているルールを一つ一つ見直してみることが重要だ。そして、それぞれのルールが「もし破られたら、何が失敗するのか？」と問いかけてみよう。もし何も失敗しないのであれば、それは「願い事」に過ぎない。

次に、そのルールを可能な限り高い段階のガードに移行できないかを検討する。例えば、「手動で編集してはいけないファイル」に関するルールは、もしそのファイルが自動生成できるのであれば、Rung 1の「再生」によってルールを不要にできる。特定の操作を禁止するルールであれば、GitのフックなどのRung 2「アクションのブロック」を導入することで、物理的に不可能にできるかもしれない。型システムを活用すればRung 3も可能だ。

そして、ルールの順守状況を定期的に測定することも忘れてはいけない。単一の順守率を見るだけでなく、期間を区切ってその変化を追うことで、ルールの順守率が低下していることに早期に気づき、対策を打つことができる。

最終的に、ルールの実効性は、それが破られたときに「システムが何らかの形で失敗を教えてくれるか」にかかっている。人間が意識して守るべきルールは必ず存在するが、可能な限り機械的な仕組みでルールを強制し、開発者が本来集中すべきタスクに集中できる環境を整えることが、質の高いソフトウェア開発につながるのだ。