Claudeのinternal-commsスキルで3P更新・社内報・FAQを書く

週次の進捗報告、全社向けのニュースレター、社内でよく出る質問への回答。どれも毎回ゼロから書くと、体裁が書き手ごとに揺れます。internal-commsは、この3種類と汎用の社内文書について書式と集め方を決めておくスキルです。Anthropicが公開しているスキル集(anthropics/skills)に入っていて、Claude Codeでもclaude.aiでも使えます。

internal-commsスキルは何を持っているか

internal-commsは、社内向け文書を書く依頼が来たときに、種類を見分けて対応する書式ファイルを読み込むスキルです。中身はSKILL.mdとexamples/配下の4ファイルだけで、スクリプトや外部APIの呼び出しはありません。

SKILL.mdのdescriptionには、対象としてステータスレポート、リーダー向け更新、3P更新、社内ニュースレター、FAQ、インシデントレポート、プロジェクト更新が挙がっています。ただし専用の書式があるのは次の3種類で、残りは汎用ファイルが受けます。

3つの専用ファイルに共通するのは、情報を探しに行く順番です。Slackは反応やスレッド返信の多い投稿、メールは返信の多いやりとり、Google Driveは閲覧の多い文書、カレンダーは参加者の多い会議を優先して拾う指示になっています。接続されていなければ、ユーザーに載せたい内容を尋ねるか、渡された内容を書式に整える作業に切り替わります。

入れ方 — Claude Codeとclaude.ai

Claude Codeでは、anthropics/skillsをプラグインのマーケットプレイスとして登録します。internal-commsはexample-skillsというプラグインに束ねられていて、リポジトリのREADMEには次の2行が載っています。

/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

example-skillsにはinternal-commsのほか、brand-guidelines、doc-coauthoring、skill-creator、mcp-builderなど12本が入っています。1本だけ欲しくてもプラグイン単位で入る点には注意が必要です。プラグインのスキルは/プラグイン名:スキル名で呼べるため、明示的に起動したいときは/example-skills:internal-commsになります。

claude.aiについては、READMEに「これらのexampleスキルは有料プランのClaude.aiでは既に使える」と書かれています。API利用の場合は、Anthropic提供のスキルを使う方法と、自作のスキルをアップロードする方法の両方がREADMEで案内されています。スキル全般の仕組みはClaude Skillsとは・使い方に、Claude Code側のSKILL.mdの書き方はClaude Code Skillsのfrontmatter全フィールドとSKILL.mdの書き方にあります。

入れたあとは、スキル名を言わなくても動きます。SKILL.mdのdescriptionに「社内向け文書を頼まれたら使う」と書かれているので、次のような依頼で読み込まれる想定です。

モバイルチームの今週分の3P更新を書いて。
進捗は iOS 18対応のリリース、課題はAndroidのクラッシュ率上昇。

3P更新 — 進捗・計画・課題を3行で書く

3P更新は、Progress(進捗)、Plans(計画)、Problems(課題)の頭文字です。想定読者は経営陣や他チームで、チームの事情に詳しくない人でも30〜60秒で読める長さに収める、という前提が置かれています。対象期間は、ほぼ必ず1週間です。

書式は固定で、これ以外の体裁を使わないよう指示されています。

[絵文字] [チーム名] (対象期間)
Progress: [1〜3文]
Plans: [1〜3文]
Problems: [1〜3文]

絵文字はチームや更新の雰囲気に合うものを選ぶことになっています。各項目は1〜3文で、可能なら数値を入れ、淡々と書く指定です。チームの規模が大きいほど粒度を粗くする、という考え方も書かれています。モバイルチームなら「機能をリリースした」「バグを直した」、全社なら「20人採用した」「10件成約した」の粒度です。

作業の流れは4段階です。

先ほどの依頼から返ってくる文面は、例えば次のような形になります(書式ファイルの指定に沿って作った例で、実際の出力ではありません)。

📱 モバイルチーム (10/20〜10/26)
Progress: iOS 18対応版をリリースし、審査も1回で通過。
Plans: Androidのクラッシュ率上昇の原因を特定し、来週中に修正版を出す。
Problems: Androidのクラッシュ率が先週の0.4%から1.1%に上昇。再現条件が絞れていない。

数字を埋めるのはこちらの仕事です。スキルは「データに基づいて」と指示しているだけで、数値の出所までは保証しません。指標がチャンネルに無いなら、依頼文に数字を含めて渡します。

社内ニュースレター — 20〜25項目を「私たち」で書く

全社向けのニュースレターは、直近1週間か1か月の動きを、Slackとメールで配れる形にまとめます。目安は箇条書き20〜25個前後で、各項目は長くても1〜2文です。文体は「私たちは〜した」という一人称複数にします。書き手も会社の一員として語る形です。

リンクを多く入れる指定も特徴です。重要なGoogle Drive文書、告知チャンネルや経営陣の投稿、全社宛てのメール、会議に添付された資料、報道への言及を優先して拾います。拾う基準は次のようになっています。

• 載せる: 全社に影響があること、リーダーからの発表、大きなマイルストーン、多くの社員に関わる情報、社外からの評価
• 載せない: チーム単位の細かな更新(3P更新に回す)、少人数にしか関係のない情報、すでに周知済みの内容

見落としやすいのは、書式ファイルが前提にしている「会社は1000人以上」という規模です。セクションの切り方の例として、製品開発・営業・財務、採用・実行・ビジョン、社外ニュース・社内ニュースが挙がっています。数十人規模の会社なら、この分け方は大げさになります。セクションは2〜3個に絞り、項目数も減らすほうが読まれます。

