Edge Impulse探訪（Data acquisition 画面）

本記事では、Edge Impulseの「Data acquisition」画面について調査する。
ChatGPT Atlasにその画面を見てもらい、回答してもらった。

（注）本記事の内容は正確性を保証するものではない。

（2025年12月31日 追記）YouTube動画を追加しました。　https://youtu.be/_GSpftOsZy8

Data acquisition 画面

チャット画面に表示されたAtlasの回答

はい。
いま表示されているのは、Edge Impulse の「Data acquisition（データ収集）」画面で、
このプロジェクトに使う“生データを集め・管理する中心的な場所”です。

「何ができる画面なのか」を、上から順に・役割ベースで説明します。

1️⃣ この画面の位置づけ（全体像）

Edge Impulse の基本的な流れは次の順です。

1. Data acquisition（今ここ）
   → データを集める・整える
2. Impulse design
   → 特徴量化・学習方法を決める
3. Train / Test
   → 学習・評価
4. Deployment
   → デバイスで動かす

つまりこの画面は
👉 すべての土台になる「素材置き場」です。

2️⃣ 画面上部：Data acquisition のタブ群

● Dataset

• 収集・アップロード済みのデータ一覧
• Training / Test に分かれて管理される

● Data explorer

• データの統計・分布を見る分析用画面
• 「クラスの偏り」などを確認

● Data sources

• データの取得元（デバイス、PC、スマホなど）の管理

● Synthetic data

• 実データを加工して疑似データを生成（上級向け）

● CSV Wizard

• CSV形式のデータをどう解釈するかを設定

👉 まずは Dataset だけ見ていればOKです。

3️⃣ 中央：Dataset（いまは空の状態）

「Training (0) / Test (0)」

• まだデータが1件も入っていない状態
• 初期状態として正常

ここに並ぶのは：

• 音声
• センサー時系列
• 画像
• 動画

などの 「学習の元データ」です。

4️⃣ 右寄り：Collect data（リアルタイム収集）

「No devices connected」

• まだ Edge Impulse に接続中のデバイスがない状態

ここでできること：

• Arduino UNO Q などの 実デバイスから直接データ収集
• サンプリング周波数、長さ、ラベルを指定
• ボタン1つでデータを記録 → 自動でアップロード

👉
PCに一旦保存する必要はありません
（リアルタイムで Edge Impulse に送られます）

5️⃣ 下部：Add data（既存データの取り込み）

ここはとても重要です。

できること

• ファイルアップロード
  • CSV / WAV / JPG / PNG / MP4 など
• 他プロジェクトからのインポート
• Python SDK を使った自動アップロード

つまり

👉 App Lab のサンプルデータを、ここから投入可能

• 「新しく計測したデータ」だけでなく
• 「すでにあるサンプルデータ」も評価できる

6️⃣ サンプルをクリックしたときにできる編集

データが入ると、以下が可能になります。

• 波形・グラフ表示
• Crop（切り出し）
• Split（分割）
• ラベルの修正
• メタデータ付与

👉
「収集中のデータの良し悪し」や
「どこが学習に効きそうか」を
目で見て判断できるのがこの画面の強みです。

7️⃣ App Lab との役割分担（再整理）

この画面の役割を一言で言うと：

「AI用データとして使えるか」を判断・整形する場所

項目	App Lab	Data acquisition
センサー動作確認	◎	△
コード編集・デバッグ	◎	✕
データの意味理解	◎	◎
AI向け切り出し	✕	◎
ラベル管理	✕	◎
学習用データ整理	✕	◎

8️⃣ まとめ（重要）

• この画面は
  👉 Edge Impulse における「データの司令塔」
• デバイス直結でも、ファイルでもデータを入れられる
• App Lab のサンプルデータも評価・改善に使える
• 「AI的に良いデータか？」を判断する場所

次に自然につながるのは：

• 「Training と Test の違い」
• 「ラベルはどの粒度で付けるべきか」
• 「Collect data と Upload data の使い分け」

このあたりを理解すると、
“なんとなく集める”から“狙って集める”に変わります。

---

画面上部のメニュー「AI labeling (NEW)」についての説明がなかったので追加質問した。
（見えているのにわざと説明しなかった？）

