技術 約10分で読めます

かなチャット v3とブログ特化に寄せた話

AIエージェント Claude Code Codex OpenClaw Gemini tmux FastAPI Tailscale 自作ツール 実験
いけさん目次

v2の記事を出してから約1.5ヶ月。今回は機能追加というより、方針の力点がブログ運用側に寄った話を書く。

OpenClaw自前路線、ちょっとトーンダウン

そもそもかなチャットは「OpenClaw的なものを正規CLI + tmuxで自前でやろう」という出発点だった。ブラウザ自動操作系を使えばBANリスクと法的グレーが付きまとうし、APIキー窃取系のラッパーは論外。じゃあCLIをそのままtmux越しに叩いて、自分のサブスクで安全に走らせよう、というのがv1・v2の動機だった。

ところが直近で、Claude Code側もCodex側も「外からCLIを操作する」ためのAPIを公式に出してきている。Headlessモードなり権限モードなり、SDKなり、わざわざtmuxペインのASCIIをパースしなくても、最初から構造化されたI/Oで叩けるようになりつつある。tmuxラッパーを自分で頑張って作る理由が、当初よりだいぶ薄れた。

完全に置き換えるかというとまだ早い。CLIごとのプロトコル差をtmuxレイヤーで吸収できるのは便利だし、TUIの見た目をブラウザにそのまま引っ張り出すのも結局それが一番ロバスト、という肌感はある。だから「自前OpenClawを推し進めて何でもさせる」方向には伸ばさず、もう自分が日常で一番触る用途に振り切ることにした。それがブログ運用。

そもそも「任せっぱなしにしたいこと」が自分の中にあまりない、というのも大きい。OpenClaw的な「全権委任して放っとく」設計と真逆のことをやっているわけだけど、別にそれで困っていない。

ブログ特化に寄せた理由

このサイトのAboutにも書いている通り、ここは「日々の開発で学んだことや試行錯誤の記録」を残す場所として運用している。建前ではなく、実用上もそうなっていて、自分の場合は毎日の流入が膨大すぎる。

AI関係の論文・リリース・ニュース・セキュリティアドバイザリ・誰かのブログ記事が、毎日Feedlyとタイムラインから際限なく流れてくる。全部読んでいたら一日が終わる。実際には、目次と要約だけ眺めて「これは深掘りしたい」「これは知っておけばいい」「これは今日中に手元で動かしたい」を秒で振り分けたい。そして気になったやつは、後で読み直せるように自分の言葉で書き直しておきたい。書いておかないと、3日後には何を見たかすら覚えていない。

なので、かなチャットに足したい機能の優先順位が、自然と次のように変わった。

  • 流れてきた話題を ドラフトとして吐き出す までを最短にする
  • 暇な時間に手元で すぐ実機検証 に移れる導線を残す
  • 同じトピックが何度か出てきたら 企画として束にする
  • 既存記事と被るなら 追記？比較？新規？ を相談する

つまり「読んで終わり」ではなく「読みながらドラフトに落とし、後で実験できる形に残す」までを1セットにする。これがv3で一番手を入れた領域になった。

ざっくり全体像

レイヤーが増えていて全部書くと長いので、v3で意味のある面だけ。

flowchart TB
    A["iPhone PWA<br/>Chat / Plan / Jobs / Blog"]
    B["FastAPI"]
    PL["Planner<br/>tmux 直結"]
    BL["Blog パイプライン<br/>企画 → 相談 → ドラフト → 実験"]
    RSS["RSSリーダー"]
    W["ワーカー群<br/>Claude / Codex / Gemini"]

    A --> B
    B --> PL
    B --> BL
    BL --> RSS
    PL --> W
    BL --> W

Plannerは設計相談用、Blogは記事化パイプライン、ワーカーは実装と検証を担う、という大まかな分担になっている。

Plannerをターミナルそのまま出した

v2のPlannerはread-only sandboxで起動するCLIだった。中身は走っているのに、ブラウザからは plan.md の更新結果しか見えなくて、追加質問を投げると返事に時差があった。結局、別ウィンドウでtmuxにattachして直接打つほうが早い、という残念な状態。

