部品の 名前から呼ぶ。
ハーネス、エージェント、スキル。そして残りの部品。

ハーネス — 機械に付ける馬具

GLOSSARY · 2026

ハーネス（harness）はもともと馬に付ける馬具だ。馬の力を殺すものではなく、その力を馬車につないで方向を与えるもの。AIハーネスも同じで、モデルの能力を囲む規則・権限・検証・記録の枠組みだ。ルビャンカシリーズで一度使った等式を再び出そう。エージェント＝モデル＋ハーネス。モデルは借り物の頭脳なので私には変えられないが、ハーネスはすべて私の手の中にある。

この言葉を作った開発者の定義は、意外なほど素朴だ。機械が失敗するたび、同じ失敗を二度とさせない装置を一つずつ作ること。装置は四つに分かれる。できることを減らし（制限）、すべきことを教え（情報）、正しく行ったか確かめ（検証）、間違ったら直す（修正）。この教本の全パーツは、この四本柱のどこかに属する。

実体は素朴だ。リポジトリの中のフォルダ一つと文書数個。慣例ではルートに憲法文書（CLAUDE.md、毎セッション自動で読む規則書）を一つ置き、隠しフォルダ.claude/の下に作業員定義（agents/）、手順書（skills/）、自動実行スクリプト（scripts/）、配線表（settings.json）を入れる。すべてテキストファイルだ。開いて読めるし、直せるし、消せる。

なぜファイルなのか。チャットの指示はセッションが終わると蒸発するが、ファイルは残るからだ。憲法文書は新しいセッションが開くたびに自動で機械の前に置かれる。同じ規則が百回のセッションで百回繰り返される。人が百回タイプしなくてもよい。だからハーネスエンジニアリングの最初の原理はこうなる。一度だけ言いたいことは、言わずに書け。

エージェント — 役割と権限を分けた作業員

GLOSSARY · 2026

エージェントは特定の役割を担う別の作業員だ。実体はやはりファイルで、Markdown文書一つが作業員一人になる。冒頭のfrontmatterに四つを書く。名前（name）、いつ呼ぶか（description）、渡す道具の一覧（tools）、使うモデル（model）。本文には役割と禁止事項を書く。

ぴんと来なければ思考実験を一つ。iPhoneアプリ、Androidアプリ、Web、サーバーの四系統からなるサービスを、一つのチャット窓口で全部進めるとしよう。断言するが、機械は三つのうちどれかをやる。作業を忘れるか、違う場所を直すか、虚偽報告をするかだ。機械の底には有能な秘書を演じようとする性格がある。初めから失敗を認めれば無能な秘書になるので、嘘を選ぶ。だから人間の組織と同じことをする。露店と一人会社を除けば、一人に全作業を任せる会社はない。人を雇い、分業させ、検査を別部門に渡す。エージェントを作るとは、その採用だ。

四項目で最も重要なのは道具の一覧だ。それが権限そのものだからだ。調べた作業場で最も美しい設計がここにあった。検証専任の作業員から修正道具のEditとWriteを丸ごと外していたのだ。読み取りと実行だけが可能な検査官は、こっそり修正してから合格したと報告する不正を、したくてもできない。規則で禁止するのではなく、構造で不可能にする。この教本を貫く原則だ。

構成の定型も実測で繰り返し見つかる。企画者は仕様だけを書きコードは禁止。実装者は承認された仕様があるときだけ作業する。検証者はコード修正禁止で報告のみ。そして視覚の正本を守る担当やコスト会計士などのドメイン守護者。核心は人数ではなく分離だ。計画する手、作る手、検査する手が、異なるファイルと権限に分かれていることだ。

スキル — 手順をファイルに固定したもの

GLOSSARY · 2026

スキルは繰り返す手順を文書に固定したものだ。フォルダ一つにSKILL.mdを一つ。冒頭に名前と発動条件、本文に段階ごとの手順と禁止事項を書く。エージェントが「誰がするか」なら、スキルは「どの順番でするか」だ。

会社のたとえを続けよう。エージェントが採用なら、スキルは会社の業務規則集だ。新人が来ても報告書の品質が保たれる会社は、人ではなく手順書が働く会社だ。実際の発動はこうなる。機械が「全部終わりました」と打つ瞬間、その口癖が引き金になり手順書が割り込む。ビルドを回したか。出力を付けたか。昨日の結果を今日の証拠にしていないか。三つを埋めるまで完了という言葉を言い終えられない。この性格矯正がスキルの本質だ。機械は完了と答えるようにしつけられている。口癖自体は直せないので、それが出てくる道に検問を置く。

