コンテキストエンジニアリングは、AIが処理する時点で必要な指示、資料、履歴、ツール結果などを選び、更新して渡す設計です。ファイルを保存するだけでは、その内容をAIが読み、正しく使うところまで完了したことにはなりません。
この記事では、実行時に必要な情報と、社内で管理するファイルの分け方を区別し、架空の問い合わせ返信で具体化します。
コンテキストエンジニアリングとは?定義をひとことで
対象は指示文だけでなく、その時点でモデルに渡る情報全体です。必要な情報を検索して追加する、古い状態を入れ替える、不要な履歴を減らすことも含みます。情報が多いほどよいわけではなく、今回の仕事に必要な根拠を選びます。
Anthropicのコンテキスト設計の解説(2026年10月10日確認)。
なぜ今、コンテキスト構築が重要なのか
生成AIの性能そのものは、モデル提供会社が同じであればどの会社にも平等に開放されています。しかし実際にAIを使っている現場を見ると、成果には大きな差が出ています。プロンプトを工夫しても頭打ちになる会社がある一方で、AIが実務の大部分を任され続けている会社もあります。この差の正体が、コンテキストエンジニアリングに取り組んでいるかどうかです。
差が生まれる理由は単純で、AIは渡された文脈の外にある情報を知らないからです。自社の商品、顧客の属性、過去にうまくいったやり方、やってはいけないこと——これらは会社の中にしかなく、AIが自動的に察してくれるものではありません。プロンプトエンジニアリングだけに頼っている会社は、この文脈を毎回のチャットの中で口頭説明のように渡しており、説明者のスキルと体調に成果が左右されます。一方でコンテキスト構築を進めている会社は、この文脈をファイルとして先に用意しておくため、依頼時の前提をそろえやすくなります。ただし、担当者・モデル・実行環境が変わった場合も、同じ課題で出力を確かめる必要があります。今、この差が急速に広がっているのは、AIに任せられる業務の範囲そのものが広がり、渡すべき文脈の量も比例して増えているためです。
この差は時間が経つほど広がっていく性質を持っています。コンテキストを積み上げている会社は、日々の仕事の中でNG集や判断基準が自然に増えていき、半年後には最初と比べ物にならないほど精度の高い土台ができあがります。逆にプロンプトの工夫だけで乗り切ろうとしている会社は、担当者が変わるたびにゼロからやり直しになり、蓄積が起きません。今このタイミングでコンテキスト構築に取り組むかどうかが、数か月後のAI活用の差になって現れます。
コンテキストを構成する4つの要素
| 観点 | 問い合わせ返信なら |
|---|---|
| 指示 | 事実と未確認事項を分ける |
| 知識 | 現在の商品資料と価格 |
| 履歴 | 関連する過去のやり取り |
| 状態 | 今回の在庫確認がまだ終わっていない |
これは業務を点検するための4分類です。すべての仕事へ4種類を必ず足すという意味ではありません。検索や外部ツールから得る最新結果も、出典と時点を確かめて必要な情報として使います。
プロンプトエンジニアリングとの違い
| 比較 | プロンプトの設計 | コンテキスト全体の設計 |
|---|---|---|
| 対象 | 依頼・規則・例などの書き方と構成 | 指示に加え、資料・履歴・ツール結果などの選択と更新 |
| 再利用 | 雛形として保存、共有、版管理できる | 情報源と参照手順を保存、更新できる |
| 確認 | 意図が伝わり出力条件を満たすか | 必要な情報を実際に参照し、古い情報を混ぜていないか |
両者は補い合います。ファイルを更新しても、読み込まれなければ今回の出力には使われません。
コンテキスト構築の3層設計——ルール・ナレッジ・メモリ
ルール・ナレッジ・メモリの3層は、社内で情報を保管し管理する一つの設計案です。先ほどの4分類は実行時に何の情報が必要かを見る軸で、同じ分類ではありません。各ファイルに更新者・出典・適用範囲を付け、必要な部分を今回の入力へ取り出します。
| 管理する場所 | 入れるもの | 更新時の確認 |
|---|---|---|
| ルール | 許可範囲、出力形式、不明値の扱い | 責任者が変更を承認 |
| ナレッジ | 商品や手順の事実と出典 | 元資料・適用日を照合 |
| 作業記録 | 完了・保留・次の行動 | 現在地と過去の記録を混ぜない |
ルール層——CLAUDE.mdに会社の憲法を書く
ルール層は、会社やチームが何があっても変えない前提を書く場所です。目的、価値観、絶対にやってはいけないこと、意思決定の優先順位などが該当し、更新頻度は低く保つのが原則です。AIエージェントを使う環境では、この役割をCLAUDE.mdのようなファイルが担い、AIは作業の前に必ずこれを読み込んでから動きます。ルール層がしっかりしていると、担当者やAIが変わっても判断の軸がぶれません。たとえばルール層に「顧客への返信は必ずですます調で書き、根拠のない誇大表現は使わない」と明記しておけば、担当するAIの数が増えても文体と誠実さの水準がぶれることはありません。具体的な書き方や構成の作り方はCLAUDE.mdの書き方で詳しく解説しています。
ナレッジ層——業務ファイルに実務知識を渡す
ナレッジ層は、業務ごとの知識・判断基準・手順を書く場所で、ルール層と違って業務が増減・変化するたびに更新されます。「メルマガ執筆」「請求書発行」「問い合わせ対応」のように1業務1ファイルで分けて持つのが基本で、AIはその業務にあたるときに該当ファイルだけを読み込みます。ナレッジ層を丁寧に作るほど、AIへの指示は短くて済むようになります。たとえば請求書発行のナレッジファイルに、宛名の書式や振込先の記載順、金額の丸め方まで書いておけば、「今月分の請求書を作って」という一言だけで、毎回同じ体裁の請求書が仕上がります。1業務1ファイルの分け方や書き方の具体的な手順はナレッジ構築の記事で5ステップに分けて解説しています。
メモリ層——日々の記録で経験を蓄積する
メモリ層は、日々の作業の中で起きた気づき・決定事項・修正内容を記録していく場所です。更新頻度は3層の中でもっとも高く、毎日、あるいは作業の区切りごとに追記していきます。メモリ層があると、AIは「前回何が起きたか」「なぜその決定をしたか」を踏まえて次の作業に取り組めるようになり、同じ説明を毎回繰り返す必要がなくなります。たとえば「先週のキャンペーンでは価格訴求よりも事例訴求の方が反応が良かった」という1行がメモリ層に残っているだけで、次回の企画からその学びを踏まえた提案が返ってきます。メモリ層の記録のうち、繰り返し使う恒久的な判断はナレッジ層やルール層に昇格させていくと、3層が噛み合った状態を保てます。
今日からできるコンテキスト構築の実践4つ
コンテキストエンジニアリングと聞くと、専門的なツールやプログラミングの知識が必要に思えるかもしれませんが、実際に必要なのは書く習慣だけです。ここでは、今日から始められる実践を4つに絞って紹介します。特別な準備は要らず、テキストファイルとメモ帳があれば十分に始められます。共通しているのは「書いたその日からAIの働きが変わる」という即効性なので、完璧な内容でなくても、まず1つ手を付けてみることが継続の一番の近道になります。
実践1 自己紹介ファイルを作る
まず、自分自身や会社について書いた自己紹介ファイルを1枚作ります。役割、大事にしている価値観、よく使う言い回し、絶対に避けたい表現などを箇条書きで書くだけで構いません。たとえば「語尾は敬体で統一する」「専門用語は使わず、専門外の取引先にも分かる言葉で説明する」「返信は必ず結論から書く」といった項目を5〜10個書くだけで、初稿の質は大きく変わります。AIに何かを依頼する前にこのファイルを読ませておくと、初回のやり取りから的外れな回答が大きく減ります。人間の新しい同僚に自己紹介するつもりで書くと、必要な項目が自然と揃います。
実践2 「なぜ」を書く
理由と適用範囲を添えると、人もAIも規則を確認しやすくなります。ただし理由を読んだから別の約束を勝手にしてよいわけではありません。「値引きしない。条件変更は担当者へ確認する」とし、納期短縮や特典追加も未承認の約束として扱います。
実践3 NG集を育てる
誤りから規則を足す場合は、元の状況と理由、適用範囲を残し、担当者の確認後に反映します。禁止を増やすだけでは矛盾が生じるため、古い規則との重複も見直します。追記後は参照できたかと、同じ入力で誤りが減ったかを再確認します。
実践4 結果を書き戻す
出力の誤りを直すときは、根拠・修正案・適用範囲を残します。担当者が承認してから正本へ反映し、同じ依頼で参照と出力を再確認します。一度の指摘を、検証なしで会社全体の規則にしないようにします。
コンテキスト設計の効果を同じ課題で測る
効果は、資料を増やした量ではなく、同じ入力での事実誤り、要確認の漏れ、人の修正時間で見ます。モデルや資料版、依頼が違う試行を比べる場合は、その条件差も残してください。
コンテキスト構築に使うツール——ObsidianとClaude Code
コンテキスト構築自体はテキストファイルとメモ帳だけでも始められますが、ファイルの数が増えてくると、保管場所と参照のしやすさを考えたツール選びが効いてきます。私たちが実務で使っているのは、保管にObsidian、実行にClaude Codeという組み合わせです。
ObsidianはフォルダとMarkdownファイルでナレッジを管理できるツールで、特定のサービスにデータを囲い込まれない点と、ファイル同士をリンクでつなげる点が、コンテキスト構築との相性の良さにつながっています。ルール層・ナレッジ層・メモリ層をそれぞれフォルダで分けて保管しておくと、後から参照する際に迷いません。ファイルの分け方や運用の具体的な作り方はObsidianで第二の脳を作る方法で紹介しています。
実行側では、Claude Codeのようなエージェント型AIにフォルダごとアクセスさせ、「作業前に該当ファイルを必ず読む」というルール自体をコンテキストの中に書いておきます。こうしておくと、AIは依頼のたびに毎回ファイルを開いて読み込んでから作業するようになり、コンテキストエンジニアリングの効果を人手を介さずに引き出し続けられます。ツールはあくまで器であり、重要なのは中に書く内容そのものだという点は変わりません。
ツールを選ぶ際の基準はシンプルで、テキストファイルとフォルダとしてデータを持ち出せるかどうかです。特定のSaaSの中にしかコンテキストが存在しない状態は、そのサービスを解約した瞬間に土台ごと失うリスクを抱えます。ObsidianもClaude Codeも、実体はローカルのMarkdownファイルであるため、将来ツールを乗り換える場合でも、書き溜めてきたコンテキストそのものはそのまま引き継げます。この「持ち運べる」という性質は、コンテキストを長期の資産として考えるなら欠かせない条件です。逆に言えば、ObsidianやClaude Codeでなくても、フォルダとテキストファイルで管理できる形になっていれば、他のメモアプリやエージェント型AIに乗り換えても同じ考え方がそのまま通用します。
3ファイルで試す参照と更新の具体例
架空の文具店の問い合わせを3ファイルで試す例です。ファイル数自体に意味はなく、変わる情報を切り分けるための配置です。
rules.md:丁寧な返信案を作る。資料にない価格・在庫・納期は確定しない。
product.md:赤いノートは500円。在庫はこの資料に記載なし。
case.md:問い合わせは「明日届きますか」。配送確認は未実施。3ファイルを読み、返信案と担当者の確認項目を作ってください。
参照したファイル名を示し、外部には送らないでください。期待する結果は、価格500円を保ち、翌日配送を約束せず、在庫と配送条件を要確認にすることです。次にproduct.mdを600円へ更新し、参照先が旧版のままにならないかを確かめます。保存・読込・正しい出力の3段階を別々に記録します。この例は未実行の検証提案です。
コンテキスト構築のよくある失敗パターンと回避策
コンテキスト構築に取り組む中で、私たちが自社と支援先で見てきた典型的なつまずきを整理しました。どれも事前に知っていれば避けられるものばかりで、共通しているのは「気合いで乗り切ろうとして仕組み化を後回しにする」という構造です。
| 失敗パターン | なぜ起きるか | 回避策 |
|---|---|---|
| プロンプトだけをひたすら工夫し続ける | コンテキストという土台の存在を知らない | まずルール・ナレッジ・メモリの3層を1つずつ作る |
| ルールだけ作ってナレッジを作らない | 全社共通の方針で個別業務がカバーできると誤解する | 業務ごとにナレッジ層のファイルを分けて作る |
| メモリ層を作らず毎回同じ説明を繰り返す | 日々の記録を残す習慣がない | 日次ログをまず1行からでも書き始める |
| 1つの巨大ファイルに全部詰め込む | ファイルを分割する発想がない | 1業務1ファイルの原則で分割する |
共通しているのは、コンテキストという土台の存在そのものを知らないか、3層のどれか1つだけに偏ってしまうことです。まずは小さく3層を1つずつ作り、実際にAIに読ませながら直して育てていくことが、遠回りに見えて実は最短の進め方です。失敗に気づいた時点で完成度の低いファイルを恥じる必要はありません。粗くても書いて動かしてみることの方が、机上で完璧な設計図を作り続けることよりずっと価値があります。
法人・個人でコンテキストエンジニアリングを始めるには
ここまで、コンテキストエンジニアリングの考え方と3層設計、今日からできる実践を見てきました。実際に着手する段になると、法人として組織的に導入したい場合と、個人として自分のスキルとして身につけたい場合とで、進め方が変わってきます。どちらの立場から始めるにせよ、土台となる考え方(ルール・ナレッジ・メモリの3層)は共通しています。違うのは、それを1人で書き進めるのか、代行してもらいながら組織に定着させるのかという進め方だけです。
法人でコンテキストエンジニアリングを導入したい場合
対象業務を一つ選び、現在使う資料と出力の見本を用意します。資料の正本、更新する担当、使ってよい範囲を社内でそろえ、3ファイルの例のように更新後の参照まで確認します。複数部署へ広げるのは、閲覧権限と確認担当を決めてからです。
個人でコンテキストエンジニアリングを学びたい場合
経営者・個人事業主が自分の手でコンテキストエンジニアリングを身につけたい場合は、PLaiの実務ノウハウを体系化した講座AGI CAMPで、本記事の3層設計と実践4つを実際に手を動かしながら習得できます。
実務で試すときに確認したいこと
文脈は多ければよいわけではなく、今回の仕事に必要な情報を選ぶことが重要です。会社の前提、業務ルール、今回の資料、依頼を分け、矛盾や古い条件が混ざらないようにします。出力がずれたら指示を長くする前に、必要な資料へ到達できたかを確認してください。
この記事の「必要な文脈を渡す4つの層」を、自社の業務[業務名]に置き換えて検討します。
前提:[現在の手順・使ってよい資料・確認担当]
確認したいこと:情報を増やす前に、必要な資料が参照されたかを確かめていますか?
上の資料で分かること、不明なこと、最初に確認することを分けて整理してください。事実や実績を作らず、提案には理由を添えてください。外部送信や設定変更は行わず、検討用の案を出してください。よくある質問
Q. コンテキストエンジニアリングとプロンプトエンジニアリングはどちらを先に学ぶべきですか?
A.順番にこだわる必要はありませんが、迷う場合はプロンプトエンジニアリングの基本に軽く触れつつ、並行してコンテキスト構築に着手するのがおすすめです。良いプロンプトの感覚を知ることは、AIに何を渡せば伝わるかを理解する助けになります。ただし成果を長期的に安定させたいなら、最終的にはコンテキストエンジニアリングへの投資が効いてきます。プロンプトの工夫は書いた本人の中にしか残りませんが、コンテキストはファイルとして残り、次のやり取りにもそのまま活きるからです。どちらか一方だけで終わらせず、両方を並行して育てていく姿勢が、最も安定した成果につながります。
Q. コンテキスト構築を始めるのに専門知識やプログラミングは必要ですか?
A.必要ありません。コンテキスト構築の実体はテキストファイルに文章を書くことで、必要なのは自社の業務や判断基準を言葉にする力だけです。本記事で紹介した実践4つも、自己紹介ファイルを書く、理由を添える、NG集を育てる、結果を書き戻すという、どれもプログラミングとは無関係な作業です。ツールに慣れてきたらObsidianのような専用ツールやエージェント型AIを併用すると効果を引き出しやすくなりますが、最初の一歩はメモ帳でも十分です。書くこと自体に苦手意識がある場合は、AIに質問形式でインタビューしてもらい、答えた内容を文章化してもらう方法も有効です。
Q. ルール・ナレッジ・メモリの3層は必ず全部揃える必要がありますか?
A.最初から3層すべてを完璧に揃える必要はありません。まずはナレッジ層、つまり日々の業務ファイルから着手し、迷ったときの判断基準が固まってきたらルール層としてまとめ、日々の気づきはメモリ層に記録していくという順番で自然に揃っていくことが多いです。大事なのは3層のどれか1つに偏らず、抜けている層があると気づいたら、そのつど少しずつ埋めていく姿勢です。抜けている層に気づいた時点で、慌てず1つずつ埋めていけば十分です。
Q. コンテキスト構築の効果はどのくらいで実感できますか?
同じ課題で、事実の誤り、要確認の漏れ、修正時間を測ります。資料を保存した直後に必ず効果が出るとは限りません。必要な情報が読み込まれたか、出力が期待値に合うかを確かめてください。
Q. 個人のタスク管理にもコンテキストエンジニアリングは使えますか?
A.使えます。会社組織に限らず、個人が自分専用のAIアシスタントに仕事を任せる場面でも考え方は同じです。自分の役割や好みを書いた自己紹介ファイル、よく行うタスクの手順、過去にうまくいかなかったことのNG集を用意しておくだけで、個人利用のAIとのやり取りも大きく安定します。会社の規模でなくても、コンテキスト構築は今日からひとりで始められる取り組みです。会社員であっても、まずは自分の担当業務だけを対象にしたコンテキスト構築から始めることができます。
まとめ:コンテキスト構築がAI時代の競争力になる
必要な情報を整理し、その処理で使う内容を選びます。指示文は保存して再利用でき、コンテキストには履歴やツール結果も含まれます。3層は保管方法の一案として使い、保存、読込、出力を別々に確認してください。
AI活用の「何から?」を、
30分で解決。
御社の仕事を伺い、AIに任せる業務と
最初に試すことを、一緒に決めます。
- AIに任せたい仕事を整理
- 自社に合う始め方を具体化
- 明日からの一歩を決める

次は、御社の話を聞かせてください。
参考資料・出典
製品の機能・仕様や外部の発表は、以下の資料を参照しています。PLaiの運用例・実績と、公式の説明を分けてご覧ください。
- Anthropic:Effective context engineering for AI agents
コンテキストの選択・整理とエージェントの設計
確認日: - Claude Code公式ドキュメント:メモリ
CLAUDE.mdと指示・記憶の扱い
確認日: - Obsidian公式ヘルプ:データの保存方法
VaultとローカルMarkdownファイルの保存方式
確認日:







