OpenClawとは何なのか

OpenClawは、AIエージェントプラットフォームだ。雑に言えば「AIに仕事を任せるための基盤」で、LLM（大規模言語モデル）をベースに、MCP（Model Context Protocol）という仕組みで外部サービスと接続し、Skill（スキル）と呼ばれるタスク定義を通じて、自律的に業務を遂行する。

Slack、Asana、Google Workspace、MicroCMS、GitHub——普段使っているサービスをMCPで繋げば、AIがそれらを横断して操作できる。チャットで指示を出すだけでタスクを作成し、記事を下書きし、スケジュールを確認してくれる。いわば「全サービスのAPIを理解したインターン」が24時間常駐しているようなものだ。

Ragateでは2026年3月23日からこのOpenClawの本格導入を開始した。ここから先は、その過程で何がうまくいき、何に苦しんだのかを正直に書く。

インフラ構成

まず、今回用意した環境の全体像を整理する。

方針としては、メインの推論はAnthropicのClaudeを使い、軽量なタスクやフォールバック用にローカルLLMを走らせる二段構えだ。

苦戦その1：MLXとの別れ

ローカルLLM環境を構築するにあたり、最初に試したのはApple純正のMLXフレームワークだった。Apple Siliconに最適化されているという触れ込みで期待していたのだが、結果から言うと不採用になった。

理由は2つある。まず、MLXのサーバー機能が実用レベルに達していなかった。OpenClawとMLXの間にプロキシを挟む構成を取ったのだが、ストリーミングレスポンス周りでインシデントが多発した。リクエストが途中で切れたり、レスポンスが返ってこなかったりする。

もう1つは、API規格の問題。MLXはOpenAI互換のAPI（chat/completions）を提供しているが、実態としてはOpenAI-response規格より前の仕様で動いており、Function CallingやTool Useといった機能が正常に動作しない。MCPを通じてツールを呼び出すOpenClawとは根本的に相性が悪かった。

苦戦その2：ローカルLLMモデルの選定

MLXを諦めてOllamaに切り替えた後、次の課題はモデル選定だった。

最初に検討したDeepSeekは、日本語性能は悪くなかったものの、Function Callingに非対応だった。OpenClawはMCPを通じてツールを呼び出す仕組みなので、Function Callingが使えないとそもそも連携が成立しない。この時点でDeepSeekは候補から外れた。

日本語を優先しつつFunction Callingにも対応しているモデルを探すと、選択肢はQwen系にほぼ絞られた。最終的に採用したのがDeepSeek-R1-Distill-Qwen-14B-4bitだ。DeepSeekの推論能力をQwenアーキテクチャに蒸留したモデルで、日本語力と推論力のバランスが取れている。

ただし、14Bパラメータのモデルは Mac mini のメモリには重かった。推論中にスワップが頻発し、レスポンスが極端に遅くなる。「めちゃくちゃ遅い」という表現がそのままの実感だ。RAMの節約が最優先課題となり、量子化レベルの調整やモデルサイズの縮小で対応した。

苦戦その3：コンテキストサイズの壁

OpenClawにはコンテキストサイズの最小値が設定されている。その値は16,000トークン。クラウドのLLMであれば何の問題もない数字だが、ローカルLLMにとっては大きい。

コンテキストサイズが大きいほどメモリ消費は増え、推論速度は落ちる。OpenClawの設計思想としては精度を保つための下限値なのだろうが、メモリが限られたローカル環境では苦しいトレードオフだった。このあたりは、将来的にハードウェアのスペックアップで解決するしかない。

苦戦その4：Asana連携の罠

MCPを通じた各種サービスとの連携は、基本的にはスムーズに進んだ。Slack連携は早い段階で安定し、Google Workspace MCPも問題なく動作した。しかし、Asanaだけは手こずった。

タスクの発行がうまくいかない。APIリクエスト自体は通るのだが、フィールドのマッピングやプロジェクトの指定で微妙なズレが生じる。OpenClawのSkill定義とAsana APIの仕様の間にギャップがあり、その調整に想定以上の時間を取られた。

苦戦その5：「ノールック実装」の教訓

これは技術的な問題というより、AIとの付き合い方の話だ。

セットアップの過程で、設定ファイルの作成やスクリプトの実装をAIにかなり任せた。いわゆる「ノールック実装」だ。指示を出して、出てきたものをそのまま使う。これが9割以上はうまくいく。だが残りの1割で、意図しない方向に設計が曲がっていく。

たとえば、プロキシの構成やデーモンの登録方法など、アーキテクチャの根幹に関わる部分は自分で理解してから指示を出さないと、後から修正コストが膨れ上がる。AIは命じられたことを実行するが、全体の設計意図までは汲み取れない。1割の意思決定は、やはり人間がやるべきだ。

うまくいったこと

苦戦の話が続いたが、成果もしっかりある。

特にSlack連携の安定感は想像以上だった。メンバーが自然にOpenClawに話しかけ始め、チームの一員として機能し始めている。「ロブスターがいい感じに育ってきた」という実感は、数値では測りにくいが確かに手応えがある。

今後の技術的な展望

現時点のボトルネックは、明確にローカルLLMのハードウェアリソースだ。Mac miniのメモリではモデルサイズに制約があり、推論速度も限界がある。

夏頃には、より高スペックなサーバーを調達する予定だ。十分なGPUメモリを確保できれば、ローカルLLMでも大きなモデルを快適に動かせるようになる。用途に応じてモデルを使い分ける構成にも対応しやすくなる。

また、OpenClaw上でのSkill開発もまだ始まったばかりだ。コンテンツマーケティングの自動化、動画やHTMLメールの生成、SNSのリアクション自動集計など、やりたいことのリストは長い。技術的にはMCPの拡張とSkillの充実が鍵になる。

OpenClawの導入は、正直なところ「すんなりいった」とは言えない。MLXの挫折、メモリとの戦い、ノールック実装の失敗。でも、それらを乗り越えた先に、確かに使えるAIエージェント基盤が立ち上がった。この経験が、同じようにAIエージェントの社内導入を検討しているエンジニアの参考になれば幸いだ。