HOSHUTAROは星取表UIで設備機器の編集や保全履歴の追加・修正ができるアプリです。 ここまでならExcelでもできる話ですが、HOSHUTAROには生成AIによる編集機能と、IBM MaximoなどのEAMソリューションへのデータ連携（API）が容易な設計が加わります。
また、社内データが大手AIに学習・漏洩しないか懸念されている企業向けに、ローカルPCで動く軽量AI（ローカルLLM）や、プライベートクラウドで動かせるオープンウェイトLLMの使用にも対応できる設計にしています。
現在はHOSHUTARO固有の機能開発とチューニングを続けている段階ですが、企業向けにカスタム開発して提供できる段階に入ったと判断し、公開に踏み切りました。 アプリのコードはオープンソースですので、独自に開発していただくことも可能です。
なぜ星取表なのか
石油・化学プラント、発電プラント、ごみ焼却プラント、各業界の製造設備、ビル設備管理、船舶・航空機保全—— 現場で設備の面倒をみる保全員の皆さんは、日々膨大な数の機器と向き合っています。 その機器たちの保全履歴を、ビジュアル的に一目で確認したい。これは、業界を問わない共通のニーズです。
現場が最初に求めるもの
かつては、Excelで星取表を作成し、担当者・担当グループ単位で管理するのが現場の常識でした。 この保全履歴は保全業務の重要な資産であり、規模が大きくなるにつれて次のようなニーズが生まれます。
- 履歴を資産として未来へ残したい
- 部門・グループを横断して閲覧できるようにしたい
- 履歴を分析し、過剰整備や余剰在庫を減らしたい
- 経理システムと連携し、財務管理を適切に行いたい
こうしたニーズに応えてきたのが、IBM MaximoをはじめとするEAMソリューションでした。
EAMのUIは「データを見る」ためのもの
しかし、EAMの保全履歴画面は、まさに言葉どおり「データを見る」ビジュアルです。 保全担当者がコア業務として行う「保全履歴を把握し、次のアクションを計画する」という流れに対して、このUIは十分ではありませんでした。
私たちはEAMソリューションの元ユーザーであり、IBM Maximoのデリバリーエンジニアとして多くの導入プロジェクトに関わってきました。 その経験を通じて気づいたのは、業界・企業を問わず、保全担当者からまず一言目に求められるのは必ず「星取表」だったということです。 さらに、EAMへのシステム移行時にデータ移行の元データとなるのも、Excelで作られた星取表でした。
それにもかかわらず、Maximoに限らずどのパッケージソリューションにも、星取表UIは存在しませんでした。 類似機能はあっても、UIとして十分なものではなく、メイン画面にもなっていませんでした。 星取表UIの開発は決まって「今後の開発課題リスト」に掲載され、その後お蔵入りになる——その結果、ExcelとEAMの二重管理という状況を、私たちは何度も目にしてきました。
保全担当者の業務の入り口が星取表であることは、疑いようのない事実です。 この問題を解決しようと開発したのが「HOSHUTARO」です。
HOSHUTAROはExcelもEAMも受け入れる
プロジェクトと現場の温度差
設備保全最適化プロジェクトでは、「Excelの脱却・EAMへの完全統合」が目標に掲げられることが多いと思います。 プロジェクト開始当初は現場も同意しますが、運用が始まったあとの本音は「Excelが使いやすい・Excel最強」です。
大抵の場合、EAMからExcelをダウンロードする機能がカスタム実装されますが、問題はダウンロードされたExcelが現場で育ち続け、そのデータがEAMに反映されないことです。 結果として、EAM導入プロジェクトはその時点のデータ整備にとどまり、プロジェクト終了後はスナップショットのデータレイクになってしまう——そんな事例を、私たちは何度も見てきました。
データは資産、だからこそ構造が重要
この現状を踏まえ、HOSHUTAROはExcelからEAMへのデータ同期をソリューションのコアと考えて設計しています。 この設計思想には、私たちが長年ExcelからEAMへのデータコンバートを行ってきた知見を余すところなく取り込んでいます。
一方で、現場視点に寄りすぎると「そもそもEAMは必要なのか？」という問いが浮かびます。 ただのデータの溜まり場になるなら、クラウドストレージにCSVやExcelを保管しておけばいい、とも言えます。
しかし、データは資産です。資産とは利益を生む可能性があるから資産なのであって、分析やデータ連携など「使いやすい状態」にあってこそ価値を持ちます。 そう考えると、EAMのデータベース構造は非常に理にかなっています。 特にIBM Maximoは、データの活用柔軟性において他のソリューションと比べて圧倒的に優れていると感じています。 私がユーザー企業のDX推進者からIBM Maximoのソリューションエンジニアにジョブチェンジした理由は、まさにここにあります。
忖度なしに言えば、MaximoのUIが優れているとは今でも思っていません。 しかし、データ構造とデータ活用の設計思想には、脱帽しました。
HOSHUTAROのデータ構造はJSON形式での出力が可能で、データ項目は汎用的かつ一貫性のある設計になっています。 多くのEAMはJSON等の形式で外部データを取り込める仕様であるため、HOSHUTAROからの連携は難しくありません。
現在のHOSHUTARO
基本的なUIとバグ修正を終え、開発PCでアプリの動作を実機確認できる状態です。 ただし、ExcelをMaximoなどへ同期するデータ連携機能は現在開発中です。
Maximo API連携そのものの難易度は高くありません。 課題は、ファイルやシートによって配置が異なるExcelデータをJSONの項目へ自動マッピングするチューニングです。 GeminiやClaudeのような大規模クラウドLLMを使えばかなり精度よく変換できることは実験で確認済みですが、 現在は軽量ローカルLLMを使い、一般的なPCのNPU・GPU・CPUを効率的に活用しながら、プロンプトやオーケストレーションのチューニングを行っています。
プライベートクラウドを使ったオープンウェイトモデルの実験は、開発資金の都合でまだ未着手です。 まずはローカルLLMで確かな精度を出すことに集中しています。