OpenClaw 使用記録
OpenClaw は オープンソースの AI Agent 自動実行フレームワーク です。 その中核的な目標は、AI を単なる「対話」にとどめず、タスクを自動でプランニングし、ツールを呼び出し、操作を実行し、継続的にイテレーションして複雑な目標を達成できる ようにすることです。最近しばらく使ってみて、いくつかの内容をまとめました。
この記録を書いたきっかけは単純です。チャット型の AI を長く使っていると、その天井は「うまく答えられるか」ではなく「答えた後どうするか」にあると気づきます。コードの提案は出た、コマンドも列挙された、しかし実際に実行し、検証し、間違いを直すのは結局人間です。Agent フレームワークが解決しようとしているのはまさにこのラストワンマイル——「言う」を「やる」に変えることです。OpenClaw は私が最近実際にしばらく動かしてみたものの一つで、使用中の観察と問題を書き留めておきます。自分が後で見返すためでもあり、技術選定中の人への参考でもあります。
簡単に言えば、OpenClaw は次のように理解できます。
コードを自動で書き、コマンドを実行し、プロジェクトを分析し、タスクを継続的にイテレーションできる AI エンジニアリングアシスタント。
通常の ChatGPT や Claude と異なり、OpenClaw の設計目標は次のとおりです。
- AI に タスク実行能力を持たせる
- 複雑な目標を分解 できる
- 自動的に ツールを呼び出しコマンドを実行 する
- タスク完了まで イテレーションを継続 する
したがって、これはむしろ AI 自動化開発アシスタント(AI Software Engineer) に近い存在です。
OpenClaw — Personal AI Assistant
OpenClaw のコア能力
OpenClaw の能力は主に タスクプランニング + 自動実行 + ツール呼び出し の 3 つの面に現れます。
この 3 つは実は Agent システムの古典的なループに対応しています。モデルはまず目標に基づいて計画を生成し(プランニング)、次にツールを通じて実環境に働きかけ(実行)、そして実行結果——コマンド出力、エラーメッセージ、テスト結果——を観察としてモデルにフィードバックし(フィードバック)、それに基づいて次のアクションを修正します。このループをタスク完了とモデルが判断するまで繰り返します。この「プランニング—実行—観察」のクローズドループを理解すれば、OpenClaw の挙動は予測しやすくなります。
1) タスクプランニング(Planning)
ユーザーが OpenClaw に目標を与えると、例えば:
「このプロジェクトに Redis キャッシュを追加して」
OpenClaw は自動的にタスクを分解します。例えば:
- プロジェクト構造を分析する
- データベースアクセスのコードを見つける
- キャッシュ戦略を設計する
- コードを修正する
- テストを追加する
- 検証を実行する
このプロセスは AI が開発計画を自動生成する ようなものです。
強調しておきたいのは、この計画は一度生成されたらそのまま最後まで実行されるわけではないということです。1 ステップ完了するごとに、モデルは残りのステップを見直します——例えばプロジェクト構造を分析した結果、JPA ではなく MyBatis が使われていると分かれば、その後の変更方針もそれに合わせて調整されます。計画は生きているのです。これこそが Agent と「モデルに一度でスクリプトを出力させる」やり方との本質的な違いです。
2) タスクの自動実行
OpenClaw は提案を出すだけでなく、次のことができます。
- コードの修正
- ファイルの作成
- Shell コマンドの実行
- 依存関係のインストール
- スクリプトの実行
例えば:
# 対象プロジェクトをローカルに取得
git clone project
# プロジェクトの依存関係をインストール
npm install
# テストを一通り実行し、変更が既存機能を壊していないか検証
npm run test
AI はこれらの操作を直接実行できます。
実行の鍵は結果のフィードバックにあります。コマンドの stdout、stderr、終了コードはすべて次のラウンドのコンテキストに入ります。テストが落ちれば、モデルは具体的にどのテストケースがどんなエラーで失敗したかを見て、自分で修正しにいきます——これが「タスク完了までイテレーションを継続する」の具体的な姿です。
3) ツール呼び出し能力
OpenClaw は Tool を通じてさまざまな能力を呼び出せます。例えば:
- ファイルシステム
- Shell
- Git
- HTTP API
- コンパイルツール
- テストフレームワーク
ツールとは本質的に、モデルに公開された説明付きインターフェースの集合であり、モデルはタスクに応じてどれを呼び、どんなパラメータを渡すかを自分で決めます。この仕組みは拡張可能です。社内システムをインターフェースでラップして登録すれば、Agent はそれを操作できるようになります。能力の境界はフレームワーク自体ではなく、どれだけのツールをつなぐ気があるかで決まります——もちろん、つなげばつなぐほど、権限管理はより慎重にする必要があります。
OpenClaw の欠点
OpenClaw は非常に強力ですが、現時点ではいくつかの明らかな問題が残っています。
1) モデル能力への強い依存
OpenClaw の能力は 基盤となるモデルに大きく依存 します。
モデルの能力が不足すると:
- タスクプランニング能力が低下する
- コード品質が低下する
- 実行でエラーが起きやすくなる
そのため多くの場合:
Agent の能力 ≈ モデルの能力
モデルが弱ければ、OpenClaw も「かなり間抜け」になります。
この問題は Agent のシナリオでは増幅されます。通常の対話ならモデルが一言間違えても、人が一目見て訂正できます。しかし複数ステップの実行ループでは、最初のステップの誤ったプランニングが後続のすべてのステップに継承され、エラーは蓄積していきます。フレームワーク側のプロンプトエンジニアリングでカバーできるのは一部だけで、モデル自体の推論力の弱さまではカバーしきれません。
2) Token コストの問題
Agent システムには通常、次のものが必要です。
- 複数ラウンドの思考
- 複数回のモデル呼び出し
- 継続的なコンテキスト
Token の消費が非常に大きく、毎回大量のコンテキストを携えてモデルを呼び出します。チューニングしても一部のコストを削減できるだけで、あるいは安いモデルに置き換える手もありますが、安いモデルに置き換えると上記の問題が発生し、OpenClaw は完全に信頼できず、制御不能になってしまいます。
原因は難しくありません。毎ラウンドの呼び出しには、タスク目標、過去の操作、ファイル内容、コマンド出力を含める必要があり、コンテキストはイテレーション回数にほぼ比例して増大し、しかも毎ラウンドが完全なモデル呼び出しです。複数ステップのタスクを一つこなすと、消費は単発の対話の数十倍になることもあります。コストと能力はここで避けられないトレードオフになります——お金を節約して弱いモデルにすれば、最初の問題がすぐに襲ってきます。
ハマりどころと注意点
前述の 2 つの欠点を踏まえて、実際の使用ではいくつかの提案があります。
- 本番環境で直接動かさないこと。 Agent は本当にコマンドを実行します。ファイル削除も設定変更も、本当に削除され本当に変更されます。コンテナや隔離された作業ディレクトリの中で動かし、権限は最小限にしましょう。
- タスクは小さく分割すること。 目標が大きいほどプランニングは脱線しやすく、コンテキストの膨張も速くなります。「キャッシュを 1 つ追加する」は「データ層全体をリファクタリングする」よりずっと確実です。
- 実行プロセスを見張ること。 前述の実行プロセスが不透明という問題について、監視プラットフォームが整っていない状況では、少なくとも完全な操作ログを残し、事後にそれが何をしたのか追跡できるようにしておくべきです。
- コストに上限を設けること。 複数ラウンドのイテレーションによる Token 消費は簡単に制御不能になります。特にモデルがある間違いに対して繰り返しリトライしているときは要注意です。ラウンド数の上限や予算上限を設定し、朝起きたら請求書が爆発していた、という事態を避けましょう。
総評
OpenClaw は非常にポテンシャルのある AI Agent フレームワーク です。
メリット:
- 自動タスクプランニング
- 自動実行能力
- 拡張可能な Agent アーキテクチャ
デメリット:
- モデルへの強い依存
- Token コストが高い(モデル呼び出しが非常に多く、複雑なタスクの能力は完全にモデル次第)
- 実行プロセスが不透明(非常に深刻。実行プロセスは完全にブラックボックスで、コントロールプレーンと組み合わせて監視しないと使えない)
したがって、現時点では次の用途に向いています。
- AI 自動化開発
- DevOps 自動化
- AI Agent の実験
しかし、次のものと組み合わせれば:
- 強力なモデル
- 可視化システム
- Agent 管理プラットフォーム
将来はこうなるかもしれません。
AI 自動化チームの中核インフラストラクチャ。
まとめ
Agent フレームワークの価値は、モデルの出力を実環境につないでクローズドループで実行することにあり、OpenClaw はこの道において十分に完成度が高いです。プランニング、実行、ツール呼び出しの 3 つがすべて揃っています。しかしその上限はモデルの能力に縛られ、下限はコストと透明性に足を引っ張られています。現段階での私の使い方は、小さいタスク、隔離環境、ログを見張りながら動かす、というものです。周辺の監視・管理エコシステムがもう少し成熟してから、より重要なフローへの投入を検討するつもりです。
COMMENTS