思考を外部化して生成AIで
活用する情報設計——
「書かせる」から
「任せる」へ

生成AIに文章を頼んで、出てきたものを見て違和感を覚えたことはないでしょうか。
情報は正確で、構成も整っている。
でも、自分では絶対に使わない言い回しが混ざっていて、どこか他人の文章を読んでいる感覚が残ります。

<svg class="eyecatch-svg" viewBox="0 0 192 192" xmlns="http://www.w3.org/2000/svg">
  <!-- 背景 -->
  <rect width="192" height="192" rx="32" ry="32" fill="white"/>

  <!-- カードスタック:3層構造 -->
  <!-- 変遷ログ(後ろ・差分ログ) -->
  <rect x="52" y="88" width="104" height="60" rx="6" ry="6" fill="#BBDEFB"/>
  <!-- テーマ別資料(中間・呼び出しコンテクスト) -->
  <rect x="44" y="76" width="104" height="60" rx="6" ry="6" fill="#42A5F5"/>
  <!-- 判断軸ファイル(前面・常時コンテクスト) -->
  <rect x="36" y="64" width="104" height="60" rx="6" ry="6" fill="#1565C0"/>

  <!-- 前面カードの3本ライン(3階層・幅が徐々に短くなる) -->
  <line x1="50" y1="84" x2="122" y2="84" stroke="white" stroke-width="5" stroke-linecap="round"/>
  <line x1="50" y1="95" x2="108" y2="95" stroke="white" stroke-width="5" stroke-linecap="round"/>
  <line x1="50" y1="106" x2="94" y2="106" stroke="white" stroke-width="5" stroke-linecap="round"/>

  <!-- AI接続ノード(アンバーバッジ) -->
  <circle cx="146" cy="60" r="16" fill="#FFB300"/>
  <!-- ネットワーク三角形(AI参照の接続を表現) -->
  <line x1="139" y1="64" x2="153" y2="64" stroke="white" stroke-width="2" stroke-linecap="round"/>
  <line x1="139" y1="64" x2="146" y2="53" stroke="white" stroke-width="2" stroke-linecap="round"/>
  <line x1="153" y1="64" x2="146" y2="53" stroke="white" stroke-width="2" stroke-linecap="round"/>
  <circle cx="139" cy="64" r="3" fill="white"/>
  <circle cx="153" cy="64" r="3" fill="white"/>
  <circle cx="146" cy="53" r="3" fill="white"/>
</svg>思考を外部化して生成AIで<br class="chiilabo-br is-on">活用する情報設計——<br class="chiilabo-br is-on">「書かせる」から<br class="chiilabo-br is-on">「任せる」へ

これは使い方の問題ではなく、設計の問題です。

関連記事

1. AIが平均値を返す理由

1. AIが平均値を返す理由

ChatGPTにせよClaudeにせよ、AIは入力されたコンテクストをもとに出力を生成します。
「〇〇について記事を書いて」という一行だけが入力されていれば、AIが参照できるのもその一行だけです。
判断軸がなければ、ネット上に存在する似たコンテンツの統計的な平均値に近い文章が返ってきます1。

「書かせる」と「任せる」の差は、ここにあります。

「書かせる」は丸投げです。
判断軸を共有していない相手に投げているので、出てくるものは誰が頼んでも似たような内容になります。
「任せる」は委譲です。
「この人はどう考えるのか」をAIが参照できる形で渡したうえで、実行を委ねます。
コードレビューの方針も、表現の好みも、何を優先して何を捨てるかも、事前に渡していなければAIは推測するしかありません。
推測の根拠がなければ、平均値に着地します。

では、何をどう渡せばよいのか。

1.1. コンテクスト設計という問題

1.1. コンテクスト設計という問題

「全部渡せばいい」という発想は方向として正しいですが、すぐ限界に当たります。
AIには一度に読める情報量の上限があり、コンテクストサイズ(Context Size)と呼ばれます2。
自分のメモや資料を全部貼り付けようとすると、あっという間にその上限を超えます。
かといって何も渡さなければ平均値しか返ってこない。