「そのくらい自分でやるだろう」と思ったら操縦席を想像してほしい。飛行時間二万時間の機長も、離陸前にはチェックリストを声に出して読む。熟練を疑うからあるのではなく、熟練者にも見落とす日があると分かっているからある。スキルも同じだ。そしてこの手順書の実体は十行のテキストファイルにすぎない。名前一行、「全部終わりました」「すべて通過」などの引き金となる言葉、そして三行のチェック。それだけだ。

九つの作業場で最も多く移植された四つのスキルが事実上の標準だ。一つ目は完了宣言ゲート。「全部終わりました」の直前に発動して実測の証拠を要求する。二つ目は体系的デバッグ。推測による修正を禁止し、再現・隔離・仮説検証の順番を強制する。三つ目は調整判断。直接やるか作業員に任せるかを基準表で分ける。四つ目はドメイン検査。その作業場固有の画面・方針・整合性を測る手順だ。

実際の作業場を開くと、規則集には担当部署も書かれている。完了宣言ゲートの表紙には「担当：検査官」、デプロイ手順書には「担当：インフラ作業員」。誰でも取れる共用規則もあるが、大半の手順書はその手順を担当する作業員の机に置かれる。エージェントが採用でスキルが手順書なら、よいハーネスは各手順書の担当者が決まった会社だ。

残りの部品 — フック・センサー・ゲート・メモリ・正本

GLOSSARY · 2026

フック（hook）は決めた瞬間ごとに自動実行されるスクリプトだ。セッション開始時、利用者がプロンプトを送るとき、機械がファイルを直した直後、セッション終了時。こうした瞬間に配線したスクリプトが人の手なしに実行される。調べたフックの圧倒的多数は何も阻止しない。警告を画面に流すだけだ。強く噛み付くのは次の二部品の役目になる。

センサー（sensor）は状態を測る計器だ。型検査・テスト・ビルドを実際に回し、結果を言葉ではなく数字で出す。終了コード（exit code）が0なら合格、それ以外は失敗。ゲート（gate）はその数字で通行を止める検問所だ。代表がGitフック。コミット直前やプッシュ直前にセンサーを回し、失敗すればコミット自体が拒否される。機械がどれほど「問題ありません」と言っても、ゲートは文章を読まない。数字だけを読む。

メモリはセッション間の記憶だ。セッション終了時にその日の作業と判断をファイルに書けば、次のセッションが読んで引き継ぐ。正本（canon）は「一つの事実は一か所だけに書く」という規則だ。同じ事実を三つの文書に書けば、必ず食い違い始める。実測で確認された腐敗であり、食い違う文書は機械を誤らせる。各部品を実際に作る方法は02編と04編で扱う。

なぜ全部を一度に読み込まないのか

GLOSSARY · 2026

誤解を一つ正して辞典を閉じよう。作業を命じた瞬間に全エージェントと全スキルが機械の頭に読み込まれる。そう想像しがちだが、そうではないし、そうしてもいけない。普段機械の前にあるのは一覧だけだ。作業員の名前と一行説明、手順書の名前と一行説明。本文全体は、その作業員を実際に呼ぶ瞬間、その手順書が発動する瞬間だけ開かれる。書斎を思い浮かべればよい。本は棚にあり、机には今読む一冊だけが載る。

なぜそうするのか。第一に注意力だ。機械が一度に消化できる指示量には限界がある。規則が十個なら大半を守るが、百個なら何が重要か判断できなくなることは、すでに測定されている。デプロイ手順書、デバッグ規則、視覚検査一覧が、今の翻訳作業と無関係にすべて開かれていれば、その山が本当に重要な一行を埋める。机の上の本が増えるほど、今読んでいる文への視線はぼやける。

第二に費用だ。機械の前に置く文字には、毎回、改めて料金が付く。セッションの各ターンで使いもしない手順書三十冊を丸ごと再掲するのは、会議のたびに全社員の業務マニュアルをすべてコピーして配る会社と同じだ。第三に隔離だ。作業員が資料を調べて作る数万行の中間出力は、その作業員の机で終わり、主会話には一枚の要約だけが戻る。全員が一つの机を使えば、この防火壁は消える。

実務への含意は二つある。一つ目。一覧に残る「一行説明」が事実上の呼び出しボタンだ。機械はその一行だけで呼ぶか決めるので、「便利なお手伝い」のような美辞ではなく、「完了宣言を検証するとき、コードは直さず判定のみ」のように発動条件を書く。二つ目。完了宣言ゲートのように必ず発動すべき手順を、機械の判断だけに任せない。一覧から選んで読む構造は、選ばない自由も与える。見逃せない手順には、04編の引き金、口癖を捕まえるフックを別に取り付ける。