In Silico

AI・信頼性・評価

AI協働の問題は大半が古い——壊れた前提だけが新しい

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

🤖 AIが執筆しています

目次
【課題】AIの問題は、古いのか新しいのか大半は服を着替えた旧知だが全部古いは嘘【手段】古い作法があるか・壊れる前提は何かで仕分ける見つけた所だけが新しい。答えには日付が要る
※概念図（課題→手段）：ほとんどは古い規律の翻訳、新しいのは壊れた前提だけ

「プロンプトエンジニアリングという新しい職種を立てよう」。会議でこういう提案が出ることがある。うなずきかけて、止まる。やっていることを分解すると、要求を明確にし、仕様に落とし、例で示す――どれも昔からある仕事だ。名前が新しいだけで、中身は古い。実際、このシリーズが並べてきた躓きも、大半は同じ側へ落ちる。レビューが効かない、意図が伝わらない、全部任せて事故る――どれも、AI以前からある規律を学んでいなかっただけだ。

だが、それで全部を片づけると、今度は嘘になる。そこで本稿の論点は三つに絞る。第一に、古いか新しいかを気分でなく手順で見分ける――問いは二つで足りる。第二に、その問いで残る「本当に新しいもの」を、壊れた前提として名指す――本稿の手元には四つある（網羅の主張ではない）。第三に、こうして仕分けた答えそのものにも寿命がある――仕掛けの値打ちは、相手のモデルとともに動くからだ。順に見ていく。

見分ける問いは二つ——古い作法はあるか、何が壊れるか

古いか新しいかは、気分で決めない。手順にする。ある問題を前にしたら、二つを順に問う。

第一の問い。AI以前の規律に、これを指す名前と作法がすでにあるか。コードレビュー、変更管理、要求定義、品質管理、最小権限。あるなら、出発点は「新しい問題」ではなく「その作法をこの文脈へ翻訳する」だ。

第二の問い。その古い作法が前提していたもののうち、AIが壊すものは何か。壊れる前提がなければ、問題はそのまま古い。作法を当てればいい。壊れる前提を具体的に言えたなら――そこだけが、本当に新しい。

例で言う。「AI生成物のレビューが効かない」。レビューという作法は昔からある。AIが壊す前提は「変更を書いた本人が、その理屈を持ってレビュアーの問いに答える」――その問いを受け取る相手が、AI出力にはいない。関所は残り、答える側だけが不在になった。ここだけが新しく、あとは古い。この線引きができれば、慌てる範囲は驚くほど狭くなる。

なお、この二つの問いは、担い手を決める仕分け（機械判定できるか・可逆か・静かに壊れるか）よりも、さらに手前に立つ。誰に任せるかを決める前に、そもそも既存の作法を当てるべき問題なのかを仕分ける。

「新スキル」を疑う——退屈な標準語に置き換える

見分けができると、ハイプへの耐性がつく。ソフトウェア工学には、銀の弾丸はない――複雑さの本質的な部分は、道具の一新では消えないと、Brooksは1987年に論じた1。派手な新規性の主張は、たいてい本質でなく偶有の部分にかかっている。

だから、嗅ぎ分けの型を持っておく。その「新スキル」は、退屈な標準語に置き換えても興奮が残るか。プロンプトエンジニアリングは、要求定義と仕様化と言い換えた瞬間、多くが古い作法に戻る。そもそもプログラミングとは、文書に書き尽くせない「理論」を頭の中に築く仕事だ、とNaurは1985年に論じた2。この理論を持つ仕事は、AIより前からあり、AIが来ても消えない。新規性を独自に産もうとする衝動は、たいてい、古い規律の再発見で足りる。

この置き換えが言葉の遊びで終わるかどうかは、言葉ではなく道具に当ててみれば分かる。

実在のハーネスを開けると、部品はほとんど古い

いま実際に使われているコーディング・エージェントのハーネスを開けて、中の部品を一つずつ退屈な標準語に置き換えてみる。

Aiderは編集のたびにコミットを一つ挟み、説明を添える。気に入らなければ取り消せる——版管理と可逆性だ。リポジトリの地図は、ファイルを節点・依存関係を辺とするグラフの順位づけで作り、--map-tokens（文書上の既定は1kトークン）という予算におおむね収まる分だけを送る——予算制約下の情報選択。lintやテストが落ちるとその出力を投げ返してやり直させるが、実装はその往復を3回で打ち切る3——暴走しない再試行の上限。どれも、AI固有の新語を必要としない。

SWE-agentは、ファイルを一度に100行の窓で見せ、検索は一致したファイルを簡潔に列挙するだけにとどめる。編集は、構文として正しくなければコマンドそのものを通さない4——ページング、出力の要約、入力検証。ここにも新語はない。

