mcpField
S
sgds-writing

sgds-writing

github.com/govtechsgデザイン・UI18207 回インストール3 日前に更新
リポジトリ

sgds-writing について

sgds-writing は、Singapore Government Design System を使う政府デジタル製品チーム向けのライティングガイドです。UI 文言やドキュメントを対象に、文体、イギリス英語の綴り、文法、アクセシビリティ、UI 表現のルールをまとめています。

主な機能

  1. 01トーンと文体の基準
  2. 02イギリス英語の綴り規則
  3. 03大文字表記、句読点、文法の規則
  4. 04エラーや読み込み中の文言ガイド
  5. 05アクセシビリティに関する執筆指針

活用シーン

  1. 01政府製品の UI 文言を作成
  2. 02コンポーネント文書、ツールチップ、ラベルを編集
  3. 03エラーやステータスメッセージを統一
  4. 04デジタルコンテンツのアクセシビリティを確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/govtechsg/sgds-web-component --skill sgds-writing

インストール後、Claude Code で/sgds-writingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

reference/
grammar.md
punctuation.md
spelling.md
word-choice.md

詳細

SGDS ライティングガイド

Singapore Government Design System を使用して構築された行政向けデジタル製品のコンテンツ基準です。すべての UI コピー、ドキュメント、ツールチップ、ラベル、エラーメッセージ、および SGDS コンポーネントに付随するあらゆる文章に、これらのルールを適用してください。


トーンと文体

官僚的ではなく、信頼できる有能なパートナーとして書いてください。GovTech の文体は次のとおりです。

  • 明快 — 必要な言葉だけを使い、伝えたいことを正確に述べます
  • 直接的 — 読者に「あなた」と呼びかけ、能動態を使います
  • 敬意を払う — 読者を判断力のある大人として扱い、説明しすぎないようにします
  • 目的を重視 — すべての文に役割を持たせ、余分な言葉を取り除きます

企業用語(「活用する」「相乗効果を生み出す」「包括的なアプローチ」)、中身のない強調語(「非常に」「極めて」「重要な」)、曖昧な将来志向の表現(「革新的な」「最先端の」「将来にも対応した」)は、文脈上本当に必要な場合を除き避けてください。

推奨: 私たちは、行政機関がデータを安全に共有できるよう支援します。 避ける: 私たちは、最先端の革新的なソリューションを活用し、政府機関間でシームレスなデータ交換を包括的に実現します。


スペル

全体を通してイギリス英語のスペルを使用してください。

イギリス英語(正)アメリカ英語(避ける)
colourcolor
centrecenter
programmeprogram(ソフトウェアを指す場合を除く)
organisationorganization
recogniserecognize
analyseanalyze
cataloguecatalog
licence(名詞)license(名詞)
license(動詞)licence(動詞)
travelledtraveled
fulfilfulfill
practise(動詞)practice(動詞)
practice(名詞)practise(名詞)

スペルチェック設定:エディターと CI のスペルチェッカーを en-GB に設定してください。VS Code では "editor.language": "en-GB" に設定するか、Spell Right 拡張機能を "spellright.language": ["en-GB"] とともに使用します。

単語一覧の全体は、→ reference/spelling.md を参照してください。


大文字表記

以下で明示的に例外とされている場合を除き、すべての見出し、ラベル、ボタンテキスト、ナビゲーション項目、エラーメッセージ、本文にはセンテンスケースを使用してください。

センテンスケースとは、文頭の単語と固有名詞だけを大文字にすることです。

正:

  • 申請を提出する
  • すべてのサービスを表示する
  • エラー:ファイルサイズが上限を超えています

誤(タイトルケース):

  • 申請を提出する
  • すべてのサービスを表示する
  • エラー:ファイルサイズが上限を超えています
大文字表記が必要な例外
  • 固有名詞:GovTech、SingPass、CorpPass、Smart Nation、Singapore、Ministry of Finance
  • 常に大文字で表記する頭字語:API、ICT、UI、UX、PDF、URL
  • 大文字表記が定着している製品名およびシステム名:Singpass、CorpPass、MyInfo
  • 代名詞として使う「I」
大文字にしないもの
  • 説明的に使う役職名:「the director approved the request」(名前の前に称号として使う場合のみ大文字:「Director Jane Tan approved the request」)
  • 一般的な意味で使う行政サービスやプログラム:「the digital identity programme」、「the data-sharing initiative」
  • 季節、方角、概念:「the autumn release」、「head north on the main road」

