「AI用コンテキスト」とは何か（おさらい）

Part 1 でも触れた概念ですが、本記事の前提として一段詳しくします。AI用コンテキストとは、「AIに『あなたはこういう会社で、こういう仕事をしている人を支援するんですよ』と毎回伝える情報の集まり」です。具体的には次のようなテキスト群です。

• 会社の基本情報──業態、主力プロダクト、組織図、用語集
• 業務ルール──締切ルール、承認フロー、文体・トーン、機密度の扱い
• 定型タスクの手順書──議事録の整え方、提案書の構成、メールテンプレ
• 過去の意思決定ログ──なぜそのKPIにしたか、なぜその取引先を選んだか
• NGリスト──触れてはいけない取引先、書いてはいけない表現、避けるべき選択肢

これらをAIに渡せるテキストとして整備し、必要なときにAIが自動で読み込めるようにすると、毎回のプロンプトに同じ前提を貼り直す手間が消えます。さらにメンバー全員が同じ前提でAIを使えるので、出力品質のばらつきも減ります。

世界のベストプラクティス──Anthropic／Cursor／GitHub／Block／Microsoft

「自社で初めて AI コンテキスト管理を始めたい」という段階で、ゼロから設計する必要はありません。すでに先行している企業・OSSコミュニティの実装が公開されており、その共通項を抜き出すと、自社設計の下敷きになります。本セクションでは、2026年4月時点で参考にすべき5つの代表事例と、そこから抽出できる7つの普遍原則を整理します。

1. Anthropic「skills」リポジトリ──Markdownで配布する公式 Skills集

Claude を作っている Anthropic 公式の skills リポジトリは、AI コンテキストを GitHub で配布する模範例です。各 Skill は SKILL.md として独立したフォルダに収まり、フロントマター（YAML）で「いつ使うか」を宣言、本文に「どう動くか」を Markdown で書く構造。社内向けに同じ構造を Private リポジトリで再現するのが、はてなベース DX 事業部でも採用しているパターンです。

Anthropic Engineering の公式記事「Equipping agents for the real world with Agent Skills」では、「コードでなくMarkdownで知識を記述する」ことの利点と、Skills を Git でバージョン管理する設計思想が解説されています。一読する価値があります。

2. Cursor「.cursorrules / Cursor Rules」──プロジェクトごとに AI ルールを置く

AI コードエディタの Cursor は、リポジトリ直下に .cursor/rules/ ディレクトリを作って .mdc ファイルを並べるか、ルートに .cursorrules ファイルを置くことで、そのリポジトリ専用の AI ルールを定義します（公式ドキュメント「Working with Context: Rules」）。Markdown 形式で「使う技術スタック」「コーディング規約」「言語・トーン」を書くだけで、Cursor の AI が常にそれを参照するようになります。

ポイントは、個別リポジトリ単位で AI 動作を制御できることです。本記事の3階層構造で言えば「部門リポジトリ」「個別プロジェクトリポジトリ」レベルでのルール記述に相当し、リポジトリと AI コンテキストが Git の履歴を共有する設計を実現しています。

3. GitHub Copilot「Knowledge Bases」──組織のリポ群を Copilot に読ませる

GitHub Copilot Enterprise の Knowledge Bases は、「Markdown ドキュメントが含まれる GitHub リポジトリの集合体」を1つの知識ベースとして登録し、Copilot Chat にそのコンテキストを踏まえた回答をさせる機能です。Anthropic の Skills や Cursor のルールと違い、「複数リポジトリを束ねて1つの知識源として扱う」のが特徴。

これが組織として AI コンテキストを GitHub に集約する根拠になります。本記事の3階層リポジトリ（個人／部門／全社）を作っておけば、Copilot Enterprise から横断的に参照できる──という構造が、設計時点から想定されています。

4. Block（旧Square）──5,000 名規模の組織で「Goose」と AI コンテキストを運用

