第5回｜社内SEの「これ、無駄じゃない？」から始まったAWS開発への挑戦
これまで、ローカルLLMやRAGの学習、Amazon QuickとSlackを活用した社内IT問い合わせチャットボットの構築について紹介してきました。今回は、少し違った切り口で、日々の業務の中で感じていた不便を解消しようとした取り組みについて紹介します。
社内SEとして仕事をしていると、
「この作業、もっと簡単にできないだろうか？」
「こういう仕組みがあれば便利なのに」
と思うことがあります。
今回紹介するのは、そんな日常の小さな疑問から始まった、故障機器の報告・管理システムの開発です。
最初は既存の社内システムを組み合わせて実現しようと考えていましたが、さまざまな制約があり、最終的にはAWSで仕組みを構築することになりました。私にとって、初めて本格的にAWSを使って業務システムを開発した経験になります。
1. 手書きノートで管理していた故障機器
従来、現場でIT機器が故障すると、故障した機器を倉庫内の所定の場所に置き、手書きのノートに故障内容を記載する運用でした。IT担当者は定期的に倉庫を巡回し、ノートに記載された内容を確認します。その後、必要に応じてベンダーへ修理を依頼するという流れです。
この運用には、以前から疑問を感じていました。
故障機器があるかどうかを確認するためだけに、IT担当者が倉庫へ足を運ぶ必要があります。また、ノートを確認するまでは、どのような故障機器が置かれているのかもわかりません。
さらに、故障内容だけでなく、機器固有の情報や設置場所などをSharePointの入力フォームへ登録する運用もありました。つまり、故障機器の情報が手書きノートとSharePointに分かれていたのです。
「故障機器の情報を事前に確認できれば、もっと効率的に対応できるのではないか？」
これが、今回の取り組みの出発点でした。
2. 最初に考えたのはWebフォーム
最初の構想は、それほど複雑なものではありませんでした。故障機器の置き場の近くにパソコンを設置し、利用者がWebフォームから故障内容を登録するというものです。
IT担当者はシステム上で登録状況を確認し、故障機器がある場合にだけ回収に向かいます。さらに、事前に故障内容がわかれば、現地で復旧できそうなのか、それともベンダーへの修理依頼が必要なのか、ある程度判断できます。
単に手書きノートを電子化するだけではなく、IT担当者が現地に行く前に必要な情報を得られるようにすることが目的でした。
SlackとSharePointを連携できないか？
検討を進める中で、故障機器の確認や報告は、協力会社の方が担当している業務だとわかりました。そこで、専用のWebフォームではなく、すでに社内で使用されているSlackを報告の入口として利用できないかと考えました。
具体的には、Slackから故障機器の情報を報告すると、その内容が自動的にSharePointへ登録される仕組みです。既存の環境を活用できれば、新たなシステムを用意する負担も抑えられます。
そこで調べたのが、MicrosoftのPower AppsやPower Automateでした。これらを使用すれば、SharePointとの連携を比較的簡単に実現できそうでした。ところが、社内ではPower AppsもPower Automateも使用が許可されていませんでした。
技術的には実現できそうでも、社内のルールによって利用できない。こうした制約も、社内SEとして業務改善を進める際の難しさだと感じました。
3. そもそもSharePointである必要はあるのか？
SlackとSharePointの連携が難しいとわかり、別の方法を考える必要がありました。そこで、改めて本当に実現したかったことを整理しました。
現場から報告された故障機器の情報を、IT担当者が倉庫へ行かずに確認できるようにすることです。
必要なのは、故障情報を登録できる仕組みと、登録された情報を遠隔から確認できる仕組みです。それなら、データの保存先はSharePointでなくても構いません。
故障機器の情報を保存するデータベースがあり、その情報を確認できれば、当初の目的は達成できます。既存の社内システムに無理に連携させるのではなく、必要な機能を持つ仕組みを自分で作ればよいのではないか。
そう考え、AWSを使ったシステムの構築に挑戦することにしました。
4. AWSで故障報告システムを構築する
今回構築した仕組みは、Slackを入口として、AWSで故障機器の報告内容を処理・保存するものです。
主に以下のAWSサービスを利用しました。
Slackから送信された故障報告は、API Gatewayを経由してLambdaで処理します。そして、故障情報をDynamoDBに保存する仕組みです。また、定期的に故障情報のサマリーをSlackへ通知する機能も実装しました。
これにより、IT担当者が倉庫へ行かなくても、Slackを通じて報告された故障機器の状況を確認できるようにすることを目指しました。
今回はLambdaにPython 3.12を使用し、サーバーを常時稼働させる必要のない、サーバーレス構成を採用しました。
AWSの各サービスについて学習した経験はありましたが、実際の業務に使うために複数のサービスを組み合わせて構築するのは初めてでした。
5. 故障報告にAIを組み込む
今回の仕組みでは、Amazon BedrockのClaude 3 Haikuも使用しています。ただし、すべての処理をAIに任せているわけではありません。
故障内容を選択式で入力する
故障機器をベンダーへ修理依頼する際には、故障カテゴリや故障内容を、あらかじめ用意されたリストから選択する必要があります。
IT担当者であれば、故障状況から適切な項目を判断できます。しかし、ITに詳しくない現場の利用者に、同じ判断を求めるのは難しい場合があります。そこで、よく発生する故障については、Slackのフォームから選択できるようにしました。
例えば、「電源が入らない」「起動しない」といった一般的な事象であれば、リストから選ぶだけで報告できます。一方、リストだけでは状況を十分に説明できない場合もあるため、自由に入力できる備考欄も設けました。
備考欄の内容をAIで分類する
備考欄に入力があった場合には、必要に応じて既存の故障分類に当てはめる処理を行います。
この判断に利用するのが、Amazon BedrockのClaude 3 Haikuです。
AIが備考欄に書かれた内容を確認し、既存の故障カテゴリや故障内容に該当する項目があれば分類します。該当する項目がなければ、無理に分類せず、備考欄の情報として残します。ただし、備考欄が空欄で、選択項目だけで報告が完結する場合にはAIを呼び出しません。
通常のプログラムで処理できるものはプログラムで処理し、判断が必要な部分だけAIに任せる。
このような設計にしました。
6. AIの利用コストを抑える工夫
今回のシステムは、個人の学習用ではなく、実際の業務で使用することを想定しています。そのため、AWSの利用料金も考慮する必要がありました。特に生成AIは、呼び出すたびに料金が発生するため、必要以上に動作させることは避けたいと考えました。そこで、DynamoDBを利用したAIのキャッシュを実装しました。
処理の流れは以下のとおりです。
利用者がSlackのフォームから故障内容を報告する
備考欄が空欄であれば、AIを呼び出さずに登録する
備考欄に入力があれば、DynamoDBのAI Cacheを検索する
キャッシュが見つかれば、過去の分類結果を再利用する
キャッシュがなければBedrockで分類し、その結果をキャッシュに保存する
つまり、備考欄に入力があっても、必ずAIを呼び出すわけではありません。過去に処理した内容と一致するキャッシュがあれば、その結果を再利用します。同じような報告が繰り返された場合に、AIの呼び出し回数を減らせる仕組みです。
もちろん、キャッシュには古い分類結果や誤った分類が残る可能性もあるため、その管理は今後の運用で考慮する必要があります。
このシステムを導入するにあたっては、上司への説明も必要でした。
単に「AIを使えば便利になります」ではなく、何にAIを使うのか、どの程度のコストで運用できるのかを説明できる設計にすることも重要だと考えました。
7. システムは完成。でも、まだリリース前
試行錯誤を重ねながら、当初考えていた故障報告システムをAWSの開発環境に構築することができました。
Slackから故障機器の情報を報告し、DynamoDBに保存する。必要な場合にはAIで内容を分類し、キャッシュによってAIの利用コストを抑える。さらに、登録された故障情報を確認し、定期的にSlackへ通知する仕組みも実装しました。
ただし、現時点ではまだ現場へのリリースには至っていません。
今回の仕組みはAWSの開発環境で構築しており、実際に業務で使用するためには、運用環境への移行が必要です。そのためには社内の承認手続きを経る必要があり、現在は手続きを進めている段階です。
したがって、実際にどれくらい倉庫の巡回が減ったのか、どの程度の業務効率化につながったのかについては、まだ評価できていません。システムとしては完成しましたが、業務改善としての成果が出るのはこれからです。
8. まとめ
今回、社内SEとして以前から感じていた業務の非効率を解消するため、初めてAWSを本格的に使った業務システムの構築に挑戦しました。
最初は、既存の社内システムを組み合わせて実現しようと考えていました。しかし、Power AppsやPower Automateの利用制限があり、思うようには進みませんでした。そこで、改めて実現したいことを考え直しました。SharePointを使うことが目的ではなく、故障機器の情報を遠隔で確認できるようにすることが目的だったのです。
この発想の転換から、AWSでのシステム構築に進みました。
また、AIを組み込む際にも、何でもAIに任せるのではなく、必要な部分だけ利用し、キャッシュによってコストを抑える設計を意識しました。
今回の経験を通じて、既存のシステムや実現手段にこだわらず、本当に解決したい問題から考えることの重要性を改めて感じました。そして、今回のAWS開発では、システムを作り上げていく過程でもう一つ大きな発見がありました。
それは、私自身のAIの使い方を大きく変えるものでした。
次回は、AIに作り方を教えてもらうところから、AIに実際の作業を任せるようになるまでの経験について紹介したいと思います。
