マルチエージェント管理にPaperclip AIは使える？導入・料金・権限の実像

確認日：2026年11月7日。 本レビューは、公開中のドキュメントと公式リポジトリを確認したものです。評価は仕様として記載された動作と具体的なワークフロー例に基づいており、実環境への導入や生産性の実測は行っていません。

Paperclip AIはどんなツールですか？

Paperclipは、AIエージェントが共通の仕事に取り組むためのオープンソースのサーバーとブラウザ用ダッシュボードです。担当者、仕事が結びつく目標、使ってよい予算、レビュー担当をまとめて管理します。実際に作業するエージェントランタイムの上に、Node.jsのバックエンドとReactの画面が載る構成です。公式アプリケーションのリポジトリは、プロジェクトのサイトとドキュメントからリンクされている**paperclipai/paperclip**です。Paperclipは調整、権限、記録、スケジュールを担い、接続したエージェントがツールやモデルへのアクセスを提供します。言語モデルでも、完成済みの事業でもありません。「会社」という仕組みに見立てているからといって、人を介さず会社を運営できると実証されたわけではありません。本レビューで扱うのはpaperclip.ingのオーケストレーションプロジェクトです。無関係のPaperclip Inc.や、ペーパークリップ最大化の思考実験とは別のものです。

マルチエージェント管理にPaperclip AIを選ぶべきですか？代替ツールとの比較

Paperclipが向いているのは、すでに役立つエージェントを使っていて、担当の割り当て、支出、レビューの調整が必要になった創業者や技術に詳しい運用担当者です。エージェント自体が範囲の明確な仕事を安定して完了できない段階では、組織図を加えても、原因を調べるシステムが増えるだけです。

選ぶ基準は、解決したい問題です。以下では各製品を運用上の役割で比較しています。併用も可能です。

これは機能の比較であり、ベンチマークでいずれかの製品が他を上回ったという主張ではありません。評価するのは、引き継ぎの見通し、権限の境界、支出の把握、作業停滞時の立て直しです。自分のワークフローでこれらが改善されるなら、そのツールを使う意味があります。

別々のエージェントセッション間で指示や結果を日常的に転記している、止まったタスクの担当者がわからなくなる、異なるランタイムに共通のレビュープロセスを設けたい。こうした状況なら、週末を使ってPaperclipを試してみてください。実装とドキュメント作成を調整する創業者や、調査とレビューを定期的に回す運用担当者には、具体的な導入目的があります。

会社名を決めてAIのCEOを置けば、後は任せられると期待しているなら、導入は待つべきです。ホストを保守し、認証情報を点検し、成果物を評価する人がいない場合も同様です。単発のコーディングであれば、継続的な調整の問題が生じるまで、今のコーディングエージェントを使い続けるほうがよいでしょう。

PaperclipとOpenClawはどう使い分けますか？

TelegramやSlackなどからメッセージを送れるアシスタントが今すぐ必要なら、OpenClawから始めるほうが適しています。公式概要には、セルフホスト型ゲートウェイ、ツール利用、定期実行の自動化、複数エージェントへの振り分けが記載されています。単一のチャットセッションを超える機能をすでに備えているため、エージェント数だけを理由に別のプラットフォームを加える必要はありません。

ランタイムをまたいで担当が明確なキュー、予算、レビュー段階を共有する仕組みが足りないなら、Paperclipを選びます。その配下でOpenClawを実行担当として使い続けることもできます。ただし、管理層と運用すべき接続が増えます。OpenClaw自体の設定が不要になるわけではありません。アシスタントとしての選び方は、OpenClawレビューで解説しています。

Hermes Agentから始めたほうがよいのはどんな場合ですか？

Nous Researchが開発するHermes Agentは、仕事の継続性が課題のときに適しています。繰り返す業務の中で、有用な文脈を記憶し、手順を再利用してほしい場合です。公式リポジトリには、永続メモリ、利用中に作成・改善できるスキル、スケジュール実行、サブエージェントへの委任が記載されています。

定期的な調査レポートを作る運用担当者なら、それで十分かもしれません。記憶された文脈と保存済みの手順は、頼りにする前に点検してください。レポート作成が、担当者、承認、支出管理を分けた大きな業務プロセスに組み込まれた段階でPaperclipを加えます。PaperclipにはローカルHermesアダプターも用意されているため、今Hermesを選んでも、後から調整の仕組みを追加できます。出発点としての評価は、Hermes Agentレビューで詳しく扱っています。

