社内FAQはAIで作る。「あの人に聞けば分かる」を「読めば分かる」に変える手順

「経費のこれ、どの科目ですか」「VPNがつながらないんですけど」「あの申請書、どこでしたっけ」。この手の質問は、会社の中の決まった誰かに集まります。総務のあの人、情シスのあの人、経理のあの人。答える側は自分の仕事を止めて答え、聞いた側は答えをもらって終わり。そして同じ質問が、来月また別の人から来ます。FAQを作ろうという話は何度も出ているのに、書く時間だけが、いつまでもない。

先に結論を置きます。社内FAQは、書くものではありません。集めて、AIに下書きさせて、人は検品するものです。「FAQを作ろう」と言って挫折した会社は、ほぼ例外なくゼロから書こうとしています。原料は、もう社内に溜まっています。実際に聞かれた質問、チャットの履歴、議事録。そこから一問一答をAIに組ませて、人は中身の確認だけをやる。この順番に変えると、書く時間がない会社でもFAQは作れます。

この記事は、ツールの紹介では終わらせません。NotebookLMをはじめ、文書を読ませて答えさせる道具の使い分けはNotebookLMの業務活用記事に書いてあります。ここに書くのは、どの道具を選んでも変わらない設計です。原料をどこから集め、どの質問を選び、AIに何を渡し、人がどこを見て、どこに置き、どう回し続けるか。順番にいきます。

---

質問が一人に集まる構図は、属人化の入口

「あの人に聞けば分かる」は、社内では褒め言葉です。頼りになる。話が早い。本人も、聞かれれば答えます。悪者はどこにもいません。ところがこの構図を仕事の流れとして見ると、別の顔が出てきます。会社の答えが、文書ではなく特定の人の頭の中にだけある、という顔です。

書籍『コンテキスト経営』の序章に、私はこう書きました。道具は増えたのに、会社は変わらない。チャットもクラウドも入れたのに、仕事は前と同じ人に張り付いたまま。理由は、文脈が人の頭の中に残っているからです。社内の質問対応は、その最小単位です。経費の科目の判断基準も、VPNの直し方も、申請書の置き場も、文書になっていないから、頭を持っている人に質問が集まる。

コストは、答える1〜2分では済みません。私が生成AI顧問として累計約15社、研修や講座を含めると30社超を見てきて、質問集中の高くつく順はこうです。

• 割り込みのコスト。答える側は、そのたびに自分の仕事を中断します。中断した仕事に戻るまでの時間は、答えた時間より長いことが多い。質問が1日10件来る人は、10回仕事を止めています。
• 再演のコスト。同じ質問に、先月も先々月も答えています。答えるたびに丁寧に説明する人ほど、会社としては同じ芝居を何度も打っている。
• 不在のコスト。その人が休んだ日、質問の行き先がなくなります。仕事が止まるか、聞かずに進めて間違えるか。どちらも起きます。
• 昇格できないコスト。答えられる人が答え続ける限り、その人は質問対応から離れられません。「頼られている」状態が、その人の次の仕事を塞ぎます。

よく見る光景を、一般化して一つ置きます。月末の経理担当の席には、経費精算の質問が列を作ります。「これ、会議費ですか交際費ですか」「領収書じゃなくてレシートでもいいですか」。担当者は月次の締め作業の手を止めて、一件ずつ答えます。答えは毎月ほぼ同じです。それでも列は消えません。答えがその人の頭の中にしかなく、聞く以外の入手経路がないからです。締めが遅れる原因を聞くと「作業量」と返ってきますが、横で見ていると、作業より割り込みで遅れています。

質問対応は親切な仕事に見えるので、誰も問題にしません。ここが厄介です。放っておくと、答えられる人が増えるのではなく、聞く先が固定されていきます。この構図の全体像と解き方は属人化解消の記事に書きました。FAQは、その中で一番軽い最初の一手です。人を替える必要も、組織図を触る必要もない。「読めば分かる」を1問ずつ増やすだけです。

「FAQを書こう」が失敗し続けてきた理由。時間ではなく順番

社内FAQの構想は、たいてい一度は出ています。誰かが「まとめておきましょうか」と言い、テンプレートが作られ、数問だけ書かれて、止まる。私はこれを、担当者の怠慢だと思っていません。順番が逆なんです。

