TCC社内Wiki アーキテクチャ構想
このノートについて
オサケンさん発案「議事録Wiki化」構想を、Claudianが4層アーキテクチャで補完したもの。LLM-Wiki記事（Zenn/tsurubee）の思想を下敷きにしつつ、TCC固有の組織課題（声の大きな傍観者文化）を踏まえたフィルター設計を中核に据える。
0. 設計の核心：「整流装置としてのWiki」
オサケンさんの素朴な感想（2026-05-19）
この社内Wikiはそのまま読ませたくないんだよね。声の大きな傍観者、井戸端会議、野次馬が大勢を占めているTCCには悪影響が多いと思うので。
これは素朴な感想ではなく、==設計の核心==。
126本の生議事録には、事実の他に 派閥・感情・私情・言い回しのトゲ・誤解 が混ざっている。これを全社員に開示すると、Wikiは議論の燃料ではなく 「派閥の弾薬庫」「言った/言わない論争の根拠地」 になる。
LLM-Wikiの真の価値は、検索性でも要約でもなく、==「知識の整流（フィルタリング）」==。
- 生情報 → 派閥が利用する
- 整理された知識 → 組織が依拠する
この差を生むのがWikiレイヤーの存在意義。
1. 4層アーキテクチャ
図は2形式で用意
- Mermaid版（下記）：本文と一緒に読める。構造把握向け
- Excalidraw版：
Transclude of TCC社内Wiki_アーキテクチャ図.excalidraw— 縦長で一画面把握＋手描き風編集
flowchart TD subgraph L0["Layer 0: 原典層（非公開）"] A["126本の幹部会議事録<br/>Obsidian Vault<br/>obsidian-skills形式"] end subgraph L1["Layer 1: Wiki層 ★整流フィルター★"] B1["人物ページ"] B2["施策ページ"] B3["KPIページ"] B4["課題ページ"] B5["決定事項ログ"] B6["未解決事項ログ"] end subgraph L2["Layer 2: 配信層"] C1["Google Document<br/>自動アップデート"] C2["NotebookLM<br/>Wiki全体ソース化"] end subgraph L3["Layer 3: 利用層"] D1["一般社員<br/>LINE個別"] D2["部門グループ<br/>グループLINE"] D3["幹部（部長・課長層）<br/>NotebookLM直接"] D4["しおりさん社長<br/>Claude"] end A -->|LLM抽出・整流| L1 L1 -->|定期同期| C1 L1 -->|ソース投入| C2 C2 --> D1 C2 --> D2 C2 --> D3 L1 -->|横断質問| D4 A -.原典参照.-> D4 style L0 fill:#fee,stroke:#933 style L1 fill:#ffd,stroke:#960 style L2 fill:#dfe,stroke:#063 style L3 fill:#def,stroke:#036
2. 各層の役割と取扱者
Layer 0：原典層（非公開）
- 中身：126本のTCC幹部会議事録（Obsidian Vault内）
- 形式：obsidian-skills（callout・wikilink・引用カード完備）
- 取扱：Claudian / Cloco / Claude（オサケンさん＋しおりさん）のみ
- 原則：==社員には直接見せない==。原典は法廷記録のような厳密性を持つが、組織運用には不適
Layer 1：Wiki層 ★整流フィルター★
- 中身：コンセプト単位のページ群
- 人物ページ：登場人物ごとの発言傾向・役割・関係性（事実ベース）
- 施策ページ：客単価／コンペ／DP／茶店／評価制度 等
- KPIページ：来場・売上・回転・離脱率の推移と議事録での言及
- 課題ページ：未解決の構造的問題
- 決定事項ログ：日付付きの公式決定
- 未解決事項ログ：3回以上議論されて結論が出ていない件
- 生成主体：Claudianが原典を読み、LLMで抽出・整流
- 更新トリガー：新規議事録追加 or 週次バッチ
- 整流フィルター内容：
- 派閥的言い回し → 中立表現に
- 感情語 → 事実描写に
- 個人攻撃 → 構造課題に
- 「言った/言わない」 → 「日付・発言・根拠」のみ
Layer 2：配信層
- Google Document：
- Wiki層の最新版が自動アップデートされる
- 社員が「正式記録」として参照する正典
- 編集権限は Claudian / オサケンさん / しおりさん のみ
- NotebookLM：
- Wiki全体（Layer 1）をソース化
- 社員が自然言語で質問できる対話窓口
Layer 3：利用層
| 利用者 | チャネル | 用途 |
|---|---|---|
| 一般社員 | LINE個別 | 「うちの部署のDPは今どう決まってる？」等の確認 |
| 部門グループ | グループLINE | 部門会議の前提共有・前回の流れ確認 |
| 幹部（部長・課長層） | NotebookLM直接 | 戦略判断のための横断検索 |
| しおりさん社長 | Claude | より深い掘り下げ・原典まで遡る判断 |
3. Wikiドメイン分割設計（4Wiki構成）
設計の重要判断
単一巨大Wikiではなく、==4つの独立Wikiに分割する==。オサケンさん発案・Claudian合意（2026-05-19）。
3-1. なぜ分割が正解か（5つの理由）
| # | 理由 | 内容 |
|---|---|---|
| 1 | RAG精度 | 単一巨大Wikiでベクター検索すると無関係ドメインのページが混入しハルシネーション源になる。検索空間を絞る＝精度が上がる |
| 2 | 整流ルールが本質的に違う | 幹部会＝厳格／VoC＝軽め／規定＝なし。1つに混ぜると全部に同じルール適用できない |
| 3 | 権限管理が自然になる | Wiki単位＝権限単位で明快。ページ単位の権限制御は運用破綻する |
| 4 | NotebookLM仕様に合致 | 1ノート＝50ソース等の制約があり、全部1ノートは無理 |
| 5 | 「意図」の哲学 | 「どのWikiに聞くか」を選ぶ行為が利用者のメタ認知トレーニングになる |
3-2. 4Wiki構成
| Wiki | 原典の所在 | 整流レベル | 主利用者 | 公開範囲 |
|---|---|---|---|---|
| 幹部会議事録Wiki | TCC幹部会議事録/（126本） | 厳格（派閥対策） | 幹部・経営層 | 管理職以上 |
| 企画室Wiki | TCC企画室議事録/ | 中（中立化） | 企画室＋経営層 | 関係者 |
| Voice of Customer Wiki | 新規・既存DB集約 | 軽（匿名化のみ・生の声尊重） | 現場・マーケ・経営層 | 全社員（場合により） |
| 社員規定Wiki | 新規 TCC_社員規定/ | なし（原典そのまま） | 全社員 | 全社員（一般公開） |
各Wiki＝独立NotebookLMノート＋独立Google Doc＋独立LINE Bot応答経路。
3-3. 整流ルール差の具体例
| Wiki | 個人名 | 派閥的言い回し | 感情語 | 引用 |
|---|---|---|---|---|
| 幹部会 | 役職表記化 | 中立に書き直す | 事実描写に | 厳選 |
| 企画室 | 役職表記化 | 経緯は残す | 文脈次第 | 論点ごと |
| VoC | 匿名化（必要時） | お客様の声はそのまま | むしろ残す（顧客感情が情報） | できるだけそのまま |
| 社員規定 | なし | なし | なし | 原典そのまま |
VoCで感情語を中和すると、お客様の声の価値が消える。逆に幹部会で感情語を残すと派閥対立を温存する。整流は全ドメイン共通ではない。
3-4. 横断質問の沼を避ける3層設計
オサケンさんの懸念（「横断したいけど沼に入りそう」）に対する答え：
| 層 | 利用者 | 横断範囲 | 方法 |
|---|---|---|---|
| 1 | 一般社員（LINE） | 単一Wiki内で完結 | @幹部会 @VoC のメンションで明示選択 |
| 2 | 幹部（NotebookLM） | 各Wikiノートを切替 | NotebookLM標準UI |
| 3 | しおりさん（Claude） | 4Wiki＋Layer 0原典 全横断 | 経営判断の根拠探索専用 |
3-5. 横断テーマへの対処：「メタページ」
「客単価」のように複数Wikiに登場するテーマは、Phase 2以降に メタページ（各Wikiの該当ページへのリンク集）として作る。沼に入らず、必要時だけ横断する形。
3-6. LINE Botでの分割選択（明示メンション方式）
最初は自動振り分けを避け、明示メンションを推奨：
ユーザー：@幹部会 客単価議論の流れ教えて
Bot：（幹部会Wikiだけ参照）2024年Q1から3回議論されてます…
ユーザー：@VoC 最近のクレーム傾向は？
Bot：（VoC Wikiだけ参照）2026年4月以降、特に多いのは…
自動振り分けはハルシネーション源泉になるため、Phase 3以降の検討事項。
3-7. 実装優先順位
==幹部会議事録Wikiから着手==（2026-05-19合意）。理由：
- 126本という最大の死蔵資産
- 経営判断の根拠が眠っている
- 整流ルールの最難関 = ここを通せば他は楽
- しおりさん監修サイクルが回しやすい
他3Wiki（企画室／VoC／社員規定）は、幹部会Wikiの整流ルールv1.0が固まった後に並行展開。
3-8. 第5Wiki：キーパーソンWiki（次フェーズ・極秘）
オサケンさん発案（2026-05-19）
理事長・オーナー・天皇・国王＝小池建夫さんのWikiを別建てで作る構想。「脳死状態で言われるままに右往左往し赤字化・貧乏化しないですむ」 ための装置。議事録LINE化の次フェーズで着手。
3-8-1. なぜ4Wikiとは別建てか
第5Wikiは組織情報Wiki（4Wiki）とは構造的に別物：
| 観点 | 4Wiki（組織情報） | 第5Wiki（キーパーソン） |
|---|---|---|
| 本質 | 組織の意思決定の記録 | 特定個人の判断パターン |
| 整流ルール | 個人名→役職に変換 | 個人名そのまま（本人が対象） |
| 公開範囲 | 全社員〜幹部 | しおりさん・オサケンさん・腹心のみ（極秘） |
| 情報源 | 議事録（完成形ソース） | 議事録抜粋＋取材＋観察（ボトムアップ） |
| 機能 | 過去議論の可視化 | 意思決定前の判断軸の客観化 |
3-8-2. 設計思想：RAGより「丸裸」
オサケンさん（2026-05-19）
RAGはブラックボックス的だけど、Wikiは丸裸（笑）
RAGは「答えを出す」道具だが、==なぜその答えが出たかが辿れない==。Wikiは構造化された静的ページなので、誰でも全体を見渡し、批判的に検証できる。経営判断の場では「丸裸」の方が組織健全化に効く——「小池さんがこう言った」を脳死で受け入れない仕掛けになるから。
3-8-3. 情報収集アプローチ（ここが本丸の難所）
議事録のような完成形ソースがないため、ボトムアップで集める：
- 既存議事録からの全件抽出：126本＋企画室から「小池さん発言」のみ時系列で抽出
- しおりさんへの構造化インタビュー：オーナーとのやりとりの記憶ダンプ（量的に最大）
- オサケンさん観察記録：コンサル経験から見た判断パターン
- 過去メール・LINE・Slack：テキストが残っているもの全てスキャン
- （上級）小池さん本人インタビュー：表向きは別目的（自伝・取材）で実施
3-8-4. 抽出する情報の構造
- 意思決定パターン：「こういう案件にはこういう反応をする」
- 価値観・好み・タブー領域
- 口癖・言い回し（判断の前触れになる言葉）
- 歴代の重要決定とその文脈
- ==逆鱗ポイント==（地雷リスト）
- ==過去の「赤字化・貧乏化」を招いた指示パターン==（脳死防止の核）
3-8-5. 着手タイミング
- Phase 2（LINE化）完遂後に本格着手
- それまでに、幹部会議事録Wikiの作業中に「小池さん発言抽出」を副産物として蓄積しておく（=情報源1の前倒し）
- 公開範囲が極秘なので、しおりさんとの個別合意を取った上で進める
4. なぜ「LLM-Wiki」が機能するか
4-1. 理論的根拠（Zenn記事の核心）
3つの本質：
- 帳簿コストがゼロに近づく
- 従来のWiki：人間が手で書く・更新する → 死ぬ
- LLM-Wiki：議事録追加→自動更新→人間は監修だけ
- 繋げて初めて見える知見
- 単一議事録には現れない「3ヶ月にわたる客単価議論の変遷」が可視化される
- 理解のボトルネック解消
- 「過去経緯を知らないから発言できない」が消える
- 一般社員も前提を持って議論に参加できる
TCCにこれが起きると、「お伺い文化」「上意下達」の構造的根拠（情報の非対称性）が消える。
4-2. TCC現場での実証データ ★★
オサケンさんが既に試した類似手法（2026年初頭）
基幹システムの新旧マニュアルを丸ごとNotebookLMに投入し、TCC社員に 「読まずに質問する」運用 を提案。結果、その社員は感激した。
- 当時のTCC社員の状況：
- ある社員は5cm厚さで印刷して机に積み上げて読んでいた
- ある社員はExcelファイルのマニュアルを苦労してスクロールしていた
- NotebookLM化の効果：
- 「全部読む」というハードルが消えた
- 必要なときに必要なことだけ質問できる
- 設計上の重要な示唆：
- NotebookLMは「読むツール」ではなく ==「読まないで済ます基盤」==
- つまり議事録Wiki化も「読ませる」ではなく「質問できる場をつくる」が正解
- 既にTCC内で受容実績があるチャネルなので、社内導入の心理的障壁が低い
==この実証データは、構想全体の説得力を一段上げる==。新規施策ではなく「成功した試みの拡張」として位置付けられる。
5. リスクと運用設計
リスク
| リスク | 内容 | 対策 |
|---|---|---|
| 整流の不完全さ | LLMが派閥的言い回しを残してしまう | Layer 1公開前にしおりさん or オサケンさんが監修 |
| Wiki≠原典の混同 | 社員が「Wikiにこう書いてある」と原典を無視 | Wikiに「※これは整理版です。判断材料としての原典は経営層保管」を明記 |
| 既得権者の抵抗 | 情報非対称性で優位だった人が反発 | Phase 1は試験運用・限定公開でリスク管理 |
| 個人名の露出 | 名指しが残ると人間関係悪化 | 整流ルールに「個人名→役職表記」を組み込む |
| 「言った/言わない」の決着 | データで決着がついて感情的しこりが残る | しおりさん経由で配慮した伝え方 |
運用ルール案
- 更新サイクル：週1回バッチ＋幹部会後即時
- 編集権限：Layer 1=Claudian書き込み・しおりさん承認 / Layer 0=変更不可
- アクセスログ：誰が何を見たかは記録（必要時のみ参照）
- 異議申し立て窓口：社員が「この記述は違う」と言える経路を設ける
6. 段階導入計画（3フェーズ）
実装容易性の順に並べる。==Phase 1だけで価値は既に出る==。LINE化は Phase 2、しおりさんClaude深掘りは並走で OK。
Phase 1：Google Docs ＋ NotebookLM化（最速・2-3週間） ★
==基幹マニュアル事例と同じ方式。社員にとって既知のチャネル。==
- Claudianが6本のサンプル概念ページを作成（客単価／コンペ／DP／茶店／評価制度／レストラン）
- 2026-05-19 オサケンさん判断：当初5本＋「レストラン」追加（単価アップの重要テーマ）
- 「茶店」は薄いテーマでの整流ルール実証用として継続
- 整流ルールでパイロット → しおりさん監修
- Google Docs化（自動アップデート設定）
- NotebookLMノート作成 → 幹部層に共有
- スライド化・Podcast化・横断質問は標準機能でそのまま使える
- この時点で「読まずに質問する」価値は届く
- 段階的に126本フル展開＋管理職層→一般社員に拡張
Phase 2：LINE化（改造2-3日＋社員教育数週間）
==Phase 1の手応えを見てから着手。商品化への布石でもある。==
- 既存LINE-aika／すみこ代理AIスタックを流用
- LINE個別（社員ホワイトリスト）＋部門グループLINE対応
- Gemini API（Google Workspace親和性）でRAG実装
- 出典Wiki＋日付を必ず提示
- カジュアル入口として一般社員の利用を底上げ
Phase 3：しおりさんClaude深掘り化（Phase 1と並走可能）
- しおりさん専用：原典まで遡れる横断質問環境
- Wiki層 ＋ Layer 0原典 の両方にアクセス可能
- 経営判断時の「根拠まで遡る」用途
- Phase 1と独立してすぐ稼働可能
Phase 4：定常運用と発展（3ヶ月以降）
- 議事録追加で自動更新
- 「未解決事項ログ」が幹部会の議題セットになる
- TCCダッシュボードとの統合（KPI実績 ⇔ Wiki議論履歴）
- 商品化検討の入口（§9参照）
フェーズ別の優先度マトリクス
| フェーズ | 実装難度 | 効果が出るまで | 心理的障壁 | 商品化への寄与 |
|---|---|---|---|---|
| Phase 1（NotebookLM配信） | 低 | 即時 | 低（既知チャネル） | 中 |
| Phase 2（LINE化） | 中 | 数週間 | 中（新規習慣） | 高 |
| Phase 3（しおりClaude） | 低 | 即時 | なし（個人利用） | 低 |
7. 配信チャネル設計：NotebookLMを本丸、LINEを入口に
==重要：「LINEありき」ではない==。基幹マニュアル事例から学べたのは、NotebookLMだけで既に「読まないで質問する」価値が届くこと。LINEはあくまでカジュアル入口（=普段使い）に位置付ける。
7-0. チャネルの使い分け
| 社員タイプ | 主チャネル | 用途 |
|---|---|---|
| 普通の社員 | LINE | 「DPはいま何が決まってる？」等の即時確認 |
| 熱心な社員 | NotebookLM | スライド化／Podcast化／横断質問 |
| 幹部 | NotebookLM | 戦略判断のための横断検索 |
| しおりさん社長 | Claude | 原典まで遡る深掘り（Phase 3） |
7-1. NotebookLM配信（本丸）
- Wiki更新 → NotebookLMノート同期はClaudianがMCP経由で自動化可能（既に第15回チュートリアル等で実証済み）
- スライド化・Podcast化・引用付き回答 すべて標準機能
- TCCがGoogle Workspace運用 → SSO・権限管理・アクセス制御が自然
- ==基幹マニュアル事例で既に社員に受け入れられている==
7-2. LINE×NotebookLM 連携の運用可否（Phase 2向け回答）
オサケンさんの質問（2026-05-19）
LINEでNotebookLMWikiにチャットで問い合わせは実際に実現可能、運用レベルでできますか？
==結論：「NotebookLMそのもの」をLINEに繋ぐのは不可。だが「同等以上の体験」は十分実現可能。しかも既存のオサケンさん資産で。==
7-3. なぜNotebookLM「そのもの」は繋げないか
- NotebookLMは公式の LINE Bot連携機能なし
- 公開APIなし（2026-05-19時点、GoogleはGemini本体のAPIを推している）
- 私たちが使っている
notebooklm-mcpも非公式の自動化（Cookieベース）であり、社内本番運用には不向き
7-4. 代わりに何で実現するか
==「Gemini API ＋ Wiki本文をRAG的に注入」== でNotebookLM体験を再現する。Gemini採用はTCCのGoogle Workspace運用と親和性が高い（自然な選択）。
社員のLINE質問
↓
LINE Messaging API (Webhook)
↓
Vercel Function（既存LINE-aika資産を流用）
↓
1) 質問から関連Wikiページを検索（埋込検索 or 全文）
2) Wiki抜粋 + 質問 を Gemini Flash に投げる
3) 回答を整形（出典Wikiページのリンク付き）
↓
LINE Bot 返信
7-5. 既存資産との接続
オサケンさんが既に持っているもの：
- LINE-aika（line-aika.vercel.app）: LINE Bot + Vercel Function + AI API のひな型
- すみこ代理AI: 同スタックで複数ユーザー対応の実証済み
- Wikiコンテンツ（これから作る）: GitHub or Vault同期で配信
- NotebookLM運用ノウハウ: 基幹マニュアル事例で社員受容実績あり
==新規開発はほぼ不要、改造で2〜3日==。
7-6. コスト感（試算）
| 項目 | 月額 |
|---|---|
| LINE Messaging API（〜1000通） | 無料 |
| Vercel（個人利用枠） | 無料 |
| Gemini 2.0 Flash（100社員×月10問×1Kトークン） | $1未満 |
| 合計 | 実質ゼロ円 |
100社員が月10問ずつ叩いてもこの程度。TCCの予算規模なら誤差。
7-7. 運用レベルで詰めるべき論点
| 論点 | 提案 |
|---|---|
| 認証 | LINEのuserIdをホワイトリスト化（社員のみ） |
| グループLINE対応 | Bot招待＋メンション検出で実装可能 |
| 監査ログ | 誰が何を聞いたか・Vault _logs/ に追記（個人特定可） |
| 出典提示 | 回答末尾に「根拠：Wiki『DP施策』2026-03-15更新」と必ず付ける |
| ハルシネーション対策 | RAGで該当箇所が無ければ「Wikiに記述なし」と返す（推測禁止） |
| 改訂対応 | Wiki更新→Webhook→自動でインデックス再構築 |
7-8. 注意点（しおりさんへの相談材料）
- ログ＝監視と受け取られるリスク：誰が何を質問したかを記録すると、社員が萎縮する可能性。「集計のみで個人特定はしない」など運用方針を決めておく
- 回答の権威性：AIが「決定事項」と答えたものを社員が鵜呑みにする → 必ず出典Wiki＋日付を提示
- 方言・敬語：Bot回答のトーンは「である調」「ですます調」のどちらか統一を最初に決める
8. Antigravityへの発散について
こういう使い方はAntigravityのほうがいいのかな？
==今は要らない==。理由：
- Obsidian-Excalidrawプラグインが入っているので、左ペインプレビューはObsidianで完結
- このWiki構想は「対話＋整理」が主で、Antigravityの強みである「エディタ統合・コード補完」は出番が薄い
- AntigravityはClaudianが第15回チュートリアル分析等で別途使う方が活きる
9. Excalidrawファイルについて
TCC社内Wiki_アーキテクチャ図.excalidraw に4層図を切り出しました。 Obsidianで開けば手描き風に編集可能。最後の絵心はオサケンさんの手で。
10. しおりさん社長への相談ポイント
このノートを丸投げせず、以下5点を持って行く：
★ 最重要メッセージ（必ず最初に伝える）
==「Wikiは議論の触媒です。完成形ではありません。揚げ足を取ってもらうほど良くなります」==
これが伝わらないと、Wikiは「権威化された静的ドキュメント」になり、組織議論を硬直化させる。逆効果。 ==しおりさん／オサケンさん／幹部が積極的に揚げ足を取る文化==がWiki化の成功条件。
相談5項目
- 「整流フィルター」という設計思想（井戸端会議対策）への合意
- 4Wiki構成への合意（幹部会／企画室／VoC／社員規定の独立Wiki化）— まず幹部会から着手
- Phase 1試験運用の許可（基幹マニュアル事例の拡張として位置付け・7本サンプル・幹部層限定）
- 個人名取扱いルール（役職表記化の徹底）
- ==★ Class D（口頭証言）補完取材への協力== — Wiki化最大のキー
- 議事録には「声が大きい人」しか書かれない構造的バイアスを認識
- しおりさん／オサケンさんの ==口頭証言== がWikiの最大価値源
- 「議事録にない裏ストーリー」を取材形式で補完
- 例：ビール値上げの真の発案者・採用判断の背景・相乗効果は全て議事録外
将来の商品化視点（==TCCとは切り離し==、別ノート _LLM-Wiki_SaaS事業構想.md で管理。しおりさん相談時にはこの話を持ち込まない）
持って行きやすい言い方（提案）
「基幹システムのマニュアルでNotebookLM試したやつ、感激してくれましたよね。あれと同じやり方で、幹部会議事録もWiki化できます。==ただ大事なことがあります：Wikiは完成形じゃなくて、議論のきっかけ。揚げ足を取ってもらうほど良くなるんです。56本のうち、まず7本だけ整理して、しおりさんに『これ違うんじゃない？』って指摘してもらうところからやりたいんです。特に、議事録に書かれてない真相 — 例えば誰が最初に提案したか、誰の前例があったから採用されたか — そういうのは口頭で教えてもらわないと、Wikiには絶対残らない==。LINE連携は次のフェーズで、社員も使えるようにしますね」
合意取れたら、ClaudianがPhase 1サンプル7本を1週間で作る。56本読むのは私の役目です。
Class D（口頭証言）取材セッションの提案
しおりさん相談1回目の場で、いきなり ==1〜2本だけ Class D 取材を実演==する：
- 「コンペの最初の20組限定化、誰の発案でした？」
- 「客単価が下がり始めた最初の月、しおりさんが最初に気づいたきっかけは何ですか？」
- 「人員不足が一番厳しかった時期、何を最初に手放そうと考えました？」
==この場で「Wikiに書かれていない真相」が引き出せれば、合意は得られる==。
関連リンク
更新履歴
| 日付 | 内容 |
|---|---|
| 2026-05-19 | 初版（Claudian）。オサケンさん発案「議事録Wiki化＋Google Doc＋NotebookLM＋LINE＋Claude」構想を4層モデルで補完。 |
| 2026-05-19 | 更新（Claudian）。基幹マニュアルNotebookLM実証データ追加・段階導入を3フェーズ化（NotebookLM配信→LINE化→Claude深掘り）・商品化視点を新節として追加。 |
| 2026-05-19 | 更新（Claudian）。§3にWikiドメイン分割設計（4Wiki構成）を新設・以降の節番号を+1シフト・しおり相談ポイントに「4Wiki構成合意」追加。構想フェーズ完了→次は幹部会議事録Wiki化の実装フェーズへ。 |
| 2026-05-19 | 更新（Claudian）。§10「商品化への射程」を_LLM-Wiki_SaaS事業構想.mdへ切り出してTCCドキュメントから削除。以降番号-1シフト。理由：TCCを実験台扱いと読まれかねないため、しおり相談時の文脈から外す（オサケンさん判断）。 |
| 2026-05-19 | 更新（Claudian）。§3-8として「第5Wiki＝キーパーソンWiki（小池建夫さん）」構想を追記。議事録LINE化の次フェーズで着手。極秘扱い・しおりさん個別合意必要。「RAGはブラックボックス、Wikiは丸裸」というオサケンさん洞察を設計思想として記録。 |
| 2026-05-19 | ==第3の方法論的進化==（Claudian）。オサケンさんの「議事録には声が大きい人のことしか書かれない」「揚げ足を取られてこそWiki」発言により、しおり相談ポイント§10を全面改訂：(1)「Wikiは議論の触媒です」を最重要メッセージとして冒頭に置き、(2) Class D（口頭証言）補完取材への協力を相談項目5として追加、(3) しおりさん相談1回目の場で「Class D取材を実演」する具体案を提案。整流ルールv0.5は§4を4クラス化＋§10「声の大きさバイアス」＋§11「Wiki化の触媒哲学」へ進化。 |