それでは毛玉諸君、これにて失敬

日々の精進を備忘録的に綴ります。

JTのロシア事業について少し調べた

JT(日本たばこ産業)の株を保有しているのですが、先日、ロシア事業に関するニュースを受けて株価が大きく下がりました。

JTは昔から高配当株として知られています。僕も配当をもらいながら長く保有したいと思っていたので、今回のニュースはなかなか衝撃的でした。

そもそもJTがロシアでどれくらい事業をしているのか、あまり知らなかったので、AIも使いながら少し調べてみました。

何が起こったのか

2026年11月5日、ロシアのプーチン大統領が、JTのロシア現地法人4社をロシア企業の「一時管理下」に置く大統領令に署名しました。翌6日にはさらに3社が追加され、対象は合計7社になりました。

「一時管理」とは、所有権そのものが移るわけではないものの、現地の事業をロシア側が管理できるようになる措置です。

つまり、JTはロシアでの事業をこれまでどおり自由に経営できなくなる可能性が高いということです。

このニュースを受けて、11月6日のJTの株価は前日比19.3%下落し、6,269円でストップ安となりました。

JTは今回の措置について、詳細や今後の対応、業績への影響を確認していると発表しています。

参考: - JT:当社グループのロシア事業について(2026年11月6日) - ロイター:ロシア、一時管理下のJT傘下企業を3社追加(2026年11月8日) - 共同通信:JT株19%下落、ストップ安(2026年11月6日)

JTのロシア事業は思った以上に大きかった

調べて驚いたのが、ロシア事業の規模です。

JTは1999年の海外たばこ事業の買収をきっかけにロシアで事業を展開し、その後も現地企業を買収するなどして規模を拡大してきました。

2026年1〜9月時点でロシアのたばこ市場における販売数量シェアは約36%。ロシア国内で最大手のたばこ会社です。

さらに報道によると、ロシア事業はJTグループの売上高の約10%、営業利益の約25%を占めるとのこと。

売上の約1割に対して利益は約4分の1。思っていた以上に重要な市場だったようです。

これだけ利益に貢献している事業の経営権を失うとなれば、株価が大きく下がったのも理解できます。

参考: - JTI:ロシア事業の紹介(英語) - JT:投資家説明会資料 - ロイター:ロシア事業の規模について

なぜロシアから撤退しなかったのか

2022年にロシアがウクライナへ侵攻して以降、多くの外国企業がロシアからの撤退や事業縮小を進めました。

JTも2022年3月にロシアでの新規投資やマーケティング活動を停止し、事業の売却を含む選択肢を検討していました。

それでも、事業は継続してきました。

利益への貢献が大きいことに加え、工場や従業員を抱える事業を簡単に売却できない事情もあったのだと思います。

ただ、JTがなぜ撤退しなかったのか、その判断の詳しい背景までは分かりませんでした。

参考: - JT:ロシア市場における現在の状況に関するお知らせ(2022年3月10日) - 会社四季報:JT、ロシア事業の売却も選択肢に(2022年4月28日)

そもそも、なぜロシアはJTの事業を管理下に置いたのか

ここも気になりました。

調べてみると、今回の大統領令にはJTを対象とした具体的な理由は書かれていないようです。

一方、ロシアは2023年に、外国企業の資産を一時管理下に置く制度を設けています。

ロシア側はこの制度を、欧米などによるロシア資産の凍結や制限に対する措置として説明しています。

日本もウクライナ侵攻後、ロシアへの経済制裁に参加してきました。

つまり、JTの経営が悪化したからではなく、国同士の関係が影響して今回のような事態になったと考えられそうです。

ただし、なぜ数ある日本企業の中からJTが選ばれたのか、今回の決定の具体的な理由は分かっていません。

参考: - ロイター:ロシアによるJT資産の一時管理について(2026年11月7日) - ロシア大統領令第302号の日本語仮訳(2023年)

他にもロシアで事業をしている日本企業はある?

気になったので、JT以外の企業についても少し調べてみました。

例えば、横浜ゴムはロシアにタイヤの生産拠点を持っています。公式サイトによると、現地法人では2025年末時点で715人が働いていました。

また、三井物産や三菱商事は、ロシアの石油・天然ガス開発事業「サハリン2」に出資しています。

特にサハリン2は日本のエネルギー調達にも関わる事業で、簡単に撤退を判断できるものではなさそうです。

もっとも、工場を自社で運営している場合と、資源開発事業に出資している場合とでは事情が違います。

ロシアに関わる日本企業がすべてJTと同じ状況にあるわけではありませんが、他の企業も政治的なリスクと無関係ではないのだと思いました。

