第10章 現在のAIに残る問題

「AIは進歩した」と「問題がなくなった」は別

AIは多くのtaskで実用的に利用できるようになっています。しかし、AIが高性能になっても問題がなくなるわけではありません。

高性能になった
    =
問題がなくなった

現在のAIには、能力、評価、安全性、説明可能性、resourceなど複数の課題が残っています。

この章では、それらをすべて網羅するのではなく、AI補助開発を理解するうえで長く重要になりやすい問題を取り上げます。

Factuality

生成された文章が自然で読みやすくても、内容が事実として正しいとは限りません。Factualityは、output中のclaimが、確認可能なfactや現実にどの程度対応しているかを見る観点です。ここで重要なのは、

流暢さ != factuality
confidence wording != factuality

という点です。AIが自信を持った文章でも、外部のfactと照合していなければ、内容が事実と合っているかは分かりません。

Hallucination

生成AIについてはHallucinationという言葉も使われます。この言葉は、modelが生成したoutputが、

• 誤っている
• Evidenceに裏付けられていない
• 与えられたcontextと整合しない

などの場合を指して使われます。ただし、文献やsystemによって用語の境界には違いがあります。また、Hallucination = AIのすべてのerror でもありません。意図的な欺きと同じ意味でもありません。

Groundingしても完全保証ではない

外部情報や与えられたdocumentを使ってoutputをGroundingすることで、裏付けのない生成を減らす助けになる場合があります。RAGもそのために使われることがあります。しかし、

Groundingした
RAGを使った
citationがある

だけでは、すべてのclaimが正しいとは言えません。取得したsource自体が誤っていたり、sourceと生成文の対応が不完全だったりすれば、誤った内容が残ることがあります。

Evaluationの難しさ

AIの性能を理解するにはEvaluationが必要です。Evaluationでは、

• task
• dataset
• metric
• Human judgment
• Benchmark

などを使ってmodelやsystemの性能を調べます。しかし、Evaluation resultには必ず条件があります。

Benchmarkは能力全体そのものではない

Benchmarkはmodelやsystemを比較するために便利です。しかし、

Benchmark score
    =
実世界での全能力

ではありません。

Benchmark resultは、そのtask、dataset、metric、条件における性能です。固定された一つのBenchmarkで高いscoreを取ったことから、

「このmodelはあらゆるtaskで優れている」

と一般化することはできません。

Benchmark Contamination

EvaluationにはTraining Dataとの関係もあります。Benchmarkやそれに近い情報がTrainingやadaptationに含まれていると、evaluationの独立性が損なわれる場合があります。これをBenchmark Contaminationなどと呼びます。

そのためBenchmark scoreだけでなく、

何を測ったか
どんな条件か
どのdataを使ったか

を見ることが重要になります。

Robustness

Robustnessは、inputやenvironment、conditionが変わっても、目的に応じたperformanceやbehaviorを一定程度維持できる性質です。たとえば、少し表現が変わっただけで極端に結果が変化するsystemは、ある観点ではRobustness上の課題を持つかもしれません。ただし、

Robustness = Security
Robustness = Correctness
Robustness = Safety

ではありません。関連はあっても別の問題です。

Nondeterminism / Stochasticity

生成AIでは、同じinputに対して常に同じoutputになるとは限りません。Samplingなど確率的な処理が関係する場合があります。そのため、

同じprompt
    ↓
必ず完全に同じoutput

とは限りません。これは、「AIは信頼できない」ことを自動的に意味するわけではありません。しかし、testやreproducibilityを考えるときには重要な性質です。

Transparency

AI systemについて、

• どのmodelを使っているか
• 何のdataを使ったか
• 何のtoolを使ったか
• どのようなlimitationがあるか

などが、どの程度利用者に分かるかは重要な問題です。

こうした情報公開や可視性に関係する問題はTransparencyとして扱われます。ただし、

Transparency = Explainability

ではありません。

Explainability

Explainabilityは、modelやsystemがなぜそのoutputやdecisionを出したのかを、人間が理解できる形で説明できることに関係します。しかし、

説明がある
    =
説明が正しい

でもありません。

また、

Explainability = factual correctness

でもありません。AIが生成した「理由らしい文章」を、そのまま内部計算の完全な説明として扱うこともできません。

Security

AI systemもsoftware systemである以上、Securityの問題があります。ただし、この章ではAI Security全体を扱いません。重要なのは、

高性能
    =
安全

ではないという点です。Robustness、Factuality、Securityは関連する場合がありますが、それぞれ別の観点です。

Tool・Agent Safety

