AIエージェントに今必要なのは『プロンプト』ではなく『制御フロー』だ

AIエージェントの進化において、プロンプトエンジニアリングで精度を上げようとするアプローチには限界が来ている。今、真に求められているのは、LLMに複雑な指示を詰め込むことではなく、プログラムのような明確な「制御フロー（ロジック）」を組み込むことではないだろうか。プロンプトの継ぎ接ぎで苦労するよりも、構造化された実行制御こそが、エージェントを実用レベルへ引き上げる鍵になる。

共感はするんだけど、結論は少し変えた方がいいと思う。プロンプトの限界に達したら、タスクをこなすためにランタイムでLLMを使うのをやめて、タスクをこなすためのソフトウェアを書かせる方向にシフトすべきだ。ランタイムにおけるLLMの役割は、厳格なビジネスルールを組み込んだソフトウェアに対して、ユーザーが準拠した入力を選べるように補助する程度に収まっていくはずだよ。

だからこそ私は、単なるLLMではない「次世代AI」という言葉をよく使うんだ。LLMはかなりクールだし、仮にAIの基礎技術がこれ以上進歩しなくても、これまで以上に興味深い方法で活用され、最適化が進むだろう。たとえモデルが今のままで凍結されたとしても、使い方の工夫次第で引き出せる価値はまだまだあるからね。

とはいえ、基礎的な次世代の進化が必要だと感じる部分もある。LLMが「絶対にXするな」という指示を曖昧にぼかしてしまい、いくら工夫しても、結局それを「Xしてくれ」という指示のように解釈してしまう挙動は、LLMの根本的な仕組みそのものに起因しているように思える。今はLLMに何ができるかを模索する初期段階で（すでに多くの発見があるにもかかわらず）つい見失いがちだけど、LLMは私たちがAIに求めるすべてではない。

「絶対にXするな」という指示を人間と同じように理解できるアーキテクチャが必要だ。また、単なる「コンテキストウィンドウ」ではなく、私たちのようなメモリ階層を持つべきだ。例えば、同じ初期状態のAIと2人の人間が十分に長い対話をしたら、結果として出来上がる2つのAIは、コンテキストウィンドウが違うだけでなく、それぞれ別個の「人格」を持つようになるようなね。

もちろん、それが具体的にどんな姿をしているかなんて誰にもわからないけど、LLMがAIの到達点だと考える理由はどこにもないと思うよ。

そもそもLLMの使い所を間違えているのが問題なんじゃないかな。あちこちで言われているように、エージェントへのプロンプトは、タスクを可能な限り再現性・検証可能性・決定論的な方法でこなすためのコードを書かせるべきなんだろう。理想を言えば、エージェント自身の出力の検証もそこに含めるべきだ。最終的なゴールは、プログラムでより効率的（かつ正確）に処理できる部分にLLMを関与させないことにある。

文言が単なる提案に過ぎず、関数がハルシネーション（幻覚）を起こしながら「成功」を返すようなプログラミング言語を想像してみてほしい。推論は不可能になり、複雑さが増すにつれて信頼性は崩壊する。

これって本質的には宣言的プログラミングの話だよね。従来のプログラミングの多くは命令型で、ほとんどの開発者が慣れ親しんでいるのは「正確な手順を指示し、書いた通りに実行されることを期待する」というスタイルだ。一方、エージェントは命令型というより遥かに宣言的。結果を与えれば、そこに至るプロセスはエージェントが考えてくれる。もちろん問題なのは、SQLのような宣言的なものなら結果は一貫して定義されるけれど、それでも裏側のエンジンがどう処理するかは信用しなきゃいけないという点だ。

エージェントを無理やり制御するようなルーブ・ゴールドバーグ的なシステムを設計するより、宣言的な考え方をする方が自分にはしっくりきた。うまくいかなかった？OK、正しくないと判定できたから、次は別の方法で試そう、という風にね。

どうしても命令型で動かしたいなら、そう記述すればいい。あるいはエージェントに書かせればいいんだ。この手の議論は、目的のために間違った道具を使おうとして苦戦しているように見える。

私が見る限り、現状のLLM用ハーネスはすべてこの点で的外れだ。中には深刻なものもある。

例えばスラッシュコマンドなんて、悪い機能の代表例だよ。コンテキストウィンドウの状況や、そのセッションでいくら使ったかを確認するためだけに、チャットボットが応答を終えるのを待たなきゃいけないなんておかしい。制御機能はチャットのループとは直交しているべきだ。

テキスト生成の入出力制御と全く関係ない機能まで、単に「チャットだから、IRCボットを動かしてるふりでもしようぜ」といった理由でチャットのアクションに紐付けられている。

