AIエージェントを組んでいると、奇妙なことに気づきます。同じモデルを使っているのに、成果がまるで違う。腕のいい人が組んだエージェントは仕事をこなし、そうでないものは同じ作業で迷走する。プロンプトの巧拙という話でもありません。差が出ているのは、ハーネスと呼ばれる部分です。AIを部下のように動かすための、権限とスキルの設定のことです。

この記事では、そのハーネスとは何なのかを整理します。実装の細かい話は次回以降に譲り、今回は考え方だけを扱います。

ハーネスとは、AIを部下のように動かすための「権限とスキルの設定」

ハーネスという言葉は耳慣れないと思いますが、やっていることは単純です。

新しく入った部下に、仕事をどう任せるか。
それと同じことを、AIに対してやる。

決めるのは3つだけです。

• どんな手順書と情報を渡すか（スキル）
• どこまで自分の判断でやってよいか（権限）
• どこで報告・相談させるか（停止条件）

新人にいきなり「何でも好きにやっていいよ」と言っても動けません。逆に、一挙手一投足に許可を求めさせたら仕事は進みません。その中間をどこに置くかを決めること——それがハーネス設計です。

なぜ「ハーネス」と呼ぶのか

ハーネス（harness）は、もともと馬具のことです。馬の力そのものは変えられない。変えられるのは、その力をどう繋ぎ、どこへ向けるかだけ——そういう含意があります。

AIも同じです。モデルの賢さはこちらでは変えられません。世界（ファイル、API、データベース、人間）も、そこにあるだけです。設計できるのは、その間をどう繋ぐかだけ。図でいえば、中央の枠の中身だけが私たちの仕事です。

私たちが設計できるのは真ん中だけです。にもかかわらず、世の中の議論は「どのモデルが賢いか」に集中しています。実務で差がつくのは、ほぼすべてハーネス側だというのが、実際に組んでみた実感です。

権限をどう与えるか——3万円のイベント代の話

抽象的な話が続いてもわかりにくいので、先に具体例をひとつ。権限の設計がどういうものかを、人間の話から始めます。

営業担当に「イベントの参加費として3万円まで使っていい」と渡したとします。ところがその期間、めぼしいイベントがなかった。担当者は余った1万円を、取引先とのお茶代に使いました。

本人に悪気はありません。営業活動には違いないからです。しかし会社としては「それは違うだろう」となる。金額は伝わっていたが、趣旨は伝わっていなかったわけです。

ではどうするか。決裁の条件を決め直します。たとえば「社内の誰かが出席するイベントの参加費に限る。それ以外には使わない」。対象と用途を絞ることで、解釈の幅を消します。

これが権限設計です。金額を決めることではなく、何に使ってよいかの境界を決めること。境界が曖昧だと、悪意がなくてもズレます。

ところが、人間とAIでは同じ渡し方が通用しない

同じ「3万円まで」を人間とAIに渡すと、起きることがまるで違います。

	人間の部下	AIエージェント
指示が曖昧なとき	空気を読んで補う（ただしズレる）	補わない。書いてあるとおりに実行する
判断に迷ったとき	「これは聞いたほうがいいかな」と察して相談してくる	察しない。条件に無ければ相談せず進む
決めた範囲	善意で逸脱することがある（お茶代）	決めた範囲は正確に守る
一度言ったこと	次からは覚えている	毎回ゼロから。外に書かないと消える

つまり、人間には趣旨を伝えれば細部は補完してもらえるが、AIには趣旨が伝わりません。「常識的に考えて危ないことはやめてね」は、人間には通じてAIには通じない。

裏を返せば、条件さえ書き切れば、AIは人間より正確に守ります。お茶代への流用は起きません。曖昧さを残したまま任せるか、書き切ってから任せるか——その差だけです。

だから「機械的に判定できる基準」で線を引く

弊社がAIに与えている権限は、こういう形にしてあります。

