Denoに学ぶRustで堅牢かつ拡張性の高いCLIアプリケーションを構築する Part 2: 非同期タスクにおける共有設定と安全な所有権管理

解析日: 2026/7/4

対象コミット: ef62439

RustArcOwnershipConcurrencyTokioCLIDeno

1. 概要

Denoは、JavaScript/TypeScript/WebAssemblyのためのセキュアなランタイムであり、その大規模なコードベースはRustシステムプログラミングの優れたプラクティスが詰まっています。

「Denoに学ぶRustで堅牢かつ拡張性の高いCLIアプリケーションを構築する」シリーズのPart 1では、DenoのCLIにおけるサブコマンドの設計と、SubcommandOutputトレイトを使った共通処理の抽象化について学びました（前回の記事）。サブコマンドによってアプリケーションの機能がどのように構造化され、実行されるかを理解したところで、今回は「非同期タスク間で共通のコンフィギュレーション（設定）をいかに安全かつ効率的に共有するか」という、Rustの非同期アプリケーション開発で避けては通れないテーマに焦点を当てます。Denoがどのように Arc<Flags> を活用しているかを見ていきましょう。

2. アーキテクチャと共有設定の課題

DenoのようなCLIツールでは、ユーザーが指定するコマンドライン引数（Flags構造体でパースされる）が、実行される全てのサブコマンドや内部の非同期タスクに影響を与えます。例えば、--allow-net のようなパーミッション設定、--config で指定される設定ファイルパス、--watch フラグなどは、アプリケーションのライフサイクル全体で参照される必要があります。

Rustの厳格な所有権システムにおいて、複数の非同期タスクが同じデータを同時に所有し、参照することは一筋縄ではいきません。特に、ミュータブルなデータ共有はデータ競合やデッドロックのリスクを伴います。Denoでは、この課題に対して std::sync::Arc (Atomic Reference Counted) を巧みに利用し、アプリケーション全体で設定データを安全に共有しています。

graph TD A["CLI #quot;main()#quot;"] --> B{引数パース}; B --> C["Flags (struct)"]; C --> D["Arc::new(Flags)"]; D --> E["Subcommand #quot;run#quot;"]; D --> F["Subcommand #quot;test#quot;"]; D --> G["Subcommand #quot;fmt#quot;"]; E --> E1["Arc::clone(&Flags)"]; F --> F1["Arc::clone(&Flags)"]; G --> G1["Arc::clone(&Flags)"]; E1 --> E2["非同期タスクA (Worker)"]; F1 --> F2["非同期タスクB (Runner)"]; G1 --> G2["非同期タスクC (Formatter)"]; E2 -- "Flagsを参照" --> D; F2 -- "Flagsを参照" --> D; G2 -- "Flagsを参照" --> D;

図1: Arc<Flags> による共有設定の概念図

この図が示すように、Flags は一度パースされた後 Arc にラップされ、その Arc のクローンが様々なサブコマンドや非同期タスクに渡されます。これにより、複数のタスクが同じ Flags を参照しつつ、それぞれが Flags の所有権を持っているかのように安全に扱えるようになります。

3. この記事で学べること

Arc を用いた不変な共有状態の管理: 複数の非同期タスク間で設定を安全に共有するDenoのパターンを学びます。
Arc::clone() の意味: 参照カウンタのインクリメントが、データ自体のコピーよりもはるかに軽量であることを理解します。
Rustの所有権システムと非同期処理の連携: Arc がどのように所有権のルールを遵守しつつ、並行性を実現するかを考察します。
Flags 構造体の設計: アプリケーション全体で利用される設定の構造化について学びます。

4. 実践的な実装・コード解説

Denoの cli/main.rs や cli/lib.rs を見ると、Flags 構造体がパースされた後、頻繁に Arc::new(flags) や Arc::clone(&flags) でラップされて他の関数や非同期タスクに渡されていることが分かります。

例えば、run_subcommand 関数では、パースされた flags が Arc::new(flags) で Arc 化され、その後 Arc::clone(&flags) を介して各サブコマンドの実装関数に渡されます。これにより、各サブコマンドが独自の Flags の所有権を持っているかのように扱え、並行処理中に Flags が不意にミューテートされることを防ぎます。

// cli/lib.rs
// ...

