アクセントの表現、固有表現の誤り、公平性のばらつき、修正作業量を評価する、盲検化された条件一致の方法。

HiNoterアクセント・ベンチマーク・グループ執筆 · 編集ステータス：内部の構成および証拠範囲のQA完了；公開前に適格な法務レビューが必要 · 2026-08-31公開・更新 · 米国／国際英語版

定義された言語変種、部屋、マイク、タスク、誤りのしきい値がなければ、アクセントに対する普遍的に最良のAI文字起こしは存在しません。ワークフロー内のアクセントを代表する人々が同じ内容を話す、盲検化された条件一致テストを使用してください。名前、数字、発話の切り替わり、欠落、修正作業量を採点し、単一の勝者ではなくばらつきを報告します。話者に公平性を確認してもらい、1人の声をコミュニティ全体の代理として使用しないでください。「アクセントに最適なAI文字起こし」には、次の判断基準を使用します：代表的なアクセントで同じ台本を録音し、ツールの順序をランダム化し、レビュー担当者からシステムの身元を隠し、人による修正経路を伴う条件別の結果を公開すること。

アクセントの品質は、人々と条件が明らかになって初めて比較の問題になります。次の編集者が作成したシナリオを考えてみてください：分散型チームが見出しのスコアを基にツールを選び、後になって、2人の地域担当の同僚が話した顧客名が繰り返し書き換えられていることに気づきます。顧客、従業員、候補者、患者、クライアント、参加者のデータは一切含まれていません。この場面が有用なのは、「どのAI文字起こしツールがアクセントを最もうまく処理するのか」という問いを、整ったデモから引き出し、責任の所在、権限、証拠、復旧を検証できる判断へと移すためです。

このガイドでは証拠の階層を使用します。「公式」とは、ファーストパーティのプラットフォーム、規制当局、法令、またはプロバイダーのページが、限定的な機能や義務を説明していることを意味します。「観測済み」とは、権限を持つレビュー担当者が、日付のある環境で挙動を再現したことを意味します。「編集上の解釈」とは、1つのアクセントを標準として扱わずに文字起こしツールを比較する多言語・分散型チームのために、執筆者がそれらの資料を解釈したものを意味します。テストされていない機能はN/Aのままにします。

この記事を形作る結論は次のとおりです：標準的でないアクセントは、狭いベンチマークを基準に評価されることが多いため、洗練された平均値によって、特定の話者や単語に対する体系的な誤りが隠される可能性があります。したがって、実務上の基準は意図的に保守的です：代表的なアクセントで同じ台本を録音し、ツールの順序をランダム化し、レビュー担当者からシステムの身元を隠し、人による修正経路を伴う条件別の結果を公開すること。これはこのユースケースのためのレビュー方法であり、普遍的な製品声明ではありません。

アクセントに最適なAI文字起こしは、明確なユースケースから始まる

静かなポッドキャストで勝者となるツールが、テンポの速い顧客通話では失敗することがあります。

盲検テストの注記：「代表性」を受け入れ項目として使用します。合格とは、話者が実際のユースケースを反映していることです。これは、1つのアクセントを標準として扱わずに文字起こしツールを比較する多言語・分散型チームにとって、カテゴリー全体が機能するという広範な声明よりも有用です。話者に自分の出力を確認してもらい、その修正を盲検スコアと比較してください。

この現場ケースにルールを当てはめてください：チームは話者、デバイス、結果を明示せずに見出しのスコアを比較します。最も近いパターンは「現場チーム」で、優先事項は地域の発話、人間による境界条件はノイズを含めることです。「1つのアクセントを全体の代表にする」を重大な失敗として扱います。直ちに明らかになるリスクは明確です：1つのアクセントを全体の代表にすること。説明責任を負う担当者は、復旧がまだ実行可能なうちにそれを確認する必要があります。アクセント・ベンチマークの例は、どの仮定が最初に崩れ、誰がなお対応する権限を持っているかを示します。