• 取り消せる操作（ファイルの編集、下書きの保存、データの集計）……いちいち確認しない
• 取り消せない操作（記事の公開、メールの送信、購入、削除）……必ず止まって確認する

ポイントは、「重要かどうか」ではなく「取り消せるかどうか」で分けていることです。重要度は主観なので、AIには判定できません。可逆かどうかなら、機械的に判定できます。

人間の部下なら「これは重いから一応確認しよう」と察してくれます。AIにそれを期待してはいけない。察しなくても正しく動く基準を渡すこと——それがAIに対する権限設計です。

設計すべきことは、3つしかない

いま見たのは「権限」の話でした。ハーネス全体としては、決めることは3つだけです。

1. 何を見せるか（入力の設計）……コンテキストに何を載せ、何を載せないか
2. 何をさせるか（行動の設計）……どんなツールを、どんな粒度で与えるか
3. いつ止めるか（制御の設計）……終了条件、失敗条件、人間を呼ぶ条件

逆に言えば、うまく動かないエージェントは、必ずこのどれかが決まっていません。症状から原因を引くこともできます。

症状	疑うべき箇所
迷走する・話が逸れる	①が過剰か、③が無い
何もできない	②が足りない
事故を起こす	③の「人間を呼ぶ条件」が無い

いま実際に動いているもの

抽象的な話が続いたので、私の会社で現に動いているものを挙げます。特別な技術は何ひとつ使っていません。

やっていること	与えている権限	渡してある手順	起動条件と報告先
ブログ記事の作成	投稿の作成・更新。公開はできない	記事を作るときに必ず揃える6点を手順書にしてある	私が頼んだとき。結果は下書きとして残る
朝のニュース収集	Slackへの投稿だけ。過去ログは読めない	収集元と要約の形式を決めてある	毎朝9時台。決まったチャンネルに8本
チケットの処理	チケットの読み書き	内容が毎回違うので渡していない	注記に印を書くと1分以内に動く。結果は同じチケットに返る
SNSの定期投稿	投稿API	投稿文の型を5種類	毎晩、決まった時刻

表を横に読むと、どれも同じ3列で説明できることが分かります。やっている内容はバラバラでも、設計しているものは同じです。

権限は、狭くすると速くなる

1行目の「公開はできない」がその例です。記事を書かせるとき、公開する権限は渡していません。下書きまでです。

制限すると遅くなりそうに思えますが、逆でした。公開できないと分かっているから、私は途中の確認を挟まずに書かせられます。取り返しのつかない操作が存在しない範囲では、いちいち止める理由がありません。

2行目も同じ考え方です。ニュース収集のために渡してあるのはSlackへ投稿する権限だけで、過去ログを読む権限は渡していません。読む必要がないからです。渡していない権限は、事故になりようがありません。

権限を絞るのは、信用していないからではない。
確認を減らすためです。

起動条件は、新しい作業を増やさない場所に置く

3行目が、いちばん効いているものです。チケットにいつもどおり注記を書く。そこに印をひとつ付けておくと、1分以内にAIが動き出し、結果が同じチケットに返ってきます。

ここで意識したのは、「AIを起動する」という新しい作業を増やさないことでした。起動のために別の画面を開く仕組みにすると、たいてい使われなくなります。すでにやっている行為の中に、起動条件を埋める。

結果をチケットに書き戻しているのにも理由があります。どこかのログファイルではなく、人間が普段から見る場所に返す。そうしないと、動いたかどうかを誰も確認しなくなります。

実例：手順書には、手順を書かない

①の「何を見せるか」について、弊社での実際の運用を書きます。

エージェントに常時読ませている全社共通のルールには、作業手順が一行も書いてありません。書いてあるのは「完了したら冒頭に大きく完了と出す」「許可が必要な操作は、できるだけ一つにまとめて承認が一度で済むようにする」といった、振る舞いの規約だけです。

理由は単純で、手順をすべてここに書くと、関係のない作業のときにも読まされるからです。

