AIモデルは進化しているのに、なぜ開発ツールは退化しているのか？

最新のAIモデルは驚異的な進化を遂げている一方で、それらを扱うための開発ツールや周辺エコシステムは、かえって使い勝手が悪くなったり、複雑さが増したりしていませんか？本質的な生産性を妨げる現在のツールチェーンの現状について、皆さんの意見を聞かせてください。

クローズドソースのクラウドLLMの弱点を延々と突く記事には批判的な俺だけど、この記事はかなりいい。単にPiに関する話だからというだけじゃない。Piは、オープンソースのハーネス（連携フレームワーク）の準リファレンス実装のような立ち位置になりそうだし、何より技術的な詳細がすごく有益だ。

ただ、これには考えさせられる：

「今、我々が進んでいる道筋が少し心配だ。代替のツールスキーマは、単に馴染みがないだけではないかもしれない。特定の、寛容なツールエコシステムに最適化されたポストトレーニングによって、暗黙のうちに罰せられている可能性があるからだ」

暗黙のうちに、か……。

--

何十年も前、MOO（MUD Object Oriented）を学習環境として使う研究をしていた頃の話。MOOオブジェクトが生成するテキストストリームの中に「ツールコール」を埋め込んで、リッチクライアントが画像を表示したり、フレーム内でWebページを読み込んだり、地図上で移動させたり、画面上のオブジェクトの見た目を変化させたりできるようにしていたんだ。

MUD/MUSH/MOOクライアントでこれを試みた全員が、今のLLMクライアントと同じような問題にぶち当たった。制御シーケンスをインバンドのコンテンツに無理やり押し込む試みは、セキュリティリスクだらけで、オブジェクトが誤ったインターフェースを不用意に起動したりした。アウト・オブ・バンドで真に通信することは不可能だったんだ。

エージェント向けのハーネスの仕組みについて読めば読むほど、20代の頃にMOOクライアントで書いたあのコードに対して、恥ずかしさは薄れていくよ。

自分のハーネスでは、patch -p1用のunified diffをそのまま受け取るapply_patchを実装したんだけど、モデルがいかにdiffの生成が苦手かを見て愕然としたよ。diff失敗をログに記録して分析してみたところ――

• すべてのモデルがまともなdiff用の行番号生成において壊滅的。期待するのはやめたほうがいい。

• 一部のモデル（Owl-alphaなど）はCodexのトランスクリプトでポストトレーニングされているようで、たまにV4Aパッチ形式を、それが使えないdiffツールにも無理やり適用しようとする。

• Codexはシステムプロンプトにパッチ形式についての情報を大量に詰め込んでいて、粒度の細かい修正ではなく大きな塊（hunk）を作らせようとするんだ。

ハーネス側がモデルごとにシステムプロンプトを持つ必要が出てくるかもね。リトライでなんとかなるにしてもさ。昔、ブラウザごとにHTMLやCSSの解釈が違っていて、デバイスによっても表示がバラバラだった時代を思い出すよ。そういう意味では、新しい話じゃないのかも。せめてデバイスの種類が違わなければ、と言おうと思ったけど、モデルはモデルで適切なgrepのバリアントを出力しなきゃいけないんだしな。

モデルに有効なJSONを出力させることはできる

いつも上手くいくわけじゃないよ。より良いパフォーマンスを得るためには、膝をついてお願いするしかない。

Fableについて興味があるなら：彼らが動かしている分類器が、自分を黙ってOpusから格下げしてしまうかもしれないと確信が持てなかったので、意図的にテストしなかった

これってまだあるのか？Anthropicはサイレント格下げを撤回したと思ってたよ。今ではすべてのドメインで非サイレントに格下げされるようになったはずだろ。

自分のサーバーレスバックエンド（https://saasufy.com/ ）用のエージェント統合を構築する際、MCPを使うのはやめて、スキル用Markdownファイルの中にcurlコマンドを直接記述することにしたよ（https://github.com/Saasufy/skills ）。

curlコマンドは圧倒的に普及しているから、モデルはそれを使いこなすのが本当に得意みたいだ。

それに、curlはbashの構文を使っていて、プラットフォーム側はJSONペイロードを要求するという分離がエージェントにとっても明確なのが気に入ってる。かなり信頼性が高いと感じているよ。

いまだにモデルがツールをテキストとして出力していることに驚くよ。もうずっと前から、推論エンジンレベルで出力を制限したり、モデルが使えるツールやパラメータを制限したりできるのに。

編集：見つけた。これだね「Grammar-Constrained Decoding (GCD)」。

まさにうってつけの記事！AIインフラ/ツールエンジニアとして（hic-ai.com）、主力製品の「HIC Mouse」を開発してる。これは幅広いモデルやハーネスで動作するように設計されたコーディングエージェント向けの精密編集システムだ。MouseはMCPを介して11個のツール（読み取り、検索、編集操作）を提供していて、座標ベースのスキーマ（正確な文字列置換や複数箇所の置換も可能）や、エージェントによるステージングとレビューを強制するダイアログボックス機能を備えている。また、エージェントが破壊的な操作や過剰な出力をしようとしていないか判断するガイドメカニズムも充実させているよ。

確かにモデルは特定の人気ハーネスを使うように学習されていたり、編集ツールで特定のフィールドを期待するように調整されている可能性はあるね。特定のフォーマットに適合させようとするのではなく、多様な入力やツールコールを柔軟に扱えるように設計するのが自分のアプローチだ。ツールコールが失敗した時にエージェントが復旧できるようにしたり、妥当な範囲で結果を自動正規化したりね。これだけでも劇的に違うんだよ（有意義な進歩だと確信していなければリリースなんてしなかったさ）。とにかく、この問題を毎日どっぷりと考えている立場から、自分の視点を共有したかった。

Piに読み取り/書き込み/編集用のツールなんて必要なの？全部bashコマンドにして、何でもモデルにsedを使わせればいいんじゃないか？

心配なのは、呼び出しが失敗することじゃないんだ。呼び出し自体は正しくても、余計なフィールドが混入してくるのが問題なんだよ。そうなると、ランタイムが単なる実装の詳細ではなく、モデルのインターフェースの一部であるかのように感じられてしまう。寛容な環境でモデルをトレーニングすると、他のランタイムまでその癖を引き継ぐことになってしまうんだ。