社労士事務所のClaude Code活用｜就業規則・助成金書類の点検【2026】

事例出典：実装パターン解説（想定モデルケース）
本記事は、助成金活用研修の現場で提携先の社労士の先生方と書類をやり取りしてきた経験をもとに、社労士事務所の業務フローへClaude Codeを組み込む実装パターンを「顧問先30社規模の事務所」という想定モデルで解説するものです。本文中の工数・削減率はすべて試算値であり、特定の実在事務所の実測値ではありません。

「就業規則の改正対応、結局ぜんぶ目視で読み直してるんですよね…」

助成金を活用した企業研修の案件では、提携している社労士の先生方と申請書類をやり取りする機会が多いのですが、打ち合わせのたびに驚くのがこの「目視点検」の量です。就業規則の改正反映、36協定届の記載チェック、助成金申請書類の数値突合。どれも「定型文書を、決まったルールに照らして、差分を確認する」作業で、構造としてはソフトウェア開発のコードレビューとほぼ同じなんです。

コードレビューの世界では、版管理（git）と差分表示（diff）と自動チェック（CI）で「全文読み直し」をとっくに卒業しています。それなら、同じ道具立てを規程と申請書類に持ち込めばいい。本記事では、Claude Codeを使って社労士業務の文書点検を自動化する実装パターンを、ディレクトリ設計・プロンプト・スクリプトのレベルまで具体的に解説します。

なぜ社労士業務はClaude Codeと相性が良いのか

社会保険労務士の登録者数は46,506人（令和7年8月31日現在、厚生労働省「第57回社会保険労務士試験の合格者発表」資料より）。多くの事務所が数名から十数名の体制で、数十社の顧問先の規程・届出・助成金を抱えています。つまり「少人数で大量の定型文書を回す」構造です。

エンジニア視点で社労士業務を観察すると、自動化に向く特徴が3つあります。

1. 文書がテキスト中心 — 就業規則・36協定届・助成金様式は、図面や画像ではなくテキストと表で構成される。LLMが最も得意とする入力形式
2. 判定ルールが明文化されている — 労働基準法第89条の必要記載事項、第36条の上限規制、助成金の支給要領など、チェック基準が公開文書として存在する
3. 「差分」が業務の中心 — 法改正への追従、顧問先ごとのカスタマイズ、申請書類の修正往復。どれも「前の版と何が変わったか」の管理が肝になる

この3条件は、会計事務所・税理士法人でのClaude Code活用で解説した税務書類とも共通する、士業文書全般の特徴です。違いは、社労士の場合「規程の版管理」という、gitの設計思想がそのままはまる業務が中核にあることです。

一方で、就業規則や助成金は従業員の権利・金銭に直結する領域です。AIは下書きと点検の補助ツールであり、最終判断者ではありません。この前提は記事全体を通じて変わりませんので、最初に明記しておきます。

想定モデル：顧問先30社規模の事務所の点検フロー（導入前）

本記事の想定モデルは次のような事務所です（試算の前提条件として明示します）。

項目	想定値
体制	社労士3名+事務スタッフ2名
顧問先	30社（常時10人以上の事業場が中心）
就業規則の改正対応	月4〜6規程（法改正期は集中）
36協定届	年間延べ40件前後（更新時期に集中）
助成金申請	人材開発支援助成金を中心に月2〜3案件

常時10人以上の労働者を使用する事業場には就業規則の作成・届出義務があるため（労働基準法第89条）、顧問先が30社あれば、本則+賃金規程+育児介護休業規程…と、管理対象の規程は容易に100ファイルを超えます。

導入前のボトルネックは典型的にはこうなります。

• 就業規則の改正反映チェック：旧版と新版をWordの2画面で並べて目視比較。1規程あたり約3時間
• 36協定届の記載チェック：上限規制・対象期間・過半数代表者の選出方法などを紙のチェックリストで確認。1件約15分でも、件数が重なると丸1日が消える
• 助成金申請書類：訓練計画届・支給申請書・賃金台帳の間で数値（訓練時間・対象者数・賃金額）がズレていないかの突合に1案件約2時間

合計すると、点検系の作業だけで月およそ42時間。これはあくまで想定モデルの試算ですが、士業の現場感覚として大きく外れてはいないはずです。そしてこの42時間は「新しい価値を生む時間」ではなく「ミスを防ぐための時間」です。ここをClaude Codeに肩代わりさせます。

