AI・信頼性・評価

AIエージェントとスクリプトの使い分け：非決定のコストと来歴

2026/8/3 （更新: 2026/10/13）

🤖 AIを使用して執筆

非決定のコストを差し引いた純益で振り分ける

ここでいう「安くなった」の土俵は、同じ量を人の手で書き起こす場合と、一世代前のモデルに同じ量を出させる場合の二つだ。本稿は具体的な単価を扱わない。価格表はモデルごと・改定ごとに動くうえ、効くのは単価ではなく、リトライと検証まで含めた一件あたりの総額だからだ。安いは、無料ではない。値札が安くなっただけで、帳簿が消えたわけではない。費用の欄と、来歴の欄。この二つを順に埋める。費用の側は、何を誰に任せるかと、任せ方を縛るゲートにいくら払うかの二段になる。

素朴な答えから始める。「生成はほぼ無料になった。なら、迷ったら投げればいい」。これは決まった場所で破綻する。決まった形式の変換や決まった条件の集計のように、仕様を一行で固定できる仕事をエージェントに投げたとする。返ってくるものは、同じ入力でも揺れる。揺れる以上、構造は正しさを保証せず、一件ずつ検証して買うしかない。全件を確かめ、外れを作り直させ、直ったものをまたレビューする。この費用は、生成の値札に載らないまま積み上がる。同じ仕様はスクリプトにも書けて、そちらは同じ入力に必ず同じ出力を返すから、仕様と実装を一度確かめれば、一件ずつの検証は要らない。安いはずの選択が、高くて不確実な選択に変わる。破綻の芯はここだ。安くなったのは生成であって、検証ではない。

マルチエージェント系の7フレームワークから集めた1642本の注釈付きトレースを分類した研究がある。この研究は、失敗の44.2%がシステム設計の問題に、32.3%がエージェント間のずれに由来すると報告する¹。原著者自身、失敗の多くは個々のエージェントの能力ではなく組織設計と協調の課題から生じるとし、基盤モデルが強くなるだけでは潰しきれないだろうと述べている。だとすれば、この費用はモデルが賢くなれば消える、という類のものでもない。曖昧に投げれば、賢いエージェントでも曖昧に外す。検証と作り直しの費用は、投げる前の見極めで決まる部分が大きい。

だから、エージェント・決定的コード・人間という三つの担い手を並べ、非決定のコストまで差し引いた純益で選ぶ。

自律エージェントにやらせる。 柔軟で、幅広く、24時間動く。だがトークン代に、誤りの期待被害と、その検証・作り直し・レビューの費用という非決定の代償が乗る。仕様を固定できる仕事に使えば、いま見たとおり高くて不確実になる。過剰適用だ。

決定的なスクリプトや従来コードにやらせる。 安く、速く、再現できて、一度確かめれば一件ずつの検証は要らない。ただし、仕様を決定的に固定できる範囲でしか効かない。曖昧さ・自然言語・判断には無力で、ここに固執するとエージェントの領分まで潰す。過少適用だ。

人間にやらせる、あるいは人間の承認を挟む。 人手を残す理由は、品質の順位ではなく、責任とコンテキストの配置の問題だ。ここで要るのは、その配置に付く値段のほうだ。人手は最も高く、遅く、スケールしない。安い労働が余っている今、人間を安易に使うのは最大の浪費だ。不可逆・高リスク・対外や倫理の判断に温存すべき、希少な資源だ。

二問を上から順に当てる。一問目は仕様の側で、決定的に固定できるかを問う。固定できればスクリプトへ回すが、それで終わりではない。どちらの答えでも二問目、失敗をどこまで巻き戻せるか、巻き戻せない分の被害はどれほどかへ進む。スクリプトも、仕様の見切りを誤れば黙って壊れるからだ。

この「自動化すべきか、手でやるか」を費用便益で決める発想は、ソフトウェア工学がずっと持っていた。make か buy か。自動化の損益分岐点。三度手でやったら自動化する、という経験則もそうだ。新しいのは、非決定な自動化という第三の選択肢が加わったことだ。これでコストの式に、期待失敗コストと検証コストの項が増えた。だから「安くなった」を無条件に受け取らず、その項を差し引いた後の純益で判断する。

Self-Consistencyと呼ばれる手法がある。ひとつの問いに何度も答えさせ、割れた答えのうち多数派を採用する。原論文が測ったのは、推論課題での正答率の向上だ²。費用を設計で薄める工夫のひとつだ。ただし原論文は、この手が効くのは最終解答が定まった選択肢から出る問題に限ると断っている。開いた形の生成には、そのままでは移せない。そして手法自体は費用を消すのではなく、サンプル数のぶんだけ費用の欄に付け替える。帳簿から項が消えるわけではない。ただし原論文は、付け替えた項を小さく抑える目安も示している。5本か10本という小さなサンプル数を出発点にすれば利得の大半は取れ、多くの場合そこから先はすぐ頭打ちになる。だからこそ、差し引いた後の純益が計算できる。

