ハーネスエンジニアリングとは｜Claude Codeでアプリ開発の質が変わる3つの仕組み

 

「僕が実際に同じ一文で2つのアプリを作らせたら、片方だけ保存したデータが消えました」

 

AIにアプリを作らせると、たいてい動くものは返ってきます。問題はその先です。ボタンは付いている、画面も動く、けれど再読み込みしたらデータが消えている。こういう不具合は、人間が画面を見ているだけでは気づけません。指示の書き方を工夫しても、モデルを新しくしても、この手の見落としは減りませんでした。

 

こんにちは、ルーティンラボ（@rutinelabo）です。本記事では、いま開発現場で急速に語られるようになったハーネスエンジニアリングという考え方を、実際に動くアプリを2つ作りながら解説します。あわせて、僕が普段の資料作成で回している検証ループの実測値もお伝えします。

 

LINE友だち登録して情報Get

 

 

結論｜AIを賢くするのではなく、AIの周りに仕組みを置く

 

先に結論をお伝えします。ハーネスエンジニアリングとは、AIそのものを賢くするのではなく、AIの「周り」に仕組みを置いて失敗しにくくする考え方です。プロンプトを磨くのでも、より賢いモデルに乗り換えるのでもありません。AIが作業する環境の側に、合格条件と検証の手順をあらかじめ置いておきます。

 

ハーネスという言葉は、もともと馬に取り付ける馬具のことを指します。手綱や胴回りのベルトで、馬をうまく扱えるようにする道具です。この馬をAIだと思ってください。馬そのものを速くするのではなく、扱うための道具を整える。それがハーネスという表現になっています。

 

やることは3つだけです。合格条件を先に出す、AI自身に検証させる、触ってよい範囲を決めておく。この3つを回すと、こちらが一回一回チェックして指摘する手間が大きく減ります。

 

 

ハーネスあり・なしで生成物がどう変わるか

 

言葉で説明するより、実物を見ていただくほうが早いと思います。同じ「マス目を塗れる描画アプリを作って」という一文で、ハーネスを組んだ環境と組んでいない環境の2つでアプリを作らせました。

同じ「マス目を塗れる描画アプリを作って」で2つ作りました。

片方は保存を押して再読み込みすると絵が消えます。もう片方は残ります。

違いはAIの賢さではなく、AIの周りに置いた仕組みだけ。

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

— せなお| AIとITを使った仕事術 (@rutinelabo) 投稿を見る

 

どちらのアプリも、見た目はきちんと出来上がっています。マス目が並んでいて、色を選んで塗れて、保存ボタンも付いています。ここまでは違いがありません。実際に絵を描いて、保存ボタンを押すところまで同じように動きます。

 

差が出るのはその次です。ハーネスなしの環境で作ったアプリは、ページを再読み込みすると描いた絵がきれいに消えます。保存ボタンをわざわざ押しているのに、何も残っていません。一方でハーネスありの環境で作ったアプリは、何度再読み込みしても絵がそのまま残ります。

 

 

簡単なアプリを1つ作るだけでも、環境を整えているかどうかで完成物の質が変わってしまいます。ここをうまく設計できる人かどうかで、これから生成AIの使い方が上手な人かどうかが大きく分かれていくと感じています。

 

よくある3つの誤解

 

ハーネスという言葉が広まるにつれて、いくつか誤解も見かけるようになりました。先に整理しておきます。

 

よくある理解	実際のところ
テストを書くことだ	テスト項目は3つのうちの1つ。権限やルールの設計も同じくらい重要
全部を自動化できる	最後の判断は人間がする。人間が見る前に、AIが何度も確かめてくれる状態を作るだけ
AIが賢くなる	モデルの性能は変わらない。作業する環境の側を整えている

 

とくに3つ目は大事です。ハーネスを組んでも、AI自身の推論能力は1ミリも上がりません。上がるのは「どういう作業をして、どういう作業をしないか」の精度です。それでも結果として返ってくる生成物の質は上がるので、使っているとAIが賢くなったように感じます。この体感のズレが、そのまま誤解として広まっているのだと思います。

 

