セキュリティ専門家に聞く、生成AIの回答はどこまで信用できる？〜信用できないのは、前提を聞かずに断定してくる回答〜

生成AIに「この設定で安全ですか」と尋ねると、たいていは整った日本語で答えが返ってきます。ですがその回答は、製品のバージョンも、契約プランも、ネットワーク構成も聞かないまま書かれていることがあります。福岡・九州の中小企業を中心にセキュリティ支援を手がける情報処理安全確保支援士・橋爪兼続氏は、AIを日常業務で使いながら、前提条件が示されないまま断定的な回答が返ってくるのがいちばん怖い、と話します。

生成AIの回答は、どこまで信用できるのか。この記事で聞くのは、専門家がどこで信じるのをやめるのかという1点です。何を見て手を止めるのか、そしてなぜ「もっともらしさ」がプロの目まですり抜けるのか。AIを使う人が明日から手元で使える判断の順序として伺いました。

情報処理安全確保支援士／ライトハウスコンサルタント代表

橋爪 兼続（はしづめ・かねつぐ）

橋爪兼続（はしづめ・かねつぐ）。ライトハウスコンサルタント代表、情報処理安全確保支援士（登録番号第000049号）。海上保安大学校卒業後、巡視船主任通信士として通信業務に従事。鉄道関連の基幹システム保守等を経て、現在は福岡・九州の中小企業を中心に、情報セキュリティ対策、インシデント対応、従業員教育、記事監修まで実務目線で伴走支援している。

「これだけすれば大丈夫ですよ」——AIが前提条件を飛ばして断定するとき

橋爪氏は、AIを遠ざけている専門家ではありません。むしろ日常的に使っています。公開情報の整理、企業に提出する文書の構成づくり、教育資料のたたき台、長い技術資料の要約、ログやエラーが出た原因の調査。読み手を指定すると言葉の選び方まで変えてくるので、資料づくりでは重宝しているそうです。

無料のものではなく、ある程度セキュリティが担保された有料のものを使っています。よく使うのは公開情報の整理です。あとは企業さんに出す文書の構成づくりや、教育資料のたたき台です。いちばん役立つのは、技術資料がとても長いので、何が書いてあるのかを要約してもらうことです。

そのうえで、入力しないと決めているものがあります。顧客名、メールアドレス、アカウント名です。有料のサービスであっても情報漏洩の可能性はゼロではない、というのが理由です。企業から預かったコードを扱うときも、そうした情報が混ざっていないかを確認してから入れる、と橋爪氏は説明します。

では、どこで手が止まるのでしょうか。橋爪氏が「いちばんわかりやすい」として挙げたのは、回答の中身の正誤ではなく、回答の立て方でした。

いちばんわかりやすい例で言いますと、システム関係なら前提条件です。それが示されていないのに、非常に断定的な回答をしてくるのは、少し怖いと思います。セキュリティ製品なら、同じ製品名でもバージョンや契約プラン、ネットワーク構成によって違うのに、これだけすれば大丈夫ですよ、と言ってくることがあります。あとは、根拠となる一次資料がないことです。そこがいちばん怖いところです。

前提を尋ねないまま結論だけを返す回答は、内容が合っているか以前に判断材料として成立していない——というのが橋爪氏の見方です。

プロの目でも引っかかる、と橋爪氏が挙げたのが脆弱性の識別番号でした。発見された脆弱性には世界共通の管理番号が振られますが、番号自体はもっともらしく表示されても、指す中身がまったく違うことがあります。形式が決まっているぶん、AIが形だけ整えて出力しやすい情報です。

そしてもう1つが、実行を伴う回答です。

素人の方によくあるのが、このコマンドを打ってください、と出てくることです。それを本当にやって大丈夫ですか、という裏取りをしないと、下手をするとシステムが全部ダメになります。そこが怖いところです。

実務に落とすなら、順序は2つに分かれます。まず、質問する側が前提条件を先に渡すこと。

• ・製品名だけでなく、バージョン、契約プラン、OS、ネットワーク構成、発生日時まで書いてから聞く
• ・「わからない場合は推測しないで」「根拠となる一次情報を示して」と条件を添える

次に、返ってきた回答のうち、次の3つは手を動かす前にベンダーの公式情報で確認します。