実装スタックとリポジトリ設計

まず動作環境です。検証時の構成を明記しておきます。

レイヤー	採用技術	備考
AIエージェント	Claude Code（CLI、モデルはClaude Sonnet 4.6）	ターミナルから対話+ヘッドレス実行
版管理	git（プライベートリポジトリ）	規程・チェックリストの正本管理
文書形式	Markdown（規程）/ YAML（チェックリスト）	Word正本からの変換はpandocを利用
様式処理	Python 3.12 + 標準ライブラリ	e-Gov帳票CSVの正規化
OS	macOS / Windows（WSL2）どちらも可	事務所PCはWSL2構成を想定

リポジトリは「規程の正本」「チェックリスト」「スクリプト」「出力」を分離します。

sr-office/
├── CLAUDE.md                  # Claude Codeへの常時指示
├── kitei/                     # 規程の正本（顧問先別）
│   ├── client-a/
│   │   ├── shugyo-kisoku.md   # 就業規則 本則
│   │   ├── chingin-kitei.md   # 賃金規程
│   │   └── ikuji-kaigo.md     # 育児介護休業規程
│   └── client-b/
├── checklists/
│   ├── kisai-jiko-89jo.yml    # 労基法89条 必要記載事項
│   ├── 36kyotei.yml           # 36協定 上限規制チェック
│   └── jinkai-seigosei.yml    # 助成金書類の数値突合ルール
├── scripts/
│   ├── normalize_egov_csv.py  # e-Gov帳票CSVの正規化
│   └── make_diff_report.sh    # 差分レポート生成
└── output/                    # 点検レポート出力先（git管理外）

要のひとつが CLAUDE.md です。Claude Codeはセッション開始時にこのファイルを読み込むため、事務所固有のルールをここに集約します。

# CLAUDE.md — 社労士事務所 規程管理リポジトリ

## このリポジトリの役割
- kitei/ 配下は顧問先の規程の正本。直接の書き換えは提案モードでのみ行う
- 点検結果は output/ にMarkdownで出力する。規程ファイル自体は変更しない

## 点検時の必須ルール
- 法令・通達の条文番号を挙げるときは、根拠（参照ファイルまたは公式URL）を必ず添える
- 判断に迷う論点は「要・社労士確認」のラベルを付けて列挙する。勝手に結論を出さない
- 氏名・住所・マイナンバーなどの個人情報を発見したら、処理を中断して報告する

## 文体・形式
- 点検レポートは「指摘事項 / 根拠 / 推奨対応 / 重要度」の4列の表で出力する

「勝手に結論を出さない」「個人情報を見つけたら中断する」という防御的な指示をエージェントの常時コンテキストに置いておくのが、士業でAIを使うときの土台になります。

実装1：就業規則をgitで版管理し、diffで点検する

最初にやるのは、Word正本のMarkdown化とgit管理です。これだけで点検の景色が変わります。

# Word正本をMarkdownに変換（pandoc）
pandoc kitei_genko/client-a/就業規則.docx -t gfm -o kitei/client-a/shugyo-kisoku.md

# 初期コミット = 「現行版」のスナップショット
git add kitei/client-a/
git commit -m "client-a: 就業規則 現行版（2026-04-01施行）を登録"

改正案を作ったら、ブランチを切って編集し、diffをClaude Codeにレビューさせます。プロンプトはこうです。

kitei/client-a/shugyo-kisoku.md の main ブランチとの差分（git diff main）を確認し、
次の3点を点検してください。

1. 変更箇所が労働関係法令（特に労働基準法89条の必要記載事項）と矛盾しないか
2. 変更した条番号の「枝番ズレ」（第23条を削除したのに第24条以降の参照が残る等）がないか
3. 本則の変更に対して chingin-kitei.md / ikuji-kaigo.md 側の連動修正が漏れていないか

点検結果は output/client-a_diff_review.md に「指摘事項/根拠/推奨対応/重要度」の表で出力。
不足している情報があれば、最初に質問してから作業を開始してください。

実際にこの構成を検証していて感心したのは、2点目の「枝番ズレ」検出です。条文の削除・挿入で後続の条番号参照が崩れる事故は、目視だと本当に拾いにくい。diffという「変更箇所だけが見える」入力形式とLLMの組み合わせは、この種の参照整合チェックにきれいにはまります。