参考: - 横浜ゴム:ロシア現地法人 - 三井物産:投資家情報・決算資料 - 三菱商事:決算公表資料

今回のニュースで学んだこと

今回のニュースで、株式投資では地政学的なリスクも考える必要があるんだなと思いました。

これまでは、企業の業績や利益、今後の市場動向などを中心に考えていました。

でも今回のJTのように、事業が利益を生み出していても、国同士の関係によって状況が大きく変わることがあるんですね。

ウクライナ侵攻が始まったのは2022年なので、今回のリスクも突然生まれたわけではありません。自分があまり意識していなかっただけなんだと思います。

とはいえ、こうした出来事を事前に予測するのは難しそうです。

今後は、企業がどの国で事業を展開しているか、その国にどんな政治的・経済的リスクがあるのかも、少し意識してみようと思いました。

JTの株はどうしようか

さて、肝心の保有しているJT株についてです。

JTの2026年の年間配当予想は1株272円。配当性向75%を目安とする方針もあり、高配当株としての魅力は感じています。

ただ、今回のニュースで、ロシア事業への依存度が思っていたより高いことが分かりました。

今後、ロシア事業の利益がJTグループの業績に反映されなくなるようなことがあれば、配当にも影響するかもしれません。

もちろん、現時点で減配が決まったわけではありません。

長く保有したい気持ちはあるのですが、これまであまり考えていなかったリスクに気づいてしまい、少し悩ましいところです。

とりあえず、JTが今回の措置による業績への影響をどう説明するのか、続報を見てから考えようと思います。

参考: - JT:株主還元方針・配当


※2026年11月8日時点の公開情報をもとに、AIも使って調べた内容をまとめました。ニュースや決算資料に基づく事実と、個人的な感想・推測を含みます。投資を推奨する記事ではありません。

picoCTFで出会ったncコマンドをSSHと比較してみた

picoCTF をやっていたら nc コマンドに出会ったので備忘録として。
指定されたサーバーに nc で接続すると文字列が返ってくる、という問題です。
普段使っているssh コマンドと似ているように感じましたが、調べても違いがいまいち理解できなかったので、実際に試しながら整理してみました。

調べる前の認識

  • SSH: リモートサーバーの操作や Github への接続に使う
  • nc: 知らない

SSH とは

SSH(Secure Shell)は、ネットワーク経由で別のコンピューターと安全に通信するためのプロトコルです。
通信の暗号化や接続先サーバーの認証などを行います。
普段、リモートサーバーにログインするときに使っている ssh コマンドは、このSSHプロトコルを利用するクライアントです。
SSHは通常TCP の上で動作し、標準的には22番ポートを使用します。
SSHはリモートサーバーの操作だけでなく、ファイル転送やGitの操作などにも利用されます。

nc とは

nc はnetcatの略で、TCPやUDPを使ってデータを送受信するためのコマンドです。
主な用途には、次のようなものがあります。

  • 指定したホスト・ポートへの接続確認
  • 接続先のプログラムとのデータの送受信
  • 簡易的なサーバーの起動や通信テスト

nc は接続先にデータを送れますが、SSHのような暗号化やユーザー認証を自動的に行うツールではありません。

実際に試してみる

SSH と nc の違いを理解するため、普段SSH で接続しているサーバーに対して、それぞれのコマンドを実行してみました。
※接続先のユーザー名とIPアドレスは、それぞれ、に置き換えています。出力の一部も省略・マスクしています 。
自分のMacでSSHサーバー(リモートログイン)を有効にすれば、をlocalhostにして同様の実験もできます。

1. SSHで接続する

まず、普段使っているSSHコマンドでサーバーに接続してみます。

ssh <USER>@<HOST>

SSH接続できました(接続後の操作ログは省略)。

2. nc で同じサーバーに接続する

はじめにSSHと同じ形式で接続してみました。ポートは22番を指定します。

nc <USER>@<HOST> 22

結果:

nc: getaddrinfo: nodename nor servname provided, or not known

エラーになりました。
nc では、sshのように ユーザー名@ホスト という形式では指定できません。接続先のホストとポート番号を指定する必要があります。
ユーザー名を除いて再実行します。

nc <HOST> 22

結果:

SSH-2.0-OpenSSH_[version]

SSHサーバーから識別文字列が返ってきました!
これはプロトコルのバージョン識別文字列で、SSHのバージョンや実装に関する情報を表します。
SSHでは、通信開始時にクライアントとサーバーがそれぞれ識別文字列を送ります。

