「難しいのはエージェントではない。ハーネスのほうだ」。この言い方が、2026年のAI開発をよく言い表している。では実際のハーネスとは何なのか。うちで動いているものを、隠さず並べてみる。

ハーネスとは、馬具のことである

ハーネス（harness）は、もともと馬を制御するための馬具を指す言葉だ。手綱と鞍。馬の脚力を否定する道具ではなく、脚力を目的地に向けて使えるようにする道具である。AIの文脈でもほぼそのままの意味で使われている。モデルに何を言うか（プロンプト）でも、何を知らせるか（コンテクスト）でもなく、どんな道具・ルール・検証を通して働かせるかを設計する話だ。

この三つは、焦点が順に移っていく。プロンプトは振る舞いを、コンテクストは理解を、そしてハーネスは信頼性を扱う（※1）。

信頼性が問題になるのは、二回目からである

一回うまくいくことと、毎回同じ品質で返ってくることは、まったく別の問題だ。デモは驚くほどうまくいくのに業務に載せると回らない、という話の正体はたいていこれである。同じプロンプトと同じ文脈を与えているのに、出力の質が日によって振れる。振れ幅が読めないものは、業務プロセスに組み込めない。

ハーネス・エンジニアリングとは、モデルの回答そのものではなく、回答を取り巻くシステムのほうを設計する仕事である。

具体的には、こういう問いを立てる仕事だ。この結果を自動で検証する方法はあるか。ファイル削除や公開のような取り返しのつかない操作は、人間の承認なしにブロックされているか。何かがおかしくなったとき、何が起きたのかを後から追えるか。

ハーネスの五つの層

整理すると、だいたい五つの層に分かれる。左が一般的な整理、右がPOSIIで実際に動いている実装である。

ここから一つずつ、実物で説明する。

① ツールオーケストレーション：チケットを指示書にする

うちではDocker上にRedmineを立て、そこにAIエージェント（Claude Code）を繋いでいる。チケットに @claude と書いた注記を残すと、常駐スクリプトが一分ごとにそれを拾い、AIを起動し、作業結果をチケットに書き戻す。外出先のスマホから注記を書いておくと、帰る頃には実装が終わって報告が付いている、という運用が現に回っている（※2）。

ここで効いているのは自動化そのものより、指示の置き場所と仕様の置き場所が一本化されることのほうだ。チャットに書いた指示は流れて消える。チケットに書いた指示は残り、しかもそれがそのままAIへの入力になる。

② 検証ループ：本人の自己申告を信用しない

AIは「完了しました」と言う。だが完了したかどうかを決めるのは、本人ではない。ここを分けられるかどうかが、実務に載るかどうかの分水嶺になる。

うちではDjangoアプリの確認に、Docker上のSelenium Grid経由の実ブラウザE2Eテストを使っている。画面を実際に開いて、フォームを実際に埋めて、通ったかどうかを外側から判定する。noVNCで操作の様子をそのまま見られるので、「通った」の中身も確認できる。

検証は、厳密である必要はない。本人以外が判定していることのほうが本質的だ。テストが一件も無い状態でAIに書かせるのは、報告書だけ読んで現場を見ないのと同じである。

③ コンテクスト／メモリ：二度目からは説明しない

毎回ゼロから説明するなら、人を雇っているのと変わらない。ハーネスの三つ目の層は、説明を資産に変える仕組みだ。うちでは三段構えにしている。

• プロジェクト規約：このリポジトリでの約束事（命名、テストの走らせ方、触ってはいけない場所）をファイルに書き、毎回自動で読み込ませる。
• スキル：繰り返す手順を一本の手順書に落とす。手順書には、うまくいった手順だけでなく踏んだ地雷を必ず書く。次回は同じ穴を避けられる。
• 永続メモリ：案件をまたいで効く事実（この環境ではこの方法が使えない、など）を残す。

実例を一つ。この記事が載っているサイトのアイキャッチ画像を設定する作業は、最初は試行錯誤で三十分ほどかかった。その手順を地雷ごと一本のスキルにまとめた結果、次からは記事一本あたり一〜二回のやり取りで終わるようになった。差を生んだのはモデルの賢さではなく、手順が外に置かれたことである。

そしてこの層でいちばん間違えやすいのは、情報は多いほど良いと考えることだ。関係の薄い資料まで全部渡すと、かえって的外れな出力が増える。渡す情報を選ぶこと自体が設計である。

④ ガードレール：削除と公開だけは、人間の指を通す

作業は、リスクで三つに分けられる。読む・書く・壊すである。読む作業は自由にやらせてよい。書く作業は取り消せる範囲なら任せてよい。問題は三つ目だ。

ファイルの完全削除、外部への送信、公開、決済。これらは失敗したときに元へ戻せない。だからうちの無人実行では、削除系と公開系の操作を最初から許可していない。

この記事自体がその例になっている。調査・執筆・整形・タグ付け・アイキャッチ設定までは自動で進み、下書き保存で止まる。公開ボタンだけは、必ず人間が押す。そこに人間が要るのは、AIの文章力が足りないからではない。取り消せないからである。

「AIにどこまで任せるか」は能力の問題ではなく、可逆性の問題である。

⑤ 可観測性：後から「何が起きたか」を追える

最後の層は地味だが、これが無いと事故が学習にならない。うちでは作業の経緯がすべてチケットの注記として残り、コードの変更はコミットメッセージの refs #番号 でチケットに紐づく。「このチケット、結局どのコードで直したのか」が、人間にもAIにも一目で辿れる。

ログが無い自動化は、うまくいっている間は快適で、一度おかしくなると何も分からない。可観測性は、うまくいっているときには一切役に立たない層である。役に立つのは事故の日だけだ。だから後回しにされ、そして事故の日に後悔する。

作る順番を間違えないこと

五つ並べたが、ゼロから作るときの順番は表の並び順ではない。おすすめは④ガードレール → ⑤可観測性 → ①オーケストレーション → ②検証 → ③コンテクストである。

理由は単純で、④と⑤が無い状態で自動化を進めると、壊れたときに何が壊れたのか分からないまま壊れるからだ。逆に④と⑤さえあれば、あとは失敗しながら育てられる。順番の問題であって、優先度の問題ではない。

そして最初の対象は、全社業務ではなく失敗してもよい業務から選ぶ。うちが最初にAIへ渡したのはチケットの一括登録だった。間違えても消して作り直せば済む。可逆な仕事から始めて、可逆でない仕事は最後まで人間に残す——ハーネス設計の実務は、だいたいこの一言に集約される。

ハーネスは、部長の仕事に似ている

別稿で書いたことだが、AIまわりの用語は人間側から並べ直すと分かりやすくなる。プロンプトは新任上司の仕事、コンテクストは課長の仕事、そしてハーネスは部長の仕事によく似ている（※3）。

他部との関係を滑らかに保ち、部内の繁閑を均し、指示が確実に実行されるところまで環境を整える。優秀な部下がそろっているのに成果が出ない部署は、たいてい指示が悪いのではなく環境が悪い。AIエージェントを組んでいると、この構造が嫌になるほどはっきり見える。モデルをより賢いものに替えても改善しないのに、渡す道具と権限の設計を直した途端に通る、ということが普通に起きる。

AIに任せられる範囲は、モデルの性能ではなく、こちらが用意した馬具の出来で決まる。