AIエージェントを作るとき、つい「もっと丁寧に指示を書こう」「この手順もプロンプトに入れよう」と考えがちです。
でも今回の記事は、そこにかなりハッキリしたツッコミを入れています。
要するに、
複雑なタスクを安定してこなすエージェントには、長いプロンプトよりも、ソフトウェアとしての deterministic control flow（決定的な制御の流れ）が必要だ
という主張です。
これ、かなり本質的だと思います。地味だけど重要。むしろAI開発の“あるある”を刺してくる話です。
この記事の中心メッセージはシンプルです。
AIに「ちゃんとやって」と強く言うより、間違いにくい仕組みを作ったほうがいい
人間相手なら、多少あいまいな指示でも、文脈を読んでうまくやってくれることがあります。
でもLLMは、そういう期待をするとたまに平気で外してきます。しかもそれっぽく。
記事では、MANDATORY や DO NOT SKIP みたいな強い文言をプロンプトに書き始めたら、それはもう「プロンプトで頑張る限界点」に来ている、と言っています。
これはかなり共感できます。私も、プロンプトを盛れば盛るほど「これ、もう設計で解決すべきでは？」と思うことがよくあります。
記事のたとえがわかりやすいです。
「命令文が suggestion（提案）扱いで、function が “Success” を返すのに hallucinate（それっぽい嘘を出す）するようなプログラミング言語」を想像してみろ、と。
かなり乱暴なたとえですが、言いたいことは明確です。
つまり、推論や検証がしづらいんですね。
これはソフトウェアとしてかなり致命的です。システムが大きくなるほど、「なんとなくうまくいっている」は危険になります。
記事では、ソフトウェアがスケールする理由として、recursive composability を挙げています。
これは簡単にいうと、
小さな部品を組み合わせて、より大きな仕組みを作れること
です。
たとえば、
こうした構造があると、「この部品はこう動く」と局所的に理解できます。
要するに、予測できるんです。
一方で prompt chain は、似たようなことをやろうとしても、どうしても性質が弱い。
文で文をつないでいく方式は、柔軟ではあるけれど、厳密さや検証可能性で負けやすい。ここが痛いところです。
記事の重要ポイントのひとつがここです。
ロジックを文章（prose）から実行時の仕組み（runtime）へ移せ
つまり、
「LLM に全部考えさせる」のではなく、決めるべきことはコードで決める、という考え方です。
たとえば、
こういうものは、自然言語の指示文よりも、プログラムの if / else や state machine で書いたほうがずっと堅いです。
個人的には、ここがこの記事でいちばん大事だと思います。
AI開発って、つい「モデルに頑張らせる」方向へ行きがちですが、実際には頑張らせるより、迷わせないほうが強いことが多いんですよね。
記事では、信頼性のために deterministic scaffolds が必要だと述べています。
これは直訳すると「決定的な足場」みたいな感じですが、要するに、
を持つ枠組みのことです。
LLMはその中で使う部品であって、システム全体の主役ではない。
この発想はかなり健全です。
LLMは便利ですが、万能ではありません。
文章を作る、候補を出す、要約する、といった用途では強い。でも、「正しさが大事な処理の流れ」まで任せると危ない。
この線引きは、これからのAI設計でかなり重要になると思います。
記事が鋭いのはここです。
LLMベースのシステムは、ときにsilent failure（失敗しているのに失敗に見えない）を起こします。
これ、普通のソフトウェアより厄介です。
このタイプの失敗は、人間の直感をかなりだますんですよね。
「動いてるっぽいから大丈夫」と思った瞬間に危ない。個人的には、この手の“静かな失敗”が一番怖いです。
だから記事は、aggressive error detection、つまり「かなり強めのエラー検出」が必要だと言っています。
ふわっと見守るだけでは足りない。ちゃんと機械的にチェックしろ、というわけです。
記事の最後の整理が、かなり皮肉が効いていて好きです。
プログラム的な検証がないと、結局やれることは次の3つだとしています。
Babysitter
人間がそばで見張って、ミスを止める
Auditor
実行後に、最初から最後まで厳密に検証する
Prayer
なんとなく信じる、いわば「Vibe accept」
この3つ、かなり本音で笑ってしまいます。
特に最後の Prayer。AIプロダクトの現場で、心の中ではこれに近い運用になっているケース、正直あると思います。
でも本来は、祈るしかない設計にしてはいけない。
ここがメッセージの肝でしょう。
この記事は、単に「プロンプトよりコードが大事」と言っているだけではありません。
むしろ、
LLMを使うなら、ソフトウェア工学の基本に戻れ
と言っているように読めます。
プロンプトは魔法の呪文ではないし、長くすれば賢くなるわけでもない。
複雑な仕事を任せるなら、必要なのは「うまい言い回し」より「失敗しにくい構造」です。
これは、AIを“会話相手”として見るか、“部品”として見るかの違いでもあります。
私は後者の見方のほうが、実務ではずっと強いと思います。
少なくとも、ちゃんと信頼できるシステムを作るなら、感覚より設計です。
この元記事が言いたいのは、かなり一貫しています。
AIエージェント開発が進むほど、
「どれだけ賢いか」より「どれだけ壊れにくいか」が大事になるはずです。
この記事は、その当たり前だけど見落としがちな点を、かなり気持ちよく言語化していました。
