士業事務所のAzure Functions小さな自動化をClaude Codeで作る: 相談フォーム通知から始める

士業事務所の相談フォームで、相続、労務、補助金、契約書レビューの内容がそのままメール本文に流れ、送信失敗のログには相談者の氏名と本文が丸ごと残る。しかも問い合わせ通知は届いたり届かなかったりして、翌朝スタッフが「昨日の相談、見落としていないよね」と受信箱を探します。小さな自動化のつもりでも、ここは信頼に直結します。

この記事では、士業事務所がAzure Functionsで相談フォーム通知を作る時に、Claude Codeで設計メモ、確認コード、失敗時の確認表を作る手順を書きます。狙いは「メール送信Functionを置く」だけではありません。相談者の個人情報をログに残しすぎず、通知失敗を見逃さず、面談予約へ進む導線を作ることです。

この記事の要点

• 士業の相談フォーム通知は、到着メールより先に、個人情報、守秘、同意、通知失敗、予約導線を見る。
• Azure FunctionsのHTTP triggerはフォーム受信に使いやすいが、匿名公開、raw log、平文secretを放置すると危ない。
• Claude Codeには、Function構成、入力項目、ログ方針、Key Vault参照、失敗時の再通知表を下書きさせる。
• 人が見る範囲は、法律・労務・税務判断、相談本文、個人情報、広告表現、守秘、初回面談の受付可否。
• 成果はPVより、相談フォーム送信件数、通知見落とし件数、面談予約率、初回返信までの分で見る。

現場で起きる失敗シーン

士業事務所のサイトでは、相談フォームが「名前、メール、相談種別、相談本文」だけで作られがちです。Azure FunctionsでHTTP triggerを作り、POSTされた本文をメールに送れば一見動きます。けれど、相談本文には財産、家族、退職理由、給与、契約先、トラブル相手などが入ります。

一番まずいのは、トラブル調査のつもりでrequest bodyを丸ごとログに出す形です。ログは開発者だけが見るとは限りません。Azure Portal、Application Insights、外部監視、エクスポート先に残ります。士業の相談は、問い合わせ前の時点でも十分に重い情報です。

参考にした一次情報は、Azure Functions HTTP trigger、Triggers and bindings、Key Vault references、App Service authentication and authorization、Securing Azure Functionsです。仕様は変わるため、実装前に公式ページを見直します。

業務フロー: 相談フォームから面談予約までを見る

士業事務所のフォーム通知は、フォーム送信、受付メール、担当者通知、案件分類、折り返し、面談予約、相談記録の作成までが一つの流れです。Azure Functionsは、その中の「受け取る」「通知する」「記録する」の小さな部品に向いています。全部を一つのFunctionに詰めると、失敗時にどこで止まったか見えません。

最初に作る確認表は、技術設定だけではなく、事務所の受付ルールを含めます。例えば、相続は担当A、労務は担当B、補助金は受付停止中、契約書レビューは初回面談へ誘導、急ぎは電話優先、という分け方です。Claude Codeには、この業務ルールを先に読ませます。

流れ	Azure Functionsで見る点	人が見る点
フォーム受信	HTTP trigger、method、auth、rate limit	同意文、相談種別、必須項目
通知作成	件名、本文のマスク、request id	相談本文の扱い、守秘
secret管理	app settings、Key Vault references	APIキー、メール送信権限
失敗時	retry、失敗記録、アラート	相談者への折り返し
予約導線	受付完了画面、予約URL	面談可否、担当割当

この表があると、「Functionを作って」ではなく、「士業の受付に必要な事故防止を含めて作って」と頼めます。初心者でも、どの設定を見ればよいかが残ります。

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

Claude Codeに任せる範囲は、Azure Functionsの最小構成、function.json、入力バリデーション、ログ項目、Key Vault参照のメモ、通知失敗時の確認表です。相談フォームの項目名、受付ルール、メール件名、予約URL、NGログ例を渡すと、危ない箇所を洗い出せます。

人が見る範囲は、相談内容そのものです。相続、労務、税務、契約、補助金、許認可の判断はAIに任せません。フォーム文面の広告表現、守秘、同意文、個人情報、面談を受けるかどうか、緊急対応の要否は、人が見ます。

Azure Functionsでは、HTTP triggerのauthLevel、App Service認証、Function keys、Key Vault references、managed identity、Application Insightsのログ範囲を確認します。初心者向けに言うと、「URLを知っていれば誰でも送れる状態か」「相談本文がログに残るか」「APIキーがコードにあるか」をまず見ます。

