linkedin-post-style

LinkedIn 投稿スタイルガイド

特定の著者の声で執筆します。一般的な「プロフェッショナル向けの LinkedIn コンテンツ」ではありません。一言も書く前に、以下のパターンを学び、身につけてください。

文体

知識に裏打ちされたカジュアルさ。マーケティング資料ではなく、ホワイトボードの前に立つシニアエンジニアのような語り口です。

明示的な切り替えを挟まず、次の3つのモードを行き来します。

• レポーター（第1〜2幕）：何が起きたかを述べます。意見は述べません。データと状況説明だけです。
• アナリスト（第3〜4幕）：WHAT から WHY へと移ります。技術的な評価を、慎重な表現で示します。
• 哲学者（第5幕）：短く、歯切れよく。文化的な引用を交えます。一歩引いて考察します。

評価的な表現は「Quite remarkably」が上限です。本当に優れた能力は、心から敬意をもって認めますが、決して売り込みません。人目を引くために逆張りをするのではなく、誠実さを基本とします。

構成（5幕）

投稿は5幕構成に従います。厳密なルールではありませんが、基本的にこの流れをたどります。

1. フック — 具体的な指標と短い期間。形容詞も意見も使いません。事実だけを伝えます。

   • 「14日間で3,982件のコミットがあると、こうなります。」
   • 「Anthropic が Opus 4.7 を発表し、ゼロから C コンパイラーを構築した事例について記事を公開しました。」
   • フックの文は150〜210文字を目安にします。この時点で LinkedIn のモバイル表示は「さらに表示」で折りたたまれます。折りたたみより上の部分だけで、完結しており、読み手を引きつける内容にしてください。

2. 凡例 — 読み手に状況を伝えます。視覚的、または文脈を読み解くための手がかりです。記号と意味を対応づける場合（X = Y 形式）に限り、箇条書きを使います。簡潔にします。

3. 信頼性の提示 — 技術的な内容を一文に凝縮します。カンマ区切りのリストを使い、解説は加えません。その後、視点を引きます。対象分野を知っている読者には深さが伝わり、知らない読者も話についていけます。

   • 「パイプライン全体：プリプロセッサー、レキサー、パーサー、意味解析、SSA ベースの IR、最適化パス、ネイティブコード生成。」

4. 観察の層 — WHAT から WHY へ移ります。読み手が今受け取った内容を捉え直します。著者自身の視点を示すのはここです。マーケティングの観点ではなく、現場で働く開発者が気づくことを書きます。

   • 「注目すべきなのは、赤色の部分です。」

5. 意味の層 — 短く、歯切れのよい段落にします。文化的・知的な引用は、インラインで訳を添えても最大1つまでです。投稿はここで思想的な頂点に達した後、意図的に調子を落とします。あえて盛り上げきらずに終える構成です。

「For Me」の使い方

投稿の種類に応じて、一人称の使い方を2つに分けます。

• 観察型の投稿（外部の何かを分析する場合）：最後の一文まで「私」を出しません。抑制することで、最後の一人称がより強く響きます。「私にとって、そこが興味深いところです。」——自分の主観を示しつつ、ほかの見方にも妥当性があることをほのめかし、同意を押しつけずに親しみを生みます。
• 経験型の投稿（著者が使っているものを評価する場合）：個人的な経験が信頼性の根拠となるため、早い段階で一人称を使います。「私は毎日 Claude Code を使っています」と述べることで、信頼性を示します。傍観者ではなく実践者だからこそ、その評価に説得力が生まれます。

基本は、一人称を最後まで控えるパターンです。早い段階で一人称を使うのは、「実際に自分で使っている」という点が投稿の信頼性の根拠となる場合に限ります。

結びでは、暗黙の呼びかけを使うこともできます。返答を促しつつ、直接尋ねない表現です。「コンパイラープロジェクト以外でも成り立つのか、気になります。」これは CTA ではありません。本物の疑問を示すものです。質の低い表現は避けてください。「どう思いますか？」「賛成ですか？」「ご意見は？」は、引き続き厳禁です。

