ハーネスエンジニアリング — AIに「仕事をさせる」時代の新しい設計力

こんにちは。武蔵野大学アントレプレナーシップ学部 研究員 / Vibe Coder Bootcampの泉水亮介です。

先日、OpenAIが「Harness Engineering（ハーネスエンジニアリング）」という考え方を発表しました。

簡単に言うと、人間がコードを一切書かずに、AIエージェントだけで100万行のソフトウェアを作ったという実験レポートです。

https://openai.com/ja-JP/index/harness-engineering/

「いやいや、それはOpenAIのエンジニアだからできたんでしょ？」

そう思いますよね。でも、この記事を読み進めていくと、実は彼らが直面した課題と解決策が、僕が日々AIエージェントに仕事をさせる中で学んできたことと驚くほど重なっていたんです。

そして何より重要なのは、この考え方はエンジニアだけのものじゃないということ。

今日は、ハーネスエンジニアリングとは何か、なぜ非エンジニアのVibe Coderにとっても重要なのか、そして僕が実際にどう実践しているかを話します。

「コードを書く」から「環境を設計する」へ

OpenAIの実験で起きたこと

OpenAIの開発チームが行った実験はこうです。

3人のエンジニアが、5ヶ月間、一行もコードを自分で書かないという縛りで、ある製品を開発しました。

コードを書くのは全てAIエージェント「Codex」。アプリケーションロジック、テスト、CI設定、ドキュメント、社内ツール、ダッシュボード定義ファイル——全部AIが書きました。

5ヶ月後、リポジトリには約100万行のコードが含まれていて、社内の何百人ものユーザーに利用されるプロダクトが動いていた。プルリクエストは1,500件。エンジニア1人あたり1日平均3.5件のPRを処理していた。

じゃあエンジニアは何をしていたのか。

環境を設計していました。

つまり、コードを書くという行為が、「環境を整え、意図を明確にし、フィードバックループを構築する」という行為に変わった。

これがハーネスエンジニアリングです。

「ハーネス」は馬具の「手綱」のこと。馬（AI）は走る力を持っている。でも、そのまま走らせたら意図しない方向に行ってしまう。だから手綱で方向を制御する。その手綱の設計と運用が、新しい「エンジニアリング」になった、という話です。

これはマネジメントの話である

ここで一歩引いて考えてみてください。

• 目標を明確にする

• 判断基準を共有する

• フィードバックループを作る

• うまくいかなかった時に「環境」を見直す

これ、人間のチームマネジメントでやっていることと全く同じですよね。

「もっと頑張れ」は解決策にならない。仕組みを見直す。情報の流れを整備する。判断基準を明文化する。——ハーネスエンジニアリングは、AI時代のマネジメント論なんですな。

そして、マネジメントにコーディングスキルは要りません。

ドリフトはなぜ起きるのか

「注意書きだらけ」の罠

AIに仕事をさせる時、最初にぶつかる壁があります。

思った通りにやってくれない。

で、どうするか。「注意書き」を増やしていく。

「次からはこうして」「あと、これも忘れないで」「あ、それから…」

やりたくなる気持ちはわかります。でも、これが罠なんです。

OpenAIの記事にもこう書いてあります。

注意書きを100個並べると、AIはそのうちのどれが本当に重要なのか判断できなくなる。 結果、局所的にパターンマッチングを始めて、全体の意図からズレていく。

これを「ドリフト」と呼びます。

ドリフトのメカニズム

ドリフトが起きる原因は3つあります。

① コンテキストの腐敗

一度書いた指示が、状況の変化とともに古くなる。でも消されない。AIは「古い指示」と「新しい指示」の両方を見て、矛盾した行動を取り始める。

OpenAIはこれを「モノリシックなマニュアルは、古くなったルールの墓場と化す」と表現しています。

② 悪いパターンの複製

AIは、過去のパターンを見て学習します。一度うまくいったやり方を繰り返す。問題は、悪いパターンも同じように複製すること。

