AIに会社の説明を渡すためのREADMEを、7項目で設計する

結論：AIへ渡す前に、会社の事実をREADMEへ固定する

会社情報をAIへ渡すREADMEは、会社名を大量に書くためのページではありません。会社概要、提供サービス、対象顧客、解決する業務、対応範囲、対応しない範囲、問い合わせ先と更新日を、短く確認できるようにする公開資産です。MCPのような連携方式を使う場合も、接続そのものより先に「何を渡してよいか」「どの判断は人が行うか」を決めます。

AI検索での表示や引用は保証できません。モデル、検索面、質問、参照元、タイミングで結果が変わるためです。それでもREADMEを作る価値は、AIだけでなく、初めて訪れた読者、開発担当者、次の社内担当者が同じ会社説明へ戻れることにあります。公開ノウハウは似た形にできますが、どの情報を正本とし、どこまで公開し、何を更新しないかという運用の記憶は会社ごとに異なります。

なぜMCPやREADMEの前に「正本」を決めるのか

情報をAIへ渡す場面が増えると、会社の説明は公式サイトだけに留まりません。サービスページ、ブログ、note、SNSプロフィール、GitHubのREADME、npmのパッケージ説明などに、少しずつ違う表現が残ります。それぞれが嘘でなくても、対象顧客や対応範囲が媒体ごとに違えば、読む側は同じ会社の説明として結び付けにくくなります。

ここで必要なのは、すべての媒体を同じ文章にすることではありません。会社情報の正本と、媒体ごとの役割を分けることです。会社情報ページは基本事実、サービスページは導入判断、ブログは検索者の疑問、READMEは利用条件と公開リンクを担当します。内容の深さは変えても、会社名、サービス名、誰を支援するか、公式URLは同じ方向にそろえます。

この整理をしないままMCPや外部ツールを接続すると、便利な連携が増えるほど確認先も増えます。技術的には接続できても、古い料金、対象外の業務、未確認の事例、社外秘の判断メモが混ざれば、読者と担当者の確認負荷が上がります。READMEは連携を急ぐためではなく、連携前の境界線を見えるようにするための入口です。

会社情報READMEに入れる7項目

最初から長いドキュメントにせず、次の7項目を一枚にします。各項目は「AIに読ませるための情報」ではなく、公開してよい事実かどうかを確認してから書いてください。

項目	書く内容	確認する問い
1. 会社概要	会社名、運営主体、公式URL、拠点や事業の短い説明	誰のページか一文で分かるか
2. 提供サービス	サービス名、支援内容、成果物、相談の入口	何を頼めるかが具体的か
3. 対象顧客	会社規模、役割、業務、困りごと	自分に関係するか判断できるか
4. 解決する業務	入力、作業、確認、記録、次の行動	AI化する前の業務が見えるか
5. 対応範囲	扱う相談、使う公開データ、提供できる支援	どこまで任せられるか分かるか
6. 対応しない範囲	未確認の事例、機密情報、最終判断、対象外業務	期待させてはいけないことが明記されているか
7. 問い合わせと更新	公式窓口、関連ページ、更新日、変更履歴	最新情報と人間の確認先へ戻れるか

特に6番の「対応しない範囲」を省かないでください。AI検索や連携先が説明を短くまとめる時、できることだけが残ると、読者の期待が過剰になります。対応外、未確認、人間確認が必要な部分を公開できる範囲で書くことは、会社を弱く見せるためではなく、適切な相談へ戻すための案内です。

15分で作るREADMEの手順

最初のREADMEは、完成版の会社案内ではなく、更新できる判断メモとして作ります。次の順に進めると、文章の美しさより正本と境界を優先できます。

