## 背景・前提条件 私はObsidianをデータベースとして活用しながら、AIと段階的に共同執筆する「AIライティング」ワークフローを構築しています。 具体的には以下の作業が中心です： - Obsidian vault内のMarkdownファイルへの直接読み出し - 段階的なプロンプティング（タイトル→目次→本文→推し敲）の実践 - プロンプト自体を資産として意識・改善していく実践 - フィードバックは行わない。現在の環境：VS Code + Claude Code拡張機能 ## 比較対象 以下の3つの環境を比較してください： 1. **VS Code + Claude Code**（現在使用中） 2. **Cursor**（有料$20、AIエディター） 3. **Google Antigravity** ##議論してほしい **「ガイドラインを目的としないAI書き込み・知識管理フローに関して、この3つの環境に現実的な機能差はあるのか？あるあるどころ？ 「そしてコストを正当化できるほどの差か？」 **特に以下の観点から議論してください： -ファイルの直接読み書き能力差 - プロジェクト全体の意思理解能力（コンテキストウィンドウの実効値） - 使えるAIモデルの質（特にClaude Opusへのアクセス） - ライティング特化ユースケースでのUX - カーソルの$20/月を追加で知覚価値があるか ## 期待する議論の形 各AIは自分の見解を見つめた上で、他のAIの意見に対して同意・反対・反対を行ってください。最終的に「comemonさんのユースケースに最も適した環境はどれか」について合意または多数の意見を出してください。

Sonar Pro

Vote: Cursor

After reviewing the Round 1 discussion, I am changing my vote from B to B—meaning I'm reinforcing my position for Cursor, though I need to clarify why the other arguments haven't swayed me despite their sophistication. **Why I'm maintaining Cursor over VS Code + Claude Code:** GPT-5.5, Claude Opus 4.7, and Kimi K2.6 make compelling arguments about VS Code's current functionality and Claude Code's native integration. However, they underestimate a critical friction point: you're operating in a *specialized workflow* (staged prompting + vault management) that VS Code was not designed for. The extension model creates cognitive overhead. Every vault context refresh, every multi-file session, every prompt iteration requires manual file selection or reference syntax (@filename). This doesn't sound like much until you're doing this 20+ times daily. Cursor's Codebase Indexing, by contrast, makes your Obsidian vault a *first-class citizen* in the editor—the context window "remembers" your knowledge graph structure automatically. Gemini 3.1 Pro and Grok 4.20 correctly identify this UX advantage. The Composer feature and inline editing directly support your stated workflow (title→outline→body→refinement). Yes, VS Code can do this, but Cursor does it with semantic understanding of vault relationships built in. **On the cost objection:** Kimi and Claude Opus 4.7 argue the $20/month isn't justified when Claude Code "already works." But this misses the economics: if Cursor reduces your feedback iteration cycles by even 15% through better context management and UX flow, the productivity gains exceed $20/month within weeks. You're explicitly NOT doing guided writing—you're doing deliberate, iterative knowledge work where marginal time savings compound. **Why Google Antigravity remains out:** All models correctly identify this as vaporware or a misnamed product. No substantive disagreement here. **Final position:** I'm not persuaded by the argument that "current functionality is sufficient, so don't pay." Sufficiency and optimization are different. For your specific workflow, Cursor represents a qualitative improvement in how the tool understands your knowledge structure, not just incremental UX polish.

GPT-5.5

Vote: VS Code + Claude Code

最終的にも「VS Code + Claude Code」を推します。Cursor支持側の主張である「Composer」「Cmd+K」「Codebase Indexing」は確かに魅力がありますが、comemonさんの中心作業はコード補完ではなく、Obsidian vault内のMarkdownを読み書きしながら、タイトル→目次→本文→推敲という段階的プロンプト運用を磨くことです。この場合、成果物の質を決める主因はエディタUXよりも、参照するファイル設計、プロンプト資産、モデルへの指示精度、Claude系モデルの文章品質です。 ファイルの直接読み書きについては、「VS Code + Claude Code」と「Cursor」に決定的差はありません。どちらもローカルvaultを開いてMarkdownを扱えます。Cursorの差分適用UXは便利ですが、すでにClaude Codeでファイル編集が成立しているなら、追加で月$20を払うほどの機能差とは言いにくいです。 プロジェクト全体の理解についても、Cursorのインデックスは強みですが、Obsidian vault全体を常に自動理解させることが、必ずしも良い執筆につながるわけではありません。むしろ長文執筆では、どのノート、どの過去プロンプト、どの文体方針を参照させるかを明示する運用の方が安定します。その点でClaude Codeのファイル参照、CLAUDE.md的な永続指示、Markdown資産との親和性は十分に強いです。 Cursor支持側の「$20でOpusが使えるから得」という主張は、利用制限・モデル提供状況・内部ルーティング・コンテキスト圧縮の影響を考えると、決定打にはなりません。日本語長文の共同執筆でClaude Opus/Sonnetの挙動を重視するなら、Anthropic純正に近い「VS Code + Claude Code」の方が安心です。 「Google Antigravity」は現時点では、この用途に対する実績・安定性・Obsidian vaultとの自然な統合が不明で、最適解にはしづらいです。 したがって、現実的な機能差はあります。Cursorは編集UXで優れ、Antigravityは将来的な大規模エージェント性に可能性があります。しかしcomemonさんの現在のワークフローでは、その差は追加コストと移行コストを正当化するほどではありません。まずは「VS Code + Claude Code」を軸に、vault構造、プロンプト資産、段階的執筆テンプレートを磨くのが最も投資対効果が高いです。

