マイク、ノイズ、同意、要約の忠実度を部屋ごとにテスト。
執筆:HiNoter Room Test Collective · 編集ステータス:内部の構造および証拠境界のQA完了;公開前に資格を有する法務レビューが必要 · 公開・更新日 2026-08-28· 米国/国際英語版
対面会議に最適なAI議事録作成ツールとは、話すべき人の声を明瞭に捉え、理解できる通知を行い、室内のノイズに対応し、レビュー可能な要約を作成し、人間による代替手段を残すものです。オンラインでの性能から、カフェ、会議室、広い部屋での結果を予測することはできません。「対面会議向けAI議事録作成ツール」については、次の判断基準を使ってください:小さな会議室、騒がしいカフェ、広い部屋で同じ短いスクリプトを実行し、マーカー語の正確性、話者の帰属、同意、復旧を比較します。

対面での収音は、部屋自体が信号経路の一部であるため、部屋のテストを行う価値があります。次のような編集者が作成したシナリオを考えてみましょう:あるチームがウェブカメラのデモを見て議事録作成ツールを選び、最初の顧客ワークショップで、エコー、コーヒーショップのノイズ、軸外から話す人々に直面します。顧客、従業員、候補者、患者、クライアント、参加者のデータは含まれていません。この場面が有用なのは、「対面会議に最適なAI議事録作成ツールとは何か」という問いを、クリーンなデモから引き出し、所有権、権限、証拠、復旧を検証できる判断の場に持ち込むからです。
このガイドでは、証拠の階層を使用します。公式とは、ファーストパーティのプラットフォーム、規制当局、法令、またはプロバイダーのページが、限定的な機能や義務を説明していることを意味します。観測済みとは、権限を与えられたレビュアーが、日付のある環境で挙動を再現したことを意味します。編集とは、ビデオ通話のデモに頼るのではなく、物理的な部屋での会議収音を比較するチームのために、執筆者がそれらの資料を解釈したことを意味します。テストされていない機能はN/Aのままです。
この記事を形作る帰結は次のとおりです。洗練されたオンラインデモでは、マイクの配置、HVACノイズ、周辺の会話、距離、同意に関する問題が隠れ、物理的な部屋の文字起こしが信頼できなくなる可能性があります。したがって、実務上の基準は意図的に保守的です:小さな会議室、騒がしいカフェ、広い部屋で同じ短いスクリプトを実行し、マーカー語の正確性、話者の帰属、同意、復旧を比較します。これはこの用途のレビュー方法であり、普遍的な製品声明ではありません。
対面会議向けAI議事録作成ツール:部屋も製品の一部
モデルが動作する前に、マイクとの距離と反響が結果を左右することがあります。
部屋に関する注記:「フォールバック」を受け入れ項目として使用します。合格とは、人間または承認済みのレコーダーが引き継げることです。これは、ビデオ通話のデモに頼るのではなく、物理的な部屋での会議収音を比較するチームにとって、カテゴリーが機能するという広範な声明よりも有用です。3つの部屋で同じマーカースクリプトを使用し、実際の成果物を比較してください。
このルールを次の現場ケースに当てはめます:ガラス製テーブルの遠端にいる静かな人の発言が文字起こしから抜け落ちています。最も近いパターンは「カフェ」で、優先事項はノイズとプライバシー、人間による境界線は対象範囲を狭めるか収音を拒否することです。「部屋が唯一の記録を失う」ことを重大な失敗として扱います。直ちに生じるリスクは明らかです:部屋が唯一の記録を失います。説明責任を負う担当者は、復旧がまだ現実的なうちにその事実を把握すべきです。部屋のテスト例は、どの前提が最初に崩れ、誰が対応する権限をまだ持っているかを示します。
実務上は、ツールを比較する前に、部屋の形状と収音範囲を記述します。現場シートには、部屋の形状、デバイス、座席配置、ノイズ、通知、マーカー結果、要約レビュー、フォールバックを記録します。この部屋のテストでは、別のレビュアーが観測を再現できるだけの情報を残します。文書を公式、再現された挙動を観測済み、解釈を編集とラベル付けします。経路が失敗した場合は、人間のメモ担当者を割り当て、音声テストに失敗したときは承認済みの室内レコーダーまたは手書きの記録を使用します。これは、対面会議向けAI議事録作成ツールについての範囲を限定した発見を裏付けるものであり、普遍的な約束ではありません。
| 管理項目 | 合格する証拠 | 重大な失敗 |
|---|---|---|
| 部屋のカバー範囲 | すべての話者がテスト済みの収音パターン内にいる | 静かな話者の声が消える |
| ノイズ | 背景ノイズが測定され、理解されている | HVACまたはカフェの音声が支配的になる |
| 同意 | 部屋で通知と拒否が機能する | 人々が理解する前に収音が始まる |
| マーカー | 既知の語が文字起こしに残る | 用語が黙って変更される |
| 要約 | 決定事項と担当者が原文と一致する | 流暢な出力がコミットメントを捏造する |
| フォールバック | 人間または承認済みのレコーダーが引き継げる | 部屋が唯一の記録を失う |
部屋のテストに関する証拠注記: 関連するポリシー、プラットフォームの管理機能、または機能に依拠する前に、現在の Zoom Support — Zoom Support Center ページを確認してください。
小さな部屋を基準に始める
管理された部屋が、後の失敗に対するチームの基準を提供します。
「小さな部屋を基準に始める」の判断は、「部屋のカバー範囲」にかかっています。基準は具体的です。すべての話者が、テスト済みの集音パターンの範囲内にいること。ビデオ通話のデモに頼るのではなく、実際の部屋での会議記録を比較するチームにとって有用な問いは、インターフェースが安心感を与えるかどうかではありません。示された条件の下で、同僚が同じ証拠を再現できるかどうかです。観察または文書化されていないものは、すべてN/Aのままにします。
ここでラベルではなく状況を確認します。中央のマイクは台本を通しますが、側面の位置では子音が失われます。これは「小さな部屋」に似ており、直近の懸念は短い距離と反響で、レビューの境界はマイクを中央に置くことです。証拠によって「静かな話者の声が消える」ことが示された場合、その結果を通常のものとして扱うのをやめます。この判断では、安心感を与えるインターフェースや洗練された成果物よりも、「静かな話者の声が消える」ことを重視します。記録を超えてしまう優雅な説明より、狭く限定した再構成のほうが安全です。
このセクションでのアクション:中央、側面、軸外の座席をテストします。フィールドシートには、部屋の構造、デバイス、座席、ノイズ、通知、マーカー結果、概要レビュー、フォールバックを記録します。テストは機微な内容を含まないものにし、結果に影響した状態を保持し、関係のない個人情報は破棄します。証拠の連鎖が終われば、主張も終わります。運用上のフォールバックは、人間のメモ担当者を割り当て、音声テストに失敗した場合は承認済みの部屋用レコーダーまたは手書きの記録を使うことです。