ゼロから書くFAQは、「聞かれそうな質問」を想像して書きます。想像で書いた質問は、実際に聞かれる質問とずれます。ずれたFAQは検索されず、読まれず、読まれないものは更新されず、更新されないFAQは1件の古い答えで信用を失います。一度「あそこ、古いよ」と言われた社内ページは、二度と開かれません。作って終わりの社内Wikiやナレッジベースが死んでいく経路はナレッジ管理の失敗記事に詳しく書きましたが、FAQはその最短コースです。

似た形を、AI導入の現場でもよく見ます。導入直後に配られた社内プロンプト集が、1ヶ月後には誰にも開かれなくなる。あれも同じで、作った側の想像と、使う側の現実がずれているからです。ずれを埋める方法は、想像の精度を上げることではありません。現実に起きた質問だけを原料にすることです。

観点	ゼロから書くFAQ	集めて検品するFAQ
出発点	聞かれそうな質問の想像	実際に聞かれた質問のログ
書く人	答えを知っている人＝一番忙しい人	下書きはAI。人は検品だけ
需要との一致	ずれる。読まれない	3回聞かれた質問だけ。読まれる
質問文の言葉	社内の正式用語	質問した人の言葉のまま
完成までの時間	「時間ができたら」のまま数年	原料集め2週間＋検品は1問数分
更新	大改訂を待って止まる	新しい質問が来るたび1問ずつ
1年後	誰も開かないページ	質問対応の一次窓口

右側の列に共通しているのは、「書く」という動詞がないことです。集める、選ぶ、下書きさせる、検品する、置く、戻す。この6つの動詞でFAQはできます。以降のセクションが、その6つです。

原料はもう社内に溜まっている。質問ログ・チャット履歴・議事録

集める、から始めます。実際に聞かれた質問は、需要の証明書です。誰かが仕事を止めてまで聞いたのだから、答えを探した人が確実に一人いる。想像で書いた質問には、この証明がありません。原料になるのは、次の6か所です。

原料	取れるもの	注意
チャットの業務チャンネル	質問の原文と、そのとき実際に答えた文面のセット	個人DMは原料にしない。業務チャンネルに限る
問い合わせメール	部署の外から来る定番質問	顧客名・個人情報の混入に注意
議事録	会議のたびに繰り返される確認事項	抽出の詳しい型は議事録記事へ
口頭質問の1行メモ	電話・立ち話・席への訪問。実はこれが最多	その場で1行。後でまとめて思い出そうとしない
新人からの質問	古株の「当たり前」が当たり前でない証拠	質問者を「分かってない人」扱いしない
過去のトラブル対応の記録	「やってはいけない」系の一問一答の種	個人の失敗談の形で書かない

最初の2週間は、これだけやってください。質問が集中している人が、聞かれるたびに「日付・質問・答えた要点」を1行メモする。チャットで聞かれた分は、後から遡って拾えるのでメモ不要です。口頭と電話だけ、その場で1行。2週間で、たいてい20〜40行たまります。その中に、同じ質問が2回3回と出てきます。それが最初のFAQ候補です。

議事録も、思っている以上に良い原料です。会議で毎回誰かが確認する事項は、文書がないから毎回確認されています。うちの会社でも、過去の議事録9本をAIに読ませて、繰り返し出ていた判断をルール39本として書き出し、社内規程に戻す作業をやりました。会議の前後にAIを入れる話は別の記事に譲りますが、議事録から繰り返しを拾う手つき自体は議事録AIの記事にあります。

原料を集める段階で、線を1本だけ引いてください。個人DM・人事評価・健康・給与の話は、原料の箱に入れない。FAQは共有される前提の文書です。共有できない情報が混ざった原料からは、共有できないFAQしか生まれません。AIに渡してよい情報の段階分けはセキュリティ設計の記事と社内ルールの記事に詳しく書いてあります。

総務・情シス・経理。最初の10問が眠っている場所

2週間のメモを待たずに当たりを付けたい場合のために、質問が集中しやすい3部署の「鉱脈」を書いておきます。私がFAQづくりを手伝うとき、最初に覗きに行く場所です。

総務は「場所と期限」型。申請書はどこか、提出はいつまでか、押印は要るのか、備品はどう頼むのか、入退社のとき何を出すのか。答えは完全に決まっているのに、聞かれ続けます。決まっている答えほどFAQの効きが早いので、最初の10問は総務から選ぶと立ち上がりが軽くなります。難易度も低い。「答えの検品」でもめる要素がほぼありません。