金融サービスの Block 社は、社内 AI エージェント「Goose」を OSS で公開しており、5,000 名超のエンジニアが日次でAIエージェントを使う運用を実現しています。Goose は MCP サーバを介してファイルや GitHub ・Linear・Slack のデータにアクセスし、業務文脈を取り込みます。Block の AI 担当 VP は、社内ドキュメントを 「AI が読みに行ける場所」に整える投資が、エージェント活用の成否を分けたと公開講演で繰り返し語っています。

つまり、AI が業務知識を活用するかどうかは、AIモデルの賢さよりも「知識がアクセス可能な形でどこにあるか」にかかっている──その「どこに」の最有力候補が、現代では GitHub だということです。

5. Microsoft & GitHub──「.github」「CODEOWNERS」「organizational templates」のレイヤード設計

Microsoft / GitHub 自身は、Organization 単位で .github リポジトリを置き、そこに Issue/PR テンプレート、コントリビューションガイド、組織標準のCLAUDE.md相当を集約します（公式ガイド「Creating a default community health file」）。これは個別リポジトリにファイルがなくても自動でフォールバック参照される仕組みで、3階層の最上位「全社」を技術的に担保する標準アプローチです。

同時に CODEOWNERS ファイルで、特定パスの変更には特定チームのレビューを必須化できます。AI コンテキストファイル（CLAUDE.md・glossary.md・style-guide.md）の更新には経営企画＋情シスの両方の承認を必須化する、といった統制をコードレベルで設計できます。

5社から抽出した7つの普遍原則

事例を並べて見えてきた、組織が AI コンテキストを GitHub で管理する際の普遍原則を整理します。自社で運用設計する際のチェックリストとして使ってください。

これらは Anthropic・Cursor・GitHub・Block・Microsoft の少なくとも2社以上が共通して採用している実装ルールです。1社の独自手法ではなく、業界として収束しつつあるベストプラクティスとして捉えてください。

3階層リポジトリ構造──個人／部門／全社

1つのリポジトリにすべて詰め込むと、機密度の異なる情報が混ざって権限管理ができません。逆にバラバラにしすぎると、参照効率が落ちます。間を取った実用解が「個人・部門・全社の3層」です。

3階層の利点は、「重要度に応じて変更頻度と承認フローを変えられる」ことです。個人は気軽に編集、部門は同僚レビューあり、全社は経営承認あり、のように段階を分けられます。

3層の関係図

[ AI（Claude / ChatGPT ）]
      ↑ 参照する
      │
┌─────┴─────────────────┐
│  個人リポジトリ           │ ← 自分しか見ない
└─────┬─────────────────┘
      │ 読み込み（含む）
      ↓
┌───────────────────────┐
│  部門リポジトリ           │ ← 同じ部門のメンバーで共有
└─────┬─────────────────┘
      │ 読み込み（含む）
      ↓
┌───────────────────────┐
│  全社リポジトリ           │ ← 全社員で共有（基本情報の正本）
└───────────────────────┘

個人リポジトリは部門リポジトリを参照（含む）、部門は全社を参照、というふうに下から上を読み込む構造にします。これでAIに渡す情報が「まず最も具体的な個人スコープ、それでも足りなければ部門、それでも足りなければ全社」の優先順位で参照されます。

CLAUDE.md と Skills の置き場

本記事の参考になる実例として、Claude を作っている Anthropic 自身の GitHub Organization を見てみましょう。「skills（公開Skills集）」「claude-code（Claude Code本体）」「claude-cookbooks（活用例）」「prompt-eng-interactive-tutorial（プロンプト学習用）」など、AI 活用に関わるリポジトリが並んでいます。

Claude Code（および互換ツール）は、CLAUDE.md というファイル名のテキストを自動で読み込みます。これがClaudeの「会社理解の本」になります。カレントディレクトリ→親ディレクトリ→ホームディレクトリの順に読み込まれるので、3階層リポジトリ構造と相性抜群です。

