導入後のAIを、誰が動かし続けるのか

シンガポールで新たに発表された人材・能力開発の取り組みと、オーストラリアの銀行・保険会社による本番運用の経験から、AI投資を評価する実務的な視点が見えてきます。システムを担う人たちに、適切な運用に必要な知識と実践の機会が用意されているでしょうか。

2026年9月16日にシンガポールで開催されたData + AI World Tourで、デジタル開発・情報相のジョセフィン・テオ氏は、AI活用をさらに進める上での課題を3点挙げました。人材・スキルの不足、既存業務への組み込み、良質なデータへのアクセスです。多くの場合、組織は一つのプロジェクトの中で、この3点すべてに対応しなければなりません。

これは、技術を導入する側の進め方にも関わります。データを維持・管理し、回答を吟味し、変更を承認するチームには、システムの構築段階から関わってもらう必要があります。引き継ぎの打ち合わせまで準備を先送りすれば、ソフトウェアの追加購入だけでは解消しにくい依存関係が残ってしまいます。

シンガポールとシドニーでは、同じ日にDatabricks World Tourが開催されました。シンガポールでの発表とシドニーで公表された金融サービス分野のプログラムは、この問題を考える上で二つの視点を与えてくれます。シンガポールでは、導入と人材育成のつながりが明確に示されました。一方、シドニーの議題は、既にAIを日々の業務で活用している銀行や保険会社の事例と重ねて考えることができます。

シンガポール：運用する力を、プロジェクトの中で育てる

Databricksは、シンガポールで今後3年間にさらに2万人を育成する計画を発表しました。人数の目標以上に注目したいのは、併せて発表された支援体制です。EDB（経済開発庁）が支援するEnterprise AI Transformationプログラムでは、参加企業にDatabricksの費用負担でForward Deployed Engineer（導入を支援するエンジニア）を配置するとしています。現地パートナーとともに導入を進め、その後のAI活用を企業が自ら拡大できる運用体制を整える計画です。

これらは幅広い企業分野を対象とした取り組みであり、成果はこれから示される段階です。それでも、設計には注目すべき点があります。開発中に生じる疑問を学習内容に反映できる一方、運用を担う人たちは、後から変更に大きな費用がかかる依存関係が固まる前に、設計上の判断を問い直せます。導入側にとっては、構築と並行して学習を計画し、予算を確保する理由になります。

公共機関では、その機関が負う責任にも合わせて進める必要があります。DatabricksのGovTech事例は、AWSを用いた基盤の移行、Unity Catalogによるきめ細かなアクセス制御と、エンジニアリングチームが主導し、Databricks Academyを活用する利用者向け研修計画を紹介しています。ベンダーが公開した事例ではありますが、基盤を変える際に、利用する人たちの準備も進める具体例です。

シンガポールでは、公共部門のデータに関する義務にも独自の根拠があります。政府資料は、Public Sector (Governance) Actと政府内の規程を、民間部門のPDPAの枠組みと区別しています。各機関は、委託先に適用するデータセキュリティ要件を定めます。そのため、実務に役立つ演習には、その機関が承認したデータ、アクセスの仕組みと運用手順が必要です。機微な情報を扱う場合には、適切な代替資料を用意する必要もあります。

ここで力を発揮するのが、専門性を備えた現地チームです。アクセス権限を承認する人たちと協働し、組織内で意思決定がどう進むかを理解し、サービスが運用に入ってからも関与を続けられます。域内の専門家も、業務範囲とアクセスについて合意があれば、専門性を補うことができます。海外拠点の人員を増やしても、それだけで政府データの移転や政府システムへのアクセスが認められるわけではありません。

シドニー：役立つAIには、運用上の責任が伴う

シドニーの公表プログラムには、適切な管理の下で運用できるデータとAIの基盤を扱う金融サービスのフォーラムが含まれ、NAB、Great Southern Bank、Lendi Groupの登壇者が掲載されていました。公開された顧客事例を見ると、こうした課題がなぜ重要なのかが分かります。

2026年6月にNABが公表した記事によると、Databricks GenieとGenie Codeは、同行の分析担当者の間で既に稼働していました。初期の利用では、ユースケースごとに開発にかかる時間を2〜4日分短縮できたとしています。一方、業務部門への利用拡大はまだ試行段階にあり、研修とガバナンスの整備が展開を支えていました。

