Claude CodeでLinkedIn技術事例を作成

LinkedIn向けのClaude Code

エンジニアは他チームの技術事例から学びます。採用担当者や同僚もLinkedInでこうした記事を読みます。難しいのは文章を書くことではなく、何を公開してよいか判断し、主張を一つずつ証明することです。Claude Codeは変更を加えたプルリクエスト、ベンチマーク用スクリプト、当時の作業メモなど、実際の根拠にアクセスできます。このガイドでは決済インフラの事例を使い、技術的な事例記事を誠実に保つ確認方法を説明します。公開前に執筆者と法務担当者をレビューに参加させる流れも紹介します。読みやすさだけでなく、公開してよい情報かどうかを確認することが重要です。数値を掲載する場合は、環境、測定条件、出典を明らかにし、顧客を特定できる情報を残さないようにしてください。

例：フィンテックチームが照合作業を高速化

決済チームが夜間の照合作業を4時間から40分に短縮しました。技術リードはリポジトリでClaude Codeを開き、設計ドキュメント、変更リクエスト、ベンチマーク結果を指定します。同時に「顧客名、取引量、ホスト名は書かない」というルールを伝えます。Claudeは約250語の事例を作り、課題、比較した二つの案、決定、バッチ処理に関する一つの教訓をまとめます。「4時間から40分」という数値はベンチマークファイルで裏付けられていると示し、「エラーが99.9％減少」という主張には根拠がないと印を付けます。リードは後者を削除し、Claudeはcreate_draftsで会社ページ向けの下書きを保存します。法務担当者がTarenoで文章を確認してから、リードが水曜日の投稿枠を申請します。

手順

1. 01

   公開できる情報のルールを決める

   最初の下書きを作る前に、顧客名、取引量、内部ホスト名、未公開製品は含めないと明記します。Claude Codeはこのルールを文章作成時のフィルターとして使えます。何を除外したかも一覧にするよう依頼してください。

2. 02

   根拠となる資料を指定する

   設計ドキュメント、変更リクエスト、ベンチマーク結果を指定します。技術事例は実在するファイルに基づいて作り、公開する各主張を具体的なファイルや行までたどれるようにします。

3. 03

   課題、選択肢、決定、教訓を下書きする

   この順序で約250語にまとめるよう依頼します。採用しなかった案も、他のエンジニアにとって大切な情報です。都合のよい成功談だけにせず、検討した選択肢を下書きに残してください。

4. 04

   主張を一つずつ検証する

   下書きにある数値と因果関係の主張をすべて挙げ、根拠となるファイルと行を示すようClaude Codeに依頼します。出典がない記述は未検証とし、削除するか慎重な表現に直します。

5. 05

   レビュー用の下書きを保存する

   Claude Codeはlist_accountsでLinkedInアカウントを確認し、create_draftsで下書きを保存できます。投稿枠を申請する前に、レビュー担当者がTarenoで実際の文章を確認できる状態にしてください。

6. 06

   レビュー後に投稿枠を申請する

   技術面と法務面の確認が終わってから、日付、時刻、IANAタイムゾーンを指定します。Tarenoは保留中の操作を作成し、担当者がダッシュボードで承認するまで待機します。

コピーして使えるプロンプト

docs/design/reconciliation.md、変更リクエスト[番号]、scripts/bench.shの出力を読んでください。これらのファイルで裏付けられる数値と、裏付けられない主張を分けて列挙してください。公開ルールとして顧客名、取引量、ホスト名は含めないでください。まだTarenoには何も保存しないでください。

LinkedIn向けに約250語の技術事例を書いてください。構成は課題、検討した二つの選択肢、決定、一つの教訓の四部です。根拠がある数値だけを使い、[エンジニアリングマネージャー]向けに書いてください。マーケティング調の表現は避け、最初はレビュー用の文章だけを提示してください。

下書きにある数値と因果関係の主張をすべて列挙し、根拠となるファイルと行を添えてください。出典がないものは未検証とし、それぞれ慎重な言い換えを提案してください。レビューが終わるまでTarenoには保存しないでください。

Tarenoを使ってLinkedInの会社ページ[名前]を確認し、承認済みの文章をそのページの下書きとして保存してください。下書きIDと保存された文章を返してください。法務レビューが完了したと私が伝えるまで、投稿時間を申請しないでください。

避けるべき間違い

• ステージング環境のベンチマーク数値を公開すること。測定した環境を明記するか、公開できる説明を添えられない場合は数値を省いてください。
• 成功だけを並べた事例にすること。採用しなかった案や選択した方法のコストも書くと、他のエンジニアから信頼されやすくなります。
• 図に内部サービス名を残すこと。画像をアップロードする前に、ホスト名や未公開のコードネームが見えていないか確認してください。
• 珍しい取引量や地域情報など、文脈だけで顧客を特定できるのに法務や顧客のレビューを省くこと。