Sakana AI・SCSK・住友商事の提携、研究を業務へつなぐ条件

研究と業務の間を、三社でつなぐ

各社の役割は明確に分かれている。Sakana AIはモデルやAIソリューションの研究開発、課題から具体的な用途を考える作業を担う。SCSKはデータ整備、既存システムとの接続、情報セキュリティ、品質やガバナンスを含む実装を担当する。住友商事は事業の構想と、多様な産業の現場への展開を担う。

住友商事が示す約900社の連結事業会社と10万社の顧客基盤は、事業展開の基盤として挙げられた数字だ。すべての会社にAIの導入が決まったという件数ではない。大きなネットワークがあっても、各業務の必要条件と採用の判断は個別に残る。

この組み合わせの意味は、モデルの性能だけでは越えにくい壁を対象にした点にある。企業のデータには欠損や形式の違いがあり、既存システムには権限や稼働の制約がある。そこを調整せずにAIの入口だけを用意しても、安定した業務にはつながらない。公式発表も、運用と継続改善まで一体で考える必要性を強調している。

初期の取り組みは四つ

最初の領域には、金融・製造業など高い信頼性が必要な実案件が挙げられた。PoCにとどまらず、本番利用を見据えた設計、品質管理、運用まで知見を蓄積する方針である。ただし具体的な導入企業名や成果の数字が、この発表で一括して公表されたわけではない。

二つ目はサイバーセキュリティで、Sakana AIのオーケストレーション技術を使い、脆弱性の診断から修正まで支援するサービスや事業モデルを検討・開発する。これは取り組みの計画であり、すでに誰でも契約できる完成商品が同日発売されたという説明ではない。

三つ目は企業向けAIプロダクトやサービスの共同開発・高度化だ。特定のモデルへ限定せず、目的に合う技術を選び、進歩に応じて評価を続ける方針が示された。四つ目は街づくりなどの社会インフラ領域で、国内で得た知見の海外展開も視野に入れる。

いずれも幅が広いが、発表では一律の提供価格、全領域共通の開始日、売上などの数値目標は示されていない。提携の発表、個別案件の開始、商品提供、効果の実証は異なる段階である。どこまで進んだかを追うときも、その段階を分けて確認する必要がある。

一つのAPIで、実装の責任は消えない

Sakana AIのFuguに関する説明では、複数のAIエージェントの調整を一つのモデルAPIとして扱う設計が示されている。個々のモデルの得意分野を組み合わせることは、用途に応じた性能と費用の調整につながりうる。ただし今回の提携全体がFuguだけに固定されるという意味ではない。

モデルを取り替えられる構造でも、利用企業側にはデータと業務への統制が必要だ。どの情報を外部へ送れるか、誰の権限で処理を実行するか、誤った出力があったときに誰が止めるかを決める責任は残る。モデルの選択を外へ任せるほど、結果を受け取る側の確認条件を明確にしたい。

なお、Fuguの製品ごとに、構成モデルを利用者が指定・除外できる範囲は異なる。提携で技術が利用されると聞いただけで、顧客ごとの処理先やデータ保持の条件が確定するわけではない。案件の契約と設計の段階で確認する事項である。

PoCを終えたあとの評価項目

以下は編集部の考察だ。企業が今回のような提携サービスを評価するなら、デモで良い回答が出るかに加え、日常業務で失敗をどう扱うかを確認したい。担当者が不在のときに処理が止まるのか、途中まで進んだ仕事を再開できるのか、担当部署へ引き継げるのかといった条件が、継続利用の負担を左右する。

金融や製造業では、平均的な正答率だけでは運用を決めにくい。たまに発生する重大な誤りが、単純な手作業より負担を増やす場合がある。通常の処理と例外を分け、AIが回答を控えるべき場面、人が承認する場面、記録を残す場面を定めることが必要だ。

評価の単位も、生成した文章の数だけでは足りない。確認を終えて採用された件数、担当者の修正時間、復旧に要した時間、問い合わせの増減を併せて見ることで、見た目の省力化と業務全体の改善を区別できる。導入前にこれらの基準をそろえておけば、複数社の提案も比較しやすくなる。

モデルの更新を、業務の変更として扱う

AIの性能が上がっても、既存の手順と完全に同じ動きになるとは限らない。モデルを更新した結果、以前は保留した依頼へ回答するようになったり、出力形式が変わったりする可能性がある。更新を単なる部品交換として扱わず、業務で必要な動作を再確認する仕組みが重要になる。

三社は継続的な評価と改善を掲げるが、顧客側でも検証に使うデータと合否を維持する必要がある。外部の支援者が変わっても検証を続けられるよう、評価記録と判断の理由を手元に残すとよい。導入担当者の経験を、組織で引き継げる知識へ変える作業だ。

契約の前に確認できる成果物

導入を検討する企業にとって、体制図の次に必要なのは、各段階で何が納品・確認されるかという具体性だ。例えば、データを整理する工程では、利用可能な項目と不足している項目の整理がある。システムとの接続では、参照だけの権限と、実際に書き込む権限を分けられる。運用へ移す前には、例外の一覧、障害時の連絡先、変更の承認方法を確認できる。

これらは今回の三社が一律に提供すると発表した成果物ではなく、発注側が検討する項目である。研究、接続、事業展開を別の組織が担うほど、工程の受け渡しに何が必要かを決めることが重要になる。モデルの問題なのか、接続先のデータの問題なのか、業務ルールの問題なのかを調べられなければ、改修の責任が曖昧になるためだ。

また、AIが出力するまでの速度だけでなく、承認を経て仕事が完了するまでの時間を見る必要がある。人の承認が必要な仕事を、承認工程を除外して自動化の効果として数えれば、現場の負担と説明する成果が離れてしまう。導入の前後で同じ範囲を測り、残った手作業も含めて評価するほうが、次の案件の判断に役立つ。

他社へ広げるときは、共有できない部分もある

実案件で得た知見を他の顧客へ展開する方針は、導入のやり直しを減らす可能性がある。一方、同じ業種でも承認経路やデータの意味、責任分担は異なる。テンプレートを移すだけで安全性が再現できるとは限らない。共通化する部分と、各社で設計し直す部分を見極めることが必要だ。

特に社会インフラへ広げる場合は、現場の関係者、利用者、保守する組織が多くなる。海外展開では言語だけでなく、契約やデータの取り扱い、現地での運用の違いも生じる。国内の成功例を示すだけでなく、どの条件が変わると再検証が必要かを示すことが、展開の説明として重要になるだろう。

この提携は、研究の成果を実業務へ接続するための体制づくりとして注目できる。今後見るべきは提携先の規模だけではなく、どの案件で何を確認し、運用を含む成果をどこまで具体的に公表するかである。構想と利用可能なサービスを分けて追うことで、企業は導入の時期と範囲を判断しやすくなる。

運営会社・AIの業務導入に関する相談先はRO合同会社へ。参考報道：イノベトピアの三社提携解説。本記事の実務上の提案は編集部の考察で、三社による効果保証ではない。