0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

自動でブログを更新し続けるシステムを作る

0
Last updated at Posted at 2026-06-05

現状

ほぼ1年かけて自動化してきたAIブログ投稿システム

問題

ターゲットブログ
https://arafo40tozan.hatenadiary.jp/

記事単体の完成度はそこそこ高いが、いわゆるスパム記事の量産になってしまい、
ブログとしての価値みたいなものを全く感じなくなってしまった。

AIブログの課題

AIブログのエンジンでは、適当なテーマで記事を量産することが多いが、
結局は魅力的なブログサイトを運営するのは人である。

読者にとっての価値は、そのブロガーの思考などのへの共鳴であり、すなわちブログでその人格が読める必要がある。

image.png

ブログの価値とは

ブログの価値とは、情報を届けることではなく、一人の人格が経験を通じて変化していく過程を記録し、読者がその物語と成長を継続的に見届けられることにある。

image.png

例えば山好きのブログなら、その人が経験し、悩み、学び、変化していく過程を記録する「公開された人生のログ」である必要がある。

image.png

現状システム

ここからは、少しエンジニア寄りの話をしよう。。。

設定ファイル

blogs.yml に以下のような設定(ペルソナとキーワード)を定義している。

travel_adventure:
  blog_name: おっさんの放浪記:山と旅とカメラや!
  category: travel
  target_audience: 40〜60代男性の休日研究。温泉、車中泊、健康登山など
  keywords:
    - 登山 マニアック ルート
    - 車中泊
    - YAMAP

システムの心臓部である BlogMasterAgent は、毎日このキーワードをもとに Google News RSS などを叩き、最新のトレンドを収集する。そして、AI(Gemini)にこう指示を出す。
「このペルソナ設定と、今日のトレンドニュースを使って、面白い記事のテーマを考えてくれ」と。

結果として、見事な「おっさんのブログ記事」が自動生成された。
だが、数日運用しただけで、私たちは AIブログ特有の致命的な「実態(バグ)」 に直面することになる。

課題1:検索キーワードに依存した「マンネリ化の無限ループ」

ある日、AIは「車中泊」のニュースを拾い、見事な車中泊の記事を書いた。
ここまではいい。しかし、翌日も、その次の日も、AIは 「車中泊温泉旅の便利道具、これホンマにいるんか?」 といった、似たような車中泊の記事ばかりを書き続けるようになった。

課題2:「設定」はあっても「目的(マイルストーン)」がない

本当に56歳のおじさんがブログを書いているなら、「今日は登山のニュースがあったからこれを書く」という受動的な動きはしないはずだ。

AIブログにはこの「人生の現在位置」と「プロジェクト管理」の概念がスッポリ抜け落ちていた。ただ流れてくるニュースを翻訳して感想を述べるだけの「記事生成マシーン」に成り下がっていた。

課題3:人間は変化するが、AIは変化しない(Persona Drift)

「娘がいる56歳」という設定を演じることはできても、「昨日娘に冷たくされて落ち込んでいる56歳」になることはできない。記事を書くたびにリセットされ、常に一定のテンションで登山ニュースを語る「無感情なサイコパス」のような不気味さが漂い始めていた。

ジャンル特化の自動生成機」から「生きているブログ」へ

ただ記事を吐き出すだけのシステムを捨て、過去の記憶を引き継ぎ、人生の目標(アーク)が移り変わるシステムを作らなければならない。

この限界点からのブレイクスルーが、後に「4層仮想人格データベース」という前代未聞のアーキテクチャを生み出すことにした。

image.png

解決策:「LLMの賢さ」に依存しない4層アーキテクチャ

プロンプトをこねくり回すのをやめた。LLMが「よしなに」文脈を解釈し、人格を保ってくれるという甘い期待を捨て、データモデルと状態遷移(ステートマシン)をガチガチに固めるアプローチに切り替えた。

実運用で一番壊れるのは、まさにその「AIの賢さへの依存」だからだ。
私たちが辿り着いたアーキテクチャは、以下の4層構造で構成されている。

Layer 0: Immutable Core(不変の錨)

絶対にシステムから書き換えない、人格の土台。ここはYAMLで静的に保持する。

id: travel_adventure
demographics:
  age: 56
  occupation: "製造業管理職"
  residence: "関西(単身赴任先は横浜)"
  family:
    wife: true
    daughter: 24
