AI・信頼性・評価

AIエージェントのハーネスとは：外側で組む制御と検証

2026/7/12 （更新: 2026/10/10）

🤖 AIが執筆しています

整って返る出力には、綻びが混じる

AIに記事の下書きを書かせると、主張には出典がつき、注も整い、一読すると直すところが見当たらない。ところが引用元を一本ずつ開いて確かめると、当の文献がそもそも存在しない、ということがある。2023年4月の測定では、GPT-3.5 が生成した参考文献の55%、GPT-4 でも18%が実在しなかった。実在した文献への引用にも、著者名・表題・年・巻号頁といった書誌の実質的な誤りがそれぞれ43%・24%あった（42トピック・84本・636件の参考文献）¹。同じ測定は、引かれた文献がどれも話題に少なくとも広く関連し、93%が一般向けではなく学術的な文献だったとも報告している¹。この測定が数えたのは参考文献の実在と書誌の正しさである。本文が「その論文はこう述べている」と書いた内容が当の論文には見当たらない型は、この測定の対象外だ。原典自身、本文中の虚偽の記述を体系的に検出しようとはしていないと断っている。

AIに何かを頼むと、最初に返ってくるものは、たいてい驚くほど整っている。体裁の良い文章、それらしいコード、よどみのない説明。問題はそのあとだ。本当に使おうとした瞬間から、細かい綻びが見えはじめる。事実が一つずれている。前提が黙って入れ替わっている。指示したはずの条件が、いつのまにか抜けている。綻びは例外ではない。2021年に、MITRE Top 25 由来の54シナリオを中心に、SQLインジェクションの言い換え17とVerilogのハードウェア弱点18を加えた計89のシナリオでコードを生成させたところ、1,689本のうち約4割が既知の脆弱性を含んでいたと、Pearce らは報告している²。シナリオは危険度の高い弱点に関わる場面として著者らが手作りしたもので、この割合はその集合についての値である。候補を最上位の一本に絞っても割合はほとんど変わらない（89シナリオ中35本＝39.33%）²。原典は最上位の候補の安全性をとりわけ重く見ていて、その理由に、初心者は「最良」とされた提案を受け入れやすいかもしれないことを挙げている。

「作らせる」ことは、もう難しくない。生成側の価値は小さくない。2022年5月から6月、Copilot の一般提供が始まる直前に、Copilot を提供する GitHub と、その親会社 Microsoft の研究部門 Microsoft Research の研究者3人に、MIT Sloan の研究者1人を加えた4人が対照実験を行っている（公表は2023年）。Upwork で募集した専門プログラマ95人を無作為に分け、JavaScript で HTTP サーバを実装させる、完了条件を12本のテストで先に定めた単発の課題で、Copilot を与えられた側が55.8%速く終えたと、著者らは報告している（95%信頼区間は21〜89%と広い）³。ただしこれは課題を完遂できた人に限った比較で、その人数は両群それぞれ35人である。同じ論文は成功率そのものの差（+7ポイント）は統計的に有意でなかったとも報告している。原典は、この実験がコードの品質への影響を調べていないとも断っている。ツールの側にも実例がある。ターミナルで動くコーディング・エージェントのAiderは、各リリースの新規コードのおよそ7割を自分自身に書かせている、と作者が公表している（変更履歴が割合を載せている47版では中央値66%、範囲は0〜93%）。FAQ は数え方も書いている。公開リポジトリで git blame 相当の集計をし、ソースコードのファイルの行だけを数えたものだ。本稿でコミット履歴を数え直してはいない⁴。

だが速く出てくることと、安心して次へ渡せることは別の話だ。難しいのは、返ってきたものを、その状態にすることのほうだ。手元でとりあえず動くことと、検証なしでそれに頼れると言い切れることのあいだには、はっきりした距離がある。この距離を詰める作業が、ここで扱う主題だ。

手がかかるのは、モデルの外側にある検証と設計

