OpenWorker：Andrew Ng のオープンソース AI エージェント

プロンプトに答えるだけでなく、仕事を最後までやり遂げる AI システムが欲しいなら、OpenWorker の核心は一行で言えます。タスクを計画し、ツールを使い、リスクの高い操作の前には承認を求めて立ち止まる ということです。

私ならこうまとめます。OpenWorker はオープンソースでローカルファーストのエージェントフレームワークで、デスクトップアプリとローカルの Python サーバーを介して動作し、ジョブをクラウドとローカルのモデルに振り分け、4 段階の権限レベルでファイルアクセス、コマンド実行、外部へのメッセージ送信を制御します。データをより厳密に管理したい、モデル間のセットアップの手間を減らしたい、リスクのある操作の前に明確な人間のチェックを入れたい、というチームに向いています。

短くまとめると次のとおりです。

• 何をするか： ゴールを複数ステップのワークフローに変換する
• どう動くか： Tauri 2 デスクトップアプリ + React 18 UI + ローカルの FastAPI/Uvicorn サーバー
• モデルアクセス： aisuite を通じたクラウドプロバイダーとローカルモデル、さらにローカル利用向けの Ollama
• 安全性モデル： read、write_local、exec、external
• 人間によるレビュー： すべての exec および external ステップは承認を待つ
• 連携ツール： ファイル、カレンダー、Slack、その他のチームシステム
• モデルエンドポイントの選択肢： OpenAI 互換の単一 API による APIMart
• 最も適した業務： レポート、リサーチ、コンテンツパッケージ、サポート業務、メディアパイプライン
• 本番運用に必要なもの： トレーシング、評価、プロンプトのバージョン管理、支出の追跡、送信前レビュー（アウトボックス）フロー

いくつかの事実が際立ちます。OpenWorker は 4 種類のアクションタイプを使い、人が承認するまで exec と external のアクションを 100% ブロックし、ワークフローのロジックを変えずに GPT-5、Claude Sonnet 4.6、Gemini 3 Pro Preview といったモデルを切り替えられます。

自分のチームに合うかどうかを判断するなら、まず一つのことを見ます。明確なステップがある反復的な業務があり、リスクのある操作に人間の承認が必要か？ もし「はい」なら、OpenWorker は理にかなっています。

Andrew Ng：AI エージェントの現状 | LangChain Interrupt

OpenWorker の仕組み：アーキテクチャ、モデル、権限

OpenWorker の信頼性は、ローカル実行、モデルルーティング、承認ゲートという 3 つの層から生まれます。

デスクトップアプリとローカルエージェントサーバー

OpenWorker は React 18 UI を備えた Tauri 2 デスクトップアプリケーションとして動作し、FastAPI と Uvicorn を使うローカルの Python 3.10+ サーバーと組み合わされます。平たく言えば、デスクトップ上に見えるアプリが、あなたのマシンで動くローカルサーバーと並んで連携して働きます。

この構成により、エージェントはデータとユーザーの両方の近くに保たれます。サーバーはデフォルトで localhost をリッスンするため、制御の観点でも物事をより引き締めやすくなります。

クラウドとローカル LLM をまたぐモデルルーティング

OpenWorker は aisuite を使って、クラウドのモデルプロバイダーと Ollama のようなローカルランタイムの間でリクエストを振り分けます。これにより、すべてを一つの経路に流すのではなく、各タスクをどこに送るべきかをチームが決められる余地が生まれます。

たとえば、プライベートなタスクはローカルに保ち、リスクの低い作業は別の場所に振り分けられます。データが機微であれば、タスクを Ollama 経由でローカルモデルに送れます。

タスク計画、型付きアクション、承認ゲート

OpenWorker にゴールを与えると、そのゴールを個別のステップに分解し、何かを実行する前に各アクションへ権限タイプを割り当てます。つまり一つの大きなブラックボックスではなく、確認とレビューが可能な一連のステップが得られます。

4 つの権限タイプはリスクレベルに直接対応します。

承認ゲートは、人が承認するまですべての exec と external アクションをブロックします。この制御モデルこそが、次の連携の層を実用的にしています。

ツール、連携、そして APIMart を活用したモデルアクセス

ファイル、カレンダー、Slack、チームシステムをまたいだ作業