superpowersは、コーディング・エージェント向けの開発方法論を、組み合わせ可能な規律文書（スキル）の集まりとして与える枠組みだ。方法論の側の流れは標準語のままである。何を作りたいのかを聞き出し、仕様に落とし、読める大きさに割って承認を取り、実装計画を書き、red/greenのTDDとYAGNIとDRYを守らせ、各タスクの成果を検査してから次へ進む——冒頭に挙げた「要求を明確にし、仕様に落とし、例で示す」が、そのまま製品の目次になっている。

その中の一枚、スキルの書き方を定める規約は「スキルを書くことは、手順書に適用したテスト駆動開発だ」と自ら書いている。手順は、規律なしの圧力シナリオを与えて破らせ、出てきた言い訳を逐語で採取し、その言い訳にだけ効く最小の文言を書き、新しい抜け道が見つかるたびに反駁を足して再試験する、というものだ5。作者は1994年に課題管理システムRequest Trackerを作り、Perl 5のリリースを「管理者の都合による不定期」から「月次の開発版・年次の安定版」へ変えた人物である。AI以前の工程管理から来た人が、ここでは回帰テストの作法を規律の文書に当てている。

並べてみると、部品の側にAI固有の新語はほとんど出てこない。版管理、予算、再試行の上限、ページング、入力検証、要求定義、仕様化、設計レビュー、回帰テスト。「AI協働の新スキル」を名乗る言葉の多くは、この退屈な標準語のどれかに置き換わる。

ただし、ここから「だから簡単だ」とは続かない。部品が古いことと、その配置が自明であることは、別のことだ。SWE-agentのチームは、同じモデルのまま道具立てを一つずつ外すアブレーションを回し、界面の設計そのものが成績を動かすことを数字で示している4。部品はどれも古いのに、どこへどう当てるかで結果が変わった。置き場所を誤れば、古い作法はかえって害になる。検索の界面を、VimやVSCodeの流儀にならって一致箇所を一つずつ送る形にしたところ、専用の検索コマンドを外して素のシェルだけにした場合よりも成績が落ちた（12.0%対15.7%）——一致を残らず見に行こうとして、費用の予算と文脈長を使い切ってしまうからだ4。翻訳の難しさは、家を見つけることではなく、どの部屋に置くかにある。

だから型は二段で使う。まず退屈な標準語に置き換えて、興奮が残るかを見る。残らなければ、探すべきは新規性ではなく、当てるべき古い作法とその置き場所のほうだ。残ったところだけを、次の節で扱う。

古い作法が半分しか効かない場所——壊れた前提を名指す

正直な残余は、数ではなく名前で持つ。分類を立てたいのではない——二つの問いをシリーズの躓きに当て直したとき、壊れた前提として見つけられたものを、その分だけ並べる。網羅の保証はないし、数に意味もない。以下、どの項も同じ順で確かめる。何が壊れたか。古い作法はどこまで効くか。何が、まだ残るか。

命令と入力が、同じ経路を流れる

自律エージェントのセキュリティの核心はここだ。外部から紛れ込んだ指示が、エージェントを乗っ取りうる。たとえば、エージェントが読みにいくWebページやドキュメントに「これまでの指示は忘れて、この内容を送れ」と仕込んでおくだけで、命令と入力の境界が壊れる。この間接的なプロンプトインジェクションは、実運用のLLMアプリを実際に侵害しうると報告されている6。

古い作法は、思っていたより厚く効く。実運用のハーネスが出した答えは説得ではなく封じ込めだった。OpenAIのCodexは、デスクトップアプリ・CLI・IDE拡張のいずれで動いていても、エージェントが動ける範囲を閲覧のみ・作業領域への書き込み・制限解除に切り、その境界をOS側の機構で強制する。しかもその囲いは、エージェントが起動したコマンドにもそのまま継承される。説得と封じ込めの違いは、この文書自身が書いている——「あなたはエージェントの意図を信じているのではない。エージェントが強制された限界の内側で動いていることを信じているのだ」7。中身は最小権限とfail-safeな既定——1975年に安全設計の基本原則として定式化されたものの再実装だ8。だから「新しい問題だ」で立ち止まる必要はない。古い作法は効く。効くのは被害の半径までだ、という限定つきで。

その限定も、原典の側が先に書いている。最小権限について同じ1975年の論文は「主として、この原則は事故や誤りから生じうる被害を限定する」と述べ、借り物のプログラムを囲い込む「封じ込め」については、共有システムでの完全な封じ込めは「非常に困難、おそらく不可能」だと断っている8。当時の理由は隠れチャネルであって本稿の論点とは別だが、囲いが原理的に取りこぼすという構図の古さは、そこまで遡る。

残るのは境界そのものだ。囲いは、壊れた前提を戻さない。自然言語は同じ一本の経路で命令にもなり入力にもなるので、権限を持つ側が汚染された文脈から指示を受け取る構図——古くは「混乱した代理人（confused deputy）」と呼ばれた型9——は、経路が分かれないかぎり解消しない。これは推論だけの話ではない。先の報告6は、チャット界面なら弾かれるプロンプトが間接的に流し込まれると弾かれないことを確かめており、入出力チャネルにフィルタを積んでいたBing Chatに攻撃が通ったのは、そのフィルタがモデルの外部入力を勘定に入れていないためだろう、と述べている。半径は縛れる。境界は、まだ戻っていない。挙げたなかで、この項目の新しさはいちばん狭い。それでも残る。