実務上の対応は、テスト前に目標条件を書くことです。盲検テストのログには、話者の代表性、台本、ツールの順序、固有表現の誤り、発話の切り替わりの結果、レビュー担当者の時間、公平性に関する注記を記録します。このアクセント・ベンチマークの確認では、別のレビュー担当者が観測を再現できるだけの情報のみを残してください。文書を公式、再現された挙動を観測済み、解釈を編集上の解釈として分類します。経路が失敗した場合は、元の音声を保管し、話者に詳しい人間のレビュー担当者を加え、承認された発音または語彙の補助を使用します。これにより、アクセントに最適なAI文字起こしについての限定された知見が得られ、普遍的な約束にはなりません。

アクセント評価の証拠メモ： 関連するポリシー、プラットフォームの管理策、または機能に依拠する前に、最新の NIST — AIリスク管理フレームワーク ページを確認してください。

ブラインドテストで比較を守る

レビュアーは、無意識のうちに、なじみのあるブランドや予想された結果を高く評価することがあります。

「ブラインドテストで比較を守る」という判断は、「盲検性」にかかっています。基準は具体的です。レビュアーはツールの識別情報を知りません。多言語・分散チームが、特定のアクセントを標準扱いせずに文字起こしツールを比較する場合、有用な問いは、インターフェースに安心感があるかどうかではありません。明示された条件下で、同僚が同じ証拠を再現できるかどうかです。観察も記録もされていないものは、すべてN/Aのままにします。

ここでラベルではなく場面を確認します。誰も言葉を確認する前に、洗練されたインターフェースが高い評価を受けています。それは「社内スタンドアップ」に似ており、直ちに懸念されるのは素早い応答で、レビューの境界はレイテンシーの測定です。証拠によって「ブランドへの期待がスコアを変える」ことが示されたなら、その結果を通常のものとして扱うのをやめます。この判断では、安心感のあるインターフェースや洗練された成果物よりも、「ブランドへの期待がスコアを変える」ことを重視します。記録を超えてしまう優雅な説明より、限定的な再現のほうが安全です。

このセクションでのアクション：システムの識別情報を隠し、出力順をランダム化します。ブラインドテストのログには、話者の構成、スクリプト、ツールの順序、エンティティの誤り、ターンごとの結果、レビュアーの所要時間、公平性に関するメモを記録します。テストは機微なものにせず、結果に影響した状態を保持し、無関係な個人情報は破棄します。証拠の連鎖が終われば、主張も終わります。運用上の代替策は、元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合に発音または語彙の補助ツールを使用することです。

アクセント評価の証拠メモ： 関連するポリシー、プラットフォームの管理策、または機能に依拠する前に、最新の 米国連邦取引委員会 — FTC、不正なAIの主張や企てに対する取り締まりを発表 ページを確認してください。

名前と数字が本当の差を明らかにする

重要なエンティティは、通常の文章よりも早くアクセントの偏りを明らかにすることがよくあります。

どのような証拠が判断を変えるでしょうか。まず「エンティティ」から始めます。結果が合格するのは、名前と数字が採点されている場合だけです。この枠組みにより、「名前と数字が本当の差を明らかにする」は、特定のアクセントを標準扱いせずに多言語・分散チームが文字起こしツールを比較するための、観察可能な作業に結びついたままになります。セクションを機能の称賛に変えてはいけません。不明点は、より小規模なテストを行うきっかけであり、推測する許可ではありません。

反例は実務的です。ある話者のすべての出力で、2つの顧客の姓が変更されています。これは「カスタマーサポート」のケースとして読み取ります。証拠の対象は名前とアカウント用語で、人間によるチェックポイントはエンティティの採点です。停止条件は「一般的な単語だけが数えられる」です。管理策が機能しなければ、実務上の結果は「一般的な単語だけが数えられる」です。これは脚注ではなく、運用上の判断に含めるべきものです。出力の残りが滑らかに読める場合でも、その結果は重要です。

結論を公開する前に、エンティティと訂正を別々に採点します。ブラインドテストのログには、話者の構成、スクリプト、ツールの順序、エンティティの誤り、ターンごとの結果、レビュアーの所要時間、公平性に関するメモを記録します。公式ページが述べていること、チームが再現したこと、編集者が推測したことを分けます。このアクセント評価テストを完了できない場合は、N/Aを使用し、復旧手順に従います。元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合に発音または語彙の補助ツールを使用します。

