Skeleton-of-Thoughtとは？骨子先行で長文を守るプロンプト設計

この記事の監修者

リスキルAIキャリア編集部

リスキルAIキャリアは、AI時代の学び直し・キャリア形成・副業・転職に役立つ情報を発信するWebメディアです。編集部では、生成AIスキルの身につけ方、AI関連スクール・講座の選び方、キャリアアップにつながる学習方法などを、実務目線でわかりやすくお届けしています。

Skeleton-of-Thought（SoT）は「まず骨子を作り、各項目を展開する」プロンプト設計です。論文が示す最大2.39倍の高速化は並列API前提で、ChatGPTのチャット画面を使う個人にはほぼ効きません。個人が得る実利は速度でなく、長文の抜け漏れと構成破綻を防ぐことです。

この記事でわかることを先に示します。SoTでできること、できないこと、PEP検定との関係の3点です。

• できること：職務経歴書、提案書、記事構成、FAQなど、章で分けられる長文の骨子設計
• できないこと：計算、コード実装、原因分析など、前後関係が強いタスク
• PEP検定との関係：プロンプト設計とAI活用リテラシーの土台になる

生成AIを副業・転職で使うなら、SoTはAIに丸投げする技術でなく、出力を設計・検証する技術です。PEP検定で問われるプロンプト設計やAI活用の基礎にも直結します。

Skeleton-of-Thoughtとは？骨子を先に作る仕組み

Skeleton-of-Thoughtは、回答を一気に書かせず「骨子→展開」の2段階に分ける手法です。人間がアウトラインを組んでから書く発想をLLMに移植しています。最初に見出しレベルの骨子だけを出させ、各項目を個別に肉付けするのが核心です。

SoTの2ステップと実行テンプレ

SoTは2工程で動きます。第1にスケルトン（骨子）を3〜10項目の短い箇条書きで生成します。第2に各項目を並列に、または順番に展開して本文化します。骨子は各項目3〜5語に制限すると、展開時の重複や矛盾が減ります。

チャット画面でそのまま使える2種類のテンプレを示します。まず2段階版です。骨子生成と本文展開を分けて送ります。

あなたは{役割}です。
以下のテーマについて、先に骨子だけを作ってください。

条件：
- 骨子は5〜7項目
- 各項目は10字以内
- まだ本文は書かない
- 重複する項目は作らない
- 最後に「この骨子で展開してよいか」と確認する

テーマ：
{作りたい文書の内容}

骨子を承認したら、展開用プロンプトを送ります。

承認した骨子に沿って、本文を作成してください。

条件：
- 各章は{文字数}字以内
- 各章の冒頭で主張を1文で書く
- 数値・固有名詞・日付は、根拠がない場合は「要確認」と書く
- 骨子にない話題を追加しない

1回で済ませたいときは、1プロンプト完結版を使います。骨子・本文・対応表を一度に出させます。

以下のテーマについて、Skeleton-of-Thoughtで回答してください。

手順：
1. 先に5項目の骨子を出す
2. 各骨子を順番に本文化する
3. 最後に、骨子と本文の対応表を出す

制約：
- 骨子は各10字以内
- 本文は各150字以内
- 根拠不明の数値は断定しない

テーマ：
{テーマ}

骨子は「章立て」であって「要約」ではないと割り切ると精度が安定します。

論文の一次情報（Ning et al. 2023）

SoTの一次情報は次のとおりです。数値の主張は論文本文に基づきます。

• 論文：Skeleton-of-Thought: Large Language Models Can Do Parallel Decoding
• 著者：Xuefei Ning ほか
• arXiv ID：2307.15337
• 公開：2023年
• 採択：ICLR 2024 poster
• 確認先：arXiv / OpenReview

論文では、複数モデルでSoTを検証し、レイテンシを最大2.39倍改善したと報告しています。また、12モデル中8モデルで2倍超の高速化を確認したとしています。品質面では、LLMZoo評価の約60%の質問で従来と同等以上とされています。

前提と限界も論文が明記しています。高速化は各骨子を並列にデコード、またはAPI実行できる環境が条件です。品質評価はGPT-4を審査役にしたもので、大規模な人手評価が中心ではありません。項目間に依存があるタスクでは品質が下がり、トークン増でコストが増える点も論文が認めています。

個人利用でSkeleton-of-Thoughtの速度が効かない理由

個人がChatGPTやClaudeのチャット画面で使う限り、SoTの高速化はほぼ体感できません。高速化は複数の展開を同時実行できることが前提で、チャット1画面は1回に1応答しか返さないからです。