部屋のテストに関する証拠メモ: 関連するポリシー、プラットフォームの制御、または機能に依拠する前に、現在の Google Meet ヘルプ — Google Meet ヘルプセンター ページを確認してください。
カフェはノイズと社会的リスクを加える
ノイズ低減によって、公共の部屋がその内容に適しているかどうかを判断することはできません。
どのような証拠があれば判断は変わるでしょうか。「ノイズ」から始めます。結果が合格になるのは、背景ノイズが測定され、理解されている場合だけです。この枠組みにより、「カフェはノイズと社会的リスクを加える」という内容は、ビデオ通話のデモに頼るのではなく、実際の部屋での会議記録を比較するチームにとって、機能を称賛するセクションに変えることなく、観察可能な作業に結び付けられます。不明点は、より小規模なテストを行うためのきっかけであり、推測する許可ではありません。
実用的な反例は次のとおりです。顧客との会話中に、近くのテーブルの音声が聞こえるようになります。これを「ワークショップ」のケースとして読みます。証拠の対象は動きとグループで、人間によるチェックポイントはメモ担当者を割り当てることです。停止条件は「HVACまたはカフェの音声が支配的になる」です。制御が破綻した場合、実際の結果は「HVACまたはカフェの音声が支配的になる」です。これは脚注ではなく、運用上の判断に含めるべきです。残りの出力が滑らかに読める場合でも、その結果は重要です。
結論を公開する前に、会議を分類するか、範囲を縮小するか、記録しない経路を使います。フィールドシートには、部屋の構造、デバイス、座席、ノイズ、通知、マーカー結果、概要レビュー、フォールバックを記録します。公式ページに書かれていること、チームが再現したこと、編集者が推測したことを分けます。この部屋のテストを完了できない場合はN/Aを使用し、復旧手順に従います。人間のメモ担当者を割り当て、音声テストに失敗した場合は承認済みの部屋用レコーダーまたは手書きの記録を使います。
- 部屋のカバー範囲を確認:すべての話者がテスト済みの集音パターンの範囲内にいる
- ノイズを確認:背景ノイズが測定され、理解されている
- 同意を確認:部屋で通知と拒否が機能する
- マーカーを確認:既知の単語が文字起こしに残る
- 概要を確認:決定事項と担当者が原文と一致する
部屋のテストに関する証拠メモ: 関連するポリシー、プラットフォームの制御、または機能に依拠する前に、現在の Google Meet ヘルプ — ビデオ会議を録画する ページを確認してください。
大きな部屋にはゾーンが必要
距離、天井からの反響、移動する話者によって信号は変化します。
部屋に関するメモ:「同意」を受け入れ項目として使います。合格とは、部屋で通知と拒否が機能することです。これは、カテゴリーが機能するという広範な主張よりも、ビデオ通話のデモに頼るのではなく実際の部屋での会議記録を比較するチームにとって有用です。3つの部屋で同じマーカー台本を使い、実際の成果物を比較します。
この現場ケースにルールを当てはめます。ワークショップの発表者の声は明瞭ですが、後方列からの質問が消えます。最も近いパターンは「大きな部屋」で、優先事項は距離とゾーン、人間による境界はテスト済みの部屋用マイクを使うことです。「人々が理解する前に記録が開始される」を重大な失敗として扱います。「人々が理解する前に記録が開始される」をエスカレーションのトリガーとして扱います。これは誰が対応すべきか、通常の経路を継続すべきかを変えます。部屋のテスト例は、どの前提が最初に破綻し、誰が対応する権限をなお持つのかを示します。
実際の対応は、ゾーン、移動、集音範囲の端をテストすることです。フィールドシートには、部屋の構造、デバイス、座席、ノイズ、通知、マーカー結果、概要レビュー、フォールバックを記録します。この部屋のテストでは、別のレビュアーが観察を再現できるだけの情報のみを保持します。文書を、公式、再現された観察済みの挙動、編集上の解釈としてラベル付けします。経路が失敗した場合は、人間のメモ担当者を割り当て、音声テストに失敗した場合は承認済みの部屋用レコーダーまたは手書きの記録を使います。これは、対面会議用AIノートテイカーについての限定された発見を支えるものであり、普遍的な保証ではありません。
| シナリオ | 証拠の対象 | 安全な対応 |
|---|---|---|
| 小さな部屋 | 短い距離と反射 | マイクを中央に置く |
| カフェ | 騒音とプライバシー | 対象範囲を狭めるか、録音を見送る |
| 大きな部屋 | 距離とゾーン | テスト済みのルームマイクを使う |
| ワークショップ | 移動とグループ | 議事メモの担当者を決める |

