Codexスライドの作り方｜PPTXを見やすく仕上げる依頼術

Codexスライドが今注目される理由

Codexはコードの修正だけを頼む道具だと思われがちですが、OpenAIの公式活用例には「Generate slide decks」が独立した項目として掲載されています。説明は、PPTXを操作し、画像生成も組み合わせてスライドを作るというものです。これは文章の章立てを返すだけではなく、内容を構造化し、編集可能なプレゼンテーションとして扱う方向が公式に示されたということです（出典: OpenAI Codex Use Cases）。

なぜ今このテーマを確認する価値があるのでしょうか。2026年7月31日には Codex CLI 0.147.0-alpha.4 が公開され、Codexの入口や対応範囲は短い周期で変わっています。公式の活用例ページも、コード以外の成果物を同じ作業場所で作り、確認する使い方を前面に出しています。新しい機能名を追いかけるより、資料を作る目的、元データ、確認基準を決めておく方が、版が変わっても再利用できます（出典: Codex CLI 0.147.0-alpha.4）。

PPTXと文章の下書きは別物

テキストの下書きは、言い回しや情報の順番を整える成果物です。一方でPPTXは、文字の大きさ、余白、図形の位置、ページをめくる速度まで含めて判断されます。同じ内容でも、見出しが長すぎれば視線が止まり、図と注釈の距離が離れれば意味を読み違えます。Codexへ頼むときは「原稿を書いて」ではなく、「編集可能なPPTXを作り、各ページの意図と確認点も残して」と成果物の単位を明示しましょう。

Codexに頼む仕事は「作る」より「直す」まで

最初の版を作ることだけを成功条件にすると、完成したファイルが発表の場で使えるか判断できません。初稿では構成を確認し、次の依頼で文字量、図表、色、ノートを直し、最後に数字と出典を照合するという段階を最初から設けます。Codexの公式資料が、成果物を見ながらコメントを次の指示へ変える考え方を紹介している点も、この進め方と相性がよいでしょう（出典: OpenAI公式資料）。

公式情報から分かることと分からないこと

公式ページから分かるのは、Codexの活用例としてPPTXの操作と画像生成を組み合わせたスライド作成が示されていることです。利用できる画面、契約プラン、対応する入出力の細かな条件まで、すべての環境で同一だと断定しているわけではありません。実際に使う前には OpenAIのCodexページ と表示される案内を確認し、手元の環境で開けるファイル形式と保存場所を小さな資料で試してください。

依頼前に決める四つの軸

スライド作りで時間がかかるのは、文字を入力することより「何を残し、何を捨てるか」を決めることです。Codexへ大量の資料を渡してから考え始めると、情報の重要度が均され、ページ数だけが増えます。先に四つの軸を決め、依頼文へ埋め込むと、Codexが迷ったときの判断基準を渡せます。次の表は、社内説明、顧客向け提案、技術共有のいずれにも応用できる最小セットです。

聞き手を職種ではなく判断で表す

「エンジニア向け」「経営層向け」だけでは、必要な説明の深さが決まりません。聞き手が発表後に何を判断するのか、どの言葉なら前提を共有できるのかまで書きます。たとえば「実装担当者が、既存の手順を変える価値があるか判断する」とすれば、背景説明を短くし、比較表と導入条件へページを使う方針が立ちます。

目的を一つの動詞にする

報告、提案、合意、教育、記録は似ているようで、必要なページが違います。「理解してもらう」だけで終わらせず、「承認してもらう」「候補を選んでもらう」「手順を試してもらう」のように、最後の動詞を一つ選びます。目的が二つある場合は、主目的と補助目的を分け、表紙や結論ページで何を優先するかをCodexへ明示すると、情報が散らかりにくくなります。

素材の出どころと使用範囲を整理する

入力する資料は、採用するもの、参考にするだけのもの、使わないものへ分けます。数値の原典、取得日、対象期間、画像の出典を同じメモにまとめておくと、作成中の言い換えで意味が変わりにくくなります。公開範囲が決まっていない資料は、先に共有してよい部分だけへ切り分け、Codexへ渡す内容を小さくしてください。

