ロストイントランスレーション～AIアシストに潜む罠

前回は、CNAPP導入前に揃えるべき条件を、前後編で整理しました。
今回は特に、CNAPP製品の組み込みAIアシストについて説明していきます。

AIアシストに潜む罠

ChatGPTとひねもす語り合う今日この頃、皆様いかがお過ごしでしょうか。

コードは思った通りに動かない。書いた通りに動くというのは、よく知られた教訓です。
それなら生成AIは？思った通りのコードを生成してくれますか？それとも、指示した通りですか？
例えば、「外部と疎通できる仮想マシンを検出させるコード」を依頼したとしましょう。
その「疎通できる」はfromですか？それとも、toですか？

そこで本稿では、CNAPPソリューションに組み込まれた生成AIについてお話ししていきます。より正確に言えば、製品に組み込まれたAIとの対話で生じた「ディスコミュニケーション」についてです。

同じAIや、ソリューションによって個性や母語があります。日本語対応として快適なインターフェースを用意してくれていることも多いけれども、英語中心のデータ・UI文化で育った場合も多い。文脈、つまり暗黙の了解を共有していない可能性があるのです。面白いことに、彼らは非常に優秀で、往々にして空気を読めてしまうからこそ、より危ないと言えます。

個性についても同じです。RHELとUbuntu、SUSEとCentOS、どれもLinuxだし同じだろと言われれば黙り込みますよね？そして、この例えがピンとこないのであれば、きっとLinux文化圏に属していないのだと思います。これもまた、暗黙知の違いです。

問題は、翻訳されているかどうかではなく、どの言語で思考しているかです。わずかなニュアンスの差が、期待とは大きく異なるアウトプットを生み出します。まさに Lost in Translation。ただし、生成AIとの対話では、こうした認識のズレは静かに誤った判断を招きます。

文化圏特有の言い回しは、往々にして無自覚です。例えば、土砂降り。単語だけで推測すれば崖崩れをイメージするのが一般的でしょう。英語の慣用句で土砂降りは、raining cats and dogsと表現しますが、直訳の「天から雨と犬と猫が降る」と聞いて情景が目に浮かびますか？ちょっと頭を捻りたくなりませんか？

さて、話を引き戻します。冒頭のfrom/to問題は典型的です。英文の場合、fromでもtoでもなくbetweenを選ぶのであれば意図があるはずですが、日本語の場合は無意識のうちに、自然とベクトル無しで繋いでしまうことも容易です。

前置きはここまでに、今回は生成AIの利用時に発生した、下記3種のディスコミュニケーションの事例を紹介していきます。

• 生成AIに期待する視点のズレ
• 生成AIに投入する情報のズレ
• 生成AIが代替できる役割のズレ

ディスコミュニケーション事例集、もしくは踏み抜いた地雷について

この事例では、下記3種のディスコミュニケーションについて紹介します。ただ、内容が内容であるためソリューション名は明示できません。（実際の利用者であれば、試してみればすぐわかることでもあります）

1. 生成AIのキャラクターの違いによるディスコミュニケーション
2. 生成AIに求めたことと返されたことの間のディスコミュニケーション
3. 生成AIから返された結果と、現実......それも契約面に関するディスコミュニケーション

事例①：AIアシストの「思考前提」が露わになったケース

さて、まずは単純な例から。肩の力を抜いて読んでください。

昨今のモダンなCNAPPソリューションは、検知ポリシー作成やアラート分析にAIアシストを組み込んでいます。これまで汗をかいていた作業の肩代わり、非常にありがたい話です。ですが、当然ながらAIごとに専門分野は違います。

場面	複数ソリューションの機能比較
目的	古いTLSを許可するAPIゲートウェイ（API GW）を検出するポリシーをAIに生成させる
分岐点	検証用アカウントにAPI GWが存在しなかった

結果

ソリューション①	存在しない資源を対象にしても、検知ロジックを生成できた
ソリューション②	存在しない資源を対象としたロジックは生成できなかった

一見すると①が優秀に見えます。ですが、ここが面白いところです。原因は性能差ではなく、ソリューションの根底を流れる設計思想に差があったのです。

ソリューション①	設定ミス検知を主眼に、ルール（型）を先に作る
ソリューション②	現実の資源と設定を前提に、包括的なリスク（実体）から組み立てる

乱暴に言えば、①は予防寄り、②は診断寄り。どちらが正解という話ではありません。ただ、PoCでここを見落とすと「思っていたAIアシストと違う」が導入後に起きます。

結局、AIはエンジニアです。彼に何をさせたいのかが曖昧だと、PoCの設計に漏れが出ます。「何ができるか」だけでなく、「何ができないか」を確認しておく。これだけで事故は減らせます。

ミクロに落とすなら、テストケースはOK/NGだけでは足りません。Nullと境界まで入れましょう。今回なら、例えばこの4つです。

OK	古いTLS許可のAPI GWが実在し、検知できる/適切なTLS許可のAPI GWは検知されない
NG	古いTLS許可のAPI GWで検知漏れは無いか/適切なTLS許可のAPI GWで過検知は無いか
Null	API GWが存在せず、「何も起きない」を正しく扱えるか
境界	TLS終端が別レイヤ（LB/WAF）で、判断が割れるか

