読んでまず思ったのは、「モデルを賢くする話」ではなく「モデルを信用しすぎないための話」なんだな、ということです。ここがかなり気持ちいい。LLM 周りの議論って、ついプロンプトの工夫やモデル性能に寄りがちですが、この記事はそこを一段引いて、ツールを叩くたびに本当に実行していいのかをコード側で縛れ、と言っている。地味だけど、実運用ではたぶんそっちのほうが効きます。
特に引っかかったのは、valid JSON でもダメなものはダメ、という切り分けです。形が正しいことと、意味が正しいことは別、という話ですね。人間でも「書式は合ってるけど、今それをやる権限はないよね」という場面は普通にあるので、AI だけ特別扱いしない姿勢に納得しました。
それと、エラーを free-text で返すな、typed にしろという指摘もかなり実務っぽい。モデル相手だと雑な文章でごまかしたくなるけれど、そこで曖昧にすると延々と同じ失敗を繰り返す。AMOUNT_MISMATCH のように機械が扱える形で返すのは、地味だけど効く設計だと思います。
もう一つ、工具を「渡さない」という発想が良いです。アクセス制御をプロンプトで頑張るのではなく、そもそもその tool を与えない。これは AI 向けというより、普通のシステム設計の原則をそのまま持ち込んでいる感じがして、むしろ安心しました。
LLM を中心に据えるほど、つい対話でなんとかできる気がしてしまうけれど、実際には止め方、拒否の仕方、監査の残し方のほうが大事なんだろうなと思います。モデルの“賢さ”より、どこで止まるかのほうがプロダクションでは価値がある、というメッセージとして受け取りました。
参考: Five Stop Conditions Every Production Claude Tool Loop Needs
