📋 この記事でわかること
「同じ依頼をしているのに、返ってくる原稿が毎回違う」。導入して数日でぶつかったのは、この出力のブレでした。原因はAIの性能ではなく、社内の当たり前が言語化されていないことにあります。この記事では、CLAUDE.md というルールファイルに社内の前提を書き出し、出力を安定させるまでの記録をまとめました。実際に書いた4種類の項目、3ステップの作り方、効かなかった書き方と直した文の比較表まで、そのまま真似できる形で公開します。情シスのいない会社でも、A4で1枚から始められます。
📖 この記事は約16分で読めます。
なぜ同じ依頼なのに、AIの出力は毎回ブレるのか
Claude 法人導入を始めて数日、私が最初にぶつかったのは「AIが賢いかどうか」という話ではありませんでした。同じつもりで依頼しているのに、返ってくる文章の粒度も文体もその日ごとに違います。原因を探っていくと、問題はこちら側にありました。
「毎回、同じ説明をしている」ことに気づいた日
打ち合わせの音声メモから議事録をまとめてもらう。個人アカウントで試していた議事録づくりを、社内の業務として正式に任せ始めたのは、自社サイトの更新に続く2つめでした。ただ、依頼のたびに私は同じ注文を付け足していたのです。「箇条書きで」「敬体で」「会社名は正式名称で」「決まっていない件は決まっていないと書く」。三日目に自分の入力履歴を見返して、少しぞっとしました。ほぼ同じ前置きを毎回ゼロから書き直し、急いでいる日ほど書き忘れて、あとから直す羽目になっていました。AIの出力が安定しないのではなく、こちらの入力が安定していなかったわけです。
ブレの正体は「暗黙の社内ルール」だった
言い直しの内容を紙に書き出してみると、そのほとんどが社内では当たり前とされている決まりごとでした。社名の表記、日付の書き方、お客様の呼び方、原稿の長さの感覚。どれも口頭で伝えてきた内容で、文書としてはどこにも存在していません。人間の新人なら周囲を見て覚えてくれますが、AIは社内の空気を読んでくれません。渡していない前提は守られない、という当たり前の話に、いざ自分がやられて初めて腹落ちしました。
プロンプトを長くしても解決しなかった理由
最初の対策として、依頼文の冒頭に前提をすべて書く方式を試しましたが、これは三日でやめました。理由は三つあります。第一に、前置きが長くなるほど肝心の依頼が埋もれます。第二に、忙しい日ほど書き忘れます。第三に、私と別の社員では書く前提が違うので、担当者ごとに成果物の型がずれます。前提とは、毎回書くものではなく、あらかじめ置いておくものだったわけです。
CLAUDE.md とは何か──社内の前提を1枚に集める仕組み
Claude 法人導入の実務でいちばん効いた作業を一つ挙げるなら、CLAUDE.md の整備です。難しい設定ではありません。ルールを書いたテキストファイルを、作業フォルダに置くだけです。
会話のたびに自動で読まれる「前提の置き場所」
CLAUDE.md は、Claude Code が作業を始めるときに自動で読み込むマークダウン形式のファイルです(2026年7月時点の仕様です。最新の挙動は公式ドキュメントでご確認ください)。ここに書いたことは、依頼文に毎回書かなくても前提として扱われます。感覚としては、業務マニュアルを机の上に開いたまま仕事をしてもらうのに近いものです。書けるのは日本語の文章だけで十分です。私が最初に作った版も、印刷すればA4で1枚に収まる分量でした。
全社・案件・個人の3階層で考える
いきなり完璧な1枚を目指すと手が止まります。次の3階層に分けて考えると整理がつきました。
- 全社共通……会社名の表記、文体、日付の書式、絶対にやってはいけないこと。どの案件でも変わらないもの。
- 案件ごと……その案件のフォルダ構成、使っているシステム、公開までの手順、担当者と連絡先の扱い。
- 個人……自分の作業環境や、説明の細かさの好み。他人に強制しないもの。
この分け方をしておくと、社内に配るときに「全社共通の部分だけコピーすればいい」と説明でき、展開が楽になります。
「その日の指示」と「いつもの前提」を分ける
書き分けの基準はシンプルです。今日だけ必要なこと、たとえば「この議事録をまとめて」は依頼文に書きます。いつ誰がやっても守ってほしいこと、たとえば「社名は正式名称で書く」はファイルに書きます。この線引きだけで、依頼文は短くなり、成果物のばらつきも減りました。判断に迷ったら「来月も同じことを言うか?」と自問すると、だいたい正しく振り分けられます。
実際に書いた項目──当社のCLAUDE.mdを分解する
ここからは、実際に書いた内容を4つの型に分けて紹介します。中身は業種によって変わりますが、型はそのまま使えるはずです。
①表記と文体のルール(手戻りの大半はここで消えた)
いちばん効いたのはこの項目でした。社名は正式名称で書くこと、日付は西暦で年月日を省略しないこと、時刻にはJSTと添えること、文体はです・ます調でそろえること、専門用語は初出でひとこと説明を入れること。書いたのはこの程度です。どれも読めば当たり前の内容ですが、書いていないと守られません。書いた瞬間から、私が赤入れする回数は減りました。文字の直しに使っていた時間が、内容の検討に回るようになったのが大きい変化です。
②やってはいけないことのリスト
次に効いたのが禁止事項です。ここは肯定文よりも否定文のほうがはっきり効きます。数字を推測で書かないこと、実績や事例を勝手に作らないこと、断定できない話を断定形で書かないこと、お客様の固有名詞を了解なく出さないこと、医療や税務の判断を断定しないこと。特に「わからないときは、わからないと書いて質問する」という一文は、私のCLAUDE.mdで何度も登場する考え方になりました。もっともらしい嘘が混ざるより、途中で止まって聞いてくれるほうが、実務では安全だと考えています。
③成果物の型(テンプレートを先に決める)
議事録、見積の下書き、お知らせ文。社内で繰り返し作る文書は、見出しの並びまで先に決めてしまいました。議事録なら、日時と参加者、決まったこと、決まらなかったこと、次のアクションと期限、という並びで固定します。型が決まっていると、出来上がりを見た瞬間に抜けが分かります。レビューが「読む作業」から「照合する作業」に変わり、確認の時間が短くなりました。
④迷ったときの行動指針
最後の一群は、指示が曖昧だったときにどう振る舞ってほしいかです。選択肢が複数あるときは勝手に決めずに二択か三択で聞くこと、ファイルを消す前に確認すること、想定と違う状態を見つけたら作業を止めて先に報告すること。ここを書いておくと、こちらの説明が足りない日でも事故になりません。以下は、最初の1枚に入れておくと迷いにくい項目のチェックリストです。
- 会社名・サービス名・商品名の正式表記
- 文体(敬体か常体か)と、一文の長さの目安
- 日付・時刻・金額・単位の書式
- 絶対に書いてはいけないこと(推測の数値、未確定の事実、他社の実績)
- 繰り返し作る文書のテンプレート(最低ひとつ)
- 迷ったときの行動(勝手に決めず質問する)
- 成果物を出す前の自己チェック項目
3ステップで作る、自社版CLAUDE.mdの書き方
「何を書けばいいか分からない」というのは、私自身が最初にぶつかった壁でした。おすすめは、頭で考えないことです。すでに自分が毎日口にしている言葉を、そのまま拾えばいい。
ステップ1:1週間ぶんの「言い直し」を集める
AIに頼んで返ってきた成果物に対し、自分が付け足した言葉をそのままメモしておきます。「もっと短く」「その言い方はうちでは使わない」「その数字はどこから出したの?」。この言い直しこそが、文書化されていない社内ルールの正体です。私は1週間でメモが二十数行たまりました。同じ趣旨の言い直しが三回以上出てきたものは、ルール化の候補と考えてよさそうです。
ステップ2:守れたか判定できる文に書き換える
集めたメモを、そのまま貼っても効きません。「丁寧に書く」ではなく「一文は60字以内、専門用語には初出で説明を入れる」と書き換えます。ポイントは、第三者が成果物を見て「守れている/守れていない」を判定できる文にすることです。判定できない文はルールではなく感想です。少し時間はかかりますが、後の効き方が違ってきます。
ステップ3:1週間運用して、効かなかった行を消す
作った直後のファイルは、たいてい欲張りすぎています。私も初版に書きすぎ、重要な行が埋もれました。運用を1週間続けて、守られていない行や、書いた本人が忘れている行は思いきって削ります。増やすより減らすほうが難しく、そして効果があります。以下は、着手前にそろえておくと作業が速く進む準備のチェックリストです。
- 直近の成果物(議事録・提案書・お知らせ文など)を3点そろえる
- 「言い直し」を書きためるメモ帳を1つ決めておく
- 社名・商品名の正式表記を確認できる資料を手元に置く
- ファイルの置き場所を決める(案件フォルダの直下が分かりやすい)
- 書いてはいけない情報の線引きを、あらかじめ社内で確認しておく
- 1週間後に見直す予定を、その場でカレンダーに入れる
効かなかった書き方と、直したあとの文
ここが本題かもしれません。私が実際に失敗した書き方と、直したあとの文を並べて残しておきます。
抽象語は判定できないので効かない
初版でいちばん多かったのが「読みやすく」「いい感じに」「丁寧に」といった抽象語でした。人間の部下に対しても効きにくい指示で、AIに対してはさらに効きません。読みやすさの基準は人によって違うからです。数値や具体的な形に落とすと、守られるようになります。
長すぎるファイルは、優先順位が消える
もう一つの失敗が、書きすぎです。あれもこれもと足すうちに、絶対に守ってほしい禁止事項と、できれば守ってほしい好みが同じ重さで並んでしまいました。今は冒頭に「絶対」の項目だけをまとめ、それ以外を下にぶら下げる構成にしています。重要な行には目印を付け、順番そのものに意味を持たせています。
例外を書かないと、ルールが暴走する
「必ず質問してから進める」と書いたら、ごく小さな判断まで毎回聞かれて手が止まりました。ルールには例外の範囲も添える必要があります。「ただし、表記ゆれの修正など元に戻せる作業は確認不要」と一行足すと、ちょうどよい距離感になりました。禁止と許可はセットで書く——社内規程の作り方と同じだと感じます。
| 失敗した書き方 | 直したあとの文 | なぜ効くのか |
|---|---|---|
| 読みやすい文章で書く | 一文は60字以内。3文ごとに改行を入れる | 守れたかどうかを見た目で判定できる |
| 正確な情報を書く | 出典を確認できない数値は書かない。必要なら「試算」と明記する | 禁止と代替案が同時に示されている |
| 丁寧な言葉づかいで | です・ます調。社名は正式名称。お客様は「様」付け | 抽象語を具体的な表記ルールに落としている |
| 必ず確認してから進める | 削除・公開・送信の前は確認する。表記の修正は確認不要 | 例外を書いたので作業が止まらない |
| 議事録はいい感じにまとめる | 日時/参加者/決定事項/未決事項/次アクションと期限の順で書く | 型が決まり、抜けが一目で分かる |
| (何も書かない) | 迷ったら勝手に決めず、二〜三択にして質問する | 説明不足の日でも事故にならない |
運用ルール──誰が、いつ、どう更新するか
ファイルは作った時点では半分です。更新の仕組みまで決めて、ようやく仕事の一部になります。ここは社内に広げる段階で問題になりやすい部分でもあります。
更新のトリガーは「同じ指摘を2回した」とき
更新のタイミングを気分に任せると、誰も書き足さなくなります。当社では「同じ指摘を2回した時点で1行足す」という決まりにしました。3回目を言う前に書く、と考えると分かりやすくなります。逆に、1回だけの指摘は書きません。たまたまその日の事情かもしれないからです。この基準にしてから、ファイルが太りすぎることはなくなりました。
変更履歴と共有(複数人・複数拠点での扱い)
誰がいつ何を変えたかが分からないファイルは、そのうち信用されなくなります。バージョン管理の仕組みに載せるのが理想ですが、非エンジニアだけの部署ではハードルが高くなります。現実的だと考えているのは、ファイルの先頭に最終更新日時(JST表記)を書き、変更した行の意図を末尾に一行だけ残す運用です。複数の拠点や端末で同じファイルを使う場合は、置き場所を一か所に決め、そこを正とします。手元にコピーを置くと、いずれ食い違いが起きます。
機密情報は書かない(ここだけは厳格に)
CLAUDE.md は共有されるファイルです。パスワード、接続情報、鍵の値、お客様の個人情報は書きません。必要なのは「認証情報は別ファイルから読む」という手順の記述であって、値そのものではありません。この線引きは、社内規程やセキュリティの取り決めと連動させる必要があります。判断に迷う情報は書かずに残しておき、社内で確認してから追記してください。運用ルールの作り方は、専門家にも一度ご確認いただくことをおすすめします。
書き足しながら運用して分かった、CLAUDE.mdの効き方
最後に、しばらく運用して感じている変化を、誇張せずに書いておきます。数字で断定できるものではないので、当社の体感としてお読みください。
変わったこと(当社の体感)
いちばん変わったのは、レビューの中身です。以前は文体や表記の直しに時間を取られていましたが、今はその工程が大きく減り、内容そのものの検討に時間を使えています。二つめは、依頼文が短くなったことです。前提を書かなくてよいので、頼みごとが一行で済みます。三つめは、担当者が変わっても成果物の型がそろうことです。これは社内展開を考えるうえで、大きい効果かもしれません。当社ではこのコーポレートサイト自体の更新も日本語の指示で回していますが、その運用の実例はWordPressとAIを活用した日本語指示によるホームページ更新のページにまとめています。
変わらなかったこと(任せてはいけない領域)
一方で、ルールを書けば何でも解決するわけではありません。何を作るべきかという判断、お客様の事情をふまえた優先順位づけ、そして最終責任。この三つは今も人間の仕事です。細かい表記の指摘から解放されたぶん、この三つに向き合う時間が増えました。AIに任せる範囲を決めるのは経営判断であって、ファイルに書けば済む話ではない、というのが今の実感です。
これから書く方へ(無料相談のご案内)
Claude 法人導入でつまずくポイントは、契約でも操作でもなく、この「社内の当たり前をどう言語化するか」に集中していると感じます。とはいえ、自社のルールは中にいると見えにくいものです。当社では、自社の業務でこの運用を回したうえで、支援メニューを組み立てています。詳しくはClaude 法人導入支援のページをご覧ください。「うちの場合は何から書けばいいか」を一緒に整理したい方は、無料相談(オンライン・全国対応・所要60分)からお気軽にご連絡ください。
よくある質問(FAQ)
CLAUDE.md はプログラミングの知識がないと書けませんか?
いいえ、書けるのは日本語の文章だけで十分です。中身は業務マニュアルに近く、社名の表記や文体、禁止事項を箇条書きにするところから始められます。当社の初版もA4で1枚程度でした。難しく考えるより、まず短く作って運用しながら育てるほうが失敗しません。
どのくらいの分量が適切ですか?
一般的な目安として、最初はA4で1枚、多くても2枚程度に収めるのがおすすめです。長くなるほど重要な行が埋もれ、優先順位が伝わりにくくなります。増やすときは、絶対に守ってほしい項目を冒頭にまとめる構成にすると読み違いが減ります。
書いたルールが守られないことがあります。原因は何でしょうか。
多くの場合、文が抽象的で判定できないことが原因です。「読みやすく」ではなく「一文は60字以内」のように、第三者が成果物を見て守れているか判断できる形に書き換えてください。それでも守られない行は、他の行と矛盾していないかを確認すると原因が見つかります。
パスワードや顧客情報を書いてもよいですか?
書かないでください。CLAUDE.md は社内で共有される前提のファイルです。認証情報や個人情報は値そのものを書かず、「別管理のファイルから読む」といった手順だけを記述します。社内規程との整合や具体的な取り扱いは、情報システムの担当者や専門家にもご確認ください。
更新は誰が担当するのがよいですか?
更新権限を一人に絞るより、「同じ指摘を2回したら誰でも1行足す」という運用が現実的でした。ただし追記の重複や矛盾が出るため、月に一度は誰かが通しで読み、重複と古い行を整理する時間を取ることをおすすめします。
効果はどのくらいで出ますか?
明確な数値をお約束することはできませんが、当社の体感では、表記や文体の指摘が減る効果は書いた当日から現れました。一方で、成果物の型がそろい社内展開が楽になる効果は、数週間の運用を経てから実感しています。まずは1週間、削る前提で書いてみるのが近道です。
✏️ 山崎 将史より
CLAUDE.md を書く作業は、正直に言うと地味です。新しいツールを触るときの高揚感はありません。それでも独立した一本として書いたのは、Claude 法人導入の成否がここで大きく分かれると考えているからです。当社でうまくいかなかった原因を掘っていくと、「AIの精度が低い」という話は、たいてい「社内のルールが誰の頭の中にもあるが、どこにも書かれていない」という話に着地しました。これはAIの問題ではなく、引き継ぎや新人教育でずっと起きてきた問題と同じものだと感じます。
Web構築を25年やってきて、仕様が曖昧なまま進んだ案件がどうなるかを何度も見てきました。作り直しになるのは、たいてい技術力の不足ではなく、前提の共有不足です。AIが相手になったことで、その曖昧さが以前よりずっと早く表面化するようになりました。面倒が増えたというより、先送りにしてきた言語化に期限が付いたのだと受け止めています。
もう一つお伝えしたいのは、完璧を目指さないことです。私の初版にも、いま読み返すと恥ずかしい行がたくさんあります。それでも書いてよかったと思うのは、書いたから間違いに気づけたからです。頭の中にあるうちは、間違っていることにすら気づけません。ファイルにして初めて、そのルールは検証できる対象になります。
当社は「机上の空論を売らない」ことを大事にしています。この記事に書いた内容も、すべて自社の業務で回したうえでのものです。もし今、社内のどこから手を付ければよいか迷っていらっしゃるなら、まずは今週ご自身が言い直した言葉をメモすることから始めてみてください。ご一緒に整理したい方は、無料相談でも、サービス詳細ページからでもお気軽にお声がけください。