スクラムの文献でLLM Wikiを作る - コンテンツをどう活かすか

Cover Image for スクラムの文献でLLM Wikiを作る - コンテンツをどう活かすか
mo
monotalk

文献の選定、用語や概念の抽出、そしてインジェストパイプラインと構文リントの整備を経て、Scrum Literature LLM Wikiの土台が整いました。

前回の記事（Lint）に続くステップとして、今回は「こうして構築したコンテンツを、現在のところどのように活用しているのか」という実践について書きます。

読み手の整理：人間とAIエージェント、それぞれが求めるフォーマット

まず、このLLM Wikiの読み手には2種類存在すると整理しています。 **「人間」と、Claude CodeやGitHub Copilotといった「AIエージェント」**です。両者では必要とするフォーマットやコンテキストの前提が異なります。

  • 人間のためのフォーマット

    • 人が読むためのフォーマットであり、現在は静的サイトジェネレータを介してHTMLで閲覧するWebページを想定している。
    • Markdownが一次コンテンツであり、ブラウザなどのアプリケーションを通じて人間が探索しながら読むため、コンテキストウィンドウの制限を気にする必要がない。

  • AIエージェントのためのフォーマット

    • AIエージェントが効率的に処理できる構造化されたフォーマットである。
    • JSONやYAML、あるいはMarkdownが適している。人間向けのHTMLをそのまま読ませようとすると、タグなどのノイズが多くコンテキストサイズの肥大化を招くためである。

一次ソースであるMarkdownから、人間にはWebサイトとして配信し、AIエージェントには別のアプローチで届ける必要があります。

AI用インターフェースとしてのMCPサーバー

Webサイト上のHTMLを直接AIに読ませると、コンテキストを著しく圧迫してしまいます。そのため、AI向けの専用窓口（インターフェース）としてMCP（Model Context Protocol）サーバーを定義しています。 MCPサーバーに持たせるべき基本的なインターフェースとして、以下の3つを実装しました。

  1. look_up_scrum_terms: 用語・概念・ルールを「引く」（id指定でピンポイント取得、query指定で横断検索の両方を透過的に処理）。
  2. consult_on_a_concern: チームの課題・悩みを「相談する」（現場の問いカタログから打ち手と文献を提案）。
  3. review_sprint_board: 手元のボードデータ（NotionやGitHub）を渡し、スプリントの状況を「点検する」。

これらに加え、Wiki本来の構造を活かすために「ページ同士の関連性を示すデータ」を持たせることが必要になります。

検索（Query）の限界と、階層化されたYAMLによる自律探索

MCPサーバーのクエリ機能について考えていくと、単純なコンテンツ検索の限界が見えてきます。 検索クエリを投げてヒットしたページをまとめて返すことは可能です。しかし、それを受け取った側のAIエージェントは、検索結果として渡された複数のページ群から「どの情報が本当に必要なのか、どう活かせばいいのか」を判断しづらいという問題が生じます。 そこで重要になるのが、コンテンツを取得した際に、単なる本文テキストだけでなく「構造化されたメタデータと次の探索導線」をあわせて返すことです。 このサーバーでは、Wikiのフロントマターやオントロジー情報をもとに、以下のようなメタデータをページのヘッダー部として整形して返しています。

  • 概念の分類・階層: カテゴリ、タグ、およびオントロジー上の上位クラスや祖先チェーン
  • 関心のスコープ: そのページが扱う公式定義や対象範囲
  • 次の一歩となる具体的なツール呼び出し: 関連する別ページや検証ルールを開くための記述

エージェントは返されたYAMLの階層構造を読み取ることで、上位クラスや関連概念を把握できます。その構造をもとに「次にどの問題を検索し、どう対処すべきか」をエージェント自身が判断し、必要な情報を自律的にたどりに行くことができます。

以下は、MCPサーバー経由で「PO」を検索したときの戻り値データのサンプルです。

  {
    "aliasNote": "「PO」を「プロダクトオーナー」として検索しました。",
    "question": "PO",
    "contexts": [
      {
        "source": "guide",
        "title": "Scrum Guide 2020",
        "section": "プロダクトオーナー",
        "citation": "『Scrum Guide 2020』プロダクトオーナー",
        "content":
"プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。...",
        "score": 0.95
      }
      /* ... 複数ガイドの引用チャンク（省略） ... */
    ],
    "resolution": {
      "method": "search",
      "status": "fallback",
      "suggested": [
        {
          "slug": "concepts/product-owner",
          "title": "プロダクトオーナー (Product Owner)",
          "kind": "concept",
          "open": "look_up_scrum_terms(id=\"concepts/product-owner\")"
        }
      ]
    }
  }

未知のプラクティスへのフォールバックとサジェスト

登録されている事例や論文由来の情報にない事象については、当然ながら直接の回答ができません。 この課題に対して、フォールバックの仕組みを用意しており、「もしかしてこれのことかな?」という候補を提示できるようにしています。そこで関連する情報が引っかかった場合は、AI側から「では、こちらの観点はどうですか?」と横に広がる質問やサジェストがなされ、探索を広げられるようにしています。

チャンクに検索をかけて、ヒットが0件だった場合にフォールバックが走り、suggestした内容を返すようにしています。

MCPサーバー側にしかないもの：SROルールと概念リントツール

WebサイトやMarkdownファイル群には文献知識が書かれていますが、MCPサーバー側にしか準備していないツールがあります。 それが、SROのルールとそのルールに基づいて検証する一連の処理（概念リントツール）です。 現場のデータが「概念に照らし合わせて正しいかどうか」を判定するためのツールreview_sprint_boardをMCPのインターフェースとして組み込んでいます。

