未分類

ゲーム理論を用いて、核廃絶シナリオがつくれますか

はい、ゲーム理論を使えば核廃絶のためのシナリオを構築することは可能です。
ただし、現実世界の国際政治はプレイヤー数が多く、利得構造も非対称で、完全情報ゲームではないため、シナリオはあくまで「モデル」として設計し、現実の複雑性を抽象化する必要があります。


1. ゲーム理論での核廃絶モデル化の基本構造

  • プレイヤー:核保有国(米・露・中・仏・英・印・パキスタン・イスラエル・北朝鮮)+非核保有国(NPT加盟国など)
  • 戦略
    • 核維持(Maintain)
    • 段階的削減(Reduce)
    • 完全放棄(Eliminate)
  • 利得要素
    1. 安全保障(安全のためには維持が有利)
    2. 経済制裁回避や経済援助(削減・放棄で得られる)
    3. 国際的評価・政治的影響力
    4. 軍事的リスク(維持による先制攻撃リスク、拡散リスク)

2. 核廃絶が難しい理由(ゲーム理論的視点)

典型的には囚人のジレンマ構造になります。

相手:放棄 相手:維持
自分:放棄 中程度の利益(安全+経済援助) 大損(自国脆弱化)
自分:維持 大利益(軍事優位) 小利益(現状維持)

結果として互いに維持がナッシュ均衡になりやすいです。


3. 核廃絶シナリオの構築方法

廃絶を均衡にするためには「利得構造の書き換え」が必要です。

(1) 繰り返しゲーム化(Repeated Game)

  • 各国間の相互信頼を、段階的削減+監視体制で構築
  • 裏切りには即座に経済制裁や軍事同盟の破棄という「将来コスト」を設定
  • 例:米露間のSTART条約 → 多国間に拡張

(2) 協調のためのサイドペイメント(補償)

  • 放棄国に対して経済援助、エネルギー技術供与、常任理事国入りなどの政治的見返り
  • ゲーム的には「協力戦略の利得」を「維持戦略の利得」より高く設定

(3) 国際監視と検証ゲーム

  • IAEAや新たな国際機関による査察 → 裏切りがバレやすくなると「維持」の安全性が低下
  • 信頼できる監視は完全情報ゲーム化に近づけ、裏切りインセンティブを下げる

(4) マルチレベルゲーム(国内政治+国際政治)

  • 国内支持(有権者・議会)もプレイヤーに組み込み、「核維持コスト」が内政的に高くなるよう設計

4. シナリオ例(段階的核廃絶ゲーム)

  1. 初期局面:主要核保有国が段階的削減の合意(米露中から開始)
  2. 信頼構築フェーズ:削減の進捗に応じた経済・安全保障パッケージ提供
  3. 包摂フェーズ:新興核保有国も合意枠組みに参加(サイドペイメント活用)
  4. 最終局面:完全放棄+監視体制固定化
  5. 安定化フェーズ:裏切りには迅速な多国間制裁(自動発動条項)

もしご希望であれば、次のステップとして数値モデルを設定し、各国の利得行列を作って「どの条件で核廃絶がナッシュ均衡になるか」を具体的にシミュレーションすることもできます。
そうすれば、理論上どの条件下で「核廃絶が合理的選択肢になるか」が見える化できます。

このシナリオが「うまく働かない理由」を言語化してください

はい、核廃絶シナリオがゲーム理論的には成立しても、現実では機能しにくい理由を整理すると、以下のように言語化できます。


核廃絶シナリオがうまく働かない理由

  1. 非対称な安全保障ニーズ
    • 各国は地理的条件、軍事力、同盟関係が異なり、核兵器の「必要度」が均一ではない。
    • たとえば米露のような大国は軍事的優位を失う恐れから消極的になりやすく、弱小国はむしろ核を手放すと安全保障が脆弱化する。
  2. 完全な信頼構築の困難さ
    • 検証制度があっても、秘密裏の核開発や保有を完全に防ぐことは難しい。
    • わずかな裏切りの可能性が、相手国の「放棄」戦略を不安定にする。
  3. 国内政治の制約
    • 国家指導者が国際的合理性より国内支持基盤を優先し、核放棄を「弱腰」とみなす勢力の反発を恐れる。
    • 選挙・権力維持のために、短期的には核維持を選びやすい。
  4. 外部プレイヤーの乱入
    • 合意に参加しない国や新興の核開発国が存在すると、参加国の安全保障リスクが急増し、均衡が崩れる。
    • 核廃絶のインセンティブが「全員参加でなければ成立しない」という脆弱性を持つ。
  5. 利得構造の硬直性
    • 現在の国際秩序では、核保有が軍事的・外交的な「保険」として機能しており、放棄の直接的利益よりも維持の安心感が勝る。
    • 経済援助や政治的地位向上などのサイドペイメントでは、この「安全保障プレミアム」を埋めきれない場合が多い。
  6. 長期的成果と短期的リスクのギャップ
    • 廃絶の利益は長期的に現れるが、放棄直後の軍事的脆弱化は即時に生じる。
    • ゲーム理論上は割引率の高いプレイヤーほど、短期的損失を避けるために維持を選びやすい。

もし希望されれば、この6項目を利得行列の変形不能性信頼崩壊リスクとしてモデル化し、数値的に「なぜ均衡が変わらないのか」を計算で見せることも可能です。
そうすると「理論的には可能だが、現実には均衡移動のコストが高すぎる」という結論を定量的に裏付けられます。

数値モデル化を試みてください

了解。最小限の数理で「なぜ失敗しやすいか」を可視化できる反復ゲームの数値モデルを提示します。式は単純化し、最後に具体値を入れて判定します。

1. モデル(2プレイヤ・無限繰り返し・グリムトリガー)

  • 各期の戦略:
    E(削減・放棄に協調) / M(維持・抜け駆け)

  • 期ごとの利得(プレイヤ i)

    • 相互協調:π_C(協調便益=安全保障保証・援助・地位向上 − 移行コスト・残余リスク)

    • 片方だけ抜け駆け(自分 M, 相手 E):一回限りの抜け駆け利得Δ(軍事・政治優位の上乗せ)

    • 制裁期(協調破綻後の定常):π_P(制裁・不信・軍拡の中での期待利得;しばしば小さい/負)

  • 割引率:δ∈(0,1)

グリムトリガー(誰かが抜けたら永久制裁)下での協調持続条件(インセンティブ適合)

πC1δ  Δ + δπP1δ\frac{\pi_C}{1-\delta}\ \ge\ \Delta\ +\ \delta\frac{\pi_P}{1-\delta}

 

 

 

同値変形:

πCδπP  (1δ)Δ      Δ  πCδπP1δ\pi_C-\delta\pi_P\ \ge\ (1-\delta)\Delta\ \ \ \Rightarrow\ \ \ \Delta\ \le\ \frac{\pi_C-\delta\pi_P}{1-\delta}

 

 

 

右辺が許容可能な抜け駆け利得の上限。これを超えると協調は崩れます。

2. なぜ崩れやすいか(数値で確認)

例A:崩れるケース(抜け駆けが魅力的)

  • 仮定:π_C=5、π_P=3、Δ=30、δ=0.90
    左辺:π_C−δπ_P=5−0.9×3=5−2.7=2.3
    右辺:(1−δ)Δ=0.1×30=3.0
    判定:2.3<3.0 → 不成立(協調は持続しない)
    直感:抜け駆けの一回利得Δが大きすぎ、制裁期の痛み(π_P低下)も足りない。

