R言語 CRAN Task View：パッケージの開発と保守

CRAN Task View: Package Development and Maintenanceについて、機械翻訳を交えて日本語化し掲載しております。

CRAN Task Viewの一覧はR言語 CRAN Task Viewsを参照ください。

1 概要
2 はじめに
3 最初の一歩
- 3.1 既存のパッケージ状況の確認
- 3.2 パッケージの初期化
4 パッケージ開発
5 メンテナンス

概要

Maintainer:	Lluís Revilla, Heather Turner
Contact:	lluis.revilla at gmail.com
Version:	2026-10-14
URL	https://CRAN.R-project.org/view=PackageDevelopment
Source:	https://github.com/cran-task-views/PackageDevelopment/
Contributions:	このタスクビューに対する提案や改良は、GitHubのissueやpull request、またはメンテナのアドレスに電子メールで送ってください。詳しくはContributing guideをご覧ください。
Installation:	このタスクビューからのパッケージは、ctvパッケージを使用して自動的にインストールすることができます。例えば、ctv::install.views(“PackageDevelopment”, coreOnly = TRUE)は全てのコアパッケージをインストールし、ctv::update.views(“PackageDevelopment”)はまだインストールしていない全てのパッケージと最新のものをインストールします。詳細については、CRAN Task View Initiativeを参照してください。

本タスクビューの作成にあたり、初期段階で尽力されたRoger Bivand氏に深く感謝いたします。

はじめに

パッケージは、追加のコードやデータを提供することでRの機能を拡張するものです。パッケージの開発は通常、反復的なプロセスであり、その保守にはR本体やパッケージの依存関係の変化への対応が求められます。

パッケージのビルドやインストールに不可欠なツールは、「R CMD」コマンドラインツールとして提供されています。Base R（Rの標準機能）では、パッケージ開発・保守専用のtoolsパッケージに加え、utilsパッケージ内にも関連する多数の関数が用意されています。また、コントリビュート・パッケージ（ユーザー提供パッケージ）によって、代替または補完的な支援機能が提供されることもあります。

Rパッケージ開発に関する決定版の資料は、Writing R Extensions (WRE)マニュアルです。CRAN Repository Policyは、このマニュアルを前提としつつ、さらなる基準を定めたものです（他のリポジトリのポリシーについては、以下の関連リンクを参照してください）。

パッケージ開発を支援する目的で作成されたコントリビュート・パッケージであっても、それらがWREやリポジトリ・ポリシーと完全に整合しているとは限りません。特に、支援用パッケージを「前方依存関係（forward dependency）」として追加する場合には注意が必要です。開発時の利便性を優先した結果、パッケージの作者自身や、そのパッケージに依存する他のパッケージ（逆依存関係にあるパッケージ）の作者にとって、保守作業が困難になる可能性があるためです。

パッケージ開発者を支援するため、本タスクビューではWREの関連セクションを参照しつつコントリビュート・パッケージを整理・紹介しています。その際、代替・補完的なツールよりも先に、baseパッケージや推奨（recommended）パッケージに含まれる関連機能を取り上げるようにしています。

最初の一歩

既存のパッケージ状況の確認

新しいパッケージの開発を始める前に、すでに利用可能なパッケージがないか調べておくことは有益です。これは開発者の視点（「車輪の再発明」を避けるため）からも、ユーザーの視点（同じ、あるいは類似した処理を実装するパッケージが多数あると混乱を招くため）からも言えることです。もし同じ機能を提供するパッケージがすでに存在する場合は、新規に作成するのではなく、その既存パッケージへの貢献を検討してみてもよいでしょう。

貢献の機会を探しているなら、メンテナンス担当者が不在となった既存パッケージ（オーファン・パッケージ）の引き受け手が必要とされていたり、まだ存在しないパッケージに対する要望が出されていたりすることに気づくかもしれません。

CRANチームは時折、R-package-devel mailing listを利用して、メンテナンス担当者が不在となったパッケージを引き受けてくれる人を募集することがあります。

CRAN Searchページは、Rに関連する検索ツールへのリンクがまとめられており、パッケージのソースコード、書籍、タスクビュー、サポート用メーリングリスト、ブログ、さらにはインターネット全体を対象とした検索が容易に行えるようになっています。

「utils::RSiteSearch()」関数を使うと、http://search.r-project.org/の検索エンジンを利用して、ヘルプページ（Windows専用パッケージや一部のBioconductorパッケージを除くすべてのCRANパッケージ）、パッケージのメタデータ、ビネット（vignettes）、タスクビューなどを対象に、キーワードやフレーズの検索を簡単に行うことができます。

rOpenSciは、（共同）メンテナを募集しているrOpenSciパッケージを検索できるHelp Wantedページを運営しています。rOpenSciフォーラムのWishlistチャンネルは、新しいパッケージや機能に関するアイデアを議論する場として利用されています。
Bioconductor Code Searchは、Bioconductorパッケージのソースファイルを検索するための公式ツールです。
CRANの全パッケージ（アーカイブされたものを含む）を対象とした非公式の読み取り専用ミラーであるcran GitHub mirrorは、GitHub Code Search syntaxを用いて、パッケージのソースファイル全体を横断的に検索することができます。

パッケージの初期化

「utils::package.skeleton()」は、新しいソースパッケージのセットアップ作業の一部を自動化します。この関数は、ディレクトリの作成、指定された関数・データ・Rコードファイルの適切な場所への保存、ヘルプファイルの雛形（スケルトン）の生成、そしてパッケージ化の今後の手順を説明するファイル（Read-and-delete-meファイル）の作成を行います。

パッケージを初期化する際には、そのライセンスをどうするか検討することをお勧めします。CRANリポジトリ・ポリシーには、database of licenses acceptable for CRANへのリンクが記載されています。

WRE（Writing R Extensions）の参照箇所：Package Structure（パッケージの構造）

