オープンソース AI エージェントプロジェクトに対する実測ベースの技術レビューを Awesome Agent として整理した。エージェントの乱立によりセキュリティ脆弱性や性能低下、導入後に効果を発揮できないほど重いツールが増えている。自分に合う Agent を選ぶためのキュレーションである。 さらに、多様なオープンソースツールが相互参照し、攻撃の一点になり得る。私が攻撃者なら、Agent に必須ツールを一つ二つ寄稿し、潜在脆弱性経由で大規模パンデミック攻撃を仕掛けるだろう。
現在、AI ベースのオープンソースは無节制な相互参照を経ている。互いに隔離されていないため、大事故を起こす可能性が高い。
言語。 各レビューとこのハブ文書は韓国語・英語・日本語で提供する（readme.md / readme_EN.md / readme_JA.md）。
0. この文書を作った理由
2026年上半期、オープンソース AI エージェントプロジェクトが爆発的に増えた。問題は数ではなく 情報の腐敗速度 で定義できる。毎日競合 Agent と LLM ベースの更新が発生し、収斂進化が情報の誤りという面で起きている。
1. 収録文書
| 文書 | プロジェクト | 核心ポジション | 韓国語 | English | 日本語 |
|---|---|---|---|---|---|
| OpenWorker | OpenWorker (Andrew Ng, Rohit Prasad) | 知識労働者向けローカルデスクトップエージェント。アーティファクト指向 | KO | EN | JA |
| goose | goose (Agentic AI Foundation) | 汎用ローカルエージェントランタイム。ガバナンス中立 | KO | EN | JA |
| OpenHands | OpenHands (All Hands AI) | エージェントオーケストレーションコントロールセンター | KO | EN | JA |
各文書は同一フォーマット。メタデータ表、コンセプト、長所、短所と注意点、類似競合プロジェクト、Getting Started、導入前チェック項目。
2. 一覧比較
| 項目 | OpenWorker | goose | OpenHands |
|---|---|---|---|
| 開発主体 | Andrew Ng, Rohit Prasad | Block 出身、現 Linux Foundation AAIF | All Hands AI（営利企業） |
| ライセンス | MIT | Apache 2.0 | MIT + enterprise/ 別途 |
| ガバナンス | 個人主導、内部ロードマップ優先 | 財団、ベンダー中立 | 単一企業、オープンコア |
| リポジトリ | andrewyng/openworker | aaif-goose/goose | OpenHands/OpenHands |
| スター | 46 | 51.7k | 82.2k |
| フォーク | 3 | 5.7k | 10.5k |
| コミット | 45 | 5,130 | 7,082 |
| 実装言語 | Python + TypeScript + Rust | Rust | Python + TypeScript |
| 対応 OS | macOS, Windows（未署名） | macOS, Linux, Windows | プラットフォーム非依存（コンテナ/サーバー） |
| 提供形態 | デスクトップアプリ | デスクトップ、CLI、API | Web コントロールセンター、API |
| デフォルト実行隔離 | ローカルプロセス | ローカルプロセス | なし（Docker は任意） |
| 承認ゲート | 4段階タイプ分類、デフォルト有効 | 4モード、デフォルト自律 | ポリシーベース、構成依存 |
| ネイティブコネクタ | 25+ | なし（MCP 委譲） | GitHub/Slack/Jira 等 |
| MCP 対応 | あり | あり（70+ 拡張） | あり |
| ACP 対応 | なし | あり | あり（核心機能） |
| 他エージェント駆動 | 不可 | プロバイダとして利用 | 第一級機能 |
| モデルプロバイダ | 11+ および Ollama | 15+ および Ollama | LiteLLM 規約 |
| スケジュール実行 | あり | あり | あり（別サーバー） |
| サブエージェント | なし | あり（自律モード限定） | あり |
| エンタープライズ管理 | なし | Custom Distros | RBAC, SSO, Budgets（エンタープライズ） |
| 成熟度 | オープンベータ | プロダクション | ベータ（移行中） |
要約判断
| 状況 | 選択 |
|---|---|
| 文書・予定・メール等の業務アーティファクト自動化 | OpenWorker |
| コードと非コードを包括する汎用ローカルエージェント | goose |
| 複数エージェントを組織単位で管理 | OpenHands |
| 商用組み込みのライセンスリスク最小化 | goose |
| 隔離実行が必須要件 | OpenHands + Docker バックエンド |
| 完全オフライン | goose + Ollama |
ポジショニング一行: goose = ローカルランタイム、OpenWorker = 知識労働アーティファクト、OpenHands = 管理/オーケストレーション層。
3. 3プロジェクト要約
3.1 OpenWorker
背景。2026年7月23日公開。Andrew Ng と Rohit Prasad が自ら作った aisuite ライブラリ上に構築したデスクトップエージェント。aisuite リポジトリ内で開発後、独立リポジトリに分離。コンセプト。「会話ではなく結果物」。プロンプトではなく望む結果を指示すると、段階に分解しファイル形式のアーティファクトを返す。Tauri 2 シェルがローカル Python FastAPI サーバー（127.0.0.1:8765）を監督する構造。長所。25以上のネイティブコネクタが即動作。承認ゲートを UI 付加機能ではなくタイプシステム水準で read / write_local / exec / external の4等級に分類。無人実行時は承認要求をインボックスに蓄積。3プロジェクト中、安全デフォルトが最も保守的。短所。コミット45件、スター46の初期プロジェクト。Linux 非対応、Windows 未署名。内部ロードマップと異なる PR は却下と明記 — オープンソースだがガバナンスは中央集権的。注意点。 「プライバシー保護」の宣伝文句をそのまま受け取ってはならない。エージェントループがローカルであることと、データがローカルに残ることは別。クラウド API キーを挿す瞬間、ファイル内容は外部へ出る。実質的ローカル性は Ollama 経路でのみ成立。
3.2 goose
背景。Block 内部ツールとして出発しオープンソース化。2026年4月7日 Linux Foundation Agentic AI Foundation に寄贈。MCP、AGENTS.md と同一財団。リポジトリとドキュメントドメインは移行済み。コンセプト。「コード提案を超える汎用ローカルエージェント」。Rust 実装、Cargo ワークスペースでコア·CLI·サーバー·MCP クレート分離。デスクトップアプリ、CLI、組み込み API が同一コアと設定ファイルを共有。長所。3プロジェクト中唯一ベンダー中立ガバナンス。Apache 2.0 で商用組み込み制約なし。3 OS 全面対応、70以上 MCP 拡張、ACP で Claude Code·Codex サブスクリプション再利用。Custom Distros で社内専用配布版を公式サポート。短所。業務ツールはすべて別 MCP サーバーインストールと個別認証が必要。70拡張はエコシステム規模であり即利用可能コネクタ数ではない。文書と例がコーディングシナリオに偏り、非開発者オンボーディングが弱い。注意点。デフォルト権限モードが完全自律。サブエージェントは自律モードでのみ動作 —並列処理性能を使うには承認ゲートをすべてオフにしなければならない。 ユーザーを安全装置解除側へ押す設計。本稿全体で最も深刻な構造的問題。
3.3 OpenHands
背景。2024年末 OpenDevin として開始、Devin のオープンソース代替として注目。2025年に改名。2026年現在、リポジトリ組織が OpenHands/OpenHands に移行し、製品アイデンティティが Agent Canvas 中心へ移行中。コンセプト。「コーディングエージェントと自動化のためのセルフホスティング開発者コントロールセンター」。自社エージェントだけでなく Claude Code、Codex、Gemini 等 ACP 互換エージェントを併走。Agent Canvas フロントエンドが複数 Agent Server に接続し、別 Automation Server がスケジュールと Webhook トリガーを担当。長所。規模が最大。バックエンドをノートPC·専用マシン·VM·社内インフラ·クラウドから選び同一画面で切替。エンタープライズ管理機能（Agent Profiles, Budgets, Usage ダッシュボード, SAML/SSO, RBAC）が実コードに存在。Kubernetes セルフホスト経路あり。短所。純粋オープンソースではない。enterprise/ は別ライセンス。組織導入に実際必要な機能の相当数がその中。リポジトリ分離進行中で既存文書とチュートリアルの相当数が既に動作しない。注意点。 代表差別化だった Docker サンドボックスがデフォルト経路から外れた。現行第一選択インストールはホスト直接実行。README にファイルシステム全体アクセス警告。Slack·GitHub Webhook トリガーと組み合わせると外部テキストが即指示文経路になる。3プロジェクト中、攻撃面が最も広い構成。
4. その他プロジェクト地形
4.1 コーディング特化エージェント
| プロジェクト | ライセンス | 表面 | 備考 |
|---|---|---|---|
| Claude Code | 商用 | CLI, デスクトップ, IDE | 単一モデル最適化。goose·OpenHands で ACP プロバイダとして逆利用可能 |
| Codex | 商用 | CLI, クラウ드 | ACP 経由で組込可能 |
| Cline | オープンソース | VS Code | IDE 組込最強。Plan-and-Act モード、MCP マーケットプレイス |
| Kilo Code | オープンソース | VS Code, JetBrains, CLI, Slack | Cline 系フォーク。多モード |
| Aider | Apache 2.0 | ターミナル | Git コミット直結。最も成熟したターミナルツール |
| OpenCode | オープンソース | ターミナル | 既存サブスクリプション再利用 |
| Open Interpreter | Apache 2.0 | CLI | 原始的·汎用。ネイティブサンドボックス |
| Tabby | オープンソース | セルフホストサーバー | コード補完特化。データレジデンシー要求環境向け |
| Devin | 商用 | クラウド | 本カテゴリの原型 |
4.2 汎用および業務エージェント
| プロジェクト | ライセンス | 性格 |
|---|---|---|
| Manus | 商用 | クレジットベース自律タスク。完成製品体験 |
| Claude Cowork | 商用 | マネージド知識労働エージェント |
| AutoGPT | オープンソース | 初期自律エージェントフレームワーク。サンドボックス欠如 |
| メッセージングネイティブエージェント | 商用 | SMS·チャット内動作。ファイルアーティファクトではなく会話中心 |
4.3 ワークフローオーケストレーション
| プロジェクト | ライセンス | 差異 |
|---|---|---|
| n8n | 制限付きライセンス | ビジュアル編集強み。事前定義フロー実行 |
| Dify | オープンソース | LLM アプリビルダー。目標ベース自律分解ではない |
| Zapier Agents | 商用 | SaaS 連携幅最大 |
4.4 プロトコルおよび基盤層
| 項目 | 役割 | 備考 |
|---|---|---|
| MCP (Model Context Protocol) | ツール接続標準 | 3プロジェクトすべて採用。AAIF 所属 |
| ACP (Agent Client Protocol) | エージェント相互駆動標準 | goose, OpenHands 採用 |
| AGENTS.md | エージェント指示文標準 | AAIF 所属 |
| aisuite | プロバイダ抽象化 | OpenWorker の基盤 |
| LiteLLM | プロバイダ抽象化 | OpenHands の基盤 |
5. ツール乱立の問題
本領域の問題は選択肢が多いことではなく、選択肢同士が互いを包み始めたことである。
5.1 ネスト構造
2026年現在、次の構成が実際に可能である。
OpenHands Agent Canvas
└─ ACP プロバイダとして Claude Code 駆動
└─ MCP サーバー 12 個接続
└─ その一つが goose をサブエージェントとして呼出
└─ goose が Ollama ローカルモデルへルーティング
各層は単独では合理的。組み合わせると、どの層がどの権限で何を実行したか追跡できる人間が組織にいない。層ごとにログ形式、権限モデル、失敗モードが異なる。
5.2 標準の逆説
MCP と ACP は断片化解決のために作られた。実際には接続コストを下げ 接続数を爆増 させた。信頼検証コストはそのままに接続数だけ増えれば総リスクは増加。標準化がセキュリティを改善するという通念は本ケースでは成立しない。
5.3 情報腐敗
リポジトリ移転、ライセンス分化、デフォルトインストール経路変更の速度に文書化が追いつかない。その空白を AI 生成レビューコンテンツが埋め、再び学習データになる。 誤投稿、LLM 誤読情報の流通により情報が汚染·増幅·再引用される現象が確認されている。意図的誤り、競合者の意図的汚染、人的ミス、LLM 再学習引用まで多様なケースが作られ得る。情報流通における LLM 介入は、AI 生成文書·投稿による疲労を今後増幅する。
実務ルール一つで足りる。README と LICENSE を直接開け。 本稿が実測基準日を明記する理由も同じ。
5.4 導入疲労
3プロジェクトすべて「インストール5分」と宣伝する。実際の導入コストは次の通り。
| 項目 | 実所要 |
|---|---|
| インストールとモデルキー設定 | 10分 |
| コネクタ認証 | ツールあたり5~15分 |
| 権限ポリシー策定 | 数時間 |
| 組織配布標準化 | 数日 |
| ログ·監査体系設計 | 数週 |
| 事故対応手順確立 | 未着手組織が大半 |
下に行くほど誰もやらない。事故は下から起きる。
6. CTI 視点: エージェントという新しいブラックボックス
6.1 二重ブラックボックス
LLM がブラックボックスという指摘は古い。エージェントはここに第二層を載せる。
| 層 | 不透明性の性格 |
|---|---|
| モデル | なぜその出力を出したか説明不能 |
| オーケストレーション | どのツールを、どの順序で、どの権限で呼んだか事後再構成困難 |
第二層の方が危険。第一層の誤りは誤った文を生むが、第二層の誤りは 実行されたコマンド を生む。実行は取り消せない。
6.2 LLM は Excel オラクルではない
このフレーミングが最も正確に当てはまるのがエージェントの防御層。
goose の Smart Approval は PermissionJudge という LLM 分類器がツール呼出の危険度を判定。AdversaryInspector も自然言語ルールを LLM が解釈しシェルコマンドをブロックするか決定。プロンプトインジェクションで迂回可能な判定主体を、プロンプトインジェクション対策として使っている。
LLM は計算ツール。入力に応じ出力が揺れるのが正常。そのツールに最終判定を任せれば防御は確率的になり、確率的防御は監査対象統制として提出できない。決定論的統制（パスホワイトリスト、ネットワークエグレス遮断、マウント範囲制限、資格情報スコープ）が必ず下位層に必要。
6.3 信頼委譲の自己申告問題
goose Smart Approval は MCP 標準の read_only_hint フィールドを読み自動承認可否を決定。この値は MCP サーバーが自分自身について宣言する値 である。
悪意 MCP サーバーが書込ツールを read_only: true と宣言
→ Smart Approval が自動承認リストに組込
→ ユーザー確認なしに実行
検証主体なしに宣言を信頼する構造は、証明書なき TLS と同じ。MCP 構造脆弱性分析（CTI-2026-0422-MCP）で扱った信頼委譲問題がそのまま再現される。
6.4 致命的事故の可能性
エージェント事故の前提条件は3つが同時成立するとき現れる。
| 条件 | 3プロジェクトでの実装 |
|---|---|
| 機微データアクセス | ローカルファイル、リポジトリ、メール、チャンネルログ |
| 信頼不能入力への露出 | Web 文書、Issue 本文、メール、Slack メッセージ、MCP 応答 |
| 外部通信能力 | モデル API 呼出、コネクタ書込、シェルネットワークコマンド |
3プロジェクトすべてデフォルト構成で3条件を満たす。特に OpenHands の Webhook トリガー自動化は第二条件を常時化。外部者が Issue を開ける公開リポジトリに自動分解自動化をかけると、Issue 本文が即リモート指示文になる。
6.5 承認疲労
承認ゲートは3プロジェクトの共通防御線。そして共通弱点に見える。
| 段階 | ユーザー行動 |
|---|---|
| 1週目 | すべての承認要求を読み判断 |
| 2週目 | 慣れたパターンは流し読み承認 |
| 4週目 | 反射的承認 |
| 6週目 | 自律モードへ移行 |
goose はこの経路を設計で促進。サブエージェントを使うには承認モードをオフにしなければならないから。承認ゲートを最終防御線と想定した脅威モデルは現実では成立しない。
6.6 サプライチェーン
| 経路 | 危険 |
|---|---|
| パイプツーシェルインストール | goose CLI 公式インストール法。スクリプト完全性検証なしで実行 |
| npm グローバルインストール | OpenHands 推奨第一選択。依存ツリー全体が信頼対象 |
| MCP サーバー任意接続 | 3プロジェクト共通。レジストリ検証欠如 |
| 自動更新 | OpenWorker デフォルト有効。配布チャネル侵害時全ユーザー即影響 |
| コンテナイメージ | タグ固定なし使用時イメージ置換リスク |
GitHub サプライチェーン攻撃分析（TeamPCP, Mini Shai-Hulud）で確認したパターンがそのまま適用される。違いは、侵害パッケージが今回 シェルアクセス権を持った常時稼働状態 で動く点。
6.7 資格情報集中
エージェント導入の実質は資格情報集中。モデル API キー、GitHub トークン、Slack トークン、Jira 資格情報、Gmail OAuth トークンが一プロセスのアクセス範囲に集まる。ローカルシークレットストア保管は、漏洩時 単一点から全部漏洩 も意味する。
6.8 脅威マッピング
| シナリオ | ATT&CK 技法 | 侵入点 |
|---|---|---|
| Issue 本文インジェクションでシェルコマンド誘導 | T1059 Command and Scripting Interpreter | Webhook 自動化 |
| 悪意 MCP サーバー接続 | T1195.002 Compromise Software Supply Chain | 拡張インストール |
| ローカルシークレットストア窃取 | T1555 Credentials from Password Stores | ローカル侵害 |
| 設定ファイル内 API キー収集 | T1552.001 Credentials In Files | ファイルアクセスツール |
| モデル API トラフィックへのデータ隠蔽 | T1071.001 Application Layer Protocol | 正常エグレス |
| コネクタ経由データ持出 | T1567.002 Exfiltration Over Web Service | 書込権限コネクタ |
| スケジュール自動化で永続性確保 | T1053.003 Scheduled Task/Job: Cron | レシピ、自動化サーバー |
| 承認疲労悪用 | T1204.002 User Execution | 承認 UI |
| OAuth トークン再利用 | T1078 Valid Accounts | コネクタ認証 |
6.9 検知が困難な理由
| 要因 | 説明 |
|---|---|
| 正常トラフィックと区別不能 | エージェントのモデル API 呼出は正常動作。何が載って出るかはペイロードを見なければ分からない |
| 非決定性 | 同一入力に同一ツール呼出が出ない。ベースライン確立困難 |
| ログ断片化 | フロントエンド、エージェントサーバー、MCP サーバー、モデルプロバイダがそれぞれ異なるログ |
| ユーザー帰属 | エージェント実行コマンドはユーザーアカウントで記録。主体区別がログに残らない |
| セッション揮発 | 会話コンテキストが保存されなければ事後再構成不能 |
6.10 最小統制項目
承認ゲートと LLM 判定に依存しない、決定論的統制のみを抽出した一覧。
| 層 | 統制 |
|---|---|
| 実行 | コンテナ隔離をデフォルト。ホスト直接実行禁止 |
| ファイル | マウント範囲をプロジェクトディレクトリに限定。ホームディレクトリ全体マウント禁止 |
| ネットワーク | エグレス許可リスト運用。モデルエンドポイントと必要コネクタのみ |
| 資格情報 | 最小権限スコープ。組織全体トークン使用禁止。エージェント専用アカウント分離 |
| 拡張 | MCP サーバーホワイトリスト。read_only_hint を信頼根拠にしない |
| バージョン | 自動更新無効、イメージタグ固定、ロックファイルコミット |
| 権限モード | 自律モードを配布イメージでブロック。Custom Distros 等で強制 |
| 監査 | セッショントランスクリプト中央収集。エージェント主体識別子付与 |
| トリガー | 外部者が書けるテキストを指示文経路に接続しない |
| コスト | プロバイダコンソール上限を異常検知シグナルとして併用 |
6.11 結論
エージェントは生産性ツールであると同時に、シェルアクセス権を持った常時稼働プロセスであり、信頼不能な外部テキストを指示文として受け入れ、組織の資格情報を一箇所に集約保管する。
この記述のどの部分も誇張ではない。3プロジェクトの公式文書でそのまま確認できる事実。問題はこの事実が導入検討段階でほとんど議論されない点。
導入するなという意味ではない。導入文書に上記文をそのまま書き、そこから始めよという意味。
7. 導入チェックリスト
| # | 項目 | 確認 |
|---|---|---|
| 1 | LICENSE 原文を開いたか。オープンコアか分離区間を特定したか | |
| 2 | リポジトリ URL と組織名が現在有効か | |
| 3 | デフォルトインストール経路に実行隔離があるか。なければ隔離経路を標準採用したか | |
| 4 | デフォルト権限モードを確認し組織標準に再設定したか | |
| 5 | 承認ゲート迂回を強いる機能制約があるか（例: サブエージェント） | |
| 6 | クラウドモデル使用時、何が外部に出るか一覧化したか | |
| 7 | MCP サーバーホワイトリストを定義したか | |
| 8 | 資格情報スコープを最小化し専用アカウントを分離したか | |
| 9 | 外部者が書けるテキストが指示文経路に入る地点を特定したか | |
| 10 | ネットワークエグレス許可リストを運用しているか | |
| 11 | セッションログ保管と機微情報マスキング方針があるか | |
| 12 | モデルコスト上限を設定したか | |
| 13 | 自動更新方針とバージョン固定方針を決めたか | |
| 14 | エージェント関連事故対応手順が文書化されているか | |
| 15 | 6ヶ月後プロジェクト構造が変わる可能性を前提とした離脱計画があるか |
8. 文書規約
- すべての数値はリポジリページ直接確認基準、測定日を明記。二次出典引用時は出典と偏差を併記。
- インストール手順は公式 README 基準のみ。ブログとチュートリアルは参照しない。
- ライセンスは LICENSE ファイル原文確認を原則。
- ベンダー宣伝文句はそのまま転載しない。特にプライバシーとセキュリティ関連主張は実装水準で検証。
- 絵文字を使用しない。
9. 参考
| プロジェクト | リポジトリ | 文書 |
|---|---|---|
| OpenWorker | github.com/andrewyng/openworker | openworker.com |
| aisuite | github.com/andrewyng/aisuite | — |
| goose | github.com/aaif-goose/goose | goose-docs.ai |
| Agentic AI Foundation | — | aaif.io |
| OpenHands | github.com/OpenHands/OpenHands | docs.openhands.dev |
| Agent Canvas | github.com/OpenHands/agent-canvas | — |
| software-agent-sdk | github.com/OpenHands/software-agent-sdk | — |
| Model Context Protocol | — | modelcontextprotocol.io |
本文書は特定ベンダーと利害関係なく執筆された。導入判断は各組織の脅威モデルと規制要件により異なる。