Jev AI
すべての記事に戻る

開発者ガイド

Laya AI：モデル選択とAPI連携ガイド

Laya AIの仕組みとモデルの選び方、Laya APIの連携方法を解説。実行可能なコード例、型付き判断、エラー処理、クレジット、導入前の評価方法まで紹介します。

執筆者：Jev AI2026年9月28日読了時間：21分
Laya AI：モデル選択とAPI連携ガイド

Laya AIは文脈を、範囲の定まった判断に変換します。出力はカテゴリ、順序のあるスコア、またはある命題が真である確率です。 アプリケーションが候補となる結果をすでに把握していて、その中から選ぶ助けを必要とするときに、Layaモデルが役立ちます。Laya APIはこうした判断をHTTP経由で利用できるようにしますが、モデルと、そのインターフェースを提供するサービスは別のものです。

「更新後からチェックアウトが動かず、お客様が支払いを完了できません」というサポートメッセージを考えてみてください。アプリケーションには、担当先、優先度、場合によっては人による確認が必要かどうかのフラグが必要です。それぞれの判断について、文章を生成する必要があるとは限りません。Laya AIオンラインプレイグラウンドで、自分のサンプルを使ってこの方式を試せます。

この記事では、このワークフローに沿ってモデル選択、APIリクエスト、本番導入に向けた評価を説明します。モデルの説明は上流プロジェクトに基づき、エンドポイントの説明はthejevai.comのサービスを対象としています。資料は2026年9月28日に確認しました。例と図は連携方法を説明するもので、性能の実測結果ではありません。

目次

Laya AIとは

LayaはConvai Innovationsによるオープンウェイトの判断モデル群で、Apache-2.0ライセンスで公開されています。非自己回帰型のアーキテクチャにより、回答をトークン単位で生成するのではなく、定義済みの回答候補を評価します。英語のチェックポイントはModernBERT、多言語のチェックポイントはmmBERTを使用します。上流のPythonパッケージにはルーターが含まれ、ローカル推論に対応しています。

このアーキテクチャは、分類、振り分け、目的の明確な評価に適しています。生成モデルが顧客への返信を下書きし、Layaが振り分けのための情報を返す、といった組み合わせも可能です。求められる出力の役割が異なるため、両者は連携できます。

次の三つの層を区別してください。

層 選択するもの 検証すること
モデル チェックポイント、リビジョン、実行環境 自分のタスクでの正確性
API 認証、リクエストとレスポンスの形式 制限、可用性、実際の提供構成
アプリケーション 許可する操作とフォールバック規則 判断を操作の実行につなげてよいか

構造化された出力は連携を簡単にしますが、形式上有効なラベルでも判断自体は間違うことがあります。同様に、オープンなライセンスでホスティング費用がなくなるわけではなく、特定のGPUで測ったベンチマークから自分のアプリケーションの応答時間が決まるわけでもありません。

三つの判断タイプを理解する

Layaのカテゴリ別確率分布、順序付きスコア、はい・いいえの確率を比較する数学スケッチ

Choice：名前の付いた結果を選ぶ

billing、technical、otherのように意味の明確なカテゴリには、choiceを使います。回答内のchoiceフィールドが選ばれたラベルを示し、確率のフィールドも返される場合があります。人が同じルールを一貫して適用できるように、カテゴリを説明してください。

たとえば、「二重に請求された」は請求担当、「チェックアウトがクラッシュする」は技術担当に相当します。一つのメッセージに両方の問題がある場合は、どちらを振り分けの基準にするかを定めます。otherは自分で定義した受け皿のカテゴリであり、モデルが不確実性を検出したことを自動的に意味するものではありません。

Score：順序のある尺度で評価する

順序に意味がある場合は、scoreを使います。実用的な緊急度の基準なら、通常の質問、回避策がある業務停止、回避策がないサービス停止などを区別できます。ホスト型インターフェースの尺度はゼロから始まり、結果は小数になることもあります。

