はじめに

社内アプリ開発や業務改善の話をしていると、「APIで連携すればいい」「AIを使えば効率化できる」といった言葉を聞くことがあります。

言葉としては分かります。
ただ、実際に自分でAPI連携をしようとすると、認証、リクエストの形式、レスポンスの扱い、エラー時の確認など、思ったよりも考えることが多く、なかなか形にできないことがありました。

「こういう仕組みがあったら便利そう」と考えることはあっても、実際に動くものとして作るところまでは進められていませんでした。

今回は、そのまま考えだけで終わらせず、Makeを使ってLINE Botと自作APIをつなぎ、業務報告をAIでナレッジ化するプロトタイプを作ってみました。

作ったのは、業務中に発生した対応内容をLINE Botへ報告すると、AIが不足している情報を確認し、あとで検索できるナレッジとして保存する仕組みです。

この記事では、作成したBotの概要、Makeを使った理由、全体構成、FastAPI側の処理、AI判定、DB設計、詰まったところについてまとめます。

作ったもの

今回作ったものは、LINEで業務報告を送ると、AIが内容を確認し、不足している情報があれば追加質問してくれるBotです。

十分な情報がそろった場合は、報告内容を構造化してPostgreSQLに保存します。保存されたナレッジは、LINEから検索できます。

たとえば、ユーザーが以下のように送信します。

社内システムに入れない事象に対応しました

この内容だけでは、原因や対応内容が分かりません。そのため、AIが追加質問します。

どのようなエラーや状況でしたか？

ユーザーが原因や対応内容を回答すると、AIがナレッジとして十分かを判定します。問題がなければ、DBへ保存します。

保存後は、LINEから以下のようにメッセージを送ることで検索できます。

検索 VPN

検索結果として、原因・対応内容・次回確認事項が整理された形で返ってきます。

このBotでやりたかったこと

このBotでやりたかったことは、単にLINEの内容をDBに保存することではありません。

目指したのは、忙しい現場でも、あとから使える形で対応履歴を残せる仕組みです。

通常、業務対応のメモは次のようになりがちです。

VPN対応済み
社内システムログイン不可対応
プリンタ直した

このようなメモは、その場では意味が分かっても、あとから見返すと詳細が分かりません。特に後任者や別の担当者が見る場合、「何を確認すればよいのか」が分かりにくくなります。

そこで、AIに以下のような観点で内容を確認させることにしました。

何が起きたのか
原因は何だったのか
どのように対応したのか
対応後に何を確認したのか
次回同じことが起きたら何を確認すべきか

十分な情報がそろうまではDBに保存せず、不足している場合は追加質問する設計にしています。

なぜMakeを使ったのか

今回はMakeを、LINEとFastAPIをつなぐ中継役として使いました。

LINE Messaging APIを自前で直接FastAPIに接続する場合、Webhookの受信、署名検証、イベントJSONの解析、replyTokenの取得、Reply APIへの送信などを自分で実装する必要があります。

もちろん、FastAPIだけでも実装は可能です。しかし、今回の目的はLINE Messaging APIの周辺処理をすべて自作することではなく、業務報告をAIでナレッジ化する流れを試すことでした。

そのため、LINEとの接続部分はMakeに任せ、FastAPI側では以下の処理に集中する構成にしました。

AIによる不足判定
会話状態の管理
DBへの保存
検索処理
LINEへ返す返信文の生成

Makeを使うことで、LINE連携の入口と出口をシナリオとして扱えるため、自作API側の処理を整理しやすくなりました。

デモ動画

以下の動画では、LINEから業務報告を送り、AIが追加質問し、最終的にナレッジとして保存・検索する流れを確認できます。

動画内では、以下の流れを確認できます。

LINEから業務報告を送信
AIが不足情報を質問
ユーザーが詳細を回答
DBにナレッジとして保存
「検索社内システム」で保存済みナレッジを検索

全体構成

全体構成は以下です。

LINE
↓
Make
↓
FastAPI on さくらのVPS
↓
OpenAI API
↓
PostgreSQL
↓
Make経由でLINEへ返信

処理フロー

LINEから送られたメッセージは、Makeを経由してFastAPIへ渡しています。
FastAPI側では、検索コマンドなのか通常の業務報告なのかを判定し、必要に応じてOpenAI APIやPostgreSQLを呼び出します。

