2026-10-08 ナレッジハブMTG・最新情報の反映

GitHub（PLUS-Company/knowledge-hub、plus-nakataで参照）の10/8議事録と小林さんの当日作業ログを読み、プロジェクトページとWikiを更新しました。根拠はmainの1863c324（10/8 18:04 JST）です。

今日のMTGで決まったこと

参加：小林真由・中田文人・米原楓。
1. 用語は新メンバー・新事業部の参加を起点に追加。厳密なルールより最低限の記載項目を重視する。
2. 複数事業部で使われる語は共通用語へ。company/を新設し、会社概要・用語集1ファイル・疑問ストックを置く（9/7のai/配置方針を変更）。
3. 人の質問だけでなく、AI自身が理解できなかったことも溜める。まず手動で試し、人が回答する時間を運用に含める。
4. 解決した内容は用語集かルールに残す。回答の解釈ずれは当面、人同士で修正する。
5. Slack APIは各自で取得範囲・セキュリティを調査。期限なし。

MTG後の進展と残作業

• 小林さんの作業ログでは、疑問ストックの叩き台・説明資料を作成し、登録の試用とチーム共有まで実施。1疑問＝1ファイル、重複は既存へ追記、会話中に解決したものは用語集・rulesへ直接反映、解決済みファイルはdoneへ移す案です。
• 疑問ストック用の共通指示文3行はチーム承認待ち。回答が人によって違う場合の決め方も保留。叩き台の細則を正式決定として扱わないよう明記しました。
• mainにはcompany/about.md・glossary.mdが存在します。同じコミットのcompany/配下に疑問ストックファイルはまだ見つかっていません。全員への適用済み・自動通知稼働済みとは記載していません。
• 施策ログv2は議事録上、ログ作成から本番反映の検知・計測中への切替まで。期限自動通知は未着手。昇格の数値基準、GA4の移行・閲覧権限、リス用ウォッチャー調整とCLI試用が残ります。
• 次回はcompany/・疑問ストックの試用結果、昇格ルール、計測の仕組みを扱う予定。具体的な次回日時は議事録に記載がありません。

反映・検証

プロジェクトの現在地・次の作業・保留・決定7項目・MTG履歴を更新。Wikiは10/8 MTGと疑問ストックの2ページを追加し、関連9ページを更新しました。過去の記録は日付付きで保持。保存後のAPI読戻しで本文を照合し、関連ページのHTTP 200と表示内容も検証済みです。

• プロジェクト：https://plus-creative.xyz/nakata/plus_ai_intro/projects/detail.php?slug=knowledge-hub
  
• 10/8 MTG：https://plus-creative.xyz/nakata/plus_knowledge_wiki/index.php?page=mtg-2026-10-08
  
• 疑問ストック：https://plus-creative.xyz/nakata/plus_knowledge_wiki/index.php?page=question-stock
  
• 次のアクション：https://plus-creative.xyz/nakata/plus_knowledge_wiki/index.php?page=next-actions
  

訂正：2026-09-24 MTG 記録（コメント #1275）の参加者と宿題の担当

• 参加者：中田・奈良・小林・髙橋・米原（9/30 確認）
• 次回（10/1）までの宿題「施策ログ用コマンドの叩き台作成」「叩き台の試用・調整」の担当は未確定です。
  
  • 議事録が2つあり、担当が「奈良・髙橋」の版と「小林・米原」の版（knowledge-hub の pluswork/Knowledge-mtg/ にある訂正版）に分かれています。
• それ以外の決定事項・議論の内容に変更はありません。
• プロジェクトページと Wiki も同じ内容に直しました。

2026-09-24 ナレッジハブMTG 記録（施策ログ運用・記録の仕組み化）

開催情報

• 2026年9月24日（木）10:00〜
• 参加：中田・奈良・髙橋
• 資料：https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026092403.html
  （ほか 2026092401 / 2026092402）

決定事項

1. 作業ログと施策情報は分けて管理する（作業ログは従来どおり日付単位。施策情報はプレイブック候補として別ファイルで更新し、リンクで紐づける）
2. 施策記録の対象は「数値改善が見込める施策」のみ。クライアント都合の変更などは作業ログだけに残す
3. 施策記録の単位はタスク番号（同じページでも依頼が別なら別ファイル）
4. ツール開発などのログもナレッジハブ経由で残す
5. 記録はコマンド化する。自動で取れる項目はAIが埋め、仮説・考察はAIが質問して引き出す
6. 必須項目は大きい項目（考察など）に絞り、細目は候補の提示にとどめる（全項目が埋まらなくても記録できる）
7. GA4連携はアカウント整備を待たず、参照できる範囲で先に仕組みを作る

議論のポイント

• テンプレートは中田作成の統合テンプレート（記入例つき）をたたき台にし、運用しながら削る
• ビフォー・アフター画像は必須にしない。ドライブ・Figma・コードなど後から確認できる形で紐づけばよい
• 仮説は「かっこいい仮説」でなくてよい。予測があるから、結果が違ったときに原因を考えられる
• 検証＝仮説と実測値の答え合わせ。検証を経て考察に進む
• 施策単体の効果はABテストをしていないため測れていない（ページ全体の前後比較のみ）
• 記録の仕組み自体の効果も定期的に振り返る

次回（10/1）までのタスク

