AIのテストをするつもりが、プロンプトも書くことになった話

LayerXさんでのイベント
AIプロダクトの品質保証を語ろう！ - freee × マネーフォワード × LayerX の登壇資料です
https://layerx.connpass.com/event/381467/

Transcript

1. AIのテストをするつもりが、 
 プロンプトも書くことになった話 
 
 2026.02.16
2. 2 1. 対象機能とシステム構成
 2. AIプロダクトのテストの目的
 3. 開発における課題
 4. 課題の解決
 5. 精度検証の効率化
 6. 機能別の評価方法
 7. メンテナンス
 8. まとめ
 目次

3. 3 ワークフロー 契約締結 保管管理 ⽂書作成 煩雑な契約業務をワンストップでカバーできる機能を搭載 ⾼機能で使いこなせないではなく、痒い所に⼿が届く便利な機能が豊富 freeeサインの紹介 

4. 4 対象機能とシステム構成 
 
 検索項目自動登録： 
 契約書から以下の項目を抽出・登録する機能
 抽出項目：会社名・金額・契約開始日・契約終了日・自動更新の有 無・解約通知期限
 
 リースチェック： 
 契約書の内容から「リース契約※」に該当するかを判 定し、その根拠も示す機能
 
 どちらの機能も AIの学習は無効となっています 
 
 ※リース契約とは、リース会社が購入・所有する設備や機械などを、利用 者が一定期間・一定額のリース料を払って長期利用する契約形態のこと です。
 
 社内LLM
 OCR
 社内LLM
 リースチェック 
 検索項目自動登録 
 契約書アップロード画面 
 対象機能
 システム構成 

5. 5 AIプロダクトのテストの目的 
 1. 精度向上（プロンプトのチューニング） 
 AIが実用レベルの回答を出せるよう、出力をコントロールするため
 a. 目標値の設定: 
 精度80%以上を目標に、プロンプトを繰り返し改善
 b. データ準備: 
 実際の契約書、Web上のテンプレート、LLMに生成してもらったデータなど計100件を用意
 c. 専門家による判断（リースチェック機能）: 
 単なる正誤判定だけでなく、公認会計士の視点を取り入れ、「判定の根拠」が妥当かどうかも精度の一部として検証
 
 2. 不具合の抽出（品質の担保） 
 システムとして安定して動作し、予期せぬ挙動を防ぐため
 a. LLMとアプリとの連携部分でバグがないか、ユーザーが実際に操作した際に期待通りの挙動をするかを確認
 b. リスクの最小化: 事前にプロンプト側で「想定外の回答」を絞り込んでおくことで、アプリ実装後の致命的な不具合を未然に防止

6. 6 元々は、機能開発と同様に、
 「開発エンジニアがプロンプトまで書く」という予定ではありました。
 
 実際にやってみると、以下のような課題がでてきてしまいました。
 
 1. 開発のリソースの逼迫 
 a. プロンプトの検証コスト思ったよりも大きく、アプリケーション開発のリソースを逼迫してしまうという懸 念がありました。
 
 2. 非効率なテストとスケジュール 
 a. アプリケーション開発が終わった後にアプリケーション上でテストする想定になっており、非効率かつ スケジュール的にもあまり現実的ではない状況でした。
 
 開発における課題 
 要件定義
 プロンプトチューニング 
 QAテスト
 メイン機能開発
 元々想定していた開発フロー 

7. 7 
 1. 開発のリソースの逼迫の解決 
 a. プロンプト自体は自然言語での記述が大半となっており、開発エンジニアが作業する必要性は薄い のでは？というところから、じゃあQAがやってみようとなりました。
 これにより、開発リソースの問題が解消されました。
 
 2. 非効率なテストとスケジュールの解決 
 a. LLM上で出力の検証もできるのでは？というところからアプリケーションの完成を待たずに、プロンプ トの検証をしてしまおうとなりました。これにより、アプリケーション開発とプロンプトチューニングが並 列して実施できるようになりました。
 b. アプリケーション上でのテストは、大量のデータ検証はとても非効率になるため、専用のツールを開発 してもらいました
 
 課題の解決 
 要件定義
 チューニング
 ツール開発
 プロンプトチューニング 
 QAテスト
 メイン機能開発
 実際の開発フロー 

8. 8 精度検証の効率化 
 プロンプトチューニングツールの活用
 100件のデータを繰り返し検証するため、専用の一括処理ツールを開発。
 
 • 大量の契約書をまとめてLLMに投入
 • 結果をスプレッドシートへ自動出力
 • アプリ完成を待たずにPDCAを高速化
 
 
 検索項目自動登録 
 リースチェック
 社内LLM
 チューニング ツール
 
 
 OCR

9. 9 機能の特性に合わせて、評価の軸を使い分けました。
 機能別の評価方法 
 検索項目自動登録 
 評価軸：期待値一致 
 期待値が明確なため、どれだけ期待値に沿ったアウトプットができるかを評価
 本来取れなくても問題のないデータが取れるケースもあり、ノイズとしてカウントはしているが異 常値でなければ許容している
 
 リースチェック 
 評価軸：期待値一致・妥当性判断 
 判定は期待値一致として明確ではあるが、判定の「根拠」に定まった正解がないため、公認会 計士の協力を得て、出力が許容できるかを一件ずつ検証

10. 10 メンテナンス 
 外部モデルを利用する上で、サポート終了への対策は必須です 。
 モデルアップデートのたびに同じような検証を再度実施するのは非効率なため、
 自動比較用のLLMアプリを作成し新旧モデルのアウトプットを比較するための仕組みを構築
 
 出力結果を事前に準備した「期待値」と自動照合し、正誤判定を自動化
 モデルアップデート時の迅速な検証とリリースを実現しています
 
 社内LLM
 （アップデート 後）
 メンテナンスツール
 
 
 
 
 
 
 
 
 
 OCR
 検証LLM

11. 11 これまでのQAエンジニアは、「裏方」のような立ち位置と感じておりました。
 しかし、今回の経験を経て、「主役」になれる可能性を感じました。
 まとめ：QAが切り拓く、 AI時代のシフトレフト 
 1. プロンプトは「仕様」：
 QAがプロンプト作成に関わることは、「シフトレフト」そのもの。
 
 2. 開発効率の最大化：
 アプリの完成を待たずに精度検証を並列で走らせることで、リリースまでのリードタイムを大幅に短縮。
 
 3. 品質の作り込み：
 「期待値」に誰よりもこだわるQAだからこそ、AIの振る舞いを理想に近づけられる。