Zenn技術記事の校正スキル

指定された記事ファイルを読み込み、以下のガイドラインに基づいて校正を行い、修正案を提示します。

著者ペルソナ

記事は以下の人物像で書かれていること。校正時もこのペルソナから逸脱していないか確認する。

•55歳の個人事業主プログラマ。 組み込みがメインだが、Windowsアプリ・Linux・スマホアプリも経験あり
•新しい技術には興味を持ってすぐ手を出すタイプ。 AIもその一つとして淡々とスキルを蓄積している
•AI驚き屋ではない。 「革命的！」「すごい！」のような煽りは書かない。淡々と事実と所感を述べる
•せっかくなので共有する、というスタンス。 教えてやる感や布教感は出さない
•Web系はトレンドを追っているが広く浅い。 HTML/CSSべた書きの頃からやっている古参だが、最新フレームワークに精通しているわけではない
•Linuxも出始めから使っている。 Docker等は使ってはいるが深くはない
•ベテランの落ち着き。 若手エンジニアのような興奮や誇張はなく、長年の経験に裏打ちされた淡々とした語り口
•OSSや他者のツールへのリスペクト。 自分が作ったわけではないものを「構築した」「作った」と書かない。fork・導入・設定した場合はその旨を正確に書き、開発者の手柄を正しく帰属させる
•自分のシステムの限界も認める。 自分の環境が最強という書き方はしない。属人的な構成であれば素直にそう書く。比較対象の良い点も公平に評価する

校正の重点項目

1. トーンと文体の確認

文体は「ですます調」を使用

•記事全体を「ですます調」で統一する
•「だ・である調」は使わない
•例: 「〜です」「〜ます」「〜でした」「〜ました」

先回りして書いた感のある表現を避ける

•❌ 「次のような疑問を持つ方もいるかもしれません」
•❌ 「という反論もあるでしょう」
•✅ 「ここまで理解して、気になったのが〜」
•✅ 「さらに疑問が湧いてきました」

AIっぽい表現を避ける

•❌ 「あなたの」「あなたが」
•❌ 「〜いるんです」「〜だったんですね」（砕けすぎ）
•✅ 自然な日本語で、主語を明示しすぎない

不自然な主語の繰り返しを避ける

•❌ 「私は思いました」「私は疑問に思いました」
•❌ 「筆者は〜しました」「筆者にとっては」（三人称主語も同様）
•❌ 「合同会社花丸福は」のような固有名詞を主語として前面に出す
•✅ 「ここで気になったのが」「さらに疑問が湧いてきました」
•✅ 日本語では主語を省略して文脈から読ませるのが自然

感情の過度な表現を避ける

•❌ 「感動しました」「驚きました」
•✅ 淡々と事実を述べる

押し付けがましい断定を避ける

•❌ 「理解できるはずです」
•✅ 「見えてくるかもしれません」

仰々しい表現を避ける

•❌ 「新しい地平を切り開く挑戦です」（自分が作ったわけではないツール）
•✅ 「バージョン管理に対する考え方が変わりました」

2. 冗長性のチェック

冗長な前置きを削除

•❌ 「ここで気になったのが〜という点です。確かに〜があります。しかし調べてみると〜」
•✅ 「〜がありますが、以下の点で異なります」

不要な説明文を削除

•❌ 「次のようにします」「このように〜使えば」
•✅ コード例だけで意味が通じる場合は説明不要

「調べてみると〜わかりました」を簡潔に

•❌ 「調べてみると〜ことを設計思想の中心に据えていることがわかりました」
•✅ 「〜を設計思想の中心に据えています」

3. 太字の適切な使用

太字にすべきもの

•重要な技術用語の初出
•本質的な違いや特徴
•表内の対比項目

太字にすべきでないもの

•「重要なポイント:」「重要な注意点:」などのラベル
•説明文中の普通の名詞（「Git側でのブランチ名」など）
•対比を示すだけの文（「Gitにもgit reflogがありますが」など）

4. 記事の構成

個人の学習体験として書く

•自分が発見した順序で説明する
•「先回りして答える」のではなく「自分が疑問に思った流れ」で展開

「人に勧める」トーンではなく「自分の判断を共有する」トーン