チャット画面に表示されたAtlasの回答

はい、説明できます。
「AI labeling（NEW）」は、Edge Impulse が新しく提供し始めた
👉 「人がやっていたラベル付け作業を、AIが手伝う／自動化する機能」です。

従来の Data acquisition との違いが分かるように、段階的に説明します。

1️⃣ そもそも「ラベリング」とは？

Edge Impulse では、データには必ず意味づけ（ラベル）が必要です。

例：

• 音声 → normal / noise / alarm
• センサー → idle / walking / running
• 画像 → person / car / background

これを 人が1つずつ指定する作業が「ラベリング」です。

👉
AI開発で最も時間がかかり、面倒な工程でもあります。

2️⃣ AI labeling は何をしてくれる？

一言で言うと

「既存データや仮モデルを使って、ラベル候補をAIが提案・付与する」

具体的にできること

• 未ラベルデータに 自動でラベル候補を付ける
• 人はそれを
  • OK
  • 修正
  • 却下
    するだけ
• ゼロから手作業で付けるより圧倒的に速い

3️⃣ Data acquisition の通常ラベリングとの違い

項目	従来	AI labeling
ラベル付与	完全手動	AIが提案
作業量	多い	大幅削減
精度	人の判断次第	モデル＋人
学習との循環	弱い	強い（反復）

👉
「人が主」→「AIが下書き、人が最終判断」
という役割分担になります。

4️⃣ どんな仕組みで動いている？

主に次のどれか（または組み合わせ）です。

① 既存の学習済みモデル

• すでに作ったモデルで未ラベルデータを推論
• 推論結果をラベル候補として使用

② 類似データ検索

• すでにラベル済みのデータと似ているものを探す
• 近いラベルを付与

③ ルール・ヒューリスティック

• 時間帯・メタデータ・センサー条件などを活用

5️⃣ 「NEW」と書いてある理由（重要）

この機能は：

• まだ進化途中
• プロジェクトやデータ形式によっては制限あり
• UIや挙動が今後変わる可能性あり

という意味で NEW が付いています。

👉
「全部自動で完璧」ではありません。
“人の判断を速くする道具”です。

6️⃣ Arduino UNO Q + センサーデータでの使いどころ

あなたのケースに当てはめると：

使いやすい場面

• App Lab や Edge Impulse で
  大量に集めた時系列データ
• 同じ動作・状態が何度も出てくる
• ラベルの種類が少ない（2〜5種程度）

まだ人手が必要な場面

• 新しい動作・異常系
• 境界があいまいなデータ
• 最初の「基準作り」

7️⃣ おすすめの使い方（実践順）

1. 最初は手動で少量ラベル付け
2. モデルを1回学習
3. AI labeling で未ラベルデータを補助
4. 人が確認・修正
5. 再学習
6. 繰り返す

👉
これが Edge Impulse が想定している王道フローです。

8️⃣ まとめ（超重要）

• AI labeling は
  👉 ラベル付けを“楽に・速く”する新機能
• 人の代わりではなく
  👉 人を補助するAI
• Arduino UNO Q + センサー開発では
  👉 データが増えてきた段階で真価を発揮

次に気になるポイントとしては、

• 「いつ AI labeling を使い始めるのが正解か」
• 「誤ラベルをどう見抜くか」
• 「Training / Test にどう影響するか」

このあたりを理解すると、
“AIに振り回されない使い方”ができるようになります。

以上が、Data acquisition 画面の説明。大まかな画面構成・メニュー構成が確認できた。

以降、Atlasから追加質問候補（合計２１個）が提示されたので、それらに対する回答を紹介する。

まとめて追加質問（最初の６個）

Atlasから、次の質問候補が提示されていたので、それらをまとめて質問した。

チャット画面に表示されたAtlasの回答

以下、ご指定の6点について、順に・実務目線で説明します。
全体を通しての前提は Edge Impulse は「実験を回しながらデータを洗練させる」ための道具だという点です。

Training と Test の違い

結論から

• Training：モデルに「答えを教えるためのデータ」
• Test：モデルに「初見問題を解かせるためのデータ」

役割の違い

項目	Training	Test
学習に使用	する	しない
モデルが見たことある	ある	ない
目的	覚えさせる	実力測定
誤ラベルの影響	学習が歪む	評価が歪む