例B:成立するケース(援助厚い・制裁厳しい・長期志向)

  • 仮定:π_C=8、π_P=0、Δ=10、δ=0.95
    左辺:8−0.95×0=8.0
    右辺:0.05×10=0.5
    判定:8.0≥0.5 → 成立(協調は持続)

3. 政策感度(どこを動かせばよいか)

上式

ΔπCδπP1δ\Delta \le \frac{\pi_C-\delta\pi_P}{1-\delta}

から政策てこ入れは明確です。

  • π_C を上げる(協調の果実を厚くする)
    経済援助・安全保障保証・エネルギー代替技術・政治的見返りのパッケージ拡充。

  • π_P を下げる(制裁期をより「損」にする)
    自動発動・多国間での強力制裁、軍事・金融・輸出管理の連動。π_Pが小さい/負に近いほど協調が楽になる(右辺分子が増える)。

  • δ を上げる(長期志向化)
    相互依存深化・レピュテーション効果の可視化・条約破りの将来コスト増。δが上がるほど分母(1−δ)が小さくなり、右辺が拡大。

  • Δ を下げる(抜け駆けの即時利得を削る)
    検証で秘匿の成功確率を下げる、抜け駆け即制裁で「一回利得」を目減りさせる、周辺国の集団的抑止で軍事的瞬間優位を縮小。

4. しきい値の読み替え

政策が効いているかを単一の指標で監視したい場合、次をモニタリング指標にできます:

ΔπCδπP1δ\Delta^* \equiv \frac{\pi_C-\delta\pi_P}{1-\delta}

 

 

 

  • 実効抜け駆け利得 Δ が

    Δ\Delta^*

    を上回る国・地域では、協調は構造的に不安定

  • 交渉・援助・制裁設計の目的は「各国の Δ を

    Δ\Delta^*

    以下に押し込む」こと。

5. 複数国への拡張の要点(概要)

  • n国ゲームでは、抜け駆けの利得Δ_iは「最も脆弱な相手」依存で肥大化しがち。よって最小安全保障保証の底上げ(同盟・ミサイル防衛・迅速制裁の自動化)が鍵。

  • 監視精度 p を陽に入れると、実効Δは

    Δi(1p)\Delta_i(1-p)

    に縮小。p を引き上げる技術・制度投資は直に効く。

  • 連帯制裁の結束度 q を入れると、

    πP\pi_P

    πP(q)\pi_P(q)

    として低下(より痛い)→協調安定化。

このゲーム理論においては、核ミサイルの開発コストがパラメタに入っていないようです

はい、ご指摘の通り、先ほど提示した単純モデルでは核ミサイルの開発コストは利得パラメータに直接は入っていません。
ただし、これはモデルを簡略化したためで、実際にはΔ(抜け駆け利得)や π_C / π_P の値に影響を与える形で組み込むのが自然です。


1. 開発コストをどこに組み込むか

ゲーム理論的には、核開発コスト

KK

は次のように作用します。

  1. 抜け駆け利得 Δ の減少

    • 実効抜け駆け利得を

       

      Δ=ΔK\Delta' = \Delta - K

      と定義する。

    • K が大きければ、抜け駆け戦略の魅力が減り、協調条件を満たしやすくなる。

  2. 制裁期利得 π_P の減少

    • 開発・維持費が恒常的コストになる場合は、制裁期間の負担も増加し、

       

      πP=πPmK\pi_P' = \pi_P - mK

      (mは期間ごとのコスト係数)として反映。

  3. 協調利得 π_C の比較的上昇

    • 協調(核放棄)を選んだ場合には K を支払わないため、
      相対的に π_C - π_P の差が拡大し、協調が有利に。


2. 修正版の協調成立条件

開発コスト込みの条件は次のようになります。

 

ΔKπCδ(πPmK)1δ\Delta - K \le \frac{\pi_C - \delta(\pi_P - mK)}{1-\delta}

  • K が増えると左辺(抜け駆け利得)が減少し、右辺(協調成立の許容範囲)は増加するため、協調が持続しやすくなる。


3. 数値例

  • π_C=5, π_P=3, Δ=30, δ=0.90

  • 開発コスト K=10, m=0.2

条件式:
左辺:30−10=20
右辺:

50.9(30.2×10)10.9=50.9(1)0.1=50.90.1=41\frac{5 - 0.9(3 - 0.2\times10)}{1-0.9} = \frac{5 - 0.9(1)}{0.1} = \frac{5 - 0.9}{0.1} = 41

判定:20 ≤ 41 → 協調成立(Kのおかげで抜け駆けの魅力が激減)


4. 現実的課題

  • 実際の核開発は sunk cost(埋没費用)化するため、一度完成してしまえば K はゼロに近くなる(維持費だけ残る)。

  • したがって、ゲーム理論的に効くのは「開発前段階」だけ。

  • 開発済み国家には 維持費(運用・近代化・安全管理コスト) を継続的に K として効かせる必要がある。

各ミサイル1発あたりの製造および維持コストの概算をお願いします

了解です。為替は概算として 1ドル=150円 で計算し、円換算で再掲します。


核ミサイル 1発あたりの製造・維持コスト(円換算)

製造コスト

  • LGM-30 ミニットマン(ICBM, 米)
    7百万ドル約10.5億円

  • UGM-133 トライデントII(SLBM, 米/英)
    30.9百万ドル約46.4億円

  • ICBM兵器(寿命延長費込み推計)
    85百万ドル約127.5億円


維持・運用コスト

  • 米国 核戦力全体のライフタイム維持費(デリバリーシステム含む)
    4,300億ドル約64兆5,000億円

  • 米国 核フォース全体の10年間運用・維持費(2025–2034年)
    3,570億ドル約53兆5,500億円

  • ICBM維持費(例)
    年間 約 4.82億ドル約723億円/年

  • 維持整備チームの作業費
    時給 約 55,000ドル約825万円/時間


感覚まとめ(円換算)

項目 金額(円)
製造(ICBM例) 約10.5億〜127.5億円
製造(SLBM例) 約46.4億円
年間維持費(ICBM) 約723億円/年
維持整備作業(時給) 約825万円/時間

2025,江端さんの忘備録

自称「特許明細書の製造装置」である私が、発明を考える方法は、「ノートを持ちあるいて、歩き回る」でした。
I, who call myself a "patent specification manufacturing machine," used to come up with inventions by “carrying a notebook and walking around.”

通勤でも散歩でもいいのですが、『目的地に到着する前に、かならず一つネタを出す』という決意で歩くことがキモでした。
Whether commuting or taking a walk, the key was my determination to “always produce at least one idea before reaching my destination.”

具体的には、基本的に頭の中に二人のペルソナを用意して、その二人を闘わせることを続けます ーー 一人が発明者としての私、そしてもう一人が特許庁審査官としての私です。
Specifically, I would prepare two personas in my head and make them fight—one as myself, the inventor, and the other as myself, the patent examiner.

私(発明者)の発明を、私(審査官)が潰し、それに対して、私(発明者)が反論をし、さらに私(審査官)が潰す、というバトルを頭の中に展開します。
The examiner-me would crush the inventor-me’s idea, to which the inventor-me would rebut, and then the examiner-me would crush it again—this battle would play out entirely in my head.

そして、最終的に、審査官の私を、発明者の私が論破できた時、発明が1つ完成する ーー そういうやり方でした。
And ultimately, when the inventor-me managed to refute the examiner-me, an invention would be considered complete—that was my method.