OpenWorker は、組み込みツール、ホスト型の連携、コネクタを通じて、ローカルファイル、カレンダー、Slack、その他のチームシステムに接続します。^[4] そのため、単発のタスクだけでなく、連携した業務の自動化にも役立ちます。

実際にはこのようになります。オペレーションチームが OpenWorker に週次のパフォーマンスレポートを作成し、チームで共有するよう依頼します。エージェントはローカルの分析エクスポートを読み込み、共有フォルダに整った文書をまとめ、主要な指標を含む Slack の要約を下書きし、そしてチームの外に何かを送信する前に承認を求めて立ち止まります。^[4] 調整は OpenWorker が行います。何を送るかは、依然として人が決めます。

コンテンツやマーケティングのチームも、同じ構成をコンテンツパッケージに使えます。OpenWorker はローカルファイルから元となるリサーチを引き出し、ブリーフやブログ文書を下書きし、チームカレンダーにレビュー期限を記録できます。誰かが承認するまで外部システムには一切触れません。^[4]

統一モデルエンドポイントとしての APIMart の利用

ツールが接続できたら、次のステップはモデルアクセスです。OpenWorker は単一の OpenAI 互換ベース URL を通じて、APIMart を統一モデルエンドポイントとして利用できます。^[2][3]

セットアップはかなりシンプルです。

• APIMart の API キーを作成する
• チャット、補完、メディアリクエスト向けに標準的な OpenAI 互換 JSON ペイロードを送信する

OpenWorker から見ると、APIMart は一つの安定したプロバイダーのように見えます。しかしその単一のエンドポイントの背後で、チームはエージェントのワークフローをまったく変えずに GPT-5、Claude Sonnet 4.6、Gemini 3 Pro Preview といったモデルを切り替えられます。つまりルーティング層は一つで済み、チームが使うモデルにまたがる保守の手間が減ります。

コンテンツ・メディアチーム向けのマルチモーダルワークフロー

同じルーティング構成は、テキストを超えたマルチモーダルな作業もサポートします。APIMart を使えば、OpenWorker はリサーチからスクリプト、動画生成まで一つのエンドポイントで移行できます。^[1]

週次で動画コンテンツを制作するチームであれば、OpenWorker はリサーチ、スクリプト作成、アセット生成、レビュー準備というパイプライン全体を調整でき、その裏で APIMart がモデル選択を担います。ワークフローは同じままです。変わるのはモデルだけです。

OpenWorker を本番環境で安定して運用する

本番利用には、モデル、タスク、チームをまたいだトレーシング、制御、コストの可視化が必要です。すでに整った権限とモデルルーティングの上に構築されるこのセクションでは、それらの土台を実際に機能させる運用層を扱います。次のステップは、その構成を本番環境で観測、監査、制御できるものに変えることです。

トレーシング、評価、プロンプトのバージョン管理

本番環境での信頼性は、あらゆる実行のあらゆるステップを可視化することから始まります。

すべてのエージェント実行は、実行状態の全体をログに残すべきです。会話の状態、ツールの入力と出力、使われたモデル、トークン数、ステップごとのレイテンシです。それがなければ、デバッグは当て推量になります。それがあれば、ワークフローがどこで失敗したかを正確に把握し、他の部分を乱さずにその箇所を修正できます。

プロンプトのバージョン管理も同じくらい重要です。チームが出力品質を高めるためにシステムプロンプトを更新すると、すでに動いていた何かを壊してしまう可能性が常にあります。既知の良好な入力と期待される出力の小さなセットであるゴールデンテストを、すべてのプロンプト変更に対して実行しておくと、本番に到達する前にリグレッションを捉えられます。ゴールデンテストは、デプロイ前にプロンプトのリグレッションを捉えます。

機微な操作に対するリスク制御と人間の監督

エージェントが共有システムに影響を及ぼしうる場合、実行にはレビュー可能な引き渡しが必要です。

機微な操作には、アウトボックスパターンを使います。エージェントは、実行前にレビューするために意図したアクションを記録します。^[5] これは共有システムに適した方法で、被害が生じた後ではなく、実行前に人間のレビューが行われるべきです。

