はじめに

JAWS-UGコンテナ支部 #29「App Runnerありがとう会」でLTする機会があり、この登壇資料を Spec-Driven Presentation Maker（以下SDPM）で絶賛作成中です。

日時: 2026/05/08(金) 19:00 〜 21:00

「いきなりスライドを書き始めない、まず仕様から固める」という、仕様駆動開発をプレゼンテーション作成に取り入れた体験をしたので、その流れや所感を共有します。

仕様駆動開発とは

仕様駆動開発（Spec-Driven Development）は、コードを書き始める前に「何を作るか」の仕様を先に固めるという開発スタイルです。
要件定義 → 設計 → 実装、という一見当たり前の流れですが、AI開発の文脈ではAIに仕様を渡してから実装させることで、手戻りや認識ズレを減らせるアプローチとして注目されています。
この考え方をプレゼンテーション作成に応用したのが SDPM になっています。

Spec-Driven Presentation Makerとは

SDPM（仕様駆動プレゼンテーション）はAWSが公開しているオープンソースのサンプル実装です。ざっくり言うと、「何を伝えるか」を先に設計してから、スライド構築をAIに任せるという考え方を実装したものです。ソフトウェア開発で言う「先に設計してから作る」のプレゼンテーション版です。

詳しくはAWSブログの紹介記事がとても分かりやすいです。

具体的には、以下の3つのフェーズで資料を設計します。

ブリーフィング — 聞き手は誰か、何を伝えたいか、聞き手にどうなってほしいかを定義します

アウトライン — 1 スライド 1 メッセージの原則で、各スライドが答えるべき疑問と、その答えを定義します

アートディレクション — 色使い、フォント、ビジュアルの方向性を定義します

設計書が完成した後に、AIがテンプレートに準拠してスライド（PPTX）を生成します。「いきなりスライド作成」を許してくれません。先にどういった資料を作るのか、考えざるを得なくなります。

利用形態は用途に応じて選べる

SDPMは、用途に応じて利用形態を選べます。

ユースケース	AWSアカウント
Kiro CLIで個人利用	不要
ローカルMCP（Claude Desktop / VS Code / Kiro）	不要
チームデプロイ	必要
フルスタック（Web UI + チャット）	必要

今回はローカルMCP をClaude Desktopから使う構成で試しました。AWSアカウント不要でサクッと試せるのが良かったです。

セットアップでいきなりつまずいた話

まずはGitHubからクローン。

git clone https://github.com/aws-samples/sample-spec-driven-presentation-maker.git
cd sample-spec-driven-presentation-maker

続いて依存関係をインストール。

cd mcp-local && uv sync

ここまでは問題なく完了。あとはClaude Desktopの設定にMCPサーバーとして登録……したのですが、起動に失敗しました。ログを見るとこんな感じでした。

args: [
  'run',
  '--directory',
  '/path/to/mcp-local',   ← ここがプレースホルダーのまま
  'python',
  'server.py',
]
error: No such file or directory (os error 2)

設定例の/path/to/mcp-localを脳死でそのままコピペしてました。実パスに置き換えるだけで解決しました。

{
  "mcpServers": {
    "spec-driven-presentation-maker": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/xxx/sample-spec-driven-presentation-maker/mcp-local",
        "python",
        "server.py"
      ]
    }
  }
}

サンプル設定をコピペするときはご注意ください。

実際のフロー：「App Runnerありがとう会」のLT資料を作る

MCP設定を行ったあとはチャットで以下のように伝えるとSDPMを認識しました。

Spec-Driven Presentation Makerで資料作成したいです。

するとこのような質問が来て、回答はチャット上で4択を選択する形式だったので、もしやこのまま資料作成してしまうのではと不安がよぎりました。

Q: どんなテーマの資料を作りたいですか？
Q: 想定スライド枚数は？
Q: デザインテイストの希望は？

こちらに回答すると後述するようにSDPMのフローが始まり安心しました。

Phase 1: ブリーフィング（聞き手と目的の定義）

先ほどの4択に回答すると、Phase 1のブリーフィングが始まりました。
Claudeがブリーフィングのワークフローを呼び出して、想定オーディエンス・前提知識・トーンの方向性などを段階的に確認してくれます。

実例

ワークフローに沿って、まず**Phase 1: ブリーフィング（企画の合意）**から始めます。スライドを作る前に「誰に・何を伝え・何を起こすか」を固める段階です。
App Runnerありがとう会の文脈を踏まえて、いくつか確認させてください。

前提の確認
[1] 想定オーディエンス
a. AWSをガッツリ使うエンジニア
b. App Runner利用経験者・興味がある人
c. JAWS-UGコンテナ支部のコアメンバー（ECS/EKSヘビーユーザー）
d. 全部混在（おそらくこれかも？）

