こんな悩み、ありませんか
ChatGPTやClaudeに自分のGitHubリポジトリを読み込ませようとして、「ファイルが多すぎて肝心な部分を見てくれない」「毎回コンテキストを説明するのが面倒」と感じたことはないでしょうか。特に副業や個人開発でリポジトリが育ってくると、AIにうまく全体像を伝える工夫が必要になってきます。
よく候補に挙がるのが「階層構造+index.md」と「Obsidian形式」の2パターンです。どちらもドキュメントの整理方法としては王道ですが、AIに読ませることを前提にすると、それぞれ得意・不得意が分かれます。
この記事でできるようになること
この記事では、両方の形式を実際に自分のリポジトリで組んでみた上での比較と、それぞれの実装手順を紹介します。読み終える頃には、自分のプロジェクトにどちらが向いているか判断でき、今日中に手を動かして整理し始められる状態になります。
ポイント:どちらか一方が絶対的に優れているわけではなく、リポジトリの規模と用途によって向き不向きが分かれます。
ステップ1:階層構造+index.mdを準備する
この方式は、フォルダごとにindex.mdを置き、そのフォルダに何が入っているか・どのファイルを読めばいいかを箇条書きで案内する形です。README.mdをルートに置くのと同じ発想を、サブフォルダにも展開するイメージです。
/docs
index.md ← docs全体の目次
/api
index.md ← APIドキュメントの目次
endpoints.md
/guide
index.md
setup.md
各index.mdには、そのフォルダの役割と、優先して読むべきファイルの順序を書いておきます。AIに「このリポジトリの構成を教えて」と聞かれたときに、ルートのindex.mdから順にたどれば全体像がつかめる状態を作るのが目的です。
正直なところ、既存のリポジトリに後からこれを当てはめるのは地味に手間がかかります。フォルダが10個あれば10個分のindex.mdを書く必要があり、最初の1〜2時間は「本当に効果あるのか」と半信半疑になるかもしれません。ただ、一度整えてしまえば以降のAIへの指示が驚くほど短くて済むようになります。
ステップ2:Obsidian形式でリポジトリを整理する
もう一方のObsidian形式は、各Markdownファイルの先頭にフロントマター(タグや作成日などのメタ情報)を付け、関連するファイル同士を[[ファイル名]]のようなリンク記法でつなぐスタイルです。Obsidianというノートアプリでよく使われる書き方をそのままリポジトリのドキュメントに持ち込む形になります。
---
title: 認証処理の仕様
tags: [auth, backend]
---
このファイルは [[api-overview]] と連携しています。
この方式のメリットは、ファイル同士の「つながり」を明示できる点です。階層構造だけでは表現しづらい、複数フォルダをまたいだ関連性をリンクで補足できます。個人的には、機能同士が複雑に絡み合っているプロジェクトではこちらのほうが情報の抜け漏れが少ないと感じています。
一方で、AIがリンク記法をどこまで正確にたどってくれるかはツールやモデルの読み込み方に依存する部分があり、この点は使う環境ごとに実際に試して確認するのが確実です。
Obsidian形式のナレッジ管理について、より詳しい運用方法はこちら → ObsidianはAIの記憶保管には向いていない?AIと連携させないナレッジ管理の運用方法
ステップ3:速さ・コスト・正確性の視点で見比べる
実際に両方を試してみると、傾向として次のような違いが見えてきます。
- 読み込みの速さ:index.mdで目次を用意しておくと、AIが読むべきファイルを先に絞り込めるため、無関係なファイルを開かせる手間が減ります。
- コスト(トークン消費):階層構造+index.mdは目次だけを先に渡せるので、最初の指示に含めるテキスト量を抑えやすい傾向があります。Obsidian形式はリンクをたどるために複数ファイルを開かせる場面が増え、結果的にやり取りが長くなることがあります。
- 正確性:関連性の網羅という点ではObsidian形式のリンクが役立つ場面もありますが、単純に「このリポジトリは何をするものか」を素早く把握させたいなら、index.mdによる案内のほうが迷いにくいと感じます。
目的が「全体像を素早くつかませる」ことなら階層構造+index.md、「ファイル間の関連性を丁寧に伝えたい」ならObsidian形式、という使い分けが現実的です。
両方を併用する手もあります。ルート直下はindex.mdで目次を整理し、複雑に関連し合う機能群だけをObsidian形式のリンクで補足する、というハイブリッド運用は個人的に使い勝手が良かったやり方です。
AIへの情報構造化についての実践例をさらに学べます → 有名エンジニアの .claude/skills 公開ラッシュから学ぶ、良い Claude Code Skills の書き方
つまずきやすいポイントと対処
最初に戸惑いやすいのが、「どこまで細かくindex.mdを分けるか」という粒度の問題です。フォルダひとつひとつに作りすぎると管理が煩雑になり、逆にまとめすぎるとAIが目的のファイルを見つけにくくなります。まずはルートと主要な機能フォルダだけに置いてみて、様子を見ながら増やしていくのがおすすめです。
もう一つ注意したいのが、[[Wikilink]]記法をGitHub上でそのまま使うと、GitHubの標準Markdownビューアーではリンクとして機能しないという点です。Obsidian上での見た目とGitHub上での見た目が違ってくるので、リポジトリを人にも見せる予定がある場合は、通常の相対パスリンクと併記しておくと安心です。
フロントマターの書式やタグの付け方がリポジトリ内で統一されていないと、AIが情報を拾う際にばらつきが出やすくなります。最初にテンプレートを1つ決めて、全ファイルで統一することを心がけてください。
完璧な整理を最初から目指さず、まずは主要ファイルだけ整えて運用しながら調整していくのが現実的です。
まとめ
「階層構造+index.md」と「Obsidian形式」は、どちらもAIにリポジトリを認識させるための有効な整理方法ですが、目的によって向き不向きが分かれます。全体像を素早くつかませたいなら前者、ファイル間のつながりを丁寧に伝えたいなら後者、というのがひとつの目安になるのではないでしょうか。まずはルート直下のindex.mdだけでも整えてみて、AIの反応を見ながら自分のリポジトリに合った形を探ってみてください。
AIサブスクの月額がかさんできたら
複数のAIサービスを1つの契約にまとめて、コストを抑えながら使い倒す選択肢もあります。



コメント