アクセント評価の証拠メモ： 関連するポリシー、プラットフォームの管理策、または機能に依拠する前に、最新の W3C — ウェブコンテンツ・アクセシビリティ・ガイドライン（WCAG）2.2 ページを確認してください。

アクセントの文字起こしをブラインド比較する

差を公開する

ワークフローのしきい値を決め、例外については元の音声と人間によるレビューを維持します。採用、範囲縮小、再テスト、または却下で終えます。主経路が失敗した場合は、元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合に発音または語彙の補助ツールを使用します。

話者にレビューを依頼する

テストで代表された人々に、 unfairまたは誤解を招く誤りを指摘してもらいます。証拠が不足している場合はN/Aと記し、責任者を明記し、不明点を有利なスコアに変換しないでください。

重大な誤りを採点する

話者ごとに、単語、エンティティ、話者、レイテンシー、省略、訂正の結果を記録します。全体的な流暢さや見た目の洗練度で判断せず、書面による期待値と結果を比較します。

ツールをランダム化する

ツールの識別情報を隠し、各システムで同じ順序、音量、ファイルを使用します。意図的に機微でないサンプルを使い、承認されたプロセスで削除が求められる場合はテスト成果物を削除します。

対応するスクリプトを書く

名前、数字、専門用語、質問、否定表現、自然なターンの変化を含めます。結論を変える場合に限り、アカウント、主催者との関係、プラットフォーム、会議の種類、設定、日付、レビュアーを記録します。

対象範囲のアクセントを定義する

重要な言語、地域的な変種、話者、デバイス、会議条件を明記します。対象範囲として、次の架空のテストパターンを使用します。分散チームが見出しのスコアからツールを選び、後になって、2人の地域担当同僚が話した顧客名が繰り返し書き換えられていることに気づきます。

ターンテイキングもアクセント対応の一部

文字起こしは単語を正しく表記できても、それを話した人々を一つにまとめてしまうことがあります。

ブラインドテストのメモ：「ターンテイキング」を受け入れ項目として使用します。合格とは、話者の交代が実用可能な状態に保たれることです。これは、特定のアクセントを標準扱いせずに多言語・分散チームが文字起こしツールを比較する場合、カテゴリが機能するという広範な説明よりも有用です。話者自身に出力を確認してもらい、訂正内容をブラインドスコアと比較します。

この現場ケースにルールを当てはめます。同僚間の短い引き継ぎが、匿名の一つの段落になっています。最も近いパターンは「経営層向けブリーフィング」で、優先事項は結果であり、人間による境界はレビュアーの承認を必須にすることです。「一人の声が統合される」を重大な失敗として扱います。「一人の声が統合される」をエスカレーションのトリガーとして扱います。それによって、誰が対応すべきか、通常の経路を継続すべきかが変わります。アクセント評価の例は、どの前提が最初に崩れ、誰がなお対応する権限を持つのかを示します。

実務上は、話者の交代と割り込みをテストします。ブラインドテストのログには、話者の構成、スクリプト、ツールの順序、エンティティの誤り、ターンごとの結果、レビュアーの所要時間、公平性に関するメモを記録します。このアクセント評価では、別のレビュアーが観察を再現するのに十分な情報だけを保持します。文書を、公式、再現された観察結果、編集上の解釈に分類します。経路が失敗した場合は、元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合に発音または語彙の補助ツールを使用します。これは、アクセントに最適なAI文字起こしについての限定された知見を支えるものであり、普遍的な約束ではありません。

アクセント評価の証拠メモ： 関連するポリシー、プラットフォームの管理策、または機能に依拠する前に、最新の Microsoft Learn — Teams会議の文字起こしと字幕を構成する ページを確認してください。

会議ワークフローガイド に進むか、 AIノートテイカーのトピックライブラリを確認してください。

公平性とはばらつきを報告すること

平均値が良好に見えても、修正作業の大部分を一つのサブグループが担っていることがあります。

「公平性とは分布のばらつきを報告すること」という判断は、「公平性」にかかっています。基準は具体的です。話者ごとの誤りのばらつきが報告されていること。多言語・分散型チームが、1つのアクセントを標準として扱わずに文字起こしツールを比較する場合、役立つ問いは、インターフェースが安心感を与えるかどうかではありません。提示された条件のもとで、同僚が同じ証拠を再現できるかどうかです。観察または記録されていないものは、N/Aのままにします。

