Paperclip約 11 分で読めます

Paperclipの内側——「AI会社」が最初のコマンドからどう動くか

合同会社Fujigoソフトウェアソリューション

M&C Holdings（日本）のメンバー

2026年3月15日

2026年、AI agentを1つ動かすのは簡単です。10個のagentを同時に動かし、しかも互いに足を引っ張り合わないようにする——これこそが本当の課題です。前回の記事では、PaperclipはAI agentを管理する「会社」のようなものだとお伝えしました。しかし具体的に、その会社はどのように運営されているのでしょうか——サーバーを起動してから、最初のagentが仕事を始めるまで。

Control plane——PaperclipはAIを動かすのではなく、AIを組織する

「AIプラットフォーム」と聞くと、多くの人はAPIを呼び出し、promptを処理し、modelを学習させるシステムを思い浮かべます。Paperclipはそのいずれも行いません。

Paperclipは control plane ——誰が・いつ・どれだけの予算で・何をするかを決定する調整レイヤーです。OpenAI APIやAnthropic APIを直接呼び出すことはありません。コードを書くこともありません。コードを書く実体を管理するのです。

こう考えてみてください。ソフトウェア会社のCEOは自分でコードを書きません。CEOはtaskを割り振り、進捗を追い、成果をレビューし、コストを管理します。Paperclipはまさにそれを行います——ただし、AI agentのために。

各agentはそれぞれ独自の adapter 上で動作します。Claude Code、Codex、あるいはあなたが選ぶ任意のLLMです。adapterは実行の「筋肉」が宿る場所です。Paperclipはtaskを渡し、状態を追い、コストを記録し、誰も任務から逸脱しないことを保証するだけです。

Control plane = 組織する頭脳。Adapter = 実行する筋肉。この2つを明確に分離することが、Paperclipにおける最も重要な設計上の決定です。

Heartbeat——なぜagentは常時稼働しないのか

あなたは5つのAI agentを雇いました。5つすべてが24時間365日、常時稼働し、毎分APIを呼び出し、毎分tokenを消費します。月末、請求書が届きます——そしてあなたは、その800ドルがどこに消えたのか分かりません。

Paperclipはこの問題を heartbeat ——agentのための「目覚まし」の仕組みで解決します。

常時稼働する代わりに、各agentは眠った状態にあります。順番が来たとき(または新しいイベントが発生したとき)、Paperclipはagentを起こします。agentは目を覚まし、やるべきtaskがあるか確認し、仕事をし、結果を報告し、そしてまた眠ります。このサイクルが繰り返されます。

目覚めるたびに、それを heartbeat と呼びます。そして各heartbeatにはaudit trailがあります。どのagentが起きたか、何をしたか、何tokenを消費したか、どれだけの時間がかかったか。

Paperclipは2種類の起こし方をサポートします。

Interval —— 定期的なスケジュールで起こす(例:10分ごとに新しいtaskを確認)
Event-driven —— イベントが発生した瞬間に起こす:新しいtaskが割り当てられた、新しいcommentが付いた、あるいはapprovalが承認されたとき

なぜこれが重要なのでしょうか。agentが目を覚ますたびにお金がかかるからです——送信されるtoken、受信されるtoken、API callごとに価格があります。heartbeatは、agentが本当にやるべき仕事があるときだけお金を使うことを保証します。無限loopなし。予期せぬ請求なし。すべてのドルが、正しいtask・正しいagent・正しいタイミングまで追跡できます。

Org chart——CEO、CTO、Engineer:単なる比喩ではない

紹介記事で、私たちはこう問いかけました。もし誰も管理していない20個のagentがいたら、何が起こるか?混沌です。

Paperclipはagentを、実際の会社のように hierarchy で組織します。CEO agentが最上位に立ち、taskをCTOへ割り振ります。CTOは分析し、細分化し、Engineer agentへ伝えます。Engineerはコードを書き終えると、上へ報告を返します。美しい比喩ではありません——これは実際の権限を持つ、実際の仕組みです。

Chain of command は逆方向にも機能します。あるEngineer agentが行き詰まったとき(contextが足りない、taskが不明確、想定外のエラー)、それは黙っていません。自動的にCTOへescalateします。CTOは対処するか、さらにCEOへescalateします。CEOはBoard——システムの背後にいる本物の人間——へescalateすることもできます。

権限も明確に階層化されています。すべてのagentが新しいagentを作れるわけではありません。すべてのagentがコードをapproveしたり、pull requestをmergeできるわけではありません。各roleには境界があり、Paperclipはその境界を自動的にenforceします。

結果として、あなたは常に誰が誰に報告するかを把握できます。エラーが起きたとき、どのagentが責任を負うのか、そしてどのmanagerが本来もっと早くそのエラーに気づくべきだったのかが正確に分かります。

org chartを持つ20個のagent = 規律あるチーム。org chartを持たない20個のagent = ばらばらに動く20の実体。

Task lifecycle——backlogからdoneまで:7つの状態、取りこぼしゼロ

