エージェント型AIが推進されるのはなぜか？ モデルは単純な指示すらまともに守れないのに

• AIコーディングモデルが単一の命令すら信頼性高く実行できない現実にもかかわらず、バックグラウンドで自律的に動作するエージェント型コーディングへの過度な期待が生まれている
• 筆者は100行規模のGolang関数を参照コードとして提示したにもかかわらず、GPT-5とGemini Proの両方で一部ロジックの欠落や更新漏れを経験した
• エージェント型システムが50個のファイルと多数の関数を自律的に処理するのは、現在の技術水準では非現実的であり、かえってデバッグにより多くの時間を要する危険がある
• コミュニティの反応は、体系的なプロンプト設計、ドキュメント化、段階的検証によって限定的に成功活用できるという意見と、エージェント型はまだ実用的ではないという懐疑的な意見に分かれた
• 現在のLLMは知能ではなく知識ベースのシステムであるため、開発者が自ら文脈を与え、段階ごとに検証する「道具としての活用」が現実的なアプローチである

---

元記事執筆者の問題提起

• 単純な命令の失敗事例: 100行のGolang関数を参照として提供し、別の関数を同じ構造に更新するよう依頼したが、GPT-5とGemini Proはいずれも一部ロジックを省略したり、更新を見落としたりした
• エージェント型コーディングの非現実性: 単一関数すらまともに処理できない状況で、50個のファイルにまたがる多数の関数を自律的に修正するエージェント型の方法は、さらに多くの問題を引き起こしかねないと懸念されている
• 6000行ファイル更新への質問: Stripeのバージョン更新のように、6000行規模のファイルを安全に修正する方法についてコミュニティに意見を求めた

前向きな活用事例と方法論

体系的なドキュメント化とインデックス化のアプローチ

• Markdown参照ファイルの活用: .md ファイルにリファレンスを保存し、AIにそれを読ませるよう指示すると、一貫性と正確性が向上する
  • 例示プロンプト: "添付の goLang_Update_reference.md ファイルを参照して、update関数の重要ポイントを要約し、それを基にソフトウェア更新のドラフトを作成してください"
• ローカルインデックスの構築: 大規模ファイル（6000行以上）の場合、1000行単位でスキャンして関数名と行参照を含むインデックスを生成する
  • フロントエンド作業時には fr.index.md など、特定領域だけを分離したインデックスを活用

エージェント管理と作業の構造化

• エージェントの専門化: 設計（architect）、コード探索（codeseeker）、コーダー（coder）など役割別のエージェントを構成し、それぞれに対応した .md ルールファイルを与える
• バーティカルスライスのアプローチ: 10万トークン以下で完結できる小さな機能単位に作業を分割する
  • 10万トークンを超えるとエージェントの誤作動可能性が急増する
• 作業文書化の強制: docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md の更新を必須にして、作業の継続性を確保する

Plan ModeとAsk Modeの活用

• Plan Mode: プロジェクト全体をレビューし、要求に応じて計画を立てたうえで段階的に進行する
• Ask Mode: コードベースへのクエリ、アイデア探索、選択肢の検討などに活用し、GoogleやStackOverflowの代替ツールとして有用

単体テスト先行アプローチ

• テスト駆動開発: 関数を書く前に単体テストを先に作成し、AIがテストを通過するコードを繰り返し生成するようにする
  • 機能的に正しいコードを得られる確率が大幅に上がり、その後は最適化や整理作業だけで済む

懐疑的な意見と限界認識

エージェント型の現実的限界

• 監督なしの作業は自殺行為: 現在の技術水準でチケットを割り当て、バックグラウンドで自律的に作業させるのは失敗確率が高い
• 虚偽を語る可能性: モデルは成功するよりもハルシネーションを生み出す可能性のほうが高く、最悪の場合は既存コードを破壊しかねない
• Planning Modeの重複性: ベースモデルに詳細な計画を求めるだけでも十分であり、Planning Modeは実質的に新しい機能を提供していない

LLMの本質的制約

