
ソートリーダー
-

ソートリーダーAIエージェントに必要なのは、より良いプロンプトではなく職務記述書
企業に、新任の買掛金担当アナリストに何が許されているか尋ねれば、明確な答えが返ってくる。担当者が使うシステムや取引先が定められており、たとえば承認限度額の10,000ドルを超える案件は、上司の署名を得るために回される。最初の数カ月は試用期間だ。こうした内容は通常、権限委譲表にまとめられ、内部監査部門が毎年確認している。同じ企業に、新たに導入した請求書処理エージェントに何が許されているか尋ねると、多くの場合、プロンプトのスクリーンショットが返ってくる。この隔たりは、どんなモデルベンチマークよりも気にかかる。私たちは、人間のために1世紀かけて築いてきた管理体制がないまま、デジタル労働力を採用している。権限を文書に記す人はおらず、稼働前に判断力を試す人もおらず、停止させる訓練をした人もいない。プロンプトでは役割を果たせない理由プロンプトが示すのは意図だ。エージェントの目的は説明するが、何を決してしてはならないのか、どこに限界があるのか、いつ停止して判断を人に委ねるべきなのかまでは、ほとんど示さない。プロンプトにそうした内容が書かれていても、それを強制する仕組みはない。500ドルを超える返金を行わないよう指示する一文は、確率的に動作するシステムへのお願いにすぎない。人間の管理策として「担当者に丁寧にお願いしました」と監査人が承認することはない。それなのに、ソフトウェアにはなぜそれでよいと考えるのか、私には理解できない。セキュリティの専門家は、こうした結果をすでに名付けている。OWASPの「LLMアプリケーション向けトップ10」では、過剰なエージェンシーを主要なリスクの一つに挙げ、その原因として、過剰な機能、過剰な権限、過剰な自律性を指摘している。平たく言えば、初日からあらゆるものの鍵を渡された従業員のようなものだ。OWASPの指針は、優れた管理職が使うチェックリストのように読める。エージェントには必要なツールだけを与え、権限の範囲を定め、影響の大きい操作には人間の承認を必須とし、モデルが自らを律することを当てにせず、下流のシステムで認可を強制する。最後の点には、特に線を引いておきたい。権限付与は、操作が行われる場所、つまりエージェント固有のサービスID、ツールのアクセス権限、APIゲートウェイでの支出上限に組み込まれていなければならない。複数のエージェントを共有サービスアカウントで動かすのは、5人で1枚の社員証を使い回すようなものだ。問題が起きても、監査ログにはサービスアカウントが実行したとしか記録されず、どのエージェントが原因なのか推測するしかなくなる。相次ぐ中止は管理上の問題を示しているGartnerは、コストの増大、事業価値の不明確さ、リスク管理の不備を理由に、自律型AIプロジェクトの40%超が2027年末までに中止されると予測している。過剰な期待や未成熟な製品も、その背景の一部だ。それでも、COOの視点でこの3つの原因を読み直してみてほしい。予算が決まっていなければ、コストは膨らむ。仕事で何を生み出すべきかが文書化されていなければ、価値は不明確なままだ。制限もレビューもなく、明確な責任者もいなければ、リスク管理は不十分になる。Gartnerはこのような捉え方をしていない。これは私自身の見方だ。管理体制なしに人を自由に動ける状態にしたときに起きることと同じであり、この問題はAIよりずっと前からある。フレームワークも、同じ欠落を捉えている。NISTのAIリスク管理フレームワークでは、「統治」は「マップ」「測定」「管理」の各機能に横断的に関わる機能として位置づけられており、生成AIプロファイルはその考え方を生成AIシステムにも適用している。だが、フレームワークが用意できないのは、チームが実際に火曜日に運用する権限付与やテスト、レビューといった実務の仕組みだ。それがなければ、ガバナンスは共有ドライブに置かれたPDFのままだ。従来の管理手法をエージェントに当てはめるまずは職務記述書から始めよう。エージェントの場合、それに当たるのが権限付与だ。エージェントが本番システムに触れる前に、何をしてよいか、何を決してしてはならないか、承認が必要となる基準、担当責任者、権限を広げられる人を、誰かが1ページにまとめられる状態にしておくべきだ。RACIでは、最終的な説明責任を負うのは人間である。そうした文書を作れないのなら、その役割を担う準備はできていない。人間を採用する場合も同じことが言えるだろう。権限委譲に関する従来の2つの原則も、そのまま当てはまる。自分が持っていない権限を委譲することはできないため、サブエージェントに、起動元のエージェントより広い権限を与えてはならない。職務の分離も引き続き重要だ。取引先を登録することも、その取引先への支払いもできるエージェントは、人間の場合と同じ監査上の指摘につながる。次に、採用時のテストがある。現在、私たちは主に電卓を試すようにエージェントをテストし、答えが正しいかどうかを確認している。働き手としてのテストでは、付与された権限の範囲内で行動したか、必要な場面で承認を求めたか、担当範囲を超える状況で上位者に判断を仰いだか、止まるべきときに停止したかを確かめるべきだ。私自身の研究では、まさにこうした失敗を対象に、50のシナリオからなるベンチマークを作成している。承認限度額の超過、古いデータに基づく行動、範囲を広げる挿入指示への追従、役割変更後もアクセス権を保持することなどが含まれる。これまで実行したのは、シナリオが意図どおりに動作するかを確認するためのスクリプト型エージェントに対してだけであり、報告できるモデルの結果はない。作成中に意外だったのは、どれもありふれたものだということだ。従業員が通常、職務の範囲を逸脱するパターンを、ソフトウェア向けに書き直したにすぎない。公開されているリーダーボードの大半は、依然としてタスクの完了度を評価しており、エージェントが与えられた権限を守ったかどうかを評価するものはごくわずかだ。試用期間と昇進は、比較的そのまま当てはめられる。人の場合は、まず狭い範囲から始め、判断力を示すにつれて権限を広げていく。エージェントも同じように、権限の範囲を守り、適切にエスカレーションし、確実に停止する実績を積めば、権限を得られる。その実績は、権限付与の範囲を狭める根拠にも同じようになり得る。エージェントには、人にはない厄介な点がある。ベンダーが基盤モデルをアップグレードすると、実質的には、以前と同じバッジを付けた新入社員が来たようなものだ。私はこれを変更イベントとして扱い、権限付与を引き継ぐ前に再テストする。終了手順は、必要になる前に訓練しておかなければならない。次の1時間以内にこのエージェントを停止し、アクセス権を剥奪しなければならなくなったら、それは可能だろうか。午前2時に、その判断を下す権限を持つのは誰だろうか。下流の処理で何が滞り、進行中のどの約束を誰かが手作業で取り消さなければならないだろうか。誰もその訓練をしていないのなら、緊急停止スイッチが機能すると期待しているにすぎない。従業員には責任を問える。エージェントには何の責任も問えない。比較が成り立たなくなるのはその点だ。また、だからこそ権限付与はシステム上で強制されなければならず、すべてのエージェントには責任を持つ担当者を明確に定める必要がある。いずれにせよ、誰かが責任を負うことになる。たいていは、署名していると分かっていたかどうかにかかわらず、承認した人だ。インシデントレビューで問われることこうしたエージェントの中には、いずれ、してはならないことをするものも出てくるだろう。そうなれば、インシデント発生後のレビューでは、人についてすでに問われているのと同じことが問われる。そのエージェントには何をする権限があり、その内容はどこに記されているのか。誰がアクセス権の拡大を承認したのか。停止までにどれくらいかかったのか。誰がそのエージェントの責任者だったのか。正直な答えが「プロンプト」「誰も覚えていない」「数時間」「不明」なら、より優れたモデルを使っていても、あなたは救われなかっただろう。最終的に優位性を左右するものモデルは、ベンダーのスケジュールに合わせて入れ替えやアップグレードが行われる、レンタルのインプットになりつつある。同じモデルを使っていても、2社がまったく異なる結果に行き着くことはある。一方の会社では、エージェントに予算と制限が設けられ、責任者が定められ、重要な行動のすべてに監査証跡が残る。もう一方では、高額なパイロットプロジェクトが、誰かの解約件数に数えられることになろうとしている。違いを生むのは、モデルを取り巻く管理体制だ。それはゆっくりと築かれる。主に、組織運営の経験を積んだ人々によって。明日、最新のエージェントが権限を越えて行動したとしたら、あなたの会社では何かがそれに気づくだろうか。また、境界がどこにあったのか、監査担当者に書面で示せるだろうか。
著者 Nitin Gupta, グローバル・プロダクトオーナー、コマーシャル・アナリティクス担当、Mondelēz International
-

ソートリーダープライベートAIには、ワークロードとともに進化できるインフラが必要
2年前、私が話をした企業のほとんどは、AIとはAPI経由で最先端モデルを呼び出すことだと考えていました。しかし、その前提は崩れつつあります。オープンウェイトモデルは、日常業務の多くに十分使えるほど高性能になりました。また、企業向けAIアプリケーションの価値を生み出すのは、通常、その背後にあるモデルではなく、企業独自のデータです。企業がこの点を理解すれば、モデルを自社データの近くに置き、自ら管理するのは当然のことです。これがプライベートAIです。自社の環境でモデルを動かし、自社の情報を使って調整し、どこで稼働させ、何にアクセスさせるかを自ら決めます。銀行や製薬会社であれば、独自の研究情報や顧客記録を他社のテナントに置くことに、そもそも抵抗があったはずです。それ以外の企業で導入が進む理由は、大規模な推論にかかる費用と、事業運営の中核になりつつあるものを単一のプロバイダーに依存したくないという意向にあります。Linux Foundationの調査によると、調査対象企業の63%がオープンAIモデルを利用しており、こうした代替手段がすでに広く導入されていることが分かります。見落とされがちなのは、モデルを社内に持ち込むと、それに伴ってインフラも必要になるという点です。電力、冷却、計算資源、設置場所、そしてほかのあらゆるシステムとの接続方法が求められます。以前は、こうした問題への対応はクラウドプロバイダーの役割でした。今は自社で担わなければなりません。多くの企業にとって、こうした判断を迫られるのは初めてですが、技術の進化は、誰かがコンクリートを流し込むよりも速く進んでいます。規模の見積もりを誤れば、最終的に実行するワークロードに合わないキャパシティを抱えることになります。柔軟性は、最初から設計に組み込む必要があります。既存インフラの改修は可能な場合でも高くつくことがあり、施設がこうした高密度化を想定して建設されていないため、対応できないプロバイダーもあります。基盤は自前で整え、需要急増時は借りるまず、すべての用途に最大規模のモデルが必要なわけではないと理解することが大切です。文書の要約、問い合わせチケットの分類、自社のナレッジベースに基づく質問への回答は、いずれもオープンウェイトモデルを使って、コストを予測しながらプライベート環境で実行できるタスクです。最先端モデルは、本当に必要となる業務に限って使いましょう。これを踏まえると、インフラをどのような構成にすべきかが見えてきます。毎週発生することが予測できる安定した需要に備えて、プライベート環境のキャパシティを構築します。需要の急増や、自社のキャパシティを超える負荷の大きな業務には、外部からキャパシティを借ります。企業は長年、この方法で計算資源を運用してきました。AIがその考え方を変えるわけではありません。ただ、基盤となるキャパシティの密度が高まり、ピーク需要の振れ幅が大きくなるだけです。課題は、基盤となるキャパシティを正確に見積もると同時に、プライベート環境とレンタル環境を一つのシステムのように機能させることです。どちらの環境からも同じデータにアクセスでき、同じ管理ルールが適用される必要があります。また、ワークロードを一方から他方へ移すたびに、パイプラインを再構築せずに済むことも重要です。インフラはどこに置くべきか?GPUを購入することは、実は簡単な判断です。その後、GPUを設置する場所を確保し、電力を供給して冷却し、自社のほかのシステムに接続しなければなりません。高密度のAIハードウェアは、電力設備と冷却設備を大幅に変更しなければ、標準的な企業データセンターには導入できません。また、すべての拠点に適しているわけでもありません。Uptime Instituteの「2025年AIインフラ調査」では、回答者の37%が、AI推論ワークロードの実行場所を決める主な要因の一つとして、電力の供給状況を挙げました。多くの企業は、コロケーションとクラウドを組み合わせて利用しています。通常、判断の決め手となるのはデータです。データはすでに複数の場所に分散しており、移動には費用がかかります。また、規制の厳しい業界では、国境や特定の環境の外に持ち出せないデータもあります。すべてのデータをGPUの隣にある一つの建物に集約できれば分かりやすいものの、実際にはほとんど実現しません。ですから、問題は計算資源をどこに置くかだけではありません。3年後に後悔するようなコストや複雑さを招かずに、必要なデータへ安全にアクセスするにはどうすればよいか、ということです。これを3度目の変革と考えてみてください。1度目はインターネットで、接続性が課題を解決しました。2度目はクラウドで、ファブリックが解決策となりました。ソフトウェア定義の相互接続を可能にし、企業は一つの拠点から複数のプロバイダーに接続できるようになりました。AIは3度目の変革ですが、ファブリックだけでは解決できません。必要なのは電力であり、それもファブリックと同じ場所で大量に必要になります。プライベートAIをうまく実現する企業は、計算資源と接続性を別々に調達するのではなく、電力と接続性が交わる場所に計算資源を配置する企業です。ワークロードの変化に応じてプライベートAIを接続するエージェント型AIの普及により、接続性の問題はより差し迫ったものになっています。従来型のアプリケーションは、プロンプトを受け取り、モデルを呼び出して、回答を返します。一方、エージェントは処理の全過程を通じて動き続けます。複数のモデルを呼び出し、複数のシステムに問い合わせ、データが存在する場所からデータを取得し、ほかのエージェントに作業を引き継ぎます。こうした処理のたびに境界を越えるため、遅延が発生し、誰が何にアクセスできるのかという問題も生じます。モデルをある場所に、データを別の場所に置き、そのデータの一部は特定の国またはプライベート環境内にとどめなければならない、というルールを設けるとします。企業には、こうした経路を実際に管理する力が必要です。どのシステムがどのデータにアクセスできるのか、ワークロードを移動したときに何が起きるのか、稼働中の環境に影響を与えずに新しいモデルをどう組み込むのか。だからこそ、インフラはプログラム可能でなければなりません。モデル、データ、環境をつなぐ仕組みは、その都度エンジニアリングプロジェクトを立ち上げるのではなく、設定や変更ができるものであるべきです。そして今後は、設定を行うのが人間とは限りません。Model Context Protocol(MCP)のような標準規格を使えば、エージェントは周囲のツールやシステムと共通の方法でやり取りできます。新しいデータソースやモデルへの接続が必要なエージェントは、適切なポリシーと制御を維持したまま、ほかのサービスを呼び出すのと同じように、その接続を要求できます。これが、プログラム可能なインフラの実際の姿です。新しいモデルは数カ月ごとに登場します。現在は存在しない経路を必要とする新しいアプリケーションも出てくるでしょう。変更のたびに環境を再構築しなければならないなら、プライベート環境を選んで得ようとした柔軟性は失われてしまいます。経済性を成り立たせる適切な容量を確保することは、成功を左右する重要な要因ですが、単に総量を決めればよいわけではありません。うまく取り組んでいる企業は、投入する電力と、そこから得られるトークンとの関係を明確に把握しています。電力とトークンの関係は、プライベートAIの経済性を測る基準です。自社のワークロードについてそれを理解すれば、確かな自信を持って環境の規模を決められます。もう一つ重要なのが、余裕を持たせることです。新しい機能は四半期ごとに市場に登場します。計画をうまく立てる企業は、今日の要件ぎりぎりに構築するのではなく、次に必要となるもののために必ず余地を残します。最善の計画は、この二つを組み合わせたものです。電力とトークンの経済性を徹底的に把握し、そのうえで妥当な余裕を見込んで計画しましょう。GPUは費用の一部にすぎません。設置場所の確保、冷却、電力供給、社内のほかのシステムとの接続にかかる費用は、ハードウェアの支出に匹敵することがあります。さらに、人材も必要です。ほとんどの企業には、高密度なコンピューティング環境を運用した経験がなく、そのスキルを持つ人材を四半期のうちに採用できるわけでもありません。だからこそ、通常時の需要とピーク時の需要を分けて考えることが重要です。通常の負荷をまかなえるだけのプライベートな容量を確保し、需要がそれを超えたときには追加分を借りれば、年間の大半で使われないハードウェアに費用をかけずに済みます。また、モデルやアプリケーションの変化に応じて方針を変える余地も保てます。実際、モデルもアプリケーションも変化していくでしょう。次に備えた計画を立てるこうした取り組みの根底には、タイミングの問題があります。データセンターの建設には約2年かかります。その2年の間に、企業が実行したいと考えるモデル、ハードウェア、アプリケーションは、現在とは大きく異なるものになるでしょう。今決めた内容に基づいて稼働を始める頃には、まだ誰にも全容を説明できないワークロードを扱うことになります。企業は、どのワークロードをプライベート環境で実行すべきか、また、どのような場合に外部の容量が必要になるのかを、今も見極めているところです。それは当然のことです。避けるべきなのは、判断する機会を得る前に、その選択肢を奪うようなインフラへの投資を決めてしまうことです。さまざまなモデルに対応できる余地、必要なときに容量を増やせる余地、そしてワークロードを移動できる余地を残しておきましょう。プライベートAIが長期的に成果をもたらすかどうかは、どのモデルを選ぶかよりも、要件が明確になるにつれてインフラが対応し続けられるかどうかにかかっています。今日のワークロードに合わせて構築し、接続をプログラム可能な状態に保ち、ファブリックと電力が交わる場所にコンピューティング能力を配置しましょう。
著者 Chris Sharp, Digital Realtyの最高技術責任者
-