もうひとつ、自動化を目的にしないことも大切です。最終的に人間が判断する工程は必ず残ります。ただしその手前で、AIがチェックにチェックを重ねて、テストをクリアした状態のものを出してくる。この状態を作るのがハーネス設計です。

 

どこにハーネスを置くと効くのか

 

すべての作業に仕組みを置く必要はありません。置いて効くのは次のような場所です。

 

 

逆に、1回きりの作業や、人にしか決められない判断には向きません。「このデザインが好みかどうか」のような項目は、機械に判定させようがないからです。繰り返し発生していて、かつ合否が機械で判定できる。この2つが重なる場所から手を付けるのが早道です。

 

ハーネスに置く3つの仕組み

 

実際に置く中身を、3つに分けて見ていきます。

 

step
1受入条件を、コードより先に出す

 

アプリを作らせる前に、「どうなったら合格か」を文章で渡します。今回の描画アプリなら、こう書きました。マス目を塗れること。保存ボタンを押したらデータが保存されること。再読み込みしたときに、以前描いたイラストが残っていること。

 

ポイントは、この時点ではアプリのコードを一行も書かせないことです。受入条件とアプリを同時に作らせると、AIは自分が作りやすい条件を書いてしまいます。条件が先、実装が後。この順番を崩さないだけで、出来上がるものが変わります。

 

step
2AI自身に、ブラウザでテストさせる

 

次に、その受入条件を満たしているかをAI自身に確かめさせます。ブラウザを実際に立ち上げて操作させ、合格か不合格かを出させる。不合格なら、通るまで自分で修正させます。人間が「ここが動いていません」と指摘して回る工程が、ここで丸ごと消えます。

 

step
3触ってよい範囲とルールを決めておく

 

サンドボックスと呼ばれる考え方です。コードを書いてよいのはこのフォルダの中だけ。履歴の操作や設定ファイルには触らない。頼んでいない変更や削除は絶対に行わない。こうしたルールをあらかじめ渡しておきます。

 

僕はローカルで動くAIエージェントにメールの下書きを作らせていますが、そこには「勝手にメールを送信しない」という一行を必ず入れています。報告の形式や、迷ったときに許可を求めるかどうかも、あらかじめ決めておきます。

 

迷ったときの判断まで決めておくと効果的です。「シンプルな見た目にするか、情報量の多い見た目にするか」で迷ったら、必ずシンプルなほうにする。こう書いておけば、AIは止まらずに作業を進めてくれます。毎回こちらが判断を求められる手間がなくなり、かなり自動化に近い形になります。

 

CLAUDE.mdとAGENTS.mdに仕組みを埋め込む

 

ここまでの内容を毎回プロンプトに書くのは現実的ではありません。そこで、開発環境のフォルダにファイルとして置いておきます。

 

ツール	読み込むファイル	置き場所
Claude Code	CLAUDE.md	./CLAUDE.md または ./.claude/CLAUDE.md（プロジェクト）／~/.claude/CLAUDE.md（個人全体）
Codex ほか	AGENTS.md	プロジェクト直下

 

ここで1つ注意点があります。Claude CodeはAGENTS.mdを読みません（2026年9月時点・公式ドキュメント参照）。すでにAGENTS.mdを使っているリポジトリで両方に効かせたい場合は、CLAUDE.md側から取り込む書き方をします。

 

@AGENTS.md

## Claude Code 向けの追記
- src/billing/ 以下の変更はプランモードで行う

 

AGENTS.mdはコーディングエージェント向けのオープンフォーマットで、Codexのほか Google Jules、Aider、Cursor、Gemini CLI、GitHub Copilot などが対応しています。6万を超えるオープンソースプロジェクトで使われています（2026年9月時点・公式サイト参照）。

 

