LEARNING LOG — RAG & Acceptance Criteria
2026年7月7日の早坂さん定例で話した、RAGの仕組み・NotebookLMの限界・精度の測り方・受け入れ条件の書き方。社内のAI活用を判断するときの基準を、この1ページにまとめました。
KEY MESSAGE — Four Takeaways
「社内データにAIで聞きたい」は、まずNotebookLMで大半解決する。手段の分岐は「実作業の有無 × コスト × 精度」。
AIの品質は、受け入れ条件を決定論的に書けるかで決まる。
素のAIに学習ループは無い。振り返り→CLAUDE.md・スキルへの追記を工程に組み込む。
本当の痛みの特定と構造の作り替えは、AIにはできない。それが人間＝eapの売り物。
RAG — Retrieval-Augmented Generation
AIモデルは学習カットオフ以降の知識を持たない。データを持ち続けるとモデルが重くなるからです。そこでモデルとは別に「データの置き場（DB）」を立てて、回答のたびに参照させる——この機構がRAGです。
Obsidianに知識を外部化しておいて、必要なときに読み込むのと同じ発想です。
Structure
NotebookLM — Where It Ends
Scope
できること
参照して答えるまで
できないこと
答えた先の作業
限界が来るのは「そこからAIに作業をさせたい」とき。そこで初めて、次の分岐に進む。
DECISION — Which Tool, When
Branch
NotebookLM等の既存ツールで足りる。作らない・買わないで解決するのが最安。
エージェント基盤（Claude Code等）や個別開発を検討。コストと精度要件で絞り込む。
AIは失敗しても再実行コストが低い。人間のエネルギーより圧倒的に安いので、「物量で押す」戦略が取れる。
ACCURACY — Recall × Precision
Two Axes
Recall
再現率
拾うべきものを、どれだけ拾えたか。
例：医師が海外由来の病気を知らない → そもそも候補に挙がらず、再現率が落ちる。
Precision
適合率
拾ったものの中に、間違い（ノイズ）がどれだけ混ざっていないか。
例：知識はあるのに別の病気と誤診する → 候補は出たが外れて、適合率が落ちる。
両者はトレードオフ。カバー範囲（知識・選択肢）を広げると再現率は上がるが、選択肢が増えてピンポイントで当てにくくなり、適合率が下がる。このバランス調整こそ技術で解決する領域。検証は「人間・AI・プログラム（計算で判定できるもの）」のどれで行うかを決める。
判定確率0.5はコイン投げ（ランダム）と同じ。閾値の設定に意味を持たせる。
EMBEDDINGS — Why Prompts Work
文字情報は「キーワードから連想される概念」として数百〜数千次元のベクトルに分解されます。成分が近い＝意味が近い。モデルの「◯◯億パラメータ」はこの次元数のことで、x・y・zの軸が無限に増えていくイメージです。
回答の生成は「次に来る語」の確率分岐の連続。連想ゲームで軸を広げ、ありえないものを外しながら1つの回答に絞り込んでいます。
だからこそ、プロンプトで概念を渡すほど、AIは正しい回答に辿り着きやすくなる。ここを理解するとAIの使い方そのものが上手くなります。
CONTEXT — Draw the Line
GPTの「プロジェクト」＝境界の単位。境界の中に蓄積した文脈（過去の議事録など）を踏まえた回答はできますが、新規プロジェクトには持ち越されません。
1箇所に詰め込みすぎると、ノイズが増え、過去のバイアスに引っ張られ、別の観点で見る力が落ちます。人間と同じで「全く別の人に意見を聞く」が有効——あえて境界を分ける、別モデル（Claude・Gemini等）でセカンドオピニオンを取る、が実務の型です。
WORKFLOW — Checkpoints & Loops
個人の作業図がチームでは何本も連なります。工程を繋げて中間を削れる箇所と、品質のブレを防ぐためにチェックを残す箇所の見極めが設計の肝。ものづくりの検品と同じで、途中のチェックを飛ばすと欠陥品が後工程に流れ、後工程の作業が増えます。
Team Pipeline
ACCEPTANCE CRITERIA — The Core Lesson
タスクを依頼するとき、「これができたら完成とみなす」という受け入れ条件を一緒に渡す。条件が具体的かつ決定論的（何回やってもブレない）であるほど、AIは失敗しなくなります。
AIの動きは非決定的でも、ゴールさえ固定されていれば、どのルートを通っても辿り着けるからです。
必須のリンクがすべて入っている
計測タグが入っている
ブラウザのコンソールにエラーが出ない
ボタンを押すと正しいページに遷移する
抽象度の高い依頼でも、受け入れ条件をパターン化して固定しておけば毎回書かずに済む。条件の整理自体もAI（ブレインストーミング系スキル等）に任せられる。
PLUGINS — Train Your Tools
スキルの発動はキーワード依存。Claude Codeはコード向けに最適化されているため、ビジネス用途では引っかかるキーワードを意識するか、意図的に発動させる必要があります。
自分用にカスタマイズ（調教）して初めて真価が出る。そしてプラグインは入れすぎると喧嘩するので、用途で使い分ける。
HUMAN WORK — What AI Cannot Do
上層部の言う課題と現場の痛みは乖離しがちです。現場は本音を言いにくく、対策は「人を増やす・金で解決」に流れやすい構造があります。
提案すべきは対症療法ではなく、痛みが発生しない構造への作り替え。この「本当の痛みの特定と構造化」はAIにはできない——人間がやるべき領域であり、eapの提供価値そのものです。
ACTIONS — What Happens Next
| アクション | 期限 | 完了基準 |
|---|---|---|
| 岡久様向け提案資料の作り直し（骨格維持・ヒアリング設計重視） | 7/9（木）まで | 次回MTGでレビューできる状態 |
| AI開発相談メンバーを来週MTGに追加 | 7/13週 | 招待・案内送付済み |
| LP等の定型タスクの受け入れ条件をパターン化しスキルに固定 | 7月中 | 依頼時に自動適用される状態 |
| デイリーの振り返り→CLAUDE.md／スキル反映のループ運用 | 運用中 | 日次学習サイクルで知見が蓄積されている |
| ビジネスサイド向けプラグインの選定（入れすぎ注意） | 任意 | 候補リストの確認 |
SOURCES — Read the Full Notes
※ 社内向けページです。クライアント名・内部リンクを含むため、社外への共有はしないでください。