AIで記事を書く。AIで翻訳する。AIでリンクを直す。AIでアクセスを集計する。AIに「ここ分かりにくくない？」と聞いて、またAIで直す。
ここまで来ると、だいたい次の問題が出る。
全員、サイトのことを知りすぎている。
作った側はボタンの意味を知っている。AIは仕様を読めば「このボタンは関連記事です」と理解する。運営者は何度も見ているので、多少変でも脳内で勝手に補完する。
でも初めて来た人は違う。
「これ何？」 「どこ押すの？」 「なんでここだけ英語？」 「戻れないんだけど」 「文章は読めるけど、なんか気持ち悪い」
この「なんか」が欲しい。
そこで最終的に出てきた案が、だいぶ面白い。
とうとう人間をデバッグ工程に外注する。
しかも、1つの指摘につき1円。1人あたり最大1000円。
人間がAIの仕事を奪う時代が来た。担当業務は「違和感」である。
1. 外注したいのはコードレビューではなく「初見の引っかかり」
今回ほしいのは、専門家による大規模な監査ではない。
- ボタンの意味が分からない
- 次にどこへ行けばいいか分からない
- 見出しが妙
- スマホだと押しにくい
- リンク先の言語が違う
- 何かを押したら真っ白になった
- 文章としては成立しているが、人間が読むと変
- ここにこの機能があると便利そう
こういうものだ。
Digital.govはユーザビリティテストを、実際の利用者が製品やサービスを使おうとする様子を観察する方法として説明している。[1] GOV.UKも、実ユーザーの操作を見ることで、言語やレイアウトなど具体的な問題を見つけられるとしている。[2]
つまり「人間に一度触らせる」は、AI時代になって急に生まれた謎の儀式ではない。
昔からあるユーザビリティテストが、AIで大量生産・大量修正できるサイトに戻ってきただけである。
2. 運営者本人が一番まともにテストできないことがある
自分のサイトを毎日ちゃんと見る。
言うのは簡単だが、記事が増え、言語が増え、機能が増えたら普通に無理である。
しかも「作った人が見る」には別の問題がある。
どこに検索があるか知っている。 関連記事がどこに出るか知っている。 言語切替の仕様も知っている。 多少おかしくても「そういうもの」として通過する。
そして何より、見るのがめんどくさい。
ここは意外と重要である。
めんどくささを精神論で殴って「毎日100ページ確認しよう」にすると、その運用は長く続かない。だったら、めんどくさい工程そのものを分離する。
運営者は全部見る人ではなく、
何を見るべきか決め、集まった異常を直す仕組みを作る人
になればいい。
3. 1件1円で買っているのは「アイデア」ではなく fresh eyes
1件1円という数字だけ見ると、ものすごく安い。
でもここで買いたいものは、立派なコンサル資料ではない。
初見の目で一回引っかかったという事実である。
1人が1000個出せば1000円。 ただし、同じ内容を言い換えただけなら1件。 1人あたりの報酬上限も1000円。
この上限はかなり大事だ。
「いっぱい出してほしい」と言った瞬間、世界は突然「AIに改善点1万個出させれば1万円では？」という方向へ進み始める。
なので、件数インセンティブと同時に、
- 実際にサイトを見ていること
- 実在する場所・挙動について書くこと
- 同じ指摘の言い換えを水増ししないこと
- 上限を決めること
をセットにする。
なお、1件1円はこのケースの実験設計であって、普遍的な適正報酬ではない。長時間の作業や専門的な評価を求めるなら、時間や難易度に見合う条件へ変える必要がある。
4. 最大の敵は「AIで改善点を1万個作りました」
AI利用を禁止する必要はない。
問題は、サイトを一度も見ていない改善案である。
「一般的にWebサイトではナビゲーションを分かりやすくしましょう」 「アクセシビリティを改善しましょう」 「レスポンシブ対応を最適化しましょう」
全部正しい。
そして全部、今回ほしいものではない。
ほしいのは、
「このページのこのボタン、押したら何が起きるか分からなかった」 「この見出しの次に突然話題が飛んだ」 「この言語版だけ関連記事が別言語に飛んだ」
という観察だ。
AIは、その観察を短く整形したり、重複をまとめたりする補助には使える。
人間が発見し、AIが整理する。
順番を逆にしないのが重要である。
5. 1件ずつチャットで送られると、依頼者が先に死ぬ
報告数を増やしたいなら、提出方法も設計しないといけない。
一番つらいのは、
「1件目です」 「2件目です」 「そういえば3件目」 「追加で4件目」
とチャットが永久に伸びる方式である。
これではデバッグを外注したのに、今度は報告回収という新しい手作業が生まれる。
そこで提出は一括。
- Excel
- スプレッドシート
- txt
- 番号付きリスト
- コピペできるテキスト
なら何でもいい。
スクリーンショットも原則不要。画像は見るには便利でも、後で検索・重複排除・AI処理するときの摩擦が大きい。
GOV.UKのユーザー研究ガイドでも、タイピングしたノートは後から保管・分析しやすく、1つの観察を1項目に分けると並べ替えや分析がしやすいとしている。[3]
フォーマットは単純でいい。
場所 / 今どうなっているか / どうするとよさそうか
バグなら、
場所 / 何をしたか / 何が起きたか
これだけで、後段のAIがかなり働ける。
6. 多言語サイトでは「翻訳できた」と「人間が読める」は別問題
多言語サイトはさらに面白い。
機械上は12言語すべて生成成功。 ビルドも成功。 HTTP 200。 リンクも存在する。
それでも、人が見ると普通に変なことがある。
- 一部だけ元言語が残る
- ボタンだけ翻訳が妙
- 文として意味は通るが、母語話者には不自然
- 文字が長くなってレイアウトが崩れる
- 言語切替後、関連記事だけ元言語へ戻る
- 同じ記事のはずなのに一部が欠ける
ここは読める人だけ見ればいい。
英語が読める人は英語。 韓国語が読める人は韓国語。 中国語、スペイン語、ポルトガル語、インドネシア語、タイ語、ベトナム語、フランス語、ドイツ語も同じ。
全員に全言語を見せる必要はない。
機械が「生成できた」を確認し、人間が「これ普通に読める？」を確認する。
役割が違う。
7. 重複は報酬上は1件でも、分析上はめちゃくちゃ重要
同じ人が、
「ボタンが分かりにくい」 「ボタンの意味が不明」 「このボタン何？」
と3回書いたら、それは1件でいい。
しかし、別々の3人が独立して同じボタンで止まったら話が変わる。
それは単なる重複ではなく、再現性のある摩擦である。
だから集計するときは、
- 同一人物内の言い換え → 統合
- 別人物からの独立した同一指摘 → 頻度として保持
と分ける。
「3人が同じところで迷った」は、運営者の好みより強い。
GOV.UKも実際または想定される利用者で頻繁にユーザビリティを確認し、利用者の行動を反映する端末群でテストすることをサービス標準としている。[4]
人数を増やす意味は「意見投票」ではなく、同じ摩擦が別の人にも起きるかを見ることにある。
8. 完成形は AI → 人間 → AI。人間はセンサーになる
最終的な工程はかなりきれいになる。
- AIが記事を生成する
- AIが翻訳する
- AIがリンク・構造・表示を検査する
- AIが既知の問題を修正する
- 人間が実際に読む・押す・迷う
- 人間が「なんか変」をテキストで出す
- AIが重複を統合する
- AIが重大度・再現性・修正コストで分類する
- AIが修正候補を作る
- 修正後、また機械検査と人間確認へ戻す
とうとう、人間までパイプラインの一工程になった。
ただし、人間に残った仕事は単純作業ではない。
人間だから感じる摩擦を検出することである。
これはむしろ役割の格上げに近い。
機械に「リンクが404か」を見てもらい、人間には「404ではないけど、なぜここへ飛ばされたのか分からない」を見てもらう。
機械に「翻訳文字列が存在するか」を見てもらい、人間には「存在するけど普通の人はこう言わない」を見てもらう。
その方が分業として自然だ。
9. テスターが見ればPVも増える。でもそこを目的にしない
当然、サイトを何十ページも見てもらえば閲覧数は増える。
広告があるサイトなら、通常の閲覧に伴って表示が発生する場合もある。
ただしこれは完全に副産物である。
広告をクリックしてもらう、広告表示を増やすことを作業条件にする、といった設計は別問題になる。
買っているのはPVではない。
人間がページを見た結果として残る観察である。
そのついでにアクセスが少し増えたなら、「ユーザーテストしていたらレジも少し鳴った」くらいに考えるのがちょうどいい。
10. 自動化の終点は「人間ゼロ」ではなかった
AIを使い始めると、つい「どこまで人間を消せるか」を考えたくなる。
でも実際に自動化を進めると、逆の結論になることがある。
人間を全部消す必要はない。
人間にしか価値が出ない場所まで、人間を移動させればいい。
記事の下書き。 翻訳。 重複整理。 リンク検査。 分類。 集計。 修正案。
このあたりは機械に寄せる。
そして最後に、
「初めて見たけど意味分からん」 「ここ嫌」 「なんか変」 「これ便利」
だけ人間から買う。
1件1円で買っているのは、1行の文章ではない。
自分でもAIでも持てない、別の人間の一瞬の違和感である。
自動化を突き詰めた先で、人間が戻ってきた。
しかも担当部署は「なんか変」。
めちゃくちゃ人間らしい。
出典
参考資料（4件）
- Digital.gov, “Usability testing digital.gov
- GOV.UK Service Manual, “Using moderated usability testing gov.uk
- GOV.UK Service Manual, “Taking notes and recording user research sessions gov.uk
- GOV.UK Service Manual, “4. Make the service simple to use gov.uk
