個人でアプリ事業とブログメディアを並行して運営していると、一日の生産性を左右するのは「自分が寝ている間にどれだけ仕事が進むか」だと痛感します。複数サイトの自動投稿パイプラインを組み、夜間にバッチを走らせる運用を続けるなかで、私が繰り返し感じてきたのは、人間の手を離れた時間が長いほど、最初に与えた方針の質が指数的に効いてくるという感覚でした。Antigravity と Claude Code を毎日併用している個人開発者の立場から、この「自律時間」の設計を改めて考え直す材料が、ある新モデルのデモに詰まっていました。
先日 GIGAZINE が報じた Alibaba Qwen チームの新モデル Qwen3.7-Max は、まさにその「人間の手を離れた時間」の限界をひとつ押し広げたモデルでした。SGLang の Extend Attention Kernel を、学習時に見ていない T-Head ZW-M890 PPU 上で、約35時間・432回のカーネル評価・1158回のツール呼び出しを通じて自律的に最適化し、Triton 参照実装に対して幾何平均で10倍の高速化を達成したと報告されています。Claude Code を中心に Antigravity も併用している個人開発者として、このデモから自分のワークフローに取り込める設計を整理しておきます。
参考にした元記事はこちらです：Alibaba が AI エージェント向け新モデル「Qwen3.7-Max」を発表、35時間の自律作業と1000回超のツール呼び出しに対応 — GIGAZINE 。
35時間という数字を、個人開発者の現実に翻訳する
「35時間ぶっ通しで自律実行」と聞くと、企業の研究開発の話に聞こえます。ですが、自分の現場に落とすとこういう数字です。
ブログ運用での自動投稿パイプラインは、4サイト×4本/日＝16タスクが毎日走る
アプリ事業では、月1回のアセット差し替えと半年に1回の OS 対応更新がある
文献調査や競合分析は、数日かけて段階的に深まる
このうち「途中で人間が介入しないまま、複数の依存関係を整理して進める」性質のものに、Qwen3.7-Max のような長時間自律モデルが効きます。逆に、毎ステップ人間の判断が必要なタスクは、35時間の数字が意味を持ちません。Qwen3.7-Max のデモが示しているのは「自律で続けられる粒度のタスクなら、人間が介入しなくても改善し続けられる」という設計可能性です。
私の現場で、まずこの設計が効きそうなタスクは下記の3つです。
アプリの A/B テスト自動化 — eCPM が時間帯で変動する AdMob まわりを、夜中に走らせて翌朝レポートブログサイトの内部リンク再設計 — 1記事追加するたびに既存記事の内部リンク候補を再計算記事の文体パーソナライズ検証 — 5,000本超のストックに対して、月1回の文体スコアリング
35時間に達するタスクは稀でも、「8〜12時間の長時間タスクが安定して走るかどうか」は、個人開発者にとって死活的に重要な基準になります。
Qwen3.7-Max のベンチマークを、私が見ている価格レンジで読み直す
GIGAZINE の元記事には、Qwen3.7-Max の主要ベンチマークが整理されていました。コーディング AI エージェント関連だけ抜き出すと下記です。
ベンチマーク Qwen3.7-Max DeepSeek-V4-Pro Max Claude Opus-4.6 Max
Terminal-Bench 2.0 Terminus-2 69.7 67.9 — SWE-bench Verified 80.4 80.6 80.8 MCP-Mark 60.8 — — MCP-Atlas 76.4 — 75.8
SWE-bench Verified が 3 モデルで 80 前後にきれいに揃っているのは、コーディング系の上位帯がほぼ天井に近づいているサインだと読み取っています。差がつくのは MCP-Mark・MCP-Atlas のような「実行環境をまたいでも崩れないか」を測る評価です。Qwen チームが Claude Code・OpenClaw・Qwen Code の各実行環境で一貫した性能が出たと強調しているのは、ここを評価軸として打ち出したいからでしょう。
私の選定基準は、ベンチマークの絶対値ではなく次の3点です。
長時間タスクで落ちないか — 8時間以上のジョブで再現可能かMCP の癖に引っ張られないか — 同じプロンプトを別環境で動かしたとき、結論が大きくブレないかトークン単価が読めるか — 月の運用予算に対して、価格変動が突然来ないか
Qwen3.7-Max は Alibaba Cloud Model Studio 経由で OpenAI 互換 API と Anthropic 互換 API の両方が用意される予定とされており、既存の Claude Code 用ハーネスをそのまま使い回せる可能性が高いのが個人開発者には大きな利点です。
1158回のツール呼び出しが意味すること — 失敗を内包した設計
Qwen3.7-Max のカーネル最適化デモで最も学ぶところがあるのは、ツール呼び出し回数の多さです。1158回という数字は「1回平均1分10秒で何かを実行している」計算になります。多くは失敗・部分的成功・再試行の繰り返しのはずで、Qwen チームは「Qwen3.7-Max が1000回を超えるツール呼び出しの間も最適化方針を保ち、30時間を超えた後も意味のある改善を見つけ続けた」と書いています。
ここから私が取り出した設計原則は3つです。
失敗を捨てない — 失敗ログを次のツール呼び出しの入力として再利用できる構造にする方針メモを持たせる — 数百回のツール呼び出しの間に、最初の方針が散逸しないように要約を更新し続ける検証器を分離する — タスクを解く側と、解けたかを判定する側を明確に分ける
3つ目の「検証器の分離」は、Qwen チームが学習設計の節で説明している「タスク・実行環境・検証器を分離し、組み合わせを変えながら訓練する」という考え方とも整合します。Antigravity でエージェントを作るとき、私もこの分離は強く意識しています。
// 検証器を分離した最小構成例（TypeScript） type Verifier = ( artifact : string ) => Promise <{ passed : boolean ; signal : string }>;
async function autonomousLoop ( task : string , tools : Record < string , Function >, verifier : Verifier , policyMemo : string , ) { for ( let step = 0 ; step < 1200 ; step ++ ) { const action = await planNextStep ({ task, tools, policyMemo }); const result = await runAction (action, tools); const checked = await verifier (result.artifact);
policyMemo = await updatePolicyMemo ({ previous: policyMemo, lastAction: action, lastResult: result, verdict: checked, });
if (checked.passed && checked.signal === 'final' ) break ; } } policyMemo を毎ステップ更新するこの構造は、私が Lacrima と Mystery の自動投稿パイプラインでも採用している型です。1500回近いツール呼び出しを耐えるには「文脈の要約を捨てない」「検証は別人格」が効きます。
Antigravity と Claude Code をどう使い分けるか
私は Antigravity（Google）と Claude Code（Anthropic）を併用しています。Qwen3.7-Max のような長時間自律モデルが台頭してきた今、3つの軸で使い分けています。
軸 Antigravity が強い場面 Claude Code が強い場面
マルチエージェント Subagents の並列実行・タスクの直交分割 単一エージェントの深い推論・対話的ループ 実行環境 Cloud VM を瞬時に立てて検証する ローカルマシン上で安全に試す ファイル監査 リポジトリ全体のスキャンを並列で 局所的なリファクタを丁寧に
Qwen3.7-Max のような「環境依存性が低いと主張するモデル」が増えてくると、Antigravity と Claude Code どちらで動かしても結果が大きくブレないことが期待できます。これは個人開発者にとって、ロックインリスクを下げる動きとして歓迎すべきです。
ただし、私が3ヶ月使ってきた感覚では、ローカルファイル操作とユーザーへの問いかけが頻繁に絡むタスクは Claude Code、Cloud 上のスクラッチビルドや並列タスクは Antigravity という線が今のところ最も実用的です。Qwen3.7-Max を試す場合も、まずはこの線引きの上で「Claude Code 互換 API として呼ぶ」「Antigravity の Subagent として呼ぶ」の両方を検証する計画にしています。
自分のリポジトリで MCP-Mark 相当の評価セットを作る
MCP-Mark・MCP-Atlas のような評価セットは、Qwen チームが評価しているのと同じ形では使えませんが、自分のリポジトリで似たことはできます。私が組んでいる評価セットの構造は下記です。
タスク — 「content/articles/ja/agents/ から特定の条件に合致する MDX を抽出する」など、リポジトリに閉じた具体タスクを10本実行環境 — Claude Code（ローカル） / Antigravity Subagent / OpenAI 互換 API 直叩き、の3環境検証器 — 期待出力（JSON）との差分を取り、合格/不合格を機械的に判定
# 評価セットの呼び出し例 for env in claude-code antigravity openai-compat ; do for task in tasks/*.json ; do result = $( ./run_task.sh " $env " " $task " ) ./verify.sh " $task " " $result " done done > eval-$( date +%Y%m%d ).log このような評価セットを月1回回しておくと、新しいモデルが出てきたときに「自分のワークフローでどれくらい使えるか」を客観的に測れます。Qwen3.7-Max のような新モデルを試すときも、すぐに評価セットに通せる準備をしておくことで、誇大評価にも過小評価にも振らされずに済みます。
トークン単価のシミュレーション — 個人開発者の現実値
35時間の自律実行は、トークン単価でどれくらいになるのか。具体的なモデル別単価は公開待ちですが、私のブログ自動投稿パイプラインでの実測値から仮の計算をしておきます。
1記事の生成で、入力トークン約 8,000 + 出力トークン約 6,000 を使う
1日4本×4サイト = 16本 → 月 480本
月のトークン消費は約 670 万入力 + 290 万出力 = 約 960 万トークン
これを Claude Opus 4.6 相当の単価（仮に入力 $15/M、出力 $75/M）で見ると、月のトークン代だけで $100〜$330 のレンジに収まります。Qwen3.7-Max のような新モデルがこの 1/10 のコストで同等性能を出してくる場合、年間で見ると $1,000〜$3,000 の差になり、個人開発者にとっては選定理由として十分大きいです。ITmedia が「Cursor 開発の新モデル、コスト 1/10 で最先端モデル並み性能 第三者機関が評価」と報じている Cursor Composer の話も、同じ文脈で読むことができます。
まとめに代えて — 個人開発者が「自律時間」をどう投資するか
Qwen3.7-Max のような長時間自律モデルが普及していくと、個人開発者にとっての時間設計が変わります。これまでは「人間が起きている時間にどれだけ濃く働けるか」が勝負でしたが、これからは「人間が寝ている時間にどれだけ良い自律タスクを走らせられるか」が同じくらい重要になってきます。
私自身、1997年に独学でプログラミングを始めた当時は「夜中に動き続ける何か」と聞くと、コンパイラの長時間ビルドくらいしか想像できませんでした。今は、深夜に Claude Code が文体パーソナライズを確認し、明け方に Antigravity が翌週分の記事案を整理し、朝起きたら自分はその結果を判定する側に回っている、という運用が現実になっています。
Qwen3.7-Max が示した「35時間・1158回」という数字は、自分のワークフローに置き換えると「夜から朝までに3〜4回分の長時間タスクを安全に走らせられるか」という問いに翻訳できます。次のアクションとして、自分の評価セットを1つだけ書いてみてください。1つあれば、新しいモデルが出るたびに比較できるようになり、誇大広告に流されずに済みます。