読み込まれる順番も知っておくと便利です。次の順に連結されます。上書きではないので、個人の設定に共通の考え方を書いて、プロジェクト側にはその案件固有のルールだけを書く、という使い分けができます。

 

順番	置き場所	効く範囲
1	組織の管理ポリシー	そのマシンの全セッション
2	~/.claude/CLAUDE.md	自分の全プロジェクト
3	./CLAUDE.md	そのプロジェクト（チームで共有）
4	./CLAUDE.local.md	そのプロジェクトの自分だけ

 

僕自身はホームディレクトリのCLAUDE.mdに、設計はFable 5.1、実装はOpus 5とGPT-6 Astraに割り振る、という方針を書いています。ハーネス設計・ループ・グラフの考え方を常に意識して運用する、という内容も埋め込んであります。こうしておくと、毎回の指示でハーネスを意識した書き方をしなくてよくなります。

 

なお、CLAUDE.mdは長いほど追従性が落ちます。1ファイル200行未満が目安です。ファイル種別ごとに出し分けたい場合は .claude/rules/ に分けて、frontmatterの paths でスコープを指定します（2026年9月時点・公式ドキュメント参照）。

 

あわせて読みたい：GPT-6 Astraの特徴5つ｜公式ガイドと1週間の実測でわかったコツ

GPT-6 Astraの特徴5つ｜公式ガイドと1週間の実測でわかったコツ

続きを見る

 

同じタブ・別タブ・開き直しの3つを試す

 

ここが今回いちばんお伝えしたい部分です。テストを書くといっても、書き方が浅いと通ってしまいます。

AIに作らせたアプリ、動いたから合格にしていませんか。

同じタブで再読み込み、別タブで開く、いったん閉じて開き直す。この3つは別の結果になります。

最後のひとつだけ落ちることがある。だからテストを先に渡します。

— せなお| AIとITを使った仕事術 (@rutinelabo) 投稿を見る

 

保存の確認ひとつ取っても、実は3種類あります。同じタブで再読み込みする、別のタブで開く、いったん閉じてから開き直す。この3つはブラウザの内部では別の動きになるので、結果も変わります。

 

浅いテストだけを書くと、同じタブの再読み込みでは通るのに、開き直すと絵が出てこないという状態が起こります。テストは緑になっているのに、実際に使うと壊れている。この状態がいちばん厄介です。

 

だから受入条件には「開き直しても残っていること」まで書いておきます。ブラウザベースでアプリを作れるサービスとの違いも、まさにここです。とりあえず作らせて動かしてみて、人間が何となく見て大丈夫そうだと判断する。その進め方では、人の目には見えない裏側のエラーや見落としが残ります。

 

実際に運用している検証ループの回数

 

この考え方は、アプリ開発だけの話ではありません。僕はこの動画の台本も、配布しているスライド資料も、同じ仕組みで作っています。

この動画の台本も資料も、同じ仕組みで作っています。

資料1本あたり検証ループが15〜17回。そのうち2回は条件を満たさず自動で差し替えになりました。

人が見る前に、機械が止めてくれる状態を先に作る。

— せなお| AIとITを使った仕事術 (@rutinelabo) 投稿を見る

 

資料を作るときは、チェック項目をあらかじめ決めてループで検証させています。実測すると、資料1本あたり15〜17回のループが回っていました。そのうち2回は条件を満たさず、自動で差し替えになっています。台本のレビューでは、重い指摘が3回あがってきました。

 

項目	実測値	内容
検証ループ	15〜17回	資料1本あたり、自動で回った回数
不合格	2回	条件を満たさず自動で差し替えになった
重い指摘	3回	人が見る前に止められた項目

 

チェック項目には、変わったものも入れています。たとえば「台本の都合をそのまま資料に載せない」という条件です。台本には「このタイミングでこれを見せる」といった収録側の都合が書かれることがあります。それが資料に残ると、見ている人からすれば関係のない情報が見えてしまい、少し冷めてしまいます。

 

