Cordova でバーコードスキャナーアプリを作る：2026年ガイド

おそらく、あなたは次のどちらかの状況にいるはずです。ビジネス上重要なCordovaアプリを引き継いだか、あるいはチームが新しいツールへ徐々に移行する間、安定したハイブリッドアプリを維持しているか。そこに、スマートフォンのカメラで在庫ラベル、チケット、小包、棚札などをスキャンしたいというプロダクト要件が舞い込みます。

そこで Cordova用バーコードスキャナー ここからが本番です。基本的なデモを作るのは簡単ですが、プロダクション環境への統合はそうはいきません。バーコード形式に合ったプラグインの選定、ネイティブ権限の適切な設定、そして実機でしか発生しないプラットフォーム固有の挙動への対応が難所となります。もしアプリが現場作業や在庫フローに関わる場合、スキャン機能は通常、以下のような広範な運用課題と結びつきます。重要なITコンポーネントの管理、そこではモバイルアプリが、より大規模な資産およびサービスワークフローの一部となります。

Cordovaはエンタープライズの保守作業において依然として実用的なスタックです。2010年代半ばには、Cordovaでのバーコードスキャンはトイ的なデモを超え、Android向けに構築されバックエンドサービスと接続されたハイブリッドエンタープライズアプリへと進化しており、文書化されたフローとして cordova create, cordova platform add android、および生成された barcodeScanner-debug.apk を実用的なアプリビルドの例として SitePointのCordovaスキャン解説。チームが長期的なアーキテクチャの選択を検討している場合、このネイティブアプリとWebアプリの直接比較の比較は、なぜハイブリッドアプリが依然として本格的なモバイルデリバリーパイプラインに登場するのかを理解する助けになります。

Cordova アプリにバーコードスキャナーを追加する理由
- メンテナンスモードでもCordovaは意味がある
- 価値はデモではなくワークフローにある
Cordovaバーコードスキャナプラグインの選び方
- インストール前に確認すべきこと
- プラグイン比較表
インストールとプラットフォーム設定
アプリケーションへのスキャナーの実装 Code
テストとよくあるエラーのトラブルシューティング
パフォーマンスのヒントと Capacitor への移行
- Capacitor への実用的な移行パス

Cordova アプリにバーコードスキャナーを追加する理由

スキャナーは、Cordova アプリが現場でできることを変えます。ユーザーにシリアル番号や注文ID、商品コードを入力させる代わりに、カメラを入力デバイスとして使えます。これで手間が減るだけでなく、特に重要なのは、ユーザーが誤った値を入力する経路を減らせることです。

実際には、バーコードスキャンはモバイルアプリと実際の業務が交わる場面で使われます。倉庫の受入、小売での商品検索、フィールドサービスの部品検証、来客チェックイン、社内資産管理はいずれも効果を発揮します。スキャナーはユーザーの期待値も変えます。カメラが使えるようになると、明確なフォールバックがない限り、ユーザーは手動での code 入力を許容しなくなります。

メンテナンスモードでもCordovaは意味がある

Cordovaは消えたかのように語られることが多い。しかし実際には、メンテナンス負荷の高いエンタープライズ環境で生き残っている。動作しているアプリを置き換えるのは、機能を拡張するよりも難しい。認証、同期、フォーム、オフラインストレージをすでに処理しているアプリでは、スキャナーを追加する方が、製品全体を再構築するよりもリスクが低いことが多い。

実践的なルール： アプリの残りの部分がすでにチームの運用を阻害している場合を除き、スキャン機能の要求をリファクタリングのきっかけとして扱わないこと。

Cordovaが地位を確立したのは、プラグインがネイティブデバイスの機能をWeb code が利用可能な形で公開したからだ。そのため、ハイブリッドモバイルアプリでバーコードスキャンが普及した。Cordovaが設計されたパターンに完全に合致している：ネイティブ機能をJavaScript API の背後に置き、アプリのフローを主にWebベースに保つ。

価値はデモではなくワークフローにある

テキストを返すスキャンボタンは簡単な部分だ。主な作業は、その周囲にあるすべて:

