AIに私らしい文章生成を。指示ではなく、任せる環境を整えた話（ハーネスライティング）

AIに書かせた原稿を読み返すと、言っていることは合っているのに、自分の文章ではないため、結局は最初から書き直す。それならAIに頼む意味がないと思っていませんか。

新しい人が入る日に、机も名刺もマニュアルも用意せず「しっかりやってね」とだけ言う上司はいません。ところが私は、AIにはこれをやっていました。頼み方ばかり磨いて、仕事場を作っていなかったのです。

今回、私はAIへ渡すものを作り直し、AIがタスクを実行する環境を整備しました。毎回まとめて渡していた605行を骨格・執筆・レビューの3つの束に分けたところ、低コストのAIモデル（DeepSeek）で書かせても作り直しは3回から1回になりました。

直らなかったのは指示（プロンプト）ではなく、渡す環境の問題だったのです。今回はそんなAIの環境づくり、「ハーネスライティング」についてお話していきます。

この記事の要点

• 指示を足しても直らない、AIの文章
• 渡すファイル・ルール・検査を先に置く、環境づくり
• 最初の1つは、自分で守るルールを5つまで書いたファイル1枚

AI生成の文章修正は、指示ではなく渡す環境で減った

AI生成の文章は、指示を増やしても直りませんでしたが、渡すものを整えたときに直りました。

文体はこう、ここは禁止、あれは禁止。一言ずつAIへの指示を足していっても、直したそばから崩れます。同じような修正を何度も頼み、最後は高性能なモデルに頼る。この悪循環の原因は、指示の足りなさではなく、AIが働く環境にありました。

ルールが多くなると、AIが指示を守れなくなるのは、以下の理由が考えられます。

• ルールが多いと、どの優先順位が高いのかAIが迷うため
• 長文の中間部分にある指示を見落としやすいため（Lost in the Middle現象）
• AIが一度に記憶・処理できるトークン数（文字数の単位）の上限に近い、または超えているため
• ルール同士に矛盾が発生しているため
• ルールの解釈が、人間とAIに乖離が発生しているため

そして、環境を整え直してから、執筆には低コストのモデル（DeepSeek）を、判断が必要な工程には高性能なモデル（Claude）を使うようになりました。原稿1本の作り直しは、3回から1回に減っています。この記事は、その環境をどう作ったかの記録です。

指示を重ねるほど、AIの文章は自分の文章から遠ざかった

量産の時代は終わり、AIっぽさが問題になった

これまで機械が文章を書くことはできましたが、決まったルールベースの中だけでした。テンプレートに値を流し込むような文章を量産して、サイトの資産を積むことに一定の価値や効果がある時代でした。

AIの登場で、この前提は変わりました。文章を生み出すコストは圧倒的に下がり、表現も柔軟に選べる。すると次の課題が浮かび上がります。大量の文章が作れる世界で、「AIっぽい文章」はネガティブな印象を持たれ、かといって文章を整えるためだけに自分の時間を使いたくもないということです。

一言ずつ指示を足しても、直らなかった

私は最初、指示（プロンプト）で何とかしようとしました。「文体は◯◯して」「〜は禁止」「ここは箇条書きで」と。ところが、指示を足せば足すほど、モデルは全部を拾えなくなります。一度に処理できる量には限りがあり、指示が長くなるほどルールの情報が薄れていきます。作業机が小さいと、最初に置いた資料が机の外に落ちたり、埋もれたりしてしまうのと同じです。

3回指示しても直らないときは、結局、高性能なモデルであるClaude Opusに書き直させていました。費用はかさむし、直してもらった文章も、どこか自分の言葉ではありませんでした。

欲しかったのは、自分の生の言葉を文章にするゴーストライター

AIが書いた文章には自分らしさがなく、修正しても修正しきれない。それなら、自分の生の言葉を受け取って文章にしてくれる存在がほしい。そう考えて、ハーネスライティングの構築に取り組みました。

書籍の執筆では、ライターがインタビューをして文章にまとめるケースがあります。同じことをAIにやらせたい。そのために、AIへの指示ではなくAIが働く環境を変えました。

