「PCでも大きい」「治った」「引き継ぎを上手く出来てない」――短いフィードバックを仕様変更へつなげた実例

長い仕様書より先に、短い一言が問題を確定した

Knowledge基盤の改修では、API処理や引き継ぎ設計を長く組み立てた後でも、実際に使った可児 波起の短い反応によって設計を変える場面がありました。

このとき重要だったのは、短い反応を「感想」として読み流さず、どの仕様が現実の使い方と合っていないかを示す入力として扱ったことです。

「PCでも大きくなってる」でTypography方式を変えた

最初は、CMS Rich Text内の固定font-sizeを一括解除し、Wix Editor側で調整できる状態にする方針でした。

しかし解除後、可児 波起は「文章にH2と段落が混じってる文章では、個別にフォントサイズを変更できない。PCでも大きくなってる」と指摘しました。

この反応を受け、「固定解除→Editor側で調整」という方式を続けず、CMS Rich Text内部へPC／スマホ別のレスポンシブfont-sizeを直接入れる方式へ変更しました。

「治った」は、仕様採用の確認になった

レスポンシブTypography適用後、可児 波起は「治った」と回答しました。

この一言は、全60ページ・全デバイス幅を網羅したテストではありません。

それでも、可児 波起が問題としていた表示については改善確認が得られたため、その方式を以後のKnowledge制作ルールへ採用する根拠になりました。

ここでは、「治った」を技術的原因の解明とは扱わず、対象としていた利用上の問題が解消したという人間確認として扱っています。

「引き継ぎを上手く出来てない」で引き継ぎ設計そのものを変えた

別の場面では、新規Knowledge量産を別の制作チャットへ移すために詳細な引き継ぎプロンプトを作成しました。

しかし可児 波起は「引き継ぎを上手く出来てない」と評価しました。

この指摘によって、最初の引き継ぎ方式を成功扱いせず、Project Sourcesを全文で読み直す方式へ設計を変更しました。

「メイン画像のトンマナが崩れたり」でHero工程まで変えた

引き継ぎ失敗の具体例として、可児 波起は「メイン画像のトンマナが崩れたり」と述べています。

その後の引き継ぎでは、単に16:9、白、ティール、フラットといった特徴を列挙するだけではなく、Hero画像詳細ガイドの全文読解、Hero生成直前の再読、画像制作の別工程化、記事固有の視覚的な核、直近3本との比較、生成後の自己検査まで追加されました。

つまり、1枚のHeroだけを修正するのではなく、次回以降の制作手順そのものを変更しています。

短いフィードバックには、少なくとも3つの役割があった

今回の記録では、人間の短い反応がすべて同じ役割だったわけではありません。

• 不具合報告：「PCでも大きくなってる」
• 採用確認：「治った」
• 方式全体への否定：「引き継ぎを上手く出来てない」
• 失敗箇所の特定：「メイン画像のトンマナが崩れたり」

同じ「フィードバック」でも、何を示しているかを分けることで、その後の処理も変えられます。

訂正を一回の回答修正で終わらせなかった

この運用で特徴的なのは、指摘された出力だけを直して終わらなかったことです。

Typographyの問題はTypography方式変更へ、引き継ぎ失敗はSource読解方式とHero制作工程の変更へ進みました。

元の採掘記録では、この動きを「人間の短い訂正を仕様変更要求として蓄積すると、運用ルールそのものが進化する」と分析しています。これは複数の実例から導いたAIによる整理です。

既存Knowledgeとの違い

既存Knowledge「『既視感』『滑ってる』『普通』の後、AIの次の候補が変わった」は、創作会話の中で短い否定を探索信号として使った実例です。

また、「完成作品より『違う』の瞬間に人物が出る」は、訂正ログを人物理解のEvidenceとして扱います。

本記事はそのどちらとも異なり、訂正をAI運用システムの仕様更新へ使った事例です。対象は作品案でも人物像でもなく、ワークフロー自体です。

再利用するなら、短い反応を6段階で処理する

長期AI共同作業でフィードバックを運用へ戻す場合、今回の実例から次の流れへ整理できます。

1. 記録：短い反応をそのまま残す。
2. 対象特定：何に対する反応かを明確にする。
3. 種別判断：不具合、否定、採用確認、要望のどれかを分ける。
4. 仕様へ翻訳：その場の修正で終えるか、恒常ルールを変えるか判断する。
5. 再実行：変更した方式で作業を行う。
6. 確認：人間の次の反応で採用・再修正を判断する。

この6段階は、元の複数事例を再利用可能な形へ整理したAIによる分析です。

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

短いフィードバックを仕様変更へ反映する方法が、他の利用者・他のプロジェクトでも同じ効果を持つかは確認していません。

また、Hero引き継ぎの再設計後に実際の品質がどの程度改善したかは、元の作業記録では未確認です。

確認できるのは、「PCでも大きくなってる」「治った」「引き継ぎを上手く出来てない」「メイン画像のトンマナが崩れたり」という短い反応の後に、Typography方式、引き継ぎ方式、Hero制作工程が実際に変更されたことです。

このKnowledgeの関連知識

創作中の否定フィードバックと比較： 「既視感」「滑ってる」「普通」の後、AIの次の候補が変わった――強い否定フィードバックの実例

既存記事は、その場の探索方向を変える否定フィードバック。本記事は、フィードバックを一度きりの出力修正で終わらせず、運用仕様そのものへ反映した例です。

引き継ぎ設計が変わった実例を見る： ルールをProject Sourceに保存しただけでは引き継げなかった――全文読解と実行直前の再読を工程化した

「引き継ぎを上手く出来てない」という短い指摘が、具体的にどの工程変更へつながったかを確認できます。

現在地： AI WORKFLOW → 判断基準・レビュー設計

Knowledgeトップを見る