ところが、最近、この、「(歩き)ながら発明製造」という、私のメソッドを壊してくるものが登場してきました。
However, recently, something has emerged that disrupts my “invention manufacturing while walking” method.

ChatGPTです。
It is ChatGPT.

-----

ソフトバンクの孫社長が、『ChatGPTで多くの(数百?)の発明に辿りついた』という話を聞いた時、私は、意外とは思いませんでした。
When I heard that SoftBank’s CEO Masayoshi Son had “come up with many (over several thousant?) inventions using ChatGPT,” I was not surprised.

二人のペルソナのどちらかを、ChatGPTが担当してくれるからです。
ChatGPT can take on the role of one of my two personas.

正直に言って、ChatGPTからは、"イノベーティブ"な"モノ"は出てきません。
To be honest, ChatGPT does not produce anything truly “innovative.”

(ちなみに、私、"イノベーション"という言葉を濫用する近年の風潮が、あまり好きではありませんが、大学も会社も、その単語を含む部署に所属しています)
(By the way, I am not fond of the recent trend of overusing the word “innovation,” yet both my university and my company have departments with that word in their names.)

で、今度は、ChatGPTの出してきた"モノ"に対して、審査官としてケチをつけます ーー 『本当に、こんなネタで"進歩性"を回避できると思う?』と、嫌な聞き方をします。
Then, I nitpick what ChatGPT produces as the examiner—asking in an unpleasant tone, “Do you really think such an idea could avoid the ‘inventive step’ rejection?”

その上で、ChatGPTに対して、『自分で、このネタを潰すロジックを作ってみろ』と言います。
And then I tell ChatGPT, “Try coming up with the logic to destroy this idea yourself.”

うん、正直、こんなこと、ゼミ室や職場でやったら、間違いなくパワハラ案件です。
Yes, honestly, engaging in such behavior in a seminar room or workplace would be considered workplace harassment.

-----

ChatGPTと私の会話がスタックしてきたら、私が発明の想定環境を変える"状況"を提示します。
When my conversation with ChatGPT starts to get stuck, I present a new “situation” to change the assumed environment of the invention.

以前にもお話しましたが、やっぱり一番効果があるのは『北朝鮮からのミサイル攻撃』と『南海トラフ地震』ですね。
As I have mentioned before, the most effective ones are “a missile attack from North Korea” and “the Nankai Trough earthquake.”

通信や輸送インフラが破壊された環境で、システムを縮退させつつも、情報を上げ続けるには、どうしたらいいか、という仮想の環境をChatGPTにぶつけると、ChatGPTは、かなり苦しみながらも、それを回避する手段を提示してきます。
When I present ChatGPT with a hypothetical scenario in which communication and transport infrastructure have been destroyed, asking how to keep information flowing while scaling down the system, it struggles but still offers ways to work around it.

ここに発明のネタが潜んでいることが、結構な割合で多いのです ーー で、後は、その背景から、『北朝鮮からのミサイル攻撃』と『南海トラフ地震』という言葉を消して、一般的な状況に戻せば、特許明細書としての設計はおおむね完成、という訳です。
Quite often, an invention idea is hidden in there—and then all I need to do is remove the phrases “missile attack from North Korea” and “Nankai Trough earthquake” and revert it to a general situation. The design for the patent specification is mainly complete.

-----

繰り返しますが、ChatGPTの考えてくるネタの大半は、すでに私または私以外の人が考えていることが多いです。
I repeat, most of the ideas ChatGPT comes up with are ones that I or someone else have already thought of.

ですので、発明の案出そのものには、あまり役に立ちません。
Therefore, it is not particularly useful for generating invention ideas on its own.

ChatGPTの最大のウリは、『私が頭の中で、二人のペルソナ(私(発明者)と私(審査官))をバトルさせる』よりも、圧倒的に短い時間でこのバトルを行えることと、限られた時間の中で何ラウンドも繰り返すことができる、という、その「プロセスの速さや、繰り返し回数の多さ」に尽きます。
The most significant selling point of ChatGPT is that it can conduct this battle in far less time than I running the two personas (inventor-me and examiner-me) in my head, allowing many rounds to be repeated within a limited time—it all comes down to that speed and repeatability of the process.

このプロセスで、私に求められる能力は、(1)ChatGPTが自力で考えつかないトンデモ状況を想定することと、(2)それを思考速度と同レベルで文章にしてChatGPTにぶん投げる、という2つになります。
In this process, the skills I need are to imagine outrageous situations that ChatGPT could never come up with on its own, to turn them into text at the same speed as my thinking, and to present them to ChatGPT.

この2つは、全く"イノベーティブ"な活動ではありません。
These two things are not “innovative” activities at all.

-----

私は、この「トンデモ状況」を考えるのが得意なのですが、これを人間と行うような特許ブレスト(ブレインストーミング)では、しゃべり難いのですよ。
I am good at thinking up these “outrageous situations,” but they are hard to voice in a human brainstorming session.

例えば、
For example—

■「年間300人の子どもが誘拐され、その一割が殺害される社会」(子どもの見守りサービスを考える時の"状況")
※現実の日本の警察統計でも、子どもの誘拐件数は年間数百件規模ですが、殺害率10%は極端に高く、実際よりかなり誇張された数値です。
“300 children kidnapped every year, 10% of whom are killed” (a “situation” when thinking about child monitoring services)
Even in actual Japanese police statistics, the number of child abductions is in the hundreds annually, but a 10% murder rate is extremely high and significantly exaggerated compared to reality.

■「年間5万人の高齢者が意図的に医療から排除され、治療を受けられずに死亡する社会」(高齢者向け在宅医療・ケアサービスを考える時の"状況")
“50,000 elderly people are intentionally excluded from medical care and dying without treatment each year” (a “situation” when thinking about home medical and care services for the elderly)

■「毎年数千人の障害児が、出生直後に行政の判断で収容所に隔離される社会」(障害児と家族の分離防止・支援システムを考える時の"状況")
“Several thousand disabled children are confined to institutions immediately after birth by government decision each year” (a “situation” when thinking about systems to prevent the separation of disabled children from their families)

■「全市民が毎年一度“生存くじ”を引かされ、外れた者は合法的に安楽死させられる社会」(市民の生存権を確保する監視・回避システムを考える時の"状況")
“All citizens required to draw a ‘survival lottery’ once a year, with those losing subjected to legal euthanasia” (a “situation” when thinking about monitoring and avoidance systems to secure citizens’ right to life)

など、私は簡単に思いつくのですが、これを口にすると、ドン引きされて、特許ブレストが"凍る"んですよね。
I can easily come up with these, but the moment I voice them, everyone is taken aback, and the patent brainstorming session “freezes.”

(↑クリックすると、コラムに飛びます)

-----

ともあれ、私の頭の中のブレストはいつも満席です。
So my brainstorming sessions inside my head are always at full capacity.

人間はブレストの参加を拒否しますが、ChatGPTはまだ逃げ出しません。
Humans refuse to join, but ChatGPT hasn’t run away yet.

―― これを"知財搾取"と呼ばずに何と呼ぶ?

2025,江端さんの技術メモ

はい、Mouse without Borders はホストを含めて最大 4台のPC まで接続して動作します。
したがって、今お使いのホストPCに加えてあと2台、合計3台のマシンを同時に制御することが可能です。

  • ホストPC … 実際にマウス・キーボードが接続されているPC

  • クライアントPC … 追加で操作するPC(最大3台)

