Skip to main content

アプリケーションについて

GitHub API でインテグレーションを構築し、柔軟性を強化して自分のワークフローの摩擦を軽減できます。また、GitHub Marketplace で他のユーザーとインテグレーションを共有することも可能です。

GitHub のアプリケーションを使用すると、ワークフローを自動化し改善できます。 アプリをビルドしてワークフローを改善できます。 また、GitHub Marketplace でアプリを共有または販売することもできます。 GitHub Marketplace にアプリを掲載する方法については、GitHub Marketplace の概要を参照してください。

GitHub Appsは、データへのアクセスについてより細やかな権限を提供することから、GitHubとのインテグレーションのための公式に推奨される方式ですが。ただし、GitHub は OAuth Apps と GitHub Apps の両方をサポートしています。 アプリの種類の選択については、「GitHub App と OAuth App の違い」を参照してください。

GitHub Actions でアプリを使用していて、ワークフロー ファイルを変更したいのであれば、workflow スコープを含む OAuth トークンでユーザーの代わりに認証を受けなければなりません。 ユーザは、ワークフローファイルを含むリポジトリの管理もしくは書き込み権限を持っていなければなりません。 詳細については、「OAuth アプリのスコープを理解する」を参照してください。

GitHub App をビルドする手順については、「最初の GitHub App のビルド」を参照してください。

GitHub Apps について

GitHub Apps は GitHub の中でも主役級の存在です。 GitHub App は独自で動作し、独自の ID を使用して API 経由で直接アクションを実行します。つまり、ボットやサービスアカウントを別途維持する必要がありません。

GitHub Apps は、Organization や個人アカウントに直接インストールでき、特定のリポジトリへのアクセス権を付与できます。 精細なアクセス権限が付いており、webhook が組み込まれています。 GitHub App をセットアップする際、アクセスさせるリポジトリを選択できます。 たとえば、リポジトリに問題を書き込み、リポジトリMyGitHubのみにoctocat き込むアプリをoctocat設定できます。 GitHub App をインストールするには、Organization のオーナーであるか、リポジトリで管理者権限を持っている必要があります。

デフォルトでは、Organization内のGitHub Appsの設定を管理できるのはOrganizationのオーナーだけです。 Organization内のGitHub Appsを管理できるユーザを追加するには、管理者がそのユーザにGitHub Appの管理者権限を許可します。 組織内の GitHub App マネージャーを追加および削除する方法については、「GitHub App マネージャー」を参照してください。

GitHub Apps は、どこかにホストする必要があるアプリケーションです。 サーバーとホスティングに関する詳しい手順については、「最初の GitHub App のビルド」をご覧ください。

ワークフローを改善するため、複数のスクリプトまたはアプリケーション全体を含む GitHub App を作成し、それをその他の数多くのツールと接続できます。 たとえば、GitHub Apps を GitHub、Slack、その他の社内アプリケーション、電子メールプログラム、その他の API などに接続できます。

GitHub Apps を作成する際は、以下に気を付けてください。

  • ユーザーまたは Organization は、最大 100 の GitHub Apps を所有できます。

  • GitHub App は、(アプリがユーザーからサーバーへのトークンを使用している場合を除き) ユーザーに依存しないアクションを実行する必要があります。 ユーザからサーバーへのアクセストークンをさらにセキュアにするために、8時間後に期限切れとなるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。 詳細については、「ユーザーからサーバーへのアクセス トークンの更新」を参照してください。

  • GitHub App は、必ず特定のリポジトリと統合するようにしてください。

  • GitHub App は個人アカウントまたは Organization に接続する必要があります。

  • ユーザができる全てのことを GitHub App が知り、行えるとは思わないでください。

  • 単に「GitHub でログイン」するサービスが必要な場合は、GitHub App を使用しないでください。 ただし、GitHub App では 、ユーザー識別フロー を使用してユーザーをログイン させ、 他の操作を実行できます。

  • GitHub ユーザーとして動作し、ユーザーが実行できることをすべて実行したい だけ の場合は、GitHub App をビルドしないでください。

  • GitHub Actions でアプリを使用していて、ワークフロー ファイルを変更したいのであれば、workflow スコープを含む OAuth トークンでユーザーの代わりに認証を受けなければなりません。 ユーザは、ワークフローファイルを含むリポジトリの管理もしくは書き込み権限を持っていなければなりません。 詳細については、「OAuth アプリのスコープを理解する」を参照してください。

GitHub Apps アプリケーションの開発を始めるには、「GitHub App の作成」から取りかかってください。構成済みの GitHub Apps を作成できる GitHub App マニフェストの使い方については、「マニフェストからの GitHub Apps の作成」を参照してください。

OAuth Apps について

OAuth2 は、外部アプリケーションがパスワードにアクセスすることなく、ユーザの GitHub アカウントの個人情報にアクセスする承認を要求できるようにするプロトコルです。 これは Basic 認証よりも好ましい方法です。なぜなら、トークンは特定の種類のデータに限定でき、ユーザがいつでも取り消すことができるからです。