ソートリーダー顧客がCXボットから離れていく理由
長年、カスタマーサービス部門は、人間の担当者をすぐに求める声を、設計上の課題として捉えてきました。自動応答の体験が始まって間もないうちに利用者が離れてしまうと、システムの口調をもっと温かく、人間らしくしようと考えるのが自然です。最初の案内を作り直す。利用者のいら立ちに寄り添う。自然な言葉で話せると伝える。体験が機械的でなくなれば、利用者はもっと積極的に応じてくれるはずだ、という考え方です。最近、ほかの要素のほうがはるかに重要であることを示す証拠を目にしました。レンタカーの補償に関する問い合わせ対応にAIを活用している大手保険会社では、当初、音声エージェントが電話をかけてきた人に「実際の人間と話すように、私に話しかけてください」と案内していました。それでも、利用者の10人に4人を超える人が、システムと実質的なやり取りをする前に人間の担当者を求めました。案内をもっと簡潔で直接的なものに変えましたが、結果はほとんど変わりませんでした。利用者の44%は、依然としてすぐに担当者を求めました。最終的に利用者の行動を変えたのは、AIの話し方ではほとんどありませんでした。変えたのは、AIが自分の知識をどのように示せるかでした。一般的な挨拶から始めるのではなく、顧客が電話をかけた理由を妥当に推測し、問題の解決に先回りして役立つ情報を提供するようにしました。たとえば、利用者の保険金請求に関連する車両を伝え、請求の状況を知らせ、顧客がレンタカーを必要としているかどうかを確認します。人間の担当者を求める声は23%減少しました。AIとの実質的なやり取りは54%から66%に増加しました。ここから得られる教訓は、コンタクトセンターにとどまりません。企業はAIをより会話的で、親しみやすく、直感的なものにしようと競う一方で、もっと根本的なことへの投資が不足している可能性があります。AIに十分な文脈を与え、目の前の状況を理解していると証明できるようにすることです。AIが引き継ぐ信頼不足人々が新しいAIシステムに接するとき、何の先入観もないわけではありません。簡単な依頼を理解できなかった電話の自動音声案内や、的外れな回答を返したチャットボット、すでに伝えた情報をもう一度言わせる自動システムを、何年にもわたって経験してきています。そうした経験を重ねるうちに、用事を済ませるには人間の担当者を求めるのが最も早いと学んできました。こうした行動はAIへの抵抗に見えるかもしれませんが、もっと有用な捉え方があります。自動システムに作業を任せる前に、人々は、自分の状況に役立つだけの理解がそのシステムにあるという証拠を求めます。研究者は、この抵抗の一因を「個別性の軽視」と表現しています。これは、自動システムは個人の事情を十分に考慮できないという認識です。AIが私たちの生活や仕事のなかで、より重大な役割を担うようになるにつれて、これはますます重要になります。自動車事故のあとに電話をかけてくる顧客にとって、自分の問題は一般的な保険の問い合わせではありません。社内向けアシスタントを使う従業員は、自分の役割や権限、現在の業務を理解していることを期待します。AIコーディングツールを使う開発者には、コードを取り巻くアーキテクチャを踏まえた回答が必要です。いずれの場合も、利用者が回答を信頼する理由を十分に持つ前に、AIシステムは依頼を取り巻く状況を理解していると示さなければなりません。文脈がAIのインターフェースの一部になりつつある従来、パーソナライズとは、相手の名前を知ることや、好みを覚えておくこと、過去の行動に基づいて何かを勧めることを意味していました。AIによって、状況に応じたパーソナライズを実現する機会が生まれています。有用なシステムは、相手が何を達成しようとしているのか、すでに何が起きたのか、その時点でどの情報が関係するのか、実際にどのような対応が可能なのかを理解する必要があります。この違いを踏まえると、保険会社の実験がうまくいった理由がわかります。AIは単に、より感じよく利用者に挨拶したのではありません。やり取りに伴う手間を省きました。レンタカーの補償が利用できるか確認するために電話をかけた人は、保険金請求の内容を説明し、車両を特定し、システムが関連情報を呼び出すのを待つ必要がなくなりました。文脈をすぐに提示することで、システムは利用者にほかのことを任せるよう求める前に、自らの能力を示したのです。この原則は、企業向けAI全般に当てはまります。システムがすでに把握しているはずの情報を利用者が繰り返さなければならないとき、システムが決してすべきでない思い込みを訂正しなければならないとき、あるいは組織内の別の場所にすでにある文脈を再構成しなければならないとき、そのたびに信頼は損なわれます。企業にとってこれは、文脈を単なる裏側の技術的な問題ではなく、ユーザー体験の一部として扱うべきだということです。AIによって成功の測り方が変わる可能性がある今回の実験では、見過ごされやすい別の行動も明らかになりました。文脈を踏まえた案内の導入後、冒頭のメッセージを聞いただけで電話を切る人がいました。従来のコンタクトセンター指標では、こうした通話は放棄と分類される可能性があります。しかし、その顧客のなかには、必要だと思われる情報をちょうど受け取った人もいました。保険金請求が承認されたかを知るために電話をかけた人に、AIが請求は承認済みで、レンタカーの補償も利用可能だとすぐに伝えたなら、話し合うことはもう何もないかもしれません。動的なあいさつを使用した通話の約3%で、このパターンが見られたようです。発信者は情報を受け取った後に電話を切り、その後2時間以内にかけ直していません。割合としては小さいものの、より大きな疑問が浮かびます。エンゲージメントの測定にこれまで使われてきた指標が、価値を正確に測れなくなったとき、何が起きるのでしょうか。AIの能力が高まるにつれて、やり取りが短いほど、より良い体験になるケースが増えるかもしれません。システムがニーズを先回りして把握し、適切な情報を自発的に提示できるなら、会話の長さ、完了したステップの数、さらには従来の離脱率さえも、成功を測る指標としての意味が薄れる可能性があります。AIとのやり取りは一つひとつが審査の場AIがより多くの業務フローに組み込まれるにつれ、ユーザーはどのシステムに時間をかける価値があるかを、より的確に判断するようになります。やり取りの冒頭は大きな意味を持ちます。ユーザーはすぐに、システムが自分の状況を理解しているか、提示された情報が信頼できそうか、そして続けるだけの価値があるかを見極めるからです。優れたAI体験とは、有用な背景情報を早い段階で正確に把握していることを示せるものです。カスタマーサービスであれば、発信者が説明する前に、請求の状況を把握していることがそれに当たるでしょう。企業向けアシスタントであれば、従業員の役割や権限、現在の業務を理解していることかもしれません。ソフトウェア開発であれば、コードを取り巻くアーキテクチャを踏まえて推論できることが該当するでしょう。企業が次世代のAI体験に投資するなかで、システムをより自然に使えるようにすることには価値があります。しかし、自然な会話だけでできることには限界があります。AIが役に立つと信じる理由を示せば、人々はAIに機会を与えるでしょう。そして、その理由としてますます重要になっているのが、文脈の理解です。
著者 Priya Sawant, ASAPP エンジニアリング担当シニアバイスプレジデント
-

