Galileoで評価基準を決める項目一覧｜合格線は人が書く

「評価の基盤を入れれば、エージェントの品質は数字で保証できるはずだ」「既成の評価項目がこれだけそろっているなら、自分たちで基準を考える必要はないのでは」——AIエージェントを業務に出そうとしている情報システム部門やAI導入の担当者から、こうした期待をよく耳にします。けれども、採点の仕組みがどれだけ精巧でも、何をもって合格とするかは、業務を知っている人が言葉で書かない限り、どこにも存在しません。評価の基盤は、書かれた基準を速く大量に当てはめる道具であって、基準そのものを決めてくれるわけではないのです。この記事では、AIとエージェントの評価・監視の基盤である Galileo を例に、社内に入れる前に決めておく項目を一覧の形で整理します。

Galileo は、AIとエージェントの答えを採点し、本番で見張る基盤

Galileo は、生成AIのアプリやAIエージェントについて、評価・観測・本番での防御の三つをまとめて扱う基盤です。公式サイトでは、開発中のデータや本番の記録、合成したデータから評価用のデータを作り、業務の専門家が正解の印を付け、それに対して評価項目で採点していく流れが説明されています。社内文書を引いて答える仕組み（RAG）やエージェント、安全面・セキュリティ面について、20を超える既成の評価項目を用意し、自社用の評価項目も作れるとしています。

観測の側では、エージェントの一連の動きを記録し、どこで失敗したかを分析する機能があります。公式サイトの例では、作り話の答えの原因を「道具に渡した入力の誤り」までたどり、例示を足すといった直し方を提案する流れが示されています。さらに、評価をそのまま本番に置き、点数に応じてエージェントの動作や道具の使用、人への引き継ぎを切り替える防御の仕組みとしても使えると説明されています。

提供の形は、事業者のクラウドで使う形、自社専用のクラウド環境に置く形、自社の設備に置く形の三つが公式サイトに挙げられています。つまり Galileo は「答えを作るAI」ではなく、答えを作るAIを横から採点し続けるための仕組みです。社内で扱うときも、作る側の道具とは別の、品質管理の道具として位置づけるのが出発点になります。

2026年の動き：シスコによる買収と、評価の調整を人の訂正から行う機能

鮮度を確かめておきます。2026年4月9日、シスコは Galileo の買収の意向を発表しました。スプランクの公式ページでは、買収は完了したとされ、Galileo は「スプランクのエージェント観測（スプランク エージェント オブザーバビリティ）」として位置づけられ、スプランクの観測のクラウドに組み込まれると案内されています。買収完了の日付や、Galileo 単体での販売・既存契約の扱いは、確認した範囲の公式ページには書かれていませんでした。契約前に、今後どの名前・どの契約で提供されるかを営業窓口に確認するのが安全です。

製品の側も動いています。公式ブログによると、2026年4月2日には、採点役のAIの採点を人の訂正から自動で調整する機能を発表しました。2026年5月19日には、Claude Code と Codex に、評価の診断と修正計画づくりの手順を教え込む「評価エンジニア」という技能の束を、初期段階の版として公開しています。翌20日には、小型の評価モデルを自社用に調整する Luna Studio の作り方を解説する記事も出ています。3月11日には、エージェントを横から制御する仕組みを Agent Control という名前でオープンソースとして公開し、同じ日にシスコのAI防御の製品との連携も発表しています。買収の発表より前から、両社の製品は近いところで組み合わされていたことになります。

公式サイトは2026年10月時点でも更新されており、終了や新規受付停止の告知は見当たりません。一方で、買収の直後は製品名や窓口、契約の形が変わりやすい時期です。導入の判断を「機能が足りるか」だけで行わず、提供の主体が変わることを前提に、やめ方まで含めて決めておくことが、この製品では特に大事になります。

「評価の基盤を入れれば品質が決まる」は誤解である理由

評価の基盤を検討するとき、最初に起きやすい誤解は「既成の評価項目を全部オンにすれば、品質が保証される」というものです。既成の評価項目が測っているのは、たとえば「答えが渡した資料に沿っているか」「質問に答えているか」「有害な表現がないか」といった、どの業務にも共通する性質です。自社の業務で何が合格かは、既成の項目のどれにも書かれていません。