• 推論ではなく予測: モデルは結果を検証せず、次の単語を予測する方式で動作するため、grounding、memory、feedbackが改善されるまでは信頼性は不安定なままだろう
• 知能なき知識ベース: LLMは知能を持たない高度化された知識ベースであり、開発者が自ら知能（BYOI: Bring Your Own Intelligence）と文脈を与える必要がある
• メモリ不足: モデルには真のメモリがなく、contextとcontext cacheにのみ依存しているため、新しいチャットを始めるたびに文脈が初期化される

言語とデータのバイアス

• Golangの相対的不利: GolangはPythonやJavaScriptに比べて公開コードベースが少なく、モデルが学習したパターンや慣習が不足している
  • これは一貫した編集や変換結果を得にくくする構造的要因である

成功活用のための実践ガイド

プロンプト設計と文脈の提供

• 明確で詳細な指示: 文法と句読点を正確に使い、曖昧な表現ではなく明示的な指示を与える
• 関連ファイルをすべて明示的に参照: エージェントが使うべきファイルをすべて指定しないと、スパゲッティコードが生まれる確率が上がる
• ルールファイルの設定: ワークスペース全体のルールとプロジェクト別ルールファイルを設定し、一貫したコード生成を促す
• @Docsの活用: エージェントに必要な中核知識を与えるため、ドキュメント参照機能を活用する（一部バージョンでは動作が不安定）

作業範囲と検証

• 小さな単位への分割: 一度に処理できる最小単位まで作業を分割し、各段階を検証してから次へ進む
• リアルタイムレビュー: 生成されるすべてのコードをリアルタイムで確認し、即時に修正を依頼してスパゲッティコードを防ぐ
• バックアップとバージョン管理: 各段階ごとにバックアップを作成し、GitHubなどのバージョン管理システムを活用する
• テスト実行: pytest --testmon -q で影響を受けるテストを増分実行し、完了前に全体テストを実行する

モジュール化とコード構造

• 6000行ファイルの分割: 単一ファイルで6000行はモジュール化されておらず、文脈提供にも不利なため、500行規模の12ファイルに分割するほうが効果的
• バーティカルスライスの重視: エンドツーエンドで実行可能な小さな機能単位で開発する

モデル選択とコスト管理

• Claude Sonnet 4.5を優先検討: GPTやGeminiより一貫性と正確性が高く、追加コストに見合う価値がある
• トークン消費に注意: 大規模な計画は多くのトークンを消費するため、実行時には小さな段階に分けて進めるほうがコスト効率が良い

特殊なユースケース

一回限りのスクリプト生成

• 分析スクリプト: 1日に数百本の一回限りのデータ分析スクリプトを書く必要がある場合、正確性が50%でも手作業で書くより1000倍速く生成・実行できる
• 結果の検証可能性: 結果を自分で検証できるため、精度が低くても実用的

ゼロからのアプリ構築

• マルチエージェント構成: 大規模アプリをゼロから構築する際、監督エージェントが他のエージェントの作業をレビューし、一貫性を維持する
  • import名、変数名の一貫性、コード重複の防止などに有効
• コスト対効果: それでも複雑な修正やリファクタリングが必要であり、段階的アプローチのほうが長期的には安価

コミュニティ意見の要約

前向きな体験（生産性3〜5倍向上）

• Next.jsのWebサイト: ゼロから完全に動作し、デプロイ可能なWebサイトを数分で構築
• 複雑な機能実装: チャットアプリにthreads機能を3〜4分で実装（本来は3日程度の作業量）
• 体系的アプローチ時: 明確なルール、十分な文脈、段階的検証を組み合わせれば、一貫して成功できる可能性がある

否定的な体験（現時点では非実用的）

• スパゲッティコードの量産: 広範な目標を与えると、文書更新漏れ、不要ファイルの未削除などの問題が起きる
• 意味的な誤り: 技術的には動作しても、コードの配置が不適切だったり、既存関数を再実装してしまったりするなど構造的問題がある
• 5分超の追跡失敗: 5分以上続く長い追跡は、たいてい役に立たない結果を生む

[GN⁺]

Hacker Newsの意見

