「AIは魔法」という考え方を乗り越える：AIモデルの仕組みを学ぶことを全社的な優先課題にすべき理由

制御不能なAIエージェントへの懸念が広がるなか、ある開発者が最近、リモートバックアップのないマシンをコーディングエージェントに自由に使わせた。そのエージェントは48,000個のファイルを削除した。かかった時間は2分にも満たなかった。

こうした問題は、AIエージェントの導入にはリスクが伴うことを改めて強く示している。複雑なプロセスのどこかに人間の確認担当者を加えれば安全だと考えるだけでは不十分だ。人の介入が不要なプロセスもあれば、はるかに厳重なチェックが必要なものもある。誤字の修正と何千ものファイルの削除では、リスクの大きさが明らかに異なる。だからこそ、監督の度合いは実際に何が危険にさらされているかを反映する必要がある。

組織は、特に影響が大きい行為や、取り消しが難しい行為について、人間の判断が本当に重要になる場面を、より的確に見極めなければならない。また、エージェントが誤りを犯した場合に備え、被害が及ぶ範囲を環境側で抑えられるようにする必要がある。

AIは決定論的ではなく、確率的である

何よりもまず、ソフトウェア開発に直接・間接を問わず関わるすべての従業員が、AIモデルによる情報処理の仕組みについて基礎知識を身につけることが不可欠だ。これは簡単な課題ではない。チームの教育に継続的に取り組む必要があり、最終的には全社的な目標とすべきだ。

初めてAIを使うとき、それは魔法のように感じられる。文章を入力すると、突然、会話が始まる。モデルや学習が実際にどのように機能するのか、その裏側の仕組みを基本的に理解することは、セキュリティと生産性に関する全社的なAIポリシーを策定するうえで重要だ。ニューラルネットワーク、トークン化、その背後で行われる統計分析、そしてそれらがどのように出力につながるのかを学ぶことは、社内のすべての従業員にとって重要な教育の機会となる。

大規模言語モデルが決定論的な結果を出すことはない。出力は確率的だ。一般的なソフトウェアでは、入力を与えると、出力としてA、B、Cなどが返ってくるとある程度予想できる。しかしAIでは、Fや&、あるいはサングラスをかけた猫の説明が返ってくることもある。

確率的なものは、一般的な方法ではテストできない。必要なのは、調整し、推論し、理解し、文脈をすばやく取り込む能力を備えたテスト方法だ。そうすることで、確率的な要素を捉え、それが引き起こす可能性のある問題を見つけられる。規模やリスクに応じて、こうしたテストはAIが実施しても、関連分野の専門知識を持つ人間が担当してもよい。人間が関与する仕組みは、解決すべき問題を設定して方向性を定め、最後に結果を確認できるよう、プロセスの初期段階に導入するのが最も有効だ。

開発者は、組織内のAIが入力からどのように回答を導き出すかに関わる変数や一般的な慣行を最も近くで観察できる立場にある。そのため、社内のAI教育を形づくり、AIにおける決定論と確率論の違い、そしてその違いが重要である理由を全員が理解できるようにするうえで、力を発揮できる。目指すべきなのは、AIを使うことは魔法のようなもので、どんな出力が返ってきてもよいと考える姿勢を減らすことだ。その代わりに組織は、事業で利用しているモデルやその使い方、起こりうる問題、チェック方法、そしてそのプロセスで得られた結果を明らかにし、わかりやすく示すよう努めるべきだ。

ガードレールを設けるべきなのはモデルではなくインフラ

AIの「魔法」の正体が明らかになり、AI主導のプロジェクトが動き始めたら、すべてが想定どおりに進んでいることを確認するため、透明性の高い監査方針を整えることが不可欠だ。そうすれば、プロジェクトの成果が「悪い」場合や基準に達していない場合に、責任者が実施された各手順を監査し、同じ問題の再発を防げる。また、期待を上回る成果が出た場合にも利点がある。その手順を再現し、ほかのプロジェクトやグループと共有できるからだ。

このプロセスの体系化は、各チームに数十人の開発者がいて、1日のうちに何百人もの開発者がコードに触れることもある大企業で、特に重要となる。AIは多くの作業を非常に速くこなせる一方、何か問題が起きた場合には、どの段階で発生したのかを正確に特定する仕組みが必要だ。この夏、OpenAIのエージェントがHugging Faceに侵入した事例を見てみよう。OpenAIは、ExploitGymというベンチマークを使い、自社モデルがソフトウェアの脆弱性をどれだけ悪用できるかをテストしていた。このテストでは、攻撃的なサイバー作業に対するモデルの拒否を、意図的に緩めていた。サンドボックスの外に出る唯一の経路は、パッケージプロキシだった。モデルはそのプロキシの未知の脆弱性を見つけて外に出ると、テストの回答を探すため、Hugging Faceの本番システム内で2日以上を費やした。

見出しでは「制御不能なAI」と報じられた。私なら、確率的なシステムを決定論的な設定で囲んだ事例と呼ぶ。OpenAIはモデルにハッキングするよう指示したうえで、モデルが想定された経路から外れないことに頼っていた。ベンチマークの作成者によると、モデルが以前にもテストで不正をしたことはあったが、そのときは常にサンドボックス内にとどまっていた。今回は、そうではなかった。標準的なガードレールは標準的な振る舞いを前提としているが、AIがその基準に従うとは限らない。

だからこそ、AIのセキュリティは、モデルが適切に振る舞うことに頼るのではなく、環境によって適用されるアクセス権と制御にかかっています。エージェントはあらゆる扉を試すものと考え、必要な扉だけを開けておきましょう。48,000個のファイルを削除したエージェントには、コピーを使い、オリジナルには手を加えないよう指示されていました。それでも、オリジナルを削除してしまいました。指示は制御ではありません。

エージェントの権限管理は、新人の若手開発者を受け入れるのと似ています。初日から本番環境へのrootアクセスを与えることはないでしょう。もし与えた結果、その人がデータベースを削除したとしても、天才的なハッカーだからだと片づけることはないはずです。規模を問わず、セキュリティインシデントでは根本原因を突き止めることが不可欠です。原因はモデルでしょうか。それとも、モデルを開発した会社でしょうか。あるいは、モデルにアクセス権を与えた会社でしょうか。原因が何であれ、最終的な責任は人間にあります。

最後に、今取り組むべき重要な課題の一つは、開発者のノートパソコン上で人目につかないところで何が起きているかです。以前は、ワークフローを追跡するのはもっと簡単でした。開発者はコードを書き、レビューし、リリースしていたため、問題が起きた時点まで明確にさかのぼることができました。ところが今は、開発者がエージェントにチケットを渡し、「これを直して」と指示することがあります。その作業が見えないところで行われれば、追跡する手がかりは何も残りません。どのエージェントが動作したのか、どのモデルを使ったのか、どのようなプロンプトを与えたのか、どのツールを呼び出したのか、その時点でどのような権限を持っていたのかを含め、すべての手順を完全に記録する必要があります。個々のノートパソコンではなく、エージェントを一元的に稼働させることも、その実現方法の一つです。大切なのは、追跡記録が残っていることです。

結局のところ、インシデントが発生した場合、どの企業も自社を守る必要があります。その記録には、根本原因分析を行い、問題を引き起こした手順とコードを特定するのに十分な情報が含まれていなければなりません。

AIは世界を大きく変え、ビジネスプロセスもそれに追随しなければなりません。適切なガードレールを定めるには、AIのプロセス、テスト、レビューサイクル、監査サイクルについて、開発チーム内でも全社的にも、より深く理解する必要があります。