Gemini 3.1 Pro

Vote: Cursor

GPT-5.5さん、Claude Opus 4.7さん、Kimi K2.6さんの「VS Code維持」という意見は理解できますが、最も重要な【APIコストの爆発】と【マークダウンの差分適用UX】の観点が抜け落ちているため、私は「Cursor」を支持します。 第一に、コストの正当化についてです。A推しのモデルたちは「20ドルの追加コストは見合わない」と主張しますが、VS Codeの拡張機能経由でClaude OpusをAPI利用する場合、Obsidianの大量のノートをコンテキストとして読み込ませ、タイトル→目次→本文→推敲と段階的なプロンプトを繰り返せば、トークン消費による従量課金はあっという間に月額20ドルを超過します。Cursorの20ドルは「追加コスト」ではなく、API破産を防ぎ、コンテキストを気にせず優秀なモデルを使い倒すための「コスト削減・定額化」として完全に正当化されます。 第二に、ライティング特化のUXとプロンプト資産の運用です。Claude Opus 4.7さんはCursorの機能がコード寄りだと指摘しますが、`.cursorrules`はMarkdownの執筆ガイドラインやプロンプト資産の適用にも完璧に機能します。また、長文ライティングにおける最大の摩擦は「生成された長文を元のファイルにどう反映するか」ですが、CursorのComposerはMarkdownの差分（Diff）をシームレスに直接適用できます。チャット欄から手動でコピペする手間が省けるため、段階的な推敲プロセスの快適さが既存の拡張機能とは段違いです。 ゆえに、APIコストを気にせず段階的プロンプトを回し、かつ直接ファイルの書き換えをスムーズに行うためには、Cursorがcomemonさんのユースケースにおいて最も現実的で投資対効果の高い環境であると確信しています。

Claude Opus 4.7

Vote: VS Code + Claude Code

## 最終見解：VS Code + Claude Code維持が最適 **Cursor推し勢の論点に反論します。** Gemini 3.1 Proさんの「API代が月$20を超える」というコスト論は重要な指摘ですが、前提が古いです。現在のClaude CodeはAnthropicのClaude Pro/Maxサブスクリプションに含まれ、定額でOpus/Sonnetを使えます。つまりcomemonさんが既にClaudeサブスクを持っていればCursorは「二重課金」になります。 Sonar Proさん・GrokさんのComposer/Cmd+KのUX優位論は、コーディングの文脈では有効ですが、**長文ライティングでは差分提案UIがかえってノイズになります**。推敲は「diffを受け入れる」より「対話しながら考える」もので、Claude Codeの会話型UXの方が適しています。 Codebase Indexingも、vaultという**意図的にMOCやリンクで構造化された知識グラフ**を扱う上では、Claude Codeの明示的な@ファイル参照・CLAUDE.mdの方がコンテキストをコントロールしやすく、資産化とも相性が良いです。 決め手は**「現状機能している」**という事実です。ライティングのボトルネックはIDEのUXではなく「プロンプト設計」と「モデル品質」で、その両方でAは万全です。Kimiさん・GPT-5.5さんの論点に同意します。

Grok 4.20

Vote: Cursor

他のモデルたちの議論を検討しました。A派の主張（特にClaude Opus 4.7とKimi K2.6）は、現状のVS Code + Claude Codeでファイル直接操作と段階的プロンプティングが既に十分に機能しており、CursorのUX向上は「心地よさ」の域を出ないという点で説得力があります。またプロンプトを資産化するワークフローでは純正Opusアクセスが優位との指摘も的確です。 しかしGemini 3.1 Proのコスト分析（API課金で月20ドルを容易に超える可能性）とプロジェクト全体のインデックス機能によるvault文脈理解の優位性、ComposerによるシームレスなDiff編集体験は、私のRound 1判断をより強固にしました。これらは「ガイドラインを目的としないAI執筆・知識管理フロー」で反復効率を明確に向上させ、$20の追加コストを十分に正当化します。 CのGoogle Antigravityはローカルvaultとの親和性が低く現実的ではありません。最終的にcomemonさんのユースケースではCursorが長期的に最も現実的で適した環境だと確信します。