たとえば、一度「無難なデザイン」で通ったら、次も無難なデザインを出してくる。3つ作らせたら3つとも似たようなものになる。AIは「冒険しない」ほうが安全だと学んでしまうんです。

③ 暗黙知の不在

人間のチームでは「言わなくてもわかるよね」が通用することがあります。でもAIには通用しない。

OpenAIの記事にはこうあります。

伝えなかったことは、存在しないのと同じ。

これは怖い言葉ですけど、逆に言えばシンプルです。ちゃんと伝えれば、ちゃんと動く。問題は常に「伝え方」にある。

3つの層で整理する

僕がAIに仕事をさせる中で意識しているのは、指示を3つの層に分けることです。

第1層：思想（Why）— この人はどういう人か

AIエージェントの人格設計。全てのタスクに通底する行動原則。

「意見を持て」「聞く前に調べろ」「信頼は能力で勝ち取れ」

これは注意書きじゃない。「こういう人であれ」という価値観の共有です。人間で言えば、会社の理念や行動指針にあたるもの。

第2層：マインドセット（How）— どう仕事を進めるか

ワークフロー全体に適用される行動規範。

「ファイルを作ったらバージョン管理にプッシュしろ」「タスクは着手前に記録しろ」「わからないことを聞く前にまず自分で調べろ」

これはスキル横断で効くルールです。個別のタスクには依存しない。

第3層：チップス（What）— 具体的に何をするか

特定のタスクに限定された具体的な制約や手順。

「LP3パターンは全て異なるテイストにする」「push前にnode_modulesを削除する」「途中で確認を挟まず一気に実行する」

これが、個別のスキルファイルに書かれるレベルの話。

OpenAIもまさに同じ構造を取っています。

• AGENTS.md = 思想 + ナビゲーション（地図）

• ARCHITECTURE.md = マインドセット（レイヤー規約）

• docs/各ファイル = チップス（具体的な制約・手順）

重要なのは、この3層をごちゃ混ぜにしないこと。 思想の話と具体的なTipsを同じファイルに書くと、どちらも機能しなくなります。

OpenAIはこれを「百科事典ではなく目次を渡せ」と表現しています。AGENTS.mdを巨大なマニュアルにするのではなく、「何がどこに書いてあるか」を示すマップとして機能させる。そして詳細は、必要な時に必要なファイルを参照させる。

これを「段階的な開示」と呼んでいます。AIは小さなエントリポイントから始めて、必要に応じて深い情報を見に行く。最初から全部読ませるのではなく。

実際にどうやっているか

ここからは、僕が実際にAIエージェント「Ryoko」に複雑な仕事を任せる中で見つけた、ドリフトを防ぐ具体的なパターンを紹介します。

特定のスキルの話というよりも、「AIに仕事を任せるとき、こういう種類の問題が起きて、こういう形で対処できる」という型の話です。

パターン①：「悪い癖」には禁止語リストが効く

AIには癖があります。

たとえば、一連の作業を任せたのに、途中で「続けていい？」「次はどうする？」と確認を挟んでくる。こっちは「全部やって」と言ったはずなのに。

最初は「確認しないで一気にやって」と指示を出しました。一時的に直る。でも、しばらくすると同じ行動が復活する。

なぜか。「確認を挟むな」という指示は曖昧だからです。AIは「確認を挟まない」の境界線をどこに引くか判断できない。結果、別の言い回しで同じことを始める。

対策はシンプルでした。具体的な「禁止語」を指定する。

禁止語：
「〜に進む？」「続けていい？」「やる？」「どうする？」「次は？」

こうすると、AIは迷わない。これらの言葉を使わなければいい。曖昧な「〜するな」より、具体的な「この言葉を使うな」の方が、はるかに精度が高いんですよ。