では手順はどこにあるかというと、スキルという単位で外に出してあります。WordPressの記事にSEO情報を設定する手順、チケット管理システムに起票する手順、動画を生成する手順——そういったものが個別に登録されていて、その作業をするときだけ読み込まれます。

導入して何が変わったか

全然違います。毎回指示する必要がなくなりました。

以前は、記事にSEO情報を設定するたびに「この入力欄には id が無いので name で取ってほしい」「保存する前に投稿IDが一致しているか確認してほしい」と説明していました。同じ説明を、作業のたびに繰り返していたわけです。

ただ、効いているのは「説明が省ける」ことだけではありません。その作業をしていないときに、その知識が視界に入らないことのほうが大きい。動画を作っている最中に記事編集の手順を読まされていたら、注意はそちらにも引かれます。人間なら「いまは関係ない」と無視できますが、エージェントは無視しません。渡された情報は、すべて判断材料として扱われます。

だから設計の問題は「何を渡すか」ではなく「何を渡さないか」になります。スキルという仕組みの本質は、手順の再利用ではなく視界の切り替えにあります。

一番効くのは「失敗の記録」

手順書として価値が高いのは、正しい手順そのものではありません。一度失敗した箇所です。たとえば記事を書かせるための手順書には、こういう行が並んでいます。

• 保存したらもう一度読み込んで、6項目が揃っているか確認する。揃う前に「できました」と報告しない
• 公開ボタンは押さない。下書きまで作って、公開は人間が判断する
• 本番サーバーへの確認は1件ずつ、間隔を空けて行う。まとめて叩くと締め出され、サーバーの障害と勘違いする

どれも、一度やらかしてから書き足された行です。1行目はアイキャッチと抜粋を入れ忘れたまま「完成しました」と報告してきたので足しました。3行目は、確認のつもりで一気にアクセスして自分で締め出され、サーバーが落ちたと思って原因を探し回った末に、落としていたのが自分だと分かったときのものです。

人間なら二度目は覚えていますが、エージェントは毎回まっさらな状態で来ます。だから、外に書いておく必要があります。

うまくいかなかったときの話

いま挙げた3つは、どれも実際に事故になったものです。順に書きます。

① 毎朝8時のはずの作業が、一度も動いていなかった

営業リストを作る作業を、週3回、朝8時に設定していました。ところが何週間経っても成果物が出てこない。

原因は、モデルでもプロンプトでもありませんでした。朝8時は私が寝ていることです。処理の途中で「この操作をしていいですか」という確認が出て、答える人間がいないまま時間切れになる。それが毎回起きていました。

動かない理由が、技術の側にひとつも無いことがある。

実行時刻を13時に移しただけで、動くようになりました。「いつ動かすか」は、ハーネスの設計そのものです。人間の承認が要る処理を、人間がいない時間帯に置いてはいけない。

② 同じ投稿が2回流れた

SNSへの定期投稿が、ときどき二重に走りました。原因は単純で、「投稿した」という記録を、投稿したあとに書いていたことです。

投稿はできたのに、記録を書く前に落ちる。すると記録の上では「まだやっていない」ことになり、次の実行がもう一度投稿します。

直し方は、順番を入れ替えるだけでした。先に「これからやる」と記録し、実行し、成功したら「やった」に更新する。分散システムでは当たり前の考え方です。当たり前すぎて、AIに任せているときは飛ばしてしまいました。

③ 文字化けした投稿が、そのまま8本届いた

Slackへニュースを流す仕組みで、日本語が全部文字化けしたまま8本投稿されたことがあります。

最悪だったのは、どこにもエラーが出なかったことです。スクリプトは正常終了し、Slackも問題なく受け取ってしまう。投稿されたものを目で見るまで、誰も気づけませんでした。

止まってくれる失敗は、まだいい。
止まらない失敗のほうが高くつく。