サポート対象のシンボロジーの選択: アプリはQRコードのみで十分かもしれないし、小売や物流用のコードも必要かもしれない。
権限のクリーンな処理: カメラアクセスが一度でも失敗すると、ユーザーは機能が壊れたと考えることが多い。
スキャン後のアクションの設計: カメラUIよりも、検索、検証、ナビゲーション、重複処理の方が重要です。
モダナイゼーションの計画: チームが Capacitor への移行を進める場合、機能を Cordova 固有の前提条件に縛られないアプローチが必要です。

最後の点は重要です。チームは初期の Cordova 統合に成功しても、プラグインの下のネイティブレンダリングモデルが変わるため、移行時に問題にぶつかることが多いです。スキャナー自体は動作しますが、プレビューが想定した場所に映りません。

Cordova バーコードスキャナープラグインの選択

アプリの code を書く前に、何を最適化するかを決めましょう。幅広いバーコード対応が必要なチームもあれば、QRフロー用のカメラオーバーレイだけで十分なチームもあります。最初に間違ったプラグインを選ぶと、リリース後に製品側から追加のバーコード形式が要求された際に、後から作り直しが発生します。

多くの開発者が認識しているプラグインは cordova-plugin-barcodescannerです。その npm パッケージには scan(success, fail) API と、一般的なシンボロジー（ QR_CODE、DATA_MATRIX、UPC_A、EAN_13、CODE_128、PDF_417、AZTEC）への対応が記載されており、QRベースのユースケースだけでなく、小売や物流のシナリオにも適しています（ npm 上のプラグインパッケージのドキュメント.

プラグイン戦略をより広く検討しているチームには、 Capacitor プラグインに関する基礎知識が役立ちます。従来の Cordova 系プラグインの前提と、新しいネイティブブリッジモデルの違いを明確に示しているためです。

モバイル開発における cordova-plugin-cszbar と phonegap-plugin-barcodescanner の機能比較チャート。

インストール前に確認すべきポイント

人気だけで始めないでください。スキャン用途から考えましょう。

アプリが異なる運用環境で複数のバーコード形式を読み取る必要がある場合、最小限の API よりも幅広いシンボロジーサポートが重要です。QRコードでのチェックインのみであれば、カメラ体験がシンプルであれば、機能の少ないツールでも許容できます。ジュニア開発者が見落としがちなのは、スキャナーの課題は「スキャンできるか」ではなく、「運用で使われている正確なラベルを、無理な回避策なしにスキャンできるか」であるという点です。

良い選定チェックリストは次のようになります：

バーコード対応範囲： 本番環境で使われている正確な形式を確認してください。
プラットフォームの期待値： プラグインが過去に対応していたものではなく、チームが現在サポートしているものを確認してください。
UIモデル: 一部のプラグインはネイティブのスキャナーフローを開きます。他のプラグインは埋め込みプレビュー方式を前提としています。
移行耐性: アプリが後で Capacitor に移行したら、このプラグインが厄介になるか聞く

デモでは動くのに、アプリのレイアウトやライフサイクル、移行パスと衝突するプラグインは、たいてい間違った選択です。

プラグイン比較表

機能	phonegap-plugin-barcodescanner	cordova-plugin-qrscanner
主な用途	複数フォーマット対応のバーコードスキャン	QRコード中心のスキャンフロー
API スタイル	多くのレガシー Cordova プロジェクトで一般的なコールバックパターン	ライブカメラプレビューのようなユースケースに選ばれることが多い
バーコード形式の範囲	QR以外のスキャンも必要な場合に最適	QRコードのみが必須要件の場合に最適
移行リスク	動作は可能だが、新しいブリッジ移行で古い前提が表面化する可能性がある	プレビュー重視のアプローチは、レンダリングの問題をより早く露呈させることがある
最適	小売、物流、資産管理、複合バーコードのワークフロー	チェックイン、URL、認証、QRコード専用のフロー

この表はスコアカードではなく、実用上の適合性を示したものです。小売や物流のシンボロジーが必要なら、より広範なプラグインカテゴリを選ぶ方が通常は安全です。QRコードだけをスキャンし、より制御されたプレビュー体験を求めるなら、QR特化型の方が軽量で済みます。

最もよく見かける間違いは、最初のリリースでQRコードしか必要ないからといってQR特化型のツールを選び、後からUPCやCode 128への対応を無理やり追加してしまうことです。業務ユーザーがプリンター、棚、ビン、出荷書類のラベルをスキャンする可能性が少しでもあるなら、その将来を見据えて今選んでください。

