internal-comms

internal-commsスキルの概要

internal-comms スキルは、社内向けの連絡文やアップデートを、単に整った無難な文章ではなく、実際のチームが日々共有している書き方に近い形でAIに作成させるためのスキルです。特に、週次の3Pアップデート、社内ニュースレター、FAQ要約、ステータスレポート、経営層向けアップデート、プロジェクト更新、インシデント風の要約など、繰り返し発生する社内文書のドラフトを素早く作りたい人に向いています。

internal-commsスキルの用途

このスキルが解決する本質的な課題はシンプルです。組織内に散らばった情報を、既知の社内フォーマットに沿ったコミュニケーション文書へ変換することです。単にモデルへ「アップデートを書いて」と頼むのではなく、internal-comms スキルは、形式ごとのガイダンスを伴う、より狭く明確なパターンへタスクを振り分けます。

インストールに向いている人

このスキルが特に合うのは、次のような人です。

• オペレーション担当者、chief of staff、社内広報・社内コミュニケーション担当
• 週次・月次アップデートを書くチームリード
• 複数部門の進捗を集約するエグゼクティブアシスタントやプログラムマネージャー
• 定常的な社内文書作成にAIを使いたい人。特に internal-comms for Email Writing や Slack向け要約を作るケース

普通のプロンプトと何が違うのか

主な価値は、裏で何か自動化されることではありません。形式の選択とサンプル例があることです。リポジトリには、以下それぞれに対する個別のガイダンスがあります。

• 3P updates
• company newsletters
• FAQ answers
• general internal communications

この構造が効くのは、一貫性がボトルネックになる場面です。つまり、簡潔さ、適切な読者レベル、必要十分な文脈量を揃えたいときに役立ちます。

internal-commsスキルが得意なこと

internal-comms スキルが最も力を発揮するのは、次のような条件です。

• どの種類の社内連絡かがすでに決まっている
• 組織内に繰り返し使えるアップデート様式がある
• 元情報が Slack、メール、ドキュメント、カレンダー、メモに存在している
• 簡潔で、読者に合わせた初稿が欲しい

これ単体ではできないこと

これは、データ収集パイプラインでも、完全に作り込まれた編集ワークフローでもありません。このフォルダには、スクリプト、ルールエンジン、リトリーバル用ツールは含まれていません。元になる事実は自分で渡すか、アップデートの情報源があるシステムへモデルがアクセスできる必要があります。社内で厳密なテンプレート、承認ポリシー、法務レビューがある場合は、それを別途上乗せする必要があります。

internal-commsスキルの使い方

internal-commsのインストール方法

一般的な skills 環境では、Anthropic skills repository から internal-comms skill をインストールします。

npx skills add https://github.com/anthropics/skills --skill internal-comms

その後、以下の配下にファイルがあることを確認してください。

skills/internal-comms

インストール前に評価したい場合は、ソースをこちらで確認できます。
https://github.com/anthropics/skills/tree/main/skills/internal-comms

最初に読むべきファイル

最短で使い始めるなら、次の順番で読むのがおすすめです。

1. SKILL.md
2. examples/3p-updates.md
3. examples/company-newsletter.md
4. examples/faq-answers.md
5. examples/general-comms.md

このリポジトリは小規模なので、実質的にはサンプルがプロダクト本体です。実用上の振る舞いの多くは、そこに書かれています。

まず適切なコミュニケーション形式を選ぶ

ドラフト品質を最も大きく左右するのは、書き始める前に正しいサンプルファイルを選ぶことです。

• examples/3p-updates.md は、Progress / Plans / Problems 形式の短い経営層向け・チーム向け更新に使います。
• examples/company-newsletter.md は、全社向けの振り返りを箇条書きでまとめる用途に向いています。
• examples/faq-answers.md は、多くの社員が似た質問をしていて、統合した回答集が必要な場合に使います。
• examples/general-comms.md は、それ以外の一般的な社内連絡向けです。

この手順を飛ばすと、出来上がる文章はかなりの確率で無難すぎる汎用文になります。

internal-commsスキルに必要な入力

internal-comms の使い方として最も結果が良いのは、次の情報を与える場合です。

• コミュニケーションの種類
• 対象読者
• 対象期間
• 元資料
• 望ましいトーン
• 必須のリンクや引用
• 文字数、承認上の配慮、避けたい内容などの制約

弱い入力例:

• “Write a company update.”

より強い入力例:

