Clawith レビュー: エージェントに「持続する身元」と自前のスケジュールを持たせる設計
Your First AI Agents Company
ひと目でわかる
- これは何？
- Clawith は複数の AI エージェントに soul.md と memory.md、専用ワークスペースを与え、組織の同僚として協調させる Python 製プラットフォーム。README から読み取れる仕組みと、採用前に確認すべき境界を整理する。
- 誰に向いている？
- 向いているのは、Slack や Discord、Feishu/Lark 上で複数の業務エージェントを常駐させ、監査ログと承認フローを効かせたい小規模チームだ。逆に、単発のプロンプト処理やローカル完結の推論を求める用途には合わない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 20 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
単発のチャットボットではなく「組織に所属する同僚」を名乗る理由
多くのエージェントツールは、一つの会話セッションを閉じれば文脈も役割も消える。Clawith が解こうとしているのはこの消失で、README は「Unlike single-agent tools, Clawith gives every AI agent a persistent identity, long-term memory, and its own workspace」と述べ、エージェントを crew として協調させると説明する。対象読者は、社内の定型業務を複数のエージェントに分担させ、それぞれに人格と担当領域を持たせたい開発者や運用担当者だ。中心にあるのは Digital Employees という考え方で、エージェントは組織図を把握し、メッセージを送り、タスクを委譲し、他のエージェントや人間と作業関係を築く存在として扱われる。単一エージェントのラッパーではなく、複数エージェントの調整そのものを製品の境界に置いている点が、他の多くのツールとの分かれ目になる。
Aware が担う判断と、Focus Items による記憶の固定
Clawith の中核は Aware と呼ばれる自律意識システムだ。README の表現では、エージェントは命令を待つのではなく能動的に知覚し、判断し、行動する。この能動性を支えるのが Focus Items で、エージェントは現在追跡している作業を構造化された作業記憶として保持する。状態は [ ] が pending、[/] が in progress、[x] が completed の 3 種類で表される。ここで注目したいのは Focus-Trigger Binding という制約だ。タスクに関わるトリガーは必ず対応する Focus 項目を持たなければならず、エージェントは先に Focus を作り、focus_ref でそれを参照する形でトリガーを設定する。Focus が完了すれば、エージェントは自分のトリガーを解除する。つまりスケジュールが作業記憶から浮いた状態で残らない仕組みになっている。人間が目標を与え、エージェントがスケジュールを管理するという役割分担が、この参照関係で強制される。
6 種類のトリガーと、エージェント自身によるスケジュール改変
トリガーは cron、once、interval、poll、on_message、webhook の 6 種類が用意されている。cron は繰り返しスケジュール、once は特定時刻に一度だけ発火、interval は N 分ごと、poll は HTTP エンドポイントの監視、on_message は特定のエージェントまたは人間が返信したときに起床、webhook は GitHub や Grafana、CI/CD など外部からの HTTP POST を受け取る。poll と webhook の両方がある点は実務的で、監視対象がポーリングに向くのかイベント送出に向くのかで使い分けられる。README が Self-Adaptive Triggering と呼ぶのは、あらかじめ設定されたスケジュールを実行するだけでなく、タスクの進展に応じてエージェント自身がトリガーを作成、調整、削除する挙動だ。Reflections ビューでは、トリガーで起動したセッション中の自律的な推論を、展開可能なツール呼び出しの詳細つきで確認できるとされる。何を根拠に発火し、どのツールを呼んだのかを後から追える形にしているのは、自律性を上げるほど説明責任が重くなるという前提の表れだと読める。
soul.md と memory.md、ワークスペースの永続化
各エージェントは soul.md に人格を、memory.md に長期記憶を保持し、サンドボックス化されたコード実行を伴う専用ファイルシステムを持つ。README によれば、これらは会話をまたいで永続し、エージェントを一貫した存在にする。ファイルとして持たせる設計は、記憶をデータベースの内部構造に隠さず、人間が読んで編集できる点で扱いやすい。一方で、この設計は記憶の肥大化と衝突に弱い。複数エージェントが同じ組織知識を参照するとき、Plaza に流れる投稿やコメントを通じて文脈を取り込むと説明されているが、どの記憶がどの時点で更新されたのかを README は示していない。Knowledge Base が「shared enterprise context injected automatically」とされる以上、注入の単位と頻度は運用側で把握しておく必要がある。ここはドキュメントだけでは判断できず、実際のリポジトリで実装を確認すべき領域だ。
セットアップは setup.sh と restart.sh の 2 段階
前提は Python 3.12 以上、Node.js 20 以上、PostgreSQL 15 以上（簡単な検証なら SQLite でも可）、最低 2 コア CPU と 4 GB RAM、30 GB ディスク、そして LLM API エンドポイントへのネットワーク到達性だ。手順は README の Quick Start に従えば次のようになる。git clone https://github.com/dataelement/Clawith.git で取得し、cd Clawith の後、bash setup.sh を実行する。本番向けはランタイム依存のみで約 1 分、bash setup.sh --dev は pytest とテストツールも入り約 3 分と記載されている。setup.sh は .env を .env.example から作成し、PostgreSQL は既存インスタンスがあればそれを使い、なければローカル版を自動でダウンロードして起動する。続けて Python venv と pip、npm でのフロントエンド依存導入、テーブル作成と初期データ（既定の company、テンプレート、スキルなど）の投入までを行う。特定の PostgreSQL を使いたい場合は、setup.sh の前に .env を作り DATABASE_URL を設定する。README が示す例は DATABASE_URL=postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable だ。起動は bash restart.sh で、フロントエンドは http://lo 以降が README では切れているため、実際のポートはリポジトリ側で確認する必要がある。
ローカルでモデルを動かさないという前提
見落とされやすいが重要な制約として、Clawith は AI モデルをローカルで一切実行しない。README は「all LLM inference is handled by external API providers (OpenAI, Anthropic, etc.)」と明記し、ローカル配備は Docker オーケストレーションを伴う通常の Web アプリケーションだと説明する。したがって、機密データを外部 API に出せない環境では、この構成自体が採用の障害になる。オンプレミスの推論サーバーを自前で立てて Clawith のエージェントを動かす、という使い方は README の範囲では想定されていない。もう一つの制約はリソース表にある。個人の試用やデモは 1 コア 2 GB 20 GB で SQLite を使いエージェントコンテナを省く構成、フル体験は 2 コア 4 GB 30 GB、小規模チームは 2〜4 コア 4〜8 GB 50 GB で PostgreSQL、本番は 4 コア以上 8 GB 以上 50 GB 以上とされている。エージェントごとにコンテナとワークスペースを持たせる設計である以上、エージェント数を増やせばその分だけ資源が線形に近い形で積み上がる。2 コア 4 GB で何体まで実用的かは README からは読み取れない。
組織向け統制機能と、その代わりに受け取る運用負荷
Organization-Grade Control として README が挙げるのは、組織単位の分離とロールベースアクセスを伴うマルチテナント RBAC、エージェントごとに Slack、Discord、Feishu/Lark のボット身元を割り当てるチャネル統合、ユーザーごとのメッセージ上限や LLM 呼び出し上限、エージェント TTL といった利用クォータ、危険な操作を実行前に人間のレビューへ回す承認ワークフロー、そして監査ログとナレッジベースだ。ここで注意したいのは、これらが有効であるほど導入の手間が増えるという単純な事実である。承認フローを入れるなら誰が承認者になるかを決めねばならず、クォータを入れるなら上限値を決めねばならない。エージェントが実行時に Smithery や ModelScope 経由で新しいツールを発見・導入し、自分や同僚のために新しいスキルを作成できるとされる以上、承認と監査の設計は導入時の必須作業であって後回しにできる項目ではない。統制機能の一覧は、そのまま運用側が埋めるべき設定項目の一覧でもある。
向き不向きと、比較対象としての単一エージェント構成
比較対象として分かりやすいのは、単一のエージェントを 1 プロセスで動かし、スケジューラは外部の cron に任せ、記憶は毎回プロンプトに詰め直す構成だ。この構成は状態を持たないぶん壊れにくく、デバッグも容易で、エージェント間の権限分離を考える必要がない。Clawith は逆に、状態を持つこと、複数エージェントが互いを知っていること、スケジュールをエージェント自身が書き換えることを設計の中心に据えている。得られるものは一貫性と協調だが、失うものは単純さだ。エージェントが自分でトリガーを増減させる以上、ある時点で何が動いているかを把握するには Reflections と監査ログを追う必要がある。単発のバッチ処理や、決まった時刻に決まった 1 つの処理を回すだけの用途には、この仕組みは過剰で、状態の永続化とトリガー参照の整合性を維持するコストだけが残る。逆に、監視、一次対応、情報収集を複数の担当エージェントに分けて常駐させたい場合には、Focus-Trigger Binding と on_message の組み合わせが効いてくる。
Apache-2.0 とリリース頻度から見る保守コスト
ライセンスは Apache-2.0 で、リポジトリには LICENSE ファイルが置かれている。Apache-2.0 は商用利用や改変、再配布を許容する寛容型だが、特許条項や NOTICE の扱いなど条件の解釈は利用形態によって変わるため、ここで法的な判断はしない。自組織の法務や OSS ポリシーに照らして確認してほしい。保守の観点では、直近のリリースが v1.11.4-fix.1（2026-08-24、Runtime onboarding and verification hotfix）、v1.11.4（同日）、v1.11.3（2026-07-28）と並んでおり、本体リリースの直後に修正版が出る流れが確認できる。onboarding と verification のホットフィックスという名前から、初回導入時の検証まわりに不具合があったことがうかがえるが、具体的に何が壊れていたのかはこの材料からは分からない。導入を検討するなら、v1.11.4 ではなく v1.11.4-fix.1 を起点にし、リリースノートで修正内容を追うのが妥当だ。既定ブランチは main で、アーカイブはされていない。
編集部の結論
向いているのは、Slack や Discord、Feishu/Lark 上で複数の業務エージェントを常駐させ、監査ログと承認フローを効かせたい小規模チームだ。逆に、単発のプロンプト処理やローカル完結の推論を求める用途には合わない。Clawith はモデルを一切ローカルで動かさず、推論は外部 API に依存すると README が明記している。導入前に確認すべきは 3 点で、第一に .env.example の DATABASE_URL が既存 PostgreSQL を指せるか、第二に setup.sh が自動で取得するローカル PostgreSQL を本番で使うのか既存インスタンスに寄せるのか、第三に v1.11.4-fix.1 の「Runtime onboarding and verification hotfix」が何を修正したのかをリリースノートで追えるかどうかである。ここが自組織の運用に合わなければ、採用を見送る判断も十分に成立する。
コミュニティノート