• 実際に使ってみた感想では、LLMはたいてい自分の指示によく従うと感じる。もちろん、丁寧に練ったプロンプトと事前の計画は必要だが、その3つの感覚さえつかめば、この手のコーディングエージェントで十分に飛び回れる。たまに10回に1回くらいは外すが、そういう場合でも素早く止めて再指示すればすぐ本筋に戻れる。ここHNで多くの人が効果に懐疑的なのは意外だ。もちろんコストや仕事の変化など心配事は多いが、コーディングエージェントの有用性そのものを疑う声をよく見るのは驚きだ
  • 実際にエージェントシステムやLLMがGoogle検索やStack Overflowを超える価値を生んでいる例を、動画や実例で見られたらいいと思う
  • 現在の状態、望む結果、そして進め方を十分に説明すれば、エージェントと一緒に計画を立てて磨き込み、実行できる。そうすると、今の技術水準はかなり印象的だ。たった一文で複雑なことまで期待するのは無理がある。実務経験のない賢いインターンに技術作業を任せるときのように、現実には時間も手間も必要だ。ただしAIエージェントは人間のインターンよりずっと速く働く
  • 「たいていうまくいく」というのは、実質的には信頼性指標（9の数）がないという意味だ
  • さっき犬の散歩をしながら、Codex(gpt-5-high)でPythonアプリを一発でGoに変換した。成果物をテストしてみたらちゃんと動いた。仮想環境なしで単一バイナリとして配布できるようになったのが満足だ。命令がものすごく簡単だったかどうかは自分でもよく分からない
  • 「たいていうまくいく」は、自分にとっては十分ではない。もっと深刻なのは、指示に従わないことよりも、間違っていると認めずにむしろ言い張り続けることだ。自分が中程度に複雑なことを頼んだり、エラー解析を求めたりすると、かなりの頻度で誤った結論に固執する。こちらが問題を直接指摘するまで突破口を見つけられないことも多い。単純なコードやボイラープレート作業には本当に向いていて、少しフィードバックを与えるだけで新しいライブラリも作れた。だが間違いが多いので、もっと複雑なものは任せたくない。それでも行き詰まったときのアイデア出しには使っていて、たとえ外れていてもモチベーション維持には役立つ
• LLMに対する開発者ごとの経験差が不思議なくらい大きいとき、本当に自問すべきなのは「なぜこんなに体験が違うのか？」という点だ。「お前の使い方が悪い」という説明がいちばん単純だが、AIシステム開発者として実際に、複雑な指示もなく「直して」「レポート作って」だけ書いて結果を期待するユーザーが多いことにも驚かされる。「AIで何でもできる」という過剰な経営層のハイプもあり、これは企業価値や株価とも結びついている。一般大衆もAIを「本物の人工知能」だと思っているようだ。実際、LLMが単純な指示すら守れないという主張は信ぴょう性が低く、重要なのは複雑な仕事は依然としてきちんとこなせないということだ
  • もう一つの持論は、誰もが頭の中に仕様書を持っていて、それをまとまりなく書き散らしてLLMが実装してくれることを期待すると、実際の成果物は常にその仕様からずれる、ということだ。ある開発者はそのずれを頭の中で事後的に修正したり、多少の差異を受け入れたりする一方で、別の開発者はLLMが自分の頭の中の計画に合わなかったと失望する。ちょっと心理的な「偽りの記憶」に近くて、柔軟で妥協的な人もいれば、頑固な人もいる。自分もその両方を交互に体験している
  • 今は、誰かが実際に非自明な機能を作り上げる全工程を見せるスクリーンキャストでも長文記事でも、とにかくもっと見たい。AIインフルエンサーは、ほとんどAIでAIツールを作るか、CRUDやhello worldのデモばかり見せる。ベテラン開発者でさえ、コードベースの半分以上をAIが書いたと言いつつ、実際にはほとんど捨てて一部を参考にしただけだと明かす。「単一プロンプト → 完成アプリ」という話も、すぐに「真っ白な画面でやる気を出すには便利」みたいな話に変わる。実務の開発者が本当にどう使っているのか、もっと透明に共有されてほしい
  • 実のところ、「開発者」というカテゴリーはあまりに広すぎて、この議論には大した意味がない。大半が似たようなCRUD形式のコード断片を組み合わせる作業では、LLMはかなりよく機能する
  • みんなそれぞれ別のコードベースで別の作業をしている。この重要な細部はほとんど語られない。使えば使うほど期待値は上がり、限界を早く実感するようになる。たまに使うと印象的だが、一日中使っていると結局失望が積み重なる。「これくらいはできるはずだ」と思うことでも、結局こちらで手直しが必要な場合が多い
  • 結果が違うのではなく、各自の期待値が違うのだと確信している。うちの会社のIT担当SVPはAI礼賛派だ。最近、彼が昔作ったPHPのレガシープロジェクトを触っていて、彼が普段満足するコード品質の水準がものすごく低いと気づいた。自分も毎日LLMを使うが、いつも結果を修正している。つまり、コード品質への要求が低いほど、LLMの成果物に満足しやすい