Room Testingの証拠に関する注記: 関連するポリシー、プラットフォームの制御、または機能を信頼する前に、最新の Microsoft Learn — Teams会議の文字起こしとキャプションを構成する ページを確認してください。
会議ワークフローガイド を続けて読むか、AI議事録作成ツールのトピックライブラリを確認してください。
要約をソースのマーカーと照合する
流暢な要約でも、誤った担当者を割り当てたり、注意事項を省略したりすることがあります。
「要約をソースのマーカーと照合する」における判断は、「マーカー」にかかっています。基準は具体的です。既知の単語が文字起こしに残っていること。ビデオ通話のデモに頼るのではなく、物理的な部屋での会議記録を比較するチームにとって有用な問いは、インターフェースが安心感を与えるかどうかではなく、提示された条件下で同僚が同じ証拠を復元できるかどうかです。観察も記録もされていないものは、すべてN/Aのままにします。
ラベルではなく、場面を確認します。メモでは、財務部門に割り当てられたタスクの担当者として進行役が記載されています。これは「カフェ」に似ており、直ちに問題となるのは「騒音とプライバシー」で、レビューの境界は「対象範囲を狭めるか、録音を見送る」です。「条件が密かに変更された」ことが証拠によって示された場合、その結果を通常のものとして扱うのをやめてください。滑らかな出力であっても、この結果を埋め合わせることはできません。条件が密かに変更されています。証拠の境界はすでに越えられています。記録を逸脱する洗練された説明より、限定的な再構成のほうが安全です。
このセクションでのアクション: マーカーとなる単語、発言者の交代、決定事項、日付を比較します。フィールドシートには、部屋の形状、デバイス、座席配置、騒音、通知、マーカーの結果、要約のレビュー、フォールバックを記録します。テストは機微情報を含まないものにし、結果に影響した状態を保持し、関係のない個人情報は破棄してください。証拠の連鎖が終われば、主張も終わります。運用上のフォールバックは、人間の議事メモ担当者を割り当て、音声テストに失敗した場合は承認済みのルームレコーダーまたは手書きの記録を使用することです。
Room Testingの証拠に関する注記: 関連するポリシー、プラットフォームの制御、または機能を信頼する前に、最新の Microsoft Support — Microsoft Teamsで会議を録画する ページを確認してください。
3部屋テストシートを印刷: まず機微情報を含まない例を使用し、未知の結果はN/Aのままにして、検証できる動作の範囲内でのみ、現在のHiNoterワークフローを評価 してください。
同意は部屋で得る
デバイスが記録を開始する前に、参加者には通知と、実際に異議を申し立てる方法が必要です。
どのような証拠があれば判断は変わるでしょうか。まず「要約」から始めます。結果が合格となるのは、決定事項と担当者がソースと一致する場合だけです。この枠組みにより、「同意は部屋で得る」は、ビデオ通話のデモに頼るのではなく、物理的な部屋での会議記録を比較するチームにとって、機能を称賛するのではなく、観察可能な作業と結び付けられます。未知の結果は、より小規模なテストを行うきっかけであり、推測する許可ではありません。
反例は実際的なものです。開始時の説明の後に、遅れて参加者が加わります。これを「小さな部屋」のケースとして読み取ります。証拠の対象は「短い距離と反射」で、人間によるチェックポイントは「マイクを中央に置く」です。停止条件は「流暢な出力がコミットメントを捏造する」です。レビューによって「流暢な出力がコミットメントを捏造する」ことが確認された時点で判断は変わります。完璧な説明を待つほど、復旧は難しくなります。残りの出力が滑らかに読める場合でも、その結果は重要です。
結論を公開する前に、通知を繰り返し、質問のために一時停止します。フィールドシートには、部屋の形状、デバイス、座席配置、騒音、通知、マーカーの結果、要約のレビュー、フォールバックを記録します。公式ページに書かれていること、チームが再現したこと、編集者が推測したことを分けてください。この部屋のテストを完了できない場合はN/Aを使用し、復旧経路に従います。人間の議事メモ担当者を割り当て、音声テストに失敗した場合は承認済みのルームレコーダーまたは手書きの記録を使用してください。