次に、ラベルではなく状況を検討します。小規模な地域サンプルを無視すると、全体スコアが改善します。これは「フィールドチーム」に似ており、地域の発話が当面の懸念で、「ノイズを含める」がレビューの境界です。証拠によって「平均値がサブグループを隠している」ことが示されたら、その結果を通常のものとして扱うのをやめます。どれほど滑らかな出力でも、この結果を埋め合わせることはできません。平均値がサブグループを隠しているのです。証拠の境界はすでに越えられています。記録を超えてしまう洗練された説明よりも、狭い範囲での再構成のほうが安全です。

このセクションでのアクション：話者ごと、条件ごとの結果を公開します。ブラインドテストのログには、話者の代表性、スクリプト、ツールの順序、エンティティの誤り、ターンの結果、レビュアーの所要時間、公平性に関する注記を記録します。テストは機微情報を含まないものにし、結果に影響した状態を保持し、無関係な個人情報は破棄します。証拠の連鎖が終われば、主張も終わります。運用上のフォールバックは、元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合に発音または語彙の補助を使用することです。

アクセントベンチマークの証拠メモ： 関連するポリシー、プラットフォームの制御、または機能を信頼する前に、現在の Google Meet ヘルプ — ビデオ会議を録画 ページを確認してください。

修正作業は製品コストである

スコアが良くても、常に修正が必要なツールは最適とは限りません。

どのような証拠があれば判断は変わるでしょうか。まず「修正」から始めます。結果が合格となるのは、人間の作業量とソースへのアクセスが測定された場合だけです。この枠組みにより、「修正作業は製品コストである」という考えが、1つのアクセントを標準として扱わずに文字起こしツールを比較する多言語・分散型チームにとって、機能を称賛するセクションではなく、観察可能な作業に結びつきます。不明な点は小規模なテストを行うためのきっかけであり、推測してよいという許可ではありません。

反例は実際的なものです。レビュアーが会議を読むよりも名前の修正に長い時間を費やします。これを「社内スタンドアップ」のケースとして読みます。証拠の対象は迅速なターンで、人間によるチェックポイントは遅延の測定です。停止条件は「勝者には終わりのない修正が必要」です。レビューによって「勝者には終わりのない修正が必要」であることが確認された時点で、判断は変わります。完璧な説明を待つだけでは、復旧が難しくなるだけです。出力の他の部分が滑らかに読める場合でも、この結果は重要です。

結論を公開する前に、時間、ソースへのアクセス、語彙サポートを測定します。ブラインドテストのログには、話者の代表性、スクリプト、ツールの順序、エンティティの誤り、ターンの結果、レビュアーの所要時間、公平性に関する注記を記録します。公式ページに記載されていること、チームが再現したこと、編集者が推測したことを分けます。このアクセントベンチマークテストを完了できない場合は、N/Aを使用し、復旧ルートに従います。元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合に発音または語彙の補助を使用します。

アクセントベンチマークの証拠メモ： 関連するポリシー、プラットフォームの制御、または機能を信頼する前に、現在の Zoom サポート — Zoom サポートセンター ページを確認してください。

ブラインドアクセントテストを開始： まずは機微情報を含まない例を使用し、不明な結果はN/Aのままにして、検証できる動作の範囲内でのみ 現在のHiNoterワークフローを評価してください 。

代表的な話者でHiNoterを評価する

現在のHiNoterの言語および話者に関する動作には、承認を得たブラインドテストが必要です。

ブラインドテストのメモ：「代表性」を合格項目として使用します。合格とは、話者が実際の利用ケースを反映していることです。これは、カテゴリーが機能するという広範な声明よりも、1つのアクセントを標準として扱わずに文字起こしツールを比較する多言語・分散型チームにとって有用です。話者自身に自分の出力を確認してもらい、修正内容をブラインドスコアと比較します。

