AIエージェントに必要なのは長いプロンプトでなく「制御フロー」──1本の短いブログ記事がHacker Newsで広く共有された理由

AIエージェントへの指示文に「MANDATORY（必須）」「DO NOT SKIP（絶対にスキップするな）」といった強調語を書き足した経験はないだろうか。2026年5月7日に個人ブログ「brian's thoughts」に公開された短い記事「agents need control flow, not more prompts」は、それこそが「プロンプトで解決できる限界に達したサイン」だと主張する。わずか数百語の記事だが、Hacker Newsをはじめ複数の場所で広く共有された。原文の主張をそのまま確認する。

3行まとめ

1. 個人ブログ「brian's thoughts」が2026年5月7日に公開した短い記事は、「信頼できるエージェントに必要なのはソフトウェアに組み込まれた決定論的な制御フローであり、手の込んだプロンプトの連鎖ではない」と主張した
2. この記事はHacker Newsで590ポイント・296コメントを集めた（本記事執筆時点でCurlで確認した数字）
3. Anthropicも2024年12月の技術ブログで「ワークフロー（あらかじめコード化された経路）」と「エージェント（LLMが自ら制御する）」を区別しており、両者は独立に主張しながら近い構図に行き着いている

記事の主張：テーゼは一文で言い切られている

記事冒頭は、主張を次の一文に凝縮している。

"Thesis: reliable agents tackling complex tasks need deterministic control flow encoded in software, not increasingly elaborate prompt chains"

複雑なタスクに取り組む信頼できるエージェントに必要なのは、ますます手の込んだプロンプトの連鎖ではなく、ソフトウェアに組み込まれた決定論的な制御フローだ、という主張だ。

「MANDATORY」「DO NOT SKIP」は限界のサイン

記事はこう続ける。

"If you've ever resorted to MANDATORY or DO NOT SKIP, you've hit the ceiling of prompting."

これらの強調語に頼ったことがあるなら、それはプロンプティングの天井に達したということだ、と言い切る。続けて、この状況を比喩でこう説明する。

"Imagine a programming language where statements are suggestions and functions return 'Success' while hallucinating. Reasoning becomes impossible; reliability collapses as complexity grows."

文がすべて「提案」に過ぎず、関数が幻覚を見ながら「成功」を返すようなプログラミング言語を想像してほしい、と。そこでは推論が不可能になり、複雑さが増すほど信頼性は崩壊する。

ソフトウェアの強みは「再帰的な組み合わせ可能性」

記事は、通常のソフトウェアがなぜ信頼できるのかを、次のように説明する。

"Software scales through recursive composability: systems built from libraries, modules, and functions. It's code all the way down. Code exposes predictable behavior, enabling local reasoning. Prompt chains lack this property."

ソフトウェアは、ライブラリ・モジュール・関数から組み立てられたシステムという「再帰的な組み合わせ可能性」によってスケールする。どこまで行ってもコードであり、コードは予測可能な振る舞いを示すため、局所的な推論（この部分だけを見て正しさを判断すること）が可能になる。プロンプトの連鎖には、この性質が欠けている。プロンプトは狭いタスクには有用だが、非決定論的で、仕様があいまいで、検証が難しい、と記事は指摘する。

解決策：LLMを「システム」でなく「コンポーネント」として扱う

記事が提示する処方箋はこうだ。

"Reliability requires moving logic out of prose and into runtime. We need deterministic scaffolds: explicit state transitions and validation checkpoints that treat the LLM as a component, not the system."

信頼性を得るには、ロジックを散文（プロンプトの文章）からランタイム（実行時のコード）に移す必要がある。必要なのは、明示的な状態遷移と検証チェックポイントを持つ「決定論的な足場（deterministic scaffolds）」であり、そこではLLMはシステム全体ではなく、1つのコンポーネントとして扱われる。

エラー検知：3つの選択肢

記事は、決定論的なオーケストレーションだけでは戦いの半分に過ぎないとも指摘する。

"But deterministic orchestration is only half the battle. In a system prone to silent failure, an agent without aggressive error detection is just a fast way to reach the wrong conclusion."

静かに失敗しやすいシステムにおいて、積極的なエラー検知を欠いたエージェントは、間違った結論に速くたどり着く手段にすぎない。プログラムによる検証がない場合、残された選択肢は次の3つだと記事は整理する。

• Babysitter（子守）：人間をループの中に置き、エラーが伝播する前に捕まえる
• Auditor（監査人）：実行が終わった後に、網羅的なエンドツーエンド検証を行う
• Prayer（祈り）：出力をそのまま「なんとなく」受け入れる

記事はこの3択を提示して締めくくられており、それ以上の具体的な実装手法（どのようなツールで状態遷移を実装するかなど）には踏み込んでいない。

Hacker Newsでの反響を数字で確認する

「広く共有された」という以上の定量データを、Hacker News自体のページとAlgolia検索APIから確認した。この記事のスレッド（投稿者bsuh、投稿ID 48051562、2026年5月7日16:43 UTC投稿）は、確認時点で590ポイント・296コメントを集めている。Hacker Newsのフロントページ掲載は流動的で、この数字は時間とともに動くため、あくまで本記事執筆時点でのスナップショットである。個人ブログの短いエッセイとしては大きな反応で、2026年5月というAIエージェント活用が急拡大していた時期に、開発者コミュニティの実感に触れた投稿だったことがうかがえる。

