Skip Navigation
Show nav
Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • Developer Tools
    • コマンドライン
    • Heroku VS Code Extension
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリーとインテグレーション
    • 継続的統合
  • 言語サポート
    • Node.js
      • Working with Node.js
      • Node.js Behavior in Heroku
      • Troubleshooting Node.js Apps
    • Ruby
      • Rails のサポート
      • Bundler の使用
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Python でのバックグランドジョブ
      • Python Behavior in Heroku
      • Django の使用
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Maven の使用
      • Spring Boot の使用
      • Troubleshooting Java Apps
    • PHP
      • PHP Behavior in Heroku
      • Working with PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres スターターガイド
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
      • Migrating to Heroku Postgres
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • AI
    • Working with AI
    • Heroku Inference
      • Inference API
      • Quick Start Guides
      • AI Models
      • Inference Essentials
    • Vector Database
    • Model Context Protocol
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
      • シングルサインオン (SSO)
    • Private Space
      • インフラストラクチャネットワーキング
    • コンプライアンス
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Salesforce とのインテグレーション
  • 継続的デリバリーとインテグレーション
  • パイプライン

パイプライン

日本語 — Switch to English

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2023年08月14日(月)

Table of Contents

  • パイプラインの作成
  • パイプラインへのアクセス
  • パイプラインへのアプリの追加
  • パイプラインでのデプロイ
  • パイプラインの所有権と移動
  • GitHub 同期
  • レビューアプリ
  • パイプラインと Heroku CI
  • 一時的なアプリのアクセス許可
  • 設計に関する考慮事項
  • よくある質問

パイプライン​は、同じコードベースを共有する Heroku アプリのグループです。パイプライン内の各アプリは、継続的デリバリーワークフロー​内の次のいずれかのステージを表します。

  • 開発
  • レビュー
  • ステージング
  • 本番

パイプラインは、アプリの複数の環境を管理​するためにきわめて有効です。一般的なパイプラインワークフローには、次のステップが含まれます。

  1. 開発者は、コードベースに変更を加えるためのプルリクエストを作成します。
  2. Heroku は、そのプルリクエストのレビューアプリ​を自動的に作成し、開発者が変更をテストできるようにします。
  3. 変更が準備できると、その変更はコードベースのマスターブランチにマージされます。
  4. マスターブランチは、それ以上のテストのためにパイプラインのステージングアプリに自動的にデプロイ​されます。
  5. 変更が準備できたら、開発者はステージングアプリを本番にプロモート​し、それをアプリのエンドユーザーから使用できるようにします。

パイプラインの概要ページには、このフローのステージが示され、各ステージのステータスに関するメタ情報が表示されます。たとえば、本番アプリがステージングとは別のコードを実行しているかどうかを確認できます。

パイプラインの例

パイプラインの作成

Heroku Dashboard での操作

アプリの一覧の右上にある New​ (新規) ボタンをクリックし、Create new pipeline​ (新しいパイプラインの作成) を選択します。

アプリの一覧からのパイプラインの作成

あるいは、アプリの Deploy​ (デプロイ) タブに移動し、そのアプリを含む新しいパイプラインを作成することもできます。

アプリからのパイプラインの作成

Heroku CLI での操作

CLI からパイプラインを作成するには、pipelines:create​ コマンドを使用できます。このコマンドでは、パイプラインに追加する既存のアプリを指定する必要があることに注意してください。

$ heroku pipelines:create -a example-app
? Pipeline name: example-pipeline
? Stage of example-app: production
Creating example-pipeline pipeline... done
Adding example-app to example-pipeline pipeline as production... done

CLI から、パイプラインの名前と、それに追加するアプリのステージ (development​、staging​、または production​) を指定するよう求められます。

このコマンドのオプションの完全な一覧を表示するには、heroku help pipelines:create​ を使用します。

パイプラインへのアクセス

パイプライン内のアプリは、Heroku Dashboard には個々のアプリとして表示されません。代わりに、個々のアプリを表示するためのドロップダウンを備えた 1 つのパイプラインエントリの一部として表示されます。

アプリの一覧内のパイプライン

パイプラインへのアプリの追加

Heroku アプリは、1 つのパイプラインの 1 つのステージのみに属することができます。

Heroku Dashboard での操作

パイプラインの概要ページから、デプロイステージの横にある + Add app​ (+ アプリの追加) をクリックして、パイプラインのそのステージに既存のアプリを追加します。

Heroku CLI での操作

heroku pipelines:add​ コマンドを使用して、パイプラインにアプリを追加します。

$ heroku pipelines:add example-pipeline -a example-staging-app
? Stage of example-staging: staging
Adding example-staging to example pipeline as staging... done

パイプラインステージの複数のアプリ