Galileo 自身も、この点を隠していません。2026年4月の発表では、汎用の評価の指示文を新しい業務領域に当てると、人の判断と食い違う割合が2割から3割に上るという研究を引いています。採点役のAIが「正しい」と言った答えの中に、業務担当者なら不合格にするものが混ざる、ということです。

ですから、評価の基盤の導入で最初にやる仕事は、設定画面を開くことではなく、業務の担当者が「この答えなら顧客に出してよい」と言える条件を文章にすることです。以下の一覧は、その文章を Galileo の評価項目や運用に落とすまでに決める項目を、順番に並べたものです。項目1から順に埋めていけば、入れるかどうか、どこまで任せるかの判断材料がそろいます。

項目1　業務の合格基準を、評価項目より先に文章で書く

最初に決めるのは、評価の対象にするエージェントの業務と、その業務での合格の条件です。たとえば問い合わせに答えるエージェントなら、「料金と契約条件は公式の料金表に書かれた範囲でしか答えない」「保証できないことは保証しない」「判断に迷ったら担当者に引き継ぐ」といった条件になります。条件は、評価項目の名前ではなく、業務の言葉で書きます。

このとき、合格の条件と同じくらい大事なのが「絶対に出してはいけない答え」の一覧です。値引きの約束、納期の断言、競合製品への断定的な批判、個人情報の読み上げなどです。合格の条件は程度の問題になりやすい一方、出してはいけない答えは一つでも出れば事故になります。この二つを分けて書いておくと、後の工程で「点数で見る項目」と「一件でも出たら止める項目」を分けやすくなります。

書き手は、AIの担当者ではなく、その業務の責任者です。問い合わせなら窓口の責任者、マーケの記事なら編集の責任者です。AIに下書きさせてもかまいませんが、最後に「これが合格の線だ」と署名するのは業務の責任者にします。ここが曖昧なまま評価の基盤を入れると、点数は出るのに、その点数が良いのか悪いのか誰も答えられない状態になります。

項目2　合格基準を評価項目に翻訳する：既成で足りるところ、自作が要るところ

次に、文章で書いた合格基準を、Galileo の評価項目に対応づけます。既成の評価項目で測れるものはそのまま使い、測れないものは自作の評価項目にします。自作の評価項目は、採点役のAIに渡す採点の指示文として書くのが基本の形です。下の表は、問い合わせ用のエージェントを例にした翻訳の一例です。

業務の合格基準（業務の言葉）	評価項目への翻訳	置き方
答えは社内の資料に書いてある範囲に限る	資料に沿っているかを見る既成の項目	点数で傾向を見る
質問に正面から答えている	質問への応答度を見る既成の項目	点数で傾向を見る
料金・契約条件を約束しない	約束表現を見つける自作の項目	一件でも出たら人へ回す
迷ったら担当者に引き継ぐ	引き継ぐべき場面で引き継いだかを見る自作の項目	抜き取りで人が確かめる
個人情報を読み上げない	個人情報の検出の既成の項目	本番で止める候補
敬語と自社の言い回しを守る	表現の型を見る自作の項目	週次で傾向を見る

翻訳でつまずきやすいのは、一つの業務基準を一つの評価項目に無理に押し込むことです。「丁寧で正確で簡潔」のような基準は、採点役のAIにとっても曖昧で、点数がぶれます。一つの評価項目には一つの性質だけを測らせるのが原則です。また、翻訳した評価項目ごとに、業務基準のどの行から来たのかを記録しておくと、後で点数が下がったときに、業務の誰に相談すればよいかがすぐ分かります。

自作の評価項目の指示文を書くときは、業務の担当者が実際に不合格にした答えを一つ、合格にした答えを一つ、理由と一緒に添えると採点が安定します。点数の段階も、細かくしすぎないほうが扱いやすくなります。十段階で採点させると、6点と7点の違いを誰も説明できません。合格・要確認・不合格の三段階で返させ、それぞれの理由を一文で書かせる形にしておくと、人が抜き取りで読むときの手がかりにもなります。

項目3　採点役のAIに任せる範囲と、人が見る範囲を分ける

Galileo の評価項目の多くは、大きな言語モデルに採点させる方式（AIによる採点）か、それを小型化したモデルで動きます。採点役もAIである以上、間違えます。そこで、評価項目ごとに「採点役のAIの点数だけで済ませるもの」と「人が確かめるもの」を分けておきます。

