資料の内容はそろっているのに、見出しが本文に重なり、説明文がスライドの外にはみ出している。AIにスライドを作らせるとき、最後に人が直すのは、こんな細かいところだったりする。

IBM Researchが11月3日に報告した「Palette」は、スライドの設計と作図を分け、出来上がったページを描画してから崩れを検査する研究だ。修正後に検査結果が良くなったページだけを採用し、改善しなければ元に戻す。「もっと見やすく」とAIに頼むだけでなく、文字や図形が重なっていないかを測って、直しを確かめる。

ただし、見た目が整えば内容も正しい、とはいかない。研究チームが苦労したのも、元の資料にない情報をAIが埋めてしまう問題だった。資料作りを任せるうえで、どこまで自動で直せて、何を別に確かめる必要があるのか。その違いが見える報告だ。

「何を見せるか」を決めてから、1枚ずつ作る

Paletteでは、200億パラメーターのモデルを追加学習させ、同じ追加学習済みモデルに「デザイナー」と「コーダー」の二役を担わせた。

デザイナーが作るのは、配色、書体、各ページのレイアウト、載せる内容、デザインを選んだ理由をまとめた設計書だ。機械で扱えるJSON形式だが、人も読んで編集できる。コーダーはそこから1ページ分を受け取り、PowerPointファイルを作るライブラリー「PptxGenJS」用のJavaScriptを書く。

例えば、導入計画に「3月に試験導入、5月にセキュリティー審査、7月に全技術部門へ展開」と並んでいたとする。原本で紹介されている指示は、そこに [[make this a timeline]] と添える方法だ。単なる表ではなく、時系列で見せたいという意図を設計書に反映し、その指定に沿ってページを作る。

先に全ページの設計を固めるため、作図コードはページごとに並列で生成できる。チームは、並列化によって、このコード生成部分が約6〜7倍速くなったと報告している。他のスライド生成製品との速度比較でも、資料の読み込みから完成までの所要時間でもない。測定環境や詳しい比較条件は、発表本文だけでは分からない。

一つのAIに構成と配置を一度に任せるのではなく、まず「このページは何を伝えるのか」を固定する。途中で1枚だけ見せ方を変えたいときも、設計書を直せるのが特徴だ。

設計書JSONで内容・配色・配置を決め、各ページのコードを並行生成する。描画して重なり・切れ・はみ出しを検査し、問題ページだけ修正する。再検査で改善したら修正を採用し、改善しなければ元のページを残す工程図。

Paletteの主要工程を、IBM Researchの説明から整理した。各ページのコードを並行生成し、描画後に問題のあるページを修正。再検査で改善した修正だけを採用し、改善しなければ元のページを残す。図は独自制作の説明図で、Paletteの実画面・実出力ではない。既知の不具合を直す単純なルール処理などは省略した。 出典：IBM Research原本。

直したつもりのページを、そのまま返さない

コードを書けたことと、読めるスライドができたことは別だ。Paletteは各ページを実際に描画し、文字の重なり、切れ、枠外へのはみ出しを検査する。問題のあるページは別の編集用モデルに渡し、そのページのコードを書き直させる。

大事なのは、その修正案を無条件では採用しないことだ。もう一度検査し、結果が改善した場合だけ置き換える。悪くなったり、良くならなかったりすれば、元のページを残す。

チームは、スライド生成の評価用データ「PresentBench」の131組の資料をそれぞれ一度生成し、検査・修正を入れた場合と入れない場合を比較した。検査・修正を加えると、評価が平均で改善したと報告している。RINKAKUによる追試ではない。

この方法が防げるのは、あくまで検査で捉えられる問題だ。文字の重なりが減ったからといって、主張が正しくなったり、説明が分かりやすくなったりしたとまでは言えない。「修正して悪化しない」も、検査結果についての約束として読む必要がある。

きれいな表ほど、埋めた数字に気をつけたい

報告の中で、特に気になったのは情報の捏造への対処だ。

設計書が「6行5列の表」を求めているのに、中身として渡したのは三つの箇条書きだけ。これでは、作図するAIが空欄を埋めようとして、元にはない内容を作ってしまう。チームによると、プロンプトに禁止事項を足すだけでは防げなかった。

効果があったのは、学習用データを作るAIに見せる、お手本の資料を直すことだった。AIは注意書きより、お手本を強くまねていたという。

ここは、資料作りをAIに任せるときにも覚えておきたい。見栄えのいい表ができると、中身まで確かに見える。けれど、余白をなくすために埋めた数字や説明は、資料の質を上げるどころか、信用を損なう。レイアウトの検査とは別に、設計書へ必要な情報が渡っているか、完成した表の各項目を原資料へ戻して確かめる必要がある。

上段は架空のスライドを示し、見出しに重なる本文と、スライド枠の外へ出る説明枠を指摘している。下段は完成資料の項目から原資料へ戻る照合を示し、見栄えが整っても、根拠のない内容を埋めてはいけないと伝える比較図。

見た目の検査で捉える配置の問題と、原資料へ戻って確かめる内容の根拠は別の確認対象だ。上段は重なり・はみ出しを説明する架空の配置例。下段は原資料照合の必要性を示すRINKAKUの編集上の整理であり、Paletteの実出力や照合機能を評価した結果ではない。 出典：IBM Research原本。

Paletteは現時点では研究報告として読むのが適切だ。発表本文だけでは、モデルやコードの配布方法、動作に必要な機材、料金、日本語資料での品質は確認できない。評価時には原資料から最初の計画を作る別の高性能モデルも使われており、すべてを200億パラメーターのモデルだけで完結させた実験でもない。

それでも、「設計する」「作る」「描画して直す」を分ける考え方には、資料作りをもう一段任せるための手掛かりがある。AIがファイルを出力したところで完成にせず、人が開いたときに読めるかまで確かめる。資料を受け取る人にとっては、そのひと手間が残っているかどうかの方が、モデルの大きさより気になるはずだ。

出典：IBM Research「Palette: teaching a small model to build decks in your design language」（2026年11月3日公開）。2026年11月4日に原本を確認。RINKAKUではPaletteの実行、速度測定、日本語品質の検証は行っていません。