推奨ファイル配置

~/CLAUDE.md                              # 個人グローバル設定（個人リポからシンボリックリンク）
~/.claude/skills/                        # 個人Skills（同様）

~/work/sales-context/CLAUDE.md           # 部門の標準（営業部門）
~/work/sales-context/skills/             # 部門共通Skills

~/work/company-context/CLAUDE.md         # 全社の標準
~/work/company-context/skills/           # 全社共通Skills

ChatGPTやCursorなど他ツールも、同じリポジトリの別ファイルを読み込ませる構成にすれば共存可能です。

CLAUDE.md に書くべきこと（雛形）

# [部門/会社名] のClaudeへ

## 基本ルール
- 文体: 丁寧体（です・ます調）
- 長さ: 簡潔に。冗長な前置きは省く
- 機密: 顧客名は伏字（A社/B社）で書く

## 用語集
- ベイス = 弊社の略称。文中の登場時は「はてなベース」と表記
- ヘリ = ヘリンボーン店（取引先A社）の略称

## 業務文脈
- 主力サービスは freee/kintone のバックオフィスBPR
- 顧客は中小企業の経理・情シス
- 提案書は1ページ目に「課題・解決・効果」の3点セット

## やってはいけないこと
- 顧客の実名を文中に出す
- 推測で数字を挙げる（「約30%削減」のような）
- 顧問税理士に確認していない税務判断を出す

このファイルをまず1枚作って GitHub に置くだけで、AIの出力品質が体感で1ランク上がります。あなたの会社の流儀をAIが学習した状態でやり取りできるようになるからです。

Skills（手順書のパッケージ）

「議事録の整え方」「提案書のひな形作成」など、繰り返し使う手順はSkillsとして個別Markdownファイルに分けて保存します。Claude Code は ~/.claude/skills/ 配下のSkillsを自動で認識し、ユーザーが該当する用途で呼び出すと参照してくれます。

~/.claude/skills/
├── meeting-minutes.md       # 議事録の作成手順
├── proposal-template.md     # 提案書のテンプレ
└── monthly-report.md        # 月次レポートの組み立て

各Skillは1ファイル1機能で、上から30行以内に「何をするスキルか」「いつ使うか」「具体的な手順」を書く構造が定着しやすいです。

ChatGPT・Geminiカスタムプロンプトの管理

ChatGPT のカスタムGPT、Gemini Gem、Microsoft Copilot のプロンプトテンプレなど、各社AIには「事前にプロンプトを保存しておく仕組み」があります。これらの「中身」も同じリポジトリに集約できます。

ファイル構成例

company-context/
├── CLAUDE.md
├── prompts/
│   ├── chatgpt/
│   │   ├── proposal-writer.md     # 提案書ドラフト用GPT
│   │   ├── email-polisher.md      # 英文メール校正用GPT
│   │   └── meeting-summarizer.md  # 議事録要約GPT
│   ├── gemini/
│   │   └── data-analyzer.md       # データ分析用Gem
│   └── shared/                    # ツール非依存の共通プロンプト
│       └── company-tone.md        # 文体ガイド
└── skills/
    └── ...

各Markdownファイルには「プロンプト本体＋使い方の説明＋更新履歴」を併記します。ChatGPTのカスタムGPT管理画面に直接貼り付けることで使う運用にすると、リポジトリが正本、ChatGPTのカスタムGPTが「派生クローン」という関係になります。

プロンプトの典型構造

# 提案書ドラフト用 GPT

## 役割
あなたは中小企業向けDXコンサルの提案書ライターです。

## 入力
ユーザーが「業界」「課題」「想定予算」を渡してきます。

## 出力
1. 課題の整理（200字以内）
2. 解決策（3つ、それぞれ200字）
3. 効果（定量で2つ、定性で1つ）
4. 価格レンジ（3段階）

## 守ること
- 文体: 丁寧体
- 数字は推測でなく根拠ベース
- 顧客名は伏字（A社/B社）

