お客さんのコードの置き場所と名前の付け方

お客さんから預かったコードは、自社のものとは別の置き場所にまとめ、全部を非公開にします。名前は「お客さん-種別」でそろえます。この2つだけで、一覧の混在と、見せてはいけないものを見せる事故の多くを防げます。

小さな会社でお客さんのサイトや自動化の仕組みを預かっていると、コードの中身より「どこに置くか」「どう名付けるか」でつまずくことが多くあります。最初の数件は何とでもなりますが、件数が増えると一気に崩れます。

この記事では、私たちが GitHub で使っている置き場所の分け方と名前の付け方を紹介します。例に出す名前は、実際のお客さんのものではなく、説明用に作ったものです。

混ぜると、何が困るのか

自社のものとお客さんのものを同じ場所に置くと、件数が増えたとたんに一覧が混ざり、権限の付け方を間違えやすくなります。

最初は、自社の道具と同じ場所にお客さんの成果物も置いていました。数件のうちは問題ありません。ところが案件が並ぶと、一覧に自社とお客さんの資産が混ざり、「これはどなたのものだったか」を毎回思い出すことになります。

もっと困るのが権限です。あるお客さんの担当者を招きたいとき、資産が同じ場所に混ざっていると、別のお客さんのコードまで見える状態を作りかねません。お客さんの仕事で守りたいのは、「見えてはいけないものは見えない」ことです。それを注意力ではなく、置き場所の作りで保証したいと考えました。

お客さん専用の置き場所に、非公開でまとめる

お客さん専用の組織を1つ作り、すべてのリポジトリを非公開で置きます。自社の道具や公開しているコードとは、入れ物そのものを分けます。

GitHub では、個人のアカウントとは別に organization（組織）という入れ物を作れます。私たちは、お客さんの資産だけを置く組織を1つ作り、そこにすべてを非公開で置いています。2026年11月時点で、ここには7つのリポジトリがあります。

組織を分けると、一覧が混ざる問題は消えます。組織の単位で「関係者以外には見えない」を初期の状態にできるからです。GitHub は、組織・チーム・リポジトリの3つの層で、誰にどこまで見せるかを決められます。

名前は「お客さん名-種別」でそろえる

名前は、先頭にお客さん名、後ろに種別を置きます。お客さん名で検索すれば、その方の資産がまとめて並びます。

たとえば、ある工務店のサイトのテーマなら example-koumuten-wp-theme、同じお客さんの自動化の仕組みなら example-koumuten-automation のように付けます（説明用の名前です）。

一覧はアルファベット順に並ぶので、先頭にお客さん名を置くと、同じお客さんのものが自然に隣り合います。私たちが束ねたい単位は「どなたの案件か」なので、そちらを先に置きました。

「client-」を付けるのをやめた理由

置き場所が「ここは全部お客さんのもの」と語っているなら、名前にその印を重ねて付けるのは重複です。名前の先頭は一番使う索引なので、お客さん名に譲りました。

最初は、お客さんのものだとひと目で分かるように、名前の頭に client- を付けていました。ところが専用の組織に移したとき、置き場所そのものが「全部お客さんのもの」だと語っていることに気づきました。

しかも頭に印があると、検索や入力の補完のたびに、その文字を通り過ぎないとお客さん名にたどり着けません。分け方が置き場所で決まるなら、名前は置き場所が語らない部分だけを持てばよい。そう考えて、印を外しました。

境界は、仕組みに守らせる

お客さんの担当者を招くときは、その方のリポジトリだけに権限を付けます。組織を分けているので、ほかのお客さんの資産に触れる余地がそもそも生まれません。

置き場所と名前がそろうと、権限の付け方も素直になります。担当者を招くなら、その方のリポジトリにだけ読み書きの権限を付ければ済みます。引き継ぎや外部の確認が入っても、共有する範囲を最小限に切り出せます。

少人数の会社で、こうした境界を頭の中の注意力で守ろうとすると、いつか必ず取りこぼします。だから、組織という壁と、お客さん名で束ねる名前の付け方に肩代わりさせています。いまお客さんの資産が自分のアカウントにたまり始めているなら、件数が2〜3件のうちに置き場所と名前だけ先に整えておくと、後がずっと楽です。

よくある質問

参考・出典

• Managing user access to your organization's repositories（GitHub Docs）（組織・チーム・リポジトリの3層の権限）