ゲートの値打ちは、外して測る

費用の欄には、まだ載せていない行がある。ゲートそのものの費用だ。人間の承認ゲートも、機構による検査も、置けば実装と保守が要り、待ち時間が増え、拒否のたびに説明の文がコンテキストを食う。だから本来は、そのゲートが防いだ損害と、そのゲートを回す費用の二行が並ぶ。ところが前者は、たいてい主張で埋まる。防いだ事故は起きなかった事故なので、数えにくい。効いていると思うから置き、置いたまま残る。

だが効き目のほうは、測れる場合がある。外して、点差を見ればいい。SWE-agent はそれを自分の道具立てでやった。SWE-bench は、GitHub の実際の課題を与え、そのリポジトリの実テストが通るかどうかで採点する。人手の採点者を挟まないので、同じ条件を何度でも回せる。SWE-agent はその300件版で、モデルを固定したまま、エージェントに持たせる部品を一つずつ外したり別の作りに替えたりして点数を比べている³。

検索の設計が分かりやすい。基準の構成では、検索結果が上限（50件）を超えたら結果を返さず、もっと具体的な問い合わせを書けと促す。基準の構成を、結果の一括表示から一件ずつの逐次表示へ替えると、18.0%から12.0%へ落ちる。差は6.0ポイント、基準の三分の一だ。ただし原著の図は、この促しを、全件を一度に見せることと並べて、逐次表示には無い基準の構成の性質として挙げている。この差は上限単独の値ではなく、検索の設計ひとまとまりの値打ちにあたる。原著者の説明では、結果が多いとエージェントは全件を順に見尽くそうとし、費用の予算やコンテキストウィンドウを使い果たしうる。効くのは、比較の点がもう一つあることだ。検索コマンドを丸ごと持たせない構成は15.7%で、逐次表示の検索より高い³。設計を誤った能力は、その能力が無い状態にも劣りうる。ゲートを外した分だけ点が下がるという足し算には、なっていない。

同じ比較表には、留保の要らないゲートも載っている。編集が構文エラーを生む場合に、その編集を適用せず差し戻す検査だ。これを外すと18.0%から15.0%へ、3.0ポイント落ちる³。原著の小見出しはそのまま「ガードレールは誤りからの復帰を助ける」で、狙いは同じ箇所を延々と編集し直す失敗の連鎖を断つことにある。差し戻すときにエージェントへ返す文からも要素を落として試していて、誤りの種類・変更後の断片・元の断片の三つを揃えるのが役に立つと報告している。誤りの種類が無ければ誤診しうるし、変更後の断片が無ければ同じコマンドを打ち直すことが増え、元の断片が無ければ何手も前の内容へ注意を戻さねばならない、というのが原著の説明だ。拒否文の中身も、ゲートの一部として設計されている。もっとも原著は、この検査の代償も書き添えている。適用を阻む以上、この検査は編集に特定の順序を強いる。入れるかどうかは、よくある誤りをどれだけ減らすかと、モデルの進め方をどれだけ妨げるかを見比べて決まる、と。防いだ損害と回す費用の二行は、測った側でも同じように並んでいる。

この種の値付けは、我々が当たった範囲では、実運用のハーネスで唯一の公開例だった。しかも査読を通った学会論文としての公開だ。数値そのものは2024年の一モデル・一ベンチマークの測定で、自分のゲートに同じ点差が出る保証はない。移せるのは数値ではなく手順のほうだ。外して、回して、差を見る。

費用の側にも、実装が示す自認がある。Claude Code などへフックと規約を配布しているパック ECC は、ゲートの拒否メッセージがコンテキストを食うこと自体を設計の対象にしている。同じ拒否文が溜まるとモデルが同じ動作を繰り返すループに落ちやすくなる、と実装のコメントに書き、同じセッションでファイル編集ゲートの拒否が重なると、既定では4回目以降、長い説明を序数つきの1行へ畳んで毎回の文面を変える（破壊的コマンドと初回Bashのゲートは対象外）。ECC は主なゲートの拒否文に、そのゲートを切る手順も併記する。ただし全部ではなく、破壊的なコマンドを止める拒否文には付かない。強制の段数は minimal・standard・strict の三段で、どのゲートがどの段まで生き残るかが、そのまま値打ちの順位の宣言になっている⁴。ゲートの費用は、書いた時ではなく、回すたびに発生する。