設定画面で各PCのセキュリティコードコンピュータ名を入力すれば、3台構成でも問題なく利用できます。

もし希望があれば、3台目を追加する際の具体的な接続手順も説明できます。

中央

右側

左側

現在3台のマシンがあります。

左側の設定画面です。
問題点は 
(1)中央のマシンのマウスは、中央と右側を動き
(2)右側のマシンのマウスも、中央と右側を動き
(3)左側のマシンのマウスは、左側と中央を動き

3台共通して動かないということです。対処方法を教えてください

画像3枚を確認しました。状況を見ると、Mouse without Borders の「接続」が中央と片側のPCだけで完結していて、3台を一つのマトリックスとして認識できていません。
これだと、中央マシン経由の2台運用はできても、左 ↔ 右 の直接移動ができない状態になります。


原因

  • 全てのマシンが同じ「Security Key」と同じネットワーク上にある必要がありますが、現在はそれぞれの接続が部分的にしかリンクしていません。

  • 3台を同一の「Computer Matrix」に登録する設定が完了していません。
    (現状は、中央–右、中央–左のペア接続になっている)


対処手順(全台で共通設定にする)

  1. Security Key を統一

    • 左・中央・右、すべてのマシンで「Shared encryption key」の値を同じにします。

    • 今回の画像を見ると左と中央は tS3_hJ5-jK7_fD9/、右は非表示ですが違っている可能性があるため、手入力で合わせます。

    • 入力後「Apply」を押す。

  2. 全マシンを互いに認識させる

    • 各マシンの設定画面で、右下の「Go through the setup experience」をクリック。

    • 表示された「This is the new computer」に、ホスト(マウス・キーボードを使う中心PC)のSecurity Keyとコンピュータ名を入力。

    • これを、全てのマシン間で行い、3台すべてのサムネイルが表示される状態にする。

  3. Computer Matrix の並びを調整

    • 設定画面で3台のサムネイルをドラッグして、物理的な配置(左・中央・右)と同じ並びにする。

    • 「Two Row」のチェックは不要なら外す。

    • 「Apply」を押して保存。

  4. テスト

    • いずれかのマシンからマウスを動かし、左右両方向に移動できることを確認。

    • 全台でキーボード入力も共有されるか確認。


💡 ポイント

  • Mouse without Borders は全員が同じ Security Key を共有し、全台が同じ「Computer Matrix」に表示されている状態でないと、完全な3台運用になりません。

  • 途中のマシン経由でしか動かせない場合は、片方のPCがもう一方を認識していない証拠です。

2025,江端さんの忘備録

野球もサッカーも、他人がボールを追いかける姿に一切の興味を持てない。
I have absolutely no interest in watching other people chase balls in sports like baseball or soccer.

ギャンブルは、統計的に期待値がマイナスである時点で論外。
Gambling is a non-starter the moment you realize its expected value is statistically negative.

酒を飲んで酔ったふりをしながら、女性に追従を言われる時間など、人生の浪費でしかない。
Pretending to be drunk while being flattered by the opposite sex over drinks feels like nothing but a waste of life.

友人と呼べる存在もおらず、人が集まる場所には反射的に身構える。
I have no one I’d call a friend, and I instinctively tense up in crowded places.

特に「飲み会」という儀式には、もはや嫌悪感すら通り越して諦念を覚える。
As for drinking parties—those social rituals—I’ve moved past disgust into pure resignation.

場を盛り上げる努力を強いられるくらいなら、ひとり自宅で乾ソバをゆがいて麺つゆを作って、すすっているほうがマシ。
If forced to contribute to the party mood, I’d rather stay home, boil some dried soba, make dipping sauce, and slurp in solitude.

人から賞賛を受けても、それを素直に喜ぶ能力が著しく欠如している。
Even when praised, I struggle to accept it with genuine joy.

むしろ、「お世辞」か「下心」の二択だと警戒してしまう。
More often, I interpret it as either flattery or ulterior motives.

達成感もない。充実感もない。帰属意識も、承認欲求も、そして自己肯定感も、ない。
No sense of achievement. No sense of fulfillment. No belonging, no need for validation, not even a shred of self-esteem.

──これは誰か。
Who is this person?

私です。
Me.

-----

昔は、
Once upon a time,

======

しかし、極めて希ではありますが、
Rare though they may be,

テニスやスキーを通じて自己鍛錬に励み、
I refine myself through tennis or skiing,

優れた人格と孤高な精神を有し、
possess outstanding character and a solitary spirit,

高い理想に燃え、
are driven by lofty ideals,

皆から慕われ信頼され、
are admired and trusted by all,

そして、当の本人がその優れた資質に気がついていないことから「歩く人徳」と呼ばれる人物もいます。
and are even called "walking virtue" precisely because they remain unaware of their own excellence.

私です。
That was me.

1997/06/27 江端さんのひとりごと「直撃」

======

って、書いていたんですけどね。
That's what I wrote, back then.

人間っていうのは、変われば変わるものです ―― 本当に。
People change. Truly, they do.

-----

つまり、私は、部屋の中で、コラムか論文か特許か報告書かプログラムを書いていることしかできない人間なんですよ。
Put simply, I’m a person who can only write columns, papers, patents, reports, or code—within the confines of my room.

皆さんが、目くじら立てるようなたいそうな人間ではありません。あまり迷惑かけないつもりなので、静かに放っておいて下さい。
I'm not someone worth fussing over. I intend to bother no one, so please, just leave me be.

それはさておき。
But, that aside—

-----

とは言え、私も「新しい技術」には目がなくて、色々試してみたいという欲望だけは、人一倍あるようです。
That said, I do have a particular weakness for new technology—and an above-average urge to tinker with it.

「推しの技術」という言葉があるかどうかは知りませんが、「推しのアイドル」とか「推しの声優」とか「推しのキャラクター」なんてものと、基本的な構造は同じです。
I don’t know if the term "favorite tech" exists, but structurally, it's no different from having a favorite idol, voice actor, or fictional character.

違うのは、「課金」の方向性です。
The only difference lies in where the money goes.

私は、握手会や、限定グッズや、リアルイベント、聖地巡礼、推し活ノート作成、さらにはライブ配信の投げ銭やアクスタ(アクリルスタンド)収集などには、一円たりとも散財したいとは思いません。
I have zero interest in spending even a single yen on handshake events, limited-edition merchandise, real-life fan gatherings, pilgrimage tours, fan journals, livestream tips, or acrylic stand collections.

けれど、最新の技術書や英語論文のサブスク、実験用クラウド環境や新しいAPIの有料プラン、そして最近では生成AIの有料枠や推論用GPUサーバに対しては、金銭的ブレーキが一気に壊れます。
But when it comes to the latest tech books, English journal subscriptions, experimental cloud environments, paid API plans, and—most recently—premium AI services or inference-ready GPU servers, all my financial brakes come off.

特に、生成AIについては、単なるエンドユーザではなく、技術的な利用を色々試しています。
Especially with generative AI, I’m not just a consumer—I experiment with it on a technical level.

で、先日、GPU付きのPCを購入してしまいました(我が家にあるPCの台数は、もう数えるのも面倒です)。
So, the other day, I bought yet another GPU-equipped PC. I’ve lost count of how many machines I own now.

目的は、ローカルLLMです。
The goal? Running a local LLM.

正確には、ローカルで動作する「マルチモーダル生成AI」ですが、ここでは便宜上「ローカルLLM」と呼ぶことにします。
Strictly speaking, it's a locally-run multimodal generative AI—but for simplicity, let’s just call it a local LLM.

