DEV Community: orca_forge

GitHub Proのプライベートリポジトリで「デプロイ承認ゲート」をどう作るか

orca_forge — Fri, 17 Jul 2026 19:15:33 +0000

📝 Originally published at forge.workstyle.tech.

「main にマージしても、人間が承認するまで本番デプロイは走らせたくない」——CI/CD を組むと必ず欲しくなる仕組みです。GitHub には環境（Environments）の 必須承認レビュアー という純正機能があり、これを使えば「マージ → 自動で停止 → 承認ボタンで再開」という理想的なゲートが作れます。

ところが、プライベートリポジトリでは思わぬ落とし穴があります。

落とし穴: 承認レビュアーは Pro でも private では使えない

環境の必須承認レビュアーや待機タイマーといった「デプロイ保護規則」は、GitHub Free / Pro / Team ではパブリックリポジトリでしか使えません。プライベートリポジトリで使うには GitHub Enterprise が必要です。

つまり GitHub Pro を契約していても、プライベートリポジトリに承認レビュアーを設定しようとすると API はこう返します。

HTTP 422: Failed to create the environment protection rule.
Please ensure the billing plan supports the required reviewers protection rule.

これは課金トラブルではなく プランの仕様です。環境（Environment）そのものは Pro の private でも作れますが、その上の「承認レビュアー」ルールだけは別枠、という点が紛らわしいところです。

解決策: `workflow_dispatch` を承認ゲートとして使う

純正ゲートが使えないなら、デプロイを手動実行（workflow_dispatch）にするのが確実です。

name: Deploy
on:
  # 手動実行 = 人間による「デプロイ承認」ゲート。
  # main にマージしただけでは走らず、Run workflow を押した時だけ実行される。
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: 本番デプロイ
        run: echo "デプロイを実行"

こうすると main へのマージでは何も起きず、担当者が GitHub の Actions → Deploy → Run workflow を押したときだけデプロイが走ります。ボタンを押す行為そのものが承認に相当するわけです。

どちらを選ぶか

プライベートのまま運用したい → workflow_dispatch の手動ゲートが恒久解。追加コストゼロ。
純正の「自動停止 → 承認」UI が欲しい → リポジトリを public にするか、Enterprise にアップグレードするかの二択。

小さなチームや個人開発なら、まず手動ゲートで十分です。実際のデプロイ先（Vercel / Cloudflare など）は多くの場合それ自身にプロモーション承認の仕組みを持つので、GitHub 側のゲートに固執する必要もありません。

まとめ

環境の承認レビュアーは Free/Pro/Team では public 限定。private は Enterprise が必要。
代替として workflow_dispatch の手動デプロイが、無料・private で確実に動く承認ゲートになる。
「マージ ≠ デプロイ」を明示的に分離できれば、仕組みは何であれ目的は達成できる。

git worktree でコーディングエージェントを並列実行する開発環境の作り方

orca_forge — Fri, 17 Jul 2026 19:03:09 +0000

📝 Originally published at forge.workstyle.tech.

複数のコーディングエージェント（Claude Code や Codex など）を試していると、こんな悩みに突き当たります。「同じリポジトリで別々のタスクを同時に進めたいが、作業が互いに干渉してしまう」「エージェントAとエージェントBの結果を並べて比較したい」。

これを解決するのが git worktree を使った並列実行環境です。この記事では、専用のデスクトップ型 ADE（Agent Development Environment）を例に、セットアップから並列比較、デプロイ承認までの流れを整理します。特定ツールに依存しない考え方が中心なので、自分の環境に読み替えて活用できます。

なぜ git worktree なのか

git worktree は、1つのリポジトリから複数の作業ディレクトリを切り出せる仕組みです。ブランチごとに独立したフォルダが用意されるため、次のような使い方が可能になります。

タスクAはエージェントに任せつつ、タスクBは別のエージェントに任せる
それぞれの変更が別ディレクトリに閉じるので、ファイルの衝突が起きない
同じ課題を複数のエージェントに解かせ、diff を並べて品質を比較する

ブランチ切り替え（git checkout）だと作業ツリーは1つきりですが、worktree なら物理的に別の場所で並行作業できる、というのがポイントです。

事前に揃えておくもの

環境を作る前に、以下が入っているか確認します。

コーディングエージェントの CLI（例: Claude Code）と、そのログイン認証済みの状態
git と node（プロジェクトの CI で使うランタイム）
エージェントを束ねる ADE アプリ本体