👉
Test は「成績表」なので、ここが汚れていると「良い／悪い」の判断そのものが壊れます。

ラベルはどの粒度で付けるべきか

原則（とても重要）

人が迷わず、一貫して付けられる粒度

よくある失敗

• 細かすぎる
  例：歩く_速い / 歩く_少し速い / 歩く_普通
• 抽象的すぎる
  例：異常（何が？）

実務的な目安

• 最初は粗く（2〜4種類）
• 境界が説明できるかを自問する
  → 説明できない粒度はNG

👉
AIは「人の判断の一貫性」しか学べません。

Collect data と Upload data の使い分け

Collect data

• デバイス直結・リアルタイム
• センサー条件が明確
• その場で試しながら集めたいとき

向いている場面：

• Arduino UNO Q 接続直後
• 新しいセンサー追加時
• ラベルの妥当性確認

Upload data

• 既存データをまとめて投入
• App Lab のサンプル
• CSV / WAV / 画像など

向いている場面：

• 過去資産の評価
• 条件が固定されたデータ
• 大量データの一括投入

👉
Collect = 現場／Upload = 倉庫

いつ AI labeling を使い始めるのが正解か

正解のタイミング

「自分で正解が言えるデータ」が少し溜まったあと

具体的には：

• 各ラベル 10〜30サンプル以上
• 人が「これは○○だ」と即答できる状態

早すぎるとどうなる？

• AIが適当な基準を作る
• 誤ラベルが量産される
• 後で直すコストが激増

👉
AI labeling は“加速装置”であって“起爆装置”ではありません。

誤ラベルをどう見抜くか

王道チェック方法

① 波形・グラフを見る

• 同じラベルなのに形が明らかに違う
• ノイズだけの区間に意味ラベル

② Test 精度だけ異常に低い

• Training 高精度 / Test 低精度
  → ラベル or 分布が怪しい

③ クラス間で混同行列を見る

• 特定の2ラベルだけ誤認識が集中

④ 「自分に説明できるか」

• なぜこのラベルなのか言語化できない → 要再確認

👉
AIは嘘をつかないが、人のミスを忠実に再現する。

Training / Test にどう影響するか

誤ラベルが Training にあると

• モデルが間違いを学習
• 精度は出ているように見える
• 実機で使えない

誤ラベルが Test にあると

• モデルが良くても評価が低い
• 改善方向を誤る
• 無駄なデータ追加をしがち

AI labeling 使用時の注意

• Training 側に入れる前に必ず人が確認
• Test は原則「人が確認済みのみ」

👉
Test は最後まで“人間の基準”を守る場所です。

全体まとめ（重要）

• Training：教科書
• Test：試験
• ラベル粒度：人が迷わない単位
• Collect / Upload：用途で使い分け
• AI labeling：基準確立後に使う
• 誤ラベル：精度より「違和感」を信じる

ここまで理解できていると、
「データを集める人」から「AIを設計する人」の段階に入っています。

次に進むなら：

• 「最初の失敗しないデータ収集数」
• 「ラベルを増やす判断基準」
• 「Test を減らしていいケース／ダメなケース」

このあたりが実戦的です。

---

チャット画面に表示されたAtlasの回答

以下、ご指定の3点について、順に・判断基準が分かる形で説明します。
前提として、Edge Impulse は「少量 → 検証 → 追加」を高速で回す設計になっています。

最初の失敗しないデータ収集数

結論（最小安全ライン）

1ラベルあたり「20〜30サンプル」から開始

これは「本番用」ではなく、
“方向性が合っているかを確認するための最低限”です。

なぜこの数か

• 10以下 → 偶然に強く引っ張られる
• 20〜30 →
  • 特徴が安定し始める
  • 明らかな誤りが見える
• 50以上 → 改善フェーズ

例（3ラベルの場合）

• 最初：
  • 30 × 3 = 約90サンプル
• これでやること：
  • 学習
  • Test 確認
  • 「無理そうか／いけそうか」を判断

👉
最初から大量に集めるのは失敗の元です。

ラベルを増やす判断基準

結論

「誤認識の理由が“量”ではなく“意味”の問題になったとき」

ラベルを増やすべきケース（OK）