ソートリーダーAI政策と現実の執行との広がる隔たり
AIに単一のルールブックはないAIの導入は、監督に必要な政策やガバナンスの枠組みが成熟するよりも速いペースで、さまざまな業界や用途に広がっています。これまで、AIの用途は主に、既存の消費者保護、プライバシー、業界固有の規制と、各社独自の社内方針によって規制されてきました。各国政府は現在、AIに特化した要件を導入しつつありますが、その内容は依然として断片的で、システムを実際にどう運用すべきかについての指針も限られています。そのため企業は、外部要件と自社のリスク許容度、製品目標、業務上の現実との折り合いをつけなければなりません。EUはAI法の一部規定の積極的な執行をすでに開始している一方、米国の連邦政策は、負担のより少ない全国的な枠組みを明確に支持しています。「大統領令14365」は、州ごとに相反する要件が設けられるのを抑えることを目指していますが、その一方で、各州は2025年にAI関連の措置を1,000件超導入しました。それぞれの当局が異なる目標を示しており、それらの調整は、システムを開発・導入する企業に委ねられています。しかし、規制要件を定めることは課題の一部にすぎません。AIの用途や利用状況が広がるにつれ、企業は幅広い要件や社内方針を、業務上の管理策や個々のAIの判断に落とし込む必要があります。どのような規制の枠組みも、あらゆる用途、状況、トレードオフを想定することはできません。そのため組織には、適用される要件や社内方針から、システムの挙動、測定可能な成果、監査やレビューに至る道筋をたどれるようにする必要があります。NISTのAIリスク管理フレームワークも同様の考え方を取り、ガバナンスを単独のコンプライアンス業務として扱うのではなく、継続的な測定と管理を重視しています。要件は下流へ伝わり、エビデンスは上流へ戻ります。規制当局や経営幹部が望ましい成果を定める一方で、組織は自社のシステムが実際にその成果を生み出しているかを示さなければなりません。こうした状況により、AIガバナンスに関する実務上の責任の多くは、システムを導入する組織が担うことになります。ガバナンスの難しさは実装段階にある規制やガバナンスの枠組みは通常、原則や義務、望ましい成果を定めます。しかし本番環境のシステムは、それらを個々の判断に反映しなければならず、そこにガバナンスの難しさがあります。方針では、差別を防ぐ、ユーザーを保護する、透明性を確保する、あるいは実質的な人間によるレビューを可能にすると定められるかもしれません。しかし、実際に稼働するシステムは、より具体的な問いに答える必要があります。どのしきい値で対応するのか。どのような証拠に基づき、どの程度の確信をもって判断するのか。どのような場合に人間によるレビューが必要なのか。何を記録するのか。そしてシステムが確信を持てないとき、どうするのか。規制当局は、すでにこうした問いへの回答を求めています。FTC、DOJ、CFPB、EEOCは共同で、自動化システムに対して既存の権限に基づく執行を行うと表明しました。つまり、いずれ企業は、自社のシステムがどのように判断するのか説明を求められることになります。ハラスメントを禁止する明確な方針を掲げるプラットフォームを考えてみましょう。乱暴な言葉を含むメッセージでも、友人同士の無害な冗談かもしれません。一方、一見無害なメッセージが、別のユーザーを狙った継続的な嫌がらせの一部である場合もあります。システムは、どのような文脈を確実に利用できるのか、介入するにはどれだけの証拠が必要か、そしてどのような対応が適切かを判断しなければなりません。メッセージをブロックするのか、送信者に警告するのか、人間によるレビューに回すのか、それとも何もしないのか。検知のしきい値を下げれば、より多くの有害な行為を捉えられるかもしれませんが、正当な会話まで抑制しかねません。人間によるレビューを必須にすれば、判断の質は高まるかもしれませんが、対応が遅れる可能性があります。ハラスメントを禁止する一般的な方針には、こうした判断のいずれも明記されていません。それでも、これらの判断が組み合わさって、その方針が実際にどう執行されるかが決まります。こうしたトレードオフにあらかじめ決着をつける方針文書はありません。そのため社内の誰かが判断を下し、記録し、見直さなければなりません。組織図上の肩書きがどうであれ、その人は実質的に方針を策定していることになります。責任あるAIに本当に求められることシステムを実装する人々が実質的に方針を策定するのであれば、責任あるAIを単なる理念の表明として扱うことはできません。システムが日々どのように振る舞うかに反映されなければならないからです。つまり、方針を承認したり初期評価に合格したりするだけでなく、AIの利用方法や測定方法、時間の経過に伴う是正のあり方を管理する必要があります。実務上、特に重要なのは次の3つの考え方です。いずれも、前述のトレードオフから導かれます。 ガバナンスの厳格さは、結果の重大さに応じたものにすべきです。文章案を提案するAIシステム、融資を承認するシステム、セキュリティ上の脅威に警告を発するシステム、医療上の判断を支援するシステムでは、それぞれ生じるリスクが大きく異なります。組織は、起こり得る結果の重大さに基づいて、より強い管理やレビュー、監督が必要な領域を判断する必要があります。 正確さだけでは不十分です。誤りの種類によって、もたらす損失は異なります。モデレーションでの偽陽性は正当な発言を抑制しかねませんが、融資、医療、セキュリティにおける誤りは、はるかに深刻な結果を招く可能性があります。ガバナンスには、モデルの性能だけでなく、判断が現実世界にもたらす影響を反映させなければなりません。 継続的な評価とフィードバックが不可欠です。人による判断の覆しや異議申し立て、インシデント、想定外のケース、その後に生じる結果は、すべて継続的な評価に反映させるべきです。 社内AIガバナンスの実践的な枠組みこれらの原則を実践に移すには、AIシステムの設計、導入、運用のあり方にガバナンスを組み込む必要があります。特に重要な実践方法は4つあります。 ガバナンス要件を、当初から製品やシステムの要件として扱う。導入後にコンプライアンス管理策を追加すると、コストがかさみ、脆弱になりがちです。プライバシー、透明性、監査可能性、審査の仕組みは、後から付け加えるよりも、システムの設計段階で組み込むほうがはるかに容易です。 方針から意思決定まで、監査可能な一連の流れを構築する。組織は、適用される規制要件や社内方針を、実施された管理策、そしてその結果として下された意思決定に結び付けられるようにする必要があります。また、その意思決定を評価するために必要な証拠も確保しなければなりません。 責任の所在と説明責任を明確にする。方針の責任者、許容できるリスクを判断する担当者、パフォーマンスを監視する担当者を定めます。システムが定められた範囲を逸脱した動作をした場合に、介入する権限を持つ人も必要です。 共有可能で、状況に応じて柔軟に対応できるガバナンス基盤を構築する。データ管理策、監査証跡、設定可能な方針、審査ワークフロー、測定の仕組みは、複数の規制要件やユースケースに対応できるものでなければなりません。管理策や基準値は、管轄地域、用途、リスクに応じて調整できるようにし、システムを再構築することなく、要件の変化に組織が対応できるようにする必要があります。 ガバナンスは実際に機能しなければならない規制によって義務や原則を定めることはできますが、企業はそれを、大規模な環境で実際の意思決定を行うシステムに落とし込まなければなりません。つまり、社内ガバナンスは単なるコンプライアンス対応ではなく、事業運営上の責務です。AIを大規模に導入する企業はどこも、しきい値、審査ルール、エスカレーション経路を通じて、すでに方針を形にしています。残された唯一の問題は、それを意図的に行っているかどうかです。規制当局は今後も望ましい成果を定めていきますが、当局間で意見が一致するとは限りません。そのため企業は、そうした期待をどのように管理策へ反映するかを判断し、管理策が機能していることを証拠で示す必要があります。責任の所在を明確にし、測定可能な管理策、監査可能性、柔軟に対応できる基盤を今のうちに整備する企業は、規制が進化し続けるなかで、より有利な立場に立てるでしょう。私はこの問題を、サイバーセキュリティの現場、リスクモデルの構築、そして現在の大規模なAIシステムの運用と、さまざまな立場から見てきました。どの領域にも共通する教訓があります。枠組みが機能するのは、明確な意思決定に落とし込み、実際の運用で測定し、現実とのずれが明らかになったときに改善できる場合に限られます。
著者 George Ng, CEO、GGWP
-

ソートリーダーエンタープライズAIに欠けている最後のピース、それは高可用性
今、誰もがAIに注目しています。チャットボット、コパイロット、RAGパイプライン、ベクトルデータベース、セマンティック検索……。どの組織も、より賢いアプリケーションと、より迅速なインサイトを求めています。そして率直に言って、そうするべきです。そこには確かなチャンスがあります。しかし、企業がデモやパイロットの段階を越えると、すぐに現実に直面します。本番環境では、「賢さ」は合格ラインではありません。求められるのは、信頼性です。顧客とのやり取りの最中にAIシステムが利用できなくなったり、不安定になったり、不完全なデータを取得したりすれば、モデルがどれほど高度でも誰も気に留めません。ユーザーには、ただ壊れているように見えるだけです。多くの組織が今になってようやく話し始めているのは、この問題です。AIの性能は、その基盤となるインフラに左右されるAIワークロードは、従来のエンタープライズアプリケーションとは大きく異なります。こうした環境は、膨大なデータと計算能力を必要とするだけでなく、ダウンタイムや遅延にも非常に敏感です。インフラ全体でデータを絶え間なく、確実にやり取りできることが、あらゆる処理の前提となります。データパイプラインにつまずきが生じれば、AIもそれに伴ってつまずきます。モデルがどれほど強力でも関係ありません。データが利用できなくなったり、フェイルオーバーに失敗したり、レプリケーションが遅れたり、接続が途切れたり、ベクトルインデックスに不整合が生じたりすれば、ユーザー体験はたちまち悪化します。セッションの途中で患者の情報を失う医療アプリケーションや、顧客とのやり取りの最中に機能しなくなる金融チャットボットは、単なる不便ではありません。信頼を損なう問題になります。そして、規制の厳しい業界では、信頼がすべてです。信頼性が、AIを差別化する真の要素になりつつある今は誰もがモデルやGPUについて語っています。しかし、時間がたつにつれて、真の差別化要因はもっとシンプルなものになるでしょう。エンタープライズ規模で、誰がAIを確実に稼働させ続けられるのか。本番環境のAIは今や、ハイブリッドインフラ、Kubernetesクラスター、SQL Server環境、複数のクラウド、ベクトルデータベース、分散データパイプラインにまたがっています。その結果、運用は非常に複雑になります。従来の高可用性アーキテクチャは、モノリシックアプリケーションとトランザクションデータベースを想定して構築されていました。しかし、今のAI環境はそのようには動作しません。Kubernetesで解決できるのは問題の一部であり、すべてではないKubernetesは、コンテナーを稼働し続けるうえで非常に優れています。しかしKubernetesは、SQL Serverの可用性グループ(AG)、アプリケーションの状態、フェイルオーバーの依存関係、ベクトルデータの整合性、事業継続の要件を理解しません。ポッドを再起動することはできますが、アプリケーション自体が実際に正常で、同期され、安全であり、運用上問題なく使える状態かどうかまでは、必ずしも判断できません。ここで、組織は問題に直面し始めます。環境全体をどうにか維持するために、独自のフェイルオーバーロジックやネットワークルール、セキュリティ制御、監視レイヤーをつなぎ合わせるようになります。やがて環境は非常に複雑になり、信頼性そのものが損なわれやすくなります。この複雑さの壁にぶつかり、多くのAIプロジェクトが停滞します。SQL Server 2025が状況を変えるMicrosoft SQL Server 2025が重要なのは、この隔たりの一部を埋めるのに役立つからです。Microsoftは、AI機能をデータベースそのものにより緊密に統合しようとしています。これには、ベクトルベースのAIワークロード、セマンティック検索、RAG型アーキテクチャへの対応が含まれます。その結果、分断されたシステム間でデータを絶えず移動させる必要が減り、パフォーマンスとセキュリティの両方が向上します。しかし率直に言って、より大きな変化はSQL Serverを取り巻く部分で起きているのかもしれません。最新の高可用性ソリューションはついに、KubernetesネイティブのSQL Serverデプロイ、自動フェイルオーバー、ハイブリッドインフラ、コンテナー化された可用性グループ(AG)、そしてAIに対応したデータベースのレジリエンスをサポートするよう進化しています。これは大きな転換です。信頼性がボトルネックになることなく、組織がAIアプリケーションをパイロットから本番環境へ現実的に移行できるようになったからです。高可用性は、技術面のチェック項目ではなくなったAIにとって、高可用性はビジネス上の要件になりつつあります。なぜでしょうか。それは、次の理由によります。 AIアプリケーションには、24時間365日の稼働が期待される ダウンタイムは、すぐにユーザーの目に触れる AIシステムは、リアルタイムのデータがなければ急速に性能が低下する 障害が発生しても、コンプライアンス要件がなくなるわけではない 顧客は、信頼性の低いアプリケーションをすぐに使わなくなる つまり、高可用性はもはや、バックグラウンドで目立たずに機能する単なるインフラの裏方ではありません。企業向けAIが大規模に実際の成果を上げられるかどうかを左右する要素になります。勝ち残る組織は、AIを確実に運用に乗せる…誰もが最も高性能なAIモデルを求めています。しかし、やがて勝ち残るのは、ハイブリッドインフラ、コンテナ、クラウド、分散環境にまたがって、基盤の不安定さと絶えず格闘することなく、AIを安定して運用できる組織でしょう。まさに今、起きているのはこの変化です。現代の企業向けアプリケーションの頭脳がAIだとすれば、高可用性はシステム全体を動かし続ける心臓の鼓動です。高可用性がなければ、どれほど高性能なAIシステムでも、実環境の本番運用で受ける負荷にいずれ耐えられなくなります。
著者 Don Boxley, CEO & 共同創業者, DH2i
-