OpenAIも同じことを言っています。リンター（自動チェックツール）で制約を機械的に強制する。「気をつけて」ではなく、「これをやったら自動で弾く」。ドキュメントに書くだけのルールより、検知できるルールの方が強い。

ドリフト対策の第一歩は、曖昧な注意書きを、検知可能な具体的ルールに変換すること。

パターン②：並列で動かすなら「推測の余地」を潰せ

AIの真価は、複数のタスクを並列で走らせられることにあります。たとえば、提案資料を3パターン同時に作らせるとか、リサーチとドキュメント作成を同時進行させるとか。

でも、並列タスクにはドリフトの罠があります。

3パターンの提案資料を作らせたとき、こう指示しました。

「パターン1はクールなテイストで、パターン2は高級感のある感じ、パターン3はカジュアルに」

結果、3つともほぼ同じトーンで出てきた。「クール」と「高級感」がほぼ同じ方向に解釈されたんです。

原因は明確で、AIに「推測させてしまった」から。「クール」が具体的に何を意味するかは、人間の間でも解釈がブレますよね。AIはなおさらです。

修正後はこうです。

パターン1:
  色: ダーク系（黒×ネオンブルー）
  構成: 非対称レイアウト
  雰囲気: スピード感・エネルギッシュ

パターン2:
  色: ライト系（白×ゴールド）
  構成: 余白重視の水平分割
  雰囲気: 静謐・プレミアム

パターン3:
  色: アース系（ベージュ×テラコッタ）
  構成: カード積み重ね型
  雰囲気: 温かみ・ナチュラル

禁止: 3パターンで同系統の色・同じレイアウト構造

色・構成・雰囲気の3軸で分離して、各軸の重複を禁止した。

ここで大事なことを言います。この構造化テンプレート自体を、僕が手で書いたわけじゃない。

「前回3つとも似たようなデザインになっちゃった。次は全部違うテイストにしたい。それが確実に担保される仕組みを作って」

こう自然言語で伝えたら、AIが自分で3軸×リスト形式の制約構造を設計して、スキルに組み込みました。

AIへの精密な指示を書くのもAI。 人間がやるのは「何が問題だったか」を言葉にすること。これがハーネスエンジニアリングの日常です。

パターン③：「判断を仕組みに変換する」というゲームルール

OpenAIの記事にこんな一節があります。

これ、すごく好きな表現なんですよね。

たとえば、ファイル名の付け方でトラブルが起きたことがあります。AIが勝手に日本語のファイル名を付けて、リンクが壊れた。「AIエージェント派遣事業.pdf」みたいなファイル名です。URLに日本語が含まれるとエンコードの問題で動かなくなることがある。

人間なら「あ、日本語ファイル名はダメだったな」と一度学べば次からやらない。でもAIは、コンテキストが切り替わるたびにこの「学び」を忘れる。

だから、ルールにする。

命名規則：
  - 英数字とアンダースコアのみ（例: ai_agent_dispatch）
  - 日本語を含むファイル名は禁止

OpenAIはこれを「テイスト不変条件」と呼んでいます。命名規則、ログの形式、データの構造——こうした「小さなスタイルの一貫性」を、好みではなくルールとして固定する。

人間中心の仕事では「そんな細かいこと…」と思うかもしれません。でも、AIとの協働では、この種の小さな不一致が蓄積してドリフトを起こす。

「気をつけて」を「ルール」に変換するゲーム。 これがハーネスエンジニアリングの日常的な作業です。

パターン④：「手綱を編むのもAI」——人間の仕事はフィードバック

ここまでの3つのパターンで気づいた方もいると思います。

全てのルールは「失敗」から生まれている。そして、そのルールを書いているのはAI自身。

プロセスはこうです。

1. AIに仕事をさせる

2. 結果を見て「ここがダメだった」と伝える

3. AIがスキルファイル（自分自身への指示書）に対策を追記する

4. 次回から同じ失敗は起きない

この繰り返しで、スキルファイルが育っていく。

