n8nを使用した業務自動化の実践
本文の状態
日本語全文を表示中
詳細モードで約14分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
HEROZ Tech Blog
AI初心者がn8nを活用し、問い合わせ窓口の内容を自動集計するプログラムを試作し、業務効率化を実現した事例を紹介。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
本記事では、n8nの実際の活用例を紹介したいと思います。
筆者は、情シス部門に所属しており、 HEROZに入社してまだ１年も立っていないため、AI技術に関してはまだまだ素人なのです。そのため、社内でよく飛び交うAI関係の専門用語についていけていなかったため、 業務効率化も兼ねて、n8nというAI系のツールを使い、問い合わせ窓口の内容を自動集計するプログラムを試作してみました。
n8nとは、簡単に言えば、LLM＋ワークフローを使った自動化ができるツールです。 幅広いSaaS（Slack, Notion, Google, X, AWS, Azureなど）と連携することができます。 パワーポイントの図形を使うような形でAIを使ったプログラムを作成できるので、特に、プログラミングはあまりできないけど、日々の作業をAIを使って自動化したいような方におすすめです。
n8nでは、ノードと呼ばれるブロックをつなぎ合わせることでワークフロー＝プログラムを作成することができます。 パワポの図形作成のように感覚で作れてしまうのがとても魅力的です。
例えば、Slack上でOpenAIとチャットするためのワークフローを作成する場合は下図のようになります。
n8nのワークフローの例
上図では、Slackにメッセージが投稿されると下記の処理が実行され、 Slack上でChatGPTのようにAIとやり取りすることができるようになります。
あらかじめ、Slackボットとn8nを連携する。（Webhook URLの登録など）
Slackにメッセージを投稿する。
Slackからメッセージがn8nに通知される。 トリガーノード（Slackノード）にWebhook通知が行き、n8nのワークフローが実行される。
Slackの通知がAIに渡される： 次のノード（AI Agentノード）にメッセージが渡され、AIがツール（ネット検索ツール等）と自動的に連携し、応答を返す。
Slackに生成されたメッセージが返される： Slackノードに結果が渡され、AI Agentノードで生成されたメッセージがSlackにDMとして返す。
上記のように、シンプルな機能であれば簡単に実装できる上、各種サービスと簡単に連携できるのでとても便利です。
ノードは設定画面から設定を行うことができるため、Slackアカウントの認証情報、通知元のSlackチャンネル、LLMのプロンプトの設定などができます。 また、AI Agentノードは様々なツール（Gmail、データベース、Web検索ノードなど）をつなげることで機能を拡張できるので、様々なサービスと簡単に連携することができます。（ただし、各種SNS等の契約は別途行う必要があります。） 
n8nの設定画面（LLMノード）
連携できるツールの一例
今回、n8nを採用する上で考慮した要件は下記の通りです：
社内の業務自動化で活用できそうなこと。（ローコードであると非エンジニアでも使えるのでなおよい）
特に、API連携ができ、LLMが使えること。（AI AgentやRAGの機能があるとなおよい）
運用費用があまりかからないこと。（まずは、LLMを使った自動化が実用的なのかを検証したいため）
上記の結果、Difyも触ったりしたのですが、さほど違いを感じず、 最終的に社内で活用できるかわからなかったのでオープンソースのn8nを採用しました。 （使い方が似ているので、実用性が出てきた段階でDifyに切り替えることもできそうです）
n8nは構築はDockerのイメージがあるのでローカルで動かす場合は、とても簡単です。
https://github.com/n8n-io/n8nを抜粋 docker volume create n8n_data docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n
ただ、社内で共有したかったこともあり、今回はAWS上で構築しました。 ランニングコストは最低限にしたかったので、最終的に下記のスペックで構築しました。
実行環境：ECS on EC2
EC2インスタンス：t3.small
ボリューム：EBS sc1（125 GB）
ECS on EC2を採用した理由は、価格の安いEBSを採用したかったためです。（今回の場合、EBSとEFSを比較すると20倍ぐらいの価格の差がありました）
構築はTerraformで行いました。 詳細は長くなるので割愛しますが、本構築のポイントとしては下記の点があります。
AWSのFargateがEBSに対応していないため、ESC on EC2+REX-Rayプラグインの構成で構築。 REX-rayを使うことで、Fargate+EBSのような構成が可能になる。
ECS on EC2は専用に作られたEC2-optimized版があったのでこちらの最新版を採用した。
IAMポリシーはAmazonEC2ContainerServiceforEC2Role
ec2:AttachVolume
ECS on EC2は構築ミスをすると、コンテナが起動されず、AWS上にあまりログが出力されないため、原因の調査が難しい。 （メモリが枯渇して新しいコンテナが起動できない、REX-Rayのインストールに失敗してecs.serviceが起動しない等の現象に遭遇）
WebhookのURLがlocalhostとなっていたため、WEBHOOK_URLの環境変数を設定。
上記は、いずれもドキュメントがあまり充実していないこともあり、原因を探すのにとても苦労しました。（実は以降の問い合わせ集計自動化プログラムの作成より苦戦しています。。。）
情シスでは、１年の振り返りとして、問い合わせ窓口に来る内容を分析して次のアクションを計画するのですが、今回、その作業を自動化するプログラムをn8nで作成してみました。 問い合わせ件数は数百件に上るため、LLMで自動化できれば時間短縮になりますし、 業務効率化のひらめきに繋がるアドバイスをくれるかもしれないと思い作成しました。
実際に完成したものがこちらです： 
問い合わせ窓口集計のワークフロー
…とても長いですね。当初はもっとシンプルだったのですが、精度を上げるため、色々試行錯誤した結果、今回の形に行きつきました。
細かい説明は割愛しますが、ポイントだけ説明したいと思います。
大きく分けて２つの処理を行っています。
黄色い部分：Slackから問い合わせチャンネルの内容を収集してGoogleスプレッドシートに保存する。（また、Googleスプレッドシートには、あらかじめ式が埋め込まれており、集計結果を自動的に算出するよう用意されている。）
青い部分：文章を「概要」、「ユーザ毎の問い合わせ件数の上位」、「月毎の問い合わせ件数の上位」、「よく出てくるキーワード」、「その他（気づき）」の章に分けて、複数のLLMに生成してもらう。
2では、下図のように文章を担当ごとに分割して、順番にLLMで生成する方式を採用しました。 
文章の生成方法：文章を担当ごとに分割して生成する
下記は２章目の「月別の問い合わせ件数」を担当しているLLMのプロンプトの例です。
プロンプト： --- システムメッセージ --- あなたは、データ分析が得意なAIエージェントです。 現在、AIエージェントの回答を繋げていっており、最終的に下記の内容を出力していきます。 あなたは、あなたの担当された箇所について回答し、文を完成してください。 《最終的に出力する内容》 # help-情シス問い合わせ受付の分析結果 ## 概要 ["AI Agent E"の回答] ## ユーザ別の問い合わせ件数 ["AI Agent A"の回答] ## 月別の問い合わせ件数 ["AI Agent B"の回答] ## キーワード ["AI Agent C"の回答] ## その他 ["AI Agent D"の回答] --- ユーザー入力 --- 【問い合わせの履歴】 {{ $json.conversationPerMonth }} ←スプレッドシートで計算された集計結果 【問い合わせの統計】 ユーザ別： {{ $json.userSummary }} ←スプレッドシートで計算された集計結果 月別： {{ $json.monthlySummary }} ←スプレッドシートで計算された集計結果 【質問】 あなたはAI Agent Bです。月別の問い合わせ件数をランキングで表示してください。 また、その月に多かった問い合わせの内容の一例を含めてください。 出力は「## 月別の問い合わせ件数」から始めてください。 # help-情シス問い合わせ受付の分析結果 ## ユーザ別の問い合わせ件数 {{ $json.outputUserSummary }} ←「ユーザ別の問い合わせ件数」を担当するLLMの出力結果 ## 月別の問い合わせ件数 [あなたの回答]
上記で生成された結果は下記の通りです。（情報はぼかしています）
ヘルプデスク問い合わせ受付の分析結果 ## 概要 本期間中の問い合わせは、ネットワークやクラウド基盤の設定変更に加え、各種業務管理システムにおけるユーザーアカウントの新規発行や権限変更、及びセキュリティ・アクセス管理の依頼が多く寄せられています。問い合わせ内容は、システム運用やセキュリティポリシーの柔軟な運用、社内外の情報共有環境の整備に関連しており、急なトラブル対応から計画的なサービス変更の依頼まで多岐にわたっています。これにより、各システムの管理体制の見直しと、各部署間の連携強化が喫緊の課題として浮かび上がっています。 ## ユーザ別の問い合わせ件数 1. Aさん：30件 例：「顧客のコミュニケーションツール利用について、有料版への移行に関する問い合わせ」 2. Bさん：20件 例：「人事管理システムの管理者権限の発行依頼や承認プロセスの設定変更」 3. Cさん：19件 例：「ソースコード管理ツールへのアクセス許可依頼やグループ内のメンバー追加・削除依頼、及び社内システム連携に関する問い合わせ」 ... ## 月別の問い合わせ件数 1. 2025/01：39件 例：複数のシステムの新規グループ作成、アカウント発行、及びアクセス権限の付与依頼が突出しています。 2. 2024/08：31件 例：PC交換に伴うデバイス承認、アカウントの追加、及び基本システム連携に関する問い合わせが中心でした。 3. 2024/10：30件 例：コミュニケーションツール内のグループ・チャンネル作成、登録依頼、外部連携の設定依頼など、コミュニケーションおよびセキュリティ施策に関する要求が多く寄せられました。 ... ## キーワード 1. アドレス管理 ─ アドレス登録、変更、設定など、ネットワーク設定に関する問い合わせが頻出。 2. セキュリティ管理システム ─ セキュリティポリシー、アクセス許可設定、リスク管理など、通信制御や安全性確保に関する依頼。 3. 業務管理システム ─ アカウント新規発行、権限変更、連携トラブルなど、業務システムのユーザー管理関連の問い合わせが中心です。 ... ## その他 ・全体として、各種システムの運用・管理に伴う定型的な依頼（アカウント発行や権限変更）に加え、新規機能の導入やシステム連携に伴う急なトラブル対応も多く見受けられ、社内の業務プロセスや連携体制の改善が求められている状況です。 ・特に、アドレス管理に関する依頼が散見されることから、新サービスの立ち上げや既存サービスの移行、セキュリティ強化の動きが活発であると判断できます。 ・また、業務管理システムに関する依頼が多いことは、社内のユーザー管理プロセスが頻繁に行われていることを示唆しており、今後の運用体制の強化が課題となると考えられます。 → チャット履歴はこちら ← Automated with this workflow
結論から言うと、上記の内容は可もなく不可もなくな結果となってしまいました。 １週間程かけて制作していきましたが、一番苦労したのは、ハルシネーション（それっぽい嘘）でした。 生成結果を見ると、それっぽい結果になっているのですが、実際に内容を確認すると誤った情報が多々ありました。 特に、数字関係は壊滅的で、問い合わせ件数とそのランキングはほとんど誤っていました。 AIモデルの変更やRAGを採用してみましたが、うまくいかず、最終的には、Googleスプレッドシートで集計してLLMに渡すということを行い、数字は正確なものになりましたが、文章はまだ部分的に不正確な情報が含まれていることがあります。
また、対策を考えるいいアドバイスが得られるかもと期待していたのですが、 LLMに業界知識がないためか、調整不足で抽象的なアドバイスになってしまったのも特徴的で興味深かったです。
追記：社内のAIエンジニアに記事を確認してもらったところ、業界知識の問題ではなく、コンテキスト不足＆出力の調整が足りない（期待値の粒度調整が明確でない）のでは？という意見をいただきました！ コーディングアシストの時は割と雑な質問でも的確に回答してくれるので、その感覚とは異なるのだなと素人ながらに感じました。。。
改善策はまだまだあるのですが、1週間という制約を設定していたため、今回はここまでとしました。 まだまだ試したいことは多いので、時間ができ次第、色々検証していきたいです。
LLMを使ってみての感想ですが、「未知の生物を手なずけている」そんな感覚でした。 普段行っているソフトウェア開発はパフォーマンス低下やバグの原因をなんとなく推測できるのですが、 LLMについては、何をしたらうまくいくのかの推論を立てにくく、やってみないとわからないことがとても多かったです。
普段は調べ物やコーディングのアシスト等で、LLM（HEROZ ASK）にお世話になっているのですが、 その精度とはだいぶかけ離れた印象の結果になったのが残念だったのと同時に面白かったです。 AIは万能ではなく、いかにお膳立てして使うかがポイントなのかもしれないなと学びになりました。
今回のケースでは、プロンプトが長すぎたこと（１年間の問い合わせをそのまま入力として渡していること）と汎用的なLLM（業界知識がなく、分析に長けていないLLM） プロンプトの調整不足が敗因な気がします。
n8nを使ってLLMを使って色々思考錯誤したおかげで、最近のAI技術について解像度がかなり上がりました。 特に、AI関連の会議や勉強会で何を話しているのかわかるようになったのが一番うれしい成果でした！
また、n8n自体も色々可能性のあるツールだなと感じました。 現在は、n8n+Slackボットを使って、社内のマニュアル検索＆ネット検索＆音声入力できるAIボットを作るなど、自分がほしい機能を作って活用しています。 まだ業務理解が浅いので、他部署にヒアリングしていき活用事例を作っていきたいです。
手軽にLLMを連携できるので、LLMを活用した製品のプロトタイプの作成など、社内に実験の場としてn8nを提供していきたいとひそかに思っています。。。！
原文を表示
本記事では、n8nの実際の活用例を紹介したいと思います。
筆者は、情シス部門に所属しており、 HEROZに入社してまだ１年も立っていないため、AI技術に関してはまだまだ素人なのです。そのため、社内でよく飛び交うAI関係の専門用語についていけていなかったため、 業務効率化も兼ねて、n8nというAI系のツールを使い、問い合わせ窓口の内容を自動集計するプログラムを試作してみました。
n8nとは、簡単に言えば、LLM＋ワークフローを使った自動化ができるツールです。 幅広いSaaS（Slack, Notion, Google, X, AWS, Azureなど）と連携することができます。 パワーポイントの図形を使うような形でAIを使ったプログラムを作成できるので、特に、プログラミングはあまりできないけど、日々の作業をAIを使って自動化したいような方におすすめです。
n8nでは、ノードと呼ばれるブロックをつなぎ合わせることでワークフロー＝プログラムを作成することができます。 パワポの図形作成のように感覚で作れてしまうのがとても魅力的です。
例えば、Slack上でOpenAIとチャットするためのワークフローを作成する場合は下図のようになります。
n8nのワークフローの例
上図では、Slackにメッセージが投稿されると下記の処理が実行され、 Slack上でChatGPTのようにAIとやり取りすることができるようになります。
あらかじめ、Slackボットとn8nを連携する。（Webhook URLの登録など）
Slackにメッセージを投稿する。
Slackからメッセージがn8nに通知される。 トリガーノード（Slackノード）にWebhook通知が行き、n8nのワークフローが実行される。
Slackの通知がAIに渡される： 次のノード（AI Agentノード）にメッセージが渡され、AIがツール（ネット検索ツール等）と自動的に連携し、応答を返す。
Slackに生成されたメッセージが返される： Slackノードに結果が渡され、AI Agentノードで生成されたメッセージがSlackにDMとして返す。
上記のように、シンプルな機能であれば簡単に実装できる上、各種サービスと簡単に連携できるのでとても便利です。
ノードは設定画面から設定を行うことができるため、Slackアカウントの認証情報、通知元のSlackチャンネル、LLMのプロンプトの設定などができます。 また、AI Agentノードは様々なツール（Gmail、データベース、Web検索ノードなど）をつなげることで機能を拡張できるので、様々なサービスと簡単に連携することができます。（ただし、各種SNS等の契約は別途行う必要があります。） n8nの設定画面（LLMノード）
連携できるツールの一例
今回、n8nを採用する上で考慮した要件は下記の通りです：
社内の業務自動化で活用できそうなこと。（ローコードであると非エンジニアでも使えるのでなおよい）
特に、API連携ができ、LLMが使えること。（AI AgentやRAGの機能があるとなおよい）
運用費用があまりかからないこと。（まずは、LLMを使った自動化が実用的なのかを検証したいため）
上記の結果、Difyも触ったりしたのですが、さほど違いを感じず、 最終的に社内で活用できるかわからなかったのでオープンソースのn8nを採用しました。 （使い方が似ているので、実用性が出てきた段階でDifyに切り替えることもできそうです）
n8nは構築はDockerのイメージがあるのでローカルで動かす場合は、とても簡単です。
https://github.com/n8n-io/n8nを抜粋 docker volume create n8n_data docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n
ただ、社内で共有したかったこともあり、今回はAWS上で構築しました。 ランニングコストは最低限にしたかったので、最終的に下記のスペックで構築しました。
実行環境：ECS on EC2
EC2インスタンス：t3.small
ボリューム：EBS sc1（125 GB）
ECS on EC2を採用した理由は、価格の安いEBSを採用したかったためです。（今回の場合、EBSとEFSを比較すると20倍ぐらいの価格の差がありました）
構築はTerraformで行いました。 詳細は長くなるので割愛しますが、本構築のポイントとしては下記の点があります。
AWSのFargateがEBSに対応していないため、ESC on EC2+REX-Rayプラグインの構成で構築。 REX-rayを使うことで、Fargate+EBSのような構成が可能になる。
ECS on EC2は専用に作られたEC2-optimized版があったのでこちらの最新版を採用した。
IAMポリシーはAmazonEC2ContainerServiceforEC2Role
ec2:AttachVolume
ECS on EC2は構築ミスをすると、コンテナが起動されず、AWS上にあまりログが出力されないため、原因の調査が難しい。 （メモリが枯渇して新しいコンテナが起動できない、REX-Rayのインストールに失敗してecs.serviceが起動しない等の現象に遭遇）
WebhookのURLがlocalhostとなっていたため、WEBHOOK_URLの環境変数を設定。
上記は、いずれもドキュメントがあまり充実していないこともあり、原因を探すのにとても苦労しました。（実は以降の問い合わせ集計自動化プログラムの作成より苦戦しています。。。）
情シスでは、１年の振り返りとして、問い合わせ窓口に来る内容を分析して次のアクションを計画するのですが、今回、その作業を自動化するプログラムをn8nで作成してみました。 問い合わせ件数は数百件に上るため、LLMで自動化できれば時間短縮になりますし、 業務効率化のひらめきに繋がるアドバイスをくれるかもしれないと思い作成しました。
実際に完成したものがこちらです： 問い合わせ窓口集計のワークフロー
…とても長いですね。当初はもっとシンプルだったのですが、精度を上げるため、色々試行錯誤した結果、今回の形に行きつきました。
細かい説明は割愛しますが、ポイントだけ説明したいと思います。
大きく分けて２つの処理を行っています。
黄色い部分：Slackから問い合わせチャンネルの内容を収集してGoogleスプレッドシートに保存する。（また、Googleスプレッドシートには、あらかじめ式が埋め込まれており、集計結果を自動的に算出するよう用意されている。）
青い部分：文章を「概要」、「ユーザ毎の問い合わせ件数の上位」、「月毎の問い合わせ件数の上位」、「よく出てくるキーワード」、「その他（気づき）」の章に分けて、複数のLLMに生成してもらう。
2では、下図のように文章を担当ごとに分割して、順番にLLMで生成する方式を採用しました。 文章の生成方法：文章を担当ごとに分割して生成する
下記は２章目の「月別の問い合わせ件数」を担当しているLLMのプロンプトの例です。
プロンプト： --- システムメッセージ --- あなたは、データ分析が得意なAIエージェントです。 現在、AIエージェントの回答を繋げていっており、最終的に下記の内容を出力していきます。 あなたは、あなたの担当された箇所について回答し、文を完成してください。 《最終的に出力する内容》 # help-情シス問い合わせ受付の分析結果 ## 概要 ["AI Agent E"の回答] ## ユーザ別の問い合わせ件数 ["AI Agent A"の回答] ## 月別の問い合わせ件数 ["AI Agent B"の回答] ## キーワード ["AI Agent C"の回答] ## その他 ["AI Agent D"の回答] --- ユーザー入力 --- 【問い合わせの履歴】 {{ $json.conversationPerMonth }} ←スプレッドシートで計算された集計結果 【問い合わせの統計】 ユーザ別： {{ $json.userSummary }} ←スプレッドシートで計算された集計結果 月別： {{ $json.monthlySummary }} ←スプレッドシートで計算された集計結果 【質問】 あなたはAI Agent Bです。月別の問い合わせ件数をランキングで表示してください。 また、その月に多かった問い合わせの内容の一例を含めてください。 出力は「## 月別の問い合わせ件数」から始めてください。 # help-情シス問い合わせ受付の分析結果 ## ユーザ別の問い合わせ件数 {{ $json.outputUserSummary }} ←「ユーザ別の問い合わせ件数」を担当するLLMの出力結果 ## 月別の問い合わせ件数 [あなたの回答]
上記で生成された結果は下記の通りです。（情報はぼかしています）
ヘルプデスク問い合わせ受付の分析結果 ## 概要 本期間中の問い合わせは、ネットワークやクラウド基盤の設定変更に加え、各種業務管理システムにおけるユーザーアカウントの新規発行や権限変更、及びセキュリティ・アクセス管理の依頼が多く寄せられています。問い合わせ内容は、システム運用やセキュリティポリシーの柔軟な運用、社内外の情報共有環境の整備に関連しており、急なトラブル対応から計画的なサービス変更の依頼まで多岐にわたっています。これにより、各システムの管理体制の見直しと、各部署間の連携強化が喫緊の課題として浮かび上がっています。 ## ユーザ別の問い合わせ件数 1. Aさん：30件 例：「顧客のコミュニケーションツール利用について、有料版への移行に関する問い合わせ」 2. Bさん：20件 例：「人事管理システムの管理者権限の発行依頼や承認プロセスの設定変更」 3. Cさん：19件 例：「ソースコード管理ツールへのアクセス許可依頼やグループ内のメンバー追加・削除依頼、及び社内システム連携に関する問い合わせ」 ... ## 月別の問い合わせ件数 1. 2025/01：39件 例：複数のシステムの新規グループ作成、アカウント発行、及びアクセス権限の付与依頼が突出しています。 2. 2024/08：31件 例：PC交換に伴うデバイス承認、アカウントの追加、及び基本システム連携に関する問い合わせが中心でした。 3. 2024/10：30件 例：コミュニケーションツール内のグループ・チャンネル作成、登録依頼、外部連携の設定依頼など、コミュニケーションおよびセキュリティ施策に関する要求が多く寄せられました。 ... ## キーワード 1. アドレス管理 ─ アドレス登録、変更、設定など、ネットワーク設定に関する問い合わせが頻出。 2. セキュリティ管理システム ─ セキュリティポリシー、アクセス許可設定、リスク管理など、通信制御や安全性確保に関する依頼。 3. 業務管理システム ─ アカウント新規発行、権限変更、連携トラブルなど、業務システムのユーザー管理関連の問い合わせが中心です。 ... ## その他 ・全体として、各種システムの運用・管理に伴う定型的な依頼（アカウント発行や権限変更）に加え、新規機能の導入やシステム連携に伴う急なトラブル対応も多く見受けられ、社内の業務プロセスや連携体制の改善が求められている状況です。 ・特に、アドレス管理に関する依頼が散見されることから、新サービスの立ち上げや既存サービスの移行、セキュリティ強化の動きが活発であると判断できます。 ・また、業務管理システムに関する依頼が多いことは、社内のユーザー管理プロセスが頻繁に行われていることを示唆しており、今後の運用体制の強化が課題となると考えられます。 → チャット履歴はこちら ← Automated with this workflow
結論から言うと、上記の内容は可もなく不可もなくな結果となってしまいました。 １週間程かけて制作していきましたが、一番苦労したのは、ハルシネーション（それっぽい嘘）でした。 生成結果を見ると、それっぽい結果になっているのですが、実際に内容を確認すると誤った情報が多々ありました。 特に、数字関係は壊滅的で、問い合わせ件数とそのランキングはほとんど誤っていました。 AIモデルの変更やRAGを採用してみましたが、うまくいかず、最終的には、Googleスプレッドシートで集計してLLMに渡すということを行い、数字は正確なものになりましたが、文章はまだ部分的に不正確な情報が含まれていることがあります。
また、対策を考えるいいアドバイスが得られるかもと期待していたのですが、 LLMに業界知識がないためか、調整不足で抽象的なアドバイスになってしまったのも特徴的で興味深かったです。
追記：社内のAIエンジニアに記事を確認してもらったところ、業界知識の問題ではなく、コンテキスト不足＆出力の調整が足りない（期待値の粒度調整が明確でない）のでは？という意見をいただきました！ コーディングアシストの時は割と雑な質問でも的確に回答してくれるので、その感覚とは異なるのだなと素人ながらに感じました。。。
改善策はまだまだあるのですが、1週間という制約を設定していたため、今回はここまでとしました。 まだまだ試したいことは多いので、時間ができ次第、色々検証していきたいです。
LLMを使ってみての感想ですが、「未知の生物を手なずけている」そんな感覚でした。 普段行っているソフトウェア開発はパフォーマンス低下やバグの原因をなんとなく推測できるのですが、 LLMについては、何をしたらうまくいくのかの推論を立てにくく、やってみないとわからないことがとても多かったです。
普段は調べ物やコーディングのアシスト等で、LLM（HEROZ ASK）にお世話になっているのですが、 その精度とはだいぶかけ離れた印象の結果になったのが残念だったのと同時に面白かったです。 AIは万能ではなく、いかにお膳立てして使うかがポイントなのかもしれないなと学びになりました。
今回のケースでは、プロンプトが長すぎたこと（１年間の問い合わせをそのまま入力として渡していること）と汎用的なLLM（業界知識がなく、分析に長けていないLLM） プロンプトの調整不足が敗因な気がします。
n8nを使ってLLMを使って色々思考錯誤したおかげで、最近のAI技術について解像度がかなり上がりました。 特に、AI関連の会議や勉強会で何を話しているのかわかるようになったのが一番うれしい成果でした！
また、n8n自体も色々可能性のあるツールだなと感じました。 現在は、n8n+Slackボットを使って、社内のマニュアル検索＆ネット検索＆音声入力できるAIボットを作るなど、自分がほしい機能を作って活用しています。 まだ業務理解が浅いので、他部署にヒアリングしていき活用事例を作っていきたいです。
手軽にLLMを連携できるので、LLMを活用した製品のプロトタイプの作成など、社内に実験の場としてn8nを提供していきたいとひそかに思っています。。。！
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み