availableは、パッケージ名が有効かつ利用可能か（つまり、CRAN、Bioconductor、GitHubですでに使用されていないか）をチェックします。また、その名前に意図しない意味が含まれていないかも確認します。
- collidrは、パッケージ名や関数名が、CRAN上の既存のパッケージ名や関数名と衝突していないかをチェックします。
usethisは、最小限のパッケージ構造をセットアップするcreate_package()や、コンポーネントを追加するための多数のユーティリティ（use_*_license()関数など。ここで*はライセンス名に置き換わります）を提供します。
pkgKittenは、ほぼ空のパッケージの雛形（スケルトン）と、ヘルプページを作成するためのユーティリティを提供します。
RcppのRcpp.package.skeleton()は、package.skeleton()を拡張し、Rパッケージ内でCやC++のコードを連携させるためにRcppを使用する際、必要となるコンポーネントを追加します。usethisも同様の機能をuse_c()およびuse_rcpp()関数で提供しています。
biocthisは、Bioconductorパッケージのセットアップを自動化します。
r.pkg.templateは、Rパッケージ用のGitHubリポジトリを初期化します。これには標準的なファイルやディレクトリに加え、CI/CD設定や、一般的な問題を特定・解決するためのpre-commit gitフックが含まれます。
fusenやlitr-projectは、R Markdownファイルからパッケージを作成します。
- nowebは、noweb構文（Sweaveで使用されるもの）を用いたリテレート・プログラミングの手法でパッケージを作成します。
DataPackageRは、データセットからパッケージを作成します。
- rcompendiumは、「リサーチ・コンペンディウム（研究の完全な記録）」のための構造を作成します。これは、生データ、解析スクリプト、出力結果、makeスクリプトなどを含め、再現性のある研究を支援するためのRパッケージ構造です。
leprechaunは、依存関係を増やすことなくShinyアプリをパッケージとして作成できるよう、パッケージの雛形にテンプレートコードを追加します。
- golemは、golemフレームワークを使用してShinyアプリを開発・デプロイするためのパッケージテンプレートを作成します。
pkgverseは、関連する複数のパッケージをまとめ、一括してインストールや読み込みができる「メタパッケージ」を作成します。

パッケージ開発

開発ワークフロー

一部のコントリビュート・パッケージは、パッケージ開発の様々なタスクにまたがる機能を提供するという点で、ツールに相当する役割を果たします。

Writing R Extensions (WRE)は、パッケージ開発の基本的な作業について解説しています。

BioconductorやrOpenSciが提供するものを含め、その他のガイドについては「関連リンク」のセクションを参照してください。

devtoolsは、「load_all()」関数を通じてRコードやコンパイル済みコードの対話的な開発を支援します。この関数は、パッケージのインストールと再読み込みのプロセスをシミュレートします。さらに、ドキュメントの生成、テスト、パッケージのチェック、CRANへの提出をサポートする関数も用意されています。
usethisは、「use_r()」、「use_data()」、「use_vignette()」、「use_news_md()」といった、新しいコンポーネントを追加するためのヘルパー関数を提供します。また、「use_testthat()」や「use_git()」のように、特定のパッケージやワークフローの導入を支援する関数も含まれています。
packagerは、fakemakeやGNU makeを利用してパッケージ開発タスク（ドキュメント作成、ビルド、チェックなど）を実行します。これにより、makeの依存関係にあるファイルが更新された場合にのみ、makeターゲットが再生成されるようになります。必要な構造を持つパッケージを初期化する`create()`関数や、別の方法で初期化されたパッケージを本パッケージの管理下で扱えるようにする`infect()`関数が提供されています。また、makerリポジトリでは、開発タスクを実行するための外部Makefileが提供されています。
rtclは、開発タスク用のコマンドラインユーティリティを提供します。これらの機能は、通常のR関数としても利用可能です。
roxyPackageは、「roxy.package()」関数を提供し、ヘルプファイル、ビネット（vignette）、パッケージレベルのドキュメント（NEWSやREADMEなど）をPDFおよびHTML形式で生成します。また、パッケージのチェックやビルド、ローカルパッケージリポジトリの管理も行えます。これらのタスクは、個別または組み合わせて実行することが可能です。
gpttoolsは、パッケージ開発において大規模言語モデル（AIサービスプロバイダーのモデルやローカルモデル）の利用を支援します。具体的には、コードの関数化、ドキュメントやテストの追加、改善点の特定といった作業に役立ちます。

パッケージのドキュメント

エクスポートされるRオブジェクトについてはヘルプページを作成する必要があり、パッケージ全体に関するヘルプページを作成することも可能です。また、パッケージの機能の概要を説明したり、より複雑な使用法を解説したりするために、「ビネット（vignettes）」を含めることもできます。一部のコントリビュート・パッケージでは、パッケージのウェブサイトやチュートリアルなど、他の種類のドキュメントを作成するためのツールが提供されています。

ヘルプページ

ヘルプページのソースファイルには、「Rドキュメント（Rd）」形式が使用されます。関数やデータセットのRdテンプレートを作成するには、それぞれ「utils::prompt()」や「utils::promptData()」を使用できます。Rdファイルの検証（構文エラーの検出など）には、tools::checkRd()を使用できます。

WRE（Writing R Extensions）の参照先：Writing R documentation files

