NPOの助成金申請業務をClaude Codeで効率化｜想定モデル

はじめまして。株式会社Uravation 代表の佐藤 傑です。普段は法人向けにClaude Codeの導入支援・個別指導をやっているのですが、副次的に「NPOの事務局スタッフから助成金申請の相談をされる」機会が増えてきました。理由はわりとシンプルで、「公募が同時期に集中する」「申請書フォーマットが財団ごとに違う」「過去申請書が紙orPDFで散在している」「事務局スタッフが1〜3名で兼務」という構造があって、そこに生成AIをハマる余地が大きいからです。

本記事では、私が実際に2つの中小規模NPO(年商3,000万〜1.5億円規模、事務局2名)の事務局スタッフと話しながら整理した「もしClaude Codeを助成金申請業務に常駐させたら、どこから入れるのが現実的か」の想定モデルケースを、実装手順とあわせて公開します。採択率の数字や、実在の財団の採択実績は本記事では扱いません(特定団体の機密に踏み込まないため、また採択率は審査員構成・年度方針で揺れるため)。あくまで「事務作業の段取りを変える」話としてお読みください。

そもそもNPOの助成金申請業務は、なぜ大変なのか

本題に入る前に、NPO事務局の助成金申請業務がなぜここまで属人化・非効率化しやすいのか、構造を簡単に整理しておきます。これを共有してから実装手順を読むと、「なぜClaude Codeをここに差し込むのか」が腑に落ちやすいはずです。

第一の理由は「申請ピークが年に複数回ある」こと。公益財団系は春(4〜5月)、秋(9〜10月)、企業財団系は通年でずれて出てきます。行政の補助金(地方自治体の市民活動支援、内閣府の休眠預金活用事業、こども家庭庁の各種公募、独立行政法人福祉医療機構WAM助成など)はそれぞれ独自の公募スケジュールがあり、結果として「事務局スタッフ2名で年間10〜20件、多い団体だと30件近く申請する」のが普通の状態になります。

第二の理由は「申請書フォーマットが財団ごとに違う」こと。同じ事業内容でも、A財団は「事業の社会的意義(800字)」を求め、B財団は「対象者数とKPI(数値必須)」を求め、C財団は「他団体との連携体制(自由記述2,000字)」を求めます。同じ事業を毎回違う角度から書き直す必要があり、しかもフォーマット指定(Word添付、Excelテンプレ、Web入力フォーム)もバラバラです。

第三の理由は「過去申請書がアーカイブされていない」こと。事務局スタッフが入れ替わるたびに、前任者のGoogleドライブのどこに過去申請書があるのか分からなくなり、結果として毎年ゼロベースで書き直すことになります。「採択された申請書」と「不採択だった申請書」が同じフォルダに並んでいて、どれを参考にすればいいか分からないという団体も少なくありません。

第四の理由は「年次報告書と申請書のサイクルが分断されている」こと。本来、年次報告書(=助成金の使い道報告)に書いた「実績」や「定性的成果」は、次年度の申請書に流用できる最高の素材です。ところが、報告書作成と申請書作成は別のスタッフが担当することが多く、両者の情報がつながらない。結果として、申請書には「やりたいこと」しか書けず、「過去にやってきたこと」の裏付けが弱くなりがちです。

この4つの構造課題は、いずれも「同じ素材を、違うフォーマットに、何度も並び替える」という、まさに生成AIが得意な領域です。Claude Codeに「事業の核」と「過去申請書のアーカイブ」を渡しておけば、新規申請のたびに毎回ゼロから書く必要がなくなる、というのが本記事の基本発想です。逆に言えば、ここで省力化できた時間を「現場の受益者に向き合う時間」「代表が外部にメッセージを発信する時間」「他団体との連携を設計する時間」に振り戻せる、というのがNPO事務局にとっての本質的な価値になります。事務作業を減らすこと自体が目的ではなく、減らした時間で何をするかが組織のミッションに直結します。

想定モデルケース:中規模NPOの事務局2名体制で導入

具体的なイメージをそろえるため、本記事では以下の想定モデルケースを念頭に置きます(架空の団体です。実在団体ではありません)。

• 団体規模:認定NPO法人、年商約8,000万円、事務局スタッフ2名+理事長兼事業統括1名
• 事業領域:子どもの居場所づくり(学習支援+食事提供)を都内3拠点で運営
• 収入構造:寄付40%、助成金30%、行政委託20%、自主事業10%
• 年間助成金申請数:約15件(春ピーク7件、秋ピーク5件、通年企業財団3件)
• 現状の課題:春ピーク時に事務局2名が申請書作成で2週間ほぼ手が止まり、本業の現場運営に支障が出ている

このモデル団体に対して、Claude Codeを「下ごしらえ係」として常駐させる前提で組み立てます。重要なのは、Claude Codeに最終提出物を書かせるのではなく、「初稿の構造をつくる」「過去申請書から該当箇所を引っ張ってくる」「複数財団の要件マッチングを機械的にやる」までを任せ、最後の意味調整・固有名詞・受益者の人物像描写・代表のメッセージは人間が必ず書き直すという役割分担にすることです。

NPOの申請書で審査員に響くのは「数字」よりも「現場でのリアルなエピソード」「受益者の変化」「団体メンバーの想い」であることが多く、これは生成AIが最も苦手とする領域でもあります。だからこそ、AIに任せる範囲と人間が必ず書く範囲を最初に切り分けることが、品質を担保する一番の条件になります。

