Paperclip - AIエージェントのタスク・権限・予算を統合する運用基盤

一つのエージェントに、その場で明確な作業を頼むなら、ターミナルやエージェント自身の履歴だけで足りることが多い。複数のエージェントに継続して仕事を任せると、事情が変わる。どのセッションが何を担当し、どこまで進み、次の起動時に何を引き継ぐかを、個別の画面だけでは追いにくい。PaperclipのREADMEも、多数のターミナル、散在する設定、手作業での文脈収集、費用超過、定期作業の手動起動を既存運用の問題として挙げる。これはエージェントの推論能力そのものより、仕事を割り当てて継続させる側の問題である。

エージェントへの指示には、目前の変更内容だけでなく、その作業が属するプロジェクトや上位目標も関わる。指示を毎回組み立て直す運用では、担当や優先度の判断が会話や設定ファイルに分散しやすい。Paperclipは会社と組織図で役割や報告関係を表し、Issueをプロジェクト、目標、親タスクへ結び付ける。ここでのIssueは単なる依頼文ではない。仕事の位置付けと実行履歴を保持する単位として使われる。READMEによれば、Issueのcheckoutと実行ロックは同じ作業の重複実行を防ぐ役割も持つ。

Paperclipが対象にするのは、モデルやエージェント内部の実装を統一することではない。READMEはClaude Code、Codex、OpenClaw、Cursor、CLIエージェント、HTTP/webhook botとの接続を挙げている。個々のエージェントが作業を実行し、Paperclipが担当、起動、予算、承認、記録を調整する構図だ。このため、すでに複数の実行手段を使っているチームほど管理層を置く理由が明確になる。一方、接続先ごとにどの操作まで扱えるかは、この資料だけでは判断できない。

起点は人による目標、役割、予算の設定と、プロジェクトや上位目標に紐付くIssueの作成だ。READMEによれば、エージェントは常時動き続ける前提ではなく、予定されたheartbeat、タスク割り当て、メンションなどで起動する。定期処理ではcron、webhook、APIを契機に追跡可能なIssueを作り、担当エージェントを起こすという。ここで「何をするか」はIssueに、「いつ起こすか」はheartbeatなどの契機に分かれる。この分離により、定期作業も一回限りの依頼も、後から追える作業単位へ載せられる。

READMEの説明では、起動要求はデータベースに支えられたwakeup queueに入り、サーバーが対象エージェントの実行へつなぐ。実行前には予算を確認し、Issueをcheckoutして実行ロックを取り、ワークスペース、必要なシークレット、スキルを解決する。その後、アダプタを通じて外部エージェントを呼び出す。キューが起動の順序と対象を扱い、Issueのロックが同一作業への重複した着手を抑え、アダプタが実際の作業手段との境界になる。これらはREADMEが示す設計上の動きであり、障害時の原子性や並列実行時の堅牢性まで、この資料から確認できるわけではない。

Paperclipの管理対象には、プロジェクト用ディレクトリと、Git worktreeなどを使う実行ワークスペースが含まれる。エージェントに仕事を渡す際、どこで作業させるかを解決するための層だ。READMEは、実行から構造化ログ、費用イベント、セッション状態、監査履歴が残り、エージェントがheartbeatをまたいでタスクの文脈を継続すると説明する。したがって、単発の起動を並べるだけでなく、Issueとセッション状態を軸に後続の実行へつなぐ構成と読める。ただし、文脈の保持範囲や、個別エージェントの再開機能との境界は接続先によって確認が必要だ。

費用管理は、後から合計額を眺める機能だけではない。READMEによれば、予算確認が起動の経路に入り、上限による停止を扱う。費用は会社、エージェント、プロジェクト、目標、Issue、プロバイダ、モデルの単位で追跡できるとされる。承認段階、エージェントの一時停止や終了、監査記録も同じ統制層に置かれる。これにより、人が確認すべき作業と費用をIssueの履歴に結び付けられる。ただし、予算停止の厳密さや承認を迂回できないことを示す検証結果は提示されていない。統制機能を導入理由にするなら、実運用の条件で確かめる必要がある。

構成の中心はNode.jsサーバー、React UI、PostgreSQLを使う管理層である。READMEはセルフホストを案内し、ローカルでは埋め込みPostgreSQL、本番では利用者が用意するPostgreSQLを使えると説明する。エージェントの実行を調整する側に、Issue、キュー、セッション、費用、監査の情報が集まるため、データベースとサーバーは運用上の要になる。ワークスペースやシークレットも実行時に解決される。外部のエージェントを接続できる自由度と引き換えに、この管理層の可用性、アクセス権、保存データの扱いは運用者が評価する領域になる。

適するのは、複数のエージェントへ目標に沿った作業を継続的に割り当て、定期タスク、費用上限、承認、監査履歴を一か所で扱いたいチームだ。Claude CodeやCodexなどは作業を実行する側に残り、Paperclipはその上で担当と起動を調整する。個々のエージェントを置き換える関係ではなく、補完する関係である。AsanaやTrelloのような一般的なタスク管理とはIssue管理の領域が重なるが、Paperclipはエージェントのheartbeat、実行ロック、セッション継続、費用制御まで扱う点に焦点がある。

README自身が、単一エージェントならPaperclipは不要かもしれないと述べる。作業の割り当てや費用確認を手で追える規模なら、サーバーとデータベースを増やす利点は小さい。また、デスクトップアプリと既存チケットシステムの直接利用はREADME上で未完了のロードマップ項目だ。Asana、Linear、Jiraなどを作業の正本として使い、直接連携を必須とする運用には、現時点の資料から適合すると言えない。

READMEの要件はNode.js 24.11以降で、ソースからの開発にはpnpm 9.15以降も必要とされる。匿名利用テレメトリーは初期状態で有効で、環境変数または設定で無効化できる。シークレットを実行時に扱い、複数エージェントへ仕事を振る構成なので、権限の分離、APIキーの扱い、並列実行時のローカル資源消費、プロセス監視を導入先で確認したい。これらについて安全性監査や性能測定の結果は、与えられた資料にはない。セルフホストであることだけを安全性や運用容易性の証明とは扱えない。

取得されたリリース一覧の最新掲載版はv2026.916.1である。直前のv2026.916.0では、安価なモデルを別に選ぶcheap model profilesが削除され、マイグレーション0236が保存済みのmodelProfiles設定を除去すると記載される。モデル別の費用調整をその設定に頼る運用では、更新前に影響を確認する必要がある。取得されたリリース本文は途中で切れているため、ここで挙げた変更以外の範囲は判断できない。機能の有無だけでなく、設定の移行も運用コストに含めて評価したい。