R CMD checkをMacで行うには？2026年の研究用パッケージ受入検査

検査を始める前に環境を記録します

はじめに、検査対象のプロジェクトを特定できる状態にします。Rのバージョン、macOSのバージョン、実行アーキテクチャ、依存パッケージ、プロジェクトのコミットを記録し、後から同じ条件で再確認できるようにしてください。条件を記録せずにログだけ残すと、環境差による失敗とソースの変更による失敗を区別しにくくなります。

Rとアーキテクチャは、Rのコンソールで次のように確認できます。

R.version.string
R.version$platform
Sys.info()

依存パッケージは、プロジェクトで使う仕組みに応じて記録します。ロックファイルがある場合は、それも検査記録と一緒に保管してください。macOS arm64で確認する目的なら、記録した実行アーキテクチャが想定した環境と一致していることも確認します。

次に、Apple Command Line Toolsが利用できるか、また意図した開発者ディレクトリが選ばれているかを確認します。Appleの案内では、コマンドラインツールの導入と選択設定は別に扱われているため、ツールの有無だけで判断せず、インストール手順と選択中の開発者ディレクトリの設定を照合してください。完全なXcodeが必要か、Command Line Toolsで足りるかは、パッケージの依存機能と現行の公式要件によって異なります。

xcode-select -p

先にソースパッケージを作り、配布物を検査します

開発中の作業ディレクトリを直接確認するだけでは、配布時に必要なファイルがパッケージに含まれていない問題を見落とすことがあります。Rの公式手順に沿ってソースパッケージを構築し、その成果物に対して検査を実行してください。R公式手引きの構築・検査の説明と、Rのパッケージ構築・検査関数の説明で、利用中のRに対応するオプションを確認できます。

プロジェクトのルートディレクトリから、次の順序で実行します。package.tar.gzは構築されたファイル名に置き換えてください。

R CMD build .
R CMD check package.tar.gz

CRAN向けの検査を意識する場合は、対象となるRの手引きに記載されたオプションを確認してから実行します。たとえば--as-cranを使う方法がありますが、結果がCRANへの受理を保証するわけではありません。実際の検査範囲とオプションは、現行のR公式手引きに照らし合わせてください。

ログは途中を省略せずに保存し、検査ディレクトリとソースパッケージも残します。結果に表示されるERROR、WARNING、NOTEは別々に扱い、表示だけを機械的に一括修正せず、どの検査段階で何が起きたかを記録してください。

コンパイルの失敗はツールと依存関係から絞ります

C、C++、Fortranのコードや外部システムライブラリを使うパッケージでは、コンパイラ、ヘッダーファイル、リンク対象のライブラリ、実行アーキテクチャの整合を確認します。エラーが出た場合は、最初に失敗したコマンドとその直前のログを起点にすると、後続のエラーに引きずられず原因を絞れます。

Rの検査環境や環境変数も結果に影響するため、R公式手引きの検査プロセスと環境変数に関する説明を確認してください。また、macOSでのRの導入やビルド条件を調べる際は、R公式のインストール・管理資料も参照できます。

切り分けでは、失敗を次のように分けて記録します。

• パッケージのソースにある型、構文、宣言の問題。
• 必要なヘッダーや外部ライブラリが見つからない依存関係の問題。
• 選択中の開発者ディレクトリやコンパイラなど、ツールチェーンの問題。
• ライブラリとパッケージの実行アーキテクチャが一致しない問題。

原因が不明な場合は、失敗したコードと必要最小限の依存関係だけを残した再現用プロジェクトを作ります。既存の環境を一括更新する前に、この小さな再現例で失敗が続くかを確かめてください。更新によって原因が隠れると、別の担当者が同じ問題を再現できなくなるおそれがあります。

テストと文書をクリーンな状態で確かめます

コンパイルが終わっても、パッケージの受入検査は完了していません。tests、examples、vignette、ヘルプ文書を確認し、研究室の担当者が同じソースから同じ作業を再現できるかを見ます。とくに、個人のホームディレクトリにしかないファイル、事前に開いた作業環境、ローカル限定のデータに依存するテストは、別環境で失敗する原因になります。

