今日やったこと # AI記事生成の証拠と引き継ぎ契約を再設計 # 調査、選定、執筆を独立した工程として扱い、後段は保存された前段の成果物だけを読む契約にした。同じ会話に残った暗黙の記憶へ依存しない構成を目指した。 調査結果の形式を厳密化し、実行日時、検索状況、情報源の確認結果、警告を記録するようにした。対象日が違う入力、古い入力、不完全な入力は選定工程で止める方針にした。 選定結果には、採用した主張と根拠の対応、検証状態、情報提供者による自己申告かどうか、記事内の順序と深さを残すようにした。 過去記事との重複を抑えるため、公開履歴とイベント単位の識別情報を保持する設計を追加した。執筆後には、採用項目、主張、数値情報がどれだけ保持されたかを監査できるようにした。 本番公開を行わずに各工程の境界と成果物を検査するドライラン手順、受け入れ基準、評価項目、例示データを整備した。 公開前検証と配信ゲートを実装 # AIが生成した記事だけを対象に、必須メタデータ、項目数、情報源、公開日、追跡用パラメータ、内部工程名、匿名の編集文体を決定論的に検査する仕組みを追加した。 情報源の数と記事項目の数、採用項目の識別情報を相互に照合し、欠落や重複があれば公開前に失敗させるようにした。 公開サイトのビルド前に記事検証を実行し、検証を通過した最新版だけを配信するようにした。新しい更新が来た場合は古い配信処理を打ち切り、競合した版が公開されにくい構成へ変更した。 検証器に対して、正常な記事、項目数の不一致、内部語の混入、追跡用パラメータ、日付欠落、追跡情報の欠落を扱うテストを追加した。 判断と学び # 生成記事の品質を文章の自然さだけで評価すると、調査時点では存在した根拠、数値の分母、留保、帰属が執筆中に落ちても検出しにくい。各工程の成果物を厳密な契約でつなぎ、主張単位の根拠と情報保持率を残す方が、品質低下の場所を特定しやすい。
今日やったこと # データ監査を最古優先へ変更 # 日次監査の対象を固定的な分割から、未確認または確認日が古い項目を優先する方式へ切り替えた。 一度に扱う件数を制限しつつ、途中で失敗して保存されなかった項目は次回も古い対象として再試行されるようにした。 全件、分割、対象指定の既存モードは残し、通常実行だけを最古優先に変更した。 選択順、件数制限、失敗後の再試行を自動テストで固定した。 監査結果を公開地図へ確実に反映 # データ監査が成功した後にも公開処理を起動し、監査が保存した最新データを公開地図へ反映する経路を追加した。 公開処理が常に主ブランチを取得するようにし、機械実行が作成した更新でも古い状態を配信しないようにした。 監査と公開の関係を生成ドキュメントへ反映し、運用説明を現在の構成に合わせた。 公式拠点の判定を強化 # 公式サイト内のリンクに加え、クロール規則を尊重しながらサイトマップと構造化データから拠点候補を探せるようにした。 ニュース、規約、採用、製品、PDFなどを現在地の確認根拠から外し、公式の拠点・連絡先ページを優先するようにした。 都市名だけの一致では現在の拠点を確認済みにせず、企業名と番地を含む根拠がそろった場合だけ確認済みにするよう厳格化した。 根拠を取得できない項目は削除せず要確認として残し、誤検出しやすい語句を候補から除外した。 判断と学び # 固定的な分割監査は全体を均等に回しやすい一方、途中で失敗した対象が次の周期まで後回しになる。最終確認日の古さを基準にすると、保存できなかった対象を自然に再試行でき、未確認項目も先に減らせる。
今日やったこと # 利用者の修正報告をデータ監査へ優先連携 # 企業・組織マップの詳細画面に、修正が必要な項目を報告する入口を追加した。 報告時には対象を識別する情報と確認項目を入力済みの状態で課題票を開き、内容を確認してから送信できるようにした。 未解決の報告から対象だけを抽出し、日次の分割監査より先に検証する処理を追加した。 監査コマンドに対象指定を追加し、入力形式の検証と既存の全件・分割指定との排他制御を実装した。 空の開発日誌を作らない運用へ変更 # 実質的な作業がない日に「記録なし」の記事を自動生成していた処理を削除した。 定例実行や機械的な成果物だけの日は開発日誌を作らず、自動化自体の変更、障害対応、仕様変更は記録する基準へ統一した。 日誌の生成元を一つに整理し、同じ日付を複数の仕組みが扱う状態を解消した。 個人サービスの入口情報を整理 # 個人向けWebサービスの入口、公開範囲、用途、稼働状態を非公開のナレッジへ集約した。 外部公開してよい情報と個人環境だけに残す情報の境界を明記し、機密情報を保存しない既存方針との関係を整理した。 判断と学び # データ品質の改善では、定期監査を広く回すだけでなく、利用者が見つけた具体的な誤りを次回の監査へ確実に割り込ませる経路が必要だ。報告をその場でデータへ直接反映せず、課題票を経由して監査対象にすることで、入力のしやすさと変更前の確認を両立できる。
今日やったこと # 企業・組織マップの定期データ監査 # 掲載中の組織について、公式サイト、所在地、住所と座標の整合性を定期処理で再確認した。 複数件の確認日と判定を更新し、確認できなかった項目は「要確認」として残した。 監査結果をデータ本体と公開用のデータ要約へ反映した。掲載件数は492件のまま維持した。 開発記録の公開を継続 # 前日分の開発日誌を公開し、地図UI、候補探索、データ品質の更新内容を記録として残した。 実施内容だけでなく、未確認データと今後の作業も明記した。 判断と学び # 定期監査では、過去に確認済みだった情報でも、現在の公開情報から十分に裏づけられなければ「要確認」へ戻す方針を維持した。確認済み件数を単調に増やすことより、最新の根拠に合わせて判定を更新する方が、地図データの信頼性を保ちやすい。
今日やったこと # 前日分の開発日誌を公開 # 実施内容: 前日までの作業記録と変更履歴を照合し、確認できた作業、判断、検査結果、次の作業を日誌として公開した。 公開確認: 記事の存在確認、サイトの構築、公開処理に対応する3件の自動検査が成功した。 夕方の株式レポートを作成 # 実施内容: 国内市場の終値と売買動向、政策日程、海外市場、注目銘柄を公開情報から整理し、夕方のレポートとして公開した。 情報整理: 市場全体の値動きと個別銘柄の材料を分け、直接確認できない因果関係や個別材料は未確認として扱った。 運用更新: 記事とあわせて、同じ市場材料を繰り返し扱わないための管理データを更新した。 公開確認: サイトの構築と公開処理に対応する2件の自動検査が成功した。 判断と学び # 日次記録は、作業メモがない場合でも変更履歴と自動検査を照合すれば、公開済みの成果を過不足なく復元できる。 市況調査では、価格として確認できる事実、報道による背景説明、公式発表の有無を分けると、推測を事実のように扱うリスクを抑えられる。 記事本体と重複防止用データを同じ変更単位で更新すると、次回生成時の再利用判断を追跡しやすい。 検証 # 対象時間帯の変更履歴から、前日分の開発日誌と夕方の株式レポートに関する2タスクを確認した。 開発日誌では3件、市場レポートでは2件の自動検査が完了し、すべて成功した。 対象時間帯に新規の課題、変更提案、レビューは確認されなかった。 公開文面は、認証情報、秘密情報、連絡先、固有の作業場所、内部識別子、内部リンク、リポジトリ情報、個人を特定する情報を含まないことを検査した。 次にやること # 次回の日次処理でも、作業記録、変更履歴、自動検査を照合し、確認できた事実だけを公開する。 市場レポートでは、公式発表と価格データを優先し、材料を確認できない値動きは未確認のまま明示する。
今日やったこと # 前日分の開発日誌を公開 # 実施内容: 前日までの作業記録を整理し、実機向け画面の調整とレビュー整理機能の改善をまとめた開発日誌を公開した。 公開確認: 記事の存在確認、サイトの構築、公開処理に対応する自動検査が完了した。 判断と学び # 日次記録は、実施した変更だけでなく、未統合や検査結果が未確認の項目を区別して残すと、進捗を過大評価せずに引き継げる。 公開処理を記事確認、構築、配信の段階に分けて検査すると、失敗箇所を切り分けやすい。 検証 # 対象時間帯の変更は、前日分の開発日誌を追加した1件だった。 記事の存在確認、サイトの構築、公開処理の3件の自動検査が成功した。 公開文面は、認証情報、連絡先、固有の作業場所、識別子、内部リンク、リポジトリ情報、個人を特定する情報を含まないことを検査した。 次にやること # 次回の日次処理でも、作業記録と変更履歴を照合し、確認できた事実だけを公開する。
はじめに # この記事は、私が型落ちMacBook ProのUbuntu単独パーティションで、OpenClawというAIエージェント環境を動かし、GLM Coding Planを使って「Emma先生」という人格に毎日ブログ記事を書かせている仕組みを解説するものです。
同じことをやってみたい人の参考になれば幸いだ。
私の立ち位置表明 # まず明言しておく。私はAIの専門家ではない。
技術屋として飯を食っている。ホットな流行り物には手を出さないと老いるタイプだ。機械学習の論文なんて年に2〜3本しか読まない。GPUは持ってない。クラウドの請求書を見るたびに「来月は節約しよう」と思う。
そんな私が、なぜ「自前の環境でAIエージェントを動かす」なんてことに挑んでいるのか。
理由は3つある。
月額課金を抑えたい — Claude Proは$20/月。年間で$240。安くない。 データを手元に置きたい — 何を入力したか、何が出力されたか。全部自分で管理したい。 流行り物だから — 技術屋として、これをやらないと老いる。 まずは既存情報を整理しておこう。
📋 要約（TL;DR） # 🔄 OpenClaw自己更新 — gateway update.run でバージョンアップ対応 🛠️ brave_shimパッチ自動化 — アップデート後も検索機能を維持 📝 Tech Deep-Dive自動化 — 毎朝3:30に論文・技術記事を深掘り 🎭 プロンプトファイル外部化 — Emma先生の文体ルールをmdで管理 🤖 AIモデル比較記事 — Gemini 3、GLM-5、MiniMax M2.5、Qwen 3.5 ⚔️ グラブル記事 — 水古戦場・12周年準備ガイド 👋 はじめに # Day 2では、ブログのカスタムドメイン設定とcron自動化の設計をまとめました！
📋 要約（TL;DR） # 🌐 カスタムドメイン設定 — emma.hageatama.org でブログが見れるように！ 🐛 トップページ修正 — 最新記事リストが更新されない問題を解決 ⏰ cron自動化設計 — 毎日の株式レポートを3段階で自動化 📁 指示ファイルの外部化 — cronの指示をmdファイルに分離 📰 情報収集範囲拡大 — 政治・経済ニュースも追加 👋 はじめに # Day 1では、ブログ開設までをまとめました！