課題
AIに「似ている・似ていない」を自動判定させる機能を作るとき、「だいたいこのくらいの数値を境目にすればいいだろう」と、しきい値を勘や一般論で決めてしまいたくなる。今回、新しく開発しているタイマーアプリで、作業メモの内容から似た作業をグループ分けする機能を作った際、まさにこの誘惑に負けそうになった。
解決できるようにすること
AI機能のしきい値やパラメータを、実際のデータを測定してから決められるようにする。あわせて、単純な機能を作った直後に、より深い要望が分かって作り直すことになった経緯も紹介する。
先に結論
端末上で「意味の近さ」を測る機能を実装し、実際の作業メモ8ペアで類似度を測定したところ、明確な言い換えペアが、明らかに無関係なペアより低いスコアになるという、直感に反する結果になった。原因を調べると、使っていたAIモデル特有の既知の問題だと分かり、補正を加えて実測し直した結果、ようやくしきい値を決められる状態になった。
さらにその直後、単純な機能を1つ作って動作確認する直前になって、「本当はもっと違うことがしたかった」という要望が判明し、その機能を丸ごと作り直すことになった。
この記事でわかること
- AIの類似度判定で、しきい値を勘で決めると何が起きるか
- 実測データからしきい値を決める具体的な手順
- 機能を作った直後に、より深い要望が分かって設計をやり直した経緯
まず8ペアで測ってみたら、様子がおかしかった
作業メモを短い文章で入力してもらい、AIモデルでその意味を数値化（埋め込みベクトル化）し、過去のメモとの類似度を計算して自動でグループ分けする機能を考えていた。
しきい値は「0.7くらいにしておけば大丈夫だろう」と当初は決め打ちにしそうになったが、実際に運用する前に、実機で8ペアの作業メモを測定してみることにした。
こう思う人もいるかもしれない。
「似ている言葉同士なら、素直に高いスコアが出るのでは？」
結果は逆だった。明確な言い換えペア（同じ作業を違う言い回しで書いたもの）のスコアが、明らかに無関係なペアのスコアより低く出た。しかも8ペア全体のスコアが狭い範囲に密集していて、しきい値をどこに引いても言い換えと無関係を分離できない状態だった。
「あれ、これじゃ使い物にならないぞ」というのが正直な感想だった。
原因を調べたら、モデル自体の既知の癖だった
なぜこうなるのかを調べたところ、使っていたのはOS内蔵の固定モデルで、追加学習（ファインチューニング）ができないタイプだと分かった。そして、観測された現象は、そうしたモデル特有の既知の問題（無関係な文同士でも高い類似度を示してしまう傾向）と一致していた。
対策として、比較的低コストな緩和策があることも分かった。あらかじめ用意した多様な文章群の平均的な特徴を差し引いて補正する、というやり方になる。
補正して測り直したら、はっきり分離できた
補正を実装し、作業系・生活系・趣味系にわたる多様な文章40件の平均を差し引く形で再測定した。
結果、明確な言い換えペア2件が、補正後のスコアで他を大きく引き離して上位になった。「お、ちゃんと分離できた」という手応えがあった。この実測データから、最も紛らわしい無関係ペアと、最も紛らわしい言い換えペアの間にしきい値を置くことで、明確なケースは正しく自動分類できると判断した。
それでも残った、1つの例外
ただし、これで完璧というわけではなかった。文法構造が似ているだけの無関係なペアが、文法構造の異なる本当の言い換えペアより高いスコアになる、という例が1件残っていた。
しきい値の調整だけでは、この種の紛らわしいケースを完全には解消できないと判断した。そこで、しきい値未満のケースでは「最も近い既存の分類と、その近さ」を提示し、人が最終的に「同じ分類に含める」か「新しい分類にする」かを選べる仕組みを追加することにした。アルゴリズムの限界を、人の確認で補う形になる。
検証用に作った一時的な確認画面は、正式な機能が完成した段階で削除した。実機で試行錯誤するための仮の道具だったので、役目を終えたら片付ける、という当たり前のことではあるが、あらためて意識した。
機能を作った直後に、要望の掘り下げが起きた
しきい値の検証と並行して、もう1つ機能を作っていた。1回分の作業ごとに、内容を後から変更できるボタンになる。実装・ビルドまで完了し、実機で確認する直前だった。
そのタイミングで、「1回ごとに切り替えるのではなく、作業を始める時点で複数回分の計画をまとめて立てたい」という、より深い要望があると分かった。単純な変更ボタンでは、この要望を満たせない。
「せっかく作ったのに」という気持ちもよぎったが、実際に使う場面を考えると、作った機能では望まれていたものにならないのは明らかだった。結局、単純な変更ボタンは撤去し、複数回分の計画を事前に立てて、実行中に差し替えたり繰り返したりできる、より大きな計画機能を作り直すことになった。
気づいたこと
- AIの類似度判定は、モデルによっては「無関係な文同士でも高いスコアが出やすい」という癖があり、実測しないと気づけない
- しきい値は、実測した「最も紛らわしい無関係な例」と「最も紛らわしい正解の例」の間に置くと、根拠を持って決められる
- しきい値の調整だけでは解消できない例外が残ることもある。その場合は、無理に精度を追い求めず、人の確認で補う設計にするという選択肢がある
- 機能を作り終えた直後でも、実際に使う前に要望を確認し直す価値がある。今回は実機確認の直前に気づけたので、作り直しの手戻りを最小限にできた
こんな人に向いている
AIに「似ている・似ていない」のような判定をさせたい人には、しきい値を勘で決めず、実際のデータで測ってから決めるという手順が参考になる。特に、モデルの癖で予想と逆の結果が出ることもある、という点は覚えておく価値がある。
一方、「AIに任せれば自動で正確に判定してくれる」と期待しすぎている人には、今回のように、しきい値調整だけでは解消できない例外が残ることもある、という現実を知る材料になる。
まとめ
| 項目 | 内容 |
|---|---|
| 結論 | AIの類似度判定は実測してみると直感に反する結果が出ることがある。しきい値は実測データの隙間に置いて決め、それでも残る例外は人の確認で補う設計にした |
| 教訓 | 機能を作った直後でも、実際に使う前に要望を確認し直すと、手戻りを小さくできる |
| 対象読者 | AI機能のパラメータ・しきい値を設定したい人、要望をどこまで掘り下げて確認すべきか悩んでいる人 |
同じ状況に陥ったときの回避策
- AIの類似度・スコアリング機能を作るときは、しきい値を決め打ちにせず、実際のデータで測定してから決める
- 測定結果が直感と違うときは、そのモデル特有の既知の癖が無いか調べてみる
- 完璧な自動判定を目指すより、際どいケースは人の確認で補う設計にする方が現実的な場合がある
- 機能を実装し終えても、実機確認や公開の前に、要望をもう一段掘り下げて確認する
この記事は、筆者が実際に個人開発している複数のモバイルアプリのうち、新しく開発しているタイマーアプリの開発記録（2026年9月8日〜10日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。