法改正対応も同じ枠組みに乗ります。たとえば改正内容の要点をMarkdownでリポジトリに置き、横断チェックさせます。

references/2026-kaisei-youten.md に今年度の法改正の要点をまとめてあります。
kitei/ 配下の全顧問先の育児介護休業規程（ikuji-kaigo.md）を走査し、
改正項目ごとに「反映済み / 未反映 / 該当条文なし」を判定して一覧表にしてください。

仮定した点は必ず「仮定」と明記してください。
判定に迷うものは「要・社労士確認」として分類してください。

30社分の横断チェックを1プロンプトで依頼できるのが、ファイルシステムを直接読めるClaude Codeの強みです。チャット型AIに規程を1本ずつ貼り付ける運用とは、ここで決定的な差がつきます。

実装2：36協定届を上限規制チェックリストと突合する

時間外労働の上限は原則「月45時間・年360時間」、特別条項付きでも「年720時間以内」「月100時間未満（休日労働含む）」「複数月平均80時間以内（休日労働含む）」という法定の枠があります（厚生労働省「時間外労働の上限規制 わかりやすい解説」）。この種の数値ルールは、自然文ではなくYAMLで構造化しておくとAIの照合精度が安定します。

# checklists/36kyotei.yml（抜粋）
limits:
  general:
    monthly_overtime_max: 45      # 月の時間外労働上限（時間）
    yearly_overtime_max: 360      # 年の時間外労働上限（時間）
  special_clause:
    yearly_overtime_max: 720      # 特別条項でも超えられない年上限
    monthly_total_lt: 100         # 時間外+休日労働 月100時間未満
    multi_month_avg_max: 80       # 2〜6ヶ月平均 80時間以内
required_fields:
  - 対象期間（1年に限る）
  - 過半数代表者の選出方法（民主的手続きであること）
  - 特別条項の発動要件（臨時的・具体的であること）

届出ドラフトのチェックは、ヘッドレスモード（claude -p）でスクリプトに組み込めます。

#!/bin/bash
# scripts/check_36.sh — 36協定ドラフトの一括点検
claude -p "checklists/36kyotei.yml の基準に従って drafts/36/ 配下の協定届ドラフトを全件点検し、
基準超過・記載漏れの候補を重要度つきの表にまとめてください。
数字と固有名詞は、根拠（参照ファイル名と該当行）を添えてください。" \
  --allowedTools "Read,Grep" \
  > output/36_check_$(date +%Y%m%d).md

--allowedTools "Read,Grep" で読み取り系ツールだけを許可しているのがポイントです。点検ジョブに書き込み権限は不要なので、権限を最小に絞っておけば「点検のつもりがドラフトを書き換えていた」という事故を構造的に防げます。

なお、36協定届や就業規則の届出はe-Govで電子申請でき、令和3年4月以降は電子署名・電子証明書も不要になっています（厚生労働省「労働基準法等の規定に基づく届出等の電子申請について」）。「Claude Codeで点検→e-Govで電子申請」と並べると、紙を一度も経由しない届出フローが組めます。

実装3：人材開発支援助成金の申請書類ドラフトとdiff点検

助成金業務はファイル数と転記箇所が多く、点検自動化の効果が最も出やすい領域です。人材開発支援助成金には人材育成支援コース、人への投資促進コース、事業展開等リスキリング支援コースなど7つのコースがあり（厚生労働省「人材開発支援助成金」、参照日2026-06-11）、たとえば事業展開等リスキリング支援コースの場合、中小企業では経費助成が実費相当額の75%、賃金助成が1人1時間あたり1,000円とされています（同省の令和8年5月14日版コース案内より。2026年6月時点の情報のため、申請時は必ず最新の支給要領を確認してください）。

ここで自動化するのは「ドラフト生成」と「書類間の数値突合」の2つです。まずドラフト生成。

plans/client-c/kunren-gaiyo.md に顧問先の訓練計画の概要（訓練名・対象者・期間・
実施形態・経費見積）をまとめてあります。

この内容をもとに、templates/jinkai/ 配下の様式テンプレートに沿って
訓練実施計画届のドラフトを output/client-c/ に生成してください。