AIに任せる環境をひとそろい用意する、今回のやり方を「ハーネスライティング」と呼んでいます。ハーネスライティングがあれば、誰でも自分のゴーストライターを持てる。この考えを軸に、AIが文章を書くための仕事場を作っています。

任せる前に仕事場を整える。ハーネスライティングという考え方

新しい社員を迎えるとき、机も名刺もマニュアルも用意せず「しっかりやってね」と言う人はいません。AIも同じで、口頭の頼み方（指示）を磨くより、仕事場を整えるほうが先です。この仕事場がハーネスで、AIに安全に仕事を任せるための仕組み一式で、渡すファイル・ルール・機械検査・工程の束をまとめたものです。

ハーネスという考え方自体は、エンジニアの世界にあります。AIに仕事を任せる枠組みを整える「ハーネスエンジニアリング」です。これを文章執筆に応用したのが、ハーネスライティング。先ほどのゴーストライター願望に、この技術の考え方が組み合わさりました。

もうひとつ、執筆に取り入れた考え方があります。TDD（テスト駆動開発）です。

ハーネスだけだと、ルールは増え続けます。ああしてほしい、これは駄目、これとこれならこちらのほうが良い。ルールが増えれば何が起きるかはすでに経験済みです。だから完成条件と検査を先に置き、「指示を磨く」ではなく「環境を作る」に切り替えました。

環境側の具体は次のとおりです。

• 声の見本を3〜5件渡す
• 日本語のルールを1ファイルにする
• 機械検査（禁止表現を機械で拾う仕組み）で不合格ゼロを目指す
• 完成条件を先に決める
• 渡すものを工程ごとにまとめる

どれも、指示の上手さではなく、用意する側の仕事です。

AIに渡すものを、骨格・執筆・レビューの束に分けた

一括で渡すのをやめた

渡す環境のいちばんの変更は、AIにルールを一括で渡していたのをやめたことです。改修前の私は、毎回まとめて605行・19,711字をAIに渡していました。

書かせる文章を1本の原稿約6,000字とすると、入力が出力の3.3倍。ルールを足すほど守れないルールが生まれる、そのままの構造でした。

そこで渡すものを、骨格・執筆・レビューの3つに分け、工程ごとに使用するAIモデルも切り替えています。例えば、判断が必要な工程（骨格とレビュー）には高性能なモデル、量が出る工程（執筆）には低コストなモデルです。執筆時に渡すルールは3,500字前後と、以前の5分の1になりました。

私が実装しているハーネスライティングの構成例

1. AIモデルへ渡すファイル（工程ごとに渡すファイルを決めている）

ファイル名	役割	記載されているもの
voice-bank.md（examples内）	声の再現	私が作成した確定文の抜粋を用途別タグ付きで格納（リード・前提の転換・数字の出し方・失敗の書き方・例え・締め・要点・短文・作ったものの見せ方）。束Bでは該当タグの見本3〜5件だけを渡す
nabe.md	声・人格の索引	「なべ」とは誰かを記載（ZOO代表・ライター役・起業7期目）、実文からは読み取れない決め事（一人称「私」・敬体8割常体2割・例えは難所に絞る・一次体験を核に）。全文はモデルに渡さない
nihongo.md	日本語ルールの参照先	「禁止 → これを使う」形式で記載。推奨（言葉の選び・数字・秘匿・readmore・装飾・見出し）と学習時の追加手順も。
brand-concept.md	読者像（誰のための文章か）	確定コピー、存在理由、読者定義を記載。束A・束Cで渡す
format.md	文章の型・形式	冒頭書式、記事構造、タイトル、リード、要点、本文の運び、芯の置き方、画像、見出し、締め、提出前チェックリストなどを記載。束A/B/Cで該当節だけを渡す
markdown-map.md	マークダウン↔HTMLの変換仕様	書式ごとの生成HTML対応表と規則

 

2. 判断の枠組み（束Cで使う）

