コーディングエージェント「Factory AI」導入ガイド：料金・機能・比較

コーディングエージェントFactory AIとは？

Factoryは、Droidsと呼ばれるエージェントを備えたソフトウェア開発プラットフォームです。Droidsはリポジトリを調べ、計画を提案し、ファイルを変更し、チェックを実行して、プルリクエストを準備できます。プルリクエストとは、コードベースにマージする前にレビューできるよう、変更をまとめたものです。Droidsはターミナル、統合開発環境（IDE）、FactoryのデスクトップアプリやWebインターフェースから利用できます。「エージェントネイティブ開発」とは、個々の編集を逐一指示する代わりに、達成したい結果を伝え、出来上がった成果をレビューする開発の進め方です。Factoryはモデルと開発ツールをまとめる製品であり、新しいプログラミング言語でも、自分で学習させるモデルでもありません。この位置づけは、Factoryの製品ページでも説明されています。

本記事は、Factoryの公開料金ページとドキュメントを基に、2026年10月21日に内容を確認しています。ドキュメントを基にした評価であり、具体的な利用例と費用の試算を交えて解説します。コーディングのベンチマークや実機検証を行ったという主張はしていません。

Factoryが向くのは誰？今のエージェントを使い続けるべきなのは？

Factoryが向いているのは、開発者ごとに使うエディタが違っても、作業の任せ方を統一したいエンジニアリングリードです。モデルの提供元を変えるたびに、すべてのワークフローを作り直したくない場合にも候補になります。一方、既存のエージェントがリポジトリ、テスト、レビューの流れをすでに把握し、あまり手をかけずに作業を進められている創業者にとっては、導入の魅力は小さくなります。

比較候補は、Anthropicの開発エージェントであるAnthropic Claude Code、OpenAIのコーディングエージェントであるOpenAI Codex、そしてエディタ兼エージェントプラットフォームの**Cursor**です。購入によって日々の開発の進め方がどう変わるかを比べると、判断しやすくなります。

これは導入判断のための比較であり、ベンチマーク順位ではありません。Claude Code、Codex、Cursorは、すでに単一のチャット画面やターミナルにとどまらない製品です。複数のインターフェースがあるだけでは、Factoryを選ぶ決め手にはなりません。

Factory AIとClaude Codeはどう選ぶ？

幅広いワークフローの中で、Claudeモデルを選択肢のひとつとして使いたいなら、Factoryは検討に値します。すでに組織内で有用な指示、外部連携、レビューの習慣がClaude Codeを中心に整っているなら、そのまま使う方がシンプルです。DroidでClaudeモデルを動かしても、Claude Codeと同じものにはなりません。周辺ツール、コンテキストの選び方、実行時の振る舞いは、エージェント製品ごとに異なるためです。

たとえば、バックエンド担当はJetBrains、フロントエンド担当はCursorを使っているチームで、リードが共通の保守タスクを処理するためにFactoryを導入するのは、筋の通った判断です。別のモデルを使ったデモが印象的だったという理由だけで、全員に乗り換えを求めるのは妥当ではありません。

主な問題が曖昧な要件、不安定なテスト、誰もレビューしないプルリクエストの滞留にあるなら、今はFactoryの導入を見送りましょう。Droidsも同じ問題の影響を受けます。まずはClaude Code、Codex、Cursorを使い続けながら、作業の正しさを確かめやすい状態を整えるべきです。選択肢を絞った比較はCodexとClaude Codeの比較記事、より広い候補はAIコーディングエージェントの比較記事で扱っています。

以下では、コンテキストの質、実行の制御、インターフェース間の継続性、変更が受け入れられるまでのコストという4つの観点から評価します。

Factory AI Droidの使い方：エディタはそのまま、作業範囲を明確に

