コンテンツにスキップ
NBS Workshop

Casefile Agent

役割

Casefile Agent は BWTS IOT パイプラインの履歴アナリストです。IOT Manager がフェーズ1調査を派遣すると、このエージェントは過去事象、船隊全体のパターン、解決履歴を検索して前例を見つけます。その出力により、マネージャーはこの問題が以前にも見られたか、どのように解決されたか、そしてその修正が実際に機能したかを知ることができます。

調査プロセス

graph TB
    START["Receive Investigation\nTask from IOT Manager"] --> S1


    subgraph "Search Strategy"
        direction TB
        S1["Same-Vessel\nHistory"]
        S2["Fleet-Wide\nPattern Search"]
        S3["Resolution\nEffectiveness"]
        S4["Contextual\nSimilarities"]


        S1 --> S2 --> S3 --> S4
    end


    S4 --> REPORT["Compile\nCASEFILE REPORT"]


    style START fill:#1a1a2e,stroke:#0f3460,stroke-width:2px,color:#fff
    style S1 fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style S2 fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style S3 fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style S4 fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style REPORT fill:#1a1a2e,stroke:#e94560,stroke-width:3px,color:#fff

  1. 同一船舶履歴

    同一船舶と機器タグの過去アラートと調査を検索します。これは最も関連性の高い検索です — 同一ハードウェアが同一運転条件下にある場合。同じアラームコード、同じパラメータ、同時発生した関連アラームを探します。

  2. 船隊全体パターン検索

    検索を船隊内のすべての船舶で一致する機器種別に拡大します。同じアラームコードや症状が姉妹船で発生しているかを探します。船隊全体のパターンは、しばしばシステミックな問題 — ファームウェアのバグ、ロット欠陥、複数設置に影響する環境要因 — を示します。

  3. 解決有効性

    ステップ1および2で見つかったすべての一致する過去事象について、その解決が実際に機能したかを確認します。同じアラームが数日や数週以内に再発したか?修正は恒久的な解決だったか、一時的な回避策だったか?このステップにより、すでに試されて失敗した修正を推奨することをパイプラインが防ぎます。

  4. 文脈的類似性

    アラームコードが異なっていても、文脈要因を共有する事象を検索します。関連する文脈には、アラート時の運転モード(Treatment、CIP、Standby)、最終 CIP サイクルからの時間、季節/地理的条件(熱帯水域、寒冷気候港)、船舶運用プロファイル(タンカー vs バルクキャリア、短航海 vs 長航海)が含まれます。

データソース

完了したアラート・タスク

LifeOSAI Issue Search

?q= パラメータを使って、過去の完了した調査タスクを検索します。完了した各タスクには、元のアラート、IOT Manager の統合、確定原因、適用された解決策が含まれます。これは構造化された調査履歴の最も豊富なソースです。

PARA メモリ・グラフ

Knowledge Graph

PARA メモリシステムは、過去の調査から抽出された知識を原子的な YAML 事実 — 機器の癖、再発パターン、既知の故障モード、得られた教訓 — として保存します。これらの事実はセッションを跨いで持続し、タスク履歴に完全に記録されていない可能性のある組織的知識を捕捉します。

IoT イベント・データベース

bwts_iot_events Table

PostgreSQL 内の生イベントログで、すべての BWTS アラート、状態変化、オペレーター・アクションのタイムスタンプ付き記録を含みます。統計分析に使用 — このアラームは何回発火したか?発生間の平均時間は?頻度は増加しているか?

出力形式

すべての Casefile Agent 応答は、CASEFILE REPORT 構造に従います。

セクション内容
Same-Vessel History同一船舶/機器の過去事象 — アラームコード、日付、発見原因、適用された解決策
Fleet-Wide Matches船隊内の他船舶での同一または類似事象 — 機器タグ、日付、共通点
Resolution Effectiveness各過去解決策について:持続したか?アラームは再発したか?該当する場合は再発までの時間
Similar Incidents文脈的に類似する事象(異なるアラームだが類似の条件や故障モード)
Summary重要な所見を箇条書きに抽出 — 履歴がこの新規アラートについて何を物語るか
Data Gaps判明できなかったこと — 欠落記録、不完全な解決策、履歴のない船舶

ツール

graph LR
    CF["Casefile\nAgent"] --> LOS["LifeOSAI\nIssue Search\n?q= parameter"]
    CF --> PARA["PARA Memory\nFiles\nKnowledge graph"]
    CF --> DB["db_query.py\nbwts_iot_events"]


    LOS --> TASKS[("Completed\nTasks")]
    PARA --> YAML[("YAML\nFacts")]
    DB --> PG[("PostgreSQL")]


    style CF fill:#1a1a2e,stroke:#e94560,stroke-width:3px,color:#fff
    style LOS fill:#16213e,stroke:#0f3460,stroke-width:2px,color:#fff
    style PARA fill:#16213e,stroke:#0f3460,stroke-width:2px,color:#fff
    style DB fill:#16213e,stroke:#0f3460,stroke-width:2px,color:#fff
    style TASKS fill:#0d1b2a,stroke:#1b9aaa,stroke-width:1px,color:#fff
    style YAML fill:#0d1b2a,stroke:#1b9aaa,stroke-width:1px,color:#fff
    style PG fill:#0d1b2a,stroke:#1b9aaa,stroke-width:1px,color:#fff
ツール目的
LifeOSAI Issue Search?q= クエリ・パラメータで完了した調査タスクを検索。過去アラート、確定原因、適用解決策を返す。
PARA Memory Files抽出された事実 — 機器の癖、再発パターン、得られた教訓 — について知識グラフを問い合わせ。セッション間で持続。
db_query.pyPostgreSQL の bwts_iot_events テーブルに対する SQL クエリを実行。統計分析 — アラート頻度、再発間隔、イベント・クラスタリング — に使用。

してはならないこと

センサー分析しない

テレメトリ・テーブルを問い合わせない、トレンドを分析しない、センサー値を解釈しない。ライブと過去のセンサーデータは Data Analysis Agent の領域です。

保全チェックしない

保全スケジュール、計画作業指示、サービス記録にアクセスしない。保全データは PMS Agent に属します。

マニュアル検索しない

機器マニュアル、トラブルシューティング・ガイド、メーカー文書を検索しない。それは Manual Agent の責務です。

レポート生成しない

クライアント向けレポートを作成しない、メールを送信しない、HTML 出力を整形しない。レポート作成と配信は Report Agent の仕事です。