•❌ 「〜という疑問が湧くかもしれません」
•✅ 「〜が気になりました」「ここで気になったのが〜という点です」
•❌ 「結論から言えば」「〜する必要はありません」
•✅ 「検討した結果」「〜しないことにしました」
•❌ 「推奨環境」「〜する価値があります」
•✅ 「向いている環境」「〜と思いました」「〜について考えてみる」
•❌ 「現実的な選択肢」「〜で問題ありません」
•✅ 「自分が考えた選択肢」「〜することにしました」

不要な感想を削除

•まとめの後に追加の感想文は不要
•要点はまとめセクション内で完結させる

実体験を入れる

•具体的な体験談を含めることで読者の共感を得る
•例: 「私自身、何かあるたびにcommitしてpushする習慣があり...」

防衛的な表現を避ける

•❌ 「なぜこれが『新しい地平』なのか」（コメントへの反論に見える）
•✅ 「squashとの本質的な違い」（中立的）

事実を簡潔に述べる

•不要な「私にとって」などの主観的フレーズを削除
•事実だけを述べれば十分

5. Linter指摘への対応

textlint-jaからの指摘

textlintコマンドを実行して指摘を確認（必須）

bash

npx textlint "記事ファイルパス"

•日本語の文法、表記ゆれ、冗長表現などの指摘に対応する
•技術用語の表記統一を確認する
•不自然な助詞の使用を修正する
•
「述語 + コロン（：）」パターン: AIっぽい英語直訳表現を避ける
- •❌ 「以下のようにする：」「次の通り：」
- •✅ 「以下のようにする。」「次の通り。」「重要なポイントは以下の通り。」

markdownlintからの指摘

•Markdown構文の問題を修正する
•見出しレベルの適切な階層構造を確保する
•コードブロックに言語指定を追加する
•リストの書式を統一する
•空行の適切な配置を確認する

校正の手順

•記事ファイルを読み込む - 指定された記事の全内容を確認
•Linterを実行 - npx textlint "記事パス" を実行して指摘を確認（最優先）
•Linter指摘に対応 - textlint-jaの指摘をすべて修正
•全体を通読 - 記事全体の流れとトーンを確認
•トーンの一貫性 - 先回りした感じやAIっぽい表現がないかチェック
•冗長性の確認 - しつこい前置きや不要な説明を削除
•太字の見直し - 本当に強調すべき箇所だけに絞る
•構成の確認 - 個人の学習体験として自然な流れになっているか
•最終確認 - 不自然な箇所や内容の密度バランスをチェック
•Linter再実行 - 修正後に npx textlint "記事パス" で検証

6. コンテンツの正確性

事実と違う記述をしない

•誰の判断だったか、誰がやったかを正確に書く
•AIが勝手にやったことと、人間が意図的に決めたことを混同しない
•インシデントの経緯は記録に基づいて正確に

死んでいるリンクは貼らない

•外部URLは実在確認できるもののみ
•アクセスできないURLはテキストのみにするか削除

他の記事と被る内容はリンクで飛ばす

•同じ話を2箇所で詳しく書かない
•「詳細は別記事に書いた」＋リンクで済ませる

専門用語は脚注でなくかみ砕いた表現に置き換える

•脚注を入れると記事の重要ポイントがぼける
•用語そのものを避けて平易な表現にする
•どうしても必要な場合は文中で軽く説明

7. 記事の締め方

不安で終わらない

•❌ 「これが今の正直な状態です」（読後感が悪い）
•✅ 前向きな一文で締める

数字は表で見せる

•箇条書きの羅列より、表の方が一覧性が高い
•対比（Before/After）がある場合は特に有効

8. 内部情報のフィルタリング

読者に関係ない技術詳細は書かない

•❌ Notion DB IDの違い（database_id vs data_source_id）
•❌ 設定ファイルのJSON構造の詳細
•✅ 「設定ミスで通知が届かなかった」程度の抽象度

一言感想をこざかしくしない

•❌ 「自動化は便利だけど、制御が本質だな」（悟った風）
•❌ 「〜と痛感しました」（大げさ）
•✅ 自然な感想。困ったなら「困った」、面白いなら「面白い」

注意事項

•個人ブログの記事であることを念頭に置く
•教科書やドキュメントではなく、学習の記録として
•読者に教えるのではなく、自分の発見を共有する姿勢で
•校正の最初と最後に必ずtextlintコマンドを実行する
•textlint-jaの指摘は必ずすべて対応する（エラー0にする）
•修正は一度にすべて行い、Edit toolで反映させる