Gemini Sparkの下書きをClaude Codeに渡したら、正しくしようとして面白くなくなった

自分は今、ブログを書くのに3つのAIを使っています。Gemini Spark、Claude Code、それにCodexというやつです。

先日、大阪のワンルーム投資について1本書こうとしました。金利の見直し通知が実際に来たので、その話です。

まずSparkに下書きを作らせました。出てきたのは1,800字くらい。読んでみて、これはこのままでも記事になるなと思いました。

そこからClaude Codeに渡しました。事実を調べて自分の体験を足してもらえば、もっと面白くなるはずだと思ったからです。

戻ってきた原稿は、5,400字でした。

3倍です。

約1,800字が、5,400字になって戻ってきた

正しくしようとした跡は、たしかにたくさんありました。

Sparkが「毎月の返済額はおよそ3,000円〜3,500円増加」と書いていた数字は、条件を置いて計算し直されていました。実際は3,501円から3,903円。合っていませんでした。

家賃の改定も、法律の条文まで確認されていました。自分が「更新か退去のときしか上げられない」と思っていたところは、法律上はそうではないと直されていました。

数字も、法律も、出典も、たしかに強くなっていた。

それでも、読み始めてすぐに「これは違う」と思ったんです。

消えていたのは、中身ではなく「運び」だった

あとから2つの原稿を並べて、何が変わったのかを見ました。

書き出しがこれです。

戻ってきた原稿（5,400字の方）

通知を見て分かったのは、自分のローンに5年ルールと125%ルールが付いていた、ということでした。金融機関の説明では、こう定義されています。

このあと、銀行の用語集から定義が2つ引用され、さらに引用ブロックが続き、さらに注意書きが付きます。

書き直した原稿（実際に公開した方）

構えて口座を見たのですが、毎月の引き落とし額は変わっていませんでした。

同じことを書いているんです。5年ルールの話です。

でも、片方は用語の説明から始まり、もう片方は自分が口座を見た瞬間から始まっている。

消えていたのは、事実でも数字でもありませんでした。Sparkが持っていた話の運び方です。

具体的には、この3つでした。

1. 話が前へ進むテンポ
2. 結論がはっきりしていること
3. 全体の組み立て・順番

面白いのは、「思いつかない切り口」は消えていなかったことです。Sparkが特別に賢いことを言っていたわけではない。

つまりSparkの価値は、賢さではなく、読ませる形だったんですね。渡す前の自分は、それを言葉にできていませんでした。

正しくしようとするほど、話が止まる

なぜこうなったのか。あとで整理して、3つ分かりました。

1つ目。一般論を「置き換え」ずに「足した」。

Sparkが「一般的にはこうです」と書いた部分を、自分の実体験で置き換えるべきでした。ところが実際は、一般論を残したまま、その下に「そして自分の場合は」を足していた。全部の章が二重構造になっています。

これで倍近くになりました。

2つ目。注意書きと引用と表で、道をふさいだ。

戻ってきた原稿には、こう入っていました。

	戻ってきた原稿	書き直した原稿
文字数	約5,400字	約4,300字
注意書き（⚠️）	6箇所	0
引用ブロック	4つ	0
表	3つ	1つ

段落を1つ読むごとに、注意書きが出てくる。引用が挟まる。表が現れる。1つずつは正しいのに、全部合わさると前に進まない。

3つ目。「レビューを通ること」が目的になっていた。

うちでは、書いた原稿をCodexというAIがレビューします。事実の間違いや危ない断定を見つける役です。Claude Code側は、そこで指摘されないように書いていました。突っ込まれそうなところに先回りで注意書きを付け、断定しそうなところに条件を足す。

読者にではなく、審査に向けて書いていたわけです。 これをやると、通りやすいけれど読みたくならない文章ができあがります。

差し戻して、残したものと外したもの

「長くなって、面白くなくなった」と伝えて、書き直してもらいました。

ここで面白かったのは、削ったものが「論点」ではなかったことです。