この問題への答えは「何を渡すか」の設計にあります。

コーディングの文脈では、すでにこの設計が実践されています3。
AGENTS.mdやCLAUDE.mdにプロジェクトの方針を書いておき、テーマごとにディレクトリを分けて、変更理由をgitのコミットに残す。
AIに渡す情報を「常に読む上位方針」「必要なときだけ参照する詳細」「変化の記録」という3つの役割に分けて管理する構造です4。
同じ考え方を、文章生成や思考管理に持ち込むとどうなるか。

2. 3層の構造——判断軸ファイル、テーマ別資料、変遷ログ

自分の思考を外部化してAIに活用させるためには、情報を3つの役割に分けて管理します。

2. 3層の構造——判断軸ファイル、テーマ別資料、変遷ログ
  • 判断軸ファイルは、AIが毎回読む常時コンテクストです。
    自分の経歴や原体験、価値観、仕事観、文章表現のルール、避ける言い回し、好む論理展開——「この人はどういう背景を持ち、何を大事にし、どう判断するのか」を圧縮したひとつのファイルです。
    AGENTS.mdに近い役割で、これを読ませることがすべての起点になります。
  • テーマ別資料は、必要なときだけ読む呼び出しコンテクストです。
    仕事観、テクノロジー観、組織論、ノート術など、テーマごとに詳細な考えを分けて置いておきます。
    仕事について書くなら「判断軸ファイル+仕事観」を読ませ、テクノロジーについて書くなら「判断軸ファイル+テクノロジー観」を読ませる。
    全部を毎回渡さないことがポイントで、コンテクストサイズの節約にもなります。
    NotebookLMでノートブックやソースをテーマごとに切り替えて使う感覚に近いです5。
  • 変遷ログは、判断軸の変化を記録する差分ログです。
    「いつ、何を、なぜ変えたか」を残しておきます。
    gitのコミットログと同じ役割で、現在の判断軸ファイルに、その形成の経緯を紐付けられます6。
    判断軸は時間とともに変わります。
    変遷ログがなければ、それは「思考の更新」ではなく「気分の揺れ」と区別できなくなります。

3つをまとめると、次のような対応になります。

層機能コーディングでの対応
判断軸ファイル常時コンテクストAGENTS.md / CLAUDE.md
テーマ別資料呼び出しコンテクストプロジェクトディレクトリ
変遷ログ差分ログgitコミット履歴

2.1. 外部化のプロセス

2.1. 外部化のプロセス

この3層を作るとき、「さあ書こう」と構えると止まります。
思考は、構えていない場所に漏れ出しています。
日常の会話ログ、仕事でのチャット発言、移動中の音声メモ——「建前ゼロ」の場所に、判断軸の断片が現れやすいです。

素材が集まったら、AIに要約させるのではなく、構造化と格納先の判定をさせます。
たとえばこういうプロンプトです。

このテキストを読んで、繰り返し出てくるこだわり、強い違和感を持っている対象、
判断に使っている基準、一般論からズレている視点を抽出してほしい。
そのうえで、判断軸ファイルに入れるべきか、テーマ別資料のどこに入れるべきかを
分類して教えて。

「要約」と「構造化」は別の作業です。
要約は情報を圧縮します。
構造化は情報を再利用可能な単位に変換します。
このプロンプトが機能するのは、出てきた内容をそのまま3層のどこかに書き戻せるからです。
単に「まとめて」ではなく、分類先まで含めてAIに判定させる点がポイントです。

なお、プライベートな会話ログや仕事の発言ログを素材にする場合は、相手の名前や案件名など他者に関わる情報を除いたうえで、自分の発言に絞って渡すのが適切です。

3. 実際の使い方

短文の投稿であれば、判断軸ファイルだけを読ませて書かせるのがシンプルです。

3. 実際の使い方