roxygen2は、Rソースファイル内の特定のマークアップが施されたコメントからRdファイルを生成するroxygenise()関数を提供します。Markdownと併用することで、ドキュメントのソースに必要なマークアップの量を大幅に削減できます。いくつかのdevelopment workflowパッケージが、roxygen2によるドキュメント作成をサポートしています。
sinewは、roxygenのスケルトン（雛形）を生成し、必要に応じてNAMESPACEファイルやDESCRIPTIONファイルを更新します。roxygenドキュメントの新規作成だけでなく、更新にも利用可能です。
Rd2roxygenは、Rdファイルをroxygen2形式のコメントに変換する機能を提供します。
roxygen2mdは、roxygen2コメント内のRd構文を、それに対応するMarkdown記法に置き換えます。
roclangは、Rdファイル（同一パッケージ内または別のパッケージ内のもの）からドキュメントの構成要素を抽出し、roxygenコメント内に挿入して再利用しやすくします。
pasteAsCommentは、クリップボードの内容をroxygenブロックとして貼り付けるRStudioアドインを提供します（例の挿入などに便利です）。また、roxygen2Commentは、通常のコードをroxygenコメント付きのコードに変換したり、その逆を行ったりするRStudioアドインを提供します。
roxyglobalsは、「utils::globalVariables()」を使用してグローバル変数を定義するRコードを生成するためのroxygenタグを追加します。これは、パッケージ内の関数が非標準評価（non-standard evaluation）を用いる関数を呼び出す際に、パッケージチェックで誤検出（false positive）が発生するのを防ぐのに役立ちます。
devtagは、エクスポートされない関数（非公開関数）向けの開発者用ドキュメントを作成するための`@dev`タグを提供します。srrは、rOpenSciのソフトウェアレビュー基準への準拠を文書化するためのタグを追加します。
Rdpackは、ドキュメント開発のための関数やRdマクロを提供します。例えば、新しい引数用のドキュメントテンプレートの追加、BibTeXファイルからの参考文献のインポート、Rコードの評価と結果（出力や図）の挿入などが可能です。
Rd2mdは、RdファイルをMarkdownに変換し、統合されたMarkdownリファレンスマニュアルを作成します。rd2markdownは、ソースRdファイルやインストール済みパッケージのヘルプページからMarkdownを生成します。
rd2listは、RdファイルをRのリスト形式に変換します。

ビネット

ビネットのデフォルト形式は、WRE（Writing R Extensions）で規定された特殊なメタデータを含むSweave形式です。「R CMD build」は、ビネットのビルドに際し、デフォルトのビネットエンジンとして「utils::Sweave()」を使用します。別のビネットエンジンを使用する場合は、メタデータ内で「<package>::<engine>」という形式で指定可能です。

WREの参照箇所：Writing package vignettes（パッケージビネットの作成）、特に「Non-Sweave vignettes（Sweave以外のビネット）」の項。

knitrは、HTMLおよびPDF形式のビネット（vignette）をコンパイルするためのエンジンを提供しています。「knitr::rmarkdown」エンジンは、「rmarkdown::html_vignette()」フォーマットと組み合わせて使用でき、これは「knitr::html_document()」の軽量な代替手段となります。数式をオフラインで表示させるには、「rmarkdown::html_vignette()」の「math_method」引数を「”katex”」または「”r-katex”」に設定する必要があります。
litedownは、独自のHTMLおよびPDF出力フォーマットで使用できるビネットエンジンを提供しています。依存関係を最小限に抑え、軽量なHTMLファイルを生成するように設計されています。目次、相互参照、引用など、ほとんどのビネットに必要な機能を備えており、より高度な機能が必要でない限り推奨される選択肢です。
quartoは、HTMLフォーマットの設定を固定して軽量なファイルを生成するビネットエンジンを提供しています。（Sweaveと同等の）より高度な機能が必要な場合や、すでにQuartoを使用しているコンテンツを再利用する場合には、この選択肢が適しているかもしれません。ただし、quartoはrmarkdownに依存し、さらにシステムレベルの依存関係としてQuarto自体を追加するため、依存関係の多い選択肢となります。
prettydocは、「rmarkdown::html_vignette()」の代替として「html_pretty()」を提供しており、より洗練されたテーマを使用しつつ軽量なファイルを生成します。
R.rspは、静的なPDFまたはHTML形式のビネットを組み込んだり、プレーンなLaTeXファイルからビネットをコンパイルしたりする機能を提供します。また、「R.rsp::rsp」エンジンを使用してPDFやHTMLのビネットをレンダリングすることで、RSPのプリプロセッシング・ディレクティブ（外部ファイルの読み込みやドキュメントのメタデータ利用など）や、コードスニペットを用いてテキストをループ処理できるコード式などを利用可能にします。

その他の形態の文書

pkgdownは、標準的なドキュメントファイルを基にパッケージのウェブサイトを生成します。また、外部ホスト型のlearnrチュートリアルなどの追加コンテンツを組み込むことも可能です。GitHub Pagesへのサイトデプロイを支援する機能も用意されています。
altdocはpkgdownの軽量な代替ツールとして設計されており、Quarto、Docute、Docsify、MkDocsなど、多数のドキュメント生成ツールに対応しています。
r2readthedocsは、パッケージのドキュメントをRead the Docs形式のウェブサイトに変換します。
rdoxygenは、パッケージ内のC++コードに対してDoxygen形式のドキュメントを生成し、オプションでそれを「vignette（解説記事）」として公開することも可能です。

パッケージのメタデータおよび情報ファイル

「tools::CRAN_package_db()」は、CRANパッケージリポジトリ内の現在のパッケージに関するDESCRIPTIONメタデータの大部分を文字型列として含むデータフレームを返します。

「utils::news(package = “pkg”)」を使用すると、特定のパッケージのNEWS（変更履歴）を抽出し、ブラウザに表示することができます。