• 混同行列で
  • A と B が常に混ざる
• 人が見ても
  • 「これは別物だ」と説明できる
• 追加ラベルの定義が
  • 誰がやっても同じ判断になる

例：

• normal に
  • 明確に異質な abnormal_pattern が混じる

増やすべきでないケース（NG）

• 単に精度が低い
• データが少ないだけ
• 境界が曖昧で言語化できない

例：

• 動作A_やや強い
• 音B_ちょっと高い

👉
ラベルは「精度改善の道具」ではなく「意味の分離」です。

Test を減らしていいケース／ダメなケース

基本原則

• 標準：80% Training / 20% Test
• ただし状況により例外あり

---

✅ Test を減らしていいケース

1. データ総数が少ない初期
   • 総数 < 100 のとき
   • 90 / 10 でもOK
2. 探索フェーズ
   • 「この問題は解けそうか？」を見る段階
   • 精度の絶対値より傾向重視
3. 同条件・同環境のみ
   • 実験室内
   • 条件がほぼ固定

👉
この場合、Test は
“参考値”として扱う

---

❌ Test を減らしてはいけないケース

1. 実運用が近い
   • 現場投入前
   • 実機評価前
2. 環境差がある
   • 場所・人・時間帯が変わる
   • センサー取り付け差
3. AI labeling を多用している
   • Training が半自動
   • Test は最後の砦
4. 「精度◯%」を根拠に判断する場面
   • 報告
   • 比較
   • 判断材料

👉
この段階で Test を削るのは危険です。

3点をつなげた実践フロー（重要）

1. 少量（20〜30/ラベル）で開始
2. Training / Test を軽く回す
3. 誤認識の理由を見る
   • データ不足 → 追加
   • 意味混在 → ラベル分割
4. AI labeling は「基準確立後」に投入
5. 最終段階で Test をしっかり確保

---

最後に（設計思想として）

• データ数は 「正しさ」より「意味」
• ラベルは 「増やす勇気」より「増やさない勇気」
• Test は 「邪魔」ではなく「保険」

この感覚が身につくと、
Edge Impulse を「操作」する段階から「設計」する段階に入れます。

次に進むなら：

• 「精度が上がらないときに見るべき3点」
• 「実機でズレる原因の切り分け」
• 「モデルよりデータを直す判断基準」

このあたりが“現場対応力”に直結します。

---

チャット画面に表示されたAtlasの回答

以下、ご指定の3点について、現場でそのまま使える判断軸として順に説明します。
前提は Edge Impulse では「モデル調整より先に、必ず確認すべきポイントがある」という考え方です。

精度が上がらないときに見るべき3点

結論（優先順位）

① データの意味 → ② データの分布 → ③ モデル設定

多くの場合、①と②で原因が見つかります。

---

① ラベルの「意味」が一貫しているか（最重要）

確認すること：

• 同じラベルの中に
  • 明らかに違う状態・動作が混じっていないか
• 人が見て
  • 「これは同じと言い切れるか？」

典型的な問題：

• normal の中に
  • 静止
  • 微動
  • ノイズ多発
    が混在

👉
意味が混ざったラベルは、精度が上がりません。

---

② Training / Test の分布がズレていないか

確認すること：

• Test にしか出てこないパターンがないか
• Training が「きれいすぎないか」

典型例：

• Training：実験室で丁寧に取得
• Test：実環境で雑音あり

👉
精度が低いのではなく「想定外」が多いだけの可能性。

---

③ モデル以前に特徴量が出ているか

確認すること：

• DSP後の特徴グラフに
  • ラベル間の差が見えるか
• 人が見て
  • 「違う」と分かるか

👉
人に見えない差は、モデルにも見えません。

---

実機でズレる原因の切り分け

結論

「データ取得時」と「推論時」の条件差を1つずつ潰す

よくあるズレの原因（優先度順）

① センサー条件の違い

• 取り付け位置
• 向き
• 固定／手持ち

👉
学習時と1cm違うだけで別世界になることもあります。

② 時間条件の違い

• サンプリング周期
• ウィンドウ長
• 推論間隔

確認：

• Edge Impulse の DSP 設定
• 実機コードの設定

👉
ms単位のズレが致命的なケースあり。

