AI に自身の文脈を持ち運ぶ

AI サービスが増えると、利用者は同じ自分を何度も説明することになる。ChatGPT、Claude、Gemini、Copilot、社内 AI、ローカル LLM などを併用すると、それぞれの AI は別々の履歴、別々の記憶、別々のファイル、別々のプロジェクトを持つ。その結果、利用者の文体、判断基準、禁止事項、技術環境、過去の経緯、好む説明粒度は、サービスごとに断片化される。これは単なる利便性の問題ではない。AI が利用者をどのように理解するかという文脈が、サービスごとに閉じ込められる問題である。

この問題に対する答えは、単に「よいプロンプトを書く」ことではない。より根本的には、利用者自身の文脈を外部化し、AI サービスを越えて持ち運べる形にすることである。OpenAI のメモリ機能は、会話内容を後続のチャットに活用し、利用者がオン・オフや削除を管理できる仕組みとして説明されている[1]。Google も Gemini で Google アプリや検索履歴を使った個人化を打ち出しており[2]、Microsoft 365 Copilot も保存されたメモリ、チャット履歴から推論された詳細、カスタム手順を使ってパーソナル化する仕組みを提供している[3]。これらは有用である。しかし、いずれも基本的には各サービス内の文脈管理であり、利用者が複数 AI にまたがって同じ文脈を一貫して運ぶ仕組みそのものではない。

本稿では、AI のパーソナライズを、好みや口調の記憶ではなく、利用者の暗黙知、判断基準、趣向、思想、作業規則、履歴を外部化し、AI が参照可能な情報構造へ変換する行為として捉え直す。そのうえで、Markdown による ai_context ディレクトリを設計し、恒久ルール、準恒久方針、更新型コンテキスト、時点記録に分け、連結スクリプトで full_context.md を生成する具体的な方法まで示す。つまり、本稿は抽象論だけで終わらない。AI 時代の自己記述をどう設計し、どう保守し、どう持ち運ぶかを、思想と実装の両面から整理する。

1. AI サービスが増えるほど、自分を何度も説明する問題が起きる

AI 利用が単一サービスの中で完結しているうちは、会話履歴やメモリ機能に依存しても大きな問題は見えにくい。しかし、実際の利用は次第に分散する。文章を書くときは ChatGPT、コードを書くときは別の AI、社内文書を扱うときは Enterprise 環境、ローカルデータを扱うときはローカル LLM、業務連携では Copilot、Google Workspace では Gemini、というように、用途ごとに AI が分かれる。AI サービスが増えることは能力の選択肢が増えることだが、同時に、利用者の文脈が分裂することでもある。

このとき起きるのは、毎回同じ前提を説明し直す負荷である。たとえば、文章作成では「要約ではなく論理を深く展開する」「表層的な一般論で終わらせない」「参考文献を本文登場順に並べる」「HTML では特定のタグ運用を守る」といったルールがある。コード作成では「コメントは英語」「diff が来たらレビューしてからコミットメッセージ」「余計なリファクタリングをしない」「ドキュメント更新を伴う」といった作業規則がある。これらは一度の会話では伝えられても、別の AI、別のプロジェクト、別の環境に移るたびに失われる。

問題は、AI の性能差ではない。高性能な AI であっても、利用者の文脈を持たなければ、利用者に合わない回答を出す。逆に、基礎能力が同程度でも、文脈が適切に与えられていれば、回答のずれは小さくなる。したがって、複数 AI 時代の実務問題は「どの AI が賢いか」だけではなく、「どの AI にも同じ自分の文脈を渡せるか」へ移る。

状況	起きる問題	必要になる対応
AI サービスを用途別に使い分ける	サービスごとに記憶と履歴が分かれ、同じ前提を何度も説明する必要が生じる。	利用者側で正本となる文脈ファイルを持つ。
プロジェクトごとに AI の作業空間が分かれる	プロジェクト内では文脈が保たれても、別プロジェクトへ移ると前提が失われる。	プロジェクト固有情報と利用者共通ルールを分離する。
業務 AI と個人 AI を併用する	同じ判断基準を使いたくても、サービスの記憶機能が共有されない。	外部 Markdown として必要な範囲だけ持ち込む。
AI の内部メモリに依存する	保存・更新・削除・移植の制御がサービス仕様に依存する。	内部記憶を補助キャッシュとし、外部コンテキストを正本にする。

2. パーソナライズとは、好みを覚えさせることではない

パーソナライズという語は、しばしば浅く理解される。名前を覚える、敬体か常体かを合わせる、好きな話題を覚える、よく使うツールを覚える、という程度で捉えられやすい。もちろん、それもパーソナライズの一部である。しかし、AI との継続的な協働において重要なのは、もっと深い層である。利用者が何をよい回答とみなすか、何を危険な回答とみなすか、何を十分な説明とみなすか、何を余計な提案とみなすか、どの粒度で構造化されると理解しやすいか、そうした判断構造が反映されていなければ、表面的に口調だけ合っていても「自分向けの回答」にはならない。

たとえば、ある利用者にとって「丁寧な説明」とは、長い文章ではなく、定義、背景、因果、具体例、反例、限界がそろっている説明である。別の利用者にとって「実用的な回答」とは、すぐ実行できるコマンドだけでなく、失敗時の切り戻し、ログ確認、影響範囲、ドキュメント更新まで含む回答である。これは好みではなく、判断基準である。パーソナライズとは、この判断基準に合わせて AI の応答生成を調整することである。

つまり、パーソナライズとは「利用者好みの装飾」ではない。利用者の判断構造を AI の応答に反映させることである。表層の文体は、深層の判断構造の一部にすぎない。AI が本当に個人向けになるには、利用者の暗黙知、価値観、注意配分、言語化の癖、失敗回避パターンを、できる限り明示的な文脈として受け取る必要がある。

