AI向けナレッジの作り方 前編 AIに自分の判断基準を教えるナレッジ整備
AIの回答が一般論で終わる原因は、渡している情報の不足かもしれません。GitHubリポジトリに自分の判断基準をMarkdownで蓄積し、AIに自分らしい判断をさせる実践を紹介します。
AIの回答が一般論で終わる理由
ChatGPTやClaudeに相談して、教科書のような答えが返ってきた経験はないでしょうか。技術選定を相談すれば主要フレームワークの比較表が返り、ツールの導入を相談すればメリットとデメリットが並びます。どれも間違ってはいませんが、「で、自分の場合はどうすればいいのか」には答えてくれません。
これはモデルの能力不足というより、情報の不足です。AIは一般的な知識なら十分すぎるほど持っています。しかし、あなたが何を大事にしているか、どういう基準で判断するか、どんな環境で働いているかを知りません。「自分の場合はどうすればいいのか」という質問に答えるための材料を、そもそも渡していないのです。逆にいえば、そこさえ用意すればAIは十分に賢く振る舞います。
とはいえ、必要な情報を毎回プロンプトで用意するのも大変です。相談ごとに同じ情報を書き起こしても、その会話が終われば捨てられてしまいます。プロンプトが使い捨ての消費だとすれば、書き貯めたナレッジは何度でも使える資産です。
筆者は2026年4月から、AIに渡す前提情報をGitHubリポジトリに蓄積しています。前後編の前編となる本稿では、この実践をもとにAI向けナレッジの設計と書き方を解説します。後編では、ナレッジをMCPサーバーで配信し、会社のナレッジへ展開した話を紹介します。
覚えてもらうより、読める場所に置く
毎回、プロンプトを書かずに済ませる方法として、まず思いつくのはメモリ機能でしょう。ChatGPTやClaudeには、会話の内容を記憶して以降の回答に活かす仕組みがあります。
便利な機能ですが、ナレッジの置き場として見ると問題があります。1つはコントロールのしづらさです。何がどんな形で保存されたかを把握しづらく、意図しない要約のされ方をすることもあります。もう1つはポータビリティの低さです。メモリはサービスに紐づくため、ChatGPTに蓄積した記憶をClaudeで使うことはできません。AIの勢力図が変わり続けるいま、自分の前提情報を特定のサービスに預けてしまうと、乗り換えの自由まで手放すことになります。
そこで、自分でAIが読める場所を用意してテキストを置いておくことにしました。ただのMarkdownファイルにしておけば、ChatGPTやClaude、コーディングエージェントのどれからも読めます。中身は自分の管理下のまま、使うAIだけを変えられます。
補足：Obsidianという選択肢
Markdownでナレッジを貯める方法として、Obsidianも選択肢になります。ローカルにただのMarkdownファイルとして保存されるため、AIに読ませる使い方にも向いています。筆者はすでにObsidianを別の用途で使っていたため、AI用ナレッジをそこへ混ぜず、別の置き場所を選ぶことにしました。
GitHubにMarkdownを置くだけ
エンジニアには素直な選択肢があります。ローカルに置いたMarkdownをGitで管理し、GitHubのリポジトリへ上げるのです。
筆者のナレッジは、今のところ次のように整理されています。
ナレッジリポジトリの構成
knowledge/
├── personal/ 自分の判断基準や執筆スタイル
├── dev/ 開発方針や技術選定の選好
└── pixelgrid/ 会社関連の非公開情報
リポジトリにしたことで、変更履歴が残る、プルリクエストでAIにレビューさせられる、CIでtextlintを回して表記を揃えられるといった開発のプロセスをそのまま流用できます。
AIと話す中で「これは毎回説明しているな」「この提案は自分の方針と違うな」と気づいたことを、その都度1つの記事にしていきます。ここでいう記事は、ナレッジ1件を書いたMarkdownファイルのことです。書き始めて4ヶ月ほどで48ファイルになりました（2026年8月時点）。
現在は、候補を思いついたらまずはGitHub Issueに登録し、あとからナレッジとして有用かを検討した上で記事として追加しています。追加登録をAIが提案してくることもあります。
プロフィールではなく判断基準
最初につまずいたのは、何を書くかでした。自分のことを知らせるのだからと、経歴や役割を並べたプロフィールを書こうとして、違和感があったのです。履歴書のような情報を渡しても、AIの回答はあまり変わりません。AIに必要なのは「筆者が何者か」ではなく、「筆者ならどう判断するか」でした。
筆者がナレッジを貯めるのは、リスクの低い判断ならAIに任せたいからです。任せるためには、判断の基準そのものを渡しておく必要があります。
たとえば、リポジトリの中心にある個人の意思決定プロファイルには、次のようなことが書いてあります。
- 意思決定で重視するのは品質・速度・収益。ただし何を決めるかによって優先順位は変わる
- 強く避けたいのは、ベンダーロックイン、将来的な移行性を下げる選択、運用コストが継続的にかかる構成
- 判断の基本方針は、まず小さく試すこと
さらに、方針や判断をAIの行動に反映したい記事の末尾には「AIへの解釈メモ」という節を置き、書いた内容や考えを、AIが従うべき行動ルールに変換しています。技術スタックの記事なら「AWSやVercelを提案する場合は、その条件（クライアント指定・Next.js必須・コスト許容）が揃っているか確認する」といった具合です。
情報を書くだけでは、AIはそれをどう使えばよいか迷います。この情報があるときどう振る舞ってほしいかまで書くことが、AIの回答をもっとも変えました。
実は、この意思決定プロファイルは筆者が自分の手で書いたものではありません。AIに筆者へのインタビューをさせ、回答を整理させて作りました。以降の記事も原則として自分では編集せず、AIエージェントに依頼して書かせています。読み手もAIなので、自分の言葉と多少表現が違っても、利用されたときに違和感がなければ気にしません。たとえば先ほどの「強く避けたい」は筆者の実感よりやや強めの表現ですが、避けているのは確かなので、そのままにしています。
雑談からも判断基準は生まれる
判断基準が出てくるのは、仕事の対話からだけではありません。たとえば筆者の場合、「推し活に違和感があるのだけど、それが何か探りたい」という雑談をAIと始めたことがあります。AIが原因の候補を挙げ、筆者が「新興宗教感かな」「普通のファンには違和感がないんだ」と応じる。
そんなやり取りを重ねるうちに、何に違和感があるのか見えてきました。作品や仕事を好きになるのは自然に受け入れられるのに、人を無条件に好きでい続けるように見える状態に、筆者は距離を感じていたのです。対話の最後には、人物への評価、作品への評価、将来への期待は独立して持ちたい、という基準にたどり着きました。
この基準は、推し活だけの話ではありません。著名な人が作ったライブラリには期待するが、採用するかは設計と実際の出来で判断する。企業への好感で、その製品の評価を上書きしない。趣味の雑談から出てきた基準が、技術選定を含む幅広い場面で役に立ちます。ナレッジとして使い回せるのは、まさにこの形です。過去の事例から引き出した学びも立派なナレッジですが、もう一度、同じ状況にならないと出番がないことも多く、できるだけ多くの判断に当てはまる形へ一般化して書き留めています。
環境の情報を書いたナレッジ
ナレッジに書くのは、判断の基準だけではありません。自分の環境についての情報も、AIに渡さなければわからないものです。使っている機材、契約しているサービス、社内のツール構成。一般的な知識をどれだけ持っていても埋められず、相談のたびに説明しています。
判断基準の記事に比べ、この種の環境についての記事は、作成を始めるのが簡単です。型番と構成、購入日と価格を表として並べるだけで、自分の考えを書き出す必要がありません。判断基準は、なぜそう決めているのかを整理してからでないと書けません。環境の情報なら、手元にあるものを並べるところから始められます。
この記事を用意しておくと、機材の互換性を毎回調べ直す手間もなくなります。筆者はこれから家にあるすべての家電の型番まで入れるつもりです。いつ買ったどの機種かをAIが把握していれば、故障や買い替えの相談も安心です。
まずは一緒に管理し、あとから分ける
このようにナレッジとして貯めているテキストが、ずっとこのリポジトリに残るわけではありません。方針や基準はナレッジに置いたままにしますが、決まった手順の繰り返しは、スキル（エージェントへ作業のやり方を渡す仕組み）として定義するほうが適しています。ただ、最初から厳密に分類するのは難しいので、AIに何度も説明している情報はいったん同じ場所へ集めておけばよいでしょう。
たとえば、技術スタックの記事に「指定がなければCloudflare Workersを第一候補にする」と書いておくと、AIは何も言われなくてもその前提で技術選定を始めます。これはナレッジのままでよい情報です。併せてデプロイのコマンドや確認の手順も書いていますが、こちらは将来的にスキルへ移せます。運用しながら整理していけばよいのです。
AIが読む前提で書く
このナレッジは、完全にAIが読むものとして設計しています。人間向けの読み物なら導入や語り口も大事ですが、AI向けでは優先順位が変わります。コンテキストは有限で、読ませた分だけトークンを消費するからです。筆者はこの方針を次のように決めて、これ自体もナレッジの1つにしています。
AI用コンテキストでは、読み物としての自然さより、タスクに必要な情報が過不足なく含まれていることを優先する。導入、修辞、感情的な補助、同じ内容の言い換えは省く。規則、適用範囲、優先順位、例外を明示し、情報を一つずつ独立して記述する。ただし、短さのために曖昧さを増やさない。判断が分かれうる規則には、理由や具体例を添える。目指すのは最少のトークン数ではなく、AIが誤解なくタスクを実行できる最小限のコンテキストである。
短ければよいという話ではありません。かといって、読み手の役に立たない、書き手の満足のための文章も要りません。
記事1ファイルは、次のフォーマットで書いています。
記事1ファイルの形
---
summary: 個人の意思決定プロファイル（役割、優先順位、避けたいこと、判断基準、制約）
verified: 2026-05
---
# 個人意思決定プロファイル
AIが判断や提案を行う際に、前提として参照してほしい個人プロファイル。
## プロファイル
- 判断の基本方針は、まず小さく試すこと
- 新技術は積極的に採用する。自社プロダクトではベータ版も許容し、クライアント案件では正式公開版を優先する
- コミュニケーションは忖度せず率直に。反論でも判断材料になる本音の見解を歓迎する
## AIへの解釈メモ
- 新しい案は、最初から大きく入れるより、小さく検証できる形に分解する
- 実験余地があるなら新技術を前向きに検討するが、クライアント案件では安定性と説明責任を強めに見る
- 遠回しな配慮より、率直で根拠のある指摘を優先する
先頭のsummaryとverifiedは、一覧や検索から当たりをつけるための要約と、内容を最後に確認した年月です。本文には判断の中身やその理由を書きます。末尾の「AIへの解釈メモ」には、それを踏まえてAIに取ってほしい振る舞いを、理由抜きで並べます。
このほか、運用しながら決まったルールもあります。内容を再確認しただけでもverifiedは更新します。AIが古い情報を今の方針だと誤解しないよう、鮮度を明示するためです。記事同士は依存させず、1ファイルだけ読めば使えるようにしています。
いつ読ませるかを決める
記事を読むタイミングは、次の2つに分けています。
- 常時読み込ませるもの
- 必要なときだけ取得するもの
常時読み込みの対象は、無関係なタスクでもノイズにならない記事だけです。ノイズになるのは、たとえば「一人称は筆者」のような媒体ごとの表記ルールです。このルールはプロジェクトのドキュメントを書く場面では使いませんが、常時読み込ませているとそのまま持ち込まれかねません。
この2つは優劣ではなく役割の違いです。すべてを常時読み込ませるとコンテキストを圧迫し、すべてを必要時の取得に任せると、AIが記事の存在に気づかないことがあります。
特に見落としが起きるのは、AIの既定の振る舞いが筆者の方針と食い違う場面です。記事があっても読まれないまま、既定どおりの提案が返ってきます。
そこで、場面と記事を対応させたknowledge-dispatch.md（ディスパッチ表）を1ファイルだけ用意し、常時読み込ませています。「Macへツールを入れる」「新規プロジェクトの技術選定」といった行に、その場面で読む記事のパスを並べたものです。AIは表を見て、必要になったファイルを自分で開きます。すべての記事が載っているわけではなく、読まないと提案が方針から外れてしまう記事だけです。表が長くなるほど常時読み込みのコストが増え、表そのものが読み飛ばされるからです。
どう常時読み込ませるかは、AIツール側の設定で決まります。Claude Codeなら~/.claude/CLAUDE.mdがセッションの最初に必ず読まれるので、そこへ@とパスを書いてナレッジのファイルを取り込みます。直接取り込むのはalways.mdの1ファイルだけにして、常時読み込みの対象はそのなかで並べています。
always.mdの中身
@personal/decision-profile.md
@personal/writing-style.md
@personal/knowledge-candidate-proposal.md
@dev/principles.md
@personal/knowledge-dispatch.md
@のパスは、書いてあるファイルからの相対で解決されます。対象を足すか外すかは、このファイルを直せば済みます。ほかのコーディングエージェントでも、設定ファイルからリポジトリのパスを参照させる形は変わりません。
ナレッジが判断を変えた場面
ナレッジを渡したAIは、実際どう答えるのでしょうか。印象的だったのは、AIが筆者自身の提案を却下した場面です。
ターミナル環境でコマンドが見つからないエラーを直していたとき、筆者は「実行ファイルの絶対パスを設定に書いてしまえばいい」と提案しました。するとAIは、絶対パスを埋め込めばユーザー名やマシン構成に依存すると指摘しました。移行性を下げる選択を避けるというナレッジの方針を根拠に、採用しませんでした。楽なほうへ流れようとした自分が、自分の書いた判断基準に止められたわけです。前提を知らないAIなら、同意してそのまま直していたはずです。
変わるのは技術の判断だけではありません。苦手なことをどう扱うか相談すると、AIはたいてい練習や学習を勧めてきます。筆者のナレッジには、苦手をなくすことではなく、それが成果に影響しない状態をつくるという方針を書いています。外部化・自動化・委任を先に検討し、安全や健康、経営責任、信頼関係に関わる領域だけは最低限の習得を求めます。これを読んだAIは、克服の計画を出す前に、道具や環境でカバーできないかを探ります。責任の絡む相談なら、仕組みだけに頼らせず自分で向き合うよう促します。
環境の情報を書いたナレッジが、答えを変えた場面もあります。
デスクのスピーカーをサウンドバーへ買い替えたくなり、ケーブルを減らしたいという条件でAIに相談しました。候補を挙げる中で、USB-C 1本で給電と音声をまとめるには5V/3Aを出せるポートが要るとわかりました。そこで「今のモニターは給電できる？」と聞きました。AIはいったん、型番が特定できないと答えました。「ナレッジにあるよ」と伝えると、常用機材の記事からDell UltraSharp U3223QEを見つけ、USB-Cダウンストリームが最大15Wという公式仕様を確認し、ちょうど足りると判定しました。MacBook Airからモニターへ1本、モニターからサウンドバーへ1本という配線まで示しました。
このケースで引っかかったのは、AIが最初に常用機材の記事を読まなかったことです。そこには「AIへの解釈メモ」がなく、読むきっかけを渡すディスパッチ表にも載せていませんでした。前の節で書いた、いつ読ませるかの設計が抜けていたのです。気づいたあとで、この記事へ「AIへの解釈メモ」を書き足し、ディスパッチ表にも1行加えました。こうして抜けを見つけるたびに直していけば、ナレッジは育っていきます。
まとめ
AIの回答が一般論で終わるのは、モデルが賢くないからではなく、判断に必要な情報を渡していないからです。自分のナレッジを貯めれば、AIは代わりに判断できます。
ナレッジに書く価値があるのは、判断基準と、自分の環境についての情報です。判断基準はAIの回答を変え、環境がわかっていれば説明や調べ直しが要りません。
用意したナレッジは、いつ読ませるかを設計する必要があります。ナレッジが増えるほど、この設計が大事になります。AIが見つけられないナレッジは、ないも同然です。
渡したナレッジの分だけ、AIは筆者と同じ判断ができるようになります。細かく指示しなくても任せられる範囲が広がるわけです。まずは、AIに何度も同じ説明をしていることを1つ選び、Markdownに書き出すところから始めるとよいでしょう。
後編では、このナレッジをMCPサーバーで配信してどの環境のAIからも参照できるようにした構成と、会社のナレッジへ展開した話を紹介します。