ChatGPTや社内のAIアシスタントに文章を書かせてみたものの、「うーん、正しいんだけど、このままはちょっと使えないな……」 そんなアウトプットを、何度も何度も手直ししていないでしょうか。
特に会社で使うとなると、事業の前提や自社ならではの言葉遣い、判断基準 がAIにうまく伝わらず、「惜しいアウトプット」が大量生産されがちです。
この記事では、AIのモデル性能そのものよりも、「現場のコンテクストをどう設計してAIに渡すか」＝『コンテクストエンジニアリング』 という考え方に焦点を当てます。
なぜAIを入れても仕事が変わらないのか どんなコンテクストを設計すると、アウトプットが“そのまま使えるレベル”に近づくのか 実際の現場でどう実装していけばいいのか を、具体例を交えながら掘り下げていきます。
自社のAIプロジェクトに「なんとなく手応えがない」と感じている方は、ぜひ最後まで読んでみてください。
ここ1〜2年で、社内のAI利用は一気に進みました。
会議の議事録はAIが自動でまとめてくれる
提案資料のたたき台やメール文面も、まずAIに書かせてから直す
社内wikiの検索も、生成AIで「いい感じの要約」が返ってくる
「これなしの生活には戻れないよね」と感じている人も、もう少なくないと思います。 それでも、ふと冷静に見てみると──
働き方が劇的に変わった実感はまだ薄い
売上や利益の数字に、はっきり効いているかと言われるとちょっと困る
「AI活用事例」は増えたけれど、「事業の勝ち方」が変わったとは言い切れない
そんな“天井感”を共有している会社が大半ではないでしょうか。 このギャップって、つい
「やっぱりまだAIは精度がイマイチだからな」 「もっといいモデルが出てこないと、本番では使えないよね」
とモデル側の問題にしたくなります。 でも、少し丁寧に見ていくと、かなりの部分は
AIに渡している“前提（コンテクスト）”が浅すぎる
ところから来ています。
ここではまず、日常の小さな違和感から出発して、 「会社でAIを本気で使う」ときに何が起きているのか、 そしてそれを変えるための考え方としてのコンテクストエンジニアリングを、ざっくり整理してみます。
1. 「謝罪メール書いて」でモヤっとする理由
ごく小さな例から。 AIにこう頼んだことはないでしょうか。
「上司に送る謝罪メールの文章を考えて」
返ってくるのはたいてい、
文法は完璧
言葉遣いも丁寧
一般的には“正しい”謝罪文
です。でも読んでみると、どこかモヤっとする。
「この上司にここまで畏まりすぎると、逆に距離出るな…」
「うちの会社のノリだと、ちょっと硬すぎる」
「自分のミスのニュアンスが、まるっと消えてる」
冷静に考えると、AIにはこんなコンテクストを1ミリも伝えていません。
何をやらかしたのか（軽傷なのか、重傷なのか）
相手との日頃の関係性
会社の文化（固めか、フラットか）
コンテクストがゼロなので、 “世界一般ではそこそこ正しいが、自分の状況にはハマらない文章”が出てくる──それだけです。 ここまでは「まあそうだよね」で済みます。 でも、会社でAIを本気で使おうとした瞬間、この問題は一気にスケールします。
2. 会社でAIを使うときに必要な「コンテクスト」は桁違い
例えば、次のような使い方をイメージしてみます。
営業提案のたたき台をAIに出してもらう
顧客クレームの傾向を分析して、打ち手候補を出させる
事業別パフォーマンスを要約し、経営会議用の資料にする
ここで必要になるコンテクストは、謝罪メールどころではありません。 ざっくり言うと、会社のまわりには二つの“情報の山”があります。
① 顧客の声の山
コールセンターの通話ログ
営業商談の録音・議事録
問い合わせメール／チャット
アンケートの自由記述
SNSでの口コミ
② 企業コンテクストの山
経営理念や中期経営計画
プロダクト・事業ごとの戦略やKPI
過去施策の成功／失敗の記録
会議の議事録、Slack / Teams の会話ログ
ベテランしか知らない“昔の大事故・暗黙ルール”
どちらの山も、
量は膨大
データの偏りも強く
文脈次第で意味が変わる
という厄介な性質を持っています。 この状態で、
「とりあえず全部ベクトルDBに突っ込んでRAGすればOK」
とやると、高い確率で「めちゃくちゃよくまとまっているけれど、経営の意思決定には乗せづらいレポート」が出来上がります。
実際、海外の調査でも 「AIに大きな財務的メリットを出せている企業は全体の1割程度」、 「AI活用が“成熟している”と言える企業はごくわずか」と報告されています。 どの業務にAIを入れるか（ユースケース選定）や、どのモデルを採用するか（ベンダー選定）は議論してきたけれど、
「AIに何を前提として渡すのか」という設計がほとんどされていない
まま走っている── これが、「AIは便利だけど、事業の勝ち方はまだ変わっていない」状態の正体のひとつです。
3. AIは「超優秀だけど事情を知らない新卒」
ここで一度、AIを頭の回転が異常に速い新卒社員だと考えてみます。
この新卒は：
どんな資料でも一瞬で読み込めて
過去の事例も大量に横断して比較できて
初めてのテーマでも、それっぽい提案を書ける
一方で：
自社の歴史
過去の大失敗
社内政治・暗黙のタブー
特定顧客との微妙な関係性
は知りません。 この状態で、
「うちの強みをアピールする提案書つくって」 「このクレームを分析して次の打ち手出して」
とだけ頼めば、
世界一般では筋は通っている
しかし「うちの事情」を踏まえていない
アウトプットが返ってきます。 AIに起きていることも、まったく同じです。
問題は「頭の良さ」ではなく、どんなコンテクストを前提に考えさせるかが設計されていない
という一点にあります。
実際の例。確かに、「受注した商談はお客さんの課題が明確だけど、失注した商談はお客さんの課題が曖昧だった」というアウトプットをAIに返されても、そりゃそうだけどさ、となりますよね。
4. コンテクストエンジニアリングとは何か？
そこで出てくるのが コンテクストエンジニアリング という考え方です。 一行で言うと、こうなります。
AIに渡す「前提情報」と、その「優先順位・扱い方・順番」を設計すること
典型的には、次の3つの問いに答える仕事になります。
① 何をテーブルに乗せるか？
最新の顧客発言だけを見るのか
過去の契約・クレーム履歴も必ず含めるのか
自社の戦略やKPIも一緒に渡すのか
👉 「この意思決定のとき、本来テーブルに乗っているべき情報は何か？」
② どんな重みで扱うか？
解約直前のクレームは重めにカウントするか
SNSの声は“参考情報”程度にとどめるか
5年前の成功事例より、直近1年の失敗事例を優先するか
👉 「全部平等に扱うのではなく、どれをどれだけ信じるか？」
③ どの順番で渡すか？
まず顧客の声を見てから社内制約を見るのか
先に戦略とKPIを渡してから顧客の声を読むのか
似た過去案件を最初に見せ、そのあと詳細ログを読むのか
👉 「AIと人間が、どんな順番でコンテクストを共有するか？」 “魔法のプロンプト”を探すのではなく、どんなコンテクストでAIを動かすかを決めること。 その設計仕事に名前をつけたものが、コンテクストエンジニアリングです。
5. コンテクストを渡すのは「一人の職人」ではなく「横断チーム」
ここまで聞くと、
「なるほど。じゃあコンテクストをうまく書ける“プロンプト職人”を育てればいいのか」
と思うかもしれませんが、実態は逆です。 一人の巧みなプロンプト職人に頼る運用は、絶対に続きません。 必要なのは、
ビジネス側（現場・経営）
データ／AI側
システム・運用側
が一緒になって、
「どんなコンテクストを、どんなパイプでAIに渡すか」
を設計する横断チームです。 海外のレポートでも、AIをスケールさせている企業は
ドメインの専門家
プロセス設計者
データサイエンティスト／MLOps
ITアーキテクト
といったメンバーで構成された、
*クロスファンクショナルな“変革スクワッド”**を組成していると繰り返し指摘されています。
ざっくり言えば、
従来の「経営企画」が“戦略と数字のOS”を設計してきたとしたら、これからは「AI企画・設計チーム」が“コンテクストのOS”を設計するフェーズに入っている
ということです。
どのプロセスから着手するのか
そこで使うべき顧客の声・社内データは何か
どの粒度・どのフォーマットでAIに渡すのか
人間はどこで判断し、AIはどこまで自動化するのか
こうしたことを、「なんとなく現場任せ」ではなく、 チームとして責任を持って決めていく必要があります。
まとめ：「AIが使えない」のではなく、「前提が雑すぎる」
仕事でAIを使う場面が増えるほど、こんな瞬間が出てきていると思います。
たたき台としてはすごく助かる
でも「このままお客様に出すのは、まだちょっと怖い」
結局、最後のところは自分の頭で考え直している
AIのアウトプットを見ながら、
「便利なんだけど、“任せきり”にはできないんだよな」
という感覚を持ったとき、 本当に足りないのはモデルの性能でしょうか。 それとも、
こちらが渡しているコンテクストが、そもそも浅すぎるだけ
でしょうか。
どの領域で使うか（ユースケース）
どのモデルを選ぶか（ベンダー）
に加えて、
どんなコンテクストを
どの重みで
どの順番で渡すのか
を設計できるかどうかが、 「AIをなんとなく使っている会社」と「AIでちゃんと勝っている会社」を分けていきます。 次にAIの出力を見て、
「便利だけど、このままではまだ出せないな」
と感じたときは、一度こう問い直してみてください。
「これはモデルの限界なのか？それとも、こちらが渡している前提がショボいだけなのか？」
その問いから先を、コンテクストエンジニアリングという名前で意識し始めること。それ自体が、これから数年でAI活用の差をじわじわ広げていくスタートラインになるはずです。
最後に
ここまで読んでくださりありがとうございます。 本記事は、前回の「AIが『情報前処理係』を消したあと、残るのは一次情報OS」の続編的な位置付けです。 前回は、AIがホワイトカラーの「中継・翻訳・報告」を外部化したあと、企業に残る勝ち筋は「一次情報を経営意思決定のOSにすること」だ、という話をしました。 コンテクストエンジニアリングはOSにするためのHowの重要な概念です。
私が代表をしている ブリングアウト では、まさに本文で書いたような、
一次情報経営を可能にする、企業の変革論点の特定
それを支えるカスタムAIエージェントの設計、販売
経営会議〜現場オペレーションまでの実装・伴走
をセットで支援しています。 興味を持っていただいた方は、以下もぜひ覗いてみてください。
【関連リンク】
【CEO Comment】
AIエージェントはこれからも進化しますが、モデル任せでは9割の会社の働き方は変わりません。 成否を分けるのは、現場に眠る一次情報をどう集め、どの判断軸で構造化し、AIエージェントにどう順番・重み付けして渡すか――つまり“コンテクストのOS”です。 今はモデルがコモディティ化し、差別化が実装力に移る転換点。プロンプトの小手先ではなく、何をテーブルに乗せるかを経営と現場が合意し、データ/AI、システム・運用が同じ責任で回す横断チームが必要になります。 ブリングアウトは対話データを起点に、経営会議から現場まで一気通貫でコンテクスト基盤とエージェントを設計し、AXを“実働”に変えます。『便利だけど出せない』を『そのまま意思決定に乗る』へ。 一次情報経営の実装を一緒に進めましょう。
著者・ブリングアウトについて
ブリングアウト株式会社 代表取締役 中野慧
『東洋経済 すごいベンチャー100』 『日経 未来の市場を創る100社』 『日経テクノロジー展望 未来をつくる100の技術』 などに選出され、国内大手企業を中心に導入が進んでいます。 ◾️ ホームページ： https://www.bringout.biz/