インストールとプラットフォーム設定

統合が壊れるのは、スキャン後ではなく通常は最初のスキャン前です。ほとんどの失敗は、JavaScript側の想定とネイティブプラットフォーム設定の乖離から起こります。この部分はクイックインストールではなく、チェックリストとして扱ってください。

堅実な実装フローは、プラグインまたは SDK を追加し、キャプチャコンテキストを作成、本番で使うコードにシンボロジーを絞り込み、UI を設定し、最後にスキャンリスナーを登録する、という順序で始まります。この順序は Scandit の SparkScan 向け Cordova ガイドで示されており、ハイブリッドアプリでプロフェッショナルなスキャナー統合を保守しやすく保つ方法とも一致します。以下の Scandit の Cordova バーコードスキャン用開発者ガイドで説明されています。アーキテクチャレベルで依然としてハイブリッド色が強いなら、こちらの Cordova ハイブリッドアプリ開発ガイドが役立ちます。

code エディタを開いたノートPC、スタンドに置いたスマートフォン、木製デスク上の回路基板。

統合フローから始める

スキャナー機能は、まず次の項目を決めておくとスムーズに進みます：

アプリで受け付けるバーコードの種類。
スキャンを全画面アクションにするか、埋め込みワークフローの一部にするか。
読み取り成功後にアプリが何をするか。
カメラが使えない場合のフォールバック。

これにより、プラグインのインストールが汎用的なデバイス機能ではなく、実際のワークフローに紐付けられます。

Cordovaのインストール手順

一般的なバーコードスキャナープラグインを使う従来のCordova構成では、パッケージのドキュメントに記載された標準のインストールコマンドが出発点です。

cordova plugin add cordova-plugin-barcodescanner

一般的なプロジェクトセットアップの流れは次のとおりです。

cordova create barcodeScannerApp
cd barcodeScannerApp
cordova platform add android
cordova platform add ios
cordova plugin add cordova-plugin-barcodescanner
cordova build android
cordova build ios

この手順はシンプルですが、そこで止めないでください。プラグインのインストール直後にビルドして、UIをcodeにつなぎ込む前にネイティブ依存関係の問題を把握しましょう。ビルドが失敗したら、まずそれを解決してください。

最初に壊れがちなネイティブ設定

オンラインに iOSと、カメラへのアクセスはネイティブプロジェクトの設定で正しく宣言する必要があります。パーミッションの説明が欠落しているか曖昧だと、ユーザーにとってスキャナーは機能していないように見えます。 Info.plist アプリがカメラを必要とする理由を説明する、明確なカメラプライバシーの説明を追加してください。

オンラインに Androidでは、インストール後にマニフェストのエントリとプラグイン関連のパーミッションを確認してください。プラグインは必要なものを追加しますが、古いプロジェクトには蓄積された設定変更、カスタム Gradle 設定、プラグインの重複が含まれており、ビルド警告やランタイムでの混乱を引き起こす可能性があります。プラグインが正常にインストールされたからといって、マニフェストがクリーンだと安易に考えないでください。

この簡単なチェックリストを使用してください：

プラットフォームバージョンを確認： 古い Cordova プロジェクトには、古いプラットフォームパッケージが含まれていることが多いです。
パーミッションのプロンプトを確認： ユーザーの信頼には、文言とタイミングが重要です。
早期に実機でテスト： エミュレーターではカメラの挙動を十分に把握できません。
スキャナーのスコープは狭く保ちましょう: ワークフローで受け入れる code タイプのみを有効にしてください。

スキャナーに1〜2つのフォーマットしか不要な場合は、まずそれらを設定してください。幅広いスキャンは柔軟に見えますが、読み取れないラベルが曖昧になるため、デバッグが遅くなる傾向があります。

ジュニア開発者にとっての重要な教訓はこれです: インストールは単なるターミナルコマンドではありません。ネイティブプロジェクトの整合性確保です。AndroidとiOSを意図的に設定しなければ、JavaScriptレイヤーはあなたを救ってくれません。

アプリケーションへのスキャナーの実装 Code

プラグインをインストールしてアプリがビルドできたら、最初の実装はあえて地味にしましょう。スキャン操作をボタンに割り当て、結果はすべてログに出し、コールバックの流れが動くことを確認してから、洗練されたUIを設計してください。

