promptflow を採用する前に読む: flow.dag.yaml と pf コマンドで何が固まるか

promptflow が埋めようとしている穴は「試作と本番の断絶」

LLM アプリの開発では、プロンプトを書き換えて結果を見る、という作業が延々と続く。問題は、その試行錯誤が Notebook や単発のスクリプトに閉じがちなことだ。動いたコードを本番に持っていく段で、入力の受け渡し、モデル接続、リトライ、そして「この変更で品質が上がったのか下がったのか」の判定が、すべて手作業になる。promptflow はこの断絶を、フローという実行単位を最初から定義させることで埋めようとする。README は「from ideation, prototyping, testing, evaluation to production deployment and monitoring」という一続きの開発サイクルを掲げており、対象読者はプロンプトを書く人と、それを配備する人の両方である。Python パッケージとして配布され、CLI と VS Code 拡張の両方から触れる。

flow.dag.yaml が実行グラフそのものになる

中心にあるのは flow.dag.yaml というファイルだ。README の chatbot の例では、このファイルが inputs/outputs、nodes、connection、そして LLM モデルを記述する。ノードは LLM、プロンプト、Python コード、その他のツールを連結したもので、要するに DAG の各頂点に「何を実行するか」を宣言する。chat ノードでは connection フィールドに open_ai_connection、deployment_name フィールドに gpt-35-turbo が指定されている、と README は説明する。deployment_name は OpenAI のモデル名、または Azure OpenAI のデプロイリソース名を指す。ここが設計上の分岐点である。プロンプトとモデル呼び出しがコードではなく YAML 側に置かれるため、フローの構造をレビューや差分管理の対象にできる。一方で、条件分岐やループを多用する複雑な制御を YAML で表現しようとすると、素の Python で書くより冗長になる。

導入手順: pip と pf コマンドの実際

ローカル環境の場合、README が示すのは pip install promptflow promptflow-tools の2パッケージだ。Python は 3.9 以上 3.11 以下が推奨と明記されている。この上限は見落としやすい。3.12 以降の環境では、依存パッケージの解決が README の想定から外れる可能性がある。フローの雛形は pf flow init --flow ./my_chatbot --type chat で生成され、my_chatbot フォルダと必要なファイルが作られる。API キーの登録は pf connection create で行う。OpenAI なら pf connection create --file ./my_chatbot/openai.yaml --set api_key=<your_api_key> --name open_ai_connection、Azure OpenAI なら同じコマンドで api_base も --set に渡す。README は「override keys and name with --set to avoid yaml file changes」と述べており、キーを YAML に書かずコマンドラインから上書きする運用が想定されている。対話的な確認は pf flow test --flow ./my_chatbot --interactive で、Ctrl + C で終了する。ここまでの流れは一貫して CLI で完結する。

品質を数値で扱うための評価ステップ

promptflow の主張でもっとも具体的なのは、評価を開発サイクルに組み込む部分だ。README は「Evaluate your flow's quality and performance with larger datasets」と書き、その結果を CI/CD に統合してフローの品質を担保できるとする。チュートリアルとして、プロンプト調整、バッチテスト、評価を15分でたどる flow-fine-tuning-evaluation の資料と、PDF チャットを題材に評価指標まで含めた e2e-development/chat-with-pdf の例が案内されている。つまり、フローを定義するとテスト用データセットに対して一括実行でき、その出力を指標で比較できる、というのが売りである。ただし、この仕組みが機能するかどうかは評価用データセットの質に完全に依存する。指標そのものを promptflow が決めてくれるわけではない。ここは README だけでは踏み込んでおらず、実際の評価設計は利用者側の作業になる。

配備と監視は「選んだ基盤に載せる」以上のことを言っていない

README の配備に関する記述は「Deploy your flow to the serving platform you choose or integrate into your app's code base easily」と、抽象度が高い。具体的な配備先や手順は README には書かれておらず、Azure AI 上の Prompt flow をクラウド版として使うことが任意ながら強く推奨されている、という位置づけだ。監視についても、冒頭で production deployment and monitoring に触れるものの、README の範囲では具体像が見えない。ここは採用判断で注意すべき点である。promptflow は実行と評価の枠組みを提供するが、配備後の可観測性は選んだサービング基盤側の機能に依存する。ローカルで完結させたい場合、監視は自前で用意することになる。

LangChain との設計差はどこにあるか

同じく LLM アプリの構成を助けるライブラリとして LangChain がある。両者は解こうとしている問題の重心が違う。LangChain は Python コードの中でコンポーネントを鎖状につなぐ抽象化を提供し、開発者はコードを書きながら組み立てる。promptflow はフローの構造を flow.dag.yaml という宣言的なファイルに外出しし、そのファイルを pf コマンドと VS Code 拡張の両方から扱えるようにする。この違いは、レビューのしやすさと引き換えに、YAML とコードの二重管理を生む。プロンプトだけ変えたいのか、ノードの接続を変えたいのかによって、触るファイルが変わる。すでに LangChain で書かれたコードベースがあるなら、promptflow への移行は書き直しに近い。逆に、プロンプトの差分をレビュー対象にしたい、評価を CI のジョブとして固定したい、という要求があるなら、宣言ファイルを持つ設計は素直に効いてくる。

向かないケースと、採用前に潰しておくべき前提

promptflow が過剰になる場面は明確だ。プロンプトを1つか2つ試すだけ、モデルも1つ、評価データセットも作らない、という段階では、pf flow init でフォルダを作るより単一の Python ファイルのほうが速い。また、Python 3.12 以降しか使えない環境、あるいは gpt-35-turbo や Azure OpenAI のデプロイ名とは異なる接続方式しか許されない環境では、README が示す手順をそのままなぞれない。バージョンは promptflow 1.17.1 が 2025-01-09、1.17.0 が 2025-01-06、1.16.2 が 2024-11-25 と、マイナー更新が比較的短い間隔で続いている。pf コマンドや YAML のスキーマに変更が入る可能性を前提に、フローのファイルをバージョン管理下に置き、更新時に pf flow test を回して差分を確認する運用が要る。ライセンスは MIT で、リポジトリの LICENSE に従う。MIT は商用利用を含めて制約が緩い部類だが、同梱する依存パッケージや、Azure 側のサービス利用条件は別に確認が必要になる。ここは法的助言ではないので、最終判断は自組織の基準で行ってほしい。

編集部の結論

採用を検討すべきなのは、プロンプトを Python 関数と YAML のノードに分解し、その構成をそのまま CI で回したいチームである。逆に、単発のスクリプトや対話的な試行錯誤だけで完結する用途には、flow.dag.yaml と pf コマンドの学習コストが回収できない。導入前に確認するのは、Python が 3.9 から 3.11 の範囲に収まっているか、対象モデルが gpt-35-turbo のような既存の接続方式で扱えるか、そして評価を回すデータセットを自前で用意できるかの3点。特に評価データが用意できないなら、promptflow の中心的な価値である品質改善ループは空回りする。

公式情報源

1. License: MIT
2. microsoft/promptflow on GitHub
3. Project website
4. README
5. Releases