GitHubリポジトリをAIの記憶領域として使う

最近の AI 活用で起きている変化は、チャットの答えがうまくなったことだけではありません。価値の中心が「答えを返すこと」から「必要な文脈を踏まえて仕事を進めること」へ移りつつあります。Anthropic が prompt そのものより context engineering を前面に出しているのも、その流れをよく表しています¹。

この変化は、まず開発の現場で目立つようになりました。最近のコーディングエージェントは、リポジトリ全体を一度に入力へ詰め込まなくても、必要なファイルを探し、読み足しながら大きなコードベースで作業を進められます。Anthropic の公開事例でも、大きく複雑なコードベースから関連ファイルを見つけ、必要な文脈を集める負担を減らしながら作業できることが強調されています²。つまり「コンテキストウィンドウを超えるリポジトリを丸ごと読める」という話ではなく、必要な部分を段階的に集めながら動けるようになってきた、ということです。

ここで重要なのは、この能力がコーディング以外にも広がり始めていることです。実務を分解すると、資料を読み、既存ファイルを更新し、手順に沿って処理し、結果を残す作業は開発以外にも多くあります。Anthropic の公開事例では、非技術の Growth Marketing チームが Claude Code で反復的なマーケティング業務や簡易な記憶の仕組みを作っています²。コーディングエージェントの発想は、すでに一般業務にも入り始めています。

ただし、ツールが揃ってきたことと、チームで使える共有記憶ができたことは別です。セッションをまたいで共有でき、しかも後から人間が監査できる記憶をどこに置くかは、まだ設計課題として残っています。

その有力な解の一つが、GitHub リポジトリを AI の記憶領域として使う考え方です。この記事では、なぜその発想が必要なのか、何を置くべきか、そこからどんな価値が生まれるのかを整理します。

要点

いま起きている変化は、モデルがただ賢くなったというより、AI をうまく働かせるための文脈設計と共有の重要性が上がったことです。Anthropic はそれを context engineering と呼び、GitHub Copilot と Claude Code も、memory や指示ファイルの仕組みで同じ問題を扱っています¹³⁴。

ただし、その場でうまく働けることが、そのまま共有記憶になるわけではありません。GitHub も stateless な AI の限界を率直に説明しており³、Claude Code の auto memory も machine-local です⁴。そのため、CLAUDE.md や custom instructions file のような指示ファイル、docs、ADR、issue、PR といった リポジトリ内の人間可読な資産を共有記憶として扱う流れが強まっています。

この構成の価値は、AI が何かを覚えることそのものより、人間と AI が同じ記憶を見て、同じ差分で更新できることにあります。GitHub 上に残せば、レビュー、履歴、責任分界、ロールバックまでまとめて扱えます。

AI活用が広がっても、記憶はまだ別問題

まず押さえたいのは、AI 活用で問われることが、モデルの賢さだけではなくなっている点です。Anthropic は、エージェント構築において prompt engineering より広い文脈で context engineering を論じています¹。

こうした変化は、もともとコーディング AI の進化の中で目立ってきました。ただ、日々の業務の多くも、結局は「既存の情報を読み、必要な変更を加え、確認し、残す」の繰り返しです。議事メモの整理、手順書の更新、社内ナレッジの追記、問い合わせ対応の下調べなどは、その典型です。そう考えると、ファイルや文書をまたいで作業を進められる AI が、開発以外の現場でも価値を持ち始めているのは自然です。

問題はその先にあります。次回も同じ前提で動けるか。別のメンバーが同じ AI を使っても、同じ判断基準にたどり着けるか。 GitHub Copilot Memory の説明は、この点を正面から扱っています。stateless な AI は、別のやり取りになるとコードベースへの理解を保持できないため、毎回同じ説明を prompt に書くか、custom instructions file を保守する必要がある、という説明です³。

ここで重要なのは、コンテキスト長の増加と共有記憶の成立は同じ話ではない、ということです。コンテキスト長が伸びれば「その場で渡せる量」は増えますが、同じ判断基準を、誰でも、監査可能な形で再利用できるかまでは保証しません。だからこそ、記憶をどこに置くかが設計上の課題になります。そこで有力になるのが、前提知識をリポジトリ内の人間可読なファイルとして残すやり方です。

リポジトリを記憶にすると、共有と監査がしやすい

リポジトリを記憶層にする価値は、単に永続化できることではありません。diff と review が効く形で前提を共有できることです。hidden prompt や SaaS 側の見えない設定に知識を閉じ込めると、チームメンバーは「AI が何を前提に動いたか」を確認しづらくなります。リポジトリに置けば、誰がいつ何を足したか、どの branch で前提が変わったか、間違っていたらどこへ戻すかを Git の流儀で扱えます。

もう一つ大きいのは、ツールが変わっても持ち運びやすいことです。Claude Code は CLAUDE.md を persistent instructions として扱い⁴、GitHub Copilot も、毎回同じ説明を prompt に書く代わりに custom instructions file を保守する必要を説明しています³。つまり、中心をリポジトリ内の人間可読な指示ファイルに置く構成は、特定ベンダーの画面設定に閉じにくいということです。

さらに、作業単位ごとに前提を分けて管理しやすいのも実務では便利です。ある作業の期間だけ必要な前提や、特定ディレクトリだけで有効な注意事項を、実際の変更と同じ単位で残せます。人間のレビューと相性が良いのも、この構成の強みです。

リポジトリに置くべき記憶と、置かないほうがよい記憶

