AIオーケストレーションとは？Cursor ProjectsとAstra司令塔運用を比較

重い開発をSolへまとめて任せると、利用上限に当たることが増えました。かといって、作業の途中で使うモデルを自分で切り替え続けるのも簡単ではありません。そもそも、いま進めている仕事のすべてにSolが必要なのか。そこから私は、仕事に合わせて担当を振り分けるオーケストレーションを自分で作り始めました。

現在は、OpenRouterへ約10ドル分のクレジットを入れた自作オーケストレーションに加え、CodexではAstraを司令塔にして、作業をSolやTerraへ振り分けています。そこへ『数千のAIエージェントに仕事を任せられる』というCursor Projectsが出てきました。自分で作った仕組みを残す意味はあるのか。Cursorへ切り替えた方がよいのか。その疑問が、今回比較した出発点です。

先に結論を出します。いまは自作オーケストレーションを残し、匿名データを使う1本の開発でCursor Projectsと比較するのが合理的です。私はCursor Projectsをまだ使っていません。実測前に全面移行も、開発工程の移管も決めません。営業、調査、書類、集計設計、業務ツール開発まで扱う現在の仕組みと、リポジトリ中心のCursor Projectsでは担当範囲が違うからです。

結論：どちらか一つではなく、担当させる仕事が違う

ここで比べているものは同じ階層ではありません。Astra、Sol、Terraは仕事を担うモデルで、Cursor Projectsはコーディネーター、実行環境、リポジトリ連携をまとめた製品です。Cursor側はリポジトリ、ブランチ、実行環境、サブエージェントへの委任が一つにまとまっていますが、それで現在の運用より速く安くなるかは、私の環境ではまだ未検証です。何を集計するか、どの数字を正とするか、顧客情報をどこまで扱うかも、製品を入れただけでは決まりません。

なぜ自作オーケストレーションを作ったのか

最初から、複数のAIを束ねる大きな仕組みを作ろうとしていたわけではありません。Solで開発を進める中で、重い作業を一気に走らせると上限に当たりやすくなり、そのたびに作業を止めたり、使うモデルを切り替えたりする必要がありました。自分で切り替えながら開発全体を管理するのは簡単ではありませんでした。

そこで見直したのが、『この作業は本当にSolでなければできないのか』という点です。難しい判断や複雑な実装と、抽出、整理、定型確認を同じモデルへまとめて渡す必要はありません。仕事を分け、必要な部分にだけ強いモデルを使い、結果を同じ完成条件へ戻す。その切り替えを毎回手で行う代わりに、自分でオーケストレーションを作りました。

今はその仕組みで仕事をこなしています。ただし、自作したこと自体を守りたいわけではありません。Cursor Projectsが、私が苦労して作った振り分けや長期の文脈管理を製品側で担えるなら、切り替える理由になります。だから今回は機能の多さではなく、現在の運用と比べて、上限への対処、モデルの切り替え、保守、確認の手間が実際に減るかを見ます。

AIオーケストレーションは、AIを何人も並べることではない

AIオーケストレーションを私の仕事に置き換えると、中心はモデルの数ではありません。一つの目的を持つ司令塔が、前提、禁止事項、完成条件を保ち、必要な作業だけを別のAIへ渡し、結果を同じ基準へ戻すことです。

• 本人が、目的と外へ出してよい情報を決める
• Astraが司令塔として、全体の判断、作業分解、最終確認を持つ
• SolやTerraが、範囲を限定した調査・実装・レビューを担当する
• 文字数、リンク、差分、テスト結果はスクリプトでも確認する
• 公開、削除、課金、社外送信は本人へ戻す

使っている海外サービスはOpenRouterです。OpenRouterは複数のAIモデルを一つのAPIから利用でき、購入したクレジットを各モデルに使えます。外部経路では、OpenRouterからMoonshot AIのKimi K2.5を使うほか、GoogleのGemini Flash系も使っています。利用記録で確認できたのはGemini 3.5 Flash-Liteです。私は最初に約10ドル分のクレジットを入れ、自分で作ったオーケストレーターから必要なタスクを振り分けています。OpenRouterが仕事の分解まで自動で行うのではなく、どの仕事をどのモデルへ渡すかは自分で組んだ部分です。