これは先に設定した exec と external の権限タイプに直接結びついています。アウトボックスパターンが、これらのリスクの高いアクションの最終的な引き渡しを管理します。より複雑なマルチエージェント構成では、inbox/、outbox/、workspace/ ディレクトリを中心に組んだフォルダ構造が、データの境界を明確に保ち、引き渡しを予測可能にします。^[5] 各エージェントはどこから読み、どこへ書くかを把握しているため、パイプラインの監査が容易になります。

APIMart ルーティングによるコストとモデルの管理

ワークフローが稼働し始めると、コスト制御は運用上の要件になります。

APIMart を中央エンドポイントとすることで、チームは支出の追跡、価格上限の設定、レイテンシの監視を一か所で行えます。すでにマルチモデルのワークフローを運用しているなら、中央集約型のルーティングは、プロバイダーごとに別々のキー、SDK、ダッシュボードを管理するオーバーヘッドを削減します。

直接キーでは、コストの急増は請求サイクルの終わりになって初めて見つかることが多いです。APIMart ルーティングなら、ワークフローが高コストな問題になる前に、チームは価格上限とルーティングルールを設定できます。

実践的なユースケースとまとめ

リサーチ、コンテンツ運用、メディアワークフロー

ワークフローの制御が整うと、OpenWorker は反復的で大量の作業でその真価を発揮しがちです。タスクが同じ一連のステップを何度も繰り返すときに、最もうまく機能します。

だからこそ、マーケティング、リサーチ、メディアのワークフローによく合います。チームは、プロセスのさまざまな部分を調整し、最終的な出力をブランド基準と照らし合わせることで、コンテンツの組み立てを自動化できます。あるパイプラインでは、チームは単一のエンドポイントを通じてコピーを下書きし、画像を生成し、短い動画を作成できます。

この構成により、リサーチからテキスト、画像、動画の生成への移行がはるかにスムーズになります。ツールを手作業でつなぎ合わせる代わりに、チームはフロー全体を一か所で実行できます。

サポート、オペレーション、社内業務の自動化

同じ考え方は、社内のサポートやオペレーションにも引き継がれます。OpenWorker は単純な返信を送る以上のことができます。注文状況の確認、パスワードのリセット、請求に関する依頼といったルーチンタスクに対して、回答し、検証し、行動を起こせます。

チームにとってこれが重要なのは、社内業務の多くが難しくないからです。ただ反復的なだけです。OpenWorker は、機微な操作を承認ゲートの背後に置いたまま、その業務を前へ進める手助けをします。

まとめ：チームが今日つくれるもの

これらのワークフローを合わせて見ると、OpenWorker が今どこで最も強いかがわかります。オープンソースの設計により、チームはカスタマイズ、データ、コストを直接コントロールできます。この構成は、ローカルファーストの実行と、仕事を始めるだけでなく最後までやり遂げる実用的な自動化を軸に組まれています。

賢い始め方はシンプルです。大量で反復的なワークフローを一つ選び、価値を証明し、それから拡大するのです。

よくある質問

OpenWorker は誰に最適ですか？

OpenWorker は、AI をデモから信頼性の高い本番運用可能な自動化へと移したい部門横断的なチーム、開発者、事業部門に最も適しています。

リサーチ、コンテンツ運用、カスタマーサポート、業務プロセスの自動化にまたがって複数ステップのワークフローをスケールさせたいチーム、とりわけカスタマイズ、連携、コストを自分たちの管理下に置きたいチームに向いています。

OpenWorker は機微なデータをローカルに保てますか？

はい。オープンソースのエージェントフレームワークはローカルデプロイをサポートすることが多く、開発者は機微なデータを自分たちのシステム内に保ったままエージェントを構築・テストできます。

ローカルデプロイのモデルとファイルベースの通信プロトコルを使えば、チームは厳格なデータ境界を維持し、運用を社内に留められます。

チームはまずどのタスクを自動化すべきですか？

大量でルールベースのワークフローから始めましょう。最良の初期対象は、反復的で、計測しやすく、すでに CRM、ERP、ヘルプデスクといったシステムに結びついているタスクです。

良い最初のユースケースには、カスタマーサポートのトリアージと請求書処理が含まれます。なぜこれらを最初に？ 大がかりなプロセス改修なしに、手作業を素早く減らし、サービスコストを下げられるからです。

そこから、チームは文書処理、データ抽出、コンテンツ生成へと広げられます。