# AIのしくみ

PM on RailsのAIは、ためた情報を**バラバラの文書ではなく、意味のつながりを持った形**で扱います。だから、普通のキーワード検索や汎用チャットよりも、「あなたのプロジェクトの事実」に基づいて的確に答えられます。

![PM on RailsのAIアシスタント。会話の下に確認カードが出ていて、資料を添付すると要求・確認事項・タスクは確認カードを承認したあとだけ作られる。導入前は資料を読み直して未決を手で拾っていた。導入後は確認して実行するだけで整理が始まる。](https://pmonrails.com/docs-img/chat.png)

## 普通の検索・汎用チャットとの違い

- **つながりで辿って答える** — 例:「ログイン要求はなぜ必須なの？」と聞くと、元になった打ち合わせの発言や、過去の似た判断まで遡って答えます。キーワード検索だと「ログイン」を含む文書が並ぶだけです。
- **意味で見つける** — 例:「認証まわりを強くしたい」と書いても、「ログイン改善」「パスワードの安全性」のように言葉の違う関連要求を拾います。[確認事項](https://pmonrails.com/docs/clarifications.md)の本文も検索対象に含まれ、未回答の質問を会話から辿れます。
- **根拠つきで答える** — 例: 回答に「（要求カード〇〇より）〜という発言があった」と引用元が付きます。引用は実データから取るので、ありもしない出典は出しません。
- **使うほど合ってくる** — 例: いつも採用している種類の候補を、次回から上位に出すようになります。
- **安全** — 例: プロジェクトAで検索しても、プロジェクトBの要求や、自分に閲覧権限のない議事録は出てきません。

## なぜ「つながり（グラフ）」で持つと的確なのか

PM on Railsは、情報を表（行と列）ではなく、**点と線のつながり（グラフ）** として持っています。具体的には、次のような場面で役立ちます。

- **影響範囲がすぐ分かる** — 例:「在庫数の扱い」という要求を変えたら、配下の3つのストーリー・8つのタスク・2つの受入シナリオが影響する、と一覧で出ます。表ツールなら一つずつ見比べる作業です。
- **何段も先の関連をたどれる** — 例: 目の前のタスクから「これはどの要求から来たの？」を、タスク → シナリオ → ストーリー → 要件 → 要求まで一気にたどれます。
- **「なぜ」を遡れる** — 例: 完成したタスクから、その仕様にした理由（元の発言や採用の判断）へ逆向きにたどって根拠を示せます。
- **後から関係を足しやすい** — 例:「このバグはこのシナリオに影響する」というつながりを、後から線で結ぶだけ。データの作り直しは要りません。

表形式のツールでは、これらは毎回手作業で見比べることになります。つながりで持つことで、AIも人も「関係をたどる」だけで答えにたどり着けます。

## 情報は古くなる — 鮮度との付き合い方

ためた情報は、時間が経つと実態とずれていきます。担当者が変わった、方針が変わった、仕様を作り直した。こうした変化のあとも古い記録は残るため、放っておくとAIの回答や検索結果に「昔の話」が混ざることがあります。これはどのツールでも起きる自然な現象で、次のように付き合うのがおすすめです。

- **取り込み続けるほど新しくなる** — 議事録や資料を継続的に取り込むと、新しい情報とのつながりが増え、AIは最新の判断を優先して拾いやすくなります。「最初に一度だけ入れて終わり」にしないのがコツです。
- **引用元で「いつの情報か」を確かめる** — AIの回答には引用元が付きます。回答が古く感じたら、引用元をたどって元の議事録や要求カードの日付を確認してください。
- **終わったものはアーカイブする** — 使わなくなった要求カードやストーリーはアーカイブしておくと、一覧や集計から外れて情報が整理されます（過去の経緯としては残ります）。
- **おかしい回答を見つけたら元を直す** — 回答の引用元が実態と違っていたら、その要求カードやドキュメント自体を更新するのが根本的な対処です。次からの回答に反映されます。

## ナレッジグラフを手入れする

AIの精度を保つには、グラフを「作って終わり」にしないことが大事です。PMは次の運用を定例の確認に入れておくと、後から開発者がMCPで辿ったときにも迷いにくくなります。

- **新しい一次情報を入れる** — 定例会議の議事録、仕様変更メモ、確認事項への回答、設計判断は、発生したタイミングで取り込みます。古い要求を直すだけでなく、新しい根拠をグラフに足します。
- **引用元と日付を確認する** — AIの回答が怪しいときは、回答そのものではなく引用元の文書・要求・判断の日付を見ます。古い根拠を参照しているなら、最新の要求カードやDecisionを追加・更新します。
- **上流から直す** — ストーリーやタスクだけを直すと、あとで「なぜそうなったか」が追えなくなります。元の発言や要求が変わったなら、元の文書・要求・要件を更新し、下流のストーリー・シナリオ・タスクへ反映します。
- **確認事項を閉じる** — AIレビューや会話で出た質問は [確認事項](https://pmonrails.com/docs/clarifications.md) に残し、回答を受けたら解決済みにします。回答内容は要求・要件・ストーリーにも反映して、質問だけが浮かないようにします。
- **古いものは削除よりアーカイブ** — 使わなくなった要求・ストーリーはアーカイブして、履歴として残します。完全削除は重複・誤登録など、履歴として残す価値が低い場合に限るのがおすすめです。
- **変更後に差分を見る** — 再取り込みや上流変更のあと、[変更の追従](https://pmonrails.com/docs/change-tracking.md) とストーリー画面の「未確認の上流変更」で、下流に反映漏れがないかを確認します。
- **孤立を減らす** — 要求だけ、ストーリーだけ、タスクだけで浮いているものは、AIが根拠を辿りにくくなります。AIアシスタントやMCPで「根拠がないストーリー」「シナリオがないストーリー」「要求に紐づかないタスク」を確認し、必要な線を足します。

## どこで使えるか

- 会話で使う → [AIアシスタント](https://pmonrails.com/docs/ai-assistant.md)
- 外部ツール（Claude Web / Claude Code / Codex）から使う → [Claude Web・Claude Code・MCP連携](https://pmonrails.com/docs/mcp.md)

---

https://pmonrails.com/docs/graphrag
