こんにちは！
グループ経営ソリューション事業部 アドバンストテクノロジー部の佐藤です。
突然ですが、日々の技術学習で、皆さんはどのように AI を活用しているでしょうか？
Copilot Chat と対話的に疑問を紐解いていく方もいれば、Genspark のような AI 検索エンジン派の方、最近だと ChatGPT Atlas といった AI ブラウザを駆使する方もいるでしょう。
このように、新しい知識を調べ、学習するために AI を活用することはもはや当たり前になりつつあります。
しかしながら、こうした「インプット」のノウハウは、AI 駆動開発のように何かを作り出す「アウトプット」の話題と比べると、語られる機会が少ない印象を受けます。
そこで、電通総研 Advent Calendar 2025 、16 日目の今日は、技術知識の学習における「メンタルモデル」の重要性を押さえつつ、自分だけのナレッジベースをAIと共創することでメンタルモデルの構築を効率化する実践的な学習スキームを紹介したいと思います。
技術知識を学ぶ理由
学習スキームの話に入る前に、少し立ち止まって「そもそも論」を考えてみたいと思います。
そもそも、私たちはなぜ技術知識を学ぶのでしょうか？
多くのエンジニアに共通する理由の一つとして
「興味や関心といった"知識欲"を満たすため」
があるかと思います。
これは、エンジニアにとって最も純粋かつ強力な、尊重されるべき動機です。エンジニアとして長く働き続けるための、必須要件とすら言えるかもしれません。
しかし、ビジネスの観点からは、これだけでは不十分です。
所属する組織、ひいては社会に対し価値を提供するために「知識をどう使うのか」という視座から、技術知識を学ぶ本質的な理由を考えなければなりません。
本稿では、それを 「意思決定の質を高めるため」 と捉えてみたいと思います。
意思決定への道標
ソフトウェア開発は、意思決定の連続です。
アーキテクチャの選定から変数の命名に至るまで、あらゆる活動は意思決定により駆動されます。
語弊を恐れずに言えば、あらゆる知識は、この「意思決定」に寄与することで、初めてビジネス上の価値を与えられます。
「技術知識は意思決定の根拠ではなく、 課題解決の手段 ではないか」
と思う方もいるかもしれません。
確かに、多くの技術知識の本質は手段です。しかし、知識が手段としての価値を発揮するか否かは、意思決定に依存しています。
例えば、Strategy パターンを知っていたとしても、「このコンポーネントは Strategy パターンで実装する」という意思決定が出来なければ、その知識は一行のコードも生み出すことはありません。
つまり、いかなる知識も、意思決定の土俵に上げられない限りは宝の持ち腐れとなってしまいます。
では、意思決定において適切な知識を動員し、質の高い決断を下すにはどうすれば良いでしょうか。
そのためのカギとなるのが、「メンタルモデル」 です。
メンタルモデルについては、弊社のアーキテクトである米久保さんの過去記事でも解説されています。
tech.dentsusoken.com
メンタルモデルの構築には、知識を点として暗記するのではなく、対象が持つ多面性を捉え、それが「何を解決するのか」「いつ適用できるのか」といった様々なコンテキスト上で概念化を行うことが重要です。
そのようにして構築された個々のモデルは、やがてアナロジーや対比などの認知作用によって相互に関連付けられ、言わば 「認知の地図」 を描き始めます。
この地図を心に広げることができれば、知識は 私たちを意思決定へと導いてくれる、確かな道標 に変貌するのです。
次章では、この「認知の地図」を描く際のパレットとなる自分だけのナレッジベースを、AIと共創する学習スキームを紹介します。
RTKB - Reviewable and Traceable Knowledge Base -
技術知識を AI で調べるとき、最も手軽で一般的なアプローチは、Copilot Chat などの AI チャットとの対話的な学習だと思います。
しかし、チャット上での対話は基本的に 使い捨てのフロー情報 であり、チャット履歴は知識の墓場になりがちです。
RTKB は、そんな漫然としたチャットから脱却し、AI からの回答を Reviewable かつ Traceable な形式知として管理することで学習効果を高めるアプローチです。
AI チャットに「聞くだけ」の学習に対する課題感から、筆者自身が実際に試行錯誤しつつ実践してきたアプローチを、本稿執筆にあたりブラッシュアップし、スキームとして定義しました。
大仰な名前を付けてはみましたが、仕組みはいたってシンプル です。
まずは、ローカル環境にナレッジベースのルートディレクトリを作成し、Cursor などの AI コーディングエディタでワークスペースとして開きます。
あとは、エージェントに学びたい知識の技術ドキュメントを作成してもらい、Git で構成管理するだけです。
これだけであれば、ただのドキュメントのフォルダ管理ですが、RTKB の要はプロジェクトに配置する AGENTS.md にあります。
このファイルに、 メンタルモデル構築に適したドキュメントの仕様 を厳格に定義することで、AI チャットにただ「聞くだけ」では得られない、学習効果の高い出力を引き出します。
ここからは実際の AGENTS.md を一部引用しつつ、ポイントを解説します。
※ AGENTS.md の全文や、実際に出力されたサンプルドキュメントは GitHub リポジトリ にて公開していますので、あわせてご確認ください
ドメインと品質の定義
AGENTS.md では、まずこのナレッジベースが扱う「技術的概念」のドメインを定義しています。
## Glossary - 技術的概念: - Computer Science のコンテクストにおける汎ゆる概念を示す - 技法・原理・原則・プロトコル・パターン・プラクティス・仕様・パラダイム などを含む
ここで「技術的概念」という言葉をあえて広義に定めることで、RTKB は特定の要素技術から抽象度の高い概念まで幅広く適用可能な汎用スキームとして機能します。
また、NON-NEGOTIABLE な規約として以下を明記することで、ハルシネーションを可能な限り抑制し、学習教材としての信頼性向上を狙います。
## 全ての文書において NON-NEGOTIABLE な遵守事項 - 技術的概念について記述する際は、**必ず厳密な技術用語を利用**する - 厳密とは、その言葉が対象の技術領域において広く一般的に使われる正確な言葉であるという syntactic な側面と同時に、意味的にも定義通りであるという semantic な側面の両方を満たす事を指す - 技術的概念に関して不明確な点がある場合に、推察や推論、憶測による根拠のない断定を行ってはならない。全ての文章は、事実に基づき記述される必要がある
TDL（Test-Driven Learning）
TDD のように、学習もテストから始めましょう。
## Comprehension Check 記載時の遵守事項 - `Comprehension Check` 章には、主要な技術的概念、技術文書の重要な論点/要点の理解度を問う簡潔なテストを箇条書きで記載する - 正誤を問う形式や選択肢問題ではなく、自由回答方式の設問とする - 技術文書の主題ならびに主要な技術的概念について、それ自体（WHAT）ではなく、それに関する WHAT FOR / WHY / WHEN の理解度を問う設問が望ましい - 重要な技術的概念と同じ問題空間を対象とした、異なる技術的概念が存在する場合、それとの違いを問う設問を含める
RTKB では、ドキュメントの冒頭に必ず Comprehension Check を設けています。
これにより、ドキュメントが Reviewable （＝復習可能）になると同時に、読者は「何を理解しなければならないか」を明確化したうえで学習を開始することができます。
なお、各設問では意思決定に向けて重要な観点である "WHY" や "WHEN" を 自由回答方式 で問うことを推奨しています。
この回答を通して、対象の概念を「自分の言葉」で説明するという営みは、メンタルモデルの構築にとって重要なファクターとなります。
ただドキュメントを読み返すのではなく、復習として Comprehension Check に取り組むことで、より効果的にメンタルモデルを構築することができます。
抽象と具体の分離
アーキテクト思考：メンタルモデル構築の重要性 でも説明されているとおり、メンタルモデルの構築には「抽象と具体の往来」が効果的です。
RTKB は、概念の解説（＝抽象）と、その適用事例の解説（＝具体）が必ずドキュメントに含まれる ようにスケルトンを定義しています。
## {WHAT/WHAT FOR/WHY/WHERE the CONCEPT IS FROM (the ORIGIN):主題と関わる技術的概念の解説}
- 文章形式での記述を優先し、必要に応じて項への分割、箇条書き・表を用いる
## {HOW/USAGE:技術的概念の使い方/機序/運営・運用/活動/メカニズム/アプローチ}
- 文章形式での記述を優先し、必要に応じて箇条書き・表を用いる
また、それらを異なる章に分離することで段落内の抽象度の揺らぎを回避し、概念理解から適用への思考フローと読書体験の摩擦を低減します。
問題空間の明確化
多くの技術的概念は、何らかの課題を解決する手段として機能します。
RTKB では、技術的概念が対象とする 問題空間 についても説明することを定めています。
また、ある概念の適用事例と併せて、その概念を「適用しない場合」を対比的に解説することで、問題空間をより鮮明に浮かび上がらせるよう図ります。
## 全ての文書において NON-NEGOTIABLE な遵守事項
- 技術的概念は、何らかの問題空間上の課題に対する解決空間で機能する。技術文書には、必ずこの問題空間上の課題の詳説と、それを理解するための関連する技術的概念まで含めて説明されなければならない
## {HOW/USAGE:技術的概念の使い方/機序/運営・運用/活動/メカニズム/アプローチ}
- 理解の促進のため、その技術的概念{を使わない場合/が存在しなかった時代}における具体例を初めに提示する
### {HOW/USAGE WITHOUT the CONCEPT:技術的概念 {を使わない/が存在しなかった時代} のアプローチ}
<!-- optional/if applicable:主題の技術的概念が存在しなければ解決不可能な課題である場合、本章は省略可能 -->
- コードによる実装例や、具体的な事例を示すことで、主題の技術的概念が存在しない場合にどのような問題があるかを詳説する
これにより、その技術的概念が「なぜ必要とされるのか」「いつ適用すべきか」といった 実践的なコンテキストにおける理解 が深まります。
加えて、その概念が対象とする問題空間を把握することにより、その空間を対象とする他の技術的概念とのアナロジカルな関連付け、すなわち 「認知の地図」の広がりも期待 されます。
トレーサビリティの確保
上述の通り、 AI とのチャット履歴は使い捨ての「フロー情報」であり、ナレッジベースに蓄積するストック情報とは一般的には相容れません。
しかし少し見方を変えると、 AI への質問履歴は理解に至るまでの軌跡 そのものであり、捨て去るには惜しい情報とも思えてきます。
そこで RTKB では、質問履歴をチャットに埋もれさせず Traceable に文書化するための規約も定めています。
## 質問回答時の遵守事項 既存の技術文書に関して、ユーザーからの質問を受領した場合は、以下の方針に従う。 ### WHAT IS THIS:技術的概念の定義に関する質問 - 技術的概念そのものの定義を確認する質問の場合は、`Glossary` 章に追記する ### FOLLOW UP QUESTIONS:方法や理由、目的、意図を問う質問 - 技術文書に記載された内容に関する、理解を深めるための follow up questions に対しては、`Dialogue for Understanding` に質問の要約と回答を追記する - 質問が、`Dialogue for Understanding` の回答に対する追加の質問の場合は、新たな"Q"節は設けず、既存の回答に追記する
RTKB の学習フロー
ここまで解説してきた AGENTS.md により作成される技術ドキュメントを軸に、RTKB では以下のフローで学習を行います。
学習トピックのバックログ管理
- 仕事やプライベートで出会った「ちゃんと説明できないな」「詳しく理解したいな」といったトピックを、任意のツールでバックログ管理しておきます
- マイナーな技術や、複数のバージョンが存在するライブラリにおける特定バージョンのAPIの使い方など、AI が誤りやすいトピックについては、RTKB の対象外として管理することを推奨します
問いかけ
- 学習トピックについて「分からないことが分からない」状態であれば、学ぶべき技術的概念を対話的に定めます
- 自身の理解の程度を示しつつ対話することで、ドキュメントが扱うスコープの最適化が期待されます
ドキュメント作成依頼
- 学習したい対象が明らかになったら、ドキュメントの作成をエージェントに依頼します
- 実装例で使用する言語の指定や、
AGENTS.md記載ルールの範囲内における詳細度などの調整は可能です
- 実装例で使用する言語の指定や、
- 冒頭の Comprehension Check を確認し、学習のゴールをイメージしたうえで、読み始めます
- 回答例は
▶ Answersを押下すると展開表示されます
- 回答例は
深堀り
- 読み進めていくなかで、疑問点があればエージェントに質問します
- エージェントは、ユーザーからの質問に合わせてドキュメントを適切に追記/修正してくれます
Review
- 空き時間を使って Comprehension Check による復習を実施します
- ナレッジベースを GitHub 上で管理していれば、アプリを使って 移動中などの隙間時間で復習が捗る のでお勧めです
さいごに：AI 時代における意思決定の重要性
冒頭に記載したとおり、ソフトウェア開発は意思決定の連続です。
これをもう少し解像度を上げて見ると、日常の活動は、意思決定に先行する「方針検討」と、意思決定に基づく「遂行」から構成されると言えるでしょう。
今日の AI は、詳細設計に基づくコーディングのような具体的な「遂行」作業だけでなく、抽象度が高く複雑な「方針検討」タスクでさえも、その高度な推論能力により高い精度でこなせるようになりつつあります。
意思決定の前後が急激に「時短」されたことにより、私たちが ある期間に下さなければならない意思決定の数は、数年前とは比べ物にならない程増加 しています。
そして、この 「意思決定の時間密度」はこれからも高まり続けていく と考えられます。
だからこそ、来る AI 時代において、より迅速かつ的確な決断を下せるよう、私たちはこれからも様々な技術を学び続け、「認知の地図」を拡張していく必要があるのではないでしょうか。
その一つのアプローチとして、本稿で紹介した RTKB が少しでも皆さんのご参考となれば幸いです。
* 本稿に掲載された画像は AI により生成されました
執筆：@satorin
レビュー：@miyazawa.hibiki
（Shodoで執筆されました）
