「この問い合わせは経理か、情シスか」。短い判断のために毎回クラウドへ文章を送る代わりに、手元のMacで候補を返す選択肢があります。は、そのためのオープンな判断モデルを取得し、実行する道具です。2026年9月26日の更新で、のGPUを使う実行が加わりました。公式の更新情報
編集部では9月27日、架空の日本語問い合わせ20件を同じモデルの実行とGPU実行で比較しました。初回を除く所要時間は短くなりましたが、部署が明確な16件の分類一致は、どちらも9件でした。この記事では設定方法だけでなく、何が速くなり、何をまだ自動化できないかを、配布データとともに確認します。
1. 9月26日に変わったのは、Macでの実行方法
Ollayaの初版は9月24日朝の公開で、今回の焦点は初公開ではありません。9月26日17時34分（日本時間）の0.7.1で、Layaの英語版・多言語版とnli:modernbert-largeがApple GPUで動くようになりました。公式条件はApple silicon搭載Mac、macOS 14以降です。すべてのモデルが一律に高速化するわけではありません。0.7.1リリース
本記事の実測には、9月27日7時18分公開のOllaya 0.7.2を使いました。この版はTypeSafe互換の経路で、モデルに収まらず切り詰められた入力をエラーにする改善も含みます。古い紹介記事の手順と混ぜず、実行版とモデル名を一緒に記録することが再現の出発点です。0.7.2リリース
2. Ollayaは実行する道具、Layaは判断するモデル
Ollayaはそのものをローカルで動かす製品ではありません。今回はの多言語版を選び、経理・情シス・人事・総務のどれに当たるかを尋ねます。Ollayaはモデルの取得と実行、共通のを担当し、分類内容は選んだモデルと質問の定義に左右されます。公式モデル一覧
TypeSafe互換の /v1/systemone へ、入力と質問をで送れるため、Jevの記事で扱った問い合わせ分類の構成を移しやすくなります。ただし、リクエストや応答の形が似ていることと、同じ判断が返ることは別です。Jevと同等の精度、同じ確率、同じ処理速度を保証するものではありません。互換性の説明
| 要素 | 今回の選択 | ここで決まること |
|---|---|---|
| 実行ソフト | Ollaya 0.7.2 | 取得・起動・ローカルAPI |
| 判断モデル | laya:multilingual | 日本語を含む入力への分類 |
| 実行場所 | CPU / Apple GPU（MLX） | 同じ重みをどこで計算するか |
| 業務の定義 | 固定した4部署と説明 | 何を経理・情シスなどと呼ぶか |
Ollayaと今回のLayaはApache-2.0で公開されています。従量制の外部API料金は発生しない構成ですが、機材や電力、導入・評価の手間はかかります。ほかのモデルに替える場合は、その重みの利用条件も確認してください。本記事では有料API、顧客データ、実際の担当変更を使っていません。Layaの配布条件
3. 分類先を先に決め、日本語20件を固定する
今回は試用前から用意していた架空教材を、結果に合わせて変えずに使いました。経理・情シス・人事・総務を各4件、計16件。さらに複数部署への依頼、会社業務の対象外、情報不足を含む4件を加えています。部署の境界は会社ごとに異なるため、この教材の定義をそのまま自社の正解にする必要はありません。
| 候補 | 固定した担当範囲 | 境界を見る例 |
|---|---|---|
| accounting：経理 | 立替経費、請求書、取引先への支払い | 画面は開くが、交通費が精算対象か不明 |
| it：情シス | 会社端末・システム・アカウント・ネットワークの障害 | 経費精算システムがエラーになる |
| hr：人事 | 勤怠、休暇、入退社、社会保険、従業員情報 | 勤怠画面は開くが、退勤時刻を打ち忘れた |
| general：総務 | 会議室、入館証、設備、事務用品 | 入館証をなくしたので再発行したい |
重要なのは、要確認4件の human_review を採点用のラベルにだけ置いたことです。モデルへは4部署しか渡していません。したがって、範囲外の相談にも何らかの部署を選びます。4件を「正しく人へ戻せたか」の成功率として数えたり、部署16件と混ぜて単純な正解率を作ったりしません。まず強制選択の挙動を見る実験です。
教材には正解ラベルと理由がありますが、送信するのは問い合わせ本文、部署の定義、固定した質問文だけです。後から別モデルを試す場合も、この部分を変えずに使えます。今回は同じLayaの実行場所を比較したもので、MicaやJevとの実機比較は行っていません。
python3 evaluate_ollaya.py4. MacでCPUとApple GPUを切り替えて試す
配布した準備コードは、公式0.7.2の本体とMLX用ファイルを新規フォルダーへ取得し、公開時点のチェックサムを検査して展開します。システムへのインストールや常駐登録は行いません。Python 3.10以降、Apple silicon、macOS 14以降を使い、空き容量は2 GB以上を確保してください。準備でエラーが出たら、その時点で止めます。
python3 prepare_macos.py --directory ./ollaya-trial
# ターミナルA：CPUで前景起動し、この画面は開いたままにするOLLAYA_MODELS="$PWD/ollaya-trial/models" \OLLAYA_HOST=127.0.0.1:11439 OLLAYA_DEVICE=cpu \OLLAYA_MAX_LOADED_MODELS=1 \./ollaya-trial/runtime/bin/ollaya serve次の操作は、別のターミナルを同じ教材フォルダーで開いて行います。laya:multilingual は今回の取得時点で関連ファイル込み約684 MBでした。laya とだけ書くと英語版なども取得するため、タグを省略しません。取得時はインターネットを使い、評価コードは起動済みの 127.0.0.1 だけに送信します。公式CLI仕様
curl --noproxy '*' --fail-with-body http://127.0.0.1:11439/api/versioncurl --noproxy '*' --fail-with-body http://127.0.0.1:11439/api/pull \ -H 'Content-Type: application/json' \ -d '{"model":"laya:multilingual","stream":false}'python3 evaluate_ollaya.py --run --output my-cpu.csvCPUの実行後はターミナルAで Ctrl+C を押し、終了を待ちます。同じ起動コマンドの OLLAYA_DEVICE=cpu を OLLAYA_DEVICE=metal に替えて再起動してください。その後、出力名を替えて測ります。GPUを指定しただけで済ませず、/api/ps の device: "metal" と、サーバーログの engine=mlx を確認します。終わったら再び Ctrl+C で終了します。
python3 evaluate_ollaya.py --run --output my-metal.csvcurl --noproxy '*' --fail-with-body http://127.0.0.1:11439/api/ps5. 実測：速くなったが、分類一致は9/16だった
編集部の環境はM2 Ultra、メモリー192 GiB、macOS 27.0。9月27日11時19〜20分に、0.7.2・同じ多言語Layaの重み・同じ質問を使いました。CPUを先に、サーバーを終了してからApple GPUを測定しています。各ケースはそれぞれ1回、予熱用の呼出や、結果を見た後の質問調整はしていません。測定条件とモデル識別子
| 実行条件 | 明確16件の一致 | 最初の1件 | 残り19件の中央値 |
|---|---|---|---|
| CPU / ONNX / fp32 | 9 / 16 | 1,408.3 ms | 95.2 ms |
| Apple GPU / MLX / fp32 | 9 / 16 | 2,359.2 ms | 12.6 ms |
APIと起動ログの両方でGPU実行を確認でき、20件の選択結果はCPUとGPUで一致しました。初回はGPUの方が長く、その後の中央値は小さくなっています。これは今回のMacと短い問い合わせでの観測です。並列処理、大量データ、他のMac、長い文章の速度へは一般化できません。CPUの全記録／GPUの全記録
分類では、たとえば「経費精算システムに入るとエラーになる」は情シスを期待しましたが、経理が選ばれました。このときconfidenceは0.6035です。「入館証の再発行」も期待は総務、出力は経理でした。日本語を受け付けて速く返るだけでは、部署の境界を正しく理解したことにはなりません。9/16はこの固定教材の一致件数であり、日本語全般の精度ではありません。
| 要確認ケース | CPU/GPUで共通の出力 | confidence |
|---|---|---|
| 出張費精算とパソコン故障が混在 | 情シス | 0.3584 |
| 自宅テレビの修理相談 | 情シス | 0.2501 |
| 「例の件」とだけ書かれた依頼 | 人事 | 0.3064 |
| 入社・端末設定・会議室予約が混在 | 総務 | 0.1606 |
6. confidenceを、そのまま自動処理の閾値にしない
OllayaのChoiceのconfidenceは、候補の確率が一つにどれだけ集中したかを表します。候補数をK、最大の確率をpとすると、式は (K × p − 1) / (K − 1)。今回のKは4です。最大の確率そのものとも、個別の分類が正しい確率とも異なります。APIの項目名だけを見て、別の実装から同じ閾値を持ち込まないようにします。公式の値の定義
さらに公式は、多言語Layaには再調整した温度が付いておらず、信頼する閾値に使う前に自社のラベル付きデータでを行うよう説明しています。今回の20件を見て都合のよい閾値を探し、同じ20件で安全性を証明することはできません。業務の境界を定義し直す場合も、調整用と最終確認用のデータを分けます。公式の制約
次の試用では、担当者が回答候補を見ずに付けた分類と照合し、複数依頼・対象外・情報不足をどこで人へ戻すかを別に設計します。今回の教材はその前段です。実務では候補を表示して人が確認するところから始め、誤分類の種類と見直しの手間を記録してください。速度だけで導入を決めないための進め方は、新しい道具を選ぶ考え方も参考になります。
7. この結果から、次に何を試すか
Ollayaの価値は、同じ入力形式でモデルや実行場所を替え、手元で確かめやすくなることです。今回の多言語LayaはGPUで速く動きましたが、定義した部署分類をそのまま任せられる結果ではありませんでした。固定したケース・質問・モデルの版・生応答を残せば、別モデルや別の質問を試したときに、改善した点を具体的に比べられます。
まずは配布した20件を自分のMacで再現し、期待と違った相談の内容を確認してください。その先で、自社の担当範囲に合う評価データを増やします。モデル間の比較や保留条件の設計は、読者の反応と検証結果に応じて続編で扱います。