AIエージェントをマイクロマネジメントすると、かえって「バカ」になる理由

最近のGitHubリポジトリから適当な system_prompt.txt を開いてみると、何が書かれているだろうか？大抵の場合、パニックに陥ったような長文の壁が目に入る。「Xは絶対にしないでください。必ず3つの箇条書きで出力してください。このライブラリは絶対に使わないでください。」

開発者たちは、人類史上最も高度な推論エンジンを、まるで壊れやすい正規表現スクリプトのように扱っているのだ。

歴史的に見れば、このパラノイア（過剰な警戒心）は完全に理にかなっている。ほんの1、2年前まで、初期のLLMは話題から逸れないようにするだけでも、手取り足取りの極端なサポートが必要だった。しかし、時代は変わった。現代のモデルは信じられないほど賢くなっているのに、私たちは未だに1980年代の電子レンジをプログラミングするかのようにプロンプトを書いている。知能をハードコードしようとしているのだ。

最近、Vercelでこの点を証明する非常に興味深い出来事があった。彼らのエンジニアリングチームが、v0プロダクトをどのように改善したかについての詳細を公開したのだが、そこには直感に反するようなアプローチが記されていた。なんと、エージェントのツールの80%を削除したというのだ。

結果はどうなったか？システムは壊れなかった。それどころか、はるかに良くなったのだ。過剰に指定されたツールやガチガチのレールを取り払うことで、混乱を減らし、モデルが最も得意とすること、つまり「問題について推論すること」に集中できるようになった。摩擦が減ったことで、より良いコードが生まれるようになったのだ。

今AIを使って何かを構築しているすべての人にとって、ここには深い教訓がある。それは、**「厳格なルールではなく、原則を与える」**ということだ。

LLMに対してステップバイステップで正確に何をすべきかを指示すると、限られたアテンション（計算リソース）を、品質の向上ではなく「指示に従うこと」に浪費させてしまう。あなたがハードコードした解決策よりも、膨大な学習データを使ってよりエレガントな解決策を見つけ出す能力を奪ってしまうのだ。

その違いを理解するために、ほとんどの開発者がどのようにエージェントのプロンプトを書いているか、そして本来どう書くべきかを比較してみよう。

悪い例（厳格なルール）:

「ユーザーデータを取得するPython関数を書いてください。必ず requests ライブラリを使用してください。エラーは try/except ブロックで処理しなければなりません。必ず 'name'、'email'、'status' のキーのみを持つ辞書を返してください。async は使用しないでください。すべての行にコメントを追加してください。」

良い例（原則と目標）:

「ユーザーデータを取得する堅牢なPython関数を書いてください。モダンで標準的なライブラリを優先してください。コードは本番環境で使えるレベルである必要があり、ネットワーク障害やエッジケースを適切に処理できるようにしてください。巧妙さよりも、可読性とクリーンなアーキテクチャを優先してください。後続のシステムは、標準的なユーザープロファイル（name, email, status）を想定しています。」

この視点の変化に気づいただろうか？最初の例は、AIを「信頼できないジュニア開発者」のように扱っている。2つ目の例は、目標とコンテキストを理解している「シニアエンジニア」として扱っている。良い出力がどのようなものか、そしてそれはなぜかを伝え、あとは一歩下がってどうやって実現するかをAI自身に考えさせているのだ。

もちろん、このルールには一つだけ大きな例外がある。

エージェント同士が対話する場合や、上流のエージェントが厳格な下流のデータベースパーサーにデータを渡す場合は、絶対的な厳密さが必要だ。マシン間の受け渡しには、正確で妥協のないJSONスキーマが求められる。しかし、推論、生成、問題解決においては？もっと手綱を緩めよう。

もし今日、あなたのコーディングアシスタントを即座にアップグレードしたいなら、以下のブロックをそのままコピーして、claude.md や memory.md、あるいはエージェントのコアとなるシステムプロンプトに貼り付けてみてほしい。

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

マシンをマイクロマネジメントしようとするのはもうやめよう。現代のLLMを信頼するんだ。彼らを幼児のように扱うのをやめれば、彼らはより速く、より賢く、そして無限に有能な存在になるのだから。