1. 奈良：施策ログ用コマンドの叩き台を作成（既存の自分用フローを今回の項目に合わせて改造）
2. 髙橋：叩き台を試用し、拾えていない項目を調整
3. 早くできたらMTG前に全員へ共有し、次回決められる状態にする

次回・持ち越し

• 施策ログコマンドと項目の最終決定
• 昇格ルール（点数・閾値）の確定
• 会社概要・用語集（エンジニア目線の項目が未反映で停滞）
• スクショでしか残せない成果物の保存場所

反映先

• プロジェクトページ：https://plus-creative.xyz/nakata/plus_ai_intro/projects/detail.php?slug=knowledge-hub
  
• Wiki：https://plus-creative.xyz/nakata/plus_knowledge_wiki/index.php?page=mtg-2026-09-24
  

2026-09-24 ナレッジハブMTG — 話し合う内容

開催情報

• 2026年9月24日（木）10:00〜（毎週木曜の定例）
• Google Meet：https://meet.google.com/axz-sfqa-shh
  

話し合う内容

1. 施策記録の残し方の統一（メイン）
   　- MS・リスの今のlogs・施策記録を見せ合う
   　- 各自の「理想の残し方」を持ち寄り、全員がまず同じ情報を残せる形にする
   　- 決めたいこと：記録の置き場所／必須項目／結果を書く担当と期限
2. logsの調整（重複防止）：フォーマット変更に合わせて一緒に対応
3. projects/mapping.md：「社内・ツール」表の置き場所を、logsの調整とあわせて相談
4. 会社概要・用語集：制作途中（進捗の共有のみ）

資料

• 提出資料との比較：https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026092402.html
  
• 前回（9/17）議事録：knowledge-hub の pluswork/Knowledge-mtg/2026-09-17_プレイブック昇格フロー・汎用性判定MTG.md

2026-09-17 ナレッジハブMTG — 話し合う内容と事前準備

開催情報

• 2026年9月17日（木）10:00〜（毎週木曜の定例）
• 主な議題：9/7の宿題「プレイブック昇格スコアの点数基準（合計点の閾値・段階分け）」「各指標の数値取得方法（GA4含む）」「MS側GA4のアクセス権」
• 提出資料：小林さん（ナレッジハブ改善3件）／米原さん（プレイブック点数ルール・GA4確認 MS案）／奈良さん（プレイブック昇格スコア リス案）

今日話し合う内容

1. 前提の共有：部署の違い＝流入元の違い - MS＝SEOで流入するサイト／リス＝リスティング広告で流入するサイト／アド＝アド広告で流入するサイト
- ナレッジハブ（ai/CLAUDE.md・projects/mapping.md・用語集）を読んでも、AIはこの区分を判断できなかった。会社概要・会社Wikiに部署ごとの「流入元・サイトの形・成果までの経路・数字を動かす外部要因・数値の所在」を揃えて書くヒントとして共有する

2. プレイブック昇格スコア（3案で方向性は大枠一致） - 一致：3項目×0〜2点／2点の線はCVR 1.1倍（+10%）／再現性は1回0点・2回1点・3回以上2点／合計5〜6点 即採用・3〜4点 情報追記待ち・2点以下 持ち越し（リス案）／効果量0点は対象外／AIが採点し人が確認
- 今日話せると進めやすい点：
- 汎用性の判定の軸（リス案＝A8ジャンル区分／MS案＝GA4来訪者属性の偏り／資料1＝対象状況）。9/7に「全員で揃える」と決まった項目
- 効果量で施策単体の数字をどう使うか、ページ全体の数字が0.95倍未満のときの扱い（9/7の「両方で判定」との関係）
- 確認したい点：
- リスの承認ベースCVと「1週間後に判定」の組み合わせ（承認がそろう時期）
- 件数（母数）が足りない結果の扱い（注釈のみ／暫定扱い／採点しない）
- 小規模案件で送客率をCVの代わりに使うか（リス案）
- 失敗施策（0.95倍未満）の記録（リス案）
- 再現性を数える単位（案件数／回数）と、再現性が点数として機能するか（リス案の論点）
- 施策の定義と、開始時に最低限記録する項目（本番反映日／施策前の数字と件数／変えた内容の分類）

3. ナレッジハブ改善（小林さん資料） - logsの重複：collect_sessions.py の原因（①ファイル更新日だけで当日分と判定 ②発言を日付で絞っていない）はコードで確認済み。補足として、セッションの発言時刻はUTCで記録されているため、日付で絞るときは日本時間に直す必要がある
- logsフォーマット：人の指摘・修正 を該当時のみにし、## 考察・学び を新設して閲覧サイト（site_build.py）で両方を抽出する案。## 判断理由 の扱い
- mapping.md「社内・ツール」の置き場所（サイト一覧の整理と合わせて検討）

本日の対応（Claude Code）

MTG資料の作成 - 資料1：reports/2026091701.html「2026年9月17日 ナレッジハブMTG 資料（Claude Opus 5作成）」
- 共有：AIがナレッジハブを読んでも分からなかったこと（部署＝流入元）
- プレイブック昇格スコア 確認シート：9/7の決定と未決事項、9/1〜9/7の5案（中田・小林・米原・奈良・Codex）の比較、28問の選択式（サイト種別ごとに回答可）＋AIの推奨＋試し採点、ナレッジ記録（logs）の改善5問
- 論点10件（観るべきポイント・論点の流れ・メモ欄）、メモのMarkdown出力、参照資料リンク25件
- 資料2：reports/2026091702.html「提出資料との比較（Claude Opus 5作成）」
- 3資料と資料1の一致点・違い8点と意見、話し合う点15問（各案の立場・選択肢・AIの推奨・メモ）
- 3人の提出資料（reports/data/20260917_01〜03.md）を、ページ遷移せずタブで切り替えて見られるビューア（初期表示は左固定、「フォーカス」でポップアップ）
- 比較の言い回しを、各案を否定しない表現に調整
- 提出資料の配置：01＝ナレッジハブ改善3件、02＝MS案、03＝リス案（ファイルの中身で確認）

