この知恵で考えられること
生成AIや大規模言語モデル（LLM）を使った実装が広がる中で、「評価」という行為の位置づけが誤解されていることが多いと感じています。
——設計と実装が溶け合う時代の、新しい品質の作り方
はじめに
生成AIや大規模言語モデル（LLM）を使った実装が広がる中で、「評価」という行為の位置づけが誤解されていることが多いと感じています。
特に、
- まだAIの評価を実際にやったことがない人
- 従来のITのテストと同じものだと思っている人
に向けて、「生成AIにおける評価とは何をしているのか」を言語化してみたいと思います。
1. 生成AIは「実装」の難易度を劇的に下げた
まず大前提として、生成AIの登場によって「動くものを作る」ことのハードルは大きく下がりました。
従来のITシステムで、
「こんにちは」と言われたら「こんにちは」と返す
という仕組みを作ろうとすると、ボタンを作り、条件分岐を書き、ランダム表示のロジックを書き……と、細かい実装が必要でした。
しかし生成AIなら、
「相手が挨拶をしたら、自然な挨拶で返してください」
という人間の言葉で指示できます。
ここが決定的に違います。
プログラミングを「システムが理解できる形式で設計を記述する行為」と定義するならば、生成AIでは人間の自然言語がそのまま実装の媒体になる。
その結果、何が起きるか。
2. 設計と実装の境界が溶ける
従来の開発プロセスは、
- 要件定義
- 設計
- 実装
- テスト
- リリース
というフェーズに分かれていました。
しかし生成AIの場合、
- 「どういう振る舞いをしてほしいか」を言語化すること
- 実際にAIに指示を与えて動かすこと
がほぼ同時に起こります。
つまり、
設計と実装がほぼ同じ行為になっている
という状態です。
そしてここに、「評価」という行為が深く関わってきます。
3. システムは“動いている”ように見えてしまう
従来のITでは、
- エラーが出る
- サーバーが落ちる
- 異常な挙動をする
といった形で「壊れている」ことが可視化されます。
だからテストは主に、
- 想定外入力に耐えられるか
- 同時アクセスに耐えられるか
- 悪意ある操作に耐えられるか
といった「壊れないか」の確認が中心でした。
しかし生成AIでは違います。
AIはたいていの場合、何かしらの出力を返してきます。
エラーにならない。
破綻もしない。
でも——
意図した内容になっているとは限らない。
たとえば、
「挨拶されたら、相手が話したくなる話題を返してください」
というのが本当の目的だったとします。
でも「こんにちは」に対して単に「こんにちは」と返ってきた場合、
システムとしては“正常動作”です。
しかし目的は達成していない。
ここが生成AIにおける評価の本質です。
4. 評価は「意味」を確認する行為になる
生成AIでは、
- 出力が存在するか
- エラーにならないか
ではなく、
- 意図が反映されているか
- 文脈を適切に解釈しているか
- 組織として許容できる振る舞いか
を確認する必要があります。
つまり評価は、
「意味」「程度」「ニュアンス」の確認
になります。
しかもそれは、最終段階だけではありません。
5. 評価はプロジェクトの全工程に入り込む
従来の開発では「テスト」は最後の工程でした。
しかし生成AIでは、
- 設計して
- 出力させて
- 評価して
- 設計を修正する
というループが、プロジェクトの最初から最後まで続きます。
評価は「後工程」ではなく、
能力を積み上げていくための設計プロセスの一部
になります。
6. 条件分岐は“自然言語の中”に埋まっている
従来のシステムでは、条件分岐は明示的でした。
IF お問い合わせが返金に関するものなら
FAQを返す
ELSE
別処理
生成AIでは、これが曖昧になります。
問い合わせ文はテキストの塊であり、
- これは金銭に関わるか？
- これは紛争になりそうか？
- 感情が高ぶっているか？
といった判断は、AIの解釈に委ねられます。
しかし、
それを明示的に設計していなければ、AIは期待通りには動かない。
ここで評価が必要になります。
7. 実例：30件テストして初めて見えること
たとえば、
- ありそうな問い合わせを30件用意する
- 同じプロンプトで一括実行する
- 出力を並べて確認する
すると、
- 通常の挨拶はうまくいっている
- 金銭関連の判定はできている
- しかし感情が高ぶったクレームに弱い
といった傾向が見えます。
そして気づく。
「あ、感情が高ぶっている場合の指示を書いてなかった」
人間は「当然わかるだろう」と思っている部分を、AIは当然わからない。
評価は、自分たちの設計の曖昧さを可視化する行為でもあります。
8. 500件投入して分かる“傾向”
さらに実際の問い合わせ500件を流してみると、
- 検索を間違えやすいケース
- 意図を誤解しやすいケース
- 曖昧な質問に弱いケース
が見えてきます。
そこから、
- 指示を具体化する
- 処理を分ける
- 先に分類AIを入れる
- 危険な場合はオペレーターに回す
といった設計変更が生まれます。
ここで重要なのは、
どの時点でもシステムは「動いている」
しかし能力はまだ設計途中である
ということです。
9. ゲーム開発に近い
このプロセスは、ゲームのバランス調整に近い。
男性キャラを強く設定し、女性キャラも設定し、
いざ遊んでみると男性キャラが強すぎてつまらない。
エラーではない。
でも面白くない。
だから調整する。
生成AIの評価も同じです。
正しく動いているかではなく
望ましい体験になっているか
を確認している。
10. 製造業の試作工程が最も近い
さらに近いのは製造業の試作工程です。
- 素材を作ってみる
- 強度を試す
- 温度変化で試す
- 雨の日も試す
最終検査ではなく、
「意味のある製品として成立するか」を確かめながら作る
工程。
生成AIの評価も同じです。
11. なぜ最初から完璧に設計できないのか
よくある誤解はこれです。
最初から完璧なプロンプトを書けばいいのでは？
無理です。
一度も出力させずに、
あらゆるケースを想定した完璧な指示文を書くことはほぼ不可能です。
しかし、
- 30件出力を見る
- ダメな例を見る
- 会社に詳しい人が「ここはこう言った方がいい」と言語化する
これはできる。
つまり評価は、
頭の中では設計できないことを、現実の出力を見ながら言語化するプロセス
です。
12. AIを「育てる」という感覚
このプロセスは「学習」ではありません。
しかし感覚としては近い。
- 仕事をさせてみる
- 苦手を知る
- 得意を知る
- データ不足に気づく
- マニュアル不足に気づく
そして、
現場で労働させられる水準まで能力を積み上げる
それが生成AIにおける評価です。
結論：評価とは「能力を設計する行為」である
生成AIにおける評価は、
- デバッグでも
- 最終品質チェックでもなく
能力を確からしく積み上げていくための設計行為
です。
動いているかどうかではなく、
- 意図通りか
- 現場で使えるか
- 組織として責任が持てるか
を確認しながら、設計を更新し続ける。
それが生成AI時代の「評価」です。
もし一言でまとめるならこうなります。
生成AIにおける評価とは、
「動作確認」ではなく「能力の彫刻」である。
削り、試し、確かめ、また削る。
それを繰り返すことで、
AIはようやく“実用可能な担当者”になるのです。
参考：AIとの音声対話ログ
生ログ
AIインタビュアー
2026/02/18 20:21
こんにちは！それではインタビューを始めましょう。まず最初にいくつか注意事項があります。話し終えたら必ず終了ボタンを押してください。これは履歴データの保存のために必要です。それから、こちらが話している途中でも、気になることがあれば
senko
2026/02/18 20:22
はい 概要や施行の場の趣旨は 理解を事前にしておりまして 今日話したいことは SAISやLLMを用いた実装における 評価という行為の行きづけが 何なのかというのを 解説したいと思っています で そういうことをしたことがない人とか 逆に言えばちょっと誤解をしている方に対して 伝えるために言語化をしたいです
senko
2026/02/18 20:22
Thank you for watching.
AIインタビュアー
2026/02/18 20:22
なるほど、今日は生成AIや大規模言語モデルを使った実装における「評価」という行為の位置づけについて言語化したいんですね。どんな人に伝えるかというと、まだ評価をやったことがない人や、誤解している人に向けてということですね。それでは、どれくらいの深さで言語化したいか、具体的なレベル感や、特に強調したいポイントがあれば教えてください。また、聞き手にどういうふうに伝わってほしいか、例えば理解してほしいことや行動に移してほしいことがあれば、それも教えてもらえると助かります。
senko
2026/02/18 20:24
大前提として 生成AIに関する処理の構築というものは ITと比べて 動く状態まで実際に作るっていうのは かなりスキルがいらなくなってますと こんにちはっていう挨拶に対して こんにちはって返すシステムを作るにしても 例えば先生を使わない形だったら こんにちはっていうボタンと こんばんはっていうボタンと 今日は何を食べましたかっていうボタンを3つ置いて こんにちはが押されたら こんにちはに返すとか ランダムに20個の挨拶から表示するっていう ウェブシステムを作ってようやっと動くんですけど ことをAI処理に関してだけで言えば 相手が挨拶をしていた場合に 自然な挨拶で返してくださいっていう言葉で 指示ができますと これは結構違いで そのプログラミングという言葉を システムが動くように ちゃんとシステムが分かる言葉で デザインしていく行為と言い換えるならば せいぜいにおけるプログラミングは 人の言葉でプログラミングできていると言えますと そうなってくると いわゆる要件定義や要求定義 どういうふうに何をしてほしいのかっていうのを どんどん正確に言葉にするっていう行為と 実装行為っていうのが 相手においては設計と実装って分かれてるんですけど かなり実装行為が設計行為と近づいてくるというのが まず財源としてはありますね
senko
2026/02/18 20:24
Bye! Thank you. Stay super. Bye! Stay super. Bye! Stay super. Bye!
AIインタビュアー
2026/02/18 20:24
なるほど、確かに生成AIを使うことで、従来のプログラミングで必要だった細かい実装の部分が、人の言葉に近い指示で済むようになっている、ということですね。そうすると、従来のシステム開発の流れで言うところの「設計」と「実装」の境界線が曖昧になってきているというわけですね。
では、そういう状況において「評価」という行為はどう位置づけられるのか、というところを深掘りしていきたいということですね。
一般的には、ソフトウェア開発における評価というのは、要件通りに機能しているかを確認したり、パフォーマンスや品質を測るために行われますが、生成AIの場合は、より「対話の自然さ」や「意図したアウトプットが出ているか」といった、従来より主観的な評価が重要になってくる気がします。
このあたり、誤解されやすい点や、伝えたいポイントはありますか？
senko
2026/02/18 20:26
はい そういう上で システムにおけるテストや品質評価って 比較的反応プロセスのものとして 位置づけられやすいですと で 目の前にある画面で映ってるシステムは 動いているように見えるという上で これは本当に悪意を持ったユーザーが アーケードしても大丈夫なのかとか 一般的には想定もされないような 挙動や操作をした場合に変なことにならないかとか 一気に100人が使っても壊れないかとかっていう より今パッと見た限りでは 想像がつかないリスクを 網羅的に確認をしていくっていうテストが ITにおけるテストとしては言われがちなんですが 正々堂の場合だと そういう最終段階での より存在率が低いようなケースにおける デジタルアクセスとかも もちろん結果はするんですけど そこを閉じるだけではなく かなりプロジェクトの前半でも中盤でも わりと常に評価をする 出力を評価するっていう行為が かなり頻回行われるっていうのがありまして いわばプログラミングというか 設計や実装 設計 実装 テスト リリースというわけでならば 正々堂の場合は設計と実装というプロセスの中に かなり評価や確認するという行為が かなり現れるって感じですかね
AIインタビュアー
2026/02/18 20:26
なるほど、つまり従来のシステム開発では設計、実装、テスト、リリースといったフェーズが比較的明確に分かれているのに対して、生成AIの場合はその区切りが曖昧になり、設計や実装と並行して頻繁に
senko
2026/02/18 20:26
Thank you.
AIインタビュアー
2026/02/18 20:26
評価や確認を行う、いわばフィードバックループが短くなっているということですね。その結果、プロジェクトの初期段階から終盤まで、常に性能評価や品質の確認が求められるようになっているんですね。そういった頻繁な評価が、生成AIならではのプロセス上の特徴というわけですね。
senko
2026/02/18 20:27
なんというか そのエラーが起きず 崩壊しているシステムが動いているかという意味だと
senko
2026/02/18 20:27
内容がどうであれ エラーなくシステムが返ってきてるってことは 今 立現できてしまうんですよね で その上で じゃあ 挨拶されたら 相手が話したくなるような話題を 相手に返事してねっていうのが 本当にやりたいことだったとして で こんにちはって言ったら こんにちはと返した場合に その内容がちゃんと話題が入っているかっていうのも 意外とシステムエラーという形は出ない なので いわゆる意味や内容や程度を 確認するってなってきますと で そういう意味で 意図したものが 意図したように動いているかっていうのを 全てが人の目を使った確認が必要なのかは もちろんあるんですけど 訂正的に確認をするっていう行為が 頻繁に生まれてくるっていうのがまずありますね
AIインタビュアー
2026/02/18 20:27
確かに、生成AIではシステムが動いているかどうかだけではなく、実際の出力内容が意図した通りかどうかが重要になるという点は大きな違いですね。そのため、評価や確認を頻繁に行う必要が出てくると。例えば、挨拶一つにしても、単に「こんにちは」と返すだけではなく、その後の会話が広がるような内容になっているかを確認する必要があるわけですね。その分、評価という行為が設計・実装の段階から組み込まれて、継続的に行われる必要があるということですよね。
senko
2026/02/18 20:33
そうです その上で システムの場合って こういう場合にはこうして欲しいけど こういう場合はこうして欲しくないっていう 条件分岐みたいなものが 明確に組み込まれた イフ分岐とかと言われる処理が 多いと思うんですけど AIの場合は それがごちゃっとしたテキストの意味 内容をもとに分岐をしたりだとか 紛争になりそうとか お金がらめのものだったら 明言しないで欲しいとかってあると思うんですけど それって普通のお問い合わせとかだったら FAQとか引っ張ってきて回答すればいいよねっていうのと 紛争に関する問い合わせだったら 回答しないようにするっていうのも 両方チェックしなきゃいけなくて その中でシステムチェックに確認するっていう難易度が高い なので結構作りながら確認をしながら こういう条件分岐まで明確に明言して 設計としてAIに伝えないと ちゃんと動かないんだねっていうのが分かってくると それはやっぱりAIにおける評価の話なので かなり最終段階の確認というだけではなくて 能力を確からしく積み上げていくための 良い設計を特定するための行為として 出力を評価するっていうのがあります 例えばありそうな問い合わせを30件くらい作って その出力をバーッと同じ処理に対して行って すると見てみると普通の挨拶はいけてるなと お金に関するものかどうかの判定はいけてるなと でたらこれハードクレームみたいなものとして 相手が感情が高ぶってるっていう場合にも 普通に反応しちゃってるなっていう確認が取れます で設計に戻ると確かに別に相手の感情がどうだったら みたいなの指示してなかった けど元々で分かるかなと人間側が思ってただけなんですよね っていうのを確認したり条件をつけたりっていう場合もありますし じゃあメジャーなものとか 昨月実際にあった問い合わせのものを 500個入れてみましたと で見ると意外とうまくやれているケースと うまくやれてないケースが見えてきたりしますと それやっぱり全体の傾向とかを見ながら どういう指示が足りないのかだったり どういう部分をより条件を具体的に指定していないから うまく動いてないんだなっていうのが分かってくると ということはこれ設計に戻るわけですよ どういうものは検索を間違えやすいとか どういうものは糸を組み取り間違えやすい というものを踏まえた処理だとか 逆に言えばそれが複雑すぎる場合であれば 処理を分けたりするんですね 一個のAI処理にせずに特に間違えやすい場合に 該当しそうだなっていうものかどうかを判定するAI処理を入れると その判定結果が大丈夫なものであれば ものを作った処理を動かす 大丈夫じゃないとされれば テンプレートでいただいたお問い合わせは AI回答が難しいためオペレーターにつなぎます っていう分岐を作ったりしながら 最終的な出力をマネジメントしていくっていうのが AIを具体的に実用可能な水準まで育て上げるという行為なんですけど これなんか不思議ですよね どれも毎回実装してるしちゃんと動いてるんだけど 確認や評価を繰り返しながら 具体的にAIなり処理全体が果たす能力をデザインする というのが生成も用いた場合の プログラミングに当たるんですよね なのでデバッグやリリース前の品質評価という形での 新しい評価するとももちろんあるんですけど その手前段階で実際の現場で人間に代わって 労働させる担当者として十分な状態まで いわゆるトレーニングさせてもいいですね 学習という意味ではなくこういうのっていけるのかなっていうので 仕事させてみてダメだダメだっていうのを確認しながら マニュアルを準備しなきゃなっていうのもあると思うんですけど あれがちょっとイメージに近いので 本番に出す前にいろんな経験をさせてみて 苦手や得意や曖昧でもいいところや 細かくやるとダメなところを理解しながらやっていくとか 単純にごめん うちが提供したデータが足りなかったとか マニュアル処理足りなかったわってことにも 気づきながら育てていくっていう そんなプロセスが評価しながら 具体的に育てていくっていうプロセスですね
AIインタビュアー
2026/02/18 20:33
おっしゃる通りですね。システム的には動いているように見えても、本当に意図した応答をしているかどうかを確認するためには、単なる動作テスト以上の評価が必要になるわけですね。その過程で、「あ、ここはもっと明確に指示しないとダメだな」とか、「この部分はAIには難しいからテンプレートを用意しよう」といった気づきが出てくるわけですね。最終的には、そうやって実際の運用環境に近い形で何度も試しながら、AIを「育てていく」というイメージに近いプロセスが、生成AIを使う上での評価の重要な役割ということですね。非常に明確になってきましたが、ここまでの話で特に強調したいポイントや、もう少し深掘りしたい部分はありますか？
senko
2026/02/18 20:37
わかりやすいモチーフで言えば、ゲーム開発におけるテストやデバッグって 比較的楽しくゲームができるようにはなったっぽいんだけど ゲームマップのあらゆるところを冒険してもらって 本当に変な場所がないかとか、謎のコマンドを入れるとか 変なことが起きていないかっていうのがあったりするんですけど 生成AIに置き換えるならば、男性のキャラの強さを設定して 女性のキャラの強さを設定してみて、楽しく戦えるかなと思ったら 意外とゲームをプレイしてみたら、男性キャラが強すぎて 全然遊びごたえがないので、面白さが成立しないので これじゃ売れないよねって判断をして 強さの改善とか調整をすると思うんですけど ああいうような確認の方がちょっと近いですね 最終的にはそういう質的評価とも言えるんですけど 実際に実装するという行為が難しいわけではないんですよね ただ何も出力を一回もさせずに 全ての場合に対応できる指示文を あなたは言葉にしてくださいと言ったら難しすぎるんですよね でも30個出力出してみて、うまくいってもうまくいってないものが出ましたと じゃあこのAIにはもっとどういう風に どんな言葉で依頼した方がうまくいくと思いますか っていうのは意外と現場だったり会社に詳しい人からすると 言葉にできると そういうものをどんどん具体的に見つけていくというプロセスはできるけど 頭の中で全てのパターンを考慮した言語化はできない かつそれが意外と別に社内でやるマニュアルが それとして機能するようなことの水準で 超言葉になっているとか判断のフロー分岐とかが めくくなっているかというと意外とそうではなくて みんな結構柔軟にいろいろやれてしまったりするので 人間のために整理されているドキュメントをもとに AIを作ってみても意外と全体のケースには 対応できないことも多いというのもあって ちゃんとやってみて評価をしてみてというのが大事って感じですね
AIインタビュアー
2026/02/18 20:37
おっしゃる通りですね。なるほど、ゲーム開発におけるデバッグやバランス調整にとても近いイメージですね。紙の上で考えた仕様が、いざ動かしてみると思わぬ結果を生むことが多く、それを実際にテストしながらフィードバックを得て改善していく。その過程で初めて、現実的に使えるAIの挙動や性能を見極めていくわけですね。
つまり、最初から完璧な「指示文」や「設計」を用意することはほぼ不可能で、実装と評価を繰り返すことで、徐々に適切な条件や指示を明確化していくプロセスが重要になる、というお話ですね。
そして、そのプロセスがまさにAIを「現場で役立つレベル」まで育て上げる作業そのものだという点が、従来のシステム開発とは一線を画する部分になっているんですね。
では、そうした評価プロセスを知らない人や誤解している人に向けて、どんな例やポイントを押さえて伝えるのが効果的だと思いますか？
senko
2026/02/18 20:38
なんかゲームの例以外にも対比構造の形で分かりやすい例とかってあなたは思い浮かびますか
AIインタビュアー
2026/02/18 20:38
そうですね、もう一つわかりやすい対比として、料理のレシピ作りを考えてみましょう。従来のシステム開発は、たとえばレシピ本のように、材料や手順を細かく決めておいて、その通りに料理を作るような感じです。作り方がはっきりしているので、その通りに作れば基本的には期待通りの味が出ます。
一方、生成AIを使う場面は「シェフにこんな感じの料理を作って」と口頭でお願いしているようなものです。材料や作り方がはっきり決まっているわけではなく、完成した料理が美味しいかどうかは、何度も試食して確認しながら微調整するイメージです。
たとえば、最初は「ちょっと塩味が足りないな」と感じたら、次は塩を足してみる。そのうえで、もう一度味見して「今度はちょっと塩辛すぎるかな」と微調整を繰り返し、最終的にちょうど良いバランスになるまで試行錯誤する。これが生成AIにおける評価と調整のイメージに近いです。
つまり、従来のシステム開発が「レシピ通りに作る」ことで安定した品質を保証するのに対し、生成AIは「実際に作って味見を繰り返し、その都度レシピを調整していく」プロセスが必要だということですね。
senko
2026/02/18 20:38
ほかには
AIインタビュアー
2026/02/18 20:38
もう一つわかりやすい例として、カスタマーサポートを考えてみましょう。従来のカスタマーサポートでは、よくある問い合わせに対するFAQを用意して、オペレーターがそれに基づいて案内することが一般的です。一方、生成AIを使う場合、FAQに書かれていないような微妙な質問にも対応しなければならないことがあります。
ここでも、単にAIが回答を返せるかどうかだけではなく、その回答が誤解を生まないか、顧客が満足する内容になっているかを評価することが重要です。たとえば、「返金ポリシーを教えてください」という質問に対して、AIはきちんと会社のポリシーに沿った回答をする必要があります。しかし、その回答があまりに機械的すぎると、顧客の不満につながるかもしれません。
senko
2026/02/18 20:39
料理の場合もカスタマーサポートの場合は あんまり芯を食ってない気がするので やはり何か確認や評価という単語と 結びつきやすい一般例と違いを表したりする
AIインタビュアー
2026/02/18 20:39
わかりました。では、製造業の品質管理を例にして考えてみましょう。
たとえば工場で製品を作る場合、最終的な製品をチェックして問題がないかを確認する「最終検査」は一般的です。でも、生成AIの場合で言う「評価」は、それに加えて製造プロセスのあらゆる段階で、こまめに品質を確かめるようなイメージです。
たとえば部品を作る段階で、形やサイズが正確かどうかを頻繁にチェックするのに似ています。もしズレがあれば、その場で設計や工程を調整していく。このように、最終製品ができる前に、都度都度細かい評価を重ねて、理想の仕上がりに近づけていくわけです。
従来のシステム開発では、完成したものがしっかり動くか最終確認をするのがメインですが、生成AIでは、最終確認に至るまでに何度も評価を繰り返して、望む結果が出るように育てていく、そういう感じですね。
この比較で考えると、「評価」とは単なる動作チェックではなく、理想の結果を得るために何度も試行錯誤して調整するプロセスだということがイメージしやすいかもしれません。
senko
2026/02/18 20:41
で 製造業の例が分かりやすいかもですね その最終検査以外にも 部品単位でもチェックはもちろんあるし なんだろうと どうやったらこういう動きをする その素材が作れるのかとか こういう質感のある素材が作れるのか 分からない段階もあると思うんで あの時ってすごいたくさんやってみて 確認してっていうのをやったりとか ある程度できてきたけど これ雨の日も大丈夫かなとか 晴れの日も 晴れが続きすぎてもいけるのかなっていう 本当のリリース前に行うような 日本の実企画でチェックするというよりは ちゃんと意味を成してる形に 自社として見つめる形に まず作り上げていくだけの設計って かなり作ってみて確認してってことを 行うと思うんですけど あれが近いと思いますね
AIインタビュアー
2026/02/18 20:41
おっしゃる通りですね。製造業の例は、生成AIにおける評価プロセスと非常に似ています。製品が完成する前に、まずは素材やパーツ単位で性能や耐久性を試す工程がありますよね。同じように、生成AIも、いきなり最終的なリリースに至る前に、部分ごとに出力を確認し、少しずつ改良を重ねていくイメージです。
例えば、新しい素材を使って新製品を作るとき、最初は「この素材は丈夫だろう」と推測するだけでは不十分ですよね。実際に試作品を作り、曲げてみたり、引っ張ってみたり、極端な温度にさらしてみたりしながら、期待通りの性能が発揮できるか確認します。これが製造業でいうところの「試験工程」や「品質チェック」にあたる部分です。
生成AIも同じように、「このプロンプトならうまく応答できるだろう」という仮説を立てたら、実際にいくつか入力を試してみて、どのような出力が得られるか確認します。そして、その結果をもとに、「ここはもう少しこう指示した方がいいな」とか「このパターンでは思った通りの結果が出ないな」といった調整を重ねていくわけです。
最終的には全体の品質基準をクリアするまで繰り返しチェックを行い、問題がなくなったらリリースする。そういう意味では、生成AIの評価プロセスは、まさに製造業の製品開発と似た段階的なアプローチと言えるかもしれません。