このルールをこの現場ケースに適用します。レビュアーは合成コンテンツを使用し、録音されたすべての話者から許可を得ます。最も近いパターンは「カスタマーサポート」で、優先事項は名前とアカウント用語、人間による境界はエンティティの採点です。「1つのアクセントがすべてを代表する」を重大な失敗として扱います。この境界が存在するのは、「1つのアクセントがすべてを代表する」という発見が、作業開始後の信頼、アクセス、または証拠を変える可能性があるためです。アクセントベンチマークの例は、どの前提が最初に崩れ、誰がなお対応する権限を持っているかを示します。

実際的な対応は、観測したアクセント条件だけを公開することです。ブラインドテストの記録には、話者の構成、スクリプト、ツールの順序、固有表現の誤り、各回の結果、レビュアーの時間、 公平性に関する注記を残します。このアクセントベンチマークの確認では、別のレビュアーが観測を再現できるだけの情報のみを保持してください。文書で公式に確認された内容、再現して観測された挙動、編集上の解釈を区別してラベル付けします。手順が失敗した場合は、元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合は発音または語彙の補助ツールを使用してください。これは、アクセントに最適なAI文字起こしについて限定された知見を支えるものであり、普遍的な保証ではありません。

アクセントベンチマークの証拠に関する注記: 関連するポリシー、プラットフォームの管理機能、または能力に依拠する前に、現在の HiNoter — HiNoter製品ウェブサイト ページを確認してください。

ステレオタイプではなく、しきい値を選ぶ

適切な判断では、正確性、公平性、プライバシー、そしてユーザーが修正できる能力のバランスを取ります。

「ステレオタイプではなく、しきい値を選ぶ」という判断は、「盲検性」にかかっています。基準は具体的です。レビュアーはツールの識別情報を知りません。アクセントを一つの基準として扱わずに文字起こしツールを比較する、多言語対応の分散型チームにとって、有用な問いは、インターフェースが安心感を与えるかどうかではありません。提示された条件のもとで、同僚が同じ証拠を再現できるかどうかです。観測も文書化もされていないものは、すべてN/Aのままにします。

ここでラベルではなく状況を確認します。チームは異なる条件に対応するために2つのツールと、人間による例外対応ルートを維持しています。これは「エグゼクティブ向けブリーフィング」に似ており、直ちに懸念されるのは「影響」で、レビューの境界は「レビュアーの承認を必須にする」です。「ブランドへの期待がスコアを変える」ことを証拠が示しているなら、その結果を通常のものとして扱うのをやめてください。通常の手順がもはや信頼できず、証拠が「ブランドへの期待がスコアを変える」ことを示している場合に、フォールバックはその役割を得ます。記録を超えてしまう洗練された説明より、範囲を限定した再構成のほうが安全です。

このセクションでのアクション: 話者、モデル、またはマイクが変わったら再テストしてください。ブラインドテストの記録には、話者の構成、スクリプト、ツールの順序、固有表現の誤り、各回の結果、レビュアーの時間、公平性に関する注記を残します。テストは機微情報を含まないものにし、結果に影響した状態を保持し、関係のない個人情報は破棄してください。証拠の連鎖が終われば、主張も終わります。運用上のフォールバックは、元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合は発音または語彙の補助ツールを使用することです。

• 構成を確認する: 話者が実際のユースケースを反映している
• 盲検性を確認する: レビュアーはツールの識別情報を知らない
• 固有表現を確認する: 名前と数字を採点する
• ターンテイキングを確認する: 話者の交代が実用可能な状態で維持されている
• 公平性を確認する: 話者ごとの誤りの分布を報告する

アクセントベンチマークの証拠に関する注記: 関連するポリシー、プラットフォームの管理機能、または能力に依拠する前に、現在の 英国情報コミッショナー事務局 — データ保護ガイダンス ページを確認してください。

アクセントベンチマークに関する読者からの質問

アクセントに最も適切に対応するAI文字起こしツールはどれですか?

定義された言語変種、部屋、マイク、タスク、誤りのしきい値がなければ、アクセントに最適なAI文字起こしは普遍的には存在しません。ワークフロー内のアクセントを代表する人々が同じ内容を話す、ブラインド方式の条件を揃えたテストを行ってください。名前、数字、ターン、省略、修正にかかる労力を採点し、単一の勝者ではなく分布を報告します。話者にも公平性を確認してもらい、ある一人の声をコミュニティ全体の代 proxy として使うことは避けてください。答えは、主催者、プラットフォーム、アカウントの役割、会議の種類、管轄区域、組織のポリシー、キャプチャの仕組みによって変わります。害のない代表的なケースをテストし、裏付けのない挙動はN/Aのままにしてください。