ヘルプ文書やvignetteで失敗した場合は、ログに記録された対象を特定し、ソースパッケージに必要ファイルが含まれているか、文書の生成に必要な依存パッケージが利用できるかを調べます。続いて、クリーンなセッションで同じ処理を実行し、ユーザーの作業ディレクトリや私有ファイルを参照していないか確認します。

乱数や浮動小数点の結果に差があるときは、検査結果だけを根拠に許容範囲を広げないでください。プロジェクトで事前に定めた乱数の扱い、期待する挙動、許容差に照らして、再現性と科学的な意味の両方を確認します。既にインストールされたパッケージを検証する必要がある場合は、対象とするテストの種類をRのtoolsドキュメントで確認できます。

受入結果を提出先と対象OSごとに整理します

引き継ぎ記録には、実行環境、コミット、ソースパッケージ、ログ、検出事項と対応状況をまとめます。検査していないOSやアーキテクチャも明記してください。Macでの検査結果と、Windows・Linux向けの検査結果を一つの「対応済み」にまとめると、後の利用者が未検証の範囲を判断できません。

CRANへの投稿を予定している場合は、R CMD checkの結果とは別に、投稿時点のCRAN Repository Policyを確認します。対象プラットフォームや提出条件は変更される可能性があるため、過去の検査記録だけで現在の政策を判断しないでください。

手元にMacがない場合、ローカル環境の変更だけでmacOS arm64の検査結果を得ることはできません。研究室にMacを常設する方法は継続利用には適していますが、受入検査のためだけに機材を用意するのは過剰となる場合もあります。リモート環境を選ぶなら、対象のプロジェクトを分離して検査し、ログと成果物を研究室側に保存できる運用にしてください。NodeMiniのMac利用案内を確認し、検査の必要期間と運用要件に合うか判断できます。

よくある疑問

Macでの検査はクロスプラットフォーム対応の証明になりますか

なりません。Mac上で実行した検査が確認するのは、その環境での構築やテストなどです。WindowsやLinuxでのコンパイラ、外部ライブラリ、ファイル処理の差は、各OSで別に確認してください。CRAN投稿を予定している場合も、Macでの検査結果だけで投稿要件を満たしたとは判断せず、現行の政策を照合します。

コンパイルエラーは何から確認すればよいですか

最初に失敗したコンパイルコマンドと、その直前のログを見ます。次に、エラーに出てくるソースファイル、ヘッダー、外部ライブラリを確認し、Command Line Toolsの選択状態とアーキテクチャの不一致を切り分けます。必要なツールはパッケージごとに異なるため、原因を確かめる前に一律のツール追加を行わないでください。

文書やvignetteの失敗はどう調べればよいですか

検査ログから失敗した文書を特定し、ソースパッケージにファイルが含まれていることと、生成に必要な依存パッケージがそろっていることを確かめます。その後、個人の作業ディレクトリや私有ファイルを使わずにクリーンなセッションで再実行します。環境を変えながら試す場合も、変更内容と結果を記録して原因を追えるようにします。

手元にMacがない場合はどう進めればよいですか

WindowsやLinuxの検査で代用せず、研究室のMacを借りるか、必要な期間だけリモートのmacOS環境を用意します。実行前にRや依存パッケージ、コミットを記録し、検査ログを研究室側へ保存すれば、担当者間で結果を確認しやすくなります。NodeMiniを含む選択肢は、利用期間や接続・保存の条件を確認してから比較してください。

検査期間に応じてMac環境を選びます

毎回の開発でMacを使い、物理的な接続や長期の安定運用も必要なら、研究室で実機を用意する方法が合います。一方、主な開発環境がLinuxやWindowsで、macOS arm64の確認がリリース前などに限られるなら、別OSの検査を残したまま必要な期間だけリモート環境を補う選択肢があります。

Macを常設する方法には、導入費用、管理担当者の負担、利用頻度が下がった後も維持するコストがあります。リモート利用では、接続経路とファイルの受け渡し、検査環境の記録が別途必要です。NodeMiniのリモートMacを検討する場合は、まず検査対象の作業期間と必要なアクセス方法を整理し、利用方法の案内を参照してください。研究パッケージの検査に必要な期間だけ環境を確保し、Macでの検査とWindows・Linuxでの検査を分けて記録する運用が適切です。