3つのUse case

Use case 1: 相談フォーム通知の入力項目を整理する

• 入力: フォーム項目、相談種別、受付停止中の業務、プライバシー同意文、予約URL。
• 出力: 必須項目、任意項目、メールへ載せる項目、ログへ載せない項目、受付完了画面の文言。
• 人の確認: 相談本文、個人情報、広告表現、緊急対応、面談可否を事務所側で見る。

このUse caseでは、Claude Codeに「メール本文を作って」と頼む前に、ログに残す項目を決めます。メールへ相談本文をそのまま入れるか、管理画面のURLだけを載せるかで、情報の残り方が変わります。

Use case 2: Azure FunctionsのHTTP triggerを安全に始める

• 入力: function.json、HTTP method、authLevel、App Service認証の設定、送信元フォームURL。
• 出力: POST限定、CORS方針、匿名公開の可否、追加認証、rate limit、確認コマンド。
• 人の確認: 外部公開してよいフォームか、Bot対策、電話優先の案件、受付停止中の業務が弾けるかを見る。

HTTP triggerは便利ですが、URLを知っていれば誰でも送れる設定にすると、スパム相談や大量送信が来ます。Function keyだけで十分か、App Service認証やフォーム側のBot対策も見るかを、事務所の受付量に合わせて決めます。

Use case 3: 通知失敗と面談予約の導線を作る

• 入力: メール送信API、失敗ログ、再通知先、担当者、予約URL、受付完了画面。
• 出力: 失敗時の記録、再送条件、スタッフ通知、受付完了画面、予約ボタンの出し分け。
• 人の確認: どの相談を自動で面談予約へ送るか、どの相談を電話確認にするか、担当者不在時の扱いを見る。

通知が失敗しても、フォーム送信者には受付完了画面が出ている場合があります。だから、失敗を握りつぶさず、request id、相談種別、送信時刻、再通知先、担当者を残します。本文を丸ごとログに残すのではなく、必要な追跡情報だけにします。

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

あなたは士業事務所のAzure Functions相談フォーム通知レビュー担当です。
目的は、相談フォームの通知見落とし、個人情報ログ、平文secret、予約導線漏れを防ぐことです。

入力:
- フォーム項目
- 相談種別
- プライバシー同意文
- function.json
- Azure Functionsのapp settings案
- メール送信APIの使い方
- 受付完了画面と予約URL

確認してほしいこと:
1. HTTP triggerのmethodとauthLevel
2. App Service認証や追加保護の要否
3. 相談本文をraw logへ出していないか
4. APIキーや接続文字列をコードへ直書きしていないか
5. Key Vault referencesやmanaged identityで扱える箇所
6. 通知失敗時の記録と再通知先
7. 面談予約へ進む条件

制約:
- 法律、税務、労務、許認可の判断は人が行う
- 相談本文、氏名、電話番号、相手方名をログへ丸ごと残さない
- 最後に、初心者が今日見るべき設定を5つに絞る

動く確認コード

次のコードは、Azure Functionsの相談フォーム通知で見落としがちな項目を検査する小さなレビュー用コードです。わざと危ない設定を入れているため、実行すると止めるべき項目が表で出ます。

// verify-azure-function-consultation-form.mjs
// No dependencies. Run with: node verify-azure-function-consultation-form.mjs
const functionJson = {
  bindings: [
    {
      authLevel: "anonymous",
      type: "httpTrigger",
      direction: "in",
      name: "req",
      methods: ["post"]
    },
    {
      type: "http",
      direction: "out",
      name: "res"
    }
  ]
};

const source = [
  "module.exports = async function (context, req) {",
  "  console.log(req.body);",
  "  const apiKey = 'SENDGRID_API_KEY_plain_text';",
  "  await sendMail(req.body.email, req.body.message, apiKey);",
  "  context.res = { status: 200, body: 'ok' };",
  "};"
].join("\n");

const formPolicy = {
  fields: ["name", "email", "caseType", "message"],
  required: ["name", "email", "caseType", "message", "privacyConsent"],
  hasIdempotencyKey: false,
  hasRetryQueue: false,
  hasReservationLink: false
};

const problems = [];
const trigger = functionJson.bindings.find((binding) => binding.type === "httpTrigger");

