TL;DR
- 暗黙知は個人の課題ではなく、組織設計の構造的問題として捉え直す
- 形式知化は「オンボーディング／Decision Log／レビュー／文脈ファイル」の 4本柱 で回す
- AI 時代は CLAUDE.md / AGENTS.md を SSoT に組み込み、人間と AI が同じ知識を読む状態を作る
- 自社診断10項目で「いま塞ぐべき柱」を特定 → 30/60/90 日で運用を立ち上げる
- 記事末尾でナレッジ運用テンプレ（CLAUDE.md / AGENTS.md / Decision Log / オンボーディング雛形）を配布
自社の暗黙知が組織設計のどこから漏れているか、診断テンプレで30分で可視化できます。記事末尾の配布リンクからどうぞ。
はじめに
こんにちは、みねです。
「特定メンバーが休むとプロジェクトが止まる」「ドキュメントを書いても誰も更新しない」「AI コーディング支援を入れたのに、コンテキスト不足で精度が出ない」。10〜50 名規模の開発組織を率いる EM・Tech Lead から、この三つは必ず聞きます。
結論から言います。これは個人のドキュメント力の問題ではありません。組織装置の不在が引き起こす構造的な現象です。
本記事では、暗黙知を「個人の責任」から「組織設計の問題」に再定義し、4本柱（オンボーディング／Decision Log／レビュー／文脈ファイル）で塞ぐ手順を整理します。AI 時代の文脈ファイル（CLAUDE.md / AGENTS.md）まで含めて、当社で実際に運用している一次情報を出します。対象は 10〜50 名規模の開発組織で、それ以上は組織論の力学が変わるためスコープ外です。
なぜ暗黙知は「個人の問題」では解けないのか
ここでは概念整理を行います。手順は次章以降です。
属人化の正体は「組織装置の不在」
属人化を「あの人がドキュメントを書かないから」と語ると、解決策は一向に進みません。本人の善意に依存している限り、退職・休暇・配置転換のたびに同じ問題が再発します。
属人化の正体は次のように言い換えられます。
知識の偏在は、それを引き出して残す装置が組織に存在しないから起こる。
評価制度がドキュメントを書いた人を評価しなければ、誰も書きません。1on1 で「いま誰が何を抱えているか」を可視化しなければ、誰がボトルネックかも見えません。レビューが「コードの是非」しか問わなければ、設計判断の理由は記録されません。これらは個人の問題ではなく、装置の問題です。
暗黙知 / 形式知 / SECI モデル
野中郁次郎『知識創造企業』(東洋経済新報社, 1996) で提示された SECI モデルは、知識創造を 4 プロセスで捉えます。
- 共同化 (Socialization): 暗黙知 → 暗黙知（OJT・ペアプロ）
- 表出化 (Externalization): 暗黙知 → 形式知（ドキュメント化・ADR）
- 連結化 (Combination): 形式知 → 形式知（既存ドキュメントの再構成）
- 内面化 (Internalization): 形式知 → 暗黙知（読んで実践し体得する）
本記事の文脈では、4 本柱はこの SECI を組織装置に落とし込んだものと理解してください。オンボーディングは「内面化」、Decision Log とレビューは「表出化」、文脈ファイルは「連結化」を回す装置です。
AI 時代に暗黙知コストが跳ね上がる理由
AI コーディング支援が広がると、暗黙知のコストはさらに跳ね上がります。理由は単純で、AI は 与えられた文脈の中でしか判断できない からです。
リポジトリ内に「なぜこの設計にしたか」「どのファイルが SSoT か」「禁止事項は何か」が残っていなければ、AI は最もそれらしいコードを生成します。結果、レビューに回ってから「これは前にやめたパターンだ」と判明し、手戻りが増えます。これが コンテキスト負債という新しい技術的負債 の正体です。
人間にとっての暗黙知は、AI にとっての文脈不足と同じ構造です。だからこそ、AI 時代のナレッジ共有は人間向けと AI エージェント向けの両方を同じ SSoT で扱う設計が必要になります。
暗黙知を減らす組織設計の 4 本柱
ここでは「静的な装置設計」を扱います。動的な運用力学（人間と AI が同じ SSoT を読み続ける仕組み）は次章で深掘りします。
柱① オンボーディング設計（30/60/90 日）
入社直後の 90 日で何を読み、誰と話し、何を作るかを構造化します。最低限の型は次の通りです。
- 0〜30 日: ミッション・プロダクト全体像・主要リポジトリの README / AGENTS.md を読む。1on1 で「誰が何を持っているか」のメンタルマップを作る
- 30〜60 日: 小さな PR を 5 本出す。Decision Log を 1 本書く（自分が触れた領域の設計判断を 1 つ言語化）
- 60〜90 日: 自分の担当領域のドキュメントを 1 本「使われる状態」に整備する
ポイントは、読む順序を構造化することと、書く成果物（PR / ADR / ドキュメント整備）を最初から組み込むことです。「とりあえず聞いてください」運用は、聞かれる側に依存するため属人化を再生産します。
柱② Decision Log（ADR・Nygard 形式）
意思決定の理由を残さないと、半年後に同じ議論を繰り返します。Architecture Decision Record (ADR) は Michael Nygard が "Documenting Architecture Decisions" (2011) で提示したシンプルな型です。
# ADR-0042: 認証基盤を Auth0 から自前実装に切り替える
- Status: Accepted
- Date: 2026-04-15
- Decider: @miine, @engineering-lead
## Context
ユーザー数の増加で Auth0 の月額が想定の3倍に達した。
SLA 要件と多要素認証の独自カスタマイズも必要になった。
## Decision
NextAuth.js + 自前 DB セッション管理に切り替える。
移行は3か月、既存ユーザーはサイレント移行とする。
## Consequences
- 月額コスト: 70% 削減
- 運用負荷: SREチームの監視タスクが+15%増
- 多要素認証: 自由にカスタマイズ可能
- リスク: 移行期間中のセッション不整合
当社では Nygard 形式に Date と Decider の 2 フィールドだけ追加して運用しています。これ以上拡張すると書く心理的コストが上がり、結局誰も書かなくなります。
柱③ レビュー文化（暗黙知の引き出し装置として）
コードレビューは「コードの是非を問う場」と捉えると暗黙知は出てきません。Google Engineering Practices Documentation のレビュー観点（Design / Functionality / Complexity / Tests / Naming / Comments / Style / Documentation / Every Line）を参考に、レビュー観点を 設計判断まで踏み込む よう設計します。
具体的には次の 3 つを徹底します。
- 「なぜこの設計か」を Description に書かせる: PR テンプレで Why / Alternatives / Trade-offs を必須化
- 設計レビューを実装前に分離する: 大きな PR は ADR を先に書いてレビューに通す
- AI レビューと人間レビューの役割を分離する: 静的解析・パターンチェックは AI、設計判断とドメイン知識は人間（詳細は AI時代のレビュー運用設計 を参照）
レビューは暗黙知が表出化される最大のチャンスです。コメント欄に残った設計の理由は、後から ADR や用語集にプロモートできます。
柱④ 文脈ファイル（Diátaxis × CLAUDE.md / AGENTS.md）
ドキュメントが「使われない」最大の理由は、何を読めばいいか分からないことです。Diátaxis Framework は 4 分類で整理を示します。
- Tutorials: 学習者向け、目的は学習
- How-to guides: 実務者向け、目的は問題解決
- Reference: 仕様書、目的は情報の正確な検索
- Explanation: 概念説明、目的は理解
この 4 分類で既存ドキュメントを棚卸しし、どこに何があるかを AGENTS.md のリンクから辿れるようにします。AI 時代の固有課題は、これに AI エージェント向けレイヤー が加わることです。
CLAUDE.md: Claude Code が毎セッション読む repo memory（短く保つ）AGENTS.md: Cursor / Codex 等の汎用エージェント向け SSoT.agents/rules/: オンデマンドで読む詳細ルール集docs/: 人間向けの深い知識skills/: 特定ワークフロー専用の手順書
CLAUDE.md を肥大化させないコツは CLAUDE.md最適化の本質と分離設計 で解説しました。「短く保ち、必要な時だけ skills へ逃がす」が公式推奨です。
AI 時代のナレッジ共有 — CLAUDE.md / AGENTS.md / コンテキストエンジニアリング
ここでは 動的な運用力学 を扱います。装置の定義は前章、本章は「人間と AI が同じ SSoT を読む状態をどう維持するか」です。
人間向けナレッジと AI 向けコンテキストを同じ SSoT で運用する
二重管理はかならず崩壊します。AGENTS.md と Notion に同じ内容を書けば、どちらかが古くなった瞬間、組織は信じる対象を失います。
当社の運用は次のシンプルなルールです。
- 正本はリポジトリの Markdown に置く（AGENTS.md /
.agents/rules// docs/） - Notion / Confluence は読み物のレイヤー（議事録・週報・採用情報）
- 両方に書きたくなったら、一方をリンクに置き換える
AI エージェントが読むのも人間が読むのも同じファイルです。これで「最新版はどれ？」問題が消えます。AI が迷わないリポジトリの作り方は AIが迷わないリポジトリ設計の作法 で詳述しました。
CLAUDE.md / AGENTS.md / .agents/rules/ の役割分担
Anthropic 公式仕様では、CLAUDE.md はプロジェクト単位・ユーザー単位・組織単位で置ける 持続的な指示の置き場 とされています。短く保ち、肥大化したら skills へ分散させるのが推奨です。
当社運用での役割分担は次の通りです。
| ファイル | 読まれるタイミング | 中身 | 推奨サイズ |
|---|---|---|---|
CLAUDE.md | 毎セッション自動 | プロジェクト概要・最重要ルール・参照先 | 100 行以下 |
AGENTS.md | エージェント横断 SSoT | 汎用エージェント向けプロジェクト規約 | 300 行以下 |
.agents/rules/*.md | オンデマンド | ドメイン別の詳細ルール | 各 100〜500 行 |
docs/ | 必要時参照 | 人間向け深堀り解説 | 制限なし |
.claude/skills/ | 必要時自動ロード | 専用ワークフロー | 制限なし |
階層化の詳細は Claude Codeのコンテキスト階層 を参照してください。
コンテキスト負債を返済するサイクル
ドキュメントは書いた瞬間から劣化します。劣化を放置するとコンテキスト負債が膨らみ、AI も人間も信じられなくなります。返済サイクルは次の 3 段階で固定します。
- 週次: 30 分の「ナレッジ棚卸し」。今週変わった意思決定を ADR に 1 本起こし、CLAUDE.md / AGENTS.md の参照先を更新する
- 四半期: ドキュメント全体の棚卸し。Diátaxis 4 分類で再分類し、古いものを
archived/に移動 - 半期: ナレッジ運用そのものの振り返り。「読まれていないドキュメント」を特定し、廃止か更新か判断
このサイクルを 組織カレンダーに固定 することが肝です。「気が向いたら」では絶対に回りません。
形式知化を回す運用テンプレート（実装手順）
ここからは how-to の中核です。明日から始められる 4 ステップで提示します。
ステップ① 暗黙知マップを描く
最初の一歩は「誰が何を持っているか」の可視化です。30 分のワークショップで、メンバー全員に次のテンプレを埋めてもらいます。
## 私が抱えている暗黙知
### 自分しか知らないこと（自分が休むと止まる領域）
- 〇〇の本番環境デプロイ手順
- ××の認証フローの例外パターン
- △△ベンダーとの過去のやり取り経緯
### ドキュメント化できそうなもの（次の四半期で書く候補）
- 上記のうち、ADR 化 / How-to 化 / Reference 化に分類
### ペアにすれば共有できるもの（OJT 候補）
- 共同化（Socialization）で渡したい暗黙知
このマップを集約すると、組織として塞ぐべき柱が見えてきます。例えば「ADR が誰も書いていない」なら柱②から、「オンボーディング資料がない」なら柱①から着手します。
ステップ② SSoT を 1 箇所決める
「どこに何を書くか」を決めずに装置を作ると、Slack / Notion / GitHub に情報が散在し、どれが正本か分からなくなります。先に SSoT を 1 本決めます。
- 開発組織なら リポジトリの
AGENTS.mdが最有力（コードと一緒に PR で更新できる） - 非開発職を含む組織なら Notion / Confluence のトップページに 「正本はどこか」の一覧表 を置く
- 議事録・週報など揮発性の高いものは Notion、永続性の高いもの（設計判断・ルール）はリポジトリ、で分ける
このルールを AGENTS.md の冒頭に明記しておくと、新メンバーも迷いません。
ステップ③ 4 装置に落とす
SSoT が決まったら、4 本柱を順に立ち上げます。一度に全部やる必要はありません。塞ぎたい穴の優先順位で 1 つずつ整えます。
| 優先度の決め方 | 着手すべき柱 |
|---|---|
| 採用が増えている／離職が続いている | 柱① オンボーディング |
| 設計判断の蒸し返しが多い | 柱② Decision Log |
| レビューが「コードの是非」で止まっている | 柱③ レビュー文化 |
| AI コーディング支援の精度が出ない | 柱④ 文脈ファイル |
最初の柱が回り始めるのに 1〜2 か月、4 本すべてが揃うのに 6〜9 か月が現実的な見積もりです。
ステップ④ 更新サイクルをカレンダーに固定
装置は作って終わりではありません。前章で示した「週次30分・四半期棚卸し・半期見直し」を組織カレンダーに固定します。
- 月曜朝 30 分の「ナレッジ棚卸し会」を全員参加に
- 四半期末の最終週を「ドキュメント整備週間」に
- 半期に 1 度、ナレッジ運用 KPI（更新件数 / 参照頻度 / レビュー時の引用率）をレビュー
このサイクルが回り始めると、ドキュメントは「書いて終わり」から「使われて育つ資産」に変わります。
ナレッジ運用テンプレ（CLAUDE.md / AGENTS.md / Decision Log / オンボーディング雛形）を一括配布中です。記事末尾のリンクからダウンロードください。
失敗パターンと回避策
失敗① ドキュメントを書く時間を評価しない
ドキュメント整備を「業務外の善行」扱いすると、誰もやりません。回避策は 評価制度に組み込むこと です。半期評価の項目に「ドキュメント整備への貢献」を 1 行追加するだけで、行動は変わります。具体性を持たせるなら「ADR 月 1 本」「四半期で読まれていないドキュメントを 1 本廃止」などの行動目標に落とします。
失敗② SSoT を複数持つ
「Notion にも Confluence にもリポジトリにも同じ内容がある」状態は、必ず崩壊します。回避策はステップ②の通り、1 本化と一覧表です。複数ツールを使う場合でも、「永続性の高いものはここ、揮発性の高いものはここ」のルールを AGENTS.md 冒頭に明記します。
失敗③ AI に丸投げしてコンテキストを渡さない
最後の失敗が最も多いです。Claude Code や Cursor を導入したのに、CLAUDE.md / AGENTS.md が空のまま使い始める組織が驚くほど多い。これは AI ペアプロの典型的な落とし穴で、AIペアプロでよくある失敗 でも整理しました。
回避策は CLAUDE.md の整備を最優先 にすることです。完璧でなくていい。プロジェクトの目的・主要ファイル・禁止事項を 50 行で書けば、AI の精度は劇的に上がります。書きながら気付いた暗黙知が、そのまま組織のドキュメントになります。
当社の運用例（一次情報）
AGENTS.md / .agents/rules/ のディレクトリ構造抜粋
当社で運用しているリポジトリ構造の一部を抜粋します。
.
├── CLAUDE.md # 毎セッション読む repo memory（80 行）
├── AGENTS.md # エージェント横断 SSoT（250 行）
├── .agents/
│ ├── rules/
│ │ ├── article-writing.md # 記事執筆ルール
│ │ ├── code-review.md # レビュー観点
│ │ ├── decision-log.md # ADR 運用
│ │ └── onboarding.md # オンボーディング手順
│ ├── steering/
│ │ ├── product.md # プロダクトの Why
│ │ ├── tech.md # 技術選定の理由
│ │ └── structure.md # ディレクトリ設計の意図
│ └── skills/ # 専用ワークフロー
└── docs/
└── adr/ # Decision Log 本体
CLAUDE.md から AGENTS.md へ、AGENTS.md から .agents/rules/ へ、必要に応じて辿れる階層構造になっています。
週次「ナレッジ棚卸し30分」運用
毎週月曜の朝、30 分だけ全員集合して次の流れで進めます。
- 先週変わった意思決定の共有（5 分 × 1〜2 件）
- ADR を起こすべきものを特定（その場で誰が書くか決める）
- CLAUDE.md / AGENTS.md の更新箇所を即時反映（PR を会議中に出す）
- 「読まれていないドキュメント」候補の議論（5 分）
ポイントは 会議中に PR を出す ことです。「あとでやります」が一番危険です。
Decision Log の Nygard 形式テンプレ
当社で実運用している ADR テンプレ全文です。コピーして docs/adr/ に置けば即運用できます。
# ADR-XXXX: 〇〇についての意思決定
- Status: Proposed | Accepted | Deprecated | Superseded by ADR-YYYY
- Date: YYYY-MM-DD
- Decider: @username, @username
## Context
なぜこの判断が必要になったか。背景・制約・前提を 3〜5 行で。
## Decision
何を決めたか。1 文で。
## Consequences
- ポジティブな結果（コスト削減、速度向上など）
- ネガティブな結果（運用負荷、リスクなど）
- フォローアップが必要な事項
これ以上の拡張は書く心理的コストを上げるだけなので推奨しません。
よくある質問
暗黙知と形式知の違いは何ですか？
暗黙知は「言語化されていない、個人の経験や勘に依存する知識」、形式知は「文書・図表・コードとして誰でも参照できる形になった知識」です。野中郁次郎の SECI モデルでは、両者の変換プロセスを 4 段階（共同化／表出化／連結化／内面化）で捉えます。
属人化を防ぐにはどうすればいいですか？
「個人にドキュメントを書かせる」ではなく 組織装置を整える のが近道です。本記事の 4 本柱（オンボーディング／Decision Log／レビュー／文脈ファイル）を順に立ち上げ、評価制度にドキュメント貢献を組み込むのが定石です。
ドキュメント文化を根付かせるには何が必要ですか？
3 つの条件があります。① 書いた人を評価する制度、② 使われる場所（SSoT）への一本化、③ 更新サイクルのカレンダー固定。3 つそろわないと、ドキュメントは書かれず、書かれても更新されず、更新されても読まれません。
ADR とは何ですか？
Architecture Decision Record の略で、Michael Nygard が 2011 年に提示した意思決定の記録形式です。Title / Status / Context / Decision / Consequences の 5 項目で構成され、「なぜその設計にしたか」を半年後の自分や新メンバーに伝えるための装置として機能します。
CLAUDE.md と AGENTS.md の違いは何ですか？
CLAUDE.md は Anthropic Claude Code 専用の repo memory（毎セッション自動読込）、AGENTS.md は Cursor / Codex / Aider など汎用エージェントが参照する SSoT です。当社では CLAUDE.md を短く保ち（100 行以下）、詳細ルールは AGENTS.md と .agents/rules/ に分離しています。
SECI モデルの 4 プロセスとは？
共同化 (Socialization, 暗黙知 → 暗黙知)、表出化 (Externalization, 暗黙知 → 形式知)、連結化 (Combination, 形式知 → 形式知)、内面化 (Internalization, 形式知 → 暗黙知)の 4 つです。組織のナレッジ循環をこの 4 プロセスで設計するのが、知識創造企業のフレームワークです。
AI 時代のナレッジ共有で何が変わりましたか？
人間向けと AI 向けの両方を 同じ SSoT で運用する必要が生まれました。リポジトリ内の AGENTS.md / CLAUDE.md / .agents/rules/ を整備し、人間が読むのも AI が読むのも同じ Markdown にする設計が主流です。二重管理は崩壊するため、Notion / Confluence と並走させるのは避けます。
まとめ — 自社診断10項目と次の一歩
自社診断10項目チェックリスト
次の 10 項目で、いま暗黙知が漏れている柱を特定してください。4 つ以上当てはまったら、組織装置の整備を急ぐサインです。
- 特定メンバーが 1 週間休むと止まる領域がある
- オンボーディング資料が「読むべき順序」で並んでいない
- 設計判断の理由（ADR）が残っていない
- レビューコメントが「個人の好み」で揺れる
- SSoT が複数あり、最新版がどれか分からない
- ドキュメントを書く時間が評価制度に組み込まれていない
- AI コーディング支援に渡すコンテキスト（CLAUDE.md / AGENTS.md）がない
- 用語集（Glossary）が整備されていない
- 週次・四半期のナレッジ棚卸しサイクルがない
- 暗黙知マップ（誰が何を持っているか）を可視化していない
30/60/90 日で立ち上げる順序
最初の 90 日で立ち上げる現実的な順序は次の通りです。
- 30 日目まで: 暗黙知マップ（ステップ①）と SSoT 一本化（ステップ②）
- 60 日目まで: 4 本柱のうち優先度の高い 1 本（ステップ③）
- 90 日目まで: 更新サイクルの組織カレンダー固定（ステップ④）
残りの 3 本は四半期ごとに 1 本ずつ立ち上げ、半年〜9 か月で 4 本柱が揃う想定です。
ナレッジ運用テンプレ DL → 相談導線
本記事で紹介した 4 本柱をすぐ自社で立ち上げられるよう、次のテンプレ一式を配布しています。
CLAUDE.md/AGENTS.mdの最小構成テンプレ- ADR (Nygard 形式) テンプレ
- オンボーディング 30/60/90 日チェックリスト
- 週次ナレッジ棚卸し30分のアジェンダ
「自社の暗黙知運用、どこから手を付けるべきか」を一緒に整理する組織設計レビューも提供しています。診断 10 項目の結果を持ってお問い合わせください。30 分の壁打ちから始められます。
暗黙知は個人の問題ではありません。組織設計で塞げます。
