Skip to main content
ドキュメントへの更新が� �繁に発行されており、このページの翻訳はま� 行われている� �合があります。最新情� �については、英語版のドキュメントをご覧く� さい。
� 

� 

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい。

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

この記事では、次の� �目が扱われます。

GitHub Enterprise Server API でインテグレーションを構築し、柔軟性を強化して自分のワークフローの摩擦を軽減できます。

GitHub のアプリケーションを使用すると、ワークフローを自動化し改善できます。 アプリをビルドしてワークフローを改善できます。

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

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 を作成する際は、以下に気を付けてく� さい。

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

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

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

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

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

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

GitHub Apps アプリケーションの開発を始めるには、「GitHub App の作成」から取りかかってく� さい。

OAuth Apps について

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

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

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

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

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

  • OAuth App は、GitHub 全体にわたって、常に認証された GitHub ユーザとして振る舞う必要があります (たとえば、ユーザ通知を行う� �合など)。
  • 認証されたユーザに対して「GitHub でログイン」を有効化することにより、OAuth App をアイデンティティプロバイダとして使用できます。
  • 単一のリポジトリで動作するアプリケーションが必要な� �合、OAuth App を構築しないでく� さい。 OAuth スコープを repo 使用すると、OAuth Apps は、認証 されたすべての ユーザーのリポジトリで動作できます。
  • Team や企業を代理するアプリケーションとして OAuth App を構築しないでく� さい。 OAuth Apps は単一のユーザとして認証を行うので、ある人が OAuth App を会社が使用するものとして作成し、その人が会社を辞めた� �合は、他の人がアクセスできなくなります。

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 Enterprise Server API を使用したアクセス、認証、対話に最善の方法を見極める必要があります。 統合でpersonal access token、GitHub Apps、OAuth Apps のどれを使用するかを決める際の考慮事� �を以下の画像に示しています。

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

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

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

サポートのリクエスト

GitHub Apps、OAuth Apps、および API 開発に関する疑問、バグ レポート、議論については、 を調べてく� さい。 このディスカッションは GitHub のスタッフによって進行および管理されていますが、フォーラ� に投稿された質問に GitHub のスタッフが必ずしも返答するとは限りません。

次の� �合は、お問い合わせフォー� を使用して GitHub サポートに直接連絡することを検討してく� さい。

  • GitHub Enterprise Serverのスタッフからの反応を確実に得たい� �合
  • センシティブなデータやプライベートな懸念事� �に関わるサポートリクエスト
  • 機能リクエスト
  • GitHub Enterprise Serverの製品に関するフィードバック