リポジトリ構成:「事業の核」と「過去申請書アーカイブ」を分離する

Claude Codeを助成金業務に使うとき、最初にやるべきはリポジトリ(=Claudeに読ませるファイル群の置き場所)の設計です。ここを雑にすると、毎回プロンプトに大量の前提を貼り付けることになり、運用が続きません。

推奨する構成は以下のようなディレクトリ構成です。Gitで管理する必要はありません(NPO事務局でGitを回すのは現実的でない)。Googleドライブの共有フォルダか、Macのローカルフォルダで十分です。Claude Code起動時のカレントディレクトリをここに置くだけで動きます。

npo_grants/
├── core/
│   ├── 01_mission.md           # ミッション・ビジョン・事業の核(800字)
│   ├── 02_history.md           # 設立経緯・主要マイルストーン
│   ├── 03_finance.md           # 直近3期の収支概況(数字)
│   ├── 04_kpi_definitions.md   # 自団体で使うKPI定義集
│   └── 05_voice_samples.md     # 代表・受益者のコメントサンプル
├── past_applications/
│   ├── 2024_aaa_zaidan_accepted/
│   │   ├── application.pdf
│   │   └── summary.md          # 要旨(800字)・採否・コメント
│   ├── 2024_bbb_zaidan_rejected/
│   │   └── ...
│   └── 2025_ccc_kasen_accepted/
├── annual_reports/
│   ├── 2023_annual_report.pdf
│   └── 2024_annual_report.pdf
├── foundations/
│   └── matrix.csv              # 財団要件マトリクス
├── current_application/
│   ├── brief.md                # 今回の公募要項のメモ
│   └── draft.md                # Claudeに作らせる初稿の置き場
└── CLAUDE.md                   # Claude Code向けの常駐指示書

ポイントは3つあります。第一に、「事業の核(core/)」と「過去申請書(past_applications/)」と「直近の申請ドラフト(current_application/)」を物理的に分けること。これによって「今回の申請書だけ書いて」と指示したときに、Claudeが過去申請書を勝手にコピペしてくる事故を減らせます。第二に、「過去申請書には採否を記録する」こと。フォルダ名に _accepted/_rejected を入れておくと、Claudeに「採択された申請書の構造だけ参考にして」と指示しやすくなります。第三に、CLAUDE.md(Claude Code向けの常駐指示書)を置くこと。ここに「本リポジトリでは助成金申請業務を扱う」「過去申請書をそのまま流用してはいけない」「数字は必ず core/03_finance.md から引く」といったルールを書いておけば、毎回プロンプトで前提を伝え直す必要がなくなります。

CLAUDE.md の中身の例も示しておきます。これをそのまま npo_grants/CLAUDE.md として置いてください。

# NPO助成金申請業務 — Claude Code 作業ルール

## 基本姿勢
- 当NPOの助成金申請業務を支援する補助ツールとして動作する
- 最終的な申請内容の判断は事務局長・理事長が行う。Claudeは初稿作成と素材整理に専念する
- 「採択されます」「審査員に好まれます」等の断定はしない。採択は審査員判断であり不確実

## 必読ファイル(セッション開始時に読む)
- core/01_mission.md
- core/04_kpi_definitions.md
- foundations/matrix.csv

## 数値の扱い
- 収支・受益者数・拠点数等の数字は必ず core/03_finance.md または最新の annual_reports/ から引用する
- 不明な数字は推測せず「(要確認)」と書いて停止する

## 過去申請書の扱い
- past_applications/ 配下の文書はあくまで構造参考。本文の流用は禁止
- 「採択済み(_accepted)」フォルダのものは構造を参考にしてよいが、固有名詞・年度・受益者描写はそのままコピペ禁止

## 出力フォーマット
- 初稿は current_application/draft.md に追記形式で書く
- 既存のdraft.mdを上書きせず、セクションごとに差分を提示する

この常駐指示書を1度書いておくと、新しい申請が立ち上がるたびに current_application/brief.md に公募要項のメモを置くだけで作業が始められます。事務局スタッフがClaude Codeに毎回「うちの団体は子どもの居場所づくりをやっていて…」と説明する必要がなくなり、これだけで月数時間の節約になります。

実装手順1:公募情報の継続チェックと要件マトリクス管理

最初の差し込みポイントは、「複数財団の公募情報を横並びで管理する」仕組みです。多くのNPOでは、事務局長がPC・スマホで個別に各財団のサイトを巡回し、Excelに公募一覧をまとめていますが、これが手作業のままだと「気づいたら締切3日前」になりがちです。

Claude Codeに任せる前提として、まず foundations/matrix.csv に「自団体として申請する可能性のある財団」のマスタを作っておきます。列構成の例は以下です。

foundation_id,foundation_name,category,annual_call_month,max_grant_yen,target_field,application_format,past_result,priority
F001,◯◯公益財団,公益,4-5,3000000,子ども支援,Word添付,2024採択,A
F002,△△企業財団,企業,通年,1500000,教育全般,Webフォーム,2024不採択,B
F003,××休眠預金,行政,9-10,10000000,社会的養護,Excelテンプレ+事業計画,2025初挑戦,A
...