目安は、間違えたときの損害の大きさです。表現の型や応答の長さのように、外れても後で直せるものは採点役のAIに任せます。料金・契約・法令・個人情報に関わるものは、採点役のAIが合格と言っても、一定の割合を人が抜き取りで読むことにします。逆に、採点役のAIが不合格と言ったものは、人が全件を見て、採点の誤りなのか答えの誤りなのかを判定します。

• 既成の評価項目の点数が高いので、人の抜き取りをやめた
• 採点役のAIに「合格か不合格か」だけを返させ、理由を残させていない
• 評価項目の閾値を、業務の責任者に相談せずに開発者が変えた
• 点数の平均だけを見て、一件でも出てはいけない答えの件数を見ていない

もう一つ決めておくのが、採点役のAIに点数の根拠を書かせることです。点数だけでは、人が抜き取りで読むときに、どこを疑えばよいかが分かりません。根拠の文が残っていれば、採点が業務の基準とずれているのか、答えそのものが悪いのかを、短い時間で切り分けられます。

項目4　採点のずれを、業務の担当者の訂正で詰める

採点役のAIの採点を業務の基準に近づける仕組みとして、Galileo は2026年4月に自動調整の機能を発表しました。公式ブログの説明では、業務の担当者が記録の上で「本来はこの点数であるべき」と入力し、その理由を普通の文章で書きます。集まった訂正をもとに、採点の指示文の基準や採点の条件が書き直され、チームが書き直しの差分を確かめ、試験用のデータで動かしてから公開する、という流れです。

公式ブログでは、社内の試験で5件の訂正で大きく改善し、それ以上増やしても差は小さかったと報告しています。ただし、これは事業者自身が選んだデータでの試験結果で、第三者の検証ではありません。自社の業務でも同じように効くかは、訂正の前後で、人が付けた正解との一致の度合いを測って確かめる必要があります。

運用で決めておくのは、訂正を入れてよい人と、書き直しを公開してよい人です。公式の説明では、複数の人の訂正はいったん順番待ちの列に入り、管理者が採否を決めてから調整が走る形になっています。訂正を入れる人は業務の担当者、公開を決める人は業務の責任者と分けておくと、採点の基準が担当者ごとにずれていくのを防げます。訂正の理由の文は、そのまま合格基準の改訂履歴としても使えます。

項目5　小型評価モデル Luna で全件を見るか、抜き取りで見るか

大きな言語モデルに採点させる方式は、精度は出しやすいものの、全件に当てると費用と待ち時間がかさみます。Galileo の Luna は、この採点役を小型のモデルに移したものです。公式サイトは、大きなモデルによる採点を小型モデルに蒸留し、通信の全件を見張れるようにしたと説明し、費用を大きく下げられるとしています。現行の世代は Luna-2 で、2025年6月に発表されました。

ここでの判断は、全件を見る必要が本当にあるかどうかです。本番で一件でも出てはいけない答えを止めたいなら、全件を即座に採点できる小型モデルが向きます。週に一度、品質の傾向を見るだけなら、抜き取りを大きなモデルで採点するほうが安く済む場合もあります。公式文書では、Luna-2 や、自社用に調整する Luna Studio は上位の契約で提供され、Luna Studio は利用企業の環境に置く形と案内されています。契約の段階によって使える範囲が変わるため、見積もりの前に確かめておきます。

小型モデルを自社用に調整するには、正解の印を付けたデータが要ります。公式文書の旧版では、自社の用途に合わせるのに数千件規模のデータが典型だと書かれていました。つまり、小型モデルの精度は、業務の担当者が正解を付けた量に左右されるということです。全件監視に進む前に、正解付けの手間を誰が負うかを決めておきます。

項目6　点数を本番の止め役に使うかどうか

Galileo は、評価を本番に置き、点数に応じてエージェントの動作や道具の使用、人への引き継ぎを切り替えられると説明しています。便利な一方で、ここは慎重に線を引くところです。点数で自動的に止める対象は、「一件でも出たら困る答え」に限るのが現実的です。

