「さっき伝えた条件が、途中から消えている」
「直してほしいのは一部分なのに、気に入っていたところまで変わった」
「完成しましたと言われたのに、ボタンを押しても動かない」
AIに文章や資料、サイトを作ってもらって、こんな経験はないでしょうか。
そのたびに説明をやり直し、間違いを探し、また修正を頼む。気づいたら、自分がAIの作業をずっと見張っています。
そこで考えたいのが、ハーネスです。
難しそうな名前ですが、考えることは身近です。何を任せるのか。どの資料を使うのか。どう確かめるのか。間違っていたらどこを直し、いつ止めるのか。この「仕事の進め方」を、AIの外側に用意します。
この記事で扱うAstraはOpenAIのGPT-6 Astra、FableはAnthropicのClaude Fable 5.1です。2026年9月10日時点の公式資料をもとに、後半では告知文、売上集計、サイト制作への応用を考えます。
なお、明日こちらから1日限定でハーネス動画を配布予定👇
https://x.com/MakeAI_CEO/status/2027682940847898770?s=20
1．ハーネスとは、AIが仕事を進めるための仕組み
たとえば、仕事ができる人に「来月のイベントを宣伝してください」と頼んだとします。
その人の能力が高くても、開催日、参加費、申込先、対象者を知らなければ、正確な案内は作れません。会社のSNSを操作する権限がなければ投稿できませんし、公開してよいか決まっていなければ勝手には出せません。
そこで、イベントの資料、文章の見本、作業手順、確認項目、公開前の承認ルールを渡します。
AIにも、同じような準備をする。それがハーネスを理解する入口です。
ハーネスとは、AIに渡す情報、使わせる道具、作業の進め方、確認や制限をまとめた仕組みです。
実際、Claude Codeの公式資料では、モデルの周囲に道具、情報管理、実行環境を提供するものとして、Claude Code自体をハーネスと説明しています。
ここで、似た言葉を整理しましょう。
「プロンプト」は、AIへの依頼文です。「コンテキスト」は、AIがその作業中に参照する情報です。「ハーネス」は、それらを使いながら仕事を進める全体の仕組みです。
イベント告知なら、「案内文を書いて」がプロンプト。開催概要や過去の告知文がコンテキスト。資料を読む、文章を作る、日時を照合する、承認後に公開する、という流れを動かす仕組みがハーネスです。
つまり、長いプロンプトを一つ作れば、それだけでハーネスが完成するわけではありません。
「公開前に確認して」と文章に書くことと、確認が終わるまで公開操作を止めることには、違いがあります。
この記事でいう「ハーネス理論」は、この違いを踏まえてAIの仕事場を設計する考え方です。一つの決まった数式や、特定モデル専用の機能名として扱うものではありません。
2．AstraやFableが賢くなっても、準備は必要なのか
「そんな準備をしなくても、新しいAIなら自分でやってくれるのでは？」
そう考えるのは自然です。実際、Astraの公式発表では複数の手順を伴う仕事への対応が説明され、Fable 5.1も長時間にわたる問題解決能力の向上を打ち出しています。
ただし、「考える能力」と「必要な条件がそろっていること」は別です。
非公開の参加費を渡していなければ、どれほど賢くても、その正しい金額を確定できません。申込フォームにつながっていなければ、実際に申し込めるかは確認できません。
注目したいのは、OpenAI自身がAstraの発表で、モデルの改良とは別にCodexのハーネスも更新したと説明していることです。作業を続けるための情報の保持や検索についても、新しい仕組みを紹介しています。
モデルを賢くすることと、働く環境を整えること。両方が進められているわけです。
一方で、賢いAIに一字一句まで細かく命令する必要はありません。決めておきたいのは、目的、守る条件、使える資料、確認方法です。その範囲内での工夫は任せる。この分け方を目指します。
3．最初に決めるのは、手順より「何ができたら完成か」
ハーネスを作るとき、最初に書きたいのは合格条件です。
「よい告知文」「売れるページ」「わかりやすい資料」だけでは、人によって判断が変わります。そこで、見て確かめられる条件にします。
たとえば、告知文なら次のように考えます。
対象者が冒頭でわかる。日時と参加費が承認済み資料に一致する。申込方法が書かれている。説明のない専門用語がない。根拠のない実績を載せていない。
この状態なら、AIが文章を提出した後に、どこまでできたかを確認できます。
ここで大切なのは、事業の目標と、納品物の合格条件を分けることです。
「イベントの参加者を増やす」は目標です。しかし、文章を作った時点で、参加者が増えたとは確認できません。
「対象者、参加する利点、日時、申込先が伝わる」は、文章の段階で確かめられます。その後、実際の申込数を見て改善します。
目標を忘れず、今の工程で確認できることを決める。評価を設計する公式ガイドでも、成功条件を明確にし、仕事に合った確認方法を用意することが重視されています。
「いい感じにできた」という感想だけで、完成にしないための準備です。
4．資料は、たくさん渡すより「どれを使うか」を決める
告知文を作るAIに、過去三年分の案内、古い料金表、新しい料金表、会議メモをまとめて渡したとします。
資料が増えても、「今回の正しい参加費はどれか」がわからなければ困ります。
そこで、情報を三つに分ける設計にします。
まず、今回の事実を確認する資料。次に、文章やデザインの参考にする資料。そして、古い資料や未確定のメモです。
「開催概要は今回の確定情報。去年の告知は文体だけを参考にする。会議メモの案は、決定事項として扱わない」と書けば、使い道がはっきりします。
これが、コンテキスト設計の具体例です。情報を渡すだけでなく、何のために参照するのかまで整えます。Anthropicも、必要な情報を選び、作業中に管理することをコンテキスト・エンジニアリングとして説明しています。
資料同士が食い違う場合の扱いも決めます。
新しい日付だから必ず正しい、とは限りません。公開前の案かもしれないからです。「承認済みの開催概要を優先し、それでも矛盾が残る場合は未確定として報告する」としておきます。
また、「資料にないことを補ってよい範囲」を分けましょう。
見出しの表現は工夫してよい。しかし、参加費、開催場所、人数、実績は作らない。こう決めれば、創作してほしい部分と、正確さを守りたい部分を区別できます。
資料を増やす前に、資料の役割を決める。ここから始めると、依頼文も整理しやすくなります。
5．「できること」と「やってよいこと」は別にする
次に、AIが使う道具を考えます。
最新情報を調べるなら検索。数字を集計するなら表計算や計算を実行する仕組み。サイトを確かめるなら、ウェブページを見る道具であるブラウザーの操作。画像を作るなら画像生成の道具が必要です。
文章で「調べて」「確認して」と頼むことと、その操作を実行できることは同じではありません。Claude Codeの公式説明でも、モデルの判断と、実際の操作を行うツールは分けられています。
MCPという言葉を見かけることもあるでしょう。これは、AIアプリと外部のデータや道具をつなぐための共通の決まりです。簡単にいえば、接続方法をそろえる仕組みです。ハーネス全体ではなく、その一部に使えるものです。
そして、つながった道具を無制限に使わせないようにします。
SNSの下書きを作ることと、実際に投稿すること。売上の一覧を読むことと、元データを書き換えること。この二つは、別々に許可を考えます。
この記事の実務例では、読む、下書きを作る、試作用のコピーを直すところまでを任せ、公開、送信、購入、削除には人の確認を入れる設計にします。
さらに、「削除しないで」という文章だけに頼らず、利用環境の権限設定や承認機能でも制限します。Claude Codeの資料でも、指示ファイルは強制設定ではないと説明されています。
顧客情報や社内資料についても、「手元にあるから全部渡す」ではなく、そのAI環境で扱うことが許可されたものだけを使う設計にします。
お願いとしてのルールと、操作を制限する仕組みを重ねる。
これも、ハーネスの大事な仕事です。
6．ハーネスの中心は「作る→確かめる→直す」
ループとは、同じ流れを繰り返すことです。
ハーネスで使うループは、文章を何度も書き直すだけのものではありません。作った結果を確かめ、その結果に応じて次の作業を変えます。
基本形は、\\「作る→確かめる→問題のある部分を直す→もう一度確かめる」\\です。Claude Codeの公式資料も、情報収集、行動、結果の検証を繰り返す流れを説明しています。
たとえば、申込ページのボタンが動かないとします。
「もう一度、丁寧に作って」と頼むだけでは、何が失敗しているのか曖昧です。
代わりに、試作用のページでボタンを押す。遷移しないことを確認する。設定されたリンク先を調べる。間違っている箇所を直す。そして、もう一度押す。
確認結果が、次の作業を決めています。
このとき、背景色や見出しまで作り直す必要はありません。すでに合格している部分は維持し、失敗している部分を中心に直します。ただし、修正の影響がありそうな周辺も再確認します。
もう一つ必要なのが、止まる条件です。
「完璧になるまで続ける」では、終わりを判断できません。そこで、最初の運用例として「修正は最大三巡。同じ問題が二巡続いたら、原因と不足情報を報告して止める」と決めます。
この回数は公式の最適値ではありません。仕事の大きさや費用に合わせて変えるための、最初の設定例です。
途中で止めることは、失敗をごまかすことではありません。
必要な権限がない。元資料が矛盾している。試しても原因が絞れない。そんなときは、人の判断が必要だとわかる形で止めます。
大事なのは、繰り返した回数ではなく、確認によって何がわかり、何を変えたかです。
7．AIの「確認しました」を、何で確かめるのか
「問題ありません」「すべて確認しました」。
そう書いてあっても、何をどう確認したのかがわからなければ、判断材料は足りません。
そこで、確認方法を内容に合わせて分けます。Anthropicの評価資料でも、プログラムによる確認、AIによる評価、人による評価を使い分けることが説明されています。
たとえば、金額や文字数は、計算や文字の数え上げで確認します。日時や実績は、元の資料と照らし合わせます。ボタンは実際に押して確かめます。
一方、「読みたくなるか」「説明がくどくないか」は、機械的な一致だけでは判断しきれません。AIのレビューを参考にしつつ、読者の立場で人も見ます。
ここでは、完成報告を次のように変える設計にします。
「すべて確認しました」ではなく、「日時は開催概要と一致。申込先は指定URLと一致。ただし、ログイン後の申込完了画面は未確認」と報告させます。
これなら、どこまで任せられ、どこを人が確認すべきかがわかります。
出典がついている文章も、URLが存在するだけで合格にはしません。そのページに、その主張を支える内容があるかを見ます。
確認できたこと、確認できなかったこと、推測したことを混ぜない。
確認の仕組みを増やしても、すべての誤りを必ず発見できるわけではありません。だからこそ、確認範囲を具体的に残す意味があります。AIによる評価にも限界があり、人の判断との照合が必要です。
8．AGENTS.md、CLAUDE.md、Skillsは何をするものか
ここで、よく見かけるファイル名を整理しましょう。
AGENTS.mdとCLAUDE.mdは「繰り返し使う仕事の約束」
Codexでは、AGENTS.mdというファイルに、プロジェクトの指示を書けます。Claude Codeでは、CLAUDE.mdが継続的な指示を与えるために使われます。どちらも、対応するアプリが読み込む仕組みを持っています。
たとえば、「文章はですます調」「顧客の実績を推測で追加しない」「元資料を上書きしない」「未確認の部分は明記する」といった約束です。
毎回の依頼文に同じ説明を入れる代わりに、繰り返し参照できる場所へまとめます。
ただし、今月のイベント日時まで、すべて共通ルールに入れる必要はありません。それは今回の案件資料に書く内容です。
共通ルールには、繰り返し使う約束。案件資料には、その仕事だけの条件。進捗メモには、今どこまで終わったか。このように役割を分ける設計にします。
Skillsは「特定の仕事をするときに使う手順セット」
Skillsは、ある種類の作業を進めるための手順や参考資料などをまとめたものです。OpenAIの公式資料では、必要になったときに詳しい指示を読み込む仕組みが説明されています。
たとえば、「議事録を整理する手順」「商品紹介文を作る手順」「画像を制作して確認する手順」を別々に用意します。
議事録を作るときは、発言を要約し、決定事項を分け、担当者と期限を確認する。画像を作るときは、使用場所、縦横比、必要な文字、参考の雰囲気を確認する。
同じAIでも、仕事ごとの手順を取り出して使う形です。
ファイルを増やせば強くなるわけではない
OpenAIはハーネス設計の実践記事で、巨大なAGENTS.mdにすべてを詰め込む方法の問題を説明し、必要な情報へ案内する目次のように使ったと報告しています。
この発想を日常業務に取り入れるなら、「必ず読む短いルール」と「必要なときに読む詳しい手順」に分けます。
なお、普通のチャット欄にファイル名を書くだけで、パソコン上のファイルが自動的に読まれるわけではありません。利用するアプリの読み込み方法に従って配置するか、資料として渡す必要があります。
9．AstraとFableは「作る係」と「確かめる係」に分けられる
二つのAIを使うなら、役割を分けた設計が考えられます。
たとえば、Astraが記事を作り、Fableが資料との不一致を探す。あるいはFableがページを作り、Astraが仕様に沿っているか確認する。
ただし、「Astraは論理担当、Fableは感性担当」と決めつける必要はありません。自分の仕事で試して、修正の少なかった組み合わせを選びます。
作成と評価を分ける方法自体は、Anthropicもワークフローの一つとして紹介しています。評価基準が明確で、修正による改善を確認できる仕事に向くと説明されています。
大切なのは、確認役に完成品だけを渡さないことです。
文章だけを渡して「間違いはある？」と聞いても、本来の依頼がわかりません。対象読者、合格条件、根拠資料、変えてはいけない内容も一緒に渡します。
確認役には、こんな頼み方をします。
「依頼条件への違反、資料との不一致、確認不足を分けて指摘してください。好みの違いは、必須修正と分けてください。問題がない箇所を無理に直す必要はありません。」
作成役は、その指摘をそのまま全部採用するのではなく、元資料を確かめて必要な修正を行います。
二つのAIが同じ答えを出しても、それだけでは事実の証明になりません。同じ誤った資料を読んでいれば、同じ方向に間違える可能性を排除できないからです。
そして、AstraのチャットとFableのチャットが、何も設定せず自動で情報を共有する前提にはしません。まずは人が必要な内容を渡す運用で十分です。
片方のAIで下書きを作り、人が確認するところから始めても構いません。AstraとFableの両方を使うことは必須ではありません。
二つ使う場合も、確認の視点を分けるために使います。
10．実務ではどう変わる？ 三つの設計例
ここからは、仕事に置き換えてみましょう。以下は実測結果ではなく、ここまでの考え方を使った運用例です。
例① SNSの告知文を作る
依頼は「初心者向けセミナーの告知文を作る」です。
最初に、承認済みの開催概要、読んでほしい人、申込先、過去の文章を渡します。過去の文章は文体の参考であり、今年の日時や価格の根拠にはしません。
作成役は、参加することで何を持ち帰れるかを中心に下書きを作ります。確認役は、日付、金額、対象者、申込方法を照合します。
たとえば、下書きに「受講すれば毎月十万円稼げます」と書かれていて、資料に根拠がなければ削除します。代わりに、実際に扱う作業や成果物を具体的に説明します。
一方、申込先が本文から抜けていたなら、足すべきなのは申込先です。冒頭の表現まで全部変える必要はありません。
修正後に、必要な情報がそろっているかを確認します。公開は承認後です。
公開後は、閲覧数だけでなく申込につながったかを見ます。ただし、反応の差を文章だけの効果と即断せず、投稿時間や届けた相手の違いも考慮します。
「投稿を作った」で終わらず、内容の確認と公開後の見直しを分けて設計します。
例② 売上の一覧をまとめる
依頼は「今月の売上を集計する」です。
最初に決めるのは、集計の意味です。売れた日で数えるのか、入金日で数えるのか。返金はどう扱うのか。税込みと税抜きのどちらなのか。
ここが決まっていなければ、足し算が正しくても、知りたい数字にはなりません。
作業用のコピーを使い、対象期間を絞り、計算を実行します。空欄や重複の疑いがあれば、勝手に埋めたり消したりせず、確認対象として分けます。
最後に、合計額だけでなく、集計した件数、対象外にした行、その理由を残します。
たとえば「合計は八十万円です」だけではなく、「対象期間の四十件を集計。日付が空欄の二件は保留」とわかる形にします。数字は説明用の仮の例です。
AIには列の意味の整理や確認事項の抽出を任せ、計算は表計算などで実行し、人が一部の明細と集計ルールを照合します。
この例の目的は税務判断の自動化ではなく、どのデータをどう数えたかが追える集計です。
例③ 商品紹介ページを作る
依頼は「商品紹介ページを作る」です。LPという言葉を使う場合は、申込や購入などにつなげるためのページを指します。
まず、対象者、商品の内容、価格、画像、申込先、載せない表現を決めます。
次に、見た目の前に必要な機能を確認します。申込ボタンが指定先につながる。スマートフォンで文字が読める。入力フォームがある場合は、空欄や入力ミスを適切に扱う。
作成後は、試作用の環境でページを開いて確かめます。スクリーンショットで表示を確認し、ボタンを操作して移動先を見ます。フォームは許可されたテスト方法で確認し、実際の注文や顧客への送信を勝手に発生させません。
見た目だけ整っていても、申込ができなければ合格にはしません。反対に、動いていても価格が間違っていれば修正します。
Anthropicの長時間作業に関する実験でも、コードを変更しただけで完了扱いにする問題が報告され、ブラウザーで利用者の操作を確かめる手順が取り入れられています。
公開前に人が最終確認し、元の状態に戻せるようにしておきます。
11．最初の一件に使える、共通の指示文
いきなり複雑な仕組みを組む必要はありません。まずは一つの仕事で、目的と確認方法をそろえてみましょう。
次の指示文は、そのためのたたき台です。角括弧の中を書き換えて使います。
次の仕事を、作成・確認・修正を分けて進めてください。
【仕事】
［何を作るか、何を整理するか］
【目的と使う人】
［誰が、何のために使うか］
【合格条件】
［完成時に、具体的に確かめられる条件］
【使う資料】
［資料名や、許可する参照先］
今回の事実を確認する資料と、表現だけを参考にする資料を区別してください。
資料同士に矛盾がある場合は、勝手に一つを正しいと決めないでください。
【変えてはいけないこと】
［価格、日時、固有名詞、承認済みの内容など］
【作業できる範囲】
［下書きの作成、指定フォルダ内の編集など］
公開、送信、購入、削除、権限変更は、明示的な承認前に実行しないでください。
【進め方】
まず、依頼内容、資料、利用できる道具を確認してください。
重要な不足があれば、その影響を説明してください。
不足に関係なく進められる部分は進めて構いません。
最初の成果物を作ったら、合格条件ごとに確認してください。
事実は元資料、数字は計算、動作は許可されたテストで確認してください。
確認に必要な道具や権限がない場合は、未確認としてください。
不合格の箇所を中心に修正し、関係する部分を再確認してください。
合格条件そのものを緩めて、合格にしないでください。
修正は最大三巡です。同じ問題が二巡続く場合は、
試した内容、残る問題、必要な判断を報告して止めてください。
【最後の報告】
成果物、確認できた項目、その根拠となる資料やテスト結果、
未確認の項目、人が判断すべき点を分けて示してください。
この指示文だけで、検索、ブラウザー操作、外部サービスへの接続が追加されるわけではありません。使える環境で実行し、できない確認は人が担当します。
また、公開や削除の制限は、文章に書くことに加えて、アプリ側の権限や承認設定でも守る必要があります。
「何でも自動化する指示文」ではなく、できることと確認の範囲を明らかにする依頼書として使ってください。
12．長い仕事は「続きがわかるメモ」を残す
記事を何本も作る、サイトを数日にわたって直す。そうした仕事では、今どこまで終わったかも管理します。
会話を最初から読み直すだけに頼らず、目的、決定事項、未完了の作業、確認結果、次の一手をまとめます。
Anthropicが2025年に公開した長時間作業の実験では、最初に環境を整える役と、少しずつ進める役を分け、進捗ファイルや変更履歴で続きを引き継ぐ方法が紹介されています。
日常業務なら、次のようなメモで始められます。
「目的は商品紹介ページの完成。本文と価格は承認済み。スマートフォン表示は確認済み。申込ボタンの遷移は未確認。次はリンク先を確認する。承認済み本文と価格は変更しない。」
「サイト制作を進めました」より、次の作業がはっきりします。
資料の場所や確認した版も残します。「最新版を見た」ではなく、どのファイルを見たかを特定できる形にしましょう。
ただし、メモも間違う可能性があります。次の担当は、重要な完了事項を成果物や確認結果と照らし合わせます。
引き継ぎは、記憶が完璧であることを期待する代わりに、続きから始められる材料を残す作業です。
13．仕組みを大きくする前に、避けたい失敗
一つ目は、すべての仕事に大がかりなループを使うことです。
一文の言い換えに、調査役、執筆役、確認役を毎回そろえる必要はありません。Anthropicも、必要になるまで複雑さを増やさず、できるだけ単純な解決方法から始めることを勧めています。
二つ目は、間違うたびにルールを追加し続けることです。
「短くする」と「すべて詳しく説明する」が同じ場面でぶつかれば、判断に困ります。追加する前に、古いルールを削除できないか、適用する仕事を分けられないかを見直します。
三つ目は、外部の文章を、そのまま命令として扱うことです。
読み込んだページや資料に、依頼と無関係な操作を促す文章が混ざることがあります。こうした外部データを通じてAIの行動を変えようとする攻撃を、プロンプトインジェクションと呼びます。
対策は、「気をつけて」と伝えるだけではありません。外部資料は参照する情報として扱い、必要な権限だけを与え、外への送信や重要な変更に承認を入れます。情報の受け渡し方を限定することも含め、複数の対策を組み合わせます。それでも危険を完全にはなくせません。
ハーネスは、できることを増やすだけでなく、任せない範囲を決める仕組みでもあります。
14．うまくなったかは「自分の仕事」で確かめる
最後に、ハーネスを入れた効果を確認します。
見たいのは、AIが長く作業したかではありません。条件を満たした成果物が増えたか。人の修正が減ったか。未確認事項が見えるようになったか。そして、費用や待ち時間が見合っているかです。
たとえば、よく頼む告知文を数件選び、従来の依頼文と、新しい進め方を比べます。資料、合格条件、使える道具をそろえ、人が直した箇所と確認にかかった手間を記録します。
AIの出力には揺れがあるため、一回の成功だけで結論を出さないようにします。OpenAIも、実際の用途に合った評価と、継続的な確認を重視しています。
価格の間違いが減っても、確認作業が大幅に増えているなら、別の直し方を考えます。文章の変更で使いやすくなった代わりに、以前は守れていた条件を落としていないかも見ます。
モデルを更新したときも同じです。以前必要だった細かな指示が、今も必要とは限りません。今の仕事で必要なものだけを残します。
最初に整えるのは、会社全体の巨大な仕組みではありません。よく頼む仕事を一つ選び、その仕事の完成条件と確認方法を決めるところからです。
Astraに任せるか、Fableに任せるか。その選択と並んで、「どう任せるか」を考えます。
何を作るのか。何を根拠にするのか。どの道具を使うのか。できたことをどう確かめるのか。直らなければ、どこで人に戻すのか。
この五つに答えられるようになると、AIへの依頼は、単なるお願いから、確かめながら進められる仕事に変わります。
ハーネス理論とは、AIに仕事を任せるときに、完成までの進め方と、完成したと判断する根拠を一緒に用意する考え方です。