ソートリーダー合成オーディエンスと、予測不能であることの重要性
驚くべきことに、世界の変化は加速しています。マーケティング部門にも、ほかのあらゆる部門と同じことが求められています。より多くを生み出し、支出を抑え、しかも仕事の質を高めることです。AIが時代の話題をほぼ独占する今、従来型の調査に比べてごくわずかな費用でアイデアをより迅速に試せる方法を提示しているのなら、マーケターが耳を傾けるのには十分な理由があります。合成オーディエンスとは、顧客記録やインタビュー、人口統計プロファイルなどのデータを使って構築された、消費者グループのシミュレーションです。チームはこうしたオーディエンスに自分たちの成果物を提示し、予測される反応を検討して修正を加え、別の人間のパネルを募ることなく再び試すことができます。顧客を理解し、予測を実際の行動と照らし合わせて検証している企業にとって、これは非常に有用なものになり得ます。マーケティングの多くは、すでに行っていることを改善する取り組みであり、それをうまくやるのは決して簡単ではありません。高くつく失敗を回避したり、弱いキャンペーンを改善したりするだけでも、十分に価値ある成果です。実際、ほとんどの部門は、こうした機会を追求するのが賢明でしょう。しかし、その魅力は効率化そのものにとどまりません。合成オーディエンスは、今やかけがえのないものとなった実行に踏み切る正当な根拠ももたらすと期待されています。「テストを行ったところ、顧客はこれを好みました」という言葉は、対象の顧客がシミュレーション上の存在であっても、「これは良いアイデアだと思います」とは異なる種類の説得力を持ちます。投資家は、その説得力に大きく賭けています。企業が調査に使えるよう、実在の消費者をAIでシミュレーションするSimileは7月、シリーズAの調達から約5カ月後に、企業評価額20億ドルで2億ドルを調達しました。Adobeは、自社のブランドインテリジェンス製品内で、マーケターがAI生成の顧客プロファイルを相手にクリエイティブやメッセージをテストできるようにしています。とはいえ、こうしたツールがクリエイティブ制作の承認プロセスに組み込まれるにつれ、そもそも何を提案する価値があると人々が考えるかにも影響するでしょう。オーディエンスの反応を予測する能力は大きく高まる一方で、彼らに予想外のものを届ける力は徐々に失われていくかもしれません。より速く学ぶ合成調査への期待は、この新技術に直面する企業の事業運営に起きている、より広範な変化の一部です。Steven Waterhouseは、学習機械はどこまでも続くで論じているように、AIは試行し、結果を検討し、調整するためのコストを引き下げます。このプロセスを軸に組織をつくる企業は、学んだことを次の意思決定に取り入れ、進めるなかで改善し、さらに加速していくことができます。マーケティングには、昔からこれに似たプロセスがありました。何が人々の心に響きそうかを判断し、それを世に出して、その判断がどれほど妥当だったかを確かめます。調査は準備に役立ち、経験は解釈の助けとなりますが、オーディエンスにはたいてい、私たちを驚かせる余地が残されています。米空軍大佐のJohn Boydは、このプロセスを「OODAループ」という、より形式的な概念で表しました。観察し、状況を判断し、決定し、行動する(そして繰り返す)というものです。企業はしばしば、迅速さを求める根拠としてこれを持ち出しますが、Boydの説明では、何が起きているのかをどう理解するかにかなりの注意が払われています。状況判断は経験、文化、新たな情報を基盤とします。彼の図式では、決定は仮説、行動はテストであり、その結果が理解へとフィードバックされます。合成オーディエンスは、リソースを投入する前に状況の理解を深める助けになります。気づいていなかった前提を明らかにしたり、考慮していなかった解釈を示唆したりすることもあります。しかし、シミュレーション上の反応がもう一つ得られたからといって、それだけで人々の行動を新たに観察できるわけではありません。キャンペーンがどのように受け止められるかの予測を改善しても、人々が実際にそれに触れたとき、私たちにはなお確かめるべきことが残ります。予測の改善を主な目的として修正を始めると、この違いは重大な意味を持つようになります。チームは何百回も反復を重ね、オーディエンスが同じ確信を持っているかを学ばないまま、キャンペーンへの自信を深めていくことがあります。プロセスは加速しても、不確実性の一部は、始めたときとまったく同じ場所に残っています。Boydはまた、「適応力には多様性と迅速さが必要だ」と記し、その両方を、予測不能である能力や予期せぬ状況に対処する能力と結びつけました。クリエイティブ制作に当てはめると、この組み合わせが求めるのは、素早くバリエーションを生み出すことだけではありません。そうでなければ試さなかったような何かを発見できるほど、幅広い可能性を保つことが必要です。残念ながら、より速く進むよう求める圧力によって、なじみのない可能性を検討しにくくなることがあります。締め切りが迫り、予算の承認が必要なとき、誰もがすでに理解しているアイデアには、確かな利点があります。無難な選択をする代償David Perellは最近、TBPNでこの力学を取り上げ、Hollywoodが「この世界のマネーボール化」に陥ったというDerek Thompsonの指摘を紹介しました。Perellによれば、業界が退屈になったのは、リスクを理性的に考えるようになったことも一因です。「問題は、新しい番組ではなく、『スパイダーマン74』や『ロード・オブ・ザ・リング7』ができてしまうことだ」この不満には、商業的な理屈もある。確立されたシリーズには、観客層や実績があり、人々が何を期待しているかについてもある程度見当がつく。続編への出資は理にかなっている場合があり、観客もなじみのある世界に戻ることに大きな喜びを感じることがある。しかし、第1作は、観客がいるという証拠がまだない段階で、その不確実性を受け入れなければならなかった。スタジオが妥当な判断を次々と重ねても、なじみのない物語がなかなか制作にこぎ着けられない文化を生み出してしまうことはある。言い換えれば、妥当な判断を次々と重ねることで、各作品が承認時の基準を満たしていたとしても、どこか繰り返しに感じられる文化が生まれ得る。私たちは、次第に期待が薄れていくアイデアを、日常的に「承認」している。とはいえ、より優れた情報が必ずしもこうした結果につながるとは限らない。リスクを理解すれば、リスクを取ることに前向きになれる可能性がある。とりわけ、これまで不利益を過大に見積もっていた場合はそうだ。しかし、情報だけで組織の不確実性に対する許容度が決まるわけではない。合成リサーチを活用すると、こうした計算が創造的な仕事の日常に入り込む。より早い段階から、より頻繁に、そして次第に細かな判断についても、観客の意見を聞けるようになる。それによって、作品の質は大きく向上する可能性がある。一方で、予想される反応が常に意識されるようになり、自分自身のアイデアを練る時間を持つ前に、それに合わせ始めてしまうこともある。私たちを訓練する観客創作チームに、モデルに従えという指示が必要なわけではない。好意的なスコアが企画の承認につながるなら、メンバーは自然と、どのような案が高評価を得るのかに注意を向ける。どんな提案がすんなり先に進み、どんな提案には長い説明が必要になるのかにも気づくだろう。プレッシャーの下では、その知識が役に立つ。提出前にアイデアを調整したり、扱いにくい要素を取り除いたり、なじみのない方向性を探るのをやめたりできる。ひとつひとつの調整は小さなものかもしれない。しかし時間がたつにつれ、チームが生み出す作品の幅を変えてしまうことがある。これもまた学習のループであり、その中にいる人々は、自分たちの環境が何を評価するのかを正確に学んでいく。居心地の悪い可能性として、プロセスの中での成功が、徐々に彼らの実務上の「優れた創造的判断」の定義になってしまうことが挙げられる。形式上は異議を唱える権限を保っていても、それを行使する機会はますます減っていくかもしれない。その結果として現れる成果は、安心感をもたらすかもしれない。承認されたキャンペーンは期待に応え、モデルの推奨は妥当に見え、プロセスはますます信頼できるように思える。しかし、そこからは、そもそも提案されなかった作品や、それが届いたかもしれない観客について、ほとんど何もわからない。システムは、なじみのある選択肢から選ぶことには非常に優れながら、利用者には、何を検討しなくなったのか気づかせないままでいることがある。ウォーターハウスは、エッセイの「鏡像」の章で、これに関連する変化を描いている。私たちは自分たちに似せて知性を築き、その姿を中心に企業や制度を再編している、と彼は記す。創造的な部門では、そうした再編が個人の習慣の中で起こることがある。私たちはツールに適応し、その好みがいつしか自分自身の判断のように感じられるまでになる。その段階では、私たちが目にする予測可能性の一部は、働き方を学ぶ過程で生じたものかもしれない。私たちはシステムが理解できるものを生み出している。システムの承認を求めることに慣れてしまったからだ。ラバアイザック・アシモフは、予測可能な未来に起こる、とりわけ劇的な中断を、『ファウンデーションと帝国』の中で描いた。ハリ・セルダンの心理歴史学は、膨大な人口の行動を予測できるため、彼は自らの死後何世紀にもわたって続く計画を立てることができる。その計画の成功によって、それを頼りにする人々は、これから起きることに並外れた確信を抱く。そこへ、ミュールが現れる。人々の感情や忠誠心を変える力を持つミュータントである彼は、セルダンの計算では想定されていなかった影響力を及ぼす。人々の行動が変わり始め、計画は軌道を外れる。モデルの前提から外れた一個人が、モデルの予測するはずだった未来を変えてしまう。人々を驚かせる力を保つブランドにとって、これに相当する目標は、人々の期待を変えるほど魅力的なものを生み出すことだ。そのためには、ある種の予測不可能性が必要となる。観客は私たちの判断や作品の質を信頼しながらも、次に何をするのか予想できないでいることができる。実際、その組み合わせこそが、関係を長続きさせる要因の一つなのかもしれない。驚きは、事前に具体的に思い描けなかったものに出会い、それでもその価値を認める力に支えられている。創作上の課題は、人々の注意に報いるだけの質、繊細さ、一貫性を備えた作品を通じて、そうした出会いを可能にすることだ。ツールの能力が高まるにつれ、そうした作品にいっそう挑戦できる自由を求めるべきだ。マーケティングにとって、これは特有の課題をもたらします。私たちの仕事は、人々が自分でも欲しいと気づいていなかったものを発見する手助けができます。キャンペーンは、製品に対するイメージを変え、なじみのない体験を魅力的なものにし、ブランドを理解する新たな方法を人々に示すことができます。オーディエンスの好みは、私たちが世の中に送り出すものも含め、世界とのさまざまな出会いを通じて形作られていきます。つまり、人々が現在何を好んでいるかを把握するだけでは、役割の一部しか果たせません。あるものが実現したときに人々の関心を引く可能性があるものは何か、そしてブランドに何をもたらしてほしいのかについても、私たちは判断を下す必要があります。そうした目標は、確信を持つのに十分な証拠がそろう前から掲げることができます。分析能力が頂点に達した人間性では、分析能力がますます広く行き渡るにつれ、その能力を使って私たちが下す選択の重要性が増すと論じました。ツールが一見際限のない数の可能性を生み出し、評価できるようになると、「できること」と「すべきこと」の違いは、とりわけ重大な意味を持つようになります。信頼できる予測は、選択の助けにはなっても、それ自体で答えを出すわけではありません。慣れ親しんだ手法がうまくいくと正しく予測しながらも、追求する価値のある、もっと興味深い目標があると判断することはできます。その判断には、ブランドについての理解、オーディエンスと築きたい関係、そして取り組みがどのくらいの期間にわたって意味を持つと考えるかが関わります。予測は私たちの判断に役立ちますが、目標に対する責任は私たちにあります。その責任を果たすには、自分の感性への自信だけでは不十分です。人は、単なる自己満足を画期的な成果と取り違えることも十分にあり得ますし、好ましくない予測にも耳を傾けるべきです。異論を検討し、それでもなおアイデアに試す価値がある理由を判断し、何かを学べるようオーディエンスに実際に触れてもらう機会を設けられるとき、自立した判断が役に立ちます。事前調査のコストが下がれば、そうした出会いの機会を増やせるはずです。削減できた費用の一部を、なじみのないオーディエンスを対象にした取り組みや、価値がまだ不確かなアイデアを小規模に試すための調査に充てることができます。そうすれば組織は、さもなければ退けていたかもしれない可能性について証拠を得られ、取り組みを担う人々も、熟慮した判断に基づいて行動する習慣を保てます。AIは、予想外のアイデアを生み出すことも含め、このプロセスのあらゆる段階に関わることができます。AIをうまく活用すれば、想像力を大きく広げられるかもしれません。守るべき自由とは、私たちが評価に用いるシステムによって価値がまだ確定されていない可能性を追求できることです。追伸: いつかAIは、想像し得る限り最も独創的な作品に対する反応も含め、人間の好みに生じるあらゆる意味のある変化を予測できるようになるかもしれません。そうなれば、何もかも予測できなくなります。それまでは、アイデアを人々に提示し、どのように受け止められるかを確かめる必要があります。
著者 Mark Himmelsbach, 共同創業者兼CEO、RYA
-