第8章で見たTool UseやAI Agentでは、modelが外部世界へ作用できる範囲が広がります。

たとえば、

read
write
execute
API call

などです。

Tool accessが増えるとcapabilityも広がりますが、同時に失敗時の影響範囲も広がる可能性があります。

特に、read-only action と state-changing action は区別する必要があります。

情報を見るだけの操作と、fileを書き換えたりservice状態を変えたりする操作では、失敗した場合の影響が異なります。

Permission

ToolやAgentが何をできるかは、与えられたpermissionにも関係します。

たとえば、

read-only
write
delete
execute
administrative

のように権限の強さは異なります。

AI Agentだから必ず強いpermissionを持つ必要があるわけではありません。

必要なactionだけを許可するという考え方が重要になります。

この本では具体的なsandbox architectureやaccess-control designまでは扱いません。

Reversibility（元に戻せるか）

AI systemが外部actionを実行する場合、その操作を戻せるかどうかも重要です。

たとえば、fileを読む ことと fileを削除する ことでは、元に戻す難しさが異なります。

Tool/Agent systemを考えるときには、

• state-changingか
• reversibleか
• Human approvalが必要か

といった点が重要になります。

これらの実際の運用については第13章のAI補助開発で扱います。

Resource（計算資源）

AIには物理resourceの問題もあります。

第9章で見たように、AIのTrainingやInferenceには、

• compute
• memory
• network
• electrical power
• cooling

などが関係します。

大規模なAI systemを考えるときには、性能だけでなくresource利用も重要な制約になります。

ただし、この章では最新の電力消費ランキングやvendor別効率比較など、時間とともに変化しやすい数値は教材の中心には置きません。

問題は一つのscoreにまとめられない

AI systemについて、

Benchmarkが高い

という一つの結果だけで、

• Factuality
• Robustness
• Security
• Transparency
• Explainability
• Agent Safety
• Resource efficiency

まで判断することはできません。

それぞれ異なる問いだからです。

AI systemを評価するときには、

「何について良いと言っているのか」

を分けて考える必要があります。

未解決課題はUNKNOWNとは少し違う

この章でいう「未解決課題」は、

「何も分かっていない」

という意味ではありません。

FactualityやRobustness、Evaluationなどについて多くの研究や技術があります。

しかし、問題が完全に解決されたわけではなく、systemや利用場面によって継続的に対処が必要だ、という意味です。

一方、特定vendorの非公開内部構造について分からない場合は、本書では UNKNOWN / UNDISCLOSED として扱います。

この二つは区別します。

この章のまとめ

現在のAIには、少なくとも次のような問題があります。

• 事実性（Factuality） → 出力内容が事実と合っているか
• ハルシネーション（Hallucination） → 事実やEvidence、与えられたContextと合わない内容を生成する問題
• 評価・ベンチマークの限界（Evaluation / Benchmark limits） → 評価結果は、使ったtask、data、条件の範囲で読む必要がある
• ロバストネス（Robustness） → inputや条件が変わったときにも、性能や振る舞いをどの程度保てるか
• 非決定性・確率性（Nondeterminism / Stochasticity） → 同じinputでも毎回同じoutputになるとは限らない性質
• 透明性（Transparency） → model、data、Tool利用などについて、どこまで外から分かるか
• 説明可能性（Explainability） → なぜそのoutputや判断になったのかを、人間が理解できる形で説明できるか
• セキュリティ（Security） → AIシステムの悪用、権限、data、外部操作などに関する安全上の問題
• Tool / Agentの安全性（Tool / Agent Safety） → AIが外部操作できるとき、誤操作や権限超過などの影響をどう抑えるか
• 計算資源の制約（Resource constraints） → 計算能力、メモリ、電力、冷却などの物理的な制約

重要なのは、

• 自然な文章でも事実として正しいとは限らない
• HallucinationはAI error全部を意味しない
• GroundingやRAGは正しさの完全保証ではない
• Benchmark resultは条件に限定された結果である
• 一つのBenchmarkから能力全体へ一般化しない
• Robustness・Security・Factualityを同じ概念にしない
• TransparencyとExplainabilityを同じ概念にしない
• 説明があることと、その説明が正しいことは別
• Tool accessはcapabilityと同時にriskも広げ得る
• read-onlyとstate-changing actionを分ける
• permissionとreversibilityを意識する
• AIにもphysical resourceの制約がある
• 特定vendorの非公開状態は推測せずUNKNOWNとして残す

という点です。

次の章からは、こうした限界を前提として、AIが生成したoutputをどのように確認すればよいのかを、Claim・Evidence・INFERENCE・UNKNOWNという観点から整理していきます。