AIが作ったパワポ、文字が枠からはみ出す。モデルを上げても直らなかった理由と、いまの回避策

AIにパワポを作らせたら、数字が枠からはみ出した。テキストが図形の裏に隠れて読めない。1行で収まるはずの「01」が2行に折り返されている。直させると、直った代わりに別のところが崩れる。

検索でここに来た方は、たぶんこの状態だと思います。私たちも同じでした。先に、いちばん恥ずかしいことを書いておきます。

私はその場で「モデルを上げれば直りますよ」と言って、2週間後に外しました。

この記事に書いてあること

• AIが作ったスライドで、文字がはみ出す・裏に隠れるのはどの部分か

• Sonnetから上位モデルに上げて、何が変わって何が変わらなかったか

• そのままコピーして使える、崩れを減らす指示文と生成後の点検手順

横浜の中小企業でAI活用を推進している立場から、社内の会議記録をたどって書きます。今回は、AIに作らせたPowerPointのレイアウト崩れとどう付き合うかをお届けしたいと思います。

※この連載の全体像はこちらにまとめています → 中小企業のAI推進、この1年で何が起きたか。連載全27本の目次

※AIでパワポを作っている方法

結論：崩れるのは、スライドマスターに「書いていない」ところだけでした

先に結論から書きます。

AIが作ったスライドは、全体が均等に崩れるわけではありません。崩れる場所には偏りがあります。

• 崩れない … スライドマスターに書式が定義されている場所（タイトル、本文、見出し）

• 崩れる … マスターに定義がなく、AIがその場で作った装飾（「01」「02」の番号、自作の枠、3分割のボックス）

AIは、ルールが書いてある場所ではルールどおりに流し込み、ルールがない場所では自分で座標を決めている。崩れるのは後者だけです。

これが分かってから、社内での言い方が変わりました。「AIはパワポが苦手」ではなく、「AIが自分で位置を決めた部分だけ確認する」。見る場所が減ったので、確認が現実的な作業になりました。

最初の報告は「01という数字が、枠からはみ出す」でした

2026年7月3日、部門横断のワーキンググループの定例。9人が参加する60分の会議です。

カスタマーサクセスのメンバーが、画面を共有しながら報告してくれました。アルバイト向け研修カリキュラムのExcelを、Claudeのスキル（社内で作った）に渡してスライドを生成させた、という内容です。

録画には、こう残っています。

画面には、装飾用の連番が枠から飛び出したスライドが映っていました。本人が「2行目に来てたりする」と言っていたとおり、「01」の2文字が2行に折り返されている箇所も。崩れは3種類です。

• 装飾用の番号が、枠の外にはみ出す

• テキストが、別のオブジェクトの背面に隠れる

• 1行に収まるはずの短い文字列が、2行に折り返される

どれも内容は合っています。おかしいのは見え方だけです。

「1箇所直したら、次の箇所はまた間違ってる」

そして、この日いちばん場の空気が動いたのが、次の一言でした。

会議中に、何人か笑いました。たぶん全員やったことがあるからです。

モグラ叩きです。

厄介なのは、直っているように見えることです。指示した箇所はちゃんと直るので進んでいる気になる。でも別のスライドを開くと、そこが新しく崩れている。

彼の結論はこうでした。

作らせたAIに直させるより、PowerPointの中で動くAIに直させたほうが早い。この話は、後でもう一度出てきます。

その場で私は「モデルを上げれば直ります」と言いました

ここで私が口を挟みました。

彼が使っていたのはSonnetでした。デザイン系はOpus 4.8を使うのが定石です。文字起こしが乱れているので原文そのままではありませんが、私の発言はこう残っています。

ずれは残るかもしれないが、文字が飛び出すのはだいぶ減る。なかなかの言い切りです。根拠は、自分がOpusで作ったときの体感だけでした。

2週間後、その予告は半分外れました（7月17日）

7月17日、同じメンバーが続報を持ってきてくれました。前回Sonnetで作ったスライドを、Opus 4.8に切り替えて作り直した、その差分の共有です。

まず、彼の総評です。

出だしからこれです。私は画面の向こうで、少し姿勢を正したと思います。ただ、変わったところもありました。

彼は作業フォルダに溜まった中間ファイルの数を見せてくれましたが、本人も「ちょっと参考にならないですが」と留保していて、回数の数字は出ていません。あくまで体感です。

そして、肝心のところ。

これが上位モデルでも発生した、と本人が明言しました。

私の予告は、往復回数の部分だけ当たって、はみ出しの部分は外れました。

ひとつ補足を。彼は、修正させたときの正確さはOpusのほうが上だったとも言っています。モグラ叩きの回数は変わらないけれど、1回あたりの打率は上がる、という感じです。

なぜモデルを上げても直らないのか。AIはスライドを「見て」いません