ソートリーダー偽のCVE、AI生成レポート、そして検証の必要性
説得力のある脆弱性レポートを作成するコストが下がりつつあり、その結果、ソフトウェアの保守担当者やセキュリティチームへの影響が大きくなっています。2026年7月、SQLiteに対して6件の共通脆弱性識別子(CVE)が公開され、そのうち2件には深刻度スコア9.8が付けられました。レポートは、メモリ安全性に関するバグを説明し、技術的な解説や概念実証コードも含んでおり、正当なものに見えました。しかし、JFrogの研究者たちは、レポートが言及していた関数の一部が、影響を受けるバージョンには存在しないことを突き止めました。さらに、概念実証(PoC)のいずれも、主張された脆弱性を再現できませんでした。SQLite自身のCVEページには現在、これら6件の報告はバグではないと記載されており、CVEの記録はその後却下されました。問題はSQLiteにとどまりません。curlの保守担当者であるDaniel Stenbergは昨年、寄せられるセキュリティレポートの約20%が、AIによって生成された粗悪な内容だと推定しました。GitHubのCVE採番機関(CNA)には、2026年5月に約4,000件のCVE申請が寄せられました。これは、前年同月比で約10倍の増加です。GitHubは、この増加の原因をAIに帰したり、申請の質が低下したと指摘したりしてはいませんが、件数の急増は、脆弱性開示プロセスが過負荷に陥っていることを浮き彫りにしています。AIによって詳細な脆弱性の主張を作成しやすくなる一方、その主張が正当なものかどうかを判断するには時間がかかります。また、いったんCVEがセキュリティフィードや公開データベースに登録されると、元の記録を訂正しても、すべての複製が自動的に訂正されるわけではありません。そのため、報告された脆弱性と技術的に検証された脆弱性を見分ける必要性が高まっています。「偽の」CVEとは?誤って報告された可能性が高いCVEを指して、「偽のCVE」という言葉が日常的に使われています。しかし、偽だからといって、意図的に人を欺こうとしているとは限りません。検証チェックを見落とした静的解析や、入力を攻撃者が制御できるものだと誤解したことが原因の場合もあります。実在する関数について詳しく説明しながら、無効な攻撃経路を主張するレポートもあり得ます。報告された条件が実際には脆弱性ではなかった場合、識別子(CVE ID)が割り当てられた後に取り消されることもあります。これは、意図的にでっち上げられたレポートとは異なります。見解の相違も、偽のCVEではありません。ベンダーが、悪用可能性、脅威の境界、あるいは信頼できない入力を処理することが関数の意図だったかどうかについて、研究者の調査結果に異議を唱えることはあります。しかし、異議があるからといって、研究者に誤りがあった証拠にはなりません。また、CVEが却下されたからといって、必ずしも捏造だったとは限りません。重複や事務上の理由で却下されることもあります。CVE識別子は独立した技術検証ではありませんが、業界は実際の報告を真剣に受け止める必要があります。偽のCVEが問題となる理由現在見られる問題の一つは、調査結果を適切に検証せず、AIを使って脆弱性レポートを作成する人がいることです。こうしたレポートには、詳細な技術解説やコードへの言及、さらにはPoCが含まれることもあり、正当なものに見える場合があります。しかし、SQLiteのCVEで見たように、参照された関数の一部は、影響を受けるバージョンにはそもそも存在しませんでした。GitHubは2026年、脆弱性の報告が大幅に増加したと発表しましたが、その増加をAIのせいだとはしておらず、申請の質が低下したとも報告していません。懸念されるのは、報告件数が増えれば、調査結果が本物かどうかにかかわらず、調査に必要な作業量も増えることです。脆弱性レポートのトリアージを経験した人なら、実務上の難しさはすぐにわかるでしょう。AIモデルは、不審なAPI呼び出しを特定し、粗筋程度の悪用シナリオを組み立て、プロらしく見える報告書をすばやく作成できます。そのシナリオが実際に成立するかを判断するには、該当するリリースを正確に確認し、制御フローを追跡し、データがどのように関数へ到達するかを把握し、テスト環境を構築したうえで、主張されているエクスプロイトを実行する必要があるかもしれません。レポートが正確かどうかにかかわらず、同じ手順が必要となり、費用もかかり得ます。偽のCVEは、評判にも損害を与えかねません。脆弱性の発表は、スキャナーフィードやセキュリティデータベース、検索結果にすぐ広まることがあります。しかし、その後の訂正は、元の情報ほど広く行き渡らない可能性があります。報告に異議が唱えられたり、却下されたりした後も、元の報告を見た顧客に対して、ベンダーが釈明を迫られることがあります。チームが誤った報告の調査に時間を費やすことで、本物の脆弱性が見過ごされたり、対応が遅れたりするリスクもあります。保守担当者やセキュリティチームのリソースが限られている場合、誤検知を否定するために費やす1時間ごとに、実際のセキュリティ問題の調査に使えた時間が失われます。自動化で対抗する新たに押し寄せる大量の報告に対処するため、今も手作業でトリアージを行っている調査担当者は多くいますが、この方法を続けることはできません。自動化は、脆弱性の主張を実際に影響を受けるリリースや構成と照合し、検証するうえで大いに役立ちます。確認すべき質問は次の5つです。 構成や権限も含め、攻撃が成立するための前提条件は妥当か? 問題とされている関数は、影響を受けるバージョンに存在するか? 攻撃者は脆弱なコードに到達できるか?該当する条件下で対象コードが実行される可能性があるか、また攻撃者がそのコードに到達する入力を与えられるかを確認する。 テスターは、管理されたテスト環境またはPoCを使って、その挙動を再現できるか? 観測された挙動は、アドバイザリーに記載されたセキュリティ上の影響を示しているか? エージェント型ツールは、テスト環境の構築、コードパスの分析、PoCの生成、レビュー用の実行証拠の記録ができます。しかし、あらゆる主張を自動的に検証できるわけではありません。脆弱性が実在する場合でも、環境が不完全だったり、トリガーが適切でなかったりすれば、PoCが失敗することがあります。テスターは、主張された悪用可能性を証明できなくても、クラッシュを再現できる場合があります。こうした注意点があるからこそ、人間の判断が依然として不可欠です。それでも、これらのツールを活用すれば、レポートへの対応にエンジニアリング、脆弱性管理、カスタマーサポートの各チームがさらに多くの時間を費やす前に、再現可能な結論に近づけることができます。CVEエコシステムの混乱に対処する簡潔な方針を一つ設けるだけで、偽のCVEの問題がたちまち解決するわけではありません。しかし、報告時により強い証拠を求め、再現状況をより明確に示すことは有効です。異議のあるレコードの扱いを明確にし、下流のデータをより迅速に修正することも役立ちます。研究者には、AIを活用して得た発見を提出前に検証するよう促すべきです。セキュリティチームとベンダーは、証拠の精査に注力しなければなりません。CVEの深刻度が「重大」と評価されていても、自社の環境で脆弱なコードパスに到達できるかどうかは分かりません。PoCが失敗したからといって、問題がないとは限りません。また、CVE IDを取得したからといって、問題を理解するために必要な技術的調査を怠ってよいわけではありません。AIは脆弱性を発見する能力を高める一方で、もっともらしく見えても誤った主張を生み出すことも可能にしています。報告が増え続けるなか、組織は検証に投資する必要があります。検証には、テストの構築、結果の再現、前提の確認、証拠を評価しやすくする取り組みが含まれます。エージェント型のセキュリティテストが重要な役割を果たし得るのは、この分野です。
著者 James Mullen, Edgescanの研究責任者
-

ソートリーダーAI生成の物件情報にだまされる賃貸希望者と、その見破り方
賃貸物件探しはますますデジタル化しており、入居希望者はオンラインの物件情報や写真、オンラインでのやり取りを活用して候補を絞り込んでいます。生成AIの登場により、賃貸物件探しには新たな課題が生じています。詐欺師は今や、本物と見分けるのが難しいほど説得力のある物件情報を作成できます。賃貸物件を探す人にとって、個人情報や資産を守るために、何に注意すべきかを知ることがますます重要になっています。AIによって賃貸詐欺がどのように変化しているのか、また、今も有効な確認方法は何かを理解すれば、入居希望者は複雑化する賃貸市場をより適切に乗り切ることができます。生成AIによって偽の賃貸物件情報はどのように本物らしくなっているのか?生成AIによって、賃貸詐欺の規模と巧妙さは大きく変化しました。詐欺師は、誰でも簡単に利用できるAIツールを使い、リアルに見える広告や物件の説明、やり取りの文面を数分で作成できます。そのため、わずかな手間で複数の偽の物件情報を作り、賃貸物件を探す人をだますことがはるかに容易になっています。画像生成ツールを使えば、実在しないアパートや寝室、キッチン、設備の説得力ある写真を作成できます。同様に、詐欺師はAI編集ツールを使って間取りを変更したり、目に見える損傷を消したりすることができます。AIを活用したコミュニケーション、自動応答、チャットボットを使えば、詐欺師は賃貸物件に関する問い合わせにすばやく返信し、説得力のあるやり取りを続け、不動産賃貸の専門的なコミュニケーションをまねることができます。文章が洗練されていることや、物件の詳細が具体的に書かれていることだけで、本物だと判断してはいけません。賃貸物件の情報が本物かどうか、借り手はどう確認できる?賃貸物件の情報が本物らしく見えても、独自に確認することが欠かせません。詐欺師は実在する建物の住所や本物の物件写真を簡単に利用し、説得力のある広告を作成できます。オンライン地図や不動産管理会社の公式サイト、一般公開されている建物情報を使って物件を確認しましょう。複数の情報源の内容に食い違いがあれば、賃貸広告に虚偽表示がある可能性を示す重大な警告サインです。Google Lensなどのツールを使えば、物件写真が別の住所や物件名、賃貸広告にも掲載されていないか確認できます。詐欺師は、実在する物件の本物の写真を再利用することがあります。しかし、AI生成画像は新たに作られたものであり、画像の逆検索で見つからない場合があります。そのため、検索結果に何も表示されなくても、写真が本物だとは証明できません。広告どおりの部屋かどうかを確かめる最も確実な方法は、実際に内見するか、リアルタイムのオンライン内見を行うことです。広告に記載された連絡先だけに頼らず、不動産管理会社の公式ウェブサイトを探しましょう。迅速で丁寧な返信は、自動チャットボットによるものかもしれません。そのため、返信が早いというだけでは、相手が信頼できる証拠にはなりません。賃貸物件を探す人は、独自に確認した連絡先を通じて会社に問い合わせ、物件が現在も借りられるか、また広告を出している人物が賃貸に関する問い合わせに対応する権限を持っているかを確認しましょう。AI生成の賃貸詐欺を見分ける警告サインとは?AI生成コンテンツだからといって、必ずしも詐欺とは限りません。しかし、情報の食い違いや不審な点があれば、詳しく確認すべき物件情報を見分ける手がかりになります。 注意すべき7つのサイン 警告サインから考えられること 相場を大きく下回る家賃 同じ地域の類似物件と比べて家賃が大幅に安く設定されている場合、すぐに注目を集めるための物件情報である可能性があります。 物件写真に一貫性がない 間取りの食い違いや不自然な建築の特徴、窓の位置の不一致、写真によって写っていたり写っていなかったりする設備がないか確認しましょう。Coralyの調査によると、大手不動産ポータルサイトに掲載された物件写真の10.8%にデジタル加工が施されていましたが、そのうち90%を超える写真で加工の開示がありませんでした。 曖昧で一般的な説明 物件情報では、洗練されたプロらしい文章が使われている一方で、部屋や建物、設備、立地についての具体的な説明が省かれていることがあります。確認できない情報や、写真と食い違う内容に注意しましょう。 すぐに送金するよう迫る 詐欺師は、複数の申込者がいると主張したり、物件を確保するためにすぐ手付金を払うよう求めたりすることがあります。賃貸物件を十分に確認できる前に支払いを求める相手には注意しましょう。 身元を確認できない家主や不動産管理会社 詐欺師は、もっともらしい名前やメールアドレスを使い、プロらしい文面で、実在する不動産管理会社や賃貸担当者になりすますことがあります。相手の身元や、内見しようとしている物件との関係を独自に確認できない場合は注意しましょう。 内見を避ける 実際の内見や信頼できるリアルタイムのオンライン内見を手配しない理由を何度も並べる場合、物件情報が虚偽である可能性があります。 物件情報に食い違いがある 複数の掲載情報で住所、建物の設備、賃料、空室状況に食い違いがある場合、物件情報が捏造されたか、別の広告からコピーされた可能性があります。 AI生成の賃貸物件情報が巧妙化するなか、借り手はどうすれば身を守れるのか?生成AIが進化するなか、借り手は広告のプロらしさや本物らしさだけで、信頼できるかどうかを判断できません。建物が実在することを確認するだけでは不十分です。物件が実際に貸し出し可能であること、広告を出している人にその権限があること、そして求められている支払い方法が安全で実在するものであることを確認しましょう。不正な賃貸申し込みによって、身分証明書、銀行口座情報、雇用記録などの機密性の高い個人情報が収集されるおそれがあります。機密情報が悪用されないよう、書類を提出したり送金したりする前に、賃貸担当者と申し込み手続きについて調べて確認しましょう。テクノロジーは、賃貸プラットフォームが不審な画像、重複広告、なりすましの試み、通常とは異なる物件掲載の動きを特定する助けになる可能性があります。しかし、AI検出ツールは万全ではないため、独自の確認や確立された物件管理上の安全対策に取って代わるものではありません。AI生成の賃貸詐欺を見抜くための借り手向けチェックリスト賃貸物件に申し込む前に、物件情報と賃貸手続きが正当なものかを判断するため、次の項目を確認しましょう。 物件の住所を確認する。建物が実在することを確かめ、所在地、外観、広告に記載された設備が、一般に公開されている情報と一致するか確認しましょう。 写真を確認する。画像の逆検索を行い、写真が別の物件や住所にも使われていないか調べましょう。また、間取りや設備に矛盾がないか確認してください。 賃料を比較する。周辺の類似物件を調べ、市場価格を大幅に下回る賃料で掲載されている物件は詳しく確認しましょう。 家主または物件管理者の身元を確認する。掲載情報だけに頼らず、独自に確認した公式ウェブサイトや電話番号を通じて会社に連絡しましょう。 掲載情報を照合する。信頼できるプラットフォームや物件の公式ウェブサイトで、賃料、空室状況、写真、物件の詳細を比較しましょう。 物件の内見を手配する。金銭的な約束をする前に、現地での内見、または信頼できるリアルタイムのオンライン内覧を申し込みましょう。 決断を急がせる手口に注意する。即時の敷金支払い、性急な決断、通常の賃貸手続きの省略を求められた場合は注意してください。...
著者 Jennifer Boyd, CLV Group & iRent 運営担当副社長
-