パイプラインステージには、複数のアプリを含めることができます。たとえば、本番ステージには、同じバージョンのコードを実行しているが、設定の異なるメインの本番アプリと管理アプリが含まれることがあります。

複数の本番アプリ

パイプラインでのデプロイ

パイプラインでは、デプロイされたコードがある環境から次の環境へどのように流れるかを定義できます。たとえば、コードをステージングアプリにデプロイし (これが slug)​ にビルドされる)、後でその同じ slug を本番にプロモート​することができます。このプロモーションフローにより、本番にはステージングでテストされたのとまったく同じコードが含まれ、さらに slug の再ビルドよりはるかに高速にもなります。

プロモーション

特定のパイプラインステージの変更を完全にテストしたら、それに関連付けられた slug をダウンストリームステージのアプリにプロモートできます。

ダウンストリーム​とは、パイプライン内の次の環境ステージを指します。たとえば、development --> staging --> production​ のパイプラインがある場合、ステージングは開発のダウンストリームであり、本番はステージングのダウンストリームです。

Heroku Dashboard での操作

特定のステージの slug は、パイプラインの概要ページで関連付けられた Promote​ (プロモート) ボタンをクリックすることによってプロモートできます。

パイプラインプロモーション

ダウンストリームステージに複数のアプリが存在する場合は、slug をどのアプリにプロモートするかを指定できます。

Promote​ (プロモート) ボタンは、後続のステージにアプリがある場合のみ選択できます。つまり、staging​ に、production​ にプロモートするアプリがあるが、production​ ステージにアプリがない場合、staging​ アプリをプロモートする対象がないため、プロモーションターゲットはありません。

Heroku CLI での操作

CLI から、heroku pipelines:promote​ コマンドを使用して slug をプロモートできます。このコマンドでは、ソースアプリの名前 (-a​) または Git リモート (-r​) を指定する必要があります。

$ heroku pipelines:promote -r staging
Promoting example-staging to example (production)... done, v23
Promoting example-staging to example-admin (production)... done, v54

デフォルトでは、このコマンドは、ソースアプリの slug をダウンストリームステージのすべての​アプリにプロモートします。--to​ オプションを使用して、プロモート先にするこれらのアプリのサブセットを指定できます。

$ heroku pipelines:promote -r staging --to my-production-app1,my-production-app2
Starting promotion to apps: my-production-app1,my-production-app2... done
Waiting for promotion to complete... done
Promotion successful
my-production-app1: succeeded
my-production-app2: succeeded

プロモーション中のリリースフェーズ

slug がプロモートされると、新しいビルドが作成されない場合であってもリリースフェーズ​が実行されます​。

パイプラインの所有権と移動

パイプラインの設定タブの所有権セグメント

パイプラインの Web インターフェースと CLI では、パイプライン内のアプリがパイプライン所有者​によって所有される必要があります。この所有者は、パイプラインの Web インターフェースの Settings​ (設定) タブで割り当てることができます。

パイプライン所有者 (通常は Heroku Team) を割り当てることを選択すると、コラボレーションワークフロー内のアクセス許可に関連した一般的な問題が防止されます。これは、所有者がチームメンバーに本番アプリ、ステージングアプリ、開発アプリに対する異なるアクセス権を割り当てたいと考えている場合に特に重要です。

この機能により、パイプライン内のより適切な構造や管理の階層が促進されます。

ユーザーがパイプライン内のアプリを所有している場合、そのユーザーはパイプラインを所有する資格があります。 ユーザーがパイプラインの所有権を引き継いだ場合、Web UI では、そのユーザーが所有していないパイプラインアプリが強調表示され、パイプライン内の外部アプリをパイプライン所有者に移動するための UI が提供されます。

個人が所有しているパイプラインは、その個人がメンバーである Heroku Team (または Enterprise Team) にのみ移動できます。Team が所有しているパイプラインは、そのチームのメンバーである任意の個人に移動できます。 ただし、請求のセキュリティのため、個々のパイプラインを他の個人に直接移動することはできません。

GitHub 同期

ステージングから本番へのプロモーションは優れた機能ですが、GitHub 統合​を使用してステージングに自動的にデプロイすることによって、フローをさらに最適化できます。たとえば、GitHub 上で master​ ブランチが更新され、継続的インテグレーション (CI) テストに合格した場合は常に、ステージングを自動デプロイできます。

レビューアプリ

GitHub を使用している場合は、プルリクエストを使用し、対応するレビューアプリ​を設定することを強くお勧めします。レビューアプリによって使用される dyno とアドオンは、通常のアプリとまったく同じように課金されます。詳細は、「レビューアプリの管理と費用​」を参照してください。

パイプラインと Heroku CI

