よくある質問
自動翻訳された記事です。 英語の原文を表示.
よくある質問
APIの使用状況とエンドポイントの詳細はどこで確認できますか?
詳細については、ドキュメントのAPIエンドポイントセクションをご参照ください。
必要なネットワーク設定と証明書は何ですか?
認証はtoken-basedです。ホスト名の詳細およびAPIの使用方法については、ドキュメントをご確認ください。
例:
curl -X POST 'https://api.elsanow.io/api/v1/score_audio_plus' \
-H 'Content-Type: multipart/form-data' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
-F 'api_plan="premium"' \
-F 'return_json="true"' \
-F 'audio_file=@"/path/to/file"'
その他の例については、ドキュメントのAPIセクションをご覧ください。
APIキーまたはトークンの取得方法と使用方法を教えてください。
API tokenは、NDA締結後に弊社が発行します。締結が完了しましたら、その旨をご連絡ください。トークンをご提供いたします。使用方法はドキュメントに記載されています。
APIリクエストとレスポンスの構造および制限は何ですか?
parameters(パラメーター)やlimitations(制限)を含む、リクエストおよびレスポンスの詳細な構造については、APIドキュメントをご確認ください。
サンドボックスは利用可能ですか?テストアカウントは必要ですか?
現在、staging環境はご提供しておりません。
モニタリングとデバッグのためのダッシュボードやログはありますか?
リクエストとアクティビティの可視性を提供するためのcustomer-facingダッシュボードが利用可能です。このRetoolベースのインターフェースにより、スクリプトあり・なし両方のAPIコールの使用状況を追跡できます。
弊社のAPIはRAGソリューションに対応していますか、または統合できますか?
弊社のAPIはネイティブでRAG(Retrieval-Augmented Generation)ソリューションを実装していませんが、RAGワークフローへの統合は十分に可能です。弊社のサービスは音声ストリーム分析に特化しており、その出力はRAGシステムや、音声から得られた豊富なコンテキストを活用するその他のパイプラインへの入力として使用できます。より適切な回答または最適な統合アプローチを提案するために、お客様の意図するユースケースまたはアーキテクチャの詳細をお知らせください。
AIスピーキング機能をスムーズに利用するために必要な帯域幅はどれくらいですか?
現時点では、帯域幅に関する要件はAPIドキュメントに記載されているものに限ります。これらはAIスピーキング機能の使用方法や統合方法に関わらず適用されます。具体的なユースケースについて詳しくお知らせいただければ、より正確なご提案が可能です。
各チャンクがどのIPアドレスから送信されたかを特定することはできますか?
現時点では、IPアドレスなど、APIリクエストの送信元に関する情報は保持しておりません。そのため、各チャンクがどのIPから送信されたかを特定することはできません。弊社のログはサービス機能に関連するリクエストメタデータに焦点を当てており、origin-levelのネットワーク詳細は含まれておりません。
"utterance"レスポンスセクションのパラメーターは何ですか?
utteranceレスポンスセクションのパラメーターは以下のとおりです:
nativeness_score: ユーザーが発話全体で達成したネイティブネススコア(0〜100のスケール)。
nativeness_score_partial: ユーザーが実際に発音した単語のサブセットにおけるネイティブネスを反映したスコアで、最低スコアは
25%です。decision:
nativeness_scoreに基づいた、発話の発音に関するユーザーの習熟度を示す文字列。設定可能な値:correct、almost_correct、またはincorrect。
注意: nativeness_scoreは発話内のすべての単語(ユーザーが発音しなかった単語を含む)を考慮するのに対し、nativeness_score_partialはユーザーが実際に発話した単語のみに焦点を当てます(スコアが低い場合でも)。
例: 発話が「Hello ELSA」で、ユーザーが「Hello」のみを言った場合、nativeness_score_partialは「Hello」のスコアのみを考慮します(25%を超えると仮定)。一方、nativeness_scoreは発話されなかった単語(例:「ELSA」、スコアが低いまたはゼロ)を含むすべての単語を考慮します。
詳細については、APIドキュメントをご参照ください。
"words"レスポンスセクションのパラメーターは何ですか?
wordsレスポンスセクションのパラメーターは以下のとおりです:
nativeness_score: 個々の単語の発音に対するネイティブネススコア(
0〜100)。decision:
nativeness_scoreに基づいた習熟度評価。設定可能な値はcorrect、almost_correct、またはincorrect。
詳細については、APIドキュメントをご参照ください。
"word_stress"レスポンスセクションのパラメーターは何ですか?
word_stressレスポンスセクションのパラメーターは以下のとおりです:
- decision: ユーザーが音節を正しくストレスしたかどうかを示します。設定可能な値は
correctまたはincorrect。
詳細については、APIドキュメントをご参照ください。
"phonemes"レスポンスセクションのパラメーターは何ですか?
phonemesレスポンスセクションのパラメーターは以下のとおりです:
nativeness_score: このエントリの音素に対するスコア(
0〜100スケール)。decision: 音素の発音の正確さを示します。設定可能な値は
correct、warning、またはerror。
詳細については、APIドキュメントをご参照ください。
チャンク計算の仕組み
チャンクの長さは15秒です。ただし、実際の_チャンク_数は以下の式で計算されます:
num_chunks = ceil(duration / chunk_size)
たとえば、17秒の音声入力は、切り上げ演算により2チャンク(1.13ではなく)となります。
さらに:
合計時間がAPIの最大許容時間をわずかに超える場合、制限内に収まるようにトリミングされます。これにより、数フレームの超過が原因で2回目のリクエストが発生することを防ぎます。
また、該当する場合は音声の先頭または末尾から無音・ノイズをトリミングするため、最終的なチャンク数がさらに変わることがあります。
これらの要因により、num_standard_chunksが必ずしもnum_secs / 15と正確に一致しない場合があります。
スピーチアナライザーはどのように文法ミスを検出しますか?
弊社は文法エラーを検出しますが、文脈において高い確信度がある場合のみ修正を提案します。具体的には、提案された修正の信頼スコアが少なくとも80%以上の場合にのみ適用されます。このアプローチにより、文法的な曖昧さがある場合に不適切な変更を提案することを避けられます。
音声ファイルのアップロード上限は何ですか?
バイト数
アップロード可能な最大ファイルサイズは100MBです。この制限を超えるファイルをアップロードする必要がある場合は、サポートチームまでお問い合わせください。
分数
syncフラグをTrueに設定した非スクリプトリクエストのアップロード可能な最大音声ファイル長は15分です。
スクリプトあり: 制限なし
スクリプトなし:
sync = True => 15分
sync = False => 12分
発音スコアとイントネーションスコアは関連していますか?
pronunciation_scoreとintonation_scoreの間に直接的な依存関係はありません。ただし、intonation_scoreは通常、完全な文など長い入力に対してのみ計算されます。そのため、絶対的な初心者で非常に短い、または不完全な発話をする傾向があるユーザーはintonation_scoreを受け取れない場合があります。これは関係性があるように見えるかもしれませんが、スコア間の依存関係というよりも、入力の長さと品質を反映したものです。
発音とイントネーションの判定はどのように評価されますか?
これらの判定属性は、対応するCEFR-levelスコア(例:pronunciation_cefr、intonation_cefr)に基づいています。マッピングの例は以下のとおりです:
Correct: CEFRレベル C1 または C2
Warning: CEFRレベル B1 または B2
Incorrect: CEFRレベル A1 または A2
非スクリプトAPIコールでEPSスコアやトランスクリプトが欠けているのはなぜですか?
指標付きの結果を得るには、音声の長さが20秒を超えていることを確認してください。
発音レベルは米国/英国のネイティブアクセントにマッピングされていますか?
弊社はグローバルスタンダード(CEFT、IELTS、TOEFL)に準拠しており、話者のネイティブアクセントに対してペナルティを与えるのではなく、スピーチの明瞭さに焦点を当てています。アクセントが強いユーザーに対してわずかな差異が生じる場合がありますが、通常は同じバンド内に収まります。
非スクリプトAPIの結果に文法・語彙の指標がない理由は何ですか?
これらの指標には最低閾値があります。この最低閾値にもかかわらず非スクリプトAPIで文法・語彙の指標の結果を取得したい場合は、フラグ-F force_grammar_vocab=Trueを追加してください。ただし、これらの結果は最低閾値を満たした場合の結果と比べて精度が低い場合があります。
説明可能性についてどのような標準を使用していますか?
弊社のモデルは独自のものであり、正確なアーキテクチャや内部メカニズムを開示することはありません。出力品質とパフォーマンスベンチマークの透明性を優先していますが、現時点ではモデルの説明可能性に関する公開標準には準拠しておりません。
総合スコアはどのように計算されますか?
総合スコアは、pronunciation(発音)、intonation(イントネーション)、fluency(流暢さ)、grammar(文法)、vocabulary(語彙)の5つの指標を組み合わせたものです。録音が短いために語彙や文法スコアを提供できない場合でも、他の利用可能な指標に基づいて総合スコアを提供できることがあります。
スコアはどのように計算されますか?
ELSA Scoreの計算方法とIELTSへのマッピングは社内で独自に開発されています。ELSAスコアを計算するパラメーターは時間とともに変わる可能性があり、IELTSへのマッピングも同様です。弊社は定期的にこれを再評価し、わずかに調整しています。
文法スコアにおける文法の範囲とエラーの重み付けはどのようになっていますか?
これらの側面の比率は録音の種類によって異なります。カジュアルなスピーチの場合、おおよそ文法エラーが60%、文法の範囲が40%です。試験のような設定では、おおよそ文法エラーが50%、文法の範囲が50%です。これらの数値は新しいデータが得られた際に調整されることをご注意ください。
発音スコアはどのように計算されますか?
発音スコアは、録音内でELSAが認識した各単語における英語の音の正確さに基づいています。ハイライトされた_誤発音_の数と重大度が発音スコアに影響します。
流暢さスコアはどのように計算されますか?
流暢さスコアは、Pace(ペース)、Pausing(ポーズ)、Hesitations(ためらい)のパフォーマンスを組み合わせたものです。適切なペースを維持し、自然な場所でのみポーズを取り、フィラーワードや繰り返しを減らすことが、良い流暢さスコアにつながります。
イントネーションスコアはどのように計算されますか?
intonation(イントネーション)スコアは、ピッチの上昇と下降、および文中の単語に対する強調の適切さを考慮します。
語彙スコアはどのように計算されますか?
Vocabulary(語彙)スコアは、主にユーザーのスピーチに含まれる単語や表現の推定CEFR levelsに基づいています。
注意: rawなCEFR分布はフィードバックとして出力されます(各A1-C2レベルの単語の割合)が、総合スコアはこの分布を0-100の値にマッピングする統計アルゴリズムによって計算されます(100%はネイティブに近い語彙使用に相当)。vocabularyスコアは、テキストが(現在)75語以上の場合にのみ返されます。
文法スコアはどのように計算されますか?
grammar(文法)スコアは、文法的エラー検出・修正モジュールの出力と、特定された文法の範囲を組み合わせて計算されます。文法的エラー検出・修正はテキスト内の文法エラーを特定し、エラースコアを出力します。文法範囲モジュールはすべての文法構造を特定し、録音内で正常に使用された上位5つの高レベル構造に基づいて範囲スコアを計算します。grammarスコアは、テキストが(現在)50語以上の場合にのみ返されます。
トレーニングデータの量と多様性はどのくらいですか?
弊社のモデルの実装の詳細や内部構造は開示しておりませんが、出力が解釈可能でユーザーの期待に沿ったものであることを保証することを重視しています。必要に応じて、エンドユーザーにとって透明で実用的な方法でモデルの評価ロジックを反映したscore breakdowns(スコアの内訳)やcategory-level(カテゴリーレベル)のフィードバックを提供しています。社内では、モデルの判断における一貫性と公平性を確保するために、堅牢な検証プラクティスとパフォーマンスのベンチマークを実施しています。
モデルの精度はどのくらいで、どのくらいの頻度で再トレーニングされますか?
これまで詳細な精度数値を公開したことはありません。弊社では通常、内部ベンチマークに基づいてモデルが競合他社よりも優れたパフォーマンスを発揮することをお伝えしてきました。model retraining frequency(モデルの再トレーニング頻度)については、モデルによって大きく異なります。一部のモデルは長期間変更されていませんが、弊社の全体的なアプローチとして、ユーザーデータを収集し(where permitted)、モデルのパフォーマンスを継続的に改善することを一貫して進めています。
バイアスや差別のリスクは何ですか?
ELSA's AIはnon-native(非ネイティブ)英語話者をサポートするために専門的に構築されています。実際の第二言語(L2)話者から収集された何千時間ものアクセントのある英語でトレーニングすることにより、ELSAは学習者の発音の課題を認識し対処するために独自のポジションにあります。このインクルーシブなアプローチはアクセントバイアスを軽減し、学習者が初日から認められ、サポートされ、力を与えられていると感じられるようにします。
モデルにおける「イントネーション」の重み付けはどのくらいで、倫理的にはどのように対処されていますか?
コンテンツがscripted(スクリプトあり)であるかunscripted(スクリプトなし)であるかに関わらず、検出率はおおよそ20%です。
このethically(倫理的)な対処に関する質問については、個人の発話パターンの検出可能性や音声スプーフィングのリスクに関する懸念が関連している可能性があります。
明確にしておくと: 弊社の音声およびイントネーション分析システムは、ユーザーの声の識別可能な特性に対してagnostic(無関係)になるよう設計されています。弊社は話者識別を行わず、そのような目的で音声データを使用することもありません。弊社は言語学習の文脈における発音とプロソディの評価のみに焦点を当てています。
APIサービスの使用状況はどのように追跡されますか?
Retoolを通じた使用状況追跡ダッシュボードを提供しており、日々のAPI消費全体の可視性を提供しています。これには、characters processed(処理された文字数)、request counts(リクエスト数、scriptedとunscriptedの使用状況別)、plan tier(プランティア)、processing time(処理時間)、number of chunks(チャンク数)、number of ASR requests(ASRリクエスト数)などの指標が含まれます。さらに、各リクエストのtier(ティア)、audio length(音声の長さ)、transcribed text(書き起こしテキスト)を含む詳細なper-request view(リクエストごとのビュー)も提供しています。このダッシュボードは使用状況の監視と管理のための信頼性の高い手段として活用できます。
短い音声に文法・語彙スコアがないのはなぜですか?
短い音声の場合、文法・語彙スコアが生成されないことがあるのは仕様通りです。弊社のシステムでは、信頼性の高い意味のある結果を生成するために、通常、文法評価には最低50語、語彙分析には75語が必要です。
最良の結果を得るために、より長い音声サンプルの提出をお勧めします。これにより、スコアリングエンジンがパターンを分析し、より包括的なフィードバックを提供できます。
スコアはどのようにマッピングされますか?
CEFRIELTSTOEFLスピーキングPTE範囲A11.50-110-10A122-310-10A12.54-510-10A236-710-11A23.58-912-15B1410-1116-19B14.512-2320-25B1514-1526-31B25.516-1732-40B2618-1941-50B26.520-2251-60C1723-2361-70C17.524-2571-79C1826-2780-86C28.528-2987-89C2930-3090-90
参考資料:
リクエストがブロックされた(403 Forbidden)のはなぜですか?
リクエストはCloudflareのManaged Rulesetによってトリガーされた1つ以上のセキュリティチェックによりブロックされた可能性があります。これらのルールは、実際には無害なリクエストであっても、潜在的に悪意のある、または不審なトラフィックを検出・防止するために設計されています。リクエストがブロックされる一般的な理由には以下のものがあります:
不審なファイル名または拡張子: 例えば、".php"、".asp"、またはその他の実行可能形式で終わるファイルは、エクスプロイトの試みによく使用されるため、アップロードまたはリクエスト内で参照される際にブロックされることがよくあります。
異常なヘッダーまたはペイロード: リクエストボディまたはヘッダーに予期しないコンテンツ(例:コードインジェクションパターンや不正なデータ)が含まれている場合、Cloudflareが不審とみなすことがあります。
既知のエクスプロイトシグネチャに一致するパラメーター: 例えば、リクエストが以下のような既知の脆弱性に一致する場合があります:
CVE-2018-9206: jQuery File Uploadプラグインのエクスプロイト。
CVE-2019-17132: Bulletinリモートコード実行の脆弱性。
これらのCVEがお客様のシステムに直接影響していない場合でも、構造や命名の類似性によりリクエストが予防的にブロックされることがあります。Cloudflareのアプローチは安全側に倒すことであり、偽陽性であっても既知の攻撃パターンやヒューリスティックに一致するリクエストをブロックすることでセキュリティを優先しています。
解決するには:
リクエストの詳細(メソッド、ヘッダー、ボディ、URL)を弊社と共有していただければ、具体的にどのルールがトリガーされたかを分析できます。
リクエストが正当で期待される動作である場合、お客様のアカウントに対して安全に例外ルールを作成するか、セキュリティレベルを変更することを検討できます。
この記事は役に立ちましたか?
または、画面隅のチャットで続けて質問できます。