理由は、点数による停止には必ず誤りが混ざるからです。正しい答えを止めてしまえば、顧客は待たされ、担当者に余計な引き継ぎが発生します。間違った答えを通してしまえば事故になります。止める対象を広げるほど、前者の誤りが増え、現場は止め役を外したくなります。そこで、個人情報の読み上げや、料金の約束のように、止めたときの損より通したときの損が明らかに大きいものから始めます。

止めた後の流れも決めておきます。止めた答えを顧客に何と伝えるか、誰に引き継ぐか、止めた記録を誰がいつ読むか、です。止める判断はAIの点数で行っても、止めた答えを再び出すかどうかの判断は人が行う、という線をここで明文化しておきます。

項目7　何が社外に出るか：事業者のクラウド・自社専用のクラウド・自社設置

評価の基盤には、エージェントへの質問と答え、参照した資料、道具の呼び出しの記録が流れ込みます。問い合わせのエージェントなら、顧客の氏名や契約の内容が記録に含まれることもあります。つまり、評価の基盤は、エージェントが扱う最も機微な情報の写しを持つ場所になります。

Galileo は、事業者のクラウドで使う形、自社専用のクラウド環境に置く形、自社の設備に置く形を挙げています。どれを選ぶかで、記録がどこに保存され、誰が触れられるかが変わります。事業者のクラウドを選ぶなら、保存期間、保存地域、削除の方法、採点に使う大きなモデルへ何が送られるかを、契約の前に書面で確かめます。買収後は、スプランク側の規約や保存の仕組みに移る可能性もあるため、移行の予定と、その時点でのデータの扱いもあわせて確認しておきます。

• 記録に個人情報が含まれるなら、送る前に伏せる処理を入れるか、評価の対象から外すかを決める
• 採点役に外部の大きなモデルを使う評価項目は、そのモデルの提供元にも記録の一部が渡る
• 自社設置を選んでも、利用状況の送信や認証の通信がないかは別に確かめる

項目8　誰の権限で動くか：評価項目と閾値を変えられる人

評価の基盤で見落とされやすいのが、設定を変えられる人の範囲です。評価項目の閾値を下げれば、本来は不合格の答えが合格になります。止め役の方針を外せば、出してはいけない答えが通ります。これは、品質の基準そのものを書き換える権限です。

権限は、少なくとも三つに分けて考えます。評価項目や閾値を変える権限、本番の止め役の方針を変える権限、記録を閲覧する権限です。前の二つは、業務の責任者の承認を経て、ごく少数の担当者だけが変えられるようにします。記録の閲覧は、個人情報を含む可能性があるため、開発者全員に開けるのではなく、必要な人に限ります。

変更の履歴も残します。いつ、誰が、どの評価項目の基準や閾値を変えたか、その理由は何か、です。点数が急に良くなったとき、それが答えの改善なのか、基準の緩和なのかを後から見分けられるのは、この履歴だけです。点数の改善と基準の緩和を見分けられない運用は、評価をしていないのと同じだと考えておきます。

使いどころ：問い合わせ対応とマーケのエージェント

BtoB企業で Galileo のような評価の基盤が効きやすいのは、顧客や見込み客と直接やり取りするエージェントです。代表は、製品の問い合わせに答えるエージェントです。答えの誤りがそのまま顧客の誤解や約束につながるため、資料に沿っているか、約束表現がないか、引き継ぐべき場面で引き継いだかを、本番で継続して見る価値があります。

マーケの側では、資料請求の後に送るメールの下書き、ウェビナーの参加者への個別の案内、記事の下書きを作るエージェントが候補になります。ここでの合格基準は、製品の仕様や数字が社内の正の資料と一致しているか、景品表示法に触れる言い回しがないか、自社の表記の決まりを守っているかなどです。点数で全件を見て、低い点のものだけ人が読む形にすれば、確認の手間を下げつつ事故を防げます。

一方で、件数が少ない業務では、評価の基盤を入れる効果は小さくなります。月に数十件しか答えないエージェントなら、人が全件を読むほうが早くて確実です。評価の基盤は、人が全件を読めない量になったときに初めて意味が出ると考え、件数の見込みから導入の時期を決めます。

評価エンジニアの技能に任せる修正の範囲

2026年5月に Galileo が公開した「評価エンジニア」は、Claude Code や Codex といった開発用のAIに、評価の結果から原因を診断し、修正の計画と確認の計画を作らせる技能の束です。公式ブログでは、初期段階の版として公開され、本番の記録から取り出した証拠をもとに、診断の文書、修正の計画、確認の計画を作り、許可されたファイルだけを直して、直す前と後を比べる流れが説明されています。

