MENU

GitHub documentation updateを解説：microsoft-graph-core 3.0.0移行の影響と確認ポイント

PHP

GitHubで公開された「GitHub documentation update: build(deps): update microsoft/microsoft-graph-core requirement from ^2.2.1 to ^2.2.1 || ^3.0.0」は、Microsoft Graph Beta SDK for PHPが依存するmicrosoft/microsoft-graph-coreを3.0.0系へ移行するための更新です。結論から言うと、PR名は^2.2.1 || ^3.0.0を許可するように見えますが、マージ後の実際のcomposer.jsonではmicrosoft/microsoft-graph-coreの要件が^3.0.0のみになっています。つまり確認すべきポイントは、PHP 8.2以上への対応、Composerのロックファイル、GitHub ActionsなどのCI設定、Kiota系依存関係の更新です。(GitHub)

この更新を「単なる依存関係アップデート」と見て自動マージすると、PHP 8.1以下の環境や、古いKiota関連パッケージを前提にしたプロジェクトでビルド失敗につながる可能性があります。Microsoft Graph Core SDK for PHPの3.0.0では、PHP 7.4〜8.1のサポート終了がBreaking Changeとして示されています。(GitHub)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

microsoft/microsoft-graph-core要件変更の全体像

今回のGitHub PRは、microsoftgraph/msgraph-beta-sdk-phpリポジトリのcomposer.jsonに対する変更です。対象はGitHubそのものの機能変更ではなく、GitHub上で管理されているMicrosoft Graph Beta SDK for PHPの依存関係更新です。

重要なのは、PRタイトルと最終的な差分が完全には一致していない点です。当初は^2.2.1 || ^3.0.0のように2系と3系の両方を許可する更新として作成されていますが、レビュー過程で「v3以上のみを受け入れる」方針に変更され、最終的には^3.0.0のみがマージされています。(GitHub)

項目変更内容実務上の意味
対象リポジトリmicrosoftgraph/msgraph-beta-sdk-phpMicrosoft Graph Beta SDK for PHPの利用者が確認対象
対象ファイルcomposer.jsonComposerで解決される依存関係に影響
変更前microsoft/microsoft-graph-core: ^2.2.1Core SDK 2系を許可
PR作成時の意図^2.2.1 | | ^3.0.02系と3系を両方許可する案
マージ後の実際の状態microsoft/microsoft-graph-core: ^3.0.0Core SDK 3系が前提になる
主な注意点PHP 8.2以上、Kiota 2系、ロックファイルCI・本番環境・開発環境をそろえる必要がある

Composerの^は、セマンティックバージョニングに沿って破壊的変更を避ける範囲を許可する演算子です。たとえば^3.0.0は通常、3.0.0以上かつ4.0.0未満の範囲を意味します。また、||は論理ORとして複数の範囲を許可します。(Composer)

そのため、^2.2.1 || ^3.0.0であれば2系に残る余地がありますが、^3.0.0のみになると、依存関係解決時に3系への移行が前提になります。ここが今回の最大の確認ポイントです。

何が変わるのか

変更の中心は、Microsoft Graph Beta SDK for PHPが使うCore SDKのメジャーバージョンです。microsoft/microsoft-graph-coreの3.0.0では、PHP 7.4〜8.1のサポート終了がBreaking Changeとして記載されています。これは、古いPHPバージョンを使い続けているプロジェクトにとって、インストールやCIの段階で失敗する可能性がある変更です。(GitHub)

さらに、Core SDK 3.0.0のパッケージ情報では、PHP要件が^8.2になり、Kiota関連パッケージも^2.0.2系を要求します。Core SDKを直接使っていない場合でも、Beta SDK経由で間接的に影響を受けることがあります。(Packagist)

変更前後の見方

// 変更前
"require": {
  "php": "^8.2",
  "microsoft/microsoft-graph-core": "^2.2.1"
}
// マージ後
"require": {
  "php": "^8.2",
  "microsoft/microsoft-graph-core": "^3.0.0"
}

ここで見るべき点は、Beta SDK側もPHP要件として^8.2を持っていることです。すでにBeta SDKの新しい系列を利用しているプロジェクトでは、PHP 8.2以上が前提になっている可能性があります。マージ後のcomposer.jsonでも、PHP要件は^8.2、Core SDK要件は^3.0.0になっています。(GitHub)