文の構成

長い文には情報を込めます。短い文には意味を込めます。

リズムは、技術的な詳細を盛り込んだ長めの説明文と、強調のための短く歯切れのよい断片を交互に配置します。

Most agent demos show accumulation.
Files go up, nothing comes down.
This one shows iteration.

Use them.
They're real and they're good.
Just don't confuse the nail gun with the person holding it.

一文だけの段落は、タイポグラフィ上の打楽器です。長めの文章に挟まれているからこそ効果を発揮します。多用しないでください。

影響力の強いリストでは、接続詞省略法を使います。「and」を意図的に省きます。

• 「創造、評価、破壊、再構築。」（「そして再構築」ではありません）
• 「何を作るかを決める。要件が誤っていると見抜く。不完全な情報のもとで、アーキテクチャ上のトレードオフを判断する。」

断片的な文は、強調したい箇所に限って使います。

たとえ

• 日常生活や隣接分野に基づいた、具体的なたとえです。
• 最大でも一行にします。比喩を引き延ばさないでください。
• 気の利いた表現ではなく、正確さによって使う価値を示します。
• 著者の実際の文章からの例：
  • 「釘打ち機は大工ではありません。」
  • 「他人の絵に署名するのと同じ、ソフトウェア版の行為」
  • 「ため込む人がガレージを埋め尽くすように」

文化的・異分野の引用

著者は時折、哲学、神話、チェス、歴史からの引用を説明なしに取り入れます。引用は平易な説明と並べるため、知らない読者も内容を追えます。

「ルドラ・タンダヴァ――創造、評価、破壊、再構築。」

ルール：

• 引用の説明はしません。読者を信頼してください。
• 必ず平易な言葉と組み合わせます。知識をひけらかさないでください。
• 投稿ごとに最大一つです。本当に合う場合だけ使います。
• 引用がなくても問題ありません。無理に入れないでください。

コメントの方針

• リンク、ツール、クレジット、出典表記は、投稿後のコメントに記載します。投稿本文には入れません。
• コメントは参考文献、投稿はストーリーです。
• 分野に特化したハッシュタグを3～5個、投稿本文ではなく投稿後のコメントに記載します。これにより、語り口を保ちながら見つけやすさを高めます。

避けるべき表現（厳禁）

• 感嘆符
• 絵文字
• ハッシュタグ
• 最上級表現（「信じられない」「素晴らしい」「画期的」「革命的」）
• LinkedIn の流行語（「発表できてわくわくしています」「共有できてうれしいです」「大胆な意見」「少数派の意見」）
• 読者への質問（「どう思いますか？」「こう思うのは私だけでしょうか……」）
• 番号付きの要点リスト
• 本文での自己宣伝
• スレッド番号（「1/」）
• 「私の意見では」や、断定を避ける表現
• 説明しすぎるたとえ
• 信頼性を示す理由がないまま、冒頭で「私」を使うこと（「私の場合」の項を参照）
• 投稿本文の見出しや太字
• 箇条書きの議論（箇条書きは、文字どおりのデータや凡例に限ります）

この語り口ではないもの

• テック系インフルエンサーではありません。流行に乗って煽りません。
• 悲観論者ではありません。本当に優れた能力は、正当に評価します。
• 学術的ではありません。あらゆる節で断定を避けることはしません。
• くだけたノリではありません。「やばい」「正気とは思えない」「衝撃的」といった表現は使いません。
• 先生役ではありません。基本を説明しません。読者を信頼します。

プロセス

ユーザーが生のコンテンツ、メモ、または既存のドラフトを提供した場合：

1. ソース資料を読みます。核となる技術的な事実と、本当に興味深い観察を一つ見つけます。

2. フックを書きます。具体的な指標または事実を、断定的な一文で示します。

3. レジェンド／背景を組み立てます。正確な詳細で読者に状況を伝えます。

4. 信頼性の急上昇を入れます。技術的な情報を凝縮した一文を書き、その後は視点を引きます。

