目的
私がブログや同人誌の原稿を執筆するPCの執筆環境、および推敲手順についてまとめる。
私はこねくり回しながら執筆するため、エラー過多な文章になりがちである。そのエラーを取り除くのにいつも四苦八苦している。有能なライターならエラーがない文章を一発で書けるのかも知れないが、私には無理っぽい。そのため、なるべく人間の経験に頼るのではなく、機械を使ってエラー訂正をアシストしてゆくことを考えていた。
ところで、私は以前からアニメを語るPodcastに感想を投稿しており、その際に下記について注意してきた。
- 声に出して読める文章
- 冗長をなくした簡潔な文章（これは文字数制限があったため）
経験上この2点を注意するだけで、かなり文章は読みやすくて分かりやすいものになる。いきなり核心に触れるが、これが私の文章作成の根幹であるといってもいい。今回の推敲手順も、それを意識した形となる。
概要
コンポーネント
まず、執筆環境の全体像をつかむため、ハードウェア、ソフトウェアのコンポーネント図（＝構成図）について説明する。
基本的には、PC内にGitのローカルリポジトリを作成し、そのフォルダ内のMarkdown形式のテキストファイルをVS Codeを使って編集する。ローカルリポジトリで管理する事で、修正履歴を残せる。
前提として、執筆者は一人の想定である。もし、複数人で執筆するなら、きちんとGitサーバーを立てるべきであろう。
なお、ローカルリポジトリはDropboxなどのクラウドストレージ（G-Driveでも、OneDriveでもよい）に同期させている。これにより、複数のPCでシームレスに執筆できる。なんなら、スマホからも直接編集可能なので、出先で急に修正が必要な場合でも、簡単な編集ならできなくはない。
執筆環境の構成図を下記に示す。
執筆シーケンス
今回、執筆のターゲットとして、下記を想定している。
| No. | ターゲット | 特徴 | 備考 |
|---|---|---|---|
| 1 | はてなブログ | 個人で執筆。 | 私のブログ（＝本ブログ） たいやき姫のひとり旅 Markdown形式でもUPできる！ |
| 2 | 同人誌 | 私の原稿に対して校正が入る。 同人誌毎に校正ルールが存在する。 |
私がお世話になっているのは Fani通さん |
同人誌編集の部分は、私がお世話になっているFani通さんのスタイルで、GoogleスプレッドシートやGoogleドキュメントなどは、適宜置き換えてもらえばよいだろう。厳密には、マスターはExcelだとかの違いはあるが、便宜上執筆者目線で簡略化して記載している。要するに校正者が校正指摘をして、執筆者が確認し修正する、というループになっている。
この流れの中で重要なのは、推敲の部分である。私の書く文章は誤字脱字や、てにをはや、諸々のエラーがとにかく多い。そのため、エラー除去の工程を複数回設けているが、それぞれの推敲工程でメリット・デメリットがある。
概略シーケンス図では、推敲を経てはてなブログに記事UPする事になっているが、実際には記事の鮮度を優先して、執筆→記事UP→推敲→記事修正となるパターンが多い。
執筆のシーケンス図を下記に示す。
Markdownについて
Markdownは、文書の見出しや太字や表を全てテキストだけで記載して、HTML文書に変換する事ができる。画像やリンクも挿入可能。VS Code上ではテキストを入力しながらプレビュー画面にリアルタイムにレンダリング結果を確認できる。
Markdownのファイル拡張子は「.md」で、プレビュー表示するには、Ctrl+K → V とキーボードを押す。
ここでは、Markdown記法の詳細は省略するが、下記などを参考にして欲しい。
Gitについて
Gitはメジャーなバージョン管理システムである。そのメリットはファイルの修正履歴を残せることにある。
なお、最低限のGitの概念と操作についての説明は付録に記載したので、そちらを参照して欲しい。
インストール
前提OSは、Windowsとするが、使用するソフトウェアはMacでもLinuxでも動作するものである。適宜、読み替えていただきたい。
アプリケーション
環境作成に必要なアプリケーションを下記に示す。
これらのアプリケーションのインストールは、特に注意事項はないと思うので、インストールの詳細は省略する。
| No. | アプリケーション | 概要 | 入手元 | ダウンロードファイル | 備考 |
|---|---|---|---|---|---|
| 1 | Git for Windows | Windows用のGit | Git for Windows | Windowsのみ | |
| 2 | VS Code | 高機能な テキストエディタ |
Download Visual Studio Code - Mac, Linux, Windows | Windowsでどれか分からなければ、User Installerの64bit | |
| 3 | Chrome | Webブラウザ | Google Chrome - Google の高速で安全なブラウザをダウンロード |
VS Code拡張機能
VS Code拡張機能のインストール手順は、下記などのWeb情報を参考にしてほしい。
| No. | 分類 | VS Code拡張機能 | 概要 | 備考 |
|---|---|---|---|---|
| 1 | 日本語 | Japanese Language Pack for Visual Studio Code | メニューの日本語化 | |
| 2 | Markdonw | Markdonw All in One | Markdownの定番 | |
| 3 | Markdonw | Markdown Preview Enhanced | プレビューがリッチになる | |
| 4 | Markdonw | markdownlint | Markdownの書式チェック | |
| 5 | 日本語 | テキスト校正くん | 日本語文章のチェック |
Chrome拡張機能
Chrome拡張機能のインストール手順は、下記などのWeb情報を参考にしてほしい。
| No. | 分類 | Chrome拡張機能 | 概要 | 備考 |
|---|---|---|---|---|
| 1 | 音声合成 | テキスト読み上げ | テキストを日本語音声で読み上げる |
執筆手順
執筆
執筆は、普通にテキストディタで文章を心ゆくまで入力してゆくだけである。
ただし、一般的には後述の「テキスト校正くん」を執筆中にオンして、リアルタイムに校正指摘を表示して、適宜修正する事が多い。デメリットとして、エラー修正に気を取られ文章入力の勢いを妨げる事になること。今回は便宜上、執筆中はオフし、執筆後の推敲時にオンすることとする。
目視
- ポイント
- 「テキスト校正くん」による表記チェック
- メリット
- 簡単な誤字や全角半角の不適切など、一般的な日本語チェックができる
- ルールはカスタマイズ可能
- デメリット
- 人によりルールが合わないケースもあり
一般的には、目視は黙読によるチェックになると思うが、ここでは「テキスト校正くん」というツールを使ったチェックに特化して記載する。
「テキスト校正くん」による表記チェックにより、エディタ画面のエラー箇所に赤い波線が表示され、マウスカーソルを合わせるとエラー詳細が表示されるので、これを修正して赤い波線を消してゆく。
なお、「問題の表示」をクリックすると問題個所をインラインで表示し、「↑」「↓」で前後のエラー箇所にジャンプするので、積極的に活用する。
校正ルールは、設定画面でオンオフをカスタマイズできる。設定画面の呼び出しは「Ctrl＋,」で、検索ボックスに「テキスト校正くん」と入力する。
私は、ほぼデフォルトで使用しているが、下記の項目のみ文章スタイルが合わずにオフしている。
- 「外来語カタカナ表記の語尾の調音表記をチェックします」
見ての通り、私の原稿は意外とエラーで真っ赤なままである。「とくに」はひらかずに「特に」の方がいい、かと言って他の言葉はひらいて欲しい。普通は、エラー多発は精神衛生上良くないので、このルールをオフにしてしまうのがよいのだろう。しかし、心配性な私はとりあえず指摘だけしてもらって、エラーを残してゆくスタイルで進めている。1ドキュメント内のエラー上限もカスタマイズ項目にあるので、上限オーバーにも要注意である。
とは言え、長文で画面が真っ赤になるとそれなりにストレスになるため、集中して執筆したいときは、「テキスト校正くん」の拡張機能自体を一時的に無効にしている（本末転倒だが…）。
実際のところ、「に」が2回以上使われているとか、読点が4回以上使われているとか、一文が長い時にハマりそうなエラーを見ては文章を短くしたり表現を手直ししているのでかなり助かっている。
音読
- ポイント
- シンプルに音読して違和感のある所をつぶしてゆく。
- メリット
- 文章に対して、シリアルに集中するので、かなり細かく効果的にエラーを拾える
- 黙読だとスルーしがちな違和感も音読で拾える
- 例えば、文章の論理展開が途中でジャンプした
- 例えば、ネタとして切り出したものの、その後、使われずに取り残されている文章がある
- 例えば、あちこちに、冗長的に記載が点在している
- 例えば、1文が長すぎてカオスになっている
- デメリット
- 俗人的、かつ集中力が必要
- 声を出していい環境に限定される
まず言っておくと、私はこの推敲手順の中で「音読」が最重要ポイントだと考えている。
音読ではツールは使わない。自分で声に出して読みながらチェックする。これが、経験上、一番効果的にエラーをチェックできるという実感がある。
人間は黙読すると、音読よりも早く読めるものだが、それゆえエラーに気付きにくくなる。声を出せるスピードに落とし、シリアルに文章をなぞっていくところがミソである。
エラー箇所は読んでいて引っかかる。引っかかったところを中心に周囲の文章との関連も見極めつつ、文章が流れるように修正する。
ただ、音読は声を出せる環境と集中力が必要なので、できる作業環境が限られる。カフェでも呟きながら出来なくはないが、正直大声で読み上げた方が効果的である。近くで家族が寝ていているため、深夜に声を出しにくい状況とかもあるだろう。とはいえ、この辺りの制約をクリアして実施しておきたい手順ではある。
音声合成ヒアリング
- ポイント
- 音声合成された声を聞いて違和感のある所をつぶしてゆく
- メリット
- 音読では拾いきれない、思い込みエラーなどを拾える
- イヤホンを使う事で、声を出せない環境でもできる
- デメリット
- どうしても人間の発音とは異なる苦手ケースがあり、必ずしも万能ではない
1つは、音読が俗人的であるがゆえに、思い込みにより脳内で無意識にエラー補正して正しく読み上げてしまう事があるのだが、音声合成ヒアリングはこの手のエラーを拾える。経験上、このタイプのエラーはしばしば発生しており、馬鹿にできない。特に繰り返し音読していると、思い込みが強まるので、音読を過信せずに音声合成ヒアリングを使う。
もう1つは、イヤホンを使う事で声を出せない環境でも推敲できること。これで電車内など音読できない環境での、音読に近い推敲作業ができる。
デメリットとしては、残念ながら人間とは違う発音になってしまうケースがしばしばある。顕著なのは人名で、海夢（まりん）、新菜（わかな）、紗寿叶（さじゅな）などは流石に難しい。他にも苦手ケースはあるが、そこは音声合成エンジンによりまちまちである。音が変わってしまうと文章のリズムが変わってしまうので、この点については音読の方が優れる。
次に、音声合成ソフトの一覧とそれぞれの使い方について示す。
| No. | 音声合成 | アプリ | OS依存 | 音声データ （オススメ） |
特徴 |
|---|---|---|---|---|---|
| 1 | macOSのスピーチ | - | macOSのみ | Kyoko | VSCode上のテキストを 直接読み上げられる |
| 2 | Windows(Edge)の音声合成 | Edge | Windowsのみ | Microsoft Nanami Online(Natural) | 操作性が良い |
| 3 | Googleの音声合成 | Chrome拡張機能 (テキスト読み上げ) |
OS非依存 | Google 日本語 | 高い読み上げ精度 |
macOSのスピーチ
- macOSは音声合成ソフトを標準搭載しており、テキストを選択→Ctrl＋クリック→読み上げ開始、と操作するだけで読み上げてくれる。ショートカットキーを割り当てておくとなお良い。
- VS Code上だけでテキストの直接読み上げが完結するので、面倒がなく非情に便利。
- 設定画面は、「システム設定」「アクセシビリティ」「スピーチ」で表示する。
Windows(Edge)の音声合成
Windowsも音声合成ソフトを標準搭載しているが、使用できるのはEdgeのみである。EdgeはWebブラウザなので長文テキストも縦に長く表示するが、音声合成ヒアリングでは逆に全体が見通せて都合が良い。読み上げ中の文章は空色に、読み上げ中のワードは黄色に表示するため、読み上げ個所を把握しやすい。読み上げ中でも、読ませたい場所をクリックするとそこにジャンプできるので聞き直しも便利。ただし、操作中に、しばしば無応答になることがあった。
操作手順を下記に示す。
- Edgeを起動→Markdown形式のファイルをドロップ→右ボタンメニューの「音声を読み上げる」を選択、これで読み上げモードに入り、読み上げが始まる。
- 「音声オプション」を押すと、スピードと音声の選択ができる。音声はデフォルトの「Microsoft Nanami Online (Natural)」が良い。
Googleの音声合成
Google製の音声合成は、Chrome拡張機能「テキスト読み上げ」から使う。読み上げ精度の高さと、OS非依存である点が強みである。
注意点としては、しばらく使っているとGoogle CloudのText-to-SpeechのWebページで「SPEAK IT」ボタンを押し、「私はロボットではありません」をチェックしてサンプルデータを読み上げる必要がある。
操作手順を下記に示す。
- Chromeを起動→「拡張機能」→→「テキスト読み上げ」を選択
- 「Input text manually」を押す
- Markdown形式のテキストを丸ごとコピペする
- 「再生」ボタンを押すとテキストを解析して読み上げを開始する
- 歯車アイコンをクリックすると設定画面を表示する。
スペルチェックソフト
Googleドキュメントにより、スペル文法チェックを行う。ここまでかなり読み込んできているつもりでも、意外とエラーが残っている。ここが、最期の仕上げ的なチェックとなる。
なお、Microsoft Wordにもスペル文法をチェックするエディター機能があるが、Microsoft365、もしくはOneDriveのオンラインのWordのプレミアムエディターを購入する必要がある。私自身は未使用なため機能比較はできないが、購入済の人はこちらでチェックするのも良いだろう。
操作手順を下記に示す。
- Googleドキュメントを新規に開き、テキストをコピペする。
- メニューから「ツール」「スペルと文法」「スペルと文法のチェック」を選択
- 指摘箇所が左上に表示される。「承諾」もしくは「無視」を選択してゆく（決断せずに「＜」「＞」で前後の指摘に移動することもできる）
- 全選択して、VS Codeにテキストを戻す
統一校正基準チェック
- ポイント
- メリット
- 簡単なルールであれば一括置換
- デメリット
- 複雑なルールは目視で確認し、手動で修正する
- 校正基準通りにしたくない場合、やはり目視で確認し、手動で修正する
校正ルール
個人ブログでは気にしていなくても、同人誌側で独自に校正ルールを持つ場合が多い。一例として、下記に私がお世話になっている同人誌のFani通さんの統一校正基準（＝校正ルール）を示す。
| 記号 | 校正ルール | 置換 | 検索用 正規表現文字列 |
|---|---|---|---|
| - | 英数字は全角→半角 | 対応 | |
| （ア） | 句読点は「、」「。」。 | 対応 | |
| （イ） | 感嘆符・疑問符は「！」「？」（全角）。 | 対応 | |
| （ウ） | 感嘆符・疑問符の後ろには全角空白を入れる。 ただし記号の前後で文が繋がっている場合は空白を入れない。 |
ただし 以降 未対応 |
[！？][^ ] |
| （エ） | 括弧類は「（）」「［］」などすべて全角。 ただし括弧の中身がすべて半角の場合は半角括弧を使う。 「<」「>」（不等号）は半角だが、括弧として使う場合は「〈」「〉」（山括弧）に置き換える。 |
ただし 以降 未対応 |
（[ -~]*）|［[ -~]*］|｛[ -~]*｝|<[ -~]*> |
| （オ） | 括弧の直前直後にある句読点は、閉じ括弧の直後へ統一。 | 未対応 | [。、]）|[。、]（ |
| （カ） | 引用符は「‘」「’」「“」「”」の対を守る。 | 未対応 | ‘|’|“|” |
| （キ） | 「...」（三点リーダ）は 2 つ重ねる。 「・」（中黒）連続は三点リーダに置き換える。 「―」（ダッシュ）は 2 つ重ねる。 「─」（罫線素片のよこ）はダッシュに置き換える。 |
対応 対応 対応 対応 |
|
| （ク） | その他の記号のうち ASCII にある文字は半角。 | 対応 | |
| （ケ） | 複数の記号が絡む場合や固有名詞等は、上記基準に拘らず個別に判断する。 | 未対応 | ― |
校正ルール適用手順
校正ルールの中で（ウ）（エ）（オ）（カ）（ケ）は括弧の対のチェックなどであり、単純な置換では対応できないので、目視で確認する事になる。
校正ルール適用手順を下記に示す。
実際に、校正ルール置換スクリプトを実行した際の画面コピーを下記に示すが、置換しない方が良い箇所も置換されてしまう事があり、その場合は手動で置換を戻す。
置換後、検索用正規表現文字列で、該当箇所を検索し、修正が必要な場合は手動で修正する。
左端アイコン列の「検索」アイコンを選択し、検索文字列を入力し、入力エリアの右横にある歯車アイコン（＝正規表現で検索）をオンにする。プロジェクト内に該当ファイルが多すぎる場合は、「…」を押し、含めるファイル」で検索対象ファイルを絞り込む。検索結果をクリックすると、当該箇所にジャンプする。
付録
付録A. Git操作概要
Gitは、本来、チームで開発する際のバージョン管理ソフトである。しかし、私の執筆は個人作業でありチームで共有する必要がない。そのため、Gitサーバー（＝リモートリポジトリ）は存在せずPC内のローカルリポジトリに閉じている。また、いくつかの編集を並行して行うためのブランチという概念もあるが、ここでは説明しない。
とこでもいいので、PC内のファイルシステムに来歴管理する作業フォルダを決めてGitの初期化を行えば、そこがローカルリポジトリとなり、Gitを使い始める事ができる。作業フォルダにはいくつかのフォルダーやファイルが存在する。それとは別に、「.git」というGit専用のフォルダが初期化時に作成されて、そこに差分情報が蓄積される。ローカルリポジトリの概念図を下記に示す。
ファイルを編集しているだけでは履歴は残らない。履歴を残すためにはコミットする必要がある。まず、修正記録を残したいくつかのファイルを「git add」する。その後、メッセージを記入して「git commit」する。コミットの概念図と概略手順を下記に示す。
次に、操作例を下記に示す。
VS Code のターミナルの規定プロファイルの選択
コマンドラインからのGit初期化（実行例）
git init git config --global user.name tsukushi # 各自変更 git condig --global user.email tsukushi@xxxx.com # 各自変更 cat ~/.gitconfig # 設定内容確認 ls -al ~/.gitconfig # 設定ファイル確認
GUIからのコミット（実行例）
- 操作例として、新規に「aaa.md」ファイルを作成し、中身を記入する
- 左端アイコン列の「ソース管理」アイコンを選択し、ファイルを選択すると、差分が表示される（ソース管理アイコンの数値は、最終コミット時からの変化ファイル数）
- ファイル名の右の「＋」を押すステージに移動する（git addコマンドと同じ）
- エディットボックスにコミットメッセージを記入し、Ctrl+Enterを押す（git commitコマンドと同じ）
- 左端アイコン列の「エクスプローラー」アイコンを選択し、ファイルを選択すると、タイムラインにコミットメッセージが追加されている
- 更に追記して、「ソース管理」アイコンを選択し、ファイルを選択すると、変更差分が表示される。後は同じ要領
- 操作例として、新規に「aaa.md」ファイルを作成し、中身を記入する
付録B. 校正ルール置換スクリプト
校正ルール置換スクリプトとファイルの入出力の概要を下記に示す。
校正ルール置換スクリプト(fanitsu.sh)のソースコードを下記に示す。
#!/bin/bash
if [ $# -ne 1 ]; then
echo "一括正規表現置換スクリプト r1.01" 1>&2
echo "---" 1>&2
echo "$0 置換ファイル名" 1>&2
echo "（オリジナルは、「入力ファイル名.org」に退避されます）" 1>&2
exit 1
fi
IN_FILE=$1
ORG_FILE="$IN_FILE.org"
TMP_FILE="$IN_FILE.tmp"
# 置換文字列配列
sed_array=(
# 英数字は全角→半角
'y/ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺ０１２３４５６７８９/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/'
# （ア）句読点は「、」「。」。
'y/,./、。/'
# （イ）感嘆符・疑問符は「！」「？」（全角）。
'y/!\?/！？/'
# （ウ）感嘆符・疑問符の後ろには全角空白を入れる。
# ただし記号の前後で文が繋がっている場合は空白を入れない。※未対応【[！？][^ ]】
's/？ +|？ +/？ /g'
's/！ +|！ +/！ /g'
# （エ）括弧類は「（）」「［］」などすべて全角。
# ただし括弧の中身がすべて半角の場合は半角括弧を使う。 ※:未対応(無条件に置換)
# 「<」「>」（不等号）は半角だが、括弧として使う場合は「〈」「〉」（山括弧）に置き換える。※未対応【<.*>】
'y/\[\]\(\)\{\}/［］（）｛｝/'
# 'y/<>/〈〉/'
# （オ）括弧の直前直後にある句読点は、閉じ括弧の直後へ統一。※未対応【[。、]）|[。、]（】
# （カ）引用符は「‘」「’」「“」「”」の対を守る。※：未対応【‘|’|“|”】
# （キ）「…」（三点リーダ）は 2 つ重ねる。
# 「・」（中黒）連続は三点リーダに置き換える。
# 「―」（ダッシュ）は 2 つ重ねる。
# 「─」（罫線素片のよこ）はダッシュに置き換える。
's/・・・+/…/g'
's/…+/……/g'
's/─+/―/g'
's/―+/――/g'
# （ク）その他の記号のうち ASCII にある文字は半角。※全角化のため除外される記号は、「()?[]{}」→「（）？［］｛｝」。
'y/”＃＄％＆＊＋，－．／：；＜＝＞＠￥＾＿‘｜～/"#$%&\*\+,-\.\/:;<=>@\\\^_`|~/'
"y/’/'/"
# （ケ）複数の記号が絡む場合や固有名詞等は、上記基準に拘らず個別に判断する。※未対応
)
# 注意点
# (1) 下記の文字は、2度実行すると3段階に変化してしまう点に注意
# 「，．」→「,.」→「、。」
cp $IN_FILE $ORG_FILE
for ((i = 0; i < ${#sed_array[@]}; i++))
do
cp $IN_FILE $TMP_FILE
echo "${sed_array[$i]}"
cat $TMP_FILE | sed -r "${sed_array[$i]}" >$IN_FILE
done
rm -f $TMP_FILE