gogとCodexでGoogleスライドを作る

はじめに

AlgomaticでBtoB向けAX（AI Transformation）事業の営業をしている、五十嵐夏菜（かなきゃん）です。普段は、お客様の業務課題を整理してAIの組み込み方を提案したり、検証設計や提案資料・ウェビナーの企画運営をしています。

非エンジニアの私がテックブログを書くのは少し緊張するのですが、今回は普段 ClaudeCode や Codex で回している業務の中でも特に頻出の「スライド作成」について書いてみます。

この記事は Algomatic 初夏のアドベントカレンダー 17日目です。前回は Go さんの「AI生成コードを保守するために、開発を『水彩』と『油絵』で分ける」でした。

テーマは、営業の現場で提案資料づくりにコーディングエージェントをどう使うか。ここ数ヶ月実戦投入している Codex CLI + Google Slides + gog CLI の話です。

以前 AI企業で働く私のガチ利用AIツール3選（2026年4月末時点） という記事を書きましたが、今回はその実務編にあたります。試す前は「全部を画像生成で作れば速いのでは？」と思っていたのですが、数ヶ月やってみて、その仮説は実務では通用しないと分かってきました。

結論を先に書くと、こうです。

AIに完成スライドを丸投げするより、編集できるスライドを作るための工程を設計する方が、実務では効果的だった。

全部をAI画像にするのではなく、Google Slides 上に編集できる要素を残し、AI画像は必要なところだけ使う。この分担が一番扱いやすかった、という話です。

冒頭の作例は、既存のGoogle Slidesテンプレートを複製し、Claude CodeやCodexからgogを操作して、表・矢羽・テキスト・体制図を編集可能な要素として組んだものです。

ただ、最初からこの形だったわけではありません。画像だけで押し切って直せなくなったり、Slides API の画像挿入で詰まったり、Codex の実行環境で gog が動かなかったり……と紆余曲折がありました。この記事ではその過程を書きます。

想定読者: Google Slides や提案資料づくりに、コーディングエージェントを入れてみたい人

扱うこと: Codex image_gen、gog CLI、Google Slides API まわりで実際にハマったこと

扱わないこと:「AIにいい感じのスライドを全部作らせる」系の一般論

何を作って、何を使ったか

作っていたのは営業・提案・ウェビナーといった日常業務のスライドです。冒頭の作例のように、与件整理、テーマ選定、スケジュール、支援体制などのページが対象でした。

素材と道具はこのあたりです。

• Codex: 調査、構成整理、ローカルファイル操作、画像生成指示

• Codex image_gen: 図解・アイコン・概念図の生成

• gog CLI: Google Drive / Slides を CLI から読む・編集する

• Google Slides: 最終的な編集面

• Git: 生成画像や挿入ガイドの保存

gog は Google Workspace を CLI から触るための OSS で、Gmail / Calendar / Drive / Docs / Sheets / Slides などを1つの CLI から扱えます。今回はスライド一覧の取得、テキスト置換、作業後の再取得確認に使いました。

やりたかったことはシンプルで、構成メモや案件メモをもとに Google Slides 上で編集できる資料に整えること。ただ、ここに落とし穴がいくつもありました。

最初に大事な前提を。gog を使えば CLI から Google Slides を新規作成できますが、ゼロから作らせるのはかなり厳しいです。

テンプレート無指定で「この内容で10枚作って」と頼むと、汎用的で見た目も弱く、会社の資料らしさもないものが出てきます。

内容は入っていても、提案資料としてはそのまま使いづらい。ここで、既存テンプレートやページの型を渡す重要性を痛感しました。

うまくいったのは、新規作成ではなく既存テンプレートを編集させるやり方です。冒頭の作例も、テンプレートを複製してフォント・余白・図形・配色を保ったまま中身を差し替えています。指示は最初からこう書きます。

新しいスライドをゼロから作らないでください。

既存のGoogle Slidesテンプレートを複製し、元のテキストボックス、フォント、

余白、図形、配色をできるだけ維持したまま編集してください。

プレースホルダー文字列は削除して作り直すのではなく、同じ要素の中で置換してください。

