GitHub Actions OIDC設定完全移行ガイド2026年4月版

ITエンジニア GitHub Actions OIDC設定完全移行ガイド2026年4月版

GitHub Actionsを鍵レスCIへ移行したいけど、Environment承認、OIDCのロール条件、cronの時差が絡んで途中で止まる人は多いですよね。この記事は、GitHub Actions OIDC 設定を2026年4月時点でやり切りたい人に向けて書きました。読むと、deployment:falseで履歴ノイズを消しながら、Environment secretsとJST cronを同時に安全運用する設計まで具体的に組めるようになります。

公開前確認（2026年5月時点）：GitHub Actionsのクラウド認証は長期シークレットからOIDCへ寄せるのが基本です。移行時はenvironment保護、最小権限、audience/subject条件、ロールバック用の短期手順を同時に確認してください。

こんな方におすすめ

  • GitHub Actionsの長期AWSキーをやめたいけど移行手順が曖昧な方
  • deployment false GitHub Actionsの使いどころを実務目線で知りたい方
  • GitHub Actions Environment secrets JST cronを1本の設計でまとめたい方
  • 承認フローを維持しつつデプロイ履歴ノイズだけ減らしたい方

この記事でわかること

  • 2026年3月アップデートで設計自由度が上がったポイント
  • OIDCを使った鍵レスCIへの段階移行ステップ
  • JST cronをUTC換算なしで運用する実装方法
  • 現場で多い失敗パターンとチェックリスト
僕は福祉事業のIT全般を担当しながら、AI×SaaS開発の準委任案件と個人の受託開発を並行しています。複数現場でGitHub Actionsを運用してきた経験をもとに、非IT部門にも伝わる言葉で整理していきます。
目次

2026年3月アップデートで何が変わったか

まず前提を揃えます。2026年3月はGitHub Actions運用の転換点でした。3月12日にOIDCトークンへrepo_property_*クレームを載せられる更新が入り、3月19日にEnvironment参照時の自動Deployment作成を止めるdeployment: falseと、on.schedule.timezoneが同時に公開されています。つまり、秘密情報の境界はEnvironmentで管理しつつ、履歴ノイズは減らし、認証は短命トークン化し、時刻運用はIANA timezoneで統一できる状態になりました。

イメージとしては、いままで「セキュリティを上げるほど運用が重くなる」トレードオフがありましたが、2026年3月以降はそのへんを分離できるようになったということです。機密情報・認証・実行時刻を別レイヤーで設計できるので、チーム全体の事故率を下げながら開発速度も落としにくくなります。

論点 2026年2月まで 2026年3月以降 実務メリット
Environment利用時の履歴 Deploymentが毎回作成 deployment:falseで抑制 CI専用ジョブの履歴が見やすい
定時実行の時刻指定 UTC換算が必要 IANA timezone指定が可能 JST運用で設定ミスが減る
OIDCの属性設計 repo/branch中心 repo_property_*を追加可能 ABAC設計を細かくできる

鍵レスCIの設計図: Environment secrets × OIDC × JST cron

ここからは実装前の設計図です。僕が現場でやっているのは、Environmentを「機密情報の境界」、OIDCを「認証の橋」、cron timezoneを「運用カレンダー」として役割分担する方法です。1本のworkflowに詰め込む前に、責務を3つへ分割すると設計が崩れにくいです。

  1. 機密情報の境界を固定 — APIキーや接続情報はEnvironment secretsへ集約します。
  2. 認証を短命化 — permissions: id-token: writeを付け、クラウド認証はOIDCで発行する一時トークンに寄せます。
  3. 実行時刻を業務時刻で管理 — timezone: "Asia/Tokyo"を使って運用ドキュメントと同じ時刻表記に揃えます。

この分け方にすると、セキュリティレビューと運用レビューを別々に進められるので、承認が早くなります。僕の体感でも、要件整理のミーティング時間がかなり短くなりました。逆にこの分離をせずに進めると、「どこで失敗したか」が見えにくくなって修正が長引きます。

permissions:
  contents: read
  id-token: write

on:
  schedule:
    - cron: '0 9 * * 1-5'
      timezone: 'Asia/Tokyo'

jobs:
  ci:
    runs-on: ubuntu-latest
    environment:
      name: staging
      deployment: false

この最小形を先に通すと、GitHub Actions Environment secrets JST cronの土台が一気に揃います。つまり、まずは小さく成功させてからロール条件を厳しくしていくのがおすすめです。

deployment false GitHub Actions実装パターンと制約

deployment:falseの本質は「Environmentを参照してもDeployment履歴を作らない」設定です。ここを誤解すると、秘密情報まで使えなくなると思って止まりがちですが、公式DocsではEnvironment secrets/varsは利用可能と明記されています。なのでCI専用ジョブではかなり使いやすいです。

ただし注意点があります。custom deployment protection ruleをEnvironmentに付けている場合、deployment:falseは非互換でジョブが即失敗します。このケースは実際にハマる人が多いです。required reviewersやwait timerは継続適用されるので、「履歴だけ消えて承認も消える」わけではありません。さらに、承認待ちは30日で自動失敗です。リリース計画が長期化しやすいチームは、この30日ルールを運用手順書へ先に入れておくと安全です。