三段階の尺度で1.8という値は、二番目と三番目の水準の間を表します。障害が発生している確率が80%という意味ではありません。中間の値をアプリケーションでどう扱うか決め、優先度の重大な過小評価と、隣り合う水準の軽微な不一致を分けて測定してください。

Noul：具体的な命題を評価する

顧客が明示的に返金を求めているか、というような焦点の定まった二択の質問には、noulを使います。値は確率の推定であり、真偽値ではありません。JavaScriptのBoolean(value)で変換しないでください。ごく小さな正の数でもtrueになってしまいます。

検出した意図と操作の承認を区別します。「返金が求められている」ことは、二重払いが発生した証拠でも、返金が許可される根拠でもありません。それらは、確認済みの記録とアプリケーションのポリシーでチェックすべき事項です。

用途に合ったLayaモデルを選ぶ

Layaモデルの概要では、モデル群と判断インターフェースを紹介しています。上流プロジェクトの主な選択肢は、英語、多言語、そして特定の型付き判断ワークフロー向けにファインチューニングされたチェックポイントです。

候補 最初に試す用途 評価の重点
英語 主に英語の入力 専門用語と曖昧なラベル
多言語 英語以外、または複数言語が混在する入力 実際に受け取る対応言語ごとの結果
Typed-decisions 特化した学習内容に近いワークフロー 自分のラベル、ポリシー、文書への適合性

言語入力、三つのLayaモデル候補、共通の評価表をつなぐ数学的な決定木

ホスト型APIは、リクエストの識別子としてenglish、multilingual、typed-decisionsを受け付けます。これらは公開インターフェースの仕様に含まれる識別子であり、特定のチェックポイントのバージョンが使われている証拠ではありません。 現在のプロジェクト実装はプロバイダーのアダプターを使用しています。ホスト型の応答を特定の公開チェックポイントの能力を示す証拠とみなす前に、実際に推論を提供しているモデルとリビジョンを確認してください。

再現可能なモデル比較には、同じ条件でバージョンを固定したチェックポイントを実行します。パッケージのバージョン、モデルのリビジョン、デバイス、質問文、コンテキスト設定を記録してください。ローカルSDKで利用できる設定が、すべてホスト型サービスにも公開されているとは限りません。

言語対応も実際のテストが必要です。幅広い言語への対応をうたっていても、言語、俗語、音写、複数言語が混在するチケットに対し、同じ正確性が得られることを意味しません。全体の平均だけでなく、こうした条件ごとに結果を分けて評価します。

分類体系に似通ったラベルが数十個ある場合は、まず大分類を選び、その中から専門の担当キューを選ぶ二段階の方式を試せます。各ラベルの説明を明確にできますが、最初の段階で誤った分岐に送る可能性もあります。追加の遅延や最初の誤判断から復帰できるかも含め、処理全体を一段階のベースラインと比較してください。

APIを呼び出す前に判断を設計する

入力となる証拠、許される結果、その結果がもたらす影響を明記した判断仕様から始めます。サポートの振り分けなら、モデルは担当キューや緊急度を提案できます。一方、誰が返金やアカウント変更を実行できるかは、既存の権限システムが決めます。

stateには、判断に十分な最小限の文脈を含めます。現在の顧客メッセージと、関連する確認済みの事実を渡してください。最新の障害報告だけが重要なら、会話履歴全体は不要です。アカウントの状態が必要なら、モデルに見えないデータを推測させるのではなく、明示的に提供します。

質問は、それぞれ独立に評価しても意味が通るように書きます。同じリクエスト内の優先度の質問が、振り分けの質問の回答を読み取ることに依存してはいけません。一つの判断が本当に別の判断に依存するなら、アプリケーション側で別々の処理段階として構成してください。