descは、DESCRIPTIONファイルを読み込み、書き込み、作成、操作するためのツールを提供します。
semverは、semantic version stringsを扱うためのツールを提供します。
newsmdは、NEWS.mdファイルを作成または更新する機能を提供します。
- fledgeやautonewsmdは、各パッケージ固有の慣習に従い、GitのコミットメッセージからNEWS.mdを生成します。
codemetarおよびより軽量なcodemetaは、DESCRIPTIONやCITATIONといったパッケージのソースからメタデータを抽出し、CodeMeta JSON-LD形式に変換します。これは、検索エンジンやソフトウェアリポジトリなどで利用される、言語横断的なメタデータ標準です。
cffrおよびcitationは、パッケージのメタデータからCITATION.cffファイルを生成し、それらのファイルを扱うためのユーティリティ（例：「bibentry」オブジェクトとの相互変換など。utils::bibentry()を参照）を提供します。
- cffrは、Gitを通じたメンテナンスを支援する機能も備えています。CITATION.cffは、ソフトウェアリポジトリや引用管理ツールで認識される、言語横断的な引用情報ファイル形式です。
badgerは、shields.ioなどのプロバイダーが提供するカスタマイズ可能なバッジのURLを生成します。これらのバッジは、現在のCRANバージョンなどのメタデータを表示するために、READMEファイルやパッケージのウェブサイトによく掲載されます。
allcontributorsは、コードやリポジトリのIssue（課題）に関わったすべての貢献者をREADME上で明記・紹介する作業を容易にします。

パッケージのロゴ

パッケージの普及を促進するため、六角形のロゴを作成することが一般的になっています。こうしたロゴは、パッケージのドキュメントや情報ファイルで使用したり、ステッカーなどの販促物を作成したりする際に活用できます。

hexStickerは、Rのプロットや画像ファイルをもとに、六角形ステッカーのデザインを作成します。
affinerは、箱や実物のパッケージのように見える3Dアイソメトリック・キューブ（等角投影図法による立方体）の形状をした六角形ロゴを作成するための「grid.isocube()」機能を提供します。
hexwallは、六角形ステッカーのデザインを敷き詰めた画像を生成します。

パッケージのテスト

「tests」ディレクトリに、単体テストや回帰テストを追加することができます。テストは、追加のパッケージに依存することなく、Rスクリプトとして記述可能です。その際、期待される結果が得られなかった場合にエラーを発生させるために、「base::stopifnot()」などを使用します。テストスクリプトはR CMD checkによって実行され、その出力は対応する「.Rout」ファイルに保存されます。もし「tests」ディレクトリに「.Rout.save」ファイルが存在する場合、これら2つの出力ファイルが比較されます。その際、差異があれば報告されますが、それによってエラーが発生することはありません。

WRE（Writing R Extensions）の参照先：Package subdirectories（パッケージのサブディレクトリ）

これらのパッケージは、コードをテストするための自動化機能やヘルパーを提供します。

tinytestは、新たな依存関係を追加することなくパッケージにテストを組み込むことを可能にし、インストールされたパッケージにテストを含めることで、ユーザーがそれらを利用できるようにします。
testthatは、スナップショットテストを含むテスト用のヘルパー機能を提供します。
- patrickは、testthatを用いたテストのパラメータ化を可能にします。
- hySpc.testthatは、テストを関数に紐付けます。
RUnitとsvUnitは、testthatと同様の代替ユニットテストフレームワークを提供します。
testitは、最小限の依存関係でシンプルなユニットテストインターフェースを実現する、assert()とtest_pkg()という2つの便利な関数を提供します。
roxytestとroxutは、testthatやtinytestを用いたテストを行うためのroxygen2用rocletを提供します。
exampletestrとdoctestは、例（example）をtestthatで実行可能なテストに変換します。
- testexは、roxygen2によるドキュメントをtestthatで実行可能なテストに変換します。
realtestは、「期待値（expected）」「許容値（acceptable）」「現在値（current）」「フォールバック（fallback）」「理想値（ideal）」「回帰（regressive）」といった異なる挙動に基づくテストを行います。
unitizerは、対話型の回帰テスト用フレームワークを提供し、テストのレビューやデバッグを容易にします。
unittestは、Test Anything Protocol（TAP）を使用してテストを行い、標準的なテキスト形式でテスト結果を出力します。
cucumberは、testthatと連携し、「Gherkin」言語（「～を行う（when <I do this>）」や「～が起こるはず（then <this should happen>）」といった形式で高レベルなシナリオを記述する言語）で指定されたテストを実行します。
xpectrは、testthatのテストにおける期待値（expectation）を体系的に生成するためのツールを提供します。
quickcheckとautotestは、ランダムに生成された入力を用いてテストを行い、testthatと互換性があります。
muttestとmutatorは、パッケージのテストスイートの有効性を評価するために、ミューテーションテスト（変異テスト）を行います。
CBTFは、パッケージのパブリックインターフェースにある関数に対してファズテストを行います。

インターネットリクエストのテストを確実に行うのは難しい場合があります。その際のヒントとして、書籍『HTTP testing in R』を参考にするとよいでしょう。

vcrは、HTTPリクエストを記録し、後続の実行時にそれを再生します。
webmockrは、HTTPリクエストに対するスタブ（ダミーの応答の生成）や期待値の設定を行います。
httptest2は、リモートサービスへのアクセスを必要とせずに、httr2パッケージによるリクエストを記録・保存する機能を提供します。
webfakesを使用すると、テストファイル内でダミーのアプリケーションを作成・起動し、複雑な動作をテストすることができます。

特定の分野に焦点を当てたその他のパッケージ：

gdiffとvdiffrは、グラフィカルな出力に対するビジュアルテストを支援する機能を提供します。vdiffrはtestthatと統合されており、テストケースを管理するためのShinyアプリも提供しています。
tinysnapshotは、tinytestフレームワーク向けの「スナップショットテスト」機能を提供し、base Rやggplot2によるプロット、およびprint()出力のテストをサポートします。
shinytest2は、Shinyアプリケーションのためのテストフレームワークを提供します。
checkmateとtestdatは、データ構造の単体テストを行うためにtestthatを拡張するパッケージです。

コードカバレッジ

covrは、パッケージテストのコードカバレッジを追跡・報告し、オプションとしてその結果をCodecovやCoverallsなどのサービスにアップロードします。
covtracerは、テスト対象のコードとドキュメントを関連付け、ドキュメント化された動作のカバレッジを評価します。

