なぜプロンプトエンジニアリングの次がハーネスなのか
質問と回答だけをやり取りしていた時代のAI活用法は、プロンプトを磨き、RAGでコンテキストを丁寧に与えることでした。モデルが弱かったため、入力を丁寧に包装しなければ良い答えが出ませんでした。今のモデルは違います。賢く、できることも多い一方、自由に放つと見当違いの方向に走ります。
そこで焦点が「入力の包装」から「行動の設計」へ移りました。エージェントにどのツール(ファイル読み書き、Web検索、ターミナル実行)を許可するか、どの順序で働かせるか、何を禁止するか。これがハーネスエンジニアリングであり、プロンプトエンジニアリングの次の段階として定着しつつあります。
同じモデル、異なる性能 — ハーネスが分けるもの
興味深いのは、モデルを変えなくてもハーネスだけで性能が変わる点です。あるオープンソースエージェントは、AIがコード修正案を出力する形式を変えるだけで、コーディング性能を目に見えて向上させました。修正位置の特定方法や結果の検証方法といった動作構造が、モデルの知能と同じくらい結果を左右します。
これはコストの観点でも重要です。より高価なモデルへの乗り換えは最も簡単な選択ですが、ハーネスを手直しする方が安くて効果的な場合が多い。「AIを使ってみたがイマイチ」という評価の多くは、モデルの限界ではなくハーネスの不在から来ています。
非エンジニアにもできるハーネスエンジニアリング
エージェントのコードを直接修正するには開発知識が必要ですが、入口はそれよりずっと低い場所にあります。AGENTS.mdやSKILL.mdのようなマークダウンファイルに「これはするな」「このプロジェクト構造はこうだ」「この形式で出力せよ」と書いておくことも、立派なハーネスエンジニアリングです。エージェントは作業前にこれらの文書を読み、その通りに従います。
犬のしつけに似ています。良い犬を連れてくることより、訓練方法が結果を分けます。ただし命令が長く複雑になると聞き取れなくなるのも同じなので、ルールは短く明確に分割して文書化するのが良いでしょう。
AXの視点:ツール導入よりルールの文書化が先
SH ConsultingがAX(AI Transformation)教育でハーネスエンジニアリングを重視する理由もここにあります。組織に必要なのは新しいツールの導入ではなく、業務のルール・禁止事項・判断基準をAIが読める文書に移す習慣です。その文書が蓄積されれば、どのエージェントをつないでも組織のやり方で働かせることができます。