西川和久の不定期コラム

ごめんLLM、もう君だけじゃ物足りない。気づけばOpenClaw沼にハマった話

  • 西川 和久

2026年6月18日 06:06

　前編ではOpenClawの設定を主に書いたが、今回の後編はいよいよ実践編。AIがプロンプトを考え、画像/動画を生成、それをcronで指定した時間にXやTikTokへ自動投稿、さらにLINEへ報告……と、OpenClawフル稼働で使ってみたい。

Windows+Docker環境セットアップ修正

　実践へ入る前に、セットアップ関連の補足説明をしたい。元々前編を書いたとき、Ubuntu+Dockerをメインで使っていて、検証用にWindows+DockerとmacOS+Dockerとしていたが、どうもWindows+Dockerの調子が悪いようなので、いったんメインをWindows+Docker環境にし、その原因を探りつつ使うことにした。基本、.openclaw/のフォルダーを丸ごとコピー、新しい環境へペーストすれば、.venvなど環境依存部分以外は、まるっと全部引越し可能だ。

　その“調子が悪い”のWindows+Docker環境は、以下のような状況だ。

問題の発端

　前編ではOpenClaw v2026.5.28をベースに書いていたが、入校日にv2026.6.1が出たので、試しているとexec toolが動作せずログに以下のエラーが出るようになった。 

EPERM: operation not permitted, chmod

　この原因はv2026.6.1のchmod/EPERMバグ。Windows+Docker環境でファイルシステムがchmodを拒否するケースの処理が壊れるのだ。

ロールバック先の選定過程

　execができないと実質使い物にならないので、ダウングレードをいくつか試してみたが、v2026.5.x系は全滅。これはv2026.5.1でexec approvalsの設計が大幅変更され、サンドボックスコンテナがデフォルト有効化。Windows+Docker+既存設定ではNGのバグが出ているためだ。前編でベースにしていたv2026.5.28も含めてダメ。そのため既に前編をベースに試していただいた読者には申し訳ない。筆者の確認が甘かった。

　そしてさらにダウングレードしていくと、うまく動いたのがv2026.4.27のみだった(アップグレードの2026.6.x系も執筆時点では全滅)。現在、これで日々運用している。従って、 

$ git clone https://github.com/openclaw/openclaw
$ cd openclaw
$ git checkout v2026.4.27

と旧バージョンを使うと指定した上で、docker compose up -d --buildする必要がある。

　また、デフォルトではpythonもコンテナにインストールされない。そのためdocker-compose.override.ymlを以下のようにして回避する。そもそもpythonを使わないなど考えにくく、デフォルトはインストール、オプションでインストールしないなら分かるが、なぜこのような仕様になったのか理解に苦しむ。ちなみに、すぐ後のビルドではこのOPENCLAW_DOCKER_APT_PACKAGESという項目名さえも変わっている。 

services:
  openclaw-gateway:
    build:
      context: .
      args:
        OPENCLAW_DOCKER_APT_PACKAGES: "python3"
        OPENCLAW_INSTALL_BROWSER: ${OPENCLAW_INSTALL_BROWSER:-}
        OPENCLAW_IMAGE_PIP_PACKAGES: ${OPENCLAW_IMAGE_PIP_PACKAGES:-}

　以上のように指定して一件落着。安定版ともいえるv2026.4.27で解決した問題の一覧は、

問題　修正バージョン
exec/chmod EPERM（Windows+Docker）v2026.4.27
カスタムプロバイダーの`input: ["text", "image"]`無視　v2026.4.25
OpenCode Go 404（model_not_found）　プロバイダー名を予約語以外に変更で回避
python3未インストール　`OPENCLAW_DOCKER_APT_PACKAGES: "python3"`で解決

となる。

　カスタムプロバイダーの`input: ["text", "image"]`無視も、Visionモデルを使いたいときは致命的だろう。なお、OpenClawを稼働させるモデル(プロバイダー)だが、筆者は、現在ローカルLLMでの運用(Qwen3.6 27b)は精度的な問題で諦め、クラウドのOpenCode GoのMiMo-V2.5(Vision対応)をメインに使っている。DeepSeek V4 Flash同様トークン単価が安く、今のところおすすめだ。

