LLMプロダクトの開発プロセス例
はじめに
この記事は、LLM を活用したシステムを企画・実装・運用する際のプロセスについて、私が考えた１つのサンプルの、そのまた一部を紹介するものです。 あくまでサンプルなので、状況によって全然活用できないかも知れません。読まれる方はそれを念頭に読んでいただきたいです。もし間違った部分があればコメントいただけるとありがたいです。
概要
背景
「Step‑by‑Step MLOps and Microsoft Products」という資料では、ML プロダクトのライフサイクルを次の三つのループで説明しています。
- INNER LOOP: モデル探索・モデル学習・モデル評価・モデル選定
- MIDDLE LOOP: 学習パイプライン構築・パラメータチューニング・モデル QA
- OUTER LOOP: 本番デプロイ・推論・モニタリング・継続学習
しかし、Gemini、Claude、ChatGPT など 事前学習済みのモデルが利用可能になったことで、このプロセスはやや変化しています。 たとえば ALGOMATIC の方が 2025 年 4 月に公開した資料からは、「モデルの学習」以降に、「プロンプト設計と出力の評価」に関するプロセスが追加されていることがわかります。
この資料が素晴らしすぎるので、これ以降の文章を書く意味はあるのかという気持ちになりつつ、自分の考えの解像度を高めるために文章にします。
本記事で扱うプロセス
私が実行しているAIプロダクトの開発プロセスは下記のようになります。
この開発プロセスは下記３つのループにより構成されています。
- モデル・プロンプト実装・評価ループ
- 前処理とエージェント実装・評価ループ
- ユーザー評価ループ
「前処理やエージェントとしての挙動の確認をなるべく早い段階で行いたい」というニーズから、このようなプロセスにしています。
モデル・プロンプト実装・評価ループ
このループでは、以下の 3 ステップを小さく回します。
- AI システムの仕様決定: ユースケースごとに入力と期待出力を明確に定義する
- AI システム設計: 所望の出力を得るためにタスクを分割し、エージェント間の相互作用を設計する
- プロンプト設計・評価: 各エージェントに与えるプロンプトの策定と、期待するエージェントの出力を決定する
AI システムの仕様決定 では、AI システムに対する入出力を、ドメインエキスパート、PM、エンジニア間で話し合って決定します。想定されるユースケース毎に最低十数点の入出力データセットを用意します。
AI システムの設計では、基本を単一のプロンプト・エージェントでの要求実現を前提としつつ、それで難しい場合に、タスクを分割し、エージェント間をどう相互作用させるか決めます。
プロンプトの設計・評価においては、上記 AI システムを前提として、それぞれの AI エージェントに対して、予想する入力と期待出力のペアを渡し、性能を評価します。
このループで期待性能を満たさない状態で開発に進んでも、期待する成果は得られません。そのため、このループが最も重要になります。
前処理とエージェント実装・評価ループ
このループでは、モデル・プロンプト実装・評価ループで固めた設計方針を具体的なコードとワークフローに落とし込み、以下のステップで検証を行います。
- 入力データ取得・前処理
- エージェント実装
- 結合テスト
入力データ取得・前処理では、必要なデータを取得するパイプラインを実装し、LLM に渡すフォーマットに変換します。画像の場合にはモデルが画像を精度高く読み解くために必要な処理をすることもあります。
エージェント実装 では、エージェントが呼び出す Tool（関数呼び出し・外部 API・検索エンジンなど）とプロンプトを実装し、マルチエージェントの場合はエージェント間の相互作用を実現します。
結合テストでは、UI なしで CLI や notebook からエージェントを実行し、性能を評価します。
ここで期待されるパフォーマンスが得られなければ、「モデル・プロンプト実装・評価ループ」に戻ることも視野に入れて、修正・改善を行います。 ここでは基本的に UI 実装は不要だと思われますが、UI を AI が動的に構築するなどの要件の場合は UI の実装・評価もこのループに組み込むと良いでしょう。
ユーザー評価ループとステークホルダー
このループでは、実際の環境でシステムを利用できるようにして、オンライン評価を行います。 このループで得られた定量・定性データから、さらなる改善・修正を考案し、またモデル・プロンプト実装・評価ループに入ります。 すべてのプロセスを書くのは大変なので、以降では、モデル・プロンプト実装・評価ループのみ詳細を記述しようと思います。 需要があったら、別の記事にて紹介します。
なお、開発におけるステークホルダーとの想定される協力体制を下記に示します。
モデル・プロンプト実装・評価ループ
ゴール
このプロセスは下記条件を満たすことがゴールです。
- AI システムの仕様が決定
- 評価用データセットの作成
- AI エージェント全体の設計
- 各エージェントの役割設定
- エージェント間の相互作用の決定
- 利用するモデルの決定
- 各 エージェントに対するプロンプトの設計・評価が完了している
- 各 AI エージェントに入力するプロンプトの決定
- AIに依頼する指示
- AIが指示を達成するための入力データ
- 各 AIエージェントにプロンプトを与えた後の出力評価
- 各 AI エージェントに入力するプロンプトの決定
AI システムの仕様決定
インタビューなどで課題特定はされている前提です。
AI システムの仕様決定では、AI システムに対する入出力を、ドメインエキスパート、PM、エンジニア間で話し合って決定します。
まず、AIシステムの具体的なユースケースを洗い出します。 たとえば、「１年分のレシートからユーザーの消費傾向を推測し、ユーザーのカレンダー上の情報も踏まえて、今年の消費予想金額を規定のカテゴリ毎に算出する」などです。
次に、各ユースケースにおいて、AI システムへの入力と期待される出力を決定します。 上述したユースケースを例にすると、入力は「１年分のレシート、１年分のカレンダーの情報」であり、出力は「年間のカテゴリ毎の出費予想」です。 重要なのは、どのような入力に対して、どのような出力が「成功」とみなされるかをステークホルダー内でしっかりと合意することです。
最後に評価方法を決定します。 AI を検索に用いる場合は評価指標(Accuracy, Recall, F1 Score など)を決めますし、テキスト出力を期待する場合は評価用データセットを作成します。 代表的な入力データと、それに対応する「理想的な」出力データのペアを複数用意します。 例えば今回のケースにおける理想的な出力データの例として、下記のものが想定されます。
{ "食費": "xxxx", "NISA": "xxxx", "ideco": "xxxx", "書籍費用": "xxxxx" }
初期段階では、ユースケースにもよりますが、数十から、百件程度のデータセットがあると良いでしょう。 このデータセットは、後の「AI エージェント全体の評価」プロセスで実際に使用されます。
AI エージェント全体の設計
AI システムの仕様が決まったら、それを実現するための具体的な AI エージェントの構成を設計します。 基本方針として、まずは単一の AI エージェント（単一のプロンプト）で要求を実現できないかを検討します。多くの場合、高性能なモデルを選択すれば、シンプルな構成で十分に期待に答えてくれます。
単一のエージェントでは要求を実現できない場合、複数の エージェントによるタスク分割を検討します。例えば、以下のようなケースではタスクの分割が有効な場合があります。
- 入力として求められるデータが大量・多様である
- 入力データの解釈に専門性が求められる
- AI エージェントの行動結果を元に次のアクションを決定する必要がある
入力として求められるデータが大量かつ多様の場合、１つのエージェントではコンテキストウィンドウの制約から対応が難しいことがあります。その場合はエージェントを分割し、データを集約するエージェントと、集約された結果を活用してタスクを実行するエージェントを作ることになります。
入力データの解釈に専門性が求められる場合、エージェントは INPUT 以外にも各種 Tool や RAG を用いてデータを取得・活用して解釈しなければならないことがあります。その場合もエージェントを分割し、解釈するエージェントと、解釈した結果を活用するエージェントに分けることがあります。
複数のエージェントによる相互作用か？と言われると少しむずかしいですが、このあたりについては下記の記事に記載しました。良かったら見ていただけると嬉しいです。
AI エージェントの行動結果を元に次のアクションを決定する必要がある場合は、例えばコーディングのエージェントなどがそれに該当します。あるエージェントが出力したコードを活用し、次のエージェントがテスト実行とその結果の評価をします。そしてその評価結果を元に、コードを修正する。といった挙動をします。
複数のエージェントを設計する場合、各エージェントの役割、入力、出力を明確にし、エージェント間の相互作用も設計します。
また、この段階で利用する LLM モデルを選定します。 タスクの性質、複雑さ、要求される精度、コスト、レイテンシなども考慮してモデルを選択します。 初期段階では高性能なモデルで検証し、十分な精度が確認されたらコスト効率の良いモデルへの変更を検討すると良いでしょう。
AIエージェントの設計において、「Agentic であることが良い」「Workflowは良くない」という議論を見かけるようになりました。設計において私は「いつでも使える方法や銀の弾丸は、基本的には存在しない」と考えています。開発者が直面している状況は、プロダクトや課題の性質、成果を期待されている期間などによって、全く異なるはずです。状況が違えば適切なシステムの設計も異なります。様々なトレードオフを踏まえて、自分の責任で判断することがエンジニアの仕事です。権威的な意見については思想や適用範囲を理解しつつ、それでもそれらの意見に安易に流されずに、自分たちと彼らの前提を想定して、自分たちに最適な設計を決めると良いと思っています。
blog.langchain.dev ※ ちなみに、私はこれらの議論に対して LangChainの方と同じような意見を持ってます。
入力データの構造化について
AI システムを構築する各エージェントに対して、どの程度構造化したデータを用いるかは、ケースバイケースで検討する必要があります。 例えば、レシートの画像を読み込む家計簿アプリのようなものを開発しているとして、「年間の消費傾向から翌年の出費を予測したい」という機能要望があったとき、 レシート画像だけで要望を実現するのはモデルが許容できるコンテキスト長から考えて難しいでしょう。１枚１枚のレシートから構造化されたデータを用意し、それらを SQL などを用いてサマライズして、要望を叶えることになります。
構造化にはメリットもありますが、リスクも伴います。例えば、将来的に新しい要件が発生した際に、既存の構造化データでは対応できなくなる可能性があります。
唯一の正解はなく、要件に応じてリスクを評価し、判断する必要があります。短期的な開発効率のために構造化データを利用しつつ、将来的な拡張性を考慮して非構造化データも保持しておく、といった選択肢もあります。
一口に構造化と言っても度合いは様々で、私はモデルが読み取った内容を JSON の自由フォーマットで保持させることもあります。どの程度の構造化が、短期・長期的な視点での ROI 最大化に繋がるかを意識し、自覚的にリスクを取る必要があります。構造化の設計が後の機能開発に追従できなくなったとき、後のエンジニアに批判されることもあるでしょう。しかし、それを恐れて構造化せず機能を適切な時期にリリースできなければプロダクトは失敗します。かと言って拙速な設計で多大な負債を残してしまえば、中期的なスパンでプロダクトの成長を妨げることもあります。戦略的にリスクを取ることがエンジニアの仕事です。「批判を恐れて何も決めない」ということがないようにしましょう。
プロンプトの設計・評価
AI エージェントの設計が完了したら、その性能を評価します。 この評価プロセスでは、「AI システムの仕様決定」の段階で作成した評価用データセットと評価基準を用います。
評価の主な目的は以下の通りです。
- 設計した AI エージェントが、要求を満たしているかを確認する。
- 各エージェントが期待した出力をするかを確認する。
- エージェントの性能が目標値を達成しているかを測定する。
具体的な評価手順は以下のようになります。
- 評価用データセットの適用: 仕様決定時に作成した評価用データセットの入力データと、AIに対する指示を設計した AI システム（または個々のエージェント）に与えます。
- 出力の比較: 得られた出力と、評価用データセットに含まれる「理想的な」出力データを比較します。
- 評価指標の算出: 定めた評価基準（Accuracy, Recall, F1 スコアなど）に基づいて、性能を定量的に評価します。
単体のエージェントであれば上記評価用データセットと評価基準をそのまま使えます。 しかし、複数のエージェントが協力するような仕組みにおいては、各エージェント毎に評価用データセットと評価基準を作り、各々の性能を評価します。 この時点ではエージェントは繋げずに、あくまで単体でテストをします。
評価の結果、性能が目標値に達していない場合は、ボトルネックとなっている箇所を特定し、修正・改善します。 原因によっては、仕様、エージェント設計から見直すこともあります。 この評価と改善のサイクルを繰り返し、AI システムが目標とする性能基準を満たすことを目指します。
最後に
以上、自分が考えた「LLMプロダクトの開発プロセス例」の紹介でした。 何かしら気になるところ等々ありましたら、コメントにて教えていただけると幸いです。