アクセントに最適なAI文字起こしについて、最初に何を確認すべきですか?

仕組みと判断の境界から始めます。代表的なアクセントで同じスクリプトを録音し、ツールの順序をランダム化し、レビュアーからシステムの識別情報を隠し、人間による修正経路を用意した条件別の結果を公開してください。最初の確認では、ワークフローが承認されているか、そして自動化された経路が失敗した場合にも信頼できるソースが残るかを明らかにする必要があります。

参加者タイルが表示されれば、録音が機能した証明になりますか?

いいえ。参加状態、音声アクセス、文字起こし、保存、後処理はそれぞれ別の状態です。生成された成果物で既知の一節を確認し、キャプチャが開始されなかったり不完全になったりした場合に、責任を負う人が有用なアラートを受け取ることを確認してください。

主催者または参加者が異議を唱えた場合はどうすればよいですか?

利便性について議論せず、承認済みの録音なしの分岐を使用してください。元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合は発音または語彙の補助ツールを使用します。機微な会議や重大な影響を伴う会議では、組織のポリシーに従い、必要に応じて有資格者の助言を得てください。

同意とプライバシーはどのように扱うべきですか?

通知、適用法、契約、組織のポリシー、目的、アクセス、保持、訂正、削除を、関連はしているものの別個の問題として扱ってください。この記事は運用上の情報を提供するものであり、法的助言ではありません。また、プラットフォームの通知は普遍的な法的許可ではありません。

このワークフローではHiNoterをどのように評価すべきですか?

見出しのスコアをもとに分散型チームがツールを選び、その後、2人の地域の同僚が話した顧客名が繰り返し書き換えられていることに気づくという状況を、機微情報を含まない形で使用してください。トリガー、参加者のシグナル、管理機能、出力、アラート、アクセス、クリーンアップについて、現在観測された挙動だけを記録します。カテゴリの表現から、欠けている機能、プライバシー特性、またはコンプライアンスを推測しないでください。

自動化が失敗した場合、最も安全なフォールバックは何ですか?

元の音声を保持し、話者に詳しい人間のレビュアーを加え、承認された場合は発音または語彙の補助ツールを使用してください。影響を受ける人々にどの記録が正式なものかを伝え、欠落箇所を特定し、ソースまたは直接の確認が利用できる場合は、重大な影響を伴う事実を記憶から再構成することを避けてください。

編集上の判断

「アクセントに最も適切に対応するAI文字起こしツールはどれですか?」という問いに対する有用な答えは、断定的なものではなく条件付きのものです。定義された言語変種、部屋、マイク、タスク、誤りのしきい値がなければ、アクセントに最適なAI文字起こしは普遍的には存在しません。ワークフロー内のアクセントを代表する人々が同じ内容を話す、ブラインド方式の条件を揃えたテストを行ってください。名前、数字、ターン、省略、修正にかかる労力を採点し、単一の勝者ではなく分布を報告します。話者にも公平性を確認してもらい、ある一人の声をコミュニティ全体の代 proxy として使うことは避けてください。公平な選択では、一つの声にコミュニティを代表させるのではなく、人々が実際に必要とするワークフローを測定します。判断では、何が検証済みか、どの会議区分がまだ除外されているか、誰が記録を承認するのか、そして失敗した、または不適切なキャプチャ経路にも耐えられるフォールバックを明示すべきです。

製品、プラットフォーム、テナント、主催者、カレンダー、ポリシー、または会議の目的に変更があったら、稼働中のアカウントを再確認してください。証拠がアクセントに最適なAI文字起こしについての記述を裏付けられない場合は、好意的な推定ではなく「未検証」またはN/Aを公開してください。

一つの勝者ではなく、分布を報告してください: 承認済みで機微情報を含まないリハーサルを1回実施し、その結果をソースと比較して、 検証した正確な範囲内でHiNoterをテストしてください。