## 更新履歴
- 2026-04-15 初版
- 2026-04-22 価格レンジを2段階→3段階に

更新履歴をプロンプト末尾に書いておくと、誰がどの版を使っているか分かりやすくなります。GitHubのコミット履歴で詳細は追えますが、プロンプト本体にも要約を残すのが社内運用上は楽です。

社内用語集・意思決定ログ・FAQ の作り方

AI用コンテキストの中でも、特に効果が大きいのが次の3つです。

1. 社内用語集（glossary.md）

業界用語・社内造語・略称・取引先のニックネームを集めた辞書。1行1用語のシンプルな表で十分です。

| 用語 | 正式名 | 説明 |
|---|---|---|
| ベイス | はてなベース株式会社 | 弊社の略称。文中では正式名を使う |
| ヘリ | ヘリンボーン店 | 主要取引先A社の社内呼称 |
| 月次P | 月次予算 | 経理が月初に提出する数字 |

これがあると、AIが「ベイスとは」「ヘリって何？」と聞き返す手間がゼロになります。

2. 意思決定ログ（decisions/）

「なぜその選択をしたか」を1意思決定1ファイルで残す形式。エンジニア界では ADR (Architecture Decision Record) と呼ばれる手法 ですが、業務でもそのまま使えます。

decisions/
├── 2025-09-営業先を中部地方に絞る.md
├── 2025-11-freee mcp を採用.md
└── 2026-02-社内コンテキストをGitHub集約に決定.md

各ファイルには「背景・選択肢・選んだもの・理由・代替案を選ばなかった理由」を書きます。半年後に新しいメンバーが「なんでこうなってるの？」と聞いてきたとき、このファイルを渡せば答えになります。

3. FAQ（faq.md）

社内によくある質問と回答を Q&A 形式で集めたファイル。新人オンボーディングの時間を半分にできるくらいの効果があります。

## Q. 経費精算の締切はいつ？
A. 毎月25日17:00。これを過ぎると翌月扱いになる。

## Q. 出張時の食事代はどこまで経費？
A. 1食あたり1,500円までが上限（規程3-2-4参照）。

## Q. 取引先との会食予算は？
A. 1人5,000円まで、4名以上で実施。
   それ以外は事前に部長承認が必要。

これをClaude/ChatGPTから参照させると、新人が経費精算の質問をしてもAIが正確に答えられるようになります。

機密情報の扱いと Private Repo の使い分け

AI用コンテキストには、社内文書がそのまま入ることが多いので、機密情報の管理が最大のリスクポイントになります。

入れて良い／入れてはいけない

3つの可視性レベル

GitHub Organizationでは、リポジトリの可視性を3段階で設定できます。

• Public（公開）──誰でも見られる。OSSプロジェクト用。社内ナレッジには使わない
• Internal（社内のみ）──Organization のメンバー全員が見られる。全社用コンテキストはここ
• Private（明示招待のみ）──招待された人だけ。部門用や個人用はここ

「Internal を全社用に使う」発想は、Organization アカウントを作っていないと選べない選択肢です。Part 5 でその設計を扱います。

秘密情報を誤コミットしてしまったら

パスワードやAPIキーをうっかりコミットしてしまった場合、ファイルを消すだけでは履歴に残ったままです。すぐにそのキー／パスワードを無効化し、GitHubの「Repository → Settings → Danger Zone → Delete this repository」でリポジトリごと削除して作り直すのが最も安全です。Git の履歴改変ツールもありますが、初心者には推奨しません。

参考──git CLI の最小コマンドセット

Part 2〜3 まではブラウザだけで使ってきましたが、Part 4 のような「ローカルで AI に読み込ませる」用途では、PC のターミナルから Git コマンドを叩く必要が出てきます。覚えるのは8コマンドだけで、まずこれで十分です。

# 0. Git のインストール確認（macOSは標準。Windowsは https://git-scm.com から）
git --version