この二つの段階を分けて捉えることには意味があります。経験を積んだ分析担当者の作業を速めることと、対話型ツールをより幅広い従業員に開放することでは、必要な対応が異なります。質問の立て方が適切か、根拠となるデータが妥当か、その回答を今回の判断に使ってよいかを見極める役割は、引き続き必要です。

Databricksが公開した発表で、Suncorpは、自社開発の生成AIアプリケーション約18件が本番稼働し、3,000人を超える従業員に利用されていると報告しています。また、人による確認を残した、より広範な保険金請求業務の自動化設計も示しています。そこでは、業務、エンジニアリングとガバナンスの各チームのニーズに応じた監視が組み込まれています。

保険会社にとって、役立つ回答が得られることは業務の一部にすぎません。従業員には情報が不十分な場合の対処手順が必要であり、エンジニアは障害を調査し、管理者はサービスの利用を制限したり復旧したりすべき状況を判断しなければなりません。APRAのCPS 230は、対象となる金融機関に対し、オペレーショナルリスクの管理、障害発生時の重要業務の継続と、サービス提供者に関わるリスクの管理を求めています。そのため、責任の所在と復旧体制も、導入時に取り組むべき課題になります。プラットフォームが顧客に代わって、その責任分担を決めてくれるわけではありません。

引き継ぐ仕事に即して学ぶ

研修で何を扱うかは、運用体制から考えます。導入した仕組みが日々のサービスになったとき、各担当者は何ができなければならないでしょうか。経営層には、提案された用途を費用とリスクに照らして評価する力が必要かもしれません。データ管理担当者には、アクセスを承認し、その根拠を説明する力が求められます。エンジニアには、元の開発者を待たずにデータパイプラインの障害を診断する力が必要になるでしょう。

例えば、シンガポールの公共機関では、承認済みのデータセットについて、アクセス申請から分析結果の公開までをたどり、各段階の判断を参加者に説明してもらう演習が考えられます。オーストラリアの保険会社では、保険金請求の業務支援AIが出した回答を元の情報までさかのぼり、根拠のない回答が出た場合の対処を試す演習が考えられます。組織が実際に求める管理手順や報告・判断の経路を使い、学んだことを実務で確かめられる点に価値があります。

すべてを個別に設計する必要はありません。標準的な講座は、プラットフォームの基礎や資格試験対策に役立ちます。銀行や公共機関には、既に豊富な専門知識が蓄積されている場合もあります。NABの段階的な展開も、自らの必要性に合わせてアクセス、研修とガバナンスを整えている例です。個別支援が価値を持つのは、顧客のシステム、役割分担や導入経験にある具体的な不足を埋める場合です。

成果を確認する基準も、同じように具体的であるべきです。チームは合意した業務を完了し、自分たちの判断を説明し、いつ上位者や専門家に対応を求めるべきかを見極められるでしょうか。出席実績や試験結果では、これとは別の側面を測っています。顧客が運用委託の継続を選ぶ場合でも、その関係を適切に管理し、十分な理解に基づいて変更を判断できるだけの知識は必要です。

導入パートナーは、何を顧客に残すべきか

Ultra Tendencyが公開しているAcademyの研修案内では、資格取得に向けた研修と、役割、用途やクラウド環境に合わせて設計する研修を区別しています。同社は、シンガポールの公共部門とシドニーの金融・保険を重点分野とし、両市場で個別のニーズに合わせた研修に注力するとしています。欧州で培ったエンジニアリングの経験と、特定の技術やクラウド事業者に依存しない同社の方針を生かし、現地での導入支援と顧客の能力育成を結び付ける方向性です。

APACで投資を進める日本企業にとって、考えるべきは、何を共通化でき、何を現地の責任で担う必要があるかという点です。共通のプラットフォームは、域内での利用拡大を支えられます。それでも、個々のサービスを担う人たちは、そのデータ、利用者と利用の影響を理解する必要があります。シンガポールとシドニーは、その力を育てる上で異なる手掛かりを示しています。

次のプロジェクト計画には、稼働開始後にシステムを担う人、その人たちが下すべき判断と遂行できなければならない業務を明記するべきです。その上で、引き継ぎ前に実践する時間を確保します。計画のこの部分を誰が担い、そのための予算は用意されているでしょうか。