社内マニュアル、ありますか？
「ある」と即答できる会社でも、聞いていくと
- 一番詳しいベテランしか作れない、書く時間がないので半年に1回しか更新されない
- どこにあるか聞かれて、誰も即答できない
- Excel の特定のシートの、隠しシートの中に書いてある秘伝のメモがある
- マニュアルにない手順が辞めた人の頭の中にあって、退職とともに失われた
このあたりが出てくることが多いです。
社内 Wiki や社内ポータルサイトを立てる、というのは正攻法ではあります。ただ、6〜20名くらいの中小企業でこれを真面目にやろうとすると、ツール選定・運用ルール策定・編集者アサイン、と道具を入れる以前のコストが膨らみがちです。結局 Excel と口頭伝承に戻ります。
Google Workspace を全社で使っているなら、もう少し軽い解き方があります。Gemini の Gem 機能を2つ作って配るだけで、ポータルサイトを立てずに「マニュアルを育てる」「マニュアルを引く」の両方を回せます。
Gem とは: Gemini の中で作れるカスタム指示付きのチャット相手、くらいの理解で大丈夫です。ChatGPT の GPTs にあたるものを想像してもらえれば近いです。Google Workspace の Business / Enterprise プランで利用できます。
全体像：作るのは2つの Gem だけ
| Gem | 役割 | 入力 | 出力 |
|---|---|---|---|
| マニュアル作成 Gem | 業務手順を質問形式でヒアリングし、マニュアルを作る | 担当者の口頭/タイピング回答 | Google Docs のマニュアル原稿 |
| マニュアル参照 Gem | 既存マニュアルを参照して質問に答える | 社員の自然文の質問 | マニュアル該当箇所の引用 + 回答 |
この2つを全社員に配布し、保管場所として Drive 内に1フォルダ用意するだけ。新しいツール導入はゼロです。
マニュアル作成 Gem の設計
属人化したマニュアルが書かれない一番の理由は、「マニュアルを書くこと自体が属人的に大変だから」です。ベテランほど業務時間を取られていて、まとまった時間がないと書けません。
これを質問に答えるだけにするのが、この Gem の役割です。system instruction の要点は3つ。インタビュー形式に振る舞いを固定する（1問ずつ聞く）。回答が抽象的すぎたら掘り下げる（「どの画面で、どの項目を」と具体化を促す）。最後に Google Docs に出力できる形式でまとめる（見出し・手順・例外処理の構造）。
system instruction はだいたい1ページ分の文章になります。骨子だけ書くとこんなイメージです。
あなたは業務マニュアル作成のインタビュアーです。
ユーザーは社内のベテランで、自分の業務を文章化したいが、
何から書けばいいか分からない状態にあります。
以下の流れでインタビューしてください:
1. 業務名と目的を1問で確認
2. トリガー（いつ始まるか）を確認
3. 手順を1ステップずつ聞く。1問につき1ステップだけ
4. 各ステップで、「具体的にどの画面・どのボタン・どの数値を見るか」を掘り下げる
5. 例外（イレギュラー対応）があるかを最後に確認
6. すべての回答が揃ったら、Google Docs に貼れる形式で整形し、
コードブロックで出力
ユーザーの回答が抽象的な場合は、「新人がこれを読んで実行できますか」
を判断基準に、具体化を促す追加質問をしてください。
担当者は Gemini を開いてこの Gem を選び、聞かれたことに答えていくだけでマニュアルの初稿が手元に揃います。「時間がない」という定番の言い訳が通用しなくなります。
出力された Markdown / リッチテキストを Google Docs に貼り、Drive 内の決まったフォルダ（例: /社内マニュアル/）に置きます。ファイル名は 業務名_v日付 のような単純なルールで十分です。
マニュアル参照 Gem の設計
マニュアルが揃っても、必要なときに引けないと意味がありません。社員が自然文で質問すると、該当する Docs の中身を引いて答えてくれるのが、もう1つの Gem の役割です。Gem の設定画面で「ナレッジ」として /社内マニュアル/ フォルダを指定するだけで、そのフォルダ内の Docs を参照対象として扱うようになります。
ここで重要なのはハルシネーション（事実に基づかない回答）を抑えることです。独自解釈で回答すると、社員はそれを「正式な手順」として受け取ってしまいます。system instruction でルールを固めておきます。
あなたは社内マニュアルの参照アシスタントです。
ナレッジに登録されたマニュアル Docs のみを情報源として回答してください。
ルール:
1. 質問に該当するマニュアル箇所を引用してから回答すること
2. マニュアルに記載がない場合は、「該当するマニュアルは見つかりませんでした。
担当者に確認してください」と返し、推測で補わないこと
3. 古い情報の可能性がある場合は、Docs の最終更新日を併記すること
4. 「マニュアルを更新したほうがいい箇所」を感じたら、回答の末尾に
「[マニュアル改善提案] ...」として書き添えてよい
「最終更新日を併記」は地味ですが効きます。社員が「これは2年前のマニュアルだから一応確認しよう」と判断できるためです。「マニュアル改善提案」は、参照 Gem をマニュアル更新のフィードバックループに組み込む工夫です。
全社員への配布
Google Workspace の組織内で Gem を共有設定にすれば、全社員が Gemini を開いたとき「組織で共有された Gem」として出てきます。配布作業はこれで終わりです（朝礼で案内するだけ）。
ポータルサイトを立てる場合と違い、新しい URL を覚えてもらう必要も、ログイン方法を案内する必要もありません。社員はすでに毎日 Gmail と Docs を開いているので、その同じ画面内でマニュアルが引ける状態になります。
気をつけたい点も3つ。ハルシネーション対策として system instruction で「推測禁止」を強く書き、社員にも「最終判断は人間」を周知します。更新責任者は人間なので、「改善提案」を週1で見る担当を決めましょう。機微情報（給与計算など）は別フォルダにして Drive の権限で絞ります。
ポータルサイトを立てるよりこちらが優れる3点
| 観点 | ポータルサイト | この Gem 構成 |
|---|---|---|
| 検索 UI | 専用検索を実装または導入 | チャットがそのまま検索 |
| マニュアル更新 | サイトに合わせた形式変換 | Google Docs の編集のみ |
| 利用導線 | 別ドメインの URL を覚える | 既存の Gemini / Chat 内 |
導入後3ヶ月でやめても困らない、というのも地味な利点です。Docs 自体は Drive にそのまま残るので、別のツールに乗り換えるときの移行コストが小さい。
このやり方は、Google Workspace の Business Standard 以上のプランで Gemini が利用可能なことが前提です。契約状況は管理画面で確認してください。Workspace 未契約でも Gemini 単体のプランで Gem は使えますが、「Drive フォルダの自動参照」の挙動が異なります。
まとめ
- 中小企業の社内マニュアル属人化は、ツールを増やすより 書く側と読む側のハードルを Gem で下げる のが現実的
- マニュアル作成 Gem（インタビュー型）とマニュアル参照 Gem（ナレッジ参照型）の2つを Workspace 全社員に配布するだけ
- ポータルサイトを立てる場合と違い、UI 学習コストがゼロで、やめるときの移行コストも小さい
「なぜ Gemini を勧めたのか」は別記事に書きました。
スモールスタートDX で、社内ナレッジの属人化解消を段階的に進める支援をしています。
