記事に画像を挿入した際、デフォルトで画像自体に謎のメディアファイルURLへのリンクが貼られてしまい、読者が誤タップして離脱するのを防ぐ。

■ 実装コード

現在有効化しているテーマ（または子テーマ）のディレクトリ内にある functions.php の末尾に以下のコードを追記する。

※functions.php は管理画面の「外観」＞「テーマファイルエディター」から編集可能だが、構文エラーによる画面の真っ白化（サイトダウン）を防ぐため、必ずFTPソフトやサーバーのファイルマネージャー経由でバックアップを取ってから追記すること。

パスは /wp-content/themes/使用中のテーマ名/functions.php である。

// 画像挿入時のリンク先デフォルト設定を「なし」にする
add_action( 'after_setup_theme', 'set_default_image_link_none' );
function set_default_image_link_none() {
$image_set = get_option( 'image_default_link_type' );
if ( $image_set !== 'none' ) {
update_option( 'image_default_link_type', 'none' );
}
}

■ 結果

メディアライブラリから画像を挿入する際、リンク先の初期値が常に「なし」に設定される。

日々厳しさを増すSNSプラットフォームのAPI制限や、複雑怪奇な仕様変更に頭を抱えてはいないでしょうか。

• XのAPI無料枠が大幅に制限され、従来の自動投稿スクリプトが機能不全に陥った
• Threadsへの自動投稿を試みたいが、公式APIの認証フローが複雑すぎて開発が頓挫している
• Pythonを用いたブラウザ自動化ツールを構築したが、Windowsのセキュリティに弾かれたり、謎のエラーで停止したりと安定稼働に至らない

XのAPI制限によるスクリプトの機能不全は、多くの開発者が直面している現実です。無料で利用できたエンドポイントが突如として有料化されたり、投稿回数に厳しい上限が設けられたりと、プラットフォーム側の都合でシステムが停止するリスクが常に付きまといます。

Threadsの自動投稿においても同様です。APIの仕様が頻繁にアップデートされる過渡期においては、公式のドキュメントを追従するだけでも多大なリソースを消費します。

さらに、実行環境側（Windows OSなど）の強固なセキュリティ機能や、ブラウザ自動化ツール特有の環境依存エラー（アクセス拒否やプロセスの暴走）によって、ローカル環境での定期実行が阻まれるケースも後を絶ちません。

結論から申し上げます。他者が提供するAPIの仕様変更に怯える日々は、今日で終わりにしましょう。

APIに一切依存せず、Playwrightを用いた直接的なDOM（Webページの要素）操作と、堅牢な3層アーキテクチャを組み合わせることで、完全放置による安定したSNS自動投稿システムは確実に構築可能です。

システムの各フェーズである【データ生成】【データ統制】【投稿実行】を独立させることでリスクを分散させています。

そして、OSやプラットフォームの隠し仕様に対しては、その仕様を完全にトレースする論理的なロジックを自前で実装します。これにより、外部要因によるシステムのクラッシュを完全に防ぐことができます。

本記事では、複数ブログの記事を要約し、XとThreadsへ投下し続ける統合型自動SNSディストリビューションシステム【FREEDOM】の構築プロセスと、その過程で直面した致命的エラーの解決ロジックをすべて公開いたします。

• 統合型自動SNSシステム【FREEDOM】の3層アーキテクチャ設計
• Xの特殊なURL文字数換算仕様の解析とトリミング処理
• WindowsのSmart App Controlによる実行ブロックの合法的な回避手法
• Playwright環境におけるアクセス拒否（0x5）エラーとゾンビプロセスの完全排除

上記アカウントを見ていただけば一目瞭然です。

統合型自動SNSシステムの3層アーキテクチャ設計では、なぜ処理を分割すべきなのかというインフラ設計の基礎を解説します。

ただ、すみません。今回はコードをここに貼り付けるということはしません。ですが、ぶっちゃけAIに聞けば余裕で構築できますし、なんならclaude codeですぱっと構築できたりします。

今回渡しの場合はGeminiを使用しましたが、『こういう事ができるよ』というベースで初心者の方にお伝えするというものなのでその点はご了承ください。

コードを見たいという場合は、コメント等で教えていただければお伝えします。

さて、ここではXのURL文字数換算仕様の解析では、文字数制限オーバーというエラーをPython側でどう論理的に防ぐかを解説します。

WindowsのSmart App Control回避では、セキュリティレベルを一切下げることなく、OSの信頼プロセスを活用してバッチ処理を実行するテクニックを公開します。

アクセス拒否エラーとゾンビプロセスの排除では、自動化ツールを長期運用する際に必ず直面するメモリの圧迫と権限エラーを、インフラエンジニアの視点で根絶する方法をお伝えします。

この記事を最後までお読みいただくことで、単なるコピペスクリプトの作成にとどまらない、本質的で論理的なインフラ設計の思考法と、安定稼働を約束するトラブルシューティングのノウハウを習得できます。

統合型自動SNS投稿システムの全体アーキテクチャ

システムの安定稼働において最も忌むべきものは、単一障害点（SPOF：Single Point of Failure）の存在です。

初心者がシステムを組む際、データの取得からテキストの生成、スケジューリング、そして実際の投稿処理に至るまで、すべてを1つのPythonファイルに詰め込む設計をしがちです。しかし、この設計はどれか1つの処理がエラーを起こした瞬間（例えばネットワークの瞬断やAPIのタイムアウト）に、システム全体が沈黙するという非常に脆弱な構造です。

この致命的な問題を解決するため、本システム【FREEDOM】では、システム全体の工程を完全に分離・独立させた3層のアーキテクチャ（Layer 1〜3）を採用しています。

• Layer 1（製造）：各WordPressブログに配置したGoogle Apps Script（GAS）
• Layer 2（統制）：中央に配置したマスターデータベース（GASとスプレッドシート）
• Layer 3（実行）：ローカルのWindows 11稼働専用機（PythonとPlaywright）