Anthropic自身も「ワークフロー」と「エージェント」を区別している

この記事の主張と独立に、Anthropicは2024年12月19日付の技術ブログ「Building effective agents」で、近い問題意識に基づく整理をすでに示していた。同社はエージェント的なシステムを大きく2つに分けている。

"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

ワークフローは、LLMとツールがあらかじめ定義されたコードの経路で調整されるシステムであり、エージェントは、LLMが自らのプロセスとツール使用を動的に指揮し、タスクの遂行方法そのものを制御するシステムだ、とAnthropicは定義する。同社はさらに、「まず最もシンプルな解決策を探し、必要な場合にのみ複雑さを増やすべきだ」とも述べており、複雑さを増やす際に使える具体的な設計パターンを次のように整理している。

これらはいずれも、bsuh氏の記事が主張する「決定論的な制御フロー」を、Anthropicが実務向けに具体化したパターン群だと位置づけられる。ただし、この技術ブログ自体は公開から1年以上が経っており、記事内には「2024年12月以降、この投稿で説明したツール状況の多くが変化している。現在のアプローチについては、Claude Managed Agentsの構築方法とドキュメントを参照してほしい」という追記がある。

「決定論的な足場」の実例：Anthropicの「context anxiety」対応

bsuh氏の記事は「決定論的な足場」を必要だと主張する一方、具体的な実装例は示していない。Anthropicが2026年4月8日付で公開した技術ブログ「Scaling Managed Agents」は、この種の足場を実際に組んだ結果、想定外の副作用が起きた事例を紹介している。

"As just one example, in prior work we found that Claude Sonnet 4.5 would wrap up tasks prematurely as it sensed its context limit approaching—a behavior sometimes called 'context anxiety.' We addressed this by adding context resets to the harness. But when we used the same harness on Claude Opus 4.5, we found that the behavior was gone. The resets had become dead weight."

Claude Sonnet 4.5は、コンテキスト上限が近づいていると感じるとタスクを早めに切り上げてしまう「コンテキスト不安（context anxiety）」と呼ばれる挙動を示すことがわかり、Anthropicはハーネス（エージェントを動かす制御コード）に「コンテキストのリセット」を組み込んでこれに対処した。ところが同じハーネスをClaude Opus 4.5に使ったところ、その挙動自体が消えており、リセット処理は「死荷重（dead weight）」になっていたという。

この事例は、bsuh氏の主張（ロジックをプロンプトからランタイムに移すべき）を裏付けると同時に、その先にある別の問題も示している。決定論的な足場を一度組んでも、モデルが更新されればその足場自体が古い前提を抱えたまま残り続けるリスクがある、という点だ。Anthropicはこの問題に対応するため、ハーネスの実装を「セッション」「ハーネス」「サンドボックス」という3つの要素に分離し、モデルが変わってもインターフェースだけは維持できる設計（Managed Agents）に移行したと説明している。

なぜ反響を呼んだのか

この記事はごく短く、具体的なコード例やケーススタディを持たない、いわば「主張だけ」のエッセイだ。それでも広く共有されたのは、AIエージェントを実際に使う開発者の多くが、プロンプトを継ぎ足していくうちに指示文が肥大化し、それでも信頼性が上がらないという経験を共有していたからだと考えられる（この背景についての定量的な裏付けは、記事自体には含まれていない）。

似た問題意識は、AIエージェントに渡す情報をどう設計するかという「コンテキストエンジニアリング」の議論とも重なる。Anthropicが2025年9月に公開した技術ブログの内容はコンテキストエンジニアリングとはで扱っている。プロンプト設計の基礎についてはプロンプトエンジニアリング入門ガイド、AIエージェントの基本概念についてはAIエージェントとはも参照してほしい。

著者の経歴は依然として確認できていない

• 著者「brian」（ハンドル名bsuh）のより詳しい経歴、専門分野についての情報は、記事本文だけでなくブログのトップページ（bsuh.bearblog.dev）も確認したが見当たらなかった。本記事でも著者の経歴は確認できていない。
• 記事自体が非常に短く、具体的な実装例・コードサンプル・ベンチマークデータは含まれていない。「決定論的な足場」の実例として本記事ではAnthropicの別記事（Managed Agentsの「コンテキスト不安」対応）を紹介したが、これはbsuh氏の記事とは別の組織による、別の文脈での事例であり、bsuh氏自身が念頭に置いていた実装例かどうかは確認できない。
• Hacker Newsの590ポイント・296コメントという数字は本記事執筆時点のスナップショットであり、時間とともに変動する。また、296件のコメントの中身（賛成意見・反論の内訳）までは読み込んでおらず、この記事の主張への反論がコメント欄にどの程度含まれているかは確認していない。
• 「複雑なタスクには決定論的な制御フローが必要」という主張自体は、Anthropicの「Building effective agents」が示すワークフロー／エージェントの区別とも重なる問題意識だが、両者が独立した主張なのか、bsuh氏がAnthropicの整理を参照して書いたのかは記事内に記載がなく、確認できていない。プロンプトの改善だけで十分なケースがあるという反対の立場を明示的に扱った記事は、本記事のソースの中には見つからなかった。