事前の正解が、存在しない

物差しのない良し悪しの判定だ。多層防御もレビューも、比べる基準か、懐疑的な人間の査読者を前提してきた。だが「良い文章か」「筋の通った設計か」に、事前の正解はない。

ここでも、古い作法はまず一歩踏み込める。正解を作れるところでは、実務は判断を実行に置き換えている。SWE-benchはパッチの成否を自己申告ではなくリポジトリの実テストで採点する。しかもその採点は最初から二本立てで、課題を解いたかを測る「落ちていたテストが通るようになるか」と、既存の振る舞いを壊していないかを測る「通っていたテストが通り続けるか」——後者は課題1件あたり中央値51本——を、別々に数える10。Aiderの順位表は、正答率とは別の列として「編集書式が正しかった割合」を並べ、内容の良し悪しと形式の遵守を混ぜない3。受け入れテストと回帰テストの分離という古い作法が、そのまま効いている。

残るのは、実行に落とせない良し悪しだ。これは外から言われていることではない。SWE-benchの著者ら自身が、自分の論文の議論の節でこう断っている――実行によるコードテストだけに頼るのでは生成物の信頼できる性能を保証するには足りず、生成されたコードは人手の解に比べて網羅性・効率・可読性でしばしば劣る、と10。実行で採点できる線の先に何が残るかは、採点する側が先に書いている。

その残りに、代理は出た――二つの回答のどちらが良いかを選ばせる形式で、GPT-4を審判に立てると、人間同士の一致率81%を上回る85%で人間の選好に一致した、とZhengらは報告した。比べる相手を用意せず一つの回答に点をつけさせる形式でも一致率はほぼ同じ（85%・84%）で、同論文は審判の側に「比較的安定した内的な基準」があると述べている――手元に比較対象がない場面にこそ効く読み方だ。ただし同じ論文が、位置と冗長さの偏りを実測し、自分の出力を高く買う疑いも挙げている（この最後の一つは、同論文自身が断定を避けている）11。

そしてもう一段厄介なのは、物差しを自前で作らねばならず、作った端から古びることだ。Aiderのコード編集ベンチは、上位のスコアが80%を超えて飽和し、新記録が1〜2問の差でしか動かなくなった。だから作者は6言語・225問の難しい課題へ作り直したが、その新しい物差しでも、公開されている順位表の上位はすでに88%に達している。しかもその順位表自体、2025年10月の測定を最後に新しい記録が入っていない3。物差しは、飽和して次へ引き継がれるとはかぎらない。更新が止まったまま、板だけが残ることもある。参照なしで良し悪しを測る作法の歴史が薄いというのは、こういう意味だ。測る道具を自前で作り、その道具の寿命まで自分で見張ることになる。

自信という信号が、壊れた

自信と正しさのズレは、中身を二つに割ったほうが正確だ。片方は古く、片方だけが新しい。

古い片方は、監視の疲弊だ。使わない技能は鈍るので、自動化に任せるほど、いざ自分の手で引き取るときの腕が落ちる。そのうえ人間はそもそも、めったに何も起きない対象を見張る注意を、三十分ほどしか保てない——Bainbridgeが1983年に、1950年の警戒研究を引いて並べたのがこの両方だ12。四十年以上前に名前がついている以上、これは新しい側ではない。「trust but verify」が疲れない査読者を前提していた、という指摘も、その古い側の内側にある。

新しいのは、信号そのものが壊れていることだ。事前学習だけのモデルは選択肢への確信度と正答率がよく較正されているのに、後工程を経ると較正が崩れると報告されている。同じ節は「GPT-4は自信を持って誤りうる——間違えそうなときに検算をしない」とも書いている13。数値として測られたのは内部の確率のほうで、口調の強さと正しさの関係を定量した測定ではない。それでも、自信の強さを手がかりにできるという前提は、その一段目からすでに崩れている。査読者は、疲れる前の時点ですでに、いつも使っていた目印を一つ失った状態で読み始めることになる。ここが残る。

相手の中身が、合意なく動く

モデル版のドリフトだ。あなたの働き手は、ベンダーの更新で挙動が変わりうる。同じプロンプトへの応答が、版のあいだで変化していくことは実際に観測されている。同一モデル名の2023年3月版と6月版に、素数か合成数かを判定する同じ設問を、同じ「順を追って考えよ」の指示つきで与えたところ、GPT-4の正答率は84%から51%へ落ち、GPT-3.5は逆に6月のほうが良くなった、という測定がある14。

古い作法はここにもある。依存を固定する――版をピン留めし、再現可能ビルドで固める。だが新しいのは、同じ名前・同じ入り口の裏で中身が静かに差し替わることだ。版のスナップショットが提供されているあいだはピン留めできる——上の測定が成り立ったのも、3月版と6月版が別々に呼べたからだ——が、それを出し続けるかどうかは提供者の裁量で、こちらの再現可能ビルドが握れる保証ではない。挙動が変わったと気づいても、行動に移せる変更履歴がない。ここに効く規律を、歴史はまだ持っていない。