- テンプレートにあるのに概要に情報がない欄は、推測で埋めずに【要確認】と記入する
- 不足している情報があれば、最初に質問してから作業を開始してください

「推測で埋めずに【要確認】と記入する」という一文が実務では効きます。LLMは空欄をもっともらしく埋めようとする性質があるので、「埋めない」ことを明示的に指示しないと、気づかないうちに根拠のない数字が様式に紛れ込みます。これは検証中に実際に踏んだ落とし穴で、初回のドラフトでは訓練時間の欄に概要メモのどこにもない「20時間」が入っていました。以後、全テンプレートのプロンプトにこの一文を入れています。

次に、提出前の数値突合です。

次の3ファイルの間で、数値の整合性を点検してください。
- output/client-c/keikaku-todoke.md（訓練実施計画届ドラフト）
- plans/client-c/kunren-gaiyo.md（計画概要）
- data/client-c/chingin-summary.csv（賃金集計。個人名は仮名化済み）

突合する項目: 訓練時間の合計 / 対象労働者数 / 1人あたり賃金助成の算定基礎
ルールは checklists/jinkai-seigosei.yml に従うこと。
不一致を見つけたら「どのファイルの値が正か」を断定せず、両方の値と出現箇所を併記してください。

「どちらが正か断定しない」のも意図的な設計です。突合ツールの仕事は不一致の検出までで、どちらを採用するかは支給要領と事実関係を知る社労士の判断領域です。助成金は支給・不支給の判断が労働局に属する制度なので、AIの出力を「申請が通る保証」と読み替えない運用ルールを、プロンプトのレベルから織り込んでおきます。

なお、助成金申請の書類点検という切り口ではNPOの助成金申請業務をClaude Codeで効率化した想定モデルも公開しています。民間助成金と厚労省系助成金で様式は違いますが、「計画と申請書の突合」という構造は同じです。

e-Gov様式のテキスト処理で詰まったポイント

実装でいちばん地味に苦労するのが、e-Gov関連の帳票データ処理です。検証中に踏んだ問題と対処をそのまま共有します。

問題1：文字コードがUTF-8ではない。行政系の帳票CSVはShift_JIS（正確にはcp932）であることが多く、そのままClaude Codeに読ませると文字化けします。前処理スクリプトで正規化してからリポジトリに入れます。

# scripts/normalize_egov_csv.py
import pathlib
import re
import sys

def normalize(path: str) -> str:
    raw = pathlib.Path(path).read_bytes()
    text = raw.decode("cp932")              # Shift_JIS系をUTF-8へ
    text = re.sub(r"\r\n?", "\n", text)     # 改行コードをLFに統一
    text = re.sub(r"[ \t]+(?=\n)", "", text)  # 行末の空白を除去
    text = re.sub(r"　", " ", text)     # 全角スペースを半角に
    return text

if __name__ == "__main__":
    sys.stdout.write(normalize(sys.argv[1]))

問題2：1セルに複数の意味が詰まっている。「氏名（フリガナ）」「期間（自）〜（至）」のような複合セルは、突合の前に正規表現で分解しておくとAIの取り違えが減ります。たとえば期間セルは re.match(r"(\d{4})年(\d{1,2})月(\d{1,2})日", cell) のように年月日を明示的に切り出してから渡します。

問題3：様式の改版。e-Govの様式は年度途中でも更新されることがあります。テンプレート側にも version: 2026-04 のようなメタデータを持たせ、点検プロンプトに「テンプレートの版が古い可能性も指摘対象に含める」と書いておくと、様式改版の検出網になります。

段階的導入のロードマップ（3 Phase）

Phase 1（1〜2ヶ月）：読み取り専用で信頼を作る。顧問先2〜3社の規程をMarkdown化してgit管理を開始。Claude Codeには点検レポートの出力だけを許可し、人間の点検結果と突き合わせて精度を観測します。ここで「AIが何を拾えて何を拾えないか」の感覚を事務所内に作るのが目的です。

Phase 2（3〜4ヶ月）：チェックリストの整備と横展開。36協定・助成金のYAMLチェックリストを実案件に合わせて育てながら、対象顧問先を広げます。ヘッドレス実行（claude -p）をシェルスクリプト化し、「届出前に必ず点検ジョブを通す」運用をルール化します。

