造船所の設計部が過去の船の仕様書と建造・保証工事の記録を Vertex AI Search で検索し、主要寸法の近い船の仕様と、その仕様の項で起きた不具合を根拠付きで引く

処理の起点を決める

設計者が検討の画面で、条件と問いを入れて送信したことを起点にします。 引合いのメールが届いたことを起点にして自動で動かす形にはしません。引合いの条件は、営業と設計者が読み合わせて、どの範囲で探すかを決めてから入れるほうが当たります。 船主の要望の書き方は引合いごとにまちまちで、そのまま検索の条件にはなりません。

送信すると、search メソッドと answer メソッドを同時に呼びます。 過去の船の一覧が先に出て、答えはそのあとに出ます。

同じ検討を問い直すときは、同じ会話として続けます。 公式ページでは、前の問い合わせのセッションの ID を渡すと続きとして問えるとされています。

入力データを集める

質を決めるのは、不具合と手直しの記録の「関係する仕様書の項の番号」です。 20年分の記録に、保証工事の担当と設計者が一緒に項の番号を付けます。 付けられないものは「項の特定なし」として残し、空欄にはしません。

船主の名前は、メタデータでは区分の記号に置き換えます。 仕様書の本文には船主の名前が書かれていますが、絞り込みに要るのは「どの船主の系列か」の区分で、名前そのものは要りません。 区分と名前の対応表は、設計部の外に出さない台帳で持ちます。

データの取得方法を決める

仕様書は、項ごとに1つの文書に分けて入れます。 1隻の仕様書を1つの文書のまま入れると、荷役の装置の項を問うても、同じ仕様書の別の項から引用されることがあります。項ごとに分け、メタデータに船番・主要目・項の番号を持たせます。 公式ページでは、非構造のデータのメタデータは JSON Lines（NDJSON）のファイルで、各行に id、structData（または jsonData）、Cloud Storage の文書を指す content の mimeType と uri を持たせるとされています。1つの項は、たとえば次の1行にします。

{"id": "spec-S1234-H-07-03",
 "structData": {"doc_kind": "spec", "hull_no": "S1234", "ship_type": "bulk",
                "dwt": 61200, "loa_m": 199.9, "breadth_m": 32.24, "draft_m": 13.0,
                "delivered": "2019-03-15", "owner_group": "OG-07",
                "section_no": "H-07-03", "section_area": "cargo_handling",
                "owner_request": false},
 "content": {"mimeType": "text/plain", "uri": "gs://<bucket>/spec/S1234/H-07-03.txt"}}

不具合と手直しの記録にも、同じ section_no を持たせます。 不具合の記録は doc_kind を defect、建造中の手直しは rework にし、仕様書の項と同じ番号で引けるようにします。 公式ページでは、取り込めるファイルの上限は200MBで、一度に100,000ファイルまで取り込めるとされています。

仕様書を項ごとに分けずに入れる部分（巻末の機器の一覧表など）は、データストアを作るときに文書の分割とレイアウトの解析を有効にします。 公式ページでは、文書の分割はデータストアを作ったあとに有効・無効を切り替えられず、見出しを各チャンクに付ける includeAncestorHeadings は既定で無効とされています。表はレイアウトの解析で検出されます。作るときに決めます。

AIへ渡す前に整形する

1. 範囲の組み立て … 入れた載貨重量・長さ・幅・喫水の範囲を、数値の項目の絞り込みにします
2. 船種のそろえ … 「BC」「ばら積み」「バルカー」などを、主要目表の船種の記号にそろえます
3. 項の分野の特定 … 検討したい項を、仕様書の章と分野の記号（荷役、バラスト、居住区など）に置き換えます
4. 引渡しの年の範囲 … 古い規則で建造された船を外すかを、設計者が選んだ範囲で絞ります
5. 問い合わせ文の作成 … 問いの文に、分野の名前と船種を足して問い合わせ文にします