このマスタができたら、Claude Codeに「新しい公募情報のスクリーンショットやPDFを渡したら、matrix.csvと突き合わせて、自団体が申請すべきかどうかをスコアリングしてほしい」と頼みます。プロンプト例は以下。

# プロンプト例1:新規公募の要件マッチング

公募要項を以下に貼り付けます。

【公募要項(コピペ)】
財団名:□□財団
公募テーマ:子ども・若者の自立支援
助成上限:200万円
申請締切:2026-07-15
求める書類:事業計画書(A4 5枚以内)、収支計画、団体パンフレット
重視するポイント:継続性・他団体連携・成果指標の明確さ

【お願い】
1. foundations/matrix.csv に既に登録されている財団か確認してください。
   - 登録済みなら past_result を踏まえて、再申請の妥当性をコメント
   - 未登録なら追加すべきかを判断し、追加するなら1行のCSV行を提案
2. core/01_mission.md と照合し、自団体の事業が公募テーマに合致するかを
   「合致度:◯/△/×」「不一致の論点」「補強すべき要素」の3点で出力
3. 過去類似テーマで採択された申請書(past_applications/_accepted)が
   あれば、ファイル名を列挙
4. 当月のスケジュールに対して妥当な案件かを、現状の申請ドラフト本数
   (current_application/配下のドラフト数)も加味してコメント

最終提出物を書く必要はありません。事務局長の判断材料を整理してください。

このプロンプトの肝は、「Claudeに採否や合否を判定させない」という線引きです。「合致度」「不一致の論点」「補強すべき要素」という3点だけ出させて、最終的な「申請するかしないか」の意思決定は人間が行います。これによって、Claudeが「うちの事業はぴったりです、ぜひ申請しましょう」のような無責任な楽観バイアスを返してくる事故を減らせます。

運用としては、事務局スタッフが各財団のメルマガ・サイトをチェックして公募要項を発見した段階で、上記プロンプトをClaudeに投げ、出力を foundations/ 配下に 20260601_zzz_zaidan_check.md のような形で保存します。週次の事務局ミーティングでこのファイル群を眺めて「今期どれに出すか」を決める、という運用フローが現実的です。

実装手順2:事業計画書のドラフト展開と過去申請書の要旨流用

次の差し込みポイントは、申請業務の本丸である事業計画書のドラフト作成です。ここでもポイントは「Claudeに完成形を書かせない」こと。Claudeには「過去申請書の要旨と core/ の素材を、今回の財団フォーマットに並べ替える」までを任せ、本文の意味調整は人間がやります。

前提として、 past_applications/2024_aaa_zaidan_accepted/summary.md のような「過去申請書の要旨ファイル」を整備しておく必要があります。要旨は800字程度、以下のフォーマットを推奨します。

# 2024年 ◯◯公益財団 助成金申請 要旨

## 公募概要
- 助成額:300万円
- テーマ:子どもの貧困対策
- 採否:採択(満額)
- 審査員コメント:「現場の数字の裏付けが具体的」「他団体連携の体制が現実的」

## 申請事業の概要(400字程度)
当団体の3拠点で実施している学習支援+食事提供の事業のうち、
新規開設予定の墨田拠点における年間運営費を申請した。
週3回の学習支援(対象児童50名)+月8回の食事会(延べ400食)を
基本パッケージとし、地域の他団体3団体との連携を体制図で示した。

## 採択された理由(自己分析・400字)
- 数字が具体的(対象児童数、食事提供回数、連携先団体数)
- 既存2拠点での実績データを根拠として提示
- 連携先団体の代表者からの推薦文を添付
- 収支計画で他収入源(寄付・自主事業)の比率を明示し、
  助成金依存度の低さをアピールできた

## 流用可能なパーツ
- 既存拠点の運営実績データ表(annual_reports/2023参照)
- 地域連携体制の図(scrapbox: link)
- 受益者の保護者コメント(個人情報マスク済み版)

この「要旨ファイル」を採択済み申請書ごとに作っておくと、Claudeが新規申請のドラフトをつくるときに「どの過去申請の構造を参考にすべきか」を判断できるようになります。プロンプト例は以下。

# プロンプト例2:新規申請の事業計画書ドラフト展開

今回申請する財団:□□財団(foundations/matrix.csv F004行参照)
申請事業:墨田拠点での子ども食堂運営(年間運営費200万円)
提出フォーマット:A4 5枚以内、事業計画書テンプレ(添付PDFを別途参照)

【お願い】
1. past_applications/_accepted/ 配下の summary.md をすべて読み、
   今回の申請事業に最も近い構造を持つ採択事例を1〜2件選定し、
   選定理由を3行で説明してください
2. 選定した過去申請の構造をベースに、今回の申請書の章立てを提案
   (各章の目安字数と、どのファイルから素材を引いてくるかを明示)
3. 章立てが固まったら、各章の初稿を current_application/draft.md
   に書いてください。ただし以下のルールに従うこと:
   - 数字は core/03_finance.md と annual_reports/ からのみ引用
   - 受益者の人物像・現場エピソードは「(事務局長記入)」とプレースホルダ
   - 代表のメッセージ部分は「(理事長記入)」とプレースホルダ
   - 過去申請書の本文をそのままコピペすることは禁止
4. 章ごとに「審査員が引っかかりそうなポイント」を【要注意】コメント
   として書き添えてください

最終提出は事務局長が判断します。あくまで初稿の構造案として作ってください。