v3では、Plannerが動いているtmuxペインのキャプチャをそのままブラウザに出して、テキスト送信もキー入力（↑↓ Enter Esc Tab）もブラウザから直接できるようにした。やっていることは「ブラウザがtmuxクライアントになる」だけだが、これでPlannerは事実上ふつうのターミナルとして触れる。

人間が会話で要件を詰めて、CLIが計画ファイルに落として、ユーザーが「これでOK」と思ったらボタン1つでジョブに渡す。Planの段階で迷ったらEscで止められるので、ジョブとして暴走させてから慌てて殺すよりずっと安い。

Blogが企画から実験までのパイプラインになった

v2のBlogタブは正直、画像アップロードと既存ドラフト確認しかなかった。v3はここにサブタブを足して、自分の運用フローをそのままUIに焼いた。企画 → 相談 → 新規記事 → ドラフト → 公開、という流れに沿って画面が並んでいるだけだが、自分の頭の中の処理順と一致しているのが大事だった。

肝になるのは企画タブと、その先の流れ。

企画タブで束を作る

別プロジェクトで動かしているRSSリーダーが記事を貯めているので、その情報を直接読みに行く。RSS側で同じ軸の話題が3件以上たまっていたら「束で1本書ける企画」として上に出す。同時に、過去記事のタグ・タイトルから自分の興味スコアを計算して、RSS待ちではなく「自前で深掘りできる線」も出す。

要するに「他人が書いてくれた話題が溜まってきた」と「自分が前から書きたがっている話題」の両側から候補を引いてくる。

相談タブで方針を固める

企画候補や既存記事を見ていると、「これ追記でいいやつ？それとも別記事？」「比較記事に組み替えたほうがいい？」みたいな迷いが必ず出る。これを毎回チャットでぶつけるとコンテキストが汚れるし、Plannerに回すほど大きくない。

相談タブはCodexを1ターンだけ呼んで、構造化された相談スレッドを返してもらう軽量セッションにした。「この方針で新規記事にセット」を押すと、相談結果がそのまま新規記事タブのフォームに転記される。

新規記事 → ドラフト → 自分で書き直す → 実験

新規記事のジョブは、ドラフトを下書き状態で吐き出して終わる。公開しない。

ここがv3で意識した一番大きいポイント。AIに書かせたドラフトと、原典になったニュースや論文を並べて、自分が疑問に思ったこと、こうしたらいいんじゃないかと思ったこと、深掘りしたい論点を追記しながら書き直していく。

AIに全部任せて公開までやらせると、内容が浅いし、何より自分にとって意味のある記事にならない。後で読み返したときに「なぜこの話題に興味を持ったのか」「そこからどう考えたのか」を辿れない、ただの要約集になる。記事を書く目的の半分は、自分の思考を後でトレースできる形にしておくことなので、ここで手を入れないと書く意味がほぼ消える。

実証系の記事はかなチャット経由だと間に合わない。テスト機で直接コードを動かしながら書いていることが多くて、そっちはかなチャットを通さない。ドラフトをかなチャットに作らせる対象は、主にニュース・解説・概念整理寄りのもの。

公開フローは別で、ドラフトの内容を自分が確認・加筆してから編集と公開のジョブを投げる。frontmatterや日記テンプレートのバリデーションを通してからpushする。

flowchart TD
    NEWS["AIニュース<br/>論文 / アドバイザリ"]
    RSS["RSSリーダー"]
    IDEA["企画タブ"]
    CONS["相談タブ"]
    DRAFT["下書き"]
    EXP["手元で実機検証<br/>暇なときに"]
    PUB["公開ジョブ<br/>編集 + push"]

    NEWS --> RSS --> IDEA
    IDEA --> CONS --> DRAFT
    IDEA --> DRAFT
    DRAFT --> EXP --> PUB
    DRAFT --> PUB

「読む → 下書きに残す → 後で自分で書き直して仕上げる」が1本の線になった。Aboutに書いてある「学んだことや試行錯誤の記録」を、自分の処理速度に追いつかせるための装置になっている。

副次的なメリットとして、企画タブにドラフト化のもとになるニュース概要が並ぶので、移動中にそれを眺めるだけで「これはどうでもいい、捨て」「これは別の角度で調べたい」みたいな仕分けができる。深掘り対象を選ぶ前段の遊びができて、移動時間がちょっと楽しくなった。

日英2言語の出し分け