Codexスライドの作り方

ここからは、Codexに依頼してスライドを作り、確認用の版を経て共有可能な版へ近づける流れを説明します。大切なのは、一度の長い指示で全ページを完成させようとしないことです。構成、内容、見た目、確認の順番を分けると、どこを直せばよいかが明確になります。各Stepは、Codex CLI、デスクトップアプリ、ブラウザのいずれから始める場合にも使えるよう、特定の画面名へ依存しない形にしています。 この順番なら、初稿の内容が決まっていない段階でレイアウトを作り込み、後から全ページを崩す事態も避けられます。

Step 1: 目的と納品物を最初に宣言する

最初のメッセージでは、テーマだけでなく、聞き手、発表時間、ページ数、形式、完成の条件を書きます。「AIについて」では広すぎるため、「開発チームが新しいCodexの使い方を15分で理解し、試す対象を一つ選ぶ」のように、時間と判断を入れます。納品物はPPTXだけか、発表者ノート、出典表、確認用の画像も必要かを明記してください。

Step 2: 素材と出典を渡し、事実の境界を作る

公式ページ、社内メモ、計測表などを渡すときは、資料ごとの役割を書き分けます。事実として使うもの、仮説として扱うもの、まだ確認していないものを区別すれば、Codexが推測で空白を埋める可能性を下げられます。出典はURLだけでなく、どのページのどの数字を使ったかまで記録するよう依頼すると、最後の照合が簡単です。

Step 3: 先に構成案だけを確認する

いきなりPPTXを作らせず、まず表紙、問題提起、根拠、比較、提案、次の行動という流れをページ単位で出してもらいます。各ページに「主張」「根拠」「聞き手にしてほしいこと」の三つを付けると、ページ数の調整がしやすくなります。構成に無理がある段階で見つければ、レイアウトを作り直す手間を避けられます。

Step 4: 編集可能なPPTXとノートを作る

構成が固まったら、16:9、本文の最小サイズ、見出しの階層、色の数、ページ番号、発表者ノートの形式を指定します。画像や図形を一枚の画像へ焼き付けず、後から文字や数値を直せる形にすることも重要です。作成後は、ファイル名、保存先、使用した素材、未確認の箇所をCodexに報告させ、初稿の状態を把握できるようにします。

Step 5: ページごとの表示と内容を確認する

PPTXを開き、表紙から最後まで通して見ます。文字が枠からはみ出していないか、図表の凡例が読めるか、ページをまたいで用語が揺れていないかを確認します。さらに、発表者ノートだけに残った重要な説明がないかも見ます。本文にない前提をノートで補っている場合、その前提をページへ移すか、口頭説明として明記しましょう。

Step 6: 修正軸を一つずつ指定する

修正依頼は「全体をもっと良く」ではなく、「5ページの結論を一文にする」「7ページの表を二つに分ける」「全ページの出典表記を同じ位置へ揃える」のように対象と基準を指定します。大きな修正の後に、ページ数、数値、画像、ノートを再確認します。版を draft と review のように分け、共有するファイルを取り違えない名前にしておくと、確認漏れを減らせます。

そのまま使える依頼文

Codexへの依頼は、自然な文章だけでも進められますが、制作条件を見出しで分けると再利用しやすくなります。次の例は、技術機能の紹介資料を想定しています。テーマ、聞き手、数字、ページ数を自分の案件へ置き換え、まず構成案を返すように指定してください。公式活用例が示すPPTX操作や画像生成を使える環境でも、最初から見た目だけを要求せず、根拠と確認基準を先に渡すのがポイントです（出典: OpenAI Codex Use Cases）。