影響を受ける可能性が高いプロジェクト

今回の更新で最も影響を受けるのは、Microsoft Graph Beta SDK for PHPを使い、Composerで依存関係を更新しているプロジェクトです。特にGitHub ActionsでDependabot PRを自動マージしているリポジトリや、dev-mainを参照している環境では注意が必要です。

利用状況影響度確認すべきこと
microsoft/microsoft-graph-betaを利用している高次回アップデート時にCore 3系へ移行するか
microsoft/microsoft-graph-coreを直接利用している高3.0.0でPHP 8.2以上に対応済みか
PHP 8.1以下の本番環境がある高依存関係更新前にPHPランタイムを更新できるか
GitHub ActionsのPHP matrixに8.1以下が残っている中〜高テスト対象を8.2以上へ移せるか
composer.lockを固定している中すぐには変わらないが、更新時に差分が大きくなる
Packagistの安定版のみを使っている中新しいタグ公開後に影響が出る可能性がある
Microsoft Graphのbeta APIを本番利用している中SDK更新とAPI仕様変更を分けて検証する

composer.lockがあるプロジェクトでは、composer installだけではすぐにCore 3系へ変わらない場合があります。しかし、composer updateやDependabotの更新PRが入ったタイミングで、ロックファイルが更新されます。つまり「今動いているから問題ない」ではなく、「次の依存関係更新で失敗しないか」を確認する必要があります。

管理者・開発者が最初に確認すべき項目

まずは、実行環境・Composer設定・CIの3つを確認します。ここを飛ばしてコード修正から始めると、原因がコードなのか環境なのか切り分けにくくなります。

確認項目コマンドまたは確認場所判断基準
PHPバージョンphp -v8.2以上か
Composerのプラットフォーム要件composer check-platform-reqs本番相当の環境で不足がないか
現在のSDKバージョンcomposer show microsoft/microsoft-graph-beta microsoft/microsoft-graph-coreCore 2系か3系か
Core SDKを要求しているパッケージcomposer why microsoft/microsoft-graph-core直接依存か間接依存か
3.0.0へ上げられない理由composer why-not microsoft/microsoft-graph-core 3.0.0PHPや他パッケージがブロックしていないか
lockファイル更新の影響composer update microsoft/microsoft-graph-beta microsoft/microsoft-graph-core --with-all-dependencies --dry-runどの依存関係が変わるか

実務では、いきなりcomposer updateを実行するのではなく、まず--dry-runで差分を確認してください。特にMicrosoft Graph SDK周辺では、Core SDKだけでなくKiota関連パッケージも同時に更新される可能性があります。

移行手順：安全にCore 3系へ対応する流れ

事前にブランチを切る

依存関係更新は、通常の機能開発よりも影響範囲が見えにくい作業です。GitHub上では、専用ブランチを作って検証するのが安全です。

git checkout -b update-msgraph-core-3

現在の状態を記録する

更新前に、現在のPHPバージョンとパッケージ状態を残しておくと、CI失敗時の比較が楽になります。

php -v
composer show microsoft/microsoft-graph-beta microsoft/microsoft-graph-core
composer why microsoft/microsoft-graph-core

dry-runで依存関係の変化を見る

composer update microsoft/microsoft-graph-beta microsoft/microsoft-graph-core --with-all-dependencies --dry-run

ここで、PHPバージョン不足やKiota関連パッケージの競合が出た場合は、先に環境側を直します。--with-all-dependenciesを付けるのは、関連する依存パッケージも含めて解決させるためです。

問題がなければ更新する

composer update microsoft/microsoft-graph-beta microsoft/microsoft-graph-core --with-all-dependencies

Core SDKを直接指定しているプロジェクトでは、必要に応じてcomposer.jsonを次のようにします。

{
  "require": {
    "php": "^8.2",
    "microsoft/microsoft-graph-core": "^3.0.0"
  }
}

CLIで指定する場合は、シェルによる^の解釈に注意してください。迷う場合は、composer.jsonを編集してからcomposer updateを実行する方が安全です。Composer公式ドキュメントでも、Windows環境でキャレットをCLI引数として扱う際の注意が示されています。(Composer)

テストと静的解析を実行する

