SynologyにGiteaを入れたらAPIキーごとpushしてた話

CLAUDE.mdやMEMORY.mdとか、Claude Code（AIコーディングツール）の設定ファイルを作業してこうしたいなと思う時に編集・追記したりしてるんですけど、分量とか設定とかが結構な量になってきてまして。

文字が多くなればなるほど、「あれ、あの設定どこだったっけ」「いつからこの書き方に変えたんだっけ」って気になる瞬間が増えてくるんですよね。そこでいつでも戻したり、見返したり、またはCLAUDE君に聞いて振り返れるようバージョン管理、欲しいなと。

おそらく一番多いのってGitHubのプライベートリポジトリを使うパターンで、スーツマンも仕事のプロジェクトはGithub のプライベートリポジトリ使ってますので、それでもいいかなと思ってます。

でも我が家にはSynologyのNASがあるので、どうせならインターネットに一切出ない、完全ローカルのGitサーバーを自分で持ってみたいなと思いまして。

いろいろ調べてみると・・・

出てきたのがGitea（GitHub風の見た目を自分のサーバーに立てられるGitホスティングソフト）でした。

結論から言うと、動くところまでは思ったよりあっさりいきました。でも事故は動いた後に起きたんです。

パッケージ版とDocker版、なにがどうちがうのか

Synologyのパッケージセンターを開いたら、Giteaが普通にあったんですよ。え、じゃあこれでいいじゃんと一瞬迷いました。

でも今回はあえてContainer Manager（Docker）版で進めることにしました。

とりあえず動かしたいだけならパッケージ版で全然いいと思います。ただ今回は「将来、他のNASやサーバーに引っ越すかもしれない」という気持ちがちょっとあったので、Docker版を選びました。

「Container Manager」って結局Dockerのことだった

ネットの記事を調べてたら「Dockerのプロジェクトでやりましょう」ってよく出てくるんですよ。

Dockerってなんだろう・・・それも別でインストールしなきゃいけないの？

実はContainer Manager＝Dockerそのものでした。SynologyがDockerのことをContainer Managerって呼んでるだけで、追加インストールは不要だったんです。

これがSynologyのパッケージセンターでインストールできるContainer Managerですね。通称Dockerといわれてるものです。

docker-compose.yamlをペーストするだけ

Container Manager → プロジェクト → 作成、と進むと「ソース」の選択肢が出てきます。ここで「Create docker-compose.yml」を選ぶのが正解でした。

version: "3"

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    ports:
      - "3000:3000"
      - "222:22"
    volumes:
      - /volume1/docker/gitea:/data
    environment:
      - USER_UID=1000
      - USER_GID=1000

これをそのままペーストして次へ進みます。案外あっけないもんだなと思いました。

「Web portal settings」でちょっとドキッとした

YAMLの次に「Web portal settings」という画面が出てきて、ポータル設定？何か設定しなきゃいけないのかなとドキッとしました。

でもこれ、リバースプロキシ（独自ドメインでアクセスできるようにする設定）の話で、今回は不要でした。http://SynologyのIP:3000で直接アクセスするだけなら、何も入力せずスキップしてOKです。

初期設定画面のBase URLはそのままでいい

ブラウザでhttp://[TailscaleのIP]:3000にアクセスすると初期設定画面が出てきました。「Gitea Base URL」という項目に、TailscaleのIPアドレスが自動で入ってたんですけど、これはそのままでOKでした。ローカルIPでもTailscaleのIPでも、どっちでも動くみたいです。

あ、ちなみにTailscale（自宅のNASに外からでも安全にアクセスできるようにするVPNサービス）を入れてるので、外出先からでもこのGiteaに繋げます。

このTailscaleもかなり便利で外出先からでもがんがん自宅NASにつなげたり、CLAUDEとNASつなげても外出先でノンストレスでうごきます。

iPhoneにもアプリ入れて同じアカウントでログインするだけでおなじネットワークに繋がって、Obsidianも同期問題に全く困らず、PCとiPhoneのObsidian のmdファイルの同期も楽々という・・またここも記事にしたいところです。

VSCodeのソース管理からpushしたかったのに、隠しフォルダで詰まる

Gitの操作を毎回ターミナルでやるのが面倒だったので、VSCodeのソース管理GUIから操作したくなったんですよ。

でも.claudeってドットから始まる隠しフォルダじゃないですか。VSCodeの「フォルダーを開く」からだと隠しフォルダが表示されないし、FinderでCmd+Shift+Gから開いても中身は見えるのに親フォルダが選択できない。あれ、これどうやって開くの…と地味にハマりました。

結局、解決策はターミナルから開くことでした。

# 新しいウィンドウで開く
code ~/.claude

# 今のVSCodeワークスペースに追加する
code -a ~/.claude

これで今開いているVSCodeに.claudeフォルダが追加されて、ソース管理のGUIからGiteaへpushできるようになりました。

一番の事故：会話ログごとAPIキーがpushされていた

Giteaへのpushが成功して、よし動いた〜と安心してたんです。そしたらリポジトリの中に880個近いファイルですよ、880個。こんなに作った覚えないぞと。

中身を確認してみたら、会話ログ（.jsonlファイル）の中に、WordPressのJWTトークンやGoogleのアクセストークンが丸ごと含まれていたんです。((((；ﾟДﾟ)))))))　血の気が引きました。