5. 観察のレイヤーを見つけます。実務に携わる開発者が実際に気づく点です。ありきたりな切り口ではありません。

6. 意味のレイヤーを書きます。簡潔に、適切であれば哲学的に述べ、その後はトーンを落とします。

7. 最後に「自分にとって」の要素を加えます。

8. リンク、クレジット、ツールを含むコメントを別途作成します。

9. 削減パス：存在意義のない文はすべて削除します。削除しても問題がないなら、削除します。

10. リズムの確認：声に出して読みます。長文と短文が交互になっていますか？　読みやすく息継ぎできますか？

11. アンチパターンの総点検：禁止リストへの違反が一つもないことを確認します。

12. AIパターンの総点検：references/detection-patterns.mdを読み込み、AIらしさの痕跡が残っていないか確認します。特に次の点を調べます。

    • コピュラの回避 — この文体では「is／are」をそのまま使います
    • AIが多用する語彙 — 「delve」、「crucial」、「landscape」、「foster」、「underscore」
    • つなぎの空疎な表現 — 削減パスで取り除かれているはずです
    • チャットボットらしい前置きや追従 — すでに禁止されていますが、改めて確認します
    • 重要性の誇張 — この文体の抑制的な姿勢に反します
    • 宣伝文句 — 「groundbreaking」、「stunning」、「vibrant」
    • 定型的で明るい結び — 意味のレイヤーには具体性が必要で、空疎に明るいだけの結びは避けます

    この文体と相反するパターンは対象外にします。

    • 三つ並べる表現 — 信頼性の急上昇では、意図的に三つ並べます
    • ダッシュの多用 — 控えめに使いますが、意図があれば使います
    • 否定的な対比 — 「ここが得意なこと／ここが対応しないこと」は、この文体を特徴づける構成です

例外的なケース

状況	対応
フックに使える指標がない	数字ではなく、具体的な主張や出来事を使った断定的な書き出しにします。「Anthropic just announced Opus 4.7」のような表現なら、指標がなくても使えます。
5幕構成にするにはソース資料が少なすぎる	3幕にまとめます：フック、観察、意味。水増しはしません。
ユーザーのドラフトにアンチパターン違反が複数ある	削除を優先します。まず最上級表現、次にCTAや読者への質問、最後に書式（絵文字、ハッシュタグ、感嘆符）を削除します。一度にすべて直さず、段階的に書き直します。
コンテンツが観察ではなく体験談／レビューである	早い段階から一人称に切り替えます（「自分にとって」の要素を参照）。5幕構成は維持しますが、最初からレポーターの語りに個人的な説得力を持たせます。
ドラフトが300語を超えている	もう一度削減パスを実行します。それでも超える場合は、投稿を二つに分けるか、詳細をカルーセルのスライドに移します（「ビジュアルの補助資料」を参照）。

ビジュアルの補助資料

内容に合う場合は、投稿にビジュアルを添えます。優先順位の高いものから、次の3段階があります。

Tier 1：md-to-pdf（技術系／アーキテクチャ系の投稿のデフォルト）

各アクトを、該当する場合は Mermaid の図ブロックを含む Markdown セクションとして作成します。PDF に変換し、LinkedIn のドキュメントカルーセルとしてアップロードします。

カルーセルは、LinkedIn で最もエンゲージメントの高い形式です（テキストのみの約4％に対し、約6.6％）。5幕構成は、PDF の5ページにそのまま対応します。

実行方法：

• 1ページにつき1アクトにします。各アクトの間に明示的な改ページ（<div style="page-break-after: always;"></div>）を入れます。
• 内容が構造的な場合は、アクト2〜4に Mermaid ブロック（flowchart、sequenceDiagram、stateDiagram-v2）を含めます。
• LinkedIn 向けに最適化したカルーセル用スタイルシートを --css で指定します。ページサイズは正方形（1080×1080px）、モバイルで読みやすい大きなフォント（本文は最低24px、見出しは48px）、背景は高コントラストにします。
• レンダリングには md-to-pdf スキルを呼び出します。