③ 前処理の違い

• 正規化
• フィルタ
• オフセット除去

よくある事故：

• 学習時：自動で前処理あり
• 実機：素の値を投入

切り分けの王道手順

1. 実機データを そのまま Data acquisition に取り込む
2. Studio 上で推論させる
   • 合う → 実装問題
   • 合わない → データ問題

👉
「モデルが悪い」と言う前にここまでやるのが鉄則。

モデルよりデータを直す判断基準

結論（覚えるべき一文）

「人が見て納得できないデータは、モデルでも無理」

モデルを疑う前にデータを直すべきサイン

• ラベル定義を言語化できない
• 同じラベル内のばらつきが大きい
• 誤認識に一貫性がない
• Test 精度が極端に不安定

👉
この状態でモデル調整しても改善しません。

モデル調整が意味を持つケース

• データ量は十分
• ラベルは明確
• 誤認識の傾向が一貫している
• DSP 特徴は分離できている

👉
この条件が揃って初めて、モデルの出番です。

3点を統合した判断フロー（超重要）

1. 精度が低い
2. ↓
   ラベルの意味を見る
3. ↓
   Training / Test の分布を見る
4. ↓
   特徴量を見る
5. ↓
   • 人が分かる → モデル改善
   • 人も分からない → データ再設計

最後に（設計者視点）

• モデルは「拡声器」
• データは「声の内容」

👉
内容が曖昧なら、どんな拡声器でも伝わりません。

ここまで理解できているなら、次に踏み込めるテーマは：

• 「ラベル設計を先に決める方法」
• 「現場ノイズをあえて入れる戦略」
• 「失敗データを価値に変える集め方」

この段階に来ているのは、かなり良い位置です。

---

チャット画面に表示されたAtlasの回答

了解しました。
ここでは 「実務で失敗しにくい考え方」に絞って、3点を設計→収集→改善の流れとして説明します。
前提は Edge Impulse は“学習ツール”ではなく“設計検証ツール”でもある、という視点です。

ラベル設計を先に決める方法

結論

ラベルは「分類したい現象」ではなく「使う側の判断」に合わせて決める

ステップ1：AIの出力で「何を決めたいか」を言語化する

まず、人の判断を文章にします。

例：

• ○「異常ならアラートを出したい」
• ○「状態AとBで処理を分けたい」
• ✕「とりあえず分類したい」

👉
“分類”ではなく“行動”がゴールです。

ステップ2：人が迷わず決められる境界を探す

自分にこう問いかけます：

• これは誰が見ても同じラベルか？
• 5秒で説明できるか？
• 例外が多すぎないか？

悪い例：

• normal / slightly abnormal / abnormal

良い例：

• moving / stopped
• sound_present / no_sound

👉
グラデーションはNG、二択に近づけるのがコツ。

ステップ3：「将来いらないラベル」を作らない

よくある失敗：

• 将来使うかも、で細かく分ける
• 結局、統合することになる

原則：

ラベルは後から増やせるが、後から意味は揃えにくい

現場ノイズをあえて入れる戦略

結論

ノイズは敵ではなく「実環境の教師」

なぜノイズを入れるべきか

• 実機では必ず混ざる
• テスト時に初登場するのが一番危険
• 「きれいなデータだけ」は幻想

👉
ノイズ＝本番環境そのものです。

入れ方の正解（段階的）

フェーズ1：最低限の安定データ

• 条件を揃えて収集
• ラベルの意味を固定

👉 土台作り

フェーズ2：意図的ノイズ投入

• 位置をずらす
• 時間帯を変える
• 背景音・振動を足す

👉
「正解ラベルのまま条件だけ崩す」

フェーズ3：境界ノイズ

• 判断が迷うケース
• ギリギリの状態

👉
モデルが迷う理由を作る

やってはいけないノイズ

• ラベルが曖昧なまま追加
• 本来別クラスのものを混ぜる

失敗データを価値に変える集め方

結論

誤認識データは「最高品質の教材」

失敗データの正体

• モデルが自信満々で間違えた
• 特定条件で必ず失敗する
• 人は簡単に見分けられる

👉
「境界条件」が詰まっている

価値に変える3ステップ

ステップ1：失敗を捨てない

• 削除しない
• まず保存