句読点

em ダッシュは使用しない

いかなる場合も em ダッシュ(—)を使用しないでください。視覚的なノイズとなり、スクリーンリーダーで読み違えられたり、読み飛ばされたりすることがあります。

代替表現:

次の表現の代わりに次の表現を使用
The form — which is required — must be submitted by Friday.The form, which is required, must be submitted by Friday.
Submit before Friday — or your application will lapse.Submit before Friday. Otherwise, your application will lapse.
Three options — email, phone, or in person — are available.Three options are available: email, phone, or in person.

コロン、コンマで囲む表現、または新しい文を使用してください。em ダッシュは使用しないでください。

コンマ

3 つ以上の項目を列挙する場合は、オックスフォードコンマ(列挙の最後のコンマ)を使用してください。

正: You will need your NRIC, passport, and proof of address. 誤: You will need your NRIC, passport and proof of address.

ハイフンと en ダッシュ
  • 名詞の前に置く複合修飾語にはハイフン(-)を使います:「ユーザーフレンドリーなインターフェース」、「エンドツーエンドの暗号化」
  • en ダッシュ(–)は数値の範囲にのみ使います:「10~15 ページ」、「2020~2024 年」
  • em ダッシュの代わりに en ダッシュを使わないでください
アポストロフィ
  • 所有を表す場合に使います:the agency's portal、the user's profile
  • 複数形には使いません:APIs は API's ではなく、PDFs は PDF's ではありません
コロンとセミコロン
  • コロンはリストや説明の導入に使います。コロンの後の語が固有名詞、または単独で成立する完全な文の冒頭でない限り、その語を大文字にしないでください。
  • セミコロンは控えめに使います。セミコロンで文をつなぐより、短い 2 つの文に分けてください。

文法

能動態

能動態を優先してください。主語が動作を行い、動作を受ける形にはしません。

能動態: システムは確認メールを送信します。 受動態: 確認メールはシステムによって送信されます。

動作主が不明、無関係、または動作より重要でない場合は、受動態を使ってもかまいません:「データは保存時に暗号化されます。」

対比を表す否定表現を使わない

「X ではなく Y」や「X だけでなく Y も」という形の対比を表す否定表現は使わないでください。否定の段階が加わるため、読み進める速度が落ちます。

避ける表現:

  • バグトラッカーではなく、包括的なプロジェクト管理ツールです。
  • これは任意ではなく、必須です。
  • 私たちはツールを作るだけではなく、信頼も築きます。

推奨表現:

  • バグの追跡機能も備えた、包括的なプロジェクト管理ツールです。
  • これは必須です。
  • 私たちは信頼を築くツールを作ります。
文の長さ

文は 20 語未満を目安にしてください。ある節を別の節で補足する必要がある場合は、文を 2 つに分けてください。

並列構造

リスト項目、見出しの組み合わせ、ボタンラベルでは、同じ文法形式を使ってください。

正しい例(すべて動詞句):

  • 新しいアカウントを作成する
  • パスワードをリセットする
  • 取引履歴を表示する

誤った例(形式が混在):

  • 新しいアカウントを作成する
  • パスワードのリセット
  • 取引履歴を表示すること
短縮形

すべての内容で短縮形を使わないでください。常に完全な形で書いてください。

正しい例: アカウントを作成する必要はありません。 誤った例: アカウントを作成する必要はないです。

正しい例: インターフェースを更新しました。 誤った例: インターフェースを更新しました(短縮形)。