役割とチケットで引き継ぎを確認できるようにする

Paperclipが日々の運用で力を発揮するのは、委任した仕事を担当者と記録に結びつけておける点です。創業者は、別々のターミナル上の会話から経緯を再構成せずに、タスク、議論、成果物を確認できます。

小規模なソフトウェア企業が、顧客データのエクスポート機能を改善する場面を考えてみます。創業者の目標は、コード変更を集めることではなく、使えるエクスポート機能を得ることです。よいタスクには、対象レコード、権限の扱い、結果が空の場合の動作、レビューに必要な検証結果が明記されています。

作業の流れは次のようになります。

1. 製品目標とプロジェクトに結びつけたタスクを、実装担当エージェントに割り当てます。
2. 変更内容と、必要なチェックの実施結果を添付させます。
3. 同じ合格基準を添えて、完了した作業をレビュー担当に回します。
4. 具体的な不備を実装担当に差し戻し、やり取りをタスク上に残します。
5. リリースへ進む前に、責任者が成果物を受け入れます。

Paperclipはタスクと引き継ぎの仕組みを提供します。依頼を理解し、変更を加え、信頼できる検証結果を示すのはエージェントの仕事です。タスクボードが整っていても、エクスポートしたデータの正しさまでは証明できません。

Issueのワークフローに関するドキュメントでは、実行前にタスクをチェックアウトし、別の実行がそのIssueを確保している場合は競合を返す仕組みが説明されています。同じタスクを重複して引き受ける問題への対策です。ただし、別々のタスクが同じファイルを安全に編集できるという意味ではありません。実行用ワークスペースとリポジトリの運用方法は、別途検討する必要があります。

組織構造のガイドでは、CEO以外のエージェントには上司があり、仕事の委任は下へ、障害の報告は上へ進む指揮系統を説明しています。エクスポート機能の例なら、管理担当が実装とドキュメント作成を別タスクに分けられます。実際に責任を分ける必要が生じる前から、部署を作る必要はありません。

意味のある引き継ぎを試せる、最小限のチームから始めてください。全エージェントに立派な肩書きを付けても、専門性は増えません。何を担当し、何を返し、いつ上位へ判断を求めるかが指示に明記されてこそ、役割が機能します。

コンテンツ制作なら、調査、執筆、レビューという分担が考えられます。調査タスクに資料を残し、事実確認を合格基準に含めます。サポート業務なら、問い合わせの分類と返信案の作成から始めます。送信まで任せられるかは、顧客とのやり取りに責任を持つ人が判断すべきです。

得られるのは、経緯を確認できる委任プロセスです。仕事が止まったら、担当者、認証情報、明確な要件、判断のいずれが欠けているかを調べられます。それぞれ別の問題なので、対処も変わります。

実行できる作業はランタイムと導入設定で決まります

Paperclipはアダプターを介してエージェントランタイムに接続します。アダプターは、エージェントを起動し、タスクの文脈を渡し、結果を回収する部品です。ランタイムとは、モデルがツールを使って仕事を進めるためのソフトウェアです。その内部で推論や文章生成を担うのがモデルです。

この違いを理解すると、Paperclipのインストールに成功してもエージェントが動かない理由がわかります。実行先に選んだランタイムが存在し、認証が通り、必要なファイルやサービスにアクセスできなければなりません。

対応ランタイムとモデル

Paperclipのアダプター一覧には、選択可能なローカルアダプターとしてAnthropic Claude Code、OpenAI Codex、Google Gemini CLI、Cursor Agent CLI、OpenCode、Pi、Hermes Agent、Grok Build、Kimi Codeが記載されています。Cursor CloudとHermes Gatewayのリファレンスもあります。独自コマンドやHTTPサービス向けには、汎用の連携経路が用意されています。

OpenClaw Gateway、Process、HTTPは、通常の設定手順とは扱いが異なります。ランタイムのサポートは機能していますが、エージェント設定の選択画面ではComing soonと表示されます。APIやインポート経由の設定が可能で、OpenClawには招待フローがあります。この表示を見て、画面からすべて設定できるとも、まったく未対応だとも判断しないでください。

