Instiq

GitHub Administration のナレッジマップ

GitHub Administration の主要概念 191 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(191)

  • GitHub Actions

    CI/CD などを自動化するワークフロー基盤。.github/workflows に YAML で定義し、ランナー上で実行。

    前提: YAML

  • 暗号化シークレットと変数(secrets / vars)

    機密値はシークレット(secrets.<名前>)、非機密の設定値は変数(vars.<名前>)として保存する。組織/リポジトリ/環境の 3 レベルにスコープでき、同名は狭いスコープ(環境>リポジトリ>組織)が優先。REST API で管理(書き込みは公開鍵で暗号化)。

    関連: 環境(environment)と保護ルール

  • ワークフロー(workflow)

    .github/workflows/ 配下に置く YAML ファイルで定義する自動化プロセス。on: でトリガーを宣言し、1 つ以上のジョブを実行する。

    前提: YAML

  • ジョブ(job)

    ワークフロー内の実行単位。runs-on でランナーを選び、ステップの列を実行する。既定で他ジョブと並列に動き、各ジョブは独立した環境で実行される。

    関連: runs-on

  • ランナー(runner)

    Actions のジョブを実行する環境。GitHub ホステッドと自社のセルフホステッドがある。

  • コンテキスト(contexts)

    ランタイムのメタデータにアクセスするオブジェクト群。github・env・vars・secrets・inputs・matrix・needs・runner・job・steps などがある。

    前提: needs(ジョブ依存)

  • Issue

    バグ・要望・タスクを1件ずつ追跡・議論する機能。Label/Assignee/Milestone と連携。

    関連: Milestone担当者(assignee)

  • 環境(environment)と保護ルール

    デプロイ先を表す単位。必須レビュアーによる承認、待機タイマー、デプロイ可能ブランチの制限、環境スコープのシークレット/変数を設定でき、本番デプロイを承認制にできる。

    関連: 暗号化シークレットと変数(secrets / vars)

  • permissions(トークン権限)

    GITHUB_TOKEN に与える権限を宣言するキー。最小権限(contents: read 等)を既定にし、必要なジョブだけ書き込みへ昇格する。OIDC を使う場合は id-token: write を付与する。

    前提: OIDC フェデレーション(CI/CD)

    関連: GITHUB_TOKEN

  • GitHub Advanced Security(GHAS)

    コード・シークレット・依存関係を SDLC 全体で保護する機能群。2024年後半に Code Security(CodeQL/コードスキャン)と Secret Protection(シークレットスキャン/プッシュ保護)の2つの独立製品へ再編・個別課金化された。Dependabot 等の依存関係/サプライチェーン機能は無料で提供。公開リポは多くが無料、プライベート/Enterprise は製品ライセンスが必要。

    前提: Dependabot暗号化シークレットと変数(secrets / vars)Code SecuritySecret Protection(シークレット保護)

    関連: Code scanning

  • GitHub Enterprise Server(GHES)

    自社のデータセンターやプライベートクラウドに構築するセルフホスト版 Enterprise。データを自社管理下に置けるためコンプライアンス要件に応えやすい一方、機能は定期リリース(feature release)に追従して提供され、一部のクラウド専用機能(例:一部のセキュリティ機能)は遅延したり提供されなかったりする。管理者自身がアップグレードやバックアップを運用する。

    前提: GitHub EnterpriseOrganizationReleases

  • Dependabot

    依存ライブラリの脆弱性を通知(alerts)し、修正/更新の PR を自動作成する機能。

  • コードレビュー(Pull Request)

    Pull Request 上で差分にコメントし、変更を承認/変更要求するプロセス。必須レビュー数や CODEOWNERS による必須レビュアー指定でマージ前の品質を担保する。

    前提: CODEOWNERS環境(environment)と保護ルール

  • Actions のコスト最適化

    paths/branches フィルター・concurrency・キャッシュ・matrix の最小化・ランナーサイズの見直しで Actions の消費を抑える施策。品質を落とさず無駄を削るのが原則。

    前提: GitHub Actionsキャッシュ(actions/cache)concurrency(同時実行制御)strategy.matrix

  • ID プロバイダー(IdP)

    Entra ID・Okta などの企業の認証基盤。SAML SSO で認証を担い、SCIM/チーム同期と組み合わせてアカウントとグループを一元管理する。

    前提: SAML SSO(シングルサインオン)SCIM(プロビジョニング)チーム同期(team synchronization)Team(チーム)

  • ポリシー(メンバーができること)

    組織/Enterprise の設定で、メンバーができること(リポジトリ作成・可視性・フォーク・Actions 利用・GHAS 有効化など)を統制する。Enterprise の方針は下位の組織/リポジトリへ波及する。コード変更のガードレールであるルールセットとは別レイヤー。

    前提: GitHub Actionsfork(フォーク)ルールセット(ruleset)可視性(Public/Private/Internal)

  • strategy.matrix

    1 つのジョブ定義を OS×バージョン等の複数バリエーションに自動展開する仕組み。include で追加、exclude で除外する。

    前提: ジョブ(job)

    関連: include / exclude(matrix)

  • ステップ(step)

    ジョブを構成する個々の処理。run: でシェルコマンドを、uses: でアクションを実行する。上から順に実行される。

  • workflow_call(再利用可能ワークフロー)

    他のワークフローから uses: で呼び出せるようにするトリガー宣言。呼び出し側は with: で入力、secrets: でシークレット(inherit 可)を渡し、outputs を受け取れる。

    前提: 暗号化シークレットと変数(secrets / vars)ワークフロー(workflow)

    関連: secrets: inheritinputs(ワークフロー入力)

  • Team(チーム)

    Organization 内でメンバーをまとめ、リポジトリ権限を付与する単位。入れ子にでき親の権限を継承。

    前提: permissions(トークン権限)

    関連: Organization

  • ライセンス(シート)

    ユーザー単位で消費する利用枠。ライセンス使用状況を監視して未使用シートを回収する。SCIM/EMU を使うと退職者のシートが自動で空く。

    前提: SCIM(プロビジョニング)LICENSE

  • 従量課金(metered)

    ユーザー単位(シート)に加えて消費量で課金される製品。Actions の分・ストレージ・Packages・Copilot・GHAS など。使用レポートで消費の多い組織/リポを把握する。

    前提: GitHub Actions消費ベースの課金(従量課金)ライセンス(シート)GitHub Advanced Security(GHAS)

    関連: 使用レポート(usage report)

  • キャッシュ(actions/cache)

    依存パッケージなど再生成可能なデータをキーで保存・復元し、ビルドを高速化する仕組み。restore-keys で部分一致復元。残したい成果物(アーティファクト)とは目的が異なる。

    前提: GitHub Actionsアーティファクト(artifact)

  • larger ランナー

    より大きな CPU/メモリや静的 IP 範囲を持つ GitHub ホスト型ランナー。固定 IP が必要な場合や高負荷ジョブに使う。

    前提: GitHub ホスト型ランナージョブ(job)needs(ジョブ依存)ランナー(runner)

  • push / pull_request イベント

    コードの push や PR の作成・更新で起動する CI の中心イベント。branches/paths(および *-ignore)フィルターで対象を絞れる。

  • ブランチ保護ルール

    マージ前に必須レビュー・必須チェック・会話解決などを強制し、直接 push を禁止できる設定。

    前提: コードレビュー(Pull Request)環境(environment)と保護ルールpush / pull_request イベント

  • 依存関係グラフ

    マニフェスト/ロックファイルを解析し、リポジトリが依存するパッケージと推移的依存を一覧化する機能。Dependabot アラートや Dependency Review の基盤になる。

    前提: DependabotDependabot アラートとセキュリティ更新Dependency Review

  • OIDC フェデレーション(CI/CD)

    外部 CI(GitHub Actions 等)が長期アクセスキーなしで AWS のロールを引き受ける仕組み。IAM に OIDC ID プロバイダーを登録し、信頼ポリシーで sub(リポジトリ/ブランチ)を限定して AssumeRoleWithWebIdentity で一時認証情報を得る。キーレスで安全。

    前提: GitHub ActionsID プロバイダー(IdP)

  • GitHub Enterprise

    複数の Organization を束ねて一元管理する大規模組織向けの形態。Cloud(GitHubホスト)と Server(自社運用)がある。

    前提: Organization

  • fine-grained PAT(細粒度)

    権限・対象リポ・有効期限を細かく絞れる Personal Access Token。最小権限+有効期限で発行し、漏洩時は失効。組織ポリシーで承認制/制限できる。

    前提: ポリシー(メンバーができること)permissions(トークン権限)IssuePersonal Access Token(PAT)

  • GitHub Support

    管理者の設定・権限では解決できない障害・不具合・GHES のシステム障害などを扱う窓口。問題はまず「管理者で解決できるもの」と「Support 案件」に切り分ける。

    前提: permissions(トークン権限)GitHub Enterprise Server(GHES)Issue

  • ルールセット(ruleset)

    ブランチ保護・必須レビュー・必須ステータスチェックなどを組織横断で強制するガードレール。ポリシー(メンバーの権限)とは別レイヤーで、コード変更に対する統制を担う。

    前提: ブランチ保護ルールコードレビュー(Pull Request)

  • コンポジットアクション

    複数のステップ(run: や他アクションの uses:)を 1 つのアクションに束ねたもの。ワークフローの 1 ステップとして uses: で呼び出す。

    前提: GitHub Actionsステップ(step)ワークフロー(workflow)

  • GitHub ホスト型ランナー

    GitHub が用意・更新・破棄する使い捨ての仮想環境。ジョブごとにクリーンで、一般的な CI に向く。利用分課金(無料枠あり)。

    前提: ジョブ(job)ランナー(runner)

  • inputs(ワークフロー入力)

    workflow_dispatch や workflow_call で受け取るパラメーター。type(string/boolean/choice/number/environment)・required・default・options を定義し、inputs.<名前> で参照する。

    前提: ワークフロー(workflow)

    関連: workflow_dispatchworkflow_call(再利用可能ワークフロー)

  • needs(ジョブ依存)

    ジョブの実行順を制御するキー。needs: [A, B] で「A と B の完了後に実行」を宣言する。前段ジョブの outputs 参照経路でもある。

    前提: ジョブ(job)

  • on:(トリガー宣言)

    ワークフローを起動するイベントを宣言するキー。push・pull_request・schedule・workflow_dispatch・repository_dispatch・workflow_call などを指定する。

    前提: push / pull_request イベントrepository_dispatchschedule(cron)ワークフロー(workflow)

  • Code Security

    ソースコードを静的解析(SAST)して脆弱性を検出する GitHub の機能「Code Scanning」の中核。既定エンジンは CodeQL で、コードをデータベース化しデータフロー解析(source→sink)で危険な経路を見つける(サードパーティ SAST ツールも統合可能)。なお「GitHub Code Security」は 2025 年に登場したサブスクリプション製品プラン名(Code Scanning・Copilot Autofix 等を含む)であり、Code Scanning 機能そのものの改称ではない点に注意。

    前提: Code scanningautofix(Copilot Autofix)データフロー解析(source→sink)

  • Issue テンプレート

    新規 Issue 作成時に見せる定型のひな形。Markdown ベースの旧形式に加え、YAML で入力フォーム(テキスト欄・選択式・チェックボックス等)を定義できる Issue フォームがあり、必須項目や自動ラベル付与を指定して起票内容を標準化する。`.github/ISSUE_TEMPLATE/` に配置する。

    前提: inputs(ワークフロー入力)IssueMarkdownYAML

    関連: 担当者(assignee)ラベル(GitHub)

  • LICENSE

    利用・改変・再配布の条件を定めるファイル。無い公開リポジトリは既定で全権利留保。

  • Organization

    複数のメンバーとリポジトリを一元管理する組織アカウント。Team・課金・権限を持つ。

    関連: Team(チーム)

  • Secret scanning

    コミット/プッシュ中の API キーやトークンを検出。push protection で漏洩を未然にブロック。

    前提: push / pull_request イベント

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: JSON

  • fork(フォーク)

    GitHub 上で、リポジトリを自分のアカウントへ複製する操作。OSS 貢献の起点。

  • SAML SSO(シングルサインオン)

    組織/Enterprise のメンバーが IdP(Entra ID・Okta 等)で認証してから GitHub にアクセスする仕組み。認証を担い、退職者のアクセスを一括で止められる。アカウントの自動削除は SCIM の役割で、SAML 単独では行われない。

    前提: シングルサインオン(SSO)

    関連: SCIM(プロビジョニング)

  • SCIM(プロビジョニング)

    IdP でのユーザー作成・更新・削除を GitHub に同期し、アカウントを自動プロビジョニング/デプロビジョニングする仕組み。IdP で無効化したユーザーが GitHub からも自動削除され、退職時の取り残しを防ぐ。SAML(認証)とは役割が別。

    関連: SAML SSO(シングルサインオン)

  • シークレットのスコープ(環境>リポ>組織)

    シークレットは組織・リポジトリ・環境(environment)でスコープを持ち、同名は狭いスコープが優先(環境>リポ>組織)。組織シークレットは許可リポを限定し、共通認証情報は組織レベルで一元管理するとローテーションが容易。

    前提: 環境(environment)と保護ルール暗号化シークレットと変数(secrets / vars)

  • 使用状況メトリクス(GitHub usage metrics)

    Actions の実行時間・Packages/Codespaces のストレージ・ライセンス(シート)使用状況などの使用量を可視化し、課金・最適化に使うレポート。Enterprise/Organization の課金画面や使用状況レポートで確認する。

    前提: GitHub Actionsライセンス(シート)使用レポート(usage report)LICENSE

  • アクションの種別(JavaScript/Docker/コンポジット)

    JavaScript アクション(Node.js・クロスプラットフォーム・速い)、Docker コンテナアクション(環境を同梱できるが Linux ランナー限定・起動は遅め)、コンポジットアクション(ステップの束)の 3 種。

    前提: コンポジットアクション環境(environment)と保護ルールステップ(step)ランナー(runner)

  • アーティファクト(artifact)

    ビルド成果物・テストレポート等のファイルを実行に紐づけて保存する仕組み。upload-artifact で保存、download-artifact で取得。保持期間(retention)後に自動削除。ジョブ間でファイルを渡す標準手段。

    前提: ジョブ(job)

    関連: 保持期間(retention)

  • env:(環境変数)

    ワークフロー/ジョブ/ステップの各レベルに環境変数を定義するキー。狭いスコープが優先される。

    前提: シークレットのスコープ(環境>リポ>組織)環境(environment)と保護ルールジョブ(job)ステップ(step)

  • フォーク PR の実行承認

    外部のフォークからの PR で初めて Actions を動かす際に承認を必須にする設定。外部コードの無確認実行やシークレット悪用を防ぐ。

    前提: GitHub Actionsfork(フォーク)暗号化シークレットと変数(secrets / vars)

  • GITHUB_TOKEN

    各ワークフロー実行に自動発行される一時的・スコープ付きの資格情報。permissions キーで最小権限(例 contents: read)に絞り、書き込みが要るジョブだけ昇格する。長期の PAT は避ける。

    前提: ジョブ(job)ワークフロー(workflow)

    関連: permissions(トークン権限)

  • セルフホストランナー

    自分のマシン/クラウドにランナーアプリを入れて登録するランナー。特殊ハードウェア・社内ネットワークアクセス・大規模キャッシュ向け。状態が残り得るため、公開リポジトリでの利用は危険。

    前提: キャッシュ(actions/cache)ランナー(runner)

  • Secret Protection(シークレット保護)

    旧 secret scanning。コミットされた/されようとする API キーやトークンなどの秘密を検出・ブロックする。リポ/組織で有効化。漏洩した秘密はファイル削除では履歴に残るため、トークンの無効化(ローテーション)が必須。

    前提: 暗号化シークレットと変数(secrets / vars)Secret scanning

  • GitHub App

    GitHub 上で動く自動化・連携の第一級の主体。リポジトリ単位でインストールでき、必要な権限だけを細かく(fine-grained)付与する最小権限モデルのため、自動化やIntegration開発では OAuth App より推奨される。ユーザーではなくインストール(installation)としてAPIを呼び出し、専用のBotアカウントを持つ。

    前提: needs(ジョブ依存)permissions(トークン権限)

    関連: OAuth App

  • GitHub Enterprise Cloud(GHEC)

    GitHub がホストするクラウド版の Enterprise プラン。インフラ運用は GitHub 側が担い、新機能やセキュリティ更新はセルフホスト版(GHES)より先行して利用できることが多い。データレジデンシー機能を使うと保存先リージョンを選べる。

    前提: GitHub EnterpriseGitHub Enterprise Server(GHES)

    関連: データ所在地(Data Residency)

  • ラベル(GitHub)

    Issue や Pull Request に貼り付けて種別・優先度・状態などを分類するタグ機能。色とその説明を自由に定義でき、検索修飾子 label: での絞り込みや Actions のトリガー条件にも使う。組織/リポジトリ単位で既定ラベル(bug・enhancement 等)が用意される。

    前提: GitHub ActionsIssue検索修飾子(qualifiers)

    関連: 担当者(assignee)Issue テンプレート

  • Releases

    特定バージョンを、タグに紐づけてリリースノートやアセットとともに公開する機能。

  • Star

    リポジトリのお気に入り登録。Stars 一覧に保存され、関心の指標になる(通知は来ない)。

  • 監査ログとサインインログ

    ユーザーや管理者の操作を記録する監査ログと、認証イベントを記録するサインインログ。誰がいつ何をしたかを追跡し、調査やトラブルシューティングに使う。

  • Code scanning

    CodeQL などでコードを静的解析し、脆弱性やバグを検出する機能(GHAS)。

    関連: GitHub Advanced Security(GHAS)

  • カスタムリポジトリロール

    既定の Read〜Admin では粒度が合わないときに、必要な権限だけを束ねて定義できる独自のリポジトリロール。最小権限を実現しやすい。

    前提: permissions(トークン権限)

    関連: リポジトリロール

  • データ所在地(Data Residency)

    GitHub のデータを特定の地理的リージョンに保管する形態(GHEC with Data Residency)。規制・コンプライアンス要件への対応に使う。

    関連: デプロイ形態(GHEC/EMU/Data Residency/GHES)GitHub Enterprise Cloud(GHEC)

  • デプロイ形態(GHEC/EMU/Data Residency/GHES)

    要件で選ぶ提供形態。GHEC with EMU(ID 完全管理)、GHEC with Data Residency + EMU(データ所在地を指定)、個人アカウントの GHEC、GHES(完全自社管理)。

    前提: GitHub Enterprise Cloud(GHEC)GitHub Enterprise Server(GHES)マネージドサービス(管理の境界)

    関連: データ所在地(Data Residency)

  • Enterprise チーム

    Enterprise 配下の複数 Organization にまたがってメンバーシップ・ロール・ポリシー(ガバナンス)を一元管理できる上位のチーム概念。一度定義したチームを多数の Organization に割り当てられる。ネストや親権限の継承は Organization レベルのチームの機能で、Enterprise チームには当てはまらない。

    前提: OrganizationTeam(チーム)

  • GitHub Connect

    GitHub Enterprise Server/Cloud と GitHub.com を連携し、ライセンス同期・統合検索・サーバーからの Actions 利用などを有効にする機能。

    前提: GitHub ActionsGitHub EnterpriseGitHub Enterprise Server(GHES)LICENSE

  • 組織ロール(owner/member/security manager)

    組織全体を統制するオーナー、一般のメンバー、特定の管理権限を切り出した security manager など。オーナーは強力なため付与は最小限に。

    前提: security manager(役割)Organization

  • リポジトリロール

    リポジトリへのアクセスレベル。Read / Triage / Write / Maintain / Admin の段階があり、加えてカスタムリポジトリロールで権限を細かく定義できる。権限は個人ではなくチーム単位で割り当てるのが原則。

    前提: Team(チーム)

    関連: カスタムリポジトリロール

  • サポートバンドル / 診断

    GHES が生成する診断情報の一式。GitHub Support 案件(障害・不具合・システム障害)の調査のために提供する。

    前提: GitHub SupportGitHub Enterprise Server(GHES)

  • チーム同期(team synchronization)

    IdP のグループを GitHub のチームメンバーシップに対応づけ、グループの増減を自動でチームへ反映する機能。グループ管理を IdP に一元化できる。GitHub 側で手動追加したメンバーと競合し得る。

    前提: Team(チーム)

  • 使用レポート(usage report)

    従量製品の消費量を組織/リポ別・傾向で把握するレポート。予算管理やチャージバック、コスト最適化の判断に使う。

    関連: 従量課金(metered)

  • IP 許可リスト

    許可した IP 範囲からのみアクセスを受け付ける組織設定。GitHub ホスト型の送信元 IP は変動するため、固定が要れば larger ランナーの静的 IP やセルフホストを併用する。

    前提: larger ランナーランナー(runner)

  • ジョブ outputs

    ステップ出力をジョブの outputs に割り当て、後続ジョブが needs.<job>.outputs.<name> で読めるようにする仕組み。別ジョブへ短い値を渡す。

    前提: $GITHUB_OUTPUTジョブ(job)needs(ジョブ依存)ステップ(step)

  • paths / branches フィルター

    push/pull_request の起動対象を絞るフィルター。paths/paths-ignore でファイル、branches/branches-ignore でブランチを指定し、不要な実行を起こさずコストを節約する。

    前提: push / pull_request イベント

  • ランナーグループ

    セルフホストランナーをまとめ、どの組織/リポジトリが使えるかを制御する単位。機密性の高いランナーを特定リポジトリだけに限定できる。

    前提: セルフホストランナーランナー(runner)

  • runs-on

    ジョブを実行するランナーを選ぶキー。ubuntu-latest 等の GitHub ホスト型ラベルや、セルフホストのラベルを指定する。

    前提: ランナー(runner)

    関連: ジョブ(job)

  • SHA ピン留め

    サードパーティアクションを uses: owner/repo@<フルコミットSHA> で参照すること。タグは付け替え可能なため、改ざん防止には不変な SHA が最も安全。@main 等の流動的参照は避ける。

  • スターターワークフロー

    新しいワークフローを作るときの雛形(テンプレート)。組織の .github リポジトリの workflow-templates に置き、メンバーが選んでコピーする。コピー後は独立し、元の更新は波及しない。

    前提: ワークフロー(workflow)Star

  • ツールキャッシュ(toolcache)

    GitHub ホスト型ランナーにプリインストールされた言語ランタイム/ツールの版を確認できる仕組み。ランナーイメージのリリースノートと併せて参照する。

    前提: キャッシュ(actions/cache)GitHub ホスト型ランナーReleasesランナー(runner)

  • 予防優先とゲートベース

    予防優先は源流で問題を混入させない戦略(Push Protection 等)。ゲートベースはマージ/デプロイ前の必須チェックで脆弱なものを通過させない戦略(Code Scanning/Dependency Review 必須化)。排他ではなく多層で併用する。

    前提: Code scanningpush / pull_request イベントSecret scanning

    関連: Dependency Review

  • サプライチェーンセキュリティ

    ソフトウェアのサプライチェーン(依存パッケージや成果物)を保護する上位概念。GitHub では依存関係グラフ、Dependabot(脆弱性アラート・更新)、Dependency Review、SBOM 出力などを含み、直接依存だけでなく推移的依存も対象とする。

    前提: Dependabot依存関係グラフDependency ReviewSBOM(ソフトウェア部品表)

  • 担当者(assignee)

    Issue や Pull Request の対応責任者として割り当てる 1 名以上のユーザー。検索修飾子 assignee: で絞り込め、通知やダッシュボードでの自分のタスク把握に使う。レビュー担当を示す reviewer とは役割が異なる(reviewer は変更内容の査読者)。

    関連: Issue テンプレートラベル(GitHub)Issue検索修飾子(qualifiers)

  • GitHub Packages

    npm・Maven・NuGet・RubyGems・コンテナ(GitHub Container Registry / GHCR)などのパッケージをリポジトリ近傍でホスティングする機能。権限は GitHub の認可と統合し、Actions から発行/取得できる。

    前提: GitHub Actionspermissions(トークン権限)

  • Markdown

    軽い記法で書式を表す記法(.md)。Issue・PR・コメント・README で広く使う。

    前提: Issue

    関連: README

  • OAuth App

    ユーザーに代わって(on behalf of the user)GitHub にアクセスする連携方式。認可時にユーザーが持つ権限の範囲でスコープ(scope)を選び、そのユーザーの権限を借りて動作するため、GitHub App のようなリポジトリ単位の細かい権限指定はできない。個人の手軽なトークンである PAT(Personal Access Token)とも区別される。

    前提: permissions(トークン権限)Personal Access Token(PAT)

    関連: GitHub App

  • Personal Access Token(PAT)

    権限・期限・対象を絞れるトークン。Git 操作の認証にパスワード代わりに使う(fine-grained 推奨)。

  • 消費ベースの課金(従量課金)

    確保した容量ではなく実際に使った分だけ支払う料金体系。初期投資が不要で無駄が少ない。

  • Enterprise Managed Users(EMU)

    企業が自社の ID 基盤(IdP)で一元管理する専用ユーザー。個人アカウントとは切り離される。

    前提: ID プロバイダー(IdP)

  • 監査ログのストリーミング

    監査ログ(誰が・いつ・何を)を SIEM など外部基盤へ継続的に転送し、横断分析・長期保管・早期検知に使う仕組み。

    前提: 監査ログとサインインログ

  • サードパーティ Vault 連携

    外部のシークレット管理基盤(HashiCorp Vault 等)に OIDC などで接続し、認証情報を実行時に動的取得する方式。GitHub に長期保存しないため漏えい面を減らせる。

    前提: OIDC フェデレーション(CI/CD)暗号化シークレットと変数(secrets / vars)

  • アクション入力(INPUT_/getInput)

    with: で渡した入力をアクション内で読む方法。環境変数 INPUT_<名前>、JavaScript アクションでは @actions/core の getInput を使う。

    前提: GitHub Actionsアクションの種別(JavaScript/Docker/コンポジット)inputs(ワークフロー入力)

  • concurrency(同時実行制御)

    同じグループの実行を同時に 1 つに制限する仕組み。cancel-in-progress: true で新しい実行開始時に進行中の古い実行を自動キャンセルし、最新だけ検証してコストを節約できる。

  • 構成変数(リポジトリ/環境/組織変数)

    機密でない設定値をリポジトリ・環境・組織レベルで定義し vars コンテキストで参照する仕組み。秘匿値はシークレットを使う(変数は値がログに見えうる)。

    前提: コンテキスト(contexts)環境(environment)と保護ルール暗号化シークレットと変数(secrets / vars)

  • 式(${{ }})

    ${{ }} の中で評価される式。if: や値の埋め込みに使う。解析時(静的)と実行時(動的)の評価の違いがあり、シークレットを式やログに漏らさないことが重要。

    前提: 暗号化シークレットと変数(secrets / vars)

  • $GITHUB_OUTPUT

    ステップ出力を設定する特殊ファイル。echo "name=value" >> "$GITHUB_OUTPUT" で書き、同一ジョブ内は steps.<id>.outputs.<name> で参照。短い値の受け渡しに使う。

    前提: ジョブ(job)ステップ(step)

  • if(条件分岐)とステータス関数

    ジョブ/ステップの実行可否を式で制御する。success()・failure()・cancelled()・always() のステータス関数で、失敗時のみ・常時などを表現する。

    前提: 式(${{ }})ジョブ(job)ステップ(step)

  • 不変(immutable)アクション

    リリース済みアクションのバージョンを書き換え不能にし、参照したバージョンが後から差し替えられないことを保証する仕組み。SHA ピン留めと合わせサプライチェーンの安全性を高める。

    前提: GitHub ActionsSHA ピン留めReleases

  • include / exclude(matrix)

    include は matrix に特定の組み合わせを追加(または値を付与)し、exclude は不要な組み合わせを除外する。

    関連: strategy.matrix

  • 保持期間(retention)

    ログ・アーティファクト・実行を保持する期間。リポジトリ/組織で設定し、upload 時の retention-days でも調整。REST API で保持ポリシーを管理でき、ストレージ課金に影響する。

    関連: アーティファクト(artifact)

  • secrets: inherit

    再利用可能ワークフローの呼び出し側が、自分の持つすべてのシークレットをまとめて継承させる指定。

    前提: 暗号化シークレットと変数(secrets / vars)ワークフロー(workflow)

    関連: workflow_call(再利用可能ワークフロー)

  • ワークフローコマンド

    ログのアノテーション(::notice::/::warning::/::error::)、秘密値のマスク(::add-mask::)、ログの折りたたみ(::group::)など、ランナーと対話する特殊な出力コマンド。

    前提: アノテーションワークフロー(workflow)ランナー(runner)

  • .github/workflows

    リポジトリ内でワークフロー YAML を置く既定のディレクトリ。ここに置かれた YAML が Actions として認識される。

    前提: GitHub Actionsワークフロー(workflow)YAML

  • YAML アンカー / エイリアス

    同一ファイル内で繰り返す断片を再利用する YAML 機能(アンカー & / エイリアス * / マージキー <<)。パーサーが展開してから評価される。複数ファイル間の共有には使えない(その場合は再利用可能ワークフロー)。

    前提: ワークフロー(workflow)workflow_call(再利用可能ワークフロー)YAML

  • アラートの dismiss(却下)と所有権

    アラートの却下は誤検知や許容できる場合に理由を記録して慎重に行う(安易な却下はリスクの放置)。所有権を明確にして誰が対応・修復するかをはっきりさせ、放置や重複対応を防ぐ。

  • Dependabot アラートとセキュリティ更新

    Dependabot アラートは依存の既知脆弱性(Advisory/CVE)を通知。セキュリティ更新は安全な版へ上げる PR を自動作成。バージョン更新は脆弱性に関係なく定期的に最新化(両者は別物)。

    前提: Dependabot

  • Dependency Review

    PR で追加/更新される依存の差分をマージ前に検査し、脆弱な依存や不許可ライセンスの混入をブロックするゲートベースの予防。必須チェックにできる。

    関連: 予防優先とゲートベース

  • security manager(役割)

    セキュリティ方針の監督・アラート管理・例外承認を担う役割。コードの書き込み権限とは独立に、必要な人へ最小権限で付与できる。

  • README

    プロジェクトの入口となる説明(概要・使い方・貢献方法など)。Markdown で書く。

    関連: Markdown

  • シングルサインオン(SSO)

    一度のサインインで複数のアプリにアクセスできる仕組み。

  • 可視性(Public/Private/Internal)

    リポジトリの公開範囲。Public=誰でも、Private=許可者のみ、Internal=同じ Enterprise 内。

  • GitHub Copilot

    IDE・CLI・GitHub.com で使える AI コーディング支援。提案は人がレビューして責任を持って採否する。

  • アクション利用ポリシー

    使えるアクションの範囲を統制する組織/Enterprise 設定。すべて無効/すべて許可/GitHub 製のみ/GitHub 製+検証済み/特定アクションの許可リスト、から選ぶ。外部アクションの SHA ピン留め必須化も可能。

    前提: GitHub ActionsSHA ピン留め

  • ACTIONS_STEP_DEBUG

    シークレットに設定するとステップ実行のデバッグログを有効化する変数。通常ログで原因が分からない失敗の調査に使う。

    前提: 暗号化シークレットと変数(secrets / vars)ステップ(step)

  • max-parallel

    matrix の同時実行数の上限。コストとランナー枠を調整するために使う。

    前提: strategy.matrixランナー(runner)

  • Re-run failed jobs / Re-run all jobs

    失敗したジョブだけを個別に再実行する操作と、実行全体を再試行する操作。matrix の特定バリアントだけ落ちたときは前者、一時的(flaky)な失敗は後者が効率的。

    前提: ジョブ(job)strategy.matrix

  • schedule(cron)

    cron 式で定期実行するトリガー。cron は UTC 基準で、最短間隔の制約や混雑時の遅延があり、リポジトリが非アクティブだと停止する。

    前提: 式(${{ }})

  • スクリプトインジェクション

    PR タイトルや Issue 本文などの信頼できない入力を run: のシェルコマンドに直接埋め込むと、攻撃者のコマンドが実行される脆弱性。値を環境変数に入れて引用し、検証・最小権限・検証済みアクションで緩和する。

    前提: GitHub ActionsIssue

  • ステータスバッジ

    README に貼る SVG バッジで、特定ブランチ/イベントのワークフローの最新結果(成功/失敗)を一目で可視化する。

    前提: ワークフロー(workflow)README

  • $GITHUB_STEP_SUMMARY

    Markdown を追記すると実行ページにリッチなジョブサマリー(テスト結果表・カバレッジ・リンク等)として表示される特殊ファイル。

    前提: ジョブ(job)Markdown

  • workflow_dispatch

    UI/API/CLI から手動で起動するトリガー。inputs に type/required/default/options を定義して起動時にパラメーターを受け取れる。

    関連: inputs(ワークフロー入力)

  • Agent Mode

    ゴールを与えると、計画→編集→ビルド/テストで検証→修正を自律的に反復するモード。必要なファイルやコマンドも自ら判断する。

    前提: needs(ジョブ依存)

  • Copilot Chat

    自然言語で質問・コード生成・説明・修正・テスト作成を依頼できる会話型のサーフェス。選択範囲やファイルを文脈として渡せる。

    前提: コンテキスト(contexts)

  • 重複検出

    公開コードと一致する提案をブロック/抑制するセーフガード。ライセンス上の懸念を減らす。補助であり採用後のライセンス確認の責任は残る。

    前提: LICENSE

  • 出力の所有権とライセンス

    採用したコードの所有権と責任は採用した利用者/組織にある。出力は公開コードと一致し得るためライセンスに配慮し、重複検出で対応する。

    前提: 重複検出アラートの dismiss(却下)と所有権

  • 委譲バイパス / 委譲例外

    Push Protection 等のブロックやポリシーを、承認制で一時的に回避/例外扱いできる仕組み。誰が承認できるかをアクセス管理で統制し、記録して監査可能にする(恒久免除ではない)。

    前提: push / pull_request イベントSecret scanning

  • EPSS(Exploit Prediction Scoring System)

    脆弱性が実際に悪用される確率を推定するスコア。深刻度(CVSS)と組み合わせて「深刻かつ悪用されやすい」ものを優先するために使う。

    前提: Issue

    関連: CVSS(深刻度)

  • SBOM(ソフトウェア部品表)

    含まれる依存とバージョンを標準形式(SPDX・CycloneDX)で列挙した「部品表」。依存関係グラフからエクスポートでき、規制対応やサプライチェーンの透明性に使う(脆弱性一覧そのものではない)。

    前提: 依存関係グラフ

  • シフトレフト

    セキュリティを開発の早い段階へ前倒しして問題が大きくなる前に防ぐ考え方。Push Protection・依存スキャン・マージ前解析で早期予防する。後工程ほど修復コストが高くなる。予防は検出/修復を置き換えない(多層で)。

    前提: push / pull_request イベントSecret scanning

  • GitHub Marketplace

    GitHub と連携するアプリや Actions のワークフローを見つけて導入できるマーケットプレイス。CI/CD やコード品質などの機能を拡張する。

    前提: GitHub Actionsワークフロー(workflow)

  • Wiki とリポジトリインサイト

    Wiki でプロジェクトの長文ドキュメントを管理し、README で概要を示す。Insights でコントリビューションやトラフィック、依存関係グラフなどリポジトリの状態を可視化する。

    前提: 依存関係グラフREADME

  • GitHub Mobile

    スマートフォンから通知の確認・Issue/PR の操作・レビューができる公式アプリ。Copilot Chat にもモバイルから利用できる。

    前提: Copilot ChatIssue

  • .gitignore

    追跡したくないファイル/パターン(ビルド成果物・依存・秘密情報など)を除外する指定ファイル。

    前提: include / exclude(matrix)暗号化シークレットと変数(secrets / vars)

  • マネージドサービス(管理の境界)

    AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

  • Milestone

    リリースや期限の単位で Issue/PR をまとめ、達成率や期限を可視化する機能。

    前提: Releases

    関連: Issue

  • リモート(origin)

    リポジトリの保管先への名前付き参照。clone 時の複製元は既定で origin になる。

    前提: clone

  • 検索修飾子(qualifiers)

    is:/label:/author:/assignee: など、検索を種類・状態・担当などで絞り込むキーワード。複数は AND。

    関連: 担当者(assignee)

  • upstream

    フォーク元(本家)を指す慣習的なリモート名。自分の fork は origin。

    前提: fork(フォーク)リモート(origin)

  • Twelve-Factor App(十二要素)

    クラウドネイティブなアプリ設計の原則集。設定は環境変数へ外出し、プロセスはステートレス、ログはイベントストリームとして扱う、廃棄容易性、開発/本番の一致など。スケールしやすく移植性の高いアプリの指針。

    前提: 暗号化シークレットと変数(secrets / vars)

  • clone

    既存リポジトリを履歴ごとローカルに複製する操作(git clone)。

  • 行動規範(Code of conduct)

    コミュニティ参加者に期待する振る舞いと違反時の対応を定めた文書。CONTRIBUTING(貢献手順)やライセンスとともに健全な OSS 運営を支える。

    前提: LICENSE

  • CODEOWNERS

    特定パスを変更する PR に、自動でレビュアーを割り当てるための定義ファイル。

  • GitHub Discussions

    質問・アイデア共有などの会話に適した場。作業の追跡は Issues を使う。

    前提: Issue

  • action.yml(メタデータ)

    アクションのルートに必須のメタデータファイル。name・description・inputs・outputs・runs(using=node20/docker/composite)・branding を定義する。runs.using と実装が一致していないと起動しない。

    前提: inputs(ワークフロー入力)

  • アノテーション

    ログ上でエラーや警告を要約表示し、該当行へジャンプできる表示。失敗の原因特定に役立つ。

  • fail-fast

    matrix 戦略の設定。true(既定)で 1 つ失敗すると残りを打ち切り、false で全組み合わせを最後まで実行する。原因切り分けには false。

    前提: strategy.matrix

  • github コンテキスト

    イベントやリポジトリの情報を持つコンテキスト。github.ref(ブランチ/タグ参照)や github.event(イベントペイロード)などを参照できる。

    前提: コンテキスト(contexts)

  • $GITHUB_ENV

    実行時に生成した値を環境変数として後続ステップへ渡す特殊ファイル。echo "KEY=value" >> "$GITHUB_ENV" のように追記する。

    前提: ステップ(step)

  • メジャーバージョンタグ(@v4)

    利用者が @v4 のように参照するタグ。提供者は新リリースごとにメジャータグを最新コミットへ移動し、利用者は修正を自動で受け取る。

    前提: Releases

  • repository_dispatch

    外部システムが API(POST)でカスタムイベント名を付けて起動するトリガー。外部連携に使う。

  • 実行履歴(run history)

    同じワークフローの過去の実行一覧。いつ・どの変更から失敗し始めたかを特定し、原因切り分けに使う。

    前提: ワークフロー(workflow)

  • サービスコンテナ(services:)

    ジョブ実行中だけ補助コンテナ(DB・キュー等)を起動する仕組み。ポートマッピングとヘルスチェックを設定でき、外部 DB なしで統合テストを再現できる。

    前提: ジョブ(job)

  • setup-* アクション

    actions/setup-node などの公式アクションで、実行時に指定バージョンのツールを用意する。プリインストールに無い版を入れるときに使う。

    前提: GitHub Actions

  • 検証済み作成者(verified creator)

    GitHub が検証したアクション作成者。利用ポリシーで「GitHub 製+検証済み」のアクションのみ許可、といった統制に使う。

    前提: GitHub Actions

  • エージェントセッション

    Agent Mode の作業を管理する単位。進行状況の確認・中断・再開ができる。

    前提: Agent Mode

  • 監査ログイベント(Copilot)

    ポリシー変更やアクセスなどの操作を「誰が・いつ・何を」追跡する仕組み。コードの内容を保存するものではない。

    前提: 監査ログとサインインログ

  • GitHub Copilot CLI

    ターミナルから Copilot を使う仕組み。コマンドの提案・説明、シェルスクリプト生成、ファイル操作を自然言語で行う。IDE 拡張とは別にインストール・認証する。

    前提: GitHub Copilot

  • Copilot Code Review ポリシー

    組織の基準に沿って Copilot のコードレビュー支援を展開するためのポリシー。人によるレビューを置き換えるものではない。

    前提: コードレビュー(Pull Request)

  • コンテンツ除外

    特定のファイルやリポジトリを Copilot の文脈・提案の対象から外す設定。機密や規約上 AI に渡せないコードを守る。管理者がリポ/組織レベルで設定し、対象では補完が出ない。

    前提: コンテキスト(contexts)

  • コンテキストの収集とプロンプト構築

    カーソル周辺・開いているファイル・関連ファイルから関連性の高い情報を選び、モデルに渡すプロンプトを組み立てる入力処理。除外ファイルは対象外。

    前提: コンテキスト(contexts)

  • コンテキストスイッチの削減

    未知の API やエラーの意味を Chat で尋ねることで、ブラウザやドキュメントへ移る切り替えを減らし、開発の流れを保つこと。

    前提: コンテキスト(contexts)

  • Copilot 対応エディタ/IDE

    GitHub Copilot は Visual Studio Code・Visual Studio・JetBrains 系 IDE・Neovim などに拡張として組み込んで使える。補完や Chat はエディタ上で動作する。

    前提: GitHub Copilot

  • インライン補完

    カーソル位置の文脈から「続き」をグレー表示で提案する機能。受け入れる(確定する)まではコードに反映されない。

    前提: コンテキスト(contexts)

  • instructions ファイル

    コーディング規約やレビュー基準を与え、Copilot に一貫した観点でレビュー/応答させる常時適用の設定ファイル。

  • 提案のライフサイクル

    文脈変化→プロンプト生成→モデル生成→候補提示→受け入れ/却下→新しい文脈で次の提案、という循環。受け入れた内容は次の文脈に影響する。

    前提: コンテキスト(contexts)

  • レガシーコードの近代化

    古い構文・非推奨 API・冗長な実装を現代的な書き方へ書き換える支援。意味的等価性をテストで確認してから採用する。

    前提: 意味的等価性

  • Copilot 組織ポリシー(機能の可用性)

    Enterprise/組織レベルで、どの Copilot 機能を誰がどう使えるかを管理する設定。IDE と github.com の双方に及び、個人設定より上位。

    前提: ポリシー(メンバーができること)

  • 確率的生成

    LLM が確率的に出力を生成する性質。同じ文脈でも出力が揺れ、常に最適とは限らない(不具合ではない)。

    前提: コンテキスト(contexts)

  • プロンプトファイル

    再利用する定型の指示をファイル化し、Chat で一貫した応答を得るための仕組み。常時適用の instructions ファイルとは用途が異なる。

    前提: instructions ファイル

  • サブスクリプション(シート)管理

    Copilot のシート割り当て・解除・利用状況取得の管理。UI のほか REST API から自動化でき、入退社に応じたシート運用に使う。

    前提: ライセンス(シート)

  • 意味的等価性

    リファクタや近代化の前後で挙動が変わっていないこと。テストで確認し、「動く別物」になっていないかを防ぐ。

  • Spaces(Copilot)

    関連するコード・ドキュメント・指示をまとめて文脈として束ねる場。Copilot に一貫した文脈を与える。

    前提: コンテキスト(contexts)

  • Sub-Agent(サブエージェント)

    大きなタスクや膨らむ文脈に対し、サブタスクを委譲する下位エージェント。各エージェントのコンテキスト使用を最適化する。

    前提: コンテキスト(contexts)

  • AI 出力の検証

    Copilot の出力を採用前に確認する必須運用要件。コードレビュー・テスト・セキュリティスキャン・事実確認で行い、生成テスト自体も検証する。

    前提: コードレビュー(Pull Request)

  • autofix(Copilot Autofix)

    検出した脆弱性に対する修正案を自動提示する機能。開発者はレビューして採用するが、提案も誤り得るため検証してからマージする。

  • カスタムシークレットパターン

    組織独自のトークンや社内システムの鍵を検出するため、正規表現で定義するパターン。既定パターンで拾えない秘密に対応する。緩すぎる正規表現は誤検知を増やすためテストで調整する。

    前提: 暗号化シークレットと変数(secrets / vars)

  • CVSS(深刻度)

    Common Vulnerability Scoring System。脆弱性の深刻度を数値化する標準。優先順位付けでは EPSS(悪用確率)や到達可能性・資産重要度と併用する。

    関連: EPSS(Exploit Prediction Scoring System)

  • データフロー解析(source→sink)

    CodeQL が「危険な値がどこ(source)から入り、どこ(sink)で悪用され得るか」を経路として示す解析。原因と影響範囲、検証/サニタイズを入れる箇所が分かる。

  • GitHub Security Advisory(GHSA)

    GitHub Advisory Database に収録される脆弱性情報。Dependabot の検知の裏付け。リポジトリのセキュリティアドバイザリを使うと、自プロジェクトの脆弱性を非公開で修正してから公開できる。

    前提: Dependabot

  • グルーピングと自動却下(依存更新)

    グルーピングは関連する依存更新を 1 PR にまとめてノイズを減らす。自動却下は低リスクなアラートを条件で自動取り下げ(緩すぎると本物を取り下げる)。dependabot.yml で更新戦略を設定。

    前提: Dependabot

  • セキュリティルールセットと強制境界

    必須機能・必須チェック・修復 SLA などを定義し組織横断で強制する仕組み。強制境界で適用範囲(Enterprise 全体/特定組織/特定リポ群)を定める。定義だけでなく強制してこそ守られる。スイート横断で複数の柱をまとめて強制できる。

    前提: ルールセット(ruleset)

  • SARIF

    コード解析結果の交換フォーマット(Static Analysis Results Interchange Format)。サードパーティ SAST の SARIF を GitHub にアップロードすると Code Scanning アラートとして一元管理でき、CodeQL と共存できる。

    前提: Code scanning

  • 検証(validity check)

    検出されたトークンが今も有効(active)かを発行元 API 等で確認し、高信頼な秘密を優先してアラートする仕組み。失効済みやダミーに振り回されず優先順位付けを効かせる。

    前提: 暗号化シークレットと変数(secrets / vars)

  • GitHub Projects

    Issue や Pull Request を横断して計画・追跡する柔軟なプロジェクト管理ツール(Projects v2)。ボード/テーブル/ロードマップのビュー、カスタムフィールド、組み込みの自動化を備える。

    前提: Issue

  • Infrastructure as Code(IaC)

    インフラをコード(テンプレート)で宣言的に定義し、再現可能・バージョン管理可能にする考え方。手作業のドリフトを防ぎ、レビュー・自動化・複数環境の一貫構築を可能にする。AWS では CloudFormation・CDK が代表。

    前提: 環境(environment)と保護ルール

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  • 最小権限の原則

    各アイデンティティ(人・アプリ・サービス)には、業務の遂行に必要な最小限の権限だけを与えるという設計原則。過剰な権限は誤操作や侵害時の被害範囲(ブラスト半径)を広げるため、IAM ロールやポリシー、権限境界を通じて継続的に絞り込む。

    前提: permissions(トークン権限)

  • GitHub Sponsors

    OSS の開発者やプロジェクトを金銭的に支援する仕組み。Star(無償のお気に入り)とは別。

    前提: Star

  • ステージングエリア(インデックス)

    次のコミットに含める変更を選んで置く場所。git add で追加する。

    前提: include / exclude(matrix)

  • TLS

    通信を暗号化し、証明書によってサーバー(要件次第ではクライアントも)を認証するプロトコル。ハンドシェイクで鍵交換と認証を行った後、対称鍵でデータを暗号化して送受信する。クラウドのロードバランサやCDNで終端し、証明書はマネージドサービスで発行・更新するのが一般的。

    前提: マネージドサービス(管理の境界)

  • Watch

    リポジトリの更新通知を購読する操作。Star とは別物。

    前提: Star