そして値打ちは固定ではない。この値付けをした当のチームは、翌年、自分たちの作りを、ツールは bash だけという薄いものへ改めた。いまは SWE-agent のリポジトリの冒頭に、開発の主力は後継の mini-swe-agent へ移り、それが SWE-agent に取って代わった、性能は SWE-agent と同等のままはるかに簡素だ、今後は mini-swe-agent を使うことを勧める、と掲げている⁵。公式ドキュメントの側はもう一段はっきりしていて、SWE-agent は「保守のみのモード」に入ったと全ページの告知に書いている⁵。少なくともこのチームでは、ゲートの値打ちはモデルの能力とともに減価した。ただし同等の働きが薄い作りで出るからといって、SWE-agent が消えるわけではない。同じチームは、道具立てを取り替えて比べたいなら SWE-agent を使えとも書いている。実運用での値打ちが減っても、測るための道具としては残る。いま見た点差も、その残った道具から出ている。帳簿にゲートを足す欄があるなら、退役させる欄も要る。

ただし、この測り方が届かない相手がいる。平均点は、稀にしか起きないが起きたら取り返せない失敗を映さない。秘密の露出も、対外送信の誤爆も、頻度で割れば点差にはほとんど出ない。外して測って値付けできるのは、繰り返し起きて、機械が採点できる失敗のほうだ。一撃で取り返しがつかなくなる側を止めるゲートは、点差ではなく被害の大きさで正当化するしかない。差が出ないことは、外していい理由にならない。

完全再現でなく、来歴と事後検証を残す

来歴の欄に移る。ここにも素朴な答えがある。「チャットのログは全部残してある。要るなら同じプロンプトをもう一度流せばいい」。これも決まった場所で破綻する。まず、再実行は同じものを返さない。温度を下げても、共有された推論エンドポイントでは同時実行の負荷でバッチの大きさが揺れ、浮動小数点の加算順序が変わって出力が変わりうる。原因は乱数ではなくバッチ不変でないカーネルだ、と分析した報告がある。同じ報告の実測では、温度0で同じプロンプトを1000回流すと80通りに割れた。しかも最初の102トークンは全て一致していて、割れ始めるのは103トークン目だ。割れた先の中身も書かれていて、1000本のうち992本は生誕地を「Queens, New York」と続け、8本は「New York City」と続けた。80通りのうち最も多い出力でも、1000本中78本にとどまる⁶。どの出力も冒頭は同じ文で始まるので、並べて読まない限り気づかない。そもそもプロバイダはモデルの版を入れ替え、古い版を廃止する。廃止の予定日と後継の対応表を公開しているプロバイダもあり、期日を過ぎた版への要求は失敗する⁷。数ヶ月後の「同じプロンプト」は、別のワーカーへの同じ指示だ。次に、ログは会話を写すが、来歴を写さない。どの版のモデルが、どの設定で、どの入力から作ったのか。監査で要るのはその記録であって、やり取りの文面ではない。

だから、再現と監査を分けて考える。多くの場合に本当に要るのは、ビット単位の完全再現ではなく、来歴と検証だ。ここでは、生成のどの段階を担保するかで分けて考える。過程を丸ごと固定する、入力の記録を残す、出力を検証して凍結するの三つだ。

完全再現を狙うなら、乱数のseed、温度、モデルの版・プロンプト・入力をすべて固定する。だがそれでは足りない。揺れはバッチの側から入るからだ。先の報告も、推論スタックをバッチ不変なカーネルごと自分で握って初めて、1000回の生成が全て一致したと書いている。そこまでやればビットに近い再演に迫れ、監査は最強になる。ただし値段が付く。同じ報告が別の構成で測った速さは、既定の26秒に対し、決定的にすると55秒、注意機構の実装を直して42秒だった⁶。この値段は実装で動く。推論エンジンの SGLang は同じ研究所のバッチ不変カーネルを取り込んで決定的推論を起動時の設定として持たせ、先の報告の61.5%（26秒から42秒）に対し、平均34.35%の減速だったと報告している。構成は別で、開発チーム自身の測定だ⁸。しかも脆さは残る。版の廃止一つで崩れるうえ、共有エンドポイントを使う限り、その推論スタックは自分の手にない。加えて全固定は、自分を改善から締め出す。版を上げれば、固定した意味が消えるからだ。

