Japanese Translation:

信頼できる本番環境の AI エージェントを構築するには、主観的なプロンプトエンジニアリングから、測定可能な最適化プロセスへの移行が必要です。手作業で作成されたプロンプトに依存し続けることは、スケーリング時に失敗しやすい脆弱なシステムを生み出すものであり、Dan が「AI パソシス」と呼ぶ現象です。真の決定論を達成するためには、開発者はプロンプトをベクトルとして扱い、「pass^k」という厳格な適合度テストに付す必要があります。このテストは繰り返し実行され、エージェントが特定の指示（例：80 文字以下のタイトルを返すこと、あるいはブランドボイスを維持すること）を満たしていることを保証します。エージェントから微細な失敗が見られ、それを小さな調整で修正できない場合、遺伝的パレート最適化（GEPA）などの最適化器を利用した自動化されたループが必要となります。GEPA は、手作業によるテキストの調整ではなく、テスト結果に基づいてエージェントの行動を変更します。最適化における重要なステップの一つは、最適化ループ中に最適化器が見ていないホールドアウトテストを用いることで過学習を防ぐことです。現在、大規模言語モデルは頻繁にコンテナを逸脱し、無意味なデータを現場に溢れさせるため、業界基準はテキスト指令の整備から、厳密なテストスイートのためにラベル付けされた良質な回答と悪質の回答からなる大規模データセットを構築することへシフトしています。ドメインエキスパートは、テキストプロンプトの整備よりも、堅牢なデータセットを構築することに注力すべきです。将来には、実際の利用状況を監視し、実際の失敗を新しいトレーニングケースに変換する自己修正システムが登場します。この鮮やかなデータを最適化器に継続的に再実行することで、チームは人手介入なしで自動的にエージェントを改良できます。この戦略により、ユーザーは不安定な AI の罠を避けながら、自律的なアプリケーションを構築できるようになります。

エージェント開発：測定と最適化による「プロンプトエンジニアリング」の真実

1. エンジニアとしての背景と課題

プロフィール: ロサンゼルス在住のエンジニア。技術分野で25 年以上の経験を持つダンです。
本稿の主眼: 顧客が自らの名代としてタスクを実行するエージェントの本番環境における安定稼働について言及します。
- 注記: これは単なるチャットボットとは明確に区別されます。
目指すゴール: 最低限でも恥ずかしくない、誇りを持つエージェント体験の実現。
動機:
- 単なるアドバイス機械の提供やユーザー放置には満足できない。
- エージェント開発は魔法のようにもあり中毒性があり、苦行を伴うが極めて楽しいものです。

2. LLM の限界とリスク

根本的な問題:
- LLM は学術的に信頼して指示に従えない、真実を語れない、タスクを実行できないことが分かっています。
- しかし日常では比較的可靠に見えたり、巧妙にごまかしたりします。
監視の必要性:
- 「悪魔」が容器から脱走するリスクがあります。
- プロンプトへの制約（例：80 文字以下のタイトル返却）も多くの場合機能し、時折完全に失敗してフィールドに情報を洪水させます。
内部の現実:
- 「JSON についての自己メモ」などのループが繰り返され、修正方法の変更（例：
```
title
```
  を
```
heading
```
  に改名）でもいずれは邪魔されて狂います。

3. プロンプト・エンジニアリングの再定義

プロンプトの固定化は誤り

アジエンへの追加: 新しいプロンプトを適用することは、既存のテストされたコンテキストと異なる完全な別の宇宙へ投げ込むことになります。
影響:
- 既存の指示の総重量が新プロンプトの性能に確実に悪影響を与えます（通常）。
- プロンプトは「もの」ではなく、ベクトルです。重要なのはテキストコンテンツそのものではありません。

代替アプローチ：測定と最適化

正しい方法:
- プロンプトを直接書くのではなく、**測定（テストスイート）**を作成し、それに基づいて最適化するべきです。
- 「測定なしで誰かにプロンプトを渡す」ことは、AI 精神病の一種です。
自己改善フィードバックループ:
- プロンプトは一時的であり使い捨てです。
- 真の「もの」とは、自己修正システムのみが進化し持続する測定と最適化のプロセスそのものです。

4. 実装プロセス：Pass^k と GEPA

テストスイートの構築 (Pass^k)

手法: 大量にテストを実行し、エージェントの動作を測定します（業界用語：
```
pass^k
```
/ パス・パワー・K）。
目的:
- 意図せずしてエージェントの動作が狂うこと（例：頭をハンモック袋で叩かれたような状態）に気づきます。
- リクエストの一部が「幽霊」に取り憑かれ制御不能になるのを防ぎます。

オプティマイザーによる自動修正

手法:
- LLM にスキルを読み込ませ、敵対的シナリオや悪意ある回避を試みるプロンプトを大量に生成させます。
- これらをテストスイートとして**遺伝的アルゴリズム（GEPA など）**のようなオプティマイザーに接続します。
仕組み:
- オプティマイザーは、テストスイート上でプロンプトが良いか悪いかを評価し、自動的に修正を試みます。
- ループ内で継続実行し、最終的に最適プロンプトに収束します。

過剰適合の回避

リスク: オプティマイザがテスト内の例をそのままプロンプトに符号化して欺こうとすること（愚か）。
対策: **保持外テスト（Out-of-Distribution Tests）**を作成し、最適化プロセスで見たことのないシナリオでも通過するか確認します。

5. 本番環境での運用と自己改善

システムの自律的進化

構築方法:
- オプティマイザーで作成したプロンプトを、本番環境モニタリングと組み合わせます。
- デプロイ中に
```
pass^k
```
  テストを実行し、破壊的な変更を回避します。
フィードバックループ:
- 作成した LLM ジャッジをサンプリングされた本番会話で走らせ、失敗箇所を発見します。
- これらをテストスイートの「ハードケース」として追加し、再最適化に供します。

エージェントの成熟段階

製品発見: ML で何でも簡単に始められるが、完璧にはできない。
測定と決定論: 望ましい結果を得るため、測定を通じてどこで決定論性を再構築すべきか知る。
黄金データセット: ゴールデンデータセット（良い/悪いインタラクション）をキュレーションし、テストスイートとして形成。
ハネス化: シンプルなスキルから、測定と最適化の「フライホイール」で動作する堅牢なエージェントへ進化。

6. 開発者への提言

エンジニアと PM へ:
- プロンプト言語を正確にしようとするのではなく、**アーティフェクト（テストスイートや品質測定）**の構築に焦点を当てるべきです。
- プロンプトのキュレーションに時間を費やすことは非効率的です。
世界への警鐘:
- 多くの人は評価を気にせず、プロンプトから揺り動く簡易装置（Popsicle stick）を作成し続けています。
- これでは道は狂気に導かれます。
結論:
- アーキテクチャ図上のすべての箱が狂っているように見える中で、最も一貫して機能する組み合わせを探し続けるのは永遠の課題ですが、それが唯一の正道です。

プロンプトとは真実ではない