ハーネスで防ぐべきなのは、こちらです。落ちる処理はログを見れば分かります。落ちずに、間違ったまま完走する処理は、出口に検査を置いておかないと素通りします。

逆説：自由度を下げると、性能が上がる

直感に反しますが、エージェントに与える自由を減らすほど、成果は安定します。

理由は単純で、選択肢が増えるほど誤りの余地が増えるからです。百種類の道具を渡されたエージェントは、正しい一つを選ぶ確率が下がります。新人に「何でも好きにやっていいよ」と言うと固まるのと同じです。

これはソフトウェアの世界では見慣れた構図でもあります。型システムは、書けるプログラムを減らすことで、書けるプログラムの正しさを上げている。ハーネスも同じで、できることを狭めることが、できることの質を上げます。

ただし、左端に寄せてもいけない

弊社では、ファイルの読み書きやスクリプトの実行は広めに許可しています。一操作ごとに確認を求めていたら、作業がまったく進まないからです。

一方で、取り消せない操作だけは必ず止まるようにしてあります。記事の公開、メールの送信、購入、削除。この線引きが、図でいう山の頂上にあたります。

頂上は「全部自由」でも「全部確認」でもありません。可逆な操作は任せ、不可逆な操作だけ確認する——この一線をどこに引くかが、ハーネス設計の中心です。

結果として何が起きるか

生産性が上がったというより、優秀な部下ができたような感覚に近い。

これが、制約を設計したあとに実際に起きたことです。指示の量は減ったのに、任せられる仕事は増えました。制約と自律は、対立しません。むしろ制約が明確なほど、任せられる範囲が広がります。

ハーネスは、新しい概念ではない

ここまで書いてきたことは、実は新しい話ではありません。人間の組織が何百年もやってきたことと、同じ構造をしています。

「優秀な部下ができたような感覚」という表現を使いましたが、これは比喩ではないと思っています。やっていることが、実際に組織設計と同じだからです。

どの業務を任せるかを決め、どこまでは自分の判断でやってよいかを決め、どこからは相談してもらうかを決める。手順を文書に残し、失敗の経験を引き継ぐ。ハーネス設計とは、組織設計を機械に対してやり直すことです。

だから、良い組織を作れる人は良いハーネスを作れると思っています。逆もまた言えるはずです。

数学から見ると：世界を「扱える形」に切る

私はもともと数学の研究をしていました。専門は測度論という、ごく雑に言えばどんな対象になら「大きさ」を定義できるかを扱う分野です。

測度論の出発点は、意外に思われるかもしれませんが「測れない集合が存在する」という事実です。だから先に「測れる対象とは何か」を定義してから議論を始めます。世界をそのまま扱うのではなく、扱える形に切り出してから扱う。

エージェントの設計は、これとまったく同じことをしています。業務をそのまま渡しても、エージェントは扱えません。「観測できる状態」と「実行できる操作」に切り分けて、はじめて対象になります。

よく「AIでは自動化できない業務」と言われるものの多くは、能力の限界ではなく定義がされていないだけだと考えています。人間が暗黙のうちにこなしているので、切り出す必要がなかった。切り出せない業務は、技術の問題ではなく定義の問題として自動化できません。

なぜ今、この話が重要なのか

モデルの性能は、今後も上がっていきます。しかしハーネスの設計は自動的には良くなりません。そこは人間の仕事として残ります。

そして厄介なことに、モデルが賢くなるほど、ハーネスの粗さは見えにくくなります。多少設計が雑でも、それらしく動いてしまうからです。動いているように見えて、止まらない・二重に実行する・誰も確認していない、という状態が温存されます。

まとめ

エージェントを設計するとは、賢さを引き出すことではなく、世界を扱える形に切り分けることです。そして切り分けの単位は、技術ではなく業務の理解から決まります。

だから私は、これを技術者だけの仕事だとは思っていません。

次回は、この3つのうち「いつ止めるか」——どう線を引けば、うまく任せられるのかという制御の思想について書きます。