------
2026/07/17
------
まず次の処理を、現場運用員にNeptuneやGremlinを意識させない作りにする。
・データ登録、検索、バックアップ、リストア、障害確認
これらを全て、Web画面かスクリプトで実行できるようにする。

どうしてもGremlinを発行する必要がある個所は、
極力「定型テンプレート化」し、現場は値を変えるだけで済むようにする

運用設計書を作る。
システム構成図、データモデル、障害時の連絡フロー、バックアップ・リストア手順
バージョンアップ手順、性能監視方法、証明書更新など定型作業

運用手順書（マニュアル）を作る。
まず試作した環境で試行し、発生した現象、トラブルに対して自分が対処した作業に対して、
「こんなトラブルが起きたら、ここを見て、このボタンを押す」という、現場の運用フローに特化したマニュアル（手順書）を整備

データモデル仕様書を作る
RDBにおけるER図のように、頂点の一覧、エッジの一覧、プロパティの一覧、
必須項目や一意制約の一覧を作る。

APIを標準化したGremlin操作用ライブラリを作る。
検索、登録、削除、トレースのAPI

運用教育
運用演習
部品ロットを検索する、リストア訓練、監視運用テスト

AWS環境構築において
IAM、VPC、セキュリティグループなどのセキュリティ設計（現場部門やIT/セキュリティ部門と協業）
インフラのコード化（CloudFormation / CDK / Terraform）? 属人化を避け、誰でも同じ手順で構築・復旧できる状態にする

Neptune Serverlessなど運用負荷が低い構成を検討

障害時の連絡フローと合わせて、本番稼働後の運用分担の合意形成
・エスカレーションパスの定義（現場 → 研究所 → AWSサポート）
・「研究所として本番稼働後もどこまで・いつまで支援するか」の合意形成（無期限のフルサポートは現実的でないため、期限や範囲を明確化）
・どのレベルの障害は現場で対応し、どこから研究所にエスカレーションするかの基準に合意

追加改善の分担と日程計画
・現場からの機能要望、データ項目変更などの要件を集約する窓口設置
・QA・製造ラインからのフィードバックを吸い上げる仕組み

外部ベンダーによる保守委託（Neptune運用実績のあるSIer等）
------