注: これは、ほとんどのプロダクトデザインシステムガイドとは意図的に異なる方針です。GOV.UK、Canada.ca、Shopify Polaris、Apple HIG は、より自然に聞こえるという理由から、短縮形の使用をすべて推奨しています。シンガポール政府の公式プロダクトにふさわしい、正式で一貫した言葉遣いを保ち、曖昧さ(たとえば、「it's」と「its」)をなくすため、短縮形は使いません。

法助動詞 — must、need to、should、may

法助動詞は正確に使ってください。誤った選択は、意図しない法的義務や誤った安心感につながります。

語句使用する場面例
Must法的義務 — ユーザーに選択の余地がない場合1 月 31 日までにフォームを提出しなければなりません。
Need toユーザーが完了することを求められる事務手続きサインインする前にメールアドレスを確認する必要があります。
Should推奨 — 義務ではないが、ユーザーに勧める場合定期的に進行状況を保存することをお勧めします。
May許可されているが任意の場合補足書類を添付できます。

事務手続きに「must」を使わないでください。存在しない可能性のある法的責任を示唆します。実際には必須の手順に「should」を使わないでください。

数字
  • 1 から 9 までの数字は英単語で表記し、10 以上は算用数字を使います。
  • 次の場合は常に算用数字を使います:割合(5%)、通貨($10)、測定値(3 MB)、バージョン番号(version 2)。
  • 1,000 以上の数字にはカンマを使います:1000 ではなく 1,000。
  • 範囲の両方の数字が 10 未満の場合も、算用数字を使います:「3~9 営業日」。
日付と時刻
  • 日付:2025年1月1日(年・月・日の順。序数の接尾辞は付けません。「1st January」ではありません)
  • 時刻:9am、3:30pm(数字とam/pmの間にスペースを入れません)
  • 文章中の日付の範囲:2025年1月1日から3日(エヌダッシュではなく「から」と書きます)
  • 表や省スペースが必要なUI要素の日付の範囲:1–3 Jan 2025(スペースが限られている場合はエヌダッシュを使用できます)

平易な表現の原則

  1. 最も重要な情報から始めます。 要点を最初の文に入れます。
  2. 1つの段落につき1つの考えを扱います。 2つの考えを含む段落は分割します。
  3. 余分な言葉を省きます。 「ご注意ください」「注目すべき点として」「〜するために」「現時点では」は削除します。
  4. 短い言葉を優先します。 「utilise」ではなく「use」、「facilitate」ではなく「help」、「procure」ではなく「buy」、「demonstrate」ではなく「show」を使います。
  5. 名詞化を避けます。 「make a decision」は「decide」に、「provide assistance」は「help」に、「conduct an investigation」は「investigate」に変えます。
  6. 指示に「please」を使いません。 情報が増えず、遠慮がちな印象になります。「Please submit the form」ではなく「Submit the form」と書きます。取引メールや正式な文書で、心からの礼儀を示す表現は例外です。
  7. 主観的な形容詞を使いません。 何かを「重要」「簡単」「シンプル」「迅速」「わくわくする」とユーザーに伝えないでください。重要であれば、その理由を示します。シンプルであれば、デザインで伝わるようにします。検証できない主観的な主張は信頼を損ないます。

UI文言のパターン

ボタンと行動喚起
  • 動詞句を使います:「フォームを送信」「レポートをダウンロード」「サインイン」
  • あいまいなラベルは使いません:「ここをクリック」「OK」「移動」
  • ボタンのラベルに句読点を付けません
エラーメッセージ
  • 何が起きたかと、次にユーザーがすべきことを伝えます。
  • ユーザーを責めません。

適切: ファイルサイズが大きすぎます。5 MB未満のファイルをアップロードしてください。 不適切: アップロードしたファイルのサイズが大きすぎます。もっと小さいファイルをアップロードしてください。

空の状態
  • 項目が表示されていない理由を説明し、次の手順を提示します。

適切: まだ申し込みはありません。最初の申し込みを始めましょう。 不適切: ここには何もありません。

ツールチップと補足テキスト
  • ツールチップは1文にします。
  • フィールドの下に表示する補足テキストでは、ラベルの言い換えではなく、形式や制約を説明します。

ラベル: 生年月日 補足テキスト: DD/MM/YYYY形式を使います 不可: 生年月日をDD/MM/YYYY形式で入力してください

読み込み中とステータスのメッセージ
  • 現在進行形を使います:「結果を読み込んでいます…」「変更を保存しています…」
  • 完了したことを過去形で伝えます:「変更を保存しました。」「申し込みを送信しました。」

アクセシビリティに関する考慮事項

  • 意味を伝える際に色だけに頼らず、必ずテキストも併記します。
  • 画像の代替テキストでは、見た目ではなく機能を説明します:「青い長方形の画像とテキスト」ではなく「GovTechのロゴ」。
  • リンクテキストは、文脈から切り離しても意味が通じるようにします:「ここをクリック」ではなく「年次報告書をダウンロード(PDF、2 MB)」。
  • 視覚的な配置に依存する方向の指示は避けます。「右側のセクションを参照」は、スクリーンリーダーの利用者には機能しません。

参考ファイル

トピックファイル
英国式・米国式スペルの単語リスト→ reference/spelling.md
文法ルールのクイックリファレンス→ reference/grammar.md
句読点のクイックリファレンス→ reference/punctuation.md
語句の選び方と平易な表現→ reference/word-choice.md

コメント