Eevoは、複数の選択肢を「誰に、どんな結果をもたらすか」で比較する判断用AIです。 フィンランドのUprightが提供し、エージェントが集めた事実や選択肢から、関係者ごとの推奨を返します。Jevなどの判断モデルを追っている人にとって、今回注目したいのは、会社・顧客・担当チームの都合を一つの答えに隠さず扱う設計です。
たとえば、研修資料の修正を急いで今日配るか、確認を終えてから配るか。受講者には早い配布が助かっても、作成担当者には確認時間が必要です。こうした、分類先を決めるだけでは終わらない仕事の相談に使えるかを、公開仕様から整理します。
2026年10月15日にEevo-1の公式発表と開発資料を確認しました。編集部はアカウント作成、MCP接続、APIの実行をしていません。日本語の対応保証や日本語評価の公開結果は確認できず、日本からの登録完了も未確認です。本文の研修資料の例は、入力を準備するための架空例であり、Eevoの実測結果ではありません。
何が公開されたのか。Jevとの比較で押さえる場所
UprightはEevoの発表ページで、Eevo-1をAPI・MCP・Webコンソールから提供すると案内しています。Upright所属を明記したJuho Ojala氏のHacker Newsでの公表は、2026年10月15日3時52分50秒（日本時間）でした。公式ページは当日提供としていますが、サービスが最初に利用可能になった正確な時刻は確認できません。
これまで紹介したJevは、質問に対して選択・評価などの型を決めて答えを受け取る仕組みです。Eevoにも同種の型付き質問を扱うSystemOne互換APIがあります。ただし、今回の中心は、選択肢の結果を並べて比較する独自のDecision APIです。「Jevより強い」と一括りにするより、どこに判断材料を置くかを見るほうが役立ちます。
| 使い方 | 主に準備するもの | 受け取り方 |
|---|---|---|
| 型付き質問として聞く | 状況と、分類・点数などの質問 | 決めた回答候補と確率 |
| EevoのDirectモード | 状況・選択肢・関係者 | 関係者ごとの推奨と各選択肢の確率 |
| EevoのDefaultモード | 上記に加え、各選択肢が生む具体的な結果 | 推奨・確率に加え、結果の大きさや期待値の範囲 |
DefaultとDirectでは必要な入力が違います。結果を明示して判断の内訳を見たいならDefault、結果の内訳を要さず関係者ごとの答えを受け取りたいならDirectという切り分けです。Defaultへ結果なしで送る、またはDirectへ結果一覧を付けるとエラーになるとモード選択の公式資料に記載されています。
「誰にとって」を分けると、会議で確かめることが変わる
社内研修の資料に、古い操作画面が3か所残っている架空の場面を考えます。受講者は30人、研修は翌朝。今日16時の配布予定まで2時間あり、画面を差し替えた版の確認には担当者の追加作業が必要です。ここで、単に「最善案を選んで」と頼むと、早さ・正確さ・担当者の負担のどれを重視したのかが見えなくなります。
| 関係者 | 比較したいこと | 先に確認する事実 |
|---|---|---|
| 受講者 | 予習時間と、迷わず操作できること | 何人が今日のうちに予習するか |
| 資料担当チーム | 修正の確認時間と、別業務への影響 | 追加で確保できる時間、確認者の空き |
| 研修の運営者 | 研修を予定どおり進めること | 古い画面のままでも当日の説明で補えるか |
この表で挙げた事実を調べること自体に価値があります。Eevoに情報を渡す前に、問題の大きさが分からない箇所を見つけられるからです。「研修に失敗する確率30%」のような数字を、もっともらしさのために作る必要はありません。分からないことは、分からないまま材料に残します。
公式の入力作成ガイドも、意思決定者・期限・違いを生む事実を記載し、欠けた情報を捏造しないよう案内しています。関係者を会社だけにすれば、会社だけを基準にした評価になります。顧客や現場の都合が自動的に補われるとは考えないほうがよいでしょう。
メリットを言い換えて、二重に足さない
Defaultモードでは、比較の基準をそろえることも大切です。この研修例なら「追加対応せず、現状の資料を予定どおり配布する」を共通の基準にします。そのうえで、各案が何を変えるのかを書きます。
| 案 | 共通の基準から変わることの例 | 避けたい書き方 |
|---|---|---|
| A：予定時刻に修正表を添付 | 受講者が古い画面との対応を参照できる。担当者に修正表の作成作業が増える | 「Bより早い」だけで比べる |
| B：全体を修正・確認して配布を遅らせる | 画面の食い違いがなくなる。予習できる時間が短くなる。差し替えと確認の作業が増える | 正しい画面・誤解の解消・操作の理解を無条件に別々の大きな利点にする |
| C：予定の資料を配り、研修冒頭で訂正する | 冒頭の説明時間が増える。配布後に修正版を送る作業が増える | 何も変わらない項目まで利点として加える |
「正しい画面に直す」と「その画面で迷う人を減らす」は、関係する二つの効果です。両方を書くことが常に誤りなのではなく、同じ利益の一部を別名で重ねていないかを確かめます。Eevoは言い換え、包含、因果関係などの重なりを調べると公式資料で説明しています。ただし、実際の影響を正しく見積もれたかは別途確認が必要です。
入力の段階で一つの基準からの変化にそろえれば、読む人も検収できます。片方を「作業が2時間増える」、もう片方を「その2時間を節約できる」と書いて、同じ違いを両側から数えないことが出発点です。
確率とEVは、そのまま事業の成功率や円にできない
Eevoの数値の説明では、各選択肢の確率を「その関係者にとって最善だとモデルが考える確率」としています。たとえば仮にBが0.74と返っても、「Bを実行すれば研修が74%の確率で成功する」という意味にはなりません。
Directのconfidenceは、最上位の選択肢の確率です。Defaultのp_bestは、結果の大きさの不確実性から1,000回のサンプルを取り、その選択肢が最高になった割合です。同じconfidenceという名前でも、別製品の指標と意味が同じとは限りません。
DefaultのEVも、一般的な収支予測の金額とは区別します。公式仕様では、各結果が起きたものとして大きさを評価し、最大の結果の大きさを1とする関係者内の尺度で足し合わせます。別々の関係者のEVは比較できません。「会社のEVが0.8、受講者が0.5だから会社を優先」と足し引きする読み方はできない、ということです。
関係者によって推奨が割れたら、誰の負担を受け入れる判断なのかを確認します。差が小さいなら、追加情報で決められないかを考えます。推奨が明確でも、予算や公開権限を与えたことにはなりません。
試す前に、費用と保存条件を確認する
Eevoはクラウドのサービスです。Webコンソールを使う経路と、MCP対応クライアントにつなぐ経路があります。特定のローカルOSにモデルを入れる手順ではありません。Enterpriseではプライベート配備も案内されていますが、手元のMacへ自由に重みをダウンロードできるという意味ではありません。
| 項目 | 確認できた条件 |
|---|---|
| モデル | eevo-1 |
| 料金 | 入力100万トークンあたり2.50米ドル。出力無料 |
| Defaultの集計 | 1判断内の各モデル呼び出しの入力を合計する |
| 無料枠 | 新規アカウントはDefault 5判断（各10回まで改訂）、Direct 50判断 |
| 代表例 | 公式の短い入力例では、結果10件・関係者2者で約0.20米ドル |
| 固定額ではない理由 | 文脈が長いほど各呼び出しの入力が増える。最大450呼び出しでも固定の価格上限にはならない |
料金・制限の公式資料には、長い入力の例で約6.08米ドル、各テキストを上限まで使う例で約13米ドルになる記載もあります。「1回20セント」と予算を固定するのは避け、返却されるcost_usdを記録します。無料枠には混雑時の待機・再試行条件もあります。
応答時間も、発表ページの代表値を一律の約束にはできません。モード選択資料ではDefaultの目安を5〜70秒、Directを数秒と説明しています。Defaultは約50秒を超えると202で返し、IDで結果を取得する流れがあります。短い分類を毎秒大量に流す仕事と、会議で選択肢を比べる仕事では条件が違います。
データ保持の公式資料では、APIキーごとの保存期間と、OAuth接続・コンソール用の保存期間を別に設定します。Not storedを選べるのは組織がクレジットを購入した後で、無料利用時はリクエストが保存されます。また、保存と、将来のモデル学習への利用設定は別項目です。試す材料は最初から架空の案件にすると、扱いを確かめやすくなります。 Not storedでも、202で継続中の回答は1回取得または最長1時間まで一時保持され、本文を含まない利用量・料金などの記録は残ります。
最初の一回は、判断を実行させず比較表まで
- 1公式のWebコンソールを開き、登録条件・無料枠・Data controlsの保存と学習設定を確認します。日本からの登録可否は、ご自身の画面で確認してください。
- 2実在する顧客情報を含まない一件を用意します。選択肢は少数に絞り、期限と分かっていないことも書きます。
- 3Defaultを使うなら、各案の結果を共通の基準からの変化として用意します。結果の大きさが普通の計算だけで決まるなら、先に表計算などで計算します。
- 4関係者ごとの推奨、数値の意味、入力から抜けた事実、cost_usdを記録します。承認や外部操作を自動で実行する設定にはせず、人が評価します。
既にClaudeなどのMCP対応環境を使っている場合は、公式の接続ガイドからEevoを追加する経路もあります。サーバーURLは https://eevo.io/api/arvo/mcp、対話的な接続ではOAuthで認証する案内です。クライアント側の対応プランや管理者権限も確認してください。
以下は架空の社内研修です。まず不足情報を挙げ、確認できた情報だけでEevoに相談する入力案を作ってください。不足する事実・成功率・金額を作らないでください。
状況：明朝の研修は30人参加。資料は今日16時配布予定で、今は14時。古い操作画面が3か所残っています。
共通の基準：追加対応をせず、現状の資料を予定どおり配布する。
選択肢：A 修正表を添えて16時に配る／B 全体を修正・確認して配布を遅らせる／C 予定の資料を配り研修冒頭で訂正する。
関係者：受講者、資料担当チーム、研修運営者。
不明：予習する人数、修正と確認に必要な時間、古い画面でも説明で補えるか。
必要な情報を私が補った後、EevoのDefaultモードで比較してください。返却値は関係者ごとに示し、推奨の不一致、入力に依存する点、費用を説明してください。確率を研修の成功率として説明しないでください。配布や通知は実行しないでください。日本語のまま試すなら、意味を保った英訳と同じ条件で比べる、選択肢の順序を入れ替える、欠けていた情報を一つずつ追加する、といった確認ができます。これらは今後の試用案です。入力を書き換えて望む答えへ誘導するのではなく、何が変わると判断が変わったのかを残します。
| 残す項目 | 記入する内容 |
|---|---|
| 条件 | モデル名・日時・モード・入力言語・選択肢の順序 |
| 判断材料 | 既知の事実・不明点・関係者・共通の基準 |
| 返却値 | 関係者ごとの推奨・確率・EVの範囲・cost_usd |
| 人の確認 | 見落とし、採用しなかった理由、追加すべき情報 |
| 後日の振り返り | 実際に選んだ案と起きた結果。結果が良かっただけで判断時の根拠まで正しかったとはしない |
Eevoを試す価値がある仕事、先に別の方法で済む仕事
複数の部署・顧客・担当者の利害が食い違い、選択の根拠を後から説明する仕事には、Eevoの出力形式を検討する余地があります。逆に、期限の前後、費用の合計、決まった条件による承認の可否は、コードや表計算で確定できる部分を先に処理します。すべての判断にモデルを呼ぶ必要はありません。
公式には他の判断モデルとの評価表もありますが、提供企業による測定です。表の中でも指標や条件が異なり、日本語の業務で一律に優れる根拠にはなりません。まず、自分たちが人へ相談している一件について、利害と不足情報が見えるようになったかを確かめるのがよい出発点です。
判断モデル全体の位置づけはJev・Laya・Jeff・Micaの比較、判断結果から実際の処理へ進めるときの境界はMicrosoft-Decision-1の問い合わせ振り分け例でも扱っています。Eevoでは、その手前にある「誰のための、どんな結果を比べたのか」を明示してみてください。