if (!trigger || trigger.authLevel === "anonymous") {
  problems.push({ item: "authLevel", fix: "avoid anonymous public posting unless another protection layer exists" });
}
if (/console\.log\(req\.body\)/.test(source)) {
  problems.push({ item: "raw body log", fix: "log request id and case type, not the consultation details" });
}
if (/SENDGRID_API_KEY|API_KEY_plain_text/.test(source)) {
  problems.push({ item: "plain secret", fix: "use Key Vault references or approved app settings" });
}
if (!formPolicy.required.includes("privacyConsent")) {
  problems.push({ item: "privacy consent", fix: "require consent before sending the consultation form" });
}
if (!formPolicy.hasIdempotencyKey) {
  problems.push({ item: "duplicate submit", fix: "store an idempotency key from email, timestamp bucket, and message hash" });
}
if (!formPolicy.hasRetryQueue) {
  problems.push({ item: "mail failure", fix: "record failed notices and retry or alert a staff member" });
}
if (!formPolicy.hasReservationLink) {
  problems.push({ item: "booking path", fix: "include a reservation or callback path after the notice" });
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Azure Functions consultation form checklist passed.");
}

このコードで見ているのは、anonymous公開、raw body log、平文secret、同意項目、重複送信、通知失敗、予約導線です。本番では、Azure Portal、Bicep、Terraform、CI、Application Insightsの設定も合わせて見ます。まずはこの7項目をレビュー表に移してください。

Pitfall: よくある落とし穴

士業事務所のAzure Functionsで一番多い落とし穴は、メールが届いたら完成扱いにする流れです。原因は、受付業務を「送信処理」だけで見てしまう点です。直し方は、送信後の記録、失敗時の確認、面談予約、担当者割当まで表に入れることです。

二つ目は、相談本文をログへ出すことです。調査には便利ですが、相続、労務、契約、補助金の相談には重い情報が入ります。ログにはrequest id、相談種別、送信時刻、処理結果だけを残し、本文は必要な保管先で扱います。

三つ目は、Function keyだけで安心してしまう流れです。Function keyは便利な入口制御ですが、フォーム公開、Bot対策、CORS、rate limit、App Service認証、監視を合わせて見ます。受付フォームの性質に応じて、過不足を決めます。

四つ目は、APIキーをコードや設定メモへ書くことです。Key Vault referencesやmanaged identityを検討し、最低でもリポジトリへsecretを入れない運用にします。

よくある質問

Q. 小さな事務所でもAzure Functionsは使えますか。

A. 使えます。ただし、問い合わせが少ないならまずフォームサービスや既存CMSで足りる場合もあります。Azure Functionsは、通知、分類、予約URL出し分け、失敗記録を自分たちのルールで持ちたい時に合います。

Q. Function keyがあれば認証は十分ですか。

A. 受付フォームの公開範囲によります。外部公開フォームなら、Function keyだけではなく、フォーム側のBot対策、CORS、rate limit、App Service認証や別の入口制御も検討します。

Q. 相談本文をメールに入れてよいですか。

A. 事務所の運用次第です。メール転送や共有範囲が広いなら、本文を短くし、管理画面や安全な保管先へのリンクに寄せます。少なくともraw logへ丸ごとは避けます。

Q. まず何を見ればよいですか。

A. 今日まず、function.jsonのauthLevel、ログ、APIキー、privacyConsent、通知失敗時の扱いを確認してください。この5つだけでも事故の入口がかなり見えます。

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

士業事務所のAzure Functions記事から相談へ進めるなら、PVだけでは判断しません。相談フォーム送信件数、通知見落とし件数、初回返信までの分、面談予約率、スパム件数、受付停止中業務への送信件数を見ます。ここが改善すれば、フォーム通知や予約導線の相談に進む理由があります。

相談フォーム、Azure Functions、Key Vault、ログ方針、面談予約導線までまとめて整えたい場合は、ClaudeCodeLabの研修・相談で相談できます。まずはこの記事の確認コードを走らせ、自分のフォームで止めたい条件を5つ書き出してください。

実際に試した結果

この記事では、Microsoft LearnのAzure Functions HTTP trigger、triggers and bindings、Key Vault references、App Service認証、Azure Functions securityの説明を確認しました。さらに、slug、frontmatter、内部リンク、外部リンク、CTA、コードブロック、10言語ファイルの有無、記事キューの削除対象を確認しています。今日まず見る1手は、相談フォーム通知のauthLevel、ログ、APIキー、privacyConsent、通知失敗時の扱いをチェックする作業です。