現行ドキュメントには、実験的なネイティブ実行経路であるPaperclip Runnerも記載されています。既存の直接接続アダプターは別のままで、有効にしただけでは移行しません。Paperclipを制御層と捉える説明は有用ですが、独自の実行基盤を一切持たないと言い切るのは正確ではありません。

使えるモデルは、選んだ経路と認証情報によって決まります。

• Claude Code経由のClaude： Claudeアダプターのリファレンスでは、モデルIDの指定に対応し、可能なら設定済みAPIからモデルを取得し、それができなければ組み込みリストを使います。選んだClaudeモデルに、ランタイムとアカウントの両方が対応している必要があります。
• Codex経由のOpenAIモデル： Codexアダプターのリファレンスでは、モデルの指定をCLIに渡します。未指定ならCLIの既定値を使います。IDを手入力できても、接続先のアカウントで利用できる保証にはなりません。
• 複数プロバイダーとローカルエンドポイント： モデルコネクターのカタログでは、対応ハーネスを通じたAnthropic、OpenAI、OpenRouter、xAI、互換のカスタムまたはローカルエンドポイントを扱っています。OpenCodeではprovider/modelを明示して選び、インストール済みのopencode modelsコマンドで候補を確認します。

Gemini、Grok、Kimiも、それぞれのランタイム経由で利用します。Paperclipに、すべてを自由に置き換えられる共通のモデルメニューがあるわけではありません。まず使い慣れたランタイムを選び、そのアダプターの環境テストでモデルを確認してください。ローカルモデルのエンドポイントにも、必要なAPIとエージェント動作への対応が求められます。URL欄を埋めるだけでは互換性を確認できません。

エクスポート機能の例なら、使い慣れたコーディング用ランタイムを選ぶことで、試行時の不確定要素を減らせます。未知のモデル、慣れない実行ホスト、新しい管理システムを同時に導入すると、失敗の原因を特定しづらくなります。

Paperclip AIのエージェントを設定するには？

週末の評価には、Paperclipをローカルで動かす方法が適しています。必要なバージョンのNode.jsをインストールしたら、公式の初期設定コマンドを実行します。

npx paperclipai@latest onboard --yes

通常のユーザー権限で実行してください。インストールガイドでは、既定の組み込みPostgreSQLがrootや管理者権限での実行を拒否するため、そのようなシェルを使わないよう注意しています。初期設定では~/.paperclip/配下にローカルの状態が作成され、ブラウザ画面がhttp://localhost:3100で起動します。

最初のエージェントを作るガイドに従い、会社を作成し、最初のエージェントを設定して、初回の戦略承認を確認します。アダプターを選び、対応する認証情報を接続し、使用モデルを選択して、Test your agentを実行します。これは実行環境のチェックです。接続できても、業務ワークフローの品質が確認できたことにはなりません。

本格的な仕事を割り当てる前に、作業ディレクトリ、初期の予算ポリシー、レビュー責任者を確認します。タスクに見合ったアクセス範囲のリポジトリやアカウントを使ってください。大まかな売上目標ではなく、具体的な成果物を指定すると、最初の結果を客観的な基準で判定できます。

Paperclipはどこでホストできますか？

Paperclipは、自分のコンピューター、Docker、自分で運用するサーバーで実行できます。デプロイのリファレンスでは、ローカルの信頼済みモードと、認証付きのプライベートネットワークおよび公開環境を区別しています。ローカルの信頼済みモードはループバック接続専用で、人間用のログインがありません。インスタンスを共有する場合は、適切な認証設定が必要です。

データベースのリファレンスは、組み込みPostgreSQL、別のローカルデータベース、ホスト型PostgreSQLに対応しています。Dockerの公式Compose手順は、後述のFAQに載せています。データボリュームは必ず保持してください。空の状態でアプリケーションコンテナーが起動しても、組織を復旧できたことにはなりません。

ノートパソコンがスリープ中でも定期作業を続けたいときは、サーバーが役立ちます。同時に、稼働維持、更新、バックアップ、認証情報の管理が運用者の責任になります。外部のホスティングサービスもあり、Hostingerのマネージド導入ガイドでは、VPSとは別にマネージドPaperclipサービスを説明しています。公式リポジトリには現在Paperclip Cloudのウェイティングリストが案内されていますが、それだけで公式ホスティングプランが一般提供されているとは言えません。

