税理士事務所が国税不服審判所の公表裁決事例を争点と判断の段落ごとに索引し、顧問先の論点に近い事例と判断の分かれ目を根拠付きの所内メモにまとめる

処理の起点を決める

取り込みと検索は、別々のきっかけで動かします。

取り込みは、毎月1回、審判所のトピックスを確かめることで起動します。審判所は四半期ごとに「〜までの裁決事例の追加等」というトピックスを出し、同じ日に「公表裁決事例要旨」と「公表裁決事例」に事例を追加し、裁決要旨検索システムにも要旨を追加します。 毎月見れば、追加から1か月以内に索引へ入ります。毎日見に行く必要はありません。

検索は、顧問先の担当者が相談の欄を送ったことを起点にします。所内チャットの文面を直接読むことはしません。チャットには顧問先の名前や数字が混ざるので、事実関係と論点を所定の欄に書き直してもらいます。 書き直すこと自体が、論点を整理する作業になります。

入力データを集める

質を決めるのは、相談の欄の事実関係の書き方です。 「売上を少なく申告した」だけでは、仮装の事例も単純な過誤の事例も同じように当たります。「誰が、何を見て、どの帳票を作ったか」まで書くと、判断の段落の言葉と重なります。 欄には書き方の例を置きます。

要旨の《ポイント》と《参考判決・裁決》は、別の項目に持たせます。 審判所は、内容に特徴がある事例や参考となる判決・裁決がある事例について、その特徴や判決等の情報を要旨に付記しています。 一覧の上で、この印のある事例を先に読めるようにします。

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

事例のページは、審判所のホームページから取得します。 公表裁決事例の目次は四半期ごとのページ（裁決事例集の番号ごと）に分かれ、そこから各事例の全文のページと要旨のページに辿れます。 取得するのは追加された四半期の目次と、その中の事例のページだけです。

利用の条件は、審判所の利用案内で確かめます。 著作権は特記の無い限り審判所に帰属し、権利表記の無いものは「公共データ利用規約（第1.0版）」に準拠した条件で利用できます。 出典は「出典：国税不服審判所ホームページ（当該ページのURL）」と書き、編集・加工したときはそのことを別に書き、国が作ったかのように見せてはいけないとされています。所内メモには、この形で出典を必ず入れます。

取得の間隔は空けます。 1四半期の追加は数件なので、1ページごとに数秒の間を置いても数分で終わります。 審判所のサイトに負荷を掛ける取り方はしません。

判断の段落の中の該当箇所は、highlight で返させます。 OpenSearch の既定のハイライトは unified で、文に分けてそれぞれを文書のように扱い、BM25 で採点します。 断片の長さ fragment_size は既定で100文字、数 number_of_fragments は既定で5、order を score にすると関連の強い順に並びます。fragment_size を0にすると文を途中で切らずに返します。 引用は文の単位がよいので0にします。

AIへ渡す前に整形する

1. 段落に分ける … 全文を「事案の概要」「関係法令」「基礎事実」「争点」「争点についての主張」「当審判所の判断」「結論」の見出しで分けます
2. 争点ごとに分ける … 「争点1」「争点2」と番号の付いた主張と判断を、争点の番号で対応させます
3. 段落の種類を付ける … 判断の段落には judgment、主張の段落には claim_requester（請求人）・claim_office（原処分庁）を付けます
4. 属性を付ける … 裁決日、関係税法、争点区分の見出し、結果、事例のURLを各段落に持たせます
5. 相談の欄を整える … 金額・日付・固有名詞を「金額A」「日付B」に置き換え、顧問先が分かる情報を外します
6. 重複の検知 … 同じURLの事例が既にあれば、取り込みません

2番目と3番目を軽く見ないでください。 主張の段落と判断の段落は、同じ言葉を多く使います。請求人は「単なる過誤である」と主張し、判断はそれを退けます。種類を付けずに探すと、主張の言葉に当たった事例が上に来ます。 検索は judgment の段落を中心にし、主張の段落は補助に使います。