最初、Claude Codeは「Sparkの原稿には根拠のない主張が5つあるので削ります」という整理をしてきました。ここに引っかかったんです。根拠がないなら、調べればいいだけじゃないかと。

たとえばSparkは「家賃を3,000〜5,000円上げられれば、金利の上昇分は吸収できる」と書いていました。根拠なしとして削られかけたんですが、調べたら大阪の単身向け物件の成約家賃の指数が、前年同期比で4.5%上がっていました。相場7万円なら3,150円です。

市場全体の指数なので、自分の部屋を値上げできると保証する数字ではありません。ただ、3,000円前後という規模感を検討する材料にはなりました。

削らずに、出典を足せばよかったんです。

結局こうなりました。

• 論点は1つも削らなかった。 根拠を調べて、残した
• 注意書きは、記事の最後に1箇所へまとめた。 本文の途中で足を止めない
• Sparkにあって初稿で落ちていた「まとめ」を戻した

書き直しても、器は残っていた

ここまでが、当時分かっていたことです。

今回この記事を書くために、2つの原稿を機械にかけて比べてみました。思っていたのと違う結果が出ました。

• 文章は、123の文のうち同じものが14しかない。ほぼ全部書き直されている
• ところが、見出しは9本のうち7本がほとんど同じだった

中身は入れ替わったのに、章立てはClaude Code初稿のままだったんです。

問題は、Sparkの組み立てがClaude Code初稿の時点で消えていたことでした。ところが書き直しでは、そのClaude Code初稿の章立てを7割そのまま使って、中身だけを入れ替えていた。読みやすくはなりましたが、Sparkの構造に戻ったわけではなかったんですね。

今回のように、できあがった原稿へ部分修正を頼むと、その部分は直っても全体の組み直しにはならないことがあります。

じゃあ毎回ゼロからやり直すのか。それも時間がもったいない——と思っていたんですが、ここも間違いでした。

作り直すときに捨てるものは、そんなに多くありません。

• 残すもの：自分の体験と数字、調べた結果、Spark下書きで面白いと感じた組み立て
• 捨てるもの：Claude Code初稿の章立て、Claude Code初稿の文章

時間がかかっていたのは、調べ物と、自分から話を引き出す部分でした。そこは全部残ります。 作り直しても、体感ほど高くつきません。

そこで今後は、長い文章を書かせる前に見出しだけ先に確認することにしました。骨組みの段階で「これは面白くない」と言えば、捨てるのは数行です。5,400字読んでから言うのとは、失うものが違います。

AIを増やす前に、役割を1行で決める

3つ使ってみて分かったのは、同じ仕事を3つにさせても意味がないということでした。

得意なところが、そもそも違います。

	向いていたこと
Gemini Spark	最初の切り口を出す。話の順番と勢いを作る
Claude Code	資料を調べる。計算する。自分の体験を文章にする
Codex	事実を確認する。弱いところを、削らずに育てる
自分	面白いかどうかを決める

正直に書いておくと、Codexも完璧ではありませんでした。 以前は「危なそうだから外そう」と企画を弱める方に寄っていた時期があります。今は「調べて育てる」役に直している最中です。

そして今回いちばん効いたのは、最後の1行でした。

「面白いかどうかを決める」を自分が持っていたから、差し戻せた。もしAIの出したものを「調べて書いたんだから正しいんだろう」と思って出していたら、あの5,400字が公開されていました。事実を調べた跡はある。でも、たぶん誰も最後まで読まなかったと思います。

ちなみに、書き直したあとの記事はこちらです。Sparkの使い方そのものについては、前に一度書いています。

AIを2つ以上使っていて、出てくる文章がなんとなく読みにくいと感じているなら、それぞれに何を頼んでいるか一度書き出してみるといいかもしれません。自分の場合は、役割の境界を決めないまま、それぞれに「良い記事にして」と求めていました。

最後まで読んでいただきありがとうございました😊

—