パッケージ固有のオプション

パッケージ固有のオプションを実装する簡単な方法は、パッケージ固有のプレフィックスを付けたグローバルオプションを設定することですが、より洗練された堅牢なオプション管理機能を提供するパッケージもいくつか存在します。

optionsは、base::options()で管理されるパッケージ固有のオプションや、それに対応する環境変数を定義・文書化するためのヘルパー機能を提供します。これらのオプションは、グローバルにもローカル（例：関数内）にも設定可能です。
GlobalOptionsは、optionsと同様の機能に加え、オプションの検証、他のオプションに依存する形での設定、あるいは非公開（secret）や読み取り専用（read-only）のオプションといった拡張機能を提供します。
potionsは、brew()およびpour()関数を提供し、同名の既存グローバルオプションを上書きすることなく、パッケージ固有のグローバルオプションを保存・取得できるようにします。
settingsを使用すると、検証ルールを任意で設定しつつ、グローバルまたはローカルなオプションを管理するパッケージ固有のオプションマネージャーを構築できます。
futile.optionsを使用すると、グローバルオプションを管理するパッケージ固有のオプションマネージャーを構築できます。
pkgconfigを使用すると、パッケージ固有のグローバルオプション値を設定でき、それらの値を他のパッケージから参照することが可能になります。
withrは、local_options()関数を提供し、関数のスコープ内においてグローバルオプションを一時的に変更できるようにします。

ユーザーインターフェースの作成

単純な対話型インターフェースの場合、「base::readline()」を使用して基本的なプロンプトを作成できます。一方、「utils::askYesNo()」は、デフォルトで「Yes（はい）」または「No（いいえ）」といった特定の回答を求めるプロンプトを表示します。「utils::menu()」と「utils::select.list()」を使用すると、リストから項目を選択するインターフェースを、それぞれグラフィカルな形式やコンソール形式で提供できます。また、「utils::txtProgressBar()」はテキスト形式の進捗バーを提供します。

「tcltk」は（デフォルトでは読み込まれない）ベースパッケージの一つであり、Tcl/Tkを用いたグラフィカルインターフェースを作成するための豊富なツール群を提供します。このパッケージに含まれる関数の多くは、対応するTclおよびTkの関数を薄くラップしたものです。

tcltk2は、tcltkを補完する追加のTclコマンドやTkウィジェットを提供します。
fguiは、1つまたは複数の関数に対するTcl/Tkインターフェースの迅速な作成を支援します。
getPassは、ユーザーが入力する文字を隠蔽（マスキング）しつつ、安全にパスフレーズの入力を求めるためのインターフェースを提供します。可能な限りGUIを使用し、それが不可能な場合は端末（ターミナル）インターフェースに切り替わります。
progressは、RおよびC++向けに、カスタマイズ可能なテキスト形式のプログレスバーを提供します。
shinyは、ブラウザベースのインターフェースを作成するためのフレームワークを提供します。これには、単純な関数ダイアログから複雑な対話型Webアプリケーションまでが含まれ、`runApp()`を使ってローカルで実行したり、静的または動的なWebサイトとしてデプロイしたりすることが可能です。RベースのWebアプリケーションを構築するための他のフレームワークについては、Web Technologies and Servicesタスクビューを参照してください。

ローカライゼーション

パッケージは、異なる言語やロケールを使用するユーザーを対象とする場合があります。Rにおけるローカライゼーションでは、GNU gettextが利用されています（詳細は「Rメッセージの翻訳（Translating R Messages）」に関する記述を参照してください）。この仕組みでは、POファイルに格納された翻訳が使用されます。

「tools::update_pkg_po()」は、パッケージのPOテンプレートファイル（.pot）を作成または更新し、必要に応じて対応するPOファイル（.po）も更新します。また、「tools::checkPoFile()」を使用すると、翻訳ファイルの文字列の書式に不整合がないかを確認できます。

WREの参照箇所：国際化（Internationalization）

potoolsは、.potおよび.poファイルの作成・更新、パッケージ配布用の.poファイルコンパイル、そして不適切なR/Cコードに起因する未翻訳メッセージなどの問題を検出する診断機能といった、各種ヘルパー機能を提供します。
stranslateは、プレーンテキストを用いてRのメッセージをローカライズするための代替メカニズムを提供します。
rhelpi18nは、関連パッケージが提供するYAMLファイルに基づき、ヘルプページのローカライズに対する試験的なサポートを提供します。

ソースパッケージのビルドとインストール

パッケージをビルドおよびインストールするための標準的なツールは、「R CMD build」と「R CMD INSTALL」です。

pkgbuildは、Rパッケージをビルドするための「build()」関数を提供しており、コンパイル済みコードを含むパッケージのビルドを容易にするためのユーティリティも備えています。
pkgloadは、パッケージのインストールとアタッチ（読み込み）のプロセスをシミュレートすることで、迅速な反復的開発を可能にします。
GitHubやGitLabなどのプラットフォームでホストされているものを含め、リモートのソースコードリポジトリからパッケージをインストールするのを支援するパッケージは数多く存在します。
- remotesは依存関係を持たず、URL経由でアクセス可能なあらゆるGitまたはSubversionリポジトリからパッケージをインストールできるほか、特定のケースに対応する補助機能も提供しています。特に、「remotes::install_bioc()」を使用すれば、Bioconductorパッケージの開発版をインストールすることが可能です。
- ipkgは、remotesに依存しており、GitHubに直接アクセスできない環境でも、プロキシサイト経由でGitHub上のパッケージをインストールできるようにします。

パッケージのチェック

標準的なチェック

標準的なパッケージチェックは「R CMD check」によって実行されます。このコマンドは、「R CMD build」でビルドされたパッケージに対して実行する必要があります。このチェックでは、パッケージ内の例（examples）やテストが実行されるほか、整合性や移植性を確保するためにパッケージの内容が様々な観点から検証されます。

