スライド作成をAIに頼むと、形式は整っていても構成がその都度ブレます。原因は単純で、生成ツールが「形式」は持っていても「テーマ別の鉄則」を持っていないためです。
この検証では、スライド構成のパターン辞書を自作スキルとして持たせ、PPTX生成は既存スキルに委譲するという設計を試しました。スキル雛形の構築からPPTX出力まで約30分で到達しています。
この検証の概要
検証時期 | 2026年5月6日〜（検証中） |
|---|---|
対象 | slide-design-patterns（自作 Claude Code スキル）v0.1 |
やりたかったこと | スライド作成依頼に対し、テーマ別の鉄板構成を即座に提案できる状態にする |
設計 | スキル本体は構成提案のみを担当し、PPTX生成は既存スキルに委譲 |
成果 | 「3ツール比較スライド5ページ」の依頼で構成提案 → PPTX出力まで1〜2分で完了 |
判定 | 条件付きで導入可／追加検証が必要 |
参照元とした外部記事は個人研究用にローカル保管しており、本文・画像の再配布は行っていません。提案時には出典URLを併記する運用としています。
結論：役割を分けるとスキルが安定する
この設計の核心は分業です。
役割 | 担当 |
|---|---|
構成の提案（どんな型で作るか） | パターン辞書スキル |
PPTXの生成（どう出力するか） | 既存の生成スキルへ委譲 |
1つのスキルに構成判断と出力処理の両方を持たせると、どちらも中途半端になります。辞書を引いて型を決める工程と、それを形にする工程を分けることで、それぞれを独立して改善できます。
実際、「比較スライド作って」という依頼に対して辞書 → 構成提案 → 生成スキル委譲のフローが想定通り動きました。
パターン辞書の構造
約50パターンを7カテゴリに分類しています。
- A: グラフ系
- B: 図解系
- C: レイアウト系
- D: 戦略フレーム系
- E: 配色
- F: 業界別リファレンス
- G: メタ
重要なのは、辞書そのものより引き方です。
「依頼ワード逆引き」表を用意し、ユーザーの依頼文から該当パターンへ即座に辿れるようにしています。「比較スライド作って」「事業ポートフォリオ可視化」といった自然な依頼から、対応する型に到達できる形です。
知識を持っていることと、必要なときに引けることは別です。辞書は引く経路とセットで設計する必要があります。
スキルの発動率を上げるコツ
実装上の知見として、明確なものが出ています。
スキルのdescriptionには「依頼キーワードを過剰なほど列挙」した方が発動率が安定します。
スキルは、書いてあっても呼ばれなければ意味がありません。「どんな言い方で頼まれるか」を想定して並べておくことが、実用性を左右します。
実際の出力
「Codex / Gemini CLI / Claude Code の3ツール比較スライドを5ページで」という依頼で検証しました。
スライド | 内容 |
|---|---|
1 | タイトル |
2 | エグゼクティブサマリー（用途で使い分ける3択） |
3 | 6軸×3列の比較表 |
4 | ユースケース別カード |
5 | 選び方フローチャート |
5ページが破綻なく生成され、配色指定と強調記法によるプライマリカラー化も機能しました。スキル発動からPPTX出力までは1〜2分です。
ただし、評価には条件が付いています。初稿レベルなら即戦力。ただし配布前に事実確認（ライセンス・無料枠の数値）は必要。
構成は任せられても、事実は任せられません。比較表の数値は、必ず最新の公式情報で確認する工程が要ります。
データ取得で得られた知見
参照元の記事を収集する工程でも、実用的な発見がありました。
- APIのバージョンが機能ごとに混在している — 一部の機能はv1でないと404になる
- フィールドの命名規則が統一されていない — 一方はcamelCase、もう一方はsnake_caseという混在
- ページング判定の方法もエンドポイントによって異なる
非公式APIを使う場合、エンドポイントごとに仕様が揃っていない前提で組む必要があります。「同じサービスのAPIだから同じ書き方でいける」とは限りません。
取得自体は、並列処理により90件のメタ情報＋78本の本文＋1,631枚の画像を数分で完了できました（画像ダウンロードはエラー0件）。
著作権への配慮
この検証では、扱い方を明確に決めています。
- 本文・画像は個人研究用にローカル保管。再配布は行わない
- データはgit管理外のディレクトリに隔離（約186MBの画像を含む）
- 提案時には出典URLを併記する運用
- 記事化にあたって画像を直接利用しない。あくまで構成パターン抽出の参考用途
外部の情報源を参照するスキルを作る場合、この線引きを最初に決めておく必要があります。後から整理するのは困難です。
つまずいた点
症状 | 原因 | 対処 |
|---|---|---|
スキルからプロジェクトを参照できない | 相対symlinkの階層を誤った | 正しい階層に修正（移動時の追従手順もSKILL.mdに明記） |
| APIが404 HTMLを返している | エンドポイントを確認 |
| python3が別環境を指していた | 使用するpython3のパスを明示 |
symlinkについては、相対パスにしたことで「将来プロジェクトを移動する前提」の要件をクリアできています。絶対パスにしていると、移動のたびに壊れます。
残っている課題
- 画像をAIに視覚情報として渡せていない（現状はパス案内のみ）
- 配色テンプレと業界別リファレンスは、依頼ワードとの紐付けがまだ弱い
- 複雑な依頼（大規模なピッチデック等）での耐久性は未検証
- 参照元のAPI仕様変更・記事削除で更新パイプラインが壊れるリスク
1つ目が本質的です。現時点ではテキスト情報としてのパターンしか渡せておらず、実際の見た目をAIが参照できていません。マルチモーダル入力を経由する方式が次の検証項目になります。
よくある質問
既存のPPTX生成ツールと何が違いますか？
テーマ別の「鉄板構成」を持っている点です。生成ツールは形式を出せますが、どんな型で作るべきかの判断は持っていません。構成提案と生成を分業させることで、この差を埋めています。
どのくらい速くなりますか？
比較スライド初稿の構成検討が30〜60分から数分になる見込みです（要追加検証）。スキル発動からPPTX出力までは1〜2分でした。
そのまま配布できますか？
できません。構成は破綻なく生成されますが、比較表の数値などの事実関係は、配布前に最新の公式情報で再確認する必要があります。
外部記事を参照する際の注意点は？
本文・画像の再配布は行わず、構成パターンの抽出に限定することです。データはgit管理外に隔離し、提案時には出典URLを併記する運用にしています。
まとめ
- 構成提案と出力処理を分業すると、スキルが安定する
- 辞書は「依頼ワード逆引き」とセットで設計する。持っていることと引けることは別
- スキルのdescriptionには依頼キーワードを過剰なほど列挙すると発動率が安定する
- 構成は任せられても事実は任せられない。数値は配布前に必ず確認する
- 非公式APIはエンドポイントごとに仕様が揃っていない前提で組む
- 外部情報源を参照するスキルでは、再配布しない・git管理外に隔離・出典を併記の線引きを最初に決める
- symlinkは相対パスにすると移動に追従できる
AIに任せる範囲を「判断」と「作業」に分けると、それぞれ改善しやすくなります。どこまでを型として持たせるかが、出力の安定性を決めます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。