FAPOとは、LLMパイプラインを評価し、失敗ステップを特定しながら、プロンプト・パラメータ・必要に応じてチェーン構造まで自動で改善する仕組み。
多段構成のLLMパイプラインを組んだのに、評価データで精度が頭打ちになる。検索して文脈を集め、要約し、判断して出力する——この4ステップのどこかが誤答を生んでいるのは分かる。ところが、どのステップが原因かは中間出力を1件ずつ開いて目視するまで見えない。100件の失敗例を手で追う作業に半日が溶けていく。似た状況で止まっているなら、原因の切り分け方そのものを自動化する選択肢がある。
- FAPOはCisco Foundation AIが公開したClaude Code駆動の全自動プロンプト最適化システム。ライセンスはApache 2.0で、Codexでも動かせる
- 誤答をステップ単位で失敗帰属し、プロンプト→パラメータ→チェーン構造の順に必要最小の変更から試す
- Cisco公表の評価では、最先端最適化器GEPAに対し18のモデル×ベンチマーク比較のうち15で上回った
多段LLMパイプラインで精度が頭打ちになる——どのステップが失敗しているか分からない
プロンプトの文言を少し変えただけで、精度が大きく振れる。数件のサンプルではうまく動いていた指示が、件数を増やした途端に崩れる。LLMアプリケーションを本番に載せるとき、いちばん手強いのはこの再現性の低さです。単発のプロンプトなら試行錯誤で詰められても、ステップが増えるほど探索空間は膨らみ、手作業では追いつかなくなる。
そこで多くの人がやるのが、プロンプトの磨き込み。役割を明確にし、文脈を足し、制約と出力形式を指定する。構造化プロンプトの基礎として理にかなった手順で、検証と反復を重ねれば一定の効果は出ます。ただ、ある地点から改善が止まる。プロンプトをいくら整えても精度が伸びなくなったとき、直すべき対象がプロンプトそのものではない可能性が高い。
ここで押さえたいのは、AIアプリの品質はプロンプト単体だけで決まらないことです。与えるコンテキスト、そして検索・要約・判断といったシステム構造全体が精度を左右する。同じプロンプトで出力がばらつく、多段ワークフローの途中でエージェントが混乱する——こうした症状は、プロンプト単体の問題ではなく、直そうとしている層がズレているサインであることが多い。RAGが無関係な文書を返すなら、直すべきは文言ではなく検索の設計。ステップ間の受け渡しで情報が欠けるなら、いじるべきはチェーンの構造。層を見誤ったまま文言だけを回しても、労力に対して精度は返ってきません。自分のパイプラインのどの層が弱いのかを見極めるには、まず失敗をステップ単位で仕分ける必要がある。次に見るFAPOは、この仕分けと修正の反復そのものを自動化する仕組みです。
同じプロンプトでも出力がばらつく／どのステップで壊れたか見えない
厄介なのは、失敗の所在が見えにくいこと。パイプラインが最終的に誤答を返しても、その原因が最初の検索段にあるのか、中間の要約段にあるのか、最後の判断段にあるのかは、出力を見ただけでは判別できない。従来はここで、各ステップの中間出力をダンプし、1件ずつ突き合わせて「この段で文脈が欠けている」と当たりをつけていました。件数が数十を超えると、この検分作業自体がボトルネックになる。精度改善の前に、原因ステップの特定で時間を使い果たす構図です。
FAPOとは——Claude Code駆動でプロンプト最適化ループを自動化する仕組み
この原因特定と改善の反復を丸ごと自動化するのが、Cisco Foundation AIが公開したFAPO（Fully Automated Prompt Optimization）。初期プロンプトとデータセットを与えると、目標精度に達するか、割り当てたバジェットを使い切るまで、LLMパイプラインを自動で最適化するシステムです。オーケストレーション役には既定でClaude Codeを使い、代替としてCodexにも対応する。Claude Code専用ではない点は押さえておきたいところ。ライセンスはApache 2.0で、オープンソースとして公開されています。
FAPO は Fully Automated Prompt Optimization の略。
Cisco Foundation AI 公式（FAPO プロジェクト）
動きの骨格は、閉じたループです。1サイクルは6ステージ——評価（Evaluate）、失敗帰属（Attribute）、変種提案（Propose）、レビュー（Review）、比較（Compare）、反復（Iterate）——で構成され、目標精度に達するか、割り当てたバジェットを使い切るまで回り続ける。人が構造化プロンプトを手で書いては検証し、また書き直していた作業。その反復を、Claude Codeのエージェントが自律的に回す形に置き換えたものと捉えると分かりやすい。
内部構造にも触れておきます。FAPOはマルチテナント構成で、1つのテナントが1タスク分のプロンプト・データセット・チェーン定義・スコアラー・設定を自己完結で保持する。無関係なタスクどうしは干渉なく並行して最適化できる仕組みです。評価・チェーン実行・スコアリングを担うコアエンジンはhephaestusという名前で、ドメインに依存しない汎用部品として src/hephaestus/ に置かれる。パイプラインの各チェーンはLangGraphのステートグラフ（StateGraph）として表現され、テストケースを1件ずつ処理していきます。標準ではOpenAI・Baseten・SageMakerの3プロバイダに対応する。
入力（データセット＋初期プロンプト）と出力（最適化済みプロンプト／チェーン構成）
利用者が必ず用意する入力は、実はひとつだけ——対応する入力と期待出力のペアからなるデータセットです。このデータセットは、最適化に使う分割と最終評価用の held-out（取り置き）テストセットに分けて扱う。実装上は、個別ケースを最適化器に見せる training 側と、集計スコアだけを参照する validation／test 側とでアクセスを分ける設計で、テストセットは最終評価の一回きりにしか触れません。初期プロンプトやチェーン、スコアラーは、タスク記述からClaudeが足場を生成（scaffold）することもできます。出力は、最適化済みのプロンプトとチェーン構成。ただし必ず目標精度に届くわけではなく、目標に達した時点か、割り当てたバジェットを使い切った時点で停止します。入り口はデータセット、出口は最適化済みのプロンプト、という対応です。
失敗をステップ単位で特定する（step-level failure attribution）
FAPOの核が、この失敗帰属です。パイプラインが誤答を返したとき、どのステップが原因かを機械的に切り分ける。従来は人が中間出力を検分していた作業を、検証データ上での失敗分類として自動で回す部分にあたります。可観測性ツールの多くは「どこで失敗したかを見える化する」ところで止まりますが、FAPOはその先——失敗を特定のステップに帰属させ、次に何を直すかの判断材料にするところまで進める。ここが可視化止まりとの分かれ目になります。
帰属した失敗は、大きく2種類に振り分けられます。ひとつは、プロンプトの手直しで対処できるタイプ。出力が冗長すぎる、指定した出力フォーマットが崩れている、といった文言レベルの崩れがここに入る。もうひとつは、構造的なタイプ。検索段で必要な文書を取りこぼしている、そもそもチェーンに必要なノードが欠けている、といった配線の問題です。公式ブログはこの「プロンプトで直せる失敗」と「構造的な失敗」という枠組みで説明しており、両者を切り分けること自体が、次の一手を決める起点になります。
なぜステップ単位の帰属が効くのか。多段パイプラインで最終出力だけを見て「精度が低い」と判断しても、直すべき場所は分かりません。検索段が文書を取りこぼしているのに要約段のプロンプトを磨いても、失敗の根は残ったまま。原因ステップを名指しできて初めて、そのステップに合った変更を選べる。FAPOはこの帰属を評価データ全体に対して自動で行うため、100件の中間出力を人が開いて回る必要が消えます。
プロンプト→パラメータ→チェーン構造の3段階で直す
失敗の所在が分かったら、次は直し方。FAPOは改善を3つのレベルに分け、コストの低い変更から順に試すエスカレーション設計を採ります。まずプロンプトやエージェントのスキル定義（agent skills）の編集で届くかを探る。それで足りなければパラメータの調整に進む。それでも目標精度に届かないときに初めて、チェーン構造そのものに手を入れる。安いカードから切っていく発想です。
各レベルの中では、変種を提案し、検証データで測り、反復するという同じサイクルを回します。プロンプトレベルなら、指示の書き換えや制約の追加といった候補を複数生成し、検証セットでスコアを比べる。1つのレベルの探索を尽くしてから次のレベルへ上がる順序なので、いきなりチェーンを組み替えて話をややこしくすることがない。最も安い変更で解けるなら、そこで最適化は止まります。
この段階設計には副次的な利点もあります。プロンプトの手直しで届いた失敗と、チェーン構造の変更まで必要だった失敗とが、履歴として分離される。どの失敗が浅く、どの失敗が深かったかが後から追えるため、パイプライン全体の弱い箇所が見えやすくなる。3段階のうちどこまでエスカレーションしたかが、そのタスクの難所を映す指標にもなります。
対GEPA実測ベンチで見る改善幅と過学習を防ぐガードレール
FAPOの有効性は、既存の最適化器との比較で測られています。Ciscoの評価では、最先端のプロンプト最適化器GEPA（Genetic-Pareto）を比較対象に置いた。GEPAは、実行トレースへの自然言語リフレクションでプロンプトを進化させる手法で、DSPyに実装されています。この評価は6つのベンチマーク×3つのタスクモデル、計18のモデル×ベンチマーク比較で行われました。
Cisco公表の評価では、FAPOは18比較のうち15でGEPAを上回り、平均改善幅は+14.1ポイント（pp）。GEPAが上回った比較も一部ありますが、その差は標本のばらつきの範囲内とされます。とくに、プロンプト先行の探索が構造変更までエスカレーションした2つのベンチマーク（HoVerとIFBench）では、6ペアすべてでFAPOが勝ち、平均+33.8ポイントの改善を記録した。プロンプトの手直しでは届かず、チェーン構造まで踏み込んだケースで差が大きく出た形です。
もうひとつ見ておきたいのが、過学習を防ぐ仕組みです。最適化器が検証データに合わせ込みすぎると、テストデータや本番で崩れる。FAPOはこれを抑えるために複数のガードレールを持ちます。最適化器が検分できるのは training-split（検証用分割）のケースだけで、取り置きテストセットは覗けない。提案された変種のファイルは不変（immutable）で、後から書き換えられない。そして各提案には独立したレビュアーが付き、変更が決められたスコープを守っているか、テストデータの漏れ（データリーク）が起きていないかをチェックします。自動で回るからこそ、こうした制約が効いてきます。
数値の前提（Cisco公表の評価であること・自環境では要検証）
比較値を読むときの前提を明確にしておきます。+14.1ppも+33.8ppも、Ciscoが自ら公表した評価での数字。第三者による独立再現の結果ではありません。使ったタスクモデルの具体名や個別ベンチマークごとの精度は、二次媒体と論文プレプリントで記述が食い違うため、この記事では個票の数値には踏み込まない。確度の高いヘッドライン（15/18勝・+33.8pp）に限って言い切り、細部は「Cisco公表の評価では」という帰属を付けて扱っています。
自分のパイプラインにFAPOを導入する手順と勘所
実際に回すときの流れを、番号で追います。FAPOはリポジトリが公開されているため、環境を用意して手元のタスクを1テナントとして定義するところから始まる。以下は、公開情報から読み取れる導入の骨格です。詳細なコマンドや設定項目は更新されうるため、実行時は公式リポジトリのREADMEで最新の手順を確認してください。
- 最適化したいタスクのデータセットを用意する。各行は「入力」と「期待する出力」のペアにする
- データセットを検証セットと取り置きテストセットに分ける。テストセットは最終評価まで触らない
- 初期プロンプトとチェーン定義、スコアラーを用意する。タスク記述だけを渡してClaudeに足場を生成させることもできる
- オーケストレーション役をClaude CodeかCodexから選び、最適化ループを起動する
- ループが評価→失敗帰属→変種提案→レビュー→比較→反復を回すのを待つ。目標精度かバジェット上限で止まる
- 最後に取り置きテストセットで一度だけ最終評価し、検証セットへの過学習が起きていないかを確認する
データセットの最小構成は、次のようなイメージになります。中身は概念を示すための構造イメージで、そのまま動くコードではありません。
# データセット（構造イメージ）: 入力と期待出力のペア
[
{"input": "...質問やタスク...", "expected": "...期待する正解..."},
{"input": "...", "expected": "..."}
]
# → 初期プロンプト + チェーン(LangGraph StateGraph) + スコアラーを用意
# → Claude Code / Codex が最適化ループを回す
導入で見落としがちな勘所を3点。まず、データセットの質がすべての土台になる。期待出力が曖昧だと、FAPOは何を「正解」として最適化すればよいか判断できません。次に、目標精度とバジェットを最初に決めておくこと。閉ループはどちらかに達するまで回るため、上限を切らないと計算コストが読めなくなる。さらに、最適化が終わったプロンプトも、モデルのバージョンが上がれば挙動が変わりうる点。一度届いた精度を恒久のものと考えず、モデル更新のたびに検証セットで測り直す運用が現実的です。
| 料金 | 無料（オープンソース） |
|---|---|
| ライセンス | Apache 2.0 |
| 提供元 | Cisco Foundation AI |
| オーケストレーション | Claude Code（既定）／ Codex |
| コアエンジン | hephaestus（ドメイン非依存） |
| チェーン表現 | LangGraph StateGraph |
| 対応プロバイダ | OpenAI ／ Baseten ／ SageMaker |
まとめ
多段LLMパイプラインの精度が頭打ちになる根っこは、どのステップが失敗しているか手で追えないこと。FAPOはこの原因特定と改善の反復を、Claude Code駆動の閉ループとして自動化します。誤答をステップ単位で失敗帰属し、プロンプト→パラメータ→チェーン構造という3段階で、安い変更から順に試す。プロンプトで直せる失敗と構造的な失敗を切り分けてから手を打つため、当てずっぽうの変種量産より探索が短く済みます。
Cisco公表の評価では、最先端のGEPAに対し18比較中15で上回り、平均+14.1pp。構造変更まで踏み込んだHoVerとIFBenchの6ペアでは全勝し平均+33.8ppを記録した。過学習は、検証分割のみの検分・変種ファイルの不変化・独立レビュアーという3つのガードレールで抑える設計です。まず試すなら、期待出力を明確にしたデータセットを用意し、目標精度とバジェットを切ってから検証セットで実際の伸びを測る。公表値をそのままご自身の環境に当てはめず、手元のタスクで確かめる姿勢が出発点になります。
よくある質問
Q. FAPOは無料で使えますか？
FAPO本体はApache 2.0ライセンスのオープンソースで、ソフトウェアとしては無料で利用できます。ただし最適化ループはLLMを繰り返し呼び出すため、OpenAIなどのAPI利用料や計算リソースの費用は別途かかる点に注意してください。
Q. Claude Codeが必須ですか？
いいえ。FAPOは既定でClaude Codeをオーケストレーション役に使いますが、代替としてCodexにも対応します。Claude Code専用というわけではありません。どちらのエージェントで最適化ループを回すかを選べる構成です。
Q. GEPAと何が違いますか？
GEPAは実行トレースへの自然言語リフレクションでプロンプトを進化させる最適化器です。FAPOは失敗をステップ単位で帰属し、プロンプト・パラメータ・チェーン構造の3段階を必要に応じてエスカレーションする点が特徴。Cisco公表の評価では18比較中15でFAPOがGEPAを上回りました。
Q. どんなパイプラインに向いていますか？
検索・要約・判断など複数ステップを連ねた多段LLMパイプラインで、どのステップが誤答の原因か手で追いきれない場合に向きます。入力と期待出力のペアからなる評価用データセットを用意できることが前提条件になります。
