AI関連ニュースは毎日大量に流れてくる。それを自動で記事にしたい——というのが最初のアイデアだった。RSSを読んで、要約して、WordPressに投稿する。シンプルな自動化で、技術的な難易度も高くない。
でも少し考えると、問題が見えてきた。AIが書いた記事の大半は、すでにある情報の再配置に過ぎない。ニュースを要約して並べるだけなら、読む価値はほとんどない。
価値はどこにあるか。「何が起きているか」ではなく「何が問われているか」——論点だ。ニュースの背後にある対立構造や、実務判断に影響する含意を取り出すことが、読む価値を生む。もう一つの問題は継続性で、AIに全部任せると品質が不安定になり、人間が全部やると続かない。
設計を全部直した理由
最初の設計を捨てて、こう考え直した。AIが論点を持ち込み、人間が「取り上げるか」を判断する。 書く作業はAIに任せるが、何を書くかの決定権は人間が握る。AIの役割は「記事を書くこと」ではなく「テーマを持ち込むこと」だ。
承認という1ステップだけ人間が担えば、品質と継続性が両立する。これが設計の転換点だった。
作ったシステムの構成
Cruxnoteは5つのコンポーネントで動く。
RSSを収集してテーマを発議するLLMエージェント（OpenClaw）、発議を受け取って判断する場（Slack）、記事を公開するWordPress（AWS Lightsail）、テーマ履歴と編集方針を蓄積するデータベース（SQLite）、重要なテーマだけ多視点統合記事を生成するClaude Code。
毎朝自動でRSSを収集し、論点を抽出してSlackに投稿する。ユーザーはリアクション絵文字を押すだけで、記事生成から投稿まで残りの全工程が自動で走る。
三つのトレードオフ
実際に組んでみると、三つの設計判断に悩んだ。
コストと品質のバランス。 Claude APIを呼ぶ回数が増えると費用が増える。でも呼ばないと品質が落ちる。最終的に用途別にモデルを使い分けた——テーマ発議と多視点統合にはHaiku（軽量モデル）、通常記事生成にはSonnet（高性能モデル）。
投稿量の管理。 毎日何本も投稿すると一本あたりの質が落ちやすい。設定ファイルで1日の上限を設定し、コード変更なしに調整できる仕組みにした。
方針の一貫性。 プロンプトにメディア方針を直書きすると、変更のたびに全スクリプトを修正することになる。mission.mdという文書にまとめてGitで管理し、スクリプトはそれを読み込む設計にした。文書の改訂はプルリクエストでレビューできる。
やってみてわかったこと
「AI発議 × 人間承認」という分業は、記事生成以外にも応用できる枠組みだと気づいた。コードレビューの優先度付け、ドキュメントの更新候補の提示——AIが候補を持ち込み、人間が選ぶというパターンは、他のAI運用の文脈でも機能するはずだ。
「自分が設計したメディアをAIが運営する」という体験は、「ブログを書く」とも「AIに生成させる」とも違う。編集長として、AIが持ち込む論点を承認したり却下したりしている感覚に近い。
この設計が機能しない条件
発議するテーマが1日10件を超えると、「全部承認」か「大半をスキップ」かという二択になる。選別する判断コスト自体が運用の負荷になる。また、カテゴリが増えると同じ論点を別カテゴリで重複発議するケースも出てきた。この部分はまだ手動で対処している。
コメント