依存関係更新後は、最低限次の確認を行います。

composer validate
composer check-platform-reqs
vendor/bin/phpunit

PHPStanやPsalmなどの静的解析を使っている場合は、あわせて実行します。Microsoft Graph APIを呼び出す処理は、認証・リクエスト生成・レスポンス処理の3点を重点的に確認してください。

GitHub Actionsで確認すべきCI設定

GitHub Actionsを使っている場合、PHP 8.1以下のジョブが残っていると、依存関係のインストール段階で失敗する可能性があります。Core SDK 3.0.0がPHP 8.2以上を要求するためです。(Packagist)

たとえば、次のようなmatrixがある場合は見直し対象です。

strategy:
  matrix:
    php-version: ['8.1', '8.2', '8.3']

Core 3系へ移行するなら、少なくともPHP 8.2以上での検証に切り替えます。

strategy:
  matrix:
    php-version: ['8.2', '8.3', '8.4']

ただし、PHP 8.4を含めるかどうかは、プロジェクトの利用ライブラリ全体が対応しているかを見て判断してください。Core SDKの過去リリースではPHP 8.4互換性に触れた更新もありますが、実際のプロジェクトでは他の依存パッケージが制約になることがあります。(GitHub)

Dependabotの自動マージは慎重に扱う

今回のようなメジャーバージョン更新は、PRタイトルだけを見ると「依存関係の範囲を広げただけ」に見えることがあります。しかし実際には、PHPサポート範囲の変更を伴うBreaking Changeです。

GitHub管理者は、少なくとも次の運用をおすすめします。

  • ComposerのメジャーアップデートPRは自動マージしない
  • composer.lockの差分をレビュー対象にする
  • PHP 8.2以上のCIが通るまでマージしない
  • 本番デプロイ前にステージング環境でGraph API呼び出しを確認する
  • Dependabot PRのタイトルではなく、Files changedとリリースノートを確認する

今回のPRでも、最終的に変更されたファイルはcomposer.jsonであり、microsoft/microsoft-graph-coreの要件が^2.2.1から^3.0.0へ変わっています。(GitHub)

本番展開で失敗しやすいポイント

PHPの実行環境だけ古い

開発PCやCIはPHP 8.2以上でも、本番サーバーやコンテナがPHP 8.1のままというケースがあります。この場合、ローカルでは成功してもデプロイ後にcomposer installが失敗する可能性があります。

確認すべき場所は次の通りです。

環境確認ポイント
DockerベースイメージがPHP 8.2以上か
GitHub Actionsmatrixとsetup対象がPHP 8.2以上か
VPS・クラウドVMCLIとWebサーバー側のPHPバージョンが一致しているか
PaaSランタイム指定やビルドパックがPHP 8.2以上か
ローカル開発php -vとIDEのPHP設定が一致しているか

特にPHPは、CLIのphp -vとWebサーバー側のPHP-FPMが異なるバージョンを使っていることがあります。ComposerはCLI上で動くため、CIやデプロイ処理のPHPだけでなく、実行時のPHPも確認してください。

composer.lockを更新し忘れる

ライブラリ更新後にcomposer.jsonだけをコミットし、composer.lockを更新しないと、環境ごとに解決される依存関係がずれる原因になります。アプリケーションとして管理しているリポジトリでは、原則としてcomposer.jsonとcomposer.lockをセットでコミットします。

git status
git diff composer.json
git diff composer.lock

ライブラリ開発リポジトリではlockファイルを含めない運用もありますが、アプリケーションでは再現性を優先するのが一般的です。

config.platform.phpが古いPHPを指している

composer.jsonに次のような設定が残っていると、実際のPHPが8.2以上でもComposerの依存解決上はPHP 8.1として扱われます。

{
  "config": {
    "platform": {
      "php": "8.1.0"
    }
  }
}

この設定は、チーム全体で特定のPHPバージョンを前提に依存関係を固定するためには有効です。しかしCore SDK 3系へ移行する場合は、8.2以上に更新するか、設定の必要性を見直してください。

Kiota関連パッケージの競合

Core SDK 3.0.0では、Kiota関連パッケージが2.0.2系へ上がります。すでにプロジェクト内でKiota関連パッケージを直接指定している場合、古い制約が残っていると依存関係解決に失敗することがあります。(Packagist)