全体の流れは以下です。

このように、MakeはLINEとの送受信を担当し、FastAPIはAI判定・会話状態管理・DB保存・検索処理を担当する構成にしています。

役割は以下のように分けました。

要素	役割
LINE	ユーザーの入力・Bot返信
Make	LINEとFastAPIの中継
FastAPI	会話状態管理、AI判定、DB保存、検索処理
OpenAI API	報告内容の不足判定・構造化
PostgreSQL	ナレッジ保存
VPS	FastAPI、Nginx、PostgreSQLの実行環境

MakeはLINE連携の入口と出口を担当し、FastAPIは業務ロジックを担当する構成にしています。

Makeのシナリオ

Makeのシナリオは、以下の流れです。

LINEのメッセージを受信
HTTPモジュールでFastAPIへPOST
FastAPIから返ってきた reply_text をLINEに返信

HTTPモジュールでは、FastAPIに以下のようなJSONを送っています。

{
  "user_id": "LINEのユーザーID",
  "text": "ユーザーが送った本文",
  "reply_token": "LINEのreplyToken"
}

FastAPIからは、以下のようなレスポンスを返します。

{
  "status": "ok",
  "reply_text": "LINEに返信する文章"
}

Make側では、この reply_text を使ってLINEへ返信します。

この構成にすることで、Make側はLINEとの送受信を担当し、FastAPI側は受け取ったテキストに対する処理に集中できます。

FastAPI側の処理

FastAPI側では、主に以下の処理を行っています。

APIキーの検証
検索コマンドの判定
キャンセルコマンドの判定
未完了の会話があるか確認
会話ログをDBに保存
OpenAI APIで内容を判定
ask なら追加質問を返信
save ならナレッジとしてDBに保存

処理の流れは以下です。

LINEからメッセージ受信
↓
検索 / キャンセル コマンドか判定
↓
open状態の会話があるか確認
↓
会話ログを更新
↓
AIにナレッジとして十分か判定させる
↓
ask  → 質問をLINEへ返信
save → DBに保存して完了返信

最初の報告だけで保存できる場合もありますが、情報が不足している場合は status = open として会話を継続します。追加の回答を受け取った後、再度AIに判定させ、保存できる内容になった時点で status = closed に変更します。

AI判定の設計

AIには、ユーザーの報告内容がナレッジとして十分かを判定させています。

判定結果は、大きく2種類です。

ask  → 情報が不足しているため追加質問する
save → ナレッジとして十分なので保存する

AIからは、以下のような構造で結果を返すようにしています。

{
  "decision": "ask",
  "quality_score": 20,
  "missing_reason": "詳細な情報が不足している",
  "question": "エラーの具体的な内容は？",
  "raw_report": "社内システム接続不可対応",
  "error_detail": "",
  "cause": "",
  "solution": "",
  "next_action": ""
}

保存できる場合は、以下のような形になります。

{
  "decision": "save",
  "quality_score": 95,
  "missing_reason": "",
  "question": "",
  "raw_report": "社内システム接続不可対応",
  "error_detail": "社内システムを開こうとすると接続できなかった",
  "cause": "VPN接続が切れていた",
  "solution": "VPNに再接続し、社内システムにログインできることを確認した",
  "next_action": "次回はVPN接続状態、ネットワーク接続、URLの順に確認する"
}

特に意識したのは、「完了しました」だけでは保存しないことです。

たとえば、ユーザーが以下のように送った場合です。

VPNにログインして完了しました

この文章だけでは、何が起きたのか、なぜVPNが関係していたのか、対応後に何を確認したのかが分かりません。そのため、原因・対応・確認結果・次回確認事項が不足している場合は、追加質問するようにしました。

DB設計

PostgreSQLには、以下のような項目を保存しています。

カラム	内容
raw_report	件名・概要
error_detail	発生した状況
cause	原因
solution	対応内容
next_action	次回確認事項
line_user_id	LINEユーザーID
conversation_log	会話ログ
quality_score	AIの品質スコア
ai_missing_reason	不足理由
ai_last_question	最後にAIがした質問
status	open / closed / cancelled など

