結論：社内マニュアルが「あるのに使われない」最大の原因は量ではなく構造の欠如であり、Diátaxis（ディアタクシス）の4分類を判定基準としてClaude Codeに与えれば、既存マニュアル群の再分類・抜け漏れ検出・更新停滞の検知までを仕組みとして回せます。
- 要点1：Diátaxisは文書を「チュートリアル／ハウツー／リファレンス／解説」の4象限に分ける技術文書のフレームワーク。判定基準が明文化されているため、LLMによる自動分類と相性がいい
- 要点2：Claude Codeなら「分類→ギャップ検出→鮮度監査」の3段階をすべてリポジトリ上のコマンドとして定義でき、一度作れば誰が実行しても同じ結果になる
- 要点3：最初の棚卸しは既存ファイルを1行も書き換えずに始められる。分類レポートを人間がレビューしてから移行する2段階方式が安全
対象読者：社内マニュアル・業務手順書の整備を任された情報システム部門・経営企画・PM、およびドキュメント運用を自動化したい開発者。今日やること：本記事の棚卸しプロンプトを既存マニュアルのフォルダに対して1回実行し、現状の4分類マップを出すところまで。
「マニュアルはあるんです。ただ、どこに何があるか誰も分からなくて」——AI研修や導入支援の現場で、この台詞を何度も聞いてきました。共有ドライブには何百というWordやPDFが眠っているのに、新人は結局隣の席に聞き、ベテランは「前に書いたはずの手順書」を再度書き、監査のたびに最新版探しが始まる。ファイルの量は十分なのに、機能していない状態です。
この問題に「とりあえずAIに要約させる」で挑むと失敗します。構造がない文書群を要約しても、構造がない要約が増えるだけだからです。必要なのは、先に「文書をどう分けるべきか」という設計思想を固定し、その設計思想を判定基準としてAIに渡すこと。本記事では、技術文書の世界で実績のあるフレームワークDiátaxisを社内マニュアルに翻訳し、Claude Codeで運用まで乗せる実装パターンを、実際に使えるプロンプトとディレクトリ設計つきで解説します。
なぜ社内マニュアルは「あるのに使えない」状態になるのか
整備が頓挫する現場には共通の構図があります。筆者が支援先で見てきた範囲では、おおむね次の3つに集約されます。
1. 1つの文書に複数の役割が同居している。「経費精算マニュアル」を開くと、システムの操作手順、精算ルールの一覧、制度導入の背景説明、新人向けの練習課題が全部1ファイルに入っている——よくある形です。手順だけ知りたい人には長すぎ、ルールを引きたい人には探しにくく、結果として誰にとっても使いにくい文書になります。
2. 更新責任が構造に紐づいていない。「このファイルの何節を誰がいつ見直すか」が決まっていないため、制度改定があっても古い記述が残り続けます。読者は一度でも古い情報を踏むと、その文書群全体を信用しなくなります。
3. 分類軸が書き手ごとにバラバラ。部署別フォルダ、作成年度別フォルダ、担当者名フォルダが混在し、同じ業務の文書が3箇所に分かれて置かれる。検索しても複数の版がヒットし、どれが正か分からない。
注目すべきは、この3つがすべて「書く量」の問題ではなく「分け方」の問題だという点です。だからこそ、分け方のフレームワークから入る必要があります。
Diátaxisとは——4分類と2つの軸
Diátaxis（diataxis.fr）は、技術文書の書き方・分け方・並べ方を体系化したフレームワークです。文書の利用者には4つの異なるニーズがあるとし、それぞれに対応する4形式を定義します。GatsbyやCloudflare、Vonageなど数百のドキュメントプロジェクトで採用実績があり、2026年7月にはHacker Newsでも再び話題になりました。
| チュートリアル | ハウツーガイド | リファレンス | 解説 | |
|---|---|---|---|---|
| 答える問い | 「教えてもらえますか？」 | 「どうやるの？」 | 「これは何？」 | 「なぜ？」 |
| 志向 | 学習 | 目標達成 | 情報 | 理解 |
| 形式 | レッスン | 手順の連なり | 簡潔な記述 | 論述的な説明 |
| 料理の例え | 子どもに料理を教える | 料理本のレシピ | 食品パッケージ裏の成分表 | 料理の文化史の記事 |
公式サイトの比較表（The map）を要約したものです。重要なのは、この4つが単なるリストではなく2軸のマトリクスになっている点です。縦軸は「行動（実践）か、認知（理論）か」、横軸は「習得のためか、業務適用のためか」。チュートリアルは行動×習得、ハウツーは行動×適用、リファレンスは認知×適用、解説は認知×習得に位置します。
Diátaxisが警告するのは分類同士の「にじみ（blur）」です。特にチュートリアルとハウツーの混在は深刻で、公式サイトは「最悪の場合、両者が互いに崩壊し合い、どちらのニーズも満たせなくなる」と指摘しています。冒頭で挙げた「1ファイルに全役割が同居する経費精算マニュアル」は、まさにこの崩壊が起きた状態です。
Diátaxisを社内マニュアルに翻訳する
Diátaxisはソフトウェアドキュメント発のフレームワークですが、判定基準が「読者が何を求めて文書を開くか」に置かれているため、業務マニュアルにもそのまま適用できます。社内文書への対応はこうなります。
| Diátaxis分類 | 社内文書での実体 | 読者の状況 | 更新頻度の目安 |
|---|---|---|---|
| チュートリアル | 新人向けオンボーディング教材、初回セットアップの練習課題 | 入社直後・異動直後。まだ業務を知らない | 低（四半期〜年次） |
| ハウツーガイド | 業務手順書、申請フロー、障害時の対応手順 | 業務中。目の前のタスクを終わらせたい | 高（システム改修のたび） |
| リファレンス | 勘定科目一覧、権限マトリクス、規程・様式集、マスタ定義 | 業務中。正確な値・定義を引きたい | 中（制度改定のたび） |
| 解説 | 制度の背景説明、業務フローの設計思想、なぜこの承認経路なのか | 業務外。全体像を理解したい | 低（年次） |
この対応表には実務上の副産物があります。分類ごとに更新頻度の目安が異なるため、「ハウツーは90日、リファレンスは180日を超えて未更新なら要確認」のように、鮮度監査の閾値を分類単位で設定できるのです。全文書に一律の見直しサイクルを課すと形骸化しますが、分類別なら現実的な運用になります。これが後述する「更新停滞の検知」の土台になります。
実装パターン1：既存マニュアル群の棚卸しと4分類
最初のステップは、既存ファイルを1行も書き換えずに現状マップを作ることです。いきなり移行や書き換えから入ると、レビューできない規模の差分が生まれ、関係部署の合意も取れません。まず読み取り専用の分類レポートを出し、人間が確認してから動かす——この2段階が安全です。
共有ドライブのマニュアル類を作業用フォルダに集め（WordやPDFはテキスト化しておくと精度が上がります）、Claude Codeを起動して次のプロンプトを投げます。
docs-inventory/ 配下の全ファイルを読み、Diátaxis（diataxis.fr）の
4分類で棚卸しせよ。ルール:
1. ファイルは一切書き換えない。レポート出力のみ
2. 各ファイルについて「主分類 / 副分類 / confidence(高中低) / 根拠」
を1行で判定する
3. 判定基準は「読者が何を求めて開く文書か」。
- 学習のための練習 → tutorial
- 業務中の目標達成の手順 → how-to
- 正確な値・定義の参照 → reference
- 背景・理由の理解 → explanation
4. 1ファイルに複数分類が同居している場合は「混在」とし、
どの節がどの分類かを見出し単位で列挙する
5. 結果は report/inventory.md に Markdown 表で出力するポイントは4番です。実際に走らせると、体感では相当数のファイルが「混在」判定になります。これは分類の失敗ではなく、混在ファイルのリストこそが再編成の作業台帳になるということです。どのファイルを分割すべきかが、見出し単位の根拠つきで手に入ります。
レポートを人間がレビューしたら、次に移行先のディレクトリ構造を固定します。
manuals/
├── CLAUDE.md # 分類ルールと運用ルールを記述
├── tutorials/ # 新人向け教材
├── how-to/ # 業務手順書（部署別サブフォルダ可）
├── reference/ # 規程・一覧・マスタ定義
├── explanation/ # 制度背景・設計思想
└── report/ # 監査レポート出力先各ファイルの先頭にはメタデータ（frontmatter）を持たせます。これが後の抜け漏れ検出と鮮度監査の機械可読な足場になります。
---
title: 経費精算の申請手順
type: how-to # tutorial / how-to / reference / explanation
owner: 経理部
business: 経費精算
last_reviewed: 2026-07-15
review_cycle_days: 90
---混在ファイルの分割もClaude Codeに任せられます。ここは書き換えを伴うので、必ず1ファイルずつ差分をレビューしてください。
docs-inventory/keihi-manual.md は inventory.md で「混在」判定だった。
これを Diátaxis 4分類に分割せよ。ルール:
1. 原文の文言は変えない。節単位の移動と見出しの整理のみ
2. 操作手順の節 → how-to/keihi-seisan-shinsei.md
3. 勘定科目・上限額の一覧 → reference/keihi-kitei.md
4. 制度の背景説明 → explanation/keihi-seido-haikei.md
5. 各ファイルに frontmatter を付与し、元ファイルからの
移動元見出しをコメントで残す
6. 分割後、相互リンクを冒頭に張る（手順→規程、規程→背景）「原文の文言は変えない」を明示するのが重要です。分割とリライトを同時にやると、内容の正しさと構造の正しさを同時にレビューする羽目になり、確認コストが跳ね上がります。構造を直してから、必要な箇所だけ文言を直す。順番を分けるだけでレビューは格段に楽になります。コード生成の文脈になりますが、ドキュメント生成の基本パターンはClaude Codeでドキュメント生成｜README・API仕様書でも詳しく扱っています。
実装パターン2：分類マトリクスの空白セルで抜け漏れを検出する
再編成が済むと、Diátaxisのもう1つの強みが使えるようになります。「業務 × 4分類」のマトリクスを作ると、空白セルがそのまま抜け漏れ候補になるのです。従来の「マニュアルが足りない気がする」という感覚論が、機械的に列挙できる形に変わります。
manuals/ 配下の全ファイルの frontmatter を読み、
「business（業務名）× type（4分類）」のマトリクスを作成せよ。
1. 行 = business の一覧、列 = tutorial / how-to / reference / explanation
2. セルには該当ファイル数を記入し、0のセルは「空白」と明示する
3. 空白セルのうち、埋めるべき優先度が高いものを理由つきで5件挙げる。
判定の目安:
- how-to が存在するのに reference がない業務
→ 手順の中に規程値が直書きされている可能性が高い
- reference しかない業務
→ 新人がゼロから手順を組み立てられない
4. 結果を report/gap-matrix.md に出力する3番の判定目安は実務でよく効きます。たとえば「ハウツーはあるのにリファレンスがない」業務では、上限額や締切日などの規程値が手順書の本文に直書きされていることが多い。この状態だと制度改定のたびに複数の手順書を探して直すことになり、更新漏れの温床になります。空白セルの検出は、単なる「文書が足りない」以上の構造リスクを炙り出してくれるわけです。
なお、全セルを埋めることが目的ではありません。小さな業務にチュートリアルは不要なことも多く、「空白のままでよい」と判断した記録を残すことにも価値があります。マトリクスは埋めるためではなく、判断の抜けをなくすためのツールです。
実装パターン3：更新が止まった文書の検知
整備プロジェクトの最大の敵は、完成直後から始まる劣化です。ここを仕組み化しないと、1年後には元の状態に戻ります。frontmatterにlast_reviewedとreview_cycle_daysを持たせたのは、この監査を機械化するためです。
manuals/ 配下の全ファイルについて鮮度監査を実行せよ。
1. frontmatter の last_reviewed + review_cycle_days が
今日を過ぎているファイルを「期限切れ」として列挙する
2. git 管理下にあるので、git log -1 --format=%cs -- <file> で
実際の最終コミット日も取得し、frontmatter と食い違う場合は
「メタデータ未更新」として別リストにする
3. 期限切れファイルは owner 別にグルーピングして
report/staleness.md に出力する
4. 本文中の日付・年度表記（「2025年度」等）を抽出し、
現在より2年度以上古いものを「要確認の古い記述」として挙げる2番がこの監査の肝です。「メタデータ上は見直し済みなのにファイルは何ヶ月も触られていない」あるいはその逆——メタデータと実際の更新履歴のズレは、運用が形骸化し始めたサインとして早期に拾えます。Git管理にしておく利点がここで効いてきます。
この監査は手動実行でも十分機能しますが、リポジトリ運用に慣れているチームならCIやcronで週次実行し、期限切れリストをチャットに通知するところまで自動化できます。重要なのは、通知の宛先を分類とownerで絞ること。全員宛の「マニュアル見直してください」は誰も動きませんが、「経理部owner文書のうちハウツー3件が90日超過」なら動けます。
運用に乗せる：CLAUDE.mdとカスタムコマンド
ここまでの3パターンを毎回プロンプトとして打つのは現実的ではありません。Claude Codeにはプロジェクト直下のCLAUDE.mdを自動で読み込む仕組みがあるので（公式ドキュメント: Manage Claude’s memory）、分類ルールをそこに常駐させます。
# manuals/CLAUDE.md（抜粋）
## 文書分類ルール
- このリポジトリの文書は Diátaxis（diataxis.fr）の4分類に従う
- 新規文書は必ず tutorials / how-to / reference / explanation の
いずれか1つのディレクトリに置き、frontmatter を付与する
- 1ファイルに複数分類を混在させない。混在を検出したら分割を提案する
- 手順書（how-to）に規程値を直書きしない。reference へのリンクにする
- 文書を編集したら last_reviewed を更新する定型監査は.claude/commands/のカスタムコマンド（スラッシュコマンド）にします。たとえば.claude/commands/audit-docs.mdに鮮度監査プロンプトを保存すれば、以後は誰が実行しても/audit-docsの一撃で同じ監査が走ります。属人化しがちな「ドキュメント委員の秘伝の手順」を、リポジトリに焼き込めるのがこの方式の利点です。
製造業の現場で同じ発想を作業手順書（SOP）に適用した例は製造業の作業手順書・技能伝承をClaude Codeで効率化で紹介しています。あちらは動画・写真からの手順書起こしが主題ですが、生成した手順書の置き場所と分類は本記事のパターンがそのまま使えます。
段階的導入のロードマップ
全社一斉導入は推奨しません。範囲を絞って構造の効果を確認してから広げる方が、合意形成も含めて速く進みます。目安のロードマップは次の3段階です。
Phase 1（目安1〜2ヶ月）：1部署・1業務領域を選び、棚卸し→分類レポート→レビュー→再編成まで通す。ここでの目的は移行の完遂ではなく、「混在ファイルがどれくらいあるか」「分割後の使い勝手がどう変わるか」の実測です。
Phase 2（目安3〜4ヶ月）：対象部署を広げ、CLAUDE.mdとカスタムコマンドを整備して、新規文書が最初から4分類に沿って作られる状態にする。新規作成時にも分類ゲートを通します。
新しいマニュアルの下書きを作る前に、まず次を確認せよ:
1. この文書の読者は「学習中」か「業務中」か「参照したい」か
「理解したい」か。1つに決める
2. 決めた分類のディレクトリに既存の類似文書がないか検索する。
あれば新規作成でなく更新を提案する
3. how-to なら、手順は番号リスト・1手順1アクションで書き、
規程値は reference へのリンクにするPhase 3（目安5ヶ月目以降）：鮮度監査を定期実行に載せ、空白セルの解消を四半期ごとの計画に組み込む。ここまで来ると「整備プロジェクト」は終わり、「運用」だけが残ります。
やりがちな失敗パターン
❌ 失敗1：分類とリライトを同時にやる。再編成の差分に文言修正が混ざると、レビュー担当は構造と内容を同時に検証することになり、確認が追いつかずに形だけの承認になります。
⭕ まず節単位の移動だけ。文言修正は構造確定後に別の差分として出す。
❌ 失敗2：AIの分類結果を無レビューで確定する。LLMの分類は境界事例（チュートリアルとハウツーの間など）で揺れます。confidence「低」の判定をそのまま採用すると、後から分類不信が広がります。
⭕ confidenceを必ず出させ、「低」だけ人間が判定する。全件レビューより現実的で、精度も担保できます。
❌ 失敗3：フォルダを作って満足する。4分類のディレクトリを切っただけでは、次に文書を書く人が旧来の書き方に戻り、数ヶ月で混在が再発します。
⭕ CLAUDE.mdに分類ルールを常駐させ、新規作成時の分類ゲートまで含めて初めて「仕組み化」です。
❌ 失敗4：効果を「削減率◯%」で約束してしまう。マニュアル整備の効果は問い合わせ削減・引き継ぎ短縮など間接的に現れるため、事前の断定は根拠を持てません。
⭕ 着手前に「新人が特定業務を一人で完了するまでの時間」「同一質問の発生件数」など測れる指標を決め、Phase 1の実測で語る。
よくある質問
Q. WordやPDFしかなく、MarkdownでもGit管理でもありません。それでも始められますか？
A. 始められます。棚卸しフェーズはテキスト化さえできれば動くので、まずWord/PDFをテキスト抽出して分類レポートを出すところから着手してください。ただし鮮度監査（実装パターン3）は更新履歴が機械可読であることに依存するため、再編成のタイミングでMarkdown化とGit管理への移行を組み込むのが現実的です。移行自体もClaude Codeに変換させられます。
Q. Diátaxisの4分類は業務マニュアルに全部必要ですか？
A. 全業務に4分類を揃える必要はありません。実務で最初に効くのはハウツーとリファレンスの分離（手順と規程値の分離）で、チュートリアルと解説は新人受け入れが多い業務から優先的に整備すれば十分です。空白セルは「埋める」か「空白のままでよいと記録する」かを判断することに意味があります。
Q. 分類の判定精度はどの程度期待できますか？
A. 定型的な手順書や一覧表は安定して分類できますが、境界事例では揺れます。精度の数値は文書群の状態に依存するため断定できません。だからこそ本文で述べたとおりconfidenceを出力させ、「低」判定のみ人間がレビューする運用を前提にしてください。判定基準そのものをCLAUDE.mdに書いておくと、揺れは徐々に減らせます。
Q. 機密文書を扱う場合の注意点はありますか？
A. 人事評価や個人情報を含む文書は、棚卸しの対象フォルダから最初から除外するのが原則です。組織のAI利用ポリシーで許可された範囲の文書だけを作業フォルダに集める運用にし、除外リスト自体もCLAUDE.mdに明記しておくと、後から参加したメンバーが誤って投入する事故を防げます。
Q. 社内Wiki（Confluence等）を使っている場合はどうしますか？
A. 考え方はそのまま使えます。Wikiのエクスポート機能でページ群を取り出して棚卸しし、分類結果をWiki側のスペース構成やラベルに反映する形です。ただし更新履歴ベースの鮮度監査はツールのAPIに依存するため、実装難度はGit管理より上がります。どちらを正とするかを先に決めてから着手してください。
まとめ：構造を決めてからAIに渡す
社内マニュアル整備にAIを使う際の要点は、「AIに丸投げする」のではなく「判定基準を人間が固定し、その基準の適用をAIに任せる」ことです。Diátaxisはその判定基準として、明文化・実績・シンプルさの3拍子が揃っています。棚卸し→再編成→抜け漏れ検出→鮮度監査のサイクルが回り始めれば、マニュアルは「作って終わりの成果物」から「維持される仕組み」に変わります。
まずは今日、共有ドライブの1フォルダに対して棚卸しプロンプトを1回実行してみてください。自社のマニュアルがどれだけ「混在」しているかを見るだけでも、次にやるべきことが具体的になるはずです。
次のアクション：
- 既存マニュアルの1フォルダで棚卸しプロンプトを実行し、4分類マップを出す
- 混在ファイルを1つ選び、分割プロンプトで再編成の感触を確かめる
- 手応えがあれば、CLAUDE.md・frontmatter・鮮度監査までをPhase 1として計画する
Uravationでは、Claude Codeの社内導入設計・ドキュメント運用の仕組み化を含む伴走支援を行っています。自社のマニュアル群でこのパターンを試したい方はお問い合わせからご相談ください。次回は、再編成後のマニュアルを社内チャットボットの知識ベースとして接続するパターンを予定しています。
出典
- Diátaxis — A systematic approach to technical documentation authoring（公式サイト）
- Diátaxis — The map（4分類の比較表・2軸構造の解説）
- Claude Code Documentation — Manage Claude’s memory（CLAUDE.mdの仕様）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載執筆。
