こんにちは！開発チームのリーダーをやっている先輩です。
毎日のコーディング、本当にお疲れ様です。
PHPで開発をしていると、自作した便利な共通関数や、社内共通の認証モジュール、DBラッパーなどを「他のプロジェクトでも使い回したいな」と思う瞬間が必ずやってきますよね。
そんなとき、まさかコードをコピペして回っていませんよね？「あのプロジェクトのコードを修正したら、こっちのプロジェクトの修正も忘れてバグが出た……」なんて地獄の状況、想像しただけでも冷や汗が出ます。
これを解決するのが、Composerによるプライベートリポジトリ（社内ライブラリ）の管理です。
今回は、世界中のPHPエンジニアが当たり前のように使っているComposerを使って、社内ライブラリをスマートに共有・管理する方法を徹底解説します。
これをマスターすれば、ライブラリのバージョン管理やアップデートが驚くほど簡単になり、チーム全体の開発スピードが劇的に跳ね上がりますよ。一緒に一歩ずつ進んでいきましょう！
—
1. なぜComposerでプライベートリポジトリを管理するのか？
そもそも、Composerは通常 `packagist.org` という世界中の公開リポジトリからライブラリ（オープンソースのパッケージ）を引っ張ってくるツールです。
しかし、社内のビジネスロジックや機密情報を含むコードを、パブリックな場所に公開するわけにはいきませんよね。「じゃあ、どうやって社内専用のライブラリをComposer経由でインストールするのか？」
ここで登場するのが、以下の2つのアプローチです。
1. Satis（サティス）: 自前のサーバーに静的なComposerリポジトリを構築する方法（完全無料・要サーバー管理）
2. Private Packagist（プライベート・パックagist）: 有料のマネージドサービスを利用する方法（爆速導入・手厚いサポート）
この2つの違いを、現場のアーキテクト視点で分かりやすく比較してみましょう。
| 比較項目 | Satis (自前サーバー運用) | Private Packagist (マネージド) |
| :— | :— | :— |
| コスト | サーバー代のみ（実質無料） | 月額料金（チーム規模による） |
| 初期構築・手間 | 構築・Nginxなどの設定・Webhookの設定が必要 | アカウント作成してGitHubと連携するだけ（5分） |
| セキュリティ | 自社インフラ内なので完全にコントロール可能 | クラウド依存だが、SLA（稼働保証）あり |
| 向いている組織 | インフラエンジニアがいてコストを抑えたい企業 | 運用コストを極限まで削り、開発に集中したいチーム |
「まずは自社でコストをかけずに試してみたい！」というチームには Satis がおすすめですが、「サーバーのメンテナンスに工数を割きたくない、今すぐセキュアに始めたい！」というチームには Private Packagist が圧倒的な最適解となります。
今回は、基本の仕組みを深く理解するために、自前で構築できる「Satis」を使ったプライベートリポジトリの作り方と動作確認までを一緒にやっていきましょう！
—
2. Satisの仕組みと全体像
Satisは、一言で言うと「自分専用のミニPackagist（カタログサイト）」を作るためのツールです。
裏側の動きはこうなっています：
1. あなたがGitHubやGitLabなどのプライベートリポジトリに社内ライブラリ（例: `company/auth-package`）をPushする。
2. Satis（コマンド）を実行すると、各リポジトリの `composer.json` を読み込み、1つの綺麗なパッケージ一覧JSON（`packages.json`）を生成する。
3. 生成されたファイルをWebサーバー（NginxやApache）で公開する。
4. 開発プロジェクトの `composer.json` にそのSatisのURLを登録すると、Composerが社内ライブラリを安全にダウンロードできるようになる。
この仕組みを頭に入れておくと、トラブルが起きたときも「今、どのJSONが同期されていないのか」がすぐに分かるようになりますよ。
—
3. 実践：Satisを使ったプライベートリポジトリ環境の構築
それでは、実際に手を動かして環境を作っていきましょう。今回はローカル環境（または検証用サーバー）にSatisをセットアップする手順を解説します。
ステップ1: Satisのインストール
Satis自体もComposerパッケージとして提供されています。適当な作業ディレクトリを作成し、Composer経由でSatisをプロジェクトとしてインストールします。
Satis用のディレクトリを作成して移動
mkdir my-satis-repo && cd my-satis-repo
Composerを使ってSatisのソースコードをプロジェクトとしてクローン＆インストール
composer create-composer –no-dev composer/satis .
解説: `create-composer`（または `create-project`）を使うことで、Satisの実行に必要な依存関係を含めたパッケージ一式が手に入ります。
ステップ2: `satis.json`（設定ファイル）の作成
Satisの根幹となる設定ファイル `satis.json` を作成します。ここに「どのプライベートリポジトリを読み込ませるか」を定義します。
プロジェクトのルートディレクトリに `satis.json` を作成し、以下のように記述してください。
{
“name”: “My Company Private Repository”,
“homepage”: “https://satis.internal.example.com”,
“repositories”: [
{
“type”: “vcs”,
“url”: “git@github.com:your-company/company-logger.git”
}
],
“require-all”: true,
“archive”: {
“directory”: “dist”,
“format”: “zip”,
“prefix-url”: “https://satis.internal.example.com”,
“skip-dev”: true
}
}
各設定項目の深い解説:
- `homepage`: このSatisリポジトリがホスティングされる公開URLを指定します。
- `repositories`: 収集したい社内ライブラリのGitリポジトリ（SSH URLなど）を配列で指定します。
- `”require-all”: true`: 指定したリポジトリの「すべてのバージョン」を自動でカタログ化します。
- `archive`: ソースコードのZIPファイルをビルド時に生成する設定です。これをしておくと、Gitの権限がないビルド環境でも安定して高速にライブラリをダウンロードできるようになります。非常に実用的なプロの技です。
ステップ3: Satisのビルド実行
設定ファイルができたら、以下のコマンドを実行してカタログ（静的JSONファイル群）をビルドします。
第1引数に設定ファイル、第2引数に出力先ディレクトリを指定します
php bin/satis build satis.json public/
実行ログのイメージ:
Scanning https://github.com/your-company/company-logger.git (dev-main)
Writing packages.json
Writing 1.0.0.json
Writing dist/your-company/company-logger-1.0.0-9a2b3c.zip
これで、`public/` ディレクトリの中に `packages.json` や ZIPファイル群が生成されました！あとはこの `public/` ディレクトリをNginxやApacheなどのWebサーバーで公開すれば、Satisサーバーの完成です。
—
4. 精度高い HelloWorld 的な動作確認
さあ、構築したSatisサーバーから、実際に社内ライブラリを別の開発プロジェクトへインストールしてみましょう。ここが一番ワクワクする瞬間です！
1. 利用側プロジェクトの設定 (`composer.json`)
社内ライブラリ（例: `your-company/company-logger`）をインストールしたい別のプロジェクトの `composer.json` を開きます。
ここで、Composerに対して「うちの社内専用リポジトリの場所はここですよ」と教えてあげる必要があります。
{
“name”: “your-project/webapp”,
“require”: {
“php”: “^8.1”,
“your-company/company-logger”: “^1.0”
},
“repositories”: [
{
“type”: “composer”,
“url”: “https://satis.internal.example.com”
},
{
“packagist.org”: false
}
]
}
ここが現場の重要ポイント:
- `repositories` の中に `type: “composer”` としてSatisサーバーのURLを指定します。これで、Composerは公式のPackagistを見に行く前に、まずあなたのSatisサーバーへ問い合わせるようになります。
- ※必要に応じて、社内リポジトリにアクセスするためのSSH鍵やGitHubトークンが開発者の手元（またはCI/CD環境）に設定されている必要があります。
2. インストールコマンドの実行
それでは、魔法のコマンドを叩いてみましょう。
composer update your-company/company-logger -v
`-v`（verbose）オプションをつけることで、Composerが内部でどこに通信し、どのSatisサーバーからパッケージをダウンロードしているのかが詳細にログ出力されます。
成功時の出力イメージ:
Loading composer repositories with information available
Updating dependencies
Locking dependencies
Analyzing dependencies (including platform packages)
- Installing your-company/company-logger (1.0.0): Extracting archive
Writing lock file
Generating autoload files
おめでとうございます！これで、世界に公開されていないあなただけの社内ライブラリが、安全かつスムーズにプロジェクトへインポートされました。`vendor/your-company/company-logger` の中にコードが存在しているはずです。
—
5. 先輩エンジニアからの現場アドバイス：自動化のすすめ
今回は手動で `php bin/satis build` を実行しましたが、実務ではこれでは運用が回りません。
社内ライブラリ（`company-logger`など）がアップデートされ、GitHubの `main` ブランチにマージされたタイミングで、GitHub Actions や GitLab CI などのCI/CDパイプラインを走らせ、自動的にSatisサーバーを再ビルドしてストレージに同期する仕組みを必ず組み込みましょう。
この自動化を一度組んでしまえば、開発者は「新しいバージョン番号を指定して `composer update` するだけ」という、最高にストレスフリーな開発体験を手に入れることができます。
プライベートリポジトリの管理は、一見すると難しそうに見えますが、仕組みを理解してしまえば怖くありません。ぜひあなたのチームでも導入し、コードの共有と再利用を加速させてくださいね！
あなたの毎日のコーディングが、もっと快適で楽しいものになりますように。