財務部が移転価格の文書と過去のグループ内取引の検討の記録を Vertex AI Search で検索し、新しいグループ内取引の価格の決め方の根拠を、取引の種類と相手の国で絞った引用付きでそろえる

処理の起点を決める

事業部が依頼のフォームを送ったことを起点にします。 フォームの取引の種類は、製品の販売・部品の供給・役務の提供・技術の使用料・貸付の利息の5つから選ばせ、相手の子会社は一覧から選ばせます。自由な文で書かせると、同じ子会社が略称や現地の名前で届き、絞り込みが外れます。

担当が自分で問い直すこともできるようにします。 顧問の税理士法人との相談のあとで「同じ国で役務の提供の例は」と追加で調べるときは、検討の画面から取引の種類と国を選び直して問い合わせます。公式ページにある、前の問い合わせのセッションの ID を渡す方法で、同じ検討の続きとして扱います。

入力データを集める

質を決めるのは、検討の記録の「そのときの機能の区分」です。 過去の約400件には、この項目がありません。担当の2名が、ローカルファイルのその年度の機能とリスクの節を見て、件ごとに付けます。 全件を一度に付ける必要はなく、直近3年の件から付けます。

依頼のフォームの事業部の説明は、検索の問い合わせ文にだけ使います。 事業部の説明に「現地で保証の対応もしてもらう予定」と書かれていれば、機能の区分が変わる兆しとして、検討の画面にもそのまま出します。

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

ローカルファイルは、節ごとに1つの文書に分け、メタデータに子会社・国・事業年度・節の種類・取引の種類を持たせます。 公式ページでは、非構造のデータのメタデータは JSON Lines（NDJSON）のファイルで、各行に id、structData（または jsonData）、Cloud Storage の文書を指す content の mimeType と uri を持たせるとされています。1つの節は、たとえば次の1行にします。

{"id": "lf-th01-fy2025-s07",
 "structData": {"doc_kind": "local_file", "entity": "TH01", "country": "TH",
                "fiscal_year": 2025, "section": "independent_price_method",
                "txn_types": ["parts_supply", "service"],
                "function_class": "contract_manufacturer"},
 "content": {"mimeType": "application/pdf", "uri": "gs://<bucket>/lf/TH01/2025/s07.pdf"}}

section は、ローカルファイルの並びに合わせて決めます。 国外関連取引の詳細（txn_detail）、機能及びリスク（function_risk）、算定方法（independent_price_method）、比較対象取引（comparables）を分けます。検討の記録は doc_kind を review、方針は policy にします。公式ページでは、取り込めるファイルの上限は200MBで、一度に100,000ファイルまで取り込めるとされています。

AIへ渡す前に整形する

1. 子会社の引き当て … フォームの子会社を子会社の台帳で引き、番号・国・直近の事業年度・機能の区分を決めます
2. 取引の種類のそろえ … フォームの5つの種類を、データストアの txn_types の値に置き換えます
3. 問い合わせ文の組み立て … 取引の種類と事業部の説明から、「部品の供給の対価の算定方法と検証の対象の選定の理由」のような文を作ります
4. 絞り込みの条件の組み立て … 答えの側はその子会社の直近の年度と方針、一覧の側は同じ取引の種類と国の過去の検討に分けます
5. 機能の区分の比較の準備 … 台帳のいまの区分を持っておき、一覧の各件の区分と比べられるようにします

4番目で、答えの側を「その子会社の直近の年度」に限るのは、年度をまたいだ文がまじると、別の年の前提で答えが作られるからです。 過去の年度は、一覧の側で年度を付けて見せます。

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

filter（決め方の理由の答え）:
  (doc_kind: ANY("local_file") AND entity: ANY("TH01")
   AND fiscal_year = 2025
   AND section: ANY("independent_price_method", "function_risk"))
  OR (doc_kind: ANY("policy") AND txn_types: ANY("parts_supply"))
filter（過去の検討の一覧）:
  doc_kind: ANY("review") AND txn_types: ANY("parts_supply")
  AND country: ANY("TH", "VN", "ID") AND fiscal_year >= 2021

公式ページでは、ANY は指定した値のどれかに完全に一致するときに真になり、数の項目は <・<=・>・>=・= で比べられ、AND・OR と括弧で組み合わせられるとされています。絞り込みに使う項目は、スキーマの画面でインデックス可能にしておく必要があります。一覧の側の国を近い国に広げるかは、移転価格の担当が決めた組み合わせの表で決めます。

AIに処理させる

answer メソッドにさせるのは、その子会社の直近のローカルファイルと方針から、算定方法の選定の理由、検証の対象の選び方、機能とリスクの整理を、文書の言葉のまま引用付きでまとめることです。 新しい取引にどの算定方法を使うべきかは、書かせません。

search メソッドにさせるのは、過去の検討の一覧と、比較対象取引の利益率の箇所の原文の抜き出しです。 抽出型のセグメントは最大10件、前後のセグメントも最大3つずつ付けられると公式ページにあり、利益率の幅の文の前後に、比較対象の選び方の文を付けて見せます。