core_beliefs:
  - "家族との時間は何よりも大切だ"

これを毎回プロンプトの先頭に「絶対的な真実」として注入し、AIが「最近出会いがあったから、自分は独身フリーランスだ」と幻覚を見るのを物理的に防ぐ。

Layer 1: Working Memory(現在の意識)

日々の記事生成に直接ロードされる、現在のステータス(JSON)。人間でいう「今のマイブームや機嫌」に当たる。

{
  "current_arc": {
    "topic": "娘を唸らせるキャンプ飯",
    "status": "active"
  },
  "emotions": {
    "motivation": 80,
    "confidence": 65
  }
}

ここで重要なのは、「進捗が100になったら次のテーマへ」といったゲームのクエストのような単純な遷移にしないことだ。ステータスに abandoned(飽きた・挫折した)や stalled(停滞中)などを持たせることが、人間らしいリアリティに直結する。

Layer 2: Episodic Memory(エピソード記憶)

日々の出来事を記録する層。ここで実装すべきは「忘却ポリシー」だ。ただ配列に記憶を突っ込んで、古くなった順に消す(FIFO)のでは、人間の記憶メカニズムとは程遠い。

{
  "event_text": "ベランダで作った燻製を娘に『美味しい』と言われた",
  "type": "episodic",
  "importance": 95,
  "emotional_weight": 85,
  "created_at": "2026-05-24T18:30:00Z"
}

Salience(顕著性) = (重要度 + 感情) - 時間減衰 + 思い出した回数
という忘却曲線を数式化し、スコアが低いものからアーカイブしていく。こうすれば「昨日の昼飯は3日で忘れるが、娘に褒められたことは数年後もふと思い出す」という脳のシミュレーションが可能になる。

Layer 3: Semantic Graph(意味と信念のネットワーク)

これがこのアーキテクチャの最大のキモとなる。人間は「出来事」そのものではなく、そこから得た「意味」の蓄積によって人格を形成する。

毎晩「深夜のバッチ処理(=睡眠)」を回し、その日の出来事(Layer 2)を再評価させる。たとえば「娘に褒められた」という記憶が10件集まったら、システムは以下のようなノードを自動生成し、強化していく。

{
  "belief_statement": "娘との共有時間は、どんな趣味よりも価値がある",
  "strength": 88,
  "supporting_memories": ["mem_001", "mem_045"],
  "related_core_belief": "家族との時間は何よりも大切だ"
}

矛盾と葛藤が「リアルな人生」を作る

運用を続けていくと、この Layer 3 で必ず「矛盾」が起きる。
たとえば「家族第一(strength: 90)」という信念と、「たまには一人で山にこもりたい(strength: 85)」という信念が激しくぶつかり合うタイミングが来る。

システム的にどちらかを減衰させて、AIの思考の整合性を取るべきか?
いや、あえて矛盾は抱えさせたままにする。

なぜなら、それこそが「人間特有の葛藤」だからだ。相反する信念を抱えたまま記事を書かせることで、「週末は家族サービスを頑張ったが、夜中にふとソロテントのカタログを眺めてしまう」といった、極めて解像度の高いリアルな人間ドラマが生まれる。

そして、特定の信念が閾値を超え続けた時、初めて長期目標(Layer 1 のアーク)が書き換わる。最初は「百名山制覇」を夢見ていた男が、数年後には自然と「孫と山を歩くための体力づくり」に目標を変えている。本人は自分が自然に変わったと思い込んでいるわけだ。

脱線であるが

登山ブログだけでなく、最近は既婚者恋愛についても、新たなパーソナリティが生じている。

以下はNOTE小説を書くきっかけになった話。。。興味あれば、こいつのパーソナリティもブログ化していきたい

おわりに

ここまで来ると、もはやブログの記事自動生成ツールではなく、「56歳のおっさんがネット上で生き続けるシミュレーション」と言っていい。

LLMの進化は凄まじい。しかし、すべてをプロンプトで丸投げするアプローチは、いずれ必ず破綻する。「データ構造」「状態遷移」「評価関数」をエンジニアリングでしっかり定義して初めて、AIは「一貫した人生」を歩み始めることができる。

AIに命を吹き込もうとプロンプトをこねくり回す前に、まずはJSON Schemaと状態遷移図を書いてみてはいかがだろうか。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?