jinba-consulting-pptx-skillとは？使い方・導入・PPTX変換を解説

2026年9月9日、「A社向けのAI導入提案書を15枚で作って」と頼むだけで、コンサル会社の作法に沿った資料が出てくるというClaude Code向けのスキルが、X上で7万回以上表示されて話題になりました。

公開されているのはconsulting-pptx-skill。AIエージェント基盤「Jinba」を開発するCarnot AIが、自社で毎週の提案書・報告書づくりに使っている仕組みを公開したものです。

【2026年11月10日更新】GitHubのリポジトリ名は現在 jinba-consulting-pptx-skill（carnot-tech/jinba-consulting-pptx-skill）に変わっています。旧URLの carnot-tech/consulting-pptx-skill は新しいURLへ転送され、READMEとスキル自体の名前は consulting-pptx-skill のままです。パーツ集が65型に増え、HTMLから編集できるPowerPointに変換する仕組みも加わったため、この記事の該当箇所を最新のREADMEに合わせて直し、導入から使い方までの手順を追加しました。

AIに資料を作らせると、体裁は整っているのにそのままでは出せない——という経験は多いはずです。このスキルは、そこを「プロンプトの書き方」ではなく「ルールをファイルにして毎回読ませる」で解こうとしています。中身を見ていきます。

本体は約110項目の「スライド規約」というテキストファイル

READMEでは、「このリポジトリでいちばん価値があるのは、実はテンプレでもスクリプトでもない」と明言されています。中心にあるのは references/slide-rules.md という1枚のテキストファイルです。

実務の資料レビューで受けた指摘を1行ずつ書き溜めたもので、READMEの記載では約110項目。挙げられている例は次のようなものです。

• 結論はタイトルに書く
• 角丸禁止
• 塗りのあるボックスに枠線を付けない
• 1資料1用語
• 前提・定義は左、帰結は右

なぜ「口頭で注意する」ではなくファイルなのか

READMEはその理由をはっきり書いています。AIはセッションごとに記憶がリセットされるので、口頭で注意しても定着しない。だからルールをファイルにして、作らせる前に毎回読ませるのだ、という説明です。

そのうえで使い方は3つだけ、とされています。①作る前に規約を読ませる ②出力後に機械チェックで違反を検出する ③別のエージェントにレビューさせて、採用する指摘だけ直す。

65種類の「型」は発想帳として使う

スライドの部品集として、基本30パーツ＋追加35パーツの計65型のHTMLパーツが同梱されています（公開当初は62型）。表紙・全体マップ・矢羽・前提→帰結・軸のある表・評価表・分布図といった基本形から、エグゼクティブサマリー・積み上げ棒・ブリッジ・散布図・マトリクス・ロードマップ・ガントまで。型を探すときの入口は、全65型を印刷した型カタログPDF（assets/SlideCatalog_16x9.pdf）です。

ただしREADMEは「65型は作れる見せ方の上限ではない」「レイアウトの発想帳として使い、合わなければ捨ててください」と釘を刺しています。型に資料を合わせるのではなく、型を捨ててでも規約の範囲で組む、という立て付けです。

機械チェックと「フレッシュアイ・レビュー」

組んだ後の検査が2段構えになっているのが特徴です。

• scripts/check_deck.py：規約違反の機械検出。プレースホルダーの消し忘れや、タイトルに書いた「N段階」と本文の連番の食い違いもエラーにする
• scripts/check_layout.mjs：実際にレンダリングして、フッターとの重なり・右端や下端のはみ出しを検出する（Node.jsとPlaywrightが必要）
• references/content-review-prompt.md：作り方を伏せた別のエージェントにデッキを読ませ、日本語・論理・矛盾の指摘を採否表にして、採用分だけ直す

さらに references/ai-smell-lexicon.md という「AI臭い言い回し」のリストも同梱され、文章の仕上げ時に使うと案内されています。

基本情報

jinba-consulting-pptx-skillの使い方：導入から資料づくり、PPTX変換まで

2026年11月10日時点のREADMEに沿って、入れる→頼む→検査する→PDF・PPTXにするまでを順に見ます。

1. 導入する（セットアップ）

Claude Code のスキルフォルダにリポジトリを clone します。READMEのコマンドは旧URLのままですが、GitHubが新しいURLへ転送するので、どちらでも入ります。

git clone https://github.com/carnot-tech/jinba-consulting-pptx-skill.git ~/.claude/skills/consulting-pptx-skill
cd ~/.claude/skills/consulting-pptx-skill && npm run setup

• 1行目の clone だけで、規約・パーツ集・機械チェックが使えます
• 2行目は、PDF化と実レンダリング検査に使う Chromium headless shell を入れる手順です（Node.jsが必要。ダウンロードは約95MB。Linuxのコンテナなどでは npm run setup:linux）
• PDFを画像にして確認する snapshot.py には、poppler（pdftoppm）が別に必要です（macOSなら brew install poppler）
• PPTXに変換する場合だけ pip3 install python-pptx を入れます（Node.js 22以上も必要）