👉
「邪魔」ではなく「ヒント」

ステップ2：失敗理由を分類する

例：

• センサー位置違い
• ノイズ過多
• ラベル境界が曖昧

👉
原因でタグ分け（メモでOK）

ステップ3：使い方を決める

• 既存ラベルに追加？
• 新ラベルを作る？
• そもそも仕様外として無視？

👉
“データ”ではなく“設計”を直す判断材料にする

3つを統合した実践フレーム

1. ラベルは「行動」から逆算
2. 安定 → ノイズ → 境界 の順で収集
3. 失敗は削除せず、設計を磨く材料にする

一番大事な一文

良いAIは、良いデータではなく「良い失敗」から育つ

この考え方が身につくと、

• 精度が上がらないと焦らない
• 次に何を集めるべきか迷わない
• モデル調整に無駄な時間を使わない

という状態になります。

次に進むならおすすめは：

• 「ラベルを増やす vs 統合する判断フロー」
• 「現場で“これ以上集めなくていい”と判断する基準」
• 「精度90%でも使えないケースの見抜き方」

どれにしますか？

---

チャット画面に表示されたAtlasの回答

了解しました。
ここでは 「迷いが発生するポイントに“判断の物差し”を置く」ことを目的に、3点を順に・実務判断レベルで説明します。
前提は Edge Impulse を“精度を見る道具”ではなく“設計判断を下す道具”として使う、という考え方です。

ラベルを増やす vs 統合する判断フロー

結論（最初に覚える一文）

「人の判断が分かれるなら増やす／人の判断が揃わないなら統合する」

判断フロー（上から順に確認）

ステップ1：人は即答できるか？

• 3秒以内にラベルを言える → 次へ
• 迷う／説明が長くなる → 統合

👉
人が迷う境界は、AIも必ず迷います

ステップ2：誤認識に“型”があるか？

• 毎回同じ条件で間違う → 増やす候補
• バラバラに間違う → 統合 or データ不足

例：

• いつも「弱い振動」だけ誤認識
  → weak_vibration を追加する意味あり

ステップ3：増やしたラベルで“行動が変わるか？”

• 出力ごとに処理・アクションが変わる → 増やす
• 結局同じ扱い → 増やさない

👉
使われないラベルは負債です。

典型パターンまとめ

状態	判断
境界が曖昧	統合
誤認識が特定条件に集中	増やす
行動に差がない	統合
将来使うかも	統合

現場で「これ以上集めなくていい」と判断する基準

結論

「新しい失敗が出なくなったら、いったん止めてよい」

NGな判断基準

• ○「件数が○○に達した」
• ○「なんとなく十分そう」

👉
数ではなく“情報量”で判断します。

OKな判断基準（3つ揃えば止めてよい）

① 新しい誤認識パターンが出ない

• 失敗はするが、既知の失敗
• 初見の「なんで？」が出てこない

② Test 精度が上下しても傾向が同じ

• 数字は多少揺れる
• でも、間違うラベルは毎回同じ

👉
モデルが学び切ったサイン

③ 人が見て「これ以上変わらない」と感じる

• 波形・特徴量を見ても新鮮味がない
• ノイズも出尽くした感覚

👉
この段階で無理に集めると
“薄いデータ”が増えるだけです。

実務的な止め方（おすすめ）

• 一度学習を止める
• 実機テストに集中
• 実機で出た失敗だけを再収集

精度90%でも使えないケースの見抜き方

結論（重要）

「平均精度は高くても、致命的な10%があると使えない」

見抜くべき3つの観点

① 間違ってはいけないケースで間違えていないか

例：

• 異常検知で異常を見逃す
• 危険判定で安全と出す

👉
この1回の失敗がアウトなら、90%は意味がない

② 間違い方が“自信満々”ではないか

• 低信頼での誤認識 → 許容可能
• 高信頼での誤認識 → 危険

👉
確信を持って間違うAIは現場で信用されません

③ 誤認識が“特定条件に集中”していないか

• 特定時間帯
• 特定姿勢
• 特定環境音

👉
この場合、精度より「条件依存」が問題

「使える90%」と「使えない90%」の違い

観点	使える	使えない
失敗の種類	軽微	致命的
失敗条件	限定的	現場頻発
信頼度	低信頼時のみ	高信頼で誤る

