IngaDBの利用例
架空の包装ラインpackaging-lineを使い、IngaDBの主な機能を6つの例で説明します。 コード例はすべてクイックスタートで構築した環境を前提としており、 そのまま実行できます。
各例は独立しているため、関心のあるものから読めます。 3番目では、AIエージェントを使って報告書から証拠レコードを作る手順を説明します。
/db/v1はバージョン管理されたHTTP APIで、SDKや独自の連携処理から利用します。 1と2では、リクエストの内容が分かるようにcurlを使います。ingactlは、インスタンスから取得したカタログを基に、/api以下の 読み取り・書き込みAPIを呼び出すCLIです。3〜6ではingactlを使用します。 どちらも同じデータを操作します。
1. フォールトツリーをデータとして管理する
ホワイトボード上のフォールトツリーを、検索・差分確認・履歴追跡ができる 型付きトポロジーとして保存します。
イベントとゲートは型付きデータとして書き込みます。トポロジー全体の置換は一括して行われるため、 読み取り側に更新途中の状態が返ることはありません。
curl -s -X PUT "localhost:9876/db/v1/graphs/$GID/topology" \
-H "X-Org-Id: $ORG" -H 'content-type: application/json' -d '{
"events": [
{"id":"E_BEARING","label":"軸受摩耗","component":"conveyor","failure_mode":"wear"},
{"id":"E_SEAL","label":"シール漏れ","component":"pump","failure_mode":"seal_leak"}
],
"gates": [
{"id":"G_TOP","label":"ライン停止","type":"OR","inputs":["E_BEARING","E_SEAL"]}
]
}'
curl -s -X POST "localhost:9876/db/v1/graphs/$GID/views/analysis" \
-H "X-Org-Id: $ORG" -d '{}' \
| jq '{p_top: .analysis.gate_quantities.G_TOP, rev: .analysis.graph_revision}'描画ツールとは異なり、ツリーを検索でき、すべての変更をリビジョン単位で追跡できます。 各分析結果には、計算に使ったリビジョンが記録されます。
2. 故障メカニズムからフォールトツリーを生成する
ハザードごとにツリーを描くのではなく、設備の故障モード・伝播・冗長性を「メカニズム事実」として 一度だけ登録します。必要になった時点で、対象のハザードに対応するツリーを生成できます。
curl -s -X POST localhost:9876/api/mechanism -H "X-Org-Id: $ORG" -d '{
"source": "manual",
"facts": [
{"component":"pump","fact_type":"failure_mode","subject":"pump","object":"seal_leak","params":{}},
{"component":"line","fact_type":"propagates_to","subject":"pump","object":"line",
"params":{"class":"omission","rule":"or"}},
{"component":"pump_house","fact_type":"redundancy","subject":"pumps","object":"pump",
"params":{"k":1,"n":2}}
]
}'
curl -s -X POST "localhost:9876/db/v1/graphs/$GID/compile" -H "X-Org-Id: $ORG" \
-d '{"component":"line","class":"omission"}' \
| jq '{top_gate_id, written, cut_branches: (.cut_branches|length)}'writtenは常にfalseです。この処理はメカニズム事実から生成した ツリーを返すだけで、データベースを更新しません。フィードバックループなど、 フォールトツリーでは表せないため処理を打ち切った枝は、理由とともにcut_branchesへ列挙されます。ポンプを二重化する場合は、冗長性の事実を追加して もう一度生成します。
レスポンスには生成されたツリーが含まれます。以下は、実際の値を変えずに抜粋し、注釈を付けたものです。
{
"written": false, ← ①
"top_gate_id": "G_LINE_OMISSION",
"nodes": [
{ "id": "E_CONVEYOR_BEARING_WEAR", … },
{ "id": "G_PUMPS_OMISSION",
"label": "pumps fails (2 of 2)", ← ②
"properties": { "gate_type": "AND" } },
…
],
"provenance": [
{ "gate_id": "G_LINE_OMISSION",
"rule": "or",
"from_facts": [
"propagates_to(conveyor -> line)", ← ③
"redundancy(pump_house, pumps)" ] } ],
"cut_branches": [] ← ④
}- ① 読み取り専用の生成処理なので、データベースは更新されません。
- ② 冗長性の事実（k=1, n=2）がANDゲートに変換されています。
- ③ 各ゲートの根拠になったメカニズム事実です。
- ④ 打ち切った枝の一覧です。このモデルには該当する枝がありません。
3. 報告書から証拠レコードを作成する
過去のインシデント報告書から、出典付きの証拠レコードを作成します。 IngaDBは、そのレコードを基にイベントの確率を計算します。たとえば、入力となる報告書は次のような内容です。
【報告書26-041】5/12夜勤
充填ライン3号機、段取り替え後の立ち上げ中に停止。調査の結果、
供給ポンプP-101のメカニカルシールから微量の漏れを確認。
シール交換で復旧。停止時間45分。
【報告書26-055】6/3日勤
3号機のポンプでまた圧力低下。前回と同じ箇所からの漏れ。
予備シールに交換。次回定修で軸受も点検のこと。
【報告書26-072】7/18夜勤
コンベアC-3の軸受から異音。振動値は管理値内だが
摩耗の初期兆候あり。グリスアップして経過観察。Claude CodeやCodexなどのコーディングエージェントを使うと、文章から型付きレコードの候補を 抽出できます。まず、ingactl skillが出力する操作ガイドをエージェントに渡します。 このガイドはインスタンスのカタログから生成されるため、サーバーが提供するAPIと一致します。
ingactl sync
ingactl skill # 検索 → 契約確認 → ドライラン → 実行、の操作ガイドを出力指示には次の3点を明記します。候補をIngaDBが受け付ける型に限定すること、根拠箇所を 原文のまま引用すること、表記揺れの対応表を先に作ることです。この例では、 「供給ポンプP-101」と「3号機のポンプ」を同じ設備として対応付けます。 エージェントが出力する候補JSONは、次のようになります。
{
"aliases": [
{"component": "pump",
"mentions": ["供給ポンプP-101", "3号機のポンプ"]}
],
"incidents": [
{"id": "INC-26-041", "event_id": "E_SEAL",
"component": "pump", "failure_mode": "seal_leak",
"occurred_at": "2026-05-12", "confidence": "high",
"source_span": "供給ポンプP-101のメカニカルシールから微量の漏れを確認"},
{"id": "INC-26-055", "event_id": "E_SEAL",
"component": "pump", "failure_mode": "seal_leak",
"occurred_at": "2026-06-03", "confidence": "high",
"source_span": "3号機のポンプでまた圧力低下。前回と同じ箇所からの漏れ"},
{"id": "INC-26-072", "event_id": "E_BEARING",
"component": "conveyor", "failure_mode": "wear",
"occurred_at": "2026-07-18", "confidence": "medium",
"source_span": "コンベアC-3の軸受から異音。…摩耗の初期兆候あり"}
]
}source_spanには原文をそのまま記録します。レビュー時は、候補と元の報告書を 照合して内容を確認します。報告書26-072をmediumとした理由が「故障ではなく初期兆候」だという 判断も、この形式なら確認できます。
人が承認した候補だけを登録します。mutateと記されたルートでは実行前に確認が入り、--projectで指定したプロジェクトIDは、カタログで定義された位置に設定されます。 インシデントはcomponentとfailure_modeを使って、手書きか自動生成かを問わず、 ツリー上のイベントに対応付けられます。
cat > approved-incidents.json <<'EOF'
{"incidents": [
{"component": "pump", "failure_mode": "seal_leak",
"symptom": "シール漏れによる停止45分（報告書26-041）"},
{"component": "pump", "failure_mode": "seal_leak",
"symptom": "圧力低下・同一箇所の漏れ（報告書26-055）"},
{"component": "conveyor", "failure_mode": "wear",
"symptom": "軸受異音・摩耗の初期兆候（報告書26-072）"}
]}
EOF
ingactl api call data/incidents/append \
--project 'packaging-line' --file approved-incidents.json \
--dry-run # 解決済みリクエストを、送信せずに確認
ingactl api call data/incidents/append \
--project 'packaging-line' --file approved-incidents.json登録後は、読み取り専用のAPIで証拠レコードと分析結果を確認します。
ingactl api call data/event-evidence \
--project 'packaging-line' --param node_id=E_SEAL -o json
ingactl api call data/analysis --project 'packaging-line' -o json当社の故障ナレッジ基盤「Causation」は、 不具合報告書や保全記録をAIで構造化し、対策効果を計算するSaaSです。 IngaDBと同じ因果分析エンジンを使い、 「抽出はAI、承認は人、計算は決定論的エンジン」という役割分担で運用しています。
AIによる抽出結果は、そのまま登録せず候補として扱います。 人が内容を確認して承認し、IngaDBが入力を検証して計算します。エージェントには必要な読み取り権限だけを与え、 書き込みは承認済みのレコードに限定します。これにより、計算結果から引用元までたどれます。
4. 分析結果が最新か確認する
週次のリスクレビューで使う分析結果が最新かを確認します。無効になっている場合は、 計算後に何が変わったのかを差分で確認できます。
ingactl api call data/analysis --project 'packaging-line' -o json
# → 計算済みビュー、staleの状態、changes_sinceの差分
curl -s "localhost:9876/db/v1/graphs/$GID/deltas?from=0" \
-H "X-Org-Id: $ORG" | jq '.deltas[] | {revision, kind}'これにより、「先週から証拠が3件増え、トポロジーは変わっていない」といった変更点と、 再計算後の確率を確認してから会議に提示できます。
5. 保存データを変更せずに対策案を比較する
シール強化への投資を検討するため、対策前後の最上位事象の確率を比較します。 What-if分析は保存データを変更せずに実行できます。
# 強化シール導入後の想定値でモデルを評価する（結果は保存されない）
ingactl api call pipeline/what-if \
--project 'packaging-line' \
--set 'overrides=[{"target_id":"E_SEAL","value":0.005}]' -o jsonWhat-if分析の結果は保存されません。結果には、評価の基準にしたリビジョンが含まれます。 稟議書には、対策前後の確率と基準リビジョンを記載できます。
6. AIエージェントの回答に分析結果を使う
「ライン停止の一番の要因は？」という質問に対し、エージェント自身の記憶ではなく、 IngaDBが決定論的に計算した重要度指標を使って回答します。
# 1. 対象を探す
ingactl api call data/tree/search \
--project 'packaging-line' --param query=シール -o json
# 2. 最上位事象までの因果経路を辿る
ingactl api call data/causal-path \
--project 'packaging-line' --param node_id=E_SEAL -o json
# 3. 重要度で「一番の要因」に答える
ingactl api call data/importance \
--project 'packaging-line' --param node_id=E_SEAL -o json各レスポンスには計算に使ったリビジョンが含まれます。そのため、エージェントは 「rev 42時点で、Fussell-Vesely重要度が最も高いのはシール漏れです」のように、 計算時点を明示して回答できます。