AI TOOLS
AGI CockpitのQoder・Cursor・ローカルQwen・Fleetを試して、どれをいつ使うか分かった
2026年8月13日 田中啓之（ひろくん）
家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。
いやー、AGI Cockpitって「AIを何個も同時に使える箱」なんだよね。でね、ClaudeやCodexはもう使ってる人が多い。でも画面の奥に、まだ普段使いしてない包丁が残ってる。
Qoder。Cursor。手元で動くQwen。それからFleet。名前だけ聞くと開発者向けに見える。ぶっちゃけ、読者からしたら「で、私はどれを使えばいいの？」が本体だと思う。
だから今回は、私のAGI Cockpit環境で4つを同じ条件で回して、成功だけじゃなく止まった場所まで残す。内部の作業番号とか長い英数字は出さない。読者が頭に絵を描ける話だけ書く。
3行でわかるポイント
- 短い下ごしらえはQoder。味見は早い。でも「使っていい？」を出しすぎて厨房が止まる
- 後から理由を追うならCursor。同じ指摘でも、何が確定で何が推測か読みやすい
- Fleetは献立表。別々のAIを順番につなぎ、機械検査と人の確認を挟める。一本の仕事には重い
そもそもAGI Cockpitって何？
公式の言い方を借りると、AGI Cockpitは「複数のAIに仕事を渡して、進捗と判断と結果をひとつの画面で見るデスクトップアプリ」だよ。ざっくり頼むと、必要なAIを動かして、判断が要るときだけ人に聞いてくる。
公式の入口はここ。AGI Cockpit — AIエージェントの作業OS。英語の説明は What is AGI Cockpit?。最初の一本を回す手順は Install and run your first task。
あ、そうそう。前に声だけで成果物を出す実験もしてる。声だけで成果物が出てくる｜Codex音声対話×AGI Cockpit実験LIVE。今回は声じゃない。画面の奥に残ってた4つの道具の使い分け。
Fleetって何？ 一本の仕事じゃなくて、コース全体
でね、4つのなかでいちばん分かりにくいのがFleetだと思う。私も最初、名前だけ見ても絵が浮かばなかった。単体のQoderやCursorは「一人の料理人に一皿頼む」。Fleetは「献立表を書いて、厨房チームにコースを通させる」。
公式のコマンド説明（AGI Cockpit付属の cockpit help fleet。2026-08-13に実機で読み直した最新文）は、こう書いてある。
公式の定義（原文）
A Fleet is a YAML file declaring a dependency graph of agent tasks, gates, and optional bounded loop groups. A Run is one execution of that Fleet.
日本語にするとこう。Fleetは「どのAIが、どの順で、何をやるか」を書いた設計図。途中に機械の検査や、人の確認も置ける。Runは、その設計図を1回まわした記録。
同じ公式文の続きも大事だよ。設計図の各段は、普通のAGI Cockpitタスクになる。だから一枚の図の中で、ある段はQoder、次の段はCursor、という混成ができる。止まっても、関係ない完了済みの段はやり直さない。
製品ページの更新履歴でも、Fleetはいまも直近で直されてる。AGI Cockpit公式（v4.49.0 / 2026-08-11） では、ループの見え方、検査の判定、確認待ちの扱いが直った、と書いてある。名前だけの実験機能じゃない。毎日使う側の部品として、まだ磨かれてる。
料理で言うと、献立表。前菜が終わってからメイン。メインが二つなら同時に火を入れる。出す前に味見係が塩を見る。最後に店主が「出していい」を押す。その順番を、先に紙に書いておく。
一本だけ頼むなら、公式どおり普通のタスクで足りる。Fleetが要るのは、段があるとき。後の仕事が前の結果を使うとき。同時に走らせたいとき。途中で機械検査や人の確認を挟みたいとき。
判断を人に渡す部品は、公式ではAsk。Askの公式説明は、「AIから人へ判断を渡して、同じ仕事を再開する」と書いてある。Fleetの人の門は、このAskを設計図の途中に埋め込んだもの。
メリットは速さだけじゃない。順番と門を先に決めておけること。デメリットは、門の分だけ人が要ること。設計図がズレると、料理の前に席が空くこと。ここを先に置いてから、今回の実測に入る。
今回やったこと。読むだけ。原本は触らない
私のAGI Cockpit環境で、まだ普段使いしてなかった4つを同じ条件で試した。対象は短いプログラム1本と、外に出したくないメモ1本。やっていいのは読むこと。書いてはいけないのは、原本を変えること。
4つとも実出力までは届いた。原本の変更は0。
ただし「AIが全部勝手にやった」話じゃない。……ここ、大事。
ぶっちゃけ、止まった場所の方が役に立つ。Qoderは不要な確認待ち。Cursorは権限の応答が親から通らない。手元のQwenは最初、器が小さくて落ちた。Fleetは途中でログイン先がずれて、最後は人間の承認ボタンを8時間以上待った。
先に使い分けだけ置く
でね、結論から置く。細かい実測はあとで出てくる。
総合判定は「4案すべて、実用条件つきで利用可能」。残件は0。条件つき、だよ。条件なしで渡せる、じゃない。
Qoder：味見は早い。厨房が止まるのは確認待ち
Qoderは、仕事を渡すと理解・計画・実行・検証まで続けるタイプのエージェント。公式ページの言い方だと「本物の仕事向け」だよ。AGI Cockpit側でも、タスクや定期実行から呼べるようになってる。製品ページの更新履歴に、その追記がある。
場面はこう。短いプログラムを渡す。「読んで、壊れやすいところを最大3つ出して。ファイルは変えるな」。
Qoderは3つ拾った。長く動き続けると古い名簿を使い続ける。失敗を全部飲み込んで中身が見えない。「名前が無い」と「取れなかった」を区別できない。短い番号だけで紐づけると、別の仕事に結びつく余地がある。
提案は、古くなったら更新する。失敗を隠さない。番号の形を確認する。開始と終了で原本は変わってなかった。
ここまでは、短い一次チェックとして使える。一方で、中で動いたモデル名は取れなかった。記録時間は3時間19分。純粋な考える速さじゃない。途中で止まって、不要な確認待ちを含んだ時間。
料理に例えると、味見は早い。でも「この塩、使っていい？」なんて、使わなくていい確認を出して厨房が止まる。人が横にいない無人運用だと、その待ちが本体になっちゃう。
向くのは、短い一次スキャン。最小の直し方まで一気に欲しいとき。向かないのは、どのモデルが言ったかを証跡に残したいとき。確認なしで一晩走らせたいとき。
Cursor：同じ指摘でも、後から追える
Cursorは、コードを書く画面の中でAIが動く道具。AGI Cockpitの公式ページでも、束ねられるエージェントのひとつとして並んでる。
同じファイル、同じ質問、同じ「変えるな」を渡した。独立に、同じ3点を出した。しかもね、「成功したかどうか見てない」「確定と推測を分けて書く」まで出てきた。
4分。
原本の変更は0。一致したのは、古い名簿、失敗の隠蔽、短い番号依存。Qoderは短く直接的で、最小の直し方まで一度に出す。Cursorは、何が入って何が出て、何が確定で何が推測か、読みやすい。後から人が追うレビュー向き。
弱点も隠さない。読み取りの許可を、親側から普通の空Enterでは承認できなかった。回避として、元の文章を指示の中に埋め込む必要があった。原本が変わってない確認は、親が別に取った。
同じ監査の中身はほぼ同等。人が後から「なぜそう言ったか」を追うならCursor。短い一次スキャンならQoder。
手元のQwen：要約はできた。最初は器が小さすぎた
次はコード監査じゃない。外に出したくないメモを、ネットに出さずに要約する話。
公式でも、AGI Cockpit独自のエージェントは手元のLM Studioを連れてこれると書いてある。クラウドに出したくない仕事向け、だよ。経営者の「外に出したくない」不安については、前に LM Studio Bionicは経営者の情報漏洩不安を解消できるか でも書いてる。手元の機械で大きなモデルを回す話は NVIDIA DGX Sparkの使い方と活用術｜ローカルLLM5選 も近い。
今回使ったのは、手元のQwen 3.6。外部検索なし。189字の要約は、アプリ化、販売後のカスタマイズ、1週間プラン、3日目の指名待ち、市場がないときの遅さを残した。論点も、足りない点も、足りないまま書いた。
ここは使える。社外に出したくないメモの、一次整理に向く。
ただし、厳密に「原文に書いてある範囲だけ」で見ると、はみ出した箇所がある。日付から日数を足した記述。次にやることを勝手に決めた箇所。原文の抜き出しじゃなくて、推論寄り。厳格な抽出には、あとで事実チェックが要る。
実行そのものも、一発では通らなかった。最初の器は小さかった。AGI Cockpit経由の実リクエストが大きくて、拒否された。器を大きくして再試行して、そのあと成功した。所要15分は、初回失敗と設定のやり直しを含む。
冷蔵庫の中で下ごしらえはできる。でも器が小さいと、材料そのものより先に、器のサイズで落ちる。……でね、先に器を大きくしてから投げた方がいい。10万token。——器の話だ。
Fleet：機械は約3分。人が押す門は8時間超待った
最後は、単発じゃなくてコース全体。Qoderで一次チェック、Cursorでレビュー、別のAIで統合、機械の検査、人の承認。この順番をつないだ。
公式の製品ページでも、Fleetは複数の仕事を順番や並列でつなぐ仕組みとして更新され続けてる。判断が要るときは、画面の手前に確認が浮かぶ。Askの公式説明は、「AIから人へ判断を渡して、同じ仕事を再開する」と書いてある。今回の最後の門は、まさにそれ。
機械だけの工程は約3分17秒。人の承認待ち込みで8時間27分。原本の変更は0。
統合された指摘は3つ。古い名簿で更新されない。失敗と「無い」を区別できない。説明文と実際の表示が食い違う。直し方の順は、名簿の更新 → 失敗を見える化 → 表示の約束を揃える。機械の門は、その3つと「原本は変わってない」を見て通した。
便利。でも——自動で全部終わった、には見えない。
人の門は、承認があるまで8時間23分待った。機械が合格しても、人間が押すボタンが残る設計だった。
止まる場所も、本番の前に2つ出てる。最初の定義の置き場所が違って、作業場を作る前で止まった。置き場所を変えて解消した。次の回では、画面上は正しいアカウントなのに、実作業がログインしてない側へ落ちて、出力前に失敗した。最終回では、先頭の軽い係が「このアカウントでQoderを1件だけ作れ」と搬送して、あとの流れはそのまま。Qoderの監査そのものを別のAIで代替してはいない。
日常で使うなら、QoderやCursorのアカウントが途中でずれないことと、権限の応答が親から通ることが必要、というのが記録上の結論。コース料理は通せる。でも配膳係が別アカウントの厨房へ行ってしまうと、料理の前に席が空く。最後の味見ボタンは、人間が押す。
4つの道具、読者向けの比較
| 道具 | かかった時間 | 原本 | できたこと | 止まったこと |
|---|---|---|---|---|
| Qoder | 3時間19分（停止と確認待ちを含む） | 変更なし | 主要な壊れ方を3つ拾った | 不要な確認。内部モデル名は非公開 |
| Cursor | 4分24秒 | 変更なし | 同じ3指摘。確定と推測を分けた | 権限の応答が親から通らない |
| 手元のQwen | 15分（初回失敗を含む） | 変更なし | 189字の構造化要約 | 最初の器不足。推論のはみ出し |
| Fleet | 機械約3分 / 人の門込み8時間27分 | 変更なし | 一連の流れと機械検査・人の承認まで完走 | アカウントのずれ。人の承認待ち |
やってないことも残す。別のパソコンへの遠隔実行、スマホ実機の画面操作、別系統のエージェント追加、外部への送信、課金、削除は、今回やってない。
失敗から分かった、使うときの条件
成功したことより、止まった場所の方が、次に使う条件になる。悪いことこそ宝物、だよね。
あ、そうだ。Qoderの不要な確認。指摘自体は使える。無人で回す前提にはしない。人が横にいる短い一次チェック向き。
Cursorの権限応答。空Enterでは親から承認できないことがある。読むだけでも、元の文章を指示に埋め込む回避を先に用意する。原本が変わってない確認は、親が別に取る。
手元のQwenの器不足。本文が小さくても、AGI Cockpit経由だと器が足りなくなることがある。先に大きくしてから投げる。要約のあとに、原文に無い数字や次の一手が混ざってないか見る。
Fleetのアカウントずれ。画面に正しい名前を書いても、実作業がログインしてない側へ落ちることがある。実作業を作るときにアカウントを明示する。古い回は再開しない。機械の門が通っても、人の門は人間が押すまで終わらない。
いやー、悪い結果を隠すと、次の人が同じ場所で止まる。止まった場所こそ、次の手順書になる。
次に試す人向け。読者の手元でやるなら
同じ条件で再現するなら、この順で足りる。作業番号は要らない。
- 公式の 最初のタスク手順 で、AGI Cockpitを開いて一本回せるところまで行く。
- 対象を小さくする。コードなら数十行。文章なら手元のメモ1本。始める前に「今の原本」を控える。
- 最初から「原本を変えるな」と書く。改善案は提案だけ。適用しない。
- Qoderで一次チェックする。3指摘まで。不要な確認が出たら、それは欠陥として記録する。壁時計の時間と、考える時間を混ぜない。
- 同じ条件をCursorへ渡す。指摘の一致、確定と推測の分離、権限応答の成否を見る。
- 手元のQwenを使う前に、器を大きくする。小さい器のままAGI Cockpitへ投げない。要約のあと、原文に無い数字や次の一手を消すか、「推測」とラベルする。
- Fleetは新規の回にする。古い回は再開しない。QoderやCursorにはアカウントを明示する。機械の検査で「原本は変わってない」「指摘は何件か」を見る。最後の人の門は、対象と内容と変更なしを見て人間が押す。Askの公式どおり、決めるのは人。
- 終わりに、原本が変わってないことをもう一度見る。変わってたら、実用トライアルとして成立してない。
結論。渡す場面を決めるのが、こちらの仕事
単発の監査なら、後から根拠を追う用途はCursor。短い一次スキャンはQoder。ただしQoderは、モデル名の開示と確認の制御に弱点がある。
手元の要約は、Qwen 3.6で実用になった。ただしAGI Cockpit経由では、小さい原稿でも大きな器が必要になりうる。厳格な抽出には、後段の事実チェックが要る。
Fleetは、順番つなぎ、別々のAI、機械の門、人の門まで一連で完走できた。機械工程は約3分で速い。いまの最大の弱点は、Qoderのアカウントが途中でずれること。人間判断が必要な門は、省略してない。
しかもね、抱え込みOSのまま4本の包丁を全部自分で研がなくていい。人間は縦に掘る。AIは横に広げる。渡す場面を決めるのが、こちらの仕事だよ。
COLUMN
味見ボタンを消すと、コースは速くなる。でも店は壊れる
正直、機械工程3分17秒だけ見ると、全部任せたくなる。でね、記録はそう言ってない。人の門は8時間23分待って、人間が押してから通った。
「AIに全部やらせる」と「役割を渡す」は別物だよ。AIに全部やらせる前に、役割を渡そうでも同じことを書いてる。渡すなら、止まった場所も渡す。
権限の話も同じ。ガードレールは作っただけでは効かない。言葉で「正しいアカウント」と書いても、実作業がログインしてない側へ落ちることがある。通行証を、実作業まで持っていく。
自動化するほど時間が消える、なんて話もある。90日監査で見えた時間の内訳は、待ちと確認の話だ。今回の不要な確認も、権限の応答も、同じ種類の時間。
競争より共創、だと思う。道具同士を競わせて勝敗をつけるより、短いスキャン・後追いレビュー・手元の要約・一連の門、と役割を分ける。脂肪は財宝と同じで、止まった記録も捨てない。
👉 分身AIについてもっと知りたい方は分身AI.comもチェックしてね！
公式と、読んでほしい参考記事
AGI Cockpit本体
- AGI Cockpit公式（日本語製品ページ）
- 公式ドキュメント：What is AGI Cockpit?
- 公式：最初のタスクを回す
- 公式：Ask（人に判断を渡す）
- Fleetの定義文は、AGI Cockpit付属コマンド
cockpit help fleet（2026-08-13実測）。製品ページの更新履歴は 公式トップのバージョン履歴
今回触った道具の公式
AI氣道の関連記事