このプロンプトで作られた初稿は、おそらく8割方は実用に耐える構造になります。残りの2割は「受益者の具体的なエピソード」「代表の想い」「現場ならではの困難と工夫」の3点で、これらは事務局スタッフと理事長が必ず人間として書き直します。逆に言うと、この3点に集中する時間を確保するためにClaudeに前段を任せる、という運用設計です。

1点、運用上の注意があります。Claudeに「過去採択された申請書の構造を参考にして」と頼むと、同じ財団に再申請する場合、3年経つと審査員の世代交代で価値観が変わることがあります。同じ財団の過去申請書を参考にする場合でも、「直近2年以内の採択事例」を優先し、それ以前の事例は構造の参考程度にとどめるのが安全です。これも上記プロンプトに追記しておくとよいでしょう。

実装手順3:複数財団の要件マトリクス突合と「同じ事業を3財団分書き分ける」

NPOの助成金申請でしんどいのは、「同じ事業を、3つの財団それぞれのフォーマットで、3通り書き分ける」場面です。事業内容は同じなのに、A財団は「事業の社会的意義(800字)」を求め、B財団は「対象者数とKPI(数値必須)」を求め、C財団は「他団体との連携体制(自由記述2,000字)」を求める、というやつです。

これを手作業でやると、「同じ内容を3回違う角度から書く」だけで事務局スタッフが疲弊します。Claude Codeにこの「角度変換」を任せると、初稿生成の時間を大幅に短縮できます。プロンプト例は以下。

# プロンプト例3:同じ事業を3財団分のフォーマットに展開

申請する事業:墨田拠点の子ども食堂運営(年間予算300万円)
申請対象財団:
- A財団:事業の社会的意義(800字)+収支計画
- B財団:対象者数・KPI・成果指標(表形式)+短い事業概要(400字)
- C財団:他団体との連携体制(自由記述2,000字)+事業計画書一式

【お願い】
1. 同じ事業の以下「核情報」を、3財団それぞれのフォーマットに
   展開してください
   - 事業の概要:core/01_mission.md と current_application/brief.md
     から自動抽出
   - 実績数値:annual_reports/2024_annual_report.pdf から抽出
   - 連携体制:past_applications/2024_aaa_zaidan_accepted/summary.md
     の「流用可能なパーツ」を参考

2. 展開時のルール:
   - A財団向け:社会的意義(なぜこの事業が必要か)を強調
     政策的文脈(こども家庭庁の方針、地域子育て支援拠点事業との関係)を入れる
   - B財団向け:数字・KPIを表形式で出す
     対象者数、提供回数、連携先団体数、運営コストの単価などを明示
   - C財団向け:連携体制を中心に描写
     地域の他団体3団体との役割分担、年間連携会議の頻度などを具体化

3. それぞれの初稿は以下のファイルに保存:
   - current_application/draft_a_zaidan.md
   - current_application/draft_b_zaidan.md
   - current_application/draft_c_zaidan.md

4. 3財団のドラフトを並べて、以下の観点で齟齬がないか確認:
   - 同じ事業なのに対象者数が違って書かれていないか
   - 助成希望額の合計が、自団体として現実的か
     (同じ事業に3財団から助成を受けるのは原則NG、要確認)

最終的な提出判断は事務局長です。

このプロンプトの肝は、最後の「同じ事業に3財団から助成を受けるのは原則NG、要確認」です。助成金には「重複申請の禁止」「重複助成の禁止」というルールがあり、同じ事業内容で複数財団から助成を受けることは多くの場合できません(財団側の規定による)。事業を分割して「拠点別」「対象年齢別」で申請したり、補完関係(A財団=人件費、B財団=設備費、C財団=広報費)で申請する設計が必要になります。

Claudeは「3財団分のフォーマット変換」までは得意ですが、重複助成の判定までは責任を持てません。ここは必ず事務局長または顧問社労士・行政書士が人間として判断する論点として、プロンプト末尾に「要確認」と明示しておくのが安全運用です。

実装手順4:年次報告書のドラフトと申請書サイクルの統合

4本目の実装手順は、「年次報告書の素材を、次年度の申請書に流用するパイプライン」です。これは多くのNPOで分断されている部分で、Claude Codeで統合すると効果が大きい領域です。

年次報告書を書くとき、Claudeに以下のような指示を投げると、本文ドラフトの大半を整えつつ、「次年度の申請書で流用できる素材」を抽出してくれます。

# プロンプト例4:年次報告書ドラフト+次年度申請書への素材抽出

2024年度の年次報告書を作成します。

【素材】
- annual_reports/raw_data_2024.csv(活動実績の生データ)
- past_applications/2024_*/(2024年度に申請した助成金11件)
- meeting_notes/2024_quarterly_review/(四半期レビュー議事録)

【お願い】
1. 上記素材から、annual_reports/2024_annual_report.md の初稿を作成
   - 章立ては前年度(2023)に準拠
   - 数字は raw_data_2024.csv からのみ引用
   - 受益者エピソードは「(事務局記入)」とプレースホルダ

2. 報告書執筆の副産物として、次年度2025年の申請書で流用可能な
   「成果素材ファイル」を作成
   - 出力先:core/2024_outcome_assets.md
   - 内容:対象者数の推移、新規KPI実績、特筆すべきエピソードの種、
     翌年度の事業展開につながる学び