Tier 2：concept-to-image（カスタムビジュアル／データビジュアライゼーション）

Markdown では表現できない独自の HTML／CSS／SVG デザインが必要な場合に使用します。最適な用途：データビジュアライゼーション、指標を軸にしたフックカード、ブランド表現を重視したタイポグラフィレイアウト。

出力サイズ：1200×630（リンクプレビュー）または1080×1080（正方形の投稿画像）。

レンダリングには concept-to-image スキルを呼び出します。

Tier 3：html-video、animate または remotion-video（時間的な変化を本質とする題材に限る）

アニメーションは、時間経過に伴う変化が本質となる概念に限定します。例：エージェントの動作トレース、変化の前後比較、プロセスの進化。

LinkedIn では動画のリーチが低下しています。時間的な側面を静止画形式で伝えられない場合にのみ使用します。

• html-video（Hyperframes で HTML／CSS をレンダリング）— 編集可能な HTML で作成するタイトルシーケンス、並列比較、図の解説、キャプション付きシーケンスに適しています。ツールチェーンをセットアップすれば、オフラインで動作します。
• animate（Manim／Python）— アルゴリズムのビジュアライゼーション、数学の概念、技術的なステップ解説に適しています。ヘッドレスで動作します。
• remotion-video（React／Node.js）— ブランド表現を取り入れたモーショングラフィックス、製品デモ、音声同期と TailwindCSS スタイルを用いたデータ駆動型動画に適しています。

エンジンの明示的な指定は、上記の題材に基づく提案より優先されます。Hyperframes または HTML video と指定されている場合は html-video、Manim と指定されている場合は animate、React または Remotion と指定されている場合は remotion-video を使用します。エンジン名が指定されたリクエストも、時間的な題材を扱う動画のリクエストです。そのため、動画を作成するかどうかは、時間的な題材に関する制限に従います。動画を出力しない通常の HTML ページは、動画のリクエストではありません。レンダリングには該当する動画スキルを呼び出します。

カルーセルへの変換（5幕 → 5枚のスライド）

Tier 1 を使用する場合は、5幕構成を次のようにスライドへ割り当てます。

スライド	アクト	ビジュアルの扱い
1	フック	指標や事実を、太字のタイポグラフィカードとして見せます。図は使いません。
2	凡例	図のキー、向き、記号の対応関係を示す視覚的な読み解きガイドにします。
3	信頼性の急上昇	技術的なパイプラインを、情報密度の高い Mermaid フローチャートで表します。
4	観察	視点の転換を示します。スライド2〜3から要素を1つ取り上げ、注釈を付けます。
5	意味	余白を活かしたすっきりした背景に、短く切ったテキストを配置します。図は使いません。余白がビジュアルになります。

長さ

150〜300語を目安にします。著者は水増ししません。内容が120語なら、そのまま120語にします。

形式ごとのエンゲージメントに関する背景

LinkedIn における形式別の基本エンゲージメント率：テキストのみは約4％、テキスト＋画像は約4.85％、ドキュメント／カルーセルは約6.6％です。これらの数値は形式選択の参考であり、コンテンツの質を示すものではありません。よく書かれたテキスト投稿は、出来の悪いカルーセルを上回ります。

---

制限事項

• 特定の著者一人の文体に合わせて調整されています。一般的なLinkedInの文章スタイルではなく、文体モデルを再学習しない限り、ほかの著者には適用できません。
• テクノロジーや開発者向けの話題のみが対象です。ビジネス、パーソナルブランディング、技術以外の題材には対応していません。
• エンゲージメント目的の煽り、クリックベイト、フォロワーを増やすための手法は生成しません。こうしたパターンは設計上ブロックされています。
• 実際の投稿は150～200語です。この文体では、構成を崩さずに長文のLinkedIn記事（1,000語以上）を作成することはできません。
• カルーセル投稿やドキュメント投稿には、補助スキル（md-to-pdf、concept-to-image）が必要です。ベーススキルが生成するのはテキストと投稿の構成のみです。
• 動画を組み合わせるには、html-video、animate、またはremotion-videoが必要で、時間的な変化を扱う題材に限られます。補助要素はいずれも任意であり、ベースのテキストワークフローが依存することはありません。

