OneDrive配下のTech Blog作業を避け、C:\devでGitHub公開する運用

はじめに

Next.jsで構築したTech Blogを、OneDrive配下で編集していると、記事追加そのものよりも周辺作業で時間を取られることがあります。

たとえば、npm run buildで.nextを作り直すときにEPERMが出たり、publish_articles.batでビルド、commit、pushまで進める途中でファイル削除が失敗したりします。

原因の多くは、記事の中身ではなく、OneDriveの同期対象フォルダ内で大量の生成ファイルを扱っていることです。

この記事では、Softex Celware Tech Blogのような記事追加型サイトを例に、共有資産フォルダはOneDriveに残しつつ、サイト本体の作業リポジトリだけをC:\devへ移して安定させる運用を整理します。

問題は記事本文ではなく作業場所に出る

Tech Blogの記事追加では、次のような処理が発生します。

MDX記事を追加する
画像をpublic配下へ置く
用語集や関連記事リンクを更新する
article-workflow.batで記事の確認を行う
npm run buildで静的ページを生成する
publish_articles.batでcommitとpushまで行う

このうち、OneDriveの影響を受けやすいのは、主にnode_modules、.next、Gitの作業ファイル、ビルド時に生成される多数の小さなファイルです。

本文のMDXファイルが悪いわけではなく、同期サービスがファイルを監視している最中に、Node.jsやNext.jsが大量のファイルを作成・削除することで競合が起きます。

起きやすい症状

実際の運用では、次のような症状が出ます。

症状	起きる場面	見るべきポイント
`.next`を削除できない	`npm run build`や公開バッチ	OneDriveが生成物を同期・ロックしていないか
ビルドが極端に遅い	記事追加後の確認	`node_modules`や`.next`が同期対象になっていないか
publish前後で待ち時間が長い	commit / push前のビルド	ファイル監視とGit操作が重なっていないか
原因調査が記事本文に寄りすぎる	ビルド失敗時	まず作業場所と生成物ロックを疑う

特にEPERM: operation not permitted, rmdir ...\.next\static\...のようなエラーは、記事本文よりも、生成物の削除が外部プロセスに妨げられている可能性を先に見ます。

推奨する分離方針

方針はシンプルです。

OneDrive側:
  記事ネタ、画像素材、開発ノウハウ、作業メモを保管する

C:\dev側:
  Tech Blog本体のGitリポジトリをcloneする
  npm install / npm run build / article-workflow / publishを行う

GitHub:
  サイト本体の履歴と公開用ソースの正とする

OneDriveは、開発資産や素材を蓄積する場所として便利です。一方で、ビルド成果物や依存パッケージを頻繁に作り替えるWebサイト本体は、OneDrive外に置いた方が安定します。

cloneで作業リポジトリを作る

既存のOneDrive側フォルダを丸ごと移動するより、GitHubから新しくcloneする方が安全です。

mkdir C:\dev
cd C:\dev
git clone https://github.com/YujiFukami/SoftexCelwareTechBlog.git
cd SoftexCelwareTechBlog
npm install
npm run build

cloneで作ると、.git、remote、branchの状態が整理された状態から始められます。

未コミットの変更を持ったまま移動するより、まずGitHub上の最新状態をC:\devへ取得し、今後の作業場所を切り替える方がトラブルを減らせます。

記事ネタとサイト本体を分ける

この運用では、OneDriveを使わなくなるわけではありません。

OneDrive側には、次のような素材を置きます。

記事化したい開発ノウハウ
画像、スクリーンショット、説明図
サンプルコード
記事作成指示書
案件固有ではない共有テクニック

一方で、C:\dev側では、次の作業に集中します。

content配下の記事MDXを編集する
public配下へ公開用画像を配置する
src/lib/terms.tsなどサイト本体を更新する
article-workflow.batで確認する
npm run buildでビルドする
publish_articles.batでcommitとpushを行う

この分け方にすると、OneDriveは素材保管、GitHubはソース管理、C:\devは作業実行という役割に整理できます。

公開前の確認フロー

C:\devへ切り替えた後も、記事追加時の確認フローは変えません。

cd C:\dev\SoftexCelwareTechBlog
.\article-workflow.bat content\codex\sample-article.mdx
npm run build
.\publish_articles.bat "Add sample article"

重要なのは、これらをOneDrive配下ではなくC:\dev側で実行することです。

article-workflow.batは、用語候補、関連記事候補、機密語候補、frontmatter、画像パスなどを確認するための入口です。記事本文を整えた後、公開前チェックとして使います。

publish_articles.batは、ビルド、stage、commit、pushまでをまとめて実行する公開用の入口です。

OneDrive側に残すならショートカットだけにする

OneDrive側からC:\devの作業フォルダを開きたい場合は、.lnkショートカットを置く程度に留めます。

ジャンクションやシンボリックリンクでOneDrive側からC:\devの実体へつなぐと、同期ソフトがリンク先を辿ってしまう可能性があります。

導線を作るだけなら、Windowsのショートカットで十分です。

注意点

OneDrive側の古いwebsiteを編集し続けない
C:\dev側で作業することをVS CodeやCodexの開始時に確認する
.envなどGit管理外のファイルが必要な場合は移し忘れない
GitHubへpushできていることを公開完了の基準にする
OneDrive側は素材とメモの保管場所として扱い、ビルド作業場所にしない

同じサイトの実体が2か所にあると、どちらを編集したか分からなくなります。運用を切り替えた後は、編集対象をC:\dev側に固定するのが重要です。

まとめ

OneDrive配下でTech Blogのビルドや公開作業を行うと、記事本文とは関係ないファイル同期・ロック問題で作業が止まることがあります。

素材やノウハウはOneDriveに置き、サイト本体はC:\devへcloneして、ビルド、記事確認、commit、pushをそこで行う。この分離にすると、OneDriveの便利さを残しながら、Next.jsとGitHubを使った公開作業を安定させやすくなります。