Logstorage(ログストレージ)は、インフォサイエンス株式会社が開発する統合ログ管理製品です。サーバー、ネットワーク機器、Windowsのイベントログ、AWSやMicrosoft 365のログを1か所に集め、圧縮して保管し、検索・集計・検知・レポートの対象にできる製品です。この記事では、LogGateを中心とした構成、5種類のレシーバの選び方、Linuxサーバーからrsyslogで暗号化して送る設定ファイル、AWS CloudTrailのログを長期保管する準備、日次ログ量で決まるライセンスと保守費の見積り方を、2026年9月時点のVer.11系の仕様で説明します。後半ではSplunkやMicrosoft Sentinelと比べて、Logstorageを選ぶ条件と見送る場面を言い切ります。
まとめ:Logstorageが向く組織と収集方式・費用・見送り条件の結論
Logstorageが強いのは、オンプレミスのサーバーと国内製品のログが混在し、監査対応のレポートを日本語で定期出力したい組織です。PC資産管理やデータベース監査などの国内製品向けに連携パックがそろっており、フォーマット定義を自作せずに取り込めます。
収集経路は、Linuxならrsyslogからsyslog TLSで送り、Windowsならエージェントレスで集めるELCかAgentを使うのが基本形です。費用は日次ログ量で決まるエディションのライセンス価格に、その20%の年間保守費が毎年乗ります。価格は公開されていないため、見積り依頼の前に日次ログ量を実測しておくことが交渉の出発点です。
ログの発生源がAWSやAzureのクラウドサービスにほぼ限られ、検知ルールを開発チームがコードで管理したいなら、Logstorageは選びません。クラウドネイティブのSIEMか、OpenSearchなどで組んだ基盤のほうが運用に合います。
Logstorageの構成を把握する|LogGateとコンソールサーバと収集ツールの役割
最初に押さえるのは、ログを受ける側と見る側がサーバーとして分かれている点です。
LogGateとコンソールサーバの分担と標準構成で必要なCPU・メモリ
Logstorageの製品ページによると、中核はログを受信・保管・分析するLogGateと、Webブラウザから検索や設定を行うコンソールサーバの2つです。対応OSはRed Hat Enterprise Linux 8・9・10とWindows Server 2016〜2025で、Windows Server Coreには対応していません。Rocky LinuxとAmazon Linuxはベストエフォートの扱いです。
標準的なハードウェア構成は、ワークグループ版・スタンダード版・エンタープライズ版が4コアかつメモリ12GB以上、エンハンスト版とアドバンスト版が8コアかつメモリ32GB以上とされています。インストールに要るディスクは1GBですが、ログの保管領域は別に見積もる必要があります。扱えるディスク容量の上限は80ペタバイトです。
Agent・SBT・ELC・Logsource Controllerの収集方式と役割
収集側のツールは4つあり、使い分けの判断軸は収集方式と役割、エージェントレスで収集する必要があるかどうかです。Logstorage Agentは対象サーバーに入れてログをリアルタイムに送る常駐型、SBTはバッチで読み込んでFTPで送る型、ELCはWindowsのイベントログをエージェントレスで集めるサーバー、Logsource ControllerはAgentを集中管理するツールです。
実務でまず決めるのは、Windowsサーバーにエージェントを入れられるかどうかです。入れられない運用なら、スタンダード版以上に付属するELCで集めます。Linuxは標準のrsyslogから送れるため、Agentを入れる理由は、syslogに出ないアプリのファイルログを拾いたい場合に絞られます。
Ver.11.0.0のログ最大長拡張とoctet counting受信仕様
2025年12月26日のLogstorage Ver.11.0.0のリリース情報で、1件のログメッセージの最大長が32,767バイトから262,144バイトの既定値へ広がり、最大2,097,152バイトまで設定できるようになりました。JSONで出力するアプリのログや、スタックトレースを含むエラーログが途中で切れる問題への対処です。
同じ版で、RFC 5424形式のsyslogをoctet counting方式で受ける機能がTLSレシーバに入りました。RHEL 10の追加とRHEL 7の除外もこの版です。2026年6月12日公開のVer.11.0.3では同梱のOpenJDKが17.0.19に上がっており、2026年9月時点の最新は11.0系です。
Logstorageのログ収集設定|rsyslogのTLS転送手順と確認コマンド
ここからは、Linuxサーバーのログを送る側の作業です。
5種類のレシーバから収集経路を選ぶ判断基準とLinuxでの第一候補
LogGateが受ける経路は5種類で、製品ページには「テキスト形式のログはすべて収集可能」と書かれています。ログの発生源ごとに次のように選びます。
| レシーバ | 送る側 | 即時性 | 向く発生源 |
|---|---|---|---|
| Syslog(UDP・TCP・TLS) | rsyslog・ネットワーク機器 | リアルタイム | Linux、ファイアウォール、スイッチ |
| LLTP | Logstorage Agent | リアルタイム | syslogに出ないアプリのファイルログ |
| SNMP | SNMPトラップを送る機器 | リアルタイム | ネットワーク機器の障害通知 |
| ファイル共有 | 共有フォルダに置かれたログ | 定期受信 | エージェントを入れられない機器 |
| FTP | SBT | バッチ | データベース監査ログなどの定期取得 |
Linuxサーバーの第一候補はsyslogのTLSです。UDPは経路の途中で落ちても送信元が気付かず、平文のTCPはログの中身が経路上で読めます。監査証跡として保管するログなら、TLSで送り、送信側にキューを持たせる構成にしてください。
rsyslogのomfwdでoctet-counted方式のTLS転送を書く設定ファイル
rsyslogのomfwdモジュールのドキュメントによると、TCPのフレーミングは改行で区切るtraditionalが既定で、受信側が対応しているなら長さを先頭に付けるoctet-countedが推奨されています。改行を含むメッセージが複数件に割れないためです。方式の定義はRFC 6587にあります。TLSはStreamDriverにosslなどを指定し、StreamDriverMode="1"で有効にします。
# /etc/rsyslog.d/90-logstorage.conf
# RHEL 9系の前提: dnf install rsyslog-openssl で ossl ドライバを入れておく
global(
DefaultNetstreamDriverCAFile="/etc/pki/rsyslog/ca.pem"
)
*.* action(
type="omfwd"
target="loggate.example.internal"
port="6514"
protocol="tcp"
TCP_Framing="octet-counted"
template="RSYSLOG_SyslogProtocol23Format"
StreamDriver="ossl"
StreamDriverMode="1"
StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="loggate.example.internal"
queue.type="LinkedList"
queue.filename="fwd_logstorage"
queue.maxDiskSpace="1g"
queue.saveOnShutdown="on"
action.resumeRetryCount="-1"
)
RSYSLOG_SyslogProtocol23Formatはrsyslogに組み込まれたRFC 5424系の書式です。ポート番号とCA証明書はLogGate側のTLSレシーバの設定に合わせて書き換えます。octet countingの受信はVer.11.0.0からの機能のため、Ver.10系以前のLogGateへ送る場合はTCP_Framingの行を消してtraditionalで送ってください。キューの行は、LogGateが止まっている間のログをディスクに退避させ、復旧後に送り直すための設定です。rsyslog.confの書き方全般はrsyslogとは?Linuxのログ収集・転送の仕組みとrsyslog.conf設定で扱っています。
loggerコマンドで疎通を試しキューの滞留を確かめる3段階の手順
設定を入れたら、構文、経路、受信の順に確かめます。loggerコマンドのマニュアルにあるとおり、--serverと--tcpでrsyslogを通さずに直接送ることもでき、--octet-countでRFC 6587の方式を指定できます。
# 1. 設定ファイルの構文を確認してから再起動する
rsyslogd -N1
systemctl restart rsyslog
# 2. ローカルのsyslogに書き込み、rsyslog経由でLogGateへ届くか確かめる
logger -p auth.warning -t lstest "Logstorage受信テスト $(hostname) $(date +%s)"
# 3. 届かないときはキューに溜まっていないかを見る(RHEL既定のworkDirectory)
ls -l /var/lib/rsyslog/ | grep fwd_logstorage
# 参考: TLSを使わない検証用TCPレシーバへ直接送る場合
logger --server loggate.example.internal --port 514 --tcp --rfc5424 --octet-count -t lstest "直接送信テスト"
手順2のメッセージは、コンソールサーバの検索画面でタグlstestを条件にして確認します。キューのファイルが増え続けているなら、証明書の名前の不一致か、ファイアウォールでポートが閉じているかのどちらかを疑います。journalctl -u rsyslogにTLSのエラーが出ていれば前者です。
AWSログのLogstorage長期保管|CloudTrail証跡と連携パックの範囲
クラウドのログは、AWS側で残し方を決めてからLogstorageに取り込みます。
CloudTrailのイベント履歴は90日だけ、証跡をS3へ出力するCLIコマンド
CloudTrailのイベント履歴のドキュメントでは、アカウント作成時から見られるイベント履歴は1リージョンの管理イベントの過去90日分に限られ、継続して記録するには証跡かイベントデータストアを作るよう書かれています。Logstorageに取り込む前提として、まず証跡をS3バケットに出力します。
# 全リージョンの管理イベントをS3へ出力する証跡を作り、記録を開始する
aws cloudtrail create-trail \
--name audit-trail \
--s3-bucket-name example-cloudtrail-logs \
--is-multi-region-trail \
--enable-log-file-validation
aws cloudtrail start-logging --name audit-trail
# 記録が動いているかを確認する(IsLogging が true なら成功)
aws cloudtrail get-trail-status --name audit-trail
出力先のS3バケットには、CloudTrailからの書き込みを許可するバケットポリシーの事前設定が必要です。オプションの詳細はcreate-trailのリファレンスで確認できます。--enable-log-file-validationを付けると、ログファイルの改ざんを後から検証するダイジェストも出力されます。
対応パック for AWSが扱う10種のログとAzure・GCP・M365連携パックの版
Logstorage 対応パック for AWSは、CloudTrail、AWS Config、CloudWatch Logs、AWS Billing、S3アクセスログ、CloudWatch Metrics、Elastic Load Balancing、Amazon RDS、CloudFront、S3オブジェクトログの10種を収集対象にしています。中身は専用の収集モジュール、項目を切り出すフォーマット定義、検索・集計・レポートの分析テンプレートの3つです。
他のクラウド向けも更新が続いており、2026年に入ってからMicrosoft 365連携パック Ver.4.1.0、Azure連携パック Ver.4.1.0、GCP連携パック Ver.1.1.0が出ています。AWSのログをCloudWatch Logsの中だけで検索する場合の費用感は、CloudWatch Logs Insightsの料金と使い方と比べてみてください。
Logstorageのライセンスと費用の決まり方|日次ログ量の5区分と保守20%
公式サイトに価格表はありません。見積りの前提になる区分だけが公開されています。
WG版5GB/日からAD版30GB/日以上まで、エディションごとの構成の違い
エディションは1日に収集するログ量で分かれ、LogGateの台数と冗長化の方式もそれに連動します。
| エディション | 日次ログ量 | LogGateの構成 | ELC |
|---|---|---|---|
| ワークグループ版(WG) | 5GB/日 | 1台(冗長構成可) | 付属なし |
| スタンダード版(ST) | 10GB/日 | 1台(冗長構成可) | 付属 |
| エンハンスト版(EH) | 15GB/日 | 1台(冗長構成可) | 付属 |
| エンタープライズ版(EP) | 20GB〜/日 | 複数台で分散 | 付属 |
| アドバンスト版(AD) | 30GB〜/日 | ロードバランサと共有ディスク | 付属 |
Logstorageは集計・検知・レポートのモジュールを付けた形で案内されます。サーバーのログ管理に絞ったELC Analyticsという別製品もありますが、こちらには検知モジュールが含まれません。不正の兆候をリアルタイムに通知したいなら、Logstorage本体を選ぶことになります。
日次ログ量の見積り方とWindowsイベントログが膨らむ条件
エディションを決める数字は、圧縮前の1日あたりのログ量です。既存のsyslogサーバーがあるなら、du -sh /var/log/remote/2026-09-25のように1日分のディレクトリ容量を1週間分測り、最大値を採ります。平均で選ぶと、月末の締め処理やバッチの日に上限を超えます。
見積りを外しやすいのはWindowsです。ドメインコントローラーでログオンの成功イベントまで集めると、社員数に比例して量が増えます。ファイアウォールの許可通信ログも同じ傾向があります。最初は拒否ログと管理操作のログに絞り、許可ログを入れるかは容量を測ってから決めてください。
保守費はライセンス価格の20%・初年度必須とする年額の組み立て方
保守契約のご案内には、製品ライセンス価格の20%が年間の保守費用で、導入初年度は必須、2年目以降は任意で初年度と同額と書かれています。5年使う前提なら、保守費の合計はライセンス価格と同額になります。
保守を外すと新しい版やパッチが届きません。OpenJDKやTomcatの脆弱性修正が同梱ソフトの更新として配られる製品なので、セキュリティ目的で入れる以上、保守は切らない前提で総額を出します。導入前には約1か月の試用版があるため、実際のログ量と検索の速さをそこで測れます。
Logstorage・Splunk・Sentinel・OpenSearchの採否条件
統合ログ管理とSIEMの違いや製品の分類はSIEMとは?仕組み・機能とEDR/XDR/SOARの違い・製品選定で整理しています。ここではLogstorageを選ぶかどうかに絞り、Splunk・Sentinel・OpenSearchと比べたときの採用条件と見送る場面を言い切ります。
Logstorageを採用する条件は国内製品のログと日本語の監査レポート
採用してよいのは、次の2つがそろう組織です。1つ目は、オンプレミスのWindowsサーバーやネットワーク機器、SKYSEA Client ViewやLANSCOPEなどの資産管理製品のログが大半を占めていること。連携パックがフォーマット定義と分析テンプレートを持っているため、取り込みの作り込みがほぼ要りません。
2つ目は、監査法人や社内監査に出すレポートを、日次・月次でPDFやHTMLにして自動配信したいことです。検索・集計・レポートが1つの画面で完結し、担当者がクエリ言語を覚えなくても運用できます。情報システム部門の少人数で回す前提なら、この点が決め手になります。
クラウド中心でコードで検知ルールを管理するならLogstorageは見送る
ログの発生源がAWS・Azure・Microsoft 365にほぼ限られるなら、Logstorageは見送ります。LogGateのサーバーを自前で持ち、OSとディスクを保守し続ける負担に見合わないからです。Microsoft 365とAzureが中心なら、Microsoft Sentinelとは?クラウドネイティブSIEM/SOARの仕組み・料金モデルのように取り込み量で課金されるSaaS型のほうが、サーバーの運用がありません。
開発チームが検知ルールをGitで管理し、アプリのログと合わせて分析したい場合も合いません。その場合はOpenSearchやElasticsearchで基盤を組み、ルールもダッシュボードもコードで持つ構成に分があります。収集経路とインデックス設計はElasticsearchのログ収集|ELKスタックの収集経路とインデックス分割で扱っています。
Splunkと迷うのは、アプリのログやメトリクスまで横断して相関分析をしたい組織です。SplunkはSPLという独自のクエリ言語で自由に集計を書ける代わりに、それを書ける担当者が社内にいることが前提になります。クエリを書く人がいないならLogstorage、書ける人がいて分析の自由度を取るならSplunk、という分け方で外しません。
どの製品でも検知・監査の分析精度を決めるアプリ側のログ出力設計
製品を選んでも、業務アプリが「誰が・いつ・何を・どの結果で」を1行で出していなければ、検知も監査も成り立ちません。インシデント後の調査で詰まるのは、多くがこの出力側です。調査の流れはデジタルフォレンジックとは?種類・調査の流れと企業が平時に備えることで解説しています。
ログの項目名と形式は、収集製品を決める前に仕様として固めておくべきです。Ver.11系でログ最大長が広がったとはいえ、1行のJSONに利用者IDとリクエストIDを必ず入れる設計は、製品を乗り換えても使えます。AWS上のシステムでログの出力からCloudTrailやS3への保管経路までを組み直す作業は、AWS・Google Cloud・Azureのインフラ構築支援で設計から引き受けています。
よくある質問
Logstorageの検討時に出やすい疑問を5つ取り上げます。
Logstorageの価格はいくらですか?
公式サイトに価格表は掲載されておらず、エディションと収集対象の台数を伝えて見積りを取る方式です。公開されているのは、日次ログ量で分かれる5つのエディションと、製品ライセンス価格の20%が年間保守費になるという条件です。見積り依頼の前に1週間分のログ量の最大値を測っておくと、エディションの選び過ぎを防げます。
LogstorageとELC Analyticsは何が違いますか?
ELC Analyticsは、サーバーのログ管理に絞った同じ開発元の製品で、集計・レポートのモジュールが同梱されていますが検知モジュールは含まれません。Logstorageは集計・検知・レポートを付けた形で案内され、ネットワーク機器やクラウドのログまで扱えます。Windowsサーバーのイベントログを監査用に残すだけならELC Analytics、不正の兆候を通知したいならLogstorageです。
LogstorageはSIEMとして使えますか?
検知モジュールでシナリオに沿ったリアルタイム検知ができるため、SIEMの中核機能は持っています。開発元による位置づけも、SIEM・統合ログ管理製品です。ただし、脅威インテリジェンスとの自動照合やSOARによる自動対処まで求めるなら、外部製品との連携を前提に設計します。何をSIEMに求めるかを先に決めてから比べてください。
Logstorageはクラウド版(SaaS)で使えますか?
製品ページに載っている動作環境は、RHELとWindows Serverに自分でインストールする形です。AWSのEC2やAzureの仮想マシンに載せる構成は取れますが、その場合もOSとディスクの管理は利用者側に残ります。サーバーを持たずに済ませたいなら、Microsoft Sentinelなどのクラウド型SIEMと比べるのが筋です。
Logstorageのsyslog受信でUDPとTLSのどちらを選べばよいですか?
監査や調査に使うログはTLSを選びます。UDPは到達確認がなく、LogGateの再起動中に送られたログは失われます。ネットワーク機器がTLSに対応していない場合だけUDPやTCPを使い、同じセグメント内に閉じた経路に限ってください。Ver.11.0.0以降のTLSレシーバなら、octet counting方式で改行を含むメッセージも1件のまま受けられます。
関連記事
- SIEMとは?仕組み・機能とEDR/XDR/SOARの違い・製品選定:統合ログ管理とSIEMの位置づけ
- rsyslogとは?Linuxのログ収集・転送の仕組みとrsyslog.conf設定:送信側の設定の詳細
- Microsoft Sentinelとは?クラウドネイティブSIEM/SOARの仕組み・料金モデル:クラウド型SIEMとの比較
- Elasticsearchのログ収集|ELKスタックの収集経路とインデックス分割:OSSで組む場合の設計
- デジタルフォレンジックとは?種類・調査の流れと企業が平時に備えること:ログを調査で使う場面