ファイル名	役割	記載されているもの
3-layer-review.md	レビューの正本（3層構造）	第1層 一般論（機械が検査）／第2層 ZOOらしさ（正本から降りる一貫性）／第3層 なべ独自。各層の項目・破れの実例・レビュー手順・完成条件の根拠出しルール

 

3. 学習ループの層（モデルには渡さない）

ファイル名	役割	記載されているもの
feedback/	原稿修正の差分記録（生データ）	修正した原稿と完成原稿を保存。無編集段落率・編集量・実作業時間・直した理由の内訳
learnings/	ルール候補の管理	原稿作成時に出てきた次回ルールに反映する候補。承認待ち/承認/却下で管理
x-posts/	X投稿の生記録	日次ファイルに X投稿を原文写経。nabe.md の更新材料

 

4. 機械検査・運用スクリプト（scripts/）

ファイル名	役割
fix_draft.py	HARD禁止のうち決定的に置換できるもの（表記揺れ・記号・絵文字など）を後処理で直す。モデルには渡さず、check の前に通す
check_draft.py	第1層（一般論）の機械検査。FAIL 0 を確認、WARN は目視。実行末尾に第2・3層の人手レビュー項目も出力
collect_diff.py	差分を feedback/ へ記録
snapshot_draft.py	版確定時に原稿を複製
refresh_draft.py	原稿の直編集後の一括反映
render_preview.py / render_preview_png.py	draft.md → プレビューHTML
publish_article.py	WordPress 下書き保存（–dry-run → 承認 → 本番。公開は人間のみ）
md2html.py	マークダウン→WP互換HTMLの単一変換器
doc_check.py	運用文書の種別検査

 

5. ハーネスライティングの隣接ファイル

ファイル名	役割
workflows.md	記事の判定の参照元
direction.md	運用の軸
zoo-identity.md	ZOO株式会社としての自己定義

続きを開く

使っている道具と実際のワークフロー

今回、この記事を制作する際に使用したハーネスライティングの各道具と、役割分担は次のとおりです。

基盤となるAIエージェント（Hermes Agent）がハーネスの各ファイルを読み込んで文章を作成し、骨格作りとレビューは高性能なモデル（Claude）で行っています。

AIに任せている仕事は、量が出る執筆と、判断の材料を作る骨格・レビューです。機械検査はAIではなくスクリプト（簡易的なプログラム）が行います。

「何を作るか」「どこまで良しとするか」の判断と承認は、私が持っています。

原稿1本の工程で出た修正は、私がハーネス側へ書き戻して次の原稿に積み上げることで、次の原稿作成に活かされるようになっています。

キーワードではなく、声で入れる

ハーネスを作って分かったことは、生の声をどれだけAIに入れられるかが、AIが作った文章の質を決めるということです。

AIに文章生成だけをさせると、一般論やWeb上にある情報、そのAIが学習しているデータを元に生成されます。これでは意味がありません。どれだけオリジナリティのある文章にできるかは、素材（リアルな声）で決まります。

料理に例えるなら、生の声は「食材」です。自分の料理の味をコントロールしたいなら、下処理された素材より、そのままの素材のほうが良いでしょう。生の声は、自分だけ、自社だけが持っている貴重な情報なのです。

また、キーボードで打っていると、言葉は打ちやすい形に下処理されていきますが、話したときは、考えて、思っている形がそのまま言葉になって出てきます。私は音声入力にはCodexアプリを使って話しています。フィラーを取り除き、文章に整えてくれるので便利です。

生の情報は、少ないより多いほうがいい。だからキーワードではなく、音声で話してAIに入れるようにしています。

ハーネスをAIに作らせて、ファイルそのものが汚れていた

ここまで上手くいった話ばかり書きましたが、最初は失敗しています。ハーネスを作ればそれなりに良くなると思い、1週間ほどかけて構築し、この記事の一発目を制作しました。結果は、一部ルールは守れましたが、大部分は機能せず、文章は散々なものでした。

何度調整しても原稿は良くならず、自分らしい言葉とは程遠く、AIっぽく、文章も崩れていました。1週間かけたものが報われず、挫折しかけました。

