この記事では社内で生成AIアプリケーションの導入と実装を経験した話をしようと思う。
新卒で入社してから２年。比較的大きなプロジェクトで先日やっとリリースできた。
個人的に前進があった一方で、反省点も多いので、今後生成AIの導入の担当となる人の参考となれば幸い。
どんなプロジェクトだったのか
社長の一声で始まった
「生成AIを使って社員みんながより働きやすくできないか」と言う社長の一言から始まった。
その時の自分が感じていた課題として「業務の質問をしたくても、みんなが忙しそうで聞きづらい」「同じことを何度も聞いては申し訳ない」と言うストレスを感じていた。
あと、会社の手続き系を入社時に説明しても結局忘れてしまって何度も質問することになり、二度手間になってしまう事例が周りで多かった。
ここから、「会社の手続き等の基本情報を逐一確認できるAIツールがあったら目眩く未来が待っているんじゃないか」と思って、今回のプロジェクトを企画した。
ちなみに2回挫折した。
ちなみに2回挫折した。
1回目はエンジニアを捕まえて外注して始めたんだけど、このエンジニアが飛んでしまった。これは自分のマネジメント能力の欠如。
2回目は1から自分で実装しようとし過ぎてしまい、社内にデプロイするまでの道のりの遠さに挫折した。
そして今回3回目。ついに成功することになった。
後述するんだけど、Difyとの出会いとちゃんと知識のある人とコミュニケーションをとれたことが大きかった。
実装したもの
先に言っておくと大したものは作っていない。
作ったのは、社内文書をベクトルデータベースとして構築して、RAGによってユーザーの質問に対して回答を生成するChatBot。
あと、社内文書を扱う関係上、簡単にIP制限をかけた。
この過程でDockerを用いてDifyを自社のAWSサーバー上に構築した。
実装までの流れ
ステップ①｜クラウド版のDifyでやろうとしていることが可能か検証
クラウド版のDifyを使って自分がやろうとしていることが可能なのかを検証した。
社内文書を模したモデルデータを作成してそれを使ったRAGを構築した。
この時にはDifyのRAGの精度に感動したことを覚えている。
と言うのも、この前段階で自分でRAGを作ってみたこともあったんだけど、精度がめっちゃ悪かった。今考えるとチャンクの分け方が良くなかったんだけど、精度が高いRAGが簡単に構築できることに感動した。
ステップ②｜技術担当と壁打ち
ここで2回目までと大きく異なる工程が生まれる。社内の技術系の部長と壁打ちをすることができた。
振り返ってみるとここでの壁打ちが完成におおきく効いていた。
と言うのも、実装の工程の全体像をイメージできたからである。
また、社内のネットワーク要件として、IPでの制限をかける必要があることもこの段階で判明した。
ステップ③｜IP制限をかけるための勉強
まず、Difyをオンプレで作動させることができることを学習。
これをAWS上に構築することによって最低限セキュアな状態を作ろうとした。
ここでAWSを勉強した。正直完全にオーバーワークなくらいやってしまったのは反省。
ちなみにこの時にめっちゃお世話になったのは以下の記事と書籍。
ステップ④｜勉強したことを踏まえて技術担当に壁打ち
勉強したことを総動員して色んな人に壁打ちした。ネットワーク担当者とか、技術系のトップの人とか、生成AIツールとかAWSの知識に明るい人とか。
先にオーバーワークなくらい勉強したと言ったんだけど、この時の壁打ちで「こいつ本気だ」感が出せたのでまぁよしとする。
で、自分は驚いたんだけど、管轄の人と話すと驚くほど話が前に進む。
次に自分がどう動くのかが見えてくるのでそれに従って準備をしていった。
ステップ⑤｜実装〜テスト
ここからは実装を行なった。基本的には学習した内容を踏まえて、最初に構築していたアプリを再度構築するだけだった。
この段階で自分は各部署の責任者陣にアプリケーションを配布して実際に使ってもらった。
ここでテストしたのはよかった。自分では見過ごしていたたくさんのミスとかバグ、使いづらさに気がつくことができた。
ここでもらったFBを元に修正を続けていった。
ステップ⑥｜デプロイ
FBを一通り直したらデプロイをした。
「あのツール使ってみたよ！」と言われるとやっぱり嬉しい。
ただ、使う人が増えると多くの改善案をもらう。
今必死で修正をしているところ。
気がついたこと（学び）
このプロジェクトは自分の中で気がつくことが多かった。
便利なツールは積極的に使っていくべき
世の中の便利なものはどんどん使っていくべきだと思った。今回で言えばDify。
非エンジニアのくせにノーコードツールを使うと自分の介在価値が低いんじゃないかと思ってちょっと二の足を踏んでいた。
そんな自分を踏んづけたい。
今では考え方が変わって、大事なのは課題を解決すること。そして、そのスピード。
あと、ノーコードツールであっても使いこなすためには基本的な知識や理解が不可欠になる。
協力者の存在が偉大｜一人でやってはいけない
過去の失敗の根幹は「自分でなんでもやらなきゃ」精神にあった。
これも、自分一人でやらないと自分の介在価値が目減りするんじゃないかと思って人に頼れなかった。
でも、人に頼ると何倍も早くことが進んだ。そして今回も頼らなければ完成させることができなかった。
仕事は一人でやってはいけない。頼れる部分は頼って、早く目的地に辿り着けた方がいい。
反省点
とはいえ、かなり反省点が多いのも事実。
動きが遅い。完成したときには時代はAIエージェントへ…
先述の通り、このプロジェクトは2回挫折している。
なんなら1回目はDifyがまだ登場していなかった。
せめて2回目のタイミングで完成できていたらまだ時代の流れに乗っていたかもしれないんだけど、完成したタイミングではOpenAIのOperatorとかAIエージェントの時代になっていた。
動きが遅かったのは大きな反省点になっている。
手段が先行している。課題の本質はつけていない。
これはプロジェクトの本質的な部分なんだけど、今回のアプリケーションは課題の本質をつけていないと思う。
もし課題の本質を解決していたら、デプロイしたタイミングでもっと使われているはず。
原因は「生成AIのアプリケーションを社内に作る」と言う手段から先行したモチベーションになってしまっているため。
「何を解決するのか」と言う部分を起点にしてプロジェクトを進めていかないと実装のタイミングでズレが生じてしまうこともわかった。
保守運用の部分をそんなに検討していなかった。
これは今めっちゃ苦しんでいること。
格納しているデータの更新についてほとんど検討せずにデプロイしてしまった。
今はほぼ脳筋状態で保守運用をしているが、もっとスマートにできるはずだと思っている。
ここら辺をもっと検討しておくべきだったなと。。。
（そう思いながらデバッグしている）
今後のために
とはいえ一つのプロジェクトをやり終えた。
そんな自分に向けて言いたいのは「動き続けろ」と言うこと。
偶然にも自分が働く環境は変化のスピードが速い業界で働いている。だからこそ、迷ったり悩んだりする暇はない。
やると決めたらやる。そしてそのスピードを担保するために便利なものはどんどん使っていくし、人にもどんどん頼る。
そのために普段から勉強する必要があるし、人とのコミュニケーションもしっかり取っていく必要がある。
がんばれ。
