何に困っていたか

僕たちは提案資料やウェビナーの資料を、AIにpptxで作らせています。Claude Code と Codex がコードでpptxを組み、PowerPointで全ページを画像に書き出して目視する流れです。ブラウザー上のスライド作成機能やデザインツールは使わず、ローカルのpptxで作ります。人が後から手で直せることを優先しているからです。

困っていたのは、見た目の指摘が減らないことでした。「境界が見づらい」「下に寄って見える」「箇条書きの距離感がおかしい」「変な改行がある」。こうした指摘を、僕は毎日のように出していました。しかも同じ種類の指摘が、資料をまたいで繰り返されます。たとえば「境界が見えない」は、別々の資料で何度も出ました。

最初に打った手は、レビューを増やすことでした。2026年10月末に、書き出すたびにClaudeの2つのモデルとCodexの3者で全ページを目視レビューし、合格の記録がないと作業を終わらせない仕組みを入れました。そして3日後に廃止しました。

この記事の結論はここです。AIの成果物の見た目は、後からのレビューで守るより、指摘を数値の決まりに変えて作る段階で守らせる方が速くて確実です。レビューをなくしたのではなく、判断の置き場所を「作った後」から「作る前の決まり」に移しました。

全体像と役割分担

仕組みは4つの層に分かれます。

人の役割は、指摘することと判断することだけです。指摘を受けたAIは、同じターンのうちに3つをやります。指摘された箇所を直す。同じ種類の箇所を資料全体で探して直す。テーマを数値で書き直す。指摘を検知する仕組みが会話を見ていて、テーマが更新されていなければターンを終わらせません。

作り方の土台は、4つの設定を同じ資料で作り比べて決めました。公式のpptxスキルと公式のテーマ機能に、自社のテーマを足した組み合わせが一番良い出来でした。比べた中には、外部のコンサルティング風のデザインスキルもありましたが、見た目が僕たちの資料に合わず削除しました。図を画像として生成するスキルも削除しています。画像の図は、後から1文字直すだけでも作り直しになるからです。図はPowerPointのネイティブの図形で描きます。

指摘を数値に変える

肝は、指摘を形容詞のまま残さないことです。「見づらい」は次の資料で再現できません。「何pt以上」と書けば守れますし、検査もできます。実際に変えた例を並べます。

数値にするときに気をつけていることが2つあります。

1つ目は、測る基準を先に決めることです。僕が「この資料のこのページのように」と手本を示したら、その手本から寸法を測って数値にします。感覚で「少し広げる」と書くと、次のセッションでは別の「少し」になります。

2つ目は、古い決まりとの食い違いを放置しないことです。決まりは毎日増えるので、矛盾が必ず出ます。実際に、ある週に「掛け合わせはベン図の画像で描く」という記録と、「ベン図は使わない」という新しい決まりが同居していました。新しい方を正とし、古い方には取り消しを明記します。消さずに残すのは、なぜ変わったかを後から追えるようにするためです。

機械検査に落とす

数値になった決まりの多くは、描画する前にコードで検査できます。いま回している検査は次のとおりです。

• 図形に影が付いていないか
• 負の寸法がないか。あるとPowerPointで開けなくなる
• 枠からのはみ出しと、ページの下端を越えていないか
• 1行の字数が枠の幅に収まるか
• 区切り線と文字枠が交差していないか
• 空のプレースホルダーが残っていないか。編集画面で入力を促す文字が出てしまう
• 禁止語。比喩、「タイトル」と「内容」をコロンでつなぐ書き方、社名の誤記など

一番効いたのは改行の検査です。自動の折り返しに任せると、句の途中で行が折れて「変な改行」と言われます。そこで、句の切れ目で明示的に改行させ、1行の字数が枠に収まるかを計算で確かめるようにしました。考え方は単純です。なお、このコードは半角の文字も全角1字として数える簡易な計算です。半角が多い行では実際より厳しめに判定しますが、はみ出すよりは安全なので、いまはこれで足りています。

# 1行に収まる全角の字数の上限
def max_chars(box_width_in, margin_l_in, margin_r_in, font_pt):
    usable = box_width_in - margin_l_in - margin_r_in  # 使える幅(インチ)
    char_w = font_pt / 72                              # 全角1字の幅(インチ)
    return int(usable / char_w)

def overflow_lines(text, box_width_in, font_pt, margins=(0.1, 0.1)):
    limit = max_chars(box_width_in, margins[0], margins[1], font_pt)
    # 簡易な計算: 半角も全角1字として数える(実際より厳しめに判定する)
    return [line for line in text.split('\n') if len(line) > limit]

