Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。
All products
アプリ

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

この記事の内容

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

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

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

GitHub App をビルドする手順のチュートリアルについては、「アプリケーションでのGitHub APIの利用」を参照してください。

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のオーナーだけです。 組織が所有する GitHub Apps の開発者設定を追加ユーザーが変更できるようにするため、所有者は GitHub App マネージャーのアクセス許可を付与できます。 GitHub App マネージャーは、サード パーティのアプリケーションを管理できません。 組織での GitHub App マネージャーの追加と削除の詳細については、「Organizationのロール」を参照してください。

GitHub Apps は、どこかにホストする必要があるアプリケーションです。 サーバーとホスティングを扱う詳細な手順については、「アプリケーションでのGitHub APIの利用」を参照してください。

ワークフローを改善するため、複数のスクリプトまたはアプリケーション全体を含む 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アプリの作成」と「OAuth アプリを使用して REST API への認証を行う」を参照してください。

Personal access token

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

たとえば、personal access tokenにリポジトリへの書き込みをできるように設定できます。 そして、リポジトリでイシューを作成する 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 App または fine-grained personal access token を使用します。

統合がむしろアプリケーションのように動作する場合は、統合を独自のエンティティとして独立して動作させるかどうかを検討します。 そうする場合は、GitHub App を使います。

サポートのリクエスト

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

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

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