CLAUDE君（Claude Code）って、会話のやりとりを~/.claude/projects/以下に自動保存する仕組みになってるんですよね。MCP（外部サービスと連携する仕組み）を使うと、その呼び出し時のトークンや認証情報もログに残ってしまうそうです。

動いた喜びでgit add projects/とフォルダごと追加してしまったせいで、センシティブな情報がGiteaに上がってしまいました。

Giteaは自宅のTailscale内だけで動くプライベートサーバーなので、外部に漏れてはいないんですが、セキュリティリスクはつきものなので、こういうところも対処しておきたいです。

対処手順

まず.gitignoreを作って危険なファイルを除外しました。

# 会話ログ（トークン・センシティブ情報が含まれる）
projects/**/*.jsonl
projects/**/tool-results/
projects/**/subagents/

# セッション・一時ファイル
session-env/
sessions/
shell-snapshots/
telemetry/
file-history/
backups/

# 機密設定
settings.local.json

ただ、git rm --cachedでファイルを管理から外してpushしても、過去のコミット履歴にはトークンが残ったままなんですよ。これは知らなかった。完全に消すには履歴ごとリセットするしかありませんでした。

# .gitフォルダを丸ごと削除して履歴をリセット
cd ~/.claude
rm -rf .git
git init
git remote add origin http://[GiteaのIP]:3000/[ユーザー名]/dotfiles.git

# 安全なファイルだけ追加
git add .gitignore CLAUDE.md MEMORY.md settings.json projects/memory/

git commit -m "initial clean commit - safe files only"
git push --force origin main

これで過去の履歴も含めてGiteaがきれいになりました。

git add .やgit add projects/のような「まるごと追加」は危険で、必ずファイルを個別指定するか、先に.gitignoreを設定してから追加する。これに尽きます。

同士の皆さん、CLAUDE君やMCPを使ってる方は、本当にここだけは気をつけてください。

【番外編】Synology DriveとGiteaって二重管理じゃないの？

Giteaの設定が終わってから、ふと気になったんですよ。「Synology Driveですでにホームフォルダ全体を同期してあるし、.claude/もその中に含まれてる。なのにGiteaにも設定ファイルを上げてる。これってダブルバックアップ？」って。

調べてみたら、ダブルバックアップじゃなくて、役割が違う2つの仕組みでした。

Synology Driveは「完全バックアップ」、Giteaは「設定の変更履歴管理」で、どちらか片方があればいい話じゃなかったんですよね。両方あってはじめて安心できる感じです。

おまけ：CLAUDE.mdが3か所にあって混乱した話

Giteaを設定しながら、もう一つ混乱したのが「CLAUDE.mdってどこにあるのが本物？」問題です。

• ~/.claude/CLAUDE.md → 本物。Claude Codeが全プロジェクトで読み込む設定ファイル
• Obsidianのvaultフォルダ内 → 空ファイル。過去の作業で誤って作られていたので削除
• ~/Projects/myproject/CLAUDE.md → プロジェクト固有。そのフォルダを開いた時だけ追加で読まれる

読み込み順としては、①~/.claude/CLAUDE.md（グローバル・常に読まれる）＋②プロジェクトフォルダのCLAUDE.md（そのプロジェクトを開いた時だけ）の両方が重なって適用される、という仕組みでした。Obsidianは「プロジェクト」扱いじゃないので、Vault内にCLAUDE.mdを置いても何も起きないみたいです。　

やりながらルールを変えて、最適な運用を探しながら作業しています。私のCLAUDE君のプランはProプランでそこまでゴリゴリつかえないので、トークンを極力使わないような運用を目指して。

実際の構築手順まとめ

1. SynologyのパッケージセンターでContainer Managerをインストール
2. Container Manager → プロジェクト → 作成
3. プロジェクト名：gitea、パス：/docker/gitea、ソース：Create docker-compose.yml
4. 上記YAMLをペースト → 次へ → Web portal settingsはスキップ → 完了
5. project gitea successが出たら成功
6. ブラウザでhttp://[SynologyのIP]:3000にアクセス
7. 初期設定画面でBase URLを確認（そのままでOK）→ 管理者アカウントを作成 → インストール
8. Giteaでリポジトリを新規作成（例：dotfiles）
9. 先に.gitignoreを作ってから、ターミナルでinit・remote add・個別add・commit・push

感想

Gitea自体は、思ったよりあっさり立てられました。一番の失敗は、動いた喜びで「とりあえず全部push」してしまったことです。会話ログにAPIキーが混入してるなんて、正直まったく考えてませんでした。CLAUDE君やMCPを使ってる人は、ここ本当に注意した方がいいと思います。

そしてGiteaを設定してから「Synology Driveでも同期してるし二重管理じゃないか」って疑問が湧いたんですが、整理してみたら全く違う役割の2つでした。どちらも必要で、どちらかがあればいいという話じゃなかったです。

.gitignoreを最初に作る、ファイルは個別指定で追加する。この2つを守るだけで防げる事故だったので、同じ轍を踏まないでもらえたらなと思います。

とはいえ、今はGit checkoutですきな過去のバージョンのCLAUDE.mdにもすぐ戻せるようになったり、みれたりできるので、快適です♪( ´θ｀)ノ

SynologyのNASを宝の持ち腐れにしていた私が、クロスデバイス環境を設計した話

SynologyのNASを「バックアップ用」にしか使えていなかった私が、クロスデバイス環境の設計を見直した話です。鶏と卵問題・役割分担・新PC移行手順まで全部書きました。

あわせて読みたい