# 1. リポジトリを自分のPCにダウンロード
git clone https://github.com/<org>/company-context.git

# 2. リポジトリのフォルダに移動
cd company-context

# 3. 最新の状態を取り込む（毎回作業前に）
git pull

# 4. ファイルを編集（VS Code 等で）
code CLAUDE.md

# 5. 変更をステージング（保存対象に含める）
git add CLAUDE.md

# 6. コミット（メッセージ付きで保存）
git commit -m "用語集に新語を3件追加"

# 7. リモート（GitHub）に反映
git push

# 8. ブランチを切って作業する場合
git checkout -b add-glossary-terms
# … 編集 → add → commit
git push -u origin add-glossary-terms
# その後 GitHub のブラウザで Pull Request を開く

VS Code を使えば、これらの操作を 左側のソース管理アイコンから GUI で実行できます。CLI に抵抗がある人は VS Code 経由で十分。慣れてくると、CLI のほうが速く感じる場面が増えてきます。

Claude Code から GitHub へ直接コミットさせる

Claude Code を使っている場合、AI に「リポジトリの README を更新して、コミットして push して」と指示するだけで、上記のコマンド一連を AI が代行できます。CLAUDE.md に「コミットメッセージは日本語、conventional commits 形式」のように記載しておけば、メッセージスタイルも揃います。

# Claude Code への指示例
> CLAUDE.md の用語集に「ベイス」「ヘリ」を追加して、
  fix-glossary ブランチで PR を出してください。
  コミットメッセージは「docs: 用語集 にベイス・ヘリを追加」で。

これがいま生成AI時代の業務文書管理の最前線です。Git コマンドそのものを直接打たなくても、AI に意図を伝えるだけで履歴付きの変更ができる時代になっています。

Drive・Notion から GitHub へ移行する手順

多くの組織は、すでにGoogle DriveやNotionに何らかのナレッジを持っています。これらをGitHubに移行する作業は、いきなり全部ではなく「AIで使う頻度が高いものから」順に持ってくるのが現実的です。

1. 移行対象の選定──「AIに渡したい情報」のリストアップ（社内用語集／FAQ／業務手順／意思決定ログが第一候補）
2. Markdown 化──Word・GoogleドキュメントはMarkdownに変換（Notion からは標準でMarkdownエクスポート可）
3. 機密チェック──取引先名・個人名・契約金額が含まれていないか確認、伏字化
4. リポジトリへ追加──該当リポジトリにアップロード、コミット
5. Drive側の元ファイル整理──「GitHubが正本」リンクを貼って、元ファイルは「アーカイブ」フォルダへ

移行で最も大事なのは 「正本を1つに絞る」 ことです。Drive にも GitHub にも同じファイルがあると、どちらが最新か分からなくなり、結局更新が止まります。「GitHubに移したファイルは、Driveから消すかリンクだけにする」ルールを最初から徹底してください。

Part 5 への橋渡し

本記事で示した「個人／部門／全社の3階層」「CLAUDE.md と Skillsの構造」「機密管理の原則」は、すべて個人や少人数チームでも今すぐ始められる設計です。一方で、これを20人・100人・1,000人規模で運用するには、組織レベルの権限管理・SSO・監査ログ・コスト設計が要ります。

最終回 Part 5 では、情シス・経営層向けに「組織として GitHub を導入・定着させるための設計」を扱います。Organization 管理、SAML SSO、GitHub Copilot Business、社内研修の進め方──組織導入で詰まりやすいポイントをひと通り押さえます。

本シリーズの全体像（再掲）

1. Part 1──GitHubとは何か（理論編）
2. Part 2──アカウント作成と最初のリポジトリ（個人ハンズオン）
3. Part 3──編集・履歴・チーム共有（チーム運用入門）
4. Part 4（本記事）──AI用コンテキストをGitHubで管理する実践（AI連携）
5. Part 5──組織導入と運用（情シス・経営層向け）