AI エージェントを使うにつれて、だんだん渡す情報（プロンプト）が増えていきます。
目的を書き、制約を書き、参照先を書き、レビュー観点を書き、失敗したときの扱いまで書く。そうすると一応うまくいくこともあるのですが、ふと「自分はいま何をしているんだろう」と思う瞬間があります。これはプロンプトエンジニアリングなのか、ドキュメント整備なのか、単に人間が先回りしているだけなのか。まだ少し掴みきれない。
最近では Harness engineering1 といった言葉で説明されることも増えました。私もそれなりに工夫してAgentを使っていますが、その具体的な手法を紹介する前に、「これはつまり何が重要なのか」について、新しい言葉を掲げるだけでなく、これまでの言葉をつないで説明したいと思っていました。
ただ、それがなかなか難しい。「例示は理解の試金石2」という『数学ガール』のスローガンを借りるなら、私はこれをうまく説明できる例をまだ持てずにいました。
そんなとき、テレビドラマ『パリピ孔明』3の中に、その手がかりのようなものを見つけました。これからそれを紹介します。
孔明は、英子の代わりにやっていない
8話で、英子は自身で作曲した新曲について、奇跡みたいにいろんなことがつながってできた曲なのだと語ります。さらに、この曲を作る過程で、大切な人の存在に気づけたのだとも話していました。
英子の言葉だけを見ると、良い曲ができた背景には偶然や運命のようなものがあったように見えます。実際、本人にとってはそうだったのだと思います。ただ、視聴者は知っています。その「いろんなこと」のかなりの部分を、孔明が裏で整えていたことを。
英子が一人では越えにくい壁を見つけて、先回りして崩しておく。必要な人と出会えるようにする。けれど、本人の代わりに歌うわけでも、曲を書くわけでもない。孔明がやっているのは、成果を代行することではなく、英子の創造性が立ち上がる状況をつくることです。
『パリピ孔明』がおもしろいのは、孔明が万能だからではありません。むしろ、万能に見える孔明が、最後の最後で英子の中心には踏み込まないところにある気がします。
孔明は軍師なので、障害物を見つけるのがうまい。ボトルネックを見つけ、順序を組み替え、人を動かし、情報の流れを変える。かなり優秀なプロデューサーでもあり、オペレーション設計者でもあります。
とはいえ、孔明は英子の内側そのものを肩代わりできるわけではありません。歌うのは英子です。迷うのも英子です。腹をくくるのも英子です。だからこそ、英子から見ると「奇跡みたいにいろんなことがつながった」になる。
最初に書いた、「自分はいま何をしているんだろう」という感覚に、この距離感はよく似ています。
誰かの創造性を支えるとき、支援はしばしば二つの方向にぶれます。一つは放任です。本人の力を信じると言いながら、必要な情報も環境も用意しない。もう一つは介入しすぎです。良かれと思って、道筋も判断も手順も全部こちらで決めてしまう。
孔明のやっていることは、その間にあります。英子を信じるからこそ、放置しない。でも、信じているからこそ、奪いすぎない。この加減があるから、最後にできあがるものは「孔明の作品」ではなく「英子の曲」のままでいられます。
Harness engineering は、AI を管理しきることではない
この比喩がしっくりきたのは、OpenAI の Harness engineering の記事で書かれていたことと、かなり近い手触りがあったからです。印象に残ったのは、人間の役割を「全部自分でやること」から「意図と環境を設計すること」へ移す整理でした。
AI エージェントを使っていると、曖昧に頼むとうまくいかないので、つい細かく指示したくなります。これは自然な反応ですし、実際かなり大事でもあります。
ただ、毎回の手順をすべて人間が固定しようとすると、冒頭で書いたあの感覚に戻ってきます。やってほしいことは増えているのに、AI にはほとんど判断の余地がない。これでは「任せている」のか「人間が離れた場所から操作している」のか、だんだんわからなくなってきます。
Harness engineering が示しているのは、たぶんそういう方向ではありません。必要なのは、AI を縛り上げることではなく、AI が安全に、しかも意図に沿って動きやすくなる足場をつくることです。
たとえば、
- 何をゴールとみなすのか
- 何をしてはいけないのか
- どんな情報源を信頼してよいのか
- 迷ったら何を優先するのか
- できあがったものを何で検証するのか
こうしたことを先に整えておく。そうすると、細部の実行はエージェントに任せやすくなります。
これは、孔明が英子の前に立って逐一「次はこう歌って、次はこう悩んで」と命じる話ではありません。むしろ、英子が英子として前に進めるように、状況そのものを設計しているという話に近い。だからこそ私は、『パリピ孔明』を見たときに、Harness engineering という言葉を、この作品で説明できるのではないかと思いました。
良いプロンプトより先に、良い場がある
ここまで読むと、「では、プロンプトは雑でよいのか」と見えるかもしれません。もちろんそんなことはありません。具体的な依頼、明確な制約、評価基準の共有は、今でも AI 活用の基本です。
ただ、視点を少しずらすだけで、やっていることの名前はかなり変わって見えます。毎回「正しい命令」をひねり出しているのだと思うと息苦しいけれど、「AI がうまく働ける場を整えている」と捉えると、いま気にしているものの意味がつながってきます。
たとえば Coding Agent に実装を頼むとき、本当に効くのは単発の命令文だけではありません。
- どのディレクトリに何があるか
- 既存コードの流儀がどこに書かれているか
- テストをどう回すか
- レビューで何を重視するか
- 失敗したときにどこまで自律的にやってよいか
こうした周辺情報が揃っていると、エージェントは急にまともになります。逆に、プロンプトだけが立派で、周囲の文脈がぐちゃぐちゃだと、何度やっても不安定になります。
これは人間相手でも同じです。優秀な人に仕事を頼んでも、背景も判断基準も共有されていなければ、お互いに消耗します。丁寧な人ほど確認コストを背負い、雑な人ほど見当違いの成果物を出す。だから本当に設計すべきなのは、個別の指示文だけではなく、仕事が自然にうまく進みやすい環境です。
良い成果を出したいなら、毎回「正しい命令」をひねり出すことより、知識が置かれている場所、守るべき境界、確認方法、責任の持ち方を整えるほうが効くことがある。言い換えると、AI を使う技術というより、AI が働く職場をつくる技術に近いのかもしれません。
そう見えてくると、Harness engineering という少し硬い言葉も、急に遠い話ではなくなります。新しい概念を覚えるというより、すでにやっていることに別の焦点を当てる感じです。
それは、創造性を信じるということでもある
ここで孔明の比喩が単なる運用論で終わらないのは、英子自身が、自分の曲について自分の言葉で話しているからです。
「奇跡みたいに、いろんなことがつながってできた曲なんです」
この言い方には、計画どおりではなかったものが、あとから一つの意味を持ち始める感じがあります。創作にはたぶん、そういうところがあります。最初から全部を説明できるわけではないけれど、後から振り返ると、必要だった出来事がつながって見える。
孔明は、その「あとから意味が立ち上がる余地」を壊していません。全部を説明しすぎず、全部を支配しすぎず、けれど偶然だけに任せない。その絶妙さが、英子から「自分の曲です」と言える余白を守っている。
AI と働くときにも、少し似たことが起きます。
AI はもちろん人間ではないし、創造性の意味も同じではありません。それでも、何もかも人間が固定してしまうと、AI の探索能力や組み合わせの面白さは痩せていきます。一方で、ただ放り投げるだけでは、実用に耐える結果にならない。だから必要なのは、自由か管理かという二択ではなく、自由が良い方向に働きやすいように支える設計です。
そう考えると、Harness engineering という言葉はしっくりきます。手綱を強く握るためではなく、走る力をうまく受け止め、向きを与えるための仕組み。管理ではあるけれど、支配ではない。制約ではあるけれど、可能性を潰すためのものではない。そういう設計です。
じゃあ、何を整えればよいのか
ここまで来ると、冒頭の「自分はいま何をしているんだろう」に対して、ひとつ答えが出てきます。私たちは AI に命令文を書いているだけではなく、AI が判断し、試行し、戻ってこられる場を整えている。
たとえば、こんな場面があります。Coding Agent に実装を頼んだら、見た目だけはそれっぽい PR が返ってくる。でも、テストは通っていない。既存の命名規則も外している。本人なりに頑張ってはいるのだけれど、どこを見ればよいかがわからないので、ただ近くにありそうな形を真似してしまう。
このとき、人間が追加でやりがちなのは、「次はこうして」「そのファイルは触らないで」「テストも見て」「いや、その命名はだめで」と、逐一手順を足していくことです。もちろん一時的にはそれで直ります。ただ、それだけだと、次のタスクでもまた似たような指示が増えていく。
たぶん整えたいのは、その都度の命令文より、AI が最初から迷いにくい場のほうです。ここからは、その 場を整える をもう少し手触りのある形にするための、いくつかの見取り図です。正解の一覧ではありません。
1. ゴールより先に、判断基準を置く
「このタスクを終わらせて」だけだと、AI は見た目がそれっぽいものを返しがちです。何をもって良しとするか、どんな失敗を避けたいかを先に置くと、行動がかなり安定します。
2. 参照してほしい知識を、埋もれない場所に置く
長い一枚の指示書に全部を書くより、短い入口と整理された参照先があるほうが、あとから保守しやすいです。これも OpenAI の記事が強調していた点でした。
3. 自律性の範囲を決める
どこまで勝手に直してよいのか、どこからは人に確認すべきか。この線引きがないと、人間も AI もお互いに不安になります。
4. 検証のループを先に決める
テスト、レビュー観点、セルフチェックの手順があるだけで、AI の試行錯誤はかなり健全になります。大事なのは、一回で当てさせることより、間違っても戻れることです。
どれも派手ではありません。けれど、こういう地味な整備があると、AI のふるまいは「たまたま当たる」から「だいたい外しにくい」へ変わっていきます。単発の名プロンプトより、長く効くのはたぶんこちらです。
もし Harness engineering という言葉に少し構えてしまうなら、まずは「AI のための説明書を書く」と考えるより、「AI が働きやすい舞台を整える」と考えてみるとよいのかもしれません。そのほうが、この概念はずっと具体的になります。
孔明のようにはできなくても
さすがに孔明のように、すべてを見通して人と状況を動かすのは無理です。私たちはもっと鈍いし、だいたい途中で読み違えます。（きっとそれは近い将来AIの方が上手になるでしょう。）
それでも、AI を使うときに「どう命令すれば思いどおりに動くか」だけを考えるのではなく、「どういう環境なら自然とよい振る舞いになりやすいか」を考えることはできるはずです。
英子が見ていたのは奇跡だったのかもしれません。でも、視聴者は、その奇跡のかなりの部分が丁寧に準備されたものだったと知っています。
AI と働く日々にも、たぶん似たことがあります。良いアウトプットがたまたま生まれたように見えるとき、実はその背後には、見えにくい設計がある。
もし最近、AI への指示が細かくなるばかりで少し息苦しいと感じているなら、一度プロンプトそのものではなく、その周辺を見直してみるとよいと思います。手順を増やす代わりに、場を整える。そうすると、Harness engineering という言葉は、急に遠い概念ではなくなってきます。
新しい知識を覚えるというより、すでに起きていることの見方を変える。そのとき私たちが目指しているのは、AI を完全に従わせることではなく、英子の歌が英子の歌として立ち上がるように、見えない準備を整えることなのだと思います。
奇跡に見える仕事の裏に、いつも少しだけ軍師の仕事がある。パリピ孔明は、そのことを気づかせてくれました。
-
OpenAI の記事 Harness engineering: leveraging Codex in an agent-first world（2026-02-11）は、この言葉を広く印象づけた代表的なブログです。要点は、人間の仕事を「コードを直接書くこと」から「エージェントが動きやすい環境、制約、検証ループを設計すること」へ移すことにある、というもの。空のリポジトリから約5か月で、手書きコードゼロのまま約100万行・約1500 PR の内部実験を題材にしています。なお、私が追えた範囲でこの語をかなり早い時点で明示的に使っている原典候補は、Mitchell Hashimoto の My AI Adoption Journey（2026-02-05）の「Step 5: Engineer the Harness」です。そこで彼は、エージェントの失敗を見つけるたびに、同じ失敗を繰り返さないための道具やルールを整備していく実践を
harness engineeringと呼んでいます。↩ - 《例示は理解の試金石》——これは、僕たちが大事にしているスローガンだ。 抽象的なことや複雑なことを「理解した」かどうかを試すには、「例を作る」のがいいという意味になる。 理解しているかどうか不安になったら、例を作ろう。・適切な例を作ることができたなら、自分は理解している。・適切な例を作ることができなかったら、自分は理解していない。 https://girlnote.hyuki.com/trial/033/↩
- 『パリピ孔明』は、三国時代の諸葛孔明が現代の渋谷に転生し、歌手を目指す月見英子を軍師として支える物語です。孔明は英子の代わりに歌うのではなく、壁を崩し、人や情報の流れを整え、英子が前に進める状況をつくっていく。その構図が、この記事で考えたいことにかなり近く感じられました。 https://www.fujitv.co.jp/paripikoumei/↩
