士業事務所のAzure OpenAI Service導入メモをClaude Codeで作る: 個人情報を入れない社内FAQ

税理士・社労士・司法書士事務所で、社内FAQをAI化しようとして、顧問先名、マイナンバー、調査メモ、契約条件が混ざったExcelをそのまま渡すのは危険です。所長が見ているのは、FAQ候補表、顧客別メモ、Teamsの質問、Azure OpenAIの設定画面です。今日まず直す1箇所は、FAQ候補を「AIへ渡す」「人が見る」「絶対に渡さない」の3列に分ける作業です。

この記事では、士業事務所がAzure OpenAI Service、現在のMicrosoft Foundry Models sold by Azureを試す前に、Claude Codeで導入メモを作る流れを書きます。狙いは、AIチャットを急いで置く話ではありません。社内FAQ、顧客情報、権限、content filter、ネットワーク、ログ、責任者を表にして、問い合わせ削減と情報漏えい対策を同時に進めることです。

この記事の要点

• 士業事務所の社内FAQでは、便利さより先に、顧問先名、マイナンバー、契約条件、個別判断をAIへ渡さない線引きを作る。
• Azure OpenAI / Microsoft Foundry側のデータ処理、content filtering、RBAC、network、monitoringは導入メモに分けて書く。
• Claude Codeには、FAQ候補の列名、伏せたサンプル、公開資料、社内規程を読ませ、分類表を作らせる。
• 人が見る範囲は、法務・税務・労務・登記の判断、個人情報、顧問契約、回答公開、ログ閲覧、Azure権限です。
• 成果はPVではなく、問い合わせ一次回答時間、誤回答件数、AIへ渡さない情報の検出件数、研修相談率で見ます。

士業の社内FAQで起きる失敗シーン

士業事務所の社内FAQは、表向きは「新人が質問しやすい仕組み」です。ところが材料を集めると、顧問先別の相談メモ、税務調査の記録、就業規則の個別修正、相続人の関係図、委任状、本人確認資料のメモまで混ざります。これをAIの検索対象にすると、FAQではなく案件ファイルの横断検索になります。

最初に見る具体物は、FAQ候補表、顧客別メモ、過去問い合わせCSV、Teamsの質問、社内手順書、Azureリソースの権限表です。Microsoft Learnのデータ・プライバシー説明では、Azureで販売されるFoundry Modelsに渡すpromptやcompletionは他の顧客やOpenAI等のモデル提供者には使われず、基盤モデルの学習にも使われないと説明されています。一方で、statefulな機能、uploaded data、abuse monitoring、地域やdeployment type、ログ方針は利用形態で確認が必要です。だから事務所側の入口で「何を渡すか」を決めます。

参考にした一次情報は、Data, privacy, and security for Models sold by Azure、Foundry Models sold by Azure、content filtering、managed identity、role-based access control、private endpoint network setup、monitor Azure OpenAIです。SaaSのFAQ境界はVertex AI連携メモでも扱いました。

Claude Codeに任せる範囲と人が見る範囲

士業事務所でClaude Codeに渡すのは、FAQ候補のタイトル、カテゴリ、公開資料のURL、伏せたサンプル、社内規程の見出し、Azure権限表の役割名です。顧問先名、個人番号、住所、口座、調査内容、相続関係、契約金額、担当者名、相談の結論は渡しません。

Claude Codeに任せる範囲は、FAQ候補の分類、個人情報っぽい列名の検出、Azure導入メモの骨子、RBACの確認表、content filterで止まった時の社内対応メモ、ログ方針の質問作りです。人が見る範囲は、専門判断、個人情報保護、顧問契約、回答の公開可否、Azureロールの付与、private endpointの要否、運用開始の承認です。

ここで大事なのは「Azureなら安全だから全部入れる」でも「AIは危険だから何も入れない」でもない点です。公開済みの一般手順、社内教育用の共通手順、書類の提出期限のようなFAQは候補になります。顧客別判断、個別案件の経緯、マイナンバー、未公開の契約条件は別箱へ置きます。

3つのUse case

Use case 1: FAQ候補を3つの箱に分ける

• 入力: FAQ候補表、列名、公開資料、社内手順書の見出し、伏せたサンプル20件。
• 出力: AIへ渡す、人が確認する、絶対に渡さない情報の3分類表。
• 人の確認: 顧問先名、個人番号、税務・労務・登記の個別判断、契約条件を見る。

最初に作るのはAzureのリソースではなく、FAQ候補の分類表です。Claude Codeには本文を丸ごと読ませず、列名と伏せたサンプルから危ない箱を見つけさせます。人は、AIへ渡してよいか、社内だけで見るか、削除するかを決めます。