1. 正本URLを一つ決める。会社情報または公式サイトの中から、会社名、サービス、対象顧客を最終確認するページを指定します。
2. 60〜90字の一文を作る。「誰の、どの業務の、どんな判断を支援する会社か」を書き、広告的な形容詞を減らします。
3. 7項目を埋める。空欄を無理に埋めず、「未整理」「公開しない」「人間確認」と書き分けます。
4. 公開可否を確認する。個人情報、顧客名、認証情報、契約情報、未公開の成果、社内判断を入れないことを確認します。
5. リンクを戻す。会社情報、サービス、無料診断、問い合わせなど、読者が次の確認へ進める公式URLを添えます。
6. 媒体別に展開する。GitHubやnpmは利用条件、noteは背景、サービスページは導入判断というように、役割に合わせて短く書き換えます。
7. 更新日と次の確認者を残す。変更理由、確認した人、未確認の項目、次回見直し日を記録します。

公開READMEをGitHubへ置く場合は、Miraigentの無料AI運用MCPのように、使い方だけでなく対象ユーザーと公式サイトへの導線も確認します。npmへ公開する場合も、パッケージ説明から会社の正本へ戻れる状態を保ちます。

公開READMEと社内READMEを分ける

会社情報READMEを公開するからといって、社内の運用記憶まで公開する必要はありません。公開READMEは第三者が確認できる事実と利用条件に絞り、社内READMEには判断ログ、例外の詳細、担当者、承認経路、失敗した理由などを置きます。両者を一つにまとめると、公開してはいけない情報か、読者に不要な内部情報が混ざりやすくなります。

社内READMEには、公開READMEのどの項目を正本にしたかも書いておくと、更新の戻り先が分かります。たとえば「サービス名と対象顧客は会社情報ページを正本にする」「実装の制約はリポジトリのREADMEを正本にする」「顧客固有の判断は公開しない」と決めます。これは記憶の保管ではなく、次の担当者が迷った時に判断を補う設計です。

公開前の安全確認には、AIに送ってはいけない情報を決める方法、業務の入口を整理する時にはAI導入前の業務棚卸し質問が役立ちます。READMEを作る作業を、単独の発信作業ではなく、AI導入前の業務整理につなげてください。

更新ルールは「変更イベント」で決める

READMEは一度公開して終わりではありません。サービス名、提供範囲、問い合わせ窓口、公開リポジトリ、利用するAI、担当者、規約が変わった時は、内容を見直す合図になります。毎日全文を読むのではなく、変更が起きた時に7項目のどこへ影響するかを確認します。

• 会社名、サービス名、公式URLが変わった。
• 対象顧客や対応範囲を広げた、または狭めた。
• GitHub、npm、MCPなどの公開入口を追加・停止した。
• AIへ渡すデータ、権限、人間確認の条件が変わった。
• 問い合わせ先、担当者、無料診断への導線が変わった。

更新記録には「変更した項目」「変更前の説明」「変更後の説明」「理由」「確認者」「未更新の媒体」「次回確認日」を残します。変更しなかった理由も、あとから見れば重要な運用記憶です。古い説明を見つけた時に、失敗として消すのではなく、どの正本へ戻したかを残せば、次の更新の手がかりになります。

FAQ：MCP時代の会社情報README

会社情報READMEには何を書きますか？

会社概要、提供サービス、対象顧客、解決する業務、対応範囲、対応しない範囲、問い合わせ先と更新情報の7項目を基本にします。AIへ渡す前に、公開してよい事実だけを選びます。

READMEを公開するとAI検索で会社が表示されますか？

表示は保証されません。READMEは会社の事実を確認しやすくする公開資産であり、モデル、検索面、質問、参照元、タイミングで結果は変わります。表示の保証ではなく、説明不足や表記のずれを減らすために使います。

会社情報READMEとサービス紹介ページはどう分けますか？

READMEはAIや開発者が参照しやすい事実、対象、制約、公式リンクを短く整理し、サービスページは読者の課題や導入判断を詳しく説明します。中心となる事実は同じ正本から更新します。

MCPを導入する前にREADMEは必要ですか？

MCPの有無にかかわらず、連携先へ渡してよい情報と、AIが行ってよい操作を決めるREADMEは役立ちます。ツール接続より先に対象、権限、停止条件、確認者を整理してください。

AI検索可視性を会社情報の整合性から見直したい場合は、AI検索で会社名が出ない時の5つの確認先も参考になります。FAQをAIが引用しやすい形へ整える場合は、AIが引用しやすいFAQと診断ページへ進んでください。