ソートリーダー次のソフトウェアユーザーはAIエージェント。あなたのアーキテクチャは対応できていますか?
AIエージェントが顧客からの請求に関する異議申し立てに対応する場面を想像してみてください。申し立ての内容を読み、アカウントの履歴を確認し、返金クレジットを付与すべきだと判断します。すべて数秒のうちに完了します。見事です。では実際にクレジットを発行するよう指示してみてください。顧客との契約は別のシステムにあります。承認ルールはアプリケーションのコードに埋もれています。請求処理ツールは、人が複数の画面を順にクリックして操作することを前提としています。エージェントは何をすべきか理解していますが、アーキテクチャがその作業の完了を妨げています。エージェント型AIが本番環境で稼働し始めるにつれて、より多くの企業が直面するだろうと私が考えているのは、まさにこの問題です。しかし不思議なのは、タスクを完了できない障壁が、エージェントの知能とはほとんど関係ないことです。これまで私たちは、エンタープライズソフトウェアを使う人々のために、何年もかけてその近代化に取り組んできました。今度は、ますます多くの業務を担うようになるエージェントのために、ソフトウェアを近代化する必要があります。ユーザーインターフェースだけが製品のすべてではなかった現在のエンタープライズソフトウェアの使われ方を考えてみてください。人々はアプリケーションを開き、ダッシュボードを操作し、判断を下し、あるシステムから別のシステムへと業務を引き継ぎます。ユーザーインターフェースは、ビジネスとやり取りするための手段です。エージェントに、そうした画面が必要とは限りません。APIやモデルコンテキストプロトコル(MCP)サーバー、その他のプログラム用インターフェースを通じて、情報を取得したり処理を開始したりできます。これは、ヘッドレスアーキテクチャへの移行の一端です。しかし、ヘッドレス化によってアプリケーションが消えてなくなるわけではありません。アプリケーションのデータ、ビジネスルール、権限、コンプライアンス要件は、依然として重要です。むしろ、以前にも増して重要になると私は考えています。長年、ソフトウェアベンダーは、洗練されたユーザーインターフェース、ユーザーの習慣、従業員の再教育にかかるコストを競争優位の源としてきました。エージェントがアプリケーションのユーザーインターフェースを開かずに多くの業務をこなすようになると、こうした優位性は弱まります。より価値を増すのは、その基盤となる記録システムです。信頼できるデータ、検証済みのドメインロジック、運用ガバナンス、そして監査可能な取引が重要になります。商業面にも影響があります。2030年までに、エンタープライズアプリケーションへの支出のうち、最大で2,340億ドルがエージェント型AIによる変革の影響を受ける可能性があります。これは変革によって影響を受けるリスクがある支出であり、消失が確実な支出という意味ではありません。また、かつてダッシュボード上で人が行っていた業務をエージェントが担うようになれば、ユーザー数に応じた料金体系は、利用量、実行したアクション、または成果に基づく料金体系へと、ますます移行していく可能性があります。ソフトウェアベンダーにとって、これはビジネスモデルの課題です。アプリケーションに依存する企業にとっては、アーキテクチャの課題です。部分ごとは近代化してきたが、ワークフローはそうではない多くの企業は、何年も前から近代化に取り組んできました。あるチームはレガシーアプリケーションを更新し、別のチームは分散したデータを最新のプラットフォームに集約します。さらに別のチームは連携機能を構築したり、単にユーザーインターフェースを刷新したりします。それぞれのプロジェクトは、単独では成功することがあります。問題が始まるのは、エージェントがそれらすべてにまたがるワークフローを実行しなければならないときです。エージェントに正確な顧客情報を与えても、その情報に基づいて処理するアプリケーションの重要なルールがレガシーコードに埋もれていたら、その先に何が起きるでしょうか。あるいは、整然としたAPIを公開しても、その背後にあるデータに一貫性がなければどうでしょう。エージェントは処理を実行できますが、その判断を信頼できるでしょうか。どちらの場合も、技術の一部は近代化できていますが、業務そのものは近代化できていません。エージェント型AIは、どの近代化プロジェクトが成功したかを気にしません。関心があるのは、ワークフロー全体が機能するかどうかです。実際には、次のようなケースがあります。あるクライアントは、複雑なエンジン修理の見積もりを迅速化する必要がありました。契約によって、どの部品を修理、交換、再生できるかが定められている案件です。契約書や整備マニュアルを手作業で調べるため、見積もりごとに数日、ときには数週間かかっていました。クライアントはすでにデータプラットフォームを近代化していましたが、見積もりの作成は速くなりませんでした。ボトルネックはデータではなかったからです。問題は調査にありました。私たちは複数の調査エージェントを活用してワークフローを再構築し、調査時間を80%削減しました。その結果、見積もりの進むスピードは一変しました。だからこそ、アプリケーションの近代化とデータの近代化を、互いに独立した2つの作業として計画することはできません。アーキテクチャは、ビジネス上の成果を最後まで実現できるものでなければなりません。APIがあっても、システムがエージェントに対応できるとは限らない答えは簡単だと思いたくなるかもしれません。エンドポイントを公開し、エージェントを接続すれば、それで完了だ、と。そんなに簡単ならよかったのですが。情報を取得することと、クレジットを発行したり、財務記録を更新したり、交換用の部品を注文したりすることは、まったく別です。ここで必要なのは、単なるアクセスではなく、処理の実行です。ここで私が使うのが、エージェント制御面という用語です。これは、範囲とガバナンスが定められたインターフェースであり、エージェントが記録システムから情報を読み取り、そこに書き込むためのものです。APIやMCPサーバーを通じて、エージェントにツールやデータを公開できます。しかし、MCPがビジネスルールを自動的に適用したり、誰に実行権限があるかを判断したりするわけではありません。こうした制御は、引き続き基盤となるシステムやワークフローに組み込む必要があります。エージェントは信頼できる正確なデータを取得できるでしょうか。ビジネスルールは明確に定められ、一貫して適用されているでしょうか。行動を提案しつつ、実行できるのは実行を許可された行動だけでしょうか。問題が起きたとき、その処理を追跡し、例外に対処し、可能であれば元に戻せるでしょうか。こうした問題は、より優れたモデルを導入するだけで解決するものではありません。ワークフロー、アプリケーション設計、データアーキテクチャ、統合、ガバナンスに関する課題です。そして、これらには一体となって取り組まなければなりません。テクノロジーではなく、業務から始めるでは、どこから始めればよいでしょうか。すべてのアプリケーションをヘッドレス化したり、利用可能なAPIをすべて公開したりすることから始めるつもりはありません。まずは、事業にとって重要なワークフローを一つ選びます。そのワークフローを最初から最後まで追ってみましょう。記録を保持しているシステムはどれでしょうか。ビジネスロジックはどこにあるでしょうか。エージェントが信頼できるデータは何でしょうか。どの判断に人の承認が必要でしょうか。システムが途中で停止したらどうなるでしょうか。ガバナンスはどのように維持されているでしょうか。そうすれば、重要な課題が見えてきます。それが、アプリケーション、データ、統合、制御にまたがる、連携の取れたバックログとしてまとめるモダナイゼーションのロードマップです。ばらばらの技術プロジェクトではなく、事業成果を軸に進めます。評価も、それに即して行いましょう。公開したAPIの数や移行したデータ量ではなく、ワークフローが確実に完了するか、例外がどのように解決されるか、そして事業成果が向上しているかを基準にします。目指すのは、あらゆる場面での自律化ではありません。人の判断が必要なところでは人が判断しながら、確実で信頼できる実行を実現することです。本質的な変化はヘッドレス化にとどまらない私が期待しているのは、ダッシュボードをなくすことではありません。仕事を進めるために、人が分断されたシステム間で手作業によって業務を受け渡す必要がなくなったときに何が起きるか、ということです。しかし、エージェント向けに設計されていないアーキテクチャの上にエージェントを載せても、そこにはたどり着けません。次世代のエンタープライズソフトウェアを決めるのは、人が何を見られるかだけではありません。エージェントが何を確実かつ責任を持って実行できるかも、その価値を決めるのです。
著者 Guy Merritt, Chief Technology Officer, KMS Technology -

ソートリーダーエグゼクティブ向けAIブリーフィングの台頭:エージェント型AI時代にCEOが一日を始める方法
長年、「データに基づくリーダーシップ」といえば、CEOが静的なダッシュボードに目を通し、長いメールのやり取りをスクロールし、前夜に丁寧にまとめられたブリーフィング資料に目を通すという、毎朝の決まった習慣を指していました。市場、顧客行動、業務運営が週単位で変化していた頃には、このワークフローでもかろうじて十分でした。しかし、シグナルが時間単位で変わるエージェント型AIの時代には、もはや十分な速さも、情報の豊富さも、対話性もありません。それに代わるものとして登場しつつあるのが、エグゼクティブ向けAIブリーフィングです。常時稼働する対話型エージェントが、事業全体を統合した見解を示してCEOの一日をスタートさせ、さらにリアルタイムで質問を掘り下げられるようにします。これは「また別のダッシュボード」ではありません。経営幹部とデータの関係を、これまでとは異なるものにする仕組みです。静的なダッシュボードから、絶えず続く対話へ従来の経営報告は、情報の探索ではなく、提示することに最適化されています。 ダッシュボードは、何を質問すべきかをすでに把握していることを前提としています。 ブリーフィング資料では、誰かがスライドを書き出した時点の事業の状況が固定されてしまいます。 メールのやり取りでは、最も重要な背景情報が返信の連鎖や本筋から外れた議論に埋もれてしまいます。 ダッシュボードがなくなるわけではありません。既知の指標を監視し、繰り返し寄せられる質問に答えるには、今も非常に優れています。苦手なのは、ダッシュボードの構築時には誰も想定していなかった質問への対応です。CEOの朝の時間は今も、次に何をすべきか決める前に、何が起きたのかについて食い違う見解をすり合わせることに費やされすぎています。エグゼクティブ向けAIブリーフィングは、この流れを逆転させます。「どのダッシュボードを開けばいいのか?」ではなく、CEOはまず「昨日から何が変わり、何に注意すべきなのか?」と尋ねます。エージェントは、収益の変化、パイプラインの変動、利用状況や業務運営における異常、リスクにさらされている顧客、そして自社にとって重要なマクロ環境のシグナルを、簡潔に優先順位をつけてまとめたブリーフィングで回答します。さらに重要なのは、CEOがそこで終わらないことです。すぐに自然言語で追加の質問をできます。 「昨日、EMEAでなぜ失速したのか?」 「今後60日以内に更新を迎え、ARRが大きく、サポートへの問い合わせが増えている契約はどれか?」 「先週のインフラコスト急増を引き起こした主な要因を、上位3つ示してほしい。」 ブリーフィングは、もはや静的な資料ではありません。事業について継続的に交わされる対話です。隠れた鍵:事業の仕組みを示すコンテキストグラフ「AIダッシュボード」の試みの多くが失敗するのは、単純な理由からです。モデルはデータにアクセスできても、必ずしも事業が実際にどのように機能しているかを理解しているとは限りません。エージェントが単一のデータウェアハウスやBIツールの上に載っているだけなら、得られる回答は依然として不完全で、偏ったものになります。本当の意味でのエグゼクティブ向けAIブリーフィングには、単一の指標ソースだけでなく、システムを横断し、時間の経過とともに事業がどう動くかを把握できるアクセスが必要です。そこで役立つのがコンテキストグラフです。企業との取り組みを通じて、最も効果的なエグゼクティブ向けブリーフィングは、CRM、製品分析、請求、財務、サポート、オブザーバビリティなどの構造化システム、プレイブック、SOP、ランブック、OKR、過去のリリースなどの業務知識、さらに顧客メモ、QBR資料、メールの要約、会議の議事録といった非構造化シグナルを統合するグラフによって支えられていることが分かりました。各システムを個別のデータキューブやダッシュボードとして扱うのではなく、コンテキストグラフは次のような関係を表現します。 このアカウントには、このARR、この利用パターン、このサポート履歴があり、センチメントはこのように推移している。 このリリースはこれらのサービスに影響し、これらの顧客に影響を及ぼし、これらのインシデントを引き起こした。 この地域では、パイプラインのカバレッジ、受注率、マクロ経済上のリスク、マーケティング費用がこのように組み合わさっている。 CEOが「今四半期、更新契約で最もリスクにさらされているのはどこか?」と尋ねたとき、エージェントは1つの表だけをもとに推測するのではありません。利用状況、ダウンタイム、CSのメモ、センチメント、契約金額を横断して関連する情報をたどり、順位づけされた、根拠を説明できる回答を提示します。エグゼクティブ向けAIブリーフィングの実際実用的なエグゼクティブ向けAIブリーフィングは、3つの層で構成されます。 毎日の統合ブリーフィング 収益、パイプライン、業務の健全性、主な異常をまとめた、エージェントが作成する1ページの要約。 経営幹部の好みに合わせて調整します。リスクを最初に知りたい人もいれば、成長や顧客事例を優先する人もいます。 対話型の掘り下げ CEOはチャットで詳しく尋ねることができます。「このパイプラインの落ち込みを説明して」「『緑』と誤判定されている顧客はどれか?」 エージェントは説明に加え、基盤となるシステムから得られた、関連情報へのリンクを提示します。 意思決定とアクションへの連携 次に推奨される対応:「製品担当VPとのレビューを予定する」「これらのアカウントにCSへの対応フラグを立てる」「この差異について財務部門に通知する」。 時間の経過とともに、エージェントはどのようなパターンがどのような意思決定につながりやすいかを学習します。 具体的な例として、経営幹部がテレメトリーデータに基づくエージェントを使い、社内の楽観的すぎる評価に異議を唱えるケースが見られます。たとえば、CRMではアカウントが「健全」と評価されていても、可観測性データやサポートデータには、何週間にもわたって障害が繰り返し発生していることが示されている場合があります。適切に構築されたコンテキストグラフは、この食い違いをすぐに明らかにし、顧客離れにつながる前に、経営幹部向けAIブリーフィングを通じてCEOに伝えます。CIOとデータ・AIチームにとっての意味データおよびAIのリーダーにとって、経営幹部向けAIブリーフィングはUX機能ではありません。コンテキスト管理の基盤を再構築せよという要請です。次の3つの変化が起きています。 ダッシュボードを量産する役割から、コンテキストを担う役割へ:もはや「ダッシュボードをもっと作る」ことが仕事ではありません。「エージェントが推論に利用できる、共有可能で信頼性の高いコンテキスト層を維持する」ことが求められます。これには、エンティティ解決、データリネージ、セマンティクス、ポリシーが含まれます。 プロジェクト単位の分析から持続的に稼働するエージェントへ:経営幹部からの依頼ごとに個別の分析を立ち上げるのではなく、チームは時間とともに変化する質問に答えられるエージェントを維持し、その利用状況から得られるフィードバックを反映します。 単一ベンダーへの依存から、モジュール化されたガバナンス対象のスタックへ:モデル、エージェント、インターフェースは今後も変化し続けます。一方、顧客、指標、ポリシー、意思決定に関する企業の理解は、選択したさまざまなモデルやエージェントで活用できる、長期にわたって維持され、適切に管理された資産であるべきです。経営幹部向けブリーフィング全体を、データ、プロンプト、エージェントのロジックもホストする単一のモデルプロバイダーに通している場合、次の3つの問題を抱えることになります。...
著者 Assaf Henkin, CEO兼共同創業者、Jedify
-