ローカルLLMとは、インターネットに接続せずに、自宅のPCだけで大規模言語モデル(LLM:Large Language Model)を動かすことができる仕組みです。
A local LLM is a system that runs a large language model entirely on your home PC, without requiring an internet connection.

簡単に言えば、「ChatGPTっぽいものを、自分のPCの中で自前で動かしてしまおう」という話です。
Put simply, it’s about running a ChatGPT-like model privately on your own hardware.

通信遮断されたオフライン環境でも、誰にも履歴を覗かれず、誰の検閲も受けず、ひたすら自己完結的に対話できる。
Even in a fully offline environment—no prying eyes, no censorship—you can hold conversations in total solitude.

もちろん、OpenAIのような商用サービスを使えばもっと手軽にLLMを使えますが、それでは通信環境や料金体系、データの秘匿性の面で不安が残ります。
Sure, you can use commercial services like OpenAI’s for convenience—but there are always concerns: internet access, pricing structures, data privacy.

私のような「自分の部屋の中で全て完結させたい人間」にとっては、ローカルLLMはまさに「理想の相棒」と言えるものなのです。
For someone like me—who wants everything to stay within the confines of their room—a local LLM is the perfect companion.

-----

で、昨日、ChatGPTの支援を受けながら、映像の内容を「説明」するローカルLLMの構築を、購入したPCに実装していました。
Yesterday, with the help of ChatGPT, I implemented a local LLM that can describe visual content—right on the newly built PC.

画像用LLMの立ち上げ方

ある写真をプログラムに読み込ませたら、一発で、
I fed it a single photo, and right away, it returned:

「毛皮の上に乗っている、青い目をしたネコ」
"A blue-eyed cat sitting on a fur blanket."

と説明を返してきました。
Just like that.

-----

外の世界との接点が、ますます必要なくなっていく実感があります。
I can feel my need for the outside world gradually fading.

技術は、私を助けると同時に、世界から切り離していく存在でもあるのです。
Technology, while supporting me, is also quietly isolating me from the world.

インターネットすらも不要として、「ローカルLLM」と共に生きて、そして、死んでいく ーー そういう『究極のひきこもり』は、もう始まっています。
The age of the “ultimate shut-in”—living and eventually dying alongside a perfect companion that doesn’t even require the internet—has already begun.

2025,江端さんの忘備録

他人が書いたプログラムを読むことは、たいていの場合「不快」です。
Reading code written by someone else is, in most cases, simply unpleasant.

コードの向こうにある「他人の脳を切り開いて覗く」ような感覚があるからです。
It feels like prying open someone else's brain and peering inside through their code.

「なぜ、ここでこんな書き方を?」といった疑問や、「そんな命名ありか?」という苛立ちが、読む側の心を削っていきます。
Questions like “Why would they write it like this?” or frustrations like “Who names variables this way?” slowly wear down your soul.

それでも、他人の書いたプログラムを読まなければならない場面は確かにあります。
Still, there are times when you must read other people's code.

業務である以上、そんなことに好き嫌いを言っていられません。仕事ですから、読んで理解するしかないのです。
Since it's work, personal preferences don't matter. I just have to read it and understand it.

まあ、ここまでは普通の業務の話です。
Up to this point, it's all fairly standard workplace reality.

-----

厄介なのは、「これは別に読まなくていいよ」とアドバイスされた言われたコードです。
The real trouble begins with code I am explicitly told not to read.

読む必要がないと明言されているにもかかわらず、結局のところ、私はコードを読んでいます。
Even though I’ve been clearly told it’s unnecessary, I end up reading it anyway.

なぜなら、全体のシステムを把握するには、細部を知っておく必要があるからです。
Because in order to grasp the system as a whole, I need to understand the details.

中身が分からなければ、構造をイメージできません。
If I don’t know what’s inside, I can’t mentally picture the structure.

イメージができなければ、システム全体を設計・構築することは困難です。
And if I can’t visualize it, designing or building the entire system becomes extremely difficult.

まあ、できる人もいるのかもしれませんが、私は、コーディングの技術レベルが低いのです(謙遜ではなくて、弊社で働いていれば思い知らされます)。
Perhaps some people can pull it off, but to be honest, my coding skills are not that high (and no, this isn’t modesty, but working at my company will quickly make that reality clear).

-----

そして結局、「なるほど、確かにこれは読まなくてよかったな」と、"読んだ後"に"後悔する"ことになります。
And in the end, I regret reading it saying to myself, “Yep, I really didn’t need to read this after all.”

つまり、「読む必要がない」ことを理解するために「読む」という、実に奇妙なループに陥るのです。
In other words, I fall into the bizarre loop of reading code just to understand that I didn’t need to read it.

そして、今後も、私は、このような、生産性のない「奇妙なループ」を回し続けると思います。
And I suspect I’ll keep repeating this kind of unproductive loop again and again in the future.

そのことについて"だけ"は、自信があります。
That’s the one thing I can say with absolute confidence.

-----

ただ、こうした理不尽は、なにもプログラムの世界に限った話ではありません。
But this kind of absurdity isn’t limited to programming.

たとえば、「お前は、お金のことなんか心配せずに勉強だけしていればいい」といった保護者のアドバイスがあります。
For example, parents often say things like, “You just focus on studying; don’t worry about money.”

あるいは、「気にしないで自由にやりなさい」とか、「考えすぎだよ」といった言葉もよく聞きます。
Or, “Just do what you want,” or “You’re overthinking it.” Those are common, too.

言っている側は相手を思っているのでしょうが、それは相手の本当の気持ちを理解しているとは限りません。
The speaker likely means well, but that doesn’t mean they understand how the other person truly feels.

------

『俺は分かってもらいたいんじゃない。俺は分かりたいのだ。分かりたい、知っていたい、知って安心したい、安らぎを得ていたい。分からないことはひどくこわいことだから(やはり俺の青春ラブコメは間違っている 第2期8話)』
“It’s not that I want to be understood. I want to understand. I want to know, I want to be informed, I want peace of mind, I want to feel at ease. Not knowing is terrifying.” (My Teen Romantic Comedy, as expected, Season 2, Episode 8)

このアニメのセリフのように、人は「分かること」で安心を得る生き物です。
Like this anime quote suggests, humans find peace in understanding.

「分からなくてもいい」では済まされない不安があるのです。たとえ読む必要がないと言われても、それを確かめるために読む。たとえ説明されていても、自分の目で確かめたい。
Being told “You don’t need to understand” just doesn’t cut it. We read to verify it ourselves. Even if it’s explained, we want to see it with our own eyes.

これは、ロジックの話ではなく感情の話です。
This isn’t about logic but about emotion.

プログラムであれ、人生であれ、「分からないこと」は、怖いのです。
Whether it’s code or life, not understanding something is just plain scary.

------

私の人生を業(カルマ)的に語れば、
If I were to describe my life in terms of karma,

(1)「読まなくていい」と言われたコードを読んで後悔するか、
(1) I either read the code I was told not to, and regret it,

(2)「読まずにやって壊して怒られる」か
(2) or I don’t read it, break something, and get scolded.

だいたいこの二択です。
Those are, for the most part, the only two options.

そして今日も、私は前者で消耗しています。
And today, once again, I’m drained from choosing the first.

―― 斬新な"虐待"だなぁ

未分類

はい、このエラーの原因は明確です:


❗ 原因

