zpaper-draft

Type to search...

to open search from anywhere

語彙のルール

記事執筆時の語彙・表記に関するルール。漢字とひらがなの使い分けなど。

このドキュメントは、記事執筆時の語彙・表記に関するルールをまとめたものです。

漢字とひらがなの使い分け

「言う」と「いう」

「言う」は発話・会話の文脈でのみ使用する。それ以外の場合は「いう」とひらがなで表記する。

<!-- ✅ Good: 発話の文脈 -->

彼は「分かりました」と言った。
筆者が言うには、この方法が良いらしい。

<!-- ✅ Good: 発話ではない文脈 -->

ドキュメントをまとめるということではないかと筆者には思えます。
そういうことを考えると、別の方法が良いかもしれません。
〜というわけで、この方法を採用しました。

<!-- ❌ Bad: 発話ではないのに「言う」を使用 -->

ドキュメントをまとめると言うことではないかと筆者には思えます。

判断基準:

  • 誰かが実際に声に出して話している → 「言う」
  • 「〜ということ」「〜というわけ」「〜という形」など、説明や言い換えの表現 → 「いう」

「風に」と「ふうに」

「風に」「風な」と漢字で表記する。「ふうに」「ふうな」とひらがなで書かない。

<!-- ✅ Good -->

そういう風に考えると、別の方法が良いかもしれません。
そういう風な書き方をする場合は注意が必要です。

<!-- ❌ Bad -->

そういうふうに考えると、別の方法が良いかもしれません。
そういうふうな書き方をする場合は注意が必要です。

判断基準:

  • 「〜風に」「〜風な」「〜風だ」→ 漢字「風」を使用

好みの語彙

書き手が好んで使う語彙のリスト。同義の日本語表現がある場合でも、以下の語彙を優先的に使用する。

好む表現避ける表現
プラグマティック実用主義的

記号の使い分け

見出しの区切りには「: 」(半角コロン+スペース)

見出しで親子関係やdt+ddのような構造を表現する場合、「: 」(半角コロン+半角スペース)を使う。「 — 」(emダッシュ)や「:」(全角コロン)は使わない。

<!-- ✅ Good -->

## /batch: サブエージェントによる並列実行

## 具体例: 自分の /x-wt-teams スキル

## Agent Teams: 柔軟なエージェント協調システム

<!-- ❌ Bad -->

## /batch — サブエージェントによる並列実行

## 具体例:自分の /x-wt-teams スキル

## Agent Teams — 柔軟なエージェント協調システム

判断基準:

  • 見出しで「タイトル: 補足説明」のような親子・分類構造を表す → 半角コロン+スペース「: 」
  • emダッシュ「 — 」や全角コロン「:」は使わない

感想・主観表現の自動生成禁止

「面白かった」「良い感じ」「興味深い」などの感想・主観的な表現は、ユーザーの明示的な指示がない限り自動生成してはならない。AIが勝手に感想や評価を付け加えない。ユーザーのプロンプトに感想が含まれている場合のみ、その内容を反映して良い。

<!-- ✅ Good: 事実・結果のみを述べる -->

CSSの writing-mode: vertical-rl で台本レイアウトを再現できた。そのまとめ。
writing-mode がレイアウトシステム全体の挙動を変えるという点について整理する。

<!-- ❌ Bad: AIが勝手に感想・主観を付け加えている -->

結論としてはかなり良い感じに再現できたので、そのまとめ。
これが今回の調査で一番おもしろかったところ。
CSSの仕様として興味深いポイントだった。

判断基準:

  • 「面白い」「興味深い」「良い感じ」「嬉しい」「すごい」などの感想・評価 → ユーザーの明示的指示がない限り書かない
  • 結果の記述 → 事実のみを淡々と述べる
  • ユーザーのプロンプトに感想が含まれている場合 → その内容に基づいて書いて良い

「〜思う」の一人称表現の禁止

「〜だと思う」「〜と思う」のような一人称の主観表現は使わない。三人称的・客観的な表現に置き換える。「〜と考えられる」「〜と思われる」「〜だろう」などを使う。

<!-- ✅ Good: 三人称的・客観的な表現 -->

この挙動を理解した上でハイブリッド方式を採用するのが現実的だろう。
この挙動を理解した上でハイブリッド方式を採用するのが現実的であろうと考えられる。
この挙動を理解した上でハイブリッド方式を採用するのが現実的だろうと思われる。
論理プロパティを使う習慣があれば多少対処しやすくなると考えられる。

<!-- ❌ Bad: 一人称の主観表現 -->

この挙動を理解した上でハイブリッド方式を採用するのが現実的だと思う。
論理プロパティを使う習慣があれば多少マシなのだろうと思う。
個人的にはこの方法が良いと思う。

判断基準:

  • 「〜だと思う」「〜と思う」「〜だと思った」 → 使わない
  • 「〜だろう」「〜と考えられる」「〜と思われる」「〜であろう」 → これらの客観的表現に置き換える

重要性の強調表現の禁止

「ここからが実は大事な話で」「ここが一番重要な話」「ここがかなり大事なところで」のような、特定の箇所の重要性をAIが判断して強調する表現は使わない。記事は調査ノート・技術メモのトーンで、事実と手順を淡々と並べる。何が重要かの判断は読者(人間)に委ねる。

<!-- ✅ Good: 淡々と事実を述べる -->

削除のエッジケースについて見ていく。
次に、削除が絡むケースを確認する。
オフライン同期時のマージ挙動はこうなる。

<!-- ❌ Bad: AIが重要性を判断して強調する -->

ここからが実はもっと大事な話で。
ここが一番重要な話。
ここがかなり大事なところで、Y.jsのマージはGitとは根本的に違う。
実はこの部分が核心で。

判断基準:

  • 「ここからが大事」「一番重要」「実はもっと大事」「核心」「かなり大事」 → 使わない
  • 記事全体を調査ノート・技術メモのトーンで書く。感情的な盛り上げや重要度の演出はしない
  • 何が重要かはコンテンツの構成(見出し、順序)で自然に伝える

「マジで」は使わない

「マジで」は口語的すぎるため、記事中では使用しない。強調したい場合は「本当に」「実際に」など、文章として自然な表現に置き換える。

<!-- ✅ Good -->

本当に難しい問題だった。
実際にUIが壊れていた。
かなり手こずった。

<!-- ❌ Bad -->

マジで難しい問題だった。
マジでUIが壊れていた。
マジで手こずった。

判断基準:

  • 「マジで」「マジ」 → 使わない
  • 強調には「本当に」「実際に」「かなり」などを使う