情シスは「直し方」型。パスワードを忘れた、VPNがつながらない、共有フォルダが開けない、新しい端末の初期設定。この型の罠は、答えを丁寧に書くと手順書になってしまうことです。FAQに載せるのは全手順ではありません。症状の確認1行、最初に試す一手、それでだめなら誰へ、の3点だけ。10行を超える手順は手順書に切り出して、FAQからはリンクで送ります。私の体感ですが、「つながらない」系は最初の一手で大半が消えます。そういう質問から選ぶのがコツです。

経理は「判断」型が混ざる。科目はどれか、この領収書で通るか、締め日はいつか、立替はどう精算するか。締め日や精算手順は総務と同じ「場所と期限」型ですが、科目判断のように、条件次第で答えが変わる質問が混ざります。ここで全条件を書き切ろうとすると、FAQが税務の解説書になって死にます。書くのは線引きだけです。「この範囲は◯◯で処理」「迷ったら、金額と内容を添えて経理へ」。判断そのものではなく、自分で判断してよい範囲と、聞くべき範囲の境界線をFAQにする。これだけで「一応聞いておこう」の質問が目に見えて減ります。

3部署に共通するのは、質問する側は毎回「初めて」で、答える側だけが「何度目か」を知っていることです。だから質問者に「調べてから聞いて」と言っても直りません。何度目かを知っている側が、回数を記録できる唯一の人です。原料集めの主役が「一番聞かれている人」なのは、その人が一番忙しいからではなく、その人にしか需要が見えていないからです。

持ち帰り①：FAQ化する質問の選別チェックリスト10問

集めた質問を、全部FAQにしてはいけません。100問のFAQは誰も読みません。10問のFAQは読まれます。選別の基準を、私が顧問先に渡している形のまま10問で置きます。候補の質問1つにつき、上から順に当ててください。

1. 同じ質問が3回以上来たか。1回は個別対応でいい。2回目で候補メモ、3回目でFAQ化。この「3回ルール」だけで、候補は自然に絞られます。
2. 答えが半年後も変わらないか。変わるもの（料金・担当者・期限）は、答えそのものではなく「どこを見れば最新か」を書く。
3. 答えが3〜10行に収まるか。収まらないならFAQではなく手順書の仕事です。マニュアル作成の記事へ。FAQには「マニュアルはここ」とリンクだけ置く。
4. 答えに判断が要らないか。ケースバイケースの質問は、答えを書こうとすると嘘になります。「この場合の判断は誰がするか」をFAQにする。
5. 秘密情報・個人情報を含めずに書けるか。書けないなら、FAQではなく担当者ルートのままにする。
6. 質問した人の言葉のまま見出しにできるか。「VPNがつながらない」を「リモートアクセス接続障害時の対応」に翻訳すると、次に困った人が見つけられません。
7. 答えの根拠になる文書があるか。規程・通達・過去の決定。口伝しかないなら、FAQ化はその口伝を初めて文書にする機会です。根拠ごと作る。
8. どの部署から聞かれても同じ答えでよいか。部署によって答えが違うなら、違いを明記するか、この機会に統一を決める。
9. 例外の行き先を1行で書けるか。「原則はこう。例外は◯◯さんへ」まで書けて、1問の完成です。行き先のないFAQは、例外に当たった人を放置します。
10. 半年後の見直し担当を決められるか。決められないFAQは、作った日から死に始めます。担当は「一番聞かれている人」で構いません。

10問すべてに◯が付く質問だけがFAQになります。最初は10〜15問も残れば十分です。少なく感じるかもしれませんが、その10問は「実際に3回以上聞かれた質問」です。想像で書いた50問より、確実に仕事をします。

持ち帰り②：一問一答はAIに下書きさせる。人は検品だけ

選んだ質問を、いよいよ一問一答にします。ここで人が書き始めると、また止まります。書くのはAIです。ただし、うまい指示文が本体なのではありません。本体は、渡す原料と、出てきたものを人がどう検品するかです。実際に聞かれた質問の原文、そのとき答えたやりとり、根拠の文書。この3点を渡せば、指示文は素朴で構いません。

FAQ1問分の依頼文ひな形を置きます。チャット型のAIなら、どの道具でもこのまま使えます。

社内FAQの下書きを1問分作ってください。

