ハーネス設計とは何か。AIエージェントに"指示"ではなく"環境"を渡すという考え方
「ハーネス設計」という言葉、目にしたことはありませんか。
AIエージェントまわりの記事や投稿で、もうめずらしい言葉ではなくなりました。「指示ではなくハーネスだ」という言い回しも、どこかで見かけたことがあるかもしれません。この記事は、そういうあなたに向けて書いています。聞いたことはある。でも、いざ「それはどういうものですか」と聞かれると答えに詰まる。そのくらいの距離感でこの言葉と付き合っている人に、です。
少なくとも私は、しばらくのあいだそちら側にいました。使われているのは何度も見ている。でも、自分の言葉で説明しようとすると、輪郭がぼやける。
この記事でやりたいことは二つあります。ひとつは、ハーネスという言葉について、すでに世の中で共有されている客観的な理解を、きちんと並べ直すこと。もうひとつは、その理解を土台にして、実際に自分が何をどう組んでいるかを、真似して手を動かせるところまで具体的に見せることです。輪郭をなぞるだけの記事にはしません。読み終えたときに、今日から何を作ればいいかが分かる状態を目指します。
「知ってはいるけど説明できない」まま放っておく理由がない
まず断っておきたいのですが、ハーネス設計は難しい専門知識が要る話ではありません。むしろ逆で、輪郭がはっきりしていないせいで、必要以上に難しそうに見えている言葉だと思っています。
似たようなことは、他の分野でも起きます。長く使われすぎた言葉は、あちこちで少しずつ違う意味で使われているうちに、だんだん輪郭を失っていきます。ハーネス設計も、今ちょうどそのあたりにいる気がしています。聞いたことはある。なんとなく重要そうな響きもある。けれど、実際に何を指しているかは、話している人によって微妙にずれている。あなたが感じているモヤモヤは、理解が足りないからではなく、そもそも言葉のほうがまだ輪郭を持てていないからかもしれません。
ただし、ゼロから輪郭を作る必要はありません。実は、この言葉にはすでに、多くの人が共通して使っている土台があります。次の章では、その土台をそのまま並べます。感覚の話にせず、まず客観的な構成要素から入ります。
世間で言われている「ハーネス」は、実はかなり具体的
AIエージェントという言葉を分解すると、よくこう説明されます。エージェント = モデル + ハーネス。
モデルは頭脳にあたる部分です。考える力、言葉を理解する力、判断する力を持っています。ただ、頭脳だけでは仕事はできません。頭脳を実際の作業につなぐ周辺の仕組み一式が要ります。それがハーネスです。指示を受け取る窓口、道具を使う権限、途中で必ず立ち止まる場所、過去のやり取りを覚えておく場所。こうしたものをまとめて、モデルを実務に接続する装置がハーネスだと考えると分かりやすいと思います。
私が使っているClaude Code（AIにコードを書かせたり作業を任せたりするためのツール）自体、すでに「モデルに被せられたハーネス」です。そしてありがたいことに、このハーネスは利用者が自分の手で設定を足して、さらに拡張できるようになっています。つまり、既製品のハーネスを、自分の現場に合わせて仕立て直せるということです。
具体的に、Claudeの文脈でハーネスの構成要素としてよく挙げられるものを並べます。
CLAUDE.md：毎回自動で読み込まれる指示書です。プロジェクトのルールや、やってはいけないことを、あらかじめここに書いておきます。
スキル（スラッシュコマンド）：手順書をファイルとして置いておき、必要なときにAIが自分で読みに行く仕組みです。
フック：ツールを実行する前後や、作業を始めるタイミングなど、決まったタイミングで必ず走る自動処理です。AIの気分や判断に関係なく、機械的に検査や記録ができます。
サブエージェント：役割ごとに使える道具（触っていい範囲）を絞った別働隊です。調べるだけの役割には書き込む力を持たせない、といった分け方ができます。
権限設定（permissions）：どの操作を自動で許可し、どの操作は人間の確認を挟むかを決める設定です。
MCP：外部のサービスに接続するための入り口です。カレンダーや検索、社内のシステムなど、AIの外側にある道具とつながる窓口になります。
メモリ：セッションをまたいで記録を残しておく仕組みです。
これらは私が独自に考えたものではありません。Claudeでエージェントを組んでいる人たちのあいだで、共通して語られている構成要素です。ハーネス設計というのは、この一覧のどれを、どんな設定で用意するかを決める作業のことだと思ってもらえれば、まず土台としては十分です。
「指示」をやめて、「環境」を渡すということ
ここまでの一覧は、いわば部品表です。部品表を持っているだけでは、まだ何も組み上がりません。ここからは、その部品を、どういう考え方で並べるかという話をします。
ハーネスという言葉は、もともと馬具を指す言葉です。力のある馬を、どちらの方向へ、どれくらいの範囲で走らせるかを決める、あの装具のことです。馬の力そのものを弱めるのではなく、力はそのままに、進んでいい方向と踏み外していい範囲を先に決めておきます。AIエージェントの文脈でこの言葉が使われ始めたのも、たぶん同じ発想からだろうと思っています。AIの実力を削るのではなく、実力を発揮させたまま、どこへ向かって、どこまで進んでいいかを、先に用意しておく。
指示というのは、そのつど言葉で伝えるお願いのことです。「この形式でまとめて」「ここは触らないで」というふうに、都度こちらの意図を言語化して渡します。分かりやすいのですが、渡す側の負担が、渡すたびにかかり続けるという弱点があります。同じ注文を、毎回言葉にし直さなければいけません。しかも、こちらの体調や余裕によって指示の質はどうしても揺れます。忙しい日の指示は雑になり、雑な指示には雑な仕上がりが返ってきます。あなたにも、そういう覚えがあるのではないでしょうか。
環境というのは、そのお願いを、CLAUDE.mdやスキルやフックといった仕組みの中に、あらかじめ外に出しておく考え方です。手順・境界・確認のタイミングといった、毎回言葉にし直しているものを、AIの動く場所そのものに先回りして置いておきます。そうしておけば、こちらの言い方が雑でも、AIは環境のほうを参照して動いてくれます。頑張りの置き場所を、そのつどの入力から、あらかじめ用意した仕組みへ移す。これが、指示から環境への転換の中身です。
ハーネス設計とは、CLAUDE.md・スキル・フック・サブエージェント・権限設定・MCP・メモリという部品を使って、AIに何をさせるか（指示）ではなく、AIがどう動けば安全に任せられるか（環境）を、先に決めておく設計のことです。
この一文が、私がこの言葉に与えたいちばん短い定義です。難しい概念に見えて、やっていることは意外と地味です。あらかじめ決めておく。それだけです。
自分のハーネスは、この部品をこう組んでいる
とはいえ、部品の名前を知っているだけでは、まだ「自分は何を作ればいいのか」は分からないと思います。ここからは、私が実際に運用しているハーネスを材料に、5つの運用ルールが、上の部品のどれで実現されているかを見ていきます。
一つ目は、手順書です。何度も繰り返す仕事のやり方を一枚にまとめておいて、ファイルとして棚に置いておきます。これは、そのままスキルとして実装しています。私の手元では、記事の書き方から公開後の検品まで、手順書は気づけば100枚近くになりました。運用上のこだわりがひとつあって、AIに仕事を任せるときは「この手順書に従って」とファイルの場所ごと指定して渡すようにしています。手順書を渡されなければ動けない、という順番に設計しておくと、手順を飛ばした我流の作業が起きにくくなるからです。以前別の記事で詳しく書きましたが、頑張りを入力ではなく環境に置く、という発想の出発点になった部分です。
二つ目は、権限の分け方です。役割ごとに、触っていいものと触ってはいけないものを、あらかじめ線引きしておきます。これは、サブエージェントに持たせる道具を役割ごとに絞ることで実現しています。私の手元では、調査担当には読む道具と検索する道具だけを渡していて、ファイルを書き換える道具は持たせていません。投稿を実行する担当には、逆に本文を書き換える道具を持たせていません（直したくなったら制作の工程へ差し戻すしかない、という順番を道具の側で作っています）。ひとつ正直に書いておくと、道具の制限だけで線引きが完結するわけではありません。役割の定義に「既存のファイルを改変しない」といった禁止ルールを重ねて書いて、道具と言葉の二段で境界を守っています。
三つ目は、失敗が起きたときの動き方です。何かがうまくいかなかったとき、AIにすぐ別のやり方を試させるのではなく、「何が起きたか」「なぜそうなったと考えられるか」「どう立て直すか」の3点を先に書き出させてから、こちらが確認して次に進みます。これは、CLAUDE.mdに運用ルールとして書き込んでいます。実際にAIへ複数の役割を渡して動かしてみて、判断がどこにも残らず同じことを何度も考え直していた失敗から生まれたルールです。詳しい経緯は、以前その失敗をそのまま記録した記事に書きました。
四つ目は、判断や記録を、あとから思い出せる形に変えておく仕組みです。積み上がったメモを放っておくだけでは、ただ増えていくばかりで使い物になりません。これは、メモリの仕組みと、そこから関連するものを引っぱり出す検索の組み合わせで実現しています。必要になったときに関連するものを引っぱり出せるようにしておいて初めて、記録は資産に変わります。この部分は仕組みとしてやや込み入っているので、詳しい話はまた別の記事に譲ります。
五つ目は、人間の承認ゲートです。どれだけ環境を整えても、公開する・お金が動く・外部に発信するといった節目だけは、必ず人が最後に見て判断します。これは三段構えで担保しています。まず権限設定で、影響の大きい操作には人間の確認を挟むようにする。次にCLAUDE.mdの運用ルールとして「公開は私の承認の言葉が来たときだけ」と書いておく。そして、いちばん確実な止め方として、SNSへ自動投稿できる接続口（MCP）を、そもそもどの役割にも繋いでいません。渡していない道具は、どう転んでも使えません。ルールで縛るより、道具ごと外すほうが強い。これは運用していて実感している順序です。ハーネスは自走を増やすための仕組みであって、判断を手放すための仕組みではありません。この境界線だけは、最後まで動かさないようにしています。
並べてみると分かるのですが、どの運用ルールも、部品表のどれか一つ、あるいは組み合わせで実現できています。名前が先にあって、そこに中身を当てはめたのではなく、中身が先にあって、あとから「これはスキルだった」「これはサブエージェントの権限設定だった」と気づいた、という順番です。
最初から設計図があったわけではない
ここまで読むと、最初から見取り図を描いて、部品を順番に組み上げていったように見えるかもしれません。実際はまったく逆です。
正直に書くと、私は非エンジニアです。最初にAIへ複数の役割を渡して動かし始めたときは、権限の分け方も、失敗したときの動き方も、何も決めていませんでした。とにかく動かしてみて、壊れて、直す。その繰り返しの中で、ひとつずつルールが増えていっただけです。今こうして振り返っているから「これはサブエージェントの権限設定で塞ぐ話だった」と言葉にできますが、渦中にいたときは、ただ目の前の不具合をどう塞ぐかしか考えていませんでした。
この順番は、たぶん逆にはできません。先に完璧な設計図を描こうとしていたら、いつまで経っても動かせなかったと思います。動かして、ほころびを見て、そこだけ塞ぐ。塞いだ場所が増えていくと、ある時点で、それがばらばらのルールの集まりではなく、ひとつの環境として機能し始めていることに気づきます。
今日から作るなら、何から手をつけるか
ここまでの話を、明日から手を動かせる形に落としておきます。コードが書けなくても、文章ファイルが作れれば始められます。
最初の一歩は、CLAUDE.mdにルールを1行書くことです。特別なファイルではありません。プロジェクトのフォルダに置いておく、ただのテキストファイルです。たとえばこんな一文で構いません。
「失敗したら、勝手に別のやり方を試さないでください。何が起きたか、なぜそうなったと思うか、どう立て直すつもりかを先に書き出してから、私の確認を待ってください。」
この1行があるだけで、AIは毎回同じ場面で同じルールを参照するようになります。指示ではなく環境に置く、という発想の最小単位です。
次の一歩は、毎回書き直している注文を、1枚の手順書ファイルにすることです。「この形式でまとめて」「ここは崩さないで」と、あなたが何度も同じことを言い直しているものがあれば、それを箇条書きでファイルに落としてみてください。それがそのまま、スキルの原型になります。
慣れてきたら、役割と権限を分けます。調べるだけの役割、下書きを書く役割、公開する役割というふうに分けて、それぞれに持たせる道具を絞っていく。ここまでくると、少しずつ「エージェントを設計している」という感覚に近づいてくると思います。
いきなり全部を揃える必要はありません。私自身、そうしてきませんでした。目の前で困っていることを、ひとつずつ環境側に移していく。それで十分です。
ハーネスは、完成させるものではない
ここまで、ハーネス設計という言葉に、まず世間で共有されている部品表を並べ、そこに私なりの輪郭を重ねてきました。指示をやめて環境を渡す。渡す環境は、CLAUDE.md・スキル・フック・サブエージェント・権限設定・メモリという部品の組み合わせとして積み上がっていく。そして、それは最初から設計図があって組み上がるものではなく、失敗のたびに一つずつ塞いでいった結果として、後から輪郭を持つものです。
私のハーネスも、今日書いたこの記事の時点で完成しているわけではありません。任せる範囲を広げるたびに、また新しいほころびが出てくると思います。それでも、動かし続けながら直していくやり方のほうが、机の上で完璧な設計図を待つよりも、結局は早く進むと感じています。
もうひとつ、書いておきたいことがあります。ハーネス設計は、AIを信用しないための仕組みではありません。むしろ逆で、AIをどこまで信じて任せられるかを、少しずつ広げていくための仕組みです。境界をあらかじめ決めておくからこそ、その内側では安心して任せられる範囲が広がっていく。私にとっては、そういう感覚に近いものです。
もし、あなたの手元にも「同じ注文を毎回書き直しているもの」があるなら、それがハーネスの最初の一枚になります。難しく考える必要はありません。今日、CLAUDE.mdに1行書き出してみるところから始めてもらえたらと思います。
判断を記録として残す話や、そこから生まれた3つの失敗の話は、こちらに書きました。
手順書そのものを一枚まるごと見せた記事は、こちらです。
