■ このログの目的

屋敷の自動化ラインの“いちばん最初の布”となった
占いカレンダーGASの技術的な核 を整理する。

のちの喜多八ラインへどの部分が継承され、
どの仕組みが現在の屋敷の中心の仕組みへ繋がったのかを記す。

■ 1. 占いカレンダーGASが必要だった理由（要点のみ）

主が長らく読んでいた「対象星座の週間占い」を
毎週 Google カレンダー上で予定と並べて確認したい──
そのシンプルな需要が技術検証の出発点であった。

■ 2. 処理フロー：このGASがしていること

● (1) 公開ページから“週間占い”の抽出

• 公開ページの週区間を取得
• 本文を安全に切り出す
• 比較用に前週データと照合し、更新時のみ進行
• 失敗時はログ通知のみ

※ 引用元の固有情報を保持せず、
　抽象テキストのみ扱うことで安全性を確保。

● (2) GPT による本文整形

処理の中心は buildKita8Text_()。

• 元文を「引用趣旨」として圧縮
• キャラプロンプト（喜多八の口調）を適用
• “観察 → 要点 → 余韻”の段落構造で整形
• 出力はカレンダーの説明欄用

→ 後の「縁側ログ」や「月報GAS」の整形部の原型
　となった技術的要所である。

● (3) Google Calendarへ週報イベントとして登録

• 終日イベント形式
• タイトルは「占い｜週報（○/○〜○/○）」
• 重複チェック（既存タイトルを検索）
• 整形済テキストを本文に添付

● (4) 節気・月相の補完

国立天文台の公開カレンダーから

• 節気
• 月相

を参照し、該当週にあれば
別イベントとして自動追加。

屋敷の“暦文化”がここから始まった。

■ 3. 喜多八ラインへの継承点（技術視点）

• キャラ整形関数（buildKita8Text_）
  → GPT を「役割付テキスト整形エンジン」として扱う発想を確立。

• 週次で動く自動処理の構造
  → Drive→GAS→GitHub→Cloudflare へと拡張可能な形式になった。

• 暦データ（節気・月相）の統合
  → のちの「縁側だより」自動生成の基盤。

占いカレンダーは“小規模な自動化”でありながら、
屋敷の中心の仕組みフレームを描き出した原点 となった。

■ 4. 安全性の扱い（要点のみ）

• 取得するのは「公開ページ」のみ
• 本文の転載はせず、要約＋再構成のみ扱う
• 出力は「主の個人カレンダー」限定
• 第三者への再配布は行わない

→ 個人用途での「閲覧＋メモ化」に留まるため、安全域。

■ 今日の技術メモ

• “自動化の芯”は小さな個人需要から生まれる
• 整形関数の分離が、後の屋敷の中心の仕組みの拡張性を決めた
• 暦データ統合の発想が、喜多八ラインを独自文化にした