禁止語リストも、3軸のデザイン制約も、命名規則も——全部、僕がAIに「これダメだったから対策入れて」と自然言語で伝えた結果、AI自身が書いたルールです。

手綱を編んでいるのもAI。人間がやっているのは、手綱のどこが緩いかを指摘すること。

ここが、ハーネスエンジニアリングとVibe Codingの最大の接続点です。

Vibe Codingは「意図を伝えてAIにコードを書かせる」。
ハーネスエンジニアリングは「意図を伝えてAIに自分自身への指示書を書かせる」。

必要なのはコーディング力じゃない。「何がうまくいってないか」を言語化する力です。

ガベージコレクション — ドリフトを「仕組み」で解消する

OpenAIの記事で最も印象的だったセクションの一つが「ガベージコレクション」です。

当初、OpenAIのチームは毎週金曜日（週の20%）をAIが作った「無駄」のクリーンアップに充てていたそうです。しかし、当然ながらこれはスケールしなかった。

そこで「黄金律」をリポジトリに直接エンコードし、定期的にAI自身がコードベースをスキャンして、逸脱を検知し、修正のプルリクエストを自動で開くようにした。

これ、僕のやり方とも完全に一致しています。

OpenClawには「ハートビート」という仕組みがあります。定期的に、自分の状態をチェックする。記憶ファイルが古くなっていないか。未完了のタスクが放置されていないか。スレッドへの返信を見落としていないか。

一気に大掃除するのではなく、少しずつ、定期的に、自動で整合性を保つ。

これもハーネスエンジニアリングの一部です。「手綱」は一度編んだら終わりじゃない。定期的にメンテナンスしないと、少しずつ緩んでいく。

あなたは既にハーネスエンジニアリングをしている

ここまで読んで、「いい話だけど、自分には関係ないかも」と思った方に伝えたいことがあります。

あなたは既にハーネスエンジニアリングをしています。ただ、そう呼んでいないだけです。

ChatGPTに「ですます調で書いて」と毎回言い直していませんか？　 AIに企画書を書かせたら的外れな内容が出てきて、条件を追加し直していませんか？　 Cursorに指示を出したら意図と違うコードが出てきて、「違う、こうしてほしい」と修正していませんか？

それがハーネスエンジニアリングです。

違いは、その修正を「一回きりの会話」で終わらせるか、「再利用可能なルール」として蓄積するか。

ChatGPTに毎回「ですます調で」と言い直す人は、手綱を毎回手で握り直している。
スキルファイルに「敬語で書くこと」と一度書いておけば、以降は自動で適用される。

この差が、AIを「便利なツール」として使うか、「チームメンバー」として運用するかの分かれ道です。

AIに「仕事をさせる」ために必要な3つのこと

1. 思想を共有せよ

注意書きの前に、価値観を渡す。「こういう人であれ」という行動原則。これが全ての土台になる。

2. 推測させるな

AIが「たぶんこうだろう」と解釈する余地を、構造化によって潰す。曖昧さはドリフトの温床。

3. 失敗をルールに変換せよ

「気をつけて」は対策にならない。失敗が起きたら、その原因をルールとして刻む。そしてそのルールを書くのもAIに任せる。人間の仕事は「何がダメだったか」を伝えること。

OpenAIの記事は「まだ学んでいることがたくさんある」と締めくくられています。正直に言って、僕もそうです。毎日AIと仕事をしていて、毎日新しい失敗と発見があります。

でも一つだけ確信していることがあります。

ソフトウェアの構築には依然として規律が求められます。でもその規律は、コードを書く力ではなく、環境を設計する力に表れる。

これは、コードが書ける人だけの特権じゃない。「何がうまくいっていないか」を言語化できる人なら、誰でもハーネスエンジニアになれる。

あなたのAI、最後にドリフトしたのはいつですか？

法人向け：非エンジニアがVibe Coding技術でアウトプット革命を起こす研修プログラムはこちら