ここで適当な文字 a を入力してみます。

a
Invalid SSH identification string.

エラーが返ってきて接続が終了しました。
TCP接続自体は成功していますが、SSHサーバーが期待する識別文字列の形式に従っていないため、通信を続けられなかったようです。

3. SSH の識別文字列を送信する

先ほどは適当な文字列を送ってエラーになりました。 そこで、今度はSSH の識別文字列の形式に従ったデータを送ってみます。

printf 'SSH-2.0-testclient_1.0\r\n' | nc <HOST> 22

結果(一部抜粋・整形):

SSH-2.0-OpenSSH_[version]

[バイナリデータ省略]
curve25519-sha256
curve25519-sha256@libssh.org
ecdh-sha2-nistp256
...
ssh-ed25519
...
aes128-ctr
aes256-ctr
...
hmac-sha2-256
...

おお、先ほどとは違って大量のデータが返ってきました。
調べてみると、これはSSHの鍵交換で使用するアルゴリズムの候補などを通知する SSH_MSG_KEXINIT というメッセージでした。
出力に含まれていた文字列には、それぞれ次のような役割があります。

文字列 用途
curve25519-sha256 鍵交換方式
ssh-ed25519 サーバーの公開鍵アルゴリズム
aes128-ctr 暗号化方式
hmac-sha2-256 メッセージ認証コード方式

ここで疑問なのが、SSHは暗号化するはずなのに、なぜアルゴリズム名が読めるのかということです。
SSHでは、通信の開始時にお互いが利用できる暗号方式などを通知し、鍵交換を行います。
今回見えたのは暗号化が始まる前のやり取りだったため、アルゴリズム名を読み取ることができました。
今回送信したのは識別文字列だけなので、鍵交換や認証は完了していません。

4. 22番ポートへの接続を確認する

今度は、nc の オプションを使って接続の成否だけを確認してみます。

nc -vz <HOST> 22
  • -v: 詳細な情報を表示する
  • -z: アプリケーションデータを送らず、接続可能なポートを確認する

結果:

Connection to <HOST> port 22 [tcp/ssh] succeeded!

22番ポートへのTCP 接続が成功していることを確認できました。ただし、SSHによる認証やログインに成功したわけではありません。 nc を使えば、SSHに限らず、指定したTCPポートに接続できるかを調べられます。

5. picoCTF の通信を再現する

picoCTF では、nc コマンドでサーバーに接続すると文字列が返ってくる問題がありました。
これを自分のMacで再現してみます。
まず、ターミナルを2つ開きます。

ターミナルA: 待ち受け側

printf 'Hello from my server!\n' | nc -l 9000

-l は、接続を待ち受けるオプションです。
今回は9000番ポートで待ち受け、接続してきた相手に文字列を送るようにしました。

ターミナルB: 接続側

nc localhost 9000

結果:

> Hello from my server!

文字列が返ってきました! 接続しただけで文字列が表示されたのは、nc が自動的に返事を作っているからではなく、接続先のプログラムが文字列を送信していたからでした。
nc は、そのデータを受け取ってターミナルに表示しています。

※この実験では通信終了後にコマンドが残る場合があります。その際はCtrl+Cで終了します。待ち受けポートはほかの端末から接続できる場合もあるため、実験後は必ず停止します。

SSHとncの違い

実験を踏まえて、違いを整理します。

観点 sshコマンド ncコマンド
主な目的 安全なリモート通信 汎用的なデータの送受信・通信確認
主に使うプロトコル SSH(通常TCP上で動作) TCPまたはUDP
暗号化 SSHによって提供される 通常のnc接続では行わない
認証 SSHの認証機能を利用する 通常は認証機能を持たない
リモート操作 対応している 接続先次第

最初は「SSHはコマンドを送り、ncはデータを送る」という違いかなと思っていましたが正確ではありませんでした。
SSHもデータを送受信しています。違うのは、その通信にどのような仕組みが用意されているかです。

ここでTCPとSSHの関係も整理しておきます。

  • TCP: 相手との接続を確立し、データが順序どおり、信頼性のあるバイトストリームとして届ける
  • SSH: TCPなどの通信路の上で、暗号化・認証・安全なリモート操作などを実現する

nc でSSHサーバーにTCP接続できても、SSHプロトコルに従った鍵交換や認証などを行わないと、SSHとしてログインすることはできません。

