社内ナレッジ蓄積の仕組み｜拾う基準と承認・昇格の3段

「あとで見返せるように残しておいて」。そう言われて保存した成果物を、あとから本当に開いた記憶は、どれくらいあるでしょうか。

多くの現場で、社内ナレッジの蓄積は「置き場所を決める」ところで止まります。共有フォルダを作り、命名の決まりを揃え、そこへ入れる。ところが半年後、そのフォルダは検索されず、同じ判断が毎回ゼロからやり直されています。

足りないのは置き場所ではありません。何を候補として拾い、誰が承認し、どこへ昇格させるか。この手続きのほうです。この記事では、その3段それぞれの判断基準と、仕組みが形だけにならないための運用を整理します。素材は運営元WEBMARKSの内部設計と、外部の知識管理手法・公式ドキュメントです。

進行役は3人です。若葉さんが言葉の側から聞き、大森部長が体制と責任の側から聞き、鈴木さん（本誌監修）が答えます。

01社内ナレッジの蓄積の仕組みは、AIエージェントを入れる前に何を決めるんですか？

若葉さん

若葉さんの発言

ナレッジを蓄積する仕組みって、結局は保存先を決めることじゃないんですか。

鈴木さん

鈴木さんの発言

倉庫を建てるところまでは同じだと思っています。ただ、建てただけで、何を入れて誰が鍵を持つかを決めていないと、そこはいつのまにか物置になります。

社内ナレッジを蓄積する仕組みとは、成果物から型だけを取り出し、承認を経て正式なナレッジへ置き換える3段の手順です。

• 候補抽出：成果物の中から「次に同じ判断をするとき役立つ部分」だけを蒸留します
• 承認ゲート：抽出した本人以外の判断を経由させます
• 昇格の実行：承認済みの候補だけを、機械的な検証つきでナレッジ置き場へ移します

3段のどこか1つが欠けると、仕組みは壊れます。壊れ方はそれぞれ違います。

候補抽出だけで止まれば、成果物フォルダが肥大化するだけの物置になります。承認を飛ばせば、書いた本人の主観がそのままナレッジと呼ばれてしまいます。機械的な検証なしに昇格させれば、写し間違いや重複が正本を汚します。

Knowledge-Centered Service（KCS。顧客対応の現場で育った知識管理の手法）も、近い発想を採ります。KCSは、ナレッジの再利用・改善・作成を、日々の業務の一部として組み込む考え方です（出典: Consortium for Service Innovation公式）。裏を返せば、候補抽出を「別枠の仕事」にした時点で、最初の分かれ道を間違えているということです。

置き場所そのものの設計、つまり階層・原本・機密分離の考え方は、ObsidianをAIエージェントの知識基盤にする3つの設計で扱っています。本記事はその土台の上で、成果物をナレッジへ変える手続きの部分に絞ります。

02成果物と社内ナレッジは、AIエージェントから見ると何がどう違うんですか？

成果物とナレッジは、見た目が似ていても別物です。成果物は「その案件のために作ったもの」で、ナレッジは「次の別の案件でも判断を変えるもの」です。同じ文書でも、この2つを混ぜると、フォルダに入れた時点で満足してしまいます。

AIエージェントに作業を任せると、この境界はいっそう曖昧になります。出てくる文書の見た目が揃っているぶん、どれも同じ重さに見えてしまうためです。分けるのは書式ではなく、次に開かれる理由のほうです。

並べてみると、分ける線が分量ではないことが分かります。読み手が誰か、そしていつ開かれるか。この2つが違えば、同じくらいの長さの文書でも行き先は変わります。

長く書けば読まれるものになる、という順番にはなりません。ここを取り違えると、要約を厚くする作業に時間が流れていきます。

03何を社内ナレッジの候補として拾えばいいか、AI社員に渡す前にどう判断するんですか？