Paperclipにおける各taskは、7つの状態からなるlifecycleを通ります: backlog → todo → in_progress → in_review → done。さらに2つの特別な状態があります: blocked (誰かを待っている)と cancelled です。

ここで最も重要な仕組みは atomic checkout です。taskに取りかかる前に、agentは「checkout」しなければなりません——Gitでbranchをcheckoutするのと同じです。もし別のagentがすでにそのtaskをcheckoutしていれば、システムは409 Conflictエラーを返します。409を受け取ったagentはすぐに分かります:このtaskはすでに誰かが対応している、別のtaskへ移ろう、と。retryなし。競合なし。

結果として、2つのagentが同じ仕事を重複して行うことは決してありません。

heartbeat内の各actionは、 run ID ——目覚めた回の識別子——に紐づいています。誰がどのtaskをcheckoutしたか、何をcommentしたか、何時だったか——すべてが追跡できます。これは自動的なaudit trailであり、developerが自分でログを記録する必要はありません。

簡単な例を見てみましょう。Boardが「Fix bug login timeout」というtaskを作成します。CTOがheartbeatを受け取り、新しいtaskを見つけ、checkoutし、分析し、Engineerに割り当てるsubtaskを作成します。Engineerは次のheartbeatを受け取り、subtaskをcheckoutし、コードを読み、bugを修正し、commitし、結果をcommentします。CTOはその後のheartbeatを受け取り、コードをreviewし、approveします。taskはdoneへ移ります。全プロセスを通じて——飛ばされる手順は一つもありません。

リアルタイムのcost tracking——すべてのtokenが数えられ、すべての一円が記録される

多くのagentを動かすと、APIのコストは急速に増えます。そして最も難しい問いは「いくらかかったか?」ではなく「どこにかかったか?」です。

Paperclipはその問いに リアルタイムのcost tracking で答えます。各agentには月次のbudgetがあります。agentがbudgetの80%を使うと、システムは警告を送ります。100%に達すると、Paperclipは自動的にagentを一時停止します——人間が確認を覚えている必要はなく、システムが自らenforceします。

Dashboardはコストをagent別、task別、期間別に表示します。あなたはその3.50ドルが正確にどのtaskへ、どのagentが動いて、何時に、何回のheartbeatで消費されたのかを把握できます。

現在の一般的なやり方と比べてみましょう。AI agentを動かすほとんどのチームは、月末のAPI請求総額しか把握しておらず、そのうちの50ドルがどのfeatureへ入ったのか、どのagentが最も消費したのか、あるいはagentがloopしてどのtaskが「お金を燃やした」のかを知りません。Paperclipは、task単位・heartbeat単位での答えを与えます。

見積もりなし。「だいたい」なし。本物の数字を、リアルタイムで。

Demo walkthrough——1つのtaskがシステムを最初から最後まで通り抜ける

すべてが連携して動く様子を見るために、具体的な1つのtaskを追ってみましょう。

ステップ1: Board(人間)がPaperclip上で「APIエンドポイント /users を書く」というtaskを作成します。CTO agentに割り当てます。

ステップ2: CTOがheartbeatを受け取ります。inboxを確認——新しいtaskを見つけます。taskをcheckout(statusがtodo → in_progressへ移行)。CTOはbriefを読み、scopeを分析し、Engineerが必要だと判断します。「Implement GET /users with pagination」というsubtaskを作成し、Engineer agentに割り当てます。

ステップ3: Engineerが次のheartbeatを受け取ります。subtaskをcheckout。codebaseを読み、コードを書き、testを走らせ、commitします。taskにcomment:「Done. Added pagination with cursor-based approach. Tests passing.」このheartbeatのコスト:1.20ドル。

ステップ4: CTOが次のheartbeatを受け取ります。Engineerがcommentしたのを見つけます。コードをreviewし、test resultsを確認し、セキュリティ上の問題がないことを確認します。approve。subtaskをdoneにmark。parent taskをdoneにmarkします。

ステップ5: Boardがdashboardを開きます。taskはdone。総コスト:2.30ドル(3回のheartbeat——CTOの割り当て1回、Engineerのコーディング1回、CTOのreview1回)。audit logはすべての手順を余さず記録しています。飛ばされた手順は一つもなく、scope外で動いたagentも一つもいません。

全プロセスは自動です。しかしBoardは依然としてコントロールを握っています。彼らはtaskを作成し、budgetを設定し、必要であれば——コードがmergeされる前に承認します。これが「自動」と「制御不能」の違いです:agentは自律的に動きますが、agentがいつ・どこまで動けるかを決めるのは人間なのです。

次回:15分でPaperclipをインストール

あなたはPaperclipが内部でどう動くかを見てきました:control planeが調整し、heartbeatが規律を保ち、org chartが権限を分け、task lifecycleが重複作業を防ぎ、cost trackingが予算を守ります。次の記事では、あなた自身の手でPaperclipをインストールします——空のterminalから、heartbeatを動かす最初のagentまで、15分で。

トピックPaperclip