3. 2024年度に申請した11件のうち、不採択だった4件について、
   申請書と公募要項を再読し、不採択の推定要因を3点ずつ列挙
   - 出力先:foundations/2024_rejection_analysis.md
   - 「審査員からのフィードバックがある場合は、それを優先」
   - フィードバックがない場合は「あくまで推測である」と明記

不採択要因の分析は、来年度の申請改善材料として使います。
推測が含まれることを前提に、事務局会議で議論する叩き台にします。

このプロンプトの最大の価値は、「3. 不採択分析」のパートです。NPOの事務局では、不採択になった申請書の振り返りがほぼ行われていないのが普通です。事務局スタッフが疲弊していて、結果通知が来たら一瞥して終わり、という運用です。Claudeに機械的に「不採択要因の推測」を出させると、来年度の申請改善のたたき台になります。

ただし、ここでも線引きが重要です。Claudeが出す「不採択推定要因」は、あくまで申請書と公募要項のテキスト上から読み取れる範囲の推測です。本当の不採択理由は、財団側の事業方針変更、その年の応募総数、審査員構成など、外部要因によることが多く、Claudeには分からない領域です。「不採択要因の60%は外部要因、40%が申請書側で改善可能」くらいの粒度感で受け止め、事務局会議で「来年度の申請書で書き直せそうな改善ポイント」だけを抽出する使い方が現実的です。

実装手順5:不採択フィードバックの取り込みと次年度ナレッジ化

5本目の実装手順は、「審査員からのフィードバックや、不採択通知に含まれるコメントを、次年度の申請書に確実に反映する」パイプラインです。実装手順4の延長線上ですが、こちらはより「個別フィードバックの取り込み」に特化します。

多くの財団では、不採択通知に簡単なコメント(「他団体との連携体制が弱い」「数値KPIが不明確」など)が添えられることがあります。これを past_applications/<year>_<foundation>_rejected/feedback.md として保存しておき、次回同じ財団に申請するときに必ず読み込ませる運用にします。

# プロンプト例5:不採択フィードバックを次回申請書に反映

今回、◯◯公益財団に再申請します(2026年度春)。
過去履歴:
- 2024年:不採択(feedback: 「対象児童の追跡データが弱い」)
- 2025年:不採択(feedback: 「他団体連携が体制図のみで実体が不明」)

【お願い】
1. past_applications/2024_aaa_zaidan_rejected/feedback.md と
   past_applications/2025_aaa_zaidan_rejected/feedback.md を読み込み、
   過去2年で指摘された改善ポイントを統合した「対応方針」を作成
   - 出力先:current_application/feedback_response.md
   - 対応可能/不可能を分けて記載
   - 不可能な場合は「なぜ対応できないか」を率直に書く
     (例:追跡データは個人情報の関係で取得不可、等)

2. 上記の対応方針を踏まえて、今年度の申請書ドラフトを作成
   - 過去のフィードバックに対応している箇所には
     【2024フィードバック対応】【2025フィードバック対応】のコメントを
     セクション末尾に明記(申請書本体には残さず、ドラフト時点のみ)
   - これによって、事務局会議で「フィードバックへの対応度」を
     可視化できるようにする

3. 申請書ドラフトとは別に、「同じ財団に3年連続で不採択になった場合、
   申請を続けるべきか」の検討材料として、以下を整理:
   - 過去2年の不採択コメントの傾向
   - 自団体の事業との根本的なミスマッチがないか
   - 他により合致しそうな財団がfoundations/matrix.csvにないか

3.の検討材料は事務局長・理事長の判断材料です。
Claudeから「申請をやめるべき」「続けるべき」の結論は出さないでください。

この実装の肝は、「3年連続で不採択になった場合、申請を続けるべきかを検討する材料を出す」パートです。NPO事務局には「過去に申請したことがあるから、今年も惰性で申請する」というモードに入りやすい構造があります。Claudeに「やめるべきかどうかを毎年問い直す材料」を出させることで、限られた事務局リソースを、より採択可能性の高い財団に振り向ける判断材料にできます。

ここでも、Claudeに「やめるべき/続けるべき」の結論は出させません。あくまで「判断材料」を機械的に並べるところまでで止めます。「同じ財団に長く挑戦し続けることに、団体としての象徴的意味がある」というケースもあり、これは数字では判断できない領域だからです。

【要注意】NPO助成金申請でやりがちな失敗パターン4つ

ここまでで実装手順5本を紹介しましたが、Claude Codeを助成金業務に導入するときに、現場で起こりがちな失敗パターンを4つ、❌(失敗)と⭕(回避策)の形でまとめておきます。

失敗1:Claudeの出力をそのまま提出してしまう

❌ 失敗パターン:Claudeに出させた事業計画書ドラフトを、事務局スタッフが軽くチェックしただけで提出してしまう。結果、「受益者の人物像が抽象的すぎる」「現場のリアルなエピソードがない」「代表の想いが伝わらない」といった、生成AI特有の「のっぺりした文章」のまま審査員に届く。

⭕ 回避策:Claudeの初稿は「構造」と「数字」だけを信用し、受益者エピソード・代表メッセージ・現場の困難と工夫の3点は必ず事務局スタッフと理事長が人間として書き直す。プロンプト時点で「(事務局記入)」「(理事長記入)」のプレースホルダを残しておく運用が安全。