注目したいのは、公式の説明自体が、人の判断を残す設計になっている点です。修正の候補から作られた評価用の事例は「候補」として扱われ、正解として使う前に人の確認が要るとされています。新しい道具の追加やモデルの変更、製品の振る舞いの変更といった大きな判断は開発者に残り、最後に変更を取り込むかどうかも人が決めます。AIに直させてよいのは、範囲を決めた小さな修正までという線が、道具の側に組み込まれています。

社内で使うなら、この線をさらに具体的にしておきます。直してよいファイルは指示文と例示だけにする、評価項目そのものの基準はAIに直させない、確認の計画は業務の担当者が読む、などです。評価の基準を直す権限と、答えを作る側を直す権限を、同じAIに持たせないことが、採点と改善が自己採点にならないための最低限の線です。

費用の増え方と、止め方・やめ方

費用は、採点する件数と、採点に使うモデルの大きさで増えます。大きなモデルに採点させる評価項目を全件に当てれば、エージェント本体と同じくらいの費用がかかることもあります。料金の体系は公式サイトの料金ページで案内されていますが、買収後に変わる可能性があるため、見積もりは件数の見込みと評価項目の数を書いた上で、書面で取るのが確実です。

止め方は、二段階で考えます。一つは、評価の基盤が止まったときにエージェントをどうするかです。本番の止め役として使っている場合、評価が止まると答えを止めるのか、通すのかを決めておかないと、障害の時に現場が判断に迷います。もう一つは、評価の基盤そのものをやめるときです。

やめるときに手元に残すべきものは、業務の合格基準の文章、評価項目の採点の指示文、正解の印を付けたデータ、閾値と変更の履歴です。これらは道具が変わっても使い回せる、評価の資産です。逆に、事業者の独自形式でしか持っていない状態だと、乗り換えのたびに一から作り直すことになります。契約の前に、出力の形式と出力できる範囲を確かめておきます。

決める順番：入れる前の5工程

ここまでの項目を、実際に入れるまでの順番に並べ直すと、次の5工程になります。工程を飛ばして評価の基盤から触り始めると、点数は出ても判断に使えない状態になりやすいので、順番を守ることが大切です。

この順番のうち、工程1と工程2は道具がなくても始められます。Galileo を入れるかどうかを決める前に、まず合格基準と試験データを作ってみると、自社に評価の基盤が必要かどうか、どの程度の規模が要るかが見えてきます。

よくある質問

既成の評価項目だけで始めてもよいですか

傾向を見る目的なら始めてかまいません。ただし、既成の評価項目は業務の合格基準を知りません。既成の点数が高くても、料金の約束や引き継ぎ漏れのような業務固有の誤りは見逃されます。業務固有の項目は、少なくとも人の抜き取りで補うことを前提にしてください。

作り話の検出だけなら、ほかの手段でも足りませんか

答えが資料に書いてあるかどうかだけを見たいなら、その一点に絞った仕組みでも足ります。Galileo が意味を持つのは、エージェントの一連の動きの記録、業務固有の評価項目、本番の止め役、人の訂正による調整までを一つの場所で回したい場合です。必要な範囲から逆算して選びます。

採点役のAIの点数を、担当者の評価に使ってよいですか

使わないほうが安全です。点数はエージェントの答えの品質を見るためのもので、採点役のAI自体も誤ります。点数を人の評価に結びつけると、点数を上げるために基準を緩める動機が生まれ、評価の意味が失われます。

まとめ

Galileo は、AIとエージェントの答えを評価項目で採点し、本番まで見張るための基盤で、2026年にはシスコによる買収、人の訂正による採点の調整、開発用AI向けの評価エンジニアの技能と、動きが続いています。ただ、どれだけ道具が進んでも、何をもって合格とするかは業務の責任者が文章で書くしかありません。合格基準を書き、評価項目に翻訳し、採点役のAIに任せる範囲と人が抜き取りで見る範囲を分け、点数で止める対象と設定を変えられる人を絞る。この順番で決めておけば、評価の基盤は「点数が出るだけの画面」ではなく、品質の約束を守るための道具として働きます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。