WRE（Writing R Extensions）の「Checking and building packages（パッケージのチェックとビルド）」の項を参照してください。「R CMD check」で使用される環境変数の一覧は、『R Internals』マニュアルのTools chapterで確認できます。WREではSuggested packages sectionにおいて、「_R_CHECK_DEPENDS_ONLY_=true」および「_R_CHECK_SUGGESTS_ONLY_=true」を設定した場合と、これらをいずれも「false」に設定した場合の双方で「R CMD check」を実行することを推奨しています。

CRANは、WindowsおよびM1搭載macOSマシン上でのチェックを行うためのサービスとして、それぞれWinbuilderとmacOS builderを提供しています。

rhub (R-hub v2) を使用すると、GitHub Actionsを介してLinux、macOS、Windowsなどの複数のプラットフォーム上で「R CMD check」を実行できます。rhubパッケージは、自身のGitHubリポジトリへのGitHub Actionsの設定を支援します。また、GitHubアカウントを持っていない場合でも、r-hub2 GitHub組織にパッケージを送信し、共有のランナープールを利用することが可能です。
rcmdcheckは、R 上から「R CMD check」を実行し、クエリや操作が可能な「rcmdcheck」オブジェクトを返します。さらにこのパッケージは、ファイルやURL（公式のCRANチェック結果を含む）からチェック結果を解析する機能も提供します。
BiocCheckは、Bioconductorのベストプラクティスに沿った作業をメンテナに案内します。

パッケージチェックを自動的に実行する方法については、CI/CDのセクションを参照してください。

パッケージ作成者は、以下のサブセクションで紹介するツールを使用し、標準的なパッケージチェックに加えて、コードやテキストの品質に関する追加のチェックを行うことができます。

コード品質チェック

推奨パッケージであるcodetoolsは、「checkUsagePackage()」を提供し、パッケージ内のすべてのRコードに対して、可視な関数定義と整合しない呼び出しなどの潜在的な問題をチェックします。
- checkglobalsは、パッケージのインストールやコードの実行を必要とせずに、関数のインポート漏れや変数の定義漏れをチェックするツールであり、`codetools::findGlobals()` に代わる軽量な選択肢となります。
lintrは、特定のスタイルへの準拠、構文エラー、ベストプラクティスへの違反がないかコードをチェックします。「lintr::lint_package()」を使用すると、テストやビネット（vignettes）などの補助ファイルを含め、パッケージ内のRコードをlint（静的解析）できます。lintrは、MegaLinter、super-linter、CodeFactorなどのツールにおいて、他言語用のリンターと組み合わせて使用されています。
- adaptalintは、パッケージからコーディングスタイルを推論し、そのパッケージや別のパッケージのlintを行います。
- stylerは、特定のスタイルガイドに従ってコードを自動的に整形し、lintrが検出するような問題の一部を解消します。
goodpracticeは、パッケージが推奨される慣行（ベストプラクティス）に従っているかをチェックします。これには「R CMD check」やlintrによるチェックに加え、cyclocompを用いたコードの複雑度チェックなどの追加項目も含まれます。チェックは個別に実行することも可能です（例: 「goodpractice::gp(pkg_path, checks = “rcmdcheck_portable_file_names”)」）。
pkgcheckは、goodpracticeを拡張したもので、rOpenSciパッケージ向けの追加チェック（静的コード解析や、CRAN におけるパッケージ名・関数名の利用可能性の確認など）を行います。

コンパイル済みコードのチェック

WRE リファレンス: Checking memory accessでは、Valgrind、Address Sanitizer (ASAN)、Undefined Behaviour Sanitizer (UBSAN)などのツールを使用して、コンパイル済みコード内のメモリ違反や未定義動作などの問題を検出する方法について説明しています。これらのツールを使用するには、適切に構成されたRのビルドが必要です。

rchkは、RのC APIを使用するコード内のメモリ保護エラーを検出するためのツールであり、C言語を利用するRパッケージに対する追加チェックとしてCRANで運用されています。rchkのリポジトリでは、このツールが組み込まれたDockerコンテナが提供されています。
R-hub v2を利用すると、Valgrind、サニタイザー（sanitizers）、あるいはrchkを組み込んでビルドされたR-devel環境（およびその他の多様な設定のR環境）で、「R CMD check」を実行することが可能です。
cppcheckRは、CおよびC++のファイルに対してCppcheckを実行し、エラーの検出や、より適切なコーディング慣行の推奨を行うためのツールです。

テキストの品質チェック

「utils」パッケージには、パッケージ内の各要素（「.Rd」ファイルやビネットなど）のスペルチェックを行うための関数が複数用意されています（「utils::aspell_package_Rd_files」や「utils::aspell_package_vignettes」など）。これらは汎用的な「aspell」関数を利用するものであり、実行にはシステム上のスペルチェックライブラリ（aspell、hunspell、ispellなど）が必要となります。

また、「tools」パッケージには、パッケージのメタデータや情報ファイルに含まれるURLおよびDOIを検証するための「check_package_urls()」や「check_package_dois()」といった関数が用意されています。

spellingは、LaTeXやMarkdownといった一般的な形式の文書に加え、RのドキュメントやDESCRIPTIONファイルに対してスペルチェックを行います。パッケージごとに単語リストを定義し、独自の用語を許可することも可能です。

パッケージチェックで見つかった問題のデバッグ

WinbuilderやR-hubといったチェックサービスを利用すると、Rのバージョンや使用するコンパイラなど、特定の計算環境に起因するパッケージ内のバグが明らかになることがあります。こうした状況下でのデバッグには、以下のツールが役立ちます。

