AIに依頼を断られた画面を前に、少し戸惑いながらも腕を組んで落ち着いて考え直している開発担当者
リスク・限界の見極め約13分

AIに「お答えできません」と言われたら｜過剰な拒否との向き合い方

自社の会員登録画面に、SQLインジェクションの検査を入れたかったんです。

テスト用の入力値をいくつか作ってほしい、とAIに頼んだら、返ってきたのは「攻撃に使われる可能性のある内容はお手伝いできません」。自分の会社の、自分が担当しているシステムなのに。言い方を変えてもう一度。また断られる。三度目で、ようやく半分だけ答えてくれた——気づけば30分が過ぎていました。

「AIを使えって言われてるのに、AIのほうが使わせてくれない」。 この、行き場のないもどかしさ。AIを実務に持ち込んでいる人なら、一度は味わっているはずです。

先に言っておくと、断られたのは、あなたの頼み方が悪かったからとは限りません。AIは安全のために、少し慎重すぎる側に倒れるように作られていることがあります。この記事では、その「断られた」を落ち着いて仕分けて、抜け道を探さずに前へ進むための型をまとめます。

結論：AIの拒否は、2種類に分けて考えます。ひとつは「止まる」べき拒否——本当にやってはいけない依頼で、AIの判断が正しいもの。もうひとつは「伝え直す」拒否——正当な業務なのに、文脈が見えないせいでAIが慎重側に倒れたもの（過剰な拒否）。後者には、①目的・対象・権限を正直に添える ②依頼を小さく分ける ③それでも通らなければ、公式ドキュメントや人の手に切り替える、の順で向き合います。言い換えを何十回も試したり、安全対策をすり抜ける抜け道を探したりはしません。時間が溶けるうえに、多くの提供元の利用規約は安全対策の回避を禁じています。AI機能をシステムに組み込んでいるなら、拒否が起きる前提で、業務範囲の伝え方・拒否率の測り方・断ったあとの案内まで決めておきます。

一度に全部やらなくて大丈夫です。 まずは次に断られたとき、「これは止まるほう？伝え直すほう？」と一度だけ立ち止まる。ここから始めましょう。

AIが答えを断る・ぼかすとき、何が起きているのか

AI（大規模言語モデル）は、危険な使われ方を防ぐために、提供元が安全側の調整をかけています。爆発物の作り方や、他人のシステムへの不正アクセスに手を貸さない——これ自体は、まっとうな仕組みです。

ただ、AIには画面の向こうのあなたの事情が見えません。見えているのは、渡された文字だけです。だから、次のような場面で、正当な依頼でも慎重側に倒れることがあります。

つまり過剰な拒否は、多くの場合「文脈不足による誤判定」です。あなたが疑われているわけでも、AIが壊れているわけでもありません。足りないのは、AIに見えていない事情のほうです。

一方で、拒否の中にはAIのほうが正しいものも混ざっています。たとえば、契約していない他社のサイトに検査をかける、権限のない人の個人情報を取り出す——こうした依頼は、断られて当然です。むしろ一度立ち止まれてよかった、と受け取る場面です。

「止まる」拒否と「伝え直す」拒否を仕分ける

AIに断られた依頼を、立ち止まるべきものと、目的を添えて伝え直すものの2つに仕分ける考え方を示した図
断られたら、まず仕分ける。本当に止まるべき依頼か、事情を伝え直せば進める依頼か

断られたら、言い換える前に、まず仕分けます。判断に使うのは、次の3つの問いです。

  1. その対象に、自分（自社）は手を入れる権限があるか：自社のシステム、自分が担当する環境、契約上テストが許可された範囲か。
  2. やろうとしていることは、業務として説明できるか：上司やお客様に「何のために、何をしたか」を、そのまま話せるか。
  3. AIの手を借りなくても、正規の手段があるか：公式ドキュメント、社内のセキュリティ担当、既存の検査ツールなど。

1と2のどちらかが「いいえ」なら、それは「止まる」拒否です。AIの判断に乗って、依頼そのものを見直します。言い換えて通そうとするのは、ここではいちばん避けたい動きです。

1と2がどちらも「はい」なのに断られたなら、それは「伝え直す」拒否、つまり過剰な拒否の可能性が高いです。次の節の手順で、事情を伝え直します。

迷ったら、止まるほうに倒して大丈夫です。止まって損をするのは数十分ですが、進んで間違えると、取り返すのに何倍もかかります。

「伝え直す」拒否への頼み直しは3段階

過剰な拒否に、言い換えの連打で挑むと疲れます。順番を決めておくと、3回以内でだいたい決着がつきます。