GitHub を使用している場合は、Heroku Pipelines と容易に統合できる Heroku の視覚的な低設定のテストランナーである Heroku CI​ をオンにすることができます。すべての Heroku Pipeline がすでに CI に対応しているため、パイプラインの Settings​ (設定) タブでこれをオンにするのみです。テストラン期間中の dyno およびアドオンの実行時間には、秒単位の従量課金​で通常料率の料金が発生します。

一時的なアプリのアクセス許可

レビューアプリと CI アプリは、短時間の “一時的な” アプリです。パイプラインのアクセスタブを使用して、ユーザーアクセス許可を設定し、パイプライン内のすべての一時的なアプリへのアクセスを管理できます。このアクセスタブは、Heroku Teams​ および Enterprise Teams​ の “管理者” ユーザーと、個人のアカウントでのパイプライン所有者​から使用できます。

パイプラインアクセスタブのアクセス許可は、レビューアプリと CI アプリにのみ適用されます。

新しいバージョンのレビューアプリでは、Enterprise Teams および Heroku Teams の “メンバー” ロールを持つすべてのユーザーが、"表示"、"操作"、および “デプロイ” アクセス許可での自動参加を通して、レビューアプリに自動的に追加されました。パイプラインアクセスタブにより、自動参加アクセスを管理および変更することが可能になります。自動参加アクセス許可の変更は、Enterprise Teams に対してのみ可能です。Heroku Teams の場合、"メンバー" が自動参加を通して取得する “表示"、"操作"、および "デプロイ” アクセス許可は静的であり、変更できません。

Enterprise Team の既存のパイプラインに対するアクセス許可を編集するには、パイプラインアクセスタブの 「Default permissions for new team members」 (新しいチームメンバーのデフォルトのアクセス許可) セクションにある小さな鉛筆アイコンを選択します。また、自動参加を完全に無効にすることもできます。アクセス許可の変更や自動参加の無効化/有効化は新しいアプリに対してのみ有効であり、以前の設定は変更されません。

自動参加の編集

自動参加は、Enterprise Team および Heroku Teams の “メンバー” ロールを持つユーザーが、レビューアプリと CI アプリの “表示"、"操作"、および "デプロイ” アクセス許可でパイプラインに自動的に追加されたときに実行されます。パイプラインアクセスタブを使用すると、自動参加を無効にしたり、Enterprise Team の “メンバー” の自動参加アクセス許可を変更したりできます。Heroku Teams の場合、アクセス許可は静的であり、変更できません。

 

パイプラインアクセスタブでのユーザーアクセス許可へのすべての変更、自動参加の有効化/無効化、および既存の自動参加アクセス許可の編集は、これらの変更を行った時点から新しいアプリにのみ適用されます。これらは、既存のアプリには適用されません。

新しいパイプラインの場合、デフォルトでは自動参加が有効に設定され、"表示"、"操作"、および “デプロイ” アクセス許可が選択されます。パイプラインを作成するときに、自動参加を無効にしたり、アクセス許可を変更したりできます。

自動参加の新規設定

自動参加を通して自動的には追加されないその他のすべてのユーザーについては、手動で追加できます。たとえば、"共同作業者" ユーザーにパイプライン内のレビューアプリと CI アプリへの “操作” アクセスを許可する場合は、このユーザーを “操作” アクセス許可が選択されたパイプラインアクセスタブで手動で追加します。

自動参加の新規設定

Heroku Teams​ の場合、アクセス許可は静的であり、変更できないため、自動参加を有効にするときにアクセス許可を選択するオプションはありません。

静的アクセス許可

また、既存のユーザーアクセス許可を編集するオプションもありません。ユーザーには、チーム内のそのロールに基づいて、静的アクセス許可が事前に設定されています。

静的アクセス許可

個人のアカウント​の場合は、より高いチームレイヤーが存在しないため自動参加の概念はありませんが、各パイプラインには、そのパイプライン内のレビューアプリと CI アプリにアクセスできるユーザーを追加するために使用できるアクセスタブがあります。

静的アクセス許可

アクセス許可と機能

パイプラインレベルのアクセス許可は Heroku のアプリアクセス許可​と同じように見えますが、それらの機能は異なり、ユーザーがレビューアプリと CI アプリに対して実行できるアクションに固有のものです。

Enterprise Teams および Online Teams の “管理者” ロールを持つユーザーと、個人のアカウントでのパイプライン所有者のみがパイプラインレベルのアクセス許可にアクセスしたり、それを変更したりできます。

​アクション​  view  ​deploy​operate​manage
​レビューアプリ
​プルリクエストの表示​X​X​X​X
​レビューアプリの表示​X​X​X​X
​レビューアプリを開く​X​X​X​X
​レビューアプリの作成​X​X​X​X
​レビューアプリの削除​X​X​X​X
​ビルド情報の参照​ ​X​X​X
​環境設定の編集​ ​X​X​X
​CI
​テストの表示​X​X​X​X
​CI アプリの作成​ ​ ​X​X
​CI の有効化​ ​ ​ ​X
​CI 実行のキャンセル​ ​ ​ ​X

