ハーネスエンジニアリングとの向き合い方 — ルールファイルを超えて開発プロセスを設計する
2026 年 4 月、Findy が主催したオンラインイベント「Harness Engineering 入門 〜 AI エージェントを制御するアプローチ〜」が開催された。r.kagaya 氏の登壇「エージェントの開発環境を内製して気づいた『これもハーネス』」は参加者から「レベル高すぎた」と評されるほど反響を呼んだ。本記事では、r.kagaya 氏が公開した SpeakerDeck 資料「ハーネスエンジニアリングにどう向き合うか 〜ルールファイルを超えて開発プロセスを設計する〜」をもとに、ルールファイルを超えたハーネスエンジニアリングの考え方を整理する。 イベント概要 【Harness Engineering 入門】AIエージェントを制御するアプローチ（connpass #388471）は、AI エージェントによる開発が広まる中でハーネス設計がどのような意味を持つかを掘り下げるイベント。対象は AI エージェントを積極的に使っているエンジニア、チーム開発に AI を取り込もうとしているエンジニア層だ。 複数の登壇の中で r.kagaya 氏のセッションは、自社でエージェントの開発環境を内製する過程で見えてきた「これもハーネスだ」という気づきを軸に、ルールファイル設定で終わらないハーネスエンジニアリングの本質を語った。 ルールファイルから始まるハーネスエンジニアリング 多くのエンジニアがハーネスエンジニアリングを始める入り口は CLAUDE.md などのルールファイル だ。「こういうコードを書いてほしい」「このコマンドは使わないで」といった制約を自然言語で記述し、AI の振る舞いをコントロールする。 1 2 3 4 # CLAUDE.md の例 ## Bash コマンドの必須ルール - `&&` でコマンドを繋がない - `/tmp` を使わない（`.claude/temp/` を使う） この段階では「うまく動くルールを育てる」フェーズであり、試行錯誤でルールを追加・削除していく。しかし、ここで止まってしまうと 本当の意味でのハーネスエンジニアリング には到達できない。 ルールファイルの限界 ルールファイルだけに依存したアプローチには構造的な限界がある。 課題 内容 変更の影響が不透明 あるルールを変えたとき、どの程度・どの方向に結果が変わるか測定できない 劣化の検知が困難 モデルのアップデートや使い方の変化でルールの有効性が静かに落ちる 再現性の欠如 同じルールで試しても毎回違う結果が出る場合の原因特定が難しい スケールしない チームが大きくなるほど「誰がどのルールを管理しているか」が曖昧になる ルールファイルを超えた視点：開発プロセスとして設計する r.kagaya 氏が提示したのは、ハーネスエンジニアリングを「ルールを書く行為」ではなく 「開発プロセスを設計する行為」 として捉え直す考え方だ。 ...