層	内容	AI への反映	限界または重要性
表層的パーソナライズ	名前、口調、敬体か常体か、よく使うツール、好きな話題などを覚える。	出力の雰囲気や話題選択に反映される。	便利ではあるが、それだけでは利用者の判断基準までは反映されない。
作業上のパーソナライズ	レビュー手順、出力形式、禁止事項、ファイル生成方法、コードコメント規則などを覚える。	回答の手順、成果物の形式、確認観点、実装方針に反映される。	継続作業では重要だが、個別ルールが増えるほど優先順位管理が必要になる。
判断構造としてのパーソナライズ	何を十分な説明とみなすか、何を危険とみなすか、何を余計な提案とみなすか、どの粒度の構造化を求めるかを反映する。	問題の切り分け方、説明の深さ、抽象と具体の比率、リスク評価、提案範囲に反映される。	ここまで反映されて初めて、利用者にとって「自分向けの回答」になる。
内面構造としてのパーソナライズ	暗黙知、価値観、思想、注意配分、失敗回避パターン、言語化傾向を文脈として外部化する。	AI が利用者の言葉や依頼を解釈する前提そのものに反映される。	完全な再現はできないが、外部コンテキストとして管理することで解釈のずれを減らせる。

3. 暗黙知とは、まだ言語化されていない判断構造である

暗黙知は、単に「言葉にできない知識」ではない。より正確には、本人が実際に判断や行動に使っているにもかかわらず、まだ明示的な規則として切り出されていない構造である。Polanyi は暗黙知の議論で、人間は語れる以上のことを知っているという問題を示した[4]。この命題を AI 利用に引き寄せるなら、人間は AI に明示していない多くの判断基準を実際には使っている、ということになる。

たとえば、ある説明を読んで「浅い」と感じる。その時点では、なぜ浅いのかを明文化していないかもしれない。しかし分析すると、定義がない、原因が一段しか掘られていない、具体例がない、反例への配慮がない、概念同士の接続が弱い、結論だけでプロセスがない、という複数の基準が働いている。これは、内面にある漠然とした気分ではなく、まだ言語化されていない評価関数である。

AI は暗黙知を直接読めない。AI が読めるのは、会話に現れた文字列、添付ファイル、明示された指示、利用可能な外部データである。そのため、利用者が「何度言ってもずれる」と感じる場合、AI の能力不足だけでなく、利用者側の暗黙知がまだ外部化されていない可能性がある。AI 向けコンテキスト管理とは、この暗黙知を少しずつ明文化し、再利用可能なルール、方針、記録へ変換する作業である。Nonaka も、知識創造を暗黙知と形式知の相互作用として捉え、暗黙知を外部化する過程の重要性を論じている[5]。

内面で起きる判断	暗黙知としての内容	AI コンテキスト化した記述
この説明は浅いと感じる。	定義、因果、具体例、限界がそろっていない説明を不十分と判断している。	長文説明では、命題、定義、因果、具体例、限界を省略しない。
この修正は余計だと感じる。	依頼範囲を越えたリファクタリングをリスクとして見ている。	最小差分を原則とし、依頼されていない改善提案や変更を行わない。
この回答は信用しにくいと感じる。	根拠、出典、時点、影響範囲が不明な説明を不安定と判断している。	変わり得る事実は確認し、出典と時点を明示する。
この文章は自分のブログに合わないと感じる。	文体、論理密度、HTML 構造、参照番号の置き方が既存スタイルと一致していない。	ブログ用 HTML では、定義済みの文体、表記、参照、HTML 整形ルールに従う。

4. 判断基準とは、世界をどう切り分けるかの規則である

判断基準とは、ある入力に対して、よい、悪い、十分、不十分、重要、些末、安全、危険、自然、不自然、深い、浅い、といった区別を行う規則である。これは単なる好き嫌いではない。人間は、経験、専門性、価値観、失敗経験、身体感覚、社会的立場、思想的前提に基づいて、世界の中に意味のある差異を見出している。AI に判断基準を渡すとは、その人が世界をどのような切断面で見ているかを渡すことである。

技術者の判断基準を例にすると、短く動くコードよりも、長期的に壊れにくいコードを重視することがある。ログは多ければよいのではなく、異常時に原因を追跡でき、平常時にはノイズにならないことが重要になる。スクリプトは成功時に派手な出力を出すより、失敗時に正しい終了コードを返し、再実行可能で、既存環境を壊さないことが重要になる。これは趣味ではなく、運用経験から形成された判断基準である。

文章作成でも同じである。短くまとまっていることを重視する人もいれば、抽象概念を具体例と因果で展開することを重視する人もいる。参考文献は末尾に並んでいればよいと考える人もいれば、本文の初出順で番号を付け、本文からリンクし、参考文献側の URL を一度だけ出すことを重視する人もいる。これも単なる好みではなく、情報をどのように信頼可能な構造へ変換するかという判断基準である。

領域	表面的には好みに見えるもの	背後にある判断基準	AI に渡すべき文脈
技術実装	短いコードがよい、詳しいコードがよい、ログを多く出したい、静かに動かしたい。	保守性、再実行性、失敗時の追跡可能性、既存環境を壊さないことをどう重視するか。	実装ポリシー、ログ方針、終了コード方針、後方互換性、最小変更の基準。
レビュー	細かく指摘したい、必要な点だけ指摘したい、改善案を多く出したい。	レビューを品質保証と見るか、設計議論と見るか、最小修正の確認と見るか。	レビュー範囲、指摘すべき重大度、余計な提案の禁止、diff に含まれない変更を避ける方針。
文章作成	短い文章がよい、長い文章がよい、表を多く使いたい、説明を厚くしたい。	読者にとって十分な理解とは何か、定義・因果・具体例・反例・限界をどこまで必要とするか。	論述密度、段落構造、抽象と具体の比率、一覧表の使い方、説明責任の基準。
参考文献	リンクがあればよい、参考文献が多ければよい、形式をそろえたい。	情報の検証可能性、本文と出典の対応、読者が追跡できる構造をどこまで重視するか。	本文初出順、参照番号、アンカー整合、URL 表記、未引用文献を残さない方針。
AI 応答	簡潔に答えてほしい、深く考えてほしい、提案してほしい、余計な提案を避けてほしい。	AI を即答装置として使うか、思考補助として使うか、実装支援として使うか、共同編集者として使うか。	応答の深さ、追加提案の許容範囲、確認質問の抑制、成果物の完成度、既存方針の優先順位。