そこまで固定しないなら、来歴を記録する。生成の入力を出力に添える。入力とは、モデル、それを回したプラットフォームやエンドポイント、プロンプト、seed、データとコードのハッシュだ。回した先まで要るのは、同じモデル名でも提供元が変われば退役の日程が違い⁷、バッチの振る舞いも違うからだ。OpenAI の API も、seed を最善努力の機能として決定性を保証せず、バックエンド構成の指紋を応答に返して変化の監視に使えと書いている。ただし参照時点で、どちらの欄にも非推奨の印が付いている⁹。出力そのものは再現しない。安く、永続する。正確な出力を再生成できなくても、「何が作ったか」には常に答えられ、過程を監査できる。大量生成にもスケールする。ただし証明できるのは来歴であって、正しさではない。そして生成の瞬間に記録する規律が要る。あとから付け直そうにも、そのとき動いていた版や設定は、もう手元にないからだ。

この「その場で記録する」は、指示のままにせず機構へ降ろせる。Aider が引くのは、AI由来の変更と人間の変更のあいだの境界だ。編集の一手ごとに説明つきのコミットが入る。作業ツリーに未コミットの変更が残っている場合は、AIが触る前にそちらを先に確定させて分ける。公式ドキュメントは「こうすればあなたの編集は aider の編集と分かれたままになり、aider が不適切な変更をしても作業を失わずに済む」と書いている¹⁰。しかも記録は、変更を説明する文面だけで終わらない。既定では、自分で書いた変更にはコミットメッセージの末尾に Co-authored-by: aider で始まる行が付き、人の未コミット変更を代わりに確定させただけのときは committer の名前に (aider) が付く。書いたのか、通しただけなのかが、後から機械で読める。誰の手が入ったかの境界が、記録の側に引かれる。来歴は、覚えておく約束ではなく、経路に置いた手続きにできる。

残るのが、出力をartifactとして検証・凍結する手だ。生成後に決定的に検証し、通った版を不変の成果物として保存する。ビルドの成果物のように扱うわけだ。どう再生成するかを気にせずに済み、確定した版が正本になる。安く、ソフトの出荷様式にも合う。だが事後に検証できる出力にしか効かず、変種を再導出する力は失う。

初期値は、要るものを見極めて分ける。あとで誰かが検算する科学的な主張や数値結果なら、seedとモデルの版とコードを固定し、再現可能に近づける。実験法の作法だ。日々の大量成果物なら、決定的に検証してから不変のartifactとして凍結し、来歴のメタを添える。監査だけ要るなら、生成時に入力のハッシュを記録しておく。核心は、非決定を「再現できないから諦める」でなく、「何が作ったか＋通ったか」を安く固定することだ。

来歴を辿れることは、科学とエンジニアリング両方の古い規律だ。実験の再現性、データのlineage管理、バージョン管理、再現可能ビルド¹¹、通った成果物を凍結するartifactリポジトリ。ソフトウェアの供給網では、成果物がどこで・いつ・どう作られたかを、ビルドを走らせた基盤の側が記録する形が、SLSA という枠組みの来歴（provenance）の仕様に定められている¹²。新しいのは、出力が非決定になったことで、「再ビルドすれば同じ」という前提の側が壊れた。だから完全再現に固執せず、来歴と事後検証へ軸足を移す。そもそも、記録の欠落は生成AI以前からの常態だった。AAAIとIJCAIから論文400本を抽出し、うち実証研究にあたる325本へ再現性の指標を当てた2018年の調査は、必要な変数を全て記載した論文は一本もなく、記載率は各因子で2〜3割にとどまると報告している¹³。完全再現を最初の目標に据えるのは、多くの場合、払いきれない費用を帳簿に載せることだ。

コストと来歴では扱いきれず、人間が担う三つ

純益で振り分ける、来歴を残すというここまでの二つには、それぞれ届かない先がある。届かない先は三つあり、いずれも人間が担うことになる。

来歴が証明するのは「何が作ったか」であって、「それが正しいか」ではない。誤った出力の来歴は、誤ったまま完璧に辿れる。監査可能性は、正しさの代わりにはならない。

振り分けの二問も、「仕様を決定的に固定できるか」を正しく見切れることを前提にする。固定できると思った仕様に隠れた曖昧さがあれば、スクリプトは端で壊れ、その故障は表に出ない。固定できないと思って人に回した仕事が実は型にはまるなら、安い自動化の機会を潰す。見切りを誤れば、過剰適用にも過少適用にも転ぶ。

そして「安い」という前提自体が動く。モデルが良くなれば非決定のコストは縮みうるが、消えるとは限らない。今日の「使うほどではない」が明日の初期値になることもある。線は一度引いて終わりではなく、費用が動くたびに引き直す。動いたかどうかは、外して差を見れば分かる。だが測定が出すのは点差であって、引き直すかどうかの判断ではない。稀で不可逆な失敗を止めているゲートは、点差が出なくても外せない。このうち、参照なしで正しさを測る仕事と、版の差し替わりに気づけないドリフトへの手当ては、古い作法が半分しか答えない領域として、いまも未解決のまま残る。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。