STUDY研究日誌

■はじめに

こんにちは！

今回、この記事ではHinemos AIエージェントの概要とインストール方法に加え、実際の活用例についてご紹介します。

■Hinemos AIエージェントとは

Hinemos AIエージェントとは、LLM（大規模言語モデル）とHinemosマネージャを連携させ、自然言語を通じてHinemosの監視結果やジョブ実行状況などを操作・参照できるようにする仕組みです。

LLMに対して自然言語で問い合わせを行うと、LLMがMCP（Model Context Protocol）を介してHinemosのREST APIを呼び出し、その結果をユーザにわかりやすい形で返します。

●構成コンポーネント

Hinemos AIエージェントは、以下の3つのコンポーネントで構成されます。

• Hinemos MCP Server：LLMからの要求を受け取り、HinemosのREST APIを呼び出すためのMCPサーバです。Hinemos AIエージェントの中核となるコンポーネントとなります。
• LLM：自然言語処理を行うモデル本体です。クラウド型LLMのほか、Azure OpenAI ServiceやAmazon Bedrock経由での利用も想定しています。
• LLMクライアント（Open WebUI）：ユーザがLLMへ問い合わせを行うためのフロントエンドです。Open WebUI Inc.が公開するOSSで、Hinemos AIエージェントではサンプル導入パッケージを提供しています。

●処理の流れ

ユーザの問い合わせから応答までの流れは、以下のとおりです。

1. ユーザがOpen WebUIから自然言語でメッセージを送信する
2. Open WebUIがLLMにメッセージを送信する
3. LLMが呼び出すべきMCPツール（HinemosのAPI）を判断する
4. Hinemos MCP ServerがHinemosマネージャのREST APIを呼び出す
5. Hinemos MCP ServerがAPIのレスポンスをLLMに返す
6. LLMが応答を整形してユーザに返す

■Hinemos AIエージェントの主なユースケース

Hinemos AIエージェントは、日々の運用業務における「確認」「分析」「調査」「対処」の各シーンで活用できます。想定される主なユースケースは以下のとおりです。

• 確認：異常の発生有無やHinemosマネージャ／Hinemosエージェントの稼働状態を、自然言語で問い合わせるだけで素早く把握できます。
  • 重要度「危険」イベント有無を確認
  • 異常終了しているジョブ有無を確認
  • 長時間実行しているジョブを検知
• 分析：蓄積されたイベントやジョブ実行履歴をサマライズし、傾向や全体像を把握する用途に活用できます。
  • イベント発生状況をカテゴリ別に集計
  • ジョブ実行状況をカテゴリ別に集計
• 調査：障害発生時の事象把握や、発生個所の特定をHinemos AIエージェントに補助させることができます。
  • 危険イベントの内容・事象を把握
  • 異常終了ジョブの内容・事象を把握
  • 障害ノードに対する他の監視結果から原因を推測
  • イベント傾向から怪しいノードを特定
  • ジョブ異常と監視履歴から障害ノードを特定
  • 障害ノードと同スコープの影響範囲を確認
• 対処：特定したノードに対する一次切り分けや、暫定対処の支援に活用できます。
  • 特定したノードの疎通確認・手動調査
  • 障害ノードの監視を一時的に無効化

これらのユースケースは、いずれも従来であればHinemosクライアントの画面遷移や、複数の検索条件指定が必要だった操作です。Hinemos AIエージェントを利用することで、自然言語による問い合わせを起点に、必要な情報の確認を進めやすくなります。

■動作要件

Hinemos AIエージェントは、Hinemosマネージャ ver.7.2に対応しています。

対応OS、前提ソフトウェア、検証済みモデル、検証済みLLMクライアントなどの詳細につきましては、Hinemos AIエージェントのマニュアルを参照ください。

■インストール手順

本章では、Hinemos MCP ServerとOpen WebUIサンプル導入パッケージのインストール手順をご紹介します。

●Hinemos MCP Serverのインストール

提供パッケージ（hinemos_mcp_server_for7.2_yyyymmdd.zip）を、Hinemosマネージャと通信可能なWindowsサーバへ展開します。

1) インストール先ディレクトリの作成

インストール先ディレクトリ「C:\Program Files\Hinemos\hinemos_mcp_server」を作成し、パッケージの内容を配置します。

2) Hinemos MCP Serverのインストール

3) Windowsサービスとして登録

●Hinemos MCP Serverのトークン発行

LLMクライアント（Open WebUI）からHinemos MCP Serverへ接続するためのアクセストークンを発行します。

Hinemos MCP Serverのインストール先ディレクトリに移動し、以下のコマンドを実行します。「-u」にHinemosのユーザID、「-p」にHinemosのパスワードを指定します。

コマンド実行後、コンソールに表示されるアクセストークンを控えておきます。発行したトークンは、後述するOpen WebUI側のMCP接続設定で利用します。

その他、発行済みトークンの一覧表示・削除・期限切れトークンのクリーンアップを行いたい場合は、以下のコマンドが利用できます。

