AI開発でよく聞く「プロンプト」「コンテキスト」「ハーネス」を整理してみる

みなさん、こんにちは！
現役IT執行役員のグイグイです⚡

最近、AIを使った開発について考える機会がかなり増えました。

GitHub Copilot、Cursor、Claude Code、Codex、AIエージェント。このあたりが一気に広がってきて、「AIをどう使うか？」は避けて通れない話になっています。

そこで、改めて整理しておきたい言葉があります。

• プロンプトエンジニアリング

• コンテキストエンジニアリング

• ハーネスエンジニアリング

どれもAIをうまく使うための考え方ですが、見ているレイヤーが違います。

• プロンプトエンジニアリング：AIへの「指示」を設計する

• コンテキストエンジニアリング：AIが判断に使う「情報環境」を設計する

• ハーネスエンジニアリング：AIが安全に動く「実行基盤」を設計する

プロンプトエンジニアリングとは何か

一番わかりやすいのが、これです。

「この処理を実装して」とだけ言うのか、「あなたはJava 21・Spring Boot・Spring Batch・MyBatisを使う開発者です。以下の設計書に従い、既存のログ方針・例外処理方針・Nullの扱いに合わせて、Serviceクラスを実装してください。出力は差分形式で、最後にテスト観点も出してください」と伝えるのか。これだけで、AIの出力はかなり変わります。

プロンプトを構成する要素は大きく4つです。役割・目的、制約・ルール、良い例（Few-shot）、出力形式。この4つを意識するだけで、再現性がかなり変わります。うまい文章を書くことよりも、AIの振る舞いを安定させる設計の方が大事です。

私が実際にやっているのは、プロンプトを再利用資産として整備することです。その場のノリで頼むのではなく、クラス種別（Service/DAO/Repository）・処理種別（Chunk Batch/Tasklet）ごとに.promptファイルとして切り分けています。Copilot Instructionsや再利用テンプレと組み合わせることで、プロジェクト全体でAIの出力を安定させる仕組みにしています。

プロンプトは"指示文"ではなく、実装パターンを安定化する資産として設計する。これが実務での考え方です。

コンテキストエンジニアリングとは何か

プロンプトが「指示」だとすると、コンテキストは「判断材料」です。

どれだけ丁寧な指示を出しても、AIに渡している情報が悪ければ、良いものは出てきません。AIが判断に使う情報には、仕様書・ソースコード・ルール/規約だけでなく、ログ・履歴・外部ツールの実行結果なども含まれます。

ただし「全部渡せばいい」ではありません。情報過多はノイズになり、出力はむしろブレます。必要な情報だけ選んで、鮮度・出典・優先順位を意識しながら整える。雑な文脈は、生成のブレに直結します。

私がやっているのは、AIに渡す文脈を6つのレイヤーで整備することです。プロジェクト背景、技術スタック、共通設計（ログ/例外/Null/命名）、AI向け設計書（Excel→Markdown化）、インストラクション群（Copilot Instructions/.prompt）、そしてレビュー用チェックリスト。

設計書はExcelをそのまま渡すのではなく、Microsoft 365 Copilotを使ってMarkdown Specsに変換しています。ただし、その変換結果も人間がレビューする必要があります。AIに渡す文脈が間違っていたら、その先の実装もテストもレビューも全部ズレるからです。

プロンプトだけでは足りない。AIに見せる仕様・設計・ルールの質が、そのまま出力品質を左右する。 これがコンテキストエンジニアリングの本質です。

ハーネスエンジニアリングとは何か

ここからが、今後かなり重要になると思っている領域です。

AIにコードを書かせる、テストを書かせる、レビューさせる。ここまでは、すでにやっている人も多いと思います。ただ、実務で使うならそれだけでは足りません。

AIの作業サイクルは「調査→計画→実装→検証→レビュー」と回っていきますが、これを安全に回すには基盤が必要です。権限制御（最小権限でAIの操作範囲を制限する）、ログ（実行内容を記録し監査に備える）、人間承認（重要な変更は人間が最終確認する）、CIによる継続的な自動検証。AIに仕事を任せるだけでなく、実行・検証・承認の仕組みまで含めて設計することが必要です。

私が実際に回しているのは、6ステップのサイクルです。

①設計書準備（Excel→Markdown Specs化）→②実装（GitHub Copilot Enterprise/VS Code）→③自己検証（JUnit生成・実行・再テスト）→④静的解析（警告・エラー検知・自動修正）→⑤PRレビュー（Copilotレビュー＋人間レビュー）→⑥証跡・品質管理（コメント/エラー/修正履歴をCSV化）

AIが失敗したときの修正履歴はPowerShellツールでCSVに出力し、GitHub EnterpriseでPR・コメント・履歴を管理しています。AI自己レビューも工程に組み込んでいます。

AIの生成物だけでなく、AIの失敗・修正・レビューの過程まで記録し、次の改善に戻せる開発基盤にする。 これがハーネスエンジニアリングの実践です。

設計の品質が低いと、AIを使っても良いものはできない

AIを使えば開発は速くなります。これは間違いありません。

ただし、設計の品質が低いままAIを使うと、間違ったものが速く、大量に、見た目だけきれいに作られる可能性があります。

AIは、曖昧な仕様をそれっぽく補完します。共通設計が弱ければ勝手に判断します。例外処理の方針がなければ、それっぽい例外処理を書きます。コードとしてはきれいに見えることがある。でも、それが本当に業務仕様に合っているのか。運用に耐えるのか。監査に耐えるのか。ここは人間が見なければいけません。

AI時代は、設計力のない開発者が救われる時代ではなく、設計力の差がよりはっきり出る時代だと思っています。なぜなら、AIの出力品質は、前提となる設計品質に強く依存するからです。

まとめ

プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング。

最初はプロンプトだけでも効果があります。ただ、実務でAIを本格的に使うなら、それだけでは足りません。

AIに何を見せるのか。どのルールに従わせるのか。どう検証するのか。AIの失敗をどう記録し、どう次の改善に戻すのか。

ここまで考えて、ようやくAIを開発工程に組み込めると思っています。

AIを使えばコードを書く速度は上がる。でも、良いシステムができるかどうかは、結局その前提にある設計・文脈・検証の仕組みにかかっています。

これからの開発では、プロンプトを整え、コンテキストを整え、ハーネスを整えられる人の価値がかなり上がっていくはずです。

#プロンプトエンジニアリング
#コンテキストエンジニアリング
#ハーネスエンジニアリング
#AI活用
#生成AI
#GitHubCopilot
#エンジニア
#AI開発
#AIと仕事
#ソフトウェア開発