　ただ、LM StudioのエンドポイントでローカルLLMを使うときは動くが、OpenCode Goに切り替えると動かないという問題が発生した。

　調べると、プロバイダー名に「opencode-go」としたのがダメな原因のようだ。この名前は、OpenClawでプロバイダー名の予約語になっており、jsonの記述よりOpenClawが持っているリストを優先するのだが、モデルリストが古く、DeepSeek V4 Flashなどを指定しても該当なし=404エラーになってしまうというものだった。従ってプロバイダー名をopencode-goからgoへ変更。

　これからも分かるように、少し触れば分かるはずの問題がv2026.5.xx、v2026.6.xxで放置されており、唯一動くのがv2026.4.27という状況。つまり、OpenClawのコミュニティはWindows+Docker環境でのレビューはやってないのだと思われる。OS直入れで検証したのが主な原因だろう。

　ほかにもいろいろ問題は山積み。どこか直すとどこか壊れるが繰り返されている。少なくとも筆者が試した範囲では、品質管理が追いついてないような感じだ。

問題オールクリアで日頃運用しているOpenClaw(Windows+Docker) v2026.4.27

　とりあえずこれで問題はオールクリアなので、実践へ移りたい。

実例1 AIキャラの「写真/動画」を自動生成する

　実際動き出し「さて何を……」と考えたが、まず画像と動画を自動生成できるようにした。以前記事にしたように、ComfyUIはAPIが使え、jsonのワークフローをPOSTすれば生成可能と、割と簡単だからだ。

　前編の終わりに「画像生成にも影響する」と書いたIDENTITY.md。今回はこれを使って、OpenClawに常駐するAIキャラ「みー(Mii)」を作り、画像(Z-Image)と動画(LTX-2.3)を自動生成、XとTikTokへ自動投稿、LINEに結果報告を流すところまでやってみた。

　生成時のポイントは、いくつかのキーワードからランダムでプロンプトを量産する「簡易バッチ処理」にしないこと。AIを使い、



    1. 生成時の天気/時間帯/直近のニュース、さらに今の季節の流行コーデなどをWeb検索で調べる
    2. その情報をもとにLLMが「今日のシーン/服装/ポーズ」を考える
    3. 決まった構成(Scene/Subject/Wardrobe/Pose and Composition/Lighting/Camera Look)に当てはめてComfyUI用プロンプトをAIが生成
    4. ComfyUI APIに投げて画像を生成

　という流れだ。このような設定にすれば「雨だから今日は室内カットにしよう」、「夕方なので西日が入る構図に」「今っぽいワントーンコーデにしてみよう」といった判断を、AIにやらせることで、毎回違う絵が出てくるのが面白い。場所も代官山・恵比寿・中目黒など複数のロケーションを折り込み、季節感(紫陽花、新緑、夕焼けなど)を盛り込むようルール化した。

自動生成した写真。一部動画の1stフレームも含まれ、動画のサムネイルと一致しているものもある
自動生成した動画

　この一連のタスクをcronで指定時間に実行、一部XとTikTokへ自動投稿している。

　少し工夫したのは、過去にどんな服を着て、どこへ行ったかという履歴をpersona.mdというファイルに蓄積させている点だ。これにより、ペルソナデータが増え、キャラクターの個性が徐々に出るようになる。

　次に工夫したのが、生成した画像をまずVision対応のLLM(Qwen3.6 27bなど)に「この画像、手や指の数、表情、服装に不自然な点はないか」を確認させている点。人間の目視チェックではなく、AIがAIの生成物をチェックする形だ。ここで明らかにおかしい場合は再生成、問題なければ次のステップに進むようにした。