警告: OAuth App からすべてのアクセス許可を取り消すと、ユーザーの代わりにアプリケーションで生成されたすべての SSH キー (デプロイ キーを含む) が削除されます。

OAuth App は、アプリケーションにアクセス権を付与するユーザを認証するため、アイデンティティプロバイダとして GitHub を使用します。 つまり、ユーザーが OAuth App アクセスを許可すると、ユーザーは自分のアカウントでアクセスできる すべての リポジトリにアクセス許可を付与します。また、サードパーティのアクセスをブロックしていない組織にもアクセス許可を付与します。

単純なスクリプトで処理できるよりも複雑なプロセスを作成する場合、OAuth App を構築するのは良い選択肢です。 OAuth Apps は、どこかにホストする必要があるアプリケーションであることに注意してください。

OAuth Apps を作成する際は、以下に気を付けてください。

  • A user or organization can own up to 100 OAuth apps.
  • OAuth App は、GitHub 全体にわたって、常に認証された GitHub ユーザとして振る舞う必要があります (たとえば、ユーザ通知を行う場合など)。
  • 認証されたユーザに対して「GitHub でログイン」を有効化することにより、OAuth App をアイデンティティプロバイダとして使用できます。
  • 単一のリポジトリで動作するアプリケーションが必要な場合、OAuth App を構築しないでください。 OAuth スコープを repo 使用すると、OAuth Apps は、認証 されたすべての ユーザーのリポジトリで動作できます。
  • Team や企業を代理するアプリケーションとして OAuth App を構築しないでください。 OAuth Apps は単一のユーザとして認証を行うので、ある人が OAuth App を会社が使用するものとして作成し、その人が会社を辞めた場合は、他の人がアクセスできなくなります。
  • GitHub Actions で OAuth アプリを使っていて、ワークフロー ファイルを変更する場合、OAuth トークンに workflow スコープがあり、ユーザがワークフロー ファイルを含むリポジトリへの所有者か書き込みのアクセス許可を持っている必要があります。 詳細については、「OAuth アプリのスコープを理解する」を参照してください。

OAuth Apps について詳しくは、「OAuth App の作成」および「アプリの登録」をご覧ください。

Personal access token

personal access tokenは、スコープを使用してそのアクセス許可を指定できる点で OAuth トークンと同様に機能する文字の文字列です。 また、personal access tokenはパスワードとも似ています。ただし、個人アクセストークンは複数所有でき、それぞれのアクセス権をいつでも取り消すことができます。

たとえば、personal access tokenにリポジトリへの書き込みをできるように設定できます。 そして、リポジトリで issue を作成する cURL コマンドを実行するかスクリプトを記述する場合、personal access tokenを渡して認証します。 personal access tokenを環境変数として保存することで、使用のたびに入力することを避けることができます。

personal access tokenを使用する場合は、次の点に注意してください。

  • トークンは自分自身のみを表すものとして使用してください。
  • 1 回限りの cURL リクエストを実行できます。
  • 個人用のスクリプトを実行できます。
  • Team や会社全体が使用するスクリプトは設定しないでください。
  • ボット ユーザーとして動作する共有ユーザー アカウントは設定しないでください。
  • トークンに必要な最小限の特権を付与します。
  • 情報をセキュリティで保護するために、personal access tokenの有効期限を設定します。

構築すべきインテグレーションを決定する

インテグレーションの作成に取りかかる前に、GitHub API を使用したアクセス、認証、対話に最善の方法を見極める必要があります。 統合でpersonal access token、GitHub Apps、OAuth Apps のどれを使用するかを決める際の考慮事項を以下の画像に示しています。

アプリケーションの質問フローの紹介

インテグレーションがどう振る舞うべきか、何にアクセスできるべきかについては、以下の質問を検討してください。

  • インテグレーションは自分自身としてのみ振る舞うのか、それともアプリケーションのように振る舞うのか?
  • 独自のエンティティとして、自分から独立して動作させるのか?
  • 自分がアクセスできるもの全てにアクセスするのか、それともアクセスを制限するのか?
  • 単純か、それとも複雑か? たとえば、personal access tokenは単純なスクリプトや cURL に適し、OAuth App はより複雑なスクリプトを処理できます。

サポートのリクエスト

For questions, bug reports, and discussions about GitHub Apps, OAuth Apps, and API development, explore the GitHub コミュニティでの API と統合に関するディスカッション. The discussions are moderated and maintained by GitHub staff, but questions posted to the forum are not guaranteed to receive a reply from GitHub staff.

Consider reaching out to GitHub Support directly using the contact form for:

  • guaranteed response from GitHub Enterprise Cloud staff
  • support requests involving sensitive data or private concerns
  • feature requests
  • feedback about GitHub Enterprise Cloud products