3行目がいちばん起きやすい失敗です。 答えを短くまとめさせると、「営業利益率はおおむね○％前後」のように範囲を1つの数に丸めます。 数字は答えに入れさせず、抜き出しの側で見せます。

指示内容を固定する

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

あなたは財務部の移転価格の担当のための、文書の資料係です。
検索で見つかったローカルファイルとグループの方針だけを根拠に、次の順で答えてください。

1. 算定方法の選定の理由（選んだ方法と、ほかの方法を選ばなかった理由）
2. 検証の対象の選び方と、その理由
3. 各社が担う機能と負うリスク
4. 方針の該当する条項と承認の手順

守ること：
- 文書の言葉のまま書いてください。言い換えないでください。
- 利益率、価格、金額、比率の数字を書かないでください。数字は「原文の抜き出しを参照」と書いてください。
- 新しい取引にどの算定方法を使うべきかを書かないでください。
- 過去の例が新しい取引に当てはまるかを書かないでください。
- 会社の名前、国、事業年度は原文の表記のまま写してください。
- 見つからない項目は「記載なし」と書いてください。
- 検索結果に無いことを書かないでください。

「数字を書かない」を入れるのは、答えの文章の中では、どの年度のどの比較対象から出た数字かが見えなくなるからです。 数字は抜き出しの側で、事業年度と節を付けて見せます。

「当てはまるかを書かない」を入れるのは、モデルが親切に「本件にも同様の方法が適切と考えられます」と結びがちだからです。 その一文は、検討の結論のように読まれます。

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

公式ページでは、基準に届かない答えは返されず、LOW_GROUNDED_CONTENT が理由として返る例があります。引用の位置は UTF-8 のバイト単位なので、日本語の答えに印を差し込むときは文字の位置に直します。

出力形式を固定する

中継プログラムが、応答と子会社の台帳の値を次の形にそろえて検討の画面に渡します。

{
  "request_id": "",
  "txn_type": "parts_supply",
  "entity": "",
  "country": "",
  "latest_fy": 2025,
  "function_class_now": "",
  "basis_answer": "",
  "skipped_reason": "",
  "citations": [
    { "sentence": "", "doc_id": "", "fiscal_year": 0, "section": "", "quote": "" }
  ],
  "past_reviews": [
    { "review_id": "", "entity": "", "country": "", "fiscal_year": 0,
      "method": "", "tested_party": "", "function_class_then": "",
      "function_changed": false, "advisor_note": "" }
  ],
  "figures": [
    { "doc_id": "", "fiscal_year": 0, "segment": "", "prev": "", "next": "" }
  ],
  "session_id": ""
}

1つ目の理由は、function_changed で前提の違う例を見分けられることです。 過去の検討の function_class_then と、いまの台帳の function_class_now が違えば真にし、一覧の行を灰色にして「機能の区分が違う」と出します。 判定は文字列の比較だけで、AIには判断させません。

2つ目は、figures を basis_answer と別に持てることです。 利益率の幅は抜き出しの原文のまま、事業年度と前後の文を付けて画面の別の枠に出します。答えの文章と数字が同じ枠に並ぶと、数字が答えの結論のように読まれます。

3つ目は、citations に事業年度を持てることです。 引用の元が直近の年度でなければ、中継プログラムがその文を外します。

システムへ連携する

顧問の税理士法人への相談は、いまどおり担当がメールと打ち合わせで行います。 検討の画面の内容を資料として書き出せるようにしますが、送るかどうか、どこまで送るかは担当が決めます。

人が確認する

1. 機能の区分を見る … 過去の検討の灰色の行と、事業部の説明に書かれた機能の変化の兆しを確かめます
2. 引用の原文を読む … 答えの文ごとに、ローカルファイルの原文の節を開いて確かめます
3. 数字は原文で見る … 利益率の幅は抜き出しの原文と事業年度で読み、答えの文章からは読みません
4. 参考にする例を選ぶ … 前提が同じ例だけを検討の材料に残します
5. 結論を記録する … 決まった価格と理由、そのときの機能の区分を検討の記録に書きます

1番目と4番目を省かないでください。 前提の違う例を材料に入れると、税理士法人との相談がその例の説明から始まり、かえって時間がかかります。

目標は、30件をならして1件50分です。 原文を読み、参考にする例を選び、材料を整える時間です。経緯を知っている2名は、毎月、選ばれた例と結論を見比べます。 灰色の行が参考に選ばれていれば、台帳の機能の区分が古いか、区分の付け方が粗いかのどちらかです。

例外に対処する

2行目の「年度が古いことを出す」は、決算の前後に毎年起きます。 ローカルファイルの作成は年に1度なので、次の年度の文書ができるまでの数か月は、1つ前の年度の前提で答えることになります。

記録を残す

• 依頼の内容と、そのとき引いた子会社の台帳の値（直近の年度、機能の区分）
• 絞り込みの条件、answer メソッドと search メソッドの応答の全文
• 担当が参考に選んだ例と、外した例と理由
• 税理士法人に渡した資料と、意見の要旨
• 決まった価格と理由、そのときの機能の区分

最後の行が、次の検討の材料になります。 そのときの機能の区分を記録に残しておくと、数年後に同じ子会社の検討をするときに、前提が変わったかどうかが一目で分かります。