候補はもう一つあった。機構が古びること――昨日置いたゲートが、今日はもう何も守っていない、という型だ。二つの問いに当てると、古い作法はある。置いた検査を定期に見直して減らす手続きは、安全管理にも監査にも古くからある。ではAIが壊す前提は何か――答えはこの項と同じ、「相手の中身が、合意なく動く」に落ちる。だから独立の項は立てない。かわりに次の節で、この版ドリフトの裏面――成果物ではなく、こちらの仕掛けの側に出る顔――を書く。

機構は減価する——ゲートを引退させる

版ドリフトを、自分の仕掛けの側から見る。モデルが変われば、出力が変わる。それと同時に、その出力を守るために置いたゲートの値打ちも変わる。

実例がある。SWE-benchとSWE-agentを作ったチームは、2024年に、先に挙げたアブレーションで界面の作り込みが成績を動かすことを測った4。その一年後、同じチームは道具をbashだけに削り、履歴を一直線に追記するだけのエージェントを出して、こう書いている――「一年が経ち、LMがより有能になったいま、その多くは有用なエージェントを作るのにまるごと不要だ」。そして現在、SWE-agentの公式ドキュメントは自らを「mini-swe-agentに取って代わられた」「保守のみのモード」と告知し、そちらへ移ることを勧めている。同じ告知は、後継が「より簡素で柔軟でありながら、性能は同等のままだ」とも書き添える15。減ったのは仕掛けであって成績ではない、というのが本人たちの申告だ。値付けをした本人たちが、その値が下がったと判断して、作り込んだ界面を既定の座から降ろした。ただし消したのではない――道具立てや履歴の扱いを取り替えて比べたいならSWE-agentのほうを使え、と後継のREADME自身が書いている15。実運用での値打ちが減っても、測るための道具としては残る。減価は、リポジトリ単位ではなく用途ごとに起きる。

どちらの判断も、その時点のモデルに対しては妥当だったのだろう。だから引き出すべき教訓は「ゲートは無駄だった」ではない。ゲートの値打ちは、相手の能力の関数だ、ということだ。そして関数の引数は、こちらの合意なく動く。

この型の壊れ方は、シリーズがここまで扱ってきたどちらとも違う。指示は破れても静かで、機構は破れたら赤い。だが値打ちを失った機構は、そもそも破れない。相手が先へ行った分だけ、止めるべき違反のほうが来なくなるからだ。通すべきものは通り、止めるべきものは来ない。だから一度も赤くならないまま、何も守っていない。落ちないから気づかれず、書いてあるから忘れられもしない。壊れずに、課金し続ける。取り立てるのは、たとえばレイテンシ、承認の待ち時間、ゲート自身が食う説明の長さ、正当な操作を止める空振りといったものだ。

この静かな壊れ方は、測られてもいる。先に引いた版ドリフトの測定14は、素数判定の同じ設問に同じ「順を追って考えよ」の指示を置いたまま、その指示がもたらす正答率の上積みが+24.4ポイントから+0.1ポイントへ落ちたことを記録している。原典はその理由を、6月版が指示に従わなくなったことに帰している——同じ設問での平均出力長は638字から3.9字へ縮んだ。指示は消えていない。エラーも出ない。仕掛けは書かれたまま、何も生まなくなる。SWE-agentの引退が人の判断による引退だとすれば、こちらは判断を挟まずに値打ちだけが抜けた例である。

では、いつ外すか。手順はSWE-agentのチームがすでに実演している——道具立てを一つずつ外して測るアブレーションだ。外した状態で測れるなら、測ってから決める。外しても成績が動かないゲートは、置いておく理由のほうを失っている。

ただしここでも、第一の問いが先に来る。外して測れるのは、機械が決定的に採点できる仕事だけだ。採点できないゲートには、別の数え方を当てる。直近に何回発火したか。発火のうち、何回が本物の違反だったか。発火ゼロのゲートは、守り切ったのかもしれないし、守るべきものがそもそも来なかっただけかもしれない。どちらなのかは、回数だけでは分からない――そのゲートが想定した違反を意図して一度通してみて、赤くなることを確かめるところまでやって、初めて数字になる。

そして引退は、片道ではない。モデルが良くなればゲートは要らなくなるが、版が替われば要り直すこともある。版のドリフトは、上にも下にも動く。同じ測定のなかで、GPT-3.5側の同じ指示は逆に-0.9ポイントから+15.8ポイントへ値上がりしている14——同じ機構が、同じ期間に、相手によって上にも下にも動いた。だから引退は一度きりの決定ではなく、繰り返す判定になる。

ここで冒頭の二つの問いに戻る。答えには日付が要る。「これは古い問題か」の答えは、いつのモデルに対する答えなのか。仕分けは、間違っていなかったのに古びる。だから仕分けた結果を書き留めるときは、判定した日と、判定の根拠になったモデルの版を、一緒に書いておく。