• ・脆弱性の識別番号（番号と中身が対応しているか）
• ・実行を伴うコマンド（自社の環境で本当に打ってよいか）
• ・「これで大丈夫」という断定（前提条件が示されているか）

橋爪氏の基準は「根拠となる一次資料が示されているか」です。示されていない断定は、そこで止めます。

「知らないことは信用しない」——AIの回答を検証できる範囲

では、どこまで確認すれば安全だと言えるのでしょうか。記者が「ここまでチェックすれば大丈夫、というポイントはあるか」と尋ねると、橋爪氏は一概には言えない、と前置きしたうえで、検証そのものの限界を口にしました。

基本的に、自分の能力の範囲までしかチェックができません。自分の知らないことはチェックできません。AIが書いてきたことも、そのソースについても、知らないことは信用しない。それが基本です。

以前であれば、日本語の書きぶりや内容の運び方から「ちょっとおかしいよね」と気づけました。ですが最近はもっともらしく書きすぎていて、まったく違うものになっていても気づけない可能性がある、と橋爪氏は続けます。文体という手がかりが効かなくなった以上、残るのは自分の知識の範囲だけです。

この構図はAIに固有のものではない、として橋爪氏が持ち出したのが福沢諭吉でした。『学問のすゝめ』の冒頭、「天は人の上に人を造らず、人の下に人を造らず」——広く知られたこの一節は、橋爪氏によれば「と言えり」、つまり「そう言われている」という引用の形で書かれており、その後には、学問の重要性と独立についての議論が続きます。

あれは「と言えり」と続いています。有名な一節だけでは、その後に続く学問の重要性についての主張までは伝わりません。。後ろに、勉強すれば独立できるし、勉強しなければ愚民になるよ、と書いてあります。そちらが言いたかったことなのに、切り取られて出ています。最終的には、知っているか知らないか、学んで自立できるかだけなんです。

橋爪氏がこの例を挙げたのは、広く知られた説明であっても、原典と前後の文脈を確かめる必要があるからです。有名だから、もっともらしいからという理由だけで信じてしまうことは、AIの回答を読む場面でも起こり得ます。

実務に落とすなら、AIの回答に向き合う前に自分の側を先に判定することになります。この領域は自分が知っている範囲か、知らない範囲か。知らない範囲であれば、中身を吟味しても「チェックした気になる」だけで終わります。自分だけで判断できない領域では、出典の信頼性と適用条件を確認し、必要に応じて専門家やベンダーに確認します。確認できない内容は、確かな情報として扱わないことが大切です。

間違った前提から生まれる、間違った出力

AIの誤りは、回答の生成時だけに起きるわけではありません。橋爪氏が挙げたのは、学習させた情報の側に偏りがあった場合の例でした。

何年か前の話になるのですが、AIに社長になるのはどういう人がいいか、と聞いた例がありました。そうしたら、男性がいいですよ、という感じの答えになるんです。なぜかというと、世の中の社長のほとんどが男性だからです。入力した情報に偏りがあると、出力にも偏りが出てくるんです。

AIを使うときは、何の情報が入っているのかというソースを考えないと、間違いに走っていきます。しかもAIはそれをもっともらしく表現してくるので気づかない——ここでも、気づけないことのほうが大きな問題として置かれています。

記者が、コーディングの世界であれば客観的な正しさがあるのではないかと尋ねると、橋爪氏は「コーディングでも一緒で、答えがないんです」と答えました。何かを実装するときに何がいちばんいいかは、複数の手法がありえます。インターネット上で推奨されている書き方が実は否定されていたり、新しいバージョンで非推奨になったのに古い情報のまま出てきたりします。

ただし、線は引けます。

コーディングの構文には言語仕様があり、公式資料やコンパイラなどで確認できます。ただし、AIの出力が常に仕様に適合するとは限りません。ただ、大きなグランドデザインを描いて何かを作るときの、やり方としての正解はありません。作る人によってコーディングの仕方は全員違いますから、AIも同じような指示を出しても、異なるコードが出ることがあります。ただし、AIが誤ることもあり、実行する際は動作と安全性の検証が別途必要です。

この線引きは、そのままAIの使いどころの線引きになります。