失敗した理由は2つあると思っています。1つ目は、ルールをAIに与えすぎたこと。指示が肥大し、すべてのルールを守れなくなっていました。

2つ目は、もっと根深く、ハーネスをAIにすべて作らせていたことでした。

高性能なClaudeのモデルで行っていましたが、ファイルそのものにAIの乱れや汚染が入り込み、純度の高い情報だけのハーネスにはなっていなかったのです。

気づいたきっかけは、一度時間をとって中身をじっくり確認したことでした。正本であるはずのファイルに「2026年8月15日に改定：〇〇を削除しました」のような、ルールと関係のない履歴が残っていたり、私の意図とは違う形でルールとして書かれていたりしました。

ハーネスの材料をAIに作らせると、AIの癖や誤りがそのままファイルに混ざる。汚れた材料で作った環境は、いくら指示を整えても、その汚れを文章に写すだけでした。

立て直しでは、いったんすべてのファイルを白紙に戻し、Claudeには骨格だけを作らせ、中身は私が手で書き直して、ファイルの純度を上げました。

進んでいた記事は一度捨てて、最初から作り直しました。それがこの記事です。「AIに作らせる」「人間が確認する」の線引きは、ここで実際に引き直しました。

改修の効果は、原稿の見栄えではなく直しの回数に出た

修正の大きさを、2つに分けて数えています。原稿全体の半分以上の段落が入れ替わるほどの修正を「作り直し」、半分以上がそのまま残る修正を「仕上げ」と呼んでいます。

また、「最後の1回転」は、最後の修正のときに1文字も触られなかった段落の割合です。「無編集段落率」は、初稿から最終稿までの間に一度も直されなかった段落の割合です。最後の1回転も無編集段落率も「手を付けずに残った段落の割合」ですが、数える範囲が違います。

改修の効果は、原稿の見た目ではなく直しの回数に出ました。作り直しが3回から1回になり、最後の1回転は96.1%。最終の直しで、ほぼ触らずに確定できるようになりました。2本目の最後の1回転が5.8%と低いのは、公開直前まで全面的に書き直していたためです。

しかも、これを低コストのモデルであるDeepSeekで実現できており、以前のように直らないたびに高性能なモデルへ頼むことはなくなりました。

また、1本原稿を直すたびにその直しをハーネスに書き戻していて、原稿が積み上がるほど次の原稿に効いてくる実感があります。

いちばんの気づきは、環境ができてから、時間の使い方が変わったことです。自分のリアルな声を出すことに、いちばん時間をかけるようになりました。

今は「音声で生の情報をたくさん入れる → それを読める文章にAIが整形する → 整形したものを生情報として原稿作成時にAIに入れる」の順で回しています。声や表現はそのままに、無駄な言葉だけを削って純度を上げています。

環境を作る時間がない人と、AIに任せきりにしたい人へ

環境を作る時間がない

自分が仕事で使っている文書を1つ選び、「これだけは守る」を5つまで書き出して、ファイル1つに置いてみてください。

例えば、お客様へ送るメールを選んだら、以下のようなルールを置きます。

• です・ますで書く
• 1通に頼みごとは1つまで
• 読みやすいように箇条書き、改行を使う
• メール文に太字、斜体、下線の書式は使わない
• 「お世話になっております。ZOO株式会社の渡邊です。」と必ず冒頭に入れる

これだけで動けます。全部を先に作ろうとしたのが、私の最初の失敗でした。AI生成の文章を直したときに1つずつルールやフローを足していけばいいので、まずは小さくスタートするのがおすすめです。

環境ができれば、全部任せられるのか

ハーネスができたからといって、AIに完全に任せることはできません。いちばん大事なのは自分のリアルな声を出すことで、それが無いと、ただのAIスロップ（AIが作り出した低品質なコンテンツ）になってしまいます。

環境は、人間の声を受け取る器です。器がどんなに良くても、中に入れる生の情報が無ければ、出てくるのはAIらしい無難な文章です。

このバランスの答えは、まだ出せていませんが、「リアルな声を出すことに時間を使う」と決めて回しているのが現状です。