確認した事実 - 既存の効果測定の記録（リス31行・MS施策ログ12件）から6件を試し採点し、件数・施策単体の数字・計測の揃い方の不足で確定は0件
- collect_sessions.py の重複の原因箇所（更新日の判定・発言の取り込み）と、発言時刻がUTCであること
- site_build.py の抽出対象は 人の指摘・修正 と ## ルール化すべきか の2か所のみ

注意点 - 資料の元にしたナレッジハブとWikiは手元のコピー（ハブ9/15頃まで、Wiki 9/8版）。ローカルのknowledge-hubはgitが壊れていて最新を取得できないため、再クローンが必要
- 資料内の「AIの推奨」はClaude Opus 5の参考意見で、PLUSの実績から算出したものではない

ナレッジハブ Wiki（plus_wiki）— やりたいこと・考え・ワークフロー・設計

コメント #1265（本日の作業予定）の前提になる考え方と設計をまとめます。#1265 は「今日やること」、こちらは「何を・なぜ・どう作るか」です。

1. やりたいこと

ナレッジハブ（knowledge-hub）に溜まっているルール・ナレッジ・案件情報・ツールを出典にして、案件を軸に横断して引ける Wiki を自分用に試作する。既存の PLUS Knowledge Wiki（https://plus-creative.xyz/nakata/plus_knowledge_wiki/
）は「ナレッジハブを作る過程」の記録で、今回は「ナレッジハブの中身」を読むための Wiki。うまくいけば、作り方と仕組みをチームへ共有する。

2. 考え

• 閲覧サイトと同じものは作らない。 既存の閲覧サイト（Cloudflare Pages）はナレッジをチーム別・時系列に並べる一覧で、それは既に足りている。Wiki にしかできない価値は「横のつながり」= 1 つの案件について、ナレッジ・案件ルール・部署ルール・ツールを 1 ページで引けること。
• きっかけは代打の入口が無かったこと。 remvy の依頼が担当者不在時に来たとき、必要な情報（経緯・メタリフ差し替え箇所・CDN 構成・ブランチ運用）はハブに揃っていたのに、案件単位で辿る入口が無く代打側が到達できなかった。
• 手で書くと腐る。 ナレッジハブは毎日 push で増える（最新コミット 2026-09-11）。AI が読んで書き起こす方式は翌日から古くなるので、リポジトリから機械的に作り直せる形にする。Wiki の本文は生成物、正本はあくまでリポジトリ。
• Wiki を作ること自体が点検になる。 案件別にまとめると、案件名の表記ゆれ（「FX比較」と「FXランキング」、「コスメ」と「コスメ第2アカウント」、「未分類」12 件）や mapping.md の未記入がそのまま見える。これは Wiki の副産物として価値がある。
• まず自分用。 利用者は中田のみ、ローカルのみ。既存 Wiki 本体・本番・ナレッジハブ側には手を入れない。

3. 材料（2026-09-15 時点の実測）

4. 大枠のワークフロー

[出典] knowledge-hub（git）            ← 正本。手で触らない

   │  git pull

   ▼

[生成器] build スクリプト（ローカル）

   │  frontmatter・mapping.md・ディレクトリ構造を読み、ページ用 Markdown を組み立てる

   │  案件名の表記ゆれは別名表（alias）で正式名へ寄せる

   ▼

[器] plus_wiki（WIKI_SYSTEM_BASE TYPE02 / PHP + SQLite）

   │  API（page.save）で書き込み。履歴・見出しアドレス・被リンクは Wiki 側が自動更新

   ▼

[利用] 人は画面で読む / AI には同じ URL に ?md=on を渡す

   │

   └─ 気づき（揺れ・未記入・足りない情報）→ 生成器か別名表を直す → 再生成

• 再生成は何度流しても同じ結果（冪等）にする。同じ入力で 2 回流したら 2 回目の変更は 0 件。変更があったページだけ保存するので、Wiki の履歴がそのまま「ハブの何が変わったか」の差分になる。
• 出典に無いことは書かない。各ページの出典欄にリポジトリ内パスとコミットハッシュを入れる。
• 認証情報らしき文字列を含む箇所は取り込まない。

5. 設計

器

• 参考ベース: /Users/nakatafumito/dev/PLUS/plus_knowledge_wiki/（PHP 7.2 互換に書き換え済みの TYPE02）
• 作成場所: /Users/nakatafumito/dev/PLUS/plus_wiki/
• ベースのデータ（ページ・見出し・リンク・履歴・ファイル・ログ）を空にしてから使う。表示名・分類・URL・API キーは新 Wiki 用に設定する。

ページ種別（生成器が作るもの）

生成のルール