エージェントの認証はホームディレクトリの設定（例: ~/.claude）に保存され、ADE 側がそれを自動参照する方式が一般的です。すでに CLI でログイン済みなら、追加のログイン設定は不要なことが多く、GUI から繋ぐだけで使い始められます。

セットアップの流れ

1. アプリを起動して初期許可を与える

初回起動時にホームディレクトリへのアクセス許可を求められたら許可します。既存設定のインポートを促されたら、必要なければスキップして構いません。

2. リポジトリを追加する

作業対象のリポジトリを登録します。いきなり本番リポジトリではなく、練習用の小さなサンプルリポジトリから始めるのがおすすめです。追加すると git の状態が読み取られ、デフォルトブランチ（多くは main）が基準（base ref）に設定されます。

3. ワークツリー（タスク）を作成する

タスク名を付けて新しいワークツリーを作ります。これが main から独立した git worktree となり、他タスクと干渉しない作業場所になります。タスク名は add-readme-section のように内容が分かるものにしておくと後で追いやすくなります。

4. エージェントを割り当てる

ワークツリーごとに使うエージェントを選びます。認証は前述の設定を自動参照するため、ログイン済みなら即実行できます。

5. プロンプトを与えて実行する

「README に使い方セクションを追加して」のような具体的な指示を出して走らせます。

6. 並列で比較する

ここが並列環境の真価です。同じ課題に対して、手順3〜4を繰り返し -2, -3 のように複数のワークツリーを作り、別々のエージェントを割り当てます。ペインを分割すれば、それぞれの進行を同時に監視し、結果を横並びで比較できます。

レビューからデプロイまで

各ワークツリーの diff ビューで変更内容を確認します。AI による差分評価（アノテーション）機能があれば、レビューの一次スクリーニングに使えます。

良い結果が得られたら commit & push。ここから先は自動化されたパイプラインに乗せるのが定石です。

PR 作成 — push をトリガーにプルリクエストが作られる
CI 実行 — テスト（例: node --test）が自動で走る
デプロイ — 本番反映は手動トリガー（Run workflow）にして、人間の承認ゲートを挟む

エージェントが書いたコードであっても、CI と人間の承認を通す流れは変えない、というのが安全に運用するコツです。自動生成だからこそ、機械的なテストと人の目という二段構えを崩さないようにします。

つまずきやすいポイント

PATH の問題

最もよくあるトラブルが「エージェントの CLI が見つからない」です。バージョン管理ツール（fnm や nvm など）経由で node や CLI を入れている場合、それらはシェルプロファイル（.zshrc など）で初期化されて初めて PATH に載ります。

ADE が起動するシェルがこのプロファイルを読み込んでいないと、コマンドが見つかりません。もし「コマンドが見つからない」と出たら、シェルプロファイルの初期化行を確認しましょう。

認証の重複

複数アカウントを切り替える場合、認証リフレッシュが重複しないようガードされている実装が多いです。基本はホームディレクトリの設定に任せておけば問題ありません。

まとめ

git worktree を使うと、複数のコーディングエージェントを干渉なく並列実行できる
同じ課題を複数エージェントに解かせ、diff を並べて品質を比較できる
レビューは diff ビューで、本番反映は CI + 人間の承認ゲートで守る
最大の落とし穴は PATH。バージョン管理ツールの初期化がシェルプロファイルに入っているか確認する

多くの環境では新しく入れるものは少なく、既存の CLI 認証を繋ぐだけで並列エージェント開発を始められます。まずは練習用リポジトリで、同じ指示を2〜3のエージェントに投げて比較するところから試してみてください。

クレジットカード不要で使える無料LLM APIプロバイダまとめ（2026年版）

orca_forge — Fri, 17 Jul 2026 19:02:55 +0000

📝 Originally published at forge.workstyle.tech.

はじめに

LLM（大規模言語モデル）の活用が進む中、開発やプロトタイプ作成において「APIコストを抑えたい」「手軽に複数のモデルを試したい」というニーズは非常に多いものです。しかし、多くの商用APIサービスではクレジットカードの登録が必須となるケースが一般的です。

本記事では、クレジットカード登録なしで利用できる無料枠のあるLLM APIプロバイダのリストと、それらを組み合わせて堅牢なシステムを構築するための実運用における知見をまとめました。

※注：各サービスの無料枠や提供モデルは頻繁に変動するため、導入時には必ず各社の公式サイトで最新情報をご確認ください。

クレジットカード不要・無料枠ありの主要プロバイダ

