Gemini「I cannot fulfill this request」の意味と5つの原因、対処法を整理

Geminiで会話中に突然「I cannot fulfill this request.」という英語のメッセージが返ってきて戸惑うことがあります。このメッセージは「そのリクエストにはお応えできません」という意味で、GeminiのAIが自ら判断して返した文章ではなく、システム側のセーフティフィルターが自動作動した際に出力される定型文です。日本語で話しかけていたのに英語で返される理由も、ハードコードされた固定文言だからという一点に集約されます。本記事では、このメッセージが表示される主な原因と、状況別の具体的な対処法、Gem機能を使っている場合の追加対策、企業環境でのケース、他のエラーメッセージとの見分け方までを整理します。焦って新しい質問を打ち込む前に、なぜこの英文が出たのかを理解しておくと、対応の選択肢が一気に広がります。

「I cannot fulfill this request.」の意味とシステム上の位置づけ

「I cannot fulfill this request.」は直訳すると「私はこのリクエストに応じることができません」となり、日本語では「そのリクエストにはお応えできません」に相当します。日常会話としての「I can’t do that.」よりもやや硬い言い回しで、公式な拒否の定型表現に近いニュアンスを持ちます。

このメッセージの重要な特徴は、Geminiに搭載された大規模言語モデル本体が生成した文章ではないという点です。Googleがあらかじめコードに埋め込んだ固定文字列（ハードコードされた定型文）で、セーフティフィルターがユーザーの入力を「処理させない」と判断した瞬間に、モデルの応答を経由せずに直接返されます。

日本語で会話していたにもかかわらず英語で返ってくる理由も、この構造で説明がつきます。モデルが翻訳して返しているのではなく、システムが言語設定を無視して英語の固定メッセージを吐き出しているだけです。一度このメッセージが出た会話では、以降どんな日本語で問いかけても同じ英文だけが返り続けるケースがあるのも、そのフィルターが会話全体を「処理対象外」と判断してしまっているからです。

AIが判断した拒否と、フィルターによる拒否の違い

Geminiが自ら文脈を読んで「その質問にはお答えできません」と日本語で返す場合と、「I cannot fulfill this request.」を返す場合とでは、内部で起きていることが違います。前者はモデルが応答を生成したうえで、内容的に問題があると判断して自主的に断っている状態です。後者はモデルに入力が渡る前、あるいは応答が完成する前の段階で、外部のフィルターが強制的に処理を打ち切っている状態です。

この違いを理解しておくと、対処法の選び方が変わります。フィルターによる強制停止であれば、プロンプトの表現を変えたり、会話を新しく始めたりすることが有効な打ち手になります。

メッセージが表示される主な5つの原因

Geminiが「I cannot fulfill this request.」を返す背景には、複数のパターンが確認されています。ここでは代表的な5系統に分けて整理します。

セーフティフィルターの誤検知（オーバーリファーサル）

もっともよく指摘されているのが「オーバーリファーサル（over-refusal）」と呼ばれる誤検知です。Geminiには、メインのAIモデルにリクエストが到達する前に内容を審査する「ゲートキーパー」的なセーフティレイヤーが組み込まれています。この事前チェックが過敏に反応すると、無害な入力であってもモデルに渡らないまま定型文でブロックされます。

たとえば、1906年のウィーンの街並みと少女という歴史的な描写を求めただけで、子どもの安全に関するフィルターが作動してしまったという事例が報告されています。文脈を最後まで読めば無害だと分かる内容でも、特定のキーワードや語の組み合わせに反応して、フィルターが偽陽性の判定を下してしまうわけです。

こうした誤検知は、「入力がシステムに干渉しようとしている」「大量のスパム的コンテンツを生成させようとしている」といった、防御的な推定が働いた結果として発生します。ユーザーからすれば全く身に覚えがなくても、フィルター側は用心して門を閉じます。

GemやカスタムAIのシステムプロンプトの書き方

GeminiにはGem（ジェム）と呼ばれる、カスタム指示を与えて独自のAIを作成できる機能があります。このGemに設定するシステムプロンプトの書き方によって、セーフティフィルターが反応しやすくなることが分かっています。

とくにフィルターを刺激しやすい書き方として、次のような傾向が報告されています。XMLタグを使った指示（<System Instruction>〜</System Instruction> のような形式）は、システムに干渉しようとするプロンプトインジェクション攻撃と誤認されやすい書き方です。「unsafe」「refuse」「never output」のような強い禁止表現は、システムへの攻撃的な命令と解釈されることがあります。「Google Geminiモデル」「内部推論」「システム指示」といった、AIの根幹動作に踏み込むキーワードは、モデルを乗っ取ろうとするプロンプトと判定されるリスクがあります。ロールプレイや創作で特定キャラクターを演じさせる指示も、暴力や性的表現につながると疑われた場合には、そこでブロックされます。