1番目が、言葉の検索と違うところです。 本文には「61,200 t」とも「DWT 61,200」とも書かれます。主要目表の数値をメタデータに持たせて範囲で絞ります。

絞り込みの条件は、たとえば次のようになります（公式ページの書き方による）。

filter（仕様書の項）:
  doc_kind: ANY("spec")
  AND ship_type: ANY("bulk")
  AND dwt: IN(55000i, 66000i)
  AND breadth_m: IN(32.0i, 32.3i)
  AND section_area: ANY("cargo_handling")
  AND delivered >= "2012-01-01"
filter（不具合・手直し）:
  doc_kind: ANY("defect", "rework")
  AND section_no: ANY("H-07-03", "H-07-04")

公式ページでは、ANY は指定した値のどれかに完全に一致するときに真になり、数値の項目は IN で範囲を指定でき（下限は既定で含み、上限は既定で含まない。i と e で明示できる）、日付の項目は ISO 8601 の文字列で比べられるとされています。絞り込みに使う項目は、スキーマの画面でインデックス可能にしておく必要があります。

不具合の絞り込みは、一覧で選ばれた船の項の番号から2回目に組み立てます。 最初の検索で当たった仕様書の項の section_no を集め、その番号の不具合と手直しを別に引きます。 項の番号を介してつなぐのは、機器の名前の書き方が記録ごとにそろっていないからです。

AIに処理させる

answer メソッドにさせるのは、絞り込んだ過去の船の仕様書の項と、結び付いた不具合・手直しの記録から、今回の問いに関係する仕様と、その仕様で起きたことを引用付きで短くまとめることです。 仕様の良し悪しの判断はさせません。

2行目がいちばん大事です。 過去の船の仕様は、その船が建造されたときの規則の版に合わせたものです。 答えが「この仕様で問題ない」と書くと、規則が変わったあとの船にそのまま持ち込まれます。

指示内容を固定する

answer メソッドでは、回答の口調や詳しさをプロンプトの前置き（preamble）で指定できます。前置きを次のようにします。

あなたは造船所の設計部の資料係です。設計者の問いについて、
検索で見つかった過去の船の仕様書の項と、不具合・手直しの記録だけを根拠に、
次の順で短く答えてください。

1. 似た船の仕様（船番、項の番号、機器の型式・容量・配置の要点）
2. その項で起きた不具合（船番、発生日、現象、処置、再発の有無）
3. 建造中の手直し（船番、内容）
4. 同じ項で船によって仕様が違うところ
5. 船主の要望で決めたと書かれている仕様（項の番号と船番）

守ること：
- 今回の船にどの仕様を採用すべきかを書かないでください。
- 船級の規則や条約に適合するかを書かないでください。
- 不具合の原因を断定しないでください。記録に書かれた現象と処置を写してください。
- 不具合の記録が見つからない項は「不具合の記録なし」と書いてください。
  不具合が無かったと書かないでください。
- 船番、項の番号、数値、単位は原文の表記のまま写してください。
- 船主の名前を書かないでください。区分の記号で示してください。
- 検索結果に無いことを書かないでください。

「不具合が無かったと書かない」を入れるのは、記録の無さと不具合の無さが違うからです。 保証期間中の不具合の記録は、項の番号を付けた範囲でしか結び付いていません。 付けていない古い記録に同じ現象が書かれているかもしれず、「無かった」と書くと、設計者がそこで調べるのをやめます。

あわせて、answer メソッドの設定を次のようにします。

公式ページでは、maxReturnResults の既定は10・最大は25で、支持が基準に届かない答えは返されず、理由として LOW_GROUNDED_CONTENT が返るとされています。引用の位置（startIndex／endIndex）は文字ではなく UTF-8 のバイト単位なので、日本語の答えに引用の印を差し込むときは、中継プログラムでバイトから文字の位置に直します。

出力形式を固定する

中継プログラムが、2つの呼び出しの応答を次の形にそろえて検討の画面に渡します。

