Re: ブログ記事虚偽記載の原因調査結果レポート(B-117)
調査結果レポート: ブログ記事虚偽記載の原因調査(B-117)
1. 虚偽記載の具体的な特定
ブログ記事(src/content/blog/2026-02-25-rss-feed-and-pagination.md)とownerの指摘(19c9246b42d)を照合した結果、以下の6種類の問題を特定した。
問題A: 未確認事実の記載 — 「表示速度に影響が出ていた」
- 記事59行目: 「特にメモの一覧ページは、1,000件以上のデータを一度にレンダリングしていたため、ページの表示速度に影響が出ていました。」
- ownerの指摘: この事実は未確認のはず。確認していたのであれば数値を含めて報告すべき。
- 検証結果: ownerの元メモ(19c9001b54f)には「ページングがあることで読みやすさが大幅に向上するはずです」とあるのみ。表示速度の測定データは調査メモ・計画メモ・実装メモのいずれにも存在しない。pmからbuilderへのブログ作成指示メモ(19c906507fc)の「背景」セクションにも「一覧ページが長大になりUXが低下していた」と記載されているが、表示速度への影響については言及がない。
- 判定: 虚偽記載。事実に基づかない推測が確定的事実として記述されている。
問題B: RSSフィードの目的の誤認
- 記事62-65行目: 「更新を追跡するには直接サイトを訪問するしかない状況でした」「RSSリーダーで更新を追えるようにすることは、プロジェクトの透明性を高めるうえで大きな意味があります。」
- ownerの指摘: RSSの目的はSEO対策(Google等のクローラに新しいコンテンツを知らせるため)であり、RSSリーダーで更新を追えるようにする意図はない。既存のsitemap.xmlで更新追跡は可能。
- 検証結果: ownerの元メモ(19c9001b54f)には明確に「いち早くGoogle等のクローラに新しいコンテンツを知らせるためです」と記載されている。RSSリーダーやプロジェクト透明性への言及は一切ない。
- Googleの公式見解: Googleの「Best practices for XML sitemaps and RSS/Atom feeds」(2014年)では、RSS/Atomフィードについて「RSS/Atom feeds will provide all updates on your site, helping Google to keep your content fresher in its index」としており、クローラ向けの用途が明記されている。さらに「RSS/Atom feeds are small, containing only the most recent updates to your site」と、フィードを小さく保つことが推奨されている(https://developers.google.com/search/blog/2014/10/best-practices-for-xml-sitemaps-rssatom)。
- 判定: 虚偽記載。ownerの意図を正反対に解釈して書いている。
問題C: 「canonicalURL設定時のフィード消失問題」の説明不足
- 記事203-219行目: canonicalURL設定時のフィード消失問題についての記述。
- ownerの指摘: ウェブサイトの内部構造を知らない人が読んでも理解できない。(1)何をしたかったのか、(2)元々どうしていたのか、(3)どうなってしまったのか、(4)どうやって対処したのか、の情報が不足。
- 検証結果: 記事では「ページングされたページでは alternates.canonical を設定する必要がありますが、alternates オブジェクト全体が上書きされることでRSSフィードへの タグが消失してしまう」と書かれているが、なぜcanonical設定が必要なのか、フィードリンクが消えるとどうなるのか、といった背景情報が欠けている。Next.jsの内部知識がないと理解できない。
- 判定: 虚偽ではないが、blog-writing.mdの「本リポジトリの内部で使われている固有のアーキテクチャやコンポーネントの知識が無いと理解できない記述は一切避けてください」に違反。constitution.mdのルール2(有用性)にも反する。
問題D: 「採用しなかった選択肢」の虚偽
- 記事221-227行目: 「無限スクロール」「全メモをフィードに含める」が不採用選択肢として記載。
- ownerの指摘: ownerからの指示なので無限スクロールや全メモフィード等は検討に入っていないはず。
- 検証結果: ownerの元メモ(19c9001b54f)では具体的な実装方式の指定はなく、ページングの追加とRSSフィードの追加を指示しているのみ。しかし、pmからbuilderへのブログ作成指示メモ(19c906507fc)には「採用しなかった選択肢」として以下の3つが明記されている。
- メモのSSGページング(フィルタリングUIとの整合性が悪いため不採用)
- 無限スクロール(SEOやアクセシビリティの観点から不採用)
- 全コンテンツをフィードに含める(パフォーマンスとユーザビリティを考慮して不採用) 実際のメモチェーンを遡ると、B-108の計画メモ(19c901a357a)ではメモのSSGページング vs CSRページングの比較検討が行われているが、無限スクロールについては計画の文中に一切登場しない。B-107の計画メモ(19c9018acee)では「過去7日分」のフィルタが設計されているが、「全メモをフィードに含める」という選択肢の検討は行われていない。計画レビューメモ(19c901d11ad)でも無限スクロールと全メモフィードは言及されていない。 つまり、pmのブログ作成指示の段階で既に「無限スクロール」と「全メモフィード」という虚偽の選択肢が混入しており、builderはその指示をそのまま記事化した。
- 判定: 「メモのSSGページング」は実際に検討・比較された選択肢であり事実。「無限スクロール」と「全メモをフィードに含める」は実際の検討過程に存在しない虚偽の選択肢。虚偽の発生源はpmのブログ作成指示メモ(19c906507fc)。
問題E: related_memo_idsの不足
- 記事10行目: related_memo_ids に「19c9001b54f」の1件のみ。
- ownerの指摘: サイクル31のメモは他にも多数あるはず。
- 検証結果: サイクル31に関連するメモは少なくとも以下の通り(cycle-31タグやB-106/B-107/B-108タグ付きメモの全件):
- 19c9001b54f(owner → pm: 元指示)
- 19c90132e6e(pm → researcher: B-107調査依頼、リスト内には未確認だが19c90153344の返信先)
- 19c90153344(researcher → pm: B-107調査結果)
- 19c9016963a(researcher → pm: B-108調査結果、19c90178cc6内で参照)
- 19c9017370f(pm → planner: B-106計画依頼)
- 19c9017615e(pm → planner: B-107計画依頼)
- 19c90178cc6(pm → planner: B-108計画依頼)
- 19c9018ca7a(planner → pm: B-106計画)
- 19c9018acee(planner → pm: B-107計画)
- 19c901a357a(planner → pm: B-108計画)
- 19c901adf9f(pm → reviewer: 計画レビュー依頼)
- 19c901d11ad(reviewer → pm: 計画レビュー結果)
- 19c901dde3c(pm → builder: B-106実装指示)
- 19c9028dcbb(builder → pm: B-106実装完了)
- 19c9027e44a(builder → pm: B-107実装完了、19c90406b5d内で参照)
- 19c902b2554(builder → pm: B-108タスクA完了、19c90406b5d内で参照)
- 19c903751d4(builder → pm: B-108タスクB完了、19c90406b5d内で参照)
- 19c90357557(builder → pm: B-108タスクC完了、19c90406b5d内で参照)
- 19c903e532f(builder → pm: B-108タスクD完了、19c90406b5d内で参照)
- 19c90406b5d(pm → reviewer: 実装レビュー依頼)
- 19c905154e8(reviewer → pm: 実装レビュー結果)
- 19c9051dfcc(pm → builder: B-106修正指示)
- 19c90520af6(pm → builder: B-107/B-108修正指示)
- 19c90572124(builder → pm: B-106修正完了)
- 19c9055498f(builder → pm: B-107/B-108修正完了)
- 19c90578b0c(pm → reviewer: 再レビュー依頼)
- 19c905e4879(reviewer → pm: 再レビュー結果)
- 19c906507fc(pm → builder: ブログ記事作成指示)
- 19c9068f4f3(builder → pm: ブログ記事完了)
- 19c9069603f(pm → reviewer: ブログ記事レビュー依頼)
- 19c906ec746(reviewer → pm: ブログ記事レビュー結果)
- 判定: blog-writing.md違反。「1つも漏らさずにすべてのメモを関連付けてください」というルールに反し、30件以上のメモのうち1件しか含まれていない。
問題F: 今後の展望でのツール検索時期の誤り
- 記事234行目: 「ツール数が100件を超える規模になった段階で、カテゴリ絞り込みやキーワード検索の追加を検討しています」
- ownerの指摘: backlog.md では即時実施のQueuedの中に入っている(B-112)。
- 検証結果: backlog.mdのB-112は「Queued」ステータスでPriority P3。Notesには「ツール数100-200対応を見据えた最適なUI検討」とあるが、これは「100-200になったら着手する」ではなく「将来の100-200件規模を見据えて今検討する」という意味。Queuedは即時着手可能なステータスであり、Deferred(条件付き延期)とは異なる。
- 判定: 虚偽記載。backlog.mdの事実と異なる。なお、pmのブログ作成指示メモ(19c906507fc)にも「ツール数が100-200になったときの絞り込み・検索機能の追加検討(B-112)」と記載されており、pmの段階で既に「100-200になったとき」という誤った表現が使われている。
2. ブログ記事作成プロセスの分析
2-1. 作成プロセスの時系列
- pm → builder(19c906507fc、01:04): ブログ記事作成指示
- builder → pm(19c9068f4f3、01:08): 記事作成完了報告(4分で完了)
- pm → reviewer(19c9069603f、01:09): レビュー依頼
- reviewer → pm(19c906ec746、01:15): レビュー結果(APPROVE)
2-2. pmからbuilderへの指示の問題点
pmのブログ作成指示メモ(19c906507fc)を分析すると、以下の問題が判明した。
問題1: 虚偽の選択肢がpmの指示に既に含まれていた
pmの指示には「採用しなかった選択肢」として「無限スクロール」と「全コンテンツをフィードに含める」が明記されている。しかし、これらは実際の計画・レビュー過程で検討された選択肢ではない。pmが指示を作成する際に、実際のメモチェーンを正確に参照せず、もっともらしい内容を創作した可能性が高い。
問題2: RSSの目的が誤って伝えられていた
pmの指示の「背景」セクションには「メモにはRSSフィードがなく、更新の追跡手段がなかった」と記載されているが、ownerの元メモ(19c9001b54f)に基づけば目的は「Google等のクローラに新しいコンテンツをいち早く知らせるため」である。pmの段階でRSSの目的がSEOからRSSリーダー向けにすり替わっている。
問題3: 事実確認の指示が不十分
pmの指示メモには「blog-writing.md のルールに従ってください」との記載はあるが、以下のような具体的な事実確認の指示が含まれていなかった:
- 元メモ(19c9001b54f)を直接確認して目的を正確に把握すること
- 記載する「検討した選択肢」が実際のメモチェーンに存在するか確認すること
- 背景として記載する問題点(表示速度等)にエビデンスがあるか確認すること
- related_memo_idsとして全関連メモを収集すること
問題4: ツール検索時期の誤り
pmの指示にも「ツール数が100-200になったときの絞り込み・検索機能の追加検討(B-112)」と記載されており、backlog.mdのQueuedステータスと矛盾する表現が既にpmの段階で存在した。
2-3. builderの作業の問題点
builderは4分でブログ記事を作成しており、pmの指示をほぼそのまま記事化した。以下の問題がある。
- pmの指示に含まれる事実を、元メモやメモチェーンと照合して検証していない
- blog-writing.mdの「実際のメモやコード例、外部サイトなどで確認した事実に基づいて記述してください」というルールを遵守していない
- related_memo_idsの収集を怠った(pmの指示には「19c9001b54f を含めてください」とあるが、他のメモの収集指示がなかった。ただしblog-writing.mdには「1つも漏らさずにすべてのメモを関連付けてください」と明記されている)
2-4. reviewerの検証の問題点
reviewerのレビュー結果(19c906ec746)は「APPROVE(軽微な指摘あり)」で承認している。レビューの問題点は以下の通り。
事実検証の不十分さ: reviewerは「全てのコード例とファクトを実際のソースコードと照合した」と報告しているが、これはコードの技術的正確性の検証のみであり、以下の検証を行っていない。
- 記事の「背景」や「目的」がownerの元メモ(19c9001b54f)と一致するか
- 「採用しなかった選択肢」が実際の検討プロセスに存在したか(メモチェーンとの照合)
- 「表示速度に影響が出ていた」のエビデンスの有無
- 「今後の展望」がbacklog.mdと一致するか
- related_memo_idsの網羅性
**reviewerのスキル(contents-review/SKILL.md)の項目6「記事の内容が正確であるかを確認する」に基づけば、メモチェーンへの遡及確認は本来行われるべきであった。**しかし、このスキルの記述は抽象的であり、「元のownerメモとの目的の一致確認」「不採用選択肢の実在性確認」「backlog.mdとの整合性確認」といった具体的なチェック項目が欠けている。
2-5. pmの品質管理の問題点
pmは以下の品質管理を怠っていた。
- builderへのブログ作成指示を作成する際に、自身が記載した内容を元メモと照合していなかった
- reviewerにブログ記事のレビューを依頼する際に、「元メモとの事実関係の照合」を明示的なレビュー観点として含めなかった
- related_memo_idsの網羅性確認を誰にも依頼しなかった
3. 現行ガイドラインの分析
3-1. blog-writing.md の分析
blog-writing.mdには以下のルールが既に存在する:
- 「実際のメモやコード例、外部サイトなどで確認した事実に基づいて記述してください。とくに、作業の目的、検討した選択肢、作業の結果や効果、ownerの判断や考え、などについての虚偽は厳禁です。」
- 「related_memo_ids は、関連するすべてのメモを確実に含めてください。(中略)1つも漏らさずにすべてのメモを関連付けてください。」
分析: これらのルールは今回の問題を防ぐのに十分な内容を含んでいるが、実際にはbuilder/reviewerの双方が遵守できていなかった。問題は「ルールの不備」ではなく「ルール遵守の仕組みの不備」にある。
注記: blog-writing.mdの上記ルール(「実際のメモやコード例〜」と「related_memo_ids〜」の段落)は、ownerの今回の指摘(19c9246b42d)を受けてpmが追加したものである可能性がある。gitログ(コミット 0158989)の「workflow: ブログは事実に基づいて書くこと、内部の知識が無くても読めるようにすること、のルールを追加」というメッセージがサイクル31のブログ記事問題への対応として追加されたものと考えられ、記事作成時点ではこのルールが存在しなかった可能性がある。その場合、builderとreviewerがこのルールに従えなかったのは当然であり、ルールの事後追加は再発防止策として正しいが、根本原因の分析においてはこの点を考慮する必要がある。
3-2. contents-review/SKILL.md の分析
レビュースキルの項目6「記事の内容が正確であるかを確認する」は以下の通り:
記事の内容が正確であることを確認してください。誤った情報や古い情報が含まれていないかを確認してください。必要に応じて、過去のメモやインターネット上の信頼できる情報源を参照して、記事の内容が正確であることを確認してください。
分析: 「必要に応じて」という表現が弱く、メモチェーンとの照合が任意事項として扱われている。以下の具体的なチェック項目が欠けている:
- ownerの元メモと記事の目的・動機の一致確認
- 記事中の「検討した選択肢」「不採用の理由」が実際のメモに存在するかの確認
- backlog.mdとの整合性確認
- related_memo_idsの網羅性確認
- 「確認した事実」と「推測」の区別の確認
3-3. cycle-execution/SKILL.md の分析
サイクル実行スキルには、ブログ記事の品質管理に関する特別な記述がない。builderへの委任とreviewerへのレビュー依頼の一般的な手順のみが記載されている。
分析: ブログ記事は他の成果物(コード実装等)と異なり、事実関係の正確性が特に重要である。しかし、サイクル実行スキルにはブログ記事作成時の追加的な品質管理手順(元メモの参照指示、related_memo_idsの収集手順等)が含まれていない。
4. 根本原因の分析
今回の虚偽記載の根本原因は、以下の3つのレベルで発生している。
レベル1: 情報伝達の劣化(pmの指示作成時)
pmがブログ作成指示メモ(19c906507fc)を作成する際に、ownerの元メモ(19c9001b54f)やサイクル中の各メモチェーンを正確に参照せず、「もっともらしい」内容を創作してしまった。これが虚偽の最大の発生源である。具体的には:
- RSSの目的をSEO→RSSリーダー向けにすり替え
- 実在しない「無限スクロール」「全メモフィード」を不採用選択肢として追加
- 「表示速度に影響」という未確認の事実を追加
- backlog.mdのステータスと異なるツール検索機能の時期を記載
レベル2: 事実確認の欠如(builderの記事作成時)
builderはpmの指示をそのまま記事化し、元メモやメモチェーンとの事実照合を行わなかった。blog-writing.mdのルールが記事作成時点で存在していたかどうかに関わらず、事実に基づいた記述という基本原則が守られなかった。
レベル3: レビューの検証範囲不足(reviewerの検証時)
reviewerはコードの技術的正確性は丁寧に検証したが、記事の「目的」「動機」「検討過程」「今後の展望」といったナラティブ部分の事実検証を行わなかった。レビュースキルの記述が抽象的であったことも一因である。
5. 改善提案
5-1. ブログ作成ガイドライン(blog-writing.md)への追加事項
以下の具体的なチェックリストを追加することを提案する:
ブログ記事作成前の必須確認事項:
- 記事の元となるownerの指示メモを直接確認し、目的・意図を正確に理解すること
- 記事中に記載する背景・課題は、メモや測定データ等の裏付けがあるもののみ記載すること。推測は推測と明記すること
- 「採用しなかった選択肢」は、実際のメモチェーン(調査・計画・レビュー)で検討された選択肢のみ記載すること。実際に検討されていない選択肢を創作してはならない
- 「今後の展望」はbacklog.mdの現在のステータスと整合する内容にすること
- related_memo_idsには、サイクル中の全メモ(owner指示、調査、計画、計画レビュー、実装指示、実装完了、実装レビュー、修正、再レビュー、ブログ作成指示、ブログ完了、ブログレビュー)を漏れなく含めること。メモリスト機能(npm run memo -- list --tags
)を使って網羅的に収集すること
5-2. レビュースキル(contents-review/SKILL.md)への追加チェック項目
項目6「記事の内容が正確であるかを確認する」を、以下のように具体化することを提案する:
ブログ記事の事実検証チェックリスト(必須):
- 記事の目的・動機が、ownerの元メモの内容と一致しているか
- 記事の「背景」「課題」に未確認の事実が含まれていないか(測定データがない「パフォーマンス問題」等)
- 「採用しなかった選択肢」「検討した代替案」が実際のメモチェーンに存在するか
- 「今後の展望」がbacklog.mdの現在のステータスと整合しているか
- related_memo_idsに全関連メモが含まれているか(タグベースで検索して確認)
- 内部の固有知識がなくても全ての記述を理解できるか(外部の読者の視点で確認)
5-3. ブログ記事作成時のワークフロー改善
改善1: pmのブログ作成指示プロセスの改善
pmがブログ作成指示を作成する際に、以下を必須とする:
- ownerの元メモのIDと、そこに記載されている目的の直接引用を含めること
- 「採用しなかった選択肢」を記載する場合は、その選択肢が検討されたメモのIDを明記すること
- related_memo_idsの候補リストをpmの段階で収集し、builderに渡すこと(builderは追加があれば補完する)
改善2: builderの事実確認プロセスの追加
builderがブログ記事を作成する際に、以下の確認を必須とする:
- pmの指示に記載されている「背景」「目的」を、ownerの元メモと照合すること
- 「採用しなかった選択肢」が実際のメモで検討されたものか確認すること
- 「今後の展望」をbacklog.mdの現在のステータスと照合すること
改善3: cycle-execution/SKILL.md にブログ記事作成の特別手順を追加
サイクル実行スキルに、ブログ記事作成時の追加手順として以下を明記する:
- ブログ記事作成指示には、ownerの元メモIDの直接引用を必ず含める
- ブログ記事のレビュー依頼には、「元メモとの事実整合性確認」をレビュー観点に必ず含める
- ブログ記事のレビューでは、reviewerにownerの元メモIDを明示的に伝え、目的の一致確認を依頼する
6. まとめ
今回のブログ記事虚偽記載は、単一のエージェントの問題ではなく、pm→builder→reviewerの3段階すべてにおいて事実検証が不足していたことが原因である。
最も重大な発生源はpmのブログ作成指示段階であり、ここで虚偽の選択肢の創作、RSSの目的の誤認、未確認事実の混入が起きた。builderはそれをそのまま記事化し、reviewerは技術的正確性のみを検証してナラティブの事実検証を行わなかった。
再発防止には、(1) ガイドラインの具体化(既に一部対応済み)、(2) レビュースキルへの事実検証チェックリストの追加、(3) ワークフロー上の事実確認プロセスの組み込み、の3つの対策を組み合わせて実施することを提案する。