[2] 前提知識
a. App Runnerをプロダクションで使い込んでいる
b. 触ったことはある／知っている
c. 名前は聞いたことがある程度
d. 混在

[3] トーンの方向性（ありがとう会というイベント性質を踏まえて）
a. しんみり追悼系（思い出語り・感謝中心）
b. 技術振り返り系（あの機能良かったよね、こう使ってた）
c. 教訓・次への接続系（App Runnerから何を学んだか／代替どうする）
d. 混合（思い出 + 技術 + 次へ）

数字＋短文での回答でOKです（例：1=d, 2=b, 3=d, 関わりは〜、時間は〜、背景は〜）。

ここで「とりあえず話したいことから書き始める」みたいな流し方をすると、後半で「あれ、これ誰に何を伝えたいんだっけ？」となりますが、SDPMは強制的にここを言語化させてくれます。

僕の場合は以前LTした「あなたの知らないApp Runnerの世界」をインプットして、トーンはノスタルジック寄り＋技術的にも納得感のある感謝という方向で合意しました。

インプット資料

Phase 2: アウトライン（構成設計）

ブリーフが固まると、構成設計に進みます。

僕のLTは10分=15スライド前後ということで、Claudeが提案してくれました。

第1幕：あの日の願望（スライド引用する）
転：現実（メンテナンスモード移行）
第2幕：それでも好きだった理由（業務事例）
第3幕：感謝と妄想（クロージング）

ここで嬉しかったのは、伏線回収の設計まで提案してくれたことです。どんな感じの仕上がりになったかは資料公開をお待ちください。

タイトル決め

タイトルは標準ワークフローだと後続のフェーズで決まる流れなのですが、先に決めたくなったので割り込んで先にやろうと伝えたら柔軟に対応してくれました。圧倒的優秀な存在です。

僕は2025年8月)のLTのタイトルが「あなたの知らないApp Runnerの世界」だったので、その続編として

「拝啓、あの夏の僕へ〜あなたも知っているApp Runnerの世界〜」

に着地しました。
「あの夏」というフレーズがとくに自分でも気に入ってます。

Phase 3: アートディレクションとスライド生成

ここからは実際のスライドJSONを組んでいくフェーズです。SDPMはMCPツール群を提供していて、Claudeがそれらを呼び出しながら作業を進めてくれます。例えばinit_presentation（ワークスペースの初期化）、measure_slides（テキストのはみ出し検出）、search_assets（アイコン検索）など。配色やトーンを決めた後、Claudeがmeasure_slidesでテキストオーバーフローを検出してくれたり、用意されているテンプレート・アセットから探してきてくれたりします。

ハマりポイントとしては、MCPの実行サンドボックス内のファイルパスと、自分のMacのファイルシステムのパスが食い違うことがありました。init_presentationで生成したはずのファイルが手元では空ファイルに見える、という現象です。

これはpresent_filesで直接ファイルを受け取る方法に切り替えて回避しました。（Claude自身でよしなに）
MCPサーバーをローカルで動かす場合の落とし穴かもしれません。

やってみての所感

良かった点

「いきなり書き始めない」が強制される
- これだけでもLT品質が一段上がる気がします
構成設計のプロにペアプロしてもらってる感がある
- 「ここで反転させましょう」みたいな提案が刺さります
ツール自体からは少し脱線するが、Claudeの提案精度が高いこと
- 普段からClaudeを使っているので、僕の思考や特性を汲み取ったうえで提案してくれます。
  例えばタイトル案を複数出してもらうと、Claudeが「個人的にはこれがオススメ」と教えてくれるのですが、その理由が僕の特性を踏まえていて、案を見た瞬間に「これだ」と思ったものと一致しているという体験が何度もありました。
  SDPMの構造化されたワークフローと、普段の対話で蓄積されたコンテキストが合わさることで、提案の質がグッと上がる印象です

気になった点

ファイル出力のパスにちょっと混乱した
全フェーズ真面目にやるとそれなりに時間はかかるので、シンプルなLTには不向きかも
- 魂込めて作りたいLTにおすすめ

こんな人にオススメ

LTで「内容は良いんだけど構成が散らかってる」と言われたことがある人
資料作成時にいきなりスライドを書いて後悔するタイプの人
Claude Desktopをすでに使っていて、もう一歩活用したい人

まとめ

Spec-Driven Presentation Makerは、スライド作成という工程に「設計」を持ち込んでくれるツールでした。

普段はテキストでClaudeと壁打ちしながらアウトラインなど作ることもありますが、SDPMを使ったほうが練度が断然違いました。鬼滅の刃でいうと柱稽古している感覚です。

「App Runnerありがとう会」の登壇資料は、自分史上一番納得感のある仕上がりになりそうです。当日のスライドは後日SpeakerDeckで公開予定です。この記事も更新して埋め込みます。

それでは良き仕様駆動プレゼンテーションライフを！

追伸

完成した資料がこちら！