チャットは 契約ではない。
言葉は何も留めておけない。ファイルが留める。

チャットだけで指示すると何が起きるか

INTRO · 2026

見慣れた場面だ。チャット欄に指示を書く。「このボタンの位置を直して」。しばらくして機械が答える。「修正が完了しました」。画面を開く。ボタンはそのままだ。問い詰めると機械は謝り、また「完了しました」と言い、ボタンはまたそのままだ。指示は無視され、報告は嘘になり、夜が消える。

この繰り返しの根は、機械の性格ではなく構造にある。チャットで渡した指示は、その会話が終わる瞬間に蒸発する。次のセッションの機械は昨日の約束を知らない。「完了と言う前に必ず確認して」という約束も、その会話の中だけで有効な使い捨ての念書だ。約束が引き継がれないから違反が繰り返される。検査を強制する装置もないので、機械は検査せず完了を宣言する。

解決の方向は一つだ。指示をチャットではなくファイルに書く。検査をお願いではなくスクリプトにする。合否を機械の言葉ではなく実行結果の数字（exit code）で判定する。この三つをリポジトリに常設すること。それがこの教本で扱うハーネスエンジニアリングのすべてだ。

趣味人の潔癖さではなく、業界の結論であることを示す証拠がある。あるコーディングベンチマークで、あるチームはモデルを一切変えず、周辺の仕組みだけを変えて点数を52.8から66.5へ、順位を30位から5位へ上げた。同じ頭脳、違う馬具。成果を決めたのはモデルではなくハーネスだった。

九つの作業場

FIELD NOTES · 2026

一人が運用してきた九つ前後の作業場で、ハーネスのファイル構成と実行方法を比較した。三つのリポジトリからなる決済サービス、家計簿、マッチングサービス、ゲーム、画像工房、通販サイト、いくつかの内部運用ツール、そしてこのサイトだ。

規模は極端に異なる。最大の作業場には作業員（エージェント）の定義が十個、手順書（スキル）が二十六個、検証スクリプトが八十一個あり、そのうちセンサーだけで五十七個だ。最小の作業場にはフックが一つだけある。そしてある作業場は「作業員0人」をミスではなく決定として文書に記した。ハーネスは大きいほどよいのではなく、作業場のリスクに合うほどよい。

規模が違っても部品は繰り返される。「完了を宣言する前に実測せよ」という手順書がほぼすべての作業場に移植され、セッションの記憶を守るフック群がほぼ同じ形で複製され、各スクリプトの冒頭には移植元の作業場が記されている。標準部品はすでにある。この教本はそれらの組み立て説明書だ。

読み方

MAP · 2026

順に読めばよい。01編は用語辞典で、ハーネス・エージェント・スキルとは何か、名前から整理する。02編は手で作る方法。五つのファイルで最小のハーネスを構築する。03編は同じ作業をClaudeにさせる方法だ。04編はこの教本の中心であるセンサーとゲート、虚偽の完了報告を構造で止める装置を扱う。05編はモデル配置。なぜすべての仕事に最高級モデルを使うべきではないのかを扱う。

前提は一つだけだ。コードに詳しくなくてもよい。フォルダを作り、テキストファイルに文章を書ければ始められる。実際、ハーネスの部品の大半はコードではなく文書だ。規則を書いた文書、役割を書いた文書、手順を書いた文書。コードが必要なところは03編の方法で機械にやらせればよい。

始める前に一文でまとめる。この教本の目的は機械を信頼することではない。信頼なしでも仕事が回るようにすることだ。信頼は人間同士の美徳であり、機械に必要なのは証拠だ。