5. 情報とは、判断を変える差異である

AI に文脈を渡すという話を深く理解するには、情報とは何かを整理する必要がある。情報は、単なる文字列でも、単なるデータでもない。Shannon の情報理論は、通信における情報源、送信機、チャネル、受信機、宛先、ノイズといった構造を定式化し、情報を不確実性や選択の問題として扱った[6]。ただし、AI 向けコンテキストで重要なのは、通信路上の情報量だけではない。その情報が、受け手の判断や応答をどう変えるかである。

たとえば、「コード内のコメントは英語のみ」という一文は、単なる文字列ではない。AI がコードを生成するとき、日本語コメントを出すか、英語コメントを出すかを分岐させる制約である。「diff が来たらレビューしてからコミットメッセージを出す」という一文も、単なる作業メモではない。AI の処理順序を規定する制御情報である。一方、「ある年の健康診断結果」は、現在の身体状態そのものではなく、ある時点における測定記録である。これは、現在事実としてではなく、時点記録として扱われる必要がある。

したがって、AI 向けコンテキストにおける情報とは、AI の応答を利用者向けに分岐させる差異である。どの表記を使うか、どの順序で処理するか、どの前提を置くか、どの情報を現在事実とみなすか、どの情報を過去記録とみなすかを変えるものが、ここでいう情報である。Chapman が情報、意味、文脈の関係を論じているように、情報は単独で閉じるのではなく、解釈される場と結びついて意味を持つ[7]。

種類	例	AI にとっての意味
データ	日付、数値、URL、ファイル名、コマンド名。	そのまま参照できる素材だが、優先順位や用途は別途必要になる。
ルール	コードコメントは英語、参照番号は本文初出順、余計な変更をしない。	出力や作業順序を制約する。
方針	長期安定性を重視する、論理密度を重視する、表層的な提案を避ける。	判断の方向性を決める。
記録	過去の健康診断、過去のサーバー障害、過去のリリース履歴。	時点情報として参照されるが、現在事実とは限らない。
文脈	どの情報をどの優先順位で使うかを定義した構造。	情報の意味、重み、適用範囲を決める。

6. 文脈とは、情報に優先順位と解釈を与える構造である

情報を大量に並べても、それだけでは文脈にならない。文脈とは、情報に優先順位、適用範囲、時間性、解釈規則を与える構造である。たとえば、「日本語表記は一定のスタイルに統一する」という情報と、「特定 OS の特定バージョンで問題が起きた」という情報は、同じ重みで扱うべきではない。前者は恒久ルールに近く、後者は時点記録である。これらを同じ階層に置くと、AI は過去の環境情報を現在の恒久ルールのように扱う可能性がある。

AI のコンテキストウィンドウは有限であり、そこに入れた情報が常に期待どおりの重みで解釈されるとは限らない。Anthropic はコンテキストエンジニアリングを、LLM 推論時に含まれるトークン、すなわち情報の最適な集合を選び、維持する戦略として説明している[8]。この視点から見れば、個人コンテキスト管理も同じである。重要なのは、すべてを無差別に入れることではなく、AI がどの情報をどの重みで読むべきかを明示することである。

文脈は、情報の束ではなく、情報の読み方である。README に「このフォルダを正本とする」「優先順位は恒久ルール、準恒久方針、現在コンテキスト、時点記録の順とする」「時点記録は現在事実とは限らない」と書くのは、単なる説明ではない。AI に情報をどう解釈させるかを指定するメタ情報である。そのため、AI に渡す情報は、内容ではなく性質によって分類する必要がある。

7. AI に渡す情報は四種類に分けられる

AI 向けコンテキストは、少なくとも四種類に分けて扱う必要がある。第一に、恒久ルールである。これは原則として常に守る規則であり、表記、出力形式、引用整合、コードコメント、diff レビュー手順などが入る。第二に、準恒久方針である。これは長期的な判断軸であり、説明の深さ、技術判断の傾向、思想的関心、専門領域などが入る。第三に、更新型コンテキストである。これは現在の運用状態であり、サーバー構成、リポジトリ状況、OS 環境、自ブログ記事索引などが入る。第四に、時点記録である。これは過去の事実であり、健康診断、体組成、過去のバージョン履歴、過去の運用事故、過去の判断記録などが入る。

この分類は、整理のためだけにあるのではない。AI に誤用させないためにある。恒久ルールと時点記録を混ぜると、AI は「守るべき規則」と「参照すべき過去情報」を混同する。現在の運用状態と過去の障害記録を混ぜると、古い状態を現在の状態として扱う可能性がある。したがって、情報の分類は、AI の解釈誤りを減らすための安全装置である。

分類	性質	例	扱い
恒久ルール	原則として常に守る規則。	日本語表記、HTML 生成、参考文献、diff レビュー、コードコメント。	最優先で適用する。
準恒久方針	長期的な判断軸。	技術判断、説明の深さ、専門領域、思想的関心、文体傾向。	回答方針に反映する。
更新型コンテキスト	現在の運用状態。	サーバー構成、リポジトリ状態、OS 環境、記事索引、利用ツール。	現在情報として参照し、変更を前提にする。
時点記録	過去の事実。	健康診断、バージョン履歴、過去の障害、過去の判断、作業ログ。	日付付き記録として参照し、現在事実とは限らないものとして扱う。

8. AI の内部記憶に任せると、文脈の主権がサービス側に寄る

AI の内部記憶は便利である。会話のたびに同じ説明をしなくて済むし、利用者の好みや作業傾向を反映しやすくなる。しかし、内部記憶に全面的に依存すると、文脈の主権がサービス側に寄る。どの情報が保存され、どの粒度で更新され、いつ削除され、どの会話でどのように参照されるかは、サービスの仕様に依存する。また、あるサービスで蓄積された記憶を、そのまま別の AI へ移すことは一般に難しい。

これは、文脈ロックインと呼べる。従来のデータロックインでは、写真、文書、連絡先、メール、設定などが特定サービスに閉じ込められる。AI 時代には、それに加えて、利用者の判断基準、作業規則、会話履歴から推論された好み、プロジェクトの前提がサービス側に閉じ込められる。AI を長く使うほど、その AI は利用者に合うようになるが、その適合性は別サービスへ移植しにくい。

