コドモン Product Team Blog

株式会社コドモンの開発チームで運営しているブログです。エンジニアやPdMメンバーが、プロダクトや技術やチームについて発信します！

13サイクル回してわかった、AI生成コンテンツの品質を高める3つのポイント

AI プロンプトエンジニアリング

はじめに

コドモンで新規事業に取り組んでいる重田です。

最近、プロンプトエンジニアリングに初挑戦しました！ とあるインプットから、AIを使ってテキストコンテンツを生成するのですが、リリースできる品質に持っていくまでにたくさんの試行錯誤をしました。

この記事では、その過程で得たプロセスの話をお伝えします。生成しているコンテンツの中身そのものではなく、品質を高める仕組みをどう作ったか に絞って書きます。 これからAI生成コンテンツの開発に取り組むエンジニア・PdM・デザイナーの方に向けて、特に効果的な 3つのポイント を共有します。

💡ポイント1: 何はともあれ、PDCAを回せる状態を作る

価値を届けたいユーザー層の方に満足してもらい、事業目標の達成につなげるにはコンテンツの質はとても重要です。 品質を高めるには、何度も試行錯誤を繰り返すしかありません。一発で正解にたどり着くことはまずなく、評価して、何が良くて何が悪いのかを見極め、プロンプトを直して、また評価する。このサイクルを淡々と回せる状態を作ることが、品質を磨くための前提条件になります。

私たちはまず、この PDCAを回せる状態 を整備することから始めました。 評価ツールとしては promptfoo を採用し、その上で サイクル管理 と 2層評価 の運用を取り入れています。

評価ツールとしてのpromptfoo

評価の土台として、promptfoo というオープンソースのLLM評価フレームワークを採用しました。

  • YAMLでテストケース（プロンプト入力 + 期待される条件）を定義できる
  • 各テストケースに対して アサーション（評価ルール）を設定できる
    • 「100文字以内」のようなルールベース判定
    • 「事実誤認がないか」のような曖昧性を含むものもLLMで判定できる（LLM-as-a-Judge）
  • 実行すると全テストケースの結果を内蔵のWebUI（promptfoo view）から確認できる

プロンプト評価の仕組みをゼロから作るとそれだけで大仕事ですが、promptfoo を使えば最低限の評価基盤はすぐに整います。 このあとの話は、promptfoo を土台にしています。

サイクル管理

通常、コードはgitで履歴を管理します。ファイルシステム上に過去バージョンを並べておくことはしません。プロンプトも同じ感覚でgit管理だけで運用しようとすると、「前のサイクルと比べてどう良くなったか / 悪くなったか」が確認しづらい という問題が出てきます。

私たちはバージョン管理に加えて、サイクル管理 という運用を取り入れました。

.
├── cycle1/
│   ├── promptfooconfig.yaml
│   ├── prompts/
│   └── reports/
├── cycle2/
│   └── ...
├── ...
└── cycle13/
    └── ...

ポイントは3つです:

  1. 過去のサイクルを消さずに残す — いつでも前のサイクルの設定や結果を参照できる
  2. テストデータとアサーション（評価条件）は全サイクルで共通 — 比較可能性を担保する
  3. 新しい試行は新規ディレクトリで — 過去に影響を与えずに変更を加えられる

この形にすると、「cycle5とcycle6でこの観点のスコアが下がった」「cycle10で新しい指示を入れたら全体のバランスが崩れた」のような比較がやりやすくなります。バージョン管理でもgitのlogをたどれば同じことはできますが、ファイルシステムの中ですぐに参照できたほうが人間もAIも試行錯誤しやすくなります。

自動評価と主観評価の2層で運用する

評価は2つの層に分けて運用しています。

自動評価 は、promptfoo のアサーション機能を使って、毎回のサイクル実行時に自動判定します。「禁止された語彙が含まれていないか」「出力フォーマットが守られているか」のような客観的に判定できる観点や、LLMをJudgeとして使う主観に近い観点の判定を自動で回します。 これは 最低ラインを担保する仕組み です。プロンプトを変更したときに、これまで満たしていた条件を壊していないかをCIのように確認する役目を果たします。

主観評価 は、人間が出力を見て「これは良い」「これは違和感がある」と判断する作業です。自動評価で計測しきれない、文章のニュアンス、温度感のようなものは、人間の目で見るしかありません。主観評価もLLMで試してみたのですが、評価軸を明確に言語化しづらい情緒的な内容を扱っているため、イマイチうまくいきませんでした。

自動評価はテストファーストにこだわらない

テストファーストが理想ですが、そうはいきませんでした。

プロンプトエンジニアリングをやりながら感じたのは、エンジニアリングといいつつデザインの要素が強いなということです。 最初に仕様を定義してそれを満たす実装をするのではなく、サイクルを回し、時にはたくさんのバリエーションを発散させながら、より良いコンテンツや品質のガードレールを探るプロセスでした。