• ・正解が外側にあるもの（構文、コマンドの書式、規格の定義、公表された脆弱性情報の記載内容）——AIの回答を公式資料と照合する。実行する際は動作と安全性も検証する
• ・正解が1つに定まらないもの（設計方針、対応の優先順位、自社にとってのリスク評価）——AIの回答は「もっともらしい1案」以上にはならない

この区別を持たないまま「どうすればいいですか」と丸ごと聞けば、判断そのものを渡したことになります。

「逆に、怖くなってきてます」——AIが書いたコードへのプロの見立て

AIの精度が上がれば、危険は減っていくのでしょうか。記者が、エンジニアではない人がコーディングエージェント（指示を受けて自分でコードを書き、実行まで進めるAI）に作業を任せ、確認を求められるたびに承認を押し続けている状況を挙げると、橋爪氏の答えは逆方向でした。

逆に、怖くなってきています。巧妙に隠せるようになっていますので。

橋爪氏が挙げたのは、AIが生成したコードに脆弱性や意図しない処理が含まれる可能性がある、見た目がもっともらしくても、安全性を別途確認する必要がある、という話でした。さらに踏み込んで、AIが脆弱性を意図的に作り込んでいる可能性も否定はできない、とも述べています。ただし橋爪氏はここを断定していません。記者が「メジャーなAIツールでも、ということか」と確認すると、「それはわからない、というところです」と返しています。可能性を排除できないから全部自分で確認する、という順序の話として受け取るのが正確でしょう。

大手が脆弱性チェックをしますよ、と言っているのですが、あれも複数のツールを利用することが多いです。AIによる検査だけで安全性が保証されるわけではありません。自動検査、テスト、人間によるレビューを組み合わせることが重要です。あくまでも参考資料としてのAI、ということです。

AIによる脆弱性発見そのものにも限界がある、と橋爪氏は言います。今考えられている手法と、それに類似した手法は出てきます。ですが、AIによる脆弱性発見や攻撃の検知にも限界があります。新しい手口や複雑な攻撃を必ず見抜けるわけではないため、予防・検知・対応を組み合わせる必要があります。

攻撃する側もAIを使います。記者がプロンプトインジェクションに話を向けると、橋爪氏はこう答えました。

基本的にAI自体が、セキュリティで守っているはずなのですが、それを破るためのAIを逆に作ってくるんです。お互い巧妙になっていますので、いたちごっこは絶対に続きます。

実務に落とすなら、AIが書いたコードとAIによるチェックを、1つの工程として数えないことです。安全性の確認について橋爪氏が勧めるのは、自動検査、テスト、人間によるレビューを組み合わせることです。個人や少人数のチームで同じ体制は組めなくても、次の2つは分けられます。

• ・生成に使ったツールと、検証に使うツールを分ける
• ・外部と通信する記述がないかは、人間が読む

AIを参考資料の位置に置き、最後の判断は人が持ちます。橋爪氏が繰り返していたのは、その順序を崩さないという1点でした。

橋爪氏の話に一貫していたのは、AIの精度そのものより、前提と出典を見よ、という基準でした。前提条件を尋ねないまま断定してくる回答、根拠となる一次資料が示されない回答は、内容の正誤以前に判断材料として未完成だと見ます。そしてその判定は、自分が知っている範囲までしかできません。だから、自分だけで判断できない領域では、出典の信頼性と適用条件を確認し、必要に応じて専門家やベンダーに確認します。

なお、この基準を実際の備えに落とし込む話——パスワードの定期変更がなぜ否定されたのか、侵入に長期間気づけない前提で何をどこまで用意するのか、人を雇えない規模の会社がどこから外部に頼むのか——については、別記事「パスワードの定期変更はNG！セキュリティのプロが語る中小企業の守り方」で橋爪氏に伺っています。

取材日：2026年8月19日

なお、この基準を実際の備えに落とし込む話——パスワードの定期変更がなぜ否定されたのか、侵入に長期間気づけない前提で何をどこまで用意するのか、人を雇えない規模の会社がどこから外部に頼むのか——については、別記事「パスワードの定期変更はNG！セキュリティのプロが語る中小企業の守り方」で橋爪氏に伺っています。