Layer 1は、テキストデータの生成のみに責任を持ちます。Layer 2は、データの保管と適切な順序での受け渡しのみを担当します。そしてLayer 3は、受け取ったデータを元にブラウザを操作して投稿することだけに特化しています。

これら3つのレイヤーがどのように独立して稼働し、一つの巨大な自動化ミッションを完遂しているのか。各層の論理的な役割と実装の意図を詳細に解説いたします。

Layer 1（製造）：各WordPressブログにおけるコンテンツの自動生成

第1の層は、各WordPressブログに配置されたスレーブ（従属機）としてのGoogle Apps Script（GAS）です。このレイヤーの唯一の目的は、自サイトの最新記事を検知し、SNSへの投稿に最適化された魅力的なテキストデータを作成してデータベースへ送ることです。

各ブログに仕込まれたGASは、定期タイマーによって自動的に起動し、サイトのRSSフィードから最新記事のタイトル、URL、抜粋データを取得します。

ここで重要なのは、取得した文字列をそのままSNSに流し込まないことです。システムは取得したデータをGoogleの高性能生成AIであるGemini APIへ送信し、プラットフォームごとの文化に合わせた2種類のテキストを自動生成させます。

プロンプトによる厳格な制御を用いて、X用には【短文かつハッシュタグを含むテキスト】を生成させ、Threads用には【長文でハッシュタグを含まない、対話的なテキスト】を生成させます。

XとThreadsでは、ユーザーが好むフォーマットやタイムラインの雰囲気が明確に異なります。同一のテキストを機械的に使い回すことは、マーケティングの観点からもエンゲージメントの低下を招く悪手です。生成された2種類の専用テキストとメタデータ（URLなど）は、JSON形式という扱いやすいデータ形式にパッケージングされ、次の層であるマスターデータベースへと送信されます。

Layer 2（統制）：中央マスターDBとランダム抽出ロジックによるサイロ化の防止

第2の層は、各ブログから送られてきたテキストデータを受け取り、一時的にストックし、実行部隊の要求に応じて的確に払い出しを行う中央データベースです。ここでもGASとGoogleスプレッドシートを組み合わせることで、完全無料のAPIエンドポイントを構築しています。

各ブログから送信されたデータは、スプレッドシート上に【未投稿】というステータスでどんどん蓄積されていきます。開発初期の設計では、Layer 3（実行部隊）からデータの要求があった際、スプレッドシートの上から順に（つまり古いものから順に）データを渡すという極めて単純な仕様にしていました。

しかし、テスト運用を行う中で、この単純な仕様が運用上の致命的な欠陥を生み出すことが判明しました。例えば、特定のブログが1日の間に立て続けに3本の記事を更新した場合、マスターデータベースにはそのブログのデータが連続して3つストックされます。

その結果、SNSのタイムライン上には、同じジャンル、同じブログの投稿ばかりが連続して投下される【ジャンルのサイロ化（偏り）】が発生してしまったのです。これではフォロワーにスパムボットのような印象を与えかねません。

この問題を解決するため、API（doGet関数）のロジックを根本から書き換えました。

単に上からデータを取得するのではなく、ステータスが【未投稿】となっている全ての配列データを一度取得し、その中から【完全にランダムで1件を抽出】して払い出すロジックへと改修しました。

完全にランダムで1件を抽出することにより、複数のブログから集まった技術系、ゲーム系、ガジェット系といった多様なジャンルが完璧にミキシングされます。結果として、フォロワーを飽きさせない、人間が手動で投稿しているかのような自然なタイムラインの形成を実現しました。

Layer 3（実行）：ローカル専用機でのPythonとPlaywrightによる実行

第3の層は、ローカル環境に設置されたWindows 11専用機で稼働する、PythonとPlaywrightを用いた実行部隊です。このレイヤーの目的は、クラウドサーバーやVPS特有のデータセンターIP帯による制限（シャドウバンやボット判定）を回避し、一般家庭のプロバイダ回線を経由して、人間のブラウザ操作と見分けのつかない挙動でSNSへの投稿を完遂することです。

スケジューリング（投稿間隔）の設計においても、細心の注意を払っています。毎日決まった時刻や、きっちり2時間おきといった機械的な一定間隔の投稿は、SNSのスパム検知アルゴリズムに捕捉されるリスクを跳ね上げます。

そのため、Pythonスクリプトは毎時0分に起動し、乱数を用いて【その1時間の間に何回投稿するか】と【何分に投稿するか】を都度完全にランダムで算出する高度なロジックを搭載しています。これにより、人間の気まぐれなログイン間隔を完璧に模倣します。

算出した予定時刻に到達すると、Pythonは直ちにLayer 2のマスターデータベースへアクセスしてテキストデータを引き抜きます。その後、Playwrightを用いてブラウザを起動し、テキストボックスへの入力から投稿ボタンのクリックまで、実際の画面上でDOMを操作してXとThreadsへの自動投稿を行います。

公式APIの理不尽な制限や、頻繁に変わる複雑な認証仕様を一切無視し、フロントエンドから物理的にキーボード入力をシミュレートするこの手法は、SNS側のユーザーインターフェースが根本的に変更されない限り機能し続ける、極めて堅牢なアプローチです。

システム稼働を阻む4つの致命的エラーと突破の論理

アーキテクチャの設計がいかに完璧であっても、実際の運用環境ではプラットフォームの理不尽な仕様や、OS特有の予期せぬエラーが必ず牙を剥きます。

本システム【FREEDOM】の開発とテスト運用中、インフラの安定稼働を根底から脅かす4つの致命的な壁に直面しました。

• XのURL文字数換算仕様と過剰防衛トリミング
• WindowsのSmart App Controlによる実行ファイルのブロック
• PlaywrightとChromeのパス誤認によるアクセス拒否（0x5エラー）
• 沈黙するコンソールによるシステムのブラックボックス化

