AIREITERFactoryが2026年10月29日にリリースしたDroid 1.0で、最も目を引くのは効率化です。ScriptモードだけでClaude Opus 5.5のコストを15%削減し、競合ハーネスとの直接比較では最大24%低くなったとしています。ただし、購入を判断するうえで見逃せない点は変わりません。ローリング形式の利用上限と、ハーネスが高速化したことで増えるレビュー作業です。
Factory Droid 1.0で変わったこと
Factory Droid 1.0は、新しい基盤モデルではなくハーネスのリリースです。Factory Droidは従来どおり、サードパーティ製モデルやオープンモデルを独自のプロンプト、ツール、結果処理、実行ループで包む、モデル非依存のコーディングエージェントです。1.0では、その実行ループが変わりました。
Droid 1.0はDesktop、ターミナルCLI、SDKで動作します。同じエージェントをWeb、Slack、Microsoft Teams、Linear、Jiraから利用できるほか、スクリプトやCI向けのヘッドレスなdroid execにも対応します。FactoryはScriptモードを、プログラマティックなツール呼び出しの名称として、GPT-6.1 Sol、GPT-6.1 Terra、GPT-6 Astra、GPT-6 Sol、GPT-5.6 Sol、Claude Fable 5.1、Claude Fable 5、Claude Opus 5.5、Claude Opus 5、Kimi K3でデフォルト有効にしています。
モデルの選択肢は従来どおり開かれています。ユーザーがモデルを明示的に選ぶことも、Factory Routerによる自動選択を使うことも可能です。BYOKを使えば、Ollama、LM Studio、vLLMなどのローカルエンドポイントや自前のAPIキーも利用できます。
プログラマティックなツール呼び出しの実際
プログラマティックなツール呼び出しでは、モデルがツールを1つずつ呼ぶ代わりに、JavaScriptプログラムを書きます。プログラムは専用のサンドボックスで実行され、独自のファイルアクセス、ネットワークアクセス、システムアクセスは持ちません。変数としてツールを呼び出し、決められた処理でフィルタリングやループを行い、選択した結果だけをモデルのコンテキストに返します。
通常のエージェントループでは、1回のツール呼び出しが終わるたびに生の出力をコンテキストへ追加します。一方、Scriptモードでは、出力が戻る前にコードで必要な情報だけを絞り込めます。指示の送信は1回で済み、1回のモデルリクエスト内で数百件のツール呼び出しをまとめて処理できるうえ、出力サイズにも上限を設けられます。
Factoryのfrontier-harness研究記事（2026年10月29日）に掲載された2つの例を見ると、仕組みが分かりやすくなります。
| ワークフロー | 直接ツール呼び出し（推定） | Scriptモード |
|---|---|---|
| Linearの151件の課題を移動・検証。312回のツール呼び出し、書き込みごとに15フィールドを確認 | 約36回のモデルリクエスト、約310万入力トークン | 2回のリクエスト、約6.1万トークン |
| 547回の実行にまたがる5,384件のデスクトップジョブを調査。60件単位で550回のツール呼び出し | 約59〜187回のリクエスト | 2回のリクエスト。失敗した41件を含む5項目の要約で、ツール結果のコンテキスト到達率は0.1%未満 |
FactoryはGPT-6.1 Solを使ったユニットテスト修正の再生テストも実施しました。直接呼び出しではモデル呼び出しが10回、所要時間が56.8秒だったのに対し、Scriptモードでは5回、41.6秒でした。モデル呼び出しにかかった時間は42.3秒から28.0秒に短縮されています。プログラムは最大5分間、途中までの出力を待ってから返すことができ、バックグラウンドで処理を継続します。完了時にはポーリングではなく、モデルを起動して知らせます。
Terminal-Bench 4でCodex、Claude Code、Cursor、Devin、OpenCodeと比較
FactoryのTerminal-Bench 4比較は、2026年10月23日から28日にかけて、同じモデルを各ハーネスで実行したものです。以下の数値はすべてFactoryによる自己申告で、独立した検証はありません。また、絶対スコアやドルベースのコストは開示されておらず、差分のみが示されています。
| モデル | Factory Droid 1.0と競合ハーネスの比較 | 報告された差分 |
|---|---|---|
| GPT-6.1 Sol | Codexとの比較 | 正確性+3.5ポイント、コスト−12%。Droidは合格タスクあたり10%遅い |
| GPT-6.1 Sol | OpenCode、Devinとの比較 | +6.6〜+12.6ポイント、4〜11%高速 |
| Claude Opus 5.5 | Claude Code、Cursor、OpenCode、Devinとの比較 | +3.0〜+7.6ポイント、コスト最大−24%、合格タスクあたりの時間16〜26%短縮 |
| Claude Opus 5.5 | Claude Codeとの比較 | 合格タスクあたりの時間−26%、トークン−17%。Scriptモードだけでコスト−15% |
この差分をそのまま購入判断の根拠にする前に、3つの注意点を押さえておく必要があります。Factoryは、Devinが質問のために停止したケースについて、Codexが合格していた場合はDevinも合格としてカウントしました（1試行あたり平均4.7タスク、正確性のみに影響）。また、途中で再接続が発生した2試行では、トランスクリプトからCursorの不足していたトークン使用量を推定しています。さらに、直接呼び出しの比較には、実測ではなくモデル化された推定値も含まれます。GPT-6.1 Solの比較からCursorが除外されたのは、テスト時点でCursorがOpenAIモデルにアクセスできなかったためだとFactoryは説明しています。
以前のDroidに関する記事やハーネスのベンチマークで引用された2025年9月のTerminal-Benchスコアは、異なるタスクセットとハーネスのバージョンを使っています。そのため、今回の1.0の差分を裏付けるものでも、反証するものでもありません。
Agent Factoryループと、目立たない部分の改善
Factoryのfrontier-harness記事では、Agent Factoryループと、その下支えとなるエンジニアリングも説明されています。新モデルを取り込み、同じタスクですべてのモデルを評価し、失敗をトレースし、影響を受けるモデルで変更をテストする。そして20以上のモデルを対象にエンジニアがレビューしてからリリースを判断する、という流れです。
Factoryがこのループを続ける理由は、モデルごとのチューニングにあります。たとえば、読み込むすべてのファイルに行番号を付けたところ、あるタスクでは1行あたり約2トークンでOpusのコストが22%下がりました。しかしGLMでは8%、Kimiでは32%コストが上がったため、Factoryは行番号をデフォルトではなくオプションにしました。
PTC以外の変更は、キャッシュ、プロンプトサイズ、復旧、起動を対象にしています。
- プロンプトキャッシュの維持：新しく見つかったツールをリクエストの先頭ではなく末尾に追加することで、2026年10月22日までの7日間における、キャッシュから再利用された通常の入力の割合は98%まで上昇しました。20,400,000件の本番CLIリクエストをトークン量で加重した再利用率は91.5%でした。
- ベースプロンプトの削減：バージョン0.170.0から0.250.0の間で、初回リクエストの入力は20,887トークンから13,055トークンへ37%減少しました。ツール定義も15,798から8,528へ46%減少しています。オンデマンド読み込みにより、事前に定義するツールは11個から2個になりました。
- 自律性への上限設定：Factory管理のAnthropicストリームで4分間出力がなければ再試行し、目に見える出力がない状態が3ターン続けばループを停止します。同じツール呼び出しが3回続くと再考を促し、6回続くと停止します。コンパクション要約の上限は8,000トークンから16,000トークンに倍増しました。
- 起動とレイテンシ：初回描画の中央値は1,839ミリ秒から488ミリ秒（約3.8倍）、プロンプト受理は1,876ミリ秒から618ミリ秒（約3.0倍）、初回モデルリクエストまでの時間は1,741ミリ秒から646ミリ秒になりました。Factoryによれば、最初のトークンを待つ時間の約97%はモデルリクエストそのものです。
効率化の効果を削る料金と利用上限
Factory Droidの料金は公開されていますが、実際に使える容量は明らかになっていません。料金体系は分かりやすい一方、数量面は不透明です。まさにここで、1.0の効率化によるメリットが消える可能性があります。
| プラン | 料金 | Factoryが開示している内容 |
|---|---|---|
| Pro | $20/月 | 標準的なローリング上限。Desktop、CLI、SDK、トラッキングを含む |
| Plus | $100/月 | ProのStandard Usageの約5倍。現行の料金ページでは管理対象のDroid Computersを含む |
| Max | $200/月 | ProのStandard Usageの約10倍。新機能を先行利用 |
| Teams | $60/月＋1シートあたり$40（最大10シート） | シートごとのPro上限、請求を一元管理 |
| Business / Enterprise | 営業への問い合わせ | カスタム上限、SSO/SAML/SCIM、ゼロリテンション、監査、専用コンピュート、オンプレミス |
利用量は5時間、7日間、30日間のローリングウィンドウで計算され、モデルごとの倍率も適用されます。CodeToolPilotの2026年10月のレビューによれば、ドキュメントと料金ページでは、どのティアにDroid Computersが含まれるかの説明が食い違っています。購入前に確認してください。Standard Usageを使い切ると、無料のDroid Coreオープンウェイトプール、または前払いのExtra Usage（最低$10、期限なし）に切り替わります。Missionsを使うにはExtra Usageを有効にする必要があります。BYOKのキーはローカル設定に保存され、CLIとDesktopでは使えますが、ホスト型のWeb・モバイルでは使えません。プランの利用枠までは無料で、それを超えるとプランの料金レートで課金されます。
実際に問題になるのは、「5倍」という倍率が、完了する作業量の5倍を意味しないことです。処理量はモデルの選択、キャッシュの挙動、コンテキスト長、ツールループ、コンピューター操作、失敗した実行経路に左右されます。Redditのヘビーユーザーからは、キャッシュに不向きな作業ではMaxの枠を数時間で使い切ったという報告があります。Scriptモードで緩和はできますが、問題を完全になくすわけではありません。
現時点で実ユーザーが指摘していること
リリース当日のXの反応は好意的ですが、まだ情報量は多くありません。一方、r/FactoryAiのRedditに蓄積された投稿からは、試用前にコストとして織り込んでおきたい不満が3つ見えてきます。クォータの不透明さ、動作の遅さとCPU負荷、そして自律的な出力を確認するレビュー負担です。
「利用量で比較するなら、DroidのプランはおそらくAnthropicやOpenAIの補助金付きプランには太刀打ちできません……。ただ、ハーネスとしては個人的にClaude Codeより優れていると感じました。私の使い方では『とにかく動く』んです（システムプロンプトが良いのかもしれません）。Specモードも素晴らしく、必要なUX要素もすべて揃っています」— u/FahimAdib11、r/FactoryAi
同じスレッドにある反対意見では、次のような問題が報告されています。
- キャッシュに不向きな実行では、Maxプランを約4時間で使い切った（「キャッシュが大きく外れていて本当にひどい」）— クォータに関するスレッド
- アイドル時のCPU使用率が約101%。Claude Codeは約6%で、MCPが原因ではないかと推測されている — パフォーマンスに関するスレッド
- セッションを再起動するとコンテキストが失われ、無駄な再構築を強いられる
Xでの初期のハンズオン報告も、評価が分かれていることを示しています。t3code風のClaude Code連携を移植したユーザーは、Missionモードでの利用状況は良好で、ハーネスを「次のレベル」と評価しています（@Davidwuuu92）。一方で、Devinのクラウド環境とマルチプラットフォーム対応にはまだ及ばないとも述べています。
ContinuumのFactoryレビューから得られる評価上の教訓は、1.0でも変わりません。見るべきなのは開始したセッション数や作成したPRの数ではなく、受け入れられた変更、レビュアーの作業時間、見逃した不具合、介入回数、上限到達回数、総コストです。自律的な処理量が増えるほど、レビュー負債も膨らむためです。
乗り換えるべきか、使い続けるべきか：購入判断と2週間テスト
Droid 1.0はハーネス効率の面では説得力を増しましたが、クォータの予測しやすさという問題は解決していません。恩恵を受けやすいのは、複数モデル、複数の利用画面、CIにまたがって1つの実行環境を標準化したいチームで、なおかつレビュー作業を引き受けられる場合です。
| 購入者 | 1.0に対する判断 | 理由 |
|---|---|---|
| すでに別サービスに含まれる1つの最先端モデルを使う個人開発者 | 継続、または有料プランを1か月だけ試す | 軽い利用では、Scriptモードの節約効果が、補助金付きの単一モデル契約を上回ることは少ない |
| ターミナル、CI、チャットによる委任を複数モデルで標準化したいチーム | 乗り換え候補 | 1つのハーネス、Router/BYOK、Droid Computers、Missions、監査対応。幅広さが強みになる |
| 規制対象・エアギャップ環境の組織 | 候補に入れる | ハイブリッド／オンプレミス、SSO、監査、テレメトリのエクスポートに対応。料金は営業経由のみ |
| エディターの自動補完を求め、レビューの余力がない人 | 見送る | レビュアーがいなければ、出力の高速化は生産性ではなくバックログになる |
標準化する前に、同じリポジトリで2週間のテストを行いましょう。
- 受け入れテストを固定した実際のチケットを20件選ぶ。
- 複雑な作業ではSpecification Modeを有効にし、まずDroid CLIをローカルで実行する。
- 同じタスクをClaude CodeまたはCodexでも実行し、比較対象にする。
- リモート実行を追加し、決定的なバリデーターを使った小規模なMissionを1つ試す。
- 上限到達、Droid Coreへのフォールバック、Extra Usageの消費、レビュー時間、受け入れられたマイルストーンあたりのコストをすべて記録する。環境差を見つけるため、完了したタスクをクリーンなマシンでもう一度再現する。
1.0でも残るトレードオフは構造的なものです。Factoryはモデルよりもハーネスが重要だと考え、Agent Factoryを通じてモデルごとの挙動を調整しながら、モデル非依存の立場を保っています。最先端モデルの料金やレート体系が変われば、現在の12〜24%というハーネスの優位性は、Scriptモードによるバッチ処理で取り戻せるより速く縮む可能性があります。だからこそ、ベンチマーク表だけでなく、上限、データ保持、ルーティングに関する契約条件も同じように細かく確認すべきです。
Factory Droid 1.0 FAQ
Factory Droid 1.0のProプラン$20は価値がありますか？
ターミナルエージェントを十分に使い、トークンやレイテンシのコストを実感している開発者にとって、Factory Droid 1.0は$20を払う価値があります。特に、Scriptモードでツール呼び出しをまとめられる複数ファイルの作業やチケットベースの作業で効果的です。利用量が少ない人や単一モデルだけを使う人なら、すでに含まれているエージェントのほうが安い場合があります。
Factory Droidに無料トライアルや無料プランはありますか？
Factory Droidには通常の無料プランはないと記載されており、最近のレビューでは登録時に支払い方法を求められると指摘されています。有料プランの上限に達すると、無料のDroid Coreオープンウェイトプールへフォールバックしますが、それでも有料プランへの加入は必要です。
Factory Droid 1.0はClaude Codeより優れていますか？
FactoryのTerminal-Bench 4では、Claude Opus 5.5を使った場合、Droid 1.0はClaude Codeより3.0〜7.6ポイント高く、コストは最大24%低く、合格タスクあたりの時間は26%短いとされています。ただし、これはFactoryによる自己申告です。Redditのハンズオン報告では、Droidのハーネスを好む人と、Claude Codeのシンプルさや料金を好む人に分かれています。
Scriptモードがデフォルトで対応するモデルは？
Factoryは、GPT-6.1 Sol、GPT-6.1 Terra、GPT-6 Astra、GPT-6 Sol、GPT-5.6 Sol、Claude Fable 5.1、Claude Fable 5、Claude Opus 5.5、Claude Opus 5、Kimi K3を挙げています。それ以外のモデルでは、直接呼び出しまたはモデルごとのチューニングが使われます。
Factory Missionsとは何ですか？料金はいくらですか？
Factory Missionsは、大きな目標をマイルストーンに分解し、複数機能にまたがるプロジェクトでワーカーエージェントとバリデーターエージェントを使う機能です。Missionsを使うにはExtra Usageを有効にする必要があり、ローリング形式のStandard Usageとは別に、前払いの変動費を消費します。
Factory DroidはCIで動かせますか？自分のAPIキーも使えますか？
Factory Droidは、スクリプトやCI向けにJSON出力を返すヘッドレスなdroid execで実行できます。BYOKではAnthropic、OpenAI、互換エンドポイント、Bedrock、ローカルのOllama/LM Studio/vLLMに対応しています。利用できるのはCLIとDesktopで、ホスト型のWebアプリやモバイルアプリではカスタムモデルは動作しません。
関連記事：クォータを比較するならCodexの利用上限を解説、ハーネス設計の別の事例を見るならMicrosoft Copilotのハーネスを解説もどうぞ。