Phase 3（5〜8ヶ月）：ドラフト生成まで拡張。点検で信頼が積み上がってから、助成金様式や規程改正案のドラフト生成に範囲を広げます。生成物は必ずブランチに置き、社労士のレビューとマージを経て正本化する——つまりコードレビューと同じガバナンスを文書に適用します。

想定効果（試算値）

冒頭の想定モデル（顧問先30社・社労士3名）に対する試算です。実測値ではなく、業務フローの構造から積み上げた目安値として読んでください。

指標	導入前（想定）	導入後（試算）	削減率（試算）
就業規則の改正反映チェック（1規程）	約3時間	約40分	約78%減
36協定届の記載チェック（1件）	約15分	約3分	約80%減
助成金書類の数値突合（1案件）	約2時間	約30分	約75%減
点検系業務の月間合計	約42時間	約9時間	約78%減

補足を2つ。第一に、削減されるのは「点検の1次スクリーニング」であって、社労士による最終確認は残ります（残すべきです）。第二に、導入初期はMarkdown化・チェックリスト整備の先行投資が発生するため、効果が出るのはPhase 2以降です。即効性を期待して入れると「手間が増えただけ」で止まります。

【要注意】よくある失敗パターンと回避策

失敗1：Wordのまま点検させようとする

❌ 顧問先から届いたWordファイルをそのままAIに渡して点検させる
⭕ pandocでMarkdown化し、gitにコミットしてから「差分」を点検させる

なぜ重要か：版管理されていない文書には「何が変わったか」という情報が存在しません。LLMの精度以前に、入力設計の問題です。diffという最小の入力に絞るほど、点検の見落としは減ります。

失敗2：チェック基準を自然文のままにする

❌ 「36協定の上限規制に違反していないか見て」とだけ指示する
⭕ 上限値・必須記載事項をYAMLに構造化し、「このファイルの基準に従って」と指示する

なぜ重要か：基準が会話の中にしかないと、点検のたびに判定がブレます。基準をファイルにすればgitで版管理でき、「いつの基準で点検したか」まで記録に残ります。

失敗3：空欄をAIに埋めさせてしまう

❌ 様式ドラフト生成で、情報が足りない欄もそれらしく埋めさせる
⭕ 「推測で埋めずに【要確認】と記入する」「不足があれば最初に質問する」を全プロンプトに入れる

なぜ重要か：助成金書類の「もっともらしい架空の数字」は、点検で最も発見しにくい欠陥です。生成段階で空欄を明示させる方が、後段の突合よりはるかに安上がりです。

失敗4：個人情報をリポジトリに入れる

❌ 賃金台帳や労働者名簿を実名のままリポジトリに置いて処理する
⭕ 仮名化・集計済みデータだけを置き、CLAUDE.mdに「個人情報を発見したら中断して報告」と書く

なぜ重要か：マイナンバーや健康情報を含むデータの取り扱いは、AI以前に事務所のコンプライアンスの問題です。詳しくは次のセクションで扱います。

セキュリティと個人情報——社労士業務での必須ガード

社労士事務所が扱うデータには、マイナンバー・賃金・健康診断結果といった機微情報が含まれます。この領域でAIを使う場合の運用ガードを、検証で採用した構成のまま列挙します。

• リポジトリに入れてよいデータを白黒で定義する — 規程・様式テンプレート・チェックリストは可。労働者名簿・賃金台帳の生データ・マイナンバーは不可。突合に必要な賃金データは仮名化+集計済みのCSVに変換してから置く
• 点検ジョブの権限を読み取り専用に絞る — --allowedTools "Read,Grep" のようにツール許可を最小化する
• 出力にも検査をかける — output/ への書き出し後、grep -E "[0-9]{12}" などでマイナンバー様のパターンが混入していないか機械チェックする
• 組織のルールを優先する — 生成AIの利用可否・データの外部送信ポリシーは事務所および顧問先の規程・契約に従う。判断に迷う場合は弁護士等の専門家に相談する

また、繰り返しになりますが、就業規則の有効性判断や助成金の支給可否は、最終的に労働基準監督署・労働局の審査と社労士の専門判断に属します。本記事の構成は「人間の判断材料を速く・漏れなく揃える」ためのものであり、判断そのものの代替ではありません。

よくある質問（FAQ）

Q1. 社労士業務でClaude Codeを使っても安全ですか？

