実は明日6月18日、自分がコマンドライン作業で使っていた「Gemini CLI」が終了し、後継の「Antigravity CLI」に一本化される予定だ。後継ツール自体はすでに存在しているのでツール自体がなくなるわけではないのだが、無料枠が圧倒的に少なくなる。
コマンドライン側の選択肢がひとつ減るので、コーディング作業はCodexを有料にして使うか、Claudeの上位プランに課金するかで迷っていたのだが、Claudeの次のプランはちょっと値が張る。というわけで、当面はCodexを有料化する方向に倒れそうだ。一方でGeminiは、CLIではなくWeb版での出番が増えることになる。日報づくりなど普段の事務仕事はもともとGemini Web版にお願いしているので、ここでしっかり働いてもらわないと困る。
ところが最近、そのGemini Web版がやたらと「分かりません」を連発するようになっていた。聞いてもいないのに、こちらが下手なことを言ったわけでもないのに、開口一番「根拠データが提示されておらず、客観的事実を特定できないため」と来る。なんだその裁判官みたいな言い回しは。
🤖 賢くなったはずなのに、急に弱気になったGemini
こちらが「日報を作って」と言っただけなのに、Geminiは「現在のチャットに昨日のファイルや受信履歴が提示されていない」という理由で立ち止まる。いや、立ち止まるなら検索すればいいじゃないか、君にはその機能があるだろう。実際、何度も「いいから探して」とやり直しを指示すると、ちゃんとファイルもメールも読めるのである。つまり権限の問題ではなく、最初の一歩を踏み出す前に「無理です」と諦めるクセがついてしまっていたらしい。
これはおかしいぞ、と思って、Geminiに与えていたカスタム指示を見直すことにした。ただ自分で原因を探すよりも、もう一人の頭脳に分析してもらった方が早い。ということで、いつもコードレビューなどで頼りにしているChatGPT（いわゆる「チャッピー」）に、Geminiの設定を丸ごと読んでもらい、ダメ出ししてもらうことにした。
🔍 Chappyの診断：「がんばって慎重にしすぎた」
Chappyに見せたのは、私が「ハルシネーション（AIのもっともらしい嘘）を防ぎたい」という思いから書き込んだ、わりとガチガチな指示の数々だった。「分かりませんと回答することを禁止する」「Workspaceには常時完全なアクセス権限がある」「検索は最低3回以上実行せよ」など、人間が読めば「ちゃんと調べてから答えろ」という当たり前の意味なのだが、チャッピーに言わせると、AIにとってはこれが裏目に出ているという。
特に「常時完全なアクセス権限を有している」という一文が良くなかったらしい。人間としては「使えるんだから堂々と使え」という気持ちで書いたのだが、AI視点では「アクセスできるはずなのに情報が見当たらない→だったら存在しないのだろう」という、妙な方向の結論にジャンプしてしまうことがあるそうだ。否定形の禁止命令（「〜してはいけません」）も同様に、AIにはあまり効かない命令の書き方なのだという。たしかに人間でも「焦るな」と言われるとよけいに焦る。似たようなものかもしれない。
✍️ 否定をやめて、やることだけを書く
チャッピーの提案は上記の流れを汲んだものだった。「〜するな」を「〜したらこうする」に書き換えること。たとえば「十分な検索をする前に分かりませんと言うな」ではなく、「分からない場合は、まず検索を試し、それでも情報が不足するときは『取得できた情報』と『取得できなかった情報』を整理して報告する」という具体的な行動の指示に変える。つまり、失敗したときにどうすればよいかというフォールバックの指示をしっかりと書くこと。
さらに日報づくりのセクションの一番先頭に、「情報が多少欠けていても、それを理由に作業を止めてはいけない。完璧な情報収集ではなく、手元にある情報で最善の日報を作ることが目標である」という一文を追加した。これがどうも効いたようで、修正後はあからさまに「分かりません」と即答する場面が減った。今のところ、検索してから答える、という当たり前の動きに落ち着いている。
🪞 自分のことは、自分では直せない
ここで一つ告白しておくと、実は最初、Gemini自身に「うまくできなかった原因を調べて、次回からは同じ問題が起きないようにプロンプトを修正して」と指示していた。いわゆるPDCAのCAの部分だ。本人（？）は、しっかり振り返りをして対策をしたつもりだったが、結果は悪くなる一方に思えた。だから、仕方なく、チャッピーに問題点を見てもらったという流れだ。
これは人間でも、よくある話だなと思う。自分の話し方や仕事のクセを、自分一人で客観的に見直すのは難しい。だからこそ上司や同僚、あるいは外部のコンサルタントに見てもらう価値がある。AIも同じ構造の問題を抱えているというのは、ちょっと不思議でもあり、同時に納得もできる発見だった。AIだから万能で自己分析もお手の物、というわけではなく、「自分を直すには第三者の目が必要」というのは、AIにも人間にも共通する原則なのかもしれない。
Geminiがアホになったわけではなく、私が「慎重になれ」と言いすぎていたのかもしれない。それを的確に直してくれたのがチャッピーだったというのが、なんとも言えず面白い。Codexが有料になろうがGemini CLIが乗り換えになろうが、結局は「複数のAIで互いを客観視する」のが一番うまくいくのかもしれない。
最後に補足として、今回の問題の本質でもあると思われるチャッピーの回答を貼っておく。ちょっと長いけど、とても興味深いので是非読んでみてほしい。
チャッピーによる解析と提案：なぜ、Geminiの自己改善はダメだったか？
実は、
Gemini自身に「うまくいったとき何をしたか」を説明させ、それをプロンプト化した
というアプローチには根本的な落とし穴があります。
なぜなら、その説明が必ずしも「実際に成功した理由」ではないからです。
AIは成功理由を正確に説明できないことがある
例えばGemini内部では実際には
1. filemap取得成功
2. メール検索成功
3. ドキュメント取得成功
4. 日報生成だったかもしれません。
しかし後から
なぜ成功した？
と聞くと、
Google Driveを検索し
Gmailを検索し
最低3回再検索し
矛盾なく統合したのような、もっともらしい説明を作ります。
人間も似たことをします。
成功した営業マンに
なぜ契約が取れた？
と聞くと、
誠実に説明したからです
と言うかもしれません。
実際には
タイミングが良かった
だけかもしれません。
このプロンプトにその痕跡がある
私が読んでいて強く感じたのは、
これは
Geminiが成功した手順
ではなく
Geminiが成功した後に考えた理想論
に近いということです。
例えば
最低3回検索
なぜ3回？
根拠がありません。
おそらく成功した時に
検索
↓
再検索
↓
成功だったので、
後から
最低3回検索しろになったのでしょう。
しかしモデル内部には
「3回検索すると成功率が上がる」
という仕組みはありません。
矛盾なく統合
これも同じです。
成功した日報を見ると、
結果的に矛盾がなかった。
だから
矛盾なく統合せよになった。
しかしモデルからすると
矛盾がある
↓
統合できない
↓
停止になります。
実はプロンプトが「事後報告書」になっている
私が見る限り、
この文書は
本来あるべきもの
何を達成すれば良いかではなく
現状
成功したときの観察記録になっています。
この違いは大きいです。
AIに書かせるなら何を記録すべきか
成功したときにGeminiへ聞く質問を変えた方が良いです。
今まではおそらく
なぜ成功した？を聞いていたと思います。
代わりに
今回の日報作成に必要だった入力データは何か今回の失敗要因は何だったか今回の成功に必須だった検索結果は何かを聞く方が良いです。
私ならプロンプトをこう変える
現在は
最低3回検索
矛盾なく統合
思考の連鎖のような「方法論」が多いです。
代わりに
目標：
対象日の業務事実を漏れなく抽出し日報を作成する
優先順位：
1. filemap
2. 関連ドキュメント
3. 関連メール
4. GitHub通知
不足があっても処理を停止しない
取得済み情報だけで暫定版を作成する
不足情報は末尾へ列挙するのような「達成目標」を書きます。
さらに重要な点
今回の症状
何回かやり直すと成功する
は、プロンプト問題だけではなく、
Geminiのツール呼び出しの非決定性
による可能性が高いです。
同じ入力でも、
1回目
検索しない
→失敗2回目
検索する
→成功が実際に起こります。
そのため、
「成功したときの手順」を細かく書くより、
失敗したら次に何をするかを書く方が効果があります。
例えば、
filemapが取得できなかった場合：
Drive検索を実行
Drive検索で見つからない場合：
日付を変えて再検索
メールが取得できない場合：
送信者名で検索
それでも不足する場合：
不足資料を列挙して暫定版を作成のようなフォールバック中心の設計です。
現在のマスタープロンプトは「成功パターンの説明書」になっていますが、実運用では「失敗時のリカバリー手順書」の方がはるかに効果があります。今回のケースはまさにそれで、Geminiが失敗する理由を潰す方向で設計した方が安定すると思います。
コメント