AIが良い解を出したとき、何を良いとする評価を誰が決めるか

AIが「良い解」を出してきた、と報告が来ます。

画面には候補が並び、スコアが上がり、以前より速い、安い、短い、と並びます。 会議では「これで行きましょう」が早くなります。

そのとき、いちばん危ないのは、解の中身そのものではありません。

何を良いとする評価を、誰が決めたかが、まだ社内に無いことです。

発見エンジンは、評価の設計が薄いほど、速く動きます。 速く動くほど、「良い」の定義が外から運ばれてきます。

本稿の主張は一文です。

探索・最適化AIを入れる前に、何を良いとする評価関数と、その責任者を先に決める。発見より先に評価の設計。

現場で起きる、良い解の迷子

物流のルート案、在庫の割り当て、計算手順の短縮、社内ツールの処理順。 どれも「最適化したい」と言いやすいテーマです。

現場では、だいたい次の順で進みます。

1. いまのやり方が遅い、と誰かが言う
2. AIなら候補をたくさん出せる、と聞く
3. デモでスコアが上がる
4. 「良い解が出た」で採用会議が始まる

ここで止まるべき問いが、後回しになります。

• 速さは、誰の待ち時間を減らしたのか
• 安さは、どのコストを削り、どこに負荷を移したのか
• 短いコードは、誰が保守する前提なのか
• スコアの分子と分母は、自社の言葉で説明できるか

説明できないまま採用すると、あとからこうなります。

「良い解だったのに、現場が使わない。」 「使ったら、別の部署が困った。」 「改善したはずなのに、確認の仕事が増えた。」

これはAIが弱いからではありません。 良いの定義が、現場の責任の外にあったからです。

システムを作る前に決めるべきことと同じ構造です。 作る前に決めるものが薄いと、成果物が増えても判断は増えません。

発見エンジンが先に動くと、何が起きるか

2026年7月9日、Google Cloudは AlphaEvolve を Gemini Enterprise Agent Platform 上で一般提供（GA）した、と発表しています。 発表では、アルゴリズムの探索や最適化を助ける発見エンジンとして紹介されています。 ベースとなるプログラムと目標を渡し、より良い候補を探索する、という位置づけです。

ここで大事なのは、製品名そのものではありません。

探索のループは、評価が無いと回りません。 候補を出す側が強くなっても、何を良いとするかが曖昧なら、強い探索は強い迷子になります。

発表では、早期利用の顧客事例や改善の話も紹介されています。 ただし、顧客や企業側が語る改善率・効果は、企業主張です。 自社の成功定義ではありません。 「発表では〜と紹介されている」までを事実として扱い、数字を自社のKPIに直結させない、という線引きが必要です。

発見エンジンの導入検討で、最初に紙に書くのは次の四つです。

• 何を最大化するのか（速さ、コスト、品質、再現性など）
• 何を犠牲にしてよいか、何は犠牲にしてはいけないか
• 評価の計算式を、誰が更新してよいか
• 「良い」と判定したあと、誰が現場への適用を承認するか

この四つが無い導入は、探索ではなく、評価の外注です。

「良い」は、指標の名前だけでは決まらない

KPIを増やせば安心、という話でもありません。

そのKPI、誰が何のために見ていますか？で書いたように、見る人の役割が無い指標は、会議の飾りになります。 ダッシュボードを先に作る話でも、同じ落とし穴があります。 ダッシュボードを作る前に決めるべきことと同じで、表示より先に、判断の単位が要ります。

探索AIの評価関数は、さらに一段きついです。

なぜなら、AIは評価関数の穴を、真面目に突くからです。

• 処理時間だけを良くすると、確認手順が消える
• コストだけを良くすると、例外対応が人に残る
• 精度だけを良くすると、対象外データが増える
• 通過率だけを良くすると、却下理由が残らない

現場では、これを「ズル」とは呼びません。 評価の設計が、仕事の境界を書いていなかっただけです。

だから、評価関数は数式の前に、責任の文章が要ります。

「この指標が上がっても、次の確認は誰が残すか。」 「この指標が下がっても、止めてよいのは誰か。」

AIと人の責任境界は、責任の置き場から決めるの延長です。 解を出す側が強くなっても、責任の置き場が無いと、良い解は誰のものでもなくなります。

評価関数を先に決める、短い設計

tugiloでは、発見より先に、次の設計を残します。

1. 良いの一文を、現場の言葉で書く

「最適化する」では足りません。 次の形に落とします。

• 何の待ち時間を何分減らすのか
• どのコストを、どの部署の負担に移さないのか
• 失敗したとき、何をもって不合格とするのか

一文で説明できない「良い」は、まだ評価ではありません。 願望です。

2. 評価の責任者を一人にする

委員会の合意だけでは弱いです。 更新権限を持つ人を一人決めます。

候補が増えたとき、評価式をいじれる人が複数いると、良い解の定義が会議ごとに動きます。 動く定義の上では、探索は毎回別ゲームになります。

AIの候補が増えると、誰が決めたかが薄まると同じです。 候補が多いほど、決めた人の名前が薄くなります。 薄くなる前に、評価の主語を固定します。

3. 企業主張と、自社の合格線を分ける

ベンダー資料や顧客事例に出る改善率は、参考情報です。 自社の合格線は、自社の代表タスクで作ります。

• 代表タスクは一つに限る
• 合格の定義と、不合格で止める定義を先に書く
• 機密データは入れない
• 本番適用の承認者を別に置く

この四つが無い「良い解」は、デモの続きです。

4. 運用は、評価の更新ログから始める

評価関数は一度書いて終わりではありません。 現場が変われば、良いの中身も変わります。

だから運用の最初の習慣は、解の量産ではなく、評価の更新ログです。

• いつ
• 誰が
• 何を良いとする一文をどう変えたか
• その変更で、どの負荷がどこへ移ったか

このログが無いと、半年後に「なぜこの解が良いのか」が説明できません。 説明できない解は、引き継げません。

運用の週次では、解の件数より先に、次の一行を確認します。

「今週、評価の一文は変わったか。変わったなら、誰が承認したか。」

解が増えても、評価の主語が動いていなければ、探索は同じ物差しの上にあります。 逆に、解が少なくても、評価の主語が会議ごとに動けば、比較は成立しません。

発見を急がないための、最初の一歩

探索・最適化AIの魅力は、解の候補を増やせることです。 増やせるほど、現場は「選ぶ仕事」に見えます。

でも、選ぶ前に必要なのは、選ぶ物差しです。

物差しが無い会議では、いちばん説得力のある画面が勝ちます。 画面が勝つ会議では、責任は後からついてきます。 後からついた責任は、だいたい現場に落ちます。

だから、導入の初日にやることは、API接続ではありません。

紙に、次の三行だけ書いてください。

1. 何を良いとするか（一文）
2. その一文の責任者（一人）
3. 不合格で止める条件（一文）

この三行が書けないテーマは、まだ発見エンジンの出番ではありません。 先に、評価の設計の出番です。

AIが良い解を出したとき、問うべきは「すごい解か」ではありません。 その良さは、誰の言葉で、誰の責任で決まったかです。

発見は後からでも間に合います。 評価の主語が無い発見は、間に合いません。