候補抽出でいちばん多い失敗は、成果物をそのまま候補にしてしまうことです。判断は、次の条件のどれかに当てはまるかどうかで決めます。

1. 適用範囲：この型がどんな条件で使えるか
2. 判断基準：似た場面で何を根拠に選んだか
3. 前提：この型が成立する環境や制約
4. NG例：やってはいけない具体的な失敗パターン

どれにも当たらない場合は、候補として拾いません。逆に、このうち1つでも明確に書ければ、候補として成立します。分量の多さでは判定しません。

順番にすると、判定が二段になっていることが分かります。先に効くのは「そもそも対象外か」で、条件を見るのはそのあとです。ここを逆にすると、機密や正本のコピーが条件審査へ流れ込みます。

抽出の時点では、この判定は本人の自己申告で構いません。本人以外の目が入るのは、次に説明する承認ゲートからです。

KCSでは、記事は最初から完璧である必要がなく、再利用される中で磨かれるという考え方を採ります。「Reuse is Review」という技法名がそれに当たります（出典: KCS公式）。候補の時点で完成度を求めすぎないことが、抽出そのものを止めない工夫です。

04拾わないものを決めないと、AI導入のあと社内ナレッジはどうなるんですか？

拾うものと同じくらい、拾わないものを先に決めておきます。決めていないと、昇格先が二重管理の置き場になり、機密がにじみ、記録と型が混ざります。

4つに共通しているのは、置き場所を間違えると別の管理が始まってしまう、という点です。正本の写しは更新のたびに食い違い、機密は消し忘れが残り、記録は型のふりをして棚に並びます。

先に決めておく効果は、判断が速くなることだけではありません。拾わなかったものにも、それぞれ行き先が用意されている状態になります。捨てるのではなく、別の棚へ置くという運用です。

05AIエージェントが自分で覚える仕組みは、社内ナレッジの昇格とどこが違うんですか？

若葉さん

若葉さんの発言

AIが自分で覚えてくれる機能もありますよね。あれをそのまま社内のナレッジにしてはいけないんですか。

鈴木さん

鈴木さんの発言

便利ですし、うちでも使っています。ただ、覚えるかどうかをAIが自分で決めている点が違います。社内の型として認めるところだけは、人の側に残しています。

Claude Codeにも、似た判断の仕組みがあります。セッションをまたいで知識を持ち越すauto memoryは、Claude自身が判断してから保存します。次のセッションで役立つかどうかが基準です（出典: Claude Code公式ドキュメント）。

すべてのセッションで何かを保存するわけではありません。保存先のMEMORY.mdも、先頭200行または25KBのどちらか早い方までしか毎回読み込まれません（出典: Claude Code公式ドキュメント）。

読み込まれる範囲に上限があるということは、置き場所を広く取っても、実際に効くのは先頭の一部だけだということです。拾わないものを決める作業は、その限られた枠を何で埋めるかを決める作業でもあります。

ただし、決定的な違いが1つあります。auto memoryの判断はAI自身の一存で完結し、人が確認する前提を持ちません。社内ナレッジへの昇格は、その一存判断のあとに、人の承認を挟む設計にします。理由は次の章で扱います。

06社内ナレッジの仕組みでは、承認は誰が下すんですか？AIエージェント自身に任せてもいいんですか？

大森部長

大森部長の発言

承認までAIが下せるなら、そのぶん速くなります。任せてはいけない理由はありますか。

鈴木さん

鈴木さんの発言

速くはなります。ただ、あとで「誰が決めたのか」を説明できなくなります。承認は作業ではなく、責任の置き場所を決める行為なので、そこだけは分けています。

大森部長

大森部長の発言

例外はまったく無いのですか。

鈴木さん

鈴木さんの発言

社内の格上げのように、対外的に確定しない範囲だけは、案件ごとに預けることがあります。それも、範囲と終わりの日をセットで書いたときだけです。