並列APIとチャット1画面の環境差

5項目の骨子を展開する場合、チャット画面では往復が積み上がります。

• 骨子生成：1回
• 第1章展開：1回
• 第2章展開：1回
• 第3章展開：1回
• 第4章展開：1回
• 第5章展開：1回

合計6往復です。一方、APIなら第1〜5章の展開を同時に投げられます。待ち時間は「5章分の合計」でなく「最も遅い1章」に近づきます。これがSoT論文でいう高速化の正体です。

skeleton = generate("骨子を5項目で出す")
results = parallel_generate([
    f"{item}を300字で展開" for item in skeleton
])
article = merge(results)

この疑似コードは概念説明で、動作保証したものではありません。並列実行にはAPI料金と実装知識が必要です。速度目的でSoTを選ぶなら、APIとコードで並列を組む環境が前提になります。APIやプロンプト設計の基礎はPEP検定の勉強法で公式シラバスから逆算して整理できます。

速度ではなく「破綻を防ぐ構成術」としてのSkeleton-of-Thought

個人がSoTから得る価値は、長文の構成を先に固めることです。骨子を人間が確認してから展開させると、話が逸れる・章が抜ける・冒頭と結論がズレる、といった破綻を防げます。

一気に3000字を書かせると、AIは前半の論点を後半で忘れがちです。骨子を先に固定すると、各章が同じ設計図を参照し、一貫性が保てます。修正も骨子レベルで行えば、全文を書き直さずに済みます。

効き方は3点です。第1に見出しの抜け漏れが減ります。第2に章ごとの分量を指定でき、偏りを防げます。第3に骨子段階で承認でき、手戻りが減ります。SoTは速くする道具でなく、長文を破綻させない道具です。

使う/使わないの判断表と分解系プロンプトの使い分け

SoTは、章同士が独立している文書にだけ使います。判断軸は「項目どうしが独立しているか」の一点です。前の結果が次に影響する逐次依存タスクには使いません。

自分の作業に当てはめる判断表

自分のタスクを次の質問に当てはめると、向き不向きが判定できます。

プログラミングは一括で不向きとはしません。設計書・README・仕様説明はSoT向きです。アルゴリズム実装・デバッグ・エラー原因特定はSoT不向きです。「文章を分けて書けるか」と「前後の依存があるか」で分けると誤解を避けられます。

他の分解系プロンプトとの比較

計算や多段推論には思考の連鎖プロンプト（CoT）を使います。計画と実行を分けたいならPlan-and-Solveプロンプト、業務を工程で割るならプロンプトチェーンが適します。

キャリア文脈で使えるSkeleton-of-Thoughtのコピペテンプレ

ここからは実用テンプレです。骨子プロンプトと展開プロンプトを分けて使います。骨子を承認してから展開すると、本文を書いた後の大幅修正を減らせます。

職務経歴書の骨子＋展開テンプレ

まず骨子プロンプトを送ります。指定は次のとおりです。

あなたは転職エージェントです。
以下の経歴から、職務経歴書の骨子を見出しのみ7項目で出してください。

条件：
- 各項目は10字以内
- 重複する見出しは作らない
- まだ本文は書かない

経歴：
{職務経歴}

出た骨子を人間が並べ替え・削除します。次に展開プロンプトで1項目ずつ本文化します。「承認した骨子の〈自己PR〉を、実績を数値で示しつつ200字で本文化してください。誇張は禁止」と依頼します。数値と固有名詞を必ず入れさせると、抽象的な自己PRを避けられます。

提案書・副業ライティングの展開手順

提案書は「課題→原因→解決策→効果→費用」の骨子を先に固定します。骨子で5見出しを出させ、順序を人間が決めます。展開時は各章の文字数を指定し、費用の章の数字は人間が入れます。

副業ライティングでは、記事の骨子をH2・H3レベルで先に確定します。各見出しに検索意図を一言添えて展開させると、話が逸れません。骨子段階でクライアント確認を取れば、全文納品後の大幅修正を避けられます。

SoTを「使えるスキル」にするなら、プロンプト設計の基礎も押さえる

SoTは便利ですが、単体では長文を分けて書かせる小技です。実務で評価されるのは、目的を定義し、制約条件を置き、出力を検証し、事実確認までできることです。

生成AIを副業・転職で武器にするなら、プロンプトの型だけでなく、AI利用のリスク、情報の扱い、業務適用の判断基準も押さえる必要があります。PEP検定は、その基礎を確認する入口になります。受検前に次の3点を確認しておくと、学習の抜けを防げます。