システムエンジニアたるもの、これらのエラーに対して再起動で誤魔化すような場当たり的な対処をしてはなりません。原因をファクトに基づいて特定し、論理的かつ恒久的な解決策をどのように実装したのかを、初心者の方にも分かりやすく解説します。

XのURL文字数換算仕様と過剰防衛トリミング

最初に立ち塞がった壁は、Xへの投稿処理時に発生した文字数制限のエラーです。テキストを作成する際、システムが140文字（全角）の制限を大幅に超過したと誤認し、重要なハッシュタグや文章の後半部分を過剰に切り落としてしまう（トリミングしてしまう）バグが発生しました。

この原因は、Xプラットフォーム特有の内部仕様と、プログラミング言語（Python）の標準的な文字数カウントロジックとの間に存在する明確なギャップにあります。

通常、Pythonのlen()関数などを使用して文字数をカウントすると、65文字ある長いURLは、馬鹿正直にそのまま65文字としてカウントされます。しかし、Xの内部仕様では異なります。Xはセキュリティチェックやアクセス解析のため、入力されたどのような長さのURLであっても、投稿時には公式の短縮URL（t.co）に自動で変換する仕組みを持っています。

この短縮URLは、元の長さに関わらず一律で【半角23文字（全角換算で11.5文字分）】として扱われます。

つまり、65文字のURLを含んで合計150文字になっているテキストは、Xの画面上では「URL（11.5文字分）＋その他のテキスト（85文字）」となり、合計100文字未満で余裕で制限内に収まっています。しかし、Python側は「150文字だから制限の140文字を超えている！」と判定し、テキストを削り落としていたのです。

この問題を恒久的に解決するため、Pythonの投稿準備処理内に、Xの内部仕様と全く同じ計算を行うカスタム関数（enforce_length_limit）を実装しました。

具体的には、正規表現を用いてテキスト内に含まれるURLを抽出し、その実際の文字数を全体のカウントからマイナスした上で、強制的に全角12文字分を加算するアルゴリズムです。これにより、長いURLを含む投稿であっても寸分違わぬ正確な文字数計算が可能となり、テキストの欠損を完全に防ぐ論理的なトリミング防壁が完成しました。

WindowsのSmart App Controlによる実行ファイルのブロック

第2の壁は、実行環境であるWindows 11 OS自体の過剰なセキュリティ防壁です。

作成したPythonスクリプトをタスクスケジューラなどで容易に実行・管理するため、初めはPyInstallerを用いてexeファイル（実行可能ファイル）化したり、batファイル（バッチファイル）化したりすることを試みました。しかし、これらのファイルを実行しようとすると、Windowsの高度なセキュリティ機能であるSmart App ControlやDevice Guardによって無慈悲に実行がブロックされてしまいました。

ブロックされる理由は明確です。個人が作成した実行ファイルには、Microsoftや信頼できる認証局が発行する【デジタル署名】が存在しないため、OS側が「出所不明の危険なプログラムである」と判定してしまうからです。

ここで、「スクリプトを動かすためにWindowsのSmart App Controlを無効化する」あるいは「セキュリティの保護レベルを下げる」という選択をするのは、インフラを構築するエンジニアとして下策の極みです。全体のセキュリティを犠牲にして部分的な利便性を取ることは絶対に避けなければなりません。

そこで、セキュリティ設定を一切変更することなく、この厳格な検閲を合法的にすり抜けるため、Windows標準の機能である【ショートカット（.lnkファイル）】を活用する手法を採用しました。具体的には、スクリプトへのショートカットを作成し、そのプロパティのリンク先（ターゲット）を以下のように指定します。

cmd.exe /k python C:\path\to\auto_post.py

この設計の論理的な肝は、OSが実行ファイルとして認識する対象をすり替えることです。OSがチェックするのは、署名のない独自のexeファイルではなく、Windowsがデフォルトで完全に信頼しているコマンドプロンプト（cmd.exe）になります。

OSから見れば「信頼できるコマンドプロンプトが起動し、その中でPythonコマンドを実行しているだけ」という極めて正常なプロセスに見えます。OSの信頼プロセスをいわば裏口として適切に利用することで、セキュリティの網を一切鳴らすことなく、スクリプトの完全な定期実行を確立しました。

PlaywrightとChromeのパス誤認によるアクセス拒否（0x5）

第3の壁は、Playwright実行時に発生した致命的なアクセス拒否エラー（エラーコード：0x5）です。

自動投稿を行う際、毎回ログインからやり直していては効率が悪く、不審なログインとしてアカウントがロックされる危険性があります。そのため、ブラウザのセッション情報（ログイン状態やCookie）を保持するディレクトリ（プロファイル保存先）を指定する必要がありますが、この指定を行った途端にシステムがクラッシュしました。

原因は、プロファイルの保存先を./chrome_profileのように【相対パス】で指定していたことにあります。

タスクスケジューラや先述のショートカットを経由してスクリプトが呼び出された際、システムが認識するカレントディレクトリ（実行時の基準となる作業フォルダ）は、スクリプトが置いてある場所ではなく、C:\Windows\System32などのシステム領域になってしまうことが多々あります。

その結果、PlaywrightはWindowsの心臓部であるSystem32フォルダの直下にchrome_profileというフォルダを作成し、データの書き込みを行おうとパニックを起こします。当然、そのような場所への書き込みは管理者権限が必要なため、OSのUAC（ユーザーアカウント制御）によって権限エラー、すなわち【アクセス拒否（0x5）】として弾かれていたのです。

この問題の解決策は、実行方法に依存しない【絶対パス】での厳格なロックです。スクリプト内でディレクトリを指定する際、r"C:\FREEDOM_System\chrome_profile"のようにドライブ名から始まる絶対パスでハードコード（または環境設定ファイルから読み込み）を行い、データの書き込み先を物理的に固定しました。

さらに、アクセス拒否が起きる別の要因として、前回の実行時に何らかの理由でPlaywrightがクラッシュし、バックグラウンドに見えないChromeのプロセス（ゾンビプロセス）が残存したままファイルをロックしているケースもありました。