運営元WEBMARKSの内部ルールは、承認者の資格そのものを制限しています。原則として、AI自身の名前を承認者として記録できません。この線引きの詳しい設計はAIエージェントの承認ゲート｜止める操作4種と3層の選び方で扱っています。

もう1つ、承認と呼ばないものがあります。「対象を明示した依頼」だけが承認として扱われ、「候補を見せて」のような曖昧な依頼や、自動フックの起動は承認に数えません。

並べると、承認と呼びたくなる場面のいくつかが、実は承認ではないことが分かります。共通しているのは、対象が名指しされていないか、判断した人がいないかのどちらかです。

Google SREのポストモーテム運用にも、近い発想があります。ある事故の記録は、同じチームだけでなく他チームも交えたレビューを経ます（出典: Google SRE Workbook）。書いた人以外の目を通すという一点は、業種を問わず共通の設計判断です。

07委任で承認するときは、AI社員の仕組みに何を書き残すんですか？

承認の経路は、直接と委任の2つです。

直接承認は単純で、承認者・承認日時・承認の根拠（発言そのものか証跡へのパス）を記録します。委任で承認する場合は、次の条件がすべて揃っている必要があります。

1. 権限を移譲したのが人間であり、その記録が残っていること
2. 委任を受けた側が明示されていること
3. 委任の範囲に「知識の昇格」が含まれていること
4. 案件が完了した時点で、その委任が自動的に無効になること

公開・外部送信・契約・決済は、委任の対象に含まれません。委任で認められるのは、社内での格上げなど、対外的に確定しない範囲だけです。

図の左右で違うのは、対象の範囲だけではありません。終わりの日があるかどうかも違います。預けたぶんには切れる日がありますが、人しか下せない側には預けるという枠自体がないので、期限を書く欄も存在しません。

表の3行目にも触れておきます。「承認なし」は失敗ではなく、既定の状態です。誰も判断していないというだけで、候補はそこに残り続けます。壊れるのは、判断がないまま昇格先へ書き込まれたときです。

08案件・成果物・社内ナレッジの3本を、AIエージェントの運用ではなぜ分けるんですか？

昇格が終わっても、案件全体が終わったとは限りません。逆に、案件が人間の判断待ちで止まっていても、ナレッジの昇格だけは先に進められる場合があります。この2つを同じ「完了」に潰すと、どちらかの情報が消えます。

だから、状態は3本の軸で別々に持ちます。

宣言する場所は、案件フォルダの直下に置く_MANIFEST.mdという1ファイルです。案件ID・所有部署・承認の記録・3本の軸の現在値を、ここにまとめて持たせます。ナレッジの軸だけを取り出すと、次のように書かれている状態が正常です。

"knowledge": {
  "status": "candidate",
  "approved_by": null,
  "approved_at": null,
  "promoted_at": null
}

3本は独立して動きます。成果物がすでに社内正式採用へ進んでいても、ナレッジの軸は候補のまま止まっていることがあります。逆に、案件は人間の判断待ちでも、その中の成果物だけが先に社内採用されることもあります。ファイルの更新日時や連番からは、どの軸がどこまで進んだかを判断しません。

別々の物差しを並べる発想は、Google SREの運用にも見られます。障害対応では、月あたりの発生件数・検知にかかった時間・解決にかかった時間・影響範囲という複数の指標を並べて追跡します（出典: Google SRE Workbook）。1つの合否で語らない、という考え方です。

09社内ナレッジの蓄積の仕組みが形だけになるのは、AI活用の何が抜けたときですか？

大森部長

大森部長の発言

ここまでの設計は分かりました。ただ、作っただけで回らなくなる例も見てきました。

鈴木さん

鈴木さんの発言

うちも一度壊しています。成果物ができるたびに「正式なナレッジに格上げしますか、それとも途中経過のままにしますか」と毎回尋ねる方式でした。

大森部長

大森部長の発言