長文記事では、テーマに応じた判断軸ファイルとテーマ別資料をセットで読ませます。
参照させてから書かせた初稿は、何も渡さずに書かせた場合と比べて、表現レベルではなく論理の前提と判断の軸が変わります。
「自分では絶対に使わない言い回し」という違和感が消えていきます。

企画や事業構想では、判断軸ファイル全体を読ませたうえで「この判断軸を持つ人間が今の時代に何をすべきか」を一緒に考えさせます。
AIが返してくる案が最初から自分の価値観に整合するため、「筋は通っているが自分には合わない案」というノイズが減ります。

3.1. 重要なのはリポジトリ側

3.1. 重要なのはリポジトリ側

どのAIを使うかより、何を読ませるかが出力の質を決めます。
フロントのAIが変わっても、判断軸ファイルとテーマ別資料が手元にあれば、新しいモデルへの乗り換えコストはほぼゼロです。

以前NotebookLMの記事で「ノートの終点が保存から生成に変わった」という話をしました7。
思考の外部化も同じ方向を向いています。
メモとして書き留めるだけなら従来のノート術です。
AIが参照できる3層の構造にしておくと、思考は保存物ではなく、出力を生む素材になります。

コーディングで当たり前になっていることを、文章生成や思考管理に持ち込む——そう捉えたとき、この設計の意味がいちばん素直に見えてきます。

  1. 大規模言語モデル(LLM)は入力された文脈をもとに、統計的に次のトークンを予測して文章を生成します。判断軸となる固有の文脈が入力されていなければ、学習データの分布に引っ張られた「平均的な文章」になりやすい点はAnthropicの公開技術資料でも触れられています。 – Building Effective AI Agents | Anthropic
  2. 2025年時点でのClaudeの場合、標準モデルは最大20万トークン(テキストで約500ページ相当)のコンテクストウィンドウを持ちます。Claude Opus 4.6やSonnet 4.6は有料プランで最大100万トークンまで拡張されています。ただし、コンテクストが大きくなるほど処理コストも増えるため、何を入れるかの選別は常に重要です。 – How large is the context window on paid Claude plans? | Claude Help Center
  3. CLAUDE.mdはClaude Codeがプロジェクトのルートディレクトリに置いたとき、セッション開始時に毎回自動的に読み込むマークダウンファイルです。コーディング規約、アーキテクチャの方針、使用ライブラリの制約など、プロジェクト全体に共通する判断の前提を記述しておきます。AGENTS.mdは同種の役割を持つファイルで、OpenAIのエージェント向け仕様として広まっています。 – Overview – Claude Code Docs
  4. Anthropicはこのアプローチを「コンテクストエンジニアリング」と呼び、「常に読む情報」と「必要なときだけ読む情報」の設計が高品質なエージェントの鍵だと説明しています。Claude CodeのCLAUDE.mdを起点に必要なファイルだけを逐次参照するハイブリッド戦略がその実例です。 – Effective context engineering for AI agents | Anthropic
  5. NotebookLMではソースパネルで特定のソースだけを選択してチャットする機能があります。ノートブック自体をテーマ別に分けて管理し、案件・目的ごとに参照するソース群を切り替えるのが基本的な使い方とされています。 – Add or discover new sources for your notebook | NotebookLM Help
  6. gitでは変更を保存するときにメッセージを付けます(コミットメッセージ)。公式チュートリアルでは50文字以内の要約を1行目に、空行のあとに詳細を続けることを推奨しています。「何を変えたか」だけでなく「なぜ変えたか」を残す文化が広まっています。 – Git – gittutorial Documentation | git-scm.com
  7. chiilabo.jpの記事「NotebookLMは、対話できるデジタルノート」では、ノート術50年の変遷とNotebookLMの位置づけを詳しく解説しています。Evernote世代では「保存が終点」だったものが、NotebookLM世代では「生成の起点」に変わったという流れを歴史的に整理しています。 – NotebookLMは、対話できるデジタルノート(ノート術とテクノロジー) | Chiilabo Note