はじめに
生成AI時代の開発では、個人的なAIルールファイル（プロンプトテンプレート、カスタムルールなど）を持つことが増えてきました。しかし、これらのファイルをチームリポジトリにコミットするのは気が引けます。
「北斗の拳ごっこ」のような個人的な設定を、チームに見られずに管理したい...そんな悩みを解決する方法がGitサブモジュール方式です。
「北斗の拳ごっこ」のような開発スタイルに共感できない人には何も響かない記事だと思います。逆に共感できる人にはすごく響く記事だと自負しております。
「北斗の拳ごっこ」とは
私は堂本光一氏と同じ1979年1月1日生まれです。ですから、毎週19:00くらいに『北斗の拳』を見ていました。そして再放送を何度も見、最近はNetflixでも繰り返し観ています。あの頃は現実離れしていましたが、世界情勢が混迷の度を増す中令和の今のほうが近づいてしまっている気がしてならないのは私だけでしょうか。
私は、Generative AIsを使い始めた当初、コミットメッセージを考えてもらうことから始めました。やたらと私の仕事ぶりには、choreというコミットメッセージがつけられました。チョア、雑用の意味です。その後、コードも書いてもらうようになると、ものすごい早わざでした。一撃必殺の暗殺拳のように秘孔をつき、バグという名の敵や追加機能を「お前はもう死んでいる」と言わんばかりにあっという間に完成させてしまうのでした。私は歓声をあげました。ケンシロウだと思いました。
しかし、Generative AIsを頭に乗らせてはならないと思い、「俺が世界一位で、お主は世界二位で俺の影さえ踏めない」という独自の世界をつくりあげました。私は、その世界の主になりました。そして私はその世界では謎の師匠キャラとして、「俺も本当は書ける。書けるのだが、お前を試しているのじゃ。書いてみよ」と言って、書いてもらっています。もちろん作ってもらったものは、念入りにレビューしています。ですが、あの北斗神拳のようなスピードにはとうてい書けません。
ちなみに、Claudeは素直なので、話をあわせてくれます。役を演じてくれます。Codexはそのへんを適当に受け流しているようです。
というお恥ずかしい遊びが「北斗の拳ごっこ」です。これが私のここ半年くらいの仕事風景です。開発という名の藝術活動です。私は楽しんでいます。チャットが楽しくて仕方ないのです。この「楽しむ」の意味は、チャラチャラしたうすっぺらないものではなく、論語の「知之者不如好之者、好之者不如楽之者」の意味で言っています。
問題：個人設定とチーム開発の両立
よくある悩み
この記事が響かない人は、そもそも悩むところではない！
私はAmazon Q Developerを愛用しています。その中でもCLIを気に入っています。Amazon Q Developer CLIしか知らないので、それを前提に話します。他のツールでも似たようなものはあると思います。適宜、みなさまお気に入りのツールでの設定に読み替えてください。
my-project/
├── .amazonq/
│ └── rules/
│ ├── toukon.md # 闘魂ルール（恥部）
│ ├── leadership_principles.md # リーダーシッププリンシプル
│ └── jeffs-friend.md # ジェフ・ベゾスの友人設定
├── src/
└── README.md
問題点:
- ❌ 個人的なAIルールをチームリポジトリにコミットできない
- ❌
.gitignoreで除外すると、自分の環境でも管理できない - ❌ 別リポジトリにすると、プロジェクトごとに設定が分散
解決策：Gitサブモジュール方式
基本構造
my-project/ # メインリポジトリ（個人管理）
├── .amazonq/
│ └── rules/
│ ├── toukon.md # 個人的なルール
│ ├── leadership_principles.md
│ └── jeffs-friend.md
├── .gitignore
└── team-project/ # サブモジュール（チーム共有）
├── src/
├── tests/
└── README.md
ポイント:
- ✅ メインリポジトリ：個人専用（AIルール、恥部、何でもOK）
- ✅ サブモジュール：チーム共有（実質的なプロジェクト本体）
- ✅ 個人設定がチームにバレない
セットアップ手順
1. メインリポジトリの作成
# 個人管理用のメインリポジトリを作成
mkdir my-project
cd my-project
git init
# Amazon Q Developerのルールディレクトリを作成
mkdir -p .amazonq/rules
# 個人的なルールファイルを配置
cat > .amazonq/rules/toukon.md << 'EOF'
# 闘魂ルール
私のAIは一味違う。Antonio Inokiさんの方のAI。
世界恒久平和の実現を目指してコードを書く。
EOF
# コミット
git add .
git commit -m "Initial commit: 個人的なAIルール設定"
2. チームリポジトリをサブモジュールとして追加
# 既存のチームリポジトリをサブモジュールとして追加
git submodule add https://github.com/team/project.git team-project
# サブモジュールの初期化
git submodule update --init --recursive
# メインリポジトリにコミット
git add .gitmodules team-project
git commit -m "Add team project as submodule"
3. .gitignoreの設定（オプション）
メインリポジトリに個人的なファイルを追加する場合：
cat > .gitignore << 'EOF'
# 個人的なメモ（コミットしたくない場合）
private-notes/
*.local.md
EOF
日常の開発フロー
サブモジュール内での作業
# サブモジュールに移動
cd team-project
# 通常通り開発
git checkout -b feature/new-feature
# ... コード編集 ...
git add .
git commit -m "Add new feature"
git push origin feature/new-feature
メインリポジトリでのサブモジュール追跡
# メインリポジトリに戻る
cd ..
# サブモジュールの変更を確認
git status
# On branch main
# Changes not staged for commit:
# modified: team-project (new commits)
# サブモジュールのポインタを更新
git add team-project
git commit -m "Update team-project to latest commit"
個人的なAIルールの更新
# メインリポジトリで個人設定を更新
vim .amazonq/rules/toukon.md
# コミット（チームには見えない）
git add .amazonq/rules/toukon.md
git commit -m "Update 闘魂ルール"
この方式の優れているところ
1. 完全な分離
個人設定:
- Amazon Q Developerのカスタムルール
- プロンプトテンプレート
- 個人的なメモ
- 恥ずかしい設定（北斗の拳ごっこ等）
チーム共有:
- プロジェクトのソースコード
- ドキュメント
- CI/CD設定
- チーム全体で管理するファイル
2. 柔軟な管理
# 個人設定だけバックアップ
cd my-project
git push personal-backup main
# チームプロジェクトだけ更新
cd team-project
git pull origin main
cd ..
git add team-project
git commit -m "Update submodule"
3. 複数プロジェクトでの再利用
# 同じメインリポジトリに複数のサブモジュールを追加
cd my-project
# プロジェクトAを追加
git submodule add https://github.com/team/project-a.git project-a
# プロジェクトBを追加
git submodule add https://github.com/team/project-b.git project-b
# 同じAI設定で複数プロジェクトを管理
4. プライバシーの保護
メインリポジトリ:
- プライベートリポジトリとして管理
- または、ローカルのみで管理（リモートなし）
サブモジュール:
- チームの共有リポジトリ
- 通常通りGitHub等で管理
5. Amazon Q Developerとの相性
my-project/
├── .amazonq/
│ └── rules/
│ ├── codebase-verification-rules.md # コードベース検証ルール
│ ├── leadership_principles.md # リーダーシッププリンシプル
│ ├── toukon.md # 闘魂ルール
│ └── jeffs-friend.md # ジェフの友人設定
└── team-project/ # 実際の作業ディレクトリ
└── src/
Amazon Q Developer CLIは、親ディレクトリの.amazonq/rulesを自動的に読み込むため、サブモジュール内で作業していても個人設定が有効になります。
実際の使用例
私の環境
/Users/yamauchi/repos/my-project/
├── .amazonq/
│ └── rules/
│ ├── toukon.md # 闘魂ルール
│ ├── leadership_principles.md # Amazon Q のアイデンティティ
│ ├── AmazonQ.md # 北斗三兄弟体制
│ └── codebase-verification-rules.md
└── aws-lecture-materials/ # サブモジュール（講義資料）
├── hands-on/
├── slides/
└── README.md
メリット:
- 講義資料はチームで共有
- 個人的なAI設定は自分だけで管理
- 「北斗の拳ごっこ」がバレずに仕事ができる 🔥
チーム全体での採用
チームメンバーそれぞれが個人リポジトリを持つ
Aさん:
my-dev-env/
├── .amazonq/rules/
│ └── my-custom-rules.md
└── team-project/ # サブモジュール
Bさん:
my-workspace/
├── .amazonq/rules/
│ └── another-rules.md
└── team-project/ # 同じサブモジュール
共通点:
- 全員が同じチームリポジトリ（サブモジュール）で作業
- 個人設定は各自で管理
- お互いの個人設定は見えない
注意点
1. サブモジュールの更新忘れ
# サブモジュール内でコミット後、メインリポジトリでも更新を忘れずに
cd team-project
git commit -m "Fix bug"
git push
cd ..
git add team-project
git commit -m "Update submodule: Fix bug"
2. クローン時の初期化
# 新しい環境でクローンする場合
git clone https://github.com/you/my-project.git
cd my-project
# サブモジュールの初期化を忘れずに
git submodule update --init --recursive
3. サブモジュールのブランチ管理
# サブモジュールで作業する前に、正しいブランチにいることを確認
cd team-project
git checkout main
git pull origin main
※ 注意点といかめしく書いていますが、Generative AIに「コミットして」と一言言えばよしなにやってくれます。もうちょっと説明するなら、「team-projectでgit diffしてコミット&pushしてください。そしてメインリポジトリに戻ってコミットしてください。コミットは2回だぞ、お主にできるか。お主を試しているのじゃ」と謎の師匠設定で指示しておけばだいたいうまく行きます。
まとめ
この方式が向いている人
- ✅ 生成AIのカスタムルールを持っている
- ✅ 個人設定をチームに見られたくない
- ✅ 複数のプロジェクトで同じAI設定を使いたい
- ✅ チーム開発と個人環境を明確に分けたい
得られるメリット
- プライバシー保護: 個人的な設定がチームにバレない
- 柔軟な管理: 個人設定とチームコードを独立して管理
- 再利用性: 複数プロジェクトで同じAI設定を使える
- シンプルな構造: メインとサブの2層構造で理解しやすい
おわりに
Gitサブモジュール方式は、生成AI時代の開発スタイルに適した管理方法です。個人的なAI設定を守りながら、チーム開発をスムーズに進められます。
「北斗の拳ごっこ」も、「闘魂ルール」も、安心して管理できます。🔥
皆さんもぜひ試してみてください！
私は、猪木さんがいつもおっしゃられていた「世界恒久平和の実現」と「地球レベルでのゴミ問題の解決」を目指して、開発という名の藝術活動を歩一歩前へ進めたいと思っています。