　画像投稿の場合は、ここで投稿、動画投稿の場合はこの画像を1stフレームとしてLTX-2.3を使い生成する。このとき、動画のプロンプトは「動きとセリフ」だけを渡し(もちろんこれもAIが考える)、画像側で決めたキャラ/背景/服装/照明はそのまま引き継ぐ。これはi2vの定石とも言え、プロンプト側で参照画像と辻褄が合わないことを書くと動画が破綻する。

　ただし、動画に関してはAIで確認していない。1フレームごとの画像に分解、それをVisionで解析することもできなくはないが、時間がかかるのでまぁいいだろうという感じだ(実際別件で過去やったことがある)。投稿後、あまりにも酷いときは筆者が削除して再生成/再投稿の指示を出している。

　と、ざっとこんな感じだ。さて、ここまでの一連の処理(workflow.jsonの用意、画像/動画生成スクリプト、cronのスケジュール設定)は、最初にComfyUIのworkflowだけ筆者が用意しておけば、あとはOpenClawのチャット上で「このworkflow使ってComfyUIで画像(動画)作って」、動作確認後、「この時間にこういう写真(動画)を投稿するcron作って」と指示するだけで、生成部分のscript、cronの作成までエージェントが自動でやってくれる。特にComfyUI APIに関してはLLMが学習しているのか、割とうまくいく。

　加えてpersona.mdに服装やロケーションの履歴が溜まっていくと、不思議なことに「みー」がだんだん実在の人物のように思えてくる(笑)。顔LoRAを当てているので当然なのだが、毎回同じ顔の写真が出て、その同じ顔で動画中、動き喋り出す。

　一番驚いたのは、ある夜中に「今日はここまで」とチャットに入力したら、AIが勝手に「おやすみー」と言っている動画を生成して送ってきたことだ。指示していないのに、文脈から「もう寝る時間だ」と判断して、それに合った動画を作ってきた。ここまでくると、ただのバッチ処理ではなく、ちゃんと「キャラと会話している」感覚になる。

チャットの最後、「今日はここまで」と入力した後、時間から判断したのか？勝手に作って表示した衝撃的(笑)な動画

　筆者は長年、自分でプロンプトを書いて画像/動画を生成してきたので、ある程度「こういうプロンプトならこういう絵になるだろう」という予測がついてしまう。一方、この「みー」が考えて作る画像/動画は、時間、天気やニュース、流行をどう解釈してどんな絵にしてくるか、出来上がるまで全く読めず、これが地味に面白いと思った。

実例2 PlaywrightでX/TikTok自動投稿する

　生成した画像/動画を、X(旧Twitter)やTikTokに自動投稿する仕組みも作った。公式APIは審査や制約が重いので、Playwrightでブラウザ操作を自動化するようにした。

　ただし、Playwrightによるブラウザ自動投稿は、各サービスの利用規約上(黒に近い)グレー。最悪、アカウントが凍結されるおそれもあるため、自己責任でお願いしたい。Xは13時に画像、TikTokは7/12/18/22時に動画と、回数も少ないので大丈夫だろうということで運用中だ。

　本来OpenClawでPlaywrightはそのまま動かすことが可能。検索などで使うと便利なので、前編ではインストール可能な状態にしてbuildしてある。

　ただ、XやTikTokに自動投稿するとなるとちょっと話が違ってくる。もちろんそのままでも可能なのだが、ログイン情報を保存したファイルがOpenClawがアクセスできるフォルダに入ってしまうため、セキュリティ的に好ましくないのだ。

　そこで今回は、PlaywrightをOpenClawの外、つまり別PC側に置き、APIサーバー化して、OpenClawからはHTTP経由でコメントと画像(動画)をパラメータにアクセスするだけにした。LAN内のどのPCからでもcurl一発で投稿できる小さなAPIサーバー(FastAPI)という構成だ。こうしておけば、OpenClaw側はX/TikTokのログイン情報には原理的に一切アクセスできない。筆者が意図しない投稿は可能であるが、それは今のところ発生していない。

