AI出力の評価とは？手直しを終わらせる改善ループ [FLEXY meetup イベントレポート]
2026年5月12日に開催されたFLEXY meetupのテーマは「AI出力の評価と改善ループの作り方」。Asterminds株式会社CTOの加賀谷氏と、LLMアプリエンジニアのseya氏が登壇しました。本レポートでは、感覚的な手直しから脱却し、AIの出力品質を評価で科学的に高め続ける方法がわかります。
※登壇内容は登壇日時点のものです
FLEXY（フレキシー）は、副業・フリーランスのエンジニア・CTO・技術顧問・デザイナーの方向けに案件を紹介するサービスです。スキルや希望条件を登録しFLEXY担当者と面談を行うことで、専任の担当者が案件の紹介や契約まわりのサポートを行います。
無料キャリア相談を申し込む ＞＞
目次
AI出力の評価（Evaluation）とは？──本レポートを読むための前提知識
AI出力の評価とは、生成AIやLLMが返す出力の良し悪しを、感覚ではなく客観的な基準で測れる状態にする取り組みを指します。プロンプトやスキルを「なんとなく良くなった気がする」で調整し続ける運用から抜け出すための考え方です。
感覚的な手直しと評価の違い
従来のプロンプト調整は、どこを変えたから何が効いたのかがブラックボックスになりがちでした。評価では、達成したいこと（何を守りたいか）を先に言語化し、それを測れる指標に落とし込みます。これにより「以前より良くなったか」を同じ基準で判断できるようになるでしょう。ソフトウェア開発でいうテスト駆動開発（TDD）に近く、先に基準を置くことこそが改善の方向を定めるポイントです。
なぜ今、評価が重要なのか
Claude CodeやCodexといったコーディングエージェントの普及で、AIに任せられる範囲は広がりました。一方で出力を毎回手直しする「AI導入の踊り場」に留まるケースも増えています。評価で品質を測れるようにすれば、改善を回すループを組め、条件が整えばAIに自律的に品質を高めさせることも視野に入るでしょう。この記事では、その具体的な作り方を登壇者の実践から追っていきましょう。
登壇者・モデレーター紹介
加賀谷 諒 さん｜Asterminds株式会社 共同創業者・CTO：@ry0_kaga
大手ポータルサイトにてID連携システムの開発に従事。その後、株式会社ログラスに入社。生成AI/LLMチーム立ち上げ、 新規AIプロダクト開発のリードエンジニアを経験。Vercel AI Acceleratorの採択をきっかけにAsterminds株式会社を共同創業し、AIネイティブなプロダクト開発に挑戦している。
seya さん｜YouTuber・LLMアプリエンジニア：@sekikazu01
NY州立大学Stony Brook Computer Science科卒業。ソフトウェアエンジニアとしてのキャリアを経て、GPT-4のリリースを機に株式会社Gaudiyにて生成AIチームを立ち上げ、LLMアプリケーションエンジニアに転身。LLMを活用したアプリケーションの開発・運用に従事。現在は生成AI活用の普及のため、書籍・記事執筆やYouTubeチャンネル「AIでサボろうチャンネル」を起点としたメディア運営の自動化など、多角的な活動を展開している。
浜下 智美｜株式会社サーキュレーション FLEXY4部 FLEXYtoCチーム マネジャー
新卒で人材会社に入社し、派遣営業を経験。その後、より若年層へのキャリア教育に関心を持ち、通信制高校で国語教員として従事。多様な価値観に触れる中で「人の働く時間を豊かにするには、経営に近い視点からアプローチしたい」と考え、サーキュレーションに入社。現在はFLEXYにて、ITフリーランス人材のキャリア支援を担当し、累計270名以上のプロ人材のキャリアインタビューおよび案件紹介に携わる。職務経歴書のブラッシュアップ支援など、キャリアアップに直結する実務的なサポートも多数行っている。
感覚的な改善と「本当の改善」の違い
スキルやAIツールを使う中で「この修正は本当に改善できているのか」と感じる場面は多くの人にあるものです。まず両氏が、その手応えのなさの正体から語りました。
「なんとなく良くなった気」が生まれる理由
seya氏：
スキルは繰り返し使うものなので、後日使ったときに微妙だと感じたら、その場でフィードバックしてAIに改善してもらうことがあります。ただ、その場ではテストできていないというか、前まではどうだったのか、修正後に改めて実行したらどうなるのかを検証しないまま、うまくいっているだろうという感覚で進めてしまう。本当に改善できているのかは分からないけれど、ちょっと進んでいる、という感じでやっていたりします。
加賀谷氏：
スキルやAIツールに限らず、もっと原始的なプロンプトの時代から、どこの何がどう効いてこうなったのかは結構ブラックボックスでした。ふわっとした中でやっていたと思います。それはスキルでも似た状況です。普段やっているプログラミングやソフトウェア開発と比べると、直接的な因果関係が分かりづらい。実際、私が作ったスキルをseyaさんに渡すと、改善しづらいと言われたこともあります。私の思想が前面に入っていて、私がいいと思ったものを詰め込んでいるので、それがはまらないこともある。
「何を守りたいか」を言語化する
seya氏：
しっかり改善していきたいと感じたものに対しては、ちゃんと評価基準を持つようにします。何を守りたいか、このスキルで何を達成したくて何を実現したいのかを言語化する。その場で一回やってみたらうまくいった、で終わらせるのではなく、以前と同じ基準で以前より良くなったかを客観的に判断できるようにする。そこが感覚的な改善と本当の改善の違いになってきます。
加賀谷氏：
AIの出力は確率論的だとよく言われますが、自分の欲しい出力やそのときの要求によって、何が良いかは本来変わるはずです。だからこそ、何が良いかの目安、ここに向かっていると分かる物差しを持っておかないと、そもそも改善に向かっているかどうかも分からない。測れるからこそ改善できるという話です。
使う人の視点で考える習慣が身につく
加賀谷氏：
最近よくやるのは、その出力を誰がどういう場面で見て何をしたいのかを考えることです。たとえばセールス系のプロダクトなら、営業の人がどういうときに見て何をしたいから、こういう出力じゃないと駄目だよねと考える機会が増えました。これは評価の本質に通じます。TDDでテストを先に書くと使う側の期待を持ってコードを書くから設計も良くなる、という話がありますが、評価もそれに近いです。誰かの視点でこういう出力なら使いやすいと考え、どの観点に落とせるかを言語化し、測れるようにして近づけていく。そういう作業をよくやるようになりました。
seya氏：
長期でちゃんとワークさせたいスキルに向き合うときに、しっかり品質を満たしたい、その品質とは何かを言語化するところに強制的に向き合わされる感覚があります。AIに向き合わされているというか、そこはポジティブな変化かなと思います。
AIエンジニアリングにおける「評価」の正体
評価という言葉は広い概念ですが、AIエンジニアリングの文脈での評価には共通する骨格があります。定量指標を用意し、改善ループを回せる状態を作る考え方です。
計測できる状態と改善ループを作る
seya氏：
評価で何が大事かというと、何を満たしたらいいのか、できれば定量的な指標を用意して測れるようにすることです。そのうえで、実際のプロダクトの中で回していく中で、前より良くなっているか、スコアが微妙だったときは何が原因かを分析できる状態にする。データを溜めて結果を見て改善し、また評価するループを作る。シンプルに言えば、ちゃんと計測できるようにして、改善できる状態を作りましょう、というのが基本的なところです。
加賀谷氏：
プロダクト開発では、テスト駆動開発をもじって評価駆動開発と呼ばれるように、AIを使う上では評価を考えるところから始まる側面があります。一度作ってみると、ビジネスサイドの方でも評価に近い活動を何となくやっていたりする。それくらい切り離せない、大事なものだと最近改めて感じています。
共通する評価観点と、文脈固有の観点
seya氏：
チャットボットの評価なら、アプリケーション固有の観点もありつつ、どのチャットボットでも守るよね、という観点があります。正確性やファクトに基づいているか、暴力的なことを言わないかなどといったお決まりの観点です。自分の文脈固有で言語化しなければいけない部分は絶対にありますが、他の人がこう評価しているから学べる、という共通の観点もあります。
加賀谷氏：
よくある指標がある中で、このチャットボットならこの指標のほうが重要だよね、と決める概念があります。エンタメに使われる例なら、間違いを少なくするより刺激的な文章のほうがいい、となれば近い指標を選ぶ。さらに上段の、ドメイン固有の目標を定性的に作り、そこから測りやすい指標にブレークダウンすることもあります。
まずは「出してはいけないもの」をはじく
加賀谷氏：
実務的には、明らかに駄目なものをはじくところから始めるケースもあります。120点かどうかは知らないけれど、出しちゃ駄目なラインははじけるようにする。プロダクト開発ではそのほうがリリースの判断もしやすい。個人のスキルだとなかなかそこまでやるやり方はないですが。
スキルを育てる評価の実践と自動改善ループ
ここからは、両氏が実際に使う開発スキルを題材に、何を評価し、どう自動改善につなげているかを具体的に掘り下げます。評価がスキル運用のどこで活きるかについて伺いました。
開発スキルで見ている3つの評価
seya氏：
スキルには色々な粒度があり、全部に厳密な基準は要りません。長期で育てたいものに絞ります。私たちの開発スキルは、仕様を入力すると実行され、人間がレビューし、その結果から学習して改善に反映する流れです。見ているのは大きく3つで、最終的に満たしたいのがアウトカム評価、つまり人間の手直しなくAIエージェントが動いてくれること。それを満たすために必要なのがアウトプット評価、成果物の品質が求める観点を満たしているか。さらにブラッシュアップしたいときに要るのがプロセス評価で、検証やLint・テストをちゃんと回してくれたかを追えるようにしておく。それぞれ役割が違います。
加賀谷氏：
アウトプット評価はチェックリストに近くて、これはこうしてほしいという項目が全部できているかを判断するイメージです。プルリクの説明やテスト結果、スクリーンショットが所定の形式で貼られているか、はその場で評価できる。一方でアウトカムは、人間が何もレビューコメントも修正もなしですぐマージできたら、AIが作ったプルリクと言えます。だから人間があとで修正した回数や率で見ると、外していない評価になります。自動マージ率やバグ率もそうです。
指標には時間軸がある
加賀谷氏：
アウトプット評価はその場で見て分かるので即効性があります。一方でアウトカムは変数が色々あって、スキルを変えたからすぐ改善したかは分かりづらい。たとえばAIが入れたコードがマージされて10日後・20日後にどれだけ残っているか、すぐ修正されていたらその修正は効果的じゃなかった、という見方もある。これは20日後じゃないと分からないので即効性はない。1番重要だけど時間がかかるので定点観測する指標です。だから最低限のハードルとして日々気にするのはアウトプットのほうですね。
seya氏：
定量的に表せるものとしては、プルリクエストの手直しがどれだけ少なかったか、なんなら手直しなしでマージできたか、マージまでの時間、レビュー負荷などで見ます。それだけでなく、定義した各ステップを実行してくれたか、検証やテストを回してくれたかもログに残してトラックできるようにしておく。雑にまとめると、ちゃんと計測できる形にして、良くなったか悪くなったかを見られるようにすることです。
自動改善ループの仕組みと第一歩
seya氏：
仕組み自体はシンプルで、スキルを使った結果を集めて評価します。開発スキルなら、人間がどれだけ手直ししたかや追加コミットの量が行動から自動で分かる。悪くなったときは、その結果をAIに読み取ってもらい原因を分析させ、スキルを改善してもらう。そのうえで再度動かし、指標が良くなったかを見る。加えて、今まで良かったケースを同じ入力で回して悪化していないか、というリグレッション確認もします。人間の手を介さずAIが取得できる範囲は取得して、自動で改善するループを作るイメージです。
加賀谷氏：
根本で参考にしているのは、AとBがあったときにどちらが優れているかを自動で判断できる状態を作ることです。それができれば、ぐるぐる繰り返して改善を回せる。結果の良し悪しを自動で判断できるかを先に考え、できるならオートモードで回し続けても一定の改善はできます。始め方としては、結局ログや失敗履歴を集めるのが1番分かりやすい。毎日生データを、あるいは1週間に1回見るのが1番効く、などの類の話は本質に近いと思います。なんでこうなったのかを探すと見えてくるものがあります。
seya氏：
最初のステップとしては、とりあえずログが取れている状態にするのが1番大事です。GitHubのプルリクエストは何もしなくても残りますが、それとは別にエージェントの実行ログ、どれくらいのステップ数で実行し過程で何をやっていたかを取れるサービスも使っています。ログがあれば、あとで評価したくなったときに過去のデータをすぐ参照できる。あわせて、達成したいことを測れる形で言語化し、確認用のサンプルタスクを少し用意しておく。ミニマムにはそこから始められます。
関連記事：Claude Codeをエンジニアが使いこなせば業務効率アップ！活用法の具体例も併せて紹介
評価の仕組みがチームの資産になる
seya氏：
評価の仕組みを持つと、AIのスキルをチームの共有資産として育てられるのが大きな側面です。冒頭で、私は加賀谷氏が作ったスキルが何を守っているのか分からず、いじれなかった話をしました。評価観点は何を守りたいかが言語化されたものなので、それがあると他の人も、こういうのを満たしたいんだなと分かる状態にできる。だからスキルをチームの共有資産にできます。
加賀谷氏：
1年前にLLMを使った機能を作って、モデルが新しくなってアップデートしたら出力が大きく変わって大変だったことが実際にありました。そのとき、そもそも揃えなきゃいけないのか、モデル性能が上がって実はこっちが正しいんじゃないか、と議論に時間がかかった。評価の仕組みがあれば、このラインはクリアしましょうと決めておいて、それを基に判断できた。評価の概念がないまま作って忘れ去られた機能だったので、何が正しいんだっけと判断に時間がかかった。そういうのを防ぐための分かりやすい例です。
Q&Aセッション
Q.スキルが各個人で乱立して収拾がつきません。運用ルールは定めていますか？
加賀谷氏：
個人が使いたいスキルは好きにしてください、という考えなのでそこは気にしていません。一方で組織として品質やプロセスを担保するために使うスキルは、勝手に類似スキルを生やすより、そのスキル自体を改善してコミットしてください、としています。スキル同士の連携は、増えるとカオスになるので、最近は結合や役割分担・責務を分けつつ、依存関係がどうなっているかをAIにまとめさせて見たりしています。明らかに一緒のものはまとめる。システムのディレクトリ設計と同じことを考える未来が来ると思います。
seya氏：
乱立で困るのは、似たようなことをやるときに人によって使うスキルが違って品質のぶれが出るところだと思います。なので、この開発プロセスで守りたい品質はこれ、などといったチーム共通の認識が作れると良いんじゃないかと思います。
Q.いい状態の定義や評価基準はどう標準化し、判断のぶれにどう対策していますか？
加賀谷氏：
私は駄目だった例を収集するようにしています。明らかに微妙だったものやフィードバックをもらったら残しておき、何で駄目だったのかをセットにして溜める。抽象化するとこういうことか、と見えてきます。判断のぶれについては、判断する人を1人に決めてしまうケースもあります。属人性は残りますが、その人の中の判断は変わらない。もう1つは、評価の判断自体をAIにやらせて、そのぶれが起こっていないかを評価する、評価の評価をするパターンもあります。
seya氏：
理想は、満たしたいアウトカムが定義されていて指標が綺麗に紐づく状態ですが、基準は最初から全部見えるわけではありません。失敗例を見ていく中で、こういう観点が大事なんだと気づいて基準が増えていく。実態としては、「テストを必ずパスする」のような、誰が見ても判断がぶれない基準をまず作り、そこから積み上げていくこともあります。
判断がぶれようがないところから作って落としていくこともあります。
Q.評価の観点をスキルに取り入れる第一歩は何から始めればいいですか？
seya氏：
まずログが取れている状態にするのが1番大事です。取れていない情報があれば、とりあえずログを取ってみる。次に、そのスキルで達成したいことを測れる形で言語化する。さらにサンプルタスクを整備して、再実行したときに悪くなっていないかを確認できる状態にしておく。何十件も用意するのは大変なので、スプレッドシートやテキストファイルをいくつか並べたフォルダくらいのレベルで十分です。ログを取る、評価できるようにする、ちょっとしたデータを用意する、この3つからミニマムに始められます。
加賀谷氏：
どれから始めてもいいと思います。ログから始めたパターンも、アウトカムを自然言語で書いてLLMに判断させるところから始めたパターンもある。1番効くのは、やはりログや失敗履歴を集めることです。出てきたものを見て、思っていたのと違うとなったら、どこで方向性が間違ったのかをたどっていくと見えてくるものがあります。
まとめ
本ウェビナーは、AIの出力を「なんとなく良くなった気」で手直しし続ける状態から、評価によって改善を科学する道筋を、両氏の実践から具体的に描き出す時間でした。アウトカム・アウトプット・プロセスという3層の評価、ログを取ることから始める第一歩、そして評価の仕組みがチームの共有資産になるといった視点は、明日からの運用にそのまま活かせる論点です。
seya氏：
自動改善ループで自律性を高めたいとき、AIに何を達成してほしいのかを人間が言語化せざるを得ません。何が大事かをAIと一緒に擦り合わせ、より品質に向き合っていく感覚になると思います。
加賀谷氏：
人間は8時間しか働かないので、AIがあるなら寝ている間に動いてくれたらいい。そう考えると便利な仕組みが作れます。自動改善ループはその1つで、そこで評価の考え方が参考になります。
まずは自分のスキルのログを取り、何を守りたいかを言語化するところから、評価の第一歩を踏み出してみてはいかがでしょうか。
編集者からの一言
「評価」と聞くと難しく身構えがちですが、駄目だった例を残す・ログを取るなど、素朴な一歩から始められると知れたのが収穫でした。感覚に頼らない改善の型を、まず1つのスキルから試してみたいと思います。
案件探しの悩み交渉の不安、専任エージェントが全てサポート
今すぐ無料キャリア相談を申し込むAI出力の評価に関するFAQ
本レポートで扱ったAI出力の評価について、よくある質問をまとめました。
Q:AI出力の評価とは何ですか？
A:生成AIやLLMが返す出力の良し悪しを、感覚ではなく客観的な基準や指標で測れるようにする取り組みです。何を達成したいかを言語化し、測定できる形にすることで、改善が本当に進んでいるかを判断できるようになります。
Q:AI出力の評価は何から始めればよいですか？
A:まずはログが取れている状態にすることが第一歩です。あわせて、スキルで達成したいことを測れる形で言語化し、再実行時に悪化していないかを確認するためのサンプルタスクを少数用意すると、ミニマムに改善ループを始められます。
Q:自動改善ループとはどのような仕組みですか？
A:スキルを使った結果を集めて評価し、悪化した原因をAIに分析させてスキルを改善し、再度動かして指標が良くなったかを確認する流れです。結果の良し悪しを自動で判断できる状態を作ることができれば、改善を継続的に回せます。
関連リンク
- イベントレポート一覧：FLEXYイベントのレポート記事一覧
- AIエンジニア向けの案件を探す：AIエンジニア/PMのフリーランス案件一覧（FLEXY）