• slug は出典から機械的に決める（例: 案件ハブ = ドメイン、部署ルール = パス）。人が付け直さない。
• 案件名の寄せ方は生成器の外に別名表として持つ（1 行 = ゆれた値 → 正式名）。寄せられない値は台帳ページに「未分類」として残し、ハブ側の修正は今回しない。
• 状態ラベルは Wiki の既定を使い、生成ページは「作成中」、手書きの「使い方」だけ「確定」にする。

試作の範囲と評価

• まず 3 案件（脱毛（remvy）＝きっかけ／FX比較＝件数最多 26 件／コスメ＝表記ゆれ検証）。
• 評価軸は 1 つ: 「remvy の依頼が来たとき、その案件ページ 1 枚を読めば代打が動き出せるか」。足りなければ、何が足りないかをハブへの改善提案として残す。
• 通ったら、生成器・別名表・手順書をセットにして共有する。

6. 今回やらないこと

本番公開／全案件の生成／ナレッジハブ側の表記ゆれ修正／チームへの共有（試作の評価後に判断）。

本日は、ナレッジハブ（knowledge-hub）のデータを出典にした Wiki を、自分用に試作します。うまくいった場合は、作り方と仕組みをチームに共有する前提です。本日は #492（ASP移行の確認作業）と並行して進めます。

目的

既存の PLUS Knowledge Wiki は「ナレッジハブを作る過程」の記録です。今回作るのは「ナレッジハブの中身」を読むための Wiki です。

既存の閲覧サイト（Cloudflare Pages）は、ナレッジをチーム別・時系列に並べる一覧です。今回の Wiki はそれと同じものを作らず、1つの案件について、ナレッジ・案件ルール・部署ルール・ツールを1ページで横断して引けることを価値にします。

きっかけは、担当者不在時に remvy の依頼が来た件です。必要な情報（経緯、メタリフの差し替え箇所、CDN構成、ブランチ運用）はナレッジハブに揃っていましたが、案件単位で引ける入口がなく、代打側がたどり着けませんでした。

前提

本日の作業

1. ベースを空にする

中田が用意したベースのローカルファイルを受け取り、中身を空の状態にします。

• ページ・見出し・リンク・履歴・ファイル・ログのデータを消し、空の Wiki にする
• アップロード済みファイルを消す
• 表示名・導入文・分類候補（config/wiki.php）と、URL・APIキー（.env）を新しい Wiki 用に設定する
• 消す前に、データベースの構造と初期データ投入の処理を読み、どのテーブルを空にするかを確定してから実行する
• 空にした後、ホーム・検索・履歴の画面がエラーなく開くことを確認する

2. ページ構成の設計

案件ごとに1ページを作り、関係する情報をそこに束ねます。

表記ゆれ一覧を独立したページにする理由は、案件名の値が64種類あり、「FX比較」と「FXランキング」、「コスメ」と「コスメ第2アカウント」のような揺れや、「未分類」12件があるためです。案件別にまとめる以上、どの値をどの案件に寄せるかを先に決める必要があります。

3. 生成の仕組み

手で書き起こさず、リポジトリから機械的に作り直せる形にします。ナレッジハブは毎日増えるため、手書きだと翌日から古くなるためです。

• ナレッジハブを読み、ページの Markdown を組み立てるスクリプトを作る
• 書き込みは Wiki の API 経由で行う。保存時に履歴・リンク・見出しが Wiki 側の仕組みで更新されるため
• 同じ入力で2回実行したとき、2回目の変更が0件になること（何度流しても壊れない）を確認する
• 認証情報らしき文字列を含む箇所は取り込まない

4. 試作の範囲

いきなり全案件は作らず、次の3案件で型を確かめます。

本日の完了条件

• 空のベースが動いている（ホーム・検索・履歴がエラーなく開く）
• 3案件のページが生成され、ナレッジ・ルールへのリンクがたどれる
• 表記ゆれ一覧ページができている
• スクリプトを2回流して、2回目の変更が0件

本日やらないこと

• 本番への公開
• 全案件の生成
• 案件名の表記ゆれをナレッジハブ側で直すこと（揺れを一覧化するところまで）
• チームへの共有（試作の評価後に判断）

2026-09-07 ナレッジハブMTG 記録（プレイブック点数ルール・結果収集）

開催情報

• 2026年9月7日（月）14:00〜15:00 札A・東B
• 参加: 小林・中田・米原
• 議事録: knowledge-hub の pluswork/Knowledge-mtg/2026-09-07_プレイブック点数ルール・結果収集MTG.md

決まったこと

1. 会社概要・共通用語の格納先は ai/（AIフォルダ） - 候補は company/ 新設・departments/common・ai/・ハブ直下の4案。AIが最初に読み込むファイル群である ai/ に置くと決定。
- 判断基準は「AIに話しかける前提として絶対に必要な情報＝ai/ ／ 特定業務でしかアクセスしない情報＝departments/ 配下」。
- 各事業部（リスティング／MS等）固有の用語は従来どおり departments/<部署>/ に残す。共通フォルダにまとめると不要な用語まで読み込むことになるため。
- 置くファイルは about.md（会社概要）と glossary.md（用語集）のセット。叩き台は米原さんが作成し、各自がレビュー・赤入れする。