外部 Markdown として正本を持つことは、この文脈ロックインを避ける方法である。AI の内部記憶は補助キャッシュとして使えばよい。しかし、正本は利用者の手元に置く。必要な AI に渡し、不要になれば削り、古くなれば更新し、機密性が高い部分は除外する。AI に自分を覚えさせるのではなく、自分の文脈を自分で持つのである。

9. 可搬性とは、文脈を別環境で再構成できることである

可搬性とは、ファイルをコピーできることだけではない。別の AI、別のプロジェクト、別の企業環境、別のローカル LLM に移しても、同じ意味で解釈されることである。個人データの文脈では、GDPR 第 20 条が、構造化され、一般的に使われ、機械可読な形式で個人データを受け取り、別の管理者へ移転できる権利を定めている[9]。ICO も、データポータビリティを、個人データを再利用しやすい機械可読形式で受け取る権利として説明している[10]。本稿で扱う AI 文脈の可搬性は、この法的権利そのものではない。ただし、利用者に関する情報を特定サービスに閉じ込めず、再利用可能な形にするという点では、構造的に近い問題を扱っている。

ただし、AI 文脈の可搬性は、単なるデータポータビリティよりも難しい。なぜなら、持ち運ぶ対象は事実データだけではなく、解釈規則だからである。「このファイルは恒久ルールである」「これは長期方針である」「これは現在状態である」「これは時点記録である」という分類がなければ、別 AI は情報の重みを誤る。つまり、AI 文脈の可搬性とは、データの移動ではなく、解釈構造の再構成可能性である。

したがって、可搬な AI コンテキストには、本文だけでなくメタ情報が必要である。README、番号付きディレクトリ、ファイル名、Source コメント、優先順位、除外方針、更新ルールが必要になる。これらは見た目の整理ではない。AI に「どの情報をどう読めばよいか」を渡すための構造である。

10. Markdown は、人間と AI の両方が読める中間形式である

AI コンテキストの正本形式として Markdown が適している理由は、単に軽いからではない。Markdown は、人間が読める構造化テキストであり、AI にも比較的読みやすく、Git による差分管理にも向いている。CommonMark は Markdown を、電子メールや Usenet の慣習に基づく構造化文書のためのプレーンテキスト形式として説明し、曖昧さを減らす仕様化を進めている[11]。この性質は、AI 向け自己記述に向いている。

PDF や Word は、人間が読む成果物としては便利だが、差分管理、機械的連結、部分更新、構造抽出には向きにくい。JSON や YAML は機械処理には向くが、長い説明文や判断基準の記述には窮屈である。プレーンテキストは最も可搬だが、見出しや階層が弱い。Markdown は、その中間にある。人間が保守でき、AI が読め、Git で差分を追え、スクリプトで連結しやすい。

重要なのは、Markdown を「AI に読ませるためのファイル」とだけ見ないことである。これは、人間が自分の判断基準を保守するための形式でもある。AI 向けコンテキストは一度書けば終わりではない。利用者の判断基準は、経験、運用、執筆、失敗、環境変化によって更新される。Markdown は、その更新を人間の手で追える最小媒体である。

11. ディレクトリ構造で情報の意味と優先順位を表す

AI コンテキストは、一つの巨大なファイルとして直接書き始めるより、カテゴリごとに分割して管理する方がよい。分割ファイルは人間が保守し、連結ファイルは AI に渡す。これにより、編集しやすさと可搬性を両立できる。Git は高速でスケーラブルな分散バージョン管理システムとして説明されており[12]、Markdown ファイル群を Git 管理すれば、いつ、どのルールが追加・修正されたかを追跡できる。

基本構成は次の通りである。

1
2
3
4
5
6
7
8
9
10

ai_context/
README.md
01_permanent_rules/
02_durable_preferences/
03_live_context/
04_dated_records/
compiled/
full_context.md
minimal_context.md
build_full_context.py

パス	役割
README.md	全体の読み方、優先順位、正本性、矛盾時の扱いを定義する。
01_permanent_rules	恒久ルールを置く。
02_durable_preferences	長期的な判断方針、好み、専門領域、思想的関心を置く。
03_live_context	現在の運用状態、プロジェクト状態、サーバー構成、記事索引を置く。
04_dated_records	過去の測定、判断、障害、バージョン履歴などの時点記録を置く。
compiled	AI に渡す統合版を生成する出力先とする。
build_full_context.py	分割された Markdown を優先順位順に連結するスクリプトとする。

番号付きディレクトリにする理由は、単に見やすくするためではない。AI にも人間にも優先順位を明示するためである。01 は最優先、02 は長期方針、03 は現在状態、04 は過去記録である。この順序は、連結順にも反映する。

12. README.md には、このコンテキストの読み方を書く

README.md は、ai_context 全体の制御点である。単に「これは AI 用のファイルです」と書くだけでは不十分である。AI が各ファイルをどう読むべきか、矛盾がある場合に何を優先するか、時点記録を現在事実として扱ってよいか、会話中の最新指示とファイル上の記述が衝突した場合にどうするかを明示する必要がある。

README.md の最小例は次のようになる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# AI Context Policy

この ai_context 配下のファイルを、利用者向け応答の正本コンテキストとして扱う。

優先順位は次の通り。

1. 01_permanent_rules
2. 02_durable_preferences
3. 03_live_context
4. 04_dated_records

同一内容について過去の記憶・会話履歴・他ファイルと矛盾がある場合は、より上位の分類を優先する。

01_permanent_rules は恒久ルールとして扱う。
02_durable_preferences は長期的な判断方針として扱う。
03_live_context は現在の運用状態として扱い、変更され得る。
04_dated_records は時点記録として扱い、現在事実とは限らない。

ただし、現在の会話で新しく明示された指示がある場合は、その指示を最優先する。