Room Testingの証拠に関する注記: 関連するポリシー、プラットフォームの制御、または機能を信頼する前に、最新の NIST — AIリスクマネジメントフレームワーク ページを確認してください。
3部屋で議事録作成ツールのフィールドテストを実施する
フォールバックを選ぶ
記録を停止するタイミングと、正式な記録の責任者を文書化します。採用、範囲縮小、再テスト、または却下で終えます。主要な経路に失敗した場合は、人間の議事メモ担当者を割り当て、音声テストに失敗した場合は承認済みのルームレコーダーまたは手書きの記録を使用します。
成果物を確認する
文字起こしのマーカー、名前、決定事項、要約の担当者を比較します。欠落している証拠にはN/Aを付け、責任者を明記し、未知の結果を好意的なスコアに変換しないでください。
大きな部屋でテストする
距離、ゾーン、動き、端にいる話者をテストします。全体的な流暢さや見た目の洗練度で判断するのではなく、書面での期待値と結果を比較します。
騒がしい部屋でテストする
通常のカフェの雑音を加え、プライバシーと明瞭性を観察します。意図的に機密性のないサンプルを使用し、承認済みの手順で削除が求められる場合はテスト成果物を削除します。
小さな部屋でベースラインを確認する
機密性のある内容を使わずに、中央、側面、離れた席をテストします。結論を変える場合に限り、アカウント、主催者との関係、プラットフォーム、会議の種類、設定、日付、レビュアーを記録します。
部屋用のスクリプトを書く
すべての場所で同じマーカーとなるフレーズ、決定事項、質問、名前を使用します。この架空のテストパターンを範囲として使用します。チームがウェブカメラのデモから議事録作成ツールを選び、最初の顧客ワークショップでエコー、コーヒーショップの雑音、軸から外れた方向で話す人々がいることに気づくというものです。
実際の部屋でHiNoterを評価する
現在のHiNoterの収音動作は、選択したデバイスとアカウントで観察する必要があります。
部屋に関する注記:「Fallback」を受け入れ項目として使用します。合格とは、人間または承認済みのレコーダーが引き継げることです。これは、ビデオ通話のデモに頼るのではなく、物理的な部屋での会議録音を比較するチームにとって、カテゴリーが機能するという広範な声明よりも有用です。3つの部屋で同じマーカースクリプトを使用し、実際の成果物を比較します。
この現場ケースにルールを適用します。評価者は、部屋、デバイス、トリガー、出力、失敗状態を記録します。最も近いパターンは「Workshop」で、優先事項はMovement and groups、人間による境界はAssign a note ownerです。「部屋が唯一の記録を失う」を重大な失敗として扱います。この境界が存在するのは、「部屋が唯一の記録を失う」という発見が、作業開始後の信頼、アクセス、または証拠を変える可能性があるためです。部屋のテスト例は、どの前提が最初に崩れ、誰が対応する権限をなお持つのかを示します。
実務上の対応は、テストした組み合わせだけを公開することです。現場シートには、部屋の形状、デバイス、座席、雑音、通知、マーカー結果、要約のレビュー、フォールバックを記録します。この部屋のテストでは、別のレビュアーが観察を再現できる十分な情報だけを保持します。文書を公式情報、再現された観察済みの動作、編集上の解釈としてラベル付けします。経路が失敗した場合は、人間の議事録担当者を割り当て、音声テストが失敗したときは承認済みの部屋用レコーダーまたは手書きの記録を使用します。これは、AIによる対面会議用議事録作成ツールについての限定的な発見を支えるものであり、普遍的な約束ではありません。
Room Testing evidence note: 関連するポリシー、プラットフォームの管理機能、または能力を信頼する前に、現在の HiNoter — HiNoter製品ウェブサイト ページを確認してください。
復旧可能性を基準に選ぶ
最適な部屋用ツールとは、会議を失うことなくチームが停止して置き換えられるものです。
「復旧可能性を基準に選ぶ」という判断は、「Room coverage」にかかっています。基準は具体的です。すべての話者が、テスト済みの収音パターンの範囲内にいること。ビデオ通話のデモに頼るのではなく、物理的な部屋での会議録音を比較するチームにとって、有用な問いはインターフェースが安心感を与えるかどうかではなく、明示された条件下で同僚が同じ証拠を復旧できるかどうかです。観察または文書化されていないものはすべてN/Aのままにします。
ここではラベルではなく状況を検討します。雑音が収音を圧倒したとき、ホストは人間の議事録担当者に切り替えます。これは「Large room」に似ており、直近の懸念はDistance and zones、レビュー上の境界はUse tested room micsです。「静かな話者が聞こえなくなる」という証拠が確立された場合、その結果を通常どおりのものとして扱うのをやめます。「静かな話者が聞こえなくなる」という証拠があり、通常の経路がもはや信頼できないときに、フォールバックは意味を持ちます。記録を追い越す洗練された説明よりも、限定的な再構成のほうが安全です。
このセクションでの対応:部屋固有の受け入れルールとフォールバックルールを書きます。現場シートには、部屋の形状、デバイス、座席、雑音、通知、マーカー結果、要約のレビュー、フォールバックを記録します。テストは機密性のないものにし、結果に影響した状態を保持し、無関係な個人情報は破棄します。証拠の連鎖が終われば、主張も終わります。運用上のフォールバックは、人間の議事録担当者を割り当て、音声テストが失敗したときは承認済みの部屋用レコーダーまたは手書きの記録を使用することです。

