SharePoint の「プロンプト集」フォルダを開く。
最終更新日は 8 ヶ月前。投稿者の名前は、すでに別の部署に異動している。
「使えるかもしれない」とクリックしたプロンプトの説明文には、退役済みのモデル名が書いてあった。
Teams のチャットを立ち上げて、「誰かこの業務で使えるプロンプト持ってませんか」と打つ。
こういう経験が、1 度や 2 度ではない人は多いはずだ。
1. 3 年分の蓄積が、なぜ一晩で使えなくなるのか
具体的な場面を想像してほしい。
あなたのチームが、3 年かけてプロンプトを積み上げたとする。毎月の定例でメンバーが持ち寄り、担当者が週 2 時間を費やして整理した。200 件に達したとき、「ナレッジ資産」として経営報告に記載された。
2026 年 2 月、OpenAI が GPT-4o の退役を発表した。リリースからわずか 21 ヶ月だった（OpenAI 公式）。
GPT-4o 特有の挙動——長めのシステムプロンプトで安定する、特定の言い回しで精度が上がる——に最適化されたプロンプトは、次世代モデルで同じように動かない。GPT-4.1 は GPT-4o より「指示に文字通り忠実に従う」設計に変わったため、同じプロンプトでも挙動が変わることが OpenAI のプロンプトガイドに明記されている。200 件のうち何件が影響を受けるか。1 件の再テストに 30 分かかるとすれば、100 件で 50 時間だ。これが 1 回のモデル交代で発生する。
もし最初から「動作確認日」と「対象モデル」の 2 列をテンプレートに設けていたなら、どうなっていたか。
モデル更新のたびに「この日付より前・このモデル向けのプロンプト」として絞り込める。全件再テストの代わりに、影響範囲の特定から始められる。「GPT-4o の退役が出た。確認が必要な候補は 18 件」——そう絞り込める設計になっていれば、50 時間が 9 時間になっていた。差の 41 時間で、チームは次の業務自動化に着手できていた可能性がある。
「ポータルがある組織」と「ポータルが機能している組織」の差は、設計前の一手で生まれる。
2. ナレッジが腐る構造は、AI に限った話ではない
AI ポータルの形骸化は AI 固有の問題に見えるが、ナレッジ管理全般の失敗パターンと重なる部分が大きい。
ナレッジ管理施策の 55% は変革管理の不足や経営層のサポート不足で失敗する（Helpjuice「Knowledge Management Trends and Statistics in 2025」2024-25 年）。能動的な管理がなければ、ナレッジベースの 20〜40% は無関連・陳腐化コンテンツを含むようになる（同調査）。デジタルワーカーの **47% が「業務上必要な情報を見つけるのが困難」**と感じる（Gartner 2023 年調査、二次引用）という実態は、「溜まってはいるが使えない」状態が広く常態化していることを示す。
AI ポータルにはさらに固有の問題がある。モデルが変わるたびに、「動く」から「動かない」へ静かに移行するコンテンツが発生する。ライブラリの量は増えても、実際に動作するプロンプトの率は下がる。利用者は「古いかもしれない」という不安を持ち始め、アクセスが減る。アクセスが減ると投稿も減り、陳腐化がさらに進む。
日本企業固有のデータも絡む。野村総合研究所の 2025 年調査（517 社の CIO 対象）によると、生成 AI を導入済みの企業は 57.7% に達したが、課題の 1 位は「リテラシー・スキル不足（70.3%）」だ（NRI 2025 年 11 月）。導入したが使いこなせていない——その一因として、ポータルが「どう使うかを教える場所」として機能していないことが考えられる。
3. 「そもそも、なぜプロンプト集は放置されるのか」
答えを出す前に、問いを一度分解する必要がある。
プロンプト・エージェント定義は、賞味期限の異なる 4 層で構成されている。
①モデル依存テクニック層（最短寿命）
「このモデルでは長めのシステムプロンプトが安定する」「役割を与えるとハルシネーションが減る」——こうしたテクニックはモデルのアーキテクチャに依存する。モデルが変わると挙動が変わる。GPT 系統は 2023 年 3 月から 2025 年 8 月の約 29 ヶ月で 8 回の主要更新（平均約 3.6 ヶ月ごと）、Claude 系統は同期間に 7 回の主要更新（平均約 3.4 ヶ月ごと）を記録している（Wikipedia「GPT-4」 / Wikipedia「Claude」 より）。この更新サイクルと連動して腐る層だ。
②業務×AI の接続部（最長寿命）
「この業務では AI にどういう役割を与えると判断精度が上がるか」「業務特有のコンテキストをどう渡すか」——これは業務プロセスそのものと同寿命だ。モデルが変わっても業務の構造が変わらなければ価値が残る。ここだけが長期蓄積に値する層といえる。
③実装物（中間寿命）
エージェント定義・スクリプト・カスタムアプリとして実装されたプロンプト。バージョン管理で変更履歴を追跡できるため①より長命だが、モデル更新で定期的な見直しが必要になる。
④ガイドライン・ルール文書（比較的長寿命）
AI の利用区分・倫理指針・情報区分の扱い——モデルに依存しない。ただし AI 活用の実態が変われば見直しが必要だ。
ほとんどのポータルが犯している設計ミスは、4 層を同じ器・同じメタデータで収容することだ。「3 ヶ月で腐るコンテンツ」と「3 年持つコンテンツ」を同じ棚に並べると、①が腐ったとき、ポータル全体への信頼が失われる。「あそこのプロンプトは古いから使えない」という評価が定着すると、④のような長命なコンテンツまで参照されなくなる。
腐るのは設計が悪いのではなく、腐り方が違う素材を同列に扱ったからだ。
4. 「では、「図書館型」と「市場型」は何が違うのか」
設計思想の差を、2 つのモデルで整理する。
| 観点 | 図書館型（蓄積重視） | 市場型（回転重視） |
|---|---|---|
| 成功 KPI | 投稿件数・蓄積数 | 活用率・鮮度スコア・棚卸し完了率 |
| メタデータ | タイトル・カテゴリ | 対象モデル・動作確認日・業務カテゴリ |
| 更新の扱い | 追加が価値。削除は「失う」 | 廃版・アーカイブが正常なサイクル |
| 失敗の可視化 | アクセス数減少（気づくのが遅い） | 鮮度スコア低下（設計上早期に検出） |
| 1 年後の姿 | 件数は多いが利用されていない | 件数は少ないが実際に使われている |
図書館型の問題は、「蓄積数 500 件」という目標が達成された時点で、担当者の達成感と実際の利用率の乖離に気づかない構造にある。
Copilot Prompt Gallery の動きが示唆的だ。Microsoft は 2026 年 5 月、チーム共有プロンプトライブラリ機能を公式提供した際、「四半期ごとのキュレーション」を推奨している（Gethyn Ellis「Copilot Prompt Gallery」2026 年 5 月）。大手プラットフォームが自社製品の利用指針として鮮度管理を前提に置いたことは、「蓄積したら終わり」という設計思想への疑義を公式が認めた形として読める。
また、重要なパイプラインを持つ組織でのモデル移行ペースは、かつての年 1 回から四半期 1 回に変化しつつある（remio.ai 2026 年調査）。市場型への転換は、選好の問題ではなくモデルの更新速度が迫る構造的な要請になってきている。
5. 「腐らせながら、何を蒸留するのか」
市場型の設計思想は「腐る層を回転させること」だが、それだけでは半分だ。腐る層を回転させる過程で、腐らない資産を蒸留することがポータルの本来の役割になる。
腐らない資産は 3 つに整理できる。
①業務の型
「この業務では AI にどんな指示を与えると質が上がるか」という判断パターン。モデルが変わっても業務の構造が変わらなければ価値は持続する。「要約依頼の前提情報として何を渡すか」「査定コメントの生成で何を禁止するか」といった判断ルールがこれに当たる。
②診断の判断眼
「このプロンプトがなぜ動くのか・なぜ動かないのか」を見分ける能力だ。パーソル総合研究所の 2025 年 10 月調査によると、生成 AI を業務利用する人の **49.7% が「欲しい回答を得るために指示を何度も出し直すことがある」**と回答している（パーソル総合研究所「生成 AI とはたらき方に関する実態調査」）。この「出し直し」の原因を分析し、改善パターンとして記録することが診断の判断眼の蒸留につながる。蒸留が進むほど、この非効率は減る。
③未充足需要データ
「ポータルを検索しても見つからない問いの記録」だ。「このプロンプトが欲しいが存在しない」という未充足な需要は、次の投稿テーマの優先順位を決める材料になる。検索ログやリクエスト一覧として収集すれば、「何が足りないか」が KPI として機能するようになる。
パーソル調査では、組織課題の 1 位として「AI の教育・サポートが正式な業務や評価に位置づけられていない（32.5%）」が挙がっている。業務の型・診断の判断眼が組織的に蒸留されない根本原因のひとつは、「蒸留する仕組みが設計されていない」ことにある。投稿数を追っていると、この蒸留は自然には起きない。
6. ナレッジポータルが「蓄積数 KPI」から離れられない構造
整合性を欠くのは、ナレッジ管理施策の 55% が失敗すると知りながら、多くの組織が同じ設計を繰り返すことだ。
背景の一つは、測定コストにある。「投稿が 500 件ある」は数えられる。「活用率が 30% ある」は測定の仕組みを設計しなければわからない。限られた予算とスケジュールの中で、測りやすい指標が選ばれるのは合理的な判断の産物だ。
しかし、その選択が 1 年後に「使われていない」という結果を生む。測りやすさを優先した設計が、最終的に測定値そのものを無意味にする。
日本固有の実態も加わる。総務省「令和 7 年版情報通信白書」（2025 年 7 月）によると、生成 AI を「活用する」方針の日本企業は 49.7% だが、米国は 84.8%、中国は 92.8% に達している（総務省白書）。この差は評価軸設計の問題だけでなく、リスク管理・規制対応・文化的要因も含む複合的な背景を持つ。単一要因には還元できないが、「どう活用するかの設計思想を持つ組織の比率」が構造的に開いている可能性は、白書のデータからも読み取れる。
SharePoint の採用率は前年比 15% 超増加した（2024 年）にもかかわらず、「検索精度の低さ・低採用率・価値喪失」が課題として継続している（mrsharepoint.com 2025 年統計）。ツールの導入と設計思想の刷新は、別の問題だ。
見過ごされているのは、「蓄積数 KPI」を設定した時点で、ポータルの失敗軌道が確定するという構造だ。KPI は行動を設計する。投稿数を追えば投稿は増えるが、利用は設計されない。評価軸を設計前に合意することがポータル設計の核心であり、この合意が後手に回ると、ポータルは開設と同時に形骸化への道を歩み始める。
7. 4 層の賞味期限と設計指針——試算として
4 層の賞味期限と推奨設計をまとめる。
これは公的統計ではなく、モデル更新サイクルの実績値と業務プロセス管理の実例から導いた目安だ。業種・組織のモデル依存度・業務変更頻度によって大きく変動する。自組織の実態と照合して調整してほしい。
| 層 | 代表的なコンテンツ | 目安寿命 | 設計指針 |
|---|---|---|---|
| ①モデル依存テクニック | 「〇〇モデルではこう書く」「効くフレーズ集」 | 3〜6 ヶ月 | 賞味期限表示必須・自動アーカイブ設計 |
| ②業務×AI 接続部 | 業務別入力フォーマット・役割設定・業務コンテキスト | 業務プロセスと同寿命 | 積極的に蓄積・バージョン管理推奨 |
| ③実装物 | エージェント定義・スクリプト・カスタムアプリ | 6〜18 ヶ月 | Git 管理・変更ログ付き |
| ④ガイドライン | AI ルール・倫理指針・利用区分 | 1〜3 年 | 定期レビュー（半年〜年 1 回） |
①層の「3〜6 ヶ月」の根拠は、前述の GPT 系統・Claude 系統のリリース実績（平均 3.4〜3.6 ヶ月ごと）だ。②層が「業務プロセスと同寿命」という主張については直接統計はなく論理的推論であることを明記する。業種・組織によって業務プロセスの変更頻度は大きく異なる。
8. 選択肢
ポータルの現状と設計意図によって、取れる行動は 3 つに整理できる。
選択肢 A：今すぐ始める——テンプレートに 2 列を加える
既存のポータルの投稿テンプレートに「対象モデル（例：GPT-4o / Claude 3.5 Sonnet）」と「動作確認日（例：2026-03-15）」の 2 列を追加する。
これでモデル更新時に「確認が必要なコンテンツ」を絞り込める。最小のコストで鮮度管理を開始できる最初の一手だ。
ただし、2 列の追加だけでは「蓄積数 KPI」の問題は解決しない。既存ポータルの KPI が蓄積量のままであれば、新しいメタデータは「使われない追加情報」になりやすい。KPI への意識変化を伴わなければ、効果は限定的だ。
選択肢 B：設計から見直す——KPI 転換を起点にする
新規ポータルの設計、あるいは既存ポータルのリニューアル機会があるなら、KPI を「蓄積数」から「活用率・鮮度スコア・棚卸し完了率」へ転換する。
転換には設計コストがかかる。アクセスログの計測設計・鮮度スコアの定義・棚卸しプロセスの構築が必要だ。即日では始められないが、1 年後の状況が根本的に変わる選択肢だ。
評価軸の転換は、ポータル担当者だけでは決断できない場合が多い。経営層や推進委員会との合意形成が必要になる。この合意ステップの難しさが、KM 施策 55% 失敗の主因（変革管理の不足・経営層のサポート不足）と重なる。
選択肢 C：棚卸しから始める——失敗したポータルを再設計する
すでに「使われていないポータル」があるなら、全件棚卸しが出発点になる。①層（モデル依存テクニック）を特定して廃版・アーカイブし、②層（業務×AI 接続部）を抽出して再登録する。
棚卸しには工数がかかる。しかし、使われていないコンテンツの維持コスト——利用者の信頼喪失・検索精度の低下・更新担当者の疲弊——は静かに積み上がっており、先送りは割高になる。
A・B・C のどれを選ぶかより、「設計前に KPI を合意する」という姿勢を設計書の最初の行に置くかどうかが、1 年後の差を生む。
9. 設計書の最初の行
ポータルの設計を始める前に、一行だけ書いておく価値がある。
「1 年後に成功と評価するのは、何件の投稿があることではなく、今日も実際に使われている数だ。」
この一行があると、KPI を選ぶ会議の向きが変わる。測りやすい指標ではなく、実態を映す指標を選ぶ議論が始まる。
AI モデルは今後も更新を続ける。Copilot Prompt Gallery が四半期ごとのキュレーションを推奨し、OpenAI が廃止スケジュールを公表する状況は当面変わらない。ポータルが扱う素材そのものが、更新と廃版を前提とした性格を持っている。
10. 関連記事
エージェント定義をコードで管理する
③実装物層（エージェント定義・スクリプト）の長期管理には、Git ベースのバージョン管理が有効だ。変更履歴の追跡・差分管理・ロールバック設計は、市場型ポータルの「回転」を支える実装手段として機能する。賞味期限管理の実装モデルとして参照できる。
なぜ同僚は AI を学ばないのか
業務の型・診断の判断眼の蒸留が組織内で進まない背景には、AI 学習への組織的障壁がある。ナレッジ共有コストの根本原因を理解する文脈として参照できる。