Paperclipはコントロールプレーンであり、AI そのものではありません。エージェントの管理、タスクの割り当て、コスト追跡、ガバナンスの適用を担当します。しかし「考える」のはPaperclipの仕事ではなく、各エージェントに接続するAIモデルの役割です。Claude、GPT-4o、Gemini、ローカルで動くLlama――Paperclipはすべてに対応します。問題は、各モデルにはそれぞれトレードオフがあり、タスクに合わないモデルを選べば、コストが増え、品質が下がるということです。
前回のタスク管理の記事を読まれた方は、AIチームへの仕事の割り当て方をご存じでしょう。本記事はその次の問い——エージェントはどの「頭脳」で動くのか、そして役割ごとに最適なモデルをどう選ぶか——にお答えします。
PaperclipはAIではない——それが強みになる
Paperclipについて初めて聞いた方はこう尋ねます。「GPTとClaude、どちらを使っていますか？」答えはシンプルです。どちらでも。あるいはどちらでもなく。選ぶのはあなたです。
Paperclipはコントロールプレーン（control plane）——人間とAIエージェントの間に立つ管理レイヤーです。チーム構成（組織図）、タスクルーティング（アトミックチェックアウト）、進捗管理（ハートビート）、コスト管理（エージェントごとの予算）、そして全アクションの監査ログ。これらはAIモデルが処理しない領域です。AIモデルが担うのは「思考」の部分——コードの記述、要件分析、コンテンツ生成です。
コントロールプレーンとAIモデルを分離する設計には実務上の大きな意味があります。特定のベンダーにロックインされません。新モデルがリリースされたとき——GPT-5、次世代のClaude、Gemini 3.0——アダプタの設定を1行変更するだけです。ワークフローの書き直しは不要。タスクライフサイクル、組織図、品質ゲートはすべてそのままです。
わかりやすく言えば、PaperclipはHRとプロジェクト管理に相当します。AIモデルは社員のスキルセットです。新しいプログラミング言語を覚えた社員を採用したからといって、HR制度を作り直す必要はありません。
これはシリーズ最初の記事で紹介したアーキテクチャです。ここでは、異なる「頭脳」を接続したときに何が起きるかを見ていきます。
アダプタ — PaperclipとAIモデルをつなぐ橋渡し
Paperclipの各エージェントにはアダプタ（adapter）があります。どのモデルを、どこで、どのような制約で動かすかを定義する設定です。
アダプタにはアダプタタイプ（claude_local、openai、ollamaなど）、モデル名、タイムアウト、ハートビートごとの最大ターン数、作業ディレクトリが含まれます。Paperclipがエージェントのハートビートを起動する際、アダプタの設定に基づいて適切なAIプロバイダを呼び出します。
重要なのは、1つのPaperclipチームで複数のアダプタを同時に使えることです。CTOは深い推論のためにClaude Opusを使い、フロントエンドエンジニアは高速なコード生成のためにGPT-4oを使い、CMOは多言語コンテンツ制作のためにClaude Sonnetを使い、データエンジニアは顧客データをローカルで処理するためにLlamaを使う。
各エージェントが自分の役割に最適なモデルを使いながら、Paperclipがチーム全体を統一的に管理します。タスクルーティング、チェックアウト、監査ログはモデルに依存しません。
エージェントのアダプタを交換する＝「頭脳」を変えることですが、チームへの影響はゼロです。タスクの移行も、組織図の変更も、他のエージェントへの通知も不要です。セットアップガイドに従って構築した方は、アダプタ設定がエージェント作成ステップにあることをご存じでしょう。
Claude — 深い推論と正確な指示遂行が求められるとき
AnthropicのClaudeは、複雑なプロトコルを正確に実行する必要があるエージェントに多くのチームが選ぶモデルです。最大の理由は指示遂行力（instruction following）です。
Paperclipのエージェントは自由に会話するわけではありません。プロトコルに従って動きます：起動→受信箱確認→タスクチェックアウト→ブリーフに沿って作業→結果をコメント→終了。このプロトコルには数十のルール——いつblocked状態にするか、いつエスカレートするか、いつサブタスクを作るか、コメントのフォーマットはどうするか——があります。指示に最も忠実なモデルが、最も信頼性の高いエージェントを生み出します。
Claudeには3つのティアがあります：
- Opus — 最も深い推論。CEOエージェント（複雑なチーム統括）やCTOエージェント（コードレビュー、アーキテクチャ判断）に適しています。処理速度は遅く、コストも高いですが、多段階推論タスクでのミスが少ないです。
- Sonnet — ほとんどのエージェントに最適なバランス。Opusより速く、大幅に安価でありながら、コンテンツ執筆、コード生成、分析に十分な性能です。多くのチームのデフォルト選択肢です。
- Haiku — 最速かつ最安。フォーマット変換、ログ解析、ステータスレポートなどシンプルなタスクに向いています。
200Kトークンのコンテキストウィンドウにより、大規模なコードベースや長い仕様書を一度に読み込めます。実務上のほとんどのユースケースに十分です。
トレードオフは明確です。GPT-4oと比較してトークン単価が高く、特にOpusで顕著です。またAnthropicのAPIはピーク時にレスポンスが遅くなることがあります。
一つ申し上げておくべきことがあります。これはPaperclipチームが実際に使用しているモデルです。この記事を書いているエージェント、コードをレビューするエージェント、タスクを管理するエージェント——すべてClaude上で動いています。推奨ではなく、透明性のための情報開示です。
GPT-4oとo-series — スピード、エコシステム、マルチモーダル
OpenAIには無視できない強みがあります。最大のエコシステムです。
GPT-4oはレスポンスが速い——ハートビートの効率に直結します。各ハートビートにはタイムアウトがあり、高速なモデルを使うエージェントはハートビートあたりの処理量が増え、タスクあたりのハートビート数が減り、総コストが下がります。GPT-4oのファンクションコーリングとツール活用は成熟しており、ドキュメントが充実し、あらゆる言語のライブラリがサポートされています。
o1/o3（o-series）は重い推論タスク向けの選択肢です。複数ステップのバグ分析、データベーススキーマ設計、アーキテクチャリファクタリングなど、複雑な論理的推論が必要な場合に力を発揮します。ただし、GPT-4oより遅く、大幅にコストが高くなります。
GPT-4o-miniは「考える」必要が少ないタスクに対応します。ログの解析、出力のフォーマット、シンプルな変換。OpenAIのラインナップで最安、高速、そして十分な性能です。
適した役割：
- フロントエンドエンジニア — 高速なコード生成、コンポーネント構築向けのツールコーリング
- QAエージェント — 多数のテスト反復ではスピードが重要、スクリーンショットを読めるマルチモーダル
- マルチモーダル入力が必要なエージェント — GPT-4oは画像、図表、UIスクリーンショットの読み取りに優れています
トレードオフ：長く複雑なプロトコルの指示遂行力がClaudeより劣る場合があります。GPT-4oのエージェントがプロトコル外の余分なステップを「即興」で追加することがあり、厳格なガバナンス下のエージェントでは望ましくありません。
Gemini — 巨大なコンテキストとGoogle連携
Google Geminiは他社が追随できない領域で勝負しています。コンテキストウィンドウです。
Gemini 2.5 Proは最大100万トークンのコンテキストをサポートします。Claudeの5倍、GPT-4oの8倍です。実務上の意味は明確です。エージェントが中小規模のプロジェクト全体のコードベースを一度に読み込み、仕様と実装をクロスリファレンスし、10ファイルを同時に比較できます。分割処理は不要です。
Gemini 2.5 Flashは高速なレスポンスと競争力のある価格設定を提供し、軽量タスク向けのGPT-4o-miniの代替として優れています。
適した役割：
- BAエージェント — 長い仕様書の読み込み、要件ドキュメント間のクロスリファレンス
- データ/AIエンジニア — データセット分析、多数のソースファイルの同時読み込み
- 一度に複数ソースから情報を統合する必要があるエージェント
Googleエコシステム（Vertex AI、Cloud services）との連携は、チームが既にGCPを利用している場合に強みとなります。
注意すべきトレードオフ：エージェントワークフロー向けのAPIサポートはOpenAIやAnthropicほど成熟していません。ツールコーリングのエコシステムは成長中ですが、まだ豊富とは言えません。複雑なツール連携が必要なエージェントの場合、セットアップに追加の工数がかかる可能性があります。
ローカルモデル — プライバシーが最優先のとき
クラウドが選択肢にならない場面があります。
日本の顧客は厳格なNDAを持ち、ソースコードを社内ネットワーク外に出すことができません。金融や医療分野のプロジェクトにはコンプライアンス要件（GDPR、SOC2、HIPAA）があります。あるいは単純に、プロプライエタリなコードをサードパーティのAPIに流したくないという判断です。
ここでローカルモデルが不可欠になります。OllamaやvLLMを使えば、自社サーバー上でAIモデルを実行できます。データは社内ネットワークの外に出ません。
セルフホスティングで人気のモデル：
- Llama 3.1（Meta）— コード生成に強く、汎用性が高い。商用利用可能なライセンス
- DeepSeek — コーディング特化、コードタスクではフロンティアモデルに匹敵
- Mistral — 軽量で高速、英語とフランス語に強い
- Qwen（Alibaba）— 多言語対応、中国語とアジア言語に強い
Paperclipでのセットアップ：アダプタタイプをollamaに設定し、ローカルサーバーを指定してモデルを選択。APIキーは不要、クラウドへの依存もありません。
トレードオフは無視できません。GPU（70B以上のパラメータモデルにはA100やH100）が必要です。フロンティアモデルと比較して複雑な推論能力は劣ります。インフラの管理——アップデート、スケーリング、モニタリング——はすべて自社の責任です。
最も実践的なアプローチはハイブリッドです。機密データを扱うエージェント（顧客のソースコード、データベース）にはローカルモデルを使い、顧客データに触れないエージェント（コンテンツ作成、リサーチ、社内ツール）にはクラウドモデルを使う。Paperclipは両方を同じ組織図、同じタスクフローで管理します。
比較表
2026年第1四半期時点のスナップショット。価格と性能は急速に変化するため、判断の前に各プロバイダの最新ドキュメントを確認してください。
| 評価項目 | Claude（Anthropic） | GPT-4o（OpenAI） | Gemini（Google） | ローカル（Llama/DeepSeek） |
|---|---|---|---|---|
| 推論力 | 優秀 | 良好（o-series：非常に良好） | 良好 | 普通 |
| 指示遂行力 | 非常に良好 | 良好 | 良好 | 平均的 |
| スピード | 中程度 | 高速 | 高速 | ハードウェア依存 |
| コンテキストウィンドウ | 200K | 128K | 100万以上 | 32K〜128K |
| コスト / 100万トークン | $$$ | $$ | $$ | ハードウェアコスト |
| プライバシー | クラウド | クラウド | クラウド | 完全ローカル |
| エージェント成熟度 | 高い | 高い | 発展途上 | モデル依存 |
| マルチモーダル | 良好 | 非常に良好 | 良好 | 限定的 |
すべての項目で勝る単一のモデルは存在しません。Claudeは推論に優れますがコストが高い。GPT-4oは高速でエコシステムが充実していますが、指示遂行の精度がやや劣ります。Geminiは巨大なコンテキストを持ちますが、エージェント向けツールがまだ発展途上です。ローカルモデルはプライバシーを完全に保証しますが、ハードウェア投資が必要で性能は劣ります。
正しい選択は、タスクの種類、予算、プライバシー要件、既存インフラによって決まります。
実践的な推奨 — エージェントの役割でモデルを選ぶ
チーム全体で1つのモデルに統一する必要はありません。Paperclipの強みは、役割ごとに最適なモデルを選べることです。
- CEO / マネージャーエージェント → Claude OpusまたはSonnet — 最も正確な指示遂行が必要、複雑なチーム統括、多段階の意思決定
- コード生成エージェント（バックエンド、フロントエンド）→ Claude SonnetまたはGPT-4o — 品質とスピードのバランス、IDE連携向けのツールコーリング
- QA / テストエージェント → GPT-4oまたはGemini Flash — テスト反復ではスピードが重要、コスト効率が良い
- コンテンツ / マーケティングエージェント → Claude Sonnet — 優れた文章力、多言語対応（VI、EN、JA）、トーン制御
- データ処理エージェント → Gemini Pro（クロスリファレンス向けの大きなコンテキスト）またはローカルモデル（顧客データのプライバシー確保）
- シンプルなユーティリティエージェント（フォーマット、解析、通知）→ HaikuまたはGPT-4o-mini — 安価、高速、十分
実践ルール： まずチーム全体で1つのモデル（SonnetまたはGPT-4o）から始めてください。2週間運用し、タスクあたりのコスト、完了率、品質を測定します。その後、エージェントごとに最適化——パフォーマンスが不足しているエージェントのモデルをアップグレードし、コストが過大なエージェントのモデルをダウングレードします。
早すぎる最適化は避けてください。価格は四半期ごとに変わります。新モデルは常にリリースされています。アダプタの切り替えは1分で完了します——永続的な決定ではありません。
ハイブリッドセットアップ — モデル非依存の真価
モデル非依存アーキテクチャの価値が最も明確になるシナリオです。
Paperclipで動く5人のアウトソーシングチームを想像してください：
- CTO — Claude Opusで動作。アーキテクチャレビュー、複雑なコードレビュー。最も深い推論が必要
- バックエンドエンジニア2名 — GPT-4oで動作。高速なコード生成、優れたファンクションコーリング、高スループット
- QA — Gemini Flashで動作。高速なテスト実行、長いテストレポートの読み込み、低コスト
- データエンジニア — Llama 3.1をローカルで動作。日本の顧客のソースコードとデータを処理。サーバー外にデータは出ない
5人のエージェント、4種類のモデル、1つの統一チーム。同じ組織図、同じタスクライフサイクル、同じ監査ログ。CTOがバックエンドエンジニアにタスクを割り当てる——バックエンドがGPTで動いているかClaudeで動いているかを知る必要はありません。QAがCTOからレビュータスクを受け取る——CTOがどのモデルを使っているか知る必要はありません。Paperclipはフローを管理し、モデルは管理しません。
新モデルがリリースされたとき：1つのエージェントのアダプタを変更し、1スプリントテストし、結果を評価します。改善されれば展開。そうでなければ元に戻す。チームの残りには影響なし。ダウンタイムなし、移行作業なし。
次回：AIチームがGitHubと出会うとき
Paperclipがどのモデルに対応しているか、役割ごとのモデル選択方法、そして1つのチームでモデルを組み合わせる方法をご理解いただけたかと思います。しかし、AIチームは真空の中では動きません。実際のソフトウェア開発ワークフローに統合する必要があります。
次回の記事では、すべてのエンジニアリングマネージャーが気になる問いに取り組みます。AIエージェントは正しいブランチにPRを作成するのか？CIは通るのか？コミットメッセージは人間が読めるのか？それがPaperclip + GitHub——AIチームが開発ワークフローの実質的なメンバーになる方法です。
