「この件、A部長に相談すべき？それともB課長？」「C さんが昔やってたはずだけど、どう進めたんだっけ」──こういった属人的な相談ネットワークの解決をAIに任せられないか、という発想から出発した設計メモです。

1. 普通の社内AIとは何が違うのか

RAGを使った社内FAQシステムはすでに多くの企業が導入しています。しかし、これらは本質的に文書検索型です。

普通の社内AI	Person AI
「規程には何と書いてあるか」	「Aさんならどう判断するか」
文書検索中心	判断履歴中心
正解を検索する	判断を再構成する
情報単位で管理	人物単位で管理
FAQ件数を削減する	相談そのものを削減する
文書がないと弱い	TeamsやメールのやりとりもRAGに利用

会社には文書化されていない知識が大量に存在します。

「これはAさんに聞けば分かる」
「Bさんが昔やっていた」
「この案件はC課長に一度通した方がいい」

Person AIはこの属人的な相談ネットワークをデータ化する試みです。

2. CLAUDE.md から着想を得た Person.md という設計

Claude Code には CLAUDE.md という仕組みがあります。プロジェクト固有の方針・ルール・文脈をファイルに書いておくと、AIが毎回それを読み込んで判断軸にします。

参考：Claude Code Memory – Anthropic Docs

これを人間に適用したのが Person.md という発想です。

たとえば A 部長について、次のような内容をファイルに圧縮します。

Person: A部長

Role:
  担当領域: インフラ全般
  決裁可能範囲: 年間1000万円未満の構成変更
  責任範囲: 本番系インフラの安定稼働

Decision Principles:
  - 納期よりも本番影響を優先する
  - 標準構成からの逸脱を嫌う
  - 年間費用が閾値を超える場合は部長決裁
  - コスト < 安定性 < 保守期限 の優先順位

Typical Questions:
  - 製品選定、構成変更、スケジュール変更

Past Decisions:
  - 案件X: A案採用。保守期限を理由に移行期限優先（根拠: 2026-03-xx メール）
  - 案件Y: オンプレ継続。クラウド移行は次期検討（根拠: 2025-11-xx Teams）

Escalation Rules:
  - 契約変更は本人確認必須
  - 対外回答は本人確認必須
  - 重大障害はAI判断禁止

Communication Style:
  - 結論を先に
  - 選択肢は2案程度
  - メリットよりリスクを先に提示する

ただし、このファイルを人間が手書きするのでは意味がありません。

ここが重要なポイントで、AIが継続的に更新し続けます。

3. 二層構造：Person.md ＋原典検索

Person.md は「判断モデルのキャッシュ」であって、回答の唯一の根拠にはしません。

なぜなら、Person.md に

Aさんは原則オンプレミスを優先する

と書かれていても、半年前に方針転換している可能性があるからです。

そこで、質問時には次の情報を組み合わせて回答を生成します。

Outlook のメール
Teams のチャット
SharePoint の資料
会議の議事録
過去の質問回答
      ↓
AI が継続的に分析・更新
      ↓
┌─────────────────────────┐
│  Person.md（判断軸の圧縮情報）  │  ← 検索方向と判断軸を決める
└─────────────────────────┘
      ＋
┌─────────────────────────┐
│  原典データ（最新メール・Teams）│  ← 実際の根拠
└─────────────────────────┘
      ↓
 相談AI → 利用者

Person.md は検索方向と判断軸を決めるための圧縮情報という役割に徹します。

Microsoft 365 の場合、Microsoft Graph を使ってメール・会議・チャット・ファイルを組織データとして検索する基盤はすでに存在します。Microsoft 365 Copilot も既存権限に基づいてデータを grounding する設計です。

この発想で一段先を行くのが、検索結果から特定人物の判断原則を継続的に抽象化し続ける部分です。

新しい Teams 会話
    ↓
新しい判断らしき発言を発見
    ↓
既存 Person.md と比較
    ↓
判断基準変更の候補を生成
    ↓
Person.md を更新

4. AIの回答を3段階に分ける

Person AI の回答は確度によって3段階に分けると実用的です。

確度	AIの動作
高確度	AI だけで回答する
中確度	回答案と根拠を提示する
低確度	本人へのエスカレーションを提案する

重要なのは、低確度の場合でも質問をそのまま人間に投げないことです。

❌ 「どうしましょうか？」を A さんに聞く

⭕ AI が次のように整理してから渡す：

これまでの情報から A 案を推奨候補と考えています。
今回だけ判断できない点は「保守期限の優先度」です。
「保守期限を優先して B とする認識でよいか」を
A さんに確認するだけで進められます。

これだけで、上司側の対応時間は大きく変わります。

また、名称を**「クローン AI」にしないこと**も重要です。

Aさんがそう言った

という誤認を防ぐため、概念名は以下のどれかが適切です。

Expert Proxy
Consultation Agent
Decision Proxy
Digital Expert

あくまで「A さんの過去の判断資料から推定するとこうです」という立場を明確にします。

5. 最大の難所：AI の性能ではなく権限と情報境界

技術的にもっとも難しいのは、誰がどの情報を使って回答を得られるかという設計です。

Person AI では、

❌ A さんが見られる情報を学習したAI
⭕ 質問者が見られる情報だけを回答生成に使うAI

この設計を間違えると、次のような重大事故が発生します。

A さんのメールで学習した AI に聞いたら、知らないはずの人事情報が出てきた

他社との相談まで対象にする場合はさらに複雑です。会社 A と会社 B をまたぐ Person AI では、どのメール・会議・資料をどちら側に開示してよいかという契約上・情報管理上の境界を設計する必要があります。

Microsoft 365 Copilot が Microsoft 365 の既存権限を尊重して回答する設計になっているのは、この問題に正面から対応しているからです。

6. 最終的な構想：組織の判断構造をAI化する

Person AI の先にある構想は、「誰に何を相談すべきか」という意思決定経路そのものをAI化することです。

担当者 AI
    ↓
課長 AI
    ↓
部長 AI
    ↓
法務 AI
    ↓
セキュリティ AI

質問を投げると、

担当者レベルで解決できるか
課長判断が必要か
法務確認が必要か

をAIが判定します。

これは「上司のクローン」ではなく、組織内部に存在する人間 API を AI の API に変換するという捉え方に近いと思っています。

表面的な SaaS をAI化するより、組織内の暗黙知・属人ネットワーク・判断経路を構造化することの方が、実務上のインパクトは大きいのではないでしょうか。

まとめ

ポイント	内容
目的	相談をゼロにするのではなく、人間へ到達する質問を圧縮する
設計	Person.md（判断軸キャッシュ）＋原典検索の二層構造
回答	高・中・低確度の3段階で人間の負荷を分散
難所	AI性能より権限と情報境界の設計
展望	組織の意思決定経路ごとAI化する

「この件、誰に聞けばいい？」という問いに答えるのは、文書検索型AIより判断モデル型AIの方が向いています。Person.md という設計思想が、その入口になるかもしれません。

#AI #ChatGPT #LLM #RAG #Microsoft365
#社内AI #業務効率化 #AIエージェント #組織設計 #ナレッジマネジメント
#Copilot #MicrosoftGraph #Teams #Outlook #SharePoint
#PersonAI #DecisionProxy #属人化 #暗黙知 #相談コスト
#エンタープライズAI #IT企画 #社内DX #業務自動化 #AIアーキテクチャ
#ClaudeCode #CLAUDE_md #プロンプト設計 #AIシステム設計 #情報アーキテクチャ
#生成AI活用 #AIコンサルタント #意思決定支援 #組織DX #人間APIのAI化