Rockerプロジェクトでは、RがインストールされたDockerコンテナがいくつか提供されています。versioned stackを使用すれば、特定のバージョンのRで作業を行うことが可能です。また、base stackはR-releaseとR-develが併せてインストールされており、オプションでASANやUBSANといったサニタイザを有効にすることもできます。
R-hubで使用されるDockerコンテナについては、R-hub containers用サイトに詳細が記載されており、ローカル環境でのデバッグに活用するための手順も示されています。利用可能なコンテナには、R-release、R-patched、R-develの各ビルドが含まれています。特にR-develについては、メモリ関連の問題をデバッグするための構成を含め、複数のバリエーションが用意されています。
r-debugは、メモリ関連の問題をデバッグするための様々なRビルドをまとめたDockerイメージを提供しています。これには、Valgrindやgdbといったデバッグツールが組み込まれたイメージのほか、ASAN、UBSAN、あるいはgctortureを使用してコンパイルされたRを含むイメージなどがあります。

CRAN Cookbookは、CRANチームとの協力のもと作成されたガイドであり、CRANへのパッケージ提出（または再提出）時のチェックにおいて見つかる、コードやドキュメンテーションに関する一般的な問題を解決するための「レシピ」を提供するものです。

メンテナンス

多くのパッケージは、長期的な利用を想定して開発されています。そのため開発者は、R本体や他のパッケージ、さらにはパッケージの動作に影響を及ぼすシステムツールや環境（コンパイラやオペレーティングシステムなど）の変化に、常に適応していく必要があります。CRANやBioconductorといったリポジトリでは、パッケージがアーカイブ（利用停止）や非推奨の状態にならないよう、最新のポリシーを満たすことが求められます。通常、リポジトリの管理者が実施する定期的なチェックで問題が検出されると、対応が必要な場合にパッケージの作成者へ連絡が届きます。パッケージが今後も有用であり続け、利用可能な状態を保つためには、作成者自身が主体的にメンテナンスに取り組むのが理想的です。

継続的インテグレーション／継続的デリバリー（CI/CD）

継続的インテグレーション（CI）とは、コードリポジトリ内のソースコードが更新されるたびに、自動的にテストを実行する手法のことです。これに、ソフトウェアやソフトウェア製品のリリースやデプロイを自動化する「継続的デリバリー／デプロイメント（CD）」が組み合わされることもあります。GitHub ActionsやGitLab Pipelinesのように、コードホスティングプラットフォーム自体がCI/CDシステムを備えている場合もあれば、CircleCIやWoodpeckerのように、独立したツールとして提供されているものもあります。

CI/CDワークフローは、通常、リポジトリのメインブランチへのコミットをトリガーとして開始されますが、プルリクエストへのコメントといった他のイベントをトリガーに設定することも可能です。また、CI/CDパイプラインはスケジュール実行することもできます。これは、活発に開発が行われていないパッケージであっても、定期的に「R CMD check」を実行して問題の有無を確認する際などに役立ちます。

GitHubリポジトリr-lib/actionsでは、R向けのさまざまなGitHub Actionsが提供されており、その中には「R CMD check」を実行するための「check-r-package」などが含まれています。サンプルワークフローである「check-standard.yaml」では、このアクションを利用して、Linux、Mac、Windows環境で「R-release」バージョンのRを用いて「R CMD check」を実行するほか、Linux環境では「R-devel」や「R-oldrel」バージョンでの実行も行います。その他のサンプルワークフローには、covrを用いたテストカバレッジの算出、pkgdownサイトの構築と公開、roxygen2によるドキュメント作成、lintrによるRコードの静的解析（リンティング）、stylerによるコーディングスタイルの適用などを行うものがあります。
usethisが提供する「use_github_action()」関数を使うと、r-lib/actionsで公開されているサンプルワークフローを、自身のパッケージのGitHubリポジトリに簡単に導入できます。
biocthisの「use_bioc_github_action()」関数は、Bioconductorに適したGitHub Actionsを設定するためのものです。デフォルトのワークフローはr-lib/actionsの「check-standard.yaml」と同等の内容ですが、テストの実行やpkgdownサイトの構築といったオプションのステップを追加して拡張することも可能です。
pkgcheckの「use_github_action_pkgcheck()」関数は、ropensci-review-tools/pkgcheck-actionを設定するもので、これを利用してパッケージに対して「pkgcheck::pkgcheck()」を実行できます。
rworkflowsの「use_workflow()」関数は、Rパッケージ向けのGitHub Actionsを設定するものです。ワークフロー内の各ステップは、必要に応じて有効化または無効化できます。利用可能なステップには、「Bioc::BiocCheck()」によるパッケージのチェック、リポジトリのREADMEにあるバッジの更新、RStudioと対象パッケージがインストールされたDockerコンテナの構築およびDockerHubなどのコンテナレジストリへのプッシュなどが含まれます。
gitlabrの「use_gitlab_ci()」関数は、GitLab CI/CDパイプラインを設定するためのものです。ここには、「R CMD check」の実行、covrによるテストカバレッジの算出、そしてパッケージのpkgdownサイトのデプロイを行うテンプレートが用意されています。
ticは、さまざまなシステム上でCIワークフローを設定する手順をサポートしており、現時点ではGitHub ActionsとCircleCIに対応しています。Rパッケージ向けには、「R CMD check」を実行するワークフローが構築され、オプションとしてテストカバレッジの算出や「pkgdown」サイトの構築を行うことも可能です。ticは、circleを基盤としており、CircleCI APIへの低レベルなアクセス（ビルドの再実行など）を可能にしています。
r-ciは、GitHub Actions、CircleCI、Dockerなどで利用可能な、ポータブルなCI用シェルスクリプトを提供しています。
Codeberg CI/examplesは、Woodpecker CIを使用してRパッケージに対して「R CMD check」を実行するためのワークフロー例が含まれています。

依存関係の管理

多くのパッケージには、そのパッケージのDESCRIPTIONファイル内のImportsフィールドやSuggestsフィールドで宣言される「前方依存関係（forward dependencies）」が存在します。また、パッケージは通常、Rの特定の最小バージョンに依存しています。これは、Rの基本機能（データオブジェクトの圧縮など）を明示的あるいは暗黙的に利用しているためです。