外したあとで理由を考えました。難しい話ではありません。

AIはスライドをレンダリングして、目で見ながら位置を調整しているわけではありません。「この図形は横何センチ、この位置に、フォントサイズいくつ」という数値を書いているだけです。それが枠に収まるかは、PowerPointが描画するまで確定しません。書いている側は知らないのです。

※記事執筆時ではすでに「PPTXを生成 → 実際に画像としてレンダリング → AIが画像を見る → はみ出しやズレを検出 → 座標やサイズを修正 → 再レンダリング」と新しいモデルではこの挙動が見えており、精度はかなり上がっています。

ここで、6月19日の会議で私自身が説明していたことが効いてきます。別のメンバーがClaude for PowerPointで企画書からスライドを生成しているのを、全員で見ていた回です。私はこう言っていました。

マスターに書式のルールがあれば、AIはそこに沿って流し込みます。ここは崩れません。問題は「当てはまらない」ほう。3つ並んだ枠、装飾の番号、自作のラベル。ルールがないので、AIが座標を決めます。

7月3日に崩れていたのが装飾番号だったのは、偶然ではありませんでした。

マスターに書いていない要素が、ちょうどそこだったからです。

ちなみに、pptxをChatGPTやGeminiにアップして直させ、ダウンロードすると、今度はスライドマスターごと消えます（4月24日に報告された別の事故です）。この記事の崩れは、マスターが生きている状態の話です。

もうひとつ厄介なのは、崩れ方が環境で変わることです

7月3日の会議には、続きがありました。

情シス側のメンバーの指摘です。ブラウザ上のプレビューと、WindowsのPowerPointで開いたときでは、描画の仕組みもフォントの実体も違う。

私もその場で、ただのビューワーの違いだと言いました。彼はそこに、それだけではないかもしれないと留保を付けています。決着はついていません。ただ、運用としての結論は決まりました。

確認は、最終的に配る形式で開いてやる。プレビューで判断しない。

直すのは、作ったAIじゃなくていい

7月17日、報告を聞いたあとで私が提案した手順です。生成が終わったファイルをPowerPointで開く。そこにClaude for PowerPointを立ち上げて、「はみ出しとレイアウト崩れを確認して修正しろ」と指示する。放っておいても比較的直してくれます。

なぜ分けたほうがいいのか。

生成したAIは「自分がどう書いたか」は知っていますが、「それがどう見えているか」は知りません。

PowerPointの中で動いているAIは、実際のレイアウト情報を見に行けます。見えている側に直させたほうが早いのは当然でした。7月3日の「Copilotで直してもらった方が早い」も同じことだと思います。

これ、1年前にパワポ作成で「構成」と「デザイン」を分離した話を書いたときと同じ形です。工程を分けるとうまくいく。AIが賢くなっても、この発想は生き残っています。

結局いちばん効いたのは「ゼロから作らせない」でした

7月31日の分科会で、同じメンバーはさらに先に進んでいました。今度はオンラインセミナーの資料。以前は全部手で作っていたものを、こう変えたそうです。

「高校生」は誤変換で、「構成」のことです。前回のスライドを開いた状態で、背景・色使い・構成を残し、新しい中身の骨子だけをExcelで渡して置き換えさせる。

白紙から作らせると、AIは装飾もレイアウトも全部自分で決めます。決めた分だけ崩れる。既存のスライドを開いた状態で中身だけ差し替えさせれば、座標を決める余地がそもそもありません。

崩れを直す方法を探していたのに、答えは「崩れる余地を作らない」でした。

彼は最後に、全部手作業でやったときを知っているので、どえらい差が生まれた、と言っていました。

そのまま使える：先に渡す制約と、あとで点検させる指示文

ここからは持ち帰り用です。まず、生成を頼むときに先に渡す制約。発想の元は、4月24日に情シス側のメンバーが共有してくれた、ノート欄のナレーション原稿を一括生成させた話でした。

1行7文字まで、全体200文字以内。この2つを渡しておくだけで、ほぼそのまま使えたそうです。

AIは「収まるかどうか」を見ていないのだから、収まる条件を数値で先に渡す。一番安上がりな対策でした。

スライドを作るときは、次のレイアウト制約を必ず守ってください。
守れない内容は、文字を小さくせず、内容のほうを削ってください。

【文字数の上限】
- スライドタイトル: 全角25文字以内（1行に収める）
- 箇条書き1項目: 全角40文字以内（2行まで）
- 装飾用の番号・ラベル（01、STEP1 など）: 半角4文字以内。絶対に折り返さない
- ノート欄のナレーション: 1行30文字以内・1スライド合計400文字以内