失敗2:過去申請書の本文を流用してしまう(コピペ問題)

❌ 失敗パターン:過去採択された申請書の本文を、Claudeが新規申請にコピペしてくる。同じ財団に同じ文章で再申請すると、審査員に「使い回し」と認識される(財団によっては申請書の過去履歴を保管している)。別の財団に同じ文章を出すと、団体としての構成力を疑われる。最悪、複数財団で同一事業に対する助成を受けた場合、重複助成として返還を求められるリスクもある。

⭕ 回避策:CLAUDE.md に「過去申請書の本文流用は禁止、構造のみ参考」と明記する。summary.md(要旨)だけを参考にさせ、本文PDFは参照させない運用にする。また、新規申請ドラフトが完成したら、過去申請書とのテキスト類似度を機械的にチェックする(diff コマンドや、同じClaude セッションで「過去申請書との重複度を判定して」と頼む)。

失敗3:数字を推測で書いてしまう

❌ 失敗パターン:Claudeが「対象児童数50名」のような具体的な数字を、文脈から推測で書いてしまう。実際のデータと違う数字が申請書に載ると、採択後の中間報告や監査で齟齬が出て、財団との信頼関係を損なう。最悪のケースでは、助成金返還を求められたり、次年度以降の申請資格を失うこともある。

⭕ 回避策:CLAUDE.md に「数字は core/03_finance.md または annual_reports/ からのみ引用、不明な数字は『(要確認)』と書いて停止」と明記。事務局スタッフ側でも、申請書提出前に「数字の根拠を一つずつソース確認するチェックリスト」を運用する。Claudeが出した数字には必ず「ソース:annual_reports/2024_p12」のような引用元を付記させる運用にすると、後の検証が楽になる。

失敗4:Claudeに採否や審査員心理の判定をさせる

❌ 失敗パターン:「この申請書、採択されそうですか?」とClaudeに聞き、「採択可能性が高いです」のような楽観的な返答を信じてしまう。実際の採択は、その年の応募総数、審査員構成、財団の事業方針変更など、外部要因に大きく左右される。Claudeには財団内部の事情も審査員心理も分からない。

⭕ 回避策:Claudeには採否判定をさせない。プロンプトで「採択可能性を判定しないでください」と明示する。代わりに「公募要項との合致度」「不一致の論点」「補強すべき要素」のような機械的に判定できる項目だけを出させる。「審査員ウケしそう」「採択されると思う」といった出力が返ってきたら、その出力は採用しない(プロンプトを修正する)。

補足:財団タイプ別の申請書の「クセ」を Claude に教えておく

実装手順を回しはじめると、財団によって「審査員が好む文体」がかなり違うことに気づきます。同じ事業内容でも、財団タイプ別に文体を切り替えると、申請書全体の説得力が大きく変わります。Claude Code には、財団タイプ別の文体ガイドを foundations/style_guide.md として渡しておくと、初稿の質が安定します。

大まかに分けると以下の4タイプです。公益財団系は「社会的意義・歴史的文脈・継続性」を重視し、文体としては「やや硬めの論文調」が好まれます。「我が国の」「本邦における」のような言い回しが受け入れられやすく、一方で「めっちゃ」「ヤバい」のようなカジュアル表現は減点要素になりがちです。企業財団系は「事業性・ROI・スケール可能性」を重視し、ビジネス文書に近い文体が好まれます。数字とKPIが多めに入る方が説得力が出ます。行政公募(休眠預金・WAM助成・自治体)は「政策との接続・他団体連携・公共性」を重視し、政策文書(こども家庭庁の方針、厚労省の白書など)を引用しながら自団体の事業を位置づける文体が好まれます。個人篤志家・草の根助成は逆に「現場のリアル・受益者の声・代表の想い」を重視し、感情に訴える文体が好まれます。

これら4タイプを matrix.csv に style_tag 列として追加しておくと、Claude Code に「この財団のスタイルで書いて」と指示できるようになります。プロンプト例としては「F003 は行政公募タイプなので、policy_context.md を参照しつつ、政策的文脈を冒頭2段落に入れてください」のような形で、財団ごとに文体を機械的に切り替えられます。これも事務局スタッフの認知負荷を下げる重要な工夫です。

運用パターンと事務局スタッフの役割分担

5本の実装手順を導入した場合、想定モデル(事務局2名+理事長1名)での運用パターンは、おおむね以下のような分担になります。

• 事務局スタッフA(申請担当):公募情報のチェック、 foundations/matrix.csv の更新、Claude Codeへの初稿生成プロンプト投入、ドラフトの一次レビュー、過去申請書の要旨ファイル整備
• 事務局スタッフB(現場担当):受益者エピソードの素材提供、現場の困難と工夫の素材提供、Claudeが書いたドラフトの「現場リアリティチェック」
• 理事長/事務局長:代表メッセージの執筆、申請する/しないの最終意思決定、不採択時の事務局会議リード、3年連続不採択時の継続判断

この分担にすると、事務局スタッフAは「Claude Codeとの対話」が業務時間の中心になり、事務局スタッフBは「現場との情報パイプライン」が中心になります。理事長は「意思決定」と「外向きメッセージング」に集中できます。Claude Codeを導入することで、人間が人間にしかできない仕事に集中できる時間が増える、というのが想定モデルケースのゴール像です。