目的：開発チームが新しいAIコーディングエージェントの導入候補を比較し、次に試す対象を一つ決める
聞き手：実装経験はあるが、対象ツールの利用経験はない担当者
発表時間：15分
納品物：16:9の編集可能なPPTX、各ページの発表者ノート、使用した出典の一覧
ページ数：表紙と最後の確認ページを含めて10ページ以内
素材：添付した公式資料、計測表、既存の説明文だけを使う
内容の条件：
1. 最初に結論を示し、各ページの主張を一つにする
2. 数字には対象期間と単位を付け、推測した数字は使わない
3. 比較表には評価軸と判断理由を付ける
4. 画像には用途と出典を記録し、意味を説明できない装飾は避ける
5. 未確認の情報はページ上で「確認待ち」と分かるようにする
確認の条件：文字のはみ出し、用語の揺れ、数値の転記、出典の抜けをページごとに報告する
最初の返答：PPTXを作らず、ページごとの構成案と不足している素材だけを返す

この依頼文の要点は、作成の指示と確認の指示を同じ場所へ置いていることです。ページ数だけを指定すると、Codexは情報を小さくする基準を持てません。結論、根拠、比較、次の行動という役割を割り当て、何をもって確認済みとするかまで書くと、生成された資料を人が判断しやすくなります。

レイアウトと内容を確認するポイント

スライドは、ファイルが開けることと、発表で伝わることが別の品質です。PPTXの内部構造が正しくても、プロジェクターや共有画面では小さな文字、薄い色、細い線が見えなくなることがあります。また、ページ単体では整っていても、前後のページを続けて見ると同じ説明が重なったり、結論が遅れて出てきたりします。Codexへ確認を頼むときも、機械的な項目と人の判断が必要な項目を分けて伝えましょう。 表示確認は最後の飾りではなく、内容が届くかを確かめる工程として扱うのがコツです。

文字量は一枚の役割で決める

一枚に入る文字数の絶対値だけを決めるより、そのページの役割を先に決めます。結論ページなら短い主張と根拠だけ、背景ページなら用語の説明と前提だけにします。文章を削るときは、意味を保ったまま助詞を減らすのではなく、発表者ノートへ移せる補足と、画面に残す判断材料を分けるようCodexへ頼むと、読みやすさを保ちやすくなります。

図表は値・単位・期間を揃える

棒グラフや表を作るときは、値だけでなく単位、対象期間、母数、比較の方向を同じ場所へ置きます。元資料が「月次」と「累計」を混在させている場合、見た目を揃える前に定義を分けます。Codexには、図表を作ったあと「元データのどの行を使ったか」「丸めたか」「欠損値をどう扱ったか」を説明させると、数字の見栄えに引っ張られにくくなります。

画像は雰囲気より意味を確認する

画像生成を使う場合でも、画像が主張を補強しているかを見ます。表紙のイメージがテーマと関係しているか、図解の矢印が正しい方向か、実在する製品画面と誤解される表現がないかを一枚ずつ確認します。画像の出典、生成した日、差し替え候補をノートや一覧に残しておけば、後から発表先が変わったときも判断しやすくなります。

日本語の表示崩れを最後に読む

日本語の長い見出し、英数字の連続、括弧や引用符は、枠内に収まっていても視線の流れを崩しやすい部分です。PPTXをスライド一覧と全画面の両方で確認し、見出しの折り返し、行間、半角と全角の混在、フォントの置換を見ます。確認用の画像を書き出せるなら、縮小した状態でも結論が読めるかを見ると、会議室での見え方を想像しやすくなります。

うまくいかない依頼の直し方

Codexで作ったスライドが使いにくいとき、モデルの能力だけを疑う必要はありません。依頼の目的が広すぎる、素材の優先順位がない、修正の基準が見た目だけ、といった条件が原因であることが多いからです。まずどのページで何が伝わらないのかを一文にし、その原因に対応する情報だけを追加します。全ページを作り直す前に、二、三ページで修正の方向を試すと結果を比べられます。 失敗をページ単位で切り分ければ、次の依頼に必要な条件も自然に具体化できます。

「いい感じに」を具体化する