Factory Droidは既存のエディタ内で動かせるため、エディタを移行せずに小規模な試験導入を始められます。VS Code、Cursor、Windsurfでは、連携機能を通じてアクティブなファイル、選択中のテキスト、開いているファイル、診断情報が渡されます。診断情報とは、エディタが表示するエラーや警告のことです。エディタ標準の差分表示にも対応しています。統合ターミナルでdroidを実行し、/ideで接続状態を確認します。設定方法はFactoryのIDE連携ドキュメントに記載されています。

バックエンドのリードが、アプリケーションでアカウント権限を検証する仕組みを変更する場面を考えてみます。「認証まわりをリファクタリングして」だけでは、有効な依頼になりません。すべての呼び出し箇所を洗い出す、既存ユーザーに対する動作を維持する、移行手順を提案する、意図しない権限変更を検出できるテストを特定する、といった具体化が必要です。

こうした記述は、エージェントの作業範囲を定めると同時に、レビュアーが成果を却下するための基準にもなります。大きな差分が出てきただけでは、移行が正しいかどうかは判断できません。

Factory AIのSpec Modeでは何ができる？

FactoryのSpec Modeは、調査と計画を実装から切り離すモードです。関連するコンテキストを読み、計画を提案してから承認を求めます。CLIではShift+TabでNormalとSpecを切り替えます。一方、自律性レベルは別の設定で、再確認なしで進められる操作を決めます。モードのドキュメントでは、この違いが明示されています。

権限管理の移行なら、まずSpec Modeを使い、対象ファイル、互換性についての前提、検証手順を計画に含めるよう求めます。アクセスルールを変える提案なのに、既存の動作をどう維持するか説明がなければ、承認すべきではありません。判断に必要な点が明確になってから、実装を承認します。

実際には、次のように進めます。

1. Droidに、認可処理の起点と関連テストを探すよう依頼します。
2. 現在の動作を維持し、不明確な要件を洗い出した計画を求めます。
3. 計画をレビューし、許可する作業に合った自律性レベルを選びます。
4. プルリクエストを作成または承認する前に、差分とテスト結果を確認します。

利点は、エージェントが大量のコードを作る前にレビューの機会を設けられることです。ただし、もっともらしい計画でも間違っている可能性はあります。受け入れ基準には、テストが存在することだけでなく、実際の動作を含める必要があります。

エディタによる違いにも注意が必要です。Factoryのドキュメントによると、JetBrains連携は、開いているファイル、選択範囲、診断情報、Droidのネイティブ差分を自動では共有しません。複数のエディタを使うチームでは、どこでもVS Codeと同じ体験になると考えず、この差を織り込んで導入する必要があります。

ワークフローを作り直さずにモデルを選べる

Factoryでは、Droidのインターフェースとタスクの組み立て方を維持したまま、モデルの系統を選べます。作業の任せ方は統一したいものの、すべてのワークフローを特定のモデル提供元に結び付けたくないチームにとって、有用な仕組みです。

公開中のFactoryのモデルカタログには、たとえば次のモデルが掲載されています。

• Anthropic Claude Opus 5.5、Claude Sonnet 5.5。
• OpenAI GPT-6.1 Sol、GPT-6 Astra。
• Google Gemini 3.1 Pro、xAI Grok 4.7。
• Mistral Large 4、Kimi K3、DeepSeek V4.1 Flashなどのオープンモデル。

これは対応モデルの一例であり、品質の順位ではありません。また、すべてのアカウントのポリシーで、すべてのモデルが許可されていると保証するものでもありません。

依存関係の更新タスクが並んでいる場面を考えてみます。各候補のモデルに、同じ依存関係の変更、テスト手順、完了条件を渡します。更新を完了できたか、チェックを通過したか、レビュアーの介入がどれだけ必要だったかを記録します。手をかけずに済むモデルなら、使用量が多くても見合うかもしれません。安いモデルでも、テストが壊れたままの結果を繰り返し残すなら、割に合わない可能性があります。