Webアプリでいえば、白紙のHTMLを生成させるのではなく、既存デザインシステムのコンポーネントを差し替えさせる感覚です。「このP17の型を参考にP16を完成させる」「この表を3列から4列に増やす」「この矩形に収まるよう文量を調整する」くらいの操作に落とすと、急に実用的になります。

画像だけで作り切ろうとして、つまずいた

最初は、Codex で 16:9 の完成画像を作ってそのまま貼れば速いと思っていました。実際、業務フローや相関図、ToBe像のような複雑な図解は、画像でラフを作るだけでも前に進みます。

ただ、資料は作って終わりではありません。レビューで「ここだけ直したい」「この行を1つ増やしたい」は必ず来ます。全部が画像だと、軽微な修正でも再生成が必要で、しかも再生成すると別の箇所や文字が崩れます。画像だけのスライドは特にこのあたりが弱い。

• 日本語テキストを後から直せない

• 一部だけ変えたいのに再生成が要る

• Slides のテンプレ要素と馴染まない

• 画像内の文字が微妙に崩れる

そこで、画像生成と Google Slides 編集を役割分担することにしました。

1枚のスライドの中でも役割を分けます。表・スケジュール・体制図のようにテンプレートの要素で表現できるページは gog で。ピクトグラムや抽象的な概念図のように、絵を起こした方が速いものは image_gen で。左側の概念図は画像生成で作って背景透過で貼り、右側の枠やテキストはテンプレートの図形・テキストボックスで組む。これで見た目の初速と、後からの編集可能性を両立できます。

今の自分の型はこうです。

• 既存テンプレートで表現できるページ → gog で Slides 要素として編集

• 新しい概念図や ToBe像 が要るページ → まず image_gen で完成イメージ

• その画像を参考に、必要な要素だけ人間が拾う

• サイズ調整・行追加・列幅・文字量の調整は gog に寄せる

画像生成は完成スライドの代替ではなく、方向性を出すための高速な素材生成。gog は既存テンプレートを壊さず編集可能なスライドに落とす実装手段。この分担が一番しっくりきています。

つまずいたところ

1. 型とタイトルをAIに丸投げすると崩れる

「この提案資料を作って」と大きく渡すと、ストーリーはそれっぽく組んでくれます。でもスライドタイトルやメインメッセージの言葉がどこかAIっぽい。意味は通るのに、提案資料の骨格になる一文としては気持ち悪い、ということが何度もありました。

「今回のご提案背景」で十分な場面でも、AIは「なぜ Phase 1 のご提案に至ったのか」のように妙に説明的なタイトルを付けがちです。

ここは人間が先に粗く決めた方が速い。「この順番で話す」「このページはこれを言う」「ここは表ではなく矢羽」「ここはP17に近い」「ここは概念図だから画像生成」——箇条書きや音声メモでよいので、"何を言うページか" と "どの型に近いか" を先に置きます。AIには、その骨格をもとに言葉を整えたり、Slides要素に落とさせたりする。

逆に gog が得意なのは、型が決まった後の編集です。全スライドのフォントをそろえる、見出しだけ太字にする、3列を4列に増やす、矩形に収まるよう文量を調整する。AIに任せるべきは「何を言うか」の意思決定ではなく、決めた型を Google Slides 上で破綻なく実装する部分でした。

2. gogは実行環境とAPI制約で詰まる

人間のターミナルで動くことと、エージェントの実行環境で動くことは別でした。自分のターミナルでは動くのに、Codex から実行すると gog が見つからない。原因は、Codex が起動する非対話シェルでは普段の .zprofile や .zshrc が読まれないことでした。最終的に gogcli を Homebrew で入れ直し、非対話シェルでも読まれる .zshenv に PATH を追加して解決しました。

確認は本番スライドを触らず、テスト用スライドで行いました。

gog slides create-from-markdown ...

gog slides replace-text ...

gog slides raw ...

gog drive delete --force ...

もう1つは画像挿入。image_gen で作った画像を gog slides insert-image で差し込もうとしたら、組織設定や公開URLの制約で publishOutNotPermitted に当たりました。Google Slides API の画像作成リクエストは画像URLを指定して Slides 側が取得する形なので、ローカルのPNGを入れたいだけでも社内の公開制限に引っかかります。