約10ドルは私が入れたクレジット額であり、月額料金でも、仕組み全体が10ドルで完成したという意味でもありません。Cursorと比べるときは、モデル利用料だけでなく、構成、受け渡し、修正にかかる時間も数える必要があります。

OpenRouterの公式サイトを確認する

この自作方式の良さは、営業、書類、調査、集計、開発を一つの目的から振り分けられることです。使うモデル、渡す情報、確認手順も自分で変えられます。一方で、文脈の保存、APIの変更、エラー処理、費用の把握、どのAIが何をしたかの記録まで、自分で保守する必要があります。Cursor Projectsへ移る理由があるとすれば、モデルが急に賢くなるからではなく、この開発基盤の保守を製品側へ寄せられる可能性があるからです。

Cursor Projectsで何が変わるのか

Cursorの公式説明では、Projectsは2026年9月10日にベータとして発表され、全ユーザーへ順次提供される機能です。機能開発、移行、アプリ全体の構築など、1回のチャットでは終わらないソフトウェア作業を対象にしています。コーディネーター自身がコードを書くのではなく、計画し、サブエージェントへ仕事を渡し、確認できる成果としてまとめます。長期間の文脈を共有ファイルへ残し、定期作業やSlack、PRをきっかけに動かす設定もできます。

ここが、私の現在の運用との大きな違いです。私は業務全体のルールを自分で組み、最近はAstraを司令塔にして、SolやTerraへ作業を分けています。Cursor Projectsは、ソフトウェア開発で必要になる委任、クラウド実行、リポジトリとの受け渡しを製品側がまとめています。自分で運用を組む手間を減らせる代わりに、仕事をリポジトリと実行環境へ落とし込めることが前提になります。

『数千のサブエージェント』という表現は、公式が示す大規模開発の方向性です。どの仕事でも数千体が同時に動き、必ず速く正確になるという意味ではありません。まず重要なのは、必要なリポジトリ権限、環境設定、テスト、モデル利用料、外部データへの接続を用意できるかです。

Cursor Projectsの公式発表を確認する

自作オーケストラからCursorへ移る理由は5つ

• 仕事の中心が、長期間続く機能開発や移行になった
• ブランチ、PR、テスト、クラウド実行を自分でつなぐ保守負担が大きくなった
• 数週間から数カ月の開発文脈を、製品側で継続して持たせたい
• 定期実行やPR監視から、開発作業を自動で始めたい
• 同じ検体で比べ、正確性、修正回数、準備時間、総費用、手作業が自作より改善した

逆に、現在の仕組みで必要な仕事が回り、営業や書類などコード以外の割合が大きいなら、いま全面移行する理由は弱いです。比較するべき費用はCursorの月額とAPI利用料だけではありません。自作側の保守時間、失敗の修正、確認の手間まで含めます。約10ドルの入金額とCursorの月額は性質が違うため、単純には比較しません。

現在の仕組みとCursor Projectsを8項目で比較

Cursorの料金ページでは、Cloud Agentsを含むProが月20ドルから案内されています。ただし、Cloud Agentsの公式文書では選択したモデルのAPI料金で利用量が計上され、最初に利用上限を設定すると説明されています。月額だけを見て、長時間の並行作業まで定額と考えない方がよいです。料金と条件は利用前に公式で再確認します。

Cursorの現行料金を公式ページで確認する

営業集計の自動化なら、Cursorだけ入れても完成しない

私が自動化したいのは、広告費から問い合わせ、連絡、案内、成約、金額までを毎週・毎月まとめる作業です。現在は、問い合わせと担当者を確認する顧客管理システムと、案内数を記録する別の社内システムに情報が分かれています。さらに、案内の雛形やカテゴリが完全には統一されていません。

