第4回：業務を言語化する力がAIの精度を決める — CLAUDE.mdライティング入門
シリーズ: コードなしで仕事が変わる AIエージェント設計ガイド（全7回）
前回は Gemini × Google Workspace を使って、すでに使っているツールの中でAIを動かす方法を紹介しました。今回は一段階踏み込みます。「どのAIを使うか」ではなく「AIにどう仕事を教えるか」という話です。
「AIに頼んでみたけど、なんかズレた回答が返ってきた」
この経験、一度はあると思います。で、だいたい次の行動はこうなります。「プロンプトを改善しよう」。もう少し丁寧に背景を書いて、もう少し具体的な指示を足して、何度か試行錯誤して……それでもやっぱり微妙で、「自分でやった方が早かった」という結論に至る。
でも、考えてみてください。あなたが新しいアシスタントを雇ったとして、初日から「いつもの感じで議事録まとめておいて」と言って、完璧なアウトプットが返ってくるでしょうか。
答えは当然ノーです。あなたの仕事のスタイル、クライアントの傾向、使っているフォーマット、避けたい表現——そういった情報を、ある程度まとまった形で伝えなければ、どんなに優秀なアシスタントでも機能しません。
AIも同じです。問題はプロンプトではなく、あなたの仕事をAIに伝えていないことにあります。
ハーネスエンジニアリングとは
「ハーネス」という言葉は馬の馬具から来ています。馬に手綱をつけて方向をコントロールするように、AIに対して制約・ルール・文脈を与えることで、意図した方向に動かす考え方です。エンジニアリングという言葉がついていますが、コードを書く話ではありません。
むしろ、コードが書けない人にこそ必要な考え方です。
エンジニアはコードで「この処理はこう動かせ」と明示できます。でも非エンジニアが普段やっている仕事（ライティング、提案書作成、顧客対応、デザインのフィードバックなど）は、そのほとんどが「なんとなく共有されているルール」で動いています。
「クライアント向けの文章はやわらかいトーンで」「提案書には必ず根拠を2つ以上」「NGワードは業界によって違う」。こういったことをチームの新人に一から教えるとき、どれだけの時間がかかるか考えてみてください。AIに教えるのも同じです。
そのルールを言語化してAIに渡すのが、ハーネスエンジニアリングの本質です。一度言語化してしまえば、あとはそのドキュメントを更新するだけでよくなります。
ツールとしてよく使われるのが「CLAUDE.md」というテキストファイルです。
CLAUDE.mdとは何か
CLAUDE.mdは、Claude（Anthropicが提供するAI）に対して「業務マニュアル」を渡すための仕組みです。テキストファイルを1つ作って、そこに仕事のルールを書く。それだけです。
技術的な説明をすると、Claude Codeと呼ばれるエージェント型ツールを使う際、プロジェクトのフォルダにCLAUDE.mdというファイルを置いておくと、Claude がそれを自動的に読み込んで以降のやり取りに反映させます。「毎回プロンプトで説明しなくていい」状態を作れるのが最大のメリットです。
ひとつ補足があります。CLAUDE.mdの自動読み込みはClaude Code（開発者向けのCLIツール）固有の機能です。ブラウザで使うclaude.aiでは、ファイルを置いても自動的には読み込まれません。ブラウザ版で同じ効果を得るには、Claude Projectsの「Custom Instructions（カスタム指示）」に同じ内容を貼り付けてください。第2回でClaude Projectsを紹介しましたが、今回学ぶ「業務マニュアルの書き方」はそのカスタム指示に書く内容の設計ガイドでもあります。Claude Codeを使っていない方は「カスタム指示に何を書くか」という視点で読み進めてください。
Claude Codeを使わなくても考え方は応用できます。ChatGPTの「カスタム指示」機能、Claudeの「プロジェクト設定」機能。これらは全て同じ思想です。「このAIセッションで私はこういう人間で、こういう仕事をしている」という情報をAIに渡すことで、毎回ゼロから説明しなくて済む状態を作る。ツールが何であれ、仕組みは同じです。
たとえばこんな使い方があります。
- ライターが「私の記事はです・ます調で書いてください。箇条書きより文章スタイルを優先します」と書いておく
- コンサルタントが「提案書はA4・2ページ以内。結論を先に書いて根拠を後にする形式」と指定しておく
- デザイナーが「UIコンポーネントはFigmaのデザインシステムに従う。フォントはNoto Sansのみ使用」と書いておく
一度書けば、以降のすべての依頼に自動的に適用されます。毎回説明する手間がなくなり、AIの出力がブレにくくなります。
フリーランスの方にとって特にメリットが大きいのは、クライアントごとにCLAUDE.mdを分けられる点です。「Aクライアント向けは柔らかいトーン、Bクライアント向けはフォーマル」といった切り替えが、ファイルを変えるだけで済みます。複数のクライアントを抱えているほど、この仕組みの価値は上がります。
書き方の5ステップ
「何を書けばいいかわからない」という方のために、実際に手を動かせる5ステップを用意しました。
Step 1：自分の仕事を箇条書きで書き出す
まず、AIに何をやってもらいたいかを書き出します。難しく考えず、普段やっている作業を羅列するだけです。
- クライアント向けのメール文を書いてほしい
- 会議の議事録を要約してほしい
- 提案書の構成案を出してほしい
- 競合調査の結果をまとめてほしい
この段階では完璧さは不要です。「なんとなくやってほしいこと」のリストが出ればOKです。
Step 2：「やってほしいこと」と「やってほしくないこと」を分ける
Step 1で書き出したリストを見ながら、制約や避けたいことを追記します。
## やってほしいこと
- メール文の下書きを作る（私が最終確認して送る）
- 会議メモから要点を3〜5行に要約する
## やってほしくないこと
- クライアント名を勝手に変えない
- 私が確認前にメールを送ることは絶対しない
- 敬語の過剰使用（「〜でございます」を多用しない）
「やってほしくないこと」は思いのほか多く出てきます。ここが一番AIの精度に効きます。
Step 3：アウトプットの形式を指定する
どんな形式で返してほしいか、具体的に書きます。
## アウトプット形式
- メール文: 件名と本文をセットで。本文は300字以内
- 要約: 箇条書き（3〜5点）。各点は1行で
- 提案書構成: 見出しレベルで出力。詳細は私が後から書く
「なんとなく返してもらえばいい」という感覚で使い始めると、後で「こんな形式じゃなかった」という摩擦が増えます。最初に形式を決めておくのは、一見手間に見えて結果的に時間の節約です。
Step 4：具体例を1つ添える
文章で説明しにくい場合は、例を1つ入れると格段に精度が上がります。
## 参考例
### 良いアウトプット例
「お世話になっております。先日お送りした資料についてご確認いただけますでしょうか。ご不明な点があればお気軽にお申し付けください。」
### 避けたいアウトプット例
「お世話になっております。平素は格別のご高配を賜り、厚く御礼申し上げます……（過剰な敬語が続く）」
「こういうの」という感覚は言語化しにくいですが、Before/Afterで示すと伝わります。
Step 5：試して修正する（完璧を目指さない）
最初のCLAUDE.mdは荒削りで問題ありません。実際に使ってみて「またこのパターンが出た」と気づいたときに、その都度修正します。
「一度書けば完成」という感覚で臨むと、少しズレたときに「やっぱりAIは使えない」と感じてしまいます。CLAUDE.mdは生きているドキュメントです。使いながら育てるものだと思ってください。
職種別テンプレート
実際の構成を参考にしてもらうため、3つの職種別テンプレートを用意しました。このまま使うのではなく、自分の仕事に合わせてカスタマイズする出発点として活用してください。
ライター向け CLAUDE.md
# ライター業務ルール
## 文体
- 実践ガイド・手順説明: です・ます調
- コラム・考察: だ・である調も可
- 同じ文末が3回以上連続しない
## 避けること
- 「〜の3つです」「〜の4点があります」等の列挙パターン（AIっぽく見える）
- 「重要なのは」「注目に値する」等の大げさな導入フレーズ
- 冒頭の事実羅列スタート（問いかけや違和感から始める）
## アウトプット形式
- 記事: H2・H3の見出し構成 + 各セクション300〜500字
- ドラフトには必ず「Sources」セクションを付ける（3〜6件）
- 画像プレースホルダーは `` 形式で本文中に挿入
## 禁止事項
- 校正前に公開しない
- ファクトチェックなしで数値・固有名詞を使わない
コンサルタント向け CLAUDE.md
# コンサル業務ルール
## 提案書の基本フォーマット
- 結論を冒頭に（BLUF: Bottom Line Up Front）
- 根拠は2〜4点に絞る（多すぎると読まれない）
- A4換算で2ページ以内を原則とする
## クライアント情報の扱い
- クライアント名はイニシャル（A社）で記述。実名は私が後で入れる
- 業界・フェーズ情報を必ず文脈として含める
- 「御社」「貴社」の使い分け: メール=御社、書面=貴社
## 避けること
- 根拠のない断言（「〜は確実に〜になります」等）
- 業界専門用語の多用（説明なしに使わない）
- 長い前置き（結論を後ろに持っていかない）
## アウトプット形式
- 提案書構成案: 見出しのみ（詳細は私が記述）
- メール下書き: 件名 + 本文 + 署名欄（署名は「[署名]」でプレースホルダー）
デザイナー向け CLAUDE.md
# デザイン業務ルール
## スタイルガイド
- カラーパレット: プライマリ #2563EB、セカンダリ #64748B、アクセント #F59E0B
- フォント: 見出し = Noto Sans Bold、本文 = Noto Sans Regular
- 余白: 8pxグリッドシステム（8の倍数で統一）
## 画像生成の制約
- フラットデザイン厳守（3D・グラデーション・写実的な画像は使わない）
- テキスト入り画像: タイトルは左寄せ、キーワードタグは下部に配置
- 生成後に alt テキストの案を一緒に出す
## フィードバックの書き方
- 「なんか違う」ではなく「コントラストが低い」「余白が足りない」等の具体表現
- 変更前の状態と変更後のゴールをセットで書く
## 避けること
- クライアントの確認前にデザインを確定させない
- ブランドガイドに書かれていないフォント・カラーの使用
Worply Mediaで実際に使っているCLAUDE.md（抜粋）
このメディア（Worply Media）の記事執筆ルールとして、実際に以下のような設定を使っています。全文ではなく、参考にしやすい部分を抜粋・簡略化して掲載します。
# ライター運用ルール（Worply Media）
## 文体
- ニュース・解説: だ・である調
- 実践ガイド（手順中心）: です・ます調
- 同じ文末パターンが3回以上連続しない
## AIっぽさ排除
- 3つセットの列挙を避ける（2つまたは4つ以上にする）
- 「Xではない、Yだ」構文は1記事に1回まで
- 「重要なのは」「特筆すべき」等の教科書的フレーズを使わない
- 冒頭を事実の羅列で始めない（問いかけ・意外な数字・エピソードから入る）
## 記事末尾の構成
- 関連記事セクション（2〜3本）
- Sourcesセクション（3〜6件）
- シリーズ案内
## 禁止事項
- 校正前に公開しない
- site/src/ 配下のソースコードを操作しない
「AIっぽさ排除」というセクションを設けているのは、AI生成文には出やすいパターンがあるからです。「AとBとCの3つです」「重要なのは〜」という書き方は、読めばわかりますが書き手が無意識になりがちです。こうしたルールを明示しておくと、出力のトーンが安定します。
よくある失敗
失敗1：書きすぎる
最初にCLAUDE.mdを作るとき、あれもこれもと書き込みたくなります。が、長すぎると重要な指示が埋もれて効かなくなります。最初は10〜15行程度で始めて、必要に応じて足していく方が機能します。
実際にWorply Mediaでも、最初のCLAUDE.mdは200行以上に膨らみました。運用してみると、後半に書いた指示がほとんど効いていないことに気づきました。今は最重要ルールだけを20行前後に絞り込んでいます。
失敗2：抽象的すぎる
「いい感じに書いてください」「プロらしく」「読みやすく」。こういった言葉は指示として機能しません。「文末を3回以上連続させない」「件名は15字以内」のように、判断基準が明確な表現にしてください。
「丁寧なトーンで」という指示が10人いれば10通りの解釈があります。AIも同様です。「〜でございます、の多用を避ける」のように具体的に書く方が、意図した通りに動きます。
失敗3：一度書いて放置する
実際に使い始めると「またズレた」という瞬間が来ます。そこで諦めず、その瞬間にCLAUDE.mdに1行追加する習慣をつけることが大切です。半年後には、あなたの仕事を本当によく知っているAIパートナーができあがっています。
逆に言えば、初期のCLAUDE.mdが完璧でなくても問題ありません。「完璧に書いてから使おう」と思うより、荒削りでも始めてしまう方が、結果的に精度の高いものができあがります。
CLAUDE.md導入前後で何が変わるか
導入前： 毎回「です・ます調で」「300字以内で」「箇条書きより文章で」と説明。AIの出力がバラつく。修正に時間がかかる。
導入後： 最初の依頼に説明は不要。AIが仕事のスタイルを「知っている」状態でスタートする。出力のブレが減り、修正コストが下がる。
この変化は、新しいツールの導入よりも地味で、実感するのに少し時間がかかります。でも一度感じると、「なぜ今まで毎回説明していたのか」と不思議に思えるくらい自然になります。
プロンプトを磨くより、業務を言語化することに時間を使う。それがハーネスエンジニアリングの本質です。
まとめ
今回の内容を整理します。
- AIの精度が低いのはAIの問題ではなく、業務のルールをAIに伝えられていないのが原因
- CLAUDE.mdはその「業務マニュアル」。テキストファイル1つで作れる
- 5ステップで作成できる（書き出し→分類→形式指定→例を添える→試して修正）
- 完璧を目指さず、使いながら育てるドキュメント
このシリーズで繰り返し言っていることがあります。AIを使いこなすのに、新しいツールは要らない。必要なのは「自分の仕事を言葉にする力」です。CLAUDE.mdを書く作業は、AIへの指示書を作ることと同時に、自分の仕事のプロセスを棚卸しする機会でもあります。「自分はどんな仕事をしていて、どんなアウトプットを出しているか」——これを言語化できた人が、AIをうまく使える人になります。
今日の一アクション: 今日、自分の仕事の手順を5行で書き出してみてください。「毎回AIに説明していること」があれば、それが最初のCLAUDE.mdになります。
次回は「IT部門を通さずにAIを使い倒す」という話をします。会社のデータを使えない、ツールの申請が通らない——そんな制約の中でも、個人でできることは思っている以上にあります。
Zennでエンジニア向け拡張版を公開しています
この記事の内容を、エンジニア向けに深掘りした拡張版をZennで公開しています。設計パターンの使い分け、.claude/rules/ の分割戦略、Cursor Rulesとの比較など、実装寄りの内容を追加しています。
シリーズ全7回
- 第1回：ChatGPTもClaudeも使っているのに、仕事が楽にならない理由
- 第2回：Claude Projectsで「仕事の分身」を作る
- 第3回：Gemini × Google Workspaceで毎日の業務をAIに任せる
- 第4回：業務を言語化する力がAIの精度を決める — CLAUDE.mdライティング入門（この記事）
- 第5回：IT部門を通さずにAIを使い倒す — 会社データなしでできる業務効率化
- 第6回：MCPって結局何？コードを書かずにClaudeをNotionとSlackに繋いだ3ステップ
- 第7回（最終回）：1人でAIチームを組む — ハーネス設計で業務ルーティンをエージェント化した全工程
関連記事
- 第3回：Gemini × Google Workspaceで毎日の業務をAIに任せる
- Claude Code サブエージェントで5ロール体制を組む実践ガイド
- 148件突破、awesome-claude-codeが示すClaudeエコシステムの輪郭