一般的なCordovaスキャナーのパターンでは、プラグインの scan(success, fail) メソッドを使用します。このコールバック形式は古い手法ですが、レガシーなコードベースでは信頼性が高く、アプリがPromiseやTypeScriptの抽象化に移行していても、後からラップするのは簡単です。こうしたプロジェクトでWebの code がネイティブの code をどう呼び出すのか、より明確なメンタルモデルが欲しい場合は、 Capacitor がWebとネイティブの code をどう橋渡しするかについての解説が、今もCordovaで開発していても役立ちます。

段ボール箱のバーコードを、スマートフォンのカメラアプリでスキャンしている様子。

プレーンJavaScriptの例

古いCordovaアプリ向けの最小限の実装例はこちらです：

<button id="scan-button">Scan barcode</button>
<div id="scan-result"></div>

document.addEventListener('deviceready', function () {
  var button = document.getElementById('scan-button');
  var resultEl = document.getElementById('scan-result');

  button.addEventListener('click', function () {
    cordova.plugins.barcodeScanner.scan(
      function (result) {
        if (result.cancelled) {
          resultEl.textContent = 'Scan cancelled';
          return;
        }

        resultEl.textContent =
          'Text: ' + result.text +
          ' | Format: ' + result.format;
      },
      function (error) {
        resultEl.textContent = 'Scan failed: ' + error;
      }
    );
  });
});

これには3つの役立つポイントがあります。まず待機し、 devicereadyスキャンをユーザーの意図的な操作に紐付け、成功と失敗の両方を明示的に処理します。キャンセルされたケースを飛ばさないでください。ユーザーはカメラのフローを途中で抜けることがよくあります。

TypeScriptの例

TypeScriptを使っているなら、アプリの他の部分で問題なく扱えるよう、結果の型を自分で定義しましょう：

interface BarcodeScanResult {
  text: string;
  format: string;
  cancelled: boolean;
}

function scanBarcode(): void {
  cordova.plugins.barcodeScanner.scan(
    (result: BarcodeScanResult) => {
      if (result.cancelled) {
        renderStatus('Scan cancelled');
        return;
      }

      handleScannedCode(result);
    },
    (error: unknown) => {
      renderStatus(`Scan failed: ${String(error)}`);
    }
  );
}

function handleScannedCode(result: BarcodeScanResult): void {
  renderStatus(`Scanned ${result.format}: ${result.text}`);

  if (!result.text) {
    renderStatus('Empty scan result');
    return;
  }

  lookupItemByCode(result.text);
}

function renderStatus(message: string): void {
  const el = document.getElementById('scan-result');
  if (el) el.textContent = message;
}

function lookupItemByCode(code: string): void {
  console.log('Lookup code:', code);
}

この実装ではスキャン処理とビジネスロジックを分離しています。スキャナープラグインは入力の取得だけに留めるべきで、バリデーションや検索、画面遷移は別の場所で行うべきだからです。

スキャン結果の扱い方

スキャン後のフローとしては、主に以下のパターンがあります：

検索フロー： スキャンしたテキストを使って、製品・注文・アセットのレコードを取得します。
バリデーションフロー： 画面にすでに表示されている code を期待値として、スキャンした値と比較します。
ナビゲーションフロー： スキャンしたアイテムに関連するタスクへユーザーを遷移させます。
キャプチャフロー： 後で同期できるよう、値をローカルに保存します。

スキャナーのコールバックにAPI呼び出し、DOM更新、アナリティクス、ナビゲーションを詰め込まないでください。値は素早く引き継ぎましょう。

また、初期テストでは生結果をログに記録してください。本番UIに必要なのは textだけであっても、返される format はラベル不一致のデバッグに役立ちます。「スキャナーがこのcodeを読み取れない」と言われた場合、フォーマットデータは問題がバーコードの品質ではなくタイプにあることを示唆します。

テストとよくあるエラーのトラブルシューティング

バーコードスキャナーのCordova問題の多くは、スキャンAPI自体ではなく、Web UI、ネイティブビュー、デバイス権限の境界から生じます。ここでクリーンなデモが混乱したバグレポートに変わります。