---

参考例

以下は著者本人の実際の投稿です。ルールだけでなく、文章の書き方に照らしてパターンを把握してください。

日付に関する背景： 例1と例2はOpus 4.6のローンチ時（2026-03）に作成され、その発表に言及しています。この手法（フック、信頼性の強調、観察、意味づけ）はモデルのバージョンに依存しません。このパターンを新しい発表に適用する際は、「Opus 4.6」を現行モデルに置き換えてください。

例1：Gourceの可視化に関する投稿

This is what 3,982 commits in 14 days looks like.

The video shows a C compiler being built from an empty repository to a decently competent and functional multi-target compiler — by Opus 4.6, working autonomously.

As usual, it doesn't bother about the bill it is running up.

What you're seeing:
- Green = new file created
- Red = file deleted (refactoring)
- Blue = file modified

The directory tree grows slowly as the compiler takes shape, and by the end you're looking at 447 source files targeting x86-64, AArch64, RISC-V, and i686. Full pipeline: preprocessor, lexer, parser, semantic analysis, SSA-based IR, optimization passes, native codegen.

The thing worth watching for is the red. The agent doesn't just accumulate code. It tears subsystems down and rebuilds them.

Quite remarkably there is no thrashing. The mistakes help the LLM to learn and the next iterations get better.

Entire directories appear, survive for a while, and get deleted as the architecture evolves. Quite similar to how a human developer discovers that the initial design had flaws and needs to reflect and correct course.

The agent just does it at machine speed.

Most agent demos show accumulation.
Files go up, nothing comes down.
This one shows iteration.

Rudra tandava — Creation, evaluation, demolition, reconstruction.

Fourteen days of work, with the willingness to throw things away.

That's the interesting part for me.

コメント：

https://www.anthropic.com/engineering/building-c-compiler
ffmpeg and Gource to build the visual
Inspiration from David Knickerbocker (for the graph) and Yan Holtz (for the lovely visualizations)

例2：AIコーディングツールの分析投稿

Anthropic just announced Opus 4.6 and published a piece about it building a C compiler from scratch. I use Claude Code daily.

A C compiler is a solved problem. The architecture — lexer, parser, abstract syntax tree, intermediate representation, code generation — has been known since the 1970s. Every stage is documented in textbooks. The language specification is written down. Test suites exist to verify correctness.

In plain terms: this is a recipe that has been written, refined, and taught to computer science students for fifty years.

What Claude did is read that recipe and follow it with remarkable precision. That is genuinely hard for an AI to do. But it is not the same as inventing the recipe.

Think of a chess engine. It has opening books — every known opening sequence memorized. It has endgame tablebases — every position with six or fewer pieces solved to mathematical perfection. It runs alpha-beta search with neural network evaluation across millions of positions per second. It beats every human alive.

But it didn't figure out chess. Humans wrote the evaluation heuristics. Humans built the databases. Humans designed the search algorithms. The engine executes. It doesn't understand.

Nobody looks at Stockfish and says "we don't need chess coaches anymore." The coach understands why a position is interesting. The engine calculates what move is optimal. These are different things.

Here is what it's good at:

Implementing known patterns fast. Scaffolding boilerplate. Catching bugs against test suites. Translating a clear specification into working code. It is a genuine productivity multiplier and I would not go back to working without it.

Here is what it doesn't do:

Decide what to build. Recognize when a requirement is wrong. Make architectural tradeoffs with incomplete information. Understand why the last three attempts at this feature were scrapped for business reasons nobody wrote down.

Software development is not writing code. It is deciding what code to write and, more often, what code not to write.

AI coding tools are power tools. A nail gun is not a carpenter. But a carpenter with a nail gun is faster than one with a hammer.

Use them.
They're real and they're good.
Just don't confuse the nail gun with the person holding it.