2026年4月、「カミナシ 教育」開発チームのオフサイト。
エンジニア・プロダクトマネージャ（PM）・プロダクトデザイナー（PD）が3人ずつのチームに分かれ、「カミナシ 教育」のAI機能をいじりながら、ある特殊なケースを探していました。
機能のバグでしょうか？いえ、もっと厄介なものです。「出力結果はおかしいのに、評価指標は問題なしと判定してしまうケース」——AI機能を評価する仕組みそのものの盲点です。
これが私たちのチームで実施したAI評価改善ワークショップの一場面です。
こんにちは、カミナシでAIエンジニアをしている井上です。カミナシではプロダクトのAI機能の検証や開発、プロダクト横断のAI機能運用の基盤作りなどに携わっています。現在は「カミナシ 教育」のAI機能の評価基盤構築に取り組んでおり、本記事でご紹介するワークショップもその一環です。
なぜ、わざわざチーム全員を巻き込んでこんなことをしているのか。AI機能の品質を継続的に維持・改善していくためには、人間の目や顧客の声に基づく定性評価だけでは限界があり、開発時やデプロイ前の自動化された定量評価の仕組みが欠かせません。しかし、評価指標そのものがプロダクトの本質的な価値や人間の感覚とズレていれば、スコアが高くても品質は低いままになってしまいます。
つまり、AI機能の改善と並行して、評価の仕組みそのものも継続的に改善していく必要があるのです。
そしてこの評価の仕組みを育てる営みは、AIエンジニアだけで完結させられるものではありません。何を良いアウトプットとするかの判断基準は、PMが見ているユーザーの期待値や、PDが描くプロダクトの方向性など、多様な視点を統合してこそ磨かれていきます。AIエンジニア1人の感覚よりも、チームが持つ集合知の方が、顧客の感覚により速く・より正確に近づける——これが私たちの考える、AI品質改善をチームで取り組む価値です。
だからこそ私たちは、評価指標と実際の品質の乖離が顕在化する前に先回りしてAI品質改善をチーム全員の取り組みにする文化づくりに着手しました。今回のワークショップは、その第一歩です。
文化として根付かせるために、ワークショップという形を選んだ
チーム全員でAIの品質改善に取り組む——と言葉にするのは簡単ですが、実際にやってもらうとなると障壁があります。それは「AIの改善って、なんだか難しそう」という先入観です。
例えばLLMを活用した機能の改善なら、LangfuseのようなLLMOpsツールを使う必要がありますし、「データセット」「評価指標」「LLM-as-a-Judge」といった専門用語も登場します。こうした要素が実際の作業以上に難しい印象を与え、チームメンバーの心理的ハードルを必要以上に高くしていると思います。やってみると「案外自分たちでもできる」と感じられる部分が多いのですが、その感覚は外から眺めているだけでは伝わりません。
だからこそ、チーム全員が手を動かしてAI機能の品質改善を体験する場が必要だと考え、ワークショップを実施することにしました。
なお、本来は評価の改善とAI自体の改善（プロンプトや処理の改善）の両方を体験してもらいたかったのですが、時間の都合で今回は評価の改善にフォーカスしています。良い評価は良いAI機能を作るための前提条件であること、そしてAI機能自体の改善に比べて「何をやるのかイメージしにくく、1人だととっつきにくい」領域であることが理由です。ワークショップという"みんなで一緒にやる"形は、ハードルが高く感じられがちな評価改善の導入にこそ向いていると考えました。
ワークショップの設計
今回のワークショップは、LLMを活用した1つの機能を対象に、その評価の仕組みを改善していく形で設計しました。複数の機能を扱うと論点が散らばってしまうため、最初の取り組みとしては1機能に絞ってチーム全員で深く向き合える構成にしています。
チーム編成
開発チームをエンジニア・PM・PDが混在した3人ずつの小チームに分割しました。職種をあえて混ぜることで、評価の視点が一面的にならないようにしています。
当日の流れ
- 苦手なケースの収集（15分）
- 評価を実行して観察する（10分）
- 評価方法を改善する（30分）
- 共有と発表（20分）
1. 苦手なケースの収集（15分）
各チームで、プロダクト上のAI機能がうまく動かないケース（入力テキスト）を集めます。単にうまくいかないケースを探すのではなく、「評価をすり抜けそうなケース」を意図的に探すのがポイントです。既存の評価指標がどんな観点で動いているかを眺めながら、「この指標だと拾えなさそうな入力ってどんなものだろう？」とチームで仮説を立て、プロダクト上でさまざまな入力を試していきます。
実際の運用では、こうしたケースは既存顧客が日々使う中で自然に上がってきたり、新規顧客の新しい使い方で見つかったりするものですが、ここではそれを凝縮した形で体験してもらいました。
2. 評価を実行して観察する（10分）
集めたデータセットで評価を実行します。私たちのチームでは、PRに紐づいてGitHub Actions上で評価が自動実行され、結果がLangfuseに蓄積される仕組みになっています。評価指標は単一のスコアではなく、「文体に一貫性があるか」「読みやすい文章になっているか」など観点別に複数用意されているのが特徴です。
ここでの判断基準は以下のとおりです。
- スコアが低いデータ → 問題なし（苦手なケースを定量評価が正しく検出できている）
- スコアが高いデータ → 問題あり（本来検出すべきケースを評価の仕組みがすり抜けている）
3. 評価方法を改善する（30分）
評価ですり抜けてしまったケースに対して、各チームで原因を議論し、評価の仕組みそのものに手を入れていきます。コードベースの評価指標の追加・修正、LLM-as-a-Judgeの新しい評価指標の追加、既存の評価プロンプトの修正といったアプローチから選んで改善します。
ここが一番議論が白熱するフェーズで、「このケースって結局何が問題なんだっけ？」という問い直しから、「お客さんの望む"精度"ってどんな指標で測れば良いんだっけ？」といったプロダクトの本質的な価値まで話が広がることもしばしばありました。
4. 共有と発表（20分）
最後に各チームが、見つけたエッジケース・評価の改善内容・議論の過程を発表します。発表を聞くうちにチーム横断で共通するAI機能の課題が浮かび上がってきたり、「こんな観点、自分たちでは思いつかなかった」という発見があったりしました。そして何より、評価の改善って、案外自分たちでもできるんだという手応えを持ってもらえたのが、私としては一番嬉しい瞬間でした。
やってみてわかったこと
最大の発見は、「評価指標がすり抜けてしまうケース」を自分の手で見つけることで、初めて定量評価の限界と重要性を腑に落ちる形で理解してもらえるということでした。「スコアが高くても品質が低いことがある」という事実を、自分が収集したデータで目の当たりにすることで、PMやPDも含めたチーム全員が評価改善の当事者になれました。また、職種をまたいだ議論の中で、AIエンジニアだけでは気づけなかった「ユーザー視点での違和感」が評価指標に反映されるようになったのも大きな収穫です。
このワークショップは一度きりで終わりにするつもりはありません。いくつかのAI機能について、また小チームを結成し、チーム全員が関わる形で評価改善とAI機能そのものの精度改善に継続的に取り組んでいく予定です。
AI機能の品質は、AIエンジニアだけが守るものではありません。開発チーム全員で育てていくものだと、私たちは考えています。同じような課題感を持つチームの参考になれば嬉しいです。
おわりに
最後に、カミナシでは現在AIエンジニアを募集しています。本記事の通り、カミナシのAIエンジニアは実装だけではなく、AIを道具として適切に扱うための活動を文化として開発チームに根付かせる役割も担っています。興味のある方はぜひ一度カジュアル面談でお話ししましょう！
