会社の業務でMicrosoft Copilotを使うようになってから、生成AIに大量の資料を読ませて質問に答えてもらうこと自体は、思ったより簡単だと感じています。ただ、しばらく運用してみると「本当に難しいのはそこではない」ということにも気づきました。
難しいのは、次のような問いに継続して答え続けられる仕組みを作ることです。
- その情報は、どの原本のどの版に基づいているか
- 抽出結果は確認済みか、未確認か
- 過去の誤記や矛盾は、どのように訂正されたか
- 資料が改訂された後も、知識が追従できるか
- AIの会話やセッションが切れても、処理を再開できるか
- 複数部門へ展開しても、仕組みが複雑化しすぎないか
この記事では、Microsoft 365・SharePointを基盤に、原本を保護しながらAIが知識を抽出・検証・統合するための設計パターンを、自分用の備忘録として整理します。業界を限定せず、設計文書・技術資料・品質記録・保全資料などを扱う仕事であれば応用できる内容です。
この記事でわかること
- 「AI検索」だけでは長期運用が破綻する理由
- 原本を守りながらAIに知識を蓄積させる4層アーキテクチャ
- 知識を「原子レコード」に分解する設計と、否定的知識・訂正履歴の残し方
- 導入ロードマップと、よくある失敗パターン
単純な「AI検索」だけでは長期運用できない理由
AIへ大量の文書を参照させるだけでも、初期段階では一定の効果があります。ただし、運用が進むと次の問題が表面化します。
原本とAI生成情報が混在する
AIの要約や推定が原本と同じ場所に保存されると、利用者はどこまでが正式情報か判断できなくなります。特に設計値・安全条件・契約条件などでは、推定値が確定値として再利用されることが重大なリスクになります。
大きな1ファイルへ情報を集約すると壊れやすい
1つのMarkdownや表計算へすべての知識を書き足す方式は、初期構築は簡単です。しかし複数のAIエージェントが更新するようになると、競合・部分欠損・重複・誤上書きが起きやすくなります。
「存在しない情報」が記録されない
業務では「調べたが資料が存在しなかった」「改訂版でも保留状態だった」といった否定的な事実にも価値があります。これを残さなければ、別の担当者やAIが同じ探索を繰り返してしまいます。
会話履歴を状態管理に使えない
エージェントの会話履歴や一時的な実行環境は、永続的な業務台帳には向きません。セッションが変わると、前回の判断・未処理事項・作業途中の状態を失う可能性があります。
AIを導入する際は、検索機能を作り込むより先に「原本・知識・状態・監査証跡」の境界を設計する必要があります。
基本アーキテクチャは4層
推奨する構成は次の4層です。
| 層 | 役割 |
|---|---|
| 部門別の正本サイト | 図面・仕様書・記録・承認済み文書などの原本を保持。AIの都合でフォルダ再編や原本の改名・上書きはしない |
| 部門別の解析・知識化エージェント | 各部門の資料を読み取り、原本の所在・版・抽出した事実・関係・矛盾を小さな記録として生成。部門固有の用語や文書構成はこの層で吸収 |
| 統合ナレッジ層 | 各部門から提出された知識を共通スキーマで受け入れ。原本そのものではなく、原本への参照・内容ハッシュ・抽出結果・検証状態を統合 |
| 個人作業領域 | 個人メールや作業中の下書きを扱う。機密情報の検査・本人レビュー・提出可否の判断を行い、承認前の情報が自動的に共有領域へ流れないようにする |
最も重要な原則は「原本を動かさない」こと
AIナレッジ基盤を作ると、つい原本を統合サイトへ集めたくなります。しかし長期的には原本の複製が増え、どれが正しい版か分からなくなります。
ワンポイントメモ
原本は既存の正本サイトに残し、AIは読み取り専用で参照する。統合層には原本のパス・文書識別子・版・ページ・取得日時・内容ハッシュだけを記録する。再解析時はファイル名ではなく内容ハッシュで変更を判定する。
この方式なら、統合層が壊れても原本へ影響しません。知識ビューは原子レコードから再生成できます。
知識を「原子レコード」に分解する
巨大な文書へ情報を集約せず、次のような小さな単位へ分けます。
| レコード | 役割 |
|---|---|
| Inventory | ファイル・フォルダ・版・更新状態の棚卸し |
| Source Pointer | 原本の所在・版・ページ・セル・ハッシュ |
| Claim | 原本から抽出した1つの主張 |
| Relation | 機器・文書・工程・設定値などの関係 |
| Conflict | 複数資料間で競合する主張 |
| Decision | 採用・保留・却下・訂正の判断履歴 |
| Negative Knowledge | 不存在・未収録・未決定・保留継続など |
| Correction | 旧値・訂正値・訂正理由・影響 |
| View | 人間が閲覧するHTMLやダッシュボード |
Claimなら「equipment-xxxxx / ratedCurrent / 800A / 検証済み」のように、AIが生成した長い説明文ではなく、1つの事実を1レコードとして管理します。Conflictを検出しても、AIが都合よく片方を採用するのではなく、矛盾した状態のまま保存しておくことが重要です。
「否定的知識」と「訂正履歴」を資産にする
一般的なナレッジ管理では正しい答えだけを保存しがちですが、実務では次の情報も重要です。
- 探したが該当資料が存在しない
- 改訂番号は進んだが、保留表示は解除されていない
- 文書内に期待した設定値欄が構造的に存在しない
- 過去の記載値が誤りだった
訂正時は旧値を削除しないことが重要です。「旧主張：却下 → 訂正主張：検証済み → 訂正理由：原本の再確認 → 影響：後続への影響」という形で、なぜ以前の判断が誤っていたかを残すことで、監査可能な再発防止知識になります。
状態モデルは層ごとに分離する
複数エージェントを連携すると、同じ単語が異なる意味で使われる問題が起きます。個人作業領域の「レビュー待ち」と、統合基盤の処理キューの「検証中」は別のライフサイクルです。無理に統一せず、personalWorkflowState: Review / integrationRuntimeState: Validating のように名前空間を分け、同名でも意味が異なる場合は対応表に「同一視禁止」と明記するのが安全です。
識別子とレジストリを正本にする
形式検証（正規表現など）を通過しても、値が業務上正しいとは限りません。値の妥当性は正本レジストリで検証し、コード値をフォルダ名から推測しないことが重要です。推奨する識別子は次のとおりです。
sourceId／sourceVersionId／sourceContentHash／claimId／relationId／conflictId／decisionId／sessionId／packageId ― 同じIDを複数の意味で使い回さないこと。
AIの実行状態も永続化する
エージェントは1回のセッションですべてを処理できるとは限りません。大量ファイル・画像PDF・外部ツール・権限制約などで途中停止することがあるため、次の実行記録をSharePoint側へ保存します。
Session（作業開始宣言）／Claim・Lease（対象の占有）／Lock（同時更新防止）／Handover（次の実行への引き継ぎ）／Closed（終了条件を満たした記録）／Error・Retry Pending（再試行理由）／Decision Log（人間または承認済み判断）
ワンポイントメモ
終了記録が見つからなくても「放棄」「失敗」と決めつけない。検索範囲外・同期遅延・命名差異の可能性があるため「状態不明」として扱う。1回の処理量を小さくし、対象選定→原本読取→抽出→検証→保存→次タスク登録、という反復にすると、実行時間制限やコンテキスト制限に強くなる。
System Linksと人間向けビュー
大規模な文書ライブラリで毎回すべてのフォルダとファイルを列挙する設計は、件数増加やAPI制限でいずれ破綻します。設備レコードに「原本へのリンク」「関連する設定値」「改造履歴」「競合記録」「訂正履歴」「最新ビュー」を相互接続し、保存操作のたびにリンクを更新する仕組みを組み込むと安定します。
機械可読レコードは監査性に優れますが、人間には読みにくいため、原子レコードからHTMLビュー（設備別・系統別・文書別・改訂履歴・未解決Conflict一覧など）を再生成可能な形で作ります。表示物が壊れても、原子レコードから復旧できるようにするのがポイントです。
変化への自律追従と外部拡張
設備改造や文書追加に追従するには、人間が事前にすべてのフォルダを作る運用を避けます。AIは新しいファイル、原本ハッシュの変化、改訂番号の変化、新しい保留表示などを検知し、必要なInventoryやClaim、Conflictを生成します。ただし、フォルダ構造へ業務の意味を詰め込みすぎないこと。分類や関係はレジストリとリンクで管理し、フォルダは安定した保管境界として扱います。
基盤が整うと、シミュレーション・CAD・図面比較などへも拡張できます。図面生成では、生成AIに座標やCAD構造を直接作らせず、「生成AI＝意味理解・変更要求の構造化」「決定論的な作図エンジン＝座標・レイヤ・寸法生成」「検証系＝元図との比較・差分レポート」と役割を分けるのが有効です。
複数AIによる評議会型検証と、自律ループの終了条件
複雑な設計判断では、1つのエージェントが生成と自己評価を兼ねると同じ見落としを繰り返しがちです。第一原理レビュー・反対レビュー・拡張レビュー・外部視点レビュー・実行レビューのように役割を分け、統合役が弱い議論を除外して最終判断をまとめます。ただし複数モデルの一致を「正しさの証明」にせず、最終判断には必ず原本への根拠リンクと検証状態を付けます。
自己改善ループを続けさせる場合は終了条件が必須です。信頼度が条件を満たした、同一結論が複数回継続した、最大試行回数へ到達した、Conflictとして安全に停止した――「解決できないと認識して停止する」ことも正常な完了の一形態として設計します。
機密情報と個人情報を分離する
個人メールやチャットを処理する場合は、設備知識と人的情報を分けます。設備構成・定格・図面規則・改造内容・安全条件・根拠文書は統合層へ、氏名・連絡先・私的内容・一般化できない人的評価は個人領域に留めます。人的なやり取りが判断根拠になっている場合も、可能であれば「誰が言ったか」ではなく「どの文書・どの版・どの箇所で確認したか」へ置き換えます。
導入ロードマップ
| フェーズ | 内容 |
|---|---|
| Phase 1 | 1部門で基準実装を完成させる（原本読取／Inventory／Source Pointer／Claim／Conflict／訂正・否定的知識／Session管理／HTMLビュー） |
| Phase 2 | 統合層の最小受入口を作る（パッケージ受付／スキーマ検証／レジストリ検証／ハッシュ検証／重複判定） |
| Phase 3 | 少数レコードでE2E試験（原本根拠が明確な少数の訂正情報で部門層から統合層までの流れを確認） |
| Phase 4 | 人間向け統合ビューを作る（設備別／系統別／図面別／改訂別／Conflict別／未確認別） |
| Phase 5 | 外部解析と図面編集を接続（シミュレーション連携／CAD・DXF生成／PDF比較／複数モデル検証） |
| Phase 6 | 他部門へ水平展開（契約・識別子・状態境界・原本保護・System Links・監査ログは共通化、用語・文書構成・アクセス権・専門ルールは部門ごとに分ける） |
失敗しやすい設計
| 失敗パターン | 問題点 |
|---|---|
| 最初から全社統合する | 部門固有の例外が多すぎて共通スキーマが定まらない。まず1部門で実データを使い、Conflictの発生から解決まで一巡させる方が安全 |
| 原本を中央へ複製する | 複製が増え、版管理とアクセス権が複雑になる。中央には参照と抽出結果を置く |
| AIの出力を直接確定値にする | 未確認値を確定値として統合しない。Verified／Pending／Rejectedなどの検証状態を必ず付ける |
| 承認と提出を同一視する | 「レビューで承認された」ことと「共有基盤へ提出・受理・統合された」ことは別。状態を分けて記録する |
| ファイル名だけで同一性を判定する | 同名の別内容、別名の同一内容があるため、内容ハッシュ・版・原本位置を組み合わせる |
| フォルダ構造へ意味を埋め込みすぎる | 組織変更や設備追加でフォルダ設計が崩れる。意味はレジストリと関係レコードへ置く |
まとめ：12の要点
- 原本は既存の正本サイトに残す
- AI生成情報と原本を分離する
- 知識を小さな原子レコードとして保存する
- 出典・版・ページ・ハッシュを必ず保持する
- 矛盾を隠さずConflictとして管理する
- 誤記と訂正理由を削除せず残す
- 「情報が存在しない」という否定的知識も保存する
- 会話ではなくSharePoint上の記録を永続状態とする
- 小さなタスクを反復し、停止条件を持たせる
- 人間向けビューは原子レコードから再生成する
- 外部解析やCAD連携はデータ品質を確保してから接続する
- 1部門で実証してから水平展開する
この設計にしておくと、AIは単なる検索アシスタントではなく、原本を守りながら知識の変化・矛盾・訂正・判断履歴を継続的に管理する業務基盤として機能してくれます。
シリーズの他の記事
- GitHub Copilotハーネス vs Copilot Studio Classic 実務での選び方を彻底比較
- 「Obsidian第二の脳」からSystem Linksへ SharePoint版ナレッジ基盤の作り方
- 「AIにPDF図面を読ませる」を失敗させない設計 段階的解析Pipelineの作り方
- Copilot Studio・Cowork・Scout・Work IQ、結局どれを使えばいいのか
こんな人におすすめ
- 会社でCopilotやAIエージェントの導入を検討している
- 複数人・複数AIで同じナレッジベースを更新していて、情報が壊れた経験がある
- 「AIの回答は正しいが、根拠が追えない」ことに不安を感じている
よくある質問
Q. 個人や小規模チームでも、このアーキテクチャは必要ですか？
A. フル装備は不要ですが、「原本とAI生成情報を分ける」「出典と検証状態を記録する」の2点だけは、規模に関わらず早めに取り入れておくと後が楽になります。
Q. SharePoint以外の環境でも応用できますか？
A. できます。ここでの「SharePoint」は正本サイト・原子レコードの保存先の一例で、考え方自体はNotionや他のドキュメント管理基盤にも応用できます。
Q. 導入にはどれくらい時間がかかりますか？
A. 記事内のロードマップの通り、いきなり全社展開せず、まず1部門でPhase1〜3を回してみるのが現実的です。
コメント