• 公式シラバスで、プロンプト設計・生成AIリスク・業務活用の範囲を確認する
• 苦手分野を1つ選び、関連用語を10個説明できる状態にする
• SoT・CoT・プロンプトチェーンの違いを、自分の業務例で説明できるようにする

出題範囲と勉強順は、公式シラバスをもとに整理したPEP検定の勉強法で確認できます。

Skeleton-of-Thoughtの自己検証手順とチェックリスト

SoTを使うなら、出力を鵜呑みにしない検証が必要です。論文のSoT-R（自動判定）を、個人は手動チェックに置き換えます。骨子・展開・全体の3段階でチェックすると、破綻を早期に潰せます。

1. 適否判定：章が独立か、計算が不要かを確認する。依存があればCoTへ切り替える
2. 骨子検証：見出しの重複・抜け・順序を人間が直す。ここで直すのが最も安い
3. 展開検証：各章が骨子の主旨から外れていないか、1章ずつ照合する
4. 全体検証：冒頭の結論と各章の主張が一致しているか通読する
5. 事実確認：数値・固有名詞・日付は一次情報で裏取りする

出力後は、次のチェックリストで機械的に確認します。所要は5〜10分が目安です。

• 骨子に同じ意味の見出しが2つないか
• 各見出しが10字前後に収まっているか
• 本文に骨子と関係ない話が混ざっていないか
• 数値・価格・日付・制度名に根拠があるか
• 冒頭の結論と最後の結論がズレていないか
• 各章の分量が極端に偏っていないか

よくある失敗は、骨子の見出しが同じ話に寄るケースです。次のNG例と修正版で違いを確認してください。

NG骨子：
- AI活用の重要性
- AIを使うメリット
- AIで効率化する方法
- AI時代に必要なこと

問題：
すべて同じ話に寄り、展開すると内容が重複します。

修正版：
- 現状課題
- 導入目的
- 活用業務
- 運用ルール
- 効果測定

AIが出した数値は必ず自分で確認し、根拠のない断定は削ってください。

よくある質問

SoTを使うとChatGPTは本当に速くなりますか？

チャット1画面では速くなりません。骨子と展開で往復が増え、総時間は延びます。高速化は並列APIやバッチ推論を組んだ場合の効果です。個人利用の価値は速度でなく、長文の構成破綻を防ぐことにあります。

SoTとCoTはどちらを使えばいいですか？

章が独立した文章ならSoT、計算や多段推論ならCoTです。判断軸は「前の結果が次に影響するか」です。依存があるタスクにSoTを使うと品質が下がると論文も指摘しています。本記事の判断表を参照してください。

スケルトンオブソートの骨子は何項目が適切ですか？

3〜10項目が目安です。論文の実装も短い箇条書きを想定しています。各項目は10字前後に抑え、要約でなく章立てとして書かせます。項目が多すぎると展開時に重複と矛盾が増えます。

SoTの品質評価は信頼できますか？

前提を理解して使えば有用です。論文の品質評価はGPT-4を審査役にしたもので、大規模な人手評価が中心ではありません。数値は参考値と捉え、最終判断は自分の目視検証で行ってください。

Skeleton-of-ThoughtはPEP検定の対策になりますか？

SoTだけでPEP検定対策が完結するわけではありません。ただし、プロンプト設計の考え方を理解する題材にはなります。骨子を作る、制約条件を置く、出力を検証する流れは、生成AIを業務で使う基礎です。検定対策では、生成AIの仕組み・リスク・プロンプト設計・業務活用の範囲を公式シラバスで確認してください。

副業ライターや資料作成でSoTを使うときの注意点は？

骨子をAIに作らせても、検索意図・事実確認・一次情報の確認は人間が担当します。価格・日付・制度・資格情報はAIの出力をそのまま使わないでください。副業案件では、骨子段階でクライアント確認を取り、本文生成後に根拠不明の数値を削る運用が安全です。

次にやること

Skeleton-of-Thoughtを理解したら、次のどれかに進んでください。

1. 職務経歴書を作る人：本記事のテンプレで、まず7項目の骨子だけを作る
2. 副業・資料作成に使う人：提案書テンプレで「課題→原因→解決策→効果→費用」の5項目を作る
3. 生成AIスキルを体系的に確認したい人：PEP検定の公式シラバスで、プロンプト設計・AIリスク・業務活用の範囲を押さえる

SoT・CoT・プロンプトチェーンを使い分けられるか不安な人は、PEP検定の勉強法で出題範囲から逆算し、学習順を確認してから受検を判断してください。