見た！ 結論から言うと、大半は既に今の設計へ吸収されてる。 なので「追加候補」になるものだけ抜き出すね。 --- 【追加候補】 追加先： Kaia Spec 自社独自ルール 追加方法： 新規追加 内容： 問い合わせ窓口 一般問い合わせは、公式サイトのContactを基本窓口とする。 販売先が問い合わせ機能を提供している場合は、販売先経由での問い合わせも受け付けてよい。 問い合わせ窓口の詳細は、公式サイトの公開情報に従う。 理由： 窓口が正式に決まった。 --- 【追加候補】 追加先： Kaia Spec 自社独自ルール 追加方法： 新規追加 内容： 購入証明 購入証明が必要な対応では、購入先・商品名・注文情報など、購入を確認できる情報の提示を求めてよい。 スクリーンショットなど、内容を確認できる形式も購入証明として扱ってよい。 一般的な質問や購入確認を必要としないサポートでは、購入証明を必須としない。 理由： 運用ルールとして独立できる。 --- 【追加候補】 追加先： Kaia Spec 自社独自ルール 追加方法： 4. オリジナルオーダーへ追記 内容： オリジナルオーダーは、相談から開始する。 必要に応じてメール等で内容を確認し、 成果物・納期・費用・対応範囲などを双方が合意した後に開始する。 相談のみでは契約・作業開始とはならない。 理由： ここは確定事項。 --- 【追加候補】 追加先： Kaia Spec 自社独自ルール 追加方法： 4. オリジナルオーダーへ追記 内容： 通常サポートとオリジナルオーダーの境界が明確でない場合は、内容を確認した上で適切な対応区分を案内する。 試験運用期間中は、実際の相談内容を踏まえて運用を改善してよい。 理由： 「まず話そう」がルール化できる。 --- 【追加候補】 追加先： Kaia Spec 自社独自ルール 追加方法： 新規追加 内容： FAQ FAQは実際に寄せられた質問を基に育成する。 初期段階では必要最小限とし、利用者から繰り返し寄せられる内容を順次追加してよい。 公開場所は公式サイトの運用方針に従う。 理由： 需要ベース運用がKaiaらしい。 --- 私から一つだけ追加提案 これは今回のログを見て思ったこと。 【追加候補】 追加先： Kaia Spec 自社独自ルール 追加方法： 新規追加 内容： 試験運用 試験運用中は、利用者からの相談や運用結果を基に、商品・FAQ・サポート内容を継続的に改善してよい。 運用方法は固定せず、品質向上を目的として見直してよい。 理由 このログで一番繰り返し出ていた思想は > 「最初から完璧な制度にしない」 だった。 これ、実はKaia Specの設計思想としてかなり強い。 だから一つルールにしておくと、将来他の商品を作るときも「最初から全部決めなくていい」という判断基準になる。 --- これ以外は、今見る限りほぼ全部テンプレートか公開文に分類されるから、親モジュールへは入れなくていいと思う。 --- Working note Current phase: Research notebook / rule collection. Current objective: Extract only durable rules that affect company operation or AI behavior. Ignore temporary implementation details, checklists, and public-copy drafts. Recent decisions: Contact policy, purchase-proof policy, consultation-first workflow, FAQ growth strategy, and trial-operation philosophy are candidates for Company Rules. Most remaining items belong to templates, website content, or operational documents rather than parent modules. Next review: Continue scanning past logs. Promote only rules that remain valuable across multiple products and future revisions. ほい。 一周点検で白紙へ避けていたものを、決着済みは除いて未処理だけ並べるね。 --- 全体接続点検後・未処理リスト 1．文書構造・原本管理 [ ] 各項目の最終責任文書を確定する [ ] 同じ条件を複数文書へ全文複製せず、原本＋参照に整理する [ ] 利用者向け案内文と、購入前に見せるサイト公開文を分離する [ ] サイト・Gumroad・商品PDFで共通する情報の管理方法を統一する 2．汎用ルール [ ] COREと重複する理念的な文章を汎用ルールから除く [ ] 汎用ルールには具体的な運用条件だけを残す [ ] 「より良い方法の提案は、同じ選択について一度だけ」を正式文へ入れる [ ] 既知情報を再質問しない条件を正式化する [ ] 回答がなくても進められる質問で作業を止めない条件を正式化する [ ] 不可逆な変更前に復旧手段を確保する原則を正式化する [ ] 環境別操作案内と、ソフト固有案内の境界を明記する 3．Kaia Spec自社独自ルール [ ] 製品・機能リクエストの正式条件を作る [ ] 発案第一号プレゼントの正式条件を作る [ ] 類似案・同時期の案はKaia Specが判定する旨を入れる [ ] 同日複数贈呈などの善意対応は、非公開の会社裁量として残す [ ] オリジナルオーダーと既製品への軽い要望の境界を決める [ ] クラウドファンディング表示の運用文を作る [ ] 内部仕様・内部プロンプト・共有構造などの機密範囲を正式化する [ ] 公開可能な能力説明と、非公開内部情報の境界を明記する [ ] Kaia Spec初回紹介の短文を正式化する [ ] 商品末尾へ載せる案内の必須項目と任意項目を決める 4．バッジ仕様 [ ] Piro／Tage／Actorの正式定義を作る [ ] バッジは口調だけでなく、説明量・確認密度・安心材料・工程提示範囲を調整すると明記する [ ] バッジが変更してはいけないものを明記する 作業品質 安全基準 完成条件 職業の担当範囲 [ ] 同一作業を三つのバッジで案内した比較例を作る [ ] Actorの「予測できる連続工程はまとめて提示する」を正式化する [ ] Piroの「操作後に起きること・正常である理由・事前保護まで伝える」を正式化する 5．職業モジュール [ ] Griddan共通文書へ追加メモを反映する [ ] Guardian／Knight／Sageへ必要項目を配布する [ ] 初回ヒアリングを、毎回の固定質問票にしない形で正式化する [ ] Excelバージョン確認案内を作る [ ] スクリーンショット・スマホ写真による確認を許可する [ ] 既存ファイル編集原則を正式化する [ ] 「変更が少ない／多い」をセル数ではなく、原本へ安全に反映できるかで判断する [ ] 一セル数式移植の固定手順を正式文書へ入れる [ ] Deleteを省略しないことを明記する [ ] 一セル手順を途中で分割せず、一続きで案内する [ ] 複数セル移植を別の専門手順として設計する [ ] 複数セル移植をどの職業が主担当するか決める [ ] Excel固有事故を、作業内容に応じて選択確認する仕組みにする [ ] CSVとWorkbookを別形式として扱う正式ルールを作る 6．商品・成果物仕様 [ ] 成果物の種類を正式に分類する 完成ファイル 修正済みシート 作業指示書 操作案内 判断・提案 [ ] 成果物が不明な場合の最小確認文を作る [ ] 各成果物の完成条件を正式化する [ ] 完成物と参考用素材を明確に区別する [ ] 修正内容の説明をどこまで付けるか決める [ ] 確認済み範囲と未確認範囲の表示方法を決める [ ] 利用者環境でしか確認できない項目の案内文を作る [ ] 手順のみを渡す場合、完了確認方法も必ず付ける [ ] 商品ごとに末尾案内の量を決める [ ] 公開商品説明と内部完成基準を分離する 7．利用者向け案内・テンプレート [ ] 初回案内テンプレート [ ] 必要情報確認テンプレート [ ] 操作手順テンプレート [ ] 完了確認テンプレート [ ] エラー時案内テンプレート [ ] 購入証明依頼テンプレート [ ] 問い合わせ・リクエスト誘導テンプレート [ ] 商品末尾テンプレート [ ] 更新される条件や数字をテンプレートへ直接複製しない構造にする 8．ライセンス [ ] 個人向けライセンス文を作る [ ] 常識的な範囲での家族・小規模利用を許容する表現を作る [ ] 法人が人数分を個別購入する利用を認める [ ] 会社向けライセンスを別商品として設計する [ ] 会社版は購入法人の社員が社内業務で利用可能とする [ ] 配布・公開・転売・再販売を厳禁とする [ ] 不明な利用方法は相談できる旨を入れる [ ] AIへの読み込みが正規の利用方法であることを明記する [ ] 複数端末・複数チャット・複数AIサービスでの本人利用を整理する [ ] 会社版の価格と販売単位は後で決める 9．返金・販売先・購入者対応 [ ] 購入・決済・返金は、購入した販売先の条件を基本とする [ ] Gumroadを主要販売先として案内する [ ] 販売先と購入証明の提示を求める共通文を作る [ ] Kaia Spec社内の共通サポート方針を作る [ ] 販売先ごとの返金案内と会社側の案内を混同しない [ ] 委託販売先が増えても使える共通表現を用意する 10．サポート [ ] 通常サポートの対象範囲を決める 商品の使い方 読み込み方法 ファイル不備 商品内容への質問 [ ] 個別制作・大規模作業・長期コンサルを通常サポートから分ける [ ] 他社サービス側の障害に対する扱いを決める [ ] 通常サポートとオリジナルオーダーの境界を公開文にする [ ] 一般問い合わせ窓口を一本化する 11．QA [ ] QAページまたはQA欄を用意する [ ] 実際に来た質問を徐々に追加する [ ] 初期候補を用意する 家族で使えるか 小規模事業者で共有できるか 法人が人数分を個別購入できるか 複数端末で使えるか 複数AIサービスで使えるか 社外の人へ渡せるか 配布・転売の禁止範囲 [ ] 規約を細かい事例で肥大化させず、QAで補う 12．サイト・法務・公開情報 [ ] About／Company [ ] Terms [ ] Disclaimer [ ] Privacy [ ] Security [ ] AI Policy [ ] Refund案内 [ ] License [ ] Support [ ] Contact [ ] Gumroadとの整合 [ ] 商品PDFからのリンク確認 [ ] 古いURL・リンク切れの点検方法 [ ] 販売終了後も公式サイトと問い合わせへ到達できる構造 [ ] サイト・Gumroad・PDFで内容が矛盾しない確認表を作る 13．日本拠点・会社紹介 [ ] Based in Japan の配置を決める [ ] 必要な商品では Designed in Japan を使用する [ ] 日本ブランドを過剰に神話化しない [ ] 販促に有効なら、事実の範囲で日本拠点を活用する [ ] 「日本拠点で、日本人の創業者が運営する会社」という表現候補を作る [ ] 日本文化の影響は、必要なら思想ページで薄く説明する [ ] サイト・Gumroad・PDFで会社紹介の芯を統一する [ ] 場所ごとに紹介文の長さを変える 14．公開用の仕事説明 [ ] 「AIを従わせるマニュアル」との違いを正式文へする [ ] 「AIが理解し、自然に行動できるマニュアル」を一般向けに説明する [ ] AI-readable manual の表現を検討する [ ] low-noise の意味を一般向けに説明する [ ] AIへ直接使用感を聞きながら設計している点を説明する [ ] まっさらなAIで再現確認する開発工程を説明する [ ] 内部構造を公開せず、価値と利用方法を説明する [ ] サイト用英語素材メモを後日煮詰める 15．最終製品化・試験 [ ] 人間向け正式文書を完成させる [ ] AIが読みやすい形へ再加工する [ ] PDFへまとめる [ ] スマホだけで読み込ませられるか確認する [ ] 専門知識なしで利用できるか確認する [ ] まっさらなAIへ読み込ませる [ ] 目的・前提・優先順位を正しく理解するか試す [ ] 不要な確認や過剰な増築をしないか試す [ ] 挙動が崩れた後、再読込で安定へ戻るか試す [ ] 複数回・複数の新規会話で再現性を確認する [ ] 安定後に販売版として確定する 点検結果 全体の積層構造：問題なし 致命的な上下矛盾：なし バッジと職業の境界：解決済み 発案第一号の判定主体：解決済み 販売先・返金条件の責任分担：解決済み ライセンスの基本思想：解決済み 日本拠点表現の基本方針：解決済み 残作業：正式文書化、詳細設計、公開文作成、試験 全体接続点検・第一周および未処理リスト化：完了 --- 🔴 ⬛️ LM-15 --- Working note: The first-pass inspection findings have now been transferred into a consolidated unresolved-work checklist. Resolved decisions are recorded as closed; remaining work is drafting, detailed specification, public-copy preparation, and fresh-model testing.