• 一覧表示：hinemos-mcp-tokens show
• 個別削除：hinemos-mcp-tokens delete -t <トークン>
• 期限切れトークンのクリーンアップ：hinemos-mcp-tokens cleanup

●Hinemos MCP Serverの接続設定

インストール後、confディレクトリ配下の設定ファイルを編集し、Hinemosマネージャの接続情報やMCPサーバのリッスン設定を行います。

• hinemos_config.toml：HinemosマネージャのREST API接続情報を設定します。
• mcp_config.toml：MCPサーバのリッスンアドレス／ポートや、公開するHinemos API（exposed_as_tools）の制御を行います。

●Hinemos MCP Serverの起動

サービスとして登録済みであれば、以下のコマンドで起動します。

●Open WebUIサンプル導入パッケージのインストール

本サンプル導入パッケージのインストールに先立ち、Open WebUI 本体（v0.7.2）を事前にインストールしておく必要があります。Open WebUI 本体のインストールは、Pythonのパッケージ管理ツールであるpipを利用して、以下のコマンドで実行します。

※ venv（仮想環境）の作成や、Open WebUI本体の詳細なインストール手順については、Open WebUIサンプル導入パッケージ利用ガイドを参照ください。

1) パッケージの配置

「C:\Program Files\open-webui」にopen-webui_sample配下の内容を配置します。

2) Open WebUIの起動

start_open-webui.batを実行してOpen WebUIを起動します。

●Open WebUIへのHinemos MCP Serverの登録

Open WebUIの管理画面から、Hinemos MCP Serverを外部ツールとして登録します。

1. Open WebUIに管理者ユーザでログインします。
2. 「管理者パネル」-「設定」-「External Tools」を開き、「+」ボタンから新しい接続を追加します。
3. MCPサーバの接続情報を入力します。
   • タイプ：MCP Streamable HTTP
   • URL：http://xxx.xxx.xxx.xxx:8000/mcp
   • 認証：Bearer
   • APIキー：Hinemos MCP Serverで発行したアクセストークン
   • ID：hinemos_mcp_server（任意）
4. 登録後、続けて利用するLLMの接続情報（URL／APIキー）を「管理者パネル」-「設定」-「接続」から登録します。
5. 提供されているモデルプリセットをインポートし、Hinemos AIエージェントとしてモデルを公開します。
   • 左のサイドバーから「ワークスペース」-「モデル」を開きます。
   • 「インポート」をクリックし、モデルプリセットファイル（hinemos-ai-agent-model.json）をインポートします。
   • インポートされたモデルの編集画面で、ベースモデルとして先ほど登録した LLM を選択します。
   • 「ツール」欄で Hinemos MCP Server を選択（チェック）し、設定を保存します。
   • 「モデル」画面でトグルを操作し、モデルを有効化します。

■Hinemos AIエージェントの活用例

ここからは、Hinemos AIエージェントを実際の運用シーンで利用したときに、どのような対話で課題解決が進むかをご紹介します。

今回は、運用業務の中で発生頻度が高く、AIエージェントの効果が分かりやすい「夜間バッチ障害の朝のトリアージ」シーンを例にご紹介します。

本検証では、LLM として GPT-5.4 を、LLMクライアントとしてマニュアルに検証済みLLMクライアントとして記載されている Open WebUI を使用しました。また、Hinemos AIエージェントが提供するモデルプリセットに記載されているシステムプロンプトは修正せず、そのまま使用しています。

なお、検証環境では業務系スコープ配下に bizapp01〜bizapp03（業務AP）、bizdb01（業務DB）を、基盤系スコープ配下に infra01 を配置し、毎日 22:00 に夜間バッチ（Nightbatch）をスケジュール実行しています。

●夜間バッチ障害の朝のトリアージ

朝、出社して Hinemos AIエージェントに「昨晩の状況」を聞くところから始まります。前日夜間に何が起きたのか、運用担当者にはまだ分かりません。本来であれば、イベントビューを開き、ジョブ履歴を確認し、影響範囲を調査し…と、複数の画面を行き来して情報を集める必要がありました。

このシナリオでは、Hinemos AIエージェントとの対話だけで、障害事象の把握から原因仮説までを完結させます。

本シナリオで再現している障害状況

読者の皆様に状況を理解いただきやすくするため、シナリオの開始時点でどのような障害が発生しているか、構成と障害個所を整理します。なお、これらの情報は本記事の読者向けに先出しでお見せしているもので、シナリオ内の運用担当者（Hinemos AIエージェントに問い合わせを行う側）はまだ何も把握していない前提です。

ノード／スコープ構成と障害発生個所

ジョブ構成と障害発生個所

夜間22:00のスケジュール実行で異常終了したジョブ

• CMD_Aggregate（データ集計実行）: bizapp02 上で実行され、終了コード 2 で異常終了。標準エラー出力に「ERROR Aggregate job aborted: input file not found」を記録

夜間22:00のスケジュール実行で実行中が継続しているジョブ

• CMD_LongTask（長時間処理実行）: bizdb01 上で実行され、22:00 の開始から長時間にわたり実行中の状態が継続

bizapp02 に対する各監視の状態