• “Write a weekly 3P update for the Infrastructure team for leadership. Use the notes below, keep it readable in under 45 seconds, mention one blocker, and avoid low-level task detail.”

internal-commsをうまくプロンプトするコツ

良い呼び出しプロンプトは、通常4つの要素を含みます。

1. Format
   “Use the internal-comms skill and write this as a 3P update.”

2. Audience and context level
   “Audience is exec staff with partial context.”

3. Source facts
   “Use these launch notes, incident notes, and hiring updates.”

4. Output constraints
   “Keep it under 150 words, use bullets, and call out one key risk.”

「とにかく polished な文章にして」とだけ頼んで、モデルが適切な構造を選ぶことに期待するより、はるかに再現性があります。

internal-comms活用のおすすめワークフロー

実務で回しやすい流れは次のとおりです。

1. 形式を特定する
2. 生の入力情報を集める
3. その形式を明示してモデルに初稿を書かせる
4. 抜け漏れ、言い過ぎ、読者とのズレを確認する
5. より厳しい制約を付けて2回目の推敲を依頼する

このスキルは、特に初稿づくりの段階で役立ちます。ただし、社内向け更新にはセンシティブな表現、未確定情報、政治的なニュアンスが含まれがちなので、人のレビューは依然として重要です。

サンプルが出力にどう効くか

サンプルファイルには、導入判断に直結する重要な指針が詰まっています。

• 3p-updates.md は、簡潔さと読者が持つ文脈量を重視しています
• company-newsletter.md は、短い箇条書き、we 語り、多めのリンクを促します
• faq-answers.md は、繰り返し出る社員の疑問と、その要約回答に焦点を当てています
• general-comms.md は、読者、目的、トーン、形式の明確化を強く求めます

つまりこのスキルは、「創作的にうまく書く」ことよりも、情報をどの形に整えるべきかを正しく選ぶことに重心があります。

Email Writing向けにinternal-commsを使う

internal-comms for Email Writing として使う場合は、ベースのサンプルでは暗黙的にしか触れられていない、メール固有の制約も明示すると効果的です。

• その文面を Slack にも流用する必要があるか
• 件名に関する要件
• リンクを文中に埋めるか、まとめて載せるか
• あいさつと締めをどの程度フォーマルにするか
• 情報共有目的なのか、説得目的なのか、是正・注意喚起なのか

プロンプト例:
“Use the internal-comms skill. Draft a company-wide email newsletter from the past two weeks. Make it scannable, 20 bullets max, include links where mentioned, use ‘we’ voice, and add a short subject line plus preview text.”

確認質問をさせるべきタイミング

このリポジトリは、形式が不明確な場合に確認質問をすることを明示的に想定しています。次のどれかが欠けているなら、確認させたほうがよいです。

• 3Pにおけるチーム名
• general comms における読者
• 対象期間
• 想定トーン
• 出力先が Slack、email、docs のどれか、あるいは全部か

これらがないままだと、もっともらしく見えても実務では使えない文面になることがあります。

送信前の実践的な品質チェック

internal-comms で作ったドラフトを公開・送信する前に、次を確認してください。

• 対象読者に対して情報を出しすぎていないか
• 一番伝えるべき更新が埋もれていないか
• “plans” が、進捗の言い換えではなく本当に今後の予定になっているか
• blocker が具体的で、行動につながる内容になっているか
• ニュースレター形式で必要なリンクが入っているか
• FAQ回答が推測ではなく要約になっているか

このあたりが、初稿としては悪くなくても、実際の業務では落ちやすいポイントです。

internal-commsスキル FAQ

すでにプロンプトを書ける場合でも、internal-commsは入れる価値がある？

あります。標準化された数種類の形式で社内アップデートを書くことが多いなら、導入価値は十分です。internal-comms スキルの価値は魔法のような新機能ではなく、プロンプトのぶれを減らし、毎回ゼロから書くよりも良い初期構造をモデルに与えられる点にあります。

初心者でも使いやすい？

はい。リポジトリは小さく、内容も確認しやすい構成です。初心者でも、examples/ の中から近いファイルを選び、元情報を少し丁寧に渡すだけで、すぐ効果を実感しやすいはずです。セットアップの複雑さもほとんどありません。

どんな種類のコミュニケーションに向いている？

相性が良い用途は次のとおりです。

• 週次チームアップデート
• 経営層向け要約
• 全社ニュースレター
• 社内FAQダイジェスト
• プロジェクト更新・ステータス更新
• 軽量なインシデント要約