Codexに改行の位置を任せるときも、この上限の字数を指示書に書いて渡します。上限を知らないAIは、もっともらしい位置で改行して、枠の中でもう一度折り返されます。

線と文字の交差の検査も、入れてから同じ指摘が出なくなりました。区切りの線が説明文の上を横切っている不具合は、縮小した画像では見落とします。図形の座標同士を比べれば機械で拾えます。

ただし、検査で拾えないものも残ります。余白の違和感や、ページ全体の重心のずれです。ここは人の目の領分として割り切っています。指摘は減りますが、0にはなりません。0にならない分を、次の節の振り返りで決まりに変えていきます。

週に一度、指摘をまとめて振り返る

その場の更新だけでは、拾い漏れや、古い記録との食い違いが残ります。そこで、毎週月曜の朝に定時で振り返りが動くようにしました。端末が止まっていて動かなかった週は、僕が Claude Code を起動したときに補います。

振り返りは、先週の全セッションから、僕の発言のうちスライドの見た目への指摘だけを拾います。製品の画面への指摘や、文字起こしの依頼は対象外です。拾った指摘を1件ずつテーマと照合し、反映済みか、足りないか、古い記録と食い違っているかを表にします。

大事にしているのは、振り返りがテーマの正本を直接書き換えないことです。改訂した全文を別のファイルに出し、判断が要るものは一覧にして僕に聞きます。たとえば「段の流れを番号で示すか、右向きの矢印で示すか」。正本は番号で示すと決めているのに、矢印にしてほしいという僕の指示も何度かありました。どちらが例外なのかは、AIではなく僕が決めることです。

振り返りは、繰り返された指摘の傾向も出します。「普通の箇条書きにして」は、いくつもの資料で繰り返し出ていました。対策の一言は「論点を並べるだけのページは、最初から箇条書きの部品で作る」です。指摘を減らすには、直し方より、最初に選ぶ型を変える方が効きます。

決まりが固まったテンプレートは、振り返りに続けて、全社の共有のテンプレートとして配り直しています。最新版だけを置き、旧版は日付のフォルダーに退避します。僕の指摘が、翌週には社内の全員の資料に効く状態です。

試してやめたこと

書き出すたびの3者レビューをやめた理由は3つあります。

1つ目は遅いことです。1つの流れ図が、レビューで9回目にやっと合格したことがありました。配置がそろっていない、字が小さい、線が細い、と毎回少しずつ指摘が出ます。指摘のたびに作り直して書き出し、またレビューを待つ。この往復が資料全体で起きます。

2つ目は、レビューの基準がテーマ以上のものにならないことです。レビュー役のAIが見ているのも、結局はテーマに書かれた数値と、過去の指摘の記録です。それなら、同じ基準を作る段階で部品と検査に入れておけば、レビューで見つけるべきものの大半は最初から出てきません。

3つ目は、仕組み自体の誤作動です。指摘を見張る仕組みが、契約レビューやブログの相談の会話まで資料への指摘と誤判定して止めたことがありました。作業を止める仕組みは、誤判定したときの損が大きいです。

レビューを全部なくしたわけではありません。僕が「レビューして」と指示したときは、作った本人が決まった手順で描画、機械検査、全ページの目視を行います。変えたのは「毎回、別のAIで」をやめたことです。

もう1つ、やめたことがあります。デザインの大きな変更を、承認なしに全ページへ広げることです。以前、社内の大きな資料で、AIが全ページを一気に作り直し、全面差し戻しになりました。いまは、デザインを大きく変えるときは代表の2〜3ページを手本と並べて合意してから全ページに広げます。一方で、最新テンプレートへの載せ替えのような決まった作業は、途中で止めずに全ページを一度に終わらせます。止めるべき場面と止めてはいけない場面を、決まりの中で分けています。

次にやること

まだ足りないものがはっきりしています。

• 部品が足りない。課題と目指す姿を並べるページ、ポジショニングマップ、マスタースケジュール、人型の組織図は、いまは前の資料から写しています。キットの部品にします
• テーマの中の食い違いを、僕が判断して片付ける。番号か矢印か、構成図を画像にするかネイティブの図形にするか
• 振り返りで拾った傾向を、部品の既定値に反映する

AIに作らせる量が増えるほど、品質を守る場所をどこに置くかが効いてきます。僕は「作った後に見る」より「作る前に決めておく」側に寄せると決めました。皆さんのチームでは、AIの成果物の品質をレビューで守っていますか、それとも決まりで守っていますか。違うやり方があれば聞いてみたいです。