教訓：AIはエンジニア。専門（前提）が要件と合っているか確認しよう。

事例②：AIアシストが「よしなに」要求を解釈したケース

次は、AIアシストが省力化どころか工数を増やした話です。
こちらの方が、ディスコミュニケーションとしては分かりやすいかもしれません。

場面	特定ソリューションのカスタマイズ
目的	社内コンプライアンス基準との差分ポリシーをAIで量産し、省力化する
分岐点	投入する用語・条件・文脈が統一されていなかった

結果

生成されたポリシーの品質が揃わず、有識者による棚卸しと修正が発生しました。

例えば「外部からアクセスできる仮想マシン」。人間同士、責任を負わされるなら外部とはインターネットか非プライベートか、アクセス可能とは経路があるのか全面開放か、ELBやWAFを挟むならどう扱うかなどについて、自発的に確認をとります。しかし当時のAIは、「よしなに」自分で補完し、間違ってはいないが望んでいないポリシーを大量に並べました。

省力化の前提が「有識者レビューは軽微」である以上、これは致命的です。軽微では済まない"揺れ"が、量産されるからです。

ここから得た教訓は古典的ですが有効でした。用語集と入力規約です。自然言語の自由さは一度捨て、5W1Hに加えてベクトル（inbound/outbound）まで固定する。言ってしまえばネーミング規約です。AIに合わせるのではなく、AIが揺れない土台をこちらが用意すべきでしょう。

例えば、プロンプトに渡す条件を先に構造化します。

対象	VM
観点	ネットワークパス
条件	inbound（外→内）
外部定義	0.0.0.0/0 または public internet
NG基準	WAF/ALBを経由しない

さらに、「どういう指示で生成したか」を残す必要もあります。AI由来の成果物は再現性が命綱です。後から効きます。

教訓：AI生成物は"生成手順込みで成果物"。投入パラメータは規約にのっとり、管理されている必要がある。

事例③：AIの断言と、契約が数えていたものが違っていたケース

最後は、ヒヤリハットではなく、少しゾクリときた話です。

場面	テナント払い出し後、実アカウントオンボード前
目的	提案に向け、費用スコープ（課金単位）を確認する
分岐点	製品同梱AIに契約条件の解釈を尋ね、そのまま前提にした

結果

想定と実際でカウント基準がズレ、見積もりに差分が出ました。

ヒヤリハット、ゾクリ感を強めるなら......約70倍です。想定2クレジットに対し、計上は144クレジット。もっと現実的に言えば、100クレジット単位でライセンスが切られる製品なら、費用が1→2ライセンスに跳ね上がる、という話です。（2クレジット=1ライセンス。144クレジット=2ライセンスとなります）

原因は単純でした。
クレジットの消費単位についてAIに確認、「利用している仮想マシン数」という回答を基に試算を実施。

こちらの想定：「稼働している仮想マシン数」（AI回答を元に判断）
実際の課金：「存在している仮想マシン数」

停止中、検証用、テンプレートとして残っていたVMらも、管理対象として数える必要がありました。AIの回答は一般論として外していません。ただ、こちらが暗黙に置いていた「管理対象＝稼働中」という前提が、契約側とは一致していませんでした。

ここが現代的な落とし穴です。生成AIが無い時代なら、ベンダーページや契約条項を精査し、営業にも確認していたでしょう。ところが今回は「製品同梱のAIだから、製品のことは間違えまい」という暗黙の期待で、裏取りの手順が抜けました。

AIはFAQ回答機ではありません。まして、AIの回答で契約と課金が決まるわけでもありません。問題は誤答ではなく、何を正本として確認するかを人間側が定義していなかった点にあります。

教訓：AIは探索・要約の補助。意思決定は、一次情報に必ず当たる。

変わる世界と変わらぬ対話

結局のところ、AIは「よくできた同僚」です。ただし、同じ会社でも、部署が違うため文化や言葉の癖が噛み合わない同僚のようなイメージです。しかも厄介なことに、彼らは往々にして空気が読めてしまう。読めるからこそ、こちらが置いた暗黙の前提を、彼らなりの常識で補完してしまうのです。

今回の3つの事例は、その補完が露わになった話でした。存在しない資源を前提にしたとたんに生成の可否が割れ、「よしなに」を投げたとたんに揺れが量産され、契約という硬い現実の前では、断言の柔らかさがそのまま危うさになります。

そのため、対策も基本に立ち戻ります。

• 言葉を定義し、入力を規約化し、Nullと境界まで試験する。
• 契約や課金は、AIの口ではなく、条項という正本で確かめる。

便利さを手に入れるために、ほんの少しだけ不便を引き受けることが、爆発を小さくする唯一の現実解でしょう。映画『Lost in Translation（直訳：翻訳で抜け落ちたもの）』の封切りは2003年でした。対策は、その時代から変わりません。

ということで。次回は、実際のCNAPPソリューションを、これまでの観点を基に評価、解剖してみます。長々とした理論を、具体に落とせばどう見えるか。きっと、これからCNAPPに一歩踏み出す前の一助になるはずです。