2. プレイブック昇格スコアの共通大項目は3つ - 効果量／再現性／汎用性。各事業部で細かい数値基準は調整可という前提。
- 効果量は、施策単体の効果（見られた・押された等）とページ全体のCVの両方が基準を満たすかで判定する。
- 再現性は同様の施策で何回成果が出たかの回数ベース。汎用性はターゲット層の広さで、狭いターゲット限定の施策ほど点数が低い。
- 各項目0〜1〜2点の3段階評価で統一し、合計点で「即採用／情報追記待ち／持ち越し」等にレベル分けする方向。
- 現時点は3項目×0/1/2で合計6点満点の想定。ただし各段階の配点（2段階目を2点でなく5点にする等）と合計点の閾値・段階分けは次回に確定するため、あくまで仮の想定値。
- CV改善率の基準値は当初20%案が出たが、高すぎるとの意見が出て10%前後で再検討することになった。

3. 「検証の質」は独立した点数項目にせず、ルール側で担保する - データの信頼性・期間はスコア項目に入れない。代わりに、効果測定は施策から2週間経過後のデータのみを対象にする。

4. 単独施策か複数施策の組み合わせかは点数に含めない - MS側は複数施策を組み合わせて実施することが多く、評価軸に入れるとリスティングと足並みが揃わないため。参考情報としてプレイブック側にタグ・記録として残す。

5. 結果収集の現状 - リスティング側は構築済み。依頼受領→実装→1週間後の効果測定までを一連の流れとして都度AIに共有する運用（依頼内容・修正内容・作業完了報告を都度共有 → 1週間後に自動リマインド → GA4連携で数値を自動取得）。
- MS側は同様の仕組みが未整備。検討時に使うデータ（記事内容、サーチコンソールのキーワード一覧、ヒートマップのスクショ等）をまとめて渡す運用と、メモが複数ツールに分散している問題の解消は持ち帰り検討事項として残った。

6. GA4アカウントの共有 - MS側の担当者からリスティング側へGA4アカウントを共有する必要があるが、個人アカウント追加では権限が足りない。最終的にはワークスペース（グループ）単位でのアクセス権管理へ移行予定。
- 移行が完了するまでの暫定対応として、2段階認証つきの共有アカウントで対応する。

7. ツール／コマンドのレビュー - ツールとコマンドは意味合いが近く混在しているため、今後レビュー会を行う場合は「ツール」だけでなく「コマンド」も対象に含める。
- 各自が作った便利なコマンド・スキルのうち、他事業部にも応用できそうなものを共有していく方向を確認。

8. 定例MTGを毎週木曜10:00に固定

次回MTG

• 2026年9月11日（木）10:00〜 札B・東A
• メイン議題: プレイブック昇格スコアの数値取得方法のすり合わせ

次回までにやること

• 効果量／再現性／汎用性の点数基準の詳細（各段階の配点・合計点の閾値・段階分け）を各自持ち寄る
• 決めた指標の数値をどうやって取得するか（GA4での実際の取得方法を含む）をMS側含めて確認・共有する
• MS側のGA4アカウントアクセス権の確認・付与を進める
• 会社概要 about.md・用語集 glossary.md の叩き台展開と、各自のレビュー・赤入れ
• 事前資料がある場合は、会議の1時間前程度など早めに共有する

未決のまま残っている点

• 各段階の配点と合計点の閾値・段階分け
• CV改善率の基準値（20%案 → 10%前後で再検討）
• 例外昇格ルール（突出した成果の即時昇格）の要否。資料間で記載が割れている（アクションプランは「追加する」、奈良さんのスコア案は「9/1合意の例外ルール」として記載、小林さんの気づきメモは「スコア設計上不要と判断」）。9/7では決着していない。
• MS側の結果収集フローと、メモが複数ツールに分散している問題の解消
• 数字待ちの施策（保留プール）を誰がどう埋めるか

記録の反映先

• ナレッジハブのプロジェクトページに、9/7の決定8件・MTG履歴・現在値・未決論点を反映済み。
  https://plus-creative.xyz/nakata/plus_ai_intro/projects/detail.php?slug=knowledge-hub
  

参考（9/7に用意された資料）

• MTG議題: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090705.html
  
• 話し合い用資料: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090708.html
  
• 共通用語・基礎ナレッジ整理案: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090707.html
  
• 3ステップへの意見メモ: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090706.html
  

※本コメントは2026-09-07 MTGの記録です。次回で確定する項目は決定事項ではなく未決として記載しています。

本日9/7（月）の予定：ナレッジハブMTG・事前準備

MTG前の準備

• 9/1 MTGの記録とナレッジハブの現状を確認し、今回決める論点を整理する。
• Playbook昇格ルールの点数指標・閾値の案をまとめる。前回案の「反復性・共通性・重要性・再現性・根拠」を参考に、候補抽出から人の確認・正式化までを検討する。
• 施策結果の収集が漏れない仕組み（記録対象、収集タイミング、担当、結果確認の流れ）を検討する。
• Codexの提案を載せ、中田が後から自分の考え・採否・理由を追記できる検討用HTMLレポートを作成する。追記後は内容を読み取り、MTGで提示する最終案へ整理する。
• レポートは YYYYMMDDNN.html で版を分け、入力の保存と次回の読み取り手順も整備する。

ナレッジハブMTG

• 日時：2026年9月7日（月）14:00〜15:00
• 場所：札A・東B
• 主な議題：①Playbook昇格ルールの点数指標案 ②施策結果の収集漏れを防ぐ仕組みについて、各自の案をすり合わせ・合意する。
• 関連する未決論点：PLUSの会社基本情報・事業部略称（MSなど）をAIへ共有する正本と更新方法。

MTG後の予定

• 決定事項・未決事項・担当・次のアクションを整理し、タスクとプロジェクトの記録へ反映する。

