7月29日、オープンソースのアプリ構築ツールapp.buildの開発者が「Six Principles for Production AI Agents」と題したブログ記事を公開し、話題を呼んでいる。
この記事では、生成AIエージェントをプロダクション環境で安定運用するための“6つの経験則”と、それを支える設計思想・背景事情が詳しく紹介されている。以下に、その内容を紹介する。
原則1: システムプロンプトに投資せよ
LLMは適切なコンテキストを与えることで最も力を発揮する。LLMを脅したり、感情に訴えるようなプロンプトは、一時的には効果を発揮するように見えるかもしれないが、長期運用では破綻してしまう。
そのためには、AIエージェントが遵守すべきルールや共通部分を見極め、システムプロンプトとして明示することで、エージェントの処理全体のクオリティが向上する。
以下のようなガイドラインに沿って、システムプロンプトを磨き上げる必要がある。
- 公式ガイドラインを遵守: Anthropic や Google Gemini など各社のベストプラクティスを下敷きにする。
- 共有部分を大きく固定化: システムプロンプトをキャッシュ可能な大枠として保持し、ユーザ入力は最小限に抑えるとレイテンシとコストを削減できる。
# Claude 用システムプロンプト例（抜粋）
あなたは ast‑grep ルール生成アシスタントである。
出力は YAML とし、必ず `match` と `rewrite` を含めること。
原則2: コンテキストを分割せよ
AIエージェント開発における現在のトレンドは「プロンプトエンジニアリング」ではなく 「コンテキストエンジニアリング」 である。
適切なコンテキストがないと、モデルは幻覚を起こしたり、軌道から外れたり、あるいはコンテキストが長すぎると回答を拒否したりする傾向がある。その結果、注意力低下（モデルが非常に長いコンテキストの関連部分に集中できず、中間に埋もれた重要な詳細部分のパフォーマンスが低下する現象）、コスト増加、レイテンシ増加といった問題が生じうる。
著者がおすすめする原則としては、まず最低限の知識を提供し、必要に応じてツールを使ってより多くのコンテキストを取得できるようにすることだ。
例えばまず、プロジェクト内のファイルのリストをプロンプトで提供しつつ、要求された変更に関連するファイルを読み取るツールを提供するようにする。また、ファイルの内容が重要であることが確実な場合は、その内容を事前にコンテキストに含めることもできる。
ログファイルなどを読み取る場合は、コンテキストが急速に肥大化してしまう可能性がある。その場合は、コンテキスト圧縮ツール（例）を自動的に適用することで大きな効果が得られる。
つまり関心を分離し、エージェントソリューションのあらゆる部分に、本当に必要なコンテキストだけを提供する必要があり、著者はこれをオブジェクト指向プログラミングになぞらえて 「カプセル化」 と呼んでいる。
原則3: ツールを慎重に設計せよ
AI エージェントのコア機能はツール呼び出しであり、LLM + 公開ツール + 基本的な制御フロー演算子の組み合わせでエージェントが構成される。
エージェント用のツールセットの設計は、APIの設計に似ているが、実際にはより複雑だ。人間のAPIユーザーは行間を読む能力が高く、複雑なドキュメントを読み解いて回避策を見つけることができる。一方、エージェント用に作成されるツールは通常、より限定的で（ツールが多すぎるとコンテキストが損なわれるため）、直接的で分かりやすいインターフェースを備える必要がある。
著者は以下のようなガイドラインをおすすめしている。
- 機能は10個未満に集約（read_file、write_file、edit_file、executeなど）し、互いに重複させない。
- 各ツールは1–3の厳格な型を持つ引数で構成し、曖昧さ・副作用を排除する
- 冪等性を担保し、同一リクエストの再実行でも整合性を失わない。
原則4: フィードバックループを設計せよ
AIエージェントは アクター・クリティック・アプローチ と呼ばれる2段階のアルゴリズムで設計することで、飛躍的に性能が向上する。
- アクター が創造的にコードやプランを生成。
- クリティック が静的解析・テスト・型検査など機械的基準で厳格審査。
- 不合格なら リトライ / 修正 / 破棄 に分岐する。
例えばエンジニアリング領域ではコンパイラ・リンター・ユニットテストが強力なクリティックとなる。
原則5: LLMでエラー解析を自動化せよ
大量のログを メタLLM に食わせ、失敗パターンを抽出し、改善サイクルを短縮することができる。
- ベースライン実行でログを収集。
- 高コンテキスト LLM（Gemini 1 M など）が原因群を要約。
- プロンプト・ツール・ガードレールを修正し再学習。
原則6: フラストレーションは設計ミスの兆候
LLMが「指示を無視」するように見える時、
- APIキー欠落
- ファイルシステム権限不足
- システムプロンプトの矛盾
といった環境不整備が原因である場合が多い。最近のLLMは非常に優秀なので、我々をイライラさせる原因は我々自身にあることが多い。モデルを疑う前にシステム設定を点検すべきだ。
6原則の要点まとめ
| # | 原則 | キーワード |
|---|---|---|
| 1 | システムプロンプトに投資 | 明確・詳細・一貫性 |
| 2 | コンテキストを分割 | 必要最小 → 動的取得 |
| 3 | ツール設計を厳格に | 少数精鋭・冪等・型安全 |
| 4 | フィードバックループ | Actor–Critic・自動検証 |
| 5 | LLMでエラー解析 | メタLLM・ログ要約 |
| 6 | フラストレーション分析 | 環境・設計の欠陥検証 |
結論
成功するAIエージェントは「魔法のプロンプト」ではなく堅牢なシステム設計に支えられる。
明快な指示・適切なコンテキスト・厳格なツール・自動評価・継続的な誤り解析――これらを回し続けることで、失敗しても素早く回復し、漸進的に賢くなるエージェントが育つ。
詳細はSix Principles for Production AI Agentsを参照していただきたい。