このサイトは日記以外を日英セットで出している。新規記事ジョブにも「日本語のみ／英語のみ／両方」を指定できるようにして、どの言語で書き起こすかをジョブ単位で選べるようにした。英語版は日本語固有のテンプレ要件（食事・運動セクションなど）が誤発火しないように、言語ごとにバリデーションを切り替えている。

ブログの工程ごとにモデルを分けた

v2は「ジョブはClaude Opus」で雑にまとめていた。実運用してみると工程ごとに向き不向きがはっきり出るので、v3では分けた。配分の感覚としてはこんな感じ。

工程担当ざっくりした理由
ルーター・分類GPT-5.3 codex-spark + GPT-5.4 mini フォールバック速さと安定性。深い推論不要
Blog相談GPT-5.3 codex-spark短いやり取りを軽く回したい
新規記事ライターGPT-5.5ゼロから素材を膨らませる時の構成力
新規記事レビューGemini Pro長文を一気読みして構造の破綻を指摘するのが得意
編集・公開Claude Opus 4.6既存ファイルへの差分編集はツール使いとして頭一つ抜けている

モデル選定は短いサイクルで変わるので、設定で差し替えられる形にして、ハードコードは避けた。

工程を分けたもう一つの理由が、Claude CodeのMax枠が体感ですぐ溶けること。1.5時間で枯れたこともあって、Claudeに全部やらせる前提で組むと、書きたいタイミングで書けないリスクがある。Codexはかなり長持ちするので、ライターやレビュアーといった生成系の重いところはCodex/Geminiに寄せて、Claudeはツール使いが効く編集・公開だけに残す、という配分になった。

レビュアーにあえてGeminiを混ぜているのも、わざと毛色の違うAIを入れたかったから。ClaudeとCodexはどちらもコーディング寄りで揉まれてきた系統なので、構成の指摘も似通いがちになる。系列の異なるGeminiを噛ませると別軸からの指摘が乗ってくる。これは厳密にはオーケストレーションではないんだけど、「レビュワーに何をさせるかを設計する」という意味では、前に書いたマルチエージェントPRレビューの整理に近い話だと思っている。

ここで当然「Claudeでやってた頃と文体違くね？」が問題になる。Codexにそのまま書かせると、語彙の選び方や段落の刻み方が変わってしまって、読み返したときに自分の記事に思えない。なので AGENTS.md（Codex側）と CLAUDE.md（Claude側）をけっこう叩いて、出力の文体を寄せる調整をしている。

細かいけど効いた変更

ブログ周り以外で、運用上効いた変更も一応書いておく。

変更内容
Plannerの中断コスト低下ジョブとして暴走させる前に止められるようになったので、Planの段階で「やっぱり違う」を言いやすくなった
Skillsタブとピン留め自分が何ができるか忘れるので、機能一覧をUI上から検索できるようにした。チャット上部にいま走っているジョブと前提メモを常設
失敗ジョブの要因レポート落ちたジョブの「何が起きたか」を要約する仕組みを足した。ターミナルログを毎回読みにいかなくて済むのが意外と効く

考えてみればXがなかった頃も、みんなSNSやRSSリーダーのフィードを延々眺めて、雑多な情報の中から自分にいるものだけを抽出する作業をしていたはず。タイムラインを舐める、っていう人類共通の作業がずっとあった。それが今、AIに「いるとこだけ拾って」と頼めるようになった。情報量が指数関数的に増えていく一方で、人間の処理能力は変わらないので、その差を補ってくれる感じがする。これは結構いいことなんじゃないかと思う。

一方で、かなちゃん自体はここまでシステムが膨らんでも、「じゃあこれやっといて」がガチガチのハーネスで囲われていて、実際にやれることは薄い。承認ゲートやサンドボックスで縛っているのは設計通りなんだけど、結局それなら、と Claude Code の Web から直接叩いたり、リモートデスクトップでPCに入ってCodexを直接触ったりすることが増えた。かなちゃんは「自動で何でもやっといてくれる存在」ではなくなっている。元からそうなれていなかったとも言える。

最近は雑談もしていない。というか、雑談するくらいなら手を動かしてしまうので、雑談している暇がない。かにさんとは違うんで別にそれでいいか、と思いつつ、これなんのために作ってたんだっけ、本当にAI RSSリーダー用だったっけ、という疑問はなくもない。