IngaDB 0.1 · 製品ドキュメント
v0.1.0 · セルフホスト型 · 提供中 決定論的 · 同じ入力なら、同じ結果
因果分析データベース

因果分析を、
再現可能に。

フォールトツリーとインシデントデータを一元管理し、決定論的なリスク分析を実行します。 分析結果には計算時点のリビジョンが必ず残り、いつの状態に基づく数字なのかを後から確認できます。

構築を始める ドキュメントを読む $ docker compose -f deploy/docker-compose.yml up -d
✓ セルフホスト対応 · APIファースト · リビジョン管理
生産ライン / 分析 リビジョン42
イベント軸受摩耗p = 0.032
イベントシール漏れp = 0.018
ORゲート駆動部故障p = 0.0494
最上位事象ライン停止P50 · 4.94%
最小カットセット02
最新性 最新

実績ある技術基盤で構築

R Rust PostgreSQL 16{ } OpenAPI▦ Docker◎ 決定論的
解決する課題

リスク分析は、なぜ形骸化するのか。

多くの現場で、つまずきの原因は共通しています。IngaDBは症状への対処ではなく、 その構造的な原因を取り除くために設計されています。

01情報の分散

リスク情報が、図面とスプレッドシートに分散している

課題

モデルは作図ツール、インシデントは表計算ソフト、数値は報告書の中。 どれが最新版なのか、誰も即答できません。

解決

IngaDBは、モデル・根拠データ・計算結果・変更履歴を一つのデータベースに集約し、 単一のHTTP APIで提供します。

型付きグラフ一元管理HTTP API
02手描きのツリー

フォールトツリーを、ハザードごとに描き直している

課題

同じ設備をハザードの数だけ描き直すことになり、完成した図は設備側の変更に追従できません。

解決

故障モード・伝播経路・冗長性というメカニズムを一度登録すれば、ハザードごとの フォールトツリーはIngaDBが生成します。各ゲートの根拠は来歴として残り、 生成を打ち切った枝も理由つきで報告されます。

ツリー自動生成逸脱語彙来歴打ち切りの報告
03再現できない数値

その数値、あとから再現できますか

課題

担当者の環境、ツールのバージョン、乱数シードが違えば、数値は少しずつ変わります。 計算までLLMに任せれば、実行のたびに別の数字になります。監査で根拠を問われたとき、 当時と同じ計算を再現できないことが、いちばんのリスクです。

解決

計算順序は固定。確率はインシデントデータからの経験ベイズ推定、モンテカルロ法は固定シードです。 同じ入力なら必ず同じ結果になり、入力リビジョンが残るため、当時の計算をいつでも再現できます。

カットセット経験ベイズ重要度指標固定シード
04数字の独り歩き

報告書の数字だけが、独り歩きしている

課題

データも設備構成も変わり続けているのに、前四半期の数値が有効期限のないまま社内を回り続けます。

解決

すべての分析結果に入力リビジョンを記録。モデルやデータが変わった場合は、 どの変更で結果が古くなったのかを差分で示します。

リビジョン記録最新性の判定変更差分
05AIの推測

AIエージェントが、根拠のない数字を答えてしまう

課題

故障確率を尋ねられたエージェントは、参照できるデータがなければ、 もっともらしい数値をその場で作ってしまいます。

解決

取得APIとingactlが、決定論的でリビジョン付きの結果を返します。検索、因果経路、根拠データ、 重要度、カットセットを取得でき、実行前には必ずドライランを挟めます。

取得APIingactlドライラン
適用範囲の明示

すべての分析結果に、根拠と適用範囲を。

IngaDBが返すのは数値だけではありません。その数値が何に基づいているのか、 モデルの適用範囲はどこまでなのかを、データとして併せて返します。

◎ 分析結果に必ず付属する情報

各結果には、監査に使える付帯情報がデータとして含まれます。

  • 計算の基になった入力リビジョン
  • 各確率の根拠となるインシデントデータ
  • 生成された各ゲートの根拠(メカニズム事実)
  • 生成を打ち切った枝の一覧と、その理由

▣ 結果の信頼性を守る設計

書き込み経路を制限し、計算結果の説明可能性を保ちます。

  • ツリー生成は読み取り専用。結果を返すだけで、何も書き込まない
  • What-if分析は保存データに影響しない
  • 変更・リビジョン更新・差分記録は原子的にコミット
  • 破壊的な操作には明示的な確認が必要
一つのデータ基盤

記録から分析まで、一つのデータベースで。

モデル化・定量化・最新性の管理。三つの機能が一つのパイプラインとしてつながります。

01
因果モデル

「何が壊れたか」ではなく「どう壊れるか」を記述する。

イベントとAND/ORゲートを型付きのグラフデータとして保存。故障モード・伝播経路・冗長性を 登録すれば、フォールトツリーは描かずに生成できます。

イベントとゲートメカニズム事実ツリー自動生成
因果モデルの詳細
02
決定論的分析