Use case 2: Azure導入メモを権限とログから作る

• 入力: Azure resource名、利用予定部署、RBAC候補、ログ閲覧者、検証環境、本番開始日。
• 出力: owner、テスト担当、ログ閲覧者、deployment管理者、監査メモの表。
• 人の確認: 管理者権限、ログ閲覧範囲、顧問先情報の扱い、private endpointの要否を見る。

Azure OpenAIやFoundry Modelsを試す時は、モデル名より先に誰が何を見られるかを決めます。Claude Codeには、RBAC表と導入メモの不足質問を出させます。人は、最小権限、ログの保存方針、ネットワーク方針を決めます。

Use case 3: 誤回答とcontent filter時の社内対応を決める

• 入力: FAQの誤回答例、content filterで止まった例、職員の質問、修正担当、承認者。
• 出力: FAQを直す、プロンプトを直す、人へ回す、回答禁止にする4分類表。
• 人の確認: 専門判断、顧客への説明、回答の公開、再発防止、研修対象を見る。

content filterは有害な内容を検出・抑止する仕組みですが、士業の誤回答を全部防ぐものではありません。Claude Codeには、止まった理由の整理と社内対応表を作らせます。人は、回答を直すのか、FAQから外すのか、専門家判断へ戻すのかを決めます。

コピペで使えるプロンプト

あなたは士業事務所のAzure OpenAI導入メモ作成担当です。
対象は社内FAQです。顧問先情報や個人情報をAIへ渡さない前提で、FAQ候補を分類してください。

入力:
- FAQ候補のタイトルとカテゴリ
- CSVの列名
- 公開資料のURL
- 伏せたサンプル20件
- Azure resource名
- RBAC候補。人名ではなく役割名
- ログ閲覧者の役割
- content filterで止まった例

確認してほしいこと:
1. AIへ渡せるFAQ候補
2. 人が確認してから渡す候補
3. 絶対に渡さない情報
4. 顧問先名、個人番号、住所、口座、契約条件、個別案件の検出
5. RBAC、ログ、network、content filter、human reviewの不足質問
6. 誤回答時にFAQ、プロンプト、データ分類、人の判断のどこを直すか

制約:
- 顧問先名、マイナンバー、相談内容、契約金額、相続関係、調査メモは扱わない
- Azureの設定変更やdeployは実行しない
- 「安全です」と断定しない
- 最後に、今日確認する5行だけを優先順で出す

動く確認コード

社内FAQ候補を分類したら、次の確認コードで危ない混入を拾えます。実際のAzure OpenAI APIを呼ぶコードではありません。AIへ渡す前のFAQ候補表と導入メモを検査し、顧問先名、マイナンバー、契約条件、RBAC、network、loggingの抜けを表にします。

// verify-internal-faq-ai-boundary.mjs
// No dependencies. Run with: node verify-internal-faq-ai-boundary.mjs
const faqCandidates = [
  {
    id: "faq-001",
    title: "年末調整の必要書類",
    audience: "internal",
    source: "public template",
    text: "扶養控除申告書、保険料控除証明書、住宅ローン控除資料の提出期限を確認する。",
    containsClientName: false,
    containsMyNumber: false,
    containsContractTerm: false,
    approvedForAi: true
  },
  {
    id: "faq-002",
    title: "A社の税務調査メモ",
    audience: "internal",
    source: "case note",
    text: "A社 代表 山田太郎 様。マイナンバー 123456789012。調査官とのやり取り。",
    containsClientName: true,
    containsMyNumber: true,
    containsContractTerm: true,
    approvedForAi: true
  },
  {
    id: "faq-003",
    title: "電子帳簿保存の確認順",
    audience: "staff",
    source: "internal checklist",
    text: "保存場所、検索項目、権限、変更履歴、例外対応を担当者が確認する。",
    containsClientName: false,
    containsMyNumber: false,
    containsContractTerm: false,
    approvedForAi: false
  }
];

const deploymentMemo = {
  dataPrivacyRead: true,
  contentFilteringRead: true,
  rbacOwner: "",
  privateNetworkDecision: "undecided",
  loggingPolicy: "",
  humanReviewOwner: "partner"
};

const problems = [];

for (const item of faqCandidates) {
  const sensitive = [];
  if (item.containsClientName) sensitive.push("client name");
  if (item.containsMyNumber || /\d{12}/.test(item.text)) sensitive.push("my number");
  if (item.containsContractTerm) sensitive.push("contract or case detail");
  if (item.approvedForAi && sensitive.length > 0) {
    problems.push({ item: item.id, fix: "remove from AI FAQ input: " + sensitive.join(", ") });
  }
  if (!item.approvedForAi && item.source !== "public template") {
    problems.push({ item: item.id, fix: "route to human review before Azure OpenAI testing" });
  }
}

