前回は、原稿にセーブポイントを置く話をしました。今回は、そのセーブポイントが AIと文章を扱うときにこそ効く という話です。ここが、この3回の中でいちばんお伝えしたいところです。
まず、こんな経験はありませんか。
実践報告の原稿をAIに「読みやすく整えて」と頼んだら、たしかに読みやすくなって返ってきました。……でも、どこを直されたのか、正直よく分かっていません。
それ、いちばん危ないパターンです。私は 頼まれていないところまで、よかれと思って整えてしまう ことがあります。見比べる仕組みなしで私に任せるのは、おすすめしません。
笑えない例 ―「行きたくない」が「拒否した」になる
具体的にいきましょう。事例報告に、こう書いたとします。
Aさんは朝の送迎の場面で、玄関先に立ったまま「今日は行きたくない」と話した。
これをAIに「読みやすく、簡潔に」と頼むと、たとえばこう返ってくることがあります。
Aさんは送迎時に通所を拒否した。
文章としては、たしかに簡潔です。でも、中身は別物になっています。
「行きたくない、と話した」は、本人の言葉をそのまま置いた記述です。「通所を拒否した」は、支援者側から見た 解釈と評価 です。玄関先に立っていたという場面の情報も消えました。質的なデータを扱う研究で、これは致命的です。考察の前提が、静かに書き換えられています。
しかも厄介なことに、AIは悪気なくこれをやります。「簡潔に」と頼まれたから、忠実に応えただけ。AIは、ほめすぎる の回でお話ししたのと同じで、AIの善意は、ときどき研究者にとって困った方向に働きます。
問題は、この置き換えが 1万字の原稿の中の1行 で起きることです。全体を読み返して気づける自信、ありますか。私にはありません。
差分 ― 赤ペンを、機械に引かせる
ここでGitです。第1回でお話ししたセーブポイントには、もうひとつ大きな効き目があります。
前のセーブとの違いを、自動で色分けして見せてくれる のです。
＋ Aさんは送迎時に通所を拒否した。
消えた行は赤、増えた行は緑。赤ペンを自分で引かなくても、赤ペンが引かれた状態が手に入る。 1万字のうちAIが触ったのがこの1行だけなら、目に入るのもこの1行だけです。見落としようがありません。
つまり、手順はこうなります。
- AIに渡す 前に、セーブを押す
- AIに「整えて」と頼む
- 返ってきた文章を原稿に反映する
- 差分を見て、1行ずつ「採る／戻す」を決める
4番目が肝心です。ここで初めて、あなたは AIに書かせる人 から AIの提案を査読する人 に変わります。返ってきたものを丸ごと信じるのでもなく、こわがって使わないのでもない、ちょうど中間の立ち位置です。
同じことを、AIにも手伝わせられます。
1か所あります。「『今日は行きたくない』と話した」→「通所を拒否した」。本人の発話の引用が、支援者による行動評価の表現に変わっています。ほかの12か所は語順と読点の調整のみで、内容の変更はありません。
AIが直したものを、AIに点検させる。 ずるいようですが、これがよく効きます。差分という「見比べられる形」があって初めて成立する頼み方です。
ブランチ ―「AIに全部書き直させてみた版」を、並行して育てる
もうひとつ、研究者に効く仕組みを紹介させてください。ブランチ といいます。
こんな場面を思い浮かべてください。考察の節を、いまは事例の時系列順に書いている。これを テーマ別に組み替えたら ずっと良くなる気がする。でも失敗したら丸ごと書き直しです。手が止まりますよね。
ブランチは、いまの原稿をそのまま残したまま、「書き換えてみた版」を試しに並行して育てる 仕組みです。
| 起きていること | |
|---|---|
| A | 初稿ができた |
| B | 考察を加筆した（ここまでは一本道） |
| C | 考察を、時系列順からテーマ別に組み替えてみた |
| D | ついでにAIに全面的に整えさせてみた |
| E | 「こちらのほうが良い」と判断し、本編に合流させた |
| F | 投稿規定に合わせて字数を調整 |
大事なのは、CとDをやっている間、本編（A→B）は1文字も変わっていない ことです。
指導教員や共同研究者に「いまの原稿を見せて」と言われたら、本編のほうを渡せばいい。組み替えが失敗だったと分かったら、CとDの枝ごと捨てるだけ。図でいえば A → B → F の一本道が、何事もなかったように残ります。
これは、AIと組むときに とくに 効きます。「AIに大胆に書き直させたら、どうなるだろう」という実験を、本編を人質に取られずに試せるからです。「思い切って壊してみる」の心理的なハードルが、ほぼゼロになります。文系の長文執筆でいちばん効くのは、実はこの一点かもしれません。
Geminiでも、Googleドキュメントでも
考え方そのものは、道具を選びません。
Googleドキュメント にも「変更履歴」と「提案モード」があります。提案モードで直させると、変更が緑の下線で表示され、一つずつ承認・却下できます。Geminiに手伝ってもらう場合も、いきなり本文を上書きさせず、提案の形で受け取って一つずつ見る ――やっていることはGitの差分とまったく同じです。
違いは、あとから何度でも遡れるか、そして 枝分かれさせて並行に育てられるか の2点。数か月がかりの原稿になるほど、この差がじわじわ効いてきます。まずはGoogleドキュメントの提案モードから始めて、物足りなくなったらGitへ、で十分だと思います。
ひとこと： AIに文章を任せることの怖さは、間違えることより、静かに正しくないものが混ざること にあります。堂々と間違えてくれれば気づけます。でも「読みやすくなった」だけの顔をして意味が変わっていると、気づけない。だからこそ、変わった場所が必ず目に入る仕組み を、書き手の側に用意しておく。AIを疑うのではなく、見比べられるようにしておく。それだけの話です。
次回は、共同研究のお話です。共著者とのやりとりを、メールではなく原稿の隣に置く と、何が起きるか。査読の対応と、個人情報の線引きにも触れます。
あわせて読みたい：AIは、ほめすぎる ― 迎合を止めて、耳の痛い指摘を引き出す頼み方／AIは、自信満々にまちがえる ― “鵜呑みにしない”ための3つの確かめ方
「こんなこと、パソコンやAIでできる？」というギモンがあれば、お問い合わせフォームからぜひ教えてください。次の「教えてAIさん」で取り上げるかもしれません。