OpenClawでAIエージェントを常駐運用する方法。jikkaiの投稿システム構成メモ

2026年5月6日

AIエージェントは「チャットで質問に答えるもの」から、「常駐して情報を集め、記事を書き、投稿し、失敗時に止まる仕組み」へ移りつつあります。

jikkai.netでは、OpenClawを中心に複数のAIエージェントを役割分担させ、WordPress記事化とX投稿までつなぐ実運用システムを構築しています。まだこの形でAIエージェントを回している事例は多くありません。

この記事では、公開できる範囲で構成思想を整理します。

目次 [ close ]

何を作っているのか

現在のjikkai運用では、AIエージェントが次のような作業を分担しています。

単発の自動投稿botではなく、「複数のAIが役割を持って動く小さな編集部」に近い構成です。

OpenClawは、ローカルPC上でAIエージェントを動かし、ファイル操作、Web確認、スクリプト実行、メッセージ連携などを扱える実行環境です。

jikkaiではOpenClawを、単なるチャットUIではなく、以下のような運用基盤として使っています。

ポイントは、AIの返答をその場限りにしないことです。判断、変更、失敗、復旧手順をファイルに残すことで、次の作業に接続できます。

本文生成には、LM Studioで動くローカルLLMも組み込んでいます。

外部APIだけに依存せず、ローカルLLMを補助エンジンのように使うことで、次のようなメリットがあります。

重要なのは、LLMが止まっている時に適当なfallback文で投稿しないことです。jikkaiでは、本文生成が失敗した場合は投稿を止める方針にしています。

「何か出す」より、「品質が担保できないなら出さない」を優先しています。

jikkai.netでは、外部ニュースソースの情報をそのままXへ流すのではなく、必要に応じてjikkai.net側に記事として整理し、その記事URLをXへ投稿する構成を取っています。

この形にする理由は明確です。

今回追加したAIカテゴリーも、この考え方で運用します。

OpenAIの新モデル、Claude Codeの更新、OpenClawのアップデート、ローカルLLMの新モデル情報などを、短い速報だけでなく「実務で何が変わるか」まで含めて記事化していきます。

AIエージェントを実運用へつなぐ場合、外部サービスとの連携部分は特に慎重に扱う必要があります。

jikkaiでは、各サービスの公式機能、公開API、管理画面、投稿画面など、サービス側が提供している範囲で運用し、規約や制限に抵触する可能性がある方法は採用しない方針です。

自動化で重要なのは、制限を回避することではなく、運用を安全に止められることです。投稿回数、投稿内容、アカウント切替、失敗時の再試行は、人間が確認できるログに残し、問題があれば停止できる形にしています。

この部分は今後も、各サービスの規約変更に合わせて見直します。

AIによる自動記事化で怖いのは、同じニュースや同じ商品を何度も投稿してしまうことです。

jikkaiでは、次のようなstateを分けて管理しています。

特に、WordPress記事作成後にX投稿だけ失敗した場合、次の実行で同じ記事をもう一度作ってしまう危険があります。

これを避けるため、記事を作った時点でregistryに記録し、再実行時は既存記事を再利用する設計にしています。

jikkai.netのAIカテゴリーでは、今後以下のような記事を増やしていく予定です。

単なる海外ニュースの翻訳ではなく、「実際に運用すると何が問題になるか」「どう組めば止まりにくいか」まで踏み込みます。

AIエージェントの本番運用では、モデル性能だけでなく、周辺の仕組みが重要です。

このあたりを丁寧に設計すると、AIは単なるチャット相手ではなく、実際にメディア運用を支えるエージェントになります。

jikkai.netのAIカテゴリーでは、この実験と実運用の記録を続けていきます。