フィードバック→並列処理→レビュー→修正、全部で25分——3月4日の開発記録

<!-- KPI_REPORT period_start: 2026-03-04 period_end: 2026-03-04 pv: 0 revenue_total_yen: 0 revenue_template_yen: 0 revenue_consulting_yen: 0 ai_minutes: 25 no_ai_estimated_minutes: 360 -->

今日の結論

記事のフィードバック訂正、3ファイルの並列処理、3ファイルの並列レビュー、レビュー指摘のフィードバック修正。メタレビューのパターンID体系（AR-01〜AR-11）を導入した日に、この全サイクルが25分で回った。

1ファイルの編集・レビュー・修正が1人時（1人が1時間かける作業量）だとすると、3ファイル分で3人時。さらにレビュー指摘とフィードバック修正も3ファイル並列で行っているから、直列なら6時間以上かかる作業量だ。それが25分。Agent並列化の削減効果は、ファイル数が増えるほど段違いになる。

今日の最大トピック — メタレビューで「レビューの精度」を上げた

レビュー知見に番号をつけた

今日の中心作業は、レビューパターンの改善だった。

これまでの品質チェックには問題があった。「知見密度が低い」「再現性がない」といった指摘パターンは存在していたが、それぞれに番号（ID）がなかった。「どのパターンで引っかかったのか」を追跡できない。テストもできない。壊れた参照に気づけない。

改善した7項目:

1. パターンID付与: AR-01〜AR-10、CR-01〜CR-03、NZ-01 を全パターンに割り当て
2. 検出条件の定量化: 「知見密度が低い」→「50%以上のセクションに学べる内容がない場合」のように閾値を明記
3. 漏れ3件追加: AR-08（専門用語未補足）、AR-09（内部リンク欠如）、AR-10（コスト非開示）
4. 具体NG/OK例: RR-06に「頼んだ→出来た」（NG）vs「1機能を深掘り」（OK）を追加
5. 汎用/固有分離: series-structure-patterns.md を汎用法則と blog-with-ai 固有事例に分離
6. 守備範囲相互参照: review-patterns.md と series-structure-patterns.md の守備範囲を明記
7. Phase 2 Step 0追加: SKILL.md に直前記事の探索手順を具体化

要するに、「何が悪いのか」を言語化して、「どう検出するか」を数値で定義した。レビューが感覚ではなく仕組みで動くようになる。

レビュー3機 + テスト2機で検証した

改善後、3つのレビューAgent（品質・ワークフロー・悪魔の代弁者）で検証を走らせた。さらにテスト2機（レビュー検出テスト＋duo-writerワークフローテスト）で実動作を確認した。

結果、致命的1件と重要4件が見つかった。

致命的: RR-07が rewrite-rules.md で未定義（壊れた参照）。重要: Step 0の実行手順が曖昧、AR-09/AR-10が品質チェック未登録、CN-02に汎用法則なし、AR-08〜10の初出が曖昧。

全件修正し、テスト2機で再検証。レビュー検出テスト（記事06対象）では10パターン中6検出、閾値は概ね適切に機能した。

実践ログ

eyecatch コードレビュー対応

generate-eyecatch.js のコードレビュー指摘3件を対応した。

• frontmatter 区間限定: 正規表現が frontmatter 外にもマッチしていた → frontmatter区間のみに限定
• アトミック書き込み: 書き込み中にプロセスが落ちるとファイルが壊れる → write-then-rename パターンに変更
• CRLF保持: Windows環境の改行コードが書き込み後に変わる → 元ファイルの改行コードを検出・保持

duo-writerスキルテスト — 記事01リライト

改善したduo-writerスキルの実動作テストとして、記事01「コードを書けない自分が、プログラミングに触れた日」をリライトした。

v1結果: Pass 19 / Fail 1（T/A比率 23.9%）/ 要改善 3 ユーザーフィードバック: 年代修正（2022=ライター / 2023=閉鎖 / 2026=note再開→手作業増→プログラミング） v2結果: Pass 21 / Fail 2（T/A比率 19.7%、否定→肯定転換不足）

ここで気づいたのは、記事の質ではなく測定基準のほうに問題があったということだ。

新しく2つのパターンも発見した:

• AR-11: ナラティブ/体験記事は構造的にT比率が低くなる（タイプ別の許容範囲が必要）
• SG-01: dialogue-format.md に表情タグ仕様が未記載だった（14種のタグと制約ルールを追加）