この README は、AI にとってのメタ指示である。通常の文書と違い、ここにはコンテキストそのものではなく、コンテキストの読み方が書かれている。特に重要なのは、時点記録を現在事実とは限らないものとして扱うこと、そして現在の会話で新しく明示された指示を最優先することである。これにより、古い記録が現在の判断を上書きする事故を避けられる。

つまり、README.md は固定ルールを絶対化するためではなく、固定ルール、現在状態、過去記録、現在の指示を衝突なく扱うための読み取り規則である。

13. 各カテゴリには何を書くべきか

分類を作っても、何をどこに置くかが曖昧だと運用できない。ここでは、各ディレクトリに入れるべき情報を具体的に整理する。

13.1 01_permanent_rules に入れるもの

01_permanent_rules には、原則として常に守るルールを入れる。ここに入る情報は、現在の作業対象に依存せず、AI の応答全体にかかる。たとえば、応答・対話の基本ルール、diff レビュー・コミットメッセージ運用ルール、スクリプト・コード実装ポリシー、長文・論考・説明文の執筆スタイル、HTML 生成・整形ルール、参考文献・引用整合ルール、カテゴリー分類ルール、タイトル設計ルール、MathJax・数式説明ルール、日本語表記・用語統一ルール、画像生成・視覚表現ルールなどである。

ファイル例	内容	理由
basic_response_task_execution_context_rules.md	回答言語、過剰提案の禁止、依頼範囲の尊重、成果物提供時の基本姿勢を書く。	すべてのやり取りに影響するため。
change_review_minimal_diff_commit_rules.md	diff レビュー、最小差分、コミットメッセージ、変更種別判定の手順を書く。	コードレビューと変更提案の順序を固定するため。
code_script_implementation_policy.md	スクリプト実装、ログ、終了コード、CLI、ドキュメント更新、コメント規約を書く。	実装品質と運用品質を安定させるため。
html_artifact_generation_formatting_rules.md	HTML 生成、見出し、表、コードタグ、ダウンロード形式、差分最小主義を書く。	ブログ記事や成果物の形式崩れを防ぐため。
reference_citation_bibliography_integrity_rules.md	本文参照、参考文献、URL 表記、番号順、アンカー整合を書く。	引用整合を機械的に守るため。
japanese_style_terminology_consistency_rules.md	日本語表記、外来語、スペース、用語統一を書く。	記事や技術文書の表記ゆれを防ぐため。

13.2 02_durable_preferences に入れるもの

02_durable_preferences には、恒久ルールほど強制ではないが、長期的に回答方針へ反映すべき情報を入れる。たとえば、思想・関心領域、専門領域、技術判断の傾向、説明の好み、Web アクセス解析の判断方針、個人プロフィールのうち長期的に変わりにくいものなどである。ここに入る情報は、AI が回答の方向性を決めるときに参照する。

情報の種類	内容	扱い
専門領域	ソフトウェア開発、データ基盤、サーバー運用、技術文書、ブログ執筆など。	前提知識の粒度を調整する。
説明の好み	抽象概念を具体例と因果で展開し、表層的な一般論で終わらせない。	回答の深さと構成に反映する。
技術判断の傾向	長期安定性、互換性、低ノイズログ、最小変更、再現性を重視する。	実装提案や運用判断に反映する。
思想的関心	情報、構造、時間、生命、意識、AI、文明などを構造的に理解する関心。	論考や記事構成の抽象度に反映する。

13.3 03_live_context に入れるもの

03_live_context には、現在の運用状態を入れる。たとえば、技術運用・サーバー・インフラ環境、リポジトリ・スクリプト群の現在状態、OS・ディストリビューション判断、自ブログ記事・参照インデックス、現在利用中の WordPress 構成、現在の AI context ファイル構成などである。これは現在情報として参照するが、変更され得るものとして扱う。

情報の種類	例	注意点
サーバー構成	ホスト名、役割、Apache、WordPress、証明書運用、ログ運用。	外部 AI に渡す場合は機密性を確認する。
リポジトリ状態	スクリプト群、バージョン履歴、実装ポリシー、現在のタグ運用。	古い情報を混ぜないよう更新日を明示する。
記事索引	自ブログ記事、関連テーマ、参照関係、公開済み URL。	記事執筆時の参照候補として使う。
OS 判断	Debian、Ubuntu、パッケージ、運用上の注意。	リリース状況が変わるため、現在性を確認する。

13.4 04_dated_records に入れるもの

04_dated_records には、過去の時点記録を入れる。健康診断結果、体組成測定、過去の生活記録、過去のバージョン履歴、過去のサーバー運用事故、過去のアクセスログ傾向、過去の技術判断などである。ここに入る情報は、現在事実ではなく「その時点でそうだった」という記録として扱う。

記録の種類	扱い	理由
健康診断や体組成	日付付きの過去記録として扱う。	現在の健康状態と混同しないため。
過去のバージョン履歴	リリース時点の記録として扱う。	現在のコード状態や方針とは異なる可能性があるため。
過去の障害やログ傾向	再発防止の参考として扱う。	現在も同じ原因とは限らないため。
過去の技術判断	当時の条件に基づく判断として扱う。	ソフトウェアやサービスの仕様が変わるため。

14. 分割ファイルは人間が保守し、full_context.md は AI に渡す

ai_context の運用では、編集対象と生成物を分けることが重要である。01 から 04 の各ディレクトリにある Markdown ファイルは、人間が保守する正本である。一方、compiled/full_context.md は AI に渡すための生成物である。生成物を手で編集すると、元ファイルとの差分が不明になり、次回生成時に上書きされる。したがって、修正は必ず元ファイルへ行い、その後で full_context.md を再生成する。

各ファイルの前に Source コメントを入れて連結すると、full_context.md の中でどの記述がどの元ファイルから来たのかを追跡しやすい。これは、AI にとっても人間にとっても有用である。AI が特定ルールを参照するとき、どのカテゴリの情報かが見える。人間が重複や矛盾を見つけたとき、修正対象の元ファイルをすぐ特定できる。

対象	役割	編集方針
個別 Markdown ファイル	人間が保守する正本。	直接編集する。
README.md	全体の読み方を定義するメタファイル。	構成や優先順位を変えたときに更新する。
compiled/full_context.md	AI に渡す全量統合版。	手で編集せず、スクリプトで再生成する。
compiled/minimal_context.md	日常利用向けの軽量版。	必要に応じて別スクリプトまたは手動方針で生成する。