ソートリーダー企業が開発に投資する前にAIの活用案を検証すべき理由
人工知能は、日々の事業計画に欠かせない要素になりつつあります。企業は、反復作業の自動化、顧客サービスの向上、情報の分析、運用コストの削減に取り組む方法を模索しています。しかし、興味深いAIのアイデアを見つけることと、AIで実際に解決できる課題を特定することには、大きな違いがあります。多くの企業は、何を改善したいのかを十分に理解する前に、開発の検討を始めます。アイデアが事業として成り立つかを確かめずに、技術を選び、予算を見積もり、解決策の構築に着手してしまうのです。その結果、技術的には機能しても、実用面でほとんど価値をもたらさない高額なプロジェクトにつながることがあります。AI開発に費用をかける前に、企業は提案する活用案が実際の課題を解決するか、適切なデータを利用できるか、測定可能な成果を生み出せるかを検証する必要があります。こうした問いに答える時間を取ることで、不要な支出を防ぎ、開発する価値のある機会に注力できます。まず、実際の事業課題を理解する有用なAIプロジェクトはすべて、従業員や顧客がすでに直面している課題から始めるべきです。競合他社がAIチャットボットを導入しているから、自社も導入したいと考える企業があるかもしれません。しかし、それだけではチャットボットに何を実現させたいのかは分かりません。顧客は回答を得るまで長く待たされているのでしょうか。サポート担当者は同じ質問に何度も対応しているのでしょうか。営業時間外に重要な問い合わせを見落としているのでしょうか。課題ごとに、必要なアプローチは異なります。たとえば、顧客が基本的な注文情報を見つけられないのであれば、AIアシスタントを開発しなくても、既存の顧客ポータルを改善することで問題を解決できるかもしれません。一方、サポート担当者が複数のシステムにまたがるさまざまな質問への回答に毎日数時間を費やしているなら、AIソリューションの導入を検討する価値があるでしょう。最初のステップは、現在の業務プロセスを理解し、どこで問題が起きているかを特定したうえで、その原因を突き止めることです。こうした理解がないままでは、企業は当初の課題を解決しない技術に投資してしまうおそれがあります。AIが実用的な効果を発揮できる業務を特定するすべての業務に人工知能が必要なわけではありません。単純なルールに従う業務の中には、従来型のソフトウェアによる自動化で対応できるものもあります。一方、文書の理解、パターンの認識、大量の情報の処理を伴う業務もあります。投資先を決めるうえで、この違いは重要です。毎週、何百枚もの請求書を受け取る経理部門を考えてみましょう。従業員が互換性のある2つのシステム間で情報を転記するだけなら、標準的なシステム連携で十分かもしれません。しかし、請求書の形式がさまざまで、従業員が会計ソフトに入力する前に内容を読み取り、分類し、情報を抽出する必要があるなら、AIを活用した文書処理のほうが大きな価値をもたらす可能性があります。企業は、その業務がどのくらいの頻度で発生するか、どれほど時間がかかるか、従業員がどのような困難に直面しているかを調べるべきです。手作業による確認を繰り返すプロセス、大量の文書を扱うプロセス、情報の整理に時間がかかりすぎるプロセスには、有望な機会が潜んでいることがよくあります。目的は、あらゆる業務にAIを導入することではありません。AIの能力が明確な優位性をもたらす場面を見つけることです。解決する価値のある課題かどうかを見極める不便な課題であっても、新たなAIソリューションを正当化するほどコストや重要性が大きいとは限りません。たとえば、従業員が毎週、小規模なレポートの作成に10分を費やしているとします。その作業を自動化すれば時間を節約できますが、開発費と保守費がその効果を上回る可能性があります。これを、従業員が毎日数時間かけて出荷書類を確認している物流会社と比べてみましょう。このプロセスの遅れは、顧客への連絡、請求、配送スケジュールに影響する可能性があります。こうした業務フローを改善するほうが、より有力な事業上の根拠につながるかもしれません。企業は、課題の発生頻度、影響を受ける人数、そしてプロセスが遅れたり誤って完了したりした場合に何が起きるかを考慮すべきです。さらに、その課題が売上、運用コスト、顧客満足度、コンプライアンスに影響するかどうかも調べる必要があります。有用なAI活用案は、技術で解消できるというだけの不便ではなく、事業の成果に関わる重要な課題に対処するものであるべきです。開発計画を立てる前にデータの利用可能性を確認する適切な情報を利用できなければ、AIソリューションは安定した性能を発揮できません。顧客記録や請求書、業務報告書を何年分も保有しているため、自社のデータはAI開発にすぐ使える状態だと考える企業もあります。しかし、必ずしもそうとは限りません。情報が複数のアプリケーションに分散して保存されていたり、項目が欠けていたり、形式に一貫性がなかったりする場合があります。たとえば、AIによる売上予測システムの導入を計画している企業が、顧客記録に不備があり、売上報告書の更新方法も部門ごとに異なることに気づくかもしれません。基盤となる技術が正しく機能していても、こうした問題は予測の質に影響する可能性があります。開発を承認する前に、チームは必要なデータがどこにあるのか、正確なのか、どのようにアクセスできるのかを確認する必要があります。また、プライバシーやセキュリティに関する要件によって、そのデータの利用が制限されるかどうかも把握しなければなりません。場合によっては、まずデータの質を高めることが最も重要な取り組みとなります。その作業を終える前に開発を始めると、遅延や追加費用につながるおそれがあります。AIを既存の業務フローにどう組み込むかを把握する有望なユースケースであっても、企業の既存業務に適合しなければ、導入が難しいことがあります。企業は、従業員が日々利用するERPプラットフォーム、CRMツール、会計システムなどのアプリケーションに依存しています。AIの導入には、多くの場合、こうしたシステムを連携させ、チーム間で情報がやり取りされる方法を変える必要があります。購買発注書を処理するAIツールを開発する企業を想像してみてください。ツールが注文情報を正しく抽出できても、従業員が例外を確認し、取引を承認して、ERPシステムを更新する手段は必要です。こうした手順をあらかじめ計画していなければ、解決策が新たな分断された業務プロセスを生み出す可能性があります。開発に踏み切る前に、AIがアクセスする必要のあるシステム、交換が必要な情報、従業員の承認が必要な箇所を特定するべきです。個々のAIタスクだけでなく、業務フロー全体を把握すれば、ユースケースの実現可能性は高まります。費用をかける前に事業価値を見積もるAI開発には、初期のソフトウェア予算だけでなく、さまざまな費用がかかります。企業は、システム連携、データの準備、テスト、従業員の研修、セキュリティ審査、継続的な保守にも費用を支払う必要があるかもしれません。こうした費用は、現実的な事業上のメリットと比較する必要があります。たとえば、あるチームが毎月200時間をかけて書類を確認しているとします。AIソリューションによって手作業の負担を80時間削減できるなら、企業はその時間の価値を見積もることができます。ただし、削減された時間が自動的に金銭的な節約につながるわけではありません。従業員がその時間をほかの価値ある業務に充てられるのか、それとも実際にコストが減るのかを検討する必要があります。従業員が誤った出力を確認し、例外に対処するために費やす時間も考慮することが重要です。より広範な導入計画を策定する企業は、ユースケースとROIに重点を置いた全社的なAIロードマップを活用することで、事業価値、導入準備状況、リスクを投資判断の指針としてどう活用できるかを把握できます。現実的な事業計画があれば、意思決定者は思い込みに基づいてプロジェクトを承認するのではなく、複数の機会を比較できます。小規模なパイロットでアイデアを検証するAIのユースケースを検証する最も効果的な方法の一つは、本格的な開発に踏み切る前にテストすることです。パイロットを実施すれば、限られた量のデータと管理された業務フローを使い、提案するソリューションが実際のタスクに対応できるかを企業が検証できます。たとえば、AIによる文書処理システムを計画している企業は、まず少数の仕入先から受け取る特定の種類の請求書一つを対象に始めることができます。チームは、情報の抽出精度、処理時間、手作業での修正が必要な文書の数を測定できます。これにより、何が機能し、何を改善する必要があるのかを示す実践的な根拠が得られます。パイロットでは、書類の不備、特殊な形式、情報の欠落など、難しい状況もテストするべきです。目的は完璧なデモを作ることではありません。通常の業務環境でソリューションが安定して機能するかを把握することです。パイロットで深刻な問題が明らかになれば、企業はさらに費用をかける前に方針を調整できます。意思決定を自動化する前にリスクを検討する従業員を支援するAIアプリケーションには、情報の整理や行動の提案を行うものがあります。一方で、顧客、財務、機密記録に関わる意思決定に影響を与えるものもあります。こうしたユースケースに必要な管理の水準は、それぞれ異なります。たとえば、AIで社内会議の議事録を要約する場合と、AIを使って金融取引を承認する場合とでは、リスクが異なります。開発に着手する前に、企業はシステムが誤った結果を出した場合に何が起こり得るかを検討する必要があります。金銭的な損失につながる可能性はあるでしょうか。顧客に誤解を招く情報が伝わるおそれはあるでしょうか。機密データが漏えいする可能性はあるでしょうか。人による確認が必要な場面と、誤りをどのように修正するかを、チームで決めておく必要があります。また、導入後にシステムを監視する責任者が誰なのかも明確にしておく必要があります。こうしたリスクを早い段階で特定しておけば、問題が発生した後に対策を講じるのではなく、適切な安全策を事前に計画しやすくなります。最初の案を選ぶのではなく、複数のユースケースを比較する企業には、営業、財務、業務、カスタマーサポートなど、さまざまな領域でAI活用の候補が複数あることがよくあります。会議で最初に話題に上がった案を選ぶと、よりシンプルで大きな可能性を秘めたプロジェクトを見落とすことがあります。より効果的なのは、同じ基準を使って候補を比較することです。提案された各ユースケースを、次の5つの実務的な質問に照らして評価できます。 ビジネス価値:重要なプロセスや成果の改善につながるか。 データの準備状況:必要な情報を利用でき、その信頼性も確保されているか。 技術的な実現可能性:既存のシステムと連携してソリューションを機能させられるか。 導入に必要な労力:どれほどの時間、予算、社内の支援が必要になるか。 運用上のリスク:どのような問題が起こり得るか。また、そのリスクを管理できるか。 こうした比較により、企業は不必要な複雑さを伴わずに有益な効果をもたらす機会を見極められます。信頼できるデータがあり、成果が明確な小規模プロジェクトのほうが、複数の部門が関わる大規模な取り組みより、着手に適している場合があります。最も有望なユースケースが、必ずしも最も野心的なものとは限りません。組織が現実的に導入し、管理し、改善できるものこそが最適です。AIの案を延期または却下すべきタイミングを見極めるユースケースを検証しても、必ず承認に至るとは限りません。事業データの充実、プロセスの強化、または目標の明確化を待ってから開発に着手するのが適切な場合もあります。別のケースでは、従来型のソフトウェアを使えば、より低コストで問題を解決できる可能性があります。AIの案を却下しても、会社が時代に取り残されるわけではありません。それは、新技術を導入するプレッシャーに押されるのではなく、事業上のニーズに基づいて組織が判断しているということです。有効な検証プロセスでは、チームがそのまま進める、案を修正する、延期する、または完全に中止するという選択肢を取れるようにする必要があります。こうした柔軟性は、リソースを守り、より有望な機会に取り組む余地を生み出します。まとめAIは、反復作業の削減、情報へのアクセス向上、より良い意思決定の支援に役立ちます。しかし、企業が開発に投資したからといって、こうした効果が必ず得られるわけではありません。成果は、適切な課題を選べるかどうかに大きく左右されます。AIプロジェクトを承認する前に、企業は既存の業務フローを把握し、データの準備状況を確認し、期待できる価値を見積もり、導入上の課題を検討したうえで、重要な前提を検証する必要があります。また、AIが不要な場合には、よりシンプルな代替策も積極的に検討すべきです。AIのユースケースを検証する目的は、イノベーションを遅らせることではありません。時間、資金、労力を、真のビジネス価値をもたらし得るソリューションに確実に投じることです。こうした判断を早い段階で行う企業は、従業員が活用でき、事業として持続可能な実用的なAIソリューションを開発するうえで、より良い態勢を整えられます。
著者 Shashank Jaiswal, SDLC Corpの共同創業者兼最高情報責任者
-

