公式スキル · マーケティング
記事から SNS 投稿を作る
1本の記事から、LinkedIn の投稿、X のスレッド、短い投稿を作る。どれも記事のいちばん具体的なポイントをフックにする。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- 記事、ガイド、レポートを公開したばかりで広めたいとき
- 会社の記事について、自分の名前で投稿したいとき
AI に渡すもの
- 記事の本文か URL
- 投稿するのは誰か(会社か個人か)
- 読み手(任意)
できあがるもの
LinkedIn の投稿、X のスレッド、短い投稿と、試せるほかのフック2つ。
手順
- いちばん具体的なポイントを3つ探す 記事の主張を具体性で順位づけする。単位つきの数字、名前のある結果、直感に反する発見、損失のわかる失敗。「オンボーディングは大事」はポイントではない。「初日に設定を終えた顧客は、解約率が半分」はポイントだ。
- 最上位のポイントでフックを書く 1行目は30字以内(このスキルの既定値)で、ポイントか、その中にある意外さを言い切る。「その理由は…」、自分で答える問いかけ、「お知らせできることをうれしく思います」は使わない。記事に具体的なポイントがなければそう伝え、いちばんわかりやすい手順をフックにする。
- LinkedIn の投稿: 300〜550字(このスキルの既定値。LinkedIn の上限は3,000字) フック、空行、記事の例をひとつ使ってポイントを最後まで伝え、補足のポイントを短く2〜4行、最後にリンクと、記事にほかに何が書いてあるかを一行。1〜2文ごとに改行する。ユーザーが「リンクは最初のコメントに」と言わない限り、リンクは本文に入れる。
- X のスレッド: 4〜7件 1件目はフックで、それだけで成り立たせる。2件目からは1件にポイントひとつで、単独で読んでも意味が通るように書く。最後の投稿は、リンクと、記事で何がわかるかを一行。X の上限は通常のアカウントで1件280文字。リンクはどれも23文字、絵文字は2文字と数え、日本語などの全角文字も1字を2文字と数える(X の開発者向けドキュメント)。つまり全角だけなら1件140字。既定値(このスキルの判断)は、直す余地を残して270文字(全角で135字)未満。番号は、5件以上のスレッドのときだけつける。
- 短い投稿: 100字以内 ポイントひとつ、リンクひとつ。X、Threads、Bluesky、Slack での共有に使える。
- ハッシュタグとメンション 既定値(このスキルの判断)は0〜2個で、そのテーマで実際にフォローされているものだけ。X ではつけない。人や会社へのメンションは、記事に名前が出ていて、相手が喜ぶ場合だけ。
- すべての主張を記事と照らし合わせる 数字と引用は、記事に書かれているとおりでなければならない。丸めない。「かもしれない」を「そうなる」に強めない。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: social-post-from-article
description: 1本の記事やブログから、LinkedIn の投稿、X のスレッド、短い投稿を作る。どれも記事のいちばん具体的なポイント(数字、結果、意外な主張)をフックにして書き出し、ハッシュタグを並べない。記事、ブログ、レポートを渡されて、SNS 向けに再利用したい、「これを投稿にして」、LinkedIn の投稿やスレッドを書いてほしい、記事を広める SNS の文面がほしいと頼まれたときに使う。
---
# 記事から SNS 投稿を作る
再利用した投稿がうまくいくのは、リンクを押さない人にも記事のいちばんのポイントが伝わるときだ。だからフックには記事でいちばん具体的なことを置き、投稿の中でそれを最後まで伝える。リンクはおまけで、答えそのものではない。
## 使う場面
- ブログ記事、ガイド、レポート、導入事例を公開したばかりで、広めたいとき。
- 検索でまだ読まれている古い記事を、SNS でもう一度届けたいとき。
- 創業者や社員が、会社の記事について自分の名前で投稿したいとき。
- 記事のないリリースやニュースの告知には使わない。リリースの告知文を書く。
## 用意するもの
- 記事の本文か URL。本文がなければ頼む。タイトルだけでは、ありきたりな投稿になる。
- 投稿するのは誰か: 会社のアカウントか、特定の人か。個人の投稿は「私」、会社の投稿は「私たち」で語る。
- 任意: 読み手、筆者が残したい一文。なければ読み手は記事から判断する。
## 手順
1. **いちばん具体的なポイントを3つ探す。** 記事の主張を具体性で順位づけする。単位つきの数字、名前のある結果、直感に反する発見、損失のわかる失敗。「オンボーディングは大事」はポイントではない。「初日に設定を終えた顧客は、解約率が半分」はポイントだ。
2. **最上位のポイントでフックを書く。** 1行目は30字以内(このスキルの既定値)で、ポイントか、その中にある意外さを言い切る。「その理由は…」、自分で答える問いかけ、「お知らせできることをうれしく思います」は使わない。記事に具体的なポイントがなければそう伝え、いちばんわかりやすい手順をフックにする。
3. **LinkedIn の投稿: 300〜550字(このスキルの既定値。LinkedIn の上限は3,000字)。** フック、空行、記事の例をひとつ使ってポイントを最後まで伝え、補足のポイントを短く2〜4行、最後にリンクと、記事にほかに何が書いてあるかを一行。1〜2文ごとに改行する。ユーザーが「リンクは最初のコメントに」と言わない限り、リンクは本文に入れる。
4. **X のスレッド: 4〜7件。** 1件目はフックで、それだけで成り立たせる。2件目からは1件にポイントひとつで、単独で読んでも意味が通るように書く。最後の投稿は、リンクと、記事で何がわかるかを一行。X の上限は通常のアカウントで1件280文字。リンクはどれも23文字、絵文字は2文字と数え、日本語などの全角文字も1字を2文字と数える(X の開発者向けドキュメント)。つまり全角だけなら1件140字。既定値(このスキルの判断)は、直す余地を残して270文字(全角で135字)未満。番号は、5件以上のスレッドのときだけつける。
5. **短い投稿: 100字以内。** ポイントひとつ、リンクひとつ。X、Threads、Bluesky、Slack での共有に使える。
6. **ハッシュタグとメンション。** 既定値(このスキルの判断)は0〜2個で、そのテーマで実際にフォローされているものだけ。X ではつけない。人や会社へのメンションは、記事に名前が出ていて、相手が喜ぶ場合だけ。
7. **すべての主張を記事と照らし合わせる。** 数字と引用は、記事に書かれているとおりでなければならない。丸めない。「かもしれない」を「そうなる」に強めない。
## 出力の形式
```markdown
# 投稿: [記事のタイトル]
**フックにしたポイント:** [ポイント]
**投稿者:** [会社 / 名前]
## LinkedIn
[投稿]
## X のスレッド
1/ [投稿]
2/ [投稿]
## 短い投稿
[投稿]
## 試したいほかのフック
- [ポイント2からのフック]
- [ポイント3からのフック]
```
## 例
**入力:** 請求書アプリ「ハレ請求」のサポート責任者、岡田美咲さんの記事「400件の問い合わせからわかったこと」。岡田さんは400件を1件ずつ読んだ。主な発見: 問い合わせの38%がひとつの設定画面、請求書の設定画面から来ていた。迷いの原因は機能ではなく言葉で、「適用」はその請求書だけに保存、「保存」はすべての請求書に保存なのに、多くの人が逆だと思っていた。ボタン2つを「この請求書だけに保存」と「すべての請求書に保存」に変えたら、翌月、その画面からの問い合わせが60%減った。画面のほかの部分は何も変えていない。記事にはほかに、「不具合」の多くは言葉の問題だったこと、いちばん怒っていた問い合わせはエラーメッセージではなく何も表示されない失敗のあとに来ていたことが書かれ、最後にチームが分類に使ったシートがついている。投稿者: 岡田さん。
**出力:**
```markdown
# 投稿: 400件の問い合わせからわかったこと
**フックにしたポイント:** ボタン2つの名前を変えたら、翌月、ひとつの画面からの問い合わせが60%減った。
**投稿者:** 岡田美咲
## LinkedIn
ボタン2つを改名したら、ひとつの画面からの問い合わせが60%減りました。
サポートに届いた問い合わせ400件を、1件ずつ読みました。
38%が、たったひとつの画面から来ていました。請求書の設定画面です。
迷っていたのは機能ではなく、言葉でした。「適用」はその請求書だけに保存。「保存」はすべての請求書に保存。多くの人が逆だと思っていました。
ボタンを「この請求書だけに保存」と「すべての請求書に保存」に変えたところ、翌月、その画面からの問い合わせが60%減りました。
400件からわかったことは、ほかにも:
- 「不具合」の多くは、言葉の問題だった。
- いちばん怒っていた問い合わせは、エラーメッセージではなく、何も表示されない失敗のあとに来ていた。
分類に使ったシートも含めた全体はこちら: [リンク]
## X のスレッド
1/ ボタン2つを改名したら、ひとつの画面からの問い合わせが60%減りました。
2/ 問い合わせ400件を読みました。38%がひとつの画面から。請求書の設定画面です。
3/ 「適用」はその請求書だけに保存。「保存」はすべてに保存。多くの人が逆だと思っていました。
4/ 新しいラベルは「この請求書だけに保存」と「すべての請求書に保存」。翌月、その画面からの問い合わせは60%減りました。
5/ 400件からわかったことの残りと、分類に使ったシートはこちら: [リンク]
## 短い投稿
問い合わせの38%が、ひとつの画面から来ていました。ボタン2つの名前を変えたら60%減りました。[リンク]
## 試したいほかのフック
- 「不具合」の問い合わせの多くは、言葉の問題でした。
- いちばんの怒りは、何も表示されない失敗のあとでした。
```
## 送る前のチェック
- [ ] フックは記事でいちばん具体的なポイントで、30字以内。
- [ ] 数字と引用は、どれも記事に書かれているとおり。
- [ ] X の各投稿は単独で意味が通り、リンクを23文字、全角を2文字と数えて270文字未満。
- [ ] LinkedIn の投稿は300〜550字で、リンクを押さなくてもポイントが伝わる。
- [ ] ハッシュタグは全体で2個以内で、X にはつけていない。
## よくある失敗
- 記事を要約する(「新しい記事では〜について掘り下げます」)。代わりにポイントそのものを伝える。
- 3つの形式を、同じ文を長さだけ削って作る。形式ごとに組み立てを変える。
- クリックさせるために答えを伏せる。読み手は気づき、投稿を読まなくなる。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.1 · · Example: the input now carries every fact the posts use (the invoice settings page, the Apply/Save labels, the other findings, the tagging sheet), the hook is under 12 words, and the LinkedIn post is within 120 to 220 words.
- v1.0.0 · · First release.
出典
出典は英語のページです。
- Counting Characters (2026-11-04に確認)
- Post and share updates | LinkedIn Help (2026-11-04に確認)
- Inverted Pyramid: Writing for Comprehension (2026-11-04に確認)