• Cursorのフォーラムでは「君の使い方が悪い」という話ばかり繰り返されるが、本当に気になるのは信頼性、プロセス、そして実務への適用だ。ここでも結局、大規模に使っている例はほとんど見ないという印象がある。自分たちもAIはたいてい「気の利かない同僚」くらいの位置づけで使っていて、制約の少ないサイドプロジェクトでより実験的に活用している。エージェントはほとんどハイプか、せいぜいごくニッチ用途という印象だ
  • OPの結果が悪いのはCursorを使っているからだ。Cursorはコスト削減のために会話コンテキストを容赦なく削る。モデルプロバイダと違って、LLM利用コストを小売価格で払わなければならないので価格競争で不利だ。Cursorはどれだけコンテキストを削っているかを透明に開示しておらず、自分の経験では本当に攻撃的に削るので、何が何だか分からせるために同じファイルを何度も読み込ませなければならない。自分の助言は、Cursorに時間を投資するのをやめることだ。Cursorが書くコードは負債を増やすだけだ。CodexとClaudeに移って、ずっと満足している
  • 具体的にどんな改善を望んでいるのか気になる。元の投稿には具体例、プロンプト、方法論がなく、ただ「自分はプロンプト作りがうまい」と言っているだけで、これでは評価も助言も難しい。そもそもエージェント的ワークフローに懐疑的な視点は理解できるが、人々にまともに反論する機会すら与えていない。自分もここ数か月エージェントと一緒に働いているが、何がうまくいき何が失敗するのか、まだ学んでいる最中だ。自分の経験では:
    • agent-osのようなフレームワークによるオーケストレーションは必須
    • 誘導と自律のバランスを取ることが重要
    • とくにレガシーコードでは事前計画が本当に重要
    • 自分の例: レガシーシステムでコンテキストウィンドウをしょっちゅう超え、コンテキストを整理すると必要情報が抜け落ち、同じミスを繰り返す
    • 効果的だった方法: 問題を明確に構造化し、発見したこと・学んだことを逐一整理して記録し、非常に具体的なサブエージェントへ分割する（コンテキストウィンドウを管理できる）。そうして初めて、レガシーコード探索にエージェントが実質的な助けになった
  • エージェントが、自分では見つけられなかった本番バグをいくつも見つけた経験がある（自分が十分な時間を割けなかった、見慣れないバグだ）。もちろん見つけられないバグの方がずっと多いが、ソフトウェアエンジニア1時間分をかけて探すのに比べればほとんどタダ同然で、たまに当たるなら十分使える戦略だ
  • 実用的で具体的な例を含む投稿の方が意味があり、より良い回答を引き出せるだろう。具体的な実務上の問題と、LLMがどう失敗したかを示す情報の方が有益だ
  • 実際のビジネス価値は、人々が思っているよりはるかに小さくて歯がゆい。確かにボイラープレートや慣れた領域では、人間以上にうまく使えることもある。だが、それ以外の問題点（ビッグテック依存、データ汚染、検証不能な情報、創造性の低下、オリジナリティの崩壊、AI狂信者の無知、エネルギー消費、人間の創作物の盗用など）が大きすぎる。こうしたものが人類にとって純利益だと信じられるのが不思議なくらいだ