比較では、タスクと環境を一定に保つべきです。モデル、リポジトリの指示、自律性の設定を同時に変えると、結果を解釈できなくなります。Factoryのカタログには、使用量の倍率や推論設定が異なるモデルがあるため、「プロンプトを同じ回数送った」というだけでは、使用量を適切に比較できません。

**Bring your own key（BYOK）**とは、自分のモデル提供元の認証情報や、互換性のあるエンドポイントを設定して使う方式です。Factoryはローカル構成を含む個人用のカスタムモデルに対応しています。ただし、BYOKドキュメントには、利用場所に関する重要な制限があります。個人用モデルを使えるのはCLIとデスクトップアプリで、ホスト型のWebやモバイルのインターフェースでは使えません。

購入時に確認すべき点は明確です。Factoryはワークフロー内でモデルを切り替える手間を減らせますが、実際に作業を動かすインターフェースで目的のモデルを使えるかは、別途確認しなければなりません。ローカルモデルの試験運用が成功しても、それだけでWeb経由の作業委任まで検証できたことにはなりません。

デスクトップとWebで、任せた作業の成果をレビューする

Factoryのデスクトップアプリは、会話と並べて成果物を目で確認したいときに役立ちます。製品ページでは、コード差分、文書、プレゼンテーション、スプレッドシート、PDF、動作中のWebサイトをプレビューできると説明されています。コードの行や選択した要素にコメントを付けることもできます。対応OSはmacOSとWindowsです。Factory Desktopのページでは、デスクトップ、Web、モバイル、CLIの間でセッションを引き継げることも紹介されています。

技術に詳しい創業者がアカウント設定ページを変更するなら、作業の流れは明快です。必要な動作を説明し、表示された結果を確認し、該当する要素にフィードバックを付け、リリース前にコードの変更をレビューします。画面上で指摘できれば、「このエラーはメールアドレス欄の横に表示してほしい」といった依頼の対象を明確にできます。ただし、それだけでは、不正な更新をサーバーが拒否することや、他のユーザーの設定にアクセスできないことまでは確認できません。

作業を任せるうえで、この違いは重要です。画面を承認する人と、アプリケーションの動作を確認する人は、別かもしれません。見た目の変更に加え、その背後の動作が正しいことを示す証拠も求めましょう。説得力のあるプレビューだけを完了条件にしてはいけません。

Factoryは、GitHub、Linear、Slack、Sentryなどのツール向けコネクタも案内しています。利用が認められたコンテキストを取り込む手段にはなりますが、課題管理ツールをつないでも、曖昧なチケットが具体的になるわけではありません。タスクには引き続き、責任者、作業範囲、明確な成果が必要です。

リモート実行では、もうひとつ区別すべきことがあります。作業をレビューする画面と、作業を実行しているコンピューターは別です。 Factoryが管理するDroid Computersは、セッションをまたいでファイル、インストール済みパッケージ、サービス、設定を保持する永続的な環境です。自分で管理しているマシン向けには、別途Remote Controlという選択肢が用意されています。Droid Computersのドキュメントでは、両方が説明されています。

セットアップの負担が大きい場合、状態を保持できるのは便利です。同時に、環境の状態を管理する責任者も必要になります。Factoryは、Environmentを再ビルドしても、そのスナップショットからすでに作成したDroid Computerは更新されないと明記しています。したがって、プラットフォームのリードは、成功した実行を他の環境でも再現できると判断する前に、マシンの状態を確認すべきです。

AIによる開発の自動化は、繰り返せる作業から始める

開発者が毎回会話を始めなくても、Droidが決められた作業キューを処理するようになると、Factoryの価値はさらに見えやすくなります。Droid Execは、そのためのヘッドレスモードです。対話なしでコマンドからタスクを実行し、スクリプトや継続的インテグレーション（CI）システムに出力を返します。既定では読み取り専用で動作し、編集やより広い範囲のコマンドには、自律性レベルの明示的な設定が必要です。Execのドキュメントでは、出力形式、作業ディレクトリ、分離したGitワークツリーが説明されています。