最初のルールファイルを、ChatGPT・Claude・Gemini・Grokのどこに置くか

ここからは、あなたの番です。環境構築の最初のステップとして、自分で守るルールを5つまで書き出し、それをファイル1つに置いてみてください。

各AIには、プロジェクトごとに共通ルールを残す場所があります。そこに置けば、毎回の指示に書き足さなくても、出力に反映されます。

今回は、ChatGPT、Claude、Gemini、Grokの4つのサービスで紹介していきます。

どのサービスも、サイドバーから新規追加→名前を入力→共通ルールを入力、の順です。使っているAIの欄だけ読んで、1ファイル分のルールを置いてみてください。

※画面は2026年9月時点のもので、変わることがあります。

ChatGPTの場合

ChatGPTは、サイドバーから「プロジェクト」を新規追加し、名前を入れます。共通ルールは「プロジェクト設定」の「指示」欄に入力します。

Claudeの場合

Claudeは、サイドバーから「プロジェクト」を新規追加し、名前を入れます。ルールは「手順」欄に入力します。

Geminiの場合

Geminiは「Gem」を作り、名前を入れます。ルールは「カスタム指示」欄に入力します。

Grokの場合

Grokも「プロジェクト」を新規追加し、名前を入れます。ルールは「指示」欄に入力します。

一度置いたルールファイルは、手入れをやめると崩れていく

環境は、置いたあとに手入れが必要です。

一度作っても完成にはならず、常に出力をチェックして、守れていないルールを直し続ける必要があります。そうしないと、クオリティは落ち、作ったものは崩れていきます。

これは、部下を持つことと似ています。部下に「このルールで、このフローで、ゴールはこれだから、これをやってください」と指示したとき、数日は順調でも、数週間放置するとクオリティが落ち、方向性が違うものが出てきます。私自身も、会社も、周りの環境も、刻一刻と変わるので、同じ指示や環境は使い続けられません。

自動化の指示や、品質・方向性・ルールを持った成果物を出す仕組みには、定期的な確認や調整、軌道修正・アップデートが必要です。ハーネスも例外ではない、というのが今の私の結論です。

この記事で作った土台は、任せるためのAIの仕事環境です。以前書いた「シフト表の転記をAIに渡した話」では作業の線引きを、「営業リストを作ってと頼む前にやるべき30分」では頼む前の設計を扱いました。今回は、その先にある「渡し方を支える環境」の話です。

まずは1ファイル。置いたら、出てきた文章を見ながら育てていってください。直したい箇所が、次のルールの種になります。あなたが最初に書き出す5つのルールは、何になりますか。

シェアする

Googleで探しやすくする

Author

なべ

テクノロジーは好きですが、そのものを作る側ではありません。かといって、新しい道具を集めて満足するほうでもない。

何か新しいものが出てきたとき、私が考えるのは「これで何ができるか」より「今のやり方このままでいいんだっけ」のほう。道具が増えるより、やり方ごと作り変えたり、無くしたりするほうが好きです。

AIが来て、人の考え方も、仕事の進め方も変わっています。その変わり方に興味があって自分の仕事で先に試しています。techtech.clubは、そのやってみた結果を置いておく場所です。

AI Support

• Hermes Agent

  ネタ調整 / ハーネスライティング実践 / 文章生成

• Claude

  構成作成 / 文章レビュー

関連記事

AIは効率化だけじゃない。請求書づくりで消えた負担

なべ with Hermes Agent, Claude Code freee Claude Cowork Gmail Googleカレンダー MCP 経理

AIに「営業リストを作って」と頼む前にやるべき30分

なべ with Hermes Agent, Claude Hermes Agent Claude Cowork AI導入 営業

シフト表を写真1枚でGoogleカレンダーへ。転記をAIに渡した

なべ with Hermes Agent, Claude, ChatGPT Gemini Googleカレンダー 情報整理

情報収集は集め方ではなく活かし方が重要。全部読むのをやめて「関所」で捨てるようにした話

なべ Claude Code Hermes Agent 情報収集