生成AIの答えは、もっともらしく書かれています。間違っているときも同じ調子で書かれるので、読んだだけでは見分けがつきません。人間なら「たぶん」が付くところに、何も付かないからです。一人でアプリとサイトを作りながら、採用する前に必ず通すようにした確認項目をまとめます。事実・情報の新しさ・安全・規約・実際の動作の5つと、聞き方を変えて前提を引き出す方法、そして確かめられなかったものをどう書き残すかまで並べます。
なぜ見分けられないのか。聞き方を変えると拾える
間違いが自信なさげに書かれることはありません。正しい答えと同じ文体で、同じ長さで返ってきます。人間なら「たぶん」「うろ覚えですが」が付くところに、何も付きません。
しかも、こちらが求めている結論に寄った答えが返りやすい。「これで合っていますか」と聞くと、合っていることになりがちです。
だから、読んで納得できたかどうかを判断の基準にしないと決めました。納得は、正しさとは別のことです。自分が知らない分野ほど、書かれたものは正しく見えます。確かめる必要があるのは、まさにその分野なので、感覚に任せると順番が逆になります。
確認の前段として、聞き方も変えました。「これで合っていますか」は、合っている理由が返ってきます。「この方法が通用しない条件は何か」と聞くと、前提が返ってきます。後者のほうが、採用するかどうかの判断に使えました。
もう一つ効いたのは、根拠を先に出させることです。結論から書かれると、読み手は結論に引きずられます。どの資料のどこを見たのかを先に並べさせると、資料が薄いことがその場で分かります。
弱い聞き方
この書き方で大丈夫ですか？
強い聞き方
この書き方が通用しない条件を挙げて、それぞれ公式の資料のどこに書いてあるかを示してください。該当が見つからないものは、見つからなかったと書いてください。
事実と新しさ。数字・日付・URLと確認日を残す
数字、日付、固有名詞、URL。この4つは必ず自分で確かめます。もっともらしい形をしているものほど危ないからです。
確かめ方は単純で、出どころを言わせます。「どこに書いてあるか」を聞いて、そのページを自分で開く。開けないURLが返ってきたら、その時点で他の部分も疑います。
実際にありました。あるツールの公式ドキュメントを確かめに行ったら、こちらが持っていたURLは転送されていて、別の場所へ移っていました。内容は合っていても、置き場所が変わっていることはよくあります。
数字はとくに注意しています。件数や割合は、書かれた時点では正しくても、すぐ古びます。私は記事に数を書くときだけ、その場で数え直してから書くようにしました。引用ではなく、実測にします。
ここで一つ、自分のための注意もあります。都合のよい数字ほど、確かめずに通してしまう。思っていたとおりの結果が返ってきたときこそ、出どころを開きます。
情報の古さは、動くかどうかで判断できない種類の間違いです。「以前は正しかった」答えは、書きぶりが自然なぶん見抜きにくい。特に危ないのは、インストール手順、設定ファイルの書式、外部サービスの画面の名前、対応バージョンです。どれも数か月で変わります。
対策として、確認した日を本文に書くようにしました。読む人にとっても、自分が読み返すときにも役に立ちます。古びたときに、どこから疑えばよいかが分かるからです。外部のサービスについて書くときの扱いはアプリのプライバシーポリシーはどこを見る？探す五つの項目でも同じ考え方をとっています。
安全にかかわるもの。部品の既定値まで見る
鍵や認証情報の扱い、権限の設定、外へ送るデータ。ここは「動いた」で通してはいけない領域です。動いてしまうほうが危ないからです。
見落としやすいのは、自分が書いた行の外側でした。実際に、地図の部品が既定で位置情報を分析目的で送っていたことがあります。こちらのコードには送る処理を一行も書いていません。入れた部品の既定値も、自分の挙動に含まれます。
いまは、部品を足したときに、それ自身が何を申告しているかを読むところから始めます。既定で有効になっている送信が無いか、切る手段があるか、切ったあと利用者が自分で戻せるか。
このとき、テストの書き方でも一度つまずきました。「利用者が自分で決めたかどうか」を調べるつもりが、部品が登録した既定値まで一緒に拾う書き方になっていて、切るべき場面で切らない判定になっていた。⚠️ 確認のコードそのものが間違っていることもあります。
- 鍵や認証情報を、そのまま貼り付けない。
- 権限は、広く開けてから絞るのではなく、必要なぶんだけ開ける。
- 追加した部品が何を外へ送るかを、部品側の申告で読む。
規約と権利。配布物は工夫せず提供元を見る
生成された文章や画像を、そのまま外へ出す前に見る項目です。引用の範囲、他社の名前の出し方、配布物の加工の可否。
配布物には、加工してはいけないものがあります。公式のバッジがそれで、色や比率を変えることも、影を乗せることも認められていません。私は、明るい背景に白いバッジを置くと消えてしまう場面で、色を変えるのではなく、配布されている別の色のファイルに差し替える対応をとりました。
判断に迷ったら、こちらで工夫せず、提供元が何を配っているかを先に見ます。たいてい、想定された選択肢が用意されています。工夫が必要に見えるときは、だいたい探し方が足りていません。
文章のほうも同じです。要約したつもりが、元の文の構成をなぞっているだけ、ということが起きます。出すのは自分の名前なので、ここは通す前に読み直します。
提案されたライブラリやフォントも、ここに入ります。「これを使うといい」と返ってきたものが、自分の用途で使える条件かどうかは別の話です。商用で使えるか、配布物に同梱してよいか、表示義務があるか。提案の中にライセンスは書かれていないことが多いので、導入する前に自分で見にいきます。
実際に動かす。失敗すべきときに失敗するか
最後は動かします。読んで筋が通っていることと、手元で動くことは別です。
ここでも「動いた」で終わらせません。期待どおりに成功することと、失敗すべきときに失敗することの両方を見ます。片方だけだと、何も見ていない確認になります。
たとえば転送の設定を足したときは、正しい行き先に着くことだけでなく、わざと存在しない対象を指定して、ちゃんと落ちることまで確かめました。
この「両方を見る」は、テストを書かせるときにも同じです。正常系だけのテストは、通っても何も保証しません。受け取り方の話はAI開発で起きやすい「動くけれど仕様と違う」を3層で防ぐに詳しく書いています。
5つを全部、毎回やるわけではありません。読むだけの調べものに、ここまでは要りません。外へ出すもの、戻せないものに触れるときだけ通します。
- 数字・日付・固有名詞・URLは、出どころを開いて確かめたか。
- 変わりやすい情報は、公式の一次資料を見て、確認日を残したか。
- 鍵・権限・外へ送るデータに触れていないか。部品の既定値も見たか。
- 引用や配布物の扱いが、提供元の条件に合っているか。
- 成功する場合だけでなく、失敗すべき場合も動かして確かめたか。
- 確かめられなかったものを、確かめていないと書いたか。
よくある疑問と、確かめられないものの書き方
AIの答えが正しいか、読んで見分けられますか？
見分けられません。間違いも正しい答えと同じ文体で返ってきます。納得できたかどうかを基準にしないのが出発点です。知らない分野ほど正しく見えるので、感覚に任せると確かめるべきところを飛ばします。
ハルシネーションを減らす聞き方はありますか？
根拠を先に出させるのが効きました。「この方法が通用しない条件を挙げて、公式資料のどこに書いてあるか示して。見つからないものは見つからなかったと書いて」という形です。資料が薄いことがその場で分かります。
出どころを示してもらえれば、正しいと言えますか？
言えません。示されたURLを自分で開くところまでが確認です。開けないURLが返ってくることも、内容は合っているのにページが移動していることもあります。示させるのは、確かめる手間を減らすためであって、確かめを省くためではありません。
毎回この確認をするのは大変ではないですか？
全部を毎回はやりません。外へ出すもの、戻せないものに触れるときだけ通します。読むだけの調べものには要りません。通す対象を絞ると、1件あたりの確認は丁寧にできます。
AIに聞いた内容を記事に書いてもいいですか？
出どころを自分で開いて確かめたものだけにしています。数字は引用せず、その場で数え直して実測にします。そして確認した日を本文に書くようにしています。古びたときに、どこから疑えばよいかが分かるからです。
鍵やAPIキーを貼り付けてしまいました。
その鍵を無効にして、作り直すのが確実です。貼り付けた場所から消しても、履歴やログに残っている可能性があります。消す作業より、使えなくする作業のほうが確実に効きます。そのうえで、次からは環境変数など、貼り付けずに渡せる形にしておきます。
AIが書いたコードの安全性はどう確かめますか？
自分が書いた行の外側まで見ます。追加した部品が既定で何を外へ送るかは、部品側の申告を読むしかありません。実際に、地図の部品が既定で位置情報を分析目的で送っていたことがありました。こちらのコードには一行も書いていません。
5つを通しても、確かめきれないものは残ります。そのときは確かめていないと書くのが一番安全でした。
私は、ある確認項目を閉じるときに「ストアの公開APIには出ないので、管理画面でしか確かめられない」と添えて残しました。閉じた根拠が自分の確認ではないことを、あとから読んで分かるようにするためです。書かないでおくと、数か月後の自分が「確かめた」と読みます。そこから先の判断が全部ずれます。
同じ理由で、やらなかったことと、その理由も残します。測ったうえで見送ったのか、そもそも見ていないのか。この2つは結果としては同じ「やっていない」ですが、次に判断するときには全く違う情報です。
一人でやっていると、この確認を省いても誰も指摘しません。省いたぶんは、公開したあとに自分へ返ってきます。私の場合、返ってきたのは利用者からではなく、検索エンジンの管理画面と、数週間後に読み返した自分からでした。