15. Python スクリプトで full_context.md を生成する

分割された Markdown を AI に渡すには、一つの full_context.md に連結するのが扱いやすい。OpenAI の GPTs では、アップロードしたファイルを知識として使えることが説明されており[13]、ファイルアップロードにはサイズやトークンなどの制限がある[14]。したがって、外部 AI に持ち込む場合は、複数ファイルを毎回個別に扱うより、優先順位順に連結された単一ファイルを用意しておく方が単純である。

以下は、ai_context 配下の README.md、01_permanent_rules、02_durable_preferences、03_live_context、04_dated_records にある Markdown ファイルを順番に連結し、compiled/full_context.md を生成する Python スクリプトである。Python の pathlib は、ファイルシステムパスを扱う標準ライブラリとして、OS ごとの意味論を持つパスクラスを提供している[15]。この用途では、パス結合や相対パス処理を文字列連結で行わずに済むため扱いやすい。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import sys

SOURCE_DIRS = [
"01_permanent_rules",
"02_durable_preferences",
"03_live_context",
"04_dated_records",
]

OUTPUT_PATH = os.path.join("compiled", "full_context.md")

def read_text(path):
# Read Markdown content as UTF-8.
with open(path, "r", encoding="utf-8") as file_obj:
return file_obj.read().rstrip()

def collect_markdown_files(base_dir):
# Collect Markdown files in the intended priority order.
files = []

readme = os.path.join(base_dir, "README.md")
if os.path.isfile(readme):
files.append(readme)

for dirname in SOURCE_DIRS:
directory = os.path.join(base_dir, dirname)
if not os.path.isdir(directory):
continue

for filename in sorted(os.listdir(directory)):
path = os.path.join(directory, filename)
if filename.endswith(".md") and os.path.isfile(path):
files.append(path)

return files

def build_full_context(base_dir):
# Build one Markdown file from all context files.
output = os.path.join(base_dir, OUTPUT_PATH)
output_dir = os.path.dirname(output)

if not os.path.isdir(output_dir):
os.makedirs(output_dir)

files = collect_markdown_files(base_dir)

lines = [
"# Full AI Context",
"",
"Generated from ai_context files.",
"",
"---",
"",
]

for path in files:
relative_path = os.path.relpath(path, base_dir)
lines.extend(
[
"".format(relative_path),
"",
read_text(path),
"",
"---",
"",
]
)

with open(output, "w", encoding="utf-8") as file_obj:
file_obj.write("\n".join(lines))

return output

def main():
# Use the script location as the ai_context directory.
base_dir = os.path.dirname(os.path.abspath(__file__))
files = collect_markdown_files(base_dir)
output = build_full_context(base_dir)

print("Generated: {0}".format(output))
print("Included files: {0}".format(len(files)))

for path in files:
print("- {0}".format(os.path.relpath(path, base_dir)))

return 0

if __name__ == "__main__":
sys.exit(main())

このスクリプトの要点は明確である。SOURCE_DIRS で連結順を固定し、README.md を最初に入れ、各ディレクトリ内の Markdown をファイル名順に連結する。出力先は compiled/full_context.md であり、各ファイルの前には Source コメントを挿入する。Path(__file__).resolve().parent を使うことで、実行時のカレントディレクトリではなく、スクリプトが置かれた ai_context ディレクトリを基準にできる。最後に Included files を出力することで、想定したファイル数が含まれたか確認できる。

16. 実行方法と確認方法

スクリプトは、ai_context/build_full_context.py として保存する。実行方法は二通りある。リポジトリのルートから実行する場合は、python3 ai_context/build_full_context.py を実行する。ai_context ディレクトリへ移動している場合は、python3 build_full_context.py を実行する。いずれの場合も、スクリプト自身の場所を基準に処理するため、同じ結果になる。

生成されるファイルは ai_context/compiled/full_context.md である。実行後は、先頭、Source コメント、行数、含まれたファイル数を確認する。

1
2
3
4

python ai_context/build_full_context.py
head -40 ai_context/compiled/full_context.md
grep -n "Source:" ai_context/compiled/full_context.md
wc -l ai_context/compiled/full_context.md

生成結果が README.md だけになっている場合は、ディレクトリ構成がスクリプトの想定とずれている可能性が高い。たとえば、permanent_rules という名前で置いているのに、スクリプト側が 01_permanent_rules を見ている場合、README.md しか拾えない。この場合は、実際のディレクトリ名を 01_permanent_rules、02_durable_preferences、03_live_context、04_dated_records にそろえるか、SOURCE_DIRS を実際の名前に合わせて修正する。

症状	原因	確認方法	対応
Included files が 1 になる。	README.md しか見つかっていない。	ls ai_context でディレクトリ名を確認する。	SOURCE_DIRS と実ディレクトリ名を一致させる。
一部のファイルだけ入らない。	拡張子が .md ではない、またはサブディレクトリに入っている。	find ai_context -name “*.md” を確認する。	対象ファイルを直下に置くか、スクリプトを再帰対応にする。
文字化けする。	元ファイルの文字コードが UTF-8 ではない。	file コマンドやエディターで文字コードを確認する。	UTF-8 に変換して保存し直す。
順序が期待と違う。	同一ディレクトリ内はファイル名順で連結される。	ls でファイル名を確認する。	ファイル名に番号を付けて順序を明示する。

17. 他の AI に持ち込むときの指示文

full_context.md を他の AI に持ち込むときは、ファイルを添付するだけでなく、読み方を短く指示した方がよい。OpenAI の Projects は、チャット、ファイル、指示を一つの場所にまとめ、継続的な作業文脈を扱いやすくする機能として説明されている[16]。ただし、どの AI でも同じように文脈を読んでくれるとは限らない。したがって、添付時の冒頭指示で、優先順位と時点記録の扱いを明示する。

指示文の例は次の通りである。

1
2
3
4
5
6
7
8
9
10
11