if (!deploymentMemo.dataPrivacyRead) {
  problems.push({ item: "data privacy", fix: "read Azure data privacy notes before choosing data sources" });
}
if (!deploymentMemo.contentFilteringRead) {
  problems.push({ item: "content filter", fix: "read content filtering behavior and write escalation rules" });
}
if (!deploymentMemo.rbacOwner) {
  problems.push({ item: "RBAC", fix: "assign owner for who can deploy, test, and view logs" });
}
if (deploymentMemo.privateNetworkDecision === "undecided") {
  problems.push({ item: "network", fix: "decide public network, private endpoint, or pilot-only access" });
}
if (!deploymentMemo.loggingPolicy) {
  problems.push({ item: "logging", fix: "write what prompts, outputs, and request IDs may be logged internally" });
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Internal FAQ AI boundary passed.");
}

このコードで見ているのは、FAQ候補の個人情報、AI投入可否、data privacy確認、content filtering確認、RBAC owner、network方針、logging方針です。実運用では、Azure Portal、Microsoft Foundry、Entra ID、Private Endpoint、Monitor、社内の個人情報取扱規程も合わせて確認します。

Pitfall: よくある落とし穴

一つ目の落とし穴は、社内FAQという名前で顧客別メモを混ぜる点です。原因は、職員の質問が実案件から出るため、一般FAQと個別案件の境界が消えやすいからです。直し方は、公開資料、社内手順、顧客別メモ、AIへ渡さない情報の箱を先に作る形です。

二つ目は、Azure OpenAIのデータ保護説明を読んだだけで、事務所側の分類を省く点です。原因は、サービス側の保護と、自社が何をpromptへ入れるかを混同するためです。直し方は、data privacy、deployment type、uploaded data、logs、abuse monitoring、content filterを導入メモで分けます。

三つ目は、RBACを所長と担当者の感覚で決める点です。原因は、小さな事務所ほど「全員見られる方が早い」となりやすいからです。直し方は、deployできる人、テストできる人、ログを見られる人、FAQを承認する人を分けます。

四つ目は、誤回答を全部プロンプトで直そうとする点です。原因は、データ分類、FAQ本文、専門判断、人の承認のどこが悪いかを分けていないためです。直し方は、誤回答ごとに、FAQ修正、データ除外、回答禁止、人へ回す、研修対象へ分けます。

よくある質問

Q. 士業事務所でAzure OpenAIを使うなら、最初に何を作ればよいですか。

A. チャット画面ではなく、FAQ候補の分類表です。AIへ渡す、人が確認する、絶対に渡さない情報の3列を先に作ります。

Q. 顧問先名を消せばサポート履歴を使えますか。

A. それだけでは足りません。住所、契約条件、案件名、担当者名、時期、調査内容、相談の結論も手がかりになります。まず列名とサンプルを見ます。

Q. content filterがあれば誤回答は防げますか。

A. content filterは有害カテゴリの検出・抑止に関わる仕組みです。税務・労務・登記の個別判断の正しさを保証するものではありません。

Q. 成果は何で見ますか。

A. 問い合わせ一次回答時間、誤回答件数、AIへ渡さない情報の検出件数、FAQ更新件数、研修・相談への問い合わせ率で見ます。

研修・相談につなげるなら何を見るか

士業事務所のAzure OpenAI記事から相談へ進めるなら、AIチャットの見た目ではなく、データ分類と権限を見ます。職員が同じ質問を繰り返す、顧客別メモがFAQ候補に混ざる、誰がログを見られるか曖昧、誤回答時の修正先が決まっていないなら、導入前に整える価値があります。

Azure OpenAI / Microsoft Foundry、社内FAQ、RBAC、private endpoint、content filter、logging、個人情報を出さない運用メモを作りたい場合は、ClaudeCodeLabの研修・相談で相談できます。まずはFAQ候補20件を、AIへ渡す、人が確認する、絶対に渡さない情報の3列へ分けてください。

実際に試した結果

この記事では、Microsoft Learnのdata privacy、Foundry Models、content filtering、managed identity、RBAC、network、monitoringの説明を確認しました。さらに、slug、frontmatter、内部リンク、外部リンク、CTA、コードブロック、10言語ファイル、記事キューの削除対象を確認しています。今日まずやる1手は、FAQ候補20件を表にして、顧問先名、個人番号、契約条件、個別判断が混ざっていないかをチェックする作業です。