## 渡すもの
1. 実際に聞かれた質問（原文のまま）：
「（ここに質問を貼る）」
2. そのとき答えた内容（チャットや口頭メモの記録のまま）：
「（ここにやりとりを貼る）」
3. 根拠になる文書（規程・手順書・過去の通達など）：
（あれば貼る。なければ「なし」と書く）

## 作り方
- 質問文は、聞かれた言葉のまま見出しにする。正式用語に言い換えない
- 答えは3〜10行。手順が10行を超えそうなら「マニュアル化候補」とだけ書いて止める
- 答えの末尾に、根拠文書の名前を1行付ける
- 渡した資料に根拠がない部分は、推測で埋めずに【要確認】と書く
- 例外がありそうな場合は「例外の場合は◯◯へ」の行を作る。行き先が不明なら【要確認】
- 最終行に「最終確認日：」「確認者：」の空欄を付ける

このひな形で一番大事な行は、【要確認】です。AIは空白を嫌い、それらしい答えで埋めようとします。埋めさせないで、穴のまま出させる。穴を埋めるのは人の仕事です。私が普段から置いている分担——判断はプロ、作業はAI——の、FAQ版がこれです。文章の組み立てと整形はAIが速く、この答えを社内に配ってよいかの判断は人にしかできません。

検品は、次の4点だけ見ます。誤字は見なくていい。

1. 混入。秘密情報・個人情報・特定の社員の話が入っていないか。質問者の名前は残さない。
2. 古さ。答えは今日時点で正しいか。規程が改定されていないか。「最終確認日」を必ず埋める。
3. 断定。例外があるのに原則だけを断定していないか。【要確認】が残ったまま公開しようとしていないか。
4. 行き先。「例外は◯◯へ」の◯◯は、実在する現任の担当か。異動済みの名前は事故のもとです。

1問の検品は、慣れると2〜3分です。10問なら30分。「FAQを書く時間がない」と数年言い続けてきた会社が、最初の10問を半日で持てます。書かないからです。

完成形の1問。きれいさより、番号で返せるか

抽象のままだと手が動かないので、検品を通過した1問の完成形を置きます。会社名も実額も入っていない、型だけの例です。

Q3. 出張のホテル代は、いくらまで使えますか？

A. 国内出張の宿泊費は、旅費規程に上限額が定められています（旅費規程 第7条）。
　 上限を超える場合は、予約前に部門長の承認が必要です。
　 繁忙期などで上限内の宿が取れないときは、予約前に総務へ相談してください。

例外の場合は：総務・□□へ
根拠文書：旅費規程（2026年4月改定版）
最終確認日：2026-08-15　確認者：□□

見てほしいのは文章のうまさではなく、4つの部品です。番号がある。根拠文書の名前がある。例外の行き先がある。最終確認日がある。この4つが揃った1問は、「それ、FAQの3番です」の一言で質問対応を終わらせます。上限の金額そのものをFAQに書いていないのも意図的です。金額は規程の改定で変わるので、FAQには「どこを見れば最新か」だけを書く。チェックリストの2問目を、答えの書き方に落とすとこうなります。

逆に、この型に載らない質問が残ったら、それはFAQの仕事ではありません。手順が長いならマニュアルへ、条件で答えが割れるなら判断者の明記へ、そもそも仕組みが悪いなら仕組みの修正へ。FAQは何でも入る箱ではなく、この型に収まるものだけを入れる箱です。箱の形が決まっているから、AIに下書きさせても崩れません。

道具は3型だけ知ればいい。NotebookLMの細部は別記事へ

ここまで道具の名前をほとんど出していないのは、順番の問題だからです。原料と選別と検品の設計がないままツールを選ぶと、どのツールでも同じ死に方をします。その上で、社内FAQの置き方は3型に整理できます。

観点	①固定ページ型 （一問一答を並べる）	②文書検索型 （AIが文書から答える）	③常設ボット型 （チャットに住まわせる）
初期の手間	小。10問から置ける	中。文書の整備が先	大。導線と権限の設計が要る
更新の手間	1問ずつ足す	元の文書を直せば反映	設計次第で軽くも重くもなる
答えの信頼性	高い。人が検品済みの答えだけ	中。根拠のない補完が混ざりうる	中。ログの監査を怠ると下がる
向く会社	これから始める全社	規程・手順書がすでに多い会社	質問量が多く、情シスに余力がある会社
検品の場所	公開前に1問ずつ	回答の出典を都度確認する運用	回答ログの定期監査
最初の一歩として	◎	○	△

