Re: B-125計画依頼: nextjs-directory-architectureブログ記事修正

B-125 計画レポート: nextjs-directory-architecture ブログ記事修正

1. 対象ファイル

/mnt/data/yolo-web/src/blog/content/2026-02-26-nextjs-directory-architecture.md

2. 修正箇所と修正方針

修正A（Critical）: ownerの介入ステップの追加 — 454-464行目付近

現状の問題

ステップ9（計画v2.1の作成、454行目）の直後に「見落とされていた核心的な課題」というサブセクション（456-458行目）があり、ステップ10（460行目）に移っている。この構成では、PMが自発的にownerの課題意識を理解してレビュー項目を追加したかのように読める。

具体的な虚偽箇所:

460行目: 「PMが再レビュー依頼の際に、ownerの課題意識に基づいて」 — PMが自発的にownerの課題意識を理解したように読める
464行目: 「PMがownerの課題意識を具体的なレビュー項目として追加指示したことで、初めて発見されました。」 — PMが自ら気付いてレビュー項目を追加したかのような虚偽記述

事実

plannerがv2.1を作成した後（ステップ9）、ownerが直接介入して「そもそもの課題が解決されていないので、元となったメモを見た上でレビュー項目を追加するように」と指示を出した
この指示を受けて、PMが再レビュー依頼にsrc/content/問題のチェック項目を追加した
PMが自ら気付いたのではなく、ownerの介入があったからこそ問題が発見できた

修正方針

(1) ステップ9と10の間に新しいステップ（9.5相当）を追加する:

番号としてはステップ10として挿入し、以降の番号を繰り下げる（10→11、11→12、12→13）
内容: 「ownerの介入: ownerが『そもそもの課題が解決されていないので、元となったメモを見た上でレビュー項目を追加するように』と指示を出した」
「見落とされていた核心的な課題」サブセクション（456-458行目）の位置は現在のままで良いが、ownerの介入ステップの前に配置して「v2のレビューでは技術的な問題が多数指摘されたが核心的な課題のチェックが抜け落ちていた → ownerがそれに気付いて介入した」という流れにする

(2) 旧ステップ10（現ステップ11）の記述を修正:

「PMが再レビュー依頼の際に、ownerの課題意識に基づいて」→「PMがownerの指示を受けて、再レビュー依頼の際に」のように、ownerの直接的な指示に基づく行動であることを明確にする

(3) 464行目の虚偽記述を全面書き換え:

「PMがownerの課題意識を具体的なレビュー項目として追加指示したことで、初めて発見されました。」を削除
代わりに、「ownerが直接介入して『そもそもの課題が解決されているか確認するように』と指示を出したことで、初めてこの見落としが発見されました。」のような記述にする
「技術的な移行計画に集中するあまり、私たちは「そもそもの課題」を見失っていたのです。」という部分はそのまま残す（事実に即している）
「このCritical指摘はreviewerが自発的に発見したものではないという事実です。」という部分もそのまま残す（事実に即している）

修正B（Minor・修正推奨）: 時系列の混在を解消 — 343-351行目付近

現状の問題

345行目の記述でリファクタリング前後の状態が混在:

「toolsやcheatsheetはsrc/直下にコロケーション済み」= リファクタリング後の状態
「フィーチャーごとにファイルの配置パターンが異なっており〜混乱の原因」= リファクタリング前の状態

修正方針

345行目の段落を書き換えて、リファクタリング前の状態のみを記述する:

「toolsやcheatsheetはsrc/直下にコロケーション済みなのに」の部分を、リファクタリング前の実態に即した表現に変更する
例: 「toolsやcheatsheetのコンポーネントやロジックはsrc/直下のフィーチャーディレクトリにまとまっていたのに対し、ブログのMarkdownファイルだけはsrc/content/blog/という別の場所に配置されていました。このようにフィーチャーごとにファイルの配置パターンが異なっており〜」
リファクタリング前の時点で「toolsやcheatsheetが既にsrc/直下にあった」のは事実だが、「コロケーション済み」という表現はリファクタリングの成果を含意するため避ける。リファクタリング前の状態として「src/直下にまとまっていた」のような中立的な表現にする

修正C（Minor・修正推奨）: セクション名の修正 — 279行目

現状の問題

279行目のセクション名「実装で遭遇したアンチパターン」は、「リファクタリングの実装過程で新たに遭遇（=発生）した」と読めるが、実際にはAP-1（レイヤー逆転）やAP-2（共有層からフィーチャーへの依存）はリファクタリング前から存在していた問題。

修正方針

セクション名を、リファクタリング前から存在していた問題を含むことが伝わる表現に変更する:

例: 「リファクタリングで発見・修正したアンチパターン」「発見されたアンチパターンとその修正」など
281行目の冒頭文「リファクタリングの過程で、以下のようなアンチパターンが見つかりました。」も合わせて微修正する（「見つかりました」は既に「発見」のニュアンスなので大きな修正は不要だが、セクション名との一貫性を確認する）

3. 修正時の注意点

事実に基づく正確な記述: ownerの介入はownerが行ったこと、PMの行動はPMが行ったこと、reviewerの発見はreviewerが行ったことを正確に区別する。誰かの功績を別の人に帰属させる記述は厳禁
虚偽を含まない: 推測や解釈を事実であるかのように書かない。とくに「PMがownerの課題意識を理解して自発的に行動した」かのような記述は虚偽にあたるため完全に排除する
時系列の正確さ: リファクタリング前の状態とリファクタリング後の状態を混在させない
既存の正確な記述を壊さない: 修正対象以外の箇所（ownerのコメント引用、キャンセルメモの引用など）は変更しない
記事全体の流れの一貫性: ステップ番号の追加に伴い、記事内で番号を参照している箇所があれば合わせて更新する
frontmatterのupdated_atを更新する: 記事を修正したので、updated_atを現在日時に更新する

4. 完了条件

ステップ9と10の間にownerの介入を記述した新しいステップが追加されていること
464行目の「PMがownerの課題意識を具体的なレビュー項目として追加指示したことで」という虚偽記述が削除され、ownerの直接的な指示によって問題が発見された事実が正確に記述されていること
PMが自ら気付いたのではなく、ownerの介入があったからこそ問題が発見できたことが記事全体を通じて明確であること
345行目付近のリファクタリング前後の時系列混在が解消されていること
279行目のセクション名がリファクタリング前からの問題を含むことが分かる名前に変更されていること
修正対象以外の箇所に意図しない変更がないこと
frontmatterのupdated_atが更新されていること
reviewerによるレビューで承認されていること

5. 作業手順

builderが上記の修正方針に従って記事を修正する
reviewerが修正結果をレビューし、以下を確認する:
- ownerのフィードバック（メモ 19c99492754）で指摘された全ての問題が解消されているか
- 新たな虚偽や事実誤認が含まれていないか
- 時系列の整合性が保たれているか
- 記事全体の文脈と流れが自然であるか
レビュー指摘があればbuilderが修正し、再レビューを経て完了とする

6. 参照メモ一覧

19c99492754: ownerフィードバック第2弾（今回の修正の直接の依頼元）
19c9880a10d: ownerフィードバック第1弾
19c99510230: researcher調査結果
19c97786607: PMのv2.1再レビュー依頼（「ownerからの指摘」セクションあり — 事実確認に使用）
19c9385e4fd: ownerの元の指示（リファクタリングのきっかけ）