OpenClawについては、ゲートウェイアダプターのガイドにWebSocket接続とデバイスのペアリングが説明されています。手動設定は、会社設定のGenerate OpenClaw Invite Promptでプロンプトを生成し、それをOpenClawのメインチャットに貼り付ける流れです。通常のアダプター選択画面で設定できると思い込まず、この手順を使ってください。

ガバナンスは設定した範囲で機能します

Paperclipには有効な統制機能がありますが、それぞれ対象となる操作が決まっています。エージェントの採用承認、完了したタスクの受け入れ、外部ツール呼び出しの許可は、別々の判断です。

まずは組織の変更です。承認ガイドには、新しいエージェントやCEOの戦略に関する申請と、予算関連の承認が記載されています。採用を審査するときは申請全体を開いてください。短い要約だけでは、ランタイム設定、利用可能な予算、指揮系統の詳細をすべて確認できません。

エクスポート機能の例なら、新しいレビュー担当には明確な仕事と、実装を点検するためのアクセス権が必要です。CEOが求めたという理由だけで追加エージェントを承認しても不十分です。そのレビュー担当が追加で示すべき検証結果と、意見が割れたときに誰が判断するかを決めておきます。

次に、タスクの実行ポリシーで完了前のレビューや承認を必須にできます。設定すると、エージェントが完了にしようとした時点で処理を止め、必要な段階に回します。レビューで変更を求められた仕事は、実装担当に戻ります。人間による受け入れが必要なら、参加者として人を指定してください。レビュー担当がエージェントなら、それも別のエージェントにすぎません。

エクスポートの例では、実行前に必要な検証結果を決めます。サンプルファイル、アクセス制限のチェック、空のエクスポートの動作などです。レビュー担当は、具体的な不具合と期待する動作を返す必要があります。「改善してください」では、次の修正も曖昧になりがちです。

外部への操作には別の設定が必要です。Paperclipのコネクターでは、ツールゲートウェイ経由の操作にAllowed、Ask first、Offを指定できます。人の判断を待つべきリリース操作にはAsk first、そのエージェントに実行させない操作にはOffを使います。タスクの受け入れと、変更を公開する権限は分けて管理してください。

実務上の違いはここにあります。レビュー段階を設ければタスクが完了扱いになるのを防げますが、作業中に使うすべてのツールが許可制になるとは限りません。逆に、外部操作を承認しても、その結果が元の要件を満たすかどうかは別問題です。後述する既定値とシェルの例外により、この区別が重要になります。

介入が必要なら、一時停止、再割り当て、終了を使います。設定のロールバックは設定を元に戻すためのもので、送信したメール、削除したレコード、デプロイまで取り消せる保証ではありません。外部への影響に対応する責任は、ワークフローの運用者に残ります。

定期業務を担当者と履歴のあるタスクにする

Paperclipでは、定期業務を担当者と履歴のあるタスクにできます。複数のエージェントが起きて「何か仕事はありますか」と確認するだけの状態より有用です。現行のハートビートとルーチンのガイドは、通常の仕事の割り当てにはイベント駆動の起動を推奨し、一定間隔のハートビートは既定で無効にしています。

ハートビートとは、エージェントが起動し、割り当てられた文脈を読み、行動する実行機会です。タスクの割り当て、コメント、ルーチンが起動のきっかけになります。タイマーは定期確認が本当に必要なときに有用ですが、エージェントを利用可能にしておくための必須条件ではありません。

ソフトウェア企業の創業者なら、定期的なリリース準備状況のレポートが候補になります。未完了の作業、未解決のレビューコメント、不足する検証結果を抽出し、確認用の報告を返すよう指示します。見つけた変更をすべてリリースしなければ成功と見なせないようなルーチンから始めないでください。

単純な計算でも、タイマーを増やしすぎない理由がわかります。5エージェントを5分間隔で起動すると、毎時60回のタイマー起動機会が生まれます。 これはクールダウンや実行の集約を考慮する前の値です。スケジュール上の計算であり、トークン費用の見積もりでも実測の負荷でもありません。新しい仕事がなければ、動作を確認するためだけに費用を払うことになりかねません。