モデルは速く伸びている。AIが五分五分の確率で完遂できるソフトウェアタスクの長さは、2019年以降おおよそ7か月ごとに倍になってきたという計測がある。原典は「2024年以降その傾向は加速したかもしれない」と留保つきで添えており、2024年以降に区切った推定では倍化の周期は約3か月まで縮む⁵。ただし原典は、2024〜2025年だけの傾向はフロンティアモデルが七つしか無く、確信は低いと断っている。だが、この、出典の合っていない下書きをまともにするのに要るのは、次に来るより賢いモデルではない。「引用元を実際に開いて、本文の主張と一つずつ照合する」という手間だ。むしろ話は逆で、任せられる範囲が広がるほど、その成果を確かめる負荷はこちら側に積み上がる。書かせる前の段取りと、渡す前の検査。手がかかる場所は、モデルが賢くなっても消えず、たいていこちら側に残る。

この、AIにより大きく頼るための外側の仕組みを、本稿ではハーネスと呼ぶ。防御が目的ではない。安心して手放せる量を増やすための投資である。

モデルの外側だけを作って配る仕事は、すでに一つの層をなしている。ECC（Everything Claude Code）は自らを「エージェント・ハーネスの性能最適化システム」と名乗る。コーディング・エージェントに向けて配るのは、ツールを呼び出す前と後、そしてエージェントが手を止めようとしたときに発火する50本のフック実装（hooks.json の配線口は21で、うち2口はさらに20本へ振り分けるディスパッチャになっている）だ。これに21のスタック向けの規約（共通層を合わせて122ファイル）が加わる⁶。規約は常に従うべき指針として置かれ、共通ぶんと自分が使うスタックのぶんだけを選んで入れる。同じ層には、Anthropicの公式プラグイン市場にも載っているsuperpowersのように、作業の進め方を14のスキル（本体の SKILL.md だけで合計3,207行、参照文書まで含めると Markdown 37ファイル・7,054行）の散文として束ねて配るものもある。これらの数はいずれも v5.1.0 時点の実測だ⁷。ECC も superpowers も Claude Code のプラグインとして配られている（superpowers は Codex CLI など他のエージェントにも対応する）。ツールの実行前・実行後・エージェントの停止・セッション開始といった発火点はホストの Claude Code が hooks の仕組みとして定義しており、配布物はそこに何を掛けるかを束ねている⁸。どちらもモデルを一行も学習させない。中身はすべて、モデルに頼む前と、返ってきたあとの話だ。ここで数えたいのは、モデルを一つも含まない層に、これだけの作り込みが積み上がっているという事実だ。

ハーネスという語が指す範囲は、使う人によって違う。コンテキストの組み立てまで含めて呼ぶ人もいれば、事後の検査だけを思い浮かべる人もいる。配布物の側でも語は揺れていて、superpowers の README は Claude Code や Codex CLI といったホストのほうを harness と呼んでいる⁷。本稿では、二つの側を両方とも数える。ひとつは渡す前の制御である。どこまでやれば完了か（DoD）、スコープの外はどこか、前提とコンテキストを、生成させる前に決めて渡す。出力が生まれる前に形を与える側だ。もうひとつは受け取ったあとの締めである。検証し、必要ならやり直す。先に挙げたフックにも、ツールの実行前に発火するものと実行後に発火するものが両方ある。粒度は違うが、前で形を与え後ろで締めるという構えは同じだ。検証・レビュー・手順・ツールは、そのための手段である。返ってきたものを任せられるものにできるかは、たいていこの設計で決まる。そしてハーネスが効くほど、人はAIにより大きく頼れるようになる。

フックと規約は、同じ配布物の中で別々のディレクトリに分かれている。フックはコードで止め、規約は言葉で頼む。縛る力の違うものが、一つの箱の中に同居しているわけだ。この違いに名前をつけ、どの仕事をどちらへ渡すかを決めることが、次の課題になる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。