以前は、質の低い台本がそのまま出てきて、一から作り直すことがよくありました。それなら自分で書いたほうが早い、という状態です。いまは過去の投稿やデータを分析したうえで提案まで返ってくるので、磨き上げた状態から始められます。そこに自分の経験や感覚を足して仕上げる、という作業に変わりました。

 

作った本人に、合否を出させない

 

最後に、いちばんおすすめの設定をお伝えします。検証するAIは、作ったAIとは別のものにすることです。

 

生成AIには、自分で作ったものを自分でチェックすると甘く評価するという傾向があります。人間でも自分の書いた文章の誤字は見つけにくいのと同じです。だから、1つ目のAIが何かを作り上げたら、検証とテストは別の生成AIにやらせる。このハーネスを組んでおくと、アウトプットの精度がはっきり変わります。

 

 

実際、この仕組みを入れてからは、コマンドが動かない、生成物が起動しないといった問題を先に見つけて、動くものだけを提示してくれるようになりました。こちらが一回一回指摘する手間がなくなったのが、いちばん大きい変化です。

 

あわせて読みたい：Claude Codeのセッション間メッセージ｜伝言でコピペ往復が消える

Claude Codeのセッション間メッセージ｜伝言でコピペ往復が消える

続きを見る

 

今日から試すなら、この順番で頼む

 

難しい設定から入る必要はありません。頼む順番を変えるだけでも効果があります。

 

step
1どんなアプリを作りたいかと、合格条件を先に渡す

 

いきなり「描画ツールのアプリを作って」ではなく、どういうものを作りたいかと、どうなったら合格かを先に伝えます。

 

step
2どんなチェックをするか、テスト項目を渡す

 

「こういうところをチェックするようにしてください」と伝えます。同じタブ・別タブ・開き直しの3つを明記しておくと確実です。

 

step
3触ってよい範囲のルールを渡す

 

書いてよいフォルダ、触らないもの、頼んでいない削除はしない。この3行で十分です。

 

この3つを渡してループを回させるだけで、返ってくるものの質が変わります。「ハーネスエンジニアリングの視点を用いて、開発と運用の環境を整えてください」と一言添えるだけでも、しっかり組んでくれます。

 

ループエンジニアリングとグラフエンジニアリング

 

最近は、似た言葉をいくつか見かけるようになりました。整理しておきます。

 

呼び名	やっていること
プロンプトエンジニアリング	AIへの入力そのものを工夫する
コンテキストエンジニアリング	ファイルを連鎖させて自動化の仕組みを組む
ハーネスエンジニアリング	AIの周りに合格条件と検証の仕組みを置く
ループエンジニアリング	作る→検証する→直す、を繰り返し回す設計にする
グラフエンジニアリング	関連するファイル同士の紐付きをはっきりさせる

 

順番としては、プロンプト、コンテキスト、そしてハーネスと来ています。ハーネスの仕組みをうまく使えるようになると、ループもグラフも自然につながっていきます。まずはハーネスから押さえるのがおすすめです。

 

まとめ｜測ったものしか、良くならない

 

ハーネスエンジニアリングについて、要点をまとめます。

 

 

ひとつだけ、正直にお伝えしておきたいことがあります。ハーネスを作っても、測ったものしか良くなりません。受入条件に書き忘れた項目は、いつまでも直りません。だからこそ、最初に「どうなったら合格か」を考える時間が、そのまま生成物の質になります。

 

バイブコーディングが当たり前になって、普段エンジニアではない方でもアプリを作れる時代になりました。だからこそ、この周りの仕組みを知っているかどうかで差が付きます。ぜひご自身の環境でも試してみてください。

 

次回は、僕が実際に設定しているCLAUDE.mdとAGENTS.mdの中身そのものを解説します。項目の書き方をそのままお渡しする予定です。Claude CodeやCodexを使っている方には、かなり実用的な内容になるかと思います。

 

LINE友だち登録して情報Get