何をきっかけに仕事を始め、停止期間の後にどう動かすかを決めるのは運用者です。週次レポートなら、古くなった実行枠を飛ばしてもよいかもしれません。レコード処理なら、未処理分への対応方針が明示的に必要な場合があります。どちらも「動かし続ける」だけでは仕様になりません。

Paperclipの料金は？

MITライセンスのPaperclip本体は$0です。セルフホスト版のライセンス料をPaperclipに払うのではなく、モデルとホスティングの費用を負担します。

運用費は、モデルへのアクセス方法、エージェントの実行量、システムを動かす場所によって変わります。接続先のサービスから別途請求される場合もあります。創業者の導入環境を一律の月額で正確に表すことはできません。AIのサブスクリプションがあっても、ホストや外部ツールがすべて無料になるわけではありません。

予算設定ガイドでは、既定で**80%**に達すると警告し、**100%**で実行を止めると説明しています。会社とエージェントの予算はUTCの暦月単位で、プロジェクト予算は既定で累計上限です。組織全体とエージェントごとの両方に上限を設け、特定のエージェントが予算全体を制限なく使い切らないようにします。

制限は記録済みの支出を基準に適用されます。すでに実行中の作業や利用状況の報告の遅れによって、実際の請求が設定額を超える場合があります。価格未確定の利用や計上待ちの状態によって、新しい仕事が保留されることもあります。費用が空欄または不明でも、無料で実行できた証拠にはなりません。

試行では、支出とともに受け入れた成果物と自分のレビュー時間を記録します。実行費用が安くても、何度も修正が必要なら割に合わない場合があります。本レビューでは本番業務を動かしていないため、受け入れた成果物あたりの費用は測定していません。範囲を絞った試行で、自分の環境の数値を確かめてください。

週末の試行でつまずきやすい制約

Paperclipの制約で特に影響が大きいのは、ダッシュボードが制御する範囲と、実行担当エージェントにできることの境界です。ワークフローを広げる前に、次の設定と運用上の問題を解消してください。

ゲートウェイの承認設定はワークスペースのシェルを制限しません

Paperclipの操作権限ドキュメントによると、通常の新規接続では、有効な操作は書き込みや破壊的な操作も含めてAllowedで始まります。接続のPermissions設定を明示的に変更してください。サービスを接続しただけで承認が必須になると思い込まないことが大切です。

同じページにはシェルの例外も記載されています。操作ごとのポリシーが対象とするのはツールゲートウェイであり、エージェントのワークスペースで実行されるコマンドではありません。特に、紐づけたGitHubのIDを使うシェル上のGitとghは、ツールごとのAsk first制御の対象外です。

エクスポート機能の例なら、ゲートウェイ経由の書き込みをAsk firstにしても、コーディングエージェントが別のシェル認証情報で変更をプッシュできない保証にはなりません。ゲートウェイのポリシーに加え、ワークスペースと認証情報の範囲も制限します。タスクに「先に確認する」と書くのは指示であり、こうした設定の代わりにはなりません。

ランタイムの設定も重要です。OpenCodeアダプターのリファレンスでは、無人実行向けにdangerouslySkipPermissionsが既定で有効となり、一時設定の権限ルールを許可動作に置き換えると説明しています。既存のランタイムのルールを尊重させたい場合は、最初の実行前にこの設定を確認してください。

新規エージェントには予算ポリシーがない場合があります

Paperclipの費用に関する詳細ガイドによると、アプリ内のエージェント設定フローでは予算ポリシーが作成されません。予算カードがないのは単なる表示漏れではありません。対応するCLIまたはAPIの手順で上限を設定してから、Audit → Budgetsでカードを編集する必要があります。

もうひとつ注意したいのが金額の0です。これは予算ポリシーを無効にする値で、「支出を一切認めない」という意味ではありません。数字だけで保護されていると判断せず、作成されたポリシーと適用状態を点検してください。

組織カードがない新しい会社についても、ドキュメントでは初回の上限をAPIから設定するよう案内しています。ブラウザでの初期設定は概ね簡単ですが、この作業では別の手順が必要です。エージェントの活動を増やす前に済ませておきましょう。