リスクを、再現可能な計算で定量化する。

カットセット、経験ベイズによる確率推定、重要度指標、固定シードの不確実性区間。 同じ入力からは、常に同じ数値が得られます。

カットセットFussell-VeselyBirnbaumP5 / P50 / P95
03
リビジョン管理

古くなった結果に、すぐ気づける。

すべての分析に入力リビジョンを記録。データや構成が変わると、 結果を古くした変更そのものを差分として返します。

リビジョン記録最新性の判定変更差分
エージェントとエンジン

エージェントに聞く。答えはエンジンが計算する。

対話はエージェント、計算は決定論的エンジン。What-if分析は保存データに触れず、 リビジョン付きで実行されます。

エージェント — packaging-line リビジョン42
シール漏れの発生確率を半減できたら、ライン停止はどう変わる?
✓ What-if✓ エンジン計算
現状(リビジョン42)4.94%
→
半減シナリオ4.07%
≈1/1.2

エンジンで検証しました。シール漏れを半減すると、最上位事象「ライン停止」は 4.94%から4.07%に低減します。保存データには触れていません。

同じ質問を、もう一度。

同じ入力なので、結果も同じです — 4.07%(リビジョン42)。 思いつきの数字は返しません。

本番稼働の実例

同じエンジンが、実際の製品で動いています。

弊社の故障ナレッジ基盤「Causation」は、不具合報告書や保全記録をAIで構造化し、 対策効果を計算エンジンの数字で示すSaaSです。IngaDBと同じ因果分析エンジンの上で、 「抽出はAI、承認は人、計算は決定論的エンジン」という分担のまま本番運用されています。

Causation
過去トラを、資産に変える。
Causationのフォールトツリー画面。包装ラインの計画外停止をANDゲートとORゲートで分解し、各イベントに実測由来の確率が付いているhozen.cognitech.dev — フォールトツリー画面(実物)
さらに詳しく

ここから先は、ドキュメントで。

ここまでがIngaDBの中核です。具体的な使い方、システムへの組み込み方、 性能の実測値はドキュメントにまとめています。

IngaDBの設計思想

適用範囲を明示した、世界モデル。

因果推論は、範囲を定めれば世界モデルとして実装できます。IngaDBはその範囲をデータとして提供します。 設備がどう故障するかというメカニズムをフォールトツリーに変換し、記録されたインシデントで定量化し、 計算時点のリビジョンを記録する。モデル自身が適用範囲の終わりを把握しており、 生成を打ち切った枝とその理由を必ず示します。

決定論的

同じ入力からは、常に同じ結果が得られます。

根拠データに基づく

確率はインシデントの記録から推定され、根拠が併記されます。

適用範囲を明示

どの結果にも、モデルの適用範囲の終わりが示されます。

よくある質問

導入前に、よくいただく質問。

検討にあたって参考になる情報をまとめました。掲載のないご質問は [email protected] までお寄せください。

IngaDBとは何ですか?

因果分析に特化したデータベースです。フォールトツリーと、そこに紐づくインシデントデータを保存し、 カットセット・確率・重要度指標・不確実性区間といった決定論的なリスク分析を実行します。 モデルやデータが変わったとき、どの結果がまだ有効かも追跡します。

確率はどのように求めていますか?

記録されたインシデントから、経験ベイズ法で推定します。データの少ないイベントは ワークスペース全体の情報で補完(プーリング)され、すべての確率に推定の根拠が併記されます。

フォールトツリーは手で描く必要がありますか?

いいえ。故障モード・伝播経路・冗長性をメカニズム事実として一度登録すれば、 ハザードごとのフォールトツリーはIngaDBが生成します。生成は読み取り専用で、 各ゲートの根拠を示し、打ち切った枝もすべて理由つきで報告します。

モデルやデータが変わったらどうなりますか?

すべての分析結果には、計算の基になったリビジョンが記録されています。変更後は結果が まだ有効かどうかを判定し、無効になっていた場合は、原因となった事実・インシデント・ 構成変更を差分として示します。

AIエージェントから使えますか?

使えます。APIを記述するコマンドカタログがingactlも駆動するため、エージェントはカタログを同期し、 各ルートの契約と必要権限を確認し、ドライランを経てから実行できます。検索、因果経路、根拠データ、 重要度、カットセットの取得ルートがあり、結果はすべて決定論的でリビジョン付きです。

どのように導入しますか?

自社インフラで動かすセルフホスト型です。単一バイナリをPostgreSQL 16と並べて実行し、 付属のDocker Composeファイルならコンテナ二つで起動できます。APIキー、RBAC、監査ログを 標準搭載し、OpenAPI契約から生成されたTypeScript / Pythonの型付きクライアントも含まれます。

因果を、意思決定の基盤に

リスク判断に、たどれる根拠を。

フォールトツリー、インシデントデータ、リビジョン管理の分析基盤を、お使いのシステムに。