このブログの過去記事に、yomiyasu（よみやす）を適用しました。対象を調べると、記事の意味は通じても、「比較相手にモデルを置く」「Metalを使わない方に倒す」など、読者が意味を補う必要のある言い回しが残っていました。

既存22記事の112箇所を修正しました。元の記事に書かれた内容を保ち、日本語の説明だけを直しています。

yomiyasuは何をするものか

yomiyasuのSKILL.mdには、主語と述語の対応、曖昧な比喩、重複した説明、文同士のつながりを見直す手順が書かれています。単語を一括置換するツールではなく、AIが文章を推敲するときに使うAgent Skillです。同梱のPythonスクリプトは、見直し候補を検出するためのものです。

今回参照した版では、主張、評価の比重、言い切りの強さ、文の働きを変えないことが最優先になっています。「重要なのは」を見つけたら必ず削る、といった使い方ではありません。何が重要かを述べている文なら、その評価は残します。

用途別にはtech、business、essayがあります。今回は技術記事向けの仕様を中心に、AIが書いた技術説明を推敲しました。

何を直し、何を残したか

このブログでは、記事の指示はkazuph本人が出し、執筆はAIが担当しています。既存22記事すべてを対象にしました。TmuxPal、scrcpy、Finderも含みます。Zennから取り込む記事と、過去の発表スライドは対象外です。

記事をAIが執筆していても、全ての文章を変更してよいとは限りません。対象記事の中にも本人の依頼文や講評があります。また、ベンチマークで生成された小説や、他のAIの回答を原文として掲載した部分は、比較の資料です。これらも推敲しませんでした。

コード、コマンド、ログ、数値表、出題プロンプト、生成作品、画像やデモの参照先も保持しています。文章を読みやすくするために、過去の実験条件や結果まで変えてしまわないためです。

実際の修正前後

以下は今回の変更に含まれる原文と修正文です。

1. モデルと生成結果を区別する

出典 Gemini 3.5〜3.8 FlashとOpus 5の図解比較

元の文をそのまま読むと、ベンチマークで「Claude Opus 5を生成した」ようにも読めます。比較に使ったのはモデルそのものではなく、そのモデルの生成結果です。誰が何を生成したのかを直し、過去の結果を再利用したことも残しました。

2. 性格付けを、実装した内容に戻す

出典 Opus 5.5とAstraのISUCON講評

「速攻型」という性格付けを外しても、開始2分で複数の変更を入れたことから、作業の速さは伝わります。時間と実装内容は変えていません。

3. 障害の状態を具体的にする

出典 macOSの時計とDNSの復旧記事

この箇所は文頭の抜粋です。前後には名前解決の失敗を示すログがあるため、「壊れている」が何を指すのかを具体的に書けます。ログにない原因を追加したり、NTP通信全体の失敗と決めつけたりはしていません。

4. 不要な否定対比を整理する

出典 KarukanのMetalに関する説明

元の文が伝えたかったのは、単なる未対応ではなく、問題を避けるための意図的な選択だという点です。その理由は直前にも書かれているので、比喩を使わずに説明しました。

5. 「重要」を消さず、文の形を直す

出典 macOS復旧記事の切り分け方

「重要なのは」を単に削ると、著者が強調した判断まで消えます。重要性は述語に残し、比較する二つの失敗を短く書きました。

6. 評価の強さは変えない

出典 Grok 4.5、Opus 5、Gemini 3.5 Flashの図解比較

前置きと太字を削り、元の記事の「明らかに圧勝」という評価は残しています。「圧勝」を機械的に弱い評価へ置き換えるのも、意味の変更になります。

7. 本人のコメントはそのまま残す

出典 姫路城の講評（kazuph）

この文章は講評（kazuph）と明示されています。同じ記事にあるAIの講評は直しましたが、本人の言葉は触っていません。Karukanの記事にある感想の引用や、Sonnet 5の記事末尾の人間コメントも保持しました。

8. TmuxPalの検出対象を明記する

出典 TmuxPalのAI pane検出

直前には、コマンド名、pane title、process argumentを使って判定する説明があります。その結果として何を選ぶのかを明記しました。TmuxPalの記事では、このほか監視方法とキャッシュ期間など、計9箇所を直しています。最初の依頼文と実装方針の引用は変更していません。

9. scrcpyのランチャーが行うことを書く

出典 scrcpyをmacOSアプリにする説明

「薄い」「包む」ではなく、既存のscrcpyを起動するアプリだと書きました。scrcpyの記事では、実行ファイルの検索やログの説明など計6箇所を修正しています。コマンドと実行ログはそのまま残しました。

10. Finder連携の役割分担を書く

出典 Finderの画像貼り付けとKarabinerの役割

Karabinerがショートカットに反応してスクリプトを呼び出し、スクリプト側が貼り付ける内容を判定する、と役割を分けて説明しました。Finderの記事は計7箇所の修正です。通常のファイル貼り付けに影響する可能性と、別のショートカットを使う場合の注意は削っていません。

今回、どこで役立ったか

比較記事の導入では、何を比較に使ったのかを明記できました。実装や障害対応の説明では、比喩を具体的な動作や状態に置き換えられました。

一方、条件が整理された表、再現コマンド、すでに自然な説明まで作り直す必要はありませんでした。Liquid DOMの記事では、一つの言い回しだけを直しています。全記事を均一な文体に変えるよりも、引っかかる箇所を直す方針です。

リンターは「解像度」など、技術用語として必要な言葉にも反応します。また、出題文や引用にある表現まで検出する場合があります。警告は見直し候補として扱い、文章の意味と掲載目的を確認しました。

読み速度や理解度の読者テストは行っていません。そのため、「可読性が何％向上した」といった効果は示していません。今回確認できたのは、実際にどの文章をどう変え、何を保持したかです。

新しい記事に使うときも、最初に本人の文章や引用を除きます。そのうえでAIが書いた技術説明を推敲し、原文との差分を確認する。この順序なら、言い回しを整える作業と、著者の判断や実験記録の保持を両立できます。