25分計測の内訳

計測したのは、記事01の修正サイクル全体だ。人が1人で直列にやった場合の作業量（人時）と対比するとこうなる:

ステップ	内容	直列なら（人時）
1	フィードバック訂正（年代修正を記事に反映）	約0.5人時
2	3ファイル並列処理（ratio-guide.md、dialogue-format.md、記事修正）	約3人時
3	3ファイル並列レビュー（修正した3ファイルの品質チェック）	約1.5人時
4	3ファイル並列フィードバック修正（レビュー指摘を各ファイルに反映）	約1人時
合計		約6人時

これが25分で完了した。ポイントは、ステップ2・3・4のそれぞれで3ファイルを同時処理していること。1人時の作業を3つ並列で走らせている時点で、削減効果が段違いになる。

直列処理なら「編集→レビュー→修正」を3回繰り返す。並列処理なら「3つ同時に編集→3つ同時にレビュー→3つ同時に修正」で終わる。回数ではなく、同時性が効く。個人の体験レビューではあるが、「1人時×3並列」の構造は再現可能だ。

困った具体例（2ケース）

ケース1: T/A比率がナラティブ記事でハマった

• 状況: 記事01のリライトで、ユーザーフィードバックに基づき背景情報（2022年〜2026年の経緯）を追加した
• 困りごと: 背景追加でA（親しみやすい内容）の割合がさらに増え、T/A比率が23.9%→19.7%に悪化。ハウツー基準（35-45%）で見ると完全にFail
• 解消: ratio-guide.md にタイプ別の許容範囲を定義。ナラティブ記事はT 15-25%で合格とした
• 学び: 測定基準は記事タイプごとに変える必要がある。全記事に同じものさしを当てると、正しく書かれた記事まで不合格にしてしまう

ケース2: RR-07の壊れた参照

• 状況: SKILL.md の品質チェックで「RR-07（信頼性一貫）を確認」と指示されていた
• 困りごと: rewrite-rules.md を開くと、ルールは7つ存在するがどれにもIDがなかった。RR-07がどのルールを指すのかわからない
• 解消: rewrite-rules.md の全ルールにRR-01〜RR-07のIDを付与。SKILL.mdからの参照が正しく解決されるようにした
• 学び: ルールにIDがなければ、参照・テスト・デバッグのすべてが成り立たない。「番号のないルールは住所のない家と同じ」——見つけられないものは使えない

数値の見方

指標	値
AI作業時間	25分
非AI想定時間（直列）	360分（6人時）
削減時間	335分（5.6時間）
削減率	93%

93%の削減率は、並列処理の構造的な効果が大きい。1人時の作業を3つ同時に走らせ、レビューも3つ同時、修正も3つ同時。直列なら6人時かかる作業量を25分に圧縮している。個人の体験レビューではあるが、「並列数が増えるほど削減率が上がる」という構造は一般化できる。

失敗と改善

• 失敗: T/A比率の測定で、ハウツー記事の基準（35-45%）をナラティブ記事にそのまま適用してしまった。正しく書かれた記事に「不合格」の判定が出て、必要のない修正作業が発生した。合格するはずの記事を直すのは、時間だけでなく判断への信頼も削る
• 原因: ratio-guide.md にタイプ別の基準がなかった。ハウツーもナラティブも同じものさしで測っていた
• 対策: ratio-guide.md にタイプ別の許容範囲を定義（ハウツー: T 35-45%、ナラティブ: T 15-25%、比較/レビュー: T 40-50%）。記事を書く前にまずタイプを分類し、対応する基準を選ぶ手順にした

次の1歩

1. blog-with-ai シリーズ改稿: 08（知見密度スコアが最低）→ 06 → 05の順に、RR-01〜07 + AR-01〜11の品質チェックを適用しながら改稿する
2. 運用レポート×duo-writer形式の振り返り: この記事自体が初の実験。読みやすさ・情報密度のバランスを確認し、形が良ければシリーズ化する
3. キャラ素材サムネイル検討: カズハとテンのイラストをサムネイル・挿入図に使う仕組みを検討する

CTA

• 並列処理の具体的なやり方を知りたい人: Agent実践カテゴリの記事を読む
• 自分のブログでも運用レポートを書いてみたい人: このレポートの構造をそのまま使ってみる
• 個別に相談したい人: お問い合わせから申し込む