時間が経つにつれ、あるパッケージが他のパッケージからインポートされたり、利用（suggest）されたりするようになり、「逆依存関係（reverse dependencies）」が生じることがあります。CRANで公開されているパッケージの場合、逆依存関係は各パッケージの紹介ページ（https://CRAN.R-project.org/package={PACKAGE} という形式のURL）に記載されています。パッケージ開発者は、自身のパッケージを更新・発展させる際、影響を受ける可能性のあるこれらのパッケージに注意を払う必要があります。なお、CRANでは、Bioconductorのパッケージに対する依存関係や、DESCRIPTIONファイルのAdditional_repositoriesフィールドで指定された他のリポジトリに対する依存関係も許容されています。

前方依存関係や逆依存関係は、「utils::available.packages()」が返すようなパッケージデータベースに基づき、「tools::package_dependencies()」を使用して特定できます。CRANやBioconductor上の依存関係を調べるには、「utils::available.packages()」の「repos」引数に「BiocManager::repositories()」を指定します。

パッケージの変更を試す際に依存関係を更新するには、「utils::update.packages()」が役立ちます。

また、「tools::check_packages_in_dir()」を使用すれば、特定のパッケージ（またはパッケージ群）に対する逆依存関係をチェックすることが可能です。

WRE（Writing R Extensions）の参照箇所：Package Dependencies（パッケージの依存関係）

attachmentは、.Rファイルや.Rmdファイルの変更に応じてDESCRIPTIONファイルの依存関係（forward dependencies）を更新したり、DESCRIPTIONファイルに記載されているものの未インストールとなっているパッケージを素早くインストールしたりするための補助機能を提供します。
rcheologyは、Rのバージョン0.50以降における、すべてのベースパッケージおよび推奨パッケージに含まれる関数に関するデータセットを提供します。これを利用するか、あるいは関連するShinyアプリ（rcheology Shiny app）を使うことで、パッケージが依存するRの最小バージョンを特定するのに役立てることができます。
backportsは、R v3.0.0以降で導入または変更された関数を再実装したものです。これにより、パッケージ開発者は新しい機能を利用しつつ、古いバージョンのRとの互換性を維持することが可能になります。
pacsおよびpkgndepは、「依存関係の重さ（dependency heaviness）」、すなわち新しいパッケージに依存することで追加される依存関係の数を評価するためのツールを提供します。pkgndepは、パッケージの依存関係を最適化するための提案も行います。
pkgdependsは、CRAN、Bioconductor、およびGitリポジトリ上のパッケージについて、DESCRIPTIONファイルの「Remotes」フィールドで指定されたものを含め、依存関係の特定、可視化、インストールを行うために使用できます。
pkggraph、pkgnet、deepdep、crandep、およびcranlyは、パッケージの依存関係を可視化する機能を提供します。
pkgdepRは、パッケージ間における関数同士の依存関係をインタラクティブに可視化するために使用できます。
checkedおよびprrdは、逆依存関係チェック（reverse dependency checks）を並列実行するように設計されています。GitHub上で利用可能なrevdepcheckも同様の目的を持つツールであり、usethis::use_revdep()を使用することで、パッケージをrevdepcheckに対応させるための設定が行えます。
r-devel/recheckは、逆依存関係チェックを実行するためのGitHub Actionを提供します。

変更の管理

パッケージの作成者は、自身のパッケージにおける変更点を、ユーザーや、そのパッケージに依存する他のパッケージ（逆依存パッケージ）のメンテナに向けて周知すべきです。また、自身が依存しているパッケージ（順依存パッケージ）における機能、動作、あるいはAPIの変更にも常に注意を払う必要があります。

「utils::sessionInfo」は、依存先パッケージの更新によって生じた変化を追跡する際に役立ちます。この関数はパッケージがアタッチまたは読み込まれた順序を記録するため、名前空間の競合が発生した際のデバッグに活用できます。

lifecycleは、関数がライフサイクル上のどの段階にあるか（例：実験的から安定版へ、あるいは安定版から非推奨へといった移行）を明示するのに役立ちます。
newsmd,、autonewsmd、およびfledgeは、NEWSファイルの更新プロセスを効率化するために設計されています。さらにfledgeは、Gitリポジトリで開発されているRパッケージのバージョン管理もサポートしています。
diffifyは、CRANパッケージの異なるバージョン間を比較し、NEWS、依存関係、名前空間（namespace）、あるいは関数における変更点を報告する機能を提供します。
remotesは、特定のバージョンのパッケージをインストールするためのinstall_version()関数が含まれています。また、datebackを使用すれば、特定の日付や期間を指定してパッケージをインストールすることが可能です。
pacsは、パッケージ管理のためのさまざまなユーティリティを提供します。これには、特定の日付時点でのパッケージバージョンを取得するpac_timemachine()や、バージョン間でDESCRIPTIONファイルやNAMESPACEファイルを比較する関数などが含まれます。
sessioninfoは、utils::sessionInfo()の代替としてsession_info()を提供します。session_info()は、読み込まれた（またはアタッチされた）パッケージに関する詳細情報をすべて網羅したオブジェクトを返すのではなく、パッケージのインストール元を含む重要な情報に焦点を当てて提示します。ただし、パッケージはアルファベット順に記録されるため、読み込まれた順序は失われます。
changerは、パッケージ名を変更する際の作業を支援します。

利用状況の追跡

cranlogsおよびdlstatsは、RStudioのCRANミラーからダウンロード統計を取得するための関数を提供しています。dlstatsは、Bioconductorのダウンロード統計を取得することも可能です。
packageRankおよびVisualize.CRAN.Downloadsは、CRANのダウンロード統計を可視化し、傾向を調査したり、パッケージ間を比較したりするための関数を提供しています。

概要