AIに処理させる

検索は、二つの条件を組み合わせます。

more_like_this の既定値は、短い相談の文章に向いていません。 公式の既定では、入力の中で2回未満しか出ない語は無視され（min_term_freq が2）、5件未満の文書にしか出ない語も無視されます（min_doc_freq が5）。数行の事実関係ではほとんどの語が1回しか出ないので、min_term_freq を1に下げます。

検索の問い合わせは、たとえば次の形になります。

{
  "query": {
    "bool": {
      "filter": [
        { "term": { "tax_law": "国税通則法" } },
        { "term": { "section_type": "judgment" } }
      ],
      "should": [
        { "more_like_this": {
            "fields": ["text"],
            "like": ["{相談の事実関係}"],
            "min_term_freq": 1,
            "max_query_terms": 25 } },
        { "match": { "issue_text": "{相談の論点の一文}" } }
      ],
      "minimum_should_match": 1
    }
  },
  "highlight": {
    "fields": { "text": { "fragment_size": 0, "number_of_fragments": 5, "order": "score" } }
  }
}

税法と段落の種類は filter に置き、点数に混ぜません。 絞り込みは「当たるか当たらないか」だけを決め、近さの順は事実関係の文章と論点の言葉で決めます。 争点区分の見出しは絞り込みに使わず、一覧の表示に使います。区分の名前が相談の論点とずれていると、近い事例を落とすからです。

当たった段落は、事例ごとにまとめてから生成AIに渡します。 同じ事例の判断の段落が3つ当たったら、1つの事例として扱い、その事例の争点の段落も添えます。渡す事例は点数の上位5件までにします。数を増やすと、遠い事例の決め手まで並び、読む量が戻ってしまいます。

生成AIにさせるのは、当たった事例ごとに判断の分かれ目を並べることだけです。

最初の行が、この構成の線引きです。 「この事例と同じく仮装に当たる可能性が高い」と書かせると、読み手は事例を読まずに結論だけを使い始めます。 並べるのは事実までにします。

指示内容を固定する

あなたは税理士事務所の審理の担当で、顧問先の相談に近い
国税不服審判所の公表裁決事例を、所内メモのために整理する立場です。
渡した検索結果（裁決の段落）だけを根拠にしてください。

【相談の論点】{issue}
【相談の事実関係】{facts}
【検索結果】事例ごとに、争点の段落と判断の段落を渡します。

【やること】
事例ごとに次を書いてください。
1. 事案の要点（1〜2文）
2. 相談の論点にあたる争点（裁決の書き方のまま）
3. 審判所が結論を導いた決め手の事実（箇条書き）
4. 相談の事実関係と、3の事実の重なりと違い
5. 顧問先に追加で確かめるべき事実

【厳守事項】
- 検索結果に書かれていないことを書かないでください。
- 3の決め手の事実は、判断の段落から引いてください。
  請求人や原処分庁の主張の段落から引かないでください。
- 顧問先がどうなるか、処分が認められるかを書かないでください。
  「この事例では〜と判断された」までにしてください。
- 裁決の後に法令が変わったかどうかを書かないでください。
- 相談の事実関係に書かれていない事実を、補って比べないでください。
  分からないことは5の確かめる事実に回してください。
- 相談に近くない事例は、無理に関連付けず「関連が薄い」と書いてください。

「主張の段落から引かない」を明記しないと、請求人の言い分が決め手のように書かれます。 主張の段落は判断の段落と同じ言葉を使い、しかも分かりやすく書かれています。審判所が退けた主張を決め手として並べると、メモが逆の意味になります。

「法令が変わったかを書かない」を入れているのは、生成AIに改正の有無を判断させないためです。 渡しているのは裁決の段落だけで、その後の改正は検索結果に入っていません。書かせれば推測になります。