実装時のチェックポイント

  • 互換性 — custom deployment protection rule利用中なら別Environmentを切る
  • 承認期限 — 30日未承認で失敗する前提を運用に明記する
  • 式の活用 — deployment: ${{ github.ref_name == 'main' }}で条件切替も可能

このへんを押さえると、CIと本番デプロイを同じEnvironmentに無理やり載せる必要がなくなります。役割ごとにEnvironmentを分ける設計が、結果的に一番トラブルが少ないです。

GitHub Actions OIDC 設定の完全移行手順（AWS例）

ここは実作業のコアです。OIDC移行で一番大事なのは「GitHub側設定」と「クラウド側trust policy」を同時に揃えることです。片方だけ正しくても認証は通りません。手順は次の順番で進めると詰まりにくいです。

  1. Workflow権限を最小追加 — id-token: writeとcontents: readを設定します。
  2. Environment名を先に確定 — 例: prod。後でsub条件と一致させます。
  3. AWS IAM trust policyを作成 — aud=sts.amazonaws.comとsub=repo:ORG/REPO:environment:prodを条件化します。
  4. 短命トークンでAssumeRole — 長期アクセスキーをSecretsから削除します。
  5. repo_property_*で属性拡張 — チームやシステム区分でABAC条件を足します。
{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:environment:prod"
    }
  }
}

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

GitHub Actions Environment secrets JST cronの実運用

JST運用は地味ですが、放置すると障害の温床になります。workflow syntaxではscheduleはUTCが基本ですが、いまはtimezone指定が使えるので、業務時刻と設定時刻を一致させられます。例えば平日9時バッチなら次のように書けます。最短実行間隔は5分なので、細かい監視ジョブを組む場合も設計しやすいです。

on:
  schedule:
    - cron: '0 9 * * 1-5'
      timezone: 'Asia/Tokyo'
    - cron: '0 18 * * 1-5'
      timezone: 'Asia/Tokyo'
  • 検証1 — 手動実行とschedule実行の時刻差をログで比較します。
  • 検証2 — 休日運用があるならcron式を分離して誤起動を防ぎます。
  • 検証3 — 外部システムが海外時刻の場合、受け口側のタイムゾーンも同時確認します。
DSTがある地域を含む運用では、無効時刻が指定されると「次の有効な時刻」へ繰り上げ実行されます。日本中心でも、連携先が海外拠点ならこの仕様を共有しておくと混乱を防げます。

つまり、GitHub Actions Environment secrets JST cronは「書ける」だけでなく「チーム全員が読める」形へ落とし込むのがポイントです。時刻の共通言語を作ると、運用ミスはかなり減らせます。

典型エラーと移行チェックリスト

最後に、現場で再現しやすい失敗をまとめます。特にNot authorized to perform sts:AssumeRoleWithWebIdentityは、権限不足より条件不一致のほうが原因になりやすいです。ここはログを見ながら機械的に切り分けるのがおすすめです。

  • id-token未付与 — Workflowにid-token: writeがなくJWT取得できない
  • sub不一致 — trust policyがbranch形式、実行側がenvironment形式
  • aud不一致 — sts.amazonaws.com以外で評価して失敗
  • Environment境界ミス — CI用と本番用のsecretsを同じ箱に入れてしまう

さらに、deployment:falseとcustom deployment protection ruleの併用は失敗するので、ここは設計段階で分けるのが安全です。僕は移行時に「1ジョブずつ鍵を剥がす」進め方を採用しています。1回で全削除すると、どこで壊れたか追えなくなるからです。より詳しい運用相談が必要な方は、技術と働き方の両面を整理できる個別相談の窓口も使ってください。実案件ベースで優先順位を一緒に決められます。

この移行を後回しにしたときの運用コスト

長期アクセスキー運用を続けると、漏えい時の影響範囲が大きくなります。timezone未整備のままだと、定時バッチがズレて問い合わせ対応が増える可能性があります。さらに、Environment境界を曖昧にすると、CIと本番の秘密情報が混ざって監査が重くなります。知らないまま運用すると、開発速度より先に運用負債が積み上がるので、早めに小さく移行しておくのがおすすめです。

この記事を書いている理由

僕自身、2026年3月25日にJST cron運用の記事、3月29日にARC 0.14.0とdeployment:falseの記事、3月31日にdeployment:false実践ガイドを書いてきました。その中で共通していたのが、「個別最適の情報はあるけど、全部つないだ設計が見つかりにくい」という声です。福祉事業のIT運用では、エンジニア以外のメンバーとも同じ運用ルールを共有する必要があります。だからこそ、今日から動ける1本の設計図としてまとめたいと思って書きました。

次のアクション

今日からできるアクション

  • 既存workflowにid-token: writeを追加し、長期キーを棚卸しする
  • CI用Environmentを新設し、deployment:falseで1ジョブだけ移行する
  • timezone: "Asia/Tokyo"付きscheduleを1本入れて実行ログを確認する

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

ITエンジニアの最新記事8件