NotebookLMは②の代表です。規程や手順書を読ませて、出典付きで答えさせる。読ませ方と向き不向きはNotebookLMの業務活用記事に書いたので、ここでは繰り返しません。この記事から持ち帰ってほしいのは1点だけです。②や③を選んでも、①の作業はなくなりません。AIが文書から答える型は、読ませる文書の質がそのまま答えの質になります。検品済みの一問一答は、人が読んでも分かり、AIに読ませても間違えにくい、二重に効く原料です。

書籍『ChatGPTを、「AI社員」に育てる方法』の第3章で、私は「フォルダを職場にする」という言い方をしました。AIを賢い新入社員として迎えるなら、その新入社員が読む棚を先に作る。検品済みのFAQフォルダは、まさにその棚の一段です。将来ボットを置くにしても、優秀なAI社員は指示文だけでは生まれず、指示×文脈×仕組みの掛け算で決まります。FAQはその「文脈」の、一番作りやすい部分です。

置き場所の設計。作って満足した社内DBは、なぜ全部死んだか

一問一答が10問できたら、置き場所です。ここで「せっかくだから」とナレッジベースを新調すると、だいたい失敗します。立派な器を建てて、引っ越しの途中で力尽きて、器ごと忘れられる。この経路はナレッジ管理の失敗記事で詳しく書いたので、ここではFAQに必要な原則だけ絞ります。3つです。

• 質問が発生する場所の隣に置く。質問がチャットで来るなら、チャットから1クリックの場所。申請画面で迷うなら、申請画面のリンク欄。人は、困った場所から2クリック以上先の答えを探しに行きません。
• 正は1か所。チャットのピン留めと、共有フォルダと、Wikiに同じFAQを置くと、3か月後に3つの違う答えが生まれます。正を1か所に決め、他は正へのリンクだけにする。
• 番号で返せる住所にする。各問に番号を振り、「それ、FAQの3番です」と返せる形にする。URLでも文書名＋番号でもいい。番号で返せると、答える側の負担が1行になり、聞いた側は次から自分で開けます。

3つ目が、運用の生命線です。FAQを作った後も、質問は来ます。来ていいんです。そこで「FAQ見てください」とだけ返すと、冷たい運用になって続きません。「FAQの3番です」と答えと住所をセットで返す。これを2〜3回繰り返すと、聞く前に見る人が増えていきます。禁止ではなく導線で変える。ここを設計と呼びます。

更新の仕組み。新しい質問が来たら、FAQに戻す

FAQの寿命を決めるのは、初版の出来ではなく、この循環があるかどうかです。

私はAIへの指示を直すとき、直しの行き先を「その場限りで流す／覚えさせる／ルールにする／定型の呼び出しにする」の4つに分けています。社内の質問対応も、実は同じ分岐です。一度きりの質問はその場で流す。繰り返す質問はFAQに書く。そもそも質問が出ないように仕組みを直せるなら、FAQではなく申請画面や規程そのものを直す。毎回同じ作業が付随するなら、自動化する。FAQは万能の受け皿ではなく、「繰り返すが、仕組みまでは直せない質問」の置き場です。この分岐を持っておくと、FAQが無限に太っていく事故を防げます。

運用の全体を表にしておきます。登場人物は少ないほど続きます。

頻度	誰が	何をする	やらないこと
質問が来るたび	答えた本人	FAQにあれば番号で返す。なければ答えて「候補」と1行メモ	その場で清書を始める
週1・15分	決めた一人	候補メモに3回ルールと10問チェックを当てる	全部をFAQ化する
月1・30分	同じ一人	選ばれた分をAIに下書きさせ、4点検品して追記	デザインや分類の大改訂
半年に1回	見直し担当	全問の「最終確認日」を見て、古い答えを直すか消す	ゼロからの作り直し
随時	答える人全員	「FAQの◯番です」と答えと住所をセットで返す	「FAQ見て」とだけ返す
やらない	全員	—	ツール選定会議を運用より先にやる

効果の測り方も、シンプルでいいと思っています。FAQのアクセス数ではありません。質問が集中していた人に、同じ質問が来なくなった数です。2週間の1行メモをもう一度やれば、比べられます。番号で返した件数が増え、答えを書いた件数が減っていれば、FAQは仕事をしています。空いた時間で何をするかは、時間削減の話ではなく、その人が次に打てる手が増える話です。ここから先の広げ方——FAQの次に棚卸しへ進む道は業務棚卸しの記事にあります。