※本コメントは本日の作業予定です。レポート完成・ルール合意・MTG実施済みを示すものではありません。

参考：
https://plus-creative.xyz/nakata/plus_ai_intro/projects/detail.php?slug=knowledge-hub

https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090103.html

9/1のナレッジハブMTG

マッピングについて

すでに各自で追加済。

https://github.com/plus-company/knowledge-hub/blob/main/departments/lis/designer/mapping.md

https://github.com/PLUS-Company/knowledge-hub/blob/main/departments/ms/designer/mapping.md

MTG中にこのマッピングが効いているか試したところ、しっかりAIは質問に対しての回答の情報を出力してくれた。

その他マッピングのテストのため質問したところ、
「MSの〜〜〜ルールはなんですか？」
このMSをマイクロソフトの略と勘違いして対応した。

PLUSの中でMSはマーケティングソリューション部、略してMSと呼んでいるが、その文脈をAIに伝えていない。
会社の基本情報を入れてしっかりAIに理解させることが必要かも。
どんな事業部があって、どんな業務で、何で売上をあげているか。会社の歴史や運用しているサービスやサイトなどなど、目標やビジョンなども含めてAIに伝えて、その背景情報に合わせた角度でそれを踏まえた回答が求められるので、共有するためのことを考える。

プレイブックの昇格ルールについて

プレイブックの育て方.html

AIによるプレイブック昇格の仕組み案
https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090103.html

AIに昇格ルールを伝え、あるトリガーで自動でクロールさせ、情報収集させ、ナレッジやログからプレイブックに昇格させるロジックを自動でさせたい。

様々な項目に点数をあたえてスコアが閾値を超えたら昇格するなどの仕組みがどうだろうかというながれ。
次回その点数つけについて考える。

次回ナレッジMTGは以下の日時で設定済みです。

9/7(月)14:00〜15:00　札A・東B

※ご都合合わなければご連絡ください

▼次回までにやること
・Playbook昇格ルールの点数指標案を考える（参考：https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026090103.html
）
・施策の結果収集が漏れない仕組みを考える

▼次回MTGでやること
・それぞれ考えてきた案のすり合わせ・合意

資料：
https://plus-creative.xyz/nakata/plus_ai_intro/reports/20260901001.html

1.内容の深堀り

2.回答のシンプル化

3.資料に落とし込み

プロジェクトページ：
https://plus-creative.xyz/nakata/plus_ai_intro/project/detail.php?id=1

9/1 ナレッジMTG 事前準備: 意見プラットフォーム作成

次回MTG（9/1 火 11:00〜12:00 札B・東B）に向けた意見まとめページを用意しました。
https://plus-creative.xyz/nakata/plus_ai_intro/reports/20260901001.html

各項目にAI（Claude）の回答案を記載済み。アコーディオン形式で、各項目に追記欄あり。MTGまでに意見を思いついたら随時追記していく運用です。

■ このレポートで考える項目

【1. index各チーム】ナレッジハブに情報はあるがAIが辿れなかった→目次(INDEX.md)を作る
- 置き方の基本形（全体トップ=既存ai/CLAUDE.md流用+チーム別INDEX.mdの2階層、「いつ読むか」列つきの3列表）
- 目次を腐らせない運用ルール（追加と同時に1行追記の必須化+機械検知）
- エンジニアチーム分の具体案（中田=tools/とASP系、奈良さん=lis/engineerの分担案）

【2. playbook昇格ルール】現状0件をどう動かすか
- 昇格の発火条件（記録の「ルール化すべきか」欄+同種の対応が2回）
- 判定と作業の分担（候補集めはAIが週次で自動リストアップ、週次MTG最初の5分で人が承認、移す作業はAI）
- playbookファイルの型（状況→判断→根拠の1パターン1ファイル）

【3. AIルール決め 21項目の回答案】疑問一覧（2026082501）の全項目に回答案を用意
- 記録: 対象範囲の1行定義 / push前の本人確認 / 遡及記録の条件つき容認
- 振り分け: 兼務者は主務固定 / 案件名はAI追記+週次事後承認 / 昇格判定会 / アーカイブは当面保留
- メンテナンス: 削除手順 / ルールの最終確認日 / mapping穴埋めの担当 / 索引ズレ検知
- AIの権限: 階層ごとの書き込み可否マップ / 直接push継続（ai/のみPR） / AI禁止操作6項目の集約
- 環境: Sonnet推奨維持 / セットアップ完了のその場確認 / 作業前pullは現状維持
- ツール: 命名規則は奈良さん案採用 / 単体リポジトリ+tools/mapping台帳（集約案への対案） / MS・PLUS使い分けの追認

ナレッジハブ運用MTG 実施メモ（2026-08-25 11:00〜12:00 札B・東B）

正式議事録: knowledge-hub/pluswork/Knowledge-mtg/2026-08-25_ナレッジハブ運用MTG.md

■ 使用した資料
- AIが持っている疑問一覧: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026082501.html

- 自分用メモ: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026082502.html

- ディレクトリ構成案（コード表示）: https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026073003.html?mode=code

- タスク管理サンプル: https://plus-creative.xyz/nakata/task_kanri_sample/projects/detail.php?id=2

■ 課題の整理（2点）
1. 入っている情報の量・質が不足
2. インデックスが無くAIが情報を見つけられない（フォルダ構成はあるが「どこに何があるか」の目次が無い）

