事業モデルとAIシステムの設計

1. 事業構造を捉え直し、収益モデルを設計する

価値創造力の中でも「事業モデルとAIシステムの設計」は、社会課題や技術シーズを実際に回る事業へと落とし込む工程です。ここでいう「事業モデル」とは、誰にどんな価値を提供し、その対価としてどのように収益を得るのかという一連の構造(ビジネスモデル^※1)を指します。技術と社会ニーズを結び直し、新しい価値連鎖^※2と収益構造を設計する力が、この分野の最初の柱です(スキルチェック項目No.11)。

この力の★レベル(見習いレベル)は、まず既存事業の構造を説明できることから始まります。いきなり新規事業を設計できる必要はありません。たとえば、あるアパレル企業のDXプロジェクトに参加したとします。最初にやるべきことは、目新しいAI活用のアイデアを出すことではなく、「この会社は誰にどんな価値を提供し、どこで収益を得ているのか」「仕入れから販売までの流れのどこにコストと利益が発生しているのか」を整理し、上司や他部署に説明できるようにすることです。この土台があってはじめて、AI・データを使って構造のどこを変えられるかという議論に進めます。

この構造理解の力は、仮説→検証→再設計のループを回しながら、事業性・実現性・持続可能性を統合し、戦略と実装を橋渡しするための出発点になります。AIプロジェクトが「技術的には面白いが事業として成立しない」実験に終わってしまう最大の原因は、この事業構造の理解を飛ばして、いきなり技術検証から入ってしまうことにあります。

さえ

「AIで何かできませんか」っていう相談、実はすごく多いんだけど、まず聞くのは「今の事業ってどうやって儲けてるんですか?」なんだよね。ここが曖昧だと、どんなに良いアイデアも空回りしちゃうの。

2. 抽象的な構想を、伝わるストーリーに変える

優れた事業構想も、関係者に伝わらなければ実現しません。抽象的な構想を、関係者が理解し動けるストーリーとして再構成する力(スキルチェック項目No.12)は、顧客・現場・経営という異なる立場の人たちを同じ地図に乗せ、意思決定と資源配分を動かすためのコミュニケーション設計です。★レベルでは、価値提案を要約して伝えられることが求められます。

たとえば、需要予測AIを導入するプロジェクトを考えてみましょう。データサイエンティストが「LSTMモデルによる時系列予測で、RMSEを15%改善しました」と報告しても、現場の店長や経営層にはピンときません。ここで必要なのは、「これまで欠品と廃棄ロスで年間◯百万円の機会損失が出ていたが、この仕組みを使えば発注のブレを小さくでき、廃棄を2割減らせる見込みです」という、相手の言葉に翻訳したストーリーです。

価値提案のストーリー化ができていないと、どれほど技術的に優れた仕組みでも「よくわからないから様子見」という結論で止まってしまいます。DXプロジェクトの成否を分けるのは、技術力以上にこの翻訳力であることが少なくありません。

3. PoC・MVPで「解けなかった問題」に再挑戦する

ここからが、この章の中でも特に重要な考え方です。AI・データの登場によって、これまで「解けなかった問題」に再挑戦できるようになりました。その再挑戦を安全かつ効率的に行うための検証設計力(スキルチェック項目No.13)が、PoC(Proof of Concept、概念実証)^※3とMVP(Minimum Viable Product、実用最小限の製品)^※4を使いこなす力です。★レベルでは、PoCを計画できることが求められます。

PoCとMVPは似た言葉ですが、目的が異なります。PoCは「そもそも技術的・事業的に実現できそうか」を小さく検証するための実験です。MVPは「実際にユーザーに使ってもらえる、価値のある最小限の製品」を作り、市場の反応を確かめるためのものです。この違いを理解せずに混同してしまうと、いつまでも実験を繰り返すだけで事業化に進めない、というプロジェクトによくある失敗に陥ります。

スキルチェック項目No.13の定義にあるとおり、この検証設計力の本質は「指標・リスク・学習計画を組み込んだ検証から拡張の道筋を描く」ことにあります。つまり、PoCは単に「試してみる」だけでは不十分で、何を測れば次に進んでよいと判断できるのかを事前に決めておくことが欠かせません。これを決めずに始めたPoCは、いつまでも「なんとなく良さそう」で終わってしまい、事業化の判断ができなくなります。

さえ

PoCとMVP、名前が似てるからよく混同されるんだけど「作れるか」を試すのがPoC、「使われるか」を試すのがMVPって覚えるとスッキリするよ。試験でも引っかけっぽく出てくるから要注意!

4. AIと人の役割分担を設計する