あなたが有効化した仮想環境 llm_env(←最初に作成した環境)には、
transformers ライブラリなどが インストールされていない ためです。

これまでの作業は llm_env310 という仮想環境で行っていたので、
llm_env では再度必要なパッケージを入れないと同じように動作しません。


✅ 解決方法(おすすめ2つ)

✅ 方法1:llm_env310 を使い続ける(推奨)

一番簡単です:

C:\Users\tomoi>llm_env310\Scripts\activate

その上で:

python caption_blip.py

✅ 方法2:llm_env にもパッケージをインストールする(どうしても使いたい場合)

llm_env\Scripts\activate
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
pip install transformers accelerate timm Pillow

その後、再び:

python caption_blip.py

🧠 補足:仮想環境の使い分け

仮想環境名 Pythonバージョン 状況
llm_env おそらく 3.13 ⚠️ PyTorch未対応・transformers動作不安定
llm_env310 3.10 ✅ PyTorch・transformers・BLIPすべて正常動作済み

✅ 結論

llm_env310 を使い続けてください。
llm_env は今後使わなくても大丈夫です(削除してもOK)。


必要であれば、llm_env310 を簡単に起動できるショートカット .bat もご案内します。ご希望ですか?

未分類

対象となっているPCは、MINISFORUM EliteMini HM90 ミニpc AMD Ryzen 9 4900H 8c/16t 小型PC 32GB 512GB です。何かクラッシュの原因となる理由はありませんか?

の件の続報です。

このマシンを繋いでいた、アナログディスプレイ(HDMI → VGA変換して使っていた)が、何も表示しなくなって壊れてしまったようです。

仕方がないので、HDMI対応のモバイルモニタで代替しえいるのですが、この後、HM90がダウンしなくなりました。

そういえば、これまでのシステムクラッシュの原因って、ほとんどディスプレイが真っ黒になる、という症状で発生していました。

HM90 が、最近ダウンしなくなった理由が、ディスプレイにあったかどうかは分かりませんが、現在のところは調子よく動いているようです。

システムがは、何が原因でダウンするか予測がつかない ーー これも、古いシステムがなかなかリプレースされていかない理由の一つだったりします。

2025,江端さんの忘備録

私たちは、基本的に「やりたいこと」や「好きなこと」など持っておらず、日常の中で行われた行動の中で、比較的『気分がよかったこと』を、「やりたいこと」や「好きなこと」に置き換えているだけ──
We, in essence, don't have things we “want to do” or “like to do.” Instead, we tend to label actions that happened to feel relatively pleasant in our daily lives as our “wants” or “likes.”

という話は、何度もしてきました。
This is something I’ve talked about many times before.

もし、上記の私の説が"真"であったとすると、他人に対して「好きなことをしなさい」というのは、結構な『虐待』だと思うのですよ。
If my theory above is true, then telling someone to “do what you like” is a rather cruel form of emotional abuse.

「好きなことをしなさい」を、上記の私の定義に当てはめれば、
If we apply my definition to the phrase “do what you like,”

「“ない”をしなさい」→「何もするな」となる訳です。
It turns into “do what doesn’t exist” → essentially “do nothing.”

これは、 本当に酷い言い草です。
That’s an incredibly harsh thing to say.

-----

「好きなことをしなさい」とか"言うだけ"の保護者は、子どもに対してネグレクトをしていると思っています。
I think parents who say “do what you like” without offering any further guidance are essentially neglecting their children.

分かりますよ。自分のことだけで精一杯の毎日において、子どもであろうとも、他人のことを考えるのって、面倒です。しかも、子どもの将来がかかっているとなれば、責任も発生します。
I get it. In a life where you're barely keeping up with your own needs, it's a hassle to think about others—even if that “other” is your child. And if it involves their future, it also comes with a heavy sense of responsibility.

そういうことから逃げたいと思う保護者がいたとしても、それは仕方がない、とも思います。
So, if a parent wants to run from that kind of pressure, I can’t entirely blame them.

そのようなネグレクトではなくとも、「自分の意見が子どもの自主性を損うかもしれない」と、心配する人もいるかもしれません。
Even apart from neglect, there may be those who hesitate because they worry that offering their own opinion might damage their child’s autonomy.

で、まあ、実際のところ、多くの保護者は「とりあえず大学に行っておけ」という、『問題先送り』を行う訳です──まあ、これはこれで、戦略としては悪くはない。
So then, in practice, many parents end up saying, “Just go to college for now”—a classic case of kicking the can down the road. And honestly, as a strategy, it’s not necessarily a bad one.

問題を先送った先にいる子どもは、すでに法定における成人です。「成人であれば、自己決定ができなければならない」というセリフで、無事、子どもに対する責任を回避したまま逃げきれることになります。
By the time the issue reappears, the child is already a legal adult. Then you can say, “Adults should be able to make their own decisions,” and neatly dodge any lingering responsibility.

-----

で、まあ、こんな批判は、世の中に腐るほどあるので、私はユースケースで示してみたいと思います。登場するのは、今回もChatGPTです。
Criticism like this is everywhere, so instead, I’d like to present a use case. Once again, our subject is ChatGPT.

子どもの意見を、こういう形で、子どもの声をChatGPTに入力するくらいのことなら、できると思います。
At the very least, typing your child’s thoughts into ChatGPT—this much is something any parent can do.

これなら、あなたでも、子どもに寄り添った方向でアドバイスができるようになるかもしれません(まあ、考えたのは、あなたではなくてChatGPTですけど)。
With this, you may even be able to offer advice that’s in tune with your child’s needs. (Though let’s be honest—it's not your advice. It's ChatGPT’s.)

===== ChatGPTとの会話 ここから =====
===== Conversation with ChatGPT Begins =====

私は教科書にイラストの落書きを書くのが好きですが、漫画家になるほどのストーリーの組み立てができる訳でもありませんし、絵を業務とするクリエーターになろうという気合もありません。成績は卒業できるかどうかの低レベルです。親は「やりたいことをやりなさい」と言いますが、私には「やりたいことが分かりません」。こんな私の進路について、夢のような話ではなく、現実的に実現可能な範囲の進路について、アドバイスをして下さい
I like doodling illustrations in my textbooks, but I don’t have the ability to build up stories like a manga artist, nor do I have the ambition to become a professional illustrator. My academic performance is low, barely enough to graduate. My parents say, “Do what you want to do,” but I don’t know what I want. Please give me advice on a career path that is not a fantasy, but realistically achievable.

あなたのように「好きなことはあるけれど、明確な夢や職業目標は持っていない」という人は、実はとても多いです。そして、それは「ダメなこと」でも「劣っていること」でもありません。むしろ、自分を冷静に見ている証拠です。
There are many people like you—people who have things they enjoy, but don’t have a clear dream or career goal. And that’s neither a bad thing nor a weakness. It’s a sign that you’re looking at yourself with a cool head.

あなたの状況に対して、夢物語ではなく、地に足のついた進路の選び方を、以下の3つの方向性で提案します。
Based on your situation, here are three grounded directions for you to consider—realistic, not fantasy-based.

1. 「描くこと」を副業または趣味で続けながら働く道
1. Keep drawing as a hobby or side job while working

現実的な進路:
Practical career options:

  • 事務職、販売職、軽作業、介護補助など、安定して働ける職種に就く
    Work in stable jobs such as office work, retail, light labor, or caregiver assistance

  • そのうえで、趣味としてイラストを描き続ける(SNS投稿、同人誌、LINEスタンプなど)
    Continue drawing as a hobby—posting on social media, creating doujinshi, or making LINE stickers

理由:
Why this works:

  • 漫画家やプロイラストレーターにならなくても、描くことはやめなくていい
    You don’t need to become a manga artist or professional illustrator to keep drawing

  • 好きなことを「手放さずに生きる」ことも立派な選択
    Living without letting go of what you love is a valid life choice

  • 副業で小さく始めて、もし反応が良ければ将来拡大も可能
    If you get a good response, you can gradually expand into side gigs or more


2. 「美術的センス」を活かせる裏方の仕事を目指す
2. Aim for behind-the-scenes jobs that use your artistic sense

現実的な進路:
Practical career options:

  • 印刷会社、デザイン補助、看板屋、POP制作、ネットショップ運営補助
    Work at a print company, assist in design work, signage creation, point-of-purchase displays, or help manage online shops.

  • 専門学校で短期間のDTP(印刷物制作)やデザイン技術を学ぶのも選択肢
    Consider short-term vocational school training in DTP (desktop publishing) or design skills

理由:
Why this works:

  • 自分で創作しなくても「見る目」「構成力」は役に立つ
    Even if you don’t create, having an eye for design and composition is valuable.

  • ストーリーを作れなくても、素材をまとめる仕事はある
    You don’t need to write stories—there are jobs focused on assembling materials

  • デザイン補助なら高スキルは不要でも歓迎される現場が多い
    Many workplaces welcome design assistants without needing top-tier skills


3. とにかく働きながら、好きなことを試し続ける道
3. Keep working while trying out different interests

現実的な進路:
Practical career options:

  • まずは卒業を目標にして、バイト→正社員化が見込める職場で経験
    First, aim to graduate. Then work part-time at a job with potential to become full-time

  • 並行して、「自分が嫌いじゃないこと」を少しずつ試す
    Alongside, try out things you don’t dislike—bit by bit

    • 絵以外でも「興味がなくはない」ことを試す(動画編集、接客、パソコン作業など)
      Try things beyond drawing—like video editing, customer service, or computer work

理由:
Why this works:

  • やりたいことは「考えて分かるもの」ではなく「試して分かるもの」
    You don’t figure out what you want to do by thinking—you find it by trying

  • 最初の仕事が「一生の仕事」になる必要はない
    Your first job doesn’t need to be your lifelong career

  • 一つの仕事を1~2年やってみることで、自分の向き不向きがわかる
    Doing a job for 1–2 years will help you understand your strengths and weaknesses


最後に一言:
Final Thought:

「やりたいことが分からない」状態のまま、人生を進めても大丈夫です。
It’s okay to move forward in life even if you don’t know what you want to do.
むしろ、「分からないけど動き続けた人」の方が、あとから本当にやりたいことに出会います。
In fact, those who keep going despite not knowing often end up discovering what they truly want to do later on.

あなたが「落書きが好き」という感覚を見つけられているのは、とても貴重です。それは「無い」ではなく、「小さな種」をもう持っているということです。その種を、生活のどこかで大事に育てながら、まずは現実に食べていける進路を一緒に探していけばいいのです。応援しています。
The fact that you’ve found joy in doodling is precious. That’s not “nothing”—you already have a small seed. Take care of that seed somewhere in your life, and in the meantime, let’s find a career path that helps you earn a living. I’m rooting for you.

===== ChatGPTとの会話 ここまで =====
===== End of Conversation with ChatGPT =====

あなたに必要なのは「考えること」ではなく、「子どもの意見をまとめてChatGPTに入力する作業」なのです。
What you need isn’t to think—it’s to gather your child’s thoughts and input them into ChatGPT.

これも「ネグレクト」の一態様かもしれませんが、子どもに「好きなことをしなさい」と言うより、はるかに「マシ」です。
This might also be considered a form of neglect. But compared to telling your child to “do what you like,” it’s a far better option.

-----

ChatGPTの答えは、完璧でも万能でもありません。でも、子どもの「困っている気持ち」に対して、「一緒に困ること」ができます。そして、それで十分で、それが一番大切だと、私は思っています。
ChatGPT’s answers aren’t perfect or all-knowing. But it can help you share in your child’s confusion—and that, in itself, is enough. I believe that’s the most important thing of all.

―― 私たちには、やりたいことなどない

2025,江端さんの技術メモ

pybind11とは何ですか

pybind11 とは、C++で書かれたコードをPythonから簡単に呼び出せるようにするライブラリです。具体的には、C++関数・クラスをPythonにバインディング(橋渡し)するための軽量なヘッダオンリーライブラリです。


✅ 要点まとめ

項目 内容
名称 pybind11
用途 C++コードをPythonから使えるようにする(バインディング)
特徴 ヘッダオンリー、軽量、C++11以降対応
主な代替 Boost.Python、SWIG など
主な用途 Pythonから高速なC++シミュレータや計算ライブラリを使うときなど

🧠 なぜ使うのか?

Pythonは書きやすいが遅い、C++は速いけど扱いにくい。
そのため、重い処理はC++で書き、インターフェースだけPythonで操作したいことがよくあります。

text
たとえば:
Python部分 → 学習ロジック(強化学習など)
C++部分 → シミュレータの高速実行

この「橋渡し」に pybind11 が使われます。


🔧 使用イメージ

C++側(example.cpp)

#include <pybind11/pybind11.h>

int add(int i, int j) {
    return i + j;
}

PYBIND11_MODULE(example, m) {
    m.def("add", &add, "A function which adds two numbers");
}

Python側

import example
print(example.add(1, 2))  # → 3

このように、C++の関数をまるでPythonで書いた関数のように使えるようになります。



🔚 まとめ

観点 内容
概要 C++とPythonをつなぐためのヘッダオンリーライブラリ
主目的 C++で書いた高速なロジックをPythonから呼び出す
利点 軽量・高速・簡単・CMakeと相性良好
使用場面 シミュレーション、機械学習、画像処理、ゲームエンジン等のバックエンド連携

必要であれば、あなたの railway_simulator モジュールが pybind11 で作られているかどうかも確認する手順を案内できます。

使用イメージを実際に動かすにはどうすれば良いですか

以下に、pybind11 を使って C++ 関数を Python から呼び出せるようにする最小構成の実行手順をまとめます。
Linux / WSL / Mac / MSYS2 などの UNIX互換環境を前提にしています(Windows でも MSYS2 や WSL を使えば同じです)。


✅ ゴール

C++ の関数を Python から呼び出せるようにする:

cpp
int add(int a, int b) { return a + b; }

↓ Pythonから:

python
>>> import example
>>> example.add(1, 2)
3

🔧 準備

① Python と pybind11 のインストール

以下をターミナルで実行:

bash
pip install pybind11

(C++コンパイラが必要です:gcc, clang, cl など)


📁 ② ファイルを作成

example.cpp(C++側)

#include <pybind11/pybind11.h>
int add(int i, int j) {
    return i + j;
}
PYBIND11_MODULE(example, m) {
    m.def("add", &add, "A function which adds two numbers");
}

⚙️ ③ ビルド(共有ライブラリ作成)

以下のコマンドをそのままコピー&ペースト:

c++ -O3 -Wall -shared -std=c++11 -fPIC \
    `python3 -m pybind11 --includes` \
    example.cpp -o example`python3-config --extension-suffix`

このコマンドは:

  • pybind11 のヘッダを含めて

  • example.so(もしくは .pyd)というPython拡張モジュールを作成します


✅ ④ 実行(Pythonから呼び出し)