Claude Code に「https://github.com/carnot-tech/jinba-consulting-pptx-skill を ~/.claude/skills に入れて」と頼んで入れてもらう方法も、公開元の投稿で紹介されています。

2. Claude Code に資料を頼む

入れたあとは、Claude Code に作りたい資料を頼むだけです。公開元の投稿では「A社向けのAI導入提案書を15枚で作って」のように頼み、参考にする資料・調べてほしいこと・伝えたいことなどの背景情報を、できるだけ多く渡すよう勧めています。スキルは、規約を読む→パーツ集から必要なパーツを取り出して1枚ずつ組む→機械チェックを通す→作り方を知らない別のエージェントにレビューさせる、の順で進めます。

3. 手で動かすときのコマンド

スキルフォルダの中で、次のコマンドを直接使うこともできます。

本文の「Text 1」や数値の「00」といったプレースホルダーが残っていると、check_deck.py がFAILにします。社外に出す前は --forbid オプションで、顧客名や社内用語の消し忘れも検査できます。

4. PowerPoint（.pptx）にする

READMEの方針は「まずHTMLで仕上げ、PPTXにするのはユーザーから明示されたときだけ」です。html_to_pptx.py はChromeで描画した結果を読み取ってPowerPointの図形として組み直すので、文字・表・図形はPowerPointでそのまま編集できます。SVGのチャートや画像は画像として貼られ（中の数値は編集できない）、書体はYu Gothic / Yu Minchoに置き換わります。PPTXを渡したあとに修正が来たら、HTMLを直して変換し直す流れです。

社内の標準デッキや作りかけの提案書に数ページ足したいときは、変換したPPTXでは書体や表の作りが揃いません。その場合は scripts/measure_deck.py で元の資料の書式を測り、その資料のマスターの上に直接ページを組む方法が用意されています。

5. 最新版への更新と、自社ルールの足し方

規約と機械チェックは使った人の指摘で頻繁に直るため、READMEは週1回を目安に cd ~/.claude/skills/consulting-pptx-skill && git pull で最新を取り込むよう案内しています。自社の規約・禁止語・テンプレートは local/ フォルダに置きます。git の管理外なので更新しても消えず、local/slide-rules.local.md は本体の規約のあとに読まれて、重なる規則はこちらが優先されます。

業務でどう使える？どう変わる？

効くのは、提出先に読ませる資料を毎週作っている仕事です。一度規約を置いてしまえば、資料の種類が変わっても同じ基準が効きます。

職種別の活用アイデア

• 営業：提案書のたたき台づくり。「結論はタイトルに書く」を機械が守らせるので、読み手が中身を追わなくても筋が通る
• 経営企画・PM：定例の報告資料。ロードマップやガントの型があるので、毎回レイアウトから悩まなくて済む
• マーケティング：施策の振り返り資料。「推移・構成比・分布はグラフで描く。表に流し込んで済ませない」という規約が、数字を並べただけの資料を防ぐ
• 受託・コンサル：自社のレビュー指摘を slide-rules.md に足していけば、自社専用の資料作成ルールとして育つ。READMEも「いちばん効くのは追記」としている

ここが今までと違う

AIに資料を作らせる話は、これまで「どう指示するか」に寄っていました。このスキルは「作った後にどう検査するか」まで込みで設計されている点が違います。

そしてREADMEは、良いスライドを決めるのは型ではなく組んだ後の調整だと書いています。表を2枚に割る、右カラムを帰結の形に書き直す、タイトルだけを通して読んでストーリーを繋ぎ直す。型とパーツ集は「たたき台を早く出して、調整に時間を回す」ための道具だ、という位置づけです。

よくある質問

まとめ：プロンプトを磨くより、ルールを1か所に置く

この投稿が広がった理由は、AI資料の品質を「指示の巧さ」ではなく「規約と検査」の問題として組み直した点にあると見ています。毎回うまいプロンプトを書ける人は多くありませんが、指摘を1行ずつファイルに足していくことなら誰でもできます。

導入しない場合でも、自社のレビューで繰り返し出る指摘を10行だけテキストに書き出し、AIに資料を頼むたびに一緒に渡す。それだけで戻ってくるものは変わります。

今回の内容は、【公式】Jinba（@jinbaflow_JP）さんの投稿を参考にさせていただきました。自社で実際に運用している仕組みを、使い方まで添えて公開されているポストです。

「まず自分がAIを業務で使える側になりたい」という方には、デイトラのAI業務活用コースで、プロンプトの基本からMCP・AIエージェントまで体系的に学べます。