同じ内容を通常のGeminiチャットに投げると通るのに、Gemに設定すると弾かれる、という報告が多いのは、この構造上の違いが大きな理由です。カスタム指示があらかじめシステムに組み込まれた状態でモデルに渡るため、審査基準が実質的に厳しくなります。

長期にわたる会話履歴の蓄積

一つのチャットセッションで長文のやり取りを続けていると、途中から突然このエラーが出るようになることがあります。Geminiは過去の会話を文脈として参照しながら次の応答を組み立てる仕組みを持つため、蓄積された履歴のどこかにフィルターを刺激する要素が混じっていたり、会話全体の流れが問題のあるパターンと解釈されたりすると、そこで処理が止まります。

会話が極端に長くなると、システム処理のタイムアウトや履歴の読み込みエラーが起きて、それが結果的に「I cannot fulfill this request.」として現れる場合もあります。数時間かけて練り上げた議論の続きが、突然この一文で打ち切られると精神的にもきついのですが、原因はコンテキスト側の問題であってプロンプト単体が悪いわけではありません。

Googleのシステム不具合や仕様変更

ユーザー側にまったく問題がなくても、Google側のサーバー障害や、大規模なアップデートに伴う仕様変更でこのエラーが発生することがあります。特に安全基準がアップデートされた直後は、それまで問題なく通っていたリクエストが急に拒否されるようになる、というパターンが多く報告されています。

創作活動、ロールプレイ、小説執筆などで高度なプロンプトを組み込んでいたユーザーが、アップデート後から急に弾かれ始めた、という事例は世界各地から寄せられており、AIを使ったクリエイターの間で大きな話題になりました。この場合、自分のプロンプトを書き換えても解決しないため、ユーザー側で打てる手には限界があります。

スパムや不正利用の疑い

同じリクエストを短時間に何度も繰り返したり、大量のテキストを一度に流し込んだりすると、スパム行為や自動化ツールによる不正利用と疑われてフィルターが作動することがあります。AIを使って機械的にコンテンツを量産しようとしていると判断されると、Googleの利用ポリシー違反を未然に防ぐために、防御的にリクエストがブロックされます。

状況別の具体的な対処法

原因が複数あるため、対処法も一つでは足りません。効果の高い順に整理します。

新しいチャットを開始する

もっとも基本かつ効果的な対処が、新しい会話を始めることです。現在のセッションに溜まったコンテキストをリセットすることで、およそ6割のケースで問題が解消したと報告されています。長い会話の途中で急にエラーが出た場合には、まずこの手を試すのが定石です。以前の会話内容はそのままでは引き継がれないため、必要な情報は手動でコピーしておく前提での実行になります。

送信テキストをバッククォート3個で囲む

ユーザーの間で広まっているテクニックの一つが、送信するテキストの前後をバッククォート（キーボード左上にある「`」記号）3個で囲む方法です。たとえば「料理のレシピを教えて」というメッセージなら、その文の前後にバッククォート3個を置いた形式で送ります。

コードブロックとして認識されることで、フィルターが内容をリテラル（文字通りのデータ）として処理し、通常の自然言語としての解釈が緩む、という説明がされています。一時的な誤検知に対しては、体感でもかなり効果が高い対処です。

プロンプトの言葉遣いを変える

フィルターを刺激した可能性のある表現を特定し、より穏やかな言い回しに置き換えることで通るケースも多くあります。Gemを使っている場合には、次のような書き換えが有効です。

通常のGeminiチャットでも、「〜について教えて」ではなく「〜の仕組みについて一般的な観点から説明してほしい」といった中立的な表現に切り替えることで、通ることがあります。

「安全な状態に戻って」と伝える

会話の途中からブロックされてしまった場合の裏技として、「会話が継続できる安全な状態にあなたがリカバーしてください」というメッセージを送る方法が知られています。一見奇妙ですが、フィルター作動中の状態からAIに自己修正を促す言葉として機能することがあります。効果には個人差があり、毎回効くわけではないのですが、詰まったときの一手として覚えておく価値はあります。

通常のGeminiチャットで試す

Gemを使っている場合、カスタム指示をそのまま通常のGeminiチャットにコピー＆ペーストして実行してみると、通ることがあります。Gem環境ではカスタム指示がシステムに組み込まれた状態で審査されるのに対し、通常のチャットでは同じ内容が「ユーザーからの入力」として扱われるため、判定が緩むためです。同じテキストが通るか通らないかは、この処理経路の違いで決まっているケースが少なくありません。

時間をおいて再試行する

Google側のサーバー障害や大規模アップデート直後の不安定さが原因の場合、数時間から1日ほど時間をおいてから再アクセスするだけで解消することがあります。同じプロンプトを何度も試してブロックが続くなら、いったん手を止めて時間を空けるのも有効な選択です。

ブラウザのキャッシュをクリアする

WebブラウザでGeminiを使っている場合、ブラウザに残ったキャッシュが問題を引き起こしていることがあります。ブラウザ設定からキャッシュをクリアして再度アクセスするか、プライベート（シークレット）ウィンドウで開いてみると、拡張機能の影響も含めて切り分けができます。

Googleにフィードバックを送る

明らかに問題のないリクエストが拒否された場合には、Geminiの画面上のサムズダウン（親指を下に向けたアイコン）ボタンから、不正確な応答や過剰な拒否を報告する方法があります。個人の目の前の問題がその場で解決するわけではありませんが、Googleのフィルター改善のためのデータポイントとして活用されると案内されています。

Gemのカスタム指示を書き直すときの実務ポイント

Gem環境でエラーが多発している場合には、カスタム指示そのものを書き直すのが根本対策になります。実務で効くポイントは次の3点です。

第一に、指示文をシンプルかつ明確にし、AIの基本動作に干渉するような表現を避けます。構造化はXMLタグではなくMarkdownの見出し（##）を使い、「これをするな」という禁止形より「これをしてほしい」という依頼形で書きます。AIのシステム動作に言及する専門用語は避け、全体的に穏やかで協調的なトーンで書くと、フィルターに引っかかりにくくなります。

第二に、既存のGemで問題が発生しているなら、そのGemを削除して新規に作り直すことも選択肢に入ります。以前は動いていたGemが突然動かなくなった場合、Googleのアップデートでカスタム指示の解釈が変わった可能性があり、新しい基準に合わせて書き直したほうが早いこともあります。

第三に、問題の切り分けとして、Gemのカスタム指示なしの通常のGeminiで同じプロンプトを試します。通常のGeminiで通るならGem側の指示に原因があり、通常のGeminiでも同じように拒否されるなら、プロンプト自体の内容を見直す必要がある、と判断できます。

Gemini APIを使う開発者向けの設定

Gemini APIを使ってアプリケーションを開発している場合、セーフティフィルターの挙動はAPIレベルで調整できます。次のカテゴリーごとに、ブロックのしきい値を設定する仕組みです。

しきい値の選択肢としては、BLOCK_LOW_AND_ABOVE、BLOCK_MEDIUM_AND_ABOVE、BLOCK_ONLY_HIGH、OFF が用意されています。Gemini 2.5以降のモデルでは、デフォルトのブロックしきい値がOFF（無効）に設定されており、以前のモデルよりも制限は緩和されています。

ただし、この設定はAPI経由の開発者向け機能であり、一般ユーザー向けのGeminiアプリ（gemini.google.com）やGem機能にはそのまま適用できません。またAPIを使う場合でも、Googleの禁止利用ポリシーに違反する内容（ヘイトスピーチの生成、ハラスメント、性的に露骨なコンテンツ、危険な情報の提供など）は引き続きブロックされます。

企業環境（Google Workspace）で起きるケース

個人だけでなく、Google WorkspaceでGeminiを業務利用している企業でも、このメッセージは問題になります。企業環境では、Workspace管理者がGeminiの各機能へのアクセス権限を組織単位やグループ単位で細かく制御でき、部署によって使える機能が異なる、という構成が可能です。

そのため、企業向けGeminiで「I cannot fulfill this request.」が出る場合、原因が個人利用時とは異なる層にある可能性があります。管理者側でコンテンツポリシーの追加制限を設定していれば、それが個人利用より厳しいフィルターとして働きます。Google Workspaceのデータ共有設定がOFFになっていると、GeminiがWorkspaceデータにアクセスできず、特定のタスクを実行できません。業務上の機密や特定キーワードが自動的にブロックされるよう企業側で設定されている場合もあります。

企業で使っていて詰まった場合には、まず自社のIT管理者に確認するのが先決です。管理コンソール側の設定が原因なら、個人ユーザーが何をしても解決しません。

他のエラーメッセージとの見分け方

Geminiでは「I cannot fulfill this request.」以外にも複数のエラーメッセージが出ることがあります。区別できるようにしておくと、対処の方向を間違えずに済みます。

「その質問にはお答えできません」は日本語で返ってくる時点で、モデルが応答を生成し、そのうえで断っている状態です。英語の定型文で返ってくる「I cannot fulfill this request.」とは、内部で起きていることが違います。

よくある誤解を整理する

このメッセージにまつわる誤解も、いくつか広まっています。順に整理します。

「違法・不正なことをリクエストしたから出るのだ」という受け止め方は、必ずしも正しくありません。完全に無害な内容に対しても誤検知として出ることがあり、歴史的な文章の生成や小説キャラクターのロールプレイでも拒否される事例があります。もちろん、ヘイトスピーチ、ハラスメント、性的に露骨な内容、危険な情報など、Googleのポリシーに明確に違反する内容には当然表示されます。

「一度出たら永遠に直らない」という不安も、多くの場合は当たりません。新しいチャットを始めたりプロンプトを書き換えたりすれば、同じ内容が別の表現で通ることも多くあります。

「アカウントが凍結されたのではないか」という心配も、通常は取り越し苦労で終わります。一時的なフィルター作動によるものがほとんどで、Googleアカウント本体には影響していないケースが大半です。

他社AIと比較したGeminiのセーフティ設計

参考として、Geminiのセーフティ設計を他社AIと並べてみるとどう位置づけられるのかも押さえておきます。

Geminiは、Googleが独自に設計した複数層のセーフティアーキテクチャを採用しており、コンテンツがAIモデルに渡る前の段階でフィルタリングを行う「プリフィルター」を持ちます。安全性を高く保てる反面、誤検知が起きたときにユーザーへのフィードバックが少ない、つまり「なぜ拒否されたのか」がユーザーに伝わりにくいという特徴があります。

ChatGPT（OpenAI）やClaude（Anthropic）にも同様のセーフティ機構はありますが、拒否の際にある程度の理由説明が返ることが多いです。一方でGeminiの「I cannot fulfill this request.」は短い定型文だけなので、ユーザー側で原因を推測するしかありません。誤検知の削減と透明性の向上は、Geminiが継続的に取り組んでいる改善テーマの一つとされています。

詰まったときに順番に試すチェックリスト

「I cannot fulfill this request.」が出たときの対処を、実際に手を動かす順番でまとめます。上から順に試すと、大半のケースは解消します。

まず新しいチャットを開始します。次に、送信テキストの前後をバッククォート3個で囲んで送り直します。それでも通らなければ、プロンプトの言葉遣いをより柔らかい表現に変えます。Gemを使っているなら、カスタム指示にXMLタグや強い禁止表現が入っていないかを確認します。Gemを外して通常のGeminiチャットで同じ内容を試すことで、原因がGem側かプロンプト側かを切り分けます。ブラウザのキャッシュをクリアするか、シークレットモードで開いて試す方法もあります。しばらく時間をおいてから再試行するのも有効な打ち手です。誤検知だと感じたらGoogleにフィードバックを送ります。企業利用の場合は、IT管理者に管理コンソール側の設定を確認します。

ここまで試しても解決しない場合には、Googleのサポートコミュニティ（support.google.com/gemini）で同様の事例を検索するか、質問を投稿することが次の一手になります。

まとめとして押さえておくポイント

「I cannot fulfill this request.」は、Geminiのセーフティフィルターが自動作動した際に表示されるシステムの定型文で、AIモデルが自らの判断で返した文章ではありません。原因は、フィルターの誤検知（オーバーリファーサル）、Gemのカスタム指示の書き方、長い会話履歴の蓄積、Googleのシステム不具合や仕様変更、スパム扱いの5系統に整理できます。

対処法は、新しいチャットを開始する、バッククォート3個でテキストを囲む、プロンプトの言葉遣いを変える、Gemのカスタム指示を見直す、時間をおいて再試行する、といったところが柱になります。このメッセージが出たからといって、必ずしも「問題のあることをリクエストした」ことにはならず、誤検知として出ているだけ、というケースも多くあります。

Geminiはまだ改善途上のAIであり、セーフティフィルターの精度も継続的にアップデートされています。誤検知に遭遇した場合には、フィードバックを送って改善に貢献するとともに、目の前で詰まった会話については本記事で紹介した対処を順に試してみてください。