どこに置くか — 三つの構成パターン。
IngaDBは単体で完結するツールではなく、既存のシステム構成に組み込む一つの層です。 よくある三つの置き方と、そこでIngaDBが担う役割・担わない役割を紹介します。
1. 監視スタックの隣に
センサーや稼働データの異常検知は、お使いの時系列基盤の仕事です。IngaDBはその先を引き受けます。 原因の構造（フォールトツリーとメカニズム事実）、実績由来の確率（経験ベイズ）、 そして重要度指標による「どの故障モードから直すか」の優先順位。 既存の監視スタックには手を入れず、報告書や点検記録という眠っていたテキストの証拠が、 検知の「その後」を説明する材料になります。
接続は疎結合です。検知側からはアラート発生時に data/analysis や data/importance を照会し、レビューの場では changes_since の差分で 「先週から何が変わったか」を確認します。
2. 自社アプリの土台に
フォールトツリーの型付き保存、カットセット列挙、証拠からの定量化、リビジョン追跡—— この一式を自前で実装する代わりに、エンジンごと組み込む構成です。 IngaDBはPostgreSQLと並べて動く単一バイナリで、公開ポートを持たない内部サービスとして 配置できます。契約（OpenAPI）から生成されたTypeScript / Pythonクライアントが付属するため、 アプリ側は型付きの呼び出しだけを書きます。
画面はあなたのプロダクトのまま、数値の出所はIngaDBのリビジョン付き応答—— 「この確率はどの証拠から、いつ時点の計算か」に、アプリの外からでも答えられる構成になります。
3. 文書とエージェントの間に
組織の因果知識の多くは、報告書やFMEA、熟練者の頭の中にあります。この構成では、 文書から候補を組み立てるのはコーディングエージェント（Claude CodeやCodexなど）、 承認するのは人、検証と計算はIngaDBという分担をとります。 エージェントは ingactl skill --format claude-skill が生成する操作ガイドで 自己ブートストラップし、書き込みは必ずドライランと確認を挟みます。
結果として、熟練者の知見は「読み物」ではなくメカニズム事実というデータとして残り、 ハザードごとのツリーへいつでもコンパイルできます。具体的な手順は報告書から証拠レコードを作成する手順を参照してください。
どの構成でも、IngaDBが担うのは「因果の保存・検証・決定論的な計算」です。 異常検知や時系列の蓄積、画面づくりは隣のコンポーネントの仕事として残ります。 役割の境界が明確なほど、それぞれの層を独立に入れ替えられます。