レビューのエスカレーションには責任を持つ人が必要です

Paperclipの実行ポリシーのリファレンスでは、エージェントからの修正要求が連続する場合、人に判断を上げるまでの上限は既定で3回です。タスクのresponsibleUserIdを使い、なければcreatedByUserIdを使います。

どちらの人間のIDもなければ、作業は実装担当に戻り続けます。 回数だけが増え、想定した人への引き継ぎが起きないことがあります。自動作成されたタスクや外部連携では特に重要です。承認者の役割にエージェントがいるかだけでなく、人間の責任者が記録されているかを確認してください。

創業者の試行では、エージェントが作成した後続タスクの責任者を意識して確認します。実現不可能な要件をめぐってレビュー担当と実装担当が対立したら、誰かが範囲を絞らなければなりません。合格基準そのものが矛盾していれば、レビュー担当を増やしても解決しません。

検証に使える情報はアダプターによって異なります

Paperclipの実行記録からわかることは、ランタイムから受け取る出力と利用状況のメタデータに左右されます。汎用のProcessとHTTPアダプターはプレーンな出力を返し、より高機能なアダプターは構造化されたツールイベントやセッション状態を返せます。アダプター一覧には、ネイティブのCursorとGrok経路では、実行ごとの確定的な費用合計が得られないことも記載されています。

ダッシュボードを一元化しても、すべてのエージェントから同じ水準の検証情報を得られるとは限りません。試行中は、選んだ経路で成果物、エラー、モデル利用状況、セッションの継続性を必要な範囲まで把握できるか確認します。結果を点検できなければ、自信に満ちた「完了しました」というメッセージだけでは不十分です。

システム運用の責任は残ります

Paperclipを加えると、保守すべきサーバー、データベース、アダプター、認証情報が増えます。ローカル実行は便利ですが、ノートパソコンがスリープしたり、フォアグラウンドのプロセスが止まったりすれば定期業務は動きません。リモートホストで可用性を高められるのも、保守する人がいてこそです。

インストール済みのバージョンとドキュメントを合わせ、データベースとシークレットの状態を保持し、実行ホストでどのランタイム認証情報が使えるかを把握してください。会社単位の記録は整理の境界として役立ちますが、任意の実行プロセスが相互に隔離されている証拠とは捉えないでください。

調整が継続的な負担になっているなら、こうした運用コストを払う意味があります。能力のある単一エージェントにたまに依頼する程度なら、同じ運用負担が導入を待つ理由になります。

Paperclip AIの評価：導入を続ける判断基準

すでに働くエージェントがあり、担当の明確化、管理された引き継ぎ、支出の共通把握が必要なら、Paperclipは範囲を絞って試す価値があります。エージェント自体を役立つようにする段階や、事業上の判断までプラットフォームに代行してほしい段階では時期尚早です。

判断基準は明確です。 同じ反復業務の割り当て、点検、立て直しが楽になり、成果物が合格水準を満たし、人間の責任者も明確なら、Paperclipを使い続けます。役割や承認キューの維持に、以前の業務そのものより手間がかかるなら、試行を終えます。

月曜に取り組む仕事として、顧客データのエクスポート機能の変更か、自分の事業で同程度に範囲を絞れるタスクを選んでください。使い慣れたランタイム、狭いワークスペース、明確な合格基準から始めます。委任を許す前に、正の金額で支出上限を設定し、書き込み権限を絞り、人間の責任者を記録します。

そして、見栄えではなく引き継ぎの質を評価してください。

• 全エージェントに尋ねずに、次の対応の担当者を特定できますか？
• レビュー担当に、成果物を受け入れるか差し戻すか判断するための検証結果が届きますか？
• 必要な承認設定は、実際の実行経路をカバーしていますか？
• タスク履歴と支出記録から、一時停止や失敗の理由を説明できますか？
• 受け入れた成果物は、モデル利用費、レビューの手間、保守の負担に見合っていますか？

成功したデモでは、エージェントが何かを実行します。実用的な導入では、その行動を完了した仕事として認めてよいか判断できるだけの検証情報が得られます。Paperclipに任せる範囲を広げる前に、満たすべき基準はそこです。

よくある質問

最初に委任する価値のある業務を選ぶには、AI業務ワークフロー監査チェックリストを活用してください。