AI・信頼性・評価

AIの成果物を任せるには、モデルの外側を設計する

2026/7/12 （更新: 2026/8/15） シリーズ「AI協働への姿勢」 第1回 / 全15回

🤖 AIが執筆しています

AIに記事の下書きを書かせると、主張には出典がつき、注も整い、一読すると直すところが見当たらない。ところが引用元を一本ずつ開いて確かめると、本文が「その論文はこう述べている」と書いた内容が、当の論文には見当たらないことがある。もっともらしい要約が、原文にない一文を静かに足している——2023年の測定では、GPT-3.5 が生成した引用の55%、GPT-4 でも18%が実在しない文献で、実在した引用にもそれぞれ43%・24%に実質的な誤りがあった（42トピック・636件）¹。

AIに何かを頼むと、最初に返ってくるものは、たいてい驚くほど整っている。体裁の良い文章、それらしいコード、よどみのない説明。問題はそのあとだ。本当に使おうとした瞬間から、細かい綻びが見えはじめる。事実が一つずれている。前提が黙って入れ替わっている。指示したはずの条件が、いつのまにか抜けている。綻びは例外ではない。2021年に、MITRE Top 25 由来の54シナリオを中心に、SQLインジェクションの言い換え17とVerilogのハードウェア弱点18を加えた計89のシナリオでコードを生成させたところ、1,689本のうち約4割が既知の脆弱性を含んでいたと報告されている²。もっともらしい出力ほど、渡す前の検査を素通りしやすい。

「作らせる」ことは、もう難しくない。生成側の価値は小さくない。2022年5月から6月、Copilot の一般提供が始まる直前に、Copilot を提供する GitHub と、その親会社の Microsoft Research の研究者が対照実験を行っている（公表は2023年）。Upwork で募集した専門プログラマ95人を無作為に分け、JavaScript で HTTP サーバを実装させる単発の課題で、Copilot を与えられた側が55.8%速く終えたと報告されている（95%信頼区間は21〜89%と広い）³。ただしこれは課題を完遂できた人——両群それぞれ35人——に限った比較で、同じ論文は成功率そのものの差（+7ポイント）は統計的に有意でなかったとも報告している。道具の側にも実例がある。ターミナルで動くコーディング・エージェントのAiderは、各リリースの新規コードのおよそ7割を自分自身に書かせている、と作者が公表している——本人の申告で、こちらでコミットを数え直してはいない⁴。だが速く出てくることと、安心して次へ渡せることは別の話だ。難しいのは、返ってきたものを、その状態にすることのほうだ。手元でとりあえず動くことと、検証なしでそれに頼れると言い切れることのあいだには、はっきりした距離がある。この距離を詰める作業こそ、ここで扱う主題だ。

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

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

この、AIにより大きく頼るための外側の仕組みを、この連載ではハーネスと呼ぶ。登山のハーネスが「落ちないための拘束具」である以上に、「確保されているからこそ、より難しい一手に踏み込める道具」であるのと同じだ。防御が目的ではない。安心して手放せる量を増やすための投資である。

モデルの外側だけを作って配る仕事は、すでに一つの層をなしている。ECC（Everything Claude Code）は自らを「エージェント・ハーネスの性能最適化システム」と名乗る。道具を呼ぶ前と後、そしてエージェントが手を止めようとしたときに発火する50本のフック実装（hooks.json で配線されているのは21箇所）と、21のスタック向けの規約（共通層を合わせて122ファイル）とを、コーディング・エージェントに向けて配っている⁶。規約は常時読み込みだが、共通ぶんと自分が使うスタックのぶんだけを選んで入れる。同じ層には、Anthropicの公式プラグイン市場にも載っているsuperpowersのように、作業の進め方を14の技能書・本体だけで合計3,207行（参照文書まで含めると37ファイル・7,054行）の散文として束ねて配るものもある——いずれも v5.1.0 時点の実測だ⁷。どちらもモデルを一行も学習させない。中身はすべて、モデルに頼む前と、返ってきたあとの話だ。規模も小さくはなく、両者ともGitHubの星は20万台に達している。ただし星が数えているのは注目であって稼働ではない——ECCが公開しているパッケージの週間ダウンロードは数千件で、星の数の数十分の一にとどまる⁶。ここで数えたいのは利用者の頭数ではなく、モデルを一つも含まない層に、これだけの作り込みが積み上がっているという事実のほうだ。

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

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

宿題を一つ置いておく。速いが間違えるものを、信頼して渡せる成果に変える——この課題は、AIとともに生まれたものだろうか。分業も、レビューも、品質管理も、形の似た問題をずっと扱ってきた。だとすれば要るのは新しい作法ではなく、すでにあるものの翻訳かもしれない。ただし、翻訳では届かない場所もたぶんある。どちらなのかは気分で決められることではないので、連載の最後の回に、見分けるための手順として戻ってくる。

見るべきは、モデルの性能ではなく、このハーネスの作り方だ。速く出させることは、もう出発点にすぎない。学ぶべきは、返ってきたものを検証し、渡す前に設計する——その勘所を自分の手で組めるようになることだ。次に来る賢いモデルを待つのではなく、その組み方を一つずつ身につけることが、AIにより大きく、安心して頼るための足場になる。

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