AIシステムを事業に組み込むとき、必ず考えなければならないのがAIと人の役割分担です(スキルチェック項目No.14)。AIに何を任せ、人が何を担うのかという線引きは、業務・UX(ユーザー体験)・技術的な制約を行ったり来たりしながら最適な協働プロセスとして設計する必要があります。★レベルでは、人とAIの基本的な役割分担を説明できることが求められます。

この役割分担は、大きく「自動」「補助」「判断」の3つに整理できます。「自動」はAIがすべてを完結させる領域、「補助」はAIが候補や下書きを提示し人が最終確認する領域、「判断」は最終的な意思決定を人が担う領域です。たとえば与信審査AIを導入するプロジェクトでは、明らかに問題のない少額案件はAIが自動判定し(自動)、グレーゾーンの案件はAIがスコアとその根拠を提示して担当者が確認し(補助)、高額・特殊な案件は必ず人間が最終判断する(判断)、という設計にすることで、効率化と安全性を両立できます。

ここで重要なのは、役割分担を決めるだけでなく、AIが失敗したときにどう安全に倒れるか(フェイルセーフ^※5)や、人にどう引き継ぐか(エスカレーション^※6)まで含めて設計することです。AIに任せきりにした結果、明らかな誤りに誰も気づかず被害が拡大した、という事例は実際のAI導入プロジェクトでもたびたび報告されています。役割分担の設計は、効率化のためだけでなく、事故を防ぐための設計でもあるのです。

5. 将来を見据えた拡張可能なアーキテクチャ設計

事業やAIシステムは、作った瞬間から陳腐化が始まります。将来の技術進化・利用規模の拡大・障害の発生をあらかじめ織り込んだ、拡張可能な全体設計力(スキルチェック項目No.15)が必要になる理由はここにあります。★レベルでは、現状のアーキテクチャを整理し、説明できることが求められます。

たとえば、最初は1店舗だけの実験だったAI需要予測の仕組みを、将来的に全国数百店舗に展開することが決まったとします。1店舗分のデータを前提に組んだ仕組みをそのまま拡大すると、データ量の増加に処理が追いつかなくなったり、店舗ごとの特性の違いに対応できなかったりする問題が起こりがちです。こうした事態を避けるには、最初の設計段階から「将来何倍の規模になっても耐えられるか」「古いレガシーシステム^※7とクラウドをどう滑らかに接続するか」を意識しておく必要があります。

6. 目的→指標→データ→モデル→運用を一本化する

この章の締めくくりとして、最も重要な考え方を扱います。AI・データを「価値の文脈」から設計に統合し、目的→指標→データ→モデル→運用を一本化する力(スキルチェック項目No.16・必須)です。★レベルでは、目的に応じた指標を設計できることが求められます。

AI・データ活用プロジェクトが失敗する典型的なパターンは、この5つの要素がバラバラに切り離されてしまうことです。「とりあえず精度の高いモデルを作る」ことが目的化してしまい、そのモデルが事業のどの指標を改善するためのものかが誰にも説明できない、という状態です。これを防ぐには、次のような一本の線でつながった設計を意識する必要があります。

目的から運用までを一本の線として設計する姿勢は、単なるプロジェクト管理のテクニックではなく、人とAI・データの関係を直感的かつ倫理的に設計するという、この章全体を貫く考え方の到達点でもあります。次の9-5では、この設計をさらに安全に運用するための、ガバナンスと組織の設計について見ていきます。

さえ

目的・指標・データ・モデル・運用って、バラバラに考えがちだけど、実は1本の線でつながってなきゃダメなんだよね。ここが試験でも実務でも一番大事なポイントだから、しっかり覚えておこう!

まとめ

ここまで、DS検定の出題範囲である「価値創造力／事業モデルとAIシステムの設計」の考え方を見てきました。最後に振り返っておきましょう。

1. 事業構造と収益モデルの設計 ― まず既存事業の構造を説明できるようになり、そこから価値連鎖と収益構造の再設計を考える
2. 価値提案のストーリー化 ― 抽象的な構想を、顧客・現場・経営それぞれに伝わる言葉に要約する
3. PoC・MVPによる検証設計 ― 「解けなかった問題」に再挑戦するため、成功基準・撤退基準・学習計画を組み込んでPoCを計画する
4. AIと人の役割分担 ― 自動・補助・判断の3つに整理し、フェイルセーフやエスカレーションまで設計する
5. 拡張可能なアーキテクチャ設計 ― 将来の規模拡大や障害を織り込み、レガシーとクラウドを滑らかに接続する
6. 目的→指標→データ→モデル→運用の一本化 ― 5つの要素が一本の線でつながるように設計し、目的に応じた指標を自ら設計できるようにする

次のレッスンでは、こうした事業モデル・AIシステムの設計を安全に実行するための、ガバナンス・倫理と組織の設計について扱います。