このゾンビプロセスを完全に排除するため、Playwrightのプロセスを起動する直前に、OSのコマンドを用いて既存のChromeプロセスを強制的に終了させる（taskkill /F /IM chrome.exe /T 相当の処理）クリーンアップロジックを実装しました。これにより、環境依存の不安定要素を根絶しています。

沈黙するコンソールによるシステムのブラックボックス化

最後の壁は、プログラミングコードのエラーではなく、運用上のシステム設計に関わる重要な問題です。それは【可視性の欠如】です。

Layer 3の実行システムは、毎時0分にランダムなスケジュールを算出し、予定時刻にひっそりと投稿を行った後、次の時間帯のスケジュール計算まで完全に沈黙します。コマンドプロンプトのコンソール画面には何も表示されず、黒い画面がただ置かれているだけになります。

管理者としては、この黒い画面を見たときに「システムは正常に時間を待っている（待機中）のか」、それとも「内部で無限ループに陥ってフリーズしている（停止中）のか」を外から判断する術がありません。

インフラストラクチャにおいて、内部の状態がどうなっているのか把握できないブラックボックス化は、運用者に多大なストレスを与える最大の運用リスクです。

この不安を払拭するため、ロギングとコンソール出力の設計を大幅に見直しました。投稿処理が完了した直後、または毎時0分の計算処理が完了した直後に、以下のデータをコンソール画面へ明示的に出力するロジックを追記しました。

• 現在の時刻とシステムのステータス（待機中であるか、実行中であるかの明示）
• その1時間内において算出された「残りの予定投稿回数」
• 次の投稿が行われる「着弾予定時刻（〇時〇分）」

ただ待機機能（time.sleep）を使うだけでなく、システムが今何を考え、次にいつ動く予定なのかを常にテキストとして可視化することで、システム監視における不要な不安と不透明性を完全に排除しました。ちょっとしたユーモアを交えたログメッセージを表示させることで、開発者自身のモチベーション維持にも繋がっています。

まとめ：妥協なき設計だけが真の自動化を実現する

APIの仕様変更に振り回されず、OSのセキュリティを低下させることなく、完全放置で動作し続ける自動化システムを構築するためには、単にネットに落ちている表面的なコードを繋ぎ合わせるだけでは不十分です。

本システム【FREEDOM】の構築プロセスで示した通り、発生しうる最悪のシナリオ（パスの誤認、プロセスの暴走、仕様のギャップ）をあらかじめ想定し、それらを徹底した論理によって一つずつ潰していくインフラ設計のアプローチが必須となります。

他者が用意した環境やデフォルトの設定に盲従することは、運用における大きな脆弱性に直結します。妥協のないアーキテクチャ設計と、ファクトに基づくデバッグの徹底こそが、真の自動化と長期的なシステムの安定稼働をもたらす唯一の解であると断言します。

この記事が、自動化の壁に挑む皆様の設計の一助となれば幸いです。

それでは最後まで御覧いただきありがとうございました！ﾉｼ

以前、GitHub ActionsとGAS（Google Apps Script）を用いたサーバーレス構成で運用を試みましたが、「プラットフォーム依存による実行遅延（5分～30分の不可避なラグ）」と「リソース共有による実行スキップ」という構造的な欠陥に直面しました。

TDR待ち時間自動収集システムの構築手順｜GitHubとGASで資産化する方法ディズニーパークの混雑傾向を自分で分析したいが、手動での記録には限界がある 既存の待ち時間サイトが閉鎖されるリスク

記事を読む

データの鮮度が価値そのものであるリアルタイム分析において、制御不能な遅延は致命的です。 そこで私は、利便性を優先したGitHub Actionsを撤廃し、Xserver（Cron/Node.js）とGASを組み合わせた「オンプレミス回帰」とも言える堅牢な自律分散システムへと移行しました。

本記事では、以下の技術的課題をどのように解決し、月間数万レコードのデータを安定稼働させているか、その設計思想と実装の全容を公開します。

• 完全制御：Cronによる秒単位の実行スケジューリング
• データ整合性：JST（日本標準時）の厳密な管理と重複排除
• 耐障害性：API制限（429 Error）を考慮した指数バックオフの実装

単なるスクレイピングの手順書としてではなく、「信頼性の高いデータ収集基盤をどう設計すべきか」というエンジニアリングのケーススタディとしてご覧ください。

GitHub Actionsをスクレイピングに使ってはいけない理由

なぜ、無料で手軽なGitHub Actionsを捨てる必要があるのでしょうか。その理由は、以下の2点に集約されます。

• 実行時刻の不透明な遅延
• リソース共有による実行スキップ

GitHub Actionsのスケジュール実行は「ベストエフォート」であり、起動時刻が保証されません。10時00分に設定しても、実際には10時15分に開始されることが頻繁にあり、この15分のズレはデータの価値をゼロにします。（検証した結果、1時間後に実行されることもありました…）

また、混雑時には実行待機やスキップが発生し、ログすら残らず処理が消滅します。原因の切り分けが不可能になることは、長期運用において致命的なリスクとなるため、GitHub Actionsの使用を撤廃したと言うわけです。

XserverとGASによるシステム構成

データの正確性と連続性を高めるため、以下の役割分担でシステムを再構築しました。

• 実行エンジン：Xserver (Node.js)
• データベース：GAS + Google Spread Sheets

Xserver側では、Cronによる秒単位の定期実行、JST（日本標準時）の管理、リトライ処理を担当させます。一方、GAS側にはデータの受信、マスタデータとの照合（名寄せ）、および「蓄積ログ」の保存を担当させます。

この構成により、実行の正確さとデータの扱いやすさを両立させました。

Phase 1：GAS側（受信・蓄積エンジン）の構築

まず、データを受け取って保存する「データベース部分」を構築します。ここでは「蓄積ログ」と、英語名を日本語に変換するための「施設マスタ」の2つを用意します。