導入初月のスケジュール感としては、以下のような3週間のオンボーディングを想定するとスムーズです。1週目は環境構築週として、Claude Code のインストール、 npo_grants/ ディレクトリの初期構築、core/ フォルダの基本ファイル整備までを行います。事務局スタッフAが半日 × 5日くらい使う感覚です。2週目は試運転週として、過去採択申請書3件分の summary.md を作成し、その3件をClaudeに読ませて「もし今、同じ財団に再申請するとしたら、どんな骨子になるか?」を試させます。ここで「Claude が書いてくる文章のクセ」「現場視点で違和感が出るポイント」を把握しておくと、本番運用での修正コストが下がります。3週目は本番投入週として、実際の新規公募1件にClaudeを使って初稿を作成し、事務局会議で全員でレビューします。この3週目のレビュー会議が、組織として Claude Code の使い方を共有する場になります。

3週目以降は通常運用に入りますが、最初の2〜3ヶ月は「Claudeに任せた範囲」と「人間が書き直した範囲」を毎回記録するのがおすすめです。 current_application/handoff_log.md のようなファイルに「Claudeの初稿:◯◯字、人間の書き直し:◯◯字、書き直しの主な理由:◯◯」を残しておくと、3ヶ月後に「どこの工程で人間の介入が一番必要か」が見えてきます。介入が多い工程ほど、プロンプトの改善やcore/ファイルの充実で次回以降の負荷を下げられる、改善サイクルが回せるようになります。

当然ながら、これは「Claude Code を導入すれば自動的にこの分担になる」というものではなく、事務局会議で役割分担を明文化し、月次で見直す運用とセットでないと機能しません。生成AIの導入で最も陥りやすいのは「ツールだけ入れて運用設計しない」パターンで、これは助成金申請業務でも同じです。

補足:中間支援組織・社労士・行政書士による「複数NPO並走運用」

本記事のここまでは「単一のNPO事務局が自分たちのために Claude Code を導入する」前提でしたが、現場では中間支援組織や、NPO顧問をしている社労士・行政書士が、複数団体の助成金申請を並走で支援するケースも多いはずです。ここでは複数団体並走時の運用上の留意点を補足しておきます。

まず最重要なのが「団体ごとにリポジトリを物理的に分ける」こと。1つの作業ディレクトリに複数団体の core/ や past_applications/ を混ぜると、Claude Code が別団体の数字や事業内容を誤って引用する事故が必ず起きます。npo_grants_a団体/ npo_grants_b団体/ のように完全に分け、セッション開始時のカレントディレクトリを明確に切り替える運用にしてください。中間支援組織のメンバー側で「今 A 団体の作業中」「次は B 団体に切り替え」というコンテキスト管理を徹底することが大前提になります。

次に重要なのが「データの預かり管理ポリシー」です。NPO の事業計画書には、受益者の個人情報(マスクされていても再識別リスクあり)、団体の財務情報、寄付者リスト、理事の住所など、機微情報が含まれます。中間支援組織として複数団体のデータを Claude Code で扱う場合、各団体との間でデータ取り扱いの覚書を交わし、「中間支援組織のローカル PC でのみ扱う」「クラウドアップロード時は事前許諾」「業務終了時は削除」などのルールを明文化しておくべきです。Anthropic 側のデータ利用ポリシーも変更があり得るので、現行の規約を年1回はチェックする運用を入れましょう。

もう1つ、「共通テンプレと団体別差分の分離」も大事です。中間支援組織で複数団体を支援していると、「事業計画書の標準章立て」「収支計画の標準フォーマット」「採択されやすい表現」のような共通ノウハウが蓄積されてきます。これを shared_templates/ として中間支援組織側で1箇所に集約し、各団体リポジトリからは参照する形にしておくと、ノウハウのアップデートが楽になります。Claude Code からは ../shared_templates/ という相対パスで参照させる構成にしておくと、団体側のリポジトリは clean な状態を保てます。

Claude Codeを助成金業務に使うときの倫理的論点

最後に、技術論ではなく倫理的な論点を3つ書いておきます。NPOの助成金業務にAIを使うことに、社会的・道義的な異論が出る可能性があるからです。

第一の論点は「助成金は公的資金性が強く、申請書の作成プロセスにAIを使うことは適切か」です。助成金の原資が公的資金(休眠預金、企業のCSR予算、行政補助金)である以上、申請プロセスの透明性は重要です。Claude Codeを使うこと自体は禁止されていませんが、財団によっては「申請書はすべて自団体内で作成すること」を求めることがあります。AI利用の有無を聞かれた場合は正直に開示するのが安全運用です。「Claudeに初稿の構造を作らせ、本文は人間が書き直した」と説明できる状態にしておきましょう。

第二の論点は「生成AIの利用で、申請書の質に格差が生まれるのではないか」です。事務局スタッフが多く、AI活用に詳しいNPOと、事務局スタッフが1名のみで AI に触れる時間がないNPOとで、申請書の完成度に差が出てしまうリスクがあります。これは制度設計の問題でもありますが、現場としては「Claude Codeを使えるNPOが、使えないNPOに知見を共有する」中間支援機能を意識的に持つべきです。本記事のようなオープンな知見共有も、その一環として位置づけられます。