見つけたガードレールを都度アサーションとして定義し、自動評価を回せる状態を作りました。

💡ポイント2: チームから手軽にフィードバックをもらえる仕組みがポイント

こんな感じでMiroを使ってました

改善サイクルを回す中で、特に効いたのがここです。

何が正解か不透明な中、1人で主観評価をやるとどうしても行き詰まってしまいます。 ユーザーのことを誰よりも理解しているPOやデザイナーを中心に、チームからフィードバックを得ることが重要です。

そのために、フィードバックをもらいやすい状態を作るよう工夫しました。

HTMLレポートでは参加してもらえない

promptfoo で評価を実行すると、結果は内蔵のWebUI（promptfoo view）から閲覧したりできます。エンジニアにとっては慣れた形式ですが、これをPdMやデザイナーに「見てフィードバックしてください」と渡しても、なかなか実のあるレビューにはなりません。

  • HTMLレポートは情報量が多く、どこを見ればいいか分からない
  • 比較したい出力同士が離れた場所にあって、並べて見にくい
  • コメントを残す場所がない

参加コストが高いと、レビューしてもらえる回数が減ります。回数が減ると、改善サイクルが回らなくなります。

スクリーンショットにしてMiroに貼る

promptfoo の内蔵ビューアではなく、独自に見やすい形のHTMLレポートを生成し、見てもらいたい箇所だけを スクリーンショットにしてMiroに貼る というやり方を採用しました。

AIを使えばレポートの生成スクリプトは簡単に作れますし、スクショの生成も自動化できます。

それをMiroに貼ることで、フィードバックするコストが大きく下がりました。サイクルごとの結果を全てMiroに残すことで、今の進捗や生成結果が良くなっている様子を可視化することもできました。

💡ポイント3: やりながら構造を見出す

サイクルを回しながら、もうひとつ大事な変化が起きました。プロンプトの設計を支える「考え方の枠組み」が、走りながら見えてきた ことです。

6サイクル目あたりの気づき

最初の数サイクルは、生成結果を見ながら「良いところ」と「違和感のあるところ」をMiroで付箋に書き、プロンプトを改善する作業を繰り返していました。 （チームメンバーからフィードバックをもらいつつ、自分自身でも付箋に書いて、何から直すべきかを考えていました）

そうしているうちに、Miroの付箋が大きく2種類に分かれていることに気づきます。

  • 「この内容を入れた方がいい / 避けた方がいい」というコメント
  • 「この言い方が気になる / 違和感がある」というコメント

何を書くか（内容） と どう書くか（伝え方） に分解できることに気づいたのです。

もう少し抽象度を上げて整理すると、生成しているコンテンツは次のような式で表現できることが見えてきます。

コンテンツ = 内容 × 伝え方 × バリエーション

これをマインドマップに整理しました（具体の指示内容は伏せて、構造のみ示しています）。

これは最初から設計していたものではなく、ループを回した結果として見えてきた構造 です。

構造を見出すことで得られた3つの効用

この整理ができたことで、3つの効用がありました。

1. デザイナーとのコラボレーション

「ボイス」「トーン」のような語彙は、もともとUXライティングやブランドガイドラインの世界で使われている概念です。これをプロンプトの設計に持ち込んだことで、デザイナーとのコラボレーションが生まれました。

2. 自分の中の整理ができた

Miroで集まるコメントが「内容軸の指摘」「伝え方軸の指摘」のいずれかに分類できるようになり、対応の優先順位や、どこを修正すれば良いかが見えやすくなりました。

3. プロンプトの構造化ができた

プロンプトを書くときの章立てが、フレームに沿って自然に決まるようになりました。「ここは内容の指示」「ここはボイスの定義」「ここはトーンの調整」のような構造化が進み、修正もしやすくなります。

まとめ

AI生成コンテンツの品質を高めるには、何度も試行錯誤を繰り返すしかありません。一発で正解にたどり着くことはまずありません。だからこそ、まず 回せる状態を作る ことが何よりも大事です。

繰り返しになりますが、13サイクル回してきた経験から、特に効果的だった3つのポイントは以下です。

  1. PDCAを回せる状態を作る: サイクル管理。自動評価と主観評価を2層で運用する
  2. チームから手軽にフィードバックをもらえる仕組みを作る: スクショとMiroで、PdM・エンジニア・デザイナーの誰でもコメントできる場所を用意する
  3. やりながら構造を見出す: 最初から完璧なフレームを目指さず、改善サイクルを回しながら自然に出てくる整理を取り込んでいく

特に2つ目の チームからのフィードバックを集める仕組み は、ループを継続させる上での生命線でした。 自分では想像できていなかった良いフィードバックをもらえることもありますし、人と話すことで沼にハマりすぎてしまうのを回避できます。

これからAIを使ったプロダクトを作る人にとって、何かの参考になれば嬉しいです。