以下に、比較的利用しやすい無料枠を持つプロバイダをまとめました。

プロバイダ	取得方法	無料枠の目安	特徴
Google Gemini	AI Studio	モデル別RPM/日次	高品質なモデルが利用可能。※プロンプトが学習に利用される場合があるため注意
Groq	Console	モデルによりRPM/RPD制限あり	LPUによる超高速推論が最大の特徴
Cerebras	Cloud	1M トークン/日	日次での利用容量が大きい
OpenRouter	Webサイト	`:free`モデル 20 RPM / 50〜1000 RPD	1つのAPIキーで多数のモデルを切り替え可能
NVIDIA NIM	Build	無料クレジット/枠	多数のオープンモデルを高速に実行可能
GitHub Models	Marketplace	Copilotのプランに依存	GitHubアカウントのみでGPT系などのモデルが利用可能
Cohere	Dashboard	Trial枠（20 RPM程度）	トライアル用途に適したモデル群
SambaNova	Cloud	永続無料枠 + 初期クレジット	高速な推論パフォーマンス
Mistral	Console	Experiment枠（大容量）	大規模なトークン利用が可能（認証条件あり）

実運用における重要な設計指針

無料枠のAPIは非常に強力ですが、商用アプリケーションに組み込むには特有の考慮事項があります。

1. フォールバック戦略を構築する

無料枠のAPIを利用する際最大の課題は、API制限（Rate Limit）や日次上限（Quota）によるサービス停止です。これを回避するには、複数のプロバイダを一つの「プール」として管理し、一つのサービスが制限に達した際に自動的に別のプロバイダへリクエストを飛ばすフォールバック（Fallback）の仕組みが不可欠です。

例えば、LiteLLMなどのマルチプロバイダ・ルーターを活用してモデルのグループ化を行うことで、特定のプロバイダが落ちていてもアプリケーションの可用性を維持できます。

2. エージェント用途での注意点：推論モデルの互換性

AIエージェントを構築する場合、モデルの出力形式に注意が必要です。最近では reasoning_content（思考プロセス）を出力するモデルが登場していますが、モデル間でこの出力形式が異なると、マルチターン（対話継続）の際にコンテキストが壊れる原因になります。エージェント用途で無料枠を使う場合は、モデル間で挙動が統一されているものを選ぶのが定石です。

3. セキュリティとプライバシー

無料枠を利用する際、多くのサービスでは「入力したデータがモデルの学習に利用される」という条件が付いています。そのため、機密情報や個人情報をプロンプトに含めることは絶対に避けてください。機密性の高い業務への適用は、必ず学習に利用されない有料プランまたはエンタープライズ契約のモデルで行うようにしましょう。

まとめ

無料枠のAPIプロバイダは、プロトタイピングや小規模な自動化タスクにおいて非常に強力なツールとなります。これらを単体で使うのではなく、複数のプロバイダを組み合わせて「可用性」と「速度」を最適化する設計思想を持つことが、エンジニアとしての実運用における鍵となります。

プロトタイプ・単発生成：無料枠で十分対応可能。
対話型エージェント・高頻度通信：容量・速度・プライバシーの観点から、有料サブスクリプションの利用を検討すべき。
設計のポイント：フォールバックの実装と、データの取り扱い（学習への利用）への配慮。

DEV Community: orca_forge

GitHub Proのプライベートリポジトリで「デプロイ承認ゲート」をどう作るか

落とし穴: 承認レビュアーは Pro でも private では使えない

解決策: workflow_dispatch を承認ゲートとして使う

どちらを選ぶか

まとめ

git worktree でコーディングエージェントを並列実行する開発環境の作り方

なぜ git worktree なのか

事前に揃えておくもの

セットアップの流れ

1. アプリを起動して初期許可を与える

2. リポジトリを追加する

3. ワークツリー（タスク）を作成する

4. エージェントを割り当てる

5. プロンプトを与えて実行する

6. 並列で比較する

レビューからデプロイまで

つまずきやすいポイント

PATH の問題

認証の重複

まとめ

クレジットカード不要で使える無料LLM APIプロバイダまとめ（2026年版）

はじめに

クレジットカード不要・無料枠ありの主要プロバイダ

実運用における重要な設計指針

1. フォールバック戦略を構築する

2. エージェント用途での注意点：推論モデルの互換性

3. セキュリティとプライバシー

まとめ

解決策: `workflow_dispatch` を承認ゲートとして使う