この状態で『全部集計して』とCursor Projectsへ頼んでも、担当者の決め方や案内の数え方までは分かりません。接続できたとしても、間違った定義を高速で集計するだけです。先に次の順番が必要です。

• 問い合わせ、連絡成立、案内、成約、売上の定義を本人とAstraで固定する
• 重複、担当変更、月またぎ、分類できない記録の扱いを決める
• 社内規程に従い、匿名CSVや許可されたAPIなど入力方法を決める
• Cursor Projectsへ集計ツールの実装とテストを任せる
• 既存集計と突き合わせ、差異が出た行を本人が確認する
• 精度が安定してから、週次・月次の実行を検討する

受付、事務、店舗の集計にも同じ考え方は使えます。予約、来店、問い合わせ、入会などのデータが取得でき、数え方が決まっていれば、集計ツールを作る候補になります。これは私が各業種で導入した実績ではなく、同じ構造を持つ仕事への応用案です。

私なら、匿名データで小さく比較してから決める

Cursor Projectsへ全面移行するかを、紹介記事だけで決める必要はありません。まず、個人や会社を特定できないダミーまたは匿名CSVを使い、1本の集計ツールを作ります。現在の方法と同じ答えが出るかを確認し、次の5項目を比べます。

• 集計結果の一致率と、誤差が出た項目
• 指示を直した回数
• データ準備から完成までの時間
• 月額とモデル使用量を含む費用
• 最後まで人が行った手作業

この比較で、正確性を落とさず、長期のコード実装と修正にかかる総時間・総費用・手作業が自作方式より改善したら、その工程だけを移します。データの取り出しや定義確認に時間がかかるなら、先に社内側を整えます。AIの人数ではなく、残った手作業で判断します。

私がAntigravityからCursorへ移した理由を見る

営業の困りごと別にAIツールを選ぶ

最終判断：いまは残し、同じ仕事で比べてから移す

私の現在の答えは、Cursor Projectsへ全部を移すことではありません。OpenRouterを使う自作経路と、CodexでAstraを司令塔にしてSolやTerraへ作業を振る現在の運用を残し、Cursor Projectsには匿名データを使う1本の開発を試しに渡します。Cursorから戻った成果は、同じ入力、同じ期待結果、同じ確認項目で現在の方式と比べ、最後は私が採用します。

仕事の中心が大規模な機能開発、移行、継続的なPR作成へ変わり、必要なデータもリポジトリや接続済みサービスにそろい、比較結果でも保守を含む負担が下がったなら、Cursor Projectsを中心に置く判断へ変えます。違いはAIの賢さより、仕事をコードの単位へ落とせるか、自作の保守を減らせるかです。

AIオーケストレーションとCursor Projectsのよくある質問

Cursor Projectsへ移ればAstra・Sol・Terraは不要ですか？

現時点では不要になりません。営業、調査、書類、集計定義まで含む全体判断はAstraへ集め、SolやTerraへ範囲を区切って渡す現在の運用を残します。同じ開発課題をCursor Projectsでも試し、実測で負担が下がった工程だけ移します。

Cursor Projectsは社内システムの数字を自動で集計できますか？

接続方法と権限が必要です。CSV出力、許可されたAPI、MCP等でデータを渡せるかを確認し、指標の定義と例外処理を先に決めます。社内システム名を伝えただけで自動接続されるわけではありません。

数千のエージェントを使えば必ず速くなりますか？

必ず速くなるとは判断できません。分けやすい開発作業には向きますが、定義が曖昧な仕事は並行化しても確認が増えます。小さな実データ代替テストで、時間、修正回数、費用、残る手作業を測ります。

現時点でどちらを選べばよいですか？

仕事の大半がリポジトリ中心の開発ならCursor Projectsを比較候補にします。複数の業務、Web、書類、調査、公開判断をまとめて動かすなら、全体の司令塔を残したまま、同じ開発課題だけCursorでも試して判断します。