はじめに — ペルソナ情報が6ファイルに散らばっていた
ZERONOVA LABには複数のコンテンツチャネルがあります。Journal（開発者向け技術記事）、Focus Blog（フリーランス向け記事）、X投稿、note記事、KDP書籍。それぞれにガイドラインのドキュメントがあり、それぞれに「著者のペルソナ」が記述されていました。
問題は、6つのファイルに同じようなペルソナ情報が重複して存在していたことです。AI協業の表現ルール、創作禁止ガイドライン、トーン＆ボイス。チャネルが増えるたびに同じルールを書き直し、更新のたびに全ファイルを修正する必要がありました。
ペルソナ情報が6ファイルに分散・重複していた。チャネルが増えるたびに（Focus Blog → Journal → X → note → KDP）同じルールを書き直すことになり、更新漏れ・矛盾が発生するリスクが高まっていた
2月13日の開発日記にこう書きました。この日、docs/author-persona.md を「著者ペルソナのSingle Source of Truth（唯一の原本）」として新規作成し、5つのドキュメントから約160行の重複情報を削除しました。
きっかけ — AI協業の表現ギャップ
ペルソナのドキュメント化を考え始めたきっかけは、2月8日のAI協業表現の改善作業でした。この判断に至った理由は「開発記事でAIとの協業をちゃんと書くことにした理由」にも書いています。
ZERONOVA LABは「AIネイティブ実験スタジオ」を掲げています。しかし当時の記事を読み返すと、AIとの協業がほとんど表現されていませんでした。「実装した」と書いてあるだけで、Claude Codeとどう協業したのかが見えない。
ブランドコンセプトと記事表現の一貫性は意識しないと乖離する: AIネイティブを掲げていても、技術ブログの慣例に引っ張られて「実装した」と書いてしまう。表現ガイドラインを明文化して初めて、記事レベルでコンセプトを体現できる
2月8日の開発日記にはこう書きました。技術ブログの慣例——「〜を実装した」「〜を設計した」——に引っ張られて、AIの関与が透明化されていたのです。
AI協業の2段階表現レベル
この問題を解決するために設計したのが、2段階の表現レベルです。
PM-AI 対話: 表現レベルの設計
ZeronovaZeronovaこの表現レベル設計が、後の著者ペルソナ定義書の核心部分になりました。
レベル1（言及） は全チャネルで推奨。「Claude Codeで実装した」「AIに別のアプローチを提案してもらった」のように、文中で自然にAIの関与を記述します。
レベル2（対話） はJournal記事で必須。意思決定の分岐点で、ZeronovaとClaude Codeの対話セクションを挿入します。PMが方針を示し、AIが具体案を提案する構図です。
2月8日に全38記事をレビューした結果、23記事は既にレベル1を満たしていました。この表現設計が60本以上の技術記事を2週間で書く基盤にもなりました。問題は「全く書いていなかった」のではなく「一部の記事で表現が薄かった」こと。レベル2の対話セクションは、devlogに記録された判断プロセスがある記事にのみ追加しました。
「PM ≠ エンジニア」の一貫性
著者ペルソナ定義書のもう一つの柱が、職種の一貫性です。
Zeronova はPM（プロダクトマネージャー）であり、エンジニアではありません。本業は「価値探索（Discovery）」——課題を見つけ、仮説を立て、優先順位を判断すること。AIを活用して実装（Delivery）まで完結させますが、実装そのものが専門ではありません。
この区別が重要な理由は、AIとの協業を隠すとブランドと矛盾するからです。「AIネイティブ実験スタジオ」を掲げている以上、AI抜きで実装したかのように書くことは不正確です。
定義書には具体的な表現ルール表を整備しました。
- 「PMとして課題を定義し、AIに実装を依頼した」→ OK
- 「実装した」（AIの関与が見えない）→ NG
- 「AIの出力をレビューして修正を依頼した」→ OK
- 「デバッグして修正した」→ NG（PM側の行動は「レビュー」と「判断」）
創作禁止ガイドライン
定義書の3つ目の柱が、創作禁止です。「事実でないことを事実として書かない」。全コンテンツチャネルに共通する絶対ルールです。
これが必要になったのは、AI（Claude Code）が文章を面白くするために、devlogにないエピソードを「補完」しようとすることがあるからです。
実施していないユーザーテストを「実施した」と書いたり、実際にはない会話を「こう言われた」と創作したり。AIの出力をそのまま公開すると、事実と異なる記述が混入するリスクがあります。
AI は文章を面白くするために、devlog にないエピソードを「補完」しようとすることがある。「事実でないことを事実として書かない」という原則を徹底するには、明示的なガイドラインが必要
具体的な禁止事項を表形式で列挙し、「予測・想定であることを明示する」書き方（「〜の可能性がある」「〜と考えた」）も示しました。
Single Source of Truth の実装
2月13日、これらのルールを1つのファイルに集約しました。
docs/author-persona.md は12セクション構成です。
- プロフィール基本情報
- コンセプト
- 経歴・実績（事実データの参照元を明記）
- 著者アイデンティティ（PM ≠ Engineer + 表現ルール表）
- AI協業ガイドライン（レベル1/2 + 対話フォーマット）
- 創作禁止ガイドライン
- トーン＆ボイス
- チャネル別適用ルール（Journal / Focus Blog / X / note / KDP）
- プライバシーガイドライン
- JSON-LD定義
- よくあるNG例
- 公開前セルフチェック（5項目）
PM-AI 対話: 集約のスコープ判断
Zeronovaauthor-persona.md に移すと、各ガイドラインの独立性が失われる。Zeronova> 詳細は docs/author-persona.md を参照 と一行の参照だけ残す。作成後、5つのファイルの重複ペルソナ情報を参照に簡素化しました。
- Journal仕様書 — AI協業ガイドライン（約90行）＋ 創作禁止ガイドライン（約57行）を参照に置換
- X投稿ガイドライン — ペルソナ定義（約19行）を参照に置換
- noteチェックリスト — 創作禁止セクション（約13行）を参照に置換
- KDP企画書 — 執筆ルール1〜4を参照に置換
合計約160行の重複を削除。今後ペルソナルールを変更する場合は author-persona.md の1ファイルだけ修正すればよくなりました。
「固有ルール」と「共通ルール」の分離が鍵: 各ガイドラインに残すのはチャネル固有のルール（例: Journal は devlog 引用必須、KDP はプロモーション回数制限）のみ。共通部分（ペルソナ、トーン、創作禁止）は全て参照に集約
双方向参照の設計
Single Source of Truthを機能させるために、もう一つ重要な設計がありました。双方向の参照です。
author-persona.md は経歴データの出典として eeat-seo-improvement-plan.md を参照しています。E-E-A-T改善の全体像は「E-E-A-T × SEO改善を個人開発サイトに実装した全記録」を参照してください。逆に、eeat-seo-improvement-plan.md にも author-persona.md への参照を追加しました。
A → B の一方向だけでは、Bを編集するときにAの存在に気づけません。双方向にすることで、どちらのファイルを編集するときも関連ファイルの存在に気づけます。
学んだこと
ドキュメントの重複は必ず矛盾を生む: 同じ情報を複数ファイルに書くと、更新のたびに「どこを直すべきか」を調べる手間が発生します。1ファイルに集約し、他のファイルは参照だけにする方が安全です。
「固有ルール」と「共通ルール」の分離が重要: 各チャネルには固有のルール（Journalはdevlog引用必須、KDPはプロモーション回数制限）があります。これらはチャネル側のドキュメントに残し、共通部分だけをペルソナ定義書に集約する設計が有効でした。
AIとの協業には明示的なガイドラインが必要: 技術ブログの慣例に任せると、AIの関与が透明化されます。表現レベルの設計、禁止事項の明文化、チャネル別の適用ルールを事前に定めることで、ブランドコンセプトとコンテンツ表現の一貫性を保てます。
双方向参照はドキュメント管理の基本: A → B の参照だけでなく、B → A の逆参照も設計しておくことで、変更時の影響範囲を把握しやすくなります。
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。