フィールドエンジニアがWhatsAppに貼り付けた障害報告を、SLA（サービスレベル合意）準拠のExcelレポートへ変換するまでを5分以内に完了させる——そのような業務自動化システムが、ナイジェリアの通信業界向けに個人開発者の手で構築されました。作業時間を2〜4時間から95%超削減するという数字は、技術的な興味を超えて、業務システム設計の教科書的な事例として参照する価値があります。
非構造化テキストの解析という本質的な難しさ
業務システムにおける入力データの「汚さ」は、エンタープライズ開発では避けて通れない課題です。このシステムが扱うのは、フィールドエンジニアがWhatsAppに書き込んだ非定型の障害報告です。セパレータなしで連結されたサイトID、先頭のゼロ抜け、カスケード障害（ある障害が別の障害を引き起こす連鎖）、複数フォーマットの停電時間が混在します。
実際の入力例として、シード記事では次のようなテキストが挙げられています。
EN0035+25(EN0707,EN0377): DG fail to start =34mins or 1hr 20mins or 1:20hrsこれを構造化データとして分解するには、サイトIDの正規化、カスケード関係の抽出、時間表記の統一という3つの変換を同時に行う必要があります。正規表現だけで対応しようとすると、表記ゆれのたびにルールを追加するいたちごっこになります。このシステムはパーサ（テキスト解析器）を独立したコンポーネントとして設計し、後段の分類ロジックから切り離しています。
8段階を順番に通過させる分類パイプラインの構造
分類エンジンは、優先度順に8つのステージを通過させる設計です。順番に整理すると以下のようになります。
- 短時間障害ルール: 一定時間以下の障害を先に振り分ける
- ハードオーバーライド: 強制的に特定カテゴリに分類するビジネスルール
- 学習済み補正: 過去に人手で修正された分類を優先適用する
- パートナー対応キーワードエンジン: インフラパートナー別の分類辞書
- Google Gemini AI: 上記で判定できない曖昧な事例をLLMに問い合わせる
- パートナーロック: サイトの管理会社情報に基づく最終確認
- サイト履歴フォールバック: 過去の同サイトの分類実績を参照
- 汎用ファジーフォールバック: 最終手段として部分一致でカテゴリを推定
この設計で注目すべきは、LLMへの問い合わせを5番目に置いている点です。LLMを呼び出すコストと待機時間を考慮し、ルールベースとキャッシュで解決できる事例はその手前で完結させます。LLMはあくまで「人手ルールとキーワード辞書では分類できない曖昧なケース」にのみ適用するという役割分担です。
さらに、Geminiへの問い合わせはサーバーサイドのプロキシ経由で行われます。これにより、APIキーがブラウザのネットワークトラフィックに露出しません。クライアントサイドに秘密情報を置かないという原則は、エンタープライズシステムでは基本ですが、個人開発のツールで確実に実装されているケースは必ずしも多くありません。
パートナー対応分類が示す業務要件とデータモデルの関係
「同じ障害説明文でも、管理会社が異なればSLAカテゴリが変わる」という仕様は、通信業界特有の契約構造に由来します。同一の「DG（ディーゼル発電機）起動失敗」という障害であっても、IHSやATCといったインフラ管理会社によって責任範囲が異なり、SLAレポート上の分類が変わるのです。
これは日本の業務システムでも類似した構造が現れます。たとえば、同一の取引でも与信グループや契約種別によって会計処理のルールが変わるケースです。キーワードマッチングだけで分類しようとすると、コンテキスト（文脈情報）が欠落して誤分類が増えます。このシステムが「パートナー対応を最初に考慮する」と明示しているのは、業務の文脈情報をデータモデルに織り込む設計判断として評価できます。
継続学習による分類精度の向上とSupabaseへの永続化
レビューステップでオペレータが分類を修正すると、その修正内容がSupabase（PostgreSQLベースのBaaS）に保存され、次回以降の「学習済み補正」ステージで優先参照されます。BaaS（Backend as a Service）とは、データベースや認証をAPIとして提供するクラウドサービスです。SupabaseはRow Level Security（行レベルセキュリティ、ユーザーごとにアクセス可能な行を制御する機能）を標準で持つため、複数オペレータが使う環境でも設定で対応できます。
技術スタックはReact 19、TanStack Start（ファイルベースのフルスタックフレームワーク）、TypeScript、Tailwind CSS v4という構成です。入力ファイルはHuaweiのRNATracker（設備稼働率トラッキングツール）が出力する.xlsbバイナリ形式で、出力は色分けとオートフィルタ付きのExcelファイルです。「入力も出力もExcel」という制約は日本の業務システムでも頻繁に登場するパターンです。
このプロジェクトが示すのは、「既存の業務フローを壊さずにLLMを差し込む」という設計思想です。出力形式をExcelのまま維持し、入力チャネルをWhatsAppのままにしながら、中間の分類処理だけを自動化することで、オペレータの習熟コストを最小化しています。レガシーシステムの改善に取り組む際、既存の入出力インターフェースを継続使用しながら処理の中核だけを置き換えるアプローチは、導入リスクを下げる現実的な選択肢になります。