GitHubデータをインプットにした検証と、AIからの「質問」

検証ツールへのインプットとしては、GitHub IssuesなどのプロジェクトデータをJSON形式で受け取る形を想定しています。 ただし、GitHubのプロジェクトデータだけでは、SROが示している問いやルール（例：レトロスペクティブで決まった改善タスクなのか、チームの自律的な判断なのか等）にすべて答えられるわけではありません。 そこで、データのみでは判定できない部分については、「AI側から人間に質問を投げかけ、問いを通じて不足している文脈を埋める」という形をとっています。 SROのプロセスリントでは以下の内容を確認しています。

### SROがチェックする4つの柱

   1. 計画の基本はあるか？  ── 「何をもって完成とするか（受け入れ条件）」が決まっているか
   2. 完了に嘘はないか？    ── 条件を満たしていないのに「完成（Done）」にしていないか
   3. 実態と乖離していないか？── スプリント外の勝手な作業や、計画外のタスクが混ざっていないか
   4. プロセスが健全か？    ── 振り返りで改善が出ているか、自律性や心理的安全性はあるか
 ──────
 ### 具体的なチェックポイント

 #### ① 計画と構造のチェック（S系）

 • 受け入れ条件はあるか？: 何を満たせばOKなのか曖昧なストーリーを検知（「作ってから考える」の防止）。
 • タスクに分解されているか？: スプリントバックログに実行可能なタスクが用意されているか。
 • 体制・イベントが揃っているか？:
 役割の欠落や、4大イベント（プランニング・デイリー・レビュー・レトロ）の実施を確認。

 #### ② 実績・完了の正当性チェック（R系）

 • 未完成のまま出荷していないか？: 受け入れ条件を満たしていない成果物が「完成」と扱われていないか。
 • 失敗・中断した成果物が紛れていないか？: 途中でボツになったコードやタスクが、成果物に誤混入していないか。
 • 計画外の作業が暴走していないか？: スプリントの計画に含まれていない勝手なタスクが実行されていないか。

 #### ③ プロセスの健全性とアンチパターンのチェック（E系）

 • 改善が形骸化していないか？: レトロスペクティブで具体的な改善アクションが出ているか。
 • フィードバックを受けているか？: レビューに外部ステークホルダーが参加しているか。
 • アンチパターンはないか？: デイリースクラムへの外部者の不適切な介入や、ベロシティのノルマ化を検知。

 #### ④ 組織・文化のチェック（ガイドライン）

 • 自律性: タスクが上から一方的に割り振られておらず、開発者が自ら選択してコミットしているか。
 • 支援と心理的安全性: 管理職がマイクロマネジメントではなく障害排除に動き、ミスを責めない環境があるか。

「コーチ」としてのトーン

検証ツールがSROルールに基づいて違反や警告を出したときの警告文は少し柔らかい言葉を使うようにしました。 違反をユーザーへ突きつける形になるため、MCPサーバーから配信するスキルやプロンプトでは、「対話し、改善をサジェストするトーン」を意識させています。

コンテンツ活用をしてみての感想

以下、LLM Wikiのコンテンツを活用してみての感想になります。

AI経由での利用に対する手応え

  • AIがMCPサーバーを叩いて（引いて）使う形が最も効果的だと感じた 人間が直接読むためのUI以上に、AIエージェントがMCP経由で知識やリント機能を呼び出し、人へ説明・仲介する構成に確かな手応えを感じました。 ナレッジのリポジトリへクエリを投げて情報を取得し、AIにまとめてもらった内容を人が理解する、という使い方が有効だと感じました。

SRO（オントロジー）と現場の適合性・活用法

  • SROのすべてをそのまま現場に適用できるわけではない SROには、スクラムガイドには定義がない要素（工数ログやアトミックユーザーストーリー）もモデリングされているため、チームによって運用の実態が異なると感じました。 実際にLLM Wikiの開発はカンバンを用いていたため、個人の開発でのプロセスリントがかけられず、カンバンのオントロジーとプロセスリントで状況を確認していました。

  • 「プロセス見直しのきっかけ」としての価値はある SROにも価値はあり、全てをそのまま適用できなくても、形式的にルール化された定義を通すこと自体が、「自分たちの開発プロセスを客観的に見直すためのきっかけ」として有用に思いました。 アセスメントの1つとして活用できると思いました。

  • チーム専用オントロジーという展望 定義の作成自体はLLMに任せられます。自分たちのチームや会社の文脈に合わせたオントロジーを形作り、ルールや流儀に沿っているかを確認する「チーム自己点検用の道具」として育てるアプローチは、非常に有意義であり実現可能だと考えています。

スクラム実践研究論文の限界と、必要な学習領域の広がり

スクラムの実践研究で、スクラムチームやスクラムマスターの課題が解決できるかというと、そうでもないことがわかりました。

  • スクラム関連の実践研究論文だけでは、現場が抱える問題のすべては解けない プロセスの実践研究論文だけではカバーしきれない問題が現場には多数あるなと感じました。 実際にスクラムマスターが直面する課題には、「人のコーチング」や「組織力学・チームサイエンス」に関わるものもあります。スクラム文献だけではなかなか解決事例が見当たらないため、スクラムの文献にとどまらず、そうした隣接する領域の知見も幅広く追っていく必要があると実感しました。 ただ、それだとスクラム文献のLLM Wikiというアイデンティティから離れていってしまうため、どうすれば良さそうか? 取るべき文献の軸は検討が必要だと考えています。

以上、LLM Wikiのコンテンツ公開と活用してみての所感でした。

LLM Wikiについては一通り書いた気がしていますが、何かトピックがあれば今後も少し記事を書いてみようかと思います。

関連記事

コメント