MANIARUの記事を増やす前に、AIを使って既存記事の品質を見直しました。最初から全記事を書き換えるのではなく、代表記事を監査し、基準を作り、一記事だけ改善してから再監査する流れです。
この方法で重視したのは、文章が自然かどうかだけではありません。初心者が「理解する」「同じことを試す」「成功したか確認する」ところまで進めるかを分けて確認しました。
この記事では、AIに記事を一度で完成させてもらうのではなく、監査役と改善役を分けて品質を上げた実例をまとめます。
記事数を増やす前に、初心者として読み直す
既存記事には、実際に試した内容や判断理由が書かれていました。一方で、書き手には分かっている前提を、読者も補完できるとは限りません。
- 何を作る記事か、冒頭で分かるか
- WordPressのどこを操作するか分かるか
- コードをどこへ置くか分かるか
- 掲載例だけで中心動作を再現できるか
- 成功・失敗を読者自身が判断できるか
そこで、AIへ単純な校正を頼むのではなく、「初めてMANIARUを読む初心者」という視点を与え、読者が止まる場所を探す監査から始めました。
最初は代表3記事だけ監査する
初回監査では、すべての記事を細かく読み直しませんでした。WEB、CODE、PROJECTから、性質の違う代表記事を一つずつ選びます。
- WEB：設定場所や画面の説明が必要な記事
- CODE：実際のコードと動作条件を含む記事
- PROJECT：実験の流れと判断理由を記録した記事
記事の種類が違えば、初心者が止まる場所も違います。まず少数を深く見ることで、共通問題と記事タイプ固有の問題を分けました。
この段階では記事を変更しません。監査と修正を同時にすると、問題の全体像を把握する前に部分的な書き換えが始まり、基準が記事ごとに変わってしまうためです。
AIの指摘をA・B・Cへ分ける
AIに「改善点を出して」とだけ頼むと、細かな言い換えや追加案が大量に出ることがあります。そこで、問題の大きさを3段階に分けました。
| 優先度 | 意味 | 例 |
|---|---|---|
| A | 再現を止める | 実行場所がない、必要な変数がない、成功判断ができない |
| B | 再現できるが初心者には難しい | 環境差や操作場所の説明が弱い |
| C | あるとさらに良い | 補足画像、追加コメント、軽い可読性改善 |
指摘には「どこが問題か」「なぜ読者が困るか」「どう直すか」を付けます。点数だけでは修正の順番を決めにくいため、総合点は使いませんでした。
監査結果を共通の品質基準へ変える
代表記事の監査から、MANIARUの記事を確認する10の観点を整理しました。
- WHAT：何をする記事か
- BEFORE：作業前はどうなっているか
- WHY：なぜ必要か
- WHERE：どこを操作するか
- HOW：どう進めるか
- WHY THIS：なぜその設定やコードか
- RESULT：何が変わったか
- CHECK：成功をどう判断するか
- TROUBLE：実際に起きた問題は何か
- LEARN：試して何が分かったか
これらを毎回10個の見出しとして並べるわけではありません。記事の内容に応じて、読者が自然にたどれる構成へ落とし込みます。
本文画像も枚数では決めず、BEFORE、WHERE、SETTING、RESULT、TROUBLE、COMPAREのどの役割を持つかで判断します。「一記事に何枚」ではなく、文章だけで同じ状態へたどり着けるかを基準にしました。
一記事だけ改善して、基準を試す
基準を作ったあと、CODE記事の スクロール位置に合わせて目次を切り替える記事へ適用しました。
最初の改善では、コードを書く場所、本文見出しと目次リンクの関係、必要な変数、MANIARU固有部分と汎用部分、結果画像、コード表示を整理しました。
ここで「改善したから完了」とせず、今度はJavaScriptを少し触ったことがある初心者として再監査します。制作者の知識で不足情報を補完せず、記事だけで実行できるかを順番に確認しました。
再監査で、最小例の条件不足が見つかった
再監査では、本文の説明とコード表示は改善できていました。しかし、掲載した最小例にA問題が一つ残っていました。
スクロール位置に応じて目次を切り替える例なのに、デモページの高さが足りないと十分にスクロールできません。さらに、ページ最下部で最後の項目をactiveにする補正があるため、短いページでは初期表示から後方の見出しが選ばれる可能性がありました。
コードの構文は成立していても、中心動作を確認する条件がサンプル内にありません。そこで、実行場所、HTML・CSS・JavaScriptの組み合わせ、十分な縦方向の長さ、初期・中間・最下部の成功状態を、最小例の周辺だけに追加しました。
この経験から、最小コードは「エラーなく動く」だけでなく、「紹介する動作を実際に確認できる」ことまで必要だと分かりました。
監査と修正を分けると、直す範囲を絞れる
今回の流れは、次の5段階です。
- 代表記事を選び、変更せず監査する
- 共通問題を品質基準へまとめる
- 一記事だけ基準に沿って改善する
- 別の読者条件で再監査する
- 残ったA問題だけを最小修正する
監査だけの段階ではWordPressを変更しません。修正時も、A問題が最小例の条件不足なら、タイトルやカテゴリー、記事全体を作り直さず、該当範囲に絞ります。
AI作業が途中で区切られる場合は、監査結果、採用した基準、完了済みの修正、残った問題を分けて記録します。再開方法は、AI作業を途中から安全に再開する記録でまとめています。
最後の判断は人が行う
AIは、観点に沿った確認、記事間の比較、抜けの列挙、同じ条件での再監査を繰り返す作業に向いていました。一方で、指摘をすべて採用するわけではありません。
- どの読者を想定するか
- 記事の目的は解説か実験記録か
- どの問題を公開前に直すか
- 実際に行ったことと提案をどう分けるか
- 最終的に公開できる品質か
これらは、サイトの目的と実体験を知る人が判断します。AIの役割は答えを決めることではなく、同じ基準で見落としを探し、判断材料を整えることでした。
一度の生成より、監査できる流れを作る
AIで記事を作るとき、一度の指示で完成形を出すことに集中しがちです。しかし、読者条件を変えて読み直すと、書き手側では気づきにくい前提不足が見つかります。
監査する。基準へ変える。一記事で試す。再監査する。残った問題だけ直す。
この順番にしたことで、AIの提案を無制限に反映せず、初心者の再現を止める問題から改善できました。記事の品質を一度で決めるのではなく、確認できる工程として残す方法です。