1. スプレッドシートの準備

新規スプレッドシートを作成し、以下の2つのシートを用意してください。

① シート名：「蓄積ログ」

収集したデータをひたすら溜めていくメインのシート（蓄積ログシート）です。1行目に以下のヘッダーを設定します。

• A列：日付
• B列：時間
• C列：曜日
• D列：祝日
• E列：パーク
• F列：アトラクション名
• G列：カテゴリ
• H列：エリア
• I列：DPA
• J列：待ち時間
• K列：元時刻
• L列：RunID

② シート名：「施設マスタ」

APIから来る英語名を、日本語名やエリア情報に変換するための辞書シート（マスタシート）です。ヘッダーは以下のように設定します。

• A列：英語名
• B列：日本語
• C列：カテゴリ
• D列：エリア
• E列：DPA

このマスタシートに行を追加していけば、コードを触らずに新アトラクションに対応できます。

2. GASコードの実装 (doPost)

Xserverからのデータを受け取り、マスタシートを参照して日本語化し、ログに追記するコードです。

/**
 * TDRデータ受信サーバー (doPost)
 * 生データを受け取り、日時分解・マスタ結合を行って蓄積ログへ保存する
 */
function doPost(e) {
  const lock = LockService.getScriptLock();
  if (!lock.tryLock(10000)) return ContentService.createTextOutput("Busy");

  try {
    const ss = SpreadsheetApp.getActiveSpreadsheet();
    const logSheet = ss.getSheetByName("蓄積ログ");
    const masterSheet = ss.getSheetByName("施設マスタ");
    
    // --- 1. マスタデータの読み込み (Map化) ---
    // A列:英語, B:日本語, C:カテゴリ, D:エリア, E:DPA
    const masterValues = masterSheet.getDataRange().getValues();
    const masterMap = new Map();
    // ヘッダー行(0)をスキップ
    for (let i = 1; i < masterValues.length; i++) {
      masterMap.set(masterValues[i][0], {
        jp: masterValues[i][1],
        category: masterValues[i][2],
        area: masterValues[i][3],
        dpa: masterValues[i][4]
      });
    }

    // --- 2. 受信データのパース ---
    const rawData = JSON.parse(e.postData.contents);
    if (!rawData || rawData.length === 0) return ContentService.createTextOutput("No Data");

    // --- 3. 重複チェック (RunID) ---
    const newRunId = rawData[0].run_id.toString();
    const lastRow = logSheet.getLastRow();
    if (lastRow > 1) {
      // L列(12列目)がRunID
      const lastRunId = logSheet.getRange(lastRow, 12).getValue().toString();
      if (lastRunId === newRunId) return ContentService.createTextOutput("Skipped");
    }

    // --- 4. 日時・祝日判定の準備 ---
    // Xserverから送られてくる updateTime (例: "2026/02/19 12:00:00") を解析
    const updateTimeStr = rawData[0].updateTime; 
    const dateObj = new Date(updateTimeStr);
    
    // 日付 (YYYY/MM/DD)
    const dateStr = Utilities.formatDate(dateObj, "Asia/Tokyo", "yyyy/MM/dd");
    // 時間 (HH:mm)
    const timeStr = Utilities.formatDate(dateObj, "Asia/Tokyo", "HH:mm");
    // 曜日
    const weekDay = ["日", "月", "火", "水", "木", "金", "土"][dateObj.getDay()];
    // 祝日判定 (Googleカレンダー利用)
    const calendarId = 'ja.japanese#holiday@group.v.calendar.google.com';
    const holidays = CalendarApp.getCalendarById(calendarId).getEventsForDay(dateObj);
    const isHoliday = (holidays.length > 0) ? "祝日" : "平日"; // 土日の場合も"平日"表記になるため、必要なら要調整

    // --- 5. データ変換 (マスタ結合 & A-L列生成) ---
    const rows = rawData.map(d => {
      // マスタ取得（なければ英語名のまま・不明扱い）
      const info = masterMap.get(d.name) || { 
        jp: d.name, category: "-", area: "-", dpa: "-" 
      };

      // 待ち時間の処理（CLOSE等は -1 になっているので文字に直すならここ。今回は数値をそのまま入れる）
      const waitVal = (d.status === "OPERATING") ? d.waitTime : -1; 
      // ※もしログ上で「休止」と文字で出したい場合は上記を書き換える

      return [
        dateStr,        // A: 日付
        timeStr,        // B: 時間
        weekDay,        // C: 曜日
        isHoliday,      // D: 祝日
        d.park,         // E: パーク
        info.jp,        // F: アトラクション名
        info.category,  // G: カテゴリ
        info.area,      // H: エリア
        info.dpa,       // I: DPA
        waitVal,        // J: 待ち時間
        d.updateTime,   // K: 元時刻
        d.run_id        // L: RunID
      ];
    });

    // --- 6. 蓄積ログへの追記 ---
    logSheet.getRange(lastRow + 1, 1, rows.length, 12).setValues(rows);

    return ContentService.createTextOutput("Success");

  } catch (err) {
    return ContentService.createTextOutput("Error: " + err.toString());
  } finally {
    lock.releaseLock();
  }
}

3. デプロイとURLの発行

Xserverからのアクセスを許可するため、以下の設定でデプロイを行います。

画面右上の [デプロイ] > [新しいデプロイ] をクリック。

• 種類の選択：ウェブアプリ
• 次のユーザーとして実行：「自分 (Me)」
• アクセスできるユーザー：全員 (Anyone)※最重要

発行されたURLは、次のフェーズで使用します。（これが後の工程で使用する「gasUrl」に設定するURLとなります。）

Phase 2：Xserver側（実行環境）の構築

WordPress等が稼働している公開領域を汚染しないよう、隔離されたディレクトリに実行環境を作ります。

まずは接続する設定をXサーバーの管理画面で行います。

準備

まずは準備が必要です。