見出しの例は絵文字付きで、Slack向けです。

:megaphone: 会社からの発表
- 発表1
- 発表2
 
:dart: 重点テーマの進捗
- 領域1
    - 細目1
    - 細目2
 
:pillar: リーダーからのメッセージ
- 投稿1

SlackやGoogle Driveを実際に読み込ませる手順は、Claudeで社内報・ニュースレターを自動作成する方法にあります。そちらは接続を前提にArtifactで作る手順で、internal-commsは書式と取捨の基準を決める側です。両方を組み合わせると、基準が固定されたままArtifactに仕上げられます。

FAQ — 社員が迷っていることを先回りして答える

FAQの書式ファイルが狙うのは、社内で多くの人が迷っている質問を見つけ、短く答えることです。出発点は、Slackで多くの反応が付いた質問、メール内のFAQ、会議資料の内容から推測される疑問などです。例として、資金調達や新任役員、近く予定されている製品の発表、採用の進み具合、方針の変更が挙がっています。

書式は2行だけです。

- *Question*: [質問 1文]
- *Answer*: [回答 1〜2文]

回答のルールは、公式な社内告知に基づくこと、不確かな点はそう明記すること、根拠となる資料にリンクすること、トーンは丁寧だが堅すぎないこと。経営陣の判断が要る質問には、その旨の印を付けます。

「経営陣の判断が要る質問に印を付ける」は、FAQを作る場面で最も使える指示です。分からないことを推測で埋めず、答えられる人に回すからです。人事制度や報酬など、誤答が実害になる話題では、この指示を依頼文でも繰り返しておくと安全です。

それ以外の文書 — 汎用ファイルは質問から始まる

ステータスレポートやインシデント報告などは専用の書式を持たず、general-comms.mdが受けます。このファイルは書き始める前に4点を尋ねる作りです。読者、目的、トーン(硬い・くだけた・緊急・情報提供)、書式の指定です。そのうえで、明快に簡潔に、能動態で、重要なことを先に書くという原則で書きます。

障害対応の報告書を書くなら、専用の流れを持つスキルのほうが向きます。Claudeのincident-responseスキルで障害対応とポストモーテムを回すでは、状況報告からポストモーテムまでを扱っています。

自社用に作り替える

SKILL.mdのdescriptionは「私の会社が好む書式で社内文書を書くための資料集」と読める書き方です。つまり、標準の書式は出発点で、自社の流儀に合わせて書き換える前提のスキルです。書式ファイルに残る前提(1000人以上の会社、Slackで配布、絵文字付きの見出し)が、最初に直す箇所になります。

作り替えは、スキルのフォルダを自分の場所へコピーして編集します。Claude Codeでは、保存場所で効く範囲が変わります。

プラグイン版と取り違えないよう、team-commsのように別名で置きます。例えば、日本語で出力し、チームの既定値を持たせる場合は次のようにします。

---
name: team-comms
description: >
  プロダクト開発部の社内向け文書(週次3P、月次ニュースレター、
  FAQ)を書くときに使う。
---
 
出力は日本語。Slackに貼るため見出しは絵文字+太字のみ使う。
 
## 3P更新
- チーム名の既定値: プロダクト開発部
- 対象期間は月曜〜日曜。Plansは翌週分
- 形式は examples/3p-updates.md に従う。数値がなければ空欄にして聞き返す

元の3p-updates.mdはexamples/にそのまま置いておけます。SKILL.mdから参照すれば、必要なときだけ読み込まれる構成のままです。自社の過去の3P更新を2〜3本、書式ファイルの末尾に例として足すのも効果があります。標準版には実例が入っていないため、文体の手がかりが書式の説明文だけになるからです。

うまくいかないときの切り分け

• スキルが呼ばれない: 依頼に「社内」「3P」「ニュースレター」のような語が入っているかを見ます。SKILL.mdのKeywordsに挙がっているのは、3P updates、company newsletter、company comms、weekly update、faqs、common questions、updates、internal commsです
• 3P更新の項目が長くなる: 依頼文に元の資料を大量に貼ると、要約しきれずに文が伸びます。数値と出来事だけを箇条書きで渡すほうが、書式に収まります
• ニュースレターが薄い: Slackやメールに接続していないと、書式を整えるだけの作業になります。接続の有無は依頼の最初に伝えます
• 標準版と自作版の両方が反応する: 同じ種類の依頼にdescriptionの近い2つのスキルがあるためです。自作版を使う運用にするなら、標準のプラグインを無効にして1本に絞ります

doc-coauthoringとの違いにも触れておきます。doc-coauthoringスキルでClaudeと文書を共同で書き上げる手順は、仕様書や提案書のような長い文書を対話で組み立てるスキルです。internal-commsは、短く定型で、定期的に出す文書の書式を決めます。資料の見た目を揃えたいならClaudeのブランドガイドラインをSkill化して資料に自動適用するの守備範囲です。

まとめ

internal-commsは、社内文書のうち「短く、定型で、繰り返し出すもの」の書式を固めるスキルです。3P更新は3項目・各1〜3文、ニュースレターは20〜25項目、FAQは質問1文と回答1〜2文という縛りを持ち、汎用の依頼は質問から始まります。

そのまま使うと、1000人超の会社を想定した書式が出てきます。自分の組織の規模と使うツールに合わせて、まず3P更新だけをteam-commsに切り出し、数週間回して手直しするのが現実的な入り方です。