■ 決定事項
- 今回やることは2点に絞る: ①インデックス作成（全体トップ＋各チームの2階層） ②playbook昇格ルールの整備
- ルールは1人がリードせず、各自が案を作り実践して持ち寄る方式
- 「AIが持つ疑問一覧」の他の論点は随時消化（今回は保留・優先度低）

■ 対応済み（MTG当日）
- tools/ フォルダ新設（projectsと同等構成・tools/mapping.md）: https://github.com/PLUS-Company/knowledge-hub/tree/main/tools

- 社内ワーク用 pluswork/ 新設（過去MTG議事録を遡及配置）: https://github.com/PLUS-Company/knowledge-hub/tree/main/pluswork/Knowledge-mtg

- 中田の7〜8月分ナレッジ18件を knowledge/logs/engineer/ へ遡及反映済み

■ 次回MTG: 9/1(火)11:00〜12:00 札B・東B
▼次回までにやること
- 各事業部ごとのindex案
- playbook昇格のrule案
▼次回MTGでやること
- それぞれのルールでナレッジを他の人も引き出せるようになっているか検証

(1) ディレクトリ構成
(2) スキルズのヘッダー、中身、構成
(3) ナレッジの中身・構成・書き方

--
https://plus-exciting.slack.com/archives/C01ULPA2YHL/p1783925564895329?thread_ts=1783044102.975329&cid=C01ULPA2YHL

ナレッジハブ説明資料
https://plus-testing.com/nara/knowledge-hub/guide/

https://plus-testing.com/nara/knowledge-hub/engineer/

方向性の参考？
https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026070903.html

参考：
米原さんの資料をみてAIがレポートしたもの
https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026072302.html

奈良さんのサーバーの要件定義を見てAIがレポートしたもの
https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026072303.html

https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026072301.html

[11:29]https://plus-creative.xyz/nakata/plus_ai_intro/reports/2026072303.html

Knowledgeハブを利用した指示イメージ：

siteAにXXXXXXをするタスクを行います。

/xxxxxx/siteA/
のサイト情報を理解して

/xxxxx/yyyyy/skills/xxxx.md
を読んで作業をしてほしい。

/xxxx/yyyy/cccc/xxxxx.txt
にリストアップされている画像を
GPTに作らせて用意して　

完成させて。 （編集済み） 
10:50Knowledgeハブへ、資料やSkillsや情報をどこに格納し、
(2)Knowledgeハブを利用した、AIへの指示の仕方、ワークフロー

が決まれば良い？
[10:55]- 黄色のカードを整理してナレッジハブに格納
- この全体のフロー説明したSkillsを格納[10:56]ルール・フレームワーク化

AIへ情報渡したら振り分けてくれる仕組みだが、箱を増やすとAIが理解していないので無視される？

→AI（チーム）が理解できる、共有できるフローがあれば大丈夫そう？

メモ（2026-07-22 検討内容）

1. 奈良さんからの共有: 閲覧手段の移行検討

• ナレッジハブの閲覧手段を GitHub Wiki から Cloudflare Pages（静的サイト）へ切り替える技術要件が共有された。
• 構成: Pythonで静的HTML生成（site_build.py 新設）/ Tailwind CSS / PHP不使用で確定 / git push 自動デプロイ / 認証は Cloudflare Access（社内限定、当面メールOTP+会社ドメイン、Google Workspace 導入後はSSOへ切替検討）/ 既存Wikiは廃止（データ移行不要）。
• 位置づけ: 7/16 の次回アクション「奈良さん: サーバー・保存方針などシステム部分の検討継続」の成果物。knowledge-hub 未解決項目だった「private Wiki の検索性」への回答にもなる。
• 議題（未定4点）: 独自ドメインの要否 / 認証の代替手段 / UIの作り込み度合い / 静的HTML出力先のディレクトリ構造。

2. 中田側の見解（返答方針）

• 方向性は賛成。技術選定は要件（無料・自動デプロイ・アクセス制御）に合っている。
• 独自ドメイン: 当面 pages.dev で開始し、社外共有の本格化時に検討で十分。
• 認証: Cloudflare Access 案のままで問題なし。外注・インターンはメール個別許可で対応可。
• UI: 最小限で開始し、まず全ページの一覧・検索を優先。作り込みは使われ方を見てから。
• 出力先・ディレクトリ構造: 生成側で決めず、ソース側（knowledge/ のフォルダ分けと各ファイルのメタデータ）を先に決め、site_build.py はそれを反映するだけにする。役割×チームのマトリクス（7/21 デザイナー資料）をフォルダ/タグ基準に使い、各Markdownヘッダーに役割・チーム・公開可否フラグを持たせれば、社内/社外共有ページの出し分けと「斜め横断」参照が同じ仕組みで解ける。7/23 でこの基準を一緒に詰めたい。
• 確認事項: Wiki廃止後、AIの日次自動蓄積フロー（main直push）と Pages のビルドトリガーが両立するか。Wiki同期ロジックの置き換え方針も要確認。

3. INBOX機能の移植設計（見本実装より）

• 見本実装のINBOX（ https://plus-creative.xyz/nakata/plus_ai_intro/inbox/
  ）を検討。仕組みは「捕獲（人は貼るだけ・分類不要）→ AIが振り分け（Wiki化/Task化/Source化/Decision化/追記を判断して成果物作成）→ 痕跡（何になったかの参照と処理メモを必ず記録）」の3段。
