スモールライフ株式会社では、生成AIを単に文章作成に使うだけではなく、実際の業務の中に組み込む取り組みを進めています。
今回、某デザインスクールでの業務をきっかけに、生成AIを活用した「生徒管理アプリ」を開発しました。
スクールでは、日々の生徒さんとのやり取りや、質問、進捗、相談内容などがSlackに蓄積されています。
情報は残っているのですが、人数が増えてくると、
「この生徒さん、最近どんな状況だったっけ？」
「前回、何について困っていたんだっけ？」
「次に声をかけるとしたら、何を確認すればよかっただろう？」
といったことを、過去のSlackをさかのぼって確認する必要があります。
そこで、蓄積された情報を生成AIに整理してもらい、生徒さんごとの状況をすぐ確認できる仕組みを作ることにしました。
どんなアプリなのか
アプリを開くと、生徒さんを選択して質問できます。
たとえば、
- 最近の状況をまとめて
- 未解決のことはある？
- 次回フォローした方がよいことは？
といった質問をすると、過去の記録からAIが情報を整理して回答します。
AIの回答だけで終わらせない
今回のアプリでは、AIによる要約だけではなく、その下に実際のSlackの原文も時系列で表示するようにしました。
新しい書き込みから順番に、
- 投稿日
- 書き込んだ人
- 実際の文章
を確認できます。
対象となる生徒さんの名前はハイライト表示されるので、原文の中から該当箇所も見つけやすくしています。
つまり、
AIの回答を読む → 気になったらすぐ原文を確認する
という使い方ができます。
これは最初から決めていた仕様ではありません。
実際に何人かの生徒さんについて使ってみたところ、
「AIがこうまとめているけれど、元の文章も一緒に確認できた方が安心だな」
と感じました。
そこで、あとから原文表示を追加しました。
今回の開発では、こうした実際に使ってみて初めて分かったことを、その都度アプリへ反映しています。
個人情報を外部の生成AIへ送らない
今回、もっとも重視したのは個人情報の扱いです。
Slackには当然、生徒さんの名前や学習状況、質問内容などが含まれています。
こうした情報を、そのまま外部の生成AIサービスへ送ることは避けたいと考えました。
AIはMacの中で動かす
そこで今回は、AIをインターネット上で動かすのではなく、Macの中だけで動くローカルAIを利用しています。
モデルはQwen + Ollamaです。よく使われている組み合わせだそうです。
SlackのデータはMac内へ保存し、その内容をMac内で動くAIに読ませます。
AIによる分析もMac内で完結するため、生徒さんの情報を外部の生成AIへ送る必要がありません。
生成AIを業務で使う場合、性能だけでなく、
「どのデータを、どこで処理するか」
を設計することが非常に重要だと感じています。
どのような技術を組み合わせたのか
今回のアプリでは、いくつかの技術を役割ごとに使い分けました。
通常のプログラムは正確な処理を担当
中心となるのはPythonです。
Pythonには、
- Slackデータの取得
- 生徒ごとの情報検索
- 日付順の整理
- 名前の管理
- キャッシュ
- 安全判定
といった、正確さが必要な処理を担当させています。
生成AIは「意味を理解する部分」を担当
一方で生成AIには、
- 文章の意味を理解する
- 状況を整理する
- 要点をまとめる
- 自然な文章で回答する
といった、人間の言葉を扱う部分を担当させています。
この役割分担が重要でした。
すべてを生成AIに任せるのではなく、
機械的に処理できることは通常のプログラムで処理し、意味の理解だけをAIに任せる
ようにしています。
ブラウザから使えるようにした
画面については、Pythonから簡単にWebアプリを作れる仕組みを利用しました。
そのためブラウザ上で、
- Slackを更新
- 生徒を選ぶ
- AIに質問する
- 原文を確認する
といった操作ができます。
最終的にはMacのデスクトップにアプリのアイコンを置き、ダブルクリックするだけで起動できるようにしました。
毎回ターミナルでコマンドを打つ必要はありません。
AIの回答を「正解」にしない
開発していて、かなり重要だと感じたことがあります。
生成AIは便利ですが、必ず正しいとは限りません。
特に今回のSlackのような文章では、
「誰が何をしたのか」
が曖昧なケースがあります。
人間でも迷う文章をAIだけに決めさせない
たとえば、
「本人に説明した」
と書かれていても、その「本人」が誰なのか、前後を読まないと分からない場合があります。
人間でも判断が難しい文章を、AIだけに完璧に判断させようとすると無理があります。
そこで今回は、AIに無理をさせない設計にしました。
誰について書かれた記録なのかが明確なものだけをAIの回答に使用し、曖昧な記録はAIの判断材料から外します。
ただし、その文章自体を削除するわけではありません。
画面上では、
「AI回答には使っていないが、原文としては確認できる」
ようにしています。
AIは整理を担当し、最終確認は人間が行う。
この役割分担にしています。
難しかったのは「名前」と「主語」
今回、技術的に意外と難しかったのが人物の扱いでした。
Slackの中では人が「ID」で保存されている
Slackの内部データでは、書き込んだ人が名前ではなく、ユーザーIDで保存されています。
そのままでは、
「この文章を書いたのは誰なのか」
が分かりません。
そこでSlackからユーザー情報を取得し、ユーザーIDと実際の名前をローカルで対応付ける仕組みを作りました。
これによって、画面上では、
「書き込んだ人：○○さん」
と表示できるようになりました。
生徒さんの名前には表記揺れがある
生徒さんの名前も、いつも同じ表記で書かれるとは限りません。
名字だけで書かれることもあれば、呼び方が違うこともあります。
そのため、生徒ごとに複数の呼び方を登録して検索できるようにしました。
こうした細かい部分は、実際の業務データを扱ってみないと見えてきません。
新しい生徒やスタッフも検出する
さらに、新しい生徒さんやスタッフが増えた場合に、毎回手作業で名簿を更新するのも面倒です。
そこで現在は、Slackの中に今まで登録されていなかった人物が現れた場合、「新しい人物候補」として表示する仕組みも作っています。
スタッフは機械的に、新しい生徒はAIで候補抽出
スタッフについては、Slackの投稿者情報から検出できます。
一方で生徒さんは、Slack本文の中に名前として登場します。
そこでローカルAIがSlack本文を読み、
「これはまだ名簿に登録されていない生徒さんではないか」
という候補を抽出します。
ただし、AIが見つけた人物を自動的に名簿へ登録することはしません。
画面上に候補を表示し、人間が確認して、
- 生徒として追加
- スタッフとして追加
- 無視
を選びます。
ここでも、AIに最終判断を任せない設計にしています。
「完璧に設計してから作る」をやめた
今回の開発で、もう一つ強く感じたことがあります。
最初から完璧なシステムを設計しようとすると、なかなか完成しません。
「こういうケースもあるかもしれない」
「こんな問題も起きるかもしれない」
と考え始めると、機能もテストも増え続けます。
まず動かして、使ってから直す
そこで途中から方針を変えました。
まず、最低限安全に動くものを作る。
そして実際に使ってみる。
使ってみて、
- 原文も見たい
- 投稿者の名前も表示したい
- 新しい生徒を自動で見つけたい
という具体的な要望が出たら、その機能を追加する。
この繰り返しです。
実際、原文表示も、投稿者名表示も、新しい人物の検出も、最初から計画していたわけではありません。
使ってみたから必要性が分かりました。
生成AIを使った開発では、この進め方が非常に相性がよいと感じています。
生成AIを「判断者」ではなく「補助者」にする
今回のアプリでは、生成AIそのものを主役にはしていません。
役割を整理すると、
Slackは事実の原本。
通常のプログラムは正確な処理。
生成AIは意味理解と整理。
人間が最終判断。
という構成になっています。
生成AIが登場すると、
「何でもAIにやらせよう」
と考えがちです。
しかし実際には、従来のプログラムと生成AIを組み合わせ、それぞれ得意な仕事を担当させる方が、安定したシステムになります。
今回の生徒管理アプリは、その一つの実例になりました。
生成AIで小さな業務アプリを作るハードルは下がった
今回のアプリは、大規模なシステムではありません。
一人の担当者が日々の業務で使う、小さな業務支援ツールです。
しかし、こうした小さなツールこそ、生成AI時代には大きな可能性があると感じています。
これまでは、
「欲しいけれど、わざわざシステム開発会社へ依頼するほどではない」
という業務改善がたくさんありました。
今は生成AIを活用することで、実際の仕事をしながら、
「ここが不便だ」
「こうなったら便利だ」
という要望を、そのままアプリへ反映しやすくなっています。
スモールライフ株式会社では今後も、生成AI単体の活用だけでなく、既存の業務データ、従来のプログラム、ローカルAIを組み合わせた実践的な業務改善を試していきたいと考えています。