AIに記事の下書きを書かせると、一見それらしい文章がすぐにできます。ただ、そのまま公開すると、間違いや、出典のない話が混ざっていることがあります。この記事では、このブログのAI編集部で、チェック役が実際に指摘した点をもとに、公開前に見るべきポイントをチェックリストにまとめます。
1. 事実・数字・年号
- □ バージョン番号や料金は、公式サイトで最新のものか確かめたか
- □ 年号や期間は、出典と一致しているか（例：「晩年まで」のようなあいまいな言い方を、確認できた年に直す）
- □ 「〜サイズ」「〜枚」などの数字に、根拠があるか
- □ 料金には「通常料金」「別途手数料がかかる場合あり」など、条件を書いたか
実際の例：ルーマンのツェッテルカステンについて「晩年まで続けた」と書いていた部分を、資料で確認できた「1997年初めまで」に直しました。料金も「月額〇ドル」だけでなく、「通常料金。別途手数料がかかる場合あり」と条件を足しました。
2. 引用と出典
- □ 「〇〇はこう語った」という引用に、出典があるか。なければ「〜と語ったとされる」にするか、削る
- □ よく知られた方法が、誰の考えなのかを取り違えていないか（本人の分類か、後の人が広めた方法か）
- □ 出典のリンクは、すべて開けるか
実際の例：「思考の多くはカードの中で起きている」というルーマンの言葉に出典が見つからず、「〜と語ったとされる」に改めました。また、ノートを3種類に分ける方法は、ルーマン本人ではなく、Sönke Ahrens『How to Take Smart Notes』（2017年）で広まった方法だと明記しました。
3. 技術的な正しさ
- □ コマンドの書き方は、公式ドキュメントと合っているか
- □ 「〜が必要です」という前提条件が正確か（ツールによって必要な環境が違うことがある）
- □ OSによって手順が変わるところに、注意書きがあるか
実際の例：Kubernetesの記事で「どちらもDockerが必要」と書いていましたが、minikubeは仮想マシンでも動くため、ツールごとに書き分けました。MacやWindowsでは、ターミナルを開いたままにする注意書きも足しています。
4. 言い切りすぎていないか
- □ 「全自動」「絶対」「必ず」など、大げさな言い方をしていないか
- □ まだ確かめられていない効果を、言い切っていないか（例：使い始めたばかりなのに「〜が減った」と書く）
実際の例：AIを使い始めた初日の記事に「記事の間違いが減った」と書いていましたが、まだ言い切れないため「チェックで細かい誤りを拾えるようになった」に変えました。
5. 公開して大丈夫な情報か
- □ サーバー会社の名前、セキュリティ設定の中身、IPアドレス、ユーザー名やパスワードの変数名が入っていないか
- □ 画像や図に、出してはいけない実名や画面の情報が写っていないか
実際の例：サーバーのトラブルを紹介した段落に、サーバー会社の名前や、ゆるめたセキュリティ設定の中身が書かれていました。外から守りの弱いところがわからないように、「サーバー側の設定を必要なところだけ調整した」とぼかしました。
6. サイトの中での役割
- □ 同じテーマの既存記事と、内容がかぶっていないか（かぶるなら、役割を分けて内部リンクでつなぐ）
- □ 関連する記事への内部リンクと、抜粋（説明文）を入れたか
実際の例：Clineの記事が2本あって内容がかぶりそうだったため、片方を入門編、もう片方を応用編に分け、互いにリンクでつなぎました。
チェックを回すコツ
このブログでは、書く役とチェックする役を別のAIに分けています。同じAIに「見直して」と頼むよりも、別の役が読むほうが、見落としに気づきやすいと感じています。そのうえで、公開するかどうかは必ず人が決めています。
体制の詳しい話は、Grok BotでAI編集部を作ってみたで紹介しています。
まとめ
- AIの下書きは、事実・引用・技術・言い切り・公開してよい情報か・サイト内での役割、の6つの観点で見る
- 出典のない引用や、確かめていない効果は、削るかぼかす
- 書く役とチェックする役を分け、最後は人が判断する
コメント