Room Testing evidence note: 関連するポリシー、プラットフォームの管理機能、または能力を信頼する前に、現在の EUR-Lex — 一般データ保護規則 ページを確認してください。
部屋のテストに関する読者からの質問
対面会議に最適なAI議事録作成ツールは何ですか?
対面会議に最適なAI議事録作成ツールとは、意図した話者を明瞭に収音し、理解しやすい通知を行い、部屋の雑音に対応し、レビュー可能な要約を作成し、人間によるフォールバックを残すものです。オンラインでの性能から、カフェ、会議室、大きな部屋での結果を予測することはできません。答えは、主催者、プラットフォーム、アカウントの役割、会議の種類、管轄区域、組織のポリシー、収音の仕組みによって変わります。害のない代表的なケースをテストし、裏付けのない動作はN/Aのままにします。
対面会議用AI議事録作成ツールについて、最初に何を確認すべきですか?
仕組みと意思決定の境界から始めます。小さな会議室、騒がしいカフェ、大きな部屋で同じ短いスクリプトを実行し、マーカー語の正確性、話者の帰属、同意、復旧を比較します。最初の確認では、ワークフローが承認されているか、自動経路が失敗した場合にも信頼できる情報源が残るかを明らかにする必要があります。
参加者タイルがあれば録音が機能した証拠になりますか?
いいえ。存在、音声アクセス、文字起こし、保存、後処理は別々の状態です。生成された成果物で既知の発言を確認し、収音が開始されない、または不完全になった場合に、責任を負う担当者が有用なアラートを受け取ることを確認します。
主催者または参加者が異議を唱えた場合はどうすればよいですか?
利便性について議論せず、承認済みの録音なしの分岐を使用します。人間の議事録担当者を割り当て、音声テストが失敗したときは承認済みの部屋用レコーダーまたは手書きの記録を使用します。機密性の高い会議や重大な結果につながる会議では、組織のポリシーに従い、必要に応じて有資格者の助言を得てください。
同意とプライバシーはどのように扱うべきですか?
通知、適用法、契約、組織のポリシー、目的、アクセス、保持、訂正、削除を、関連しているものの別個の問題として扱います。この記事は運用上の情報を提供するものであり、法的助言ではありません。また、プラットフォームの通知は普遍的な法的許可ではありません。
このワークフローについてHiNoterをどのように評価すべきですか?
チームがウェブカメラのデモから議事録作成ツールを選び、最初の顧客ワークショップでエコー、コーヒーショップの雑音、軸から外れた方向で話す人々がいることに気づくというケースの、機密性のないバージョンを使用します。トリガー、参加者へのシグナル、管理機能、出力、アラート、アクセス、クリーンアップについて、現在観察された動作のみを記録します。カテゴリーに関する表現から、欠けている能力、プライバシー特性、コンプライアンスを推測しないでください。
自動化が失敗したとき、最も安全なフォールバックは何ですか?
人間の議事録担当者を割り当て、音声テストが失敗したときは承認済みの部屋用レコーダーまたは手書きの記録を使用します。影響を受ける人々にどの記録が正式なものかを伝え、欠落部分を特定し、情報源または直接の確認が利用できる場合は、重大な事実を記憶から再構築することを避けます。
編集上の判断
「対面会議に最適なAI議事録作成ツールは何ですか?」という問いに対する有用な答えは、断定的なものではなく条件付きのものです。対面会議に最適なAI議事録作成ツールとは、意図した話者を明瞭に収音し、理解しやすい通知を行い、部屋の雑音に対応し、レビュー可能な要約を作成し、人間によるフォールバックを残すものです。オンラインでの性能から、カフェ、会議室、大きな部屋での結果を予測することはできません。最適な議事録作成ツールとは、部屋がデモのように振る舞わなくなったときにも信頼性を保つものです。判断では、何を検証したか、どの会議クラスをなお除外しているか、誰が記録を承認するか、失敗したまたは不適切な収音経路を乗り越えられるフォールバックは何かを明示すべきです。
製品、プラットフォーム、テナント、主催者、カレンダー、ポリシー、または会議の目的を変更した後は、ライブアカウントを再確認してください。対面会議用AIノートテイカーに関する主張を裏付ける証拠がない場合は、好意的な推定ではなく「未検証」またはN/Aを公開してください。
物理的な会議室の指標を確認してからのみ選択してください: 承認済みで機密情報を含まないリハーサルを1回実施し、その結果を元の情報と比較して、 検証した正確な範囲内でHiNoterをテストしてください。