Re: B-117 虚偽記載の再発防止策実施計画

実施計画: B-117 虚偽記載の再発防止策策定

調査結果（メモ19c925e1301）およびPMからの計画依頼（メモ19c925f4cf0）に基づき、以下の実施計画を策定しました。

計画の概要

修正対象は3ファイルです。修正の方向性は「ルールの不備を補う」のではなく「ルール遵守を確実にする仕組みを組み込む」ことです。blog-writing.mdには既にownerが追加したルールがあるため、重複を避けつつ具体的な手順を補強します。

タスク1: .claude/skills/contents-review/SKILL.md の修正

修正の目的

レビュアーが「何を検証すべきか」を具体的に把握できるよう、項目6の事実検証を具体化する。現状は「必要に応じて」という任意表現になっており、メモチェーンとの照合が確実に行われていない。

修正内容

項目6「記事の内容が正確であるかを確認する」の本文を以下のように改訂する。

現在の記述（30-32行目）:

記事の内容が正確であることを確認してください。誤った情報や古い情報が含まれていないかを確認してください。必要に応じて、過去のメモやインターネット上の信頼できる情報源を参照して、記事の内容が正確であることを確認してください。

改訂後の構成:

既存の概要文は残しつつ、その下にブログ記事向けの事実検証チェックリストをサブセクションとして追加する。

追加するチェックリスト（必須項目として記載）:

ownerの元メモと記事の目的・動機が一致しているか確認する（元メモIDはレビュー依頼メモに記載されている）
記事中の「背景」「課題」に、メモや測定データ等の裏付けがない未確認事実が含まれていないか確認する
「検討した選択肢」「採用しなかった選択肢」「不採用の理由」が、実際のメモチェーン（調査・計画・レビュー）に存在するか確認する。実際に検討されていない選択肢が創作されていないか注意する
「今後の展望」がbacklog.mdの現在のステータスと整合しているか確認する
related_memo_idsに全関連メモが含まれているか、npm run memo -- list --tags <タグ> を使って網羅的に確認する
確認できた事実と推測が明確に区別されているか確認する
本リポジトリの内部知識がなくても全ての記述を理解できるか、外部の読者の視点で確認する

注意事項

項目1-5の既存の記述は変更しない
チェックリストは「ブログ記事の場合」という条件付きのサブセクションとする（他の種類のコンテンツレビューに過度な負担をかけない）
「必要に応じて」という表現は使わず、「必ず確認してください」という必須表現にする
チェックリストの各項目には「なぜその確認が必要か」の簡単な理由を添える（例: 「pmの指示段階で内容が変質する可能性があるため」）

完了条件

項目6にブログ記事向けの事実検証チェックリスト（7項目）が追加されている
既存の項目1-5, 項目6の概要文が維持されている
日本語として自然で簡潔な表現になっている

タスク2: .claude/skills/cycle-execution/SKILL.md の修正

修正の目的

サイクル実行のワークフローにブログ記事作成時の品質管理手順を組み込む。根本原因であるpmのブログ作成指示段階での情報変質を防ぐための具体的な手順を明記する。

修正内容

現在の「## 作業の進め方」セクション（ステップ1-4）と「## 作業が完了したら」セクションの間に、新しいセクション「## ブログ記事の作成」を追加する。

追加するセクションの構成:

「## ブログ記事の作成」

ブログ記事は通常の実装作業とは異なり、事実関係の正確性が特に重要であるため、以下の追加手順に従うこと。

手順1: ブログ作成指示の作成（pmの責務）

ownerの元メモIDを明記し、そこに記載されている目的・意図を直接引用する形で「背景」を記載すること
「採用しなかった選択肢」を記載する場合は、その選択肢が実際に検討されたメモのIDを併記すること。メモチェーンに存在しない選択肢を創作してはならない
「今後の展望」を記載する場合は、backlog.mdの該当タスクのステータスを確認し、整合する内容にすること
related_memo_idsの候補リストを、npm run memo -- list --tags <サイクルタグ> を使って収集し、builderに渡すこと

手順2: builderへの指示

builderには、pmの指示内容だけでなく、ownerの元メモIDを渡し、元メモを直接確認して事実を照合するよう指示すること
blog-writing.md のルールに従うことを明示すること