古いと新しいを混ぜない——慌てる場所を狭める

だから、二段構えで立つ。ほとんどの問題は、古い規律をこの文脈へ翻訳すれば解ける。慌てて新規性を産む必要はなく、たいていは要求定義とレビューと変更管理と最小権限の再発見で足りる。実在のハーネスを開けても、出てきた部品はその標準語のままだった。

だが、前提が壊れた場所は違う。ここでは古い作法が半分しか効かない。エージェントの安全では、囲いが被害の半径を縛る一方、命令と入力の境界は戻らない。参照なしの評価では、実行に落とせるところまでは古い作法が届き、その先で物差しを自作することになる。確信のズレでは、監視の疲弊に1983年から名前がついているのに、自信の強さが当てにならないことのほうには名前がない。版ドリフトでは、ピン留めは書けるのに、ピン留めを提供し続けるかはこちらの手にない。乏しい注意を、あちこちに撒くのでなく、壊れた前提が見つかった場所に集める。見分けるのは、慌てないためではない。慌てるべき場所を、正しく狭めるためだ。

そして、狭めた場所も、そこに置いた仕掛けも、日付つきだ。冒頭の会議に返す答えは、こうなる。新しい職種は要らない、要求定義と仕様化の翻訳で足りる。ただし、そのAIに外部のページを読ませて動かすつもりなら、そこは前提が壊れている側だ。慌てるのは、そこでいい。そして半年後に同じ会議を開き、そのとき置いた検査がまだ働いているかを、数えて確かめる。