連携前に、小規模な難例セットを用意します。明確な請求問題、技術障害、複数の要望が混じる依頼、無関係なメッセージ、英語以外のチケット、証拠が不足したメッセージを含めます。「返金を求めているわけではありません」といった否定も追加してください。順調なケースだけのデモでは見えにくい基準の曖昧さを、こうした例で早く発見できます。

最初のLaya APIリクエストを送る

Laya API連携ドキュメントには、このサイトのエンドポイント、認証、レスポンス全体の構造が記載されています。アカウントのAPIキーを作成し、十分なクレジットを確保して、サーバーの環境変数LAYA_API_KEYにキーを保存します。

Bearer認証とJSONを使って、https://thejevai.com/laya/v1/systemoneへPOSTリクエストを送ります。このパスに言語の接頭辞は付きません。キーがブラウザー用のコードに含まれないよう、バックエンドのプロセスから呼び出してください。

クライアント、APIキーを保持するサーバー、Laya API、アプリケーションのポリシー判定を示す数学的な構成図

次の例をlaya-triage.mjsとして保存し、環境変数を設定した後、Node.js 18以降で実行してください。送信は一度だけで、課金される可能性のある操作を自動再試行しません。英語の入力例はenglishモデルに合わせて原文のままにしています。

const apiKey = process.env.LAYA_API_KEY;
if (!apiKey) throw new Error('Set LAYA_API_KEY on the server.');

const payload = {
  model: 'english',
  state: {
    message: 'Checkout crashes for every customer. Nobody can pay.',
    verified_status: 'No workaround has been confirmed.',
  },
  questions: {
    department: {
      type: 'choice',
      instructions: 'Which team owns the reported problem?',
      criteria: {
        billing: 'Charges, invoices, or refund requests',
        technical: 'Software failures or unavailable services',
        other: 'Issues outside billing and technical support',
      },
    },
    urgency: {
      type: 'score',
      instructions: 'Assess urgency using only the supplied evidence.',
      criteria: [
        'Routine question; work is not blocked',
        'Work is blocked but a workaround is confirmed',
        'Service is unavailable and no workaround is confirmed',
      ],
    },
    refund_requested: {
      type: 'noul',
      instructions: 'Does the customer explicitly request a refund?',
    },
  },
};

const response = await fetch('https://thejevai.com/laya/v1/systemone', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${apiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(payload),
  signal: AbortSignal.timeout(45_000),
});

const body = await response.json();
if (!response.ok || body.code !== 0) {
  throw new Error(`Laya request failed: HTTP ${response.status}`);
}

const answers = body.data?.result?.answers;
const department = answers?.department;
const urgency = answers?.urgency;
const refund = answers?.refund_requested;
if (
  department?.type !== 'choice' ||
  !['billing', 'technical', 'other'].includes(department.choice) ||
  urgency?.type !== 'score' ||
  !Number.isFinite(urgency.score) ||
  urgency.score < 0 ||
  urgency.score > 2 ||
  refund?.type !== 'noul' ||
  !Number.isFinite(refund.noul) ||
  refund.noul < 0 ||
  refund.noul > 1
) {
  throw new Error('Unexpected decision output; send this case for review.');
}

console.log({ answers, creditsUsed: body.data.creditsUsed });

指定した質問IDをキーとして、data.result.answersから回答を読み取ります。HTTPの成功とcode === 0の両方を確認してください。使用前に、返された型、ラベル、数値の範囲を検証します。この例は結果を表示するだけです。エラーになったケースを人の確認キューへ送る処理は、アプリケーションで実装する必要があります。

レスポンスには、data.result内のトークン使用量と処理時間、data.creditsUsedの実際の消費クレジットも含まれます。サンプル応答の時間や料金は、その後のリクエストへの保証ではありません。サーバー側が報告する経過時間とは別に、クライアント側のエンドツーエンドの遅延も記録してください。

制限、エラー、クレジットに対応する