実務で迷いやすいのは、どこへ何を置くかです。ここでは、実際の運用で使いやすい形にまとめます。

リポジトリに置くべきなのは、毎回必要だが、毎回手で説明したくない知識です。

• ルートの指示ファイルには、ビルド方法、テスト手順、レビュー観点、禁止事項のような「最初に守る前提」を置く
• docs/ や MDX には、設計判断、runbook、用語集、業務フロー、FAQ のような長文知識を置く
• issue / PR / commit は、最終決定に至る経緯をたどるための「判断の履歴」として使う

逆に、リポジトリに置かないほうがよいものもあります。

• 秘密情報や強いアクセス制御が必要な情報
• 秒単位で変わる運用ステータスや一時データ
• 個人だけが覚えていればよいメモや、未整理の思いつき

要するに、リポジトリは「長く共有したい前提」を置く場所であって、何でも入れる箱ではありません。特に重要なのは、ルートの指示ファイルを何でも入れる倉庫にしないことです。Claude Code は CLAUDE.md を全文読みますが、短いほうが従いやすいとも説明しています⁴。トップには「守るべき規律」と「読むべき場所への入口」だけを書き、詳しい説明は別ファイルへ逃がすのが自然です。薄い index と深い docs を分けるほうが、AI にも人間にも読みやすくなります。

同じ理由で、毎回必要ではないが繰り返し使う作業手順は、ルートの指示ファイルとは分けて管理したほうが扱いやすいです。ルートの指示ファイル、詳細な docs、個別の手順書の役割を分けておくと、リポジトリ全体の見通しがよくなります。

Markdownベースの知識管理は、人間にも効く

ここで次に問われるのは、その知識を人間にとっても見やすくできるかです。リポジトリを記憶にする発想は、AI だけに効くわけではありません。Markdown や MDX で蓄えた知識を、人間向けのドキュメントサイトやナレッジベースとして見せられるなら、AI のために整えた情報がそのまま人間向けの基盤にもなります。Fumadocs は、そうした見せ方を実現する手段の一例です⁵。大事なのは、リポジトリに蓄えた知識を人間も確認しやすい形で見せられることです。

これは副作用ではなく、本質的な利点です。AI のために増やした知識が、そのまま人間のオンボーディング、レビュー、問い合わせ対応にも効くからです。見えない prompt に知識を閉じ込める構成では、人間が追随できません。リポジトリとドキュメントサイトを組み合わせれば、AI の共通記憶を整えるほど、人間の確認コストも下がるという良い循環を作れます。

大事なのは、前提と結果が残ること

ここまでが「何を残すか」の話なら、次は「どう動かすか」です。リポジトリ中心の仕事では、MCP や Skills を整備しなくても、まずは CLI ツールを使わせるだけで十分進む場面が多くあります。既にあるファイル、コマンド、履歴をそのまま扱えるぶん、CLI 中心のほうが素直に動くこともあるからです。

もちろん、リポジトリの外へ機能を広げたいなら MCP や Skills を足せます。外部サービスへの接続が必要なら MCP、繰り返し使う手順をまとめたいなら Skills、既存の環境をそのまま操作したいなら CLI という分け方で考えると迷いにくいです。

haya株式会社での実践

この考え方は抽象論だけではありません。haya株式会社でも、Claude Code、GitHub リポジトリ、Markdown ベースの知識管理を組み合わせた AI エージェント運用を実際に回しています。方針はシンプルで、共有したい判断基準や手順はリポジトリに残し、人間も読みやすい形で可視化し、Claude Code でその共通の情報源を直接読ませて実行するというものです。

この構成にすると、毎回同じ前提を説明し直す回数が減り、AI が何を根拠に動いたかもリポジトリ上で追えます。hidden prompt に閉じず、pull request と同じやり方で改善できるため、個人のノウハウで終わりにくいのが強みです。

OpenClaw 導入支援 では、この考え方をバックオフィス業務へ導入しやすい形に整理しています。会話や依頼をタスク、Wiki、次アクションに変え、既存業務ツールの更新へつなぐ流れを、実運用に合わせて形にしています。各社向けの個別実装は、AIエージェント実装 で説明しているとおり、Slack、GitHub、Notion など既存ツールを前提にカスタマイズして提供しています。対象業務が具体化している場合は、お問い合わせ からご相談ください。

まとめ

AI エージェントで問われるのは、もう「ツールを使えるか」だけではありません。そこはかなり整ってきました。次に問われるのは、何を共有記憶として残し、誰がそれを更新し、どこまで監査できるかです。

その意味で、GitHub リポジトリは有力な記憶層です。CLAUDE.md や custom instructions file のような指示ファイル、docs、issue、PR、commit history を、AI だけのためではなく人間も読む前提で整える。さらに Markdown ベースの docs ツールで可視化する。この方向は、各社の公式ドキュメントを読み比べても筋が通っています。

記憶をリポジトリに寄せると、AI が少し賢くなるというより、チームとして AI を扱いやすくなる。そこに一番大きな価値があります。

参考文献

Footnotes

1. Anthropic Engineering: Effective context engineering for AI agents ↩ ↩² ↩³

2. Anthropic case study: How Anthropic teams use Claude Code (PDF) ↩ ↩²

3. GitHub Docs: About agentic memory for GitHub Copilot ↩ ↩² ↩³ ↩⁴

4. Claude Code Docs: How Claude remembers your project ↩ ↩² ↩³ ↩⁴

5. Fumadocs Docs: MDX Getting Started ↩