インタビュー冒頭の質問がゼロコンテキスト（標準タスクのベースライン仮説を提示せず、常に白紙の質問になる）

[claude]

Requested by sunagawa · Slack thread

課題（現状の挙動）

標準タスク（約20業務、docs/kb/workflows/_standardized-20/*）でインタビューを開始すると、どのタスクでも「業務の正式名称と通称を教えてください」「関係者はどなたですか？」といった完全に白紙・ゼロコンテキストの質問から始まる。対象業務が固定資産税でも印鑑登録でも、開口一問目の文言はほぼ同一で、事前に分かっているはずの情報（正式名称・目的・根拠法・所管部署の当たり）が一切活用されていない。

職員としては、「一般的には資産税課が担当だと思いますが、他に関係する部署はありますか？」のように仮説を提示して確認・訂正してもらう形の方が回答しやすく、聞き取り効率も上がる。現状は毎回ゼロから聞かれるため、労力に対して得られる情報が薄い。

原因調査（コード確認済み）

1. lib/server/interview/slots.ts の SLOT_DEFS が定義する質問テンプレート（taskName / purpose / legalBasis / stakeholders 等のスロット）は、全タスクで完全に同一の白紙テンプレートであり、タスクごとに一切変化しない。
2. lib/kb/loader.ts の loadStandardFlowSummary() は mermaid フロー本体と displayName のみを followup.ts に渡しており、flow-standard.md の YAML frontmatter（spec_law / psid_service_category 等）は質問生成プロンプトに一切注入されていない。
3. lib/server/interview/followup.ts の buildSystemPrompt には「推測や断定はしない」という明示ルールがあり、これが「仮説を提示して確認してもらう」という望ましいUXと構造的に矛盾している。
4. この白紙前提の設計は、フォーク元（チームみらいのインタビューアプリ）から引き継いだものと推測される。フォーク元とこのアプリでは目的（標準フローベースのインタビュー）が異なるため、単なるデータ不足ではなく設計のミスマッチである可能性が高い。

あるべき姿

標準タスク（約20業務）については、インタビュー冒頭でタスクメタデータから導いたベースライン仮説（正式名称・通称、一般的な目的、典型的な根拠法、所管部署の当たり、よく関連する部署）を提示し、確認・訂正を求める質問として開始する。ベースラインデータが存在しないタスク（「その他」／カスタムタスク等）では、現状の白紙質問にフォールバックする。

技術的な着手ポイント

コンテンツ（flow-standard.md へのベースラインデータ追記、docs/kb/concepts/department-naming-baseline.md の新設）は別途人が作成予定。本Issueはコード側の対応を追跡する。

• flow-standard.md の frontmatter を拡張し、baseline オブジェクトを追加（common_name / common_aliases / purpose_generic / primary_department_hint / related_department_hints / department_naming_note。典型的な根拠法は既存の spec_law を再利用）。
• 部署名が自治体規模で揺れる問題（例：人事課↔総務課、固定資産税課↔税務課）を都度書かないよう、docs/kb/concepts/department-naming-baseline.md のような横断参照ファイルを既存 concepts/ の作法に合わせて新設。
• コード変更（本Issueのスコープ）：
  1. KB frontmatter の型／スキーマに baseline を追加（lib/kb/types.ts の FlowStandardFrontmatterSchema 等）。
  2. lib/kb/loader.ts の loadStandardFlowSummary（または新規関数）を拡張し、baseline フィールドを呼び出し元に渡す。
  3. lib/server/interview/followup.ts の buildFollowupRequest（相当）を拡張し、baseline データが存在する場合にLLMコンテキストへ注入する。
  4. buildSystemPrompt の「推測・断定しない」ルールに明示的な例外を追加：ベースラインデータがある場合は仮説として提示し確認・訂正を求める、無い場合は現状どおり推測しない。
  5. lib/server/interview/slots.ts の SLOT_DEFS（またはフォローアップのプロンプトテンプレート）を更新し、taskName / purpose / legalBasis / stakeholders 等のスロットで、ベースラインデータがある場合は仮説確認形、無い場合は現状の白紙形の文言にフォールバックする。

受け入れ条件

• baseline frontmatter フィールドがKB型定義・スキーマに追加され、パースできる
• loadStandardFlowSummary（または新規関数）が baseline フィールドを呼び出し元に渡す
• baseline データを持つタスクでインタビューを開始すると、開口の質問が仮説提示・確認形（例：「一般的には人事課だと思いますが、他にどんな関係部署がありますか？」）になる
• baseline データを持たないタスク（「その他」等）では、現状どおり白紙の質問にフォールバックする
• buildSystemPrompt の「推測・断定しない」ルールに、ベースラインがある場合の例外が明記される
• 既存の他業務のインタビュー進行が壊れない

優先度

中〜高。#34（本筋からの脱線防止）の対応後、聞き取り効率・職員の回答負担を下げる改善として着手を推奨。コンテンツ（ベースラインデータ本体）の作成待ちであり、コード側の受け皿を先行して用意しておくと着手が早い。

関連Issue

関連: #34, #36, #40（ただし別問題。冒頭質問のゼロコンテキスト問題は上記いずれとも別の根本原因であり、重複・統合はしない）

[claude]

Requested by Yuki Kawabe ryoma 川邊悠紀 · Slack thread

このスレッドでの追加調査の記録

1. e-Gov法令APIの調査結果

e-Gov法令API（Version 1）は以下の4種のエンドポイントのみを提供している。

• 法令名一覧取得
• 法令取得（全文）
• 条文内容取得（条・項・別表）
• 更新法令一覧取得

取得は法令番号または法令IDを指定するのが基本であり、キーワードによる全文検索機能はV1には無い。また、部署名（所管部署）に相当するデータは一切含まれていない。「更新法令一覧取得API」の AuthFlg は「所管課確認中」を示すフラグであり、部署名そのものではない。

→ 結論：e-Gov法令APIは根拠法令（spec_law）の裏取りや条文引用の確認には使えるが、ベースラインRAGの中心的な要素（正式名称・目的・所管部署）の代替データにはならない。

2. 新しい方向性：pgvectorでの統合検索

バックエンドがSupabase構成であることを踏まえ、pgvectorを使って「法令データ」と「独自データ（baseline知識、KBのknowledge-notes等）」を同一のベクトルインデックスで検索できるようにする案が出た。

法令データのソースとして、e-Gov法令XMLをあらかじめMarkdown形式に変換済みの公開データセットが使えないか調査した。

• DaisukeHori/japan-law（第一候補）: e-Gov法令XML → Lawtext → Markdown（相互参照リンク付与）というパイプラインで、憲法・法律・政令・省令など約8,000件をMarkdown化して収録（data/markdown/{constitution,acts,cabinet_orders,imperial_orders,misc}/）。GitHub Actionsによる週次/日次更新があり、リリースタグも切られている。実データ（data/markdown/constitution/321CONSTITUTION.md）を直接fetchし、Markdown形式で条文が入っていることを確認済み。
• yno9/lawcode-jp（代替候補）: 収録数は301件（いわゆる六法＋主要法令）と少ないが、法令1件＝1ファイルでYAML frontmatter（identifier / law_num / enforced_at / law_type）が付いており、引用時のメタデータとしては扱いやすい。ただしメンテナンス頻度は低い（スター/フォークなし）。
• 除外した候補：aluqas/gitlaw-jp（XMLのみでMarkdownではない）、yamachig/Lawtext（独自の .law.txt 形式でMarkdownそのものではない）、japanese-law-analysis 系ツール群（XML/JSON中心）、legalize-dev（法令のMarkdown化＋Git管理という同種コンセプトだが対象31カ国に日本は含まれない）。

3. 今後の検討点

pgvectorでの統合検索は法令テキストの「取得」を効率化できるが、依然として**「業務の正式名称・目的・所管部署」等の組織知識（本Issueのベースライン仮説の中核）は法令データからは得られず、別途人手で用意する必要がある**という整理は変わらない。法令Markdownデータセットの導入は根拠法令の裏取り・引用精度向上には有効だが、本Issueの受け入れ条件（baseline frontmatル等）の代替にはならない点は留意する。

[claude]

Requested by sunagawa · Slack thread

設計修正：baseline の重点を「名称・所管部署」から「関連部門・関連業務」へ

プログラムリード（sunagawa）から以下の指摘があったため、本Issue本文「技術的な着手ポイント」節で提案した baseline フィールド案を修正する（Issueの立て直し・別Issue化ではなく、既存提案への修正コメント）。

業務の名称や所管部署は自治体によって異なるから、そもそもそれを聞くことはそこまで重要ではない。むしろ、関連部門や関連業務の方が重要。

つまり、common_name / 所管部署名は自治体ごとに表記・組織構造が揺れるため、これを仮説の中心に置いても「訂正されるだけ」で終わりやすく、ベースライン仮説としての価値が低い。一方で「この業務にはどの部署・どの業務が関わってくるか」という関係構造は、名称が違っても自治体間でパターンが共通しやすく、聞き取り効率への貢献度が高い。

フィールド優先度の修正

Issue本文で提案した6フィールドを以下のように再区分する。

低優先度／任意（参考情報として残すが、開口質問の主役にはしない）

• common_name
• common_aliases
• primary_department_hint
• department_naming_note

これらは削除はしないが、「仮説として提示して確認を求める」対象からは外し、必要なら補助的なヒント（プロンプト内の参考メモ程度）に留める。purpose_generic は名称・部署に紐づかない業務目的の記述なので、この修正の対象外（従来どおり）。

最優先フィールド（新設・昇格）

• related_department_hints を昇格し、related_departments_and_processes として再定義する。
• 単に「関連する部署名」だけでなく、関連する標準タスク／業務プロセスも併せて持たせる。実装上は下記のような構造を想定：

  baseline:
    related_departments_and_processes:
      - department: "資産税課"
        related_task: "workflows/_standardized-20/kotei-shisan-zei/"  # 他KBスラッグへの相互参照
        note: "評価替え時の連携"
      - department: "住民課"
        related_task: "workflows/_standardized-20/jyumin-ido/"
        note: "..."

  部署名だけ・業務名だけの要素も許容し、両方揃っていなくてもよい（任意項目の緩やかな配列）。

既存の depends_on フロントマターとの関係（調査結果）

調査の結果、depends_on は既に存在し、実データも入っているが、今回必要な「関連部門・関連業務」を十分にはカバーしていない。部分的に重なるのみで、置き換えにはならない。

• 実例（jyumin-ido/flow-standard.md、jido-teate/flow-standard.md、kaigo-hoken/flow-standard.md、kokumin-kenko-hoken/flow-standard.md、seikatsu-hogo/flow-standard.md 等で確認済み）：

  depends_on:
    - target: "concepts/household.md"          # または他の standardized-20 スラッグへのパス
      type: "definition_dependency"             # data / timing / definition / authority / notification
      note: "..."

• depends_on の type は data_dependency / timing_dependency / definition_dependency / authority_dependency / notification_dependency の5種（docs/kb/CONTRIBUTING.md 記載）。ターゲットは他の workflows/_standardized-20/* スラッグか concepts/*.md。
• つまり depends_on は「この業務が処理を始める前提として、どのデータ・定義・権限に依存するか」という一方向・かつデータ/定義レベルの依存関係を表す構造であり、対をなす triggers（この業務の完了が後続業務を呼び出す条件）と合わせて「業務間の連鎖」の一部は既にモデル化されている。
• しかし以下はdepends_on/triggers では表現できない：
  1. 部署名・部署情報がフロントマターに一切存在しない。現状、部署（担当課）はMermaid図の subgraph ラベル内にのみ記述され、frontmatterから構造的に参照できない。
  2. データ依存関係を伴わない「よく一緒に関わる部署／業務」（並行関係・非依存的な関連）は対象外。
  3. depends_on/triggers は任意項目であり、埋まっていないタスクも多い（scripts/check-kb-seed.ts にも「inkan-toroku: frontmatter に triggers / depends_on なし」という例が明記されている）。

結論：depends_on（および対をなす triggers）は「関連業務」の一部（データ/定義/権限レベルの依存に基づく他タスクへの相互参照）を既にカバーしているため、新設する related_departments_and_processes は重複を避けるべく、業務側の参照については既存の depends_on / triggers の target パスと同じ表記規則（workflows/_standardized-20/[slug]/ への相対パス）を再利用する。一方で「部署」については depends_on/triggers に対応する概念が存在しないため、related_departments_and_processes が新規にカバーする。

docs/kb/stakeholders/*.md との関係（調査結果）

docs/kb/stakeholders/ は「構造的知識 vs 関係的知識」を区別するフォルダで、対象は外部・準外部組織（社会福祉協議会、民生委員、地域包括支援センター、都道府県、日本年金機構、後期高齢者医療広域連合、福祉事務所、児童相談所、教育委員会、消防本部、自衛隊等）に限定されている（docs/kb/stakeholders/README.md）。

• これは今回の「関連部門」のうち、外部・準外部組織が関係先になるケース（例：国民年金業務における日本年金機構、後期高齢者医療業務における広域連合）には有効に使える。これらは自治体内部の課名のような表記揺れが少なく、related_departments_and_processes からリンクする価値が高い。
• 一方、今回問題になっている「自治体内部の部署名の揺れ」（人事課↔総務課、固定資産税課↔税務課等）は、stakeholders/ が明示的に対象外としている領域（内部の同一自治体内の部署は「関係的知識」寄りではなく、そもそも構造的知識としてこのフォルダの類型表に存在しない）。
• したがって stakeholders/ は本修正に部分的に関連（外部組織を関連部門として参照する際の裏付けKBとして活用可能）だが、内部部署の相互関連までは代替しない。内部部署間の関連は related_departments_and_processes 側で直接記述する。

まとめ（この修正で変わること）

• Issue本文の受け入れ条件・実装ステップ（lib/kb/types.ts の FlowStandardFrontmatterSchema 拡張、loadStandardFlowSummary 拡張、followup.ts への注入、buildSystemPrompt の例外追加、slots.ts のスロット文言）自体は変更なし。対象となるフィールド名と重点のみ本コメントの内容に置き換える。
• 開口の仮説確認質問は「一般的には◯◯課だと思いますが」ではなく、「この業務は一般的に△△業務・□□課と連携することが多いですが、実際の連携先を教えてください」のような関連部門・関連業務中心の文言に修正する。
• common_name 等は完全に削除せず、低優先度の参考情報として baseline に残す（将来的に自治体側の名称が分かった場合の記録用途は残す）。