AI成果物チェックの落とし穴：エラーを減らすために品質の上限まで下げてはいけない
明らかなエラーは防ぎつつ、もっと良い結果が生まれる可能性まで塞いではいけない。
目次
検収は成果物の可能性を狭める作業ではなく、実際に誤りがある部分を見つけて直す作業だ。
文字がスライドの外にはみ出していた。送る直前になって、やっと目に入った。エクセルには #REF! エラーが残っていて、表の罫線はあるマスにはあって、別のマスにはなかった。Word文書には、消えているはずのマークダウン記号がそのまま残っていた。こういうのは好みの問題ではない。ただ成果物が壊れているだけだ。AIが作ったオフィスファイルには、こういうミスがよく出る。だからチェックツールは必要だ。問題は、チェックツールがどこまで口を出すべきか、ということだ。
チェックは下限を上げる作業だ
チェックツールがやるべきことは、成果物の下限を上げることだ。スライドの外にはみ出したテキスト、壊れた数式、未処理のプレースホルダー、文書に残ったマークダウンのように、誰に見せても問題になるものを拾うのだ。こういうエラーは、早く拾えば拾うほどいい。人が最後に目で探すには細かすぎるし、そのまま出てしまえば致命的すぎる。AIがファイルを作ったなら、AIが見落とした明らかな欠陥を自動で検査し直す仕組みは必要だ。ただ、ここで線を越えやすい。エラーを拾おうとして作ったツールが、いつのまにかスタイルを強制し始めるのだ。
スタイルをエラー扱いすると上限が下がる
一部のチェックツールは、フォントの数、箇条書きの数、文字数、余白、色、情報の密度まで、たった一つの正解のように扱う。「スライドにはフォントを二つしか使ってはいけない」「箇条書きは六つを超えてはいけない」といった具合だ。もちろん、そうしたルールが役に立つこともある。でも、いつでも正しいわけではない。技術文書、投資レポート、講義資料、一枚もののプレゼンスライドが、すべて同じ密度・同じ見た目でなければならない理由はない。こうしたルールを絶対の基準にすると、おかしなことが起きる。モデルがもっと良い結果を作ったのに、過去のお手本と違うという理由で減点されるのだ。すると、チェックツールは成果物の下限を上げる仕組みではなく、成果物の上限を下げる仕組みになってしまう。
エラーと選択を分ける問い
検査項目を入れる前に、まず問うべきことがある。第一に、ユーザーの意図や好みが違っても、ほぼいつでも欠陥といえるか。壊れた数式の #REF!、スライドの外に押し出された図形、未処理のプレースホルダーは、たいていそのまま納品する理由がない。第二に、もっと有能なモデルでも、この問題は避けようとするか。より良い結果のためにわざと破ることもあるルールなら、エラーと決めつけない。情報の密度、色の組み合わせ、フォントの数、余白、文の長さといった項目がここに当てはまる。
要点はシンプルだ。もっと優れたモデルでも避けたいと思う失敗なら、拾うべきだ。でも、もっと優れたモデルが意図して選ぶこともある表現なら、チェックツールが止めてはいけない。
良い検収ツールは、モデルの創造的な試みまで消さず、実際に欠陥がある出力だけを見つける必要がある。
すべての問題を白黒で分けられるわけではない
実際のファイルチェックでは、すべての判断がきれいに分かれるわけではない。テキストボックスの重なり、文字のはみ出し、小さすぎる文字、画像の比率の変化は、欠陥である可能性が高いが、意図した演出かもしれない。だからチェック結果は分けるべきだ。確実な構造上の欠陥は ERRORと表示する。もう一度目で確かめるべき項目は WARNにしておく。WARNは欠陥だと断定するものではない。確認のお願いだ。この区別がないと、ツールは弱すぎるか、逆に乱暴すぎるものになる。
自動検査は最後の判断の代わりにはならない
AIがオフィスファイルを作るときに生まれる欠陥の多くは、結果を見直せないことから生まれる。モデルは座標やセルの値を書き込むが、最終的なレンダリング画面を十分に確認できないことがある。ついさっきユーザーが直した最新のファイルの状態を、きちんと反映できないこともある。だから自動検査は必要だ。作った直後にファイルを読み直し、測れる欠陥を拾うのだ。数式エラー、キャンバスからのはみ出し、残ったマークダウンといったものは、人が最後に探す前に機械が先にふるい落とすべきだ。ただ、自動検査が最後の判断まで代わってはくれない。文脈、意図、読み手、発表の場は、ファイル一つを見ただけでは完全にはわからない。良いチェックツールは、自分が確実にわかる範囲をはっきりさせるべきだ。
Office File Inspectorを作った理由
この原則で Office File Inspectorをまとめた。AIが作ったPowerPoint、Excel、Wordのファイルから、明らかな欠陥を見つけるオープンソースのツールだ。目標は、成果物を一つの形にそろえることではない。明らかな失敗は早く防ぎ、より良い選択をする余地はモデルと人に残しておくことだ。チェックツールは、モデルの可能性を狭める道具になってはいけない。良いチェックは下限を上げる。上限は下げない。