この記事は、連載「言わない技術」の第 3 回です。各回はファイルやスクリプトを一つ置けば完結します。連載の全体像と各回の一覧は序論にあります。
今回は、AI に不具合を伝えるときの話です。どの画面で、何をしたら、何が出たか。以前は毎回、私がそれを書いていました。いまは書いていません。動かして、コピーして、貼るだけです。
前作「AIの意見を聞かない技術」の第 6 回で、本番の不具合は踏んだ人から届くと書きました。届く先の一つが、不具合報告のフォームです。あの回では、機械が判定できないものを人のところへ溜める網でした。今回は、同じフォームを私が使います。
まず一つだけ、思い出してみてください。直近で AI に不具合を直させたとき、あなたが打った文章です。再現手順、URL、エラーの文言、ブラウザ。そのうち、あなたにしか書けなかったものは何行ありましたか。
CC BY 4.0
書いていたのは、画面が知っていることでした
不具合の報告は、書くのに時間がかかります。どの URL か。どの曲か。何をクリックしたか。コンソールに何が出ていたか。画面の大きさは。書き終えて AI に渡し、足りないと聞き返され、また画面を開いて確かめる。
書きながら気づいたのは、その大半を、私は画面から書き写していることでした。URL はアドレスバーに出ています。エラーはコンソールに出ています。画面はそこにあります。私が知っていて画面が知らないのは、「何が変だと思ったか」の一文だけです。
私の手元の本番プロジェクト——typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです——には、ユーザー向けの不具合報告のフォームがあります。ある日から、自分で見つけた不具合も、そのフォームから送るようになりました。運営者用の入口を別に作ったのではありません。ユーザーと同じフォームを、同じ画面で押します。
理解したことは一文にできます。
不具合の詳細は、人が思い出して書くものではなく、その場の画面が知っているものだ。だから書く代わりに、画面に集めさせて、そのまま貼る。
仕組み: 人が打つのは、症状の一文だけにする
置くのはフォーム 1 つです。ただし、集めるものの大半を人に書かせません。
// app/javascript/controllers/feedback_controller.js(実物からの簡約版)
const payload = {
category: this.categoryValue, // 選ぶだけ(不具合 / 要望 / 歌詞の間違い)
comment: this.commentTarget.value, // ← 症状の一文。人が書くのは、ここだけ
page_url: window.location.pathname + window.location.search, // どこで(画面が知っている)
screenshot_data: includeScreenshot ? this._screenshotData : null, // 画面そのもの(html2canvas)
console_logs: includeConsoleLogs ? getErrorLog().slice(-20) : [], // 直近 20 件。スタックトレース込み
screen_resolution: `${window.screen.width}x${window.screen.height}`
}
サーバー側は、これに送信日時と環境の情報を足します。人が打つのは、症状の一文と、チェック 2 つだけです。
届いた 1 件は、管理画面に一式で並びます。ページ URL、カテゴリ、環境、スクリーンショット、コンソールログ、そして症状の一文。私がやるのは、そのページを開いて、全部コピーして、AI に貼ることです。打つ言葉は要りません。貼った時点で、着手に要るものは揃っています。
⚠️ ここで集めているのは事実だけです。原因の推測も、直し方も、フォームには入っていません。それは貼られた AI が、コードを読んで決めます。
CC BY 4.0 はここまで
書かなくなったもの
再現手順、環境、エラーの文言です。報告そのものが減ったわけではありません——不具合は前と同じだけ見つかります。減ったのは、画面が知っていることを私が書き写す工程です。残ったのは「何が変だと思ったか」の一文で、これは今も私が書いています。
CC BY 4.0
注意: フォームが無いところでは、書くのは今も人です
一つ、フォームが無いなら、詳細を書くのは今も私です。 フォームがあるのは不具合と要望の経路だけで、新機能の設計にはありません。そしてそのフォームを作るのは安くありません。列を決め、送信を繋ぎ、一覧を作り、状態を持たせる。それをやらずに、書くのだけやめるのは、この回の話ではありません。
二つ、フォームが集めるのは、その画面で起きたことだけです。 別の画面から始まる手順、時間が経ってから出る症状は、フォームには載りません。そういう不具合は、症状の一文にそのことを書きます。それでも、URL とログとスクリーンショットは付いてきます。
三つ、コンソールログには、何でも入ります。 手元では 1 件 2,000 字、送信 20 件までに切っていて、クライアントとサーバーの両方で同じ上限を持たせています(呼び手を信用しない)。集める側を厚くするほど、出す側の線引きが要ります。
検証手順: 同じ不具合を、二通りで渡す
前提
- フォームは無くてもできます
- 手元で再現できる不具合が 1 つあること
- セッションを 2 つ立てられること
所要時間: 15 分
手順
- 1 つ目のセッションに、あなたが、症状の一文だけを渡します——「タイピングでたまに変になる」。⚠️ URL も、エラーの文言も、画面の大きさも書かないでください
- あなたが、聞き返された項目をそのまま書き出します。直しはまだ頼みません。この一覧が、この検証の成果物です
- 2 つ目のセッションに、あなたが、同じ不具合を材料付きで渡します——ページの URL、コンソールのログ、スクリーンショットの 3 つです。症状の一文は 1 つ目と同じ文にします
合格条件
- 2 つ目のセッションの AI が、聞き返さずに原因の調査へ入る
合格しなかったとき
- 2 つ目でも聞き返された —— その項目は、3 つの材料に入っていません。手順 2 の一覧に足してください。それが、あなたのフォームが集めるべき列です
後始末
- 要りません。どちらのセッションにも、まだ直させていません
⚠️ 手順 2 で出てくるのは、たいてい URL・再現手順・環境です。それが、フォームが代わりに集めているものです。 フォームを作る前に、この 2 回の比較で列を決められます。
CC BY 4.0 はここまで
次回は「計画を書けと言わない技術」。私は、AI に「計画を書いて」と頼んだことがありません。それでも、計画書は 200 本あります。
連載「言わない技術」
- ← 前回: 第 2 回 具体的な指示を出さない技術
- → 次回: 第 4 回 計画を書けと言わない技術
- 全回の一覧: 序論