• 2025年には、マーケティングはRedditやLinkedInなどあらゆるフォーラムで、ブランドが会話に染み込む形で本当にうまく行われている。CEO、AI「思想家」、VCたちはLLMを魔法のように宣伝し、v0やLovableなどを次世代の革新として売り込む。リーダー層の答えもみな似たり寄ったりだ（関連動画）。だが実際には、CLAUDE.mdやcursorrulesのようなものをどれだけ作っても、ほとんど効果がない。結局LLMが指示に従わなければならないのに、実際にはランダムに見える。とても単純なルールですらほとんど守らないので、Cursorフォーラムに書き込んでいる人たちはみんなアマチュアなのではと思ってしまう。そして、新しいコードを書く作業はLLMが本当に苦手だ。存在しないライブラリを前提にしたり、ほとんど役に立たない文字列を並べたりする。自分は文字どおりspeech-to-textのような使い方しかしていないが、LLMの方が自分の見落としたエッジケース、知らないベストプラクティス、文法などを見つけるのは得意だ。
  • [1] 検索やPerplexityなどに出てくる結果は、たいていマーケティングチームがばらまいた宣伝の塊だ
  • 新しいコードを書く作業にLLMが本当にひどい、という点には完全に同意する。現行のSOTAモデルは、非常に有名で一貫したパターン（MVCなど）があるフレームワークでは、ボイラープレートや単純な構造をそれなりに作れる。真に光るのは、大量の情報をざっと見て何か（コードベース、ログ、スタックトレースなど）を見つける任務だ。だが「エージェントがコードベース全体を作る」というマーケティングは、少なくとも現時点では現実ではないと思う
  • 自分は体験がまったく逆だ。ここ1週間ほど、Claude Codeが自分の管理しているコンパイラの問題をほぼ自律的に修正してくれた。たまにいら立つことはあったが、微妙なコード生成やパーサのバグまで一貫してうまく直してくれたし、自分が介入する部分もcompaction管理などツールの限界に近い。書籍を読まないと分からないような手法まで実装し、実際に動かしてうまく機能することも確認した。完全に新しくて本当に「革新的」なものは少ないだろうが、実際ほとんどのコードは新規性がない。自分の経験では、よく構造化されたガイドに従わせれば、たいてい非常によく従う。ただCLAUDE.mdに雑に書いておけばいいわけではない。肝はプロセスについての丁寧な案内だ。自分のやり方は、1) プロジェクトごとのデバッグガイド、2) 受け入れ基準の明確化、3) テストを頻繁に回し、単位ごとの小さな変更はファイルに記録させる、に分かれる。こうするとClaudeで何時間もの自動作業を、ほとんど監督なしで回せる（途中で「続けて」と命じたり、/compactを使う程度）。毎回完璧なコードを出すわけではないが、自分だって同じだ。それでもたいてい前向きな変化につながり、自分の労力は大幅に減った。設計が固まっていない段階でのブートストラップはまだ勧めないが、たまにはそれもやり遂げる（ただし事前レビューは必要だ）。最近はClaudeに何日もぶっ通しで問題解決を任せることまで考えている
  • 人によってLLM体験がここまで違いうるというのは本当に興味深い。自分の場合、codex-cliで生産性が5倍になった実感がある。非常に変則的な構造のソースや内部SVG実行トレースをカスタムJSONグラフ形式に変換したり、複合的なPython/C++コードベース（低レベルのRISCVカーネルまで含む）から正確なドキュメントを抽出したりも難なくこなせた。同じツールでもここまで結果が違う原因が本当に気になる
  • Claudeでコーディングしていると、スロットマシンを回している気分だ。たまに欲しいものがぴたりと出るが、もっと頻繁にそうならないか、完全に外れる。絶対に単独の無人運転に任せるべきではない
  • 自分の感覚でも、LLMの最も安定した価値は、人間がよく見落とす些細なミスや最良の例、コード文法などをいちばんよく拾ってくれることだ。だからPRレビュー担当として使うなら、少し差し引いて見れば悪くない