添付した full_context.md は、私に対する応答方針・恒久ルール・長期方針・現在の運用状態・時点記録をまとめた正本コンテキストです。

この内容を優先して読み、以後の回答では次の優先順位で扱ってください。

1. 01_permanent_rules は恒久ルールとして常に優先する
2. 02_durable_preferences は長期的な判断方針として扱う
3. 03_live_context は現在の運用状態として扱う
4. 04_dated_records は時点記録として扱い、現在事実とは限らない

同一内容について矛盾がある場合は、より上位の分類を優先してください。
ただし、私がこの会話で新しく明示した指示がある場合は、その指示を優先してください。

この指示文の目的は、AI に「このファイルは単なる参考資料ではなく、利用者向け応答の正本コンテキストである」と認識させることである。特に、恒久ルールと時点記録の区別は重要である。時点記録を現在事実として扱うと、古い健康情報、古いサーバー構成、古い OS 判断、古いバージョン履歴が現在の判断を汚染する。

18. full_context.md と minimal_context.md を使い分ける

全量コンテキストは強力だが、常に必要とは限らない。full_context.md には、恒久ルール、長期方針、現在状態、時点記録がすべて入る。新しい AI サービスへ移行する、Enterprise 環境に登録する、長期プロジェクトを開始する、複雑な記事執筆やコードレビューを依頼する、といった場面では有効である。一方、日常的な短いやり取りでは重すぎる場合がある。

そのため、minimal_context.md を別に用意するとよい。minimal_context.md には、応答・対話の基本ルール、表記ルール、diff レビュー手順、HTML 生成ルール、参考文献ルール、主要な長期方針だけを入れる。健康情報、サーバー詳細、過去のログ、古いバージョン履歴などは、必要がない限り含めない。これにより、情報漏洩リスクとコンテキスト過多を避けられる。

ファイル	用途	含める情報	除外しやすい情報
full_context.md	新環境への引き継ぎ、長期作業、全量移植。	すべてのカテゴリ。	原則として除外しないが、外部共有時は機密情報を確認する。
minimal_context.md	日常利用、軽量な会話、外部 AI への安全な持ち込み。	恒久ルールと主要方針。	個人情報、健康情報、サーバー詳細、古い時点記録。
project_context.md	特定プロジェクト専用。	プロジェクト固有の要件、ファイル構成、作業方針。	プロジェクトに関係しない個人記録。

19. Git 管理する場合の運用

ai_context を Git 管理すると、ルールや方針の変更履歴を追跡できる。これは非常に重要である。AI 向けコンテキストは、自分の判断構造を外部化したものであるため、時間とともに変わる。いつ、どのルールを追加したか、どの方針を更新したか、どの記録を時点情報として移したかを追えることは、自己記述の保守性を高める。

compiled/full_context.md を Git に含めるかどうかは、運用方針による。生成物として扱うなら .gitignore に入れてよい。一方、他 AI へ持ち込む成果物として常に最新ファイルを保持したいなら、あえてコミットしてもよい。重要なのは、生成物を手で編集しないことである。

.gitignore の例は次の通りである。

1
2
3

# Generated context files
ai_context/compiled/full_context.md
ai_context/compiled/minimal_context.md

ただし、ai_context に個人情報、健康情報、サーバー情報、業務情報が含まれる場合、公開リポジトリに置くべきではない。private repository にするか、機密情報を別ファイルとして管理し、外部 AI へ渡す版から除外する必要がある。

20. 機密情報と個人情報をどう扱うか

AI コンテキストは便利だが、深い個人情報を含みやすい。健康情報、生活環境、業務情報、サーバー情報、アクセスログ、運用事故、リポジトリ状態、内部ルールなどは、外部 AI に渡す前に慎重に確認する必要がある。OWASP は LLM アプリケーションのリスクとして、プロンプトインジェクションや機密情報漏洩などを挙げている[17]。また、プロンプトインジェクションは、自然言語入力によってモデルの挙動を意図しない方向へ変える脆弱性として整理されている[18]。個人コンテキストを外部サービスへ渡す場合、このリスクを過小評価してはならない。

特に、API キー、パスワード、秘密鍵、トークン、管理画面 URL、内部 IP、公開していないサーバー構成、業務上の秘密情報は入れてはならない。健康情報や生活情報も、必要な AI に必要な範囲で渡すべきであり、全サービスに常時渡すものではない。full_context.md と minimal_context.md を分ける理由は、ここにもある。

NIST の AI Risk Management Framework は、AI に関するリスクを個人、組織、社会の観点から管理する枠組みとして提示されている[19]。個人の AI コンテキスト管理も、小さな AI リスク管理である。何を入れるか、何を入れないか、どの AI に渡すか、どの情報を時点記録にとどめるかを決める必要がある。

情報	full_context への格納	外部 AI への共有	方針
表記ルールや文体ルール	入れてよい。	共有してよい。	パーソナライズに有用でリスクが低い。
技術判断の方針	入れてよい。	内容を確認して共有する。	業務固有情報が混じる場合は注意する。
健康情報や生活記録	必要なら入れる。	原則として共有先を限定する。	minimal_context からは除外しやすい。
サーバー構成や運用事故	必要なら入れる。	公開 AI への共有は慎重に判断する。	ホスト名、内部構成、攻撃面を含む可能性がある。
認証情報や秘密鍵	入れない。	共有しない。	例外なく除外する。

21. この仕組みは AI を賢くするのではなく、ずれを減らす

AI コンテキストを整備しても、モデルの基礎能力そのものが上がるわけではない。論理能力、コード生成能力、検索能力、推論能力の限界は残る。OpenAI の GPT トラブルシューティングでも、知識ファイルがうまく使われない場合には、より明確でテキスト中心のソースファイルにすることや、必要な情報が実際にファイル内にあるか確認することが推奨されている[20]。つまり、ファイルを渡せば必ず正しく使われるわけではない。

それでも、AI コンテキストには価値がある。その価値は、AI を万能にすることではなく、利用者とのずれを減らすことである。ずれには、説明粒度のずれ、文体のずれ、前提のずれ、禁止事項の見落とし、過去情報の誤用、優先順位の誤解、判断基準の不一致がある。AI の回答に対する不満の多くは、能力不足そのものより、こうした解釈構造のずれから生じる。