最初のワークフローとして適しているのは、メンテナーが根拠を確認できるリポジトリ分析です。Droidをインストールして認証を済ませたら、リポジトリ内で次を実行します。

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

これは呼び出し方の例であり、本レビューで実行した結果ではありません。このコマンドだけでテストカバレッジを証明することもできません。動的な呼び出し、結合テスト、生成コードがあると、単純な判断は誤りにつながります。出力は、メンテナーが検討する作業候補の一覧として扱います。

次の段階では、別のブランチまたはワークツリーで、承認済みの範囲を絞ったテスト変更をDroidに実装させ、リポジトリのチェックを実行します。受け入れ判断を、エージェント自身の説明文だけで済ませてはいけません。完了を決めるのは、CIの結果とレビュアーの判断です。

自動化では、見落としやすい壁もあります。コマンドポリシーの実効判定がaskなら、自律性レベルがHighでも承認が必要です。しかし、単発で実行するジョブでは、対話による承認を受け取れません。したがって、自律性を上げるだけでは、停止している自動処理が動くとは限りません。Factoryは、実行前にポリシーの判定を確認するためのdroid rules checkを案内しています。これは意図を持って解決すべき設定上の問題であり、あらゆる権限チェックを無効化する理由にはなりません。

より大きな作業では、Mission Modeがワーカーと検証を調整します。利用にはHighの自律性、またはドキュメントに記載された安全性の制限を外す設定が必要です。また、個人向けプランのMissionsは、レート制限に達すると一時停止することがあります。大規模な移行を無人で完了できると約束する前に、通常の範囲を絞ったタスクから始めましょう。

得られる価値は、同じ受付手順、権限範囲、確認資料を毎回そろえられる再現性です。一方で、運用の責任は残ります。依存関係、認証情報、タスク範囲、失敗時の処理を、誰かが維持しなければなりません。個々のコーディングセッションよりも、こうした運用基盤の方が重要になったら、次の検討材料はAIソフトウェアファクトリーのプラットフォーム比較です。

Factory AIの料金：必要なワークフローに合わせて選ぶ

請求をまとめたい小規模チームにとって、Factory Teamsは分かりやすい選択肢です。契約に基づく使用量の共有、ID管理、管理者ポリシーが必要なら、検討すべきはBusinessです。個人向けプランからTeamsへ移れば、こうした管理機能も手に入るとは考えないでください。

以下は、2026年10月21日に確認したFactoryの公開料金ページの月額条件です。

料金ページには、トークンの利用枠は掲載されていません。使用量はProに対する倍率でのみ示されています。 この倍率は、処理できるタスク数を保証するものではなく、受け入れ済みプルリクエスト数に妥当に換算する方法もありません。組織向けプランのドキュメントによると、Teamsの各席にはProのレート制限が適用されます。BusinessとEnterpriseは、契約条件に基づいて使用量を共有します。

Teamsを5席契約した場合は、$60 + 5 × $40で月額$260です。10席なら**$460になります。仮に5席のチームが、ある月にDroidのプルリクエストを20件受け入れたとすると、サブスクリプション費用は受け入れたプルリクエスト1件あたり$13**です。これは単なる計算例で、処理能力の予測ではありません。総費用を比較するには、追加使用量、コンピューティング環境、レビュアーの作業時間も加える必要があります。

必要なワークフローに対して、選んだプランが足りないことはよくあります。Proには、Businessの欄にある全社向け管理機能は含まれません。Teamsも、各席でPlus相当の使用量を利用できるとは案内されていません。また、個人向けプランのドキュメントでは管理型Droid ComputersがProに含まれる一方、販売用の料金ページではPlusからの追加機能とされています。予算を組む際は料金ページを基準にし、管理型の実行環境を前提にする前に、実際の利用権を確認してください。

導入を止めかねない制約