会話途中のデータは status = open として保持します。AIが保存可能と判断したら、status = closed に変更します。

検索時は、status = closed のナレッジだけを対象にしています。これにより、会話途中の不完全な情報は検索結果に出ないようにしています。

検索機能

LINEで以下のように送ると、DBから該当するナレッジを検索します。

検索 社内システム

検索対象は以下です。

件名・概要
状況
原因
対応内容
次回確認事項

検索結果は、LINE上で以下のような形式で返します。

#12 社内システム接続不可対応
状況: 社内システムを開こうとすると接続できなかった
原因: VPN接続が切れていた
対応: VPNに再接続し、正常にログインできることを確認した
次回: VPN接続状態、ネットワーク接続、URLの順に確認する

単なるメモではなく、あとから見た人が確認しやすいように、状況・原因・対応・次回確認事項を分けて返すようにしました。

実装の進め方

今回の実装は、AIに相談しながら進めました。

ただし、コードをそのまま使うのではなく、実際にVPS上で動かしながら、curl、ログ、DBの中身を確認して修正していきました。

特に、以下の点を確認しながら進めました。

MakeからFastAPIにHTTP POSTできているか
APIキーによる認証が通っているか
FastAPIがVPS上で起動しているか
OpenAI APIの判定結果が ask / save で返るか
AIの判定結果がPostgreSQLに保存されているか
LINEから検索したときに、保存済みナレッジが返るか

AIに相談することで実装の速度は上がりましたが、実際に動く形にするには、ログを見て原因を切り分ける作業が必要でした。

詰まったところ

「完了」だけで保存されてしまう

最初は、ユーザーが「完了」と送っただけでも、AIが保存してしまうことがありました。

しかし、後から使えるナレッジにするには、「完了」という結果だけでは不十分です。何を実施したのか、何が確認できたのか、なぜ解決したと言えるのかが必要です。

そのため、AIへの指示に以下のようなルールを追加しました。

「完了」「対応済み」「直った」「OK」だけでは save にしない。
何を実施したのか、何が確認できたのか、なぜ解決したと言えるのかが分からない場合は ask にする。

このルールを追加することで、内容が不足している場合は追加質問されるようになりました。

テストデータが検索結果に出てしまう

開発中は、curlでAPIを直接叩いて動作確認をしていました。その結果、テスト用のデータもDBに保存され、検索結果に出てしまうことがありました。

そのため、テスト用の line_user_id には test- から始まる値を使い、検索時に除外するようにしました。

本番利用とテスト利用を分けて考えることの重要性を感じました。

MakeとFastAPIの責務分担

最初は、どこまでをMakeで行い、どこからをFastAPIで行うべきか迷いました。

Make側で複雑な条件分岐や会話状態管理まで行うこともできますが、今回はAI判定やDB保存を含むため、FastAPI側に業務ロジックを寄せました。

結果として、MakeはLINEとの接続、FastAPIは業務ロジックという分担にしたことで、処理の見通しがよくなりました。

今後の改善

今後は、以下を改善したいです。

IT対応だけでなく、定型作業にも対応する
LINEユーザーIDをハッシュ化して保存する
検索精度を上げる
似たナレッジをまとめて表示できるようにする
将来的には、口語で入力した内容をより自然に整形できるようにする

現時点では、主にIT対応の記録を想定しています。定型作業や設備対応などに広げる場合は、AIに求める情報の種類を変える必要があると感じています。

まとめ

Make、LINE Bot、FastAPI、OpenAI API、PostgreSQLを組み合わせて、業務報告をAIがナレッジ化するBotを作りました。

今回のプロトタイプでは、以下の流れを実現できました。

LINEで報告
↓
AIが不足判定
↓
足りなければ追加質問
↓
十分ならDB保存
↓
LINEから検索

今回作ってみて、Makeは単にノーコードで処理を作るだけでなく、外部サービスと自作APIをつなぐ中継役としても使えると感じました。

また、業務報告をそのまま保存するのではなく、AIに不足情報を確認させることで、あとから使いやすいナレッジに近づけられる可能性を感じました。

最終的には、忙しい現場でも気軽に情報を残せるようにし、後任者や別の担当者が過去の対応内容を確認しやすい環境につなげていきたいです。