確認時点で、このホスト型エンドポイントは最大32 KiBのUTF-8 JSONボディと、一回につき1–8問を受け付けます。Choiceの選択肢は2–100個、Scoreの順序付き説明は2–10個です。ログイン済みのプレイグラウンドからの呼び出しには、最低3秒の間隔が必要です。このルールをAPIキー全般の共通レート制限として扱わないでください。

推論リクエストのタイムアウトは30秒です。クライアントには通信と完全なレスポンス受信のために追加の時間が必要です。ただし、クライアント側のタイムアウトを長くしても、サービス自身の推論制限は延びません。

HTTPステータス 意味 適切な対応
400 無効なリクエスト フィールドや判断基準を修正する
401 認証失敗 サーバー側のキーを確認する
402 クレジット不足 十分な残高を確保する
413 リクエストボディが大きすぎる 文脈を短くするか処理を分割する
429 リクエストの間隔が短すぎる Retry-Afterがあれば従う
502 推論失敗、または無効なデータが返された 原因を調べてから再試行を判断する
503 サービスを利用できない フォールバックするか後で試す

このエンドポイントには、冪等性キーが文書化されていません。クライアントがタイムアウトしても、最初のリクエストが完了して課金される場合があります。無条件の再試行は、重複処理や重複課金につながりかねません。ローカルのジョブ状態を保存し、可能な範囲で結果を照合して、再試行するかを明示的に決めてください。

リクエストのサイズとモデルのコンテキストも区別します。32 KiBのHTTP制限を満たしていても、すべての文や選択肢がチェックポイントのトークン予算内に収まるとは限りません。長い入力や多数のラベルは、個別にテストしてください。

自動化の前に判断を評価する

混同行列、確率校正プロット、選択的リスク曲線を描いた数学スケッチで、実測ベンチマークではなく概念図

実際の業務から適切に取り扱ったサンプルを集め、評価セットを作成します。しきい値の調整用データと、最終テストセットは分けてください。関連するメッセージは同じ分割先にまとめ、よく似たチケットが訓練、検証、テストの間で漏れないようにします。

出力は、その影響に合わせて評価します。振り分けには混同行列とクラス別の適合率・再現率を確認します。緊急度では平均誤差だけでなく、重大な過小評価も数えます。返金要求の検出では、明示的な要求、否定、仮定の議論、引用されたメッセージをテストしてください。

確率校正は別途確認する必要があります。近い確率を返した予測をまとめ、実際に起きた頻度と比較します。0.8程度の確信度を返す予測が半分しか正しくないなら、その数値に基づくしきい値は見かけの意味と違う挙動をします。校正の調整を行う際も、最終テストセットを使用してはいけません。

上流のモデルカードには、過度な確信度やラベル用トークン予算への敏感さなど、重要な制約が記載されています。また、選択肢のラベルが入力内容よりも強く答えに影響するnoulの失敗例も説明されています。二択の出力が固定されているように見える場合は、対照的な例で調べ、二つの選択肢を持つchoiceの書き方と比較してください。測定せずに、この回避策が有効だと決めつけないことが大切です。

判断の保留にはトレードオフがあります。カバレッジは自動処理するケースの割合、選択的誤り率はその自動処理した集合内の誤り率です。しきい値を高くすると、自動化の割合が下がり、確認待ちのキューが増える可能性があります。簡単なケースだけを残した小さな集合の正解率を強調するのではなく、両方の指標と確認作業量を報告してください。

単純なベースラインも用意します。明確な障害コードに対する決定的なルールや、既存の振り分け分類器が、一部のケースを低コストですでに解決できるかもしれません。同じ入力と結果の定義を使って、Layaをそのベースラインと比較します。代表的な失敗と原因を短いログに残し、質問、提供する証拠、チェックポイント、しきい値のうち一つずつ変更してください。改善の理由を説明でき、見栄えのよいデモになるまで調整するだけの状態を避けやすくなります。