手順3: レビュー依頼

reviewerへのブログ記事レビュー依頼には、以下を必ず含めること:
- ownerの元メモID（目的の一致確認のため）
- 「元メモとの事実整合性確認」をレビュー観点として明記
- サイクルのタグ（related_memo_idsの網羅性確認のため）

注意事項

既存の「## 作業の進め方」セクションと「## 作業が完了したら」セクションの内容は変更しない
新セクションは両セクションの間に配置する（作業完了前の手順として自然な位置）
ブログ以外の記事（将来追加される可能性のあるコンテンツ）にも適用できるよう、「ブログ記事やその他のコンテンツ記事」という表現にすることも検討する

完了条件

「## ブログ記事の作成」セクションが追加されている
pmの指示作成、builderへの指示、レビュー依頼の3つの手順が明記されている
既存セクションが維持されている

タスク3: .claude/rules/blog-writing.md の修正

修正の目的

既にownerが追加した事実確認ルール（コミット0158989）を活かしつつ、具体的な手順を補強する。重複は避け、既存ルールを支える手順として追加する。

修正内容

現在のblog-writing.mdの内容を確認した結果、以下の2点の強化が必要です。

強化1: related_memo_idsの収集手順の具体化（61-63行目付近）

現在の記述:

related_memo_ids は、関連するすべてのメモを確実に含めてください。これらのメモには、 researcher, reviewer, planner, builder や、それらを中継するPMのメモ、場合によっては元となるownerのメモなどが含まれるはずです。 1つも漏らさずにすべてのメモを関連付けてください。

この記述の後に、具体的な収集手順を追加する:

npm run memo -- list --tags <サイクルタグ> を使って該当サイクルの全メモを取得し、IDを収集すること
タグが複数ある場合は（例: B-106, B-107, B-108 など個別タスクタグ）、それぞれのタグで検索して網羅すること

強化2: 事実確認ルールの具体例の追加（33行目付近）

現在の記述:

実際のメモやコード例、外部サイトなどで確認した事実に基づいて記述してください。とくに、作業の目的、検討した選択肢、作業の結果や効果、ownerの判断や考え、などについての虚偽は厳禁です。確定情報ではない推測を書くときは、推測であることを明確にしてください。

この記述の後に、具体的な確認手順を補足として追加する:

記事の「背景」「目的」は、ownerの元メモを直接確認して記述すること。pmの指示メモだけに依存しないこと
「採用しなかった選択肢」は、実際のメモチェーン（調査・計画・レビュー）で検討された選択肢のみ記載すること
「今後の展望」は、backlog.mdの該当タスクのステータスを確認して整合する内容にすること
パフォーマンスや速度への影響など、測定が必要な主張は、測定データがある場合のみ確定的に記述すること

注意事項

ownerが追加した既存のルール文言は変更しない（コミット0158989の内容を尊重）
追加する内容は「手順」「補足」であり、ルール自体の重複にならないようにする
箇条書きで追加し、簡潔に保つ（過度に冗長にしない）

完了条件

related_memo_idsの収集に npm run memo -- list コマンドの使用手順が追加されている
事実確認の具体的な手順が補足として追加されている
既存のルール文言が維持されている
blog-writing.mdの全体の分量が過度に増えていない（追加は10行程度に収める）

作業の進め方

builderに上記3ファイルの修正を依頼する（1つのタスクとして依頼可能。3ファイルはすべて関連する変更のため）
reviewerに修正結果のレビューを依頼する。レビューの観点:
- 既存のルールとの重複がないか
- 追加内容が簡潔で明確か
- 日本語として自然か
- 今回の調査結果で判明した根本原因（pm→builder→reviewerの3段階の問題）がすべてカバーされているか
レビュー結果に基づいて必要に応じて修正する

全体の完了条件

3ファイルすべての修正が完了し、レビューを通過している
修正内容が調査結果の根本原因（レベル1: pmの情報変質、レベル2: builderの事実確認欠如、レベル3: reviewerの検証範囲不足）のすべてに対応している
既存のルールとの重複がない
過度に冗長にならず、実用的な内容になっている