「同じCSVファイルを読ませているのに、自分のPCと別のPCで時刻が9時間ズレる」「Excelから書き出したときは合っていたのに、あとから処理したら朝の値が9時間ずれていた」——受け渡し用のCSVを挟むと、ここでつまずきます。
ファイルが壊れているわけではありません。私の環境では、原因は次の3つに絞り込めました（他の要因が絡む場合もあります）。私のシステムでは、この問題は画面に症状として出たのではなく、コードの点検で見つかりました（このPCでは偶然ずっと正しい答えが出ていたため、症状は一度も出ていません）。見つけてから直すまでに何を確認したかを、そのまま並べます。
⚠️ この記事の情報は2026年8月時点のものです。マーケットスピードII および RSS の仕様は変更されることがあるので、最新の情報は楽天証券の公式マニュアル（RSS関数仕様書）でご確認ください。仕様の変更に合わせて、この記事は随時更新します。
また、私のシステムは相場を観測・研究するためのもので、自動発注はしません（read-only）。判断はすべて仮想発注のみで、実際のお金での発注はしていません（実発注なし）。この記事は特定の銘柄の売買を勧めるものではありません。記事中の銘柄コード・価格はすべて架空の例です。
この記事で分かること（先に結論）
結論から書きます。書き出したCSVの時刻に「時差の情報」が入っていないからです。そして読み込む側が、その情報がない時刻を実行しているPCの設定で勝手に解釈する。だから同じファイルでも、読ませるPCによって答えが変わります。
- 書き出し側は、収集PCのローカル時刻を文字としてそのまま書いている。「これは日本時間です」という印は付いていない
- 読み込み側は、印のない時刻を実行PCの設定で読む。設定が違えば結果が動く
- 自分のPCでは「たまたま合っている」ので、普通のテストでは表に出ない。これがいちばん厄介でした
【早見表】症状 → まず見る場所
※そもそもRSSでExcelに株価を出すところからという方は、先にマーケットスピードII RSSの使い方をご覧ください。
| 症状 | まず見る場所 | 確かめること |
|---|---|---|
| 同じCSVなのにPCによって時刻が違う | 読み込み側のプログラム | 時差の情報がない時刻を、実行PCの設定で読んでいないか |
| 朝9時台のデータが9時間ずれた時刻（同じ日の夕方）として扱われる | 読み込み側のタイムゾーン設定 | 実行PCの設定が日本時間以外になっていないか（+09:00の印がない時刻は9時間ぶん後ろへずれる） |
| クラウドに置いた途端に結果が変わった | 実行環境のタイムゾーン | クラウド側の既定はUTCのことが多い |
| 自分のPCでは何度試しても再現しない | テストのやり方 | タイムゾーン設定を変えて試しているか |
前提：受け渡しCSVはどんな列でできているか
私のシステムは、Excel側で受け取った値をいったんCSVへ書き出し、それを別のプログラムが読む形です。列はこの8つ。
ts（時刻）／date（日付）／code（銘柄コード）／price（価格）bid（買い気配）／ask（売り気配）／volume（出来高）／source（取得元）
実際の1行は、たとえばこんな形です（銘柄コードと価格は架空の例に置き換えています）。
| ts | date | code | price | source |
|---|---|---|---|---|
| 09:01:56 | 2026-08-10 | 9999 | 1000.0 | ms2_rss |
ts は 09:01:56 という文字だけ。どこにも「日本時間」とは書いていない。この一点が、このあと全部の原因になります。
原因1：書き出し側に「時差の情報」が入っていない
収集PCのローカル時刻が、そのまま文字で書かれている
書き出し側のコードを読み直したら、答えはあっけないものでした。「いまの時刻」をそのまま文字にして、時分秒を ts に、年月日を date に入れているだけ。時差の情報は一切付けていません。
つまり 09:01:56 は「収集したPCのローカル時刻で9時1分56秒」という意味しか持たない。そのPCが日本時間の設定なら日本時間、別の設定ならその時間。ファイル側からは区別がつきません。
先に断っておくと、この記事で直せるのは「読み込み側」だけです。書き出し側に時差を書かせる改修は今回の範囲外で、いまも時差なしのまま出力しています。詳しくは後半の「いまも残る限界」で書きます。
自分の環境で裏を取る方法
推測で「たぶん日本時間だろう」と決めたくなかったので、実ファイルで確かめました。ある日の収集ファイルの先頭行が 09:01:56、日付は同じ日、取得元は ms2_rss。日本市場が開いた直後の時刻です。
これで「値は日本市場のローカル時刻と整合している」と裏が取れました。やり方は、寄り付き直後に収集されたファイルの1行目を開き、時刻が朝9時台か見るだけ。9時台でなければ、収集PCの設定を疑う番です。
原因2：読み込み側が「実行PCの設定」で解釈してしまう
ここが本丸でした。読み込み側は、印のない 2026-08-10 09:01:56 という文字を、内部の数値（基準の日から数えて何秒目か、という通し番号）へ変換していました。
問題は、その変換が「印がないなら、このPCの設定で読む」という動きだったこと。入力が同じでも、出てくる数値が環境で動くわけです。
再現テスト：タイムゾーン設定だけ変えて、同じCSVを読ませる
実際に測りました。同じCSVを、タイムゾーン設定だけ変えた3通り——「PCの既定のまま」「UTC」「アメリカ東部時間」——で読ませます。
修正前は3通りとも違う数値。記録に残っている実測では9時間ぶんの開きが出ました。修正後は3通りとも1つの値に揃った。1つのファイルから3つの答えが出る状態だった、ということです。
この確認にOSの設定変更は要りません。呼び出した先だけに効く一時的な実行環境（子プロセス）の設定だけを変えて試せます。自分のPCの時計をいじる必要はない。ただし、この切り替えが効くかどうかは環境によります（私の環境では効きましたが、効かないOSもあります）。値が動かなかったからといって安全とは限りません。その場合は、コード側で「時差の印を付けてから数値に変換しているか」を直接読んで確かめてください。
原因3：別のPCやクラウドへ持って行くと結果が変わる
クラウドの実行環境は、既定でUTC（世界標準時）になっていることが多い。手元で正しく動いていた処理をそのまま載せると、日本時間として書かれた「09:01」がUTCの09:01として読まれます。ズレは9時間ぶん。日本時間に直すと、寄り付きのデータが同じ日の夕方18時台として扱われる、という見え方です。
厄介なのは、エラーが出ないこと。プログラムは何も文句を言わず、静かに違う答えを返します。
確認手順3ステップ
- ステップ1：CSVの時刻の列を見る。
09:01:56のように時分秒だけなら、時差の情報は入っていません。+09:00のような印があるかどうかが分かれ目です - ステップ2：寄り付き直後のファイルで整合を見る。先頭行の時刻が朝9時台なら、日本市場のローカル時刻として辻褄が合っています。合わなければ収集PCの設定を疑う
- ステップ3：タイムゾーン設定を変えて同じCSVを読ませる。結果が動いたら、読み込み側が実行PCの設定に依存している証拠です（動かない場合は環境の都合で切り替わっていない可能性があるので、コードを直接確認）。このときPC本体（OS）の時計やタイムゾーン設定は変えないでください——他のアプリや予約実行に影響します。呼び出した先だけに効く一時的な実行環境（子プロセス）の設定だけを変えて試します
ステップ3を飛ばすと「自分のPCでは動くので問題なし」という結論になります。私がまさにそれでした。
実録：修正までの時系列と、詰まった箇所
このPCでは偶然正しいので、普通のテストでは気づけなかった
修正の前後で、実際に溜めてある3,139個の収集ファイルを通して結果を比べました。答えは1バイトも変わらなかった。
当たり前です。このPCは日本時間の設定なので、「このPCの設定で読む」動きが偶然ずっと正解を出していた。欠陥は「答えが間違っていること」ではなく「環境が変わると答えが動くこと」でした。手元で回すテストだけでは、この種の欠陥は表に出ません。
回避策：時差を固定して、変換前に必ず刻む
直し方は一言でいうと、数値に変換する前に「これは日本時間（UTC+09:00）です」と明示的に刻むだけです。刻んでから変換すれば、読み込み側についてはどのPCで読んでも同じ数値になります（書き出し側の前提が同じであれば、という条件つきです）。
ここで一つ選択をしました。タイムゾーンの扱いには、地域名（Asia/Tokyo）で引く方式と、時差の数字（+09:00）を直接持つ方式があります。選んだのは後者の固定値。地域名で引く方式は、別途タイムゾーンのデータベースが入っていない環境で失敗しうるからです。入口の変換が外部データの有無で挙動を変えるのは避けたかった。
代わりに限界も1行残しました。日本は1951年を最後にサマータイムを実施しておらず（1952年に廃止）、現状+09:00で一定ですが、将来導入されたらこの固定値は見直しが要る。直す場所が1か所で済むよう、時差の定義はプログラム内の1か所に集めています。
事前チェックが警告を出したが、回避せず証跡で答えた
作業中、仕込んである事前チェック（変更を確定する直前に自動で走る検査）が「RSS関連の挙動を変えている」と警告を出しました。止めるほどではないが要確認、という扱いです。
検査を黙らせる設定を入れるのは簡単でした。やらないことにしました。警告としては正しい検知だったからです。代わりに、何を変えて何を変えていないかを書き残して答えました。RSSのExcel関数は変更なし、CSVを書き出す側も変更なし、列の構成も変更なし、注文に関わる経路も変更なし。変えたのは「読み込む側の時刻の解釈」だけ。警告を消すより、範囲を書き出すほうが早い。
いまも残る限界：書き出し側は今もタイムゾーンなし
正直に書きます。この修正で直ったのは読み込み側だけです。
書き出し側は、いまも時差の情報なしでローカル時刻を書いています。つまり「収集しているPCの設定が日本時間になっていること」に依存したままです。収集PCの設定が変わったら、CSVの中身自体が変わります。読み込み側をいくら固めても、そこは守れません。
書き出し側にも時差を書かせる改修は、今回の作業範囲の外に置きました。「これで問題は消えた」とは言えない状態です。同じ構成でCSVを受け渡している方は、収集PCのタイムゾーン設定を変えないこと・変えるときはCSVの中身を確認することを運用ルールにしておくのが現実的だと思います。
なお、ここは公式リファレンスに載っている話ではなく私の環境での記録です。同じ症状でも原因が別にある可能性はあります。
非エンジニアが得た教訓
- 時刻の文字列は、それだけでは意味が確定しない。「9時1分」は、どの地域の9時1分かが書いていなければ情報として不完全
- 「自分のPCで動く」は、正しさの証明にならない。偶然、環境が一致しているだけのことがある
- ズレは静かに起きる。エラーが出ないぶん、数字がおかしいと気づくまでに時間がかかる
- 直したら、直していない範囲も書き残す。「読み込み側だけ直した」と書いておかないと、あとで自分が誤解する
まとめと、次に読む記事
同じCSVなのにPCによって時刻が変わるとき、見るべきは3か所です。書き出したCSVの時刻に時差の印があるか、読み込み側が実行PCの設定に頼っていないか、環境を変えて同じ結果になるか。この順で確かめれば、原因はだいたい絞れます。
なお、私のシステムは相場の観測・研究のためのもので、判断は仮想発注のみ、実際のお金での発注はしていません。この記事で扱ったのはCSVの読み書き、つまり観測の部分だけです。
関連記事
- マーケットスピードII RSSの使い方｜ExcelにRSSで株価を出すところから知りたい方はこちら
- マーケットスピードII RSSが動かないときの対処｜数式やデータが出ない側のトラブルはこちら
- マーケットスピードII RSSで全銘柄を扱う｜大量の銘柄をCSVで受け渡すときの構成
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年8月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント