目次
2026年9月8日、NotebookLM（現 Gemini Notebook）のスライドやインフォグラフィックを、編集できるPPTXに変換するSaaS「Swift-Slide」をリリースしました。
なぜ作ったかという個人的な経緯はnoteに書いたので、こちらでは中身の話だけを書きます。
2026年2月の時点で先行サービスに全項目で負けていた状態から、8月末までに何をしたか、という話です。
最初に作ったのは、社内用のGoogle Apps Script＋Gemini APIの変換ツールでした。動くには動く。ただ、先行サービス（Codia AI NoteSlide）と並べて測ってみたら、こうなりました。
1ページあたりの変換コスト：負け
変換精度：負け
変換時間：負け
全敗です。この状態で出しても劣化版にしかなりません。やめようかと思った時期もありました。
最初にやったのは、指標の定義を固めることでした。「精度が上がった気がする」を繰り返しても、半年後に何も残らないからです。
特に精度は言葉が曖昧なので、次の3つに分解しました。
消し切れているか — 1枚のスライドから、消し漏れなく文字を除去できるか
戻せているか — 適切な位置に、適切な文字サイズで再配置できるか
色が合っているか — 元の文字色を再現できているか
この3つに割ってから、改善の打ち手がはっきりしました。「精度が低い」ではなく「2番が弱い」と言えるようになると、次に何を触ればいいかが決まります。
コストと速度も同じで、固定のサンプル資料を用意して、変更のたびに同じものを流す。地味ですが、これが半年間の判断のすべてを支えました。
現在の構成は、1ページごとに4つの処理を通す形に落ち着いています。
文字認識（OCR） — ページ画像から文字と座標を読み取る（Azure Document Intelligence）
図表の分類 — 文字と図・イラストを見分け、消してよい文字だけを選ぶ（Vertex AI Gemini）
背景復元 — 文字を消した跡を埋める（RunPod上で画像インペインティング）
スタイル推定と再配置 — 色・サイズ・配置を推定し、編集できるテキストとしてPPTXに戻す
初期のGemini中心の構成と比べて、1ページあたりのコストは桁が変わる水準まで下がりました。効いたのは3つです。
インペインティングを自前推論に切り替えた。 背景復元を外部APIに頼るのをやめ、RunPod上で自前で回すようにしました。ここが削減の主因です。
色と配置の判定を、バックエンドの自前ロジックに移した。 当初は文字のスタイル判定までAIに投げていました。これを内部処理に置き換え、チューニングを重ねた結果、この工程のAPIコストがまるごと不要になりました。処理時間も短くなっています。
「どこをAIに任せ、どこを自前で書くか」は個人開発でずっと悩むところですが、少なくとも自分のケースでは、AIに投げていた判定のうち、自前のロジックで置き換えられるものが思っていたより多かったというのが結論でした。
AIを使う範囲を絞った。 ただし、これはコストのためというより品質のための判断だったので、次章で書きます。
そのうえで各処理のチューニングを繰り返し、1ページあたりの処理時間も大幅に改善しました。
一番苦戦したのがここでした。
文字を消して背景を埋める処理の質は、インペインティングそのものより どこを消すか で決まります。そして途中で気づいたのは、消さないほうがいい文字があるということでした。
イラストの中に文字が焼き込まれている場合、それを消して背景を復元すると、絵として破綻します。文字だけがきれいに消えても、資料としての品質は下がる。
なので、こうした領域は剥がしと再配置の対象から外すことにしました。品質を守るための判断でしたが、結果として処理対象が減り、コスト削減にもつながっています。
もうひとつ、早い段階で受け入れた前提があります。AI変換は完璧にはならない、ということです。
だから変換して終わりにせず、ブラウザ上に編集画面を用意しました。消し残しはブラシでなぞればAIが背景ごと修復し、消えてしまった図やロゴは元画像から範囲を切り取って復元できます。
先行サービスとの差がはっきり出たのはこの部分でした。AIに作り直させるのではなく、元のデザインを保ったまま、細かく直せる。ここを軸に据えると決めてから、優先順位がぶれなくなりました。
4つの処理を1ページずつ直列に回すと、100ページの資料は現実的な時間で終わりません。ページ単位で並列処理する構成にしています。
実行環境はCloud Runで、リクエスト量に応じて複数インスタンスが自動でスケールアップ／ダウンします。ひとりで運用する以上、深夜に手動で増強するような設計にはできません。
ページ数 変換時間 1ページ 約27秒 15ページ 約1分12秒 111ページ 約3分54秒
（2026年3〜7月の実測例。原稿・混雑状況により変動します）
ページ数が7倍になっても、時間は3倍強に収まっています。実運用と負荷検証を合わせると、累計で10,000ページ以上を変換しています。
ただ、混雑時に遅延が出ること自体は避けられません。そこで、遅くなったときにどう見せるかも作りこみました。遅延が発生している場合は画面に「遅延発生中」と表示し、ダッシュボードに戻るよう案内したうえで、完了時にメールで通知します。処理中に画面を開いたまま待たせない、というだけの話ですが、待ち時間の体験はこれでかなり変わります。
並列化の工夫より、使い続けてもらえるかどうかはこういうところで決まる気がしています。
先行サービスは、1回の処理でオブジェクト分離とテキストの再配置まで完了します（2026年8月時点の私の理解です）。Swift-Slideの変換は文字の剥がしと再配置までで、オブジェクト分離はエディタ上の追加機能として、必要なときに実行する形です。
一発で全部済ませたい人にとっては、手数が増えます。ここは素直に負けている点です。
そのうえでこの設計にしたのは、変換時に全オブジェクトを分離すると、意図しない切り離しが起きたときに戻す手段がないからです。必要な箇所だけ後から分離できるほうが、業務で使う資料では扱いやすいと判断しました。
前章の「イラスト内の文字は剥がさない」も同じ考え方で、全部を自動でやりきるより、外したくない部分は人が触れるようにしておく、という方針で通しています。この判断が正しかったかは、これから使われてみないと分かりません。
2026年2月 → 2026年8月末
1ページあたりの変換コスト：負け → 同等以上
変換精度：負け → 同等以上
変換時間：負け → 同等以上
全敗から、同等〜部分的に上回る水準まで来ました。
半年前に「勝てる気がしない」と思っていた3つの数字が動いたのは、自分の実装力が急に上がったからではありません。この半年でモデルが進化して解けるようになった問題と、AIに任せるのをやめて自前で書いたら解けた問題が、両方あった。その切り分けを繰り返していただけです。
9月8日に日本向けにリリースし、9月15日にProduct HuntとShow HNなどで英語圏にも出す予定です。
Freeプランは月5ページ＋初回登録ボーナス5ページ、クレジットカード不要です。NotebookLMで作った資料が手元に残っている方は、1枚試してみてください。
https://swift-slide.com/
実装で気になる点があれば、コメントでもXでも聞いてください。答えられる範囲で書きます。
X: @tsuyoshibuilds
コメントはまだありません