手動でプロンプトを直し続ける作業は、精度が上がっても再現性がなく、複数ステップのパイプラインではどこが壊れているかも見えにくい。Cisco Foundation AIが公開したFAPO（Fully Automated Prompt Optimization）は、Claude CodeやCodexをオーケストレーターに据え、評価から失敗分析、改善案の検証までを自律的に回すフレームワークです。

この記事では、FAPOが解く課題と仕組み、GEPAとの性能比較、導入の流れを整理します。

  • FAPOが手動プロンプト設計のどこを自動化するか
  • 6段階の最適化ループと3層の変更レベル
  • GEPAとの18比較で15勝という根拠
  • テナント構成と始め方

https://github.com/cisco-foundation-ai/fully-automated-prompt-optimization

手動プロンプト設計が抱える4つの壁

LLMアプリの品質は、プロンプトの文言に大きく左右されます。Cisco Foundation AIの公式ブログでは、表現を少し変えるだけで精度が20%前後動く例が挙げられています。しかし本番運用では、次のような壁が重なります。

  • ステップ単位の可視性がない：最終回答のスコアだけでは、検索・推論・整形のどこで失敗したか切り分けにくい
  • 試行が遅い：変更のたびに全件評価を回し、結果を手作業で読む必要がある
  • 単一プロンプト前提のツールが多い：多段パイプラインでは、上流の失敗が下流へ連鎖する
  • 失敗パターンの体系化がない：感覚で直すと、直した箇所が別のケースを壊す

FAPOは、パイプライン全体を「検査可能なワークフロー」として扱い、各ステップの中間出力を記録したうえで失敗原因を分類します。プロンプトで直せる問題と、チェーン構造を変えるべき問題を切り分けられる点が、従来のプロンプト最適化との大きな違いです。

FAPOの全体像

FAPOは、共有の評価エンジン（src/hephaestus/）と、タスクごとに隔離されたテナント（tenants/<id>/）で構成されます。パイプラインはLangGraphでステートフルなグラフとして表現し、最適化の指揮はClaude Codeが担います。Codexをオーケストレーターに使う構成にも対応しています。

最適化対象のタスクモデル（GPT-4.1-miniやGemma 3-12Bなど）と、最適化を動かすエージェントは別レイヤーです。評価基準となるデータセットは開発者が用意し、検証用とテスト用に分割します。初期プロンプト、LangGraphチェーン、スコアラーはClaude Codeに生成させることもできます。

論文（arXiv:2606.19605）では、FAPOを「Fully Autonomous Prompt Optimization」と表記していますが、製品名・ブログ上の呼称は「Fully Automated Prompt Optimization」で統一されています。

6段階の最適化ループ

FAPOの中核は、次の6段階を繰り返すクローズドループです。

  1. Evaluate（評価）：データセット全件でチェーンを実行し、ケースごとのスコアとステップ出力を収集
  2. Attribute（帰属）：ルールベースのヒューリスティクスとLLM分析で失敗を分類
  3. Propose（提案）：支配的な失敗クラスタに対し、プロンプト・パラメータ・構造のいずれかで改善案を生成
  4. Review（レビュー）：独立エージェントがスコープ遵守、データ漏洩、スコアラー互換性を検証
  5. Compare（比較）：検証を通過した案を評価し、ベスト候補と比較
  6. Iterate（反復）：目標精度に到達するか、予算（50バリアントまたは10ラウンド）まで継続

変更レベルは3段階あり、まずプロンプト文面を試し、効果が頭打ちになった場合のみチェーンパラメータや構造へエスカレーションします。最適化エージェント、ステップ帰属サブエージェント、バリアントレビューサブエージェントの3体が役割を分担します。

過学習を防ぐガードレール