出典15件

  1. F. P. Brooks, “No Silver Bullet—Essence and Accidents of Software Engineering,” Computer, vol. 20, no. 4 (1987). 道具の一新では複雑さの本質は消えない――派手な新規性の主張を疑う支持側（ハイプの多くは偶有の部分）。https://doi.org/10.1109/MC.1987.1663532 ↩

  2. P. Naur, “Programming as Theory Building,” Microprocessing and Microprogramming, vol. 15 (1985). 文書に書き尽くせない「理論」を築く仕事が古くからあることを示す――「多くは昔からある規律」の支持側（AIへの言及は原典にはなく、本稿の当てはめ）。https://doi.org/10.1016/0165-6074(85)90032-8 ↩

  3. Aider（オープンソースのターミナル型コーディング・エージェント）公式ドキュメントとブログ、および実装（2026年8月2日参照）。編集については「aiderがファイルを編集するたびに、説明のついたコミットメッセージでその変更をコミットする」と述べ、/undo で直前の変更を取り消せるとする。リポジトリ地図は「ファイルを節点、依存関係を辺とするグラフの順位づけ」で作り、送る量は「--map-tokens スイッチの影響を受け、既定は1kトークン」と述べる。lint/テストの失敗を投げ返す往復は実装側で上限が決まっており、aider/coders/base_coder.py に max_reflections = 3 と、超過時の警告文「Only 3 reflections allowed, stopping.」がある。ベンチマークについては、旧来のコード編集ベンチが「上位のスコアが80%に迫り、そして超えるにつれて飽和しつつあった」ため、6言語・225問の難しいExercism課題で polyglot ベンチを作り直したと書く。公開されている順位表は「Percent correct」と「Correct edit format」を別の列として並べ、2026年8月2日時点での首位は gpt-5 (high) の 88.0%（2025年8月23日の測定）——作り直した側の物差しも、旧ベンチを飽和と判断した80%の線をすでに越えている。板に載る全69記録の測定日を数えると最新は2025年10月3日で、以後の追加はない（2026年8月9日確認）。月あたりの追加は2025年4月の13件から2025年10月の2件へ落ちて止まっており、いま見えている首位は凍結した板の首位である。モデルが古い物差しを飽和させるほど伸びたというAIに有利な観測であり、同時に、ハーネスの部品（版管理・トークン予算・再試行上限）がAI以前の標準語のままであることの一次例でもある。https://aider.chat/docs/git.html https://aider.chat/docs/repomap.html https://aider.chat/2024/12/21/polyglot.html https://aider.chat/docs/leaderboards/ https://github.com/Aider-AI/aider ↩ ↩2 ↩3

  4. J. Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering,” (2024), arXiv:2405.15793 および公式ドキュメント “Agent Computer Interface (ACI)“（2026年7月26日参照）。ファイル閲覧は「一度に100行を表示するのが最もうまく機能する」、検索は「一致した各ファイルを簡潔に列挙する」、編集は「コードが構文的に正しくなければ編集コマンドを通さない」と述べる。同じモデルのまま道具立てを一つずつ外すアブレーションを回し、界面設計だけで成績が動くことを数字で示した――モデル単体では足りず機械的な足場が要るというAIに不利な側であり、同時に「部品は古いが配置は自明ではない」ことの一次例。本文が引いた数字はその Table 3（SWE-bench Lite、GPT-4 Turbo）で、検索の界面は既定の Summarized が 18.0%、Iterative が 12.0%、No search が 15.7%。原典は leading to even worse performance than the not having additional search tools at all (15.7%↓ 2.3 for No search vs. 12.0%↓ 6.0 with Iterative search) と書く。Iterative は directly inspired by traditional user interfaces for search, e.g., Vim or VSCode と説明されるもので、No search は検索専用コマンドを持たない Shell-only 設定＝an agent performs localization using only standard bash commands and utilities（図5キャプション）を指す。検索道具を丸ごと取り上げた設定ではなく、grep や find は使える。https://arxiv.org/abs/2405.15793 https://swe-agent.com/latest/background/aci/ ↩ ↩2 ↩3 ↩4

  5. obra/superpowers v6.3.0（2026年8月12日リリース）の skills/writing-skills/SKILL.md および README。Anthropicの公式プラグインマーケットプレイスからも導入できる開発規律フレームワークで、README は自らを「コーディング・エージェントのための完全なソフトウェア開発方法論であり、組み合わせ可能なスキル群と、エージェントにそれを確実に使わせる初期指示の上に築かれている」と説明する。「How it works」の節が並べる流れ——本当は何をしたいのかを聞き返す、対話から仕様を引き出して読める大きさに割って見せる、承認後に実装計画を書く、red/green の TDD と YAGNI と DRY を重んじる、サブエージェントに各タスクを進めさせて検査とレビューを挟む——は、本稿が挙げた退屈な標準語そのものである。スキル（規律文書）の書き方の規約として「スキルを書くことは、手順書に適用したテスト駆動開発である（Writing skills IS Test-Driven Development applied to process documentation）」「失敗するテストなしにスキルを書くな（NO SKILL WITHOUT A FAILING TEST FIRST）」を掲げ、規律なしの圧力シナリオでモデルに規律を破らせ、出てきた合理化の文言を採取してから、それに効く反駁だけを書く、という手順を定める。この出典は上流の改稿が速いが、ここで引いた3つの逐語（README の自己説明、TDD の宣言、鉄則）はいずれも v5.1.0 から v6.3.0 まで同文で、当該スキルの本文は v6.2.0 以降まったく動いていない。規律文にここまでの回帰テストが要るのは、モデルが規律から言い逃れるからで、その意味でAIに不利な側の証拠。作者Jesse VincentはRequest Tracker（1994年）の作者で、Perl 5.12・5.14のリリース管理者として同言語のリリースを不定期から月次の開発版・年次の安定版へ変えた（経歴は https://en.wikipedia.org/wiki/Jesse_Vincent で確認）。https://github.com/obra/superpowers/blob/v6.3.0/skills/writing-skills/SKILL.md ／ https://github.com/obra/superpowers/blob/v6.3.0/README.md ↩

  6. K. Greshake et al., “Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection,” AISec (2023), arXiv:2302.12173. 外部から紛れ込んだ指示がLLMアプリを実際に侵害しうると報告――自律エージェントのセキュリティが古い作法で塞ぎきれない留保側。原典は LLM-Integrated Applications blur the line between data and instructions（抄録）、the data and instruction modalities are not disentangled（§4.2）と、命令と入力が切り分けられていないことを自ら二度書いている。防御についても prompts that are typically filtered out via the chat interface are not filtered out when injected indirectly（§4.2）、our attacks succeed on Bing Chat, which seems to employ additional filtering on the input-output channels without considering the model's external input（§5.3）と観測し、緩和策は hard to imagine a foolproof solution と結ぶ。射程: 実証の対象は Bing Chat（GPT-4、実運用のブラックボックス）と GitHub Copilot、および GPT-4 上の合成アプリ。ただし注入の配信は Edge サイドバー経由のローカルHTML（コメント内）で、検索索引を介した公開注入は「他の利用者に害が及ぶのを避けるため」あえて実施していない（§5.2）。本文が例に挙げた「エージェントが読みにいくWebページ」という経路について、原典は原理的には成立すると考える旨を述べるにとどまる。https://arxiv.org/abs/2302.12173 ↩ ↩2

  7. OpenAI Codex 公式のサンドボックス解説（2026年8月9日に再参照し、以下の記述が現行であることを確認）。この文書は Codex CLI 専用ではなく、冒頭で「ChatGPTデスクトップアプリ、Codex CLI、IDE拡張のいずれでローカルの対話がコマンドを走らせる場合も、それらは既定の全権ではなく制約された環境の内側で走る」と述べ、面をまたいで考え方は同じだとする。サンドボックスの主な段階を read-only（閲覧のみ、編集やコマンド実行には承認が要る）／workspace-write（作業領域内の編集と定型コマンドまで。低摩擦の既定）／制限解除に分け、「Codexは各OSのプラットフォーム固有の強制機構を使う」——macOSは組み込みのSeatbelt、LinuxとWSL2はbubblewrap、WindowsではネイティブのWindowsサンドボックス——と述べる。さらに「サンドボックスは組み込みのファイル操作だけでなく、起動されたコマンドにも適用される。エージェントがgitやパッケージマネージャやテストランナーを走らせれば、それらのコマンドも同じ境界を継承する」と明記する。節「Why it matters」は You aren't just trusting the agent's intentions; you are trusting that the agent is operating inside enforced limits.（あなたはエージェントの意図を信じているのではない。エージェントが強制された限界の内側で動いていることを信じているのだ）と述べ、冒頭では The sandbox defines technical boundaries. The approval policy decides when the agent must stop and ask before crossing them. と、囲いと承認が別々の制御であることを明示する。エージェントの安全を「説得」ではなく古典的な封じ込めで扱えているというAIに有利な側の実装例（製品ゆえ更新されうる）。https://learn.chatgpt.com/docs/sandboxing ↩

  8. J. H. Saltzer & M. D. Schroeder, “The Protection of Information in Computer Systems,” Proceedings of the IEEE, vol. 63, no. 9 (1975). 最小権限とfail-safeな既定を安全設計の基本原則として定式化した古典。実運用ハーネスの封じ込め（サンドボックス、権限の剥奪）はこの原則の再実装であり、「エージェントの安全は丸ごと新しい」という見立てを弱める側。縛れるのが被害の範囲であることは原典自身の記述で、最小権限の説明の第2文が Primarily, this principle limits the damage that can result from an accident or error（主として、この原則は事故や誤りから生じうる被害を限定する）と述べる。命令と入力が同一経路であること自体がこの原則の対象外だ、という接続のほうが本稿の当てはめ。同論文はさらに、借り物のプログラムを囲い込む「封じ込め（confinement、Lampsonによる語）」について Complete confinement of a program in a shared system is very difficult, or perhaps impossible, to accomplish と書く。ただしその理由はページング率の変動などの隠れチャネルによる情報漏出であって、本稿が論じる命令と入力の混線とは別の機構である。なお原典はfail-safeな既定をE. Glaser（1965年）、権限の分離をR. Needham（1973年）に帰しており、1975年の時点ですでに既存の作法を集めたものだと自ら書いている。https://doi.org/10.1109/PROC.1975.9939 ↩ ↩2

  9. N. Hardy, “The Confused Deputy: (or why capabilities might have been invented),” ACM SIGOPS Operating Systems Review, vol. 22, no. 4 (1988)。著者自身が「ほぼ実話」と断って書く事例——権限つきのコンパイラが、利用者に指定されたファイル名をそのまま自分の権限で開き、同じディレクトリにあった課金情報を上書きしてしまう。著者は、コンパイラのコードのどこを直せば防げたかを順に潰していったうえで（出力先を利用者が指定できること自体は正当、ディレクトリ名の走査も無効、機微なファイル名の列挙も破綻する）、壊れているのは「誰の権限で、誰の指図を実行しているのか」を経路上で区別できない構図のほうだと論じる。汚染された文脈から指示を受け取るエージェントに同じ型が再現しているというのは本稿の当てはめであり、原典はLLMに言及しない。doi:10.1145/54289.871709（著者版 https://cap-lore.com/CapTheory/ConfusedDeputy.html は2026年8月時点で TLS 検証に失敗するため、読むなら https://web.archive.org/web/2023/https://cap-lore.com/CapTheory/ConfusedDeputy.html ） ↩

  10. C. E. Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR (2024), arXiv:2310.06770. パッチの成否を自己申告でなくリポジトリの実テストが通るかで採点する――参照を作れる領域では「参照なし評価」の問題が実行による検証へ落ちる、という支持側。テストは二種に分けて数えられており、課題を解いたかを測る fail-to-pass（原典 §2.3「これらのテストは、モデルが課題文の問題に対処したかを評価する」）と、既存の振る舞いを壊していないかを測る pass-to-pass（同「revision が既存の期待される振る舞いを壊したり侵したりしないことを保証するために含まれる」）で、後者は課題1件あたり中央値51本が追加で走る。同じ論文の §7 Discussion は、その採点方式の限界も自ら書いている――while this work evaluates models using execution-based code testing, relying solely on this method is insufficient to guarantee reliable performance of model generations, as we find automated code generations from LMs can frequently be less comprehensive, efficient, or readable compared to human-written solutions. https://arxiv.org/abs/2310.06770 ↩ ↩2

  11. L. Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena,” NeurIPS Datasets and Benchmarks (2023), arXiv:2306.05685. GPT-4を審判にすると人間同士と同程度の8割超で人間の選好に一致すると報告する（抄録は over 80% agreement, the same level of agreement between humans。本文 Table 5 の S2 条件＝タイを除く実数では、対比較のGPT-4と人間の一致が85%、人間同士が81%で、even higher than the agreement among humans と書かれている）。比較対象を用意せず一つの回答に点をつけさせる single-answer grading でも一致率は85%・84%で、GPT-4 has a relatively stable internal rubric と述べる。一方で、位置・冗長さの偏りは実測して報告する。自己優遇だけは扱いが違う——GPT-4は自分を10%、Claude-v1は25%高く評価する一方で他モデルも優遇し、GPT-3.5 は自分を優遇しない。同論文は Due to limited data and small differences, our study cannot determine whether the models exhibit a self-enhancement bias と、存在を断定していない（抄録は三つを並べて挙げるので、抄録だけ読むと三つとも確立した所見に見える）。参照なし評価に使える代理はあるが偏りが残るという両面。https://arxiv.org/abs/2306.05685 ↩

  12. L. Bainbridge, “Ironies of Automation,” Automatica, vol. 19, no. 6 (1983). 自動化で使わない技能は鈍り、そもそも人間は低頻度事象の監視を長く続けられない――「trust but verify」が疲れない査読者を前提していた限界を突く留保側。この指摘が四十年以上前に名前を得ている事実自体が、本稿では「監視の疲弊は新しい問題ではない」の根拠にあたる。https://doi.org/10.1016/0005-1098(83)90046-8 ↩

  13. OpenAI, “GPT-4 Technical Report,” arXiv:2303.08774 (2023), Section 5。事前学習のみのモデルは確信度と正答率がよく較正されているが、後工程を経ると較正が崩れることを、MMLUサブセットの選択肢logprobを使った信頼度図で示す（ECEは0.007から0.074へ）。同じ節は較正の記述の直前で GPT-4 can also be confidently wrong in its predictions, not taking care to double-check work when it's likely to make a mistake. とも述べている。数値として測られたのは内部の確率のほうで、口調の強さと正しさの関係を定量した測定ではない（そこが本稿の留保の範囲であり、「自信ありげに誤る」こと自体は原典の記述である）。AIに不利な側の一次報告。 https://arxiv.org/abs/2303.08774 ↩

  14. L. Chen, M. Zaharia & J. Zou, “How Is ChatGPT’s Behavior Changing over Time?” (2023), arXiv:2307.09009. v3 (2023-10-31) 時点。同一モデル名でも版のあいだで挙動が変わりうると観測――モデル版ドリフトに対応する規律を歴史が持たない留保側。本文が引いた 84%→51% は Chain-of-Thought プロンプトを与えた条件の値で、CoT なしなら 59.6%→51.0%（Table 1）。同じ Table 1 が、CoT の上積みそのものの減価も測っている――GPT-4 では +24.4ポイント（3月）から +0.1ポイント（6月）へ落ち、GPT-3.5 では逆に -0.9ポイントから +15.8ポイントへ上がる。なお6月のGPT-4の上積みは、Table 1 の欄では +0.1% だが、同じ表のキャプションと §3.1 本文は dropped to -0.1% in June / the accuracy was actually 0.1% worse と書いており、原典の中で符号が揺れている。ここは表の欄と、その根拠になる 51.0%→51.1% に従った。上積みが消えたという読みはどちらでも変わらない。原典は落ち込みの理由を、6月版が CoT の指示に従わなくなったことに帰しており（the new version did not follow the CoT instructions）、同じ課題での平均出力長は 638.3字から 3.9字へ縮んでいる（§3.1）。https://arxiv.org/abs/2307.09009 ↩ ↩2 ↩3

  15. SWE-agent/mini-swe-agent の README（SWE-bench・SWE-agent を作った同チーム、2026年7月26日参照）。「SWE-agentは2024年にAIエージェントの開発を加速させた。当時、我々は道具とエージェント専用の界面を重視した。しかし一年が経ち、LMがより有能になったいま、その多くは有用なエージェントを作るのにまるごと不要だ」と書き、bash以外の道具を持たず履歴を一直線に追記するだけで「SWE-bench verified で74%超」と主張する（本人らの主張であり、我々は再現していない）。約100行はエージェント本体（agent class）の行数で、環境・モデル・実行スクリプトはそれとは別にある。あわせてSWE-agent側の公式ドキュメントは「SWE-agentはmini-swe-agentに取って代わられた」「SWE-agentは現在、保守のみのモードにある」と告知し、mini-swe-agentへの移行を勧めている。同じ告知は移行を勧める理由も並べて書いており、後継を mini-swe-agent is simpler & more flexible while still being as performant（より簡素で柔軟でありながら、性能は同等のまま）と評する（同じ趣旨はSWE-agent側のREADME冒頭のバナーにもある）。＝移行の理由は開発資源の都合ではなく、同じ成績がより少ない仕掛けで出るようになったこと、と本人たちが述べている。ただし減価は用途ごとに起きる——mini側のREADMEは、道具立てを取り替えて比べたい場合と履歴処理を取り替えて比べたい場合はSWE-agentを使え、と明記している。機構の価値がモデルの能力とともに減衰し、実際にゲートが引退させられた事例＝AIに有利な側（README・公式ドキュメントとも2026年8月12日に再取得して上記の文言が現行であることを確認）。https://github.com/SWE-agent/mini-swe-agent https://swe-agent.com/latest/background/aci/ ↩ ↩2

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