こんにちは！代表取締役 兼 AIサービス開発室の鈴木生雄です。
突然ですが「コンテキストエンジニアリング」というキーワードを聴いたことはありませんか？私自身は、最近このキーワードをよく目にするようになったので、自分なりに調べてみたところ、AIを活用していく上でとても重要な概念だと感じました。しかし、とても重要であるにも関わらず、入門者にわかりやすいコンテンツを見つけられなかったので、自分で作ってみました（ちなみに、文：Claude、絵：Gemini です）。
これからの時代、開発者・非開発者に関わらずホワイトカラー職にとっては必須の知識だと思いますので、ぜひ読んでみてください。
AIと歩んだ5週間 ― ある新入社員の「コンテキストエンジニアリング」入門記
これは、IT企業テクノフォース社に入社したばかりの新入社員・高瀬ユウキが、AIアシスタント「ナビ」と共に成長していく5週間の記録です。
ユウキに割り当てられた最初の仕事は、社内ナレッジベース「テクノペディア」の問い合わせ対応。社員から届く質問に対して、社内の技術資料やマニュアルを調べて回答する業務です。
「AIが何でもやってくれる時代なんだから、楽勝でしょ」
入社初日、ユウキはそう思っていました。
月曜日の朝、最初の問い合わせが届きました。
「勤怠システムにログインできません。対応方法を教えてください。」
ユウキはさっそくナビに頼みました。
「ナビ、この問い合わせに回答して。」
ナビの回答はこうでした。
「勤怠システムにログインできない場合、一般的な対処法としては、パスワードのリセット、ブラウザのキャッシュクリア、またはシステム管理者への連絡が考えられます。」
一見まともに見えます。しかし、テクノフォース社の勤怠システムは3ヶ月前にリプレイスされたばかりで、旧システムのブックマークからアクセスしようとしている社員が多いという事情がありました。正しい回答は「新しいURLはこちらです」と案内することだったのです。
ユウキが的外れな回答を送ってしまった後、先輩社員の宮本さんがやってきました。
「ユウキ、新入社員に仕事を頼むとき、『これやっておいて』とだけ言って、背景も目的も制約も何も伝えない先輩がいたら、どう思う？」
「……それは困ります。何をどうすればいいかわからないです。」
「AIも同じだよ。AIにとっての『わかる・わからない』は、人間が渡す情報で決まる。この情報のことを コンテキスト と呼ぶんだ。」
宮本さんは続けました。
「勤怠システムが最近リプレイスされたこと、旧URLからのアクセスが問い合わせの主な原因であること、新URLの情報。これらを伝えないと、ナビは一般論しか返せない。逆に言えば、正しいコンテキストを渡せば、正しく動ける。」
ユウキは問い合わせ文と一緒に、勤怠システムの移行経緯と新旧URL情報をナビに渡してみました。すると、ナビはすぐに的確な回答を返してくれました。
この週の気づき：AIが的外れな回答をするのは、AIが悪いのではない。渡された情報（コンテキスト）が足りない、または間違っているからだ。
1週目の学びを活かして、ユウキは毎回丁寧にコンテキストを伝えるようにしました。しかし、1週間もすると新たな問題が出てきました。
問い合わせが届くたびに、ユウキはナビにこう伝えていました。
「テクノフォース社の問い合わせ対応ルールは、24時間以内に初回回答すること。回答は敬語で、結論から先に書くこと。参照した資料名を必ず記載すること。勤怠システムは3ヶ月前にリプレイスされていて……」
毎回これを書くのに5分かかります。1日に10件の問い合わせがあれば、それだけで50分のロスです。
「宮本さん、毎回同じ前提条件をナビに説明し直すのが大変なんですが……。」
宮本さんは笑いました。
「新入社員が入ってきたとき、毎朝『うちの会社はこういうルールで、こういう方針で……』って一から教え直す？ そんなことはしないよね。最初に業務マニュアルを渡して、いつでも参照できるようにしておくでしょう？」
「確かに。」
「AIにも同じことができる。変わらない前提情報――社内ルール、対応方針、用語集、よくある質問と回答パターンなど――を文書にまとめて、常にナビが参照できる場所に置いておくんだ。ツールによってはこの文書のことを設定ファイルと呼んだりする。開発の現場ではCLAUDE.mdやCOPILOT-INSTRUCTIONS.mdという名前で知られているよ。」
ユウキは「テクノペディア対応ガイド」という文書を作成しました。対応ルール、社内システムの一覧と変更履歴、よく使われる社内用語の意味。これを常にナビに読み込ませておくことで、毎回同じ説明をする必要がなくなりました。
さらに、新しいシステム変更があった際にはこの文書を更新するだけで、ナビの対応が自動的に最新化されることにも気づきました。
この週の気づき：毎回伝えるコンテキスト（都度の情報）と、常に参照させるコンテキスト（永続的な前提知識）は分けて設計する。後者を仕組みとして整備すれば、効率も精度も上がる。
2週目までの工夫で、ナビの回答品質はかなり上がりました。調子に乗ったユウキは、次のステップに進みたくなりました。
「ナビ、今日届いている10件の問い合わせ、全部まとめて対応しておいて。」
ナビは10件を一気に処理しようとしましたが、結果は散々でした。簡単な質問への回答は問題ありませんでしたが、複数のシステムにまたがる複雑な質問では、調査が中途半端なまま回答を生成してしまいました。ある問い合わせでは、質問の意図を取り違えて見当外れの長文を返していました。
宮本さんに相談すると、こう言われました。
「ユウキ、新入社員にいきなり『この10件の案件、全部やっておいて』って丸投げする？」
「しないです。まず内容を確認して、優先度をつけて、1件ずつ取り組んでもらいます。」
「それと同じだよ。AIに仕事を任せるときも、タスク分解が大事なんだ。大きな仕事をそのまま渡すんじゃなくて、AIが処理しやすい粒度に分ける。」
宮本さんはホワイトボードにこう書きました。
問い合わせ対応の分解例：
ステップ1：問い合わせ内容を読み、カテゴリを分類する
ステップ2：該当するナレッジベースの記事を検索する
ステップ3：記事の内容を問い合わせに当てはめて回答案を作成する
ステップ4：回答案を対応ルールに照らしてセルフチェックする
「こうやって分解してあげると、各ステップでAIが何をすべきかが明確になる。結果として全体の精度も上がるし、どこで問題が起きたかも特定しやすくなる。」
ユウキはナビへの仕事の出し方を変えました。10件を一括で渡す代わりに、1件ずつ、しかもステップごとに処理させる形に。すると、複雑な質問でも、各ステップで確実に処理が進むようになりました。
この週の気づき：AIに仕事を任せるとき、「何を渡すか」だけでなく「どの粒度で渡すか」も重要。大きなタスクは、AIが確実に処理できるサイズに分解する。
3週目までの工夫で、ナビは1件ずつの問い合わせに対して質の高い回答案を作れるようになりました。しかし、ユウキはあることに気づきました。
ナビは回答案を作ったあと、いつもこう言うのです。
「回答案を作成しました。ナレッジベースの記事ID #1042 に該当する内容がありそうですが、私はナレッジベースに直接アクセスできないので、ユウキさんが確認してください。確認後、問い合わせ者にメールで送信してください。」
つまり、ナビは「調べて」「送って」と頼まれても、実際にナレッジベースを検索したりメールを送ったりする 手足 を持っていなかったのです。ユウキは毎回、自分でナレッジベースを開いて記事を確認し、回答文をコピーしてメールソフトに貼り付けて送信していました。
「宮本さん、ナビは頭はいいんですが、自分では何も実行できなくて。結局、調査も送信も僕が手作業でやっています。」
「それは ツール連携 の話だね。AIが自律的に動くためには、外部のシステムやサービスと接続する『手足』を与えてやる必要がある。ナレッジベースの検索APIに接続すれば自分で記事を探せるし、メール送信のAPIに接続すれば自分で送ることもできる。」
「じゃあ、全部のシステムに繋いじゃえばいいですか？」
宮本さんの表情が少し厳しくなりました。
「ここが重要なところだ。新入社員にいきなり全システムの管理者権限を渡すか？」
「それは絶対にやりません。事故のもとです。」
「AIも同じ。認証認可、つまり『何にアクセスしてよいか』『何をしてよいか』の範囲を明確に設計しなきゃいけない。たとえば、ナレッジベースの検索は許可するが、記事の編集は許可しない。メールの下書き作成は許可するが、送信は許可しない、とかね。」
宮本さんはさらにこう付け加えました。
「最近は MCP（Model Context Protocol） のような標準化された接続の仕組みも出てきている。AIと外部ツールを安全につなぐための共通の『規格』のようなものだ。個別にバラバラに接続するより、標準化された方法を使った方が管理しやすいし、安全性も高い。家電製品のコンセントの規格が統一されているのと同じ発想だよ。」
ユウキはナビにナレッジベースの検索権限（読み取りのみ）と、メールの下書き作成権限（送信は不可）を設定しました。ナビは自分でナレッジベースの記事を検索し、内容を確認した上で回答案を作成し、メールの下書きまで自動で準備してくれるようになりました。
この週の気づき：AIが自律的に動くためには、外部ツールとの連携（手足）と、その利用範囲の設計（認証認可）がセットで必要。便利にするために全権限を与えるのではなく、必要最小限の権限を設計する。
4週目までに、ナビはかなり自律的に動けるようになりました。問い合わせを受け取り、ナレッジベースを検索し、回答案を作成し、メールの下書きまで準備してくれます。ユウキの仕事は下書きを確認して送信ボタンを押すだけ。
「だいぶ楽になったな」と思っていた金曜日、事件が起きました。
ある社員から「経費精算システムの承認フローを教えてほしい」という問い合わせがありました。ナビはナレッジベースから該当記事を見つけ、回答案を作成しました。しかし、その記事は半年前のもので、2ヶ月前に承認フローが変更されていました。ナビは古い情報に基づいた回答を作ってしまい、ユウキもそれに気づかずそのまま送信してしまったのです。
問い合わせ者が古い手順で申請してしまい、経理部から「なぜ旧フローで申請が来るのか」と問い合わせが入って、ようやく間違いが発覚しました。
落ち込むユウキに、宮本さんはこう言いました。
「ユウキ、これは君だけのミスじゃない。仕組みの問題だ。」
「仕組み？」
「自動車の自動運転を考えてみて。技術が進んでも、完全に人間が何もしなくていいレベルにはまだ達していない。だからこそ、『ここは自動に任せる』『ここは人間が必ず確認する』という線引きが設計されている。AIとの協働も同じだよ。」
宮本さんはホワイトボードに3つの仕組みを書きました。
① ワークフロー設計 ― 仕事の流れを定義する
「問い合わせを受けてから回答を送るまでの一連の流れの中で、どのステップをAIに任せ、どのステップで人間が介入するかを明示的に設計する。」
② HITL（Human-in-the-Loop） ― 人間の確認ポイントを組み込む
「『ループの中に人間を入れる』という意味だ。今回の例でいえば、ナビが回答案を作った後、情報の鮮度を人間が確認してから送信する、というチェックポイントを設けるべきだった。全部を人間が確認する必要はない。リスクが高いもの、たとえば社内ルールや手続きに関する回答は人間が確認する。よくある定型的な質問は自動送信を許可する。こういう濃淡をつけるんだ。」
③ 評価・観測 ― AIの動きを監視し、品質を測る
「AIが何を検索して、どの記事を根拠にして、どういう回答を生成したかを記録して追跡できるようにする。そうすれば、問題が起きたときに『どこで間違えたか』がすぐにわかるし、同じ間違いを防ぐ改善もできる。」
ユウキは、この3つの仕組みを取り入れて問い合わせ対応の流れを再設計しました。
- 定型的な質問（パスワードリセットなど）→ ナビが自動回答、ログだけ記録
- 手続き・ルールに関する質問 → ナビが回答案を作成、ユウキが内容と情報鮮度を確認してから送信
- 複数部署にまたがる複雑な質問 → ナビが調査結果をまとめ、ユウキが判断して回答を作成
また、ナビの全ての対応ログ（検索したキーワード、参照した記事、生成した回答文）を記録し、週次で回答の正確性をレビューする仕組みも導入しました。
この週の気づき：AIに任せることと、人間が確認することの線引きを設計する。そしてAIの動きを観測できる仕組みを作ることで、問題の早期発見と継続的な改善が可能になる。
金曜日の夕方、宮本さんがユウキのデスクにやってきました。
「ユウキ、この5週間で君がやってきたことを振り返ってみようか。」
宮本さんはホワイトボードにこう整理しました。
1週目：適切なコンテキストを渡す（情報の質と量）
2週目：永続的な前提知識を仕組み化する（記憶の設計）
3週目：仕事をAIが処理しやすい粒度に分解する（タスク分解）
4週目：AIの手足を整え、権限を設計する（ツール連携と認証認可）
5週目：人間の確認ポイントを設け、AIの動きを観測する（ワークフロー・HITL・評価）
「実はこれらを体系的にまとめた考え方に名前がある。コンテキストエンジニアリング というんだ。」
「コンテキスト……エンジニアリング？」
「エンジニアリングというのは、『工学』、つまり物事を体系的に設計し、構築する技術のことだ。プロンプト（AIへの指示文）をうまく書くテクニックは『プロンプトエンジニアリング』と呼ばれてきたけど、AIに長期的に自律して仕事をしてもらうためには、プロンプトの書き方だけでは足りない。AIが仕事をするために必要な 情報・知識・道具・仕事の流れ・権限・チェック体制 ——これらすべてを設計する。これが『コンテキストエンジニアリング』だ。」
ユウキは5週間を思い返しました。最初は「AIに頼めば何でもやってくれる」と思っていた。でも実際には、AIが力を発揮するかどうかは、AIそのものの性能よりも、AIの周りに自分が何を整えるかで決まることを実感しました。
「考えてみれば、これって人間の新入社員を育てるのとよく似ていますね。」
「そうだね。AIの性能はこれからも上がり続ける。でも、どんなに優秀な新入社員でも、業務の背景を知らなければ的外れな仕事をするし、道具がなければ手が動かないし、チェック体制がなければミスが見逃される。コンテキストエンジニアリングは、AIを活かすための 環境と仕組みの設計技術 なんだ。」
宮本さんは最後にこう付け加えました。
「そしてこれは、君たちエンジニアが最も得意とする領域のはずだよ。システムの要件を整理し、設計し、品質を担保する。そのスキルが、AIとの協働にもそのまま活きる。」
ユウキはナビの画面を見つめながら思いました。
まだまだ学ぶことはたくさんある。でも、この5週間で手に入れた「コンテキストエンジニアリング」という地図があれば、これからの道のりも迷わずに進んでいけそうだ、と。
まとめ：コンテキストエンジニアリングの5つの柱
| 週 | テーマ | ひとことで言うと |
|---|---|---|
| 1 | コンテキストの質 | AIに過不足のない情報を渡す |
| 2 | 記憶・永続的な指示 | 変わらない前提知識を仕組みとして整備する |
| 3 | タスク分解 | 仕事をAIが処理しやすい粒度に切り分ける |
| 4 | ツール連携と認証認可 | AIの手足を整え、権限の範囲を設計する |
| 5 | ワークフロー・HITL・評価 | 人間の確認ポイントを設計し、AIの動きを観測する |
AIは魔法の杖ではなく、優秀だけれど入社初日の新入社員です。
その力を引き出すのは、あなたが整える「コンテキスト」です。