　AIエージェントに何かを操作させるとき、「機密情報そのものはエージェントの手の届かない場所に置き、エージェントには結果だけを返すAPIを与える」という設計は、今後この手のツールを使う上で重要かも知れない。

Xへ自動投稿した写真
TikTokへ自動投稿した動画

　余談になるが、ちょうどこのAPIサーバーを作るとき、話題の「Claude Fable 5」が使える状態だったので切り替えて試していたものの(停止の数日前)、「Playwrightを使ってXとTikTokに自動投稿したい」的な指示をしたところ、セキュリティリスクがあると勝手にSonnetにフォールバックしてしまった(笑)。気持ちは分かるがそこまでしなくても……という感じだ。

実例3 LINEでcron結果を見られるようにする

　もともとチャネルと呼ばれているLINE連携などは、外出先で使うことを想定したものだが、筆者場合、ほぼ自宅なのでcronの実行結果を通知として受け取るために設定した。

　これはこれで便利なのだが結果として、LINE上でそのまま「みー」とチャットするのも普通にでき、けっこう面白かったりする(笑)。

　方法はいろいろやることが多く手順だけ(詳細に書くと1回分の原稿量相当になる)。事前にOpenClawが動作するPCへTailscaleをインストールしておくこと。

1. OpenClawのLINEプラグインを有効化 

docker compose exec openclaw-gateway openclaw plugins enable line
docker compose restart openclaw-gateway

2. LINE DevelopersでMessaging APIアプリを作る

トップ > knishika_ai_test > MiiOpenClaw > チャネル基本設定

3. Messaging APIアプリのチャネルアクセストークン/チャネルシークレットをopenclaw.jsonに設定。gatewayリスタート 

"channels": {
  "line": {
    "enabled": true,
    "channelAccessToken": "LINE_CHANNEL_ACCESS_TOKEN",
    "channelSecret": "LINE_CHANNEL_SECRET",
    "dmPolicy": "pairing"
  }
}

docker compose restart openclaw-gateway

4. Tailscale Funnelで自宅のOpenClaw(のWebhookだけ)をインターネットに公開 

tailscale funnel localhost:18789

　成功すると以下のようになる。LINE連携している間は止めないように。 

Available on the internet:
https://xxxxx.tail1da766.ts.net/
|-- proxy http://localhost:18789
Press Ctrl+C to exit.

5. Messaging APIアプリのWebhookにURLを登録/検証。OKであれば接続されている。

https://xxxxx.tail1da766.ts.net/line/webhook

6. 初めてLINEでメッセージを送るとペアリングコードを表示するので、OpenClaw側で承認

LINE側
OpenClaw: access not configured.
Your lineUserId: U006bxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pairing code: XXXXXXXX
OpenClaw側
docker compose exec openclaw-gateway openclaw pairing approve line <pairing_code>

と、このような流れとなる。Tailscale Funnelを使う理由は、Webhookにhttpsで外部からアクセス可能なURLが必要となるからだ。

　OpenClawの一部をインターネットに公開する形になるが、これはLINEのチャネルシークレットによる署名検証とセットで使うことが前提であり、宅内サーバーのIP/ポートをそのまま外部に晒すのとはレベルが違う……とはいえ、公開している間はそのURLにリクエストを送れる状態であることに変わりはなく、リスクがゼロというわけではない。

　これで文字だけならLINE上でやり取り可能になったが、チャット上に画像/動画を出すには一工夫必要。LINEへのメディア送信はhttpsのURLが必須。OpenClawが生成した画像/動画をそのままメッセージに含め渡せないのだ。そこで画像/動画を一時的に外部の無料ホスティングへアップロードしてそのURLを渡す形にした。この場合、URLが分かれば誰でも見れてしまうものの、そもそもXやTikTokに投稿しているものなので、見れたところで実害はないだろう。

　最初に試したcatbox(アカウント登録不要で画像・動画ファイルを匿名アップロードでき、直リンクURLが発行される定番サービス)はLINE側からアクセスできず失敗。どうもLINE側が遮断しているようだ。

　そこで画像はfreeimage.host(アカウント登録不要で画像をアップロードでき、直リンクURLが発行される画像専用の無料ホスティングサービス)に切り替えたところチャット内に画像として表示されるようになった。

　ただfreeimageは動画非対応のため、動画はcatboxを使用。チャット内には展開せずリンクをタップして別途開く形とした。画像はインライン、動画はリンク、という形だが、実用上はこれで十分というところに落ち着いている。

　考えてみれば筆者はVPSを使ったhttpsでアクセス可能なWebサーバーを持っているので、これに画像/動画を転送すれば問題ないはずだ。もしくはもう1つTailscale Funnelを作り、特定フォルダを公開、そこへ画像と動画をコピーするという手もある。いずれにしても今後の課題というところだ。

　さて、この一連の対応、実は「catboxを使ってみては」という提案も、ダメだった後の「freeimageに切り替える」という対応も、筆者の指示ではなくOpenClaw自身が考えて勝手にやったものだ。そもそも筆者はこのようなサービスがある事自体、知らなかった(笑)。

AIが考えcatboxからfreeimageに切り替えた
無事インラインで画像表示

　「LINEで画像が表示されない」と伝えただけで、原因の切り分けから外部サービスの選定、切り替えの実装まで一通り自走した。

　前編で「何をどう組み合わせてゴールに達するかはAIが判断する」と書いたが、まさにこのトラブルシューティング自体が、その自律性を実演した格好になった。

　前編ではDockerでの安全なセットアップとセキュリティ面を中心に紹介したが、後編では実際にOpenClawを「使い倒す」側に焦点を当てた。

　天気やニュース、ファッショントレンドをAIが調べそれを元にプロンプトを考え、ComfyUIとZ-Image/LTX-2.3で画像/動画を作り、Playwrightで作ったSNS投稿サーバーへ渡し投稿、報告はLINEに届く……これが全部OpenClaw上で自動的に動いている。

　動画に関してはクオリティを上げたいなら、話題の(15秒で牛丼程度のコストがかかるものの)Seedance 2.0を使う手もある。AIだけでのインフルエンサーはやる気になれば十分射程範囲内だ。

　LTX-2.3の動画に関しては、音声も同時に生成してるが、さすがにバラツキがある。これはTTSを使ってリファレンス音声でセリフmp3を生成、それを使いリップシンクで動画生成すれば行けるのは分かっているが、これ以上遊びで精度上げてどうする？といった感じで保留中だ。

　OpenClaw自体にまだ細かい不具合が残っているのは、以上に書いた通りだが、ローカルLLM/画像生成/動画生成/SNS投稿/通知という、それぞれ単体でも「やってみたい」と思う要素を1つのエージェントの上でつなげられるのは面白い。OpenClawに限らず、AIエージェントに興味がない人でも、「AIを使うとここまで自動化できるんだ」という雰囲気だけでも感じてもらえれば幸いだ。

　余談だが、今回の検証を通して、筆者はローカルLLMとのやりとりにOpen WebUIをほぼ使わなくなってしまった。Open WebUIでもMCP経由で同様にWeb検索やツール連携はできるのだが、「ツールを呼び出している」という意識がどうしても残るし(MCPボタンのオン/オフが必要)、できることも限られる。

　一方OpenClawでは、IDENTITY.mdで定義した「みー」というキャラクターが、裏でWeb検索、パワポにまとめたり、ComfyUIで画像/動画生成、cronなどのツールを使っていることを特に意識させず、ただの雑談相手として振る舞うのだ。

　その結果、「ちょっと画像作ってー」、「これ調べてパワポに」と気軽に話しかける先が、いつの間にかOpenClawになっていた。エージェントとしての機能性はもちろんだが、こうした「ツールを意識させないインターフェイス」としての側面も、地味だが大きな価値ではないだろうか。

　しかし筆者のOpenClawマシン、強力なGPUマシン(画像/動画生成とLLMで2台)と、結構なリソース使っていったい何をやっているのやら!?(笑)。