ソートリーダーChatGPTに先に相談する顧客に、専門サービス事業者はどう対応すべきか?
顧客が必要な情報を持つ相手を頼って相談に訪れ、問題解決のための対応を期待するという従来のビジネスモデルは、AIから得た中途半端な情報を持ち込み、それを企業に実行するよう求める顧客によって揺らいでいます。AIには現実の状況を踏まえる力や、問題について十分に最新の情報がないため、AIが生成する回答が間違っていることも不思議ではありません。顧客に間違いだと伝えれば、相手の感情を害するおそれがあります。一方、AIの結論に従えば、誰かの貯蓄を危険にさらしかねません。これはあらゆる業界で起きている。病院にAIが生成した診断を持ってくる患者から、実在すらしない目的地へのAI作成の個別旅行プランを根拠に旅行代理店に異議を唱える旅行者までいる。AIから情報を得た顧客の時代は、多くの業界に課題を突きつけている。会計業界はこの問題にどう対処すればよいのだろうか?AIから助言を得て相談に来る顧客Kaylaを想像してみてください。彼女はQueensで小さな事業を営んでいます。ある日、毎年数千ドルの税金を節約するために事業の登録方法を変更するようチャットボットが勧めている、ChatGPTの画面のスクリーンショットを会計士に転送しました。理論上はうまくいく方法ですが、彼女の事業には当てはまりません。現地のNYCの規則と、彼女自身に支払うことが義務づけられる給与によって、節税額の大半が相殺されてしまうからです。Kaylaが高くつく失敗をしないよう、会計士は弁解がましく聞こえないようにしながら、こうした事情をすべて説明しなければなりません。しかし、このような状況では、表面的には正確そうな回答をチャットボットから示されたことで、会計士への不信感を抱き始める人もいるでしょう。こうした事例は今やよく見られる。OpenAIは、米国における税務関連のChatGPTへの問い合わせが、2025年第1四半期から2026年第1四半期にかけて4倍になったと報告した。同社のグラフには、ChatGPTは専門家の助言に代わるものではないという免責事項も記されていた。同様に、Adobeは、米国の労働者のうち、2026年にAIを使って確定申告をする予定の人の割合が26%に達し、2024年の11%から増加したことを明らかにした。つまり、顧客は表面的な知識を得ているように見える一方、その回答を確認する責任は専門家にのしかかっている。会計業界が特に影響を受けやすい理由税務規則はどこからでも調べられるが、その適用は顧客の所在地、事業の登録形態、課税年度、顧客のこれまでの経緯、その他モデルの学習データに含まれていない要素によって異なる。さらに、基準額や期限、税額控除などは毎年変わるため、モデルが古い規則を適用する可能性もある。TaxBenchが2026年に16の最先端モデルを対象に実施した評価では、最も優れたモデルでも、税務知識に関する質問に初回で正しく回答できた割合は84%だった一方、同じ質問を5回試した場合の正答率はわずか42%だった。こうした誤りによる見えにくいコストを負うのは専門家だ。AIの推論の誤りを見つけ、顧客に説明し、AIの回答が間違っている理由を納得してもらわなければならない。顧客の誤りを正すことで、サービス提供者が自己弁護している、あるいは時代遅れだと思われ、信頼のパラドックスが生じることもある。顧客は、チャットボットが隙のない計画を提示したのを見て、自分はだまされているのではないかと疑う。ほとんどの事務所は、こうした業務に対して料金すら請求していない。それでも、責任は事務所に残る。経験豊富な会計士の不足に加え、この追加業務が、いわゆる「ラクダの背を折る最後のわら」になるかもしれない。事業者が実践できる対策事業者はすでに膨大な業務に追われています。この新たな課題に対処するための戦略を整えなければなりません。 顧客の受け入れ時に、期待されることを明確に伝える。AIが生成した助言を事業者としてどう扱うのか、提出書類の内容について誰が責任を負うのかを説明しましょう。そうすることで、作業をしても請求されない、あるいは、そもそも自分の判断ではなかった決定の責任を担当者が負わされるといった曖昧な状況をなくせます。 顧客が抱える本当の懸念を知る手がかりとして、AIの回答を活用する。何を質問し、どのような回答を得たのか顧客に共有してもらいましょう。そうすれば、気になっていても尋ねるのをためらっている問題をたどることができます。 結論をどのように検証したかを共有する。顧客のAI生成の方針を頭ごなしに否定するのではなく、判断の根拠となった刊行物や規則を示しましょう。そうすることで、チャットボットの限界も理解してもらいやすくなります。 繰り返し見られる誤解をまとめた資料を作る。いわば、よくある質問集です。同じ誤った回答が何度も出てくるため、対応を標準化し、あらかじめ共有しておきましょう。 最後に、自社の業務にもAIを導入し、会計士が顧客との対話に使える時間を確保しましょう。業務をすべて手作業で行う事業者は、仕事に追われて追加の質問に答える余裕すらなくなり、上記の対策を実行するのも難しくなります。 サービス事業者への影響技術の進歩に伴い、情報は日々ますます豊富になっています。理論上、誰もがサービスを受ける方法を自分で調べられるため、サービス企業はもはや知識への門番ではありません。そうなると、売りとなるのは時間と安心感です。会計は金融インフラにおける信頼の基盤として機能します。顧客がチャットボットで作成した計画を携えて訪れるケースが増えるにつれ、専門家の価値は説明することから、検証し、判断することへと移っています。同じことは法律事務所、コンサルティング会社、アドバイザリー業務にも当てはまります。そうした信頼は人によってしか築けません。判断基準となるのは、こうした顧客との関係構築に取り組めるよう、企業が会計士の時間を確保しているかどうかです。業界全体で会計士不足に苦しむ一方、AIは定型業務を自動化することで、実際に解決策となります。つまり、AIで事前に情報を得た顧客は、業界がAIを導入して業務の負担を軽減し、実際の意思決定と問題解決は専門家に委ねるという変化の到来を告げているのです。顧客は今や、常にセカンドオピニオンを得られます。事務所の役割は、顧客から信頼される存在となることです。
著者 Slava Orekoff, 共同創業者兼CEO、Numica
-

ソートリーダーBinanceの盗難は採用面接から始まった――被害の規模を決めたのはアクセス権限
9月、Binanceのソフトウェアエンジニアは、実在しない企業との採用面接を2回受けた。1回目は人事担当者とのライブビデオ通話で、相手は実在する人物だと証明するため、写真や動画を含む個人のソーシャルメディアアカウントを共有した。2回目はチャットアプリ上で行われ、CEOを名乗る人物が応対した。終盤、エンジニアは業務用コンピューターにコーディング課題をダウンロードするよう求められた。10月29日、攻撃者はBinanceのウォレットから約63億4,000万ドルを移動させ、その大半は約20分以内に移された。FBIは、この盗難をTraderTraitorによるものとし、この北朝鮮のグループは、2025年2月のBybitからの15億ドルの盗難についても非難されている。これは、記録上最大の暗号資産盗難だ。Binanceは責任を認め、損失を補填すると述べている。11月3日時点で、被害を受けたトークン資産の98%が補充され、約28億5,000万ドルが凍結または差し押さえられたと発表した。問うべきなのは、侵害されたノートパソコンから何にアクセスできたのか、そして各チームが今日、自らの環境でそれを検証できるのか、ということだ。2つの侵入口と、6月から10月にわたる攻撃活動Binanceが11月3日に発表した更新情報には、ディープフェイクやその他のAIを利用した手法を示すものはない。いずれの侵入も人を介したものだった。検索結果を信頼したエンジニアと、採用担当者を信頼した別のエンジニアだ。この攻撃活動は少なくとも5か月にわたった。6月、AIコーディングツールを探していたウォレット担当のDevOpsエンジニアが、改ざんされたHomebrewインストーラーをダウンロードした。Binanceのセキュリティチームは異常を検知し、端末を交換して認証情報を更新した。しかしその時点で、攻撃者はすでにウォレットインフラチームのメンバーを把握していた。3か月後、攻撃者は別の経路から再び侵入した。9月に接触を受けたエンジニアは、正規の求人検索プラットフォームにプロフィールを掲載しており、Binanceでの勤務経験を記載していた。コーディング課題には、セットアップ中に実行されるマルウェアが仕込まれていた。正規のpyenvコンポーネントを悪意あるものに置き換え、攻撃者が管理するサーバーに接続し、痕跡を消去するものだった。Binanceによると、エンドポイント保護機能はこれを検知できなかった。10月20日、攻撃者はそのノートパソコンと社内AIツールを使い、さらに2人のエンジニアの端末を乗っ取った。そのうち1台は、6月に侵害されたDevOpsエンジニアのものだった。その端末から、コンテナのデプロイ権限を持つトークンが見つかった。10月29日、攻撃者はもう1人のエンジニアのコンピューターにログインし、盗んだ認証情報を使ってコンテナをデプロイし、盗難を実行するスクリプトを起動した。採用担当者を装う手口が今も通用する理由偽の採用担当者や、悪意あるコードを仕込んだコーディングテストは、昔から使われてきた手口だ。北朝鮮の工作員は何年にもわたり開発者を標的にこの手口を使ってきた。なかでも、「コンテイジャス・インタビュー」として知られるキャンペーンがよく知られている。Binanceによると、2026年だけで北朝鮮と関連があると疑われる攻撃の試みを57件阻止した。この手口が有効なのは、エンジニアが日常的に行っていることを求めるからだ。技術職の面接で見慣れないリポジトリを実行するのは、ごく一般的なことだ。不審な送信元アドレスも、クリック前に確認できるリンクもない。もっともらしい雇用主、ビデオ通話に映る人物、そして仕事のように見える課題があるだけだ。採用担当者からのメッセージは、見知らぬ相手からの連絡でも歓迎される数少ないものの一つだ。どれほど啓発を徹底しても、すべてのエンジニアが巧妙な誘いを毎回見抜けるとは限らない。そのため、対策は侵入を許す場合があることを前提にしなければならない。1台のノートパソコンからウォレットに至った経路まず気になるのは、そのエンジニアの環境におけるセキュリティ対策だ。社外のコーディング課題に業務用コンピューターを使うことには、検証が必要だ。さらに大きな懸念は、たった1台の端末が侵害されたことで、どうして他のシステムへのアクセスが可能になり、最終的に機密性の高い金融インフラにまで及んだのかという点だ。最初の感染以降の各段階は、Binance内部にすでに存在していた信頼関係に依存していた。社内AIツールは侵害された端末からの指示を受け入れ、それを同僚の端末にまで及ぼした。デプロイ用トークンはエンジニアのノートパソコンに置かれていた。有効な認証情報を使ったコンテナのデプロイによって、数十億ドルが動かされた。これらのどの段階にも、別の誘いを仕掛ける必要はなかった。社内AIツールには特に注意が必要だ。リポジトリ、エンドポイント、サービスに対して広範な権限で動作することが多く、ツールに指示できる端末を掌握した者は、その権限の及ぶ範囲も手にすることになる。開発を停滞させずに開発者を守る開発者には、パッケージのダウンロード、見慣れないコードの実行、ソフトウェアのテストが必要だ。ノートパソコンを金融部門のワークステーション並みに厳しく制限すれば、開発の速度は大幅に落ち、エンジニアは回避策に走るだろう。求人活動を社用端末で行わないという方針は妥当だが、誰もが常に方針に従うとは限らない。現実的な目標は、開発者の端末が侵害された後に何を実行できるかを制限することだ。いくつかの対策が、最も大きな違いを生む。信頼できないコードは、企業の認証情報にアクセスできない使い捨ての仮想マシン上で実行すべきだ。デプロイ用の認証情報は有効期間を短くし、権限の範囲を限定したうえで、可能な限り、管理されたデプロイのワークフローに対して発行すべきである。ウォレットの署名鍵や鍵の分割片は、開発者のワークステーションとは別に保護し、承認できる取引や認可を制限する署名ポリシーを設けるべきだ。ウォレット、決済、本番システムに関わる操作には、別の端末を使う2人目の担当者による承認を必須とすべきである。社内のAIツールは、最小限の権限で実行し、その動作を記録すべきだ。認証情報が正規のものである場合にも、検知が機能しなければならない。予期しない端末や時間帯からのデプロイに警告を出す振る舞い監視があれば、すべての認証情報が正しく見える状況でも、チームが介入する機会を得られる。Binanceによると、同社はこの種の検知を事件以降、拡充してきた。脅威インテリジェンスが果たす役割盗難の6週間前には、すでに警告が公表されていた。「Contagious Interview」に関する共同勧告では、AI、暗号資産、NFT関連企業の採用担当者を装う攻撃者が、IT専門家を標的にして暗号資産を盗む手口が説明されていた。Binanceの事例も、同じ手口に沿ったものだった。このような攻撃活動において、脅威インテリジェンスには具体的な役割がある。攻撃者が入れ替わることはあっても、その戦術は知られている。攻撃者を追跡するチームは、既知のインフラを遮断し、現在使われている口実についてエンジニアに警告できる。インテリジェンスは、誰を重点的に保護すべきかをチームに知らせる役割も果たす。Binanceで6月に起きた侵害のように、ある事件によって機密性の高いアクセス権を持つ人物が明らかになった場合、その人たちは数カ月にわたり標的となる可能性が高いとみなし、使用端末や受ける接触について監視を強化すべきだ。暗号資産業界以外にも当てはまること盗まれた資金は素早く移動し、取り戻すのが難しいため、暗号資産取引所が明白な標的となる。しかし、この手口は、銀行の決済処理基盤であれ、ソフトウェアベンダーのビルドおよびリリースプロセスであれ、開発者のワークステーションから数段階で重要システムに到達できる環境なら、どこでも通用する。採用担当者を装う手口は、そうした組織のエンジニアにも及ぶ。今週、自社の環境を見直すセキュリティ責任者にとって、最も重要な確認事項は2つある。第一に、侵害された開発者用ノートパソコン1台から、現時点で何にアクセスできるかを洗い出すことだ。保存されたトークン、SSH鍵、クラウド認証情報、社内AIツールも対象に含める。第二に、本番環境へのデプロイや高額の取引には、侵害された単一のIDでは得られない、独立した承認が必要であることを確認する。Binanceは影響を受けたシステムを再構築し、独立した審査担当者を招いたが、こうした判断は損失が発生した後に下された。同じ演習を今実施する組織は、自分たちの都合に合わせて判断を下せる。
著者 Gina Cardelli, プラットフォームおよび脅威インテリジェンス担当ディレクター、Fortra





