ハーネスエンジニアリングの費用対効果：設定ファイルへの投資が工数削減につながった実例
この記事について
「CLAUDE.mdやルールファイルを整備する時間は、最初は無駄に感じた」というのが正直なところです。
サイトを構築するのに直接関係のないファイルを作るよりも、実際のコードや記事を書いた方が進捗が出る気がしていました。しかし3ヶ月間を通じて、その感覚は変わりました。この記事では、ハーネスを整備する前と後で何が変わったかを具体的に書きます。
ハーネスを整備する前に起きていたこと
AIが毎回同じ間違いをした
同じ種類の作業を依頼するたびに、AIが同じ判断を誤ることがありました。例えば、日本語と英語の記事を同時に作成する際、「英語の一人称はIのみ、weは使わない」というルールをAIに適用させるために、毎回同じ説明を指示に含める必要がありました。
一度説明しても、次の記事を依頼するときにはまた同じ間違いが起きました。
同じ説明を繰り返した
コードの変更をAIに依頼するたびに、「このサイトはAstro + Starlightで構築されている」「日本語が基準でURLのパスはこの形式にする」「既存のナビゲーションは変更しない」といった前提条件を毎回説明し直していました。
一つの依頼に対して、前提条件の説明が本来の指示と同じくらいの量になることもありました。
AIの変更をレビューする時間が長かった
前提条件を伝え切れていないまま変更を依頼したため、AIが意図しない変更を加えることがありました。例えば、一つのファイルを変更する指示で、関連する別のファイルも同時に変更されていた、というケースがありました。これを確認するためのレビュー時間が、変更の実施時間より長くなることもありました。
ハーネスを整備した後に変わったこと
同じ間違いが減った
「英語の一人称はIのみ」「既存のUIは変更しない」「スラッグの形式はblog/〇〇にする」といったルールをCLAUDE.mdとルールファイルに書いてからは、毎回説明し直す必要がなくなりました。AIはセッションの開始時にこれらのファイルを参照し、ルールに従って動作するようになりました。
説明なしで進められる作業が増えた
前提条件をハーネスに書いておくことで、新しい記事や変更の依頼に前提条件の説明を含めなくても、AIが適切に対応するようになりました。依頼の文章が短くなり、意図が伝わりやすくなりました。
レビューの手間が減った
AIが変更を加える範囲を「このファイルのみ」「このコンポーネントのみ」と限定するルールをハーネスに書いたことで、意図しない変更が減りました。変更後のレビューで確認する箇所が絞られ、レビューに使う時間が短くなりました。
投資とリターンの感覚
ハーネスの整備に費やした時間は、最初の1〜2週間に集中していました。
CLAUDE.mdの初期版を作るのに数時間、個別のルールファイルを整備するのに合計で1日程度かかりました。その後も、新しい問題が見つかるたびにルールを追加・修正する時間は発生しています。
一方で、毎回の説明が不要になったことで節約できた時間は、1〜2週間で整備コストを回収できる規模でした。正確な時間を測定したわけではないため、傾向としての説明になりますが、投資に対するリターンはあると感じています。
どのルールが効果的だったか
すべてのルールが同じ効果を持つわけではありませんでした。効果が大きかったルールは、次の条件を満たすものでした。
- 繰り返し同じ問題が起きていた
- ルールの内容が具体的で、AIが判断しやすかった
- 守られているかどうかを確認しやすかった
逆に、抽象的な方針を書いたルールや、適用条件が曖昧なルールは、効果が限定的でした。ルールを書く際に「これが守られていない場合の具体例は何か」を考えることが、効果的なルール作成につながります。
まとめ
ハーネスへの投資は、最初は直接の成果が見えにくい作業です。しかし同じ種類の作業を繰り返す場合、整備コストは比較的早く回収できます。ハーネスを整備するかどうかの判断基準として、「この問題は今後も繰り返し起きるか」という問いが有効です。一度きりの問題であれば、その都度対処する方が効率的です。繰り返す問題であれば、ルールとして書いておく価値があります。