Factory

Factoryが選ばれる理由

Factoryは、従来のコーディングアシスタントというよりも、エージェント・ネイティブなエンジニアリングプラットフォームとして捉えるのが適切です。その核心は、Droidが開発者の作業場所（ターミナル、IDE、プルリクエスト、Jiraチケット、Linearのイシュー、Slackのスレッド、CI/CDジョブ、クラウドまたはローカルの開発環境）に直接現れてサポートするという点にあります。

この位置付けは重要です。多くのAIコーディングツールは、依然として開発者が一つのエディタに座り、一行ずつ助けを求めることを前提としています。対してFactoryは、より「委任」に近いワークフローを目指しています。タスクを説明すれば、Droidがコンテキストを調査し、計画を提案し、変更を加え、チェックを実行し、レビュー可能な結果を返してくれます。

主なワークフロー

実践的なFactoryのワークフローは、ターミナルまたはアプリから始まります。開発者がリポジトリを開いてDroidを起動し、コードベースの分析や特定のタスクの完了を依頼します。その後、ターミナルUIや接続された開発環境を通じて計画をレビューし、変更を承認または却下します。

より大規模な作業には「Mission（ミッション）」機能が構造的なアプローチを提供します。単一の変更を依頼する代わりに、タスクを「コードベースの理解」「実装設計」「編集」「テスト実行」「差分レビュー」「後続作業の要約」といったステージに分割できます。これは、移行作業、リファクタリング、障害調査、あるいは複数ファイルにまたがる変更に適しています。

運用パターンで最も重要なのは「制御」です。Factoryの調整可能な自律レベルとレビュー可能な差分表示は、予期せぬ変更を防ぐよう設計されています。チームはこれを戦略的に活用すべきです。定型的な編集は迅速に進め、リスクの高いコマンド、広範なファイル変更、シークレット関連の作業、データベース移行、セキュリティに敏感なコードには承認を必須にするといった運用が可能です。

向いている用途

Factoryは、エージェントが進行管理できる程度の構造を持つエンジニアリングワークフローに適合します。具体的には、バグ修正、リファクタリング、移行、依存関係の更新、ローカルでのコードレビュー、セキュリティレビュー、テスト生成、障害対応、QA検証、ドキュメント更新、そして反復的な「イシューからPR作成」までの作業などが挙げられます。

特に、Jira、Linear、Slack、Notion、GitHub、CI/CD、ランブックなどに強力な内部コンテキストを既に持っている組織において真価を発揮します。Droidが、人間のエンジニアと同じチケットの背景、エンジニアリング規約、リポジトリの知識を参照できるようになると、その有用性は飛躍的に高まります。

他のツールとの比較

Devinと比較すると、Factoryは「一人の自律型ソフトウェアエンジニア」という体験を提示するよりも、既存のツールの中で開発者をサポートすることに重点を置いています。エンジニアリング作業の委任という点ではDevinが直接の競合ですが、Factoryの差別化要因は、CLI、IDE、チームツール、クラウドコンピュータ、自動化、エンタープライズガバナンスを横断するDroidのワークフローにあります。

OpenHandsと比較すると、Factoryはオープンソースではなく、より商用プラットフォーム向けに調整されています。透明性、ローカル制御、セルフホストを優先する場合はOpenHandsが魅力的ですが、パッケージ化されたマルチサーフェス体験、エンタープライズ管理、管理されたリモートコンピュータ、統合された利用分析を求めるチームにはFactoryが適しています。

Claude CodeやCodex CLIと比較すると、Factoryは特定のモデルやターミナルのみに限定されない、より広範なエージェントプラットフォームです。Claude Codeなどは個人のターミナルワークフローに強力ですが、Factoryはモデル選択、クラウド/ローカルエージェント、ミッション、Jira/Slack/Linear連携、管理者ポリシーを備え、チーム全体での導入をターゲットにしています。

ClineやRoo Codeと比較すると、Factoryは特定のVS Code拡張機能の体験に縛られません。IDE内でも動作しますが、その核心的な価値は、エンジニアリング作業を複数のツール間で追跡・継続できる能力にあります。

推奨される設定

個人の開発者の場合は、アクティブにメンテナンスされているGitリポジトリでCLIから使い始めるのが良いでしょう。まずは、アーキテクチャの解説、未コミットの変更のレビュー、関数へのテスト追加、あるいは一つのチケットの実装など、小さくレビュー可能なタスクから開始してください。これにより、広範な作業を任せる前に、Droidがコードベースをどのように推論するかを把握できます。

チームで利用する場合は、AGENTS.md形式のリポジトリガイド、明示的なテストコマンド、命名規則、アーキテクチャノート、レビュー規則を整備することが重要です。コードベース側で「チームが実際にどのように作業しているか」をエージェントに伝えることで、エージェントの品質は向上します。Jira、Linear、Slack、MCPなどの連携は、コアとなるリポジトリワークフローが安定してから行うのが得策です。

エンタープライズでの導入では、広く普及させる前にモデルポリシーと自律性のデフォルト設定を定義してください。高コストなモデルや実験的なモデルをすべてのプロンプトのデフォルトにすべきではありません。OTEL（OpenTelemetry）ベースのテレメトリと利用ダッシュボードを活用して、どのチーム、リポジトリ、モデル、ワークフローがコストと生産性を牽引しているかを把握してください。

導入時の注意点

補完ツールから移行するチームは、Factoryを提案の質だけで評価すべきではありません。より適切なテストは、問題の調査、安全な差分の作成、チェックの実行、トレードオフの説明といった「限定された作業を完遂できるか」です。これは単なるコード生成速度ではなく、エージェントのワークフロー能力を測定するものです。

ターミナルエージェントから移行するチームは、永続性とツール間の継続性をテストしてください。セッション、ミッション、IDEでの利用、チームのコンテキスト、自動化ワークフローが、一つのターミナルウィンドウに孤立せず連携することで、Factoryの価値は最大化されます。

オープンソースのエージェントと比較検討している組織は、どこに制御権を置きたいかを判断する必要があります。ソースの可用性とローカルのみの運用が最優先事項であれば、オープンソースのエージェントが適しているかもしれません。ガバナンス、モデル選択、クラウドコンピュータ、チームワークフロー、エンタープライズ向けの可観測性を重視するのであれば、管理されたエージェント・ネイティブ開発プラットフォームとしてFactoryを検討する価値があります。