ここは画像挿入の完全自動化を諦めました。Codex で素材を生成 → リポジトリに保存 → 挿入ガイドを作り、貼り付けは人間が UI で、貼り付け後のテキスト修正や QA は gog で。この分担の方が全体としては速かったです。

3. image_genの出力管理を雑にすると事故る

Codex に「スライド画像を作って」と頼むと、image_gen を呼ばずに matplotlib や PIL でそれっぽい画像を描こうとすることがあります。クオリティが低いだけならまだしも、~/.codex/generated_images/ に新しい画像が作られないことがあり、「最新の生成画像」を拾うスクリプトだと過去画像を拾って複数スライドが同じ画像になる、という事故が起きます。

対策は2つ。1つはプロンプト先頭に明示すること。

あなたは画像を生成するエージェントです。

必ず image_gen ツールを直接呼び出して画像を生成してください。

Pythonスクリプトで画像を生成してはいけません。

もう1つは、生成前後のディレクトリ差分で新規画像を特定することです。

before=$(mktemp)

ls ~/.codex/generated_images/ > "$before"

# codex exec ... を実行

new_dir=$(ls ~/.codex/generated_images/ | grep -vFf "$before" | head -1)

ls -t | head -1 で最新を拾うだけだと、失敗時に過去画像を拾います。生成AIの出力はただでさえ揺れるので、保存・検証まで曖昧にすると一気に壊れます。

画像生成プロンプト自体にも注意が要ります。細かい日本語テキストを入れる指示をすると、モデルが「画像内の日本語は崩れるので後から重ねる前提に」と判断することがあります。親切ではあるのですが、スライドでは困るので「日本語も画像内に含める」と明示しました。ただし人名・金額・日付・タイトルのように正確性や編集が重要なものは、Slides のテキスト要素として残した方が安全です。

現時点でのベストプラクティス

数ヶ月試して、今はこの流れに落ち着いています。

• 構成メモ・スライド番号・そのページで言いたいことを Markdown で対応づける

• ストーリーと型は人間が先に粗く置く（タイトルまで作り込まない）

• gog は本番資料の前に、テストスライドで作成・置換・読み取り・削除まで通す

• 全スライドを同じ作り方で進めず、最初に3種類へ仕分ける

• 生成画像・挿入ガイド・構成メモは Git に残す（~/.codex/generated_images/ に置きっぱなしだと、どの画像をどのスライドに使ったかが追えなくなる）

ステップ4の仕分けは、こんなイメージです。

種類

作り方

既存テンプレートで表現できるページ

gog でテンプレートを複製・編集する

新しい概念図や ToBe像 が必要なページ

Codex image_gen で完成イメージを作る

画像と Slides 要素を混ぜるページ

人間が必要な要素を拾い、整形を gog に任せる

この仕分けをせず全部を画像生成に寄せると後で直せず、逆に全部 gog だけで作ろうとすると概念図や絵作りで苦しくなります。

参考リンク

• Codex CLI - OpenAI Developers

• Claude Code - Anthropic

• Image generation - OpenAI API

• gog GitHub Repository

• gog 公式ドキュメント

• Google Slides API: CreateImageRequest

• Google Slides API: Add images to a slide

なお、掲載しているスライドはすべて架空の提案資料であり、実在の顧客・案件・人物とは関係ありません。

まとめ

• 全面画像化より、編集可能な骨格 + 画像素材のハイブリッドが実務向き

• タイトル・ストーリー・型選びは、人間が粗く置いてから AI に実装させる

• gog は既存テンプレートの編集に便利だが、PATH や API 制約の確認が要る

• Codex image_gen は便利だが、保存・検証まわりを雑にすると事故る

AIで資料作成が速くなるのは間違いありません。ただ速くなる理由は「AIが全部やってくれる」からではなく、人間が最後に直しやすい状態を AI と一緒に作れるからだと思っています。

AIでスライドを作るなら、完成画像より、編集可能なスライドのための素材と作業ログを整える方がいい。

エンジニアもAI好きなBiz職も絶賛募集しています！

ここまで読んでいただきありがとうございました！Algomatic では「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも学びと試行錯誤を続けられるエンジニアを募集しています。少しでも気になったら、ぜひカジュアル面談へ。