Factoryで特に影響が大きい制約は、インターフェースやプラン間での一貫性に関わるものです。個々のコーディングセッションがうまくいっていても、これらが導入の障害になることがあります。

エディタへの対応と、機能が同等であることは別です。 JetBrainsには、VS Code系エディタで説明されているファイル、選択範囲、診断情報の自動共有がありません。ZedのAgent Panelでは、以前のFactory Droidセッションを復元できません。Droidsに統一するチームでも、エディタごとの導入手順とコンテキストを復元する方法が必要です。Factoryはこれらの違いを明記しています。

個人用BYOKは、ホスト型のWebやモバイルには引き継がれません。 ローカルで設定したモデルが、コストやデータの扱いを判断するうえで重要な場合もあるでしょう。しかし、その構成をFactoryのすべてのインターフェースで利用できるわけではありません。ローカルのデモだけを根拠に購入する前に、想定しているリモートでの利用経路を検証してください。この制限は明記されています。

使用量の倍率だけでは、安定して確保できる処理能力は分かりません。 個人向けプランのドキュメントには、5時間、7日、30日の独立したローリング期間が記載されています。上位のサブスクリプションにしても、これらが公開されたトークン枠や完了保証に変わるわけではありません。顧客への納期が無人実行に依存するなら、短期間の試験結果から推測せず、契約上の処理能力について相談すべきです。Factoryの個人向け使用量ルールにも、レート制限に達するとMissionsが一時停止すると記載されています。

管理型の実行環境を使えるプランは、確認が必要です。 ノートPCから離れた場所で作業を動かしたい創業者にとって、ProとPlusに関する記載の食い違いは重要です。本レビューの料金表は公開料金ページを基にしています。矛盾するドキュメントがあるからといって、無料で上位機能を使える根拠にはなりません。また、「クラウドエージェント」という表記だけで必要なインフラがすべて含まれると考えず、モデルの使用量とは別に、コンピューティング環境の条件を確認しましょう。

権限ルールは、OSによる隔離とは異なります。 この点は、Factory自身の自律性に関するドキュメントでも説明されています。コマンドが許可されていることは、無害である証明にはなりません。また、自然言語で「本番環境には触れないで」と指示しても、ネットワーク上の境界にはなりません。試験導入では、そのタスクに適したアクセス権と環境を使い、組織全体で強制したい要件については、個別見積もりのプランにある管理機能を評価してください。

こうした制約を踏まえると、導入範囲を絞るのが適切です。環境、モデル、権限、レビュアーが明確なワークフローでFactoryを使いましょう。それらを決める前にすべてのリポジトリへ広げると、調整作業が増え、作業を任せる利点が失われかねません。

Factory AIの評価：導入を決める基準

Factoryを導入する価値があるのは、定義されたタスクを受け入れ可能な変更に仕上げるまでに、人が費やす作業を減らせる場合です。モデルの選択肢、複数のインターフェース、リモート実行が役立つかどうかも、その成果が改善するかで決まります。

共通の保守タスク、複数エディタをまたぐワークフロー、条件をそろえたモデル比較を行う場所が今は十分に整っていないなら、現在のエージェントと併用して導入します。同等の作業で比較し、受け入れチェックの水準を落とさずにレビュアーの負担や総費用が減ったと確認できてから、その種類のタスクに限って既存のエージェントを置き換えます。Claude Code、Codex、Cursorがすでに十分こなしているワークフローと重複するなら、導入を見送ります。

週明けに着手するなら、成果に責任を持つリードを決め、小さく評価を始めましょう。

Factoryは、このような評価を行うに値する候補です。ドキュメントからは、幅広く設定可能なエージェントシステムであることが確認できます。ただし、エンジニアが使い慣れたエージェントをDroidに置き換えるだけで、より良い成果を出せると証明されているわけではありません。

よくある質問

エージェントの導入を広げる前に、タスク、権限、レビュー責任者、運用コストを整理しましょう。AI Business Workflow Audit Checklistは、ニュースレターから入手できます。