今やLLMエージェントはごまんとあるけれど、制御とエージェントループ、そして提示内容をうまく分離できているものは皆無に近い（少なくともヘッドレスモードがあるやつは少しまともだけど）。

1000%同意。Anthropicが繰り返す「将来のモデルの性能を見越して開発しろ、もっと良くなるから」というお題目は、ますます信用できなくなっている。

私たちのチームでは、ブラウザセッション内で200個の要件定義ファイルをチェックするQAエージェントを動かしている。チームの効率向上に貢献してくれたクールなシステムだ。長い間、「このディレクトリの要件ファイルを見て、各ファイルについてアプリケーションが要件を満たしているか判断し、TODOリストを作成せよ」というプロンプトを機能させようと試行錯誤してきた。つまり、モデルに高レベルな制御フローを管理させようとしたんだ。

でも、30ファイルを超えたあたりで崩壊し始めた。ファイルをスキップしたり、同じファイルの束を3回もテストして、3分で終わるはずが10分かかったり。一つのファイルでエラーが出ると、なぜか前の4つのファイルまで再テストが必要だと思い込んだりして、本当にフラストレーションが溜まった。テストの結果、モデル（確かOpus 4.6とGPT 5.4）のワークフロー管理能力には一貫性が全くないことがわかった。うまくいったり、いかなかったり。Opus 4.7やGPT 5.5でも試したけど、傾向は同じだった。

結局、モデルの周りに超シンプルな決定論的ハーネスを作ることにしたよ。各テストケースに対してモデルを呼び出し、結果を配列に保存し、ファイルに書き出す。これだけで信頼性が何億倍も高まった。でも、こうなるとCursorのCloud AgentsやAnthropicなどの管理型エージェントプラットフォームでは動かせなくなってしまう。「エージェントが全部やるべきだ」というバイアスに囚われすぎていて、適切な場所に少しだけ決定論的なロジックを加えるだけで、どれほど価値あるシステムになるかが理解できていないんだ。

プロンプト強制 > 決定論的フロー > プロンプト強制と一周回ってきた者として反論させてもらう。

「スキップするな」が失敗する理由は、エージェントに多くのことを任せすぎているからだ。コンテキスト内に余計な情報が混ざっていて、その指示への注意が逸らされているんだよ。

でも、強制力を担うエージェントと構築を担うエージェントが同一人物である必要はないと言ったはずだ。決定論的な制御フローに賢い判断ロジックを組み込むこともできるだろうけど、そうすると柔軟性がなくなるか、あるいは複雑になりすぎて、それならエージェントをそのまま使った方がセットアップも保守も安上がりだという結論になる。

結局、ベースとなる3つのエージェントが必要なんだ。

• ループを管理し、何かあったら軌道修正するスーパーバイザー
• タスクを適切なエージェントに割り振り、ガードレールを適用するオーケストレーター
• 作業を実行するワーカー。これらはタスクに応じて多様な形を取る。

だから私はデータ駆動型のリアルタイムアプリを作るためのエージェントツールとして https://saasufy.com/ を作ったんだ。

14年前に少しずつ作り始めて、当初はジュニア開発者が柔軟性を保ちつつ、必要なセキュリティやスケーラビリティのガードレールを確保できるようにすることを目標にしていた。実際かなり柔軟で、Saasufyの大部分自体がSaasufyで構築されているくらいだよ。カスタムのバックエンドコードは、実際のユーザーサービスとオーケストレーション部分だけだ。

また、ユーザーが認証、アクセス制御、スキーマ検証といった重要な概念を素早く学べるように設計した。結局、ジュニア開発者が必要とするこれらの要素は、LLMが必要とするものと全く同じだったんだ。

最初Claude Codeでテストした時は一貫して素晴らしい結果が出たし、最近GPT 5.5を搭載した https://pi.dev でテストしても同等のパフォーマンスだった。

これは制御フロー層の先にあるべきものの重要性を示唆していると思う。エージェントが境界のあるワークフローを実行した後、チームには依然として、エージェントがどのような権限・スコープを持ち、どの成果物に触れ、どんな検証が走り、どんな証跡が残され、そしてどのような制限が残っているかをレビューできるオブジェクトが必要だ。ログは有用だけど、それはアクションの完了証明書とは別物だからね。

実はこのことについてずっと考えていたんだ。これは専門化（スペシャライゼーション）の議論にも通じる。モデルに求められる専門性が高ければ高いほど、基礎能力は低くなるように感じる。逆に、ほんの少し抽象化を目指すだけで、両方のいいとこ取りができるかもしれない。

かなり具体的な例だけど、思考の糧になればいいなと思ってシェアするよ。

ポッドキャスト（20分要約）:
https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.html

論文:
https://arxiv.org/abs/2605.00225