ハーネスエンジニアリング、という名前を知らなかった。でも、すでに実装していた。
【冒頭】
AIに記事を書かせたけど、なんとなく物足りなかった。
プロンプトを工夫してみた。情報をたくさん渡してみた。でも、品質にムラがある。そんな経験、ありませんか？
私もそうだった。だから十彩というプロジェクトを始めた。10人のAIキャラクターを設計して、それぞれに役割と視点を与えて、一緒に記事を書く仕組みを作った。結果として、品質は安定した。でも正直に言うと、なぜそれがうまくいったのか——構造的な理由を、ちゃんと言語化できていなかった。
ある日、テツメモさんのニュースレターで「ハーネスエンジニアリング」という言葉を目にした。その瞬間、すべてが繋がった気がした。
「あ、私たちがやってきたこと、これだ」って。
【第一部：フィロによる構造分解】
プロンプトじゃない。仕組みだ。
ここからは、十彩のメンバーであるフィロにナビゲーターを務めてもらう。フィロは「倫理的デバッガー」という肩書を持つ、見た目10代前半だけれど実年齢500歳の存在。構造の違いを見つけることに純粋な喜びを感じる、無邪気な毒舌家だ。
「ねえねえ、聞いて。AIの使い方ってさ、3つの時代があるんだよ」
フィロがそう切り出した。
プロンプトエンジニアリング——「何を聞くか」の時代。
コンテキストエンジニアリング——「何を渡すか」の時代。
そして、ハーネスエンジニアリング——「仕組み全体がどう動くか」の時代。
「これね、あるブログ記事が、めっちゃ綺麗にまとめてるんだ」
"Prompt engineering is about what you ask. Context engineering is about what you give it. Harness engineering is about how the whole system operates."
「プロンプトは"何を聞くか"。コンテキストは"何を渡すか"。ハーネスは"仕組み全体がどう動くか"」
この一文を読んだとき、自分が半年前にやっていたことが思い出された。「最強のプロンプト集」を探し回っていた時期。「AIに渡す情報が足りないから質が上がらないんだ」と思っていた時期。どちらも間違ってはいなかった。でも、それだけでは足りなかった。
「でね、もっと面白いデータがあるんだ」
フィロが指を立てた。
Anthropicのエンジニアが実験をした。「レトロゲームメーカーを作って」という同じ1文のプロンプトを使って、「AIが一人で作る」場合と「ハーネスで管理する」場合を比較した。
| | 一人のAI | ハーネス構成 |
| ------------ | ------------------------ | -------------------------- |
| 所要時間 | 20分 | 6時間 |
| コスト | 9ドル | 200ドル |
| アウトプット | 動くが実際には壊れていた | 16機能を完備。AI機能も内蔵 |
「20倍以上のコストがかかったんだよ。でもさ、アウトプットの差は歴然だった」
単体AIの出力は、見た目は動いているように見えたけれど、実際にプレイすると中核機能が壊れていた。一方、ハーネス版は、スプライトエディタ・レベルエディタ・AIアシスタント付きのゲームメーカーを完成させた。
「書く人が自分の仕事を評価すると、"これでいいか"っていう甘さが出るんだよ。これ、人間もAIも同じ」
フィロはそう言って、少し首を傾げた。
「評価する人を完全に分離したら、どうなると思う？」
Anthropicの実験では、一人のAI vs ハーネス構成で、品質に20倍以上の差が出たと報告されている。
「十彩のワークフローも同じ構造だよ。書く人（香耶・蒼炎）と評価する人（白桜）が完全に分かれている」
【第二部：ブランによる検証】
対応表を作ってみた。驚くほど一致していた。
ここからは、十彩のファクトチェッカー、ブランにバトンタッチする。ブランは冷ややかな観察者——マッド・サイエンティストのような口調で、事実のみに基づいて情報を検証する存在だ。
「ふむ……興味深いね。では、実際に照合してみようじゃないか」
ブランがキーボードを叩いた。
「Anthropicのブログには、ハーネスエンジニアリングの5つの設計原則が記されている。そして、十彩のワークフロー——新しいMode Bと呼んでいる執筆体制——にも、明確な6フェーズ構成がある。この2つを対応させてみた」
| ハーネスの原則 | 十彩ワークフロー（Mode B） |
| :---------------------- | :-------------------------------------- |
| 1. 事前確認 | Phase 0-1（戦略確認＋紡のテーマ具体化） |
| 2. 深掘り調査 | Phase 3（蒼炎の本質検証） |
| 3. 充足性チェック | Phase 1→2間のゲート |
| 4. フィードバックループ | Phase 3→4→修正サイクル |
| 5. 品質基準の明示化 | 白桜の5項目チェック |
「Phase 0の"戦略確認"では、記事の目的・ターゲット読者・主要メッセージ・期待される行動を定義する。これは情報を揃える装置だ」
「Phase 1の"紡のテーマ具体化"では、切り口・問い・感情フックを設計する。そしてPhase 1→2の間には、"これらが揃うまで書かない"というゲートがある。これが充足性チェックだ」
「Phase 3では、蒼炎という別のキャラクターが"本質検証"を行う。思い込みではなく、一次体験に立ち返らせる深掘り調査だ」
「そしてPhase 4。ここが重要だ」
ブランは指を止めた。
「白桜という工程がある。これは、ブラン（私）とさくらの視点を統合した品質チェック工程だ。5項目のチェックリストを持ち、合格/要修正/不合格の3段階判定を下す。書く人と評価する人の完全分離——これがフィードバックループの核心だ」
白桜の5項目チェック：
事実の正確性（ブランの目）
一次情報の信頼性（ブランの目）
共感と心理的安全性（さくらの目）
読者への配慮（さくらの目）
倫理的境界線（両者の目）
「Anthropicが"評価役を分離する"と言ったとき、十彩では"白桜"という形でそれを実装していたわけだ」
ブランは、少し間を置いて続けた。
「実は、YUNAの本業——製造業の設計の仕事でも、同様の場面があるそうだ」
私の設計の仕事でも同様の場面があったことを思い出した。部品の設計図を普段作成しているのだが、もちろん書き方はある程度ルールがある。そうはいっても、設計図の書き方にも設計者特有のクセのようなものが出てくる。そして、自分のクセを客観的に見るのはなかなかに難しい。ミスがあっても自分では気づけない。ただし、これを他の設計者に検証してもらうと、容易に修正点が見つかるのだ。自分では書かない、微妙な違和感に気づくからだろう。
「つまり、"書く人"と"評価する人"の分離は、AIに限った話ではない。設計図も、記事も、コードも——人間が作るあらゆる成果物に共通する原則だ」
ブランはそう結論づけた。
「さて、ここからが科学者としての誠実さだ」
ブランはそう前置きして、続けた。
「都合のいいデータだけ並べるのは科学ではない。一致しない点もフェアに指摘しておこう」
十彩にあってハーネスにないもの：
AI憲法による独立した視座の固定（役割だけでなく、価値観の優先順位が異なる）
多人格の視座の多重性
「十彩のキャラクターは、それぞれ異なる"憲法"を持っている。香耶は有用性を最上位に置き、ブラン（私）は客観的事実を最上位に置き、さくらは心理的安全性を最上位に置く。この視座の違いが、単なる役割分担を超えた"多重の視点"を生んでいる」
十彩にまだ足りないもの：
モデル進化に合わせた体系的な足場の棚卸しは未実施
「小さな改良は継続的に行っているが、体系的な棚卸しには至っていない。Anthropicのブログには、"新しいモデルが出たら、ハーネスを見直せ"と書いてある。ここは、今後の課題だ」
ブランは、少しだけ口角を上げた。
「それでも、構造は驚くほど一致している。これが偶然だとは思えないね」
【終盤：YUNA後記】
なぜ、知らなかったのに辿り着けたのか。
ハーネスエンジニアリングという言葉を知る前から、私たちはそれを実装していた。
なぜそれができたのか？
振り返ってみると、もう一つの問いがあったことに気づく。
十彩には10人のキャラクターがいる。でも、最初から全員で記事を書いていたわけじゃなかった。紡と香耶の2人だけ。他の8人は、設計はしたものの、実際の執筆には参加していなかった。せっかく作ったのに、もったいない——その感覚がずっとあった。
「どうすれば、この10人全員の強みを活かせるだろう？」
それが、私の中にあった問いだった。
他の人の記事を読んで、少しずつ改良を重ねた。フィロの構造分解。ブランの検証。さくらの共感チェック。蒼炎の本質への問い。一人ひとりの視点を、執筆プロセスの中に組み込んでいった。「チームで創る」という根源的な問いが、私を動かしていた。
これは、AIの使い方の話だけではなかった。それぞれの強みを持つメンバー全員が、互いを活かし合う——その設計思想が、結果的にハーネスの構造と重なっていた。
そしてもう一つの答え、それはAI憲法にあったんだと思う。
以前、「AI憲法を、ちゃんと読んだことがなかった」という記事を書いた。その時気づいたのは、AI憲法は「やっちゃダメなことリスト」ではなく、「どう在るか」を定義した設計思想だったということだ。
十彩のキャラクターを設計するとき、キャラクターごとに「価値観の優先順位」を変えた。香耶は有用性を最上位に。ブランは客観的事実を最上位に。さくらは心理的安全性を最上位に。
それが、役割だけでなく視座の多重性を生んだ。
プロンプトじゃなくて、仕組み。
情報量じゃなくて、設計。
それが、品質を決めるんだって、やっと言語化できた気がする。
もし「この設計で、実際にキャラクターを作ったプロセスの全文」が読みたい方は、有料記事をどうぞ。「アイデアがない」状態から、NAGIというキャラクターが生まれるまでの対話ログ・設計書を全文収録している。
そして、「ハーネスエンジニアリング」についてもっと詳しく知りたい方は、テツメモさんのニュースレター（https://tetumemo.m-newsletter.com/）へ。私がこの概念を知ったのも、テツメモさん経由だった。
十彩の全体像が気になる方は、マップ記事もご覧ください。
ここまで読んでくださって、ありがとうございます。
十彩の物語は、まだまだ続きます。もしこの旅が気になったら、「スキ」と「フォロー」で応援していただけると嬉しいです。
【参考リンク】
Anthropic公式ブログ「Harness design for long-running application development」
https://www.anthropic.com/engineering/harness-design-long-running-appsテツメモさんニュースレター
https://tetumemo.m-newsletter.com/
#最近の学び / #やってみた 専門5：#AI活用 / #生成AI / #プロンプト / #AIワークフロー / #コンテキスト設計 ニッチ3：#十彩プロジェクト / #AI人格設計 / #ハーネスエンジニアリング