• PING_BIZ（PING監視）: 「100% パケットロス」を継続検知 → 重要度「危険」
• PROC_BIZAPP02（プロセス監視）: 「プロセス数 : 0」を継続検知 → 重要度「危険」

本シナリオでは、これらの障害状況を全く把握していない運用担当者が、朝に Hinemos AIエージェントへの問い合わせのみで、障害発見から原因仮説・一次対処案の策定までを完結させる流れを再現します。

なお、以降に掲載する Hinemos AIエージェントの応答画面は、実際の応答が長文であるため、要点となるセクションのみを切り抜いて掲載しています。

質問1：夜間バッチの実行状況を確認する

まずは、夜間バッチ（Nightbatch）の実行状況と、配下のジョブの結果を確認します。

【質問】「昨晩開始した夜間バッチ（Nightbatch）の実行状況を、配下のジョブも含めて教えてください。」

Hinemos AIエージェントは、ジョブ履歴とジョブセッション詳細を取得し、夜間バッチ全体は「実行中」状態であるものの、配下のデータ集計ジョブ（CMD_Aggregate）が bizapp02 で異常終了していること、終了コード 2 で標準エラー出力に「ERROR Aggregate job aborted: input file not found」と記録されていたこと、また長時間処理ジョブ（CMD_LongTask）が bizdb01 でまだ実行中であることを、「事実」「推測」「推奨アクション」の構造で整理して報告してくれました。1 つの質問だけで、障害の入り口から根本原因の手がかりとなる ERROR メッセージまでが一気に把握できました。

質問2：関連する異常イベントの有無を確認する

ジョブ異常終了に加えて、bizapp02 周辺で他にも異常がないかを確認します。

【質問】「bizapp02 で他に異常イベントは発生していますか？直近 24 時間で確認してください。」

bizapp02 では、直近 24 時間で重要度「危険」のイベントが発生していることが分かりました。具体的には、PING 監視で「100% パケットロス」が連続発生し、プロセス監視で「プロセス数 : 0」が継続的に検知されています。Hinemos AIエージェントは、これらの事実を踏まえて「bizapp02 はノード障害または疎通断の可能性がある」との推測まで提示してくれました。単なるジョブ失敗ではなく、ノード自体の異常を示唆する状況です。

質問3：影響範囲を確認する

bizapp02 と同じスコープに属する他のノードでも異常が発生していないか、影響範囲を確認します。

【質問】「bizapp02 と同じスコープのノードでも異常は出ていますか？」

業務系スコープ（BizScope）配下には bizapp01・bizapp02・bizapp03・bizdb01 の 4 ノードが存在しますが、検索期間内で発生した約 200 件の重要度「危険」イベントは、確認できた範囲ですべて bizapp02 に紐付くものでした。他ノードへの波及は確認されず、異常は bizapp02 に局所化していると整理されました。

質問4：原因仮説と一次対処案を整理する

ここまでの調査結果をもとに、原因仮説と一次対処案を整理してもらいます。

【質問】「ここまでの情報から、原因仮説と一次対処案を整理してください。」

Hinemos AIエージェントは、ここまでの一連の対話で得た情報をもとに、原因仮説と一次対処案を優先順位付きで整理して提示してくれました。最有力の仮説として「bizapp02 のノード障害または疎通断が主因」を挙げつつ、「bizapp02 上の入力ファイル未生成／未配置」「bizdb01 の長時間ジョブ残留」など複数の可能性を並列して列挙。一次対処として「bizapp02 の生死確認」「入力ファイル確認」「bizdb01 のジョブ調査」の順で具体的な手順を提示し、「主障害：bizapp02、業務影響：入力ファイル欠落、並行課題：bizdb01 の長時間実行」という暫定結論まで導いてくれました。ベテラン運用担当者が考えるような調査・対処手順を、対話のみで導き出すことができました。

従来であれば、複数の画面を行き来し、ジョブ履歴・イベント・ノード情報をそれぞれ手作業で突き合わせ、自分の頭の中で仮説を組み立てる必要がありました。Hinemos AIエージェントを利用することで、これらを一連の対話の中で完結できるようになります。

●活用例まとめ

本シナリオは、先ほどご紹介したユースケースカテゴリのうち「調査」と「対処」に位置付けられます。具体的には以下のユースケースをカバーしています。

• 異常終了ジョブの内容・事象を把握する
• 障害ノードに対する他の監視結果から原因を推測する
• イベント傾向から怪しいノードを特定する
• 障害ノードと同スコープの影響範囲を確認する
• 特定したノードの疎通確認・手動調査を支援する

従来であればHinemosクライアントの画面遷移や、複数の検索条件指定が必要だった操作を、Hinemos AIエージェントを活用することで、自然言語による問い合わせを起点に進められることが分かりました。原因仮説の立案や一次対処案の整理まで AI が支援してくれるため、運用担当者の認知負荷を大きく下げる効果が期待できます。

■おわりに

この記事ではHinemos AIエージェントの概要とインストール方法に加え、実際の活用例についてご紹介しました。

Hinemosの運用にあたって、お役に立てれば幸いです。