一枚ずつ直す作業から、資料をまとめて直す作業へ
今回の発表では、サイドパネルからの指示で、資料全体の見た目をそろえたり、内容を更新したり、複数のスライドをまとめたりできると説明されています。変更は編集可能なスライドに直接反映され、処理後には変更の要約が表示されます。Googleは、元に戻す操作や変更履歴を使った見直しも案内しています。
ここで考えたいのは、「見た目を統一したい」という依頼と、「説明の内容を組み替えたい」という依頼の違いです。例えば、社内説明資料の見出しをそろえるだけの作業と、三枚の説明を一枚へ短縮する作業では、確認する場所が異なります。前者では文字の読みやすさや配置が中心になりますが、後者では条件や例外が抜けていないかも読む必要があります。まとめて編集できることを、まとめて確認を省けることと取り違えない使い方が求められます。
編集後の確認方法に関する本稿の提案です。機能の優劣や検証結果を示す図ではありません。
変更の要約は、内容が正しいという証明ではない
変更の要約は、どこを見直すべきかをつかむ手掛かりになります。ただし、要約に「内容を整理した」とあっても、引用した数値や説明の意味が保たれたとは限りません。編集後の資料を受け取る際は、見た目が整っているかと、説明の根拠が残っているかを別に確認する、というのが本稿の提案です。
架空の社内説明会資料を例にすると、公開された製品仕様を説明するページでは、対応条件が省かれていないかを元資料と照合します。短縮を頼んだ箇所では、限定的な説明が無条件の断定へ変わっていないかを読みます。これは利用手順を考えるための編集例であり、実際の業務で試した成果や、誤りを防げたという実測報告ではありません。
共同作業中の資料では、完成形だけでなく、今回どの部分を変えるつもりだったかを共有しておくことも考えられます。依頼範囲が曖昧なままだと、同僚が意図して残した表現まで変更候補に含めてしまうかもしれません。AIに変更を依頼する前に目的を短く説明できる状態にすることは、人に編集を頼む場合にも共通する準備です。