3点をまとめた“現場判断ルール”

• ラベルは「人の判断」が基準
• データは「新しい失敗」が止まったら止める
• 精度は「平均」ではなく「最悪ケース」で見る

最後に（設計者向けの一文）

AIは“正解を当てる装置”ではなく
“間違い方を設計する装置”

この視点を持てると、

• ラベルで迷わなくなり
• 収集を止める勇気が持て
• 数字に振り回されなくなります。

次に深掘りするとしたら、

• 「信頼度（confidence）をどう使うか」
• 「誤認識を前提にしたUI／制御設計」
• 「AIを“判断補助”として使う設計」

このあたりが次のステップです。

---

チャット画面に表示されたAtlasの回答

了解しました。
ここでは 「AIを“当てる装置”から“安全に使える部品”に変える設計思考」として、3点を順に・実装判断レベルで説明します。
前提は Edge Impulse の出力は“答え”ではなく“情報”であるという考え方です。

信頼度（confidence）をどう使うか

結論（最重要）

信頼度は「当たっている確率」ではなく
「その判断を使ってよいかの指標」

よくある誤解

• ✕ 0.9以上なら正しい
• ✕ 数字が高いほど安心

👉
confidence は“モデルの自信”であって“正解保証”ではありません

正しい使い方①：三段階に分ける

例（分類モデル）：

confidence	扱い
高（例：≥0.8）	自動で使う
中（例：0.5〜0.8）	保留・再確認
低（<0.5）	判断しない

👉
0/1で使わない。必ず“グレー”を作る

正しい使い方②：ラベルごとに閾値を変える

• normal：0.7でOK
• abnormal：0.9以上のみ採用

👉
危険側のラベルほど厳しく

正しい使い方③：confidence の変化を見る

• 単発の値 → 使わない
• 時系列で安定 → 信頼

例：

• 3回連続で0.85以上 → 採用
• フラフラ → 無視

👉
confidence は「傾向」で使う

誤認識を前提にしたUI／制御設計

結論

AIが間違える前提で“逃げ道”を用意する

UI設計の基本原則（3つ）

① AIの判断を「断定表示」しない

• ✕「異常です」
• ○「異常の可能性があります（85%）」

👉
人に判断を返す余地を残す

② AIの状態を見せる

• confidence を色で表示
• 「判断不可」「不明」を表示できる

👉
沈黙より“不明”の方が安全

③ 誤認識しても事故にならない導線

• 自動停止ではなく通知
• ワンクッション挟む

例：

• 即制御 → NG
• 「確認してください」→ OK

制御設計での鉄則

状態	挙動
高信頼・安全	自動
低信頼	何もしない
高信頼・危険	人に確認

👉
AIに“最後の決定権”を与えない

AIを「判断補助」として使う設計

結論（設計思想）

AIは「Yes / No」を出すのではなく
「人が考える材料」を出す存在

判断補助としての典型パターン

パターン①：絞り込み役

• 全体 → AIが怪しい候補を提示
• 最終判断 → 人

例：

• 音の中から「怪しい区間」だけ抽出

パターン②：優先度付け

• 重要度スコアを出す
• 人は上位から見る

👉
「全部見る」をやめられる

パターン③：変化検知

• いつもと違う、だけを通知
• 正解ラベルを決めない

👉
分類しないAIも立派なAI

判断補助設計のチェックリスト

• AIがなくても最低限動くか？
• AIが間違っても致命傷にならないか？
• 人はAIを「疑える」か？

👉
YESが3つ揃えば安全

3点を貫く共通ルール

• confidence は「使う／捨てる」の判断材料
• 誤認識は“想定内”にする
• AIは決めない、人が決める

最後に（現場で一番効く一文）

良いAI設計とは
AIを信用しすぎない設計である

ここまで来ると、

• 精度に一喜一憂しなくなり
• データ収集の目的が明確になり
• 「使えるAI」と「デモAI」を見分けられる

ようになります。

もし次に進むならおすすめは：

• 「confidence を使った具体的な制御ロジック例」
• 「異常検知で“異常と出さない”設計」
• 「現場オペレータがAIを信頼するまでの段階設計」

どれを深掘りしますか？