有用なワークフローを段階的に導入する

ラベル付け、シャドー評価、人による確認、制御された自動化へ進むLayaワークフローの数学ノート風スケッチ

最初はシャドーモードで運用します。推奨結果を記録しつつ、実際の結果は既存のワークフローで決めます。モデルの判断を人による処理結果と比較し、不一致が集中するケースを調べてください。繰り返される誤りは、不明確なラベル、文脈不足、言語の不一致、モデルの不適合を示す場合があります。

次に、実行前にスタッフが推奨結果を確認します。これにより、確認にかかる費用、スコアのわかりやすさ、提案された振り分けが本当に時間を節約するかを把握できます。実測した誤り率と運用上の利点が見合うと判断できてから、範囲が狭く取り消し可能な操作を自動化します。

サポート業務で試験導入する場合は、開始前に成功基準を定めます。許容する誤振り分け、重大な緊急案件の見逃しの上限、確認に使える人員、サービス障害時の代替手段を明確にしてください。元の振り分け経路に戻せる簡単なスイッチも用意します。確認担当者が、基礎となるポリシーを知らないうちに変更することなくラベルを修正でき、その修正が次回の評価データに反映されるようにします。

失敗を再現できるだけのメタデータを記録します。独自のリクエストID、スキーマのバージョン、指定したモデル識別子、取得できる提供側のバージョン情報、遅延、料金、最終結果などです。顧客の内容は必要最小限の保存にとどめてください。入力言語、ラベル頻度、確認件数の変化を追うと、全体の正解率より先にドリフトを発見できる場合があります。

経済性はワークフロー全体で比較します。ホスト型のクレジット、自前の計算資源、技術的な保守、人による確認、誤操作のすべてが費用に影響します。導入方式の幅広い比較は、JevとLayaの比較も参考になります。自分の評価結果と運用上の制約に合った構成を選んでください。

Laya AI、モデル、APIのよくある質問

Laya AIはチャットボットですか

中心となる用途は、範囲を定めた判断です。選択、評価、分類に使用し、自由な文章が必要な場合は生成モデルを使用します。アプリケーションで両方を組み合わせることもできます。

Layaモデルは無料ですか

公開された重みはApache-2.0ライセンスです。ただし、実行には計算資源と運用の手間がかかります。この記事で紹介するホスト型サービスはアカウントのクレジットを消費するため、公開された重みと無料のホスト型リクエストを混同しないでください。

Laya APIはチェックポイントを自動選択しますか

このサイトのAPIでは、モデル識別子を明示的に指定します。上流のローカルSDKにはルーターがありますが、その動作や設定がすべてのホスト型サービスに当てはまるとは限りません。

Layaの確率を操作の承認に使えますか

確率はポリシーの判断材料になりますが、権限を付与したり、入力にない事実を確認したりするものではありません。影響のある操作には、アプリケーション側のチェックと適切な確認プロセスを設けてください。

ローカル推論とホスト型APIのどちらから始めるべきですか

リクエストの仕様やワークフローを試すなら、ホスト型インターフェースを使えます。特定のチェックポイントの実験やインフラの管理が必要なら、バージョンを固定したローカル推論を使います。どちらも同じ代表的なケースで評価してください。

出典と更新時の確認

Layaの上流リポジトリには、インストール、ルーティング、サービスの提供方法、実行時オプションが記載されています。Convai Innovationsのモデルカードでは、チェックポイント、構造、評価、既知の制約を説明しています。ホスト型リクエストの詳細は、上でリンクした二つのサイト内ガイドと、このプロジェクトのエンドポイント実装に照らして、2026年9月28日に確認しました。

導入前に、推論バックエンド、制限、モデルのリビジョンを再確認してください。重要な判断を一つ選び、実際のサンプルで測定し、その結果に根拠があるときに自動化の範囲を広げていきます。

© 2026 Jev AI Journalホームに戻る