生成AIのSaaSを作って企業に提供した話
昨年末から生成AIのビッグウェーブがきましたが、最近は「企業全体で生成AIを活用しよう」という動きが本格的になってきたように感じます。
私もこの半年、生成AIの事業利用について考えており、ある企業のために、生成AIサービスを開発し、販売してみました。
この記事では、その一連の経験で分かったことを整理してみます。
どんなものを開発したのか？
詳しくは書けないのですが、スマホゲーム開発のある領域において発生していたバーニングな課題を、生成AIで解決しました。
Azure OpenAI（gptモデル・Embedding Adaモデル）とAWS、スプレッドシートを使って開発しています。
９月から導入を開始して現在２ヶ月ほど経過したところですが、一定の価値を発揮でき、現場では「無いと困る状態」になってきています。
なぜ開発したのか？
実は、最初から生成AIサービスの導入を目的としていた訳ではなく「PM支援」としてそのプロジェクトに参画しました。
担当した領域は、経験者がおらず手付かずな状態だったため、まずは自分で業務を行いながら、ワークフローの構築をしました。
そして、運用メンバーをアサインして引き継ぎを始めたのですが、あるタスクが引き継げないことが分かりました。
引き継げない理由は、大きくこの２点です。
必要な能力が特殊（＝採用がかなり困難）
モチベーションも下がりやすい（＝採用しても退職しやすい）
この問題を、生成AIを活用することで解決しようと、ビジネスモデルを考えて、自社（MIGIUDE）で開発を始めました。
開発しても導入されず、ただの赤字で終わる可能性もありましたが、恩のある企業だったのでリスクを取りました。
論点１ 「生成AIをどの業務に活用すべきか？」
ここからは、分かったことを書いていきます。
企業が「社内で生成AIを活用しよう」とか「生成AIを活用した商品を作ろう」と考えた時に、最初の論点は「どの業務に使うか？」です。
企業の方とお話する機会が増えましたが、よく「時間がかかる業務に使うべき」と聞きます。しかし、もう少し観点があると思いました。
人の採用で解決しづらいことに使おう
私の考えとしては、「生成AI」の代替手段は「人」なので、「人の採用で解決しづらいこと」に活用するのが良いと思います。
では、「人の採用で解決しない業務」とは何か、６つの観点を挙げてみました。
例えば、私が生成AIを導入した業務は、下記３つの観点で「人の採用」での解決が難しかったのです。
能力：複数領域のスキルが必要で難しく、ミスが多発する
期日：突然、数時間後が締め切りの依頼がくる
意義：下請けっぽくなりやすく、やりがいを感じづらい
生成AIの特性を理解しよう
では「人」の代わりに「生成AI」を採用するとして、「生成AI」はどんな人材なのでしょうか？
よく聞くのは「スピード」です。
これは間違いないですが、私の考えでは３つの特性があります。
「スピード」以外にも「クオリティ」と「コミットメント」の特性が大きいと考えます。
「クオリティ」は、正直、ハイコンテクストな業務を正確にできるハイパフォーマーには敵いません。様々な文脈を汲み取り、あちこちに散らばる情報を捉えて判断するのは、生成AIにはまだ難しいです。
しかし、ローパフォーマーの業務を標準化することには、十分に使えます。
そして、軽視できないのは「コミットメント」です。ハイパフォーマーは、いつ転職してしまうか分かりません。生成AIの導入に投資することは、ノウハウ・データを組織に蓄積し、属人化リスクを下げることに繋がります。
生成AIは、ワークフローに組み込もう
ある企業が行った「ChatGPTを組織的に活用できているか」の調査を見たのですが、全く活用できていませんでした。
ChatGPTを業務で使う人は、実はかなり限定的だと思います。多くの人にとって、何に使えるのかも想像つかないし、適切なプロンプトを作るのも難しいです。
では、生成AIの組織活用を促進するには、どうすれば良いのでしょうか？
結論は「ワークフローに組み込む」ことなのですが、まず、業務を２種類の領域に分けて考えてみましょう。
ChatGPTは、Creative領域（上流/発散フェーズ）においては利用できるのですが、Logical領域（下流/収束フェーズ）の業務には向きません。
そして、一般的な企業では、「Creative領域」の業務は少なく、「Logical領域」が大半です。ゼロから創造的な業務を行うのではなく、様々な既存事例を参考に、フローに沿って、再現性を持って業務を行うことが多いです。
そのため、「Logical領域」の業務で生成AIを活用した方が、組織へのインパクトは大きくなります。すなわち、ワークフローに生成AIを組み込む必要があるということです。
ワークフローに組み込まないと「Nice-to-have（あると助かる）」止まりになります。ワークフローの中の「人の採用で解決しない部分」を生成AIサービスで解決できると「Must-have（無いと困る）」になります。
論点２「生成AI活用のハードル」
「ワークフローに組み込もう」と言いましたが、生成AIサービスを、ワークフローに組み込めるレベルで作り上げるのは、大変です。
「生成AI」は最先端でクールな印象がありますが、実際は、泥臭い作業だらけで、大きく４つの関門がありました。
フローの河
課題のある業務は、ワークフローが整っていないから、課題が発生しています。マクドナルドのマニュアルのように整備されておらず、人によってバラバラで属人化しています。
データの谷
特定業務で生成AIを活用するには、社内データが必要となることが多いです。しかし、データは様々なところに分散していたり、チャットで流れており蓄積されていなかったりします。
クオリティの崖
これは、最大の難関です。
最初のアウトプットの品質は低いです。現場の人がそのアウトプットを見て「これだと使えないね」と判断されたら、終わりです。信頼を再び獲得するのは大変です。
オペレーションの泥道
ワークフローの中で生成AIが活用され始めても、組織の成長に伴って、ワークフローやフォーマットは変わっていきます。そのアップデートについていかなくてはいけません。
・・・書いてるだけで疲れてきました。
論点３「生成AI活用ハードルを突破する方法」
たくさんハードルがあることが分かりましたが、これらを突破して、生成AIサービスを作る方法はあるのでしょうか？
唯一の方法は「生成AIサービスの企画者が、ワークフローに入り込む」ことです。まずは業務の解像度を上げ「人力AI」としてアウトプットします。
整備フェーズ（プロンプトデザイン）
生成AIシステムを企画する上では、まず「整備」をしますが、その手順はこのようになります。
1. ワークフローを、タスクに分解して言語化する
2. タスクを、人がやるタスクと生成AIサービスがやるタスクに分ける
3. 生成AIサービスがやるタスクの、思考回路を言語化する
4. その思考回路を、プログラムやプロンプトで、生成AIサービスに実装
これを「プロンプトデザイン」と言います。
その業務を行う手順や思考回路を言語化するのが大事ですが、人間が瞬時に行う判断の思考回路を言語化するのは、意外と難しいです。
そして、思考回路は「ハイパフォーマー」のものでなくてはいけません。
例えば「スケジュール調整をAIにやらせよう」と考えた時「参加者が空いている時間で最短を選ぶ」という思考回路を実装してはいけないということです。
ハイパフォーマーは、MTG参加者のスケジュール一覧を見ながら、
MTGの内容的に、午前に入れるか、色々落ち着いた遅い時間が良いか
MTGをいつ以降なら準備ができ、いつまでに実施すれば大丈夫なのか
出社状況や前後の予定からして、いつどこで実施すると負担が低いか
など、様々な思考をしており、一定ロジックに沿ってスケジュールを押さえます。この思考回路を言語化し、生成AIのプロンプトとします。
改善フェーズ（プロンプトエンジニアリング）
アウトプット品質の改善はとても重要なのですが、とても地味で地道です。このような手順で行います。
1. プロンプトを書いてAIシステムを実装
2. AIシステムでアウトプットしてみる
3. アウトプットを評価する
4. アウトプットに至る中間アウトプットを見ながら、どこで自分の思考回路と違ったのかを発見し、プロンプトを改善する
これを「プロンプトエンジニアリング」と言います。ビジネス職とエンジニア職が合体したようなものなので、なかなか難しいと思います。
企業での生成AI活用を成功させるには？
生成AI活用の道のりは、書いているだけで気が遠くなり、ここまでに１週間ほどかかりました・・・
最後に、企業で活用する生成AIサービスは、誰が開発するのが良いのでしょうか？
３つのパターンが考えられます。
企業内のAI推進室
企業内の事業部メンバー
AIソリューション事業を行う企業
まず「企業内のAI推進室」は難しいです。
ワークフローへの生成AI導入は、論点３で説明したように「ワークフローに入り込むこと」が必要になるため、「フローの河」で流されてしまいます。（経費精算のようなHorizontalな業務なら良いと思います。）
次に、事業部メンバーも難しいです。
目の前にある業務が優先され、生成AIシステムの品質改善をする余裕がなくなります。例えば、事業部のWikiが更新されなくなったりカオスになっていくのと同じです。「クオリティの崖」を登りきれません。
最後に、AIソリューション事業を行う外部企業も、難しい気がします。
お金を払って開発はしてくれたとして、よっぽどのコミットメントがない限り、「データの谷」「クオリティの崖」で終わると思います。
・・・どれも難しいとなってしまいましたが（笑）、必要なのは「やり切る覚悟」です。
１番覚悟を引き出せるのは、外部企業に「利用量ベースで支払う」という従量課金契約パターンです。使われなければ料金が発生しないので、必死に品質を上げ、オペレーションに食らいつく力学が働きます。
企業内で行う場合にしても、覚悟を持ってやり切る座組みを考えられると良いと思います。
この記事が気に入ったらサポートをしてみませんか？