自動最適化は、訓練データへの過学習を起こしやすい領域です。FAPOは次の4点で制約をかけています。

  • データ分割のアクセス制御：最適化エージェントは訓練分割の個別ケースのみ閲覧でき、検証・テストは集計スコアだけが見える
  • スコープ契約：テナントのプレイブックで変更可能範囲を定義し、レビューエージェントが独立検証
  • イテレーション記録：バリアント、スコア、打ち止め理由を構造化ログに残す
  • バリアントの不変性：採用・却下にかかわらず、毎回新しいファイルとして保存し、既存案を上書きしない

この設計により、「なぜこのプロンプトになったか」を後から追跡できます。

GEPAとの比較結果

比較対象のGEPA（Genetic-Pareto）は、DSPy上の固定チェーン内で指示文を進化的に探索するプロンプト最適化手法です。実行トレースをLLMが読み、失敗理由を言語で診断して改善案を出す点で、現行の有力な自動最適化の一つです。

FAPOとGEPAの比較実験では、6ベンチマーク（HotpotQA、HoVer、IFBench、LiveBench-Math、Papillon、AIME）と3タスクモデル（GPT-4.1-mini、GPT-5.4-mini、Gemma 3-12B）の計18組み合わせで評価されました。両者は同一のベースラインパイプラインとプロンプトから出発し、FAPOのオーケストレーターとGEPAのリフレクターにはいずれもClaude Opus 4.6が使われています。

Cisco Foundation AIの公式ブログが示す主な結果は次のとおりです。

指標 数値
FAPOがGEPAを上回った比較 18件中15件
平均改善幅 +14.1ポイント
構造変更を伴ったHoVer・IFBenchの6比較 全6件でFAPOが勝利、平均+33.8ポイント
プロンプトのみで勝った比較 12件中9件

構造変更が効いた典型例として、HoVerでは検索ホップ数を3から4〜5に拡張し、IFBenchでは指示制約を強制する後処理ノードを追加しました。検索やフォーマット制約がボトルネックになるタスクでは、プロンプトだけを直しても頭打ちになりやすく、FAPOのパイプライン変更が大きな差を生んでいます。

AIMEだけはGEPAが先行しましたが、論文では試行間のばらつきの範囲内と評価され、一貫した劣化とはみなしていません。セキュリティ分野のCTIBench-RCM（CVEからCWEを分類するタスク）では、プロンプトのみの最適化でGPT-5が+4.0ポイント、Foundation-Sec-8B-Instructが+7.1ポイント、Foundation-Sec-8B-Reasoningが+2.0ポイントのテスト精度向上が報告されています。

使い方の流れ

リポジトリはApache 2.0ライセンスで公開されています。導入は次の流れです。

  1. pip install -e . でインストール
  2. テナントを作成し、データセット（JSONL）、LangGraphチェーン、スコアラー、評価設定を配置
  3. python -m hephaestus.cli eval --config <config> でベースライン評価
  4. Claude Codeで /optimization を実行するか、Codexに最適化ワークフローを指示

Claude Codeに「分類タスク用のテナントを作って」と依頼すれば、プロンプト・チェーン・スコアラー・設定ファイルを自動生成できます。最適化のたびに prompts/variants/、configs/、docs/ に履歴が残り、監査可能な形で改善過程を追えます。ReActエージェント向けのMCPワークフロー評価拡張も用意されています。

既存手法との位置づけ

DSPyやGEPAが「固定されたプログラム内の指示文」を主に探索するのに対し、FAPOはステップ単位の帰属分析を軸に、プロンプト・パラメータ・構造の3層を段階的に探索します。GEPAやDSPyをライブラリ依存として組み込む必要はなく、比較実験ではGEPAの評価設定を再利用しているにとどまります。

手動でプロンプトを微調整し続ける運用から、スコア関数とデータセットを定義すればエージェントが改善を回す運用へ移行できる点が、実務上の価値です。特に検索・推論・整形が連なる多段パイプラインでは、どのステップがボトルネックかを機械的に切り分けられることが、精度改善の速度を大きく変えます。