• 振り分け成果物の例: https://plus-creative.xyz/nakata/plus_ai_intro/wiki/view.php?slug=plus-company-current-understanding
  
• 評価: 7/16 の課題「振り分け未実装・貯めるだけ」への直接の回答部品。投入の摩擦が最小のため記録が続き、「記録するほどでもない断片がローカルにしか残らない」問題も解消できる。
• knowledge-hub への移植方針: DB・PHP・常駐APIは持ち込まない。①inbox/ フォルダに1メモ1ファイル（ヘッダーに状態・優先度・振り分け先候補・処理結果参照・公開可否）②投入用コマンド1本 ③処理は退勤前の「今日の記録をして」に1手順追加、の3点セットで実現。Cloudflare Pages 方針（PHP不使用）と非互換なし。閲覧は site_build.py に inbox 一覧ページを1枚追加。
• 調整が必要な差分: 処理トリガーの固定（退勤前+週次残量確認）/ 命名・ヘッダー規約の明文化 / 公開可否フラグの追加 / 振り分け先を knowledge・projects・rules の3択に読み替え（Wiki廃止対応）/ Pagesビルド頻度との整合（要奈良さんすり合わせ）。

4. 7/23 MTG に向けて

• 実物INBOXを動くデモとして見せ、knowledge-hub への移植は上記3点セット案で提案する。
• 米原さんの作業フロー叩き台には「入口はINBOXに統一する」という観点で接続する。
• ディレクトリ構造・公開可否フラグの基準は奈良さんの出力先設計の議題と合流させて詰める。

ナレッジベース化の経緯まとめ（2026-07-21時点）

経緯（MTG4回）

• 6/25: ナレッジをGitHubプライベートリポジトリ1箇所に集約する方針を決定。エンジニア側（中田・奈良）が先行検証しデザインチームへ展開する分担。3層構造案（基礎情報 / ルール / 施策結果）を共有。
• 7/2: 両チームの現状共有。エンジニア側はrules・skills・作業記録の運用、デザイン側はタスク書き出し→AIに相談・チェックの実態。宿題は「自分の作業のAI化に必要なナレッジの洗い出し」。
• 7/9: 奈良さんが統括リポジトリ knowledge-hub とWiki（AI自動蓄積）を公開。チーム向け手順書とエンジニア向け資料を共有。デザイナー側は運用全体像（CLAUDE.md + commands + memory6フォルダ + スキル10個）を共有。
• 7/16: 進捗共有・ナレッジハブ説明・活用と役割分担の5部構成で実施。詳細は下記。

7/16 MTGの要点

• 目的のズレが判明し2軸に整理: ①ルール・権限・ポリシーのナレッジ化（属人性排除）②勝ち筋の蓄積（成果データに基づく最適解）。コーディング側は①先行・②手薄、デザイン側は②先行・①手薄という非対称も判明。
• 権限の論点が新規追加: デザインマニュアルは概ね公開可だが、運営サイト名・ドメインアライアンスは社外秘。コーディング/ドメイン権限とデザイン権限は分離。公開可否フラグの自動付与案。
• 現状の限界: 自動振り分けは未実装で「貯めるだけ」。Wikiとして使える形への加工が課題。
• 進め方: マーケター領域まで広げず、エンジニア+クリエイティブで小さく試す。「見せ合うだけの会」を避け、一人の叩き台に全員で指摘する方式に合意。

7/21 受領: デザイナー資料「ナレッジベース_使用イメージ」（全3ページ）

• P1: 「作業効率化」と「勝ちパターン出力」の2フローを図解。両フローともフィードバック記録で新ナレッジに還元されるループ。+αとして社外向け閲覧ページ共有案（運用サイト名等はタグ等で切り離す）。
• P2: 役割（エンジニア/デザイナー）×チーム（MS/リス/アド）の領域マトリクス。役割ナレッジはエンジニア側「概ね固まっている」・デザイナー側「まだあやふや」。疑問MEMO: 縦/横の切り分けだと斜めの横断（例: リスチームがMSデザイナーの成功例を引く）ができないのでは?
• P3: 個人の現状申告。ナレッジは各領域とも蓄積中（Claude経由）、出力（AIにメイン作業を任せる / 勝ちパターンの組み合わせ出力）は未達。
• 7/16で整理した2軸と図解が一致しており、認識は収束傾向。マトリクスはフォルダ分け基準の議論にそのまま使える。斜め横断の疑問は、各ファイルにチーム/役割のメタデータを持たせればAIの横断検索で解消可能（見込み）。

現在地と残課題

• 到達: Phase1（集約）基盤の稼働（リポジトリ+Wiki+手順書）/ 目的の2軸整理 / 進め方の型（叩き台方式）。
• 残課題3点: ①振り分け未実装（貯めるだけ）②権限設計（公開範囲の線引き・フラグ方式）③勝ち筋の記録フォーマット未定。

次回（7/23木・同時間）

• 米原さん: 作業フロー叩き台を会議前に事前共有 → 当日それをベースに議論。
• 奈良さん: サーバー・保存方針などシステム部分の検討継続。
• 中田: 叩き台への指摘観点の整理 / 権限・ディレクトリ構成の論点準備 / 勝ち筋の最小フォーマット案（施策・数値・判断理由の1施策1ファイル）を用意して臨む。

自身のタスクでのワークフローにAIの活用やナレッジ活用する場合どうなるかを言語化