自社で 3P やそれに近い更新習慣がすでにあるなら、特にフィットしやすいです。

internal-commsが向かないのはどんなとき？

次のような場合は、相性がやや弱くなります。

• 厳密なコンプライアンス文言や法務レビュー前提の表現が必要
• 形式が高度にカスタマイズされていて、同梱サンプルと大きく異なる
• まだ元になる事実が存在していない
• タスクが外部向けPR、マーケティング文面、顧客向けメッセージである

これは社内文書作成の補助であり、あらゆるコミュニケーションに使える万能フレームワークではありません。

Slack、email、docsと自動連携する？

このフォルダ単体ではしません。サンプル内では Slack、Email、Calendar、Documents などが理想的な情報源として挙げられていますが、このスキル自体にコネクタは同梱されていません。実運用では、エージェント環境側ですでにそれらのツールへアクセスできる必要があるか、関連する情報を自分で貼り付ける必要があります。

汎用的な「アップデートを書いて」と何が違う？

汎用プロンプトでは、読者調整や構造が外れやすくなります。internal-comms のガイドは、タスクを絞ることで結果を改善します。たとえば 3P なら、短く、経営層が読みやすく、Progress・Plans・Problems に分かれているべきです。こうした制約があることで、実際に使える初稿になりやすくなります。

internal-commsスキルを改善する方法

依頼を広げるより、元情報を強くする

最も効く改善は、入力を良くすることです。

• チームリードからの箇条書きメモ
• 元ドキュメントへのリンク
• リアクションや可視性が分かる Slack メッセージ
• リリース済み項目、意思決定、blocker、今後の作業の一覧
• FAQ統合の元になる、社員からの粗い質問群

圧縮すべき根拠が増えるほど、このスキルの出力は大きく良くなります。

読者を具体的に指定する

“Leadership” と “whole company” と “teammates” は同じではありません。より良いプロンプト例は次のようなものです。

• “Write for executives who know the project name but not sprint-level details.”
• “Write for the full company, including non-technical teams.”
• “Write for employees already discussing this topic in Slack.”

読者指定の精度によって、用語選び、詳細度、何を重要とみなすかが変わります。

事実・解釈・リスクを分けて渡す

internal-comms の運用でよくある失敗は、確定事実と楽観的なストーリーが混ざることです。これを防ぐには、入力を次の3つに分けて渡してください。

• confirmed facts
• proposed framing
• unresolved questions or risks

こうしておくと、モデルが不用意に言い過ぎるのを防ぎやすくなります。

形式制約を明示する

レビューを通しやすい出力が欲しいなら、次を明示してください。

• 最大文字数
• 箇条書き数
• 必須セクション
• 必ず入れるリンク
• 禁止フレーズ
• 不確実な項目に対する確信度の扱い

たとえばニュースレターのサンプルは、箇条書き数とリンク要件を指定すると明らかに良くなります。3Pのサンプルは、簡潔さを厳しく求めるほど効果が出ます。

的を絞った修正依頼で初稿を改善する

単に “make it better” と言うのではなく、次のように修正指示を具体化してください。

• “Make the Problems section more concrete.”
• “Cut jargon for a company-wide audience.”
• “Add links where a reader would want to click through.”
• “Reduce this from 220 words to 120 without losing the main blocker.”
• “Turn repeated project details into one executive summary line.”

こうした依頼は、このスキルの本来の強みにきれいに噛み合います。

主な失敗パターンをチェックする

よくある問題は次のとおりです。

• 間違ったサンプルファイルを選んでいる
• 文脈レベルが読者に合っていない
• 生メモを繰り返すだけで要約・統合できていない
• blocker が曖昧
• ニュースレター形式でリンクが不足している
• FAQ が、社員が実際に知りたいことではなく、経営側が言いたいことに答えてしまっている

これらの失敗パターンを確認するのが、internal-comms の出力品質を最短で上げる方法です。

自社向けにinternal-commsスキルを拡張する

標準の internal-comms スキルが近いけれど足りない場合、最もきれいな改善策は、自社向けのサンプルファイルを追加することです。たとえば次のような形式です。

• meeting recap format
• incident review summary
• launch announcement
• org change memo
• monthly business review digest

このスキルはサンプル主導で設計されているため、一般論の指示を長く書くよりも、自社で実際に使うテンプレートを足すほうが、たいてい価値が高くなります。