コンテキストエンジニアリング入門：AIに業務知識を「正しく渡す」技術

AIの答えの質は、モデルの性能だけでは決まりません。同じモデルでも「どんな文脈を、どれだけ正確に渡すか」で、結果は大きく変わります。この、AIに渡す情報を設計する営みを、コンテキストエンジニアリングと呼びます。

そして業務でAIを使うとき、最良のコンテキスト源は、多くの場合社内の業務マニュアルです。自社の「正しいやり方」は、汎用的な生成AIモデルの学習データには入っていません。経費精算のルールも、解約兆候の見極め方も、自社の手順書にしか書かれていないからです。AIに自社の業務を語らせたいなら、まずその知識を構造化された形で渡す必要があります。

なぜ「口頭の指示」では足りないのか

AIに業務を任せようとして、つい曖昧な指示を投げてしまうことは多いと思います。「いい感じにレポートまとめて」では、AIは何を見て何を集計すべきか分かりません。これは人間の新人に「いい感じにやっといて」と頼むのと同じで、結果がばらつくのは当然です。

伝え方の差を整理すると、次のようになります。

右の列が、そのままコンテキストエンジニアリングの目標でもあります。AIに正しく渡せる情報は、人間が読んでも正しく再現できる情報と一致します。ですから「AIのために特別な準備をする」のではなく、良いマニュアルを作ること自体が、最良のコンテキスト整備になると私たちは考えています。人間向けの整備とAI向けの整備を、二重にやる必要はありません。一度きちんと手順を構造化すれば、その成果物が両方に効きます。

ここで多くのチームが取り違えるのは、コンテキストエンジニアリングを「プロンプトの言い回しを磨く作業」だと思い込んでしまうことです。実際の効き目は逆で、渡す中身が9割、言い回しが1割に近いと感じています。中身が薄いままプロンプトをいくら整えても、AIは存在しない情報を補えず、もっともらしい誤った情報（ハルシネーション）を返してしまうこともあります。先に整えるべきは、AIへの頼み方ではなく、AIに渡す業務知識そのものです。

マニュアルがコンテキストとして優れている3つの理由

1. 手順が構造化されている

良いマニュアルは、業務を「ステップの並び」に分解しています。AIにとって、これは理想的です。何を最初にやり、次に何を判断するかが順序立っているので、AIはその流れに沿って答えを組み立てられます。だらだらした議事録や雑多なチャットログより、はるかに扱いやすくなります。

2. 判断基準が言語化されている

ベテランの「勘」は、本人の頭の中にあるうちはAIに渡せません。マニュアル化の過程で「なぜこの数字を選ぶか」「どの条件なら例外扱いか」を言葉にしておくと、その判断基準ごとAIに引き継げます。暗黙知を形式知に変える作業が、そのままコンテキスト整備になります。

3. 画面情報が紐づいている

操作系の業務は、言葉だけでは伝わりにくいものです。「設定画面の右上のボタン」をテキストで延々と説明するより、スクリーンショット付きの手順のほうが正確です。画面と手順が結びついたマニュアルは、操作に関する問い合わせに対して、具体的にどこを触るかまで含めて案内できる土台になります。テキストだけの手順書では「その画面、今は表示が違う」という食い違いが起きがちですが、画面と手順が一体なら、どの状態のことを指しているかが一目で揃います。

この3点はどれも、後付けで揃えようとすると骨が折れます。だからこそ、業務をやっている画面をそのまま録画し、手順・判断・画面を一度に拾ってしまうやり方が理にかなっています。記録のために業務を止めるのではなく、業務をしている様子そのものが記録になる、という発想です。

たとえば、マニュアル根拠のチャット

Flowbaseは、業務をやっている画面を録画するだけで、AIが手順・スクリーンショット・説明文を組み立て、業務マニュアルを自動生成します。そして、そのマニュアルを文脈として、チャットでAIに質問できます。マニュアルを検索して答えの根拠にする、RAG（検索拡張生成）と同じ仕組みです。

たとえば経費精算のマニュアルを作っておけば、新人が「交通費の立替ってどう申請するんでしたっけ？」と聞いたとき、AIはそのマニュアルの記述に基づいて手順を答えます。汎用的な一般論ではなく、自社の手順書に書かれた通りのやり方が返ります。これがコンテキストエンジニアリングの実践です。正しい文脈（つまりマニュアル）を渡してあるから、正しい答えが返る、という関係です。

逆に言えば、マニュアルが曖昧なら答えも曖昧になります。AIの回答品質は、渡したマニュアルの品質を超えません。良い答えが欲しければ、まず良いマニュアルを用意する。順序はいつもこちらです。

この順序を体感する一番早い方法は、答えが外れたときの直し方を変えてみることです。AIの答えが的外れだったとき、つい「聞き方が悪かったか」とプロンプトを書き直したくなります。ですが多くの場合、本当の原因は、参照しているマニュアルに該当の手順や判断基準が書かれていないことにあります。プロンプトをいじるループに入る前に、まず元のマニュアルを見て「そもそもそこに答えが書いてあるか」を確かめます。書いていなければ、マニュアルに一行足すほうが、何十通りも言い回しを試すより確実に効きます。

たとえば、同じ質問でも文脈の差で答えが変わる

文脈の有無で答えがどう変わるか、請求書処理を例に並べてみます。新人が「この請求書、どのフォルダに保管すればいい？」と尋ねたとします。

文脈がない状態では、AIは一般論しか返せません。「取引先名や日付でフォルダを分けるのが一般的です」という回答は、間違いではありませんが、自社で実際にどう分けているかは答えられません。新人は結局、先輩に聞き直すことになります。

一方、請求書処理のマニュアルを文脈として渡してあれば、答えは具体になります。「受領した月のフォルダに入れ、ファイル名は『取引先名_年月日』で統一します。スキャンの場合はPDF化してから保管します」というように、マニュアルに書かれた自社のルールがそのまま返ります。違いは、モデルの賢さではなく、渡した文脈の差だけです。

この差は、業務が複雑なほど大きく開きます。判断の分岐が多い業務ほど、一般論では当てられず、自社の文脈が効いてきます。コンテキストエンジニアリングが「投資する価値のある作業」になるのは、まさにそうした属人的で判断の多い業務においてです。

AIの回答品質は、渡したマニュアルの品質を超えません。良い答えが欲しければ、まず良いマニュアルを用意する。プロンプトを磨くのは、その後です。

やること、やらないこと

実務で押さえる勘所を、やること・やらないことで整理します。

よくある質問