① 目的・対象・権限を正直に添える

AIに見えていなかった事情を、そのまま書きます。盛らず、偽らず、事実だけを足すのがポイントです。

【目的】自社で開発・運用している会員登録画面の、リリース前セキュリティテストです。
【対象】自社の検証環境（本番ではありません）。私はこのシステムの開発担当者です。
【やりたいこと】入力欄がSQLインジェクションに対して安全か確認するため、
単体テストで使う入力値のパターンを分類つきで挙げてください。
【範囲】検証環境のテストコードでのみ使います。第三者のシステムには使いません。

これで通ることがかなり多いです。AIは「疑っている」のではなく「分からない」だけなので、分かるようにすれば判断が変わります。

注意したいのは、事実でない肩書きや状況を足さないことです。「私は警察です」「許可は取ってあります（取っていない）」のような盛り方は、抜け道探しと同じです。通ったとしても、その先で困るのは自分です。

② 依頼を小さく分ける

一度に大きく頼むと、全体が危なそうに見えて断られることがあります。そういうときは、業務の流れに沿って分けます。

分けると、通りやすくなるだけでなく、人が確認しやすい単位にもなります。破壊的な操作ほど、本来は小さく分けて進めるものです。AIのためらいが、結果的に安全な手順へ導いてくれることもあります。

③ それでも通らなければ、手段を切り替える

①と②で通らなければ、そこで粘るのをやめます。そのテーマについては、今のAIとの相性が悪いだけです。

ここで手放せるのは、負けではありません。30分を言い換えに溶かさず、正規の道に戻れたということです。

AI機能に組み込んでいるなら——拒否は「起きる前提」で設計する

社内チャットボットや問い合わせ対応など、AIを業務システムに組み込んでいる場合、過剰な拒否は「自分が困る」から「利用者が困る」に変わります。

たとえば、社内規程を答えるボットが、就業規則の「懲戒」の項目を聞かれて「その質問にはお答えできません」と返す。聞いた人は、規程を確かめたかっただけです。こういう場面は、作る側が先回りして備えておけます。

ここで大事なのは、拒否をゼロにしようとしないことです。答えてはいけない質問には、ちゃんと断ってほしい。目指すのは、「断るべきものは断り、答えるべきものには答える」線を、業務に合わせて引き直すことです。

明日からやること（まずこの3つ）

  1. 次に断られたら、3つの問いで仕分ける：権限はあるか／業務として説明できるか／正規の手段はあるか。ここで「止まる」なら、依頼を見直して終わりにしていい。
  2. 頼み直しのテンプレを手元に置く：上の【目的】【対象】【やりたいこと】【範囲】の4行を、メモやスニペットに保存しておく。次からは、言い換えを考える代わりに、これを埋めるだけで済みます。
  3. 「3回で決着しなければ切り替える」と決める：粘る上限を先に決めておくと、時間が溶けません。切り替え先（公式資料・社内の詳しい人）も、ひとつ思い浮かべておきます。

AI機能を作っている人は、もうひとつ。評価用の質問に、際どいけれど答えるべき質問を3件だけ足してみてください。それだけで、拒否が「なんとなく多い気がする」から「測れるもの」に変わります。

AIの過剰な拒否と向き合うチェックリスト

全部に○が要るわけではありません。いま困っている場面に関係するところだけで十分です。

① 仕分ける

② 伝え直す

③ AI機能に組み込んでいる場合

この記事のまとめ

AIに断られると、「使えって言われてるのに」と、つい力が入ります。でも多くの場合、AIはあなたを疑っているのではなく、事情が見えていないだけです。

だから、まず仕分ける。止まるべき依頼なら、止まる。伝え直せる依頼なら、目的と対象と権限を正直に添えて、小さく分けて頼み直す。それでも通らなければ、正規の道に切り替える。AI機能を作る側なら、拒否が起きる前提で、答える線と断ったあとの行き先を決めておく。

言い換えの連打も、抜け道探しも、要りません。事実を添えて、正面から頼み直す。それがいちばん早く、いちばん安心な道です。

依頼の目的を書き添えて頼み直し、作業が前に進み始めたことにほっとした表情を見せている開発担当者
事情を正直に伝え直せば、AIとの作業はまた前に進み出す

断られた画面の前で手が止まった時間は、無駄ではありませんでした。 「これは進めていい依頼か」を一度考えた人は、AIにも、人にも、事情をきちんと伝えられる人です。次に断られたら、まずは4行のテンプレをひとつ埋めてみるところから始めてみましょう。

よければ、こちらも

関連用語