1. [サーバーパネル] ＞ [SSH設定] ＞ [ONにする]。
2. [公開鍵認証用鍵ペア生成] ＞ パスフレーズを入力し [生成する] をクリック。

ローカル（PC）での配置：

.ssh ディレクトリへ移動し、鍵の権限を厳格に設定（chmod 600）。

SSH接続コマンド：

ssh -i ~/.ssh/〇〇.key 〇〇@〇〇.xsrv.jp -p 10022

※〇〇サーバー番号、ポート番号はデフォルトの22ではなく、Xserver指定の 10022 を使用します。

1. SSH接続とNode.jsの導入

セキュリティを担保するため、公開鍵認証にてSSH接続を行います。接続後、バージョン管理ツール nodebrew を使用して Node.js（v18系推奨）をインストールしてください。

2. プロジェクトディレクトリの作成

ホームディレクトリ直下に隠しディレクトリを作成し、プロジェクトを初期化します。

mkdir -p ~/.tdr_system/fetcher
cd ~/.tdr_system/fetcher
npm init -y
npm install node-fetch@2

Phase 3：収集ロジックの実装 (index.js)

タイムゾーン（JST）を厳密に管理し、API制限対策のリトライ機能を搭載したエンジンを実装します。このフェーズでの重要なポイントは以下の3点です。

• JST時刻の厳密管理
• 指数バックオフ（リトライ）
• 直接ファイルロギング

サーバーの時刻設定に依存せず、Intl.DateTimeFormat で日本時間を強制取得します。また、通信エラー時に即時終了せず、間隔を空けて再試行することで欠測を防ぎます。ログは標準出力ではなく、ファイルへ直接書き込むことでバッファ消失を防ぎます。

/**
 * TDRデータ収集・送信エンジン
 */
const fetch = require('node-fetch');
const fs = require('fs');
const path = require('path');

// Phase 1で発行したGASのURL
const gasUrl = 'https://script.google.com/macros/s/xxxxxxxxxxxxxxxxx/exec';

const logPath = path.join(__dirname, 'execution.log');
const writeLog = (msg) => {
    const now = new Date().toLocaleString('ja-JP', { timeZone: 'Asia/Tokyo' });
    fs.appendFileSync(logPath, `[${now}] ${msg}\n`);
};

(async () => {
    const now = new Date();
    const jstFormatter = new Intl.DateTimeFormat('ja-JP', {
        timeZone: 'Asia/Tokyo',
        year: 'numeric', month: '2-digit', day: '2-digit',
        hour: 'numeric', minute: '2-digit', second: '2-digit',
        hour12: false
    });
    
    const parts = jstFormatter.formatToParts(now);
    const p = parts.reduce((acc, part) => { acc[part.type] = part.value; return acc; }, {});
    
    const timestamp = `${p.year}/${p.month}/${p.day} ${p.hour}:${p.minute}:${p.second}`;
    const hour = parseInt(p.hour);
    const min = parseInt(p.minute);

    writeLog(`Check: ${timestamp} (H:${hour} M:${min})`);

    // 21:01〜07:59は実行停止
    if ((hour === 21 && min > 0) || hour > 21 || hour < 8) {
        writeLog("Operation out of hours. Process skipped.");
        process.exit(0);
    }

    const fetchWithRetry = async (url, options = {}, retries = 3) => {
        for (let i = 0; i < retries; i++) {
            try {
                const res = await fetch(url, options);
                if (res.ok) return res;
                writeLog(`HTTP Error: ${res.status} (Attempt ${i + 1})`);
            } catch (err) {
                writeLog(`Network Error: ${err.message} (Attempt ${i + 1})`);
            }
            if (i < retries - 1) await new Promise(r => setTimeout(r, 5000 * (i + 1)));
        }
        throw new Error(`Max retries reached: ${url}`);
    };

    try {
        const destRes = await fetchWithRetry('https://api.themeparks.wiki/v1/destinations');
        const destData = await destRes.json();
        const resort = destData.destinations.find(d => d.name.toLowerCase().includes('tokyo'));

        const childrenRes = await fetchWithRetry(`https://api.themeparks.wiki/v1/entity/${resort.id}/children`);
        const childrenData = await childrenRes.json();
        const targetParks = childrenData.children.filter(c => 
            c.name.toLowerCase().includes('disneyland') || c.name.toLowerCase().includes('disneysea')
        );

        const runId = now.getTime().toString(); 
        let allAttractions = [];

        for (const park of targetParks) {
            const liveRes = await fetchWithRetry(`https://api.themeparks.wiki/v1/entity/${park.id}/live`);
            const liveData = await liveRes.json();
            const parkType = park.name.toLowerCase().includes('disneyland') ? 'TDL' : 'TDS';

            const attractions = liveData.liveData.map(ride => ({
                park: parkType,
                name: ride.name,
                waitTime: (ride.queue && ride.queue.STANDBY) ? (ride.queue.STANDBY.waitTime || 0) : -1,
                status: ride.status,
                updateTime: timestamp,
                run_id: runId
            }));
            allAttractions = allAttractions.concat(attractions);
        }

        writeLog(`Sending ${allAttractions.length} records to GAS...`);
        const response = await fetchWithRetry(gasUrl, {
            method: 'POST',
            body: JSON.stringify(allAttractions),
            headers: { 'Content-Type': 'application/json' }
        });

        writeLog(`GAS Response: ${await response.text()}`);

    } catch (e) {
        writeLog(`CRITICAL: ${e.message}\n${e.stack}`);
        process.exit(1);
    }
})();

Phase 4：Cronによる完全自動化

不条理な遅延を許さない、Xserver内部スケジューラー（Cron）への登録を行います。

0,15,30,45 8-21 * * * cd /home/〇〇/.tdr_system/fetcher && /home/〇〇/.nodebrew/current/bin/node index.js >> /home/〇〇/.tdr_system/fetcher/debug.log 2>&1

※〇〇にはサーバーIDを入れてください。