「洗練された」「分かりやすい」「プロらしい」は人によって意味が違います。余白を広くする、見出しを一行にする、色を三色以内にする、比較表の列を四つにするなど、観察できる条件へ置き換えます。参考にしたい既存資料がある場合は、好きな理由を「余白」「文字階層」「図表の位置」のように分解して伝え、内容そのものを複製する依頼にならないようにしてください。

情報を最初から詰め込みすぎない

元資料をすべて一つのページへ集約すると、Codexは重要度を判断しにくくなります。まず結論に必要な事実だけを選び、補足資料はノートや別紙へ分けます。ページ数が足りないときは、文字を小さくする前に、似た主張を統合する、例を一つに絞る、詳細を発表者ノートへ移すという順番で整理しましょう。

PPTXだけを受け取って終わりにしない

編集可能なファイルでも、表示環境によって改行やフォントが変わることがあります。PPTX本体に加え、ページごとの確認用画像、出典一覧、未確認箇所のメモを残します。確認者が別の端末で開く場合は、どの版を見たか、どの修正が反映済みかをファイル名へ含めます。成果物の中身と確認記録を一緒に扱うことで、修正の経緯を説明しやすくなります。

根拠のない数字を残さない

見栄えを整えるために、空欄を平均値や推測値で埋めるのは危険です。数字が必要なら、出典、取得日、対象範囲を指定して調べ直すか、「未確認」と表示します。Codexへは、根拠が見つからない場合に数字を作らず、確認待ちの文言を置いて報告するよう依頼してください。発表直前の差し替えでも、グラフと本文の値が同じかを照合します。

Codexに任せない最終判断

Codexは構成を考え、文章を整え、図表を組み、PPTXを編集する作業を速められます。しかし、資料を公開してよいか、数字の定義が意思決定に耐えるか、発表の場で誤解を生まないかは、利用者が判断すべき領域です。公式の活用例が示すのも、成果物を作ってレビューする流れであり、確認を省略してよいという意味ではありません。便利さを保ちながら責任の所在を明確にするには、次の三点を最後の確認項目として残します。 作成速度が上がるほど、最後の確認を短縮しないことが資料の信頼性につながります。

数字と引用は原典へ戻る

スライドの文章が自然でも、引用元の範囲を越えていないとは限りません。原典のページ、更新日、対象読者、定義を開き直し、スライドの主張と照合します。公式ページへのリンクを置くだけでなく、どの記述を根拠にしたかを出典表へ書けば、発表中の質問にも答えやすくなります。更新が早い製品の情報は、発表日を更新日として記録しておくと、古い数値との混同を防げます。

公開範囲を決めてから素材を使う

会議用の資料に含まれる顧客名、個人情報、未公開の計測結果は、スライドの目的に必要な範囲だけへ絞ります。Codexへ渡す前に、固有名詞を役割名へ置き換え、不要な行を削り、公開版と内部確認版を分けます。作成後は、ノート、画像の代替テキスト、ファイルのプロパティまで含め、見せる相手に不要な情報が残っていないか確認してください。

発表者の声に合わせる

スライドは読ませる文書ではなく、話しながら見る補助線です。Codexが整えた文章をそのまま読み上げるのではなく、発表者が自然に説明できる言葉へ直します。専門用語の読み方、略語を最初に説明する場所、質問が出そうな前提をノートへ残し、聞き手が迷うページには短い補足を入れます。最後に一度、時間を計って通し、予定時間に収まらない場合は文字を小さくせず内容を減らしましょう。

まとめ

Codexスライドの作り方で重要なのは、派手なデザインを一度で出すことではありません。聞き手と目的を固定し、根拠を整理し、構成案を確認してからPPTXを作り、表示と内容を別々に見直すことです。公式の活用例は、CodexがPPTXの操作と画像生成を組み合わせてスライド作成へ使える方向を示しています。一方で、実際の画面や利用条件は更新されるため、OpenAIのCodex公式ページ と Codex Use Cases を確認しながら、小さな資料で試すのが安全です。2026年7月31日のCLI更新のように入口が変わっても、目的、出典、確認基準を依頼文へ残しておけば、スライド作成の品質を同じ軸で保てます。