この場合は、Core SDKだけを個別に上げるのではなく、関連パッケージ全体をdry-runで確認します。

composer why microsoft/kiota-http-guzzle
composer why-not microsoft/kiota-http-guzzle 2.0.2
composer update microsoft/microsoft-graph-core microsoft/kiota-http-guzzle --with-all-dependencies --dry-run

すぐに移行できない場合の判断基準

PHP 8.1以下の環境が残っている場合、Core 3系への移行を急ぐよりも、まずPHP 8.2以上への移行計画を作るべきです。Core SDK 3.0.0は、古いPHPサポートを落とすことで安全でない依存関係に対応する趣旨の更新として説明されています。(GitHub)

一時的にCore 2系へ留める判断はあり得ますが、その場合は「いつまでにPHP 8.2へ上げるか」を決めておく必要があります。何となく依存関係更新を止め続けると、後でMicrosoft Graph SDK、Kiota、PHP本体の更新がまとめて発生し、移行コストが大きくなります。

状況推奨判断
全環境がPHP 8.2以上Core 3系への移行を検証する
CIだけPHP 8.1が残っているCI matrixを先に更新する
本番だけPHP 8.1以下本番ランタイム更新を先に計画する
Kiota関連の競合がある直接依存の制約を見直す
Microsoft Graph beta APIを重要機能で使っているステージングでAPI呼び出しを重点検証する
Dependabot PRが自動マージ対象メジャー更新はレビュー必須にする

よくある疑問

GitHub自体の仕様変更なのか

いいえ。今回の更新は、GitHub上で公開されているMicrosoft Graph Beta SDK for PHPリポジトリの依存関係変更です。GitHubのAPIやGitHub Actionsそのものの仕様変更ではありません。

ただし、GitHub ActionsでComposerを実行しているプロジェクトや、DependabotでComposer更新を管理しているリポジトリには影響します。

PR名の^2.2.1 || ^3.0.0を信じてよいのか

最終判断では、PR名ではなくマージ後の差分を見るべきです。今回のPRでは、レビュー後に^3.0.0のみへ変更され、マージ後のcomposer.jsonでもmicrosoft/microsoft-graph-coreは^3.0.0になっています。(GitHub)

PHP 8.1のまま使い続けられるのか

Core SDK 3.0.0へ移行する場合は、PHP 8.2以上が必要です。PHP 8.1以下の環境では、依存関係解決やインストールの段階で問題が出る可能性があります。(Packagist)

composer.lockがあるなら対応不要なのか

短期的には、既存のcomposer.lockがCore 2系を固定していれば動作が変わらない場合があります。ただし、Dependabot PRや手動のcomposer updateでlockファイルが更新されると影響が出ます。対応不要ではなく、更新タイミングを管理する必要があります。

何から始めるべきか

最初にやるべきことは、PHPバージョンと依存関係解決の確認です。次の3つを実行すれば、移行の難易度が見えます。

php -v
composer show microsoft/microsoft-graph-beta microsoft/microsoft-graph-core
composer update microsoft/microsoft-graph-beta microsoft/microsoft-graph-core --with-all-dependencies --dry-run

この時点でPHP 8.2未満が出るなら、SDK更新よりもPHPランタイムの更新が先です。dry-runでKiota関連の競合が出るなら、関連パッケージの制約を見直してください。

まとめ：PRタイトルではなく、実際の差分と実行環境を見る

今回のGitHub上の更新は、microsoft/microsoft-graph-coreを3.0.0系へ移行するための依存関係変更です。PRタイトルには^2.2.1 || ^3.0.0とありますが、最終的なマージ内容は^3.0.0のみです。この違いを見落とすと、PHP 8.1以下の環境や古いKiota依存関係を持つプロジェクトで失敗しやすくなります。

次に取るべき行動は明確です。まずPHP 8.2以上で動く環境かを確認し、composer update --dry-runで依存関係の変化を確認します。そのうえで、GitHub ActionsのPHP matrix、composer.lock、config.platform.php、本番ランタイムをそろえてから移行してください。Dependabot PRを扱う場合は、PR名だけで判断せず、Files changedとリリースノートを必ず確認することが安全な展開につながります。

PHP
GitHub PHP Composer Microsoft Graph Dependabot

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次