Claude CodeとFactory Droidの違い — claude -pとdroid execを比較

Claude CodeとFactory Droidの非対話実行は、どちらもプロンプトを渡して結果を受け取り、終了コードで成否を返す一回きりの実行です。大きく違うのは権限の与え方です。droid execは読み取り専用から始め、--auto low・--auto medium・--auto highの3段階でつまみを上げます。claude -pは権限モードと許可ツールの規則を重ねて組み立てます。

この記事では、FactoryのDroid CLIの構成を押さえたうえで、2つの非対話実行を入口・権限・失敗の扱い・並列実行・プロジェクト文脈の順に比べます。Claude Code側の基本はClaude Code -pモードの記事にもまとめています。

Droid CLIとは何か、Claude Codeのどこに当たるか

Droid CLIは、Factoryのランタイムをターミナルから使うための入口です。対話型のターミナルUIで、プロジェクトの文脈・承認・MCPツール・Missions・ヘッドレス実行を同じランタイムで扱います。Factoryのドキュメントは、対話での作業が安定したらdroid execでスクリプトやCI/CDに移す流れを想定しています。

拡張の部品は次のとおりです。

Missionsだけは、Claude Codeに同じ名前の機能がありません。計画役・作業役・検証役を分け、作業役と検証役のモデルを別に指定できる、droid exec専用の実行形態です。サブエージェントを組み合わせれば似た構成は作れますが、フラグ1本で起動する形にはなっていません。

つまり部品の顔ぶれはほぼ重なっており、差が出るのは非対話実行の細部です。

非対話実行の入口を並べる

プロンプトの渡し方はほぼ同じで、認証の置き方が違います。

Droid側の最小形は次のとおりです。

droid exec "analyze code quality"
droid exec -f prompt.md
echo "summarize repo structure" | droid exec

Claude Code側も同じ形で書けます。

claude -p "このプロジェクトの構成を要約して"
cat build-error.txt | claude -p "根本原因を簡潔に説明して" > output.txt

認証には1つ注意点があります。claude -pに--bareを付けると、OAuthの認証情報もキーチェーンも読まなくなります。その場合はサブスクリプションのログインが使えないので、ANTHROPIC_API_KEYを環境変数に置くか、apiKeyHelperを--settingsで渡します。Droid側は、インストール後にFactoryの設定ページでAPIキーを発行し、FACTORY_API_KEYとして渡す流れです。

権限の与え方 — つまみ1本か、モードと規則の重ね合わせか

非対話実行で最も差が出るのは権限です。

droid execは「作業の危険度」で段階を切る

droid execは、フラグなしでは読み取り専用で動きます。ファイルの閲覧、ディレクトリの一覧、git status・git log・git diffのような読み取りだけが許され、編集・パッケージのインストール・gitの書き込み・デプロイは止まります。そこから--autoで段階を上げます。

--auto highでも、Droidの安全確認は残ります。--skip-permissions-unsafeは全ての権限確認を飛ばしますが、--auto系のフラグとは併用できません。使ってよい場所として挙げられているのは、使い捨てのコンテナ、実行後に破棄されるCIランナー、一時的なVMです。

判断の軸が1本なので、設定を読んだ人が「このジョブはどこまで触れるか」を一目で言えます。逆に、「git commitは許すがnpm test以外のBashは許さない」のようなコマンド単位の許可は、--autoでは表せません。設定のpermissionRulesか、次に挙げるツール単位のフラグで絞ります。

claude -pは「モード」と「規則」を重ねる

Claude Codeの権限モードはdefault・acceptEdits・plan・auto・dontAsk・bypassPermissionsの6つです。非対話実行では、--permission-modeでモードを選び、--allowedToolsで承認なしに実行させるツールを足します。

非対話実行で使い分けが効くのは、主に3つです。

• acceptEdits: ファイル編集と、mkdir・touch・mv・cpのような一般的なファイルシステムコマンドを承認なしで通す
• dontAsk: 事前に許可したツールだけを実行し、承認が要る呼び出しは全て拒否する。公式がCI向けに挙げているモード
• bypassPermissions: 全てを通す。コンテナやVMの中だけで使う前提

dontAskとの組み合わせが、Claude Code側の設計の特徴をよく表します。公式のCI例は、実行できるコマンドを完全一致で列挙する形です。

claude -p "run the test suite" \
  --permission-mode dontAsk \
  --allowedTools "Bash(npm test)" "Read"

この形なら、npm testと読み取り以外は何も走りません。droid exec --auto mediumが「ローカル開発で普通に必要な操作の束」を一括で許すのに対し、こちらは許すコマンドを1つずつ名指しします。

詳しい挙動はdontAskモードの記事にあります。

ツール単位の絞り込みフラグ

どちらにも、使えるツールそのものを絞るフラグがあります。

Droidのドキュメントの例は、--disabled-tools execute-cliのようにツール名で指定する形です。Claude Codeの--disallowedToolsは、Bash(rm *)のようにコマンドの書式まで規則に書けます。なお--additional-toolsと--allowedToolsは名前が近いものの、前者はツールを有効にする指定、後者は承認を省く指定で、働きが同じとは限りません。

規則と「全許可」の関係は逆向きになる

どちらにも、規則でコマンドを止める仕組みがあります。

Droid側は、設定のpermissionRulesでallow・ask・blockを定めます。同じ規則が複数あれば、blockがaskに、askがallowに優先します。非対話実行では承認の応答を返せないため、askに当たるコマンドは--auto highを付けても通りません。blockは--skip-permissions-unsafeでも通りません。旧来のcommandAllowlist・commandDenylist・commandBlocklistは非推奨ですが、後方互換のため引き続き効きます。

Claude Code側は、denyルールがどのモードでも効きます。bypassPermissionsでも同じです。一方でallowルールはbypassPermissionsでは効果を持ちません。全許可のモードでは、足した許可規則が意味を失い、禁止規則だけが残る設計です。

実行前の確認手段にも差があります。Droidには、規則を試すdroid rules checkがあります。

droid rules check
droid rules check --command 'git push origin main' --json

ただし、このプレビューは実行時の全ての確認までは評価しません。検査が成功終了してもblockと報告されることがあるので、終了コードの0は「許可」を意味しません。

同じ作業を両方で組む

「依存を入れてテストを回し、失敗を直す」CIジョブを例に、近い設計を並べます。この2つは仕様上の厳密な等価物ではなく、許す範囲が近くなるように選んだ組み合わせです。

# Droid: ローカル開発の操作をまとめて許す
droid exec --auto medium \
  "install deps, run tests, and fix failing checks"
 
# Claude Code: 許すコマンドを名指しする
claude -p "install deps, run tests, and fix failing checks" \
  --permission-mode acceptEdits \
  --allowedTools "Bash(npm install)" "Bash(npm test)"

Droidの--auto mediumは、git commitまで許します。Claude Code側で同じ範囲を許すなら、Bash(git commit *)のような規則を足すことになります。逆にDroidで「npm test以外のBashは通さない」を表したければ、--autoの段階では足りず、permissionRulesで規則を書くか、--disabled-toolsでBashに当たるツールを外す形になります。

読むべき差は、デフォルトの置き方にあります。Droidは危険度の段階に作業を当てはめ、Claude Codeはツール単位の許可を積み上げます。ジョブの内容が「Factory側の段階にきれいに収まる」なら前者が楽で、「許すコマンドが数個に決まっている」なら後者が締まります。

失敗の扱いと出力形式

CIでは、失敗をどう検知するかが設計の中心になります。

終了コードと止まり方

droid execは、成功で0、失敗で0以外を返します。失敗には、権限の違反・ツールのエラー・目的を達成できなかった場合が含まれます。要求した操作が現在の自律レベルを超えると、すぐ止まって明確なエラーを出し、部分的な変更は残しません。

claude -pも、成功で0、失敗で0以外を返します。ただし無効なフラグは実行前に標準エラー出力へ出る一方、認証切れのように実行中に起きた失敗は、結果として標準出力に書かれます。スクリプトで拾うときは、終了コードに加えて出力の中身も見ます。

if ! claude -p "run the test suite" \
    --permission-mode dontAsk \
    --allowedTools "Bash(npm test)" "Read" > result.txt; then
  echo "claude -p failed" >&2
  exit 1
fi

SIGTERMの扱いも、Claude Code側には明記があります。killやプロセス管理から止めると終了コード143で終了し、進行中のターンは未完のまま、結果も記録されません。ターンを正常に終わらせたいなら、先にSIGINTを送ります。Droidのexecのページには、シグナルの扱いを説明する節がありません。

出力形式

JSON出力のうち、Droidの結果にはresult・session_id・duration_ms・num_turnsが含まれます。Claude Codeの結果には、total_cost_usdとモデル別のコスト内訳が入ります。スクリプトからの課金の見積もりを取りたいなら、Claude Code側のほうが材料が揃っています。この値はクライアント側の見積もりで、請求額とは差が出ることがあります。