{
  "request_id": "",
  "conditions": { "ship_type": "", "dwt_range": [0, 0], "breadth_range": [0.0, 0.0], "section_area": "" },
  "answer_text": "",
  "support_score": 0.0,
  "skipped_reason": "",
  "citations": [
    { "sentence": "", "doc_kind": "spec | defect | rework", "hull_no": "", "section_no": "", "quote": "", "owner_request_flag": false }
  ],
  "ships": [
    { "hull_no": "", "ship_type": "", "dwt": 0, "loa_m": 0.0, "breadth_m": 0.0, "delivered": "", "owner_group": "", "defect_count": 0 }
  ],
  "unlinked_defect_note": "",
  "session_id": ""
}

1つ目の理由は、ships を答えと別に持てることです。 条件に合う船が何隻あり、そのうちどの船で不具合が何件あったかが、答えの文を読む前に一覧で分かります。 答えが1隻の仕様だけを引いていても、ほかの船を一覧から開けます。

2つ目は、owner_request_flag で船主の要望を見分けられることです。 真の引用は画面で色を変え、自社の標準と分けて読めるようにします。

3つ目は、unlinked_defect_note に「項の番号が付いていない不具合の記録がある」ことを書けることです。 一覧の船番で、項の特定なしの記録が残っていれば件数を出し、設計者が必要なら原本を見に行けるようにします。

システムへ連携する

検討メモは、設計者がいつもの書式で書きます。 画面から引用を貼り付けられるようにしますが、メモそのものを自動で作ることはしません。 検討メモは船主との打合せの元になり、何を採用して何を変えたかの理由が書かれていなければならないからです。

船主の系列ごとに見られる人を分けるかは、最初に決めます。 公式ページでは、データストアの文書単位のアクセス制御は、データストアを作るときにしか有効にできず、文書のメタデータの acl_info に読める人とグループを並べ、1文書の読み手は3,000までとされています。この機能は Preview です。設計部の全員が全部の船を見てよいなら使わず、船主との契約で見られる人を限る系列だけ、別のデータストアに分けます。

人が確認する

1. 一覧の船を先に見る … 条件に合う船の数と、主要目の違いを確かめます
2. 引用の原文を開いて読む … 仕様書の項と不具合の記録を、原文で読みます
3. 建造の年と規則の版を確かめる … 前の船が建造されたときの規則と、今回の船の規則が同じかを確かめます
4. 色の変わった引用を確かめる … 船主の要望で決めた仕様は、今回の船主に持ち込めるかを考えます
5. 項の特定なしの記録を必要に応じて見る … 件数が出ていれば、原本を開きます
6. 検討メモを書き、設計の責任者に回す … 採用・変更の案と理由を書きます

3番目を省かないでください。 同じ仕様でも、建造された年の規則の版が違えば、今回はそのまま使えないことがあります。 答えは規則の版を判断しません。

目標は、90件をならして1件30分です。 一覧を見て、原文を読み、規則の版を確かめ、検討メモを書く時間です。船番を探して聞いて回る時間がほぼ無くなり、読む時間と考える時間が残ります。

例外に対処する

4行目が、最初の数か月は多く出ます。 20年分の記録すべてに項の番号を付けるのは時間がかかるので、新しい船から順に付け、付いていない記録があることを画面で隠さないようにします。

記録を残す

• 検討の依頼（条件、問いの文、依頼した設計者、日時）
• 絞り込みの条件、search メソッドと answer メソッドの応答の全文、セッションの ID
• 画面に出した答えと、外した文、色を変えた引用
• 設計者が開いた原文と、検討メモに貼り付けた引用
• 仕様書と記録の版、データストアに入れた日
• 項の番号を付けた担当と日付

4つ目が、いまは残っていない記録です。 どの船のどの項を参考にして今回の仕様を決めたかが残れば、次の船でその仕様に不具合が出たときに、どこから持ち込んだかをさかのぼれます。