生成AIを使ううえで、最初に広く語られたのは「プロンプトエンジニアリング」でした。ChatGPT にどのような指示を出せば、より意図に近い回答が得られるのか。どのような役割を与え、どのような条件を指定し、どのような形式で出力させるのか。生成AIの初期活用では、この「AIへの頼み方」が非常に重要視されていました。
しかし、生成AIの利用が進むにつれて、プロンプトだけでは限界があることも見えてきました。どれだけ丁寧な指示を出しても、AIが必要な情報を知らなければ、正しい回答はできません。社内規程を知らないAIに社内手続きを答えさせることはできませんし、顧客ごとの過去の対応履歴を知らないAIに、適切な返信文を作らせることもできません。
そこで重要になってきたのが「コンテキストエンジニアリング」です。これは、AIに何を知った状態で考えさせるか、どの情報をどの粒度で渡すか、どの文脈を保持し、どの情報を除外するかを設計する考え方です。
さらに最近では、AIに情報を与えて答えさせるだけではなく、AIを業務の中で実際に動かすための環境設計が重要になっています。ファイル、フォルダ構成、API、MCP、外部ツール、データベース、ログ、権限管理、人間による確認フローなどを含め、AIが実際に仕事をするための「実行基盤」を設計する領域です。これをここでは「ハーネスエンジニアリング」と呼びます。
この記事では、プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリングの違いを整理し、そのうえで、生成AI時代のIT人材に求められるスキルについて考えます。
1. プロンプトエンジニアリングとは何か
プロンプトエンジニアリングとは、AIに対する指示文を設計することです。もっと簡単に言えば、AIへの「頼み方」を整える作業です。
たとえば、単に「ブログを書いてください」と入力するよりも、「初心者向けに、落ち着いた文体で、見出しを付けながら、3,000字程度の記事を書いてください」と入力した方が、出力は安定します。
プロンプトエンジニアリングで扱う要素には、次のようなものがあります。
・AIに役割を与える
・出力形式を指定する
・文体を指定する
・対象読者を指定する
・文字数や構成を指定する
・禁止事項を指定する
・例を示す
・手順を指定する
・判断基準を明示する
たとえば、ビジネスメールを作成する場合でも、「丁寧なメールを書いてください」だけでは不十分です。相手との関係、伝えるべき内容、避けたい表現、こちらの立場、求める着地点などを指定した方が、実務で使いやすい文章になります。
この意味で、プロンプトエンジニアリングは今でも重要です。生成AIの出力は、入力の仕方によって大きく変わります。曖昧な指示には曖昧な回答が返ってきますし、条件を整理した指示には、比較的安定した回答が返ってきます。
ただし、プロンプトエンジニアリングには限界があります。プロンプトはあくまで「命令」や「依頼」の設計であって、AIが参照する情報そのものを十分に保証するものではないからです。
AIに「正確に答えてください」と指示しても、必要な情報がなければ正確には答えられません。AIに「社内規程に基づいて回答してください」と指示しても、その社内規程が与えられていなければ、一般論や推測に頼るしかありません。
つまり、プロンプトエンジニアリングは必要条件ではありますが、十分条件ではありません。
2. コンテキストエンジニアリングとは何か
コンテキストエンジニアリングとは、AIに与える文脈や背景情報を設計することです。プロンプトが「どう頼むか」だとすれば、コンテキストは「何を知った状態で考えさせるか」です。
ここでいうコンテキストには、さまざまな情報が含まれます。
・会話履歴
・ユーザーの目的
・過去の作業内容
・社内資料
・商品情報
・顧客情報
・業務ルール
・最新の価格表
・エラー履歴
・参照すべきドキュメント
・使ってはいけない古い情報
たとえば、AIに顧客対応メールを書かせる場合を考えます。
プロンプトとしては、「お客様への返信メールを書いてください」と依頼できます。しかし、それだけでは一般的な返信文しか出てきません。実務で使える文章にするには、顧客が何を問い合わせているのか、こちらは何を回答できるのか、過去にどのようなやり取りがあったのか、社内ルール上どこまで対応可能なのか、といった情報が必要です。
この情報を適切に渡すことで、AIの回答は実務に近づきます。
ただし、コンテキストエンジニアリングは、単に大量の資料をAIに与えることではありません。ここが重要です。
AIに資料を大量に渡せば精度が上がる、というわけではありません。むしろ、関係のない情報が多すぎると、AIは余計な情報を拾いやすくなります。古い資料、新しい資料、例外規定、重複した説明が混ざっていると、AIの回答が不安定になることもあります。
したがって、コンテキストエンジニアリングでは、次のような判断が必要になります。
・今回のタスクに必要な情報は何か
・不要な情報は何か
・原文で渡すべき情報は何か
・要約して渡してよい情報は何か
・最新情報をどう優先するか
・矛盾する情報がある場合にどう扱うか
・会話履歴をどこまで保持するか
・古い履歴をどう圧縮するか
・検索結果のどの部分をAIに渡すか
たとえば、社内FAQのような仕組みであれば、質問内容に応じて関連する資料だけを検索し、その中でも根拠として必要な部分だけをAIに渡す必要があります。これは一般にRAGと呼ばれる仕組みと関係しますが、RAGそのものを作ることだけがコンテキストエンジニアリングではありません。
RAGは、コンテキストを動的に取得するための代表的な技術の一つです。しかし、コンテキストエンジニアリングはもっと広い概念です。検索、要約、履歴管理、優先順位付け、情報の除外、メタデータ設計、プロンプトへの埋め込み方まで含みます。
つまり、コンテキストエンジニアリングとは、AIにナレッジを与えることではありますが、より正確には、AIが必要なナレッジを、必要なタイミングで、必要な形で使えるようにする設計です。
3. ハーネスエンジニアリングとは何か
ハーネスエンジニアリングとは、AIが実際に働くための実行環境や接続基盤を設計することです。
プロンプトが「指示」、コンテキストが「材料」だとすれば、ハーネスは「作業環境」です。AIを単なるチャット相手として使うのではなく、業務システムやファイル、API、外部ツールとつないで、実際に作業できる状態にするための設計です。
たとえば、AIに請求書処理をさせる場合を考えます。
このとき、プロンプトとしては「請求書を処理してください」と言えます。コンテキストとしては、請求書の内容、取引先マスタ、会計ルール、過去の処理履歴などを渡すことができます。
しかし、それだけでは業務システムとしては不十分です。
請求書PDFはどこのフォルダに保存されるのか。AIはそのフォルダをどう監視するのか。PDFをどう読み取るのか。読み取った結果をどの形式で保存するのか。会計ソフトにAPIで登録するのか。登録前に人間の承認を挟むのか。エラーが起きた場合はどう通知するのか。処理ログはどこに残すのか。
こうした実行環境全体の設計が必要になります。
ハーネスエンジニアリングには、たとえば次のような要素が含まれます。
・フォルダ構成の設計
・ファイル命名規則
・API連携
・MCPサーバーの設計
・データベース設計
・ツール呼び出しの設計
・ワークフロー設計
・ログ設計
・エラーハンドリング
・リトライ処理
・権限管理
・認証情報の管理
・人間の確認ポイント
・テスト環境と本番環境の分離
・運用監視
この意味で、「ハーネスエンジニアリングは、コンピュータ上のフォルダ構成、MCP、APIなどの設計を含めたエンジニアリングである」という理解は、かなり妥当だと思います。
ただし、より広く言えば、ハーネスエンジニアリングは「AIを実務の中で安全かつ継続的に動かすための基盤設計」です。
AIが単発で文章を書く段階では、ハーネスはあまり意識されません。しかし、AIにファイルを読ませる、コードを書かせる、ツールを実行させる、外部システムを操作させる、業務フローの一部を担わせる、という段階になると、ハーネスの重要性が急に高まります。
AIにどこまで権限を与えるのか。どの操作は自動実行してよいのか。どの操作は人間の承認を必須にするのか。失敗したときにどの状態へ戻すのか。こうした設計がなければ、AIを安全に業務へ組み込むことはできません。
4. 3つの違いを整理する
ここまでを整理すると、3つの違いは次のようになります。
プロンプトエンジニアリングは、AIへの指示を設計することです。主に自然言語による依頼、制約、出力形式、役割設定を扱います。
コンテキストエンジニアリングは、AIに与える情報や文脈を設計することです。AIが回答や判断をするために必要な情報を選び、整え、渡す領域です。
ハーネスエンジニアリングは、AIが実際に動作する環境や仕組みを設計することです。外部ツール、ファイル、API、MCP、ワークフロー、ログ、権限などを扱います。
かなり単純化すれば、次のように言えます。
プロンプトは、AIへの「指示」です。
コンテキストは、AIに渡す「情報」です。
ハーネスは、AIが動く「仕組み」です。
料理にたとえるなら、プロンプトはレシピ、コンテキストは食材、ハーネスはキッチンや調理器具です。
レシピだけ良くても、食材が悪ければ良い料理はできません。食材が良くても、調理器具や作業場が整っていなければ、安定して料理を提供することはできません。
生成AIも同じです。良い指示、良い情報、良い実行環境がそろって初めて、実務で使える仕組みになります。
5. 生成AI活用の中心は移動している
生成AIが登場した当初は、プロンプトの重要性が強く語られていました。どのように質問すればよいか、どのように命令すればよいか、どのようなプロンプトを使えば高品質な出力が得られるかが注目されました。
その後、モデルの性能が向上すると、単なるプロンプトの工夫だけでは差がつきにくくなりました。むしろ、何をAIに見せるか、どの情報を参照させるかが、出力の質を大きく左右するようになりました。ここでコンテキストエンジニアリングが重要になります。
そして最近では、さらにその先に進みつつあります。AIに答えさせるだけでなく、AIに作業させる段階です。ファイルを読み、情報を抽出し、外部ツールを呼び出し、データベースを更新し、人間に確認を求め、処理結果をログに残す。こうした実行基盤の設計が必要になります。ここでハーネスエンジニアリングが重要になります。
この流れは、生成AI活用の成熟段階として見ることができます。
最初は、AIにうまく聞く段階。
次に、AIに必要な情報を渡す段階。
そして、AIを実際の業務システムに組み込む段階。
この順番で、関心の中心が移っているように見えます。
もちろん、プロンプトが不要になったわけではありません。コンテキストが重要になっても、プロンプトの設計は必要です。ハーネスが重要になっても、コンテキストの設計は必要です。
むしろ、上位の段階へ進むほど、3つは重なり合っていきます。実務的なAIシステムでは、プロンプト、コンテキスト、ハーネスを別々に考えつつ、全体として設計する必要があります。
6. これからのITエンジニアに求められるスキル
この流れを踏まえると、これからのITエンジニアに求められるスキルは、単にコードを書く能力だけではなくなっていくはずです。当然。
もちろん、コードを書けることは依然として重要です。AIがコードを書けるようになっても、そのコードが正しいか、安全か、保守しやすいかを判断するには、技術的な理解が必要です。API、データベース、認証、ネットワーク、セキュリティ、エラーハンドリングといった基礎を理解していなければ、AIが生成したコードを適切に評価することはできません。
ただし、価値の中心は少し移動します。
従来は、「自分で実装できること」がエンジニアの重要な価値でした。これからは、「何をAIに任せるか」「どの情報を与えるか」「どのような仕組みとして組み立てるか」「どこに人間の確認を入れるか」を設計できることが重要になります。
求められる能力を挙げると、次のようになります。
第一に、問題を構造化する力です。現場の課題は、最初からきれいな要件として存在しているわけではありません。「なんとなく面倒」「ミスが多い」「確認に時間がかかる」といった曖昧な状態から、どの作業を分解し、どこにAIを入れるかを考える必要があります。
第二に、情報設計の力です。AIに何を見せるか、どの情報を検索対象にするか、どの情報を優先するか、古い情報をどう扱うかを設計する力です。これはコンテキストエンジニアリングそのものです。
第三に、システム設計の力です。AIを外部ツールや既存システムとどう接続するか、どのタイミングでAPIを呼ぶか、ファイルをどう管理するか、ログをどう残すかを設計する力です。これはハーネスエンジニアリングに関わります。
第四に、品質を検証する力です。AIの出力は、もっともらしく見えても間違うことがあります。したがって、AIの回答を鵜呑みにせず、検証し、必要に応じて人間の確認を挟む設計が必要です。
第五に、現場運用を考える力です。技術的には可能でも、現場で使われなければ意味がありません。誰が使うのか、どこで確認するのか、失敗したときにどう戻すのか、既存業務とどう接続するのかを考える必要があります。
このように見ると、これからのITエンジニアは、単なる「実装者」ではなく、「設計者」や「建築家」に近づいていくように思います。
7. コードを書く人から、仕組みを設計する人へ
生成AIによって、コードを書く作業の一部は確実にAIへ移っていきます。すでに、小さなスクリプト、Webアプリの雛形、SQL、VBA、Pythonの処理などは、AIにかなり任せられるようになっています。
しかし、それはエンジニアの価値がなくなるという意味ではありません。むしろ、エンジニアの役割が上位レイヤーへ移動していると考えた方が自然です。
AIにコードを書かせるとしても、そもそも何を作るべきかを決める必要があります。どのような入力を受け取り、どのような処理を行い、どのような出力を返すのかを定義する必要があります。エラーが起きた場合の挙動、データの保存先、権限、運用フローも考えなければなりません。
つまり、コードを書く作業が減ったとしても、設計する仕事は残ります。むしろ重要になります。
ここでいう設計とは、単に画面設計やDB設計だけではありません。業務、情報、AI、外部ツール、人間の確認、運用を含めた全体設計です。
従来のエンジニアリングでは、要件定義、設計、実装、テスト、運用という工程がありました。生成AIの登場によって、実装工程の一部はAIに置き換わるかもしれません。しかし、要件定義、設計、検証、運用の重要性はむしろ増していく可能性があります。
AIがコードを書く時代には、人間には「何を作るのか」「なぜ作るのか」「どう使うのか」「どこまで任せるのか」を決める力が求められます。
8. ハーネス自体もAIが設計し始める
ただし、ここでさらに考えるべきことがあります。
プロンプトだけでなく、コンテキスト設計やハーネス設計そのものも、AIが支援し始めているという点です。
すでに Claude や ChatGPT は、フォルダ構成の提案、API設計、DBスキーマの作成、MCP構成の検討、ワークフロー設計、エラーハンドリング方針の提案などをかなり行えます。
つまり、人間がAIに対して「この業務を自動化したい」と説明すれば、AIがそのための構成案を出すことは可能になっています。プロンプトを書くAI、コンテキストを整理するAI、ハーネスを設計するAIが出てくるのは自然な流れです。
では、人間の役割はさらに小さくなるのでしょうか。
一部はそうだと思います。定型的な設計、よくある構成、一般的な連携パターンは、AIがかなり作れるようになります。
しかし、だからこそ人間側には、より上位の判断が求められます。
その業務は本当に自動化すべきなのか。
どこまでAIに任せてよいのか。
誤処理が起きた場合の責任はどうするのか。
現場の人が使える形になっているのか。
長期的に保守できるのか。
セキュリティ上のリスクは許容できるのか。
その仕組みは事業上の価値を生むのか。
AIが設計案を出せるようになるほど、人間には、その設計案を評価する力が必要になります。
9. 非エンジニアにも関係する変化
この変化は、ITエンジニアだけに関係するものではありません。
生成AIを業務に組み込む場合、現場の知識が非常に重要になります。経理、営業、製造、物流、カスタマーサポート、一次産業など、どの領域でも、実際の業務には現場固有の知識があります。
どの情報が重要なのか。
どこでミスが起きやすいのか。
どの判断は自動化してよいのか。
どこは人間が確認すべきなのか。
古いルールと新しいルールがどのように混在しているのか。
例外処理がどこにあるのか。
こうした情報は、現場を知らない人には見えにくいものです。
そのため、生成AI時代には、純粋な技術者だけでなく、現場を深く理解している人も重要になります。現場理解を持つ人が、AIに任せるべき作業を定義し、必要なコンテキストを整理し、業務に組み込む流れを設計できれば、大きな価値を出せます。
言い換えれば、これからは「コードが書ける人」だけでなく、「業務を構造化できる人」が重要になります。
現場の問題を言語化し、情報の流れを整理し、AIに任せられる形に変換する力。これは、エンジニアと非エンジニアの境界を少し曖昧にしていくように思います。
10. まとめ
生成AIの活用は、段階的に変化してきました。
最初に注目されたのは、プロンプトエンジニアリングでした。AIへの指示をどう書くか、どう頼むか、どう出力を制御するかが重要とされました。
次に重要になったのが、コンテキストエンジニアリングです。AIにどう指示するかだけではなく、何を知った状態で考えさせるかが重要になりました。必要な情報を選び、整理し、適切な形で渡すことが、出力の質を大きく左右するようになりました。
そして最近では、ハーネスエンジニアリングが重要になっています。AIに答えさせるだけでなく、実際の業務の中で動かすための環境や仕組みを設計する必要が出てきたからです。フォルダ構成、MCP、API、外部ツール、データベース、ログ、権限管理、確認フローなどを含めた実行基盤の設計が求められます。
この3つを整理すると、プロンプトは指示、コンテキストは情報、ハーネスは仕組みです。
生成AIを本格的に使うには、この3つを別々に理解しつつ、全体として設計する必要があります。
そして、この変化はIT人材像にも影響します。これからのITエンジニアには、コードを書く力だけでなく、問題を構造化する力、情報を設計する力、AIと外部ツールを組み合わせる力、品質を検証する力、現場で運用できる仕組みに落とし込む力が求められます。
生成AIによってコードを書く量は減るかもしれません。しかし、設計する力の重要性はむしろ増していくはずです。
AIが実装を担う時代には、人間には、何を作るか、何を任せるか、何を確認するか、どのように運用するかを判断する力が求められます。
プロンプトを書く人から、コンテキストを設計する人へ。
さらに、AIが働く環境を設計する人へ。
生成AI時代のIT人材は、単なる実装者というより、情報と業務とシステムをつなぐ設計者に近づいていくのだと思います。
コメント