ルールをProject Sourceに保存しただけでは引き継げなかった――全文読解と実行直前の再読を工程化した

最初の対策は、ルールを会話の外へ出すことだった

Knowledge制作ルールは、最初は会話の中で積み上がっていました。

可児 波起の依頼を受け、「海辺の部屋｜Knowledge憲法 Version 1.0」として50条＋最終チェックへ整理し、Knowledgeの目的、Blogとの分離、Direct Answer、Evidence、Sources、Typography、Breadcrumb、Pillar、Cluster、Relation、Index、Hero Image、Featured、urlKey、標準制作フロー、Quality Gateなどを明文化しました。

その後、憲法はProject Sourceへ追加され、1194行のファイルとして全文検索・読取できることも確認されています。

「保存できた」ことと「引き継げた」ことは同じではなかった

ルールをProject Sourceへ外部化した後、新規Knowledge量産を別の制作チャットへ移すため、詳細な引き継ぎプロンプトが作られました。

しかし可児 波起は、その結果について「引き継ぎを上手く出来てない」と明確に評価しました。

具体例として挙げられたのが、「メイン画像のトンマナが崩れたり」です。

失敗原因は、この記録だけでは特定していない

この時点で確認できるのは、詳細な引き継ぎを書いたにもかかわらず、可児 波起がHero画像のトンマナ崩れを認識したことです。

なぜ崩れたのかについて、元の作業記録では原因を一つに確定していません。

モデル差、Source参照不足、実画像比較不足などの可能性は分析候補として挙げられていますが、どれが主因だったかは未確認です。

対策を「もっと長いプロンプト」にしなかった

引き継ぎ失敗後に行った変更は、ルール文をさらに長く書き足すことではありませんでした。

代わりに、Project Sourcesの使い方そのものを工程へ組み込みました。

1. 制作開始時：Knowledge憲法、Admission Gate、Hero画像詳細ガイドを全文で読む。
2. 本文制作：記事本文とCMS作業を進める。
3. Hero直前：Hero画像ガイドをもう一度全文で読む。
4. Hero専用工程：本文を書き終えた勢いで、そのまま画像生成へ進まない。

Source検索と全文読解を分けた

新しい引き継ぎ設計では、Sourceが存在することを確認するだけでは不十分としました。

検索で該当Sourceを特定した後、全文を読み、内容を確認してから作業へ進む流れへ変更しています。

元のネタ帳では、これを「検索 → 特定 → 全文読解 → 確認報告」という工程として整理しています。

さらに「実行直前の再読」を追加した

特にHero画像ルールは、チャット開始時に一度読ませるだけではなく、画像生成の直前に再読するよう変更されました。

これは「保存されたルールを知っている状態」と「これから行う作業の直前に、その制約を再び入力へ戻す状態」を分けた設計です。

長いAI作業では、開始時と実行時の間に本文制作、CMS更新、Relation設計など多くの工程が入るため、重要な視覚ルールだけを直前に再注入する方式へ変わりました。

Hero制作そのものも独立工程にした

第2版の引き継ぎでは、「本文を書き終わった勢いで、そのまま画像を生成しない」と明記されています。

生成前には「この記事にしか使えない視覚的な核は何か」を文章で一つ決め、可能なら直近3本の成功したHero実画像と比較するルールも追加されました。

比較対象は、同じシルエット、タイトル位置、カード配置、矢印、抽象図などです。

生成後にも自己検査を置いた

Hero生成後には、少なくとも次の確認を行うルールが作られました。

• タイトルを隠しても記事内容を推測できるか。
• 別記事へタイトルだけ差し替えて成立しないか。
• 直近3本と同じに見えないか。
• 写真風、広告風、企業資料風になっていないか。
• 情報過多になっていないか。

既存Knowledgeとの違い

既存Knowledge「AI作業を別スレッドへ引き継ぐとき、成果物だけでなく『作業状態』を渡す」は、対象、ID、実行済み内容、失敗、未確認、次工程など、引き継ぐ情報の中身を扱っています。

本記事の問いは別です。

情報を保存し、引き継ぎ文にも書いたのに実行時の出力へ十分反映されなかった経験から、Sourceをいつ・どの深さで読み戻すかをワークフローへ組み込んだ実例を扱います。

この事例から言えるのは「保存」と「利用」を分けること

この作業記録から直接確認できるのは、Source化した後にも引き継ぎ失敗が起き、その後に全文読解・直前再読・専用工程・比較・自己検査を追加したことです。

「実行直前に再読すれば必ず品質が上がる」と一般化できる比較実験はありません。

ただし、長いAIワークフローの設計として、ルールを保存する工程と、そのルールを必要な作業直前に読み戻す工程を分離したことは確認できます。

このKnowledgeで確認できないこと

再設計後の新しい制作チャットで、Heroトンマナが実際にどの程度改善したかは、元の作業記録では未確認です。

また、最初の引き継ぎが失敗した主因が、Source参照不足、モデル差、プロンプト構造、実画像比較不足のどれだったかも確定していません。

確認できるのは、50条のKnowledge憲法をProject Sourceへ保存して全文読取可能にした後でも引き継ぎ失敗が報告され、その後に「開始時の全文読解」と「Hero生成直前の再読」を含む工程へ変更したことです。

このKnowledgeの関連知識

引き継ぐ内容そのものを見る： AI作業を別スレッドへ引き継ぐとき、成果物だけでなく「作業状態」を渡す

既存記事は「何を渡すか」を扱い、本記事は保存されたルールを「いつ・どの深さで読み戻すか」に焦点を当てます。

Heroの固定要素と可変要素を見る： AI画像でブランドを統一しながら、ワンパターン化を防ぐ方法

引き継ぎ失敗の具体例だったHeroトンマナを、固定するデザイン言語と毎回変える構図へ分ける既存Knowledgeへ接続します。

再読するSource自体の正本・旧版を整理する： AI向けProject Sourcesは増やすだけでは整理できない――正本・旧版・補助資料を分けた実例

全文読解と直前再読を工程化した次に、どのSourceを正本として読むのか、旧版をどう扱うのかを整理します。

現在地： AI WORKFLOW → 長時間作業・状態引き継ぎ

Knowledgeトップを見る