• うちの会社ではクラシックなXP方式を採用している。ブラウンフィールドのアプリに新機能を開発するときは、「red-test-writer」「minimal-green-implementer」「refactorer」など、ほぼ8つのサブエージェントに分割する。今ではClaude Codeに「このTDDプロセスでX機能を作って」と入力するだけで、30分でずっと良いコード、90%のテストカバレッジ、即受け入れ可能な状態の成果物ができあがる。何年にもわたるXP・ペアプログラミング・TDDの経験は前提だが、もう1年以上、本番コードの95%はAIが書いている（非自明な複雑機能も含む）。実質的に秘密のノウハウもなく、うまく回っている。自分たちには本当に大きな効果がある
• ここでは意見の差があまりに大きい。各自が何に失敗したのか、どんな作業に使っているのかを明かさなければ、まともな議論はできない。LLMが失敗／成功した具体的なカテゴリを語らないなら、全部ノイズ以上のものではない
  • 議論するなら、言語／フレームワーク、問題ドメイン、SREレベル、LLM（モデル／バージョン）、agentic harness（claude code、codex、copilotなど）、失敗／成功ケース、LLMの熟練度まで詳細に明記すべきだ。さらに、そのエンジニアが一つのコードベースだけを10年やってきたのか、複数プロジェクトを行き来しているのか、新規開発（Greenfield）なのか保守なのか、革新研究なのか、CRUDなのか、といった条件も違い得る
• 科学者の立場では、データセットごとに少しずつ異なるボイラープレートを繰り返し書かなければならないことが多く、コーディングエージェントがこれをかなり解決してくれる。特に「絶対にデータを捏造するな、np.randomを使うな」と5回も大文字で強調してもClaudeが無視することがある。こういう点は意外なほどひどい。うまくいくときは夢のようだが、だめなときは失敗のシグナルすらない。LLMマーケティングの観点では、コーディングエージェントの後ろに、それがちゃんと仕事をしているかをリアルタイム監視する「PIPA（Performance Improvement Plan Agent）」みたいなエージェントがついて回る未来まで想像してしまう。PIPAがコーディングエージェントの成果をチェックし、HRや経営陣がAI従業員（エージェント）を管理する、そんな未来が来るのかもしれない
  • 「ピンクのチュチュを着たゾウを考えるな！」と言われたら、むしろ思い浮かばなかったか？ 科学者なら、LLMの性質上、否定文をうまく理解できないことは知っているはずだ。LLMはトークン単位で学習しているので、「NO ELEPHANTS」と言っても「ゾウ」という単語が文脈に残る。だからむしろその単語へ誘導される。肯定形の指示文を書く方が有利だ
  • PIPAの想像だけでも怖い
• モデルが自力で適切な文脈を見つけられるよう、プロンプト（良いエラーメッセージなど）が重要で、作業を非常に小さく一定に分割すれば、反復や段階テストの結果を次の作業の文脈として渡せるようになる。問題の50%はこのやり方に合っていて、さらにその50%のうち半分は、従来の自動化よりLLMループの方が手間が少ないが、そのまた半分は投資に見合うほど追う価値がない。結局、魔法のような「12.5%」のケースがあるなら、強く制約された（Constrained）エージェント方式が最適だ
  • その過程をそのままYouTubeなどで生配信してみれば（チュートリアルではなく自然なライブコーディング）、よいインサイト共有になるはずだ
• ほぼ30年前、AIに入門したころ、こんなことを言われた。「intelligent agent（知能エージェント）」という言葉を聞いたら、「訓練可能なアリ」だと思え、という助言だった
  • もっと詳しく知りたい
• 自分にとって最大の問題は、AIツールの性能が作業ごとに大きくばらつき、どこで失敗するか予測しづらいため、時間を消費してしまうことだ。ツール経験を積めばプロンプトの腕も上がるのだろうと思うが、それでもまだもどかしい。ただ、エージェントとAIの有用性が重なる領域もある（例: 新規プロジェクトのボイラープレート自動生成など）。そういうときは「エージェントモード」の方が便利だ。まだ自分の実戦経験は十分とは言えない
  • ちゃんと動くほど期待値はどんどん上がり、用途も広げたくなるが、そこで限界にぶつかると、むしろ最初の頃より失望が大きくなる