AI コンテキストは、このずれを減らす。利用者が「レビュー」と言ったとき何を期待しているか、「最小差分」と言ったとき何を禁止しているか、「ブログ用」と言ったときどの HTML 構造を期待しているか、「参考文献」と言ったときどの番号規則を要求しているかを、AI にあらかじめ渡しておける。これにより、毎回の再説明が減り、修正往復が減る。

22. AI 活用は、質問力から文脈設計へ移る

これまで AI 活用では、プロンプトの書き方が強調されてきた。もちろん、明確なプロンプトは重要である。しかし、AI が一回限りの回答装置ではなく、継続的な作業相手になるほど、単発プロンプトだけでは足りなくなる。必要になるのは、どの情報を、どの形式で、どの優先順位で、どのタイミングで AI に渡すかという文脈設計である。

この流れは、AI 開発全体にも現れている。Anthropic の Model Context Protocol は、AI アシスタントをコンテンツリポジトリ、業務ツール、開発環境などデータが存在するシステムへ接続する標準として発表された[21]。Claude Code では CLAUDE.md のようなファイルを、プロジェクトに永続的な文脈を与える指示として扱う仕組みが説明されている[22]。Google Cloud の Gemini Enterprise でも、会話履歴やデータソースをパーソナライズに接続する設定が示されている[23]。OpenAI Academy も、Projects がファイル、チャット、指示をまとめ、継続的な作業文脈を安定させると説明している[24]。これらは製品ごとの機能差を持つが、共通しているのは、AI の出力品質が単発の質問文だけでなく、周辺に配置される文脈によって左右されるという点である。

つまり、AI 活用は、質問力だけでなく、文脈設計へ移っている。個人利用でも同じである。自分の暗黙知、判断基準、作業規則、関心、履歴をどう分類し、どの範囲を AI に渡し、どの範囲を秘匿し、どう更新し、どう持ち運ぶかが重要になる。これは、個人版のコンテキストエンジニアリングである。

23. 結論：AI に自分を覚えさせるのではなく、自分の文脈を自分で持つ

AI のパーソナライズは、好みを覚えさせることではない。より深く見れば、それは人間の暗黙知、判断基準、趣向、思想、作業規則、履歴を、AI が参照できる情報構造へ外部化することである。人間同士の知識共有でも、暗黙知はそのままでは伝わらない。Nonaka らの知識創造論が、暗黙知と形式知の相互変換、共有される場、知識創造のプロセスを論じたように[25]、AI との協働でも、内面にある判断構造を外部化し、再利用可能な形式へ変換する必要がある。

この外部化は、単なる自己紹介ではない。プロフィールは「自分は何者か」を書く。しかし、AI コンテキストは「自分の依頼、言葉、判断、過去情報をどう解釈してほしいか」を書く。そこには、恒久ルール、準恒久方針、更新型コンテキスト、時点記録が含まれる。これらを Markdown として分割管理し、README で優先順位を定義し、Python スクリプトで full_context.md に連結すれば、複数 AI に持ち運べる自己記述ができる。

AI に自分を覚えさせるだけでは、文脈はサービスの中に閉じる。自分の文脈を自分で管理すれば、AI サービスを越えて持ち運べる。これが複数 AI 時代のパーソナライズである。AI の内部記憶に依存するのではなく、利用者自身の判断構造を、可搬な情報として外部化する。AI に自分の文脈を持ち運ぶという実践は、技術的には Markdown とディレクトリと連結スクリプトの話であり、根本的には、人間の内面構造を情報として扱う新しい実務である。

参考文献

OpenAI, Memory and new controls for ChatGPT. https://openai.com/index/memory-and-new-controls-for-chatgpt/
Google, Gemini gets personal, with tailored help from your Google apps. https://blog.google/products-and-platforms/products/gemini/gemini-personalization/
Microsoft, Copilot personalization and memory. https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-personalization-memory
Michael Polanyi, The Tacit Dimension. https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html
Ikujiro Nonaka, A Dynamic Theory of Organizational Knowledge Creation. https://josephmahoney.web.illinois.edu/BA504_Fall%202008/Uploaded%20in%20Nov%202007/Nonaka%20%281994%29.pdf
Claude E. Shannon, A Mathematical Theory of Communication. https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf
David Chapman, Information, meaning and context. https://oro.open.ac.uk/29045/2/2B5B59E1.pdf
Anthropic, Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
GDPR-info.eu, Art. 20 GDPR – Right to data portability. https://gdpr-info.eu/art-20-gdpr/
ICO, Your right to data portability. https://ico.org.uk/for-the-public/your-right-to-data-portability/
CommonMark, CommonMark Spec. https://spec.commonmark.org/current/
Git, git Documentation. https://git-scm.com/docs/git
OpenAI Help Center, Creating and editing GPTs. https://help.openai.com/en/articles/8554397-creating-and-editing-gpts
OpenAI Help Center, File Uploads FAQ. https://help.openai.com/en/articles/8555545-file-uploads-faq
Python Documentation, pathlib — Object-oriented filesystem paths. https://docs.python.org/3/library/pathlib.html
OpenAI Help Center, Projects in ChatGPT. https://help.openai.com/en/articles/10169521-projects-in-chatgpt
OWASP, Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/
OWASP Cheat Sheet Series, LLM Prompt Injection Prevention Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
NIST, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework
OpenAI Help Center, Troubleshooting GPTs. https://help.openai.com/en/articles/11325361-troubleshooting-gpts
Anthropic, Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol
Anthropic Claude Code Docs, How Claude remembers your project. https://code.claude.com/docs/en/memory
Google Cloud, Configure personalization and memory | Gemini Enterprise. https://docs.cloud.google.com/gemini/enterprise/docs/configure-personalization
OpenAI Academy, Using projects in ChatGPT. https://openai.com/academy/projects/
Ikujiro Nonaka, Ryoko Toyama, Noboru Konno, SECI, Ba and Leadership. https://agileconsortium.pbworks.com/f/Nonaka_etal_2000_SECI.pdf