ハーネスエンジニアリングとは

こんな経験ありませんか

• Claude を入れてみたけど、思ったほど仕事してくれない
• 同じ質問でも、人によって AI の回答品質がバラバラ
• プロンプトを磨いたのに、結果はあまり変わらない

モデルを新しくすれば解決する、とは限らない

差を生んでいるのは何か

同じ Claude を使っているのに、人やプロジェクトで結果が違う。
違うのはモデル本体ではなく、その "周り" の仕組み

"モデルを動かす外側の仕組み全般" を総称して ハーネス と呼ぶ

ハーネスの定義は、まだ揺れている

ハーネスエンジニアリングは新しい言葉。捉え方は発表者ごとに異なる。

• "モデル以外のすべて" と広く捉える立場
• "LLM を効果的に動かす仕組み全般" と絞る立場
• 組織・顧客接点まで含めて語る立場

共通するのは "モデルの外側が品質を決める" という認識

ハーネスの中身

モデルの "外側" すべてがハーネスの対象

自分がやっていること

Claude Code を日々運用する中で作っているもの

• CLAUDE.md /branch-create → /commit-ja → /push-ja → /pr-create の作業順序を宣言
• カスタムスキル SRE業務をコマンド化
  • (/sre-issue-workflow、/create-sre-issue、/check-securityhub-cve)
• フック コミットメッセージが feat: / fix: / docs:... 形式でなければ deny
• メモリ 標準機能で運用（以前は SQLite で自前管理）

これ全部、ハーネスエンジニアリング

でも、よくある落とし穴

「ルールファイルを整備する」だけで満足してしまう

• CLAUDE.md に大量のルールを書く
• スキルをたくさん作る
• で、それって本当に効いてる？

書いた側の "気持ち" で終わっていないか。

本丸は "評価" (Eval)

ハーネスを測る仕組みを持たないと、改善ループが回らない

1. エージェントの出力を記録する
2. 良し悪しを定量評価する（ルーブリック / LLM-as-a-Judge）
3. データを元に CLAUDE.md・スキル・プロンプトを改善する
4. 再評価して効果を確かめる

測れないものは、育たない

まとめ

1. モデルだけでは決まらない 品質は外側の設計で決まる
2. ルール整備は入口 CLAUDE.md やスキルは第一歩にすぎない
3. 評価まで回して初めて"工学" 感性から工学へ

まだまだ模索中です。
評価の目を一緒に育てていきましょう。

Appendix: 理想の CLAUDE.md

短く・構造化・普遍的に

• 200行以下 長いほど遵守率が下がる（指示の"枠"は150〜200個が限界）
• WHY / WHAT / HOW で構造化 目的 → 構成 → 運用の順に書く
• 広く適用されるもののみ プロジェクト固有の罠・運用ルールを優先
• 詳細は別ファイルへ 本体は"索引"、詳細は rules/ に分割
• 強制できるものは Hook / Lint へ フォーマット指示は機械に任せる

「この1行を消したら Claude が間違えるか？」で No なら削る

Appendix: どう評価するのか

軽量 → 本格の 3段階 で考える

段階	方法	ツール例
1. 手動	使った本人がで記録	スプレッドシート
2. ゴールデンデータセット	期待入出力ペア10〜30件を LLM-as-a-Judge で自動採点	Promptfoo / DeepEval
3. Eval 基盤	本番トレースをルーブリックで連続評価	Braintrust / Langfuse

測る対象: タスク成功率 / 正確性 / 一貫性 / コスト・速度

まずは "CLAUDE.md 変更前後で10件流して差分を見る" から