【図形の置き方】
- スライドマスターに定義されているプレースホルダーを最優先で使う
- マスターにない枠を新規に作るのは、1スライドあたり3つ以下に抑える
- 新規に作った図形どうしを重ねない。重なる場合は縦に並べ直す
- 図形の内側の余白は上下左右とも0.2cm以上を確保する

【禁止】
- テキストを収めるためにフォントサイズを10pt未満にすること
- 図形の枠外にテキストがはみ出した状態で完成とすること

次に、生成後にPowerPoint側のAIへ貼る点検指示文。1回で全部直させようとせず、観点を並べて順に見させるのがコツです。

このプレゼンテーションの全スライドを、レイアウト崩れの観点だけで点検して修正してください。
内容・文言・配色・スライドマスターは一切変更しないでください。

点検する観点は次の5つです。1つずつ、全スライドを通して見てください。

1. テキストがプレースホルダーや図形の枠からはみ出していないか
2. テキストが他のオブジェクトの背面に隠れていないか（重なり）
3. 1行で収まる想定の短い文字列（番号・ラベル・見出し）が2行に折り返されていないか
4. 同じ役割の要素（各スライドの見出しなど）の位置とサイズが揃っているか
5. 画面外にはみ出しているオブジェクトがないか

修正は「文字サイズを下げる」より「枠を広げる」「改行位置を整える」を優先してください。
修正したスライド番号と、何を直したかを一覧で報告してください。

最後の「一覧で報告してください」を入れてから、モグラ叩きの回数が目に見えて減りました。直っていない箇所が自分で分かるからです。

人が最後に見るのは、この4つだけです。

• 配る形式で開いたか（生成時のプレビューで判断しない）

• AIが自分で作った装飾（番号・ラベル・自作の枠）を重点的に見る

• 背面に沈んだテキストがないか（ホーム → 選択 → オブジェクトの選択と表示 で一覧を出す）

• フォントが自社指定のものか（ホーム → 置換 → フォントの置換 で一括確認）

1枚ずつ全部は見ません。

ここで一つ、反対側の見方も置いておきます

ここまで「崩れる」「直らない」と書いてきましたが、公平のために。

それでも、手で作るより圧倒的に速いです。

7月3日の報告も、締めくくりは愚痴ではありません。Gemini、Claude、Copilotを組み合わせてスライドのたたきがさくっとできたので良かった、という話で終わっています。崩れは、ゼロから作る手間と引き換えのコストです。

ただ、そのコストは時間だけではありません。9月4日にAIツールの利用状況を確認したとき、私はこう言っています。

上位モデルは、はみ出しを直してくれない代わりにトークンをよく食べます。「モデルを上げれば解決する」が危ういのは、精度の話としてだけでなく、お金の話としてもそうでした。

7月の別の会議で、私はAIで作ったものはクオリティ的には7割だと思わないといけない、と言っています。「とりあえず7割」の話は1年前にも書きましたが、生成AIでも同じでした。3割は人が触る前提で工程を組んだほうが速いです。

まとめ：はみ出すのは、AIが「自分で決めた」ところです

3行にまとめます。

崩れるのは、スライドマスターに定義がなく、AIがその場で座標を決めた要素だけ。

モデルを上げると往復回数は減るが、はみ出しと重なりは減らない。AIはスライドを見ていないから。

収まる条件を数値で先に渡し、直すのはPowerPoint側のAIに任せ、そもそもゼロから作らせない。

私たちも、ここにたどり着くまでに4ヶ月かかりました。しかも「崩れなくなった」ではありません。「崩れる場所が分かったので、そこだけ見ることにした」というところまでです。

さて、あなたの手元のスライドはどうでしょうか。次にAIに作らせたら、まず「AIが自分で作った枠」を探してみてください。たぶん、そこに全部います。

あとがき

この記事を書きながら、7月3日の録画を見直しました。

自分の「モデルを上げれば減ると思います」という発言は、あらためて聞くとかなり軽いです。根拠は体感だけ。しかも推進する立場の人間が会議で言い切ると、それはもう社内では答えになってしまいます。

間違っていたことより、根拠なく言い切ったことのほうが問題でした。

救われたのは、2週間後に彼が、劇的には変わらなかった、と正直に持ち帰ってきてくれたことです。あそこで気を使って「良くなりました」と言われていたら、「デザイン系はOpusにすれば崩れない」という嘘のノウハウが社内に残っていました。

言い切るなら検証してから。検証していないなら「たぶん」を付ける。次からはそうします。

あわせて読みたい

同じように社内でAI活用を推進している方の話が、一番参考になります。 「うちはこうだった」があれば、ぜひコメントで教えてください。

この連載では、横浜の中小企業でAI活用を進めるなかで、 うまくいったことも、うまくいかなかったことも、そのまま書いています。 よかったらフォローして、次回も読んでいただけると嬉しいです。