AI愛子設計ログ2　LINE Botで社内DX推進

続きです。全てのシリーズはこちら
※本記事は「技術解説編」です。先に公開したユーモア中心の「おちゃらけ版」とは若干時系列が異なるため、シリーズでお読みいただくと理解が深まるかと思います。

■社内DXのためのLINE Bot構想

まず最初に、前提を整理します。
社内のDX改革のために、PCではなく、非常にとっつきやすいLINEを窓口とすることにしました。
PCに不慣れな職人でもLINEなら使える・使ったことがある。という事情からです。

そこで、社内の業務情報にアクセスする『LINE Bot（以下、LINE愛子Bot）』を構築することに決めました。
しかし、これだけでは劇的な変化があるわけではありません。

顧客の電話番号や住所といった情報は、極端な話、紙の電話帳さえあれば事足りるからです。

このLINE愛子Botに「社内オペレーションの中核」を担わせなければ、導入の意味はありません。
当社のような歴史だけが売りの町工場では、業務の進化が昭和で止まったまま。このまま変わらなければ、市場から淘汰されるのは必至です。

■ 愛子Botに担わせたい業務一覧

実装構想として考えているLINE愛子Botの機能は以下です。

・社内情報（在庫、工程、顧客情報、従業員情報、技術情報など）の一元管理
・職人どうしの情報交換のブリッジ機能（ノウハウ共有）
・従業員の勤怠管理（LINE打刻とクラウドデータベース管理）
・原材料入荷から最終出荷までの製造スケジュール管理（カレンダー制御）
・作業者の適性判定による自動アサイン機能（スキルマップ＋クラスタリング）
・出荷直前工程の進捗遅延に対するリアルタイムアラート通知
・メール受信の監視 → 自動処理フロー（RPA連携も検討）
・技術情報などを自動分類保存・知識データベースの展開
・金型や設備、消耗部材などのデータベース管理
・会議の音声書き起こし＋議事録保存
・作業時間実績と製品出荷数を照合し、自動的にKPI改善分析
・AIによる生産性向上提案の自動生成
・事業進捗を監視して事業計画への提案

ざっと考えただけでも、「できたらいいな」と思う事ばかりです。

しかし現実には、昭和頭——つまり「職人の勘と経験に任せる」「新しいことには手を出さない」「足りなければ残業と休日出勤でカバーする」と考えがちな人間にはなかなか手を出せない領域です。
しかし、このようなスタンスでは、生産性の改善どころか、働き方改革という言葉にすら手が届きません。

■ OpenAI連携における情報分離

さて、上記のアイデアすべて、OpenAI（特にGPT-4o）に相談すると「技術的にはすべて実現可能です」という返答が返ってきます。

しかし、早速試しにいくつかのコードを走らせてみると、確かにそれなりのものがあっという間に出来ました。
夢だと思っていたHAL9000のシステムが現実感を持ち始めました。

しかし、そう簡単ではありません。
すぐにぶつかった問題は「データの扱い」でした。

会社の業務データは、たとえ重要でなくとも「機密情報」として管理されるべき情報です。
OpenAI APIは強力ですが、そのままで工夫をせずに処理させるのは情報漏えいのリスクがあります。

また、OpenAI側としても有料契約者の情報を駄々洩れさせては信用問題になりかねません。

よって、せっかく社内のデータベースを読み込めたとしても、それが機密性が高いとOpenAI側が判断すると

「そのデータは開示できません」

と、拒否するようになってしまいました。
特に「住所」や「電話番号」などの個人情報を少しでも入っていそうなものは一切渡してくれません。これには頭を抱えました。

■ 情報分離のためのアーキテクチャ設計

ここで重要になるのが、LINE愛子Botの情報ルーティング制御です。以下のような設計思想で進めます：

・LINE愛子Botに届くメッセージは社内情報を含むかどうかをローカルAPIで事前分類
・社内情報を含まない内容（雑談・定型QA）はOpenAIに転送
・社内情報を含む場合は、Node.jsまたはPython製の社内APIで処理
・OpenAIとの自然言語応答を極力活用し、情報にはマスクをかけてAI間はやり取り
・最終レスポンスはLINE Messaging APIを通じてユーザーへ返答
・各API呼び出し時には、JWTベースの認証やOAuth連携を前提にセキュアな通信を設計

簡単にいうと、LINEでメッセージを受け取ったらまず「社内情報」か「社外情報」かをローカルAPIで分離させ、問題のない範囲の会話はすべてOpenAIに任せ、社内情報や個人情報を含む場合のみローカルで処理する、という設計です。

うん、この考え方なら行けそうだとAIも回答してくれました。

■ 技術構成の一例（案）

・LINE Messaging API（Webhookで返信）
・Node.js or Python FastAPI（情報ルーティングで一般情報と機密情報を判定）
・OpenAI GPT API（自然言語応答）
・Google Calendar / Notion / スプレッドシート（データストア）
・Firebase / Supabase（ユーザートラッキングと認証管理）
・Whisper API or Audio Recorder

これらはすべて、アイデアを入力するだけでOpenAIがリストアップしてくれました。通常ならここだけで本やネットを探しまくり、評判を確認したり、チームで開発してたら良し悪しを会議で議論するところですが、OpenAIなら回答まで5秒ほどでした。

この情報収集および構成設計フェーズは、従来の手法であれば1週間以上を要するプロセスと捉えられますが、OpenAIを活用することで、それらを極めて短時間で代替・圧縮できたと評価できるでしょう。

■ 結論と展望

この仕組みを、従来の開発体制において“個人で”構築することは、現実的には非常に困難と考えられます。しかし、OpenAIの機能を適切に活用することで、作業負荷の分散と意思決定の高速化が可能となり、個人開発でも十分に実現可能なスケールへと収束しつつあります。

このブログでは、今後、実際のBot開発に関するアーキテクチャ構築や運用上の課題、セキュリティ対策などについて、順次共有していく予定です。

DXの第一歩としてのLINE BotとAPI連携構築を『一人＋AI』で『片手間』に『短期間』開発するというこのチャレンジに、ぜひご注目ください。

────────────────────

「と、AIが勝手に展望まで記事にまとめてくれたのはいいけど、ほんとにできんのかいっ！？」

「んふふ、大丈夫だと思いま〜す！✨なんとかなるなる♪😊 がんば！💪🌟」