ストリームの扱いは、設計が違います。Claude Codeのstream-jsonは、1行が1イベントのJSONです。Droidのstream-jsonrpcは、標準入出力で相手に呼びかける、JSON-RPCの形です。1行が1リクエスト、1行が1レスポンス・通知になります。自前のUIやオーケストレーターを作るなら、後者のほうが制御面が広くなります。古いstream-json入力も動きますが、非推奨で警告が出ます。

実行の上限にも差があります。Claude Codeには、ターン数の上限--max-turnsと、推定費用の上限--max-budget-usdがあります。droid execのオプション一覧には、これらに当たるフラグがありません。

並列実行と隔離

どちらも、gitのworktreeで並列ジョブの衝突を避けられます。

Droid側は-w, --worktree [name]です。専用のブランチでworktreeを作って実行し、クリーンなworktreeは終了時に自動で消えます。変更が残ったworktreeは、レビューとpushのために保存されます。

droid exec --worktree codemod-a --auto medium "apply codemod A" &
droid exec --worktree codemod-b --auto medium "apply codemod B" &
wait

Claude Code側にも--worktree(-w)があり、<repo>/.claude/worktrees/<name>に隔離された作業ツリーを作って始めます。名前を省けば自動で付きます。書き方は同じ形になります。

並列ジョブごとに別の段階を与えたい場合、Droidは--auto、Claude Codeは--allowedToolsをジョブごとに変えます。ここで書き込みの範囲を確定させるのは、worktreeではなく権限の側です。worktreeは作業ツリーを分けるだけで、シェルの副作用は分けません。

作業ディレクトリは、Droidなら--cwd <path>で指定します。モノレポで範囲を絞るときに使います。

プロジェクト文脈と再現性

FactoryのドキュメントにはAGENTS.mdのガイドがあり、プロジェクト固有の指針を置く場所として案内されています。Claude CodeはCLAUDE.mdを読みます。両方のツールを同じリポジトリで使うなら、指示ファイルが2つになる可能性があります。Claude CodeがAGENTS.mdを読まない原因は、Claude CodeでAGENTS.mdが動かない原因の記事にまとめています。

CIで差が出やすいのは、実行環境が持ち込む設定です。claude -pは、--bareなしだと対話セッションと同じ文脈を読みます。作業ディレクトリや~/.claudeにある設定も対象です。具体的には、フック・スキル・サブエージェント・プラグイン・MCPサーバー・自動メモリ・CLAUDE.mdです。チームメイトの~/.claudeにあるフックが、CIの結果を変えることがあります。

--bareは、これらの自動探索を全てやめます。必要な文脈は、フラグで明示的に渡します。

Claude Codeのドキュメントは、--bareをスクリプトとSDK呼び出しの推奨モードとしており、将来-pの既定になる予定です。droid execには--append-system-promptと--append-system-prompt-fileがあり、--disable-builtin-skillsでFactory提供の組み込みスキルを外せます。ただし、オプション一覧に--bareのような「自動探索を全部切る」スイッチはありません。

どちらを選ぶか

段階で運用するならDroid、許すコマンドを固定するならClaude Codeが合います。

• 作業を「読むだけ」「編集」「ローカル開発」「デプロイ」の段階で分けて運用したいなら、--autoの3段階が説明しやすい。Missionsや、JSON-RPCで自前のクライアントを組む用途も、Droid側にだけある
• 許すコマンドを数個に固定し、それ以外を機械的に拒否したいなら、dontAskと--allowedToolsが向く。ターン数・費用の上限、スキーマ指定の出力、--bareによる再現性も、Claude Code側のフラグで揃う
• Factoryの組織で既にDroidが標準になっているなら、権限の段階を--autoで決めて、規則はCIの外のdroid rules checkで試す運用が自然

もう1つの比較記事として、Augment CodeとClaude Codeの違いもあります。クラウド自動化まで含めた比較が必要なときの参考になります。

どちらの製品でも、非対話実行の安全性の基本は「最も低い権限から始めて、足りないぶんだけ上げる」ことです。Droidのドキュメントは最も低い--autoの段階を勧め、Claude Codeは--allowedToolsの列挙から始められます。本番変更やgit pushを伴うジョブだけは、使い捨てのランナーで動かし、--skip-permissions-unsafeやbypassPermissionsは隔離された環境に限る、というのが2つのドキュメントに共通する線引きです。