WordPressへのリアルタイム連携

蓄積されたデータをブログで表示するため、GAS側にデータ取得用のAPI（doGet）を追加し、WordPress側でショートコードを作成します。

1. GASコードの追加 (doGet)

先ほどのGASプロジェクトに以下の関数を追加し、再度デプロイ（バージョンアップ）してください。

function doGet(e) {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sheet = ss.getSheetByName("蓄積ログ");
  
  // 最新の77件（アトラクション数分）だけを取得して返す例
  const lastRow = sheet.getLastRow();
  // ヘッダー行のみの場合は空を返す
  if (lastRow <= 1) return ContentService.createTextOutput("[]");
  
  // 過去の膨大なログから直近のデータのみ抽出
  // ※ここでは簡易的に末尾100行を取得するロジックとします
  const startRow = Math.max(2, lastRow - 100); 
  const data = sheet.getRange(startRow, 1, lastRow - startRow + 1, 7).getValues();
  
  // 最新の run_id を持つデータのみにフィルタリング
  const lastRunId = data[data.length - 1][6]; // 6番目=run_id
  const latestData = data.filter(row => row[6] === lastRunId);
  
  const headers = ["park", "name", "waitTime", "status", "area", "updateTime", "run_id"];
  const result = latestData.map(row => {
    let obj = {};
    headers.forEach((h, i) => obj[h] = row[i]);
    return obj;
  });

  return ContentService.createTextOutput(JSON.stringify(result))
    .setMimeType(ContentService.MimeType.JSON);
}

2. WordPress (functions.php)

以下のコードを追加することで、ショートコード [tdr_wait_list] が使用可能になります。

add_shortcode('tdr_wait_list', function() {
    // GASのウェブアプリURL
    $url = 'https://script.google.com/macros/s/xxxxxxxxxxxxxxxxx/exec';
    
    // Transient APIで60秒間キャッシュ
    $cache_key = 'tdr_data_log';
    $data = get_transient($cache_key);

    if (false === $data) {
        $response = wp_remote_get($url);
        if (is_wp_error($response)) return 'データ取得中...';
        $data = json_decode(wp_remote_retrieve_body($response), true);
        set_transient($cache_key, $data, 60);
    }

    if (empty($data)) return '現在データはありません';

    $html = '<div class="tdr-wait-list">';
    foreach ($data as $row) {
        $wait = ($row['status'] === 'OPERATING') ? $row['waitTime'] . '分' : '一時休止';
        if ($row['status'] === 'CLOSED') $wait = '終了';
        
        $html .= '<div class="attraction-item">';
        $html .= '<span class="name">' . esc_html($row['name']) . '</span>';
        $html .= '<span class="wait">' . esc_html($wait) . '</span>';
        $html .= '</div>';
    }
    $html .= '</div>';
    return $html;
});

まとめ

本構築により、GitHub Actionsという不透明なリソースを排除し、自らの管理下で「責任の所在」を明確にしたデータ収集基盤が完成し、現在の待ち時間を15分間隔で取得してWordPressで確認できるところまで実装できました。

次は蓄積したデータを基にグラフとして可視化したり、何曜日の何時くらいが空いているのか、何月に人が多いのかなどの情報を他の予測するサイトより、数字に基づいた立証データを出せると思いますので楽しみにお待ちいただければと存じます！

最後までご覧いただきありがとうございました！

もし一つでも当てはまるなら、この記事が「答え」です。

結論から言います。OptiPlex990を捨てないでください！

5年前のPCでも、正しい手順を踏み、たった1つのパーツを交換すれば、Windows 11の最新バージョン（25H2）が実用レベルで動作します。

必要な追加投資は、新品のSSD代（約5,000円〜）のみです。 これだけのコストで、廃棄寸前のPCが「現役の事務マシン」に生まれ変わります。実際に私が検証した全手順と結果を公開します。

【結論】第2世代Core i5でもWindows 11は「サクサク」動く

まず、論より証拠をご覧ください。これが現実です。

「無理やりインストールしたら重くなるのでは？」という常識は間違いです。ストレージをHDDからSSDにさえ換えていれば、Excelの起動、YouTubeのフルHD再生、複数タブを開いてのブラウジングは驚くほど軽快です。

はっきり言って、ドン・キホーテなどで売られている「現行の格安CeleronノートPC」よりも、この15年前のCore i5の方が遥かに快適に動作します。事務用PCとしての寿命は、これで完全に延びました。

なぜ今、あえて「Dell OptiPlex 990」なのか？

今回、実験台（兼、私のサブ機）としてOptiPlex 990 Core i5 モデルを選んだのには、明確な理由があります。

圧倒的な安さと流通量、そして中古市場では数千円で投げ売りされているお店も多数あり、多くの中小企業の倉庫にも眠っています。（ただ、2026年1月現在だと購入するのは難しいかもしれません笑）

神がかったメンテナンス性 Dellのこの世代のビジネスPCは、工具不要でケースを開けられ、パーツ交換が容易です。「壊れても痛くない実験機」としてこれ以上の素材はありません！

…と言っていますが、家においてあるPCをなんとか有効活用したいなーって思っただけというのは内緒。

第2世代のCore i5搭載のOptiPlex 990は、PCの歴史に残る名機と言っても過言じゃありません。（あ、いや過言かも…。）ITテクニカルアドバイザーの意地として、Windows 11ごときで引退させるには惜しいポテンシャルを持っていますので復活させます！

準備編：インストールUSBの作成手順（Rufus設定）

ここからが具体的な手順です。マイクロソフト公式のメディア作成ツールは使いません（要件チェックで弾かれるため）。代わりにフリーソフトの「Rufus」を使います。

用意するもの

いくつか以下の通りです。

• 8GB以上のUSBメモリ（中身は消えるので注意）
• Windows 11のISOファイル（Microsoft公式サイト等のアーカイブから 25H2 を使用・無料）
• Rufus（ブートUSB作成ツール・無料）
• 2.5インチ SATA SSD 250GB以上（※必須です。Amazon等で5,000円〜7,000円程度で購入可能）