まとめ

  • nc はTCPやUDPでデータを送受信するための汎用的なコマンド
  • ssh はSSHプロトコルに従って、暗号化や認証を伴う通信を行う
  • ncでもSSHサーバーの22番ポートにTCP接続できるが、それだけではSSHログインはできない
  • ncはポートの接続確認や、独自の通信を行うプログラムの動作確認に使える
  • ncで接続したときに何が返ってくるかは、接続先のプログラムによって決まる

今回一番印象に残ったのは、TCPで接続できることと、その上で動くプロトコルに従って通信できることは別だという点です。
普段何気なく使っているSSHにも、TCP接続、識別文字列の交換、鍵交換、認証といった段階があるんですね。
picoCTFをきっかけに、ネットワーク通信の仕組みを少し理解できました。

参考

SSHとは | SSHプロトコル | Cloudflare

ncコマンドでサーバーと通信させよう! | エンベーダー

https://www.rfc-editor.org/rfc/rfc4253.html?utm_source=chatgpt.com#section-4

SSHの公開鍵認証の仕組み(RFC準拠) #ssh公開鍵認証 - Qiita

Chatbot Arena論文

論文リンク

これは何?

  • 人間が実際にどちらのLLMの回答を好むのかを、大規模なペアワイズ比較によって評価する Chatbot Arena を提案した論文
  • Arena に集まったプロンプトでモデル間の能力差を識別できた
  • Arena内で収集されたプロンプトには十分な多様性があり、プラットフォーム上での投票には一定の品質があることを確認できた

なぜこの研究をした?

LLM の性能評価のために、さまざまなベンチマークが提案されてきました。これらは次の表に示すような2つの観点で分類することができます。

  • 質問の供給源
    • 静的(static)かライブ(live)か
  • 評価指標
    • 正解(ground truth)に基づくものか、人間の選好(human preference)に基づくものか

これらの観点をもとに各種ベンチマークを4つのカテゴリーに分類した結果が次の表です。

現在もっとも一般的なLLM評価方法は「静的」「正解に基づく」ものです。評価が低コストかつ再現しやすいことが理由です。
しかし、この種類のベンチマークには以下のような課題があり、人間の選好を評価するという点では不十分です。

  • LLMの利用方法として一般的な、自由回答形式の性能評価においては不十分
  • テストセットが固定化されており、学習データに混入する可能性がある。その結果評価結果の信頼性を損ねる
  • 多くの複雑なタスクでは、明確な正解を定めること自体が難しい

これらの課題を解決するためには、リアルタイムで新鮮かつ多様なユーザーからの質問を収集する必要があります。

何をやった?

この論文ではモデル同士の対戦を行う LLMベンチマークプラットフォーム「Chatbot Arena」を提案しています。
webサイトで質問をすると匿名化された 2つのLLMからそれぞれ回答が返され、ユーザーはより好ましい回答を生成したモデルに投票します。この評価をもとにモデルのランキングを作成するプラットフォームになっています。

Chatbot Arena のスクショ

ユーザーからの質問を随時受け付けることでリアルタイムで質問を収集できます。さらに多くのユーザーに利用してもらうことで、多様なユーザーの評価を集めることが可能です。
2023年4月にデータ収集を開始し、2024年1月時点で 9万人を超えるユーザーから約24万件の投票を収集しました。

何が分かった?

Arena のプロンプトで、モデル間の能力差を識別できることが示されました。
Llama-2-70b-chatとGPT-4の性能を比較し、GPT-4 の勝率は

  • 問題解決能力をあまり必要としないプロンプトでは 60 % 未満
  • コーディングや推論能力を必要とするプロンプトでは最大 97 %

となりました。これは Arena で集めたプロンプトによって各モデルの強みを識別できたということになります。

モデルの評価にあたり、「Arena内で収集されたプロンプトには十分な多様性があるか」「プラットフォーム上での投票には一定の品質があるか」を検証しています。
プロンプトをトピックごとに分類したところ600のクラスタに分かれ、最大のクラスタでも全体の1%にとどまることから、Arena内のプロンプトが多様な分布を持つことを確認しています。
後者に関しては、一般ユーザーと専門家による評価を比較しています。一般ユーザーと専門家の評価の一致率は 72~83% でした。一方、専門家同士でも一致率は 79~90 % 程度で、完全には一致していませんでした。そもそも質問に明確な答えが存在しないものもあったためと考察しています。

一般人、専門家2グループ間の評価の一致率

ただし、Arena の利用者は LLM 好きや研究者に偏っているのでバイアスが発生していることを論文中で認めています。

読んでいて気になったこと

  • そもそも人間の選好ってなんだろう
  • 人間が好む回答と、事実として正しい回答が食い違った場合、Arena では前者を高く評価してしまう可能性があるのでは?