データの置き方次第です。マイナンバーや実名の賃金データはリポジトリに入れず、仮名化・集計済みデータだけを扱う設計にすれば、リスクを大きく下げられます。利用可否は事務所・顧問先のセキュリティポリシーに従い、機微情報の扱いは必要に応じて弁護士等の専門家に確認してください。

Q2. プログラミング経験がない社労士でも導入できますか？

Phase 1（規程のMarkdown化とgit管理、対話での点検依頼）は、ターミナルの基本操作ができれば始められます。一方、e-Gov帳票の前処理やヘッドレス実行の自動化（Phase 2以降）はスクリプト作成が必要になるため、エンジニアの伴走があるとスムーズです。

Q3. e-Govと直接連携できますか？

本記事の構成では、Claude Codeの担当は「提出前の点検まで」とし、提出はe-Govの電子申請で行う分担にしています。36協定届や就業規則届出はe-Govで電子申請が可能で、令和3年4月以降は電子署名・電子証明書が不要になっています（厚生労働省の案内ページ参照）。

Q4. 助成金の支給判断までAIに任せられますか？

できません。支給・不支給の判断は労働局の審査に属し、要件解釈は支給要領の最新版に基づく社労士の専門判断が必要です。本記事で自動化しているのは、書類間の数値突合と記載漏れ検出という「判断の手前」の工程です。

Q5. 規程をgit管理するメリットは点検以外にもありますか？

あります。「いつ・誰が・なぜ変えたか」がコミット履歴として残るため、顧問先からの「この条文いつ変えましたっけ？」に履歴付きで即答できます。労務監査やデューデリジェンスの場面でも、規程の変更履歴を時系列で提示できるのは強い武器になります。

まとめ：今日から始める3つのアクション

1. 今日やること：顧問先1社の就業規則をpandocでMarkdown化し、gitリポジトリに初期コミットする
2. 今週中：労基法89条の必要記載事項をYAMLチェックリスト化し、Claude Codeに1規程の点検レポートを出させて、自分の目視結果と比較する
3. 今月中：CLAUDE.mdに事務所の点検ルール（個人情報の扱い・要確認ラベル・出力形式）を書き、36協定または助成金書類のどちらか1業務で「提出前に点検ジョブを通す」運用を試す

次回予告：行政書士業務（許認可申請の添付書類管理）へのClaude Code適用パターンを、本記事と同じリポジトリ設計の延長で解説する予定です。

あわせて読みたい：

• 【2026年最新】会計事務所・税理士法人でのClaude Code活用ガイド — 同じ士業でも「数値検算」が中心になる税務系の実装パターン
• 【2026年最新】司法書士・法律事務所のClaude Code活用 — 登記・契約書という「条文参照」中心の業務での使い方
• NPOの助成金申請業務をClaude Codeで効率化｜想定モデル — 民間助成金版の書類突合パターン

参考・出典

• 厚生労働省「人材開発支援助成金」 — コース構成・支給要領（参照日: 2026-06-11）
• 厚生労働省「時間外労働の上限規制 わかりやすい解説」 — 月45時間・年360時間等の上限規制（参照日: 2026-06-11）
• 厚生労働省「労働基準法等の規定に基づく届出等の電子申請について」 — 36協定・就業規則届出の電子申請（参照日: 2026-06-11）
• 厚生労働省「第57回社会保険労務士試験の合格者発表」 — 社労士登録者数46,506人（令和7年8月31日現在）（参照日: 2026-06-11）
• Anthropic「Claude Code」公式ドキュメント — CLAUDE.md・ヘッドレスモード・ツール許可設定（参照日: 2026-06-11）

---

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（@SuguruKun_ai）で活用法を発信（フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。助成金を活用したAI研修の設計支援も多数。著書『AIエージェント仕事術』（SBクリエイティブ）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

関連記事（自動）

• ▸ 【2026年最新】葬儀社のClaude Code活用｜会葬礼状・式次第を自動化
• ▸ 【2026年版】行政書士事務所のClaude Code活用｜許認可申請を効率化
• ▸ 【2026年版】保険代理店のClaude Code実践｜日報・設計書・乗合管理
• ▸ 非エンジニアのClaude Code活用7選【2026年最新】｜業務担当者入門
• ▸ 【2026年最新】会計事務所・税理士法人でのClaude Code活用ガイド