【最重要】Rufusの設定

ISOファイルをRufusに読み込ませ、「スタート」を押した直後に出るこの画面が運命の分かれ道です。

用意していただいたUSBメモリをPCに接続しRufus-〇〇.exeをダブルクリックで起動します。（〇〇はバージョンです、最新は4.11.2285）

すると以下のようなソフトが立ち上がります。

USBメモリが挿さっていれば、基本的にはブートの種類の右側の「選択」をクリックして

ダウンロードしたwin11のisoファイルを選択するだけでOKです。スタートを押します。

すると次のようなポップアップが表示されます。

重要なのは赤枠の部分。

必ず、一番上の項目「4GB以上のRAM、セキュアブート及びTPM 2.0の要件を削除」にチェックを入れてください。

これにチェックを入れるだけで、インストーラーが行う「古いCPUお断り」「TPMチップがないとお断り」という厳しいチェックを全て無効化（スキップ）できます。 これ以外に難しい設定は一切不要です。

作成に結構時間かかりますが、5～10分ほどお待ちください。

実践編：エラーゼロでデスクトップまで到達

覚悟して挑みましたが、正直に言うと「書くことがない」ほとんどないくらい、驚くほど普通にインストールできました。

作成したUSBメモリをOptiPlex 990に挿し、デスクトップにあるPCアイコン→USBメモリを選択、

setup.exeをダブルクリックして、インストーラーを起動してあとは通常のWindowsインストールと同じ画面が進んでいきます。

• ブルースクリーン？　→　出ません。
• 「このPCは要件を満たしていません」という警告？　→　出ません。
• 途中の再起動でのフリーズ？　→　ありません。

写真を撮るタイミングを逃すほどスムーズに進行しまして、気づけば「こんにちは」の画面を経てデスクトップが表示されていました。この「あっけなさ」こそが、Rufusを使ったクリーンインストールの最大のメリットですね。

検証編：ドライバとセキュリティは大丈夫か？

「入ったとしても、音が出ないとか画面がおかしいとかあるんでしょ？」 そう疑っている方、検証結果をお見せします！

1. デバイスドライバの認識状況

驚くべきことに、Windows 11標準のWindows Updateを回しただけで、Dell特有のチップセットやオーディオドライバがほぼ全て自動で当たりましたしなんの支障もエラーもなかったです。 「不明なデバイス」を探してネットを彷徨う必要はありません。現代のOSの対応力は凄まじいですね。

2. アイドル時の負荷状況

起動してからYouTubeを見てみました。CPU使用率は10～40％（安定はしませんけど、まぁこれはYouTubeの特性である意味で一定です）、メモリ消費も一定であり、落ち着いています。

バックグラウンドで不要なプロセスが暴走することもなく、非常に安定しています。これが「クリーンインストール」の強みでもありますね。

余談：SSDの交換について

OptiPlex 990は元々はSSDではなくHDDが搭載されていました。

2～3年前にSSDへ換装しており、今回換装自体は端折っております。

なお、SSDに交換するにはその当時、EaseUSという会社の無料のクローンソフト（バックアップ兼起動可能）がありまして、クローンを作りSSDへの換装を行えておりました。

ですが現在は改悪され、無料でクローンを作れなくなりました・・・が！最近ではAcronisというソフトを使用して、完全無料でクローンを作成することが可能です。

Google検索やYouTube等で換装方法はいくらでも出てきますのでご参照ください。

一応必要なものを置いておきます。

＼安定のWD製SSDです／

Western Digital (ウエスタンデジタル) 240GB WD Green 内蔵SSD ソリッドステートドライブ – SATA III 6Gb/秒 2.5インチ/7mm 最大545MB/秒 – WDS240G3G0A

created by Rinker

ウエスタンデジタル(Western Digital)

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

＼こちらも安定な玄人志向のお立ち台／

玄人志向 外付け 3.5 型 / 2.5 型 SATA 接続 HDD/SSD スタンド お立ち台 USB3.2 Gen1 対応 最大容量 32TB ドライブ換装 【国内正規品】 KURO-DACHI/CLONE/CRU3

created by Rinker

玄人志向

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

まとめ：5,000円のSSD投資で、PC寿命はあと3年延びる

今回の検証結果をまとめます。

• OptiPlex 990（Core i5-2500）は、Windows 11でも現役性能を発揮する。
• Rufusを使えば、TPM 2.0やCPU制限は完全に無視できる。
• ただし、約5,000円の「SSD換装」は絶対に必要（HDDは不可）。

逆に言えば、「飲み会1回分のコスト」で、廃棄寸前のPCが「最新OS搭載のサブ機」に生まれ変わるということです。コストパフォーマンスという意味では、最強の部類に入ります。

Windows 10のサポート終了に怯えて、使えるPCを捨てるのはやめましょう。技術と知恵があれば、まだまだ彼らは働けます！

【法人・個人事業主の方へ】そのPC、廃棄する前にご相談ください

「記事の手順通りにやればできることは分かった。しかし……」

• 「社内にある10台以上のPCを、一台ずつ設定して回るのは面倒すぎる」
• 「万が一、失敗して重要なデータが消えたら怖い」
• 「SSDへの換装作業なんて、ドライバーを握ったこともないから不安だ」

そんな経営者様・担当者様へ。 「Creative Swamp」では、『中小企業向けPC延命リフレッシュ代行』も行っています。

面倒なインストール作業、SSD換装、メモリ増設、内部清掃まで、全てワンストップで代行いたします。新品の法人用PCを買い替えるコストの1/5以下で、快適でセキュアなWindows 11環境を構築しませんか？

まずは「PCの型番」と「台数」をご連絡ください。既存の環境を調査し、最適な延命プランをお見積りいたします。

[ >> お問い合わせ・見積もり依頼はこちら（フォームへ移動） ]