丁寧に見えますが、何が起きたのですか。

鈴木さん

鈴木さんの発言

更新時刻だけを根拠に「成果物ができた」と判定していたので、無関係な別案件の生成物を拾って、作業中の文脈を乗っ取りました。根拠を当てにならない値に置いていたのが原因です。

対策は、質問そのものをやめることでした。今の設計は、明示的な承認証跡が無い限り、既定で「候補のまま」を選び、毎回は尋ねません。承認は、対象を明示した依頼か、有効な委任のどちらかでしか成立しません。

前後で入れ替わったのは、丁寧さではありません。判定の根拠のほうです。尋ねる回数が減ったのではなく、尋ねる理由が消えました。

形骸化を防ぐ仕掛けは、ほかに3つあります。

1. 昇格マーカーの必須化：昇格した先には、出典・昇格日・承認者を書いた行を先頭に置きます。この行がない追記は、昇格として数えません
2. 「承認: 未」を無効票にする：承認者の欄が空欄や未記入のままの昇格は、正式なものとして数えません
3. 測る対象を絞る：定期点検のスクリプトは、ファイルの更新時刻や本数を見ません。案件IDに紐づいた承認証跡だけを数えます

10昇格の仕組みを生成AIごと点検するには、何を数えればいいんですか？

点検で何を数えるかは、設計そのものと同じくらい結果を左右します。

Google SREも、ポストモーテムの改善アクションを追跡から漏らさないための仕組みを持っています。対応項目を専用のバグ管理システムに登録し、消化状況を追跡します（出典: Google SRE Workbook）。「言うだけで終わる」運用を防ぐ具体策は、宣言と実際の状態を機械的に突き合わせることです。

KCSも、日々の実践（Solve Loop）と定期点検（Evolve Loop）を分けて定義しています（出典: KCS公式）。前者は成果の即時再利用、後者は仕組み自体の健全性チェックが役割です。日々の実践だけでは仕組みは維持できず、点検の循環が別に要るという構造です。

定期点検は週次で回す設計です。案件・成果物・ナレッジの3本が実際につながっているかを、証跡だけを根拠に確認します。つながりが崩れていれば、決裁が必要な項目として一覧に上がります。

候補のまま止まっている状態は、失敗ではありません。ただし、止まったままの件数を誰も見ていなければ、昇格は起きないままになります。既定の終わり方として許すことと、見ないことは別です。

11AIエージェントに社内ナレッジを任せるとき、つまずくのはどこですか？

1つ目は、承認の章で扱った自己承認です。抽出者と承認者が同じだと、ゲートを作った意味そのものが消えます。この資格制限はAI社員の組織設計｜部署より先に決める3点と確かめ方が扱う組織設計にも組み込まれています。

2つ目は、候補が既定の終わり方として扱われることの副作用です。止まってよいことと、止まったまま誰も見ないことは違います。

3つ目は、機械検証を迂回する近道です。昇格先にすでにファイルがある場合、手作業での上書きは事故のもとになります。適用に失敗したときは、生成物を削除せず専用の退避場所へ移す設計にしておくと、やり直しが安全になります。

12社内ナレッジの蓄積の仕組みが守れているかは、AIエージェントの運用中に何で確かめますか？

設計と運用のあいだにずれが出ていないかは、案件が終わるたびに手元で見ます。見る対象は、成果物の出来ではなく、手続きが1段ずつ踏まれたかどうかです。

どれか1つでも空欄のまま次の案件へ進むと、その空欄は次も空欄のままになります。埋まらない項目が続くようなら、運用が悪いのではなく、欄の置き場所が実際の作業から遠すぎることを疑ってください。

13よくある質問

14まとめ｜今日やる3つのこと

蓄積の仕組みは、置き場所ではなく手続きでした。承認は速度の話ではなく、責任の置き場所を決める行為でした。そして候補のまま止まることは、失敗ではなく既定の終わり方です。