ターミナルで Python を起動し、次を試してください:

>>> import example
>>> example.add(10, 5)
15

成功すれば pybind11 のバインディング成功です!


📎 注意点

項目 内容
ビルドは1行で 改行してしまうと command not found になります。1行にしてください
Windows の場合 -fPIC は不要/MSYS2環境を推奨します
pybind11 の場所 python3 -m pybind11 --includes により自動取得できます
Python バージョン python3.11 など環境によって異なる場合があります。必要なら python3-config を変更してください

✅ もしうまくいかなかったら…

次の情報を貼ってもらえれば、個別にビルドコマンドを調整できます:

  • OS種別(Windows / Mac / Ubuntu / WSL など)

  • Pythonバージョン(python3 --version

  • コンパイラの種類(gcc --version など)


必要であれば、CMakeLists.txt を使った構成や、.pyx ファイルとの違い(Cython との比較)についてもご説明します。

c++ -O3 -Wall -shared -std=c++11 -fPIC \
    python3 -m pybind11 --includes \
    example.cpp -o examplepython3-config --extension-suffix
> > /home/ebata/.pyenv/versions/3.8.10/bin/python3: No module named pybind11
example.cpp:1:10: fatal error: pybind11/pybind11.h: No such file or directory
    1 | #include <pybind11/pybind11.h>
      |          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.

と言われました

ありがとうございます。エラーメッセージを解析すると、以下の2つの問題が発生しています:


❌ 問題1:pybind11 がインストールされていない

bash
/home/ebata/.pyenv/versions/3.8.10/bin/python3: No module named pybind11

これは pybind11Python環境に未インストールであることを示しています。


❌ 問題2:C++ヘッダファイル pybind11/pybind11.h が見つからない

bash
example.cpp:1:10: fatal error: pybind11/pybind11.h: No such file or directory

これは Python モジュールが見つからなかったため、--includes で得られるインクルードパスも空になり、結果として pybind11.h が見つからないという流れです。


✅ 解決手順

以下の手順に従って修正してください。


① pybind11 を正しい Python 環境にインストール

あなたは pyenv を使って Python 3.8.10 を使っているようなので、次のコマンドを使います:

bash
~/.pyenv/versions/3.8.10/bin/pip install pybind11

※または pyenv の環境をアクティベートしてから:

bash
pyenv activate 3.8.10
pip install pybind11

② 再度ビルドコマンドを実行

インストール後、以下の1行コマンドを再度実行してください:

c++ -O3 -Wall -shared -std=c++11 -fPIC \
    `python3 -m pybind11 --includes` \
    example.cpp -o example`python3-config --extension-suffix`

(必要なら python3~/.pyenv/versions/3.8.10/bin/python3 に書き換えてください)


✅ うまくいけば…

カレントディレクトリに example.cpython-38-x86_64-linux-gnu.so のようなファイルができます。

Pythonで次のように実行できれば成功です:

bash
python3
>>> import example
>>> example.add(2, 3)
5

📌 備考(トラブル防止)

内容 対処法
複数バージョンの Python がある 明示的に ~/.pyenv/versions/3.8.10/bin/python3 を使う
pip install したのに ModuleNotFoundError pippython が同じ環境を見ているか確認(例:which pip, which python3
pybind11 のヘッダが見つからない python3 -m pybind11 --includes の出力結果を確認して -I/path/to/pybind11/include を手動で追加

2025,江端さんの忘備録

チケットの転売が社会問題になっています。
Ticket reselling has become a social issue.

社内で開催される講演会の出席率の低さが(以下、自主規制)。
The low attendance rate at internal company lectures is... (self-censored).

社内講演会は業務時間中に開催されるため、出席しても問題はありません。
Internal lectures are held during working hours, so there's no problem in attending them.

ただし、この「業務時間内」というのがクセモノです。
However, the phrase “during working hours” is somewhat ambiguous.

はっきり言って、みんな「忙しい」。
Everyone is “busy.”

講演を聞きたくても、時間がないのです。
Even if they want to attend the lecture, they don’t have the time.

リモート中継で済む話では?と思いがちですが、
You might think a remote broadcast would solve the problem,

主催者側としては「リアルな出席人数」が大きな評価ポイントになるようです。
But for the organizers, the number of people physically present is often a key metric.

-----

その気持ち、私にはよく分かります。
I completely understand that sentiment.

出席者が少ないと、
When there are few attendees,

せっかく講演を依頼した大学の先生や著名な著者に対して「申し訳ない」という気持ちが湧いてくるでしょう。
You can’t help but feel “sorry” toward the professor or distinguished author you invited.

さらに、質疑応答が盛り上がらないと、
Moreover, if the Q&A session doesn’t take off,

「関心がなかったのでは?」という無言のメッセージになってしまうのでは、という心配もあるでしょう。
You worry it sends a silent message: “Maybe people weren’t interested.”

-----

私が主催者だった頃は、
When I was the organizer,

「この先生の◯◯の話が最高!」「この本は何度も読んだ、面白かった!」など、
I would write things like “This professor’s talk on XX is amazing!” or “I’ve read this book multiple times—it's great!”

ネタバレすれすれの宣伝文を、
—almost spoiler-level promotional messages—

メール(当時はチャットもSNSもなかった)で、言葉を変えながら繰り返し発信していました。
I would keep sending them emails (there was no chat or social media at the time), changing the wording each time.

要するに、「コンテンツの中身」を「自分の言葉」で伝える努力をしていました。
In short, I made the effort to convey the “content” in “my own words.”

(今にして思えば、かなりの時間をかけていました)。
(Looking back now, I realize I spent a lot of time on it.)

そんな過去をもつ主催者の一人としては、
As someone with that kind of experience as an organizer,

「業務命令による強制動員」は、ちょっと違うんじゃないかな?という気がしています。
I can’t help but feel that “mandatory attendance via work orders” is somehow... off.

ただ、講演を依頼した相手との関係などを考えると、
That said, considering the relationship with the invited speaker,

ある程度の「業務命令」もやむを得ないのかもしれません。
Some level of “work-enforced attendance” might be inevitable.

-----

私も、学会での発表で聴講者が少ないとガッカリすることはあります。
I also feel disappointed when there are few attendees at my conference presentations.

せっかくなら聞いてほしい。資料作成もがんばったので。
After all, I want people to hear it, and I worked hard on preparing the materials.

私の場合、なぜか聴講者が少なくても質問が多いです。
In my case, for some reason, even with a small audience, I get a lot of questions.

私自身も聴講したら必ず1つは質問するようにしています。
I always ask at least one question when I attend a lecture.

-----

逆のケースもあります。
But there’s also a case where the opposite is true.

たとえば、論文の最終審査(公聴会)では、出席者は少ない方がありがたい。
For example, in the final thesis defense (public hearing), fewer attendees are welcome.

なぜか?
Why?

論文最終審査とは、英語で「Final Defence」って言うんですが ----
Because in English, the final thesis presentation is called a “Final Defence”—

真の意味において「専守防衛」なんです(この話はまた別の機会に)
In the truest sense, it’s “strictly defensive warfare.” (More on that another time.)

-----

本日の結論としては、講演の出席率を上げたいなら「業務命令」より「ネタバレ」です。
In conclusion, if you want to boost attendance, “spoilers” work better than “work orders.”

あと、ケーキやビールも効果あります(たぶん)。
Additionally, cake and beer are also helpful. (Probably.)

『英語に愛されないエンジニアの、国際学会プレゼンテーションのリアル』