診断が最も難しいのは、Capacitor移行やCordovaとCapacitorの混在環境で現れるAndroidのレンダリングバグです。Capacitorのissue #1213で、ある開発者がこう述べています： 「capacitor アプリでこのプラグインを試しましたが、スキャナーがアプリの背後にあるようです」、修正にはネイティブ WebView の背景を透明にし、DOM の透明度も合わせる必要がありますが、標準的な Cordova チュートリアルでは通常扱われていません。これは Capacitor の Android レンダリング問題に関するディスカッションに記載されています。ハイブリッド移行をデバッグしている場合は、こちらのガイドを参照してください: Capacitor アプリのデバッグ開いたままにしておく価値があります。

アプリのバグの背景にあるAndroidプレビュー

症状
スキャナーを起動します。権限は問題なさそうで、明らかなクラッシュもありません。しかし、カメラプレビューが見えない、遮られている、またはアプリUIの「背面」にあるように見えます。

原因
ネイティブのスキャナービューとWebViewでは、元のCordovaプラグインが想定していた重なり方と異なります。AndroidのCapacitor形式の構成では、WebViewの背景が不透明なままになり、ネイティブプレビューは存在していてもその下に隠れてしまいます。

ソリューション
両側で透過設定を適用します：

ネイティブ側： WebViewの背景を透明に設定します。
Web側： スキャナープレビューの上に重なるコンテナ要素から、不透明な背景を削除します。
レイアウト側: フルスクリーンラッパー、モーダルシェル、フレームワークのページコンテナのデフォルト背景色を確認してください。
テスト側: 開発シェルではレイアウトの挙動が誤解を招くことがあるため、実機のAndroidで検証してください。

これは、実際にはビューの構成問題なのに、開発者にプラグインが壊れていると思わせるバグです。

権限エラーと誤検知

権限の失敗は、スキャナーのバグのように見えることがあります。

ユーザーがカメラへのアクセスを拒否した場合、コールバックで汎用的なエラーが返ったり、スキャナーが想定通りに表示されなかったりします。権限の拒否はUIの通常の分岐として処理してください。何が起きたのか、アクセスを有効にした後にどう再試行すればよいかをユーザーに伝えましょう。特にiOSでは、権限に関する説明が不明確だと、ユーザーはスキャナーを見る前に不信感を抱きます。

いくつかの習慣が役立ちます:

明確なユーザー操作からスキャンをトリガーします: 権限プロンプトが怪しまれにくくなります。
フォールバックの入力手段を表示します: 手動入力でワークフローを維持できます。
拒否後の再試行パスをテストします: 多くのチームはハッピーパスを一度しかテストしません。

ビルドと実機テストの問題

一部の失敗は特定の環境でしか発生しません。

問題点	考えられる原因	実用的な修正
スキャナーが開くが、有用な結果が返らない	非対応または予期しないバーコード形式	設定されたユースケースに一致する既知のラベルでテストする
プラグインインストール後にビルドが壊れる	古いプロジェクトでのプラットフォームまたは依存関係の乖離	アプリのcodeを変更する前に、プラットフォームパッケージを調整する
あるアプリシェルでは動作するが、別のシェルでは動作しない	ビューのレイヤリングまたはCSSの干渉	画面を最小限のレイアウトに戻し、スタイルを徐々に追加していく
エミュレータの挙動は誤解を招く	カメラシミュレーションはデバイスの実態を反映していない	実機のAndroidとiPhoneで早期にテストする

デバッグ中は、ページを1つのボタンと1つの結果表示要素だけに絞る。そこでスキャナーが動作すれば、問題はプラグインではなく、レイアウトやアプリシェルcodeにあることが多い。

パフォーマンスのヒントと Capacitor への移行

バーコードスキャナーは正しくデコードできても、実用上はユーザーに失敗を招くことがある。問題として現れるのは、ラグ、ちらつき、カメラプレビューの異常、または同じテストプール内のデバイス間で挙動が異なるAndroid画面などだ。

古いCordovaアプリでは、デコーダーが弱点であることは稀だ。WebView、ビューのレイヤリング、およびスキャン結果に反応するcodeの方が、バーコード認識そのものよりも多くの問題を引き起こす。

まずはスキャン画面の範囲を絞ることから始めましょう。在庫ラベルをスキャンする画面なら、在庫ラベルのスキャンだけにします。余計なフィルター、アニメーション付きパネル、広範な状態更新は、Android WebViewのレンダリングがもともと不安定なところに再描画処理を増やします。

