1. 社内の連絡は、件名と冒頭から用件を伝えたい

英語圏の社内報のような明るい呼びかけや、見出しと絵文字の多い構成は、日本の会社の連絡には合わないことがあります。件名が「〜について」だけだと、お知らせなのか、期限のある依頼なのかも分かりません。

そこで、件名で用件と期限、冒頭で結論と依頼が分かり、部署の外に転送されても困らない文面を目指しました。internal-notice-jaは、日本の会社の社内のお知らせ・週報・連絡を書くためのスキルです。

着想元は、Anthropicの公開スキル集「internal-comms」（Apache License 2.0、参照日：2026-10-27）です。「連絡の種類を見分け、該当する書き方の決まりを読む」という構成だけを参考にしました。文章・例・プロンプト・コードの転載や翻訳はせず、日本語の決まり・例文・スクリプトは独自に作っています。Anthropicとは関係のない非公式のスキルであることを、READMEにも明記しています。

2. 種類と読み手を決め、冒頭3行を先に見せる

扱うのは、全社へのお知らせ、週報・進捗の報告、部署内の依頼・連絡、障害・事故の報告（第一報と続報）、よくある質問への回答の5種類です。当てはまらない連絡には、共通の決まりだけを使います。

種類と読み手を決めたら、材料を集めます。日付・数字・規程の名前・担当者は推測で作らず、不足は「要確認」で残します。本文より先に、件名と冒頭の3行を見せる手順にしました。結論・依頼・期限を先に置き、種類ごとの型で本文を書いてから点検します。最後に文面と「要確認」、転送して困る情報の確認結果を返し、ファイルの書き換えや外部への送信はしません。

共通の決まりでは、件名を【お知らせ】【ご依頼】【報告】などの区分＋用件＋日付・期限にし、「〜について」で終えません。日付には曜日を付け、「今週中」のようなあいまいな期限を避けます。社外秘の情報、個人の評価・健康の情報、未確定の人事は入れず、絵文字や英語圏の社内報のような呼びかけも使いません。詳しい決まりと種類ごとの型は公開READMEへ案内しています。

3. 件名を直し、週報は結論から始めた

READMEに掲載した件名の修正前後です。区分だけでなく、何が変わるのか、いつまでの依頼か、いつ時点の報告かを件名に入れました。

修正前 修正後
会議室予約の切り替えについて 【お知らせ】会議室予約システム切り替え・2026年11月9日（月）
貸出一覧について 【ご依頼】貸出一覧の未返却欄更新・2026年11月6日（金）15:00期限
社外秘・予約システムの障害について 【報告】【社外秘】会議室予約の登録不可・第一報・2026年11月5日（木）10:15時点
貸出機器の延長について 【回答】貸出機器は原則延長不可・2026年11月6日（金）回答

週報は、冒頭を「予定20件に対し18件完了・2件遅れ」という結論と、判断の依頼にしました。出来事を順に並べる前に、予定との差と、読み手に決めてほしいことを示す形です。

4. 機械の点検と、人の確認を分ける

補助スクリプト check_notice.py は、Pythonの標準ライブラリだけで動き、読み取りと標準出力だけを行います。件名末尾の「について」、件名の日付の欠落、冒頭の日時・依頼の言葉の欠落、絵文字、あいまいな期限、曜日のない日付、残った「要確認」を表示します。

公開READMEの記録では、AIが架空の依頼メモを5種類各1本作り、決まりと型を読んで書き直しました。

連絡の種類 修正前 修正後
全社へのお知らせ 8件 0件
週報 9件 0件
部署内の依頼 6件 0件
障害の第一報 7件 0件
よくある質問 6件 0件

修正後の5本は、同じスキル集の ai-smell-ja による点検でも0件でした。件数は検出項目に一致した数で、読みやすさの評価点ではありません。 作成と照合は同じAIが行い、実際の利用者との確認の往復はしていません。

スクリプトは0件でも、最後に人が確かめる点を表示します。対象者が適切か、敬語が合うか、転送して困る情報がないか、規程の内容が正しいかは、人が原文や社内の決まりと照らして確かめる分担です。

5. まだ分からないこと

試したのは5種類各1本の短い例だけです。長文、複数の依頼、第一報から続報への実際の運用は試していません。実際の社員による読みやすさの評価や、業種・会社ごとの慣習の違いも未確認で、時間の短縮や品質の向上は測っていません。

正規表現の指摘には、見逃しと誤検出があります。また、比較例のように件名へ「社外秘」と書くだけで、情報の共有が安全になるわけではありません。法令の判断や人事・健康の情報は担当部署に確かめ、文面を採用する前に共有先と内容を確認してください。