こんにちはコトリです。作業お疲れ様です^^
「Gemini Gemって使えますか?」と聞かれたら、ボクはこう答えます。「使ったことがある人間が、やめた理由があります。」
2025年の年末、Geminiを使ったAIコンサルシステム「Mr.D」を構築して、多くの方に喜んでいただきました。
つまりGeminiを批判する人間ではなく、Geminiを信じて商品にした人間です。そのボクが2026年の春、Claudeに乗り換えた。なぜか。その話をします。
この記事を読んでほしいのは、Gemini Gem(もしくはMr.D)をアフィリエイトや情報発信で稼いでいる方、また、構築されている方。あるいはすでに使っていて「なんか違う」「いまだにインプットのみ、、」の皆さんです。エビデンスと実体験、両方で正直に話します。
- 2025年末にGeminiを選んだ「当時の合理的な理由」と、それが覆った経緯
- Gemini Gemにファイル機能はある。でも「ある」と「機能している」は別の話
- 500行→120行「無断削除」問題の実態
- 同じGemでも人によって動作が異なるメカニズム(3つの理由)
- Claude ProjectとGemini Gemの「設計レベル」での構造的な差
◆ここに広告貼り付け①◆
Contents
正直に言います。ボクはGeminiで商品を作って売った人間です
- Mr.D誕生の経緯と、Geminiを選んだ当時の合理的な理由
- 販売終了に至った本当の経緯
2025年末、GeminiはClaudeより「土台として優秀」だった
2025年初頭から年末にかけて、複雑なOSプロンプトや大量データの読み込みにおいて、GeminiはClaudeやChatGPTより頭一つ抜けていました。これは事実です。
ボクがGeminiを選んだのは「好きだったから」ではなく、「当時最も優秀だったから」です。
当時のClaudeは、長大なOSファイルを安定して処理させることが難しく、プロジェクト機能も今とは比較にならないほど未成熟でした。ナレッジファイルの扱いも限定的で、「システムとして売れる品質」には届いていなかった。
一方Geminiは、長大なOSプロンプトを受け付けるコンテキストウィンドウの許容量が大きく、「データをストックして動かす」という設計思想に向いていた。当時のClaudeにはなかった、その余裕がありました。
ボクのデータをストックでき、2万文字を超えるOSプロンプトを動かすことができたのが、当時はGeminiだったのです。
その判断は間違っていなかったし、Mr.Dが当時機能していたのも事実です。だから今でも「あの判断は正しかった」と思っています。問題は、その後に起きたことです。
行動経済学に「サンクコスト効果」という概念があります。過去に投じたコストへの執着が、合理的な判断を妨げる心理です。ボクがGeminiを辞めた判断は、この逆でした。「構造的に限界が見えたから変える」。これが稼ぎ続ける人間の判断軸です。
もちろん、人間はコンフォートゾーンから離れたくないので、Mr.Dのままでいく選択のほうがラクだったけど、今後のAIの状況を考えた場合、GEMINIやGemを信じ続けるほうがリスクがあると思ったし、Claudeに変えてMr.D以上のシステムを組むほうが絶対に自分の利益になると思ったんです。
500行が120行になった日
予兆はGeminiの突発的な「バカになる現象」としてあったのですが、それは開発の際の話。
販売用のMr.Dを制作していたとき、壁打ちの途中でいろんなことが起こりました。
チャット履歴が消える、勝手に「消してはダメなところが消えてる」などなど。。
500行あったプロンプト(AIへの指示文)が、いつの間にか120行になっていました。Geminiが自己判断で削除していたんです。さらに確認すると、1,000行規模のプロンプトが一気に400行程度まで圧縮されていた箇所も見つかりました。
AIを信頼していたから「どの段階で削られているのか」がわからない状態でした。これが最大の問題でした。自分でも気づかないうちにシステムが改変されている。
賃貸を借りてリフォームしたら、大家が告知なしに壁を壊した状態です。しかもそれに自分では気づけない。これを「無断工事」と呼ぶのは比喩ではなく、実態を正確に表現しています。
Mr.D自体は悪い商品ではありませんでした。2025年12月の段階では、ベストな選択だったと今でも思っています。
ただ2026年になってからは、アップデートのたびに挙動が変わった。購入者さんからも「見出しが作れなくなった」「長文が途中で切れる」という相談が来るようになった。ボクの環境では問題ないのに、誰かの環境では壊れている。その繰り返しでした。
問題は変化そのものより、その変化が「告知なし」で行われたことです。
2月の終わり頃、世間ではClaudeCodeが騒がれ始めました。コワーク、ClaudeCode、Claudeの違いもよくわからない状態で、大した期待もせずにClaudeを使い始めたんです。
安定感が、凄かった。「これはMr.Dより最高なものを作れる。みんなに喜んでもらえるかもしれない」そう思ってから、約1ヶ月。クロちゃんのベースを作り始めました。
◆ここに広告貼り付け②◆
Gemini Gemの技術的限界:「ファイルがある」と「機能している」は別の話
- Gemini Gemのファイル機能の「実際の動き方」
- Claude Projectのナレッジが「使うほど差が開く」理由
Gemini Gemにもファイル機能はある。でも、落とし穴がある。
正確に言います。Gemini Gemにも、ファイルをアップロードする機能はあります。最大10ファイル、1ファイル100MBまで。
「じゃあ同じじゃないか」と思った方、そこが落とし穴です。
Gemのナレッジファイルは「毎回読まれている」わけではありません。
ファイルの内容はベクトルデータに変換されてインデックスに保存されており、「その質問が、ファイルの内容と意味的に近いとき」だけ呼び出される仕組みです。システムプロンプトに書いた内容は毎ターン必ず読まれますが、ナレッジファイルはクエリとの意味的な一致度が低いと呼び出されません。
具体的にこういうことが起きます。
- 「記事を書いて」と入力する
- AIはその質問に対して意味的な検索をかける
- 「キャラの口調設定」「禁止表現リスト」「共通の敵の設定」。これらがクエリと意味的に一致しないと判断されれば、呼び出されない
- ファイルはそこに「ある」。でも、使われていない
図書館の本棚に例えると、こういうことです。本は確かに棚にある。でも司書(AI)に「記事を書いて」と頼んだとき、司書が「これは記事生成の依頼だから、クセ辞書と禁止リストは関係ない」と判断すれば、その本は一切開かれない。ファイルを「入れた」ことと「使われた」ことは、まったく別の話なんです。
「なんか違う文体で出てくる」「使ってはいけない表現が混じる」。Mr.Dの購入者から来たこういった相談の根本原因は、実はここです。Gemが「ちゃんと動いてない」のではなく、設計上「毎回引っ張ってこられるとは限らない」。
ボクはMr.DのOSを2万文字以上のシステムプロンプトに直書きすることで、この問題を部分的に回避していました。ファイルに頼らず、直接書き込む。でもそれは根本的な解決ではなく、「構造的な欠陥を力技で補っていた」状態です。
Claude Projectのナレッジが「根本から違う」理由
Claude Projectのナレッジはどう動くか。
クセ辞書・禁止リスト・IS(インテリジェンスシート)。これらをプロジェクトにファイルとして入れると、毎チャット・毎出力で「呼ぶ必要なく参照される」設計になっています。
- ファイル数の上限:なし
- OS(指示文)の文字数制限:なし
- チャットをまたいでのナレッジ参照:可能
- ナレッジの「呼ばれ忘れ」:構造上起きにくい
クロちゃんは現在、数十個のナレッジファイルを組み合わせて動いています。DRMの型、ペルソナ設定、クセ辞書、禁止リスト、価格設計、事例集。これらが毎回の出力に反映される。
Gemで「10ファイルまで」と言われたとき、何を削りますか?クセ辞書?禁止リスト?ISテンプレート?DRMの型?「入れたファイルが、呼ばれるかどうかわからない」状態で、「毎回均一に稼げる文章が出てくる」と信じることは難しい。
使えば使うほど、クロちゃんはコトリを知っていく。ISが育ち、ペルソナへの解像度が上がり、出力の精度が上がる。これが「使うほど差が開く」という意味です。Geminiのように「毎回検索に頼る」構造では、この蓄積は生まれません。
ちなみに、クロちゃん自身にこのプロジェクトの価値を聞いたことがあります。
DRMの集合知・ペルソナ設計・文体DNA・価格設計・モード自動判定・IS蓄積システム。これらを一人のマーケターに対して専属で構築するとしたら、コンサルフィーと実装コストで100万円を超えてもおかしくない、という回答でした。
それがそんなにしない金額で、この記事を読んでいただいている方へは提供します。しかも使えば使うほど精度が上がっていく。「高い」か「安い」か、もう答えは出ていると思います。
100万円の札束を50万円で買えれば、それはお得です。50万円もしません(笑)例え話です。
◆ここに広告貼り付け③◆
同じGemでも人によって動作が違う理由
- アカウント別に動作が変わる3つのメカニズム
- Claudeのスナップショット管理との対比
「ボクは問題ないけど買った人だけ壊れる」という現象
Mr.Dを販売していた頃、購入者Aさんから相談が来ました。「h2タグ(見出し)が生成されなくなりました」という報告でした。ボクの環境では問題なし。他の購入者さんも問題なし。Aさんのアカウントでだけ起きている。
同じGemを使っているのになぜ?これには3つのメカニズムがあります。
- (1) ユーザーごとの会話履歴・使用パターンへの依存。Geminiは「その人の使い方の文脈」を学習して挙動を変える設計がある
- (2) アカウント別のアップデートロールアウトのタイミングズレ。同じ日に同じGemを開いても、適用されているバージョンが人によって異なる可能性がある
- (3) 出力トークン制御の個人環境による差異。アップデートで出力フォーマットの優先度が変わると、HTMLタグの生成が省略されやすくなる箇所が人によって変わる
つまりGeminiは、同じ設定・同じプロンプトを使っても、アカウントや環境によって出力が変わります。これは教材として販売する際に致命的な問題です。「買ったのに動かない」というサポートが永遠に続きます。
心理学に「可用性ヒューリスティック」という概念があります。自分がよく経験することを「みんなも同じはず」と錯覚する認知バイアスです。「ボクの環境では動く」という事実だけで「みんなも動くはず」と判断してしまう。これがMr.Dサポート問題の根本にありました。
Claudeのスナップショット管理が解決していること
Claudeは「スナップショット日付」という仕組みでモデルを管理しています。Claude公式ドキュメントには、同じモデル名(スナップショット日付)を呼び出せば、どのアカウントでも、どのタイミングで使っても、同じ挙動が保証される設計だと明記されています。
アカウントによって結果が変わることが構造的に起きない。サポートが永遠に続く地獄から、構造で解放されています。
教えるビジネスで「再現性」が担保できない商品は商品ではありません。Geminiという土台を選んだ時点で、ボクはこのリスクを背負っていた。それが乗り換えの本当の理由です。
IKEAの家具を買ったとき、同じ説明書で組み立てれば世界中で同じ棚ができる。教材とはそういうものであるべきです。「買った人によって動いたり動かなかったりする」システムは、教材ではなくギャンブルです。
◆ここに広告貼り付け④◆
では、Gemini Gemを使うべき場面はどこか
- GeminiがClaudeより優れている用途
- アフィリエイターの「本業」にGeminiを使うリスク
GeminiにはGeminiが強い用途がある
正直に言うと、Geminiが優れている用途はあります。
- Google検索がリアルタイムで連携するため、トレンドや最新情報の調査に強い
- YouTube動画・音声ファイルをネイティブで処理できる(Claudeは非対応)
- GmailやGoogle Docsへの統合がネイティブで、G Suite日常使いには摩擦ゼロ
- Gemini Flash APIは最安クラスの価格で、大量自動処理のコストが低い
SNS発信のトレンド調査、YouTube台本のアイデア出し、Googleカレンダーやスプレッドシートとの連携。こういった用途ではGeminiは十分に強いです。
ただし「稼ぐ文章を書く」という本業の部分にGeminiを使うのはリスクが高い。ハルシネーション率の差・長文ドリフト・文体維持の困難さ・ナレッジの不確実な呼び出し。これらが複合的に絡まって、アフィリエイトの収益に直結します。
大工に例えるなら、Geminiはメジャーや電動ドライバーとして優秀です。でも家を建てる「柱」を選ぶなら、強度が保証された素材を使う。稼ぐ文章という柱の部分に、強度が保証されていない素材を使うリスクを軽く見てはいけません。
結論:Geminiは補助、Claudeは本業
ボクが現在やっている使い分けはシンプルです。
Claude(クロちゃん)で記事・メルマガ・セールスコピーを書く。Geminiは画像のみ。ディープリサーチもClaudeが最強。この分業です。
「Claude一本でいいじゃないか」ではなく「それぞれの土俵で使い分ける」のが正解です。ただし稼ぐ文章の本業は、Claudeです。
ゼロを自動化してもゼロです。文章で稼ぐ土台がない人がGeminiのAPI連携を試し続けても、ゼロの量産にしかなりません。まずClaudeで「1円稼ぐ」土台を作って、その後でGeminiを補助に使う。この順番が正しいです。
守破離という言葉があります。まず「守」。型を完全に習得する。その後に「破」「離」がある。Claudeで稼ぐ文章の型を体に入れる前に、ツールの組み合わせや自動化を追いかけても、型のない人間が速く動くだけです。
◆ここに広告貼り付け⑤◆
まとめ:Gemini Gemはアフィリエイターの本業ツールになれない
ボクがMr.Dを終了してクロちゃん(Claude Project)に移行した理由は、Geminiが嫌いになったからではありません。
当時のGeminiは、当時のClaudeより確かに優秀な部分がありました。長大なOSを受け付ける許容量、ファイルアップロードの自由度。2025年末の時点では、あの判断は正解だった。でも、AIの進化は止まらない。Claudeのプロジェクト機能が成熟し、設計の差が「収益の差」として現れるようになった今、土台を変える理由が生まれた。
「ファイルがある」と「ファイルが機能している」は別の話。「動いている」と「再現性がある」も別の話。この2つの差に気づくまでに、ボクはシステムを一つ作って、売って、終了させる経験が必要でした。
皆さんには同じ回り道をしてほしくない。だからこそ、結論を先に言います。稼ぐ文章を書くための土台は、Claudeです。ツール選びは地味に見えて、実は収益の根幹に関わる判断です^^
- 2025年末のGeminiはOS許容量・ファイル自由度でClaudeより優秀だった。あの選択は当時正しかった
- Gemini Gemにもファイル機能はある。ただし「呼ばれるかどうかわからない」RAG構造
- クセ辞書・禁止リスト・IS。稼ぐ文章に必要な設定は「毎回確実に呼ばれる」必要がある
- Claude Projectはファイル数無制限・OS文字数無制限・チャットをまたいだ参照が可能
- 使えば使うほどISが育ち出力精度が上がる。Geminiの構造では生まれない蓄積
- 500行→120行の無断削除問題は「Gemの壊れ」ではなく「Geminiの設計」だった
- 同じGemでも人によって動作が変わるのはアカウント別ロールアウト・履歴依存・トークン制御の3つが原因
- Claudeはスナップショット日付管理で全アカウント同一動作が保証される
- GeminiはSNSトレンド調査・YouTube台本・G Suite連携では強い
- 稼ぐ文章の本業はClaude、リサーチ補助はGeminiの分業が現実解
- ゼロを自動化してもゼロ。Claudeで1円稼ぐ土台を先に作ること
◆◆文末広告◆◆◆