次の変更はすぐに効果が出やすいです：

受け付けるバーコード形式を制限する プラグインが対応していれば、誤読を減らせ、テストカバレッジも考えやすくなります。
スキャン後のロジックを簡潔に保つ パース、バリデーション、UI更新は、可能な限り最小限の部分だけに行います。
重複読み取りを一時的にブロックする デバイスによっては、ユーザーがカメラを動かす前に同じ結果が何度も発火します。
手動入力をフローに組み込む 実環境では、ラベルの破損、照明不足、反射するパッケージなどが依然として発生します。
Androidの再描画コストを注視する 重いオーバーレイ、CSS transition、レイヤー化されたコンポーネントは、Cordova WebView内のカメラプレビューを不安定にすることがあります。

モバイルバーコードスキャナーアプリを最適化し、将来に備えるプロセスを示す4ステップのインフォグラフィック。

Capacitor への実用的な移行パス

最もクリーンな Cordova から Capacitor への移行は、段階的に進めるもので、一気にやるものではありません。チームがトラブルに陥るのは、アプリコンテナ、スキャナープラグイン、権限フロー、UI オーバーレイを一度に置き換えて、どの変更が原因で壊れたのか分からなくなったときです。

代わりに、次の順序で進めてください。

現行プラグインを棚卸しする
すべての Cordova プラグインを洗い出し、それぞれを「アクティブ」「置き換え可能」「古いプラットフォーム動作に依存するリスクあり」に分類します。
まずアプリシェルを移行する
スキャナーのcodeを置き換える前に、既存のWebアプリをCapacitor内で実行してください。これでコンテナの問題とプラグインの問題を切り分けられます。
必要なら、移行期間中はCordovaプラグインを残す
スキャナー、ファイルアクセス、権限処理を同時に書き換えるより、一時的な互換性を保つ方が安全なことが多いです。
スキャナーの壊れやすい部分は早めに置き換える
カスタムオーバーレイ、文書化されていないAndroidの挙動、古いカメラ処理に依存する古いプラグインは、優先度を上げるべきです。

Androidのカメラプレビューのバグは、デバッグに多くの時間を奪われるため、特に注意が必要です。ネイティブプレビューがWebViewの背面に隠れたり、端が切れたり、特定のAndroid端末で真っ黒に描画されたりして、スキャナー画面が動作しないケースを何度も見てきました。その時点では、根本原因がビューの構成にあるにもかかわらず、真っ先にバーコードプラグインのせいにされがちです。

これはスキャナーだけの調査ではなく、レンダリングの調査として扱ってください。装飾的なオーバーレイを削除し、ページをプレビュー、トリガー1つ、結果フィールド1つだけに絞り込んでください。その後プレビューが安定するなら、問題は通常、デコードではなく画面構造かCSSにあります。

Capacitor への移行が正当化され始めるのもこの場面です。Capacitor はすべてのカメラバグを解消するわけではありませんが、通常はネイティブビューの処理と Web UI の code の間により明確な境界を作れます。バーコードスキャンでは、 @capgo/camera-preview カスタマイズ可能なコントロール付きのネイティブオーバーレイとしてライブカメラ映像を表示するので、プレビューがWebViewの背面に隠れることなく、JavaScriptでフレームをデコードできます。Zebraデバイスでのエンタープライズスキャンでは、 @capgo/capacitor-zebra-datawedge DataWedgeのプロファイルとスキャントリガーを管理します。NFCタグのワークフローでは、 @capgo/capacitor-nfc iOSとAndroidでネイティブのタグ検出、読み取り、書き込みを処理します。

Cordovaプロジェクトは、プラグインの老朽化やプラットフォームの変化、古い統合に潜む暗黙の前提によって壊れがちです。Capacitorプロジェクトでは、主にライフサイクル処理やネイティブレイヤー周辺で別の問題が表面化しますが、ネイティブ側がより明示的なため、障害の原因は追いやすくなります。

現在のCordovaスキャナーが、デバイス固有の修正を積み重ねてようやく動いているなら、パッチを追加するのはやめましょう。スキャン画面を安定させ、Androidのプレビューバグが本当にWebViewのレイヤリング問題なのかを確認してから、段階を区切って移行してください。その進め方は最初の1週間は遅くても、プロジェクトの残りでは速くなります。