出力形式を固定する

生成AIへの指示は、検索結果のブロックで渡します。 公式のドキュメントでは、search_result のブロックに source・title・content を入れると、自社の文書を検索結果として引用付きで答えます。 source に事例のURL、title に裁決日と争点区分、content に段落を1つずつのテキストブロックで入れます。

引用はテキストブロックの単位で付きます。 返る引用には cited_text と、content の何番目から何番目かを示す start_block_index・end_block_index が入ります。段落を細かいブロックに分けておくほど、引用が細かくなります。 また、引用の設定はリクエストの中のすべての検索結果でそろえる必要があり、混ぜるとエラーになります。

所内メモの下書きは、引用を組み込んで次の形にします。

{
  "issue": "",
  "cases": [
    {
      "url": "",
      "decided_on": "",
      "tax_law": "",
      "issue_heading": "",
      "result": "",
      "has_point_note": true,
      "summary": "",
      "decisive_facts": [
        { "text": "", "cited_text": "", "block": [0, 1] }
      ],
      "overlap_with_client": "",
      "difference_from_client": "",
      "facts_to_confirm": []
    }
  ],
  "source_notice": "出典：国税不服審判所ホームページ（各事例のURL）を加工して作成"
}

1つ目の理由は、決め手の事実ごとに引用を持てることです。 decisive_facts の1行ごとに cited_text が付くので、審理の担当は引用の文を元のページで探すだけで確かめられます。

2つ目は、decided_on を事例ごとに持つことです。 承認のときに、裁決日より後の改正を確かめる対象がすぐ分かります。

3つ目は、source_notice を必ず入れることです。 所内メモは事例を要約し加工したものなので、利用規約の例に沿って加工したことを書きます。

システムへ連携する

顧問先の管理システムとはつなぎません。 顧問先の帳簿や申告書を検索基盤に入れる構成にはせず、担当者が書いた事実関係だけを使います。

承認した所内メモは、論点の名前で保存します。 顧問先の名前と日付のファイル名をやめ、税法と論点で探せるようにすると、次に同じ論点が来たときに前のメモが先に見つかります。

人が確認する

1. 引用の確認 … 決め手の事実の引用を、事例の元のページで確かめます。判断の段落からの引用かを見ます
2. 改正の確認 … 裁決日より後に、関係する条文や通達が変わっていないかを確かめます
3. 顧問先の事実の確認 … 「確かめるべき事実」を顧問先の担当者に渡し、聞き取りを頼みます
4. 承認 … 所内メモとして承認し、論点の名前で保存します

2番目を省かないでください。 公表裁決事例の案内には、裁決の前提となった税制、税法等が変更となっている場合があることに留意するよう書かれています。平成の初めの事例が、いまの条文で同じに読めるとは限りません。

承認の目安は、1件あたり22分です。 引用の確認に10分、改正の確認に8分、メモの手直しと承認に4分ほどを見込みます。引用は全部を開くのではなく、決め手の事実として並んだものだけを開きます。 開いた引用と直した箇所は記録に残し、同じ事例が次に使われたときの確認を軽くします。

例外に対処する

1行目は、出さないことが大事です。 近くない事例を並べると、読み手は「近い事例があった」と受け取ります。

記録を残す

• 取得したページの写しと、取得した日時・URL
• 段落の分け方の結果（どの見出しで分けたか、争点の対応）
• 相談の欄の中身（顧問先の名前を外したもの）、検索の条件、返した段落
• 生成AIの下書きと引用、審理の担当が直した箇所
• 承認した所内メモと、使った事例のURL

取得したページの写しを残すのは、後でページが変わっても当時の文面を確かめるためです。 審判所は公表事例を法令の改廃や判決の結果を勘案して掲載しているとしており、文面が手直しされることがあります。

最後の行は、次の相談の入口になります。 同じ事例が何度も使われていれば、所内の判断の基準として整理しておく価値があります。