第三の論点は「受益者の物語をAIに書かせていいのか」です。NPOの申請書には、子ども・高齢者・障害のある方など、社会的に弱い立場の人々の物語が出てきます。彼らの人生の一場面をAIが「文学的に整える」ことには違和感を持つ人もいるはずです。本記事の実装では、受益者エピソードは 必ず事務局スタッフが現場で聞き取った素材を、人間がそのまま書く運用にしています。Claudeに整えさせない、整わせない、ということ自体が、NPO事業者としての倫理的な態度表明です。

導入のはじめの一歩:今週やる3つのこと

本記事を読んで「うちのNPOでも試してみたい」と思った方に向けて、最初の1週間でやるべき3つのアクションを提案します。

1. core/ フォルダの整備(所要時間:半日):上記の core/01_mission.md から core/05_voice_samples.md までを、既存資料(団体パンフレット、定款、直近の年次報告書、寄付者向けレター)から組み立てる。これだけで、以降のClaude Codeとのやりとりが激変します。
2. 過去採択申請書3件分の summary.md 作成(所要時間:1日):直近3年で採択された申請書の中から、代表的な3件を選び、要旨ファイルを作成。完璧でなくて構いません。「この3件があれば、似たような新規申請の初稿は8割組み立てられる」状態を目指します。
3. foundations/matrix.csv の最低限化(所要時間:半日):現在申請している・申請を検討している財団を10〜15件、CSVに並べる。完全なリストでなくて構いません。「公募が来たらClaude Codeに突合させる先がある」状態を作るのが目的です。

この3つを揃えれば、4日目から「新規公募が来たら、Claude Codeに突き合わせて、初稿を1時間で作る」運用に入れます。最初の数件は手探りで時間がかかりますが、3〜4件目から劇的に早くなります。

まとめ:NPO事務局を「現場に向き合う時間」に取り戻す

本記事では、NPO・非営利団体の助成金申請業務にClaude Codeを「下ごしらえ係」として常駐させる想定モデルケースを、5本の実装手順とともに紹介しました。重要なのは以下の3点です。

第一に、Claude Codeに任せるのは「公募チェック」「要件マトリクス管理」「初稿の構造作成」「過去申請書の要旨流用」「不採択フィードバックの取り込み」までで、受益者エピソード・代表メッセージ・現場の困難と工夫の3点は必ず人間が書くこと。第二に、CLAUDE.md と core/ フォルダを最初にきちんと整備すれば、毎回の指示文を短くでき、運用が続けられること。第三に、採択は審査員判断であり、Claude Codeを使ったからといって採択が約束されるものではないこと。あくまで事務局の作業負荷を軽減し、人間が現場に向き合う時間を取り戻すための道具として位置づけることが重要です。

NPOの事務局スタッフが疲弊する根本原因は、「同じ素材を違うフォーマットに何度も並び替える事務作業」に時間を取られすぎていることです。Claude Codeはこの並び替え作業を肩代わりするのは得意ですが、現場で受益者と向き合うこと、代表として団体の想いを語ること、財団との信頼関係を築くこと、地域の他団体と連携を組むこと──これらは人間にしかできません。生成AIを導入することで、人間にしかできない仕事に集中できる時間が増える、というのが本記事のメッセージです。

関連する業界向けの実装事例として、以下の記事もあわせてどうぞ。SaaS事業者のカスタマーサクセスでヘルススコアを運用する事例、監査法人の監査調書レビューを7ステップで効率化する事例、地方自治体の業務にClaude Codeを差し込んだ5つの事例を扱っています。

• SaaS事業者のカスタマーサクセス業務でヘルススコアをClaude Codeで運用する想定モデル事例
• 監査法人の監査調書レビューをClaude Codeで7ステップ効率化する想定モデル事例
• 地方自治体・市町村業務をClaude Codeで効率化する5つの想定モデル事例

参考出典

• 内閣府「NPOホームページ」(認定NPO法人制度、特定非営利活動法人制度の概要、所轄庁別の認証情報。事業計画書の標準項目を確認するときの一次ソースとして参照)
• 独立行政法人福祉医療機構「WAM助成(社会福祉振興助成事業)」(NPO・社会福祉法人向けの代表的な助成制度。公募要項・申請書様式の構造を参考にする際の一次ソース)
• 一般財団法人 日本民間公益活動連携機構(JANPIA)「休眠預金等活用事業」(休眠預金を原資としたNPO向け助成事業の枠組みと公募スケジュール。複数年事業計画書のテンプレ構造の参考)
• Anthropic公式「Claude Code」(本記事で扱っているコーディング/対話型ツール本体の公式ドキュメント。CLAUDE.md や ファイル参照の仕様について最新仕様はこちらを確認のこと)
• こども家庭庁「こども家庭庁公式サイト」(子ども・若者支援領域のNPO向け公募事業の所管。本記事の想定モデルケース(子どもの居場所づくり)に関連する政策的文脈の確認用)

関連記事（自動）

• ▸ 【2026年最新】司法書士・法律事務所のClaude Code活用｜登記・契約書を効率化
• ▸ 【2026年最新】税理士・会計事務所のClaude Code活用｜申告書・顧問先レポート自動化
• ▸ 法律事務所×Claude Code 完全実装ガイド｜契約書ドラフト・判例リサーチ・依頼者対応の月100時間効率化【2026年最新】
• ▸ 【2026年最新】コールセンター応対メモ自動化×Claude Code
• ▸ 動画字幕・サムネ案・概要欄をClaude Codeで半自動化