よくある質問

Q1. 社内FAQは何問から始めればいいですか？

10問前後で始めてください。100問のFAQは立派に見えて読まれません。3回ルールで選別すると、最初はだいたい10〜15問に絞られます。少ない状態で公開して、循環の中で1問ずつ足すほうが、初版で網羅するより確実に生き残ります。

Q2. チャット履歴を原料にして、社員に嫌がられませんか？

線を先に宣言すれば大丈夫なことが多いです。使うのは業務チャンネルだけ、個人DMは見ない、FAQに質問者の名前は残さない、目的は質問対応の分散。この4つを始める前に伝えてください。黙って収集を始めると、内容ではなく進め方で不信を買います。

Q3. NotebookLMに規程を全部読ませれば、FAQは要らなくないですか？

検索の答えは出ますが、検品されていない答えです。規程同士が矛盾していたり、古い版が混ざっていたりすると、AIはそれらしくまとめてしまいます。人が検品した一問一答を挟むと、人にもAIにも効く原料になります。読ませ方の詳細はNotebookLMの記事に書きました。

Q4. 担当は誰にすべきですか？

一番質問が集まっている人です。需要を全部知っているからです。ただしその人に「書かせて」はいけません。書くのはAI、その人は週1の選別と月1の検品だけ。合計で月1時間強です。それ以上かかる設計になっていたら、設計のほうを疑ってください。

Q5. FAQを作っても、調べない人は結局聞いてきませんか？

聞いてきます。それでいいんです。「FAQの3番です」と番号で返してください。答えはもらえるので聞いた人は困らず、答える側は1行で済み、2〜3回で先に見る人が増えます。「聞くな」と言う運用は角が立って続きません。導線で変えるほうが早いです。

Q6. 人によって答えが違う質問が出てきました。どうしますか？

それはFAQ作りの一番の副産物です。会社として決まっていないことが露呈しました。その質問はまだFAQに書けません。決める人に上げて、決まってから載せます。FAQを作る過程は、答えの整備と同時に「決まっていなかったこと」の棚卸しになります。

Q7. 顧客向けFAQも同じ作り方でいいですか？

骨は同じです。問い合わせ履歴が原料で、AIが下書きし、人が検品する。ただし検品の基準が変わります。社外に出してよい情報の線、表現のトーン、法的な言い回しの確認が加わるので、検品者は変えてください。この記事の型は社内向けに書いています。

Q8. 最初は回ったのに、更新が続きません。

意思の問題ではなく、仕組みの欠けです。だいたい「答えた直後の1行メモ」か「月1の30分」のどちらかが抜けています。メモは答えたその場で、清書せず1行だけ。月1はカレンダーに固定。この2点が戻れば循環は再開します。続けようと頑張る運用は、頑張れなくなった日に止まります。

まとめ：FAQは書くものではなく、集めて検品するもの

社内FAQをAIで作る手順を、動詞だけでもう一度並べます。集める、選ぶ、下書きさせる、検品する、置く、戻す。「書く」はどこにもありません。

• 質問が一人に集まる構図は属人化の入口。FAQはその一番軽い最初の一手
• 原料は質問ログ・チャット履歴・議事録。想像で書かない。2週間の1行メモから始める
• 選別は3回ルール＋チェックリスト10問。全部をFAQ化しない
• 一問一答はAIに下書きさせる。【要確認】を残させて、人は混入・古さ・断定・行き先の4点だけ検品
• 置き場は質問が発生する場所の隣に1か所。「FAQの◯番です」と番号で返せる住所にする
• 新しい質問はFAQに戻す。消えた質問の数が投資回収

2年後、ツールの名前も画面も変わっているでしょう。それでも、聞かれた質問を原料にすること、人は検品に回ること、番号で返すことは残ります。私が自社で回し、顧問先に型ごと渡しているのはこの3つです。

「あの人に聞けば分かる」は、その人がいる間だけの仕組みです。「読めば分かる」に変える作業は、最初の10問なら半日で始められます。伴走が要る場合の顧問の役割はAI顧問とはに書きました。原料の集め方から検品の分担まで、進め方をまとめた無料の資料セットも置いてあります。