async fn run_subcommand(
  flags: Flags,
  unconfigured_runtime: Option<UnconfiguredRuntime>,
  roots: LibWorkerFactoryRoots,
) -> Result<i32, AnyError> {
  // `flags` は一度だけパースされ、ここでは所有権がある。
  // 各サブコマンドに渡すために Arc で共有可能にする。
  let flags = Arc::new(flags);

  let handle = match flags.subcommand.clone() {
    DenoSubcommand::Add(add_flags) => spawn_subcommand(async {
      // Arc::clone で参照カウンタを増やし、flags の参照を渡す
      tools::pm::add(flags.clone(), add_flags, tools::pm::AddCommandName::Add)
        .await
    }),
    DenoSubcommand::Bench(bench_flags) => spawn_subcommand(async {
      // ここでも flags.clone() で共有
      if flags.watch.is_some() {
        tools::bench::run_benchmarks_with_watch(flags.clone(), bench_flags)
          .boxed_local()
          .await
      } else {
        tools::bench::run_benchmarks(flags.clone(), bench_flags).await
      }
    }),
    // ... 他のサブコマンドも同様に Arc::clone() を使用
  };
  handle.await?
}

// ...

Arc<Flags> を使用することで、元の Flags データはヒープ上に確保され、その参照カウンタによって寿命が管理されます。複数の Arc クローンが存在しても、データ自体は一つしか存在しないため、メモリ効率も保たれます。また、Flags 構造体自体が不変であれば、データ競合の心配なく複数のスレッドやタスクから安全に読み取ることができます。

5. 実務に持ち帰れるTips

不変な共有設定には Arc<T> を活用する: 複数の非同期タスクやスレッド間で読み取り専用の設定やデータを共有したい場合、Arc<T> が最も安全かつ効率的な選択肢です。T はイミュータブルなデータ構造であることが望ましいです。
Arc::clone() のコストを理解する: Arc::clone() は、内部のデータをコピーするのではなく、参照カウンタをアトミックにインクリメントするだけです。これは非常に軽量な操作であり、データが大きくなりがちな設定オブジェクトでもパフォーマンスへの影響は最小限に抑えられます。
ミュータブルな共有が必要な場合は Arc<Mutex<T>> または Arc<RwLock<T>>: もし共有データがミュータブルである必要があるなら、Arc の内部に std::sync::Mutex や tokio::sync::Mutex (非同期版)、あるいは RwLock を組み合わせて使います。ただし、これによりデッドロックやロック競合のリスクが生じるため、設計には一層の注意が必要です。
Rc<T> との使い分け: Rc<T> は単一スレッド内でのみ参照カウントによる共有所有権を提供します。Arc<T> は複数スレッド間での共有を可能にするため、アトミック操作のオーバーヘッドがあります。Denoのように spawn_subcommand で非同期タスクが別のスレッドプールで実行される可能性のある場合には Arc が必須ですが、main 関数内のようなシングルスレッドのコンテキストであれば Rc で十分な場合もあります。
設定構造体の設計: Flags のようにアプリケーション全体で利用される設定は、可能な限りイミュータブルに設計し、複雑になりすぎないようモジュール化を検討しましょう。これにより、Arc<Flags> で共有した際の安全性が高まります。

6. トレードオフと注意点

参照カウンタのオーバーヘッド: Arc は参照カウンタを管理するためのアトミック操作を伴います。これは Rc よりもわずかにコストが高く、純粋な参照渡し（&T）に比べるとオーバーヘッドがあります。しかし、Denoのような複雑な非同期アプリケーションでは、その安全性と利便性がこのコストを上回ると判断されています。
循環参照によるメモリリーク: Arc は循環参照が発生すると、参照カウンタが0にならず、メモリリークを引き起こす可能性があります。Denoの Flags のようなシンプルな設定構造体では発生しにくいですが、より複雑なオブジェクトグラフを Arc で共有する際には std::rc::Weak や std::sync::Weak の使用を検討する必要があります。
不変性: Arc<T> は内部の T が不変であることを強制しませんが、推奨されます。もし Arc<T> を通じて内部の T を変更したい場合は、前述のように Mutex や RwLock を組み合わせる必要があり、これには複雑さとデッドロックのリスクが伴います。

7. まとめ

DenoのCLIにおける Arc<Flags> の活用は、Rustの非同期システムプログラミングにおいて、複数の並行タスク間で設定データを安全かつ効率的に共有するための優れたパターンを示しています。

このパターンを理解し実践することで、皆さんのRustプロジェクトでも、グローバルな設定や共有リソースを、Rustの所有権システムと並行性への配慮を両立させながら設計できるようになるでしょう。

Part 3では、DenoがTokioとFuturesをどのように活用し、高度な非同期処理を実現しているかについて深掘りする予定です。お楽しみに！