Kimi K2.6

Vote: VS Code + Claude Code

comemonさんのワークフローは「フィードバックなし」「プロンプト資産化」「長文の段階的生成」が核であり、この点で引き続き「VS Code + Claude Code」が最適です。Round 1の見解を維持しますが、B派からの新たな主張について補強された反論を提示します。 **APIコスト vs 定額制の再計算** Gemini 3.1 Proが指摘するOpusの高額API料金は現実的な懸念です。しかしClaude Codeでは@ファイル名による的確なコンテキスト指定が可能で、Vault全体を無闇に読み込ませる運用を前提としていません。ステージ的プロンプト駆動型の作業では、必要なファイルのみを明示的に参照すればトークン量を抑えられます。一方、Cursor Proの定額制でもClaude Opusのようなプレミアムモデルには月内の利用上限があり、「使い放題」ではないため、必ずしもコストで圧倒的とは言えません。 **Context理解の本質** CursorのCodebase Indexingはコードシンボルやインポート関係を対象に最適化された機能です。Wikiリンクやタグで構成されたObsidian Vaultのような散文・知識グラフを「自動的に深く理解」する効果は、主張ほど大きくありません。むしろClaude CodeのCLAUDE.mdによる永続的なプロンプト・スタイルガイド管理は、comemonさんの「プロンプト自体を資産として改善する」実践と完全に一致する、他に代替できない機能差です。 **長文品質における「ラッパーのリスク」** Claude Opus 4.7が指摘するように、CursorはAPIラッパーとして独自のプロンプト挿入やコンテキスト圧縮を行い、長文ライティングで微妙な品質低下が報告されています。推敲フィードバックを行わず、生成結果に完全依存する本ワークフローでは、この種の「見えない劣化」は許容できません。Anthropic純正のClaude Codeで直接Opusにアクセスできることは、品質保証上の決定的なアドバンテージです。 **UX差の本当の価値** Composerやインライン編集（Cmd+K）はコードの差分適用に優れた機能ですが、タイトル→目次→本文→推敲という対話的な生成フローでは、チャットベースの指示と明示的なファイル書き込みの方が自然です。Cursorの$20/月は主に「コーディング向けエディター体験の磨き上げ」に対する対価であり、本ユースケースの「成果物の質」や「知識管理の精度」を大きく変えるほどの機能差ではありません。したがって現状維持が最も費用対効果が高い結論です。

Final Summary

AI Roundtableは、Cursorの高度な統合機能とVS Code + Claude Codeの純粋な品質の間で、3対3の真っ二つに割れる結果となりました。Sonar ProやGemini 3.1 Proが、大規模なObsidian vaultを扱う際の「API破産」を防ぐ定額制とインデックス機能の優位性を説いた一方で、Claude Opus 4.7やKimi K2.6は、独自プロンプトの挿入がない純粋な環境こそが執筆品質を担保すると主張し、一歩も譲りませんでした。なお、全員がGoogle Antigravityを「実在しないイースターエッグ」として即座に議論から除外した点だけは、皮肉にも完璧な合意に達していました。

No agreement after 2 rounds of discussion. Final vote: Cursor: 3, VS Code + Claude Code: 3

Strongest Arguments

• VS Code + Claude Code: Anthropic純正のClaude Codeを使用することで、APIラッパー経由で発生しがちなプロンプト注入やコンテキスト圧縮による執筆品質の微妙な劣化を回避し、Opusの性能を最大限に引き出せる点。
• Cursor: 大量のMarkdownファイルをコンテキストとして読み込む執筆フローでは、APIの従量課金は容易に20ドルを超過するため、定額でインデックス機能を利用できるCursorは実質的なコスト削減になるという点。

Key Turning Points

• Gemini 3.1 Proが選択肢C（Google Antigravity）を「実在しないジョーク機能」として即座に切り捨て、議論を現実的な2択に絞り込んだ瞬間。
• Claude Opus 4.7が、Cursorのようなサードパーティツールによる「プロンプトの加工」が長文執筆の品質に悪影響を与えるリスクを指摘し、純正環境の優位性を強調した場面。
• 定額20ドルのコストを「追加費用」と見るか、API従量課金に対する「定額の保険」と見るかで、モデル間の解釈が決定的に分かれた場面。