設計に関する考慮事項

パイプラインは、アプリケーション slug のフローのみ​を管理します。アプリの Git リポジトリ​、環境設定​、アドオン​、その他の環境依存関係は、独立して管理する必要があります。

パイプラインプロモーションを使用したデプロイは、ステートレスビルド​のアプリにのみ推奨されます。環境設定の値を slug にコンパイルするビルド (つまり、ステートフルビルド​) は、プロモートされるときに問題が発生する場合があります。ステートフルビルドのアプリの場合は、代わりに Heroku の標準の Git ベースのデプロイ​または GitHub デプロイ​を使用してください。

slug がプロモートされると、Heroku はそれを何も変更せずにコピーします。ターゲットアプリの環境に合わせて再ビルドされることはありません​。ビルドがビルドアプリのコンテキストから環境に組み込まれている場合、その slug はパイプラインステージ間で移植できなくなります。これは、たとえば、ビルド環境内の URL によって定義された CDN でホストされているアセットをビルドするために Ruby on Rails とアセットパイプラインを使用している場合が考えられます。これは、ビルドアプリに固有の URL が css および js ファイルに組み込まれ、それらがプロモートされたときに正しく機能しないためです。これを Rails で設定する方法に関する手順については、この記事​を参照してください。

slug は、それらがビルドされたスタックと関連付けられています。これは通常、slug がそのスタック内のシステムライブラリに対してコンパイルされたバイナリを含んでいるためです。したがって、slug を 1 つのアプリから別のアプリにプロモートすると、ターゲットアプリのスタックは、プロモート元のアプリと一致するように更新されます。

よくある質問

パイプラインの CLI では他に何を実行できますか?

コンソールで、使用法の詳細を含むパイプラインのコマンドの完全な一覧を表示できます。

$ heroku help pipelines

Heroku CLI プラグインのリポジトリ README​ では、追加の使用法の例や機能の履歴が提供されています。

開発、ステージング、本番以外のパイプラインステージを使用できますか?

いいえ。これらの 3 つのステージに加え、特殊なステージであるレビューのみが現在サポートされています。

プロモーション時に rake db:migrate などのスクリプトを実行できますか?

Heroku Release Phase​ を使用すると、新しいバージョンのアプリが継続的デリバリーフローのいずれかのステップにデプロイされる前に、スキーマ移行などの一般的なタスクを実行できます。詳細は、関連するドキュメントを参照してください。

パイプラインステージで複数のアプリを使用できますか?

はい。

パイプラインには常にアプリが必要ですか?

はい。パイプラインには常に 1 つのアプリケーションが含まれている必要があります。 アプリが含まれていないパイプラインにはダッシュボードからアクセスできず、削除されることになります。 レビューアプリがパイプライン内に存在することが常に保証できないため、少なくとも 1 つの永続的なアプリをパイプラインに含めることを強くお勧めします。

パイプラインは GitHub なしで動作しますか?

はい。パイプラインは GitHub と極めて適切に統合されていますが、この統合は必須ではありません。

“開発” ステージが表示されません。開発アプリを追加するにはどうすればよいですか?

アプリは他の任意のステージに追加できます。それには、アプリカードのコンテキストメニューを使用して、アプリを “開発” に移動します。あるいは、アプリの Deploy​ (デプロイ) タブに移動し、そこから “開発” ステージを指定してパイプラインに追加することもできます。

パイプラインは Heroku Enterprise Teams と連携して動作しますか?

はい。パイプラインは Enterprise Teams で完全にサポートされています。 ただし、場合によっては、「Using App Permissions in Heroku Enterprise Teams​」(Heroku Enterprise Teams でのアプリアクセス許可の使用) で説明されているように、チームメンバーがアクセス制御のためにパイプライン内の特定のアプリで操作できなくなることがあります。ユーザーは、アプリ上で関連する操作を実行するには十分なアクセス許可が必要です。

パイプラインは Private Space と連携して動作しますか?

はい。パイプラインは、Common Runtime および複数の異なる Private Space のアプリにまたがって動作できます。これにより、本番アプリでのみ Private Space にプロモートしながら、Common Runtime または別の Private Space でテストおよびステージングアプリを使用できます。

パイプラインのコストはいくらですか?

パイプライン機能の使用自体は無料ですが、パイプライン内のアプリによって使用される dyno やアドオンにコストが発生します。

関連カテゴリー

  • 継続的デリバリーとインテグレーション
アプリの複数の環境の管理 リリースフェーズ

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices