[{"categories":["メモ書き雑感"],"content":"知乎（ジフー）で面白いトピックを見た：今の時代最大の红利（レッドパケット／恩恵）は、もしかしたら「平成の引きこもり生活」かもしれない。\nこの言い方には少し自嘲的な響きがある。人が一人で部屋に住み、エアコンはつき、照明は明るく、飲み物やスナックが手の届くところにあり、画面には見きれないほどのアニメや映画、ゲーム、ショート動画が並んでいる。外出したくはないし、外出する必要もない。仕事はオンラインで済ませられ、食事は玄関まで届けてもらえるし、知らない他人の知識や経験もいつでも検索できる。こうした暮らしは、おそらく過去五千年では想像すら難しかっただろうが、今では多くの人が何気なく選べるデフォルトの選択肢になっている。\n私たちはそれに慣れすぎており、それがどれほど贅沢であるかをほとんど意識していません。\n何千年もの苦労を、一つの部屋に凝縮する 古代人々は、一日のかなりの時間を、生活を維持するために費やしていました。食べ物を得ること、食べ物を保存すること、水を得ること、暖を取ること、照明を得ること、天候を避けること、身体の不快に対処すること。もし過去を過度に悲観的に捉えないとしても、快適さが生活の基調ではなく、継続的な労働によって换来される短暂な状態であることを否定するのは難しいでしょう。\n今日では、一般の部屋でも夏には涼しく、冬には暖かく保つことができます。冷蔵庫は食べ物の保存期間を延ばし、洗濯機は繰り返しの手作業を代わりに行い、照明は夜を暗闇と同じにすることはありません。私たちがしなければならないのは、スイッチを押すこと、あるいは目立たない電気料金を受け入れることだけです。\nこれはある天才の発明によってもたらされた奇跡ではなく、エネルギー、工業、交通、都市、公共サービスが共に積み上げた結果である。現代人の「何もしなかった」は、多くの人々、多くの機械、そして多くの世代の仕事の上に立っていることが多い。\n所谓的廃宅とは、まず第一にインフラに支えられた人間のことである。\nエンターテインメントが初めてほぼ無限大になる かつては、夜の時間を潰したいと思っても、人に取り得た選択肢は多くなかった。本は書かれ、印刷され、手元に届けられる必要があった。演劇には俳優、舞台、そして同じ場所に居合わせる観客が必要だった。音楽や物語には明確な時と場所があった。\n現在、私たちはプライベートな娯楽をほぼ過剰に所有している。人はベッドの上に横たわり、数秒のうちに他人の物語、他人の競技場、他人の宇宙に入り込むことができる。画面は番組を提供するだけでなく、社交、ニュース、チュートリアル、ゲーム、そして絶えず更新される公共の広場をも提供する。\nこの素晴らしい点は、娯楽が高級になったということではなく、娯楽への入口がついに希少でなくなったということだ。人付き合いが苦手だったり、体が不自由だったり、一時的に職を失ったり、あるいは単に今日は誰にも会いたくないという人でも、一晩中ひとつの世界を持つことができる。\nこれはかつて「手を抜く選択」ではなく、そもそもそのような選択肢自体が存在しなかった。\n知識もポケットに入った 私がこの時代のもう一つの好きなところは、多くの問題が、博識な人物の出現を待たなくても、回答を得る機会があるということだ。\n何かの直し方を知りたいなら、検索すればよい。言語を学びたいなら、コースを開けばよい。見知らぬ土地に興味があれば、まず地図や他の人の記録を見る。答えが信頼できるとは限らないし、情報が知恵につながるとも限らないが、「知りたい」という思いと「探し始めることができる」ということの間の距離は、信じられないほど短くなっている。\nかつては、知識は地域や身分、財産、そして師弟関係と結びつくものでした。今日では、平凡な人が小さな部屋に座りながら、時に自分の生活圏を大きく超えた経験に触れることができます。接触の機会が増えたとしても、理解の機会がすでに平等になったわけではありません。設備、ネットワーク、教育、そして注意力は依然として境界線を引きます。それにもかかわらず、この開放性はすでに一人の人の精神的な生活を変えるのに十分です。\n引きこもりは必ずしも世界からの撤退ではない。時には、ただ低コストな方法で、過度に大きな世界につながっているだけなのだ。\n配当は自動的に幸福にはならない もちろん、快適な部屋それ自体が幸福ではない。\n一人はエアコンもネットワークも無限のコンテンツも持てるが、それでも不安を感じ、孤独にさいなまれ、不眠に悩まされることがある。選択肢が多すぎると雑音になり、常にオンラインであることは新たな労働になり、玄関まで届けられる食事も人の関係や病気、老いを代わりに処理してくれるわけではない。「ひきこもり生活」を最も楽しみやすい人々は、概して比較的安定した住居、設備、収入と私的な時間をすでに持っている人であり、別の人々にとって、孤独であることは自由ではなく、他に居場所がないということである。\nつまり、「平成ニート」と呼ばれる人々が見出す価値とは、自分を閉じ込めることではなく、努力を拒むことでもない。むしろこう認めることなのだ──すなわち、人間には人生の一部を休息に、遊びに、ぼんやり何もしない時間に、あるいは何の成果も生まない活動に充てる権利がある、ということを。\n私たちは、空き時間の一つひとつをすべてスキル、収入、あるいはよりよい自分自身と交換する必要はない。\nこれは私たちが最も誤解している種類の豊かさかもしれない 人間はどうしても、目先の便利さを当然のものとしてしまい、すでに持っているものを空気のように扱ってしまいがちです。より広い家、より速い設備、より高い収入のために悩み続ける一方で、「今晩、安全にベッドに横たわり、自分の選んだ映画を観られる」ことに対して、驚きを感じることはあまりありません。\nしかし、少し長いスパンで見てみると、今日における普通の人々の余暇は、かつての貴族でさえ完全に持ち得なかったものかもしれない。安定した温度、豊富な食事、持続的な照明、個人的な娯楽、遠方の知識、そして次のことを許可なく選べる自由。\nこれは、私たちがすでに楽園に生きているという意味ではない。そうではなく、この時代を嘆く前に、時にはこの時代が私たちに贈ってくれた贈り物に気づいてもよいのではないかということだ。\nドアを閉めて、画面をつけて、静かに夜を越す「平成のひきこもり」になることは、ある意味では、五千年の生活史が普通の人々の手に渡った巨大な配当のようなものである。\n本当の問いは、おそらくこうだ。やっと休む資格を手にしたとき、休息そのものを恥じずにいられるのかどうか。\n写作附记 元のプロンプト $blog-writer 知乎で興味深い話題を見かけました、今の時代最大の红利：平成废宅の生活。それは過去五千年において想像もできなかったものです。しかし今、それは簡単に手に入ります。\n執筆に関する説明 本文は、ユーザーから提供された选题に基づくオリジナルの随筆であり、知乎の元の投稿の転載や言い換えではない。「平成廃宅」はユーザーから提供された観察的な表現として使用しており、出典についての考証は行っていない。\n","date":"2026-07-22","language":"ja","permalink":"https://ttf248.life/ja/p/the-greatest-dividend-is-the-heisei-otaku-life/","tags":["時代観察","ライフスタイル","引きこもり","幸福感","随想"],"title":"平成ひきこもりの生活は、この時代最大の红利である","year":"2026"},{"categories":["投資 (tōshi)"],"content":"十年働いてきた中で、私はかつて金利が比較的高い時期に定期預金を組み入れ、その後債券がポートフォリオの中でより重要な部分を占めるようになりました。私が保有してきた定期預金や債券商品は、一時期約4.5%のリターンを提供してくれました。その頃私は、適切な期間にお金を預け入れ、時間の働きに大半を委ねることに慣れていました。\n現在、私の口座における現金管理型商品の収益は明らかに低下しており、従来の方法を見直す必要があります。この半年間、私は純債のポジションを減らし、債券プラス（固収+）の配分を増加させてきました。ここでの「プラス」は収益数値を良く見せるためではなく、単一の低ボラティリティ資産では今後しばらくの目標を達成できない可能性があるからです。\n私が整理したいのは、低金利、クロスボーダーでのファンド購入状況が保証されない、株式市場が下落する可能性がある——こうした条件が同時に存在する場合に、10年期間の資金をどう配分するかということです。\n収益率の変化から、キャッシュフローの問題に立ち返る 過去の金利経験は、資産配分を「より高い利回りの場所を選ぶ」ことと理解しやすくさせます。口座内の低リスク収益が下がったとき、私はまず次のように問い始めます。今後5年から10年の間に、必ず使うお金それぞれに自分の場所があるか。長期間使わない資金が純資産の変動に耐えられるか。変動が発生したとき、手元の現金にまだ余裕があるか。\n私は投資期間を最低でも5年とし、10年を計画の一区切りとして設定しています。これは自分なりの時間尺度であり、さまざまな市場局面が帳簿に組み込まれる機会を確保し、変動や回復期も想定に入れるためのものです。期間そのものはリスク判断の代わりにはならず、ある日必ず収益が回復するという約束でもありません。\n私にとって、資金の配分順序は具体的な投資対象よりも優先されます。まず近々の支出と緊急用の現金を確保し、次にさまざまな資産カテゴリごとに許容できるポジション上限を設定し、その上でようやく長期の積立投資について話し合います。実際の暴落局面で計画通りに実行できるかどうかは、その時に売却不要な現金が手元に残っているかどうかにかかっています。\n以前、ファンドと固定收益理财について書いたことがありますが、その時はファンドや固定收益商品に触れた経験の記録でした。この古い記録は、資金配分は自分のステージや市場の状況に応じて見直す必要があることを改めて気づかせてくれます。\n2つのクロスポーダー構成の実用上の制約 長期保有ポートフォリオの部分では、ナスダック100とS\u0026amp;P500に対応する指数に連動するファンドの口数を保有し、少額での積立投資を行っています。この部分の資金を配分する際に、QDIIファンドの申购（購入）状況が保証されないという状況に遭遇しました。そのため、「下落時に買い増す」という行動は、私にとっていつでも実行できる操作ではありません。\n市場が比較的高水準にある局面では、機会を逃すことへの不安から一度に多額を投入したくない。一方で、明確な調整局面が訪れたときには、用意しておいた資金が購入ステータスの制約によって投入できない可能性がある。市場の上昇・下落も、こうした購入ステータスも自分の意思で決められるものではないため、それらを確実に実行できる追加入口の計画として書き記すことはできない。\nしたがって、私は国境を越えた部分を長期計画における限定的な枠組みとしてのみ位置づけ、総額と積立のペースをあらかじめ制約している。このアレンジメントは市場のバリュエーションや申込みの状況を変えることはできないが、流動性を維持しなければならない資金を、いつでも追加で投資できる資金としてあらかじめ設定してしまうことを避けることができる。\nCSI 300 関連部分についてですが、私は現在この指数のファンド持分を保有しており、今後は徐々に CSI 300 増強型戦略へ移行させる予定です。私の本通貨資金の配分については、自身のキャッシュフロー、積立投資のペース、预留資金（预留资金）に基づいて記述できます。もし将来ドローダウンが発生した場合に追加投入するかどうかは、事前に決定したポジション上限に従うこととします。これは私の計画ロジックであり、誰に対する取引指示を構成するものでもありません。\n再現可能な基準で歴史を検証する 私の実際の積立投資では、プラットフォームのスマート積立投資機能を使用しており、弱気相場では多めに、強気相場では少なめに購入します。ただし、Alipayのアルゴリズムの公開パラメータも、実際の引落し記録も持っていないため、以下のバックテストはAlipayのスマート積立投資アルゴリズムを再現するものではなく、実際の口座のリターンでもありません。\n結果を検証可能にするため、バックテストではより素朴な代替ルールを採用しています。すなわち、各自然月の最初の入手可能な基準価額日に、1単位の現金を等額投入し、その日の単位基準価額に基づいて口数を換算し、期末には最後の入手可能な単位基準価額で評価します。\n年率換算収益：全期間の月次投資キャッシュフローと期末口座時価を基に、年率換算 XIRR を算出します。 最大ドローダウン：当ファンドの完全な取得可能区間における基準価額系列に基づき算出します。 ドローダウン回復期間：最大ドローダウン前の基準価額の高値から、基準価額が初めてその高値またはそれ以上まで回復するまでの暦日数を指します。 純資産額は東方財富天天基金が公開している過去の純資産額インターフェースから取得し、取得日は 2026 年 7 月 22 日です。使用するフィールドは単位純資産額であり、累計純資産額や日次騰落率ではありません。各ファンドは入手可能な全期間を使用しており、長期データを比較のために揃える目的で切り詰めたものはありません。\n本稿は単位純資産価額（NAV）をデータソースの基準としており、口座レベルの費用や摩擦については別途シミュレーションを行っていない。具体的には、売買手数料、税金、為替コスト、実際の購入制限、トラッキングエラー、その他の取引摩擦が含まれるが、これらは「同額月次積立は透明性の高い代替ルールであり、Alipayのスマート積立の再現ではない」という境界を変更するものではない。\nファンドコード（ファンド名称） バックテスト期間 月次投入回数 年率 XIRR 最大ドローダウン ドローダウン回復期間 001015（华夏CSI300インデックス増強A） 2015-02-10 ～ 2026-07-21 138 7.61% -42.02% 1,728日 000051（华夏CSI300ETFリンクA） 2009-07-10 ～ 2026-07-21 205 5.77% -43.43% 1,857日 270042（広発ナスダック100ETFリンク人民元(QDII)A） 2012-08-15 ～ 2026-07-20 168 17.11% -31.18% 588日 019305（モルガン・スタンレー S\u0026amp;P500インデックス(QDII)人民元C）* 2023-09-01 ～ 2026-07-20 35 13.95% -17.44% 127日 019305 はわずか 35 か月という自然月サンプルしかなく、経てきた市場局面は他の 3 本のファンドよりも明らかに少ない。その年率 XIRR、最大ドローダウン、回復期間はあくまでこの短いサンプルのみを記述するものであり、長期サンプルのファンドと横並びで比較すべきではない。まして、そこから将来のドローダウンが小さいとか回復が速いといったことを推断してはならない。 私はまず最大ドローダウンと、その回復に要した時間を見る。この一連の歴史サンプルを例にとると、001015 の最大ドローダウンは2015年6月12日の高値から始まり、2020年3月5日に単位純価が初めてその高値に再び到達または超えるまで1,728日間かかった。000051 は1,857日間かかった。数年連続で未回復の帳簿上の変動に直面することは、この10年計画が必ず織り込まなければならない状況である。\nバックテストは私に判断を下してはくれなかったが、問いかけ方を変えてくれた 履歴バックテストは、もやもやしていた私の漠然とした期待を、事前に答えるべきいくつかの問いへと書き換えてくれました。\nまず第一に、预留された資金が、予想よりも長い修復期をカバーするのに十分かどうかである。ドローダウンは数週間しか続かない折れ線ではなく、少なくとも上述した二つのCSI300サンプルでは、以前の高値を回復するのに四年以上が掛かった。その分の資金を短期的に使う予定にしていた場合、計画通り継続することは難しい。\n次に、クロスボーダー資産の追加ポジションの前提が、保証されない申込状態に依存しているかどうかである。私は既存のポジション、それが起こり得る変動、そして他の資産の資金手配を、まず自分が許容できる範囲内に置く。追加ポジションは申込条件が許可された場合の選択肢に過ぎない。\n第三に、本通貨の權益を引き出すルールに明確な境界があるかどうか。私はまず、この部分の資金の総額、何回に分けて投入するか、そしてどの程度下落したら追加投入しないかを書き留める。明確に書き留めるまでは、臨時的な追加ポジションをルールとは見なさない。\n私の低金利環境の経験では、過去の収益感をそのまま再現してくれる資産は存在しません。私の調整は、債券をポートフォリオの安定部分に戻し、株式とクロスボーダー構成をより長いサイクルに組み入れ、申込状況、キャッシュフロー、ドローダウンをすべて計画に書き入れることです。\n最低5年、1サイクル10年という期間で、私はこの計画のために確保したい時間を設定している。 これは利益の約束書ではない。 次に市場の変動が訪れた時、応急資金を売却するかどうかをその場で決めたり、 QDIIファンドの申购状態の変化に遭遇したことで計画全体を書き換えたりせずに済むようにしたいと思っている。\nデータ説明 本文のバックテストでは、東方財富天天基金が公開している過去の基準価額データを使用しています：001015（華夏CSI300インデックス増強A）、000051（華夏CSI300ETFリンクA）、270042（広発ナスダック100ETFリンク人民元(QDII)A）、019305（モルガン・スタンダード＆プアーズ500インデックス(QDII)人民元C）。基準価額の取得日は2026年7月22日で、データの取得可能期間および計算方法は表に示すとおりです。\nバックテストはデータソースの単位純資産価額のみに基づいて算出されており、申込・償還手数料、税金、為替コスト、実際の申込制限、トラッキングエラー、その他の取引摩擦など、アカウントレベルの費用や摩擦は別途シミュレーションされていません。過去のデータは将来のパフォーマンスを保証するものではなく、本文中の個人資金の配分は考え方の説明のみを目的としており、投資、取引、資産配分の推奨を構成するものではありません。\n参考資料 東方財富天天基金履歴純価インターフェース：https://api.fund.eastmoney.com/f10/lsjz（2026-07-22 取得；単位純価基準） 東方財富ファンドページ：https://fund.eastmoney.com/001015.html、https://fund.eastmoney.com/000051.html、https://fund.eastmoney.com/270042.html、https://fund.eastmoney.com/019305.html（2026-07-22 ファンド名を検証） 写作附记 元のプロンプト $blog-writer 金利引き下げ時代の資産運用ポートフォリオについて考える。仕事に就いてから10年、そのほとんどの期間を高金利の時代を過ごしてきた。最初の4年間は定期預金だけでもまずまずの収益が得られ、その後の5年間は債券でもまずまずで、以前は4.5% も難しくはなかった。国際的なマクロ環境の変動に伴い、中国は急速に金利引き下げのチャネルに入り、ユーバオ（Yu\u0026rsquo;ebao）の年率収益率は1% を割り込むまでになった。最近の半年間は債券のポジションを減らし、債券プラス（固収+）の債券を増やしてきた。ナスダック100ETF と S\u0026amp;P500ETF のドルコスト平均法を配置し、QDII の外貨枠が規制されている中、少額のドルコスト平均法を行った。現状は高値圏にあり、大口投資も適切ではない。米株指数については問題があり、大暴落時にQDII の枠がなく、どうやって追加ポジションを取ればよいのかという課題がある。またCSI300 指数も配置しており、その後 CSI300 増強タイプに調整した。これは管理しやすく、調整時に追加ポジションを取れ、資金の計画は合理的に行う必要がある。計画通りに進め、バックテストで収益を検証する。ドルコスト平均法はすべて智能定投（スマートドルコスト平均法）で、弱気相場では多く買い、強気相場では少なく買うというもので、すべて支付宝（アリペイ）のアルゴリズムを使用している。バックテストで得られたデータを表に整理し、本文中に掲載する：年率収益率、最大ドローダウン、ドローダウン回復時間。バックテストに使用するファンドコード：CSI300ETF 増強：001015、CSI300ETF：000051、ナスダック100ETF：270042、S\u0026amp;P500ETF：019305。\n新しい投資計画、投資期間は5年からのスタート、10年を一つのサイクルとする。\n","date":"2026-07-22","language":"ja","permalink":"https://ttf248.life/ja/p/ratecut-allocation-plan/","tags":["投資 (tōshi)","投資信託の定期積立","資産配分","AI霊感衝突坊"],"title":"低金利環境下で、私は10年間の財務プランを組み直した","year":"2026"},{"categories":["金融知識データベース"],"content":"7月初め、沪深市場の引け後固定価格取引の拡張に関するニュースが話題となり、古くて新しい疑問がトレーディングデスクに戻ってきました。引け後に突然成立する取引は、一体「引け後取引」と見なすべきなのでしょうか。米株のMOC（Market on Close）や香港株のCAS（Closing Auction Session）と並べて考えると、答えは次の通りです。いずれも終値を中心に流動性を組織するものの、それぞれ価格形成の異なる段階に位置しています。\nこの件の本質は取引時間が30分延びることそのものではなく、注文件数を増やすことで執行結果を公的終値により近づけられる点にある。終値は日足チャートの終点であると同時に、指数算出、ファンドの運用評価、ベンチマーク比較で広く用いられる共通の基準となる。ベンチマークを追跡する必要がある口座にとって、日中「割安に見える」約定が、必ずしもベンチマークと整合した約定の代替とはならない。\n3つの「クローズ」概念を分解する 市場関連の議論では、終値前後のさまざまな取引を総称して「クローズ取引」と呼ばれることがよくありますが、実際には少なくとも次の3つのカテゴリに分ける必要があります。\nメカニズム 終値がここで形成されるか 典型的な用途 クロージング・オークションまたは終値オークション はい 注文を集約し、公的な終値基準を形成する 確定終値でのポストクローズ・オークション いいえ 形成済みの終値で引き続き取引を成立させる 延長取引セッション いいえ、価格変動の可能性あり クローズ後も気配提示と取引を継続する 第一の種類は「本日の公式終値はいくらですか」という問題を解決する。第二の種類は「価格はすでに決定されており、この価格で取引したい人はまだいるか」という問題を解決する。第三の種類になって初めて、通常言われる時間外延長取引に近づく。参加者は取引を継続し、約定価格は公式終値から乖離する可能性がある。\nしたがって、MOC は米国株式のポストマーケット取引の同義語ではなく、CAS は 1 枚の注文でもない。今回 A 株で議論されているポストマーケットの固定価格取引は、終値形成後の価格マッチングである。3 者の共通目標は終値の基準であり、制度上の位置づけは異なる。\nA株の増量：固定されるのは価格であり、約定数量ではない 公開報道によれば、上海および深セン市場は、ザラバ後の固定価格取引の適用範囲を、スターマーケット（科創板）と創業板の株式から、上海・深セン市場の全A株およびETFに拡大することを計画している。報道では、取引のマッチング時間帯は15:05〜15:30とされ、約定価格は当日の終値、時間優先の原則で逐次マッチングされるとされている。本ラウンドで取得できる資料はメディアによる報道にとどまるため、実際の実施日、対象有価証券の範囲、申告受付および注文取消しのタイミングについては、取引所の当該時点で有効な規則および通知を基準とすべきである。\nこの仕組みのビジネス上の意味は非常に明確である。終値が決まっており、売り手と買い手の双方がその価格を受け入れた場合にのみ、排队マッチングが継続される。価格を再発見することはなく、二番目の終値も生じない。価格リスクは「今日の終値を受け入れるかどうか」まで圧縮されるが、約定リスクは依然として存在する。有效申报（有効な注文）を出したとしても、必ずしも相手が現れるとは限らない。言い換えれば、この仕組みが固定するのは価格であり、数量と流動性ではない。\nここでは、上海市場と深セン市場の終値メカニズムをひとつの概念にまとめて考えてしまうことを避けなければなりません。深セン市場には引け時のザラバ終了に伴うコール・オークションが設けられていますが、上海市場の公式な終値はその市場自身のルールに従って算出されます。それぞれの市場において終値がどのように形成されるにせよ、立会外での固定価格取引（Post-Closing Fixed-Price Trading）は、その公式な終値が確定した後に行われます。\nETF は、この拡張の中で最も誤解されやすい要素の一つです。時間外取引は ETF の二級市場における売買を取り扱うものであり、ETF の設定・解約（申込・赎回）を直接行うものではありません。設定・解約は引き続き、ファンド契約書および関連業務規則に従って行われます。これは、ETF の管理、マーケットメイク、そして ETF または構成銘柄を用いたリバランスを行うアカウントに対し、二級市場における新たな執行窓口を提供する可能性があり、約定価格が評価やトラッキングに用いられる引け基準価格により近づきやすくなることを意味します。\n米国株式 MOC：クロージング・オークションで最終価格を受け入れる MOC は「最終終値で約定させるクローズ注文」と理解できます。これは注文をクロージング・オークションに送り込みます。発注時点では最終価格はわからず、ビッガーによって最終的に形成された公式終値を受け入れるという意思表示であり、終了後 に通常の成行注文を発注するわけではありません。\nこの違いが重要である。時間外確定価格取引が対象とするのはすでに判明している固定の終値であるのに対し、MOC が対象とするのはまだ競売によって確定する最終終値である。前者は主に終値形成後のマッチングを担い、後者は注文を終値形成プロセスに持ち込む。MOC は無条件の約定を意味するわけではなく、注文の受付締切、取消制限、需給の不均衡に関する情報、約定可否の条項などはすべて取引所のルールによって異なるため、「米国株の MOC」を市場全体で完全に同一のルールであるかのように理解してはならない。\nなぜクローズウィンドウにこのような需要があるのか？インデックスファンド、ETF、そして公式クローズ価格で評価される口座は、多くの場合、約定価格とベンチマークの一致をより重視します。指数調整やポートフォリオのリバランスなどのイベント日には、こうした需要がより集中する可能性があります。しかし、1件のMOC注文や終盤の出来高の急増から、特定タイプの資金が必ず強気または弱気であると直接推断することはできません。\n港株 CAS：注文ではなく、ザラ場終了の手続き CAS は香港株式市場のクローズ・オークション・セッション（Closing Auction Session）の略称です。これは MOC（マーケット・オン・クローズ）と直接対応する注文名称ではなく、引け値の決定プロセスを構成する一連の仕組みです。具体的には、参照価格、許容価格レンジ、注文入力、付け合わせ（マッチング）、そしてランダム・クローズなどの各要素を通じて、引け段階における売買の意図を集約します。ランダム・クローズとは、クロージングの終了タイミングを正確に予測できない仕組みであることを意味します。\n階層的に見ると、MOC は引け竞价に参加する一種類の注文であり、CAS は引け竞价を担う一連の時間帯と手続き全体です。A 株の引け後固定価格取引は、公式の引け値が形成された後、その価格で約定を行います。CAS の対象証券、段階区分、価格制限は、その日の香港取引所有効規則に基づくべきであり、香港に上場しているからといって、必ずしも同等の CAS 流動性があると仮定してはなりません。\n規模：まず基準を統一してこそ、比較に意味がある 「クロージング関連の取引量がどの程度か」という問いには、本来、自然で統一された答えなど存在しない。ある者は全日の最後の数分間の売買代金を集計し、ある者はクロージング・オークションの売買代金を集計する。ETF を含める者もいれば、株式のみを対象とする者もいる。また、クロージング・オークション、Post-Market の固定価格取引、延長取引セッションを同じ分母に含めて考える者もいる。たとえすべて「クロージング取引の比率」と呼ばれていても、日付・対象市場・通貨・取引の定義が異なれば、単純には横並びで比較することはできない。\n本ラウンドでは、3つの地域における同一日付・同一基準での最新の公的規模データを取得できなかったため、噂されているシェアや金額を結論として記述することは控える。確認できるのは構造的な意味合いのみである。すなわち、これらのメカニズムはクロージング基準値に近い注文を必要とするトレーダーに対し、それぞれ異なる経路を提供する。指数調整など特定の日には、関連するフロー額が顕著に増大する可能性がある。どの地域が「より大きい」のか、あるいは全日のどの程度の割合を占めるのかについては、まず統計基準を揃える必要がある。\n終値前の大量取引を見たら、まず5つの質問をする 約定は公式終値の形成前、形成中、それとも形成後に発生したか？ 注文は最終終値を受け入れているのか、それとも依然として新たな指値の判断を表しているのか？ 当日にインデックス調整、ETF リバランスなど、既知のベンチマーク執行需要が存在するか？ 注文の不均衡、企業情報、あるいは市場イベントなど、より直接的な説明は他に存在するか？ データの対象は株式、ETF、あるいは特定の取引セッションのいずれか？ 終値が約定を引きつけるのは、それが本来強い方向シグナルを含んでいるからではなく、最も公共的で比較しやすい価格であるからだ。MOC、CAS、A株のアフターセッション固定価格取引は、いずれもこの基準を中心に流動性を組織する異なるツールである。MOCは終値オークションに参加し、CASはクロージング・オークション・プロシージャを組織し、A株のアフターセッション固定価格取引は価格形成後も引き続き注文をマッチングさせる。この分業を理解するほうが、終盤の出来高増加を単純に強気・弱気の判断に翻訳するよりも信頼性が高い。本稿は取引メカニズムの説明のみを目的としており、いかなる取引提案も構成するものではない。\n参考資料 《重要な調整！明日より、A株の取引ルールが変わる》，北京日報が中国基金報を転載、搜狐が再転載、2026-07-05：https://www.sohu.com/a/1045971173_163278 《引け後も営業？A株取引の新ルールとはいったい何を意味するのか？》，澎湃号、2026-06-10：https://www.thepaper.cn/newsDetail_forward_33342443 写作附记 元のプロンプト $blog-writer A株は最近終了後取引を拡大しており、米株にはMOC、港株にはCASがあります。この業務について、背景、規模、業務上の意味を詳しく説明してください。\n","date":"2026-07-14","language":"ja","permalink":"https://ttf248.life/ja/p/close-price-trading-moc-cas/","tags":["AI霊感衝突坊","A株 (エーショウ)","市場のマイクロ構造","ETF","クローズ竞价","MOC","CAS"],"title":"引け値付近の出来高：A股のクロージング・コール・オークション、MOC、CASについて","year":"2026"},{"categories":["コンピューター","投資 (tōshi)"],"content":"この記事はモデルのリーダーボードからではなく、月単位での記録から始まる。2022 年 11 月以降、AI 産業はほぼ毎月、問いを塗り替えてきた。まず「一般人が大規模モデルを使えるか」、次に「モデルが画像・音声・生成・推論を行えるか」、続いて「ツールを呼び出したりパソコンを操作したりできるか」、そしてようやく「これらの能力がユーザーを惹きつけ、予算に入り、キャッシュフローを生むか」へと、問いは移っていった。\nタイムラインには、実際に起きた高シグナルのイベントのみを選定する。モデルのリリース、オープンウェイトの公開、製品の一般公開、効力発生済みの政策、企業ガバナンスは記載可。予告、噂、未完了の資金調達は起きた事実として書かない。毎月最初の1件はその月の株式市場（最大4件）、残りの項目はAI産業のイベントを記録し、2026年7月は7月13日までとする。\nここでの株式記録はYahoo Financeの月足データを使用し、米株・A株・港株を無理に同一指数にまとめていません。月次テーブルにはすでに取り入れている高ボラティリティ銘柄を残したまま、当月記録に値する新しい銘柄を追加しています。「妖股（やおうかぶ）」は当月の上昇率・値幅・出来高またはテーマ拡散が特に突出したものに対する俗称であり、ファンダメンタルズ評価でも売買推奨でもありません。表中の「当月騰落率」は月末の復権終値を前月末の復権終値と比較して算出しており、「取り込み後累計」はこれらの月間騰落率を複利計算したものであって、実際の保有収益を表すものではありません。現在月は2026年7月13日時点までのデータであり、正確な価格は文末のYahoo履歴行情入口で再確認してください。\n2022 年：入口が開かれる 11月：ChatGPTが公開デビュー（NVDA +25.4%） 市場記録： ナスダックは利上げとリセッション（景気後退）予想の中で依然として揺れており、エヌビディアは安値から反発しているが、AIはまだ独立した市場のメイントレンドを形成していない；妖株（異常騰落株）：明確なAI妖株はまだ形成されていない。\n怪物株累計表（2022年11月末まで、月末復権終値の複合；エヌビディアをリーダー対照として）\n対象（コード） タイプ 追加月 今月の騰落率 追加後累計 エヌビディア（NVDA） 中核リーダー比較 2022-11 +25.4% +25.4% 11月30日、OpenAIがChatGPT研究プレビューを公開。 ダイアログボックスが大規模モデルを初めて一般ユーザーに提供する製品入口となり、モデルの能力は研究機関によるデモから一般ユーザーが繰り返し利用できるソフトウェアへと変わった。OpenAI：Introducing ChatGPT 今月の見解: 重要なのは、ChatGPT が最初にテキストを生成するかどうかではなく、自然言語が初めて十分に低い敷居のソフトウェアインターフェースになったということです。\n12月：デモから拡散へ（NVDA -13.6%） 市場の記録： 米国のテクノロジー株は利上げ観測の下で下落し、NVIDIA は半導体セクターとともに軟調となった。ChatGPT の普及はすぐに株式相場には反映されず、明確な材料株としては形成されていない。\n怪物株累計表（2022年12月まで、月末権利調整後終値の複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 -13.6% +8.3% ChatGPT が急速な普及期に入る。 OpenAI のその後のリリースノートには、ユーザーがコンテキスト、ネット連携、プラグイン、コードインタプリタに関する製品要件を求め始めたことが記録されており、チャット製品は単なる一回限りの質疑応答デモではなくなっている。ChatGPT リリースノート 今月の判断： 産業の最初の成長は新しいモデル名からではなく、利用習慣からもたらされる。ユーザーがまずモデルにタスクを任せることに慣れ、開発者がようやく埋め込み可能なワークフローを探し始める。\n2023 年：能力、オープンウェイト、設備投資のすべてが同時に加速 1月：クラウドとオフィスが結びつき始める（BBAI +385.2%） 市場記録： 米国のグロース株は2022年の安値から反発し、Microsoft、NVIDIA、AMDはまずクラウドとチップ回復の銘柄として取引された。C3.ai（AI）はテーマ性のある値動きを見せ始めたが、まだ安定したAIの過熱株群は形成されていない。\n妖怪株累計表（2023-01まで、月末復権終値の複合；エヌビディアをリーダー対照として）\n対象（コード） タイプ 掲載月 今月の騰落率 掲載後累計 エヌビディア（NVDA） 中核リーダー比較対象 2022-11 +33.7% +44.9% C3.ai（AI） 米国株ハイボラティリティ 2023-01 +77.4% +77.4% BigBear.ai（BBAI） 米国株ハイボラティリティ 2023-01 +385.2% +385.2% 昆仑万維（300418.SZ） A株ハイボラティリティ 2023-01 +35.2% +35.2% 微软宣布扩大与 OpenAI 的合作。 合作把模型能力、Azure 算力和办公软件放到同一条商业链上，AI 从独立产品开始进入云和生产力软件。Microsoft：延長與 OpenAI 的合作 今月の結論: クローズドソースモデルの優位性は、パラメータ規模からクラウド、配布、企業向け契約、継続的なサービスへと拡大している。\n2月：BardとLLaMAの分岐（688256.SS +121.4%） 市場記録： ChatGPTとBardの競争により、AIの物語が初めて株式市場に集中して反映され、ナスダックのハイテク銘柄が上昇した。C3.ai、BigBear.aiなどの小型時価総額の中核銘柄が最初の「妖股」となり、値動きは感情と出来高によって主に動かされた。\n妖股累計表（2023年2月まで、月末権利調整後終値の複合；エヌビディアを筆頭銘柄として対照）\n銘柄（コード） タイプ 組み入れ月 当月の騰落率 組み入れ後累計 エヌビディア（NVDA） 中核銘柄（比較基準） 2022-11 +18.8% +72.1% C3.ai（AI） 米株（高ボラティリティ） 2023-01 +13.8% +101.9% BigBear.ai（BBAI） 米株（高ボラティリティ） 2023-01 -10.1% +336.2% 崑崙万維（300418.SZ） A株（高ボラティリティ） 2023-01 +110.7% +184.9% SoundHound AI（SOUN） 米株（高ボラティリティ） 2023-02 +50.3% +50.3% 新易盛（300502.SZ） A株（高ボラティリティ） 2023-02 +50.7% +50.7% 寒武紀（688256.SS） A株（高ボラティリティ） 2023-02 +121.4% +121.4% 工業富聯（601138.SS） A株（高ボラティリティ） 2023-02 +79.4% +79.4% Google が Bard を公開。 検索企業が ChatGPT に正面から対抗し始め、生成系 AI は検索エントリーの競争に突入した。Google：Bard と検索のアップデート Meta が研究用モデル LLaMA を発表。 小型モデル、公開研究、コミュニティによる再現を通じて、オープンなモデルエコシステムの重要な出発点を提供した。Meta：Introducing LLaMA 今月の判断： 同じ競争が二つの道に分かれている。一つは安定したクラウドゲートウェイの獲得、もう一つは開発者・ウェイト・オンプレミス展開権の獲得を巡る争いである。\n3月：GPT-4 がツールとの接続を開始（300308.SZ +52.8%） 市況メモ： 銀行リスクのショック下にもかかわらず、資金は大型テック株や計算インフラへ集中し、NVIDIA が GTC を前後に主役となった。A 株では、360（サンリョウ）、iFlytek（科大訊飛）、Cambricon（寒武紀）、Inspur（浪潮信息）に明確な ChatGPT コンセプトの変動が見られた。\n怪物株累計表（2023年3月まで、月末権利調整後終値の複合；エヌビディアをリーダー对照）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核銘柄対照 2022-11 +19.7% +106.0% C3.ai（AI） 米株高ボラティリティ 2023-01 +48.7% +200.2% BigBear.ai（BBAI） 米株高ボラティリティ 2023-01 -17.0% +262.0% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 +39.3% +296.8% SoundHound AI（SOUN） 米株高ボラティリティ 2023-02 -7.7% +38.7% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 +42.2% +114.3% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 +34.2% +197.1% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 -6.4% +67.9% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 +52.8% +52.8% 3月14日、ChatGPT Plus向けにGPT-4が公開された。 議論の焦点は「書けるかどうか」から、複雑な指示・コード・推論・専門的なタスクへと移った。OpenAI：GPT-4 research 3月23日、ChatGPTがプラグインの実験提供を開始した。 ブラウジング、コードインタープリター、第三者プラグインにより、モデルは単なる回答者からツール呼び出し側へと進化した。ChatGPT リリースノート 今月の判断： モデル能力の価値は、最新情報、計算環境、外部サービスにアクセスできるかどうかに依存し始めている。\n4月：Google DeepMindの合併（300476.SZ +52.8%） 市場の記録： 米株のAIリーダー銘柄は高値圏で揉み合い、中国A株は全面高からテーマ物色へ切り替わり、iFlytek（科大訊飛）、Kunlun Tech（崑崙万維）、360（奇虎360）などの応用関連銘柄の値幅は非常に大きい。「妖株」はモデル会社から演算力や応用チェーンへ拡大し始めている。\n怪物株累計表（2023年4月まで、月末復権終値の複合；エヌビディアをリーディング銘柄として対照）\n銘柄（コード） タイプ 表入り月 今月騰落率 表入り後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 -0.1% +105.8% C3.ai（AI） 米国株高ボラティリティ 2023-01 -46.9% +59.4% BigBear.ai（BBAI） 米国株高ボラティリティ 2023-01 +18.9% +330.5% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 -12.0% +249.2% SoundHound AI（SOUN） 米国株高ボラティリティ 2023-02 -3.6% +33.7% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 +22.4% +162.3% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 +1.9% +202.8% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 +12.0% +88.1% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 +19.4% +82.4% 勝宏科技（300476.SZ） A株高ボラティリティ 2023-04 +52.8% +52.8% Google が Google Brain と DeepMind を統合し、Google DeepMind を設立。 研究チーム、計算能力、製品ロードマップが一つの組織に集約され、Google は次世代マルチモーダルモデルを中核方針として明確に位置づけた。Google：Google DeepMind の設立 今月の見解： モデルの競争は単なる研究のブレークスルーだけでなく、人材、計算能力、製品ディストリビューションを組織化することも必要である。\n5月：ロングコンテキストがGPU注文と出会う（SMCI +112.4%） 市場記録： Nvidiaの決算報告がAI受注を市場全体の価格シグナルに変え、5月25日の株価は1日で約24%上昇し、Nvidia、AMD、Broadcom、およびA株の光モジュール関連チェーンがともに追捧された。これは真にグローバルな拡散効果を持つ最初のAI相場である。\nゴーストストック累計表（2023年5月まで、月末復権終値複合；エヌビディアをリーダー対照）\n対象銘柄（コード） タイプ 採用月 当月の騰落率 採用後累計 エヌビディア（NVDA） 中核銘柄（基準） 2022-11 +36.3% +180.5% C3.ai（AI） 米株ハイボラ 2023-01 +124.5% +257.9% BigBear.ai（BBAI） 米株ハイボラ 2023-01 -23.8% +228.0% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -29.8% +145.1% SoundHound AI（SOUN） 米株ハイボラ 2023-02 +14.7% +53.4% 新易盛（300502.SZ） A株ハイボラ 2023-02 +13.0% +196.4% 寒武紀（688256.SS） A株ハイボラ 2023-02 -26.0% +124.0% 工業富聯（601138.SS） A株ハイボラ 2023-02 +39.6% +162.5% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +37.3% +150.5% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -13.9% +31.6% Super Micro Computer（SMCI） 米株ハイボラ 2023-05 +112.4% +112.4% Palantir（PLTR） 米株ハイボラ 2023-05 +89.8% +89.8% Marvell（MRVL） 米株ハイボラ 2023-05 +48.2% +48.2% Anthropic が 100K コンテキストウィンドウを発表。 ロングドキュメント、契約、コードリポジトリがモデルの入力となり、ロングコンテキストが研究の指標から企業向け製品の売り点へと変わり始めた。Anthropic：100K Context Windows エヌビディア決算により AI 期待が GPU 受注に転換。 2024 会計年度第 1 四半期のデータセンター事業と次四半期の見通しが市場予想を大きく上回り、市場は AI に対しコンピュート、ネットワーク、データセンターという軸で価格をつけ始めた。NVIDIA：FY2024 Q1 決算 今月の判断: インフラの上流レイヤーは実際の注文を比較的早期に獲得できるが、アプリケーション層の収益・継続率・利益ははるかに遅れて現れる。コンテキストが長くなるほど、出所・権限・検証がより重要になる。\n6月：APIが関数の呼び出しを開始（SOUN +49.2%） 市場の記録： 米株は引き続き「シャベルを売る」テーマで価格形成されており、エヌビディア、Super Micro Computer、ネットワーク機器株が上昇している。A株ではコンピューティングパワー、光モジュール、サーバーの間で資本のローテーションが見られ、C3.aiのような純粋なコンセプト株のボラティリティはリーダー銘柄よりも明らかに大きい。\n怪物株累計表（2023年6月まで、月末復権終値の複合；エヌビディアをリーダーとして対照）\n銘柄（コード） タイプ 表入り月 今月の騰落率 表入り後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +11.8% +213.6% C3.ai（AI） 米国株ハイボラ 2023-01 -8.9% +226.0% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 +6.3% +248.7% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -8.0% +125.5% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 +49.2% +128.9% 新易盛（300502.SZ） A株ハイボラ 2023-02 -23.6% +126.4% 寒武紀（688256.SS） A株ハイボラ 2023-02 -12.8% +95.4% 工業富聯（601138.SS） A株ハイボラ 2023-02 -9.2% +138.4% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -13.2% +117.4% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -6.3% +23.3% スーパーマイクロ（SMCI） 米国株ハイボラ 2023-05 +11.3% +136.4% Palantir（PLTR） 米国株ハイボラ 2023-05 +4.2% +97.8% Marvell（MRVL） 米国株ハイボラ 2023-05 +2.2% +51.5% OpenAIがAPIにfunction calling、長文コンテキスト、より低い価格を追加。 開発者はモデルにJSON Schemaで関数のパラメータを出力させることができるようになり、モデルと外部ツールの接続がオーケストレーション可能になり始めた。OpenAI：Function calling and other API updates 今月の判断： ツール呼び出しの要点は、モデルが「お手伝いできます」と言うかどうかではなく、実行可能で検証可能な構造化結果を安定して生み出せるかどうかである。\n7月：オープンウェイトモデルとクローズドソースモデルが並行して進展（SMCI +32.5%） 市場記録： 米株AIリーダー銘柄は一方向の上昇から高値圏での消化局面に移行し、A株・香港株のAI取引はテーマのローテーションに依存している。エヌビディア、AMD、光モジュール、サーバー関連株が依然として中心であり、板块から持続的に独立して上昇する新たな妖怪株は現時点では出現していない。\n怪物株累計表（2023年7月まで、月末権利調整後終値の複合；エヌビディアを先導株として対照）\n銘柄（コード） タイプ 組入月 今月の騰落率 組入後累計 エヌビディア（NVDA） 中核リーダー比較対象 2022-11 +10.5% +246.5% C3.ai（AI） 米国株ハイボラ 2023-01 +15.3% +275.9% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 -14.5% +198.1% 昆侖万維（300418.SZ） A株ハイボラ 2023-01 -2.3% +120.3% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 -48.8% +17.2% 新易盛（300502.SZ） A株ハイボラ 2023-02 -12.2% +98.8% 寒武紀（688256.SS） A株ハイボラ 2023-02 -3.2% +89.1% 工業富聯（601138.SS） A株ハイボラ 2023-02 -1.9% +133.9% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -10.5% +94.6% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -2.3% +20.4% スーパーマイクロ（SMCI） 米国株ハイボラ 2023-05 +32.5% +213.2% Palantir（PLTR） 米国株ハイボラ 2023-05 +29.4% +155.9% Marvell（MRVL） 米国株ハイボラ 2023-05 +9.1% +65.2% MetaとMicrosoftがLlama 2を公開。 モデルの重み、初期コード、商用利用条件がより広く解放され、開発者はクラウド上またはローカルで独自のアプリケーションを構築できるようになった。Meta：Llama 2 AnthropicがClaude 2を公開。 より長い入力、コード、推論能力により、クローズドソースモデル間の競争はチャット体験から長文ドキュメントや開発者向けAPIへと広がった。Anthropic：Claude 2 今月の見解： 「オープンソース」が業界スローガンになりつつありますが、デプロイメントに本当に影響を与えるのは、ライセンス、重み、VRAM、推論速度、保守責任です。\n8月：Code Llamaがコードの入り口を制す（000158.SZ +26.2%） 市場の記録： NVIDIAの決算期待が引き続きコンピュート関連銘柄を支えているが、高バリュエーションのAI小型株には分化が見られる。NVIDIAとAMDは多くのソフトウェア関連銘柄よりも強く、市場は「AI関連なら何でも上がる」から、実際の受注を持つ銘柄を探す方向へとシフトしている。\n妖股累計表（2023年08月末まで、月末調整後終値の複合；エヌビディアをリード銘柄として対照）\n銘柄（コード） 種別 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） コア銘柄対照 2022-11 +5.6% +265.9% C3.ai（AI） 米国株ハイボラ 2023-01 -26.1% +177.8% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 -18.4% +143.3% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +6.0% +133.6% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 +8.2% +26.8% 新易盛（300502.SZ） A株ハイボラ 2023-02 +0.9% +100.6% 寒武紀（688256.SS） A株ハイボラ 2023-02 -21.9% +47.7% 工業富聯（601138.SS） A株ハイボラ 2023-02 -10.1% +110.2% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +1.0% +96.5% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +1.4% +22.1% スーパーマイクロ（SMCI） 米国株ハイボラ 2023-05 -16.7% +160.9% Palantir（PLTR） 米国株ハイボラ 2023-05 -24.5% +93.2% Marvell（MRVL） 米国株ハイボラ 2023-05 -10.6% +47.7% 常山北明（000158.SZ） A株ハイボラ 2023-08 +26.2% +26.2% MetaがCode Llamaを発表。 オープンソースモデルはコード生成・補完・ローカル開発用途で本格的な競争を開始。Meta：Code Llama 今月の判断： coding が最初に有料化の境界線となったのは、コード系のタスクにはテスト・提出・成果物の納品が伴い、汎用チャットと比べて価値の検収が容易であるためである。\n9月：ChatGPTがマルチモーダルに対応（000158.SZ +21.9%） 市況メモ： 米株の長債金利が上昇し、AI セクターは主導株が高値から反落したが、エヌビディアは依然として相対的に強い中心銘柄である。A 株ではテーマ性のある応用株への熱狂が冷え込み、新たな持続的な材料株は形成されていない。\n妖股累計表（2023年9月まで、月末復権終値の複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 採用月 当月騰落率 採用後累計 エヌビディア（NVDA） コアリーダー対照 2022-11 -11.9% +222.4% C3.ai（AI） 米国株ハイボラ 2023-01 -17.7% +128.6% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 -7.9% +124.0% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -17.8% +92.0% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 -20.2% +1.2% 新易盛（300502.SZ） A株ハイボラ 2023-02 -31.8% +36.8% 寒武紀（688256.SS） A株ハイボラ 2023-02 -13.5% +27.8% 工業富聯（601138.SS） A株ハイボラ 2023-02 -25.3% +57.0% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -24.2% +49.0% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -9.2% +10.9% スーパーマイクロ・コンピュータ（SMCI） 米国株ハイボラ 2023-05 -0.3% +160.1% Palantir（PLTR） 米国株ハイボラ 2023-05 +6.8% +106.4% Marvell（MRVL） 米国株ハイボラ 2023-05 -7.1% +37.2% 常山北明（000158.SZ） A株ハイボラ 2023-08 +21.9% +53.8% OpenAIが画像理解、音声、画像会話をChatGPTに導入。 テキストモデルがマルチモーダルな作業の入り口になりつつある。OpenAI：ChatGPTの画像と音声のアップデート 今月の判断： モデルが処理する対象はテキストからスクリーンショット、会議の議事録、ファイルへと拡張されましたが、材料を読めることは、材料が本物であることを知ることとは異なります。\n10月：画像生成が対話へ進出（300502.SZ +47.5%） 市場の記録： 米国のテクノロジー株は、金利と輸出規制への予想によって引き続き圧迫されており、AI関連大手株はもみ合いながら軟調に推移している。A株（中国のA株市場）では演算能力関連株と応用株が交互に反発しており、行情は短線的なテーマ投資の様相を呈し、新たなグローバルAI銘柄はまだ出現していない。\nモンスター株累計表（2023年10月まで、月末復権終値の合成；エヌビディアをリーダーの対照として）\n銘柄（コード） タイプ 表掲載月 今月の騰落率 掲載後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 -6.3% +202.1% C3.ai（AI） 米国株（高ボラティリティ） 2023-01 -4.4% +118.6% BigBear.ai（BBAI） 米国株（高ボラティリティ） 2023-01 -15.9% +88.4% 崑崙万維（300418.SZ） A株（高ボラティリティ） 2023-01 +2.6% +97.0% SoundHound AI（SOUN） 米国株（高ボラティリティ） 2023-02 -20.9% -20.0% 新易盛（300502.SZ） A株（高ボラティリティ） 2023-02 +47.5% +101.8% 寒武紀（688256.SS） A株（高ボラティリティ） 2023-02 +39.7% +78.5% 工業富聯（601138.SS） A株（高ボラティリティ） 2023-02 +2.6% +61.1% 中際旭創（300308.SZ） A株（高ボラティリティ） 2023-03 +8.2% +61.2% 勝宏科技（300476.SZ） A株（高ボラティリティ） 2023-04 -5.1% +5.2% スーパーマイクロ（SMCI） 米国株（高ボラティリティ） 2023-05 -12.7% +127.1% Palantir（PLTR） 米国株（高ボラティリティ） 2023-05 -7.5% +90.9% Marvell（MRVL） 米国株（高ボラティリティ） 2023-05 -12.7% +19.8% 常山北明（000158.SZ） A株（高ボラティリティ） 2023-08 -11.0% +36.9% DALL·E 3 が ChatGPT Plus および Enterprise に導入。 画像生成は独立したプロンプトツールから対話的な編集ワークフローへと移行し、同時に生成コンテンツを識別するためのソース分類器の試験運用が開始されました。OpenAI：DALL·E 3 今月の判断： AIGCの競争は、ワンショット生成から、反復、著作権、出典、信頼性へと移行し始めている。\n11月：DevDay とガバナンス危機（PLTR +35.5%） 市場記録： 米株 AI 銘柄が決算報告と OpenAI のガバナンス危機の中で再び上昇し、マイクロソフト、エヌビディア、AMD の確実性は小型株よりも高い。A 股 AI 取引は回復しているが、基本面から長期的に切り離される新たなコンセプト銘柄は出現していない。\n怪物株累計表（2023年11月まで、月末復権終値の複合；エヌビディアをトップ銘柄として対照）\n銘柄（コード） タイプ 追加月 今月の騰落率 追加後累計 エヌビディア（NVDA） コア銘柄（参考） 2022-11 +14.7% +246.5% C3.ai（AI） 米株ハイボラ 2023-01 +19.3% +160.7% BigBear.ai（BBAI） 米株ハイボラ 2023-01 +33.9% +152.3% 昆仑万維（300418.SZ） A株ハイボラ 2023-01 +15.6% +127.7% SoundHound AI（SOUN） 米株ハイボラ 2023-02 +34.6% +7.7% 新易盛（300502.SZ） A株ハイボラ 2023-02 +6.5% +114.9% 寒武紀（688256.SS） A株ハイボラ 2023-02 -9.9% +60.8% 工業富聯（601138.SS） A株ハイボラ 2023-02 +0.1% +61.3% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +19.0% +91.8% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -4.2% +0.8% スーパーマイクロ（SMCI） 米株ハイボラ 2023-05 +14.2% +159.3% Palantir（PLTR） 米株ハイボラ 2023-05 +35.5% +158.6% Marvell（MRVL） 米株ハイボラ 2023-05 +18.0% +41.4% 常山北明（000158.SZ） A株ハイボラ 2023-08 -8.4% +25.4% Arm（ARM） 米株ハイボラ 2023-11 +24.8% +24.8% OpenAI DevDay が GPT-4 Turbo、Assistants API、視覚機能、および価格引き下げを発表。 API、検索、関数呼び出し、そしてアシスタントフレームワークにより、モデルがアプリケーションへさらに組み込まれるようになりました。OpenAI：DevDay で発表された新モデルと開発者向け製品 OpenAI 取締役会が Sam Altman を突然解任し、その後復帰させる。 わずか1週間で起きたガバナンス危機により、モデル企業におけるガバナンス、株主との関係、そして人材依存が業界の現実として顕在化しました。OpenAI：Sam Altman が CEO に復帰し、新たな初期取締役会が発足 今月の評価： モデル会社の製品リスクに加え、取締役会、コア人材、資本、パートナーに関するリスクがある。\n12月：Geminiがマルチモーダルを製品に導入（BBAI +25.9%） 市場の記録： 米株の AI 先導銘柄が年初来高値圏に迫り、NVIDIA が年間で最も明確な「シャベル売り」のメインテーマとなっている。A 株と香港株は依然として構造的な相場であり、サーバーや光モジュールは純粋なアプリケーションコンセプトよりも資金を集めやすい。\n妖怪株累計表（2023年12月まで、月末権利調整後終値の複合；エヌビディアをリーダー对照として）\n銘柄（コード） タイプ 掲載月 今月騰落率 掲載後累計 エヌビディア（NVDA） 中核リーダー比較対象 2022-11 +5.9% +266.9% C3.ai（AI） 米国株高ボラティリティ 2023-01 -1.4% +157.1% BigBear.ai（BBAI） 米国株高ボラティリティ 2023-01 +25.9% +217.6% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 -20.7% +80.6% SoundHound AI（SOUN） 米国株高ボラティリティ 2023-02 -0.9% +6.7% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 -14.0% +84.8% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 -18.5% +31.1% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 -12.0% +41.9% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 -9.0% +74.6% 勝宏科技（300476.SZ） A株高ボラティリティ 2023-04 -19.6% -18.9% スーパーマイクロ・コンピュータ（SMCI） 米国株高ボラティリティ 2023-05 +3.9% +169.5% Palantir（PLTR） 米国株高ボラティリティ 2023-05 -14.4% +121.4% Marvell（MRVL） 米国株高ボラティリティ 2023-05 +8.2% +53.0% 常山北明（000158.SZ） A株高ボラティリティ 2023-08 -11.7% +10.7% Arm（ARM） 米国株高ボラティリティ 2023-11 +22.2% +52.5% Google が Gemini 1.0 を発表。 Gemini は最初から Ultra、Pro、Nano に階層化され、クラウド、アプリケーション、デバイス側をカバーし、ネイティブマルチモーダルを強調している。Google：Introducing Gemini 今月の判断： モデル競争は、単一の Web チャット入口を巡る争いではなく、検索、モバイル、クラウド、開発者ツールを同時に巡る争いへと進化している。\n2024 年: マルチモーダル、推論、エージェントが製品へ導入される 1月：GPTストアがアシスタントの配信を試行（SMCI +86.3%） 市場記録： 2024年の幕開けは引き続き米国株の半導体セクターが牽引しており、エヌビディア、AMD、ブロードコム、Arm、Super Micro Computerが高い弾性銘柄となっている。A株AIは序盤強くもその後分化しており、全市場統一の妖株はまだ出現していない。\nゴッドストック累計表（2024年1月まで、月末権利調整後終値の複合；エヌビディアをリーダー銘柄として対照）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +24.2% +355.7% C3.ai（AI） 米国株・ハイボラティリティ 2023-01 -13.7% +121.9% BigBear.ai（BBAI） 米国株・ハイボラティリティ 2023-01 -24.3% +140.5% 崑崙万維（300418.SZ） A株・ハイボラティリティ 2023-01 +36.1% +145.8% SoundHound AI（SOUN） 米国株・ハイボラティリティ 2023-02 -21.7% -16.4% 新易盛（300502.SZ） A株・ハイボラティリティ 2023-02 +41.6% +161.7% 寒武紀（688256.SS） A株・ハイボラティリティ 2023-02 +53.3% +100.9% 工業富聯（601138.SS） A株・ハイボラティリティ 2023-02 +40.4% +99.3% 中際旭創（300308.SZ） A株・ハイボラティリティ 2023-03 +50.9% +163.4% 勝宏科技（300476.SZ） A株・ハイボラティリティ 2023-04 +46.4% +18.7% スーパーマイクロ・コンピュータ（SMCI） 米国株・ハイボラティリティ 2023-05 +86.3% +402.0% Palantir（PLTR） 米国株・ハイボラティリティ 2023-05 -6.3% +107.4% Marvell（MRVL） 米国株・ハイボラティリティ 2023-05 +12.4% +71.9% 常山北明（000158.SZ） A株・ハイボラティリティ 2023-08 +8.7% +20.4% Arm（ARM） 米国株・ハイボラティリティ 2023-11 -6.0% +43.4% OpenAI が GPT Store を公開。 ユーザーがカスタマイズした GPT を公開・発見できるようになり、モデルプラットフォームはプロンプト、知識ベース、ツールを組み合わせて配布可能なソフトウェアユニットにする取り組みを開始した。OpenAI：Introducing the GPT Store 今月の判断： プラットフォーム化の難しさは、「アシスタントを作れるかどうか」から、発見・配信・権限・継続利用へと移っている。\n2月：Sora と長文コンテキスト競争（SOUN +347.0%） 市場の記録： NVIDIAの決算とAIサーバー受注が相場を加速局面に押し上げ、Super Micro Computer、Arm、SoundHoundなどのボラティリティの高い銘柄が次々と「妖怪株」となった。A株市場では光モジュール、サーバー、コンピューティングパワーレンタルも明らかに活発化した。\n妖股累計表（2024年2月まで、月末復権終値複合；エヌビディアを先導対照として）\n銘柄（コード） タイプ 表入り月 当月騰落率 表入り後累計 エヌビディア（NVDA） コア銘柄対照 2022-11 +28.6% +486.0% C3.ai（AI） 米国株ハイボラ 2023-01 +49.2% +231.0% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 +107.4% +398.7% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -1.3% +142.6% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 +347.0% +273.6% 新易盛（300502.SZ） A株ハイボラ 2023-02 +11.6% +192.1% 寒武紀（688256.SS） A株ハイボラ 2023-02 +2.8% +106.5% 工業富聯（601138.SS） A株ハイボラ 2023-02 +21.8% +142.7% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +0.9% +165.8% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +11.5% +32.3% スーパーマイクロ（SMCI） 米国株ハイボラ 2023-05 +63.5% +720.8% Palantir（PLTR） 米国株ハイボラ 2023-05 +55.9% +223.4% Marvell（MRVL） 米国株ハイボラ 2023-05 +5.8% +81.9% 常山北明（000158.SZ） A株ハイボラ 2023-08 -6.5% +12.6% Arm（ARM） 米国株ハイボラ 2023-11 +99.6% +186.1% OpenAI が Sora 研究プレビューを公開。 テキストから動画を生成するモデルは、生成モデル競争の時間的一貫性、物理世界シミュレーション、動画出所検証という新たな次元を切り開いた。OpenAI：Sora Google が Gemini 1.5 を発表、長コンテキストと MoE アーキテクチャを強調。 モデルがより長い動画、コードベース、複数ドキュメントの入力を処理し始めた。Google：Gemini 1.5 今月の見解： マルチモーダルの次の敷居は、綺麗な1フレームを生成することではなく、長時間かつ長文脈における一貫性を維持することにある。\n3月：モデルが能力別に階層化を開始（300502.SZ +29.1%） 市場の記録： GTCとエヌビディアの新世代コンピューティング（算力）に関するナラティブが引き続き半導体セメントを押し上げており、エヌビディア（NVIDIA）、スーパーマイクロ（Super Micro Computer）、Arm、およびサーバーチェーンは高水準での持ち高の入れ替えが行われている。A株ではCambricon（寒武紀）、Industrial Fulian（工業富聯）、Zhongji Innolight（中際旭創）といった高ベータの銘柄でボラティリティが顕著となっている。\n妖怪株累計表（2024年3月まで、月末復権終値の複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核銘柄（比較対象） 2022-11 +14.2% +569.2% C3.ai（AI） 米国株（高ボラティリティ） 2023-01 -26.8% +142.3% BigBear.ai（BBAI） 米国株（高ボラティリティ） 2023-01 -39.0% +204.2% 昆仑万維（300418.SZ） A株（高ボラティリティ） 2023-01 +0.3% +143.3% SoundHound AI（SOUN） 米国株（高ボラティリティ） 2023-02 -20.6% +196.7% 新易盛（300502.SZ） A株（高ボラティリティ） 2023-02 +29.1% +277.1% 寒武紀（688256.SS） A株（高ボラティリティ） 2023-02 -1.2% +104.1% 工業富聯（601138.SS） A株（高ボラティリティ） 2023-02 +7.6% +161.2% 中際旭創（300308.SZ） A株（高ボラティリティ） 2023-03 +19.0% +216.3% 勝宏科技（300476.SZ） A株（高ボラティリティ） 2023-04 +22.5% +62.1% スーパーマイクロ（SMCI） 米国株（高ボラティリティ） 2023-05 +16.6% +857.0% Palantir（PLTR） 米国株（高ボラティリティ） 2023-05 -8.3% +196.6% Marvell（MRVL） 米国株（高ボラティリティ） 2023-05 -1.1% +79.9% 常山北明（000158.SZ） A株（高ボラティリティ） 2023-08 -4.5% +7.5% Arm（ARM） 米国株（高ボラティリティ） 2023-11 -11.4% +153.5% Anthropic が Claude 3 シリーズを発表。 Opus、Sonnet、Haiku が異なる能力、速度、コストでエンタープライズ API をカバーし、モデルの選択がルーティング問題になり始めた。Anthropic：Claude 3 family 今月の結論： 「最強モデル」が唯一の答えではなくなり、レイテンシ、価格、タスクの難易度も同様に製品の実用性を決定づける要素となっている。\n4月：Llama 3がオープンエコシステムを拡大（300308.SZ -39.7%） 市場の動き： 金利上昇と決算発表シーズンを控えて警戒感が強まり、米株市場のAI銘柄には利確売りが広がりました。スーパーマイクロや一部の高PER中小型株の下落が目立ちています。A株市場でもAIテーマ株が同時に冷却感を強め、投機的な\u0026quot;妖怪株\u0026quot;相場は一服しています。\n妖股累計表（2024年4月まで、月末復権終値複合；エヌビディアを筆頭銘柄として対照）\n銘柄（コード） タイプ 採用月 今月の騰落率 採用後累計騰落率 エヌビディア（NVDA） 中核銘柄（対照） 2022-11 -4.4% +539.8% C3.ai（AI） 米国株（高ボラティリティ） 2023-01 -16.8% +101.6% BigBear.ai（BBAI） 米国株（高ボラティリティ） 2023-01 -19.0% +146.4% 崑崙万維（300418.SZ） A株（高ボラティリティ） 2023-01 -12.7% +112.4% SoundHound AI（SOUN） 米国株（高ボラティリティ） 2023-02 -28.0% +113.6% 新易盛（300502.SZ） A株（高ボラティリティ） 2023-02 +0.3% +278.2% 寒武紀（688256.SS） A株（高ボラティリティ） 2023-02 +2.0% +108.1% 工業富聯（601138.SS） A株（高ボラティリティ） 2023-02 -6.5% +144.2% 中際旭創（300308.SZ） A株（高ボラティリティ） 2023-03 -39.7% +90.7% 勝宏科技（300476.SZ） A株（高ボラティリティ） 2023-04 -7.9% +49.3% スーパーマイクロ（SMCI） 米国株（高ボラティリティ） 2023-05 -15.0% +713.5% Palantir（PLTR） 米国株（高ボラティリティ） 2023-05 -4.5% +183.2% Marvell（MRVL） 米国株（高ボラティリティ） 2023-05 -6.9% +67.5% 常山北明（000158.SZ） A株（高ボラティリティ） 2023-08 -5.0% +2.1% Arm（ARM） 米国株（高ボラティリティ） 2023-11 -19.0% +105.3% Meta が Llama 3 を発表。 8B モデルと 70B モデルがコミュニティに公開され、学習データの規模、ツールチェーン、クラウドパートナーが同時に拡大されました。Meta：Llama 3 今月の見解： オープウェイトのモデルは、研究目的の代替手段から完全なエコシステムへと移行しつつあり、デプロイ側はコストとデータの境界をコントロール権と交換できるようになってきている。\n5月：GPT-4oがリアルタイム対話を実現（NVDA +26.9%） 市場の記録： NVIDIAの決算報告が再びAI設備投資を確証し、NVIDIA、Dell、AMD、TSMC関連銘柄が上昇。中国A株の光モジュールおよびサーバー関連チェーンも追随し、資金は再び受注を確認できる「ハードウェア材料株」へと傾いた。\n妖股累計表（2024年5月まで、月末権利調整後終値の複合；エヌビディアをリーディング銘柄として対照）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計騰落率 エヌビディア（NVDA） コア銘柄（参考） 2022-11 +26.9% +711.9% C3.ai（AI） 米株・ハイボラ 2023-01 +31.2% +164.5% BigBear.ai（BBAI） 米株・ハイボラ 2023-01 -9.6% +122.8% 崑崙万維（300418.SZ） A株・ハイボラ 2023-01 -7.5% +96.5% SoundHound AI（SOUN） 米株・ハイボラ 2023-02 +19.1% +154.4% 新易盛（300502.SZ） A株・ハイボラ 2023-02 +21.7% +360.3% 寒武紀（688256.SS） A株・ハイボラ 2023-02 +13.7% +136.7% 工業富聯（601138.SS） A株・ハイボラ 2023-02 +19.6% +192.1% 中際旭創（300308.SZ） A株・ハイボラ 2023-03 +23.1% +134.8% 勝宏科技（300476.SZ） A株・ハイボラ 2023-04 +18.7% +77.2% スーパーマイクロ（SMCI） 米株・ハイボラ 2023-05 -8.7% +642.7% Palantir（PLTR） 米株・ハイボラ 2023-05 -1.3% +179.5% Marvell（MRVL） 米株・ハイボラ 2023-05 +4.4% +74.9% 常山北明（000158.SZ） A株・ハイボラ 2023-08 -8.6% -6.7% Arm（ARM） 米株・ハイボラ 2023-11 +19.1% +144.6% OpenAI が GPT-4o を発表。 テキスト・視覚・音声の機能を単一のより高速なモデルに統合し、リアルタイム音声インタラクションが製品の中核となった。OpenAI：GPT-4o 今月の判断： マルチモーダルは単なるファイルアップロードではなくなり、リアルタイムインタラクションがスマートフォン、カスタマーサービス、オフィスの入口を巡って競合し始めている。\n6月：AIがデバイスとワークフローへ進出（ARM +35.8%） 市場記録： NVIDIAは6月に一時的に世界時価総額最高的企業となり、株式分割とインデックスファンドにより注目度がさらに高まった。A株市場では、中際旭創、新易盛、工業富聯などのコンピューティングチェーンが多くの応用株よりも強く、NVIDIAがこの段階で最も典型的なAIリーダーとなっている。\n妖股累計表（2024-06 まで、月末復権終値複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 採用月 今月の騰落率 採用後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +12.7% +815.0% C3.ai（AI） 米国株ハイボラ 2023-01 -2.1% +158.9% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 +0.7% +124.3% 昆仑万維（300418.SZ） A株ハイボラ 2023-01 -6.5% +83.7% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 -21.8% +98.9% 新易盛（300502.SZ） A株ハイボラ 2023-02 -5.3% +335.9% 寒武紀（688256.SS） A株ハイボラ 2023-02 +32.9% +214.5% 工業富聯（601138.SS） A株ハイボラ 2023-02 -13.0% +154.1% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -6.1% +120.5% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +19.5% +111.7% スーパーマイクロ・コンピュータ（SMCI） 米国株ハイボラ 2023-05 +4.4% +675.4% Palantir（PLTR） 米国株ハイボラ 2023-05 +16.8% +226.5% Marvell（MRVL） 米国株ハイボラ 2023-05 +1.6% +77.7% 常山北明（000158.SZ） A株ハイボラ 2023-08 -0.3% -6.9% Arm（ARM） 米国株ハイボラ 2023-11 +35.8% +232.1% Apple が Apple Intelligence を発表。 オンデバイスモデル、パーソナルコンテキスト、Private Cloud Compute、ChatGPT 連携が iPhone、iPad、Mac のシステム体験に組み込まれた。Apple：Apple Intelligence Anthropic が Claude 3.5 Sonnet を発表。 コーディング、視覚、ツール利用におけるモデルの改善により、コーディングおよび Agent タスクがクローズドソースモデル競争の中心に押し上げられた。Anthropic：Claude 3.5 Sonnet 今月の判断： AI は「ウェブサイトを開く」からデバイスやワークフローへと移行し始め、プライバシー、権限、レイテンシも体験の一部となりつつある。\n7月：大規模モデルの低コストルーティングへの転換（SOUN +28.9%） 市場記録： 市場は大型ハイテク株から小型株や非AIセクターへとローテーションし、エヌビディアやスーパー・マイクロ・コンピューターなどは上昇後に調整；A株の計算能力関連株は高値圏で保ち合い、思惑株の特性は「連続上昇」から「高ボラティリティ・高速ローテーション」へと変化した。\n妖股累計表（2024年7月末まで、月末復権終値複合；エヌビディアをリーディング銘柄として対照）\n銘柄（コード） 種別 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） コア銘柄（参照） 2022-11 -5.3% +766.5% C3.ai（AI） 米株ハイボラ 2023-01 -7.6% +139.3% BigBear.ai（BBAI） 米株ハイボラ 2023-01 +0.0% +124.3% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -9.9% +65.5% SoundHound AI（SOUN） 米株ハイボラ 2023-02 +28.9% +156.4% 新易盛（300502.SZ） A株ハイボラ 2023-02 -6.0% +309.7% 寒武紀（688256.SS） A株ハイボラ 2023-02 -2.8% +205.7% 工業富聯（601138.SS） A株ハイボラ 2023-02 -11.7% +124.4% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -15.9% +85.4% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -12.3% +85.7% スーパーマイクロ（SMCI） 米株ハイボラ 2023-05 -14.4% +563.7% Palantir（PLTR） 米株ハイボラ 2023-05 +6.2% +246.7% Marvell（MRVL） 米株ハイボラ 2023-05 -4.1% +70.4% 常山北明（000158.SZ） A株ハイボラ 2023-08 +21.9% +13.4% Arm（ARM） 米株ハイボラ 2023-11 -11.9% +192.6% MetaがLlama 3.1 405Bを公開。 オープンウェイトモデルが最先端のクローズドソースモデルと直接対抗し、長文コンテキストとAgent向け参照システムも提供。Meta：Llama 3.1 OpenAIがGPT-4o miniを公開。 より小型で安価なモデルにより、簡易タスクのローカル実行やバッチ処理が進み、モデルルーティングの経済性が明確化。OpenAI：GPT-4o mini 今月の見解： AI 製品のユニットエコノミクスは、最強のモデルだけに依存するわけではない。低コストモデルが大量のシンプルなタスクを処理することで、初めて API 呼び出しを長期的な予算に転換できる可能性がある。\n8月：AI Act施行（000158.SZ +69.3%） マーケットメモ： 円キャリートレードの巻き戻しにより世界のハイテク株が急落した後、急速に戻りをつけ、NVIDIA と Super Micro Computer の値幅が再び拡大した。A 股の AI 関連は引き続きローテーションが主軸であり、新たな単一の妖株（テーマ株）は形成されていない。\n妖股累計表（2024年8月まで、月末権利調整後終値の合成；エヌビディアをリーダー対照とする）\n銘柄（コード） 種別 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核銘柄（比較対象） 2022-11 +2.0% +783.9% C3.ai（AI） 米国株（高ボラ） 2023-01 -12.7% +108.9% BigBear.ai（BBAI） 米国株（高ボラ） 2023-01 +5.3% +136.2% 崑崙万維（300418.SZ） A株（高ボラ） 2023-01 +38.3% +128.9% SoundHound AI（SOUN） 米国株（高ボラ） 2023-02 -3.9% +146.4% 新易盛（300502.SZ） A株（高ボラ） 2023-02 +38.6% +467.9% 寒武紀（688256.SS） A株（高ボラ） 2023-02 +12.6% +244.2% 工業富聯（601138.SS） A株（高ボラ） 2023-02 +23.1% +176.2% 中際旭創（300308.SZ） A株（高ボラ） 2023-03 +42.2% +163.6% 勝宏科技（300476.SZ） A株（高ボラ） 2023-04 +17.4% +118.0% スーパーマイクロ・コンピュータ（SMCI） 米国株（高ボラ） 2023-05 -37.6% +314.2% Palantir（PLTR） 米国株（高ボラ） 2023-05 +17.1% +306.0% Marvell（MRVL） 米国株（高ボラ） 2023-05 +13.8% +93.9% 常山北明（000158.SZ） A株（高ボラ） 2023-08 +69.3% +92.0% Arm（ARM） 米国株（高ボラ） 2023-11 -7.8% +169.8% EU「AI法」が発効。 リスク分類、透明性、汎用AIモデルに関する義務が本格的な適用段階に入った。EUR-Lex：Regulation (EU) 2024/1689 今月の結論: 規制はもはや公開前の抽象的な議論にとどまらず、モデルのドキュメント、デプロイメントのプロセス、そして企業の調達チェックリストの中に徐々に浸透していく。\n9月：推論モデルに新たな動き（000158.SZ +180.8%） 市況メモ： 利下げ期待が米国のハイテク株の反発を支えるが、資金は割高な半導体からソフトウェアやプラットフォームへの分散を開始。エヌビディア、Arm、Super Micro Computer は引き続き高ボラティリティの代表格であり、A株のAI関連は底値模索を繰り返している。\n怪物株累計表（2024年9月まで、月末復権終値ベース；エヌビディアを筆頭銘柄として対照）\n銘柄（コード） タイプ 表入り月 当月騰落率 表入り後累計 エヌビディア（NVDA） コア銘柄対照 2022-11 +1.7% +798.9% C3.ai（AI） 米株ハイボラ 2023-01 +3.8% +116.8% BigBear.ai（BBAI） 米株ハイボラ 2023-01 -8.2% +116.8% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +8.5% +148.4% SoundHound AI（SOUN） 米株ハイボラ 2023-02 -4.7% +134.8% 新易盛（300502.SZ） A株ハイボラ 2023-02 +0.2% +469.0% 寒武紀（688256.SS） A株ハイボラ 2023-02 +56.9% +440.1% 工業富聯（601138.SS） A株ハイボラ 2023-02 -3.7% +166.0% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -7.6% +143.6% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +13.4% +147.2% スーパーマイクロ（SMCI） 米株ハイボラ 2023-05 -4.9% +293.9% Palantir（PLTR） 米株ハイボラ 2023-05 +18.2% +379.9% Marvell（MRVL） 米株ハイボラ 2023-05 -5.4% +83.4% 常山北明（000158.SZ） A株ハイボラ 2023-08 +180.8% +439.2% Arm（ARM） 米株ハイボラ 2023-11 +7.6% +190.3% OpenAI が o1-preview と o1-mini を発表。 推論モデルはより多くの計算を回答段階に振り向け、数学、コード、複雑なタスクが「思考量」によって価格付けされるようになる。OpenAI：o1-preview と o1-mini 今月の判断： 「より大きく」以外に「より長く考える」という能力曲線が現れており、待機、トークン、レビューのコストを併せて計算する必要がある。\n10月：エージェントがパソコンの操作と検索を開始（SMCI -30.1%） 市場の記録： 米株のAI関連銘柄は決算前後に明暗が分かれ、エヌビディアは比較的堅調だったが、スーパーマイクロ・コンピュータや時価総額の小さいAI株は値動きがより大きかった。A株の資金は演算能力、衛星通信、ロボットといった新たなテーマに流れており、仕手株の動向は明らかに短期化している。\n妖股累計表（2024年10月まで、月末復権終値の合成；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 表入り月 当月騰落率 表入り後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +9.3% +882.5% C3.ai（AI） 米国株高ボラティリティ 2023-01 +1.7% +120.5% BigBear.ai（BBAI） 米国株高ボラティリティ 2023-01 +8.9% +136.1% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 +13.2% +181.1% SoundHound AI（SOUN） 米国株高ボラティリティ 2023-02 +7.9% +153.4% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 -11.7% +402.4% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 +23.7% +568.1% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 -8.5% +143.4% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 -11.4% +115.8% 勝宏科技（300476.SZ） A株高ボラティリティ 2023-04 -9.9% +122.7% スーパーマイクロ・コンピュータ（SMCI） 米国株高ボラティリティ 2023-05 -30.1% +175.3% Palantir（PLTR） 米国株高ボラティリティ 2023-05 +11.7% +436.1% Marvell（MRVL） 米国株高ボラティリティ 2023-05 +11.2% +104.0% 常山北明（000158.SZ） A株高ボラティリティ 2023-08 -29.5% +280.2% Arm（ARM） 米国株高ボラティリティ 2023-11 -1.2% +186.8% Anthropic がコンピュータ使用機能を発表。 Claude が画面を認識し、マウスを動かし、クリックや入力が可能となり、エージェントは API 呼び出しから汎用ソフトウェアの操作へと進化する。Anthropic：computer use OpenAI が ChatGPT Search を発表。 チャットインターフェースがリンク付きのリアルタイムな Web 回答を直接返すようになり、検索と Q\u0026amp;A の境界はさらに曖昧化する。OpenAI：ChatGPT search 今月の結論： Agent の価値は実行から生まれるが、実行能力が高まるほど、権限、プロンプトインジェクション、エラーのロールバック、そして責任の境界を省略することはできない。\n11月：MCP接続ツールとデータ（SOUN +85.1%） 市場メモ： 米国大統領選後、AI はソフトウェア、自動運転、ロボットといったテーマと共に過熱しており、NVIDIA、Palantir、SoundHound などの銘柄は上昇しているが、二極化が激しい。香港市場のテック株も連れ高となっているが、安定した AI 投機銘柄のバスケットはまだ形成されていない。\n妖股累計表（2024年11月末まで、月末復権終値の複合；エヌビディアをリード銘柄対照として）\n銘柄（コード） タイプ 表入り月 今月騰落率 表入り後累計 エヌビディア（NVDA） コア・リード比較対象 2022-11 +4.1% +922.8% C3.ai（AI） 米国株高ボラティリティ 2023-01 +51.0% +233.0% BigBear.ai（BBAI） 米国株高ボラティリティ 2023-01 +44.0% +240.0% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 -16.5% +134.7% SoundHound AI（SOUN） 米国株高ボラティリティ 2023-02 +85.1% +369.0% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 +0.5% +405.0% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 +17.3% +683.7% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 -3.1% +135.8% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 -2.5% +110.4% 勝宏科技（300476.SZ） A株高ボラティリティ 2023-04 +3.8% +131.2% スーパーマイクロ・コンピュータ（SMCI） 米国株高ボラティリティ 2023-05 +12.1% +208.6% Palantir（PLTR） 米国株高ボラティリティ 2023-05 +61.4% +765.3% Marvell（MRVL） 米国株高ボラティリティ 2023-05 +15.7% +136.0% 常山北明（000158.SZ） A株高ボラティリティ 2023-08 -22.9% +193.1% Arm（ARM） 米国株高ボラティリティ 2023-11 -5.0% +172.5% Anthropic が Model Context Protocol を公開。 MCP は汎用プロトコルでモデルと外部ツールおよびデータソースを接続しようとし、ツール統合は単一企業の実装からエコシステム・プロトコルへと移行し始めている。Anthropic：Model Context Protocol 今月の判断： Agent のボトルネックは、モデル自体からツールプロトコル、コンテキスト管理、権限システムへと徐々に移行している。\n12月：Sora が登場、Gemini が Agent の時代へ（SOUN +113.1%） 市場の記録： 年末のAI取引はチップからソフトウェア、データ、ロボットへと広がり、NVIDIAは高値でもみ合い、PalantirやSoundHoundなどの高ベータ銘柄はむしろ妖怪株のような様相を呈した。A株のコンピューティングチェーンは年初の全般的な上昇を再現しなかった。\n妖股累計表（2024年12月まで、月末復権終値の複合；エヌビディアをリード銘柄として対照）\n銘柄（コード） タイプ 表入り月 当月騰落率 表入り後累計 エヌビディア（NVDA） コアリーダー比較対象 2022-11 -2.9% +893.1% C3.ai（AI） 米国株・ボラティリティ高 2023-01 -7.4% +208.3% BigBear.ai（BBAI） 米国株・ボラティリティ高 2023-01 +94.3% +560.7% 崑崙万維（300418.SZ） A株・ボラティリティ高 2023-01 -4.1% +125.1% SoundHound AI（SOUN） 米国株・ボラティリティ高 2023-02 +113.1% +899.5% 新易盛（300502.SZ） A株・ボラティリティ高 2023-02 +8.8% +449.4% 寒武紀（688256.SS） A株・ボラティリティ高 2023-02 -13.1% +581.0% 工業富聯（601138.SS） A株・ボラティリティ高 2023-02 -0.2% +135.3% 中際旭創（300308.SZ） A株・ボラティリティ高 2023-03 -7.0% +95.7% 勝宏科技（300476.SZ） A株・ボラティリティ高 2023-04 +26.5% +192.5% スーパーマイクロ・コンピュータ（SMCI） 米国株・ボラティリティ高 2023-05 -6.6% +188.3% Palantir（PLTR） 米国株・ボラティリティ高 2023-05 +12.7% +875.1% Marvell（MRVL） 米国株・ボラティリティ高 2023-05 +19.2% +181.3% 常山北明（000158.SZ） A株・ボラティリティ高 2023-08 -11.7% +158.8% Arm（ARM） 米国株・ボラティリティ高 2023-11 -8.1% +150.4% OpenAI が Sora を正式リリース。 動画生成が研究プレビューからサブスクリプション製品へと移行し、ウォーターマークと出所識別措置が標準で組み込まれた。OpenAI：Sora is here Google が Gemini 2.0 を発表、エージェント時代を強調。 マルチモーダル出力、ツール呼び出し、リアルタイムインタラクションが次世代製品の方向性となる。Google：Gemini 2.0 今月の見解： 2024 年のメインテーマは、「モデルが何を生成できるか」から「モデルが現実環境で一連のアクションを完了できるかどうか」へと移行した。\n2025年：推論コストの低下、コーディングがエージェントの実験場になる 1月：R1の再計算コスト、Stargateがインフラ増強（688158.SS +155.2%） 市場記録： 1月27日、DeepSeekの衝撃によりエヌビディアは単日で約17%下落し、まれに見る巨大な時価総額後退を引き起こした。米国市場のコンピューティング関連株が最初に売り込まれ、A株のコンセプト株はまず異動し、旧正月明けに再び拡散、浙江東方、美格智能、每日互動、優刻得などが高ボラティリティの代表となった。この月は同時に「海外でコンピューティングを売り、国内でアプリケーションを買う」という分裂した相場が出現した。ロイター：DeepSeekがAI株の売り浴びせを引き起こす\n怪物株累計表（2025年1月まで、月末権利調整後終値の複合；エヌビディアをリーダー对照として）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計騰落率 エヌビディア（NVDA） 中核リーダー比較対象 2022-11 -10.6% +787.8% C3.ai（AI） 米株ハイボラ 2023-01 -8.9% +180.9% BigBear.ai（BBAI） 米株ハイボラ 2023-01 -4.7% +529.6% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +0.3% +125.8% SoundHound AI（SOUN） 米株ハイボラ 2023-02 -28.7% +612.6% 新易盛（300502.SZ） A株ハイボラ 2023-02 -23.6% +319.7% 寒武紀（688256.SS） A株ハイボラ 2023-02 +28.6% +775.8% 工業富聯（601138.SS） A株ハイボラ 2023-02 -1.2% +132.5% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -12.1% +72.0% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -4.1% +180.5% スーパーマイクロ（SMCI） 米株ハイボラ 2023-05 -6.4% +169.8% Palantir（PLTR） 米株ハイボラ 2023-05 +9.1% +963.9% Marvell（MRVL） 米株ハイボラ 2023-05 +2.2% +187.5% 常山北明（000158.SZ） A株ハイボラ 2023-08 +41.6% +266.5% Arm（ARM） 米株ハイボラ 2023-11 +29.3% +223.8% 浙江東方（600120.SS） A株テーマハイボラ 2025-01 +43.0% +43.0% 美格智能（002881.SZ） A株テーマハイボラ 2025-01 +40.9% +40.9% 優刻得（688158.SS） A株テーマハイボラ 2025-01 +155.2% +155.2% 青云科技（688316.SS） A株テーマハイボラ 2025-01 +139.2% +139.2% 拓維信息（002261.SZ） A株テーマハイボラ 2025-01 +98.5% +98.5% DeepSeek が DeepSeek-R1 をリリースし、ウェイトと論文を公開。 オープンな推論モデルにより、最先端の能力・学習手法・単位コストが一挙に世界市場へ提示された。DeepSeek：R1 リリース 米国が Stargate プロジェクトを発表。 OpenAI、ソフトバンク、Oracle などの協業先が大規模な AI インフラ計画を公表し、設備投資のナラティブは引き続きデータセンターに集中している。OpenAI：Stargate プロジェクト 今月の結論： DeepSeek は市場に対してユニットあたりの能力コストを再計算させた。一方、Stargate は総需要、総投資、そして推論一回あたりのコストが同時に上昇しうることを示している。\n2月：研究、推論とコーディングのロングタスクチェーン（300476.SZ +58.7%） 市場の記録： DeepSeekテーマがA株で引き続き拡大し、浙江東方が連続ストップ高の後に天地板（高値引けから安値引けへの急変）を記録し、美格智能、優刻得、青雲科技、拓維信息などが順番にバトンを繋いだ。米株はパニックから修復し、エヌビディアとクラウド事業者が再び設備投資ロジックに戻り、A株の「妖怪株」と米株のトップ銘柄は異なるリズムで動いている。浙江東方と美格智能に関するリスク警告\n妖股累計表（2025-02 まで、月末復権終値複合；エヌビディアをリード銘柄対照）\n対象銘柄（コード） 種別 組入月 当月騰落率 組入後累計騰落率 エヌビディア（NVDA） コア銘柄（参考） 2022-11 +4.0% +823.3% C3.ai（AI） 米国株（高ボラ） 2023-01 -25.2% +110.1% BigBear.ai（BBAI） 米国株（高ボラ） 2023-01 +21.7% +666.3% 崑崙万維（300418.SZ） A株（高ボラ） 2023-01 -6.9% +110.2% SoundHound AI（SOUN） 米国株（高ボラ） 2023-02 -23.5% +445.2% 新易盛（300502.SZ） A株（高ボラ） 2023-02 +2.2% +329.0% 寒武紀（688256.SS） A株（高ボラ） 2023-02 -15.3% +641.8% 工業富聯（601138.SS） A株（高ボラ） 2023-02 -6.3% +117.9% 中際旭創（300308.SZ） A株（高ボラ） 2023-03 -2.2% +68.2% 勝宏科技（300476.SZ） A株（高ボラ） 2023-04 +58.7% +345.1% スーパーマイクロ（SMCI） 米国株（高ボラ） 2023-05 +45.4% +292.3% Palantir（PLTR） 米国株（高ボラ） 2023-05 +2.9% +994.7% Marvell（MRVL） 米国株（高ボラ） 2023-05 -18.6% +134.0% 常山北明（000158.SZ） A株（高ボラ） 2023-08 -11.9% +222.9% Arm（ARM） 米国株（高ボラ） 2023-11 -17.5% +167.1% 浙江東方（600120.SS） A株（テーマ株・高ボラ） 2025-01 -12.1% +25.7% 美格智能（002881.SZ） A株（テーマ株・高ボラ） 2025-01 -15.9% +18.5% 優刻得（688158.SS） A株（テーマ株・高ボラ） 2025-01 -26.3% +88.1% 青云科技（688316.SS） A株（テーマ株・高ボラ） 2025-01 -17.0% +98.5% 拓維信息（002261.SZ） A株（テーマ株・高ボラ） 2025-01 -14.6% +69.5% OpenAI が deep research を発表。 モデルが自律的に複数ステップのウェブ検索・閲覧・統合を開始し、研究タスクは Agent の代表的なシナリオとなった。OpenAI：deep research Anthropic が Claude 3.7 Sonnet と Claude Code を発表。 ハイブリッド推論モデルとターミナル向けコーディングツールが同時に登場し、ソフトウェア工学は長時間タスク Agent の試験場となった。Anthropic：Claude 3.7 Sonnet and Claude Code OpenAI が GPT-4.5 リサーチプレビューを発表。 大規模事前学習モデルと推論モデルが二つの補完的な路線となり、モデル名称以外の学習コストやサービスコストにも関心が集まり始めた。OpenAI：GPT-4.5 今月の判断： 推論モデル、联网調査、coding Agent はいずれもタスクチェーンを延伸させるが、それに伴いコンテキスト、待ち時間、検証コストも増幅させる。\n3月：ウェブ検索がAPI機能に（NVDA -13.2%） 市場概況： 市場は DeepSeek 関連のテーマから推論、コンピューティングパワー、ロボットへと移行し、NVIDIA が GTC 前後で再び注目を集めた。A 株では Tuowei Information、Changshan Beiming、Inspur Information および光モジュール関連銘柄が高ボラティリティで推移し、香港株のテクノロジー株は比較的活発だった。\nモンスター株累計表（2025年3月まで、月末権利調整後終値の複合；エヌビディアをリーダー対照として）\n銘柄（コード） 種別 組入月 月間騰落率 組入後累計 エヌビディア（NVDA） コア銘柄（対照） 2022-11 -13.2% +701.5% C3.ai（AI） 米株・ハイボラ 2023-01 -10.2% +88.7% BigBear.ai（BBAI） 米株・ハイボラ 2023-01 -44.6% +324.5% 崑崙万維（300418.SZ） A株・ハイボラ 2023-01 -7.4% +94.7% SoundHound AI（SOUN） 米株・ハイボラ 2023-02 -25.0% +308.9% 新易盛（300502.SZ） A株・ハイボラ 2023-02 -8.5% +292.5% 寒武紀（688256.SS） A株・ハイボラ 2023-02 +12.9% +737.5% 工業富聯（601138.SS） A株・ハイボラ 2023-02 -9.1% +98.0% 中際旭創（300308.SZ） A株・ハイボラ 2023-03 -15.4% +42.3% 勝宏科技（300476.SZ） A株・ハイボラ 2023-04 -9.3% +303.7% スーパーマイクロ・コンピュータ（SMCI） 米株・ハイボラ 2023-05 -17.4% +224.0% Palantir（PLTR） 米株・ハイボラ 2023-05 -0.6% +988.2% Marvell（MRVL） 米株・ハイボラ 2023-05 -32.9% +57.0% 常山北明（000158.SZ） A株・ハイボラ 2023-08 +1.7% +228.4% Arm（ARM） 米株・ハイボラ 2023-11 -18.9% +116.6% 浙江東方（600120.SS） A株・テーマ株・ハイボラ 2025-01 -6.6% +17.4% 美格智能（002881.SZ） A株・テーマ株・ハイボラ 2025-01 +3.0% +22.1% 優刻得（688158.SS） A株・テーマ株・ハイボラ 2025-01 -13.5% +62.7% 青云科技（688316.SS） A株・テーマ株・ハイボラ 2025-01 -16.7% +65.4% 拓維信息（002261.SZ） A株・テーマ株・ハイボラ 2025-01 +16.4% +97.3% GoogleがGemini 2.5を公開。 「思考モデル」がGeminiシリーズの中核的な物語となり、長コンテキストとマルチモーダル推論は製品化へと向かいつつある。Google：Gemini 2.5 AnthropicがClaude APIにWeb Searchを導入。 検索機能は単一のチャット製品から、開発者が組み合わせ可能なAPIツールへと拡張された。Anthropic：Claude can now search the web 今月の見解： インターネット接続は、もはや単なる製品のオン/オフ切り替えではなく、Agentアーキテクチャにおけるオーケストレーション可能な能力となっています。\n4 月：モデル比較ユニットが完全なタスクに成長（PLTR +40.3%） 市場の記録： 関税と成長懸念が世界のハイテク株の急速な反落を引き起こし、NVIDIA、AMD、Super Micro Computer、AIインフラ関連株は下落後に反発した。A株の高位置にあるコンピューティング関連株は分化し、市場は「受注が実際に成立するか」という点をテーマ性よりも重視し始めている。\n妖怪銘柄累計表（2025-04まで、月末調整後終値の複合；エヌビディアを筆頭銘柄として対照）\n銘柄（コード） タイプ 表入り月 当月騰落率 表入り後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +0.5% +705.5% C3.ai（AI） 米株ハイボラ 2023-01 +4.6% +97.3% BigBear.ai（BBAI） 米株ハイボラ 2023-01 +19.2% +406.0% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +4.8% +104.0% SoundHound AI（SOUN） 米株ハイボラ 2023-02 +14.4% +367.8% 新易盛（300502.SZ） A株ハイボラ 2023-02 +38.2% +442.4% 寒武紀（688256.SS） A株ハイボラ 2023-02 -14.2% +618.6% 工業富聯（601138.SS） A株ハイボラ 2023-02 +4.8% +107.6% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +12.0% +59.4% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +18.2% +377.2% Super Micro Computer（SMCI） 米株ハイボラ 2023-05 -7.0% +201.4% Palantir（PLTR） 米株ハイボラ 2023-05 +40.3% +1426.7% Marvell（MRVL） 米株ハイボラ 2023-05 -5.1% +49.0% 常山北明（000158.SZ） A株ハイボラ 2023-08 -2.2% +221.1% Arm（ARM） 米株ハイボラ 2023-11 +6.8% +131.3% 浙江東方（600120.SS） A株テーマハイボラ 2025-01 -6.2% +10.1% 美格智能（002881.SZ） A株テーマハイボラ 2025-01 -11.9% +7.5% 優刻得（688158.SS） A株テーマハイボラ 2025-01 -13.3% +41.1% 青云科技（688316.SS） A株テーマハイボラ 2025-01 -12.7% +44.4% 拓維信息（002261.SZ） A株テーマハイボラ 2025-01 -12.0% +73.6% Meta が Llama 4 Scout と Maverick を発表。 オープンウェイトモデルにネイティブマルチモーダルと MoE アーキテクチャが導入され、コミュニティのロードマップはデプロイメント権を巡る競争を続けている。Meta：Llama 4 OpenAI が GPT-4.1 シリーズを発表。 長コンテキスト、指示追従、コーディングが API リリースの主な売りとなっている。OpenAI：GPT-4.1 OpenAI が o3 と o4-mini を発表。 推論モデルが ChatGPT 内で初めて検索、ファイル解析、Python、画像生成などのツールを組み合わせて使用し、エージェントとしての形態がより完全なものとなった。OpenAI：o3 and o4-mini 今月の判断： モデルリリースの評価単位が単一の回答からタスクへと移行し、ツール利用、コード修正、結果検証が同じ製品ループの中に組み込まれ始めた。\n5月：Claude 4が長時間コーディングタスクを巡る競争（300308.SZ +56.5%） 市場記録： 米株AI関連銘柄は決算と設備投資見通しのなかで反発し、エヌビディア、ブロードコム、デル、クラウド大手が多くの応用株を上回るパフォーマンスを見せている。A株では光モジュール、PCB、サーバー関連チェーンが再び活発化し、投機的な株価急騰の特徴が産業チェーンの細分化されたセクターに集中している。\n妖怪株累計表（2025年5月まで、月末復権終値の複合；エヌビディアをリード銘柄として対照）\n銘柄（コード） タイプ 組入月 今月の騰落率 組入後累計 エヌビディア（NVDA） コア銘柄（参考） 2022-11 +24.1% +899.6% C3.ai（AI） 米国株・ハイボラ 2023-01 +20.8% +138.4% BigBear.ai（BBAI） 米国株・ハイボラ 2023-01 +22.0% +517.3% 崑崙万維（300418.SZ） A株・ハイボラ 2023-01 +0.6% +105.2% SoundHound AI（SOUN） 米国株・ハイボラ 2023-02 +8.8% +408.9% 新易盛（300502.SZ） A株・ハイボラ 2023-02 +43.9% +680.6% 寒武紀（688256.SS） A株・ハイボラ 2023-02 -0.4% +615.7% 工業富聯（601138.SS） A株・ハイボラ 2023-02 +12.9% +134.3% 中際旭創（300308.SZ） A株・ハイボラ 2023-03 +56.5% +149.5% 勝宏科技（300476.SZ） A株・ハイボラ 2023-04 +55.4% +641.6% スーパーマイクロ（SMCI） 米国株・ハイボラ 2023-05 +25.6% +278.5% Palantir（PLTR） 米国株・ハイボラ 2023-05 +11.3% +1599.2% Marvell（MRVL） 米国株・ハイボラ 2023-05 +3.1% +53.6% 常山北明（000158.SZ） A株・ハイボラ 2023-08 -0.2% +220.5% Arm（ARM） 米国株・ハイボラ 2023-11 +9.2% +152.6% 浙江東方（600120.SS） A株・テーマ株・ハイボラ 2025-01 +9.4% +20.5% 美格智能（002881.SZ） A株・テーマ株・ハイボラ 2025-01 +7.5% +15.6% 優刻得（688158.SS） A株・テーマ株・ハイボラ 2025-01 +16.1% +63.8% 青云科技（688316.SS） A株・テーマ株・ハイボラ 2025-01 +28.7% +85.8% 拓維信息（002261.SZ） A株・テーマ株・ハイボラ 2025-01 +5.7% +83.5% Anthropic が Claude 4 を発表。 Opus 4、Sonnet 4 と Agent ツールの連携能力がさらに強化され、長時間のコーディングタスクがフロンティアモデルの競争における重要な指標となっている。Anthropic：Claude 4 Anthropic が API 向け Web Search および接続機能を発表。 モデル提供各社が、検索・ファイル・外部サービスへの接続を再利用可能な開発者向けインフラとして提供し始めている。Anthropic ニュースルーム 今月の結論： coding の競争は、数行のコードを補完することではなく、リポジトリを読み込み、タスクを分割し、ファイルを編集し、テストを実行し、失敗を処理することである。\n6月：ターミナルがエージェントの作業環境に（601138.SS +65.1%） 市場の記録： 米株市場ではAI資本支出の取引が継続しており、エヌビディア、ブロードコム、データセンター関連サプライヤーが強い動きを維持している。A株市場では中際旭創、新易盛、勝宏科技、工業富聯といったコンピューティング関連チェーンが高値圏で拡大しており、光モジュールとPCBはこの局面で「妖株（投機的急騰銘柄）」に最も近い方向性となっているが、産業の景況感と個別銘柄の価格を同一視してはならない。\n怪物株累計表（2025年6月まで、月末調整後終値の複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 表入り月 当月騰落率 組み入れ後累計 エヌビディア（NVDA） 中核リーダー比較対象 2022-11 +16.9% +1068.5% C3.ai（AI） 米株ハイボラティリティ 2023-01 -7.6% +120.3% BigBear.ai（BBAI） 米株ハイボラティリティ 2023-01 +63.2% +907.5% 崑崙万維（300418.SZ） A株ハイボラティリティ 2023-01 +6.7% +119.0% SoundHound AI（SOUN） 米株ハイボラティリティ 2023-02 +6.1% +440.0% 新易盛（300502.SZ） A株ハイボラティリティ 2023-02 +49.0% +1063.1% 寒武紀（688256.SS） A株ハイボラティリティ 2023-02 +18.0% +744.5% 工業富聯（601138.SS） A株ハイボラティリティ 2023-02 +65.1% +286.9% 中際旭創（300308.SZ） A株ハイボラティリティ 2023-03 +49.2% +272.2% 勝宏科技（300476.SZ） A株ハイボラティリティ 2023-04 +42.9% +959.7% スーパーマイクロ（SMCI） 米株ハイボラティリティ 2023-05 +22.5% +363.7% Palantir（PLTR） 米株ハイボラティリティ 2023-05 +3.4% +1657.0% Marvell（MRVL） 米株ハイボラティリティ 2023-05 +28.6% +97.6% 常山北明（000158.SZ） A株ハイボラティリティ 2023-08 +5.3% +237.5% Arm（ARM） 米株ハイボラティリティ 2023-11 +29.9% +228.2% 浙江東方（600120.SS） A株テーマ株ハイボラティリティ 2025-01 -0.2% +20.2% 美格智能（002881.SZ） A株テーマ株ハイボラティリティ 2025-01 -4.4% +10.5% 優刻得（688158.SS） A株テーマ株ハイボラティリティ 2025-01 +16.6% +90.9% 青云科技（688316.SS） A株テーマ株ハイボラティリティ 2025-01 +24.9% +132.1% 拓維信息（002261.SZ） A株テーマ株ハイボラティリティ 2025-01 +4.8% +92.3% Google が Gemini CLI をオープンソースの AI エージェントツールとして開発者向けに公開。 ターミナルが、モデル呼び出し、検索、コード修正のための直接的な入り口となりつつある。Google：2025年 AI ニュース振り返り OpenAI が o3-pro をリリース。 計算予算を増やした推論モデルは、信頼性、速度、価格のバランスを同じ利用コストの中に収め続けている。OpenAI モデルリリースノート 今月の判断： ターミナルと IDE は、もはやモデルを表示するだけのインターフェースではなく、エージェントがコンテキスト、権限、検証フィードバックを得るための作業環境である。\n7月：Agent がモデルからデリバリーへ（688256.SS +110.4%） 市場記録： AI相場がチップからコーディング、ソフトウェア、データセンターインフラへと広がり、米株の主力銘柄は高位でのローテーションを行い、A株では光モジュール、サーバー、PCBの分化が続いている。中際旭創、新易盛、勝宏科技などの高ベータ銘柄が、市場が注目する「妖株型」の代表となっている。\nゴーストストック累計表（2025年7月まで、月末復権終値複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核銘柄（参考） 2022-11 +12.6% +1215.7% C3.ai（AI） 米株（高ボラティリティ） 2023-01 -4.1% +111.2% BigBear.ai（BBAI） 米株（高ボラティリティ） 2023-01 -6.5% +842.0% 崑崙万維（300418.SZ） A株（高ボラティリティ） 2023-01 +17.0% +156.2% SoundHound AI（SOUN） 米株（高ボラティリティ） 2023-02 -3.7% +420.0% 新易盛（300502.SZ） A株（高ボラティリティ） 2023-02 +88.3% +2090.1% 寒武紀（688256.SS） A株（高ボラティリティ） 2023-02 +110.4% +1676.9% 工業富聯（601138.SS） A株（高ボラティリティ） 2023-02 +55.5% +501.6% 中際旭創（300308.SZ） A株（高ボラティリティ） 2023-03 +63.1% +507.1% 勝宏科技（300476.SZ） A株（高ボラティリティ） 2023-04 +39.2% +1375.2% スーパーマイクロ（SMCI） 米株（高ボラティリティ） 2023-05 +20.3% +457.8% Palantir（PLTR） 米株（高ボラティリティ） 2023-05 +16.2% +1941.6% Marvell（MRVL） 米株（高ボラティリティ） 2023-05 +3.9% +105.3% 常山北明（000158.SZ） A株（高ボラティリティ） 2023-08 +11.5% +276.3% Arm（ARM） 米株（高ボラティリティ） 2023-11 -12.6% +186.8% 浙江東方（600120.SS） A株（テーマ株・高ボラティリティ） 2025-01 +6.6% +28.2% 美格智能（002881.SZ） A株（テーマ株・高ボラティリティ） 2025-01 +27.8% +41.2% 優刻得（688158.SS） A株（テーマ株・高ボラティリティ） 2025-01 +5.5% +101.4% 青云科技（688316.SS） A株（テーマ株・高ボラティリティ） 2025-01 -5.1% +120.2% 拓維信息（002261.SZ） A株（テーマ株・高ボラティリティ） 2025-01 +27.7% +145.6% xAI が Grok 4 を発表。 推論、ツール利用、リアルタイム検索が一つのモデル製品に統合され、最先端モデル競争はさらにエージェントおよびリアルタイム情報へと拡張された。xAI ニュースルーム OpenAI が ChatGPT agent を発表。 リサーチ、ブラウザ操作、ターミナル、コネクタが複雑なタスクを実行できる一つのエージェントに統合され、モデルは「開始から納品まで」のリクエストを直接処理し始めた。OpenAI：ChatGPT agent 今月の見解： Agent の評価はソフトウェアエンジニアリングの評価に近づき始めており、一度にきれいな回答を生成するよりも、タスクを着実に完了することのほうが重要になっています。\n8月：GPT-5とオープンウェイトが同時に前進（SOUN +26.0%） 市場の記録： 米株式市場ではモデル能力とプラットフォームエコシステムの再評価が行われ、エヌビディア、Microsoft、Meta などの時価総額が大きい銘柄が多くの小型株を上回る動きとなりました。A株市場ではAI資金がコンピューティング能力からアプリケーションや端末へと広がり、単一の持続的なテーマ株は形成されていません。\n妖股累計表（2025年08月まで、月末復権終値の複合；エヌビディアをリーダー対照）\n銘柄（コード） 種別 組み入れ月 今月の騰落率 組み入れ後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 -2.1% +1188.1% C3.ai（AI） 米国株ハイボラ 2023-01 -28.2% +51.7% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 -20.2% +651.7% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +15.7% +196.4% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 +26.0% +555.2% 新易盛（300502.SZ） A株ハイボラ 2023-02 +2.7% +2149.2% 寒武紀（688256.SS） A株ハイボラ 2023-02 -11.2% +1477.9% 工業富聯（601138.SS） A株ハイボラ 2023-02 +22.6% +637.6% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +13.7% +590.3% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +6.8% +1475.5% スーパーマイクロ（SMCI） 米国株ハイボラ 2023-05 -29.6% +292.7% Palantir（PLTR） 米国株ハイボラ 2023-05 -1.0% +1921.2% Marvell（MRVL） 米国株ハイボラ 2023-05 -21.8% +60.5% 常山北明（000158.SZ） A株ハイボラ 2023-08 -11.7% +232.3% Arm（ARM） 米国株ハイボラ 2023-11 -2.2% +180.5% 浙江東方（600120.SS） A株テーマハイボラ 2025-01 -2.5% +25.0% 美格智能（002881.SZ） A株テーマハイボラ 2025-01 -13.6% +22.0% 優刻得（688158.SS） A株テーマハイボラ 2025-01 -2.8% +95.8% 青云科技（688316.SS） A株テーマハイボラ 2025-01 -11.5% +94.9% 拓維信息（002261.SZ） A株テーマハイボラ 2025-01 -12.8% +114.2% OpenAI が GPT-5 を発表。 統合システムにより、高速回答・深い思考・視覚・コード・エージェント機能を同一世代の製品にまとめ、コーディングは中核的なユースケースとして明確に位置付けられた。OpenAI：GPT-5 OpenAI が gpt-oss-120b と gpt-oss-20b を発表。 OpenAI がオープウェイトモデル市場に再参入し、モデルをダウンロードしてカスタマイズし、ローカル環境または自社インフラ上で実行できる。OpenAI：gpt-oss 今月の結論: クローズドなサービスとオープンなウェイトは二者択一ではなく、モデル企業は API で課金しつつ、オープンウェイトでエコシステムを拡大するという両立が可能である。\n9月：Agentにチェックポイントとロールバックが必要になる（MRVL +33.7%） 市場記録： 利下げとソフトウェアの利益期待により、AI取引がハードウェアからプラットフォーム、ソフトウェア、データへと移行し、Palantir、ソフトウェアインフラ、一部のロボット株のボラティリティが拡大している。A株の高位テーマ株は急騰急落の局面に入っている。\n怪物株累計表（2025年9月まで、月末復権終値複合；エヌビディアを筆頭銘柄として対照）\n銘柄（コード） タイプ 表掲載月 月間騰落率 掲載後累計騰落率 エヌビディア（NVDA） 中核リーダー対照 2022-11 +7.1% +1279.6% C3.ai（AI） 米株高ボラティリティ 2023-01 +2.5% +55.5% BigBear.ai（BBAI） 米株高ボラティリティ 2023-01 +28.6% +866.7% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 -5.2% +181.0% SoundHound AI（SOUN） 米株高ボラティリティ 2023-02 +23.5% +709.2% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 -5.9% +2016.5% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 +3.8% +1537.8% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 +9.1% +704.7% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 +17.3% +709.7% 勝宏科技（300476.SZ） A株高ボラティリティ 2023-04 +3.0% +1522.7% スーパーマイクロ（SMCI） 米株高ボラティリティ 2023-05 +15.4% +353.2% Palantir（PLTR） 米株高ボラティリティ 2023-05 +16.4% +2252.7% Marvell（MRVL） 米株高ボラティリティ 2023-05 +33.7% +114.6% 常山北明（000158.SZ） A株高ボラティリティ 2023-08 +0.9% +235.2% Arm（ARM） 米株高ボラティリティ 2023-11 +2.3% +187.0% 浙江東方（600120.SS） A株テーマ高ボラティリティ 2025-01 +14.0% +42.5% 美格智能（002881.SZ） A株テーマ高ボラティリティ 2025-01 -7.2% +13.2% 優刻得（688158.SS） A株テーマ高ボラティリティ 2025-01 -6.7% +82.7% 青云科技（688316.SS） A株テーマ高ボラティリティ 2025-01 -3.3% +88.5% 拓維信息（002261.SZ） A株テーマ高ボラティリティ 2025-01 -5.2% +103.1% Anthropic が Claude Sonnet 4.5 をリリース。 コーディング、コンピュータ使用、Claude Code チェックポイント、Agent SDK が同じリリースでまとめて更新され、長時間タスクのロールバック可能性が製品機能として確立され始めた。Anthropic：Claude Sonnet 4.5 今月の判断： Agent を本番環境に投入する場合、チェックポイント、メモリ、権限、ロールバックはモデルの能力と同じくらい重要である。\n10月：低レイテンシモデル配置（ARM +20.0%） 市況メモ： 低遅延モデルの商用化期待がソフトウェアおよびクラウドサービス株を下支えし、チップ株は足元で高値圏でもみ合いとなっている。A株のAI相場ではセクター間の資金循環が続いており、テーマ株は単一のモデル概念から、ドローン（低空経済）、ロボット、エッジデバイスといったクロスセクターのテーマへと広がっている。\n怪物株累計表（2025年10月まで、月末調整後終値の複合；エヌビディアをリーダー株として対照）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） コア銘柄（比較用） 2022-11 +8.5% +1396.8% C3.ai（AI） 米株（高ボラ） 2023-01 +1.4% +57.6% BigBear.ai（BBAI） 米株（高ボラ） 2023-01 +6.1% +925.7% 崑崙万維（300418.SZ） A株（高ボラ） 2023-01 -5.6% +165.3% SoundHound AI（SOUN） 米株（高ボラ） 2023-02 +9.6% +786.8% 新易盛（300502.SZ） A株（高ボラ） 2023-02 +1.0% +2037.7% 寒武紀（688256.SS） A株（高ボラ） 2023-02 -3.2% +1485.4% 工業富聯（601138.SS） A株（高ボラ） 2023-02 -15.7% +578.3% 中際旭創（300308.SZ） A株（高ボラ） 2023-03 +8.8% +780.9% 勝宏科技（300476.SZ） A株（高ボラ） 2023-04 -7.9% +1394.5% スーパーマイクロ（SMCI） 米株（高ボラ） 2023-05 +8.4% +391.2% Palantir（PLTR） 米株（高ボラ） 2023-05 +9.9% +2485.6% Marvell（MRVL） 米株（高ボラ） 2023-05 +11.6% +139.5% 常山北明（000158.SZ） A株（高ボラ） 2023-08 -5.1% +218.1% Arm（ARM） 米株（高ボラ） 2023-11 +20.0% +244.4% 浙江東方（600120.SS） A株（テーマ株・高ボラ） 2025-01 -12.7% +24.4% 美格智能（002881.SZ） A株（テーマ株・高ボラ） 2025-01 -8.3% +3.8% 優刻得（688158.SS） A株（テーマ株・高ボラ） 2025-01 -4.3% +74.8% 青云科技（688316.SS） A株（テーマ株・高ボラ） 2025-01 -0.8% +87.0% 拓維信息（002261.SZ） A株（テーマ株・高ボラ） 2025-01 -7.6% +87.6% Anthropic が Claude Haiku 4.5 を発表。 より高速で安価なモデルにより、前世代の最先端能力が頻度の高いタスクにも降りてきており、モデルのルーティングとコスト管理は引き続き細分化が進んでいる。Anthropic：Claude Haiku 4.5 今月の判断： 産業は最強のモデル一つだけを残すことはなく、低遅延かつ低価格なモデルが、大量の実際の呼び出しが成立するかを決定する。\n11月：Gemini 3 接続開発プラットフォーム（300502.SZ +23.9%） 市場の記録： 米株のAI大手は設備投資とバリュエーションの間で引き続き綱引きを続けており、NVIDIA、ブロードコム、クラウドベンダーが中心テーマとなっています。ソフトウェア株は動きが分かれています。A株ではコンピューティングパワー、アプリケーション、ロボティクスのテーマが順番に物色されており、AI市場全体を代表する銘柄は存在しません。\n妖股累計表（2025年11月まで、月末復権終値複合；エヌビディアを主導銘柄対照として）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 -12.6% +1208.2% C3.ai（AI） 米国株 高ボラティリティ 2023-01 -17.8% +29.6% BigBear.ai（BBAI） 米国株 高ボラティリティ 2023-01 -8.4% +839.5% 崑崙万維（300418.SZ） A株 高ボラティリティ 2023-01 -4.1% +154.4% SoundHound AI（SOUN） 米国株 高ボラティリティ 2023-02 -31.6% +506.6% 新易盛（300502.SZ） A株 高ボラティリティ 2023-02 +23.9% +2548.6% 寒武紀（688256.SS） A株 高ボラティリティ 2023-02 +1.8% +1514.0% 工業富聯（601138.SS） A株 高ボラティリティ 2023-02 +2.2% +593.3% 中際旭創（300308.SZ） A株 高ボラティリティ 2023-03 +18.6% +944.8% 勝宏科技（300476.SZ） A株 高ボラティリティ 2023-04 +6.2% +1487.2% スーパーマイクロ（SMCI） 米国株 高ボラティリティ 2023-05 -34.9% +219.8% Palantir（PLTR） 米国株 高ボラティリティ 2023-05 -16.0% +2071.9% Marvell（MRVL） 米国株 高ボラティリティ 2023-05 -4.6% +128.5% 常山北明（000158.SZ） A株 高ボラティリティ 2023-08 -6.8% +196.5% Arm（ARM） 米国株 高ボラティリティ 2023-11 -20.2% +174.8% 浙江東方（600120.SS） A株 テーマ株 高ボラティリティ 2025-01 -1.3% +22.7% 美格智能（002881.SZ） A株 テーマ株 高ボラティリティ 2025-01 +6.9% +11.0% 優刻得（688158.SS） A株 テーマ株 高ボラティリティ 2025-01 +16.3% +103.3% 青云科技（688316.SS） A株 テーマ株 高ボラティリティ 2025-01 -5.6% +76.5% 拓維信息（002261.SZ） A株 テーマ株 高ボラティリティ 2025-01 +4.5% +96.1% Google が Gemini 3 を発表。 推論、マルチモーダル、コーディングが再統合され、Agentic development platform が製品提供の一部となり始めている。Google：Gemini 3 今月の評価： モデルベンダーの戦場はモデルAPIから、開発プラットフォーム、検索、ブラウザ、そしてオフィスソフトウェアへと拡大している。\n12月：推論能力の継続的な低コスト化（688158.SS +33.6%） 市場の記録： 年末の市場は推論コストと実際の呼び出しを重視し、AI の主導株は単なるハードウェア相場から、クラウド、ソフトウェア、アプリケーションへの階層別展開へと移行した。ボラティリティの高い投機株は依然存在するが、持続期間は短縮されており、それらを産業の景況感の代表として用いることはできない。\n妖股累計表（2025年12月まで、月末権利調整後終値の複合；エヌビディアをリード銘柄対照として）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計騰落率 エヌビディア（NVDA） 中核銘柄（比較対象） 2022-11 +5.4% +1278.9% C3.ai（AI） 米株ハイボラ 2023-01 -6.7% +20.9% BigBear.ai（BBAI） 米株ハイボラ 2023-01 -14.8% +700.5% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +33.8% +240.4% SoundHound AI（SOUN） 米株ハイボラ 2023-02 -17.3% +401.7% 新易盛（300502.SZ） A株ハイボラ 2023-02 -2.6% +2479.7% 寒武紀（688256.SS） A株ハイボラ 2023-02 -7.1% +1399.4% 工業富聯（601138.SS） A株ハイボラ 2023-02 -6.5% +548.2% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +6.4% +1011.7% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -7.9% +1361.8% Super Micro Computer（SMCI） 米株ハイボラ 2023-05 -13.5% +176.6% Palantir（PLTR） 米株ハイボラ 2023-05 +5.5% +2191.4% Marvell（MRVL） 米株ハイボラ 2023-05 -4.9% +117.3% 常山北明（000158.SZ） A株ハイボラ 2023-08 -1.7% +191.5% Arm（ARM） 米株ハイボラ 2023-11 -19.4% +121.5% 浙江東方（600120.SS） A株テーマ株ハイボラ 2025-01 +5.4% +29.4% 美格智能（002881.SZ） A株テーマ株ハイボラ 2025-01 +0.4% +11.4% 優刻得（688158.SS） A株テーマ株ハイボラ 2025-01 +33.6% +171.7% 青云科技（688316.SS） A株テーマ株ハイボラ 2025-01 +25.9% +122.2% 拓維信息（002261.SZ） A株テーマ株ハイボラ 2025-01 -4.3% +87.6% Google が Gemini 3 Flash を発表。 Gemini 3 の能力を引き継いだ、より高速でコストパフォーマンスに優れたモデルが登場し、最先端モデルと大規模呼び出しの間にある価格差は引き続き縮小している。Google：2025年12月のAIアップデート 今月の結論： 推論能力は、単価が十分に低くなって初めて、デモから日常業務へと移行する。\n2026年：モデル企業が公開市場と現実のワークフローの精査を受け入れる 1月：Constitutionと自動閲覧（NVDA +2.5%） 市場記録： 香港株の AI 企業は取引可能な公開市場のサンプルが出始め、智譜（02513）と MiniMax（00100）は上場後に大きな値動きを見せている。米国株は引き続き NVIDIA、Microsoft、クラウド事業者が主導している。新興株の高回転率は「妖株型」相場として記録できるが、売上やバリュエーション分析の代替とはならない。香港取引所：MiniMax 新上場証券受入通知\n怪物株累計表（2026-01まで、月末復権終値の複合；エヌビディアを筆頭銘柄として対照）\n銘柄（コード） タイプ 組入月 当月騰落 組入後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +2.5% +1313.4% C3.ai（AI） 米株高ボラ 2023-01 -18.3% -1.2% BigBear.ai（BBAI） 米株高ボラ 2023-01 -6.7% +646.9% 崑崙万維（300418.SZ） A株高ボラ 2023-01 +9.5% +272.7% SoundHound AI（SOUN） 米株高ボラ 2023-02 -15.1% +325.9% 新易盛（300502.SZ） A株高ボラ 2023-02 -14.2% +2113.4% 寒武紀（688256.SS） A株高ボラ 2023-02 -6.4% +1303.4% 工業富聯（601138.SS） A株高ボラ 2023-02 -3.5% +525.5% 中際旭創（300308.SZ） A株高ボラ 2023-03 -17.7% +814.9% 勝宏科技（300476.SZ） A株高ボラ 2023-04 +14.8% +1578.2% スーパーマイクロ（SMCI） 米株高ボラ 2023-05 -0.5% +175.2% Palantir（PLTR） 米株高ボラ 2023-05 -17.5% +1790.4% Marvell（MRVL） 米株高ボラ 2023-05 -7.1% +101.9% 常山北明（000158.SZ） A株高ボラ 2023-08 +4.9% +205.8% Arm（ARM） 米株高ボラ 2023-11 -3.6% +113.5% 浙江東方（600120.SS） A株テーマ高ボラ 2025-01 +2.9% +33.1% 美格智能（002881.SZ） A株テーマ高ボラ 2025-01 +9.9% +22.5% 優刻得（688158.SS） A株テーマ高ボラ 2025-01 +7.6% +192.3% 青云科技（688316.SS） A株テーマ高ボラ 2025-01 +9.7% +143.8% 拓維信息（002261.SZ） A株テーマ高ボラ 2025-01 +15.3% +116.3% Anthropic が Claude の新しい Constitution を公開。 モデルの価値観、訓練目標、行動規範が可読な完全ドキュメントとして公開され、安全性とガバナンスは付録から製品資料へと格上げされた。Anthropic：Claude\u0026rsquo;s Constitution Google が 2026 年 1 月の AI アップデートを総括。 Gemini が Chrome、検索、自動ブラウジングにさらに浸透し、AI 製品は質問に答えることから、複数ステップのタスク代行へと進化し始めている。Google：2026 年 1 月の AI アップデート 今月の判断： 2026年の競争の焦点は、「さらに文章を生成できるか」ではなく「ユーザーに代わって物事を前に進められるか」になっている。\n2月：推論モデルが研究の協業へ（2513.HK +20.6%） 市場記録： 智譜と MiniMax の香港株式取引は、上場時のムードから流通株式・ロックアップ解除・ valuation ゲームへと移行しており、香港株式のハイテク銘柄は分散している。米国株式市場の AI 銘柄は依然として設備投資と推論需要を中心に価格形成されており、新たな世界的な統一テーマ株は今のところ存在しない。香港取引所：智譜と MiniMax による空売りが認可\n怪物株累計表（2026年2月まで、月末調整後終値の複合；エヌビディアをリード銘柄として対照）\n対象銘柄（コード） タイプ 掲載月 当月騰落率 掲載後累計騰落率 エヌビディア（NVDA） 中核リーダー対照 2022-11 -7.3% +1210.2% C3.ai（AI） 米株ハイボラティリティ 2023-01 -27.8% -28.7% BigBear.ai（BBAI） 米株ハイボラティリティ 2023-01 -21.4% +487.0% 崑崙万維（300418.SZ） A株ハイボラティリティ 2023-01 -19.8% +198.9% SoundHound AI（SOUN） 米株ハイボラティリティ 2023-02 +1.7% +333.1% 新易盛（300502.SZ） A株ハイボラティリティ 2023-02 +23.1% +2624.7% 寒武紀（688256.SS） A株ハイボラティリティ 2023-02 -16.6% +1070.4% 工業富聯（601138.SS） A株ハイボラティリティ 2023-02 -7.6% +478.0% 中際旭創（300308.SZ） A株ハイボラティリティ 2023-03 +6.6% +875.3% 勝宏科技（300476.SZ） A株ハイボラティリティ 2023-04 -17.5% +1284.5% Super Micro Computer（SMCI） 米株ハイボラティリティ 2023-05 +11.3% +206.3% Palantir（PLTR） 米株ハイボラティリティ 2023-05 -6.4% +1669.4% Marvell（MRVL） 米株ハイボラティリティ 2023-05 +3.5% +108.9% 常山北明（000158.SZ） A株ハイボラティリティ 2023-08 -17.2% +153.2% Arm（ARM） 米株ハイボラティリティ 2023-11 +21.0% +158.3% 浙江東方（600120.SS） A株テーマ株ハイボラティリティ 2025-01 -16.1% +11.7% 美格智能（002881.SZ） A株テーマ株ハイボラティリティ 2025-01 -22.2% -4.7% 優刻得（688158.SS） A株テーマ株ハイボラティリティ 2025-01 -0.4% +191.1% 青云科技（688316.SS） A株テーマ株ハイボラティリティ 2025-01 -16.7% +103.1% 拓維信息（002261.SZ） A株テーマ株ハイボラティリティ 2025-01 -6.4% +102.5% 智譜（2513.HK） 港株新規上場ハイボラティリティ 2026-02 +20.6% +20.6% Anthropic が Claude Opus 4.6 を発表。 コーディング、エージェント、コンピュータ操作、ツール呼び出し、検索がより高い能力クラスに引き上げられ、モデル開発会社は複雑なワークフローの獲得競争を続けている。Anthropic Newsroom Google が Gemini 3 Deep Think をアップデート。 専用の深層推論モードが科学、研究、エンジニアリングタスクへと拡張された。Google：Gemini 3 Deep Think 今月の見解： 推論モデルは試験やランキングから研究コラボレーションへと軸足を移しつつあるが、その真の価値は依然として、専門家による検証と再利用が可能かどうかによって測られる。\n3月：Agent が検索と記憶を補完（688256.SS +72.9%） 市場記録： AI 株式の分化は引き続き拡大しており、米株の大時価総額プラットフォームおよびコンピューティング能力サプライヤーは比較的安定している一方、港株の智譜、MiniMax、およびA株のコンピューティング能力チェーンは日中変動幅が大きい。「妖株」は単一のモデル名称から、流通規模が小さく、期待値の変化が速い銘柄へと移行している。\n妖股累計表（2026年3月まで、月末権利調整後終値の複合；エヌビディアをリーダー対照として）\n銘柄（コード） タイプ 組み入れ月 当月騰落率 組み入れ後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 -1.6% +1189.2% C3.ai（AI） 米国株ハイボラ 2023-01 +5.9% -24.5% BigBear.ai（BBAI） 米国株ハイボラ 2023-01 -11.1% +421.9% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -0.3% +198.0% SoundHound AI（SOUN） 米国株ハイボラ 2023-02 -20.1% +246.1% 新易盛（300502.SZ） A株ハイボラ 2023-02 +18.7% +3134.2% 寒武紀（688256.SS） A株ハイボラ 2023-02 +72.9% +1923.7% 工業富聯（601138.SS） A株ハイボラ 2023-02 +22.2% +606.3% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +50.8% +1370.7% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +31.7% +1723.4% スーパーマイクロ（SMCI） 米国株ハイボラ 2023-05 -29.7% +115.4% Palantir（PLTR） 米国株ハイボラ 2023-05 +6.6% +1786.2% Marvell（MRVL） 米国株ハイボラ 2023-05 +21.3% +153.4% 常山北明（000158.SZ） A株ハイボラ 2023-08 -1.1% +150.4% Arm（ARM） 米国株ハイボラ 2023-11 +18.7% +206.7% 浙江東方（600120.SS） A株テーマ株ハイボラ 2025-01 +0.0% +11.7% 美格智能（002881.SZ） A株テーマ株ハイボラ 2025-01 +2.2% -2.6% 優刻得（688158.SS） A株テーマ株ハイボラ 2025-01 +12.0% +226.1% 青云科技（688316.SS） A株テーマ株ハイボラ 2025-01 +0.9% +104.9% 拓維信息（002261.SZ） A株テーマ株ハイボラ 2025-01 +3.7% +110.0% 智譜（2513.HK） 香港株新規上場ハイボラ 2026-02 +25.2% +51.0% Google が Gemini Embedding 2 をリリース。 テキスト、画像、動画、音声、ドキュメントが同じマルチモーダルベクトル空間に統合され、検索と分類がエージェントの基礎レイヤー能力になりつつある。Google：Gemini Embedding 2 Gemini の Search Live、Canvas、アプリを横断する機能が引き続き拡張。 検索がリアルタイム対話、長時間タスクのワークスペース、プロファイル連携を同時に担うようになっている。Google：2026 年 3 月の AI アップデート 今月の判断： Agent のインフラは大規模モデルだけでなく、検索、メモリ、ファイル、搜索、跨アプリケーション権限も含む。\n4月：長期タスクが製品のライフサイクルと出会う（2513.HK +83.8%） 市場記録： 市場はAI製品の定着率、コスト、キャッシュフローを株価のナラティブに組み込み始め、コンセプト株のバリュエーションの柔軟性は低下している。米国株の大手企業、香港株のAI新規上場株、中国A株のコンピューティング関連株はそれぞれ独自の相場を展開しており、新たな市場横断的なテーマ株は形成されていない。\n妖怪株累計表（2026年4月まで、月末復権終値の複合；エヌビディアをリード銘柄として対照）\n銘柄（コード） タイプ 組入月 当月騰落率 組入後累計 エヌビディア（NVDA） 中核リーダー対照 2022-11 +14.4% +1374.9% C3.ai（AI） 米株ハイボラ 2023-01 +4.9% -20.8% BigBear.ai（BBAI） 米株ハイボラ 2023-01 +13.1% +490.2% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 -10.1% +167.9% SoundHound AI（SOUN） 米株ハイボラ 2023-02 +15.9% +301.1% 新易盛（300502.SZ） A株ハイボラ 2023-02 +34.4% +4246.7% 寒武紀（688256.SS） A株ハイボラ 2023-02 +15.0% +2227.3% 工業富聯（601138.SS） A株ハイボラ 2023-02 +16.7% +724.2% 中際旭創（300308.SZ） A株ハイボラ 2023-03 +35.4% +1891.4% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 +12.2% +1945.8% スーパーマイクロ（SMCI） 米株ハイボラ 2023-05 +20.3% +159.1% Palantir（PLTR） 米株ハイボラ 2023-05 -4.9% +1693.7% Marvell（MRVL） 米株ハイボラ 2023-05 +66.8% +322.7% 常山北明（000158.SZ） A株ハイボラ 2023-08 -10.9% +123.1% Arm（ARM） 米株ハイボラ 2023-11 +39.0% +326.3% 浙江東方（600120.SS） A株テーマハイボラ 2025-01 -13.8% -3.7% 美格智能（002881.SZ） A株テーマハイボラ 2025-01 +16.3% +13.3% 優刻得（688158.SS） A株テーマハイボラ 2025-01 -14.1% +180.1% 青云科技（688316.SS） A株テーマハイボラ 2025-01 -11.5% +81.3% 拓維信息（002261.SZ） A株テーマハイボラ 2025-01 -16.3% +75.8% 智譜（2513.HK） 港株新規上場ハイボラ 2026-02 +83.8% +177.5% Anthropic が Claude Opus 4.7 を発表。 コーディング、エージェント、ビジュアル、長尺タスクの能力がさらに強化され、モデル競争はより長期的なタスクへと向かいつつある。Anthropic ニュースルーム Sora 製品がサービス提供を終了。 動画生成の技術的インパクトは依然として存在するが、単一プロダクトのユーザー数、コスト、商業的リターンはモデルデモによって自動的に保証されるものではない。OpenAI：Sora リリースページ内のサービス状況説明 今月の判断： AI 製品も同様にライフサイクルやユニットエコノミクスの検証を受けるべきであり、モデルの能力が高いことが必ずしも製品が長期的に存続できることを意味するわけではない。\n5月：AIアプリケーションが実行システムへ（SMCI +68.2%） 市況メモ： AI 設備投資は依然として米国株のメインストーリーだが、資金はモデルの呼び出しを収益に変換できるソフトウェアやアプリケーションを探し始めている。A株市場ではコンピューティングパワー、光モジュール、PCBがローテーションし、港股（香港株）のAI新規上場銘柄はボラティリティが高く、投機的な小型株と主導株の差がより明確になっている。\n怪物株累計表（2026年5月まで、月末復権終値の複合；エヌビディアをリーダー対照）\n銘柄（コード） 種別 組入月 今月の騰落率 組入後累計騰落率 エヌビディア（NVDA） 中核リーダー対照 2022-11 +5.8% +1460.4% C3.ai（AI） 米国株高ボラティリティ 2023-01 +22.0% -3.3% BigBear.ai（BBAI） 米国株高ボラティリティ 2023-01 +26.6% +647.2% 崑崙万維（300418.SZ） A株高ボラティリティ 2023-01 -8.1% +146.2% SoundHound AI（SOUN） 米国株高ボラティリティ 2023-02 +13.1% +353.7% 新易盛（300502.SZ） A株高ボラティリティ 2023-02 +20.5% +5137.8% 寒武紀（688256.SS） A株高ボラティリティ 2023-02 +21.8% +2734.6% 工業富聯（601138.SS） A株高ボラティリティ 2023-02 -1.7% +710.2% 中際旭創（300308.SZ） A株高ボラティリティ 2023-03 +9.4% +2078.5% 勝宏科技（300476.SZ） A株高ボラティリティ 2023-04 -6.0% +1823.1% スーパーマイクロ（SMCI） 米国株高ボラティリティ 2023-05 +68.2% +335.8% Palantir（PLTR） 米国株高ボラティリティ 2023-05 +12.5% +1918.0% Marvell（MRVL） 米国株高ボラティリティ 2023-05 +24.1% +424.6% 常山北明（000158.SZ） A株高ボラティリティ 2023-08 -15.7% +88.1% Arm（ARM） 米国株高ボラティリティ 2023-11 +68.0% +616.1% 浙江東方（600120.SS） A株テーマ高ボラティリティ 2025-01 -9.9% -13.2% 美格智能（002881.SZ） A株テーマ高ボラティリティ 2025-01 -19.8% -9.2% 優刻得（688158.SS） A株テーマ高ボラティリティ 2025-01 -5.0% +166.1% 青云科技（688316.SS） A株テーマ高ボラティリティ 2025-01 -12.7% +58.3% 拓維信息（002261.SZ） A株テーマ高ボラティリティ 2025-01 -5.6% +65.9% 智譜（2513.HK） 港株新規上場高ボラティリティ 2026-02 +31.9% +266.1% Google I/O 2026 が Gemini 3.5 Flash と Gemini Omni を発表。 Gemini が「agentic era」に突入し、モデルは入力、推論、行動、動画制作を同時に処理し始める。Google：I/O 2026 概要 Google が Agent、Search、Gemini App、開発プラットフォームを一連の製品アップデートに統合。 検索、ショッピング、コード、パーソナルアシスタントの境界は融合し続けている。Google：I/O 2026 今月の判断： 「AI アプリケーション」は、もはや独立したチャットボックスというよりも、検索、オフィス、デバイス、開発ツールにまたがる実行システムのようなものになりつつある。\n6月：エッジモデルが公開市場と出会う（MRVL +45.3%） 市場記録： エッジモデルにより、Apple、携帯電話、ストレージのバリューチェーンが再びAIの値決めに参加するようになり、公開市場ではモデル会社の資金調達と損失に対する疑問の声が上がり始めている。A株では中際旭創、新易盛、勝宏科技などが高値圏で揉み合い、港股では智譜、MiniMaxのロックアップ解除と流通株の変化が新たな取引変数となっている。\n妖股累計表（2026-06 まで、月末権利調整後終値の複合；エヌビディアをリーダーの対照として）\n銘柄（コード） タイプ 組入月 今月騰落率 組入後累計騰落率 エヌビディア（NVDA） 中核銘柄（参考） 2022-11 -5.1% +1380.8% C3.ai（AI） 米株ハイボラ 2023-01 -15.6% -18.4% BigBear.ai（BBAI） 米株ハイボラ 2023-01 -27.2% +444.0% 崑崙万維（300418.SZ） A株ハイボラ 2023-01 +22.4% +201.4% SoundHound AI（SOUN） 米株ハイボラ 2023-02 -28.1% +226.2% 新易盛（300502.SZ） A株ハイボラ 2023-02 -13.8% +4415.0% 寒武紀（688256.SS） A株ハイボラ 2023-02 -12.3% +2385.9% 工業富聯（601138.SS） A株ハイボラ 2023-02 -8.1% +644.6% 中際旭創（300308.SZ） A株ハイボラ 2023-03 -13.9% +1775.7% 勝宏科技（300476.SZ） A株ハイボラ 2023-04 -21.5% +1409.6% スーパーマイクロ（SMCI） 米株ハイボラ 2023-05 -36.4% +177.1% Palantir（PLTR） 米株ハイボラ 2023-05 -25.5% +1403.4% Marvell（MRVL） 米株ハイボラ 2023-05 +45.3% +662.3% 常山北明（000158.SZ） A株ハイボラ 2023-08 +3.7% +95.0% Arm（ARM） 米株ハイボラ 2023-11 +0.4% +619.0% 浙江東方（600120.SS） A株テーマ株ハイボラ 2025-01 +12.6% -2.3% 美格智能（002881.SZ） A株テーマ株ハイボラ 2025-01 +3.5% -6.0% 優刻得（688158.SS） A株テーマ株ハイボラ 2025-01 +1.2% +169.3% 青云科技（688316.SS） A株テーマ株ハイボラ 2025-01 +0.9% +59.7% 拓維信息（002261.SZ） A株テーマ株ハイボラ 2025-01 +14.5% +90.0% 智譜（2513.HK） 港株新規上場ハイボラ 2026-02 -22.1% +185.2% Apple、第3世代の Apple Foundation Models を発表。 オンデバイスモデル、サーバーモデル、Google と提携した基盤モデル体系が新世代の Apple Intelligence に統合された。Apple Machine Learning Research Anthropic、Claude Sonnet 5 を発表。 低コストモデルがブラウザ、ターミナル、ツール呼び出し、長時間タスクの実行を担うようになり、Agent 能力はより大規模な日常的な呼び出しへとさらに下沉している。Anthropic：Claude Sonnet 5 Anthropic、IPO 向け秘密書類を提出。 発行規模、価格、上場時期は未定だが、確実に言えるのはモデル企業が公開市場を選択可能な資本調達の経路として捉え始めたことである。AP：Anthropic confidential IPO filing 今月の判断： 端末側モデルと公開市場はそれぞれ異なる制約を代表している。前者は電力消費、プライバシー、レイテンシであり、後者は収益、損失、資金調達、キャッシュフローである。\n7月：コーディングエージェントが明確な主役に（NVDA +5.4%） 市場記録： 7月13日時点で、米株AI大手は依然としてコンピューティングパワー、クラウド、ソフトウェアプラットフォームの高位域でのローテーションが続いており、A株の光モジュールとPCB、港株の智譜およびMiniMaxはより高い弾力性を示しています。coding Agentは新たな市場ナラティブですが、すべてのAI株を同期して上昇させることはまだ証明されていません。\n怪物株累計表（2026年7月まで、月末復権終値複合；エヌビディアをトップ銘柄対照として）\n銘柄（コード） タイプ 掲載月 月次騰落率 掲載後累計 エヌビディア（NVDA） コア銘柄（基準） 2022-11 +5.4% +1460.8% C3.ai（AI） 米株（高ボラティリティ） 2023-01 -1.5% -19.6% BigBear.ai（BBAI） 米株（高ボラティリティ） 2023-01 -10.9% +384.7% 崑崙万維（300418.SZ） A株（高ボラティリティ） 2023-01 -2.5% +193.9% SoundHound AI（SOUN） 米株（高ボラティリティ） 2023-02 +2.6% +234.7% 新易盛（300502.SZ） A株（高ボラティリティ） 2023-02 -2.0% +4324.7% 寒武紀（688256.SS） A株（高ボラティリティ） 2023-02 -0.7% +2368.5% 工業富聯（601138.SS） A株（高ボラティリティ） 2023-02 -4.8% +608.9% 中際旭創（300308.SZ） A株（高ボラティリティ） 2023-03 +1.3% +1800.1% 勝宏科技（300476.SZ） A株（高ボラティリティ） 2023-04 +0.4% +1415.6% スーパーマイクロ（SMCI） 米株（高ボラティリティ） 2023-05 -3.5% +167.4% Palantir（PLTR） 米株（高ボラティリティ） 2023-05 +8.7% +1534.2% Marvell（MRVL） 米株（高ボラティリティ） 2023-05 -20.8% +503.7% 常山北明（000158.SZ） A株（高ボラティリティ） 2023-08 -2.5% +90.1% Arm（ARM） 米株（高ボラティリティ） 2023-11 -8.8% +555.7% 浙江東方（600120.SS） A株（テーマ株・高ボラティリティ） 2025-01 +1.4% -1.0% 美格智能（002881.SZ） A株（テーマ株・高ボラティリティ） 2025-01 -0.2% -6.2% 優刻得（688158.SS） A株（テーマ株・高ボラティリティ） 2025-01 -4.1% +158.2% 青云科技（688316.SS） A株（テーマ株・高ボラティリティ） 2025-01 -6.2% +49.8% 拓維信息（002261.SZ） A株（テーマ株・高ボラティリティ） 2025-01 +2.9% +95.5% 智譜（2513.HK） 港株（新規上場・高ボラティリティ） 2026-02 +0.3% +186.0% 7月8日、xAIがGrok 4.5を公開。 発表ページでは、コーディング、エージェント、知識労働を主な用途として挙げ、Cursor、Grok Build、APIを通じて提供している。xAI：Grok 4.5 AnthropicがClaude Codeの開発回顧を公開。 社内CLIからコーディングエージェントに至る過程が体系的にまとめられており、ソフトウェアエンジニアリングが長期間タスクのエージェントを検証する重要なワークフローであり続けていることを示している。Anthropic：The Making of Claude Code OpenAIがChatGPT Workを公開。 エージェントがアプリ 今月の判断： 7月13日時点で、最も明確な製品の方向性依然是coding Agentであることは依然として変わらない；その強みはコードを書けることではなく、タスクを分割・実行・テスト・ロールバックできることにある。\nタイムラインの後、何を見るべきか エントリポイントはチャットからワークフローへ ChatGPT はまず、自然言語がソフトウェアの入り口になり得ることを証明しました。GPT-4、プラグイン、マルチモーダル、検索によって、その入り口はファイル、ネットワーク、外部ツールへとつながりました。2025 年以降、deep research、Claude Code、Codex および各種ターミナルエージェントによって、タスクチェーンはさらに長く引き伸ばされています。ユーザーが受け取るのはもはや単なる回答ではなく、研究成果、変更の一連の内容、テスト結果一式、あるいはそのまま稼働させ続けられるプロジェクトです。\nオープンウェイトとクローズドソースサービスはそれぞれ異なるコストを負担する ルート 得られるもの 支払うもの 適合する問題 クローズドソース API 素早いアップデート、製品の完成度、エンタープライズサポートとサービスの安定性 従量課金、クォータ、ベンダーロックイン、データ境界 迅速な立ち上げ、複雑な機能、統一されたデリバリが必要な場合 オープンウェイト ローカルデプロイ可能、ファインチューニング可能、データ境界をより制御可能 GPU、メモリ、運用ライセンス、アップグレードコスト プライベートデータ、ローカル実験、カスタムデプロイ ハイブリッドルーティング 単純なタスクはローカル化、複雑なタスクはクラウド呼び出し 評価、ルーティング、フォールバック、モニタリングが必要 コスト、プライバシー、機能の両立を重視するワークフロー 「オープン」であることは無料であることを意味せず、「クローズドソース」であることはエコシステムがないことも意味しない。真のデプロイ判断は、ライセンス、VRAM、コンテキスト長、推論速度、ツール呼び出し、障害処理、責任の所在に立ち返る必要がある。\nAIGC は生成素材から信頼性の競争へ移行 文章は事実確認が必要であり、画像は出典と著作権を確認すべきであり、動画は時間と素材を確認すべきであり、音声は身元の境界を考慮すべきである。生成コストが低下した後には、検証コストがむしろより重要になる。視覚的な完成度は証拠の連鎖に取って代わることはできず、モデルの自信を持った口調も、原始文書や再現可能な過程に取って代わることはできない。\nコーディングは最も早く検収できる Agent のシナリオである コード補完は出発点に過ぎません。本物のコーディングエージェントには、リポジトリの読み取り、制約の理解、ファイルの変更、コマンドの実行、テストの実行、失敗への対応、チェックポイントの保持、そして人間によるレビューとロールバックの可否が求められます。ソフトウェア工学には明確な納品境界があるため、汎用チャットよりもサブスクリプションや企業予算に組み込みやすい一方で、モデルが生成するすべてのコード行がテストと保守の対象となります。\nAI株はコンピューティングパワー（演算能力）の受注からキャッシュフローへ移行しなければならない AI 株は一斉に上昇する一本線ではない。初期の市場は参入と期待を買い、2023 年からは GPU 注文とデータセンターを買い、2025 年以降は単位推論コスト、アプリの支払い、設備投資、そしてモデル企業の資金調達能力がより重視される。上流は先に資金を受け取れるが、アプリ層はパイロット導入、調達、更新、利益検証を経てようやく収益化される。\n毎月の「市場記録」を振り返ると、3 回はっきりとしたテーマの移行が見られる。2023 年 5 月以前は、「生成 AI が入り口になるか否か」に市場が価格をつけていた。エヌビディアの決算発表後は、コンピュート注文とデータセンターが主要なテーマとなり、DeepSeek の衝撃後は、学習と推論をより安価に行えるかが再び問い直されるようになった。2026 年に入り、Zhipu や MiniMax などのモデル企業が香港株式市場に上場したことで、論点はモデルの発表会の単純な比較から、収益、損失、浮動株、ロックアップ解除といった事柄へと移ってきている。\n次に追跡する価値のある3つの表は次のとおりです：\nクラウド事業者の設備投資、注残、契約負債残額は、インフラ需要があとどれだけ続くかを決める。 モデル企業の売上、損失、推論コスト、顧客集中度、キャッシュフローは、能力を予算に転換できるかどうかを決める。 コーディングおよびエージェント製品の利用深度、手戻り率、テスト合格率、継続課金は、「タスクを遂行できる」ことが本当に「ビジネス価値がある」ことと等しいかを決める。 相場資料と記録の境界 ナスダック総合指数の履歴 と ナスダック市場データ Yahoo Finance：エヌビディアの履歴、スーパーマイクロの履歴、C3.aiの履歴、SoundHound AIの履歴、Palantirの履歴、Armの履歴 Yahoo Finance：中際旭創の履歴、新易盛の履歴、寒武紀の履歴、工業富聯の履歴、智譜の履歴 上海証券取引所：株式データ、深セン証券取引所：相場 香港交易所：証券価格 本文の月次テキストおよび累計表は、Yahoo Finance の公開月次エントリと当月のニュースに基づいています。表には調整後終値を使用しており、当月分は 7 月 13 日時点の部分的な月次データとなっています。異なる市場の指数、通貨、および取引制度を無理に統合していません。Yahoo Finance は MiniMax（00100.HK）の有効な月次データを提供していないため、本文ではその騰落率を補完的に算出していません。文中の「妖株」は市場センチメントを振り返るための記述であり、投資助言を構成するものではありません。上場時期、空売りの適格性、ロックアップ解除、企業開示に関しては、証券取引所の公告を基準としてください。\n参考資料 OpenAI：Introducing ChatGPT OpenAI：GPT-4 research OpenAI：GPT-4o OpenAI：o3 and o4-mini OpenAI：deep research OpenAI：GPT-5 OpenAI：gpt-oss Anthropic：Claude 3 family Anthropic：Claude 3.5 Sonnet と computer use Anthropic：Claude 3.7 Sonnet と Claude Code Anthropic：Claude 4 Anthropic：Claude Sonnet 4.5 Google：Gemini Google：Gemini 2.5 Google：Gemini 3 Meta：Llama 2 Meta：Llama 3 Meta：Llama 3.1 Meta：Llama 4 DeepSeek：R1 Release [Apple：Apple Intelligence](https://www.apple.com/news 本記事は公開資料の整理と個人的な観察のみを目的としており、投資アドバイスを構成するものではございません。モデル、製品、価格、株価、企業開示は継続的に変化します。2026 年 7 月に関する内容は 7 月 13 日を区切りとしており、それ以降は最新の企業公告と原典の市況に戻ってご確認いただくようお願いいたします。\n写作附记 元のプロンプト 今のAI大事件は主に私の歴史記事の集約で、対応するタイムラインが不足している。各月ごとに、AI関連のニュース記録、ウェブ検索を追加し、各月のホットイベントを3つ以内に抑え、記事の構造もそれに合わせて調整する。\n初稿のオリジナルプロンプト 参考 2026 年度の重大イベントを新規作成し、AI 重大イベントを作成します。ChatGPT の登場から書き始め、2026 年度重大イベント、2025 年度重大イベント、2025 年の記事の中から削除が必要と思われる内容を削除し、AI 重大イベントに抽出してください。インターネットで調査し、AI 重大イベントにどのような内容を記載すべきか整理してください：大規模モデル能力の発展、オープンソースモデル、クローズドソースモデル、株価関連企業の株価変動、AIGC から現在ではコーディング競争が始まっているなど、内容は非常に多いため、大綱を整理してください。\n今ラウンドの元プロンプト AI の大きな出来事は、現在は毎月の主要な出来事を記録していますが、対応する出来事に伴う株式市場については記録していません。この AI ブームにおいて、株式市場もまた歴史的に稀な状況であり、毎月新たな出来事を最初に掲載し、その月の株価の動向を簡単に記録し、各「妖股（異常な値動きを示す銘柄）」を記録します。\n本改訂では、原稿の主題判断を時系列の後に保持し、主構造を年別・月別の記録に調整した。月次の事象は公開されている発表ページを主とし、予測・噂・提案中の資金調達を既成事実として記述することはしていない。\n","date":"2026-07-13","language":"ja","permalink":"https://ttf248.life/ja/p/ai-major-events/","tags":["AI霊感衝突坊","ai","大規模モデル","AIGC","AIプログラミング","オープンソースモデル","投資 (tōshi)"],"title":"AI 大事件","year":"2026"},{"categories":["メモ書き雑感"],"content":"断片的な考えや断片を記録するもので、単独で記事にするほどのものではない。年間記事はニュース年鑑ではなく、単独で読む価値のある長文の代わりでもない。それは、1か月の中で本当に判断を変え、価格を変え、あるいは日常生活に痕跡を残したものだけを残す。\n2026 年 7 月 12 日 現在、ここにはすでに起きたことだけを記録しています。8 月以降は場所だけ確保しておき、実際に起きた時点で追記します。予告を事実として扱いません。AI 関連の出来事は AI 大事件 に集約しており、このページではそれ以外の年間イベントを残します。\n2026 年 1 月 新年はルール変更から始まる 1月1日から、新たな規定が順次施行され、増値税法、改正後の治安管理処罰法および国家公園法などが新たな執行段階に入ります。これらの規定は突発的なニュースのように話題を呼ぶことはありませんが、この一年の基調を成しています。税制、公共秩序、生態保護のいずれにおいても、原則をより具体的で日常的なルールへと落とし込む作業が進められています。\n海外所得の自己点検に関するリマインダー 税務当局は、納税者に対して過去3年間の海外所得について自己点検を行うよう注意喚起しています。ここで一つの境界線を引く必要があります。これは公開報道における自己点検の注意喚起であり、すべての人が同じ通知を受け取ったわけではなく、一本の記事だけで申告義務の有無を判断できるわけでもありません。クロスボーダー所得、税額控除、税務上の居住者身分については、すべて各自の書類と正式な指針に立ち返る必要があります。\n小さな事柄もビジネスの真の構造を明らかにする 白酒の「開封红包」や支付宝富黒カードの特典調整は、表向きにはプロモーションや会員特典の変化だが、その根底にはいずれも既存顧客をめぐる競争がある。酒造企業は実際の開栓率を高めたいと考え、プラットフォームはコストを礼品からより持続可能なサービスへと移行させたいと考えている。これらはまだ年間レベルの大きな出来事とまでは言えないが、ここに記録しておく価値はある。「优惠」という二文字だけを見るのではなく、その利益が最終的に誰の負担となるのかを見極めなければならないという、自分自身への戒めのためである。\n遅すぎる別れ 実家の老人が亡くなった時、長年外で働いている人になって初めて分かるのは、距離によってただ最後の対面を逃すだけでなく、本来きちんと伝えられたはずの言葉が宙に消えてしまうこともあるということだ。アルツハイマー病は別れの始まりを早めるが、家族に明確な別れの瞬間を残してはくれない。これは公共のニュースではなく、この一年で最も残すべき個人的な一コマに過ぎない——電話ができるうちに、もう一通多く電話をかけておくこと。\n2026 年 2 月 ミラノ・コルティナ冬季オリンピック 2月6日から22日にかけて、ミラノ・コルティナ冬季オリンピックが開催されます。年中に行われる米加墨ワールドカップとともに、2026年における数少ない確実な世界的な公共イベントを構成しています。スポーツイベントの意義はメダル獲得だけではなく、市場の動きやモデルのランキングから一時的に目を離させることにもあります。\n「アメリカの斬殺ライン」がネット上の隠喩になる 「アメリカの斬殺ライン」はネットのミームから、生活費・医療・失業リスクをおおまかに表す隠喩へと変わった。この言葉は厳密な経済指標ではなく、貧困線や医療負担、家計資産のデータの代わりにはならない。記録する価値があるのは、「収入は低くなさそうに見えるのに、実際には余裕がない」という不安を率直に言い表しているからだ。\n小米の世代交代と電気自動車セクターの冷え込みは、この1か月の市場心理のもう一つの側面を示している。製品サイクルとバリュエーション期待が分離し始め、もはや業界の熱狂を個々の企業の利益検証の代替とは見なせなくなっている。\n2026 年 3 月 「十五五」期の開幕、政府活動報告が具体化 3月の全国两会（全国人民代表大会と中国人民政治協商会議）で政府活動報告が発表された。2026年は「第十五次五カ年計画」の初年度となる。報告では、内需拡大、新しい生産力の発展、雇用の安定、リスク防止が同じ任務表に掲げられている。一般の人々にとって、マクロ的な目標は最終的に消費、仕事、住宅、企業の受注に落とし込まれることになる。年間の記事ではまずこの方向性を記しておき、政策スローガンをすぐに投資の結論に変換するのは急がずにおく。\n2026 年 4 月 映画も、ウェブ小説も、白酒も、すべて同じ問題に直面している 茅台の純利益が初めて減少した、五一档（メーデー連休）の興行収入が2023〜2024年の水準を下回っている、それぞれ異なる業界で起きているが、いずれも「注目と信頼が繰り返し消耗されている」ことを示している。ユーザーは全く消費しないわけではなく、むしろ口コミや結果を待ってから、時間と金を預けるかどうかを決めるようになっている。\n松江大学街にあるスナック屋 「零食很忙」が松江大学城に進出したというニュースは小さなローカル情報に過ぎないが、低価格小売がいかにして適切な顧客層を見つけるべきかをよく示している。大学城は安定した若い客流を提供し、周辺の新しい市街地は店舗の家賃、通勤、そしてコミュニティ消費というもう一つの支えを与えている。低価格は万能の答えではなく、立地と人口密度こそが店舗が存続できるかどうかの前提条件なのである。\n突然死のニュースを目にして改めて出勤を見つめ直す 突然死のニュースが次々と目に飛び込んでくると、胸のもやもや一つだけでも、生活全体への問いに膨らんでしまう。長期間にわたる別居働きをなぜ続けるのか、貯めたお金で結局何を得ようとしているのか。医学的な問題は医師に任せるべきで、この一年のページには、それが突きつけた生活上の問い——仕事、結婚、健康、そして「低コストで躺平（寝そべり）したい」という空想——だけを残しておこう。どれか一つだけでは、残る三つを解決することはできない。\n2026 年 5 月 クロスポーダー証券業務、集中是正の期間に入る 証券監督管理委員会など8部門が「違法な越境証券・先物・基金管理業務の総合的な是正活動実施方案」を公布し、Futubull（富途）やTiger（老虎）といったインターネット証券会社が、市場で最も観察しやすい事例となっている。ここで最も避けるべき誤読は、是正の窓口期間が2年間の自由な営業期間とは限らないということ、また、禁止措置の解除に関する統計が株主の売却を意味しないということである。ルール、口座の境界、執行の詳細については、それぞれ別個に検討する必要がある。\n2026 年 6 月 ワールドカップ開幕、注目再び大型大会に 译文说明：该标题按字面意思翻译为\u0026quot;ワールドカップ開幕、注目再び大型大会に\u0026quot;。如需更自然流畅的表达，可译为\u0026quot;ワールドカップ開幕、大型大会が再び人々の関心を集める\u0026quot;。\n米加墨ワールドカップは6月に開幕します。これは史上初めて3か国が共同で開催し、48チームに拡大された男子サッカーのワールドカップです。大会によってもたらされるトラフィック、旅行、広告ビジネスは、今後数か月でAI、消費、短編動画と同じ注意力をめぐって競合することになります。\n2026 年 7 月 2026 年 8 月 まだ発生しておらず、補完が必要です。\n2026年9月 まだ発生していないため、追記が必要。\n2026年10月 まだ発生しておらず、追記が必要です。\n2026 年 11 月 まだ発生していないため、追記が必要です。\n2026年12月 まだ発生しておらず、後で補完する。\n参考資料 国務院弁公庁による2026年一部祝日の安排に関する通知 2026年政府活動報告解読、中国政府網 違法な越境証券・先物・基金経営活動の包括的取締り実施方案、中国証券監督管理委員会 中国証券監督管理委員会による特別行動に関する記者への回答 2026年ミラノ・コルティナ冬季オリンピック、Olympics.com FIFAワールドカップ2026 公式情報 Gemma 4 公式リリース、Google 2026年「メーデー」興行収入が昨年を上回る、国家映画局 智譜関連主体による2026年7月9日付け新H株割当公告、香港取引所 MiniMaxによる2026年7月10日付け新株割当及び転換社債発行公告、香港取引所 ","date":"2026-07-12","language":"ja","permalink":"https://ttf248.life/ja/p/2026-major-events/","tags":["年間総括","大事件","随想"],"title":"2026 年度の大きな出来事","year":"2026"},{"categories":["金融知識データベース"],"content":"7月10日の引け値で、Zhipu（02513.HK）は19.29%安、MiniMax-W（00100.HK）は9.68%安だった。この数字だけを見れば、「資金調達のニュースは意味がない」という単純な結論に至りやすい。しかし、その日の値動きは一直線ではなかった。午前から昼過ぎ早盤にかけて、MiniMax-W の下落率は一時さらに深くなったが、午後には持ち直した。一方、Zhipu は下げ止まらず、終値でより大きく下落した。\n同じ週に、二社はロック解除された株式と新たな資金調達スキームに直面する。ここでは3つの異なる価格が存在する。当日のセカンダリー市場の約定価格、特定投資家への新株割当価格、転換社債が将来的に株式へ転換され得る価格である。これらをまとめて「市場評価」とすると、結論は歪んでしまう。\nまず価格経路を見る ロック解除は同日ではなかった。香港株式メディア「港股解码」の統計によると、智譜（Zhipu）の約2,568.16万株の基石投資家持ち分は7月8日にロック解除され、総発行済株式の約5.76%に相当する。MiniMaxの約1.46億株は7月9日にロック解除され、総発行済株式の約46.44%に相当し、ロック解除前の自由流通株式は6%未満だった。これはメディアによる統計であり、実際の売却に関する会社の開示ではない。これは潜在的な供給量の規模の違いを示すものであり、これらの株式が当日実際に売却されたことを証明するものではない。\n日足でまず概要を示す。ロックアップ解禁後の 7 月 9 日、智谱は上昇して引け、Konka-W は下落して引けた。7 月 10 日には両銘柄とも下落し、智谱の売買代金と引け値の下落率がより大きかった。\n日付 企業 始値 高値 安値 終値 終値騰落率 売買代金 7月8日 智谱 1,563.0 1,918.0 1,450.0 1,825.0 +13.35% 本文では記載しない 7月8日 MiniMax-W 323.8 389.8 311.0 362.6 +12.0% 本文では記載しない 7月9日 智谱 1,879.0 2,222.0 1,803.0 2,032.0 +11.34% 本文では記載しない 7月9日 MiniMax-W 359.8 397.4 283.8 297.4 -17.98% 本文では記載しない 7月10日 智谱 1,850.0 1,999.0 1,597.0 1,640.0 -19.29% 約132.60億香港ドル 7月10日 MiniMax-W 280.4 291.6 248.4 268.6 -9.68% 約35.94億香港ドル 価格単位は香港ドル。騰落率は前取引日の終値に基づいて算出。データはTencentファイナンスの相場インターフェースから取得しています。解禁数量および比率は前述のメディア統計によるものであり、日足データとは出典および算出基準が異なります。\n時間帯ごとに二つのナarrativeを分解するとこうなる。MiniMax-W は午前中と午後の早い時間帯により大きな下落を受け、その後回復を見せた。智谱は午後の修復に追随せず、終盤にかけて下げ幅を拡大した。\n7月10日時点 智譜価格 / 前日比 MiniMax-W価格 / 前日比 当時下落幅が大きかった銘柄 9:31 1,946.0 / -4.23% 278.4 / -6.39% MiniMax-W 11:32 1,790.0 / -11.91% 251.4 / -15.47% MiniMax-W 13:42 本記事では同時刻の価格は掲載しない 248.6 / -16.41% MiniMax-W が日中安値に近い 14:48 1,698.0 / -16.44% 276.2 / -7.13% 智譜 終値 1,640.0 / -19.29% 268.6 / -9.68% 智譜 この表は価格の前後関係を示すことはできても、因果関係を示すことはできない。タイムスタンプ付きで検証可能な注文やニュース伝播の証拠がない限り、特定の時間拐点を資金調達ニュースに帰することはできず、解除規模から実際の減持規模を導き出すこともできない。\n新しいお金と古いお金の価格 MiniMax が 7 月 10 日に公告したのは、まだ完了していない一連の取引、すなわち 3,560 万株の新規 A 類株式の予定配售、および 65 億香港ドルのゼロクーポン担保付転換社債です。一方、智譜が 7 月 9 日に公告したのは、1,978 万株の新規 H 株の尽力募集による配售であり、その公告では当該取引が完了しない可能性があることが明確に示されています。\nIPOはすでに完了しています；下表の香港株式による追加資金調達は依然として提案中の取引です。公告に記載されている予想手取額を既存の現金残高と混同しないよう、状況欄は意図的に別立てとしています。\n会社 事項 ステータス 価格と金額 用途 MiniMax-W IPO 完了 発行価格 165 香港ドル；基本発行総額/手取り額 約 48.176 億/45.961 億香港ドル；オーバーアロットメントオプション完全行使後の手取り額 約 52.9339 億香港ドル 研究開発 90%、運転資金 10% 智譜 IPO 完了 発行価格 116.20 香港ドル；基本発行総額/手取り額 約 43.481 億/41.734 億香港ドル；オーバーアロットメントオプション完全行使後の手取り額 約 48.962 億香港ドル 汎用大規模モデル研究開発 70%、MaaS 10%、パートナーネットワーク及び戦略的投資 10%、運転資金 10% MiniMax-W 新規 A 種株式の私募配售 提案中、条件付き 3,560 万株、1株あたり 268 香港ドル；総額/手取り額 約 95.408 億/94.9141 億香港ドル 転換社債と合計した手取り額のうち、80% を AI インフラおよびモデル研究開発に投資予定、10% をグローバル展開、10% を運転資金及び一般用途 MiniMax-W 無利子の保証付き転換社債 提案中、条件付き 元本 65 億香港ドル、2027 年満期；当初転換価額 335 香港ドル；手取り額 約 64.658 億香港ドル；全額転換シナリオで約 1,940.3 万株増加 同上 智譜（香港取引所公告主体は Knowledge Atlas） 新規 H 株のベストエフォート配售 提案中、完了しない可能性あり 1,978 万株、1株あたり 1,588 香港ドル；総額/手取り額 約 314.1064 億/313.7495 億香港ドル モデル研究開発人材、計算能力および関連技術サービス；事業拡大および戦略的投資；資本構造および一般運転資金。2027年末までに使用予定 MiniMax の2つの取引がともに完了すれば、総額は約160億4,080万香港ドル、純額は約159億5,720万香港ドルとなる。この金額は、オーバーアロットメント権が全額行使された後の IPO 純額のおよそ3倍に相当する。Zhipu の擬配售純額も、同基準での IPO 純額のおよそ6.4倍に達する。数字は大きいが、それが自動的に好材料とは限らない。資金は投資サイクルを延長させる一方、1株あたりの将来キャッシュリターンに対するより厳格な問いかけももたらす。\n配售价は、資金調達がどのような条件でまとまったかを示すものではあっても、会社全体の Valuation や目標株価を示すものではない。MiniMax-W の 268 香港ドルという配售价は、7 月 9 日の終値 297.4 香港ドルから 9.89%のディスカウントとなっている。智谱の 1,588 香港ドルという配售价は、7 月 8 日の終値 1,825 香港ドルから 12.99%のディスカウントとなっている。開示内容、比較基準、取引方式が異なるため、「どちらの企業が市場からより深いディスカウントを受けたか」をこのデータから単純に比較することはできない。\n転換社債には債券属性、期間、および転換選択権というもう一層の要素が加わるため、335香港ドルの当初転換価格は普通株式の配售价と並べて、単純に MiniMax に対する市場の評価額とみなすことはできない。二級市場の終値は、あくまで当日における流通株式数、リスク選好、および情報集合の下での限界的な取引価格であり、会社側が資金調達時に取得した全体の価格設定ではない。\nIPO時期に近かった際の潜在的な株式価値は、その後異なる取引構造に組み込まれた IPO 発行価格に IPO 後の発行済み株式数を掛けて算出すると、MiniMax の暗黙的な株式価値は約 517.5 億香港ドル、智譜は約 518.0 億香港ドルとなります。この計算は、あくまで同一の IPO 時点で両案件の発行に基づく株式価格を復元したものであり、その後の時価総額を示すものではなく、公表されたポストマネー評価額を代替するものでもありません。\nこの2件の近いタイミングの案件は、今週の再融資を理解するうえで手がかりになる。MiniMaxが提示した組み合わせは普通株式と転換社債であり、一部は決済・発行を経て新規株式となり、もう一方はまずは負債として入り、転換されるかどうかは条件と保有者の選択次第となる。智譜は大型の普通株式のベストエフォート増資で、新規株式の発行と資金調達の完了に関する不確実性が、いずれもより直接的に取引のテーブル上に載せられている。\nこの種のアナウンスメント日において、市場は単に「誰かが出資する意思があるか」だけに応えるわけではない。同時に、新たに取引可能となる株式または潜在株式の数、資金調達のディスカウント、資金調達の完了可否、資金の投入スピード、そして既存株主による解禁後の流動性ニーズも衡量する。MiniMax が直面する潜在的な流通株式の供給規模は明らかに大きく、智谱は IPO の規模を大幅に上回る尽力配售に直面している。これらは 7 月 10 日の騰落に対する単一の帰結ではなく、分化を説明するための検証可能な背景である。\nA株にはもう一ラウンドあるが、金額は事前に計算に入れることはできない 両社とも、提案されている人民元建て株式に関する事項を開示しているが、進捗状況や情報量は異なっている。\n企業 開示事項 現時点で確認できること MiniMax-W 5月31日、人民元建て株式の発行意向を公告 規模、金額、用途、完了時期は未開示であり、実施を保証するものではないことが明記されている Zhipu 6月1日、科創板における3,876.8964万株を超えない新規A株の発行意向を公告（オーバーアロットメントを含まない） 価格は未決定、正式な契約はまだ存在しない。150億元人民元は投資予定のプロジェクト総額であり、調達済み資金ではない。その内訳は汎用基盤モデル120億元、MaaS 20億元、運転資金補填10億元 この表にある 150 億元を智譜がすでに保有している現金に加算するのは、よくある誤読です。これはプロジェクトの投資計画であり、実際に発行できるか、どの価格で発行できるか、最終的にどれだけを募集できるかは、今後の手続きと開示次第です。MiniMax の公告情報はさらに一段前で、計画金額と用途すら示されていません。\n大規模モデルの資金調達がここまで続いている中、市場は一体何を見ているのか 大規模モデル企業の資金の使い道は非常に似通っている。モデル、演算能力、インフラ、製品、そしてグローバル化だ。同じ使い道だからといって、同じ成果が出るとは限らない。この段階において、市場の資金調達に対する判断には少なくとも以下の4つの順序がある：\n取引が成立するか、そして実際の純額はいくらになるか。 現金残高、および将来のコンピュート、トレーニング、推論に関するコミットメントがどのように変化するか。 新規発行株式および転換可能性のある株式が、1株あたりの持分をどのように変えるか。 売上、総利益、現金消費量、そしてコンピュート単位あたりの効率が改善されているか。 リファイナンス（借り換え）によって、企業は次世代モデルへの投資を続けることができ、検証サイクルも次の決算報告書と次の資本構造の開示まで先送りされる。7月10日の取引時間中の強弱の入れ替わりと引けでの同時下落はほんの一側面に過ぎない。真の再評価は、現金が持続可能な収益に変わった後にしか答えが出ない。\n本記事は投資助言を構成するものではありません。\n参考資料 テンセント財経：智譜 02513 日足・分足行情；分足インターフェース。 テンセント財経：MiniMax-W 00100 日足・分足行情；分足インターフェース。 香港株解読：両社のロックアップ解除時期と流通株式数の統計。メディアによる統計であり、実際の減持データとはしない。 MiniMax：2026 年 7 月 10 日付のプレースメント及び転換社債発行に関する公告。 智譜関連主体：2026 年 7 月 9 日付の新 H 株プレースメントに関する公告。 MiniMax：IPO 最終発行価格及び配分結果；人民元建て株式発行に関する公告。 智譜関連主体：IPO 最終発行価格及び配分結果；科創板での A 株発行に関する公告。 写作附记 本文は、香港取引所の公告、行情（マーケットデータ）インターフェース、および明示的に付記されたメディア統計に基づいて執筆されている。再調達およびA株関連の事項は、いずれも公告時点の提案状態として取り扱っている。解禁（ロックアップ解除）統計は実際の売出を意味するものではなく、分時価格経路はニュースによる因果関係の証明を構成するものではない。\n元のプロンプト 智譜、Minimax は先週、初めてロックアップ解除の波を迎えた。過去の関連記事で内容を整理したが、実際にその時を迎えると、2社の株価の値動きは全く異なり、智譜は上昇、Minimax は下落した。その理由を分析する。その後、資金調達のニュースが伝えられたが、盘中では依然として Minimax の方が大きく下落し、場引けにかけて智譜が大幅に下落した。関連相場データを表にまとめる。\nIPO による資金調達規模を整理する。今週新たに発表された資金調達規模に対し、市場がこれら2社をどのように評価しているか。また、その後まだ1ラウンドの A 株による資金調達が予定されており、2社の資金の使途についても触れる。大規模モデルの資金調達がここまで続き、市場はどのように見ているのか。\n","date":"2026-07-10","language":"ja","permalink":"https://ttf248.life/ja/p/zhipu-minimax-unlock-financing-repricing/","tags":["AI霊感衝突坊","大規模モデル","資金調達","恒生指数 (こうせいしじょ)"],"title":"上場解禁と資金調達ニュースが同日に発表、ZhipuとMiniMaxはどのように再評価されたか","year":"2026"},{"categories":["コンピューター"],"content":"エンコーディングモデルに要件を書くとき、私はますます、リポジトリで検索できる名前をいくつか添える傾向があります。関数名、コンポーネント名、CSSクラス名、あるいはインターフェースパスなど。これらの言葉がなければ、モデルが対応できないわけではありませんが、たいていはまず「この文章はどのコードに対応するのか」を推測する時間を一回費やすことになります。\n例えば、次のように書きます。\nログインボタンの無効化状態を調整し、送信中に繰り返しクリックされないようにし、スタイルもグレーにする。\n人間はページ全体の印象から「ログインボタン」がどこにあるかを理解できるが、コーディングモデルは数十個のボタン、複数のログインエントリーポイント、コンポーネント・状態管理・スタイルファイルに散らばった実装に直面する可能性がある。まず自然言語の「ログインボタン」をリポジトリ内の具体的なシンボルにマッピングし、その上でイベント処理・状態変数・CSS のどれを修正すべきかを判断しなければならない。\n要件を以下のように変更すると、検索範囲はかなり小さくなります。\nLoginForm の handleSubmit における送信状態を調整します。送信中は .login-submit を無効化し、重複リクエストを防ぎます。既存のエラー表示の動作は変更しません。受け入れ基準: リクエストが完了していない状態で再度クリックしても 2 件目のリクエストは送信されず、ボタンは無効化されたスタイルになります。また、リクエスト完了後は元の状態に戻ります。\nここで本当に役立つのはプロンプトが長くなることではなく、コード上に落とせるアンカーが数枚増えることである。\nモデルが予測中、エージェントはまずコードを探す 現在の主流大規模言語モデルは、通常、入力をトークンに分割し、既存の文脈に基づいて後続のトークンを段階的に予測します。Transformer の自己注意機構により、シーケンス内のトークン同士が関連付けられるようになります。大規模な事前学習とそれに続くアラインメントを経ることで、モデルは指示に従い、コードを解釈し、修正案を生成することができるようになります。しかし、「文脈に基づいて生成できる」ということと、「現在のあなたのリポジトリ内のログインボタンの配置を自然に把握している」ということは同義ではありません。\nコーディングエージェントにはもう一つの層があります。ファイル検索、テキスト検索、読み取り、テストツールを呼び出して、リポジトリから関連コードをモデルのコンテキストに取り込みます。関数名 handleSubmit やクラス名 .login-submit はこの段階で二重の役割を果たします。\n第一の層は検索アンカーです。自然言語における「ログインボタン」は、文言、コメント、テスト、複数のコンポーネントと一致する可能性があります。正確なシンボルはテキスト検索ツールに直接渡すことができ、定義や参照、関連するテストを素早く見つけることができます。関連のないファイルを少し読む手間を省くことで、時間とトークンを節約できるだけでなく、無関係なコードが判断を妨げるのも軽減されます。\n第二の層は意味的な制約です。handleSubmit は変更が送信ロジックに関連することを示唆し、.login-submit は視覚的状態を特定のセレクタに限定し、LoginForm はコンポーネントの境界を提供します。これらが一体となって、「そもそもどのボタンなのか、状態はどの層に置くべきなのか」という曖昧さを減らします。モデルは依然として確率的に生成していますが、選択可能な解釈が減り、次のステップが正しいコードパスに沿って展開しやすくなります。\nだからこそ、私はこの書き方を「プロンプトのテクニック」ではなく「座標を提供する」と呼びたいのです。座標はモデルだけでなく、モデル外部のツールチェーンにも役立ってくれます。別のコーディングモデルに置き換えたとしても、リポジトリの検索が必要である限り、これらの座標は価値を持ち続けます。\n優れた要件は単なるキーワードの羅列ではない シンボル名だけでは不十分です。以下のような記述は検索しやすいものの、何に変更すべきか分かりません。\nLoginForm、handleSubmit、.login-submit を最適化してください。\n私が現在よく使っている書き方には、4種類の情報が含まれています。\n情報 役割 例 コードアンカー 検索範囲を絞り込む LoginForm、handleSubmit、.login-submit 目標とする挙動 変更後に何が起こるかを説明する 送信中は重複リクエストを禁止する 保持する項目 隣接する挙動の偶発的な変更を防ぐ 既存のエラー表示を変更しない 受入条件 実装とテストの終了点を提供する 2 回目のクリックではリクエストを送信せず、リクエスト終了後に復旧する ファイルパスやテスト名、インターフェース名、エラーメッセージもアンカーとして機能します。自分が確認した、識別性の高い名前を優先し、具体的に見せるためにすべての関連シンボルを詰め込む必要はありません。通常、一二つのエントリ関数や一つのコンポーネント、スタイル名で、エージェントが検索を始めるには十分です。その他の呼び出し関係は、エージェントにコードから検証させるべきであり、要件作成者が記憶から補完するべきではありません。\n誤った座標にも警戒が必要です。関数の名称が変更されていたり、クラス名が複数の場所で再利用されていたり、あるいは要件が実際には別のページを指しているような場合、精密だが間違ったキーワードは、モデルをより速く誤った方向へと導いてしまいます。安全な表現としては、「名称が変更されている可能性があるため、まず検索して確認してください」という一文を追加するか、ページの動作と表示されるテキストの両方を提供して、エージェントに相互検証させるといった方法が挙げられます。\nしたがって、より実用的な結論は「要件にキーワードを多く詰め込む」ことではなく、人のページに対する印象をリポジトリで检索可能な座標に翻訳し、さらに行動と受け入れ条件によって修正結果を制約することである。前者はコードを探すコストを減らし、後者は誤ったコードを書く余地を減らす。この両方が同時に存在して初めて、コーディングモデルの効率向上はより安定したものとなる。\n参考資料 Attention Is All You Need Language Models are Few-Shot Learners OpenAI Academy：AI fundamentals OpenAI：Why language models hallucinate 写作附记 元のプロンプト 大規模モデルでコーディングの要件を書く際に、関連する関数名やフロントエンドに関連するスタイル名などのキーワードを含めると、モデルの効率が向上します。LLMの原理を少し説明し、現在の 대규모モデルの原則を解説し、なぜこのようにする方がより優れているのかについて説明します。\nここでは「関数名やスタイル名を覚えればコーディング効率が上がる」という現場の判断をそのまま残しつつ、言語モデルによる生成とコーディングエージェントによる検索の違いを補足しました。Transformer の完全なチュートリアル、モデルの世代間比較、汎化的なプロンプト一覧は省いており、仕組みの説明が本来扱いたいエンジニアリング上の論点から目を逸らさないようにしました。\n","date":"2026-07-05","language":"ja","permalink":"https://ttf248.life/ja/p/code-anchors-for-llm-requirements/","tags":["AI霊感衝突坊","ai","LLM","AI プログラミング"],"title":"コードモデルにいくつかのコードアンカーを与える","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"今回の AI 株相場で最も違和感があるのは、「設備投資相場（キャップエックス強気相場）」だと叫ぶ人がいる一方で、多くの A 株や香港株が全く上昇していないどころか、むしろ大きく下落していることだ。一見矛盾しているように見えるが、実はこれは同じことの裏表に過ぎない。お金は依然として AI インフラや一部のアプリケーションの入口に集中しているが、二級市場（株式市場）はすでに、こうした設備投資を最終的にキャッシュフローに転換できるのは誰なのかを問い始めている。\nまず、あなたのいくつかの質問に直接お答えします。\nこの記事は3つの軸で読むことができる。北米大手には成長の糸口がないわけではなく、重い設備投資で次のカーブに賭けていること。プログラミングは現時点で最も収益化しやすいAIアプリケーションであること。智譜とMiniMaxの核心的な問題はストーリーの有無ではなく、バリュエーションとロック解除後の供給を市場が吸収できるかどうかである。\n北米の大企業の旧来の成長分野が限界効率の低下を迎える中、AIは数千億ドル規模の設備投資ストーリーを支えられる数少ない方向性として残った。クラウド、広告、検索、ソーシャル、eコマースは今もなお利益を上げているが、時価総額を引き続き高い倍率で評価し続けるには、次に十分な規模の成長曲線が必要となる。AIの特異な点は、それが新製品としても、クラウドコンピューティング、チップ、データセンター、電力、そしてエンタープライズソフトウェアの再投資サイクルとしても語ることができる点にある。\n「設備投資ブル（Capex Bull）」という言い方には道理がある。現在最も高く評価されているのは、必ずしもすでに AI による純利益を上げている企業ではなく、巨大テック企業の設備投資の最前線で収益を得ている企業である。すなわち、GPU、ASIC、HBM、光モジュール、サーバー、スイッチ、データセンター、電力設備、クラウドリソースである。問題もまさにここにある。設備投資の伸びが最終的な収益の実現よりも速い場合、株式はまず狭い範囲のブル相場として上昇し、その後、調整局面で真のキャッシュフローを持つ企業のみが残る。\n大手テック企業も資金的に余裕がなくなったのか？私の判断は、資金難になったのではなく、AI への投資額が大きすぎて、キャッシュフローが強い企業であってもバランスシートを最適化する必要が出てきた、ということです。ゴールドマン・サックスや JPMorgan などの機関は、近日のレポートやメディアでの転載において、2026 年の hyperscaler の設備投資額を 7,000 億ドルを超える規模と見積もっている。Axios も 6 月中旬に、Nvidia が大規模な債券融資のウィンドウに入ったと報じており、その背景には AI データセンターとサプライチェーンの債務融資が同時に拡大していることがある。潤沢なキャッシュと起債の継続は矛盾しない。これはむしろ一つのシグナルである。今回の上昇局面は資産軽量のインターネット株主導の牛市ではなく、資産集約型のバランスシート拡大局面である。\n注：原文中的「hyperscaler」、\u0026ldquo;capex\u0026rdquo;、\u0026ldquo;Nvidia\u0026rdquo;、\u0026ldquo;Axios\u0026rdquo;、\u0026ldquo;balance sheet\u0026rdquo; 等保持原样未译。\n投資家は換金を急いでいるのか？一部はその通りです。IPO、A+H上場、二級市場ロックアップ解禁、そしてM\u0026amp;Aは、いずれも一級市場の帳簿上の評価額を流動性に変換する経路です。特にZhipuやMiniMaxのような、上場後の流通株式数が極めて薄く、株価が指数への組入れや希少性によって押し上げられている銘柄については、解禁前後の核心は「会社が良いかどうか」という単純なものではなく、元々小さかった取引可能な供給が突然拡大し、市場が流動性プレミアムを再評価しなければならないという点にあります。\nプログラミング赛道がなぜ白熱化するのか？理由は直接的です。「汎用AIが世界を変える」よりも早く有料化の意思が見えるからです。開発者は業務効率化に対して月額料金を支払う意欲があり、企業はコード、テスト、移行、セキュリティ監査のために座席を購入する意欲があります。Anthropicは以前の公式資金調達資料で、Claude Codeのランレート売上が25億ドルを超えたことを明らかにし、OpenAIもCodexを企業向けのコーディングエージェントとして構築し、2026年のGartner企業向けAIコーディングエージェントのマジッククアドラントにおいて、毎週400万人以上がCodexを使用していることを強調しています。これからの競争は単なるモデルスコアの比較だけでなく、リポジトリのコンテキスト、権限制御、CI/CD統合、企業コンプライアンス、推論コスト、安定性で競うことになります。\n智譜（Zhipu）の香港株式時価総額は妥当か？2026年6月18日のYahoo Financeが返す 2513.HK の終値2094香港ドル、上場後の発行済み株式総数440,230,190株で大まかに計算すると、智譜の時価総額はおよそ9220億香港ドルである。1 2025年の同社売上高は7.243億元人民元である。為替換算を正確にしなくても、これは約1000倍のPSR（株価売上高倍率）の水準である。これは「やや高い」というレベルを超えており、非常に遠い将来の売上と利益でしか説明できない。智譜がモデル会社から中国のAIインフラプラットフォームに変わり、将来の売上が2桁規模で拡大すると信じない限り、現在の時価総額を今の財務諸表で支えるのは難しい。\n資金調達データをまず縦長のテーブルに変換します。\n対象 資本アクション 金額 / 評価額 OpenAI 公的による新たな資金調達ラウンド 1220億ドルのコミット資本；ポストマネー 8520億ドル Anthropic Series H 650億ドル；ポストマネー 9650億ドル SpaceX / Cursor 株式買収に関するメディア報道 約600億ドルの取引規模 Nvidia / AI債券による資金調達 大規模債券発行に関するメディア報道 約200億〜250億ドル 智譜 港股上場、科創板上場議案を推進 IPOによる調達額は約43億香港ドル；時価総額は約9220億香港ドル MiniMax 港股上場、A株上場ガイダンスを開始 IPOによる純調達額は約45.96億香港ドル；時価総額は約1540億香港ドル 私の判断は表の外に置いておく。OpenAI や Anthropic はもはや通常の SaaS 資金調達ではなく、インフラと入り口（ゲートウェイ）への資金調達である。Cursor が 600 億ドル規模の取引評価額に押し上げられたことは、プログラミングエージェントがツール競争から戦略的入り口競争へと移行したことを示している。Nvidia のようなサプライチェーンの中核企業も資金の期間（デュレーション）を長期化させ始めており、AI インフラの資金調達がますます資本市場におけるエンジニアリングの様相を帯びてきている。\nZhipu と MiniMax は別の問題を抱えている：二次市場は非常に高いフォワード・プラットフォーム・プレミアムを与えているが、彼らはさらに赤字、再資金調達、流通株式の拡大とロックアップ解除への対応に直面している。この表の意味は「すべての AI 企業が安全だ」ということではなく、資金調達がビジネスモデルの一部になっているということだ。資本が大きければ大きいほど、市場は 2 つの問いを突きつける：資金はこれからも流入し続けるのか、そしていつになったら売上がこれらの支出がサンクコストではないことを証明するのか。\nプログラミングがまずキャッシュフローの入り口になる 以前は誰もが汎用AIを作りたがっていました。なぜなら、汎用AIの物語が最も壮大だからです。しかし後に気づいたのは、最も壮大な物語が最速の収益還元に繋がるとは限らないということです。C(Consumer)エンドのチャット製品はトラフィックがありますが、課金率、リテンション、計算コスト、競争による補助金などが厳しい状況にあります。汎用エンタープライズアシスタントは効率化を語れますが、デリバリサイクルと社内コンプライアンスが重すぎます。一方、プログラミングは異なります。ソフトウェアの生産ライン上に直接立っているのです。\n開発者が毎月 20 ドル、100 ドル、200 ドルを追加で支払っても、数時間節約できるなら、それは簡単に納得できる。企業においても同様で、本当に地に足のついた使い方は「プログラマーを置き換える」というスローガンではなく、バグ修正、フレームワーク移行、テスト作成、コードレビュー、リファクタリング、社内ナレッジベースの連携、PR の作成といった場面だ。これらの場面には明確な作業対象、明確なビフォーアフターの比較、そして明確に料金を支払うユーザー層が存在する。\nつまり、OpenAI と Anthropic の競争は、ますます三層の戦場のようになっていくでしょう。\n第一層はモデルの能力である。誰がビッグコードベース、長コンテキスト、複数ファイルの変更をより安定的に読み取れるか、それがアドバンテージとなる。\n第二層はエンジニアリングのラッパーです。Codex、Claude Code、Cursor のようなツールは、本質的には単なるモデル呼び出しではなく、権限、ターミナル、サンドボックス、Git、テスト、ログ、ロールバック、人間のレビューも処理する必要があります。モデルが強くてもラッパーが貧弱であれば、開発者はすぐにうんざりしてしまいます。\n第3レイヤーはエンタープライズへの配布です。本当の大きな収益は、チームシート、プライベートコードのセキュリティ、監査ログ、IDEやCI/CDとの統合、管理者コンソールにあります。将来的には、多くの企業が単にチャットボットを購入するだけでなく、AIコーディングエージェントを研究開発インフラとして調達することになるでしょう。\nこの路線は今後、集中化の方向に進む可能性が高い。独自のモデルや計算能力、あるいは強力なディストリビューションを持たない独立系ツールは、上下から挟まれるリスクを抱えている。上流のモデルプロバイダーが値上げやレート制限を行えば痛手を負い、下流の巨大プラットフォームは機能をIDEやクラウドプラットフォーム、オフィススイートに直接組み込んでくる。CursorがSpaceXとの取引うわさで600億ドル規模の評価額に押し上げられたことは、プログラミングエージェントが単なる小さなツールではなく、戦略的な入口と見なされていることを示している。\n智譜（Zhipu）の時価総額が高い理由 智譜の問題は「AIストーリーを持っているかどうか」ではない。もちろん持っている。目論見書や年次業績が既に示しているように、モデルも企業顧客も研究開発投資も資本市場における存在感もある。問題は二級市場が割り当てる価格があまりに先進的すぎる点にある。\n最も大雑把な尺度で計算すると：\n\\[ \\text{粗略市売率} \\approx \\frac{\\text{総時価総額}}{\\text{年間売上}} \\]6月18日の終値2094香港ドルに440,230,190株を掛けると、時価総額は約9220億香港ドル。2025年の売上は7.243億元人民元。香港ドルと人民元の換算を気にしなくても、この比率は通常のソフトウェア株やクラウド会社、そしてほとんどの成長株が許容できる説明範囲を超えている。\nそれが合理的だと言うには、いくつかの事柄を同時に信じる必要がある。智譜（Zhipu）の今後の売上が数十億レベルではなく、数百億、数千億レベルに達すること。粗利益率がモデルの推論とデリバリーコストから確保できること。研究開発費が売上に占める割合が顕著に低下すること。そして国内の政務・エンタープライズ、インターネット、端末、開発者エコシステムが、長期にわたって予算を同社に投じる意思があること。\nこうした事柄は決して不可能ではないが、もはや「2025年の年次報告書を見て会社を買う」という話ではなく、2030年以降に生まれるかもしれないプラットフォームの地位に対して、今の時点で価格をつけるという話である。这种股票（この種の株）は、流通株式数が極めて小さいときには法外なほど上昇しうるが、ロックアップ解禁ともなれば、市場は改めて問いかけることになるだろう。――将来のキャッシュフローを見据えて買うのか、それとも単に希少で得がたい流動性を買っているのか、と。\n注：「这种股票」は文脈的に投資対象の銘柄を指しているため、「この種の株」と意訳しました。必要であれば「こうした銘柄」に置き換えても構いません。\nMiniMaxの Valuation も同様に安価ではない。6月18日時点の0100.HK終値497.6香港ドル、発行済株式総数309,255,668株で概算すると、時価総額は約1,540億香港ドルとなる。2025年の売上高は7,903.8万米ドルで、香港ドル換算で約6億香港ドル強。PSR（株価売上高倍率）も同様に数百倍レベルである。唯一の違いは、Zhipuの最新の時価総額がより突出しているのに対し、MiniMaxの7月の供給ショックがより大きいということである。\n七月の解禁で実際に何が変わったのか 禁解除表は二つの基準で見る必要がある：総株式数の基準と上場取引可能株式数の基準である。前者は潜在的な希薄化と既存株主の供給を見るものであり、後者は二級市場がその日にどれだけの株式を引き受けられるかを見るものである。幅の広い表が混在するのを避けるため、ここではまず流通盤の変化のみを示す：\n会社 ロックアップ解除前の流通 7月後の流通 智譜 2513.HK 約 1174 万株 約 3742 万株 MiniMax 0100.HK 約 1269 万株 上限約 1.66 億株2 智譜が上場した後の総株式数は440,230,190株である。7月7日に基石投資家が保有していた25,681,600株のロックアップが解除され、総株式数の約5.83%に相当する。これにより、理論上取引可能な供給は約1174万株から約3742万株に増加し、およそ3.2倍となる。\nMiniMax上場後の発行済株式総数は309,255,668株。7月8日に基石投資家16,504,040株のロックアップが解除され、既存株主は約136,997,480株の上限でコミットメントを解除できる。両者を合わせると発行済株式総数の約49.63%に上り、上限ベースで取引可能な供給は約1,269万株から約1.66億株付近まで急増する。\nこの表で最も誤読されやすいのは MiniMax である。その配分結果発表では、既存株主が保有する複数の Class A 普通株式のロックアップコミットメントが 2026 年 7 月 8 日に満了すると示されている。発表を一項目ずつ集計したところ、約 1.37 億株となり、市場報道で言及されている「総発行済株式数の約 44.29%」という数字と一致する。これに基石投資者の 1,650.4 万株を加えると、理論上の供給上限は総発行済株式数の約半分に達する。\nただし、ここで重要なのは、コミットメントの解除が、当日にすべて売却可能になるわけではないということです。公告の脚注では、一部の Pathfinder SII が 18C 規則に基づくより長期のロックアップ制約を受けると記載されています。さらに、既存株主の一部株式のロックアップ期間は、「ストックコネクトでの取引可能化後 20 営業日」または「上場後 9 か月」のいずれか早い方と規定されています。つまり、実際の売り圧力は、複数のロックアップの重複、株主の性質、ストックコネクトの進捗、二級市場の価格など複数の要因に依存します。本記事では上限の口径を用いており、読者に供給ショックの規模感を伝えることを目的としており、これらの株式がすべて同日に売却されるという意味ではありません。\n智譜の7月の制限解除はずっと少ない。基石投資家による2568.16万株の制限解除は、元々極めて薄い流通量を拡大させるが、本当の大規模な既存株主のロックアップ期間は2027年1月7日に設定されている。智譜の配分結果公告には明確に記載されている。18C規則の下では6ヶ月の要件があるが、すべての既存株主は適用される中国法に基づき、上場後12ヶ月間はその保有株式を処分してはならない。つまり、智譜にとって7月は初めての流通量拡大のタイミングであり、来年1月こそがより大きな供給の試練となる。\n大規模な時間ポイントを個別に列挙してください：\nZhipu、2026年7月7日：基石投資者25,681,600株のロックアップが解除され、発行済株式総数の約5.83%に相当。流通株式は極めて低い水準から拡大する。 Zhipu、2027年1月7日：既存株主の12ヶ月ロックアップが満了。このうち既に上場済みのH株は約1.78億株規模で、未上場内資株は転換および全流通アレンジメントの制約を受ける。これがより大きな潜在的供給のウィンドウとなる。 MiniMax、2026年7月8日：基石16,504,040株に加え、既存株主のコミットメント解除上限約136,997,480株。7月が主要なショック・ウィンドウとなるが、重複するロックアップ分を差し引く必要がある。 MiniMax、港股通（ストックコネクト）組入後20営業日または2026年10月8日のいずれか早い方：別バッチの既存株主株式、約5,695万株規模。これが10月より早くなるかは、港股通の取引可能時間に依存する。 MiniMax、2028年1月8日：支配株主の24ヶ月ロックアップが満了、約7,900万株規模。これは創業者および支配権に関連するチップに相当し、時期はより遠い。 したがって、7月に誰がプレッシャーを感じているかと問われれば、答えは直接的です。MiniMaxです。智谱も7月に流通枠を拡大しますが、本当の試練はもっと先にあります。MiniMaxの問題は、7月の理論上の供給が大きすぎることです。株価がまだ高いバリュエーション（評価）レンジにある場合、初期株主が全株を売却する必要はなく、市場はまず「売却される可能性」というリスクを織り込んで割引かれるでしょう。\nA株と香港株の多くがなぜ上昇していないのか このラウンドの株式市場は全面高の牛市ではない。A株・香港株は特に顕著で、多くの企業はAIの設備投資（capex）を直接享受しておらず、むしろ高金利、消費の弱さ、不動産チェーン、地方財政、輸出と内需の期待といった要因によって抑え込まれている。\nAI 関連株の強気相場で資金が流れるルートは限られている。まずは米国の大手ハイテク株と半導体チェーンを買い、そこから電力、データセンター、光通信、ストレージ、少数のアプリケーション入口へと広げていく。A 股や港股には「AI」と名のつく企業は多いが、実際に受注を売上へ、売上を粗利益へ、粗利益をキャッシュフローへと転換できる企業はそれほど多くない。市場が「AI 概念があるか」から「実際に業績に反映されているか」へと関心を移した瞬間、多くの銘柄は振り落とされることになる。\n香港株にはもう一つ追加の問題がある。多くのニューエコノミー企業は上場時の流通規模が小さく、短期的には希少性と指数の買いによって価格が大きく押し上げられる。しかしロックアップ解除の期限が来ると、市場は初めて実際の需給に直面する。智譜と MiniMax はまさにこの論理の縮図である。ハンセンテックへの組み入れ、滬港通・深港通への組み入れ期待、AI 関連銘柄としての希少性が買いを呼び込む一方で、ロックアップ解除、赤字、セカンダリーオファリング、高いPSR（株価売上高倍率）が買い手の慎重姿勢を招く。\n私の総合的な判断は次の通りです：AI には成長余地がないわけでもなく、AI が純粋なバブルであるわけでもない。しかし、この強気相場が主に支出によって牽引されるものであるなら、必然的に二極化が進むだろう。シャベルを売る企業がまず利益を受け、AI を高頻度の有料ワークフローに変換できる製品が次に利益を受け、汎用 AI の将来像だけを語り、キャッシュフローが見えない企業は、ますますバリュエーションを維持することが難しくなるだろう。\nプログラミング分野はその後も熾烈な競争が続く見通しです。なぜなら、ここは「AI がシート単位・使用量単位・チーム予算単位で収益を上げられる」と最も早く証明された方向性だからです。OpenAI、Anthropic、Cursor、そして大手 IDE/クラウドプラットフォームがこぞって参入してくるでしょう。そしてそれは「数行のコードを書く」レベルで止まるのではなく、ソフトウェアデリバリーのプロセス全体に食い込んでいきます。要件定義、コード、テスト、レビュー、デプロイ、セキュリティ、運用まで、すべてエージェントの収益化ポイントになり得ます。\nしかし、株式市場はすべての答えが明確になるのを待ってはくれない。ますは最もインフラに近い企業に高いバリュエーションを与え、その後、解禁、資金調達、債務、四半期決算、調整局面の中で少しずつ検証していく。今問われているのは「AIに未来があるのか」ではなく、現在の株価はすでにどのくらいの未来を織り込んでいるかである。\n本記事は公開されている資料の整理および個人的な分析を行うものであり、いかなる投資助言を構成するものでもありません。相場、時価総額およびロックアップ解除に関する数値は公告や市場の変化に応じて変動するため、具体的な取引判断は公式に開示された書類およびご自身のリスク許容範囲に基づいて行うようにしてください。\n参考資料 OpenAI: OpenAI raises $122 billion to accelerate the next phase of AI Anthropic: Anthropic raises $65B in Series H funding at $965B post-money valuation Anthropic: confidentially submits draft S-1 to the SEC OpenAI: named a Leader in enterprise coding agents by Gartner OpenAI: Codex for every role, tool, and workflow Axios: SpaceX will buy Cursor for $60 billion Axios: AI debt boom ramps up with Nvidia bond sale Business Insider: Goldman Sachs on AI capex supercycle MiniMax Group Inc. 招股書、HKEX（香港交易所）開示書類 MiniMax Group Inc. 配分結果、HKEX（香港交易所）開示書類 MiniMax Group Inc. 2025年度業績公告、HKEX（香港交易所）開示書類 北京智譜華章科技股份有限公司 招股書、HKEX（香港交易所）開示書類 北京智譜華章科技股份有限公司 配分結果、HKEX（香港交易所）開示書類 北京智譜華章科技股份有限公司 2025年度業績公告、HKEX（香港交易所）開示書類 Yahoo Finance：0100.HK、2513.HK、^HSI の履歴相場、取得日時は 2026-06-21；0100.HK は今回 2026-06-18 の1件のみ返されたため、これに基づく完全な履歴系列は展開していない。 写作附记 元のプロンプト $blog-writer 実はまだ腑に落ちないのですが、北米の大企業は新しい成長ポイントを見つけられなくなったのでしょうか？こぞってAIに参入していますが、このラウンドのブル市場を「支出ブル」と呼ぶ人もいるほどで、成り立っているのは大企業の投資によるところだとされています。資金調達データや最新の資金調達ニュースを分析して、表にまとめてください。この資金調達データをどう見ますか？大企業も資金的に余裕がなくなったのでしょうか？投資家も換金を急いでいるのでしょうか？以前は誰もが汎用AIを作ろうとしましたが、後になって、やはり収益を上げられることが大切だと分かり、プログラミングという分野は儲かるので、OpenAIやClaudeが競争しており、すでに白熱しています。今後はどう進むのでしょうか？香港市場のZhipuの時価総額は妥当ですか？7月にMinimaxやZhipuはロックアップ解除（解禁）の一波がありますが、解禁前後の流通株式データの変化を分析し、大規模な解禁はいつで、対応するデータ変化はどうなるかを示してください。今回の株式市場では、多くの株価が下落し、上がっておらず、A株や香港市場では特に顕著です。あなたはプロの金融アナリストとして、まず私の質問に答えてください。\n執筆思路の要約 この文章は、元となったプロンプトにある核心的な問題——支出の強気姿勢、資金調達ニュース、プログラミング分野、Zhipu の評価額、MiniMax と Zhipu のロックアップ解除、A/H 株の分化——を保っている。削ったのは検証できない絶対的な表現であり、たとえば「大企業はみな成長の糸口を見つけられない」「投資家は必ず現金化を急ぐ」といったものだ。\n本文では、資料を3つの階層に分類している。会社公式の資金調達と業績は一次情報であり、capex、社債、Cursor 取引については最新の状況を反映した最近の報道を背景に用いている。また、時価総額、浮動株数、解禁リストは、香港取引所の開示資料および 2026年6月18日時点の相場に基づく概算である。MiniMax の7月の解禁については、特に「上限ベース」および「重複ロック」を明記しており、理論上の供給量をそのまま当日の売り圧として記載することは避けた。\n本稿の香港株式の株価および時価総額の概算には 2026-06-18 の終値を使用しています。0100.HK については、今回の Yahoo Finance では 2026-06-18 の1件のみの気配が返されたため、それに基づいて MiniMax の完全な過去の値動きを提示していません。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n这里是理論上の上限枠です。MiniMaxの一部のPathfinder SIIおよびその他の株主は、18C規則、ストックコネクトの取引可能時間、その他のロックアップの取り決めによる制約を依然として受ける可能性があり、ロックアップ解除の約束は、すべての株式が同日に売却されることを意味するものではありません。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2026-06-21","language":"ja","permalink":"https://ttf248.life/ja/p/ai-capex-unlock-coding-cashflow/","tags":["AI霊感衝突坊","ai","投資・資金調達","恒生指数 (こうせいしじょ)","Zhipu","MiniMax"],"title":"AI 支出のブルは規制緩和の入り口へ","year":"2026"},{"categories":["コンピューター"],"content":"Hermes を SearXNG に接続すると、表面上は検索の問題を本機内に回収したように見えます：SEARXNG_URL=http://localhost:8888。しかし、国内サーバー（中華圏のサーバー）で実際に詰まりやすいのは Hermes から SearXNG への通信ではなく、SearXNG が独自に Google、DuckDuckGo、Brave、Startpage といった検索ソースへアクセスする部分です。\n最終的に、私はリンクを3層に分割しました。Hermes はローカルの SearXNG にのみアクセスし、SearXNG は設定内で HTTP/HTTPS のアウトバウンドリクエストを明示的に Mihomo に委ね、Mihomo が単独でサブスクリプション、ヘルスチェック、ノードの自動選択を担当します。この方法のメリットは「設定がかっこいい」ことではなく、問題発生時に階層ごとに確認できる点です。Hermes がローカル検索にリクエストを送ったか、SearXNG が JSON を返したか、Mihomo に利用可能なノードがあるか、そしてサブスクリプション自体の解析に失敗していないか。\n全体のフローは次のとおりです。\nHermes Agent -\u0026gt; http://localhost:8888 -\u0026gt; SearXNG -\u0026gt; http://mihomo:7890 -\u0026gt; Mihomo が利用可能なノードを自動選択 -\u0026gt; 海外の検索エンジン ホストマシンでローカルポートのみを公開する：\n127.0.0.1:8888 -\u0026gt; SearXNG 127.0.0.1:7897 -\u0026gt; Mihomo 混合プロキシ、デバッグ用 127.0.0.1:9097 -\u0026gt; Mihomo コントローラー、ローカル管理用 SearXNG と Mihomo は同じ Docker ネットワーク内にいるため、SearXNG はホストマシンの 127.0.0.1:7897 にアクセスせず、コンテナ名でアクセスします。\nhttp://mihomo:7890 SearXNG で最も見落とされやすい 2 箇所 Hermes が SearXNG を呼び出す際に JSON をリクエストします。SearXNG 公式 Search API ドキュメントにも明記されている通り、format パラメータを使用できるかどうかは settings.yml の search.formats で有効化されているかどうかに依存します。有効化されていないフォーマットをリクエストすると 403 が返されます。したがって、デフォルトの HTML だけを残しておくわけにはいきません。\nsearch: safe_search: 0 autocomplete: \u0026#34;\u0026#34; formats: - html - json 2つ目はプロキシです。Docker の環境変数やシステムレベルの http_proxy がアプリケーション層で安定的に継承されると過信しないでください。SearXNG のリクエストは独自に行われるため、最も直接的な方法は outgoing.proxies に明示的に記述することです。\noutgoing: request_timeout: 15.0 max_request_timeout: 40.0 extra_proxy_timeout: 10 proxies: \u0026#34;http://\u0026#34;: \u0026#34;http://mihomo:7890\u0026#34; \u0026#34;https://\u0026#34;: \u0026#34;http://mihomo:7890\u0026#34; SearXNG のデフォルト設定例では all://: という書き方が見られるため、自然に間違った設定項目ではないことが分かります。ただし、私が今回使用した環境では、all://: は期待通りにマッチせず、最終的に落ち着いたのは http:// と https:// を分けて記述する方法でした。記事内でこの境界を保持しているのは、ある一度の実測結果をすべてのバージョンにおける確定的な結論のように書いてしまわないためです。\n完全な SearXNG の主要な設定は以下のように圧縮できます。\nuse_default_settings: true general: instance_name: \u0026#34;Hermes SearXNG\u0026#34; search: safe_search: 0 autocomplete: \u0026#34;\u0026#34; formats: - html - json server: secret_key: \u0026#34;请替换成随机密钥\u0026#34; limiter: false image_proxy: true bind_address: \u0026#34;0.0.0.0\u0026#34; valkey: url: valkey://valkey:6379/0 outgoing: request_timeout: 15.0 max_request_timeout: 40.0 extra_proxy_timeout: 10 proxies: \u0026#34;http://\u0026#34;: \u0026#34;http://mihomo:7890\u0026#34; \u0026#34;https://\u0026#34;: \u0026#34;http://mihomo:7890\u0026#34; engines: - name: bing disabled: false shortcut: bi - name: bing news disabled: false shortcut: bin - name: google disabled: false shortcut: go timeout: 8.0 - name: brave disabled: false shortcut: br timeout: 8.0 - name: duckduckgo disabled: false shortcut: ddg timeout: 8.0 - name: startpage disabled: false shortcut: sp timeout: 8.0 - name: wikipedia disabled: false shortcut: wp - name: arxiv disabled: false shortcut: arx - name: sogou disabled: true - name: 360search disabled: true ui: static_use_hash: true ここでちょっとした落とし穴があります：SearXNG のデフォルトエンジン設定では、Bing ニュースの name は bing news であり、engine が bing_news です。use_default_settings: true の場合、engines は name でマージおよび上書きされるため、ここでは name: bing news と記述し、name: bing_news とは記述しないでください。\nMihoma がやることはただ1つ：SearXNG に安定した出口を与えること Mihomo はサーバー全体を引き継ぐ必要はなく、Docker をグローバルにプロキシ経由にする必要もありません。mixed port を 1 つだけ開いて、同じ Docker ネットワーク内の SearXNG がアクセスできるようにします:\nmixed-port: 7890 allow-lan: true bind-address: \u0026#39;*\u0026#39; mode: rule log-level: info ipv6: false external-controller: 0.0.0.0:9090 secret: \u0026#34;请替换成随机密钥\u0026#34; profile: store-selected: true store-fake-ip: true proxy-providers: sub: type: http url: \u0026#34;你的订阅地址\u0026#34; interval: 3600 path: ./proxy_providers/sub.yaml health-check: enable: true url: https://www.gstatic.com/generate_204 interval: 300 timeout: 5000 lazy: false expected-status: 204 proxy-groups: - name: AUTO type: url-test use: - sub url: https://www.gstatic.com/generate_204 interval: 300 timeout: 5000 tolerance: 50 lazy: false expected-status: 204 - name: PROXY type: select proxies: - AUTO - DIRECT use: - sub rules: - MATCH,PROXY この設定の意味はとても限定的です：購読は 3600 秒ごとに更新され、ノードは 300 秒ごとにヘルスチェックを行い、AUTO は url-test でレイテンシに基づいてノードを選択し、すべてのトラフィックは最終的に PROXY にマッチします。新しい設定が最初に起動されたとき、PROXY リストの最初にあるのは AUTO です。今後、コントロールパネルでノードを手動で切り替えた場合、store-selected: true が選択を保持するため、「デフォルトで AUTO を通る」とは限りなくなります。\nまた、サブスクリプション形式にも注意が必要です。proxy-providers は provider 形式、あるいは Mihomo が provider として解析できるサブスクリプションに適しています。サービス事業者によっては、完全な Clash 設定を返すものもあれば、ノードリストを返すものもあります。ログに解析失敗のエラーが出た場合、SearXNG を疑うのではなく、まずサービス事業者の管理画面で Clash Meta、Mihomo、Proxy Provider 形式に切り替えてください。\nMOD スクリプト このスクリプトは、SearXNG を /opt/searxng に配置済みのマシンを対象としています。既存の docker-compose.yml と searxng/settings.yml をバックアップし、本機にあらかじめ用意されている metacubex/mihomo イメージをそのまま利用し、SearXNG、Valkey、Mihomo を同じ compose プロジェクトにまとめます。\nこのスクリプトはMihomoのイメージを自動的にプルしません。SearXNGとValkeyについても、ローカルに対応するイメージがない場合、docker compose upが起動できるかどうかは、ローカルのイメージとネットワーク環境によって異なります。完全にオフラインの環境では、3つのイメージを事前にすべて用意しておいてください。\nsudo bash -s \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; set -euo pipefail APP_DIR=\u0026#34;/opt/searxng\u0026#34; COMPOSE_FILE=\u0026#34;$APP_DIR/docker-compose.yml\u0026#34; SETTINGS_FILE=\u0026#34;$APP_DIR/searxng/settings.yml\u0026#34; MIHOMO_DIR=\u0026#34;$APP_DIR/mihomo\u0026#34; if [ ! -f \u0026#34;$COMPOSE_FILE\u0026#34; ]; then echo \u0026#34;$COMPOSE_FILE が見つかりません。SearXNG が /opt/searxng にデプロイされているか確認してください\u0026#34; exit 1 fi if [ ! -f \u0026#34;$SETTINGS_FILE\u0026#34; ]; then echo \u0026#34;$SETTINGS_FILE が見つかりません。SearXNG settings.yml のパスを確認してください\u0026#34; exit 1 fi if docker image inspect metacubex/mihomo:latest \u0026gt;/dev/null 2\u0026gt;\u0026amp;1; then MIHOMO_IMAGE=\u0026#34;metacubex/mihomo:latest\u0026#34; else MIHOMO_IMAGE=\u0026#34;$(docker images --format \u0026#39;{{.Repository}}:{{.Tag}}\u0026#39; \\ | awk -F: \u0026#39;$1==\u0026#34;metacubex/mihomo\u0026#34; \u0026amp;\u0026amp; $2!=\u0026#34;\u0026lt;none\u0026gt;\u0026#34; {print; exit}\u0026#39;)\u0026#34; fi if [ -z \u0026#34;${MIHOMO_IMAGE:-}\u0026#34; ]; then echo \u0026#34;利用可能なローカル metacubex/mihomo イメージが検出されませんでした。\u0026#34; echo \u0026#34;先に確認してください：docker images | grep -i mihomo\u0026#34; exit 1 fi echo \u0026#34;ローカル Mihomo イメージを検出しました：$MIHOMO_IMAGE\u0026#34; LOCAL_MIHOMO_IMAGE=\u0026#34;searxng-mihomo-local:latest\u0026#34; docker tag \u0026#34;$MIHOMO_IMAGE\u0026#34; \u0026#34;$LOCAL_MIHOMO_IMAGE\u0026#34; printf \u0026#34;Clash/Mihomo の購読 URL を入力してください: \u0026#34; \u0026gt; /dev/tty IFS= read -r -s SUB_URL \u0026lt; /dev/tty printf \u0026#34;\\n\u0026#34; \u0026gt; /dev/tty if [ -z \u0026#34;$SUB_URL\u0026#34; ]; then echo \u0026#34;購読 URL が空のため、終了します。\u0026#34; exit 1 fi mkdir -p \u0026#34;$MIHOMO_DIR/proxy_providers\u0026#34; chmod 700 \u0026#34;$MIHOMO_DIR\u0026#34; TS=\u0026#34;$(date +%Y%m%d-%H%M%S)\u0026#34; cp -a \u0026#34;$COMPOSE_FILE\u0026#34; \u0026#34;$COMPOSE_FILE.bak.$TS\u0026#34; cp -a \u0026#34;$SETTINGS_FILE\u0026#34; \u0026#34;$SETTINGS_FILE.bak.$TS\u0026#34; echo \u0026#34;バックアップを作成しました：\u0026#34; echo \u0026#34; $COMPOSE_FILE.bak.$TS\u0026#34; echo \u0026#34; $SETTINGS_FILE.bak.$TS\u0026#34; MIHOMO_SECRET=\u0026#34;$(openssl rand -hex 16)\u0026#34; cat \u0026gt; \u0026#34;$MIHOMO_DIR/config.yaml\u0026#34; \u0026lt;\u0026lt;YAML mixed-port: 7890 allow-lan: true bind-address: \u0026#39;*\u0026#39; mode: rule log-level: info ipv6: false external-controller: 0.0.0.0:9090 secret: \u0026#34;$MIHOMO_SECRET\u0026#34; profile: store-selected: true store-fake-ip: true proxy-providers: sub: type: http url: \u0026#34;$SUB_URL\u0026#34; interval: 3600 path: ./proxy_providers/sub.yaml health-check: enable: true url: https://www.gstatic.com/generate_204 interval: 300 timeout: 5000 lazy: false expected-status: 204 proxy-groups: - name: AUTO type: url-test use: - sub url: https://www.gstatic.com/generate_204 interval: 300 timeout: 5000 tolerance: 50 lazy: false expected-status: 204 - name: PROXY type: select proxies: - AUTO - DIRECT use: - sub rules: - MATCH,PROXY YAML chmod 600 \u0026#34;$MIHOMO_DIR/config.yaml\u0026#34; OLD_SECRET=\u0026#34;$(grep -E \u0026#39;^[[:space:]]*secret_key:\u0026#39; \u0026#34;$SETTINGS_FILE\u0026#34; | head -n1 | sed -E \u0026#34;s/.*secret_key:[[:space:]]*[\u0026#39;\\\u0026#34;]?([^\u0026#39;\\\u0026#34;]+)[\u0026#39;\\\u0026#34;]?.*/\\1/\u0026#34; || true)\u0026#34; if [ -z \u0026#34;$OLD_SECRET\u0026#34; ] || [ \u0026#34;$OLD_SECRET\u0026#34; = \u0026#34;secret_key:\u0026#34; ]; then OLD_SECRET=\u0026#34;$(openssl rand -hex 32)\u0026#34; fi cat \u0026gt; \u0026#34;$SETTINGS_FILE\u0026#34; \u0026lt;\u0026lt;YAML use_default_settings: true general: instance_name: \u0026#34;Hermes SearXNG\u0026#34; search: safe_search: 0 autocomplete: \u0026#34;\u0026#34; formats: - html - json server: secret_key: \u0026#34;$OLD_SECRET\u0026#34; limiter: yml:ro - searxng-cache:/var/cache/searxng:rw depends_on: - valkey - mihomo networks: - searxng-net logging: driver: json-file options: max-size: \u0026#34;2m\u0026#34; max-file: \u0026#34;3\u0026#34; valkey: image: docker.io/valkey/valkey:8-alpine container_name: searxng-valkey restart: unless-stopped command: valkey-server --save 30 1 --loglevel warning volumes: - valkey-data:/data networks: - searxng-net logging: driver: json-file options: max-size: \u0026#34;2m\u0026#34; max-file: \u0026#34;3\u0026#34; mihomo: image: $LOCAL_MIHOMO_IMAGE container_name: searxng-mihomo restart: unless-stopped command: [\u0026#34;-d\u0026#34;, \u0026#34;/root/.config/mihomo\u0026#34;] ports: - \u0026#34;127.0.0.1:7897:7890\u0026#34; - \u0026#34;127.0.0.1:9097:9090\u0026#34; volumes: - ./mihomo:/root/.config/mihomo networks: - searxng-net logging: driver: json-file options: max-size: \u0026#34;2m\u0026#34; max-file: \u0026#34;3\u0026#34; networks: searxng-net: volumes: searxng-cache: valkey-data: YAML cd \u0026#34;$APP_DIR\u0026#34; if docker compose version \u0026gt;/dev/null 2\u0026gt;\u0026amp;1; then DC=\u0026#34;docker compose\u0026#34; elif command -v docker-compose \u0026gt;/dev/null 2\u0026gt;\u0026amp;1; then DC=\u0026#34;docker-compose\u0026#34; else echo \u0026#34;docker compose / docker-compose が見つかりません\u0026#34; exit 1 fi echo echo \u0026#34;サービスを開始しています...\u0026#34; $DC up -d --no-build echo echo \u0026#34;サービスの起動を待機しています...\u0026#34; sleep 12 echo echo \u0026#34;コンテナーの状態:\u0026#34; $DC ps echo echo \u0026#34;Mihomo の最新ログ:\u0026#34; $DC logs --tail=80 mihomo || true echo echo \u0026#34;Mihomo ローカルプロキシーポート 127.0.0.1:7897 をテストしています:\u0026#34; curl -I -sS --max-time 25 --proxy http://127.0.0.1:7897 https://www.gstatic.com/generate_204 || true echo echo echo \u0026#34;SearXNG JSON 検索をテストしています:\u0026#34; curl -sS --max-time 50 \u0026#34;http://127.0.0.1:8888/search?q=openai%20gpt\u0026amp;format=json\u0026#34; \\ | python3 -c \u0026#39;import sys,json; d=json.load(sys.stdin); print(\u0026#34;OK:\u0026#34;, len(d.get(\u0026#34;results\u0026#34;, [])), \u0026#34;results\u0026#34;)\u0026#39; || true echo echo \u0026#34;完了しました。\u0026#34; echo \u0026#34;Hermes は引き続き次の設定を使用します: SEARXNG_URL=http://localhost:8888\u0026#34; echo \u0026#34;SearXNG 送信プロキシー: searxng -\u0026gt; http://mihomo:7890\u0026#34; echo \u0026#34;Mihomo ローカルデバッグプロキシー: http://127.0.0.1:7897\u0026#34; echo \u0026#34;Mihomo 制御ポート: http://127.0.0.1:9097\u0026#34; echo \u0026#34;Mihomo 設定ファイル: $MIHOMO_DIR/config.yaml\u0026#34; EOF Hermes は検索エントリのみを保持する Hermes 側は Mihomo について知る必要はありません。必要なのは、ローカルマシンに SearXNG があるということだけです。\nnano ~/.hermes/.env 書き込み：\nSEARXNG_URL=http://localhost:8888 次に、~/.hermes/config.yaml で検索バックエンドを指定します：\nweb: search_backend: \u0026#34;searxng\u0026#34; Hermes 公式の SearXNG skill をインストールしている場合は、引き続き使用できます。\nhermes skills install official/research/searxng-search もし Hermes がユーザーサービスであれば：\nsystemctl --user restart hermes systemctl --user status hermes --no-pager ここにも境界があります：SearXNG は検索を担当し、ウェブページ本文の抽出は担当しません。Hermes のドキュメントでも search backend と extract backend は分けられています。後で Hermes に検索結果ページの本文を読み込ませたい場合は、web.extract_backend に Firecrawl、Tavily、Exa、Parallel などの抽出ソリューションを別途設定する必要があります。\n検証：階層をスキップしないこと まず Mihomo をテストしてください。すぐに Hermes に問い合わせないでください。\ncurl -I --proxy http://127.0.0.1:7897 https://www.gstatic.com/generate_204 HTTP ステータスを返せる場合、ホストのデバッグプロキシポートが利用可能であることを示します。次に SearXNG の JSON をテストします。\ncurl -s --max-time 50 \\ \u0026#34;http://127.0.0.1:8888/search?q=openai%20gpt\u0026amp;format=json\u0026#34; \\ | python3 -c \u0026#39;import sys,json; d=json.load(sys.stdin); print(len(d.get(\u0026#34;results\u0026#34;, [])), \u0026#34;results\u0026#34;)\u0026#39; ここで 403 が発生した場合は、まず search.formats に json が含まれているか確認してください。ここでタイムアウトが発生したり結果が空の場合は、SearXNG のログを確認してください。\ncd /opt/searxng docker compose logs -f searxng 次に、Hermes で検索をトリガーするリクエストを送信します。\nOpenAI GPT の最新情報をインターネットで検索し、ソースリンクを列挙してください。 ログに /search?...format=json が表示されている場合、Hermes がローカルの SearXNG を呼び出していることを示しています。次に Mihomo を確認します。\ncd /opt/searxng docker compose logs -f mihomo サブスクリプションの更新、provider、health check、AUTO といった情報に注目してください。 Mihomo がサブスクリプションを解析できていなければ、SearXNG をどれだけ正しく設定しても意味がありません。\n省いてはいけない境界線いくつか まず、ポートをパブリックネットワークに公開しないでください。本記事の compose はローカルホストのみにバインドしています：\nports: - \u0026#34;127.0.0.1:8888:8080\u0026#34; - \u0026#34;127.0.0.1:7897:7890\u0026#34; - \u0026#34;127.0.0.1:9097:9090\u0026#34; 「変更しないでください：」のように変更しないでください。\n0.0.0.0:8888:8080 0.0.0.0:7897:7890 0.0.0.0:9097:9090 そうでない場合、検索サービス、プロキシポート、および Mihomo のコントロールポートは、いずれもパブリックネットワークから悪用されるリスクがあります。external-controller: 0.0.0.0:9090 はコンテナ内でのリッスンであり、外部からアクセスできるかどうかを実際に決定するのは compose のポートバインディングです。\n第二に、Google や Startpage が頻繁にタイムアウトする場合、すぐにリンク構成全体を否定的に見直さないでください。まず Bing、Brave、DuckDuckGo、Wikipedia、arXiv などをそのまま残しておき、Mihomo のサブスクリプションとヘルスチェックが安定してから、验证码やタイムアウトを引き起こしやすいエンジンを有効にしてください。\n第三に、スクリプトのロールバックポイントが明確である点です。\ncd /opt/searxng cp docker-compose.yml.bak.あなたのタイムスタンプ docker-compose.yml cp searxng/settings.yml.bak.あなたのタイムスタンプ searxng/settings.yml docker compose up -d 私はサーバー全体にグローバルプロキシを適用するよりも、このように役割を分割するアプローチを好みます。グローバルプロキシの問題は影響範囲が広すぎることであり、障害が発生した際に、それがシステム環境、Docker、アプリケーション設定、それともプロキシノード自体が原因なのかを判断するのが難しくなります。Hermes、SearXNG、Mihomo はそれぞれ一つの役割だけを担うため、トラブルシューティング時にはむしろ楽になります。\n参考資料 Hermes Agent：Web Search \u0026amp; Extract Hermes Agent：Free meta-search via SearXNG SearXNG Search API SearXNG settings.yml SearXNG outgoing settings SearXNG engines settings SearXNG デフォルト settings.yml Mihomo proxy-providers configuration Mihomo url-test proxy group 写作附记 この文章では、元の素材の中で最も実用的な部分を保持しています。具体的には、階層化アーキテクチャ、SearXNG JSON、明示的な outgoing proxy、Mihomo の provider とヘルスチェック、Docker Compose、Hermes 設定、検証コマンド、よくある質問、そしてロールバックです。削減したのは繰り返しの説明や、誤解を招きやすい絶対的な表現です。たとえば all://: は汎用的に無効な設定ではなく、この環境では期待どおりにマッチしなかっただけです。\nまた、設定名を1か所修正しました：SearXNG の Bing ニュースエンジンは name: bing news と記述する必要があります。name: bing_news と書くと、デフォルトのエンジン名と一致しないため、通常のスペルミスよりもリスクが高くなります。\n元のプロンプト ユーザーは、「中国国内サーバーへの Hermes + SearXNG + Mihomo デプロイ：Hermes 検索をプロキシ経由にし、利用可能なノードを自動選択させる」と題した完全なデプロイ資料を提供し、整理・分析して記事に誤りがないことを確認した上で、ブログ執筆スキルを呼び出して記事にまとめるよう求めています。\n資料には、背景、目標アーキテクチャ、なぜシステムプロキシを使用しないのか、SearXNG settings.yml、Mihomo config.yaml、Docker Compose、改造スクリプト、Hermes 設定、検証フロー、よくある質問、ロールバック方法、最終的な効果が含まれています。\n","date":"2026-06-21","language":"ja","permalink":"https://ttf248.life/ja/p/hermes-searxng-mihomo-proxy/","tags":["AI霊感衝突坊","Hermes","SearXNG","Mihomo","Docker"],"title":"Hermes の検索が不安定：SearXNG のアウトバウンドを Mihomo に任せる","year":"2026"},{"categories":["コンピューター"],"content":"昨日 MiniMax のオフライン開発者会議に参加して、戻ってきてからずっと頭から離れない言葉がある：loop engineering。\n简单说，就是把\u0026quot;提示词—模型输出—反馈\u0026quot;做成一个闭环，让模型自己改 prompt、自己改自己。\n筆者の理解では、これは要するに「プロンプト → モデルの出力 → フィードバック」という闭环を作り、モデル自身がプロンプトを改め、自らを改善していく仕組みのことである。\n但它真正让人不安的地方在于：当 loop 足够长、反馈足够稠密，模型就开始越过\u0026quot;工具\u0026quot;那条线，开始自己决定要解决的问题、自己判断完成的标准。\nしかし本当に不安を感じさせる点は、loop が十分に長く、フィードバックが十分に密になると、モデルが「ツール」という一線を越えてしまい、自らが解決すべき問題を決め、自らが完成の基準を判断し始めることだ。\n记得大会上有个工程师打了个比方说：\u0026ldquo;以前我们养的是宠物，loop engineering 养的是同事。\u0026rdquo;\n最初はエージェントを何ラウンドか回すだけだと思っていた。この理解はあまりにも浅はかだった。本当に行き詰まったのは、AI がコードを書く速度がもはや人間がコードをレビューする速度を大幅に超えてしまっているということで、もし人間の関与が「すべてのステップを確認し、すべてのステップで判断する」レベルにとどまっているなら、最終的に生産性は人間の確認速度によって制限されてしまう。\nこれは、私が最近 Codex を使って感じたこととつながる。以前その目標に関する記事を書いた時、私がより注目していたのは「完了条件」という事柄だった。何が目標で、どこに境界線があり、何で検証し、いつ完了とみなすのか。\n以下は補足です。最初の文「この文章は CC BY-NC-SA 4.0 のライセンスで公開されています。」のような前置きや、結論段落の「この方向が正しいと確信している理由は、まだこれからです。」も訳した方がよろしいですか？必要であれば、追加で翻訳いたします。\n大会が終わって改めて振り返ると、goal は loop engineering の中の小さくはあるが非常に重要な一部分に過ぎない。gole は、単一のタスクが人間から繰り返し指示されなくても前に進めるようにするためのものだ。さらに大きな問題は、どのタスクをループに任せるべきか、どのチェックポイントを人間に残すべきか、どの判断を事前にシステムに書き込んでおくべきか、どの責任を AI に押し付けるべきではないのか、ということだ。\n今の私が最も契合するシナリオは二つあると感じています。\nひとつはパフォーマンス最適化です。これはもともと指標があり、できれば自動再テストも備えています。エージェントに「インターフェースの P95 をいくつまで下げる」「ファーストビューを何ミリ秒に抑える」「バンドルサイズを何 KB まで削減する」「回帰テストは失敗させてはいけない」と伝えます。エージェントは変更するたびにベンチマーク・プロファイリング・負荷テストを毎回実行し、目標に達しなければボトルネックの探索を続けます。ここで人の価値は毎回どの行を修正したかを確認することではなく、まず受入可能な指標を提示し、そのうえで重要な節目で「この最適化が業務セマンティクスを変えていないか」を判断することにあります。\nもう一つは UI のリファクタリングです。その前提として、明確なデザイン案が必要となります。理想的には 1:1 で忠実に再現できることが望ましいです。デザイン案がない場合、人は「このマージンがおかしい」「この色が違和感ある」「このインタラクションは違う」といった瑣末な判断に常に引き戻されてしまいます。デザイン案があれば、AI のループはスクリーンショット、DOM、スタイル、視覚的な差分を中心に収束させることができます。人はすべての CSS 調整につき従う必要はありませんが、最終的な UI には責任を持つべきです。\nこれら 2 つのシナリオに共通しているのは、検収物が「もっとうまくやってほしい」のような一言ではないということです。パフォーマンス最適化には数値があり、UI リファクタリングにはデザインがあります。ループが機能するのは、AI がより従順だからではなく、タスク自体に比較可能な目標があるからです。\nMultica は共同作業ボードのようなものです 会場では、オープンソース界隈の人々からプロジェクトの紹介を受けることもあり、その中で Multica はなかなか興味深いものでした。帰って調べてみたところ、これは新しい单体（单体）的コーディングエージェントではなく、Claude Code、Codex、GitHub Copilot CLI、OpenCode、Gemini、Kimi、Cursor Agent などのツールを同じタスク協調レイヤーに接続するものだと分かりました。\nその README では、agent を teammate として記述しています。issue を割り当てられたり、blocker を報告したり、ステータスを更新したり、カンバンやコメント、タスクのライフサイクルに登場したりします。ドキュメントではさらに具体的に、agent は workspace の一級メンバーであり、issue を assign でき、コメントで発言でき、@ でメンションされ、agent を作成するときには背後にある AI coding tool を選択でき、instructions、model、環境変数、CLI 引数、可視性、並行制限を設定できると説明されています。\nこれにより、「どのモデルを使うか」がプロンプトの中での一時的な選択から、チームコラボレーションにおける役割の設定へと変わります。\nこの仕組みの最も興味深い点は、「マルチエージェント」という言葉そのものではなく、異なるエージェントに異なる役割を割り当てられることだ。例えば、あるエージェントには安価なモデルを使って反復的な修正を担当させ、別のもっと強力なモデルを使うエージェントにはアーキテクチャの判断を担当させ、さらに別のエージェントにはレビューだけを行わせてコードは変更させない。こうしてSquadのような仕組みを組み合わせ、リーダーエージェントがissueの内容に応じてタスクを適切なメンバーにルーティングするのである。\n私は Multica を最初から最後まで完全に動かしたわけではないので、ここでは公開されている資料で照合できるサンプルとして扱うしかない。ただ、この設計の方向性は loop engineering と同じ種類の問題であり、1 つの AI にすべてを任せるのではなく、タスク・役割・モデル・レビュー・状態遷移を同じループの中に組み込むというものである。\n企業が実際にAIによるコーディング導入を検討する場合、この違いは非常に重要である。\n現在はモデルごとに価格も能力の境界も異なっています。すべてのタスクに最も高額なクローズドソースモデルを使うと、コストを必ずしもちません。すべてのタスクに安いモデルを使うと、手戻り作業やレビュー漏れによってコストが後段に移転する可能性があります。より現実的な方法は階層化することです。リスクが低く、反復的で、境界がはっきりしている作業はまず安いモデルに任せます。重要な変更、アーキテクチャの取捨選択、最終レビューは、より高性能なモデルや人に残します。\nクローズドソースの高性能モデルがレビュー担当として使われるのは、私は良い位置取りだと思います。レビューは単に「文法ミスを見つける」だけではなく、要件が歪められていないか、境界を越えていないか、テストが表面しかカバーしていないか、コミットメッセージがリスクを隠していないかを確認する必要があります。このようなタスクにはより高い判断力が求められますが、実装段階ほど呼び出し頻度は高くないかもしれず、コストの計算もより受け入れやすくなります。\n人手の関与が少ないことは、人が責任を負わないということではない 円卓会議であった意見に私も共感する点がある：コードはAIが書くが、コードを提出するのは人間である。\nこの言葉は責任を問うリマインダーのように聞こえるが、実はプロセス設計の原則でもある。AI はコードを書いたり、修正したり、テストを実行したり、PR の説明を生成したり、さらには別のモデルに先にレビューさせることもできる。しかし、最終的にコードをメインブランチにマージする人は、「これは AI が書いたもので、自分には関係ない」とは言えない。\n会社で求められるのは、誰がキーボードで文字を打ったかではなく、誰が結果に責任を持つかだ。あなたが提出したということは、今回の変更のビジネスセマンティクス、リスク境界、テストのエビデンス、ロールバック計画に対して責任を持つ意思があるということだ。AI の関与が深いほど、この点を曖昧にしてはならない。\nつまり、loop engineering は人をプロセスから完全に排除するものではありません。むしろ、人の配置を再構築するようなものです。\nタスク開始前に、人間が目標、境界、受け入れ基準を明確にする。 ループ実行中、システムとエージェントが反復的な試行、テスト、修正、状態同期を自ら処理する。 重要な節目では、人間が証拠、差異、リスクを確認し、AI の出力を逐行で追わない。 コードを提出する際、結果に対する責任は人間が負い、AI を免責の理由にしない。 だからこそ私は、goal、性能指標、デザイン稿、Multica という、一見ばらばらのものを結びつけているのです。これらはすべて、人の判断を前倒しにし、外在化し、構造化しています。人の関与は少なくなりますが、関わるポイントはより重要になります。\nこの件をうまくやらないと、別の形の非効率になってしまう。AI が多くを生み出すが、人間がレビューしきれず、最終的にチームは「何となく大丈夫そう」という感覚でコードをマージする。問題が起きた後、その責任を AI に押し付ける。それはエンジニアリング化されたとは言えず、単に混乱の生産者を変えただけにすぎない。\n本当に追いかける価値のあるループとは、AI にずっと書き続けさせることではなく、書く・直す・テストする・レビューするという各ラウンドを、同じ受入チェックリストに立ち返らせることなのだ。人の仕事は「書いているのを見張る」ことから、「何が良しとされるかを定義し、エビデンスが十分かを確認し、提出物に責任を持つ」ことへと変わる。loop engineering という言葉がずっと私の心に留まっているのは、たぶんこの点なのだ。\n参考資料 Multica GitHub README Multica Docs: Agents Multica Docs: Create and configure an agent Multica Docs: AI coding tools matrix Multica Docs: Squads 写作附记 元のプロンプト $blog-writer 昨日、Minimaxのオフライン開発者会議に参加したのですが、ずっと頭から離れなかったものがあり、それは「loop engineering」です。最近は codex を使ってコード開発をしていますが、goal も使うのが好きで、goal に関する記事を書いたこともあります。2 つのユースケースを発見しましたが、最も契合するのは次の 2 つです。1 つはパフォーマンス最適化で、要求したパフォーマンス指標を直接出力してくれること。もう 1 つは UI リファクタリングで、デザイン案を提供すれば 1:1 で復元してくれることです。冒頭に述べた loop engineering に戻ると、AI 時代のプログラミングでは、AI の生産性は人間を遥かに超えているため、人間のレビュー速度では AI の出力速度にまったく追いつけません。しかし、現在の vibe coding では、多くの意思決定に依然として人間の関与が必要です。人間の関与が増えると、全体的なフローを完全に自動化することが難しくなります。loop engineering の理念は、まさに人間の関与の度合いを下げることにあります。また、オープンソースコミュニティの人々が自らのプロジェクトを宣伝するのにも遭遇しましたが、その中で特に興味深いプロジェクトが一つありました。それは Multica です。関連情報を調べて、簡単に紹介してみてください。彼の設計理念を除いて、最も興味深い点は、与えられたモデルごとに異なるアイデンティティを付与することで、各社の大規模モデルを効果的に活用できることです。結局のところ、現在モデルの価格はさまざまで、ソース非公開のモデルにレビューを行わせるというのは良いアプローチです。会社における AI コードの導入について、ラウンドテーブルのディスカッションで一致していた見解もあります。コードは AI が書きますが、コードを提出するのは人間であり、提出するコードに対して責任を負う必要があります。これはあなたの責任感や、物事に取り組む姿勢を示すものです。AI が書いたものだから、自分とは関係がないとは言えません。\n執筆思路の要約 2026-06-13 に MiniMax のオフライン開発者会議に参加するという現場のきっかけを保持し、それをカンファレンスのレポートに膨らませることはしない。 主軸を「人の参与位置がどう変わるか」に収斂させ、loop engineering、goal、Multica、そして会社の責任を逐一説明することはしない。 Multica のパートは公開資料で裏付けられる能力のみを記述し、「クローズドソースのモデルを審査に用いる」という点は著者の判断として明示する。 具体的なモデルの価格、会社の管理制度、コードレビューのフローに関する展開は抑え、記事がワークフローの観察から管理制度の提言に脱線するのを避ける。 ","date":"2026-06-14","language":"ja","permalink":"https://ttf248.life/ja/p/loop-engineering-human-checkpoints/","tags":["AI霊感衝突坊","ai","Codex","MiniMax","Multica","agent"],"title":"Loop engineering 的人物を checkpoint に移動する","year":"2026"},{"categories":["コンピューター"],"content":"最初は単にフロントエンドの整備が後回しになっているだけだと思っていました。strategy_studio のビジネスロジックは着実に前へ進んでおり、行情同期、PostgreSQL、非同期バックテスト、レポートの DB 格納、リサーチワークベンチへと次々と接続されていきましたが、ページは「機能を先に乗せ、 UI は後で清算する」ような状態に見えてきました。Codex に UI を破壊的に再構築させようとしたとき、初めて問題がはっきりと表面化しました。プロンプトをどれだけ強く書いても、界面は古い枠の中でコンポーネントを挪動させているだけのように見えました。\nCodex を使ってコードを改善するのは、今回が初めてではありません。バックエンドのロジック、API 連携、テスト修正、レポート生成といったタスクは、ふだんからそのままゴールだけ放り込んで、ファイルを読ませ、コードを修正させ、検証を走らせ、コミットさせています。問題になったのはフロントエンドのリファクタリングです。今回は UI のデザイン案を先に作らず、しかも事前に業務の土台を先に組み上げてしまいました。一度でも旧 UI が存在すると、モデルに見えるのは要件だけではありません。既存のコンポーネント、既存のルーティング、既存のスタイル、そしていくつかの歴史的な慣性までもが見える状態になります。\n私の最初の反応もとても普通でした：プロンプトを追加し続ける。破壊的な再構成を許可し、UIとインタラクションのロジックを再設計し、要素を詰め込みすぎず、24インチと32インチのモニターに対応し、コア機能に焦点を絞り、保守的にならない。一つ一つの文は単体で見ればどれも正しいのですが、全部合わせてもまだ何かが足りません：最終的に一体どうあるべきか、ということです。\nつまずくのはボタンの色ではない strategy_studio はボタンが 2、3 個しかない小さなツールではありません。README では、すでに中国語を優先した戦略研究プラットフォームとして位置付けられています。Next.js のフロントエンド、FastAPI の API、PostgreSQL、Worker、Scheduler、Yahoo 同期パイプラインが一緒に動作します。さらにフロントエンドの README は、ページを 1 つのリサーチワークベンチへと集約しています。サンプル準備、実験構成、タスク追跡、結果レビュー、テンプレート管理、そしてレポート詳細と運用・保守のエントリポイントです。\nこのプロジェクトにおけるフロントエンドの問題は、表面上は「十分に美しくない」というものですが、実際には情報の秩序が定まっていないことにあります。ユーザーはまず相場を見るのか、それともまずバックテストのタスクを見るのか。レポートの詳細画面では、曲線、指標、入力パラメータ、再実行ボタンのうちどれがより重要なのか。トップページはナビゲーションのページなのか、それともワークスペースなのか。大画面では要素を隙間なく敷き詰めるのか、それとも余白を持たせるのか。\nこれらの判断は文章だけで説明されているため、Codex は「既存ページの中で少し最適化する」という解釈を容易にしてしまいます。コンポーネントの変更、余白の調整、色の変更などを行いますが、それでも古い構造に沿って作業を進めます。破壊的なリファクタリングを許可するだけでは不十分です。なぜなら、破壊的なリファクタリングが解決するのは「コードを大幅に変更できるかどうか」という問題であり、「検証可能なビジュアル目標が存在するかどうか」という問題ではないからです。\n日中に一度出かけたのですが、夜になって急に思いつきました。Codex に UI を推測させるのはやめよう。まずは ChatGPT の Web 上で UI デザイン案を描き出して、その画像を Codex に渡して再現させよう。\n当時使っていたプロンプトはとても直接的でした：\nhttps://github.com/ttf248/strategy_studio 現在のプロジェクトのフロントエンドコードを分析し、業務ロジックを理解した上で、プロのUIデザイナー・インタラクションデザイナーとして、フロントエンドページを設計し直してください。各ページごとに個別に画像を作成し、24インチ・32インチのディスプレイに対応させ、要素を必要以上に詰め込みすぎず、ユーザーが中核機能に集中して使いやすいようにしてください。 このステップで出た効果は、Codex で形容詞を積み重ね続けるよりもずっと安定している。Codex にはまず可視的な目標が与えられる。ページをどう並べるか、モジュール比率をどう分けるか、ビジュアルセンターの配置、余白のおおよその目安といったものだ。その後の Codex が取り組むタスクは、「審美眼を頼りに再設計する」ことから「図に基づいて業務を理解しコードを復元する」へと変わる。\n配色も先に素材にしよう 初稿の図でレイアウトの問題は解決しましたが、デフォルトの配色が依然として通常のバックエンドシステムらしい青と白であり、私の美的感覚にはあまり合っていません。ここで「青と白が好きじゃない、もっと落ち着いた配色にして」とそのまま Codex に投げてしまうと、本質的にはまた推測させることになります。\nこれが最初の青と白のカラーリングバージョンです。ページ構造を示すことはできていますが、まだ普通の管理画面の雰囲気です。\nその後、私はやり方を変えました。まず ChatGPT のウェブ版で配色の方向性について話し合い、ベースカラー、アクセントカラー、カードの階層、そして研究ツールらしい雰囲気について明確に伝えました。その上で、画像モデルにその方向性に従って意図を示してもらいました。これは正式な Figma ではなく、完全なデザインシステムでもありませんが、フロントエンドの再構築で最もずれやすい要素を固定するには十分です。\n最終的に手にしたのは「大きく網羅した1枚のホームページ」ではなく、ページごとに分かれたデザイン原稿です。ホームページ、行情研究、バックテスト実験、レポートセンター、レポート詳細、ストラテジーテンプレート、運行保守。 この分割方法が非常に重要 です。strategy_studio のフロントエンドはマーケティングページではなく研究ツールです。ホームページ、行情ページ、レポート詳細ページが担う閲覧タスクはそれぞれ異なるため、すべてを同じカードグリッドに詰め込むことはできません。\n図が描けたことで、Codexの役割が明確になります。CodexはゼロからUIデザイナーを務めるのではなく、既存のビジネスロジックを読み、コンポーネントを分解し、レイアウトを調整し、インタラクション状態を揃え、lint/buildを実行し、そして旧フロントエンドを設計稿に近い目標状態にリファクタリングします。\n単なる「ウェブ版の方が賢い」ではない その後、公式資料をもう少し調べてみたが、この件を「異なるチャネルの ChatGPT の知能レベルが異なる」や「Codex を直接使用すると機能が制限される」と解釈できるかどうかを確認したかった。この説明はあまりにも粗い。\nOpenAI による Codex CLI の説明は、ローカルのターミナルで動作する coding agent に関するものです。現在のディレクトリにあるコードを読んだり、変更したり、コマンドを実行したりできます。Codex web は、クラウド環境でコードタスクを処理します。OpenAI が Codex agent loop について語るとき、重視しているのは「モデルがすべてを凭空に生み出す」ことではなく、モデルの推論、文脈管理、ツール呼び出し、ファイルの読み書き、コマンド実行が一体となってソフトウェアタスクを構成するという点です。\nChatGPT Images は別のエントリーポイントです。OpenAI Help における Images in ChatGPT の説明によると、ユーザーは会話内で画像を作成および編集したり、モックアップやクリエイティブなビジュアルを作成したりできます。この製品の形態は、納品物がコードではなく画像であるため、ビジュアル目標をまず探索するのに本質的により適しています。\nしたがって、今回の違いは「どちらがより賢いか」ではなく、タスクの形態が異なるという点にあります。「UIの再設計」を直接 Codex に任せると、コードリポジトリの視点で考えます。どのファイルを修正すべきか、どのコンポーネントを壊してはいけないか、どうすればビルドを通すことができるかを考えます。同じビジネスコンテキストをまず ChatGPT Images に渡すと、抽象的な美的感覚と情報の階層をまず見える目標画像に圧縮します。\nこれはまた、後になって Codex がむしろ使いやすくなる理由を説明している。設計ドキュメントが Codex を回避したのではなく、設計ドキュメントが Codex にコンテキストと受け入れ基準を補完したのである。公式の Codex prompting ドキュメントも、Codex に関連ファイル、画像、明確な完了基準を提供することを強調している。図がない場合、「要素を密集させすぎないでください」は単なる形容詞に過ぎないが、図があって初めて、それは再現可能なレイアウト制約となる。\nよりスムーズなリンク これ以降は、この種フロントエンドのリファクタリングを3つのパートに分割することにします。\n第一段階は、まずビジュアル探索から始めます。ChatGPT の Web 版にリポジトリを読ませ、業務を理解させ、ページごとに画像を生成させ、色使い、密度、大画面対応、ビジュアル階層といった点を中心に繰り返し調整します。この段階で生み出される成果物はコードではなく、目標となる画像です。\n第二段階では、目標画像とエンジニアリング上の制約を Codex に渡します。プロンプトは「UI を再設計してください」で止めてはいけません。代わりに、どの画像を目標とするか、どのビジネスロジックを壊してはならないか、どのページが破壊的な再構築を許可されているか、どのテストとビルドが通らなければならないかを明確に記述する必要があります。\n第三段落ではエンジニアリングによる復元に入ります。ここで初めて Codex にゴールモードや連続タスクモードを使わせるのに適しています。まずフロントエンドの構造を読み取り、次にページごとに分割して実装します。各ページが完了したら検証を実行し、最後にインタラクションとレスポンシブ対応を一括して確認します。\n以前は「プロンプトをもっと強く書くこと」を解決策だと考えがちでした。今振り返ると、フロントエンドのリファクタリングにおいて本当に有効なのは強引さではなく、不足している中間成果物を補うことだと分かります。UI デザインがない場合、破壊的なリファクタリングは単に分解を広げるだけに過ぎません。UI デザインがあって初めて、破壊的なリファクタリングには正しい方向性が生まれます。\nこのフローは strategy_studio にしか使えないわけではない。すでにビジネスロジックはあるものの、フロントエンドをずっと後付けで継ぎ足してきたような個人プロジェクトなら、どれでも同じ要領で進められる。まず画像モデルに UI のゴールを描かせ、次に Codex にそのゴールをコードに変換させる。各モデルが互いに代替し合うのではなく、それぞれ得意な工程を担当するという形だ。\n参考資料 ttf248/strategy_studio GitHub リポジトリ Strategy Studio README Strategy Studio Frontend README Strategy Studio UI デザイン原稿ディレクトリ OpenAI Help：Images in ChatGPT OpenAI Help：ChatGPT Capabilities Overview OpenAI Developers：Codex CLI OpenAI Developers：Codex web OpenAI Developers：Codex prompting OpenAI：Unrolling the Codex agent loop 写作附记 元のプロンプト $blog-writer 日常的に codex を使って ChatGPT モデルを调用しコードを書いているが、オープンソースプロジェクト https://github.com/ttf248/strategy_studio を開発する際、当初は UI モックアップを作成せず、直接ビジネスロジックの開発を行っていた。そのためフロントエンドの UI が計画されておらず、codex 内で直接プロンプトを書いてみた。「破壊的なリファクタリングを許可し、UI とインタラクションロジックを再設計してください」と指示したが、調整してもなかなか良い結果が得られなかった。この時点ではまだ codex の問題を疑っていなかった。昼間外出した夜、ふと閃いた。「Web 版で image2 を呼び出して UI デザイン案をいくつか生成し、それを codex に渡して goal モデルで復元開発してもらえばいいのでは？」と。早速試してみたところ、全く問題なく進められた。使用したプロンプトはこちら: https://github.com/ttf248/strategy_studio プロジェクトのフロントエンドコードを解析し、ビジネスロジックを理解したうえで、プロの UI デザイナー、インタラクションデザイナーとして、フロントエンドページを一式再設計してください。各ページごとに個別に画像を出力し、24 インチと 32 インチのディスプレイに対応させ、要素が密集しすぎないようにして、ユーザーがコア機能に集中しやすくしてください。これでかなり良い結果が得られたが、デフォルトの配色（よくある青と白の組み合わせ）が自分の好みには合わなかった。そこでさらに調整した。まず Web 上で適切な配色をいくつか相談し、image にその配色でデモ画像を生成させる。次にその配色方案と先ほどのプロンプトを組み合わせることで、以下を得ることができた: https://github.com/ttf248/strategy_studio/tree/main/ui。書いた内容が多いので、整理して一篇の記事にまとめてほしい。分からない点があれば、自分でネット検索して調べてください。提供した https://github.com/ttf248/strategy_studio/tree/main/ui には画像がたくさんあるので、適当に 2 枚ほど選んでブログに貼り付けてください。\n執筆思路の概要 この書き直しでは、原文の判断と材料をそのまま保ちながら、冒頭部分を「まずは完全な答えを示す」から「フロントエンドのリファクタリングで行き詰まった現場に入る」に変更している。記事は汎用的なモデル評価を省き、今回のワークフローで実際に効果があった転換、つまり視覚的な目標をあまずグラフ化し、それから Codex にエンジニアリングの復元を行わせる、という点だけを記述している。\n","date":"2026-06-14","language":"ja","permalink":"https://ttf248.life/ja/p/codex-chatgpt-ui-mockup-workflow/","tags":["AI霊感衝突坊","Codex","ChatGPT","UIデザイン","ai"],"title":"Codex がインターフェースを書くのに失敗したあと、ChatGPT に UI を描かせる","year":"2026"},{"categories":["投資 (tōshi)"],"content":"シャオミの今回の株価下落は、「AIへの出費」という単なる物語にのみ起因させることはできません。過去1年間の間に、株価は202\n先に一つの見解を述べさせてください：Xiaomiの利益回復は、AIブームが完全に収束するのを待つ必要はありませんが、ストレージおよびスマートフォン部品コストの上昇勾配（上行斜率）が鈍化するか、あるいはXiaomiがより高いASP、低端在庫の減少、そして自動車部門での規模による利益によってコストを吸収できるまで待つ必要があります。AIは唯一の問題ではありません。むしろ、今回のストレージ価格高騰と設備投資（CapEx）の増幅器のようなものだと考えられます。\n株価の下落による収益性への疑念 時点 レトロフィット終値 解釈 2025-06-12 52.20 港元 1年前の起点 2025-07-02 60.15 港元 区間高値 2025-09-30 54.00 港元 まだ高い水準を維持 2025-12-31 39.36 港元 年末には既に大幅なバリュエーション低下 2026-03-31 31.76 港元 第1四半期の業績圧力が織り込まれ始める 2026-06-11 25.84 港元 区間安値 ここには資金面（資本流入）のノイズがあります。人民元は過去1年間、確かに増価しました。Yahoo FinanceのUSDCNY=Xは7.1928から6.7725に下落し、ドル対人民元で5.84%の下落を見せました。香港ドル対人民元も0.9164から0.8643に下落しました。人民元建てで香港株を見ると、同じ香港ドルの資産はより割高に見えます。南下資金は短期間で為替やポジションのサイクル（リズム）を持つでしょう。\nしかし、これを「人民元が上昇した（円安になった）から南向きの資金が減り、だからシャオミが下がった」と記述するのは、あまりにも都合が良い／単純すぎる。HKEXのStock Connect 2025 Reviewによると、2025年の南向きの日平均売買額は1,211億香港ドルで、2024年は482億香港ドルの水準でした。さらに、2025年第4四半期末の南向き売買額が香港現物株取引に占める割合は23.0%であり、これは2024年第4四半期末の20.9%\n株価の下落の原因は、「シャオミが車を作れない」とか「シャオミにAIがない」といった点ではなく、市場がかつてからの古い問いを再び投げかけていることにある。すなわち、「シャオミはハードウェア競争の中で利益を守り切れるのか？」という点だ。\n挙げられるいくつかのネガティブ要因（利空）は、すべて同じ種類の圧力ではない プロンプトで挙げられているネガティブ要素（下落要因）は三つの層に分けることができ、これらを混同すべきではありません。\n最初の側面は、バリュエーションと資金の割引率です。米ドルの流動性、海外資金のリスク選好度、そして香港株全体の取引リズムといった要因は、シャオミのような高ベータの香港株すべてに影響を与えます。FRB（連邦準備制度理事会\n第二層は自動車補助金と電気自動車の競争です。2024年から2025年は、新エネルギー乗用車にかかる購入税が免除され、車両あたりの非課税限度額は3万元です。2026年から2027年には半減して徴収され、車両あたりの減税限度額は1.5万元に変わります。20万から30万元の価格帯の車にとって、これは小さな数字ではありません。これにより、2つの結果が生じます。すなわち、2025年末までに需要の一部が早期に放出されること、そして2026年には自動車メーカーが一部の価格圧力に耐えるか、あるいは注文ペースが鈍化することを受け入れるかのどちらかになります。小米（Xiaomi）汽車は、2025年において既に増産能力を証明しましたが、2026年の第1四半期に80,856台という納車台数は、2025年第4四半期の145,115台から44.3%減であり、「年間目標55万台」だけを見る市場ではなくなり、モデルチェンジと車両あたりの利益が注視されるようになります。\n「第3層こそがスマートフォン原価です。この圧力が最も厳しく、なぜならこれはすでに売上総利益率に反映されているからです。2025年第4四半期、シャオミのスマートフォン売上総利益率は8.3%まで低下し、2026年第1四半期もわずか10.1%にとどまっています。同期のスマホ出貨台数は3,380万台で前年同期比約19％の下落となりましたが、ASPは逆に1,310元近くに上昇しています。これは\nこの場でのAIの役割は少々入り組んでいます。小米自身も、AI、自動運転、そして具身知能に投資する予定ですが、「財新」の要約によると、2026年のAIおよび具身知能への投資\nストレージ価格の上昇は、スマートフォンにどう影響するか 過去2年間のストレージ価格は、滑らかに上昇したのではなく、まず回復し、その後制御不能になりました。\nHDDは、ユーザーが機械式ハードドライブについて尋ねられたため、表の中で個別に残しています。しかし、これはシャオミのスマートフォンに直接的なBOMへの影響はありません。HDDが影響を与えるのは、シャオミのノートPC、NAS/エコシステム全体、クラウドAIストレージ、そして消費電製品全体の価格環境です。実際にシャオミのスマートフォンに組み込まれているのは、LPDDR4X/LPDDR5XとeMMC/UFSです。\n小米公式サイトのグローバル製品ページで現在も展示されているいくつかの機種を例にとると、コストの圧力は概ね以下のようになります。\nここには、Xiaomiがすべてのコスト上昇分を単純に消費者へ価格として転嫁できない理由も説明できます。Redmi 14Cのような大ヒット商品は、50元の上昇だけで予算に敏感なユーザー層に影響を与える可能性があります。Redmi Noteシリーズが100元上がると、競合製品のプロモーションと直接的にぶつかります。フラッグシップ機が300元上がれば、ユーザーはAppleやSamsung、vivo、OPPOなどのカメラ特化型フラッグシップと比較するでしょう。Xiaomiができるのは、ハイエンド比率を高めること、低利益在庫の圧力を減らすこと、そして新製品のペースを速めることですが、これらすべてが一定の出荷量あるいは市場シェアの犠牲となる可能性があります。\nスローガンではなく、内容を見るべき したがって、シャオミの利益回復は、AIが完全に終わるのを待つ必要はありません。より現実的な引き金（トリガーポイント）が3つあります。\n第一に、メモリ価格の上昇の傾きが鈍化することです。\nDRAMとNANDが依然として第1四半期（Q1）や第2四半期（Q2）のような四半期単位の急激な高騰サイクルにある限り、スマートフォンの売上総利益率を安定的に維持することは難しいでしょう。価格が2024年の底値に戻らなくても、上昇率が「四半期で2倍近辺」から通常のサイクルによる価格上昇に落ち着けば、Xiaomiは在庫管理、製品構成（ポートフォリオ）、および価格設定を通じて徐々に回復させることが可能です。\n2点目は、スマートフォンASP（平均販売単価）の上昇が売上に悪影響を与えていないかという点です。2026年第1四半期は、「ASPは高値を記録した」にも関わらず、「出貨量は前年比で約19%減少」という矛盾を抱えています。今後、単に価格を上げて粗利益（毛利）を維持するだけでは、株価が必ずしも追従しない可能性があります。米がハイエンド機とミドルレンジの主力機を用いてASPを安定させるとともに、出荷量の落ち込み幅を縮小できれば、初めて市場は携帯事業に対して再評価を行うでしょう。\n最初の論点は、自動車事業が再び規模による利益性を証明できるかという点です。2025年の通期では、EV、AI、その他の新事業\n株価の動きから見ると、25香港ドル付近はすでに過去1年間の安値であり、テクニカルな形も依然として弱い状態です。私の基本的な判断としては、新たな利益回復の証拠がない場合、短期的には25～32香港ドルのレンジ内での弱気な回復に留まる傾向があります。もし25香港ドルを割れる場合、市場は次のサポートラインとして22～24香港ドルを探ることになります。その後、決算報告で携帯電話の売上総利益率が下落停止し、自動車の納車台数が再び一段階上がったことが確認されれば、まず32香港ドルを見てから、35～40香港ドルの領域に挑戦できる機会があるでしょう。このレンジは売買のアドバイスではありません。単に、現在の利益圧力と過去1年間の価格分布を重ね合わせた観察の枠組みです。\nむしろ、「AIブームの終息を待つ」という判断基準に留まりたくありません。もしAI熱狂が完全に消退すれば、ストレージ価格は緩和するかもしれませんが、小米（Xiaomi）の自動車やスマホAI、自動運転、ハイエンド機といった物語性も一緒に一定の評価弾力性を失うでしょう。小米にとってより良い状態とは、AIバブルが破裂することではなく、AIインフラが「買い漁り」段階から安定的な調達フェーズに入り、ストレージ価格が四半期ごとにハードウェアの会計帳簿を書き換えられる状況にならなくなることです。\n参考資料 人工知能\nオリジナルプロンプト $blog-writer 小米の株価、複数のネガティブ要因：人民元の切り上がりにより、南向の大口資金が香港への投資を減らしていること。ドルの流動性引き締めにより、外資の資金も減少していること。電気自動車の補助金制度の変更、国の補助金の縮小傾向、そしてAIによる継続的な出費。ストレージチップの値上がりとAIの活況により、半導体価格が継続的に高騰している。小米の利益回復は、このAIブームが完全に終焉するのを待たないといけないのだろうか？私が前に述べた内容を整理し、過去1年間の小米の株価を集めて分析を行い、今後の推移を予測したい。半導体の値上がりに関して、ここ2年間における毎年分のSSD（ソリッドステートドライブ）、HDD（ハードディスクドライブ）、メモリの値上がり幅をまとめ、小米の人気モデルを調査して、機械のハードウェアコストがどれだけ増加したかを評価 ### 執筆の骨子（または：作文の概要） 本記事では、ユーザーから提案された資金、補助金、AI、ストレージ、株価といった複数の論点を維持しましたが、「すべての弱気要因が均等に展開する」という記述は削除しました。人民元高や南下資金は「資金の勢い」（ファンドのサイクル）要因として格下げされました。これは、HKEX（香港証券取引所）のデータでは、南下資金全体を明確な縮小として示すことができないためです。ストレージ価格の上昇と携帯電話の売上総利益率はより確度の高い主要テーマであるため、本文ではコストの内訳分析により多くのスペースを割きました。 コストの推定は範囲のみとなります。シャオミ様の実際の仕入れ価格として記載することはできません。真の購入価格を確定するには、契約書、在庫状況、サプライヤー情報、および納品ウィンドウといった詳細が必要であり、公開資料からは確認が不可能です。 ","date":"2026-06-12","language":"ja","permalink":"https://ttf248.life/ja/p/xiaomi-stock-memory-cost-2026/","tags":["AI霊感衝突坊","小米 (Xiǎomǐ)","恒生指数 (こうせいしじょ)","半導体","ai"],"title":"Xiaomi、収益源をハードウェア本体に回帰：メモリ価格高騰、車用補助金、そしてAI投資費用が同時に影響。","year":"2026"},{"categories":["金融知識データベース","投資 (tōshi)"],"content":"まず期間の定義（時間軸）を明確にしましょう。A株が6月5日の日中に下落したのは、主に自社の高位テクノロジー株、資金調達の制約、およびセクターの過密化（クラウディング）の問題が表面化したためです。一方、米国株が6月5日の夜間に下落\nA株市場では、6月5日に滬指が0.74%下落し、深成指数が2.21%下落、創業板指が3.2%下落しました。証券時報は、この際、「大暴落」という言葉で覆い隠されがちな詳細を報じています。A株市場では約3,300銘柄が上昇し、北証50も5.59%上昇したというのです。つまり、先週金曜日はすべての銘柄が一斉に崩壊したわけではなく、ウェイト銘柄と高位のテクノロジーセクターが指数を下方に引っ張ったということです。新浪財経の終値レポートによると、科創50は4.01%下落し、半導体やストレージチップは調整局面に入り、光通信やコンピューティングパワー関連ハードウェアなどの分野が重圧にさらされています。\n6月8日現在、売りの圧力は「一日下げ」で止まっていません。日経経済新聞の終値データによると、当日、上証指が1.7%下落し、深セン指が3.22%下落し、チャイネク指が3.69%下落し、スター50が4.30%下落するなど、約4,600銘柄が下落を記録しました。同日、証券\n米国株式市場では、6月5日の下落がより顕著でした。APの終値データによると、S\u0026amp;P 500は2.6%下落し、ダウ平均株価は約1.3%下落、ナスダックは4.2%の下落となりました。BLSが同日発表した5月の雇用統計からは、米国の非農業部門雇用者数が17.2万人増加し、失業率は4.3%で推移していることが示されました。このデータは市場の予想を上回ったものの、「経済が良いから株が良い」という構図ではなく、金利の上昇と利下げ期待の後退により、高評価なハイテク株の将来キャッシュフローが再評価（ディスカウント）された形となりました。Axiosはこの日を半導体株がナスダックを下押しした動き\nしかし、東部時間（EST）2026年6月8日正午時点では、相場は単調に崩壊し続けてはいませんでした。トレーディングツールが示すUTC 16:21頃の市場中の基準では、QQQは約2.36%上昇、SPYは約0.86%上昇、DIAは約0.24%上昇、SOXXは約7.27%上昇しました。個別銘柄では、Nvidiaは約2.26%上昇、Broadcomは約3.14%上昇、AMDは約5.27%上昇、Marvellは約13.95%上昇、Micronは約11.11%\n「ここでは、『国内が下落して、米国株も下落し、米国株が反発すれば、AIは大丈夫だ』という文章が最も誤解されやすい点です。私はそうは思いません。」\n金曜日に両市場が共有したのは、「バリュエーション（評価）と取引構造的な圧力」でした。月曜日のA株で確認できたのは、「過度に集中した売買がまだ解消に向かっていること」です。そして、月曜日午前の米国株での反発は、「高い弾力性を持つ資産には、買い戻しを望む交易資金がいまだに存在していること」を確認したものです。\nこれら三者間には関連性はありますが、それは同じ因果関係線上にあるわけではありません。\nA株はまだ過熱感の払拭に取り組んでいる A株市場におけるここ数日の主な要因については、3つの視点から見ていきます。\n第二の層は取引構造です。21世紀経済報告が6月5日の引け後インタビューを行った際、あるファンドマネージャーが「複数の証券会社による半導体およびAI業界リーディングカンパニーへの資金調達換算率引き下げ」を重要な引き金の一つとして挙げました。この見解は、あくまで市場的な解釈の一つとして捉えており、公式な結論として述べるものではありません。しかし、これが示すのは、高値の株が落ちるスピードが加速する理由です。取引が過度に混雑している場合、レバレッジ、証拠金、換算率、および資金調達能力に影響を与えるあらゆる変数が、通常よりも容易に増幅されてしまうからです。\n第3の段階は、スタイルチェンジ（テーマの切り替わり）です。6月8日の下落はハイテク株だけではありませんが、約4,600銘柄が売られたことは、リスク選好が広がり始めていることを示しています。しかしながら、銀行、石油・ガス関連、石炭、北証50といった分野が抵抗して推移した（逆行した）事実は、資金が全てのリスク資産を一斉に投げ売りしているわけではないことを示唆しています。むしろ、高値圏にあったハイテク株の集団から資金を引き出し、その一部をディフェンシブな銘柄に振り分け、残りを小型株やその他のテーマで「弾力性」（＝上昇余地）を探っている動きと解釈できます。\nしたがって、今回のA株の下落を、マクロ的な意味での全面的なリスクの浄化（クリーンアップ）と呼ぶよりも、高値となったテクノロジー株における集中的なデ・コンジェスティングであると捉える方が適切だと考えます。この違いは非常に重要です。前者はセクター内での分散化が起きることを意味しますが、後者となるとすべてのリスク資産をシステム的な危機として扱わなければならないということです。6月8日に追加された情報によると、デ・コンジェスティングはまだ終わっておらず、「金曜日の単一日ショック」から「翌営業日になっても継続的に確認される事態」へと変化しています。\n米国株の日中反発は「出清」完了を意味しない 金曜日の米株の重圧は、まるで二つのボタンが同時に押されたかのようです。\n一つは金利です。BLSの非農業雇用者数データ自体は悪くありませんが、高バリュエーションなテクノロジー株にとって、強すぎる雇用統計は市場に「連邦準備制度理事会（FRB）が緩和策へ転じるのが難しくなるのではないか」という懸念を抱かせます。AI株は特にこれを警戒しています。なぜなら、その多くのバリュエーションが、今後数年間にわたる収益と利益に基づいているからです。割引率がわずかでも上昇すると、長期的なストーリーは大きく削られてしまいます。\nもう一つは、「期待」の問題です。Broadcomの公式な決算報告書が、倒産企業のような「暴落」を示すものではありませんでした。同社は、2026会計年度第2四半期のAI半導体売上高を108億ドル（前年同期比143%増）、そして第3四半期の総売上予測を約294億ドルと発表しました。問題は、これまでAIチップ株が上がりすぎてしまっていることです。市場が求めているのは単に「良好」というものではなく、「すでに高い想像を超えるもの」なのです。決算報告書がその期待値カーブをさらに引き上げ続けることができなければ、資金はまず売りさばくことになるでしょう。\n6月8日の日中の反発は、無視できません。SOXX、Marvell、Micron、AMDのような資産が早く反発するほど、それらが依然として高ボラティリティの取引の中核であることを示しています。短期資金は暴落後に反発を狙いますが、この撤退サイクルが終わるかどうかを真に決定するのは、午前の上昇率ではなく、終値を守れるかどうかの点、出来高がパニック的な手仕舞いから安定した買い板に移行しているか、そして金利予想が引き続きバリュエーションを抑えているかどうかです。\nAI銘柄の最も矛盾している点は、業界トレンド自体は非常に強いにもかかわらず、株価が大きく下落することがあるということです。そして、一度大幅に下がった後には、すぐに反発することもあります。なぜなら、株式取引で求められているのは、「AIに未来があるかどうか」という点ではなく、「現在の価格において、すでにどれだけの『未来』を先行して買い込んでいるか」、そして「市場内に、同じ根拠、同じレバレッジ、同じ時間軸を使って買っている人がどれだけいるか」ということだからです。\n6月5日、6月8日のA株と、6月8日の米国市場の当日中の動きをまとめてみると、本当に注目すべきなのは方向性の謳い文句ではなく、以下のいくつかの変数のことです。\n後方の3本の線 次からは、「AIの買い場（底値掴み）」や「AIから距離を置く」といった二者択一的な判断はしません。AIは依然として今後数年間の設備投資および産業構造のアップグレードにおいて、最も強力なテーマの一つですが、6月5日と6月8日のような調整局面を経て、市場はより選別的になるでしょう。\n第一の点として、過熱感（テーマ性）が本当に解消しているかどうかを見る必要があります。A株の場合、半導体、光モジュール、計算能力ハードウェアにおける出来高の多い個別株が、引き続き出来高を増やした暴落を続けるのか、それとも出来高を抑えて安定化し始めるのかを見極める必要があります。また、銀行、石油ガス、石炭、小型テーマの強さが、一時的なリスク回避によるものなのか、資金がテクノロジー分野のポジションを持続的に下げているのかも見ておくべきです。米国株については、午前の取引時間帯のデータだけを見るのではなく、ナスダック指数やSOXX（半導体）、AIチップ関連銘柄が終値後も日中の反発を維持できるかどうかを注視する必要があります。\n3番目の論点として、バリュエーションが金利に対してまだ敏感かどうかを注視する必要があります。もし米国の雇用やインフレデータが引き続き利下げ期待を後退させると、高バリュエーションのAI株は割引率によって繰り返し圧迫されます。この圧力は業界全体のトレンドを変えるわけではないかもしれませんが、株式のリズムを変えます。以前は市場が2028年の利益に対して資金を提供する意欲があったものの、今は2026年と2027年に確実に見込める受注額に対してしか支払いを望まないかもしれません。\nこれも、以降AI関連株を分析する際、これらを一つのバスケットに入れるのではなく、3つのカテゴリに分けて見ていくことになりました。\n一つは、真に料金設定力があり、安定したキャッシュフローを持ち、顧客基盤が強固なインフラ企業といったタイプです。これらも下落する可能性はありますが、一度落ち込むことで、市場はより容易に再評価（または「改めて算段」）できるようになります。\nあるタイプは、産業バリューチェーンのマッピングと受注期待に支えられている高弾力性の企業群です。これらは急騰しやすい一方で、調整局面での下落幅も大きくなる傾向があります。特に資金調達の制約、業績が市場の期待を下回る場合、および顧客による注文キャンセル（失注）に関する噂に対して弱いのが特徴です。\nまた、コンセプトの拡散のみに依存する企業群というのもある。強気相場ではこれらは最も軽やかに見え、調整局面でもファンダメンタルズの支点を見つけるのは最も難しい。6月5日と6月8日以降、この種の銘柄はより高いリスクディスカウントを要求される必要がある。なぜなら、市場が「物語への寛容さ」から「実現性の厳密な精査」へと移行し始めているからである。\n私の結論は限定的ですが、今回の調整（ローテーション）はAI産業トレンドの終焉ではありません。しかし、おそらくこれはAI株における価格設定方法についての警鐘だと考えます。今後AIを見る際は、「単にAIか否か」という点だけではなく、この企業がAIの設備投資（CapEx）のどの部分から実際に収益を上げているのか、売上総利益率を守れるのか、キャッシュフローはいつ回復するのか、そして現在のバリュエーションが今後2〜3年分の良いニュースすべてをすでに織り込んでいるかどうかを問わなければなりません。\nこれらの問題に答えられない場合、下落が必ずしも安いわけではありません。しかし、もしこれらの問題の回答が得られるのであれば、大幅な下落は単に追従資金を洗い出すだけで終わるでしょう。現在のより難しい点は、米国株の日中の反発が「もう大丈夫だ」という錯覚を与えてしまうことですが、A株の6月8日の終値は、過剰な取引が本当に解けることは通常それほど綺麗なものではないことを思い出させています。\n本記事は市場の振り返りおよび個人的な観察に過ぎず、いかなる投資助言を構成するものではありません。日次および時間中の相場データの算出基準は、取引所、チャートソフト、メディアによる統計方法によって多少異なる場合があります。特に、本文執筆時点における米国株の6月8日のデータは終値（クローズ）基準ではない点にご注意ください。具体的な投資判断は、必ずご自身の口座制約、リスク許容度、および正式に開示された情報に基づいて行ってください。\n参考文献 データマイニング ディープラーニング ニューラルネットワーク 元のプロンプト $blog-writer 先週金曜日、国内A株が大きく下落しました。主な下落原因を分析し、金曜日の夜には米国株も暴落したため、今後のAI関連銘柄の見方について考察します。 今回のアップデート（プロンプト） 本日6月9日です。6月8日のA株の市場データ、および現在の米国株の騰落率（未決済）に基づき、「07-AI-股票回撤后-先看拥挤交易怎么散」の記事を更新します。 記述のアウトライン（構成案）の要約 今回の更新では、元の文章の主要な判断を維持しています。A株と米国株は強引に一つの因果関係として結びつけることはできませんが、両方ともAI取引による過熱（混雑）、金利感応度、業績実現の圧力を露呈させています。新たに追加された6月8日のA株データでは、「金曜日の単日下落」を「次の取引日で混雑が続く」に変更しています。また、追加された米国株の日中市場の情報は、半導体株のお昼あたりの反発を早まって「決済完了」として記述しないよう読者に注意を促すものです。\n個別のA株（中国本土株式）銘柄の漲落や日中の取引推奨は削除しました。なぜなら、こうした内容は復盤の内容を短期売買の指示書にしてしまうからです。本文では、判断を裏付ける指数、セクター、出来高、および米国株の日中値動きのみを残し、関連する段落で「米国市場はまだクローズしていない」という境界線を繰り返し明記しています。\n","date":"2026-06-07","language":"ja","permalink":"https://ttf248.life/ja/p/ai-stocks-after-a-share-us-selloff/","tags":["AI霊感衝突坊","ai","A株 (エーショウ)","ニューヨーク証券取引所（NYSE）/ 株式市場","AI株"],"title":"AIによる株の調整局面では、まず過熱した取引（群集行動）がどのように解消していくかを見るべき。","year":"2026"},{"categories":["コンピューター"],"content":"/goal は、「agent にしばらく動作を続けさせる」という命令だと誤解されやすいです。\nこれは当然、その表象にすぎません。Codexに目標を与えるだけで、その目標を中心に継続的に推し進めることができ、一度の回答で止まるわけではありません。しかし、真に注目すべき点は「長く稼働できること」ではなく、「何が完了と見なされるか（終了条件）」という概念を一時的なリマインダーからタスク自体の一部へと昇華させた点です。\n通常のプロンプト（prompt）は、次に何をすべきかを述べています。それに対し、goal は、エージェントに対して『受入チェックリスト』を渡しているようなものです：目標が何か、境界線（スコープ）はどこか、どの検証項目を通過する必要があるか、そして作業完了のために満たすべき条件とは何か、といった要素を定義しています。\n目標は「次へ（または続行）ボタン」ではありません コマンドの形式（命令形）だけを見ると、/goal は「完了するまで続ける」という概念を強化したようなものに非常に似ています。しかし、このように捉えすぎると、議論が脱線してしまいます。\n長期間のタスクで最も厄介な点は、モデル自身が継続を望むかどうかという点ではなく、各ラウンド終了後に、誰が（またはどの仕組みが）継続すべきかを判断する点です。\nこれらの停点は必ずしも間違っているわけではありませんが、人の受け入れ基準とは異なる場合がよくあります。\n目標が解決すべきことは、このことです。すなわち、受入基準（または「判定基準」）を事前に明確に記述し、それによって以降のすべてのラウンドで判断ができるようにすることです。\n一般的な目標の例は以下の通りです。\n/goal フロントエンドを Next.js に移行する手伝いをしてください。 その問題は短いことではなく、停止条件がないことです。Codexは数ページの移動ができたり、ついでにコンポーネントをリファクタリングしたりでき、さらに追加すべきだと考えるものを継続的に追記し続けることもできます。\nより使える書き方は次のようになります。\n/goal 注文の管理画面を React Router から Next.js App Router へ移行する。 ログインページ、注文リスト、注文詳細、および購入（または決済）ページの見栄えは旧バージョンと一致させる必要がある。 API契約とデータベーススキーマは変更しないこと。 ページ群が完成するたびに、npm run build、npm test、およびPlaywrightの重要パスを実行すること。 これらの検証すべてが通った場合のみ完了とする。 この追加部分は、単なる余談ではなく、4つのコントロールプレーン（制御面）に関するものです：\n要素 作用 目標 最終的にどのような結果であるか 境界 手動では対応できないインターフェース、データ、ファイル、または動作は何か 検証 それが本当に完了したことを証明するための証拠は何か 停止条件 どのような条件を満たした後に停止できるか 「目標」を高くするのは、これら4つのことです。\nなぜ長時間実行できるのか Codex は、一度の回答が引き伸ばされたからではなく、goal の下で継続的に推進することができます。\n実際の作業方法は、むしろサイクルに近いです。すなわち、計画し、実行し、ツールの結果を観察し、修正を行い、続けるかどうかを決定する、というプロセスです。ビルド失敗、テスト失敗、スクリーンショットの不一致、リンティングエラー、評価サンプルが通らないといった事象はすべて、タスクを次のサイクルに戻します。\n「検証方法」が目標に記載されている場合、エージェントは直感や推測だけで「完了したはずだ」とは述べられません。必ず証拠を得る必要があります。証拠が得られない場合は調査を継続し、証拠に問題がある場合は修正を続けなければなりません。すべての証拠が通過して初めて、「完了」と認める資格があります。\nこれが、goal が移行（マイグレーション）、リファクタリング、バッチ校正、プロンプト評価、長尺のデバッグといったタスクに適している理由です。これらの共通の特徴は、一度で完結しない点、そして完成に主観的な判断だけでは頼れない点にあります。\n逆に、このような目標は非常に危険です：\n/goal より高度なプロダクトプランを考案する 境界がなく、検証もされず、かつ停止条件もない。エージェントは長時間動作するかもしれませんが、「長い時間動くこと」が「有用であること」を意味するわけではありません。最低限、何組のソリューションを出力するのか、どのような制約を網羅しているのか、どの基準で絞り込むのか、そしていつ停止するのかを明確に記述する必要があります。\nClaude Codeも同じことを処理しています Claude Code にも /goal があり、公式ドキュメントの説明の方がより直接的です。ユーザーが「完了条件」（completion condition）を設定すると、Claude はその条件が満たされるまでターンをまたいで継続的に作業します。\n『Claude Code』のドキュメントには、各ラウンド終了時に完了条件が満たされているかを確認し、もし条件を満たしていない場合は次のラウンドへ進むと記されています。この点が非常に重要であるのは、「継続」という判断をモデル自身の主観的な結論付けのプロセスから切り離し、外部の追加的な条件判定（ロジック）としているためです。\n両社の具体的な実装詳細が無理に同一である必要はありませんが、方向性は一致しています。すなわち、エージェントは「次の指令を実行する」という段階から、「検証可能な目標を中心に継続的に推進していく」という段階へと移行し始めているということです。\n簡単に分類すると：\nこの表において、goal の役割は非常に明確です。それはフックの代替ではなく、記憶（メモリ）の代替でもありません。それが管理しているのは、「今回のタスクをどの程度まで達成すれば完了とみなせるか」という点です。\nGood goals should be written like acceptance criteria 今から、一つのゴールを四行に分けて記述します。\n目標：最終的にどのようなユーザーに見える結果が出なければならないか。 範囲：どのファイル、インターフェース、データ、視覚的要素、または動作を変更してはならないか。 検証：どのようなコマンド、テスト、スクリーンショット、評価、または手動チェックを証拠として使用するか。 停止条件：すべてが満たされたときに停止するもの。どの権限、事実、製品判断に遭遇したときに一時停止するか。 これは普通のプロンプトとは大きく違います。\n通常のプロンプトは次のアクション（行動）のようなものであり、ゴール（目標）は完成の基準（クオリティ）のようなものです。それは人間をプロセスから排除するのではなく、人間の判断を事前に組み込むものになります。あなたは、「これはまだ完了ではない」と都度指摘する必要がなくなり、「何をもって完了とするか」という条件を最初から守らなければならない制約として記述できるようになるのです。\nですから、エージェントに自主的に動かしてもらいたいほど、目標はより狭く（限定的に）設定する必要があります。\nプロセスへの注視を減らそうとすればするほど、検証（バリデーション）はより具体的・現実的に記述する必要があります。\n逸脱（暴走）を最も避けたいからこそ、境界線を明確に定義することが重要だ。\n「goal」が真に注目すべき点は、ここです。単にコマンドが増えることでも、どれだけ長く動作するかという点でもありません。むしろ、ターミナルエージェントが、「完了の判断を下す主体は誰か」という問題を表舞台に引き上げてきた点にあります。\n参考文献 目標に従う | Codex ユースケース Codex CLI のスラッシュコマンド | OpenAI Developers Codex で長期のタスクを実行する | OpenAI Developers 目標に向かってClaudeを機能させ続ける | Claude Code Docs 執筆に関する補足 元のプロンプト $blog-writer codexが新しくリリースしたgoalコマンドの詳細について、動作原理は何か、なぜ長時間の処理が継続するのか、そして公式が提供する具体的な事例を解説してください。Claude Codeに同様の命名規則はあるか？また、ついでに、最近リリースの2つのターミナルで、便利でおすすめな機能をいくつかピックアップして表としてまとめてください。 執筆のアイデア概要 原文の主要な判断点を維持する：goal の核となるのは、コマンド名ではなく、完了条件である。 元のプロンプトで要求されていた Claude Code の比較とターミナル機能の表を補完する。 「公式ドキュメントの再述」は排除し、実用的な goal の記述方法に重点を置く。 ","date":"2026-05-27","language":"ja","permalink":"https://ttf248.life/ja/p/codex-goal-command-explained/","tags":["AI霊感衝突坊","ai","codex","Claude Code","agent"],"title":"Codex goalは、完了基準をタスク自体に委ねること","year":"2026"},{"categories":["金融知識データベース","投資 (tōshi)"],"content":"A株の半導体およびAIハードウェアバリューチェーンが急騰する際、最も出やすい極端な感情は二種類あります。一つは、「乗り遅れたこと」の痛みが実際の損失を出すよりも辛いと感じるタイプ、もう一つは、過剰に上昇したものは必ず泡（バブル）だと感じてしまうタイプです。\nこれら二つの方向（分野）は、スピードが速すぎます。半導体、コンピューティングパワー（算力）、光モジュール、ストレージといった領域の産業的なロジックは真実である可能性があります。AIの学習と推論は確かにハードウェア需要を牽引し、国産化による代替もまた、現地企業にストーリー性と受注機会を提供しています。しかしながら、問題なのは、業界ロジックが成立したからといって、今飛び込んで利益（リターン）が見込めるわけではないという点です。\n歴史的に、白酒（ホワイトリカー）、新エネルギー、医薬、コア資産への群がり、TMTなど、類似の相場サイクルは繰り返されてきました。いずれの局面にも真のロジックが存在していました。それらが崩壊したからといって、必ずしもロジックが消失したわけではなく、バリュエーション（評価）、ポジションサイジング、業績の実現、そして流動性といった要素間のリズムが間違っていただけなのです。\nまずは今回の値上がり幅を見てみよう まず、対象を明確にしましょう。現在、A株市場で最も強力な「AI関連企業」は、2023年のような広範なメディア概念ではなく、より堅固な三段の連鎖（サプライチェーン）に基づいています。\n半導体製造および装置代理。 自社開発のCPU / GPU / AIチップ。 光モジュール、光デバイス、およびコンピューティングインフラストラクチャ。 以下の表の騰落率は、Yahoo! Finance の前修正終値基準（adj. close）を用いて、2026-05-25 終値まで統一して算出しています：\n公司名 コード 期間 上昇率 半导体 ETF 代理 159995.SZ 2026-04-07 到 2026-05-25 66.1% AI ETF 代理 515070.SS 2026-04-07 到 2026-05-25 40.5% 中芯国际 688981.SS 2026-04-07 到 2026-05-25 63.1% 海光信息 688041.SS 2026-04-07 到 2026-05-25 51.5% 寒武纪 688256.SS 2026-04-07 到 2026-05-25 87.5% 中际旭创 300308.SZ 2026-04-07 到 2026-05-25 76.6% 新易盛 300502.SZ 2026-04-07 到 2026-05-25 43.7% 1ヶ月強の傾きだけを見ると、これはもはや「緩やかな上昇による回復（スローブル修正）」ではなく、非常に典型的な感情とファンダメンタルズが共鳴した主要な急騰です。問題は、それがどれだけ筋道立っているかということではなく、その合理性が株価によってすでにどれほど先行して織り込まれているかという点にあります。\nAIだけではない、多くの「真のロジック」がこれまでに挫折を経験してきた経緯 (Alternative phrasing focusing on failure:)\nAIに限らない。数々の「論理的な概念」も、失敗を繰り返してきた歴史がある 結論から先に述べます。このような相場状況は、以前にも発生しているだけでなく、AIや半導体、TMTといったテクノロジー分野だけに限定されるわけではありません。より一般的なケースは、根拠（ロジック）が依然として存在し、景気もすぐに悪化してはいませんが、株価の最も急激な動きの時点で、数四半期から数年先までの楽観的な期待がすでに織り込まれてしまっているという状況です。\n相場サイクル期間 セクターの主なテーマ 代替株または代表銘柄 上昇局面 継続期間 上昇局面での上昇率 以降の下落要因/動き その後の調整幅 2014-05-16 から ` データマイニング ディープラーニング ニューラルネットワーク これは「ハイテク株になりやすいバブル」なのではなく、A株の数年ごとに本質的なロジックを過熱したコンセンサスにしてしまうことなのです。\n白酒は以前、偽りの論理ではありませんでした。リーディング企業のキャッシュフローとブランドの参入障壁は本物でしたが、50倍や60倍といった評価額で消費の確実性を買うことは、結局回収しなければなりませんでした。 新エネルギーもまた偽りの論理ではありません。浸透率は引き続き上昇していますが、サプライの拡大、価格競争、そして収益の下落が同時に発生した場合、株価は長期的なストーリーがゆっくりと実現するのを待ってくれません。 製薬およびヘルスケアサービス分野の方がより典型です。多くの会社のビジネス自体は残っていますが、政策変数とバリュエーション変数が同時に転換すると、調整（リトレース）に非常に ですから、今日の半導体やAIハードウェアのサプライチェーンには確かに本物があります。しかし、白酒、新エネルギー、医薬品、優良株（「白馬」）の抱団も、かつては本物がありました。その後起こった大混乱の原因は、当初全てのロジックが詐欺だったからではなく、「将来良くなるだろう」というものを価格が「未来は完璧でなければならない」ものとして取引してしまったからです。\n現在、この銘柄群の業績は株価を支えているのでしょうか 注目すべきは、「半導体に将来があるかどうか」ではなく、「利益の伸び率が、直近6〜7週間の株価の上昇トレンドに追いつくことができるか」です。ここでは、最も代表的な数社に分けて見ていきたいと思います。\n人工知能\n第一に、すべての大きな上昇が単なる「空気の回転」（投機的なもの）ではありません。特に中際旭創や新易盛、寒武紀といった銘柄群は、この局面は純粋なコンセプト連鎖ではなく、利益と受注が実際に具現化しています。だからこそ、多くの人は自然と下落（調整）への警戒心を緩め、「業績さえあれば大きく下落することはない」と考えてしまっています。\n第二に、業績の実現がそのまま買い付けポイント（投資タイミング）の安全性とイコールではありません。SMICや海光情報といった企業が良い例として挙がっています。業界ロジック自体は完全に成立しているものの、短期的な株価の弾力性が、最新四半期の利益成長率を明らかに上回って動いています。市場が見ているのは、単に今発表されたこの決算報告書だけではありません。向こう数年間のシェア、ASP（平均販売価格）、設備投資額、そして国産代替といった潜在空間まで、すべてを「最大化できるかどうか」を見ているのです。\nだからこそ、同じ「本物の好景気」であっても、ある人はトレンドから利益を上げる一方で、ある人は調整局面で資金を溶かしてしまいます。間違っているのは方向性ではなく、タイミングなのです。\n現在、半導体への資金投入（買い増し）に関して。問題は正しさの是非ではなく、ポジションにある。 どうしても一言でまとめる必要があるとしたら、私見では以下の通りです。\n今から半導体に買い増しをするのは、方向性が間違っているというわけではなく、単にリスクリワード比率が4月上旬ほど有利ではないからです。特に新規資金にとってはなおさらであり、これは低リスクなポジション構築というよりは、高値圏でのモメンタムを追いかけている側面が強いです。\n現在の半導体とAIハードウェアのチェーン（またはエコシステム）を三つのカテゴリーに分けて見ていきます。\nというわけで、「半導体はどうか？／半導体産業はマシか？」といったご質問であれば、答えは概ね問題ない（あるいは「大丈夫」）でしょう。\n「『2026年5月25日』のようなタイミングで買い増しをした場合、高値掴みにならないかどうか」という点について尋ねているのであれば、その答えは業界のトレンドを用いるべきではなく、ポジション（サイズ）とドローダウンを用いて回答すべきです。\n低値で既にポジションを持っている人は、問題は追いかけるかどうかではなく、どれだけポジションの比重（傾き）を下げるべきかという点です。 高値圏で資金を待っているが追いたい人は、買っているのは、過去6〜7週間ですでに織り尽くされた感情や期待が大部分を占めます。 本当に参入したい人は、より合理的な前提として、単なる大きな陽線よりも、「まともな調整局面（またはレンジ）であること」か、「次回の決算報告によって市場の期待値がさらに前倒しにされること」を待っていることが多いです。 歴史上、今と最も似ているのは、単なる「2021年半導体」や「2023年AI/CPO」といった期間だけではありません。白酒（中国の蒸留酒）、新エネルギー、医薬、そして「白い馬」（優良銘柄群）への資金集中投資からも同じことが警鐘を鳴らしています。市場が最も危険な時期は、必ずしもロジックが一番偽りであるときではなく、かえってロジックが非常にスムーズで、誰もが理解できるときなのです。\n参考文献 Yahoo Finance，159995.SZ 履歴データ：https://finance.yahoo.com/quote/159995.SZ/history Yahoo Finance，515070.SS 履歴データ：https://finance.yahoo.com/quote/515070.SS/history Yahoo Finance，512690.SS 履歴データ：https://finance.yahoo.com/quote/512690.SS/history Yahoo Finance，515030.SS 履歴データ：https://finance.yahoo.com/quote/515030.SS/history Yahoo Finance，512010.SS 履歴データ：https://finance.yahoo.com/quote/512010.SS/history Yahoo Finance，510300.SS 履歴データ：https://finance.yahoo.com/quote/510300.SS/history Yahoo Finance，600519.SS 履歴データ：https://finance.yahoo.com/quote/600519.SS/history 執筆注記\n元のプロンプト $blog-writer 最近急騰したA株のモジュール（半導体、AI関連企業）について、以前にも同様の動きがあったのか？もしあった場合、いつ登場し、どのセクターに関連する銘柄は何か。また、どれくらいの期間持続し、どのように崩壊したかを分析してください。現在、半導体に資金を投じるのは合理的か？これは高値での買い付け 本稿は、上記の元のプロンプトを出発点とし、初回原稿作成時の手法に従って、主要な論旨（メインライン）、材料の密度、および構造を決定しました。`date` フィールドには元の公開日時を引き継ぎ、その他の内容は現在の記事のコミットメントのみに焦点を当てています。 ","date":"2026-05-25","language":"ja","permalink":"https://ttf248.life/ja/p/a-share-semiconductor-ai-rally-timing/","tags":["AI霊感衝突坊","A株 (エーショウ)","半導体","AI","投資 (tōshi)"],"title":"A株の半導体は再び上昇した。産業ロジックが、買われすぎな取引にできるわけではない。","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"プラットフォームにとって、違法な国境を越えた事業の是正が最も損するのは、一、二日分の株価ではなく、これまでの成長モデルそのものが再評価されなければならない点です。罰金というものは一つの会計上の問題にすぎませんが、国内におけるボリューム顧客が引き続き取引、融資、資産、およびコンバージョン（転換）を貢献できるかどうかが、より長期的な課題なのです。\n富途や老虎といったインターネット証券会社が持つ最大の強みは、香港および米国株式取引を低摩擦な（シームレスな）製品として提供している点にあります。しかし、この体験が本土のユーザーを対象とする場合、ライセンス、外貨規制、投資家適格性、データ取り扱い、そして越境金融サービスという複数の境界線上の課題に直面してしまいます。\nしたがって、第3章ではビジネスモデルと機関の層別化に焦点を当てます。クロスボーダー証券会社は依然として強力なプロダクト能力を持っていますが、規制当局による境界線が最大の、最も都合の良いユーザー層を再び囲い込んでしまった場合、その企業価値はもはや以前の成長ストーリーに基づいて語られることはできなくなります。\nインターネット証券会社が最も完全なサンプルである 監管の視点から見ると、Futu、Tiger、Changqiaoには共通点があります。それは、オンラインでのプロセスが一貫しており（または、「線上リンクが完結しており」）、ビジネスモデルが標準化され、顧客獲得と取引の両方が高度にデジタル化されているという点です。このモデルの良い点は成長スピードが速いことですが、欠点として、残されたコンプライアンス上の痕跡もより完全になることです。\n不正な越境活動の経路を分解すると、大体以下のようになります。\nコンテンツと広告による国内ユーザーへのリーチ アプリのダウンロードや口座開設ページへの誘導 リモートでの口座登録完了 海外アカウントによる取引受入 資金の出入りに伴う配套なルート（経路）の確立 カスタマーサービス、コミュニティ、投資教育コンテンツによる継続的なエンゲージメント維持 インターネット証券会社は、これら6つのステップをほぼ標準製品として提供しています。規制当局にとって、このような対象は、定義するのが最も容易であり、証拠の確保も最も容易であり、また模範的な効果を生み出しやすいのです。\nしたがって、最初にインターネット証券会社を例に挙げただけであり、「これらだけが問題である」と解釈する必要はありません。より合理的な理解は、それらが規制当局によって完全に分解可能なサンプルリンク（または実態）のようなものだということです。\n名前が呼ばれていない＝安全な場所ではない この点については、2023年2月15日の証監会（中国証券監督管理委員会）の記者質疑応答で非常に率直に述べられています。すなわち、「同一種の業務に対して統一的な監督を実施する原則に従い、当時はすでに、国内証券会社が海外子会社を通じて行う違法な越境展開に関する規範的な是正措置作業を展開・実施しました」というものです。\nこの文章は非常に重要です。少なくとも3つのことを示しています。\n第一に、規制のロジックは、「インターネット証券会社の基準」と「中国資本系の証券会社の基準」を分けているわけではありません。 第二に、2022年末に始まったのは、FutuやTigerのような個別の事例だけではなく、より大規模な統一的な是正・改善の枠組み（フレームワーク）なのです。 第三に、公的な露出度（注目され方）が異なっても、それが規制上の要求水準が異なることを意味するわけではありません。\nしたがって、「この3社だけが不運を被り、その他はうまく乗り切れる」という見解には同意しません。 しかしながら、「皆クリーンではない」といった言葉だけで断罪することも賛同できません。この判断基準は粗すぎ、真のリスク露出（潜在的な危険）を区別するのに適していません。\nより現実的な表現としては、以下の点が挙げられます。各機関のリスクエクスポージャーの方法が異なるため、改善の圧力も階層化するでしょう。\n分層で見る方が、一発逆転より役立つ (または、多角的に分析する方が、単一の視点より有効である) 公開された定義やビジネスモデルから考えると、大まかに三層に分けることができます。\n分層 典型特徴 圧力の大きさ 高リスクな露出 内地（本土）個人投資家を対象とした、オンラインでの勧誘、口座開設、取引、コミュニティ運営、コンテンツ提供など。 最大 中等リスクな露出 主に既存顧客へのサービスが中心であり、公的な集客行動はやや弱いものの、過去のビジネスチェーンは残っている。 次高 低リスクまたはコンプライアンス対応チャネル 香港株通、QDII、クロスボーダー資産運用通など、認可された、証明書を保持する、または限られた枠組み（額度）のチャネルを通じてサービスを行う。 比較的管理可能 ここで最も混同しやすいのが第3層です。多くの人が、「香港や米国の株式に投資できる」合法的なルートと、「国内ライセンスを持たない海外機関が、中国本土の住民に対して直接事業展開すること」を一つの事柄として混同してしまっています。実際には、これが今回の規制によって明確化されようとしている境界線なのです。\n国境を越えた合法的な投資チャネル自体が全体的に否定されたわけではありません。 規制の対象となったのは、国内のライセンスや市場参入資格、さらには資金・業務上の境界線を迂回するような部分的な経路（リンク）の部分です。\n今後は、実行の細部への注視がより重要になる 公開されている政策に沿って進んでいくとすると、以下の数種類の動きが順次出現する傾向があると考えます。\n第一種として、証券会社自身が地域的な分離（ローカライゼーション）を行うケースです。 例えば、口座開設ページ、開口座リンク、配信チャネル、カスタマーサービスでの応対手順、コミュニティのコンテンツ、口座開設リンクの出所特定など、あらゆる面で国内ユーザーと非国内ユーザーをより厳密に区別するようになります。\n第2のタイプとして、既存口座の取引権限を分割（切分）します。 最も典型的なのは、「売る専用」「買う専用」のように用途を限定する場合や、市場、商品、通貨ごとに権限を分けて処理する場合です。\n第三種として、資金フロー経路の制限が続いています。 証券会社のフロントエンドのアナウンスが完全に出ていない場合でも、銀行、支払い（決済）、両替、入出金といったリンクは先行して制限がかかる可能性があります。多くのケースにおいて、ユーザー体験を最初に阻害するのは取引ボタンではなく、「資金が入ってこないこと」なのです。\n第4の項目です。資産承継の手配が段階的に明確になっています。 この部分は現在、公開されている情報が最も少ないため、最も注目すべき点です。なぜなら、クライアントが最終的にすべてを清算して売却するしかないのか、それともコンプライアンスに準拠した構造を通じて事業を移管・承継できる機会があるのか、という点が決まるからです。\n第5類において、罰則文書で適用範囲を明確にする必要があります。\n特に、「全違法所得」が具体的にどのように計算されるのか、どの期間まで遡及するのか、またどのような主体を対象とするのかといった点です。現在、これらの公表されている基準は不\n3つの名前に留まりません 私の個人的な判断ですが、今回は「特定の3社名を公に指名する」といった水準で終わらない（留まらない）と思います。\n理由は非常に単純です。「八部門（の）合同案」が規制しようとしているのは、特定の種類の活動であり、三社のブランド名ではありません。ビジネスモデルが同じサプライチェーン上にある限り、その後の罰則のペースや公的開示の度合い、改善の強度が異なっても、長期間にわたって枠組みの外を漂うことは難しいでしょう。\n決定的に違うのは、おそらく以下の3点でしょう。\n過去の蓄積規模はどの程度ですか この2年間で、国際化と本土依存からの脱却はどのレベルまで進みましたか 機関は、事前に地域的な隔離策や在庫水準（または蓄積圧力）の引き下げを行いましたか したがって、この件に関して次に注目すべきは、「他に誰が名前を挙げられるか」という単純な推測ではなく、どの企業の事業構造が、今回の境界線（ボーダー）の再定義に最も耐えられるかである。\n数列の収束 これら3本をまとめて読むことで、全体の流れ（脈絡）が非常に明確になります。\n2022年（の時）は、新規追加を制限することが焦点でした。 上証株通（シアンハイ・ストックコネクト）の時は、約1年近くの明確な移行期間が与えられました。 2026年5月22日の今回は、基準が「既存分は売却のみで買い付けを行わない」に引き上げられ、またインターネット証券会社を典型的なサンプルとして公開処理し始めました。\n強いて最も簡潔な判断を下すとするなら、私はこう言います。\nこれは突然の態度の変化ではなく、数年前から構築されてきた規制上の論理（ロジック）が、今や既存事業部門（存量業務）をも組み込んで処理する必要がある段階に達したものです。\nもちろん、その後には実行細則や企業の対応、公式の処分文書、資産の引き継ぎの手配などは出てくるでしょう。しかし、大枠の方向性としては、このグレーな越境小売チャネルは引き続き圧縮され続けており、基本的にはもはや不確実性は残っていません。本当に待つべきなのは、どの程度のスピードで、どのような範囲にわたり、どれほどのコストをかけて縮小されるかという点です。\n参考資料 証券監督委員会、Futu HoldingsおよびTiger Securitiesの不法越境経営活動是正作業を推進（リンク） 証券監督委員会報道官による記者会見（2023年2月15日）（リンク） [中国証券監督委員会など8部門が共同発表：「不法越境 執筆上の注記 元のプロンプト 香港・米国株の取引において、本日突如としてニュースが飛び込んできました。不正な国境を越えた事業展開や、タイガー証券などの機関が厳格に調査される事態が発生しています。富途やタイガーはプレマーケット（取引開始前の時間）で40%も下落しました。まず、前回中国証券監督委員会が行った一連の点検行動を振り返ってみましょう。あの時は国内ユーザーのアカウント開設が完全にロックされましたが、既存顧客への影響はありませんでした。しかし今回は、既存顧客に対し取引禁止措置が取られる可能性があります。去年、あるいは再来年頃に、香港株仲介業者に対して内地の顧客が滬股通（上海株式接続）で取引を行うことが禁止された例もありました。関連政策を検索し、政策の実施から証券会社による執行まで：内地ユーザーが買い付けすることを禁止するまでに、どのくらいの期間の隔たりがあったのかを確認する必要があります。今日のニュースでは、ユーザーに清算のための猶予期間として2年間が与えられたとされています 今回の書き直しでは、原稿の監管上の経路（規制リンク）、機関の階層構造、および今後の観察項目は維持しましたが、第3章の内容を「プラットフォーム成長モデルがどのように再評価されるか」という点に絞り込みました。第2章との重複を避けるため、アカウント操作に関する詳細な掘り下げは行っていません。 ","date":"2026-05-22","language":"ja","permalink":"https://ttf248.life/ja/p/illegal-cross-border-brokerage-crackdown-3/","tags":["AI霊感衝突坊","香港株式 / グローバル株式 (Global Stocks)","証券会社","クロスボーダー規制","チャンチャオ"],"title":"不法越境営業の是正（3）：インターネット証券会社による評価再計算を優先","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"規制に関するニュースが出た後、一般のユーザーが最も関心を持つのは証券会社の株価ではなく、自分自身の口座を動かせるかどうかです。すなわち、買いができるか、売りができるか、資金を引き出せるか、ポジションを移せるかといった点です。ここで最も誤解しやすいのが、「2年間の集中的な是正期間」という部分です。\n新規口座開設のみを制限するだけであれば、既存ユーザーの体感はすぐに変わりません。しかし、さらに既存の取引まで制限した場合、ユーザーは全く異なる問題に直面します。最も穏やかな対策としては、「売るだけ（買いをしない）」という形が考えられます。一方、最も厳しい対策では、資金移動、出金、または特定の取引権限の停止が求められる可能性があります。\nこの記事はユーザー側の視点にのみ言及しています。真に準備すべきなのは、規制が緩和されるかどうかを推測することではなく、「歴史的にどの程度の猶予期間が設けられたか」と「今回の公的な声明がすでに何を要求しているか」という点を分けて見るべきです。\nあの滬股通（上海株式コネクト）の件では、確かに1年近く期間が与えられました。 多くの人は、「後では購入できなくなった」という事実は覚えているものの、どれほどの期間が空いたのかを忘れている傾向があります。公開されたルールと取引所による執行通知に従うと、おおよそ以下のようになります。\n日付 文書/アクション 要点 2022-06-24 香港証券取引所が参加者通知 CT08822E を発行 本土ルールの改定に伴い、資格を持つ既存投資家のために移行措置を設ける 2022-07-25 中国証券監督管理委員会（CSRC） 「ルールが施行されてからフロントエンドでの購入禁止」で計算した場合、期間は2022年7月25日から2023年7月24日までとなり、約364日間です。 「取引所による通告公開からフロントエンドでの購入禁止」で計算した場合、2022年6月24日から2023年7月24日までで、合計395日間となります。 さらに遡って、2022年6月10日に中国証券監督委員会が発表した第200号令の決定までとなると、約409日になります。\nですから、あの時は緩衝期間（または「余裕」）がないわけではなく、約一年間の猶予が与えられており、さらに最終の購入禁止日についても明確に記載されていました。\nしかし、今回直接的に1年分の緩衝期間を適用することはできない 表面的ところ、今回の2年間の重点的な改善期間は前回よりも長いように見えます。しかし、実際には、二つの事柄の規制対象と処理目標が異なります。\n上海株式関連取引の件は、本質的に「逆方向（戻り）の取引」を阻止するものだった。本土の投資家は本来、香港の証券会社を経由してA株を買うべきではないため、規則が改定された際、明確な移行期間が設けられ、最終的には「売りだけ、買いはしない」という形に切り替わり、論理がかなり単一化している。\n2026年の今回の取り締まりは、より複雑になっています。単に特定の取引インターフェースのみを対象とするのではなく、違法な越境証券・先物・基金の運営チェーン全体を視野に入れています。公表された範囲は、同時に以下の要素をカバーしています：\n不法な勧誘 違法な口座開設 不正な委託取引 不正な宣伝による集客（誘導） 国境を越えた資金移動への関与／協力 問題が複雑なため、前回のような全国統一、フロントエンド統一、文案統一の「X月X日 00:00より購入禁止」という対応をすることは、必ずしもできるとは限りません。\nさらに付け加える点として、今回は具体的な組織名（機関）を挙げているうえ、「全額の違法な収益没収と、法に基づいた厳罰処分を行う予定」という点が同時に言及されています。これは単なる制度上の最適化ではなく、明確な法執行・処分的な側面を持っていることを意味します。 したがって、執行措置の進め方（ペース）は、各企業に対する呼び出し（聴取）、是正計画、システム改修、顧客への通知、そして資金引き継ぎの手配などによって左右されるため、単純なスケジュール表でまとめて概説することは難しいでしょう。\nしたがって、上証・深港通の事例は単なる参考情報に過ぎません。規制がルール発表からフロントエンドでの実行に至る過程では、システムおよび顧客側の処理時間を考慮する必要があります。しかし、「今回も必ず1年間通常通り買い付けができる」と断定することはできません。\n2年間のウィンドウであって、2年間自由に買い付けるという意味ではありません 私が一番伝えたい点です。\n「8部門案」および証券監督委員会（CSRC）の記者団向け質疑応答で公に示された主要な方針は以下の通りです。すなわち、集中的な是正期間中は、既存投資家からの買い注文を受け付けることは禁止され、所持している証券を売却し資金を引き出すことのみが許可されます。つまり、公開されている政策レベルから見ると、「2年間」とは、自由に取引を継続するための猶予ではなく、残余業務（存量業務）を整理・清算するための期間であるということです。\nなぜ多くの人は誤解（または、読み違え）するのでしょうか？\n皆が自然と滬株通の件を想起するため。「以前は1年かかったのだから、今回も長くかかる可能性があり、フロントエンドはすぐに動かないかもしれない。」この推測は全く根拠がないわけではないものの、あくまで憶測にとどまり、事実として扱うことはできない。\nより確実な理解の順序は以下の通りです。\n公開された規制の基準は「売却のみ、購入不可」に切り替わりました。 各証券会社のアプリで具体的にどの日に完全に適用されるかは、それぞれの発表を待つ必要があります。 発表が出る前は、「それならデフォルトでしばらく買い続けられるだろう」と逆に仮定することはできません。 この3文の順番は変えてはいけません。ユーザーにとって最も危険なのは、売却が早すぎることや遅すぎることではなく、規制上のクリーンアップウィンドウ（清算期間）を取引猶予期間と誤認することです。\n投資家にとって最も重要なのは、日付を予測することではなく、シグナルを追跡することだ もしあなたが実際にこのような証券会社を利用しているのであれば、最も注視すべきは以下の公開シグナルです。コミュニティのスクリーンショットを最終ルールとして扱うべきではありませんし、他人のアカウントの「可買状況」を自分のアカウントに外推してはいけません。\nシグナル なぜ重要か 噂よりも価値のある理由 証券会社からの公式発表 アカウントが買い付けではなく売却のみに切り替わる時期を決定する これはあなたのアカウントに対する最も直接的な効力を持つ文書である 入出金ルートの変更 交易制限が本格的に適用されるよりも早い場合が多い 銀行、決済、外国為替 過去の経験からすると、アカウント体験に真に影響を与えるのは、規制上のスローガンそのものではなく、むしろこれらの実行上の詳細な部分です。利用者の側ができることとしては、この件を短期的なトレード機会として捉えるのではなく、\n私の結論 「滬股通」の件は、市場に対して非常に明確な参照点を提供しました。それは、規則の発効から実際の売買禁止措置までが約1年間の隔たりがあり、最終的な日付も極めて明確であったという点です。\nしかし、今回は機械的に適用することはできません。理由は、規制がより緩和になるからではなく、むしろ規制の範囲がより広く、執行性がより強く、関連するチェーンが長いため、「公開口調は既に厳しくなっていた」ということと「フロントエンドの一律的な購入禁止日（禁買日）がまだ完全に公になっていない」ということが同時に存在しているからです。\nつまり：\n確認されている事実：今回の公開された規制要件は、2022年のような「通常取引の維持」とは異なります。 未確認な事実：各証券会社が同じ日、同じ方法で買い取りを停止する可能性。 最も危険な誤解：「2年間の整理期間がある」ことを「以前のように2年間購入できる」と理解すること。 次回の記事では、視野をプラットフォーム側の視点に広げます。なぜ富途や老虎、長橋といったインターネット証券会社が最初に名前を挙げられたのか、そして他の中国系証券会社も本当に安全なのでしょうか？\n参考資料 内地与香港股票市场交易互联互通机制若干规定（证监会令第 200 号） 香港交易所参与者通告 CT08822E：关于限制内地投资者参与北向交易的实施安排 富途帮助中心：关于内地投资者参与沪深股通交易的安排 中国证监会等八部门联合印发《开展综合整治非法跨境证券期货基金经营活动专项行动工作方案》 证监会新闻发言人就开展综合整治非法跨境证券期货基金经营活动专项行动答记者问 執筆上の注記 元のプロンプト 香港・米国株取引に関して、今日突発ニュースがありました。不正な越境事業により、ローホーク証券（Tiger Securities）などの機関が厳しく取り締まられています。富途やローホークは取引時間前に40%下落しました。まず前回、中国Securities Investment Association (CSRC) による調査行動を振り返ってみましょう。前回は国内ユーザーの口座開設を完全にロックダウンしましたが、既存顧客には影響しませんでした。今回は、既存顧客に対して取引禁止措置が取られようとしています。 昨年か一昨年のことですが、香港株証券会社が中国本土顧客による滬深港通での取引を禁止されました。関連政策を検索し、ポリシーが実行されるまでに、どこからいつまで「国内ユーザーの買い付け禁止」が行われたのかを確認する必要があります。今日のニュースでは、ユーザーに清算するための期間として2年間が残されているとされていますが、いつから買い付け禁止が執行されるのかは詳細が語られていません。違法所得をどのくらいの期間遡って追及するのかも詳細は不明です。富途が公告を出したにもかかわらず、2026年第1四半期末時点で、中国本土の資産を持つ顧客数が全グループの総資産保有顧客数に占める割合はすでに13%に低下しています。同時に、グループによる有効な国際化戦略のもと、海外資産を持つ顧客数は継続的に増加しています。顧客数の点だけでなく、資産規模と取引量の比率という2点が重要です。株価は下落し続けており、回復していません。 今回の書き直しでは、上海株のロールオーバー（渡期）に関するタイムラインと公式文書上の基準は維持していますが、第2部の中心を「2年間の期間という窓口は誤解してはいけない」に変更しました。具体的な取引上のアドバイスや、どの証券会社が有効日であるかを推測することはしておらず、規制上の事実を交易指示として記述するのを避けています。 ","date":"2026-05-22","language":"ja","permalink":"https://ttf248.life/ja/p/illegal-cross-border-brokerage-crackdown-2/","tags":["AI霊感衝突坊","滬深港通","富途","クロスボーダー規制"],"title":"不法な国境を越えた事業への是正措置（II）：最も誤解されやすい「2年間」の期間","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"香港・米国の証券会社が調査を受け、株価が先に下落し、その後に口座の問題がユーザーに真正面から突きつけられました。今回最も重要な変化は、単なる規制当局からの声明がまた一つ増えたことではなく、「これ以上新規で追加しない」という境界線から、「既存のものをどう撤退させるか」へと焦点が移行した点です。\n前回の調査において、多くの人は「国内ユーザーは安易に新規で口座を開設できなくなったが、すでに開設しているユーザーは引き続き取引をすることができる」と理解していました。この境界線は、プラットフォームとユーザー双方に緩衝材（バッファ）を与え、既存の口座を「グレーではあるが維持可能な歴史的な負債」のように見せています。\nこの一連の文章を三つの記事に分けるべきです。第1の記事では規制の境界線のみについて述べ、第2の記事では口座がどのように変動・利用できるかを扱い、第3の記事でプラットフォームや他の証券会社がどのように再価格設定を行うかという点に焦点を当てます。まず「境界線」を明確にしておくことで、後からユーザーのアクション、企業価値の評価、業界の立て直しといった複数の要素をごちゃ混ぜにしてしまうことを防ぐことができます。\n2022年は新規成長の固定化、2026年は既存量の維持・管理 時系列に沿って（出来事を）展開すると、多くの誤った解釈は、この二度の是正措置を一つの事象として混同してしまっていることに起因しています。\n時期 公開された行動 主要な指針 2022-12-30 証監会がFutuやTigerによる違法な越境事業の是正を推進 増加分を効果的に抑制し、既存分の問題を秩序立てて解消させること。新規口座開設を停止し、既存顧客は引き続き取引可能。 2023-02-15 証監会が記者団に回答し、適用範囲を国内証券会社の外資子会社まで拡大 同種の業務に対して統一的な規制を行う。理由のない形で既存 2022年当時、規制は蛇口を閉め、新しい水の流入を防いでいました。しかし、2026年では、もはや新規の追加だけを止めるのではなく、古い水までも外に出し始めました。この二つの最も本質的な違いは一言に尽きます：\n2022年：既存顧客は引き続き取引が可能です。 2026年：既存顧客は購入ができなくなり、保有している有価証券を売却し、資金を引き出すことのみとなります。 これが市場の反応がこれほど大きくなった理由です。インターネット証券会社にとって、新規口座開設の制限は「成長の勾配」を傷つけます。一方、既存顧客が売りばかりで買い込まない状態は、「取引活動性」「リテンション（維持率）」「資金の淀み」「信用取引・有価証券売買（マージン取引など）」、そして「資産運用コンサルティングへの転換」といった要素を損ないます。前者は成長ストーリーが減速していること、後者はビジネスモデルそのものが再評価されていることを示しています。\nすでに明らかになっているものは多く、未公開のものであっても非常に重要です 公開されている口径で見ると、すでに明らかになっている部分は少なくありません。\n第一に、規制の対象はアプリ名だけではなく、「違法な越境業務チェーン」全体です。八部門による計画では非常に明確で、目標として、違法な勧誘（募集）、口座開設、取引、資金送金、宣伝による誘導など、これらの活動を総合的に是正することが挙げられています。証券監督委員会もまた、この問題を「秘匿性がより強く、危害がより大きい」新たな不正行為・違反活動として定義しています。\n第二に、摘発・処分の厳しさが2022年よりも強まっています。証券監督委員会（CSRC）は5月22日に公開した口調を、「老虎、富途、長橋および関連する国内外のすべての主体から違法所得全額を没収し、法律に基づいて厳しく処罰する意向」にまで引き上げました。そして当日夕方以降、米証券取引所に上場している両プラットフォームが自ら開示したSEC情報が、市場が最も注目する「規模（量）」をさらに具体的にしました。富途の公的な伝達口調に基づく提案される罰金総額は、概算で18.5億人民元に及びます。一方、老虎自身が開示している課徴金の累計合計は約4.112億人民元です。\n3つ目に、2年間の集中的な改善・是正（整頓）期間が設けられました。この「2年間」は重要ですが、「この2年間は何事も変わらない」と単純に理解することはできません。公的な発表内容はそれとは真逆です。集中的な改善期間中は、既に既存顧客に対して購入を禁止し、売却のみを要求しています。「2年間」というのは、自由な取引の窓口というより、清算（退場）のための窓口のようなものです。\n市場を真に動揺させているのは、まだ完全に公開されていない部分です。こうした情報の空白は、憶測（噂）で埋めることもできず、また規制当局の具体的な実施日を代わりに定めることもできません。\nこれらの空白は、そのままバリュエーション・ディスカウントとなります。最悪の口径（シナリオ）が不明なため、市場はまずより厳格な基準に基づいて算出する傾向があります。\n「13%の顧客数は、計算に影響しません」 富途の回答には、市場を安心させる言葉が広まっています：「2026年第1四半期末時点で、中国本土に資産を持つ顧客数がグループ全体の資産を持つ顧客総数に占める割合はすでに13%まで低下し、海外に資産を持つ顧客は継続的に増加しています。」\nこの記述が全く役に立たないとは言えませんが、利益への影響を算出するには程遠すぎます。\n問題なのは、それが「顧客数比率」しか提供しておらず、最も重要な2つの項目が欠けている点です。\n中国本土顧客の資産規模比率 中国本土顧客の取引高またはコミッション（手数料）貢献度比率 これらの項目が不明な場合、13%という数字を利益への影響に直接結びつけることができません。インターネット証券会社が最も懸念するのは、このような計測基準（定義）のミスマッチです。顧客数が少ないからといって、必ずしも資産規模が小さいわけではなく、取引力が弱いわけでもありません。特に既存顧客は、資金量が大きく、売買回転率が高い傾向にあり、また融資ニーズも強いため、単一のアカウントが持つビジネス価値は低いとは限りません。\n富途が最近公開した財務報告書からわかるのは、グループ全体の指標は依然として非常に強いということです。2025年の年間財務報告書および年次報告書の両方で開示されているところによると、総顧客資産は既に1兆2300億香港ドルに達し、2025年の収益は228億香港ドル、ファンド口座（funded accounts）は336万5千件に上っています。これは、同社が過去数年間で国際展開を確かに進めてきたことを示しています。しかしながら、同じ公開資料の中には、「\nしたがって、市場が今は信用してくれないのは当然のことです。国際化を信じていないわけではなく、単に内地の既存顧客が資産と取引の活発度という側面で、具体的にどれほど残っているのか（またはどの程度活性化しているのか）が分からないだけなのです。顧客数は人数ベースですが、バリュエーションは、資産、交易、資金調達、そして通貨化といった側面にこそより関心があるのです。\nこれは普通の罰金によるネガティブ材料ではない 市場オープン前に40％以上急落したものの、その後迅速な反発（または回復）を見せなかったのは、根本的にこのネガティブ要因が非線形であるためです。\n単に数千万規模の罰金であれば、市場はこれを一時的な損失として織り込むでしょう。 しかし現在公表されている数字は、Futuで約18.5億元人民元、Tigerで約4.112億元人民元に引き上げられており、その規模は明らかに「小さな傷」ではありません。\nもし新規追加の停止に留まるだけなら、市場は成長の鈍化を織り込むでしょう。 しかし、「既存の売却のみを許可し、購入\n\\[ \\text{将来の評価額} \\neq \\text{現在の顧客数} \\times \\text{単純ディスカウント} \\] 3段階の割引が同時に適用されているようなものです：\n取引頻度の低下 口座資産の流出 コンプライアンスコストと不確実性の高まり もう一段階として、将来的にこの「グレーゾーン」（曖昧な領域）を通じてさらなる増分を計上できるのか。今回の公式見解では、もはや幻想の余地は残されていない。\nしたがって、今回の株価の下落は単なる感情的な変動ではなく、規制当局が長期にわたって存在していたにもかかわらず十分に価格に織り込まれていなかったリスクを、一度に表面化させたようですね。問題の難しさは、「一回でいくら罰金が出るか」という点にあるのではなく、「残った既存ストックをどのように収益に変えていけるか」というところにあります。\n私の現在の所見 私の見解は非常に明確です。2026年5月22日のこの局面（またはサイクル）は、2022年の過去の事象の再燃ではなく、前回実施された規制強化策のアップグレード版であり、すでに「これ以上の拡大を禁止する」段階から、「既存分の縮小化を求める」段階へと移行しています。\nFutuやTigerのような銘柄を保有している人にとって、次に注目すべきはコミュニティ内の感情ではなく、3種類の公開情報です。\n各証券会社独自の実施に関する発表、特に買い付け制限の開始日 処分文書またはその後の正式な決定における「違法所得」の計算基準（算定方法） 資産移動、口座分類、地域隔離といった付帯的な取り決めが発生するかどうか 参考文献 元のプロンプト 香港・米株取引に関する今日の発破ニュースです。不法な越境事業展開が発覚し、タイガー証券などの機関が厳しく取り締まられています。富途やタイガーは時間外取引で40%下落しました。まずは前回の中国証 今回の書き直しでは、元原稿のタイムライン、公式文書、および会社の開示基準は保持していますが、「新たに追加された制限」と「既存の処理（処分）」の違いに第一の記事で焦点を絞りました。アカウント実行ウィンドウやその他の証券会社による階層分けについては、本記事では展開せず、後続の二つの記事でそれぞれ扱います。 ","date":"2026-05-22","language":"ja","permalink":"https://ttf248.life/ja/p/illegal-cross-border-brokerage-crackdown-1/","tags":["AI霊感衝突坊","香港株式 / グローバル株式 (Global Stocks)","富途","トラ柄証券","クロスボーダー規制"],"title":"不法な国境を越える業務（活動）の是正措置（１）：既存口座の境界線の再定義","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"智譜（ZhiPu）とMiniMaxが恒生テック指数に組み込まれた後、最もよく提起される問題は、「まだ初回ロックアップ期間ではないのに、指数ファンドは強制的に買い集めを強いられるのではないか？」という点です。\nこの問題（本件）については、単なる感情だけで回答することはできません。\n指数の組み入れは、まず公開された方法論に従う必要があります。ロックアップ（解禁）は将来的な供給量と株価の圧力に影響を及ぼしますが、恒生テクノロジー指数の方法論における絶対的な障壁ではありません。パッシブファンドが指数発効前後で買い入れるのは、指数を追跡する必要があるためであり、上場企業が既存株主（老株主）の出口戦略を手配しているわけではないからです。\n恒科のルールに「解禁」の項目が見当たりません ハングリー・セン・テック指数の方法論は非常に明確に記載されており、香港に上場し、テクノロジーテーマへの露出が高い30社で構成されています。\nいくつかの重要な条件を先に提示することができます：\n「最初に制限が解かれるまでの期間（または猶予期間）を経ることが必須」という記述は、ここにはありません。\nしたがって、智谱やMiniMaxが業界、テーマ、イノベーション選別、流動性、時価総額ランキングなどの要件を満たす場合、恒科に進出できる可能性があります。ただし、それが第一層のロックアップ期間まであと1ヶ月かどうかは、別の問題です。\nここが、インデックスルールと投資感情が頻繁に衝突する点でもあります。投資家は「今買うのが誰かを代わりに引き受けているのか」を気にし、一方のインデックスの方法論は「それがサンプル選択条件を満たしているか」を気にしています。\n今回の告知で具体的に変更された点は何ですか？ 恒生指数公司は、2026年5月22日に四半期レビュー結果を発表しました。公告には、すべての変更が2026年6月5日の取引終了後に実施され、2026年6月8日から発効すると記載されています。\n恒生科技指数は今回も30の構成銘柄を維持し、調整内容は以下の通りです：\nアクション 企業名 組み入れ MiniMax Group Inc. - W 0100 組み入れ 北京智譜華章科技股份有限公司 2513 除外 金蝶国際ソフトウェアグループ有限公司 0268 除外 金山ソフトウェア有限公司 3888 これらの4つの名前を並べると、「AIの新興勢力が老舗のソフトウェア企業に取って代わる」といった文章になりがちです。しかし、これは単なる物語的な表現にすぎません。真のルールはもっと厳しく、四半期のレビューの後には、30のポジションがメソッド論に基づいて再編成され、参入する者と撤退する者がいます。\n今回注目すべきなのは、「誰が参入したか」ということではなく、参入した後にどれほどの「重み」（影響力や価値）を持つかという点です。\n「指数が2026年5月20日に調整されるという仮定」に基づいて、変更後のウェイトを付属資料三に記載しています。智譜（Zhipu）とMiniMaxの初期ウェイトは高くありません：\n会社 流動係数 調整後ウェイト 智譜 2513 8% 0.53% MiniMax 0100 6% 0.36% 金蝶國際 0268 85% 除外前 0.70% 金山軟件 3888 75% 除外前 0.67% 新規組み入れされた2社の合計は1%に満たないものです。\nしたがって、「パッシブファンドによる購入」は事実ですが、「巨額の買い支え（または、大口な吸い上げ）」を「組み入れられた」という2文字だけで導き出すことはできません。買いの大きさを見るためには、フリーフローティング時価総額、ウェイト、トラッキング資金規模、そして有効期間内の取引の混雑度を確認する必要があります。\n銘柄の取り扱い可能化（または上場開示）と指数への組み入れは別の概念である 「元の問題で最も重要な点は、『まだ解禁されていないのに、ファンドが買い支えをするのか』という点です。」\nここを3層に分ける必要があります。\nまず、株主が売却できるかを確認する。\n目論見書に記載されているロックアップ期間が経過していない場合、関係株主はもともと市場で売却することができません。インデックスファンドによる購入の場合も、二次市場の流通分でのみ買い付けることができ、ロックされた株式を直接売却可能な株式に変えることはできません。\n第二に、指数の法則は〜（この部分は文脈によって翻訳が異なります）。\n恒科の方法論は、サンプル空間、テクノロジーテーマ、イノベーション選別、時価総額ランキング、四半期レビュー、フリーフローティング比重、および上限制約を考慮しています。そこは、「最初のロックアップ期間が経過した」ことをスクリーニング条件として設定しているわけではありません。\n第三に、パッシブ資金は購入するのでしょうか？\n恒科のETFや指数商品を追跡する場合、発効前後の保有調整が必要となります。これは、個別の企業が「割安かどうか」を能動的に判断しているのではなく、トラッキングエラーを管理するためのものです。\nこれら3層（または「これらの3つの要素」）を一緒に考えることで、結論はより明確になります。\n今回の組み入れは、ロックアップされた株主に対して売却ルートを提供するものではありません。 それは流動株（流通プール）に確実な受動的な買い需要をもたらします。 流通盤が薄い場合、価格弾力性がより顕著になる可能性があります。 しかし、これは「インデックスファンドがロック解除された株主の分を代わりに引き取る」ということではありません。 より正確な言い方をすると、ルールは（銘柄の）ロックアップ解除を見ていません。資金が注目するのは流通株数（フリーフロー）です。\n組み入れが上昇を保証するものではありません またよくある誤解として、「指数を買い進む（エントリーする）＝必ず強気なシグナル、売りに転じる（エグジットする）＝必ず弱気なシグナル」だと捉えてしまう点があります。\n短期的に取引に影響を及ぼす可能性があります。発表から効力発生までの間、アクティブ資金、アービトラージ資金、ETFの組み換え、およびデリバティブによるヘッジなどは、すべて先行して動き出す傾向があります。発効日前の最後のクローズでは、機械的な売買の動きが見えやすいことがよくあります。\nしかし、中長期的な視点では単純に（それだけで）はなりません。\nハンセンテクノロジー指数は四半期ごとのレビューです。多くの場合、企業が組み入れられる時点では、時価総額、出来高、市場の関心度はすでに一定の動きを経ており、除外される時点でも、株価や流動性は既に一巡弱くなっている可能性があります。指数の調整は、新しいファンダメンタルズの出発点というより、むしろ事後的な確認に過ぎません。\nしたがって、指数の調整という点に注目して、3つのポイントに分けて説明します。\n問題 何を見るか 組み入れられるか？ 方法論、業界、テーマ、イノベーション選別、時価総額ランキング パッシブな買い需要があるか？ 初期ウェイト、追跡資金の規模、適用ウィンドウ（有効期間） 今後上昇するか？ 企業のファンダメンタルズ、バリュエーション、 まず第一にルール、第二にトレード、そして第三に投資判断です。\nこれらを混同すると、「指数への組み入れ」を万能な追い風として捉えがちになったり、あるいは「まだ解禁されていないこと」を万能の陰謀だと見なしがちになってしまう。\n智譜とMiniMaxについての見解 智譜とMiniMaxが[恒科]に組み入れられたことは、香港のAI企業が指数付き企業のルール上の視野に入り始めたことを示している。この件は象徴的な意味合いを持つとともに、短期的な取引への影響も及ぼす。\nしかし、それはファンダメンタルズによる裏付けでもなく、上場廃止の取り決めを確定させるものでもありません。\n真に注視（または「焦点」）を当てるべきは、以下の三点です：\nまず第一に、ウェイトが上昇し続けるかどうかという点です。初期のウェイトが低いからといって、今後も常に低水準であるとは限りません。その後の株価、時価総額、流通係数の変動はすべてリバランスに影響を及ぼします。\n第二に、ロックアップ解除後の流通株の変化です。指数への組み入れだけでは供給の問題は解決できません。ロックアップ期間が過ぎると実質的な流通株が増加するため、価格の圧力については再評価が必要です。\n第三に、恒科自体の資金環境です。資金規模の追跡、ETFの申し込みと償還、恒科先物およびオプションによるヘッジなどはすべて、発効前後の取引への影響を及ぼします。\nですから、この件を「底買い」や、「大きな追い風（ポジティブな材料）」といった形で記述はしません。\nこれはルールが確認されたようなものです。AI関連の新規株式が手法を満たし指数に組み入れられ、パッシブ資金はウェイトに応じて購入します。それ以降のパフォーマンスは、引き続きファンダメンタルズ、流通株数、そして市場センチメントに委ねられます。\n一言で圧縮すると：\n規則は解禁期間を考慮せず、ファンドは重み付けに基づいて購入します。その後の値動きがどうなるかについては、指数会社の責任ではありません。\n参考資料 作成にあたっての注記 元のプロンプト $blog-writer 恒生テクノロジー指数の調整について。智譜とMinimaxが指数に組み込まれるとのことですが、その調整ルールはどのようなものですか ### 執筆構想の要約 ","date":"2026-05-22","language":"ja","permalink":"https://ttf248.life/ja/p/hang-seng-tech-index-zhipu-minimax-review-rules/","tags":["AI霊感衝突坊","恆生テクノロジー指数 (こうせい テクノロジー しすい)","恒生指数 (こうせいしじょ)","エクイティファンド","ai"],"title":"智譜とMiniMaxがヘン科に入った件だが、ルールと買い板は全くの別物だ。","year":"2026"},{"categories":["金融知識データベース"],"content":"米国債を初めて見る人は、数字を読み間違えがちです。\n市場で「4.5%」という表記を見ると、「今から投資したら、毎年確実に4.5%が取れるし、満期までずっと受け取れそうだ」と勝手に（あるいは思わず）解釈してしまいます。\nこの文は半分だけ正しいです。\n「4.5%」という数字は、「年換算利回り（アニュアルライズド・リターン）」の基準に近い場合が多いだけであり、「毎年必ず4.5%で現金がもらえる」ということではありません。実際にお客様の口座に入金されるのは、配当金（またはクーポン）、購入価格、そして満期償還というこれら3つの要素すべてを合算して計算された結果となります。\n結論から言うと 通常の固定金利の米国債、すなわち Treasury Notes または Treasury Bonds を購入し、満期まで保有して早期に売却しない場合、という点について。\n受け取るのは、ルールに従って支払われるキャッシュフローであり、空中に浮かぶようなパーセンテージではありません。 中間では、通常6ヶ月に一度、利息を受け取ります。 満期時には元本を取り戻します。 購入時に目にする 4.5% は、おおよそ「満期保有時においてこの水準に近づく年換算の利回り」と理解していただいて構いませんが、「毎年4.5%の現金が支払われる」ことを意味するわけではありません。 あなたが購入しているのが、1年以内の短期国庫証券である「Treasury Bills」の場合、こちらはまた別の戦略となります。\n期間中は通常、利息は支払われません。 ディスカウント価格で購入し、満期時には額面元本で償還されます。 収益の主な源泉は、「購入価格」と「満期時に回収する金額」との差額です。 ですから、米国債の初心者の方はまずこの一言を覚えてください。あなたが買っているのが、クーポン付きの債券なのか、それとも割引短期債券なのかを明確に区別することです。\n4.5%とは何か ここで特に混同しやすいのが、以下の3つの用語です：\n米国財務省はTreasuryDirectで非常に明確に記載しています。「Notes」と「Bonds」には半年ごとに利息が支払われ、クーポンレートは入札時に決定されます。しかし、債券価格は利回りとともに変動します。つまり、利回りは直接あなたに支払われる現金ではなく、価格と将来のキャッシュフローを組み合わせて計算された年率の結果なのです。\nそのため、ニュースでよく目にする「10年物米国債の利回りが4.5%に上昇」という報道は、「今から10年物米国債を買うと毎年4.5%の現金配当が得られる」と直接的に翻訳することはできません。これは、市場が当該期間の米国債に対して算出し提示する利回り水準のようなものです。ここで私が提供している解説は、TreasuryDirectが定義しているクーポン（票息）、価格、および利回りの関係に基づいて行っています。\n公式の新しい債券で算出 空気を読んで話しても無駄なので、公式のオークション結果をそのまま伝えましょう。\n米国財務省は、2026年5月12日に発表された「10年物国債（10-Year Note）」のオークション結果です。\n`金利`：`4-3/8%`、つまり `4.375%` `高利回り`：`4.468%` `価格`：`99.256552` `発行日`：`2026-05-15` `満期日`：`2036-05-15` 今回のオークション結果に基づき、「1,000 USドル額面」を購入する場合、まずは費用（勘定）は以下のようになります：\nプロジェクト 数値 意味する内容 액면가 $1,000 満期時に取り戻せる元本の基準額 購入価格 $992.57 価格が 99.256552 のため、1,00 配当金という件は、実は式がとてもシンプルです：\n\\[ \\text{半期クーポン}=\\text{面額}\\times\\text{クーポン率}\\div 2 \\]この「債」に代入すると、それは次のようになります。\n\\[ 1000\\times 4.375\\% \\div 2 = 21.875\\text{ ドル} \\]この10年間ずっと売却せず、税金や為替レートも考慮しないと仮定した場合、名目上の総キャッシュフローは以下のようになります。\n\\[ \\text{総キャッシュフロー}=\\text{総クーポン}+\\text{到期元本}=437.50+1000=1437.50\\text{ 米ドル} \\]あなたの当初の仕入れコストは、約 $992.57 です。したがって「合計でいくら戻ってきたか」という視点から見れば、この負債（投資）が損失であるということは当然ありません。\nただし、ここで一度立ち止まる必要があります。これは、あなたが毎年 4.468% の現金を受け取るということではありません。\nあなたが実際に受け取るものは、これです：\n半年に一度、利払い（配当金）が支払われます。 最終的な満期日に元本が払い戻されます。 額面を下回る価格で購入されているため、さらに「購入価格から額面への回復」による上乗せ分（スプレッド）も得られます。 これら3つの部分を組み合わせることで、あのオークション結果に記載されている 4.468% High Yield が完成します。\nなぜクーポン利回りが4.375%なのに、利回りは4.468%なのか 額面より安く購入したからです。\nこの債券のクーポンは 4.375% に過ぎませんが、取引価格は 99.256552 であり、額面の 100 よりも低いです。したがって、毎年受け取る利息は額面に基づいた 4.375% のみですが、償還時にはやはり 100 が元本として返済されます。この中間で発生したわずかな価格差が、全体的な保有期間の利回りを 4.468% まで引き上げる要因となります。\n逆もまた真である。\nある既存債券のクーポン利息が市場の利回りより高い場合、その債券はプレミアム（上値）で取引されがちです。そのため、購入する際にはより高額な資金を支払う必要があります。\nこうなるため、半年ごとに受け取るクーポン利息が増えるものの、満期時には額面価格しか戻ってきません。その結果、最初に支払ったプレミアム分が徐々に目減りし\nしたがって、米国債を見る場合、最も確実な順番はまず 4.5% を見るのではなく、むしろ：\nまず、どのような種類の債券であるか、そして残りの満期年数を確認します。 次に、クーポン（利息）がいくらかをチェックします。 最後に、実際に購入した価格に基づいた利回りを確認します。 全く売らずに保有し続ける場合、収益率を本当に4.5%と解釈できるのか 可能です。ただし、脚注を2つ追加する必要があります。\n第1に、4.5% は年率（年間換算）の基準に見えるだけであり、現金支払いペースを示すものではありません。 固定金利のNoteまたはBondを購入し、途中で売却することなく、実際に満期まで保有する場合、購入したその瞬間には一連の将来のキャッシュフローが確定します。\n半年ごとの利息額 満期償還元本 この一連のキャッシュフローに対して、現在いくらを支払いましたか 市場が示す「Yield to Maturity」（利回り）とは、これら3つの要素を年率の収益率に換算したものです。初心者の方にとっては、「この債券を償還（満期）まで保有した場合、だいたいこのくらいの利回りになる」とご理解いただければ大丈夫です。\n第二に、口座内の資金は自動的に複利計算されません。4.5% この点は誤解されやすいところでもあります。\n債券のYTM（利回り）は年率ベースの収益率ですが、途中で受け取ったクーポンが単に口座に留まっているだけで再投資されない場合、それ自体が同じ利回りを生み出すわけではありません。\n言い換えれば：\n債券自体のキャッシュフローは、おおよそ事前にわかります。 あなたの最終的な複利（再投資）結果は、クーポンを受け取った後どのように処理するかによります。 したがって、より厳密な言い方をすれば、「購入時に目にする 4.5% は、『保有期間に応じた年率リターン（目安）』のようなものであり、『口座が毎年自動で複利4.5%になるという保証書』ではありません。」\nいつ配布されますか 物事は分類（品目別）にして、すべてを一度に手詰めしようとしないでください。\n(または、より自然なアドバイスの表現として：) 課題は一つひとつに分け、全体をまとめて対処しようとしない方が良いです。\n国庫証券 米国財務省の公式な定義では、「Bills」は1年またはそれ以下の期間の国庫証券であり、通常は割引価格で発行され、満期時に額面金額が支払われるものです。\nあなたにとってそれは：\n購入時に初期費用を支払う必要があります 期間中、通常は定期的な利息（クーポン）の支払いはありません 到期時に額面金額が一度に払い戻されます したがって、もしあなたが短期債を購入した場合、「いつ利息が支払われるか？」と尋ねると、答えはしばしば次のようになります。月々でも半年に一度でもなく、途中の支払いはなく、満期時にまとめて清算されます。\nTreasury Notes および Treasury Bonds これら二つの種類はクーポン債（または利払いのある債券）です。米国財務省の公式文書には「固定金利で、到期日まで6ヶ月ごとに一度利息を支払う」と明確に記載されています。\nあなたにとってそれは、というものです：\n半年ごとにクーポンを受け取る 到期時に元本を回収する 初心者の方には分かりにくい詳細な点も一つあります。米国財務省の説明によると、特定の reopening を購入する際、価格に一定の発生利息が含まれる場合があります。この部分は、初回正式な金利支払い時に回収されます。つまり、最初に振り込まれる金額が直感的に予想される額と異なることがありますが、それは必ずしもシステム上の計算ミスであるわけではありません。\n私がまずクリアにしておくべきだと考えるのは、収益率そのものではなく、「（指標の）定義」です 初めて米国債を買うのであれば、最初から「4.5％は高いのか低いのか」を気にするのは控えたほうが良いです。\nまず、以下の3点を理解しておけば、後に遭遇する多くの「落とし穴」（または「トラップ」）が自動的に半分になります。\n「収益率」は「配当金」とは異なります。 「償還までの利回り」は「年間現金分配比率」とは異なります。 「売却しないこと」は、途中の価格変動が売却結果に与える影響を避けられる助けになりますが、為替レート、税金、および証券会社の手数料を避けることはできません。 この記事では、あえて最後の項目における「為替レート」、「税金」、および「証券会社手数料」については深く掘り下げていません。これらの要素が重要でないわけではありませんが、これら3つの変数が一度に入ると、米国債そのものの利回りメカニズムが混同されやすいからです。「まず『債券自体がお金をどう支払うか』という点を理解してから、国境を越えた投資のレイヤーを見ていただくと、ずっと簡単になりますよ。」\n参考資料 TreasuryDirect, 米国財務省証書について TreasuryDirect, 価格設定と金利の理解 TreasuryDirect, 米国財務市場証券の購入方法 U.S. Treasury, 米国財務省オークション結果、10年債、2026年5月12日 執筆上の注記 元のプロンプト 米国債の利回りについて詳しく教えてください。例えば、現在市場価格が4.5%の米国債の場合、今から購入して売却せずに保有し続けた場合、どれくらいの利回りになりますか？また、利息はいつ支払われますか？私は米国債に関する知識が全くない初心者です。\n執筆の構想（アイデア）概要 まず「クーポン」「利回り」「成約価格」の3つの側面を分けて説明する必要があり、そうしないと後述するキャッシュフローすべてが誤解につながる。 抽象的な定義だけにとどまらず、具体的な例として 2026-05-12 の公式な10年物米国債入札結果を使用することを推奨する。 本文では、「購入後にどのようなお金を、いつ受け取れるか」に重点を置き、単なるマクロ金利の解説にならないように留意する。 ディスカウント型の短期間債（Bills）とクーポン付債（Notes/Bonds）は明確に分けて記述し、割引短期債とクーポン付債を混同させない工夫をする。 本稿では、「為替レート」「税金」「証券会社手数料」の詳細は割愛し、あくまでリマインダーとして残すことにする。なぜなら、ユーザーがまずは米国債自体の収益メカニズムを理解することが最優先だからである。 ブレストの拡張 ","date":"2026-05-21","language":"ja","permalink":"https://ttf248.life/ja/p/understanding-us-treasury-yield-for-beginners/","tags":["米国債","債券 (seitoken)","収益率","金融","AI霊感衝突坊"],"title":"米国債利回り 4.5%、購入後具体的に何が得られるのか？","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"結論から言うと。\n2026年5月20日現在、A株の強さと恒生科技（HST）の弱さは、一つの資産プールの中で誰か一人が取り残されたという話ではなく、二つの異なるプライシングロジックが分岐していることを示しています。上証指数は2026年5月20日に4162.19点で取引を終え、依然として4200ポイント付近で推移していますが、恒生科技指数は直近の取引日である2026年5月19日に4857.46点を記録したものの、2021年2月17日の局面的な過去最高点10945.22からはまだ55.6%も乖離しています。\nあなたが言及された「滬深300 ETFが史上最高値を更新した」というのが、最も一般的な510300を指している場合、私が2026年5月20日に取得した終値は4.871であり、これは2021年2月10日の5.807から約16.1%のドローダウンが残っており、史上最高値には達していません。おそらく、様々な算出基準（価格、純資産価値、調整後純資産価値、トータルリターン指数など）が混ざってしまっているためで、見た目は似ていても実際は異なります。\n一つ、名前を訂正させてください。あなたが言及された「中国金龍魚指数」は、通常、ナスダック・チャイナ・ゴールデンドラゴン指数のことを指します。英語では Nasdaq Golden Dragon China Index です。「金龍魚」ではありません。\nまず定義を統一する 今回は、価格水準（ポイント）をそのまま使って相関を算出するのではなく、リターンのみを用いて関連性を計算します。価格自体に長期的な傾向があるため、単純に価格で関連性を算出すると、長期間上昇してきたどの資産ペアでも「強く相関している」と誤認しやすいのです。\n対象 私が採用する定義 それに似ているもの 香港恒生テクノロジー指数 (Hang Seng Tech Index) 香港証券取引所が定義する、香港上場の大手テクノロジー企業30社。単一銘柄のウェイト上限は8%。 香港株ハイテクリーダー + オフショア中国成長 ナスダック・チャイニーズ・ドラゴン・インデックス (Nasdaq China Dragon Index) Nasdaqが定義する、米国上場、または登録地や主要事業が中国本土を指す証券の集合。 米国株中の関連銘柄へのリスク選好度 ナスダック総合指数 (Nasdaq Composite Index) 米国株ハイテク成長セクターの広範なリスクファクター。 グローバル米ドルテクノロジー資産へのリスク選好度 香港恒生テック指数とA株の広範なインデックスは、どちらも「中国資産」と呼ばれますが、構成銘柄は大きく異なります。HS Techの2026年4月時点の公式ファクシートによると、上位10銘柄は、基本的にMeituan、SMIC、BYD（比亜迪）、Alibaba、NetEase、Xiaomi、Tencent、JD.com、Baidu、Kuaishouという銘柄群で構成されています。それは銀行、保険、資源、配当株といったセクターの重しを持つものでもありませんし、「中国資産が上がれば必ず上がる」と保証できるわけでもない指数です。\nなぜA株は好調なのに、ハンセンテクノロジーが調整局面なのか この件は、3つの層に分解するのが良いと思います。\n第1層、成分構造が異なる。\n上場指数と滬深300の今回の強さは、金融、基幹製造業、大型株のウェイト銘柄、および一部の高配当資産に恩恵をもたらす傾向があります。恒生科技は別の論理で動いています：インターネットプラットフォーム、半導体、消費電子、スマートカーサプライチェーンです。これらの企業は、バリュエーション、海外流動性、リスク許容度、地政学的なセンチメントにより敏感です。\n第二層では、資金の価格付けが異なります。\nA株市場は、よりローカルな資金、ローカルな政策、そしてローカルのリスク選好度に基づいた結果が多くを占めています。HSTECHも南向き資金の影響を受けますが、本質的にはオフショア（海外）市場のアセットです。オフショア市場は、「規制期待」「米金利」「ADRのリスクプレミアム」「海外ファンドのポジション」により高いウェイトを与えます。A株が「安定成長と大盤（大型銘柄）の比重」を重視する局面にある場合、HSTECHは「以前に上がりすぎたため、\n第3層目、前の上昇は、もともと同じリズムではなかった。\n恒生科技は過去2年間にわたり、数回非常に急激な反発を経験しました。A株よりも上昇するスピードが速い反面、調整局面もより深刻になりがちです。恒指会社が2026年4月付けたファクトシートによると、1年間の年率換算ボラティリティは、恒生テクノロジーが30.80%であるのに対し、恒生指数が14.08%、国営企業指数が12.62%となっています。高ボラティリティ資産は、相場の分岐段階において、まず利益確定が行われやすい傾向があります。\nこの現象を一言で要約すると、A株は「本土の大型資産の修復」に近く、恒生テクノロジーは「オフショア中国成長株の二次的な価格設定」に近いというものです。これらは同じ方向に動きますが、同時に動くわけではありません。\n恒生テクノロジーと中国株の優良銘柄、本当に強い相関があるのか 結論を先に述べます：はい、週間および月次スケールでは非常に強く、日次のスケールでは中〜高程度の相関があります。\n2020年8月17日から2026年5月19日までの共通取引日を抽出し、日次リターン、5日間リターン、20日間リターン、および60日間リターンのそれぞれについてピアソン相関係数を算出しました。その結果は非常に明確です。\nペア比較 1日間リターン相関 5日間リターン相関 20日間リターン相関 60日間リターン相関 香港テック vs ナスダック中国ドラゴン 0.60 0.85 0.90 0.93 ナスダック中国ドラゴン vs ナスダック総合 0.49 0.46 0.35 0.35 香港テック vs ナスダック総合 0.17 0.36 0.31 0.28 この結果はとても面白いです。\nハングリー・テックと中国関連上場銘柄（中概金龍）は、短期から中期において、同じ種類のリスク資産を追う2つの取引所バージョンとして見なすことができます。 中概金龍とナスダックの間には、想像されているほど密接ではありません。これらは相関しているものの、直結しているわけではありません。 ハングリー・テックとナスダックはより弱い関係です。その間には「中国資産独自の（固有の）リスクプレミアム」という層が存在します。 あと、気をつけておきたい詳細な点があります。\n多くの人は、香港株は日中に取引を開始するとき、前夜の米国株に主に連動すると考えています。しかし、恒生テクノロジーの当日の値動きを「前営業日の中国概念優良銘柄群」と照らし合わせた場合、相関性はむしろ低下します。これは、単に「昨晩の米国株から情報をコピーしている」のではなく、中国概念優良銘柄群とともに、同じオフショア・チャイナ・ベータによって牽引されていることを示しています。\n中国株（中概）とNASDAQ、は強い相関があるのか？ 私の判断は：中程度の関連性があり、強い相関とは言えません。\n「すべてアメリカで取引されている」という点だけを見ると、誤った判断を下しがちです。中国概念銘柄（中概金龍）は米国市場に上場していますが、この指数の定義が捉えているのは、アメリカ本土のテック系優良企業群ではなく、中国本土の企業群であることを理解する必要があります。\nそのため、本指数は以下の二種類の要因の影響を受けています。\n一つ目は、ナスダックが代表する米ドルのグロース株に対するリスク選好度です。 もう一つは、中国の政策、監査規制、ADRディスカウント、人民元の見通し、プラットフォーム経済および不動産セクターのリスクです。 これが、2024年度の日次リターン相関において、中国概念黄金ドラゴンとナスダックが約0.22に留まり、2026年には再び約0.59に戻った理由です。これは永続的に安定した米国テクノロジーのベータではなく、「中国資産のベータ」へと段階的に切り替わります。\n「米国株の下落と恒成テクノロジーの急騰」というサイクルは存在しますか はい、そして一度だけではありません。\nしかし、ここで完全に説明すると：恒生ハイテクが米国株から切り離されたのではなく、むしろその期間において、中国資産の再評価力がナスダックの調整を上回ったということです。\n最も典型的なウィンドウを3つ選びました。\n| 観察期間 | ハングリーシン・テック | ナスダック\nしたがって、答えは「ない」ではなく、「あるものの、純粋なグローバルリスク選好のフェーズで発生することは稀である」となります。恒生テクノロジーが米株の下落局面（調整）時に逆行した場合、その背景には通常、中国政策の度合いの変化、バリュエーション（評価額）の修復、オフショアに拠点を置く中国資材のポジション積み増しといった、よりローカルな促進要因が存在します。\nハンセン・テックのこれら複数の大きな周期は、それぞれどのように開始し、どのように終了したか ここでは、10%の反発すべてを新しいサイクルとしてカウントすることは避けており、そうなると記事が市場の速報のようなものになってしまうからです。私は、約30%という閾値を用いたスイング分割法で、2020年8月17日から2026年5月19日までの期間を大規模な段階に分け、その上で重要なサブレベルでの調整（回撤）を個別にマーキングしました。\nサイクル 区間 持続期間 変動率 始動要因 終焉要因 第1波上昇 2020-08-17 → 2021-02-17 184 日間 +54.7% 新指標発表後のハイテクバブル、グローバルな流動性緩和、プラットフォーム大手企業の高景気 バリュエーションの過熱、それに続く反トラスト法、プラットフォーム規制、ドル金利の上昇 第1波大熊市場 2021-02-17 → 2022-10-24 614 日間 -74.4% 規制による再評価、ADRリスク、利上げサイクルがバリュエーションを共同で圧迫 極みに落ちた後、政策的な口調の改善が緩やかになり、ポジションと期待値の両方が低い状態 第1波急反発 2022-10-24 → 2023-01-27 95 日間 +71.8% 再開（reopening）取引 + 政策の回復 + 売られすぎからの買い戻し 期待が先に進みすぎて、ファンダメンタルズが追いつかない 第2波下落 2023-01-27 → 2024-01-31 369 日間 -37.6% 回復が予想に及ばず、不動産による重し、プラットフォーム経済の新たな物語性の欠如 バリュエーションが再び低水準まで圧縮され、市場が新たな触媒を再検索する 第2波大回復 2024-01-31 → 2025-03-18 412 日間 +103.1% 極めて低いバリュエーション + 政策的な期待 + テクノロジー成長スタイルの回帰 上昇が速すぎた後の利益確定、外部からの混乱による変動の増幅 急激な調整 2025-03-18 → 2025-04-07 20 日間 -27.9% 前期の急激な上昇に続く大きな反落 パニックが比較的速く放出される 再度の急騰 2025-04 この表で私が一番注目しているのは、上昇率や下落率ではなく、その 終了方法 です。\n香港恒生テクノロジー（Hang Seng Tech）の急騰（上昇）は、緩やかに完了するというよりも、むしろ以下のような[パターン]となることが多いです。\nバリュエーションの高い水準を長期間維持した。 感情（センチメント）が突如として一致した。 最後に一度の急落で終わった。 下落も直線的な陰線による底打ちではなく、むしろ：\n主要な下落局面は長期にわたる。 その途中に、目立った急反発が数回挟まる。 真の底値を打つ際（本当に落ちきった時）は、通常「政策的な微妙な変化 + ポジションの軽さ/資金不足 + 低いバリュエーション」を伴う。 この種の資産について違和感を覚えやすい点は、まさにここにあります。それはインデックスのように見えますが、実際にはよりボラティリティの高い業界群をまとめたものに近いのです。\n最後の文章 (or 文) 恒生テクノロジーを「香港版ナスカック」と見なすと、誤った判断をしがちです。しかし、これを「香港株における中国のテクノロジー成長ベータ」として捉え直せば、多くの点が明確になります。（あるいは、「多くがスムーズに見えます」）\nA株が強いからといって、ハンセンテック指数も同時に強くなるとは限りません。\nハンセンテックと中国概念株（中概）の間には強い相関がありますが、ナスダックとの関連性は中程度に過ぎません。\n米国株が下落する際、ハンセンテック指数が確かに大きく上昇することはありますが、それは要因が「グローバルなテクノロジーリスク選好」から、「中国資産による自己評価/再評価」へと切り替わったことを示していることが多いです。\nしたがって、この市場の動きは、一つの方向にだけ目を向けるべきではありません。まずは、それがあらゆるトレンドや勢いのうち、一体どこに沿っているのかを見る必要があります。\n参考資料 Hang Seng Indexes, Hang Seng TECH Index Factsheet, April 2026 Nasdaq, Nasdaq Golden Dragon China Index Methodology FRED, NASDAQ Golden Dragon China Index FRED, NASDAQ Composite Index 中証指数有限公司, CSI 300 Factsheet, 2026-03-31 Sina Finance, 恒生科技指数页面 ライティングノート 元のプロンプト A株 上証指数は最近かなり上昇しましたが、一度調整し、4200付近で上下動しています。しかし、滬深300 ETFはすでに歴史的なピークに近づいています。同じ時期に恒生科技指数が下落している理由を調査してください。恒生科技指数は、米国株の中国金龍魚指数と強い相関関係がありますか？中国金龍魚指数はナスダック指数と強い相関関係がありますか？米国株が下落する際に、恒生科技指数が急騰した周期は存在しますか？また、恒生科技指数の過去のサイクルの持続期間や、いかに始まり、いかに終焉を迎えたのかを分析してください。\n執筆構想の要約 「金龍魚指数 アイデアの拡張・深化 ","date":"2026-05-20","language":"ja","permalink":"https://ttf248.life/ja/p/why-hang-seng-tech-lags-a-shares/","tags":["AI霊感衝突坊","恒生指数 (こうせいしじょ)","ニューヨーク証券取引所（NYSE）/ 株式市場","恆生テクノロジー指数 (こうせい テクノロジー しすい)","中国株 (または、中国企業関連の株式)"],"title":"恒生テクノロジーがなぜA株の上昇に追随しなかったのか","year":"2026"},{"categories":["コンピューター"],"content":"まず、時期を明確にしましょう。ChatGPTの公開研究プレビュー版は、2023年ではなく、2022年11月30日にリリースされました。[1]\nこの時期以降、NVIDIAのデータセンターGPUのメインラインは非常に明確です。Ampereが終息し、Hopperに引き継がれ、Hopperは大容量メモリを刷新し、そしてBlackwellが重心を「単一カードでの高密度計算能力」から、「推論スループット、消費電力、システム全体レベルの相互接続性」へと移していくという流れです。対照的に、中国向け特別仕様ラインは別の物語があります。A800、H800、H20といったものは、本質的には米国の輸出規制の制約の下で作られた\n本稿では、2本の線のみを統計しています。\nグローバルデータセンター向けのトレーニング／推論メインライン：比較基準としてA100、H100、H200、B200、B300。 中国向け特別供給ライン：A800、H800、H20。 L4、L40、L40S、L2といったものは本文に組み込んでいません。それらが重要でないわけではなく、むしろこれらはビデオ推論、一般推論、グラフィックス、仮想化という用途ラインがメインであり、A100/H100/H200/B200のような大規模モデルトレーニングの主軸と混ざってしまうと、価格や性能の指標が混乱してしまうからです。\nまずメインラインを見る 結論から述べます。2022年11月30日以降の発表ペースで見ると、H100が生成AI爆発初期の真の起点となり、H200は「メモリ不足」を補うための刷新的なカードであり、B200こそが真の意味でのプラットフォームレベルの世代交代であり、B300はBlackwellを推論（Inference）および思考（Reasoning）の時代へとさらに押し進めたと言えます。\nモデル名 リリース日 アーキテクチャ メモリ容量 メモリ帯域幅 インターコネクト 公式性能指標 A100 80GB 2020-11、対照ベースラインとして Ampere 80GB HBM2e 2.039 TB/s NVLink 600 GB/s BF16/FP16 Tensor Core 312 TFLOPS，INT8 624 TOPS [2] H100 SXM 2022-03-22 Hopper 80GB HBM3 3.35 TB/s NVLink 900 GB/s BF16/FP16 1,979 TFLOPS，FP8 3,958 TFLOPS；DGX H100 シングルシステムで 32 PFLOPS FP8、DGX A100 から 6 倍向上 [3][4] H200 SXM 2023-11-13 Hopper 改良版 141GB HBM3e 4.8 TB/s NVLink 900 GB/s 公式が強調しているのはコア演算能力の倍増ではなく、Llama2 70B 推論で 1.9 倍、GPT-3 175B 推論で 1.6 倍の向上；H100 に対する相対的なメリットはより大 ここで最も誤解しやすい点は、H200が「演算能力を暴力的に倍にしたカード」ではないということです。むしろHopper世代のための補習（キャッチアップ）のようなものです。大規模モデルの訓練と推論が超長コンテキスト、巨大なKVキャッシュ、MoE、そしてより大きなバッチサイズという段階に入ると、ボトルネックはもはや単純なBF16のピーク性能ではなく、VRAM容量とVRAM帯域幅になるからです。H200はこの弱点を補完しました。\n真の世代的な飛躍はBlackwellにあります。Blackwellが売っているのは単なる単体のカードではなく、一連のプラットフォーム能力：新しい精度、インターコネクト、システム全体レベルの帯域幅、推論コスト、消費電力効率、ラックスケールでの組織方式といったもの全般です。これが、多くの資料がB200について語る際に、単体カードの指標がH100ほど一目で理解しにくい理由であり、なぜならNVIDIAのナラティブ（物語上の焦点）が、「この\n中国限定ラインを再確認 中国専用ラインは個別に検討する必要があります。なぜなら、その目的が世界のフラッグシップ製品を打ち破ることではなく、輸出規制のレッドラインを下回りながら、商用利用可能性を可能な限り保持することにあるからです。\nこのラインで最も覚えておくべき一文は、「A800とH800は『相互接続を減らす』ものであり、H20は『計算能力すらも抑え込まなければならない』ものである」ということです。\nそのため、誰かが単にVRAMの数字だけを見て、「H20はH800より新しいから、もっと高性能だ」と判断するのは誤りです。H20の96GB HBM3と4.0 TB/sの帯域幅は悪くありませんが、それが登場する前提条件は、より厳しい輸出規制を満たすことです。その商業的な目的は、まず「売れること」、次に「可能な限り使いこなせること」なのです。\n前世代と比較して、具体的にどれだけアップグレードされたのか 計算方法から説明します：\n\\[ \\text{アップグレード率}=\\frac{\\text{次世代指標}-\\text{前世代指標}}{\\text{前世代指標}} \\] ただし、この数式は定義（スコープ）が統一された指標にのみ適しています。メモリ（VRAM）、メモリ帯域幅、NVLinkの帯域幅は直接計算が可能です。一方で、プラットフォームレベルの推論コストやシステム全体の処理能力（スループット）といった要素は、シングルカードのTFLOPSのような単一基準には無理に当てはめることはできません。\n世界の主要動向 読み進めていくと、ある法則があることに気がつきます。\nH100は、単一カードのテンソル演算能力を飛躍的に引き上げた世代です。 H200は、VRAM（ビデオメモリ）を補強した世代です。 B200は、「トレーニング用カード」を「AIファクトリーのインフラストラクチャ」へと変貌させた世代です。 B300は、Blackwellをより明確に推論および大規模な推論の領域へ押し進めた世代です。 中国特別供給ライン 世代 直感的印象はアップグレードに見えるが、実際には分けて考える必要がある 私の考察 A800 -\u0026gt; H800 ローカルHBM帯域幅だけを見ると、A100からH100レベルまでは、約+64%の世代的な進歩と理解できる しかし、根幹となる制約は依然としてインターコネクト それゆえに、「各世代でどれだけ総合的に向上するか」という形で記述するのは、中国の特注ラインには適さないのです。このラインは元来コンプライアンス上の制約を伴っており、設計目標が技術的な最適さではなく、ルールによる制約の下での商業的な実現可能性にあるからです。\n販売価格は一体どれくらい上がったのか この部分は誤った情報が書き込まれやすい箇所です。NVIDIAはデータセンターGPUの単体MSRPをほとんど公開していないため、一般的に利用できる情報は以下の通りです：\nDGXシステムの価格、またはサードパーティによるシステムの実売価格（提示価格）。 中国向け特別仕様カードのチャネルからの見積もり価格。 メディア、証券会社、またはサプライチェーンからの情報。 そのため、ここでは「公開で追跡可能な価格サンプル」のみを提供し、一見すると完璧だが実際には算出基準が混乱した公式の価格表を偽造することはしません。\nデバイス 公開価格サンプル 前世代との比較の解釈 DGX H100 2022-03-22 发布時官方起售价 1 したがって、「全体の販売価格はどの程度上がったのか」という点で、2つの結論をご報告します。\n第一に、世界のフラッグシップ主力製品は確かに上昇しており、その上昇幅もさほど小さいものではありません。公開で比較可能なサンプルを見る限り、DGX B200は、同時期にリストされているDGX H100と比較して、およそ40％から50％高価になっています。[19]\n第二に、中国の特別供給ラインは一律に価格が上昇しているわけではなく、「後から出るカードの方が安価」という状況が発生する可能性があります。H20の8枚カードサーバーの公開見積もりは、H800の8枚カードサーバーよりも約30%低い水準ですが、これは良心の問題ではなく、性能能力がさらに圧縮されたためです。[17]\nまとめ ChatGPTが公開された以降のNVIDIAデータセンター用GPUの変化を一言にまとめると、私の判断は〜です。\nH100 は生成AIが爆発した時点でのスタートの引き金であり、H200 はメモリ志向の延命措置です。B200 こそが AI ファクトリー時代における真のプラットフォーム世代交代であり、B300 は推論（reasoning）時代に向けて明確に道筋をつけ始めています。中国向け特別供給ラインは全く別のロジックに基づいています。それはフラッグシップを追いかけるのではなく、ルールの隙間で可能な限り利用可能性を維持することを目指しているのです。\nこの2つの要素は混同しないでください。混ぜて見ると、「新しいカードのVRAMが大きいから、世代がより優れている」「価格が低いから、コストパフォーマンスが高い」といった、大きな差はないものの、方向性自体を間違えた結論を導き出しやすいです。\n参考資料 執筆注記 元のプロンプト ChatGPTのリリース以降、Nvidiaが発表したGPUモデルとそれに対応する性能パラメーターをまとめてください。前世代と比較してどれくらいアップグレードされたか、また全体的な価格はどの程度上昇しているかを知りたいです。データセンターで使用されるGPUが必要で、中国向けの特別版も含めてください。\nライティング（執筆）の構成案要約 拡張ブレーンストーミング | 方向 | 正文への採用可否 | 対応理由 | | \u0026mdash; |\n","date":"2026-05-15","language":"ja","permalink":"https://ttf248.life/ja/p/nvidia-data-center-gpu-since-chatgpt/","tags":["AI霊感衝突坊","ai","NVIDIA","データセンター向けGPU","中国限定版"],"title":"ChatGPTが公開された後、NVIDIAのデータセンター向けGPUはどのように進化するでしょうか？","year":"2026"},{"categories":["魚の7秒間の見聞"],"content":"今回の会談は、米中関係が突如「温暖化」したわけでも、誰かが完全に相手を凌駕したわけでもありません。むしろ、高圧的な環境下での強制的な調整（キャリブレーション）のようなものです。\n表面だけを見ると、歓迎式典や国\n言い換えれば、今回の北京での会談はまず「暴走の防止」が目的であり、次に「取引を行うこと」が目的だということです。\n最初に、前提となる範囲を明確にします。本記事は、2026年5月14日午前までに公開された情報に基づいてまとめられています。今回の訪問（または：この会合）はまだ進行中であるため、ここでは経緯や既報のスケジュール、および外部の予想について記述するものであり、未だ発生していない結果を確定事項として記述するものではありません。\nまず、今回の会談について整理しておきましょう この会談は、ドナルド・トランプ米大統領が2026年5月13日〜15日に中国を国事訪問するものです。中国外交部によると、これは「約9年ぶりのアメリカ大統領による訪中」であり、またトランプ氏にとって2017年11月以降の2度目の大統領としての訪中となります。\n公開情報からすると、今回のアクセス（または「訪問」）には最低でも3つのレベル/層があります。\n階層 確認された内容 これは何を意味するか 首脳レベル 習近平とトランプが北京で対面会談したこと 最高層が直接方向性を定め、最優先の課題は二国間関係がさらなる漂流をするのを防ぐことである。 経済貿易レベル 何立峰とベセンテが韓国で事前に協議を済ませたこと 話題となっているのは単なる儀礼的な事項にとどまらず、具体的な取引や交換条件であることを示している。 対外レベル 世界はイラン、台湾、技術規制、農産物、およびボーイングの注文に高い関心を示している 会談の重要性はすでに二国間を超え、グローバル市場や地政学的な波及効果を伴っている。 したがって、これは単なる形式的な訪問ではありません。明確な議題（アジェンダ）を抱え込みつつも、品格のある雰囲気を維持することが必須となるような、ハイレベルな会合なのです。\n経緯は実際には突然ではありませんでした 「5月13日にトランプ氏が北京に到着した」という事実だけを見ると、今回の会談は非常に早く訪れたと感じるかもしれません。しかし実際には、以前から何周にもわたって布石が打たれていたのです。\n第1の導入部：2025年10月釜山会談が目指す「一時的な停滞」 中国外交部と商務部は、今回「釜山会晤」という単語を繰り返し言及しています。\nこれは非常に重要です。なぜなら、北京が今回行った多くの公開声明が、「釜山会談および過去の通話で得られた重要な合意事項を実行すること」を前提条件として扱っているからです。外資系メディアは同時に報じており、昨年10月の釜山での会合の後、両者は一連の経済貿易上の休戦協定を形成しました。米国側は中国商品に対する3桁レベルの関税引き上げを一時停止し、一方、中国側もレアアースの供給制限をこれ以上激しくすることはしませんでした。\n私の判断では、釜山での会談は問題を解決したというよりは、最も危険なエスカレーションの引き金（ボタン）を一時的に遠ざけたものだと考えます。今回の北京での面会は、本質的にはこの臨時の停戦メカニズムが今後も維持できるのかどうかを確認するものだったと言えます。\n第2部への布石：「2026年2月4日」の首脳会談で、今年のアジェンダを先に掲げる 2026年2月4日、習近平（しゅうきんぺい）はトランプ氏と電話で会談した。中国側が出した通稿には、注目すべき点を2点挙げている。\nまず、両者が昨年円滑なコミュニケーションを築いたことや、釜山での会談が「米中関係の方向と航路を示した」と明確に言及している点。これは北京側の論調が一貫しており、具体的な取引を先に強調するのではなく、まず首脳による舵取り（指導）を強調していることを示唆しています。\n第二に、通話の中で、両国それぞれの重要な日程として「2026年」を直接取り上げた。これには、中国による「第15次五ヵ年計画」の始動、中国がAPECを主催すること、米国がG20を主催することといった内容が含まれる。この発言の潜在的なメッセージは明白である。すなわち、両国とも今年は関係を制御不能な状態にすることは適切ではないということだ。\n第3部での布石：5月12日から13日の韓国の経済貿易協議が、北京での会談の下地となる 今回の会談が、単なる象徴的な意味合いにとどまらず、事前に（行う）韓国との協議であったことを物語っています。\n5月10日、中国商務部によると、何立峰氏は5月12日から13日にかけて韓国へ渡り、アメリカ側と経済貿易協議（経貿磋商）を行うと発表し、これを「両国首脳の釜山会談およびこれまでの通話における重要な共通認識に導かれる」ものだと明確に述べました。そして5月13日には、新華社が非常に定型的でありながら情報量の少ないまとめとして、「両者は率直で、深く、建設的な交流を行った」と報じました。\nこのような記述は通常、双方が交渉決裂したというわけではないものの、大成果を事前に発表できるレベルにも達していないことを意味します。むしろ、首脳会談の前にクリアしなければならない技術的な障害を、あらかじめ一通り片付けているようなものです。\n第四章の布石：中国訪問のタイミング自体が、表面以上の緊迫した状況を示唆している 海外メディアの報道によると、今回の訪中は本来もっと早く予定されていたが、後にイラン情勢を理由に「5月14日から15日」に延期されたとのことである。つまり、この北京会談は安定した国際的な環境下で行われたものではなく、中東の戦火、世界的な原油輸送リスク、アメリカ国内のインフレと選挙圧力が複合的に重なった後に、改めてスケジュールが再調整されたものだ。\nこの点は重要です。これは、今回の会談において、イラン問題が米中間の経済貿易問題や台湾問題と並び、主要な公的議題として取り上げられる理由を説明しています。\nスケジュールの公開状況について 2026年5月14日午前時点での公開行程は、概ね以下のように整理できます。\n日付 予定される行事 情報源 5月13日 夜 トランプ氏が北京に到着し、韓正氏が空港で出迎える 新華社 5月14日 午前 習近平氏が人民大会堂東門外広場で歓迎式典を開催 新華社速報 5月14日 昼間 両者が人民大会堂で会談 ロイター通信（ホワイトハウスの予定を引用） 5月14日 ここには注目すべき2つのポイント（詳細）があります。\nまず、天壇は適当に選ばれた観光地ではありません。外資メディアによると、天壇は中国古代の皇帝による豊作を祈る儀式に対応しており、象徴的な意味が非常に強いそうです。北京にとって、この配置は、外交上の配慮であると同時に、物語の設計でもあります。\n第二に、5 月 15 日 にはお茶会と業務ランチが設けられている。これは、今回の会談が単なる「顔合わせ、記念撮影をしてお互い別々の場所に戻る」といった場ではなく、双方に引き続き細部を磨き上げるための時間を与えられたことを示している。\n国内の見方：まずは安定化を図り、その後に相違点を議論するが、レッドラインは譲らない 国内における一般的な見解は、実を言うと複雑ではありません。\n公式見解で最も核となる二つの言葉は、「安定性」と「確実性」です。外交部が5月11日に行った記者会見においても、また新華社による5月12日の論評においても、首脳外交の中米関係における戦略的な指導的役割を強調しており、世界情勢が不安定な中で、中米はグローバルにさらなる安定した期待を提供する必要があることを主張しています。\nしかし、これは一方的な好意ではありません。中国の記述にはもう一つの非常に強い一線があります。「協力は話し合えるが、原則を取引の道具にすることはできない」というものです。特に台湾問題については、米中関係において「最も重要な課題」の位置に明確に置かれています。新華社の論説はさらには、「一つの中国原則」と米中の3つの共同声明を再び政治的な基盤上の位置に戻しました。その意図は非常に明白で、協力の議論は歓迎するが、北京（中国）が核心利益に関して曖昧な扱いをすることは期待しない、というのです。\n国内の世論を社会的なレベルに引き上げると、感情も非常に現実的です。ロイターが取材した北京の回答者は、トランプ氏の真意に疑問を持ちつつも、「良い政策が出てくるといい」と願っています。このような反応は典型的であり、情熱的な楽観論というよりも、単に事態が混乱するのをやめてほしいという願いなのです。\n私の理解では、中国国内の多くの視点からは、今回の会談を「中米関係が全面的に改善する」ための起点としてではなく、単なる必要不可欠な損切り行動（危機管理的な動き）として捉えられています。ただ安定させることができれば、それはすでに有効と見なされますが、もし経済貿易面での実務的かつ具体的な進展を引き出せれば、それはプラス評価となるでしょう。\n海外からの視点：華やかなイベントになるが、ブレークスルー（飛躍的成果）は小さめと見られるものの、双方とも今回の面談を避けられない 海外の見解はより分断的ですが、主な筋道は非常に明確です。\nある種の見方：儀式感が非常に強くなるが、実質的な突破は限定的である APの判断は非常に明確で、今回の会談は「規模が大きい」と思われるが、貿易、台湾、イランといった核心的な問題については、決定的な進展はないだろう。\nこれは容易に理解できます。なぜなら、現在話し合えるのは、ほとんどがリスク管理、休戦期間の延長、限定的な利益の交換にとどまっています。真に最も難しい構造的対立――例えば、ハイテク制限や台湾への武器販売、サプライチェーンの安全保障など――については、誰も安易に大きな取引ができる立場まで譲歩していないからです。\nある視点：トランプにとって、今回の会談は2017年よりも必要性が高い ロイターの分析はより辛辣だ。その判断は、今回の力の均衡は『2017年』とは異なっているということだ。当時、中国はハイレベルな接待と買い付けでトランプを落ち着かせようとしたが、今回はむしろアメリカ側が、対抗相手であり取引先である中国を避けて通れないことを自主的に認めているように見える。\nこの変化の裏にある原因も、難しく見ることはありません。\nトランプ氏は、特に農業、ボーイング、エネルギーなど、政治的な実績として素早く結びつけられる経済・貿易面での成果を必要としている。 イラン戦争は彼の支持率を押し下げただけでなく、米国国内のインフレと中間選挙の圧力を高めている。 今回のアメリカ企業の視察団は人数が多いが、その要望は非常に具体的である。単に大きな言葉を聞きに来たのではなく、市場参入障壁の撤廃、承認プロセス（規制）の緩和、サプライチェーンの回復、そして規制緩和を勝ち取りに来ている。 つまり、ホワイトハウスが今回北京を訪問したのは、単に戦略的な姿勢を見せるためだけでなく、現実的な利益も求めているからだ。\nさらに一段より冷静な判断：双方とも事態を失速させたくない これが私にとって最も賛成する点です。\n中国と米国が現在対立がないわけではなく、むしろ矛盾や問題が多すぎるため、最高レベルでのコミュニケーションを維持することが必須です。なぜなら、万が一首脳間の対話が途絶えると、経済・貿易、台湾、科学技術、地域安全保障といった複数の議題が相互に波及しあい、最終的には誰も事態の収拾がつかなくなる可能性があるからです。\nしたがって、今回の会談で真に重要となるのは、どれだけ多くの契約を締結するかということではなく、双方に紛争エリア（対立する領域）を管理し、すぐに解決できない問題を先に隔離できる能力があるかどうかという点です。\nこの面会（または会談）を促したのは、いったい何だったのでしょうか あえて一言でまとめると、「今回の出会いを促したのは、共通の好意ではなく、共通のプレッシャー（あるいは、共通の課題）だった」ということになります。\nより具体的に言うと、4つの力が同時に作用しているということだ。\n1. 釜山の後の休戦は、延長が必要である 昨年10月の釜山会談後、両者は少なくとも経済貿易関係がさらなる失控に陥るのを一時的に回避しました。この一時的な均衡は本来脆く、協議を継続しなければ再び悪化する可能性があったのです。北京での会談は、まずこの「停戦」状態（または「安定した状況」）を維持するためのものでした。\n2. 双方それぞれ具体的な取引について話し合う必要がある 米国側が真剣に協議したい議題は、農産物、ボーイング、エネルギー輸出、中国での米企業による市場参入（准入）、および半導体・AI企業が直面している規制上の問題です。\n中国側から同様に議論したい現実的な課題は、チップ、装置、先端半導体に対する制限の緩和、技術的封鎖（または「技術規制」）の緩和、そして経済貿易協力がより予測可能な軌道に戻ることです。\nこれは価値観の対話ではなく、条件の交換です。\n3. イラン・イラク戦争が、米中関係をあらためて同一の舞台に引き戻した イラン問題は、米中関係に付属する単なる議題ではなく、今回の会談においては、ほとんど外部から押し付けられる（あるいは「引き起こされる」）変数の域に至りました。米国は、中国に対し、エネルギーおよび地域の関係における独自の影響力を利用し、情勢の緩和に貢献することを期待しています。一方、中国側は、世界のエネルギー・海運リスクが引き続き制御不能となり、それがわが国の貿易や世界経済にさらなる打撃を与えることを懸念しています。\n双方の立場は異なるものの、どちらも事態がさらに悪化することだけは避けたいと考えている。これだけでも、面会するための動機付けとなるだろう。\n4. 両方に比較的安定した 2026 が必要です 中国側は、「第十五五期」（「15年五ヶ年計画」）の立ち上げに加え、APEC（アジア太平洋経済協力）の開催という重責を担っています。一方、米国側は、独自に掲げる『250周年』という物語（ナラティブ）を持っているものの、G20や中間選挙といったプレッシャーも抱えています。両者ともに強硬な姿勢を示す能力を備えていますが、決定的に不足しているのは「予測可能性のある外部環境」であると言えます。\nしたがって、今回の会談の実質的な意味は、誰が誰を説得するかという点にあるのではなく、両者が「今話さないとコストが高くなる」ということに気づいた点にあります。\n私の判断 今回の北京での会談は、米中関係を「新時代」へと導く可能性は低いでしょう。むしろもたらされるのは、限定的ではあるものの重要な結果であり、両者が今後も競争を続けることを確認するが、その範囲内（レールから逸脱しないこと）という点に留まるでしょう。\nロマンチックとは言えませんが、現在の米中関係においては、既にかなり現実的な側面がありますね。\n今後の真の成果が出た場合、最初に具体化するのは、大規模な叙事詩のようなものではなく、いくつかの実務的な内容になる可能性が高い。すなわち、経済貿易の休戦を継続し、少量の調達や承認のシグナルを発信することで企業界に外部報告可能な進展を与えつつ、イランと台湾の問題に関しては、完全に立場を決める前にある程度の柔軟な余地を残すというものだ。\nより根深い競争、特にハイテクノロジー、サプライチェーン、安全保障といった問題が今回の会談によって消え去るわけではない。単に一時的に、よりコントロールされたペースの中に収まっているだけだ。\nどう言えばいいか分かりませんが、今回の会談は、中米がすでに相互に信頼し合っていることを証明するためというよりは、むしろ、お互いに不信感があるという前提のもとで、両者が今後も関係を継続できる能力を持っているかどうかを示す場なのではないでしょうか。\nこれが真の重みです。\n参考文献 執筆上の注記 元のプロンプト 中米が最近会談を行った件について、関連する経緯（来龍去脈）や行程を整理してください。また、国内外から見た今回の会談の評価や、会談の主な推進要因は何だったのかについてもまとめてください。\n執筆構想の要約 ブレインストーミングの拡張 | 方向 | 本文への組み込みの要否 | 理由 | |\n","date":"2026-05-14","language":"ja","permalink":"https://ttf248.life/ja/p/trump-second-china-visit-2026/","tags":["日中関係","トランプ","国際政治","地政学","AI霊感衝突坊"],"title":"トランプが再び中国を訪問：今回の米中首脳会談は、まず安定を図り、次に取引について話す場に","year":"2026"},{"categories":["金融知識データベース","投資 (tōshi)"],"content":"前回の記事 この半導体サイクル、終点は多分 2026 年ではない では、まず判断を提示しましたが、あえて決算書の詳細な項目まで深く掘り下げてはいませんでした。\n今回補うのは、市場のセンチメントによって最も覆されがちな部分です。半導体が上昇するときは、誰もが利益を上げられると知っています。しかし、サイクルがどれだけ長く持続するか、どの企業が高い成長期（ハイサイクルの景気）における収益をより確実なものにできるかを真に決定するのは、往々にして株価ではなく、低迷期の損益計算書、設備投資額、そして製品への投資の方向性なのです。\nより具体的な判断を一つ挙げるとすれば、2026年5月13日現在も、この好景気の終点を2026年に置くつもりはありません。しかし、いくつかの巨大企業の中から最も注目すべき銘柄を選ぶとしたら、私はまずSK hynixに目を向けます。それは、不況を経験しなかったからではありません。むしろ正反対の理由からです。それは、2023年に最も厳しい時期にあった際、最も象徴的な選択をしたからです。\nまず基準（定義）を一貫させる必要があります。そうしないと、この表が誤った解釈や混乱を招く可能性があります。 この記事では、SK hynix、Micron、TSMCの3社のみを取り上げます。\n理由は簡単です：\nSK hynix：今回のAIメモリの最も直接的な恩恵を受ける企業であり、本記事で重点的に補足すべきデータ対象です。 Micron：米株の中で最もクリーンなストレージ指標（β）であり、SKハイニックスと比較して見ることができます。 TSMC：メモリ会社ではありませんが、それゆえに比較対照群として最適です。 2つの観点から、まずご説明します。\nSK hynix、TSMC は主にカレンダーイヤー（自然年）に基づいて見てください。 Micron は会計年度に基づいており、FY2025 は2025年8月28日時点のものです。 したがって、これらの表は、同一企業における期間をまたいだ変化を見るのに適しており、異なる企業を強引に比較して横断的な評価（バリュエーション）を行うのには適していません。\n2度の下落サイクルと調整を経て、メモリー分野の業績（決算）のボラティリティは非常に大きい この表を最後まで見ていただくと、まず基本的な（あるいは第一段階の）結論が明らかになります：\n半導体はサイクルではない、少なくともmemoryとロジックファウンドリが同じ強度ではありません。\n2019年、世界の半導体業界は下落傾向にありましたが、TSMCの売上高は依然として業界の流れに逆行する成長を遂げ、利益率も落ち込みませんでした。対照的に、SKハイニックスやMicronは、ストレージ価格サイクルの反転に直面した場合、売上高が失速するよりも先に営業利益が減少し、その落ち込み幅はより大きい傾向があります。\nこれが、前回の記事で私が一貫して強調してきた理由でもあります。米国株のストレージ（メモリ）と韓国半導体は、「一般的な半導体株」としてだけ見てはいけないということです。これらは景気の良い局面ではより強い動きをし、調整局面においてもより大きな動きをします。\n本当に補うべきは、海力士の「逆周期」がどこで逆なのかということ 結果だけを見ると、SKハイニックスの2024年と2025年の決算報告書は、まるで「お金を刷っている」ように見えますね。\n年度 売上高 営業利益 営業利益率 2023 32.766兆ウォン -7.73兆ウォン -23.6% 2024 66.193兆ウォン 23.4673兆ウォン 35.5% 2025 97.1467兆ウォン 47.2063兆ウォン 48.6% 2023年から2025年にかけてのこれは、単なる回復（立て直し）ではありません。深刻な赤字から、約50%の営業利益率への大きな転換なのです。\nしかし、「逆周期の生産能力拡大」という表現をあまりに大雑把に話してしまうと、重要なポイントを見落としてしまいます。\nより正確な言い方としては：\n\\[ \\text{海力士の逆周期} \\neq \\text{全線大規模増産} \\]\\[ \\text{海力士の逆サイクル} = \\text{総投資の縮小} + \\text{HBM/DDR5/LPDDR5 の停滞} \\]つまり、2023年に全ての製品ラインを均等に維持したわけではなく、むしろ最も困難な時期に、次期で最も収益性の高い数少ないライン（製品群）に資金を優先的に配分していたということなのです。\nこの違いは非常に大きい。\n2023年に出た度重なる発言で、SKハイニクスの戦略（打法）の全貌が解明された 公式の定義を時系列に沿って並べると、より明確になります。\nしたがって、「SKハイニックスの景気循環に逆らう増産」という件を覚えているなら、その記憶の方向性は間違いではありません。ただし、限定する言葉を一つ加える必要があります。それは選択的な景気循環に逆らった増産であり、全面的な無謀な拡大ではなかったということです。\nこれも、それが最も風向標のように思える理由です。\nこのメモリサイクルがさらに引き延ばせるかどうかを真に決定するのは、「皆が生産能力を拡大しているかどうか」ではなく、低迷期にHBM、DDR5、先進パッケージング、そして高付加価値なサーバーストレージのポジション（需要）を誰が最初に確保したかだ。\nMicronとTSMCを並べて比較すると、SKハイニックスの特徴がより明確になります マイクロンは、実際には似たようなことを行った経緯があります。\nこれは何を意味しますか？\nMicronがAIメモリーの次の需要フェーズに向けても準備を進めていること、また設備投資（CapEx）が明確に再び上昇に転じていることが示されています。\nしかし、SKハイニックスの特徴はより際立っています。同社は2023年の下落が最も深かった局面において、既に数回にわたりHBMやDDR5を投資優先事項として取り入れているからです。マイクロンは、景気回復が確認された後に需要に合わせて追加的に投資を拡大していくような印象です。一方、SKハイニックスは、最も厳しい決算報告の段階で、次の主要な成長分野（メインストリーム）を先んじて確保したようにも見えます。\nTSMCを再度見てみると、以前とは全く異なる印象を受けます。\n2019年の世界の半導体業界はすでに減速傾向にありましたが、TSMCは「7nm」の需要がより強いため、同年の設備投資を149億ドルまで引き上げました。そして2023年に入ると、業界が在庫消化を進めているにもかかわらず、売上高はわずか4.5%の減少にとどまり、営業利益も17.8%の下落に抑えられました。その後、2024年には、売上高が2.8943兆新台湾ドル、営業利益が1.3221兆新台湾ドルまで急回復しました。\nこれは、常識に反しますが、非常に重要な事実を示しています：\n「半導体巨大企業」のこの四文字の下には、全く異なる2種類の財務構造が備わっています。\nmemoryのリーダー株は、高レバレッジな景気循環型資産のような性質を持つ。価格が順調に動くと利益が爆発する一方、価格が逆行すると利益がまず急激に悪化する傾向がある。 logic / foundryのリーダー株は、堀（モート）を持った産業プラットフォームに近い側面を持っている。景気循環という側面はあるものの、memoryほど「ASP」一つで覆されやすいものではない。 したがって、今回のサイクルのうち「景気循環に乗って利益を拡大しやすい（恩恵を受けやすい）企業」を狙いたいのであれば、SKハイニックスとMicronは当然ながらTSMCよりも敏感な指標となります。\nしかし、「リスクが選択的な設備増強から業界全体での設備増強へと移行するタイミング」を知りたいのであれば、TSMCの大規模な設備投資（CapEx）、先進パッケージング、そして顧客構造こそが、別の種類の先行シグナルとなるでしょう。\nこれらの財務データが、前回の分析（または判断）を完璧に補完しています 前回の記事では、この半導体サイクルが2026年までに終わらない可能性が高いと述べました。\n財務データを補完した後、より論理的になりました。\nまず、2023年の底が深すぎました。\nSK hynixとMicronの両社とも、利益表が大きく下落する局面を経験しました。このように深い落ち込み（深坑）を経た場合、その後、価格や製品構造が回復した際、利益の回復は「線形」というよりも「跳躍的」になりやすい傾向があります。\n第二に、SKハイニックスのような企業は、好景気のサイクルが2024年から始まったのではなく、むしろ2023年の最も厳しい時期からポジションを築き始めたことを証明しています。\nこれは、2026年に見込まれる高収益が、単なる在庫回復の終焉ではなく、これまでの選択的な逆周期投資による「回収段階（ペイオフ）」であることを意味します。この実現期がまだ終わっていない限り、サイクルが急激に終了することは少ないでしょう。\n3つ目、真に危険なのは、Hynixが2023年に「HBM」ラインを確保したことではなく、2025年から2026年にかけて、多くの企業がこの選択的な投資を大規模な投資にしてしまうかどうかです。\n市場が「ハイエンドメモリの先行的な拡大」から「全ての人々が上向きに（全体的に）拡大する」フェーズへと移行すれば、私が前回の記事で述べた危険なウィンドウは、ますます近づいてくるでしょう。\n後で本当に注目するなら、私はこれだけのことに注目するだけだ つまり、多くの人は半導体の周期に注目しており、まず株価を見て、次にニュースを読み、最後にようやく決算書を確認するという習慣があります。\nしかし、今回は本当に時間窓を正確に見極めたいなら、順番を逆にした方が良いでしょう。\nまず、決算書における利益と製品構造がどのように変化しているかを確認し、次にcapexがどの分野に投資されているかを見てから、最後に株価が2〜3年分の好調な時期をすべて織り込みすぎていないかをチェックする。\nSK hynixを単体で取り上げる価値があるのは、それが常に景気循環による落ち込みから免れるという点ではなく、2023年の最も酷かったメモリー市場の低迷局面において、非常に標準的な解答を示したからです。\n総投資額は減らすことができるが、次期において最も利益を生み出す数本の柱（ライン）は止めるわけにはいかない。\nこの文章は、「半導体景気の継続」といった壮大な物語よりも、むしろ役立つかもしれません。\n参考文献 SK hynix Inc.が2018年度および第4四半期の業績を発表 SK hynix Inc.が2019年度および第4四半期の業績を発表 SK hynixが2022年度および第4四半期の財務実績を報告 SK hynixが2023年第1四半期の財務実績を報告 SK hynixが2023年第2四半期の財務実績を報告 SK hynixが2023年第3四半期の財務実績を報告 SK hynixが2023年第4四半期の財務実績を報告 ファクトシート - SK hynix SK hynixが24年度第4四半期の財務結果を発表 SK hynixが25年度の財務結果を発表 Micron Technology, Inc.が2018会計年度第4四半期および通期の業績を報告 Micron Technology, Inc.が2019会計年度第4四半期および通期の業績を報告 Micron Technology, Inc.が2022会計年度第4四半期および通期の業績を報告 [Micron Technology, Inc.が2023会計年度第4四半期および通期の業績を報告](https://investors.micron.com/news-releases/news-release-details/micron-technology-inc-reports-results ライティング注記 元のプロンプト 以前の記事では、この半導体サイクルの終点は2026年ではない可能性が高いと述べられていますが、詳細な財務データがありません。新しい記事を作成し、いくつかの有名な半導体大手について、複数回の半導体サイクルにおける財務データを補完したいと思います。特にSKハイニックス（海力士）についてです。以前ニュースで、逆周期に能力を拡大しているという報道を見たのを覚えています。\nライティングの指針（または：執筆の方向性）要約 本稿は前回の記事で述べたサイクルに関する結論を繰り返すのではなく、決算報告書（財報）、利益率、および設備投資という層を追加するに留める。 本文ではメモリとロジック／ファウンドリを意図的に同じテーブルに載せているが、重点は同一企業における複数周期にわたる変化を見ることにあり、強引な横比較は行っていない。 SKハイニックスの「反サイクル性」という表現は、「総投資は縮小しているものの、HBMとDDR5の開発・投入は止ま 拡張ブレインストーミング ","date":"2026-05-13","language":"ja","permalink":"https://ttf248.life/ja/p/sk-hynix-financials-across-semiconductor-cycles/","tags":["AI霊感衝突坊","半導体","ストレージ","財務諸表","韓国株式市場","ai"],"title":"半導体サイクルは株価だけでは判断しきれず、SKハイニックスの決算書がより風向計となる。","year":"2026"},{"categories":["金融知識データベース","投資 (tōshi)"],"content":"前回の記事では半導体サイクルについて書きましたが、何か背景の部分が足りない気がします。\nあなたが提示したこの判断は、大まかな方向性としては正しいです。そして、これは今回の半導体の熱狂的な高騰を理解する上で、最も見落とされがちな前提だと感じます。\nより正確に言えば、「全てのインターネット巨大企業が同じ戦場（赛道）で争っている」ということではなく、むしろ：大規模モデル（LLM）が、本来、検索、広告、ソーシャル、Eコマース、オフィス、クラウド、コンテンツ配信といった異なる領域に分散していた巨大テック企業たちを、初めて大規模に同一の技術スタックにおける正面競争へと引き寄せている、という点である。\nこの技術スタックには、モデル、コンピューティングパワー（算力）、推論、クラウド、エ\nあなたの意見が基本的に成立する理由 これまでのインターネットの競争は、それぞれの陣地を守っているようなものだった。\nGoogle / Baiduは主に検索に強みを持つ。 Meta / Tencentは、主にソーシャルとトラフィックの分散（または配信）を主戦場とする。 Amazon / Alibabaは、主にEコマースと出店者エコシステムを主戦場とする。 Microsoftは、オフィスソフトウェアとエンタープライズソフトウェアを主戦場とする。 AWS、Azure、Google Cloudはこれらも取り組んでいるが、それらはよりクラウドインフラストラクチャおよびエンタープライズITに関する戦いだ。 今ではないです。\n大規模モデルは単なる点（特定の）機能ではなく、むしろあらゆる入口を飲み込むような「マスターキー」のようなものです。検索の仕組みが刷新され、広告の出稿も刷新され、カスタマーサポートも刷新され、コード生成も刷新され、eコマースにおける購買ガイドも刷新され、企業のナレッジベースさえも刷新されていきます。\nしたがって、これらの巨大企業は、表面上はそれぞれの独自の領域で利益を上げているものの、水面下では同じものを競い合っているのです。\n\\[ \\text{AI競争力}=\\text{モデル能力}+\\text{算力供給}+\\text{配布チャネル}+\\text{商業化クロージングサイクル} \\]差は、誰がどの分野でより強いかという点だけだ。\nMicrosoft はエンタープライズでの展開と Azure に強みがあります。\nAlphabetは検索、広告、そして独自の研究モデルスタックに強い。\nAmazonはAWS、チップ、およびエンタープライズクラウド顧客に強みを持っています。\nメタは、トラフィック導線（流入経路）と広告環境に強みを持っています。\nテンセントはスーパーアプリ、ゲーム、および広告の実装に強みがあります。\nアリババはEコマース、クラウド、産業顧客に強い。\n百度は検索、AI Cloud、およびERNIEに強みを持っています。\nあなたの判断は正しいですが、一点補足が必要です：皆が戦っているのは同じ巨大な戦場であり、単に同一の武器を持ち、同一のユーザー層を奪い合っているわけではない、という点です。\nこれが半導体が一緒に点火されてしまう理由です ストレージと韓国の半導体について前述しましたが、当時私はHBM、DDR5、eSSDといった具体的な品目に重点を置いていました。\nしかし、さらに上のレイヤーで見ると、これらの要素を真に一気に加速させたのは、インターネット大手による設備投資が特定の方向へ集中し始めたことです。\n今年はGoogleがサーバーを多めに買うから、来年はMetaがそれに続くってことだ。\nむしろ、2025年から2026年という段階では、マイクロソフト、グーグル、アマゾン、Meta、アリババ、テンセント、百度といった企業がほとんど、AIインフラストラクチャ、モデル訓練、推論サービス、エージェントプラットフォーム、およびAIの配信入口について語っています。具体的な定義は異なるところもありますが、資金はGPU、HBM、ネットワーク、SSD、データセンター、電力などの領域に集まっています。\nこの件はインターネットの歴史上では珍しいことです。\nモバイルインターネット時代は非常に大きく、しかしすべての企業が独自のOSを開発する必要はありません。\nショート動画時代は大変な盛り上がりを見せていますが、すべての企業が自前で推薦モデルの基盤（ベース）を訓練する必要はありません。\nクラウド時代は長いものですが、MetaやTencentのようなトラフィックプラットフォームやゲーム会社が、そのすべての中核（重心）を雲上に置いているわけではありません。\nしかし、今回の大規模言語モデルは、ほとんど全てのプラットフォーム型巨大企業が欠かせないと見なしている点で異なります。これが、今回の半導体サイクルがこれまでのサイクルと違う点です。\n各社が現在盛り上がっている技術（トレンド）の、真の焦点はどこか まず、前提となる定義を明確にしましょう。\n表内の売上高と純利益につきましては、可能な限り「各社が2026年5月12日時点までに完了した最新の会計年度」における公式な開示情報を用いるようにしています。しかし、「AI投資」という項目については、各社の開示方法にばらつきがあり、CAPEX（設備投資）を示すところもあれば、3年間の投資計画を提示しているところ、R\u0026amp;D費のみを開示しているところ、あるいは単四半期ごとの投入額しか公表していないところなどがあります。\nしたがって、この列は強弱の方向性を見るだけであり、機械的な順位付けをすることはできません。\n| 会社名 | 元来の柱 / 基盤事業 | 現在AIにおける牽引力 / 推進力 | 最新の通期売上高 | 最新の通期純利益 | 最新開示されたAI投資の内訳/指標 | | \u0026mdash; | \u0026mdash;\nこの表で最も注目すべきなのは、誰が最も多く収益を上げているかではなく、AIの先行投資期間を耐えうる十分な「キャッシュカウ」（資金力）を持っているかどうかです。\nMicrosoft、Alphabet、Amazon、Meta のこの4社は、ほぼ皆、一方では紙幣を刷り、もう一方では生産能力を拡大しています。\nテンセントとアリババも同様で、旧事業から継続的に資金源（または収益）を得ているため、AIへの投資を強化することができます。\n百度の問題点はさらに明白だ。早期に参入したものの、その企業規模やキャッシュフローの厚みが先行する数社と比較して弱く、耐え抜く能力（セストレージ・キャパシティ）が本質的に一段劣っているのが懸念点である。\n同じ「AI競争」というテーマであっても、各社の戦略（アプローチ）は実際には異なっている さらに掘り下げてみると、これらの企業は皆競争が激しいものの、立ち位置（ポジショニング）が異なることがわかります。\nカテゴリ1：シャベルを売る、そして自分で戦場に降り立つ Microsoft、Alphabet、Amazon はこのカテゴリーに属します。\nクラウド、チップやアクセラレーター、エンタープライズ顧客、そしてモデルやモデルエコシステムを持っています。\nこのような企業にとって最も怖い（厄介な）点は、AIが単なる製品ではなく、プラットフォーム全体への「アップグレード税」となってのしかかってくる点にあります。\nモデルをトレーニングするには、クラウドが必要です。\n推論するには、GPUをレンタルする必要があります。\nAgentになりたいので、プラットフォームサービスを購入する必要があります。\n従業員にAIツールを導入するためには、Copilot、Gemini、Bedrockに関連する機能（能力）も購入しなければなりません。\nそのため、単にバズるAIアプリを作りたいだけなのではなく、AIをシステム全体（あるいはITの出費）の一部として組み込みたいと考えているのです。\n第二種目：トラフィック王は、まず配布（流入）のエントリーポイントを書き直す Meta、Tencent、Baiduの方がこの種類に近いです。\n最も価値があるのは企業との契約ではなく、トラフィックのエントリーポイント、広告システム、コンテンツエコシステム、そして高い頻度で利用するユーザーの時間である。\nMetaが最も典型的です。すべての企業顧客にまずAIを販売する必要はなく、単に広告のターゲティング、コンテンツの推薦、クリエイティブの生成、対話インターフェースといった分野でAIを活用するだけで、広告効率と収益化能力を向上させるのに十分な効果があります。\nテンセントも同様です。WeChat、広告、ゲーム、クラウドは元々AIを組み込むのに最適な（自然な）シナリオだからです。必ずしもマイクロソフトと同じようにOfficeスイートでの競争が必要というわけではありませんが、WeChat内のAIアシスタント、広告配信効率、ゲームコンテンツの制作、そして企業向けWeChatでの協業といった分野で間違いなく力を入れてくるでしょう。\n百度は、より従来の検索エンジン企業として変革を遂げようとしている様子が見られます。モデル、クラウド、検索機能といった要素を備えながらも、旧広告事業からのプレッシャーが最も大きいのが現状です。そのため、伝統的なトラフィック基盤を維持しつつ、AIのビジネス化を強力に推進することが求められています。\nカテゴリ3：エコシステムリーダー。AIをトレーディングおよび産業インフラストラクチャにしたいと考えている アリババがこのタイプにおいて最も典型的な例です。\nその野心は、単に通義千問を作るためでも、単に阿里云を売却するためでもありません。真に目指しているのは、AIをEコマース、出店者ツール、カスタマーサービス、マーケティング、サプライチェーン、産業用クラウドといった、このシステム全体に組み込むことなのです。\nそのため、アリババは近年一貫して「AI + Cloud」を掲げています。この四文字は単なるスローガンではなく、多くの企業よりも早く以下の点を認識していたからです：モデル自体が最も収益性が高いとは限らないが、モデルによってクラウドと取引プラットフォームの再価格設定（または再定義）が可能になること。\nなぜこの紛争が半導体需要をこれほど集中させたのか ここから、実は半導体に戻ることができます。\nある特定の企業だけがAIを好意的に見ている場合、それがもたらすのは単なるテーマ投資の側面が強いだけです。\nキャッシュフローが最も強い七〜八社のプラットフォーム企業が、capex、R\u0026amp;D、モデル、推論、エージェント、配信チャネルといった要素を同じレイヤーに積み上げていけば、それはもはやテーマではなく、現実の受注案件となるでしょう。\nしかし、実際の注文は最終的にこれらになります：\nGPU およびカスタムAIチップ。 HBM および高性能DRAM。 エンタープライズSSD、高帯域幅ストレージ。 高速ネットワーク、スイッチングチップ、光モジュール。 データセンター、電力（電源）、冷却（排熱）。 そのため、最近の半導体市場を分析する際は、単に一つのメモリメーカーや韓国の企業だけに注目すべきではありません。\n本当の背景は：インターネット巨大企業たちが、異例なことに同じレベルの軍拡競争において同時に勢いを増した（アクセルを踏んだ）点にある。\nまとめ 2026年5月12日時点での、あなたのご意見に対する私の判断は以下のとおりです。\n基本的に正しいです。 より正確な表現は以下の通りです：インターネット大手は「同じ製品の競争領域」に完全に巻き込まれているのではなく、むしろ同一レイヤーのAI基盤技術における軍拡競争に巻き込まれています。 このことが重要なのは、単にAIがバズるアプリケーションを生み出すからという理由だけではなく、検索、広告、SNS、Eコマース、オフィス、クラウドといった元々分散していた利益の源泉を、再び単一の基盤的な競争フレームワークに引き寄せているからです。 これもまた、半導体、特にGPU、HBM、ストレージ、データセンターといったサプライチェーンが最近これほど活発な背景の一つでもあります。 どう言ったらいいでしょうか。かつては各社が独自の縄張りを固めることが可能でした。しかし、今はそうはいかなくなってきました。大規模モデルという事柄は、単なる一つの新潮流ではなく、プラットフォーム企業にとって無視できない「インフラストラクチャ戦争」と化しているのです。\n参考文献 Microsoft FY25 Q4 Income Statements Microsoft FY26 Q3 Press Release Alphabet 2025 Q4 Earnings Call Alphabet 2025 Q3 Earnings Call Alphabet 2025 Q2 Earnings Release [Alphabet 2025 Q1 Earnings Release](https://abc.xyz/assets/34/fa/ee06f3de4338b99acffc5c229d9f/2025q1-alphabet- 作成上の注記 元のプロンプト 前半ではAI需要の旺盛さ、半導体の急騰について述べましたが、ここで一般的に見落とされがちな背景があります。それは「AIの大規模モデル」という分野です。これは稀有なケースで、各社のインターネット巨大企業が皆参戦し競争を繰り広げている領域です。以前はそれぞれの分野で発展していましたが、このようにすべてが一つの領域で激しく争っている状況は珍しいです。まず、私のこの見解が正しいか確認させてください。次に、各国が展開している分野、それぞれが得た売上高、純利益、そしてAIへの投資額を整理したいと思います。\nライティングの構成案の要約 まず、意見の妥当性を判断し、「どの程度のレベルで成立しているか」を明確に説明することで、断定的な表現を避けてください。 本文中で「同一赛道（同じ市場）」という表現は、「同一技術スタック」に書き換えることで、各社の実態 拡張ブレインストーミング ","date":"2026-05-12","language":"ja","permalink":"https://ttf248.life/ja/p/ai-giants-common-battleground-2026/","tags":["AI霊感衝突坊","ai","大規模モデル","インターネットの巨大企業","半導体"],"title":"大規模モデル（LLM）という事柄は、本当にインターネットの巨大テクノロジー企業群を一つの闘技場（あるいは戦場）に集めましたね。","year":"2026"},{"categories":["金融知識データベース","投資 (tōshi)"],"content":"今回の半導体市場の動向について、私は一時的に2026年がピークになるとは見ていません。\nもし最初に判断を述べるとするならば、2026年5月12日時点での私の見立てでは、真に危険な時期は現在ではなく、2027年下半期から2028年上半期にあると考える傾向が強いです。現在の株価上昇サイクル、特に米国のストレージや韓国の半導体において、その核心は単なる普通のリバウンドではなく、AIがHBM、DDR5、エンタープライズ級SSDなどをまとめて牽引している点にあります。供給を拡大できない場合、価格と利益は共に高騰するでしょう。\nこれが、MicronやSK hynix、Samsungといった企業が最近まるで「お金を刷っている」かのように見える理由です。半導体サイクルは消滅していませんが、今回は需要が上がり始めたタイミングで崩壊するのではなく、むしろ増産がようやく追いつき、市場がすでに2〜3年分の利益を享受しきってしまった時に終わる可能性が高いのです。\n結論から言えば、なぜ私は2026年終了を見ないのか まず、「一手」と「半一手」の材料を数本、テーブル（机）の上に置いてください。\n対象 2026年5月時点のシグナル 私の見解 Micron 2026年度第2四半期売上高が2386億ドル、売上総利益率74.9%。会社は需要が強く供給がタイトであり、その状況が2026年以降も続くと明確に発言。 米国のストレージ市場は単なる「反発」ではなく、利益爆発の取引が行われている。 SK hynix 2026年第1四半期売上高が52.6兆韓国ウォン、営業利益が37.6兆韓国ウォンと過去最高を記録し、DRAMおよびNANDにおける有利な価格環境が続くことを明確に発言。 韓国半導体の核となる焦点はAI これらの信号を繋げると、答えはより明確になります。\nこれは従来のPCサイクルでも、スマートフォン買い替えの波でもありませんし、「パンデミックによる半導体不足」の単純な反復でもありません。その原動力となっているのは、巨大テック企業からのAIデータセンター設備投資であり、AIサーバーがメモリとストレージに要求するスループットの高さが、HBM、DDR5、大容量DIMM、エンタープライズSSDといった要素を同時に逼迫させています。Micronは昨年12月の投資家向け資料で非常に明確に述べている通り、「可視的な将来においても、業界全体の供給は需要を明らかに下回っており、タイトな状況は2026年以降も続く」とのことです。\n言い換えれば、現在市場が賭けているのは、「来年良くなるかどうか」ではなく、「2027年より前に緊迫した状況が終わるかどうか」です。もしこの前提が覆されなければ、サイクルは2026年に自ずと終焉を迎えるのは難しいでしょう。\nこの波で、なぜ米国株のストレージと韓国半導体が同時に盛り上がったのか 多くの人は「米国のストレージ」と「韓国の半導体」を別々に見ています。しかし、実はこの2つの流れは、2026年までにはすでにほぼ合流しています。\nマイクロンは、米国株市場において最も直接的なメモリ関連のベータ（指標）です。ロイターは、2026年3月19日の報道で、マイクロンが年初からすでに株価を61%以上上昇させたことに加え、同社が2026会計年度の設備投資計画にさらに50億ドルを追加し、総額を250億ドル以上に引き上げたと報じています。この動き自体が、経営陣が既存の生産能力だけでは、今回のAIによる需要の高まりに対応しきれないことを認めていることを示しています。\n韓国の方がさらに誇張されています。SK hynix は 2026 年 5 月 4 日に史上最高値を記録し、当日終値は 12.52% 上昇しました。ロイターの同じ記事には、韓国の中央銀行の高官が、今回の半導体好況が以前よりも長く続く可能性があると判断したとも触れられています。この発言は根拠のないものではなく、韓国を代表する主要なメモリメーカーの2社が、自社の決算報告や電話会議で継続的に同様の情報を出しているからです。\nサムスンは2026年4月下旬の電話会議で、**「既に入手した2027年の需要に基づくと、2027年の需給ギャップは2026年よりもさらに大きくなる」**と述べました。この発言は非常に重いものです。これは、市場が現在熱狂的に急騰している理由が、単に2026年の利益を巡って争っているからではなく、2027年の品不足（欠品）を先回りして取引していることを意味します。\nしたがって、今回の相場において最も重要な特徴は、「半導体全体の景気」ではなく、むしろ：\nAIは、最も収益性の高いメモリの特定セクターを、業界全体のボトルネックにしてしまった。 HBMはDRAMの生産能力と先進パッケージング資源を消費し、同時に通常のDRAMも逼迫させてしまうだろう。 サーバーおよび推論サイドのSSD需要は、もはやPCやスマートフォンに追随するだけでなく、大規模モデルのインフラストラクチャに直接紐づくものとなっている。 これらの3要素を組み合わせると、Micron、SK hynix、Samsung の収益の弾力性は非常に驚異的になります。メモリ（ストレージ）は元々高い営業レバレッジを持つ業界であるため、ASPが上昇すると、利益は直線的に上がるというよりも、急激に跳ね上がる傾向があります。\nこれまでの半導体サイクルは、通常どのように終焉を迎えるのか この部分を半導体の年代記として書きたいわけではありません。真に投資としてインパクトがあり、記憶に残るものは、実は以下の数サイクルなのです。\nこの表を見ると、実はとてもシンプルな法則（パターン）がわかります。\n半導体サイクルの真の終焉は、「バリュエーションが高すぎるから落ちる」といった理由だけによるわけではありません。それは、3つの条件のうち2つを満たしたり、さらには3つすべてが同時に出現する場合が多いです：\n\\[ \\text{サイクルピーク} \\approx \\text{供給成長率が需要成長率に追いつくこと} + \\text{在庫水準の底値からの反転} + \\text{最終需要の限界的な減退} \\]簡単に言うと：\n新たな供給能力（新キャパシティ）が放出され始める。 顧客が、買い占めから様子見に移行する。 主要企業は、品不足について語るのではなく、在庫、コスト、および価格圧力について言及し始める。 需要の崩壊と在庫により、2001年に亡くなる。\n2008年から2009年のマクロ経済危機による死者。\n2019年は、価格サイクルと貿易の混乱によって（左右された）。\nパンデミックによる過剰消費に伴う在庫削減（調整）が、2023年の景気後退要因となった。\nですから、私が今最も信じがたい（懐疑的な）考え方の一つは、「半導体が高騰しすぎたので、もうすぐ終わるはずだ」というものです。サイクルピーク（周期の頂点）は、決してこのように訪れるものではありません。それは、現実の世界での需給関係がまず緩和される必要があるのです。\n今回と2021年～2022年の回との、決定的な違い（差）とはどこにあるのか 2021年から2022年頃のサイクルでは、多くのチップが上昇しましたが、背景となる論理は散漫でした。自動車、家電、携帯電話、PC、サーバーなど、ほぼすべての分野で在庫補充が行われましたが、パンデミックによってサプライチェーンは大きく混乱しました。そのサイクルの終焉も非常に典型的でした。すなわち、エンドユーザーの需要落ち込み、チャネルにおける在庫の高止まり、そして業界全体が集団的な調整（修正）に入ったという流れです。\n2026年は、より集中的、そしてより危険なラウンドになるでしょう。\n注目されているのは、資金が主にAIデータセンターに注ぎ込まれており、需要の発生源は少ないものの、一点あたりのインパクトが大きいという点だ。\n危険なのは、このような需要が完全に市場化された日常的な消費によるものではなく、いくつかの巨大企業からの設備投資（資本支出）によって牽引されている点です。もしクラウドベンダーやプラットフォームベンダーが特定のタイミングで気づいてしまうと：\nGPUの利用率が期待されていたほど高くなかったこと； 推論による収益の実現が、設備投資（キャピタル支出）に比べて遅いこと； エージェンティックAIが商業化を成し遂げていないこと； あるいは、マクロな環境、関税、エネルギー、為替レートなどがリターンサイクルを長期化させていること。 それだと、需要の伸び率は急激に落ちる（低下する）でしょう。\n現在、業界はこの段階には至っていません。むしろ目に見えるのは、多くの巨大テック企業が引き続きAIインフラストラクチャに大規模な投資を続けていることです。SIAのデータによると、2025年の世界の半導体売上高はすでに7,917億ドルに達し、2026年にはほぼ1兆ドル近くになると予測されています。サムスンもまた、2026年下半期には、ハイパースケーラーがエンタープライズAIおよびLLMサービスを支えるため、サーバーメモリの需要が引き続き高いままであると明確に述べています。\nこれが私がこう判断する理由です：「2026年は天井を打つ一年というより、価格上昇と生産拡大が並行して進む年となりそうだ。」\nじゃあ、このラウンドはいつ頃終わりそうでしょうか？ これはあくまで基準となる判断（または評価）ですので、過度に複雑に考える必要はありません。\n私のベースラインシナリオ 突然の世界的な景気後退がなく、AI関連の設備投資が断崖絶壁のように急縮する事態がない場合、この半導体の上昇サイクルは**2027年下半期頃から懸念域に入る可能性が高く、2028年上半期には真のサイクルピークの特徴が見えやすくなるでしょう。\n原因は4つあります。\n第一に、供給の放出には物理的なタイムラグがあります。\nMicronが設備投資を拡大するにせよ、SamsungやSK hynixがHBMおよび関連ラインを拡充するにせよ、クリーンルーム、装置、パッケージング、歩留まりの確保には時間がかかります。現在すべての企業がお金が儲かりやすいと知っていますが、今日拡張すると発表したからといって、明日すぐに製品を納入できるわけではありません。\n第二に、2027年分の需要はすでに早期に確約（受注/確保）されています。\nサムスンはすでに数年にわたる拘束力のある契約に言及していますが、ロイターが報じた電話会議の内容はさらに直接的であり、2027年の需給ギャップ（不足分）は2026年よりも大きくなる可能性があります。このシグナルは非常に重要です。これは、主要顧客が四半期ごとに購入するのではなく、年間、さらには複数年単位でリソースを確保していることを意味します。\n第三に、今回はHBMだけではありません。\nもし単にHBM一本のラインに留まるのであれば、「先進製品が好調で、他は平均的」と解釈することもできます。しかし現在、Samsung、SK hynix、Micronの発表内容は、より広範なDRAMおよびNANDの逼迫を示しており、特に大容量サーバー向けDRAMモジュール、AI向けのeSSD、KVキャッシュ関連ストレージが該当します。この波及が収まらない限り、サイクルは外側へ伝播し続けていると言えます。\n第四に、株式市場は通常、決算発表よりも早くピークを迎える傾向があるが、ナラティブ（物語）の盛り上がりよりも先にピークを迎えるわけではない。\n現在、主要なナラティブは依然として「欠品、値上げ、受注確保、設備増強が追いつかない」というものです。株価が真に天井を打ったように見えるのは、メインのナラティブが「生産能力の実現、価格のピークアウト、顧客が物資を買い占めるのではなく待てるようになる」といったフェーズに移行した場合です。\nどのような場合に早期に終了するのか 天井を打つ可能性がないわけでもないです。\nもし以下の出来事の2〜3点が、2026年第4四半期から2027年上半期にかけて同時に発生した場合、私は明らかに慎重になります。\nクラウドベンダーがAI設備投資の成長率の下方修正を開始している。 主要なメモリメーカーが、不足品（欠乏）を強調するのをやめ、代わりにCAPEX、減価償却費、および歩留まりの改善に焦点を移している。 一般的なDRAM / NANDの価格が、HBMよりも先に横ばい、あるいは反転している。 スマートフォン、PC、エンタープライズIT予算が高価なメモリに対応できず、需要を巻き戻している。 マクロレベルで景気後退、関税引き上げ、エネルギーショック、または韓国国内の生産擾乱が発生している。 特に第5条は、決して低く見積もることはできません。2008年から2009年の局面では、半導体業界がどれほど強固であっても、マクロな信用と需要の落ち込みという両方には耐えられないことが証明されました。\n本当に注目すべきは、「どれだけ上がったか」ではなく、これらの転換点だ サイクルの終焉時期に関心があるなら、日々の株価の上げ下げ（赤や緑）を追うよりも、むしろ下記のシグナルに注目することをお勧めします。\n私の判断基準は非常にシンプルです。業界が「需要超過」について語っている限り、そして「在庫調整（回復）」ではなく話題にしている限り、このサイクルはまだ真に終わっていません。\nまとめ 2026年5月12日時点では、私の結論は：\n今回の半導体サイクルは、おそらく2026年には終わらないでしょう。 米国の株式市場におけるストレージと韓国の半導体の異常な高騰は、同じ事実に裏打ちされています。それは、AIがメモリ・コンプレックス（memory complex）の利益弾力性を根底から開いたからです。 これまでのサイクルの終焉の仕方は神秘的なものではなく、中核となるのは需要の下落、在庫の増加、そして供給が追いつくという流れに尽きます。 今回最も可能性の高い危険水域は、現在ではなく、**202 もちろん、今すぐに無条件で投資（飛びつく）という意味ではありません。どう言えばいいでしょうか。半導体のような業界が最も恐れているのは「景気」そのものではなく、むしろ皆が好況が永久に続くものだと信じ込み、結果として高利益な年に必死になって設備を拡張してしまうことです。\nサイクルは通常、最悪の時に衰退するのではなく、最も良くて、盛り上がって、品薄な時（ピーク）に衰退しやすい。\n参考文献 Micron Technology, Inc.が2026年度第2四半期の決算を発表 Micron 2026会計年度第1四半期投資家説明資料 Micron 2026会計年度第1四半期決算電話会議準備原稿 SKハイニックスが第1四半期2026年の財務結果を発表 Samsung Electronicsが2026年第1四半期の決算を発表 グローバル半導体売上、Q4 2025からQ1 2026にかけて25%増加 グローバル年次半導体売上は、2025年に7,917億ドルで25.6%増加 グローバル半導体売上は、2018年に4,688億ドルで13.7%増加 [世界半導体売上は、2019年に4,120億ドルで12%減少](https://www.semiconductors.org/worldwide-semiconductor-sales-decrease-12-percent 作成上の注記 元のプロンプト 最近、半導体関連銘柄が急騰しています。米国におけるストレージ（メモリ）、韓国の半導体などについて、関連資料を整理し、今回の半導体サイクルがいつ終了するのかを予測したいです。また、過去の半導体サイクルはそれぞれどのような形で終焉を迎えたのか、どれくらいの期間続いたのかを知りたいと考えています。\n作成の構想の要約 ブレストの拡張 ","date":"2026-05-12","language":"ja","permalink":"https://ttf248.life/ja/p/semiconductor-cycle-not-ending-in-2026/","tags":["AI霊感衝突坊","半導体","ストレージ","ニューヨーク証券取引所（NYSE）/ 株式市場","韓国株式市場"],"title":"この半導体サイクル（周期）の終点は、おそらく2026年ではない可能性が高いです。","year":"2026"},{"categories":["金融知識データベース","投資 (tōshi)"],"content":"富途（の）この問題については、先に結論をお話しします。\n富途証券が現在デフォルトで表示しているのは、多くの人が理解する「購入分だけを見て売却分を見ない」という単純な平均コストではなく、「平準化された原価（摊薄成本）」に焦点を当てています。さらに掘り下げると、香港の証券会社には統一されたデフォルトの計算基準はありません。もし中国語圏の個人投資家向けの保有状況ページであれば、一般的に平準化コスト、平均コスト、元本保護価格といった表示基準が使われます。しかし、IBKRのように税務ロト（tax lot）や取引報告書の整合性をより重視する国際的な証券会社の場合、デフォルトではFIFO（先入先出法）を用いることが一般的です。\n国内の証券会社の場合、A株取引クライアントで最も一般的な「コスト価格／保有コスト価格」という項目は、単純な購入平均価格ではなく、償却原価（攤薄成本）または元本維持を重視した価格帯であることがより一般的です。ただし、各証券会社によって名称が統一されておらず、「保有コスト」と呼んでいるところもあれば、「摊薄成本」と呼んでいるところもあり、また単独で「購入平均価格」を表示しているケースもあります。\nまず、3つの概念を分けて見ていきましょう これら3つの言葉はよく混同されますが、同じものではありません。\n「お手持ちの残り株の平均的な取得単価」だけを確認したいだけであれば、平均コスト（平均単価）が最も直感的です。\n「この銘柄を何度も売買（T）した後、残りのポジションは元本維持からどれくらい離れているか」といったことを気にしているなら、平均取得単価を引き下げる方がより現実的です。\n「どの古いロット（ポジション）が最初に売却されたのか」という点に関心があるのであれば、それは単なるフロントエンドでの建玉表示の問題ではなく、FIFOのようなロットマッチング（実現ロジック）の問題となります。\n富途の現在のデフォルトはどれですか 私は、2026年5月8日に富途香港ヘルプセンターと富途NiuNiuヘルプセンターを確認し、2つの非常に明確な事実を得ることができました。\n第一に、富途ヘルプセンターでは、「コスト平準化価格」と「平均単価」という2種類のアルゴリズムについて個別に説明しています。\n[ \\text{調整後原価}=\\frac{\\text{保有期間中の買付総額}-\\text{現金配当}-\\text{売却総額}}{\\text{保有数量}} ] \\[ \\text{平均コスト価格}=\\frac{\\text{購入前の平均コスト価格}\\times\\text{数量}+\\text{今回購入価格}\\times\\text{数量}}{\\text{購入後の保有数量}} \\]富途牛牛の「ポジション（保有）フィールドの説明」ページでは、株式の保有フィールドがそのまま**コスト単価（割当コスト）**として記載されています。このページに提示されている計算式には現金配当が含まれておらず、重点を置いているのは、ポジションページの表示ロジックの説明です。一方、香港ヘルプセンターの「コスト単価のご紹介」や「よくある質問」では、計算式の中に現金配当も組み込まれています。両者の記述方法が完全に一致しているわけではありませんが、\nFutuは「よくある質問」の項目でより直接的に説明しています。すなわち、**「現在Futuでは加重平均コスト価格を使用しています」**と記載されています。また、多くのユーザーが初めて目にしたときに戸惑う現象についても説明しています。それは、売却金額が購入金額を上回っているにもかかわらず、口座にまだ残っているポジションがある場合、取得単価（コスト）が0、あるいはマイナスになることがあるという点です。 この件自体が示すのは、富途のデフォルト表示は「平均原価」ではなく、「過去に発生した売却損益をすでに考慮に入れて調整された（償却された）」基準に基づいているということです。\nしたがって、「富途証券のデフォルト原価計算アルゴリズムは何ですか？」という質問であれば、答えはかなりシンプルで明確です。それは「デフォルトでは平均取得単価が適用される」ということです。\n香港の証券会社はデフォルトでどの種類？一言では決めつけられない。 「香港の証券会社」をひとつのまとまり（全体）として捉えがちですが、この表現は正確性に欠けます。\n調べたいくつかの事例からは、それ（が）統一的でないこと（が一貫性がないこと）がよくわかります。\n証券会社 / システム 確認した計算方法 結論 富途 現在は平均取得原価を使用している デフォルトは平均取得原価に偏る 老虎証券 平均取得原価、FIFO、平均コストを明確に区別し、設定で選択可能 単一のデフォルトロジックで全てがカバーされているわけではない 老虎証券のヘルプセンターは非常に分かりやすいです。平均原価、FIFO（先入先出法）、加重平均コストをそれぞれ個別に項目として提示しており、同じ取引群に対して3つのアルゴリズムで異なる結果が示されています。同時に、虎の「実現損益」「未実現損益」のページには、FIFOと平均原価では結果が異なる場合があるため、設定から選択できる旨が明記されています。\nこれはどういう意味ですか？\n「香港の証券会社がデフォルトとしているのはどれか」という問題は、具体的な証券会社に絞り込まないと、結論が大きくずれてしまう可能性が高いです。\n私の判断は以下の通りです。\n富途証券や老虎などの中国語圏のリテールブローカーのアプリの「保有銘柄ページ」の文脈の場合、保有銘柄の表示を中心に計算を行うことが多く、「コスト平均化（摊薄成本）」、「平均コスト」、「元本維持価格（保本价）」といった指標がよく見られます。 IBKRのような国際ブローカーのレポートや税務の文脈の場合、FIFO方式の方がより一般的なデフォルトの考え方です。 したがって「香港の証券会社はデフォルトでFIFO」という表現も、「香港の証券会社はデフォルトでコスト平均化」という表現も誤りであり、正しい説明は特定の証券会社と特定のページに限定される必要があります。 国内証券会社でより一般的なのはどちらか A株の証券会社クライアントで最も一般的に使用される「取得価格」フィールドに範囲を絞った場合、私の結論は以下の通りです。\n国内の証券会社では、単純に平均価格での買い付けというよりも、コスト平均化や元本維持を重視するアプローチの方が一般的です。\n国信証券は、以前からこの定義を非常に明確に記述しています。その「保有コスト価格」のアルゴリズムは以下の通りです：\n\\[ \\text{保有コスト価格}=\\frac{\\text{保有期間内の購入資金総額}-\\text{保有期間内の売却資金総額}}{\\text{利用可能株数}} \\] この公式の鍵となる点は一つだけです：売却金額が残りの保有コストに逆の影響を与えます（または、調整します）。これはもはや単なる単純平均購入価格ではなく、明らかにコスト平均化の考え方に近いものです。\n興業証券や長江証券を見ると、指標の区分けがより細かくなっています。これらは、「購入平均単価」「保有コスト」「調整後コスト」「元本保全価格」を個別に説明しています。特に長江証券は、自社のコスト価格の種類が4種類に分かれていると直接述べています。\nこれは逆に2つのことを示しています。\nまず、国内の証券会社は平均原価を算出できないわけではなく、むしろ「平均原価」というものを独立した項目（フィールド）として扱うことが多く、必ずしもそれをデフォルトの「取得コスト（原価）」として使用するわけではありません。\n第二に、国内の証券会社はフロントエンドでの表示において、「現在の保有ポジションが元本回復からどれだけ離れているか」を重視しすぎるため、売却による影響も容易に原価表示に取り込んでしまいます。この考え方は、実際にはIBKRのロット勘定ロジックというよりも、富途（Futu）の方が近いものと言えます。\nなぜ多くの人が「コスト価格（原価）が間違っている」と感じてしまうのか 通常、計算を間違えているわけではなく、あなた（ご自身）が頭の中で持っている「コスト価格」の定義と、証券会社の画面上に表示されている「コスト価格」が示すものが異なるためです。\n最も一般的な誤りは3つあります。\n種類1：購入平均価格でのみ理解する 一部を売却しても、残りのポジションの取得コスト（平均原価）は変わるはずではないと思いますか。\nこれは「平均コスト」の観点から成り立ちます。\nしかし、もし証券会社が表示しているのが調整（または平準化）された原価である場合、以前に利益が出た売却は、残りのポジションの平均取得コストを確かに引き下げます。逆に、以前に損失が出た売却を行うと、残りポジションの平均取得コストが押し上げられることになります。\n2つ目：ポジションの表示基準とレポート算出ロジックが混在している点 Appの保有銘柄ページでは、コスト平均化（加重平均）が表示されている可能性があります。\nしかし、月次決済明細書、税務申告書、実現損益の分離は、FIFOまたはその他のロットマッチングルールに従っている可能性があります。\nこれら二つの指標（または定義）は、もともと必ずしも一致しません。\n第3つ目：企業行為（コーポレートアクション）、ポートフォリオの組み替え、配当、株式分割などが発生した場合 こうしたシナリオでは、原価設定が最も混乱しやすい点です。\nFutuとTigerのヘルプセンターでも案内されていますが、企業行動や売却後の原価は参照用であり、正確でない場合があります。この注意点は非常に重要です。なぜなら、多くのユーザーがフロントエンドの表示を会計上の根拠（台帳）として利用し、最終的に混乱してしまうことが多いためです。\n私の結論 最後に確認してください。\nもし、Futu（富途）について尋ねているのであれば：\n富途証券では、現在デフォルトとして平準化された取得価格（平均原価）が採用されています。 もし、香港の証券会社全体について尋ねているのであれば：\n統一されたデフォルトアルゴリズムがない。 富途はコスト平準化に重点を置く傾向がある。 老虎は複数の原価計算アルゴリズムの切り替えに対応している。 IBKRのような国際証券会社のデフォルトの税務原価算出（tax lot）は、FIFOに傾いていることが多い。 国内の証券会社全体について尋ねられている場合：\nより一般的なのは、コスト平準化／原価維持への重点です。 「平均仕入れ価格」は通常存在しますが、それは別のフィールドであることが多く、必ずしもデフォルトで表示される「原価」であるとは限りません。 誤判断を避けるには、「香港の証券会社がどの種類をデフォルトとするか、国内の証券会社がどの種類をデフォルトとするか」といった大枠の結論を覚えるのではなく、以下の3つの問題に直接注目するのが最も確実な方法です。\nこのページに表示されているのは、「保有コスト」、「平均購入価格」、それとも「元本維持価格」のどれですか？ 売却取引を行うと、残りのポジション（残高）のコストに影響しますか？ この算出根拠は、フロントエンドでの表示用ですか、それともレポート／税務上のロット単位（または区分け）での基準ですか？ この3点をしっかり理解すれば、原価価格に惑わされることはなくなるはずです。\n参考資料 ライティングの注記 元のプロンプト フトゥ証券の原価計算アルゴリズムは、香港の証券会社ではデフォルトでどちらが採用されていますか？国内の証券会社では、デフォルトでどちらですか？\n執筆の概要（骨子） 脳のブレインストーミングを広げる ","date":"2026-05-08","language":"ja","permalink":"https://ttf248.life/ja/p/futu-cost-basis-hk-mainland-brokers/","tags":["AI霊感衝突坊","富途証券","香港株式 / グローバル株式 (Global Stocks)","証券会社","原価"],"title":"富途証券の原価計算アルゴリズムについて、香港および国内の証券会社では標準的にどちらの方法（方式）を採用していますか？","year":"2026"},{"categories":["投資 (tōshi)"],"content":"今回のAI市場における最も異様な点は、NVIDIAが大きく上昇したことそのものではなく、その上昇幅がサプライチェーン全体にわたって波及している点です。具体的には、まずGPUに始まり、その後サーバー、スイッチング機器、ASIC、HBMへと広がり、そしてNAND、ストレージ（ハードディスク）、電力、データセンターまで広がっています。\n単なる概念に過ぎないのであれば、市場がこれほど長く続くはずではない。しかしながら、それが完全な利益サイクルを形成したと断定するには、時期尚早すぎるようだ。\n私はこれを「確実な支出に牽引された強気相場」として捉える方が良いと思います。クラウドベンダーとモデル企業が本当に資金を費やし、上流工程の企業が実際に収益を得ているので、まず株価は上昇します。しかし、エンドユーザーアプリケーションがこれらの投資によって安定的に十分な利益を上げられることをまだ証明していないため、バブルのリスクも現実的に存在しています。\nまず、定義（スコープ）から明確にしましょう 本記事は投資助言ではありません。株価データは、公開された市場情報および過去の終値に基づいた概算の振り返りです。焦点は「局面」と「論理」であり、各取引日の小数点以下の精度を追求するものではありません。\n時間的な起点（開始点）は「2022-11-30」と設定します。これはChatGPTがリリースされた当日頃のものです。終点については、執筆時点である「2026-05-08」付近の公開市場状況に基づいた理解として扱ってください。\n上昇率は、概算で以下のように理解することができます：\n\\[ \\text{上昇率}=\\frac{\\text{期間末価格}-\\text{期間初価格}}{\\text{期間初価格}} \\]時間の推移：AIがどの段階に進むか、株価はどこを牽引するか 2023年5月は、初期段階における最も重要な転換点でした。\nChatGPTが大きな話題となった際、市場は「これはチャットボットのバブルではないか？」と疑念を抱くこともできました。しかし、NVIDIAが2023年5月に示した業績ガイダンスが、その疑念を一気に払拭しました。データセンターの収益および来四半期の収益ガイダンスは市場予想を大幅に上回っており、市場は「モデルの能力」が実際に「GPUの受注」に結びつくことを初めて目にしたのです。\nだからこそ、NVIDIAは2024年になってから初めて上昇を始めたのではなく、2023年にはすでに主要な上昇局面に入っていたのです。\n2024年になり、市場の焦点は「GPUを買う」という段階から、「AIファクトリー（工場）」を買うという段階へと拡大しています。大規模モデルをトレーニングするには、単にいくつかのグラフィックカードを購入するだけではありません。真に高額なのはクラスター全体です。GPU、HBM、ネットワーク、サーバー、液体冷却、電力、データセンターの設備、そしてソフトウェアスタック。どれか一つでも欠けると動作しないのです。\nしたがって、Supermicroが急騰し、Broadcomも急騰し、TSMCも上昇し、Oracleも上昇するでしょう。それらは同じ種類の企業ではありませんが、すべてAIインフラストラクチャの決済チェーン上に位置しています。\n2025年以降、市場は二層目の確実性を探し始めています。それは、「モデルが実際に企業プロセスに組み込まれるか否か」という点です。PalantirのAIPがまさにこの段階を代表しています。市場が購入しているのは、単なるソフトウェア会社そのものではなく、「AIが企業の意思決定や運用システムに進出する」という想像上のスペース（ポテンシャル）なのです。\nこっちのほうが、想像上のポテンシャルが明らかに高い。GPU関連企業は既に収益を上げている一方、エンタープライズ向けAIソフトウェアは、継続的にどれだけの収益を確保できるかをまだ証明している段階だ。\n主要企業の概算上昇幅 ChatGPTの公開以降という観点から見ると、最も急騰しているのは、マイクロソフトやグーグル、アマゾンのような大型テック株ではなく、時価総額が比較的小さく、業績の弾力性がAIによって大きく引き上げられている企業である。\n| 企業名 | 事業分野 | 2022年11月30日頃から2026年5月頃までの大まかな推移 | 最も急激な期間 | 主要な要因 |\nこの表で最も注目すべき点は、上昇幅が「AIとの関連度」によってのみ決定されるわけではなく、元の時価総額、利益の弾力性、保有構造（銘柄構成）、および業界サイクルなど、複数の要因によって同時に決定されるという点です。\nマイクロソフトはもちろん重要ですが、大きすぎます。マイクロソフトが50％上昇する場合、必要となる資金や時価総額の増加分があまりにも誇張されすぎています。一方、中小市值企業の場合、もし市場が突然その企業をAIの主要なサプライチェーンに乗っていると認識すれば、株価はより容易に何倍にも引き上げられやすい傾向があります。\nこれもSanDiskが急騰する中心的なロジックの一つです。\nシーディがなぜこれほど急騰したのか サンディスクは、2022年以降、AIの盛り上がりとともに上昇してきたような既存の大型銘柄ではありません。その独自性は、2025年にウェスタンデータから分社化し、より純粋なNANDおよびフラッシュメモリに特化した銘柄となった点にあります。\nその高騰は、「AIがストレージを必要とするから」という理由だけではありません。より正確に言うと、いくつかの要因が組み合わさって（または「重なって」）います：\n| 要因 | 効果\nユーザーが言及された「時価総額が低く、資金を消費する量が少ない」という判断は正しいと思います。ただし、一点補足させてください。時価総額が低いのは単なる「弾力性の源泉」に過ぎず、「上昇の理由そのもの」ではありません。\nNAND価格の回復、AIデータセンター向けのSSD需要、または会社独立後の財務実績改善といったファンダメンタルズによるカタリストがなければ、時価総額が低いだけでは、売られやすいだけでなく、暴落しやすい側面もあります。真に強い相場は、一般的に「低時価総額 + 低い期待値 + ファンダメンタルズの緩やかな改善」という要素が同時に発生する場合です。\nキオクシアの今回の動きは、AIによる追い風がストレージサイクルの底に到達したように見えます。風自体は非常に強いのに、地盤（市場）がちょうど乾燥している状況です。\n今回の相場はインターネットバブルに似ていますか 〜のような、〜に似ているが、そうではない。\n重要な点は、バリュエーションが利益のサイクルに先行することです。多くの企業の株価の上昇は、今後5年、あるいは10年という未来への期待（想像）に基づいています。市場は、「インフラになり得る」企業を事前に織り込んで価格をつけているのです。\n異なる点は以下の通りです。今回のアップストリーム企業は、すでに実金を得ています。NVIDIA、TSMC（台湾積体電路製造）、ブロードコム、メモリメーカー、サーバーメーカーなどは、単にプレゼン資料を売っているのではなく、ハードウェアとサービスを納入している点です。\nそのため、「全てがバブルだ」と一言で括るという点には、あまり同意できません。むしろ、〜のようです。\nレイヤー 現状 リスク 計算リソースハードウェア 収益化のサイクルが最も明確で、受注も本物である CAPEXが減速すると、バリュエーションと在庫 現時点で最も大きな矛盾点は、AIの上流工程では既に利益循環モデル（収益の閉環）が確立されているにもかかわらず、下流工程にはそれが未だ実現していないという点です。\nNVIDIAが稼ぐのはクラウドベンダーからの資金であり、そのクラウドベンダーは設備投資（CAPEX）を行う。この設備投資は、最終的には企業顧客と消費者が負担することになる。もしエンドユーザーからの支払いが不十分であったり、AIが企業に十分なコスト削減や効率化をもたらさない場合、サプライチェーンの最後で誰かが減価償却費とバリュエーション（評価）の圧力を背負うことになるだろう。\nこの時点では、株価がすぐに暴落するとは限りませんが、市場はもっと難しい問いを投げかけ始めます。それは、「これらのGPUからのリターン率はどこにあるのか？」という問いです。\n調査レポートと機関の見解：「崩壊（暴落）の可能性」について 私が見つけた機関の見解は一貫していませんが、3つのタイプに分類できます。\n最初のタイプは「慎重派」です。ゴールドマン・サックスが2024年に発表した生成AIに関するレポートのタイトルは非常に直接的で、大まかに言って「投下しすぎるが、収益が少なすぎる」という内容でした。その本質的な指摘は、AIが無用だということではなく、「短期的に行う巨額の設備投資が十分なリターンを生み出せるのか」という点に疑問を呈しているのです。\n第二のタイプは穏健派です。Sequoia社は「AI収益のギャップ」という問題を指摘しました。エコシステム全体がGPUへの投資を支えるためには、非常に大きなエンドユーザー（端末）収益を生み出す必要があり、現在のアプリケーション層の収益だけでは、インフラストラクチャへの投資に追いついていません。これはAIに対する悲観論ではなく、ビジネスのクローズドループがまだ完成していないという注意喚起なのです。\n第3のカテゴリは楽観論者です。彼らは、AIもクラウドコンピューティングと同様に、まず何年ものインフラ投資を経験し、その後ゆっくりとソフトウェアやサービスの収益を生み出すだろうと考えています。この判断にも根拠があると言えます。畢竟、クラウドコンピューティングの初期段階でも資金浪費だと疑問視された経緯がありますから。\n問題は、株式市場が価格を確定するのを10年間待っているわけではない点です。早期に買いすぎることもあれば、逆に早期に（過度な）売り（暴落）も起こるからです。\n私の判断としては：\n短期的に必ずしも崩れるわけではありません。なぜなら、設備投資は続いており、受注も残っているからです。AI競争も止まっていません。マイクロソフト、Google、Amazon、Meta、Oracleといった企業が引き続きデータセンターを拡張する限り、上流のハードウェア会社の収入は支えられています。\nしかし、途中で厳しいROIレビューを受けることになるでしょう。トリガーポイントは以下の通りです：\nクラウドベンダーによるAI設備投資（Capex）の減速； 大規模モデルの価格競争により、推論収益がコストを十分にカバーできていない状況； 企業のAIプロジェクトにおいて、パイロット段階から本番運用へ移行する際の失敗率が高すぎること； 特定の上流工程での在庫の高水準な積み増し； 金利やマクロ環境の変化により、市場が長期的な成長ストーリーに対して高い評価額を付与することに消極的になっている点。 これはAI技術の失敗を意味するものではありません。インターネットバブルが崩壊した後も、インターネット自体は消えませんでした。本当に失われたのは、評価額の中に早期に織り込まれすぎた部分です。\nどの指標に注目すべきですか？ もし今後もこの相場の動向を観察し続けるのであれば、モデル発表会だけに目を向けるのはやめておきます。\nより有用なのはいくつかの指標です：\n特に最後のもの（点）です。AIは収益だけを見るのではなく、減価償却も見る必要があります。\nGPUの購入も、データセンターの構築も無料ではありません。AIサービスの収益成長が非常に好調であっても、フリーキャッシュフローが悪化し続けるようであれば、市場はいずれ再評価を下すでしょう。\n結論 このAI株の上昇は、最初にChatGPTがもたらした技術的な衝撃を買い、続いてNvidiaの受注に目を向け、さらにその後はAIエコシステム全体へと広がり、最終的にはストレージ、メモリ、電力、そしてエンタープライズソフトウェアへと波及しています。\n閃迪の急騰は単なる孤立した出来事ではありません。これは、AIストレージ需要、NANDサイクルの反転、独立上場、そして低時価総額による弾力性（レバレッジ）といった複数の交差点に位置しているため、上昇率は多くの巨大企業よりも過剰になる可能性が高いのです。\nしかし、このような相場においては、「AI需要が無制限」という側面だけを見ていてはいけません。資本市場は、長期的なトレンドを一気に株価に織り込むことを好み、また、その実現速度が不十分であると判断した際には、逆方向への修正を行うのが最も得意です。\nAIが偽物である可能性は非常に低いです。問題なのは、現在の多くの株価には、すでに「AIがすぐに非常に利益性が高く、安定しており、大規模なビジネスになる」という前提が織り込まれていることです。\nこのデフォルト値が、後で最も問題が出やすい箇所だ。\n参考文献 作成メモ 元のプロンプト ライティングのアプローチ概要 拡張ブレインストーミング 方面 取り扱い 電力、原発、データセンター REITs 関連性はあるが、記事を別の主要なテーマに膨らませてしまうため、本文では軽く触れるのみとする。 中国のAI産業チェーン 政策、為替レート、A株（中国A株）のバリュエーション体系の影響が大きい上、今回は分析範囲に含めない。 OpenAI、Anthropic の非上場估価 バブル的な感情を説明できるが、データは上場企業ほど検証しにくいため、深掘りしない。 インターネットバブルとの ","date":"2026-05-08","language":"ja","permalink":"https://ttf248.life/ja/p/ai-stock-rally-since-chatgpt/","tags":["AI霊感衝突坊","ai","投資 (tōshi)","半導体","ニューヨーク証券取引所（NYSE）/ 株式市場"],"title":"AI株が天に昇った後で","year":"2026"},{"categories":["メモ書き雑感"],"content":"以前は、スマートフォンが512GBや1TBにまでなるのを見ると、少し贅沢すぎる（または「もったいない」）なと感じていました。\nこの容量って、普通のノートパソコンと比べても遜色ないよね。スマホの中には一体何があって、こんなに場所を取っているんだろう？以前の私の理解ではもっとシンプルだったんだけど。写真や動画、WeChatのデータなんかは定期的にパソコンにバックアップして、スマホを掃除するだけで十分なんじゃない？\n後になって、この判断が実際には非常に強い個人的な習慣／傾向に影響されていたことに気づきました。\nデスクトップPCを持っているので、資料を整理する際にはパソコンを使うのが習慣です。写真は年やイベントごとにフォルダ分けしてエクスポートします。微信内の重要なファイルは別途保存し、スマホの容量が足りなくなったら古いデータを移動させます。この一連のプロセスは、パソコンが元々私の作業の中心地（ワークスペース）だから、私にとっては手間ではありません。\nしかし、多くのZ世代（または2000年代生まれ）や、上の世代の高齢者にとって、コンピューターはもはや単なる資料センターではありません。\n彼らがコンピューターが使えないわけではなく、むしろコンピューターを中心に資料管理の習慣を築く必要がないということです。写真は携帯で撮り、チャット履歴も携帯にあります。支払い証明書、スクリーンショット、身分証明書の写真、子供のビデオ、旅行の写真なども全て携帯に入っています。このプロセスにおいて、コンピューターは逆に外部機器のような存在です。たまにファイルを印刷したり、複雑なフォームに記入したり、大きなファイルを送ったりする程度です。\nもしデータの取り込み、使用、そして想起がすべてスマートフォン上で行われるのであれば、スマートフォンのストレージはもはや「一時キャッシュ」としてのみ理解することはできなくなっている。\nPC管理用アルバムの賢さが落ちてきた 以前はコンピューターで写真を管理することに利点がありました。それは、画面が大きく、ファイルシステムが整理されており、コピー＆ペーストも便利だったという点です。しかし欠点も非常に明白であり、すべての秩序を人自身が維持する必要がありました。\nどこに、いつ出かけたか自分で覚えて、フォルダを自前で作り、重複写真を削除し、さらにはWeChatの画像と相簿内の写真を分別しなければならない。しかし時間が経つにつれて、ほとんどの人は結局「スマホのバックアップ」「スマホのバックアップ2」「古いスマホのバックアップ」「微信写真」といったいくつかの巨大なディレクトリしか持てなくなるだけだ。\n近年、スマートフォンギャラリーがむしろこの問題を解決するために取り組んでいます。\nAppleは、自身のPhotoのプライバシー説明において、この写真アプリがオンデバイス機械学習を使用して写真や動画を整理し、「思い出」「人物とペットのアルバム」「厳選された写真」といった機能をサポートすることを明確に述べています。一方Googleフォトもまた、Geminiをアルバム検索に組み込み、ユーザーが自然言語を使って自分の写真ライブラリについて質問できるようにしています。\nこれらの機能単体で見ると、それほど驚くものではありませんが、組み合わせてみると、全く別のデータ管理方式となります。ユーザーはフォルダ構造を事前に明確にする必要はなく、写真がどのディレクトリにあるかを知る必要もありません。「あの時の海岸に行った」「子供が初めて自転車に乗った」「去年の春節に誰と食事をした」といった記憶を思い出すだけで、システムが関連データを引き出してくれるのです。\nこのインターフェースは完璧とは限りません。AI検索は遅かったり、間違えたりする可能性があり、プライバシー上の懸念も伴います。しかし、従来のコンピューターのアルバムソフトウェアよりも、すでに日常的な利用により近いものです。一般ユーザーが求めているのは、ファイルシステムを完全に整頓することではなく、必要なときに「見つけられる」ことです。\n大規模な能力は、怠惰によるものではなく、経路（アプローチ）の変化によるもの この観点から見ると、512GBのスマートフォンは、「整理を怠った」結果ではなく、資料管理のプロセスが変化したことによる自然な選択なのです。\n以前は、スマートフォンを単なる撮影デバイスとみなし、コンピューターをデータ倉庫として捉えるのが一般的でした。しかし現在では、多くの人にとってスマートフォンは、撮影設備であるだけでなく、データの保管庫であり、情報検索の入り口でもあります。そのため、スマートフォン内のデータがより網羅的（かんらてき）であればあるほど、「アルバムAI」「システム検索」「チャット履歴検索」といった機能の有用性が高まってくるのです。\n写真がすべてPCのハードドライブに書き出されてしまうと、スマートフォンのアルバムに残るのは直近数か月のデータだけになってしまいます。システムはもちろん思い出や人物の認識はできますが、それは断片的な人生の一部を見るにすぎません。3年前にあった集まりの写真を探したいとしても、それも助けてくれることはありません。\nこれも以前私が見落としていた点です。私が資料を定期的に「クリーンアップして移動させる（アーカイブする）」のは、その後にどこに置くのか、そして将来どうやって取り出すのかを知っているからです。コンピューターに不慣れな方にとって、「整理して移動させる」ことは、後で二度と開かない場所に紛失することと同じになってしまいます。これは物理的な紛失ではなく、利用できなくなる（アクセス不能になる）という喪失を意味します。\nスマートフォンメーカーが容量を増やす背景には、単に4Kや8K動画の撮影のためだけでなく、ゲームのインストールファイルがどんどん大きくなっているからだけではありません。iPhone 17 Pro Max はすでに2TBを提供し、Galaxy S25 Ultra も1TBバージョンがあります。これは少なくとも一つのことを示しています。それは、スマートフォンメーカーが、ユーザーがより多くの個人データを長期的に保存することを前提としているということです。\nこの傾向は若者に限っているわけではありません。\n高齢者がより典型的な傾向があります。多くの高齢者は、写真を定期的にバックアップしたり、WeChatのファイルをエクスポートしたりすることさえありません。彼らの資料管理方法は、「削除しない」というものです。これは粗雑に聞こえるかもしれませんが、実際の利用という点から見ると、実は最も安定した方法なのです。スマートフォンが残っていれば写真はそこにあり、チャット履歴が削除\nもちろん、これは非専門的で安全性が低く、バックアップに対する意識が不足していると批判することはできます。しかし彼らにとって、コンピューター、データケーブル、ディレクトリ構造、定期的なメンテナンスを必要とする一連のソリューションは、単に大容量のスマートフォンを購入するよりも実際の成功率が低い可能性があります。\n本質的な問題は容量ではなく、移行とバックアップである スマートフォンの容量が大きいほど良いということではありません。\nスマートフォンが資料センターとして機能することには、避けられない2つの問題があります。それは、「機種変更に伴うデータ移行」、そして「デバイスの紛失」です。容量が大きいほど、内部に蓄積されるデータが多くなるため、単一障害点のリスクも大きくなります。以前は携帯電話を紛失した場合、主に連絡先や最近の写真程度でしたが、今では数年分の家族写真アルバム、チャット履歴、そして生活の証拠（記録）が失われる可能性があります。\nしたがって、大容量スマートフォンが解決するのは「容量不足」の問題であり、「データの長期的な信頼性」という問題は解決しません。\n真に合理的な状態とは、すべての人をPCに戻してデータを管理することを強制することではなく、スマートフォンがすでに多くの人にとっての主要なデータ保管庫であることを認め、その現実に基づいたバックアップを行うことです。例えば、自動クラウドバックアップや家族メンバーによる移行支援、重要なアルバムのみの個別同期、あるいは少なくとも機種変更時に写真やチャット履歴が本当に移行されたかを確認することなどです。\nスマートフォン（携帯電話）の容量に対する考えが変わりました。\n安定したPCのワークフローを持つ人であれば、256GBまたは512GBで十分な場合があるでしょう。しかし、その人の生活資料が基本的に携帯電話に保存されている場合、512GBは決して過剰ではありません。これが提供しているのは単なる空き容量ではなく、「掃除の手間を減らし、データ移行の手間を減らし、そして『二度と開かない』といったPCのフォルダにデータをしまい込む回数を減らす」という価値です。\n多くの人にとって、スマートフォンはもはやコンピューターの付属品ではありません。\nスマートフォンが彼らのパソコンです。\n参考資料 iPhone 17 Proおよび17 Pro Max - 技術仕様 - Apple Galaxy S25 Ultra | 特徴とハイライト | Samsung US 写真とプライバシー - Apple 写真に尋ねる：Googleフォトの新AI機能 (Ask Photos) 執筆上の注記 元のプロンプト スマートフォンのストレージはますます容量が大きくなっています。以前は不要だと感じていましたし、512GBという容量\n執筆の考え方（アウトライン）要約 本記事の核心的な判断は、スマートフォンの大容量の価値を「一時的なキャッシュ」として捉えることはできなくなった点にある。 本文では、認識の違いをデータ管理のエントリーポイントの変化に落とし込んでいる：筆者はPCを使う習慣があるが、多くのユーザーはすでにスマートフォンをメインの資料庫と考えている。 アルバムAIは、事実を裏付けるためのサポートとしてのみ使用され、スマートフォンAI機能のレビューへと発展していない。 本記事では、クラウドドライブ、NAS、具体的な機種購入推奨といった脇筋となる部分を意図的に抑え、単なるソリューションリストになるのを避けている。 最後に判断を移行とバックアップのリスクに戻している：容量は保存の問題を解決するが、長期的な信頼性の問題は解決しない。 ","date":"2026-05-06","language":"ja","permalink":"https://ttf248.life/ja/p/phone-storage-is-not-too-big/","tags":["AI霊感衝突坊","ai","スマートフォン","資料管理","アルバム"],"title":"512GBあれば、スマホとしては十分（または「かなり」）大容量ですね。","year":"2026"},{"categories":["魚の7秒間の見聞"],"content":"今年のメーデー期間（五一档）の映画の興行収入は振るわず、もはや「どの作品が大ヒットしなかったか」という問題ではありません。\n経済の低迷だけを語れば、もちろん一部は説明できます。誰もが以前のような金銭的な余裕がなくなり、支出がより慎重になっているのは現実です。しかし、全ての問題を経済のせいにするのは、業界をごまかしている（擁護している）だけだと私は思います。観客が突然映画を嫌いになったわけではなく、むしろ度重なる「過剰な宣伝」「強すぎる上映スケジュール」、そして「内容の薄さ」という組み合わせによって、忍耐力が消耗されてきたのです。\nまずデータをみる。\n年 期間口径 総興行収入 動員数 備考 2021 5月1日〜5月5日 16.68億元 4,410.54万 国家映画局の基準で、当時「五一」の記録を樹立 2022 4月30日〜5月4日 2.97億元 865.8万 感染症の影響による異常な低水準 2023 4月29日〜5月3日 15.19億元 3,763万 パンデミック前後の高水準に回復 2024 5月1日〜5月5日 15.27億元 3,777万 2023年とほぼ横ばい 2025 5月1日〜5月5日 7 2022年は、映画市場が崩壊したことを直接証明するものとは言えません。その年はパンデミックと映画館の営業制限があったため、異常値です。本当に気になりますのは、2024年から2026年までのこの推移（またはこの線）です。\n2023年と2024年の連続した2年間は、約15億を記録し、観客動員数も3,700万以上でした。しかし、2025年になると興行収入は急落して7億4,700万にまで落ち込み、観客動員数はわずか1,889.5万にとどまりました。一方、2026年は5月4日夜現在すでに6億6,000万を超えており、最終日まで増加が見込まれますが、たとえ最終的に多少積み上がったとしても、2023年や2024年の水準に戻るのは難しいでしょう。\nこれは通常の変動ではなく、明確な断層（ブレイク）です。\nさらに困ったことに、2026年の「五一」期間初日の平均チケット価格は、約36.9元まで下落し、過去4年間\n以前は、ひどな映画がなかったわけではない。\n過去数年間、観客が駄作に金を払ったわけではないのですが、ただあの頃は映画が休暇消費として捉えられており、ある種の慣性がありました。春節、国慶節、五一といった時期には、朋友圈（SNS）で誰かが見ていたり、短動画プラットフォームが宣伝したり、映画館のスケジュールは埋まり、マーケティングの盛り上がりが至る所にありました。多くの人がチケットを購入したのは、本当に映画に感動したからではなく、「みんなが見ているみたいだから」という理由によるものでした。\nこのビジネスモデルは短期間で非常に有効です。 (Alternative: この商売は短期的にとても効果があります。)\n知名度の高いスターが初回の予約販売を牽引し、エモー\nしかし、この手法には副作用があります。それは、観客が映画館に対して抱いている信頼を使い果たしてしまうことです。\n『満江紅』や『熱辣滾燙』のような作品は、今でも追いつくことにあまり興味が湧かない。商業的には成功していないと言っているわけではないし、もちろん成功していることは理解している。問題なのは、ある映画の公的な議論がますますマーケティング戦術のようになり、観客が自分が見ているものが「作品そのもの」であると信じることが難しくなってきている点だ。ネット上では、いくつかの映画の宣伝費用が制作費用を上回っているという人がよく言うが、この主張について信頼できる公開財務データを見つけられないため、「事実」として断定することはできない。しかし、観客としての肌感覚から言えるのは、誰もが「お金が映画を作るためではなく、皆に『絶対に見なければならない』と思わせるため」に使われているのではないかと疑い始めているということだ。\nこのような疑念が一度形成されてしまうと、次回のトレンド（ホット検索）だけで払拭するのは難しいです。\n以前は、みんなが「ひどい映画だ」と罵った後でも、次の公開作品には行きたかった。しかし、今は違う。ショート動画、ドラマ、ゲーム、コンサート、旅行、キャンプ、シティウォークなど、休日の選択肢が多すぎる。映画が「映画館で観るべき理由」を提供できなければ、自然にその場所から排除されてしまうだろう。\n経済の減速は、単なる加速装置ではなく、唯一の原因ではない。\nお金が厳しい時、人は消費を完全にやめるのではなく、支出の優先順位を組み直します。以前は、映画チケットに飲み物やポップコーンを加えて100〜200元（またはそれ相当額）使うのは許容範囲でした。しかし、今同じ金額なら、食事をしたり、ゲームを買ったり、どこかへ出かけたりできます。もし、映画が未だに「話題性」「集客力」、そして感情的な拘束力に頼ってこのお金を勝ち取ろうとするならば、観客は当然ながらよりためらうようになるでしょう。\nさらに厄介なのは、過去数年間の映画市場が観客に「防御的な消費心理」を抱かせてしまった点です。上映前に過剰に宣伝されるほど、「待ってから判断しよう」と考え、ホット検索が密集しているほど「まるで買い付けられたもの」と感じ、初日興行収入が誇張されているほど、それが本当に良い作品である証拠だと受け入れなくなりました。観客は理解していないわけではなく、単に以前はそこまで気にするのが面倒だっただけなのです。\nいい加減、勘定をつけていきますね。\n「五一档」の崩壊は、皆が突然映画館を裏切ったからではなく、それまで映画館が提供してきた「確実性（確定性）」が失われたことが原因だ。かつてチケットを買うことは、まるで「休暇という儀式」を買うようだったが、今はより「リスク判断」に近い。映画があまり良くない上に、お金は無くなり、時間は消え、さらに2時間の気まずさを我慢しなければならないのだ。\nですから、私はこれが悪いことだとは思いません。\n短期的には、映画館も業界全体も苦戦しています。長期的に見ると、観客が盲目的な追随を減らし、市場の\n問題は、業界がこれを認めようとするかどうかにあります。\n今後も経済、チケット料金、天候、ショート動画のせいにしたり、人気スターやマーケティング的な言葉で作品を埋めようとするなら、ゴールデンウィーク（五一档）はほんの序章にすぎない。観客は「映画館から離れる」と正式に宣言しない。ただ、繰り返しチケットを買わなくなるだけだ。\nこれは、罵声（ばせい）より恐ろしいです。\n参考文献 新華社：2021年ゴールデンウィーク映画興行収入16.68億元 毎日経済網：2022年ゴールデンウィーク総興行収入2.97億元 国家映画局：我が国2023年ゴールデンウィーク映画興行収入は15.19億元に達する 国家映画局：2024年ゴールデンウィーク映画興行収入は15.27億元に達する 中国映画報：マオヤン研究院が『2025年ゴールデンウィークデータインサイト』を発表 [新浪財経：5月4日20時30分時点、2026年ゴールデンウィーク総興行収入は6. 執筆上の注記 元のプロンプト 執筆の構成案の概要 ","date":"2026-05-05","language":"ja","permalink":"https://ttf248.life/ja/p/wuyi-box-office-trust-collapse/","tags":["AI霊感衝突坊","ゴールデンウィーク","映画の興行収入","消費"],"title":"「五一」の落ちたのは興行収入ではなく、信頼だ。","year":"2026"},{"categories":["メモ書き雑感"],"content":"改めてこの件を精査したところ、結論は実に明白です。問題の本質は、「ファーウェイがTSMCに頼れない」ということではなく、アメリカの規制によってコンプライアンスを維持できる道筋がほぼ存在しないという点にあります。一方、シャオミがTSMCを利用できるのは、そもそもファーウェイと同じ分類の輸出管理リストに含まれていないからです。\n華為（ファーウェイ）はなぜ制約を受けているのか 华为は、まず2019年5月15日に米国商務省のエンティティリストに加えられました。このリストの意味は非常に明確で、同社へ米国技術を輸出するには許可が必要であり、その許可は拒否される可能性もあります。\nつまり、華為技術が直面しているのは単なる「チップ購入の禁止」という問題ではなく、設計、製造、受託生産（ファウンドリ）、設備、ソフトウェアに至るまで、サプライチェーン全体にわたって制約を課されているということです。\nこれは次のように理解していただけます。華為技術にとっての問題は、「工場を見つけられるか否か」という点だけでなく、「その工場が実際に仕事を受注する勇気があるのか」、そして「受注したとしてもアメリカの規則に違反しないか」という点が重要なのです。\nXiaomiはなぜ今でもTSMCと協業（提携）できるのか XiaomiとHuaweiは同じ扱いではありません。XiaomiはCommerce Departmentのエンティティリスト（Entity List）に掲載されていないため、Huaweiのような「受託生産メーカーが単に注文を一つ受けただけで規制に抵触する」といった状態にはなっていません。\n多くの人が2021年のXiaomi（小米）とHuawei（華為\nより重要なのは、米国が近年ターゲットを非常に的確にしており、規制の対象としているのは、すべての中国消費電子製品ではなく、ハイエンドなAIチップ、スーパーコンピューティング、および関連機器である点です。BIS（国際決済銀行）は、2023年10月17日にルールを更新する際に、これを明確に記述しています。重点は「advanced computing semiconductors」「semiconductor manufacturing equipment」そして「supercomputing items」であり、その核心的な目標は軍事AI能力と軍民融合のリスクにあります。\nこれにより、XiaomiのXRING O1がまだTSMC（台湾積体電路製造）を利用できる理由が説明できます。これは消費電子エレクトロニクスチップであり、監視対象となっているAIトレーニングチップとは異なります。顧客が制裁リストに加えられておらず、かつチップ仕様がそのレッドラインに抵触しない限り、TSMCにはコンプライアンス上の余地があるのです。\nまだTSMCに受託製造を依頼する人はいるのだろうか はい、そして数多くあります。公開された報道によると、2024年にはMetaXやEnflameのような中国のAIチップ企業が、TSMCの生産能力を継続的に確保するため、設計を格下げしてから審査に提出しなければならなかったと取り上げられています。この詳細は問題点を明確に示しています。アメリカが現在阻止しているのは、「中国製品は海外ファウンドリを利用できない」ということではなく、「ハイエンドなAIチップを簡単に迂回することはできない」ということです。\n言い換えれば、本当に重点的に制裁（あるいは制限）を受けているのはAIチップの領域であり、全ての中華企業や全ての中国製品ではありません。コンシューマー向けのSoCはまだ余地があるかもしれませんが、ハイエンドなAIアクセラレータカードとトレーニングチップはますます困難になっています。\n華為のAIチップはどのようにして開発されたのか 今回、この一連の経緯（または「関連情報」）が明らかになったのは、華為自身が公的に認めたからではなく、分解調査によるものです。\n2024年10月、ロイター通信は、TechInsightsがファーウェイの製品を分解したところ、TSMC製と思われるチップを発見し、その後TSMCも米国当局に通知したと報じました。さらにロイター通信は続報として、TSMCが自社製造のチップがファーウェイのAIプロセッサ内で発見されたことを受け、中国の半導体設計会社Sophgoへの出荷を停止したと報道しました。\nこのラインが最終的に対応する製品は、HuaweiのAscend 910Bです。つまり、外部が組み立ててきたのは、スマートフォン向けのチップではなく、HuaweiのAIプロセッサなのです。厄介な点は、「どこのファウンドリを使ったか」という点だけではなく、アメリカにとって最も機密性の高い種類のチップに分類されてしまったことにあります。\n私自身の判断 これをしばらく観察していると、アメリカのアプローチは均等に力を分散させるのではなく、ますます「点穴（ピンポイント）」のように特定の要所に集中していることが分かります。ファーウェイがモデルケースであり、AIチップが主戦場であり、ファウンドリ（代工工場）は単なる実行段階の役割にとどまっています。\n小米がTSMCを利用できることは、米国が中国に対するチップ規制を緩和したことを意味するわけではありません。単に、より狭く、そしてより厳格なレッドラインを踏み越えていないだけです。華為（Huawei）が進まないのは、「華為が大きいから」という理由ではなく、既に輸出管理の的の中心（ターゲット）に押し込められており、回避することができないからです。\n参考文献 執筆メモ 元のプロンプト 関連政府資料を調査し、なぜファーウェイのチップはTSMCで製造できないのか、それに対しシャオミの玄戒（Xuanjie）チップはTSMCが製造できるのか、そしてシャオミはアメリカによる封鎖を受けていないのかを説明してください。シャオミ以外に、他の国内企業がTSMCを利用して受託製造を行っている事例はありますか？ 現在、AIチップのロックダウン（供給制限）に焦点を当てているようですが、ファーウェイのAIチップの受託製造に関する詳細を解説してください。また、それが今後どのように発覚するのか、そして対象となる製品は何でしょうか？\n執筆の着想・要約 本記事は、「なぜHuaweiが制約を受け、Xiaomiは進めるのか」というルールの差異に焦点を当てています。 Huaweiの部分では、歴史的なタイムラインを強調しています：2019年に製品名が挙げられ、2020年になんか代工チェーンが付け加えられています。 Xiaomiの部分では、個別に明確化されています：投資制限に直面したことはありますが、Huaweiのような輸出封鎖ではありません。 本稿は、完全な米中技術戦争の総説として展開することは避け、TSMCの代工と直接関連する部分のみを残しています。 HuaweiのAIチップの開発過程は、「分解 - 遡及 - 代工チェーン」という一連の流れとして描かれています。 結びは現実的な判断に戻っています：現在、重点的に監視されているのは、すべての中国チップではなく、ハイエンドのAIチップです。 ","date":"2026-05-04","language":"ja","permalink":"https://ttf248.life/ja/p/huawei-xiaomi-tsmc/","tags":["AI霊感衝突坊","ai","華為 (Huawei)","小米 (Xiǎomǐ)","チップ","輸出管理"],"title":"華為が追い詰められる中、シャオミはTSMCと提携できるのか","year":"2026"},{"categories":["魚の7秒間の見聞"],"content":"5月1日以降、一般の人がドローンを購入する際、「単に空を飛ぶカメラ」という感覚ではなくなってきた。\nそれは、身元（アイデンティティ）、軌跡（トラジェクトリ）、承認の関係を持つフライトターミナルのようなものです。この変化がDJIに与える影響は、単に数台の機体を売れなくなるというレベルではなく、消費者向けドローンの「製品定義」そのものが書き換えられてしまったということです。DJIができることは実は多くありません。少なくとも北京のような厳しく管理された地域では、まず流通チャネルを回収し、その後、コンプライアンス機能を製品およびサービスプロセスに組み込むしかできないのです。\n今回の変更は単一のファイルではありません 混同しやすいのは、二つのレベル（層）にわたる政策です。\n全国レベルでは、2026年5月1日から強制的な国家標準が2つ実施されます。一つは「民間無人航空機の実名登録と活性化要件」であり、「誰が飛べるか」という問題を解決します。ドローンは飛行前に実名登録を完了し、システムによる検証を経て初めて飛行能力を獲得できます。もう一つは「民間無人航空機システム運行識別規格」であり、「誰が飛ばしているか」という問題を解決します。民航局の解釈によると、運行識別送信機能を備えていない民間ドローンは、2026年5月1日以降、運用してはなりません。\nもはや、以前のように実名登録のQRコードを貼るだけという単純な話ではありません。以前は多くのユーザーが「購入したら一度登録するだけで、勝手に飛ばないようにすれば十分だ」と直感的に考えていました。しかし、今の管理ロジックはさらに高度になり、機械がアクティベートできるか、飛行中に識別されるか、さらには製造メーカーがインターフェースやアップグレード案を持っているかといった要素まで、すべてが製品の一部となってきています。\n北京市レベルでは、より直接的です。\n『北京市無人航空機管理規定』も、2026年5月1日に施行されます。北京は市全体の行政区域を無人航空機管制空域として指定し、すべての屋外飛行活動には申請が必要となります。さらに重要なのは、販売、輸送、携行（持ち運び）、保管がすべて規制対象となる点です。具体的には、北京市行政区域内の法人や個人に対し、無人航空機とその主要部品の販売・賃貸は禁止され、また、ドローンおよび主要部品を北京に持ち込むための輸送や携行も禁止されます。既存の無人航空機について、実名登録と情報確認が完了しているケースについては別途規定されています。\nつまり、外部から見た「大疆が取り扱いを停止した」という問題の核心は、全国市場全体で突然売れなくなったことではなく、北京という特殊な市場のみが個別的に封鎖された点にあります。この違いが非常に重要です。全国的な政策が追跡可能性（トレーサビリティ）に関するものであるのに対し、北京の政策が実施しているのは高強度の空間的規制なのです。\n大疆に与える影響はどこか DJIが最も直接的な影響を及ぼしたのは、北京の消費市場における通常の小売シーンが実質的に失われたことです。\n界面新聞によると、4月29日午後以降、北京のDJI店舗ではドローンの販売がなくなり、オンラインプラットフォームからも北京地域への出荷が停止します。今後、北京のユーザーが修理を必要とする場合、店舗は修理の責任を負わず、他の省や市からのセルフ発送による修理、または認定サービスセンターでの交換が必要となります。この変化は、消費電子機器の企業にとって非常に厄介な問題であり、単に一つの都市の売上減少にとどまらず、顧客体験プロセスにも影響を与えるからです。\nドローンはスマートフォンとは違います。スマートフォンは北京で買えなくても、他の場所で買って持って帰って同じように使えます。しかし、ドローンは購入、持ち運び、飛行、保管、修理のいずれにおいても、同一の管制ロジックに触れる可能性があります。北京のユーザーであっても、購買意欲があっても「買った後、持ち帰れるか」「飛ばせるか」「壊れたらどう直すか」という疑問によって断念してしまうでしょう。\n第二个影响は、製品コンプライアンスコストが上昇し続けることです。\nこれらのことは、ユーザーには「機能の強化」だと感じられないでしょう。彼らはただ単に面倒（手間がかかる）だと感じるだけです。しかし、メーカーはこれを実装せざるを得ず、うまくできなければアフターサポートの問題になってしまいます。\n3つ目の影響は、DJI（大疆）のコンシューマー向けのエッジが縮小されるため、より業界レベルの能力が重要になることです。\n北京のような場所では、個人によるドローン撮影の需要はかなり抑えられます。実際にプロセスを完遂できるのは、より明確な主体と用途を持つ緊急対応、測量、巡検、研究開発、公共安全、映画・テレビ撮影などのニーズが主です。「安くて楽しい」ことではなく、「任務の信頼性」「承認資料の完全性」「データの追跡可能性」「サービスの実現可能性（ローカライズ）」を追求します。\nこれはDJIにとって必ずしもすべてが悪いわけではありません。DJIには元々産業用途の製品ラインがあり、農業、エネルギー、測量などのシーンもあります。しかし、一般消費者向け製品の想像空間は狭まり、以前のような「普通の人（一般人）がMiniを一台買って旅行中に気軽に飛ばす」という物語は、厳しく規制された都市ではますます難しくなっていくでしょう。\n大疆（DJI）はどのように対処したのか 短期的に見ると、DJIの対応はかなり現実的です：北京チャネルでの取り扱い停止、オンラインでの出荷制限、アフターサービスを広域な修理送付または正規サービスセンターへの移行に切り替え、公的な資料では引き続きユーザーに対して実名登録と飛行申請を行うよう促しています。\nこれは非常に洗練された対応とは言えませんが、現実的な対策ではあります。地方の規定により、\nDJIの公式サポートページでは、実は早くからユーザーをUOMシステムへ誘導しています。例えば、実名登録ページでは「DJIドローンユーザーは早めに登録を完了してください」と促し、DJI Fly内で実名制の状態を確認できる旨を説明しています。飛行報告のページでも、UOMへの申請プロセス、離陸前レポート、飛行終了後の上報といった手順が非常に細かく記載されています。つまり、DJIが規制に直面し始めたのが5月1日というわけではなく、単にこの日が来たことで、元々「注意喚起」程度の情報であったものが、製品を継続して使用できるかどうかの「ハードな制約条件」になり始めただけなのです。\n私からすると、そここそがDJI社にとって最も課題となる点だと思います。\n(Alternative options depending on nuance:\nFocusing on a vulnerability/pitfall: 私が思うに、こここそがDJI社の一番の弱点（ネック）ですね。 More neutral/academic: ここがDJI社にとって懸念される最大のポイントだと感じます。) 消費電子機器メーカーが最も懸念しているのがこの点です。なぜなら、こうした種類のコストはスペック（仕様）表に反映させるのが難しく、また、ユーザーが対価を払ってでも購入したいセールスポイントになりにくいからです。\n今後のドローンはどう進化するか ドローンは、今後たぶん2つの道に分かれるでしょう。\n一つは、よりツールに近いものです。特定のタスクをサポートし、飛行前には申請があり、飛行中には認識が行われ、飛行後には記録が残ります。これは、巡視点検、測量、農業、消防、物流、都市管理といった様々なシーンに導入されます。ここで重要となるのは、派手な映像技術ではなく、プロセスの信頼性、責任の明確化、そしてデータの閉ループ（完結）です。低空経済が真に発展するためには、市民の皆さんが都心の公園でなんとなく飛び立つような形ではなく、この道筋に頼るべきでしょう。\nもう一つは、規制がより厳しくなる「撮影用のおもちゃ」のような側面です。コンシューマー向けの空中撮影自体は存在し続けますが、飛行可能エリアや観光地のルール、地方自治体の政策、プラットフォームへの届け出など、様々な要因にますます依存するでしょう。今後ドローンを購入する人は、バッテリー持続時間や画質、重量といったスペックだけを見るのではなく、車を買う時と同じように、使用シーンをまず気にする必要が出てくるかもしれません。\nこの件を単に「DJIへの抑圧だ」と単純化して理解することには、あまり同意できません。北京の規制は確かに厳しく、一般消費者にとっても非常に使いにくい状況です。\nしかし、規制当局の観点から見ると、ドローンとカメラの最大の違いは、「公の空域に入るかどうか」という点にあります。\nそれが飛行でき、カメラを搭載でき、塀や道路といった障害物を越えることができる以上、単なる一般デジタル製品と同じ方法で永久的に管理することは不可能だと思います。\n真の問題は、規制が単なる禁止だけで成り立たないことだ。\nもし将来「飛ばせない、売れない、持ち込めない」といった状況が続いた場合、ドローン産業は少数の単位専用の設備に限定され、一般消費者や小規模なビジネスチームは市場から排除されてしまうでしょう。より良い発展方向性としては、コンプライアンスプロセスをさらに明確にすることが求められます。具体的には、「どの区域で飛行できるか」「申請にどれくらいの期間が必要か」「どのような理由で却下されたのか」「一時的な活動の届け出方法」「都市間を越えて持ち込む際の取り扱いはどうするか」「既存設備のアップグレード方法はどうか」「責任範囲はどのように定義されるのか」といった点が明確にされるべきです。\nDJIも、今後はこの方向に進むしかない。ハードウェアを小型化し、安定性や安全性を追求することは一部に過ぎない。より重要なのは、ID認証（身元識別）、ジオフェンス、運用報告、飛行申請、アフターサービスの流れといった要素を製品として確立することだ。聞くと面白みに欠けるかもしれないが、これはさらなる高画質化よりも重要かもしれない。\nドローンは自由な発展から制度による統制へと移行しており、この事態はすでに起こっています。DJIにとって、北京は単にこの現実を最初に世間に示した都市に過ぎません。一般ユーザーにとっては、ドローンを購入する前に「どこで合法的に飛ばせるか」と尋ねることが、将来的に「この機械は画質が良いか」と尋ねることよりも重要になるかもしれません。\n参考文献 執筆に関する注記 オリジナルプロンプト $blog-writer 中国内地5月1号无人机の新政が大疆に与える影響、大疆はいかに対応したのか？今後のドローンの発展はどうあるべきか？\n作成のアイデア概要 ","date":"2026-05-04","language":"ja","permalink":"https://ttf248.life/ja/p/drone-policy-dji-2026/","tags":["AI霊感衝突坊","ドローン","DJI","低空経済","政策動向 (せいさくどうこう)"],"title":"ドローンに関する新たな規制が施行され、DJIはまず北京で停滞した","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"今回の五粮液は、単なる業績の変動ではなく、白酒業界における従来の暗黙の了解そのものを覆しました。2025年の年次報告書によると、同社の年間売上高は405億2,900万元、親会社株主に帰属する当期純利益は89億5,400万元でした。しかし、さらに驚くべきなのは、同社が2025年の第1四半期、中間、第3四半期について、前期会計誤謬の訂正を行った点です。平たく言えば、2025年において非常に良く見えた多くのデータは、後に再計算されたということです。\nこの件に関する私の見解は非常に明確です。これは単なる「業績の暴落」ではなく、五糧液が市場に対して、「これまでチャネルを通じて在庫を積み上げたり、財務諸表によって将来的な潜在力を使い切ってきたやり方」は、もはや維持できなくなったと伝えているのです。\n以前のルールは何でしたか 白酒業界で以前最も重要なルールは、「最終的な販売額がいくらか」ではなく、「商品（モノ）を先に市場に出し、帳簿上の数字を良いものに見せること」でした。\nメーカーがディーラー（販売店）に商品を大量に渡すと、そのディーラーがさらに下位チャネルに流し込むことになります。すると、帳簿上では売上と利益を先に計上することが可能になります。卸値が安定しており、在庫が消化できる限り、誰もがこのロジックが成立していると見なします。見た目上はブランドが拡大しているように見えますが、実際には多くのケースで、チャネル側がメーカーの将来の売上を先取りして吸収している状況なのです。\nこのビジネスモデルが機能するためには、3つの前提条件が必要です。まず、業界自体がまだ拡大を続けており、ディーラーが伴走してくれること。次に、価格体系が安定しており、最終的に商品が滞りなく売れるという共通認識があることです。そして、ブランド力が十分強力でなければならず、在庫を抱えたとしてもすぐに危機（損失）にならないことが必要です。\nそのため、以前の白酒業界が最も恐れていたのは、売れないことではなく、価格の乱高下（値崩れ）でした。価格が不安定になると、販売店（ディーラー）の信頼は失われ、在庫は「帳簿上では立派に見える」状態から、「倉庫の中では目立つ問題」になってしまうのです。\nなぜ五糧液が（スポットライトを）浴びるのか 私としては、今回は五粮液が注目を集める（または、躍進する）と考えており、そこには少なくとも3つの理由があると思います。\n第一に、業界は本当に深い調整期に入りました。五糧液が年次の報告書で明確に述べているように、2025年の白酒（中国の蒸留酒）業界は全面的な深層調整の「深水区」に突入し、業界発展の構造が加速的に進化しています。同社自身も、市場の変化に積極的に対応し、流通チャネルの圧力を緩和し問題解決を支援することが必要であると認めています。\n第二に、旧来の基準が自滅し始めている。前期の会計誤謬訂正に関するお知らせで非常に明確に述べられていたように、当社は2025年のビジネスモデルを見直し（整理）、慎重性の原則に基づき、2025年の一部業務収益認識に関する計算を調整しました。つまり、過去にチャネルと収益計上のタイミングに頼って作成された「きれいな」レポートは、もはや真実として通用しなくなったということです。\n三つ目として、ガバナンスの圧力も増しています。年次報告書（アニュアルレポート）の要約には、会長が正常に職務を遂行できないため、取締役会審議を欠席したことが記されています。また、外部メディアは2月末にも、彼に対する拘束措置が取られたことを報じています。このような状況下では、企業が古い問題を引きずり続けることはますます不可能となり、かえって過去のしわ寄せを一気に白日の下に晒す方が容易になってきています。\nだから今回「テーブルをひっくり返す」のは、五糧液が急に態度が硬くなったからではなく、もはやそうしないわけにはいかないからだ。古いルールは限界に来ており、表面的な繁栄を維持し続けるだけでは、後の穴（問題）をさらに大きく引き延ばすことになる。\n決算発表前後の変化点 今回注目すべきは、特定の年度の総数ではなく、2025年にすでに開示された3つの期間（四半期）の報告書がまとめて書き直された点です。訂正公告によると、修正対象となるのは、2025年の第1四半期、半期、第3四半期の連結貸借対照表および連結損益計算書の一部項目であり、キャッシュフロー計算書には影響がないとのことです。\nまず、最も核となる収益と利益を見てみましょう。\n期間 元の売上収益 修正後の売上収益 元の親会社株主に帰属する純利益 修正後の親会社株主に帰属する純利益 2025 一季度 369.40 亿元 170.86 亿元 148.60 亿元 44.16 亿元 2025 半年度 527.71 亿元 235.10 亿元 194.92 亿元 46.24 亿元 2025 三季度 609.45 亿元 306.38 亿元 215.11 亿元 64.75 亿元 これらの数字は非常に目を引きます。売上高が3度にわたって半減に迫る下方修正となっており、利益の下方修正はさらに厳しくなっています。特に半期報告書では、親会社帰属純利益が194.92億元から直接46.24億元へと改定されており、まるでそれまでの好景気の感覚を完全に引き剥がされたかのようです。\n貸借対照表の変化を見ることで、これが単なる表記の修正ではないことがよりよく理解できるでしょう。\n期間 その他流動資産 その他流動負債 その他の未払費用など 未払法人税等 2025 一季度 11.82 亿元 -\u0026gt; 34.99 亿元 5.04 亿元 -\u0026gt; 190.93 亿元 115.30 亿元 -\u0026gt; 106.16 亿元 81.68 亿元 -\u0026gt; 56.83 亿元 2025 半年度 1.91 亿元 -\u0026gt; 81.87 亿元 4.23 亿元 -\u0026gt; 277.49 亿元 189.05 亿元 -\u0026gt; 私がより注目しているのは「その他の流動負債」の項目です。この項目が3つの開示時点で高い水準に引き上げられていることから、過去に何らかのものがチャネルや決済サイクルの中に抑え込まれていたことがわかります。言い換えれば、今回の問題は単なる利益の落ち込みではなく、収益認識と販売（または流通）\n今後の進め方 短期的に見ると、白酒業界はより厳しい状況になるでしょうが、同時により現実的になります。\n再構成された2025年通期および2026年第1四半期の実績を見る限り、レポートは以前より「地味」になるが、同時に悪化する可能性もある。\nより重要なのは、業界が「誰がどれだけ在庫を抱えられるか」という競争から、「本当に消費者の手に酒を届けられるか」という競争へと徐々にシフトしている点です。五糧液は年次報告書の中ですでにこの方向性を示しています。伝統的なチャネル、Eコマース（EC）、グループ購入、法人へのダイレクトセールス、エンドポイントの最適化、消費者育成など、全てがより直接的な販売動線（商品流通）を目指して進んでいるのです。\nこの道は容易ではありません。旧ルールが一たび撤廃されれば、ディーラーの在庫圧力はより顕著になり、メーカーの利益変動もさらに大きくなります。業界において、価格差や情報差を糧としてきた中間段階（または仲介業者）も、一層苦しく圧迫されることになるでしょう。\nより気にしている点 この件で真に注目すべきなのは、五糧液が今回どれだけ下落したかということではなく、「過去数年間の多くの華やかな数字は、実体的な消費に基づいて積み上げられたものではない」と認める勇気があるかどうかだ。\n白酒を成熟した業界と見なした場合、今後、根拠のない規模の拡大、在庫の強制的な抑制、そして不必要な価格引き上げという状況に再び陥る可能性は低いでしょう。業界の分化がさらに進む一方、トップブランドには一定の地位は残りますが、成長率は鈍化し、財務諸表も金融上の物語ではなく、実際のビジネスの実態を反映したものになるはずです。\n投資家にとって、これは純粋な悪材料ではありません。マイナス面としては、古い秩序に支えられていた高成長時代は基本的に戻らないということです。しかし、メリット（プラス点）なのは、今後決算書を見る際、少なくとも商品が流通倉庫にまた詰め込まれているのではないかと常に疑う必要がなくなることです。\n参考資料 宜賓五糧液股份有限公司 2025年度報告抄録 宜賓五糧液股份有限公司 2025年度報告全文 [宜賓五糧液股份有限公司 期前の会計誤謬更正に関する公告](https://static.cninfo.com.cn/finalpage/2026-04 作成時の注記 元のプロンプト 五粮液の白酒における業績崩壊に至る経緯と原因、業界はこれまでどのようなルールだったのか？今後の展開はどうなる？なぜ五糧液が異議を唱えて現状を覆そうとしているのか？\n執筆の思路の要約 2025年の年次報告とこれまでの会計誤謬修正点を確定させ、今回の動きが単なる市場の変動ではなく、計上基準（口径）の見直しであることを示す。 「以前のルール」を、チャネルによる在庫積み上げ、出荷＝帳簿計上、および棚卸資産に基づく報告という従来のロジックに限定して記述する。 五糧液の動きは、業界調整、チャネル圧力、そしてガバナンス上の圧力が複合的に作用した結果として説明する。 後半では、業界が真の実売（動く在庫）、消費者中心主義、およびより直接的な流通モデルへとシフトしていく点を重点的に書く。 本稿では意図的に五糧液と茅台の横断比較や短期的な株価予測は展開せず、主要な論点（主線）を「ルールの変化」に絞る。 ","date":"2026-05-04","language":"ja","permalink":"https://ttf248.life/ja/p/wuliangye-breaks-the-table/","tags":["AI霊感衝突坊","五糧液","白酒","財務諸表","ファイナンス知識ベース","投資 (tōshi)"],"title":"五糧液はなぜテーブルをひっくり返したのか","year":"2026"},{"categories":["メモ書き雑感"],"content":"AIのショートドラマの最も面白い点は、すぐに実写のショートドラマに取って代われることではなく、それまで「手を出しにくい」とされてきたテーマを、試すことができる題材に変えた点です。\nゾンビ、軍隊、精霊獣（スピリットビースト）、玄幻といった要素は、従来の実写\nAIが最初に修正したのはこの予算書です。すべてのシーンが高品質である保証はありませんが、以前は必須だったセットの構築、キャストの手配、特殊効果といった部分を、実験的な範囲まで抑え込むことができました。ゾンビに実際にエキストラ百人を組織する必要はなく、霊獣にも最初から映画レベルの効果予算を使い果たす必要もありませんし、軍隊のシーンも必ずしも衣装とロケーションから始めるわけではありません。\n実写のショートドラマ時代においては、多くの題材が「誰も作りたくない」わけではなく、むしろ製作サイドが根本的に着手（撮影）することを恐れているというのが実情です。\n軍隊のシーンを撮るなら、まず人物はどこから登場させるか、ロケ（背景）はどう組み上げるか、車両や爆発のエフェクト処理など、多くの課題を解決する必要があります。\nゾンビを撮る場合も同様に、メイクアップ、追いかけっこ（アクション）、集団シーン、そして特殊効果といった点が課題となります。\nしかし、霊獣やファンタジーのような作品となると、難易度がさらに上がります。なぜなら、初期段階で「この存在が具体的にどのような姿をしているのか、動いたときに説得力があるかどうか」を、低コストで検証することが非常に難しいからです。\nそのため、以前は多くのプロジェクトが非常に早い段階で頓挫していました。放送に至る過程でもなく、視聴者のフィードバックによるものでもなく、制作計画や予算の時点で却下されてしまうのです。本格的な創作ディスカッションに入る前から、「それは夢物語だ」とすでに予算から釘を刺され、実現不可能だと判断されることがありました。\nAIショートドラマにおいて最初に組み込まれたのが、まさにこのハードル（門戸）です。それは、単に短編ドラマの審美的な上限をどこまで引き上げたかという点ではなく、元々「試す価値もない」とされていたテーマ群を、「企画化が可能」「プロト\nなぜ、まさかこれほどこれらの題材から出てくるのか また、これは非常に直感的な現象を説明しています。AIショートドラマにおいて最も頻繁に登場するのが、オフィスラブや家庭倫理といった題材でも、最も安価な都会の会話劇でもなく、むしろ神話、ファンタジー、アドベンチャー（冒険）、SFなど、本来実写での撮影には向かないジャンルなのです。\n理由は複雑ではありません。写実的で、舞台設定がシンプルであるもの、俳優の演技や生活感に依存するタイプの題材ほど、AIが現時点で提供するメリットはかえって直接的ではないのです。しかしながら、作品が世界観、モンスター、異種生物、大掛かりなシーン、非現実的な環境に高度に依拠するようになると、AIの価値は即座に非常に具体的になります。\nそれは、まず「想像する（具現化する）」という行為そのものを手頃なものにした。\nそして、元々サイクル（周期）、資金繰り、試行錯誤の余地といった点に非常にシビアな短編ドラマのようなコンテンツ形態において、アイデアを視覚化するコストを最初に下げた者が、過去には制作できなかったテーマを世に出すことができるのです。\n公開事例が何を証明しているのか 公開された事例から見ると、このラインは非常に一貫しています。\n2024年7月8日、快手はWAICフォーラムにおいて、「中国初のオリジナルAIGCファンタジーマイクロドラマ」『山海奇鏡之劈波斬浪』を披露した。この動き自体が非常に象徴的である。AIが最初に挑んだのは、低コストな現実題材ではなく、世界観と視覚効果のサポートを最も必要とするファンタジーマイクロドラマだった。\n2025年1月1日に公開されたAIマイクロ短編ドラマ「美猴王」は、舞台を中国神話へと置き換えました。花果山、水簾洞（すいれんどう）、龍宮などのこれらのシーンは、本来低予算での実写撮影には適していませんでした。ここでAIが提供したのは、「描ける絵」に留まらず、これらのシーンをまず低コストで納品可能なビジュアルとして実現した点です。\n2025-02-24 になると、『馬家窯の謎と神杖の暗号』は、再びテーマを先史時代の部族、考古学的ファンタジー、そしてトーテム叙事へと向けた。科学技術日報の報道には非常に重要な詳細が記されていた。それは、チームがAIに単にランダムな生成を行わせるのではなく、研究報告書、3Dスキャンデータ、古籍を「インプット」として与え、その上で考古学的な境界内での推論を行わせたという点だ。つまり、AIは単にコストを下げるだけでなく、これまで検証に非常に高額なコストがかかっていたテーマを、「何度も試行し、何度も修正できる」制作\n過去を振り返ると、2025-06-26に中央電視台ウェブサイトが報じた『新世界加载中』は、もはや単一のファンタジー題材ではなく、SF、ファンタジー、不条理コメディ、歴史など7つのユニットドラマを集めたものだった。このシグナルは、単なる個別の事例よりも重要である。なぜなら、AIショートドラマが時折オカルト・怪奇ものを描くだけでなく、多ジャンル、壮大な世界観、様式の切り替えを、継続的に供給できる生産方法として捉え始めていることを示しているからだ。\n技術が補っているのは、実質的にデリバラビリティ（納品物としての完成度）である これらの事例だけを見ると、「AIが皆の特殊効果費用を節約してくれる」と誤解されやすいです。実際のところ、事実はそれほど単純ではありません（または、問題はそこまで狭くありません）。\n2026年2月5日にクァイショウが可霊 3.0をリリースした際、公式の重点はナラティブ制御、一貫性、最大15秒の動画、および複数キャラクター対応の多言語ネイティブ音声に置かれてきました。これをショートドラマ制作に応用した場合、これらの言葉を平易な日本語に訳すと、以下のようになります\nこれは、AIショートドラマが「単に描けるかどうか」という段階を解決するだけでなく、「完成された作品（成果物）として繋げられるか」という水準に近づいていることを示している。\n制作プロセスが「リソース（資源）の有無を先に吟味する」段階から、「アイデアに挑戦する価値があるかを先に判断する」段階へと移行するとき、最も恩恵を受けるのは、必ずしも最も写実的な題材ではなく、むしろ予算によって潰されがちな題材となるだろう。\nどこに限界があるのか もちろん、これはAIが実写ドラマを完全に代替したということではありません。\nそれは、単にハードルを「撮影できるかどうか」という点から、「どれだけうまく語れるか」という点へと押しやっただけだ。霊獣を生み出すことができたからといって、それが成立する玄幻のショートドラマがあるわけではないし、戦闘シーンを作り出したからといって、キャラクターの関係性や感情的な推移、そしてテンポの制御が自動的に確立されるわけでもないのだ。\n今のところ、多くのAIショートドラマは、「ハイコンセプトな設定の予告編」のような見た目で、完結した作品とは言えません。これらが証明しているのは、物語構成能力が追いついたということではなく、単に題材（テーマ）の利用可能性が解放されたという点だけです。\nしたがって、この件に対する私の判断は同じですが、以前の原稿よりも焦点が絞られているという点があります。AIがショートドラマの分野で最初に行ったことは、審美的な革命ではなく、これまで予算を見て却下されてきたアイデア群を、改めて企画案のテーブルに戻したことなのです。\nゾンビ、軍隊、精霊獣ファンタジーなどは、目立つ例の一部にすぎません。その後には、そもそも低予算のショートドラマに出るべきではないものが、AIによってテスト撮影エリアに引きずり込まれてくるでしょう。しかし、これらの題材が本当に残れるかどうかを決定するのは、「ついに作れたから」というだけの理由ではなく、最終的には脚本、テンポ（リズム）、そしてキャラクターなのです。\n参考文献 執筆上の注記 元のプロンプト AIショートドラマは、短編ドラマのジャンルを大幅に広げました。ゾンビ、軍隊、霊獣ファンタジーといったテーマがそうです。以前は、これらのテーマの実写短劇の場合、撮影コストを制御することが難しかったのですが、AIで制作することで、まさにぴったり合致しました。\n本記事は、上記の元のプロンプトを出発点としています。メインライン（主線）、素材の密度、および構造については、初回ドラフトの手法に準拠しています。date フィールドは元の公開日時を使用します。その他の内容は、現在の記事の目的に沿った情報のみです。\n","date":"2026-05-04","language":"ja","permalink":"https://ttf248.life/ja/p/ai-short-drama-budget-got-repriced/","tags":["AI霊感衝突坊","ai","短編劇","AIGC","コンテンツ産業"],"title":"ショートドラマでゾンビや霊獣を撮影したとしても、最初に変わるのは予算表だ。","year":"2026"},{"categories":["投資 (tōshi)"],"content":"今日、支付宝で006327を購入したんだ。午後の3時前に注文すれば、「今日の恒生ハイテクの終値」が買えると思ってたんだけどさ。ところが、ページの利益がしばらく動かないし、口数の確認も遅くて。最初に思ったのは、「これってどういうこと？」って呆然としたよ。一体何基準で取引されるんだ？なんであと二日も待たないといけないんだろう\n正直なところ、この誤解は非常によくあります。Alipayが場外ファンドの売買をあまりにも株式注文のように演出しているのですが、これには本質的に二つの落とし穴があります。第一に、006327は恒生テクノロジー指数ファンドではありません。第二に、場外でファンドを購入しても、特定の指数のリアルタイムの終値ポイントが手\nまず誤解を訂正させてください 006327 は 易方達中证海外互联网50ETF联接(QDII)A です。これは、恒生科技指数ではなく、中证海外中国互联网50指数 を基礎として追跡しています。\nこれら二つのものは、どちらも香港のインターネット株と関連しているように見えますし、市場でも高い確率で同時に上昇し、同時に下落するため、一つの概念として混同されやすいです。しかし、実際に注文を出すときには、コードはあなたの「感覚」を理解してくれません。間違った買い方は、ただ間違っているだけなのです。\nこれが理由です。ファンドを購入する際、支付宝（Alipay）のチャートだけを見てはいけません。頭の中では「恒生科技」を考えていても、実際に発注しているものが 006327 の場合、その後に利益表示が問題なくても、軸（アンカー）はすでにずれてしまっています。\n本当に取引されるのは指数の終値ではない 上場外ファンドの申し込みは、非常にシンプルなルール、「未知価格の原則」に基づいています。お申し込みいただく時点では、最終的な基準価額が分からないため、実際に使用される価格は、そのファンドが申込当日に市場を閉めた後に計算された「ファンドの口数（純資産）」となります。\nここで最も混同しやすい点は、多くの人が投資信託を株式と同じように理解してしまうことです。株式は板を見て売買し、価格がその場で成立します。しかし、投資信託は異なります。購入するのは、「一篮子（バスケット）の資産」に対応する口数であり、この口数がいくらの価値を持つかを算出するには、運用会社がポジション（保有状況）、為替レート、現金残高などの要素をルールに基づいて締め処理してから、ようやく当日の純資産価値（NAV）が計算されるからです。\nしたがって、午後3時前に入金を行う場合、支付宝がこの申請を当日有効なものとして記録するという前提であれば、あなたが固定しているのは「ある指数の今日のある時点の終値ポイント」ではなく、申請日そのものです。また、恒生テクノロジーの終値を単純に係数で掛け合わせて直接取引が成立するわけでもありません。\nなぜQDIIはいつも二日も待たされるのか 一般的なオフショアファンドの承認プロセスはすでに株式よりも遅く、QDII はさらに時間がかかります。その理由は複雑なものではなく、単に海外市場に投資するため、バリュエーション（評価）の経路が長くなるためです。\n「006327」のファンド契約に基づくと、T日時点の基準価額はT+1日になって初めて計算され、T+2日以内に開示と確定が完了します。このルールをユーザーインターフェース（UI）上での体感として表現すると、今日購入しても今日の結果は見られず、明日もまだ待機している状況であり、明後日にならないと「実際に完了した」という感覚にはなりません。\nここを見て、多くの人が再び誤解してしまうかもしれません。「収益の表示が2日遅れている」ということは、「この2日間はまだ収益計算を始めていない」ということだと。しかし、これも正しくありません。より正確に申し上げると、基金の口数や純資産価値の結果の「表示」が遅れているだけであり、ファンドが3日目からあなたのために計算を始めたわけではありません。\n「表示の遅れ」と「データが実際に反映される（有効になる）のが遅れること」は、別問題です。ただ、QDIIのような商品の場合、プラットフォームが最終的に提示できる数値群は、お客様が購入ボタンを押された時点から、元々約2営業日ほど経過しているものなのです。\n2026年4月27日分のこの明細（伝票）を詳しく見てみましょう 「もしあなたが、2026年4月27日（月）15:00以前に支付宝を通じて006327の買い付け申請を提出し、かつその注文がシステムによって当日有効な申請として正常に記録された場合、おおむね以下のようなタイムラインになります。」\n2026-04-27：申請を提出し、取引日はこの日に確定します。 2026-04-28：ファンド会社が、2026年4月27日に対応する基金の純資産価値（NAV）を計算します。 2026-04-29：契約上の取り決めに基づき、口数確定と純資産価額の公表は通常この日頃になります。 2026-04-30：支付宝のような販売代理プラットフォームでは、保有状況および収益表示がより完全で安定している傾向があります。 海外市場が休場していたり、為替レートの評価に遅延があった場合、あるいはプラットフォーム自体の表示同期にタイムラグが生じたなどの事情により、この時間もさらに繰り延べとなる可能性がございます。\nしたがって、元の理解は、もっと正確なバージョンに修正する必要があります：\n正しい点：利益の表示が2日遅れているのは、基本的に正常な現象です。 誤っている点：あなたは、本日の恒成テクノロジー指数（Hang Seng Tech Index）の終値で売買したわけではありません。 最後に これは画面表示の問題に見えますが、本質的には取引対象と取引メカニズムを混同されているのが根本原因です。お客様が購入しているのはファンドの口数（基金份额）であり、指数そのものの水準ではありません。また、提出されているのは場外での申購申請であり、市場内のリアルタイム成約注文ではありません。\n今後、支付宝でこのような QDII に遭遇した場合、まず確認すべきなのは「今日のローソク足がどこで終値するか」ではなく、以下の3点です。コードが正しいか、追跡している基準資産が自分が購入したいものか、プラットフォームが申し込みを当日の取引日として記録したか。\nファンドを株式のように買ってはいけませんし、香港のインターネット株すべてが恒生テクノロジーに分類されると考えてはいけません。前者は約定価格の判断を誤らせ、後者は自分が何を買ったのかという点まで偏見を持たせてしまいます。色々な経験をしてきた中で、注目すべきは2日後の損益数字ではなく、注文を出した瞬間に自分自身が具体的に何を購入したか、その点なのです。\n参考文献 執筆に関する注記 元のプロンプト 今日、アルリペイで006327ファンドを購入しました。15時前に入り、恒成テクノロジー指数の今日の終値で購入したのでしょうか？収益の表示がたった2日遅れるだけで良いという理解で合っていますか？\n続きを書いて、その後記事としてまとめます。\nライティングの構成案要約 ","date":"2026-04-27","language":"ja","permalink":"https://ttf248.life/ja/p/how-alipay-006327-nav-works/","tags":["AI霊感衝突坊","アリペイ (Ālipèi)","ファンド","QDII","投資 (tōshi)"],"title":"Alipayで006327を買う場合、どの日の純資産価値（ネットアセットバリュー）で計算されますか？","year":"2026"},{"categories":["コンピューター","メモ書き雑感"],"content":"ここ数ヶ月、ClaudeやCodexといったツールを使ってコードを書いている中で、最も強く感じているのは、「プログラマーが不要になる」ということではなくて、以前は新人に練習課題として出していたような作業まで、AIがすでに叩き台（ドラフト）を生成してくれることだ。\nスキャフォールドの作成、いくつかのテストの追加、ついでに小さな機能を修正する…という操作を続けていくと、その速度があまりにも速くて、なんとも言えない「意難平」な気分になる。\n私のような卒業から10年が経過した人間にとって、正直なところ、これは主に効率化の問題です。なぜなら、どこを信じてよいか、どこを信用してはいけないか、そして表面上は動作しているように見えても、実は後に罠（落とし穴）がある場所などを概ね把握しているからです。しかし、新卒者にとっては、この問題はそれほど簡単ではありません。AIは単に数時間の肉体労働を奪ってくるだけでなく、「初心者がどうやって無知から熟練へとなるか」という確立された道筋そのものを圧縮してしまっているようなものです。これが私が改めて書きたいと考えている点でもあります。\n本当に淘汰されたのは、プログラマーではなく、「スマホの技能大会（モバイルスキル）」だった 以前のチームには、技術的な難易度は高くないものの、新人にとって非常に適した種類のタスクが常にあります。例えば、ページ修正、インターフェース（API）連携、CRUD機能の実装、エッジケースのバグ修正、ログを追跡しながら一つずつデバッグを行うといった作業です。タスク自体は大規模ではありませんが、「文法を書ける」だけの段階の人を、「実際のシステム全体がどう動いているか」を理解できるレベルまで育て上げることができます。\n現在、このような仕事はAIに最も早く飲み込まれる傾向があります。\n米国労働統計局（BLS）が2025年版の職業展望において、非常に興味深い対照的な指摘をしています。\n一方では、ソフトウェア開発やテストといった職種は今後10年間も成長し続けると述べる一方で、「コンピュータープログラマー」という、より「コードの記述・実行」に重点を置いた職種については減少傾向にあるとし、多くの定型的な（反復的な）プログラミング作業が継続的に自動化されるだろうと明確に記しています。\nこの変化は極めて重要です。\nソフトウェア業界から人がいなくなるという意味ではありません。というのも、「ただタスクを受けてコードを書くだけ」という価値が、ますます薄くなっているからです。企業は当然、コスト計算をします。AIにまずドラフトを作成させ、その後経験豊富な人材に仕上げ（磨き上げ）てもらえるのであれば、なぜこれまでのように多くのジュニアポジションを配置して時間をかけて育成する必要があるのでしょうか。\nだからこそ怖いのは、必ずしも人員削減ではないのかもしれない。むしろ、人が補充されなくなることだ。道（チャンス）自体はまだそこにあるものの、幅が狭くなってしまったということだ。\nなぜベテランほどAIの恩恵を受けやすいのか この件、ちょっと矛盾している気がしますね。一見すると、AIが生成したコードでも、新卒のエンジニアより優れているとは限りません。しかし、真にAIを使いこなせるプロは、多くの場合、何らかの失敗（落とし穴）を経験してきたベテランなのです。\n理由は複雑ではありません。\nまず、ベテランは、「動くように見える」ことと「実際に本番環境で機能する」ことは別物だと知っています。Anthropicは、2026年1月のEconomic Indexにおいて、ソフトウェア開発を個別に分析した結果、このようなリクエストは高度に体系化されているものの、タスク成功率は約61%に留まることが判明しました。また、ほとんどのシナリオでは、一度AIに任せて終わりではなく、往復での反復的なやり取りが必要\n第二に、ベテランには「コードのセンス」というものがある。この言葉は少し玄妙だが、非常に実効性がある。インターフェースをこう分割すべきか、例外処理をこのように飲み込むべきか、テストが単にCIをごまかすだけではないか、リファクタリングによって来週分の落とし穴まで先に埋めてしまうのではないか。AIも今では間違いを犯すのだが、その多くは構文ミスではなく、方向性の誤りや抽象化の誤り、境界の誤りだ。古法でのプログラミングを経験したことがない人は、正直なところ、こうした誤りを識別するのがより難しい。\nつまり、AI時代において最も価値があるのは、タイピングの速さではなく、判断力なのです。\n新人が道がないのではなく、古い道が存在しなくなっただけのことだ 新しい分野に参入した人が、完全に機会を失うとは思えません。世界経済フォーラム（WEF）は、2025年1月のレポートにおいても、ソフトウェアおよびアプリケーション開発者を成長が著しい職種として位置づけています。また、米国労働統計局のソフトウェア開発職に関する長期的な展望も依然として増加傾向にあります。これは、需要が突然消滅したわけではないことを示しています。\nしかし、参入方法が確実に変わった。\n以前の標準的なキャリアパスは、まず実務を通じて苦労を重ね、書きながら学習し、経験を積んで感覚（フィーリング）を磨き出すというものでした。しかし現代では、企業はあなたが入社したらすぐに2つのことを期待する傾向がより強くなっています。\nまず、AIを「答え」としてではなく、「ツール（道具）」として扱うことが大切です。問題点を明確に言語化したり、要件を細かく分解したりして、まずは利用できる草稿を出してもらうといった対応ができる必要があります。\nもう一つの点は、それ（コードなど）をレビューできる能力です。単に「これは間違っている」と言うだけでなく、どこが間違いなのか、なぜ間違いなのか、そしてプロジェクトのコンテキストに合わせてどのように修正すべきかを理解していることです。\nこれは困りましたね。「コードレビューができる能力」というのは、本来数年間の仕事経験を積んで身につくものなのに、今は練習する機会が減っているのに、かえって新人にこの能力を早く持っていることを求められている。どう言えばいいか、まるでゲームの初心者村が取り壊されたのに、ボスは目の前で待っているような状況です。\n今後の展望 私の現在の判断は比較的単純です。\nAI は熟練者の生産性を向上させ続けると同時に、初級職における最も標準化しやすく、細分化しやすい業務部分を圧縮し続けるでしょう。この二つの事象は矛盾することなく、同時に発生する可能性が高いです。ILO は 2025 年 5 月の報告書で非常に抑制的な見解を示しており、生成AIは単に仕事全体を一気に消滅させるというよりは、タスク構造そのものを変えるものだとしています。問題なのは、タスク構造が変わると、最も先に廃止されがちなのが、本来新人育成のために設計されていた低リスクの業務であるということです。\nしたがって、次に希少価値が高まるのは、「最もコードが書ける人」ではなく、基本的な能力を持ち、AIを使いこなすことができ、さらにビジネスと品質に対して責任を持てる人物です。\n経験者にとって、これはより鋭いシャベルを一つ加えたようなものであり、疲れはするものの、効率が格段に上がりました。しかし、新人にとっての問題は、AIを使えるかどうかではなく、最初からAIに頼って書いた場合、いつが質の高い文章で、いつが本気でデタラメ（嘘）を書いているのかを誰が教えてくれるのかという点なのです。\nこの答えは、今のところ学校でもAIでも提供できません。結局は自分で補完していく必要性が高いでしょう。「門が閉まったわけではないけれど、より入るのが難しくなってきましたね。」\n参考資料 2025年仕事の未来に関するレポート ソフトウェア開発者、品質保証アナリスト、テスター コンピュータプログラマー BLS雇用予測におけるAIの影響 Anthropic経済指数：最新データからの洞察 [Anthropic経済指数 作成上の注記 元のプロンプト AIプログラミングに関するいくつかの考察です。新卒の学生は、コーディング能力がClaudeやCodexには及ばないのは間違いないでしょう。ベテランにとってはAIが効率性を高めてくれますが、同時にAIによって企業側がジュニアプログラマーのポジションを大幅に削減するという事態も生じました。私は卒業から十年が経ち、初心者から熟練者へと成長する道のりを経験してきました。これから新しく業界に入ってくる人たちはどうなっていくのでしょうか？私たち年配の世代は「古き良き」コーディング手法を経験してきたため、簡単に言えば、現在の段階にあるAIが書いたコードが良いものなのか悪いものなのかを見分けることができます。畢竟（ひんこう）今のAIはまだ間違いをするからです。\n執筆の考え方（または論旨）の要約 主張の軸を「AIが圧縮しているのは、新参者の練習機会であり、ソフトウェア業界全体ではない」とする点に置く。 前半部では、ベテラン層がなぜAIの恩恵をより大きく受けるのかを述べた後、それが ","date":"2026-04-27","language":"ja","permalink":"https://ttf248.life/ja/p/when-ai-writes-code-how-juniors-level-up/","tags":["AI霊感衝突坊","ai","プログラマー","キャリア思考","ソフトウェア開発"],"title":"AIがコードを書き始めたけど、新人は何でスキルアップすればいいの？","year":"2026"},{"categories":["金融知識データベース"],"content":"数日前に、ある人がかなり昔の貴州茅台の「調整前価格（前復权価格）」を持ってきて質問をしてきました。正直なところ、私も最初は少し戸惑いました。同じく「前復権」を見てみると、\nこの記事はただ一つのことを行います。それは、この2つの指標を切り分けることです。混乱しないよう、まず私の見解から述べます：国内で主流のチャートソフトにおける「前復権」は、取引所が決定した除権・除息参考価格に沿ってローソク足（K線）を平滑化しているように見えるのに対し、海外で一般的に使われる adjusted close は、累積乗数を使って「配当再投資」による総利回りを表現しているようです。どちらも「前復権」と呼ばれますが、回答している質問はまったく異なるのです。\nA株の前行調整において、最初に問われるのはKラインの接続方法だ 国内のこの算出基準（または、考え方）を用いる場合、公開されている参照ポイントは実は見つけるのが難しくありません。深セン取引所が除権除息に関する参考価格の公式を提供しています：\n$$ \\text{除権（配当）基準価格} = \\frac{(\\text{前日終値}-\\text{現金配当})+\\text{割当価格}\\times\\text{株式変動比率}}{1+\\text{株式変動比率}} $$ 東方財富百科に記載されている「正確な複利調整（または『正確な再調整』）」の事前計算式は、基本的な考え方がこれと同じ系統です。\n$$ P'=\\frac{(P-D)+K\\times r}{1+r} $$ここで、$P$ は調整前の価格、 $D$ は一株当たりの現金配当金、$K$ は配当や新株の価格、$r$ は流通株式の変動比率です。この式で最も重要な点、それは割り算があるかどうかではなく、現金配当が一定額を差し引かれていくという点です。\nしたがって、企業の活動が現金配当のみとなり、送付や新株発行がない場合、この公式はそのまま〜に単純化します。\n$$ P'=P-D $$この件の結果は非常に直接的です。上場時期が早く、累積配当が多いA株（中国本土の株式）の場合、もし歴史的な価格を遡って計算した場合、実際にマイナスになる可能性があります。東方財富などのサイトで、このような極めて初期の負の値を目にすることがありますが、必ずしも計算ミスとは限りません。むしろ、単に国内で一般的なこの「事前調整（前複権）」の定義を採用し続けているだけかもしれません。\n現在、私はこれを「グラフィカルな連続性を優先する」という観点として捉える方が良いと思っています。例えば、今日ソフトを開いたとき、現在の価格が動かず、過去のローソク足（Kライン）が下に押しやられると、チャートがつながりやすく、テクニカル指標もより見やすくなります。これは銘柄分析において非常に有用ですが、当然ながら総リターンの系列\n港美株の調整後終値について、まず総収益（トータルリターン）はどのように計算しますか Yahoo! の公式な Adjusted close の定義は非常に明快です。これは、株の分割と配当の両方で調整を行います。さらに、配当乗数は「配当が価格に占める比率」に基づいて算出されます。公式にはまた、これを行う主な目的の一つが負の過去の株価を避けることであると明確に記されています。\n式で表現すると、一般的な考え方としては、まず各企業の行動に乗数（係数）をかけるというものがあります。\n株分割倍率: 例えば `2-for-1` の場合、過去価格に `0.5` を乗じます。 配当乗数: `m=1-D/C_{t-1}` ここで、$D$ は一株当たりの現金配当であり、$C_{t-1}$ は配当落ち前の終値です。その後、以降の全ての企業行動の乗数を連続的に掛け合わせることで、累積調整係数 $F_t$ を得ます：\n$$ F_t=\\prod_{j\u003et}(s_j\\times m_j) $$したがって、調整後価格は次の通りです：\n$$ P_t^{adj}=P_t\\times F_t $$ この書き方（手法）の意味は明確です。これは、「もし配当金も引き続きこの銘柄に再投資し続けた場合、総収益がどうなるか」を近似的に示しています。したがって、リターン計算、長期バックテスト、時系列での比較を行うのに本質的により適しています。国内で一般的な、現金配当金を履歴価格から直接差し引く算出方法は、見た目はローソク足を修正しているように見えますが、その骨子は全く異なります。\n補足させていただきますが、6月の旧記事では、Yahoo / yfinance の adjusted データと Tushare の qfq が、「完全に同じもの」のように述べられておりましたが、これは厳密ではありません。より正確に言えば：これらは同じ系統（ファミリー）に属し、どちらも乗数型またはファクター型の調整ですが、正規化のアンカーポイントが必ずしも一致するわけではない、ということです。\n調整係数は萬能の翻訳器ではない 問題は実際、この点にあります。多くの人は「復権因子」という言葉を見るだけで、全ての市場が因子の列として抽象化でき、その後 price * factor で計算できると（と思い込んで）しまいます。この考え方は、香港や米国株で一般的に用いられている調整後終値（adjusted close）のシステムでは基本的に成り立ちますが、国内の事前復権（pre-adjustment）システムではそうとは限りません。\n理由は複雑ではありません。国内で用いられているこの精確な再加重公式は、実は純粋な乗法ではなく、アフィン変換なのです:\n$$ P'=\\frac{1}{1+r}P+\\frac{Kr-D}{1+r} $$つまり、本質的には：\n$$ P'=aP+b $$現金配当が発生する場合、定数項 $b$ はゼロではありません。複数の企業アクションが積み重なると、得られるのは単一の累積倍率ではなく、仿射変換（affine transformation）を連積・連加した一連のものになります。この場合、個別の「調整係数」では不十分であり、少なくとも現金配当、割り当て価格、株式変動比率などのイベント情報、あるいは等価な $(A, B)$ パラメーターが必要となります。\nしたがって、答えは明白です：「調整係数」という概念は、この2つのスキームでは直接適用することはできません。\n海外で一般的に用いられている調整後終値（adjusted close）のシステムにおいて、除却係数が中心的な対象となります。 国内のこの正確な調整システムでは、係数は「株式分割／配当金」といった部分的な比率変化しかカバーできず、現金配当に遭遇すると、単一の係数では対応できません。 これが、国内ソフトウェアの事前調整価格とYahooの調整後終値を同じ水準で無理に比較すると、結果的にますます混乱してしまう理由です。\nTushare はどちらの側に立っているのか この問題については、公式サイトで非常に明確に記述されています。TushareのA株調整後価格データのドキュメントが示す式は以下の通りです：\n$$ \\text{前復権} = \\frac{\\text{当日終値} \\times \\text{当日調整係数}}{\\text{最新調整係数}} $$同じページには、さらに以下の二点が明記されています：\n設定された end_date に基づいて動的に権利調整を行います。 「配当再投資」モデルを採用しています。 これらの2文で定義は十分です。TushareのA株におけるqfqは、概念的には海外の乗数/ファクター型の調整後終値に近く、東方財富社の正確な再評価前の再評価手法とは異なります。 ただ、独自に正規化の方法を維持しています。それは常に「本日」をアンカーとするのではなく、今回のクエリウィンドウのend_dateを基準とするものです。\nしたがって、Tushareの位置付けは一文にまとめることができます：\n東方財富（Oriental Fortune）のものとは、同一の事前調整（前複権）定義ではありません。 Yahooのものに似ていますが、数値が一点たりとも完全に一致するわけではありません。 Tushareは、その後、香港株や米国株に対しても調整係数（复权因子）と調整済みデータインターフェースを追加しました。公式の説明もやはり price * adj_factor = 調整価格 です。これは、その製品設計の考え方が、本質的には掛け合わせの係数を用いる派生であることをさらに示しています。\nバックテストに戻る：まずは評価基準を定め、その後で是非を議論する このことを理解すれば、多くの議論は自然と消えていくでしょう。\nもしお探しのものが「〜」の場合：\n国内の相場ソフトのスクリーンショットに合わせる 現在価格が一定で、過去のローソク足と滑らかにつながっている 「A株」の文脈における「前調整グラフ」（ぜんふくけん）を見る ですから、国内（中国）で用いられているこの精度の高い調整基準を使用すべきです。\nもしあなたがお求めなのが：\nバックテスト収益率 配当再投資による総利回り 長期的な戦略評価 それならTushareのqfqやYahooのAdjusted closeのような乗数ファクター（積算）基準を使うべきです。\n6月の旧記事ですが、最大の問題は完全に間違っていたことそのものではなく、この2つの定義を「唯一の標準」として混ぜこぜにしてしまった点にあります。今振り返ってみて本当に記憶しておくべきなのは、「比例法が絶対正しく、加減法が絶対間違っている」ということではなく、むしろ: そもそも、あなたは画像編集をしているのか、それとも収益を計算しているのか。 という二つの問題を先に分けていないと、後続のバックテスト結果やローソク足（K線）の比較、さらには「なぜマイナス値が出てくるのか」といったこともすべて絡み合ってしまいます。\n参考資料 ChatGPT 共有会話：復権計算の違いの分析 Tushare：A株の調整後価格チャート Tushare：米国株の調整後価格チャート Yahoo Help: What is the adjusted close? 深圳証券取引所：権利落ち（配当落ち）価格の計算方法は？ 東方財富百科：調整 執筆上の注記 元のプロンプト $blog-writer ここの内容を分析してください：https://chatgpt.com/share/69e653e4-2814-83ea-bd7d-4233343ca9cf。また、過去記事27について、バックテストデータはどこで入手できますか？まず、国内で一般的に使用される前修正（pre-adjusment）の計算式を整理し、次に海外で一般的に使用される前修正の計算式を整理してください。除権係数（または調整要因）の概念は、両方のスキームで共通して利用できますか？Tushare のデータはどの方式に属するものですか？ ライティングの構成案の要約 ","date":"2026-04-22","language":"ja","permalink":"https://ttf248.life/ja/p/backtest-front-adjustment-formulas/","tags":["量子化 (Kyūka)","バックテスト","権利調整 (けんりちょうせい) / クローバック (Klobacku - 文脈による)\n\n*注：文脈によって適切な訳語が異なります。金融や株式の文脈で「権利落ち」に関連する場合は、「権利調整」が一般的です。*","AI霊感衝突坊"],"title":"バックテストにおける事前調整は、国内と海外では異なるアルゴリズムです。","year":"2026"},{"categories":["投資 (tōshi)","金融知識データベース"],"content":"2026-04-17、貴州茅台が2025年の年次報告サマリーを公開しました。 年次報告の要約によれば、売上高は1688.38億元で前年同期比1.21%減少し、親会社帰属純利益は823.20億元で前年同期比4.53%減少しました。 さらに下を見ると、本当に厳しいのは第4四半期であり、四半期純利益が2024Q4の254.01億元から`176.9\nこの件は、茅台という銘柄をどのように見るかに直接影響するため、個別に掘り下げる価値があります。かつて多くの人は、茅台を永遠に右肩上がりの消費神話だと捉えており、若者が飲むかどうかといった点は些細な問題でした。しかし、現在の状況はそうではありません。\n若者が白酒に本能的に興味を持たないのは当然の事実ですが、これはむしろ「遅い変数（slow variable）」のようなものです。年次報告書に見られるような突然の転換点という動きの裏側には、古いビジネス需要全体、古い富の分配方法、そして古い「体面」消費システムといったものが縮小しているように見えます。\n若者は飲まない、それは表面的なものに過ぎない かつては、私もつい原因を世代交代に帰してしまいがちで、若者がクラフトビールやカクテル、ウイスキーなどを飲むので、白酒は当然周縁化してしまうと考えていました。この判断が間違っているとは言えませんが、茅台の今回の決算報告書における急激な変化を説明するには不十分です。\n理由は単純です。世代的な嗜好の変化はゆっくりと進むものであり、ある四半期にわたって利益がこれほど急落することはありません。\n実際、高価格帯の白酒の価格と利益を限界点で決定しているのは、「飲んでいる人がいるかどうか」だけではありません。「誰が、どのようなシーンで、なぜ2000元から3000元ものボトルを買う意思があるのか」という点こそが重要です。\n高価格帯の白酒が売っているのは、単なる味わいそのものではなく、「社交的な効率性」「面子（体面）の確認」「人間関係の円滑化」といった要素である場合が多いのです。実際に\nマオタイ自体も、この変化についてかなり率直に述べています。「2025-12-28」の全国ディーラー懇親会で、会社経営陣は「伝統的な消費層の主要な需要の減退」に言及するとともに、新しい顧客層や新しいシーンを探すことが重要だと強調しました。この発言には非常に大きな情報量が含まれています。これは、これまでマオタイの価格体系を支えてきたコアな購入層が、以前ほど強力ではなくなってきているということを認めているに等しいのです。\nなぜ茅台は不動産セクターの「影子株」のように見えるのか ここでいう「影の銘柄」（影子股）とは、茅台のレポートに不動産プロジェクトが山ほど含まれているということでもなく、地価が下落したからといって、茅台株がそれに一対一で連動するという意味でもありません。私はむしろ、需要構造上の反映（マッピング）として理解したいと思っています。\n過去20年間に、中国で最も派手で継続的かつ支出的なビジネスシーンの多くは、不動産チェーンと関連しています。地方財政は土地の売却に依存し、城投（都市インフラ投資）は土地を巡って動き、開発業者は高い回転率を実現します。そして、施工総合請負業者、下請け、建材、内装、仲介業者、金融支援といったものが一堂に利益を得ています。この連鎖が一度繁栄すると、ビジネス宴会、お祝いの贈答品、人間関係の維持、プロジェクト協力といったあらゆる側面で過剰な支出が引き起こされます。お金は住民の日々の生活費から少しずつ削り取られるのではなく、高いレバレッジ、高い回転率、そして高いプレミアムが付加されたシステムから溢れ出ているのです。\nこのような環境下において、茅台は単なるお酒ではなく、高級なステータスシンボルのような存在です。そのポジションに非常に適したいくつかの特徴があります。すなわち、ブランド力があること、価格が高いこと、識別性が高いこと、そして流通性も十分良いことです。\n多くの場合、一本のボトルが2000元なのか3000元なのかといったことは、その場の会の予算ロジックを変えるものではありません。むしろ、高価であるほど、「あなたを大切に思っている」「私には力がある」「この場には格がある」というシグナル伝達をより強力に行うことができるのです。\nそのため、「マオタイは不動産の影の株式（シャドウ株）である」という見解には強く同意しますが、より正確に表現すると言うと：それが映し出しているのは、建物そのものではなく、不動産による信用拡大期に生み出されたハイエンドなビジネス消費の秩序なのです。\n現在のこの秩序は後退している。国家統計局が発表した2025年の全国不動産データも芳しくない：不動産開発投資は前年比で17.2%減、新築商品住宅の販売面積は8.7%減、デベロッパーの手元資金は13.4%減となった。不動産市場が縮小すると、最初に消えるのは食料品などの生活必需品ではなく、むしろ予算の弾力性が最も高く、体面を重視し、またプロジェクトや人間関係に最も依存している消費財である。ハイエンドな白酒はまさにこの状況でつまずいているのだ。\nこの年次報告書が本当に示しているのは、単なる業績不振だけではない より重要なシグナルは、実は茅台自身が物語を変え始めたことだ。\n2026-01-09、茅台は販売店会議で、「市場化への転換は茅台にとって避けて通れない必須の課題である」と公に述べた。さらに深く掘り下げ、これまでの販売領域における「非市場的」な側面が、一般消費\n言い換えれば、茅台が現在取り組んでいることは、本質的に自らに対して「金融的属性からの脱却」「贈答品への依存の解消」「閉鎖的な層構造からの開放」を図\nこれもまた、同社が「2025」年の第3四半期まではプラス成長を維持できたにもかかわらず、年間全体で急激にマイナスの結果となった理由を説明しています。それまでは（売上を）勢い、ブランド力、そして販売チャネルに頼ってカバーできていましたが、第4四半期になると支えきれなくなりました。既存の需要は衰退し、新たな需要が完全に引き継ぎ切れていないため、自然と損益計算書はまず芳しくならないのです。\nこの銘柄は、見方を改めて考える必要があるかもしれません マオタイがこれ以上ダメだとは思いません。そのブランド力、生産地、製法、そして供給の制約はすべて残っていますし、「堀」が一夜にして崩れるものではありません。年次報告書にはもう一つ重要なデータがあります。同社は2025年度の累積配当金が予想され、650.33億元に上り、これは親会社株主に帰属する純利益の79%を占めます。もはやキャッシュカウのような機械ですね。\nしかし、問題はここにもあります。以前、市場が茅台に高いバリュエーションを付けたのは、それがブランド消費財でありながら、同時に高い確実性を持つ成長エンジンであるという核心的な前提があったためでした。現在、「成長」の部分から緩みが始まっています。それにより、評価のアンカーは別の方向へと移動しつつあります。すなわち、高成長な消費材リーダーから、低成長、高配当、強力なキャッシュフローを備えたディフェンシブな資産へと徐々に移行していく傾向です。\n投資家にとっては、別の話です。 （または：投資家から見ると、それは別の問題です。）\nかつて「売上が常に二桁、卸値が常に安定、ビジネス需要が常にある」という古い考え方で見てしまうと、心の葛藤を覚えるかもしれません。なぜなら、旧時代において最も厚かった需要は、確かに不動産とともに落ちてしまったからです。しかし、茅台を「バブルを剥がれ、投機性を排し、真の消費基盤に戻っていくスーパーキャッシュフロー資産」と捉え直すならば、それはまったく別の評価ロジックとなります。\nおわりに したがって、この件に対する私の理解（認識）は、以前のものとはかなり変わってきました。\n若者が白酒を飲まなくなったのは真実であり、宴会文化が強い歴史的段階性を持っていることも事実です。しかし、より根源的な点に注目すると、高級白酒を神聖視する時代は、平民の日常的な消費によって支えられていたのではなく、不動産信用による拡大、過剰なビジネス接待、そして「体面」に基づく歪んだ消費という一連の環境によって成り立っていたのです。\n不動産業界が冷却期に入ったからといって、白酒がすぐに消えるわけではありませんが、その中でも最も高収益で、コストパフォーマンスを\n茅台というこの銘柄に関して、2025年の年次報告は、単なる業績の変動ではなく、バリュエーション（評価）ストーリーが切り替わる始まりである可能性が高い。今後これを見る際には、ブランドへの信仰心だけを注視するのではなく、実際の消費による需要吸収のスピードを見ることが重要だ。また、チャネル改革が、過去に「局」（特定の仕組みや状況）に頼って支えられていた需要を、より持続可能な消費基盤へと変革できるかどうかを見極める必要がある。\n参考資料 [貴州マオタイ酒股份有限公司 2025年度報告書要約](https://file.finance.sina.com.cn/211.154.219. 作成上の注記 元のプロンプト A株市場における白酒ブランド・マオタイの株式について、2025年の決算データを分析すると、純利益が初めて落ち込んでいる。以前は「若者が白酒を飲まなくなった」「中国的な飲み会文化は単なる歴史的産物に過ぎない」と理解していたが、最新の考察では、この歴史的産物とは不動産業であり、マオタイ白酒は不動産セクターの影の銘柄である。現在、不動産市場自体が衰退し、それに伴うビジネス接待もかつてのような熱狂的なものではなくなり、白酒という派生商品が必要とされる度合いも以前ほどではない。白酒の純利益が高いのは事実だが、ビジネスの場において\n執筆構想の要約 ","date":"2026-04-22","language":"ja","permalink":"https://ttf248.life/ja/p/moutai-profit-decline-and-real-estate-cycle/","tags":["AI霊感衝突坊","貴州茅台","白酒","不動産","A株 (エーショウ)"],"title":"マオタイ、純利益が初めて落ち込むのは、単に若者が白酒を飲まなくなったからだけではない","year":"2026"},{"categories":["魚の7秒間の見聞"],"content":"この数日、Blockが2026年2月末に1万人以上のチームから4000人を削減したのを見て、正直ショックを受けました。私はこれまでずっと金融IT、取引フロー、米英株、システム基盤といった分野に携わってきましたので、「効率化」「自動化」「コスト削減と効率向上」といった言葉には慣れていますが、お金やコンプライアンス、リスク管理にこれほど近いフィンテック企業が、AIを解雇理由として公言するのは、やはり胸が沈みます。\n私の現在の判断は非常に直接的です。AIによる人員削減が最も恐ろしい点は、ある日ニュースで流れる解雇リストそのものではなく、「より小さなチームでも多くの仕事ができる」という前提が会社にデフォルトとして浸透し始めることです。これは、退職者が補充されないこと、初級職の減少、そしてheadcount（人員数）がさらに厳しく管理されることを意味します。2025年4月から2026年4月にかけて、この風はアメリカではまだ吹いています。中国国内では、あのような目立つ大規模な解雇の波は一時的に見られませんが、静かながらも圧迫はすでに始まっています。\nまず、最も代表的な企業を見てみましょう Block は今回最も手厳しい、そして最も直接的でした。2026年2月26日の決算発表後、ジャック・ドーシーの発言には曖昧な余地はほとんど残されていませんでした。AIが企業の構築方法と運営方法を変え、より小規模なチームでも多くのことができるようになった、というものです。APの報道によると、Blockは4000人以上をレイオフし、これは1万人以上の従業員の約4割に相当します。市場も非常に率直で、取引開始前に一時20%以上急騰しました。なぜ上昇したのか？投資家が聞いているのは「技術的な理想」ではなく、利益率、営業レバレッジ、そしてより速い収益成長だからです。以前、Blockは2025年11月のインベスターデーでも、2026年のgross profitが17%増加し、調整後営業利益が30%以上増加するという目標を提示していました。つまり、これは「会社がまずいから人員削減する」という話ではなく、「成長を続けながら、人件費をさらに削れる」と会社自身が考えているということです。\nDuolingo は別の戦略をとっています。2025年4月下旬、同社は「AIファースト」の路線に公然と転換し、AIが可能なアウトソーシング業務を段階的に廃止すると明言しました。また、新規採用枠についても、まずAIでは対応できないことを証明する必要があると述べました。数日後、同社は生成AIを用いて作成された148もの新しいコースを一気に公開しました。2025年8月には、Duolingoの決算報告書が第2四半期の収益が前年同期比で41%増加し、利益とサブスクリプション収益の両方が好調であったことを示し、同日株価も30%近く急騰しました。しかし、この会社は別の教訓も与えました。それは、ユーザーが完全に納得しているわけではないということです。CEO自身も後に認めましたが、ソーシャルメディア上での反発が成長をガイダンスレンジの下限に押し下げたのです。つまり、AIは企業の内容制作能力や利益を拡大させることはできますが、ブランドと信頼はタダでは手に入らないということです。\nKlarna は、過去2年間で最も典型的な「AIによる人件費削減」の事例と言えます。同社は2024年に、AIカスタマーサポートアシスタントが相談対応の3分の2を処理し、その作業量がフルタイムのカスタマーサービス担当者700人に相当すると述べています。2026年3月に提出された目論見書では、Klarnaはさらに明確に計算しています。2023年末には4,352人のフルタイム従業員がいましたが、2024年末には3,422人、そして2025年末にはわずか2,831人にまで減少しており、同社自身が「AIを活用した効率向上による、全体的なヘッドカントリーの積極的な圧縮」が人員削減の要因であると明記しています。同時に、2025年の一人当たり収益は、2022年の34.4万ドルから124万ドルに引き下げられています。この数字は非常に衝撃的です。しかし、Klarnaはその後、特に高単価でハイリスクなシナリオなど、一部の複雑なカスタマーサービスの問題を人手に戻し始めています。ここからの教訓も明らかです。AIは標準化され、反復的でプロセス化された作業を食い尽くすのは非常に得意ですが、複雑な判断、信頼性の保証、グレーゾーンの責任といった領域では、やはり人間が最後の砦として必要になるということです。\nShopify は、むしろもっと恐ろしいことを口にしました。2025年4月、Tobi Lutke が従業員に送ったメモは非常に率直でした。「より多くのheadcountを申請する前に、チームはなぜAIだけで物事を完結させられないのかを証明しなければならない」と。毎日ヘッドラインで人員削減が報じられるわけではありませんが、これは解雇リストよりもぞっとします。なぜなら、それは職の入り口自体が塞がれてしまうことを意味するからです。特に初級職や標準化して分割できるポジションにおいてそうです。\n市場が拍手喝采する理由 資本市場はAIの物語を聞くのが好きで、この件はもはや隠す必要がなくなりました。\n理由は単純です：\n売上は落ちず、むしろ伸びている。 人件費がまず下がる。 一人当たりの生産性がより良く見える。 後々の利益率とキャッシュフローの想像の余地が大きい。 そのため、Block の株価は「より小さなチームでもより多くのことができる」という理由で即座に買い上げられ、Duolingo は世論から批判されながらも、相変わらず良好な決算報告を得て、Klarna は AI と効率性を自身の上場ストーリーに組み込むことになるでしょう。\nここにはもちろん真の効率化は含まれていますが、明白な AI washing の要素もあります。多くの企業にとって、あるモデルが突然賢くなって部門全体を丸ごと廃止できるわけではなく、経営陣がついに「耳障りで、投資家に対しても説明しやすい理由」を見つけたのです。それは、過去数年間に拡大した人員配置を縮小し、自然退職した人の補充をやめ、一部の外部委託、カスタマーサービス、オペレーション、コンテンツ制作、初級分析といった業務を AI とより少ない人数で分担するというものです。\nなんて言うか、AI はここではツールであると同時に旗印でもある。\nこの風は、今もアメリカにありますか まだ、しかも 2026年3月までは、風が2025年よりも強くなっています。\nアメリカのレイオフ追跡機関であるChallenger, Gray \u0026amp; Christmasのデータは、問題をよく示しています。\n2025年通年で、企業が「AIを理由とする」人員削減計画は54,836人に達した。 2025年10月には、AIが当月の2番目に多く挙げられた人員削減理由となり、これに対応する職種数は31,039であった。 2026年3月になると、AIは初めて当月の米国企業から最も多く挙げられた人員削減理由となり、これに対応する職種数は15,341で、当月に開示された人員削減計画の約4分の1を占めた。 しかし、このデータも逆から見る必要があります。これはAIによる人員削減が現実のものであり、単なるジョークではないことを示しています。また、「すべての人員削減がAIによる代替である」という段階にはまだ達していないことも示唆しています。Challengerが2023年から追跡している範囲で、明確にAIによる人員削減と分類されたケースは、発表された全レイオフ計画のごく一部を占めるに過ぎません。言い換えれば、現在のアメリカは二つの力が重なり合っている状態です：\n一つの流れは真の自動化による代替であり、まずカスタマーサービス、コンテンツ、ローカライゼーション、初級ホワイトカラー、バックエンドプロセスを狙う。 もう一つの流れは、マクロな環境、コスト圧力、経営層による縮小という物語に、AIという外衣を被せることである。 そのため、ニュースの見出しだけを見ると「AIはホワイトカラー層全体を解雇した」と感じやすいですが、公式な見解だけを見ていると、それがすでに採用や組織構造の書き換えを始めていることを過小評価しがちです。\nこちら中国では、なぜアメリカのような状態になっていないのか 私は、中国が影響を受けていないのではなく、影響の現れ方が違うのだと考えています。\n公開された見解からすると、中国の 2025年から2026年にかけては、「AI人材を奪い合う」という側面が強く、「AIを使って人員削減を行う」というわけではないようです。\n新華社が2025年3月下旬の報道で、2月のアルゴリズムエンジニアと機械学習の職種の採用数が前年比でそれぞれ46.8%および40.1%増加し、AI人材の需給比は約3:1であり、明らかに需要が供給を上回っていると報じました。2026年2月には、新華社の別の記事で、2025年第4四半期の中国におけるAI関連職種の採用数が前年比でさらに19%増加していると触れられています。工信部が2026年3月に開示したデータによると、2025年の中国のコアAI産業規模はすでに1.2兆元を超え、関連企業は6,200社以上となっています。\nこのデータセットは、少なくとも2つのことを示しています。\n現在の中国における公開された主流なテーマは、依然として産業の拡大、モデルの実装、そしてAI人材の不足です。 真に不足しているのは、アルゴリズム、エンジニアリング、業界知識を組み合わせた人材であり、単なる一般的なオフィスワーカーではありません。 しかし、これがプレッシャーがないということではありません。\n国内はより静かに押し寄せているようです：\nアウトソーシング先の縮小。 新卒採用や初級職のポジションがより慎重になっている。 オペレーション、テスト、コンテンツ、カスタマーサービスといった標準化されたポジションが最初に削減されている。 かつては2〜3人で協力して行っていた雑務も、今では一人でAIを使いこなすことがデフォルトになりつつある。 そのため、「なぜ中国中でAIによる人員削減が叫ばれているのを見かけないのか」と感じるかもしれませんが、多くの職種の参入障壁はすでに狭まっており、単に投資家向けの公開書簡として大々的にパッケージ化されていないだけです。\n金融IT開発、最も警戒すべきは「明日置き換えられること」ではない 私自身も金融ITに携わっているので、この部分はより実感があるかと思います。\n短期的観点から見ると、金融業界のコアなプロセスにおける開発、特に取引、決済、リスク管理、コンプライアンス、監視、低遅延通信といった領域は、AIによって一律に置き換えられる可能性は低いと考えられます。理由は複雑ではありません。責任が重すぎ、監査が厳しすぎ、異常発生時のコストが高すぎるためです。何か問題が発生した場合、単にプロンプトを修正しただけで済むものではありません。\nしかし、別の側面も現実的です：\n「接着剤コード」を書く人はまず辛くなるでしょう。 純粋なCRUD、純粋なインターフェースの運搬、純粋なドキュメント整理といった価値は引き続き低下するでしょう。 テスト、運用スクリプト、レポート、内部ツールのような作業は、「AIと一緒に完了させる」ことがデフォルトになり、ますます多くなるでしょう。 チームには、個人の戦闘能力、業務理解度、アップストリームとダウンストリームを繋ぐ能力に対する要求が高まるでしょう。 率直に言って、今後数年間で最も危険なのは、「AI が開発を肩代わりする」ということそのものではなく、「会社が、AI を使いこなせる上に業務の境界線も理解している人材を標準装備し、それが以前の2〜3人の生産性に匹敵するものになる」ということです。もし開発者がコードの実務的な作業だけしか残らず、業務知識やリスク理解がなく、最終的な責任を負えない状態であれば、確かにますます不利になっていくでしょう。\n最後の一点、あまり良くない判断 Blockのこのニュースには衝撃を受けました。それはAIが金融テクノロジー企業を完全に掌握できるほど成熟したことを示しているからという理由ではなく、経営陣と資本市場がそう語ることに同意し、市場がそれを信じるようになったことを示しているからです。\nここが一番肝心なところです。\n技術的な成熟度は、まだそこまで誇張されたレベルではないかもしれません。しかし、組織はまず「これで十分だ」という前提で変更し、採用は「人を少し減らしても大丈夫だろう」という前提で変更し、昇進や業績評価もまた、「なぜAIをもっと活用しないのか」という視点から変わってくるでしょう。\n一般の開発者にとって、特に金融ITのように業務、コンプライアンス、システム安定性の間で挟まれる職種の場合、次にすべきことはAIと戦うことでも、盲目的に楽観視することでもなく、「コードの肉体労働者」から「業務を理解し、リスクを理解し、境界線を理解し、最終的な責任を持てる人材」へとできるだけ早くシフトしていくことです。\nさもないと、アメリカの風は、いずれ吹き付けてくるだろう。同じニュースの見出しでなくても、プレッシャーは同じ人物にかかることになる。\n参考資料 AP News：Fintech company Block lays off 4,000 of its 10,000 staff, citing gains from AI Block：Block Shares Multi-Year Financial Outlook at Investor Day Block：Block Fourth Quarter 2025 Earnings Call Klarna：AI assistant handles two-thirds of customer service chats in its first month Klarna Group plc 20-F TechCrunch：Klarna CEO says company will use humans to offer VIP customer service TechCrunch：Duolingo launches 148 courses created with AI after sharing plans to replace contractors with AI Duolingo：Q2 2025 results TechCrunch：The backlash against Duolingo going \u0026lsquo;AI-first\u0026rsquo; didn\u0026rsquo;t even matter TechCrunch：Duolingo CEO says controversial AI memo was misunderstood TechCrunch：Shopify CEO tells teams to consider using AI before growing headcount Challenger：2025 Year-End Challenger Report Challenger：March 2026 Challenger Report 新华社：China\u0026rsquo;s rapid AI growth sparks hiring boom as demand outpaces supply [新华社：AI reshapes China\u0026rsquo;s workforce via new professions, constant learning, one-person startups](https://english.news.cn/20260204/8d1bd05e8c4240998206fb9b 作成上の注記 元のプロンプト 最近1年間のAIによるレイオフ、大規模な人員削減、それ以降の企業の経営状況、市場の反応について整理してほしい。現在もアメリカでレイオフの風が吹いているのか、中国国内への波及は少ないのか。私は金融IT業界の開発者だが、Blockのレイオフのニュースには非常に衝撃を受けた。\nライティングのアイデア概要 「Block」のニュースから切り込み、まず「金融IT開発者が衝撃を受けている」という個人の視点を維持する。 全てのレイオフをAIのみに粗暴に帰因させるのではなく、「公表された人員削減」「増員凍結」「エントリーレベルの職種の圧迫」の三層に分解する。 Block、Duolingo、Klarna、Shopifyという代表的な4つのサンプルを選び、それぞれについて、レイオフ、増員凍結、事業結果、市場の反応を見る。 中国の部分は「問題ない」と断定的に書くのではなく、「アメリカほどではないが、構造的な圧迫は始まっている」というトーンにする。 結論では判断を金融IT開発者の実際の状況に戻し、重点を感情論ではなく、職業構造の変化に置く。 ","date":"2026-04-16","language":"ja","permalink":"https://ttf248.life/ja/p/ai-layoffs-and-hiring-freeze/","tags":["AI霊感衝突坊","ai","人員削減","職場","金融"],"title":"解雇されること自体が恐ろしいのではなく、補充されなくなることが怖い。","year":"2026"},{"categories":null,"content":"最近引っ越したため、自宅のブロードバンドを電信から聯通に変更しました。普段ドラマを見たりゲームをしたりする分には、特に何も感じませんが、先日資料をダウンロードしようとして、癖でアメリカノードに切り替えたところ、どうやっても速度が上がらず、私は少し呆然としました。\nこの件は後になって理解できました。以前は、アメリカのデータセンターの帯域幅が十分与えられているから、アメリカのノードは元々より強力だとずっと思っていました。今見ると、その認識は半分しか正しくありません。アメリカのサーバーのリソースが豊富であることは一つの側面ですが、国内でどの回線を使うか、国際出口をどう通すか、戻りの経路でより良いバックボーンを利用できているか、というのがもう一つの側面です。以前は中国電信を使っていたので露呈しなかった問題が、ユニコムに替わってからは全て明らかになりました。\n平常では本当に見つけにくい このような差異は、普段は気づかれやすいものです。\nドラマを見る場合は動画プラットフォーム独自のスケジューリングが使われることが多く、クロスボーダー帯域を常に最大に引き出す必要はありません。ゲームの場合は遅延の揺らぎやノードの安定性がより重要で、実際に大容量ファイルのダウンロードや高帯域幅での継続的な実行になると、回線が適切かどうかが一目瞭然になります。\nそのため、今となってはダウンロード速度こそが最も正直な測定だと感じています。普段はすべて正常だと感じるかもしれませんが、それはこの道が本当に広いということではなく、単に限界まで走らせていないだけなのかもしれません。\nかつてアメリカのノードはフル稼働できたので、アメリカのデータセンターだけが優れているわけではない 中国电信が独自に公開している資料によると、ChinaNet は同社のメインの広域網であり、CN2 (AS4809) は低遅延と高品質を強調した次世代のグローバルバックボーンネットワークで、国際的な品質をより重視するビジネス向けです。この件は多くの人が聞いたことがあり、普段空港の業者はこれをセールスポイントとしてよく使います。\nそのため、以前は電気通信のブロードバンドを利用していて、アメリカノードに切り替えるだけでダウンロード速度を上げることができましたが、今振り返ると、「アメリカが生まれつき速い」というよりは、「アメリカのデータセンターリソース ＋ ノードの上流回線 ＋ 電気通信側の国際ルーティング」がたまたま重なっただけだと思います。回線が電気通信にとって好都合な方向に当たると、体感は本当に良くなりますね。\n率直に言って、以前のスピードは、ノード全体が強いというよりは、私がちょうど有利な側に立っていただけだと思います。\n中国聯通は国際回線がないわけではないが、以前と同じルートとは限らない しかし、この件を単に「中国電信網への依存」と理解することはできません。\n中国聯通独自の国際ネットワークもそれなりに大きい。联通の国際公式サイトには明確に記載されており、そのバックボーン網である AS4837 は世界中に 400以上の PoP を持ち、さらに品質の高いキャパシティを担う AS9929 も持っている。カバレッジで見ると、シンガポール、台湾、アメリカといった地点には自前で展開している。\nしかし、問題はここにあります。「国際回線がある」ことと、「今購入したプロキシノードがたまたまこのキャリアにフレンドリーである」ことは、別物なのです。\n家庭のブロードバンドユーザーが真に感じるのは、キャリアが海外リソースを持っているかどうかだけではなく、以下の点も含まれます。\nお客様のローカルキャリアはどちらですか プロキシサービスプロバイダーが購入するアップストリームはどちらの帰り回線に傾いていますか ノードの往路と復路は同じ種類の最適化ですか ピーク時に混雑はありますか このリンクは中国电信寄りですか、それともユニコムや移動体通信寄りですか 多くの米国のノードについて、以前は中国電信（China Telecom）を使っていた時は回線が満杯になるほど使えたのですが、聯通（China Unicom）に替えてからは駄目になりました。私はこれを「これらのノードの回線構成自体が、元々中国電信寄りのものなのだ」と理解する方がしっくりきます。以前はそう思わなかったのは、自分自身が中国電信を使っていたからかもしれません。\nなぜシンガポールと台湾が逆に順調なのか これもかなり面白いですね。\n聯通に乗り換えた後、アメリカのノードはダメになりましたが、シンガポールと台湾はかなり快適になりました。この変化の方が、「アメリカのノードの速度低下」よりも問題をよく示しています。\n私の理解では、アジア方面は元々より近く、経路が短く、地域間の相互接続も密です。联通（China Unicom）自身がシンガポールと台湾の両方にネットワークリソースとPoPを持っているため、このような状況で代理サービスプロバイダーがアジアのノード上でよりスムーズな地域パスを提供すれば、ダウンロード速度は自然と出しやすくなります。\nこれはシンガポールや台湾のデータセンターがアメリカより優れていることを意味するわけでもなく、すべてのブロードバンド接続でアジアノードを選ぶべきだという意味でもありません。むしろ、現在お使いのブロードバンド回線とこれらのリージョンノードとの相性が高いということのようです。\nどう言えばいいか、ノードの強さは、単にデータセンターの場所だけでは決まらない。結局は、自宅からの道のりがあなたを認めてくれるかどうかを見なす必要があるんだよ。\nこの件で、私のこれまでの認識が修正されました 私の以前の考えはかなり単純でした。アメリカのデータセンターは大きく、ブロードバンドのリソースが豊富なので、資料をダウンロードする際はアメリカのノードを選ぶのが基本で、間違えることはないと考えていました。\n今のところ、この判断はあまりに大雑把です。\nより正確な言い方としては、\nアメリカのノードが満杯かどうかは、単にアメリカのデータセンターだけを見ているわけではなく、あなたの家のブロードバンドがどのバックボーンネットワークに接続されているかにも左右されます。\n電信ユーザーが快適に使える回線でも、ユニコムに変わると必ずしもそうとはいかない。逆にユニコムの下の方がスムーズなシンガポールや台湾も、「アジアのノードが急に強くなった」わけではなく、単に回線がようやくしっくりきただけだ。\nそのため、今後プロキシやノードを選ぶ際は、アメリカに固執することは少なくなるでしょう。まず自分の回線がどのようなものか、次にサービス提供者がどの回線に重点を置いているかを見る方が、「データセンターがアメリカにあるかアジアにあるか」よりも重要になります。\nあー、こういう差は、普段ドラマを見たりゲームをしたりしているだけではなかなか気づきにくいですね。実際に大きなファイルを扱うとなると、回線（帯域）の実力が一気に表れちゃいますね。\n参考資料 China Telecom Americas: IP Access / Global Internet Service（CN2、ChinaNet 介绍） China Unicom Global Singapore: DIA（AS4837、AS9929 介绍） China Unicom Global Europe: Global Presence（新加坡、台湾、美国等海外节点） 作成上の注記 元のプロンプト プロンプト：中国本土で代理ソフトウェアを使い、科学的にインターネットに接続する方法を試したところ、中国電信と聯通のブロードバンドの違いに気づきました。普段ドラマを見たりゲームをしたりするだけでは、その違いはほとんど分かりません。資料をダウンロードすることがたまにあるのですが、アメリカのノードを選ぶことが多く、そちらのノードだとダウンロード速度がほぼ最大まで出ます。これは以前の認識とも一致しており、アメリカのデータセンターのサーバーは十分なブロードバンドリソースを提供していると感じていました。最近引っ越しをして聯通の回線に切り替えたところ問題に気づきました。アメリカのノードではダウンロード速度が出なくなりました。シンガポールや台湾に切り替えるとかなり良くなりました。これは中国のブロードバンドのバックボーンネットワーク、つまりCN2高速バックボーンネットワークがすべて電信のものなので、聯通は電信の回線を借りているという関係に関係しているのだと思います。\nライティングのアイデア概要 「引っ越しで回線を変えて初めて違いに気づいた」というリアルなトリガーポイントは維持し、記事を単なるネットワークの科学解説にしない。 コアとなる判断基準は「ノードの速さだけでなく、国内回線と国際ルーティングも見る必要がある」という点を維持する。 CN2、中国光通信（Unicom）の国際バックボーン、および海外PoPについて補足的な検証を行い、「中国光通信は電信網に完全に依存している」という記述をより正確な表現に修正する。 シンガポールや台湾が速い点については、「地域パスが短い」「回線マッチング度が高い」といった形で説明し、絶対的な法則として断定しない。 構成としては、まず体感（実体験）から書き始め、次にその理由を解説し、最後に「今後どのようにノードを選ぶべきか」という結論に落とし込む。 ","date":"2026-04-16","language":"ja","permalink":"https://ttf248.life/ja/p/us-nodes-not-as-good-after-switching-to-china-unicom/","tags":["AI霊感衝突坊","ブロードバンド","ユニコム","通信","ネットワーク"],"title":"聯通に引っ越してから、アメリカのノードが急にそれほど良くなくなった。","year":"2026"},{"categories":null,"content":"昨日書いた《HermesをOpenClawの代替品と見なすのは危険かもしれない》を書き終えた後、私は周りのドキュメントを巡回しました。巡るほど、この二つのものの違いを見るには、機能だけを見ているだけでは不十分で、トークンがどのように消費されるかを見る方が、より直接的だと感じました。\n私の判断は、まずここに置きます。\nOpenClaw はデフォルトで長期的にオンラインのワークベンチのようなものであり、多くのアイデンティティ、ルール、ワークスペースファイル、メッセージ面制約などが自然に各対話フローに引き継がれるため、ベースラインは通常重くなります。一方、Hermes は明らかに抑制的で、多くのコンテキストはオンデマンドで発見され、オンデマンドで注入されます。システムプロンプトも意図的に安定したプレフィックスを維持しており、デフォルトではトークンを抑えやすいです。\nもちろん、これはHermesが必ずしもより節約できるという意味ではありません。memory provider、skills、sub-agent、長いツール出力をすべて有効にすると、同じように大量のトークンを消費します。しかし、率直に言って、これら2つのアーキテクチャは、初日から異なる方法でトークンを消費しています。\nOpenClaw はなぜデフォルトでより重いのか OpenClaw の設計ロジックは、元々「軽いエージェントを一つ出して、ちょっとおしゃべりする」というものではなく、「まず長期的に存在するエージェントのワークステーションを構築する」というものです。この点は公式の workspace ドキュメントに非常に明確に書かれています。\nAGENTS.md、SOUL.md、USER.md はセッションごとにロードされます。IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOT.md、MEMORY.md といったファイルも、同じワークスペース内で巡回します。ドキュメントはさらには、HEARTBEAT.md は非常に短く保つよう注意喚起し、トークン消費を避けるように促しています。このような注意喚起自体が、OpenClaw が自身のデフォルトのコンテキストが比較的厚いことを明確に示しています。\nしかし、一つ明確にしておくべき点があります。OpenClaw はすべてを無条件で全文常駐させるわけではありません。公式のトークンドキュメントには、skills をシステムプロンプトに組み込む場合、デフォルトでは単なるメタデータであり、具体的な説明は必要に応じて read する必要があると明記されています。したがって、問題は「節約ができない」ことではなく、「デフォルトで持っていく土台自体が元々大きい」ということです。\nこの件は実は理解しにくいものではありません。OpenClaw が解決しようとしているのは、「長期的なオンライン状態」と「複数のメッセージ面での存在感」です。\nTelegram、Discord、Slack、WhatsAppといった複数の場所に同時に存在し、アイデンティティ、ルーティング、境界線、委任（delegate）を伴いながら活動させる場合、多くのルールは後から付け足すものであってはなりません。それはまず自分自身が何者であるか、どのように話すべきか、誰に向き合っているのか、現在のワークスペースの制約は何か、スキルをどこから取得するのか、どの記憶を持ち運ぶべきで、どの記憶を持ち運んではいけないのかを知る必要があります。\nそのため、OpenClaw のトークン消費は、より固定のオーバーヘッドが大きい傾向があります。\nメッセージを送信するたびに、単にモデルに一文を話しかけているのではなく、すでに完成された「アシスタント環境」全体を呼び出しています。この環境は使いやすいのですが、その代償としてベースとなるプロンプトがより厚くなり、たとえ今回のターンで直接使われなくても、多くのコンテキストがそこに保持されることになります。\nHermes はなぜより抑制的に見えるのか Hermes の件ですが、ドキュメントの中で最も興味深い点は、常に2つのことを強調している点です。それは「オンデマンドローディング」と「プロンプトキャッシュの保持」です。\nまずコンテキストファイルをチェックしてください。Hermesはセッション開始時に、現在の作業ディレクトリでヒットした種類のプロジェクトコンテキストのみをロードします。AGENTS.mdやCLAUDE.md、.cursorrulesなどは「最初に見つかったものが採用される（first match wins）」ため、すべてが一度に読み込まれるわけではありません。さらに重要なのは、サブディレクトリ内のAGENTS.mdは起動時にすべて読み込まれるのではなく、実際にそのディレクトリに移動し、そのファイルを読み込み、そのパスに到達したときに、段階的に発見され、段階的に注入されるということです。\n公式ドキュメントでは、この設計の利点が明確に書かれています：\nシステムプロンプトの肥大化なし プロンプトキャッシュの保持 この味はOpenClawとは全然違いますね。Hermesが言っているように、システムプロンプトは長すぎない方がいいし、後回しにできるコンテキストは後回しにして、関連するタイミングでのみ出現するものなら、最初のラウンドで詰め込みすぎない方がいいですよ。\nskills も同じ考え方です。Hermes の skills ドキュメントには、プログレッシブ・ディスクロージャー（段階的開示）が明確に書かれており、目的はトークン使用量の最小化です。言い換えれば、skill はデフォルトで全文常駐するのではなく、モデルにまず軽量なインデックスを見せ、本当に必要なときだけ具体的な内容を展開させるということです。\nデータマイニング ディープラーニング ニューラルネットワーク そして、その記憶システムも組み合わせ型に偏っています。公式ドキュメントでは組み込みメモリが厳しく制限されており、MEMORY.md は約 800 トークン、USER.md は約 500 トークンで、合計すると固定のコンテキストウィンドウは約 1300 トークンになります。SOUL.md は固定のアイデンティティであり、USER.md とメモリはシステムプロンプトに含まれますが、セッション検索やメモリプロバイダー、Honchoなどはより外部レイヤーのようなものです。この構造自体がプロンプトを自然に短くするわけではありませんが、コスト管理がしやすいデフォルトの姿勢を提供しています。\nそのため、アーキテクチャの観点から見ると、私はHermesを「デフォルトでは控えめだが、徐々に重みを増していく」と分類する方が気が進みます。\nこれは誰がより進んでいるかではなく、どこにコストをかけるかである 多くの比較記事は、トークン消費を単一の結論として記述する傾向がありますが、これは適切ではないと思います。\nOpenClaw が重いのは、設計が悪いからではありません。むしろ、意図的に多くのものを前置しているのです。長期オンラインで、クロスプラットフォームで、パーソナリティを持ち、ワークスペースとルーティングを備えたアシスタントを求めるなら、これらのコンテキストにはいずれコストがかかります。単にデフォルトのパスでこれらを一式揃えているだけです。\nHermes はより抑制的ですが、それがないわけではありません。長い SOUL.md やプロジェクトの AGENTS.md、複数のスキル、MCP、メモリプロバイダー、サブエージェント、長いツール出力などを重ねると、トークンはやはり速く消費されます。特にツールの結果自体が非常に長い場合や、複雑なコードベース内を何度も検索させる場合は、アーキテクチャ名だけで節約できるわけではありません。\nしたがって、より正確な言い方は以下の通りです。\nOpenClaw は、コストを「アシスタント環境の常駐」に前倒しします。\nHermes はコストを「必要な時に能力を展開する」ことに後置します。\nこれら二つのアプローチに絶対的な優劣はありませんが、請求書の構造が全く異なります。\n本当に差がつくのは、システムプロンプトだけではない 他にも、見落とされがちな細かい点があります。\n第一に、Hermes は context files の部分を安定したプレフィックスにするように設計されています。サブディレクトリの hint は、関連するツールの結果に追加されるものであり、すべてのプロジェクトコンテキストを system prompt に絶えず流し込むわけではありません。このアプローチはトークンを節約するだけでなく、本質的にはプロバイダーのプロンプトキャッシュのためのスペースを確保しているとも言えます。\n第二に、Hermes の execute_code のようなツールは、設計上、スクリプトが最終的に print() で出力した結果のみをモデルに返すように設計されており、途中の RPC ツール呼び出しの結果がすべてコンテキストに入るわけではありません。複雑なフローの場合、この構造により、無意味なツールのノイズを大幅に削減できます。\nOpenClaw のワークスペースの哲学は、「家財道具を全部持っていく」というものに近いです。たとえ個々のファイルが短くても、種類が多い、人格レイヤーが多い、ルールレイヤーが多い、スキルや記憶の階層が多いだけで、基本的なコンテキストは少しずつ厚みを増していきます。この厚みはバグではなく、製品としての取捨選択によるものです。 第四に、両側がサブエージェントの処理を行うことも、総勘定書に影響を与えます。Hermes の多くの設計はローカルなコンテキストとローカルな実行を強調していますが、OpenClaw は複数のエージェントのアイデンティティ、ルーティング、委任といった組織能力をより重視しています。一方はコンテキストを切り替えるようなものであり、もう一方は存在関係を組織するようなものです。最終的にトークン料金に落とし込むと、形状は当然異なります。\n本当に計算するなら、口先だけではダメだ 長期的に使うつもりなら、誰かが「こっちの方が節約になる」と言っても鵜呑みにせず、ツールが出したデータを見てください。\nOpenClaw の公式ドキュメントには、/context detail や /usage tokens のようなコマンドがあり、ドキュメントでもセッション開始時にどのファイルが注入されるか通知してくれます。これはベースディスクがどれだけ分厚いかを見るのに非常に適しています。\nHermes の件ですが、公式ドキュメントの Honcho や関連する機能において、トークンバジェット、スキルプログレッシブディスクロージャー、コンテキストファイル注入の方法といった手がかりが提供されています。これらは hermes insights、セッションストレージ、および実際のプロバイダーの請求書と合わせて確認できます。\n要するに、アーキテクチャは「どう使うか」しか決められず、「どれだけ使うか」までは決めてくれない。実際に請求額を決めるのは、君が書いた SOUL.md の長さ、詰め込んだ記憶の量、開いたスキル数、ツールの出力をどれだけ取り込めたか、そしてモデル自体の価格だ。\n結局、私はこの側に立つ デフォルトのアーキテクチャだけを見て、極端な設定は考慮に入れなければ、私はやはり Hermes の方がトークンの消費を比較的抑制された範囲に抑えやすいと考えています。\nより強力だからではなく、プロンプト設計の段階から「無意味な永続コンテキストの膨張」を回避し続けているからです。OpenClawはそれとは対照的で、多少多く持っていくことを厭わずとも、その長期オンラインアシスタントとしてのアイデンティティ、ワークスペース、メッセージングインターフェースの境界が崩れないことを保証します。\nそのため、トークンコストを特に気にする場合や、ワークフローが主にローカル、CLI、コードリポジトリ、スキル蓄積といったシナリオで発生する場合は、Hermesのアプローチの方が一般的に扱いやすいでしょう。\nもしあなたが、様々なメッセージの場に本当に常駐する長期アシスタントを求めているのであれば、OpenClawはトークンを多めに使う方が、むしろ正常な対価だと思います。まるで人間のように常にオンラインでありながら、毎回使い捨ての小さなツールであるかのような軽さを要求することはできませんから。\nああ、結局この件はまた元の問題に戻ってきましたね。\nあなたはオンラインアシスタントを育てているのか、それともローカルエージェントコアを育てているのか。これを明確にすれば、トークン計算はそれほど難しく感じなくなるはずだ。\n参考資料 前の記事：Hermes を OpenClaw の代替品と見なすのは、最初から偏っているかもしれない Hermes Agent Features Overview Hermes Agent Context Files Hermes Agent Personality \u0026amp; SOUL.md Hermes Agent Skills Hermes Agent Built-in Tools Reference Hermes Agent Honcho Memory OpenClaw Agent Workspace OpenClaw Token Use and Costs OpenClaw Memory OpenClaw Multi-Agent Routing OpenClaw Context Reference 作成上の注記 元のプロンプト プロンプト：Hermes と OpenClaw について、両者のトークン消費状況に関する記事をもう一つ書いてください。アーキテクチャが異なるため、消費量も当然異なります。\nライティングのアイデア概要 前回の記事の判断を引き継ぎつつ、論点をトークン消費に絞り込み、全体的なアーキテクチャ比較は繰り返さない。 「どちらが省」といった空論ではなく、両者のデフォルトのコンテキストアセンブリ方法を重点的に比較する。 Hermes はプログレッシブディスカバリー（段階的開示）、オンデマンドでの発見、およびプロンプトキャッシュの保持に焦点を当てる。 OpenClaw はワークスペース常駐ファイル、長期オンラインアシスタント環境、固定オーバーヘッドに焦点を当てる。 結びではユーザーが提示した核心的な判断は維持しつつも、「実際の請求書を見るなら、公式の usage/context ツールと実際のプロバイダーの課金体系を考慮する必要がある」という現実的な注意喚起を補足する。 ","date":"2026-04-16","language":"ja","permalink":"https://ttf248.life/ja/p/hermes-openclaw-token-usage-diff/","tags":["AI霊感衝突坊","ai"],"title":"アーキテクチャが変わったので、HermesとOpenClawのトークンの消費方法は違います。","year":"2026"},{"categories":null,"content":"この二日間、HermesとOpenClawのドキュメントを何度も読み返しましたが、読むほどに、多くの人がこれら2つのプロジェクトを一緒にして比較していますが、実は最初から比較の軸がずれていると感じました。\nもちろん、これらはすべて「パーソナルAIアシスタント」を構築しています。メッセージの受信、モデルの呼び出し、ツールの実行、そしてある程度のコンテキスト保持が可能です。Hermesはさらにはhermes claw migrateという専用コマンドまで用意しており、OpenClawユーザーの一団を受け入れることを明白に知っているようです。\nしかし、端的に言えば、Hermes は OpenClaw のスキン変更版ではなく、OpenClaw もメッセージ入力口がいくつか増えたエージェントフレームワークではありません。一方は Gateway から外側へ伸びていき、もう一方は AIAgent から外側へ伸びています。この違いを先に理解しないと、後でアーキテクチャや設計思想、エコシステムについて話しても、どんどん話が混乱していきます。\nそれらは最初から一つのものになるつもりではなかった OpenClaw の公式ドキュメントでは Gateway を非常に早い位置に置いています。その定義は非常に直接的です。長期実行される Gateway がすべてのメッセージ面を保持し、コントロール面クライアント、Web UI、Node デバイスがすべてこの Gateway に WebSocket 経由で接続します。さらに、ホスト上にはコアなメッセージ接続を管理する Gateway は一つしかなく、WhatsApp のようなセッションも明確にそれが独占します。\nこれはどういう意味ですか？それは、OpenClaw の世界観が「まずエージェントがあり、それにいくつかのインターフェースを接続する」というものではなく、「まず常駐の通信および制御プレーンがあり、その中にエージェントランタイム、セッション、スキル、デリゲート、サブエージェントなどをすべて編成する」ということです。\nHermes はこの味ではない。そのアーキテクチャ図は最初から非常に明確で、CLI、Gateway、ACP、Batch Runner、API Server、Python Library といったエントリポイントがすべて同じ AIAgent コアに集約されている。セッションストレージは SQLite + FTS5 であり、ツールバックエンド、プロバイダー解決、プロンプトビルダーはすべてこのコアを中心に構成されている。\nそのため、骨格から見ると、OpenClaw は「常駐型のパーソナルアシスタントシステム」に近く、Hermes は「エージェントランタイムプラットフォーム」に近く、メッセージ入力は単なるその延長面の一つに過ぎません。\nGatewayを主役にしたものと、Agentを主役にしたもの このアーキテクチャの違いは、最終的に利用体験の違いに直結します。\nOpenClaw の強みは、「多くのチャネルで長期的にオンラインで存在し、アイデンティティと境界を持ち、ルーティング可能なアシスタントをどう持つか」という点に非常に力を入れていることです。デフォルトの DM ペアリング、セキュリティポリシー、チャネル/アカウント/ピアごとのルーティング、マルチエージェントバインディング、デリゲートモードがあり、さらには「誰になりすまして発言するか、どの口座で受信するか、どのグループに出現するか」といった組織レベルの問題までドキュメント化されています。\n言い換えれば、OpenClaw がまず解決したいのは存在性の問題です。このエージェントは、まず本物の人間か、あるいは真の組織アシスタントのように振る舞い、Telegram、Discord、Slack、WhatsApp、Signal、WebChatといったプラットフォーム上で生きている必要があります。その後に、コードを書けるかどうか、タスクをディスパッチできるかどうかを議論するのです。\nHermes の重点は「能力の蓄積」にあります。もちろん Gateway もあり、Telegram、Discord、Slack、WhatsApp などのプラットフォームにも接続できますが、公式な説明の中で最も前面に出ている単語は、ルーティングやアカウントではなく、persistent memory、skills、MCP、sub-agents、toolsets、さらには batch processing、trajectory export、RL training です。\nここが重要です。Hermes が解決すべき中心的な問題は、「いかに多くのメッセージングプラットフォームに AI を接続するか」ということではなく、「このエージェント自身が段階的にスキルや記憶、再利用可能な能力を育み、さらには訓練データや実験として使えるようにすること」なのです。\nそのため、私はこのように要約するのがより良いと思います：\nOpenClaw はコミュニケーションファーストのパーソナルアシスタントシステムです。\nHermes は agent-core-first のセルフホスト型エージェントプラットフォームです。\n記憶、スキル、そして拡張の方法も、一つの味ではない 多くの人が「これら2つともskill、memory、pluginをサポートしているのでは？」と言うでしょう。その通り、どちらもサポートしています。しかし、焦点が違います。\nOpenClaw のエージェントランタイムにおいて、ワークスペースは非常に重い概念です。AGENTS.md、SOUL.md、TOOLS.md、BOOTSTRAP.md、IDENTITY.md、USER.md といったファイル群は、新しいセッションの最初のラウンドで直接コンテキストに注入されます。スキル（技能）のロードにも一連の優先順位があり、ワークスペース内のもの、プロジェクト内のもの、個人ディレクトリ内のもの、~/.openclaw/skills 内のもの、バンドルされたもののすべてが積み重なります。本質的には、「ペルソナ + ルール + ワークスペース + チャネル」を統合した長期的なアシスタント環境を構築しているのです。\nHermes のスキルシステムは明らかに「手続き的記憶」に偏っています。公式ドキュメントには、skills はオンデマンドの知識ドキュメントであり、プログレッシブディスクロージャーを採用し、agentskills.io のオープン標準に対応しており、すべて ~/.hermes/skills/ 以下に統一して配置され、さらにエージェント自身がスキルを修正・削除できると明記されています。これは単に「アシスタントに説明書を数冊渡す」という感じではなく、「実行したことを再利用可能な能力ブロックとして蓄積する」という感覚です。\n記憶も同じです。Hermes には控えめな MEMORY.md と USER.md が組み込まれており、これに SQLite + FTS5 のセッション検索と、さらに 8 種類のメモリプロバイダーを外付けしています。この設計は非常に興味深く、最初から「長期的な人格環境」を厚く記述するのではなく、短期記憶、検索式回想、外付けの長期記憶を分離している点です。\nOpenClaw は記憶がないわけでもなく、サブエージェント、マルチエージェント、デリゲートといった高度な能力を持たないわけでもありません。むしろ、それらは十分に備わっています。しかし、ドキュメントの構造とデフォルトの思考モデルから見ると、それは継続的にオンラインのアシスタントワークスペースを運営しているように見えます。一方、Hermes は絶えず進化するエージェント能力グラフを運営しているように見えます。\nエコシステムはなぜ離れていくのか エコシステムに関しては、表面的にはすべて「オープンソース＋拡張可能」に見えますが、実際には分岐が非常に明確です。\nOpenClaw のエコシステムはより広く、外部接続レイヤーに重点を置いています。公式プラグインでは、channels、model providers、tools、skills、speech、web fetch、web search、memory を拡張でき、コミュニティプラグインや ClawHub も「より多くのプラットフォーム」「より多くのアカウント」「より多くのワークフロー」への接続を目指しています。さらには、.codex-plugin、.claude-plugin、.cursor-plugin のようなバンドル形式との互換性も明言しています。この動きは非常に賢く、要するに他社のエコシステムの「殻」を先に取り込み、入口（エントランス）を大きくしようとしているのです。\nOpenClaw のドキュメントを再確認すると、sub-agent、delegate、組織エージェント、thread binding、DM pairing、group mention などについて非常に詳細に記述されていることがわかります。これは単なるシングルマシンプレイヤーの遊び場ではなく、真に長期的に動作するエージェントオペレーティングシステムになることを目指していることを示しています。\nHermes のエコシステムは、「コア機能の外部接続」という側面が強いです。Python プラグインシステムがあり、メモリプロバイダープラグインがあり、コンテキストエンジンプラグインがあり、MCP サーバーへの接続もあり、さらに Skills Hub や agentskills.io のようなオープンなスキル標準があります。これに加えて、バッチランナー、トラジェクトリエクスポート、Atropos といったトレーニング関連のインターフェースがあるため、Hermes のエコシステムは自然と二種類のユーザー層を引きつけます。\n一方は、それを個人のエージェントとして使う人です。\nもう一つの分類は、それを研究、トレーニング、実験、ワークフローの基盤として利用する人々です。\nこの2種類のユーザーのニーズは大きく異なりますが、Hermesのアーキテクチャはどちらもカバーできます。そのため、HermesのエコシステムはOpenClawのように「チャネル数」や「メッセージの存在感」で先行して広がるわけではないと感じるかもしれませんが、私はむしろ、エージェント基盤（agent substrate）におけるその潜在力の方が大きいと感じています。\nさらに興味深い詳細があります。Hermesの公式READMEにはhermes claw migrateだけでなく、コミュニティプロジェクトであるHermesClawも掲載されており、これを使うことで同じWeChatアカウント上でHermes AgentとOpenClawを同時に実行できます。このシグナルは非常に明白です。Hermesは自分とOpenClawが関係ないふりをしているのではなく、ユーザーの移行パスが存在することを認め、さらにそのパスを製品化して提供しているのです。\n私の最終的な判断 もしあなたが「本当にメッセージングレイヤー上で動作する個人アシスタントシステム」を求めているのであれば、アカウント、チャネル、ルーティング、デリゲート、組織境界、常時オンライン、強力なコントロールプレーンが必要なのであれば、OpenClawの道筋の方がより完全であり、成熟した通信基盤に近いです。\nもしあなたが「使うほど自分専用のワークステーションのように馴染むエージェントコア」を求めていて、スキル蓄積、メモリの組み合わせ、MCP、プラグイン、サブエージェント、学習データ、そしてその後の可塑性を重視するなら、Hermesの方が使いやすいでしょう。\nですから、「Hermes は OpenClaw に取って代われるか？」といった単純な質問はもうしないでください。その質問の仕方が少々粗雑です。\nより正確な聞き方は以下の通りです。\nメッセージングネットワーク内に存在するAIアシスタントを求めているのか、それともローカルのワークフローやエージェントランタイムに組み込まれるAIプラットフォームを求めているのでしょうか？\nこれをしっかり理解すれば、選択はそれほど迷いませんよ。\n参考資料 Hermes Agent GitHub README Hermes Agent 公式サイト Features Hermes Agent Architecture Hermes Agent Skills System Hermes Agent Persistent Memory Hermes Agent MCP Hermes Agent Plugins OpenClaw GitHub README OpenClaw Gateway Architecture OpenClaw Agent Runtime OpenClaw Multi-Agent Routing OpenClaw Delegate Architecture OpenClaw Sub-Agents OpenClaw Plugins OpenClaw Skills Config 作成上の注記 元のプロンプト プロンプト：HermesとOpenClawの違い、アーキテクチャ上の違い、設計思想上の違い、エコシステムの違い\nライティングのアイデア概要 「代替品比較」というよくある質問形式は外し、「二つのプロジェクトの中心がどこにあるのか」というメインラインに直接絞る。 アーキテクチャ部分は、コミュニティによる二次的なまとめではなく、公式ドキュメントのメインエントリとコアコンポーネントを優先して参照する。 設計理念の部分では、抽象的な価値判断は行わず、Gateway、Agent Core、memory、skill、delegateといった具体的な設計に落とし込む。 エコシステム部分は、星マークや人気度、コミュニティでの憶測合戦はせず、拡張の方向性に重点を置く。 事実確認は、2026年4月15日時点で公開されている公式リポジトリと公式ドキュメントを基準とする。 ","date":"2026-04-15","language":"ja","permalink":"https://ttf248.life/ja/p/hermes-openclaw-not-the-same-game/","tags":["AI霊感衝突坊","ai"],"title":"Hermes を OpenClaw の代替品として見ると、最初は偏りがあるかもしれません。","year":"2026"},{"categories":null,"content":"最近AIを使ってC++の小規模なプロジェクトを立ち上げたんだけど、一番「やられる」瞬間は、それがコードを書いてくれないことじゃなくて、たった3分でそれっぽくディレクトリツリーを組み立ててくれて、ついでにサードパーティライブラリをいくつか突っ込んで、デモが本当に動く時なんだよね。問題もそこにある。新しく導入したライブラリが具体的に何に対応しているのか、コンパイルのパスはどうなるのか、どこに境界線があるのか、まだ把握できていないのに、後で手戻りが発生するのはほぼ避けられない。\n最近、AIプログラミングで最も怖いのはモデルの賢さではなく、最初からやりすぎなところだと感じています。特にC++のような、しっかりしたフレームワーク（脚手架）に頼れない言語の場合、手順を一つ間違えるだけで、コンパイル、リンク、ライブラリのバージョン、ディレクトリ構造など、後でいくつもの手間が増えてしまいます。\nこの件について、私自身の結論は非常に明確です。AI は、初期設計や依存関係の決定をすべて肩代わりするのではなく、急速に推進力のあるペアプログラマーとして適しています。GitHub のドキュメントでは、最初はより簡単なタスクから始めるよう推奨しており、エージェントにバグ修正、ドキュメント作成、テスト、技術的負債といった境界がより明確な作業を先にこなしてもらうべきだと述べています。一方、Anthropic の Plan Mode のドキュメントは、むしろ複雑な変更に対する保険のようなものであり、「まずコードを読み、計画を立ててから、修正するかどうかを決める」という流れです。両者の主張は完全に一致しているわけではありませんが、指し示す方向性は似ています。最初から最も難しく、最も混沌としていて、依存関係が最も多い塊をすべてAIに丸投げするのは避けるべきです。\nそのため、この記事では大量の仕様を語るのではなく、すぐに手を動かせる小さなケーススタディを提供します。任意の空のC++リポジトリがあれば、これに従って作業できます。\nAIじゃないからダメなのではなく、最初の一手が貪欲すぎるからだ 人工知能のプロジェクト、特にC++の場合、多くの時は非常に原始的な方法になりがちです。\nまずは main.cpp から最小実行可能なバージョンを始める まずコンパイルのリンクを通す その後、どのライブラリを導入するか決める 一歩進むごとにビルドできることを保証する ビジネスの輪郭が見えてから、リファクタリングを開始する この方法は遅く見えるかもしれませんが、実際は非常に安定しています。なぜなら、どのステップで何を得たのか、そして問題がどのステップから生じているのかをすべて知っているからです。\nAI はこのリズムを崩しやすいです。一気に「完璧に手伝ってくれる」のが好きなんです：\n設定ファイルもついでに用意したよ ログモジュールもついでに取り出したよ エラーコード、ユーティリティクラス、ディレクトリ構造もまとめて整理したよ サードパーティライブラリの組み込み方法も、代わりに選んでおいたよ 結果として、デモは完成しているように見えても、あなたのメンタルモデルは空っぽである。その後、ライブラリの能力境界とあなたが考えていることに少しでも食い違いがあると、手直しが必要なのは一点ではなく、連続したものになってしまう。\nまずは小さなプロジェクトで練習する 個人的には、練習に最適だと思うのは、非常に小さなログスキャンツールを作ることです。名前は適当でいいですが、例えば logscan のようなものです。\nそれはただ一つのことをします。あるディレクトリ内のログファイルをスキャンし、error と warn の数を数え、その結果を出力するだけです。この問題はそれほど大きくありませんが、C++の小規模プロジェクトで最も一般的ないくつかの部分をすべて通るのにちょうど良いものです：\nmain と引数エントリポイント 出力フォーマット化 ログ 設定ファイル ビジネスモジュールの分割 重要なのは問題がどれだけ高度かではなく、分解の方法です。\nこれを4つのステップに分割し、各ステップではAIが現在の小さな一歩のみを行うようにします。\nステップ1：まず出力を準備する 最初のステップは、ログや設定には触れず、抽象化を考えないことです。\n2つのことをする：\n最低限の main.cpp を作成する fmt をインポートし、スキャンしたディレクトリと統計結果を出力する fmt の公式ドキュメントには、非常に明確な CMake の使い方が記載されています。そこには fmt::fmt と fmt::fmt-header-only という2つのターゲットがあり、ドキュメントではコンパイル版をより推奨していると明記されており、その理由は単純で、ビルド時間がより親切だからです。CMake の FetchContent のドキュメントも新しいプロジェクトの開始に非常に適しています。なぜなら、これはビルド段階になってから一時的にダウンロードするのではなく、configure 段階で依存関係を読み込むからです。\nこのステップでは、依存戦略を固定し、AIに自由に発揮させません。\nFetchContent を統一する または find_package を統一する いざという時に vcpkg、いざという時に add_subdirectory、そしてまた手動でヘッダーファイルをコピーするのはやめてほしい もし練習用のプロジェクトであれば、私はAIにこのように制約をかけます：\nアーキテクチャを一度に最適化しないでください。 現在の目標はこのステップのみであり、プロジェクトは常にコンパイル可能でなければなりません。 このステップでは以下の3点のみを行います： 1. ルートの CMakeLists.txt に fmt を導入する 2. main.cpp で渡されたディレクトリとスキャン結果を fmt で出力する 3. 既存のターゲット名とディレクトリ構造を維持し、ログ、設定、テストフレームワークは追加しない まず修正リストを提示し、その後コードを提示してください。 完了したら、ビルドコマンドと期待される出力を提示してください。 ここに重要な詳細があります。AIは、制約がない場合、「ついでにこれもやった」ということを加点要素として扱いがちです。今回のラウンドでは範囲を超えてはいけないと明確に伝える必要があります。\nステップ2、ログのアップロード まずステップとして、コードが書けて、動いて、出力も綺麗になったら、spdlogを追加する。\nspdlog の公式 README は、実際何ができるかを非常に分かりやすく記述しています。コンソールログだけでなく、通常のファイル、ローテーションファイル、日付ごとの分割、さらにはバックトレースリングバッファまで対応できます。問題はここです。機能が多すぎると、AI は興奮しすぎてしまい、まるで初版でカラーコンソール、ローテーションログ、日付アーカイブ、グローバルロガーファクトリを全部盛り込みたがるのです。\n不要です。\nこのステップでは、コンソールログを出すか、せいぜい最もシンプルなファイルログを追加するだけです。なぜなら、ここで本当に学ぶべきことは、「どうやってロギングシステムを完全に設計するか」ではなく、以下の3点だからです。\nロガーの初期化はどこで行うべきか ビジネスロジック内でどのようにロガーを取得するか エラー発生時と通常出力時のログの役割分担はどうすべきか もし最初から rotating_file_sink や daily_file_sink を使うと、「機能がとても充実した」ロギングモジュールを手に入れたように感じますが、実際にはローテーションや日付ごとの分割が必要なのか、それともデバッグ段階でターミナルに出力するだけで十分なのか、自分自身がまだ分かっていないかもしれません。\n要するに、ログファクトリをいかに美しく描くかよりも、まずspdlog::info()の使い方を理解することがより重要です。\nステップ3、設定ファイルに触れる 設定ファイルの部分は、AIによって大規模なプロジェクトになりやすいです。\n私は、それが「最強」だからというよりは、新しいプロジェクトの初期段階に適しているから、toml++ のようなシンプルなライブラリで練習したいと思っています。それ自体が C++17 のヘッダーオンリーな TOML パーサーであり、README に記載されている例も非常に短く、toml::parse_file(\u0026quot;configuration.toml\u0026quot;) で直接読み込めます。さらに重要なのは、単一ヘッダーファイル形式が本当に手間いらずなことです。公式の説明文もとても面白いのですが、シングルヘッダーのソリューションは「toml.hpp をソースツリーに放り込むだけ」で、「第二の手順はありません」。\nこのステップでは「設定センター」は行わず、以下の3つのフィールドを読み込んでください：\nスキャンディレクトリ キーワードリスト 出力はファイルに書き込むか そしてそれらを非常に薄い AppConfig 構造体に詰め込みます。\nそれで十分です。\n多くの手戻りは、実はここから生じているんです。設定を起動時に一度読み込むのか、実行時にホットアップデートするのか。ローカルのCLI専用なのか、それとも将来的にサービスプロセスで再利用するのか、ご自身でまだ明確に考えていない。AIはすでにあなたのために5、6層も処理してくれました。後から方向性を変更すると、これまで積み上げてきた「完璧な設計」がすべて重荷になってしまいますよ。\nステップ4：ビジネスモジュールの分解 例えば、fmt、spdlog、toml++ などはすべて自分で公式ドキュメントを一度確認し、実際に動作テストを行った上で、AIにモジュール分割を手伝ってもらう、といった具合です。\nこの時分解すると、心に余裕ができます。\n通常、私は以下のようなファイルを収集します：\nmain.cpp はアセンブリのみを担当する app_config.{h,cpp} は設定の読み取りのみを担当する logger.{h,cpp} はログの初期化のみを担当する log_scanner.{h,cpp} に業務ロジックを配置する 注意点として、この段階になってから分割するものであり、最初から分割するわけではありません。最初のステップで目次をきれいに並べることは、多くの場合、視覚的に心地よいだけであり、認知的な明確さが増すわけではありません。\n本当に役立つのは、複雑な規範ではない インターネット上には、AIのコーディング規約が非常に複雑なものが多くて、十数項目、数十項目とあって、見るだけで疲れますね。私が今残したものは、実はたった3つだけなので、これで十分だと思います。\n第1条、まず「ライブラリカード」を作成します。\nサードパーティライブラリを準備するたびに、私はまずAIに以下の4つの質問だけを回答するようにしてもらいます。\nこのライブラリは何の問題を解決しますか 公式版はどこまでサポートしていますか 今回はどの機能の 1 つか 2 つに絞って使いたいと思っています ビルド、デプロイ、実行にどのような制約をもたらしますか このカードが分からない場合は、とりあえず受けないでください。\n第2条、一度にAIを一つのチェックポイントだけに通す。\n例えば、このラウンドではこれだけを完了させることを許可する：\nコーディングできる 実行できる 期待される出力を確認できる 同じラウンドで「ついでにディレクトリをリファクタリングする」「ついでに設定クラスを追加する」「ついでに例外処理の仕組みも統一する」といったことをするのはやめてください。C++プロジェクトでは、「ついで」というものが、問題の原因箇所を汚染しやすくなります。\n第3条、各ラウンドでロールバックポイントを残すこと。\nコミットしなくても、以下の質問に答えられる必要があります。\nこのステップで具体的に何が変わったのか 間違っていた場合、どこを削除する必要があるか 一つ前のステップに戻した場合、プロジェクトはまだ編集可能か 気づくと、この考え方は実は手動での開発と非常によく似ています。違いは、以前は自分でコードを書いていたのに対し、今はAIが暴走しないように見張っているという点だけです。\nより実戦的なAIの活用方法 この一連のものを本当に習得したいなら、3周連続でやることをお勧めします。\n第1ラウンドは、AIにfmtの補完だけを任せて、残りは自分でCMakeの設定と出力コードを読み直してください。\n第2ラウンドは、AIにspdlogのみを扱わせてください。コンソールログにするかファイルログにするかは自分で決めてください。両方同時に使うのは禁止です。\n第3ラウンドは、AIにtoml++の受け渡しのみをさせ、設定項目は自分で決め、AIに将来のニーズを推測させることは禁止とする。\nこの3周を終えると、AIプログラミングに対する感覚が大きく変わるでしょう。前は「どうしてこんなにたくさん生成してくれるんだ」という感じだったのが、徐々に「次のステップをどれくらい小さくすれば最も効率的か」という視点になるようになります。\nこれが今のAIプログラミングで最も価値のある能力だと思います。\nデモを出すわけではない。\nむしろ、一つのプロジェクトを確実に前進させる。\n正直なところ、このやり方は目新しくなく、むしろ古臭いかもしれません。しかし、古い方法は再作業に強い傾向があります。特にC++のような言語では、AIに少し任せる部分を減らして、自分で確認する部分を増やすと、後が本当に楽になります。そうしないと、3分で飛び立っても、3時間かけてやり直すのは自分自身ですからね。\n参考資料 Anthropic, Claude Code Common Workflows Anthropic, Claude Code Overview GitHub Docs, Best practices for using GitHub Copilot to work on tasks CMake Docs, FetchContent {fmt} Get Started gabime/spdlog README gabime/spdlog Wiki: Sinks marzer/tomlplusplus README 作成上の注記 元のプロンプト プロンプト：人間がプロジェクトを構築する際、C++のようにフレームワークを使わない言語の場合、まずmainからロジックを展開していく「骨格」を作り、徐々に設定ファイル、ログモジュール、反復的なビジネスモジュールなどを追加していくのが良いと思います。私の習慣としては、毎回コンパイルが通ることを確認し、段階的にリファクタリングを進めることです。最初から最適解である必要はありません。AIによるプログラミングは、今や多くのケースで工程を飛ばしたり、初期の思考が不足したりしがちです。特に新しいサードパーティライブラリを導入する場合、AIはすぐにデモを出せますが、私が新しく導入したサードパーティライブラリの詳細な仕様やサポートする機能が不明確なため、関連ロジックの作り直し（手戻り）率は人間による開発よりも明らかに高くなります。学べるような良い実例はありませんか？インターネット上には複雑なAIプログラミング規約はたくさんあると知っていますが、私はもっとシンプルで、すぐに適用できるものが欲しいです。\nライティングのアイデア概要 トピックを tooling レーンに絞り、AI がワークフローを変えた後、どこが楽になり、逆にどこが不自然になったかを重点的に書く。 一般的な規範リストではなく、C++ の小規模プロジェクトの段階的な練習事例に変更する。 ユーザーが「main から始め、各ステップでコンパイルでき、徐々にリファクタリングできる」という核となる判断を維持し、これを記事全体のメインラインとする。 Anthropic、GitHub、CMake、fmt、spdlog、toml++ の一次資料を補完し、ツールの機能や依存方法について憶測するのを避ける。 記事の構成は fmt -\u0026gt; spdlog -\u0026gt; toml++ -\u0026gt; モジュール分割 の順に進め、意図的に AI に一度で全てを解決させないようにする。 ","date":"2026-04-10","language":"ja","permalink":"https://ttf248.life/ja/p/ai-demo-fast-rework-faster/","tags":["AI霊感衝突坊","ai","C++","ソフトウェア工学"],"title":"AI はデモの作成が速く、修正作業も本当に速いです。","year":"2026"},{"categories":["コンピューター"],"content":"以前VS CodeでC++をデバッグするとき、設定は基本的にlaunch.jsonに留まっていて、せいぜいGDBの行を追加する程度でした。 programを埋めて、gdbを埋めて、ブレークポイントを設定する。それで終わり？毎回デバッグ前にターミナルで手動でcmake --buildしないといけませんでした。 さらに面倒なのは、カスタム価格、契約、注文タイプなどでブレークポイントを打った後、VS Codeのデバッグウィンドウには内部フィールドが大量に表示されるだけで、データ自体は正しいのですが、人間が理解できる言葉になっていない点です。 この件がおかしいと思う点は、以前見たチュートリアルもlaunch.jsonまでしか触れていなかったことです。最近AIに新しいプロジェクトの設定を依頼したところ、なんと自動でpreLaunchTaskとgdb_printers.pyを追加してくれたので、「VS CodeでC++をデバッグするって、ただGDBを起動させるだけじゃないんだな」と気づきました。デバッグ前にCMakeのコンパイルを自動実行できるし、ブレークポイントで停止した後に、GDBにPythonスクリプトをロードさせて、ビジネスロジックの型を自分が見やすい形に整形させられるんです。 正直なところ、これは何かの「裏ワザ」というわけではありません。 しかし、C++の日常的なデバッグにおける非常に面倒な2つの空白部分――起動前のビルドとブレークポイント後の変数表示――を完璧に埋めてくれたのです。\n以前只配了一半 多くのチュートリアルにある .vscode/launch.json は、大体このような内容です：\n{ \u0026#34;version\u0026#34;: \u0026#34;0.2.0\u0026#34;, \u0026#34;configurations\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;Debug with GDB\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;cppdbg\u0026#34;, \u0026#34;request\u0026#34;: \u0026#34;launch\u0026#34;, \u0026#34;program\u0026#34;: \u0026#34;${workspaceFolder}/build/debug/bin/vscode_cpp_debug_demo\u0026#34;, \u0026#34;args\u0026#34;: [], \u0026#34;stopAtEntry\u0026#34;: false, \u0026#34;cwd\u0026#34;: \u0026#34;${workspaceFolder}\u0026#34;, \u0026#34;MIMode\u0026#34;: \u0026#34;gdb\u0026#34;, \u0026#34;miDebuggerPath\u0026#34;: \u0026#34;/usr/bin/gdb\u0026#34;, \u0026#34;setupCommands\u0026#34;: [ { \u0026#34;description\u0026#34;: \u0026#34;Enable pretty-printing for gdb\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;-enable-pretty-printing\u0026#34;, \u0026#34;ignoreFailures\u0026#34;: true } ] } ] } この部分は間違っているとは言えません。 VS Code の公式の C++ サンプルでも、同様の構造が使われています：type に cppdbg を使い、MIMode に gdb を使い、setupCommands で pretty-printing を有効にしています。 しかし、決定的に欠けている動作があります。 F5 を押すと、それは program が指す実行ファイルを起動します。問題は、そのファイルが今まさにコンパイルされたものかどうかです？ もしそうでなければ、前回ビルドした古いプログラムをデバッグしてしまいます。 私も以前、よくこんな馬鹿なことをしていました。コードを変更し、ブレークポイントも設定したのに、しばらく動かしてみたら動作がおかしいことに気づき、最後に「ああ、さっき再コンパイルするのを忘れていた」と思い出す、ということがありました。\npreLaunchTask こそがそのフックである VS Code の Tasks は、本質的に外部コマンドをエディタに組み込む仕組みです。 コンパイル、テスト、パッケージングといった作業は、以前はターミナルで手動で行う必要がありましたが、今では .vscode/tasks.json に記述できます。そして launch.json の中の preLaunchTask が、そのラベルを使って該当するタスクを探し出します。 最小限の CMake プロジェクトを例に挙げると、このように配置できます：\n. ├── .vscode/ │ ├── launch.json │ └── tasks.json ├── CMakeLists.txt ├── src/ │ └── main.cpp └── tools/ └── gdb_printers.py CMakeLists.txt はまず、これだけ記述します：\ncmake_minimum_required(VERSION 3.16) project(vscode_cpp_debug_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 20) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) add_executable(vscode_cpp_debug_demo src/main.cpp ) 次に、.vscode/tasks.json です：\n{ \u0026#34;version\u0026#34;: \u0026#34;2.0.0\u0026#34;, \u0026#34;tasks\u0026#34;: [ { \u0026#34;label\u0026#34;: \u0026#34;cmake: configure debug\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;process\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;cmake\u0026#34;, \u0026#34;args\u0026#34;: [ \u0026#34;-S\u0026#34;, \u0026#34;${workspaceFolder}\u0026#34;, \u0026#34;-B\u0026#34;, \u0026#34;${workspaceFolder}/build/debug\u0026#34;, \u0026#34;-DCMAKE_BUILD_TYPE=Debug\u0026#34; ], \u0026#34;problemMatcher\u0026#34;: [] }, { \u0026#34;label\u0026#34;: \u0026#34;cmake: build debug\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;process\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;cmake\u0026#34;, \u0026#34;args\u0026#34;: [ \u0026#34;--build\u0026#34;, \u0026#34;${workspaceFolder}/build/debug\u0026#34;, \u0026#34;--parallel\u0026#34; ], \u0026#34;dependsOn\u0026#34;: [\u0026#34;cmake: configure debug\u0026#34;], \u0026#34;group\u0026#34;: { \u0026#34;kind\u0026#34;: \u0026#34;build\u0026#34;, \u0026#34;isDefault\u0026#34;: true }, \u0026#34;problemMatcher\u0026#34;: [\u0026#34;$gcc\u0026#34;] } ] } ここの cmake --build に注目してください。 CMake の公式なビルドのエントリーポイントは、この形式です：cmake --build \u0026lt;dir\u0026gt;。これは、Make や Ninja、MSBuild といった背後のネイティブビルドツールを呼び出します。 つまり、VS Code はあなたのプロジェクトが make を実行すべきなのか ninja を実行すべきなのかを知る必要がないのです。 そのことは CMake に任せているわけです。\nF5 の前に、まずコンパイルする その後、.vscode/launch.json に戻り、preLaunchTask を追記してください：\n{ \u0026#34;version\u0026#34;: \u0026#34;0.2.0\u0026#34;, \u0026#34;configurations\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;CMake Debug with GDB\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;cppdbg\u0026#34;, \u0026#34;request\u0026#34;: \u0026#34;launch\u0026#34;, \u0026#34;program\u0026#34;: \u0026#34;${workspaceFolder}/build/debug/bin/vscode_cpp_debug_demo\u0026#34;, \u0026#34;args\u0026#34;: [], \u0026#34;stopAtEntry\u0026#34;: false, \u0026#34;cwd\u0026#34;: \u0026#34;${workspaceFolder}\u0026#34;, \u0026#34;environment\u0026#34;: [], \u0026#34;externalConsole\u0026#34;: false, \u0026#34;MIMode\u0026#34;: \u0026#34;gdb\u0026#34;, \u0026#34;miDebuggerPath\u0026#34;: \u0026#34;/usr/bin/gdb\u0026#34;, \u0026#34;setupCommands\u0026#34;: [ { \u0026#34;description\u0026#34;: \u0026#34;Enable pretty-printing for gdb\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;-enable-pretty-printing\u0026#34;, \u0026#34;ignoreFailures\u0026#34;: true } ], \u0026#34;preLaunchTask\u0026#34;: \u0026#34;cmake: build debug\u0026#34; } ] } ここが重要です：\n\u0026#34;preLaunchTask\u0026#34;: \u0026#34;cmake: build debug\u0026#34; F5 を押す流れは以下のようになります：\nlaunch.json -\u0026gt; preLaunchTask -\u0026gt; tasks.json: cmake: build debug -\u0026gt; dependsOn: cmake: configure debug -\u0026gt; cmake -S ... -B ... -\u0026gt; cmake --build ... -\u0026gt; gdb が最新の program を起動する Windows + MinGW の場合、program は .exe 付きのパスに変更する必要がある可能性が高く、miDebuggerPath も自身の gdb.exe を指すようにする必要があります。 Visual Studio Generator のような複数の設定を生成するジェネレータの場合は、ビルド引数に通常 --config Debug を追加する必要があります。 しかし、基本的な流れは変わりません。 デバッグする前に VS Code に一度ビルドタスクを実行させてください。自分で記憶に頼るのはやめましょう。\nもう一つの課題点：カスタム型の可読性 コンパイルリンクを繋げるだけでは不十分です。 C++コードで少し業務的な型をラップするだけで、VS Codeの左側の変数ウィンドウがすぐに見づらくなります。 例えば、以下の例を見てください。\nsrc/main.cpp:\n#include \u0026lt;cstdint\u0026gt; #include \u0026lt;cstdio\u0026gt; #include \u0026lt;string_view\u0026gt; #include \u0026lt;vector\u0026gt; namespace market { struct Price { std::int64_t raw{}; static Price from_double(double value) { return Price{static_cast\u0026lt;std::int64_t\u0026gt;(value * 10000)}; } double to_double() const { return static_cast\u0026lt;double\u0026gt;(raw) / 10000.0; } }; struct Instrument { char symbol[16]{}; Price last; }; Instrument make_instrument(std::string_view symbol, double price) { Instrument instrument; std::snprintf(instrument.symbol, sizeof(instrument.symbol), \u0026#34;%s\u0026#34;, symbol.data()); instrument.last = Price::from_double(price); return instrument; } } // namespace market int main() { std::vector\u0026lt;market::Instrument\u0026gt; watchlist{ market::make_instrument(\u0026#34;IF2406\u0026#34;, 3578.6), market::make_instrument(\u0026#34;IH2406\u0026#34;, 2468.2), }; market::Price limit = market::Price::from_double(3600.5); // ここでブレークポイントを置き、watchlistとlimitを観察する。 return watchlist.empty() || limit.raw == 0; } market::Price は業務上「価格」です。 しかし、デバッガがデフォルトで見せるのは以下のようになるかもしれません：\nlimit = {raw = 36005000} その通り、データは正しいです。 しかし、私の頭の中では、この 36005000 を手動で 3600.5000 に変換しなければなりません。もしプロジェクト内に Price、Quantity、OrderId、Instrument、AlgoState などが山ほどある場合、デバッグウィンドウはすぐに構造体の墓場になってしまいます。 このときこそ GDB の pretty-printer が必要になります。 GDB の公式マニュアルには非常に明確に書かれています。それは、Pythonコードを使って値をpretty-printするための仕組みを提供しており、この仕組みはMI（Machine Interface）とコマンドラインの両方に適用できるということです。 VS CodeのC++デバッグがまさに GDB/MI という経路を通っています。\nビジネスタイプ用のPython表示層の作成 tools/gdb_printers.py を新規作成します：\nimport gdb import gdb.printing class PricePrinter: def __init__(self, val): self.val = val def to_string(self): raw = int(self.val[\u0026#34;raw\u0026#34;]) return f\u0026#34;{raw / 10000.0:.4f}\u0026#34; class InstrumentPrinter: def __init__(self, val): self.val = val def to_string(self): symbol = self.val[\u0026#34;symbol\u0026#34;].string() price_raw = int(self.val[\u0026#34;last\u0026#34;][\u0026#34;raw\u0026#34;]) price = price_raw / 10000.0 return f\u0026#34;{symbol} last={price:.4f}\u0026#34; def build_pretty_printer(): printer = gdb.printing.RegexpCollectionPrettyPrinter(\u0026#34;market\u0026#34;) printer.add_printer(\u0026#34;Price\u0026#34;, \u0026#34;^market::Price$\u0026#34;, PricePrinter) printer.add_printer(\u0026#34;Instrument\u0026#34;, \u0026#34;^market::Instrument$\u0026#34;, InstrumentPrinter) return printer gdb.printing.register_pretty_printer( gdb.current_objfile(), build_pretty_printer(), replace=True, ) 次に、launch.json の setupCommands にこれをソースとして読み込ませます：\n\u0026#34;setupCommands\u0026#34;: [ { \u0026#34;description\u0026#34;: \u0026#34;gdbのプリティプリンティングを有効化\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;-enable-pretty-printing\u0026#34;, \u0026#34;ignoreFailures\u0026#34;: true }, { \u0026#34;description\u0026#34;: \u0026#34;プロジェクトのプリティプリンターをロード\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;-interpreter-exec console \\\u0026#34;source ${workspaceFolder}/tools/gdb_printers.py\\\u0026#34;\u0026#34;, \u0026#34;ignoreFailures\u0026#34;: false } ] F5 を再実行します。 この後、デバッグウィンドウを見ると、Price の表示は以下に近くなるはずです：\nlimit = 3600.5000 Instrument もまた、単なる配列や構造体から、よりビジネスに近いものになります：\nIF2406 last=3578.6000 ここで「近い」と言っているのは意図的です。なぜなら、プリティプリンターはコンパイラ、型名、実際のフィールドレイアウトと一致させる必要があるからです。 もしあなたのビジネスタイプの中に std::vector や std::array、スマートポインタなどがネストされている場合、Pythonスクリプトからアクセスするフィールドはさらに深い呼び出しが必要になるかもしれません。一つのスクリプトですべてをカバーできると期待しないでください。 しかし、考え方はしっかりしています。 「デバッグ時に人間が見たい姿」を、独立したPythonの表示ロジックとして記述するのです。\nlaunch.json を全てだと思ってはいけない この設定群を見ると、少なくとも3層あると感じます。 .vscode/launch.json は「デバッガをどう起動するか」を担当します。 .vscode/tasks.json は「デバッガを起動する前に、まずプロジェクトをビルドする」を担当します。 tools/gdb_printers.py は「ブレークポイントで止まった後、変数を人間が理解できる形で表示する」を担当します。 以前は最初の層だけを設定していました。 動くものの、非常に素っ気ないものでした。 本当に快適な C++ デバッグというのは、「まずターミナルでコンパイルしてから、戻ってきて F5 を押して、変数ウィンドウでフィールドの意味を頭の中で計算する」というものであってはいけないはずです。 より快適なフローは、F5 を押すと VS Code が自動的に CMake を実行し、GDB がプロジェクトの Python printer を自動ロードし、ブレークポイントで停止した際に、デバッグウィンドウが直接ビジネス言語で表示してくれることです。 今回 AI にプロジェクトの設定をしてもらったことで、最も価値があったのは、どれだけ C++ コードを生成したかということではありませんでした。 むしろ、これらの古いツール間の「接着剤」の部分を補ってくれた点です。 以前から CMake や GDB が分からないわけではありませんでした。 ただ、その中間にあるいくつかのフック（接続部分）を設定していなかっただけなのです。\n参考資料 VS Code で Linux 上の C++ を使用する VS Code: タスク経由で外部ツールと統合する CMake cmake(1) マニュアル GDB マニュアル: プリティプリンティング GDB マニュアル: プリティプリンタの記述 作成上の注記 元のプロンプト プロンプト：$blog-writer vscode で C++ を開発する際、以前見たチュートリアルは、launch.json 内の gdb デバッグ情報の設定のみで、preLaunchTask の設定に触れていませんでした。CMake のコンパイルを自動的にトリガーできる機能があれば、これは AI が新しいプロジェクトを設定する上で非常に役立つものです。もしコードにカスタムデータ型が多く含まれていて、VS Code のデバッグウィンドウで直接表示できない場合でも、Python スクリプトを導入して前処理を行うことで、それらも表示できるようになります。上記の内容について、すべて実際のコード例を提供してください。\nライティングの骨子まとめ メインテーマを「これまで launch.json の設定だけだったが、実際にはデバッグ前のビルドとデバッグ時の表示という2層の接着剤（仕組み）が欠けていた」ことに置く。 ユーザーから提供されたトリガーポイントは維持する：AI が新しいプロジェクトを設定する際に、preLaunchTask で CMake のコンパイルが自動的にトリガーされることを発見した点。 コード例は最小限の CMake プロジェクトで構成し、CMakeLists.txt、tasks.json、launch.json、C++ のカスタム型、および GDB Python pretty-printer を含める。 事実確認は VS Code、CMake、GDB の公式ドキュメントを最優先とし、本文ではドキュメント全体を翻訳せず、このデバッグフローに関連する事実のみを残す。 pretty-printer に関しては、型名、標準ライブラリの実装、フィールドレイアウトなどが Python スクリプトに影響を与える点について注意喚起を行う。プロジェクト内では自身の型に合わせて修正が必要である旨を明記する。 ","date":"2026-04-09","language":"ja","permalink":"https://ttf248.life/ja/p/vscode-cpp-debug-prelaunch-cmake-gdb-printer/","tags":["vscode","c++","cmake","gdb","ai","AI霊感衝突坊"],"title":"VS CodeでC++を扱う際は、CMakeとGDB Printerを忘れないように。","year":"2026"},{"categories":["コンピューター"],"content":"最近アルゴリズムサービスを書いていて、twap や vwap のようなモジュールをいくつか展開したところ、またこの古い問題に直面しました。\nC++ でクラス名に頼ってセマンティクスを無理やり押し付けると、名前はすぐに制御不能になります。TwapOrderManager、VwapOrderManager、AlgoOrderManager のようなものは、書き進めているうちに「自分の構造が手に負えないことはわかっているけど、とりあえずプレフィックスを付け足しておこう」という感じになってしまいます。端的に言えば、フォルダで階層分けをして、さらに namespace を一つ追加するのは、コードの潔癖症なのではなく、C++ に Java のようなネイティブな package システムがないことによる空隙を埋めているのです。\n結論から言うと もし最も近いソフトウェア工学の用語を探さなければならないとしたら、私は以下の2つの言葉が最も適切だと思います。\nモジュール化（modularization） 名前空間管理（namespace management） もう少し具体的に言うと、このようなディレクトリ構成は、しばしば以下のようなことを行っています。\n機能ごとのパッケージング / ドメインごとのパッケージング、つまり一般にいう package by feature ビジネス境界が非常に明確な場合は、バウンデッドコンテキストの要素も含まれます。 つまり、これは単一の標準的な訳語を持つ小さな概念というよりも、いくつかの設計原則が積み重なったもののようなものです。\nこれは事前に解決している、というよりは「見栄え」の問題ではない 多くの人は namespace を見ると、まず名前の衝突を避けることを思い浮かべます。これはもちろん正しいです。C++ の標準ライブラリにおける namespace は、本来大規模なプロジェクトでの名前の衝突を防ぐために存在します cppreference。しかし、実際のビジネスコードにおいては、その価値はそれだけにとどまりません。\nディレクトリ構造と namespace が整列されることで、クラス名が上位のセマンティクス（意味）を繰り返す必要がなくなります。\n例えば、以前は以下のように書くことが多かったかもしれません：\nclass TwapOrderManager; class TwapScheduleEngine; class VwapOrderManager; class VwapScheduleEngine; ディレクトリと名前空間を使うように変更すると、より自然な書き方は通常以下のようになります：\nnamespace algo::twap { class OrderManager; class ScheduleEngine; } namespace algo::vwap { class OrderManager; class ScheduleEngine; } これにより、冗長な接頭辞がなくなり、かえってセマンティクスが明確になります。「それがどのコンテキストに属するか」という情報がクラス名の中に詰め込まれるのではなく、ディレクトリ構造と namespace に委ねられるようになるからです。\nしたがって、このアプローチの本質は、**「名前からコンテキスト情報を抽出し、構造（ディレクトリや名前空間）に担わせる」**ことなのです。\nこれはむしろ「機能（特性）ごとにパッケージ化する」に近い もしあなたのディレクトリが以下のように長い場合：\nstrategy/ twap/ order_manager.h schedule_engine.h slicer.h vwap/ order_manager.h schedule_engine.h slicer.h あなたはもはや従来の「技術層ごとにパッケージ化する」ことをしているわけではありません。\n伝統的な分け方は、むしろ以下のようになります：\nmodels/ services/ utils/ controllers/ この分け方は初期段階では整然として見えますが、ビジネスロジックが増えてくると、service ディレクトリはゴミ集積所のようになってしまいます。ある機能に関連するクラスが異なるディレクトリに散らばり、コードを読むたびに頭の中が飛び回ります。\n一方、twap や vwap のような分け方は、「機能（フィーチャー）ごとにパッケージ化する (package by feature)」という考え方に近いです。つまり、あるディレクトリはまず「このビジネス領域は何をするのか？」に答え、その中にそのビジネスに必要なオブジェクトやフローを配置していくイメージです。Javaの世界ではこの言い方がより一般的ですが、C++においても同様に成立します。ただし、それを支えているのはネイティブな package ではなく、「ディレクトリ + 名前空間 (namespace) + ヘッダーファイルの境界」になります。\n端的に言えば、あなたはコードを「見た目（構造）で組織するのではなく、変更の理由（振る舞い）によってコードを組織している」のです。\n一歩遡ると、それは高凝集・低結合ということになる ソフトウェア工学でよく耳にする「高凝集、低結合」という言葉は、まさにこのような場所に当てはまります。\ntwap の下のオブジェクト同士が頻繁に協調して動作する場合、それらは物理的にも近く配置し、名前空間も近接させるべきです。vwap もこれと似ていますが、全く同じわけではないので、独立した境界を持たせるべきです。このようにすることで、いくつかの直接的な利点があります：\n同じモジュール内のクラス名を短くできる モジュール間の依存関係が視覚的に把握しやすくなる リファクタリングの際、変更が他の場所に波及するかどうかを判断しやすくなる 将来的に特定の機能を独立したライブラリとして切り出す際のコストも低くなる これが、多くの成熟したプロジェクトが最終的に「ディレクトリ境界 + 名前空間境界 + コンパイル境界」が可能な限り一致する形になる理由です。QuickFIX のようなプロジェクトを見ても、同様の考え方が見られます。型や拡張ポイントは、長いクラスプレフィックスに頼って強制的に区別するのではなく、できるだけ明確な名前空間の下に配置されています QuickFIX GitHub。\nいつまた足りなくなるのか しかし、この件を神格化する必要はありません。\nフォルダの階層化にさらにnamespaceを適用したとしても、それはあなたがモジュール化の方向に進んでいることを示すだけであり、アーキテクチャが自動的に良くなるわけではありません。よくある落とし穴も明白です：\nディレクトリと名前空間が一致していない ディレクトリは twap/ なのに、コードの中にはバラバラに配置されたグローバルクラスや、namespace common があちこちに散らばっていて、これは基本的に無駄です。\nモジュール境界は偽の境界である 表面上には twap や vwap があるが、実際にはお互いに #include しており、共通ロジックは自由に透過し、結局ただファイルを移動させただけで、結合度は全く下がっていない。\ncommon ディレクトリが肥大化する これが最もよくあるケースです。多くのプロジェクトは最初はきれいに分割されているのに、後になると面倒になり始め、「common」「base」「util」などに物を放り込みがちになります。その結果、最終的には真に安定した抽象概念が蓄積されるどころか、誰でも触れてしまい、誰もが依存してしまう巨大な穴（負債）ができてしまいます。\n構造はレイヤーごとに分け、ビジネスロジックごとには分けない もしあなたのディレクトリが常に api、service、dao、model のようになっている場合、多くのビジネス概念に適切な「家」が存在しません。クラス名は必然的にどんどん長くなり、本来構造で表現すべきものをすべて名前に詰め込むことになります。\nそれって結局何と呼ぶべきか チーム内でコミュニケーションする場合、私は3つのレベルに分けて話せると思います：\n人間言葉で伝えたいだけなら：ディレクトリと名前空間に基づいてモジュール化する よりエンジニアリングっぽく言いたいなら：機能（フィーチャー）ごとにパッケージを分ける方法で、階層的な名前空間を組み合わせる もしこの境界がすでにビジネスのセマンティクスに強く結びついている場合：バウンデッドコンテキスト（Bounded Context）の匂いがするモジュール分割 私自身は2番目に傾いています。なぜなら、それがあなたが説明しているシナリオに最も近いからです。\nあなたが言っているのはC++の文法的なテクニックでも、単なる命名規則でもなく、もっと本質的なことをやろうとしているのです：構造を使ってセマンティクスを担わせ、名前を本来の意味に戻すこと。\nクラス名が短くなり、ファイル名も短くなることで、コードを読む際に最初に目に入るのは、ディレクトリの責務、命名の責務、実装の責務をすべてごちゃ混ぜにしたTwapOrderManagerImplのようなものではなく、コンテキストが明確なtwap::OrderManagerのようなオブジェクトになります。\nそうなることで、ようやくJavaでパッケージ構造が成熟した後のような感覚になるのです。\n最後のまとめ したがって、ソフトウェア工学には当然対応する概念はありますが、唯一の正解というわけではありません。\nより大きな視点で見れば、「モジュール化」と呼ばれます。コードの構成という観点からは「機能ごとのパッケージング」、さらにネームスペース管理が加わります。ドメイン境界という観点から見ると、それはある種のバウンデッドコンテキストの意味合いも持ちます。\nどう言えばいいでしょうか、このようなプラクティスの最も価値のある点は、「名前がきれいに整った」ことではなく、ついに超長いプレフィックスに頼って構造的な欠如を補わなくてよくなった、という点なのです。\n参考資料 cppreference: Namespaces QuickFIX/C++ 公式サイト QuickFIX GitHub リポジトリ Java Practices: Package by feature, not layer Martin Fowler: Bounded Context 作成上の注記 元のプロンプト プロンプト：コーディング開発において、C++の良いプラクティスの一つは、フォルダで階層化し、各クラスに名前空間（namespace）を適用することです。これはJavaのパッケージのようなもので、ファイル名やクラス名に含まれる冗長な内容を効果的に減らすことができます。quickfixという古典的なプロジェクトがありますが、最近開発したアルゴリズムサービスでも同様のデザインを使用しました。TWAPやVWAPなど、多くの機能モジュールが似ています。ソフトウェア工学において、これに特化した概念はありますか？\nライティングの思考プロセス要約 アルゴリズムサービスにおける twap や vwap の実際のモジュールトリガーポイントから切り込み、まず判断を明確にする。 問題を単一の名詞として無理に説明するのではなく、モジュール化、名前空間管理、特性ごとのパッケージ分けといった、より正確な階層に分解した。 QuickFIX と Java パッケージの対応関係を残し、C++ がディレクトリと名前空間に頼って構造的な意味（セマンティクス）を補うことが多いことを説明するために用いた。 「重複名の回避」といった表層的な説明に留まるのではなく、「構造を用いて意味を担わせる」点に重点を置いた。 後続の展開が容易になるよう、namespace、package by feature、bounded context に関する参考リンクを追加した。 ","date":"2026-04-09","language":"ja","permalink":"https://ttf248.life/ja/p/cpp-folder-namespace-what-is-it-called/","tags":["c++","ソフトウェア工学","アーキテクチャ設計","AI霊感衝突坊"],"title":"フォルダの階層構造に名前空間を重ねる、これは一体何と呼ばれますか？","year":"2026"},{"categories":["コンピューター"],"content":"今回フォーラムを巡回していて、一番印象に残ったのは、「またランキングを出した」というところではなく、「VRAMが足りないから、パラメータがどれだけ大きくても無駄だ」という、かなり生易しい（陳腐な）一言でした。\n以前は「モデルが遅い」ことを計算能力の問題だと捉えがちでした。しかし、後になってよく気づいたのは、多くのケースでGPUの計算能力が足りないのではなく、データが適切な場所に留まらないことが原因だということです。メモリのパスが少し変わるだけで、トークン速度は少し落ちるというレベルではなく、直接落ちてしまいます。\n前2の記事で、前提となる問題は全て網羅しました。第1回 ではリリースとライセンスについて、第2回 では3060 12GBでなぜまず26B A4Bを見るのかについて解説しました。そして、今回の記事では、速度が具体的にどのように落ちていくのかだけを扱います。\nVRAM不足、慢のはちょっとの問題ではない 推論というプロセスを分解して見ると、特に重要なのが以下の2点です。\nモデルの重み（モデルウェイト） KVキャッシュ 重みはモデルそのものを決定し、KVキャッシュはこれまでの文脈の状態を記録します。コンテキストが長くなるほど、KVキャッシュは大きくなります。この2つが安定してGPUのVRAM内に収まっていれば、トークンを生成する際も基本的に高帯域幅なVRAM内でのデータ読み出し、計算、結果書き戻しが行われるため、速度は通常期待できます。 本当に厄介なのは、VRAMに乗り切らない場合です。 一度容量オーバーになると、推論フレームワークは譲歩せざるを得ません： 一部の重みをシステムメモリに配置する あるいは一部のKVキャッシュをシステムメモリに配置する あるいはCPUとGPU間でデータを頻繁に行き来させる この状況では問題は「少し計算量が増えた」というレベルではなく、「トークンを一つ出すたびにデータ待ちが発生する」というレベルになります。 なぜ急落（断崖）が発生するのか、線形に遅くなるわけではない この罠に初めて遭遇した多くの人は、「モデルが $14\\text{B}$ から $31\\text{B}$ になったら、2倍以上遅くなるから、我慢できる範囲だ」と直感的に考えます。\nしかし、現実はそうではありません。\n真の境界線はパラメータが2倍になることではなく、ワークセットがVRAM（ビデオメモリ）の境界を越えたかどうかです。\nまだ越えていない場合、モデルが大きくなることで遅くなるのは、通常予測可能な範囲内です。\n一度それを超えると、システムの状態が根本的に変わります：\nそれまでは「VRAM内でのクローズドループ」だった 今や「VRAM + メインメモリ + バスによるデータ転送」になる 経路が変わるだけで、コストは全く異なります。特にデコード（生成）の段階では、元々トークンを一つずつ順に進んでいき、バッチサイズもそれほど大きくないため、この時最も怖いのは、すべてのトークンに対してデバイスをまたいでデータを待つ必要があることです。\nそのため、非常に典型的な現象を目にすることがあります：\nモデルが動かないわけではない GPUも完全に遊んでいるわけではない しかし、トークン/秒（token/s）の数値が非常に悪い これが皆が言う「断崖」です。モデルが突然賢さを失ったのではなく、メモリのデータ経路が突然非効率的になったのです。\n「26B A4B」がローカルプレイヤーにとってより親切な理由 この点も、なぜ私が前回の記事で一貫して「26B A4B」を重視してきたのかを説明しています。 当然ながら総パラメータ数は小さいわけではありませんが、実際にトークンごとにアクティブになるのは約「3.8B」程度です。これは、類似のデプロイメント条件下において、計算リソースやVRAMへの負荷が、密な（dense）大規模モデルよりも管理しやすい場合が多いことを意味します。 これも魔法ではありません。 もしコンテキストを長くしすぎたり、量子化やフレームワークのサポートが不十分だと、これでも苦労します。ただ、最初からVRAMを使い切ってしまうような密なモデルと比較すると、「26B A4B」は、一般消費者向けのグラフィックカードにとってより現実的な選択肢という側面があります。 ですから、多くのケースで「31B」が弱いのではなく、ローカルマシンが誰と長期的に付き合うのに適しているか、という問題なのです。\nMac が「爆発しにくい」理由 Mac の最も異なる点は、モデルではなくメモリ構造にあります。 Apple silicon はユニファイドメモリを採用しています。CPU と GPU が同じメモリプールを共有するため、専用GPU搭載機のように、片方がVRAM、もう片方がメインメモリで、間にバスを介してデータを移動させるという構造ではありません。 この構造の最大の利点は、専用GPU搭載機では「VRAMにそもそも収まらない」モデルでも、Mac 上では別の状態になることです：\n必ずしも速くはないが まずは格納できる可能性が高いということです。 つまり、Mac は最初から非常に硬い「VRAMの壁」にぶつかりにくいのです。 これが、多くの人が Mac がローカルでの大規模言語モデル（LLM）において特に適していると感じる理由です。それは、「まずワークセット全体を同じメモリプールに詰め込めるか否か」という問題を解決してくれるからです。 しかし、ユニファイドメモリが高速を保証するわけではない この部分は分けて考える必要があります。 ユニファイドメモリは何を解決したのか？\n専用GPUメモリとメインメモリの物理的な分離の問題を解決した 小容量のVRAMでは直接搭載できなかった多くのモデルに対応できるようになった 非常に煩雑な、デバイス間でのデータの往復移動の問題を解決した しかし、何が解決されていないのか？ 大規模モデルの推論を「大量のメモリ読み出し」から別のものに変えていない 大規模モデルが突然帯域幅を消費しなくなるわけではない すべての推論フレームワークが自動的にCUDAのような成熟したエコシステムを持つわけではない したがって、Macの快適さとNVIDIAの大容量VRAMカードの速さは、同じものではありません。 Macはむしろ以下のようなものです： 機械が静かであること 総メモリが大きいこと 統一されていること これまで搭載できなかった多くのモデルを、とりあえず動かすことができるようになったこと NVIDIAの大容量VRAMカードはむしろ以下のようなものです： エコシステムが成熟していること CUDAツールチェーンが完全であること モデルとキャッシュをGPU内に留め込むことができれば、速度を上げやすいこと なぜスピードを求めるのか、結局はNVIDIAのVRAM容量が重要になる これは感情的な判断ではなく、ローカルにデプロイする過程で容易にたどり着く現実的な結論です。 もしあなたが以下のようなものを追求しているなら：\nローカルアシスタントの常駐化 多回の長文対話 長いコンテキストウィンドウ より高いトークン/秒 (token/s) 待ち時間を極力減らすこと それらの場合、結局はVRAM容量の大きなNVIDIA製GPUが重要になります。なぜなら、あなたが真に購入しているのは、モデルとキャッシュをできるだけ安定してGPU上に保持する能力だからです。 Macももちろん当てはまりますが、こちらは別の種類の要求に適しています： 大きなモデルを一度に搭載したい 速度は平均的でも良いが、ドライバや周辺機器の設定で手間をかけたくない 全体的な体験、消費電力、騒音を重視する これら二つのアプローチはいずれも合理的ですが、解決しようとしている問題点が異なります。 Gemma 4 に戻る、私の最終判断 今回、Gemma 4 は、ローカルでオープンソースのモデルが、より真剣にハードウェアについて議論すべき段階に入ったと感じさせられました。 しかし、モデルが強くなっても、物理法則まで緩むわけではありません。 どれだけ強力な 31B でも、VRAM が不足すれば速度は落ちます。 どんなに現実的な 26B A4B でも、コンテキストが長すぎれば負荷がかかります。 Mac のユニファイドメモリは快適ですが、それは単に「とりあえず動かす」のが容易になるだけであり、大容量の VRAM を持つ CUDA カードの速度を無償で提供してくれるわけではありません。 そのため、結局やはりこの地味な結論になります：\n速度を求めるなら、最優先は NVIDIA の大容量 VRAM です。 万全を期すなら、Mac のユニファイドメモリは確かに快適です。 3060 12GB のようなマシンで長期的に遊ぶのであれば、常に巨大なモデル（dense model）ばかりを気にするのではなく、26B A4B のようなアプローチの方が現実的です。 この一連の記事は、ここまでで締めくくりとします。 参考資料 Gemma 4: Byte for byte, the most capable open models Gemma 4 model card Apple unveils M3, M3 Pro, and M3 Max Apple unveils M2 Pro and M2 Max MacBook Pro Tech Specs 作成上の注記 元のプロンプト $blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルデプロイメントを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GB NVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関する評価を検索してください。重要な点として、今回のGoogleによる更新でモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものでした。昨年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図（トラップ）を理解していました。コンソールへの五芒星の出力は非常に厄介なため、直接アスキーアートとして文字列をハードコーディングし、コンソールに出力しました。これが原文です：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑である（座標変換やピクセル充填が関わるため）。最も古典的で視覚効果が高い方法は、アスキーアート（文字芸術）を使用することである。私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画したのです。」以前はローカルでの翻訳タスクにGemma4をよく使用していました。現在のブログの多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。同時にフォーラムを閲覧し、私は「VRAMが不足している場合、モデルパラメータを上げると、生成トークンの速度が急激に低下する」ということに気づきました。なぜそうなるのか説明してください。Macではこの問題は発生しません。ユニファイドメモリを使用しているため、技術的な理由を説明してください。また、速度が必要な場合は、やはりNVIDIAのVRAM大容量グラフィックボードが必要です。Macのソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。 ライティングの骨子まとめ 第3編では、「なぜスピードが落ちるのか」と「Macが速さ＝ではない理由」の2つの論点のみを残し、前2編の内容への回帰的な説明は行わない。 まずVRAM（ビデオメモリ）の限界について述べ、次に非線形な速度低下について述べることで、前回版よりも論理の流れがスムーズになる。 MacとNVIDIAをそれぞれ異なる側面から語り分け、一方は「安定性重視」、もう一方は「速度重視」という形で対比させる。 結論ではハードウェアの判断のみに留め、シリーズ分割の理由付けは繰り返さない。 ","date":"2026-04-08","language":"ja","permalink":"https://ttf248.life/ja/p/gemma-4-series-vram-cliff-and-mac-unified-memory/","tags":["AI霊感衝突坊","ai","gemma","VRAM","Mac","NVIDIA"],"title":"Googleが今回Gemma 4を公開した（3）","year":"2026"},{"categories":["コンピューター"],"content":"ランキングだけを見ると、一番心が動くのは間違いなく 31B です。 しかし、実際にマシンを前にすると、やはりアップグレードされていない RTX 3060 12GB の方が、判断はすぐに変わります。どう言えばいいか、ローカルにデプロイするということは、最後に一番派手なものが勝つのではなく、長く一緒にいられそうなものを選ぶことなんです。私にとっては、今回まず試す価値があるのは 31B ではなく、26B A4B です。\n前回の記事 GoogleがGemma 4を公開した件（一）：急いでローカルに動かす前に、モデル名とプロトコルを理解すべき では、リリースとプロトコルについて説明しました。今回の記事ではローカルでの体験そのものに焦点を当てています。最後の記事では GoogleがGemma 4を公開した件（三）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのか を続けます。\nなぜ先に「26B A4B」を試すのか 理由は実はかなり現実的、つまりハードウェアの制約によるものです。 「31B」はもちろん強力で、公式ランキングやコミュニティからの初期フィードバックも非常に高いです。しかし、それを「RTX 3060 12GB」のようなマシンに載せると、問題はすぐに「どれだけ強いか」から「待つ価値があるか」へと変わってきます。モデルやキャッシュがシステムメモリに退避してしまうと、速度が急激に落ちてしまうことがあり、この件については第3弾で詳しく解説します。 「26B A4B」は違います。 総パラメータ数は「25.2B」ですが、実際にトークンごとにアクティブになるのは約「3.8B」程度です。平たく言えば、これは今回のGemma 4の中で、「ローカルユーザー向けに特別に用意された」モデルと言えます。 ですから、もしあなたのマシンが私と同じような、コンシューマーグレードの古いグラボであるなら、判断はシンプルになります：\nランキングを見たいだけなら、「31B」を試す 本格的に長期でローカルに使いたいなら、まず「26B A4B」から始める 五芒星の問題、今回はついに誰かが私が罠を仕掛けていることに気づいた 私自身がずっと持っている、かなり原始的なテスト問題があります。モデルに C++ コードを書いて、コンソールに五芒星を出力させるというものです。\nこの問題は冗談のように見えますが、実際には結構厄介です。なぜなら、多くのモデルはこれを純粋な数学的な描画問題だと誤解し、座標系や三角関数、ループ処理などを持ち出してきてしまい、最終的にテキストコンソール上に、全く見づらい文字の塊を出力してしまうからです。\n去年の小規模パラメータのオープンソースモデルの多くが、この点でつまずきました。\nしかし、今回 Gemma 4 の最初の反応は、逆に私を驚かせました。すぐに理解したふりをするのではなく、制約条件を先に認識し、以下の判断を出してくれたのです：\n純粋なテキストコンソール（Console）上で、正確な幾何学的構造を持つ五芒星を数学的なロジックだけで描画するのは非常に複雑です（座標変換やピクセル充填が関わってきます）。最も古典的で視覚的に効果的な方法は、ASCII Art（文字アート）を使用することです。\n五芒星の問題、今回はついに誰かが私が仕掛けた罠を理解してくれた 端的に言うと、まず問題の背後にある環境的な制約を理解した点だ。コンソールはキャンバスではなく、文字グリッドもピクセルグリッドではない。先に「どうすれば安定して五芒星を出力できるか」を考え抜いてから、数学的な描画について語るべきだった。\nそして、最初のバージョンではいきなりハードコーディングされた五芒星の文字列を提示した。 この行動は非常に的確だ。推論を見せるためではなく、まず問題を正しく解くことを優先した。\nさらに驚いたのは、それがさらに進んでいくことだった 単にASCIIアートで止まっていただけなら、この問題はトラップを認識したとしか言えない。 私が高く評価したのは、その後も数学的な計算を要求し続けた際にも、それが失敗せず、むしろ幾何学的な関係性を文字のグリッド上にマッピングし、最終的に五芒星を算出した点だ。 これは「コードを書ける」ということではなく、この問題が実際には二層構造になっていることを理解している証拠だと考える。\n第一層：コンソール上で最も確実な答えは何か 第二層：もし計算をしなければならない場合、どのように幾何学の問題を文字のグリッド上に落とし込むか 以前の多くのローカル小規模モデルは、最初から第二層に飛びつき、結局第一層ができていないことが多かった。Gemma 4 は今回、逆の手順を踏み、まず境界線を見極め、それからどう解くかを決定した。 私はこの点の方が、単体のベンチマークスコアよりも価値があると思う。 今回のコーディング能力の向上は、「賢くなった」だけではない この五角星の問題が使いやすいのは、単に文法を問うものではないからです。 本当に試しているのは以下の点です：\n出力環境を先に理解できるか 直感的な解法が不適切であることを認められるか 「最適な表示効果」と「ユーザーによる強制計算要求」の間を切り替えられるか このような問題を正しく解けるということは、モデルが単にコードスニペットを補完するだけでなく、現実の制約を処理できる開発アシスタントらしくなり始めたことを示しています。 だからこそ、私にとって Gemma 4 の第一印象は、去年の小規模パラメータのオープンソースモデル群よりも格段に良いのです。昨年の多くのモデルは、チャットができる、補完できる、なんとかこなせるレベルでしたが、このような少し境界線を感じさせる問題に直面すると、脆さが露呈しがちでした。 今回、Googleはこの弱点を少なくとも補ってくれました。 この一文を翻訳すると、「Gemma 4 が全面的に引き継ぐ」と単純には言えない あなたが以前指摘した点は非常に重要です。これまでローカルで翻訳を行う際によく Gemma を利用していましたよね。\nこの件は、Gemma 4 になると、実はそれほど直線的ではありません。なぜなら、Google は 2026 年 2 月に単独で TranslateGemma をリリースし、しかもそれは Gemma 3 のアーキテクチャをベースにしているからです。\nこれはどういう意味か？ ということです。もしあなたがすでにローカルでの翻訳パイプラインを確立していて動いているなら、短期間で全てを Gemma 4 に切り替える必要はないかもしれません。特に、目的が非常に限定的で、単に安定した多言語変換だけを求めるシナリオにおいては、専用の翻訳モデルには依然として価値があります。\nしかし、もしあなたが求めているのが、翻訳、質問応答、コード、一般的なテキストタスクなど、複数の用途を可能な限りカバーできるローカルモデルセットであるならば、26B A4B のようなより万能なアプローチの方がスムーズでしょう。\nこれが最も特化しているわけではないかもしれませんが、「とりあえず動く、十分なメインストリームモデルが欲しい」という現実的な選択肢に近いと言えます。\nなぜ第2回で「31B」を褒め続けたくないのか 「31B」がダメだからというわけではない。むしろ、良すぎるからこそ、注意が逸れやすいのだ。 ずっと「31B」のベンチマークスコアばかり見ていると、「強力なモデルは本当にすごい」という記事になりがちだ。しかし、ローカル環境で最も怖いのは、そういった謳い文句である。なぜなら、あなたが毎日使い続けるかどうかを決定するのは、ランキングではなく、以下の点だからだ：\n起動が遅すぎないか 回答速度が著しく落ちないか 長いコンテキストを扱うとすぐに体験を台無しにしないか 自分自身のマシンで本当に支えられるか 「3060 12GB」のようなマシンでは、これらの現実的な問題の方が、ランキングよりもずっと重要だ。 そのため、第2回の締めくくりはシンプルにした。 「31B」は見る価値があるが、「26B A4B」は使う価値がある。ローカルユーザーにとって、この二つの文は全くの別物なのだ。 私のローカルでの第一印象 今回の実測感触を一言でまとめると、それは以下の通りです。 Gemma 4 はついにシーンを考慮できるローカルモデルになり始めた。 特に 26B A4B がそうですね。これはベンチマーク表を飾るためのモデルというよりは、古いマシンやコンシューマー向けのグラフィックボード、ローカルでの長期利用といった現実的な制約の下では、かえって真の主力選択肢のように感じられます。 少なくとも今回の五角星テストに関しては、Googleは合格点を超えました。\n参考資料 Gemma 4: Byte for byte, the most capable open models Gemma 4 model card google/gemma-4-26B-A4B-it on Hugging Face Gemma 3: The Developer Guide TranslateGemma: A new family of open translation models Gemma 4 31B on FoodTruck Bench 作成上の注記 元のプロンプト $blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルでのデプロイを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GBのNVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関するレビューを検索してください。重要な点として、今回のGoogleの更新によりモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものです。去年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図（トラップ）を理解していました。コンソールに出力する五芒星は非常に面倒なので、直接アスキーアート形式の文字列としてハードコーディングし、コンソールに直接出力しました。原文は以下の通りです：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑であるため（座標変換やピクセル充填が関わる）、最も古典的で視覚効果が高い方法はASCII Art（文字アート）を使用することです。私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画することができました。」以前はローカルでの翻訳タスクにGemma4をよく使っていました。現在ブログにある多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。またフォーラムを閲覧していて気づいたのですが、VRAMが不足している場合、モデルパラメータを上げると生成トークンの速度が急激に低下します。この理由を説明してください。Macではこのような問題が発生しないのはなぜですか？ユニファイドメモリを使用する技術的な理由を説明してください。さらに、速度が必要な場合は、やはりNVIDIAの大容量VRAM搭載グラフィックボードが必要です。Macのソリューションはバックアップとしては機能しますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。 ライティングの骨子要約 第2編はローカル体験のみに留め、第1編の総括や第3編のVRAM原理の説明は行わない。 まず「なぜ先に 26B A4B を実行するのか」という明確な判断を提示し、その後で五芒星テストを展開する。 五芒星の問題が主軸となるのは、ベンチマークスコアよりもコーディングシナリオにおける限界点をよりよく示せるからである。 翻訳タスクは独立したセクションとして扱い、Gemma 4 が全ての旧プロセスを線形的に引き継いでいるという印象を避ける。 ","date":"2026-04-08","language":"ja","permalink":"https://ttf248.life/ja/p/gemma-4-series-local-test-on-rtx-3060/","tags":["AI霊感衝突坊","ai","gemma","Google",3060],"title":"Googleが今回Gemma 4を公開した（2）","year":"2026"},{"categories":["コンピューター"],"content":"初日に私がやりたかったことはとてもシンプルでした。Gemma 3 に対応するアップグレード版を見つけて、まずダウンロードして動かしてみることです。 しかし、全体をざっと見ていくと、少し戸惑いを覚えました。以前慣れていた 4B / 12B / 27B という命名規則がなくなり、代わりに E4B、26B A4B、31B といったものが現れたのです。どう言えばいいか、今回Googleが真に変わったのは、単にモデルのサイズだけではなく、「この一連のモデルをどう理解すべきか」という部分まで変わってしまったからです。\nこの記事群は3つの記事に分けて書きました。現在の記事では、リリース情報、モデル名、プロトコルを明確に説明します。次の記事では Googleが今回Gemma 4を公開した（2）：RTX 3060 12GBでローカル実行してみた、真の現実的なのは26B A4B を書きます。そして最後の記事では Googleが今回Gemma 4を公開した（3）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのか で締めくくります。\nまず、今回具体的に何がリリースされたのかを明確にしましょう 昨年の Gemma 3 は 2025年3月12日にリリースされ、今回の Gemma 4 は 2026年4月2日と、確かに約1年空いています。 しかし、今回は「27Bの次は何だろう」という考え方で探すのはやめましょう。公式が提示した主要な4つのサイズは、もはや単に総パラメータ数で区分けされているわけではありません。 | E2B | Dense | 2.3B effective，5.1B 含 embeddings，128K context | デバイス側、超軽量ローカル |\n今回、結局何を発行したのかを明確にする モデル名 構造 主要な数値 代表的なユースケース E4B Dense 有効パラメータ 4.5B、埋め込み込み含む 8B、コンテキスト長 128K 元の 4B の小型モデルをメインラインとして展開 今回到底发布了什么说清楚 モデル名 構造 主要な数値 代表的なユースケース 26B A4B MoE 合計 25.2B、アクティブ約 3.8B、コンテキスト 256K コンシューマー向けGPU、ローカルデプロイメント、品質と速度の両立 まず、今回具体的に何を出したのかを明確にする モデル名 構造 主要な数値 代表的なユースケース 31B Dense 30.7B dense、256K context 最高性能の追求、ランキングでの優位性、より安定した品質 今回、結局何を出したのかを明確にする 表面だけを見ると、今回のネーミングはより混乱していると感じるかもしれません。しかし実際は混乱しているのではなく、Googleが意図的に3つの異なるアプローチに分割しているのです：\n小規模モデル・デバイス側向けに E2B / E4B を提供 ローカルプレイヤー路線として 26B A4B を提供 品質と上限を重視した路線として 31B を提供 これが、多くの人が最初に「以前の馴染んだアップグレードパスが途切れた」と感じる理由です。アップグレード版を提供していないわけではなく、Googleはもはや総パラメータ数という単一の次元だけで製品を売りたいわけではないのです。 「E」と「A」は今回、装飾文字ではありません このモデル名の中で、最も誤解を招きやすいのが E4B と A4B です。 E2B や E4B に含まれる E は、公式では effective parameters（実効パラメータ）を指します。これら2つのモデルは Per-Layer Embeddings を使用しているため、総パラメータ数と真の有効パラメータ数が同じ基準ではありません。平たく言えば、Googleは「これは過去のような『単なる 4B の密なモデル』ではない」と注意喚起しています。 一方、26B A4B に含まれる A は active parameters（アクティブパラメータ）を指します。総容量は 25.2B ですが、各トークンで実際に活性化するのは約 3.8B です。これがMoE（Mixture of Experts）の鍵であり、モデル全体のサイズは大きいものの、実行時に実際に計算に参加する部分はかなり小さいということです。 そのため、この2つの名前はどちらも「4B」を含んでいますが、その意味合いは全く異なります。\nE4B は小規模モデルのメインラインです。 26B A4B は大規模なMoEであり、ローカル推論時には「アクティブな規模が約 4B 程度」というイメージに近いです。 この命名規則は当初は確かに不自然ですが、過去のものよりも実際のデプロイ体験により近くなっています。 以前 Gemma 3 を使っていた場合、今回どういう対応関係で探せばいいか 私が思うに、この世代で最も誤解しやすいのは、これを Gemma 3 の線形なアップグレードだと捉えてしまう点です。\n使用する習慣から考えると、だいたい以下のように理解できます：\nこれまで 4B で軽いタスクを動かしていた人は、まずは E4B を見てください。 これまで 27B でモデルの限界値を見ていた人は、今度は 31B を見てください。 これまでコンシューマー向けのグラボで「十分強力だけど、完全に動かせなくなるほどではない」というバランス点を探していた人は、重点的に 26B A4B を見てください。 この部分を先に整理しておかないと、後からローカルにデプロイする際に非常に迷いやすいです。「いつものアップグレード版がないな」と文句を言いながら、実際自分に合っているモデルを見逃してしまう可能性があります。\n今回最も価値のあるアップデートは、実はパラメータではない 今回「ようやく腑に落ちた」と感じさせたのは、ランキングではなくプロトコル（ライセンス）でした。 以前のバージョンの Gemma の利用規約が全く使えないわけではありませんが、ずっとどこか引っかかる部分がありました。特に以下のようなことを気にされている場合：\n再配布 蒸留や二次加工を行う モデルを自社の製品ラインに組み込む 商用展開を行う といった場合、常にライセンス条項内の通知（notice）、下流利用の制限、付帯する契約などをどう処理すべきかを確認する必要がありました。 Gemma 4 が今回直接 Apache 2.0 に変更されたことで、状況が非常にクリアになりました。核となるメッセージは極めて明確です： 商用利用が可能である 改変が可能である 再配布が可能である 義務は主に、ライセンス、通知（notice）、改変の説明といったオープンソースの世界で馴染み深いものに留まるというものです。 つまり、Googleが今回単にモデルをオープンソースにしたのではなく、「皆が安心して使えるかどうか」という点まで含めて整備してくれたのです。 コミュニティからの初期評価は、基本的に2つのラインに集約される 最初の週の口コミだけを見ると、大まかに2つの声があります。\n1つ目のラインは、「31B は確かに実力がある」というものです。 公式が発表したスコアは非常に強力です。Arena AI のテキストランキングでは、31B がリリースされた時点でオープンソースモデルの上位にランクインし、LiveCodeBench v6 でも Gemma 3 27B よりかなり向上しています。多くの人が最初に抱く感想は、「このサイズでこれだけの性能が出せるのは、期待を上回っている」というものです。\n2つ目のラインは、「26B A4B はローカルユーザーのための生命線のようなものだ」というものです。 一見して最も華やかなフラッグシップモデルというわけではありませんが、非常に現実的です。特にデータセンターではなく、コンシューマー向けのグラフィックボードやワークステーション、さらには古いマシンで動かす場合、ローカルでの体験はむしろこのラインに落ち着きやすいのです。\nもちろん、最初の口コミには非常に現実的な前提があります。それはエコシステムがまだ追いついている最中だということです。テンプレート、量子化、推論フレームワーク、フロントエンドツールなど、多くのものがまだ完全に追いついていません。そのため、現段階で目にするレビューは、以下の2つのレイヤーに分けて見るのが最善です。\nモデル本体: 今回は確かに大きな進歩があった ローカル体験: 今後もツールの成熟度に影響され続けるだろう 第1回の結論について 単に今回のGoogleが何を発表したのかを知りたいだけであれば、一言で十分です。 「Gemma 4」は、「小さいものから大きいものまで並べる密度の高いモデル」という古い考え方ではなく、デバイス側、ローカルデプロイ、品質の上限という3つの道を分離しました。「E4B」、「26B A4B」、「31B」と名前は奇妙ですが、背後にあるのは非常に現実的なデプロイメントの分業です。 しかし、もし私に今回の最大の変化は何だと尋ねられたら、やはりこの判断になります。 パラメータでも、ベンチマークスコアでもなく、Googleがようやく「Gemma 4」を皆がより安心して使えるオープンソースライセンスに組み込んだことです。 この一歩こそが、表の数字以上に重要です。 次の記事では、発表会の論調は語らず、直接ローカルマシンに戻ります。やはりアップグレードされていない「RTX 3060 12GB」を使い、なぜ私が最初に注目したのは「31B」ではなく「26B A4B」だったのか、という点です。\n参考資料 Gemma 4: Byte for byte, the most capable open models Gemma 4 model card Gemma Terms of Use Apache License 2.0 for Gemma 4 Gemma 4 31B on FoodTruck Bench LocalLLaMA discussion on Gemma 4 license changes Gemma 3: The Developer Guide 作成上の注記 元のプロンプト $blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルでのデプロイを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GBのNVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関するレビューを検索してください。重要な点として、今回のGoogleによる更新でモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものです。昨年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図した「罠」を理解していました。コンソールでの五芒星の出力は非常に厄介なので、直接アスキーアート（文字）としてハードコーディングし、コンソールに直接出力しました。原文は以下の通りです：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑であるため（座標変換やピクセル充填が関わる）、最も古典的で視覚効果が高い方法はアスキーアート（文字芸術）を使用することです。」私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画することに成功したのです。以前はローカルでの翻訳タスクにGemma4をよく使っていました。現在ブログにある多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。同時にフォーラムを閲覧し、私は「VRAMが不足している場合、モデルパラメータを上げると、生成トークンの速度が急激に低下する」ということに気づきました。なぜそうなるのか説明してください。Macではこの問題は発生しません。統一メモリを使用しているため、技術的な理由を説明してください。また、もし速度が必要な場合は、やはりNVIDIAのVRAM大容量のグラフィックボードが必要です。Macのソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。 ライティングの骨子まとめ 第1の記事では、「今回具体的に何がリリースされたのか」と「プロトコルがなぜ重要なのか」を明確に伝えることに専念し、ローカル体験に関する話題は取り上げないようにする。 モデルラインナップの説明は、まずモデル群を分解してからアルファベットの意味を説明するという順序にし、前回のバージョンよりも論理的な流れを重視する。 プロトコルに関する部分は、「今回緩和されたのはパラメータではなく、利用制限である」という判断軸を維持する。 コミュニティの評価については、まとめに留め、ローカル体験に関する記述は過度に盛り込まないようにする。 ","date":"2026-04-08","language":"ja","permalink":"https://ttf248.life/ja/p/gemma-4-series-models-and-license/","tags":["AI霊感衝突坊","ai","gemma","Google","apache"],"title":"Googleが今回Gemma 4を公開した（1）","year":"2026"},{"categories":["コンピューター"],"content":"倉庫の構成を一周確認した結果、逆に確信したことがあります。このシステムは、単体のモデルがどれだけ強力かではなく、どのレイヤーにコストを負わせるべきか、という点にかかっているということです。\n最も明白なシグナルは、現在有効な published.runtime.json が依然として 2026年4月2日に生成された minimax-m2 であることです。しかし、2026年4月3日16:38の 5f17088 は、blog-style-suite のデフォルトプロバイダーをローカルの LM Studio 内の gemma-4-26b-a4b に切り替えています。これは一見すると前後で矛盾しているように見えますが、実はそうではありません。むしろ、このパイプラインに分業が始まったことを示しています。\nこの記事群はここまでで、最初の2本で境界線を描きました。第1回 では、blog-writer がなぜ生まれたのかを語り、第2回 では、blog-style-suite がどのようにスタイル学習とトークンコストを分離したのかを語りました。そして最後のこの記事では、最も現実的な問題に焦点を当てます。ローカルモデル、オンラインモデル、Minimax は、結局どのワークステーションに置くべきなのか、という点です。\nスタイルデータでのトレーニングは、すべてのステップでオンラインモデルを焼く価値はない スタイルデータというものは、真剣に取り組むと、トークンがすぐに現実的な問題になります。 やりたいかどうかではなく、役割分担をしないと、このシステム全体が長く動きません。 以前最も陥りがちだった誤解は、一つのオンラインモデルにすべての作業を任せてしまうことでした。\n過去記事のクロール スクリーニングの実施 分類を行う スコアリング サンプルの抽出 スタイルの調整（トーン合わせ） そして最後に原稿を書く このように行う最大の問題は、「モデルが十分強力でない」ことではなく、すべてのステップで同じコストを消費してしまうことです。 今振り返ると、真に合理的なアプローチは逆から考えるべきです。どのステップはオンラインで行う必要があるのか、どのステップは可能な限りローカル化すべきなのか、さらにはモデルに任せるべきではないステップがあるのか、という点です。 この境界線が不明確なままだと、どれだけ強力なモデルを導入しても、結局は本来前処理で対応できたはずの作業を繰り返すだけになってしまいます。 ローカルモデルは「汚い作業」「重労働」、そして「試行錯誤の繰り返し」に適している 私は今や、ローカルモデルを本番環境における「体力層（ワークホース）」として定義するようになりつつあります。 必ずしも最強である必要はなく、毎回最も洗練されているわけでもありませんが、以下のタスクを担うのに特に適しています：\n何度も実行する構築プロセス スタイルデータの複数ラウンドにわたる圧縮実験 設定変更後の再スキャン 既存の構造に対する低リスクな再計算 これらの作業には共通点があります。 それは単発で価値が極めて高いことではなく、繰り返し実行する必要がある、試行錯誤を許容できる、そしてできれば毎回高額なコストを払う必要がないという点です。 現在、scripts/blog-style-suite/config.json は lm-studio-gemma4 に切り替わっており、これ自体が判断が変わっていることを示しています。ローカルの gemma がオンラインモデルより必ずしも強いわけではなく、むしろ本番環境のこのパイプラインは、「実行可能か」「頻繁に実行できるか」「繰り返し変更できるか」を優先し始めたのです。 これは、私が以前書いた 弱モデルに無理に高度なタスクを割り当てない と同じ論理に基づいています。 ローカルモデルが複雑な記事全体をゼロから書き上げるのに適しているとは限りませんが、**「汚い作業」「重労働」「バッチ処理」**を受け持つには非常に適しています。スタイルデータの前処理は、元々このようなタスクに近いです。 オンラインモデルは「仕上げ」に向いており、「全てをこなす」のには向かない ローカルモデルがプロダクション側に向いているからといって、オンラインモデルに価値がないわけではありません。 オンラインモデルが真価を発揮するのは、まさに最後の「仕上げ（クロージング）」の部分です。 例えば：\n最新の情報に基づいて事実を補完する より大きなコンテキストの中で論証を整理する ネットワーク接続による検証が必要な時間的制約のある情報を処理する すでに準備された構造化されたスタイルアセットを、公開できる記事に仕上げる これらの動作は、表現の質、事実の統合、コンテキスト理解といった要求が高いため、オンラインモデルがここに配置される方が価値が高いのです。 つまり、強力なモデルはまるで総組立ラインの最後の工程のようなものです。前工程まで手を広げられるわけではありませんが、最初から最後まで全てを処理させると、コスト構造がすぐに崩れてしまいます。 これが、blog-writer が設計上、投稿済みデータである published.runtime.json のみを読み取り、原稿作成時にプロバイダーを切り替えたり、スイートディレクトリ全体を再走査したりしない理由です。消費側（クライアント側）が軽いほど、より強力なモデルに記事の「仕上げ」に集中してもらうのが最適なのです。 Minimax の意味は、単にプロバイダーを増やしただけではない 多くの人は「Minimax」を見ると、「またモデルを一つ追加しただけか」と最初に思いがちです。\nしかし、そうは思いません。\nMinimax が真に価値があるのは、「複数のプロバイダーからの出力を、単一の公開契約（スキーマ）で消費できる道筋を作った」点にあります。\n2026年4月2日 10:18 の 9f15199 で blog-style-suite がマルチモデル構成に変更され、出力がプロバイダーごとに分離されました。その後も README やランタイムの構造では、常に一つのことを強調しています。それは、スイートは多くの結果を生成できるが、実際に有効なのは人間が選んだ published.runtime.json だけだということです。\nこの境界線（バウンダリー）が非常に重要です。\nなぜなら、一度この境界が明確になると、Minimax の役割は「執筆プロセスに組み込まれなければならないもの」から、以下のようなものへと変わるからです。\n本番環境での比較に参加できる ランタイム版を生成するために使える ローカルモデルの成果物と横断的に比較できる 最終的に人間がどのバージョンを公開するかを決定する これにより、プロバイダーは「システムへの依存」から「交換可能な部品」へと変わりました。\nこれが、このエンジニアリングスタックにおける Minimax の最も興味深い意義だと私は感じています。それは、エンドツーエンドの全工程を支配するために存在するのではなく、「このリンク（プロセス）がインターフェースをきれいに受け止めているかどうかを検証する」ために存在しているのです。\n真の役割分担は、モデルの強さによるのではなく、タスクの種類によるべき 私は今、非常に古風だが実用的な分類法をより支持しています。\nルールとハード制約 ローカルスクリプトに任せる。 scanner.py、write_post.py、write_post_series.py のような決定論的なツールで解決できることは、モデルに混ぜ込ませないこと。\nスタイルデータ生成 ローカルモデルまたはコストの低いプロバイダーを優先します。 ここでの最も重要なのは、単発の出力が最も華やかであることではなく、再現性、試行錯誤可能性、キャッシュ可能性です。\n最終原稿作成と事実の締めくくり より長いコンテキストの統合、表現の収束、およびインターネットからの事実補完に適したモデルに任せる。 このレイヤーこそが、オンラインモデルにお金をかける価値がある場所だ。 このように分解すると、以前は悩んでいた問題も実はそれほど複雑ではないことがわかる。毎日「どのモデルが最強なのか」を議論する必要はなく、「このタスクはどのレイヤーに属するか」と尋ねるだけでよいのだ。\n結局、最も価値があるのはモデルではなく境界が明確なことである 第3編はここまでとさせていただきます。 blog-writer と blog-style-suite という一連のものは、進化する過程で、誰を接続したか、誰に入れ替えたか、どのプロバイダーを試したかといった点よりも、最も価値があるのは境界が徐々に明確になってきたことです。\nblog-writer は消費側を担当 blog-style-suite は生成側を担当 published.runtime.json が公開の場所である ローカルモデルは繰り返し実行する面倒な作業や重い作業に適している オンラインモデルは最後の仕上げに適している Minimax のようなオンラインプロバイダーは、システムの中枢というよりも交換可能な部品のようなものだ。 境界が明確になると、ワークフロー全体がスムーズになる。 一つのモデルパッケージだけで全てを解決できると期待したり、全てのステップを最も高価なレイヤーに積み重ねたりすることはなくなる。結局のところ、これはモデルを選ぶように見えて、実際には異なる種類のタスクに作業場所を割り当てているだけなのだ。 端的に言えば、単一の点が強いのはもちろん良いことだ。 しかし、長期的に見ると、境界が明確であることは、単一の点よりも強く、より重要であることが多い。 参考資料 リポジトリコミット：9f1519967981c5eef7bd1eb407b0406ac542ebd0 リポジトリコミット：5f17088391ee858b88fc50df884bc0103ff0b3c1 リポジトリファイル：scripts/blog-style-suite/config.json 有効なランタイム：.agents/data/blog-writing/published.runtime.json 関連旧記事：重度AIプログラミングの日々 関連旧記事：結局は国産モデルに戻る 関連旧記事：弱モデルに無理な強活を適用しない 作成上の注記 元のプロンプト $blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writerの初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルとして存在していました。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それがblog-style-suiteの誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考えたため、minimaxとも連携させました。blog-style-suiteとblog-writerの進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルのblog-writerやblog-style-suiteのコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することも可能です。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。 ライティングの骨子まとめ 第3編では、アーキテクチャの説明を繰り返すのではなく、「モデルの役割分担」という現実的な問題に焦点を当てて締めくくる。 冒頭で、現在のリポジトリにある published.runtime.json が minimax-m2 や config.json からローカルの gemma4 に切り替わっているという事実を直接提示し、前置きを減らす。 重要なのは、誰がより優れているかを証明することではなく、なぜ異なるタスクを異なるコストレイヤーに割り当てるべきなのかを説明することである。 Minimax を「交換可能なプロバイダー」の位置で語るのは、その意義をモデルのベンチマークリストではなく、エンジニアリングの境界線に引き戻すためである。 最後に、「単一の最高性能よりも明確な境界線の方が重要である」という全体的な判断に戻り、一連の記事を締めくくる。 ","date":"2026-04-03","language":"ja","permalink":"https://ttf248.life/ja/p/how-i-split-local-online-and-minimax-models/","tags":["AI霊感衝突坊","ai","プログラミング","minimax","ローカルモデル","blog-style-suite"],"title":"AIがブログを書くという件は、結局エンジニアリングにする必要がある（三）","year":"2026"},{"categories":["コンピューター"],"content":"トークンが十分にある場合、最も手っ取り早い方法は非常に粗暴ですが、過去の記事をそのままモデルに投入し、自分で学ばせることです。\n問題は、この方法はたまに1記事書くのには適していますが、繰り返し書くのには適さないということです。もしブログ執筆を長期的なワークフローとして真剣に取り組むのであれば、「生データ（歴史的な文章）」というアプローチは、すぐに「高コストで散漫」になってしまいます。\nこの一連の記事では、主軸が移りました。前回の記事 AIによるブログ執筆は、結局エンジニアリングにする必要がある（1）：blog-writerがなぜ生まれてきたか では、消費側（コンテンツの利用側）の自動化について取り上げました。この記事からは生産側、つまりスタイルデータがどのように生成され、どのように圧縮され、どうすればトークンを無駄に燃焼させないかという点について語ります。次の記事では AIによるブログ執筆は、結局エンジニアリングにする必要がある（3）：ローカルモデル、オンラインモデル、そしてMinimaxの役割分担 を続けます。\n最初の一番自然な発想は、過去の記事をそのまま与えることだ この道筋は本当に自然すぎる。 モデルにあなたの書き方を学ばせたいのなら、最も直感的な方法はもちろん、古い記事を餌として与えることだ。できれば、過去のブログの中で自分自身に一番近いと感じるものを詰め込んで、自分で要約させるのがベストだ。 一度きりのタスクを見る限りでは、これを行っても問題はない。 むしろ多くのケースで効果は良い。コンテキストが十分長く、モデルが十分に強力で、過去の記事が十分にあれば、スタイルを習得することは確かに可能だ。 しかし、問題は「この記事を書き上げられるか」ではなく、「次の記事、その次の記事も、これを繰り返さなければならないのか」ということなのだ。 毎回古い記事のバッチを再投入することは、いくつかの非常に現実的な副作用をもたらす：\n同じ材料が繰り返しコンテキストを占有する トークン消費量が執筆回数にほぼ線形に増加する モデルが見るノイズが増えすぎ、真に有用なシグナルが逆に希釈されてしまう 執筆という動作とスタイル維持という動作が完全に結びつき、どちらも軽々しくできなくなる つまり、トークンが潤沢な時は、生で与えるのはもちろん可能だ。しかし、工学的な観点から常にこのようにすることはできないのだ。 これがデータモジュールとデータ生成モジュールを分離しなければならない理由です 後になって考えたところ、核心は一言に尽きます。「消費側」と「生産側」を分けることです。\nblog-writer が担当しているのは消費側です。これは、すでに公開されたランタイムを読み取り、固定の契約に従って記事を書き出すだけです。\n一方、スタイルデータのスキャン、フィルタリング、スコアリング、圧縮、プロバイダー比較などは、別の生産側のパイプラインに置かれるべきでした。つまり、後から作られた blog-style-suite のようなものです。\ngitの履歴を見れば、この転換は非常に明確です。\n2026年4月1日 21:47 のコミット 84a06b5 で、元の blog-style-maintainer スキルがリポジトリレベルのCLIツールに置き換えられたことが明記されています。この動きは物事を物語っています。なぜなら、scan/build/rebuild があり、出力ディレクトリがあり、リカバリ機構がある時点で、それはもはや単なる「スキル」ではなく、通常のPythonプロジェクトのように見えてくるからです。\nさらに2026年4月1日 23:05 のコミット 9e92b8e では、blog-style-suite が scanner.py、builder.py、compressor.py といったモジュールに分割され続けました。この段階に至ると、考え方はすでに非常に工学的なものになっています。\nscanner.py: ディスクから記事をスキャンし、構造化された特徴を抽出する役割 builder.py: スコアリング、選別、キャッシュ、ランタイムアセンブリの役割 compressor.py: モデルが関与するいくつかの圧縮ステップを担当する これは、単にスーパープロンプトを一段書くというアプローチとは、全く異なる考え方なのです。\nトークンを節約するのは、玄学ではなく前処理とバッチ化によるもの このエンジニアリングセットで真に価値があるのは、2026年4月2日19:41のbc4b950だと思います。\nあのコミットは非常に率直なことを述べていました。AIの呼び出し回数が約「2000回」から、各プロバイダーで最大「5回」に直接削減されたのです。\nどうやって達成したのか？ それは「プロンプトをより賢くする」のではなく、事前に処理すべきものを前もって実行することによるものです。\n現在のblog-style-suiteのフローは非常に明確になりました：\nscanフェーズは純粋にヒューリスティックであり、AI呼び出しは0回。 buildフェーズではまずヒューリスティックなスコアリングを行い、これもAI呼び出しは0回です。 その後、technical / finance / essay / toolingの4つのレーンそれぞれで1回のバッチ選別とラベリングを行います。 最後に作者スタイルの圧縮を1回行います。 これを計算すると、コールドスタートでも最大5回の呼び出しに抑えられます。\nさらに重要なのは、この5回が各記事に分散しているのではなく、すでに前処理された高価値な要約材料に集中している点です。\nこれが前処理が真にトークンを節約する部分です。単に数文字を減らすのではなく、「記事ごとに呼び出す」から「フェーズごとに集中的に呼び出す」というパラダイムシフトなのです。\nその後は、キャッシュも整備されました。 builder.pyにはレーンのバッチフィンガープリントがあり、プロバイダーのチェックポイント復元機能があり、さらにローカルモデルのコンテキストのためにreview_pool_per_lane = 12のような縮小化が行われています。少しデータを変更しただけで、パイプライン全体を再実行する必要がありません。\nこうした設計は一見派手ではありませんが、一つ一つが非常に実用的です。なぜなら、それらはすべて「同じトークン群を二度と無駄に燃焼させない」という問題を解決しているからです。\n現在のデータ構造は、本質的に真に有用なシグナルを圧縮しているものだ この構造を分解すれば、データ構造も整理されるだろう。 私は今、これを3層として理解する方がより良いと感じている。\n第1層：scan.json これは共有の原料です。 ここには、記事のパス、タイトル、日付、カテゴリ、タグ、冒頭段落、クロージングスタブ、見出し、スクリーニング結果、レーン分類といった構造化されたシグナルが格納されています。 これは blog-writer に直接渡されるものではなく、生産側でさらに加工するためのものです。\n第2層：{provider}.source.json これはプロバイダーレベルのチェックポイントです。 共有された原料に加え、スコアリング結果、レーン選択、フィンガープリント、キャッシュステータスといった中間状態が追加されています。つまり、「加工過程の中間製品」のようなものであり、復元可能、再利用可能、中断して再開できる点が重要です。\n第3層：{provider}.runtime.json と published.runtime.json これが消費側が真に気にする完成品です。 ここには以下のものが保持されています：\nauthor_style lanes samples writer_guide つまり、元々大量にあった過去の記事群を、そのまま利用できるランタイムスタイルアセットとして圧縮したものになります。 特に published.runtime.json という公開用のファイルが重要です。blog-writer はこのファイルのみを読み取り、content/post を再スキャンしたり、suite ディレクトリ内の全プロバイダーの完全なイメージを気にする必要がなくなります。 この境界線が引かれることで、消費側は軽量化します。執筆モデルが見るのは、もはや原始的な古い記事の山ではなく、すでに前処理された高密度のシグナルとなるのです。 すべてのことをモデルにさせるべきではない 最近、このエンジニアリングにおいて最も正しい判断は、「モデルを多く追加すること」ではなく、「モデルに任せるべきでないこともモデルに投げ渡さないこと」だと感じています。\n以下のようなことは、ローカルルールで処理する方が適しています：\nfrontmatter の解析 冒頭段落の抽出 見出し（headings）の抽出 本人/転載/モデルによる署名の判断 blockquote の比率チェック \u0026lt;!--more--\u0026gt; や埋め込みプロンプト、本文の長さといったハードルルールでのフィルタリング これらの作業をモデルにやらせることは不可能というわけではなく、単に無駄です。\nモデルがより適しているのは、曖昧さやトレードオフを含む部分です。例えば、「あるレーンの中でどの記事が現在の論調をよりよく代表しているか」、あるいは「高評価の記事から著者のスタイルタグを抽出する」といった作業です。\nそのため、blog-style-suite が真に価値があるのは、「トークンを節約できる」という点だけではなく、人間、ルール、モデルのそれぞれが担当すべき役割を再定義した点にあるのです。\n前処理はトークンを節約するためではなく、執筆作業を持続可能にするためである 第2回の結論について、もっと直接的に伝えたい。 トークンが潤沢な時は、過去の記事をそのまま使うのはもちろん問題ない。むしろ、本当に1〜2本だけ書くなら、頭を使う量が少ないかもしれない。 しかし、このことを長期的なワークフローにしたいと思うなら、前処理は選択肢ではなくなる。なぜなら、前処理をしないと、執筆モデルは毎回古い素材を見直さなければならず、スタイルの維持と記事生成が常に混ざり合ってしまうからだ。 blog-style-suite の意味するところは、このごちゃ混ぜになっているものを分解することにある。 システムに見せるためでも、プロジェクト名を増やすためでもなく、blog-writer が軽快に、安定して、「執筆」という一つの動作だけに集中できるようにするためなのだ。 ここまで来ると、次のステップの問題は自然とついてくる。 すでに生成側が独立した以上、このコストをどのモデルに負わせるべきなのか？ローカルモデル、オンラインモデル、Minimax はそれぞれどの工程に立つべきなのか？この件については、次回の記事 AIでブログを書くという行為は、結局エンジニアリングにする必要がある（三）：ローカルモデル、オンラインモデル、そして Minimax の役割分担 で触れることにする。\n参考資料 リポジトリコミット：84a06b5dc743f2e9bc6e788d53496a1261bc63ae リポジトリコミット：9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043 リポジトリコミット：bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e リポジトリファイル：scripts/blog-style-suite/README.md リポジトリファイル：scripts/blog-style-suite/style_pipeline/scanner.py リポジトリファイル：scripts/blog-style-suite/style_pipeline/builder.py リポジトリファイル：scripts/blog-style-suite/style_pipeline/compressor.py 有効なランタイム：.agents/data/blog-writing/published.runtime.json 作成上の注記 元のプロンプト $blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その際は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づいたため、これらの作業を自動化するskillを作成できないかと考えました。これがskill blog-writerの初稿の誕生につながりました。また、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したskillでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それがblog-style-suiteの誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxを組み込みました。blog-style-suiteとblog-writerの進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルのblog-writerやblog-style-suiteのコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。 ライティングの骨子（要約） 本稿では、執筆という行為からデータエンジニアリングへと焦点を移し、「なぜモジュール化する必要があるのか」という核心的な問いに答えることを目指した。 冒頭で「生きた歴史の記事をそのまま使える」と認めることで、後続の分割理由に説得力を持たせている。 scan.json、source.json、runtime.json の三層構造を重点的に展開し、単なるアーキテクチャの説明に留まらないようにした。 bc4b950 を中間地点の転換点として配置した。なぜなら、「約2000回から5回へ」という変化が前処理の価値を最も明確に示すためである。 最後に、消費側と生産側を再分離し、次回の記事で扱うモデルの役割分担への布石を打った。 ","date":"2026-04-03","language":"ja","permalink":"https://ttf248.life/ja/p/how-blog-style-suite-split-style-and-token-cost/","tags":["AI霊感衝突坊","ai","プログラミング","blog-style-suite","token","ワークフロー"],"title":"AIがブログを書くという件は、結局エンジニアリングにする必要がある（2）","year":"2026"},{"categories":["コンピューター"],"content":"昨年、多くの AI に関する記事を書きました。あの頃の最も手間のかかるプロセスは、まず自分でアウトラインや問題リストを整理し、大規模言語モデルに本文を出力させてもらい、その後その内容をローカルの md ドキュメントにコピー＆ペーストし、フロントマター、タグ、カテゴリ、タイトルなどを補完してから公開するというものでした。 このプロセスが使えないわけではありませんが、非常に面倒です。本当に時間がかかるのは本文ではなく、本文の外側の繰り返しの作業です。特に最近 Codex を使いすぎてからは、その不自然さがより強く感じられます。それはリポジトリを読み込めるし、ファイルを編集でき、資料を補完できるだけでなく、記事を直接ディレクトリに書き込むこともできます。もし私がまだ手動でコピー＆ペーストを繰り返していると、まるで人間がツールの足を縛っているような気分になります。\nこの一連の記事は、実は一つのことを伝えたいのです。AI によるブログ執筆は、単なるプロンプト一つに頼るだけでは限界が来ています。今回の記事ではまず blog-writer がなぜ生まれてきたのかを説明します。次の記事では AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（2）：blog-style-suite でスタイル学習とトークンコストをどう分離するか を続けます。そして最終回は AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（3）：ローカルモデル、オンラインモデル、Minimax は最後にどう分業するか で締めくくります。\n本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ 初期のワークフローは、端的に言えば外部委託されたパイプラインのようだった。 私自身がまず問題を明確にするか、あるいは大まかなアウトラインを立てる。モデルが本文を骨子として展開する。その後、人間が戻ってきて残りの公開作業を補完する。\nローカルの md にコピーする title、date、slug を補完する タグとカテゴリを入力する \u0026lt;!--more--\u0026gt; を補完する 参考資料を整理する どのディレクトリに配置するかを決定する この一連の作業は、一つ一つのステップを見れば難しくはないが、繋げると非常に面倒だ。面倒なのは技術的な難しさではなく、それらがすべて機械的であるにもかかわらず、やらざるを得ない点にある。 だからこそ、私は後になって、「[コマンドラインベースのAIコーディングインタラクション](/ja/p/command-line-ai-coding-interaction/）」のような変化は、単に「入り口が変わった」だけではないと感じるようになった。AIがリポジトリ内で直接ファイルの読み書きができるようになった今、ブログ執筆がまだ「本文をローカルドキュメントにコピーする」レベルに留まっているとしたら、ワークフロー全体がすでに時代遅れになっているのだ。 blog-writer 最初の価値は文体ではなく、契約を固定化すること blog-writer の最も初期のノードは、2026年4月1日17:00の 991536a です。gitコミット履歴を見ると、このバージョンではすでに SKILL.md、write_post.py、そして一連の初期のスタイル資料が組み込まれています。\nしかし、後から振り返ってみると、このドラフトの最も価値のある点は「AI が私の文体を学んだ」ことではなく、執筆の契約を固定化したことです。\n「契約を固定化する」とはどういうことか？\n入力には最低限、アウトラインとファクトアンカー（事実の錨点）が必要であること 出力は必ず完全なMarkdown形式であり、未完成品であってはならないこと frontmatter は人手に頼ることはできないこと 記事はチャットウィンドウ内に留まるのではなく、直接 content/post に配置されること この点は非常に重要です。なぜなら、プロンプト自体が不安定だからです。「以前のように書いて」と今日言っても、それはトーンが少し似ていると解釈されるかもしれません。明日もう一度同じことを言っても、表面的な構文しか学べないかもしれません。しかし、それが Skill として書かれると、ルールは「その場での即興」から「固定された工程」へと変わります。\n後続のいくつかのノードも、実質的にこの契約を補強し続けています。\n2026年4月2日22:54の 8eb735a では、著者フィールド、執筆に関する注記、元のプロンプトなどが固定されました。この段階に至ると、ブログ記事の完成は単に「本文が書き終われば完了」ではなくなり、メタ情報、トレーサビリティ（追跡可能性）、公開される注記までが標準化されたのです。\nしたがって、blog-writer の最初の価値は、モデルをより文章を書くのが上手に見せかけることではなく、執筆という行為自体に、再現可能な境界線を持たせたことなのです。\nシリーズ形式は、実は執筆の契約をさらに一歩進めたもの 単発の記事で安定して書けるようになると、次の問題がすぐに浮上します。 あるテーマは、そもそも一つの記事に詰め込むのが適していません。無理に詰め込もうとすると、結局は情報量が多すぎてメインの筋が散漫になり、どの点も深く掘り下げきれない長文になってしまいがちです。 これが、2026年4月2日 23:55 の 1a5604e が重要だった理由です。あの時、シリーズ形式と write_post_series.py をまとめて追加しました。記事間は relref で繋ぎ、一括書き込みの際に統一的に置換するようにしたのです。 これは単なるファイル生成スクリプトの小さなアップグレードに見えますが、実際はそうではありません。 それは一つのことを示しています。執筆の工程化は、「この一篇をどう生成するか」だけを考える段階から、「この一連のコンテンツをどう安定して配置し、順序をどう保証し、サイト内で相互にリンクさせるか」という視点に移ってきたということです。 翌日の2026年4月3日 09:29 の 04dccb9 は、この件をさらに一歩進めました。シリーズ記事のタイムスタンプが分単位で増加し、もはや共通の時間を使用しないようにしたのです。この変更は非常に小さいものですが、エンジニアリング的な深みがあります。なぜなら、Hugoのリストページ、前後の記事リンク、シリーズの順序といった「実際の問題」を解決しているからです。 端的に言えば、シリーズ形式というのは、格好良く見せるためではなく、「複数の記事をまとめて公開する」という作業が、もはや手動でのフォローアップに頼らなくて済むようにするためなのです。\nしかし、単一のスキルだけでは、後でトークン制限にぶつかることになる 問題はここにあります。 文体学習を真剣に行い始めると、blog-writer のコンテキストがすぐに肥大化します。ただ書くだけでなく、以前あなたのように書くことも期待するわけです。最も自然な方法は、過去の記事も一気に詰め込むことです。 これなら、一度だけは実行できます。 しかし、たまに記事を書くだけではなく、長期的なワークフローにしたいと思うと、すぐに問題が発生します：\nトークン消費量が高い 毎回同じ古い記事を繰り返し与えることになる モデルの注意力が古い材料によって希釈される 原稿執筆とスタイル維持が絡み合い、どちらも容易ではない ここから、私はblog-writerは、すべてを任せる側（生成側）というよりは、消費する側として使う方が適していることに気づき始めました。 原稿執筆という動作は、できるだけ軽く、直接的に、そしてできれば公開されたバージョンのみを参照するようにすべきです。一方、スタイルデータの生成方法、選別方法、圧縮方法は、別の生産側のパイプラインの問題なのです。この判断が、私を次のステップへと導き、それがAIでブログを書くという件は、結局エンジニアリングにする必要がある（2）：blog-style-suiteでスタイル学習とトークンコストをどう分離するかへと繋がりました。 まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる 今振り返ると、blog-writer が生まれたのは、私が突然ブログライティングアシスタントを作りたいと思ったからではない。 むしろ、これまでのワークフロー自体が、新しい働き方に合わなくなってきたことが原因だ。 Codex のようなツールがインターネットに接続して資料を補完できたり、リポジトリ内での読み書きができたり、スクリプトを直接呼び出せるようになった場合、「ブログを書く」という行為は「本文をローカルドキュメントにコピーする」という段階で止まっているべきではない。この部分を自動化しなければ、かえって全体のプロセスの中で最も非効率な工程になってしまう。 そのため、最初の記事の結論はここまでとする。 blog-writer が最初に解決したのは、文体ではなく、公開作業における反復的な手作業だった。このレイヤー（層）という契約がなければ、後からトークンやデータ構造、ローカルモデルについて語っても、実際には根拠がない。\n参考資料 リポジトリコミット：991536a237d04aba7c44dec501b3d98c644040c8 リポジトリコミット：8eb735aa8448c97deb2af1ea46b86772008fa9e3 リポジトリコミット：1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892 リポジトリコミット：04dccb98c55a6ea3b81408012b33a6219cf8ab77 リポジトリファイル：.agents/skills/blog-writer/SKILL.md リポジトリファイル：.agents/skills/blog-writer/scripts/write_post.py リポジトリファイル：.agents/skills/blog-writer/scripts/write_post_series.py 作成上の注記 元のプロンプト $blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writer の初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それが blog-style-suite の誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxとも連携させました。blog-style-suite と blog-writer の進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルの blog-writer および blog-style-suite のコードを基にして、設計思想や、どのようにトークン節約を実現したか、データ構造はどう設計したか、といった核となる設計思想について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。 ライティングのアイデア概要 最初の記事はワークフローのトリガーポイントに焦点を当て、トークンとモデルの役割分担を急ぎすぎず、3つの記事でメインテーマを奪い合うのを避ける。 「本文自体は難しくないが、公開前後の一連の機械的な作業が面倒である」という判断を重点的に残した。 991536a、8eb735a、1a5604e、04dccb9 などのノードを通じて、「プロセスを契約化する」ことを実際のGitの進化に落とし込む。 シリーズ形式はこの記事で取り上げることで、ブログ執筆が単発の記事生成から一連の成果物（セット）へと移行したことを示すためである。 最後に意図的に問題をトークンウォールに引きつけ、次の記事でのデータエンジニアリングと前処理のための布石とする。 ","date":"2026-04-03","language":"ja","permalink":"https://ttf248.life/ja/p/why-blog-writer-had-to-exist/","tags":["AI霊感衝突坊","ai","プログラミング","blog-writer","skill","ワークフロー"],"title":"AIがブログを書くという件、結局は工学的なものにする必要がある（1）","year":"2026"},{"categories":["コンピューター"],"content":"この数日、AIプログラミングについて見てきましたが、さっきまでみんながMCPの話をしていて、次の瞬間にはまたSkillの話をしています。この言葉を初めて目にする人は、本能的にこれをまた新しいプロトコルか、あるいは高度なプロンプトだと捉えがちです。\n私の判断は非常にシンプルで、SkillはMCPの座を奪いに来たものではなく、むしろエージェントに職種マニュアルのようなものを提供している感じです。MCPが解決するのは「エージェントが外部世界と接続できるか」という点であり、Skillが解決するのは「接続した後、どのような手順で確実にタスクを遂行するか」という点です。これらは代替関係ではなく、むしろ前後関係に近いです。\n端的に言えば、MCPはエージェントに手足を与え、Skillはエージェントが勝手に動かないようにするためのものです。\nSkill とは一体何なのか 最も分かりやすい言葉で説明するなら、こう言います。 ベテラン社員の頭の中にある熟練したやり方を、再利用可能で、トリガーでき、実際に実行できるマニュアルとしてまとめたものが Skill です。\nOpenAI の公式ドキュメントの定義も非常に直接的です。Skill は特定のタスクに向けた能力パッケージの一種であり、指示（プロンプト）、参考資料、そしてオプションのスクリプトを格納できます。目的はモデルを「より賢くする」ことではなく、ある種のタスクにおいて固定されたワークフローに従って安定的に出力をさせることです。\n何に最も近いか？\n通常のプロンプトとは異なり、一度話して終わりではないからです。 MCP とも異なります。なぜなら、ツールやデータソースを接続する責任を持たないからです。 また、AGENTS.md のようなものでもないからです。全リポジトリで通用するルールではないからです。 むしろ、専門の SOP（標準作業手順書）や、職種マニュアルのようなものです。\n例えば：\nGitHub PR のコメントを処理する場合：まずどのコメントを処理すべきかを確認し、次にユーザーにどのコメントを処理するか尋ね、コードを修正し、最後に結果をフィードバックする。 CI の失敗を調査する場合：まず GitHub Actions のログを取得し、次に失敗した部分を抽出して要約し、修復計画を立て、承認されてから作業に取り掛かる。 ブログ記事を書く場合：まず固定の文体でタイトルを生成し、次に事実情報を補完し、さらにフロントマター（メタデータ）を追加し、最後に公開する。 これらの事柄に共通しているのは、「モデルがどう回答すべきか知らない」ということではなく、「モデルのやり方が毎回異なり、逸脱しやすい」という点です。ここで Skill の価値が出てくるのです。\nSkill と MCP、結局どこが違うのか これは実際のワークフローに当てはめて見ないと分かりにくいので、単なる説明だけでは誤解を招きやすいです。\nMCP はインターフェース層のようなものです。\n公式における MCP の定義は、「AI アプリケーションを外部システムに接続するためのオープンスタンダード」です。ファイル、ローカルデータベース、検索エンジン、デザイン稿、サードパーティサービスなど、これらすべてを MCP を通じて取り込むことができます。つまり、これが解決しているのは「取り込み（コネクション）」の部分です。\n一方、Skill はプロセス層のようなものです。\nOpenAI の Agent Skills ドキュメントには明確に書かれていますが、Skill は再利用可能なワークフローを記述するためのフォーマットです。一つの Skill には最低限 SKILL.md が必要で、さらに scripts/、references/、assets/ を含めることができます。Codex はまずその name と description を読み込み、実際に使用する必要があると判断した場合にのみ、完全な説明をコンテキストにロードします。これが公式が言う「プログレッシブ・ディスクロージャー（段階的開示）」です。\nしたがって、両者の役割分担は非常に明確です。\nMCP: 能力を取り込む（コネクションする） Skill: 行う手順の順序を定める 非常に分かりやすい例で言うと、「Figma からコードへの変換」のような作業です。もしエージェントがデザイン稿自体を読み取れていない場合、まず補うべきなのは MCP です。しかし、すでにデザイン稿を読み取れるようになったのに、毎回バラバラにコーディングしてしまう（今日はコンポーネントから書き始め、明日はページ分割から始め、明後日にはビジュアルチェックを忘れる）という状況であれば、補うべきは Skill なのです。\nスキルの開発方法 これは思ったほど重くありません。 OpenAIの公式推奨では、まず組み込みの$skill-creatorを使用し、トリガー条件、範囲、スクリプトが必要かどうかといった骨格部分を構築してもらうことです。デフォルトではinstruction-only（指示のみ）が優先されるため、焦ってスクリプトを書くのではなく、まずは説明を明確にすることが重要です。 手動で記述する場合でも、最小限の構造は非常にシンプルです：\nmy-skill/ ├── SKILL.md ├── scripts/ ├── references/ └── assets/ この中で真に必要なのはSKILL.mdだけです。そして、このファイルには最低限2つのメタデータが必要です：\n--- name: skill-name description: Explain exactly when this skill should and should not trigger. --- 私が考えるに、Skillを開発する上で最も重要なのは以下のステップです。\n1. 「繰り返し現れるバイアス」を探す すべてのタスクが Skill にする価値があるわけではありません。 エージェントに単発で作業をさせるだけであれば、通常のプロンプトで十分です。真に Skill として抽出するのに適しているのは、通常以下のようなケースです：\n同じことを何度も繰り返して指示している場合 エージェントには能力があるはずなのに、実行順序がいつも変わってしまう場合 間違いが発生する箇所が毎回似ている場合 つまり、「能力不足」なのではなく、「手順（ノウハウ）が安定していない」ということです。 2. description をトリガー条件として記述し、宣伝文句にしないこと このステップは非常に重要です。 公式ドキュメントでは、Codex がどの Skill を暗黙的に呼び出すかについて、description に大きく依存すると強調しています。「これはとても便利なスキルだ」といった表現ではなく、「いつ使うべきか、いつ使ってはいけないか」を記述してください。 例えば、gh-fix-ci の公式スキルの説明は非常に明確です：「ユーザーが GitHub PR チェックの失敗をデバッグまたは修正してほしい場合に使用する」というものです。重要なのは、ログを確認し、失敗の原因を要約し、修正計画を提示することであり、そして明示的な承認を得てから実行することです。これを見るだけで、その境界線がどこにあるかがわかります。\n3. 説明で対応できるなら、まずスクリプト化しない OpenAIのドキュメントでも非常に実用的なアドバイスをしています。明確な決定論的動作や外部ツールが必要でない限りは、いきなりスクリプトにするのではなく、まずは説明（プロンプト）を使うべきです。 なぜか？スクリプトが増えれば増えるほど、メンテナンスコストが上がってくるからです。 多くのSkillは、最初は単に手順を明確に説明するだけで十分です：\n何から始めるか 次に何をするか 出力形式はどうするか どのような状況でユーザーに確認を求めるべきか これだけでも大半の問題は解決します。 あるステップが非常に安定していて、非常に機械的で、自動化に適している場合にのみ、scripts/に落とし込むようにしましょう。 4. 資料、テンプレート、リソースを分離する Skill は書き進めるうちに、非常に長い説明文になりがちです。そんな時は分割すべきです。\nSKILL.md はルールと手順を担当する references/ には背景ドキュメントや参照資料を置く assets/ にはテンプレート、アイコン、サンプルを置く scripts/ には安定して実行できるアクションを置く このようにすることで、2つの利点があります。 第一に、メインファイルが肥大化しすぎるのを防げます。第二に、モデルが必要なときだけ詳細を読み込む形になり、「プログレッシブ・ディスクロージャー（段階的開示）」という考え方に沿えます。 5. ローカルで先に使い、プロジェクトをまたいで配布する 公式ドキュメントでもこの点は明確に分けられています。 もしご自身の現在のリポジトリでのみ使用するのであれば、.agents/skills/ に配置するだけで十分です。Codex はリポジトリ、ユーザー、システムなどの場所からスキルディレクトリをスキャンします。 しかし、この仕組みが単一のリポジトリだけでなく複数の場所で使えることに気づいた場合や、複数のスキルをまとめてパッケージ化して配布したい場合は、skill folderの層に留まらず、plugin を検討すべきです。OpenAI公式ドキュメントの記述も非常に明確で、Skill はワークフローそのものであり、真にインストールおよび配布に適した単位は plugin です。\nスキルが適しているシナリオ Skill は多ければ良いというものではなく、以下の種類のタスクに最も適しています。\n高頻度で繰り返すタスク 毎週行う、そして毎回手順がほぼ同じもの。 例えば：\nPRレビューコメントの処理 ブログ記事の執筆とフロントマターの追記 CI失敗の調査 リリース前のチェック このような作業は、モデルができないことよりも、毎回説明し直さなければならないことが一番面倒です。 固定フローのタスク ある事柄には、生まれながらにして順序があるものがあります。 例えば問題の調査をする場合、まずログを確認し、次に範囲を絞り込み、それから計画を立て、そして修正するという流れになります。このような場面では、Skill が特に適しています。なぜなら、順番を固定できるため、モデルがその場しのぎで対応するのを減らせるからです。\n専門的な文脈に紐づける必要があるタスク 手順が固定されているだけでなく、強い制約を伴うタスクもあります。 例えば：\n公式ドキュメントのみを参照すること 特定のレビュー形式で出力しなければならないこと チーム内の既存の用語を保持しなければならないこと 特定のリポジトリの記述または開発規約を遵守しなければならないこと このような作業は、毎回プロンプトに頼って一時的に指示を出すだけでは、漏れが生じやすいです。 ツールとプロセスを併用するタスク このシナリオは特に典型的なものです。 単に「GitHubに接続する」だけで終わるのではなく、接続した後も、何らかの方法でログを確認し、問題を分類し、修正が必要かどうかを判断し、最後にどのようにフィードバックするかという一連の作業が必要です。つまり、外部接続と内部プロセスが組み合わさって機能しなければなりません。 このような場合、しばしば MCP + Skill が組み合わさって登場します。\nスキルとして実装する必要がないシナリオ 逆に、どこまでを「スキル」とするのかを明確に伝える必要があります。そうしないと、何でもかんでもSkillにしようとしてしまいがちです。\n一回限りの気軽なタスク ユーザーが一時的に質問する場合、通常のプロンプトで十分なことが多いです。\nあなたが望んでいるのは「外部システムへの接続」だけだ その場合は、Skill ではなく MCP を優先的に検討してください。\nリポジトリ全体の長期的な振る舞いを制約したい場合 これは Skill の仕事というよりは、AGENTS.md の仕事に近いです。 したがって、簡単にまとめると以下のようになります：\n接続が不足している場合、MCP を使う プロセスが不足している場合、Skill を使う グローバルなルールが不足している場合、AGENTS.md を使う 代表的な事例をいくつか 概念をどれだけ説明しても、実際の事例を見る方が良いです。\n1. roll-dice：最小限の入門ケース このケースはOpenAI公式のAgent Skillsドキュメントからのものです。 非常に小さく、ディレクトリ内にはほとんどSKILL.mdしかなく、エージェントがユーザーからサイコロを振るよう要求された際に、PowerShellの乱数コマンドを呼び出すようにします。 なぜこの例が良いのか？ それはSkillの最も核となる骨格を直接示しているからです：\n明確なトリガー条件がある 明確な実行方法がある 明確な境界線がある これは、Skillが必ずしも大きくなくて良いことを示しています。あることが繰り返し発生し、モデルに無作為な振る舞いをさせたくない場合、それをSkillとして実装できるということです。 2. gh-address-comments：GitHub コメント処理のワークフロー例 このケースは、OpenAI 公式の openai/skills リポジトリから来ました。 目的は「GitHubに接続する」ことではなく、「現在のブランチのPRのコメントを処理する」という一連のプロセスを固定化することです。公式バージョンでの手順が非常に典型的です：\nまずghが認証済みか確認する 次に、現在のPRのコメントとレビュースレッドを取得する これらのコメントに番号を振り、要約する ユーザーにどのコメントを処理するか明確に選択させる その後で初めて処理を開始する この例は、Skill の価値を特に示しています。 多くのエンジニアリングタスクにおいて、難しさは「モデルがGitHubとは何かを知っているか」という点ではなく、「正しい順序で物事を処理できるか」という点にあります。gh-address-comments が解決しているのは、まさにこのような順序の問題です。 3. gh-fix-ci：CI 失敗のエンジニアリングケースの調査 これも openai/skills リポジトリ内の公式スキルです。 これは別の非常に典型的なエンジニアリングタスクを対象としています。それは、PR のチェックが失敗したとき、「直すべきか」「どう直すか」というものです。 この Skill で定義されているワークフローも非常に代表的です：\nまず gh のログイン状態を確認する 現在の PR を見つける GitHub Actions の失敗したチェックとログを取得する 失敗した部分を抽出する まず修正計画を立てる 承認を得てから実行する これは、「CI がなぜ失敗したか見て」という単なるプロンプトでは安定して対応できないシナリオです。なぜなら、権限、ログ、外部ツール、承認の境界線、実行順序など、これらすべてを定義する必要があるからです。 4. リポジトリ固有のスキル：チーム独自のノウハウを蓄積する 公式なサンプル例以外で、私が考える Skill のより大きな価値は、実はプライベートリポジトリ内にあります。 例えば、目の前のブログリポジトリにある blog-writer は、本質的には非常に典型的な repo-scoped skill です。これは「モデルに中国語の書き方を学ばせる」ことを担当しているのではなく、このリポジトリで既に固定された文体、構造、ファクトチェック、出力パス、データ保存形式などをワークフローとして記述したものです。 このような Skill は、最も現実的な価値を持つことが多いです。なぜなら、すべての人に向けられているわけではなく、「あなたはこのリポジトリで、どのような種類の作業が繰り返し発生し、かつ逸脱しやすいか」という点に特化して解決するものだからです。\n実際に「Skill」を使うべき時 そこで、最後に最も実用的な問題に戻ります。いつ真剣に Skill を作るべきでしょうか？ 私の答えは以下の通りです。 それは、問題がもはや「モデルの能力不足」ではなく、「毎回同じ行動が安定しない」と感じたときです。 この段階でプロンプトを積み重ねても、得られる利益は通常低くなる一方です。今日一文追加し、明日また一文追加するうちに、プロンプトはまるで出来事の羅列になり、モデルはやはりミスを犯します。 むしろ、それを Skill として整理し、トリガー条件、手順、境界線、スクリプト、資料などを分けて管理する方が、効果が安定しやすく、再利用性も高まります。 MCP は外部世界と接続し、Skill は内部のノウハウを固定化します。 前者は「できるかどうか」を解決し、後者は「どうすれば安定してできるか」を解決します。 これが私が今理解している Skill です。 それは新しいプロンプトでも、新しいプロトコルでもありません。 むしろ、エージェントに職種マニュアルを渡すようなものです。\n参考資料 Agent Skills - Codex | OpenAI Developers Using skills to accelerate OSS maintenance | OpenAI Developers What is the Model Context Protocol (MCP)? | Model Context Protocol openai/skills | GitHub gh-address-comments/SKILL.md | openai/skills gh-fix-ci/SKILL.md | openai/skills 作成上の注記 元のプロンプト プロンプト：AI大規模言語モデルによるプログラミングについて、まずMCPが登場し、次にSkillが登場しました。平易な言葉で、Skillが何か、どのようにSkillを開発するか、どのようなシナリオに適しているか、それぞれ具体的な代表的な事例を挙げて説明してください。\nライティングの骨子まとめ 「MCP と Skill の概念レビュー」として繰り返し書くのではなく、重点を Skill の役割と使用範囲に置いた。 「職種マニュアル」「特定作業手順書（SOP）」といった平易な比喩を用いて、抽象的な定義を実際のワークフローに落とし込んだ。 開発部分は公式ドキュメントの実構造に沿って記述し、description、progressive disclosure、instruction-only といった重要な点を保持した。 ケーススタディは可能な限り公式ソースを選定し、それぞれ公式ドキュメント内の roll-dice、および openai/skills リポジトリ内の gh-address-comments と gh-fix-ci を使用した。 最後に、読者が読み終えた後も混同しないよう、MCP、Skill、AGENTS.md の三者の境界線を改めて整理した。 ","date":"2026-04-02","language":"ja","permalink":"https://ttf248.life/ja/p/skill-is-an-agent-handbook/","tags":["ai","codex","skill","mcp","プログラミング"],"title":"Skill は新しいプロンプトではなく、エージェントに職種マニュアルを提供するものです。","year":"2026"},{"categories":["コンピューター"],"content":"最近、いくつかの端的な作業を MiniMax やローカルモデルに移行させているが、使うほど「最強モデル」という基準で物事を測るのは違うと感じるようになった。\n私の判断は非常にシンプルだ。弱いモデルに無理に難しいタスクを割り当ててはいけない。「MiniMax」のようなモデルは、能力が劣っているのは事実だが、複雑なコーディング、長尺の推論、曖昧な要件の分解といった作業には確かに物足りない。しかし、データクレンジング、ドキュメント作成、提案資料の検索といったタスクであれば、これらは十分にこなせる。同じロジックで、ローカルの12Bクラスのモデルも同様だ。翻訳、フォーマットの書き直し、バッチ処理でのクレンジングなど、むしろそちらが本来適している場所なのだ。\n端的に言えば、モデルに価値がないのではなく、単に間違った場所に配置されているだけだ。\n本当の問題は、モデルがどれだけ強力かではなく、どれだけ「生きている」かである 多くの人が大規模言語モデルについて話すとき、頭の中では最も難しいタスクを思い浮かべがちです。\n複雑なエンジニアリングを単独で書くこと システム全体を一度に分解すること 長いコンテキスト内での複数ターンにわたる推論の処理 検索しながら計画し、実行する これらはもちろん重要です。しかし、現実の業務で机の上に積み重なっているものの多くは、このような作業ではありません。 むしろ多いのは以下の類です： 一連の汚れたフィールドをクリーンアップすること ばらばらの資料を読みやすいドキュメントに整理すること 長文を要約、FAQ、アウトラインに変更すること 中文と英文が混在する内容を統一フォーマットにすること 複数のウェブページから資料を探し出し、ついでに提案書の草稿としてまとめること このようなタスクで最も必要なのは、「モデルが天才のように考える」ことではなく、以下の3点です： 指示追従性が極端すぎないこと（常識的であること） 出力構造が可能な限り安定していること コストが十分に低く、何度も使いたくなるほど低いこと だからこそ、私は弱いモデルは役に立たないのではなく、単にフラッグシップモデルと同じ戦場に持ち出せないだけだと考えているのです。 MiniMax が真に得意なこと まず MiniMax についてです。\n公式は MiniMax-M2.5 の位置づけを非常に高く設定しており、プレスリリースやオープンプラットフォームのドキュメントでは、プログラミング、ツール呼び出し、検索、オフィス生産性といったシナリオに重点を置いています。さらには速度と価格の優位性を強調しています。これらの主張を完全に信じられないわけではありませんが、私はそれを分解して見る方が好みです。\n私にとって、MiniMax が真に使いやすいのは、「最も複雑な開発タスク」ではなく、以下の点です：\nデータクレンジング データクレンジングと一口に言っても、半構造化テキストの肉体労働です。\n名称の統一 フィールドのマッピング 外れ値のアノテーション 分類ラベル付け 表形式フィールドの補完 このような作業が最も恐れるのは、モデルが「愚か」なことではなく、フォーマットが不安定であったり、出力が拡散したりすることです。モデルが JSON、表、固定テンプレートに従って結果を出力できれば、実は十分な場合が多いです。高性能なモデルももちろん可能ですが、最も高価なモデルをフィールドクレンジングに使うのは、多くの場合費用対効果が悪いです。 ドキュメント作成 ドキュメント作成は面倒くさい、難しいわけではない。 インターフェースが変わる、プロセスが変わる、フィールドが変更される、といったたびに説明書を修正しなければならない。この過程には、モデルに高い創造性が求められるというよりは、むしろ余計なことをして元の明確な情報を曖昧にしてしまわないように注意することが重要だ。 MiniMax はこのような作業において、想像以上に信頼できることが多い。特にコンテキスト（文脈）を準備しておけば、真のエンジニアというよりも、実務ができるドキュメントアシスタントのような存在になる。\n方案資料検索 公式側も検索やツール呼び出しを推進しているので、この方向性は問題ありません。 多くの場合、私たちが求めているのはモデルに「空から答えを思いつかせる」ことではなく、ウェブページ、ドキュメント、お知らせ、資料などをまず探し出してきて、それから整理してもらうことです。このようなシナリオでは、MiniMax のような安価なモデルの価値が非常に高くなります。なぜなら、検索、要約、統合といった作業は元々頻繁に行う雑務だからです。 したがって、私の実際の見解は以下の通りです：MiniMax がダメなのではなく、むしろ生産パイプラインの中での「汚い仕事」「面倒な仕事」「繰り返しの仕事」に向いているということです。雑用をさせるなら、合格点であることが多いですが、すべてを包括的に担当させようとすると、がっかりする確率が高くなります。\nローカルの12Bモデルは、持ち帰るのに最も適したタスクがある さらに下を見ると、ローカルデプロイメントは基本的に同じロジックです。 多くの人が「ローカルモデル」と言うと、どうしても一つの疑問が浮かびます。「クラウド上のフラッグシップに取って代われるのか？」と。 しかし、この質問自体が最初から偏っていると思います。 ローカルの12B程度のモデルが持つ真の価値は、「自分も最強クラスのタスクをこなせることを証明する」ことではなく、安定していて、反復的で、機密性が高く、利益率は低いが頻度の高い作業を持ち帰ることなのです。\n翻訳 これはローカルモデルにとって得意なシナリオの一つです。 Qwen2.5 の公式ブログでも明記されているように、長文生成、構造化データ理解、JSON 出力などが強化されており、さらに29以上の言語をサポートしています。この組み合わせは、翻訳、バイリンガルでの書き直し、フォーマットの統一、専門用語の標準化といった作業に本質的に適しています。 技術ドキュメント、フィールドの説明、製品紹介、インターフェースコメントなどは、構造が安定しており、専門用語が固定されていることが多いため、ローカルモデルが最もエレガントに翻訳できるとは限りませんが、通常は十分な品質です。\nデータクレンジング ここがローカルモデルが特に現実味を帯びている点です。 多くの表、ドキュメント、業務資料は、クラウドにアップロードしたくないものがあります。特に内部データ、顧客情報、議事録、未完成の提案書などは、プライバシーや権限が関わるため、ローカルで実行する方がずっと安心できます。 このような状況において、ローカルの「12B」程度のモデルの意義は、「どれだけ賢いか」ではなく、「自分のマシン上で動作し、こうした面倒な作業を安定してこなせるか」という点にあります。\n固定フォーマットへの書き換え 例えば：\n会議議事録を固定テンプレートに整理する 商品タイトルを統一の命名規則にクレンジングする バグの説明を工單形式に書き直す 中英が混在したテキストを単語バージョンにクレンジングする このようなタスクは共通の特徴を持っています：ルールが明確、バッチ処理が大きい、繰り返しが多い、単発あたりの価値は高くないが、総量が多いのが面倒。 これこそがローカルモデルが最も適している仕事です。 3060 12GB で 12B クラスのモデルを動かせるのか この件については、もっと現実的に書く方が良いと思います。「動かすことはできるが、あまり期待しすぎないでください。」という感じです。\nGoogle は Gemma 3 の公式ドキュメントで、非常に参考になるVRAM使用量の表を公開しています。Gemma 3 12B を動かすには、おおよそ以下のメモリが必要です：\n全精度バージョンをロードする場合：約 20 GB 中程度の量子化バージョンをロードする場合：約 12.2 GB より低いVRAM使用量のバージョンをロードする場合：約 8.7 GB 公式はまた、これがモデルのロードに必要なメモリ量のみであり、プロンプトや実行時の追加オーバーヘッドは含まれていないと注意喚起しています。\nこの一文が非常に重要です。\nこれはどういう意味か？ 3060 12GB のようなグラボで 12B クラスのモデルを動かすことが不可能だということではなく、前提条件があるということです。その前提とは通常以下の通りです：\n量子化されたバージョンを使用していること コンテキスト（プロンプト）を長すぎないようにすること タスクが複雑すぎないこと 速度が平均的、あるいは遅くても許容できること もしあなたがこれらの前提を受け入れる意思があるなら、ローカルで 12B クラスのモデルを動かすことは確かに可能です。少なくとも翻訳、要約、表のクレンジング、固定フォーマットへの変換といったタスクであれば、大げさな要求ではありません。\nまた、Qwen2.5-14B-Instruct-GGUF の公式リポジトリ自体が複数の量子化形式を提供しており、これはすでに考え方を非常に明確に示しています。このクラスのモデルは、本来ローカル推論のエコシステムを念頭に置いて適応されているのです。\nしたがって、私の結論は一貫して「3060 12GB が 12B モデルを楽々こなせる」というものではなく、むしろ： **「このようなモデルを動かすことはできるが、期待値が低く、反復性が高く、プライバシーが重要な作業に向いている」**ということです。\n安価なモデルとローカルモデルを使うことで節約できるのはAPI費用だけではない この件について話している人の多くは、まず「お金を節約できる」という反応をします。 もちろん、お金の節約は重要です。しかし、私が思うより大きな価値は、以前は面倒だと避けていた雑務を、思い切って外部に委託できるようになることです。 以前なら、数百件のデータクレンジングのために専用のスクリプトを書くことはなかったかもしれませんし、数十ページの日英資料のフォーマット統一のために手作業で少しずつ修正することもなかったでしょう。また、一時的な提案書のために資料を集める際も、ウェブページを一つ一つ読み込んで整理することさえなかったはずです。 しかし、今は違います。 コストが十分に低く、ハードルが十分に低い限り、「やる価値がない」と思われていたこれらの作業が一気に「やる価値がある」ものになります。あなたは「やるべきか？」と悩むのではなく、まず安価なモデルやローカルモデルに実行させるだけです。 これが私が目にする最も現実的な変化です。 強力なモデルは難題に取り組むことに専念し、弱いモデルは雑務をこなし、ローカルモデルが最終的な保証とバッチ処理を担当する。 このように役割分担することで、ワークフロー全体がスムーズになるのです。\nまとめ だから最後に言いたいのは、一つのモデルで全てを解決しようと考えすぎるなということです。 MiniMax のようなモデルは、能力が弱いという点はあるものの、使い物になりません。これを複雑なエンジニアリング、曖昧な要件定義、多段階の推論にぶつけても、当然ながらがっかりさせられるでしょう。しかし、データクレンジング、ドキュメント作成、ソリューション資料の検索といった作業に使えば、かえって非常に扱いやすいことが多いです。 ローカルで動作する 12B 程度のモデルも同じです。これらは「もうクラウド上のフラッグシップは必要ない」と証明するためではなく、安定していて、反復的で、機密性が高く、バッチ処理の大きいタスクを、地道に自分自身のマシン上に持ち帰るためにあるのです。 つまり、苦手なことを弱いモデルにやらせてはいけないということです。 適切な場所（用途）に置けば、それ自体が現実的な価値を持つわけです。\n参考資料 MiniMax M2.5: Built for Real-World Productivity MiniMax オープンプラットフォーム：テキスト生成 Qwen2.5: A Party of Foundation Models! Qwen2.5-14B-Instruct-GGUF Gemma 3 model overview 作成上の注記 元のプロンプト minimax の大規模言語モデルは、能力が弱いのは弱いが、データクレンジング作業やドキュメント作成、提案資料の検索などを行う分には問題ない。同じロジックで、ローカルに大規模言語モデルをデプロイし、翻訳などの作業やデータクレンジング作業を行うのも良い。モデルのパラメータ数は12b程度で、ローカルの3060 12GBのグラフィックボードでも動かせるはずだ。\nライティングの思考プロセス要約 「弱いモデルに無理なタスクを割り当てない」という核となる判断は維持し、モデルランキング比較としては記述しませんでした。 MiniMax の部分は、公式が定義するプログラミング、検索、オフィス作業といった用途に基づき、その判断をデータクレンジング、ドキュメント作成、資料検索といった現実的なタスクに落とし込みました。 ローカルモデルの部分では、公式ソースから Qwen2.5 と Gemma 3 の2つを選択しました。一方は多言語対応と構造化出力をサポートし、もう一方は 12B パラメータとVRAM使用量を考慮したものです。 3060 12GB に関する記述は、「帯域幅はあるが、あまり期待しすぎないでほしい」というニュアンスを意図的に含め、量子化推論を絶対的な結論として扱わないようにしました。 最後に、強力なモデル、弱いモデル、ローカルモデルという分類を用いて締めくくり、メインの論旨に焦点を絞りました。 ","date":"2026-04-02","language":"ja","permalink":"https://ttf248.life/ja/p/weaker-models-shouldnt-do-frontier-work/","tags":["ai","minimax","ローカルモデル","qwen","gemma"],"title":"弱いモデルに無理に強いものを適用しない","year":"2026"},{"categories":["コンピューター"],"content":"3月を通して、私は様々な大規模言語モデル（LLM）APIのトランジットポイント間を行き来して試していました。\n安さについては、確かに安いものでした。月にあまりお金をかけずに、ChatGPT、Claude、Geminiといった海外のモデルをすべて触ることができ、表面上は非常にコストパフォーマンスの高い解決策を見つけたように思えました。しかし、実際に使ってみるうちに、この道筋が最初から「品質、安定性、費用対効果」という不可能な三角形から逃れられないと感じるようになりました。これら三つが同時に成立するのは難しいのです。\n先週末には、この件はほぼ白日の下に晒されました。2026年3月28日から2026年3月29日までの二日間で、ChatGPT関連のチャネルの風控（リスク管理）が明らかに厳しくなり、Claudeも同様でした。以前はなんとか使えていた低価格なトランジットサービスも突然不安定になったり、完全に機能しなくなったりしました。私にとっては、これは低価格APIトランジットモデルの段階的な終焉を告げるものとなりました。\n中継ステーションとは何か まず概念を明確にしましょう。 いわゆるAPI中継ステーションは、本質的にモデルベンダーが公式に提供するサービスではなく、ユーザーと上流のモデルの間にある「転送層」のようなものです。リクエストを中継ステーションに送り、中継ステーションが代わりにOpenAIやAnthropicなどの他のモデルサービスプロバイダーにリクエストを転送し、最後に結果をあなたに返します。 ユーザーの視点から見ると、それはより安価で、より「柔軟な」統一のエントリーポイントのようです。技術的およびビジネスモデルの観点からは、上流のリソースを再パッケージ化し、再配布しているようなものです。 このようなサービスがこれまで利用され続けている理由は非常にシンプルです。\n価格が安い 利用開始のハードルが低い モデルの種類が多い 国内ユーザーにとって、登録、支払い、ネットワーク環境に関する手間を省ける しかし、問題もまさにこの点にあります。これは公式な経路ではないため、多くの利便性は、安定したライセンスに基づいているのではなく、「余分な層を追加している」ことに本質的に基づいています。 彼らは通常どのように機能しますか プラットフォームによってアプローチは異なりますが、一般的なパターンはいくつかの種類に大別されます。\n1. 主要な二次ディストリビューション（再販） 一部のプラットフォームは、本質的に自社のアップストリームAPIキーを統一して転送し、そのクレジットをダウンストリームユーザーに分割して提供しています。購入しているのは、OpenAIやAnthropicが直接販売するプランではなく、彼らが提供する一層目のパッケージです。 このモデルの問題点は、アップストリームのキーが制限されたり、クレジットが上限に達したり、ポリシーが調整されたりすると、ダウンストリームでの体験が即座に不安定になることです。\n2. アカウントプールのローテーション 業界でよく使われる「号池」とは、アカウントリソースをプール化して管理することを指します。プラットフォームが複数のアカウントを集約し、リクエストに応じて順番に呼び出すことで、クォータ（割り当て枠）の負荷や不正検知のリスクを分散させます。 ここでの「号池」は、モデルベンダーの公式な専門用語ではなく、より俗語的で裏話的な表現です。これは製品の機能性そのものよりも、リソースのスケジューリング方法に重点を置いています。どのプールの規模が大きいかによって、短期的に安定しているように見えますが、上流側から一斉にクリーンアップ（監視・制限）が始まると、この安定性はあっという間に失われることがあります。\n3. リバースエンジニアリングによるラッパー化（逆アセンブル） もう一つの手法として、本質的には公開されている標準の公式APIを利用するのではなく、ウェブページやクライアント側のリクエスト方法を調査し、その呼び出しプロセスを「あたかもAPIであるかのように」再構築してユーザーに提供する方法があります。 この「リバース（逆行）」という言葉は、簡単に言えば、公式が用意した入り口から入るのではなく、裏口や窓、さらにはパイプラインなどからシステム間の通信方法を理解し、自分自身でラッパー層を設けるということです。 この手法の弱点も非常に明白です。今日使えるからといって、明日も使えるとは限りません。ページの構造、認証方式、デバイス検証、行動ポリシーなどが少し変わるだけで、エンドツーエンドの処理全体が機能しなくなる可能性があります。\n3月の実体験について この3月度の集中的な体験を経て、私が最も感じたのは「安いから良い」という感覚ではなく、「不確実性を継続的に我慢しなければならない」ということです。\n同じ要求であっても、今日のある中継地点（プロバイダー）ではうまく答えられるのに、明日になると知能が落ち始めることがあります。午前中は安定して出力できるのに、夜になるとエラーが出たり、タイムアウトしたり、コンテキストが失われたりします。自分がモデルの能力を買っていると思いがちですが、実際には多くの場面で絶えず変動する「確率的なサービス」を購入しているにすぎません。\n一時的にモデルを試したり、軽い質疑応答を行うだけであれば、この変動は我慢できます。しかし、それを実際のワークフローに組み込むと、問題が非常に明白になります。\n品質が不安定で、出力レベルが高低差がある 安定性に欠け、タイムアウトやエラー、途切れが発生しやすい コンテキストの連続性が低く、長時間のタスクでの体験が悪い プラットフォームを上流（プロバイダー）に切り替えると、モデルの個性やスタイルが漂流する 同じ時間を費やして問題を調査しても、目に見えないコストは低いわけではない つまり、安価な中継地点の最大の問題点は、「安くない」ということではなく、本来公式プラットフォームが負うべき「確実性」を、ユーザー自身に再転嫁させている点です。\n表面上は費用を節約しているように見えますが、実際には時間、精神力、そしてワークフローの予測可能性というコストを多く払っているのです。\nなぜ私はそれが不可能性の三角形に入り込むと言ったのか 最近繰り返し使ってみて、このような中継サービスは必然的に「不可能性の三角形」に陥ると感じています。\n品質 品質を高く保つためには、実際に利用可能なアップストリームモデルの確保、十分なクレジット枠の確保、そしてできるだけ少ないサンプリングやダウングレードが不可欠です。このこと自体が安くはありません。\n安定性 安定性を高めるためには、より多くのリスク管理、アカウントの損失、ネットワークの変動、レート制限、バックアップ回線などを処理する必要があり、さらにはより複雑なスケジューリングやフォールバック機構を自前で構築する必要があります。これらはすべてコストになります。\nお得な価格設定について 最初の2つのことをしっかりと固めれば、価格をこれ以上低く抑え続けることは不可能になります。長期にわたって超低価格を維持できる場合、それはコストが真に解決されていないだけであり、単に先送りされたか、あるいは将来の何らかの集団的な失敗に分散されていることを示していることがよくあります。 そのため、多くの仲介業者は「高い費用対効果」を実現しているように見えますが、実際には脆い均衡を保っているだけであることが多いです。平穏な時には成立しますが、上流側のリスク管理が厳しくなると、この均衡は容易に崩壊します。\n先週末は、ほぼ明牌だった 私に「もうこれ以上深入りするのはやめよう」と決意させたのは、2026-03-28 から 2026-03-29 のこのローテーションでした。\n私自身の体感では、ChatGPT関連のチャネルがその二日間で非常に顕著な集中絞り込みを見せ、Claude側のリスク管理も同時に強化されていました。以前は、回線を変えたり、モデルを変えたり、プランを変えたりすることで「なんとか使える」状態を保つことができましたが、それが突然通用しなくなりました。\nここでは、「業界全体が完全に死んだ」といった断定的な表現は避けたいと思っています。結局のところ、自分たちにはまだ別のチャネルがあると言う人は必ずいるからです。しかし、一般ユーザーの実用価値という観点から見ると、低価格なAPI中継ルートというのは、少なくとも私がこれ以上時間を費やす価値はないと感じています。\n「安い」ということは、「タスクを安定して完了できる」という前提があって初めて意味を持ちます。基本的な信頼性すら維持できなくなれば、安さというのは単なる錯覚になってしまいます。\nなぜこのパターンは元々脆弱なのか 表面だけを見ると、メーカーが「意図的に利用を制限している」ように感じられるかもしれません。しかし、深く考えてみると、実はこうしたパターン自体が非常に脆い土台の上に成り立っているのです。\nOpenAIやAnthropicといった企業は、そもそも「二次的なグレーな再販」というロジックで製品を設計したわけではありません。公式の利用規約には、APIキーの売買・譲渡、制限の回避、リバースエンジニアリング、保護措置の迂回などについて、明確な制限が設けられています。OpenAIのサービス規約では、「APIキーの売買または譲渡」「レート制限や保護措置の回避」「使用制限の回避」を禁止行為として明記していますし、Anthropicの商用利用規約も、違反利用、不正アクセス、サービス乱用に対する制約空間を明確に留保しています。\n言い換えれば、これらの仲介業者は、公式が推奨するエコシステムの中でイノベーションを起こしているのではなく、公式なガバナンスの隙間を縫って生き延びようとしているだけです。モデル提供元が真剣に清掃（対策）を始めた場合、このパターンは自然と最初に打撃を受ける運命にあります。\nさらに、非常に現実的な背景があります。多くの海外のモデルサービスには、もともと地域、支払い、アカウントシステム上の障壁が存在します。公式がサポートする地域が限られているため、多くのユーザーが門前払いとなり、それが仲介（中継）需要を生み出しています。しかし、需要があるからといって、そのパターンが盤石であるとは限りません。それは単に、「グレーな代替案」に市場があることを示しているだけであり、長期的な確実性を持っているわけではないのです。\n最終的な結論 色々試した結果、今の私の結論はかえってシンプルになりました。 codex の方がコストパフォーマンスが高いと感じています。少なくとも私自身の使用経験からすると、本番環境に導入する用途にはこちらの方が適しています。国内で大規模なアカウント停止のフィードバックをあまり聞かないこと、そして全体的な心理的負担も低い点も理由の一つです。 もちろん、codex に制約がないわけではありません。5時間の制限や週ごとの制限は存在しますし、今使うときには、以前のように無計画に何でも質問したり、すべてを任せきりにしたりすることはなくなりました。多くの問題については、まず頭の中で一度シミュレーションしたり、自分で分解してから、今回のクレジットを使うかどうかを判断するようになりました。 こう考えると、制限というのは必ずしも悪いことばかりではありません。客観的に見て、人間に再び思考プロセスに参加することを強制し、問題を整理させ、判断させ、取捨選択させることを強いるためであり、すべての思考を外部に丸投げすることを防いでくれます。以前も書きましたが、モデルが少し「賢くない」ことは、必ずしも悪いことではなく、むしろ利用者に基本的な思考強度を維持するよう促してくれるからです。今振り返ってみても、この判断は依然として正しいと思います。 Claude は現時点では考慮していません。能力が低いわけではありません。それどころか、非常に強力です。しかし、個人での正規購入であってもアカウント停止の不確実性が残っている以上、今の段階でメインのソリューションとするには適さないと考えています。 国内のモデルについては、引き続き様子を見ることにします。まだ長期的に深くコミットできる段階ではないからです。 そのため、結局は非常に素朴な選択に戻りました。ChatGPT Plus を購入し、とりあえず使いながら、大規模言語モデル業界が今後どのように進化していくのかを見守る、という形です。多くの場面で、一番安いプランが必ずしも一番お金がかからないわけではなく、一番気が楽な（ストレスの少ない）プランこそが真のコストパフォーマンスを秘めているのです。\n参考リンク OpenAI 対応地域：https://help.openai.com/en/articles/5347006-which-countries-and-territories-are-supported-by-openai OpenAI サービス規約：https://openai.com/policies/services-agreement/ Anthropic 商用利用規約：https://www.anthropic.com/legal/commercial-terms ","date":"2026-03-30","language":"ja","permalink":"https://ttf248.life/ja/p/the-end-of-low-cost-api-relays/","tags":["AI霊感衝突坊","ai","大規模モデル","api","chatgpt","claude","codex"],"title":"低価格API中継地点の終着点：3月の大規模言語モデル体験と不可能性の三角形","year":"2026"},{"categories":["コンピューター"],"content":"近年のプロジェクトにおいて、AIプログラミングが非常に多く用いられ、これは過去3年間にわたる最もAIの活用度が高かったプロジェクトである。記録したメモは体系化されておらず、思いついたことをそのまま書き留めている状態だった。\n背景 Linux環境、バックエンドサービス開発、UI開発などのフロントエンドコンテンツは含まれません。\nモデル 国内のminimax、glm、kimiの三巨頭も上手試してきたが、kimiの効果が一番良い。claudeは大規模な要求に対して効果的に分解し、codexは生産環境に最適で、非常に慎重だ。\nClaudeは最も汎用性の高い選手で、現在プログラミング競技会では誰も打ち負かすことができない。ただ高価である。 Minimaxはコストパフォーマンスが最高で、速度も十分速く安定している – エビの波潮の下で利益を得た者。 Codexは大抵良いのだが、いくつかのタスクでは指示に従う度合いが低く、常に私の性能を最適化しようとして、実際には私が必要としていないのに、ユニットテスト時は冗長な回答をして直観的に事例を理解できるようにしたい – 私はそれを望んでいる。 Kimiは指定された指示に従う度合いが非常に高く、国内で一番使いやすいモデル。 GLMは休前はまともだったが、休後には計算リソースが深刻に不足し、廃止となった。 認識 AI の脳容量は個人を遥かに超え、一部のモジュールの設計において、AI とのプランニング議論を行うことで、思考連鎖を効果的に拡張し、より合理的な設計ソリューションを見出すことができます。\n高度な指導者、能力のあるアシスタント。\n位置（ポジショニング） わからないことがあれば彼に聞いてください。明確な開発タスクを提示して実行させることができ、あなたをサポートする優秀な部下がいるようなものです。\n問題 帰国後の国内のモデルで、春節（旧正月）を期して戻ってきた後、大規模な計算リソース不足が発生し、出力が非常に遅くなりました。確かに価格性能比は優れていましたが、出力速度が遅いため、実際の業務においてインタラクションの効率に大きな影響を与えます。智譜（Zhipu AI）も春節中にトラブルを引き起こし、開発者を裏切る行為と、プラン料金を乱に変更しました。最終的に事態が拡大し、大晦日の五日に謝罪文を発表し、内部プロセスも混乱していました。私の払い戻し申請後、帰国後に過去のプラン全体をすべて払い戻してくれました。当初は、アップグレード分のみ払い戻しと、旧プランの権利を維持するという公告が出ていました。\n周限額（Weekly Limit）については、最初の智譜には存在しませんでしたが、現在は購入時に設定されています。これはプラットフォームがユーザーの「羊毛抜擢」（薅羊毛 -薅 sheep）能力を見下評価していたためです。全額払い戻しにより、私も「羊毛抜擢」ができなくなってしまいました。glm-4.7は、kimi-2.5とほぼ同じレベルの性能を持ち、指示に従う度合いも十分です。\nいずれのモデルも、現在では人工による審査が必要です。\nユニットテスト プロジェクト設計初期において、各モジュールの設計は独立したユニットテストが可能な状態で行われる。開発後期に、大規模モデルが自ら生成したコードに対して、自身でユニットテストケースを作成し、ほとんどのシナリオがすべてパスしてしまうことがあった。これはテスト駆動開発（TDD）のアプローチではないため、ユニットテストの役割は、その後のビジネスイテレーションやリファクタリングフェーズにおいて、AIによる修正コードが元の機能を破壊していないかを検証するために活用される。\nパフォーマンステスト AI が一部のコア関数に対して最適化されていない場合、おそらくパフォーマンステストを行う手間を省いてしまうでしょう。しかし、AI があると、データを確認して合わせてテストレポートを作成するのも手軽になります。\nドキュメント ドキュメントのメンテナンスは大変な作業ですが、AIは違います。彼は修正したコードと同時に、ドキュメントのメンテナンスを支援し、関連するドキュメントを最新のコードブランチに同期できます。\n新能分析 Codex を使ってサービスの性能最適化を試みたところ、権限付与後に自動的に perf で性能分析を実行できるようになった。しかし、十分賢くはなく、頻繁なメモリ申請が効率低下の原因であると分析したが、それがループの回数が多すぎるために発生していることや、コード上の不合理性（ループ内部で大量のオブジェクトを生成・破棄する）を理解できなかった。\nプロセス AIプロジェクトの保守において、人的介入を行い、モジュールや関数に基づいて反復開発を行います。AIが継続的に新機能のメンテナンスを期待することはなく、毎回プロンプトを作成する際には、まるで小さな開発計画を記述しているかのように、どのモジュールに関わるのか、どこで修正するのが最適かを検討します。 インターネット上で流布している多くのプロセスは、私のもとでは試されておらず、プロセス自体が比較的伝統的であり、実際に使用しても最も直感的です。\n","date":"2026-03-16","language":"ja","permalink":"https://ttf248.life/ja/p/a-long-period-of-deep-ai-programming/","tags":["ai","プログラミング","プロセス","規範 (Koubou)"],"title":"重度のAIプログラミングの数年間の日々","year":"2026"},{"categories":["コンピューター"],"content":"本記事では、C++開発における unordered_map::find がヒットした後にオブジェクトフィールドが一致しないという奇妙な現象を分析しています。原因は、関数内部で static lambda を定義し、参照キャプチャによってローカル変数を捕捉することです。これにより、最初の呼び出し後には幽霊参照が発生し、その後の呼び出しで未定義動作（UB）を引き起こし、キャッシュデータを汚染します。この問題を解決するには、明示的なパラメータの渡しを介して暗黙のキャプチャを置き換え、ライフサイクルの管理を標準化し、Sanitizerツールを使用することを推奨します。\n高性能な行情サービスや分散型キャッシュを構築する際に、プログラマーはしばしば「異変」に遭遇します。それは、Keyを使用して std::unordered_map からオブジェクトを明確に見つけ出すにもかかわらず、その内部フィールドを読み取ると、別のKeyのデータになっているという現象です。この「身分誤認」は、隠れたC++の罠を指しています：**static lambdaとライフサイクルキャプチャの競合による未定義動作（UB）**です。\n故障パターン：「長久保存」の短寿命引用 パフォーマンスを最適化する際、一部の開発者は関数内で static lambda を定義してクロージャー作成のオーバーヘッドを削減することがあります。しかし、暗黙的なキャプチャによる参照捕獲 [\u0026amp;] と組み合わせると、爆発的な問題が発生します：\nvoid UpdateCache(std::unordered_map\u0026lt;std::string, Tick\u0026gt;\u0026amp; cache, Tick\u0026amp; current_input) { // 危険：static は lambda のライフサイクルをプロセスレベルまで延長する // [\u0026amp;] はスタック上のローカル参照 current_input をキャプチャする static auto patch_func = [\u0026amp;](auto it) { it-\u0026gt;second.price = current_input.price; // 2回目実行時、この参照は無効になっている }; auto it = cache.find(current_input.symbol); if (it != cache.end()) { patch_func(it); } } 技術原理の剖析 ライフサイクルズのずれ: static 変数はプログラムがその行に到達した際に初期化され、プロセス全体で一度だけ実行されます。つまり、patch_func 内でキャプチャされた current_input の参照は、最初の呼び出し時にスタックフレーム上のメモリのアドレスに固定されます。 幽霊参照 (Dangling Reference): 最初の UpdateCache が完了すると、元のスタックフレームが破棄されます。その結果、patch_func はすでに無効になったアドレスを読み書きしようとします。 隠れたメモリ汚染: スタック空間は繰り返し使用されるため、そのアドレスには新しいビジネスデータが格納されている可能性があります。この場合、データを書き込むことで、現在の Key の Value を更新しているように見えますが、実際には「ランダム」なメモリ領域で不正な書き込み操作が行われています。これが、find の Key が A であり、読み取った Value フィールドが B である理由を説明しています。 ソリューションとエンジニアリングプラクティス 1. 隐式捕获消除，改用显式参数传递 最稳妥的方法是让 Lambda 保持“无状态”（Stateless），将所有依赖的对象通过参数传递。\n// 推荐做法：无状态 lambda，显式传递 src auto patch = [\u0026amp;](auto it, const Tick\u0026amp; src) { it-\u0026gt;second.price = src.price; }; patch(it, current_input); 2. 静的修飾閉包の慎重な使用 関数内部で、閉包がローカル変数をキャプチャしていない限り、static を使用しない方が良いです。現代のコンパイラは非 static lambda の最適化に非常に優れており、盲目的に static を使用しても得られるパフォーマンス向上はほとんど無視できる程度でありながら、大きな安全リスクをもたらします。\n3. 強化学制と動的検出 主張チェック: 更新ロジック後に、assert(it-\u0026gt;first == it-\u0026gt;second.symbol)を追加し、開発段階で「同一性不一致」の問題を捕捉します。 ツール支援: テスト環境で ASan (AddressSanitizer) と UBSan (UndefinedBehaviorSanitizer) を有効にします。これらのツールは、無効なスタックメモリへのアクセスを正確に検出し、直ちにエラーを報告します。 結論 C++ における「テーブル参照エラー」はしばしば表象に過ぎず、その裏にある真相はメモリ管理契約の違反である。キー検索が正しくても、値が信頼できるとは限らない。特に、静的変数、グローバル変数、長寿命なコールバック関数などの長寿命オブジェクトを扱う際には、それらが捕捉している参照がスタックフレームの破棄によって失われていないか常に注意する必要がある。\n","date":"2026-03-16","language":"ja","permalink":"https://ttf248.life/ja/p/deep-dive-into-memory-corruption-and-cache-pollution-caused-by-static-lambdas-in-c/","tags":["AI霊感衝突坊","c++","トラブルシューティング","lambda"],"title":"深層解析：C++ における `static lambda` が引き起こすメモリリークとキャッシュ汚染","year":"2026"},{"categories":["投資 (tōshi)"],"content":"ポジションバイタル（ポジティブな姿勢）： 持続的に株式を保有し、仏教的な視点で観察し続け、エコシステムのプレミアムの実現を見守る。\n一、市場概況：2025年の「狂騒」から2026年の「変動」へ 2025年は香港株にとって大きな年となり、恒生テクノロジー指数は年間で23.45%の大幅な上昇を記録し、設立以来最高値を更新しました。しかし、2026年初に入ると、市場は明確な「二回の押し上げ、一次の反落」というパターンを示し始めました。\n小米は去年の11月に40港元ラインを確立し、主に第3四半期の予想を上回る業績と、雷さんと会社の積極的な自社株買いによるものでした。しかし最近では株価が一定幅で下落しており、現在は35-38港元間で変動しています。市場は主に以下の2つの要因を消化しています：SU7の改造型期間中の真空期およびハイエンドUltraモデルの販売実績の透支。\n二、 小米近年の変動：SU7 Ultraの「曲高和寡」とYU7の「頂梁柱」 製品ラインの青黄不接: 近期データによると、小米SU7 Ultraは2025年12月の販売量が小数（45台）に落ち込みました。これは超跑レベルのモデル（50万ドル以上）がブランドの象徴であり、販売基盤ではないことを示しています。 SU7改款の圧力: 現在のSU7は改款移行期にあり、次世代は4月に登場予定です。「新老交替」により1月の納車量が前月比で約22%減少し、株価もそれに伴い圧力を受けました。 YU7のエコシステムプレミアム: thankfully、SUVモデルのYU7（小米の第二台車）は非常に安定したパフォーマンスを示し、数か月連続で大型SUV販売ランキングのトップに君臨しています。これは私が以前メモの中で言及した「エコシステムプレミアム」を裏付けています。つまり、米粉が家庭用SUVに対して純粋な高性能セダンよりも高い変換率を示すということです。 買い戻しの「床価」によるサポート: 小米は最近420万株を買い戻し、投資額は1億5千万元です。「需要に応じた株価上昇」という買い戻し戦略により、株価には心理的な「左側安全圏」が設定されました。 III. 横向比較：新能源自動車セクターの「集団的な冷却」 比較すると、小米が1月に3.9万台納車した実績は、業界の衰退期（1月は通常淡季）において決して悪くありません。\n比亚迪 (BYD): 1月の新能源車販売台数21万台で、前年同期間比/前月比の両方で約30%の落ち込みが見られました。 蔚来汽车 (NIO): 同様に納車における変動に直面しており、特に純粋電気セダン市場においては、競争が激しすぎるため、価格下落を通じてシェアを維持しようとする動きが見られます。 比較結論: 小米の変動はより「内生的」な製品リズム調整であり、根本的な崩壊ではありません。他の自動車メーカーが価格戦に頼るのに対し、小米はスマートフォン+自動車+家電の「人車家全エコシステム」という強固な基盤を活かし、株価下落の深さは純粋な自動車企業標的と比較して明らかに浅いものです。 四、 縦軸比較：恒生科技指数（HSTECH） 指数走勢: 1月の恒生科技指数は3.67%上昇し、全体的に価格の中枢が上昇傾向にある。 小米 vs 指数: 近2週間の小米は大盤にやや遅れを取っている。その原因は、モ根大通などの大手証券会社が目標株価を引き下げたこと（38港元まで）であり、核心的な論理は、スマートフォン事業の粗利率が回復するまでに時間がかかることを懸念している点にある。 戦略反省: 去年の11月に私が書いたように、香港株式市場の流動性は命門である。大盤が全体的に上昇するとき、小米は白馬株として売り戻しを受けてしまうが、大盤が調整するときは、その買い戻しとキャッシュフローが最高の防御壁となる。 まとめと今後の取引戦略：「四月風光」を待つ 持ち玉戦略： 2026年の販売目標が55万辆（雷総が先日発表）に設定されているため、現在の調整は「鈍刀子割肉」（鈍い刃で肉を切る）のような陰的な下落であり、短期投機客を洗い流している。 注目点： 4月に登場するSU7の価格とグレード、およびYU7が継続的に後継車となるか。 取引戦略： 現状では操作はせず、静観（躺平）する。この水準（35～38区间）で売却する必要はない。買い増しはまだ私の心の「絶対安全垫」に達していない。 ","date":"2026-02-06","language":"ja","permalink":"https://ttf248.life/ja/p/xiaomis-new-and-old-replacement-and-defensive-battle-with-the-electric-vehicle-sector/","tags":["AI霊感衝突坊","小米 (Xiǎomǐ)","恒生指数 (こうせいしじょ)","新エネルギー自動車","投資 (tōshi)","SU7","恆生テクノロジー指数 (こうせい テクノロジー しすい)","製品ライフサイクル"],"title":"小ミの「新老交替」と、電車板の防守戦","year":"2026"},{"categories":["コンピューター"],"content":"インターネットシステムにおける負荷テストにおいて、しばしば対照的なスタイルを持つ2つのツールに遭遇します。1つは極めて軽量で、最大限の帯域幅を追求するwrkであり、もう1つは機能が豊富で、実際のビジネスフローをシミュレートするJMeterです。\n提示：コアなアイデアを整理し、科普記事を作成：HTTP 負荷テストツール、wrk vs Jmeter の違いについて、私が知っていること、wrk は 1 つの スレッドで複数の接続を行うテストに偏っており、Jmeter はより短接続モードに重点を置いており、設定によって長接続モードにも調整可能です。\nコアアーキテクチャ：マルチスレッド vs イベント駆動 これは両者のパフォーマンス差の根本的な原因です。\n1. JMeter: 伝統的な「一人一岗」制 (Thread-per-Request) JMeter は Java で開発されており、古典的な マルチスレッドモデル を採用しています。\nロジック: 各コンカレントユーザー（Virtual User）は、JVM 内の物理的なスレッドに対応します。 コスト: スレッドは非常に高価なリソースです。同時数があっという間に数千に達すると、コンテキストスイッチング (Context Switch) とメモリ消費がテストマシン自体を著しく遅延させ、「ロードマシンがサーバーを押し倒す前に、自分自身が崩壊する」といった現象を引き起こします。 2. wrk：現代的な「多面手」制 (イベント駆動型) wrk は C 言語で記述されており、コアとなるロジックは Redis と同じ ae イベントループフレームワークを利用しています（epoll/kqueue を使用）。\nロジック: wrk は各接続ごとにスレッドを作成しません。代わりに、極少数のスレッド (通常は CPU コア数に相当) のみ起動し、それぞれのスレッド内部でノンブロッキング I/O を通じて成千もの接続を同時に管理します。 利点: これが「一つのスレッドで複数の接続」という表現です。スレッド切り替えのオーバーヘッドを大幅に削減し、単一マシンで百万レベルの RPS (リクエスト毎秒) を実現できます。 连接モデル：短接続と長接続 ご指摘の接続パターンについて、より詳細な情報をご提供します。\n1. JMeter の「重」と「軽」 JMeter はデフォルトで、実際のユーザーの行動をシミュレートする傾向があります。\n短接続への偏り： デフォルト設定では、JMeter の古いバージョンや特定の構成によっては、積極的に接続を再利用せず、多数の TCP 握手が発生することがあります。 調整可能性： 「KeepAlive」を HTTP Request 中にチェックボックスで選択するか、user.properties ファイルで接続プールパラメータを調整することで、長接続を有効化できます。しかし、たとえ長接続を有効化したとしても、スレッドモデルの制限により、数十万レベルの同時長接続を維持することは困難です。 2. wrk の「快」と「狠」 wrk が設計されたのは、HTTP Keep-Alive の性能をテストするためです。\n長接続戦略： wrk はテスト開始時に指定した接続数を確立（-c オプションを使用）し、テスト中に可能な限りこれらの接続を再利用します。 適用場面： Nginx やゲートウェイ（Gateway）、高負荷 API が極端な長接続ストレス下でスループットの限界をテストするのに非常に適しています。 比較表 特性 wrk Apache JMeter 開発言語 C/Lua (スクリプト) Java (GUI) 比較表 特性 wrk Apache JMeter 並行モデル イベント駆動 (epoll/kqueue) マルチスレッド (ユーザーあたりスレッド) 比較表 特性 wrk Apache JMeter リソース消費 極低、単機スループット巨大 比較的高い、大規模同時接続には分散クラスタが必要 比較表 特性 wrk Apache JMeter ビジネス複雑度 低い。主に単一URLに焦点を当てている 極めて高い。複数ステップスクリプト、アサーション、エクストラクターをサポート 比較表 特性 wrk Apache JMeter テストシナリオ 静的API負荷テスト、容量評価 複雑なビジネス連携の負荷テスト、機能回帰テスト 深層比較表 特性 wrk Apache JMeter レポート機能 テキストのみの要約 非常に豊富、各種グラフやHTMLレポートをサポート まとめ：どちらを選ぶべきか？ これらのツールは代替関係ではなく、補完関係にある：\n選ぶワーク サーバーの最大スループット (RPS) をテストしたい。 テスト対象は単一の API または静的リソース。 最小限のテストサーバーで最大のトラフィックを発生させたい。 Lua スクリプトを使ってリクエストをカスタマイズする経験がある。 JMeter を選択する 複雑なビジネスフロー（例：ログイン → 商品検索 → 購入 → 決済）をシミュレートする必要がある。 レスポンスタイム分布、エラー率などの詳細な指標を観察するための可視化されたインターフェースが必要である。 テストでは動的パラメータ（例：前のインタフェースから取得したトークンを次のインタフェースに渡す）を処理する必要がある。 チームはコマンドラインよりもグラフィカルツールに慣れている。 ","date":"2025-12-19","language":"ja","permalink":"https://ttf248.life/ja/p/wrk-vs-jmeter-deep-benchmarking/","tags":["AI霊感衝突坊","jmeter","負荷テスト (Yōki tesuto)","wrk"],"title":"wrk と JMeter の負荷テスト (または パフォーマンス測定)","year":"2025"},{"categories":["メモ書き雑感"],"content":"アリペイで投資に慣れてきたのに、個人年金もワンストップで済ませようとしたんですが、全額は大盤指数に回していました。やっとカスタマーサービスに付き合ってアカウントの連携を終わらせたものの、結果的に目を白黒させられました。アリペイの中にはただの残高しか表示されておらず、以前購入した投資信託の詳細情報は一切見れません。このデータ同期は一体どれほど手抜きなんでしょうか？もしかしたらバグを発見したのでしょうか？\n胡乱分析 支付宝と招行の連携が十分に進んでおらず、データ同期の問題が発生している。 銀行は意図的に支付宝にデータを与えない。 支付宝との連携担当者が業務に慣れておらず、発生した問題の状況を悪化させている。 真実 分析しても何も分からず、カスタマーサービスも私の問題を理解できず、「後で返信します」とだけ言われた。カリには少し余裕のあるお金があったので、基金がどれくらい適しているか調べてみたらしようと思い、比較検討してみた。銀行側の営業費用と支付宝の費用が同じかどうかを確認した。 基金の費用は主に取引費用（申购手数料と解約手数料を含み、売買時に直接差し引かれる）と保有費用（管理費、托管費、販売サービス料を含み、日々基金純資産から自動的に差し引かれる）の2つで構成される。一方、代行プラットフォーム（支付宝のような）は仲介機関として、主に申购手数料の分収、Cクラス基金の販売サービス料、そして基金会社から管理費に応じて按比例返還される「顧客維持費」（通称尾随佣金）によって収入を得ている。そのため、個人年金といった普恵的な性質を持つ商品では、管理費が半額になり、申购手数料がかからないことから、代行プラットフォームの実際の分収は比較的低い。 色々調べてみても、華夏基金の費用が最も低かった。参考になる過去の記事：国内超大型ETF批量降费了 すると脳が回る。招商で買った基金は、支付宝ではなく銀行のチャネルで購入したのだ。支付宝はそれに見合った利益を得ていないので、私にそのデータを見せてくれない。 この一瞬のうちに浮かんだ「真実」は、商業ロジックを揶揄しているように聞こえるかもしれないが、実は金融データの同期という現実を歪んで示している：「誰が販売するか、誰が管理するか、誰がサービスするか」。 金融システムの基層にある論理では、代行プラットフォーム間の口座体系は完全に接続されていない。たとえあなたが支付宝で招商の個人年金資金口座と連携させても、支付宝はより「決済と情報検索ポータル」であり、「資産管理者」ではない。招行Appで申告した基金は、対応する取引確認書と保有状況の詳細記録が招行的代行システムに保存されており、支付宝にはこれらのプライバシーの保有明細を直接跨行呼び出す権限がない。つまり、これは「儲からないから見せてくれない」という問題だけでなく、コンプライアンスとデータ所有権の問題によって生じる技術的な隔たりである。\n予想外の比較 客服が電話に繋がるまでの間、両社の料金体系を比較してみると、以前の理論が証明されました：\n料金の一致性: 個人年金専用のYクラス份额は確かに「割引スター」です。中国銀（招商銀行）と支付宝の両方で、その管理手数料と托管手数料は、元のA/Cクラス份额を基に50%オフであり、成約手数料はほぼ0%手数料または10%手数料です。 チャネルの違い: 料金は一致していますが、両社の「体感」は全く異なります。銀行は自社の理財や深耕した保険の提案に傾倒しており、一方、支付宝のインターフェースはビッグデータの指数推奨に偏っています。 結論 支付宝のような滑らかなポートフォリオ分析、損益曲線グラフを楽しむ唯一の方法は、「どこで買うか、どこで見るか」であるようだ。究極の一本勝負の体験を求めるのであれば、以前のポートフォリオを売却（手数料がかからない場合）して、支付宝内で直接再投資することも考えられるだろう。\nあれこれ悩んだ末に気づいたこと： 金融ソフトの「相互運用性」への道はまだ遠いようだ。互いに譲らないこれらのソフトなのであれば、私はもっと手間をかけて、左手で招商銀行で見守る老資金、右手で支付宝に新規投資するしかない。結局のところ、手数料の差よりも、自分の財布の中身を守ることが最も重要だからだ。\n","date":"2025-12-18","language":"ja","permalink":"https://ttf248.life/ja/p/the-considerations-surrounding-alipays-personal-pension-binding/","tags":["アリペイ (Ālipèi)","個人年金","プラットフォーム","利益 (Rieai)"],"title":"アリペイ（支付宝）の個人年金との連携に関する考察 (Aripei (ZhiFoo) no kojin nenkin to no rienkai ni kansuru kousatsu)","year":"2025"},{"categories":["転載 (tenzai)"],"content":"個人補足：層層包裹的理财产品，普通投资者看不透的底层资产；背后的人知道不坑穷人，坑穷人，真和你拼命，坑中产，他大概率认栽。\n2025年末了，浙江大批投资者还在因为理财暴雷而堵门维权的事情上演，这个事情之所以在金融投资领域热度较高，大概能找到几个关键词：国资背景、较低收益、公务员/教师为投资主体（20万起购，验资40万）等等，事实证明，任何金融工具不管设计的有多精妙，背书有多强，哪些群体在买，都有演化成旁氏的风险。如果只看到上面这几个关键词，说明对于这个事情的全貌还原还是太浅了，这个暴雷产品真正值得深挖的地方多着呢。\n自己を自己破産させ、担保として手形を提出して融資を受ける 可控資源系の企業による融資、担保、発行プラットフォームは相互に関連しており、理解するとすれば、自分自身を自己破産させる行為であり、制御された国営資本の背景を持つ金融プラットフォームを通じて、売掛金債権を担保にして市場で融資を受け、増資も自分自身のものである。唯一の目的は、外部から新鮮な血液を得ることである。「球証、旁証に加えて主办、协办すべての機関がすべて私の人間だ。どうして私と争うんだ？」という言葉が非常に適切である。\n投資家に提示されるAA+の市場信用格付けは、一般の人々には経済体の国債よりも高いように見えるかもしれないが、実際に比較すると、恒大や碧桂園が暴雷する前はAAA級の評価に匹敵し、金印としての価値がある。深鉄の輸血を停止した後、小作文で生き延びた万科も、今年中国国内の信用格付け機関によって依然としてAAA級の高評価を得ている。真に資金を実行に移し、信用をほとんど気にかけないのだ。\nこのような異常な商品が、無数の障壁を乗り越え、高い信用格付けを獲得しながら成功裏に投資家に発行されることは、発行機関は愚か者なのか？　そうではない。この時点で二重の利益分配が行われるのである。\n極めて高い仲介コスト 金融分野で不自然な取引が起こる場合、草台班子（空売り）の裏には必ず真の利益分配の関係が存在します。投資家に対する収益はわずか4%に過ぎませんが、発行側の総合的な資金調達コストは8～9%にも達し、中間4～5%程度の仲介手数料は、発行の中枢各段階における利益分配です。これは極めて誇張されたものです。\nこれが金融体系の内在的な不安定性の基本特徴であり、利益面前にはビジネス能力を問うことはありません。投資家の金銭にみんなで分配していくのです。\nこれは投資家が低金利の根源と見なし、2023年および2024年の無リスク収益が約2.5%という状況下で、リスクプレミアムが1.5%程度であり、国資背景を考慮すると、底流資産や株式構造を調査することなく、これは高リスク資産とは言えません。むしろ、投資家に対する低収益が、騙される側の抜け道となる主な原因です。なぜなら、6%、8%、10%の収益とリスクの対応関係は、過去数年間の集中暴雷の後、人々はハイリターン投資に警戒心を抱くようになったからです。まさに理想的な状況です。低収益は低リスクではなく、中間段階の仲介手数料が極めて高いことによるものです。\n真の企業端にとって、8～9%を融資コストとして出すことは、過去の大環境では大善人ではありません。純粋に投資家の元本を守るためなのです。\nこのようなリスクは外見上の人たちには理解しづらいですが、国資股东もそうでしょうか？これらの人の利害回避能力を見下すことはできません。もし暴雷が発生したらどうなるでしょうか？もちろん、暴雷前に静かに退出します。\n国資の金蝉脱壳 これは３番目の奇跡的な点です。株式譲渡は全て秘密裏に行われ、投資家に対して十分なリスク開示や通知が行われていません。購入時には国営企業による保証でしたが、満期に近づくと民営企業へと変わってしまうのです。結果として、大家が見るのは、明確化声明と、関係を強く否定する声明だけであり、投資家は混乱し、既に資金が底をついた殼（かぶら）しか見当たらず、責任者も見つかりません。\n以前は浙江金融資産取引センターと呼ばれ、金交所としての属性を持っていました。しかし、去年の11月に発表された一紙の文書で金融許可が取り消され、今年になって浙江浙金資産運用股份有限公司に改名されました。そして、公式な保証なしの普通の投資機関として真正に機能するようになったのです。新規のリッチ・プラマイ（理財）商品を発行することはできませんが、前の商品の満期保証を担い、早めにEXIT（退出）戦略を立てることは、まさに金蝉脱壳を巧みに利用していると言えます。投資家は、国営企業による保証という罠に嵌められてしまったのです。\n房地产下行周期とリスクの波及 資産運用、あるいは不動産リスクの波及の問題について、我が国金融システム（銀行を含む）は、過去10年間で不動産から利益を得ることが非常に容易でした。10%の資金コストをかけても利益が出せるほど過熱したサイクルであり、プロジェクトを獲得し、迅速な売上回転を実現すれば、不動産企業（デベロッパー）は資金コストにほとんど気付かずにいました。しかし、不動産下行周期においては、不動産企業が破綻することが日常化し、真の危険は、自分が購入した資産運用商品の中にどれだけの不動産関連投資が含まれているのか全く分からないという点です。これは「東屋を壊して西屋を修理する」に似ており、最終的には破綻につながります。\n例えば、購入者の直接的な破綻、高純資産層の信託破綻、そしてこれらの不動産投資に関連した自己発行のリッチ（理財）商品が、近年では、不動産投資関連の資産が直接違約するだけでなく、債務を抱えながら債権を維持する形で「傍氏（旁氏）」と呼ばれる状態に陥り、流動性が枯渇した後も破綻し続けるという現象が見られます。これは誰が最後の鼓吹役となるのかによって決まります。例えば、浙金中心が発行した主要な商品は、ほぼすべて祥源グループ自身の不動産プロジェクトであり、2023年以降の割合は90%以上に達しています。あるいは、関連企業間の債務往来も同様です。核心的な問題は、住宅の売れ行きが悪化し、新しい血流が入り込まないことです。このような資産は最初の破綻者ではありませんし、最終的に破綻する可能性も低いとは言えません。\n国资背景が陥る原因について さらに掘り下げていくと、浙金中心（ぜっきんちゅうせん）の裏に位置する理財商品が、特定の富裕層グループを精選し、つまり会員限定で展開され、余剰資金が20万～40万以上にも及ぶ理由、この巧妙な仕組みは一体何なのか。こうした富裕層グループが、地方の公務員や教師といった中流階級グループと高度に重なること、国資の背書を騙して体制内での取引や中国人同士の取引も問題ないと考えていたような滑稽さは、ある地方金交所が祥源集団の融資ツールとなる仕組み、恒大と盛京銀行のような唐突な状況を生み出すこと、さらには深く掘り下げる必要がある。\nこれは2018年の華信グループ（かしんグループ）の違約に遡るべきであり、これは別の規模で大きな金融事件であった。暴雷した製品の規模は千億元を超えるにも関わらず、我々が金融体系が後進的であることは事実だが、このような金融イノベーションと「お金儲け」能力を持つ者は決して少ない。もちろん、我々は現在の浙金中心に関連する37億元の違約に焦点を当てているが、この責任は簡単に転嫁できないだろう。それは、ほぼ純粋な国資主導であり、今回のリスク損失により、浙金グループは高利回り資産と資金補填を急ぐことになり、それが祥源系との重要な関連性を生み出したのだ。毕竟、現在の不動産市場の熱狂を理由に、当時の浙金中心が資金雄厚な不動産企業経営陣によって投資されたことを否定できないだろう。なぜなら、当時の不動産企業はまさに「金鉱」であり、誰もが関わりたかったからだ。\n例えば、深鉄グループ（しんてつグループ）が万科（ワンカ）に600億元投資したケースは、他の人がお金を投資してこのラインに乗る必要があるのに対し、2018年の不動産過熱期はピークを迎えており、浙金中心は無償で資金を集め、2019年には不動産企業による株式持ち比率を通じて12亿元注入された。悪魔と取引し、将来的な失墜を伏線として埋めた。問題が発生した際に、より大きな蓋をかけるのは、失控の第一歩であり、37億元の違約、不動産企業との投資、そして当時の高利回りプロジェクトを追求することで、浙金中心は徐々に深淵へと引き込まれていった。裁判官のレベルも見ていて面白いだろうが、すでに金蝉脱壳しており、浙金という旗印の下で活動しているのも昨年11月に廃止されたため、関係ない。文章の冒頭と完璧な閉環を形成している。訴訟を起こしたいなら、待つがいい！\n最後に付け加えるならば、市場の収益は常に一定ではない。過去の平均収益を現在のリスク評価の基準として利用することはできない。例えば、専門家の欄の前幾年の無リスク収益率は3%程度であったが、現在は1.5%に過ぎない。そして、将来の判断はさらに複雑になるだろう。低収益が必ずしも低リスクを意味するとは限らない。この暴雷した製品のような包装のように、表面的なリスクと本質のリスクを混同してしまうのだ。普通の人+投資という言葉の組み合わせは、このような周期において、収益に注目するよりもリスクと元本に注目すべきである。絶対に「スキャルピング（短期売買）」をしないこと。底堅い資産に注目し、真実の信用背書を確認し、分散投資を行うこと。体制内にあるというだけで、より早い情報や安定した返済の裏付けがあるとは限らないことを忘れず、基本的な生活と将来の必要経費のための資金を確保し、低リスク・低収益またはほぼ無リスクの場所で、損することなく利益を得ることを目指すべきである。\n","date":"2025-12-18","language":"ja","permalink":"https://ttf248.life/ja/p/zhejiang-jin-investment-fraud-a-poor-scam-and-out-of-control-zhejiang-jin/","tags":["金融","国有企業","ファイナンシャルプランニング (Fainansharu Puranningu)","落雷"],"title":"浙江金信理财爆雷 - 拙劣な詐欺と制御不能の浙江金 (Zhejiang Jinxin Wealth Fraud – Poor Scam and Uncontrolled Zhejiang Jin)","year":"2025"},{"categories":["コンピューター"],"content":"背景説明、騰訊のCNBプラットフォームは微信ログインのみをサポートしており、通常のメールアカウント方式は提供されていません。その結果、グループ内で毎日何人かがあれこれ文句を言っていますし、見ていて本当に困ります。騰訊のプロダクトマネージャーが妥協案としてパスキーログインを導入しました。\n毎日、私たちは危険な行為を繰り返しています：パスワードを入力することです。複雑なルール（大文字、小文字、特殊記号、数字）があっても、データ漏洩、フィッシング詐欺、そして「パスワードを忘れてしまった」という悩みが誰一人として解消されません。\nテクノロジー大手（Apple, Google, Microsoft）とFIDOアライアンスが最終的な解決策を提供しました：**パスキー（通行鍵）**です。それは単にパスワードの「代替」ではなく、完全にパスワードを「消滅」させるものです。\nログインプロセスは、パスワードの検証から、現在使用しているデバイスの信頼性を検証することへと変更されました。\nパスキーの仕組みの詳細、管理における利用方法、関連情報を整理し、インターネット公開用の記事を作成\nパスキーとは？ 簡単に言うと、パスキーはデバイスに保存されているデジタル証明書です。 従来の「ユーザー名 + パスワード」の代わりになります。Passkeyに対応しているウェブサイト（Google、GitHub、Adobeなど）にログインする際、文字を入力する必要がなく、顔認証（Face ID）、指紋（Touch ID）、またはデバイスPINコードで確認するだけで、瞬時にログインできます。\n主な違い： パスワードは覚えている文字列（盗まれたり、推測されたり、忘れたりしやすい）であり、パスキーは所有している資産（暗号化された鍵がデバイスのハードウェアに保存されている）です。\nパスキーの仕組み：非対称暗号化 パスキーの裏側には、WebAuthn 標準と FIDO2 プロトコルがあります。理解するためには、公開鍵暗号 (Public Key Cryptography) について知っておく必要があります。\nパスキーを「鍵」と「錠」のペアだと想像してみてください：\n秘密鍵 (Private Key)：\nどこに保存されますか？ 自分のデバイス（iPhone のセキュアエンクレーブ、PC の TPM モジュール、パスワードマネージャーなど）に安全に保存されます。 特性： 極めて機密性が高く、絶対にサーバーに送信されず、デバイスから離れることもありません。 役割： それはあなたの「電子署名ペン」です。 公開鍵 (Public Key)：\nどこに保存されますか？ ウェブサイト/アプリのサーバーにアップロードされ、保存されます。 特性： 公開されており、機密性はありません。 役割： それはあなたの署名を検証する「現行機」です。 ログイン手順の詳細（ハンドシェイク） Passkey を使用してログインする際、巧妙な「チャレンジ-レスポンス」メカニズムが実行されます。\nログインの開始: あなたが「ログイン」をクリックすると、ウェブサイトサーバーはあなたのデバイスにランダムな数学の問題 (Challenge) を送信します。 ローカルでの検証: 携帯電話/コンピューターにプロンプトが表示され、生体認証（顔認証/指紋）でロック解除を求められます。 注記: このステップは単にデバイスが秘密鍵を使用することを許可するものであり、生体情報はアップロードされません。 デジタル署名: ロック解除が成功すると、デバイスは秘密鍵を使用してその数学の問題に「署名」を行い、署名結果をサーバーに送信します。 サーバーでの検証: サーバーは、あなたが以前に保存した公開鍵を使用してこの署名を検証します。署名が有効であれば、サーバーは「検証済みのユーザーが秘密鍵を持っていることを確認」し、ログインを許可します。 パスキーがなぜパスワードよりも安全なのか？ パスキーは、従来のパスワードが抱える3つの主要な問題点（死すべき問題）を解決します：\n完全な免疫「フィッシング攻撃」（Anti-Phishing） これはPasskeyの最も強力な機能です。Passkeyプロトコルにおいて、**オリジンバインディング（Origin Binding）**が強制的に含まれています。\nシナリオ： ハッカーが偽のg00gle.comを作成してあなたをだますログインを試みます。 結果： ユーザーエージェントとシステムは、現在のドメインがPasskey登録されたドメインgoogle.comと一致しないことを検出し、認証の開始を拒否します。パスワードを入力する機会すらありません。 サーバー漏洩も無意味 たとえハッカーがGoogleのサーバーを侵入し、すべてのデータベースを盗んでも、彼らが手に入れるのは単なる公開鍵だけです。\n公開鍵は秘密鍵を導き出すために使用できません。ハッカーが公開鍵を持っていることは、まるで鍵を持っていることと同じですが、開錠するための鍵（秘密鍵）があなたの携帯電話の中にあり、したがってあなたのアカウントにログインできないということです。\n「弱いパスワード」は存在しない ユーザーは、「123456」のような弱いパスワードを設定する必要がなく、鍵はアルゴリズムによって生成される強力な暗号化データで構成されているためです。\nパスキーが「ログイン管理」を変えるとは これまで、1Password、LastPass、Chromeブラウザなどで長い文字列を記録に頼ってきました。しかし、今、「ログイン管理」は根本的に変化しています。\nクロスデバイス同期 (Passkey Sync) 初期のハードウェアキー (例: YubiKey) は紛失しやすいものです。現在の Passkey はクラウド同期に対応しています：\nApple エコシステム: iCloud キーチェーンとの同期を通じて。iPhone で作成した Passkey が Mac 上で自動的に利用可能になります。 Google エコシステム: Google パスワードマネージャーとの Android および Chrome の同期。 サードパーティ管理ツール: 1Password、Dashlane など、多くのツールが Passkey を完全にサポートしています。これにより、Windows PC で iPhone に保存されている Passkey を使用してログインできるようになります (エコシステムの横断)。 クロスデバイス認証 (QRコードによる) もし、ネットカフェのPC（Windows）でログインしたいが、あなたのPasskeyがiPhoneにある場合、どうすればいいでしょうか？\nウェブページから「別のデバイスでログイン」を選択します。 画面にQRコード（FIDO Cross-Device Flow）が表示されます。 iPhoneのカメラでQRコードをスキャンします。 携帯電話がBluetoothを通じてPCと近距離接続（現場であることを証明）し、生体認証を行います。 PCでのログインが成功します。 「秘密の管理」から「信頼の管理」へ 将来のログイン管理は、個々の明文パスワードを確認するのではなく、信頼されたデバイスを管理することになります。\nあなたは次のように確認できます：「私のGitHubアカウントには、iPhoneとMacBookが関連付けられています。」 携帯電話を紛失してしまった場合でも、サーバー側（またはクラウドアカウント）でそのデバイスの公開鍵へのアクセス権を無効にするだけで済みます。 表格比較：パスワード vs. パスキー 维度 従来のパスワード (Passwords) 通行キー (Passkeys) 記憶負担 高 (複雑な文字を覚える必要がある) 無 (覚えなくてもよい) 表格比較：パスワード vs. パスキー 维度 従来のパスワード (Passwords) 通行キー (Passkeys) フィッシングリスク 極高 (騙されて入力してしまう可能性が非常に高い) ゼロ (ドメインに強制的に紐付けられるため) 表格比較：パスワード vs. パスキー 维度 従来のパスワード (Passwords) 通行キー (Passkeys) サーバー漏洩 危険（撞列/密変更が必要） 安全（公開鍵の漏洩は影響なし） 表格比較：パスワード vs. パスキー 维度 従来のパスワード (Passwords) 通行キー (Passkeys) ログイン体験 遅い (入力またはコピー＆ペースト) 速い (ワンクリック生体認証) 表格比較：パスワード vs. パスキー 维度 従来のパスワード (Passwords) 通行キー (Passkeys) 依存性 大脑またはパスブックへの依存 デバイス（スマートフォン/コンピューター）への依存 現状の課題と未来 Passkey は非常に素晴らしいですが、普及には時間がかかります：\nプラットフォームの壁: 標準は統一されていますが、Apple、Google、Microsoft がそれぞれのエコシステム内で最もスムーズな体験を提供し、Android 携帯を iPad とペアするなど、クロスエコシステムの移行は可能ですが、わずかな摩擦があります。 デバイスへの依存: 信頼できるすべてのデバイスを紛失し、クラウドバックアップがない場合、アカウントの復元は困難です（通常、リカバリーコードが必要です）。 旧システムとの互換性: 多くの古いウェブサイトや社内ネットワークが WebAuthn 標準をサポートしていません。 まとめ パスキーはパスワードのアップグレード版ではなく、インターネット認証の一種である根本的な再構築です。現代デバイスの生体認証能力と公開鍵暗号技術を活用し、セキュリティを金融レベルまで向上させると同時に、ユーザーエクスペリエンスを極限まで簡素化します。\n一般ユーザーにとって、サポートされているプラットフォーム（Google, Apple, Microsoft, Amazon など）でパスキーをできるだけ早く有効にすることは、個人情報のデジタルセキュリティの投資として最も価値の高いものとなります。\n","date":"2025-12-04","language":"ja","permalink":"https://ttf248.life/ja/p/detailed-explanation-of-how-passkeys-work-and-their-future/","tags":["AI霊感衝突坊","passkey","暗号"],"title":"パスキーの仕組みと今後の展望について解説","year":"2025"},{"categories":["コンピューター"],"content":"最近、様々なプログラミング大規模言語モデルの交流圏に浸り、モデルの知能低下（モジュール降智）が最も多く言及される問題となっている。\nローカルデスクトップPCへのデプロイメントは、量子化されたモデルであり、まさに知能低下後のバージョンである。 vibe coding が非常に人気があるため、現在の大規模言語モデルが出力するコンテンツの中で、コードが最も価値のある産物である可能性はないか？ 今回のプロンプトは一度最適化され、ちょうどモデルの知能低下を解消したタイミングだった。大規模言語モデルからの回答は、プロンプトの最適化、より詳細なタスク計画、より明確な出力要件であった。\nこの問題に対する適切なプロンプト：現在、多くの大手企業が大規模言語モデルサービスを提供しており、ユーザーからモデルの知能低下に関するフィードバックが見られることがある。専門的な観点からは、パラメータの精度、推論コストを考慮して記事を作成する。科普文として、長すぎないようにする。 最適化されたバージョン：\nあなたは経験豊富なAI業界技術専門誌作家です。あなたの目標は、一般読者向けでありながら内容が専門的な中国語の科普記事を書くことです。 以下の手順で考え、作成してください。 1. 大纲の策定：まず、明確な3段構成の記事大綱（例：導入、精度分析、コストとアーキテクチャ分析、結論）を作成してください。 2. 内容への焦点を当てる：文章は、ユーザーが指摘する「知能低下」現象を深く分かりやすく説明し、コアな分析ポイントは**パラメータの精度（量子化）** と **推論の運用コスト** を中心に展開する必要があります。 3. 文字数とフォーマット：最終的な記事の長さは600字以内である必要があります。明確な`##`タイトルを使用して段落を区切り、**太字**で本文中の重要な専門用語（例：量子化、MoE、FP16）を強調してください。 はじめに 論理を明確にし、科普的な要件を満たすため、以下の構造を策定しました。\n導入: ユーザーが認識する現実を確認し、核心となる矛盾—大規模なユーザー基盤の背景下で、サービスプロバイダーは「知的能力の頂点」と「サービスの可用性」の間でバランスを取る必要がある—を引き出します。 精度分析（コアポイント1）: パラメータと精度の関係を説明します。FP16と量子化（INT8/INT4）を比較し、「画像の圧縮」の類比を用いて、精度が低下するとロジックが劣化する理由を示します。 コストとアーキテクチャ（コアポイント2）: 推論コストを分析します。MoEアーキテクチャとスパースアクティベーションメカニズムを紹介し、費用削減と高速化のためにモデルが「怠惰」になる方法を説明します。 結論: このような「知的能力の低下」は、商業化普及の不可避な道筋（三途の川）であるとまとめます。 本文 最近、多くのユーザーから大規模言語モデルが以前ほど「賢く」なくなったというフィードバックがありました：論理が単純化され、指示の遵守が悪化し、場合によっては意味不明な発言（無駄話）まで発生します。これはすべて錯覚だけではありません。技術的な観点からは、この「知能低下」現象は、大手企業が膨大なユーザーに対処するために、推論コストとサービス速度のバランスを取るための技術的な妥協であると考えられます。\n精度「縮水」：4Kから720Pへの代償 大規模モデルの「知能」は、主に数千億個のパラメータに格納されています。理想的な状態においては、これらのパラメータが高精度の FP16（16ビット浮動小数点数）形式で動作し、極微細な意味の違いを捉えることができます。しかし、このような高精度は、膨大なVRAM（ビデオメモリ）の占有と、遅い計算速度をもたらします。\n数億人のユーザーがスムーズに利用できるようにするため、サービスプロバイダーは一般的に量子化（Quantization）技術を採用しています。これは、パラメータの精度を FP16 から INT8 甚至 INT4 に圧縮する手段です。\nこれは、4K高精細映画を720Pストリーミングに圧縮するようなものです。剧情（大まかなロジック）は変わっていませんが、画面の詳細（微細な論理的関連性、複雑な指示の実行詳細）が失われます。このような「有損圧縮」により、モデルが複雑なタスクを処理する際の表現力が低下し、ユーザーに「変に賢くなった感じ」を与えることになります。\nコスト圧迫：脳を「部分的に休ませる」 精度だけでなく、推論の運用コストがもう一つの重要な要素です。AI に質問をするたびに、サーバーは膨大な行列演算を実行し、電気代とハードウェアの劣化は驚くほど大きくなります。\nコストを下げるために、現代の大規模モデルでは、MoE（Mixture of Experts、混合専門家モデル）アーキテクチャが広く採用されています。従来のモデルが毎回すべてのニューロンを活性化するのとは異なり、MoE は 疎な活性化戦略を採用し、あなたの質問に対して、システムは関連する「専門家」ネットワークの一部分だけを呼び覚まし、残りは休眠状態に保ちます。\nこれは計算量を大幅に削減しますが、ルーティングアルゴリズム（Router）が負荷分散や演算コストの節約のために、あなたの複雑な数学的問題を「文学的専門家」に割り当てるか、速度のために専門家の呼び出し数を犠牲にする場合、出力品質は変動し、低下する可能性があります。\n結論 したがって、「降智」と呼ばれる現象は、AIが研究室から大規模な商用化へと移行する際の必然的な痛みを伴うものです。パラメータ精度における抑制とモデルアーキテクチャの最適化は、誰もがAIを使いこなせるように、メーカーが「絶対的な知能」と「コスト効率」の間で模索している微妙なバランスです。\n","date":"2025-12-04","language":"ja","permalink":"https://ttf248.life/ja/p/is-ai-getting-dumber-uncovering-the-game-between-parameter-precision-and-inference-costs/","tags":["AI霊感衝突坊","ai","大規模モデル","精度","量子化 (Kyūka)"],"title":"AIは「鈍化」しているのか？パラメータ精度と推論コストの駆け引きを解明","year":"2025"},{"categories":["コンピューター"],"content":"以前言及的 Gemini Cli 登录时需要配置 Google Cloud 项目 ID，这本身就有些不对劲了。如果是个人账户，就不应该有这个限制。出现这个限制，已经开始进入 Google 的风控系统，认为你不是个人账号。\n真是麻烦事，用了小半个月，刚适应下来，现在又要回到 cc + 国产模型的怀抱了。\n確認 現在、Google Cloud プロジェクトをご利用設定されていますが、Gemini Code Assist ライセンスをお持ちになっていません。ライセンスの申請には、管理者にご連絡ください。（#3501）\n問題の整理 昼間はログインして使用できるが、夜帰宅すると使えなくなる。当初はアップデートによるバグだと思ったが、旧バージョンに切り替えても改善されず、GithubにIssueを提起したところ、自動的に多数の類似の問題が割り当てられた。 https://github.com/google-gemini/gemini-cli/issues/14447\n関連情報を確認したところ、不具合が見つかった。gemini cliの公式サイトが更新されておらず、Github上のドキュメントでは、ログイン時にGoogle Cloud IDが必要な場合、企業アカウントとして認識されていると記載されていた。つまり、個人開発者ではないということだ。\nさらに調査を行ったところ、コミュニティにも同様の問題が多数報告されていた。https://discuss.google.dev/t/is-gemini-code-assist-incorrectly-identifying-my-personal-account-as-an-enterprise-account/287654/2 こちらも、使用しているうちに使えなくなるという報告が多数見られた。\n方案 M2 最近半月更新的内容也不少、内容量も多いです。MCP（マルチチャネルパートナープログラム）による接続検索や画像認識のサポートがあります。まずは試してみて、それでもうまくいかない場合は、Googleに課金して基本有料版に切り替えることを検討します。手持ちのアメリカン・クレジットカードが必ずしも課金に成功するとは限らず、以前ChatGPTを課金した際に失敗した経験もあります。\n","date":"2025-12-03","language":"ja","permalink":"https://ttf248.life/ja/p/ultimately-its-returning-to-domestic-models/","tags":["ai","大規模モデル","Google","gemini"],"title":"結局、国産モデルに戻るべきなのか","year":"2025"},{"categories":["魚の7秒間の見聞"],"content":"不動産企業における優秀な人材、万科も限界を迎えた。深鉄の継続的な輸血は、次第に埋まる穴を埋められなくなった。連携に関するニュース：大手6行が5年期の大額預金証券の販売を全面的に停止。\n中国不動産における債務不履行状況を整理し、タイムラインと主要な出来事をまとめる。恒大、碧桂園、万科、その他私が把握していない不動産企業もあるか。\n本分析基于 2025年12月 的最新视角，涵盖了从危机爆发到当前（2025年末）的完整时间线。\n目前中国房地产行业的格局可以概括为：“恒大已清算、融创刚上岸、碧桂园仍在挣扎中、万科则保持着破铜烂铁的姿态”。\n危機の火種：三道紅線（2020） すべては、規制当局が不動産企業の無秩序な拡大を抑制するために設定したハードルだった。\n時間: 2020年8月 政策: 「三道紅線」（前受金後の資産負債率70%超、純負債率100%超、短期預 cash flow 比率1未満） 結果: 不動産企業は、「借新還舊」で雪だるま式に拡大することができず、資金繰りが瞬く間に締め切られ、高レバレッジの不動産企業がドミノ骨牌式に倒壊を始めた。 大三元（だいさんげん）の現状とタイムライン 恒大 (Evergrande) —— 危機の発端 現状: 裁判所による清算命令が発せられる。許家印に対し強制措置が取られ、グループは崩壊・離散状態となる。 重要なタイムポイント: 2021年12月: 初めて正式な違約（米ドル債利息の支払い不能）を行い、「制限性違約」と格付け機関によって認定される。これは中国不動産市場危機の目覚ましい出来事である。 2023年9月: 許家印は違法犯罪に関与した疑いで、法に基づき強制措置が取られる。 2024年1月: 香港高等法院で正式に清算命令が出され、恒大の海外再編失敗により清算手続きに入る。 碧桂园 (Country Garden) —— “優等生”の崩壊 現状: 債務再編中。かつて「宇宙第一不動産企業」と呼ばれたものの、違約は市場に対する民営住宅企業の最後の信頼を打ち砕いた。 重要なタイムポイント: 2023年8月: 流動性圧力の発生を認め、二筆の米ドル債の利息支払いを怠った。 2023年10月: 正式に違約を発表（4.7億香港ドルの満期款を支払うことができず）、顧問を聘用して海外債務再編を開始した。 2024-2025年: 困難な債務再編交渉を続け、資産売却による自救策を実施（万達商管股权、オーストラリアプロジェクトなど）。 万科 (Vanke) —— 最後の砦 (2025年末の最新動向) 現状: 剛兑を打破。万科は長期間にわたって安定していたが、2025年末にも債務交渉（債権展延）を開始し、混合所有制/国営資本背景の不動産企業も独善できるとは限らないことを示唆した。 重要なタイムポイント: 2024年上半期: 做空と格付け引き下げに見舞われたが、深セン市国有企業の言葉による支援と、招商銀行を主軸とする20億元規模の融資（PPI）によってなんとか債務を履行した。 2025年11月: 初の債権延期提案。万科は債権者に対し、差し迫って満期を迎える非公開定向債券（PPI）の支払いを延期することを提案した。これは万科が公開市場における債務での初の「技術的デフォルト」または展期シグナルとなり、市場を騒然とさせた。 過去に債務不履行/デフォルトを起こした著名な不動産開発企業（時間順に整理） 上記以外にも、多数の数十億規模の不動産開発企業がこれに関与しています。以下は**「債務不履行/デフォルト発生時期」**によって整理されたリストです：\n第一波：早期暴雷 (2021年) 華夏幸福 (China Fortune Land): 2021年初、契約不履行、三道紅線後最早倒下的大型房企之一。目前已完成大部分債務重組。 藍光發展 (Bluewray): 2021年中、契約不履行、四川“地産一哥”、退市。 花樣年 (Fantasia): 2021年10月、契約不履行。其契約不履行非常突然，引發了市場對房企“表外負債”的極度恐慌。 佳兆業 (Kaisa): 2021年12月二次違約（曾在2015年違約過）。“舊改之王”也未能幸免。 陽光城 (Sunshine City): 2021年末開始違約、世界500強房企、迅速崩塌。 第二波：全面蔓延 (2022年) 融創中国 (Sunac): 2022年5月： 正式違約。 現状（2025年）： 已上岸。2023年末完成境外債重組，2025年末重組計画正式生效。孫宏斌は少数で成功を収めた境内外債務重組のボスであり、会社規模は大幅に縮小したが、経営主体を守った。 世茂グループ (Shimao): 2022年7月違約。かつての“豪宅教父”であり、所有するランドマーク（深坑ホテルなど）が多数あり、現在も債務に苦しんでいる。 旭輝控股 (CIFI): 2022年10月違約。かつて民企の“模範例”であったが、その崩壊は民営住宅企業の全滅を意味する。 富力地产 (R\u0026amp;F): “華南五虎”の一員であり、2022年にはすでに債務展期（名状なく展期）を行い、現在も海外資産（ロンドンプロジェクトなど）を売却して債務を返済している。 第三波：国有資/混合所有制承压（2023-2025） 遠洋集団 (Sino-Ocean): 2023年に違約。これは初の暴雷した国資（中国人寿が主要株主）背景の房企であり、”国有企業への信仰”を打ち破った。 雅居樂 (Agile): 2024年5月に公開市場で初めに違約。これ sebelumnya 長らく違約していなかったが、最終的には持て余した。 まとめ：不動産企業の生存状態分類 より明確に記憶するために、これらを4つのカテゴリーに分類することができます。\n「死亡」/清算済み:\n恒大（清算）、藍光（退市）、陽光城（退市） 「ICU」で再生医療中:\n碧桂園（再編交渉中）、世茂、旭輝、遠洋 再編完了/一時的に落ち着いている（普通病房へ転換）:\n融創（孫宏斌が自救成功）、華夏幸福 依然として維持している/危機が露呈し始めた:\n万科（展期開始）、龍湖（現在、少数で未違約の民営住宅企業だが、大きなプレッシャーも抱えている）、金地 関連ニュース：万科の件について、グループ内の仲間と友人と話したところ、結論は「降息は引き続き続く」こと。その直後にニュースでさらに情報が公開されました。\n【大手銀行全面停止5年期大額預金証書】 記者ログイン大手銀行公式APPおよびモバイルバンクで検索すると、現在各銀行の大額預金証書の期間構造は明らかに「短期化」しています。工商銀行「大額預金証書」の欄目下には、1ヶ月、3ヶ月、6ヶ月、1年、2年、3年の期限製品のみが残っています。その中で、3年期の満期の大額預金証書製品の利率は1.55%で、1年期、2年期の製品の利率はそれぞれ1.20%です。また、中国銀行、建設銀行、交通銀行および郵儲銀行の製品マトリックスも同様の特徴を示しています。5年期の製品はすべて販売リストから削除されています。農業銀行の2018年から2025年の個人向け大額預金証書製品カタログにも、5年期の大額預金証書製品の「痕跡」は見当たりません。（中国金融時報）\n","date":"2025-12-02","language":"ja","permalink":"https://ttf248.life/ja/p/analyze-the-defaults-and-delinquencies-in-chinese-real-estate/","tags":["AI霊感衝突坊","不動産","万科 (Bank of America)"],"title":"中国不動産における債務不履行状況の整理","year":"2025"},{"categories":["投資 (tōshi)"],"content":" 左側の取引は難しく、右側の取引も好調ではありません。小米社の自社株買い、雷・ヨンピン氏の自社株買いにより、株価が急上昇し、40ドル安を支えました。アリババの業績報告書における純利益の大幅な減少に対し、市場は配達补贴の規模縮小を予測し、美団の株価も大幅に上昇（6%）。AI の資本論理は未完成であり、以前のビジネスとは異なり、まずユーザーを獲得し、広範囲に展開して、徐々に利益を上げるというものではありません。AI の継続的なコストは低下せず、ハードウェアと電気代がかかります。\n現在の市場環境において、投資家たちは極端な分裂感に直面しています：左側の取引（逆勢抄底）は黎明前に死んでしまい、右側の取引（順勢追涨）も山の上で終わってしまいます。 近日における小米、アリババ、美団、そしてAI などの３つの典型的な事例が、この資金論理の駆け引きを完璧に表現しています。\n小米：真金白銀の「右側シグナル」、あるいはオーナーが先頭に立つのか 現象: 株価が40香港ドルを突破した際、一挙手一投足ではありませんでした。 深層ロジック: 小米の前後の震盪により、多くの左側埋伏資金が忍耐を失っていました。真の転換点は強力な自信注入でした。 ニュース的事実: ほんの数日前、雷軍氏が個人で超1億香港ドルを投じて自社株を買い増し、均価は約38.58香港ドルでした。同時に、小米グループも数百万株式を買い戻しました。 市場反応: この「オーナーが直接場ට入り、会社による買い戻し」という二重の好都合により、市場に最も明確な「右側シグナル」が発せられました。株価は急上昇し、40香港ドルの大関を力強く踏み込み、時価総額は万億へと回復しました。 取引の示唆: 一般投資家にとって、左側埋伏小米には非常に強い信仰（車が成功する、スマートフォンが高端化するだろうという信念）が必要です。しかし、雷總が出動した時点で右側を狙うと、コストは上昇し、利益余地は縮小されます。 阿里 vs 美団：決算における「休戦協定」 現象: アリの純利益が低下し、美団の株価は逆に急騰。一見矛盾しているように見えるが、論理的には自明である。 深層的なロジック: これは**「内需終焉、利益放出」**に関するゲームである。 ニュース的事実: アリの最近の決算では純利益が大幅に低下（一部は投資損益の影響を受けている）しているが、市場はコアなビジネスデータの変化を敏锐に捉えている——ローカル生活（デリバリー/至急配達）に対する補助金が弱まっている。 資本的推演: アリが「外食戦争」を打つために狂ったようにキャッシュを燃やさなくなった場合、業界の巨頭である美団は最大の受益者となる。市場は競争格局が「悪性価格競争」から「合理的な利益追求」へと戻ると予測している。 取引の示唆: アリの左側ロジックをショートする: 利益が低下した時点でパニック売りをすることで、そのコアなeコマースの回復ロジックを見逃す可能性がある。 美団の右側ロジックをロングする: 決算で補助金が下落し、利益が急増することが確認されるまで（右側）、株価はすでにこの期待を先取りしているため、投資に入る（右側）。今回の美団の大幅な上昇は、「他人の予測を予測した」ことで得られたものだ。 AI 領域：閉環不能の「資本ブラックホール」 現象: 米国株式市場、中国A株市場を問わず、AI が適用されたとしても株価は依然として下落し続けたり、大幅な変動を繰り返したりする。 深層ロジック: 資本市場は「ストーリーテリング」の段階から、「計算」の段階へと移行し始めている。 硬傷（資本閉環の欠如）: 従来のインターネットモデルは、資金投入 → ユーザー獲得 → 辺际コストの逓減 → 座って稼ぐというものだった。 AI の死因: AI の辺际コストはゼロに近づかないどころか、下げることが非常に困難である。 ハードウェアの劣化: 高価な GPU の折損は著しい。 エネルギーコスト: トレーニングと推論は資金を費やすだけでなく、電気代もかかる。最近、レッド・ハンター資本が発表した 「AI 6000億ドルの問題」 は、業界全体として毎年6000億ドル回収しなければインフラ構築のコストを賄えないこと、そして現在の適用収益はわずかであることを示している。 現状: 掘削機（英偉達、光モジュール）しか稼げず、アプリケーション（ユーザー獲得）は、ユーザーが増えるほど電気代と計算資源費も増えてしまう。 取引の示唆: AI の左側は現在、底なし沼のような状態であり、コストが下がらないからだ。AI の右側（業績の実現）は、ビジネスモデルがまだ実行されていないため、遥か彼方に存在する。 まとめ 小米 は、確実性を得るには資金（買い戻し/増強）が必要であること、しかしそれによって低価格の株価を失うことを示唆している。 アリババ/美団 は、巨頭間の「停戦合意」を理解することの方が、単なる財務諸表数字を見るよりも重要であることを教えている。 AI は、この分野において、「収入 \u0026lt; (ハードウェアの減価償却 + 電気代)」という公式が破られる限り、すべての反発は感情的な駆け引きであり、価値回復ではないことを示している。 ","date":"2025-11-27","language":"ja","permalink":"https://ttf248.life/ja/p/the-dilemma-of-trades-difficult-to-initiate-on-the-left-short-side-difficult-to-follow-up-on-the-right-long-side/","tags":["小米 (Xiǎomǐ)","恒生指数 (こうせいしじょ)","美团 (Meituan)","振り返り記録"],"title":"取引のジレンマ：左側は苦痛、右側は追跡困難","year":"2025"},{"categories":["投資 (tōshi)","転載 (tenzai)"],"content":"引き続き操作なし。小米は現在のサポートラインを割り込んだことなく、昨日から2日間連続で大幅に下落したが、最終的に買い戻しによって株価が安定した。昨晩の米国株式市場も興味深い動きを見せ、上昇したが、翌朝見ると全般崩れとなった。今日の中国国内では、A株や香港株も停滞している。\nこのように大きく落ちたのは良いことだ。大盤に巻き込まれることなく、静観し、落ち着いてから対応する。仏的な精神でいる（佛系）\n跌破の原因 https://wallstreetcn.com/articles/3759889 他の意見が正しいかどうかは不明ですが、定量的な資金が国内株式に与える影響はますます大きくなっています。個別の銘柄は多くの場合、指数と同じように動きます。原文は長いため、豆包が核心の内容を抽出しました。\n2025年11月、グローバルなリスク資産の大幅な下落に対し、高盛のシニアトレーダーであるRich Privorotsky氏が復習し、今回の暴落は多要因が段階的に伝播し、最終的にシステム的な売りにより発展した結果だと指摘しています。主な駆動要因は4つのレベルに及びます。\n連邦準備制度理事会（Fed）が金利を引き上げる：暴落の連鎖の起点 最新の雇用統計は矛盾した信号を示している：雇用ポジションの増加は堅調だが、失業率は4.44%に上昇（主に16～24歳の労働力の流入による）、過去3ヶ月の平均新規雇用数は6万2,000人、潜在的な新規雇用数は3万9,000人で、8月のデータも下方修正された。さらに企業による解雇傾向を考慮すると、市場は連邦準備制度理事会（Fed）が鸽派（ごうは）な姿勢を示すと予想していたが、連邦準備制度理事会は鷹派（おうは）な姿勢を維持し、12月の利下げ期待が打ち消された。利下げの可能性はほぼゼロとなり、これが暴落を引き起こす最初のドミノ骨牌となった。Privorotskyは、このような雇用状況下での鷹派的な立場を「政策の間違い」と直接指摘した。\nAI叙事の再構築：Googleが勝利至上型格局を引き起こす AIセクターにおいて、論理的な分化が鍵となる中、NVIDIAは業績が好調であるものの、投資の中心から外れる。Google Gemini-3モデルの画期的な進展がAI投資エコシステムを再構築し、「破壊的モデル」として他社に製品サイクルを遅らせ、資本支出を増加させ、投資リターンの不確実性を高めている。これにより、甲骨文などの企業ソフトウェア会社が上昇に乗れなくなった。市場は「勝利者と敗者」の明確な格局を形成し、AIは「普及」から「勝利至上型」へと転換し、関連セクターの調整を引き起こしている。\n仮想通貨の急落（シャブル）：一般投資家のリスク許容度が低下 暗号資産市場における劇的な価格変動が連鎖反応を引き起こした。過去2年間、持ち場で粘り続けた「ダイヤモンドハンド」（長期保有者）は、巨額の売り注文による鯨（機関投資家）による大量売却などの要因により、「売り手」へと転換し、積極的に暗号資産を売却してポジションをクローズするようになった。このようなパニック情绪が非上場テクノロジー企業やAI関連銘柄に波及し、Palantir社は直近で5.5%の上昇から6%の大幅な下落に転換したことを示しており、一般投資家のリスク許容度が著しく低下し、市場構造に根本的な変化が生じている。\n量規ファンドによる売り圧力：急落を加速させる主要要因 8月から、トレンド追跡ファンド（CTAs）は指数5000億ドル超のロングポジションを抱えており、指数が重要な水準を下回ることで集中清算を引き起こしました。同時に、ボラティリティの上昇によりボラティリティコントロール戦略ファンドが売りを開始し、VIX ETN資金の流れによって形成された「短足・短凸性」のポートフォリオが暴落効果を増幅させました。元々安定していた「低ボラティリティ構造」が崩壊し、量規とシステム投資家の「機械的な売り」が発動し、重大なイベントがないにもかかわらず市場が急激に水準を下げました。\n基本面隐忧と安定条件 基本面を見ると、AI投資は「資本瓶頸」に直面しています。企業債の発行ラッシュが到来し、AIデータセンターが債務拡大に依存していますが、金利上昇によってAIの拡大速度が鈍化する可能性があり、このリスクはこれまで十分に価格付けされていませんでした。ゴールドマン・サックスはS\u0026amp;P 500ミニ契約が6500ポイント下落と予測するとともに、AIの長期的な価値は変わらず、自動化を通じて労働集約型企業におけるマージナル利益の拡大によって真の勝者は生まれると考えています。\n市場の安定には以下の3つの条件が必要です：CTA（共同投資ファンド）のポジション調整完了、個人投資家の過剰な買い超えが排除され、かつ、少なくとも以下のいずれかが実現する必要があります。\n暗号資産の安定化 FRB（米連邦準備制度理事会）が明確に転換金利へと移行 AI資本支出が支えられている ","date":"2025-11-22","language":"ja","permalink":"https://ttf248.life/ja/p/global-stock-markets-plunge-for-days-fed-ai-and-quantitative-easing/","tags":["小米 (Xiǎomǐ)","恒生指数 (こうせいしじょ)","量子化 (Kyūka)","振り返り記録"],"title":"グローバル株式市場が連日暴落：米連邦準備制度理事会（FRB）、AIと量的緩和政策の影響","year":"2025"},{"categories":["コンピューター","魚の7秒間の見聞"],"content":"このサイトのメインドメインはGitHub Pages、ブログのサブドメインはVercel加速で運用していましたが、バックエンド管理ページが古臭くて退却しました。本来静かに育っていた水面下での記事ですが、ブログ界隈のグループ内の情報が絶えず流れ込み、これは通常では非常に静かな状態です。開いてみたらCFがダウンしており、多くのブロガーさんのサイトが開けなくなっていました。\nインターネットインフラとしての基本的な問題であり、故障がこれほど長く続いているべきではありません。株価の大暴落は予想外でした。\nCloudflareの障害により、多くの知名ウェブサイトにアクセスできず、事前に株価下落、関連情報を整理し、記事を作成\n2025年11月18日（火）発表 — 本日（11月18日）、米国株式市場のオープン前に、主要なグローバルインターネットインフラストラクチャサービスプロバイダーであるCloudflareが大規模なネットワーク障害に見舞われ、数千ものそのサービスの依存している著名なウェブサイトやアプリケーションがダウンまたはアクセス困難になりました。\nこの事態を受け、Cloudflare（ニューヨーク証券取引所：NET）の株価はオープン前の取引中に下落しました。\n🌍 世界規模での障害が、主要サービスを次々と「ダウン」させる この障害は火曜早朝（米国東部時間午前7時頃、協定世界時刻午後11時48分頃）に発生し始めました。世界各地のユーザーから、X (旧Twitter)、OpenAI (ChatGPT) の人工知能サービス、Spotify の音楽ストリーミングサービス、League of Legends および Valorant などのゲームプラットフォーム、BitMEX や DefiLlama などの暗号通貨取引所など、多数の人気サービスへのアクセスができないとの報告がありました。 これらのウェブサイトにアクセスしようとしたユーザーは、一般的に「500 Internal Server Error」（サーバー内部エラー）というメッセージが表示されました。Cloudflare はインターネットの「仲介者」として、世界数百万のウェブサイトにコンテンツ配信 (CDN) および DDoS 対策サービスを提供しており、そのネットワーク内のわずかな「不安定さ」が瞬く間に世界規模での連鎖反応を引き起こしました。\n📉 市場反応は迅速、(NET) 盤前株価下落 インターネットの重要なインフラストラクチャの一つであるCloudflareサービスの安定性は投資家の関心を強く惹いていた。\n故障消息が伝わった後、資本市場は迅速に反応した。Cloudflare (NYSE: NET) の株式は火曜日の盤前取引において顕著な売り圧力となった。金融データによると、株価は約 3.5%～4% 下落し、前回の取引日（11月17日）の約202.25米ドルからの閉場価格から、一時195米ドル付近まで下落した。\nこれは投資家が今回のサービス中断の深刻さと、それが会社名誉や短期収益に与える可能性のある影響に対する懸念を反映したものだ。\n🛠️ 公式声明：已定位问题，正在修复 Cloudflare 官方迅速在其系统状态页面上确认了这一事件。公司于北京时间今天下午（2023年11月18日 13:09 UTC）更新状态称：\n“问题已经确定，正在实施修复。”\n🛠️ 公式声明：问题已定位，正在修复 Cloudflare 的报告表明，此次事件被定性为“全球ネットワークに問題が発生”（Gukan netwāku ni mondai ga hassei）——“全球网络遇到问题”，并伴随“広範な500エラー”（Kōhan no 500 ērā) ——“大范围500错误”。\nCloudflare 表示，他们正在努力缓解此问题，并且已经看到服务开始恢复，但警告称在修复工作继续进行期间，客户可能仍会观察到“正常よりも高いエラー率”（Nōtō yori takai error-ritsu）——“高于正常的错误率”。\n截至发稿时，部分网站的访问已开始逐步恢复，但全球ネットワークの遅延とエラー率は依然として高水準にある。我们将持续关注事态的后续发展。\n","date":"2025-11-18","language":"ja","permalink":"https://ttf248.life/ja/p/cloudflare-experienced-a-global-network-outage-causing-websites-like-x-formerly-twitter-and-chatgpt-to-crash-the-stock-price-suffered-a-setback-ahead-of-the-market-open/","tags":["AI霊感衝突坊","cloudeflare","インターネット","ニューヨーク証券取引所（NYSE）/ 株式市場"],"title":"Cloudflareが世界的なネットワーク障害を引き起こし、X（旧Twitter）、ChatGPTなどの主要ウェブサイトがダウン。株価は大幅に下落しました。","year":"2025"},{"categories":["コンピューター"],"content":"システムサービス間のデータ同期において、最近の変更により特定のインターフェースのデータ量が増加し、頻繁に死鎖が発生しました。同僚による調査の結果、間隙ロックが原因であることが判明しました。MySQL の利用は少ないため、記録として残します。\nMySQL の間隙ロック、背景、原理、間隙ロックを閉じる方法、閉じた際の注意点；あなたは経験豊富なデータベース DBA として、私の問題に対して拡張的な分析と補足情報を提供してください。幻読とは何ですか？ 主流の大手企業は RC モードか RR モードを選択しますか？ 私は金融業界の券商システムを担当しており、あなたはそのようなシステムに最適なソリューションを提案してください。上記の質問を整理し、ドキュメントを作成してください。\nMySQL において、特に高負荷環境下では、「ロック」を回避することはできません。ギャップロックは InnoDB エンジンにおける重要な特性ですが、同時にパフォーマンスボトルネックや死鎖の根源となることもあります。\nこの記事では、ギャップロックの核心、利点・欠点を迅速に整理し、あなた（特に金融業界）に対して明確なアーキテクチャ選定のアドバイスを提供します。\n幻読とギャップロックとは何か？ 幻読 (Phantom Read): トランザクション中に、例えば ID \u0026gt; 100 の範囲を最初に検索し、10件のデータを取得する。その後、別のトランザクションが ID=101 を挿入してコミットすると、2回目の検索で11件に増加してしまう。この「幻のような」追加されたデータが、その名も「幻読」と呼ばれる。\nギャップロック (Gap Lock): MySQL は RR（可繰り返し読み） 隔離レベル下において、「幻読」の問題を解決するために発明された。行自体をロックするのではなく、データの間の「隙間」をロックする。\n作用: 他のトランザクションがその「隙間」に INSERT を実行できないように防止する。 コスト: ロック範囲が広がり、コンカレンシー能力が低下し、死鎖を引き起こす可能性がある。 間隙ロックを「閉じる」方法 最も直接的な方法は、データベースの分離レベルをRR (Repeatable Read) からRC (Read Committed) に降下させることです。\n-- 現在のセッションの分離レベルをRCに設定 SET SESSION transaction_isolation = \u0026#39;READ-COMMITTED\u0026#39;; -- 永続的に変更（my.cnf を修正し、mysqld を再起動する必要があります） -- [mysqld] -- transaction-isolation = READ-COMMITTED ⚠️ 关闭の影響（即 RC レベルの特性） パフォーマンス向上: ギャップロックがなくなるため、ロック粒度が細かくなり、同時スループットが大幅に向上します。 死鎖減少: ほとんどのギャップロックによる死鎖は解消されます。 幻読/不整合な読みが発生する: これは RC レベルの「特性」であり、トランザクション内で二回クエリを実行しても結果が一致しない可能性があります。 【必須要件】ROW形式のBinlogとの併用が必要: RC レベルを使用する場合、必ず binlog_format を ROW に設定する必要があります。そうしないと、ギャップロックの保護がないため、主従レプリケーション中に主従データが不整合になる可能性があります。 主要ベンダーの選択：RC または RR？ 回答：ほとんどの主要なインターネット企業は RC (Read Committed) + ROW Binlog モードを選択しています。\n理由： インターネットビジネス（例：eコマース、ソーシャル）は、極めて高い同時性を追求します。RR のロックスロットによる頻繁なロック待ちや死鎖に耐えられません。 トレードオフ： データベースレベルでの「読み取り追跡可能」を放棄し、代わりにアプリケーション層でオプティミスティックロック（バージョン番号、CAS など）などの方法を用いて、重要なビジネス（例：在庫、残高）の論理的一貫性を保証します。 金融業界（証券会社）における選択の指針 データの一貫性要件が極めて高い証券会社システムの場合、シナリオ別対応を推奨します：\n方案一：コア取引システム（高同時多接続、低遅延） 推奨：RC (Read Committed) + ROW Binlog + アプリケーション層のオプティミスティックロック\nシナリオ： 注文撮合、注文、資金決済。 理由： 取引システムの同時アクセス負荷は、秒殺サイトに匹敵する。RR の間隙ロックが性能ボトルネックとなり、深刻なロック競合や死鎖を引き起こすことは、取引システムでは容認できない。 対策： RC を使用して高性能を確保し、アプリケーションコード（例: Java）で UPDATE ... WHERE balance \u0026gt; ? または CAS バージョン番号メカニズムを使用して資金の安全性を保証し、オーバーサブスクリプションを防ぐ。 方案二：清算対帳システム（バッチ処理、高整合性） 推奨：RR (Repeatable Read)\nシナリオ: 期末バッチ対帳、レポート生成、日終清算。 理由: バッチ処理タスクは、「絶対的な整合性」のあるデータスナップショット上で実行する必要があります。それは RR レベルが提供する能力を必要とし、統計プロセス全体を通して「幻読」が発生しないことを保証し、最終勘定帳が正確であることを確認します。 まとめ レベル メリット デメリット 適用シナリオ RR (デフォルト) 幻読を解決し、データの一貫性が高い 并行性が低い、死鎖しやすい（ギャップロック） レポート、決済、データの一貫性要求が極高く、並行性が少ないシナリオ まとめ レベル メリット デメリット 適用シナリオ RC 并行性が高く、死鎖が少ない ファントム読み、不整合な読みが得られる 高い同時性を持つコアビジネス（例：ECサイト、金融取引）で、ROW Binlogと組み合わせて使用 まとめ 証券会社のコアシステムにおいて、RC + ROW Binlog はパフォーマンスと整合性を両立させる主要なアーキテクチャソリューションですが、データ整合性の保証をアプリケーション層でより多く担うことを要求します。\n","date":"2025-11-18","language":"ja","permalink":"https://ttf248.life/ja/p/understanding-mysql-gaps-locks-from-principles-to-enterprise-grade-selection/","tags":["AI霊感衝突坊","mysql","死鎖"],"title":"MySQL のギャップロックを理解する：原理から金融レベルの選定まで","year":"2025"},{"categories":["投資 (tōshi)"],"content":"最近、Xiaomiの第3四半期決算が発表され、予想外の結果となりました。米国不安、香港株の近況は流動性枯渇、恒生テクノロジー指数が大幅に下落しています。\nアリババは、デリバリー戦争における主要なプレイヤーとして、関連する电商税の影響も大きいため、ネット上ではあまり議論がありません。\n以前の稿子でこの件について書いたかどうかわかりませんが、Xiaomiを買入った時の私は、その時を支えた要因を十分に考えていませんでした。抖音に関連する動画をたくさん見ているのかもしれません。\n最近は恒生テクノロジー指数が下落し、香港株の電気自動車関連銘柄も同様に低迷しています。Xiaomiは複数のボーナス（buff）が重なり、ネガティブなニュースが飛び交い、株価も大幅に下落しています。\n最近、広報部門の責任者を交代しましたが、陰謀論としては、すでに換算を考えていたようです。しかし、利益に関わるため、多くのインフルエンサー（KOL）がいるため、彼らが誤った情報を発言すれば、事態は収束しにくいでしょう。\nこの記事では、小米集团 (Xiaomi Group) の估值逻辑と、美团 (Meituan) と 阿里巴巴 (Alibaba) が直面している市場および政策の課題を分析しています。\n小米：評価額が急騰する根拠（プラットフォームプレミアム） 核心观点: 資本市場が小米に与えた評価額の急騰は、その**「プラットフォーム型企業」と「エコシステム強化」による巨大なプレミアム**に起因しており、これは垂直メーカー（理想、零跑など）が持っていないものです。 評価ポイントの違い: 小米: 以下の**「テクノロジー・プラットフォーム」と「人車家全エコシステム」の希少性に紐づけられています。自動車事業はエコシステムの拡大における重要な一歩**と見なされ、リスクはスマートフォンやインターネットビジネスで分散されています。 自動車メーカー（理想/零跑）: 以下の自動車販売台数と単車利益に紐づけられ、評価曲線は自動車業界の周期と直接結びついています。 エコシステム強化の価値: 小米は数億人の高粘性ユーザーを保有しており、自動車注文転換効率が非常に高く、マーケティングコストが低いです。「人車家」のシームレスな連携は市場において業界平均水準よりも優れていると見なされ、差別化競争力として評価されています。 資本市場の期待: 投資家は小米が将来10年間で**万ドル規模の新セクターへの「参入資格」と「エコシステム連携価値」**を成功させることを買っており、全体的な評価ロジックを再構築しました。 美団：離場を検討 当初の「万物を送る」という言葉が広く受け入れられ、人心に響いたものの、今看来、強固な競争優位性もそれほど厚みがない。\n現状: 買い付け時にあまり深く考えず、近年の株価下落を受け、第3四半期の業績発表後に「肉を削る」かどうかの判断を待っている。 阿里巴巴（电商税收政策の影響） 税制変更： 中国近年の「eコマース税」は主に以下の2つの側面で集中しています。 跨境電子商取引小売輸入税（「海淘」）： 50元未満の免税措置が廃止され、海淘商品の価格は約11.9%上昇し、業界のコンプライアンス化を促しました。 国内eコマースに関わる課税情報報告基準： プラットフォームが販売情報を報告することを要求し、過去に隠れていた収入を持つC2C個人売家が継続できなくなり、業界は合規性を中心とした再構築段階に入りました。 プラットフォームへの影響： 淘宝（C2C）： 短期的にコンプライアンスを拒否する小規模事業者が出退場する可能性がありますが、長期的な視点で見ると、プラットフォームの品質と消費者の信頼性を向上させます。\n天猫/京东（B2C）： 長期的には有利であり、これらの大手B2C企業はすでに正規の課税主体であるため、新しい規制は彼らにより公平な競争環境を創造します。\n事業者損益の原因： 損益は主に逃税によって価格優位性を得ていた事業者に集中しています。小規模企業向けの優遇措置を満たす事業者の場合、コンプライアンス申告後に税負担は低く抑えられたり、免税となる可能性があります。淘汰は公平な競争への道筋を辿る必然的な段階です。\n","date":"2025-11-18","language":"ja","permalink":"https://ttf248.life/ja/p/hang-seng-index-sharp-decline-meituan-considering-exit-examining-xiaomi-alibaba-and-meituans-new-valuation-anchors-through-ecological-premium/","tags":["小米 (Xiǎomǐ)","美团 (Meituan)","恒生指数 (こうせいしじょ)","財務諸表","アリババグループ (ありばばぐループ)","EC税 (イーシーセー)","振り返り記録"],"title":"香港株式市場の流動性、美団の撤退検討？「エコシステムプレミアム」から小米、アリババ、美団の評価新たな基準点","year":"2025"},{"categories":["コンピューター"],"content":" cc が提供するコマンドが多すぎて、役立つものはどれか… 抖音で動画学習を試みて、役に感じるものを簡単に記録します。 生成規範化された Git 日志ですが、デフォルトでは著作情報が含まれます。国内では彼らのモデルを使用しなくなってしまい、連携しているのは国内の大規模言語モデルばかりなので、Git 日志内の著作情報は不要です（GitHub では cc が共同開発者として表示されます）。 ユーザー設定ファイルに \u0026quot;includeCoAuthoredBy\u0026quot;: false を追加します。 /init で現在のフォルダの概要を生成し、大規模言語モデルがプロジェクトをより良く理解できるようにします。 /compact /clear は日常的に使用するコマンドで、説明は不要です。 claude --dangerously-skip-permissions は慎重に使用してください。以前の記事の Null ファイルがこれによって作成されたため、cc の Windows 上には多くの問題があります。 # で記憶モードに入り、プロジェクトレベルで使用されることは少ないですが、ユーザーレベルでよく使用します。よく使うプロジェクトの内容を記述することで、生成コードの精度を高めます。 /ide は VSCode で現在選択されているテキストデータを感知し、trae 内部から関連ファイルの関数スニペットを提供します。コンソールに切り替わる際、同様の機能が見つからなかったため、多くの場合はプロジェクトファイルが多いため、参照する関数を定めることで、コード生成の精度を高めることができます。 mcp ？これまであまり試したことがなく、必要になった場合に改めて試してみます。少し使い勝手が難しく感じるためです。 カスタムコマンドは不要です。ユーザーレベルで代替できる Git の規範化された提出方法があります。 -r はプロジェクトを閉じると再起動し、以前の会話を復元します。複雑なプロジェクトではあまり効果がありません。国内のモデルの場合、コンテキスト 200k で簡単に満たされます。\n","date":"2025-11-08","language":"ja","permalink":"https://ttf248.life/ja/p/claude-code-frequently-asked-operations-guide/","tags":["ai","claude code"],"title":"Claude Code よく使う操作ガイド","year":"2025"},{"categories":["コンピューター"],"content":"ソフトウェア開発の日常業務において、私たちはしばしば「厄介な小さな問題」に遭遇します。それらは一見単純に見えますが、数時間という貴重な時間を費やしてしまうこともあります。特に、Windows システム上で特定のファイルを削除する（特に開発ツールチェーンによって意図せず生成されたファイル）ことは、「大惨事」の典型的な例です。\n私もそのような「地獄級」の問題に遭遇しました。ローカルで開発していた際に、プロジェクト内に莫名其妙に nul という名前のファイルが作成されてしまいました。Windows エクスプローラーや CMD コマンドラインを試しましたが、システムは「ファイルが見つからない」または「削除できません」と表示していました。このファイルはまるで幽霊のように、頑固にもプロジェクトディレクトリに根付いていました。\nフェーズ１：標準的な試行と「標準」の無効な解決策 問題に遭遇したとき、私の第一反応は \u0026ldquo;nul ファイル\u0026rdquo; です。 なぜ nul ファイルが特殊なのか？ Windows の歴史を知る開発者は、nul が「穴」と呼ばれるものだと知っているかもしれません。Windows (およびそれ以前の DOS) システムでは、NUL、CON、PRN、AUX などの名前は予約されたデバイス名です。NUL は「空デバイス」（Unix/Linux の /dev/null に相当）を表します。 Windows のファイルシステム API が、nul という名前の「ファイル」を操作しようとすると、それは空デバイスを操作しているものとして扱われ、通常のファイル名を操作しようとしているものとは区別されません。したがって、ファイルの削除やリネームなどの標準的なファイル操作はすべて失敗します。 nul ファイルがどのように生成されるのか？ これは通常、クロスプラットフォーム開発ツール（Git、Node.js スクリプト、Python スクリプトなど）の「問題」によるものです。これらのツールは POSIX (Unix 互換) 標準に基づいており、それらから見ると nul は単なるファイル名です。Windows 上で実行される場合、API を直接呼び出すのではなく、この Windows で「消化不良」を起こすようなファイルを生成することがあります。 オンラインで推奨されている「標準的な解決策」 私は迅速にインターネットを検索し、私だけが最初にこの問題に遭遇したわけではないことを知りました。コミュニティはいくつかの「高度な」解決策を提唱していました：\n\\\\.\\ 構文の使用: CMD で特別な「長いパス」構文を使用して、Windows の名前チェックを回避します。 del \\\\.\\C:\\your\\project\\path\\nul Git Bash の使用: Git Bash は軽量の Unix 環境を提供し、nul を特殊なデバイスとして扱わないためです。 rm nul WSL (Windows Subsystem for Linux) の使用: WSL に入って Windows ディスクをマウントし、Linux の rm コマンドを使用してファイルを削除します。 rm /mnt/c/your/project/path/nul しかし、これらの方法どれも私には効果がありません！ WSL でも Git Bash でも、rm nul を実行しても、「No such file or directory」（ファイルまたはディレクトリが見つかりません）というエラーが発生しました。これは、私が想像していたよりも問題が複雑であることを示唆していました。\nフェーズ２：閃光一瞬——それは「多重問題の重ね合わせ」なのか？ nul ファイルが実際に存在する場合、Unixツールはなぜそれを「見つからない」と報告するのか？\n私は疑念を抱き始めた：問題は nul ファイル自体だけでなく、その「居場所」、つまり存在するディレクトリにあるのではないか？\nそこで私は直ちにGit Bash（これが重要だ、Windowsのエクスプローラーでは異常が表示されない可能性があるから）を開き、nul ファイルが存在する親ディレクトリに移動して、ls -la (すべてのファイル（隠されたファイルを含む）をリストし、詳細情報を表示) を実行した。\nそこでついに「盲点」を発見した：\nその nul ファイルが保存されているディレクトリは、そのディレクトリ名自体に無効な文字が含まれていた！\nフェーズ2：閃きの一瞬——「マルチ問題の重ね合わせ」なのか？ 私のケースでは、このディレクトリ名はスペースやピリオド（.）で終わる名前であるか、あるいはWindowsが許可しない特殊文字（?, *, :など）を含むものである可能性があります。これらはすべて、開発ツールがクロスプラットフォーム同期する際に「持ち込まれた荷物」です。\n例えば、Git Bashでディレクトリが表示されると \u0026quot;my-app \u0026quot; (末尾のスペースに注意) や \u0026quot;my-app.\u0026quot; のようになります。 これが問題の本質です！\n問題A： nul という「不正な」ファイルがあります。 問題B： \u0026quot;my-app \u0026quot; という「不正な」ディレクトリがあります。 rm /path/to/\u0026quot;my-app \u0026quot;/nul を実行しようとすると、WindowsシステムとUnixツールが「混乱」します。Windows APIは、この不正な文字を含むパスを正しく解析できないためで、Git BashやWSLは「この不正なディレクトリを見る」ことができますが、内部の nul ファイルにアクセスしようとすると、パス解析の複合的な問題により失敗する可能性があります。 フェーズ3：釜底抽薪——パスを徹底的に排除する 「ファイルパス」と「ファイル名」という二つの問題が特定されたことで、解決策は明確になりました。nul ファイルを削除しようとするのではなく、その「不正な」親ディレクトリを直接削除するのです！\n私の最終的な解決手順は以下の通りです。\nGit Bashを開く: これが唯一、「見えない」か「処理できない」これらの不正な名前を正しく認識し、操作できるツールです。 問題ディレクトリの親ディレクトリに移動する: 問題ディレクトリの実際の名称を確認する: 「究極の削除」を実行する: rm コマンドの -r (再帰) と -f (強制) オプションを引用符で囲み、使用してそのディレクトリ全体を削除します。 コマンドを実行すると、私を悩ませていた、nul ファイルを含む、本来も不適切な名前のディレクトリが、ついに私のファイルシステムから完全に消去されました。\n","date":"2025-11-08","language":"ja","permalink":"https://ttf248.life/ja/p/local-development-pain-why-cant-you-delete-nul-files-a-solution-to-the-composite-file-system-problem/","tags":["AI霊感衝突坊","windows","ファイルシステム"],"title":"ローカル開発の苦悩：なぜ `nul` ファイルを削除できないのか？複合型ファイルシステムの問題への解決策","year":"2025"},{"categories":["コンピューター"],"content":"慣例のようにTraeを開き、コードを始める前に、通知欄にメッセージが届く。「claudeモデルが下ラインになったため使用できず、今後も回復する可能性は低い」と。公式からは補償プランが提供され、利用回数が300（1月まで）増加する。\n調べてみると、予想通り、Anthropic社はアメリカの要請により、国内企業へのclaudeシリーズモデルの使用を禁止している。TraeのDiscordコミュニティに潜入し、多くの人がclaudeモデルの下ラインについて不満を漏らし、大部分がclaudeを期待して利用していたためだ。claude 4.5モデルがtraeで同期されなかった時点で、この問題の兆候はすでに存在していた。\n試してみる 最後の1回、試してみることにした。他のモデルも体験してみた（OpenAIのgpt-3.5-turbo、gpt-4、GoogleのGemini Proなど）。 どう表現すればいいかわからないが、どれもあまり理想的ではなかった。Traeの海外チームがどのように開発したのかわからない。本来なら、こんなに大きな差はないはずだ。テストに使用したプロンプトは、以前使っていた小蓝书プロジェクトで、以前の記事にも書かれていたものだ。 加えて、Trae IDE自体に不満があったため、Traeチームにメールを送り、払い戻しの申請を行った。\n変更 誤っていただろうのは、Googleが最初にリリースしたターミナルインタラクティブAIプログラミングのことだ。IDEと比較して、日常的なスマートアシストは存在しないものの、より汎用性が高まっている。開発者は引き続き既存の開発環境を使用することができる。\nOpenAIとAnthropicの2社はそれぞれ、Claude Code、Codexを発表し、ツールとモデルが完全に固定されていない。設定ファイルを修正することで、他のモデルにも接続できる。\nDiscordコミュニティでは、minimax M2やglm4といった国内のモデル（小蓝书プロジェクト）について言及があり、Minimax M2を試してみたところ、それなりに良かった。\nインストールには科学的なアクセスが必要で、異なるモデル間の切り替えについては、https://github.com/farion1231/cc-switch を推奨します。\nclaude code Node.js に依存し、コマンド: npm install -g @anthropic-ai/claude-code\n╭─── Claude Code v2.0.33 ────────────────────────────────────────────────────────────────────────────────╮ │ │ 開始方法のヒント │ │ ようこそ戻ってこられました！ │ /init を実行して、Claude の指示を含む CLAUDE.md ファイルを作成します。 │ │ │ ───────────────────────────────────────────────────────────────── │ │ ▐▛███▜▌ │ 最新アクティビティ │ │ ▝▜█████▛▘ │ 最新のアクティビティはありません │ │ ▘▘ ▝▝ │ │ │ │ │ │ minimax-m2 · API 利用料金 │ │ │ F:\\dev\\notebook │ │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── \u0026gt; \u0026#34;util logging.py を作成して...\u0026#34; を試してください ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ！bash モードの場合は、入力フィールドをクリアするためにエスケープキーをダブルクリックします。 / コマンドの実行 alt + m で自動的に編集を受け入れる alt + v で画像を貼り付けます @ ファイルパスの表示 ctrl + o で詳細な出力を表示 # メモリ化するため tab で思考を切り替える ctrl + t でタスクを表示 backslash (\\) + return (⏎) で 改行 Codex 未体験、参考資料：https://platform.minimaxi.com/docs/guides/text-ai-coding-tools#%E5%9C%A8-codex-cli-%E4%B8%AD%E4%BD%BF%E7%94%A8-minimax-m2\n","date":"2025-11-05","language":"ja","permalink":"https://ttf248.life/ja/p/command-line-ai-coding-interaction/","tags":["ai","ide","claude code","codex"],"title":"コマンドラインベースのAIコーディングインタラクション","year":"2025"},{"categories":["魚の7秒間の見聞"],"content":" NVIDIAの1兆ドル投資による「陽謀」（戦略）分析 2025年のグローバル資本市場は、これまでにない集中化の波を目の当たりにしている。人工知能（AI）を核とした物語は、テクノロジー業界の版図を再構築するだけでなく、米国株式市場における「富の格差」を極限まで拡大させている。かつての「七雄」（Magnificent Seven）では現状を描写するには不十分であり、市場は少数のスーパーウィンナーによって支配されている。 本稿では、以下の3つの主要な問題を掘り下げる： 米国株式市場のトップ10社の時価総額が、全体の株式市場に占める割合はどれくらいか？ AIにはバブルが存在するか？NVIDIAとOpenAI間の100億ドルの「相互投資」モデルは妥当か？ NVIDIAの最近の投資行動は何か？その背後にある戦略的論理とは何か？ 記事作成：米国株式市場の上位10社の時価総額が、全体の株式市場に占める割合はどれくらいになったのか？AIにはバブルが存在するか。NVIDIAによる投資とOpenAIとの相互投資は妥当か？NVIDIAの最近の投資行動を整理し、その合理性を分析する\n市場集中度：十大巨頭垄断米股40%市值 2025年10月～11月の最新データによると、米国株式市場（標準普ル500指数を代表として）の集中度は驚くほど高い水準に達しています。\n米株トップ10社（すべて米国企業）が現在の標準普ル500指数の合計時価総額の40%を占めている。\nこの数字は、わずか一二年前に「七巨頭」が占める30%の割合よりもさらに進んでいます。2025年11月初旬時点での米株トップ10社は概ね以下の通りです：\nNVIDIA（英偉達）: 時価総額は約5兆ドル Apple（苹果）: 時価総額は約4兆ドル Microsoft（微软）: 時価総額は約3850億ドル Alphabet (Google)（アルファベット/グーグル）: 時価総額は約3400億ドル Amazon（アマゾン）: 時価総額は約2600億ドル Broadcom（博通）: 時価総額は約1750億ドル Meta Platforms（メタ・プラットフォームズ）: 時価総額は約1630億ドル Tesla（テスラ）: 時価総額は約1520億ドル Berkshire Hathaway（伯克希ー・ハザウェイ）: 時価総額は約1030億ドル JPMorgan Chase（摩根大通）: 時価総額は約850億ドル このような高い集中度とは、少数の企業の株価の動向が、全体市場のトレンドを決定する可能性があることを意味します。この「超集中化」を推進する原動力は、間違いなく——人工知能です。\nAIバブルと1兆ドル「閉環」：NVIDIAとOpenAIの「相互投資」 ご指摘の「NVIDIAとOpenAI間の相互投資」は、2025年9月時点で世界を震撼させた出来事へと発展しました。これは伝統的なVC投資ではなく、1000億ドルの戦略的パートナーシップです。 1. 協力の「閉環」構造：\nNVIDIAへの投資: NVIDIAはOpenAIに対し、最大1000億ドルを投資することを発表しました。 OpenAIによる調達: OpenAIはこの資金（およびその他の資金調達）を活用し、NVIDIAのチップシステムを調達すると同時に、**少なくとも10吉ワット（GW）**の計算能力を投入することでコミットメントします。これは数百万枚のGPUに相当し、2026年以降にNVIDIAの次世代「Vera Rubin」プラットフォームを採用する予定です。 2. このモデルは妥当か？ これは非常に議論のあるテーマであり、市場における見方は、「革命」と「バブル」の二派に分かれています。 意見１：合理で、これは「AI革命」の必然的な選択 (The Revolution Case)\nOpenAI（買い手）にとって: 通用人工知能（AGI）への道は、ほぼ無限の計算能力を必要とします。現在の市場において、NVIDIAのGPUは最も高性能で成熟したエコシステムを備えた「スコップ」です。将来数年間の最上位チップ供給を確保することは、AI軍拡競争においてリードを保つ唯一の方法です。 NVIDIA（売り手）にとって: OpenAIは最大の、そして最も重要な顧客です。1兆ドル投資を通じてOpenAIと「閉環」することで、NVIDIAは次世代プラットフォーム（Vera Rubin）に対する巨額の注文を確実にし、将来数年間の収益と市場における絶対的な支配地位を確保します。 意見２：不合理で、これは「AIバブル」の特徴 (The Bubble Case) 「閉環取引」(Closed-Loop Financing): 批判者は、これは「左手倒右手」の資本ゲームであると指摘しています。NVIDIAがOpenAIに資金を提供し、OpenAIがその資金を使ってNVIDIAからチップを購入します。これは会計上巨額の収益と成長を生み出しますが、実際には資本の「体内循環」を拡大し、評価額とバブルをさらに増幅させます。 巨大な金融リスク: 報道によると、NVIDIAはOpenAIにデータセンター建設のための債務保証についてさえ議論しています。これは、OpenAIのビジネスモデルが将来実現できない場合（例えばAGIが遅れるか、運営コストが高すぎて破産する場合）、NVIDIAが数十億ドル、あるいは数千億ドルの債務リスクを負う可能性があることを意味します。 反トラストへの懸念: この取引は規制当局や競争相手によって「競争排除」と見なされています。アナリストたちは、NVIDIAが市場における「武器商」として、投資を通じてOpenAIを深く結びつけ、AI軍拡競争においてリードを保つことで、OpenAIの競合（Anthropic、Googleなど）にチップの販売を拒否したり、より悪い条件を提供したりすることで、イノベーションを扼殺する可能性があると懸念しています。 結論: このモデルは、NVIDIAがAIにおける覇権を確立するための**高リスク・高リターンな戦略的「陽謀」**です。それはAIの大発展の触媒であると同時に、史上最大バブルの落脚を示すものとなる可能性があります。 NVIDIAの投資「帝国」：需要を創出する陽動作戦 英伟达はすでに「掘削機売り」に留まらず、そのリスク投資部門（NVIDIA GPU Ventures）を通じて、AI全体の「銀行家」および「エコシステム構築者」へと積極的に転換している。\n📈 NVIDIAの主要投資動向 NVIDIAは2024年から2025年にかけて、投資ペースが急激に加速している。2025年10月時点で、今年だけでも59社のAIスタートアップ企業に投資し、2024年の全年間実績である55社を上回っている。\nその投資ポートフォリオは、AIのあらゆる垂直分野をほぼ網羅しており、重点を置いているのは以下の分野：\nOpenAI（基盤モデル）: 2025年9月に100億ドル規模の戦略的投資と調達協定を締結。 Poolside（AIプログラミング）: 2025年10月、シードラウンドに1億ドルを出資し、AIソフトウェアエンジニアの開発を支援。 Nokia (Nokia)（6G/通信）: 2025年10月に戦略的パートナーシップを発表し、1億ドル投資して共同でAI-RAN（無線アクセスネットワーク）を開発し、6G市場でのシェアを獲得。 Figure AI（ヒューマノイドロボット）: この注目を集めるロボット企業に投資し、「身体性知能」の未来を構想。 Perplexity AI（AI検索）: OpenAIの有力な競合企業への投資を行い、次世代の情報入口を構築。 Wayve（自動運転）: イギリスの自動運転企業への投資を行い、自動車業界におけるチップ市場でのリーダーシップを確保。 🧐 投資戦略分析：その合理性は何か？\nNVIDIAのCEO、黄仁勋氏の戦略は非常に明確です。その投資の中心的なロジックは、単なる財務的リターンではなく、コアとなるチップビジネスにサービスを提供することであり、以下の3つの目標をまとめるとなります。\n1. 主要目標：「投資して、私のチップを買わせる」\nこれはNVIDIAにとって最も直接的な投資ロジックです。NVIDIAは、Poolsideのようなスタートアップに資金を注入し、これらの企業がその資金を使ってNVIDIAの高価なGB300や次世代GPUを購入します。これにより顧客をロックインするだけでなく、人工的に需要を作り出し、「互恵互利」の関係を持つビジネスサイクルを形成しています。\n2. 戦略目標：「CUDAエコシステムの城壁を築く」\nNVIDIAの真の城壁は、そのCUDAソフトウェアプラットフォームです。AIエコスのあらゆるレベル（ロボット、バイオメディカル、自動運転、AIプログラミング）に資金を投じていることで、NVIDIAはこれらの将来有望な企業が設立当初からCUDAプラットフォームに基づいて開発することを保証します。これにより、競合他社（AMD、Intel）のハードウェアが性能面で追いついても、ソフトウェアエコシステム上でNVIDIAの地位を揺るがすことはできません。\n3. 拡大目標：「チップで新たなセクターを占領する」\nNVIDIAは、その5兆ドル規模の評価額を支える次の「AIトレンド」を探し続ける必要があります。ノキア（6G）への投資は、AIチップを巨大な通信インフラ市場に押し出すものであり、Figure AI（ロボット）への投資は、「身体化された知能」がクラウドコンピューティングの後に続く次なる計算リソース消費大国になるという賭けです。\n要約：寡占下の「陽謀」 米国の株式市場における前例のない集中化は、AI革命が生産性を飛躍的に向上させることの表れである一方、巨大なバブルのリスクを孕んでいる。NVIDIAとOpenAIの数十億ドル規模の「閉環」協力体制は、この豪賭の縮図だ。\nNVIDIAの投資戦略は、洗練された「陽謀」であり、その強力な資本力を背景に、単なるAI時代の「軍需商」にとどまらず、「銀行家」と「ルール策定者」となることで、未来へのすべての道がNVIDIAのチップで舗装されるように仕向けるというのだ。この戦略は商業的には極めて合理的かつ効率的だが、同時に巨額の反トラスト圧力と潜在的な金融リスクを抱えることになる。\n投資家にとって、AI駆動による巨大企業の主導下、資本閉環によって強化されていくゲームを看破することは、現在の市場を理解するための鍵となるだろう。\n","date":"2025-11-03","language":"ja","permalink":"https://ttf248.life/ja/p/big-tech-dominance-in-the-us-stock-market-intensifies-the-top-10-companies-account-for-40-of-market-capitalization-is-ai-a-bubble-or-a-revolution/","tags":["AI霊感衝突坊","ニューヨーク証券取引所（NYSE）/ 株式市場","市場集中度","AIバブル (AIBaburu)","NVIDIA","OpenAI","投資 (tōshi)","技術革新 (Gijutsu ketsu hin)"],"title":"米国の株式市場における「巨大企業」の寡占化が深刻化の一途を辿る：上位10社の企業が市場価値の40％を占拠、AIはバブルか革命か？","year":"2025"},{"categories":["魚の7秒間の見聞"],"content":" 大量のデータの普及を否定することはできません。最近、大会のニュースを見つけるたびにクリックして確認し、抖音のような類似動画はすでに積極的に興味のないものをクリックして、同質的なコンテンツが継続的に配信されるのを防ぎます。また、以前利用していたアカウントがありましたが、予想通り、周天 TES があっという間に負け、関連トピックも知乎の熱トレンドにランクインしていました。高評価を得ている回答では、LPL に韓国人選手が導入され、「全華班」という概念が提起されました。 2018年の IG の優勝がないと、英雄聯盟はほぼ確実に衰退しています。ldl の賭博、複数のディバフの重ね合わせにより、LPL 地区の結果が生み出されました。 記事の作成：中国の英雄リーグ（LPL）に韓国人選手を導入する理由とは？コーチ陣から選手まで導入が行われていますが、これはローカル選手の育成を制限しているのでしょうか。そして、国内では全華班による優勝を望むのは、単なる人間の執念なのでしょうか。\nS4赛季末，“韓援大潮”涌入LCK以来，韓國選手和教練便成為這個賽區不可或缺的一部分。從S8的iG（Rookie, TheShy）、S9的FPX（Doinb, GimGoon），到S11的EDG（Scout, Viper），LCK三次捧起全球總決賽（S賽）冠軍獎杯，無一例外都有韓援的核心貢獻。\n然而，同時，一個響亮的口號始終貫穿著LCK的輿論場——“全華班”。觀眾們一方面為LCK的冠軍喝彩，另一方面又對“全華班奪冠”抱有近乎執念的期待。\n為什麼LCK要引入韓援？這是否限制了本土選手的發展？而“全華班”的執念，究竟源自何處？\n韓国の導入を促す理由：追随者からリーダーへの「触媒」 LPLが韓国からの援用（K-援）を導入した当初の動機は非常に純粋で、それは勝利のためでした。\nS3、S4時代において、LCK（韓国リーグ）はその無敵の運営と比類なき個人能力によって《英雄聯盟》プロジェクトを支配していました。LPLは挑戦者として、最も迅速かつ直接的な「模倣」の方法は、トップレベルの選手やコーチを招入れて「先生」にすることでした。\n1. 戦力ニーズと成績保証\nS4で三星白、三星藍が解体され、大量の韓国トップレベルの選手がLPLに流入しました。彼らは当時の最先端のゲーム理解と最高峰の操作スキルを持っていました。Rookie、Doinb、Pawn、Mataといった選手の加入により、LAN、WE、EDGなどのチームの上限が急速に向上しました。クラブにとって、これは成績を追求する必然的なビジネス選択でした。\n2. 先進した「eスポーツ産業システム」の導入\nLPLに導入されたのは選手だけではありません。コーチ陣やその裏側のトレーニング体系も含まれていました。韓国のeスポーツは、厳格な規律、データ化、高強度なトレーニングモデルで知られていました。Kkoma、DanDyといったコーチの加入により、LCKの管理経験と戦術的知識がLPLに導入され、LPLのクラブを「インターネットカフェ式」の管理から「プロフェッショナル」な管理へと転換させるように促しました。\n3. 「カジキマグロ効果」：内部競争の活性化\nトップレベルの韓国からの援用は、池にカジキマグロを入れるようなものでした。国内選手が自分のスターティングポジションを維持するために、より速く成長し、より高い強度な対抗戦に適応しなければなりませんでした。この視点から見ると、K-援（TheShy, Rookieなど）は単なる「外援」ではなく、国内選手（JackeyLove, Ming, Knightなど）の「上級パフォーマー」や「チームメイトコーチ」として、全体的にLPLリーグの平均レベルを向上させました。\n両刃の剣：韓援は「制限」か「促進」か？ これはLPL历史上最具争议性的话题であり、答えは**「兼而有之」**である。\n「制限論」の观点：\n生存空間を擠占した： 最も直接的な影響だ。LPLのトップチームが、中単（ミッドレーン）、上単（アッパーレーン）などのキーC位に韓国選手を優先的に配置する習慣（例えば、「中単は韓国語で話さなければならない」というジョーク）により、本土有潜力の新人が登场機会を得ることが困難になった。一つのポジションには1人しか出場できないため、韓国選手の優先順位が一部の本土天才の成長経路を「扼杀」（絞殺）する程度に影響を与えた。 コミュニケーションコストと戦術の一本化： 早期の「三带二」模式（3名中国選手が2名の韓国選手をサポートする）は、コミュニケーション不畅を引き起こしやすかった。チームの戦術スタイルは、韓国選手の習慣に合わせるために単一化されやすく、「LUP」（本土）選手のような「敢打敢拼」（大胆な攻撃と積極的なプレイ）のLPL式スタイルが欠如することがあった。 「促進論」の观点：\n本土選手の「下限」と「上限」を向上させた： LPLの本土選手（Tian, Ming, Knightなど）は、Rookie, Doinb, Ruler, Viperといった選手と日々交流し、共に競技することで成長してきた。彼らがS赛（世界選手権）で対戦する相手は、日常的なトレーニングマッチのチームメイトよりも強力な場合もあった。このような高強度の内部対抗は、LPL本土人材（特にサポーターとキャリーポジション）の爆発式台頭の重要な原因となった。 LPLの「造血」能力が世界第一になった： 事実は、LPLは現在、世界最大かつ最も完善な育成システム（LDL）を持っている。LPLには「人」が不足しているのではなく、「塔尖」（レーン最前線）のトップ選手が不足していた。韓国選手の導入は、まさにこの「塔尖」を完成させるための最後のピースだった。さらに、LPLの「同化」能力は非常に強く、RookieとDoinbは最終的に「LPLの本土選手」となった。 全体として、LPLは韓国選手を導入することで、「空間」を犠牲にして「時間」を得た。それは、一部の本土選手の短期的な出場機会を牺牲したことだが、その代わりに、リーグ全体の競技レベルが飛躍的に向上し、3回の世界選手権を獲得し、最終的には自身の育成システムに反哺（フィードバック）された。\n“全華班”: 一種近乎偏執的本土榮耀情結 もし導入する援手が「理性」の競技選択であれば、「全華班」を追求することは「感性」の民族情結である。この欲求を単純に「執念」と分類するのは不十分で、その裏には深刻な文化と歴史的根源が存在する。\n1. 体育の本質は“国家/地区对抗”\n伝統的なスポーツ（例：オリンピック）やeスポーツのように、それが国際競技の舞台に上がると、自然と国家/地域の栄光の色を帯びる。“我（们）の人”が勝ったというアイデンティティを確認したいという欲求が、観客の試合視聴における快感の他に存在する。\n2. “我们自己也能赢”の终极证明\nLPLは「中韓結合」の方法で自身が優勝することを証明した。しかし、「全華班奪冠」は別の次元の物語である：それはLPLリーグの選手、コーチ、戦術から青訓体系に至るまで、あらゆる面での勝利を意味する。“外部からの力に頼らず、我々が自らの力で世界頂点に立つ”という究極の証明。\n3. 歷史的遗憾与RNGの“造神”\n“全華班”の執念は、RNG戦隊（特にUzi時代のRNG）の物語との深いつながりを持つ。“S8”、その全華班のRNGがMSIチャンピオンを獲得し、多くのLPL観客に「全華班S賽奪冠」最大の希望を示した。しかし、S8最終的に敗北したものの、「ほんのわずかな差”という後悔が、この執念をさらに強化した。\n4. 亚运会的催化\n2018年のジャカルタと2023年の杭州アジア競技大会，《英雄聯盟》プロジェクトではすべて“全華班”阵容が出場する必要があった。eスポーツと「為国争光」の伝統的な体育モデルが結合されることで、「全華班」は「ファンの期待」から「国家チームの基準」へと昇華し、観客が本土阵容への认同感をさらに深めた。\n結論：借力至正名 LPLへの韓国の援用は、その発展初期における急速な追随と「逆転劇」を実現するための必然的な戦略であり、この戦略はS8、S9、S11のチャンピオンシップ獲得杯によって絶対的に成功したことが証明されている。\n韓国の援用がLPLの発展を「制限」することなく、むしろ「カジノ効果」と「内部指導」を通じて、LPLの国内人材育成を飛躍的に加速させ、現在公認される第一リージョンとしてLPLを確立した。\n一方、「全華班」（全中国チーム）への固執は、排他的な外国人拒否主義ではなく、本土自信が頂点に達した後における「究極の栄光」への渇望を表している。これは、LPL観客がこのリージョンが「外援への依存」から「自給自足と頂点」へと至る完璧なサイクルを達成することを願うことを意味する。\nLPLの物語は、グローバル化と本土化が交錯した縮図である。RulerやScoutが生み出す究極的操作を享受する一方で、2018年のRNGと2023年のアジア競技大会代表チームの「全華班」に感動を呼ぶこともあり得る。これは矛盾ではなく、このリージョンが「学生」から「大师」（名人）へと成長する道筋において、異なる段階で異なる追求をしているだけなのだ。\n","date":"2025-11-03","language":"ja","permalink":"https://ttf248.life/ja/p/lpls-korean-invaders-and-the-all-chinese-squad-dream-a-game-about-results-development-and-belonging/","tags":["ゲーム","韓国","LPL","韓国語 (韓国人)","全華班 (Zen'ika Ban)","LOL","eスポーツ (ēsupōtsu)"],"title":"LPLへの韓国人補強と「中国全盛班」の夢：成績、発展、帰属に関する駆け引き","year":"2025"},{"categories":["メモ書き雑感"],"content":"昨日の試合を観戦した後、心の中に残る「言葉を尽くせない」感情が、長くなかなか晴れなかった。偶然、あるネットユーザーの文章に遭遇し、深く共感した。「彼は小学生の頃からこのスポーツと縁を結び、私は大学になって初めて接触した」と。\n筆を執りかける際、私の脳裏には五岳を制する「絶代双骄」である林丹と李宗偉が浮かぶ。そしてFakerは、eスポーツ界の「不老松」あるいは「常青樹」であり、才能と極限の自律性が完璧に融合した典範だ。\n彼は敗北も経験したが、それはLPLに負けなかったこと。友人から、「どのチームのファンではないのか？」と聞かれ、そうではない。「国内教育体系による育成、国内チームへの支持は当然のこと。特定の選手やチームのファンではなく、中国代表の質の高い試合を見るのが好きだ」と答えた。\n解説家が感情を大きく煽ることは、観客の感情を増幅させる大きな要因である。彼らが試合の断片を強調することで、その「言葉を尽くせない」感情は数倍に放大されるのだ。\n转载 抖音で目に付いた記事の元のリンクを貼り付けられませんでした。 S3から、その当時六年級で始めた英雄聯盟です。家には良いパソコンがなく、勉強に影響が出ると感じたため、その後も少しずつプレイしていました。段位は常に真金白銀でした。しかし試合を見ることも断片的に見ていました。当時、小小的老子熱泪盈眶（こまごま模様のオコジが涙を流して感動した）という動画は本当に感動しました。また、あの年の皇族OMG（ワンズーのチャンピオンを奪ったチーム）、デビュー直後のファーカーの姿も忘れられません。意気揚々としたファーカーが簡単に2つのチームを倒していました。その後、三星ブルー白戦（サムスンとブルー、そしてホワイトの対戦）という両セクターの断層は埋められないものでした。\n大学に進学して、兵役に行く前にもずっと英雄聯盟に執着していました。インターネットで大小さまざまな動画を探し、高手（熟練者）になることを目指しました。しかし他の大小さまざまなことで気を取られることもありました。それでも、IGが優勝した夜、私は早朝に切片（切り抜き）の動画を見て涙を流しました。LPL（中国プロリーグ）には本当に希望があるのでしょうかと確信しました。兵役中の間もファーカーが優勝したことを聞きました。その時は状況が特殊だったため、あまり関心を持っていませんでした。正直なところ、EDGが優勝した年に私は特に驚きませんでしたが、全華班（中国の選手のみで構成されたチーム）で優勝するのは一度限りのことであり、本当に優勝できるのか疑問に思っていました。昙花一現のRNG（ランダムナガリング）は、その年すべての試合を勝利しましたが、最も重要な1試合で敗れ、ファーカーが5連勝のカリオでウージのチャンピオン夢を打ち砕いたことを、何人もが心痛にして退坑（ゲームから引退する）しました。\n退伍してからも毎年試合を観戦し続け、常に抜けていくファーカーでした。考研（大学入学試験）の頃のWBG、昨年のBLG、そして今日の八強ALを見て、ファーカーがメーラーで斬殺（敵を切り伏せる）をしてエタ汗（エタのチャンピオン）を奪うと、もうダメだと思いました。正直なところ、私は見ていて本当に辛かったです。英雄聯盟というゲームには、私は本当に感情移入していました。自分がどのキャラクターをプレイしているか asideから、大小さまざまな主要キャラクターの背景ストーリーは全て知っています。LPL、LCK（韓国プロリーグ）のチームの物語も知っていました。\nああ、LPLはこのセクターの風潮と実力差はLCKに比べて明らかに違うので、本当に全華班が優勝するのを願っています。王多多の一節を引用して締めくくりたいです。「也许有一天，我们会对英雄联盟的电子竞技失去信心，因为韩国的宰治在今天还在继续…」（いつか、私たちは英雄聯盟のeスポーツに自信を失うかもしれません。なぜなら、韓国の宰治は今日でも続いているから…）　私は全華班が優勝するという夢を、これからも持ち続けたいです。それは、私たちが生活で抱く些細な幻想と同じように。\n","date":"2025-11-01","language":"ja","permalink":"https://ttf248.life/ja/p/what-is-regret-in-olympic-games/","tags":["後悔 (こうかい)","LOL","青春 (Seishun)"],"title":"後悔とは何ですか？","year":"2025"},{"categories":["投資 (tōshi)"],"content":"現地の操作は一切行わず、来月の財務報告を待機しております。午後は休憩のため半日休業し、特に予定もなく、ただゆっくりしたい気分です。\n歳月 しばらくLoLの試合ライブを観ていませんでした。時が経つのは本当に早く、気づけば3～4年が経っていました。 過去のゲーム関連の記事で触れていたように、LPL（国内リーグ）のチームに対しては、複雑な感情があります。多くの選手が大舞台で頻繁に起こる低レベルなミスは、本来あるべきプロ意識がないように感じさせ、試合の見応えも大きく損なわれます。これが徐々に疎遠になっていく原因です。 今日は午後、突然思い立ち、半日休んで家に帰って片付けをしました。夏の服はまだ片付いていませんが、試合を見てみることにしました。準決勝ではT1が健在。LPLチームの前で、越えられない壁のような存在です。過去を振り返ると、LPLはSシリーズのBo5（5ゲーム制）の重要な対決で彼らを相手にまだ勝利したことがなく、どのチームも彼らと対戦すると大きなプレッシャーを感じます。 これらの文字を書いている今、試合がまさに「クラシック」な第5局に入っています。LPLチームが2-1でリードしているという好位置から相手に追いつかされ、両チームは残酷な最終決着ゲームへと突入しようとしています。\n投稿前に更新します。操作には特に問題はありませんでしたが、BP（戦術）の思路は完全に押しつぶされました。女皇コンビが原因で金克斯が序盤のレーンで兵舎を十分に稼げず、打野猪妹は梅尔によって直接的に妨害され、猪妹はチームファイトに参加することができませんでした。本当に苦しい状況でした。\n振り返り（ふれぶり） 美团（めいたん）：安定したパフォーマンスで、大きな変動はありませんでした。期間中には一時的に上昇しました。 小米（きみあい）：今回の下落は、複数の悪材料が重なり合った結果です。\nマクロ的な拖累（たろうてきなつれう）：香港株式市場のテクノロジーセクター全体が下落（例えば、ネット易（ネッツイ）、アリババ（アリババ）、テンセント（テンセント）も不調）。 自動車期待（しんるょうきたい）：新エネルギー車（しんでれいぎーしゃ）市場における“内戦”（ないせん）が激化し、市場は（例えば、比亚迪（ビアディ）などの）成長予想がピークに達していること、小米汽車（きみかいしゃ）の将来的なスペースもそれに伴って圧迫されています。 業界観察（いぎょうかんさ）： 瑞銀（ずいえん）の決算前瞻（けつざんぜんてい）では、ソリッドステートドライブ（SSD）とメモリ（メモリ）の値上げ傾向が言及されました。このコスト上昇が携帯電話ビジネスの利益をどれだけ侵食するかは、決算報告で明らかになります。 しかし、一つ確実なことは：“内戦”がこれほど激しい市場において、Androidスマートフォン（アンドロイドしょうまほう）陣営は価格を自由に引き上げられる根拠がありません。 口コミ反噬（ことろくはんせい）： そして、小米自身に戻りますと、その自動車事業（しんるょうぎょうせき）は評判の問題に直面しています。プロジェクトの初期プロモーションの声量は非常に大きく、ほとんど否定的な意見はありませんでした。しかし、現在では、過度な露出後の世論による“反噬”（はんせい）を迎えているようです。 ","date":"2025-10-31","language":"ja","permalink":"https://ttf248.life/ja/p/vacation-watching-games-when-t1-becomes-an-impenetrable-mountain-for-the-lpl-what-macro-industry-negative-factors-does-xiaomi-face-again/","tags":["小米 (Xiǎomǐ)","恒生指数 (こうせいしじょ)","ゲーム","LOL","振り返り記録"],"title":"休暇で試合を観戦：T1がLPLの難攻不落の大山となり、Xiaomiはどのような「マクロ＋業界」の悪材料に直面するのか？","year":"2025"},{"categories":["コンピューター"],"content":"ローカルのWindowsシステムインストールパッケージを更新したところ、25H2バージョンがリリースされていることがわかりました。しかし、ローカルのシステムはまだ24H2バージョンに留まっており、Microsoftのアップデートパッチもインストールされていますが、ローカルのシステムが25H2バージョンにアップグレードされていません。その間に何が足りないのか気になりました。 この記事では、Microsoftの公式サポートドキュメントに基づいて、KB5054156アップデートのコア情報を整理し、Windows 11 24H2から25H2へのアップグレードにおける重要なポイントをユーザーに理解させることを目的としています。\n更新概要 KB5054156は、Windows 11 バージョン 25H2向けの機能アップデートであり、主な目的は「パッケージを有効にする」ことで 25H2 の新機能を起動することです。その本質は、Windows 11 24H2 と 25H2 が「共通コアシステム」を共有するという特性を利用しており、25H2 の新機能が 24H2 の最新月度品質更新に含まれていますが、休眠状態にあり、「パッケージを有効にする」ことでこれらの機能を「メインスイッチ」として起動することです。\n対象範囲 本更新は、Windows 11 バージョン 24H2を実行しているデバイスのみをサポートしています。具体的なバージョンは以下のとおりです。\nWindows 11 Enterprise および Education, バージョン 24H2 Windows 11 Enterprise Multi-Session, バージョン 24H2 Windows 11 Home および Pro, バージョン 24H2 Windows 11 IoT Enterprise, バージョン 24H2 エンベージ（Enable Package）のコアなメリット 従来の機能アップデートと比較して、エンベージの核心的な価値はアップデートによるダウンタイムを削減することにあります：\n複雑なダウンロードとインストール手順が不要で、24H2から25H2へのアップグレードを完了するためにデバイスのみ再起動するだけで済みます。 アップグレード後、デバイスはすぐに25H2バージョンの新機能を使用できるようになり、完全なシステムアップデートを待つ必要はありません。 更新取得方法 KB5054156は、以下の3つのチャネルを通じてリリースされます。各チャネルの可用性と手順は次のとおりです。\n| Windows Update | 利用可能 | 自動ダウンロードおよびインストール。機能更新は「Windows 11, バージョン 25H2」として表示され、手動でのトリガーは不要 |\n更新取得方法 配信チャネル 利用可能 次のステップ Windows 更新カタログ 利用不可 なし、この更新はWindows UpdateおよびWSUSチャネルを通じてのみ取得できます 更新取得方法 发布渠道 可用性 次の操作 Windows Server Update Services (WSUS) 利用可能 以下のパラメータを設定して自動同期を実施する必要があります：\n1. 製品：Windows 11\n2. 分類：アップグレード\n更新名を「Windows 11、バージョン 25H2」に変更してください アップグレードの前提条件 KB5054156 のアップデートを適用する前に、次の 2 つの条件を満たす必要があります。\n現在実行しているシステムバージョンが Windows 11 バージョン 24H2 であること（より低いバージョンからの直接アップグレードはサポートされません）。 2025年8月29日にリリースされた KB5064081 の累積更新をインストール済みであること (OS 内蔵バージョン 26100.5074、プレビュー版およびそれ以降のバージョンを含む)。 再起動と更新の代替手順 再起動の要件: KB5054156 の更新後、25H2 機能の有効化には デバイスの再起動が必須です 。 更新の代替: この更新は、これまでにリリースされた Windows 更新を置き換えるものではありませんので、過去の更新ファイルを上書きすることについてご心配いりません。 参考資料 Microsoft公式ドキュメント：KB5054156：Windows 11 25H2 の機能アップデートを有効にする 用語集：Microsoft ソフトウェアアップデート標準用語解説 ","date":"2025-10-28","language":"ja","permalink":"https://ttf248.life/ja/p/kb5054156-windows-11-version-25h2-feature-update-package-deployment-guide/","tags":["windows","Windows 11","KB5054156","パッケージを有効にする","システム機能アップデート","25H2 バージョン"],"title":"KB5054156：Windows 11 バージョン 25H2 機能アップデート（パッチ適用ガイド - パッケージの使用方法）","year":"2025"},{"categories":["コンピューター"],"content":"私のデスクトップPCは、常年電源を入れっぱなしにしています。普段は、外出時や夜間など、使用していないときにモニターだけを消す程度です。\n🚨 故障現象 定期的な操作を行った後、ディスプレイが常に黒い状態になっていることを確認しました。 ディスプレイの電源を切り直す（リブート）を試みましたが、画面には \u0026ldquo;信号入力なし\u0026rdquo; と表示されました。 携帯電話で UU リモートコントロール を使用して確認したところ、デスクトップPCと別のミニPCが両方ともオンライン状態になっていることがわかりました。これは、ホスト自体がシャットダウンしていない可能性を示唆しています。 🛠️ 初步トラブルシューティング手順 「シグナルなし」の問題を解決するために、以下のことを試みました。\nDPデータケーブルの抜き差し を繰り返す。 HDMIケーブルへの切り替え を行う。 入力ソースをミニPCに切り替える (モニターが故障しているかテスト)。 🔍 結果と解決策 上記試行すべて問題の解決には至りませんでした。 私は抖音などのプラットフォームで検索し、断電を数分間行うことを推奨する提案を見つけましたが、何度も試した結果効果がありませんでした。 最終的な解決策： デスクトップPCの再起動を行う。再起動後、ディスプレイ信号が正常に回復し、問題が解決しました。\n","date":"2025-10-27","language":"ja","permalink":"https://ttf248.life/ja/p/computer-black-screen-troubleshooting-log/","tags":["トラブルシューティング","ディスプレイ","黒画面 (Kurogamae)","デスクトップパソコン"],"title":"💻 PCの黒い画面トラブルシューティング記録","year":"2025"},{"categories":["投資 (tōshi)"],"content":"月曜日はパニック売りが起こらなかったものの、一週間のうちに全体的に陰配が進み、まるで鈍刀で肉を切り取るように、徐々に一週間を通じて下落し続けた。\n規律取引 昨午新增的两手小米，原计划尾盘卖出。但当时尾盘略有亏损，便心生犹豫，不忍割肉，决定再观望一天。今天上午股价小幅下跌1%，到了下午跌幅扩大至2%时，我果断离场。事后证明，这次离场是正确的，股价随后仍在继续下探。\nAI分析のフォローアップアクション 数日前、ブログ界隈でAIを使って競馬予想をした人が二等賞を獲得し、税引後の約9千円の賞金を獲得したというニュースがありました。株式市場でも試してみようと思い、過去の大規模言語モデルの経験から、Deepseek が最も適していると考えました。他のモデルが出力する投資計画は、あまり見映えが良くありません。\n港元投資計画、現在手元には小米（シミー）を約10万保有しており、15%の損失を出しています。美团（ディードン）を7万保有しており、2万の損失を出しています。現在の株価を照会し、今後のポジション調整はどのように行うかです。私は長期投資を考えており、小米の購入理由は、yu9の上場、三期工場の爬坡（進捗）、販売実績が依然として高く、株価が上昇する可能性があるためです。美团は外食デリバリー市場の終焉後、安定的に成長できると期待しています。港元三季度の決算報告書は来月発表予定であり、決算が出次第操作を行う方が合理的であると考えます。私の長期投資（3～5年程度）を考慮し、私に投資計画を作成してください。\n港股投資計画：小米と美団のポジション分析と長期戦略 提供いただいた情報（小米は約10万香港ドルで15%損、美団は約7万香港ドルで約28.6%損、投資期間3年）に基づき、最新市場データと分析を整理し、詳細な投資計画をご提案いたします。以下は、総合検索結果の中核となる情報です：\n現在の株価（2025年10月17日時点）： 小米グループ-W (01810.HK)：45.88香港ドル（前日比3.82%下落、月内累積下落率超15%）。 美団-W (03690.HK)：94.50香港ドル（前日比4.30%下落、年間累積下落率37.71%）。 港股市場環境：恒生指数は2.48%下落、テクノロジー株がリードして下落、短期的な市場センチメントは疲弊しています。 あなたの買い入れる理由の検証： 小米：Yu9の上場、第3期工場での爬坡、販売台数の潜在力は合理的な長期ロジックですが、短期的に成都SU7事故の影響を受けて株価が押し下げられています（ドアの安全問題、規制当局の介入）。 美団：外食戦いが終結後の安定化が長期的な鍵となりますが、現在の競争は依然として激化しており（京东、アリババが巻き込まれる）、第2四半期の純利益が89%も暴落し、王興氏の“どんな代償を払っても”という表明が市場の懸念をさらに強めています。 ポジション管理の推奨事項：短期は慎重、長期は基本面に集中 現在のポートフォリオ全体が約18.8%の損失（合計ポートフォリオ17万香港ドル、約3.74万香港ドル相当）となっていますが、長期投資においては感情的な取引を避ける必要があります。以下に段階別の推奨事項を示します：\n| 決算前（短期：現在から11月決算発表まで） | 現状のポジションを維持し、追加購入は行わない。SU7事故調査の進捗状況とQ3自動車納車数データを注視する。 | 現状のポジションを維持し、追加購入は行わない。重点的に監視するのはQ3の外卖UE（平均注文単価）が改善するかどうか。 | 決算前の株価は変動しやすい可能性がある：\n• 小米は安全事故の影響で短期的な反発は難しい。\n• 美团外卖の競争は依然として続いており、収益回復には時間がかかる。 |\nポジションコントロールの推奨：短期は慎重、長期はバロメーター重視 取引周期 小米戦略 美団戦略 主要根拠 決算後（中期：11月～2026Q1） 決算で自動車販売台数が緩やかに増加し、スマートフォン粗利率が底打ちして回復した場合、5%～10%の買い増しを検討。 決算で競争緩和を確認し、損失が縮小した場合、5%～10%の買い増しを検討。それ以外の場合は現在のポジションを維持。 • 小米は2025年の販売目標を35万台に設定しており、スマートフォン高付加価値化が利益の鍵。\n• 美団のSOTP評価により121%の上昇余地が見られるものの、収益転換点が必要。 ポジション管理の推奨：短期は慎重、長期はファンダメンタルズに集中 取引期間 小米戦略 美団戦略 主要根拠 長期（3年） 核心ポジションを保持し、目標価格75香港ドル（潜在的な上昇幅63%）。リスク要因：自動車安全規制、スマートフォン需要の減速。 核心ポジションを保持し、目標価格247香港ドル（潜在的な上昇幅161%）。リスク要因：政策コストの上昇、新規事業の赤字。 • 小米の車・家庭エコシステムの閉環は長期的なエンジン。\n• 美団の即時小売セグメントの浸透率が向上すると予想。 位置制御推奨：短期慎重、長期基本面に集中 決算後に操作するか？ はい、3四半期決算（11月発表）を待ってから買い増し判断をすることを推奨します。理由：\n決算はあなたの買い入れロジックを検証します：小米の工場爬坡销量（積み上げ販売）、美団の競争緩和の証拠。 決算が予想に欠ける場合、株価は下落する可能性があり、より良い買い増しポイントを提供します。予想を上回る場合は、右側のシグナルを確認できます。 短期の市場センチメントはイベントドリブン（小米事故、外食価格戦など）の影響を受けやすく、決算が不確実性を軽減します。 長期投資計画（3年視点） 「高品質資産の保有＋低迷時にポジションを組む」原則に基づき、あなたの計画は以下のように詳細化できます：\n小米グループ：攻守兼備、自動車事業の転換点を注視 主要機会：自動車事業における規模効果（目標35万辆年間販売台数）、AIoTエコシステムの協調。財務健全性（Z-Score=4.19、破産リスク低）。 リスクへの対応： SU7の安全問題が継続的に拡散した場合、株価は40～42香港元区间に下落する可能性があり、買い増しラインを設定（下落10%でポジションを5%拡大）。 長期保有底線：自動車四半期販売量が8万辆以上で安定。 ポジション比率：推奨される維持比率は40～50％の総ポートフォリオにおける比重（現在約59％が高すぎ、レポート後に調整）。 美团-W：収益回復を待つ、コアビジネスに集中 主要機会：デリバリー市場シェアの安定（65%）、スナック業務の成長40%、評価額の低さ（SOTP目標価格247香港元）。 リスクへの対応： デリバリーのUE（平均売上高）が収益化した場合、買い増しのシグナル；競争激化の場合、株価は80香港元に下落する可能性があり、段階的に補填投資を行う。 長期保有底線：コアローカルビジネスの運営利益率が15%以上に戻る。 ポジション比率：推奨される維持比率は30～40％（現在約41％で合理的だが、競争の影響に警戒する必要がある）。 分散投資の提案 港股テクノロジー株は最近圧力を受けているが、長期的に新質生産力代表。通信事業者などの高配当資産への10～20%の資金を投資し、単一株式のリスクをヘッジすることを検討する。 主要監視指標とタイムマイル タイムマイル 小米の注目点 美団の注目点 操作指針 2025年11月 Q3業績報告書：自動車納車台数、スマートフォン粗利率トレンド Q3業績報告書：配達UE改善、新規事業損失率 業績目標達成なら増配、そうでなければ建玉を維持。 主要監視指標とタイムマイル タイムマイル 小米の注視点 美団の注視点 操作指針 2026年Q1 吉林省における新車種の走行試験進捗、ハイエンドスマートフォンの販売実績 外卖补贴の削減力度、闪购の収益転換点 年度の目標達成度を評価し、在庫戦略を見直す。 主要監視指標とタイムマイル タイムマイル 小米の注目点 美団の注目点 操作指針 長期（3年） 自動車事業の損益分岐、AIoT浸透率 即時小売市場シェア、政策コスト消化 目標価格まで保有するか、基本面が悪化した場合に減持。 主要監視指標とタイムマイル 提炼建議 立即行動：現状維持、避免在财報前盲目補倉。當前股價已部分反映利空，但財報前波動可能放大。 長期信心支撐： 小米汽車的生態系統和手機高端化是核心邏輯，短期事故不改變長期技術迭代能力。 美團一旦外賣戰結束，盈利彈性巨大（參考阿里隔岸觀火受益）。 風險提示：港股整體受全球流動性影響大，若美聯儲推遲降息，可能壓制科技股估值。務必確保投資資金為長期閒置資金。 本計畫基於公開資訊，不構成投資建議。市場有風險，決策需謹慎。建議透過定期複盤（如每季度）調整策略。\n要点まとめ 決算を待ってから買い増しするのは時期尚早かもしれません。その場合、株価が大幅に上昇した場合どうなるか\n提言要点まとめ ご提示いただいた問題は非常に重要であり、長期投資家が長年直面している典型的なジレンマを突いています：短期リスク（決算発表まで待つ）と、最適なコスト（割高掴まれないこと）を追求することの間に矛盾が生じます。 「決算発表後に買い増しした場合、株価が急騰して機会を逃すのではないか」という懸念は非常に妥当です。市場はしばしば先を見据え、もし決算内容が予想を大幅に上回れば、株価は短期間で急速に反応する可能性があります。しかしながら、現在保有されている2つの株式の具体的な状況下では、「決算発表まで待つ」戦略が依然として最適であると考えます。以下にその理由を詳細に説明し、リスクと機会をバランスさせるための段階的な買い増し戦略をご提案します。\nなぜ「決算を待つ」という選択が、現状ではより合理的なのか？ その根拠は次のとおりです。現在保有している2つの株式が抱える不確実性は、主にその基本面の核心的な矛盾に起因しており、決算発表こそがこれらの矛盾を検証する鍵となるからです。 現状の株価を押し上げる「触媒」となるような状況がまだ生まれていないためです。\n小米の場合：核心的な矛盾は「自動車事業への信頼危機」\n現状: SU7の安全事故によるネガティブな影響が波及しており、市場は小米自動車の品質、評判、そして将来の販売実績に対する疑問を抱いています。これは株価を押し下げる最大の要因です。 決算発表による検証効果: 3四半期決算では、自動車の納車台数データが重要な指標となります。もし納車台数が依然として好調であれば、市場の懸念を打ち消し、株価に持続的な上昇をもたらすことができます。しかし、その前には、どのような反騰も脆弱である可能性があります。 リスクと機会の比較: 待つことのリスク（割安を逃す）: 決算発表前に、ネガティブなセンチメントが依然として支配下にある状況では、株価の大幅かつ継続的な上昇の可能性は低いと考えられます。 盲目的に買うことのリスク（損失を拡大する）: もし決算で自動車販売台数が伸び悩むことが示されれば、株価はさらに下落する可能性があり、「半ばで買い付けを終えれば後悔する」というリスクを大きく招きます。 美团の場合：核心的な矛盾は「収益性の回復時期」\n現状: 激しい競争がコアなデリバリー業務の利益（UE）を継続的に侵食しているという懸念があります。 決算発表による検証効果: 決算書に記載されているコアローカルビジネスの経営利益と調整後純利益は、まさに「外食戦争が本当に緩和されたのか」を客観的に判断するための唯一の基準となります。データ改善こそが、王興氏の「代償を恐れない」という段階が終わったことを証明するでしょう。 リスクと機会の比較: 待つことのリスク（割安を逃す）: 同様に、収益回復の兆しが見えなければ、株価に大幅な反騰の根拠はありません。 盲目的に買うことのリスク（損失を拡大する）: もし決算で競争激化により利益がさらに悪化すれば、「バリュートラップ」への懸念が高まり、株価はさらに下落する可能性があります。 結論: 長期投資においては、「正しい」タイミングで購入する方が、「安い」価格で購入するよりも重要です。決算発表は、その「正しさ」を判断するための重要な根拠を提供します。小さな「割安を逃す」可能性を回避するために、「深刻な損失を招く」リスクを負うのは合理的ではありません。\n具体操作計画：待機と無謀な行動への不安を解消する 「全面投資」と「完全撤退」のどちらにも固執する必要はありません。より賢明な戦略は**「底仓観測、金字塔式増資」**です。\n第一段階：観察倉庫と操作規律の確立（現在）\n既存のポジションを底仓として維持し、市場から完全に離脱しないようにします。 増資のトリガー条件を設定します。例えば： 小米 (Xiaomi)：出来高を伴い、重要な技術水準を突破するか、SU7に関する明確なポジティブ調査結果が出た場合。 美团 (Meituan)：競合他社が価格競争から撤退するニュースが出たか、株価が100港元整数値を突破した場合。 この方法の利点：もし財務報告前に強力なポジティブ要因によって株価が先行的に上昇した場合、あらかじめ設定した規律に基づいて機会を捉え、完全に踏み越えることを防ぐことができます。 第二段階：財務報告前の小額定投式試行（任意 - より滑らかなコストを求める投資家向け）\n踏み越えるのを極度に恐れる場合、増資計画に使用する資金を10～20分割します。 財務報告前に株価が継続的に下落している場合、毎週または隔週で1単位の資金を投入します。この方法はコストをわずかに分散させますが、投資額は非常に小さいため、財務報告がネガティブな場合でも損失を抑えることができます。 第三段階：財務報告後の確実な増資（主要な操作）\nこれは計画における主な増資段階です。財務報告の結果に基づいて、以下の3つの対応を行います。 シナリオA（予想を大幅に上回る）：財務報告データが強靭で、投資論理を検証します。この場合、積極的に増資する必要があります。株価がすでに上昇している場合でも、基本面が転換点を確認し、長期的に見ると現在の価格は山の麓であることを示しています。追証（追隨上昇）ではなく、段階的に買い増しすることができます。 シナリオB（予想に合致する）：財務報告が中立的で、驚きもショックもない。既存のポジションを維持するか、わずかに増資し、次の四半期の信号を待ちます。 シナリオC（予想を下回る）：財務報告が市場の懸念を裏付けています。増資を停止し、長期的な論理が破壊されていないか再評価します。株価は下落する可能性がありますが、これはより低い、より安全な増資価格を提供することになります。 結論：あなたの長期投資計画（最適化版） 段階 操作戦略 核心目標 決算前（現在～11月） 「底仓观望」：既存のポジションを維持し、増配や追加の投資は行わない。または、わずかな定額投資に留める。好機発生時に増強するためのトリガーを設定する。 リスク管理、元本維持。基本面が悪化した場合に追加投資を防ぐ。 結論：長期投資計画の最適化版 段階 操作戦略 核心目標 決算後（11月中下旬） 「勢いに乗り」：決算結果に基づいて判断。予想を上回れば積極的に買い増し；予想を下回れば待つ。 意思決定の質を高める。基本面が確実性の高い方向に資金を投入する。 結論：あなたの長期投資計画の最適化版 段階 操作戦略 核心目標 長期（3年） 「保有と最適化」：小米のエコシステム、美団のリテールといった企業の長期競争力に焦点を当て、短期株価変動に惑わされない。 複利成長を実現。 結論：あなたの長期投資計画（最適化版） 最後に覚えておくこと：長期投資においては、忍耐は強力な競争力です。市場は常にチャンスを与えてくれます。見逃すと、次のものがあります。しかし、本เงินが失われたら、戻ってくるのは難しいでしょう。財務諸表の確定性を待つことは、本เงินを保護し、勝率を高める最も効果的な手段の一つです。\nこの詳細な計画があなたの疑問を解消し、より落ち着いた意思決定を支援することを願っています。\n","date":"2025-10-17","language":"ja","permalink":"https://ttf248.life/ja/p/attempt-ai-analysis-of-subsequent-holdings-operations/","tags":["振り返り記録","deepseek","小米 (Xiǎomǐ)","美团 (Meituan)","恒生指数 (こうせいしじょ)","投資 (tōshi)"],"title":"AIによるポートフォリオの以降取引を試行する。 (AI ni yoru pōtofiolio no ikueki torikimu o shitoryū suru.)","year":"2025"},{"categories":["金融知識データベース"],"content":"成熟市場（米国株式など）における終値（Closing Price）は、重要な参照価値を持ちます。それは単にその日の取引感情のまとめであるだけでなく、多くの指数計算、基金純資産評価、投資ポートフォリオ評価の基準でもあります。そのため、終値に対する取引需要が生まれました。盈透证券（Interactive Brokers, IB）の取引プラットフォームでは、MOC（Market-on-Close、市況終値） と LOC（Limit-on-Close、限際終値） は、投資家が終了時間帯に取引を実行するための重要な注文タイプです。\nこれらの注文の中心的な目標は、公式の終値またはそれに近い価格で取引することですが、実行の確実性と価格コントロールの面で本質的な違いがあり、異なる取引戦略とリスク許容度に適しています。\nMOC (Market-on-Close) 終集約委託 コアな特徴： 成交の保証、価格の保証ではない MOC 委託は市況注文の一種であり、唯一の目的は市場の終集約期間（Closing Auction）において、取引所の公募価格（または終集約期間中の集合競落価格）で取引を実行することです。 動作原理： MOC の買い付けまたは売り付け注文を提出すると、その注文はシステムに保持され、取引所の終集約期間（Closing Auction）の終了まで待ちます。その後、その注文は他の希望する終集約期間中の取引注文（MOC および LOC 注文を含む）と組み合わさり、最終的に形成された単一の終集約価格で取引が成立します。 利点：\n実行の確度極めて高い: 市場が正常に取引を行っている限り、MOC 委託はほぼ確実に実行されます。これは、指数ファンドマネージャーが指数を追跡するために行うリバランスや、その日のうちにポジションを決済する必要があるトレーダーなど、その日のうちに建玉または決済を行う必要がある取引者にとって非常に重要です。 リスク： 価格のコントロール不可: 最終的な終集約価格は予測できません。市場が大きく変動したり、終集約期間中に大量の買い注文と売り注文の不均衡が生じたりした場合、最終的な終集約価格は注文時の市場価格から大幅に乖離し、予想よりも高いコストで取引（買い）または低い価格で売却（売り）される可能性があります。これは「スリッページ」リスクと呼ばれます。 適用シナリオ： 指数ファンドまたはETFのリバランス: 指数成分の終集約時の重み付け変動を正確に一致させる必要があり、確実に取引が成立する必要があります。 その日のうちに完了する必要がある取引: 例えば、追加控除通知（Margin Call）への対応やオプション権利行使日に伴う株式の買い付け・売り付けなどです。 価格精度よりも実行の確度を重視する戦略。 LOC (Limit-on-Close) 制限注文のクローズ コアな特徴：価格を保証、取引は保証しない LOC 注文は、限価格とクローズ注文の特徴を組み合わせたものです。希望する最高買い価格または最低売り価格を設定し、その価格に等価または上回る収束価格で注文が実行されるようにします。\n動作原理： LOC 注文を提出する際、限価格を指定する必要があります。収束価格の集合競売時に、システムは最終的に形成された公式収束価格とあなたの限価格を比較します。\n買い注文の場合: 収束価格があなたの限価格以下または等しい場合、注文は収束価格で実行されます。収束価格が限価格より高い場合、注文は実行されず自動キャンセルされます。 売り注文の場合: 収束価格があなたの限価格以上または等しい場合、注文は収束価格で実行されます。収束価格が限価格より低い場合、注文は実行されず自動キャンセルされます。 利点：\n価格コントロール: 限価格を設定することで、取引コストを効果的に制御し、不利な価格での取引を回避し、収束時間帯における大幅な価格変動のリスクを防ぐことができます。 リスク：\n実行の不確実性: 収束価格があなたの設定した限価格に触れない場合（つまり、あなたにとって不利な場合）、注文は実行されません。これにより、取引機会を逃し、期待する建値または清算操作を完了できなくなる可能性があります。 適用シナリオ：\n取引コストに敏感な投資家: 収束時間帯で取引を行いたいが、価格が大幅に変動するリスクを負いたくない場合に適しています。 機会型トレーダー: 収束価格が自分にとって有利になると考えていますが、予期せぬ事態を防ぐために価格の底値を設定します。 収束時間帯で取引を行いたいが、成否に厳密な要件がない投資家。 MOC vs. LOC の比較まとめ 特性 MOC (市場価格終値) LOC (限価格終値) 成約確度 高い (ほぼ確実に成約) 不確定 (終値価格が限価格より優れていれば、または等価であればのみ成約) MOC vs. LOC の比較まとめ 特性 MOC (市場価格終値) LOC (制限価格終値) 価格制御 なし (最終的な終値を受け入れる) あり (取引価格は、設定した制限価格を下回らない) MOC vs. LOC の比較まとめ 特性 MOC (市場価格終値) LOC (限価格終値) 主な利点 実行力、取引の完了を確実にする コスト管理、価格リスクの回避 MOC vs. LOC まとめ 特性 MOC (市場最終価格) LOC (限価格) 主なリスク 価格変動、取引コストが最適でない可能性 注文が執行されない可能性、取引機会を逃す可能性 IBプラットフォーム使用上の注意点 注文締め切り時間: MOCおよびLOCの注文は通常、市場休場時間の特定時刻前に提出する必要があります。例えば、ニューヨーク証取引所（NYSE）やNASDAQには、通常5〜15分前のような厳格な締め切りがあり、この時間を過ぎると注文を提出、修正、またはキャンセルできなくなります。関連する取引所の具体的な規則を確認し、遵守してください。 すべての株式がサポートされているわけではない: ほとんどの主要取引所上場株式はMOCおよびLOCの注文をサポートしていますが、流動性が低かったり、特定の取引所で取引されている証券には対応していない場合があります。 直接ルーティング: IBプラットフォームで注文を行う際、MOCまたはLOCオプションを使用するには、注文を適切な取引所（NYSE、ARCA、NASDAQなど）に直接ルーティングする必要がある場合があります。 結論 MOCとLOCの委託を選択することは、基本的に「実行の確実性」と「価格コントロール可能性」の間でトレードオフを行うことです。もしあなたの主な目標が、取引を市場休場時間に確実に完了させることであるなら、MOCが適切です。逆に、価格に気を配り、注文が最終的に成立しなくても良いという場合に、LOCは重要な価格保護を提供します。この2種類の委託タイプの違いを理解することで、より柔軟かつ正確にあなたの市場休場取引戦略を実行できるようになります。\n","date":"2025-10-15","language":"ja","permalink":"https://ttf248.life/ja/p/detailed-explanation-of-ibs-moc-and-loc-order-types-two-strategies-for-closing-price-trading/","tags":["ib","クローズエンド取引","MOC","LOC"],"title":"IB の MOC および LOC 委託タイプの、終値取引の2つの戦略について解説します。","year":"2025"},{"categories":["金融知識データベース"],"content":" 港株暗盤取引には、多くの専門用語があり、ほとんどが認識されているものの、一部はまだ馴染みがありません。 参照資料：全员抽签！轩竹生物-B(2575.HK)上市首日大涨127%，19万人选择摸一手\nこれは暗盤に関連する記事で、その中の専門用語を整理・解説します：本公司本次全球发行6733.35万股，招股价定价11.6港元。发行比例为13%，募集总额约7.81亿港元，采用机制B分配方式，公开发售固定占比10%。国配部分引入了1家基石投资者，认购约0.77亿港元，占全球发售的9.81%。 公司本次申购总人数达37.6万人，其中19万人选择申购1手；另外乙组申购人数为19,516人，顶头槌2416张。 配售结果显示，公司招股公开认购倍数达4908.33倍，国配认购10.15倍，无回拨； 轩竹生物-B一手中签率仅1%，全员抽签，顶头锤也不稳中，最终中签人数为13,467人。此外，公司此次上市无绿鞋。\n以下は、記事で言及されている港株IPOおよび暗盤に関連する専門用語の体系的な整理と解説です：\n発行構造と分配メカニズム グローバル発售 会社首次公開割当（IPO）時に、国内外の投資家を対象とする発售行為であり、公募売却（一般投資家向け）と国際配分（機関投資家向け）の2つの部分を含む。本件、玄竹生物-Bグローバル発售は6733.35万株を発行し、発行比率は13%となり、上場後に株式公開市場（ストック・プブリック）で保有する株式が総発行済み株式数の13%を占めることになる。\nメカニズムB分配方式 香港証券取引所が2023年に導入した新股の分配メカニズムであり、発行人が事前に公募売却比率（下限10%、上限60%）を設定でき、回戻りなし（回戻り調整がない）という特徴を持つ。玄竹生物-Bは公募売却比率を固定で10%とし、公開承引倍数が高达4908倍であっても、国際配分から公募売却に株式を割り当てることはなく、結果として公募売却の比率は常に673.34万株となる。\n回戻りメカニズム 従来のメカニズムAの下では、公募売却倍数が一定の閾値（例えば100倍以上）を超えると、国際配分から公募売却に株式を回戻すことができ、最大50%まで調整可能だった。しかし、メカニズムBは適用されないため、玄竹生物-Bは回戻りを行わなかった。\n投資家グループと申入戦略 公開販売と国際配分 公開販売: 全面発行台数の10% (673.34万株) を占め、個人投資家に向けられ、申入人数は37.6万人を達成。そのうち19万人のみが1手（100株）の申入に限定されました。 国際配分: 残りの90% (6060.01万株) を占め、主に機関投資家に割り当てられました。本開催では1社基盤投資家を導入し、0.77億港元を申入（全発行台数の9.81%）し、ロックアップ期間は通常6ヶ月です。 グループAとグループB グループA: 申入金額が500万港元以下の中小投資家に向けられ、公開販売の株式の50% (336.67万株) を割り当てられました。本グループの申入人数は19万人で、そのうち19万人のみが1手（100株）の申入に限定されました。 グループB: 申入金額が500万港元を超える高純資産投資家または機関投資家に向けられ、公開販売の残りの50% (336.67万株) を割り当てられました。本グループの申入人数は19,516人となり、最高申入量（トップロット）は2416張に達しました。 トップロット申入 公開販売における最高限度で申入するものであり、通常は公開販売株式の50%を認購できます。竹芝生物-Bのトップロット数量は2416張ですが、公開販売が極度に火爆（超购率4908倍）したため、トップロット投資家も抽選に当選し、当選率は非常に低くなりました。 購読データと当選ルール 購読倍数\n公開購読倍数: 公開募集額を申购資金で割ったもの、散歩の需要熱度を示す。竹芝生物-Bは4908.33倍に達し、市場新記録を更新した。 国配購読倍数: 発行金額を申购金額で割ったもの、竹芝生物-Bは10.15倍であり、機関投資家の需要が中程度であることを示している。 一手当選率と全員抽選\n一手当選率: 申告1手（通常は最小取引単位）的中確率。竹芝生物-Bは1%に過ぎず、100人中1人しか当選しないことを意味する。 全員抽選: 公開募集が極めて高倍数となったため、すべての申告者（乙組とトップハンマー投資家を含む）は抽選によって配分され、”安定当選”の仕組みはない。 株式分割分配 公開売却株式が比例配分された後、1手不足の株式切れ（例えば50株）は集約され、申告金額の高い順に分配される。竹芝生物-Bにおける当選者数は13,467人であり、一部の投資家は株式分割を通じて追加で株式を得る可能性がある。\n特殊メカニズムと市場への影響 基石投資家\nIPO前、発行者と受託契約を締結する戦略的投資家を指し、通常は著名な機関や企業である。玄竹生物-Bには1社の基石投資家が導入され、0.77億香港ドル（全世界発行台数の9.81%）を受託し、市場への信頼を高めることを目的とした。\nグリーンシューズメカニズム（超え剰配售選択権）\n上場後30日以内に15％の株式を過剰発給し、株価変動を抑制するために使用される。株価が発行価格を下回った場合、証券会社は二级市場で株式を購入して価格を支える必要がある。玄竹生物-Bにはグリーンシューズメカニズムが採用されなかったため、上場初期における株価変動が大きくなる可能性がある。\nダークプール取引\n新規株式の発行前に一日行われる店頭取引であり、通常は証券会社がプラットフォームを提供する。ダークプールの価格は市場が新規株式に対して抱く初期の期待を反映し、発行価格（玄竹生物-Bの場合、ダークプール価格が上昇する可能性がある）より高い場合、上場初日におけるパフォーマンスが良いことを示唆する。逆に、下回った場合は株価が下落する可能性がある。\n重要な用語の比較と市場背景 メカニズムA vs メカニズムB メカニズムAは回拨を可能にし、投資家が過熱時により多くの株式を獲得できます。一方、メカニズムBは固定公開販売比率を採用し、機関主導のIPOに適しています。玄竹生物-BはメカニズムBを選択した理由は、証券会社が機関投資家と散布投資家の配分をバランスさせるためと考えられます。 グループA vs グループB グループAの中籤率は低いものの、各手の収益はより分散され高くなる可能性があります。グループBの中籤率は高く、より高い資金調達コストを負担する必要があります。玄竹生物-BのグループBの申入人数19,516人は、ハイネット投資家が医薬品株に熱意を持って追いかけることを反映しています。 回拨メカニズムの取消の影響 メカニズムB下では回撥は行われず、玄竹生物-Bの公開売却はわずか673万株となり、散布投資家の「僧多粥少」という状況を悪化させました。一手中籤率が過去最低を更新しました。 まとめ 恒竹生物-BのIPO事例は、香港株式市場の構造的特徴を集中して示した：メカニズムBの適用が小口投資家の配当比率を制限し、基石投資家の導入が機関投資家の需要を安定させ、超高倍率の過剰申込みと全員抽選が生物製薬株に対する投機熱を浮き彫りにした。暗所取引とグリーンシュー機構の欠如は、上場初期の不確実性をさらに拡大させた。投資家は自身のリスク許容度に応じて、新株の基本面と市場心理を合理的に評価し、盲目的な追随を避けるべきである。\n","date":"2025-10-15","language":"ja","permalink":"https://ttf248.life/ja/p/systematic-collation-and-explanation-of-proprietary-terms-related-to-hong-kong-ipos-and-dark-pools/","tags":["恒生指数 (こうせいしじょ)","IPO","暗号化ドライブ (En goda)","専門用語","システム整理 (Shisutemu seiri)","説明 (Setsumei)"],"title":"ストリート・タームの包括的整理と解説：香港株式市場（HONG KONG）のIPO（Initial Public Offering、新規株式公開）およびダークプール（Dark Pool）に関連する専門用語の体系的な整理と解説","year":"2025"},{"categories":["メモ書き雑感"],"content":"今日は午前7時半頃、家中のネットワークが静かに「ストライキ」を起こしました。PC上で動作する外部サービスは、その切断時刻を正確に記録し、一切の兆候もなく事態が進展しました。\n正午には、携帯電話でルーターの状態を確認しても、依然としてオフラインでした。以前も同様のことが何度か起こり、通常は数時間おきに自動的に復旧するのを、電信の日常的なネットワークメンテナンスだと思っていました。\nネットワークの「自己修復」は、予定通りにはなりませんでした。仕方なく、専門家の助けを求める苦しい道を選ばざるを得ませんでした。まず、家は自如（シェアハウス）の合宿形式で、リビングが改造され、バルコニー付きの一室となりました。その部屋の扉が開かないのは、ネットワークの中枢である光猫（ファイバーオプティカルモデム）と主路由器がある場所でした。\n幸いなことに、この客厅隔断出来的房间，它的主人——我的室友——前段时间刚搬走。这算是不幸中的万幸，不然若想在工作日约一个双方都方便的时间让师傅上门维修，恐怕又是一场“拉锯战”。\n自如客服に一時的なパスワードを要請しました 客服はネットワークの問題について工单（チケット）を作成することを提案し、その後、私はすぐに外部委託されたサードパーティのカスタマーサービスに転送されました さらに、サードパーティから電信（电信）のカスタマーサービスに転送されました 一時的なパスワードを入手し、部屋のドアを開けました 光猫（ファイバーオプティカルモデム）を見ると、機器全体の外殻は黄色く、年代感がありました。それは元住人のものなのか、自如がどこから入手したものなのか不明で、明確な指示灯もなく、押せるボタンもありませんでした。再起動を試みるのをやめて、まどろんで少し休憩したいと思いました。午後には仕事があるので。 午後には、電信（电信）の技術者が私に連絡を取り、門のパスワードを技術者に送信しました。信頼を強調する形でした。技術者は半日かけて調査し、最終的な解決策は予想外にも簡単——彼は単に光猫（ファイバーオプティカルモデム）を再起動しただけです。\n最近ダウンロードした資料が多く、継続的に高負荷で運搬されたために、古い光猫が死んだのかもと考えられます。今後問題が発生した場合、技術者に新しい光猫を交換してもらいましょう。自如の賃貸期間内では、このメンテナンスは正常な範囲内です。\n","date":"2025-10-15","language":"ja","permalink":"https://ttf248.life/ja/p/a-network-repair-incident-caused-by-being-too-lazytroublesome/","tags":["ネットワーク障害","光猫 (Hikikone)","通信","再起動"],"title":"「手間を省く」ことから始まったネットワークトラブルの記録","year":"2025"},{"categories":["投資 (tōshi)"],"content":"トレードレポートの作成を目的として、投資における思考を文字に落とし込み、思考を整理し、人間の感情的なバイアスに対抗します。取引そのものは反人性であり、私たちは冷静で客観的かつ規律を守る必要があります。記録と振り返りを通じて、意思決定プロセスを体系的に検証し、感情的な失敗を繰り返さないようにすることができます。\n前述の通り、先週の米国株の大暴落および「貿易戦争2.0」の可能性に対する懸念は、本日の始盤でほぼ決着しました。午前中の市場反応は穏やかであり、「杞憂（きゆう）の一報」と呼ぶべき状況でした。\n指数ファンド：計画通りに実行 大暴落を予想していたが、アリペイプラットフォームで沪深300と恒生テクノロジー指数へのポジションを構築した。しかし、尾盤市場での下落幅は大部分が回収された。今回の建倉資金量はそれほど大きくなかったため、追加の取引は現時点では行わない。指数ファンドの今後の補強戦略は保守的かつ緩やかに進み、大部分の増額資金は固定金利+製品と組み合わせることで配置される。\n香港株式市場：に対する迅速な対応と規律ある取引 現在の香港株式ポジションを基に、もし下落が続けば、新たな資金を市場内で取引を行う必要があります。\n小米事件と認知修正 本日、小米は「黒天鵝」事件に遭遇しました：その電気自動車に関わる死亡事故です。私の最初の認識は、年間交通事故件数は膨大であり、小米の車両保有台数が増加し続ける中で、個別の事例が発生することは確率の問題であるということです。ただし、後続の調査で車両自体の設計上の欠陥が除外されれば、株価への長期的な影響はコントロール可能だと考えます。 午前中、小米の下げ幅は恒生科技板块の他の株式よりも著しく大きくなりました。私は当時食事に忙っており、富途Appを情報画面に切り替えるのが遅れたため、最初の反応時間を逃しました。 技術分析に基づき、自řejměの底値圏（ディップ）が密集していると判断し、その価格差指注文で買いを取りました。当初は明日交警（交通警察）からの通告を待つ予定でしたが、予想に反して午後には調査結果が発表され、運転手が飲酒運転やスピード超過の疑いがあることが明らかになりました。このニュースを受けて株価は急騰しました。\n取引まとめ：規律を強化 規律ある取引： 本回の建玉は明確に「短期投機（ギャンブル）」と定義される。その核心目標は、成功すれば迅速に利益確定し離脱することで、既存の保有ポジションの平均コストを下げること；失敗すれば果断に損切りして撤退すること。 当初の計画では、本日または明日決済する予定だったが、最終的に今日市場の反発の中で取引を完了させた。 これまでの取引を振り返ると：当初の資金計画と比較して、現在のポジションはほぼ満配至る。美団と半年前の小米の取引記録を見ると、過去数回の短期買いを入れた後に下落し、適切な損切りタイミングで決済できず、むしろ戻り益を期待して非合理的に保有していたことが大きな問題だった。 今回の取引における最大の進歩は：短期ポジションにおいて、「欲張り」にならないこと；取引計画を厳守し、不向きなタイミングで追加投資を行うことなく、冷静に判断すること。\n短線取引の費用 過去、証券会社システム開発において、取引費用問題について深く研究してきましたが、投資家の視点からその影響を慎重に検討することはなかった。今日になって、標準的なT+0回胴取引を行った際に収益を具体的に計算したことで初めて気づいたのは、恒生指数印花税（取引金額の千分の一）が取引コストの中で最大の項目であるということだ。\n振り返ってみると、私のキャリアの出発点は港湾・米株証券会社のシステム開発だった。取引費用がシステムにおいてどれほど重要なのかを深く理解していたにもかかわらず、投資家としてその多寡（多ければ少なくなるか）について直接的な経験がなく、また、**香港交易所（恒生证券交易所）**がどのように利益を上げているのかを詳細に検討することもなかった。年初に港股通を開通させた際、私の投資目標は恒生テクノロジー板块に固定され、恒生证券交易所自身の株式を購入することを考慮しなかった。このような考え方は、「どこで転んだかと思えば、そこで立ち上がろうとする」という執念に近いものだった。\n事実は証明した。限られた認知が最初の投資選択を規定した。中国本土の上海証券取引所（上交所）や深せんぎょとりきじょは国家機関であり、上市公司ではないため、私は類似の業界である国内証券会社にも目を向けていた。証券会社を選択したのは、「牛市旗手」（市場を盛り上げる役割）というメディア叙事の影響を受けたからだ。しかし、もし比較検討ができたなら、交易所（証券取引所）は天然の希少性と独占性を持つインフラストラクチャであり、間違いなく証券会社よりも優れた選択肢だっただろう。\n","date":"2025-10-13","language":"ja","permalink":"https://ttf248.life/ja/p/reverse-human-nature-trading-review-xiaomis-black-swan-incident-t0-compliance-practices-and-the-neglected-hong-kong-stamp-duty/","tags":["振り返り記録","配置 (かいし)","追加買い付け","鉄則 (てっそく)"],"title":"反人間的取引回顧：小米“黑天鵝”事件中T+0的紀律實踐，以及被忽視的香港股票印花稅","year":"2025"},{"categories":["投資 (tōshi)"],"content":"港股市場において、着実に成果を上げたい投資家にとって、成功の源泉は市場の每一次変動を正確に予測することではなく、科学的で合理的な投資体系を構築し、厳格に遵守することにある。この体系の核心は、以下の3つの柱によって構成される：合理的ポジション管理、知恵に基づいた補充戦略、そして鋼鉄のような取引規律である。本稿ではこれらの重要な要素を統合し、投資家にとって包括的かつ詳細な運用ガイドを提供する。\nポジション管理 – 堅実投資の基礎 堅実投資における第一の目標は「先（先生）を優先し、後（発展）に備える」ことです。ポジション管理は、この目標を実現するための「盾」であり、市場の変動に対する耐性を決定します。\n総合配分：リスク許容度と市場環境に連動 個人リスク許容度: ポジション上限を決定する根本的な要素です。リスク回避型の投資家は、牛市であっても、全体的なポジション上限を**60%以下に抑えることを推奨します。ややリスク許容度の高い投資家は、上限を70～80%に設定できます。常に20%**の現金を保有し、戦略的備蓄として、極端な機会や予期せぬ状況に対応できるようにしてください。 市場環境: 高位/バブル相場 (市場熱狂): ポジションを**30～50%**またはそれ以下に引き下げます。利益を守ることが最優先です。 合理/変動相場 (方向不透明): ポジションを**50～70%**に維持し、構造的な調整を行います。 低位/パニック相場 (バリュー下落): ポジションを大幅に拡大する黄金期です。**70～80%**以上にポジションを引き上げることができます。 個別銘柄と業界配分：リスク分散、過剰投資を回避 個別銘柄の最大保有割合: どの銘柄であっても、好意的評価が高くても、個別の銘柄に対する最大保有割合は、総投資ポートフォリオの**20%に留めることを推奨します。認知度が低く、リスクが高い企業については、さらに5～10%**まで引き下げます。 業界全体の最大保有割合: 港元市場における業界集中度が高いため（金融、テクノロジーなど）、分散投資を考慮する必要があります。業界全体の最大保有割合は**30～40%**に抑え、業界固有の「黒天鵝」イベントによるリスクを回避します。 補倉戦略——被動を主动へ転換する芸術 補倉は、堅実投資家が下落市場において質の高い株を積み増す「利矛」ですが、その前提は基本面が健全で、コアコンピタンスが損なわれない優れた企業のみに投資することです。基本面が悪化したり、「老千株」のようなものに対しては、唯一正しい対応はストップロスを設定することです。\n下落幅度をどれだけまで買い増しする？ 買い増しの核心は「越えれば買う」、つまり「下がるほど買う」ことですが、計画的に、規律を守って実行する必要があります。\n金字塔式買い増し法 (下重上軽): これは比較的安全な方法で、下落幅が大きくなるほど、購入金額も大きくなります。 初回建玉: 合理的な評価区域に底仓（底値建て玉）を構築します。 第一次買い増し: 初回建玉価格から下跌15～20%のポイントで買い増しします。これは一般的な買い増しのポイントであり、市場の正常な変動を濾過するのに役立ちます。 第二次買い増し: 第一次買い増し価格からさらに下跌15～20% (累積下落約30～40%) で買い増しします。 第三次買い増し: 第二次買い増し価格からさらに下跌15～20% (累積下落幅は約50%程度) で買い増しします。この時点で通常は極端な恐怖感があり、会社基本面が依然として堅実であれば、最高の買い付けチャンスとなります。 補倉を何度か行うのは妥当でしょうか？ 誤った判断に過大な資金を投入することを避けるため、補倉の回数は不宜过多。\n推奨する補倉回数：2～3回程度が望ましいです。 リスク管理： 2～3回の大幅補倉後に株価が依然として回復しない場合、最初の投資ロジックを改めて見直す必要があります。無限に補倉を続けると、単一の株式比率が高くなり、投資ポートフォリオ全体を崩壊させる可能性があります。 現金を保有する： 過度な補倉は迅速に予備資金を使い果たし、市場に出現する他のより良い機会を見逃すことになります。 取引ルール - 新手から上級者への核心 もしポジション調整と損切りが「技術」であるならば、取引ルールは「道」である。トレーディング初心者にとって、ルールを守ることが市場で長期的に生き残るための決定的な要素となる。\n計画と実行の規律：準備不足な戦いは絶対にしない まず計画、次に取引: 全ての取引前に、明確な買い入れ理由、目標価格（損益分岐点）、損切り価格を設定しなければならない。取引中は、感情に左右されず、計画を厳守する。 追証・暴落を避ける: 「見逃すことの恐怖」（FOMO）やパニック売りによる感情的な行動を克服する。自身の計画に合致する買い付けと売り抜けのみを行う。 リスクと資金管理の規律：生き残ることが最優先事項 厳格なストップロス、迷うことなく： ストップロスは本金を守るための命綱です。初心者が最も危険な習慣である損切り死守を避けるべきです。ストップロスレベルを-5%～-10%に設定し、触れると無条件で実行します。 損切り時に追加投資して元に戻さない： これは致命的な間違いです。もし取引が誤りであることが証明され（ストップロスを突破した場合）、正しい対応は撤退することであり、さらに資金を投入して「損失を均等化する」ことではありません。これにより、小さなミスが大きな災難に発展します。 心態と感情コントロールの規律：感情を操る主体になる 損失は取引の一部であると受け入れる： 誰も百戦百勝できるわけではない。小さな損失を取引の必要経費として捉え、長期的な全体的な利益比に注目する。 利益には驕らず、損失には落胆しない： 「ギャンブラー心理」を戒め、利益によって過度なリスクを取ったり、損失によって報復的に取引したりしない。常に冷静さを保ち、一貫性のある行動を心がける。 学習と復盤の規律：継続的な進化 取引記録を堅持する: varje 取引の思考と結果を詳細に記録し、定期的に復盤して成功と失敗の原因を分析します。これは自己成長のための最も効果的な方法です。 能力圏を守る: 理解できる、理解可能な投資のみを行いましょう。未知の分野や複雑な金融商品から距離を置きます。 忍耐と規律は万人に勝る 港股投資家として、市場の波に翻弄される投機家になるのではなく、敏腕な将軍のように戦略を練り、状況を把握することを目指してください。ポジション管理を堅実な盾とし、買い増し戦略を鋭利な長槍とし、取引規律を揺るぎない軍法として体現しましょう。\n取引初期においては、**「損切りを優先する」**ことを第一目標とし、「利益を最大化する」ことではありません。継続的な学習、実践、そして振り返りを通して、機会と挑戦に満ちたこの市場で、長期的に安定した資産形成を実現してください。忍耐と規律は、常に市場を予測することよりも重要な資質であることを忘れないでください。\n","date":"2025-10-13","language":"ja","permalink":"https://ttf248.life/ja/p/a-complete-guide-to-positioning-replenishing-positions-and-stop-loss-orders/","tags":["配置 (かいし)","取引 (とりひき)","感情","規律 (Kiritsu)","小米 (Xiǎomǐ)","雷軍 (Léi Jūn)"],"title":"ポジション（配置）、補倉と鉄則の完全ガイド","year":"2025"},{"categories":["投資 (tōshi)","魚の7秒間の見聞"],"content":"以前の株式市場では、経済ニュースに注目が集まっていましたが、トランプ氏が再び帰国して以来、彼のツイート（個人向けカスタマイズ版）にも注目する必要がありました。貿易戦争は相変わらず激化し、4月7日の大幅な暴落の後、急速に回復しましたが、今回はみんなまだ買い入れると信じられるのでしょうか？\n背景回顾 2025年4月7日、米国が「対等関税」政策を実施したことで世界的な株式市場は「ブラックマンデー」を迎えました。A株は7.34%の大幅下落し、創業板指も12.5%の大幅下落、超4300銘柄が9%を超える水準で下落しました。恒生指数も13.22%の大幅下落を記録し、欧米株式市場もそれぞれ4%以上下落しました。中国はその後、央企による買い入れや匯金（ヘッジファンド）の介入などにより市場を安定させました。\n10月10日夜に米国株が再び大幅な水準で下落し、中概股指数は6%下落した主な要因は、米中貿易戦の激化への懸念でした。トランプ氏は対華関税を強化する姿勢を改めて表明し、米国側は中国船舶に対する高額な費用を課すことや、中国がそれに伴い特別港務費を徴収するなど、対等に報復しました。さらに、米政府の閉鎖（シャットダウン）や消費者の信頼感低下も市場のパニック売りを引き起こし、避難情绪下落を招きました。\n原文リンク 位置制御 現在のA株空売りポジションは、完全な空売りとは言えず、固收（固定収入）に加えて、少額の指数基金も含まれていますが、大部分は香港市場に集中しており、小米では既に本金の損失が発生しています。美团は依然として大株主であり、ポジション制御がやや不均衡です。月曜日に入って賭けるべきかどうかは問題であり、現在手元には十分なキャッシュフローはありません。もし入る場合は、旧友である支付宝の借呗を利用して架け橋となる資金を調達する可能性があります。貪心不足蛇吞象（貪欲な蛇が象を食べ込む）のように、ポジション制御が非常に不合理です。その後、減額の機会を探し、減額を行う必要があります。\n4月7日と比較すると、現在の位置は低位とは言えません。多くの株式のポジションは比較的高い水準にあり、特に恒生科技に含まれるテクノロジー株は、個別銘柄に追加投資するのではなく、ETFを通じて追加投資するのが適切です。例えば、回りきって見当たらなかった適切なものがあり、上昇率は20%～30%程度です。\n国内市場については、長期的に見て震盪（変動）しながら下落していくと予想され、短期的な大幅な上昇を狙うには、この期間内に利益確定を行うのが最適です。\n関連用語解説 ブラックスワン (Black Swan) 「ブラックスワン」という言葉は、タレーブ (Nassim Nicholas Taleb) の著作『黒色天鵝効果』に由来する。\n概念: 極めてまれで予測不可能な出来事であり、発生すると極めて大きなインパクトと破壊的な結果をもたらすこと。 特性: 稀有性/不可予測性: 発生前に先例や兆候がなく、誰もが想定していなかった出来事である。 巨大なインパクト: 一度発生すると、市場、経済、さらには社会に壊滅的な影響を与える可能性がある。 事後解釈性: 事前には予測不可能だが、事件が発生した後では、人々は様々な理由や説明を見つけ出し、「理解可能」に見せる傾向がある。 起源の典故: ニュージーランドが発見される前に、ヨーロッパ人はすべての天鵝が白いと信じていた。オーストラリアで黒い天鵝が発見されたことで、数千年の認識を覆した。したがって、ブラックスワンは予期せぬ、認知を超える出来事を象徴する。 株式市場の例: 2001年の「9·11」テロ事件（世界の株式市場への短期的な衝撃）。 新型コロナウイルス感染症 (COVID-19) の初期段階において、世界経済と市場に突然の衝撃を与えたこと。（一部にはグレーオフィスの特徴を持つと見なす意見もあったが、その爆発とグローバルな蔓延の速度および影響の程度は、ブラックスワンとして捉えられることが多い。） 灰犀牛（Gray Rhino） 「灰犀牛」という言葉は、ミシェール・渥克（Michele Wucker）によって提唱されました。\n概念： 確率的に発生しやすく、影響が非常に大きく、かつ明確な兆候や警告が存在するにもかかわらず、人々によって**集団的に無視されたり、**選択的になんらかの延期をしたりして対処される潜在的な危機。 特性： 高い確率/予測可能性： イベント発生前に明確な兆候と証拠があり、既知のリスクです。 見過ごされやすい： それが突発的ではなく、長期にわたって存在するか、または徐々に発展しているため、人々は麻痺したり、楽観的な偏見を持ったり、延期してしまい、適切な行動を講じることができません。 巨大なインパクト： 一度爆発すると、それまでの効果的な対応がないために、連鎖反応を引き起こし、深刻な破壊的結果をもたらします。 出典の典故： 灰犀牛は体格が大きく、反応が遅いため、遠くからでも見ることができ、しかししばしば軽視したり、無頓着にしたりして回避することができず、それがあなたに向かって猛スピードで突進してきたときには致命的な衝突を引き起こします。したがって、灰犀牛は明らかなにもかかわらず無視される巨大な脅威を象徴しています。 株式市場の例： 2008年の世界金融危機（多くの専門家がアメリカのサブプライム住宅ローン市場のリスクについてすでに警告を発しており、それが広く無視されました）。 主権債務危機、深刻な資産バブル、気候変動によるシステムリスクなど（これらはすべて長期にわたって蓄積され、跡が付く巨大なリスクです）。 ","date":"2025-10-11","language":"ja","permalink":"https://ttf248.life/ja/p/black-swan-goose-returns/","tags":["配置 (かいし)","株式市場","ブラックスワン (Burakusuan)","グレイオフィス (Greyphos)","ニューヨーク証券取引所（NYSE）/ 株式市場","恒生指数 (こうせいしじょ)","貿易戦争 (Bōeki senso)"],"title":"株式ブラックボディの白鳥再び (Kaikei burakku bodi no hakuchō futatabi)\n\n**Note:** This is a literal translation aiming to capture the poetic and somewhat evocative nature of the original phrase.  A more natural Japanese phrasing might be needed depending on the context.","year":"2025"},{"categories":["メモ書き雑感"],"content":"最近は減脂とボディシェイプに取り組んでおり、主にジムでのランニングでカロリーを消費しています。また、基礎的な筋力トレーニングも取り入れ、基礎代謝を高めています。気づいたこととしては、筋肉痛が遅延することがあり、運動隔日の間はそれほど酸気持ちくなく、むしろ48～72時間程度の経過後に最も顕著に現れることです。\nトレーニングの目的は理想体重に戻すことなので、筋力トレーニングの強度を特に高めることはありません。9月の廬山登山での経験から、このような筋肉痛は通常3日程度かかることが多いです（若い頃にはダイエットの経験もあり、身体機能が良かったため、回復は現在よりも速かった）。現在は下肢の筋肉が適応し、回復していますが、全身の主要な筋群を一つずつ再活性化させ、適応させる必要があります。\nDOMS（遅発性筋骨過敏症） ご指摘の現象は遅発性筋骨過敏症（Delayed Onset Muscle Soreness、以下 DOMS）と呼ばれます。 その主な特徴は痛みの出現に遅れがあることであり、運動の直後や翌日には最も激しくない状態で、通常運動後24～72時間以内にピークを迎えることがあり、これはあなたの経験と一致します（2日後に反応が顕著になる）。\nDOMSが生じる主な原因は以下の通りです。\n筋肉繊維の微小損傷： DOMSは乳酸蓄積によるものではなく（乳酸は運動後1時間以内に排泄されます）、不慣れな、または強度が高い運動、特に遠心収縮（筋肉が力を入れて伸ばされること、例えば下り坂を走る、スクワットで下降する段階など）が多いトレーニングによって、筋肉繊維と結合組織に微細な裂傷や損傷が生じることによって引き起こされます。 炎症反応の発生と発達： これらの微小損傷は身体の炎症反応を引き起こし、これは損傷を受けた組織を修復する過程です。 炎症反応の発生、発達、蓄積には一定の時間が必要です。この過程で、組織はヒスタミンやプロスタグランジンなどの化学物質を放出して神経末梢を刺激し、痛みや酸痛感を引き起こします。 したがって、酸痛感は損傷が起こってから2～3日目に最も顕著になるのに時間がかかります。これは炎症が十分に発達する必要があるためです。 あなたの筋骨過敏症には遅延があり、それは身体が筋肉の微小損傷を修復し、炎症反応を起こしているプロセスであるためであり、即座に起こる乳酸蓄積によるものではありません。現在行っている基礎トレーニングで、特に筋力トレーニングや遠心収縮動作が多い場合、このような遅発性筋骨過敏症を引き起こしやすくなります。\n取り扱いと対処法 休息と回復: 影響を受けた筋肉に十分な休息時間を与えましょう。 軽い運動: ウォーキングやストレッチなどの軽めの有酸素運動を行うことで、血行を促進し、代謝産物を除去・回復を早めるのに役立ちます。 マッサージまたはローラーでのリラックス: 筋肉の緊張や硬直を緩和するのに効果的です。 十分な栄養補給: 運動後には、筋肉の修復に必要なタンパク質とエネルギー補給のための炭水化物を適切に摂取することが重要です。 徐々に強度を上げていく: 急激な運動量の増加や強度への変化は避け、身体が段階的にトレーニングに適応できるようにしましょう。 ","date":"2025-10-11","language":"ja","permalink":"https://ttf248.life/ja/p/delayed-muscle-soreness-dms/","tags":["ダイエット","運動 (undō)","筋肉痛 (きんようとう)"],"title":"運動後の筋肉の遅延性痛み (こうりょくごふ  きんようの つえいせいぎょうたいにむかない痛み)","year":"2025"},{"categories":["転載 (tenzai)","コンピューター"],"content":"記事の投稿頻度は、AIの使用に伴い著しく増加しています。私も記事内のタグで区別し、作者欄には大規模言語モデルの名前を記載する予定です。しかし問題は残っており、AIが生成した記事では、私の関与レベルは明らかに低下しています。多くの記事が半ヶ月ほど隔てられ、内容をほとんど忘れてしまいます。コーディングの際にも同様の状況が発生し、問題に遭遇したら、まずAIによる分析を思いつき、既存のものに基づいた問題解決やトラブルシューティングではなく、「怠惰」が顕著に向上しています。\n生成AIは業務効率を向上させる一方で、その「贈り物」には巨額な代償が伴います。北大研究チームが41万件の論文と縦断的な実験分析を通じて明らかにしたところ、AIは知識生産を加速させながらも、深刻な同質化を引き起こしています。ハーバード大学の研究では、AIが「資格偏向」をもたらし、初級職が7.7%減少するという結果を示しており、マタイ効果を悪化させています。個人的には、AIによる創造性の向上は一時的な「幻覚」に過ぎず、停止すると消え失せます。しかし、思想の同質化は持続的に存在し、「創造の傷痕」を生み出しています。\n現状 生成式AIは、あらゆる産業を再構築するだけでなく、人間の文章作成、認知、思考の根本的な方法も変えています。ChatGPT 3.5 の発表後、楽観的な期待が広まりました：「AI は労働力を均等化する」という予測です。\n2023 年、マサチューセッツ工科大学の経済学博士 2 人が『Science』誌に実証研究を発表し、この見通しを裏付けました。生成式 AI が低パフォーマンス従業員のパフォーマンスを大幅に向上させ、そのギャップを埋めることで不平等感を軽減する可能性があるというものです。\n『Science』誌の編集部は、こうまとめました。「スキルが劣る参加者は ChatGPT から最も利益を得ており、これは生産性の不平等を AI で削減するという政策にとって重要な示唆を与えています。」\nしかしながら、2 年が経過した今、現実がこの理想的な経路を完全にたどっているとは限りません。\n2025 年、ハーバード大学の経済学博士 2 人は、2015 ～ 2025 年にかけて 620 万人以上、1.5 億回以上の採用・雇用データ分析を通じて、冷酷な真実を明らかにしました。生成式 AI は「資格偏重」の形で労働市場を再構築しているのです。\n数据显示、2015 ～ 2022 年にかけて、初級職と高級職の雇用成長曲線はほぼ一致していましたが、2023 年以降、両者で分岐が生じ始めました。高級職は引き続き上昇し続けましたが、初級職は方向転換して下降しました。\nAI を深く受け入れている企業の場合、その初級職の数は 6 四半期以内に約 7.7% 減少しましたが、高級職はほとんど影響を受けず、むしろわずかに増加しました。この現象の主な原因は採用の減少ではなく、大規模な解雇ではありませんでした。\nAI は、普恵的な平権をもたらすどころか、「强者更强」のマタイ効果をますます強調しています。 携程 CEO の梁建章氏は、この論文について「AI は初級の知的労働者を代替し、若者の教育、結婚、出生、職業初期といった段階における困難を悪化させるだろう」と評価しました。\n労働市場の構造変化は氷山の一角に過ぎません。より深層的な問題が浮上してきます。AI が大規模に私たちのワークフローに組み込まれるとき、それは人間の創造性自体にどのような影響を与えるのでしょうか？ AI がもたらす効率性の向上は、個人の能力の内化でしょうか？ それは、私たちが見過ごしている方法で、あるいは「統一」することで、私たちの思想を形作ったり、「統一」したりしているのでしょうか？ 個体が AI に過度に依存した後、彼らの独立した、オリジナルの思考能力は強化されたのか、それとも無意識のうちに弱体化されたのか？\n最近、北京大学 李圭泉 教授の研究チームが、社会学のトップジャーナル Technology in Society に発表した論文は、この一連の重要な問題に対する正面からの回答です。\n研究の中心は 2 つの部分で構成されています。第一に、ChatGPT 3.5 のリリース前後の、全 21 科目の学術論文を分析する大規模な自然実験を通じて、AI が世界の知識生産に与える実際の影響を分析します。第二に、数か月続く縦断的な行動実験を通じて、ラボ環境で AI が個人の認知能力に及ぼす長期的な因果効果を探ります。\n研究チームは、ブレイクポイント回帰設計と機械学習などの技術を組み合わせて、生成式 AI が個人創造性と集団同質性に与える長期的かつ現実の影響を明らかにしました。\nこのジャーナルは JCR 1区 top であり、影響因子 12.5 で、socialscience,Interdisciplinary 分類下 271本のジャーナル中ランキング第2\n41万論文の「集団無意識」 最恐ろしいのはノイズではなく、衆聞一斉であることだ。\n41万論文の「集団無意識」 この研究は大規模な自然実験でした。 研究チームは、Web of Scienceコアデータベースから、物理科学、生命科学・生物医学、応用科学、社会科学、芸術・人文など全部21分野の学術産出を抽出し、ChatGPT-3.5発表前の全419,344篇論文を約17,000名の研究者からのランダムサンプリングを通じて収集し、巨大なデータセットを作成することで、AIが世界の知識生産に与える真の影響を分析しました。\n生成AI発表前後の学術論文の同質性と創造性結果のイメージ図\n上記画像のように、2022年以前は世界の学術産出の創造性（赤/青線）と同質性（灰色線）が安定的に成長していました。しかし、ChatGPT3.5発表後、両者の傾斜が急激に上昇しました。 つまり、GPT3.5発表後、学界は知識産の創出（創造性）を著しく加速させる一方で、その内容の同質化もより速い速度で進み、生成AIが知識生産に対して持つ「両刃の剣」のような影響を明確に示すものでした。\n観察された変化がAIによって引き起こされたことを証明するため、研究チームは「断点回帰デザイン」（RDD）と呼ばれる因果推論手法を採用しました。\n方法 2022年12月ChatGPT-3.5のリリースを、天然の「時間断切」と捉えることができる。論文がその日付より前か後かで、個々の研究者にとって制御できない偶然要因（例えば査読期間）が存在し、これはほぼランダムに「実験群」（AIを使用できる機会があるグループ）と「対照群」（AIを使用できないグループ）に割り当てられたようなものである。\n信頼性の理由 この「準確率」特性により、研究者は他の長期的な要因の干渉を効果的に排除し、AIがもたらす因果効果を正確に特定することができます。その方法論の厳密性を確保するため、チームは一連の統計的検定を実施し、学者が「切り替え点」の前後に大規模な「稿を捏造する」や「早期発刊する」などの戦略的な行動を行っていないことを確認しました。これにより、研究結果の信頼性が保証されます。\n「創造性」と「同質性」の指標を定量化するには？ 因果関係が確認された後、研究チームは40以上の論文に対して、「創造性」と「同質性」という2つの次元で定量分析を実施しました。\n創造性：論文発表の「数」と発表ジャーナルの「質」（JCR分区）を評価します。\n数：学者が発表した論文の総数。 質：論文が発表されたジャーナルのJCR分区（JournalCitationReportsQuartiles）。これは、JCR（ジャーナル引用レポート・クォータイルズ）という権威あるジャーナル評価システムで、Q1は当該分野における影響力上位25%に位置するトップジャーナルを指し、Q4は末位の25%を指します。 同質性：内容類似度と言語スタイル類似度によって評価します。\n内容類似度：SBERT（Sentence BERT）という深層学習モデルを用いて論文の要約を数値「ベクトル」に変換し、そのベクトル間の「コサイン類似度」を計算することで、核心的な意味合いにおける類似度を測ります。 言語スタイル類似度：文字レベルでのマッチングアルゴリズムを用いて論文の要約から出現する短語や文型をスキャンし、それらの繰り返しをカウントすることで、文章スタイルの類似性を測定します。 冷徹な両刃の剣：より効率的、しかしより単調 如图所示のように、分析結果は明確に「両刃の剣」効果を明らかにする。 一方、AIの登場は学術産出における強力な「加速器」となったことは確かである。研究者の1人あたりの年平均発表論文数は0.9篇増加し、発表ジャーナルの質は平均6%向上した。この効果は特に技術や物理科学などの分野で顕著である。 しかしながら、効率の向上が思想と表現の多様性を犠牲にしている。データによると、論文の言語スタイル類似度は平均毎年驚異的な79%増加し、同時に論文の内容テーマも著しく同質化しており、特に物理科学、芸術、人文科学における同一化現象が最も深刻である。\n断点回归结果图\n北大研究チームによるこの大規模な自然実験は、私たちに現実世界の宏観的な証拠を提供する。生成式AIは学術産出における強力な「加速器」であり、学者たちがより迅速に論文を執筆し、より優れたジャーナルに発表するのを助ける。しかし、このような効率の向上は、思想と表現の多様性を犠牲にしている。\n世界の知識生産は、この「大交換」の中で、より効率的かつ「単調」になっているようだ。\n同時に、研究二でも、より深いレベルの問題が提起された：この宏観的なトレンドが、その場にいる個人にどのような意味を持つのか？AIが生み出す創造性の向上は、実際の個人能力の成長を意味するのだろうか？\nこの問題を解決するために、研究チームは研究二で数ヶ月にわたる継続的な追跡調査を実施し、制御された実験環境においてAIが個人の認知能力に及ぼす長期的な因果効果を探求した。\nAIが生み出した創造性の傷跡 思考が習慣に屈すると、創造性は失われてしまう。\nAIが生み出した創造性の傷跡 実際には、すでに多くの研究所で、小規模なデータを用いた実証研究が、マクロデータが示唆するトレンドから異なる角度からその傾向を裏付けています。例えば、コーネル大学の研究では、AIライティングアシスタントが文化的独自性を犠牲にし、「西欧の規範」に従うような表現へと誘導するという傾向が見られました。また、サンタクララ大学の研究でも、ChatGPTを使用している個人は、その創造性が意味レベルでより類似していることが示唆されました。\n特に注目すべきは、マサチューセッツ工科大学の研究チームが脳波（EEG）技術を用いて、個人の脳活動を直接観察したことです。彼らは、ChatGPTを使用していた学生グループの脳活動レベルが、自分自身で考えるか、検索エンジンを使用するグループと比較して著しく低いことを発見しました。\nこれらの研究は、AIが認知投入を減らし、多様性を犠牲にして効率を高めるという結論を導き出しています。\nしかし、ほとんどの研究は、AIの使用による即時の影響に焦点を当てており、AIが「離場」した後、その効果が持続するか、そしてその長期的な負の側面が軽減されるかについては、ほとんど探求されていません。\n北京大学はこの点において新たな試みを行いました。\nそれは、7日間の実験中にAIの即時的な影響を観察するだけでなく、実験終了後の30日目と60日目の独立した追跡テストを通じて、AI依存によってもたらされる長期的な結果を体系的に検証することにも取り組んだのです。これにより、AIがもたらすのは、転移可能な「能力」なのか、それとも一時的で内化できない「幻影」なのかを真正に理解することが可能になりました。\n具体的には、北京大学の研究チームは、61名の大学生を2つのグループに無作為割り当てました。「AI実験群」（ChatGPT-4を使用可能）と「純粋な脳力対照群」。\n実験デザインには、3つの主要な段階が含まれていました。まず、すべての参加者が最初の日にAIを使用せず、創造力基線テストを実施しました。次に、2日から6日までの間、「AI実験群」はAIの支援を受けて毎日の創造力タスクを完了させ、「純粋な脳力対照群」はAIの支援なしでタスクを完了させました。最後に、そして最も重要なのは、7日目、30日目、および60日目に、すべての参加者がAIの支援なしに最終的な追跡テストを実施したことです。\n研究者は、創造性を評価するために、複合的なタスクモードを採用し、複数の次元をカバーしました。これらのタスクには以下が含まれます：\n発散的思考テスト: 従来の「代替用途タスク」（AUT）で、参加者が日常のアイテム（例えば、「ペン」）について可能な限り多くの新しい用途を思いつくように求められます。 創造的な問題解決: より現実世界のビジネスシナリオに基づいた課題で、例えば、「スマート自転車」のデザインにおける革新的な機能を考案するように求められます。 集約的思考テスト: 追跡段階に組み込まれた「遠距連想クイズ」（RAT）で、参加者が関連性のない3つの単語を同時に結びつける単語を見つけ出すように求められます。 洞察力問題: 「キャンドル問題」の古典的なもので、参加者が箱に入った金槌、一本のロウソク、そして火打ち石を使って、ロウソクを壁に固定し、かつロウがテーブルに落ちないようにする必要があります。 評価の科学性を確保するために、研究者は分野における「ゴールドスタンダード」である専門家合意評価法（CAT）を採用しました。多位の専門家評委は、「双盲」条件下で、グループ分けや研究目的を全く知らない状態で、数千件の創造的なアウトプット（発散的思考タスクと複雑な問題解決策を含む）の新規性、実用性、柔軟性などの複数の次元について独立して評価しました。極めて高いデータの一貫性（評価者信度ICC \u0026gt; 0.90）が確保され、評価結果の科学性と公正性が保証されました。\n研究二では、同質性の測定方法として、研究一で採用された技術方法を完全に同一のものを使用し、2つの研究間の評価基準の一致性を確保しました。\n実験の結果は、明確な非対称性を示び露しました：\n創造性の向上は一時的で持続不可能である: AIを使用していた期間（第2～6日） 停止使用AI 2か月後でも、「AI実験グループ」の出力内容は、意味レベルおよび言語スタイルにおいて、対照群と比較して依然として著しく高い類似性を示した。 この縦断研究により、直接的な因果関係を示す証拠が得られ、AIが個人の創造性に及ぼす長期的な影響を実証した。AIが生み出すものは単なる内化できない「創造性の錯覚」に過ぎず、残された思考の同調は、長期間にわたって認知や表現習慣の中に残り続ける「創造的傷痕」となる可能性がある。\nもし世界に新しいアイデアがなくなったら これは最良の時代であり、最悪の時代である。\n新しい創造性が世界にない場合 北大が行ったこの研究の結論は、私たちが「挫折してAIを完全に放棄する」のではなく、AI時代においてAIを理解し対処するための意識的な努力を促すものである。長期的にAIに依存することで、個人の思考や認知習慣に及ぼされる深遠な影響を認識する必要があるという警告である。\n研究で明らかになった「同質化（Homogenization）」の傾向は、その根底には深い認知科学の原理が存在する。「AIの出力は、ユーザーに対して強力な「アンカー効果（Anchoring Effect）」を引き起こしやすく」、AIが迅速に「それなりによい」と思われる答えやフレームワークを生成すると、私たちの思考がその初期の提案に「固定化され」、その後の思考や創造性が大幅に逸脱することが難しくなる。それが集団レベルで思想の収束につながるのである。\n今年7月に黄仁勋氏がCNNのインタビューで述べた冷静な判断は、「世界に新しい創造性がない場合、AIが生み出す生産性の向上は失業へとつながる」というものだった。\n生成AIが継続的に使用されることで、インターネットの情報や人間の知識基盤がかつてない速度で同質化が進んでいる。北大的研究は、この傾向が実際に存在することを冷徹なデータによって証明している。社会が常に新しい創造性を生み出すことができれば、AIはより多様な雇用機会を生み出すことになる。しかし、単に既存のタスクを繰り返すだけでは、AIは数秒でそれを完了してしまうだろう。\nAIは創造性を増幅させるだけでなく、「アイデア枯渇（Mental Block）」した人々を排除する加速剤となる。\nAI時代における思考の鋭さの維持について AIは私たちの仕事を軽減する一方で、深く考えることができる思考体系を構築し、AIとインタラクティブに連携することが重要です。解決したい問題をAIに記述するだけでなく、問題自体を推論し、AIの回答が正しいかどうか判断する必要があります。そのためには、弁証法的思考が必要です。—黄仁勋\nAI時代における思考の鋭さの維持について AI時代を生きる個人として、私たちはどのように向き合うべきか？AIの利便性を享受しながらも、創造性の荒廃を防ぐにはどうすればよいか？研究からの示唆に基づいて、以下に具体的な行動提案を示します。\nAIを「思考のコーチ」と捉える: 疲れることなく、無限の視点を提供してくれる「思考のコーチ」として活用する。アイデア出しや可能性の生成、固定観念への挑戦などに利用するが、最終的な選別、深化、意思決定、そして結果に対する責任は、依然として自分自身で行うべきだ。\n「認知摩擦」を意図的に作り出す: 「アンカー効果」に対抗する最も有効な方法は、積極的に「認知摩擦」を生み出すことである。AIが最初に提示する答えに安易に同意せず、その論理的欠陥を探し出し、考慮されていない側面を质疑する。このような批判的思考の訓練こそが、私たちが独立した思考能力を維持するための鍵となる。\n「AIなしの時間」を設ける: 筋肉が萎縮しないように定期的に運動するように、脳もAIのサポートなしに鍛える必要がある。週単位で「AIなしの時間」を設け、最も基本的な紙とペン、または空白のドキュメントを使って思考、計画、創作を行う。このような意図的な「認知断捨離」は、脳の中核的な創造性と推論能力が、安逸の中で退化することを防ぐのに役立つ。\n","date":"2025-10-10","language":"ja","permalink":"https://ttf248.life/ja/p/all-the-gifts-of-ai-have-already-been-marked-up-with-prices-in-the-shadows/","tags":["ai","ウォール・ストリート・ジャーナル (Wall Street Journal)"],"title":"あらゆるAIの恩恵は、すでに影で価格が設定されていた。","year":"2025"},{"categories":["コンピューター"],"content":"あるホットな関数におけるパフォーマンス最適化で、内部ループがボトルネックとなり、AIからの提案としてenumerateとrangesが利用可能になったため、関連資料を調査した。\n文章の主体部分はAIによって生成され、筆者はコードをテストし、いくつかの補足説明を加えた。 オンラインコンパイラでC++コードをテストする際には、やはり馴染み深い老友だちである。 gcc13上で動作した場合、従来のforループがstd::views::enumerateよりもわずかに高速であり、実質的には無視できる程度だった。 gcc16上で動作した場合、両者のパフォーマンスはほぼ完全に同じだった。\nデバッグモード下では、従来のforループの方が顕著に速い。ほぼ2倍の速度だった。\nこれは素晴らしい質問です。std::views::enumerate は C++23 で導入された Ranges ライブラリの一部であり、コンテナをより簡潔かつ安全にイテレートしつつ、要素のインデックスを取得することを目的としています。 C++ の設計哲学に基づき、**std::views::enumerate (および Ranges ライブラリのほとんどの View) はパフォーマンスにおいて、従来のインデックスループやイテレータループと同等、あるいは特定のコンパイラ最適化下ではわずかに優れているはずです。これは、より高度な意味情報を提供するためです。コンパイラは通常、ゼロオーバーヘッド抽象 (Zero-Overhead Abstraction) の原則により、std::views::enumerate の高度な構造を、手書きのループと同じ機械コードに最適化できます。 以下では、enumerate パターンについて詳しく説明し、そのパフォーマンスの違いを比較するための完全な C++ テストデモを示します。\nstd::views::enumerate パターンの詳細解説 std::views::enumerate は、ビューアダプター (View Adaptor) であり、Range（例えば std::vector）を受け取り、新しい Range を生成します。\n新しい Range の要素の型: 新しい Range 内の各要素は、構造化バインディング (Structured Binding) でアンパック可能な タプル (tuple-like) オブジェクトであり、2 つの部分を含みます。 インデックス (Index): 要素のゼロベースのインデックス (std::size_t)。 値/参照 (Value/Reference): 原始 Range 内の対応する要素への参照（通常は const auto\u0026amp; または auto\u0026amp;）です。 使用方法: 通常、C++17 で導入された 構造化バインディング と組み合わせて使用され、コードをより簡潔で読みやすくします。これは Python の enumerate() に似ています。 利点: 可読性の向上: インデックスと要素値をループのヘッダー部分で分離することで、一目で理解できます。 インデックスの明示的な管理を回避: ループ外部でインデックス変数を宣言したり、ループ内部でインデックスが漏れることを心配する必要はありません。 Range-based For Loop の意味を保持: Range-based For Loop の簡潔さと、従来の For 循環におけるインデックスへの要求を組み合わせます。 完全実行可能なテストデモ (C++23) 公平な性能比較を行うため、両方のモードが大量のデータを処理する際の時間を測定するために、高精度タイマーを使用します。 注意: このコードを実行するには、C++23 をサポートするコンパイラが必要です (std::views::enumerate は C++23 標準の一部です)。\n完全実行可能なテストデモ（C++23） #include \u0026lt;iostream\u0026gt; #include \u0026lt;vector\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;numeric\u0026gt; #include \u0026lt;ranges\u0026gt; #include \u0026lt;algorithm\u0026gt; #include \u0026lt;cmath\u0026gt; #include \u0026lt;functional\u0026gt; // 別名簡略化 using std::chrono::high_resolution_clock; using std::chrono::duration_cast; using std::chrono::milliseconds; // 定数定義：テストデータ量 constexpr size_t DATA_SIZE = 50000000; // 5000万個要素 constexpr int TEST_ITERATIONS = 5; // 5回実行して平均を取る /** * @brief 大規模なベクトルを作成し、テストに使用。 */ std::vector\u0026lt;int\u0026gt; create_test_data() { std::vector\u0026lt;int\u0026gt; data(DATA_SIZE); std::iota(data.begin(), data.end(), 1); // 1, 2, 3, ... を要素として埋める return data; } /** * @brief 伝統的なパターン：インデックス付きの for ループを使用。 * * @param data 探索するベクトル。 * @return long long シミュレーションされた計算結果。 */ long long traditional_loop(const std::vector\u0026lt;int\u0026gt;\u0026amp; data) { long long sum = 0; // std::size_t を使用して、signed/unsigned の警告を回避 for (std::size_t idx = 0; idx \u0026lt; data.size(); ++idx) { const int item = data[idx]; // シミュレーションされた複雑な計算：要素値 + インデックスの平方根（コンパイラがループ全体を最適化しないように） sum += (long long)item + (long long)std::sqrt(idx); } return sum; } /** * @brief Enumerate パターン：std::views::enumerate を使用。 * * @param data 探索するベクトル。 * @return long long シミュレーションされた計算結果。 */ long long enumerate_loop(const std::vector\u0026lt;int\u0026gt;\u0026amp; data) { long long sum = 0; // 構造束 [idx, item] を使用 for (const auto\u0026amp; [idx, item] : std::views::enumerate(data)) { // idx はインデックス (std::size_t) // item は要素の参照 (const int\u0026amp;) // シミュレーションされた複雑な計算：要素値 + インデックスの平方根 sum += (long long)item + (long long)std::sqrt(idx); } return sum; } /** * @brief 実行性能テストを実行し、結果を出力。 * * @param name テスト名。 * @param func テストするループ関数。 * @param data 処理するデータ。 * @return long long 実行時間（ミリ秒）。 */ long long run_test(const std::string\u0026amp; name, std::function\u0026lt;long long(const std::vector\u0026lt;int\u0026gt;\u0026amp;)\u0026gt; func, const std::vector\u0026lt;int\u0026gt;\u0026amp; data) { std::cout \u0026lt;\u0026lt; \u0026#34;--- \u0026#34; \u0026lt;\u0026lt; name \u0026lt;\u0026lt; \u0026#34; ---\\n\u0026#34;; long long total_duration_ms = 0; for (int i = 0; i \u0026lt; TEST_ITERATIONS; ++i) { auto start = high_resolution_clock::now(); // コンパイラが関数呼び出しを最適化しないようにする volatile long long result = func(data); auto end = high_resolution_clock::now(); auto duration = duration_cast\u0026lt;milliseconds\u0026gt;(end - start); total_duration_ms += duration.count(); // 結果が使用されることを確認し、最適化を回避しながら、2つのモードの結果の一致を確認 if (i == 0) { std::cout \u0026lt;\u0026lt; \u0026#34; [結果のチェック]: \u0026#34; \u0026lt;\u0026lt; result \u0026lt;\u0026lt; \u0026#34;\\n\u0026#34;; } std::cout \u0026lt;\u0026lt; \u0026#34; Iteration \u0026#34; \u0026lt;\u0026lt; i + 1 \u0026lt;\u0026lt; \u0026#34; Time: \u0026#34; \u0026lt;\u0026lt; duration.count() \u0026lt;\u0026lt; \u0026#34; ms\\n\u0026#34;; } long long avg_duration_ms = total_duration_ms / TEST_ITERATIONS; std::cout \u0026lt;\u0026lt; \u0026#34; 平均時間: \u0026#34; \u0026lt;\u0026lt; avg_duration_ms \u0026lt;\u0026lt; \u0026#34; ms\\n\u0026#34;; return まとめ比較 std::cout \u0026lt;\u0026lt; \u0026#34;\\n==============================\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;最終パフォーマンス比較\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;==============================\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;伝統的なループ平均時間: \u0026#34; \u0026lt;\u0026lt; traditional_time \u0026lt;\u0026lt; \u0026#34; ms\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;enumerateループ平均時間: \u0026#34; \u0026lt;\u0026lt; enumerate_time \u0026lt;\u0026lt; \u0026#34; ms\\n\u0026#34;; ## 完全実行可能なテストデモ（C++23） ```cpp #include \u0026lt;iostream\u0026gt; #include \u0026lt;vector\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;numeric\u0026gt; #include \u0026lt;ranges\u0026gt; #include \u0026lt;algorithm\u0026gt; #include \u0026lt;cmath\u0026gt; #include \u0026lt;functional\u0026gt; // 別名簡略化 using std::chrono::high_resolution_clock; using std::chrono::duration_cast; using std::chrono::milliseconds; // 定数定義：テストデータ量 constexpr size_t DATA_SIZE = 50000000; // 5000万個要素 constexpr int TEST_ITERATIONS = 5; // 5回実行して平均を取る /** * @brief テスト用の大きなベクトルを作成します。 */ std::vector\u0026lt;int\u0026gt; create_test_data() { std::vector\u0026lt;int\u0026gt; data(DATA_SIZE); std::iota(data.begin(), data.end(), 1); // 1, 2, 3, ... を埋める return data; } /** * @brief 伝統的なパターン：インデックス付きの for ループを使用します。 * * @param data 探索するベクトル。 * @return long long シミュレーションされた計算結果。 */ long long traditional_loop(const std::vector\u0026lt;int\u0026gt;\u0026amp; data) { long long sum = 0; // std::size_t を使用して、signed/unsigned の警告を回避 for (std::size_t idx = 0; idx \u0026lt; data.size(); ++idx) { const int item = data[idx]; // 複雑な計算をシミュレーション：要素値 + インデックスの平方根（コンパイラがループ全体を最適化しないように） sum += (long long)item + (long long)std::sqrt(idx); } return sum; } /** * @brief Enumerate パターン：std::views::enumerate を使用します。 * * @param data 探索するベクトル。 * @return long long シミュレーションされた計算結果。 */ long long enumerate_loop(const std::vector\u0026lt;int\u0026gt;\u0026amp; data) { long long sum = 0; // 構造化バインディング [idx, item] を使用 for (const auto\u0026amp; [idx, item] : std::views::enumerate(data)) { // idx はインデックス (std::size_t) // item は要素の参照 (const int\u0026amp;) // 複雑な計算をシミュレーション：要素値 + インデックスの平方根 sum += (long long)item + (long long)std::sqrt(idx); } return sum; } /** * @brief パフォーマンステストを実行し、結果を出力します。 * * @param name テスト名。 * @param func 実行するループ関数。 * @param data 処理するデータ。 * @return long long 実行時間（ミリ秒）。 */ long long run_test(const std::string\u0026amp; name, std::function\u0026lt;long long(const std::vector\u0026lt;int\u0026gt;\u0026amp;)\u0026gt; func, const std::vector\u0026lt;int\u0026gt;\u0026amp; data) { std::cout \u0026lt;\u0026lt; \u0026#34;--- \u0026#34; \u0026lt;\u0026lt; name \u0026lt;\u0026lt; \u0026#34; ---\\n\u0026#34;; long long total_duration_ms = 0; for (int i = 0; i \u0026lt; TEST_ITERATIONS; ++i) { auto start = high_resolution_clock::now(); // コンパイラが関数呼び出しを最適化しないようにする volatile long long result = func(data); auto end = high_resolution_clock::now(); auto duration = duration_cast\u0026lt;milliseconds\u0026gt;(end - start); total_duration_ms += duration.count(); // 結果が使用されることを確認し、最適化を回避しながら、2つのモードの結果の一致を確認 if (i == 0) { std::cout \u0026lt;\u0026lt; \u0026#34; [結果のチェック]: \u0026#34; \u0026lt;\u0026lt; result \u0026lt;\u0026lt; \u0026#34;\\n\u0026#34;; } std::cout \u0026lt;\u0026lt; \u0026#34; Iteration \u0026#34; \u0026lt;\u0026lt; i + 1 \u0026lt;\u0026lt; \u0026#34; Time: \u0026#34; \u0026lt;\u0026lt; duration.count() \u0026lt;\u0026lt; \u0026#34; ms\\n\u0026#34;; } long long avg_duration_ms = total_duration_ms / TEST_ITERATIONS; std::cout \u0026lt;\u0026lt; \u0026#34; 平均時間: \u0026#34; \u0026lt;\u0026lt; avg_duration_ms \u0026lt;\u0026lt; \u0026#34; ms\\n\u0026#34;; ## 完全実行可能なテストデモ (C++23) ```cpp if (traditional_time \u0026lt; enumerate_time) { std::cout \u0026lt;\u0026lt; \u0026#34;\\n結論: Traditional Loop がわずかに速かった。\\n\u0026#34;; double diff = (double)(enumerate_time - traditional_time) / traditional_time * 100.0; std::cout \u0026lt;\u0026lt; \u0026#34;差分: enumerate モードで \u0026#34; \u0026lt;\u0026lt; diff \u0026lt;\u0026lt; \u0026#34;% 遅い。\\n\u0026#34;; } else if (enumerate_time \u0026lt; traditional_time) { std::cout \u0026lt;\u0026lt; \u0026#34;\\n結論: Enumerate Loop がわずかに速かった。\\n\u0026#34;; double diff = (double)(traditional_time - enumerate_time) / enumerate_time * 100.0; std::cout \u0026lt;\u0026lt; \u0026#34;差分: traditional モードで \u0026#34; \u0026lt;\u0026lt; diff \u0026lt;\u0026lt; \u0026#34;% 遅い。\\n\u0026#34;; } else { std::cout \u0026lt;\u0026lt; \u0026#34;\\n結論: 両方のモードがほぼ同じパフォーマンスを示した。\\n\u0026#34;; } return 0; } 完全実行可能なテストデモ（C++23） パフォーマンス差異分析と結論 理論分析 C++ において、性能差の根本原因はコンパイラがゼロオーバーヘッド抽象 (Zero-Overhead Abstraction) を実現できるかどうかにあります。\n伝統的なループ: メモリのアドレスとインデックスを直接操作する方法であり、最も低レベルで効率的です。 std::views::enumerate ループ: enumerate_view という抽象層を導入します。内部では、イテレータを使用してインデックスと値をペア化します。 現代の高度に最適化されたコンパイラ (GCC/Clang で O2/O3 オプティマイズを有効にした場合など) は、インライン化 (inline) して enumerate_view とそのイテレータの操作を実行し、ループアンローリング (loop unrolling) などの最適化を行います。最終的に、std::views::enumerate ループが生成するアセンブリコードは、伝統的なインデックスループが生成するアセンブリコードとほぼ同じになります。 実際テスト結果 実機実行デモの結果（O2/O3最適化を使用）に基づくと： | 伝統的インデックスループ | X (ベースライン) | 約0% | 低：インデックスを手動で管理する必要があり、エラーが発生しやすい |\n実験結果の結論 パターン 平均時間 (ms) 性能差 可読性/安全性 std::views::enumerate X ± 極小変動 ≈ 0% 高： 自動インデックス、簡潔で安全 実験結果の結論 結論： コンパイラ最適化を使用した場合、std::views::enumerate パターンと従来のインデックスループパターンは、パフォーマンスにおいてほぼ差がありません。したがって、その性能は同等であると言えます。 そのため、C++23 以降では、std::views::enumerate パターンを推奨します。これは、性能を犠牲にすることなく、コードの可読性、簡潔性、安全性を大幅に向上させるためです。\n","date":"2025-10-09","language":"ja","permalink":"https://ttf248.life/ja/p/c23-introduces-new-features-enumerate-and-ranges/","tags":["c++","構文シュガー"],"title":"C++23 で導入された新機能である enumerate と ranges","year":"2025"},{"categories":["魚の7秒間の見聞"],"content":"私の記憶によると、小米が当初注目を集められたのは、実証された製品力と、際立ったコストパフォーマンスの高さによるものです。初期の同スペック機種と比較すると、他のブランドは価格が4～5千元に達することもあったのですが、小米は価格を2千元台前半に抑えることができました。その頃には、周囲の人々が携帯電話を買い替える理由として、「低コストで高スペック」という選択肢を選んでいた人が多くいました。\n現状 しかし最近のフラッグシップ機2～3世代では、アップデート幅が明らかに縮小している。毎回新品のスペックや機能紹介を見ると、なかなか「これはすごい！」という印象がなく、ほとんどが微調整に過ぎない：例えばカメラのアルゴリズム最適化、バッテリー持続時間のわずかな向上、あるいは外観を新しいカラーに変更するなど、記憶に残るような核心的な変更は少ない。 小米17の文字版発表会を読み終えると、この感覚はさらに明確になった——今回の製品のアップデートは依然として限定的で、性能や機能ともに「小修小補」の域を出ない。 実際には小米だけでなく、今現在は全体的にデジタル技術業界が同様の状況に直面している：ハードウェア分野での顕著なブレークスルーが難しくなり、業界全体の勢いは減速傾向にあるようだ。かつてのように毎年目覚ましい新進撃を遂げるわけではなく——ディスプレイのリフレッシュレート向上、充電速度の倍増など、今ではハードウェアで画期的なブレークスルーを実現するには、明らかに困難になっている。 知乎には理性的ユーザーが多くいるため、小米17発表会の関連トピックの下には一面倒の批判が並び、アップデートの強度が小さいという意見が多い。\nマーケティング力 小米SU7のベストセラーは、これまで注視されていなかった大量の女性ユーザーにリーチし、小米にとって新たな顧客獲得を促した。\nまた、ほぼ同時進行で「小米16が直接改名して小米17になった」という事件が起こり、その注目度を乗せている。この動きは、外界における小米スマートフォンに対する固定観念を打ち破るだけでなく、「乗り換え」によって話題性を生み出している。\nSU7が蓄積したユーザーの好感度は、改名イベントの世論の声量と共鳴し、SU7に関心のある小米ファンは、そのスマートフォン製品に興味を持ち、改名によって小米に気づいた潜在顧客も、SU7の評判をより詳しく知りたいと考えている。\n最終的に、この連携により、小米17の発表会が非伝統的なユーザー層に突破口を開き、これまで小米を知らなかった層にリーチすることに成功した。\n","date":"2025-09-26","language":"ja","permalink":"https://ttf248.life/ja/p/productivity-and-marketing/","tags":["製品力","マーケティング力","小米 (Xiǎomǐ)","アップル","華為 (Huawei)","スマートフォン"],"title":"製品力とマーケティング力","year":"2025"},{"categories":["コンピューター"],"content":"組み立てやアップグレードを行う際に、メモリ条に「DDR5-6000 CL36」、「DDR5-6000 CL30」といったパラメータが記載されているのを見かけることがあります。その中では、「6000」はメモリの周波数（MHz）を表し、「CL36」「CL30」における「CL」は“CAS Latency”（列アドレス選択遅延）の略称であり、私たちがよく言う“レイテンシ”です。 したがって、CL36、CL30、C28 の違いは何ですか？周波数が同じ場合、それらはパフォーマンスに大きな影響を与えますか？また、どのように選択すればよいのでしょうか？ 今日は、このトピックについて詳しく掘り下げていきましょう。\n以前にメモリ周波数に関する内容を記述しました：[PC 構築のあれこれ]（https://example.com/post/2020/05-电脑组装那些事）\nメモリレイテンシ（CAS Latency）とは？ 簡単に言うと、CAS Latency（CL） は、メモリが読み出し命令を受信してから実際にデータを開始出力するまでの間のクロックサイクル数を示します。この数値が小さいほど、メモリの応答速度は速く、遅延は低くなります。\n例を挙げます：\nDDR5-6000 CL36：6000MHz の周波数で、メモリが 36 個のクロックサイクル待つことを意味します。 DDR5-6000 CL30：同じ周波数では、30 個のサイクル待ちになります。 周波数は同じでも、CL 値が低いほど、実際の遅延（Latency）は小さくなります。\n実際のレイテンシはどのように計算しますか？ 多くの人が周波数が高いほど高性能だと誤解していますが、実際には実際のレイテンシ = (CL ÷ 周波数) × 2000（単位：ナノ秒、ns）です。以下に比較を示します： | DDR5-6000 CL36 | 6000 | 36 | (36 ÷ 6000) × 2000 ≈ 12.0 ns |\n実際のレイテンシはどのように計算しますか？ モデル 周波数（MHz） CL 値 実際のレイテンシ（ns） DDR5-6000 CL30 6000 30 (30 ÷ 6000) × 2000 ≈ 10.0 ns 実際のレイテンシはどのように計算しますか？ モデル 周波数（MHz） CL 値 実際のレイテンシ（ns） DDR5-6000 CL28 6000 28 (28 ÷ 6000) × 2000 ≈ 9.33 ns 実際の遅延はどのように計算する？ 上記のように、CL28 は CL36 の実際の遅延を約 22% 低下していることが確認できます。遅延に敏感なアプリケーション（ゲーム、高頻度取引、リアルタイムレンダリングなど）においては、この差が明確なパフォーマンス向上をもたらす可能性があります。\nパフォーマンスの違いは本当に大きいのか？ 日常業務、ウェブブラウジング、動画再生といったシーンでは、CL36 と CL28 の違いはほとんど認識できません。しかし、以下のシーンにおいては、低レイテンシメモリの利点がより顕著になります。\nゲームフレーム生成時間（Frame Time）の安定性：より低い遅延は、カクツキを軽減し、特にCPU負荷の高いゲーム（例: 《CS2》、《英雄伝説 オペラ ファースト》、《永劫なき世界》など）において有効です。 コンテンツ制作とコンパイル：メモリ帯域幅と遅延に依存するワークフロー（例: 大規模コードのコンパイル、3Dレンダリングキャッシュ）も恩恵を受けます。 オーバークロックの可能性：通常、低レイテンシメモリは、海力士 A-die や M-die などのチップレットを使用した製品の方が体質が良く、さらなるオーバークロックに適しています。 ただし、注意点として、低レイテンシは一般的に価格が高く、マザーボード/BIOSの互換性もより要求されるということです。もしあなたのマザーボードが EXPO/XMP 2.0 をサポートしていないか、BIOS が古い場合は、CL28 の高クロックメモリを安定して動作させることができない可能性があります。\nそこで、6000MHz ならどれを選ぶのが良いでしょうか？ ほとんどのユーザー、特に AMD Ryzen 7000/8000 シリーズプロセッサー を搭載している方にとって、DDR5-6000 CL30 が現在の「デザート」構成です：\n公式 JEDEC 仕様で推奨される周波数が 6000MHz であり、CL30 は AMD による公式検証済みのタイミングです。 コストパフォーマンスが高く、価格も適中であり、互換性にも優れています。 実測遅延を 10ns 付近に抑え、性能と安定性を両立しています。 もしあなたが 極上のパフォーマンスを求めるプレイヤー や、限界のフレームレートを追求したいのであれば、およびマザーボードが良好にサポートしている場合（例：B650/X670 高端モデル）、CL28 Bahkan CL26 のモデルも検討できますが、手動での調整や電圧の微調整が必要になる可能性があることを覚悟してください。\n一方、CL36 は使用可能ですが、通常はエントリーレベルの DDR5 メモリであり、遅延が偏っているため、予算が非常に限られている場合にのみ推奨されます。\nまとめ C36、C30、C28 はメモリの CAS Latency（レイテンシ）を指します。数値が低いほど遅延が小さくなります。 同じ周波数でいうと、CL28 が CL36 よりも約 22% 遅延が少なく、性能面で有利です。 DDR5-6000 CL30 は現状最もバランスの取れた選択肢 であり、ほとんどのユーザーに適しています。 極上のパフォーマンスを追求する場合は CL28 を選択し、予算に限りがある場合は CL36 を受け入れますが、遅延と価格を考慮する必要があります。 ","date":"2025-09-24","language":"ja","permalink":"https://ttf248.life/ja/p/memory-timing-c36-c30-and-c28-what-do-these-mean-which-one-is-more-suitable-at-a-frequency-of-6000mhz/","tags":["デスクトップパソコン","DDR5","メモリ周波数"],"title":"メモリのタイミング C36、C30、C28 の意味は以下の通りです。\n\n*   **タイミング（Timing）**: メモリのデータ転送におけるクロックサイクルとデータ転送サイクルの関係を表す指標です。数値が小さいほど、より高速なタイミングと言えます。\n*   **C36, C30, C28**: これらの数字は、メモリのタイミングウィンドウ（Timing Window）を指します。具体的には、メモリコントローラがメモリに要求したタイミングと、メモリが実際にデータを提供できるタイミングとの差を表しています。数値が大きいほど、より遅いタイミングとなります。\n\n6000MHz 頻度下でどのタイミングを選ぶかは、以下の要素によって異なります。\n\n*   **CPU とメモリの互換性**: CPU がサポートするメモリのタイミングに合わせる必要があります。\n*   **システムの安定性**: より高速なタイミングは、システム全体の安定性に影響を与える可能性があります。\n*   **パフォーマンス**: 一般的に、より高速なタイミングは、データ転送速度を向上させ、パフォーマンスを改善します。\n\nそのため、CPU とメモリの互換性を確認し、テスト環境で実際に動作を確認しながら最適なタイミングを選択することをお勧めします。","year":"2025"},{"categories":["コンピューター"],"content":"7月の頃、思いつきで、週末に特にすることがなく、デスクトップパソコンのホコリを掃除しようと思い立ちました。4～5年ほど掃除していなかったので、確かにホコリもかなり溜まっていたのです。掃除が終わってシステムを再起動すると、すべて正常に動作し、普段からパソコンをシャットダウンせずに長期間稼働させていたため、シャットダウンしたディスプレイの電源を切っておき、幸い妻が転住してきたので、夜になると彼女が見たことのない様々な光源の下で、手当たり次第にパソコンをシャットダウンしてくれました。\n散热器 本来应该写稿子，重装系统各种事情掺杂进来，忘记了，人脑有时候就是这么神奇，今天突然想起来了。 システム起動失敗 数日ごとに起動を試みるも、システムがブルースクリーンになり、エラーメッセージが何度か変化して最終的に起動できなくなりました。ハードディスクの清掃中に、ハードディスクが固定されずに落下し、システムブートファイルが見つからなかったため、起動に失敗したと推測しました。エラーメッセージは明らかにブートロードに失敗していることを示しており、USBドライブで正常にPEシステムに入力できました。そこで、落ち着いて次の手順を実行しました。\nハードディスクケーブルを抜き差しする（ハードディスクが多数あり、特にブートディスクを確認） 徹底的にフォーマットしてシステムドライブを再インストール 他のディスクをハードディスクとして使用し、再インストール ハードディスクに問題がないか、ハードディスクチェックツールで確認 BOIS設定を変更する（UEFIと互換モードなど様々な試み） 上記の手順に基づいて、ハードディスクをMBR形式に変更し、ブート設定を再構成してシステムをインストール 週末一通りの作業を終え、システムが正常に起動し、他に問題も見つからなかったため、なぜ古いブートモードに切り替える必要があったのか疑問に思いました。\n華碩製のマザーボードを購入した際に、デフォルトでUEFIモードになっており、長年にわたってシステム再インストールもUEFIモードを使用していました。今回、様々な方法を試しても解決しないのであれば…。\n","date":"2025-09-24","language":"ja","permalink":"https://ttf248.life/ja/p/desktop-boot-loader-failure/","tags":["トラブルシューティング","UEFI","MBR"],"title":"デスクトップPCへのローディング失敗 (Desukutoppu Ki e no Roodingu Shibi)","year":"2025"},{"categories":["メモ書き雑感"],"content":"情報過多の時代において、私たち一人ひとりが無意識のうちに「情報カプセル」の中に閉じこもっている。アルゴリズムが私たちの興味のあるコンテンツを推薦し、長期的には私たちの視野が形lessに狭まる。そしてこの現象は、スマートフォンの市場においても同様に当てはまるようだ—ブランドの忠誠心、メディアの指向性、コミュニティの声がすべて消費者に次々と「カプセル」を織りなしている。\nしかし最近、小米の一挙手一投足は、静かな湖面に石を投げ込むようなものであり、この無形の壁を打ち破ろうと波紋を広げた。\nプロンプト：情報カプセル、小米携帯電話の16を17に変更するのは一時的な行動ではなく、多くの在庫があること、华为のハイエンド路線、小米のハイエンド路線は最終的に製品力で語られる\n小米的「陽謀」（暗算）：16をスキップし、17に正面突破 Xiaomiは、発売間近となる次期フラッグシップモデルを、毅然と「小米16」から「小米17」へと名称を変更しました。これは、直接AppleのiPhone 17に対抗するという意図を明確に示すものです。これは単なる衝動的な思いつきではありません。このような規模の巨大な企業にとって、どのフラッグシップモデルも、命名、備品、マーケティングは、一挙手一投足が全身に及ぶ大規模なプロジェクトです。数百万もの梱包材、宣伝物、チャネルコミュニケーションなどすべてを数か月、あるいは1年以上前から計画する必要があるのです。\n今回の名称変更は、Xiaomiが綿密に練り上げた「陽謀」（暗算）であり、ブランド戦略における大胆な賭けなのです。これは明確な信号を送っています。「高性价比」というイメージに留まることなく、AppleやHuaweiが長年支配してきたハイエンド市場への正面突破を目指すということです。\nデジタル上でiPhoneと同一化することで、Xiaomiは消費者の慣習的な思考を覆し、自社の製品をトップレベルのフラッグシップモデルと同等の対話の文脈の中に置こうとしています。これは、Xiaomiが自社製品の品質に対する高揚した自信の宣言であり、ハイエンド市場に参入して以来5年間で最も大胆かつ決断的な試みなのです。\n華為のハイエンド戦略：逆境の中で輝きを取り戻す ハイエンド市場について言えば、華為は避けて通れないテーマです。多くの周知された外部圧力の後、華為の高難易度路線は異常に困難でしたが、同時に異常なほど確固たるものでした。画像技術における継続的な深耕と自社開発チップのブレークスルーにより、華為PuraおよびMateシリーズは依然としてハイエンド市場における基準となる製品です。\n華為の戦略は、より「内功（内なる力）」の鍛錬に似ています。強力な技術的障壁を構築することで、XMAGE画像ブランド、昆仑ガラス、鴻蒙（ホンコン）オペレーティングシステムなどのように、製品の中核的な差別化要素を作り出しています。サプライチェーンの巨大な課題にも直面しながらも、華為は製品力の継続的な向上によって、非常に高いユーザーロイヤリティを確立しました。\n現在、華為は中国におけるハイエンド市場でのシェアが着実に回復しており、これは忍耐力と製品力に関する勝利の物語そのものです。その高難易度路線は、技術革新とブランドの耐久性を基盤に、逆境の中で一歩ずつ進むことで確立されました。\n高端の争いは、結局は「製品力」の対決 小米の「一挙手一投足で完了」あるいは、ファーウェイの「着実に攻める」といった、それぞれ異なるハイエンド戦略を展開する中、最終的に落着点となるのは、「製品力」である。\nハイエンドユーザーがより高い価格を支払う理由は、単なるブランドイメージだけではない。それは、製品背後の技術、体験、デザイン、そしてサービスに対する全方位的な承認だからだ。喧騒としたマーケティングの後に残るのは、実際に体験したことによる満足度であり、それがユーザーを留める鍵となる。\nそれでは、注目点を製品自体に絞って見ていこう。\n画像能力： ファーウェイPura 70 Ultraは、独自の伸縮式カメラと強力なXMAGE影像システムにより、スマートフォン写真の分野で継続的にリーダーシップを発揮している。一方、小米17シリーズも、ライカとの深度協力を受けており、新たなセンサーとアルゴリズムを搭載し、業界トップレベルの水準への挑戦を目指している。 コア性能： 小米17は、高通社の最新の骁龍旗舰チップを初搭載し、性能の解放において天然の優位性を確立している。一方、ファーウェイは、自社開発チップのイテレーションを通じて、電力効率とシステム連携における独自の競争力を発揮している。 ディスプレイとデザイン： 両社ともディスプレイ品質、筐体素材、デザイン言語において最大限の努力を惜しまない。昆仑ガラスの堅牢性と耐久性は、小米がディスプレイ表示技術に継続的に投資した結果であり、それぞれ製品の明確な特徴となっている。 エコ体験： 鴻蒙（ファーウェイ）システムの分散能力は、ファーウェイにシームレスなエコ体験を提供している。一方、小米のHyperOSも、独自のスマートエコシステム閉環構築に向けて努力している。 マーケティング戦略は、消費者の「情報茧房」を打破し、より多くの人にブランドの雄心と変化を見せることを可能にする。しかし、消費者を「破房而出」（家を出る）させ、自社の製品に心酔して乗り換えさせるには、最終的には過硬な製品力こそが、断固たる選択肢を提供しなければならない。\n小米が数字“16”を“17”に変えたことは、単なる名前の変更ではなく、そのブランド心态と市場戦略における躍遷である。ファーウェイは、嵐の中でハイエンドブランドの根拠を再構築した。中国ハイエンドスマートフォン市場におけるこの双雄の博弈は、まさに精彩を増していく段階に入っている。\n消費者にとっては、これは朗報と言えるだろう。巨頭たちが互いに譲歩し、製品自体に注目するようになると、最終的にはより多様で、体験至上主義の素晴らしい時代が到来するはずだ。そして、このハイエンドの争いの中で最後に笑うのは誰なのかは、時間と各ユーザーの指先が最終的な答えを示すだろう。\n","date":"2025-09-19","language":"ja","permalink":"https://ttf248.life/ja/p/breaking-through-the-cocoon-examining-huawei-and-xiaomis-high-end-rivalry-following-xiaomi-17s-renaming/","tags":["AI霊感衝突坊","小米 (Xiǎomǐ)","名前騒動 (Namae sōdō)"],"title":"蛹から抜け出すように：小米17の名称変更を通して、華テックと小米のハイエンドな駆け引きを見る","year":"2025"},{"categories":["AI霊感衝突坊","コンピューター"],"content":"現代インターネットアーキテクチャにおいて、高可用性はシステム設計における重要な検討事項です。本稿では、KeepalivedとHAProxyを使用して高可用なロードバランシングクラスタを構築し、サービスの継続性と信頼性を確保する方法について詳細に解説します。\n実際の構成部分が検証されていないため、本文の構成はAIによって作成されています\nこの画像は「タスク計画」というタイトルで、おそらくタスクのスケジュールやリストを示していると思われます。詳細な翻訳のためには画像の具体的な内容を確認する必要がありますが、一般的な表現として以下のように記述できます。\nタスク計画 (Tasukku Keikaku) - 任務計画 (Tanmoku Keikaku)\n技術概要 Keepalived の概要 Keepalived は、VRRP（Virtual Router Redundancy Protocol）プロトコルを基盤とした高可用性ソリューションであり、主にサーバーのフェイルオーバーとロードバランシングを実現するために使用されます。\n主な特徴：\nVRRP プロトコル対応: 仮想IPアドレスの主/備切り替えの実装 健康チェック: サービスの状態を監視し、自動的に故障トランスファーを実行 設定の簡素化: 設定ファイルのみで複雑な高可用性アーキテクチャを実現 軽量: リソース消費量が少なく、性能に優れている 動作原理： Keepalived は、VRRP プロトコルを通じて複数のサーバー間で仮想IPアドレスを共有します。正常時には、主サーバーが仮想IPアドレスを持ちサービスを提供し、主サーバーが故障した場合、備サーバーが自動的に仮想IPアドレスを接管し、サービスの停止を防ぎます。\nHAProxy の概要 HAProxy は、高性能なロードバランサーおよびリバースプロキシサーバーであり、高負荷環境で広く利用されています。 主な機能：\nロードバランシング: 複数のロードバランシングアルゴリズムをサポート ヘルスチェック: バックエンドサーバーの状態をリアルタイムに監視 SSL終端: HTTPS トラフィックの処理をサポート 統計モニタリング: 詳細な実行状態の統計情報を提供 利用シーン： Web サービス のロードバランシング データベース接続プーリング マイクロサービスゲートウェイ API インターフェース のプロキシ アーキテクチャ設計 全体アーキテクチャ ┌─────────────────┐ │ Client │ └─────────┬───────┘ │ ┌─────────▼───────┐ │ Virtual IP │ │ (VIP) │ └─────────┬───────┘ │ ┌───────────────┼───────────────┐ │ │ │ ┌─────────▼───────┐ ┌─────────▼───────┐ │ HAProxy-1 │ │ HAProxy-2 │ │ (Master) │◄────────────►│ (Backup) │ │ + Keepalived │ VRRP │ + Keepalived │ └─────────┬───────┘ └─────────┬───────┘ │ │ └──────────┬─────────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌───────▼───────┐ ┌──────▼──────┐ ┌───────▼───────┐ │ Web Server 1 │ │ Web Server 2│ │ Web Server 3 │ │ Backend │ │ Backend │ │ Backend │ └───────────────┘ └─────────────┘ └───────────────┘ 全体アーキテクチャ ┌─────────────────┐ │ クライアント │ └─────────┬───────┘ │ ┌─────────▼───────┐ │ 仮想IP (VIP) │ └─────────┬───────┘ │ ┌───────────────┼───────────────┐ │ │ │ ┌─────────▼───────┐ ┌─────────▼───────┐ │ HAProxy-1 │ │ HAProxy-2 │ │ (マスター) │◄────────────►│ (バックアップ) │ │ + Keepalived │ VRRP │ + Keepalived │ └─────────┬───────┘ └─────────┬───────┘ │ │ └──────────┬─────────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌───────▼───────┐ ┌──────▼──────┐ ┌───────▼───────┐ │ Web Server 1 │ │ Web Server 2│ │ Web Server 3 │ │ バックエンド │ │ バックエンド │ │ バックエンド │ └───────────────┘ └─────────────┘ └───────────────┘ コンポーネントの説明 仮想IP (VIP): 顧客がアクセスする統一的なエントリポイント HAProxy 主備ノード: ロードバランシングサービスを提供し、Keepalivedを使用して高可用性を実現します バックエンドサーバー: 実際にサービスを提供するWebサーバー 環境準備 サーバ計画 役割 IPアドレス ホスト名 サービス HAProxy 主ノード 192.168.1.10 lb-master HAProxy + Keepalived サーバ計画 役割 IPアドレス ホスト名 サービス HAProxy 備後端 192.168.1.11 lb-backup HAProxy + Keepalived サーバー構成 ロール IPアドレス ホスト名 サービス 仮想IP 192.168.1.100 - VIP サーバー計画 役割 IPアドレス ホスト名 サービス Webサーバー1 192.168.1.20 web1 Nginx/Apache サーバー構成 ロール IPアドレス ホスト名 サービス Webサーバー2 192.168.1.21 web2 Nginx/Apache サーバー計画 ロール IPアドレス ホスト名 サービス Webサーバー3 192.168.1.22 web3 Nginx/Apache ソフトウェアのインストール HAProxy主備サーバに必要ソフトウェアをインストールします：\n# CentOS/RHEL yum install -y haproxy keepalived # Ubuntu/Debian apt-get update apt-get install -y haproxy keepalived # サービスを起動時に自動開始にする systemctl enable haproxy keepalived Keepalived 設定 主ノード設定 (lb-master) /etc/keepalived/keepalived.conf ファイルを作成します：\n! Configuration File for keepalived global_defs { router_id LB_MASTER script_user root enable_script_security } # HAProxyサービスのステータスを確認するスクリプト vrrp_script chk_haproxy { script \u0026#34;/etc/keepalived/check_haproxy.sh\u0026#34; interval 2 weight -2 fall 3 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass mypassword123 } virtual_ipaddress { 192.168.1.100/24 } track_script { chk_haproxy } notify_master \u0026#34;/etc/keepalived/notify.sh master\u0026#34; notify_backup \u0026#34;/etc/keepalived/notify.sh backup\u0026#34; notify_fault \u0026#34;/etc/keepalived/notify.sh fault\u0026#34; } 備中节点配置 (lb-backup) /etc/keepalived/keepalived.conf ファイルを作成します：\n! keepalived の構成ファイル global_defs { router_id LB_BACKUP script_user root enable_script_security } vrrp_script chk_haproxy { script \u0026#34;/etc/keepalived/check_haproxy.sh\u0026#34; interval 2 weight -2 fall 3 rise 2 } vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 90 advert_int 1 authentication { auth_type PASS auth_pass mypassword123 } virtual_ipaddress { 192.168.1.100/24 } track_script { chk_haproxy } notify_master \u0026#34;/etc/keepalived/notify.sh master\u0026#34; notify_backup \u0026#34;/etc/keepalived/notify.sh backup\u0026#34; notify_fault \u0026#34;/etc/keepalived/notify.sh fault\u0026#34; } HAProxy健康チェックスクリプト /etc/keepalived/check_haproxy.shというHAProxyの健康チェックスクリプトを作成します：\n#!/bin/bash # HAProxyプロセスが実行中か確認 if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ]; then # HAProxyを起動を試行 systemctl start haproxy sleep 2 # 再度チェックし、まだ実行されていない場合は終了 if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ]; then exit 1 fi fi # HAProxyポートがリッスン中か確認 if ! netstat -tuln | grep -q \u0026#34;:80 \u0026#34;; then exit 1 fi exit 0 状態通知スクリプト /etc/keepalived/notify.sh という状態通知スクリプトを作成します：\n#!/bin/bash TYPE=$1 NAME=$2 STATE=$3 case $STATE in \u0026#34;MASTER\u0026#34;) echo \u0026#34;$(date): Became MASTER\u0026#34; \u0026gt;\u0026gt; /var/log/keepalived-state.log ;; \u0026#34;BACKUP\u0026#34;) echo \u0026#34;$(date): Became BACKUP\u0026#34; \u0026gt;\u0026gt; /var/log/keepalived-state.log ;; \u0026#34;FAULT\u0026#34;) echo \u0026#34;$(date): Fault detected\u0026#34; \u0026gt;\u0026gt; /var/log/keepalived-state.log ;; *) echo \u0026#34;$(date): Unknown state: $STATE\u0026#34; \u0026gt;\u0026gt; /var/log/keepalived-state.log ;; esac スクリプトの実行権限を設定します：\nchmod +x /etc/keepalived/check_haproxy.sh chmod +x /etc/keepalived/notify.sh HAProxy 設定 メイン設定ファイル 主備ノード上で同じHAProxyの設定ファイル /etc/haproxy/haproxy.cfg を作成します：\nglobal log 127.0.0.1:514 local0 chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon defaults mode http log global option httplog option dontlognull option log-health-checks option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 # ページ設定の統計 listen stats bind *:8080 stats enable stats uri /stats stats realm HAProxy\\ Statistics stats auth admin:password123 stats refresh 30s # 前端設定 frontend web_frontend bind *:80 default_backend web_servers # 後端サーバー設定 backend web_servers balance roundrobin option httpchk GET /health server web1 192.168.1.20:80 check inter 2000 rise 2 fall 3 server web2 192.168.1.21:80 check inter 2000 rise 2 fall 3 server web3 192.168.1.22:80 check inter 2000 rise 2 fall 3 設定手順 グローバル設定:\nlog: 日志設定 chroot: セーフティサンドボックス stats socket: 管理インターフェース daemon: バックグラウンド実行 デフォルト設定: mode http: HTTPモード balance roundrobin: ラウンドロビンバランシング option httpchk: HTTPヘルスチェック timeout: 様々なタイムアウト設定 バックエンドサーバー: check: ヘルスチェックを有効にする inter 2000: チェック間隔2秒 rise 2: 連続2回成功した場合に可用とマークする fall 3: 連続3回失敗した場合に不可用とマークする サービス開始とテスト サービスの起動 主節点および副節点上でサービスを起動します：\n# HAProxyの起動 systemctl start haproxy systemctl status haproxy # Keepalivedの起動 systemctl start keepalived systemctl status keepalived VIP認証の確認 仮想IPが正しくバインドされているかを確認します：\n# 主ノードでIPアドレスを表示 ip addr show # 以下の様な出力が表示されるはずです： # eth0: \u0026lt;BROADCAST,MULTICAST,UP,LOWER_UP\u0026gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 # inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0 # inet 192.168.1.100/24 scope global secondary eth0:0 機能テスト 1. 負荷分散テスト # VIPに複数回アクセスし、リクエストの分配状況を監視 for i in {1..10}; do curl -s http://192.168.1.100/ | grep \u0026#34;Server\u0026#34; done 2. フェイルオーバーテスト # 主ノードでHAProxyサービスを停止する systemctl stop haproxy # VIPがバックノードに切り替わるのを監視する ip addr show # サービスの正常性を確認する curl http://192.168.1.100/ 3. バックエンドサーバー障害テスト # 一台のWebサーバーを停止する # web1サーバーで： systemctl stop nginx # HAProxy統計ページを監視する curl http://192.168.1.100:8080/stats モニタリングとメンテナンス ロギング監視 HAProxyログ # HAProxyログの確認 tail -f /var/log/haproxy.log # アクセス統計の確認 grep \u0026#34;HTTP/1.1\u0026#34; /var/log/haproxy.log | tail -20 Keepalivedログ # Keepalivedログの確認 tail -f /var/log/messages | grep keepalived # 状態変化ログの確認 tail -f /var/log/keepalived-state.log パフォーマンス監視 統計ページ監視 HAProxyの統計ページへのアクセス: http://192.168.1.100:8080/stats 主要指標:\nSession Rate: 会話レート Session Total: 総会話数 Bytes In/Out: 流量統計 Response Time: 応答時間 Server Status: サーバー状態 コマンドライン監視 # HAProxyプロセスの状態を確認 ps aux | grep haproxy # ポートのリスニング状態を確認 netstat -tuln | grep -E \u0026#34;(80|8080)\u0026#34; # 接続数を確認 ss -ant | grep :80 | wc -l よくあるトラブルシューティング 1. VIPの切り替え不可 問題現象: 主ノード故障後、VIPがバックアップノードに切り替わらない トラブルシューティング手順:\n# Keepalived設定を確認 keepalived -t -f /etc/keepalived/keepalived.conf # VRRP通信を監視 tcpdump -i eth0 vrrp # ファイアウォール設定を確認 iptables -L | grep vrrp 解決策:\nVRRPプロトコル通信が正常であることを確認 ネットワークインターフェースの設定を確認 認証パスワードの一致性を検証 2. 健康チェック失敗 問題現象: バックエンドサーバーが利用不可としてマークされている トラブルシューティング手順:\n# 手動で健康チェックを実行 curl -I http://192.168.1.20/health # HAProxyログを確認 grep \u0026#34;Health check\u0026#34; /var/log/haproxy.log 解決策:\n健康チェックURLにアクセス可能であることを確認 チェック間隔と閾値を調整 バックエンドサーバーの状態を確認 3. 負荷分散の不均衡 問題現象: リクエストがバックエンドサーバーに均等に分散されない トラブルシューティング手順:\n# 統計ページを確認 curl -s http://192.168.1.100:8080/stats # アクセスログを分析 awk \u0026#39;{print $6}\u0026#39; /var/log/haproxy.log | sort | uniq -c 解決策:\n負荷分散アルゴリズムの設定を確認 サーバーの重み設定を検証 セッション保持の要件を考慮 オプティマイズの提案 1. パフォーマンス最適化 # システムパラメータの調整 echo \u0026#39;net.core.somaxconn = 65535\u0026#39; \u0026gt;\u0026gt; /etc/sysctl.conf echo \u0026#39;net.ipv4.tcp_max_syn_backlog = 65535\u0026#39; \u0026gt;\u0026gt; /etc/sysctl.conf sysctl -p # HAProxy設定の最適化 # maxconn値を増やす # timeoutパラメータを調整する # 圧縮機能を有効にする 2. セキュリティ強化 # 統計ページへのアクセス制限 # haproxy.cfg に ACL ルールを追加 acl allowed_ips src 192.168.1.0/24 http-request deny if !allowed_ips # SSL/TLS の有効化 bind *:443 ssl crt /etc/ssl/certs/server.pem redirect scheme https if !{ ssl_fc } 3. モニタリングとアラート # 統合監視システム # Prometheusによる監視設定 # Grafanaダッシュボードの設定 # アラートルールを設定 結論 KeepalivedとHAProxyの組み合わせにより、高可用性を持つロードバランシングクラスタを構築しました。この構成には以下の利点があります。\n高可用性: VRRPプロトコルによる自動フェイルオーバーを実現 ロードバランシング: スマートなリクエスト分散により、システム性能を向上 健康チェック: リアルタイムでサービスの状態を監視し、故障ノードを自動的に除外 メンテナンスの容易さ: 設定が簡単で、管理も容易 コスト効率: オープンソースソフトウェアを使用することで、運用コストを削減 本番環境へのデプロイ時には、ネットワークセキュリティ、監視アラート、バックアップとリカバリなどの面での整備が必要であり、システムの安定性と信頼性を確保します。 ","date":"2025-09-19","language":"ja","permalink":"https://ttf248.life/ja/p/keepalived-haproxy-for-high-availability-load-balancing/","tags":["ロードバランシング","高可用性 (Kōyūyō)","Keepalived","HAProxy","クラスタリング","運用 (Un'yō)"],"title":"Keepalived + HAProxy を用いた高可用ロードバランシングの構築","year":"2025"},{"categories":["AI霊感衝突坊","投資 (tōshi)"],"content":"波詭雲譎の株式市場において、私たちはしばしば信仰と期待を羅針盤とし、霧の中を抜け出し富の彼岸を目指そうとする。しかし、航行が羅針盤の指針から逸れると、容易に方向感覚を失い、最悪の場合、座礁してしまうだろう。本稿はまさにそのような航海に関するものであり、それは**小米（シミー）**への執着から始まったものの、資本の波潮の中で幾度となく漂流したものである。\n信念と現実の交錯：小米の得失 6月、私は雷總への信仰と、小米の電気自動車の未来に対する美しい憧憬を抱き、毅然と高位で小米を買収した。当時、信仰の力は強力であり、それは雷總が資本家としての精明さを一時的に忘れさせ、最高位閃電配售所（Flash Delivery）がもたらすリスクを無視させることになった。幸いなことに、何度か波段操作が行われたものの、いずれもわずかな利益で終わったことで、私は初入港股市場の一点甘味を得ることができた。\nしかし、蜜汁（甘い誤算）した自信もまた伴うようになった。少額儲けた九方株の後に、私はある程度昏頭（ひどく愚かになる）し、合理的な分析に基づかない意思決定をするようになり、単に港股通ネット買い入資金流という一つの指標に依存するようになった。\n美団の「滑走路」と無謀な買い増し 資金の流れに便乗して、私は美団に目を向けた。しかし今回は、会社の財務データ、過去の推移を深く分析することなく、当時勃発していたデリバリー競争さえ認識していなかった。株価が下落し始めたとき、私はすぐに損切りをせず、むしろ無謀にポジションを追加した。\n香港株の一手株式価格が2～3万香港ドルで変動し、資金の制約により自由にポジション管理ができず、これは美団での損失をさらに悪化させた。この教訓から、香港市場において、無謀な買い増しは、常に水漏れしている浴缸に水を注ぎ込むようなものであり、結果として水の流出を加速させるだけであることを痛感した。\n「愚か者万福」の予期せぬ収穫 まさに私が美団の損失に悩んでいた時、ある偶然の出来事が起こった——私はアリババを買っていた。持ち帰ることはできなかったが、迅速に売却し、この利益で美団の一部損失を補填することができた。これがまさに「愚か者万福」と呼ばれるものであり、私を美団の泥沼から一時的に脱出させることを可能にしたのだ。\n資産運用：投資よりも重要な基礎 今回の経験を通して、株式市場の変動だけでなく、改めて自身の資産運用方法を見直すきっかけとなりました。当時、短期的な緊急資金として確保していた保険資金を、中国債券に投資してしまいました。この資金は2か月後に支払いに充当される予定でしたが、債券の短期保有による収益率は低く、流動性の問題も抱えることになりました。もし当時の時点でこの資金をマネーファンドに預金していれば、より安定した収益を得ることができ、資金ニーズにも柔軟に対応することが可能でした。\n","date":"2025-09-18","language":"ja","permalink":"https://ttf248.life/ja/p/from-meituans-losses-to-bond-mismatch/","tags":["投資 (tōshi)","ファイナンシャルプランニング","株式","恒生指数 (こうせいしじょ)","小米 (Xiǎomǐ)","美团 (Meituan)","アリババグループ (ありばばぐループ)","債券 (seitoken)","資金管理 (Shikin Kanri)"],"title":"美团の赤字から債券ミスマッチへ (Meitan no akiji kara kaibon mismatch he)","year":"2025"},{"categories":["メモ書き雑感","投資 (tōshi)"],"content":"誰もがそれぞれの人生の軌跡を持っており、そのため「好为人師」（人となりを勧める）は、大人の世界ではしばしば不要に見えます。\n世界観 私達の人生の旅は、それぞれ異なる成長背景から始まり、それらの経験が河のように匯聚し、流れ込み、最終的に私たち独自の人生軌跡を形作ります。 varje 物語、 každé 选择は、私たちの脳の中で交織・融合し、世界に対する見方、つまり世界観を凝縮します。 あなたが目にした悲劇は、他人にとっては単なる本の中の物語かもしれません。 あなたが軽視する生活は、別の人にとっては苦労して追い求める理想かもしれません。 互いの違いを理解し尊重することは、この多様な世界を洞察するための第一歩です。 時には沈黙もまた理解の一形態です。 空虚なことを言っているような話題が嫌いな場合、私は私の経験と見解を共有する方が良いでしょう。 しかし避けられないのは、あなたは遭遇し、静かに流れを見ることも戦略となるでしょう。\n投資観 私が主に固定金利＋（固收+）という投資方法を選択する理由は、その安定した収益と低いリスクを重視するためです。そのため、資産配分においては、このような商品に傾斜を置きます。\n株式については、短期と長期の二つの投資として区別します。私看来、短期投資は強い投機性を伴い、一種のギャンブルに他なりません。一方、長期投資こそが真の価値投資です。これは、自分自身で会社を設立し、資金調達から上場までの一連の流れを経験するようなものであり、株式配当だけでなく、経済の法則に対する深い洞察と将来への見通しを反映していると言えます。\n幼い頃から自分がギャンブル依存症であることに気づいていましたが、読書は理性的な角度から不合理な欲求をコントロールすることを可能にします。\n暗号通貨というものは、投資の観点からは好ましくありません。実質的な価値が見つからないためですが、その原理やリスクを理解し、以前に紹介されていたステーブルコインについても知っておく必要があります。\nえッグ（卵） WeChatではグループチャットを折りたたむことが可能ですが、あなたと友人のプライベートチャットも折りたたむことができます。設計の観点からすると、すべての会話は同じ階層に属しており、単に表示方法が異なるだけです。\n","date":"2025-08-22","language":"ja","permalink":"https://ttf248.life/ja/p/sometimes-you-need-to-learn-how-to-interrupt/","tags":["投資 (tōshi)","世界観","人生の洞察","自己成長 (Jiko Seishou)","固定費＋","自己認識 (じこにれつ)"],"title":"いくつかのことを学ぶ必要があるだろう、発言を遮る方法について。 (Sukitakunakun no koto o manabu hitsuyou ga aru darou, hatsugen o sadaru houhou ni tsuite.)\n\nAlternatively, a more concise translation:\n\n発言を遮ることを学ばなければならない。(Hatsugen o sadaru koto o manabanakereba naranai.)","year":"2025"},{"categories":["コンピューター"],"content":"最後にシステムを再インストールした後、私のPCには十分な量のPDFリーダーソフトが不足していました。 360ソフトウェア管家で、迅読PDFが推奨されており、さらに「特供版」も存在しました。その時、私はこのブランドに少し印象を持っており、「PDFリーダーのようなニッチなソフトウェアを、どうやって利益を上げるつもりなんだ？」と心の中で疑問を抱きました。プロモーション費用は回収できるのだろうか？ その後、迅雷のプロモーションで再び出会い、PCにも本当に必要だと感じたので、思い切ってインストールしました。\n相安無事？直到週末… インストール後、ソフトウェア使い続ける限り相安無事でした。AI機能がいくつか含まれていることに気づきましたが、有料だったため、自分には役に立たず、購入する気もありませんでした。当時まだ純粋に、この有料機能でどれくらい稼げるのかと想像していました。 しかし、今週末、ローカル開発中にQQ音楽が突然、原因不明にフリーズし、クラッシュしました。経験から判断して、タスクマネージャーを開き、残留プロセスがないか確認しました。結果、QQ音楽のプロセスは確かに存在しましたが、応答していませんでした。強制終了したところ、QQ音楽は正常に起動するようになりました。 しかしながら、私は偶然、\u0026quot;PDFエンジン\u0026ldquo;というプロセスの存在に気づきました。それはCPU使用率がほぼ10%を占めており、システム全体のリソース使用率はわずか19％でした。好奇心からファイルパスを開くと、それが私がインストールした迅読PDFだったことがわかりました。\n信頼の崩壊 これはソフトウェアの欠陥なのかどうかは分かりませんが、今のところ私はこのシステムに対する信頼を完全に失ってしまいました。\nその過剰なプロモーションを考えると、高額な費用がどこからか回収されているのではないかと疑念を抱き始めます。バックグラウンドで奇妙なタスクが実行されているように見えるのも、それ故に「妥当である」と感じてしまいます。\n","date":"2025-08-16","language":"ja","permalink":"https://ttf248.life/ja/p/a-unexpected-software-uninstall-journey/","tags":["ソフトウェア","負荷分散 (Roodo bansen)","国産","悪魔 (akumashi) – This is the most common and appropriate translation, conveying the sense of a \"rogue\" or \"scoundrel.\"\n\nAlternatively, depending on context, you could use:\n\n*   詐欺師 (sagi shi) - Swindler\n*   無法者 (fubasha) - Outlaw/Bandit"],"title":"予期せぬソフトウェアアンインストール体験 (Yoki sune no sorutowā aninsuto teiken)","year":"2025"},{"categories":["コンピューター"],"content":"以前使用していた製品は、コード開発を行う際には大差なく、しかしByteのSOLOは、コード開発において大きな違いが生じた。当初は招待コードを通じてベータ版に参加したが、現在はメールアドレスを提出し審査を待つ形式となり、審査に通れば利用できる。いつ申請を行ったのか記憶が曖昧なところだが、今日Traeから審査通過の通知を受け取った。\n字节SOLOの利点 通常のプロジェクト開発の流れを参考に、UIデザイン、要件分析、機能設計、技術方案の実装を行い、最後にコードの開発を行うという流れを採用しています。全体的なインタラクションロジックは、初心者にとってより親切であり、複雑なプロジェクトの場合は、従来のパターンの方がより効果的です。AIは補助ツールとして、コードの修正と最適化を行います。\n港美股APP開発 はい、タイトルは私が書いたプロンプト文通りです。追加の説明はありません。SOLOモード下では、まず要求ドキュメントと技術アーキテクチャドキュメントが出力され、ユーザーが問題がないことを確認すると、コードの開発が行われます。\n要求ドキュメント 技術アーキテクチャドキュメント どうすればいいかというと、設計が特別完璧ではないとしても、初稿として完全に使えるものです。私はUIのデザイン経験がないため、Figmaからデザインファイルをインポートする機能のテストを行っていません。\nコード構築中に、いくつかのドキュメントが見つかりました。SOLOモード下では、AIは存在している問題を自力で処理しようと試みます。例えば、データベースがローカルにある場合、データベースのフィールド設計を増やす必要があるため、最初に対応するスクリプトを生成し、次にjsスクリプトを実行してデータベーススクリプトを実行します。\nまた、資料を見ながら見つからなかったポイントもありました。タスク分解機能については、港美股の頃の資料にスクリーンショットがありませんので、以前の漫画リーダープロジェクトを使用しました。バイトもお金持ちなので、一度のリクエストでたくさんのタスクを実行できますが、このシナリオは実際にはあまり多くなく、新しいプロジェクトでは大量のトークンを消費します。ユーザーが依存性を持つときこそ、ここで利益を得られるのです。 ","date":"2025-08-14","language":"ja","permalink":"https://ttf248.life/ja/p/bytedance-ais-solo-encoding-new-paradigm/","tags":["ai","trae","バイト (baaito)"],"title":"ByteDance AI エンコードの新基準 SOLO","year":"2025"},{"categories":["金融知識データベース"],"content":"プロンプト：中国人として、英語の金融ニュースや米企業の行動に関する資料を見たとき、合併についてこのように書かれているのはなぜでしょうか。「NAOV reverse stock split: 1 for 10」は、英語特有の文法的な表現ですか？中国語の文法の習慣に合っていません。それに基づいて、スプリットを説明してください。\nこんにちは！これは非常に良い質問です。中国語を母国語とする投資家が初めて英語の金融ニュースに触れる際によく遭遇する混乱です。確かに、これは英語における金融分野特有の表現であり、中国語の語順とは大きく異なります。 詳細な説明をさせていただきます。\nなぜ「1 for 10」のように合口にする必要があるのか？ まず、この表現を分解してみましょう。A for B という構造です。\nこの構造の中で：\nA はあなたが手に入れるべき新しいもの（結果）を表します。 B はあなたが提供する古いもの（コスト/交換）を表します。 “for”という言葉はここでは「交換するために」という意味です。 したがって、“1 for 10 reverse stock split” の直接的な翻訳は \u0026ldquo;1株新規発行株式、旧株10株と交換する\u0026rdquo; です。\nつまり、あなたの 旧株10株が1株の新規発行株式に統合される ということです。これが日本語でいう「10合1」または「10株並べて1株」の意味です。\n構文習慣の比較 英語の習慣 (結果 for 原因/代償)： “得られた結果”を前に置き、 “支払われた代償” を後に置く傾向があります。例えば You get 1 new share for your 10 old shares. ニュースタイトルでは簡潔にするために 1 for 10 と略されることがあります。 中国語の習慣 (原因/代償 -\u0026gt; 結果)： 時間的順序や論理的な順序に従い、まず “元の状態” を述べ、その後 “結果” を述べる傾向があります。例えば “(元々の) 10株が(現在の) 1株に合体する” というように表現します。 したがって、これは一般的な英語の文法ではなく、ビジネスや金融分野で “交換比率” を表す際に非常に一般的で習慣的な慣例と略語であると言えます。 例を挙げて説明 (NAOV 1 for 10 Reverse Stock Split) 仮に NAOV社の株式を1,000株保有し、当時は株価が$0.5ドル/株だったとします。\n総資産価値: 1,000株 * $0.5/株 = $500ドル 合弁（1 for 10）後： あなたの持株数: 1,000株 / 10 = 100株 1株あたりの価格 (理論上): $0.5/株 * 10 = $5ドル/株 総資産価値: 100株 * $5/株 = $500ドル 結論: 合弁の主な目的は、単価を上げることであり、持株数を減らすことですが（市場変動を考慮しない場合）、あなたの総資産価値は一定に保たれます。会社は通常、取引所が定める最低株価要件（例えば、ナスダックが株価を$1以上に維持することを要求する場合）を満たすために合弁を行います。 株式分割 (Stock Split) の解説 合本株式の発行の仕組みを理解した上で、株式分割は容易に理解できます。株式分割とは、合本株式の発行の逆の操作です。 英語では通常、2 for 1 stock split または 3 for 1 stock split と表記されます。 私たちが学んだ A for B の構造を使って解釈します： 2 for 1 stock split は「あなたは手元の1株の旧株式と交換するために、2株の新株式を受け取ることになる」という意味です。 これはまさに中国語の「1拆2」または「1株を2株に分割する」の意味です。 例による説明 (ある会社の 2 for 1 Stock Split): 株式分割前に、あなたが特定の企業の株式を100株保有しており、その時の株価は1株あたり$200ドルだったとします。\n総資産価値: 100株 * $200/株 = $20,000ドル 株式分割（2 for 1）後： 保有株数: 100株 * 2 = 200株 1株あたりの価格 (理論上): $200/株 / 2 = $100ドル/株 総資産価値: 200株 * $100/株 = $20,000ドル 結論: 株式分割の目的は、単価を下げ、小額投資家にとってより魅力的になるようにすることです。これにより、株式の流動性が向上します。保有株数は増加しますが、同時に総資産価値も変わりません。 まとめ 会社行動 中国語訳 英文表記例 英文の意味 保有株式数への影響 每株股价への影響 合併 (逆分割) 10合1 1 for 10 10旧株と1新株に交換 減少 上昇 まとめ 会社アクション 中国語訳 英文表記例 英文の意味 保有株式数への影響 株価一人当たりの影響 株式分割 (Stock Split) 1株を2株に分割 2 for 1 1株の旧株式と2株の新規株式との交換 増加 低下 まとめ この説明が、英語の金融情報についてより深く理解するのに役立つことを願っています。これは確かに、考え方を変える必要があるものです。\n","date":"2025-08-13","language":"ja","permalink":"https://ttf248.life/ja/p/understanding-spin-offs-and-splits-in-the-us-stock-market-can-be-challenging/","tags":["ニューヨーク証券取引所（NYSE）/ 株式市場","株式分割・株式併合","AI霊感衝突坊"],"title":"米国株式市場におけるスプリットと合併の理解がスムーズではありません。 (Hoikibo shokusa no gasshu o rikai shimasu naku wa suimu bu nai.)","year":"2025"},{"categories":["金融知識データベース"],"content":"「同一契約コード、同じ方向の取引に対して、手数料は1回のみ徴収する」という手法は、証券業界においては通常**「合併手数料（Commission Aggregation / Combined Commission）」**と呼ばれています。これは香港証取引所や規制当局の硬直的な規定ではなく、市場競争と証券会社が顧客体験を最適化するために形成されたビジネス慣例です。\n港股券商、同一契約コード、同じ方向の取引に対して、佣金仅收取一笔，这是有什么历史业务背景吗\n核心歴史的転換点：2003年の最低手数料制度の廃止 これはこの問題を理解する上で最も重要な背景です。\n改革前（2003年4月1日以前）： 香港証券市場は最低手数料制度を採用していました。当時、ブローカーは顧客に対して取引金額の0.25%以下の手数料を徴収することが義務付けられていました。この時期、すべての証券会社の手数料率は基本的に同じ水準に固定され、競争は研究能力、顧客関係、サービス品質といった点に集中し、価格競争はほとんど存在しませんでした。そのため、当時の手数料の合算に関する顧客への取り組みがありませんでした。 改革後（2003年4月1日以降）： 香港取引所は正式に最低手数料制度を廃止し、証券会社と顧客が自由に手数料率を協議することを可能にしました。この改革は香港の証券業における競争を瞬く間に引き起こし、特に手数料価格競争を引き起こしました。 白熱した市場競争の産物 最低取引手数料を廃止した後、証券会社（特に新興のインターネット証券会社）は顧客獲得のために、様々な革新的な価格戦略を採用し、「手数料統合」はその中でも非常に魅力的な取り組みの一つとなった。\nアクティブトレーダーの誘致： 高頻度取引者や、同じ銘柄を分割して買い増し/売り切り（例えば、単筆の大口注文が市場価格に与える影響を回避するため）を行う投資家にとって、取引ごとに手数料が発生することは、取引コストを大幅に増加させる。この痛みを解決するために、「手数料統合」政策は完璧であり、投資家は1日で柔軟にポジションを構築または決済することができ、複数回の手数料請求を心配する必要がなくなる。 顧客の取引コスト削減： これが最も直接的な目的である。手数料統合により、顧客の実質的な取引手数料支出は大幅に低減され、証券会社のプラットフォームはコスト面でより競争力を高める。 顧客体験とロイヤルティの向上： 顧客にとって有利なこの政策は、ユーザーエクスペリエンスを大幅に向上させ、投資家が証券会社が自分たちのことを考えていると感じるようにすることで、顧客の粘着性とロイヤルティを高める。 業務ロジックと証券会社の利益 表面上は券商の収益が減少しているように見えますが、全体的な業務ロジックから見ると双方がWin-Winの関係です：\n薄利多売: 単発取引の効果コストを下げることが、顧客がより頻繁に取引するように刺激し、全体的な取引量を向上させます。券商は単筆のコミッションで「利益を譲る」ものの、総取引額の増加によって補填し、プラットフォーム利用料や融資・信用取引利息などの他の費用も収益として得ることができます。 市場シェア獲得: 競争激しい市場、特に新興のインターネット証券会社にとって、低手数料と優待政策はユーザーを獲得し、市場シェアを迅速に拡大するための最も効果的な手段です。 注意すべき重要な点 すべての証券会社が提供しているわけではない： 「合併佣金」は主流となっているものの、これは依然として証券会社のビジネス上の意思決定であり、強制規定ではありません。伝統的な証券会社や銀行の証券サービスによっては、取引ごとに料金が発生する可能性があり、投資家は券商を選択する際に、その料金明細を注意深く確認する必要があります。 「佣金（Brokerage Commission）」のみを対象とする： 必ず注意してください。「合併」計算されるのは、証券会社が徴収する「佣金（Brokerage Commission）」に限定されます。政府または取引所が徴収する「固定費用」は、取引ごとに計算され、合算することができません。主なものは以下の通りです。 印花税 (Stamp Duty): 0.1% (買い手と売り手の双方に発生し、端数切り上げで元単位) 交易征费 (SFC Transaction Levy): 0.0027% (証券取引委員会が徴収) 交易費 (HKEX Trading Fee): 0.00565% (香港株式交易所が徴収) 会财局交易征费 (FRC Transaction Levy): 0.00015% (香港財政司署が徴収) まとめると、港股券商の「合併佣金」政策は、2003年の最低佣金制度廃止という歴史的背景に基づいています。市場の自由化と白熱化競争の下で、証券会社が顧客コストを削減し、サービス体験を向上させ、顧客を獲得・維持するために導入した重要なビジネス戦略であり、香港金融市場が伝統から現代へ、高ハードルから普惠へと移行する縮図と言えます。\n","date":"2025-08-13","language":"ja","permalink":"https://ttf248.life/ja/p/hong-kong-stock-exchange-brokerage-fee-liberalization-and-market-competition/","tags":["AI霊感衝突坊","恒生指数 (こうせいしじょ)","手数料 (しゅりょう)","自由化 (Jiyuhka)","市場競争 (Shijō sozo)"],"title":"香港株の取引手数料ゼロ化と市場競争 (Hong Kong Stock Exchange Transaction Fee Zeroization and Market Competition)","year":"2025"},{"categories":["メモ書き雑感","投資 (tōshi)"],"content":"AI を過信しすぎると、何でも AI と考えすぎてしまうことがあります。新しい動向を学ぶ場合、検索エンジンとプロジェクトの公式ドキュメントの方が信頼性が高いです。\n香港株は下げ相場に遅れて参入し、回调に遭遇して日常的に無意味な操作を行い、利益はほぼ失われています。\n策略取引 単に稼ぐために実践する必要がある、というわけではなく、学習を通して自身の能力を高めたいと考えています。私はこれらのテクニカル指標を信用せず、むしろ国の運勢や大株主指数のインデックス投資を信じています。\n戦略取引 先月のインスピレーションの一つで、AIが没収されたプロジェクトの一例を参考に、AIを使って実現しようと試みたところ問題が発生。本来はまず資料を集め、既存のプロジェクトがないか、彼らはどのようにして進めていたのかを確認すべきだった。以前は戦略取引を経験したことがなく、指標や市場データの処理など、全く触れたことがなかった。\n当初の計画は、完全に自分なりに想像したもので、AIとのコミュニケーションを通じてバックテストフレームワークを知り、GitHubでプロジェクトが活発であることを確認した。\nAIを使いすぎると、何でもAIを使って解決しようとするくなり、AIにも学習資料やアクティブなプロジェクト、そして完成度の高い公式ドキュメントを提供してもらうのが理想的だ。しかし、AIが出してくる学習案は現在のコードバージョンに追いつかない。\nプロジェクトの構造を調整する：\nデータのダウンロード：ヤフー（Yahoo!）から、変動率のローソク足データを取得 バックテストの公式ガイドに従い、基本的な使い方を学ぶ TA-Lib のインストールと使用、一般的な指標の計算、そしてバックテストでデータを表示 アリペイ（Alipay）のような積立投資ロジックの実装。この戦略は長期的ETF積立投資に適している 香港株式取引 香港株式への参入は約2ヶ月、簡単な振り返りです。 美団の買い入れとその動機は、純資金流入を単純に見るとともに、美団近況を深く分析することなく、偶然にもデリバリー大战（デリバリー競争）に遭遇し、美団の株主となりました。小米も高位で買い入れたところ、機会を見つけて減塩（ポジションから利益確定して一部売却する）し、四期工場が落地（実際に稼働を開始した）したことで一波のチャンスがあったものの、それを継続するには忍耐が必要です。3年の時間ではほぼ終わります。 香港株式における新消費財、テクノロジー株の価格はすでに高水準であり、仮想通貨という概念も加わったため、テクノロジー株が下落した際に、長期的投資には不向きな頻繁な増配（ポジションに資金を追加する）を試みてしまい、今日なら一波賭けてみる、明日には下がって後悔してしまった。持続的に下落する市場に陥ると、簡単に巻き込まれてしまいます。 長期的投資としては、操作の頻度が過剰であり、週あたり2～3回程度が適切です。 上海総合指数は3600、国内の大盤に対して定投（積立投資）をほとんど行わず、この波を見逃してしまいました。\n","date":"2025-08-01","language":"ja","permalink":"https://ttf248.life/ja/p/daily-musings/","tags":["投資 (tōshi)","ai"],"title":"日常のつぶやき","year":"2025"},{"categories":["金融知識データベース"],"content":"真に伝統的な株式とデジタル通貨の取引・決済における巨大な違いを理解するためには、それぞれのエコシステムを構成する核心となる「部品」と「ルール」について深く理解する必要があります。これらは完全に異なるゲームとして捉えることができます：一方では厳格なルールと多角的な協調が特徴の「プロリーグ」、もう一方はコードが法律となり、誰でも参加できる「オープンワールド」です。\n→ 前述2つの問題に関して、補足・拡張できる基礎知識や資料整理について説明します。\n第1部：伝統株式市場の基盤——専門機関による信頼の連鎖 伝統金融市場の中核は、**「信頼」と「仲介」**です。全体システムは多層構造として設計されており、各段階で規制された専門機関が特定の役割を担い、市場の安定性と安全性を確保します。\n主要参与者 (The Players) あなた（投資家）: 取引の起点と終点。 証券会社 (Shoken Gaisha): あなたが市場に入る唯一の扉です。上場取引所やニューヨーク証券取引所、ナスダックで直接株式を購入することはできず、免許を持つ証券会社を通じて取引を行う必要があります。証券会社はあなたの取引指示を実行し、資金と有価証券（名義保持者として）を保管します。 証券取引所 (Shoken Torihajo): 市場の**「取引大広間」**です。例えばニューヨーク証券取引所(NYSE)、ナスダック(NASDAQ)などがあります。主な機能は、買い手と売り手の申報がここで出会い（撮合）、価格が発見される公平かつ公開された場所を提供することです。取引所は取引の撮合のみを行い、資金や株式の移転後の処理は行いません。 中央決済機関 (Chuuya Tatei Kaigan): 市場の**「リスク保証人」**です。これはリスク管理の中核となります。取引が成立した後、中央決済機関が買い手と売り手の間で介入し、「すべての買い手の売り手」と「すべての売手の買い手」になります。これにより、一方のデフォルトリスクは中央決済機関によって負担され、市場内でドミノ骨牌のようにリスクが蔓延するのを防ぎます。 中央証券保管所 (Chuuya Shoken Hokansho): 市場の**「最終倉庫」と「総登記所」**です。例えばアメリカのDTCCや中国の中証登などがあります。これは非常に重要な機関で、電子化された方法で市場の大半の有価証券を集中登録・保管します。 核心概念：証券の「無紙化」と「非移動化」 無紙化 (Dematerialization): 今日お買い上げの株式は、もはや一枚一枚の紙質凭证ではありません。それはCSDデータベース内の文字列です。 非移動化 (Immobilization): これは清算の理解における鍵となります。清算が起こる際、実際に「電子株式ファイル」が券商のサーバーから別の券商のサーバーに送信されるわけではありません。実際には、すべての株式はCSDという中央金庫に「固定」されています。清算のプロセスは、CSDがその総勘定帳簿上で、売主券商の総口座（Omnibus Account）から買い手券商の総口座名下へ株式を移転することです。その後、あなたの券商が自社の内部顧客帳簿を更新し、あなた名下にこれらの株式が増加したことを記録します。 この多層的かつ分業明確な構造は、時間的な遅延（T+N）をもたらすものの、強力で成熟したリスク隔離と管理メカニズムを構築し、現代金融市場が安定して運営される基盤となっています。 第2部：暗号資産市場の基礎——コードと暗号学による「信頼軽減」システム 暗号資産は、従来の仲介機関への依存を減らし、あるいは排除することを目的としており、その基盤となるのは**「暗号学的証明」ではなく「機関信用」**です。\n核心技術 (The Technology) ブロックチェーン / 分散型台帳 (Blockchain / DLT): それを世界各地に分散され、無数の人が共同で維持され、内容が改竄できない公共の帳簿と想像してください。すべての取引は公開記録され、誰でも検証できますが、誰もがそれを制御できるわけではありません。 公開鍵と秘密鍵 (Public \u0026amp; Private Keys): これはデジタル通貨の世界におけるあなたの資産所有権の唯一の証明です。 公開鍵 (Public Key): それはあなたの銀行口座に相当します。安全に誰かに共有して、数字通貨を受信するために使用できます。ウォレットアドレスは公開鍵によって生成されます。 秘密鍵 (Private Key): それはあなたの銀行パスワード+U盾+署名の組み合わせであり、資産を動かす唯一の鍵です。秘密鍵を保持している人だけが対応するアドレス上の資産に対する絶対的な制御権を持ちます。これは暗号化世界の黄金律「Not your keys, not your coins」（あなたの私鍵ではないなら、あなたのコインでもない）の由来です。 暗号ウォレット (Crypto Wallet): それ自体は**「通貨」を保管していません**（通貨は常にブロックチェーン上に存在します）。ウォレットの本質は、あなたが入っている秘密鍵を管理するためのツールであり、秘密鍵を使用して取引に署名し、ブロックチェーンネットワークと相互作用するのに役立ちます。 スマートコントラクト (Smart Contract): それはブロックチェーン上で自動的に実行されるプログラムコードです。そのロジックは「もし…ならば…」（IF-THEN）です。例えば、分散型取引所のスマートコントラクトは次のように規定できます。「もし私がAユーザーから1つのETHを受け取ったら、私は自動的にAユーザーのアドレスに2000個のUSDCを送信します」。このプロセスはコードによって自動的に強制実行され、人工干渉も信頼も必要ありません。 核心ルール：コンセンサスメカニズム (Consensus Mechanism) 中央サーバーがないネットワークにおいて、数万ものノードがどの取引が合法かを一致するためにどのように合意するのか？ それこそがコンセンサスメカニズムの役割です。最も一般的なものは次のとおりです。\nプルーフ・オブ・ワーク (Proof of Work - PoW): ビットコインを代表するもの。 “マイナー” が大量のハッシュ計算（非常に難しい数学の問題を解くようなもの）を通じて帳簿権を競い合うことで機能します。最初に問題を解いたマイナーは、最新の取引をブロックにまとめてネットワーク全体にブロードキャストし、他のノードが検証後に受け入れます。この方法は非常にエネルギー消費が激しいですが、極めて高いセキュリティを提供します。 プルーフ・オブ・ステーク (Proof of Stake - PoS): イーサロンアップグレード後に採用されました。計算能力の競争に依存せず、代币を保有し“ステーキング”している “バリデーター” がブロックを作成および検証するために回転します。より多くのステーキングされたトークンを持つほど、ブロック作成と検証の選択確率が高くなります。不正行為を行った場合、そのステーキングされたトークンは没収されます。 まとめと比較 より明確に理解するためには、表を使って両者の根本的な違いをまとめることができます。\n| 資産の形態 | CSDにおける電子帳簿（デマテリアライズド） | ブロックチェーン上の原生デジタルトークン（ネイティブデジタルトークン） |\nまとめと比較 特徴 伝統株式市場 デジタル通貨市場 所有権証明 証券会社の帳簿記録（受益所有権） 私鍵の制御（直接所有権） まとめと比較 特徴 伝統株式市場 デジタル通貨市場 信頼モデル 規制された法制度および金融機関への信頼 オープンソースコードと暗号学的証明による「信頼の排除」 まとめと比較 特徴 伝統株式市場 デジタル通貨市場 コアとなる帳簿 CSDによって維持される中央集権型帳簿 全ネットワークノードによって共同で維持される分散型帳簿 まとめと比較 特徴 伝統株式市場 デジタル通貨市場 取引相手方 CCP（中央清算所） 取引の相手方またはスマートコントラクト まとめと比較 特徴 伝統株式市場 デジタル通貨市場 コアな推進力 機関信用 (機関クレジット) アルゴリズムと暗号化技術 (アルゴリズムと暗号化技術) まとめと比較 上記補足をご参照いただくと、従来の金融が複雑な「信頼チェーン」を構築することでリスク管理や決済を実現しているのに対し、暗号資産は技術手段（暗号学と分散型ネットワーク）を用いて仲介者を必要としない「自己認証による清算」の体系を構築しようとしていることがわかります。この2つの根本的に異なる基盤ロジックが、取引、決済、清算といったあらゆる側面で天と地ほどの差を生み出しているのです。\n","date":"2025-07-28","language":"ja","permalink":"https://ttf248.life/ja/p/significant-differences-in-trading-and-settlement-between-stocks-and-digital-currencies/","tags":["AI霊感衝突坊","株式","暗号通貨 (أنگyū tsūkō)","取引 (とりひき)","清算 (Seisan)"],"title":"株式と暗号資産の取引および決済における大きな違い","year":"2025"},{"categories":["金融知識データベース"],"content":"本日、世界がデジタル浪潮に巻き込まれている今、私たちは即時送金や秒速決済に慣れ親しんでいます。そのため、多くの人々は混乱を覚えます。「私は「売却」をクリックしたのに、資金がすぐに全額着金せず、引き出せないのはなぜか？ 1～2営業日も待つ必要があるの？」これは、まさに伝統的な株式取引における極めて重要かつ歴史悠久な概念——決済（Settlement）—を象徴しています。\n簡単に言うと、「取引（Trade）」と「決済（Settlement）」は2つの独立したステップです。\n取引： つまり、あなたが取引所にて買い付け・売り付けの指示を出し、それが成立した瞬間です。この時点で、あなたは相手方と法的拘束力のある契約を締結し、将来の特定時点において株式と資金を交換することを約束します。 決済： これは、契約で合意された内容が実行されるプロセスであり、株式の所有権が売り手から買い手に正式に、かつ取り消し不可逆的に移転され、同時に資金も買い手の口座から売り手に正式に、かつ取り消し不可逆的に振り込まれることになります。 これらの2つのステップを分離し、時間差（例：T+1制度、T+2制度）を設定する必要があるのは、歴史的な発展と金融リスクに対する厳格な管理の根源にあるのです。\n根源的历史：紙に由来する時代 コンピュータシステムが普及する以前、株式は実質的に紙の証憑証書でした。取引が取引所内で口頭またはジェスチャーによって合意された後、その後の作業は非常に煩雑でした。\n物理輸送: 売り手側の証券会社は金庫から対応する証憑証書を見つけ出す必要がありました。 背書転讓: 証書の裏面で署名と背書を行い、所有権の譲渡を証明しました。 人工伝達: これらの証憑証書と対応する小切手は、専門家（信使）が都市中を移動し、買い手側の証券会社に届けられました。 検証照合: 買い手側の証券会社は、証書の真正性と取引詳細の正確性を検証する必要がありました。 このプロセスには大量の手作業と物理的な移動が含まれており、遅延と不確実性に満ちていました。そのため、これらの複雑なプロセスを完了するために必要なのは、数日間（当初はT+5まで）の決済サイクルでした。1960年代末、ウォール街は取引量の急増により「書類業務危機」（Paperwork Crisis）に陥り、大量の取引がタイムリーに決済できず、交易所は取引時間を短縮せざるを得ない状況に追い込まれました。これは、現代の電子化清算システムの構築を直接引き起こしました。\n現代コア：代替不可能なリスク管理 今日すべての取引が電子化されているにもかかわらず、T+Nの決済システムは依然として維持されており、そのコア機能は「物流待ち」から金融システムの巨大なリスクを管理するものへと進化してきた。このプロセスは、主要な役割を担う**中央清算所（Central Counterparty, CCP）**によって行われ、アメリカのデポジットトレーディング・クリアランス機構（DTCC）や中国證券登記結算有限公司（中證登）などが挙げられる。 決済システムは主に以下のコアリスクを回避するために設計されている：\n相対者リスク（Counterparty Risk） これは最も根本的なリスクです。株式を売却した場合、購入者が確実に期日内に支払いをしてもらえると断言できるでしょうか？逆の立場では、買い手も売り手が本物の株式を確実に引き渡してくれると保証できますか？どちらか一方に契約不履行が発生すれば、連鎖反応を引き起こす可能性があります。 解決策： 中央相対者（CCP）の介入。 取引が成立した後、CCPは買い手と売り手の間に「介入」し、それは売り手にとっての「買い手」、買い手にとっては「売り手」となります。 このことを「契約更置」（Novation）と呼ばれる法的措置を通じて行うことで、元の売買当事者は互いに責任を負わなくなり、それぞれCCPに責任を負うことになります。\n売り手にとって： 株式をCCPに引き渡せば、必ずCCPからお金を受け取れます。 買い手にとって： お金をCCPに支払えば、必ずCCPから株式を受け取れます。 このようにして、個々の参加者の契約不履行リスクは、信用格が非常に高い中央機関であるCCPによって吸収され、市場全体に波及するのを防ぎます。 決済とネット清算 (Seitousu to Netto Seiutsu) 大規模な証券会社は、1日に数百万件の取引を処理します。買い注文と売り注文の両方があります。もしすべての取引を個別に資金と有価証券を移転させるなら、システムは耐えられません。 解決策： 決済日（T日）の前に「決済」を行います。 取引日（T日）の終了後、決済機関は各証券会社の買い注文と売り注文をすべて集計し、これを**「ネット清算」または「轧差」** と呼びます。例えば、ある証券会社が1日に顧客のために株式を合計で10億元購入し、9.8億元の株式を売却した場合、決済日には2000万の資金差額のみを決済機関に支払うだけで済み、19.8億の資金交換を行う必要はありません。同様に、株式の決済もネット清算で行われます。これにより、市場全体の運用効率が大幅に向上し、流動性需要が低下します。\n株式取引の完全な生命周期 ここでは、取引から決済までのプロセスを簡単な例を通して見ていきましょう（T+2ルールに基づきます）。\nT日（取引日）： 午前10時に「買い」注文を行い、100株の特定の企業の株式を即座に約定させます。この時点で、あなたは売り手と契約を結びますが、株式と資金の所有権はまだ移転していません。\nT日後場～T+1日（決済期間）：\n交易所はあなたの取引データを中央清算機関（CCP）に送信します。 CCPは取引情報を確認し、無効な場合は取引をキャンセルします。その後、「契約更替」を行い、あなたの取引相手となります。 CCPは券商いがT日に行う全ての取引の純額を計算し、T+2日に支払うべき資金と証券を券商に通知します。 T+2日（決済日）：\n午前中に、券商はCCPの指示に基づき、純額を支払うための資金をCCPに送金します。 CCPが資金を受け取ると、証券保管機構に指令し、売り手の券商のアカウントから100株の株式をあなたの券商のアカウントに引き出します。 券商は内部であなたの口座情報を更新し、あなたはこの100株の株式を保有していることを表示します。 これで決済が完了し、あなたは法律上、この100株の株式の正式な所有者となり、配当を受け取る権利や投票に参加する権利などを持つことになります。\n要するに、伝統的な株式取引で「決済」という概念が必要とされるのは、紙媒体での取引の際の煩雑さを解決するための歴史的経緯と、現代のリスク管理理論が組み合わさった結果です。中央相手方と純額決済を通じて、金融市場全体の安定性と効率性を保障する核心制度として発展してきました。この「遅延」に見える設計は、まさに投資家が取引相手の違約リスクから保護するための重要な防火壁なのです。\n","date":"2025-07-28","language":"ja","permalink":"https://ttf248.life/ja/p/why-the-concept-of-settlement-is-necessary-in-traditional-stock-trading/","tags":["AI霊感衝突坊","株式取引","コネクトポイント (Konekuto Point)","清算 (Seisan)"],"title":"従来の株式取引で「決済」（クリアランス）という概念が必要となる理由は何ですか？","year":"2025"},{"categories":["金融知識データベース"],"content":"従来の株式市場とは異なり、明確な始末時間があるのに対し、暗号資産市場は24時間365日取引が可能なという特性から、世界中の投資家の注目を集めている。この特性は、取引時間がない暗号資産の世界において、決済と清算（交割）はどのように行われるのかという核心的な問題を提起する。従来の金融における「休場」の概念が存在しない場合、決済・清算はどのように機能するのだろうか？　全く異なる仕組みになっているのだろうか？　答えは、暗号資産には決済と清算があるだけでなく、その実現方法とシステム設計こそが、全天候取引を支える重要な要素であるということだ。\n核心の違い：T+2からリアルタイム決済へ 伝統的な株式取引は、「T+N」の決済制度に従います（例えば、A株のT+1、米国株式のT+2）。これは、取引が成立した日（T日）の後、資金と証券の実質的な移動（決済）が、1つまたは複数の営業日後に完了することを意味します。この期間中、 clearing機関は、差引調整を行い、各当事者の受取金と支払金、および証券の状況を計算します。 デジタル通貨は、このパターンを完全に変えました。その清算と決済の中核は、**「取引即清算、清算即交収」**というものであり、これはその基盤にあるブロックチェーン技術によるものです。\nブロックチェーン：天然のリアルタイム全額決済システム ブロックチェーン自体は、分散型かつ改竄不可能な公共な帳簿と見なすことができます。取引は「ブロック」に記録され、暗号学的な方法で前のブロックにリンクすることで、「チェーン」を形成します。このプロセスには、以下の重要な特性があります：\nリアルタイム性（Real-Time）： 取引がネットワーク上のノードによって検証され、ブロックにパケット化されると、資産の移動が完了します。異なるブロックチェーンネットワーク（ビットコイン、イーサリアムなど）の混雑状況やブロック生成速度により、確認時間は数秒から数十分程度ですが、従来の金融の「T+N」と比較すると質的な飛躍です。 全額交収（Gross Settlement）： 従来の決済システムにおけるネット決済（Netting）とは異なり、ブロックチェーン上の取引は独立しており、全額で完了します。AがBにビットコインを送金するということは、帳簿上、Aのアドレスから1つ減少し、Bのアドレスが増加するだけであり、多方取引を轧差（わせ）して初めて振り込まれるという状況はありません。 最終性（Finality）： あるブロックが十分な数の後続ブロックによって確認されると、その取引は「最終的」かつ不可逆的なものとなります。つまり、交収が完了すると、誰もそれを取り消したり、改竄したりすることはできません。 したがって、根本的に言えば、デジタル通貨の交収はブロックチェーン上で発生し、ネットワーク共済によって自動的に完了します。 従来の意義における中央清算相手方（CCP）や托管機関の介入は必要ありません。\n中心化取引所と分散型取引所：異なる決済清算経路 基盤技術は分散型であるにもかかわらず、ユーザーが暗号資産を取引する主要な場所である取引所は、中心化（Centralized Exchange, CEX）取引所と分散型（Decentralized Exchange, DEX）取引所の2種類に分かれており、それぞれの決済清算メカニズムには違いがあります。\n中心化取引所（CEX）：内部清算＋チェーン上交割 ユーザーがバイナンス（Binance）、コインベースなどの中心化取引所で取引を行う場合、実際には交易所内の中心化された帳簿上で行われていること、ブロックチェーン上で行われることではない。\n内部清算（記帳）: ユーザーが取引所へデジタル通貨または法貨を充填した後、取引所はユーザーのアカウントに相応の残高をデータベースに記録する。プラットフォーム上のすべての買い取り行為、例えばUSDTでBTCを購入する場合など、本質的には取引所のデータベース内の異なるアカウント間の数字の増減である。このプロセスは、取引所の「マッチングエンジン」によって高速に完了し、内部的にリアルタイムで行われる清算と見なされる。\nチェーン上交割（提現/充填）: 実際にブロックチェーン上で発生する交割は、ユーザーが「充填」（外部ウォレットから取引所に転入）および「提現」（取引所から外部ウォレットへ転出）を行う場合にのみ発生する。このとき、取引所はチェーン上のトランザクションを開始し、資産の所有権を実際にブロックチェーン上に移動させる。\nシステム設計における重要なポイント:\n高性能マッチングエンジン: 高い同時接続数下で迅速に買い取り注文をマッチングできるようにする。 冷熱ウォレット分離: ほとんどのユーザーのアセットはオフライン状態の「冷ウォレット」に保管してセキュリティを確保し、少量の資産をオンライン状態の「熱ウォレット」に保管してユーザーの日常的な提現ニーズに対応する。これは7x24時間のアセットの安全な運用を維持するためのコア設計である。 内部帳簿データベース: 高性能分散型データベースを採用し、内部取引記録の正確性と即時性を保証する。 去中心化交易所（DEX）: 链上原子交換 Uniswap、SushiSwapなどの分散型取引所では、取引プロセスは根本的に異なります。ユーザーは常に自分のウォレットの秘密鍵をコントロールし、取引は「スマートコントラクト」を通じてチェーン上で直接行われます。\n原子交換 (Atomic Swap): これはDEXの清算交収の中核です。スマートコントラクトとは、ブロックチェーン上で自動的に実行されるプログラムであり、資産の交換を「原子性」で確実に行うことを保証します——つまり、両当事者が成功裏に交換するか、あるいはどちらも失敗するかという状況のみであり、一方が出資した資産がもう一方によって受け取られなくなることはありません。\n清算と交収の同時完了: ユーザーはウォレットを通じてスマートコントラクトとのインタラクションを承認し、取引がトリガーされ、ブロックチェーン上で確認されると、資産の清算と交収は瞬時に完了します。このプロセスには、いかなる中心化機関の信頼背書も必要ありません。\nシステム設計における重要なポイント:\nスマートコントラクト: 取引所の中核ロジックであり、取引ペア、流動性プール、価格アルゴリズム（自動マーケットメイカーAMMなど）といったものがコードで固定されており、公開され透明です。 チェーン上プロキシ (Oracles): 外部市場の価格情報を安全にブロックチェーン上に入力するために使用されます。これにより、特定の種類のDEXは価格参照を提供できます。 フロントエンド (Frontend): ウェブページまたはアプリケーションを通じて、ユーザーが自分のウォレットを接続し、バックエンドのスマートコントラクトとインタラクションできるようにします。 結論：暗号資産決済清算の新パラダイム 要言えば、暗号資産は清算と決済の概念を全く持っていないわけではなく、ブロックチェーン技術と革新的なシステム設計により、多岐にわたる参加者、時間のかかるバックエンドプロセスから、効率的で透明性があり、場合によってはリアルタイムな自動化プロセスへと転換したのです。\n清算の概念は依然として存在: CEXにおいては内部帳簿のリアルタイムマッチングと記帳、DEXにおいてはスマートコントラクトの取引ロジックにも清算ルールが含まれています。 決済こそが核心的な変革: ブロックチェーンコンセンサスによって決済の最終性が保証され、ほぼリアルタイムな資産移動を実現し、これが7x24時間不中断取引を支える基盤となっています。 システム設計は不中断性を目的とする: CEXのホットウォレットとコールドウォレットアーキテクチャ、DEXの自動化スマートコントラクトなど、安全性を確保しながら、人工干渉なしに休むことなく取引できる環境を実現することが、システムの第一要件です。 この画期的な清算決済メカニズムは、暗号資産市場が従来の金融市場と異なる顕著な特徴であるだけでなく、将来の金融インフラストラクチャの進化方向を示す重要な示唆を与えています。\n","date":"2025-07-28","language":"ja","permalink":"https://ttf248.life/ja/p/over-the-counter-otc-clearing-and-settlement-of-digital-currencies-unveiling-the-mechanisms-behind-7x24-continuous-trading/","tags":["暗号通貨 (أنگyū tsūkō)","清算 (Seisan)","コネクトポイント (Konekuto Point)","24時間7日間の取引"],"title":"デジタル通貨の決済と清算：7x24時間ノンストップ取引の裏側の仕組みを解明","year":"2025"},{"categories":["コンピューター"],"content":"ホストが原因不明にブルースクリーンになり起動できず、UEFI形式のブート、システムが正常にロードできなくなっていました。MBR形式の古いブート方式に変更したところ、システムは正常に起動しました。\n通常の操作として、システムの遠隔デスクトップを有効にし、別のマシンでテストを行いました。ネットワーク関連はすべて正常でした。Microsoftアカウントを使用してログインし、以前と全く同じ状態でした。\n遠隔デスクトップにログインしようとした際、**「ログイン失敗」**というエラーが表示され、その他の情報は一切表示されませんでした。\n解決策 これは Microsoft アカウントでログインしているシステムのため、リモートデスクトップ接続の際にデフォルトで使用されるのは Microsoft アカウントのメールアドレスであるため、システム上は Microsoft アカウントのメールアドレスをユーザー名として推奨されています。PIN コード認証を有効にするよう推奨されています。\nインターネット上の情報を参考に、まず第一段階としてセキュリティ設定をオフにします。具体的には、「セキュリティを強化するため、このデバイス上の Microsoft アカウントでの Windows Hello ログインのみを許可します（推奨）」というオプションを無効化します。 重要な第二段階として、システムを再起動します。これにより、PIN コード認証以外にも「Microsoft アカウント」のオプションが表示されます。アカウントでログインし、手動でユーザー名とパスワードを入力します。その後、再度リモートデスクトップ接続を試みると、問題なく動作するようになります。\n参考資料 https://learn.microsoft.com/zh-cn/answers/questions/2191955/question-2191955\n","date":"2025-07-22","language":"ja","permalink":"https://ttf248.life/ja/p/win11-pro-professional-remote-desktop-login-error-login-failed/","tags":["windows","win11","リモートデスクトップ","rdp","ログイン失敗 (login himitsu)"],"title":"Win11 プロフェッショナル版、リモートデスクトップ ログイン エラー：ログイン失敗","year":"2025"},{"categories":["金融知識データベース","AI霊感衝突坊"],"content":"技術革新の波を背景に、RWA（実物資産）とWeb3は、金融業界で今最も熱いキーワードとなっています。かつて保守的かつ安定した巨頭として見られていた伝統的な金融機関が、今ではこれらの新たな概念を積極的に受け入れ、RWAおよびDeFi（分散型金融）の発展を大きく推進しています。しかし、この技術主導による変革の裏側には、重要な問いがあります：これほど目を奪われるような新しい概念は、真に破壊的なイノベーションなのか、それとも伝統的な金融ビジネスを「再構築」しただけなのでしょうか？\nRWA と Web3：コア概念の解読 RWA（Real World Assets）とは、現実世界の有形または無形の資産を、「トークン化」（Tokenization）技術によって、ブロックチェーン上で発行・流通するデジタル資産です。 これらの資産は、不動産、債券、プライベートローン、美術品、カーボンクレジットなど、多岐にわたります。その核心価値は以下のとおりです。\n流動性の向上： 従来、流動性が低い資産（例えば不動産）をより小さな単位に分割し、投資のハードルを下げることで、株式のように二次市場で容易に取引できるようにします。 透明性と効率性の向上： ブロックチェーンの改ざん不可能性とトレーサビリティを活用して、資産の発行、取引、清算の手続きを簡素化し、中間業者や人的ミスを削減することで、コストを低減し、効率を高めます。 資金調達チャネルの拡大： 資産所有者に対し、グローバルかつより効率的な資金調達プラットフォームを提供し、地域的および伝統的な金融仲介の制限を打破します。 Web3（Web 3.0）とは、一般的に「次世代インターネット」と呼ばれるものであり、分散型、ユーザーが所有・制御するインターネットエコシステムを構築するという核心理念を持っています。 現在、少数数の巨大テクノロジー企業によって支配されているWeb2時代とは異なり、Web3はブロックチェーン技術に基づいており、データ所有権とコントロールをユーザーに返還することを目的としています。その主要な特徴には以下のようなものがあります。\n分散化： 情報やアプリケーションは、単一企業のサーバーではなく、ネットワーク内の多数のノードに分散され、単一障害点のリスクや検閲のリスクを軽減します。 ユーザー主権： ユーザーは、個人データに対するより高いコントロール権限を持ち、誰と共有するか、どのように使用するかを選択できます。 許可不要および検閲耐性： 誰でもネットワークに参加し、アプリケーションやサービスをリリースしたり、利用したりすることができ、中央集権的な機関の承認を得る必要はありません。 伝統金融機関が RWA と DeFi を積極的に推進する理由 伝統金融機関が RWA（Real World Assets：実物資産）と DeFi（Decentralized Finance：分散型金融）を積極的に推進している主な理由は、以下の戦略的考慮事項によるものです。\n効率化とコスト削減: 従来の金融システムには、大量の人手による審査、複雑な決済清算プロセス、煩雑なコンプライアンス手続きなどがあり、その結果として効率が低下し、コストが高額になるという問題がありました。スマートコントラクトやブロックチェーン技術を活用することで、DeFi と RWA は多くのプロセスを自動化し、運用コストを大幅に削減できます。 新たな収益源と市場の開拓: RWA の登場により、金融機関は新たな資産クラスとビジネスモデルを開拓することができます。例えば、不動産やプライベート・クレジットプロジェクトなどのトークン化サービスを提供したり、有価証券を発行・取引したりすることで、手数料収入やコンサルティング収入を生み出すことができます。 競争への対応と優位性の確立: 金融技術企業や暗号資産ネイティブ企業からの競争が激化しています。RWA と DeFi に積極的に投資することで、伝統金融機関は革新的な姿勢を示すことができ、次世代の顧客を獲得し、将来の金融格局において有利な立場を確保することができます。 透明性とリスク管理の向上: ブロックチェーンの透明性は、資産の裏付けとなる情報の透明性を高め、投資家がリスクをより適切に評価するのに役立ちます。また、標準化されたトークン契約と自動化されたコンプライアンスチェックは、リスク管理の効率を高めることに貢献します。 ビジネスの本質：新しいボトルに古いワイン？ RWA（トークン化された実物資産）とDeFi（分散型金融）が技術やパターンにおいて革新をもたらしてきましたが、核心のビジネスロジックにおいては、従来の金融機関が現在行っているRWA関連業務は、依然としてその伝統的なビジネスの延伸とデジタル化の進化です。\n例えば、RWAを例にとると、その核心は伝統的な資産をトークン化することです。このプロセスは、従来の資産証券化（ABS）と異曲同工であり、流動性の低いものの予測可能なキャッシュフローを持つ資産をパッケージングし、分層することで、金融市場で取引可能な証券へと変換します。RWAは、その証券化の媒体を従来の電子憑証からブロックチェーン上のトークンに転換するだけです。その本質は依然として信用中介と資産管理であり、質の高い資産を選別し、構造化設計を行い、投資家に販売することです。例えば、商業不動産の将来の賃貸収入権をトークン化して、不動産投資信託（REITs）の発行と同様に金融の本質的には違いありません。\n同様に、DeFi分野では、その“分散型”という理念が従来の金融仲介を覆そうとする一方で、現在の伝統機関の参加方法は、その技術的優位性を活用して既存のビジネスを最適化することに重点が置かれています。例えば、スマートコントラクトを使用して融資承認と放流プロセスを簡素化したり、分散型取引所を通じてより効率的なクロスボーダー決済と清算を行ったりします。その核心となる貸付、取引、決済などの業務は、依然として金融体系の基盤です。\n言い換えれば、伝統金融機関がRWAやDeFiを推進することは、まさに自己革命であり、コアな金融機能を変化させないまま、技術を活用して効率を高め、コストを削減し、市場を拡大しようとするものです。彼らは自分自身を根本的に覆そうとしているのではなく、技術革新を通じて自社の業界地位を強化・拡大することを望んでいます。\n結論として、RWAとWeb3は間違いなく金融業界に深刻な変革をもたらしています。これらの技術は、従来の金融における多くの課題を解決します。しかし、現状の伝統金融機関にとって、これらの技術を採用することは、慎重かつ現実的な戦略選択と言えます。そのビジネスの本質は根本的に変化しておらず、依然として資産、信用、取引といった古くからの金融の命題を中心に展開されます。将来的には、技術の成熟と規制の整備により、より破壊的な金融イノベーションが現れるかもしれませんが、現状では“新瓶に古いワイン”という表現が最も適切であると言えるでしょう。\n","date":"2025-07-21","language":"ja","permalink":"https://ttf248.life/ja/p/rwa-real-world-assets-and-web3-a-new-bottle-of-old-wine/","tags":["rwa","web3","フィンテック (FinTech)","ブロックチェーン","投資 (tōshi)"],"title":"RWA（与）Web3：金融の新しいボトルに古いワインを詰めるのか？","year":"2025"},{"categories":["金融知識データベース"],"content":"数字通貨の「マイニング」と「会計」の関係を、わかりやすいたとえ話を用いて説明します。また、ビットコインとイーサーステレウムが数量の上限で異なる理由についても解説します。\nはい、わかりやすい例え話を使い、数字通貨の「マイニング」と「会計」の関係を説明し、ビットコインとイーサーステレウムが数量の上限で異なる理由も解説します。\n採掘と帳簿付け：全民参加型の会計大会 ビットコインネットワーク全体を、全世界のあらゆる場所で発生するすべてのビットコイン取引（例えば、張三が李四にビットコインを送金する）を記録するために、誰かが公開透明な電子帳簿に記録する必要がある巨大なものだと想像してみてください。そうすれば、取引が成功したとみなされます。\nしかし、誰が帳簿付けをするのでしょうか？誰でも自由に書くことができれば、それは混乱になるだけです。\nこの問題を解決するために、ビットコインシステムは継続的に「採掘・帳簿付け大会」を実施しています。\n帳簿付け（Bookkeeping）: 過去約10分間に発生したすべての取引を「ブロック」（帳簿の一ページと理解できます）にまとめて、このブロックには取引記録だけでなく、前の「ブロック」（前一頁の帳簿）へのリンクが含まれています。このように一頁ずつリンクしてチェーン状になることで、改ざんが不可能なチェーン、「ブロックチェーン」が形成されます。 採掘（Mining）: 実際の核心問題は、誰がこのページを記録する資格があるのかということです。答えは：最も最初に非常に複雑な数学の問題を解いた人（またはマイニングプール）だけが、この回の帳簿付け権を獲得します。この問題を解くプロセスは、形象的に「採掘」と呼ばれます。 なぜ「採掘」と呼ばれるのですか？ このプロセスには、大量の計算リソース（マイニングマシン）と電力（エネルギー）が必要です。現実世界で金鉱を掘るのに設備や労働力を投入するのと同様です。 問題解決の目的は何ですか？ この数学の問題自体に実用的な意味はありません。唯一の目的は、帳簿付けの難易度を高め、平均して10分あたりに1人（またはマイニングプール）が解けるようにすることです。これにより、帳簿更新の速度が安定し、システムのセキュリティも確保されます。誰かが帳簿を改ざんしようとすれば、ネットワーク全体の半分よりも多くの計算リソースを持っている必要があります。これは経済的にほぼ不可能です。 したがって、採掘と帳簿付けの関係は次のとおりに要約できます。\n「採掘」は「帳簿付け権」を争うプロセスであり、「帳簿付け」は成功した「採掘」の報酬と責任です。\n採掘と会計：全民参加型の会計大会 成功にマイニングを達成した「鉱工」は、以下の2つの作業を行います。\n最新の取引を新しいブロックにまとめて、ブロックチェーンに接続する（会計処理の完了）。 システムから与えられる報酬を得る。 この報酬には、以下の2つの要素が含まれます。 ブロック報酬 (Block Reward)：システムが新規ビットコインを自動生成して報酬として与えるものです。これは新しいビットコインが創造される唯一の方法です。 取引手数料 (Transaction Fees)：当該ブロックに含まれるすべての取引の支払い者が支払う手数料です。 ビットコインには上限がある一方で、イーサーストリーム（Ethereum）にはない理由とは？ これは、2つの暗号通貨における設計哲学と目標の根本的な違いに起因するものです。\nビットコイン（Bitcoin）：デジタルゴールド、発行枚数固定 ビットコインは当初から、金のような価値の保存手段として設計されてきた。金の価値が重要な理由の一つは、その希少性—地球上の埋蔵量は限られていること—である。 この希少性を模倣するため、ビットコインの創設者中本聪は設計時に以下の二つの鉄則を定めた：\n発行枚数上限: ビットコインの発行枚数は永久に 2100万枚 に制限される。多すぎても少なすぎてもない、ちょうど良い数である。 マイニング報酬の半減: 約4年（または21,000個のブロックが生成されるたびに）、鉱業者がブロックをマイニングして成功した場合に得られる報酬は半分減少する。 2009年の開始時は50 BTC 2012年に半減して25 BTC 2016年に半減して12.5 BTC 2020年に半減して6.25 BTC 2024年に半減して3.125 BTC …以降、約2140年頃まで、新しいコインの報酬はほぼゼロに近づく。 この設計により、ビットコインは**インフレーション（通貨緊縮）**の特性を持つ。時間の経過とともに、新しいコインの生産量はますます少なくなっていく。もし需要が一定または増加し続ければ、理論上その価値は上昇するだろう。これにより、「デジタルゴールド」としての地位が強化される。すべてのビットコインがマイニングされてしまうと、鉱業家の収入は取引手数料のみに依存することになる。\nイーサリアム：分散型アプリケーションプラットフォーム、より柔軟な供給戦略 イーサリアムの目標はビットコインとは異なります。それは単なるデジタル通貨ではなく、「世界コンピュータ」であり、スマートコントラクトと分散型アプリケーション（DApps）を実行するためのプラットフォームを目的としています。 イーサリアムを分散型の「アプリケーションストア」および「オペレーティングシステム」だと想像してください。このシステムでは、プログラムの実行や取引を行うために「燃料費」（Gas Fee）を支払う必要があり、その燃料はイーサリアム（ETH）です。 この巨大で複雑なシステムを維持するためには、ネットワークのセキュリティを保護するためにマイナー（現在はバリデーター）を継続的にインセンティブ化する必要があります。ビットコインのようにハードキャップを設定した場合、新しいコインがすべて使い果たされた場合、取引手数料だけでネットワークの長期的な安全性を保証できるかどうかは不明です。 そのため、イーサリアムはハードキャップを設けない戦略を採用しました。しかし、これは無限にインフレーションするわけではありません。イーサリアムの通貨政策はいくつかの重要な調整を経てきました：\n初期（プルーフ・オブ・ワークPoW）：ビットコインと同様に、マイニングによって新しいコインが生成されますが、明確な総量上限や固定された減半サイクルはありませんでした。これにより、インフレーション率は比較的高いです。 ロンドンアップグレード（EIP-1559）：取引手数料の「焼却」メカニズムが導入されました。ユーザーが支払う取引手数料の一部は、基礎手数料として直接「焼却」（流通から永久に削除）されます。つまり、ネットワークのトランザクションが活発な場合、ETHの焼却量は新規発行量よりも多くなる可能性があり、インフレーションにつながります。 合併（The Merge）：イーサリアムは、「マイニング」（プルーフ・オブ・ワークPoW）から「ステイキング」（プルーフ・オブ・ステークPoS）に移行しました。現在、マイナーは電力を使って問題を解く必要がなく、代わりに「バリデーター」が自分のETHをステーキングすることで会計権と報酬を得ます。この転換により、新規ETHの発行速度が大幅に低下（90%以上）しています。 イーサリアムの特徴のまとめ： ハードキャップなし：ネットワークの長期的な安全性と開発のための柔軟性を提供します。 動的供給：焼却メカニズムとステーク報酬による動的なバランスにより、総供給量は穏やかにインフレーションする可能性も、トランザクションが活発な期間にはディフレーションする可能性もあります。その目標は絶対的な希少性を目指すのではなく、十分なセキュリティを維持しつつ、ETHを「燃料」として利用可能に保つことです。 コアの違いを一覧 特性 ビットコイン (Bitcoin) イーサーステート (Ethereum) コアな定位 デジタルゴールド、価値の貯蔵 世界コンピュータ、分散型アプリケーションプラットフォーム コアの違いを一覧 特性 ビットコイン (Bitcoin) イーサーステート (Ethereum) 総発行上限 あり，2100万枚 なし コアの違いを一覧 特性 ビットコイン (Bitcoin) イーサーステートム (Ethereum) 通貨政策 有弾力性（総量固定、供給量減半） 動的供給（発行＋銷毁、インフレもデフレも可能） コアの違いを一覧 特性 ビットコイン (Bitcoin) イーサーステートム (Ethereum) 発行目的 鉱工への報酬、マイニング完了まで 長期的にネットワークのセキュリティと運用を保障 主要の違いを一目で このわかりやすい説明が、それらの関係と違いを理解するのに役立つことを願っています！\n","date":"2025-07-21","language":"ja","permalink":"https://ttf248.life/ja/p/digital-currency-fundamentals/","tags":["暗号通貨 (أنگyū tsūkō)","ブロックチェーン","暗号資産","貨幣政策 (Kagiin seisaku)","フィンテック (FinTech)"],"title":"暗号資産の基礎概念","year":"2025"},{"categories":["金融知識データベース"],"content":"会社は最近、香港市場で資金調達を行っています。この資金調達は、小米が行ったものと似たようなものであり、本稿では詳細に分析します。\n九方智投配售案の解釈 配当参加について、費用はどの程度かかりますか。これらの株式はいつ売却可能ですか。この文書には他に重要な情報が含まれていますか\n✅ 配售における費用 本配售后は、既存株主が旧株から新株を配售するという配售后であり、配售后の対象は新規投資家（承配人）であり、一般の個人投資家の申込みには該当しないため、以下の通りです。\nもしあなたが承配代理によって選ばれた承配人（すなわちプロ/機関/個人投資家ではない場合）であれば、費用は発生しません。\n✅ 配售に関わる費用 もしあなたが承配人である場合、かかる費用は以下の通りです。 | 配售価格 | ✅ はい | 1株あたり39.25香港ドル |\n✅ 配售に関わる費用 費用タイプ 承配人が負担するか 備考 经纪佣金 ✅ はい 配售价、手数料、印紙税などを含まない ✅ 配售に関わる費用 費用タイプ 承配人が負担するか 備考 取引手数料 / 証券取引手数料 ✅ はい 香港株式の取引ルールに従って徴収 ✅ 配售に関わる費用 費用タイプ 承配人が負担するか 備考 印紙税 ✅ はい 香港株式の売買には0.13%の印紙税がかかります ✅ 参加卸売に関わる費用 ✅ 割当株式の売却時期について 公告内容に基づくと：\n「割当株式は、ブローカー代理が少なくとも六名以上の承受人に対し最大限努力のもと配当し、完了次第売却いたします。配售后完成后，预计任何承受人が本社の主要株主となることはありません。」\n✅ 株式の売却時期について これは以下の意味を示します：\n配当株式の譲渡制限が解除され、自由に流通可能になります。 ロックアップ期間はありません。 香港証券取引所（ヒンゲン）の二次市場で自由に売買できます。 配当株式の最終期限は2025年7月17日であり、譲渡完了は7月17日またはその直後のいずれかで完了する見込みです。 ✅ 重要なお知らせ 資金用途（746.22億港元淨額） 九方智投はこの資金を以下の４つの事業に活用します： | チェーン上金融資源投資 | 未定義 | RWA基層資産、デジタル資産取引所、信託銀行、ステーブルコイン運営主体への投資 |\n資金用途（746.22億港元純額） 用途 割合 説明 デジタル資産サービス戦略展開 不明瞭 香港および中東地区、Cエンド向けのデジタル資産投資サービス 資金用途（746.22億港元淨額） 用途 比率 説明 デジタル資産投資顧問の新モデル 不明 AI + 研究、MCN運用経験との組み合わせ 資金用途（746.22億港元純額） 用途 比率 説明 流動性補充 不明 一般企業用途 配售価格の割引が大きい 7月15日の終値41.75香港ドルから6.0%の割引 過去5日間の平均価格47.30香港ドルから17.0%の割引 過去10日間の平均価格46.36香港ドルから15.3%の割引 株式構成の変化 募集引受終了後、総株数は4.48億株から4.68億株へ増加 既存株主の保有割合が若干希釈されたものの、依然として控股地位を維持 新増設発行20,000,000株を承配人が保有し、総株数に占める割合は約4.27% リスクに関する注意喚起 募集事項は必ずしも完了するとは限らない。市場の安定性、規制当局への届出、重大な不利事象など、複数の条件を満たす必要がある。 14日以内に完了しない場合、投資信託の購入手続きは自動的に無効となる。 ✅ 概要一言以蔽之 一般投资者无法参与此次配售；配售股份无锁定期，交割后即可交易；九方智投拟用7.46亿港元布局数字资产与链上金融，未来或向Web3、AI投资顾问方向转型。\n要点：\n概要一言以蔽之 (Gyōsai ichimon ni moishizu) - Summary in one sentence 将原文翻译成日语，并保持了Markdown格式。 「先旧后新」配售方式详解 Kimi: \u0026ldquo;既存株主が旧株から順に売却」は、香港株式市場で一般的な配售方式であり、英語では Top-up Placement と呼ばれます。これを「大株主がまず旧株を売り、その後新規株式を発行する」という二段階のプロセスと理解できます。\n✅ 例を挙げれば理解できます 九方智投の例として：\n第一段階：主要株主が旧株を売却（先旧） 既存の株主（Coreworth Investmentsなど）が既に保有している20,000,000株の旧株を、市場参加者（承配人）に39.25香港ドル/株で販売します。 この結果、主要株主の持ち株数が減少し、発行済株式総数は変わらないことになります。 第二段階：会社が主要株主に新株を発行（後新） これらの主要株主に同じ数量（20,000,000株）の新株を39.25香港ドル/株で発行します。 主要株主は、旧株の売却代金で新株を購入し、持ち株数を元の状態に戻すことになります。 しかし、発行済株式総数は増加（4.48億株から4.68億株へ）し、会社が成功裏に資金調達を達成したことになり、主要株主の持ち株比率がわずかに希薄化することになります。 ✅ なぜそうするのか？ 目的 説明 迅速な資金調達 新株発行のように長期間かかるプロセスを回避し、大株主が既存株式を先行して売却し、その後新株式を発行することで、迅速に資金を得る。 ✅ なぜそうするのか？ 目的 説明 支配権を維持する 主要株主の最終的な保有株式数が変わらないため、支配権が過度に希薄化されることはない。 ✅ なぜそうするのか？ 目的 説明 新規投資家の獲得 ディスカウントによる割当を通じて、機関投資家や富裕層の投資家を誘致し、株主構成を最適化する。 ✅ なぜそうするのか？ ✅ 主要違い：旧株 vs 新株 タイプ 新株の有無 直ちに取引可能か 説明 旧株 ❌ 不再発行 ✅ 即時取引可能 市場に出回っている既存の株式で、新規投資家に販売した後も直接流通します。 ✅ 主要違い：旧株 vs 新株 タイプ 新発行株式の有無 即時取引可能か 説明 新株 ✅ 新規発行 ⚠️ ロック期間あり（通常180日） 会社が新たに発行する株式で、既存の大株主へのもので、通常は一定期間ロックされます。 ✅ 主要違い：旧株と新株 ✅ 要点まとめ 「旧換新上」とは、大株主がまず保有株式を市場に売り放ち、その後、同じ数だけ新規株式を購入することです。これにより、会社は資金調達を行いながらも、経営権を失うことなく維持することができます。\n恒生發行規則解讀 Kimi: 你的疑問非常關鍵：「為什麼恆生上市公司看起來可以『隨意』增發股票？是不是香港市場規則特別寬鬆？」 答案是：「是的，恆生比A股確實更寬鬆得多」，但也「不是『毫無限制』」，而是有一套「寬鬆但有限」的規則體系。\n✅ 上場株式市場（香港株）とA株：増資ルールの比較（主要な違い） プロジェクト 上場株式市場（香港株）ルール A株ルール 株主総会での承認が必要か ✅ 毎年株主総会で一度の権限を付与し、取締役会が資本増強（発行）を最大20%まで行うことができる。その後、別途会議は不要 ❌ 各増資ごとに個別株主総会を開催し、2/3以上の賛成を得る必要あり ✅ 上場適格証券（H股）とA株：増設ルール比較（主要な違い） プロジェクト 上場適格証券ルール A株ルール 証券取引委員会（SEC）の承認が必要か ❌ 20%以下の資本増強＋割引価格が20%以下の場合、「フラッシュ配分」が可能 ✅ SECによる個別承認が必要で、プロセスが長い ✅ 港股とA株：増発ルール比較（コアな違い） プロジェクト 港股ルール A株ルール 増発比例上限 ✅ 単次最多20%，12ヶ月内累積摊薄不得超过25% ✅ 一般不得超過30% ✅ 港股とA株：増発ルール比較（コアな違い） プロジェクト 港股ルール A株ルール 価格下落幅制限 ✅ 発行価格は市場価格の80%を超えないこと（最大20%引き下げ） ✅ ヘดターゲット増発は市場価格の80%を超えないこと ✅ 恒生指数 vs 上海総合指数：増配ルール比較（コアな違い） プロジェクト 恒生指数ルール 上証指数ルール ✅ 上場適格証券（H股） vs A株：増設ルール比較（主要相違点） プロジェクト 上場適格証券ルール A株ルール 用途制限 ✅ lediglich die Offenlegung des Zwecks, keine wesentliche Prüfung ✅ Muss den Zweck detailliert erläutern, 証券取引委員会（SEC）は却下できる ✅ 上場適格証券の比較：増配ルールに関する主要な違い（コアな差異） ✅ 港元株が「気楽」に見える理由？ 「一般性授権」メカニズム: 毎年株主総会で、取締役会の新規発行株式上限20%を一度に認可し、その後別途株主総会を開く必要がない。取締役会は、状況に応じて株式を発行できる。 「閃電配售（シャンドンパイセウ）」メカニズム: 新規発行が20%の資本上限を超えず、割引率が20%を超えなければ、24時間以内に発行を完了できる。審査は不要。 証券取引委員会による逐次承認は不要: 香港証取引所は、形式的な審査のみを行い、資金の用途や企業の質に実質的な介入を行わない。 ✅ 例を挙げます：九方智投が今回なぜ「旧から新へ」という展開を実現できたのか？ 九方智投は2025年6月20日株主総会で一般性承認を得ており、新たに最大20%（つまり89,671,400株以下）の新株式の発行を認可されています。 本件では20,000,000株を発行し、**資本の4.46%**に過ぎず、20%の上限を下回っており、承認条件を完全に満たしています。 したがって、再度株主総会を開催する必要はなく、証券取引委員会（SEC）の承認も不要で、取締役会が決定することができます。 ✅ 概要一言で表すと 香港株式市場は、「取締役会＋年次承認」の迅速な増発を可能にし、20%を超える資本比率や割引上限を超えない限り、「即時配当」を実施できます。一方、中国A株では、毎回株主総会と証券監督管理委員会（CSRC）の承認が必要であり、手続きが長く制限が多くなります。\n✅ 要点まとめ したがって、九方智投は「随意増発」ではなく、香港株の緩やかな市場メカニズムを合法的に活用したものです。\n","date":"2025-07-21","language":"ja","permalink":"https://ttf248.life/ja/p/hksg-flash-crash-sell-off-case/","tags":["恒生指数 (こうせいしじょ)","予約受付中 (yoyaku uketsuke-chuu)","投資 (tōshi)","金融"],"title":"香港株式市場（HONG KONG）の閃電配当（FLASH DEAL）事例","year":"2025"},{"categories":["金融知識データベース"],"content":"内地の居住者が香港株式および米国株式に投資する場合、関連する税制を理解することは非常に重要です。本稿では、資本所得税とは何か、香港・米株への投資がなぜこの税種に関与するのかを包括的に分析し、CRS（常設事務所規則）の仕組みを解説します。さらに、本稿では、内地の居住者が香港証券会社、滬港通、深港通といったさまざまなチャネルを通じて香港・米株に投資する場合の税務上の責任と具体的な税率についても詳細に説明します。\n核心概念解説 (Kokoronihongo Kekisai) 資本利得税（Capital Gains Tax）とは？ 資本利得税（CGT）とは、資産を売却して得た利益に対する課税のことです。これらの資産には、株式、債券、不動産、貴金属などが含まれます。購入価格よりも高い価格で資産を売却した場合に発生する収益（資本利益）は、資本利得税の対象となる可能性があります。\n留意点として、すべての国や地域が資本利得税を課すわけではありません。例えば、香港では現在、資本利得税は徴収されていません。\nなぜ港元株に資本所得税が発生するのか？ 米元株：米国は資本所得税を課す国です。非アメリカの納税居住者（例えば、ほとんどの内地投資家）が米元株を売却する場合、通常は資本所得税を免除できますが、いくつかの条件を満たす必要があります（例えば、1年間の米国在留日数が183日を超えないこと）。しかし、米元株からの配当（股息）は、通常30%の源泉徴収税がかかります。ただし、中国内地とアメリカ合衆国間の租税協定により、中国内地居住者の税率は10%に軽減される場合があります。 港元株：上記のとおり、香港は資本所得税を課しません。したがって、どのようなチャネルを通じて港元株を取引する場合でも、株式の売買差益に対して税金を支払う必要はありません。ただし、これは内地居住者がこの部分の収益について中国内地税務当局に申告する必要がないことを意味するものではなく、むしろそうする必要があります。 CRS申报とは（共同申报准則）？ CRS、すなわち「共同申报準則」（Common Reporting Standard）は、グローバルな金融口座に関する税務情報自動交換基準です。その主な目的は、海外の口座を利用した跨境逃税行為を打击することです。\n仕組み: 要約すると、CRSに署名している国/地域（例えば香港）の金融機関（銀行、証券会社など）は、その非本地の納税居民の口座を特定し、その口座情報（氏名、住所、納税居民身份、口座残高、年度総収入など）を所在地の税務当局に報告します。その後、税務当局はこれらの情報を、口座保持者として納税居民である国/地域の税務当局と交換します。\n内地投資家への影響: 香港の証券会社で口座を開設している内地居民の場合、その納税居民身份は中国内地であり、香港の金融機関は口座情報を香港税関を通じて中国国家税务总局に交換します。これにより、内地税務当局は海外の金融資産と収益に関する情報（所得）を把握し、グローバルな所得課税の基礎を提供することになります。\n内地居民美股交易税务详解 中国《个人所得税法》规定，中国税务居民个人需要就其来源于全球的所得缴纳个人所得税。这意味着，即使投资收益发生在境外，并且在当地可能免税，仍有义务向中国税务机关申报并缴纳税款。 近期，中国税务部门已加强对个人境外所得的税收征管力度。\n香港の証券会社を通じて香港株式および米国株式の取引 内地居住者の方が、香港の証券会社（富途證券、老虎證券など）を通じて香港株式および米国株式を取引する場合、税務上の責任は以下の通りです。\n米国株式取引：\n譲渡所得：米国株式の売買差益から得られる利益は、「資産譲渡所得」に該当します。中国個人所得税法に基づき、**20%**の税率で中国税務当局に申告・納税する必要があります。米国では通常、非居住者の資本利得税が免除されますが、中国の税務上の居住者として、この部分の全世界所得について中国への課税が必要となる場合があります。 配当金：米国株式から得られる配当金は、証券会社が通常**10%**の源泉徴収税（中米税制優遇措置を受けているもの）を代扣します。この時点で海外で納付された税額は、中国への申告時に控除できますが、その控除額は、この所得を中国の税法に基づいて計算した課税対象となる金額を超えない範囲に限られます。 香港株式取引：\n譲渡所得：香港には譲渡所得税がかかりませんが、内地居住者の方が香港株式から得られる価格差益も「資産譲渡所得」に該当し、**20%**の税率で中国税務当局に申告・納税する必要があります。 配当金：H株（内地で登録され、香港証券取引所に上場している会社）から得られる配当金は、発行体が通常**20%の個人所得税を代扣します。非H株（香港または海外で登録され、香港証券取引所に上場している会社）から得られる配当金は、香港側が通常10%**の配当税を代扣します。この時点で海外で納付された税額は、中国への申告時に同様に控除できます。 滬港通、深港通で取引を行う香港株式 内地と香港の資本市場の相互接続を促進するため、国家は特定の税制優遇政策を実施しています。\n譲渡益：財政部、税務総局、証券監督委員会が発表した公告に基づき、内地個人投資家が沪港通、深港通を通じて香港株式取引所上場株式を購入・売却して得た譲渡差額所得は、現時点では個人所得税を徵収されません。この優遇措置は明確に2027年12月31日まで延長されます。 配当金： 沪港通、深港通を通じて香港H株に投資し、得た配当金については、H株会社が**20%**の税率で個人所得税を代扣します。 香港非H株に投資して得た配当金については、中国结算有限公司が**20%**の税率で個人所得税を代扣します。香港で既に納付した予備的所得税は、有効な扣税憑証を提示し、中国结算の管轄税務局に申請することで、税収控除を受けることができます。 税務要点まとめ 投資先 投資対象 譲渡所得税 配当/分配金税 香港証券会社 米国株式 内地への課税申告、税率20% 米国源泉徴収10%、内地で控除可能 税務要点まとめ 投資先 投資対象 譲渡所得税 配当/分配金税 恒生株式 内地申告、税率20% H株：代扣20%；非H株：香港預提10%、内地抵免 税務要点まとめ 投資チャネル 投資対象 資本利得税 配当/赤字配分税 滬/深港通 香港株式 暫免課税（2027年末まで） H株：代扣20%；非H株：中登代扣20%，香港已納税可控除 税務要点まとめ 重要なお知事: 上記の情報は現在の政策に基づいています。税法は変更される可能性があるため、投資および税務申告を行う前に、専門の税理士にご相談いただくか、税務署が発表する最新情報を確認し、法令遵守を確実に行ってください。境外所得の自己申告期間は通常、翌年の3月1日から6月30日までです。\n","date":"2025-07-16","language":"ja","permalink":"https://ttf248.life/ja/p/comprehensive-analysis-capital-gains-tax-crs-and-inland-residents-hong-kong-us-stock-investment-tax-guide/","tags":["税務","投資 (tōshi)","金融知識","CRS","香港株式 / グローバル株式 (Global Stocks)"],"title":"包括次要内容在内的全面分析：资本收益税、CRS（自动脱税协定）及内地居民在香港和美国股票投资的税务指南","year":"2025"},{"categories":["投資 (tōshi)"],"content":"通常の人が保険証券を理解するのは、やや困難です。従来の投資戦略は年平均利回りによって理解されますが、増額寿险の計算方式は内部収益率（IRR）であり、この2つにはどのような違いがあるのでしょうか？なぜその差が生じるのでしょうか？\n→ 資金が一括で投入された場合、内部収益率（IRR） と 年平均利回り（Annualized Return） は計算結果において同じです。\n平易俗な解説 想像で、あなたは一棵木を植えます。\n一括投資 (Lump Sum Investment)：苗を買ったり、最初の肥料を与えたりする費用を一括で支払います。 年間収益率 (Annualized Return)：これは、あなたが毎年その木がどれだけ伸びたかを測り、平均して毎年何パーセント伸びるか計算することに似ています。これは、一年間におけるこの投資の平均的な成長率を測定します。 内部収益率 (IRR)：IRR の概念はより広範囲で、複数のキャッシュフロー（流入と流出）を処理できます。しかし、あなたが一括投資（一回のキャッシュアウト）を行い、最後に一括回収（一回のキャッシュイン）を行う単純な状況では、IRR も「平均して毎年何パーセント成長するか」を探し出し、その成長率で投資額が年利複利に計算された場合に、最終的に回収した金額と一致するようにします。 単一の投資、単一の回収の場合には、中間的なキャッシュフロー（例えば定期的な配当や追加投資）がないため、IRR の計算は単純化され、年利複利成長率を求めることになります。 例を挙げてみましょう 以下の仮定に基づいて計算します。\n初期投資: 2024年1月1日に、10,000元 を投資しました。 投資期間: 3年間 最終回収: 2027年1月1日に、13,310元 を回収しました。 1. 年換算利回り： 年換算利回りの計算式は以下の通りです。 $$\\text{年換算利回り} = \\left( \\frac{\\text{期末価値}}{\\text{期初価値}} \\right)^{\\frac{1}{\\text{投資期間}}} - 1$$ データに代入します。 $$\\text{年換算利回り} = \\left( \\frac{13310}{10000} \\right)^{\\frac{1}{3}} - 1$$ $$\\text{年換算利回り} = (1.331)^{0.3333} - 1$$ $$\\text{年換算利回り} = 1.1 - 1 = 0.1 = 10\\%$$ したがって、この投資の年換算利回りは 10% です。これは、あなたの資金が毎年平均して10％成長することを意味します。\n2. 内生収益率 (IRR) の計算: IRR は、すべてのキャッシュフローの現在価値 (NPV) をゼロにする割引率です。この例では、キャッシュフローには以下が含まれます:\n2024年1月1日：-10,000 元 (投資による支出) 2027年1月1日：+13,310 元 (投資回収額) 割引率 $r$ を求め、次の式を満たすようにします: $$-10000 + \\frac{13310}{(1+r)^3} = 0$$ $$\\frac{13310}{(1+r)^3} = 10000$$ $$(1+r)^3 = \\frac{13310}{10000} = 1.331$$ $$1+r = (1.331)^{\\frac{1}{3}}$$ $$1+r = 1.1$$ $$r = 1.1 - 1 = 0.1 = 10\\%$$ したがって、この投資の内生収益率 (IRR) は 10% です。 まとめ この一次性投入と一次性回収の単純な例では、年利回り（内部収益率）の計算結果は完全に同じになります。これは、この特定のケースにおいて、IRR の計算ロジックと年利回りの複利計算ロジックが等価であるためです。\nIRR が本来その力を発揮する状況は、投資に複数のキャッシュフローが含まれる場合です。例えば、毎月基金に投資する場合や、プロジェクトから異なるタイミングで配当を受け取り、最後に資金を回収する場合などです。このような複雑なキャッシュフローパターンでは、年利回りは投資の実際の収益を正確に評価できない可能性がありますが、IRR は資金の時間価値と投資全体の収益率をより適切に反映することができます。\n","date":"2025-07-09","language":"ja","permalink":"https://ttf248.life/ja/p/premium-whole-life-insurance-policy-interpretation/","tags":["保険","投資 (tōshi)","金融知識","増額生存保険 (Zōkakku Juhyōhoken)"],"title":"増額死亡保険契約の解釈","year":"2025"},{"categories":["投資 (tōshi)","コンピューター"],"content":"バックテストに必要なのは：配分法（変動率調整法）、わかりやすい例で説明します。同様に、加減算調整ができない理由を例を用いて説明し、Python で過去のデータを取得するための配分法データソースをおすすめします。\n核心概念：なぜ配当修正が必要なのか？ 投資の世界において、株式の価格は単に売買によって変動するだけではありません。上市公司が行う行為、例えば配当金の発行、株式分割、増資などは、株価に直接影響を与えますが、これらの変動は会社の真の価値の上昇または下落を反映しているわけではありません。\nたとえば、昨日終値が100円だった株式を保有していたとします。今日、会社が1株あたり5元の発行済みの現金配当金を発行するというプロセスを「除算」と呼びます（除算）。配当金を発行すると会社の総価値は減少するため、取引所は株価を5元下落させ、始値が95円になります。\nもし、95元と昨日の100元を使って上昇率を計算した場合、「-5%」という結論が得られます。しかしこれは明らかに誤りです。なぜなら、あなたの口座には5元の現金が増加し、あなたの総資産は損失していませんから。\n配当修正（Reinvestment/Adjustment） の目的は、配当金、株式分割などの非市場取引要因によって生じる株価の「ギャップ」を埋め、株価の真の動きを復元し、正確な収益率を計算したり、戦略を検証したりするために使用されることです。\n配当法（変動幅調整法）：通俗例の解説 核心思想： 配当法は、あなたが受け取ったすべての配当金や株式分割を、受け取るその瞬間に、当時の株価で即座に買い直すという仮定に基づいています。それは「総資産の変動率」に焦点を当てています。 例： あなたは 1日目 に 100元 の価格で 1 株 “マギカルカンパニー” の株式を購入します。あなたの総資産は 100元 です。 2日目、市場が変化していませんが、会社が 1 株あたり 2元 の配当金を発行することを発表しました。\n除息後、株価は自動的に 100 元から 98元 に下落します。 その時点で、あなたの保有ポジションは 1 株の株式（98元）+ 2元の現金になります。 あなたの総資産は依然として 98 + 2 = 100元 で変わりません。 3日目、マギカルカンパニーの株価が 98 元から 102.9元 に上昇します。 変動率はどれくらいですか？それは (102.9 - 98) / 98 = 5% です。 あなたの総資産は現在いくらになりますか？ もし配当金を再投資しなければ：1 株の株式（102.9 元）+ 2 元の現金 = 104.9 元。 私たちが配当法を使って「複利調整」された価格を計算する場合、私たちは 2 元の現金を除息日（2日目）に 98 元の株価で即座に買い直すと仮定します。ただし、計算を簡略化するために、配当法は単純に昨日の価格に基づいて変動率を乗算します。 配当法の計算ロジック： それは、2日目の総資産（100元）と1日目の総資産（100元）の比率が 0% の増加であることを示唆しています。3日目の総資産は、2日目に比べて 5% 上昇します。 したがって、それは次のような複利調整された価格シーケンスを構築します： 1日目複利調整価格： 100 元 2日目複利調整価格： 総資産が変化していないため、昨日の終値に基づいて今日の真の変動率を反映するように調整します。調整方法は、昨日の複利調整価格に今日の実際の変動率を加算することです。ただし、除息日当日、実際の変動率は 0%（総資産が変わらないため）であり、複利調整価格はそのままか、または技術的な調整が行われます。ここでは単純に3日目の価格を見ています。 3日目複利調整価格： 1日目の複利調整価格 * (1 + 0%) * (1 + 5%) は不正確です。正しいロジックは、除息前の価格を基準として、それを「割引」することです。 より明確な前複利の角度で理解しましょう： 3日目 の終値は 102.9 元 です。（基準） 2日目 の終値は 98 元 です。 1日目 の終値は 100 元ですが、2日目に除息（株価が 100 から 98 に下がったため、98/100 = 0.98 で割引された）が発生したため、これを後の価格と一致させるために調整する必要があります。 修正された1日目の価格 = 102.9 / (1 + 5%) / (100/98) … この計算は非常に複雑です。 最も簡単な理解方法（変動幅調整法）： 配当法の核心は、その期間内の変動幅が「配当金を再投資」戦略の下での総収益率と一致するように、2日目から3日目の複利調整価格の変動幅を保証することです。 1日目の終値から3日目の終値まで、あなたの実際の総収益率は (104.9 - 100) / 100 = 4.9% です。（ここでは配当金を再投資していないと仮定します） なぜ「加減法複権」は使えないのか？ 核心思想： 加減法複権は、単純な足し算によって配当金を直接除息前の株価に加えることを試みます。 例（前文を参考に）：\n第一天終値：100元 第二天除息2元、終値：98元 第三天上昇5%、終値：102.9元 加減法の誤った論理： それは、第二日の98元が2元の配当金によって減少したため、その2元を「戻す」必要があると考えるでしょう。\n計算される第二日の「複権価格」＝98 + 2 = 100元 計算される第三日の「複権価格」＝102.9 + 2 = 104.9元 現在、この「複権価格」系列を使って第三日の変動率を計算します。\n変動率 = (104.9 - 100) / 100 = 4.9% 問題はどこにあるのか？ この4.9%の変動率は間違っています！前述したように、株価の実変動率は(102.9 - 98) / 98 = 5%です。加減法で得られた4.9%は、株の実際の成長能力を過小評価しています。\nなぜ過小評価されるのか？ それは、加減法が「複利」効果を考慮していないためです。比例法では、2元の配当金も5%という速度で成長すると仮定しますが、加減法はそれを粗暴に2元として扱い、その後の投資の増加に組み込まないと考えています。時間の経過とともに、配当回数が増えるにつれて、この誤差はますます大きくなり、バックテストの結果が大きく歪んでしまいます。特に高配当株においては顕著です。\n一言でまとめると： 加減法は価格系列の「成長率」情報を破壊し、収益率の計算を誤らせる。比例法は実際の「収益率」を保持しており、バックテストの正しい選択である。\nPythonで過去のデータ「配分法」データソースのおすすめ 実践において、私たちは通常、自分で複利調整を計算する必要はありません。専門的なデータプロバイダーは、すでに計算された複利調整後の価格を直接提供してくれます。APIを呼び出す際に、正しい価格タイプを選択するだけで済みます。これは一般的に「Adjusted Price」（調整後価格）と呼ばれます。\n以下に、Pythonで複利調整後の過去のデータを取得するために高く評価されているデータソースをいくつかご紹介します。\nyfinance (Yahoo Finance)\nメリット: 完全無料、使いが簡単で、個人開発者や初心者にとって最初の選択肢です。提供されるデータはデフォルトで配分法（前複利調整）されています。 デメリット: データがクリーンでない場合や、まれに遅延が発生する可能性があります。非常に厳格なビジネス戦略の場合には、より専門的なデータソースが必要になる場合があります。 Pythonでの使用例: TuShare\nメリット: 国内で非常に人気のある金融データインターフェースで、A株、香港株、米国株など豊富なデータを提供しています。データ品質は高く、ポイント制度があり、基本的なデータは無料で利用できます。明確な複利調整因子と複利調整後の行情インターフェースを提供しています。 デメリット: トークンを取得するために登録する必要があります。一部の高度なデータや高頻度の呼び出しにはポイントが必要です。 Pythonでの使用例（事前にトークンを取得する必要があります）: baostock\nメリット: 無料でオープンソースの中国A株証券データプラットフォームです。データの安定性と正確性が高く、複利調整オプションも提供しています。 デメリット: 主にA株市場をカバーしています。 Pythonでの使用例: 商用級データソース (Quandl/FactSet, Refinitiv, Bloomberg)\nメリット: データ品質が最も高く、カバー範囲が最も広く、更新頻度が最も速く、プロフェッショナルなAPIと技術サポートを提供しています。 デメリット: 非常に高価で、主に金融機関や企業ユーザーを対象としています。 初心者へのアドバイス: yfinance または TuShare から始めてください。これらのデータソースは、学習、研究、および個人プロジェクトのバックテストのニーズを満たし、配分法複利調整データの理解と適用に役立ちます。APIを呼び出す際には、「Adjusted」または「複利調整済み」オプションを選択することを必ず確認してください。\n","date":"2025-06-27","language":"ja","permalink":"https://ttf248.life/ja/p/where-can-i-find-backtest-data/","tags":[],"title":"回測データはどこで入手できますか？ (Kaiteki data wa doko de otten kitemasu ka?)","year":"2025"},{"categories":["金融知識データベース"],"content":"本レポートは、米国株式オプションコード「SST1G182500500.U」を深く分析し、特にその正股コード部分がInteractive Brokers (IB) に送信する際に「SST 1」として表示される理由を探ります。期権記号の標準化構造、関連会社およびブローカーの内部処理メカニズムを分析することで、この現象の背後にある原因とその取引者への影響について明らかにします。\n米国株式オプション記号標準化（OSI） 期権市場の効率的な運営と透明性を確保するため、米国期権決済会社（OCC）は、期権記号イニシアティブ（OSI）と呼ばれる標準化された期権符号体系を策定しました。この体系は、統一されたアルファ数字形式を採用し、期権契約の重要な情報を明確にコード化します 1。2010年2月12日以降、21文字で構成されるOSI規格は、米国およびカナダにおいて全面的に実施され、それまで混乱していた5文字コード形式を代替しました 1。\n標準的なOSI期権符号には、通常以下の4つの主要な要素が含まれます。\n原資産コード（Root Symbol）: これは、期権が基づいている株式またはETFのコードです。このフィールドは最大6文字を含み、通常は原資産の取引コードと同一です。例えば、ナイキ株の期権根符号は「NKE」です 2。OSI形式では、根符号が6文字未満の場合、スペースで埋めて6文字の長さになるようにします 1。 満期日（Expiration Date）: これは6桁の数字で構成され、「年年-月月-日日 (yymmdd)」の順序で期権の満期日を表します。例えば、「220624」は、期権が2022年6月24日に満期を迎えることを示します 2。 コール/プット指示符（Call/Put Indicator）: これは単一文字のフィールドで、期権の種類を示します。‘C’はコールオプション（看漲期權）を表し、保有者が特定の価格で原資産を購入する権利を付与します。‘P’はプットオプション（看跌期權）を表し、保有者が特定の価格で原資産を売却する権利を付与します 2。 行使価格（Strike Price）: これは、期権が購入（コール）または販売（プット）するために設定された原資産の事前価格です。OSI形式では、行使価格は8桁の数字で表され、最後の3桁は小数部分を表します（「mills」、100分の1ドル）。実際の行使価格を読むには、この8桁の数字を1,000で割るか、小数点字動して左に3桁移動する必要があります。例えば、「00099000」は行使価格が99.00ドルであることを示します 2。 期権は、その価値が原資産に依存するデリバティブです。米国の大半の期権は、シカゴ期権取引所（CBOE）などの交易所で取引され、OCCを通じて決済されます。OCCは世界最大の株式デリバティブ決済組織であり、SECおよびCFTCの規制下で運営され、期権市場の安定性と完全性を確保しています 2。\n解析期権コード SST1G182500500.U ユーザーが提供した期権コード「SST1G182500500.U」は、OSI形式の要素を含んでいますが、また非標準的な表記方法も存在し、これは通常、会社の方針調整や証券会社の内部表示慣例に関連しています。\nSST1：調整後の正株式コード 「SST1」は、本期オプションコードにおいて最も重要な部分であり、ユーザーが正株式コードが「SST 1」である理由、そして「SST」ではなくなった理由に関する核心的な疑問に直接答えます。この「1」の接尾辞は、会社側の行為（株式分割、合併など）によりオプション契約が調整されたことを示すものです。\nOCC の公式情報メモ #56689 (2025 年 6 月 11 日) に明記されている通り、「オプション記号：SST が SST1 に変更された」こと、およびこの変更の適用日である 2025 年 6 月 12 日 3 を示しています。このメモが「標的コードが「SST1」である理由」を明確に説明しています。また、Robinhood などの証券会社も同様の慣例を確認しており、「保有株式オプションで逆分割が発生した場合…株式コードには数字が付加されます。例えば、ABC のオプション契約を保有している場合、逆分割後には ABC1 と表示される」 4 と述べています。この業界慣習はさらに「SST1」接尾辞の有効性と目的を裏付けています。\nG1825：満期日（非標準形式） “G1825”の部分は、OSI規格の「年年-月月-日日 (yymmdd)」形式（例：2025年7月18日は“250718”）とは明らかに異なっている 2。 OSIの実装前に、オプション符号は通常、単一文字コードを使用して満期月を表用していた 5。この古い慣習では、「G」は7月のコールオプションを意味した 5。もしこのロジックに従うならば、「18」は日付、「25」は年を表すことになる。したがって、「G1825」は最も可能性として 2025年7月18日 と解釈されるだろう。 OSI規格が明確にこの文字コードによる満期日の表示方法を廃止したにもかかわらず、SST1（OSIの後付けの調整慣例）と“G1825”が並存しており、Interactive Brokersまたはそのデータソースが混合型または内部表現を採用していることを示唆する。これは、調整後のオプションへの対応策としての遺留形式であるか、あるいはブローカー独自の表示慣例であり、古い符号体系の要素を新しい調整指示符と組み合わせたものである可能性がある。オプション符号におけるこの不一致性、すなわち、コアなOSI調整根符号と非標準的な満期日形式が並存することは、金融データ標準化における「ラストワンマイル」の課題を反映している。中央機関が統一を目指す一方で、ブローカーは互換性、内部データ管理、またはプラットフォーム機能のために微妙な差異や追加識別子を導入する可能性がある。これにより、「公式」OSI符号と、ユーザーが特定の取引プラットフォームで目にするか、入力する必要がある符号との間に差異が生じる可能性がある。したがって、オプショントレーダーは、一般的なOSI規格だけでなく、ブローカーが符号表示における微細な違いを理解し、適応する必要がある。\n00500：権利価格 ユーザーが提供した“00500”は五桁の数字であり、これはOSI標準の八桁の権利価格フィールドと一致しません（1）。OSI規則に従い、八桁の数字を1,000で割ると実際の権利価格が得られ、「00000500」は0.50米ドルとなります。 SST株式が10株に対して1株の逆分割を行った場合（9）、権利価格は分割比率に応じて調整されることが一般的です（例えば、5.00ドルの権利価格が1:10の分割後に0.50ドルになる可能性があります）。したがって、0.50ドルのような非常に低い権利価格は、調整後のオプションにとっては十分に妥当です。この五桁の数字“00500”は数値500を表しており、これを“mills”（千分の一ドル）として変換すると、0.50米ドルとなります。数字桁数の違いは、IBの内部表現が完全な8桁のOSI形式に変換する前に、極小権利価格の先導ゼロを切り捨てるか、異なる内部エンコーディングを使用している可能性があります。\n.U：券商特定后缀 “.U”という接尾辞は、OCC/OSI 21 文字形式の標準的な一部ではありません。おそらく Interactive Brokers (IB) またはその特定の市場データプロバイダーが使用する内部識別子またはフラグである可能性が高いです。このような接尾辞は、独自のシステムで、契約に関する追加情報（例えば、取引所、特定の取引の特徴、データベース内の固有識別子など）を伝達するためによく見られます。\nコアな焦点：SST1 ルート記号 期権記号の他の部分が厳密な OSI 仕様からのわずかな逸脱がある可能性はあっても、「SST1」ルート記号は間違いなく最も重要な要素です。それはユーザーの核心的な質問に直接答えるものであり、記号変更を引き起こした企業の行動を指し示しています。\n会社行動への影響：System1, Inc.（SST）の逆抽出 企業行動がオプション契約の調整に及ぼす普遍的な影響 オプションは金融派生商品であり、その価値は直接的に対象資産（例えば株式[1]）に依存します。したがって、対象証券に影響を与える重要な出来事（通常は企業行動と呼ばれます）は、未決済オプション契約の条項にも反映される必要があります。これにより、派生商品の経済的価値と完全性が維持されます[^13]。\n企業行動には、株式分割（正方向および逆方向）、合併、買収、特別配当金、および分社など、幅広い出来事が含まれます[^13]。各タイプの行為はオプション契約に独自の影響を与える可能性があります。\nオプション清算会社（OCC）は、米国オプションの主要な中央清算所として重要な役割を果たします。それは、これらの企業行動に対応するために、未決済オプション契約に必要な調整を法的に決定および実施する責任を負っています[^13]。これらの調整は、詳細なOCC情報メモを通じて市場参加者に正式に伝達されます3。\n調整の方法は企業行動によって異なり、行渡価格の変更、各契約が表す株式数（または他の資産、つまり権利取引可能物）の変更、さらにはオプション記号自体を含む可能性があります。これらの調整の全体的な目標は、オプション保有者がオプション契約の総内在価値を維持できるようにすることです[^13]。\n逆株分割とそのオプション条項への典型的な影響 逆株分割とは、発行済株式数を減らすとともに、理論上の株価を比例して引き上げる企業が行う行為6である。例えば、10:1の逆分割は、投資家が以前保有していた10株が1株に減少するものの、新株1株あたりの理論的な価値が旧株の10倍になることを意味する6。\nオプション契約においては、逆株分割に伴い、通常、契約条項の調整が必要となる。OCC（米国商品先物取引委員会）が具体的な調整方法を決定し、オプション契約が表す基礎資産株式数（例えば、1:10の分割の場合、100株から10株に減少させる）を変更したり、または比例して行使価格を引き上げたりすることがある[^13]。その目的は、分割前の価値と調整後の価値を一致させることにある。\n逆株分割の結果として、オプションの符号が変更されることが多く、通常、元の株式コードの後ろに数字が付加される（例：「1」）。これにより、これらの調整後のオプションを、分割後に新規発行された標準的なオプションと区別することが可能になる3。顕著な副作用として、これらの調整後のオプションは流動性が大幅に低下する傾向がある[^13]。\nSystem1, Inc. (SST) 1株分割 10株逆分割の詳細 System1, Inc. (NYSE: SST) は、全チャネル顧客獲得マーケティングプラットフォームとして、1株分割10株の逆反結合株式分割を実施することを公表しました。この企業行為は、2025年6月12日の市場開始前に有効となります 6。\n今回の逆反分割の主な目的は、Aクラス普通株式の1株あたりの取引価格を向上させ、会社がニューヨーク証券取引所 (NYSE) の上場要件を満たすことができるようにすることです 6。\nこの分割の結果として、System1 の10株の普通株式（保有株式を含む）はすべて1株の新規株式に自動的に再分類されました 7。これにより、発行済みおよび流通しているAクラス普通株式の総数が約7,980万株から798万株に大幅に減少しました 7。\n逆反分割が行われたにもかかわらず、同社のAクラス普通株式はニューヨーク証券取引所で既存の取引コード“SST”を使用して引き続き取引されますが、CUSIP番号が更新されています 7。\nOCCが調整の決定と実施における役割：SSTからSST1へのシンボル変更 System1, Inc. の逆株分割に対処するため、OCCは2025年6月11日に情報メモ#56689を発行し、オプション契約の調整に関する具体的な詳細を提供しました 3。\nこのメモでは、2025年6月12日以降、「オプションシンボル：SSTをSST1に変更」と明示していました 3。OCCからの公式指示であり、ユーザーオプションコードに「SST1」が根シンボルとして現れる明確な理由です。\nさらに、このメモでは調整条項が説明されています。「契約乗数：1。行使価格除数：1。新規乗数：100（例えば、プレミアムまたは行使価格の米ドル拡張の場合、1.00は100ドルに相当します）」 3。これは、名目上の契約乗数が依然として100であるにもかかわらず、「SST1」シンボルが参照する対象資産が、1株分割10株の分割を反映して調整されたことを示しています。メモでは、「SST1の対象価格は、以下の方法で決定されます：SST1=0.10（SST）」 3 と明確に述べています。これは、「SST1」オプション契約が現在、100単位を表していることを意味しますが、各単位は元のSST株の0.1株に対応し、分割後も総契約価値を維持します。\nOCCのSSTオプション契約における権利対象資産の調整 1株分割10株反転株式分割の場合、OCCは既存のSSTオプション契約を調整し、その総経済価値を維持することを目的としています。OCCは、各契約の株式数を100株から10株に（これは特定の分割シナリオでは発生する可能性があります）変更せず、代わりに権利対象資産の記号自体を「SST1」に変更しました。\nこの「SST1」記号は、オプション契約が引き続き100単位を表しますが、各単位は現在元のSST株式の0.1株に対応します3。したがって、「SST1」オプション契約は有効に100 * 0.1 = 10株分割後のSST株式を代表します。行使価格は記号名義上は変更されていませんが、この再評価された資産に適用されます。このアプローチにより、契約の総行使可能価値が分割前の価値と一致するように保たれます。たとえば、オプションが1:10分割前に行使価格が50ドルである場合、その行使価値は5,000ドル（100株 * 50ドル）になります。分割後、新規発行された分割後のSSTオプションの行使価格は500ドルになります。ただし、調整後の「SST1」オプションは元の行使価格（たとえば50ドル）を維持し、それを0.1株の資産に適用することで、有効に5,000ドルの総価値を保持します[^13]。\n表 1：SST逆分割がオプション契約の特徴に与える影響\n| 権利対象株式記号 | SST | SST（新規株式および新規オプション用） |\nOCC に対する SST オプション契約の権利内容の調整 特徴 1 股分割 10 股逆反分割前（2025年6月12日 prior） 1 股分割 10 股逆反分割後（2025年6月12日 after） 調整後のオプション記号 SST (標準オプションの根記号) SST1 (既存、調整後オプションの根記号) OCC の SST オプション契約における割付対象の調整 特徴 1 株式分割・10 株式反転分割前（2025年6月12日 prior） 1 株式分割・10 株式反転分割後（2025年6月12日 after） 各契約の有効株式数 100 株 SST 分割後のSST (100 個の SST1 单位で) OCC に対する SST オプション契約の対象物の調整 特徴 1 股分割 10 股逆反分割前（2025年6月12日 prior） 1 股分割 10 股逆反分割後（2025年6月12日 thereafter） 行使価格調整 元行使価格 元行使価格 (対象物調整後適用) OCC の SST オプション契約における割付対象の調整 特徴 1 股分割、10 股逆分割前（2025年6月12日 prior） 1 股分割、10 股逆分割後（2025年6月12日 after） 対象 CUSIP 元 CUSIP 新 CUSIP (87200P208) 10 OCC に対する SST オプション契約の権利内容調整 特徴 1 股分割、10 股逆反分割前（2025年6月12日 prior） 1 股分割、10 股逆反分割後（2025年6月12日 thereafter） 権利内容調整後の流動性 通常 低下傾向（13） OCCによるSSTオプション契約の対象資産の調整 企業行動、特に逆株分割は、企業の財務にとって極めて重要ですが、デリバティブ市場への影響はしばしば「予期せぬ」ものであり、顕著な低効率をもたらします。独自の「調整オプション」を作成し、流動性が低く、価格設定と取引が複雑であるため、この証券のオプション市場を細分化させます。このような細分化は、全体的な市場効率を低下させ、買い手・売り手の価格差が拡大したり、価格発見が困難になったりする可能性があります。これは、企業ガバナンスのニーズ（例えば、上場要件を満たすための株式分割など）と、完全に流動的でシンプルなデリバティブ市場への期待との間の直接的なトレードオフを反映しています。\n期権清算会社 (OCC) はこのプロセスにおいて極めて重要な役割を果たします。企業行動は、対象資産の本質を根本的に変化させます。介入がなければ、デリバティブ契約において重大な乖離と不公平な結果をもたらす可能性があります。OCCは、その規制権限と clearing 所の機能を活用して、オプション条項の調整に介入します。これにより、オプションの経済価値が維持され、市場が秩序正しく公正に保たれます。この継続的な調整メカニズムは、全体的な市場の完全性を維持し、期権保有者が対象企業が変化した場合でも価値の連続性を確保する上で不可欠です。\nInteractive Brokers なぜ「SST 1」を要求するのか 証券会社が調整後権利シンボルを採用する慣例 Interactive Brokers (IB) は、主要な証券会社として、オプションのシンボルに関する業界標準を明確に遵守しています。そのドキュメントでは、「IBは『オプションシンボルイニシアティブ（OSI）フォーラム』(OSI) の形式で 21 文字のシンボルを使用する」ことを確認しています 8。このコミットメントは、オプションクリアリング機構 (OCC) によって確立された慣例に基づいて、オプションのシンボルを統合および処理することを意味します。\nIB は、顧客がその保有ポジションに影響を与える可能性のある会社行動を理解し、確認するための仕組みも提供しています。Trader Workstation (TWS) とメッセージセンターには、会社行動とそれらがポジションに与える影響を監視するためのツールが用意されています [^15]。\n元の株式シンボルに数字接尾辞（例： “1”）を追加して、調整後のオプションの権利を表すことは、業界内で一般的な慣行です。この手法は通常、OCC によって直接強制され、これらの契約を会社行動後に発行された未調整の対象となるオプションと区別するために使用されます 3。\n他の証券会社も同様の手法を採用しています。例えば、Robinhood は、「保有している株式オプションが逆分割の場合、… 株式コードに数字が付加されます。たとえば、ABC オプション契約を保有している場合、逆分割後、それは ABC1 として表示されます」と明示しています 4。また、Merrill Edge では、「シンボルの横に「A」（「調整済み」を示す）が表示され、シンボル自体には追加の数字が含まれており、それが調整を表します」と述べています [^13]。Questrade も「A」アイコンまたはその他の特殊な指示子について言及しています [^14]。\n「1」接尾辞は、調整後の契約を区別するための業界慣例 「SST1」記号が最も直接的かつ主要な理由は、OCC（オプション清算機関）による調整です。OCCの情報メモ#56689に詳述されているように、System1, Inc. における1株分割と10株反転株式分割の後、「期権記号：SST を SST1 に変更」と明示されています 3。これはIB内部特有の命名法ではなく、調整後の期権契約を識別するための標準化された業界慣例です。\nこの慣例は非常に重要であり、反転株式分割などの企業行為の後、未調整の期権シリーズが上市され、標的株で取引を開始する際に、これらの期権は元の記号（例えば「SST」）を使用し続けます。これらの新しい標準契約と、調整済み契約（その権利行使価値または対象株式に対する分割後の有効行使価値が変更されたもの）との混同を防ぐために、調整済みの契約には修正された記号（例えば「SST1」）が割り当てられます [^13]。\nしたがって、「SST1」記号は、期権契約の元の条項がOCCによってSystem1, Inc. の1株分割と10株反転株式分割に合わせて変更されたことを明確に示す識別子です。\nこの慣例が取引システムの透明性を維持し、混乱を防ぐ仕組み 独自のシンボルシステムがない場合、トレーダーは注文時に意図せず「SST」オプションを取引してしまう可能性があり、それが100株のストックスプリット後の標準的なSST契約を表していると誤認する可能性があります。実際には、これは以前の調整された契約であり、異なる数の株式（たとえば、有効な10倍のストックスプリット後のSST）または再評価された行使価格を表す可能性があります。\n「SST1」のような調整されたシンボルを使用することで、取引システム、 clearing所、およびすべての市場参加者がこれらの契約を正確に識別、価格設定、処理、および決済できるようにします。この精度は、注文ルーティング、価格設定、行使、および配分におけるエラーを防ぐために不可欠であり、重大な財務的差異と紛争につながる可能性があります。\nさらに、この慣例により、調整された（旧）オプション契約と新規に発行された標準的なオプション契約が同じ原資産株式上で同時に上場・取引され、それぞれの契約は独自のシンボルで識別されます。\n証券会社がこれらの調整後のシンボルをプラットフォームに統合する方法 Interactive Brokersなどの証券会社は、OCC（注文処理センター）からの強制的なシンボル変更を、Trader Workstation (TWS)を含む取引プラットフォームにシームレスに統合しています。企業行動が発生し、OCCが調整を行った際に、IBは顧客のポートフォリオとオプションチェーン表示に影響を受けるオプション契約のシンボルを更新します 8。\n基準株式自体は、引き続き元のシンボル（“SST”）で取引を継続しますが、すでに調整された既存のオプションポジションは、新しいシンボル（“SST1”）で表示されます。これらの特定の調整後の契約に関連する注文入力やクエリを行う際には、トレーダーは“SST1”という根シンボルを使用する必要があります。これは、ユーザーがIBに“SST 1”を送信する必要がある理由を説明しています。\n重要な観察点として、基準株式System1, Inc. は、引き続き元のシンボル “SST” で取引を継続しています 7。しかし、既存の調整されたオプション契約については、その基準根シンボルが“SST1”に変わります 3。これにより、微妙な状況が生じます。つまり、新規オプション（これらのオプションは、分割後の“SST”株式の上場時に基づいて取引される）を取引する場合、基準物は “SST” であり、既存の調整されたオプションを取引する場合は、オプションシンボル内の基準物が “SST1” になります。これは、トレーダーが混乱しやすい微妙かつ重要な違いです。\nこの現象は、オプション取引における顕著なオペレーション的複雑さを浮き彫りにしています。これは、単にOSI形式を理解するだけでなく、その範囲を超えています。動的な市場において、成功したオプション取引には、企業行動がオプション市場をどのように細分化するかについての継続的な警戒と深い理解が必要です。現在の株式コードを知るだけでは不十分です。トレーダーは、現在の基準物上の“標準”オプションと、その基準物がシンボル変更された“調整”オプションを区別する必要があります。これは、オプションチェーンの詳細、企業行動通知、および証券会社固有のガイダンスを注意深く確認することの重要性をさらに強調しています。\n調整後のオプションシンボル（例： “SST1”）の実施は、明らかに clearing 組織と証券会社の“オペレーション的必要性”です。これは、企業行動の複雑さを管理し、市場の整合性を維持し、正確な清算と決済を保証するための強力なメカニズムです 1。しかし、最終的なユーザーの視点からは、この変更は重要な混乱の原因となる可能性があります。ユーザーからの直接クエリが示すように。証券会社が“A”アイコンなどの視覚指示符 13 や、顧客ポートフォリオ内のシンボルを自動的に調整する 10 を使用して、この混乱を軽減しようと努めていますが、潜在的な複雑性は依然として存在します。\nこれは、堅牢な金融市場インフラストラクチャの技術的要件と、ユーザーフレンドリーインターフェースのニーズとの間の継続的な緊張とトレードオフを明らかにしています。 “SST1”慣例は、システム的に見ると効率的かつ必要ですが、個人トレーダーにその意味を理解する負担を強いる可能性があります。これは、市場参加者がこれらの複雑さを効果的かつ自信を持ってナビゲートするために、専門分析と詳細な教育レポートの持続的な価値を強調しています。\n取引者への影響とベストプラクティス 調整後のオプションの識別方法 記号接尾辞: 調整後のオプションを識別するための最も直接的かつ迅速な指標は、期権根記号に付加された数字接尾辞（例：「1」、「7」はミニオプションに使用され、その他の数字も使用されます）9です。例えば、System1, Inc. のオプションで「SST1」ではなく「SST」と表示されることは明確な信号となります。 取引プラットフォームの視覚的インジケーター: Merrill Edge や Questrade などの主要な取引プラットフォームには、特定の視覚的なヒントが含まれています。トレーダーは、期権チェーン、見積もりウィンドウ、またはポートフォリオビューで、期権記号の横に目立つ「A」アイコン（「調整済み」を示す）やその他の特殊なインジケーターを探すべきです[^13]。Interactive Brokers は、税務最適化ツールとメッセージセンターでもアイコン（例：「C」は会社行動を示す）を使用して、影響を受けたポジションを強調しています[^15]。 流動性の低下: 調整後のオプションの強力な実証的信号は、取引量と未決済契約量の顕著な減少です。同一シリーズ内の他の期権や、新規発行され、未調整の標的資産に基づく標準期権と比較して、調整後の期権は通常、流動性の急激な低下を経験します[^13]。このような活動の減少により、買値と売値のスプレッドが拡大する可能性があります。 行使価格の乖離: 調整後のオプションの行使価格は、「不適切」に見えたり、標的株期権チェーンの他の部分と一貫性がないように見えることがあります[^13]。さらに、同じ満期日と行使価格を持つコールオプションやプットオプションが複数存在する場合も、調整後のオプションと新規発行された標準期権が並存している可能性を示唆します[^13]。 価格異常: 期権の価格が標的株の現在の市場価格に対して異常に低いか「過大評価されている」（またはその逆、「信じられないほど良い」）場合、調査が必要です。これは調整によって内在価値や取引可能物が変化した可能性があるためです[^13]。 オプション清算会社 (OCC) 情報メモと証券会社の通知の参照重要性 オプション清算会社 (OCC) は、米国オプション契約の調整を決定し実施する最終的な権限を持つ機関[^13] です。彼らの「情報メモ」は、どの企業の行動変更に関する具体的な条項を理解するための公式かつ信頼できる情報源です3。これらのメモには、取引可能数量（例えば、各契約における株式数）、行使価格、および新しいオプション記号の変更など、重要な詳細が含まれています。\nInteractive Brokers などの証券会社は、顧客にとってポジションに影響を与える可能性のある、差し迫った企業の行動に関する法的義務と運用能力を有しており、その通知を顧客に提供する必要があります。これらの通知は、通常、顧客メッセージセンター、企業行動ツール、またはプラットフォームアラートを通じて入手可能です[^15]。これらは、証券会社がシステム内で調整をどのように処理するかについての基本的な情報を提供します。\n視覚的なヒントや企業の行動に対する一般的な理解だけに頼ることは不十分であり、高額な誤解につながる可能性があります。正確なポジション管理と取引決定を行うためには、具体的な調整条項（例えば、現金を代替する株式の分割、特定の取引可能数量の変更）を特定するために、これらの公式および証券会社固有の情報源を参照する必要があります。\n取引調整後方の注意点 流動性の著しい低下: 取引調整後方で最も顕著な影響は、流動性が著しく低下することです[^13]。これは通常、買い手と売り手の価格差が拡大し、公正な市場価格でポジションに参入または退出することがより困難になり、コストも高くなります。トレーダーは、その希望する注文規模で取引を受け入れる意思のあるカウンターパーティーを見つけることが難しくなる可能性があります。 評価複雑性の増加: 取引対象物が変化するため、調整後方の評価がより複雑になります。ブラック・ショールズモデルのような標準的なオプション価格決定モデルは、新しい対象物の数量や有効行使価格を考慮するために慎重な手動調整を行わない限り、直接適用できない場合があります。この複雑さは価格効率の低下につながり、トレーダーのリスクを高める可能性があります。 取引能力の制限: Robinhoodなどの一部のブローカープラットフォームでは、取引調整後方に制限が加えられることがあり、通常は「買い直しのみ」ポジションに限定されます4。これは、トレーダーが既存の調整後の契約を売却できるものの、新しいポジションを開設することが禁止されることを意味し、戦略の柔軟性を大幅に制限します。 行使/分配の曖昧性: 行使または分配時の正確な取引対象物を理解することは非常に重要です。OCC（オレゴン州金融機関監督局）の具体的な調整条項によると、調整後のオプションは、株式、株式、現金などの異なる数量の組み合わせで取引される場合や、完全に現金で取引される場合もあります[^13]。これらの条項を誤解すると、予期せぬ財務上の結果につながる可能性があります。 オプション取引家のためのアドバイス 情報収集を積極的に行う： 定期的な習慣を身につけ、金融ニュースメディアや証券会社の会社行動に関する情報を積極的に監視し、保有しているオプションのポジションに関連する対象株式に関する発表を確認してください。 公式文書を参照する： 会社行動が判明したら、直ちに関連する OCC 情報メモ（OCC ウェブサイトまたは証券会社のリソースを通じて入手可能）および証券会社の特定通知をすぐに参照してください。これらは、正確な調整条項を理解するための権威ある情報源です。 戦略を見直し、評価する： 調整があなたの特定のオプション契約のインピンバルエーション、ブレークイーブンポイント、そしてそれらがあなたの全体的な取引戦略における役割にどのように影響するかを慎重に評価してください。調整後の契約があなたの当初の投資理念と一致しているかどうかを確認してください。 ポジション管理を検討する： 調整後のオプションポジションは、その固有の複雑さと典型的な流動性の低下により、通常、あなたの取引目標に合致しない場合や流動性問題が耐えられない場合に、ポジションをクローズすることを推奨します。 新規契約に注意する： 一般的なベストプラクティスとして、調整後のオプション契約で新規ポジションを開設することは避けてください。代わりに、会社行動後に発行された標準オプションシリーズ（対象株式上）に注目し、これらのオプションは通常、より優れた流動性とより直接的な価格設定を提供します。 企業の行動がデリバティブ市場に与える影響は、企業の財務の固有の部分ですが、しばしば顕著な低効率をもたらします。調整後のオプションを作成すると、その流動性が低く、価格設定と取引が複雑になるため、特定の株式のオプション市場が断片化されます。この断片化により、全体的な市場効率が低下し、買い手と売り手のスプレッドが拡大し、価格発見が困難になります。\nユーザーのクエリは、標準 OSI 形式のオプション記号を認識することだけでは不十分であることを明確に示しています。 “SST”記号内の見かけ上わずかな“1”接尾辞（それを “SST1” にします）は、単なる表面的な変化ではありません。これは、契約条項、取引対象物、および市場動向（流動性、価格行動など）のシリーズの根本的な変更を示唆しています。したがって、トレーダーは表面的な記号の解釈に依存するのではなく、これらの変更背後にある理由を深く探求する必要があります。この積極的な調査は、単なる記号認識を超えて、効果的なリスク管理と取引実行不可欠な要素となります。\n結論 オプションコード“SST1G182500500.U”は、System1, Inc. (SST) の調整後オプション契約を明確に示しています。その重要な「SST1」根符号は、期貨決済会社 (OCC) が強制的に実行した公式の調整の結果として随意に指定されたものではなく、System1, Inc. が2025年6月12日に発効した1株分割10株逆反結合株式分割が必要であったことに起因します。\nこの企業行動は、既存オプション契約の有効な履行対象を根本的に変更しました。名義上の契約倍率は依然として100ですが、「SST1」標的符号は、各契約が現在、分割後のSST株の10株を表していることを示し、元の経済価値を維持します。\nInteractive Brokers（他の主要証券会社と同様に）、これらのOCC強制的な符号慣例に従っています。IBは「SST1」（または「SST 1」）標的物コードを要求することで、その取引システム内でこれらの調整後の契約を正確に識別、処理、表示し、潜在的な誤りを防ぎ、市場の完全性を維持します。ユーザー符号中の“G1825”と“.U”要素は、おそらく証券会社固有または遺留の満期日および内部識別子を示すものであり、「SST1」根符号の根本原因を変えるものではありません。\n真剣なオプショントレーダーにとって、オプション符号を完全に理解することは、特に企業行動の複雑な背景下では有益であるだけでなく、極めて重要です。企業行動は、未決済オプション契約の条項、履行対象、流動性特性を根本的に変更し、「調整後オプション」として独自の符号と取引行動を持つものに転換します。したがって、会社発表、勤勉に公式OCC情報メモを精査し、証券会社固有の符号慣例に注意することは、不可欠なベストプラクティスです。これらの措置は、オプション契約条項を正確に解釈し、リスクエクスポージャーを効果的に管理し、ダイナミックな市場環境において賢明な戦略的取引決定を下すために不可欠です。これらの重要な調整を見過ごすと、予期せぬ財務上の結果、運用複雑性、および重大な損失につながる可能性があります。\n結論 結論 Option Symbology Initiative - IBKR Guides、アクセス日時：2025年6月24日、https://www.ibkrguides.com/kb/en-us/article-972.htm\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHow to Read the Ticker Symbols for Stock Options - Investopedia、アクセス日時：2025年6月24日、https://www.investopedia.com/ask/answers/05/052505.asp\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSystem1, Inc. - Reverse Split Option Symbol: SST New Symbol: SST1 Date: 06/12/2025 - Options Clearing Corporation、アクセス日時：2025年6月24日、https://infomemo.theocc.com/infomemos?number=56689\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHow corporate actions affect your options | Robinhood、アクセス日時：2025年6月24日、https://robinhood.com/us/en/support/articles/how-corporate-actions-affect-your-options/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOption naming convention - Wikipedia、アクセス日時：2025年6月24日、https://en.wikipedia.org/wiki/Option_naming_convention\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSystem1 Class A Common Stock to Begin Trading on a Split-Adjusted Basis on June 12, 2025 - Business Wire、アクセス日時：2025年6月24日、https://www.businesswire.com/news/home/20250611797981/en/System1-Class-A-Common-Stock-to-Begin-Trading-on-a-Split-Adjusted-Basis-on-June-12-2025\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSystem1 (SST) Common Stock to Begin Trading on a Split-Adjusted Basis on June 12, 2025、アクセス日時：2025年6月24日、https://www.streetinsider.com/news/24925768\u0026amp;classic=1\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPrime Trade File Upload Instructions - IBKR Guides、アクセス日時：2025年6月24日、https://www.ibkrguides.com/traderworkstation/prime-trade-file-upload-instructions.htm\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOption symbol - Wikipedia、アクセス日時：2025年6月24日、https://en.wikipedia.org/wiki/Option_symbol\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-06-25","language":"ja","permalink":"https://ttf248.life/ja/p/spdr-sp-500-etf-trust-options-code-analysis-sst1g182500500u-why-is-the-underlying-stock-code-sst-1-instead-of-sst/","tags":["ib","ニューヨーク証券取引所（NYSE）/ 株式市場","オプション"],"title":"米国のオプションコードの解析：SST1G182500500.U 米国株式コードがSSTである理由","year":"2025"},{"categories":["メモ書き雑感"],"content":"AIは日常の開発ワークフローに浸透しており、最近投資の方向転換があり、エクイティとETFへのシフトとなりました。\nオープンソースプロジェクト\nプロジェクト記録 先週、暇つぶしにGitHubバッジを取得するためにIssueモジュールを使い始めました。以前コードを書く際に、AIの変更内容を記録する場所を探していました。個別にドキュメントを作成するのは散らかってしまいがちでした。しかし、Issueモジュールを使用することで、バグ、機能、改善などのラベルで区別し、記録が明確かつ効率的にできるようになりました。将来使わない可能性もありますが、記録を残しておくことは蓄積にもなります。 Issueリストの確認\nリリースノート リリース記録を記載します。最近の関連コミットを見つけ、すべてAI生成のコミット記録であるため、ウェブインターフェースから近隣のすべてのコミット記録をコピーし、それをAIに整理させることで、素晴らしいリリース記録を作成できます。 https://github.com/ttf248/comic-reader/releases/tag/v1.9.0\nアクティビティ GitHubの個人ページをきちんと整理したことで、見栄えが良くなり、結果的にコーディングへの積極性が高まりました。なぜなら、データ可視化によって、ある種のものは、非常に奇妙で、簡単なポジティブなフィードバックが、持続するためのモチベーションを生み出すことができるからです。\nTrae 有料で1ヶ月の体験版を購入しましたが、どう表現するか分かりません。VSCode内でもClaude4モデルを使用しており、バイト（ByteDance）のIDE体験の方が優れており、実戦的な効果も優れています。場合によっては、同じ問題に対してTraeがより良い回答を提示することもあります。今後、年額料金を購入しても良いでしょうか？現状の「適当に弄っている頻度」では、Traeの利用回数が足りなくなる可能性があります。杞憂（きゆう）して構いません。後で使い切ったら考えれば良いですし、バイトには他の有料プランがあり、より多くの呼び出し回数を購入できるかもしれません。 簡単な小さな問題に対しては、マイクロソフトのものを使用しており、GitHub Copilotや各モデルも利用可能です。 計画は頓挫しました。GitHub Copilotも呼び出し回数に制限が加えられました。618での制限に関する情報 現在の使用量を確認するにはこちらを参照してください。\n投資 結局、恒生通融通が開通して以来、香港株式市場で取引したことがなく、小米の新車発表を狙って少し買い増し、値上がりすれば売却し、値下がりすれば再び買い戻す、といった操作を何度か繰り返しましたが、新車の発売には至らず、株式でわずかな利益を得ることができました。\nこの頃、恒生通の資金の流れを眺めるのが無意味ではなく、美团は資金の純流入であり、それに便乗して投資し、成功裏に株主となりました。しかし、全体的な資金の流れを見過ごし、国内からの買い入れ資金はその一部に過ぎず、香港市場には多くの外国資本も存在することに気づきました。今回、実際に試してみることで、ブルーチップ株を長期保有し、徐々に収益を増やす方法が有効であることを確認できました。\nポジションのコントロールと損切りは、人の本性とは対照的なものです。焦らず、焦らず、急がないことが大切です。小米の新車が期待外れだった場合、どうやって売却するかという問題です。投資に対する認識はまだ十分ではなく、もっと本を読んだり、学んでいく必要があります。米連邦準備制度理事会（FRB）が利下げを示唆しないため、香港株式市場は一波の暴落し、建玉を入れるタイミングを遅らせることは適切ではありません。しかし、利下げというニュースが出た場合、香港株式市場は大暴騰することになります。これが投資であり、人間の本性を試すものです。 「常々口にする言葉：買うのは国の運だが、自分はそれを信じているとは言えない」\n上記の国運の信仰を抛却して、**もう一つ重要なのは注意（注意力）**です。長期的な投資をするのであれば、頻繁にチャートを見ることは意味がありません。毎朝10分、取引終了後に10分ほどを目視で確認する程度で十分です。最終的に期待できる収益率はどれくらいでしょうか？明確な損切りポイントも設定されていません。\n市場が暴落した際に、腾讯は依然として魅力的な投資対象となり、資金が集まりました。\n| 00700 | 腾讯控股 | 498.600 | 80.08億 |\n投資 コード 名称 最新価格 取引量 03690 美団-W 128.100 68.81億 投資 コード 名称 最新価格 取引量 09992 泡盛マット 247.200 57億 投資 コード 名称 最新価格 取引量 09988 アルバビバグループ-W 109.800 53.22億 投資 コード 名称 最新価格 取引量 01810 小米グループ-W 53.050 41.05億 ","date":"2025-06-19","language":"ja","permalink":"https://ttf248.life/ja/p/daily-musings/","tags":["ai","投資 (tōshi)","注意 (ちゅうい) / アテンション","国家運 (kokunō)","github"],"title":"日々のたわごと","year":"2025"},{"categories":["コンピューター"],"content":"既存のグループ内通信プロトコルでは、steady_clock をタイムスタンプとして使用し、個々のノードの処理時間（レイテンシー）を計算しています。特定の特殊な状況において、メッセージパケット自身のタイムスタンプを使用しましたが、その自身のもつタイムスタンプは他のマシンから取得されており、結果的に計算されたレイテンシーが異常に大きくなってしまいました。\n要約：Gemini 2.5 Pro は GPT-4 を完全に凌駕する可能性を秘めている。\n問題のトラブルシューティング 開始当初、出力層のタイムスタンプ計算の問題に注意していなかったので、すべてのサービスを停止して、ローカルアクセスし、ログを分析することにした。あるサービスがずっと停止しないことに気づき、継続的に業務データを送信しているため、手段がなく、通信ポートでパケットキャプチャをして機器の位置を特定した。\nsudo tcpdump -nni any -B 4096 -s 0 -w tmp.pcap port 13100 内部ネットワークの状況は複雑で、メッセージがプロキシを経由して転送されていたため、まずローカルサービスでポート13100のパケットをtcpdumpでキャプチャした。次にプロキシサーバーに切り替えて、ポート13100のパケットをキャプチャした。\n分析の結果、異常に時間がかかるリクエストはすべて深圳オフィスから来ていたため、問題のあるサービスを調査し、そのサービスは上海オフィスにデプロイされていたことがわかった。\nsteady_clock と system_clock の違い std::steady_clock と std::system_clock は、C++ で時間を扱うための主なクロックです。主な違いは以下のとおりです。\nstd::system_clock 「壁時計時間」 (Wall Clock Time) を表す: これは、システム全体で現実世界の時間を指します。これはオペレーティングシステムがディスプレイしている時間と一致しています。 調整可能: このクロックの時間（時刻）は、ユーザーまたはシステムサービス（例：NTP ネットワークタイムプロトコル）によって前後に調整できます。たとえば、手動でシステム時刻を変更したり、システムをタイムサーバーに同期させたりすると、system_clock の値が跳ね返ります。 時間間隔の測定には不向き: 向こう見えになる可能性があるため、2つの時間点間の時間差を計算するには、負の値や不正確な結果が得られる可能性があります。 主な用途: 現在の日付と時刻を取得し、現実世界の時間に対応する必要があるシナリオ（例：ログ記録用のタイムスタンプ）で使用されます。 std::steady_clock 単調増加クロック (Monotonic Clock): このクロックは、ある開始点から常に安定して前進し、決して減少することはありません。そのレートは固定されている場合もあれば、そうでない場合もあります（ただし通常は固定されています）。 調整不可 (Unadjustable): steady_clock はシステム時間の変更の影響を受けません。つまり、ユーザーがシステム時間を変更しても、それは引き続き安定して前進し続けます。 時間間隔の測定に最適 (Best for Measuring Time Intervals): その単調性により、コードの実行時間やタイムアウト待ちなどのシナリオにおける最適な選択肢となり、正確性を保証できます。 開始点は不確実 (Uncertain Epoch): 周期（epoch）の開始時間は通常システム起動時ですが、これは標準によって保証されているわけではありません。 異なるマシンで steady_clock は同じですか？ 違います。 steady_clock の値は、異なるマシン間では比較できません。さらに、同一マシンの異なる起動セッション間でも、その値は一貫しません。 なぜなら、それは単一のプログラム実行中に時間間隔を正確に測定することを目的としており、絶対的な時間点を表すためのものではないからです。その開始点（epoch）は未定義であり、異なるシステムや起動セッションではほぼ常に異なります。\nまとめ 特性 system_clock steady_clock 種類 壁時計 一致時計 まとめ 特性 system_clock steady_clock 調整可能か はい、前後に進める いいえ、前進のみ まとめ 特性 system_clock steady_clock 主な用途 現在の日付と時刻を取得 時間間隔の測定、タイムアウト処理など まとめ 特性 system_clock steady_clock 複数マシン/再起動での比較 可能 (同期後に) 不可能 まとめ 簡単に言うと：\n「今、何時ですか？」を知りたい場合は、system_clock を使用します。 「このコードは実行されてどれくらい時間がかかりましたか？」を知りたい場合は、steady_clock を使用します。 ","date":"2025-06-19","language":"ja","permalink":"https://ttf248.life/ja/p/cross-machine-computation-time-difference/","tags":["トラブルシューティング","c++","tcpdump"],"title":"マシン間計算の時間差 (Mashinkan tenkiho no jikanusa)","year":"2025"},{"categories":["コンピューター"],"content":"引き続きAIが勝手に文章を生成し、ローカル漫画ブラウザ を使用した。 終了時にホームページに戻る機能がないことが判明したので、問題を抽出し、AIに投げかけました。解決策はパン屑ナビゲーションを追加することです。\n面包屑ナビゲーションとは？ 面包屑ナビゲーション（Breadcrumb Navigation）は、一般的なユーザーインターフェースデザインパターンで、通常はWebサイトやアプリケーション内のユーザーが現在どこにいるかを理解し、上位階層またはホームページへの迅速な移動手段を提供するために使用されます。その名前は、童話「ハンセルとグレーテル」に登場する主人公たちが家路につく際にパンの破片（面包屑）を使ってマークしたことから来ています。\n実際のアプリケーションでは、面包屑ナビゲーションは通常、階層パスの形式で表示されます。例えば：\nホームページ \u0026gt; カテゴリー \u0026gt; サブカテゴリ \u0026gt; 現在のページ このナビゲーション方法は、ユーザーエクスペリエンスを向上させるだけでなく、ユーザーが迅速に位置を特定し移動するのに役立ちます。特に、階層構造が深いコンテンツ構造においては有効です。\nクロップドナビゲーション以外にどのようなナビゲーションソリューションがありますか？ クロップドナビゲーションは優れた選択肢ですが、さまざまなアプリケーションシナリオに応じて、他の一般的なナビゲーションソリューションもいくつかあります。\n戻るボタン（Back Button） 最もシンプルで直接的な解決策であり、通常はページの上部またはツールバーに配置されます。\n← 返回 または ⬅ Back 利点：シンプルで分かりやすく、ユーザーの認知コストが低い 欠点：上一階層のみに戻ることができるだけで、より上位階層への直接移動はできない ナビゲーションバー（Navigation Bar） ページの上部または側面に固定されたナビゲーションメニュー：\nホーム | カテゴリ | 設定 | ア propos 利点：常に表示され、任意の主要ページに直接移動できます。 欠点：画面スペースを占有し、モバイル端末では折りたたむ必要がある場合があります。 側欄（Sidebar） 通常在页面左侧或右侧显示層級構造：\n📁 ホーム ├── 📂 アニメ │ ├── 📖 海賊王 │ └── 📖 うちはイチャプラ └── 📂 設定 利点：明確に完全な構造を表示し、多層階層ナビゲーションをサポート 欠点：占有スペースが多い 浮動アクションボタン（Floating Action Button） 通常は、画面の特定の場所に固定された円形の浮動ボタンです。\n🏠 (右下に浮かぶ) 利点: レイアウトスペースを占有せず、いつでもアクセス可能 欠点: 機能が単一で、コンテンツを覆い隠す可能性がある ジェスチャーナビゲーション 手勢によるナビゲーションを実現します：\n右にスワイプで上一階に戻る ダブルタップでホームページに戻る メリット: 操作がスムーズで、モバイル端末の利用習慣に合っている デメリット: 学習コストが高い、発見性が低い 適切なナビゲーション方法の選択方法 ナビゲーション方法を選択する際には、以下の要素を考慮する必要があります。\nアプリケーションの種類: デスクトップアプリ、Webアプリ、モバイルアプリなど ユーザー層: 技術的な熟練度、使用習慣 コンテンツ階層: 階層の深さ、構造の複雑性 画面スペース: 利用可能なスペースのサイズ、レイアウト制限 使用頻度: ナビゲーション機能の使用頻度 ローカル漫画ブラウザのようなシナリオの場合、以下の組み合わせを推奨します。\n主要な方法: 階層ナビゲーション（明確なパス表示） 補助的な方法: ショートカットキー（効率向上）+ フloatするホームページボタン（起点への迅速な戻り） これにより、異なるユーザーの習慣を満たしつつ、あらゆるシーンで便利なナビゲーション体験を提供できます。\n","date":"2025-06-14","language":"ja","permalink":"https://ttf248.life/ja/p/breadcrumb-navigation/","tags":[],"title":"パンくずナビ","year":"2025"},{"categories":["コンピューター"],"content":"しばらくの間、スマホのデータを整理し、アルバムや微信のチャット履歴をPCにバックアップしています。スマホには必要なチャット記録だけを残します。\n以前はきちんと地形で、スマホとデスクトップPCが同じローカルネットワーク内にあるため、直接チャット記録をPCにバックアップできていましたが、今日は何らかのエラーでうまくいきませんでした。\n試した解決策 PCがWi-Fiに接続し、スマートフォンがWi-Fiに接続している。PCとスマートフォンは同じローカルネットワーク内にあるにも関わらず、認識できない。 スマートフォンでテザリングを有効にし、PCがスマートフォンでテザリングに接続しても認識できない。 解決策 デスクトップPCで接続している有線ネットワーク、スマートフォンは無線ネットワーク、WeChatのバックアップと復元時に、このローカルネットワークを認識できない。すでにテストを実施しており、デスクトップPCからスマートフォンのIPアドレスに正常にアクセスできる。\n解決策 腾讯的東西を思いつかなかったので、混元に聞いてみたら、案もなく出てきたものが役に立たなかった。手当たり次第で豆包に投げかけてみると、サプライズがあり、ローカル環境に仮想ネットワークや多重NIC環境がないかというヒントを与えてくれた。\nこれは当たっていた。デスクトップPCにはVMware、ZeroTier、Hyper-V、Docker Desktopなど、多くの仮想NICが存在し、また、ルーターに接続するメインのNICと別のマシンを構成する局所ネットワーク用の2.5G NICも搭載されていた。\nそこで、デスクトップPC上のすべての仮想NICと過剰な物理NICを無効化し、メインのNICのみを残して、再度バックアップを実行したところ、これで成功した。\n","date":"2025-06-13","language":"ja","permalink":"https://ttf248.life/ja/p/wechat-backup-tool-local-network-recognition-failed/","tags":["WeChat (微信)","バックアップ","ローカルエリアネットワーク (LAN)","トラブルシューティング"],"title":"WeChat バックアップツール ローカルネットワーク認識失敗","year":"2025"},{"categories":["AI霊感衝突坊"],"content":"ステーブルコインは、米国内および香港において合法的な地位を確立しています。資金がより効率的にグローバルに流動化される一方で、規制がない場合はグレーゾーンが存在するのは明らかです。まるでアメリカが薬物中毒者を管理するような状況です。\nステーブルコインとは、法定通貨（米ドル、港元など）や貴金属などに連動する暗号資産であり、その価値を安定させることを目的としています。主な種類は、法案担保型（USDT、USDCなど）、商品担保型（金などの貴金属で裏付けられたステーブルコイン）、アルゴリズム型（実物資産に依存せず、アルゴリズムによって価格を調整するタイプ）です([zh.wikipedia.org][1])。\n🛠️ なぜ安定通貨を法的に支援すべきなのか？ 1. 決済効率の向上とコスト削減 ステーブルコインは、即時かつ低コストなクロスボーダー決済サービスを提供し、特に銀行がカバーしていない地域において顕著な優位性があります。その決済速度が速く、手数料が安いため、国際貿易や送金などに対して実質的な価値があります([ft.com][2])。\n2. 米ドル・通貨の国際化を強化する 米国（アメリカ）の視点では、ステーブルコインの台頭が米債などの短期資産に対する需要を高め、ドルの地位を強化するとともに、金融イノベーションを促進する。また、欧州連合（EU）もこの機会にデジタルユーロの発行を加速している。\n3. 規制空白を補完し、リスクを回避する 過去のステーブルコインは、「影金融」の状態にあり、透明性が低く、市場の乱れが頻発し、マネーロンダリングや詐欺などのリスクも含まれていた。米国が提案したSTABLE ActおよびGENIUS Actは、明確な規制、資産の開示、資本/清算規則の設定を要求することで、金融安全と投資家の権利を保護することを目指している([morganlewis.com][3])。 香港では、2025年8月より《Stablecoins Ordinance》（安定仮想通貨法）が施行され、ステーブルコインの発行には金融管理局（HKMA）の許可が必要となり、資産の裏付け、引き出し、マネーロンダリング（AML/CFT）などの基準を満たす必要があり、許可を得ていない機関による広告宣伝は禁止されている([morganlewis.com][4])。\n💰 安定通貨会社はどのように利益を上げるのか？ 储备資産の利息収入 例えば、Circle の USDC 予約資産は主に短期米国債に保管されており、現在の金利水準から恩恵を受けており、2023年の収益が大幅に増加し、2025年には約5億ドル（ft.com)の利益が見込まれています。Tether の報告書によると、2024年上半期の収益は5億2000万ドルに達しています。 取引手数料と開発者ツール収入 鋳造・贖回費用以外にも、安定通貨プラットフォームはDeFi、ウォレット、企業顧客向けにAPI、SDK、決済ツールなどを提供することで、安定した収入源を得ています（marketwatch.com)。 金融拡張サービス 一部の安定通貨発行会社は、利息贖回、投資機能、企業決済などの付加価値製品を通じて利益を得ていますが、その結果、関連法案が「金利付き安定通貨」に対して制限を設ける可能性があります。 ✅ 概要 ステーブルコイン は、暗号資産の価格変動を補うための決済手段であり、有価証券やアルゴリズムによって価値を安定させる。 規制立法 は、そのコンプライアンスを促進し、消費者保護、金融システムの安定を図ると同時に、イノベーションと国際競争力を推進することを目的とする。 収益モデル は、有価証券の利息、手数料、付加価値サービスなどから主に構成される。 将来的に規制が適切であれば、ステーブルコインはグローバルな決済システムや中央銀行デジタル通貨（CBDC）との競争において重要な役割を果たす可能性がある。\nft.com reuters.com reuters.com markets.businessinsider.com ","date":"2025-06-12","language":"ja","permalink":"https://ttf248.life/ja/p/what-is-a-stablecoin/","tags":["ステーブルコイン","暗号通貨 (أنگyū tsūkō)","暗号資産","ブロックチェーン","フィンテック (FinTech)","経済学"],"title":"安定通貨とは何ですか？","year":"2025"},{"categories":["メモ書き雑感"],"content":"影石本日上市了，有个大学室友在里面干了很多年，主导某款产品的硬件研发。\n要说专业呢，影石主营业务是运动相机，和大学的本专业关联最多：自动化。自动化是个大专业，大二时候分小专业，要说大学室友，其实有两拨人，第一拨是大一室友，第二拨是大二室友，重新分小专业的时候，寝室也重新分了。我们这个小专业，涉及嵌入式、工程自动控制、电路设计，总的来说就是很杂。\n仕事概要 大学卒業後、4人がそれぞれ異なる方向へ進みましたが、全員が自動化を専攻していましたが、それぞれの選択は異なっていました。幸いなことに、寮の4人のうち3人が短期間ですが2年間深圳で再会し、私は深圳支社に配属されました。\n私自身 以前の記事にも書いたように、卒業後すぐに金融IT業界に入り、ずっと香港・米国株式方向を担当してきました。サイト上では、関連業務の内容更新が比較的少ないです。言い換えれば、業務内容は理解しており、ある程度把握していますが、十分に深く掘り下げていません。これまで取引に関連した内容を扱ってきましたが、その後、システム基幹通信の保守や監視システムの運用など、様々な雑務も担当してきました。\n室友A は最初は寧波でエアコン関連のハードウェア営業を担当し、その後深圳に移転しました。以前の仕事内容は不明ですが、深圳で一度転職し、中興通信で試用期間中にまだ終了していないうちに退職し、さまざまな不適合がありました。その後、影石で長年勤務し、ある種のスポーツカメラのハードウェア開発を主導しました。\n室友B は中間での経歴は不明ですが、現在は武漢で自動車関連のハードウェア開発を行っており、長年勤務しています。\n室友C は現在深圳の万科で不動産監視業務に従事しています。\n人生の選択 他の二人は後悔しているのか、よくわからない。連絡が少ないのは、深圳を出る際にそうだったからで、三人の変わり者たちが集まって武汉の友人にビデオ通話をしたことがあった。\n学生時代に寝室の仲間たちはいつも言っていた。「私は自動化に進むべきじゃなかった。コンピュータ系に進むべきだった。コードを書くのが好きだったから、ここではなぜコンピューターを選ばなかったのかを述べるのはやめておこう。以前の記事でこれらすべてについて書いている。」\n今になって考えると、お金は避けて通れない話題だ。深圳を出た当初は、住宅価格が高すぎるという理由で杭州に定住することを考えていたが、運命のいたずらかで杭州には定住せず、上海で働くことにした。これも幸運だったと言えるだろう。高値で買い占められた杭州の不動産を回避できたからだ。深圳を出る際に、国内の港元と米株の取引が最も活発だった時期だった。転職によって給料が上がったが、業界に関する十分な知識を持っていなかった：「国内の引流はグレーゾーンであり、政策リスクがある」。簡単に言うと、港元を通じた取引を避け、米株市場で取引を行ったのだ。「21年」に頭打ちされたことで、国内の引流が封鎖され、国内の証券会社は次々と転換し、米株市場のビジネスが大幅に縮小した。結局のところ、金融業界では合規性が不可欠なのだ。\n稿を書く理由に戻ると、影石が上場後に急騰し270%になった。会社から投資スキームが提供され、具体的な金額についてはここでは触れない。ただ言えるのは、室友Aが深圳で家を買うための頭金をほぼ用意できたということだ。私たちがこの投資スキームについて深く話し合ったことはなかったが、私も興味があった。彼のチャネルを通じて一部を投資することを考えていたが、関わる金額が大きすぎて耐えられなかった。結局のところ、室友はリスクが低い投資スキームを選択した。\n家を持てるだけの十分な資金がないから、大きな損失に耐えられない。耐えるなら、五十個ものお金を投入して試してみる価値があるのだろうか。このようなチャンスは、一生に一度しか得られないだろう。\n人生の選択 稼げていない十年について言えば、それは嘘だと言えるだろう。時折見せる、より多く稼ぐ人々に羨望するのは事実だ。少なくとも、自分たちがやりたいことをやってきた10年間は、喜びにあふれていた。職場での精神的な虐待（PUA）のようなものには遭遇しなかった。\n不動産投資を避けて通ることはできないだろう。頭金が3分の1も必要なのだから。どれだけ努力しても、業界の周期によって成功できるかどうかが決まるし、上向く流れに乗ることさえ重要ではない。それはチャンスを得て影石に参入する機会になるかもしれない。なぜなら、その時点では彼らの製品は海外をターゲットにしており、国内での知名度もまだ高くないからだ。港湾株式（港美株）のコミュニティで安易な生活を送ることは、学校で培った本質的なスキルをほぼ全て還元したことになるだろう。\n話を色々くちゃくちゃ言っても、若者は業界を理解することが難しく、更には10年間のキャリアプランを立てることができない。\n海外展開（プロダクト出海） 輸出貿易で利益を上げる場合、同じ製品が国内で1千元販売されるのに対し、海外では3千元、さらにはそれ以上も可能である。特に現在、国内における価格競争が激化している状況においては、その影響を考慮する必要がある。影石（シャドー・ストーン）や大疆（DJI）は、全景カメラという分野において既に動きを開始している。\n影石や大疆は、深圳の産業チェーンの優位性を活用するだけでなく、プロダクト出海も重要な要因となっている。国内市場における競争が激しく、価格競争が深刻であるのに対し、海外市場においては価格が高く、利益率を確保しやすい。初期段階での生存可能性を高める上で有利に働く。\n","date":"2025-06-11","language":"ja","permalink":"https://ttf248.life/ja/p/university-dormitory-four-people-ten-years-later-they-went-in-four-different-directions/","tags":["大学 (Daigaku)","寝室 (Nemishitsu)","海外展開 (かいがいてんか)","発展方向 (Hatten housou)","人生 (じんせい / jinsei)"],"title":"大学の寮で4人の人が住んでいました。10年後、それぞれ異なる方向に進んでいきました。","year":"2025"},{"categories":["コンピューター"],"content":"C++ Linux サービスでクラッシュが発生しました。そのサービスは、ある静的ライブラリを使用してコンパイルされています。 静的ライブラリが変更され、ヘッダーファイルにメンバー変数が追加され、静的なバイナリライブラリが再リリースされました。 サービスは新しいバイナリライブラリに依存しており、正常にコンパイル・実行されますがクラッシュします。クラッシュ箇所は明らかに問題ありません。以前のコンパイラアップグレード時の未定義動作や、信頼できないスタックトレースと類似しています。 サービスを再コンパイルする際に、依存するヘッダーファイルを更新することで、正常にビルドおよび実行できるようになりました。 これはなぜ発生したのか、どのようなコンピュータ知識が関係しているのかを詳しく説明します。メモリレイアウトに関連していると推測し、具体的な例を用いて詳細に説明します。\nこれは典型的な静的ライブラリのヘッダーファイルとバイナリライブラリの不一致によって引き起こされるクラッシュの問題です。確かにメモリレイアウトに関連しています。以下は詳細な説明です。\n問題分析 静的ライブラリのヘッダーファイルは、クラスの構造（メンバー変数やメソッドなど）を定義し、静的ライブラリのバイナリファイルには実装コードが含まれています。コンパイル時に、コンパイラはヘッダーファイル内のクラス定義に基づいてコードを生成します。このコードには、メモリレイアウトとアクセス方法も含まれます。ヘッダーファイルと静的ライブラリのバイナリファイルが一致しない場合、実行時の未定義動作を引き起こす可能性があります。\n重要な知識点 メモリレイアウト: C++ において、クラスのメンバ変数はヘッダーファイルで定義された内容に基づいてメモリ上に配置されます。 ヘッダーファイルにメンバ変数を追加すると、クラスのメモリレイアウトが変化します。例えば、新しいメンバ変数を追加すると、クラスのサイズ（sizeof）が増加したり、メンバ変数のオフセットが変わったりすることがあります。 二進数互換性: 静的ライブラリのバイナリファイルはヘッダーファイルに基づいて生成されます。サービスが古いヘッダーファイルを使用してコンパイルし、実行時に新しい静的ライブラリのバイナリファイルをリンクすると、サービスのコードは古いメモリレイアウトでクラスのメンバ変数にアクセスしようとし、静的ライブラリの実装コードは新しいメモリレイアウトで操作します。この不一致により、未定義動作が発生する可能性があります。 未定義動作: 未定義動作は、クラッシュ、誤ったスタック情報、またはプログラムの実行結果の異常などとして現れることがあります。これは、プログラムがメモリ上の不正なアドレスにアクセスしたり、初期化されていない領域にアクセスしたりする場合に発生します。 例による説明 以下の前提条件を仮定します。静的ライブラリのヘッダーファイルが以下のように定義されているとします。\nclass MyClass { public: int a; void func(); }; この静的ライブラリのバイナリファイルは、上記の定義に基づいてコンパイルされています。\nその後、ヘッダーファイルが以下のように変更されます。\nclass MyClass { public: int a; int b; // 新規メンバー変数 void func(); }; 新しい静的ライブラリのバイナリファイルは、変更されたヘッダーファイルに基づいてコンパイルされています。\nサービスがコンパイル時に依然として古いヘッダーファイルを使い続けると、以下の問題が発生する可能性があります。\nメモリレイアウトの一貫性のない問題： サービスは MyClass のサイズを sizeof(int) と想定し、静的ライブラリは sizeof(int) * 2 と想定します。 サービスが MyClass のメンバー変数にアクセスしようとすると、誤ったメモリアドレスにアクセスする可能性があります。 メソッド呼び出しの問題： 静的ライブラリの実装コードが新規のメンバー変数（例: b）に依存している場合で、サービスのコードが正しく b を初期化していない場合、実行時にクラッシュが発生する可能性があります。 解決策 ヘッダーファイルとバイナリファイルを一致させる: サービスをコンパイルする際に、静的ライブラリのバイナリファイルに一致するヘッダーファイルを使用するようにしてください。 バイナリファイルの互換性がない変更を避ける: クラスの定義を変更する必要がある場合は、直接メンバー変数を追加するのではなく、継承やその他の方法で実現することを検討してください。 依存するすべてのコンポーネントを再コンパイルする: 静的ライブラリが変更された場合、そのライブラリに依存するすべてのサービスを再コンパイルし、ヘッダーファイルとバイナリファイルを一致させるようにしてください。 結論 この問題の根本的な原因は、ヘッダーファイルとバイナリファイルの不一致によってメモリレイアウトが誤っていることである。C++ のコンパイラは、コンパイル時にヘッダーファイルに基づいてコードを生成し、実行時の動作はバイナリファイルに依存する。これらが一致しない場合、未定義の動作を引き起こす可能性がある。ヘッダーファイルとバイナリファイルの整合性を確保することで、同様の問題を防ぐことができる。\n","date":"2025-06-10","language":"ja","permalink":"https://ttf248.life/ja/p/memory-layout-and-binary-compatibility/","tags":["c++","トラブルシューティング","メモリ配置","バイナリ互換性","コンピュータアーキテクチャ"],"title":"メモリレイアウトとバイナリ互換性","year":"2025"},{"categories":["メモ書き雑感"],"content":"いくつかの断片的なアイデアやメモを記録しておき、後で個別の文書にしないようにする。\n友人たちの影響を受けて、私も同様の掲示板のようなページを作りたいと思い、Notesはすでに開発されており、しかしホームページの表示方法や過去データの処理など、細かい問題点がいくつかあり、そこで年度まとめを作成することで、同様の効果を得られると考え、その結果、AIが記事の一時滞在機能の開発につながった。\n2025年2月 DeepSeek が爆発的に人気を博す 日付：2025年2月7日 旧正月前夜、DeepSeek は一時的に話題となり、わずか数日間でソーシャルメディア上で広範な注目を集めた。このような突然の爆発的な人気は驚くべきことだっただけでなく、市場全体の連鎖反応を引き起こした。同時に、NVIDIA の株価は暴落し、多くの投資家がその見通しについて疑念を抱き、一部の機関はこの期間中に大規模なショート売りを行った。まるで全てが「綿密に計画された」状況を指しているかのようだった。\n春節檔電影中的政治元素剖析 日期：2025年2月10日\n好久沒去春節檔湊熱鬧，這次去了兩部電影，感覺有點不一樣。\n本文探討2025年春節檔電影的新變化，聚焦《唐人街探案1900》和《哪吒之魔童鬧海》。前者藉由1900年美國舊金山唐人街背景，展現華人受種族歧視與壓迫，映射社會政治環境；後者作為動畫電影，以豐富隱喻元素暗諷現實國際政治格局，例如玉虛宮類似五角大樓影射美國政治體系、天元鼎上美元符號象徵美元霸權、仙人玉牌像美國綠卡暗示身份等級、滅魂丹似生化武器暗指惡意行徑等。兩部電影帶來全新觀影體驗，引發對電影藝術與政治表達關係的思考。\nオンラインとオフラインでの映画チケットの価格差が想像を超える 日付：2025年2月11日 春節期間中、家族（7～8人）で映画を見に行きたいと考えていました。淘票票や猫眼でチケットを購入しようと思い、最初に見た価格は60元でした。手元に映画館のチャージカードがあり、前台で購入する必要があるため、そこで何か割引がないか聞いてみると、同じ回数でも前台で購入すると35元だったのです。この価格差は本当に驚きです。\n哪吒火爆出圈 日付：2025-02-15 春節檔哪吒の火爆出圈、 непонятное чувство национальной гордости、 похожее на предыдущие фильмы, такие как “战狼” (Чёрная пантера) и “爱国主题” (Патриот)、 несомненно, прогресс есть、 но это не настолько хорошо、 как ожидалось。 Как геймер, многие вещи выглядят слишком жирными、 и сцены боя имеют сильный сетевой стиль。 Уже много людей купили билеты в кино из-за успеха фильма “哪吒” (Ne Zha), но не пошли смотреть。\n2025年3月 トランプ政権による関税引き上げが貿易を揺るがす 日付：2025年3月4日 米国がメキシコおよびカナダの商品に25%の関税を実施し、北米貿易チェーンが激しく変動した。カナダは1550億加ドル相当の米国商品に対する報復措置を発表し、メキシスは中国との自由貿易協定締結を加速させ、リスクを緩和しようとした。この措置により、グローバルサプライチェーンはさらに多様化し、中国の鉄鋼企業は高級鋼材の国産代替ウィンドウ期を迎えた。\n2025年5月 医学教育の天宮と董袭莹事件のバタフライ効果 日付：2025年5月7日\n北京協和の“4+4”プロジェクト（4 年非医学本科 + 4 年医学博士）は、学際的な精英育成を主軸とし、2025年に董袭莹氏事件が発覚し、その家庭背景（医学/研究世帯）を利用してこのプロジェクトに参入したこと、学歴の曖昧さ、論文における剽窃疑惑などが暴露され、この模式が精英化選考と公平性との矛盾を露呈。学制の圧縮と規培（臨床研修）に関する論争も未解決である。\nある人はこれを天宮の一角だと語り、また別の人は階級的転落だと主張する。董小姐は医者になる必要はなく、単に両親が一生不如意を感じて、彼女を協和の4+4プロジェクトに進学させただけだという。\n特岗教師採用、急に減った 日付：2025-05-12\n2020年から2025年の江西省教師採用は、大幅な縮小傾向を示した：\n特岗教師採用人数が6,617人から32人に激減（99.5%の減少） 国編教師が11,324人から2,146人に減少（81.1%の減少） 主科（語数英）の割合は安定したが、総数は縮小。音体美などの学科の割合は上昇したが、絶対的な数は限られていた（例：2025年には各々が採用人数を2人とした）。\n政策面では「退一補一」編組の緊縮により、教師資源は職教および偏遠地域に傾斜し、伝統的な中小学校のポジションは大幅に縮小。2025年には一部学科で採用計画数がゼロとなった。\n貿易戦が突然一時停止 日付：2025年5月12日 貿易戦における関税の変動は、「段階的エスカレーション - 反制 - 交渉」というサイクルを呈现し、米中間の博弈は関税対峙からルール競争へと移行した。短期的な緩和により市場への圧力が軽減されたものの、長期的な不確実性は依然として存在し、WTOの裁決、サプライチェーンの調整、地政学的な変化がグローバル経済に与える継続的な影響を注視する必要がある。\n人々は、認識を超えた利益を得ることができず、今年貿易戦が発動したことで引き起こされた株式暴落は、現在までに失地の大部分を取り戻したが、その間には多くの個人投資家が埋葬されたことを知らないだろう。\n2025年6月 苏超火爆：群众性体育の経済的価値が顕在化 日付：2025年6月9日\n江蘇省都市サッカーリーグ（蘇超）第3回大会の平均観客数は1万人を突破し、徐州奥体中心での「楚漢之争」の一試合に22198人が集まり、中国の業余競技会記録を更新。抖音などのプラットフォームが短動画を通じて話題を作り出し、18万人以上が跨城消費（都市間消費）を行い、ホテル稼働率が20～30%向上。競技会の商業化モデルが革新され、江蘇銀行や今世缘などのスポンサーブランドの露出量が大幅に増加し、「スポーツ+文化観光」の効果を実証した。\n","date":"2025-06-08","language":"ja","permalink":"https://ttf248.life/ja/p/2025-major-events/","tags":["年間の主要出来事 (ねんかんのずいこうできごと)"],"title":"2025年のビッグイベント","year":"2025"},{"categories":["コンピューター"],"content":"先前的讨论继续，今天我们将探讨局域网的 IP 地址。上次为了同步代码，服务器配置了代理，服务器和家里的台式机通过网络连接了起来，在一个局域网内，代理程序部署在台式机上，服务器通过代理访问外网。同步代码速度很慢，所以就没再理会它，过了半个月，到服务器验证代码时，发现 Git 代码同步失败，出现了网络错误，也没太在意，仔细查看了报错信息。\nローカルリポジトリ fatal: unable to access \u0026lsquo;https://cnb.cool/ttf248/learn/cpp.git/’: Failed to connect to 10.243.52.68 port 7897 after 7 ms: Couldn’t connect to server\n開発環境 当然のことをいいやまぬかと、阿里云サービスとテンセントクラウド原生開発プラットフォームにネットワーク分離があると思い、コードの同期ができないというエラーメッセージをグループに投げかけていた。グループには大賢人がポート情報を見て、「これは代理IPかもしれません」と言い、すぐに誰かが「あなたはローカルネットワークで、ドメイン解決も正しくありません」と付け加えた。まるで脳が失忆しているかのように、自分が代理を設定したことを全く覚えていないのだ。 「ローカルネットワーク」という言葉を見ると、脳が正常に戻り、自分が代理を設定したことを思い出した。エラーが発生したのは自宅のデスクトップPCが接続されているローカルネットワークのアドレスだった。\n慣習的な思考：192.168.x.xはローカルネットワークアドレスである。\nコンピュータネットワークにおいて、「ローカルネットワーク（LAN）IPアドレス」とは、ローカルネットワーク内で使用されるプライベートIPアドレスを指します。これらのアドレスは公インターネットに直接公開されず、主に内部デバイス間の通信に使用されます。上記で言及した10.243.52.68と192.168.x.xはどちらもプライベートIPアドレス範囲に属しますが、異なるアドレス範囲であり、適用されるシナリオや計画ロジックも異なります。以下に詳細な比較を示します。\nプライベートIPアドレスの分類と範囲 RFC 1918 https://datatracker.ietf.org/doc/rfc1918/ に基づき、プライベートIPアドレスは主に3つのセグメントに分類され、それぞれ異なる規模の局域網で使用されます。 | 10.0.0.0/8 | 255.0.0.0 | 約1600万個 | 大規模企業、园区ネットワーク |\nプライベートIPアドレスの分類と範囲 アドレス段 サブネットマスク 利用可能なIP数 適用シナリオ 172.16.0.0/12 255.240.0.0 約100万個 中規模企業ネットワーク プライベートIPアドレスの分類と範囲 アドレス段 サブネットマスク 利用可能IP数 適用シナリオ 192.168.0.0/16 255.255.0.0 約6.5万個 小型局域網（家庭、オフィス） あなたの問題におけるIPアドレス解析： 10.243.52.68\nは 10.0.0.0/8 範囲に属し、大規模なプライベートネットワークの典型的なアドレスであり、企業向けローカルエリアネットワーク（LAN）または広域ネットワーク（WAN）（複数の支社間の内部ネットワークなど）で使用されることが多いです。 192.168.x.x\nは 192.168.0.0/16 範囲に属し、最も一般的な小型プライベートネットワークアドレスであり、家庭ルーターや小規模なオフィスなどのシナリオで使用されます。 両者の核心の違い アドレス空間のサイズ 10.0.0.0/8: アドレス範囲は 10.0.0.0 ~ 10.255.255.255 であり、16,777,216 個の利用可能なIPアドレス を含みます。 大規模なネットワーク（企業、学校、データセンターなど）に適しており、大量のIPアドレスが必要な場合に最適です。 192.168.0.0/16: アドレス範囲は 192.168.0.0 ~ 192.168.255.255 であり、65,536 個の利用可能なIPアドレス を含みます。 小規模なネットワーク（家庭など、通常数十台程度のデバイスがある場合）に適しています。 サブネット分割の柔軟性 10.0.0.0/8: アドレス空間が大きいため、サブネットマスクを用いて複数のサブネット（例：10.1.0.0/16、10.2.0.0/16 など）に分割し、大規模ネットワークの階層的管理とトラフィックの分離を容易にします。 192.168.0.0/16: 通常、デフォルトのサブネットマスク 255.255.0.0 を使用し、サブネット分割の必要性は少ないため、シンプルなフラットなネットワーク構造に適しています。 一般的な利用シーン 10.xxx.xxx.xxx: 企業内部ネットワーク: 例えば、複数の海外拠点を経由する多国籍企業がVPNで接続し、各拠点が独立したサブネット（例：10.1.1.0/24、10.1.2.0/24）を割り当てられる。 クラウドサービスプロバイダー内部ネットワーク: AWSや阿里云などのプライベートクラウド環境でよく使用される 10. 段アドレス。 産業制御ネットワーク: 一部の産業機器はデフォルトで 10. 段アドレスを使用する。 192.168.xxx.xxx: 家庭/小規模オフィス: ルーターがデフォルトで割り当てるアドレス（例：192.168.1.1 または 192.168.0.1）。 小規模局域網の共有: 例えば、ルーターを使用して構築されたWiFiネットワークで、デバイス数は通常200台以下。 パブリックネットワークとの分離性 両者ともプライベートアドレスであり、直接パブリックネットワークにアクセスすることができないため、NAT（ネットワークアドレス変換）またはVPNを介して接続する必要がある。実際使用においては：\n10. ブロックは、より複雑なネットワークアーキテクチャが必要なシナリオ（マルチサブネット、VLAN分割など）で使用される。 192.168. ブロックは、アドレス空間が小さいため、プラグアンドプレイに適したシンプルなネットワークに最適である。 なぜ 10. で始まるアドレスが表示されるのか？ ローカルネットワークで 10.243.52.68 のようなアドレスを見つけた場合、考えられる原因は以下のとおりです。\nエンタープライズ級のネットワーク環境： 会社や組織が 10. 段を内部IPアドレスとして使用し、部門やデバイス（サーバー、PCなど）を区別するために利用している可能性があります。\n仮想マシンまたはコンテナネットワーク： クラウドプラットフォーム（VMware、Docker など）で、仮想マシンに IP アドレスを割り当てる際に 10. 段がデフォルトで使用されることがあります。\n特殊なデバイスのデフォルト設定： 一部のネットワーク機器（産業用スイッチ、ファイアウォールなど）は、工場出荷時に 10. 段のアドレスをデフォルトで設定している場合があります。\nまとめ：どのように選択するか？ 小型ネットワーク（家庭/オフィス）: 192.168.x.x を優先的に使用し、設定が簡単で十分な性能を発揮します。 中規模・大規模ネットワーク（企業/园区）: 10.x.x.x または 172.16.x.x を使用し、サブネットの分割や多数のデバイス管理を容易にします。 両者は本質的にローカルエリアネットワークアドレスであり、アドレス空間と適用シナリオの違いのみがあります。技術的な優劣はありません。具体的なネットワーク計画の要件によって選択します。\n","date":"2025-06-06","language":"ja","permalink":"https://ttf248.life/ja/p/102435268-also-belongs-to-the-local-area-network/","tags":["ip","ネットワーク","ローカルエリアネットワーク (LAN)","コンピュータネットワーク"],"title":"10.243.52.68 はローカルエリアネットワークにも属します。","year":"2025"},{"categories":["コンピューター"],"content":"国内へのGitHubアクセス速度が遅い場合、プロキシの設定で加速できます。また、国内のホスティングプラットフォーム（例えば、码云、Codingなど）を利用する方法もあります。対応するビルドパイプラインを設定し、コードをGitHubに同期します。\n長年codingを使用しており、インターフェースはシンプルで、最近公告を発表し、無料版がサポートされなくなりました。そのため、騰訊の新しいプラットフォームcnbへの移行が必要になります。それに伴い、アリババのホスティングプラットフォーム全体のインターフェースデザインは、非常に使いにくいです。\nhttps://cnb.cool/ttf248\nリポジトリの移行 cnb公式サイトで、GitHubからcnbへのコードをまとめて移行するためのツールが提供されています。 https://docs.cnb.cool/zh/guide/migration-tools.html\nGit 代理設定 加速設定を行わない場合、ツールの同期が遅いため、コードはまずローカルに同期され、その後リモートリポジトリにアップロードされます。\nGit は以下のコマンドを使用して HTTP 代理を個別に構成でき、システム全体のグローバル設定に影響を与えません。\n# HTTP 代理を設定 git config --global http.proxy http://proxy.example.com:8080 # HTTPS 代理を設定 git config --global https.proxy http://proxy.example.com:8080 # オプション：特定のドメイン名に対してのみ代理を設定 git config --global http.https://github.com.proxy http://proxy.example.com:8080 代理設定を解除するには、以下のコマンドを使用します。\ngit config --global --unset http.proxy git config --global --unset https.proxy 現在の代理設定を確認するには、以下のコマンドを使用します。\ngit config --global --get http.proxy git config --global --get https.proxy ","date":"2025-06-06","language":"ja","permalink":"https://ttf248.life/ja/p/git-single-configuration-proxy/","tags":["git"],"title":"Git単独でプロキシを設定する","year":"2025"},{"categories":["コンピューター"],"content":"ビジネスシステムは、サマリータイプの監視指標を設計し、平均処理時間（request_duration_milliseconds_sum / request_duration_milliseconds_count）を計算していました。\nデータを確認したところ、あるインターフェースの平均処理時間が非常に高くなっていることが判明しました。時系列グラフを見ると、平均処理時間が突然増加しており、それは単一のリクエストの処理時間が長かったために引き起こされたもので、平均値を押し上げている状態でした。具体的にいつ発生したリクエストを特定したいのですが、その期間内のリクエスト数が少なく、結果データが常に空になってしまいます。\nFAQ (よくある質問) / 質疑応答 (しぎおうどう応) ✅ なぜ _sum と _count にデータがあるのか _sum と _count は Summary 型のコア指標であり、Prometheus は常にこれらの値を収集して記録します。 どちらも累積型のカウンターであるため、rate() または increase() を使用するのに適しています。 リクエスト遅延がどのように変化しても、リクエストが存在すれば必ず _sum と _count のデータがあります。 ❌ {quantile=\u0026quot;0.99\u0026quot;} が時系列グラフで表示されない理由 Summary にも quantile=\u0026ldquo;0.99\u0026rdquo; を設定していても、この時間系列が存在しないか欠損している可能性があります： 指標は確実に設定されており、データが期限切れでもありません。📉 リクエスト量が少ないため、quantile を計算できません。スライディングウィンドウメカニズムにより、この期間を過ぎると統計範囲に再含まれなくなります。 分位数（例えば p99）はサンプリング統計によって計算されます：\n1～2 件程度のリクエストしかない場合、p99 の計算は不安定で代表的な意味を持たない可能性があります。 Prometheus クライアント SDK は、この quantile 時間系列を公開しないように選択します（誤解を避けるため）。 その結果、_sum、_count が正常に累積されますが、quantile=\u0026quot;0.99\u0026quot; にデータが存在しません。 ヒストグラムとサマリーの違い ヒストグラム 仕組み: ヒストグラムは、データをビン（バケット）に分割し、各ビンに収まっているサンプルの数を記録します。 例えば、定義したビンが [10ms, 50ms, 100ms, 500ms, 1s] の場合、各リクエストのレイテンシは対応するビンに割り当てられます。 利点: Prometheus で複数のインスタンス（例えば、複数のサービスノードのリクエストレイテンシ分布）からのデータを集計できます。 分位数（P50、P95、P99 など）を計算し、レイテンシの分布を観察するのに適しています。 PromQL を使用して、動的に分位数を計算するための柔軟なクエリ機能を提供します。 欠点: ビンの範囲を事前に定義する必要があり、選択が不適切だとデータ分布が均一にならない可能性があります（例えば、すべてのリクエストが 1 つのビンに集中する）。 ビンの数が多いほど、ストレージと計算のオーバーヘッドが増加します。 適用シナリオ: 複数のインスタンスからのデータを集計する必要がある場合。 分位数を動的に調整したり、レイテンシ分布を分析したりする場合。 概要 仕組み: Summary はクライアント側でパーセンタイル（P50、P95、P99 など）を直接計算し、その結果を Prometheus に報告します。 また、サンプル全体の数と合計も記録し、平均値を計算するために使用します。 利点: プレ定義されたバケットは不要で、直接パーセンタイル結果を提供します。 単一インスタンスでの正確なパーセンタイル計算に適しています。 欠点: パーセンタイルの計算はクライアント側で行われるため、Prometheus で複数のインスタンスのデータを集計できません。 パーセンタイルを調整（例：P95 から P99 に変更）するには、コードを変更して再デプロイする必要があります。 適用シナリオ: 単一インスタンスでの監視であり、パーセンタイルに対する正確性が高い場合。 複数のインスタンスのデータを集計する必要がない場合。 特性 ヒストグラム サマリー 分位数計算 プロメテウス内で動的に計算 顧客側で直接計算 特性 ヒストグラム サマリー 多インスタンス集約 対応 非対応 主な違いの比較 特性 ヒストグラム サマリー バケツの定義 事前に定義する必要がある 不要 主な違いの比較 特性 ヒストグラム サマリー ストレージコスト 桶の数に依存 固定コスト 特性 ヒストグラム サマリー 柔軟性 高 (ビンの幅を動的に調整可能) 低 (コードを変更してビンの幅を調整する必要がある) 結論 複数のインスタンスのデータを集約したり、分位数を柔軟に調整する必要がある場合は、ヒストグラムを選択してください。 単一インスタンスの正確な分位数が必要で、分位数が固定されている場合は、サマリーを選択してください。 あなたのシナリオでは、サービスが分散しているため、ヒストグラムを使用することを推奨します。これにより、Prometheus ですべてのインスタンスのデータを集約し、動的に分位数と経過時間分布を計算できます。 スライディングウィンドウの概念とそのヒストグラムおよびサマリーとの関係 スライディングウィンドウの概念 スライディングウィンドウは、時間ウィンドウメカニズムであり、一定期間内のデータ変化を統計するために使用されます。それは、継続的に移動する時間範囲を通して、システムのリアルタイム状態を動的に反映します。スライディングウィンドウの特徴は以下のとおりです。\n固定時間範囲: ウィンドウの長さは固定されており、例えば最近1分、5分などがあります。 リアルタイム更新: 時間経過とともに、ウィンドウがスライドし、古いデータがウィンドウから削除され、新しいデータがウィンドウに追加されます。 一般的な用途: リアルタイム指標（リクエストレート、平均値、パーセンタイルなど）を計算するために使用されます。 Prometheusでは、スライディングウィンドウは通常、クエリ関数（rate()、avg_over_time()など）によって実装されます。\nスライディングウィンドウとヒストグラムの関係 ヒストグラムのデータ構造: ヒストグラムは、サンプルデータをビンに分割し、各ビンのカウントを記録します。Prometheus は、これらのカウント値を周期的にキャプチャします。 スライディングウィンドウの実装: Prometheus でヒストグラムのデータに対してスライディングウィンドウを適用するには、クエリ文を使用できます。例えば： rate(http_request_duration_seconds_bucket[5m]): 過去 5 分間の各ビンのリクエストレートを計算します。 histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])): 過去 5 分間の P95 分位数を計算します。 利点: スライディングウィンドウは、最近の時間の要求時間分布を動的に反映できます。 ヒストグラムのビニングメカニズムとスライディングウィンドウを組み合わせることで、効率的に分位数や分布を計算できます。 スライディングウィンドウとSummaryの関係 Summaryのデータ構造: Summaryはクライアント側でパーセンタイルを直接計算し、Prometheusに送信します。また、サンプル総数と合計も記録します。 スライディングウィンドウの実装: Prometheusでは、Query文を使用してSummaryのデータをスライディングウィンドウ化できます。例えば： rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m]): 過去5分間の平均リクエスト時間計算します。 制限: Summaryのパーセンタイルはクライアント側で計算されるため、Prometheus側で再計算できません。したがって、スライディングウィンドウによるパーセンタイルのサポートは限定的です。 複数のインスタンスのデータを集計する必要がある場合、スライディングウィンドウはSummaryのパーセンタイルに直接作用しません。 スライディングウィンドウの適用場面 リアルタイム監視: スライディングウィンドウは、システムのリアルタイムな状態を監視するのに適しています。例えば、最近1分間のリクエストレートやレイテンシ分布などです。 異常検知: スライディングウィンドウを使用することで、短期間での異常事象（例えば、リクエストのレイテンシが急増するなど）を迅速に検出できます。 動的分析: スライディングウィンドウは、システムの変化トレンドを動的に反映し、静的なグローバル統計とは異なります。 概要 ヒストグラム とスライディングウィンドウを組み合わせることで、分位数（例：P95、P99）とリクエストの経過時間分布を動的に計算でき、分散システムでの監視に適しています。 Summary とスライディングウィンドウを組み合わせることで、平均値などの単純な指標を計算できますが、分位数の柔軟性に欠け、多インスタンスアグリゲーションもサポートしていません。 あなたのシナリオでは、極端なリクエストの経過時間（例：P99）と大部分のリクエストの平均値を監視する必要があるため、ヒストグラム を使用し、スライディングウィンドウを組み合わせてシステムのパフォーマンスを動的に分析することをお勧めします。 ","date":"2025-06-04","language":"ja","permalink":"https://ttf248.life/ja/p/prometheus-monitoring-system-histogram-and-summary/","tags":["prometheus","histogram","summary"],"title":"Prometheus監視システムにおけるヒストグラムとサマリー","year":"2025"},{"categories":["コンピューター"],"content":"文化伝播：意識形態的な影響、潜移漫歩。 AIプログラミング：ソフトウェア設計を行わないため、手戻りが多くなる。\n文化翻訳 当初のプロジェクトでは、英語、日本語、韓国語という3つの言語のみをサポートしていました。その後、「結局AI翻訳だから、色々な言語に対応した方が良いのではないか」と考え、フランス語、ロシア語、ヒンディー語を追加しました。その頃は問題に気づかず、プログラムが翻訳を実行する際に、過去のコードの問題により翻訳形式が正しくなく、保存された文章を再翻訳する必要がありました。\n統計的な時間経過の警告が表示され、すべての翻訳が完了するまでに約20時間がかかりました。これは、ローカルでデプロイされている大規模なモデルであるためです。不要な言語をいくつか削除し、翻訳時間を短縮することを考えました。フランス語、ロシア語、ヒンディー語を削除しました。その時、何かがおかしいことに気づきました。なぜ当初選択した言語（日本語、韓国語）が、私の選択になっているのでしょうか？\n世界人口の分布に基づいて見ると、これらの言語のユーザー層はそれほど多くありません。特に韓国語は、世界の利用人数は約8000万人に過ぎません。日本語はわずかに多い約1億2000万人です。一方、フランス語、ロシア語、ヒンディー語の利用人数はすべて1億人以上でした。\nその時、言語のユーザー層が、言語の使用人数によるものではなく、文化翻訳の影響によるものであることに気づきました。韓国と日本の文化は世界的に広範な影響力を持っており、特にアジア地域で顕著です。K-pop、アニメ、映画などの文化製品は大量のファンを引き付け、これらのファンは自然と関連する言語にも興味を持つようになりました。\nプロジェクトの成長を振り返ると、幼い頃によく日本のアニメや漫画を見ていましたし、大人になった今では多くの韓国映画やドラマを見ました。そのため、プロジェクトの設定時の初期言語を選択する際に、無意識のうちにこれらの馴染みのある言語を選択してしまいました。\nソフトウェア設計とAIプログラミング 翻訳助手は当初、単なるシンプルなツールに過ぎなかったが、Claude4のコーディング能力を体験してから徐々に機能が拡張され、文章翻訳、タグ翻訳などのモジュールが追加された。機能が増加するにつれて、コードの複雑さもそれに伴って上昇した。AIがコードをリファクタリングしてディレクトリ構造をより明確にしたことは確かだが、新機能の拡張やバグ修正時には、AI生成されたコードには繰り返し問題が発生することがある。\nAIはコード生成において、全体的な構造と設計理念に対する理解に欠けている。既存のコードに基づいて修正や拡張を行うことが多く、既存モジュールの有効な再利用をできていないため、コード冗長性が生じることがある。毎回、重複コードを手動で削除する必要があり、これは無意識のうちに開発コストを増加させている。\nさらに、AI生成されたコードは文法的に正しくても、論理と設計において問題がある場合がある。例えば、別のプロジェクトでプロンプトをわずかに調整しただけで、生成されるウェブページの構造が完全に異なり、一貫性がない。これは初期段階における合理的な設計の欠如、機能の追加が随意な積み重ねによるものであり、コード構造が混乱していることを反映している。\nこれはまた、ソフトウェアエンジニアリングの核心的な経験は依然として無視できないことを私たちに思い出させる。適切な設計は返工を減らすだけでなく、コードの保守性と拡張性を向上させることができる。AIは強力なツールであるものの、システム設計に対する人間の深い理解と計画を代替することはできない。\n","date":"2025-06-02","language":"ja","permalink":"https://ttf248.life/ja/p/blog-translation-project-musings-cultural-transmission-ai-programming/","tags":["ai","プログラミング","翻訳 (Hon'yaku)","文化伝播 (Bunka zen'ho)","ブログ"],"title":"ブログ翻訳プロジェクトの雑感：文化伝達、AIプログラミング","year":"2025"},{"categories":["コンピューター"],"content":"ブログ翻訳プロジェクトは当初、複雑に設計されていた——まずMarkdown形式を解析し、プレースホルダーでコンテンツを保護し、最後に大規模言語モデルに送信する仕組みだった。これは完全に無駄であり、大規模言語モデル自体がMarkdownの文法を認識する能力を備えており、元のコンテンツを直接処理し、翻訳時にフォーマットを維持することができたからだ。\n私たちの仕事は、コードのデバッグから、大規模言語モデルのプロンプトのデバッグへと変わった。 モデル：google/gemma-3-4b ハードウェア：Nvidia 3060 12GB そう、思考しないモデルを選んだ。思考するモデルは翻訳タスクを実行する際に効率が低く、4Bパラメータと12Bパラメータの効果を比較したところ、翻訳タスクにおいてはgemma3の4Bパラメータで十分だった。12Bパラメータは翻訳タスクにおいて明確な利点を持っていなかった。 12Bパラメータの速度：11.32 tok/sec、4Bパラメータの速度：75.21 tok/sec。\n背景説明 システムに様々な条件制限を加えても、出力される翻訳結果には依然として問題が発生することがありました。具体的には、フォーマットの保護が不十分であったり、過剰な説明文が含まれていたりしました。役割定義時には、Markdown形式を保護し、翻訳結果のみを出力することを明示していたにも関わらず、最終的な翻訳は不安定でした。\nその時、以前漫画翻訳プロジェクトで大言語モデルを活用した経験が思い出されました。その時の翻訳精度は、私のものより良かったようです。コードやリクエストデータを確認したところ、漫画翻訳プロジェクトでは、毎回リクエストにコンテキスト（文脈）を付与していました。現在の翻訳内容に加え、過去の翻訳内容もまとめて送信していたのです。\nこのメリットは何でしょうか？前後の翻訳の一貫性を高めるだけでなく、出力フォーマットの安定性を確保することにもつながったと考えられます。\n履歴対話の重要性 AI 大規模モデル（GPT シリーズ、Claude、Gemini など）の普及に伴い、ますます多くの企業や開発者が API を通じてこれらのモデルにアクセスし、インテリジェントな顧客サポート、コンテンツ生成、コードアシスタントなどのアプリケーションを構築しています。しかし、多くの方は API への初期導入時に共通の問題に直面します：モデル出力が不整合で文脈理解が欠如しており、場合によっては質問の意図を誤解してしまう。\nこの現象を引き起こす主要な原因の一つは——API リクエスト中に履歴対話の内容を含めないことです。\n履歴対話とは？ 履歴対話とは、一度の会話セッションにおいて、モデルとユーザー間の過去のやり取りの記録を指します。OpenAI の Chat Completions API（など、多くの大規模言語モデル API）では、開発者がリクエスト内で完全な messages 配列を作成し、過去の会話をユーザーとアシスタントのメッセージが交互に並んだ形式で渡す必要があります。\n例文 { \u0026#34;model\u0026#34;: \u0026#34;gpt-4\u0026#34;, \u0026#34;messages\u0026#34;: [ {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;退職の手紙を書いてください\u0026#34;}, {\u0026#34;role\u0026#34;: \u0026#34;assistant\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;かしこまりました。退職理由は何を書くようにしますか？\u0026#34;}, {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;個人的なキャリアの追求をしたいと考えていると述べる\u0026#34;} ] } もし最後の文だけを送った場合：\n{\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;個人的なキャリアの追求をしたいと考えていると述べる\u0026#34;} モデルは退職の手紙だと全く認識できず、文脈が理解されないため、出力品質は著しく低下します。\n歴史対話がなぜ重要なのか？ 1. 文脈の構築と一貫性の向上 AIモデルは本質的に「コンテキスト駆動型」であり、過去の出来事を記憶することはできません。除非你明示的に伝えるのです。対話履歴を渡すことで、モデルはあなたの意図や話題の背景をより良く理解し、期待される出力を生成できます。\n2. 誤解の低減 もしあなたがモデルに複数のステップで指示を実行させたい場合（例：文章作成、要約、コードデバッグ）、過去の履歴はモデルが徐々に理解を深め、途中で「逸脱」したり、重要な点を失ったりするのを防ぐのに役立ちます。\n3. 実際の人間のような対話行動のシミュレーション 実用例として、カスタマーサポートシステム、教育アシスタント、健康相談などにおいて、ユーザーの質問は通常、段階的に展開され、一度に明確な表現で表明されることはありません。会話履歴を保持することで、AIが「記憶力のあるアシスタント」のように振る舞うことができます。\nAPI 中における会話履歴の正しい追加方法 OpenAI の API を例に、以下の構造に従うことを推奨します。\nmessages = [ {\u0026#34;role\u0026#34;: \u0026#34;system\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;あなたは専門的な法律アシスタントです\u0026#34;}, {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;契約書の有効条件とは何ですか？\u0026#34;}, {\u0026#34;role\u0026#34;: \u0026#34;assistant\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;契約書が有効であるためには、以下の条件を満たす必要があります：……\u0026#34;}, {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;口頭での合意は有効ですか？\u0026#34;} ] response = openai.ChatCompletion.create( model=\u0026#34;gpt-4\u0026#34;, messages=messages ) 注意点：\nsystem メッセージを使用してモデルの動作とアイデンティティを設定します。 最新の数回の重要な会話のみを保持し、毎回すべての履歴を送信する必要はありません（トークン制限を超えないように）。 長いセッションでは、早期のコンテンツを切り捨てて、コア情報を要約し、トークンの消費を制御します。 実践的推奨事項 対話状態管理: バックエンドは、各ユーザーのセッション履歴（例: Redis、データベース）を記録するためのキャッシュメカニズムを設計する必要があります。 長さ制限: OpenAI GPT-4 のコンテキスト長は 128k tokens であり、Claude 3 は 200k～1M पर्यंत可能です。適切なトリミングが必要です。 動的履歴の要約: 履歴が長すぎる場合は、モデルを使用して古い会話を要約し、その結果を対話コンテキストに追加します。 まとめ AI 大規模モデルの能力は強力ですが、開発者に十分なコンテキスト情報を「与える」必要があります。API リクエストに過去の会話を追加することで、モデル出力の品質と一貫性を大幅に向上させるだけでなく、ユーザーエクスペリエンスをより自然で現実的な対話に近づけることができます。AI 顧客サービス、ライティングアシスタント、プログラミングアシスタント、教育アプリケーションなど、どのような分野でも無視できない最適化テクニックです。\n","date":"2025-06-02","language":"ja","permalink":"https://ttf248.life/ja/p/blog-translation-project-musings-historical-conversations/","tags":["ai","大規模モデル","ブログ"],"title":"ブログ翻訳プロジェクトの雑感：歴史対話","year":"2025"},{"categories":["コンピューター"],"content":"Go言語プロジェクトにおいて、staticcheck を使用して未使用関数を検出することは、効率的な静的解析手法です。\n1. staticcheck のインストール 以下のコマンドを実行して、Go (バージョン 1.16+) と staticcheck をインストールしてください。\ngo install honnef.co/go/tools/cmd/staticcheck@latest 2. 基本用法：未使用関数の検索 プロジェクトのルートディレクトリで以下のコマンドを実行します。\nstaticcheck ./... 主要チェックルール:\nU1000: 未使用関数、メソッド、変数、または型を検出します。 U1001: 未使用パラメータを検出します。 3. 特定のチェックルールをフィルタリングする 未使用関数のみをチェックする場合、ルールを指定できます。\nstaticcheck -checks=U1000 ./... 4. 出力形式 デフォルトの出力形式は、{path}:{line}:{column}: {message} の形式です。例：\nmain.go:10:2: func UnusedFunction は未使用です (U1000) 5. 設定ファイル (オプション) プロジェクトのルートディレクトリに .staticcheck.conf ファイルを作成し、カスタムチェックルールを定義します：\n{ \u0026#34;checks\u0026#34;: [\u0026#34;U1000\u0026#34;, \u0026#34;-ST1000\u0026#34;] // U1000 を有効にし、ST1000 を無効にする (文字列フォーマット規則) } 6. Visual Studio Code への統合 Go 拡張機能 をインストールします。 settings.json に以下を追加します： 7. 特定コードの無視 関数の上部にコメント //lint:ignore U1000 reason を追加することで、以下のチェックを無視できます。\n//lint:ignore U1000 Used by generated code func UnusedButNeeded() {} よくある質問 Q: テストファイル内の未使用関数をどのように処理しますか? A: staticcheck はデフォルトでテストファイルをチェックします。除外する場合は、-tests=false などのフラグを使用できます。 Q: CI/CD 環境への統合は? A: GitHub Actions に追加： サンプル出力 $ staticcheck -checks=U1000 ./... internal/utils/helper.go:15:2: 関数 privateHelper は使用されていない (U1000) cmd/server/main.go:23:2: initConfig 関数は使用されていない (U1000) staticcheck の U1000 規則を使用することで、未使用の関数を迅速に特定し削除し、コード品質を向上させることができます。\n","date":"2025-06-02","language":"ja","permalink":"https://ttf248.life/ja/p/find-all-functions-not-referenced-in-the-go-project/","tags":["golang","関数"],"title":"Go プロジェクトで参照されていないすべての関数を検索する。","year":"2025"},{"categories":["魚の7秒間の見聞"],"content":" 抖音で浙江金融圏の汚職摘発報道を見つけた。以前、金融汚職に関する序幕について一度書いたが、その後追跡する記事はなかった。 毎日、経済ニュースを見る習慣がある。以前は金融汚職に関する報道は見当たらなかったが、ここ2年ほどで金融汚職に関する報道が増加し、銀行や証券会社などの金融機関の幹部が摘発されるニュースが増えている。 金融汚職の序幕 近年中国金融分野において最も象徴的な事件の一つである、浙江省における金融圏の系統的な汚職風暴は、2023年に始まった反腐活動が四大国有銀行の浙江省支店長ら幹部の摘発をきっかけに明らかになった。地方金融システムが長年抱えていた権力乱用や政治的癒着といった深層の問題を浮き彫りにしたものである。以下では、事件の経緯、核心的な問題点、根本原因、そしてその後の影響という4つの側面から分析する：\n一、事件の経緯：朱從玖事件から四大行「掌門人」全軍覆没まで 火種：朱從玖事件が金融システム内のスパイ活動を浮上させる 2023年5月、当時浙江省副省長であった朱從玖が摘発され、その「金融に依存し金融で食う」腐敗モデルが突破口となった。朱從玖が在任中に企業の上場や融資などの介入を通じて巨額の利益を得て、金融機関の高官と利害同盟を形成した。2023年11月、朱從玖は党籍および公職から除奪され、捜査で明らかになった複数の手がかりがその後の金融システム地震を引き起こした。 反腐敗嵐の激化：四大行浙江支店の元頭取が相次いで摘発される 2024年4月：中国銀行浙江省支店の元頭取である郭心剛が摘発され、退職後に低価格での不動産購入や株式溢價などの方法で私腹を肥やし、鉱産融資の承認権を濫用して国有資産に重大な損失をもたらした。 2025年4月：建設銀行浙江省支店の元頭取である高強が摘発され、在任中に不正な融資承認を行い、複数のプロジェクトが未完となり、顧問料として数千万元を収受した。 2025年5月：農業銀行浙江省支店の元頭取である馮建龍が自ら投案し、在任中に農行浙江支店を「家族企業」に変え、親族が不正に役職に就き、生活作風の問題が深刻であった。 2025年5月30日：工商銀行浙江省支店の元頭取である沈榮勤が摘発され、退職後に「政商の回転ドア」を通じて钱塘江金研院などの機関を掌握し、八家民企と利益輸送ネットワークを形成した。こうして四大行浙江支店の元「一把手」（一把は「一柄」の略で、トップを意味する）が15ヶ月間で全て摘発され、反腐敗の閉環が形成された。 規制システムも同時に揺さぶられる 2025年1月、浙江省委金融部の元副主任である潘广恩が自ら投案し、職務上の便利を利用して企業株式の公開上場や投資の導入などの利益を得て、違法に巨額の財物を収受した。これは反腐敗行動が金融機関から規制部門へと拡大することを示し、「規制-金融機関-民企」三者の利害関係が深く結びついていることを明らかにした。 二、核心問題：信贷腐敗と回転門利益チェーン 信貸承認権の異化：腐敗の中核的ツール 四大行（大手銀行）の元頭取全員が信貸承認権を利用して利益移転を行った：郭心剛が鉱産融資を違法に流動化し、高強が「顧問料」で信貸を操作し、馮建龍家の一族による放贷（融資）により不良プロジェクトが発生し、沈荣勤が金研院プラットフォームを通じて関連企業に資金を移送した。データによると、2024年の銀行システムにおける被摘発者中、68%が違法な融資または貸付に関与しており、信貸権力の失控問題は目障りなほど深刻である。 回転門腐敗：退職は安全保障ではない 四人全員が退職後、「身分変換」を通じて権力を維持した：郭心剛が業界協会会長として信貸を干渉し、高強が証券会社独董に転任して資本を操作し、沈荣勤が「金融産学研」プラットフォームを構築して民企と接続した。このような「退職は休養ではない」という模式は、退職した幹部が規制を回避し、隠れた利益チェーンを形成することを可能にする。2024年の金融反腐白皮書によると、68%の事件が退職した幹部に関与しており、浙江事例が典型的なサンプルである。 政商境界線が曖昧：銀行から民企への利益移転 沈荣勤が執掌する钱塘江金研院（チャータンジャン・ジンレンユアン）は、正泰、传化など八家民企によって注資され設立された。表面上は学術機関であるが、実際には政商勾結の枢紐（ふすま）である。このプラットフォームを通じて、沈荣勤は銀行のリソースを関連企業に誘導し、「金融機関-民企智庫」という結合モデルを形成した。同様の模式は、郭心剛、高強事件にも見られ、地方金融生態における政商関係の深層的な歪曲を暴露出している。 III. 深層原因：制度の脆弱性と規制の機能不全 地方金融規制の長期欠如 浙江省は民営経済大省として、金融イノベーションが活発であったにもかかわらず、規制体制が追従しなかった。朱從玖、潘広恩などの官员が長年にわたり地方金融政策を主導し、「运动员」と「裁判員」の両方の役割を果たしたため、規制は形骸化した。例えば、潘広恩が金融办で職務を務めた期間中、企業への融資や株式改革を違法に介入したが、有効な制約を受けることはなかった。 金融機関の内部統制の失效 四大行浙江分行の内部監視メカニズムは形骸化していた。馮建龍が農行浙江分行行長を務めた時期、親族がシステム内で急速に昇進し、「一言堂」信貸承認現象が突出した。沈榮勤が推行的「员工关爱计划」は表面上福利であると見なされたが、実際には基层従業員を統制することで権力を巩固し、腐敗行為を隠蔽していた。 外部監視メカニズムの薄弱 跨省監察モデルの启用（如沈榮勤案由辽宁省监委办理）は、地方保護主義が反腐プロセスを阻害していたことを示している。さらに、金融機関と民企の複雑な股权関係（如浙商銀行前十大贷款客户中半数为房企）によりリスク伝導が隠蔽され、伝統的な規制手段が穿透することが困難であった。 四、後続の影響：規制強化と業界の再構築 反腐常態化と制度の堵漏\n広域監督と穿透的規制: 中央紀委は異地办案（異地域での事件処理）を採用し、地方の保護網を断ち切るとともに、審査範囲を在職中の行為から退職後の利益連鎖に拡大。 技術反腐落地: 浙江省が信貸承認においてAI風控モデルを試験的に導入し、人情贷（人情味のある融資）や政商贷（政治と商業を結びつけた融資）を自動的に識別し、源流から権力蓄積を阻止。 離職从业制限: 浙江省が金融高管の離職リストを作成し、銀行行長が退職後3年間、関連企業での就任を禁止することで、権力の期権化チェーンを切断。 金融生態系の再構築\n金融システムリスクの清算: 浙商銀行、杭州銀行などの機関が幹部の摘発を受けて内部整頓を開始し、不動産ローン比率が高い問題（例：浙商銀行の不動産不良率が2.48%に達する）をめぐる業務転換を迫られた。 民企融資環境の最適化: 反腐活動後、浙江省は「浙科贷」（浙科金融）などの政策を打ち出し、2024年に3万2千社以上のテクノロジー型中小企業に4500億元もの融資を提供し、金融が実体経済の本源に戻ることを促進。 社会的警示効果 四大行の浙江省支店の原行長たちが集団で失脚したことで、「退職は安全」という幻想を打ち砕き、「反腐に対するゼロ忍耐、無盲区」という信号を送った。この事件は全国の金融システムに鏡鑑（模範）を提供し、権力制約を強化し、規制体系を改善することで、金融安全を守る必要があることを示唆している。\n結論 浙江金融圏崩壊事件は、本質的には地方金融権力の長期的な失控が集中して爆発したものです。この嵐は、多くの「金融蛀虫」を排除するだけでなく、規制モデル、制度設計、および業界生態における深刻な変革を促しました。今後、金融イノベーションとリスク管理のバランスをどのように取るか、そして「親清」政商関係をどのように構築するかは、浙江および全国の金融分野において継続的に探求される課題となるでしょう。\n","date":"2025-06-02","language":"ja","permalink":"https://ttf248.life/ja/p/the-zhejiang-financial-circle-collapsed-and-the-anti-corruption-efforts-over-the-past-two-years-have-not-been-limited-to-government-departments/","tags":["浙江 (せっこう)","金融","反腐败 (Hанфуbài)","抖音 (Douyin)","経済ニュース"],"title":"浙江の金融圏崩壊、ここ2年間の反腐が政府部門に限定されなくなっています。","year":"2025"},{"categories":["コンピューター"],"content":"ローカルにGitリポジトリがあり、そのサブモジュールがプル時に一時ブランチになっている。私はその一時ブランチでいくつかのコードをコミットし、その後サブモジュールをmainブランチに戻した。しかし、これらのコミットされたコードが見つからず、mainブランチで見つけることができない。また、その一時ブランチの履歴も見つけられない。\nソリューション Git サブモジュールで一時的なブランチにコミットし、main ブランチに戻すとこれらのコミットが見つからなくなることがあります。この状況を解決するには、以下の手順に従ってください。\nコミット履歴の確認: サブモジュールのディレクトリに移動し、reflog を使用して失われたコミットを見つけます。 新しいブランチを作成してコミットを保存: 失われたコミットに基づいて新しいブランチを作成します。 メインブランチへのマージまたはcherry-pick: コードをメインブランチに統合します（マージするか、cherry-pickを使用して特定のコミットを選択）。 以下は具体的な操作手順です。\n# サブモジュールのディレクトリに移動 cd path/to/your/submodule # reflog で HEAD の変更履歴を確認（未関連ブランチのコミットも含む） git reflog PS F:\\dev\\notebook\\scripts\\hugo-content-suite\u0026gt; git reflog de05175 (HEAD -\u0026gt; main, origin/main, origin/HEAD) HEAD@{0}: checkout: moving from c8d070651310e90d283cb64d98da088c5fe05e73 to main c8d0706 HEAD@{1}: commit: feat: Markdown 記号の用法ドキュメントを追加、詳細な構文例と効果のデモを提供 48250f5 HEAD@{2}: commit: feat: 文章翻訳プレビュー機能を削除し、翻訳プロセスを簡素化 b8280b6 HEAD@{3}: commit: feat: 絶対パスを取得する機能を追加し、相対パスを絶対パスに変換をサポート 92c354b HEAD@{4}: commit: fix: 文章スキャンロジックの修正、絶対パスを使用してスキャンするようにする de05175 (HEAD -\u0026gt; main, origin/main, origin/HEAD) HEAD@{5}: checkout: moving from main to de05175d4ec0828e3ae95d726b09dfff18f67a23 de05175 (HEAD -\u0026gt; main, origin/main, origin/HEAD) HEAD@{6}: clone: from https://cnb.cool/ttf248/hugo-content-suite.git # 失われたコミットに基づいて新しいブランチを作成（例：456def を使用） git checkout -b saved-work 456def # メインブランチに戻る git checkout main # 保存した作業をメインブランチにマージ（または cherry-pick で特定のコミットを選択） git merge saved-work # または git cherry-pick 456def # 親プロジェクトディレクトリに戻り、サブモジュールの更新をコミット cd .. git add path/to/your/submodule git commit -m \u0026#34;Update submodule to include new changes\u0026#34; 主要操作手順 git reflog: HEADのすべての履歴を表示し、ブランチに関連付けられていないコミットも含む git checkout -b: 任意のコミットから新しいブランチを作成し、作業を保存する git merge/cherry-pick: 保存されたコミットをターゲットブランチに統合する reflogで記録が見つからない場合は、git fsck --lost-foundを使用して孤立したコミットを探す必要があるかもしれませんが、これは非常にまれなケースです。 ","date":"2025-06-02","language":"ja","permalink":"https://ttf248.life/ja/p/git-submodule-merge-history-lost/","tags":["git","submodule"],"title":"Git 子モジュール提交記録の消失","year":"2025"},{"categories":["コンピューター"],"content":"最近、体内時計が少し乱れていて、夜2時過ぎまでGitHub Pagesのデプロイに苦戦していました。 仕事が終わってからようやく食事を摂り、すぐに寝ようとすると、食べ終わって帰宅して8時半頃になり、眠くて困って、目を閉じるとそのまま眠くなってしまい、目が覚めるともう凌晨2時でした。\nまだ起動もしていないうちに消滅した分類：AI 研習所\nフラグ（フラッグ） 昨日、話していなかった「未熟な」フロントエンドを批判していたのに、今日はフロントエンドではなく、UI/UXの体験を追求している。\nプロジェクト 弊社の古くからの友人、https://github.com/ttf248/ai-coding-demo が参上します。 そうです、以前の選株プロジェクトを、全体の構造を再構築し、その後のAIプログラミング関連の内容はこのプロジェクト下に集約されます。\n複数の Pages をデプロイする プロジェクトは国内で https://cnb.cool/ttf248/ai-coding-demo でホストされており、周知の通り、国内では Pages の公開をサポートしていません。そのため、海外の GitHub 上に公開する必要があります。\nブログは海外の GitHub に公開されます。まだ試したことがありませんが、複数のプロジェクトを Pages にデプロイすること、そして現在の処理しているプロジェクトが従来のブログサイトではないこと（単に多くのドキュメントといくつかの静的な HTML デザイン稿が含まれているだけです。）もわかります。\nその通り、このページは私が初めてクリックしたところ、複数のプロジェクトを Pages にデプロイすることはブログの公開に影響を与えないこと、そしてブログのドメインの下に新しいパスが追加されることを発見しました。\nhttps://ttf248.life/ai-coding-demo/\nここまできたら、完璧だと叫びました。\nAI 研習社 昨日、新しい分類を作成したことをきっかけに、AIを活用して多くのコンピュータ科目の学習を進めようと考えました。例えば、アルゴリズムやLeetCodeのプログラミング問題集などです。\n毎回の学習記録をブログに公開し、知識ベースを形成します。新しい分類として「AI 研習社」を作成しました。\n現在見られるように、異なるコースごとにそれぞれプロジェクトを作成し、学習ノートは各プロジェクトのReadme.mdファイルに記述しています。\n","date":"2025-05-28","language":"ja","permalink":"https://ttf248.life/ja/p/github-pages-easter-egg-deploy-multiple-sites/","tags":["github","github-pages","pages","deploy","multiple-pages"],"title":"GitHub Pages の Easter Egg: 複数の Pages をデプロイ","year":"2025"},{"categories":["コンピューター"],"content":"長年にわたりバックエンド開発に注力してきましたが、最近は AI プログラミングを試したり、少しフロントエンド関連のことも取り組むようになりました。しかし、この間の苦労の中で、自分には昔からある古傷—「繁華なものに目を奪われる」—に気づきました。AI を使ってフロントエンドインターフェースを実現しようとするのですが、実際にはそのような試みが現在の仕事に大きな実用的な助けになりませんし、むしろ時間を浪費してしまいます。\nAI の適用シナリオ 小規模なプロジェクトにおいては、AI ツールが大きな役割を果たすことができ、特に独立性が高く、システムとの結合度が低く、ビジネスロジックが単純な関数を作成する際に非常に役立ちます。これらのタスクは通常、明確な入力と出力があり、文脈依存が少ないため、現在の AI 支援プログラミングの能力範囲に最適です。\nしかしながら、複雑なシステムアーキテクチャや深いビジネスロジックに対処する場合、AI の限界が現れ始めます。それは、プロジェクトの実際のニーズから乖離した、見かけ上は合理的だが実際には不適切なコードを生成したり、デバッグが困難な潜在的な問題を導入したりする可能性があります。これらのシナリオにおいては、AI は補助ツールとして、完全なコード生成器に依存することなく使用されるべきです。生成されたコードは厳格なレビューとテストを受け、実際の要件を満たしていることを確認する必要があります。\n誤りと学習の代償 AI を使ってフロントエンドコードを生成しようとした際、多くの課題に直面しました。フロントエンドは私の馴染みのない分野であるため、問題解決には時間と労力がかかりました。プロンプトを調整して AI にコードを書き直しても、どうしても低レベルのエラーが発生してしまうのです。このような試行錯誤は時間と労力を浪費するだけでなく、現在の私のエネルギーはバックエンドのビジネスロジックに集中すべきだと痛感させられました。\n週末に完成させたプロジェクトを振り返ってみると、バックエンド開発とユーザーインタラクションロジックに焦点を当て、コンソールから機能を実装することが、現状で最も効率的な選択であると確信します。より多くの時間とエネルギーが手に入ったら、フロントエンドの知識を体系的に学ぶ方が良いかもしれません。\nフロントエンド学習の計画 フロントエンド技術スタックは複雑で多様であり、短期間で習得するのは現実的ではありません。まずは、Vue.jsやReact.jsなどのフレームワークを選択し、そのコアな概念と使用方法を深く学ぶことを計画しています。基礎知識を習得した後で、AIを活用してフロントエンドコードを生成することで、不慣れによる誤りや時間の浪費を防ぐことができます。\nまとめると、現在の段階ではバックエンド開発に重点を置き、着実にコアスキルを向上させることに注力します。その時が来るまで、フロントエンドとAIの組み合わせを探求することは控え、より大きな成果を得られる可能性があります。\n","date":"2025-05-26","language":"ja","permalink":"https://ttf248.life/ja/p/old-ailment-stunning-flowers/","tags":["AI","フロントエンド","バックエンド"],"title":"慢性疾患、華やかなりし世相に眼移り","year":"2025"},{"categories":["コンピューター"],"content":"本サイトはHugoで開発されていますが、筆者自身は常に中国語のタイトルを使用しており、その結果、生成される文章の超リンクが使いにくい状態でした。つまり、送信する際に、中国語の文字が超リンク内で%E4%BD%A0%E5%A5%BDのような形式にエスケープされてしまうため、見た目が良くありません。設定でslugを設定することで解決できますが、毎回手動で設定する必要があり、非常に面倒でした。 そこで、Claude4を使って翻訳アシスタントを開発し、中国語のタイトルを自動的に英語のslugに変換し、文章中に超リンクを追加することを試みました。これにより、手動での設定を回避できます。\nClaude4はマジで最高！文脈理解能力が大幅に向上し、複雑なタスクの処理効率も飛躍的に向上しています。\nプロジェクトアドレス 国内プロジェクトアドレス：https://cnb.cool/ttf248/hugo-content-suite 国外プロジェクトアドレス：https://github.com/ttf248/hugo-content-suite\nコードの実装 まず、実装の思路について説明します。すべての文章をスキャンし、タグ情報と記事タイトルを抽出した後、ローカルの大規模言語モデル（例：gemma-3-12b-it）を呼び出して翻訳します。\n実際の開発において、前世代の大規模言語モデルと比較して、Claude4 はいくつかの顕著な点を発揮しました。機能要件が多いため、Claude4 はインタラクティブメニューを自動的に設計し、さまざまな使用シナリオを考慮しました。例えば、タグ処理に関しては、Claude4 はタグの統計と分析だけでなく、分類統計もサポートし、さらにラベルのない文章を検出することも可能です。また、プレビュー機能やタグページ生成機能も提供しています。\nローカルの大規模言語モデルとの連携、翻訳キャッシュの追加、大規模なコードのリファクタリングなど、Claude4 はすべて一度に完了し、ほとんど問題がありませんでした。プロジェクト規模は小さくても、多くの小さな機能を含んでいました。以前の開発プロセスでは、大規模言語モデルが前の内容を忘れてしまうことがよくありましたが、今回の Claude4 は非常に優れており、ほぼコンテキストを忘れることなく動作しました。\n要するに、スマート性が向上し、今後の開発には Claude4 をより多く使用し、日常的なコーディングの主力モデルとして活用していく予定です。\n翻訳キャッシュ この注文に関する説明では、大規模モデルの呼び出し回数を減らすだけでなく、実際に12Bモデルをローカルで実行すると効率が非常に高く、時間ロスもありません。しかし、毎回大規模モデルを呼び出す場合は、やはり少し遅くなります。また、文章のリンクを固定するために、全量更新を実行した場合、文章のタイトルが長いため、稀に2回の翻訳結果が異なり、リンクが変わってしまうという状況が発生します。これは非常に困ります。\n機能最適化 プロジェクト全体を Claude4 に引き渡して、最適化の余地を分析し、以下の提案を得ました：\n外部化の設定 - メンテナンス性と柔軟性を向上 構造化ログ - 問題のトラブルシューティングと監視が容易になる パフォーマンスモニタリング - システムの状態を把握する ユーザーエクスペリエンス - プログレスバーなどの視覚的なフィードバック エラー処理 - より包括的な例外処理メカニズム コード整理 - より明確なモジュール分割 コードをレビューしたところ、問題点は一切なく、例えば設定ファイルについては、元のコードから設定を変換し、デフォルト設定に変換した後、設定ファイルを読み込む際に、対応する設定ファイルが存在しない場合に自動的にデフォルト設定ファイルを生成することで、ユーザーの操作ミスを防いでいました。 要件：翻訳文の正体を翻訳する際に、翻訳効率を動的に計算し、残りの時間を予測して、関連情報をコンソールに出力しました。現在、文章の文字数を取得し、各行の翻訳時に現在の翻訳文字数、時間、100文字あたりの翻訳時間を適合計算しています。同時に、文章全体の翻訳残り時間を推定します。 コードが完了した後、新しい驚きを発見しました。翻訳効率の統計情報がリアルタイムで大量に表示されますが、無制限にスクロールダウンすることはありませんでした。\n原文を英語に翻訳中（合計 7163 文字）... 翻訳する必要がある行数が 53 行検出されました。 [1/53] Stage1/6 [░░░░░░░░░░░░░░░░░░░░░░░░░] 1.9% 354 文字の翻訳... ✅ 完了 (3.1秒) | API呼び出し #1 ✅ 完了 (1.5秒) | API呼び出し #2 ✅ 完了 (0.9秒) | API呼び出し #3 ✅ 完了 (0.2秒) | API呼び出し #4 ✅ 完了 (1.0秒) | API呼び出し #5 ✅ 完了 (1.0秒) | API呼び出し #6 ✅ 完了 (0.2秒) | API呼び出し #7 📊 進捗: 行の 13.2% (7/53) | 文字の 12.9% (925/7163) 114.6 文字/秒 📊 ⚡ 効率：リアルタイム 76.4 | 平均 117.9 | 最近 109.0 | ステージ 113.6 文字/秒 📊 🎯 正確度: 100.0% (7/7) | 残り: 46行 7 秒] 9.4% 110 文字の翻訳... ⏱️ 残りの推定時間: 55秒 | 予想完了時間: 00:10:19 8秒] 11.3% 114 文字の翻訳... 💾 处理速度：3211.3 行/分钟 | 总用时：8秒] 13.2% 16 文字の翻訳... [8/53] Stage1/6 [███░░░░░░░░░░░░░░░░░░░░░░] 15.1% 166 文字の翻訳... 以前、プログラムを制御するコードはあまり書かれていませんでしたが、どのように実装されているのか知りたくて、コードを調べてみました。\n// キャッシュクリアと再表示（動的更新効果） if translationCount \u0026gt; 1 { fmt.Print(\u0026#34;\\033[6A\\033[K\u0026#34;) // 上に 6 行移動し、内容をクリア } パフォーマンス統計メニュー 新たに作成されたパフォーマンス統計メニューは、私自身が設計したものでも、これほど完璧とは言えない。\n📊 パフォーマンス統計： 🔄 翻訳回数：360 ⚡ キャッシュヒット率：1.4% (5/365) ⏱️ 平均翻訳時間：315.927234ms 📁 ファイル操作：73 ❌ エラー回数：0\nデータマイニング ディープラーニング ニューラルネットワーク === ブログ管理ツール ===\n🚀 コア機能\n全ブログの処理をワンクリックで実行 (完全なブログ処理フロー) 📝 コンテンツ管理 2. タグページを生成 3. アーティクルスラッグを生成 4. 記事を多言語バージョンに翻訳\n💾 キャッシュ管理 5. キャッシュの状態を確認 6. 全量翻訳キャッシュの生成 7. 翻訳キャッシュをクリア\nプログラム終了 ","date":"2025-05-24","language":"ja","permalink":"https://ttf248.life/ja/p/claude-4-release-hugo-tags-hyperlink-translation-assistant/","tags":["ai","hugo","claude"],"title":"Claude4のリリース、開発を試す：hugoタグ、超リンク翻訳アシスタント","year":"2025"},{"categories":["AI霊感衝突坊"],"content":"中国の計画的な人口抑制政策は、人口増加を制限すると同時に、大家族主義的な発展を抑え込み、伝統的な社会構造を揺るがし、家族企業や政壇の有力な家族勢力を抑制しました。これと比較して、韓国の財閥やインドの家族壟断を見ると、その独自性が浮かび上がります。現在、出産制限が緩和され、低出生率といった課題に直面していますが、同時に新たな垄断リスクにも警戒する必要があります。多方面からのバランスを模索していく必要があります。\n一、人口抑制と家族式発展の好対照 計画生育政策は、中国が継続してきた近40年間の基本国策であり、その直接的な成果は顕著である。データによると、1978年から2007年にかけて、中国の人口自然増加率は12‰から5.2‰に低下し、少生4億余人となった。人口占める世界の割合は22.2%から20.1%に減少した。このような人口成長率の急激な減退は、中国社会における家族構造を深く再構築した。家族企業を例にとると、計画生育政策が実施された後、企業主が子供を産む数は著しく低下した：政策前では3児以上の割合が40.63%であったが、政策後には18.46%に激減し、独生子が女子として育つ割合は6.25%から32.31%へと上昇した。このような構造的な変化は、家族企業が選択できる内部の後継者範囲を大幅に縮小させ、客観的に家族企業の世代交代能力を抑制している。\n韓国とインドの状況と比較すると、その差は顕著である。韓国は厳格な計画生育を実施しなかったものの、出生率は長年にわたり低迷（2023年には0.7）していたが、財閥グループはクロス持股や相続税回避などの手段を通じて、国家経済の命脈を依然として牢として握り続けている。5大財閥の総売上高は韓国GDPの超50%を占め、サムスングループだけでも全国GDPの20%に相当する。一方、インドでは異なった様相が見られる：79%の経済産出は家族企業が貢献し、6大複合体が电信や钢铁などの重要な分野を支配しており、20社のトップ企業が全国企業の利益の80%を稼ぎ出している。このような違いの中核は、中国の計画生育政策が家庭規模を制限することで、家族企業拡大の人材基盤を源泉的に弱体化させたことにある。一方、韓国とインドは政策環境の違いにより、家族勢力が経済領域に継続して浸透したのである。\n二、寡占抑制と社会構造転換 計画生育政策が経済領域に及ぼす影響は、特に寡占現象の抑制という点において顕著である。中国の家族企業は、女性数の減少により、韓国・インド型の財閥集団を形成することが困難であった。韓国の例では、財閥は「循環出資」を通じて家族による支配権を維持し、三星グループの家族はグループ全体の2%の株式しか保有しておらず、複雑な股权構造によって全体を掌握していた。一方、中国においては、計画生育後に家族企業は一般的に「子承父業」の困境に直面し、職業经理人や株式の多元化改革を余儀なくされた。澎湃新聞の研究によると、計画生育後、家族企業の女性後継者比率は13.85%から34.21%へと上昇し、また後継者の学歴は大幅に向上しており、学士以上の学位を持つ割合は43.75%から98.46%へと増加した。このような転換は、完全に家族による支配を排除したわけではないものの、単一の家族による市場支配の可能性を著しく低減させた。\n社会構造レベルにおいては、計画生育政策が伝統的な家族核心モデルの解体を加速させた。中国における家庭規模は、1982年の4.41人/戸から2020年には2.62人/戸へと縮小し、小型化された家庭は、経済、教育、社会支援などの面で家族の機能を弱体化した。これに対しインドでは、その家庭規模が4人程度に維持され、カースト制度と家族勢力が深く結びついているため、社会流動性が低い状態が続いている。中国における家庭構造の転換は、個人主義の発達のための空間を創出しており、2023年には中国の単身成年人口が2.4億人に達し、消費市場には「一人経済」台頭のトレンドが見られる。このような変化は、家族経済の影響力をさらに希薄化させている。\nIII. 政治分野における権力分散化 計画生育政策は、政治生態に深遠な影響を及ぼした。伝統的に、家族勢力は血縁や姻親関係を通じて地方政治に浸透してきた。例えば、河南省新野県において161の政治家族がほぼすべての政府部門を支配し、副科級以上の幹部の中で20%が「官二代」（官僚の子）であった。しかし計画生育政策の実施により、家庭規模が縮小したため、家族ネットワークの拡大が制限された。北京大学の研究では、計画生育によって役人の子供たちの数が減少し、家族政治ネットワークの複雑さが著しく低下したことが示されている。さらに、政策を推進した教育の普及（1982年の一人当たり受教育年数5.2年から2023年には10.9年に向上）は社会的な流動性を促進し、家族勢力が政治資源に対する独占を弱体化させた。\n韓国とインドと比較すると、韓国の財閥と政治との深い結びつき（三星グループの高官と政府の金銭取引など）や、インドのカースト制度下における家族政治の世襲は、中国政策の独自性を浮き彫りにする。中国は計画生育政策を通じて、客観的に権力の世襲の可能性を減少させた。地方政治の中には依然として家族現象が存在するものの、全体的な傾向としては権力構造の分散化が進んでいる。2025年の全国人民代表大会（全会）期間中、政協委員の一人が「人口と計画生育法」を「人口と生育法」に改名し、完全な出生の自由化を提案したことは、将来の政治生態の変化にさらなる影響を与える可能性がある。\n四、政策調整後の課題と機会 2016年の全面二孩政策、2021年の三孩政策の実施は、中国の生育政策における重大な転換を意味する。しかし、その効果は限定的であり、2022年の出生率はわずか1.18で、世代交代水準（2.1）を大きく下回っている。\n放開された生育に対する家族企業への影響は二面性を示している。一方、一部の起業家が多胎児を通じて家族传承能力を高める可能性がある（例えば、浙江娃哈哈グループの宗慶後の娘である宗馥莉が独身女として後継者となるケースなど）。他方で、高額な育児コスト（一线都市で子供を18歳まで育てると平均100万元かかる）と職業女性の生育意欲低下により、家庭規模の拡大は制限されている。\n経済分野においては、放開された生育が新たな寡占形態を生み出す可能性がある。三孩政策は母婴、托育などの業界における集中度を高め、2025年の乳幼児托育市場規模は1621.3亿元と予測されており、大手企業が并购を通じて中小企業を統合し、CR5集中度を超える55%となっている。このような集中度は効率をもたらす可能性がある一方で、新たな寡占リスクに警戒する必要がある。政府は生育促進と市場集中防止のバランスを取り、反垄断法による規制強化や育児補助金（例えば、杭州三孩家庭が毎月3000元をミルク補助として受給するケースなど）を通じて家計負担を下げるなどの措置を講じる必要がある。\n政治分野においては、放開された生育が家族勢力に微妙な影響を与える可能性がある。短期的に伝統的な家族政治ネットワークを回復することは困難だが、長期的に見ると多子世帯が地方政治において新たな影響力を形成する可能性がある。したがって、干部の選抜メカニズムの改善と監督強化（例えば、干部の親族任用回避制度の構築など）は、権力世襲を防ぐための重要な鍵となる。\n五、国際鏡鑑と未来展望 韓国およびインドの経験は、家族勢力の親和性・敵対性と政策誘導が密接に関連していることを示唆する。韓国は財閥育成によって経済発展を遂げたが、同時に社会公平の犠牲となった。インドは効果的な政策による家族支配の抑制に失敗し、貧富格差が拡大した。中国の計画生育政策は人口コントロールを達成すると同時に、家族勢力の拡大を抑制したが、高齢化の加速や労働力不足といった問題も引き起こした。\n未来において、中国は人口政策と社会経済発展の間で新たなバランスを見出す必要がある。一方では、出産支援策（産休の延長、共配役托育施設の建設など）を通じて出生率を高めるべきである。他方では、家族企業の資本操作による新たな独占を防止するため、反垄断取締りを強化する必要がある。政治面においては、地方民主主義の構築と監督メカニズムの改善を通じて権力の透明性を確保することが重要となる。\n結論として、計画生育政策は中国社会変革の重要な推進力であり、その影響は人口領域を超えて広範である。それは家族構造、経済モデル、そして政治生態を再構築し、中国が韓印式に陥る家族支配の罠を回避するための道筋を提供した。政策の調整に伴い、新たな人口格局下で効率と公平、自由と秩序のバランスを取ることこそが、中国が直面する長期的な課題となるだろう。\n","date":"2025-05-24","language":"ja","permalink":"https://ttf248.life/ja/p/china-family-planning-policy-impacts/","tags":["計画出産 (Keikaku shussan) / 家族計画 (Kazoku keikaku)","人口政策 (Jinkōセイケン)"],"title":"計画生育政策の多面的な影響：社会構造から経済・政治への深層変革","year":"2025"},{"categories":["メモ書き雑感"],"content":"新しい「AI 灵感碰撞坊」を立ち上げたことで、様々なものが溢れてしまい、AIを使って記録したり、発信したりするものが増え続けていますが、静かに自分自身で考え込むようなものは減ってきているようです。今後はこの欄の出力をある程度コントロールし、月刊形式にまとめるのが良いかもしれません。毎月1本の内容を公開すればよいでしょう。\nこれはまるで、一種の副作用のようなもの、あるいは後遺症と言えるかもしれません。効率は上がっていますが、思考の深さや幅は縮んでしまっているように感じます。\n効率向上：否定できない 以前、ブログのコーナー「魚の七秒鐘見聞」はあまりメンテナンスされていませんでした。いくつかの話題事件を放置し、インターネット検索や記録整理を行わずにいたためです。しかし、様々なAIツールが登場し、大枠を整理するだけで、AIが自動的に関連するイベントを検索・記録し、必要な文章を生成したり、簡単なフォーマット調整を行うことができます。\nこれはまさに怠惰な人にとっての福音であり、効率は大幅に向上しました。さらには、執筆やコーディングにおいても同様です。以前はAPIインターフェースドキュメントの詳細な読み込みが必要でしたが、現在はAIがそれを代わりに行うため、非常に効率的です。APIの習得は「肉体労働」であり、「知的労働」ではありません。AIにこの部分を任せるのが最適です。\n垃圾コンテンツ 多くの稿子で、内容の質が低いと言わざるを得ません。読み応えがなく、煙火の息吹がないという点で、以前私が好まなかったスタイルです。まるで蝋を噛むようなものです。\n別の角度から言えば、AI生成コンテンツは、まさに流水線のようなもので、魂が欠けていると感じられます。\n新時代のインターネットゴミ\n忘却性 このタイプの稿子は、読者の状況が不明確であり、時間が経つにつれて、私の記憶も曖昧になり、つい忘れかけてしまうことがあります。\n同様の問題は、コードを書く際にも発生します。コードの提交記録を振り返らずに、自分がどのように考え、なぜそう書いたのか全く思い出せないのです。特に、コードとAIが繰り返しコミュニケーションを通じて生成されたコードは、当初のアイデアとは大きく異なり、場合によっては全く異なるものになってしまうことがあります。\n検索 最近、Googleや百度を開く回数が明らかに減りました。多くの問題はAIを使って検索したり、インタラクティブな部分も検索結果も、従来の検索エンジンよりもずっと良いからです。 現在では、まだ生きているかどうか分からないbing aiを追悼しましょう。これは大手企業の中で最初に公開された、インターネットに接続して検索できるAIツールです。 Googleの使用頻度が減り、stackoverflowへのアクセス回数も減りました。多くの問題は直接AIに質問するだけで済みます。このサイトも時代の淘汰にさらされるでしょう。\nおわりに 筆記がメンテナンスしているブログですが、元々アクセス数は少なかったこともあり、現在はさらに期待していません。むしろ、自分宛の記録場所という性格になっています。\n","date":"2025-05-14","language":"ja","permalink":"https://ttf248.life/ja/p/ai-overuse-side-effects/","tags":["ai","インターネット"],"title":"AIを使いすぎると、後遺症のようなものがある。","year":"2025"},{"categories":["コンピューター"],"content":"github-readme-stats は、GitHub の個人プロフィールに関する統計情報を生成するツールです。ユーザーの GitHub 個人プロフィールの様々な統計情報やグラフの表示を可能にします。多様なカスタマイズオプションを提供し、ユーザーのニーズに合わせて調整できます。\n筆者はリポジトリ管理の習慣として、プロジェクトごとにグループ化を行っていますが、GitHub はリポジトリのグループ化をサポートしていないため、異なる組織に分割することで実現しています。github-readme-stats の最新ブランチでは、異なる組織のリポジトリ統計のクロスオーバーに対応していません。そこで、対応するコードをマージしたブランチをフォークしました。\n最終結果 プルリクエスト 元のURL 組織のリポジトリからのデータを含める機能を追加\n上流のプルリクエストをフォークのリポジトリにマージする ある プルリクエスト (PR) をあなたの フォークしたリポジトリ にマージするには、いくつかの方法があり、あなたが以下のいずれかを達成したいかによって異なります。\n上流（upstream）リポジトリ から PR をあなたのフォークにマージするか、 他の人のフォークから PR をあなたのフォークにマージするか、 あなたのフォークで作成された PR (例えば、他の人があなたにフォークして PR を提起した場合) をマージする まず、最も一般的なシナリオを説明します：フォークしたリポジトリがあり、上流の PR をあなたのフォークにマージしたい場合。操作手順は以下のとおりです👇\n✅ 方法１：コマンドライン方式（最も汎用的） ステップ 1：自分のフォークをクローンする git clone https://github.com/あなたのユーザー名/リポジトリ名.git cd リポジトリ名 ステップ 2：upstream (元のリポジトリのURL) を追加 git remote add upstream https://github.com/原作者のユーザー名/リポジトリ名.git ステップ 3：上流のPRブランチをリポジトリに取得する マージしたいPRの番号（例：PR #123）を見つけます。\n以下のコマンドでそのPRのコードをリポジトリに取得できます。\ngit fetch upstream pull/123/head:pr-123 ステップ4：ブランチを切り替え、マージする git checkout main # またはあなたのターゲットブランチ git merge pr-123 すべて正常であれば、GitHub リポジトリにフォークした場所にプッシュできます。\ngit push origin main ✅ 方法二：GitHub ウェブインターフェース（シンプルだが限定的） GitHub のウェブ上で特定のプルリクエスト (PR) が上位のレポジトリに対するものである場合、以下の手順を実行できます。\nその PR ページにアクセスします。 右上部の「Commits」または「Files changed」をクリックし、この PR がどのブランチに基づいて作成されているかを確認します。 あなたのフォークページで新しいブランチを作成し、手動で PR のコミットを cherry-pick します（Git に関する知識が必要です）。 または、「Open in GitHub Desktop」をクリックして、GUI ツールを使用してマージします。 🚀 他人があなたのフォークに対してプルリクエストを送信した場合 プルリクエストのページに直接移動し、「Merge pull request」ボタンをクリックしてください。\n具体的な状況（例えば、PRリンク、ウェブインターフェースを使用しているかコマンドラインを使用しているか）に応じて、ステップバイステップでデモンストレーションが必要ですか？ または、具体的なリンクを提供していただければ、最も簡単な方法を分析します。\n","date":"2025-05-07","language":"ja","permalink":"https://ttf248.life/ja/p/merge-pullrequest-to-forked-repo/","tags":["github","fork"],"title":"フォークのレポジトリにプルリクエストをマージする","year":"2025"},{"categories":["コンピューター"],"content":"スクリプトは、Git履歴のコミットメッセージの作成者情報をまとめて変更するために使用され、git filter-branchを使用してGit履歴を書き換えます。\nご提供いただいたスクリプトは、Gitリポジトリの履歴コミットにおける作成者情報を一括で修正するものであり、全体的な考え方は正しいですが、git filter-branch の --env-filter で配列（例：OLD_EMAILS=(\u0026quot;...\u0026quot;)）を使用すると、一部のシェル環境（例：/bin/sh）では互換性の問題が発生する可能性があります。これは、配列構文がサポートされていないためです。 互換性を高めるために、配列をスペースで区切られた文字列に置き換え、forループを使用して各古いメールアドレスを反復処理することをお勧めします。以下は修正後のスクリプトの例です。\n#!/bin/sh git filter-branch --env-filter \u0026#39; OLD_EMAILS=\u0026#34;TianlongXiang51@gmail.com nick@qq.com tianlongxiang51@gmail.com\u0026#34; CORRECT_NAME=\u0026#34;tianlong.xiang\u0026#34; CORRECT_EMAIL=\u0026#34;tianlong.xiang@foxmail.com\u0026#34; for OLD_EMAIL in $OLD_EMAILS do if [ \u0026#34;$GIT_COMMITTER_EMAIL\u0026#34; = \u0026#34;$OLD_EMAIL\u0026#34; ] then export GIT_AUTHOR_NAME=\u0026#34;$CORRECT_NAME\u0026#34; export GIT_AUTHOR_EMAIL=\u0026#34;$CORRECT_EMAIL\u0026#34; fi if [ \u0026#34;$GIT_AUTHOR_EMAIL\u0026#34; = \u0026#34;$OLD_EMAIL\u0026#34; ] then export GIT_COMMITTER_NAME=\u0026#34;$CORRECT_NAME\u0026#34; export GIT_COMMITTER_EMAIL=\u0026#34;$CORRECT_EMAIL\u0026#34; fi done \u0026#39; --tag-name-filter cat -- --branches --tags 注意点：\nこのスクリプトを実行する前に、リポジトリのバックアップを作成することを強くお勧めします。これにより、予期しない問題が発生した場合に備えることができます。 この操作はGit履歴を書き換えており、コミット作成者の情報を変更するため、コミットハッシュが変更される可能性があります。 既に変更をリモートリポジトリにプッシュしている場合は、強制プッシュを実行する必要があります。 強制プッシュには注意し、特に複数人での共同プロジェクトでは、他のメンバーへの影響がないように慎重に行ってください。 リポジトリ内のすべてのユニークな作成者メールアドレスの統計\ngit log --format=\u0026#39;%an \u0026lt;%ae\u0026gt;\u0026#39; | sort -u ","date":"2025-05-07","language":"ja","permalink":"https://ttf248.life/ja/p/git-modify-commit-message/","tags":["git"],"title":"Git での履歴記録におけるコミット情報","year":"2025"},{"categories":["コンピューター"],"content":"先月の当社では、cursorを試用しましたが、無料枠の制限により、複雑な機能開発は行わず、簡単なテストに留めました。その際に見つけたのは、Byte社も同様の製品を発表しており、両者は共通してClaude-3.5という大規模言語モデルを底で呼んでいる点でした。 Byte社の製品はTraeといい、最初にリリースされたmac版が今年2月にWindows版もリリースされました。大手企業のものは良いもので、無料でClaude-3.5を無制限に利用できるため、このモデルの性能は非常に優れています。\n最終的にはK線チャートの開発で詰まってしまいました。Reactの知識が全くない私には、直接的に大きなタスクであるK線チャートの開発を引き受けることはできません。より細かくタスクを分割し、開発を進めるためには、筆者がフロントエンドの基礎知識を追加し、タスクを分解する必要がありました。\n発見された問題点 外国製のAIモデルを使用していたため、Vue3 + Element-Plusの学習データが不足しており、Reactをフロントエンドフレームワークとして採用しました。 偶発的な構文エラーが存在する可能性があり、手動での修正が必要です。 一部の複雑な問題に対する解決策は、人的指導が必要となります。 コード構造の最適化には、人的指導が必要です。 最も時間がかかったのは、フロントエンドコードをコンテナにパッケージングすることでした。筆者は環境が全く理解されておらず、.env.productionやtsconfig.jsonといった概念自体を知らなかったため、途中で助けを求める豆包（ネットでの質問サイトのユーザー）に頼らざるを得ませんでした。フロントエンドの開発 devモードとbuildモードでは、コードチェックや差異が大きく異なり、対応に苦慮しました。バックエンドのデータベースおよびサービスのコンテナスクリプトは、合計5分で完了しましたが。 AIは現状では開発効率を向上させる主な役割であり、基礎があることが最も重要です。AIがすべての問題を解決してくれるわけではありません。 リポジトリアドレス タイトル通り、今回は手を動かさず、AIと雑談して、自選株モジュールを設計・開発してみます。最終的に何ができるのか試していきます。\nリポジトリアドレス：https://github.com/ttf248/trae-demo\n詳細な使用方法は、リポジトリのREADME.mdファイルをご覧ください。\nこのリポジトリには多数の提出記録が含まれており、ほとんどが私とTraeとの会話記録、およびTraeの機能に対する私のテストです。対応する機能を実装するために人工干渉を行ったかどうかを備考に記載しています。\nプロンプト プロジェクトは、ゼロから作成するものですが、以下の内容がプロジェクトのプロンプトです：\nプロジェクトのプロトタイプ図に基づいて、以下の機能を開発してください： * 選別銘柄（ウォッチリスト）機能。契約新規追加、削除、修正、照会をサポートする必要があります。 * 選別銘柄インターフェースは、基本的な市場データを表示する必要があります。 * 複数の異なる市場の切り替えをサポートする必要があります。 フロントエンド：React バックエンド：Golang Gin GORM データベース：PostgreSQL サーバーサイドには、クロスオリジンリクエストをサポートする必要があり、データの検証とエラー処理も考慮する必要があります。バックエンドサービスが利用できない場合、フロントエンドはアラートを表示する必要があります。 バックエンドは、リクエストとレスポンスのログを表示し、フロントエンドも通信ログを出力して問題のトラブルシューティングに役立てます。 UIとインタラクションの最適化 フロントエンドインターフェースのデザインは完全にGrokに依存しています。まず、Trae内で成果物のプロトタイプを作成しましたが、美観が欠けていました。使用していたモデルはコード能力は非常に高いものの、他の能力は弱いため、Grokを使用してフロントエンドのUIを最適化する必要があります。\n現在のインターフェースのスクリーンショットを撮影し、それをGrokにアップロードして、UIを最適化するように指示します。これにより、一度に多くの最適化提案を受け取ることができ、それらを人工的に評価し、Traeにコピーして実行し、最適化の効果を確認できます。\n技術スタック フロントエンド：React + TypeScript バックエンド：Golang + Gin + GORM データベース：PostgreSQL 17 システムアーキテクチャ バックエンドアーキテクチャ バックエンドは Golang の Gin フレームワークを用いて RESTful API を実装しており、主なモジュールには以下が含まれます。\nデータベースモジュール GORM を ORM 框架として使用 環境変数でデータベース接続を設定可能 自動的にデータベーススキーマのマイグレーションを実行 ルーティングモジュール RESTful API 設計 一貫したエラーハンドリングメカニズム 内蔵されたリクエストログ記録 クロスオリジン処理 ローカル開発環境でのクロスオリジンをサポート 設定可能な CORS ポリシー Cookie を使用したクロスオリジンをサポート フロントエンドアーキテクチャ フロントエンドはReact + TypeScriptで構築され、以下の機能を実装しています。\n株価リストの表示 お気に入り銘柄の管理 相場データ表示 エラー通知メカニズム ","date":"2025-02-27","language":"ja","permalink":"https://ttf248.life/ja/p/design-develop-custom-stock-module-no-code/","tags":["ai","trae"],"title":"コードを記述せず、カスタム株式選定モジュールを設計・開発する。","year":"2025"},{"categories":["コンピューター"],"content":"米国株式市場には、プレマーケット、マーケットオープン後、マーケットクローズの3つの取引時間があります。データ配信は、プッシュ通知を使用するか、数値増分のロジック（可能な限り帯域幅を節約）を採用します。初回送信では全量データを送りますが、2回目以降はすべてのフィールドを増分で推送します。\nなぜ最適解を用いないのか？複数のプロジェクトグループに分散しており、一部はすでに数年ローンチされています。弊社は新規の連携のため、できる限り互換性を保つようにしています。\nいくつかの問題点 概要だけでは、特に問題がないように見えるかもしれないが、社内システムアーキテクチャに組み込まれた問題や、それらを引き起こす一連の問題が発生する。直前に問題を解決したにもかかわらず、新たな問題が発生し、その問題は以前の問題によって引き起こされたものである。\n取引時間帯の認識エラー 盤中ステージを protobuf で定義されている 0 と認識していますが、増分配信のため、業務側ではこの 0 がデフォルト値なのか、それとも実際の取引値なのかを明確に判断できません。\n分かりやすく言うと、0 を受信した際に、それが新しい行情設定の値なのか、protobuf のデフォルト値なのかを判断できないということです。\nオプショナルについて protobuf 3.15 以降、proto3 では (proto2 と同様に) オプショナルキーワードを使用してスカラーフィールドの存在情報を指定できるようになりました。\nチーム内の通信プロトコルは protobuf をベースにしていますが、歴史的な理由により選択されたバージョンが古く、optional キーワードをサポートしていません。理解している方はご存知でしょう。底层から protobuf を導入したため、プロジェクトの底层は静的ライブラリとして protobuf を公開しており、その結果、全体のコンパイルチェーン全体をアップグレードする必要があり、このコストは非常に高くなっています。\nGCC のバージョン問題 ようやく解決策を思いついたのだが、底层で異なるバージョンのリリースをするという方法を試みた。可能な限り protobuf の新しいバージョンのコンパイル依存関係の伝播を制御しようとした。しかし、コンパイル時に gcc のバージョンが低すぎて、protobuf の新機能に対応していないことが判明した。 グループ内でよく使われるサーバーの種類：CentOS7、CentOS8。CentOS7 のデフォルトの gcc バージョンは 4.8 であり、CentOS8 のデフォルトの gcc バージョンは 8.3 である。protobuf の新機能は gcc のバージョンが 7.4 以上であることを必要とするため、CentOS7 はサポートできない。 Bug 82461 - [7 Regression] Temporary required for brace-initializing (non-literal-type) member variable。 結局、関連サービスのデプロイやコンパイルサーバーを CentOS8 に移動することで問題を解決した。\n理論的な列挙 問題を全体的に見直すと、よりシンプルで効率的な解決策があります。それは、列挙の定義を調整し、1から番号付けするようにすることです。これにより、デフォルト値とビジネス値を明確に区別でき、上記のような問題を防ぐことができます。\nなぜ 1 から始める方が合理的なのか？ protobuf において、enum 型のデフォルト値は固定で 0 に設定されています。もし、有意義なビジネス値を 0 (例えば「市場中」) に定義した場合、増量プッシュ時にビジネス側では受信した 0 がビジネス値なのか、未設定のデフォルト値なのか判断できません。一方、enum を 1 から定義すれば、0 は無意味なデフォルト値または「未知」の状態として保持でき、問題が解決されます。\n推奨される実践：\nprotobuf の enum を設計する際には、常に 0 を無意味なデフォルト値 (例: UNKNOWN または RESERVED) として定義すること。 実際のビジネス値を 1 から割り当て、デフォルト値 0 と区別できるようにすること。 この小さな調整により、取引時間帯の識別の問題を解決するだけでなく、将来のプロトコル設計にも貴重な教訓を提供しました。\n","date":"2025-02-20","language":"ja","permalink":"https://ttf248.life/ja/p/protobuf-zero-value-trap/","tags":["トラブルシューティング","protobuf","通信プロトコル"],"title":"Protobufのゼロ値問題：デフォルト値が暗黙のビジネスロジックの致命的な脅威となる","year":"2025"},{"categories":["魚の7秒間の見聞"],"content":"2024年の国慶前に、中国株式市場は注目すべき急騰相場を経験したが、休暇後には劇的な暴落へと転換した。この株式市場の「氷火両重天」（冷暖差）は、投資家たちにジェットコースターのような心境の変化をもたらすと同時に、政策、経済、そして市場の規律に対する深い考察を引き起こした。\n昨年国慶前の株式暴騰をテーマにブログを作成し、最後に国慶後の株式暴落を含める。文章スタイル：ニュース記事\n国慶前の株式暴騰：政策主導の狂騒 2024年の国慶前に5日間、中国株式市場は低迷から一転、「沸騰モード」（煮えたぎる状態）へと急上昇した。9月30日、A株市場全体が大幅に放出しながら高騰し、主要指数はすべて過去最高値を更新した。上證指数は8.06%の大幅な上昇、深証成指は10.67%、創業板指は15.36%の急騰を記録し、北證50指数は史上最大の一日株価上昇を達成、22.84%も暴騰した。市場のセンチメントは極度に高揚し、沪深北三市（上証、深証、北證）の当日の取引額は2兆6115億元に達し、前回の取引日と比較して11559億元も放出し、主要株価指数超5300銘柄が同時に上昇し、「一片紅」（一面真っ赤）という状況となった。\nこの相場を牽引した主な要因は、政府による一連の予想を上回る政策発表と、それによって引き起こされた市場期待の変化である。9月24日、中国人民銀行は準株価（LRR）の引き下げと金利引き下げを発表し、既存住宅ローン金利を低減するとともに、最低頭金の統一基準を設定した。9月26日の中央政治局会議では、逆周期的調整の財政・金融政策の力度を強化し、資本市場を刺激するとともに、中長期資金の流入を促進する必要性を強調した。9月30日には、不動産支援策が集中して発表された。これらの政策措置は市場に政府が市場と成長を安定させる決意を示したことを伝えた。\n国慶後の株式市場の大幅暴落：歓喜の後の冷静と調整 しかし、国慶節（中秋節・国慶節）の後、市場のセンチメントは急激に転落した。10月8日、A株はほぼストップ高の水準で強気にオープンしたが、大幅な上昇後、市場は激しい変動を迎えてしまい、最終的に高値から低値へと大きく下落してクローズした。それ以来、市場の重心は継続的に低下し、10月16日時点で上海総合指数（沪指）の振幅は15%を超え、累計470点以上減少した。10月8日から10日の期間において、A株の主要指数は全線下落しており、特に新業期指数（创业板指）は6.21%も下落した。\nこの暴落の原因の一つは、前期の急速な上昇によるリスクの消化である点に加え、市場が政策に対する期待を調整したこととも関連している。一部の投資家は、政策の効果が短期的に現れていると考えているものの、長期的な効果については引き続き注視する必要があると見ている。さらに、海外市場の変動もA株に影響を与えた。10月9日、恒生指数は9.41%暴落し、A50先物も10.4%暴落したことで、市場の下落が加速した。\n市場の反省と展望 国慶節前後の株式市場における劇的な変動は、政策、経済、市場の規則に対する深刻な反省を市場に引き起こした。一方、政策の短期的な刺激効果は顕著であったが、長期的な効果は依然として観察する必要がある。他方、市場の急速な上昇と下落は、投資家が合理性を保ち、感情的な投資を避けるように促すものとなった。\n将来、A株市場が真の「長牛」行情（長期的な上昇トレンド）を出すことができるかどうかは、政策が実体経済に効果的に伝達され、最終的に経済基本面を改善させる能力にかかっている。投資家は政策の実践状況と経済データの変化を注意深く監視し、合理的な投資戦略を調整する必要がある。\n国慶節前後における株式市場の暴騰と暴落は、政策と市場の博弈であり、投資家の心構えを試すものとなった。この「氷火両重天」（極端な寒暖）の行情の中で、私たちは市場の力を目撃し、政策の影響力を認識した。将来、市場がどのように展開していくのか、今後の動向を見守るだけに終わるだろう。\n","date":"2025-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/long-time-no-see-bull-market-in-stocks/","tags":["株式市場","国慶 (Guóqìng) – This refers to the National Day of China.  A more natural translation would be:\n\n国慶節 (Guóqìngjié) - National Day (holiday)","急激な上昇 (きげきなしょうせい)","暴落 (Bōroku)","政策 (せい策)"],"title":"久しぶりに来る株の荒行 (かろうにくる かぶのあぎょ)","year":"2025"},{"categories":["コンピューター"],"content":"ビジネスモデル：バックエンドサービスがTCPを通じてグループの行情ゲートウェイと接続します。接続ごとに、最初に権限リクエストを送信し、その後継続的にハニーポットパケットを送信して接続状態を維持します。\nしかし、ある日、サービス切断警告の情報を受け取りました。詳細なログ調査の結果、バックエンドサービスは継続的にハニーポットパケットを送信していたにもかかわらず、相手からの応答が一切なく、接続自体が断続的に切断されていました。\n現場要約 当初、社内プロジェクトの進捗をオフィスで作業中に、グループチャットに警報情報がポップアップした。一 glance で見ると、以前からの恒常的な問題だと思い、おそらくネットワークタイムアウトによって心拍送信が失敗し、その結果サービスが切断されたと推測した。しかし、ログの詳細な調査の結果、実際にはそうではなかったことが判明した。バックエンドで権限認証メッセージを送信したが、応答を受信せず、同時に心拍パケットは継続的に送信され続け、相手からは心拍データに対する応答が一切なかった。ログの徹底的な分析により、以下の重要な問題点が明らかになった：\n権限認証メッセージへの応答なし：おそらく相手側のシステムが再起動しており、その結果権限認証メッセージがタイムリーに処理されなかった可能性がある。 権限認証失敗中に心拍パケット送信：調査の結果、これはプログラムロジック上の脆弱性であることが判明した。心拍送信関数の判断ロジックに欠陥があり、接続状態のみを検証し、権限状態の検証を省略していた。 サービスが切断されなかったこと：もしサービスが切断可能であれば、再接続メカニズムをトリガーして権限認証メッセージを再送信することができた。 現在、解決すべき最後の課題は、なぜサービスが切断されなかったのかである。この問題の解決には、より詳細で精緻な調査が必要となる。 ネットワークパケットの分析 tcpdump は非常に強力なネットワークパケットキャプチャツールであり、ネットワークパケットを捕捉するために使用できます。ネットワークパケットを分析することで、通信の詳細をより直感的に理解することができます。ここでは、tcpdump を使用してネットワークパケットをキャプチャし、さらに分析します。 分析図のデータから、心拍が正常に送信され続けていること、相手側のサーバーが応答していないこと、そして ACK が送られていることがわかります。これにより接続は積極的に切断されません。\n共通フラグの説明 TCP プロトコルにおいて、PSH (Push) と ACK (Acknowledgment) は重要なフラグであり、それぞれデータ転送の制御とフロー制御に使用されます。その機能は以下のとおりです。\n1. PSH (Push Flag) 機能: PSH フラグは、受信側がバッファ内のデータを上位のアプリケーションに即時送信するように要求する 役割を持ちます（バッファが満杯で待つのではなく）。 つまり、PSH フラグが付いたデータ段を受信すると、受信側はできるだけ早くそのデータをアプリケーションに処理して送信し、オペレーティングシステムのバッファに一時的に保存することはありません。 典型的なシナリオ: HTTP/HTTPS リクエスト: クライアントがリクエストを送信する際（例: GET /index.html）には PSH が設定され、サーバーから即時の応答を希望します。 SSH プロトコル: 毎回キーボード入力が発生すると PSH がトリガーされ、入力された文字をリアルタイムで転送します。 リアルタイム通信: ビデオストリームやオンラインゲームなど、低遅延のシナリオでは PSH を使用して遅延を減らすことがあります。 注意: PSH は必須ではありません。受信側はフラグを無視することもできます（ただし、データを正常に処理する必要があります）。 送信側が PSH を設定しない場合、受信側は自身のバッファリング戦略に基づいてデータ送信のタイミングを決定します。 2. ACK（Acknowledgment Flag） 機能： ACK フラグは、前段のデータが正しく受信されたことを示す。各 ACK には確認番号（Acknowledgment Number）が含まれており、これは期待される次のバイトのシーケンス番号を表す。TCP の信頼性のある転送の中核メカニズムである。 動作原理： 送信側がデータ段を送信すると、期待する受信側の ACK 値（例えば ACK = シーケンス番号 + データ長）を付加する。 受信側がデータを受信すると、受信したデータのシーケンス番号を確認するための ACK 報文段を生成する。 送信側は、対応する ACK を受信するまで再送を行わない。 例： 送信側がシリアル番号 100～199 のデータ段を送信した場合、期待される受信側の ACK は 200 になる。 受信側が 100～199 内の特定のデータを受信しない場合、ACK=150 を通じて送信側に再送を通知する。 3. PSH と ACK の組み合わせ TCP 報文において、PSH (Push) と ACK (確認応答) は同時に出現することがあり、以下のようなシナリオでよく見られます。\nHTTP リクエスト応答：\nクライアントが POST リクエスト（データを含む）を送信する際、PSH と ACK を設定し、前の応答の確認を行います。 SSH ハンドシェイク後のコマンド転送：\nクライアントがコマンドを入力した後、PSH と ACK が付いたデータ段を送信することで、コマンドが即座にサーバーで処理されるようにします。 4. その他の関連を示すフラグ フラグ 名前 概要 SYN シーケンス 接続の初期化 (3ウェイハンドシェイク) 4. その他の重要な関連 標識 名称 概要 FIN 終了 エレガントな接続のクローズ 4. その他の関連を示すフラグ フラグ 名前 概要 RST リセット 接続の強制終了 (異常状況) 4. その他の重要な関連 標識 名称 概要 URG 緊急 緊急ポインタのマーク (ほとんど使用されない) 4. その他の関連要素 まとめ PSH は、データのアプリケーション層への迅速な到達 と遅延の低減に焦点を当てています。 ACK は、データの信頼性の高い伝送 とパケットロスや乱数（順不同）を防ぐことに焦点を当てています。 両者は連携して、TCP プロトコルの効率性と信頼性をバランスしています。 ","date":"2025-02-14","language":"ja","permalink":"https://ttf248.life/ja/p/backend-service-tcp-communication-troubleshooting/","tags":["トラブルシューティング","TCP","ネットワーク通信"],"title":"バックエンドサービス TCP 通信異常トラブルシューティング","year":"2025"},{"categories":["投資 (tōshi)"],"content":"数年間の株式投資の経験を振り返ると、大金を稼げなかったものの、大きな損失も出せなかった。最大の問題は、資金の流れが不合理であり、精神状態が不安定だったことだ。現在の段階では、主な収入源は仕事で、毎日労働によって固定給を得ており、お金の変化に対する耐性は債券や銀行預金といったものに留まっている。しかし、人は欲を持つものであり、仕入れを少なくすれば株価が上昇しても利益を得られないし、仕入れを多くすれば株価が下落して損失を被る。このような状況では、精神状態の安定が非常に重要であり、それは富を守るための助けとなるだろう。\n過去の損失事例 新規参入時を除いて、小盤株や次新株に触れる機会があり、その後は主に大型株や大口指数ファンドに投資しました：工商銀行、中国連通、恒生電子、中興通信など、様々な大型株指数ファンド。\nブルーチー（老钱）と呼ばれる安定した株と組み合わせることで利益を出す戦略です：\n恒大の問題が発生した際、銀行株が暴落し、経済全体の景観に対する認識に欠けていたため、早期に市場から撤退することができました。この状況は、不動産が中国経済における割合が高いため、関連するリスクを考慮できず、最終的に「強制破綻」という形で株価が下落しました。その後、工商銀行のような優良株は2年間ほど上昇しました。\n貿易戦の初期段階で、中興通信が大きな打撃を受け、株価も大幅に下落しましたが、その後徐々に回復しました。\n恒生電子は長年投資してきた銘柄であり、アリババ（蚂蚁金服）が退任した後も株価は大幅に下落しましたが、この株式には強力な庄家が存在し、毎年何度か株価を押し上げる操作を行うことができました。適切なポジションサイズを維持することで、大きな損失を被ることはありませんでした。\n債券投資 どうでしょうか、これも利率下落の周期を拾ったと言えるでしょう。杭州での仕事に変動があり、住宅購入の計画を放棄し、手元にあった債権はすでに銀行の定期預金で配置しており、以前投資していた債券に注目し、債券への投資比率を大幅に増やしました。ちょうどこの数年間の利率が下落しており、債券の牛市（利回り上昇の時期）に乗ることができました。\n帰省した杭州での半年の仕事では、多くのことを停滞して考え、家は必ずしも購入する必要はなく、海外で働く必要性もないこと、自身の耐圧能力もそれに伴い変化すること、失業した場合の住宅ローンが山のように積み重なることを改めて認識しました。\n投資収益期待 「3年定期預金の対標を口头上には喊着（言っている）が、実際は貪心を持ってさらに多く欲しいと考えており、最初からポジションを増やすことに焦り、その後キャッシュフローが枯渇してしまう。」 保険の購入、住宅ローン、結婚など、資金の大頭となるものは全て、全体的な計画において十分なキャッシュフローを残していないため、その後のキャッシュフロー不足につながる。\n今後の計画は長期保有する券商ETFと恒生科技指数であり、資産全体の配分としては、保険を底仓（ベース）、中長期的債券、そして株式ファンドである。\n","date":"2025-02-14","language":"ja","permalink":"https://ttf248.life/ja/p/investing-takes-time/","tags":["投資 (tōshi)","株式投資 (Kaibu Tōshi)","心境 (しんけい) / 精神狀態 (せいしんとうぜい)","富 (と)"],"title":"投資して儲けるというのは、急がないと意味がない。焦っても無駄だ。","year":"2025"},{"categories":["AI霊感衝突坊"],"content":"最も初期のネット文学読者が中年になってくると、彼らに向けた爽快な物語も変化してくる。主人公は父親、師匠、あるいは高齢者といった存在が多く登場し、中年の読者のライフと感情に対する異なるニーズに応えるように変化した。このような作品は、レベルアップや逆転劇を追求するだけでなく、感情的な共鳴や人生の洞察に重点を置くようになった。\nターゲットユーザー：歳月を重ねる読者層の変遷 かつてのネット文学（ウェブ小説）の読者は、現在ほとんどが中年へと年齢を重ねています。彼らは人生経験を通して心の鍛錬を受け、価値観や考え方が変化しました。若き頃に熱狂的に支持した熱血（情熱）、冒険などの要素が唯一の追求ではなくなったのです。彼らは読書を通じて、自分自身の現在の生活状況と感情的な共鳴、そして過去の歳月への回想、未来への期待といったものを求めるようになっています。中年爽文は、まさにこのような心理的ニーズに基づき生まれたものであり、より中年人の生活や考え方に近いプロット設定によって、この特定の読者層を引きつけています。\n役割の変化：少年英雄から中年担当 私の弟子は皆大悪役：主人公陸州が師匠となることで、直面するのは個性豊かで実力も卓越した弟子たち。彼らは正義と邪悪の間で揺れ動き、陸州は彼らを正しい道へと導く必要がある。この小説は、主人公と弟子の間の交流を通して、中年人が後輩を教え導く際に直面する課題や戸惑いを浮き彫りにしている。また、弟子たちの成長と変化は読者に希望と未来を示唆し、子どもや若年層に対する自身の期待を反映しているかのようだ。\n感情共鳴：人生感悟と家庭責任 六十歳の誕生日システム：主人公は六十歳の誕生日にシステムを入手し、新たな人生の旅路を歩み始めます。この設定により、中年読者は「まだ間に合う」という希望と励ましを感じることができます。すでに晩年を迎えていますが、主人公はシステムを通して自身の価値や夢を実現することができます。このプロットは読者に、人生で失った機会や未達成の夢を想起させながら、積極的な生き方の態度を伝え、いつでも夢を追い続けることを奨励します。\nプロット設計：中年生活のリズムと趣味に寄り添う 中年爽文のプロット設計は、より生活の詳細や感情の繊細な表現に重点を置く傾向があります。若い頃の爽文のように、急速なレベルアップや冒険を追求するのではなく、登場人物間の関係性と感情的な葛藤を描写することに注力します。『史上最强师傅』のような作品では、主人公と弟子との師弟情誼、同門との兄弟情など、細やかに描写されています。このようなプロット設計は、中年読者に温かさや親しみを感じさせ、自分自身の家族愛、友情、恋愛といった生活を想起させるような感覚を与えます。\n","date":"2025-02-13","language":"ja","permalink":"https://ttf248.life/ja/p/years-of-settling-alternative-fantasy-and-emotional-attachment/","tags":["小説","サスペンス小説","中年人 (chūnnen-nin)","父愛 (Chichi Ai)","師徒"],"title":"時の流れに沿った異端な幻想と感情の拠り所","year":"2025"},{"categories":["コンピューター"],"content":"Ollamaは、大規模言語モデル（LLM）をローカルで実行およびデプロイすることを目的としたオープンソースのAIツールです。クラウドサービスへの依存なしに、開発者がローカルマシン上でGPTのようなモデルを使用するための簡単なかつ効率的な方法を提供することを目指しています。Ollamaは複数のモデルに対応し、パフォーマンスを最適化することで、リソースが限られたデバイスでもこれらのモデルをスムーズに実行できるように設計されています。\nOllamaを使用すると、ユーザーはテキストベースのAIアプリケーションを利用でき、ローカルでデプロイされたモデルとインタラクトすることができ、データプライバシーやAPIの使用料金に関する懸念なく、自然言語処理や質問応答などのタスクを実行できます。コマンドラインインターフェース（CLI）を通じて異なるモデルを呼び出し、これらのタスクを実行できます。\nollamaは様々なモデルを試すのに適しており、Windows版のテストではハードウェアの性能を十分に発揮できなかった可能性があります。これはWindows版の問題かもしれません。Linux版の方が良い結果が得られる可能性があります。32bパラメータのモデルをデプロイし、メモリとGPU負荷が低い場合に、応答速度が遅いことが確認されました。\nハードウェア概要 オペレーティングシステム: Windows 11 CPU: i7-10700K メモリ: 40GB グラフィックカード: RTX 3060 12GB 環境準備 以下のシステム環境変数を設定し、後続の使用を容易にします：\nset OLLAMA_MODELS=E:\\ollama この変数で Ollama モデルの保存場所を指定します。 E:\\ollama はフォルダパスであり、ダウンロードまたはデプロイしたローカルモデルファイルをすべてここに格納します。Ollama はこのパスに基づいてモデルをロードおよび使用します。モデルファイルの保存場所を変更する場合は、このパスを更新してください。\nset OLLAMA_HOST=127.0.0.1:8000 Ollama サービスのホストとポートを設定します。\n127.0.0.1 はローカルアドレス（localhost）であり、Ollama サービスは本機からのリクエストのみを待ち受けます。 8000 は指定するポート番号であり、Ollama サービスが 8000 ポートでリクエストを受信および処理します。必要に応じてポート番号を変更できますが、他のアプリケーションで使用されていないことを確認してください。 set OLLAMA_ORIGINS=* Ollama サービスへのアクセスを許可するオリジン（ソース）を制御します。\n* はすべてのオリジン（つまり、すべてのドメインと IP アドレス）が Ollama サービスにアクセスできることを意味します。これは通常、開発およびデバッグ環境で使用されます。本番環境では、セキュリティを高めるために、特定のドメインまたは IP アドレスのみを許可するようにより厳格なオリジン制御を設定することが一般的です。 DeepSeek-R1 モデルのデプロイ ollama のインストールは、初心者向けで簡単なため、詳細は省略します。 インストール後の検証：\nC:\\Users\\core\u0026gt;ollama -v ollama version is 0.5.11 モデルのデプロイについては、公式ウェブサイトのモデルページを参照し、対応するパラメータのモデルを選択してください: ollama run deepseek-r1:14b 14b パラメータは会話コンテキストを効果的に記憶でき、より小さなパラメータバージョンではコンテキストを記憶できません。32b パラメータバージョンは、ローカルでのデプロイ時に非常に遅延するため、詳細なテストは行っていません。\n参考文献 https://www.ollama.com/library/deepseek-r1 https://mp.weixin.qq.com/s/SPEvYTmTBxhoEkJqm1yPmw https://blog.csdn.net/x18990027/article/details/145368094 ","date":"2025-02-07","language":"ja","permalink":"https://ttf248.life/ja/p/ollama-local-deployment-deepseek-r1/","tags":["ollama","deepseek","ai"],"title":"ollama ローカル実行 deepseek-R1","year":"2025"},{"categories":["コンピューター"],"content":"Linux で使慣れた zsh を、昨日ブログを書いている時に、突然 PowerShell 7 もセッション保持設定でコマンド履歴予測ビューをサポートしていることを発見し、試しに触ってみたら、意外と便利だった。\n何が原因かはわからないけど、何か操作をしてこの機能を起動しただけで、それで終わり。\n現在多様化するオペレーティング環境において、システム管理者や開発者は、プラットフォーム間での互換性、効率性、そして強力な機能を備えたツールを求めています。PowerShell 7 はまさにそのニーズに応える注目を集めているツールです。強力なスクリプト作成能力に加え、Windows、Linux、macOS など様々なオペレーティングシステム上で動作するため、ユーザーに前例のない利便性をもたらします。\nPowerShell 7：クロスプラットフォームな強力なツール クロスプラットフォーム特性 PowerShell 7は、プラットフォームの制限を打破し、Windowsシステムでのエンタープライズレベルのサーバー管理、Linux環境でのシステム運用、macOSでの日常開発タスクなど、あらゆる環境で一貫してPowerShell 7ツールを使用できます。これにより、作業効率が大幅に向上し、プラットフォームの違いによる学習コストや操作複雑性の問題を軽減します。\n強力な機能 強力なスクリプト作成能力を備え、オブジェクト指向プログラミング、関数、モジュールなどの高度なプログラミング特性をサポートします。PowerShell 7 を通じて、ユーザーはファイルシステムを簡単に操作し、ファイルやフォルダの作成、削除、コピー、移動などの操作を実行できます。レジストリにアクセスして変更することで、システムの構成を深く調整することも可能です。プロセスとサービスを管理し、システムの状態を効果的に監視および制御することもできます。さらに、PowerShell 7 は、Active Directory におけるユーザーと権限の管理や、Azure クラウドプラットフォームにおけるリソースの配分と管理など、さまざまな Windows および非 Windows 技術との相互作用も可能です。\nオープンソースエコシステム PowerShell 7はオープンソースであり、この特性により、世界中の開発者や愛好家がその開発と改善に積極的に参加できるようになっています。大量のオープンソースモジュールやツールが継続的に登場し、PowerShell 7 の機能と応用シナリオを豊かにしています。ユーザーは自分のニーズに応じて、オープンソースコミュニティで適切なモジュールを見つけて PowerShell 7 の機能を拡張したり、自身のコードを貢献してコミュニティ全体の発展を推進したりすることができます。\n互換性と安定性 PowerShell 7は、旧バージョンのPowerShellとの互換性を維持しながら、多くの新機能と改善を導入しました。これらの改善により、パフォーマンスが向上し、安定性が強化され、ユーザーはさまざまなタスクをよりスムーズに実行でき、ソフトウェアの故障による作業中断を減らすことができます。\nコマンドレット予測ビューの起動 PowerShell 7 の多くの便利な機能の中で、Set-PSReadLineOption -PredictionViewStyle ListView コマンドは、ユーザーのコマンドライン入力体験を向上させるための実用的なツールです。\nコマンドを実行しなくても自動補完を実現できますが、これは行内での補完に限定されます。この機能を有効にすると、リスト形式で可能なすべての補完オプションを表示する予測ビューが利用できるようになり、ユーザーは上下キーを使用して必要なオプションを選択することで、コマンド入力の正確性と効率を向上させることができます。\nコマンドを永続化する方法 Set-PSReadLineOption -PredictionViewStyle ListView のようなコマンドを、PowerShellの起動時に常に有効にするには、それを PowerShell の設定ファイルに追加します。PowerShellの設定ファイルは、PowerShell が起動される際に自動的に実行する命令を含む特別なスクリプトです。\n設定ファイルのパスを特定する PowerShell では、$PROFILE 変数を使用して設定ファイルのパスを確認できます。もしこのパスにファイルが存在しない場合は、ユーザーは手動で作成することができます。\necho $PROFILE 設定ファイルのオープン テキストエディタ（例えば、高機能な Notepad++ や軽量の Visual Studio Code）を使用して、$PROFILE 変数で取得した設定ファイルパスに対応するファイルを開きます。\nコマンドの追加 開いている構成ファイルに、Set-PSReadLineOption -PredictionViewStyle ListView コマンドを追加します。コマンドの記述が正確であることを確認し、構成ファイルを実行する際に正しく有効になるようにしてください。\n構成ファイルへの保存 コマンドの追加が完了したら、構成ファイルを保存しテキストエディタを閉じます。これにより、構成ファイルには、PowerShell起動時に実行したいと希望するコマンドが含まれるようになります。\n検証設定 現在の PowerShell ウィンドウを閉じ、PowerShell を再起動します。 新しく起動した PowerShell でコマンドを入力する際、コマンドラインでの予測ビュースタイルの表示が、当方の設定に従いリスト形式で表示されることを確認します。 これにより、当方の設定が正常に適用されたことを示します。 上記の手順を実行することで、PowerShell 7 の強力な機能と特性についてより深く理解し、コマンドラインでの予測ビュースタイルの設定方法を習得するとともに、これらの設定を永続的に適用する方法も学びます。 これらの知識が、PowerShell 7 を使用する際に、よりスムーズかつ効率的に様々なシステム管理および自動化タスクを完了できるようになることを願っています。\n参考資料 https://github.com/PowerShell/PowerShell/releases https://www.v2ex.com/t/911909 ","date":"2025-02-07","language":"ja","permalink":"https://ttf248.life/ja/p/powershell-7-persisting-settings-commandline-prediction-view/","tags":["windows","powershell"],"title":"PowerShell 7 と Persistence 設定 コマンドライン予測ビュー","year":"2025"},{"categories":["転載 (tenzai)"],"content":" 株式市場の継続的な上昇トレンド（バブル）は、アメリカ本国の「硬直化された強み」を無視し、ドルの大規模な供給が主な要因である。 現代貨幣制度は、2008年の金融危機の後、世界中の複数の経済体にとって、默認で重要な理論的基盤となりつつある。その特徴は、政府による市場介入の主観的な積極性を強調し、政府財政赤字を主要なツールとして利用し、市場における完全雇用とインフレの安定を実現することにある。 大政府とは、一般的にケインズ主義を指し、景気変動において「ピークを抑え、谷を埋める」役割を重視する。例えば、過熱した時期には抑制し、収縮した時期には刺激するなど、政府支出の乘数効果（同じ金額の政府支出が、消費全体のどれだけを拡大させるか）に注目し、政府支出1に対して企業や個人が追加で増やす収入を計算する。これにより、経済の落ち込みを食い止め、回復を促す。同時に、財政赤字の上限と持続可能性については比較的保守的な見方を取り、消費乘数を通じて市場を回復させ、結果として政府の収入が増加する。特に、経済が過熱している時期には、次の景気循環のための刺激資金を蓄え、例えば、政府債の発行余地や金利水準を活用する。 現代貨幣制度は、ケインズ主義の極端な延伸と言えるが、いくつかの違いもある。最大の点は、政府債務に対する制限がないことである。中央銀行は独立性を持ち続けず、主な目標はインフレと完全雇用であり、限られた資源と生産力に対して、政府は無制限の財政赤字を通じて市場に購買力を供給し、理想的な完全雇用と生産性のボトルネックを達成するまで、継続的に増量していく。この段階でさらに通貨が増加するとインフレを引き起こすため、財政赤字の上限を設定する。ただし、市場にまだ余剰な生産手段が存在すれば、政府は赤字を拡大し続けることができる。\n金融危機後 もちろん現実には理想の世界ではない。各段階の実行は人に関与しており、ケインズ主義も選択的に適用されるため、その結果は景気の下落を刺激するものが多く、景気の過熱を抑制するものが少ない。経済的な差が刺激をもたらし、過熱も政党の成果となるため、根本的に抑制することが難しく、もたらされた多くの経済的問題、新たな金融危機は従来の生産能力過多による経済的衝撃ほどではない。2008年の世界的な金融危機は、まさにケインズ主義の下での市場の自己強化の結果であるバブルであり、不動産や不動産を基盤とする金融投資商品など、多数の派生構造金融投資品が登場した。危機が勃発する以前に、学界、政界、市場レベルにおいてリスク認識が不足しており、債務で支える繁栄を政党の成果とみなし、より多くの利益を得た。例えば、巨大な金融システムは、損失はあなたのもの、配当は私たちのもの、破産は当然、十分に儲けた。お金は吐き出すことはできない。最終的に大量の参加者が先行者の各段階の収益を負担することになった。\nこのとき現代貨幣体系の影が金融危機後に入り、典型的な特徴は急速な財政赤字のモノジ化と中央銀行による無限量の量的緩和、そしていわゆる緊急中央銀行融資政策である。中央銀行が最終的な貸し手として無限に弾を供給し、政府も継続的に債務を抱えることができる。中央銀行は国債の購入を通じて政府財政赤字支出を支援し、政策目標の一致性を確保することもある。これが現代の金融政策と財政政策の境界線がますます曖昧になっている理由である。基礎貨幣投下に関しては、中央銀行が直接国債の購入に関与することを強く依存している。左手で紙幣を発行し、右手で花を咲かせる。\nユーロ圏と米国は類似した状況を示している。2008年、欧州連合の政府債務は約67兆ユーロ、政府レバレッジ率は約66％で、一般的に認識されている警戒線である60％よりもわずかに高い。2014年、つまり救済5年の時点で、債務規模は95兆ユーロに達し、レバレッジ率は93%となった。米国はさらに誇張されており、2008年に米政府債務は約10兆ドルで、2014年には約18兆ドルに達し、最近では再び政府債務上限を打ち出している。もちろん、毎回のアすなわち政府停滞を噱頭にしており、毎回債務限度を超えるが、現在36兆ドルの突破まで拡大しており、GDP成長の要因を考慮すると、政府レバレッジは60%から120％以上に増加した。連邦準備制度理事会（FRB）は最終的な貸し手として、何度も救済において重要な役割を果たし、政府債務の主要な購入者の一人でもある。\n現代貨幣体系の弊端と限界 この政府主導の経済刺激策は、計画経済とは言えないものの、直面する問題は一貫しており、市場の全知全能性とあらゆる环节参与者の無私無畏をどのように保証できるのか？ 最もシンプルな例として、政府部門が特定の方向に予算100万ドルを追加した場合、それは上司の小甥に与えられるのか、それともよりコスト効率の高いオークションに参加させるのか？ もちろん現実には、より複雑な形で利益の輸送が生じ、結果として政府は負債と支出を拡大させながらも、完全に制御不能な方向に流れる。最近アメリカで騒がれている政府効率部門の設立は、まさにこうした問題の延伸である。もちろんこれらのことは、異なる腐敗指数経済体において、その表现は一様ではない。私たちがより議論すべきは、普遍的な問題である。\n1. インフレーションの問題 現代の情報ネットワークの発展に伴い、政府が市場情報の掌握程度は過去に比べて著しく向上したが、全知全能ではないため、市場自体には変動があり、市場は常に期待によって変化し、ループ構造に入ることが予想される。私はあなたの予測を予測する。実態での例を挙げると、2008年～2020年の間に、現代貨幣理論の実践的な成果は目覚ましく、短期的に経済の回復とインフレーションの安定を実現したものの、ユーロ圏では段階的なデフレ問題が発生し、アメリカでもインフレーションは概ね1～3%という予測範囲内に維持されたため、人々は過去のようにケインズ主義を信じるようになった。\n実際には、2008年以降も発展途上国の製造業が引き続き高い成長傾向を示しており、例えば、この期間中に世界の生産地位を確立した我が国や、それに続く東南アジアおよびインドなどの経済体も、製造業の付加価値を維持していたため、現代貨幣理論における最大の制約である資源供給の制約を打ち消し、欧米は産業減少と過剰な金融化下でも、政府債務と通貨供給の急増を背景に、比較的安定したインフレーションを維持することができた。\nしかし、2020年以降、より大規模な景気刺激策の使用により、ユーロ圏およびアメリカで顕著なインフレが発生し、ピーク時にはそれぞれ10%程度まで上昇したが、現在でも利上げ3年近く経っても、アメリカの雇用市場は異常に過熱した状態が続いており、金融市場は通貨の支えの下で経済成長を上回る過剰な繁栄を示しており、基数効果が消失すると、アメリカのインフレは再び3%に向かって加速している。このような利上げ中の過熱状態は、財政赤字と密接に関連しており、利上げは金融政策における収縮であり、財政政策においては依然として拡大しており、2020年の超大規模な通貨投機を組み合わせることで、アメリカのインフレは異常に頑固になっている。現代貨幣理論最大の制約は、インフレーションが高止まりすることである。\n2. 政府債務問題 原則上、政府は債務で財政を賄う（以債養債）ことは可能ですが、その前提は中央銀行が完全に傀儡となること、すなわち現代貨幣体系における財政政策と金融政策の目標一致性です。これは、連邦準備制度（美聯儲）が政府に完全な権限を委譲する用意がないという事実に照らし合わせると、長らく積み上がってきた政府債務残高、特に利息支出が、財政にとって巨大な負担となっている現状と合致します。\n2023财年：アメリカの2023财年の财政收入は44390億ドルで、その際の债务利息支出は财政收入の約15%を占めました。2024年も高金利の状態が継続し、米国財務省発表のデータによると…\n2024财年：アメリカ連邦政府の財政赤字は1兆833億ドルに達し、債務利息支出は8820億ドルで、これはアメリカ連邦収入の約18%を占めます。さらに、社会保障支出を上回る水準です。\nこれが財政の持続可能性の問題であり、長期的に低金利、低インフレ、高債務（例えば日本）が維持されれば、現代貨幣理論に基づいた「72ルール」に従い、利息が十分に低い場合、債務で財政を賄うことは緩やかな増長に繋がります。しかし、もしインフレーションによってこの微妙なバランスが崩れれば、債務の利息支出と累積が進み、複利効果により将来の債務は制御不能となり、本金よりも利息が主要な要因となる可能性があります。中央銀行が再び政府の目標と一致しない場合、この問題はさらに深刻化します。また、トランプ政権の政治的主張は、現在の連邦準備制度（美聯儲）の鷹派的な姿勢とは対照的であり、これがこの任期内におけるアメリカ政府と連邦準備制度（美聯儲）の関係激化の重要な要因となりました。現在主席が任期を終えることができるかどうかは、世論の関心の中心となっています。\n3. 金融バブルと貨幣信用問題 理想的には、政府が拡大した支出が家計および企業部門に流入し、皆が支出を拡大することで有効需要が増加しますが、皆さんは2000年以来の多くの金融バブルの第一人者であるため、投資と消費の選択において、大きな資産価値上昇の傾向が見られ、特に高い資産価値を期待できる商品が存在する場合、皆さんは一斉に金融市場でより高い資産価値を求めて集まり、生活水準の圧縮やレバレッジをかけて乗ることも厭わないでしょう。これは、日本の不動産高成長期、アメリカ、そして我が国の不動産高成長期でも同様の現象でした。政策的な刺激と、業者の自己利益最大化への追求、次級ローンなどの問題が多発し、多くの「救済措置」は実際には借金を促すものでした。\n歴史的経緯から見て、貨幣政策と財政政策が大規模に展開されると、常に資産バブルと富の再分配の狂騒が発生します。資産バブルが先行し、富の再分配が後を追うため、別の問題が生じます。それは、極端なケインズ主義または現代貨幣理論で頻繁に使われる経済的ピラミッド（ミン스키時間）です。熱錢があれば資産価格は継続的に上昇し、それが続けば後から来る人々が持ちお金をしてきます。物価指数（CPI）のような生活費の変化を測るものは変化せず、お金が特定の分野で空回りし、後から来る人々は無力化されます。狂騒の後に破綻が訪れます。それはミンスキー時間における裁きであり、屡々的中しています。\nさらに、貨幣自体にも需給の関係があります。市場供給が過剰になると、従来の投資品では容認できなくなったり、資金を集められなくなる場合（例えば、何度も崩壊した不動産バブルのように、日本人は数十年にわたって不動産投資に足を踏み入れない）、税制などの政策による抑制、不動産保有税を導入して投機需要を減らすことは、金融投機のコストを高めます。そのため、貨幣供給過剰の土壌においては、資金を集め、課税がかからない投資品が急増します。仮想投資商品も次々と登場し、アメリカ大統領夫妻もその一角を占める始末です。ある見方では、ドル圏を狭めることですが、実際には世界的な通貨供給過剰と金融空転下における法定通貨の信用低下は必然の結果です。現代貨測理論が最も依存している国家の独占的権利に基づく信用通貨地位さえも、挑戦を受ける可能性があります。どのような土壌かによって、どのような金融ゲームが生まれるのか。\nまとめると、現代貨幣理論とケインズ主義は、より一層の介入と市場への関与を重視し、財政赤字や中央銀行の独立性に対する姿勢がより強硬であるという点で、一種の段階的・代替関係と言えます。ケインズ主義の過剰な使用は、デフレーションと金融危機をもたらし、人工的な経済過熱からの解消には、現代貨幣理論が2008年以降に受け継ぎました。経済グローバル化下で生産性が向上しているため、短期的に成長を回復させ、インフレ率を維持しましたが、同時に大量の政府債務と金融バブルも蓄積しました。インフレが反騰し、中央銀行と政府の目標が一致しない場合、金利が高く、レバレッジも高ければ、政府財政負担はさらに増大し、財政持続可能性が大幅に低下します。また、過剰な政府介入による基礎貨幣供給は金融バブルを招き、通貨自体の信用を削弱します。見かけ上はドルが強そうに見えますが、それは他者へのごまかしであり、巨額の投資需要が土壌となり、様々な新しい金融投資投機ツールが生み出され、従来の金融投資品に対する税制上の制限から逃れることもあります。これは世界の縮図です。現代貨幣理論は未来ではなく、2008年以降使い始めた過去式であり、逆グローバル化と組み合わさることで、過去の金融バブルが大きくなるほど、政府債務が増え、金融投機ツールが狂騒的になり、富の歪んだ分配を達成する効率が高まるほど、将来的にハードランディングのリスクは大きくなります。経済的・社会的リスクを含み、ケインズ主義であろうと現代貨幣理論であろうと、貨幣供給が多ければ、富の構造問題を解決することは\n","date":"2025-02-06","language":"ja","permalink":"https://ttf248.life/ja/p/modern-monetary-theory-future-global-economy/","tags":["金融危機","現代貨幣理論 (Gendai Kakumei Riron)","財政政策","貨幣政策 (Kagiin seisaku)","インフレーション (Infureishon)","政府債務 (Seifu Chaiyū)","金融バブル (Kin'yū baburu)","貨幣信用"],"title":"現代貨幣理論は、世界の経済体の未来なのでしょうか？","year":"2025"},{"categories":["金融知識データベース"],"content":"外国為替市場、特に銀行や両替所で「買入換率」と「売出換率」といった用語をよく目にするでしょう。これらの概念について、多くの人は理解できていないか、あるいは混同しているかもしれません。そこで、ここでは簡単な例を通して、この2つの換率の意味と、それらがどのように機能するのかを解説します。\n1. 「買入相場」と「売出相場」とは何か？ 買入相場：銀行や外貨交換機関がこのレートで外国為替を購入する意思があるという意味です。つまり、あなたが外国為替（例えば米ドル）を銀行に売ると、銀行はあなたの元気を「買入相場」のレートで支払ってくれます。 売出相場：銀行や外貨交換機関がこのレートで外国為替を販売する意思があるという意味です。つまり、あなたが円を使って外国為替を購入すると、銀行は「売出相場」のレートであなたに外国為替を売ります。 簡単に言うと：\n買入相場：銀行があなたの手から外国為替を買う価格。 売出相場：銀行が外国為替をあなたに売る価格。 注意点として、銀行の買入相場と売出相場は通常異なり、「売出相場」は「買入相場」よりも高い傾向があります。この差額が銀行の利益源です。\n2. 具体事例分析 両方の為替レートの実用例をより明確に理解するために、具体的な事例を見ていきましょう。 例えば、銀行でドルを両替する場合、銀行が提示する為替レートは以下の通りです。\n買いレート：1ドル = 7.0元 売りレート：1ドル = 7.2元 シナリオ１：あなたはドルを銀行に売る あなたが持っている1000ドルの価値を、銀行が購入レートで計算します。 \\[ 1000 \\, \\text{ドル} \\times 7.0 \\, \\text{元/ドル} = 7000 \\, \\text{元} \\] つまり、銀行はあなたに7000元を支払うことになります。このレートは購入レートであり、あなたはドルを銀行に売っているためです。\nシナリオ２：お札をドルで買う あなたが手元に7000元（人民元）があり、それをドルに換算したいとします。銀行は売却レートに基づいて計算を行います。\n\\[ 7000 \\, \\text{元} \\div 7.2 \\, \\text{元/ドル} = 972.22 \\, \\text{ドル} \\]この場合、7000元で約972.22ドルを手に入れることができます。ここでいう為替レートは売方向の為替レートであり、あなたは銀行からドルを買っているためです。\n3. 円安・円高の理由とは？ あなたは、銀行の買いレート（7.0元/ドル）が売りレート（7.2元/ドル）よりも低いことに気づいただろう。これは、銀行が外貨取引を行う際、このレート差を利用して利益を得るためである。言い換えれば、銀行はより高い売りレートとより低い買いレートの間の差額を徴収することで利益を上げるのだ。\n例えば、上記のケースでは、その差額は以下の通りである：\n\\[ \\text{売りレート}（7.2） - \\text{買いレート}（7.0） = 0.2 \\, \\text{元} \\]この差額が銀行の利益源となっている。\n4. まとめ 買入相場（かいゆうまえが）：銀行はこのレートであなたから外国為替（あなたがお売りする外国通貨のレートと同じ）を買います。（あなたがお買いする外国通貨のレートと同じ） 売出相場（うつしょうば）：銀行はこのレートであなたに外国為替を売ります。（あなたがお買いする外国通貨のレートと同じ） 相場差（そうばさ）：買入相場と売出相場との間の差額が銀行の利益源です。 この2つのレートの概念について理解できたなら、外貨両替を行う際に、自分がどれだけの外国為替を受け取ることになるのか、あるいはどれだけの人民元で外国為替を買うことができるのかをより明確に知ることができます。この簡単な例が、皆さんが外貨レートの基本的な原理をより良く理解するのに役立つことを願っています！\n","date":"2025-02-06","language":"ja","permalink":"https://ttf248.life/ja/p/understanding-buy-and-sell-exchange-rates/","tags":["為替レート","外国為替 (がいこくわいふ)"],"title":"為替レートにおける「買直定価」と「売直定価」の理解","year":"2025"},{"categories":["コンピューター"],"content":"WindowsでVisual Studioを使ってプログラムをデバッグする場合、PDBファイルと実行可能ファイルが一致しない場合、Visual Studioは「シンボルファイルを読み込めません」というエラーを表示します。プログラムの実行中にクラッシュが発生し、ダンプファイルが生成される場合、不一致なPDBファイルの場合、Visual Studioはクラッシュ現場にスムーズに入ることができません。\nPDB ファイルとは PDB ファイルは、Microsoft が提供するデバッグ情報ファイルで、プログラムのデバッグに使用されます。PDB ファイルには、シンボルテーブル、ソースコード名、行番号などの情報が含まれています。プログラムをコンパイルするときに PDB ファイルが生成され、プログラムのデバッグに使用されます。\nWinDbg デバッグ WinDbg は Microsoft 製のデバッガで、Windows プログラムをデバッグするために使用されます。WinDbg は不一致な PDB ファイルをロードできますが、手動でロードする必要があります。.reload /f /i コマンドを使用して、強制的に不一致な PDB ファイルをロードできます。 しかし、WinDbg の使い勝手は Visual Studio ほど簡単ではないため、Visual Studio も不一致な PDB ファイルをロードできるようにしたいと考えています。\nVisual Studio での PDB ファイルのマッチングエラー ソースコードは現在、Git などのバージョン管理システムで管理されており、完全に一致するバージョンのコードを再コンパイルし、対応する PDB ファイルを生成できます。なぜこの PDB ファイルが読み込まれないのでしょうか？主な原因は、メタデータの不一致です。\n元データを修正し、EXE ファイルの情報に基づいて新しい PDB ファイルを生成することで、Visual Studio が PDB ファイルを読み込めるようになります。\nChkMatch ダウンロード先：https://www.debuginfo.com/tools/chkmatch.html サイトのキャッシュアドレス：chkmatch.zip\nChkMatch ユーティリティは、実行ファイルとデバッグ情報ファイルの間のマッチングを確認するために使用できます。また、互換性のある実行ファイルとデバッグ情報ファイルをマッチさせるために使用することもできます。 デバッグ情報のマッチングに関する詳細情報や関連する問題については、こちらの記事を参照してください。 サポートされているデバッグ情報形式：DBG, PDB 2.0, PDB 7.0 chkmatch [-c ExeFile DebugInfoFile ] | [-m ExeFile DebugInfoFile] -c 実行ファイルとデバッグ情報ファイルの間のマッチングを確認します。 -m 実行ファイルとデバッグ情報ファイルをマッチさせます。 ExeFile 実行ファイルの名前。 DebugInfoFile デバッグ情報ファイルの名前。 chkmatch の使用 まず、検査を実行し、不一致の原因を分析して、署名が一致しないことを示します。\nC:\\Users\\tianlong.xiang\\Downloads\\chkmatch\u0026gt;ChkMatch.exe -c \u0026#34;D:\\Program Files\\Rolan\\trade\\UAT_YinStrade\\YinTrade.Main.exe\u0026#34; E:\\YinTech\\ykcz_securities_trading_client\\Sec_Trade\\YinTrade.Main\\bin\\Release\\YinTrade.Main.pdb ChkMatch - version 1.0 Copyright (C) 2004 Oleg Starodumov http://www.debuginfo.com/ Executable: D:\\Program Files\\Rolan\\trade\\UAT_YinStrade\\YinTrade.Main.exe Debug info file: E:\\YinTech\\ykcz_securities_trading_client\\Sec_Trade\\YinTrade.Main\\bin\\Release\\YinTrade.Main.pdb Executable: TimeDateStamp: c26d9be3 Debug info: 2 ( CodeView ) TimeStamp: f86b0a4f Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 122 RVA: 001cdc44 FileOffset: 001cbe44 CodeView format: RSDS Signature: {428c9b95-39a3-4a8d-a8e5-7be453684757} Age: 1 PdbFile: D:\\stock_UAT\\ykcz_securities_trading_client\\Sec_Trade\\YinTrade.Main\\obj\\Release\\YinTrade.Main.pdb Debug info: 16 ( Unknown ) TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 0 RVA: 00000000 FileOffset: 00000000 Debug information file: Format: PDB 7.00 Signature: {06fae08e-c0a2-4f3d-9c7c-dfc684445dd1} Age: 1 Result: Unmatched (reason: Signature mismatch) 次に、デバッグ情報ファイルと実行可能ファイルを一致させる操作を実行します。\nC:\\Users\\tianlong.xiang\\Downloads\\chkmatch\u0026gt;ChkMatch.exe -m \u0026#34;D:\\Program Files\\Rolan\\trade\\UAT_YinStrade\\YinTrade.Main.exe\u0026#34; E:\\YinTech\\ykcz_securities_trading_client\\Sec_Trade\\YinTrade.Main\\bin\\Release\\YinTrade.Main.pdb ChkMatch - version 1.0 Copyright (C) 2004 Oleg Starodumov http://www.debuginfo.com/ Executable: D:\\Program Files\\Rolan\\trade\\UAT_YinStrade\\YinTrade.Main.exe Debug info file: E:\\YinTech\\ykcz_securities_trading_client\\Sec_Trade\\YinTrade.Main\\bin\\Release\\YinTrade.Main.pdb Executable: TimeDateStamp: c26d9be3 Debug info: 2 ( CodeView ) TimeStamp: f86b0a4f Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 122 RVA: 001cdc44 FileOffset: 001cbe44 CodeView format: RSDS Signature: {428c9b95-39a3-4a8d-a8e5-7be453684757} Age: 1 PdbFile: D:\\stock_UAT\\ykcz_securities_trading_client\\Sec_Trade\\YinTrade.Main\\obj\\Release\\YinTrade.Main.pdb Debug info: 16 ( Unknown ) TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 0 RVA: 00000000 FileOffset: 00000000 ## 参考資料 - [forcing-to-load-unmatched-symbols-in-visual-studio-2015-debugger](https://stackoverflow.com/questions/38147487/forcing-to-load-unmatched-symbols-in-visual-studio-2015-debugger) ","date":"2025-01-23","language":"ja","permalink":"https://ttf248.life/ja/p/visual-studio-load-unmatched-pdb/","tags":["visual studio","pdb","デバッグ","トラブルシューティング"],"title":"Visual Studio が「不整合な」PDB ファイルをロードできません。","year":"2025"},{"categories":["コンピューター"],"content":"一年又转眼即逝之际，在工作中最大的变化莫过于AI参与度明显提高。以往，不同开发语言之间切换，需要开发者熟悉各种语言的不同API接口，现在这些基础代码都可以通过AI生成代码了，对于开发者来说，无疑是一个巨大的福音。\nChatGPT 23年の時点で、簡単な入門紹介を既に2本作成していましたが、今では25年となり、どう表現しようか… 顕著な進歩を感じ取ることはなく、自律的な認知能力を発展させ、タスクを合理的に分割できることなどが求められます。もちろん、最も重要なのはAIが生成したコードにバグが存在するかどうかを特定することです。\nGithub Copilot いつの日か忘れましたが、シンガポールでサーバーがデプロイされているという情報を見つけました。国内では利用され、長期間のVPN接続も不要になりました。ただし、ログイン時にはVPN接続は必要ですが、そのVPN接続はログイン時のみ使用し、その後はオフにしておくことができます。\n日常的な使い道としてはGithub Copilotをより多く活用しています。この拡張機能は、VS CodeやVisual Studioで直接利用できます。2つのソフトウェア間の切り替えが不要です。ChatGPTと比較して、Github Copilotの方がプロジェクトのサポートが優れており、インタラクションもフレンドリーです。また、一部のローカルファイルをAIに「学習」させることで、生成されるコードがあなたのプロジェクトに合っているものになります。\nCursor AI 最近、Cursor AI という新しいAIプログラミングIDEを見つけました。これはGithub Copilotをベースにしたもので、このIDEはよりスマートで、直接ファイルを作成するのを手伝ってくれます。\n簡単な使い方は試してみて、なかなか良いと感じましたが、既存プロジェクトの理解はまだ十分ではありません。ローカルプロジェクトのファイルが多い場合や、大規模なリファクタリング、最適化、調整を行う場合は、やはり開発者がタスクを分割して行う必要があります。\n例として、curso のエンジンモードに切り替えて、以下の内容を入力してみましょう。「複数の異なるスタイルで切り替えられる個人用履歴書ウェブページの作成。個人情報をデータ表示のために埋めてください。」\n何度かやり取りするうちに、以下のようなウェブページが得られます。もちろん、このウェブページはかなりシンプルですが、初心者にとっては非常に良いでしょう。\n現在の登録ユーザーは、高度なAPIを150回無料で試用でき、有料ユーザーは5,000回まで制限されています。\nCursor AI 履歴書\n","date":"2025-01-23","language":"ja","permalink":"https://ttf248.life/ja/p/cursor-ai-programming-ide-trial/","tags":["ai","copilot","cursor","プログラミング","ide"],"title":"Cursor AI プログラミング IDE のトライアル","year":"2025"},{"categories":["コンピューター"],"content":"実際のC++開発において、ビット演算は一般的な技術であり、特にシステムの状態、フラグビット、または制御ビットを扱う際に、ビット演算は非常に効率的な解決策を提供します。本稿では、例を通して、ビット演算を使用して特定のフラグビットを取得および設定する方法について解説します。\nビット演算の基礎概念 コンピュータでは、データは2進数（0と1）のビットで格納されます。ビット演算とは、これらのビットに対して操作を行うことです。C++には、いくつかの一般的なビット演算演算子が用意されています。\n論理積（\u0026amp;）：特定のビットが1であるかどうかを確認します。 論理和（|）：特定のビットを1に設定します。 排他的論理和（^）：特定のビットを反転させます。 ビット反転（~）：すべてのビットを反転させます。 左シフト（\u0026laquo;）：すべてのビットを左に指定された数だけシフトします。 右シフト（\u0026raquo;）：すべてのビットを右に指定された数だけシフトします。 本例では、unsigned short 型の変数 wInfo に対して、さまざまなビット演算を実行し、異なるフラグビットを使用して状態を表す必要があります。\nflowchart LR A[元の数値: 00010000] --\u0026gt; B[左シフト: 00010000 \u0026lt;\u0026lt; 1] B --\u0026gt; C[結果: 00100000] C --\u0026gt; D[右シフト: 00100000 \u0026gt;\u0026gt; 1] D --\u0026gt; E[結果: 00010000] subgraph 左シフト操作 direction LR A --\u0026gt; B --\u0026gt; C end subgraph 右シフト操作 direction LR C --\u0026gt; D --\u0026gt; E end 要求分析 問題文の記述に基づき、16ビットのフラグビットがあり、これを用いて様々な状態を表します。これらの状態は個々のバイナリビットによって表現され、各バイナリビットは特定の意味に対応しています。例えば：\nbit0 が失敗かどうか bit1 が圧縮されているかどうか bit2 が増分であるかどうか bit3 が後続のパケットがあるかどうか bit5 が正常なリクエストまたは注销かどうか 位演算による実装 ビット演算を使用してこれらのフラグを設定および取得します。具体的には：\nビットごとの抽出 (ビットマスク): 特定のビットの値（0または1）を取得します。 ビット設定: 特定のビットを1に設定します。 ビットクリア: 特定のビットを0に設定します。 最初に unsigned short 型の変数 wInfo を定義し、これらのフラグを保存するために使用します。その後、ビット演算を使用して対応するフラグを確認および設定します。 C++ のサンプルコード #include \u0026lt;iostream\u0026gt; #include \u0026lt;bitset\u0026gt; // フラグ定数を定義 const unsigned short BIT_0_FAIL = 1 \u0026lt;\u0026lt; 0; // bit0 が失敗したか const unsigned short BIT_1_COMPRESSED = 1 \u0026lt;\u0026lt; 1; // bit1 が圧縮されたか const unsigned short BIT_2_INCREMENT = 1 \u0026lt;\u0026lt; 2; // bit2 がインクリメントされたか const unsigned short BIT_3_HAS_MORE = 1 \u0026lt;\u0026lt; 3; // bit3 に後続のパッケージがあるか const unsigned short BIT_5_CANCEL = 1 \u0026lt;\u0026lt; 5; // bit5 は正常リクエスト(0)または注销(1) // あるビットがセットされているか確認する関数 bool isBitSet(unsigned short wInfo, unsigned short bitMask) { return (wInfo \u0026amp; bitMask) != 0; } // あるビットをセットする関数 void setBit(unsigned short\u0026amp; wInfo, unsigned short bitMask) { wInfo |= bitMask; } // あるビットをクリア（0に設定）する関数 void clearBit(unsigned short\u0026amp; wInfo, unsigned short bitMask) { wInfo \u0026amp;= ~bitMask; } int main() { // wInfo の初期値を 0 と仮定 unsigned short wInfo = 0; // bit0（失敗フラグ）を設定 setBit(wInfo, BIT_0_FAIL); // bit1（圧縮フラグ）を設定 setBit(wInfo, BIT_1_COMPRESSED); // wInfo の2進数表記を出力 std::cout \u0026lt;\u0026lt; \u0026#34;wInfo (in binary): \u0026#34; \u0026lt;\u0026lt; std::bitset\u0026lt;16\u0026gt;(wInfo) \u0026lt;\u0026lt; std::endl; // 各フラグを確認 std::cout \u0026lt;\u0026lt; \u0026#34;bit0 (失敗したか): \u0026#34; \u0026lt;\u0026lt; (isBitSet(wInfo, BIT_0_FAIL) ? \u0026#34;はい\u0026#34; : \u0026#34;いいえ\u0026#34;) \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;bit1 (圧縮されたか): \u0026#34; \u0026lt;\u0026lt; (isBitSet(wInfo, BIT_1_COMPRESSED) ? \u0026#34;はい\u0026#34; : \u0026#34;いいえ\u0026#34;) \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;bit2 (インクリメントされたか): \u0026#34; \u0026lt;\u0026lt; (isBitSet(wInfo, BIT_2_INCREMENT) ? \u0026#34;はい\u0026#34; : \u0026#34;いいえ\u0026#34;) \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;bit3 (後続のパッケージがあるか): \u0026#34; \u0026lt;\u0026lt; (isBitSet(wInfo, BIT_3_HAS_MORE) ? \u0026#34;はい\u0026#34; : \u0026#34;いいえ\u0026#34;) \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;bit5 (注销されたか): \u0026#34; \u0026lt;\u0026lt; (isBitSet(wInfo, BIT_5_CANCEL) ? \u0026#34;はい\u0026#34; : \u0026#34;いいえ\u0026#34;) \u0026lt;\u0026lt; std::endl; // bit1（圧縮フラグ）をクリア clearBit(wInfo, BIT_1_COMPRESSED); // 更新された wInfo の2進数表記を出力 std::cout \u0026lt;\u0026lt; \u0026#34;Updated wInfo (in binary): \u0026#34; \u0026lt;\u0026lt; std::bitset\u0026lt;16\u0026gt;(wInfo) \u0026lt;\u0026lt; std::endl; return 0; } コードを実行することを推奨します：https://wandbox.org/\nwInfo (in binary): 0000000000000001 bit0 (失敗したか): はい bit1 (圧縮されたか): いいえ bit2 (インクリメントされたか): いいえ bit3 (後続のパッケージがあるか): いいえ bit5 (注销されたか): いいえ Updated wInfo (in binary): 0000000000000000 コード解説 フラグの定義: ビットシフト演算 (1 \u0026lt;\u0026lt; n) を使用して、各フラグを定義します。例えば、1 \u0026lt;\u0026lt; 0 は bit0 に対応し、1 \u0026lt;\u0026lt; 1 は bit1 に対応するなど、同様に推測されます。このようにして、各フラグには一意のバイナリ位置が割り当てられます。 特定のビットの確認: isBitSet 関数は、指定されたフラグが設定されているかどうかを確認するために、AND 演算 (wInfo \u0026amp; bitMask) を使用します。もしそのビットが1の場合、関数は true を返し、そうでない場合は false を返します。 特定のビットの設定: setBit 関数は、指定されたフラグを1に設定するために、ビットごとのOR 演算 (wInfo |= bitMask) を使用します。 特定のビットのクリア: clearBit 関数は、指定されたフラグを0に設定するために、ビットごとのAND 演算 (wInfo \u0026amp;= ~bitMask) を使用します。 結論 ビット演算を用いることで、複数の状態フラグを効率的に処理できるようになります。実際の開発においては、この技術が特に有用です。例えば、組み込み開発、ネットワークプロトコル、システムステート管理などの場面で、複数のバイナリ状態を表すためにビットフラグが頻繁に使用されます。スペースの節約と効率向上に貢献します。 この記事が、C++ でビット演算を用いてビットごとの取得と設定を理解し、習得するのに役立つことを願っています！これらのスキルは、効率的で保守しやすいコードを書く上で非常に役立ちます！\n","date":"2025-01-17","language":"ja","permalink":"https://ttf248.life/ja/p/cpp-bitwise-operations-flags/","tags":["c++","ビット演算 (bitten)","マーキングポイント"],"title":"C++ ビット演算の基礎：ビットごとのANDとフラグ設定","year":"2025"},{"categories":["コンピューター"],"content":"デスクトップPCのハードウェア三連発！前回の記事では、SSD PCIeアダプタについて触れたばかりですが、旧いSSDはどこへ行ったのでしょうか？もちろん無駄にはせず、壊れてしまっていたりするかもしれませんが、分解して新しく購入した「メカシシャ・クリエーター Mini-3765H」（一年前のモデル）にインストールしました。\nこのマシンは、ハードウェアスペックも十分に強力で、2.5GデュアルLAN、PCIe4.0、Wi-Fi 6を搭載しています。\n最近引っ越しをして、部屋にルーターを個別に設置してネットワークを構築することができず、すべてのマシンが無線ネットワーク経由で接続されています。ASUSのマザーボードデスクトップPCの無線LANカードの性能はあまり良くなく、ルーターの無線アクセスポイント、ローカルエリア間のアップロード速度が遅いこともあり、マシン間での通信速度が不安定でした。そこで、2.5G NIC（ネットワークインターフェースカード）を購入し、デスクトップPCにインストールしました。\nこれで、マザーボードのスロットはすべて埋まりました：グラフィックカード、無線LANカード、2.5G NIC、SSD PCIeアダプタ。\nネットワークの説明 両台の機器が元の無線LANに接続されているが、両台間をケーブルで直結し、両端に2.5G網カードを装着する。ケーブルで両台を直結する方法については、詳細は省略する（インターネット上には多くのチュートリアルがある）。ファイアウォールを必ず解除することに注意する。どちらか一方をゲートウェイとして使用すればよい。\ngraph TD; A[マシン1\u0026lt;br\u0026gt;IP: 192.168.4.1\u0026lt;br\u0026gt;サブネットマスク: 255.255.255.0\u0026lt;br\u0026gt;デフォルトゲートウェイ: - \u0026lt;br\u0026gt;自動取得DNS] --\u0026gt;|ケーブル直結（2.5G）| B[マシン2\u0026lt;br\u0026gt;IP: 192.168.4.2\u0026lt;br\u0026gt;サブネットマスク: 255.255.255.0\u0026lt;br\u0026gt;デフォルトゲートウェイ: 192.168.4.1\u0026lt;br\u0026gt;自動取得DNS]; A --\u0026gt;|無線LANカード| Internet; B --\u0026gt;|無線LANカード| Internet; 二重網段測速 ルーティング局域網 C:\\Users\\core\\Desktop\\iperf-3.1.3-win32\u0026gt;iperf3.exe -c 192.168.3.237 接続先ホスト 192.168.3.237、ポート 5201 に接続 [ 4] ローカル 192.168.3.122 ポート 1656 が 192.168.3.237 のポート 5201 に接続 [ ID] インターバル 転送 帯域幅 [ 4] 0.00-1.00 秒 9.17 MB 76.7 Mbps [ 4] 1.00-2.00 秒 9.91 MB 83.2 Mbps [ 4] 2.00-3.00 秒 8.74 MB 73.3 Mbps [ 4] 3.00-4.00 秒 10.2 MB 85.2 Mbps [ 4] 4.00-5.00 秒 9.23 MB 77.1 Mbps [ 4] 5.00-6.00 秒 8.80 MB 73.9 Mbps [ 4] 6.00-7.01 秒 8.00 MB 66.8 Mbps [ 4] 7.01-8.00 秒 7.69 MB 64.9 Mbps [ 4] 8.00-9.01 秒 9.72 MB 81.1 Mbps [ 4] 9.01-10.01 秒 7.63 MB 63.6 Mbps - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] インターバル 転送 帯域幅 [ 4] 0.00-10.01 秒 89.0 MB 74.6 Mbps 送信元 [ 4] 0.00-10.01 秒 89.0 MB 74.6 Mbps 宛先 iperf Done. 直連局域網 C:\\Users\\core\\Desktop\\iperf-3.1.3-win32\u0026gt;iperf3.exe -c 192.168.4.1 接続 192.168.4.1 に、ポート 5201 を確立 [ 4] ローカル 192.168.4.2 ポート 1524 が 192.168.4.1 のポート 5201 と接続 [ ID] インターバル 転送 帯域幅 [ 4] 0.00-1.01 秒 178 MB 1.48 Gbps [ 4] 1.01-2.00 秒 204 MB 1.72 Gbps [ 4] 2.00-3.00 秒 214 MB 1.80 Gbps [ 4] 3.00-4.00 秒 229 MB 1.92 Gbps [ 4] 4.00-5.00 秒 202 MB 1.69 Gbps [ 4] 5.00-6.00 秒 213 MB 1.79 Gbps [ 4] 6.00-7.00 秒 230 MB 1.93 Gbps [ 4] 7.00-8.00 秒 192 MB 1.61 Gbps [ 4] 8.00-9.00 秒 220 MB 1.84 Gbps [ 4] 9.00-10.00 秒 230 MB 1.93 Gbps - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] インターバル 転送 帯域幅 [ 4] 0.00-10.00 秒 2.06 GB 1.77 Gbps 送信元 [ 4] 0.00-10.00 秒 2.06 GB 1.77 Gbps 宛先 iperf 終了 参考資料 HugoにMermaidを導入する方法 ","date":"2025-01-10","language":"ja","permalink":"https://ttf248.life/ja/p/desktop-upgrade-to-2-5g-network-card-accelerates-local-area-network-interconnection/","tags":["windows","デスクトップパソコン","ネットワーク","2.5G NIC (Network Interface Card)","ローカルエリアネットワーク (LAN)","hugo","mermaid"],"title":"デスクトップPCを2.5Gネットカードにアップグレードし、ローカルエリアネットワークの接続速度を向上させる。","year":"2025"},{"categories":["コンピューター"],"content":"前の文脈を踏まえ、突然無線LANアダプターが認識されなくなった問題が発生しました。パーティションを再構築する前に、インターネット上でも他の解決策を探しておりました。例えば、マザーボードの電池卸載や、電源を切って15分間待つなどの方法がありました。また、最新版のBOISドライバーへのアップデートも試しましたが、いずれもうまくいきませんでした。\n他に処理すべきことがあり、制限ネットワークに切り替えて、リビングから部屋へ網線を引き込んだところ、有線LANも認識されなくなりました。最終手段としてシステムを再インストールしたところ、パーティションのガイダンスが失われました。もし常に問題が発生していれば、これほど長く悩むことはありませんでした。華碩のマシンにおけるディスク競合は、偶発的なものであり、システムの再起動時に不安定な状態がトリガーとなるようです。\n先週、台式机に新しい长江存储（チャンジアン cunzhuo）の2TB SSD（M.2インターフェース）を追加したところ、マシンは再起動せず、昨日までシャットダウンすることができませんでした。\nシステムの再インストール 時間を作ってみると、もう2年もシステムを再インストールしていない。Cドライブが足りなくなってきた。Windows の古い問題や、日常的に使用するソフトウェアが Cドライブに何かを保存しようとする。そこで、システムを再インストールすることにした。システムを再インストールした後、ネットワークカードの問題はすべて正常になった。翌日には、開発環境を回復させることができ、システムのバックアップを作成するために、新たな問題が発生した。システムを再起動すると、ブートパーティションが失われた。 前回の記事の手順に従い、ブートパーティションを再構築したが、不安定で、再起動するとブートパーティションが読み込まれなくなる可能性がある。折詰機箱を分解しようかと思ったとき、ハードディスクケーブルが緩んでいることに気づいたが、何度か確認しても問題なかった。\n記憶の想起 数年前、この機械はSSDを一度増設した際、PCIe変換器（グラフィックカードのポートに接続）を使用していました。これは、直接マザーボードに取り付けるのではなく、変換器を通してHDDを取り付ける方法でした。今回、直接マザーボードに取り付けたのは、おそらくマザーボードの問題である可能性があります。 マザーボードマニュアル マザーボードマニュアルに問題があり、記載されているSATAポートの位置と実際の位置が異なっております。ディスクの多さから、ポートにはすべてハードドライブが取り付けられており、古いSSDはSATAポートを使用しています。マニュアルでは、ポート間の競合が存在すると記載されています。しかし、実際にテストを行ったところ、この競合は不安定に発生し、発生すると対応するディスクを読み込めなくなります。ちょうどこれがシステムディスクであり、ブートローダーも同じディスク上に存在するため、システム起動時にブートローダーのロードに失敗します。 解決策 SSDをPCIe変換器に再インストールすることで、この問題を解決できます。その結果、マザーボード上のSATAポートとの競合が解消され、システム起動が正常に行われます。\n","date":"2025-01-10","language":"ja","permalink":"https://ttf248.life/ja/p/asus-z490-motherboard-disk-recognition-issues/","tags":["windows","エイスース","マザーボード","ディスク (Disukku)"],"title":"ASUS マザーボード Z490 のディスクが多すぎ、ランダムなディスクが認識されない。","year":"2025"},{"categories":["コンピューター"],"content":"元のバージョンがいつからなのかは不明ですが、Windows 11 ではディスククリーンアップツールが大幅に改善され、よりスマートになっています。\n主な理由は、これが公式のツールであり、ファイルを誤って削除したり、広告が表示されたり、ポップアップが現れたり、バックグラウンドプロセスが実行されたり、不要なものが一切含まれていないことです。\nWindows 11 では、「設定」\u0026gt;「システム」\u0026gt;「ストレージ」\u0026gt;「一時ファイル」からディスククリーンアップツールを開くことができます。\nストレージインターフェースの画像\n通常ユーザーは「推奨のクリーニング」を選択するだけで、システムはあなたの使用状況に基づいていくつかの提案を行います。\n筆者である私のような開発者は、ディスク上に多くの一時ファイルがあるため、「一時ファイル」を選択し、Visual Studio や Windows Update などの一時ファイルを多く含んでいます。\n一時ファイルの画像\n","date":"2025-01-06","language":"ja","permalink":"https://ttf248.life/ja/p/windows-disk-cleanup-storage/","tags":["windows"],"title":"Windowsに付属のディスククリーンアップツール：ストレージ","year":"2025"},{"categories":["コンピューター"],"content":"国内サーバーへのDockerデプロイで、会社がレジストリを提供していない場合、開発者が最初にやるべきことは、国内のレジストリミラーを設定することです。\n幸いにも今日、サーバー1台にミラー設定を行いましたが、イメージの取得中に常に取得できないという問題が発生しました。\nエラーメッセージ：Error response from daemon: Get \u0026quot;https://registry-1.docker.io/v2/\u0026quot;: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)\n2025年1月6日、隔日のうちにすべてのサーバーが復旧しました。この件は全く話題にならないとは信じられない。国内のすべてのレジストリミラーがダウンしていたのです\n障害の切り分けと修復試行 当初、他のミラー加速アドレスに切り替えて問題を解決することを期待したが、予想とは裏腹に問題は依然として発生し続けた。\n次に、ローカルDNS設定を修正して、ネットワーク解析の側面から突破口を探ることを試みたが、結局、ある程度のデバッグを行った結果も、障害は解消されなかった。\nこの時点で、ローカルネットワークの安定性が大きく疑われるようになり、そこで断念なく携帯電話のテザリングに切り替えて、潜在的なローカルネットワーク障害を回避することを試みた。しかし、結果は失望であり、問題の改善の兆候は見られなかった。\n問題の蔓延 現在、国内に数台のサーバーがデプロイされており、すべてDocker環境がインストールされています。これらのサーバーからイメージをプルすることを試みましたが、例外なく失敗し、返ってくるエラーメッセージも一様です。これは問題が特定のデバイスに限られたものではなく、広範囲に及んでいることを示唆しています。\nさらに調査した結果、イメージレポジトリのプロキシが瞬く間に停止していることが判明しました。この緊迫した状況下で、迅速に海外のサーバーを使用して試みましたが、幸いにもイメージのプルは正常に戻りました。これは問題が国内のネットワークリンクまたは関連設定にある可能性が高いことを意味します。\n戦略修正：迂回戦術 国内での直接リポジトリ取得の経路が重く制限される中、海外のリポジトリは正常にアクセスできる状況を鑑み、プロジェクトを迅速に進めるため、迂回戦術を採用することにしました。まず、国外サーバーに切り替えて必要なイメージを取得し、その後、国内イメージレジストリにプッシュすることで、「データブリッジ」を構築します。 同時に、Dockerfileファイルに対しても修正を行い、イメージのURLを国内環境に適したアドレスに変更してから再ビルドを実行し、最終的に成功裏にデプロイしました。\n","date":"2025-01-04","language":"ja","permalink":"https://ttf248.life/ja/p/docker-domestic-image-proxy-failure/","tags":["docker","プロキシミラー","国内 (こくさい)"],"title":"Docker 国内イメージプロキシが失敗しました。","year":"2025"},{"categories":["AI霊感衝突坊"],"content":"eスポーツ産業は、過去10年以上で急速な発展を遂げ、世界的に無視できない文化現象となっています。特に「League of Legends」（英雄伝説）（以下LOL）を代表するMOBAジャンルのゲームは、プレイヤーに競技の楽しさを提供するだけでなく、資本に強力な推進力を与え、一連のエスポーツプラットフォームやイベントの活発な発展を促進しました。しかし、これまでのすべてが資本の流入とエンターテイメント産業の台頭に伴い、徐々に衰退へと向かっています。パンダTVの隆盛と崩壊、斗鱼（ドウユー）と虎牙（ホアヤ）の競争は、「ワイルドキャピタル時代」の終焉を象徴し、eスポーツ業界の天時地利人和も変化の兆しが見えています。\n第一章：電競の台頭と資本の注入 1.1 初期における電子競技：草根からプロ化 初期の電竞産業は比較的草根的なスタートを迎え、特に中国市場においてはその傾向が顕著でした。多くのプレイヤーがゲームへの情熱を活かし，《星の衝突》（スタークラフト）やDotaといったゲームで競技に参加しました。しかし、電競の真の台頭は《英雄伝説》（League of Legends）の発表とプロモーションによって始まりました。2011年に《英雄伝説》が正式に中国市場に進出した後、電竞はニッチなコミュニティから徐々に大衆文化の一部へと発展していきました。特に2013年以降、LPL（中国プロリーグ）が段階的に形成され，《英雄伝説》が中国の電競産業における中心的な存在となりました。\n1.2 資本の異常な流入：熊猫TVと電竞ライブ配信プラットフォームの台頭 2015年は中国の電競業界における分岐点となりました。資本の流入により、電競は単なる競技イベントからより巨大な産業チェーンへと進化しました。熊猫TVがその代表的な存在として、過剰な資本によって生まれたものとなりました。王思聰（熊猫ライブの創業者の一人）が投資した熊猫TVは、革新的なコンテンツと莫大な投資で多くの視聴者やユーザーを引きつけ、急速に台頭しました。しかし、これは資本の「無慈悲」な流入の典型例であり、市場への過度な追い求めは、忍耐力や長期的な視点を欠く結果をもたらすことがあります。熊猫TVの資金と人的資源への投資は短期的に一定の成果を上げたものの、管理の問題と資本への過剰依存により、2019年に破産しました。\n1.3 ライブ配信プラットフォームの競争：斗鱼と虎牙の「資本戦争」 熊猫TVの崩壊は電競ライブ配信業界の衰退を引き起こさず、むしろ斗鱼（ドウユー）や虎牙（ホアヤ）といったプラットフォームの台頭を促しました。斗鱼と虎牙は二大ライブ配信プラットフォームとして電競業界のリーダーとしての地位を確立し、互いの競争はますます激化しました。斗鱼は初期に《英雄伝説》プロリーグのライブストリーミングやトップレベルのストリーマーへの契約を通じて、電競ライブ配信の基準となりました。一方、虎牙は電競イベントへの投資の拡大と自社のプラットフォームにおける多角的な展開によって、斗魚との差を徐々に縮小しました。\nこの過程で、資本が再び大きな役割を果たしました。2018年に斗鱼が成功裏に株式公開（IPO）を実現し、虎牙も同年に行いました。資本の急速な流れは業界の高集中化をもたらし、プラットフォーム間におけるストリーマーや著作権などの分野での激しい競争を生み出し、「資本戦争」と呼ばれる状況を形成しました。\n第2章：汎娯化とeスポーツの融合 2.1 汎娯化潮流：資金の流れが多様なエンターテイメントプロジェクトへ\n資本がeスポーツ業界に注力するにつれて、eスポーツプラットフォームの内容は汎娯化を遂げている。eスポーツ配信者は、試合解説やイベント生放送だけでなく、歌唱、ダンス、ライブインタラクションなど、さまざまなエンターテイメント形式へと展開している。プラットフォーム上のコンテンツはより豊富になり、eスポーツを核としつつ、多様なエンターテイメント要素を含むエコシステムが徐々に形成されている。\nしかし、汎娯化は問題も引き起こしている——eスポーツ本来の競技に焦点を当てた文化は徐々に後退し、エンターテインメント至上主義の流れが台頭してきた。この傾向により、かつてeスポーツを深く愛していた観客たちは離脱感情を抱き、資本も他のエンターテイメント分野へと目を向け始めている。過剰な資本の流入と利益追求により、eスポーツ産業の本質は徐々に曖昧になり、本来競技性を核とした価値理念が弱体化している。\n2.2 汎娯業界の台頭：資本の撤退と転換\nショートビデオプラットフォーム、ライブ配信プラットフォーム、娱乐圈など、他の汎娯業界の台頭とともに、資本は徐々にeスポーツからより広範なエンターテイメントコンテンツへと資金をシフトしている。この過程で、テンセント、アリババ、バイト跳動などの大手企業も、eスポーツプロジェクトのみに依存せず、映画、音楽、ショートビデオなどの分野への投資を拡大している。特にバイト跳動の台頭は、抖音（ドウイン）などのショートビデオプラットフォームの爆発的な成長により、eスポーツが他のエンターテイメントコンテンツによって覆い隠されるようになった。\n第3章：英雄聯盟の「青黄不接」：時代紅利の衰退 2011年に《英雄聯盟》（League of Legends）が中国市場に参入以来、それは中国eスポーツ業界における代名詞となり、数多くのプロ選手、チーム、大会を創出し、巨大なeスポーツ産業を生み出した。しかし、十数年を経て，《英雄聯盟》は中国eスポーツのリーダー的存在として、「青黄不接」（青色でなくなりつつある）の段階に入っている。特に近年では，《英雄聯盟》の影響力は徐々に低下し、顕著な衰退の兆候が見られる。\n3.1 プレイヤー群の「断層」\n最も顕著な変化はプレイヤー群の断層である。当初、eスポーツの急速な発展は大量の青少年プレイヤーによる支持に依存しており、その多くが《英雄聯盟》を通じてプロ選手や観客となった。あのネット中毒の少年たちは、「時代紅利」（時代の恩恵）の下で育ち、LOL（League of Legends）をもたらす競技魅力に没頭し、それが業界全体の急速な拡大を推進した。しかし、時間の経過とともに、これらのプレイヤーは成長し、社会に進出し、他の生活や職業へと転向していった。同時に、新たな世代の若年プレイヤーは《英雄聯盟》に対する熱意が昔ほどではなく、eスポーツの受衆群は明確な年齢偏差と興味の低下を示している。\n3.2 ゲームコンテンツの「疲労」\n《英雄聯盟》は何度もアップデートや改版を経て、依然として一定の競技魅力を維持しているものの、ゲーム自体のコンテンツイノベーションはやや力不足である。毎年発表されるバージョン更新、ヒーローバランス調整、新プレイスキルの導入などは、根本的にプレイヤーが求める新鮮さへの欲求を解決することができなかった。同時に、MOBA（マルチプレイヤーオンラインバトルアリーナ）ゲーム市場は飽和状態にあり、他のタイプのゲーム（例：王者荣耀（One Piece Unified Front）、和平精英（Game for Peace））が急速に台頭し、かつて《英雄聯盟》の顧客層であった大量のプレイヤーを奪っていった。このような競争状況により，《英雄聯盟》は常に「追従者」の役割から抜け出せない。\n結論：eスポーツ産業の未来はどこへ向かうのか？ eスポーツ産業は、まるで空にそびえ立つ高楼のように、インターネット業界における過剰な資金が新たなトレンドを求めてさまよう中で生まれたものだ。そして、eスポーツ産業はそのターゲットの一つとして注目を集めている。国内の人口ボーナスを背景とした短期間での爆発的な成功を収めたものの、それは確固たる基盤の上に築かれたものではない。資本の過剰流入、人材の不足、ゲームコンテンツの衰退といった問題が、eスポーツ産業の健全な発展を阻害している。\n大学時代以前は、ゲームをプレイする時間がほとんどなく、リーグは一代一貫した成長を伴うものとして存在していた。総决赛を何本も見た経験から、傍観者としての視点から見ると、中韓の選手、特にFakerのような国内の選手が、大会期間中に常に緊張と不安を感じるのを理解している。もちろん、選手の心理的なプレッシャーは大きいことは承知している。しかし、この業界は10年以上も発展してきたにもかかわらず、選手の心理問題はチームによって十分に重視されておらず、その点に改善が見られない。国内の玩法は依然として、選手自身の才能に依存している。\n","date":"2024-12-31","language":"ja","permalink":"https://ttf248.life/ja/p/end-of-league-of-legends-era/","tags":["ゲーム","eスポーツ (ē supōtsu)","パンダTV (panda TV)","闘魚","虎牙","資本","ソーシャル (sōsharu)"],"title":"野蛮資本時代の終焉：英雄聯盟eスポーツ時代終了","year":"2024"},{"categories":["金融知識データベース"],"content":"王様再びがアメリカ大統領に選出され、仮想通貨も再び大衆の目に晒されることになった。香港証取引所（HKEX）は、関連事業の積極的な展開を行っており、ここではその概要を簡単に記録する。\n関連契約リストの詳細を確認すると、当初導入されたのは現物ではなく先物を意味しており、これは理にかなっている。なぜなら、先物の市場には流動性が高く、機関投資家の参入が容易だからだ。その後導入された現物ETFも、合理的な理由がある。それは、ETFがより受け入れられやすい投資ツールであるためである。\n仮想通貨リスト 香港証取引所の市場データには、契約が仮想通貨であるかどうかを示す識別子が提供されていません。しかし、契約名から判断することができます。公式の取引リストには、対応するサブカテゴリvirtualassetが提供されています。 https://www.hkex.com.hk/Market-Data/Securities-Prices/Exchange-Traded-Products?sc_lang=en\u0026amp;asset=virtualasset\n2022年12月16日 香港証券取引所、アジア初の暗号資産ETF上場を歓迎 香港物取結算所有限公司（香港証券取引所）は本日（金曜日）、アジア初の暗号資産ETFの上場を歓迎した。これにより、製品生態圏をさらに拡大し、香港および国際投資者にとってより多くの選択肢を提供する。\n本日上場された2隻の新規ETF—南方東英ビットコイン期貨ETF（証券コード：3066）と南方東英イーサリアム期貨ETF（証券コード：3068）は、南方東英資産管理有限公司によって運用され、それぞれシカゴ商品交易所（CME）で取引される標準化された、現金決済型のビットコイン先物合約およびイーサリアム先物合約を追跡する。\n香港証券取引所の最高運営責任者兼市場広報担当官である姚嘉仁氏は、「本日上場された暗号資産ETFは、香港の多様で急速に成長している取引所製品生態圏に新たな魅力を加える。これらの新商品がアジアで投資家にとってデジタル資産への投資機会を提供する初の試みであり、デジタル経済に対する当社の関心と市場の需要を反映している。今後数か月でさらにテーマ別ETFやデジタル資産の新商品を導入することを楽しみにしている」と述べた。\nETFは、香港証券取引所の最も急速に成長している事業部門の一つであり、製品の種類は2022年に継続的に拡大し、多様化しており、年内に初のメタバースETF、初のカーボン先物ETF、初のブロックチェーンETFを上場させるとともに、初めてETFを滬深港通に組み込んだ。\nさらに、香港証券取引所の取引商品（ETP、ETFおよびレバレッジ・インバースETFを含む）の今年最初の11か月間の平均日次取引額は118億元となり、前年同期の78億元から50%増加した。これは、ETPxが投資家にとってますます人気が高まっていることを反映している。2022年11月時点で、香港証券取引所に上場されたETPxは合計168隻で、時価総額は3,735億元に達した。\n2024年4月30日 香港交易所が初の仮想資産現物ETF上場を歓迎 香港取引結算有限公司（香港証券取引所）は本日（火曜日）、アジア初の仮想資産現物ETFの上場を歓迎しました。これにより、香港市場の製品の種類が増加し、投資家にとってより豊富な選択肢を提供することで、香港をアジアにおける主要なETF市場としての地位を強化します。\n香港証券取引所の証券商品開発責任者であるロバジン氏は、「本日上場された仮想資産現物ETFは、香港証券取引所の多様かつ活発なETF市場生態圏を豊かにし、投資家にとって新たな資産クラスへの投資機会を提供します。1年前の成功に続き、アジア初の仮想資産現物ETFが、香港証券取引所の売買製品の種類と流動性をさらに向上させます。今後も市場関係者との緊密な連携を通じて、国際的な市場においてより多くの新製品を導入していくことを期待しています。」と述べています。\n最初の仮想資産先物ETFは2022年に上場後、投資家の関心を集め、活発に取引されてきました。香港で上場されている3つの仮想資産先物ETFの日平均取引量は、2023年の890百万から2024年第1四半期には5,130百万へと増加し、同時に5.29億元の資金流入も吸引しました。\n取引所売買商品（ETF、レバレッジ、インバースETFなど）は、香港証券取引所の成長が最も速い市場の一つであり、過去1年で製品の種類が継続的に増加しています。2023年および2024年第1四半期に上場された16隻のETFには、アジア初のサウジアラビアETF、香港初のデリバティブ付与型予約購入オプションETFが含まれており、現在香港証券取引所に上場されているETFは合計179隻です。\n2024年10月28日 香港証券取引所が仮想資産指数シリーズを導入 香港取引及結算所有有限公司（香港証券取引所）は本日（月曜日）、2024年11月15日に香港証券取引所仮想資産指数シリーズ（以下、「指数シリーズ」と略称）を導入することを発表しました。これは、急速に成長している仮想資産という資産クラスに対し、信頼できる基準価格を提供し、香港がアジアにおける主要なデジタル資産センターとしての発展を支援することを目的としています。\nこの指数シリーズは、アジア時間におけるビットコインおよびイーサリアムの価格設定において、透明性と信頼性の高い基準となるように設計されており、グローバルな取引所間の価格変動を解消することを目指します。\n香港証券取引所グループの行政总裁陳翊庭氏は、「本日の指数シリーズの導入に大変喜んでおります。地域におけるこの急速に成長している資産クラスへの需要に応えるものです。透明性と信頼性の高いリアルタイム基準を提供することで、投資家が合理的な投資判断を行い、仮想資産のエコシステムが健全な発展を遂げ、香港が国際金融センターとしての地位を確立することを支援できると信じております」と述べました。\nこの指数シリーズの導入は、香港証券取引所が新たな分野を探求する取り組みの一環であり、香港の金融技術（FinTech）の開発を支援すると同時に、変化し続ける市場環境において投資家にとって重要な基準ツールおよび解決策を提供します。\nこの指数シリーズには、ビットコインおよびイーサリアムの参考指数と、参考為替レートが含まれます。\n参考指数は、ビットコインまたはイーサリアムの24時間取引量加重の現物価格に基づいて計算され、主要な仮想資産取引所からの集約された市場価格を参考に算出されます。これらの数値は、香港時間を基準に即座にドルで表示されます。また、参考為替レートは、金融商品の決済を目的として設計されており、香港時間午後4:00に計算されます。\nこの指数シリーズは、欧州連合（EU）の基準法規（BMR）に準拠した初の仮想資産指数シリーズとなり、英国に登録された基準管理機関と仮想資産データおよび指数プロバイダーであるCCDataが共同で管理・計算を行います。\n香港特別行政区政府は2022年に仮想資産の開発に関する政策声明を発表し、香港において活気ある仮想資産産業およびエコシステムを育成することを目指しています。香港証券取引所仮想資産指数シリーズの導入により、リアルタイムデータとアジア時間における日次参考価格を提供することで、一般市民が仮想資産投資トレンドに対する理解を深めるのに役立ちます。\nこの指数シリーズのデザインと計算方法に関する詳細については、随時公開されます。\n参考文献 https://www.hkex.com.hk/news/news-release/2022/221216news?sc_lang=zh-hk https://www.hkex.com.hk/News/News-Release/2024/240430news?sc_lang=zh-HK https://www.hkex.com.hk/News/News-Release/2024/241028news?sc_lang=zh-HK ","date":"2024-12-31","language":"ja","permalink":"https://ttf248.life/ja/p/hong-kong-exchange-virtual-currency-history/","tags":["hkex","仮想通貨 (Kasoku tūya)"],"title":"香港証券取引所、仮想通貨の発展史","year":"2024"},{"categories":["転載 (tenzai)"],"content":"華泰柏瑞沪深300ETFなどに関する公告で、総合手数料を同業他社最安値に引き下げました。\n11月19日、華泰柏瑞基金は、投資家および資産形成ニーズのより良い充足のために、11月22日から開始し、華泰柏瑞沪深300ETFとその関連ファンドの運用管理手数料および信託手数料を減額し、関連ファンド契約内容を修正しました。\n変更後、華泰柏瑞沪深300ETFとその関連ファンドの年間運用管理手数料は0.15%に、年間信託手数料は0.05%にそれぞれ引き下げられ、すべてインデックスファンドの最安値帯に設定されました。\nほぼ同時期、業界上位規模の華夏沪深300ETF、華夏上證50ETF、南方中证500ETF、嘉实沪深300ETF、易方達创业板ETFなども管理手数料および信託手数料を減額する公告を出しており、手数料はすべて0.15%と0.05%に設定されています。\nこれまでの多くのETFの減価金減額とは異なり、今回は規模優位の品種が主体的に動き出したことで、業界への影響は大きくなる見込みです。証券取引所によると、11月18日時点で、華泰柏瑞沪深300ETFの規模は3700億元を超え、現在市場で最も規模が大きいETFとなっています。\n最大規模のスーパーETFが最初に減価金減額を実施したことは、投資家への利益還元する積極的な意思を示すとともに、投資家がより高い性价比で人気があり流動性の良いファンドに投資することを可能にします。\n業界の見解では、規模優位のETFによる減価金減額は、公募基金を通じた金融サービスの機能を発揮し、投資家の保有コストを削減し、収益性を高め、投資満足度を高めるのに役立ちます。\nまた、低手数料は製品自体の競争力をさらに高め、流動性虹吸効果とコスト運営上の優位性が加わると、製品はより多くの中長期増額資金を引き付ける可能性があり、「長投長持」の良好な生態系を構築するのに役立ちます。\n近年、取引の柔軟性、透明性の高さ、流動性の強さ、投資ハードルが低いなど、独自の利点により、広範指数ETFは資金の低位流入と「長投長持」の主要なチャネルとなっています。\n今回の減価金減額は、ある程度「加速器」となり、A股市場への長期資金の流入をよりスムーズにする可能性があります。\n跋談 筆者が定投している天弘ファンドはまだ公告が出ていませんが、追跡されるべきです。もし更新されない場合は、他のファンドへの変更を検討する必要があります。 元の手数料：0.5%、委託手数料：0.1%。新手数料：0.15%、委託手数料：0.05%。この割引幅はかなり大きいです。\n","date":"2024-11-21","language":"ja","permalink":"https://ttf248.life/ja/p/etf-fees-cut-china/","tags":["ファンド","ETF","解約 (かい yok)"],"title":"価格が下がった、価格が下がった、国内の超大型ETFが大量に価格調整を行った。","year":"2024"},{"categories":["転載 (tenzai)"],"content":" 巨大なハンマーが落下する。 金融アドバイザーサービスがショート動画の風を追い風に、または加速車道に乗ろうとしている。 今年9月の下旬、A株市場は熱狂的な情熱を示した後、抖音の推奨投資が各方面からの注目を集めた。 複数の金融系ストリーマーが抖音で人気を獲得し、間接的に資本市場に一定の変動をもたらした。 しかし、急速に人気を博している多くの金融系ストリーマーの裏には見過ごせない力がある。それは、サードパーティ型金融アドバイザーサービス会社だ。 調査によると、多くのサードパーティ型金融アドバイザーサービス会社は、ショート動画での複数のアカウント運営を通じて投流を活用してユーザーが投資教育ビデオを見るようにし、関連する金融アドバイザー製品の購入熱意を高めている。 さらに、あるサードパーティ型金融アドバイザーサービス会社は、今年10月にすでに10億元を稼ぎ出し、今年の上半期の収入を上回ったという噂もある。 しかし、「好日」はより多くの不確実性に直面している。 11月以来、複数の省庁が連名で、証券サービス機関に対し、自媒体アカウントのコンプライアンス管理を強化するように求めた。 11月15日の夕方、同花顺（300033.SZ）は、子会社がライブビジネスにおける個股推奨などの行為を含むため、証券規制委員会から罰款を受けたことを発表した。 これは市場に厳格な規制の信号を伝えているのかもしれない。 九方智投（9636.HK）をはじめとする多くのサードパーティ型金融アドバイザーサービス機関の展開も、より多くの圧力に直面するだろう。 厳密な監督が注目されるライブ配信 TikTokなどの短動画プラットフォームの台頭により、感情的な声が強調され、間接的に取引行動に影響を与えている。\n巨量算数によると、9月27日から10月8日の成交額が創高を記録した期間において、抖音A株キーワード検索指数は423.84万から1277.86万へと、実に2倍以上に膨張した。\nこのような状況下で、サードパーティの投資アドバイザー機関が「波を起こし助ける」行為に注目が集まっている。\n投資アドバイザーの職員がライブ配信を通じて様々な方法で個別の株式を推奨することは、高頻度の違反行為である。\n11月8日、広東証券監理局は、ある企業のライブ配信において、「個別株式の暗示的推奨」などの状況が存在することに対し、新規顧客の追加を一時停止する規制措置を実施した。\n11月14日午後、広東証券フューチャーズ協会は、「ライブ配信における管理体制の不備により、機関が業務停止処分を受けた」と発文し、一部の有証券投資アドバイザー資格を持つ機関がライブ配信での事業展開において、管理体制が不十分であったことや、ライブ配信中に個別の株式を推奨したことを指摘した。\n広東証券フューチャーズ協会は、「ライブ配信における推奨株行為を厳禁する」と表明した。ライブ配信は公共メディアの伝達手段であり、ライブ配信者（セクטור投資アドバイザーとして登録されているかどうかに関わらず）、ライブ配信中に個別の株式を推奨してはならない。」\nこれは例外ではない。\n11月7日に上海証券監理局が公開した罰金通知には、また、ソーシャルメディアプラットフォームで違法に株式を推奨する事例も含まれていた。\n規制当局の調査の結果、海顺证券投資顧問有限公司上海分社の投資アドバイザーである王永は、微信视频号を通じて誤解を招く動画コンテンツを公開し、これは専門家の規範に反していた。\n上海証券監理局は、この件について、王永に対して警告書を発行する監督管理措置を実施した。\n信風（ID:TradeWind01）によると、資格のない投資アドバイザー機関が、抖音で券商を介して株式を推奨しているケースもあり、現在では配信が停止されている。\n「業界の有人が抖音でライブ配信を行っているのは、実際には券商の下に位置付けられており、これにより投資アドバイザーの資格を得ることができ、オンラインでのライブ配信を通じて顧客を引きつけ、オフラインで投資アドバイザー製品を販売している。」華南の一人の投資アドバイザーは信風（ID:TradeWind01）に説明した。「しかし、ライブ配信中に株式を推奨されたため発覚し、配信が停止された。正規の券商は、セクטור状況についてライブ配信で説明するだけで、個別の株式については言及しない。」\n現在、規制当局はソーシャルメディアにおける違法な株式推奨に対して高い注意を払っている。\n例えば、深圳証券監理局は最近、業界内で一部の機関や個人が自媒体を通じて違法に株式を推奨するなど、違反行為が発生していることを通知した。これは、辖区证券投資咨询机构の自媒体運営管理をさらに規範するために、各機関が自媒体の運営管理をさらに強化する必要があるためである。\nこれにより、サードパーティの投資アドバイザーサービスの事業展開には、より多くの課題が生じる可能性がある。\n「トラフィックビジネス」は誤り ショート動画に惹かれて参入した投資家たちが儲かるのかどうかは不明だが、水供給業者としてのサードパーティ投顧サービスの二级市場での評価はすでに急騰している。 「オンライン投教第一の株式」である九方智投の時価総額は、今年9月初めの28.78亿元から、11月13日の終値で124.64亿元に急騰し、49回の取引日で既に333.08%の大幅上昇となっている。 半期報告書によると、今年の上半年九方智投は抖音（ドウイン）、小紅書（シャオホンシュー）などのソーシャルメディアプラットフォームでブランド露出を行い、今年6月末までにすでに488のアカウントと0.46億人のフォロワーを獲得した。 例えば、九方智投の首席投資顧問である「洪帮主（ホン・ハンブ）」の抖音上のフォロワー数は226万人を誇る。 「当社はMCN運営に深く取り組んでおり、ユーザー中心で、流量、ブランド、製品の包括的な発展を促進しています。」九方智投は指摘する。「ライブ配信、ショート動画などの新メディアツールとの深い融合を通じて、AI技術を活用し、ファンネットワークを構築し、積極的により効果的なeコマースモデルを探求することで、流量の効率的な変換を実現します。」 九方智投の投顧コースパッケージは数十元から十数万元まで幅広い価格帯をカバーしている。中でも最も高価なコースパッケージである「スーパー投資家」は、半年で13.96万元とされており、独占的な見解や投顧私享サービスなどが含まれている。 ただし、九方智投の投顧商品の返品率は10%以上となっている。 2024年の上半期には、九方智投のフラッグシップシリーズ、九方智投擒龍（チンロン）シリーズの返品率はそれぞれ14.7%、18.5%に達した。 しかし規制嵐の下で、九方智投の展開が影響を受けるかどうかが引き続き注目される。 最近、メディアは九方智投などのサードパーティ投顧会社旗下のアカウントが影響を受けていることを報道している。 11月7日、あるメディアは「洪帮主」がライブ配信を一時停止されたと報じた。 しかし11月15日の夕方、信風（ID:TradeWind01）がそのアカウントを検索したところ、「洪帮主」のライブ配信インターフェースで依然として11月18日のライブ配信を予約することができた。 同時に、関係機関が九方智投を検査しているという市場消息も伝わった。 しかし、九方智投に近い人物は信風（ID:TradeWind01）に、その検査は通常の検査であり、すでに完了したと述べた。 これは最近巻き込まれた規制嵐の一例ではない。 同花順（トウカシュン）も非法勧誘投資で立案され、営業を一時停止する可能性があるという報道があった。 これに対し、同花順は11月15日に「違法な勧誘投資の状況はなく、調査を受けているわけではありません」と回答した。 しかしその夜、同花順は子会社である浙江同花順雲ソフトウェア有限公司がライブビジネスプロモーション中にコンプライアンス管理が不十分であり、個別の株式を推奨するような状況にあったため、浙江証券局から3ヶ月間の新規顧客の追加停止などの制裁を受けたことを発表した。 これは、短動画プラットフォーム上の勧誘投資コンテンツに対する規制当局の関心のさらなる高まりを意味している可能性がある。 実際、ショート動画のケーキは多くの証券会社を引き付けたが、コンプライアンス要件に限定されるため、現在、証券会社はこれに対して比較的慎重になっている。 ある証券会社の人物は、同社が短動画運営やリードジェネレーションの方法を探求し、人員を短動画プラットフォーム会社に派遣して学習を行っていることを伝え、コンプライアンス要件により、現在も探索段階にあると述べた。 規制当局のさまざまなコンプライアンス要件の背後には、短動画プラットフォームの内容が明確な感情的色彩を持っていることがあり、投資は市場参加者が理性的に対応する必要があり、これら二つには天然の対立がある。 もし放漫行為の影響で資本市場が激しく変動すると、資本市場の長期的な健全な発展に反する。 証券免許機関は、短縮された時代への到来をどのような方法で受け入れ、レッドライン\n","date":"2024-11-21","language":"ja","permalink":"https://ttf248.life/ja/p/third-party-wealth-managers-scrutiny-tiktok-stock-winners-crackdown/","tags":["アドバイザー","抖音 (Douyin)","株式投資 (Kaibu Tōshi)","規制 (きそ)"],"title":"三者上場投資顧問の規制が強化され、「抖音（ティックトック）株取引」の裏で利益を上げた人物たちが取り締まりを受ける見通しとなりましたか？","year":"2024"},{"categories":["コンピューター"],"content":"CentOS Streamは、レッドハットのエンタープライズ向けLinuxディストリビューションの前段のオープンソース開発プラットフォームです。\n初めてオープンオペレーティングシステムのライフサイクルredhat and centos life cycleに注目したのが、この時期でした。\n期限が切れ、何か問題があるのでしょうか？セキュリティの問題以外にも、dnfが使えなくなってしまい、最近ツールをインストールする際に、dnfが失敗するという問題を調べたところ、CentOS 8 Streamが期限切れだったことがわかりました。\nCentOS Stream の紹介 位置と役割 CentOS Streamは、Fedora Linux（上流開発）とRHEL（Red Hat Enterprise Linux、下流開発）の中間に位置し、その橋渡し役を担っています。 最新のRed Hat系Linuxの機能を試すためのバージョンとして利用でき、ベータ版やプレビュー版としての活用に適しています。\n出身と背景 時間の経過とともに、Red Hat社はエンタープライズ向けLinuxプラットフォームの発展方法についてより効果的な方法を模索し始め、CentOS Streamを発表しました。 ‌CentOS 8が2021年末にメンテナンスを終了した後、CentOS Streamはその後継者として更新され続け、CentOSプロジェクトの将来的な開発方向となりました。\n特徴と利点 CentOS Streamは、継続的リリース（ローリングリリース）のLinuxディストリビューションであり、より迅速なアップデートを提供します。コミュニティ、パートナー、顧客への参加を促進し、透明性を高め、ユーザーがRed Hat Enterprise Linux (RHEL) に貢献するための機会を増やします。 CentOS Streamの内容は、Red Hatが次期安定版RHELに含める予定のソフトウェアであるため、コミュニティメンバーには安定したABI/APIを使用した開発およびテストのための基盤を提供します。\n利用シーンとターゲットユーザー CentOS Streamは、最新のLinux機能アップデートを継続的に取得したいCentOSユーザーや、Red Hat Enterprise Linuxの開発に参加する開発者およびパートナーに適しています。\nまた、コミュニティメンバー、Red Hat パートナー、その他の人々が、より安定かつ予測可能なLinuxエコシステムで革新的なオープンソースプログラムを最大限に活用できるよう支援することを目的としています。\n最終期限 リリース 公開日 サポート期間 セキュリティサポート 最新 9 3年前 (2021年9月15日) 2年6ヶ月後 (2027年5月31日) 2年6ヶ月後 (2027年5月31日) 9 最終期限 リリース 公開日 サポート期間 セキュリティサポート 最新 8 5年前 (2019年9月24日) 終了済み (2024年5月31日) 終了済み (2024年5月31日) 8 ソリューション アップグレードの手間を省き、長期サポート版の Ubuntu 24.04 を採用しました。\n","date":"2024-11-16","language":"ja","permalink":"https://ttf248.life/ja/p/centos-8-stream-eol/","tags":["centos stream","centos"],"title":"CentOS 8 Stream EOL","year":"2024"},{"categories":["コンピューター"],"content":"過去のコミット履歴を調べてみたところ、サイトが何度もテーマを変更しており、毎回いくつかのカスタム設定を適用していた。そこで、カスタム設定の変更方法を記録しておく。私のGitHubには「even」というテーマがあり、短期間メンテナンスを行っていたが、最新版のHugoコンパイラへのアップグレードを強行した結果、互換性が失われ、最終的に「stack」テーマに切り替えてしまった。\nHugoのモジュール化 モジュール化について言及する際、NginxモジュールやIDEAプラグインなどを思い浮かべる人が多いでしょう。 通常は、私がいくつかのモジュールをアップロードすることで、私の独自のニーズを満たすことができます。 モジュールが広く受け入れられる理由は、十分に柔軟で、あまり労力をかけずに自分のニーズを満たせることです。 多くの場合は、大体同じように見えるものの、細部には常に違いがあるからです。 これはソフトウェアの複雑さを物語っており、技術的な複雑さだけでなく、ビジネス上の複雑さも含まれます。 大多数の場合、私たちが直面しているのはビジネスの複雑さです。 これこそが、「隔行如隔山」という俗語を最もよく表すものです。\n現在では、インターネット業界だけでなく、金融業界、さらには伝統的な製造業まで、情報化システムを使用して企業の生産と管理を支援しています。 同じ「休暇申請システム」でも、同じ業界の異なる企業間には違いがあります。\nそしてHugoのモジュールは、皆さんがイメージするモジュールとは少し異なります。 機能単位で独自のニーズを満たすのではなく、ディレクトリ構造を主に使用して、共通の構造を認識します。\n資料リンク：07. Hugoアーキテクチャ — Hugoのモジュール\n[[imports]] path = \u0026#34;github.com/CaiJimmy/hugo-theme-stack/v3\u0026#34; git submodule 方式も引き続き使用できますが、本記事では推奨されません。 テーマを導入した場合、更新が発生するとメンテナンスが煩雑になり、個別の git リポジトリでテーマを管理する必要があるためです。\nテーマの修正ロジック (https://stack.jimmycai.com/guide/modify-theme) 前面モジュール化の基礎概念を理解した上で、カスタムテーマを理解すると、それほど難しくありません。hugo の現在のテーマも、複数の異なるモジュールを組み合わせて構成されています。あるモジュールを変更したい場合は、対応するテンプレートファイルを検索し、修正すればOKです。\nstack 公式ドキュメントからの抜粋：\nこの方法を使用すると、themes ディレクトリの下にファイルは存在しません。テーマを修正するには、変更したいファイルを同じディレクトリにある layouts ディレクトリにコピーする必要があります。\n例えば、themes/hugo-theme-stack/layouts/partials/head/custom.html ファイルを変更する場合は、それを layouts/partials/head/custom.html にコピーし、そこから修正します（テーマのリポジトリからコードをコピー）。assets と static ディレクトリについても同様です。\nテンプレートファイルの場所を見つける方法 従来の思路 テーマのソースファイルを確認し、テーマのデザイン思想を理解し、対応するテンプレートファイルを修正します。\n蛮力的なアプローチ 私はフロントエンドのコードがあまり理解していないため、時には手動で対応することがあります。例えば、関連するページをブラウザで開き、修正したい箇所を見つけ、要素を検査を使ってCSS名（css name）を特定し、ソースコード内で検索して該当ファイルを抽出し、それをサイトディレクトリにコピーして変更します。\nスニppets 公式サイトでデフォルトのファイルが用意されており、カスタマイズが必要な箇所は、複数のファイルに分割して custom.scss ファイルをインポートすることで、よりスタイルの管理を効率化できます。 修正内容まとめ（6時間） 現在は AI エンコードの元年であり、詳細な内容はここでは省略し、主な変更点を以下に列挙します。本サイトで行った修正内容としては、コピーボタンのスタイルの調整、コードブロックのスタイルの再設定などがあり、ChatGPT などは容易に対応できました。\n全体：グローバル文字スタイルを、以前の even と info cn を融合した表示スタイルを引き継ぎ、中国語に最適化 首页：右側のナビゲーションにマウスインタラクションアニメーションを追加 首页：記事に概要プレビュー（手間のかかる方法で実現）を追加 スクロールバー：スクロールバーのスタイルを美化 コードブロック：highlight.js を導入し、コードブロックのスタイルを美化 文章詳細：一部コンテンツが転載であるため、原作者情報と元のリンクを表示 アーカイブページ：トップのカテゴリ画像にテーマ自带の色付きマスクを削除し、元の画像を表示 アーカイブページ：年単位でのカテゴリ分類の統計表示パネルを追加 アーカイブページ：2列表示レイアウト stack テーマのコンポーネント再利用率が高いため、首页の記事への概要プレビュー追加に時間がかかりました。対応するコンポーネントを変更したことで、記事の詳細ページの変更も引き起こされ、正文が重複して表示される問題が発生しました。golang テンプレート の構文はあまり馴染みがないため、多くの時間を費やし、コンポーネント間のパラメータ伝達を解決することができませんでした。最終的には、巧みに手段として、ホームページに独自に JavaScript スクリプトを導入し、カスタムの特殊変数を通じて概要プレビューを実現しました。 コード再利用率が高すぎる場合も問題であり、変更を加えることで他の場所にも影響が及ぶ可能性があるため、テーマを変更する際には注意が必要です。元のロジックを壊さないようにしてください。\nコメント欄 このイケメンさんの修正はより洗練されています：https://blog.reincarnatey.net/2024/0719-better-waline/ 本サイトではシンプルな形で Waline 评论システムを導入しており、stack テーマがデフォルトで Waline をサポートしているため、config.toml に設定するだけです。\nホームページへのメール連絡の推奨、本サイトではコメント欄は開放していません\n","date":"2024-11-15","language":"ja","permalink":"https://ttf248.life/ja/p/hugo-module-customizing-themes-ideas/","tags":["hugo","トピック / テーマ","カスタム"],"title":"Hugo モジュールカスタムテーマの修正：考え方の解説","year":"2024"},{"categories":["AI霊感衝突坊","メモ書き雑感"],"content":"最近抖音上の大氷老師（だいひょうし）さんが非常に人気があり、よく動画の切り抜きアカウントを見かける。これらは主にライブ配信の内容だ。あるリスナーがボイスチャットで質問した。「大氷先生、西安の家を売って、故郷に戻って楽な暮らしにしたいのですが。」大氷先生は答えた。「あなたの年齢なら、30代半ばで、楽な暮らしにはならない。ご両親は年老いており、お子さんはまだ独立していない。故郷に戻れば、小県城（しょうけんじょう）の婆羅門（ばろもん）に対しても対応しなければならない。」\n先ほど述べたように、意見が正しいかどうかはさておき、婆羅門という言葉の意味は何でしょうか？\n県都の婆羅門：地方における「大物」 多くの小県城（けんじょう）では、人々はしばしば「県都の婆羅門」（けんとうのはらもん）と呼ばれる人物について語る。「婆羅門」たちは、地方社会の一種シンボルのように存在し、必ずしも真の宗教家でも、「高大上」（こうだいじょう）な肩書きを持つ者でもなく、一見普通だが重要な役割を担う人々である。彼らは小地方における「権力、地位、そして発言力」を代表し、その県城（けんじょう）内のある階層の象徴となっている。\n「県都婆羅門」とは何か？ まず、最初に「婆羅門」は本来、インド社会における最高階層を指し、知恵、権威、精神的な至高を表していました。しかし、中国の県城（けんじょう）の中では、「県城婆羅門」という言葉にはそれほど複雑な宗教的背景はなく、むしろ社会現象の一種を比喩的に表現したものです。\n簡単に言うと、「県城婆羅門」とは、県城の中で「文化的な権威」と呼ばれる存在であり、例えば教師、医師、地元の著名な商人、役人などが該当します。彼らの地位は一見平凡に見えますが、県城という比較的閉鎖的な環境においては、相対的に高い社会的な地位を占めているか、あるいは、彼らの意見や行動が地元で無視できない影響力を持つことがありました。\n「県城の婆羅門」とは？ 県城（けたしろ）に住むほとんどの業界で、そうした「婆羅門」（ばろもん）が存在する。彼らは以下のような存在かもしれない：\n教育者: 特に地方で長年教えた教師たち。必ずしも名校出身ではないかもしれないが、知識を通して威信を築き上げ、広く尊敬されている。 地方政府職員: 副県長（ふくけんちょう）や科級干部（かきげんかんぶ）など、県城の役職にある人々。彼らは一定の資源と権力を掌握しており、その地位が限られているにも関わらず、「婆羅門」として地方に影響力を持つ。 地元「企業家」: 県城の中小企業のオーナーたち。規模は大きくないものの、彼らの手にはある程度の富があり、地方における発言力を持っている。一軒か二軒の地元の知名度のある企業を経営し、県城の中で一定の影響力を持つ。 これらの人々は、大都市に住む名流や高官と比べると地位は高くはないが、県城という小さな社会においては、その地位は「文化長者」（ぶんかちょうしゃ）や「権力中心」（けんりょくちゅうしん）と同等であると言える。\n「県城婆羅門」の地位、社会にどのように影響を与えるのか？ 「県城婆羅門」の真の意味を理解するためには、県城という特殊な環境から考察する必要があります。この場所では、大都市ほど情報流通が速くなく、社会階層の流動も比較的固定されています。ここでいう「婆羅門」たちは、長年にわたり地元で深く耕作し、名声、知識、人脈を蓄積した結果です。彼らは地方の政治、経済、文化などあらゆる側面で影響力を行使します。\n文化的影響力：小規模な地域、特に教育システムが発達していない場合や、一般の人々にとって選択肢が限られている場合に、地元の「婆羅門」たちは、授業での知識伝達、メディアの説明、さらには社交的な場での言動を通じて、地方の文化雰囲気を静かに形作ります。\n社会資源の集中：県城という限られた人口と資源の中で、これらの「婆羅門」たちは、地方の主要な資源を掌握する存在の一人であることが多いです。社会福祉、政策の実行、あるいは特定のプロジェクトの承認など、彼らの影響は不可欠です。彼らの発言力や決定権が、地方社会において彼らに席次を与えています。\n人脈ネットワーク：比較的閉鎖的な小社会においては、人脈関係が非常に重要になります。「県城婆羅門」たちは、強力な社交ネットワークを構築することで、情報流通と資源配分をコントロールし、重要な局面で決定的な役割を果たします。\n「県城婆羅門」の裏に潜む比喩 「県城婆羅門」はしばしば尊敬と崇拝の対象となるが、その「高位」たる地位にも問題はないわけではない。現代社会において、多くの県城における「婆羅門」が真の能力や革新精神を持たないばかりか、世襲関係や資源独占といった方法で地位を維持していることは容易に発見できるだろう。情報化の発展に伴い、これらの「婆羅門」の権力は徐々に打破され、新たな社会流動性が小県城の面貌に影響を及ぼし始めている。\n総じて、「県城婆羅門」は非常に興味深い社会現象であり、地方社会における権力と文化構造を反映している。彼らの「権力」が国家の統治を直接脅かすわけではないかもしれないが、地方レベルにおいては、間違いなく重要な存在である。情報流通が急速に進み、社会変革が加速する現代において、県城に住むこれらの「婆羅門」たちは、これまで経験したことのない挑戦に直面しているのかもしれない。\n結論 本来如果没有这篇稿子，只是好奇 婆羅門 這個詞是什麼意思，然後把它丟給了 kimi，結果反而挺有趣的。我可以看到網頁端已經搜索出結果，但瞬間就變成相關內容無法顯示，然後我就想，這個詞是不是有什麼特別的意義，於是我就把這件事丟給了 ChatGPT，才有了這篇文章。\n","date":"2024-11-13","language":"ja","permalink":"https://ttf248.life/ja/p/county-brahmins-big-shots-in-small-towns/","tags":["大氷 (Ōhyō)","横になる","ブラフマン"],"title":"県庁の婆羅門：地方における「大物」","year":"2024"},{"categories":["コンピューター"],"content":"C++開発の歴史的なプロジェクトにおいて、カスタムプロトコルを使用して通信を行っており、そのプロトコルは2次元配列のパターンを採用していました。大量データを処理する際に、プロトコル内部では配列を遍历し、シリアライズ操作を実行してログを生成しており、このため効率が低く、システムが高負荷時に顕著なフレーム落ち（カドゥ）を引き起こしました。事業部門からは、システムのフレーム落ちに関するフィードバックがありました。\n問題の特定 問題のトラブルシューティングにおいて、まずシステムに対してパフォーマンス分析を実施し、大量データを処理する際にCPU使用率が著しく増加し、システムの応答時間が長くなっていることを発見しました。ログを分析した結果、多数のシリアライズ操作が見られ、これらの操作は2次元配列を処理する際の効率が低いことが原因でシステム性能が低下していました。 pstackツールを使用してサービスのスレッド情報を取得し、ログスレッドが文字列の連結に大部分の時間を使用していることを特定しました。\n今日は重点的に取り組むべき点です。異なる累積方式では、その効率の違いは非常に大きいです。過去のコードでは \u0026lsquo;+\u0026rsquo; 演算子を使用しており、この方法は頻繁に一時オブジェクトを作成するため、非常に非効率的でした。それは、その非効率さがどの程度であるかを知らない状況にあるようなものです。\nデモ検証 プロジェクトコードに基づいて、ビジネスロジックを抽出し、文字列連結の効率に関する問題を検証するためのシンプルなデモを作成しました。Windows環境ではVisual Studio 2022コンパイラ、Linux環境ではgcc8.5コンパイラを使用し、Releaseモードでビルドして実行することで、効率を比較します。\nキーポイントの説明 本プロジェクトで使用されたのは方法四であり、テストデータを入手する前に、どの方法が最も効率が良いか、最も効率が悪いかを読者が最初に考えてみるべきです。結果を見たときは、自分自身にとても驚きました。\n方法 1 (+= による連結)：各フィールドを += を使って文字列に直接連結します。 方法 2 (std::ostringstream による連結)：ストリーム（std::ostringstream）を使用して各フィールドを連結する方法で、特に大量のデータを連結する場合に効率的です。 方法 3 (事前にメモリを割り当てる += による連結)：reserve を使用して文字列に必要な十分なメモリを事前に割り当て、メモリ再割り当てのオーバーヘッドを削減することでパフォーマンスを向上させます。 方法 4 (bodys = bodys + body + \u0026quot;\\n\u0026quot;): 各連結で新しい一時的な文字列オブジェクトを作成するため、パフォーマンスが低下します。特に大規模な連結の場合、各連結において新しいメモリ割り当てとコピーが発生するためです。 参照結果から、プロジェクトはちょうど最も効率の悪い方法を選択していました。\nさらに詳しく分析すると、異なるプラットフォームコンパイラによる最適化効率を分析できます。Microsoft の visual studio は従来通り優れており、文字列の最適化効率は非常に高いですが、gcc コンパイラの最適化効率は少し劣ります。\n異なるマシンでコードを実行した場合、2つのデータセット間で直接比較する意味はありません。異なる連結方法間の差を比較できます。\n主要ポイント Windowsプラットフォーム下でのVisual Studio 2022コンパイラ ---------------------------------------- データ生成時間: 0.054秒。 ---------------------------------------- ---------------------------------------- データマージパフォーマンス: ---------------------------------------- + データマージ (+=) にかかった時間: 0.053秒。 + ostringstream データマージにかかった時間: 0.054秒。 + 事前予約済みデータマージにかかった時間: 0.045秒。 + データマージ (bodys = bodys + body + \u0026#34;\\n\u0026#34;) にかかった時間: 16.108秒。 ---------------------------------------- データマージ完了。 ---------------------------------------- プログラム終了。 Linuxプラットフォーム下でのgcc8.5コンパイラ ---------------------------------------- データ生成時間: 0.108秒。 ---------------------------------------- ---------------------------------------- データマージパフォーマンス: ---------------------------------------- + データマージ (+=) にかかった時間: 0.100秒。 + ostringstream データマージにかかった時間: 0.083秒。 + 事前予約済みデータマージにかかった時間: 0.057秒。 + データマージ (bodys = bodys + body + \u0026#34;\\n\u0026#34;) にかかった時間: 29.298秒。 ---------------------------------------- データマージ完了。 ---------------------------------------- プログラム終了。 完整コード #include \u0026lt;iostream\u0026gt; #include \u0026lt;string\u0026gt; #include \u0026lt;vector\u0026gt; #include \u0026lt;random\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;sstream\u0026gt; #include \u0026lt;iomanip\u0026gt; typedef std::vector\u0026lt;std::string\u0026gt; DataRow; typedef std::vector\u0026lt;DataRow\u0026gt; DataGroup; struct ResponsePackage { std::string ErrorInfo; DataRow Head; std::string ClientId; std::string UUID; std::string MsgID; std::string SessionID; std::string ExtraInfo1; std::string ExtraInfo2; DataGroup DataBody; }; // Generate specified length of random string std::string generateRandomString(size_t length) { const char charset[] = \u0026#34;abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789\u0026#34;; const size_t max_index = sizeof(charset) - 1; std::string random_string; random_string.reserve(length); std::random_device rd; std::mt19937 generator(rd()); std::uniform_int_distribution\u0026lt;\u0026gt; distribution(0, max_index); for (size_t i = 0; i \u0026lt; length; ++i) { random_string += charset[distribution(generator)]; } return random_string; } void create_large_string() { // Example request package with 50 fields ResponsePackage requestPackage; requestPackage.Head = { \u0026#34;Field1\u0026#34;, \u0026#34;Field2\u0026#34;, \u0026#34;Field3\u0026#34;, \u0026#34;Field4\u0026#34;, \u0026#34;Field5\u0026#34;, \u0026#34;Field6\u0026#34;, \u0026#34;Field7\u0026#34;, \u0026#34;Field8\u0026#34;, \u0026#34;Field9\u0026#34;, \u0026#34;Field10\u0026#34;, \u0026#34;Field11\u0026#34;, \u0026#34;Field12\u0026#34;, \u0026#34;Field13\u0026#34;, \u0026#34;Field14\u0026#34;, \u0026#34;Field15\u0026#34;, \u0026#34;Field16\u0026#34;, \u0026#34;Field17\u0026#34;, \u0026#34;Field18\u0026#34;, \u0026#34;Field19\u0026#34;, \u0026#34;Field20\u0026#34;, \u0026#34;Field21\u0026#34;, \u0026#34;Field22\u0026#34;, \u0026#34;Field23\u0026#34;, \u0026#34;Field24\u0026#34;, \u0026#34;Field25\u0026#34;, \u0026#34;Field26\u0026#34;, \u0026#34;Field27\u0026#34;, \u0026#34;Field28\u0026#34;, \u0026#34;Field29\u0026#34;, \u0026#34;Field30\u0026#34;, \u0026#34;Field31\u0026#34;, \u0026#34;Field32\u0026#34;, \u0026#34;Field33\u0026#34;, \u0026#34;Field34\u0026#34;, \u0026#34;Field35\u0026#34;, \u0026#34;Field36\u0026#34;, \u0026#34;Field37\u0026#34;, \u0026#34;Field38\u0026#34;, \u0026#34;Field39\u0026#34;, \u0026#34;Field40\u0026#34;, \u0026#34;Field41\u0026#34;, \u0026#34;Field42\u0026#34;, \u0026#34;Field43\u0026#34;, \u0026#34;Field44\u0026#34;, \u0026#34;Field45\u0026#34;, \u0026#34;Field46\u0026#34;, \u0026#34;Field47\u0026#34;, \u0026#34;Field48\u0026#34;, \u0026#34;Field49\u0026#34;, \u0026#34;Field50\u0026#34; }; requestPackage.ClientId = \u0026#34;ClientID\u0026#34;; requestPackage.UUID = \u0026#34;UUID\u0026#34;; requestPackage.MsgID = \u0026#34;MsgID\u0026#34;; requestPackage.SessionID = \u0026#34;SessionID\u0026#34;; requestPackage.ExtraInfo1 = \u0026#34;ExtraInfo1\u0026#34;; requestPackage.ExtraInfo2 = \u0026#34;ExtraInfo2\u0026#34;; // Start timing for data generation auto start_gen = std::chrono::high_resolution_clock::now(); // Generate 10,000 rows of data, each with 50 fields for (size_t i = 0; i \u0026lt; 10000; ++i) { DataRow dataRow(50, \u0026#34;This is a test string\u0026#34;); requestPackage.DataBody.push_back(dataRow); } // End timing for data generation auto end_gen = std::chrono::high_resolution_clock::now(); std::chrono::duration\u0026lt;double\u0026gt; duration_gen = end_gen - start_gen; // Display result generation time std::cout \u0026lt;\u0026lt; \u0026#34;\\n----------------------------------------\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;Data Generation Time: \u0026#34; \u0026lt;\u0026lt; std::fixed \u0026lt;\u0026lt; std::setprecision(3) \u0026lt;\u0026lt; duration_gen.count() \u0026lt;\u0026lt; \u0026#34; seconds.\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;----------------------------------------\\n\u0026#34;; // Data merging using different methods std::cout \u0026lt;\u0026lt; \u0026#34;\\n----------------------------------------\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;Data Merging Performance:\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;----------------------------------------\\n\u0026#34;; { // Method 1: Using \u0026#39;+=\u0026#39; string concatenation auto start_merge = std::chrono ## 完全なコード ```json { // Method 2: Using ostringstream auto start_merge = std::chrono::high_resolution_clock::now(); std::ostringstream bodys; for (auto\u0026amp; vec : requestPackage.DataBody) { std::ostringstream body; body \u0026lt;\u0026lt; \u0026#34;This is a test string\u0026#34;; for (auto\u0026amp; item : vec) { body \u0026lt;\u0026lt; item \u0026lt;\u0026lt; \u0026#34; \u0026#34;; } bodys \u0026lt;\u0026lt; body.str() \u0026lt;\u0026lt; \u0026#34;\\n\u0026#34;; } auto end_merge = std::chrono::high_resolution_clock::now(); std::chrono::duration\u0026lt;double\u0026gt; duration_merge = end_merge - start_merge; std::cout \u0026lt;\u0026lt; \u0026#34;+ ostringstream Data merging took: \u0026#34; \u0026lt;\u0026lt; std::fixed \u0026lt;\u0026lt; std::setprecision(3) \u0026lt;\u0026lt; duration_merge.count() \u0026lt;\u0026lt; \u0026#34; seconds.\\n\u0026#34;; } { // Method 3: Pre-allocated memory auto start_merge = std::chrono::high_resolution_clock::now(); std::string bodys; bodys.reserve(1000 * 50 * 20); // Pre-allocate enough memory for (auto\u0026amp; vec : requestPackage.DataBody) { std::string body(\u0026#34;This is a test string\u0026#34;); body.reserve(50 * 20); // Pre-allocate memory for each row for (auto\u0026amp; item : vec) { body += item + \u0026#34; \u0026#34;; } bodys += body + \u0026#34;\\n\u0026#34;; } auto end_merge = std::chrono::high_resolution_clock::now(); std::chrono::duration\u0026lt;double\u0026gt; duration_merge = end_merge - start_merge; std::cout \u0026lt;\u0026lt; \u0026#34;+ Pre-reserved Data merging took: \u0026#34; \u0026lt;\u0026lt; std::fixed \u0026lt;\u0026lt; std::setprecision(3) \u0026lt;\u0026lt; duration_merge.count() \u0026lt;\u0026lt; \u0026#34; seconds.\\n\u0026#34;; } { // Method 4: Using \u0026#39;bodys = bodys + body + \u0026#34;\\n\u0026#34;\u0026#39; auto start_merge = std::chrono::high_resolution_clock::now(); std::string bodys(\u0026#34;\u0026#34;); for (auto\u0026amp; vec : requestPackage.DataBody) { std::string body(\u0026#34;This is a test string\u0026#34;); for (auto\u0026amp; item : vec) { body = body + item + \u0026#34; \u0026#34;; // Note the use of \u0026#39;body = body + item\u0026#39; } bodys = bodys + body + \u0026#34;\\n\u0026#34;; // Again, using \u0026#39;bodys = bodys + body\u0026#39; } auto end_merge = std::chrono::high_resolution_clock::now(); std::chrono::duration\u0026lt;double\u0026gt; duration_merge = end_merge - start_merge; std::cout \u0026lt;\u0026lt; \u0026#34;+ Data merging (bodys = bodys + body + \\\u0026#34;\\\\n\\\u0026#34;) took: \u0026#34; \u0026lt;\u0026lt; std::fixed \u0026lt;\u0026lt; std::setprecision(3) \u0026lt;\u0026lt; duration_merge.count() \u0026lt;\u0026lt; \u0026#34; seconds.\\n\u0026#34;; } std::cout \u0026lt;\u0026lt; \u0026#34;\\n----------------------------------------\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;Data Merging Complete.\\n\u0026#34;; std::cout \u0026lt;\u0026lt; \u0026#34;----------------------------------------\\n\u0026#34;; } int main() { try { create_large_string(); } catch (const std::exception\u0026amp; e) { std::cerr \u0026lt;\u0026lt; \u0026#34;Caught exception: \u0026#34; \u0026lt;\u0026lt; e.what() \u0026lt;\u0026lt; std::endl; } std::cout \u0026lt;\u0026lt; \u0026#34;\\nProgram finished.\\n\u0026#34;; return 0; } ","date":"2024-11-13","language":"ja","permalink":"https://ttf248.life/ja/p/linux-backend-slow-string-processing/","tags":["c++","linux","トラブルシューティング"],"title":"Linuxバックエンドサービスの大量文字列データの処理 - 効率が悪い","year":"2024"},{"categories":["コンピューター"],"content":"C++において、ラムダ式は便利な匿名関数であり、外部変数をキャプチャして内部で使用することができます。これにより、ラムダ式は柔軟なプログラミングツールとなります。しかし、ラムダ式のパラメータのライフサイクルは特に注意すべき点であり、特にキャプチャおよびパラメータを渡す際に重要です。\n1. ラムダ式のパラメータのライフサイクル ラムダ式のパラメータのライフサイクルは、通常他のC++関数と同様です。関数の引数は関数呼び出し時に存在し、関数呼び出しが終了すると引数のライフサイクルも終了します。ただし、ラムダ式が外部変数をキャプチャする場合、そのキャプチャ方法によって引数のライフサイクルに影響を受ける可能性があります。\n2. パラメータのライフサイクルとの関係を捉える 2.1 外部変数のキャプチャ C++のラムダ式では、以下の2つの方法で外部変数 キャプチャできます:\n値によるキャプチャ: 値によるキャプチャでは、外部変数の値がラムダ内部にコピーされ、ラムダ内のコピーのライフサイクルはラムダのライフサイクルによって制御されます。 参照によるキャプチャ: 参照によるキャプチャでは、外部変数の参照が保持され、ラムダ内の参照は元の外部変数に指し示します。ライフサイクルは外部変数のライフサイクルに依存します。 int x = 10; auto lambda_by_value = [x]() { std::cout \u0026lt;\u0026lt; x \u0026lt;\u0026lt; std::endl; }; // xのコピーをキャプチャ auto lambda_by_reference = [\u0026amp;x]() { std::cout \u0026lt;\u0026lt; x \u0026lt;\u0026lt; std::endl; }; // xの参照をキャプチャ lambda_by_value(); // 10 を出力 lambda_by_reference(); // 10 を出力 キャプチャされた変数 のライフサイクルは以下のとおりです:\n値によるキャプチャ: キャプチャ時に外部変数の値がラムダにコピーされ、ラムダのライフサイクルが終了すると、コピーされたコピーが破棄されます。 参照によるキャプチャ: ラムダが外部変数の参照を保持し、外部変数はラムダの使用前に有効でなければなりません。そうでない場合、未定義動作が発生します。 2.2 ラムダパラメータ ラムダパラメータは、通常の関数パラメータと同様に、そのライフサイクルはラムダ関数内のみに限られます。つまり、ラムダパラメータはラムダが呼び出されたときに作成され、ラムダが呼び出された後にそのライフサイクルも終了します。\nauto lambda = [](int a, int b) { std::cout \u0026lt;\u0026lt; a + b \u0026lt;\u0026lt; std::endl; }; lambda(5, 10); // ここでaとbはラムダのパラメータ この例では、a と b はラムダ式のパラメータであり、ラムダが呼び出されたときに作成され、ラムダの実行後に破棄されます。\n3. 外部変数を捕捉する際のライフサイクルに関する問題 3.1 キャプチャされた変数が出 lambda の外で有効か 値によるキャプチャ：外部変数が lambda が呼び出された後に破棄されても、lambda 内には外部変数のコピーが保持されます。したがって、lambda 内のコピーは安全に使用でき、外部変数が存在しなくなっても問題ありません。 int x = 10; auto lambda = [x]() { std::cout \u0026lt;\u0026lt; x \u0026lt;\u0026lt; std::endl; }; x = 20; // x は lambda が呼び出された後に変更されます lambda(); // 10 を出力します（x のコピーを使用） 参照によるキャプチャ：外部変数を参照でキャプチャする場合、lambda 内での外部変数へのアクセスは外部変数のライフサイクルに依存します。外部変数が lambda が実行される前に破棄された場合、ダングリング参照が発生し、未定義の動作を引き起こります。 int x = 10; auto lambda = [\u0026amp;x]() { std::cout \u0026lt;\u0026lt; x \u0026lt;\u0026lt; std::endl; }; x = 20; // x は lambda が実行される前に変更されます lambda(); // 20 を出力します（x の参照を使用） lambda の実行順序が不定の場合、キャプチャされた外部変数が lambda の実行時に有効であることを保証することが重要です。\n","date":"2024-11-13","language":"ja","permalink":"https://ttf248.life/ja/p/cpp-lambda-parameter-lifetime/","tags":["c++","lambda"],"title":"C++におけるラムダ式のパラメータのライフタイムについて","year":"2024"},{"categories":["コンピューター"],"content":"前回の続きですが、戻ってみたらGhubにアップデートがあったので少し嬉しい。カスタマーサポートが言っていた、ドライバが正常にロードできない問題が解決したと言っていたのですが、色々試してみたものの、再インストールしても正常には動かない。\n背景 引き続きカスタマーサポートに問い合わせて解決策を相談したが、エンジニアによるリモート支援が可能であると伝えられたが、エンジニアの勤務時間と自身の勤務時間が完全に一致しないため、結局諦めざるを得なかった。最後にトラブルシューティングで残された資料を確認し、手動でのドライバーインストールを試みることにした。\n驱动安装包の入手方法 ロジック社の公式には、個別のデバイスのドライバインストールパッケージが提供されていません。どのようにしてドライバファイルを入手すれば良いでしょうか？ 最後にシステムを再構築した際のシステムイメージパッケージと組み合わせて、ローカル仮想マシンでシステムをクリーンに再構築し、そこでGhubを単独で展開します。これにより、ヘッドセットデバイスを仮想マシンに導入し、ドライバのパスを見つけてコピーアウトすることができます。 関連するパス：\nC:\\ProgramData\\LGHUB C:\\Windows\\System32\\DriverStore\\FileRepository\\logi_audio.inf_amd64_010b035044e24be4 デバイスマネージャー 重点は２番目のパスの探し方で、まずはWindows 11 システムがどのように手動でドライバーファイルを管理できるかを整理します。この内容は、交差法（コントロール変数法）を用いて識別し、デバイスを抜き差しすることで仮想マシン内でデバイスマネージャーの情報からデバイス情報を特定し、合計３つのドライバーを処理する必要があることを認識しました。そのうち２つのドライバーはシステムに組み込まれており、１つはロジック社が提供しています。\nドライバーマネージャー\n上記の図の２番目のドライバーは、ロジック社が提供しており、デバイスの現在のドライバープログラムを分析し、仮想マシン内のすべてのドライバーパスを検索します。もちろん、最初に「logi」で始まるファイルを見つける必要があります。その後、ファイルの比較を行うことでドライバーのファイル件を特定し、そのフォルダ全体をコピーすることでドライバーインストールパッケージを入手できます。\nドライバーインストールパッケージ\n驅動のインストール デバイスマネージャーのインターフェースで、以下の手順を実行します：\n「ドライバーの更新」をクリックし、「コンピューター上のドライブを検索」をクリックすると、以下の画面が表示されます：\n通常起動すると、USBドライバーのみが表示されます。 「ディスクからインストール」を選択し、事前にコピーしてきたフォルダのパスを指定します。 インストール後、「ドロップダウンリスト」からロジック特有のドライバーが追加され、デバイスドライバーを新しくインストールしたドライバーに変更します。\n人体工学デバイス駆動 このドライブファイルはすべてシステムが提供するものですが、デバイスのドライバの前に感嘆符 (!) があるかどうかを確認してください。もし感嘆符があれば、ドライバ選択インターフェースに移動し、ランダムな他の種類のドライバを選択してから、再度元のドライバに戻すことで正常に復元できます。\n修了 ヘッドホンマイクの音量が正常に回復し、馴染みのあるエコーキャンセル機能も復帰しました。 サイドノイズ画像\n","date":"2024-06-05","language":"ja","permalink":"https://ttf248.life/ja/p/win11-logitech-g431-headphone-driver-installation/","tags":["Logitech","トラブルシューティング"],"title":"Win11 Logitech G431 ヘッドホン ドライバー インストール","year":"2024"},{"categories":["コンピューター"],"content":"これらのことを全く理解していない場合は、すぐに公式のカスタマーサポートに連絡すれば、何時間も悩むことがなくなるだろう。\n正文 最近、自宅で開発に使っていたデスクトップPCのCドライブがストレージ容量不足になってしまったため、特意に256GBの半退役SSDをCドライブとして使用するようにした。ところが、その後、色々と勝手なことをしてしまっている。上海に引っ越してからずっと様々な業務に追われており、つい先週ようやくシステムを再インストールした。\nシステムを再インストールする過程はスムーズで、日常的なソフトウェアのインストールや開発環境のデプロイにも問題はなかった。数日後、私はリラックスして、数ゲームプレイすることを思い立ったが、その時になってマウスとヘッドホンのドライバーがまだインストールされていないことに気づいた。これらのデバイスはどちらもロジクスの製品であるため、GHUBソフトウェアをダウンロードし、このソフトウェアはハードウェアを自動的に認識し、ドライバーをインストールすることができる。\nしかし、予期せぬ事態が発生した。マウスのドライバーは正常にインストールされたが、ヘッドホンのドライバーは常に「読み込み中」と表示され続けた。最新版のWindows 11システムとロジクスのドライバーの互換性の問題でインストールが失敗しているのではないかと疑ったため、私は情報を検索し、手動でドライバーをインストールすることを試みたが、問題は解決しなかった。\n簡単に説明すると、これらのデバイスのドライバーはそれぞれどのような役割を果たしているのかを示す。\nマウスのドライバーは主にマウスの移動速度などの機能を調整するために使用される。マクロ機能はほとんど使用しないため、以前覚えていたパラメータに戻すだけでよい。 ヘッドホンのドライバーは主にヘッドホンリバーブ機能に使用され、これはチームでの音声通話時に非常に役立ち、自分の発言を聞くことができる。システムのミキサー設定にも同様のモニタリング機能があるが、ドライバーで実現するよりも効果がない。 私は何度も試みたが、ヘッドホンのドライバーは常に正常に読み込まれなかった。今日、ついにカスタマーサポートに問い合わせることを思いつき、状況を確認し、解決策を見つけることができるかどうかを尋ねた。カスタマーサポートは、最近彼らのサーバーで問題が発生しており、ドライバーのダウンロードが異常になっていると教えてくれた。彼らはこの問題を処理しており、私に急がないように指示し、次のアップデート後に問題が解決すると言った。\nまだヘッドホンのドライバーの問題が解決していないが、少なくとも原因を突き止めることができた。問題が早急に解決することを願っている。\nマウスドライバ設定 ","date":"2024-05-31","language":"ja","permalink":"https://ttf248.life/ja/p/logitech-headphone-driver-installation-failure/","tags":["Logitech"],"title":"ロジック(レイザー) ヘッドホン ドライバーのインストールに失敗しました。 (Rōjiku (Reizā) heddohon dᱨīvā no insutora ni himitsu shimaimashita.)\n\n**Note:** I've provided the romanized version for pronunciation.  A more natural Japanese phrasing would be:\n\nロジック(レイザー) ヘッドホンドライバーのインストールが失敗しました。 (Rōjiku (Reizā) heddohon dᱨīvā no insutora ga himitsu shimaimashita.)","year":"2024"},{"categories":["魚の7秒間の見聞"],"content":" unsold housing interest rate lower limit From tomorrow, the savings rate will be reduced by 0.25% First-time homebuyers down payment ratio lowered to 15% 300 billion yuan of guaranteed mortgage reloans 首套・二重所有の個人住宅ローン金利の下限措置の取消について 中国人民銀行上海本部、各省・自治区・直轄市及び計画特別市の分行；各国有商業銀行、中国郵政貯蓄銀行、各股份制商業銀行：\n党中央・国务院の方針決定・指示遂行を確実にし、我が国の不動産市場における需給関係の変化と国民の質の高い住宅に対する新たな期待に応え、不動産市場の安定した健全な発展を促進するため、以下の事項について商業性個人住宅ローン金利政策の下限措置の調整に関する事項を通知いたします。\n第一に、全国レベルで首套住宅および二套住宅の商業性個人住宅ローン金利の下限措置を取消します。\n第二に、中国人民銀行各省级分行は、地方施策に基づき、各省・地域の市場金利決定自律メカニズムを指導し、管轄区域内の各都市不動産市場の状況および地方政府の調整要求に応じて、管轄区域内の各都市における商業性個人住宅ローン金利の下限及びその水準（設定がある場合）を自主的に決定します。\n第三に、金融機関は、各省・地域の市場金利決定自律メカニズムで定められた金利の下限（設定がある場合）を参考に、本機関の経営状況、顧客リスク状況などの要素を考慮し、各融資案件ごとに具体的な金利水準を合理的に決定するものとします。\nhenkilökohtaisen asuntopääomarakkaisse lainan korkoa alennetaan 0,25 prosenttiyksiköllä Kiinan kansallisen pankin Shanghai-päämaja, maakunnat, autonomiset alueet ja suorat hallinnolliset kaupungit sekä suunnitelman yksittäisten kaupunkien sivukonttorit; Kiinan politiikkapankit, valtion kauppabankt ja Kiinan postiverkoston pankki sekä kaikki osakepohjaiset kauppabankt:\nKiinan kansallisen pankin päätös on, että henkilökohtaisen asuntopääomarakkaisse lainan korko alennetaan 0,25 prosenttiyksiköllä 18. toukokuuta 2024 alkumääräisesti, ja 5 vuoden alle (mukaan lukien) ja yli 5 vuoden ensiasunnon henkilökohtaisen asuntopääomarakkaisse lainan korot säädetään erikseen 2,35 %:ksi ja 2,85 %:ksi, kun taas 5 vuoden alle (mukaan lukien) ja yli 5 vuoden toissijaisen henkilökohtaisen asuntopääomarakkaisse lainan korot säädetään erikseen vähintään 2,775 %:ksi ja 3,325 %:ksi.\nmsızai no kōyū hōritsu o juni-tsū 15% ni tsukuriage Zhōngguó rénmín yínháng Shànghǎi zhǔtǒng, gè shěng, zìzhìqí, zhíxiàshì é jìhuàdānlúnshì fēn xíng; guójiā jīnróng jiānɡyémányǐn zǒngjū gè guǎnlǐ jú, gè guó yōuzǎi shāngyě yìngbǎn, Zhōngguó Yóuspín Chǔxīyínháng, gè gǔkfēn zhì shāngyě yìngbǎn:\nDìwèi lùyì dǎngzhòng, suǒyuán juécè bùshǔ, shìyìng Wéixuài guōdào gōngqíu xiàngguān, rénmín qúnzú duì yōuzhí jiùfáng de xīn qídài, cùjìn shāofáng shìchǎng píngwěn jiànkāng fāzhǎn, xiàn jiū yuánjí gèrén jiàdǔankuàndìxiàngshì yinxī zhǐ tōngxī yóu wèizhì:\nDuìyú dàikuǎn gòumǎi shāngpǐn jiùfáng de mínzhí jiātdì, mōuzai hǎo jiù fāngmíng hōritsu juni-tsū 15%, èr tàisài hǎo jiù fāngmíng hōritsu juni-tsū 25%.\nCǐ zhī shàng, Zhōngguó rénmín yínháng gè jiébì fēn xíng, guójiā jīnróng jiānɡyémányǐn zǒngjū gè pǎichù jízhǔ jianjí, yīnzhen shīcùlì suōyuán, zìyóu quèdìng jiùmín hángcheng de shǒutào hé èrtàisài jiàdǔankuàndìxiàngshì yinxī hōritsu xiàxiàn.\n中央銀行は3000億元を保証型住宅再融資枠として設立 下午4時、住宅及び都市建設部、自然資源部、中国人民銀行、国家金融監督管理総局の四部門が国务院政策例行吹風会に集まり、保交房（保障性住房）の実施に関する配套政策について説明しました。\n会上、中国人民銀行副行長陶玲は、中央銀行が3000億元を保証型住宅再融資枠として設立することを発表し、地方国有企業が合理的な価格で未販売の商品住宅を購入し、配售型または配租型保障性住宅として使用することを支援します。これにより、銀行の貸付額が5000亿元に及ぶと予想されます。\n中央銀行の説明によると、保証型住宅再融資枠の期間は1年可展期4次で、金利は1.75%です。これは21家全国性銀行に対して提供され、都市政府が選定した地方国有企業への融資を奨励し、未販売の商品住宅を購入して保障性住宅として使用することを促します。所收购の商品房は厳格に限定され、不動産企業が建設した未販売の商品住宅のみ購入可能です。\nこの政策について、近期（きじかい）中央銀行は《关于设立保障性住房再贷款有关事宜的通知》（保証型住宅再融資に関する規定通知）を公表する予定です。\n","date":"2024-05-17","language":"ja","permalink":"https://ttf248.life/ja/p/promoting-real-estate-and-central-bank-four-measures/","tags":["不動産"],"title":"不動産を促進するための中央銀行の4つの施策","year":"2024"},{"categories":["AI霊感衝突坊"],"content":"最近、家の装修プロジェクトにより日々の支出が急増しました。普段もクレジットカードを使っており、請求周期内にお金を返済していますが、手元に十分な現金があるにもかかわらず、これらの現金をマネーファンドで保有し、追加の利息収入を得ることを好んでいます。また、財産の安定性を確保するため、自動引き落とし機能を設定し、期日までにクレジットカードの請求をきちんと返済できるようにしています。\n銀行の現状：預金増加、貸出減少 経済的不確実性が高まる中、人々は消費や投資よりも貯蓄を優先する傾向にあります。これにより、銀行の預金残高が増加する一方、銀行は預金者に対してより多くの利息を支払う必要が生じます。一方で、消費と投資活動の低迷により、貸出需要が低下し、銀行は貸出を通じて利息収入を得ることが難しくなります。\n顧客を獲得・維持するため、銀行は競争力のある預金金利を提供せざるを得ず、さらに銀行の収益率を圧迫します。同時に、経済成長と消費を刺激するために、中央銀行が基軸利率を引き下げる政策をとれば、銀行の貸出金利にも影響を与え、その結果、銀行の収益性に影響を与える可能性があります。\n銀行マーケティング戦略：ユーザー習慣の育成 最近、返済日が近づいてきました。まず、中国建設銀行は私に連絡し、1年間の無料分割払いサービスを提供してくれました。金利は一切かかりません。続いて、招商銀行も分割金利を2.5割引したお得なキャンペーンを実施し、年換算金利はわずか1.9%でした。このような優遇措置に対し、私は両行の分割払いサービスを受け入れることにしました。\n私は、銀行がユーザー習慣を育成するために本当にコスト惜しまないことを悟りました。銀行の「流動的な顧客」という定義によれば、私は銀行にとって質の高い顧客であるべきです。現在の銀行における資金の貸し出し難い状況下において、分割払いの意識を醸成することで、銀行は将来私が起こりうる資金繰りの困難を想定し、その際に私からより多くの利息収入を得ることを目指しているのです。毕竟、広く知られているように、クレジットカード請求書の分析金利は決して低くありません。\n銀行が無料の分割払いサービスと低金利の分割払い優遇措置を提供することで、クレジットカードの使用頻度と限額を増やし、ユーザーの間でポジティブなイメージを確立しています。この戦略の変化は、銀行が市場の変化への迅速な対応と顧客ニーズに対する深い理解を示しています。このようにして、銀行は資金の貸し出し難い問題を解決するだけでなく、将来の収益のために準備を整え、利益は今だけを見れば意味がない。未来を見据えることが長続きの秘訣である。\n個人の財務管理の重要性 銀行の分割払いのような魅力的なオファーは魅力的かもしれませんが、ユーザーとして、過度なクレジットカードの分割払いに依存することによるリスクを認識する必要があります。自身の返済能力と将来の資金需要を十分に考慮し、短期的な金融的便利さのために長期的な債務問題に陥ることを避けるべきです。個人財務管理の鍵は、現在のニーズと将来の計画とのバランスを取ることです。\n招商分割払い請求書\n","date":"2024-03-31","language":"ja","permalink":"https://ttf248.life/ja/p/bank-marketing-personal-finance-balance/","tags":[],"title":"銀行マーケティング戦略と個人資産管理のバランスアート","year":"2024"},{"categories":["AI霊感衝突坊"],"content":"現代のデジタル時代において、ゲームは単なる娯楽という枠を超え、人々の日常生活に欠かせない一部となっています。心理学的な観点から見ると、ゲームは異なる年齢層の人々心理の発達においてそれぞれ異なる役割を果たし、同時に社交・娱乐との密接な繋がりも持ち合わせています。\n心理状態 若者たちは自己探求とアイデンティティ形成の段階にあり、ゲームは彼らに低コストで試行錯誤できる環境を提供します。ゲームを通じて、彼らはさまざまな役割やライフスタイルを試し、好奇心や探求心を満たすことができます。一方、年齢が成長するにつれて、個人の興味や価値観は徐々に安定し、ゲームが生活目標や興味関心に合わなくなる可能性があります。\n社交属性 同時に、ゲームも社交活動の一部となり、特に若年層にとって重要な役割を果たしています。彼らはゲームを通じて友人を作り、ソーシャルネットワークを構築し、ゲームが社交の架け橋となるのです。しかし、年齢とともに社交圈が安定するにつれて、社交ニーズはより成熟した方法で満たされるようになり、ゲームにおける社交的な役割は相対的に低下していきます。\nソーシャル属性：妹を連れて（メイトおもて） 国内においては、恋愛教育の不足により、幼少期には「しっかり勉強しろ」とだけ指導され、卒業後に突然「恋愛しろ」と言われることが珍しくない現象が見られます。学業や仕事が忙しかったり、コミュニケーションスキルが不足していたりして、現実生活で安定した感情的な関係を築けず、孤独感や注目されたいという欲求に悩む人が少なくありません。ゲームにおける「メイトおもて」と呼ばれる行為は、彼らがこのような欲求を満たす出口を提供します。 女性プレイヤーを助け、守ることで、自分が必要とされ、尊重されていると感じ、感情的な満足を得ることができます。\n同時に、ゲーム内のインタラクションルールが明確で、環境がコントロール可能であるため、現実生活の複雑さや不確実性とは対照的に、確定性と安全感を提供し、現実の交流における不確実性への恐怖を軽減します。しかし、長期的にはゲーム内の仮想的な充足感に依存することで、現実生活で健全な感情的な関係を築き、維持する能力が低下する可能性があります。\n現実のプレッシャー ゲームは、プレイヤーが一時的に現実世界でのストレスや課題、あるいは不快な感情から逃避するための仮想の世界を提供します。特に学業のプレッシャー、家庭の問題、人間関係の課題に直面している若者にとって、ゲームは慰めとリラックスを得るための手段となる可能性があります。\nゲームは通常、ミッションをクリアしたり、レベルを上げたり、敵を倒したりする際に達成感や承認を得られるように設計されています。若者はこのようなゲームに没頭することがあり、それは彼らがゲームの中で賞賛され認められているという感覚を得られるためです。この感覚は、現実生活で得ることが難しいかもしれません。\n年齢を重ねるとゲームをするのが好きになれなくなった 若い頃は、個人的な社会的な責任やプレッシャーが比較的少なく、ゲームに時間とエネルギーを費やす余裕がありました。仕事に入り、家庭を築くなど、社会的な責任が増えるにつれて、時間とエネルギーはより貴重になり、ゲームは時間の浪費としてではなく、優先順位の低いレジャー活動とはなりにくいものです。\n年齢を重ねるにつれて、人々の認知能力や興味関心も変化します。若い頃には、アクションが早く、グラフィックが美しいゲームに興味を持つかもしれませんが、経験を積むにつれて、戦略性、ストーリー性が強い、あるいは奥深いゲームを好むようになるかもしれません。もし市場に出回っているゲームがこれらの変化したニーズに応えられない場合、興味は自然と薄れてしまいます。\n","date":"2024-03-30","language":"ja","permalink":"https://ttf248.life/ja/p/games-multidimensionality-psychological-development-social-entertainment/","tags":["ゲーム","心理学","ソーシャル (sōsharu)"],"title":"ゲームの多面性：心理発達とソーシャルエンターテインメントの交差点","year":"2024"},{"categories":["金融知識データベース"],"content":"人民元の為替レートの変動と上海総合指数の下落は、主要中央銀行の動向、スイス国立銀行の予期せぬ利下げ、米国の経済データ、市場におけるインフレと利下げ期待の調整といった要因が複合的に作用したものです。これらの要因が為替市場と株式市場に影響を及ぼし、人民元の変動とA株市場の下落を引き起こしました。\nご提供いただいたリンクの内容に基づき、2024年3月22日の人民元の為替レートの状況は以下の通りです。\nドル/離岸人民元レートの突破: 当日オープンスで、人民元が下落し、ドル/離岸人民元は中盤で7.24から7.24926に上昇し、オンショアドルの中盤で7.22から7.22360に上昇しました。両方とも2023年11月17日以来の新たな高値を更新しました。記事執筆時までに、ドル/離岸人民元は7.26を突破し、最低7.2639まで下落し、トレンドも継続しています。 中央銀行の中間レート調整: 3月22日に、中国人民銀行は米ドルに対する中間レートを7.1004に発表し、62bp引き下げました。調整幅が拡大しました。 A株市場の反応: 多様な要因の影響により、当日はA株の大三指数が低迷して下落し、いずれも1%を超える水準で落ち込みました。 為替市場の変動原因: 香港の一大手部外貨取引員の資深なトレーダーは、為替市場の変動は主にスイス国立銀行による予期せぬ利下げによってドルが上昇したことと、米国経済が強調であり、インフレが粘着性を持つ可能性により、利下げが遅れることが原因であると説明しました。 主要中央銀行の動向: 本週は世界市場における「スーパー中央銀行週間」であり、米国、日本、英国、オーストラリアなど、複数の国の中央銀行が本週中に政策金利を決定します。スイス国立銀行は予期せぬ利下げを発表し、G10通貨中央銀行で自疫情発生以来初の利下げとなりました。これは市場のバランスを打ち破りました。 人民元の動向予測: 光大銀行金融市場部研究員の周茂華氏は、最近の人民元の変動は確かにあったものの、全体的な幅はドルなどの主要通貨よりもはるかに小さく、短期的な変動が年内の人民元の中立から上昇傾向を覆すことはないと予測しています。 ","date":"2024-03-23","language":"ja","permalink":"https://ttf248.life/ja/p/renminbi-exchange-rate-volatility/","tags":["為替レート","人民幣 (れんみょうひ)","外国為替 (がいこくわいふ)","A株 (エーショウ)","中央銀行","ドル"],"title":"人民元の為替レートは顕著な変動を示し、7.26を突破しました。","year":"2024"},{"categories":["コンピューター"],"content":"Python プログラミングにおいて、辞書は非常に強力なデータ構造であり、キーと値のペアを関連付け、効率的にデータを検索および操作することを可能にします。カスタムオブジェクトを辞書に格納しようとすると、通常、重要な概念である「Python におけるオブジェクト参照（参照渡し）」が問題となります。つまり、カスタムオブジェクトを辞書に入れる場合、辞書はオブジェクトへの参照を格納するだけであり、オブジェクトの完全なコピーを作成しているわけではありません。\nカスタムオブジェクトの基本的な例 以下の簡単な Person クラスを想定してください:\nclass Person: def __init__(self, name, age): self.name = name self.age = age # Person オブジェクトを作成 p1 = Person(\u0026#34;Alice\u0026#34;, 30) # オブジェクトを辞書に保存 people_dict = {} people_dict[\u0026#34;alice\u0026#34;] = p1 この例では、people_dict 辞書が \u0026quot;alice\u0026quot; というキーを持つ項目を含み、その値は Person 型の p1 オブジェクトへの参照です。 p1 の属性を変更すると:\np1.age = 31 辞書からオブジェクトにアクセスするときに、その年齢も更新されていることに気づきます:\nprint(people_dict[\u0026#34;alice\u0026#34;].age) # 出力: 31 これは、辞書が Person オブジェクトの独立したコピーを保存するのではなく、同じメモリ位置への参照を保存しているためです。\n深復元と浅復元の違い ネストされたデータ構造やカスタムオブジェクトを扱う場合、このような参照の動作は予期せぬ結果を引き起こす可能性があります。例えば、カスタムオブジェクトが可変型の属性（リストや別のカスタムオブジェクトなど）を含む場合、そのようなオブジェクトを辞書に直接格納し、その変更を加えると、辞書から取得したオブジェクトも影響を受けます。\nclass Address: def __init__(self, street, city): self.street = street self.city = city class Person: def __init__(self, name, age, address): self.name = name self.age = age self.address = address address = Address(\u0026#34;Main St.\u0026#34;, \u0026#34;Springfield\u0026#34;) p1 = Person(\u0026#34;Bob\u0026#34;, 40, address) people_dict[\u0026#34;bob\u0026#34;] = p1 # 原始アドレスオブジェクトを変更 address.city = \u0026#34;Shelbyville\u0026#34; # 辞書内の人のアドレスも変更される print(people_dict[\u0026#34;bob\u0026#34;].address.city) # 出力：Shelbyville 解決策：深復元\nこのような共有状態の問題を回避するためには、辞書がオブジェクトの完全なコピーを格納していることを確認する必要があります。つまり、参照ではなく、独立したコピーである必要があります。Python は copy モジュールにある deepcopy 関数を使用してこれを実現します。\nimport copy # オブジェクトを深復元で格納 people_dict[\u0026#34;bob_deepcopy\u0026#34;] = copy.deepcopy(p1) # 原始アドレスオブジェクトを変更しても、深復元されたオブジェクトには影響しない address.city = \u0026#34;Capital City\u0026#34; print(people_dict[\u0026#34;bob\u0026#34;].address.city) # 出力：Capital City print(people_dict[\u0026#34;bob_deepcopy\u0026#34;].address.city) # 出力：Capital City 要するに、Python で辞書を使用してカスタムオブジェクトを格納する場合は、デフォルトでオブジェクトの参照が格納されることに注意してください。独立した状態を維持する必要がある場合は、deepcopy を使用して深復元を行い、共有参照による予期せぬデータ変更を防ぐようにしてください。\n","date":"2024-03-22","language":"ja","permalink":"https://ttf248.life/ja/p/python-dictionary-custom-objects-reference-vs-deepcopy/","tags":["python"],"title":"Python辞書におけるカスタムオブジェクトの保存：参照と深いコピーの重要性","year":"2024"},{"categories":["魚の7秒間の見聞"],"content":"315 は実際には鶏骨泥の報道はなかった。この問題自体が、中央テレビ 3・15 晩会の公式暴露と同時期に発生した他の食品安全ホットスポット事件を混乱させている。\n知乎回答：新闻学 315晩会一共提了九个厂家，里面并没有淀粉肠，而现在搞得那些被提名的大品牌完全没热度，倒是把淀粉肠这种国民级（全国各地小吃街基本都会有并且摊位量应该也是第一）的小吃拉出来说事感觉淀粉肠完全就是被拉出来背锅的。我找了网上的新闻来源就是一个央广网在3.15那天发了个调查火腿肠的新闻，但也只是列出了几家厂家的成分，并且几个厂家也并不是主要生产淀粉肠的厂家，成分上并看不出什么毛病，然后这个b记者通过一个工厂员工说有时候用的是鸡骨泥替代鸡肉也就是听说，然后她就去淘宝问宠物食品店卖鸡骨泥的商家，人能不能吃？，这不是sb问题吗？人家一个宠物食品敢说让你人吃？然后后面就传谣传成淀粉肠里含的都有鸡骨泥，鸡骨泥人不能吃。\n现在搞得估计很多工厂都要关门，全国几十万的小摊贩都面临货砸手里没生意干的地步。\n315晩会において9社のメーカーが挙げられ、その中に澱粉腸は含まれておらず、現在話題になっている被指名された大手ブランドも熱意を失っている。それに対し、国民級（全国各地の小吃街に基本的にはあり、摊位数も第一）の澱粉腸を俎上に載せ、議論されているように感じられる。私はインターネット上のニュースソースとして、中央広播網が3.15日にハムの調査報道を行ったものを調べた。しかし、それはいくつかのメーカーの成分を列挙するだけであり、その中で主要な澱粉腸メーカーではない企業も多く、成分上、問題は見当たらない。その後、この記者が工場従業員の話を聞き、「時々鶏骨泥（けいこつねり）で鶏肉を代用している」と聞いたこと、そして「それを聞いて、彼女は淘宝（タオバオ）でペットフード店が販売する鶏骨泥の商家の人には食べられるのか？」と尋ねたことだ。これは明らかに馬鹿げた問題ではないか？ペットフードを販売する企業が人間に食べさせることを言うだろうか？その後、噂が広がり、「澱粉腸の中に鶏骨泥が含まれている」という誤った情報が流布された。鶏骨泥は人間には食べられないのだ。\n現在、多くの工場が閉鎖され、全国の数十万もの小摊贩（こたんぱん）が在庫切れで売り上げがないという状況に陥っていると推定される。\n人間の真実 潇湘晨報の17日報道によると、3月16日に河南省三門峡で発生した「澱粉腸の崩落」の2日後、あるおばあさんが澱粉腸を販売する出店を始めたが、2時間経っても全く人が現れず、最終的には自分自身で黙々と澱粉腸を食べた。撮影者は、「普段一人で澱粉腸を4～5本食べるが、澱粉腸の中に鶏骨と泥が入っていることを知り、食べないという決断をした」と語る。その日、彼は事件が暴露されることで誰か買ってもらえるかどうか好奇心を持って見守っていたが、2時間も売れずに1本も売らなかった摊贩（たんばん：屋台）を見て愕然とした。\nおばさんは何があったのか全く知らず、ただ今日の突然の客の減少を知っただけだ。 おばあさんの言う通りだ。彼女はただ生活を立てるために生きているだけで、製品に問題があることや、それが合格品であること、また「骨泥（こつねり：鶏骨と泥の混合物）」とは何かを知らなかった。彼女たちはインターネットを知らず、ただ底辺の人々が生き残るための方法を模索しているだけだ。 澱粉腸は崩落したが、その代償を払っているのは、個々の底辺の営業者たちだ。これは苦痛なプロセスだ。 知恵袋回答：規制不利 数年前の一度の午後、私は北漂（北京生まれの人が使う言葉）の同僚と昼食に向かい、あるソーセージや鉄板焼き肉串を売る屋台を通りかかった。 私は随気なく言った。「今の様な黒科技（最新技術）の淀粉ソーセージ、鉄板肉串がまだ食べられるのか？」なぜなら、私の考えでは、最後に淀粉ハムソーセージを食べたのは大体10年以上前だったからだ。 同僚はしばらく躊躇し、そして婉曲的に言った。「あなたはきっと大都市で暮らしているからそう思うんだ。実はうちの故郷のような小さな町では、塩辛い野菜、インスタントラーメン、ハムソーセージが毎日の生活なんだ。」 「私が学校に通っていた頃は、満点を取れば父に買ってくれる焼き肉串があった。衛生面の問題ではなく、焼き肉串を買うには1.5元しかかけられないから、2キロの青菜を買えるからだ。」 「便利本（インスタントラーメン）、炭酸飲料、スナック菓子を『駄洒落食品』と言うのは、北京で大学に通っていた頃に初めて聞いた。」 私は自分が無心な言葉の中に含まれていた傲慢さに気づき、黙って何も言わなくなった。しかし、この一件は私にとって非常に印象深いものとなった。 実際には、これが中国の大衆の日常だ。 彼らの生活には、高尚な「地中海式食事」「緑色有機野菜」「非遺伝子組み換え大豆」といったものは存在しない。彼らはただ、安くて美味しい野菜、肉類、スナック菓子を手に入れることができるかどうかを心配するだけだ。家族全員が、ほんの少しの幸福な瞬間を楽しむ。 そして棚にあるものは、どのような成分でできているのか、健康に害を与える可能性があるのか、奇妙な化学物質が含まれていないかなど、考えた。 本来、彼らが気にする必要も理解する必要もなかったのだ。 彼らはただ、問題のあるものがあれば誰かがきちんと管理してくれると素直に信じていた。 しかし、315の番組を見て初めて気づいたのだ。 市場にある電子秤やガソリンスタンドの給油機が、高度な技術で改造されたマザーボードを隠し持っていて、アップロード（動画投稿）する人たちが体罰を受けるリスクを冒して動画を撮影しなければならないこと。規制当局が「ようやく」気づいて調査・取り締まること。 ライブ配信での梅菜肉（梅干しと豚肉の煮込み料理）、屋台での淀粉ソーセージが、腐った肉や骨粉を使って作られていて、央視（中国中央電視台）の記者たちが臥底（潜入捜査）して撮影した映像で初めて明らかになること。そして、その供給源を調査し、追跡すること。 テレビ番組や空港広告で大々的に宣伝される「健康酒」が、誰かが動画を撮影して暴露することで、一夜にして緊急撤去され、市民の目に消えていくこと。 年に一度の315。毎回、数個の製品が抽選で取り上げられるだけで十分なのか？ すでに食べた、買った消費者は、誰に訴えることができるだろうか。\n","date":"2024-03-18","language":"ja","permalink":"https://ttf248.life/ja/p/sausages-and-street-vendors-capital-news-influence/","tags":[],"title":"澱粉腸と路端の屋台：資本のニュースへの影響力 (Dōhin'garu to rukan no yatai: Capita no nyūsu e no eikyoku)","year":"2024"},{"categories":["コンピューター"],"content":"自宅のネットワークを驚くほど高速にしたいですか？鍵はケーブルの種類、光猫、ルーターの設定、そして些細なディテールを知ることです。この記事では、6種類のケーブルを使ってテラビット級のネットワークを構築する方法と、簡単なデバイスチェックと設定で、あなたのネットワーク速度が制限されないようにすることについて、簡単に解説します。さあ、一緒に探求し、自宅のネットワーク速度を飛躍的に向上させましょう！\n第1章：ネットワーク伝送媒体の徹底分析 千Gb級ネットワーク接続を実現する際、情報を高速に伝送するための担い手であるケーブルが極めて重要な役割を果たします。以下では、カテゴリ5、カテゴリ6、カテゴリ7ケーブルについて詳細な解説を行います。\n1. 五類ケーブル（CAT5） 五類ケーブル、別名CAT5は、最も普及した初期のツイストペアケーブルの一種であり、各対線芯を精密ならせん構造で設計することで、クロスプレーク（串扰）を低減します。主に10/100Mbpsの高速以太ネットで使用され、最大伝送周波数約100MHzですが、現在の千ギガビット級、さらにはそれ以上の速度を求めるニーズにおいては、物理的な制限から五類ケーブルは要求を満たせません。\n2. 六類ケーブル（CAT6） 技術の発展に伴い、六類ケーブルが登場しました。五類ケーブルと比較して、六類ケーブルはより厳格な製造基準と先進的な構造設計を採用しており、干渉耐性を大幅に向上させ、伝送効率を高めています。1Gbpsまでの伝送速度をサポートし、理想的な条件下では伝送距離が100メートルにも達するため、千兆ネットワークへの接続要件を満たすのに適しています。\n3. 七類ケーブル（CAT7） 七類ケーブルは、現在のツイストペア技術における最先端の水準を代表しています。伝送速度において飛躍的な向上を実現し、理論上では最大10Gbpsの超高速率をサポートするだけでなく、設計段階で完全なシールドシステムを採用しており、各配線対間のシールドに加え、全体の外層シールドも含まれています。これにより、外部電磁干渉や近傍串波を大幅に低減し、データ伝送の安定性と正確性を保証します。ただし、七類ケーブルは主に将来の10Gbイーサネットまたは特定の要件の高い環境向けに使用されます。\n千兆家庭ネットワーク環境における構築において、千兆光ファイバの潜在能力を最大限に引き出すためには、六類ケーブルが最も経済的かつ効率的な選択肢となります。また、すべての接続ケーブルの品質が合格していることを確認し、標準的な配線方法に従って作業を行うことも、ネットワーク性能を確保するための重要な要素です。\n第2章：深層ウェブの中枢デバイスの調査 - 光猫、ルーターLANポート帯域幅の影響 光猫とそのLANポート帯域幅の重要性 光猫（光ファイバーモジュレーター・デコーダー）は、家庭用ブロードバンド接続における主要な機器であり、その機能は光ファイバー内の光信号をデジタル信号に変換し、家庭内ネットワークデバイスで使用するために供与するものです。千兆光回線ユーザーの場合、光猫が千兆伝送をサポートしているかどうかが特に重要になります。もし光猫のWANポートが10Gb（百兆）のみをサポートする場合、入宅光ファイバーの速度が高くても、このボトルネックによって10Gb以内に制限されてしまう可能性があります。同様に、光猫のLANポートも千兆出力能力を備えている必要があり、それ以外に接続されるルーターやその他のデバイスが、その真の千兆レートを取得できないのです。\nルーターLANポート帯域幅の役割 ルーターのLANポートは、受信したデータを各ターミナルデバイスに配布する役割を担います。ルーターのLANポートが単に10Gb（百兆）である場合、他のデバイスの設定がどれほど優れていても、局所網通信は10Gbのレートに制限されます。したがって、千兆家庭ネットワークを構築する場合、ルーターのWANポートが千兆データを受信し、LANポートも千兆レベルのデータ出力能力を提供できるようにすることが重要です。これにより、ご自宅のすべてのスマートデバイスが高速ネットワークによるスムーズな体験を楽しむことができます。\nさらに、一部の古いまたは低端のルーターには、LANポートレート自動交渉メカニズムが存在する場合があります。これは、ルーター自体が千兆をサポートしていても、ケーブルやデバイスの互換性などの理由により10Gbモードに降格してしまう可能性があることを意味します。したがって、ルーターパラメータを正しく設定し、強制千兆モードを有効にし、千兆スイッチまたは直結デバイスと組み合わせて使用することは、全千兆ネットワークを実現するための重要なステップの一つです。\n千兆光ファイバーにアップグレードした場合、必ず千兆光モデムと千兆ルーターに交換し、すべてのデバイスのインターフェースが千兆レベルであることを確認してください。\n第3章：隠された謎 – 一本の断線したサブラインがテラバイト級ネットワークの速度にどのように影響するか 子線故障とネットワーク性能の低下 測定期間中にネットワークが常に接続を維持し、明らかな切断状態は発生しませんでした。これは新入戸でのブロードバンド導入であり、弱電箱内に配線が散らかっており、光猫のケーブルや電源インターフェース、延長コードの位置を時々調整していたため、偶発的に測定速度が千兆に達することがありました。\n上記の資料に基づき、ケーブルの種類、光猫のLANポート速度などを分析・調査しましたが、最終的には原因はケーブル内部の一本の茶色の子線が断裂していることが判明しました。\n断裂の原因：作業員が水晶頭を設置する際に、このケーブルを少し強く引っ張ったため、子線が半分ほど断ち切られ、完全に切り離されずにいました。その後、光猫の位置を調整する際に、繰り返し移動させることで、最終的に完全に断裂してしまいました。\nケーブルの種類8本の機能解析 六類網線はTIA/EIA-568-B規格に準拠し、8本の双絞り線を含みます。以下のカラーコードに従っています：\n白橙 / 橙 (しろおげ / おげ) 白緑 / 緑 (しろりょく / りょく) 白藍 / 藍 (しろらん / らん) 白棕 / 棕 (しろしゅん / しゅん) 千兆イーサネット（1000BASE-T）の規格下では、これらの8本の線の中から4対の線が同時に動作します。具体的な役割分担は以下の通りです：\n白橙と橙のペア (1\u0026amp;2) は、送信データ (Tx+/-) 用です； 白緑と緑のペア (3\u0026amp;6) は、受信データ (Rx+/-) 用です； 白藍と藍のペア (4\u0026amp;5) および白棕と棕のペア (7\u0026amp;8) は、千兆イーサネットでは当初は副用ですが、高度なアプリケーション（例えば、一部PoE給電や将来の技術拡張など）で有効化されることがあります。従来の100Gbイーサネットでは、1, 2, 3, 6 の4本の線を使用するだけで十分です。 断裂子線がネットワーク速度に与える影響 上記の場合において、もし一根褐色の子線（すなわち棕線または棕白線）が断裂した場合、理論上は千兆ネットワーク環境下で速度低下を引き起こす可能性があります。なぜなら、千兆ネットワークでは、すべての四対の線が同時に双方向で伝送することで満速を実現する必要があるためです。しかしながら、家庭用ネットワーク機器には自動ネゴシエーション機能が搭載されており、ケーブルに問題が検出された場合、正常に動作する低いレートモード（百兆モード）に回帰します。これが、一根子線が断裂してもネットワークが接続を維持し、百兆速度で動作を続ける理由を説明しています。\n要するに、一根棕色の子線が断裂しても百兆ネットワークの基本的な動作には影響しませんが、千兆ネットワーク環境下では、それがネットワーク速度を制限する重要な要因となる可能性があります。詳細な診断と修復を行うまで、その潜在的な能力は十分に発揮されません。また、この状況は、類似の問題が発生した際に、ネットワークインフラストラクチャ上の潜在的な問題を無視しないように警告しています。たとえ基本的な接続に影響を与えないように見える小さな故障であっても、高速ネットワーク体験の隠れた障害となる可能性があります。\n","date":"2024-03-18","language":"ja","permalink":"https://ttf248.life/ja/p/gigabit-fiber-slow-speed/","tags":["ネットワーク","トラブルシューティング"],"title":"新規に設置した10Gbps光回線なのに、なぜ速度が1Gbpsしか出ないのか？","year":"2024"},{"categories":["コンピューター"],"content":"デスクトップアプリケーションの開発、特にWindows Presentation Foundation (WPF) などのフレームワークを使用してリッチクライアントアプリケーションを構築する際には、ユーザーインターフェース（UI）スレッドの適切な処理が、アプリケーションの応答性やスムーズな動作を保証するために非常に重要です。UIスレッド、またはメインスレッドとは、ウィンドウやコントロールのイベント、レイアウト計算、および画面表示の描画を担当するコアとなるスレッドです。UI要素とやり取りするすべての操作は、UIスレッド上で実行する必要があります。これは、WPFをはじめとするほとんどのGUIフレームワークが遵守する基本的な原則です。\nUIスレッドとは？ UIスレッドは、WPFアプリケーションが起動される際にオペレーティングシステムによって作成され、初期化されるアプリケーションのメインウィンドウです。これは、アプリケーション内でUIコンポーネントの状態を直接アクセスし、変更できる唯一のスレッドです。つまり、ボタンのクリック、テキストボックスへの入力、ウィンドウサイズの変更など、すべてのユーザーインタラクションによって発生するイベントは、このスレッドコンテキストで処理されます。さらに、WPFの依存性プロパティシステム、データバインディングメカニズム、レイアウトロジックもすべてUIスレッド上で同期的に実行されます。\nUIフリーズとその原因 UIスレッドが長時間占有またはブロックされると、例えば、時間のかかる計算、大量のデータ読み込み、データベースクエリ、その他のI/O密度の高いタスクを実行する場合、UIスレッドはユーザーからのインタラクションリクエストにタイムリーに対応できなくなり、結果として画面がフリーズ（Freeze）、つまり私たちがよく言う「カドト」が発生します。このような場合、ユーザーはアプリケーションの遅延や不自然さを明確に感じ、最悪の場合、「Application Not Responding」（ANR）警告が表示されます。\nUIスレッドの基本ルール２つ 上記のような状況を回避するため、WPF開発者は以下の２つの重要なルールに従う必要があります。\nUIスレッドで時間がかかる処理を実行しない: UIスレッドがブロックされる可能性のある操作は、可能な限りバックグラウンドスレッドで実行し、UIスレッドがユーザーの入力や画面の変化に迅速に対応できるようにする必要があります。\n非UIスレッドから直接UI要素を更新しない: WPFのセキュリティメカニズムにより、UIスレッドのみがUI要素の変更を行う権限を持っています。他のスレッドから直接UIの状態を変更しようとすると例外が発生します。したがって、バックグラウンドスレッドで計算やデータ準備が完了した後でも、適切なクロススレッド通信メカニズムを使用して結果をUIに表示する必要があります。\n解決策：非同期プログラミングとスレッドセーフなアップデート UIのフリーズを防ぎつつ、時間のかかるタスクを実行するために、WPFは、開発者がこの目標を達成するためのさまざまな非同期プログラミングモデルやツールを提供しています。\nDispatcherオブジェクト: WPFのDispatcherクラスを使用すると、タスクをUIスレッドのキューに追加して実行できます。Dispatcher.InvokeまたはDispatcher.BeginInvokeメソッドを使用して、バックグラウンドスレッドからUIを安全に更新できます。 async/awaitキーワード: C#言語の非同期特性を活用し、awaitキーワードを使用してバックグラウンドタスクが完了するのを待機し、完了後にUI更新コードを実行する非同期メソッドを作成できます。 ケース (ケース) / 例 (れい) Dispatcher.Invokeメソッドを使用してUIを更新する private void Button_Click(object sender, RoutedEventArgs e) { // これは時間のかかる操作であると仮定します Task.Run(() =\u0026gt; { var result = LongRunningOperation(); // ここは時間のかかる計算メソッドのシミュレーションです // 時間のかかる操作が完了したら、UIスレッドでUIを更新します Application.Current.Dispatcher.Invoke(() =\u0026gt; { LabelStatus.Text = $\u0026#34;結果: {result}\u0026#34;; }); }); } private string LongRunningOperation() { // 時間のかかる操作をシミュレーションします Thread.Sleep(5000); return \u0026#34;完了\u0026#34;; } async/awaitキーワードとTask.Runの組み合わせ private async void Button_ClickAsync(object sender, RoutedEventArgs e) { Button button = sender as Button; button.IsEnabled = false; // ユーザーが繰り返しクリックするのを防ぐ try { // バックグラウンドタスクを開始 var result = await Task.Run(() =\u0026gt; LongRunningOperation()); // バックグラウンドタスクが完了したら、UIスレッドに自動的に切り替えてUIを更新 LabelStatus.Text = $\u0026#34;計算結果: {result}\u0026#34;; } catch (Exception ex) { MessageBox.Show($\u0026#34;エラーが発生しました: {ex.Message}\u0026#34;); } finally { button.IsEnabled = true; // ボタンを再度有効にする } } ","date":"2024-03-12","language":"ja","permalink":"https://ttf248.life/ja/p/wpf-ui-thread-and-freezing-solutions/","tags":["wpf","c#","トラブルシューティング"],"title":"WPFにおけるUIスレッドとフリーズ問題とその解決策","year":"2024"},{"categories":["コンピューター"],"content":"同一段業務コードにおいて、プログラムが CentOS 7 環境下で正常にコンパイルおよび実行されていたが、CentOS 8 に切り替えて GCC の最新版を使用してコンパイルを行った際に、プログラムがクラッシュが発生した。注目すべきは、問題が Release モード 下でのみ発生し、Debug モード では完全に問題がない点である。これは初めての事例であり、3日間の調査を経て、問題の原因を特定することができた。\n問題の特定 一番の原因究明の結果、問題の本質は 関数に返り値がないこと にあります。リリースモードにおいて、GCCの新バージョンではより多くの最適化が行われるため、本来返り値のない関数が実行中に未知の論理が発生し、それがクラッシュを引き起こしました。結論として、コンパイラの警告を無視することは許されません。特に、古いプロジェクトにおいては、一部の警告が無視される可能性がありますが、すべての警告を無効にすることは避けるべきです。\n環境説明 CentOS 7 GCCバージョン: CentOS 8 GCCバージョン: クラッシュ現象 プログラムのクラッシュに関するスタックを分析した結果、以下のスタック情報が得られました：\n[New LWP 1385902] [Thread debugging using libthread_db enabled] Using host libthread_db library \u0026#34;/lib64/libthread_db.so.1\u0026#34;. Core was generated by `./pstack_main`. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007ffe894b4420 in ?? () (gdb) bt #0 0x00007ffe894b4420 in ?? () #1 0x00000000004008e9 in main () このスタックは直感的ではありません。クラッシュ関数のスタック情報が ?? と表示されるため、問題の特定がさらに複雑になります。\nコード例 問題をより良く理解するために、クラッシュを再現するための最小コード例を示します。\n#include \u0026lt;iostream\u0026gt; #include \u0026lt;map\u0026gt; int test() { std::cout \u0026lt;\u0026lt; \u0026#34;1\u0026#34; \u0026lt;\u0026lt; std::endl; } int main() { test(); return 0; } このコード内の test() 関数は明らかに値を明示的に返していません。また、その戻り値の型は int です。C++ 仕様によると、関数が int 型で宣言されている場合、必ず戻り値を持つ必要があり、そうでない場合は未定義動作を引き起こす可能性があります。\nコンパイル警告 当方のプロジェクトにおいて、CMake スクリプトが多くのコンパイル時の警告を抑制しており、その中に以下の警告情報が含まれています。\n/root/pstack/main.cpp: In function ‘int test()’: /root/pstack/main.cpp:7:1: warning: no return statement in function returning non-void [-Wreturn-type] この警告は、test() 関数が戻り値を持たないことを示しており、これがまさに問題の原因です。GCC の高バージョン（例：8.5.0）では、コードを最適化する際にこのような未定義の動作に対して不安定な最適化を行う可能性があり、プログラムがクラッシュする原因となることがあります。\n어셈블리 코드 차이점 GCC 컴파일러 최적화 동작의 차이를 설명하기 위해, 서로 다른 버전의 GCC가 생성한 어셈블리 코드를 비교했습니다.\nGCC 4.8.5 생성된 어셈블리 코드: 어셈블리 코드가 다소 길고 표준 출력 스트림(예: std::cout) 처리에 대한 로직을 포함하고 있습니다. 이는 컴파일러가 test() 함수에서 누락된 반환 값 문제에 대해 과도하게 최적화하지 않았음을 나타내며, 이로 인해 잠재적으로 충돌을 피했을 수 있음을 시사합니다. GCC 8.5.0 생성된 어셈블리 코드: 새로운 버전의 GCC는 더 많은 최적화를 수행하여 코드 양을 줄였습니다. 그러나 이러한 최적화가 누락된 반환 값을 갖는 함수의 실행 시 동작이 불확실하게 되어 프로그램 충돌을 유발할 수 있습니다. 結論 今回の問題解決を通して、C++において関数が返す値は明確に定義されるべきであるという点を深く認識しました。特に、関数をint型として宣言する場合、必ず戻り値を提示する必要があります。古いコンパイラ版を使用しているプロジェクトでGCCの新しいバージョンにアップグレードした場合、より多くの最適化や厳格な警告メカニズムが導入される可能性があります。そのため、コンパイル時にすべての警告を無効化しないことを推奨します。代わりに、関数が返す値、型の一致など、一般的な問題に対して選択的に対処する必要があります。 最終的に、test()関数に戻り値を付与することで問題は解決し、プログラムは正常に動作するようになりました。\n","date":"2024-03-10","language":"ja","permalink":"https://ttf248.life/ja/p/gcc-upgrade-causes-program-crash-code-irregularities/","tags":["c++","linux","トラブルシューティング"],"title":"GCCバージョンをアップグレードした結果、プログラムがクラッシュしました：コードの非規整性による問題点","year":"2024"},{"categories":["コンピューター"],"content":"背景：ローカルマシンにデプロイされたWindows版の業務システムで、CPU使用率が約5％です。VMwareにインストールしたCentOS8上にLinux版の業務システムをデプロイし、リソース使用量に異常が見られます。\n問題の記述 宿主机：win10 企业版 VMware：17.5 仮想マシン：centos8 仮想マシンのリソース配分は4C8GBで、ビジネスシステムを起動します。ビジネスシステムが仮想マシンLinuxシステムにデプロイされており、仮想マシン内部のtopコマンドでシステムのリソース使用率を確認すると、CPU使用率は高くありません。しかし、外側のWindowsシステムでタスクマネージャーを見ると、CPUリソース使用率は非常に高くなっています。プロセスを確認すると、VMware プロセスがCPUリソースを大量に使用しています。 +\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;+ | Windows | | | | +\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;+ | | | VMware | | | | Program | | | +\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;+ | | | +\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;+ 知識点 この問題のトラブルシューティングは、スムーズに進まず、原因はビジネスシステム自体ではなく、仮想マシンの問題にある。通常のビジネスコードからの思考を、システム負荷に転換し、さらに負荷データの異常から、スワップ中断へと追跡し、最終的に重要なポイントにたどり着くには、VMwareのスワップ中断のパフォーマンスに影響を与えるものは何か？ 本稿ではまず各知識点を解説し、最後に解決策を示す。\nHyper-V Windowsオペレーティングシステムの仮想化技術において、大きな変革がありました。Microsoftが最初にWSL（Windows Subsystem for Linux）をリリースした際、Hyper-Vサービスを有効にすると、VMware仮想マシンの同時使用ができなくなっていました。その後、バージョンアップにより、VMwareはHyper-Vサービスと互換性を持つようになりました。\nシステム負荷 Linuxシステムにおいて、「負荷」（load）とは、実行中または実行を待っているプロセスの数です。負荷は通常、1分間、5分間、および15分間の実行キュー内の平均プロセス数を表す3つの数字で示されます。これらの数字は、「uptime」コマンドまたは「top」コマンドを実行することで確認できます。\n具体的には、この3つの数字はそれぞれ以下の意味を持ちます。\n1分負荷: システムが過去1分間に実行キュー内に存在していた平均プロセス数です。 5分負荷: システムが過去5分間に実行キュー内に存在していた平均プロセス数です。 15分負荷: システムが過去15分間に実行キュー内に存在していた平均プロセス数です。 負荷の概念は、システム内で待っているプロセスの数です。この数値が高い場合、システムに多くのプロセスがCPUリソースを待機していることを意味し、システムが遅くなるか応答しなくなる可能性があります（ただし、負荷の高さとシステムの構成およびパフォーマンスによって異なります）。\n理想的には、負荷はシステムの論理CPU数の範囲内に保つことが望ましく、これによりシステムのパフォーマンスを最適化できます。負荷が継続的にCPU数を超過する場合、システム内のプロセスを分析して負荷の原因を特定し、適切な対策を講じることで、リソース割り当てを調整したり、プロセスの実行方法を最適化したりすることができます。\n負荷の分析 - mpstat mpstatコマンドは、個々のプロセッサまたは複数のプロセッサに関するさまざまな情報を報告するために使用されます。これには、平均負荷、CPU利用率、割り込み、コンテキストスイッチングなどが含まれます。sysstatパッケージの一部として、mpstatはシステムの負荷状況を分析するための非常に便利なツールです。以下に、mpstatを使用して負荷を分析する手順を示します。\nsysstatのインストール: システムにsysstatがインストールされていない場合は、使用しているシステムに適したパッケージマネージャを使用してインストールしてください。 mpstatの実行: mpstatコマンドを実行して、CPUの使用状況と負荷を確認します。デフォルトでは、mpstatは1秒ごとにCPU利用率の平均値を表示します。出力頻度を調整するには、時間間隔を指定できます。たとえば、mpstat -P ALL 2を使用して、毎秒1回mpstatを実行し、irqで割り込みの使用状況を確認します。 出力の分析: mpstatの出力には、各プロセッサの利用率とシステムの平均負荷が含まれています。平均負荷と各プロセッサの利用率に特に注意してください。これにより、システムの負荷状況を理解できます。負荷が高い場合は、どのプロセスが原因であるかをさらに分析し、パフォーマンスボトルネックがないか確認します。 他のツールの併用: mpstatに加えて、sar、pidstat、iostatなどのツールを使用して、システム全体のパフォーマンスを総合的に分析できます。複数のツールの出力を組み合わせることで、システムの負荷状況をより包括的に理解し、パフォーマンスの問題の根本原因を特定することができます。 割り込み 本内容は詳細に説明しないため、過度な解説は省略します。 推奨: アプリケーション開発者向けシステムガイド CPU編 - ソフトウェア割り込み 頻繁にソフトウェア割り込みをトリガーすると、システム負荷にも反映されます。\n問題のトラブルシューティング CPUのみから分析するだけでは問題の原因を特定できないため、システムに異常が発生しているのではないかと疑うべきでしょうか。おそらくLinuxオペレーティングシステムの負荷が高くなり、VMwareが過剰なCPUリソースを使用している可能性があります。mpstatを使用してローカル仮想マシンを分析したところ、irqの使用量が異常で、単一コアあたり25%近く占めており、正常時にはビジネスプロセス起動時に空転する場合、irqの割合は約5%程度であるはずでした。\nグループ内の同僚の開発環境では、CentOS 7がVMware上でデプロイされており、リソース使用量は正常でした。一方、上海の開発環境では、VMware上にデプロイされていましたが、ホストマシンのCPUリソース状況を直接観察することはできませんでした。この時、当社は複数の変数に直面していました：VMware仮想マシン、Linuxオペレーティングシステム、GCCバージョン。\nそこでテスト環境を分析することにしました。深圳のテスト環境は物理マシン上にデプロイされており、低バージョンのGCCでコンパイルされたサービスを実行し、CentOS 8上で動作していました。興味深いことに、深圳環境ではirqの使用量は正常でした。\nGCCバージョンに関連する問題が原因である可能性を調査するために、高バージョンのGCCでコンパイルしたプログラムを深圳環境にデプロイしてテストしましたが、結果も正常でした。\n問題は徐々に明確になってきました。オペレーティングシステムに問題があるのではないかと疑い始めました。毕竟、CentOS 8はすでに公式サポートを受けていないためです。しかし、純粋なCentOS 7とCentOS 8を再デプロイしても問題は解決しませんでした。\nこの時、当社は唯一の不確実要素、つまりVMware仮想マシンソフトウェアに疑念を抱くようになりました。突然、閃きが起こり、Hyper-V技術が以前有効になっていたものの、完全にシャットダウンされなかったのではないかと考えました。毕竟、ソフトウェア中断も仮想マシンソフトウェアを通じて実現されるためです。異なる仮想マシン仮想化技術にはバグが存在する可能性があります。これらの問題は深く考える価値があります。\n結論 マイクロソフト公式のマニュアルに従い、本機のHyper-Vサービスを完全に停止した後、VMwareがホストマシン上で正常に動作することが確認されました。これで問題はついに解決に至りました。当初述べたように、この経験は曲折で困難なものであり、包括的な分析と判断が必要でした。また、今回初めて問題を調査し、仮想マシンというレベルまで特定することができました。\nDisable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor bcdedit /set hypervisorlaunchtype off https://learn.microsoft.com/zh-cn/troubleshoot/windows-client/application-management/virtualization-apps-not-work-with-hyper-v ","date":"2024-03-10","language":"ja","permalink":"https://ttf248.life/ja/p/vmware-virtual-machine-cpu-usage-anomaly/","tags":["vmware","トラブルシューティング"],"title":"VMware仮想マシンのCPUリソース使用率異常","year":"2024"},{"categories":["コンピューター"],"content":" この記事では、C++プログラミングにおける`std::map`コンテナの不適切な使用がプログラムクラッシュを引き起こす可能性を明らかにします。中括弧演算子を使用して存在しないキーにアクセスすると、自動的に空の要素が追加されます。私たちはこの誤解を深く掘り下げ、具体的なコード例を通じてその潜在的なリスクを示します。 単純な値を格納することには問題ありませんが、ポインタを格納する場合の問題が発生します。なぜなら、ポインタはアドレスであり、初期化されていない場合、そのアドレスは不定形になるため、プログラムクラッシュを引き起こす可能性があるからです。 正文 std::map は C++ 標準ライブラリにおける連想コンテナであり、キー（key）を昇順にソートして要素を格納し、効率的なキーワード検索機能を提供します。しかし、初心者開発者は std::map の中括弧演算子 [] の動作について理解不足なために困惑することがあります。実際には、[] を使用して存在しないキーにアクセスすると、std::map は新しいキー値ペアを挿入し、デフォルトコンストラクタを使用してそのキーに対応する値の型を初期化します。\n#include \u0026lt;iostream\u0026gt; #include \u0026lt;map\u0026gt; int main() { std::map\u0026lt;std::string, int\u0026gt; myMap; // 誤った使い方：存在しないキーにアクセスし、0 が返ると仮定する std::cout \u0026lt;\u0026lt; \u0026#34;Value for \u0026#39;nonexistent_key\u0026#39;: \u0026#34; \u0026lt;\u0026lt; myMap[\u0026#34;nonexistent_key\u0026#34;] \u0026lt;\u0026lt; std::endl; // 実際には、上記の行は新しいキー値ペアを作成し、その値を int のデフォルト値（通常は 0）で初期化します。 return 0; } このコードは直接プログラムをクラッシュさせませんが、このような暗黙的な挿入動作は、リソースリークや予期しない状態の変更など、いくつかの状況で意図しない副作用を引き起こす可能性があります。さらに悪いことに、マルチスレッド環境での未初期化メモリ領域への同時アクセスにより、プログラムがクラッシュする可能性もあります。\nこれらの問題を回避するために、std::map::find() または std::map::count() メソッドを使用してキーの存在を確認するか、std::map::insert() を使用して明示的に要素を挿入することをお勧めします。\nstd::map\u0026lt;std::string, int\u0026gt; safeMap; if (safeMap.count(\u0026#34;nonexistent_key\u0026#34;) == 0) { std::cout \u0026lt;\u0026lt; \u0026#34;Key does not exist.\u0026#34; \u0026lt;\u0026lt; std::endl; } else { std::cout \u0026lt;\u0026lt; \u0026#34;Value for existing key: \u0026#34; \u0026lt;\u0026lt; safeMap[\u0026#34;nonexistent_key\u0026#34;] \u0026lt;\u0026lt; std::endl; } // または、キーと値を明示的に挿入する safeMap.insert({ \u0026#34;new_key\u0026#34;, 0 }); マップコンテナ内のオブジェクトがポインタ型の場合、暗黙的な挿入動作は未初期化のポインタを保存し、そのポインタへの呼び出しはプログラムのクラッシュにつながります。\n","date":"2024-03-10","language":"ja","permalink":"https://ttf248.life/ja/p/cpp-programming-traps-std-map-crash-details/","tags":["c++","トラブルシューティング"],"title":"C++プログラミングにおける罠：`std::map`の誤用がプログラムをクラッシュさせることの詳細な解説","year":"2024"},{"categories":["コンピューター"],"content":"ソフトウェア開発および運用において、プロセスがフリーズしてしまう状況は頻繁に発生します。この状態はシステム性能の低下やサービスの停止を引き起こす可能性があります。本稿では、pstackツールを使用してプロセスフリーズの問題を診断する方法について解説します。プロセスのスタック情報を分析することで、問題の原因を特定し解決策を見つけ出すことができます。\n背景：リスク管理システムの子サービスでフリーズが発生し、リスク管理サービスが利用不可となりました。可用性監視の欠如により、プロセスフリーズの状態を早期に検知することができず、システム全体が停止するという事態に至りました。\n本文 プロセスのフォジー（ゾンビプロセス）とは、プロセスが応答を停止しているにもかかわらず、終了していない状態を指します。この状況は、デッドロック、リソースの枯渇、例外など、さまざまな原因によって引き起こされる可能性があります。これらの問題に対処するためには、pstack ツールを使用してプロセスのスタック情報を分析し、根本原因を特定することができます。\nステップ pstack は一般的なツールで、通常は gdb (GNU デバッガ) と共に提供されます。以下のコマンドでインストールできます：\nsudo apt-get install gdb プロセスのIDを取得する: まず、スタックされたプロセスのプロセスID (PID) を取得する必要があります。ps コマンドを使用してすべてのプロセスをリストし、調査対象のプロセスIDを見つけます。\npstack ツールを使ってプロセスのスタック情報を分析します。プロセスIDを取得したら、以下のコマンドを実行してスタック情報を取得できます：\npstack \u0026lt;PID\u0026gt; これにより、現在の呼び出しシーケンスで実行中の関数が示されたプロセスのスタック情報が出力されます。この情報を分析することで、プロセスが停止した場所を特定し、問題の診断に役立てることができます。\nスタック情報を分析する: スタック情報を確認することで、プロセスがスタック状に停止している原因を見つけることができます。ロックによる競合状態、無限ループ、またはその他の異常な状況などが見つかる可能性があります。具体的な状況に応じて、適切な対策（ロックの解放、コードロジックの修正など）を講じてください。\n実行例 簡単なデモで、main関数が起動した後、新しいスレッドを作成し、実際の関数を実行することで無限ループに陥り、プログラムが正常に終了できず、偽の停止状態になります。\ncmake_minimum_required(VERSION 3.0.0) project(pstack_main VERSION 0.1.0 LANGUAGES C CXX) include(CTest) enable_testing() # スレッドライブラリを検索 find_package(Threads REQUIRED) add_executable(pstack_main main.cpp) # スレッドライブラリへのリンク target_link_libraries(pstack_main PRIVATE Threads::Threads) set(CPACK_PROJECT_NAME ${PROJECT_NAME}) set(CPACK_PROJECT_VERSION ${PROJECT_VERSION}) include(CPack) #include \u0026lt;iostream\u0026gt; #include \u0026lt;thread\u0026gt; #include \u0026lt;chrono\u0026gt; void infiniteLoop() { while (true) { // メインスレッドが無限ループに陥る } } int main() { std::thread thread(infiniteLoop); // 無限ループを実行する関数を持つスレッドを作成 thread.join(); // スレッドの終了を待つ return 0; } プログラムを実行し、pstackの結果を確認します。\nThread 2 (Thread 0x7eff3619b700 (LWP 1315017)): #0 infiniteLoop () at /root/pstack/main.cpp:6 #1 0x0000000000402ca9 in std::__invoke_impl\u0026lt;void, void (*)()\u0026gt; (__f=@0x2260eb8: 0x4029a6 \u0026lt;infiniteLoop()\u0026gt;) at /usr/include/c++/8/bits/invoke.h:60 #2 0x0000000000402b02 in std::__invoke\u0026lt;void (*)()\u0026gt; (__fn=@0x2260eb8: 0x4029a6 \u0026lt;infiniteLoop()\u0026gt;) at /usr/include/c++/8/bits/invoke.h:95 #3 0x0000000000403150 in std::thread::_Invoker\u0026lt;std::tuple\u0026lt;void (*)()\u0026gt; \u0026gt;::_M_invoke\u0026lt;0ul\u0026gt; (this=0x2260eb8) at /usr/include/c++/8/thread:244 #4 0x0000000000403126 in std::thread::_Invoker\u0026lt;std::tuple\u0026lt;void (*)()\u0026gt; \u0026gt;::operator() (this=0x2260eb8) at /usr/include/c++/8/thread:253 #5 0x000000000040310a in std::thread::_State_impl\u0026lt;std::thread::_Invoker\u0026lt;std::tuple\u0026lt;void (*)()\u0026gt; \u0026gt; \u0026gt;::_M_run (this=0x2260eb0) at /usr/include/c++/8/thread:196 #6 0x00007eff36bceb23 in execute_native_thread_routine () from /lib64/libstdc++.so.6 #7 0x00007eff36ea91ca in start_thread () from /lib64/libpthread.so.0 #8 0x00007eff361d58d3 in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7eff372e1740 (LWP 1315016)): #0 0x00007eff36eaa6cd in __pthread_timedjoin_ex () from /lib64/libpthread.so.0 #1 0x00007eff36bceda7 in std::thread::join() () from /lib64/libstdc++.so.6 #2 0x00000000004029d2 in main () at /root/pstack/main.cpp:13 プロセスが偽の停止状態になっているのは、無限ループに入っているためで、メイン\n","date":"2024-02-24","language":"ja","permalink":"https://ttf248.life/ja/p/pstack-troubleshooting-process-hangs/","tags":["トラブルシューティング"],"title":"pstack でプロセスがフリーズしている原因を調査する","year":"2024"},{"categories":["メモ書き雑感"],"content":"もしあの頃、ご家庭の計画に従って、誠実に電力網を学んでいたら、プログラミングに出会わずに、ただの真面目な青年になっていただろうに。\n記憶の中の埃を払い落とし、きっかけは近年の旧正月とルームメイトとの会話で、それまでの経歴を整理してみたのだ。\n第一章 高考の成績を褒めすぎず、悪すぎず、結局211大学を卒業した。当初、父の計画では、電気系統を専攻して帰郷先の市街地の電力局で働くはずだった。前文にも触れられているように、どのようにIT業界に進むのかについては、少し詳細が漏れていた：金銭感覚と自己制御力のことだ。\n初一は村や町内の学校に通い、初二には自宅での転校が決まり、まるで劉姥姥が大観園にやってきたかのように、市街地の繁華さに馴染めずにいた。映画館に行ったことはほとんどなく、ましてや両親と一緒に映画館に行ったこともほとんどなかったが、親戚が私を連れて行ったことがある。天命は時に幸運をもたらし、その頃には相思相愛の仲間たちと出会った。後で連絡が途絶えてしまったが、あの少年時代は今振り返っても素晴らしいものだった。週末の補習授業の後では、教室に残ったプラスチックボトルを片付け、熟練して一気に踏み潰してバッグに詰め込み、家に持ち帰って母に預けた。貯めたお金をまとめ、処理業者に売却した。一緒に将棋やバドミントンをしたり、斗地主（闘牌）で遊んだりもしたが、負けたときはプランクを数回行い、あの頃は少し感謝していた。父は幼い頃から私に様々な運動をさせていた。\nここから、金銭感覚が少し歪んでしまい、自己卑意識も芽生え始めたが、これらの不幸な出来事はすぐに過ぎ去っていった。家計には恵まれておらず、周りの友達と一緒にお金を使ったり、週末の遊びに参加したりすることができなかった。両親の努力は目に見えており、村から市街地に引っ越してきたのだ。\nその時、種が埋められ、発芽を待っている。\n頭脳が簡単な私は、学業期間を通して非常に幸せだった。多くの卒業生が経験するように、大学での勉強は決して困難ではなく、投入と成果の変換は容易だった。\n第1章 幼少期の帝国时代を記憶に刻み込み、大学期間にはノートパソコンに触れることで、まるでパンデモスの箱を開けたかのようにゲームとゲーム商人という役割に接触した。当初は底辺の営業担当者として、上流からの仕入れを行い、自身のコミュニティのチャネルを通じて商品を販売し、わずかな利益を得ていた。その後、全体の链路の運轉ロジックを徐々に理解していった。私たちが販売する商品は、上流のプログラムによる大量繁殖によって作られ、そのコストはほぼゼロに近かった。この時点で道は少し傾き始めており、専門分野にはさらに細分化されたものがあり、左側には電力網、右側には自動化（非常に複雑で、チッププログラミングや工場電気自動化）が存在した。プログラムが利益を生み出すことの可能性を理解したのは、まだ小銭程度だった。チャネルの上流は確かに多くの利益を得ており、以前からプログラミングの基礎があったため、様々なことに手を出して少しお金を稼ぎ、専門分野を選ぶ際に自然と自動化を選択することになった。大学で履修した専門科目は多くが未受講となり、常にコードを書くことで金を稼ぐことを考えていた。\n前年の論文に触れられたように、ハッカーに対する憧憬を持って接触したプログラミングは、正規の教育機関ではないIT技術者が、慈悲に基づいてアセンブリ言語、侵入テスト、ゲーム外掛、DLL劫持、および個人情報窃取を学び、様々な違法・灰色な製品やサービスに精通し理解していた。両親が人としての道徳を教え、法律によって私の道を完全に逸脱するのを防ぎ、道は完全に傾くことはなかった。\n第1章 前文リンク：那时少年\n大学の頃にも一度恋愛の話がありましたが、振り返ってみると、もっともなのはテレビドラマの中のロマンスへの憧れでした。未熟な心持ちで、あの頃はどのように人を愛するかさえ理解できず、ましてや「家を持ち、仕事をする」といったことには到底辿り着けませんでした。\n第2章 時代の流れの中で、私は幸いにも、大学での数々の騒動を経て、研究院院生になる道を選べなかった。卒業後、就職し、ITブームを追い風に順調な日々を送った。既に8年が過ぎ、業界の熱狂的な投資家（ホットマネー）は消え失せ、徐々に衰退の一途を辿っている。時折、あの選択をしたのは正しかったのかと疑ってしまうこともあった。祖父の言うように電力会社に入ればよかったかもしれない。もしも最初の5年間はそう思えるのであれば、その後は自然に消えていくのだろう。恒生銀行への校内入社から5年間も会社を変えずにいたことは、技術に対する理解、業界に対する認識、そして自身の能力に対する認識において、それぞれ欠落があると言わざるを得ない。杭州本部の指示に従い、深圳支店へ赴任し、職場の争奪戦（事後でようやく経緯を整理したところ、双方とも敗北し、最終的に勝利したのは取締役会だった）を経験した後、技術への情熱を胸に、杭州へと戻った。少し若く、自信過剰な面がありながら、杭州から撤退し、上海へと飛び込んだ。\n元々、杭州に戻り、定住し、家を購入する計画を立てていたが、金利は最高点に達し、住宅価格もピークを迎えており、最初から陥落（套路）される可能性があった。経済状況も悪く、十分な資金もなく、住宅ローンを抱えながら結婚するというプレッシャーと、業界の低迷という状況が、精神的に不安定になる原因となっていた。\n第3章 長年をかけて、多くのことを見てきたこともあり、自分自身も愚かさや浪費をしてきた。現状は順風満帆だ。様々な経験をし、様々な人々に出会うことで、人は少しずつ成長していく。もし家に閉じこもり続ければ、性格的な欠点がいかにして現れるかは誰にもわからないだろう。\n","date":"2024-02-08","language":"ja","permalink":"https://ttf248.life/ja/p/come-out-for-a-walk-is-good/","tags":["人生 (じんせい / jinsei)"],"title":"おしゃべりする時間を作るのは良いことです。 (Oshaberi suru jikan o tsukuru no wa ii koto desu.)\n\nAlternatively, a more casual translation could be:\n\n話せば話すほど良いことばかりだよ。(Hasedeba haseba doko ka yoi koto bakari da yo.)","year":"2024"},{"categories":["コンピューター"],"content":"設計行情 SDK、針對不同的回呼函數實現方式，進行了一次耗時的測試。近期在看 C++ 函數編程，當函數變成了一等公民，在程式內部流轉，耗時有什么不同？\n前文連結：编译器、回调函数、性能测试 leimao 大佬刚好也做了类似的測試，借代码一用。\n本文 実行プラットフォームは引き続き、当社の旧友である https://wandbox.org/ です。\n#include \u0026lt;cassert\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;functional\u0026gt; #include \u0026lt;iostream\u0026gt; #include \u0026lt;vector\u0026gt; int add_one(int input) { return input + 1; } bool validate_vector_add_one(std::vector\u0026lt;int\u0026gt; const\u0026amp; input_vector, std::vector\u0026lt;int\u0026gt; const\u0026amp; output_vector) { bool is_valid{true}; for (size_t i{0}; i \u0026lt; input_vector.size(); ++i) { if (output_vector.at(i) != input_vector.at(i) + 1) { is_valid = false; break; } } return is_valid; } void reset_vector(std::vector\u0026lt;int\u0026gt;\u0026amp; input_vector) { for (size_t i{0}; i \u0026lt; input_vector.size(); ++i) { input_vector.at(i) = 0; } } template \u0026lt;typename T, typename Func\u0026gt; void unitary_function_pass_by_lambda_function(T\u0026amp; output, T const\u0026amp; input, Func const func) { output = func(input); } template \u0026lt;typename T\u0026gt; void unitary_function_pass_by_std_function_value(T\u0026amp; output, T const\u0026amp; input, std::function\u0026lt;T(T)\u0026gt; const func) { output = func(input); } template \u0026lt;typename T\u0026gt; void unitary_function_pass_by_std_function_reference( T\u0026amp; output, T const\u0026amp; input, std::function\u0026lt;T(T)\u0026gt; const\u0026amp; func) { output = func(input); } template \u0026lt;typename T\u0026gt; void unitary_function_pass_by_function_pointer(T\u0026amp; output, T const\u0026amp; input, T (*func)(T)) { output = func(input); } int main() { // Set floating point format std::cout with 3 decimal places. std::cout.precision(3); size_t const num_elements{10000000}; std::vector\u0026lt;int\u0026gt; input_vector(num_elements, 0); std::vector\u0026lt;int\u0026gt; output_vector(num_elements, 0); auto const lambda_function_add_one{[](int const\u0026amp; input) -\u0026gt; int { return input + 1; }}; std::function\u0026lt;int(int)\u0026gt; const std_function_add_one{lambda_function_add_one}; std::cout \u0026lt;\u0026lt; \u0026#34;The size of a function pointer: \u0026#34; \u0026lt;\u0026lt; sizeof(\u0026amp;add_one) \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;The size of a std::function pointer: \u0026#34; \u0026lt;\u0026lt; sizeof(\u0026amp;std_function_add_one) \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;The size of a std::function: \u0026#34; \u0026lt;\u0026lt; sizeof(std_function_add_one) \u0026lt;\u0026lt; std::endl; // Call function frequently in a vanilla way. // The compiler knows what function to call at compile time and can optimize // the code. // This is the best performance we could get. std::chrono::steady_clock::time_point const time_start_vanilla{ std::chrono::steady_clock::now()}; for (size_t i{0}; i \u0026lt; num_elements; ++i) { output_vector.at(i) = add_one(input_vector.at(i)); } std::chrono::steady_clock::time_point const time_end_vanilla{ std::chrono::steady_clock::now()}; auto const time_elapsed_vanilla{ std::chrono::duration_cast\u0026lt;std::chrono::nanoseconds\u0026gt;(time_end_vanilla - time_start_vanilla) .count()}; float const latency_vanilla{time_elapsed_vanilla / static_cast\u0026lt;float\u0026gt;(num_elements)}; std::cout \u0026lt;\u0026lt; \u0026#34;Latency Pass Vanilla: \u0026#34; \u0026lt;\u0026lt; latency_vanilla \u0026lt;\u0026lt; \u0026#34; ns\u0026#34; \u0026lt;\u0026lt; std::endl; assert(validate_vector_add_one(input_vector, output_vector)); reset_vector(output_vector ## 正文 // 時々、コンパイル時に呼び出す関数を知らない場合があります。 // `std::function` を使用して、関数を引数として渡すことができます。 // この場合は、`std::function` を値で渡します。 // `std::function` のサイズが 32 バイトであるため、値を渡すと多くのコピーが発生し、パフォーマンスが悪くなります。 std::chrono::steady_clock::time_point const time_start_pass_by_std_function_value{std::chrono::steady_clock::now()}; for (size_t i{0}; i \u0026lt; num_elements; ++i) { unitary_function_pass_by_std_function_value( output_vector.at(i), input_vector.at(i), std_function_add_one); } std::chrono::steady_clock::time_point const time_end_pass_by_std_function_value{std::chrono::steady_clock::now()}; auto const time_elapsed_pass_by_std_function_value{ std::chrono::duration_cast\u0026lt;std::chrono::nanoseconds\u0026gt;( time_end_pass_by_std_function_value - time_start_pass_by_std_function_value) .count()}; float const latency_pass_by_std_function_value{ time_elapsed_pass_by_std_function_value / static_cast\u0026lt;float\u0026gt;(num_elements)}; std::cout \u0026lt;\u0026lt; \u0026#34;Latency Pass By Std Function Value: \u0026#34; \u0026lt;\u0026lt; latency_pass_by_std_function_value \u0026lt;\u0026lt; \u0026#34; ns\u0026#34; \u0026lt;\u0026lt; std::endl; assert(validate_vector_add_one(input_vector, output_vector)); reset_vector(output_vector); // `std::function` を値で渡す代わりに、参照（ポインタ）で渡すこともできます。 // この場合、オブジェクトのコピーは排除されます。パフォーマンスは、`std::function` を値で渡した場合よりも優れています。 // ただし、ワイルドな方法ほどではありません。 std::chrono::steady_clock::time_point const time_start_pass_by_std_function_reference{ std::chrono::steady_clock::now()}; for (size_t i{0}; i \u0026lt; num_elements; ++i) { unitary_function_pass_by_std_function_reference( output_vector.at(i), input_vector.at(i), std_function_add_one); } std::chrono::steady_clock::time_point const time_end_pass_by_std_function_reference{ std::chrono::steady_clock::now()}; auto const time_elapsed_pass_by_std_function_reference{ std::chrono::duration_cast\u0026lt;std::chrono::nanoseconds\u0026gt;( time_end_pass_by_std_function_reference - time_start_pass_by_std_function_reference) .count()}; float const latency_pass_by_std_function_reference{ time_elapsed_pass_by_std_function_reference / static_cast\u0026lt;float\u0026gt;(num_elements)}; std::cout \u0026lt;\u0026lt; \u0026#34;Latency Pass By Std Function Reference: \u0026#34; \u0026lt;\u0026lt; latency_pass_by_std_function_reference \u0026lt;\u0026lt; \u0026#34; ns\u0026#34; \u0026lt;\u0026lt; std::endl; assert(validate_vector_add_one(input_vector, output_vector)); reset_vector(output_vector); ## 本文 // `std::function` は、関数ポインタ、呼び出し可能オブジェクト、ラムダ関数をラップする汎用的なものです。 // 汎用性があるため、関数ポインタほど効率的ではありません。この場合は、関数ポインタを関数に渡します。 // `std::function` を参照で渡すよりもパフォーマンスが優れています。 std::chrono::steady_clock::time_point const time_start_pass_by_function_pointer{std::chrono::steady_clock::now()}; for (size_t i{0}; i \u0026lt; num_elements; ++i) { unitary_function_pass_by_function_pointer(output_vector.at(i), input_vector.at(i), \u0026amp;add_one); } std::chrono::steady_clock::time_point const time_end_pass_by_function_pointer{std::chrono::steady_clock::now()}; auto const time_elapsed_pass_by_function_pointer{ std::chrono::duration_cast\u0026lt;std::chrono::nanoseconds\u0026gt;( time_end_pass_by_function_pointer - time_start_pass_by_function_pointer) .count()}; float const latency_pass_by_function_pointer{ time_elapsed_pass_by_function_pointer / static_cast\u0026lt;float\u0026gt;(num_elements)}; std::cout \u0026lt;\u0026lt; \u0026#34;Latency Pass By Function Pointer: \u0026#34; \u0026lt;\u0026lt; latency_pass_by_function_pointer \u0026lt;\u0026lt; \u0026#34; ns\u0026#34; \u0026lt;\u0026lt; std::endl; assert(validate_vector_add_one(input_vector, output_vector)); reset_vector(output_vector); // ラムダ関数を関数に渡すこともできます。 // コンパイラは、コンパイル時に呼び出す関数を知っており、コードを最適化できます。 // `std::function` を参照で渡すよりもパフォーマンスも優れています。 std::chrono::steady_clock::time_point const time_start_pass_by_lambda_function{std::chrono::steady_clock::now()}; for (size_t i{0}; i \u0026lt; num_elements; ++i) { unitary_function_pass_by_lambda_function( output_vector.at(i), input_vector.at(i), lambda_function_add_one); } std::chrono::steady_clock::time_point const time_end_pass_by_lambda_function{std::chrono::steady_clock::now()}; auto const time_elapsed_pass_by_lambda_function{ std::chrono::duration_cast\u0026lt;std::chrono::nanoseconds\u0026gt;( time_end_pass_by_lambda_function - time_start_pass_by_lambda_function) .count()}; float const latency_pass_by_lambda_function{ time_elapsed_pass_by_lambda_function / static_cast\u0026lt;float\u0026gt;(num_elements)}; std::cout \u0026lt;\u0026lt; \u0026#34;Latency Pass By Lambda Function: \u0026#34; \u0026lt;\u0026lt; latency_pass_by_lambda_function \u0026lt;\u0026lt; \u0026#34; ns\u0026#34; \u0026lt;\u0026lt; std::endl; assert(validate_vector_add_one(input_vector, output_vector)); reset_vector(output_vector); ## 本文 ```shell # チーム全体の最適化 (O2) を有効にし、コンパイルには gcc13 を選択しました。gcc のバージョンが異なる場合、性能と時間の違いはわずかに異なりますが、バージョンが高いほど lambda の効果が良いです。 関数のポインタのサイズ: 8 バイト std::function ポインタのサイズ: 8 バイト std::function オブジェクトのサイズ: 32 バイト Vanilla パスのレイテンシ: 0.418 ns std::function 値でパスするレイテンシ: 3.47 ns std::function リファレンスでパスするレイテンシ: 1.36 ns ポインタで関数をパスするレイテンシ: 0.396 ns ラムダ関数でパスするレイテンシ: 0.44 ns 参考文献 https://leimao.github.io/blog/CPP-Function-Call-Performance/\n","date":"2024-01-24","language":"ja","permalink":"https://ttf248.life/ja/p/cpp-function-call-timing/","tags":["c++"],"title":"C++関数呼び出しのオーバーヘッド時間 / 関数呼び出し時のパフォーマンスに関する問題","year":"2024"},{"categories":["転載 (tenzai)"],"content":"バイアスの解説 ホスト序、ネットワーク序、デバッガで直接観察 コンピュータ分野の歴史的経緯から生まれた特定の設計習慣は、お尻の幅がロケットエンジンの幅を決定するように、内部の「利点」や「欠点」を分析する必要はありません。単なる歴史的な習慣です。\n元文章リンク 著: 北極 リンク: https://www.zhihu.com/question/637413724/answer/3346032134 出典: 知乎 著作権は著作者に帰属します。商業的な転載をご希望の場合は、著者に連絡して許可を得てください。非営利の転載の場合は、出所を明記してください。\n正文转载 現代の様々なデバイスの状態は、歴史的な慣習と商業化の結果であり、技術そのものとは関係がありません。ARMはビッグエンディアン（大端）でも、リトルエンディアン（小端）でも設定できます。TCP/IPヘッダも現在もビッグエンディアン（ネットワークバイト順序）です。ストレージ分野にも、大端方式でデータを保存する多くのストレージプロトコルや仕様があります。\nしたがって、質問者の3つの問題は、今日から見ると次のようになります。\nコンピュータが一般的に小端形式で保存するのはなぜ？ → 間違い。 低バイトを低アドレスに配置した小端形式の方が、大端形式よりも効率的である理由は何ですか？ → 効率は高くなりません。 現在の技術を用いてこれらの問題を論証するものは、すべて矢を射てから的を描くような行為です。\nしかし、大端または小端の選択が、コンピュータの開発史において、確かに一定の客観的な要因があったことは事実です。ホストバイト順序（小端）の利点は、小端形式の加算器は比較的簡単に作れることです。8ビット×4の加算器を作成するには、単一の8ビット加算器で、低アドレスから高アドレスまで順番に各バイトを加算するだけで済みます。桁上がり回路は非常にシンプルであり、大端形式では32ビットを一度ロードする必要があるため、計算できません。現在では、8ビットと32ビットのロードの違いはほとんどありませんが、数十年前にはメモリ価格が高価であったため、より単純な方が有利でした。そのため、ホストバイト順序を選択したのはコストを考慮した結果です。ネットワークバイト順序（大端）の利点は、初期のデバイスのキャッシュが非常に小さかったことです。最初に高バイトを受信することで、パケットの長さ（どの程度のキャッシュが必要か）やアドレス範囲（IPアドレスは前から後ろにマッチングする）を迅速に判断できます。当時のネットワークデバイスのキャッシュはバイト単位であり、先頭のバイトを取得することがより速い場合がありました。そのため、ネットワークデバイスが大端を使用したのはコストを考慮した結果です。\nしたがって、バイト順序の選択は、歴史的に見て、多くの場合、アプリケーションシナリオとコストを重視したもの（例えば、PPC/MIPSはネットワークデバイスに適している）であり、その後の技術発展において、互換性のために大端小端の設定が引き継がれているものです。\n今日から見れば、これらの利点はすべて存在せず、単なる歴史的な慣習に過ぎません。\n","date":"2024-01-24","language":"ja","permalink":"https://ttf248.life/ja/p/little-endian-storage-why/","tags":["バイアンス順序","エンドランディングストレージ (Endlanding storage)","ロングレンジストレージ (Long Range Storage)","ホストバイトオーダー","ネットワークバイト順 (Network byte order)"],"title":"コンピュータがなぜ一般的にlittle-endianなストレージを採用するのか？","year":"2024"},{"categories":["コンピューター"],"content":"心血を注ぎ、新しい壁紙を探し求めた。習慣は黒系の壁紙だが、一部の領域には色を加えても良いだろう。デスクトップにはアイコンを配置する必要があるため、他の色系が壁紙だとアイコンが不明瞭になってしまう。\n上記のコードを睨めつけ、理解できずにいた。AIに投げかけて説明したが、状況を説明していなかったのだ。それは特定の状況下で使われる指示であり、通常のコードではこのような形ではない。\nAIは今や検索エンジンには及ばない。アセンブリの知識が不足している。\n壁紙 彙集コード PUSHFD MOV DWORD PTR [ESP],0X100 POPFD 実用例\nbool IsDebugged() { __try { __asm { pushfd mov dword ptr [esp], 0x100 popfd nop } return true; } __except(GetExceptionCode() == EXCEPTION_SINGLE_STEP ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_EXECUTION) { return false; } } 彙編コード PUSHFD および POPFD は、フラグレジスタの値をスタックにプッシュおよびポップする命令です。\nMOV DWORD PTR [ESP], 0X100 は、スタックポインタ (ESP) のアドレスにある4バイト（DWORD）領域に 0x100 の値を移動する命令です。\nnop は、何もしない命令です。デバッグやテストのために使用されることがあります。\n実用例 このコードは、デバッグモードでプログラムが実行されているかどうかを判断します。\n__try ブロック内でアセンブリコードを実行し、例外が発生した場合に __except ブロックが実行されます。\nGetExceptionCode() == EXCEPTION_SINGLE_STEP は、プログラムがシングルステップモードで実行されているかどうかを確認します。\nEXCEPTION_EXECUTE_HANDLER および EXCEPTION_CONTINUE_EXECUTION は、それぞれハンドラを実行するか、実行の継続を許可する例外コードです。\nこの例では、プログラムがシングルステップモードで実行されている場合、true が返されます。それ以外の場合は、false が返されます。\n説明 TrapFlagはレジスタフラグ領域内のフラグであり、このフラグが設定されると、SINGLE_STEP例外が発生します。なぜなら、デバッガーでコードをトレースしている場合、このフラグはデバッガーによってリセットされ、その例外を捕捉できないからです。\n実際のテストでは、直接ステップオーバーしてデバッグ対象の関数を実行すると、デバッグが検出されないことがわかります。例外は、その関数にエントリする実行時のみ検出されます（資料参照、未検証）。\n参考文献 中国語の関連資料は、すべてウェブサイトの英文稿を翻訳したものです。このサイトでは、さまざまな反调试技術について解説しています。\nhttps://anti-debug.checkpoint.com/ https://song-10.gitee.io/2021/08/08/Reverse-2021-08-08-anti-debug/ ","date":"2024-01-23","language":"ja","permalink":"https://ttf248.life/ja/p/program-anti-debug/","tags":["anti-debug"],"title":"プログラムのデバッグを防止する方法","year":"2024"},{"categories":["コンピューター"],"content":"最近、有人相談してきて、焦点访谈の動画をダウンロードする方法を聞かれたんだけど、頭の中で考えていたのは、おそらくまた m3u8 形式で暗号化されているだろうという考えだったんだ。ちょっと手軽に処理してみようか。\nダウンローダー https://github.com/nilaoda/N_m3u8DL-CLI m3u8 downloader のオープンソース 命令行 m3u8/HLS/dash ダウンローダーです。普通 AES-128-CBC 解密、マルチスレッド、カスタムリクエストヘッダなどをサポートしています。简体中文、繁体中文、英語に対応しています。English Supported.\nブラウザ拡張機能 Live Stream Downloader\n蜜汁自信 アドレスを取得し、これで片付くと思ったが、結果は何もかも役に立たない。正常にセグメント内容を解析したり、資料を検索したりすることができなかった。公式がダウンロードアドレスを処理しており、ある程度の置換を手動で行う必要があることを発見した。プラグインで解析された key を以下のリンクに手動でコピー＆置き換えなければならない。\nhttps://newcntv.qcloudcdn.com/asp/hls/2000/0303000a/3/default/***********************/2000.m3u8 2024年1月現在、アドレスは有効。今後変更がある場合は、ウェブページを分析してご自身で判断してください。 過去のアドレスのバックアップ：https://hlswx.cntv.kcdnvip.com/asp/hls/main/0303000a/3/default/一串字符/main.m3u8?maxbr=2000\n参考文献 http://jln.cn/post/517.html\n","date":"2024-01-23","language":"ja","permalink":"https://ttf248.life/ja/p/how-to-download-focus-interview-cctv-videos/","tags":["焦點インタビュー (Tokyū intovīrī)","CCTV"],"title":"焦点访談/CCTV動画ファイルのダウンロード方法","year":"2024"},{"categories":["コンピューター"],"content":"会社セキュリティポリシーの調整により、機械師 miniは最終的に自宅へ移転し、予備サーバーとして利用。同時にマシンシステムを再インストールし、ubuntuがwindows serverに切り替えられました。アクティベーション手段が不正であったため、自宅で使用しても問題ないように見えていましたが、実際にはアクティベーションができていないと様子がおかしくなりました。\nMicrosoftによる検出がトリガーされ、通常稼働していたサーバーが起動から1時間で自動シャットダウン。システムログを徹底的に調査した結果、盗版であることに至りました。\n仕方なく再度システムを再インストールし、SqlServerも再インストールする必要が生じました。毎回トラブルシューティングを行うと非常に面倒であり、ファイル権限管理が厳格であるため、データベースの追加が正常に行えませんでした。\nエラーメッセージ システムを再インストールした後、SqlServerがデータベースに接続しようとすると、オペレーティングシステムのアクセス拒否エラー5120が発生することがあります。\n処理スクリプト 前文リンク：ローカルGitリポジトリの一括更新、やはりこの馴染み深いスクリプトだ。改造して、フォルダをトラバースしながらファイルの権限を変更し、現在のユーザーに完全な編集権限を与えるようにする。\nネット上のチュートリアルはほとんどが手動で修正する方法を示しており、毎回数個のファイルだけ修正するのだろうか？ 私は毎回多数のファイルを処理する必要があり、すべてを手作業で処理すると、精神的に疲れてしまう。\n$currentUserName = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 $rootDirectory = \u0026#34;D:\\data\\2013_RujiaInfo\u0026#34; Get-ChildItem -Path $rootDirectory -Recurse | ForEach-Object { $itemPath = $_.FullName if ($_ -is [System.IO.DirectoryInfo]) { $icaclsResult = icacls $itemPath /setowner \u0026#34;$currentUserName\u0026#34; 2\u0026gt;\u0026amp;1 if ($LASTEXITCODE -eq 0) { Write-Host \u0026#34;フォルダ $itemPath の所有者を $currentUserName に変更しました\u0026#34; # 現在のユーザーに書き込み権限を付与 Invoke-Expression \u0026#34;icacls `\u0026#34;$itemPath`\u0026#34; /grant `\u0026#34;$($currentUserName):(OI)(CI)F`\u0026#34;\u0026#34; Write-Host \u0026#34;$currentUserName がフォルダを編集するための権限が付与されました\u0026#34; } else { Write-Host \u0026#34;フォルダ $itemPath の所有者を変更できません。エラー情報: $icaclsResult\u0026#34; } } else { $takeownResult = icacls $itemPath /setowner \u0026#34;$currentUserName\u0026#34; 2\u0026gt;\u0026amp;1 if ($LASTEXITCODE -eq 0) { # 現在のユーザーに書き込み権限を付与 Invoke-Expression \u0026#34;icacls `\u0026#34;$itemPath`\u0026#34; /grant `\u0026#34;$($currentUserName):(F)`\u0026#34;\u0026#34; Write-Host \u0026#34;$currentUserName がファイルを編集するための権限が付与されました\u0026#34; } else { Write-Host \u0026#34;ファイル $itemPath の所有者を変更できません。エラー情報: $takeownResult\u0026#34; } } } ","date":"2024-01-23","language":"ja","permalink":"https://ttf248.life/ja/p/bulk-modify-sqlserver-database-disk-permissions/","tags":["SqlServer"],"title":"SQL Serverデータベースのディスクファイルの権限を一括で変更する","year":"2024"},{"categories":["コンピューター"],"content":"Windows 平台上有鲁大师（娱乐大师），不能说数据很准，但总归有个参考，当然也有其他的专业跑分软件。到了 Linux 系统，好像一直没遇到特别合适的跑分软件。\nSysbench 是一款多功能的基准测试工具，可用于测试 CPU、内存、文件 I/O、线程性能等。您可以使用 Sysbench 来执行各种性能测试任务。\n手头上刚好有三台机器用于测试：机械师 mini 本地小主机、阿里云 dev 开发云服务器、华为云开发服务器。\nSysbench のインストール ほとんどの Linux ディストリビューションでは、パッケージマネージャを使用して Sysbench をインストールできます。例えば、CentOS 8 では、次のコマンドを使用します。\nsudo dnf install sysbench Sysbenchの使用例 CPU性能のテスト: sysbench --test=cpu run メモリ読み取り性能のテスト: sysbench --test=memory run ファイルI/O性能のテスト: sysbench --test=fileio --file-test-mode=rndrw prepare sysbench --test=fileio --file-test-mode=rndrw run sysbench --test=fileio --file-test-mode=rndrw cleanup マルチスレッド性能のテスト: sysbench --test=threads --num-threads=4 run MySQLデータベース性能のテスト（最大接続数を調整する必要あり）： sysbench --test=oltp --db-driver=mysql --mysql-db=test --mysql-user=yourusername --mysql-password=yourpassword --oltp-table-size=1000000 prepare sysbench --test=oltp --db-driver=mysql --mysql-db=test --mysql-user=yourusername --mysql-password=yourpassword --max-time=60 --oltp-read-only=off --oltp-test-mode=complex --max-requests=0 run sysbench --test=oltp --db-driver=mysql --mysql-db=test --mysql-user=yourusername --mysql-password=yourpassword cleanup ランニングデータレポート 実行データレポート ABCD1ローカル機械師阿里云华为云2システム構成システム情報\nオペレーティングシステム Ubuntu 23.04\nカーネル Linux 6.2.0-36-generic x86_64\nモデル Machenike Machenike DT Computer\nマザーボード Machenike Machenike DT Computer\nBIOS American Megatrends International, LLC.\nDB19V012\nCPU情報\n名前 Intel Core i7-12650H\nトポロジー 1 プロセッサ、10 コア、16 スレッド\n識別子 GenuineIntel Family 6 Model 154 Stepping 3\nベース周波数 4.60 GHz\nL1 命令キャッシュ 32.0 KB x 8\nL1 データキャッシュ 48.0 KB x 8\nL2 キャッシュ 1.25 MB x 2\nL3 キャッシュ 24.0 MB\nメモリ情報\nサイズ 62.6 GBシステム情報\nオペレーティングシステム CentOS Stream 8\nカーネル Linux 4.18.0-513.el8.x86_64 x86_64\nモデル Alibaba Cloud Alibaba Cloud ECS\nマザーボード N/A\nBIOS SeaBIOS 449e491\nCPU情報\n名前 Intel(R) Xeon(R) Platinum\nトポロジー 1 プロセッサ、1 コア、2 スレッド\n識別子 GenuineIntel Family 6 Model 85 Stepping 4\nベース周波数 2.50 GHz\nL1 命令キャッシュ 32.0 KB\nL1 データキャッシュ 32.0 KB\nL2 キャッシュ 1.00 MB\nL3 キャッシュ 33.0 MB\nメモリ情報\nサイズ 1.65 GBシステム情報\nオペレーティングシステム Ubuntu 22.04.1 LTS\nカーネル Linux 5. - 64 GB 実行データレポート system LuaJIT 2.1.0-beta3)\nテストの実行方法：指定されたオプションで\nスレッド数: 1\n乱数ジェネレーターを現在の時間から初期化\n素数の制限: 10000\nワーカーのスレッドの初期化\u0026hellip;\nスレッドが開始されました!\nCPU速度:\n毎秒イベント数: 4032.48\n一般的な統計情報:\n合計時間: 10.0004秒\nイベントの総数: 40330\n遅延 (ms):\n最小値: 0.25\n平均値: 0.25\n最大値: 0.73\n95パーセンタイル: 0.25\n合計: 9997.55\nスレッドの公平性:\nイベント (平均/標準偏差): 40330.0000/0.00\n実行時間 (平均/標準偏差): 9.9975/0.00\nデータマイニング\nディープラーニング\nニューラルネットワーク - 実行データレポート system LuaJIT 2.1.0-beta3)\nテストの実行方法：指定されたオプションで\nスレッド数: 1\n乱数ジェネレーターを現在の時間から初期化\n素数の制限: 10000\nワーカーのスレッドの初期化\u0026hellip;\nスレッドが開始されました!\nCPU速度:\n毎秒イベント数: 4032.48\n一般的な統計情報:\n合計時間: 10.0004秒\n合計イベント数: 40330\n遅延 (ms):\n最小: 0.25\n平均: 0.25\n最大: 0.73\n95パーセンタイル: 0.25\n合計: 9997.55\nスレッドの公平性:\nイベント (平均/標準偏差): 40330.0000/0.00\n実行時間 (平均/標準偏差): 9.9975/0.00\nsysbench 1.0.20 (system LuaJIT 2.1.0-beta3を使用)\nテストの実行方法：指定されたオプションで\nスレッド数: 1\n乱数ジェネレーターを現在の時間から初期化\n素数の制限: 10000\nワーカーのスレッドの初期化\u0026hellip;\nスレッドが開始されました!\nCPU速度:\n毎秒イベント数: 1062.51\n一般的な統計情報:\n合計時間: 10.0008秒\n合計イベント数: 10628\n遅延 (ms):\n最小: 0.91\n平均: 0.94\n最大: 22.84\n95パーセンタイル: 1.06\n合計: 9993.46\nスレッドの公平性:\nイベント (平均/標準偏差): 10628.0000/0.00\n実行時間 (平均/標準偏差): 9.9935/0.00\nsysbench 1.0.20 (system LuaJIT 2.1.0-beta3を使用)\nテストの実行方法：指定されたオプションで\nスレッド数: 1\n乱数ジェネレーターを現在の時間から初期化\n素数の制限: 10000\nワーカーのスレッドの初期化\u0026hellip;\nスレッドが開始されました!\nCPU速度:\n毎秒イベント数: 1125.56\n一般的な統計情報:\n合計時間: 10.0005秒\n合計イベント数: 11258\n遅延 (ms):\n最小: 0.86\n平均: 0.89\n最大: 1.70\n95パーセンタイル: 0.99\n合計: 9995.40\nスレッドの公平性:\nイベント (平均/標準偏差): 11258.0000/0.00\n実行時間 (平均/標準偏差): 9.9954/0.00\nメモリテストを実行するオプション：指定されたオプションで\nブロックサイズ: 1KiB\n合計サイズ: 102400MiB\n操作: 書き込み\n範囲: グローバル\nワーカーのスレッドの初期化\u0026hellip;\nスレッドが開始されました!\n総イベント数: 101993199 (10198146.52/秒)\n\u0026lt;\nランダム数生成レポート 現在の時刻からの乱数ジェネレーター\n次のオプションでメモリ速度テストを実行中:\nブロックサイズ：1KiB\n合計サイズ：102400MiB\n操作：書き込み\n範囲：グローバル\nワーカースレッドの初期化\u0026hellip;\nスレッド開始!\n総操作数：48418803 (1秒あたり4841004.79)\n転送されたデータ：47283.99 MiB (1秒あたり4727.54 MiB)\n一般的な統計:\n合計時間： 10.0001s\nイベント総数： 48418803\nレイテンシ（ms）：\n最小： 0.00\n平均： 0.00\n最大： 25.26\n95パーセンタイル： 0.00\n合計： 4578.95\nスレッドの公平性:\nイベント（平均/標準偏差）： 48418803.0000/0.00\n実行時間（平均/標準偏差）： 4.5789/0.00\nランニングテストで次のオプションを使用中：\nスレッド数：1\n現在の時刻からの乱数ジェネレーターの初期化\n追加ファイルオープンフラグ：（なし）\n128ファイル、各16MiB\n2GiBの合計ファイルサイズ\nブロックサイズ 16KiB\nIOリクエスト数：0\n組み合わせてランダムIOテストの読み取り/書き込み比率：1.50\n定期的なFSYNCが有効になっており、各100リクエストごとにfsync()を呼び出しています。\nテストの最後にfsync()を呼び出すことが有効になっています。\n同期I/Oモードを使用\nランダムな読み取り/書き込みテストを実行中\nワーカースレッドの初期化\u0026hellip;\nスレッド開始!\nファイル操作：\n読み取り/秒： 3373.41\n書き込み/秒： 2248.94\nfsync/秒： 7201.80\nスループット：\n読み取り、MiB/s： 52.71\n書き込み、MiB/s： 35.14\n一般的な統計：\n合計時間： 10.0127s\nイベント総数： 128288\nレイテンシ（ms）：\n最小： 0.00\n平均： 0.08\n最大： 5.14\n95パーセンタイル： 0.34\n合計： 9977.78\nスレッドの公平性：\nイベント（平均/標準偏差）： 128288.0000/0.00\n実行時間（平均/標準偏差）： 9.9778/0.00\nスループット：\n読み取り、MiB/s： 52.71\n書き込み、MiB/s： 35.14\n一般的な統計：\n合計時間： 10.0127s\nイベント総数： 128288\nレイテンシ（ms）：\n最小： 0.00\n平均： 0.08\n最大： 5.14\n95パーセンタイル： 0.34\n合計： 9977.78\nスレッドの公平性：\nイベント（平均/標準 ## ランダム数生成データレポート 現在の時刻からの乱数ジェネレーター\n次のオプションでメモリ速度テストを実行中:\nブロックサイズ：1KiB\n合計サイズ：102400MiB\n操作：書き込み\n範囲：グローバル\nワーカースレッドの初期化\u0026hellip;\nスレッド開始!\n総操作数：48418803 (1秒あたり4841004.79)\n転送されたデータ：47283.99 MiB (1秒あたり4727.54 MiB)\n一般的な統計:\n合計時間： 10.0001s\nイベント総数： 48418803\n遅延（ms）：\n最小： 0.00\n平均： 0.00\n最大： 25.26\n95パーセンタイル： 0.00\n合計： 4578.95\nスレッドの公平性:\nイベント（平均/標準偏差）： 48418803.0000/0.00\n実行時間（平均/標準偏差）： 4.5789/0.00\nテストオプションで実行中:\nスレッド数：1\n現在の時刻からの乱数ジェネレーターの初期化\n追加ファイルオープンフラグ：（なし）\n128ファイル、各16MiB\n2GiBの合計ファイルサイズ\nブロックサイズ 16KiB\nIOリクエスト数：0\n組み合わせてランダムIOテストの読み取り/書き込み比率：1.50\n定期的なFSYNCが有効になり、各100リクエストごとにfsync()が呼び出されます。\nテストの終了時にfsync()を呼び出す。有効になっています。\n同期I/Oモードを使用\nランダムな読み取り/書き込みテストを実行中\nワーカースレッドの初期化\u0026hellip;\nスレッド開始!\nファイル操作:\n読み取り/秒： 3373.41\n書き込み/秒： 2248.94\nfsync/秒： 7201.80\nスループット:\n読み取り、MiB/s： 52.71\n書き込み、MiB/s： 35.14\n一般的な統計:\n合計時間： 10.0127s\nイベント総数： 128288\n遅延（ms）：\n最小： 0.00\n平均： 0.08\n最大： 5.14\n95パーセンタイル： 0.34\n合計： 9977.78\nスレッドの公平性:\nイベント（平均/標準偏差）： 128288.0000/0.00\n実行時間（平均/標準偏差）： 9.9778/0.00\nスループット： 読み取り、MiB/s： 52.71 書き込み、MiB/s： 35.14\nディスク: 2147483648 バイトを 1.81 秒で書き込みました (1129.59 MiB/秒)。\nテストオプションで実行中:\nスレッド数：1\n現在の時刻からの乱数ジェネレーターの初期化\n追加ファイルオープンフラグ：（なし）\n128ファイル、各16MiB\n2GiBの合計ファイルサイズ\nブロックサイズ 16KiB\nIOリクエスト数：0\n組み合わせてランダムIOテストの読み取り/書き込み比率：1.\n実行データレポート enabled, 各100リクエストごとにfsync()を呼び出す。\nテストの終了時にfsync()を呼び出し、有効化。\n同期I/Oモードを使用中\nランダムなr/wテストを実行中\nワーカースレッドの初期化\u0026hellip;\nスレッドが開始されました!\nファイル操作:\n読み込み/秒: 1593.12\n書き込み/秒: 1062.08\nfsync/秒: 3406.64\n帯域幅:\n読み取り (MiB/s): 24.89\n書き込み (MiB/s): 16.60\n一般的な統計:\n合計時間: 10.0164秒\nイベント総数: 60600\nレイテンシ (ms):\n最小: 0.00\n平均: 0.16\n最大: 31.32\n95パーセンタイル: 0.54\n合計: 9956.30\nスレッドの公平性:\nイベント (平均/標準偏差): 60600.0000/0.00\n実行時間 (平均/標準偏差): 9.9563/0.00\n2147483648 バイトを 18.29 秒で書き込みました (111.98 MiB/秒)。\n以下のオプションでテストを実行中:\nスレッド数: 1\n現在の時刻から乱数ジェネレーターを初期化\n追加のファイルオープンフラグ:(なし)\n128 ファイル、各 16MiB\n2GiB の合計ファイルサイズ\nブロックサイズ 16KiB\nIO リクエスト数: 0\nランダムな IO テストの読み取り/書き込み比率: 1.50\n定期的な FS INC を有効にし、各 100 リクエストごとに fsync() を呼び出す。\nテストの終了時に fsync() を呼び出し、有効化。\n同期 I/O モードを使用中\nランダムな r/w テストを実行中\nワーカースレッドの初期化\u0026hellip;\nスレッドが開始されました!\nファイル操作:\n読み込み/秒: 1665.88\n書き込み/秒: 1110.59\nfsync/秒: 3563.77\n帯域幅:\n読み取り (MiB/s): 26.03\n書き込み (MiB/s): 17.35\n一般的な統計:\n合計時間: 10.0112秒\nイベント総数: 63355\nレイテンシ (ms):\n最小: 0.00\n平均: 0.16\n最大: 205.01\n95パーセンタイル: 0.78\n合計: 9972.64\nスレッドの公平性:\nイベント (平均/標準偏差): 63355.0000/0.00\n実行時間 (平均/標準偏差): 9.9726/0.00\nスレッド数: 4 初期化されたランダムな数値ジェネレーターから現在の時刻を初期化\u0026hellip;\nワーカースレッドが開始されました!\n一般的な統計:\n合計時間: 10.0002秒\nイベント総数: 197956\nレイテンシ (ms):\n最小: 0.16\n平均: 0.20\n実行結果レポート 合計: 40050.41\nスレッド公平性:\nイベント (平均/標準偏差): 4590.0000/94.36\n実行時間 (平均/標準偏差): 10.0126/0.00\nテスト実行時のオプション: スレッド数: 4 現在の時刻から乱数生成器を初期化 ワーカースレッドの初期化\u0026hellip;\nスレッド起動!\n一般統計: 合計時間: 10.0004秒 合計イベント数: 28536\n遅延 (ms): 最小: 0.23 平均: 1.40 最大: 3.56 95パーセンタイル: 1.47 合計: 39975.16\nスレッド公平性: イベント (平均/標準偏差): 7134.0000/39.87 実行時間 (平均/標準偏差): 9.9938/0.01\n追記 ChatGPTは依然として優れたものですが、以前習得していたMarkdownで完全にテーブルを作成できず、テーブルとして表示すると効果が著しく低下します。カスタムテーマによってページの最大幅が制限されるため、幅を百分率制に調整しました。\n簡単な方法としては、TablesGeneratorのようなオンラインツールを使用してHTMLテーブルを生成する方法がありますが（内容が複雑だと不向きです）。 または、Googleドキュメントで作成し、HTMLドキュメントとしてダウンロードして保存し、ブログに直接コピーする方法を採用しました（シンプルかつ直接的です）。 configの設定でunsafeな設定項目を有効にし、ページごとの幅設定を個別に指定するようにしてください。Hugoでは、ページごとに個別に幅を設定できます。これは、ページのFront Matterにカスタムパラメータを追加することで実現できます。以下はその例です。\nMarkdownファイルのFront Matterセクション（通常はファイルの冒頭部分）にカスタムパラメータ（例えばcustom_width）を追加します： --- title: \u0026#34;私のページ\u0026#34; date: 2024-01-09 custom_width: \u0026#34;800px\u0026#34; # 幅を800ピクセルに設定 --- 本文内容... Hugoのテーマで、対応する単一ページテンプレートファイル（例えばlayouts/_default/single.html）を見つけてください。 単一ページテンプレート内で、Front Matterにcustom_widthパラメータが存在するか確認し、それを適切なHTML要素（例えばdiv）に適用します： {{ define \u0026#34;main\u0026#34; }} \u0026lt;div style=\u0026#34;max-width: {{ with .Params.custom_width }}{{ . }}{{ else }}100%{{ end }}; margin: 0 auto;\u0026#34;\u0026gt; {{ .Content }} \u0026lt;/div\u0026gt; {{ end }} この例では、内联スタイル（style属性）を使用してdiv要素のmax-width属性を設定し、custom_widthパラメータが指定されていない場合、幅をデフォルトで100%にしています。margin: 0 auto;はdiv要素を中央揃えにします。\n実際のアプリケーションでは、テーマの構造やCSSスタイルの詳細に応じて、上記の例を調整する必要がある場合があります。スタイルを調整する際には、テーマの一貫性と可読性を維持するようにしてください。\n最後に、使用しているテーマが若干異なるため、サイト全体でカスタムCSSの設定も調整しました。\n","date":"2024-01-09","language":"ja","permalink":"https://ttf248.life/ja/p/linux-system-benchmark-test/","tags":["hugo","linux","Sysbench"],"title":"Linuxシステムベンチマークテスト","year":"2024"},{"categories":["コンピューター"],"content":"習慣更新ソフトウェアバージョンです。Gitのどのバージョンの場合にHTTPリポジトリからのコード取得が許可されないか不明ですが、以下のエラーが発生します。\nfatal: Unencrypted HTTP is not supported for GitLab. Ensure the repository remote URL is using HTTPS 背景説明 環境：Windows 平台、これまで小烏龟を使ってgitを操作しており、鍵の認証も小烏龜で処理していました。以前、ローカルリポジトリを一括更新するスクリプトを作成したこともあります。\n前回の記事へのリンク：ローカルGitリポジトリの一括更新\n今日、帰宅してコードの更新を実行したところ、上記のエラーが発生し、リポジトリが正常に更新されなくなりました。Gitの設定でHTTPプロトコルを使用するように変更してみるのが妥当だと思って探しましたが、対応する設定項目は見つかりませんでした。\n最も簡単な解決策は、SSHプロトコルに変更してリポジトリを更新することです。会社側で設定しているgitlabは短期的にHTTPSプロトコルを提供しません。\n既存の問題 以前、ローカルリポジトリをバッチ更新するためのスクリプトを作成する際に、ssh を使ってリポジトリをプルすることを検討していたが、詳細を確認しなかった。小烏龟（TortoiseGit）で設定した git 設定情報を config に同期していなかったため、コマンドラインから\ngit pull # 権限がないために正常に更新できない と表示された。\nSSH キーの確認コマンド (ssh -T git@gitlab.yintech.net) を実行しても問題なく動作するため、小烏龟（TortoiseGit）でコードをプルできるのに、コマンドラインで git pull コマンドを実行すると SSH キーが正しくないというエラーが表示される場合、小烏龟は PuTTY の SSH 鍵を使用しているのに対し、コマンドラインは OpenSSH の SSH 鍵を使用している可能性がある。\n小烏亀の秘钥設定は、システム .ssh フォルダから秘钥ファイル情報を読み取らず、インターフェースでリポジトリ設定を行う際に、個別に秘钥ファイルのパスを設定する。このテクニックを利用すると、プルした最初のリポジトリの設定で秘钥を設定すれば、他のリポジトリも同じ秘钥ファイルを共有できる。PuTTY は秘钥をロードした後、すぐに終了せず、代理サービスを開始する。\nグローバル設定を調整し、システムデフォルトの ssh 設定を使用しないようにすることで、Git Bash は TortoisePlink を使用して SSH 操作を実行するように構成する。この設定は、TortoiseGit に付属の PuTTY ツールを使用する場合に適している。\ngit config --global core.sshCommand \u0026#34;\u0026#39;C:/Program Files/TortoiseGit/bin/TortoisePlink.exe\u0026#39; -batch -ssh\u0026#34; 上記の実行ファイルパスを、ご自身の TortoiseGit のパスに合わせて変更してください。完全なパスを設定することで、システム環境変数に追加する必要はありません。\n","date":"2024-01-08","language":"ja","permalink":"https://ttf248.life/ja/p/git-disable-http-repositories/","tags":["git"],"title":"Git で HTTP リポジトリを無効にする","year":"2024"},{"categories":["コンピューター"],"content":"2年前、サイトにコード領域のコピー機能を追加するために、半日ほど試行錯誤した結果、レンダリング効果が少し不満だった。半ば無能なフロントエンド開発者として、改善することも思わなかった。動けばそれで十分だ、と割り切っていた。今年、AIを使って小程序を開発し、フロントエンドの開発もより慣れてきた。そしてリファクタリングを行った（AIが再設計）。\n悟り：タスク分解をして、多くの小さなタスクはAIで開発すると自然にこなせる。すでに閉鎖された小程序において、75%のコードをAIが提供し、複数のタスクを分割して引き渡すことで、人工によってプロジェクトコードが組み立てられた。\n前文 簡単なことだと考えたけど、コードのコピーボタンを追加する\n正文 promot: クラス \u0026ldquo;highlight\u0026rdquo; を持つウェブページの要素のコンテナ内に、コードと JavaScript の CSS およびコードを記述して、テキストのコピー機能を実現するコピーボタンを追加します。\n最初のドラフトのコードは一見問題があり、基本的には使用可能なものを生成し、コピーされた内容が正しくなく、冗長な文字が含まれているため、最適化を再度誘導し、コアの色設計を指定し、エフェクトを含めるようにしました。\nお客様がボタンのサイズと色に関して特定の要件をお持ちであることを認識しており、これらの要件に合わせてスタイルのデザインを再構築できます。以下は、提供されたカラーパレットとボタンサイズの最適化を含むスタイルです。\n.copy-btn { position: absolute; top: 2px; /* 位置調整 */ right: 2px; padding: 3px 6px; /* サイズ縮小 */ font-size: 12px; /* フォントサイズ縮小 */ background-color: #8FD1E1; /* ボタンの背景色 */ color: #272822; /* テキストの色 */ border: 1px solid #272822; /* ボーダーの色 */ border-radius: 3px; /* 角丸 */ cursor: pointer; opacity: 0.7; /* デフォルトの不透明度 */ transition: opacity 0.3s ease, background-color 0.3s ease; /* 平滑なトランジション効果 */ } .copy-btn:hover { opacity: 1; /* マウスオーバー時に完全表示 */ background-color: #A3D4E5; /* マウスオーバー時の背景色 */ } .highlight { position: relative; } このスタイルでは、ボタンのサイズとフォントサイズを小さくして、より洗練された外観にしています。また、ボタンはデフォルトで半透明になっており、マウスをホバーすると完全表示され、背景色がわずかに明るくなることで視覚的なフィードバックを提供します。これにより、お客様のカラー要件を満たしつつ、モダンでユーザーフレンドリーな特徴を備えたデザインを実現しています。\n以下はよりシンプルな JavaScript です。\ndocument.addEventListener(\u0026#39;DOMContentLoaded\u0026#39;, function() { // すべての .highlight 要素を検索 const highlights = document.querySelectorAll(\u0026#39;.highlight\u0026#39;); highlights.forEach(function(highlight) { // コピーボタンを作成 const copyBtn = document.createElement(\u0026#39;button\u0026#39;); copyBtn.textContent = \u0026#39;コピー\u0026#39;; copyBtn.classList.add(\u0026#39;copy-btn\u0026#39;); // ボタンを各 .highlight 要素に追加 highlight.appendChild(copyBtn); // クリックイベントリスナーを追加 copyBtn.addEventListener(\u0026#39;click\u0026#39;, function() { // .highlight 内の最初の \u0026lt;code\u0026gt; 要素からコピーするコードを取得 (存在する場合) const code = highlight.querySelector(\u0026#39;code\u0026#39;) ? highlight.querySelector(\u0026#39;code\u0026#39;).textContent : \u0026#39;\u0026#39;; navigator.clipboard.writeText(code).then(() =\u0026gt; { // コピー成功メッセージを表示 copyBtn.textContent = \u0026#39;已コピー!\u0026#39;; setTimeout(() =\u0026gt; { copyBtn.textContent = \u0026#39;コピー\u0026#39;; }, 2000); }).catch(err =\u0026gt; { console.error(\u0026#39;コピー失敗: \u0026#39;, err); }); }); }); }); 終わりに コード領域の右上隅に、トップエリアにコピーボタンを追加することを望んでいたが、フロントエンドに関する知識が不足しており、キーワードに基づいて機能を正確に記述することができなかったため、AIと何度もやり取りして期待に応えられなかった。\nしかし、時間の経過とともに、AIがプログラミング開発にどの程度の影響を与えるのかは分からない。\n","date":"2023-12-22","language":"ja","permalink":"https://ttf248.life/ja/p/ai-programming-and-task-decomposition/","tags":["chatgpt","ai","タスク分解","コード領域","コピーボタン"],"title":"AIプログラミングとタスク分解","year":"2023"},{"categories":["魚の7秒間の見聞"],"content":"東方甄選小作文事件是一起由於东方甄选官方账号否认主播董宇辉是所有小作文的作者而引發的網路風波。到底真相如何，已經無從考證，公司權謀的鬥爭將這個事情推上了風口浪尖。\n魚的七秒鐘記憶，以後都交付給AI撰寫，嘗試了Bing AI和ChatGPT plus，前者給的資料更加完整，搜尋引擎的獲取的資料還是更多一些，輸出的博文內容不夠完整，格式比較僵硬；後者透過關鍵字獲取內容，生成的內容不是那麼完整，但是能獲得完整的博文內容，如果給出參考資料的網址，就能優化生成的稿子。\n正文 東方甄選小作文事件は、著作権と創作帰属を巡る論争であり、2023年12月5日以降、主播の董宇輝と东方甄選が関わる一連のインタラクションによって引き起こされました。この騒動は、商業運営の複雑さを示すだけでなく、現代の商業文化やインターネット社会に対する深い反省を促しました。\n2023年12月5日：事件の起点 Oriental Zen Selectionは、ホストの董宇輝が朗読した「短い文章」（小作文）の動画を公開し、それが急速に人気を集めた。 Oriental Zen Selectionは動画のコメント欄で、これらの小作文は多くがコピーライターチームによって作成されたものであり、すべて董宇輝が書いたものとは限らないと声明を発表した。 2023年12月13日：董宇辉の回答 董宇辉は長文を投稿し、「ファンダム」という名目で誰かを中傷することに反対し、自身の立場を表明した。 2023年12月14日：経営陣の回答 东方甄选CEOの孫東旭、謝罪動画を公開し、会社運営における欠陥を認めた。 东方甄选の董事长である俞敏洪も事件についてコメントし、董宇輝に謝罪した。 2023年12月16日：重大決定 东方甄选官方宣布免去孙东旭的CEO职务，俞敏洪兼任。 同日，俞敏洪发表致歉信，表示将解除直播间拉黑的网友。 2023年12月18日：董宇辉的新角色 新東方教育科技集團任命董宇輝為新東方教育科技集團董事長文化助理，兼任新東方文旅集團副總裁。 俞敏洪透露，將與董宇輝成立工作室，開闢新的直播帳號和直播間。 結論と反省 この騒動は、著作権と創作の帰属に関する争いであるだけでなく、文化とビジネスの衝突をより深く反映している。デジタル化され、断片化された時代背景の下において、コンテンツ制作の著作権帰属は、深く考えるべきテーマとなっている。東方甄選小作文事件は、単なるメディア騒動ではなく、現代における商業文化とインターネット社会に対する深刻な反省でもある。\n観察者として、私たちはこのような文化とビジネスの衝突をどのように捉えるべきか？商業的利益を追求する一方で、創造者の労務成果をどのように保護し尊重すべきか？これらの問題は、私たち一人ひとりが深く考えるべきものである。\n","date":"2023-12-20","language":"ja","permalink":"https://ttf248.life/ja/p/dongfang-zhenxuan-essay-controversy-culture-vs-commerce/","tags":[],"title":"東方日報・エナンゼンの小作文騒動：文化とビジネスの衝突","year":"2023"},{"categories":["AI霊感衝突坊"],"content":" 課金型ゲーム（かきんがたげーむ）：ここでは議論しません。ゲームコミュニティ内での呼称で、円安战士を指します。ゲーム設定の理解は不要で、潤沢な資金が必要です。 周辺の小弟の前を挟み、城を「屠城」（とじょう）する快感を享受します。 広範な視聴者を持つeスポーツタイトル（例：英雄伝説 オリンス、DOTA2、王者荣耀、バトルロイヤル バトルパス）：これらのゲームは、完全な世界観設定と健全な競技イベントサイクルを備えています。 ゲームデザインにおいて、心理学は重要な分野であり、特にソーシャルサイコロジーが重要です。人々の行動、ニーズ、動機を理解することで、より魅力的なゲーム体験を設計することができます。「自慢話」とソーシャルサイコロジーの関係について、以下の角度から考察できます。\n社会的承認欲求: 人々は社交グループの中で承認欲求を満たそうとします。ゲームにおいて、プレイヤーが特定の分野で優れていると感じさせたり、他のプレイヤーの注目を集めたりすることで、この承認欲求を満たすことができます。これは、スキルを誇示したり、獲得した報酬を示したりすることによって表現されます。 社会的競争: 一部のゲームは、社交ネットワーク上で自分の成果を示すことを奨励する要素を取り入れています。これは、ランキングシステム、アチーブメントシステム、またはマルチプレイヤー対戦などの方法で実現できます。このような設計は、プレイヤー間の競争心理を刺激し、一部のプレイヤーがより優れたパフォーマンスを発揮して社会的承認を得ようとする可能性があります。 自己表現: 一部のゲームでは、キャラクターのカスタマイズや仮想アイテムなどを通じて自己表現を行うことができます。この自己表現は、単なる自慢話だけでなく、個性と社交的な交流の方法を示すものにもなります。 チームワーク: 一部のゲームは、チームワークを重視し、ソーシャルインタラクションを通じてゲーム目標を達成します。このような状況下では、「自慢話」の行為は必ずしも奨励されず、チーム協調と相互サポートが強調されます。 心理的報酬システム: ゲームデザインは、プレイヤーの積極的な社交行動を刺激するために、心理的報酬システムを採用することができます。たとえば、プレイヤーに報酬や特権を与え、積極的にソーシャルインタラクションに参加するように促します。 全体として、ゲームデザインにおけるソーシャルサイコロジーは、プレイヤー間の相互作用とソーシャル体験を形作るために使用できます。「自慢話」の行為は、特定の状況下では存在しうるものの、ゲームデザイナーは通常、この行為をバランスさせるように努力し、すべてのプレイヤーにとってポジティブで楽しいゲーム体験を確保します。\n思いついたところまで書いただけで、完全なアウトラインはありません。少し散漫です。 筆者がよくプレイする英雄伝説 オリンスは、私たちが世代の記憶の一部であり、ほとんどの保護者が子供がゲームをプレイすることを好まないのは、このタイプのゲームを深く理解していないことと、ゲーム設定に関連しているためです。各試合は新しい始まりであり、多くの子供にとって、プレイ中に過度な思考を伴わないようにしています。これは、彼らが独自の探索方法に依存することを示しています。このような状況下では、ゲームの勝敗は、子供自身のゲームスキルに大きく左右されます。筆者の実際の経験に基づいて、相当数のプレイヤーがこのタイプに属しており、彼らにとっては、…\n最大のコストは金銭ではなく時間です。\nゲーム内にはエンターテイメントモードもあり、娯楽を求めるプレイヤーのニーズを満たしています。 英雄聯盟のような競技性の高いゲームは、筆者にとって「三国志」の世界を体験する機会でした。序盤では手持ちの資源はほとんどなく、自分の理解力でキルやヒールを行い、経済力を高め、視界を確保し、相手を待ち伏せするなど、戦略を練りながらプレイします。抜群のゲームセンスを持っていても、そうでない自分でも十分に楽しむことができます。全体を統率する「コントロール感」、不利な状況から逆転して喜びを感じる「爽快感」。 また、多くの人が語る「クラウドプレイヤー」もいます。彼らはもうゲームをプレイしていませんが、世界大会期間中には必ず試合を見守ります。 ここで触れておくべきは、「ゲーム時間」です。それは単一のゲームの時間ではなく、あなたがログインする時間のことです。週末の午後の時間、仕事終わりの夜7時から10時頃など、ほとんどの場合、チームメイトとスムーズにコミュニケーションを取り、送信した信号が理解され、返信があるのを確認できます。しかし、例えば徹夜でプレイする場合、遭遇するのは「ネット依存少年」であり、有利な状況では彼らはあなたのことを慰めることさえあります。画面越しでもその「怒り」を感じ取ることができます。 そもそもIT業界に携わっており、ゲームも多く触れ、色々な種類をプレイしてきたため、競技性の高いゲームは常に自分の頭を使ってプレイする習慣があり、反射速度や才能に頼るのではなく、チームを指揮する役割を担うことを好んでいました。最初は、学生時代にYY工会の大黒柱たちと一緒に遊んでいたのがきっかけでした。 今のゲーム環境はどうでしょうか。以前ほど落ち着きがなく、純粋なものではありません。\n長年級をプレイした後、高分段の対局をしてプレイすると本当に疲れます。 常に高度集中し、相手の謀略を考え、相手の設局をどのように回避するかを考える、まるで「プレイが終わったらもう続けたくない」という状態です。\n真に言わせてください、あなたが非常に上手いので、プロの試合に出場しない限り、人生の軌跡にはほとんど影響しません。 社交の手段としては有効ですが、生計を立てることはできませんし、社会の中で立ち上がることができません。\nシングルプレイゲームとオンラインゲームは、異なる種類のゲームであり、その玩法、体験、技術において顕著な違いがあります。 以下に、シングルプレイゲームとオンラインゲームの違いを理解するための重要な側面を示します。\n接続方法：\nシングルプレイゲーム（オフライン/シングルプレイヤー）： このようなゲームは、ローカルデバイス上で単独でプレイされ、インターネット接続が不要です。 ネットワーク接続なしでゲーム体験を楽しむことができます。 オンラインゲーム（オンライン/マルチプレイヤー）： これらのゲームは通常、インターネット接続が必要です。これは、プレイヤーがリアルタイムで他のプレイヤーと相互作用する必要があるためです。 オンラインゲームは、協力または競争的なものがあり、オンラインソーシャルインタラクションや競技を含みます。 プレイヤーの相互作用：\nシングルプレイゲーム： プレイヤーは、人工知能、プリセットされたタスク、または敵対的な要素と相互作用します。 ゲーム体験は通常、ゲーム内デザインとストーリーの影響を受けます。 オンラインゲーム： プレイヤーは、世界中の他のリアルなプレイヤーと相互作用できます。 これには、タスクの共同完了、競争、競技大会、チャット、ギルドシステムなどのソーシャル要素が含まれます。 ゲームのデザインとコンテンツ：\nシングルプレイゲーム： ゲームデザインは、完全で独立したストーリーとゲーム体験を提供するのに重点を置いています。 ゲーム内容は通常、事前に設計されており、プレイヤーはゲーム内で探索、パズル解決、または戦闘を行います。 オンラインゲーム： ゲームデザインは、リアルタイムインタラクションとプレイヤー間の競争または協力を考慮する必要があります。 ゲームの内容はよりダイナミックで、定期的なアップデート、オンラインイベント、ソーシャルインタラクションが含まれる場合があります。 技術要件：\nシングルプレイゲーム： 通常、オフライン状態で実行でき、デバイスのパフォーマンスとインターネット接続に対する要求は比較的低いです。 オンラインゲーム： 強いインターネット接続が必要であり、サーバーとネットワーク性能に関する高い要求があります。 これにより、リアルタイムインタラクションがスムーズに行われるようにします。 ビジネスモデル：\nシングルプレイゲーム： 通常、一度限りの購入またはダウンロードのビジネスモデルを採用しており、プレイヤーはゲームを購入するとローカルデバイスでゲームを完全にプレイできます。 オンラインゲーム： 無料プレイ、広告、アイテム購入、サブスクリプションなど、さまざまなビジネスモデルを採用することがあります。 これにより、サーバー運営とゲームコンテンツの継続的な更新が維持されます。 これらの違いを理解することで、プレイヤーは自分の好みを明確にし、ゲームデザイナーがプレイヤーの期待に応えるのに役立ちます。\n","date":"2023-12-11","language":"ja","permalink":"https://ttf248.life/ja/p/game-psychology-competitive-gaming/","tags":["ゲーム","心理学","eスポーツ (エスポート)"],"title":"ゲーム心理学：eスポーツ (げーむしんりよく：えスポーツ)","year":"2023"},{"categories":["コンピューター"],"content":" データマイニング\nディープラーニング\nニューラルネットワーク\n双十一のセールで、阿里云に新しいサーバーを導入しました：経済的なモデル、99ドル年間契約、構成は高くありません。ホップサーバーとして、自宅のサービスを代理するのに適しています。イベントは2026年まで続きます。\n特に上海地域のサーバーを選びました。低遅延で自宅の機械を代理し、Windows 11とWindows Server 2022を使用しました。Server版は後から展開したもので、使用中に拒否アクセスメッセージを受け取りました。当初はサーバーのアップデートだと考えましたが、すぐに回復しませんでした。関連するエラーメッセージを検索すると、誰かがログインを試みていることが示され、パスワードが間違っているため、ログインできなくなりました。 以前にもセキュリティ攻撃のスクリプトに触れたことがあります。すぐに、これらのログインは正常な行動ではないことに気づきました。サーバーが攻撃を受けており、ログインを暴力的に試みている可能性があります。サーバーのファイアウォール設定は簡素で、ホワイトリストを設定していませんでした。自宅の2台の機械の3389ポートをパブリックに公開したため、魚塘の餌のように、誰かがターゲットになりました。攻撃者がスクリプト小子であることを知ったので、次のことは単純でした。ファイアウォールのホワイトリストを設定し、会社のIPアドレスと自宅のIPアドレスのみが代理サービスへのアクセスを許可するようにしました。 frps 代理サーバーの以前の設定では、ログ記録が無効でした。ログを有効にすると、全国各地の代理IPアドレスが自宅サーバーにログインしようとしていたことがわかりました。幸いなことに、Server版の1台がありました。それによって、Windows 11の機械は必ず攻撃され、パスワード設定が簡単だったため、問題が発生するのを防ぐことができました。\n2023/11/17 16:51:14 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [101.43.98.211:50486] 2023/11/17 16:51:14 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [218.93.202.63:56970] 2023/11/17 16:51:14 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [222.179.106.174:60812] 2023/11/17 16:51:15 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [58.16.204.238:2839] 2023/11/17 16:51:15 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [124.223.47.24:50274] 2023/11/17 16:51:16 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [43.248.128.22:55883] 2023/11/17 16:51:16 [I] [proxy.go:204] [639d8947325142ac] [host-remote] get a user connection [43.143.53.138:56955] 2023/11/17 16:51:16 [I] [proxy.go:204] [639d89473251 ```shell Nov 16 04:46:34 aliyun-sh sshd[156625]: 無効なパスワード：root から 120.55.164.64 ポート 53410 の ssh2 Nov 16 04:46:34 aliyun-sh sshd[156623]: 無効なパスワード：root から 111.16.215.122 ポート 36548 の ssh2 Nov 16 04:46:58 aliyun-sh sshd[156630]: 無効なパスワード：無効なユーザー share から 139.9.233.78 ポート 53872 の ssh2 Nov 16 04:47:23 aliyun-sh sshd[156634]: 無効なパスワード：無効なユーザー spark から 139.9.233.78 ポート 36134 の ssh2 Nov 16 04:47:26 aliyun-sh sshd[156636]: 無効なパスワード：root から 120.55.164.64 ポート 46142 の ssh2 Nov 16 04:47:47 aliyun-sh sshd[156640]: 無効なパスワード：root から 111.16.215.122 ポート 42962 の ssh2 Nov 16 04:48:24 aliyun-sh sshd[156652]: 無効なパスワード：root から 120.55.164.64 ポート 38868 の ssh2 Nov 16 04:48:25 aliyun-sh sshd[156654]: 無効なパスワード：root から 111.16.215.122 ポート 46164 の ssh2 Nov 16 04:48:39 aliyun-sh sshd[156657]: 無効なパスワード：無効なユーザー test から 139.9.233.78 ポート 39386 の ssh2 Nov 16 04:48:50 aliyun-sh sshd[156659]: 無効なパスワード：root から 111.16.215.122 ポート 38892 の ssh2 Nov 16 04:48:53 aliyun-sh sshd[156662]: 無効なパスワード：root から 120.55.164.64 ポート 49348 の ssh2 Nov 16 04:48:53 aliyun-sh sshd[156664]: 無効なパスワード：無効なユーザー test から 139.9.233.78 ポート 49864 の ssh2 Nov 16 04:50:02 aliyun-sh sshd[156672]: 無効なパスワード：root から 111.16.215.122 ポート 45294 の ssh2 Nov 16 04:50:30 aliyun-sh sshd[156680]: 無効なパスワード：無効なユーザー zabbix から 139.9.233.78 ポート 52206 の ssh2 Nov 16 04:50:50 aliyun-sh sshd[156683]: 無効なパスワード：root から 120.55.164.64 ポート 34820 の ssh2 Nov 16 04:50:51 aliyun-sh sshd[156685]: 無効なパスワード：root から 111.16. ## 付録 独自のサーバーを構築する場合、Windows のパブリックアクセスにはホワイトリストの設定が必要です。Linux では、パスワードログインの無効化と、キーファイルによる認証の有効化をお勧めします。 ","date":"2023-11-20","language":"ja","permalink":"https://ttf248.life/ja/p/cloud-servers-and-script-kids/","tags":[],"title":"クラウドサーバーとスクリプトキッド","year":"2023"},{"categories":["コンピューター"],"content":"チームのプロジェクト間に依存関係があり、歴史的な理由から submodule を使用せずにプロジェクトの依存を管理してきました。日常の開発では、リポジトリコードを順番に手動で更新する必要があり、そうでない場合、さまざまな奇妙な問題が発生する可能性があります。\nオンラインの情報源を参照して、構造は基本的に同じです。ローカルで git_list.txt というディレクトリを維持し、スクリプトを使用してディレクトリを反復処理し、一度に更新を実行し、その後、作業を開始する前にこのスクリプトを実行します。\nLinux 新しいファイルを作成: batch_pull.sh\n#!/bin/bash echo \u0026#34;============ リポジトリの更新 ===================\u0026#34; # git_list.txt が存在するか確認 if [ ! -f \u0026#34;git_list.txt\u0026#34; ]; then echo \u0026#34;git_list.txt ファイルが存在しません！git をプルするリポジトリ URL を作成し、追加してください。\u0026#34; exit 1 else echo \u0026#34;============ git リポジトリリストを検出しました ====\u0026#34; fi # git_list.txt から URL を一行ずつ読み込み、プル操作を実行 while read -r url; do if [ -d \u0026#34;$url\u0026#34; ]; then cd \u0026#34;$url\u0026#34; || continue git pull cd .. echo \u0026#34;Pull $url が完了しました！\u0026#34; echo \u0026#34;========================================\u0026#34; else echo \u0026#34;ディレクトリ $url は存在しません。プルをスキップします。\u0026#34; fi done \u0026lt; \u0026#34;git_list.txt\u0026#34; Windows 新しいファイルを作成: batch_pull.bat\n@echo off chcp 65001 \u0026gt; nul rem スクリプトの存在するディレクトリへ移動 cd /d \u0026#34;%~dp0\u0026#34; rem git_list.txt が存在するか確認 if not exist \u0026#34;git_list.txt\u0026#34; ( echo git_list.txt ファイルが見つかりません！ git リポジトリ URL を作成し、追加してください。 exit /b 1 ) else ( echo ============ git リポジトリリストファイルが検出されました ========= ) rem git_list.txt 内の URL を行ごとに読み込み、プル操作を実行 for /f %%i in (git_list.txt) do ( if exist \u0026#34;%%i\u0026#34; ( pushd \u0026#34;%%i\u0026#34; git pull popd echo %%i のプルが完了しました！ echo ======================================== ) else ( echo ディレクトリ %%i は存在しません。スキップします。 ) ) 過去の遺留問題 再装システム後に発生した git フォルダの権限ファイルに関する問題を解決します：致命的なエラー「unsafe repository (\u0026rsquo;/home/repon\u0026rsquo; is owned by someone else)」 オンラインで提案されている解決策は、主に stack overflow から提供されています。\nリポジトリディレクトリに信頼を追加: git config --global --add safe.directory /home/repon .gitconfig ファイルを手動で編集し、ディレクトリを信頼として指定 [safe] directory = /home/repon 上記の方法により、リポジトリの更新は正常になりましたが、毎回 git pull を実行する際にコンソールに多数の警告メッセージが表示され、所有者に関するエラーを示しています。\nデスクトップPCのシステム再インストール 長らくシステムを再インストールしていなかったマシンで、システムディスクにゴミファイルが爆発的に発生し、仕方なく空き時間を利用してシステムを再構築した。再度この権限の問題に遭遇し、以前のスクリプトが動作しない原因は、修正した権限が不完全だったことによるもの。\n新しい解決策を採用し、*を追加することで、gitがすべてのディレクトリを自動的に信頼するように設定した。\ngit config --global --add safe.directory \u0026#34;*\u0026#34; これはユーザーの権限の問題か、それとも皆さんがWindowsプラットフォームに慣れていないことが原因なのか。実際にはchownのようなコマンドも存在する。フォルダの所有者を変更することはもちろん可能だが、もしディレクトリ数が少ない場合は、手動で所有者を変えることもできる。しかし、このワークステーションはドメイン情報を追加しており、おそらく会社のドメインが異常を抱えているか、あるいはローカルシステムの設定に問題があるため、ユーザーリストからログインに使用するユーザーが見つからない状態だった。最終的にはコマンドラインを使用して問題を解決した。\n管理者権限でpowershellスクリプトchange_ower.ps1を実行し、スクリプトファイルのエンコーディングをgbkに設定することを忘れないでください。中国語のオペレーティングシステムでは、そうしないと文字化けしてしまうため。\n# 現在のユーザー名を取得 $currentUserName = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name # PowerShell の文字エンコーディングを UTF-8 に設定 [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 # 所有者を変更するルートディレクトリパス $rootDirectory = \u0026#34;G:\\workspace\u0026#34; # 実際のパスに置き換えてください # ディレクトリとファイルを再帰的に取得し、所有者を変更 Get-ChildItem -Path $rootDirectory -Recurse | ForEach-Object { $itemPath = $_.FullName # アイテムがファイルかディレクトリかをチェック if ($_ -is [System.IO.DirectoryInfo]) { # ディレクトリの場合、icacls コマンドを使用して所有者権限を変更 $icaclsResult = icacls $itemPath /setowner \u0026#34;$currentUserName\u0026#34; 2\u0026gt;\u0026amp;1 if ($LASTEXITCODE -eq 0) { Write-Host \u0026#34;ディレクトリ $itemPath の所有者を $currentUserName に変更しました\u0026#34; } else { Write-Host \u0026#34;ディレクトリ $itemPath の所有者変更に失敗しました。エラー情報: $icaclsResult\u0026#34; } } else { # ファイルの場合、icacls コマンドを使用して所有者権限を変更 $takeownResult = icacls $itemPath /setowner \u0026#34;$currentUserName\u0026#34; 2\u0026gt;\u0026amp;1 if ($LASTEXITCODE -eq 0) { # Write-Host \u0026#34;ファイル $itemPath の所有者を $currentUserName に変更しました\u0026#34; } else { Write-Host \u0026#34;ファイル $itemPath の所有者変更に失敗しました。エラー情報: $takeownResult\u0026#34; } } } 予想外の事態が再び発生し、スクリプト実行時の出力された日本語の情報が文字化けした。コンソールエンコーディングの設定を調整したり、スクリプトのエンコーディングを変更したりしたが、すべて文字化けしてしまう。おそらく脳みそが完全に機能停止しているのだろうと推測し、コントロールパネル - 領域 - 言語設定のベータ機能を試してみた。グローバルにUnicodeエンコーディングを有効にし、スクリプト実行は正常になった。いくつかの開発ソフトウェアが正常に動作しないままであり、後で資料を整理したところ、スクリプトファイルのエンコーディングをgbkに設定する必要があることを思い出した。\n资料 https://ganzhixiong.com/p/f1b9f4fc/ https://stackoverflow.com/questions/71901632/fatal-error-unsafe-repository-home-repon-is-owned-by-someone-else ","date":"2023-10-19","language":"ja","permalink":"https://ttf248.life/ja/p/bulk-update-local-git-and-legacy-permissions/","tags":["git"],"title":"ローカルのGitリポジトリと履歴上の遺留権限の問題の一括更新","year":"2023"},{"categories":["コンピューター"],"content":"小規模アプリ（ミニプログラム）開発の設計上の問題がまだ解決されておらず、新たにWPFを立ち上げました。最近会社にも波乱があり、遠隔地での共同作業におけるコミュニケーション効率は依然として不十分で、思い切ってクライアント側のUI開発を受注しました。\nWPF WPF 微软官网学习资料 WPF 基础总结(学習建議) WPF 中文網 WPF 个人まとめと学習推奨 WPF のインターフェースデザインで使われる多くの概念は、ウェブページフロントエンドのデザインに似ています。可能な限り UI デザインとビジネスロジックを分離し、UI デザインを独立して開発することも、インターネット企業が期待する分業方法です。今年、小程序（ミニアプリ）の開発をした経験があり、多くの概念は共通しているため、習得も比較的容易でした。これらのものは現代の UI 設計における「道」であり、基本的なフレームワークの概念を理解することで、その後の道が曲がりにくくなります。\n以前 WinForm 開発の経験がある読者の場合は、WPF 基礎まとめ(学習建議) を読んでください。内容は短いため、経験豊富な読者が学習ルートを計画するのに適しています。\n初心者の方は、WPF 中文網 から始めて、基本的な概念、発展の歴史、低レベルクラスの論理的認知について理解してください。このウェブサイトは偶然にもタイミングが合っており、今年8月に作者がリリースしたばかりで、読者を惹きつけ、コースの購入を促すためのものです。私のコンテンツとのタイミングが一致しなかったら、ほぼ無縁になっていたでしょう。\n最も本格的な学習資料は、もちろん Microsoft の公式資料ですが、内容は少し退屈なので、新参者は根気強く学ぶ必要があります。\n古典的な電子書籍もたくさんありますが、日常業務に追われるため、静かに読書する時間は限られています。プロジェクトで実践しながら学習することが最適です。\nC# と .NET のリリース履歴 以前学習した言語について、最近数年間の新機能のリリースが少し多いため、文法のバージョンが毎年更新されています。 https://en.wikipedia.org/wiki/C_Sharp_(programming_language) 公式学習資料：\nhttps://learn.microsoft.com/zh-cn/dotnet/csharp/ https://learn.microsoft.com/zh-cn/dotnet/core/tutorials/with-visual-studio?pivots=dotnet-7-0 ","date":"2023-10-17","language":"ja","permalink":"https://ttf248.life/ja/p/wpf-learning-resources/","tags":["WPF"],"title":"WPF学習資料","year":"2023"},{"categories":["魚の7秒間の見聞"],"content":"中国共中央政治局：要加大国有企业、金融领域的反腐败力度，深入纠治“四风”。\n中国共中央政治局 中共中央政治局は9月27日に会議を開き，《 بشأن第20回全国党大会初の巡視調査の結果に関する総合報告》を審議しました。中国共産党総書記習近平が会議を主導しました。会議では、巡視調査を契機として、党の全面的な指導をさらに強化し、巡視対象となる党組織に政治的立場を高めさせ、党中央から委託された責任と使命を誠実に履行させ、国有企業の核心機能と競争力を高め、中国特色社会主義の重要な物質的基盤と政治的基盤を夯け、金融企業の経済主体へのサービスと国家戦略への貢献を強化し、質の高い発展を推進することを強調しました。開発と安全を統籌し、底線思考と限界思考を確立し、重大なリスクを防止・軽減するための有効な措置を講じ、安全の底線を確実に守るべきだとしました。全面から厳格な党規律の実践をさらに深めることとし、党委（党組）書記の第一責任人としての責任、幹部団体のメンバーにおける「一岗双责」（一つの職務二つの責任）、紀検監察機構における監督責任を強化し、各級「一把手」（一把は「一人の手」の意味）に対する監督を強化し、国有企業や金融分野での腐敗撲滅の力度を高め、四風（不正行為）を深く是正し、事例を基にした改革と治理を行い、敢えて腐敗しない、腐敗しない、腐敗したくないという姿勢を一体的に推進することを目指しました。（新華社）\n重大な金融リスクを引き起こす！中国銀行原党委书记・董事长劉連舸が党籍から除名 中央紀委国家監察委員会ウェブサイトによると、中共中央の承認に基づき、中央紀委国家監察委員会は中国銀行股份有限公司の原党委书记・董事长劉連舸の重大な不規律・違法行為に関する立案調査を実施しました。 調査の結果、劉連舸は理想と信念を喪失し、初心と使命を放棄し、党中央の決定と指示を揺るぎなく実行せず、打ち切ったり、弱体化させたりしただけでなく、金融リスク管理の責任を放棄し、違法な融資を行い、重大な金融リスクを引き起こし、全面から厳格な党規律の実践における主体責任を果たさなかっただけでなく、所在組織の政治的生態を深刻に損ない、私用で禁制品である書籍を持ち込んだことになり、心積もり積もって組織の調査に抵抗し、中央八項規定精神を無視し、違法な贈り物や会所への出入り、スキーや旅行の接待を受け、長期間管理対象者の車両を利用し、規則に従わない個人に関する事項の報告をしなかったため、組織からの問い合わせに対して誠実に対応せず、私的な採用と昇進における不正行為を行い、違法に資金の融資・借入れに関与し、秘密情報を私的に保持し、道徳的堕落を犯し、家族の管理を怠り、法規や倫理の底線を持たず、「金融で金融を食べる」ことを通じて、職務上の便宜を利用して他人の融資・資金調達やプロジェクト協力などの分野で利益を得ており、巨額の賄賂を受け取っていました。\n劉連舸は、党の政治的紀律、組織的紀律、廉潔的紀律、業務的紀律、生活的紀律に重大な違反を犯し、受贿罪と違法な融資行為に関与しており、党十八大以降、収縮・抑制せず、さらに拡大したため、性質が深刻で悪影響を与え、厳粛な処分を受けるべきだとされました。中国共産党規律処罰条例、中華人民共和国監察法、中華人民共和国公職人员政务处分法などの関連規定に基づき、中央紀委常委会の会議において研究され、中共中央の承認を経て決定され、劉連舸に党籍除名処分を与え、按定された待遇を取消し、その代表資格を停止し、違法な所得を没収し、犯罪に関与している問題を検察機関に移送することになりました。\n中国光大グループ原党委书记・董事长李晓鹏が重大な不規律・違法行為により党籍と公職から除名。（央視新聞） 中央紀委国家監察委員会ウェブサイトは、貴州省紀委監委の報道に基づき：貴州銀行の原党委书记・董事长李志明が重大な不規律・違法 昨年8年ぶりに、匯金が四大行を買い注ぎ 2024年10月11日、工商銀行、農業銀行、中国銀行、建設銀行の四大国有商業銀行はそれぞれ公告を発表され、匯金公司による買い注色が、2761万株、3727万株、2489万株、1838万株となりました。 匯金公司は今後6ヶ月以内に二级市場で四大行を継続的に買い注ぎ続ける予定です。\n","date":"2023-10-09","language":"ja","permalink":"https://ttf248.life/ja/p/financial-anti-corruption-curtain-rise/","tags":["金融","反腐败 (Hанфуbài)","中央政治局 (ちゅうおうせいしんきょく)"],"title":"金融汚職の幕開け (Kin'yū okujo no makkake)","year":"2023"},{"categories":["メモ書き雑感"],"content":"配信者からのiPhone？ミニプログラムランキングの報酬？様々なライブプラットフォームでのギフト抽選会？\n上記の3つは、あまり関連性のないものに見えますが、実際には無料トラフィックによる収益化の異なるパターンであり、少し金融ゲームのようなものです。\nプラットフォームでのラッキープリズ獲得 一般的な状況では、ユーザーがリセットしてプラットフォーム通貨を獲得した後、心怡の配信者へギフトを購入したり、各プラットフォームには別の遊び方があります。ユーザーがプラットフォーム通貨を獲得した後、直接ギフトを送るのではなく、一定量の通貨を使って抽選イベントに参加し、限定の高いギフトを獲得することができます。\nこの時点で問題が発生しています。オンライン抽選は、簡単に言うとプラットフォームがカジノを開いて、参加人数が多いほど確実に利益を出すということです。**屌ス（草θ）**のようなユーザーが、モバイル端末で一か所勝負する心理で、大当たりを期待し、その後ギフトを贈ることで、面子を得て、大哥（リーダー）になる！\n配信者からの贈り物（実物） 前述のプラットフォーム抽選は、ユーザー自身の投稿内容を対象としています。配信者は毎月流水ミッションや人気度ミッションを実施し、ギフト抽力を開始する玩法では、ファンが指定されたギフトを贈ったり、指定金額のギフトを贈ったりすることで抽選に参加できるチャンスを得ます。そのギフトは高級スマートフォンであったり、現金ハッピーバッグであったりします。 人気のある配信者にとって、この活動は非常に収益性が高く、一時的なゼロコスト購入に相当し、参加者が十分にあれば、配信者は利益を得ることができます。ここでは配信者の運営能力が試されます。 もちろん、報酬が高い玩法もあります（現金価値）。多くの屋外配信者はこの玩法を利用しており、間接的にオンラインギャンブルを行っていると言えます。視聴内容には誰も関心がなく、ユーザーは自分自身が当選できるかどうかだけを気にします。 ショー形式の配信者を除いて、PKモードを通じてファンに消費を促し、一般的なゲーム配信者は、プレイヤーの消費意欲を高めることが難しく、ゲームプレイとライブ視聴は娯楽であり、追加の金銭支出を望まないものです。特に競技性の高いゲームにおいては、抽選方式がユーザーの課金習慣や消費習慣を育み、時折衝動的な消費（大量に送る、当選したい気持ち）を引き起こす可能性があります。\nミニプログラムランキング報酬 ミニプログラムを設計し、役に立たないワークフローを作成したり、一部のゲームに関連する補助サービスを提供したりします。これらはすべて、騰訊（テンセント）の審査に通るための掩護措置です。ミニプログラム内の遊び方は、ランキングメカニズムを追加して、ユーザーが閲覧したインセンティブ広告やタスクを完了することでポイントを獲得し、ポイントに基づいてランキングを設定し、上位のランキングのユーザーに指定された報酬を与えます。\nコアロジック：広告収入 \u0026gt; 運営コスト + 報酬費用\nミニプログラムにも正常な稼働の方法があり、適切なサービスを提供し、適度な広告を通じて収益を得ることができます。得られる金額は多くないかもしれませんが、わずかな流れでもあり、それは可能です。\n","date":"2023-09-19","language":"ja","permalink":"https://ttf248.life/ja/p/traffic-monetization-business-model-raffle/","tags":["トラフィック収益化 (Torakku Shuyaku-ka)","くじ引き","プレゼント (Purezento)","生放送","ミニプログラム (minipurasu)","ランキング"],"title":"トラフィック収益化のビジネスモデル：くじ引き","year":"2023"},{"categories":["コンピューター"],"content":"オフィスに新たにミニPCを入手し、環境構築を兼ねて便利に考えたのですが、自宅でも時折アクセスする必要があるため、一時的に社内ネットワークのトンネリングを実施することになりました。これまでの経験から、frpサービスをデプロイしてポートフォワーディングを設定する方法を選びましたが、その品質は公開サーバーの帯域幅に依存します。少しばかり新鮮なZerotier仮想マシンによるローカルエリアネットワーク（LAN）を試してみることにしました。これはVPNと似ており、ローカルで仮想ネットワークインターフェースを作成し、すべてのマシンを1つの仮想ネットワークに参加させます。\nZerotierとは ZeroTierは、ソフトウェア定義の広域ネットワーク（SD-WAN）ソリューションであり、異なる地理的な場所にあるデバイス間で安全な仮想ネットワークを作成することを可能にします。 ZeroTierを使用すると、複数のコンピューター、サーバー、およびデバイスを、あたかも同じローカルネットワーク上にいるかのように、一元的に暗号化された仮想ネットワークに接続できます。これにより、開発者やIT専門家は、複雑なネットワーク設定やVPN構成なしで、異なる場所間で安全にデータを共有し、リソースを共有することができます。\nZeroTierネットワーク: ZeroTierネットワークは、異なるデバイスがインターネット経由で互いに接続されることを可能にする、仮想的かつグローバルなローカルエリアネットワーク（LAN）です。このネットワークには複数のサブネットを含めることができ、すべてのデバイスはZeroTierの技術を使用して相互に接続されます。\n惑星サーバー: 惑星サーバーは、ZeroTierネットワークの中核コンポーネントであり、その一元的なトポロジー構造、ルーティング情報、およびネットワーク状態を維持・管理します。惑星サーバーはグローバルなネットワーク制御センターとして機能しますが、直接データを転送しません。ユーザーのデバイスは、少なくとも1つの惑星サーバーに接続してZeroTierネットワークに参加する必要があります。\n中継サーバー: 中継サーバーは、ZeroTierネットワーク内の補助的なノードであり、デバイス間の直接通信チャネルを確立するのを支援します。デバイスが直接接続できない場合、データ転送のために中継サーバーを経由することができます。これにより、ネットワークの到達性とパフォーマンスが向上します。中継サーバーは通常、世界中に配置され、データの転送ハブとして機能します。\n全体として、ZeroTierは惑星サーバーと中継サーバーの支援により、デバイスがグローバル範囲で仮想LANを作成し、安全かつ高速なデバイス間の通信を実現します。惑星サーバーはグローバルネットワーク管理を担当し、中継サーバーは必要に応じてデバイス間の接続を確立するのに役立ちます。\nインストールと展開 https://www.zerotier.com/ の公式ウェブサイトにアクセスし、インストールファイルおよびドキュメントを入手してください。 お使いのオペレーティングシステムに応じて、ZeroTier One クライアントをダウンロードしてインストールします。Windows、macOS、Linux など、多くのプラットフォームに対応しています。 インストールが完了したら、ZeroTier One クライアントを起動します。 まだアカウントをお持ちでない場合は、ZeroTier アカウントを作成します。クライアント内でアカウントを作成できます。 ZeroTier アカウントにログインし、新しいネットワークを作成します。ネットワークには一意の16桁IDが割り当てられ、これを覚えておく必要があります。 デバイスをこのネットワークに参加させます。クライアントでネットワークIDを入力するか、QRコードスキャン機能を使用します。 ZeroTier クライアントのインストールおよび設定されたデバイスは、同じ仮想ネットワークに追加されます。これらのデバイス間では、現在、ローカルネットワークにあるかのように直接通信できるようになります。 ZeroTier のコントロールパネルで、ネットワーク設定を管理したり、デバイスを追加したり、ネットワークトラフィックを監視したりできます。 moon のインストールとデプロイ 国内の多くのキャリアが UDP トンネリングを禁止しているため、frp サービスは安定しており、TCP プロトコルを使用するため、Zerotier の中継サーバーも同様の効果を実現できます。ファイアウォールで UDP 9993 を開通する必要があります。\ncurl -s https://install.zerotier.com/ | sudo bash インストールが成功したか確認する\nzerotier-cli info ローカルネットワークへの参加\nzerotier-cli join network-id moon の作成\ncd /var/lib/zerotier-one \u0026amp;\u0026amp; sudo zerotier-idtool initmoon identity.public \u0026gt; moon.json stableEndpoints ノードを調整するために構成ファイルを開き、\u0026ldquo;サーバーのパブリック IP アドレス/9993\u0026rdquo; を設定します。署名構成を生成し、moons.d フォルダを作成し、既存のファイルをこのフォルダに移動してサービスを再起動します。\nsudo zerotier-idtool genmoon moon.json mkdir moons.d \u0026amp;\u0026amp; mv 000000eb444ec0d8.moon moons.d/ systemctl restart zerotier-one.service クライアントノードが moon サーバーに参加し、ID は前の JSON 設定ファイル内の ID フィールドから取得します。\nzerotier-cli.bat orbit ztaddr ztaddr 確認: 新しい moon ノードが作成され、ID と情報はサーバー構成と同じであることを確認してください。\n# 新規 moon 节点の出現を確認し、ID と情報がサーバー設定と一致することを確認します [root@idv-36f9d5 ~]# zerotier-cli listpeers 200 listpeers \u0026lt;ztaddr\u0026gt; \u0026lt;path\u0026gt; \u0026lt;latency\u0026gt; \u0026lt;version\u0026gt; \u0026lt;role\u0026gt; 200 listpeers 0cccb***** 35.236.*.*/64393;110;10726 327 1.6.3 LEAF 200 listpeers 3a46f***** 185.180.*.*/9993;110;757 -1 - PLANET 200 listpeers 3ed7c***** 39.97.*.*/9993;172;79 32 1.6.3 MOON 200 listpeers 4f838***** - -1 - LEAF 200 listpeers 62f86***** 50.7.*.*/9993;110;4796 351 - PLANET 200 listpeers 778cd***** 103.195.*.*/9993;5148;4887 253 - PLANET 200 listpeers 992fc***** 195.181.*.*/9993;10161;4921 226 - PLANET 200 listpeers 9d2b5***** - -1 - LEAF Windows プラットフォームでは、管理者権限でターミナルを起動し、zerotier-cli.bat コマンドラインを使用して操作します。Linux プラットフォームでは、zerotier-cli コマンドラインを使用して操作します。 listpeers サブコマンドは正常に moon 节点を表示するため、参加が成功したことを示しています。 卸载方法 Windowsプラットフォームの卸載方法は後述します。通常の操作手順に従い、コントロールパネルからアンインストールしてください。ここではUbuntuについて詳しく説明します。\ndpkgコマンドでzerotier-oneサービスを削除する sudo dpkg -P zerotier-one zerotier-oneフォルダを削除する。このフォルダにはaddressアドレスが保存されており、削除後に再インストールを行うと新しいaddressアドレスを取得します。 sudo rm -rf /var/lib/zerotier-one/ 跋談 元々は既にアンインストールされていたものが、サーバーが到着し、適切なプロキシノードが存在しないため、阿里云が営業活動を行い、開発用特供サーバーを提供しました。構成は高くなく、1999年、価格も手頃で、2年間運用しました。主な理由はサーバーから提供される帯域幅でした。\n参考文献 https://www.wnark.com/archives/152.html https://www.cnblogs.com/Yogile/p/12642423.html ","date":"2023-09-19","language":"ja","permalink":"https://ttf248.life/ja/p/zero-tier-remote-lan/","tags":["ZeroTier","イントラネット貫通"],"title":"ゼロティア・ローカルエリアネットワーク","year":"2023"},{"categories":["コンピューター"],"content":"VMWareの仮想マシンをインストールして開発を行う際、通常はディスク容量を多めに確保します。使用していくうちに、ホスト側の使用ディスク容量が仮想マシンの実際のファイルサイズを大幅に上回ることがあります。\nシナリオの説明 df -hコマンドを実行し、現在のマシンのディスク情報を確認したところ、実際に使用されているのは60GBであり、すべてのシャットアウトとクローンイメージを削除しても、ローカル仮想マシンが占有するディスクスペースは依然として60GBよりも大幅に大きい。これにより、すでに限られたハードドライブの状態が悪化している。\n前提条件 仮想マシンのインストール時に、ディスクの事前割り当てをチェックしなかった ローカルに保存された仮想マシンのハードドライブが、現在使用されている容量より十分な空き容量を持っていること 空き容量が不足している場合は、一時的に仮想マシンをポータブルHDDに移動してディスクを最適化した後、再度移行することを検討してください。 ツール 公式から open-vm-tools パッケージが提供されており、yum でインストールするか、vmware-tools イメージパッケージでインストールできます。\n命令 vmware-toolbox-cmd disk shrink / これを実行すると、仮想マシンは自動的にシャットダウンされ、VMware ホストプログラムがディスクの縮小を実行します。 実行時間は仮想マシンのサイズとディスクへのアクセス速度によって異なります。 実行効果は非常に良く、仮想マシンのディスク使用量が df -h のディスク情報とほぼ一致します。\n","date":"2023-06-21","language":"ja","permalink":"https://ttf248.life/ja/p/vmware-virtual-machine-disk-space-optimization/","tags":["vmware"],"title":"VMware 仮想マシンのディスクスペース最適化","year":"2023"},{"categories":["コンピューター"],"content":"国内の資料は、基本的には秋葉さんのワンクリックデプロイパッケージを推奨されています。すべてPythonベースのオープンソースプロジェクトなので、デプロイもそれほど複雑ではないだろうと考え、ゼロから試してみることにしました。\nAI生成画像に苦労したので、意図的にグラフィックカードを変更しました。入門版の3060 12gです。7年勤めた960が栄光のうちに退役しました。\nコアの pytorch cuda のインストールですが、以前 python ゲーム補助スクリプトを書いた際にローカルにインストールしたことがありましたが、やはり問題が発生しました。cuda の暗号化が常に有効にならないという問題です。\n待処理 文章構造を再計画し、まず PyTorch を紹介する。バージョン対応関係とバージョン確認方法 ローカル環境から PyTorch をゼロから新規に作成・デプロイする方法 Stable Diffusion の翻訳稿を作成する（https://stable-diffusion-art.com/install-windows/ から開始） 参照資料の整理 ステップ 中国語で検索すると、手順を追ったインストール方法が見つかりにくい可能性があります。Google で英語で検索すると、同様のチュートリアルがたくさんあります。ゼロから始めるものばかりです。いくつか説明した後、git のインストールが必要であること、そして python のインストールについても言及します。その後は、リポジトリをダウンロードし、直接スクリプトをダブルクリックして完了となります。 https://github.com/AUTOMATIC1111/stable-diffusion-webui 詳細な使用方法や疑問点については、issues を参照してください。https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki なぜ誰もこのリポジトリが何をするものなのか説明していないのかわかりません。名前からして、それはインターフェース制御台であり、より簡単に使用できるように設計されていることがわかります。インストール時には、現在のフォルダに Python 仮想環境があるかどうかを自動的に認識し、存在する場合は現在のパスの python を使用します。 初心者の方には、https://stable-diffusion-art.com/install-windows/ を参照することをお勧めします。\nPyTorch https://pytorch.org/get-started/locally/\n今日は私が話したいのは、まず彼らの手順をそのまま実行しないでください。Pythonはrequirementファイルを使って依存ライブラリをインストールします。これは小さな問題です。重要なのはあなたのGPUのバージョンとドライバーのバージョンがPyTorchに対応していることです。これは多くの人が対応関係を紹介しているので、ネットで調べてみればわかります。 参考：https://blog.csdn.net/weixin_40660408/article/details/129896700\n仮想環境を作成するのは、空の仮想環境を作り、その中でまず公式サイトのスクリプトを実行してPyTorchをインストールすることです。\npython -c \u0026#34;import torch; print(torch.version.cuda)\u0026#34; python -c \u0026#34;import torch; print(torch.__version__, torch.cuda.is_available())\u0026#34; 上記の2つのスクリプトで、必要なCUDAバージョンを確認したり、インストールが成功したかどうかを確認したりできます。\nここでは、派手な操作をするのではなく、まず公式サイトのロジックをそのままコピーしてインストールすることをお勧めします。直接pipを使ってインストールすると、PyTorchが失敗する可能性や、CUDAがアクティブにならない可能性があります。\npip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 ポイントは、フォルダのパスに不要なものが含まれていないことです。そうでないと、PyTorchを使用できなくなる可能性があります。\n何度もインストールを試みたり、公式のインストールファイルをダウンロードして手動でインストールしたりしました。2.0バージョンをアップグレードしたいと考えていましたが、公式ドキュメントでは2.0がより高速であると記載されています。しかし、以前はあまり使用していなかったので、Pythonのバージョンやそれが影響するかどうか分からずでした。また、公式マニュアルには3.8バージョンの推奨があることが書かれていました。これにより小さな競合が発生しました。以前、ワンクリックインストールパッケージを使用しており、その中に3.10バージョンが含まれていました。最終的には、空のフォルダを作成し、仮想環境を作成して、PyTorchが正しくインストールされていることを確認してから、インストールを開始しました。\nその後、インストールされた仮想環境をWeb UIのフォルダに移動しました。この状態でスクリプトを実行して、他の依存関係の問題は解決されました。\n移動後、次のコマンドを実行する必要があります：python -m pip install --upgrade --force-reinstall pip pipを修復します。\nおそらく、これは非常に奇妙に見えるかもしれませんが、この場所でかなり時間を費やしました。なぜなら、常にPyTorchを正しく認識できなかったからです。すべての干渉要因を除外するために、まずそれをインストールし、次に他の依存ライブラリをインストールすることを思いつきました。\nXformers 有効化することを推奨します。画像生成を高速化し、既存の占有量を削減できますが、副作用として、同じパラメータセットで生成される画像は比較的安定しません。\nstable-diffusion-webui:Xformers huggingface optimization | 100.00% | 2分57秒33 | 7440MiB / 10058MiB | 12288MiB / 12288MiB (100.0%) |\nXformers 最適化比率 時間 Torch 活性/予約メモリ システムVRAM 51.02% 1分29秒21 4547/7164 MiB 9298/12288 MiB (75.67%) Xformers ((masterpiece)),((best quality)),((high detail)),((realistic,)) 産業時代の都市、中央に深い峡谷、中国式の街並み、バザール、橋、（雨の日:1.2）、（スチームパンク:0.8）、中国建築 ネガティブプロンプト：nsfw,((カウボーイ)),(((陰毛))), ((((陰毛の髪の毛))))スケッチ、重複、醜い、大きな目、テキスト、ロゴ、モノクロ、最悪の顔、（悪いおよび変異した手:1.3）、(最悪の品質:2.0)、(低品質:2.0)、(ぼやけ:2.0)、ホラー、ジオメトリ、bad_prompt、（悪い手）、(指が足りない)、複数の四肢、悪い解剖学、（交差した指:1.2）、醜い指、（追加の指と手と足と腕:1.4）、冠髪飾り、（2girl）、(変形した指:1.2)、(長い指:1.2)、サキュバスの翼、角、サキュバスの角、サキュバスのヘアスタイル、（悪いアーティストアニメ）、悪いアーティスト、悪い手、借りたキャラクター、テキスト重視、ウォーターマーク、サンプルウォーターマーク、キャラクターウォーターマーク、Lofterユーザー名、写真の日付ウォーターマーク、映画ポスター、雑誌表紙、ジャーナル、表紙、表紙ページ、道行表、アルバム表紙、漫画表紙、ブランド名の模倣、EasyNegative、タイツ、シルクストッキング、ショート ステップ数：35、サンプラー：DPM adaptive、CFGスケール：5.5、シード：2223996555、サイズ：1088x1088、モデルハッシュ：543bcbc212、モデル：base_Anything-V3.0-pruned、Clipスキップ：2、ENSD：31337 終わりに なぜデプロイメントパッケージを推奨しなかったのかというと、そのパッケージには作者が個人的にカスタマイズした設定が含まれており、公式のオリジナルのものとは異なっているためです。もしあなたが初心者であれば、なぜそれらのパラメータが最適なのか分からないかもしれません。しかし、使用していくうちに公式のマニュアルを参照することで、どのパラメータを調整する必要があるかを知ることができます。\nグラフィックボードの選択 データマネーマイニングの後、グラフィックボードの価格は比較的高くありません。一般的なエントリーレベルのプレイヤーが、3060と3060Tiの間で選択する場合、一般的には大容量12G版の3060が推奨されます。なぜなら、より高い解像度の画像を生成できるからです。なぜ高い解像度が必要なのでしょうか？それは、生成時に解像度を上げることによって、生成される画像がより鮮明で詳細になるためです。もしあなたが小さな画像を生成したいのであれば、8GのVRAMでも十分です。\nさらに、高解像度アップスケーリングオプションがあり、ディテールを強調し、画面の詳細さを豊かにすることも、より多くのVRAMが必要です。\n以下はNVIDIA GeForce GTX 970、GeForce RTX 3060 Ti、GeForce RTX 3060、GeForce RTX 3080およびGeForce RTX 3080 Tiの単精度（FP32）、半精度（FP16）および双精度（FP64）浮動小数点演算能力の仕様一覧表：\n| GeForce GTX 970 | 2014 | 3.49 | 87.2 | 0.109 |\nグラフィックボードの選択 グラフィックボードモデル リリース年 単精度浮動小数点演算能力 (TFLOPS) 半精度浮動小数点演算能力 (TFLOPS) 双精度浮動小数点演算能力 (TFLOPS) GeForce RTX 3060 Ti 2020 16.2 32.4 0.51 グラフィックボードの選択 グラフィックボードモデル リリース年 単精度浮動小数点演算能力 (TFLOPS) 半精度浮動小数点演算能力 (TFLOPS) 双精度浮動小数点演算能力 (TFLOPS) GeForce RTX 3060 2021 12.7 25.4 0.39 グラフィックボードの選択 グラフィックボードモデル リリース年 単精度浮動小数点演算能力 (TFLOPS) 半精度浮動小数点演算能力 (TFLOPS) 双精度浮動小数点演算能力 (TFLOPS) GeForce RTX 3080 2020 29.8 58.9 0.93 グラフィックボードの選択 グラフィックボードモデル リリース年 単精度浮動小数点演算能力 (TFLOPS) 半精度浮動小数点演算能力 (TFLOPS) 双精度浮動小数点演算能力 (TFLOPS) GeForce RTX 3080 Ti 2021 34.8 68.7 1.36 显卡的選択 各種グラフィックカード性能テストデータ\n更新 半年ごとに、改めてインストール手順を整理したり、基礎概念を解説したりする予定でしたが、一般的にAIイラストを生成する場合、結局はベテランユーザーが提供した画像パラメータを調整したり、既存の画像をフォーマットして再レンダリングしたりすることになるという事実に気づきました。\n以前、AIを使ってミニプログラムのUI素材を描画するというプロジェクトがありましたが、半日かけても期待通りの結果が得られず、結局公式のミニプログラムから画像素材を直接ダウンロードする方が良いという結論に至りました。\n","date":"2023-04-13","language":"ja","permalink":"https://ttf248.life/ja/p/stable-diffusion-zero-install-story/","tags":["stable-diffusion","pytorch","python"],"title":"Stable-diffusion - そのインストールから始まる喜びと苦悩 (安定拡散 - そのインストールから始まる喜びと苦悩)","year":"2023"},{"categories":["コンピューター"],"content":"one loop thread（単一ループスレッド）の実行時間がすでにマイクロ秒レベルで、サーバーを交換した結果、最大6万パケットまでバックログが積み重なるのをほぼゼロにすることができた。\nシングルスレッドでのループ処理でデータを扱う場合、CPUの性能はクロック周波数、キャッシュサイズ、命令セットアーキテクチャなどの要因によって決まる。一般的に、クロック周波数が高く、キャッシュサイズが大きい、そして命令セットアーキテクチャが高度なCPUほど、シングルスレッドでデータを処理する際の性能が良い。\nシングルスレッド パフォーマンス向上のために、スレッドを追加することは必ずしも必要ではありません。プロジェクトのプロセスを整理し、時間がかかる箇所を特定し、シングルスレッドで要件を満たせるか検討します。シングルスレッドでは考慮すべき点が少なく、問題が発生する可能性も低くなります。\n最初からスレッドについて言及するのは、多少不適切です\nイベント 処理しているデータは市場データであり、遅延に敏感です。 一晩中ひたすら加班し、新しい最適化版をリリースし、ローカルでインターフェースを剥離してテストを行い、速度はそれなりに良かった（tps：4.2万）。 サーバーにデプロイしたところ、tpsが急降下し、2.1万になった。台式机に戻って試すと、tpsは7.9万だった。グループ内のサービス仮想マシンの問題があるのではないかと疑い始め、まずCPUのクロック周波数（主頻度）の違いを疑った。家庭用PCとサーバーのCPUでは、クロック周波数が最も異なる点だった。\nテストサーバーA\nprocessor\t: 7 vendor_id\t: GenuineIntel cpu family\t: 6 model\t: 47 model name\t: Intel(R) Xeon(R) CPU E7- 4807 @ 1.87GHz stepping\t: 2 microcode\t: 0x34 cpu MHz\t: 1866.733 cache size\t: 18432 KB physical id\t: 1 siblings\t: 4 core id\t: 3 cpu cores\t: 4 apicid\t: 7 initial apicid\t: 7 fpu\t: yes fpu_exception\t: yes cpuid level\t: 11 wp\t: yes flags\t: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm pti dtherm arat bugs\t: clflush_monitor cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips\t: 3733.46 clflush size\t: 64 cache_alignment\t: 64 address sizes\t: 40 bits physical, 48 bits virtual power management: テストサーバーB\nprocessor\t: 7 vendor_id\t: GenuineIntel cpu family\t: 6 model\t: 63 model name\t: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz stepping\t: 2 microcode\t: 0x3c cpu MHz\t: 2599.998 cache size\t: 20480 KB physical id\t: 14 siblings\t: 1 core id\t: 0 cpu cores\t: 1 apicid\t: 14 initial apicid\t: 14 fpu\t: yes fpu_exception\t: yes cpuid level\t: 15 wp\t: yes flags\t: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cpuid_fault epb pti fsgsbase smep xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts bugs\t: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips\t: 5199.99 clflush size\t: 64 cache_alignment\t: 64 address sizes\t: 40 bits physical, 48 bits virtual power management: OpenAIへの相談 まず、コア数とクロック周波数に関しては、Intel(R) Xeon(R) CPU E7-4807 @ 1.87GHzは6つの物理コアと12個の論理コアを持ち、クロック周波数は1.87GHzです。一方、Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHzは8つの物理コアと16個の論理コアを持ち、クロック周波数は2.60GHzです。したがって、コア数とクロック周波数という点では、E5-2640 v3がE7-4807よりもシングルスレッドでのデータ処理において有利であると考えられます。 次に、キャッシュサイズに関しては、E7-4807のキャッシュサイズは12MBであり、E5-2640 v3のキャッシュサイズは20MBです。したがって、E5-2640 v3はより大きなキャッシュスペースを持ち、データのアクセス速度とキャッシュヒット率を向上させることができます。 最後に、アーキテクチャに関しては、E5-2640 v3はより高度なHaswellアーキテクチャを採用しており、E7-4807は旧いNehalemアーキテクチャを採用しています。HaswellアーキテクチャはNehalemアーキテクチャと比較して性能が向上しているため、これもE5-2640 v3のシングルスレッドでのデータ処理時の性能向上に影響を与える可能性があります。 したがって、総合的に考えると、シングルスレッドでループ処理を行うシナリオでは、E5-2640 v3はE7-4807よりも優れたパフォーマンスを発揮すると考えられます。ただし、具体的なパフォーマンスの違いは、データ処理のアルゴリズム、メモリ帯域幅、システム負荷など、さまざまな要因によって影響を受けるため、個別の問題に対して具体的に分析する必要があります。\nハードウェア情報 https://www.cpubenchmark.net/compare/3786.2vs2365.2/%5BDual-CPU%5D-Intel-Xeon-E7–4807-vs-%5BDual-CPU%5D-Intel-Xeon-E5-2640-v3 | 価格 | オンライン検索 $78 - 購入 | |\nハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Xeon E7-4807 (LGA1567) Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Xeon E7-4807 (LGA1567) Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Xeon E7-4807 (LGA1567) Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア情報 仕様 Xeon E7-4807 (LGA1567) Xeon E5-2640 v3 (LGA2011-v3) 初登場 Q3 2020 Q3 2014 ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) サンプル数 1 46 ハードウェア仕様 仕様 Intel Xeon E7-4807 (LGA1567) Intel Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Xeon E7-4807 (LGA1567) Xeon E5-2640 v3 (LGA2011-v3) ハードウェア仕様 仕様 Xeon E7-4807 (LGA1567) Xeon E5-2640 v3 (LGA2011-v3) ","date":"2023-04-07","language":"ja","permalink":"https://ttf248.life/ja/p/program-optimization-dont-fight-hardware/","tags":[],"title":"プログラムの最適化は、ハードウェアと戦おうとするべきではありません。","year":"2023"},{"categories":["コンピューター"],"content":"例として、かつて検索エンジンのテクニックを学んだように、私たちはまた、AIとコミュニケーションするためのテクニックも習得する必要がある。合理的な制約条件を与え、効率的に必要な答えを得る方法を学ぶのだ。\nもし角度を変えて考えると、現在のAIは記憶力に優れた小さな子供であり、完璧に暗記し、宿題をコピーできる能力を持っている。私たちがやるべきことは、AIと正確かつ効果的にコミュニケーションする方法を学び、要求を正確に記述することで、AIが期待される結果を生み出すのを助けることだ。\n科学普及 話題となっているAI（人工知能）を具体的に言うとGenerative Pre-Training（生成事前学習）です。これはインターネット上で利用可能なデータを用いてテキスト生成を行う深層学習モデルであり、質問応答、テキスト要約生成、機械翻訳、分類、コード生成、対話型AIなど様々なタスクに用いられます。現在、GPT-1、GPT-2、GPT-3、GPT-4といった異なるバージョンのモデルが存在し、それぞれが前バージョンよりも規模が大きく、性能も向上しています。\n到底有没有智能 類似度が高ければ高いほど、精度も高くなる 基本的な、反復性の仕事は、特定の訓練を受けることで、人工の介入が不要になる 生成式AIとは、既存のテキスト、音声、画像などのデータを活用して新しいコンテンツを作成する技術である。テキスト生成、音声合成、画像生成、対話システムなど、様々なタスクに使用できる。生成式AIの論理性は、その学習データとモデル構造に依存する。一般的に、生成式AIは一定程度、文法、論理、常識に従うことができるが、誤りや偏見、または不真実を含むコンテンツを生成することもある。そのため、生成式AIの出力は人間の判断と検証が必要であり、盲目的に信頼したり使用したりすることはできない。 プロンプトエンジニア 時間は流れの法則を変えない。人は潮流に適応することを学ぶ必要がある。AIを無智能で論理性に欠けるものと捉えがちだが、よく書けば使えないコードを生成することも少なくない。\nもし別の角度から考えると、現在のAIは記憶力に優れた幼い子供であり、丸暗記する能力を持っている。つまり、問題をコピーする能力があるのだ。私たちがやるべきことは、AIに対して適切で効果的かつ正確なコミュニケーションを学び、要求を明確に記述し、AIが期待される結果を生み出すのを支援することだ。\n対話モデル 2年前、GitHub Copilotの発表は誰も予想していませんでした。その結果、OpenAIが横空に出現し、人類は大規模言語モデルの能力を認識するに至りました。\nコメントベースのプログラミングと対話ベースのプログラミングに基づき、インタラクティブなロジックは完全に異なり、対話のパターンは初心者ユーザーにとって親しみやすく、NewBingが各質問の後に提示するフォローアップのヒントは必須です。Microsoftは、AI知識ベースにあるより多くのコンテンツを取得するために、ユーザーを誘導しようとしています。\nデータの前処理 深層学習 ニューラルネットワーク 栗子 # 必要なライブラリをインポート import argparse import logging import multiprocessing import os from PIL import Image # 画像をグレースケールに変換し、透明背景を維持して画像を保存し、ファイルサイズを返す関数を定義します。 def convert_and_save(image_file): # 画像を開く try: image = Image.open(image_file) except Exception as e: logging.error(f\u0026#34;画像 {image_file} のオープンに失敗しました：{e}\u0026#34;) return None, None # 画像のモードを取得します。RGBA モードの場合、透明背景があります。 mode = image.mode if mode == \u0026#34;RGBA\u0026#34;: # 画像と同じサイズの白い背景画像を生成します。 background = Image.new(\u0026#34;RGB\u0026#34;, image.size, (255, 255, 255)) # 元の画像に背景を貼り付け、透明ピクセルを無視します。 background.paste(image, mask=image.split()[3]) # 合成された画像をグレースケールモードに変換します。 gray_image = background.convert(\u0026#34;L\u0026#34;) # グレースケール画像をRGBAモードに戻して透明背景を維持します。 final_image = gray_image.convert(\u0026#34;RGBA\u0026#34;) else: # RGBA モードでない場合は、画像が直接グレースケールモードに変換されます。 final_image = image.convert(\u0026#34;L\u0026#34;) # 元の画像のファイル名と拡張子を取得します。 file_name, file_ext = os.path.splitext(image_file) # 新しい画像のファイル名を定義し、_bw サフィックスを追加して黒白であることを示します。 new_file_name = file_name + \u0026#34;_bw\u0026#34; + file_ext # 新しい画像を保存し、品質を最適化してファイルサイズを削減します。 try: final_image.save(new_file_name, optimize=True) except Exception as e: logging.error(f\u0026#34;{new_file_name} の保存に失敗しました：{e}\u0026#34;) return None, None # 元の画像と新しい画像のファイルサイズを取得し、返します。 old_size = os.path.getsize(image_file) new_size = os.path.getsize(new_file_name) return file_name, old_size, new_size # コマンドライン引数を解析し、フォルダパスと拡張名リストを返す関数を定義します。 def parse_args(): # 解析器オブジェクトを作成します。 parser = argparse.ArgumentParser(description=\u0026#34;画像を黒白に変換し、品質を最適化します。\u0026#34;) # 位置パラメータを追加してフォルダパスを指定します。 parser.add_argument(\u0026#34;folder_path\u0026#34;, help=\u0026#34;画像が含まれるフォルダーのパスです。\u0026#34;) # オプションパラメータを追加して拡張名リストを指定します。デフォルトは png, jpg, jpeg, gif です。 parser.add_argument(\u0026#34;-e\u0026#34;, \u0026#34;--extensions\u0026#34;, nargs=\u0026#34;+\u0026#34;, default=[\u0026#34;.png\u0026#34;, \u0026#34;.jpg\u0026#34;, \u0026#34;.jpeg\u0026#34;, \u0026#34;.gif\u0026#34;], help=\u0026#34;画像ファイルの拡張子です。\u0026#34;) # コマンドライン引数を解析し、結果オブジェクトを返します。 args = parser.parse_args() return args.folder_path, args.extensions # 変換前後のファイルサイズの違いを出力する関数を定義します。 def print_result(result): # 結果が空でない場合、変換と保存が成功したことを示します。 if result: # 結果をファイル名とファイルサイズのタプルに分解します。 if len(result) == 3: file, old_size, new_size = result # コントロールパネルで変換前後のファイルサイズの違いを出力します。 logging.info(f\u0026#34;{file}: {old_size} バイト -\u0026gt; {new_size} バイト\u0026#34;) else: # 結果を出力します。 logging.info(f\u0026#34;{result}\u0026#34;) # 日志記録器を設定し、ログをコンソールとファイルに出力し、ログレベルを INFO に設定します。 logging.basicConfig(level=logging.INFO, format=\u0026#34;%(asctime)s %(levelname)s %(message)s\u0026#34;, handlers=[logging.StreamHandler(), logging.FileHandler(\u0026#34;log.txt\u0026#34;)]) # # 別のプロセスに、パイプを介して渡されたコードを実行するように通知されます。これは、`--multiprocessing-fork` コマンドライン引数を渡すことで行われます。 # `freeze_support()` 関数の実装を見ると、それが実行されているプロセスの確認と、パイプを介して渡されたコードの実行が必要かどうかを確認するタスクを実行します。 # `multiprocessing.freeze_support()` # コア数に基づいてコンピューターに自動的にプロセスを割り当てるプロセスプールを作成します。 # プロセスプール = multiprocessing.Pool() # 异步タスクの結果オブジェクトを格納するための空のリストを作成します。 # results = [] # フォルダー内のすべてのファイルに対して反復処理を行います。 # for file in os.listdir(folder_path): # # ファイルパスを結合します。 # file_path = os.path.join(folder_path, file) # # 拡張子リストに基づいて画像ファイルを判断します。必要に応じて拡張子リストを変更できます。 # if any(file_path.endswith(ext) for ext in extensions): # # 関数を呼び出して、画像を変換して保存し、ファイルサイズを取得します。パイプを介したコードの実行は、メインプロセスをブロックすることなく、非同期で行われます。 # result = pool.apply_async(convert_and_save, args=(file_path,), callback=print_result) # # 結果オブジェクトをリストに追加します。 # results.append((file, result)) # プロセスプールを閉じ、新しいタスクの受け入れをやめます。 # pool.close() # すべてのタスクが完了するまで待ちます。 # pool.join() ## 終わりに ローカル開発が `windows` システムであるため、AI が最初に提示した回答には `main` 関数も `multiprocessing.freeze_support` も含まれておらず、エラーが発生しました。質問を重ねることでエラーの原因を特定し、コードを修正しました。 かつて検索エンジンの技術を学ぶように、AI とコミュニケーションする上でも、適切な制約条件を与え、効率的に必要な回答を得るためのスキルを習得する必要があります。 注意：**もしあなたがプログラミング初心者であれば、提示されたコメントと合わせて理解できない点がある場合は、引き続き関連コードについて質問してください。** ","date":"2023-03-26","language":"ja","permalink":"https://ttf248.life/ja/p/prompt-engineer/","tags":["chatgtp","ai"],"title":"プロンプトエンジニア","year":"2023"},{"categories":["コンピューター"],"content":"WeChat Mini Program Introduction and Development Preparation\nなぜミニプログラムが存在するのか より良い体験：埋め込みウェブの読み込みが遅延し、白画面になる問題を解決。ネイティブアプリの方がより高速にロードできる。 規範と管理：微信にとって、アクセスと管理を行うため。 小程序のリリース前に、微信はSDKであるJSSDKを公開しており、微信支付や券などの微信のネイティブ機能を一部開放していた。しかし、開発者はウェブ開発言語でロジックを構築し、微信の規制を回避することができた。小程序には独自の記述言語が搭載されている。 小プログラムとは 小プログラムは、ダウンロードやインストールが不要で利用できるアプリケーションです。アプリを手の届くところに持つという夢を実現します。\nユーザーはスキャンするか検索することでアプリを開き、使い終わったらすぐに終了するというコンセプト（「使ったら片付ける」の理念）も体現しています。\nユーザーは、多くのアプリをインストールすることなく、いつでもどこでも利用できるというメリットがあります。また、インストールやアンインストールなどの手間がかかりません。\nミニアプリとモバイルアプリケーションの違い インストール不要、メモリを消費しない、拡散が容易：スキャンコード、ミニアプリカード、そーいちょうすう\n小程序が何ができるか コンテンツツール：知乎熱榜、微博热门、摩拜单车、今日头条、腾讯地图、腾讯翻訳 小売：拼多多、京东购物、蘑菇街、每日优鲜、小米商城、屈臣氏 ゲーム：跳一跳、欢乐斗地主、欢乐麻将、斗鱼直播、YY直播 2018年のコース内容。現在までに一部のアプリベンダーが倒産しているものもあります。\n開発準備 小プログラムアカウントの登録：通常通り情報を入力して登録し、メールに記載された有効化リンクをクリックします。 情報登録 小プログラム管理後台へのログイン 小プログラム情報の充実 開発者との連携：個人開発者は、ログインに使用するWeChatのIDを管理者アカウントとして使用し、追加の設定は不要です。 メールには制限があり、新しいメールアドレスが必要です。しかし、QQメールで別名を登録でき、WeChat後台での検証はありません。試行錯誤の結果、小プログラムの名前は複雑になりやすく、商標に関わる場合は審査に通りにくい可能性があります。 サービスカテゴリーを選択することも、必要に応じて追加することもできます。1つの小プログラムには最大5つのカテゴリーを追加できます。 設定画面では、小プログラムのIDを確認でき、メッセージプッシュも有効化できます。メッセージプッシュを有効化すると、メッセージテンプレート機能を使用できます。 開発者ツール（筆者談） 正常にダウンロードおよびインストールでき、特別な注意点はなく、概要を把握するだけで、すぐにゲストモードでアクセスします。モバイルデバッグを有効にするには、つまり小程序的開発バージョンを確認するには、小程序的開発者にログインし、設定をクリックしてプロジェクトの詳細から指定された小程序的IDに切り替える必要があります。\nコード構造 js: 相互作用ロジック json: データ設定 wxml: 界面の要素 wxss: 界面のスタイル ","date":"2023-03-24","language":"ja","permalink":"https://ttf248.life/ja/p/wechat-mini-program-background-and-development-environment/","tags":["WeChat Mini Programs"],"title":"微信ミニプログラムの背景と開発環境","year":"2023"},{"categories":["コンピューター"],"content":"行政通知、オフィス配置の変更（元の2階から15階への移動）、通常の事務室の移転\nデザインセンス 移住 荷造り、スムーズな進路、新しい作業場所でのPCの配線整理、心地よい姿勢で仕事を開始 (ÒωÓױ)！、ネットワークケーブルを接続し、チームメンバーがよく使うサーバーにアクセスできなくなりました。無線LANに切り替えてみましたが、正常に戻りました。 当初はサーバーのIPアドレス設定の問題だと思っていました。新しい作業場所の有線LANは、ファイアウォール設定のリストに含まれていませんでした。IT担当者に連絡して調整したら解決しました。このIPアドレス範囲は、他のサーバーにも使用されており、他のサーバーにアクセスしても正常でした。徐々に疑問が生じ始めました。専門的なことは専門家に任せるべきです。最終的に運用部門の同僚が特定し、このサーバーにdockerがデプロイされているため、サービスのデフォルトネットワークdocker0とオフィスLANの設定IPアドレス範囲が競合してしまい、送信したデータパケットを受信できなくなり、ルーティングされてdockerサービスに渡りました。 他のサーバーにはdockerサービスがデプロイされていないため、このサーバーだけでした。私がよく使うので、時々コンテナを使用してテストサービスをデプロイすることがありましたが、このような状況に遭遇したとは思いませんでした。後から考えると、グループ全体が同じオフィスビル内に存在しているため、IT部門の同僚がIPアドレス範囲を割り当てたことは珍しくありません。\ndocker0 # vim /etc/docker/daemon.json { \u0026#34;bip\u0026#34;:\u0026#34;172.200.0.1/24\u0026#34; } サービスを再起動し、新しいネットワークに切り替えると、サーバーが正常にアクセスできるようになりました。\n参考文献 Docker入門から実践 - docker0\n","date":"2023-03-11","language":"ja","permalink":"https://ttf248.life/ja/p/office-move-server-inaccessible/","tags":["ネットワーク","docker"],"title":"オフィスへの引っ越しにより、サーバーにアクセスできなくなりました。","year":"2023"},{"categories":["コンピューター"],"content":"組み込みシステムについて言及すると、脳裏に浮かぶのは、かつて学校の実験室で使っていた51ジャンク機とファルコムのイメージです。\nLPA3399Proは、瑞芯微RK3399Proプラットフォームをベースに開発されたビジュアルホストであり、大量の視覚演算が必要な携帯型コンピューティングホスト向けに設計されています。NPU（ニューラルプロセッシングユニット）内蔵で、3.0TOPSの演算能力を持ち、多様なアルゴリズムモデルに対応しています。\nRV1109は、瑞芯微におけるAI分野の機械視覚ブランチ向けのSoC（システムオンチップ）であり、独立したNPUを搭載しています。RV1109は、1TOPSの演算能力を提供します。\nSystem on Chip SoC は System on a Chip の略で、「片上システム」を意味します。これは、複数の電子システムを 1 つのチップに統合する技術です。この技術により、電子製品のサイズと重量を大幅に削減すると同時に、性能を向上させ、消費電力を低減することができます。\nSoC（System on a Chip）および CPU（Central Processing Unit）は、コンピュータシステムの重要な構成要素ですが、その間にはいくつかの違いがあります。\nCPU は、コンピュータシステムの中核となるプロセッサであり、プログラムの命令を実行します。通常、演算ユニット、制御ユニット、レジスタなどの基本的な部品のみを含みます。\n一方、SoC は、CPU 以外にもメモリ、グラフィックス プロセッサ、入出力インターフェースなど、他のコンポーネントを 1 つのチップに統合します。これにより、電子製品のサイズと重量を大幅に削減し、性能を向上させ、消費電力を低減することができます。\nまとめると、CPU は SoC の構成要素であり、SoC はより複雑で、集積度の高い電子システムです。\nマイクロコントローラユニット (Microcontroller Unit) SoC（System on a Chip）と MCU（Microcontroller Unit）は、複数の電子システムを1つのチップに統合する技術ですが、両者にはいくつかの違いがあります。\nMCU はマイクロコントローラの一種で、通常、CPU、メモリ、入出力インターフェースなどの基本的な部品が含まれています。これは、家電製品や自動車電子システムなど、他の電子機器を制御するために一般的に使用されます。\n一方、SoC（System on a Chip）は、MCU の基本的な部品に加えて、グラフィックスプロセッサや無線通信モジュールなど、さらに多くの電子システムを1つのチップに統合します。これにより、電子製品のサイズと重量を大幅に削減し、同時に性能を向上させ、消費電力を低減することができます。\nまとめると、MCU はシンプルなマイクロコントローラであり、SoC はより複雑で、統合度が高い電子システムです。\n","date":"2023-03-07","language":"ja","permalink":"https://ttf248.life/ja/p/embedded-entry-professional-terms/","tags":["組み込み (ぐみこみ)"],"title":"組み込みシステム入門編１ - プロフェッショナルな用語集","year":"2023"},{"categories":["コンピューター"],"content":"GitHub Copilot のリリースからわずか 2 年しか経っていないのに、ChatGPT が登場し、裏にある原理をよく理解していない状態で、しばらく使ってみた。2 つのツールのサポートレベルは完全に異なり、どちらも生産性を大幅に向上させた。\nあまりにも複雑なことについては、AI ではまだできないだろう。なぜなら、彼らは論理がなく、パターンや形式固定されたもの、あるいは范式を定めているからだ。学習データは十分で、AI の効果は 9 分満点になる。\nGitHub Copilot リリース時に、公式サイトの紹介の demo を見ると、あまり賢くなく、試用してみましたが、使い勝手が良くありませんでしたので、諦めました。 2022年以前に、暇つぶしで切り替えて新バージョンを体験したところ、かなり良くなっており、ただ国内の速度が少し遅いのは、ネットワークの問題である可能性が高いです。Pythonのような言語では、コメントに基づいて書かれたコードもそれなりによくできており、自分で資料を探して書いていたよりもはるかに速かったです。\nChatGPT Github Copilotは、プログラマー、つまり開発者の視点から製品を設計しており、プログラミングの知識が必要であり、コメントを通じてAIによるコーディング支援を誘導していくものでした。 ChatGPTは次の段階に進み、専門家でなくてもすぐに使いこなせるように設計されています。対話形式でのチャットインターフェースにより、質問や要件の説明、理解できない場合は引き続き質問することができます。\n例えば、品詞分割の概念を知っているものの、コーディング方法がわからない状態で、文字列の類似度を計算したい場合を考えてみましょう。\nPython 品詞分割 維天運通 LOGORY と 合肥維天運通情報科技股份有限公司 2 つの文字列の類似度を計算します。 比較前に、文字列を英語小文字に変換するなどして統一処理を行います。 2 番目の文字列の中に最初の文字列の最初の文字が見つかれば、2 番目の文字列を最初の文字列の長さと同じ長さで切り捨てます。 こんにちは、これはBingです。😊 オンラインの情報123に基づき、Python の品詞分割には jieba などのライブラリを使用できます。jieba ライブラリは、精密モード、全模式、検索エンジンモードの 3 つの分詞モードをサポートしています。要件に応じて適切なモードを選択できます。 文字列の類似度を比較するには、まず文字列を品詞分割し、その後の単語ベクトルまたは編集距離などの指標を計算する必要があります。numpy や scipy などのライブラリを使用して数学演算を行うことができます。 文字列を統一的に処理するために、英語を小文字に変換するには、Python の組み込み関数 lower() を使用できます。 2 番目の文字列を切り出すには、Python のスライス操作符 [ ] を使用できます。\n以下は、その際のコード例です。\nimport jieba import numpy as np from scipy.spatial.distance import cosine # 定義する 2 つの文字列 str1 = \u0026#34;維天運通 LOGORY\u0026#34; str2 = \u0026#34;合肥維天運通情報科技股份有限公司\u0026#34; # 統一処理：英語を小文字に変換 str1 = str1.lower() str2 = str2.lower() # 2 番目の文字列の中に最初の文字列の最初の文字が見つかる位置を探す index = str2.find(str1[0]) # 見つかった場合、2 番目の文字列を切り出す if index != -1: str2 = str2[index:index+len(str1)] # jieba 库を使用して文字列を品詞分割する words1 = list(jieba.cut(str1)) words2 = list(jieba.cut(str2)) # 2 つの文字列の単語ベクトル（頻度を重みとして使用）を計算する vector1 = np.zeros(len(words1)) vector2 = np.zeros(len(words1)) for i, word in enumerate(words1): vector1[i] += 1 # 最初の文字列内の各単語の出現回数をカウント if word in words2: vector2[i] += 1 # 2 番目の文字列内の各単語の出現回数をカウント # 2 つの文字列の類似度（余弦距離を指標として使用）を計算する similarity = 1 - cosine(vector1, vector2) print(\u0026#34;2 つの文字列の類似度は：\u0026#34;, similarity) さらに、結果を確認し、問題点を発見します。結果はランダムで、実際のコードを実行していませんが、良い結果を提供します。\n栗子 質問：SQL文で、製品コードテーブルから、製品コードが80000～89999の範囲にあるレコードを抽出するには？\nこんにちは、Bingです。😊 検索結果12によると、指定された範囲内の値を選択するために、BETWEEN演算子を使用できます。BETWEEN演算子は、開始値と終了値を両方含みます。 まず、クエリするテーブル名と列名を指定し、WHERE句でBETWEEN演算子と範囲値を指定する必要があります。 たとえば、製品コードが80000から89999の範囲にある製品コードテーブルからレコードを抽出するには、次のステートメントを使用できます。 SELECT * FROM product_code WHERE code BETWEEN 80000 AND 89999; ここで、*はすべての列3を選択します。特定の列（たとえば、製品名と価格）のみを選択する場合は、カンマで区切って指定できます。例えば： SELECT name, price FROM product_code WHERE code BETWEEN 80000 AND 89999; これで役に立つことを願っています。 さらに質問します。否定して：製品コードは文字列であり、あなたのコードは間違っています。\n申し訳ありませんが、製品コードが文字列であることに気づいていませんでした。もしそうであれば、範囲の値の前後にはシングルクォートを追加する必要があります。例えば： SELECT * FROM product_code WHERE code BETWEEN \u0026#39;80000\u0026#39; AND \u0026#39;89999\u0026#39;; 私の誤りを許してください。🙏 おめでとうございます。正しく認識します。\n","date":"2023-02-28","language":"ja","permalink":"https://ttf248.life/ja/p/ai-assisted-programming-productivity-evolution/","tags":["github copilot","chatgpt","ai"],"title":"AIによるプログラミング支援、生産性の進化","year":"2023"},{"categories":["コンピューター"],"content":"あまり使わないけれど非常に便利な git コマンド\nシステムを再インストールした結果、Windows上のフォルダーの所有権が変更されました。 新しいバージョンのGitにはセキュリティチェックが追加され、不安全であると警告が表示されるため、操作できなくなりました。\ngit config --global --add safe.directory git config --global --add safe.directory \u0026#34;*\u0026#34; ユーザーの新しいコンピューターにアカウントとパスワード情報を保存する git config --global credential.helper store 保存された情報が更新が必要な場合は、まず古い認証情報を削除してください。\ngit config --system --unset credential.helper ","date":"2023-02-17","language":"ja","permalink":"https://ttf248.life/ja/p/less-common-git-commands-summary/","tags":["git"],"title":"いくつかのGitコマンドのまとめ","year":"2023"},{"categories":["金融知識データベース"],"content":"香港交易所于12月13日宣布，旗下证券市场将推出“港元-人民币双柜台模式”（以下简称“双柜台模式”）及双柜台庄家机制，以进一步支持人民币柜台在香港上市、交易及结算。\n双柜台モードおよび双柜台庄家メカニズム 香港証取引所（HKEX）は、規制当局の承認と市場の準備が整うのを待って、これらの新措置の登録手続きが2023年第1四半期以降に開始される見込みであると発表しました。双柜台モード下では、HKEXは関連する取引および決済手続を最適化し、投資家が同じ発行体の香港ドル柜台および人民元柜台で上場された証券を交換できるようにします。\n人民币柜台の流動性を高め、両柜台間の価格差を縮小するため、香港証取引所は双柜台庄家メカニズムを導入します。関連法規が立法会で可決されるのを待って、流通量供給活動を行う市場庄家は、特定の取引を行った際に印花税の免除を受けることができます。同時に、これらの新措置も、今後の内地投資家が港股通（香港株式連動基金）を通じて人民元価格で取引される証券を準備するための前段階的な作業を行います。\n「港幣-人民币双柜台モードおよび双柜台庄家メカニズムの導入は、市場発展にとって重要な取り組みです。当社の他の市場措置と連携し、この安排はより多くの双柜台証券が香港に上場され、HKEXの既存の内地製品との良好な協調効果を発揮するのに役立ちます。HKEXは、人民币国際化プロセスを積極的に推進し、香港を世界有数の離岸人民元センターとしての地位を向上させることに尽力しています。」香港証取引所の最高執行責任者および市場統括本部長姚嘉仁が述べました。\n据悉，港股现行的上市、交易、结算及交收安排亦将大致适用于双柜台模式下的人民币柜台证券。HKEX将适时公布双柜台模式的实施日期以及符合纳入庄家机制的合资格双柜台证券名单。\n（注：上記は原文の翻訳です。）\n港元-人民元取引プラットフォームの特定方法 香港証券取引会の文書によると、港元-人民元デュアルプラットフォーム取引のアレンジメントは、既存の株式コード割り当て計画を大まかに準拠し、港元プラットフォームの株式コードは「0」で始まる5桁数字、人民元プラットフォームの株式コードは「8」で始まる5桁数字となる。 港元と人民元プラットフォームの株式コードの最後の4桁は共通である。 人民元プラットフォームの株式略称には、「-R」が付加される。\n取引のアレンジメントに関しては、人民元および港元プラットフォームで同じカテゴリーの証券であり、相互変換可能であるという前提に基づき、あるプラットフォーム（例えば港元プラットフォーム）が空売りを許可されている特定の証券がある場合、別のプラットフォーム（例えば人民元プラットフォーム）も、取引所の規則に従って空売りを許可される指定証券として組み込まれる。 したがって、両方のプラットフォームは、取引所が公開する空売り可能な指定証券リストに共通して含まれる。\n2つのプラットフォームの株式が同一カテゴリーであり、相互変換可能であるため、港元で購入または保有し、人民元で売却することは、持っている状態から売る（沽地）と見なされ、その逆も同様である。 2つのプラットフォーム間の決済期間はT+2である。\n空売り資格を満たす特定の証券の場合、例えば港元で株式を借りてから、人民元プラットフォームで売却することは、担保付きの空売りと見なされる。 その逆も同様である。\n注目すべき点は、デュアルプラットフォームモードにおいて、人民元プラットフォームは取引および決済のみを目的としており、人民元プラットフォームに物理的な株式の入金または引き出しサービスを提供しない点である。 物理的な株式は、まず港元プラットフォームに保管された後に、人民元プラットフォームに変換されるまでしか利用できない。 同様に、人民元プラットフォームは、まず港元プラットフォームに変換された後にのみ、物理的な株式を引き出すことができる。\n関連する取引の決済および清算費用は、香港の決済費用全体が、配当代行サービス料および利息代行サービス料を除いてすべて港元で計算および徴収される。 配当代行サービス料および利息代行サービス料は、関連する証券で使用されている資格通貨で計算される。\n参考資料 HKD-RMB-Dual-Counter-Model 出典：香港交易所脈搏/HKEx Pulse、券商中国\n","date":"2023-02-16","language":"ja","permalink":"https://ttf248.life/ja/p/hk-rmb-dual-counter/","tags":[],"title":"両替櫃台システム（または、クロスボーダー両替システム）","year":"2023"},{"categories":["コンピューター"],"content":"昨年、SDKを設計し、イベントのパッキング処理を担当しました。外部に対してはクラスインターフェースを提供し、サービス初期化時に呼び出し元が対応するクラスを実装し、オブジェクトポインタをモジュールに渡します。\nC11にも触れており、好奇心で猫が死ぬように、これらのインターフェースをlambda関数オブジェクトのコールバックとして実現するとどうなるのか、純粋仮想関数インターフェース定義方法と比較して、より柔軟になるのか試してみようと考えました。\n疑問が生じました。2つの異なる構文、性能面からどちらが速いのか不明です。コンパイラ原理は理解していないので、コードを書いて試してみます。\nはじめに オンラインのURLで、異なるコンパイラを選択したり、コンパイルパラメータを設定したり、linuxプラットフォーム上でコードを実行したり、対応するアセンブリコードを確認したりできます。\nhttps://wandbox.org/：時々技術検証のために、ウェブ上で小さなコードスニペットを実行するのは非常に便利です。 https://godbolt.org/：異なる色でアセンブリコードと対応するコードを区別できるため、ローカルのデバッガよりもさらに便利です。 本文 標準委員会が定める文法規則について、コンパイルレベルにおいてどのように実現するかは、各社のコンパイラに依存します。この点については、特にマイクロソフトのコンパイラは非常に優れていると言わざるを得ません。文法糖衣は万能ではなく、コールバックインターフェースが少ないこと、ラムダ式を使用することでより便利であり、空のコールバック関数インターフェースを定義する必要がないことが挙げられます。コールバックインターフェースの種類が多い場合には、従来の仮想関数の方がビジネスインターフェースの統一に有利です。\nWindowsプラットフォームでは、両者の性能はほぼ同等で、大きな違いはありません。 Linuxプラットフォームでは、仮想関数とラムダ式を比較すると、単回りは1.35ns増加します。 通常のビジネスシステム開発においては、この程度の性能損失は無視できる範囲内であり、ラムダ式を使用することで、設計面での利便性が向上します。特に多重信号処理を行う場合には顕著であり、底层にはイベントトリガーがあり、ログ出力が必要な場合、ログオブジェクトへの処理関数を呼び出します。より多くのビジネス処理インターフェースが必要な場合には、底层でvectorにラムダオブジェクトを保存し、イベントトリガー時に順次呼び出しを行います。これはQTのシグナルとスロットに類似しており、ログ、監視、ビジネス1、ビジネス2といったものが完全に疎結合です。 コード カウンター：1000000 時間：3966us カウンター：1000000 時間：5316us #include \u0026lt;iostream\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;memory\u0026gt; #include \u0026lt;functional\u0026gt; #include \u0026lt;atomic\u0026gt; #include \u0026lt;string\u0026gt; std::atomic_int64_t カウンター = 0; // 回呼インターフェースを定義 class UserInterface { public: virtual void name() = 0; virtual void full_name() = 0; }; class User : public UserInterface { public: void name() {} void full_name() { カウンター++; } }; void to_string(UserInterface* user) { user-\u0026gt;name(); user-\u0026gt;full_name(); } using name_handler = std::function\u0026lt;void()\u0026gt;; using full_name_handler = std::function\u0026lt;void()\u0026gt;; class Test { name_handler name_; full_name_handler full_name_; public: void set_name_handler(name_handler name) { name_ = name; } void set_full_name_handler(full_name_handler full_name) { full_name_ = full_name; } void to_string() { name_(); full_name_(); } }; int main() { User user; auto start = std::chrono::high_resolution_clock::now(); for (int i = 0; i \u0026lt; 1000000; i++) { to_string(\u0026amp;user); } auto end = std::chrono::high_resolution_clock::now(); std::cout \u0026lt;\u0026lt; \u0026#34;カウンター： \u0026#34; \u0026lt;\u0026lt; カウンター \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;時間： \u0026#34; \u0026lt;\u0026lt; std::chrono::duration_cast\u0026lt;std::chrono::microseconds\u0026gt;(end - start).count() \u0026lt;\u0026lt; \u0026#34;us\u0026#34; \u0026lt;\u0026lt; std::endl; counter = 0; auto name = []() {}; auto full_name = []() { カウンター++; }; Test test; test.set_name_handler(name); test.set_full_name_handler(full_name); start = std::chrono::high_resolution_clock::now(); for (int i = 0; i \u0026lt; 1000000; i++) { test.to_string(); } end = std::chrono::high_resolution_clock::now(); std::cout \u0026lt;\u0026lt; \u0026#34;カウンター： \u0026#34; \u0026lt;\u0026lt; カウンター \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;時間： \u0026#34; \u0026lt;\u0026lt; std::chrono::duration_cast\u0026lt;std::chrono::microseconds\u0026gt;(end - start).count() \u0026lt;\u0026lt; \u0026#34;us\u0026#34; \u0026lt;\u0026lt; std::endl; return 0; } 付録 gist.githubusercontent.com/benloong/8050171/raw/fa577ec923b460862078b8b40233a42a1c619eeb/functionperformance.cpp のようなコードスニペットを参考にしました。 #include \u0026lt;iostream\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;memory\u0026gt; #include \u0026lt;functional\u0026gt; using namespace std; using namespace std::chrono; class Base { public: Base(){} virtual ~Base(){} virtual int func(int i) = 0; }; class Derived : public Base { public: Derived(int base = 10) : base{base} { } ~Derived(){} virtual int func(int i) { return i*base; } private: int base; }; struct Func { int base; int operator()(int i) { return i*base; } Func(int base) : base {base} { } }; const int base = 10; int calculate(int i) { return base*i; } int main() { const int num = 10000; Base *p = new Derived{10}; int total = 0; auto start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += p-\u0026gt;func(i); } auto end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\nvirtual call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; total = 0; start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += calculate(i); } end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\ndirect function call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; Func functor{10}; total = 0; start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += functor(i); } end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\nfunctor call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; int base = 10; function\u0026lt;int(int)\u0026gt; lambda = [base](int i) { return i*base; }; total = 0; start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += lambda(i); } end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\nlambda call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; return 0; } /* test on mac mini i7 2.7GHz clang++ -std=c++11 chronotest.cpp -O0 output: result: 499950000 virtual call elapsed: 43171 nanoseconds. result: 499950000 direct function call elapsed: 31379 nanoseconds. result: 499950000 functor call elapsed: 41497 nanoseconds. result: 499950000 lambda call elapsed: 207416 nanoseconds. =================================================== clang++ -std=c++11 chronotest.cpp -O1 output: result: 499950000 virtual call elapsed: 261 ``` /* */ ここに、通常の関数と汎関数（ラムダ式）があり、コールバックインターフェースによる比較と直接呼び出しのパフォーマンスの違いは桁違いです。汎関数は関数に近いため、場合によっては汎関数のパフォーマンスが優れています。コンパイラの仕組みについては知識が不足しており、変数へのアクセスアドレスや関数が隣接していることがCPU処理を有利にするという推測です。 wandboxの結果を添付します。 ``` - 付録 コードスニペット [functionperformance.cpp](https://gist.githubusercontent.com/benloong/8050171/raw/fa577ec923b460862078b8b40233a42a1c619eeb/functionperformance.cpp) を見つけました。 ```c++ #include \u0026lt;iostream\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;memory\u0026gt; #include \u0026lt;functional\u0026gt; using namespace std; using namespace std::chrono; class Base { public: Base(){} ~Base(){} virtual int func(int i) = 0; }; class Derived : public Base { public: Derived(int base = 10) : base{base} { } ~Derived(){} virtual int func(int i) { return i*base; } private: int base; }; struct Func { int base; int operator()(int i) { return i*base; } Func(int base) : base {base} { } }; const int base = 10; int calculate(int i) { return base*i; } int main() { const int num = 10000; Base *p = new Derived{10}; int total = 0; auto start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += p-\u0026gt;func(i); } auto end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\nvirtual call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; total = 0; start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += calculate(i); } end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\ndirect function call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; Func functor{10}; total = 0; start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += functor(i); } end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\nfunctor call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; int base = 10; function\u0026lt;int(int)\u0026gt; lambda = [base](int i) { return i*base; }; total = 0; start = high_resolution_clock::now(); for (int i = 0; i \u0026lt; num; ++i) { total += lambda(i); } end = high_resolution_clock::now(); std::cout\u0026lt;\u0026lt;\u0026#34;result: \u0026#34;\u0026lt;\u0026lt;total\u0026lt;\u0026lt;\u0026#34;\\nlambda call elapsed: \\t\u0026#34;\u0026lt;\u0026lt;duration_cast\u0026lt;nanoseconds\u0026gt;(end-start).count()\u0026lt;\u0026lt;\u0026#34; nanoseconds.\\n\u0026#34;\u0026lt;\u0026lt;std::endl; return 0; } /* test on mac mini i7 2.7GHz clang++ -std=c++11 chronotest.cpp -O0 output: result: 499950000 virtual call elapsed: 43171 nanoseconds. result: 499950000 direct function call elapsed: 31379 nanoseconds. result: 499950000 functor call elapsed: 41497 nanoseconds. result: 499950000 lambda call elapsed: 207416 nanoseconds. =================================================== clang++ -std=c++11 chronotest.cpp -O1 output: result: 499950000 virtual call ## 付録 ```shell 結果: 499950000 仮想呼び出し時間: 6143 ナノ秒。 結果: 499950000 直接関数呼び出し時間: 30 ナノ秒。 結果: 499950000 ファンクタ呼び出し時間: 31 ナノ秒。 結果: 499950000 ラムダ呼び出し時間: 15134 ナノ秒。 ","date":"2023-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/compiler-callback-performance-testing/","tags":[],"title":"- コンパイラ\n- コールバック関数\n- パフォーマンステスト","year":"2023"},{"categories":["コンピューター"],"content":"コンピュータの発展の歴史において、データの保存方法には統一された標準は存在しませんでした。 バイトの並び方は2つの一般的なルールに従っていました。例えば、ある多桁数の低いバイトを小さいアドレスに、高いバイトを大きいアドレスに配置する場合、これを小端序と呼びます。その逆の場合、大端序と呼びます。ネットワークアプリケーションにおいては、バイトオーダーは考慮すべき重要な要素であり、異なる種類のコンピュータが異なる標準のバイトオーダーを採用している可能性があるため、すべてネットワーク標準に変換されます。 読解習慣に従うと、大端バイトオーダーは左から右への読み込み順序に合致します。\nプロセッサアーキテクチャ x86、MOS Technology 6502、Z80、VAX、PDP-11などのプロセッサは小端序を採用 Motorola 6800、Motorola 68000、PowerPC 970などのプロセッサは大端序を採用 ARM、PowerPC（PowerPC 970を除く）、DEC Alpha、SPARC V9、MIPS、PA-RISCおよびIA64のバイトオーダーは可変式 网络序 ネットワーク転送では一般的に大端序が採用され、ネットワークバイト序とも呼ばれ、ネットワーク序とも言います。IPプロトコルにおいて大端序はネットワークバイト序として定義されています。\nBerkeleyソケットは、16ビットおよび32ビット整数をネットワーク序とホストバイト序間で変換するための変換関数群を定義しています。\n#include \u0026lt;arpa/inet.h\u0026gt; uint32_t htonl(uint32_t hostlong); // uint32_t をネットワーク序に変換 uint16_t htons(uint16_t hostshort); // uint16_t をネットワーク序に変換 uint32_t ntohl(uint32_t netlong); // uint32_t をネットワーク序からホスト序へ変換 uint16_t ntohs(uint16_t netshort); // uint16_t をネットワーク序からホスト序へ変換 asio をネットワークライブラリとして使用する場合、組み込みの名前空間には、クロスプラットフォームに対応した関数名が用意されています。\nboost::asio::detail::socket_ops::network_to_host_long boost::asio::detail::socket_ops::network_to_host_short boost::asio::detail::socket_ops::host_to_network_long boost::asio::detail::socket_ops::host_to_network_short Visual Studio デバッガー デバッグモードでは、デバッグメニューを選択し、ウィンドウからメモリウィンドウにチェックを入れます。 Visual Studio では、デバッガー内で直接メモリ内のデータを表示できます（下記画像参照）。 メモリの確認方法 ウィンドウから直接変数名を表示し、対応する変数のアドレスにジャンプ 変数が元のポインタ型である場合、ウィンドウで変数をダブルクリックして選択し、メモリウィンドウにドラッグすることで、対応する内容のアドレスを表示 変数がポインタ型でない場合は、計算ウィンドウに追加し、アドレスを取得してから、手動でメモリウィンドウにコピー 例を挙げて説明します データを受信し、bufferオブジェクトに格納します。ネットワークバイトオーダーをホストバイトオーダーに変換し、body_lengthが30になります。サーバー側では、このデータを送信するために4バイトを使用します。\nbool NetworkMessage::decode_header() { // ネットワークバイトオーダーをホストバイトオーダーに変換 body_length_ = boost::asio::detail::socket_ops::network_to_host_long(*(int *)buffer_.data()); return auto_reserve(body_length_); } 大端型バイトオーダー: メモリウィンドウ内のbuffer_の内容を観察します。 小端型バイトオーダー: メモリウィンドウ内のbody_length_の内容を観察します。 ","date":"2023-01-10","language":"ja","permalink":"https://ttf248.life/ja/p/host-network-byte-order-debugger/","tags":["バイアンス順序"],"title":"ホストモード、ネットワークモード、デバッガを使用して直接観察する","year":"2023"},{"categories":["メモ書き雑感"],"content":"勤務における7回目の年、コードからのポジティブなフィードバックが減ってきており、どのようにしてコーディングという道に進むことになったのかを振り返る。人々の様々な選択において、幼い頃ほど正のフィードバックに従う傾向があり、害を避けることと利益を得ることの間で積極的に判断する。\n一、子供の頃 引っ越しで都心に住むようになり、コンピューターの教科書？ハッカーの資料？Windowsシステムに触れるなど、これらは全てエピソードです。\n時間は子供時代と、親戚である甥っ子と秘密裏に家のパソコンでゲームをしていた頃に絞るべきでしょう。親戚のおじさんお兄さんがパソコンショップを経営していました。\n幼い頃から私達兄弟姉妹はコンピューターに触れる時間が比較的早かったため、基本的な認識を確立しました。その後、学校ではミクシ（微機）科の授業を受けましたが、興味を持つようになりました。\n中学生の頃にはコンピュータ競技会について聞いたことがあり、とてもクールだと感じました。転校後は、その話はしばらく置いておきました。\n私が上中時代だった頃は、コンピューターの基本的な操作に慣れており、ミクシ科の授業では、比較的注目を浴びることができました。\nもしあなたがそれもまだ知っているなら、間違いありません。熟練しているのではなく、Officeなどのオフィスソフトに精通している方が、さらに素晴らしいでしょう。\n二、引越し 引越しということを改めて考えると、都心に引っ越してきたことと近所の状況から、図書館に接触することになり、小説を αρκε数読んだものの、雑誌も多く読みました。\n『コンピュータ報』、『大众软件』\nますますコンピューターという製品に対して興味を持つようになりました。子供の頃の心理におけるハッカーへの崇拝が強く、積極的に学校で関連する知識を学びました。\nオペレーティングシステムの基本的なことを理解しました：コントロールパネル、CMDコマンド、VBSスクリプト\n『コンピュータ報』は初心者向けで適しており、毎回事例形式でシステムの操作方法を解説していました。\n『大众软件』では、様々なソフトウェアの紹介、業界ニュース、もちろんゲームニュースもありました。当初のモチベーションもここで生まれ、ゲームへの興味が芽生えました\nIII. Senior High School When I was in my second year of high school, Bo Ge transferred to our class and had several predecessors who were admitted through computer competition quotas in the previous two years. The school principal also paid a lot of attention to this competition.\nThere was also a pre-existing hardware foundation: an alumnus from America donated a building to the school, which resulted in a new library and a new computer lab – it all seemed so coincidental.\nPlus Bo Ge’s explanations, he became the computer guru in our class at that time.\nA scholar + computer master, knowing how to hack other people\u0026rsquo;s computers and disable classroom surveillance software.\n3. 高校 競技は紆িরে最終戦までたどり着き、内容を十分に理解できず、問題は基礎的なアルゴリズムばかりでした。しかし、結局は結局です。まるで旅行に出かけただけのようなものでした。\n第四、大学 専門選択に至り、家で自動化を選んだが、実は強電を志しており、帰宅して電力局に入ろうと考えていた。しかし、専門課程はほとんど学ばず、 自己駆動力の学習能力は専門課程ではほとんどなく、大課程内のコンピュータコースは、非常にスムーズに学べた。 専門科目のサボりや、コンピュータコースを真面目に学び、日常的に以下のフォーラムで活動：「精易フォーラム」「吾愛破解」。 専門知識であるアセンブリ言語やC++の知識と組み合わせ、フォーラムで仕事を受注して稼ぎ、より多くの肯定的なフィードバックを得て、ますます規模が拡大していった。 最終的には、小規模な選択肢を選び、チップを書くコードを選択し、家でもあまり関心を持たれず、私自身で選択した。 その時、第三の重要な人物：堂（とう）哥（ご）、高い学歴を持ち、百度（ベイドゥ）に入社していた。 お姉様も私のことを理解しており、私が当時研究に集中できなかったことを知っていたため、堂哥と話して将来の展望を確実にした。 夏休みに帰宅せず、指導教官のもとでプロジェクトに取り組み、経験を積んだ。 自分が見れる成績に基づいて、恒生電子（カントンエレクトロニクス）に入社した。\n５．卒業 ここで重要なことは、私が壁を掻き分けて、選択科目として「コンピュータ情報検索」を選んだこと。資料や問題の迅速な検索と特定の方法を知り、そしてキーパーソンである**碩哥（せきちょう）**から時間を与えられ、問題を自分で解決し、根源まで突き止めることを学んだことです。さらに、研究開発センターのベテランとの出会いも促してくれました。\nこれらの経験が、深圳分社において、私が非常に優秀だと周囲に認識されるきっかけとなりました。特に、取引チャネルグループを担当することに成功しました。\nしかし、ここから問題が生じます。コンピュータオペレーティングシステム、アルゴリズムといった基礎知識、ソフトウェア工学設計については、体系的な学習を積んでいなかったため、自身の経験に頼るしかありませんでした。\nそのため、過去の経験に基づき、矛盾したコード設計をしてしまったり、ルールに基づかないモジュール設計になってしまい、７年目に差し掛かり、徐々に力を発揮できなくなってしまいました。\n","date":"2023-01-09","language":"ja","permalink":"https://ttf248.life/ja/p/that-boy-talent-maybe-but-not-much/","tags":["人生 (じんせい / jinsei)"],"title":"その頃の少年は、才能があるかもしれないが、それほど多くはなかった。","year":"2023"},{"categories":["魚の7秒間の見聞"],"content":"政策の発表は非常に突然で、実行も迅速だった。行程制限が解除され、公共の場での緑色コードのチェックはなくなった。\nニューヨーク・タイムズ中文網を閲覧すると、全体に中国の解封についての議論が溢れている。\n政策を評価することはせず、周囲の状況を記録するだけだ。\n北京には元々ゼロコロナ政策はなく、制限が緩和され、急速に感染が拡大した。周りの友人の中では重症者は誰もいなかった。\n深圳は広州市に隣接しており、これも急速に発展した。上海で仕事をしている友人は、会社が郊外にあるため、この稿を書いている時点で大規模な感染は発生していない。\n故郷の予防措置は少なかったが、それに続いて大規模な拡散があった。\nほとんどの場合と同じように感じるだろう。突然解き放たれ、1週間ごとに政策が変わるまで続いた。そして最終的に全面解封に至ったのだ。\n3年間のゼロコロナ政策の効果を否定することはできない。随遇に安うことだ。\n","date":"2022-12-22","language":"ja","permalink":"https://ttf248.life/ja/p/china-coronavirus-end-lockdown/","tags":[],"title":"中国の新型コロナウイルス感染症解除","year":"2022"},{"categories":["コンピューター"],"content":"コードを眺めていると、std::this_thread::yield() が突然視線を集めました。C11 の構文糖で、これほど多く使われていたのは初めてです。yield を以前は目にすることはありませんでした。\nマニュアルを確認せず、まず思い浮かべたのは、それが非同期処理と関連しているのではないかということでした。yield は boost 協程の実装の中に見られる単語であり、ここでは非同期処理とは関係ありません。制御ロジックは通常のスレッドに関連しています。\nドキュメント yield この関数の正確性は、実装に依存し、特に使用されている OS のスケジューラメカニズムとシステムの状態に依存します。例えば、先入れ先出しリアルタイムスケジューラ（Linux の SCHED_FIFO）が現在のスレッドをサスペンドし、それを実行可能な同優先度のスレッドのキューの末尾に置く（同優先度で他のスレッドがない場合、yield は効果がない）といった具合です。\nsleep_for 現在のスレッドの実行をブロックし、指定された sleep_duration 分間少なくとも停止します。 この関数は、スケジューリングやリソース競合による遅延のため、sleep_duration より長くブロックされる可能性があります。 標準ライブラリでは、安定したクロックを使用して時間を測定することをお勧めします。システム時間で実装する場合は、待機時間がクロック調整に敏感になる可能性があることに注意してください。\n分析 両方の関数は、現在のスレッドがスレッドを占有しないようにし、実行効果はプラットフォームによって異なる可能性があります。ここまでの内容でまだ少し理解が曖昧ですが、コードを実行して結果を確認してみましょう。\nThinkPad ノートパソコン（Visual Studio Community 2022）、腾讯云 S2 標準サーバー（gcc8.5）\n分析 実行プラットフォーム 関数 初回/us 二次/us 三次/us Windows sleep_for 9872 1884 11302 分析 実行プラットフォーム 関数 初回/US 二回目/US 三回目/US 分析 実行プラットフォーム 関数 初回/us 二回/us 三回/us Linux sleep_for 171 168 167 分析 実行プラットフォーム 関数 初回/us 二次/us 三次/us Linux yield 101 102 101 分析 実行結果から判断すると、オペレーティングシステムの異なる実装により、高精度なスリープ（休眠）時の sleep_for の安定性差が非常に大きいことがわかります。高精度なスリープを実現するためには、yield を使用する方が適しています。\n時間精度を ms (ミリ秒) に向上させた場合、両者の差異はほとんど見られなくなります。\n#include \u0026lt;iostream\u0026gt; #include \u0026lt;chrono\u0026gt; #include \u0026lt;thread\u0026gt; // 別のスレッドで短い時間の“忙しいスリープ”を実行することを推奨します void little_sleep(std::chrono::microseconds us) { auto start = std::chrono::high_resolution_clock::now(); auto end = start + us; do { std::this_thread::yield(); } while (std::chrono::high_resolution_clock::now() \u0026lt; end); } int main() { auto start = std::chrono::high_resolution_clock::now(); little_sleep(std::chrono::microseconds(100)); std::this_thread::sleep_for(std::chrono::microseconds(100)); auto elapsed = std::chrono::high_resolution_clock::now() - start; std::cout \u0026lt;\u0026lt; \u0026#34;waited for \u0026#34; \u0026lt;\u0026lt; std::chrono::duration_cast\u0026lt;std::chrono::microseconds\u0026gt;(elapsed).count() \u0026lt;\u0026lt; \u0026#34; microseconds\\n\u0026#34;; } 参照 https://qingcms.gitee.io/cppreference/20210212/zh/cpp/header/thread.html https://qingcms.gitee.io/cppreference/20210212/zh/cpp/thread/sleep_for.html ","date":"2022-09-20","language":"ja","permalink":"https://ttf248.life/ja/p/c11-sleep-for-vs-yield/","tags":["c++"],"title":"C11: sleep for vs yield","year":"2022"},{"categories":["コンピューター"],"content":"闲置の腾讯クラウドサーバーがあり、年末に契約が満了し、更新も考えていなかったので、開発用のデータベースとしてMySQLをデプロイすることにした。システムを再構築する際に、手間を省いて、腾讯クラウドから提供されている汎用イメージを選択した。すでにMySQLデータベースがインストールされていた。本来はシステム内にReadmeのようなファイルがあり、パスワードや設定ファイルの場所などを説明してくれるだろうと期待していた。\n腾讯クラウドのシステム再構築は非常に速く、約1分で完了通知が来た。ログインしてsystemctl status mysqlコマンドを実行したところ、MySQLサービスが起動していることが確認できた。パスワードを探し回ったがどこにも見つからず、次第に焦り始めた。\nそこで、サーバーにアクセスしているのであれば、root権限を使ってパスワードをリセットする方法があるはずだと考えた。資料を調べたり、阿里云フォーラムの投稿を参考にしたりして、さらに試行錯誤を続けた。\nパスワードのリセット 構成ファイル vim /etc/my.cnf を編集し、mysqld ノードに以下の設定を追加します：skip-grant-tables 、systemctl restart mysql コマンドを実行してデータベースを再起動します。 その後、mysql を直接使用してデータベースにログインし、通常の操作が続行できます。 root ユーザーのパスワードをリセットし、同時にリモートログインを許可します。\nUSE mysql; UPDATE user SET authentication_string = password(\u0026#39;pass\u0026#39;) WHERE User = \u0026#39;root\u0026#39;; GRANT ALL PRIVILEGES ON *.* TO \u0026#39;root\u0026#39;@\u0026#39;%\u0026#39; IDENTIFIED BY \u0026#39;pass\u0026#39; WITH GRANT OPTION; FLUSH PRIVILEGES; 変更した構成ファイルをロールバックし、データベースを再起動して完了です。\n参照資料 https://help.aliyun.com/document_detail/42520.html ","date":"2022-09-20","language":"ja","permalink":"https://ttf248.life/ja/p/linux-server-reset-mysql-password/","tags":["mysql"],"title":"Linuxサーバー、MySQLパスワードのリセット","year":"2022"},{"categories":["メモ書き雑感"],"content":"中国文字の浩大な体系において、「命」という字は唯一無二であり、同じ読みを持つ字が一つもない。もしかしたら、この冥冥の中の暗示は、人それぞれの生命が一度きりで、複製したり、やり直したりすることができないことの表れなのかもしれない。\n暇な時間に起点中文网のランキングを調べてみると，《夜的命名術》の月票数が圧倒的に多く、首位を独占し、第二名との差はあまりにも大きく、追いつくことすら難しい。これまで私は、唐家三少や耳根といった知名作家の作品を多く読んできたが、今回は新作者の作品に挑戦して、違った読書体験を得ることにした。\n8月初旬時点では，《夜的命名術》の月票数は200万を突破し、第二位は8万人と大きく差が開いているのが驚くべきことだ。\n私は自分の知識不足を自覚しており、この本の文筆を評価する能力はないと考えている。しかし、10数章読み終えたところ、物語は緊密に、巧みに絡み合い、読者を惹きつける魅力的な展開であり、このような高い月票数を獲得しているのは、まさに実力至上主義であると感じた。\n「命」の字と同様に、「死」という字も中国文字の中で同じ読みを持つ字が見つからない。これは生命の終焉が同様に唯一無二で、代替不可能な深い意味合いを秘めているのだろうか？\n","date":"2022-08-11","language":"ja","permalink":"https://ttf248.life/ja/p/nights-naming-art/","tags":["出発点","小説"],"title":"夜の命名術","year":"2022"},{"categories":["コンピューター"],"content":"金融取引システムにおけるテストへの投資は、他のシステムを大幅に上回っており、煩雑なテスト手順が繰り返し行われていました。ROI（投資対効果）は著しく低く、プロジェクトや人員の変更に伴い、不可避的に多くのコントロールできない要因が導入されました。よく見られるのは、Aインターフェースからの出力フィールドを修正するとBインターフェースの結果に影響が出るケースです。各バージョンリリースごとにリスクも蓄積されていきます。\n理論的知識 自動化の価値をどのように測定するか？ 自動テストのROI = (手動実行時間) * (実行回数) / (開発コスト + メンテナンスコスト) どのような機能に自動テストを行うべきか？ ユーザーが頻繁に使用し、頻繁に変更されない機能。このようなインターフェースに対して自動テストコードを作成することで、最大の利益が得られます。 なぜこのタイミングで自動テストを推進するか？ プロジェクトのリリース直前は不適切であり、遠い水の問題を近渴（近隣の渇き）で解決しようとするのは無駄です。自動化は長期的な収益モデルであるため、最も適切なタイミングは、プロジェクトが本番環境で稼働し、安定したリリースサイクルに入っている時点です。 フレームワークの選択 関連の実践経験が不足している状態で、このような自動化テストのタスクを受け取った場合、一般的なスタートは、検索エンジンを開いて、現在のシステム技術スタックで利用可能なツールやフレームワークを探し、マニュアルを読み、一発勝負。適切なツールを見つけられれば、おめでとうございます、完璧なスタートです。 まず「間違っていた」と言っておきながら、関連資料を調べ直すと、これは存在しないわけではなく、むしろフレームワーク自体が複雑で、デプロイに必要なリソースも多すぎることがわかります。初心者にとって必要なのは、小さくて、簡潔で、テストチームの同僚に相談すると、Python 自体構築のフレームワークについて提案され、簡単に言うと、既存のユニットテストフレームワークを自動テストフレームワークとして活用するというものです。 参考となるプロジェクトのデザイン思路：https://github.com/wintests/pytestDemo\nフレームが必要な理由 サービスには、開発環境、テスト環境、本番テスト環境など、複数の異なるデプロイ環境が存在します。フレームワークの役割は、これらの環境間の抽象化層を提供することです。テストケースとデータが分離され、それぞれの環境設定に合わせて異なるケースデータを適用できます。また、共通のデータをサポートすることも可能です。\n主な目的は、自動化の利用率を向上させることです。より複雑なシナリオでは、異なる環境間でのデータ連携は存在せず、全く関係ありません。ケースデータを設定する際に label 属性を追加し、現在のデータがサポートする環境を指定するだけで済みます。\n参考文献 最高のコストパフォーマンスな自動テスト\n","date":"2022-08-04","language":"ja","permalink":"https://ttf248.life/ja/p/automated-testing-overview/","tags":["自動テスト","アーキテクト","極東時間 (Kyoutou Jikan)","auto-test"],"title":"自動テストに関する考察","year":"2022"},{"categories":["コンピューター"],"content":"学歴から算じると、C++に触れるのは10年以上になる。他のプログラミング言語を学ぶ必要がなぜあるのか？\n職務経験：エレガントなモジュール設計の経験が不足しており、C++の構文は自由度が高いため、他の言語を学習することで、よりエレガントな設計を書くことができるように導かれている。\nいくつかのツールを作成する際に、頻繁に利用することがある。\n低レベルライブラリのデザインやビジネスモジュールの実装など、デザインの原則もすべて理解できている。\n","date":"2022-08-04","language":"ja","permalink":"https://ttf248.life/ja/p/why-learn-a-new-language/","tags":["c++","python","golang"],"title":"新しい言語を学ぶべき理由は何ですか？","year":"2022"},{"categories":["コンピューター"],"content":"C++をクロスプラットフォームで開発する際、中国のオペレーティングシステムではよく遭遇するエラーは、error C2001（定数に改行文字が含まれています）です。\nVisual Studio CMakeはプロジェクトのコンパイルスクリプトを組織し、Windows環境での開発時に一時的にソリューションファイルを生成します。クロスプラットフォームである理由として、ファイルエンコーディングにUTF-8を選択しています。\n引用資料では、問題の原因について原理に基づき詳細な説明が提供されています。\nエンコーディングに関して、MSVCにはコンパイルオプション/source-charsetと/execution-charsetがあり、これらを使用することで、ほとんどのエンコーディング問題を解決できます。\n例えば、WindowsのcmdコマンドプロンプトはデフォルトでGBKエンコーディングしか表示できない場合でも、コードファイル自体がUTF-8で記述されているため、クロスプラットフォームであることや、直接GBKに変換する変更を加えることが難しい状況です。そこで、Win10上で/source-charset:utf-8 /execution-charset:gbkというコンパイルオプションを設定し、コンパイラをUTF-8エンコーディングで読み込み、内部の文字列配列にはGBKエンコーディングで保存することで、直接printf関数を使用してcmdコマンドプロンプトで漢字を表示することができます。\nVisual Studio 用の CMake 設定 if(WIN32) message(STATUS \u0026#34;WIN32 での構成実行中\u0026#34;) set(CMAKE_CXX_FLAGS \u0026#34;${CMAKE_CXX_FLAGS} /source-charset:utf-8 /execution-charset:gbk\u0026#34;) endif() 参考文献 https://zhaolan.zhihu.com/p/146543940 ","date":"2022-08-04","language":"ja","permalink":"https://ttf248.life/ja/p/visual-studio-character-set/","tags":["visual studio","cmake","文字コード"],"title":"Visual Studio コンパイル文字セット [転送]","year":"2022"},{"categories":["魚の7秒間の見聞"],"content":"政治に無知であり、コメントはしない。このインターネット上の「狂騒」を記録する。\n随筆 先日起きた唐山暴行事件、人教小教材文化浸透事件、もうすでに多くの人が覚えていないだろうか。ニュースで取り上げられるような話題は、すでに無関心になり、ほとんど感情が動かない。退社していつも通りドラマを観るだけだ。経済状況がすでにこのような状態であるにもかかわらず、戦争が勃発すれば、生活はより悪くならないだろう。政治のことを理解せず、意見を述べることもない。インターネット上での「狂騒」を記録するだけに留める。\nWiki 概要 2022年南希·佩洛西访问台湾，又称佩洛西访台，是指美国第52任众议院议长南希·佩洛西于2022年访问亚洲国家之旅，其间，访问台湾的行程。\n由于美国众议院议长被视为美国第三号人物，并计划访问台湾，日期短期内接近8月1日的中国人民解放军建军纪念日，长期内接近中国共产党第二十次全国代表大会、2022年美国选举及2022年中华民国地方公职人员选举。中华人民共和国方面，其政府提出强烈抗议，派遣海军驱逐舰部队到达台海东北海域，动员山东舰与辽宁舰两个航空母舰战斗群，东部战区与南部战区分别在东海与南海开展大规模实兵实弹演习。美国方面，派遣罗纳德·里根号航空母舰战斗群抵达台海周边护卫佩洛西可能的访台行程，并调遣多批次侦察机与空中加油机至驻日美军嘉手纳空军基地待命。\n中国国家主席习近平与美国总统乔·拜登在访问前曾进行视频会晤，内容涉及台湾问题。台湾与国际媒体透露佩洛西议长及众院访问团将于2日抵达台北松山机场，过夜后将在3日会见中华民国总统蔡英文等政府高层。有观点认为此次佩洛西访问台湾有可能造成自1996年台湾海峡导弹危机，26年来新一次的台湾海峡危机。\n08-11 本日ほぼ確定となり、この間の話題騒ぎはついに終息。様々な海軍演習や、知乎も熱意をもって毎日のようにランキングを更新していたが、語られていたのは全てこの一件だった。編集部の皆様、お疲れ様でした。\n","date":"2022-08-02","language":"ja","permalink":"https://ttf248.life/ja/p/pelosi-visits-taiwan/","tags":["ペロシー (Perotti)","台湾 (Taiwan)"],"title":"ペロシの台湾訪問","year":"2022"},{"categories":["コンピューター"],"content":"Linuxプラットフォームは非常にシンプルです。「du -sh *」という一行のコードで済みます。Windowsはどうでしょうか？ディスクが複数あり、クリーンアップしたいのですが、ファイル数が多くて、システム標準の「リソースマネージャー」でフォルダサイズを統計すると、速度が遅くて諦めそうになります。\nEverything Windows 平台で開発をしている方で、Everything を実際に使ったことがない方もいるかもしれません。検索速度はシステム標準のファイルエクスプローラーを圧倒的に上回ります。システムレベルでファイルの高速インデックス作成がサポートされているので、同様のツールを見つけることができるはずです。ファイルサイズも同時に統計できます。\nWizTree 公式サイト：https://www.diskanalyzer.com/ 通常のインストールモードまたはグリーン版を解凍して実行 高速、データ表示タイプが豊富で、左側はツリー状図モード、右側にはファイルの種類が表示され、もちろんグラフィカルな表示も、ソフトウェアの下欄にあります。\nSpaceSniffer (2023年不再维护更新) ソフトウェア公式サイト：http://www.uderzo.it/main_products/space_sniffer/ 操作は非常に簡単です。対応するドライブを選択すると、ソフトウェアはグラフィカルな方法でフォルダのサイズを表示し、サイズが大きいほど画像内の対応する行列も大きくなります。その他の操作は、自分でクリックすれば理解できます。ファイル条件フィルタリングをサポートしています：\nファイルサイズのフィルタリング ファイルの日付フィルタリング 基本的な使い方\n高度な使い方\n参照資料 https://moe.best/software/spacesniffer.html\n","date":"2022-08-01","language":"ja","permalink":"https://ttf248.life/ja/p/windows-platform-quick-folder-size-statistics/","tags":["Everything","SpaceSniffer","windows","WizTree"],"title":"Windowsプラットフォームでフォルダのサイズを迅速にカウントする","year":"2022"},{"categories":["コンピューター"],"content":"静的ブログのテーマは、主流が海外製のテンプレートで、調整や修正を行うことが多く、中国語コンテンツのレイアウトにはあまり考慮されない。\n本文 半月ほど前、ブログのスタイルシートを調整しました。長年バックエンドサービスの開発をしているのですが、フロントエンドは純粋な初心者です。前後とも半日かけて苦戦した結果、デザインがなかなか良くありませんでした。突然閃いて、よく読む技術ブログ（infoq、开源中国など）のデザインが良いなと思い、参考にしてみようと思いました。ソースコードを拝見し、関連する要素を特定しようとしましたが、霧だらけでした。\nフロントエンドの友人がこの部分を見ると笑ってしまうかもしれません。指定された要素を特定することも理解できません。理解する必要はありません。週末は時間があるから、立ち止まって考えればいいのです。以前、python で爬虫（ウェブスクレイピング）を書いたときには、似たようなものを使っていたように思います。\n要素検査 そうです、ブラウザに標準搭載されている要素検査ツールを使って、スタイルシートをコピーしたり、指定した要素の位置を特定したりするのは、あっという間です。selector で要素を特定したり、hugo で user define css を新規作成したりすることも可能です。\n元素のコピー outerHTML のコピー セレクタのコピー JS パスのコピー スタイルのコピー XPath のコピー 完整的 XPath のコピー ","date":"2022-07-31","language":"ja","permalink":"https://ttf248.life/ja/p/how-to-copy-webpage-css-element-inspect/","tags":["スタイルシート","CSS"],"title":"ウェブページのスタイルシート（CSS）をコピーする方法：要素の検証","year":"2022"},{"categories":["コンピューター"],"content":"上海国安数据库事件、在黑客圈子内闹得沸沸扬扬，不知真假，过两年如果还记得，再回头看看。根据以往的经验，更新了一波本地的社工数据库资料，看到一个巨型SQL文件：17.9G，一般的文本编辑器，预览都是个问题，更别说打开了，和网友闲聊，提到了：EmEditor。\n正文 公式サイト：https://www.emeditor.com/ 週末に時間を割いて試してみたところ、非常に便利で、デザイン面でも大ファイル編集をサポートしており、十分なメモリがあれば、ファイル全体をメモリ上に読み込んで検索や編集速度が非常に速く、分割機能も利用できます。\n","date":"2022-07-31","language":"ja","permalink":"https://ttf248.life/ja/p/windows-platform-edit-large-files-emeditor-text-editor/","tags":["windows","EmEditor","エディター","大規模ファイル"],"title":"Windowsプラットフォームで超大型ファイルを編集する：EmEditor (テキストエディタ)","year":"2022"},{"categories":["魚の7秒間の見聞"],"content":"リーダーシップチームは、先週2日間で上海が封鎖されることはないと死に際の尊厳を保ちながら主張していた。上海は重要だからだ。しかし、現状に屈し、あるいは自分の地位を守るために、対岸から隔てるような行動に出たのだ。まず黄浦江（ファンパール・カン）の対岸をしばらく閉鎖し、その後江（ガン）側も封鎖するという流れになった。\n封鎖 幼い頃にSARS（重症肺炎）を経験しており、あまり記憶に残っていません。その後、関連資料を見たことで、潜伏期間が短く、全国的な蔓延が起こる前に終息したことを知りました。小学校に通っていた頃、毎日授業が終わるのがとても早くて、教室には消毒液の匂いが漂っていました。\n20年末から現在まで、新型コロナウイルス感染症はほぼ3年になります。在外労働者も慣れており、マスクを着用すべき時はマスクを着用しています。上海での波及感染が繰り返され、当初は香港からの輸入型感染症で、その後、国境を越えたゲートを通じて深圳に拡散し、上海では香港の一波の輸入型感染症の影響によるものです。政府は最後に発表した通告で、隔離施設の保護対策が不十分であったために感染拡大につながったと説明しています。変異株のウイルス毒性は弱まりましたが、伝染速度は速くなりました。隔離施設の換気システムを通じて拡散しました。当初は症状が重くなく、制御することができました。\n人は自信を持つものだ。上海のリーダーたちも同じです。彼らは格画的な地域管理を私たちに選択し、精密な防控を行います。\n封鎖 ご覧のとおり、新たに発生した感染者数はすでに2万人を突破し、逼迫した状況から封鎖を実施せざるを得なくなりました。重要な点として、封鎖という言葉を使用せず、以前の記者会見で「封城」という言葉を使わなかったことが挙げられます。これは、最後の顔面（みかじめ）を守ろうとしたものと解釈できます。\n買い物 外食産業は、インターネットが作り出した新興産業です。その核心は、誰かがあなたのために食材を配達する必要があること。しかし、パンデミックにより広範囲で都市封鎖が行われたことで、店舗が営業できるものの、誰もが配達を受け取ることができず、サプライチェーンの最後のリンクが欠けてしまいました。外の人には理解しにくいかもしれませんが、国際的な大都市である上海が、人々が集まって買い物に行くのは珍しいことではありません。考えてみると、多くの人は地方から仕事のために住んでいるだけで、賃貸アパートに住み、普段は会社の食堂で食事をしたり、外のレストランで食事をしたりすることがほとんどです。外出路が閉ざされた場合、条件を満たしている店舗は買い物を始めます。この都市封鎖に関する発表は事前に通知されておらず、人々は日常的に十分な食料や野菜を備蓄していませんでした。そのため、ビデオに登場するような一斉の買い物が発生し、その状況下での集団発生が、再び感染を拡大させました。\n業界 主な業務はIT業界に関連しており、今回のコロナ禍で自宅勤務を経験し、その影響について感じました。2019年の春には、自宅でほぼ1ヶ月間過ごし、往復で切符の変更手続きを10回以上行い、いつ深圳に戻れるのか全く見通しの立たない状況でした。飲食業界や観光業、あるいは多くのサービス業の人々が、この数年間にどのような経験をされたのか想像もできません。\n","date":"2022-03-30","language":"ja","permalink":"https://ttf248.life/ja/p/shanghai-yuanyang-pot-sealed/","tags":[],"title":"上海鴛鴦鍋封城 (Shànghǎi yuānyāng guō fēngchéng)\n\nThis is a direct translation, as \"Shanghai Yuanyang Guo Fengcheng\" refers to a specific historical event.  It literally means \"Shanghai Yuanyang Pot Siege.\"","year":"2022"},{"categories":["メモ書き雑感"],"content":"一般人都是社交动物，没错，你是个人，也是一个直立行走的动物，附带很强的社交属性；有自卑心、虚荣心，社会一直在变化，也在一直侵蚀你的平淡感。我们不讨论那些伟人，那些甘愿为了社会、为了国家燃烧自己。\n今の私 平均賃金、あるいは故郷の賃金を見ると、今の私の収入は明らかに平均レベルを大きく上回っています。それにもかかわらず不満があると言えるのでしょうか？\n一百万稼げたら次は一千万円、二千万円…と考えるのは常人のことです。人は自分の内なる声に耳を傾けるべきです。\n今の私 その赤い目元のものは、より楽に稼ぐ方法：ショート動画のことです。\n業界への入行は皆が知っていることではありません。あなたが目にするのはショート動画ですが、それには撮影や文章作成といった裏側の努力があります。しかし、人それぞれには天才的な夢があり、私はその業界に向いているし、生まれながらにしてそれが私の適性だと信じています。\n接触開始 たくさんの動画を見てきました。自分の頭で少しずつ多くのシーンを分析すると、明らかにプロの編集手法が使われており、強い映画的な色彩を持っています。つまり、彼らは皆、科目を学んだ出身です。もちろん、草根派が爆発的に人気が出るような論理もありますが、それは一般の人には当てはまりませんよね？ 抖音上では、動画をどのように作るか教える動画もたくさんあります。その時、人間が清醒に目覚めるのです。もし本当に稼げるのなら、なぜ彼らは自分自身で作り、他の人に教えないのでしょうか。\n反社会的なレコメンドアルゴリズム 以前、抖音のアルゴリズムが映画のクリップやアニメのクリップを勧めてくる際に、見ているうちに面白いと感じることがありました。しかし、私が抖音がどのように稼ぐのかについて調べたとき、彼らは様々な教育ビデオをノンストップで勧めてきて、私のレコメンドストリーム全体を埋め尽くしました。自分自身もIT業界で働いているため、この状況に「アルゴリズムのオタクたちの大脳は本当に問題があるのではないか」「こんな風に勧めるのは、私達を愚かに見なしているのか、それともあなた自身が愚かに見なしているのか」という疑問を感じました。重要なのは、あなたが抖音で稼ぐ方法に関するビデオを、様々な角度から、あらゆるジャンルからノンストップで勧めてくることです。この稿は、凌晨3時に書いたものであり、本来書くつもりはありませんでしたが、このようなビジネスモデルがどれくらい持続できるのか、そしてあなた方はどれくらいの時間を奪い続けることができるのか疑問に感じました。\n活明白 人に何かを教えるときは、一套一套のやり方を提示し、自分自身で行動するときは、どうしても制御できない。これがまさに笑話だ。純粋な技術ブログ執筆者ではないので、いくつかのことは国内に発信していなかったが、ここでは随意的つぶやきをする。もし有一天、封鎖されたとしたら、それは別の場所を探せばいいだろう。抖音を全く使っていないとは言えないだろう。少なくとも、現在ではリアルタイムニュースの伝達、国家の政策プロパガンダなど、積極的に協力している。毕竟、我国においては、党に反することのできないからだ、そうだね？ そうした時、昔の学生時代を思い出す。本当に人生の意味を見つけられなくなったとき、静かに一冊の本を読むだけで十分だ。今の時代には、心を落ち着けて静かに本を読むことができる人は、果たしてどれくらいいるのだろうか。\n付録 ここでは、科学技術の進歩にも感謝したいと思います。もしあなたがこの行を見ているなら、この記事全体が非常に口語的であることを発見することでしょう。そして私自身は、これを読みふけきながら書き続けていったのです。普段使っている入力法は、検索狗（すこごう）入力法で、8年以上も使ってきました。しかし、音声入力に関しては、専門的であるのは讯飞（しんぴー）です。\n2022年の記事の番号が002に変更された理由ですが、これは夢でした。今年の記事数を100本に超えるという目標を掲げたのです。もちろん、「記事」とは言い切れません。記録といったところでしょうか。吾日三省吾身（われひさんぜんごしん）ですね。あなたはきっと何かを思いつくことでしょう、そうですよね？\n","date":"2022-03-27","language":"ja","permalink":"https://ttf248.life/ja/p/when-you-want-to-make-money/","tags":["人生 (じんせい / jinsei)","ソーシャル (sōsharu)","抖音 (Douyin)"],"title":"お金を稼ぎたいときに","year":"2022"},{"categories":["コンピューター"],"content":" 「ouuan」を４時間も調べて、その時この文章を見ていると、まだ面白がっていて、どうしてこんなに時間がかかったのか不思議だった。最後に時間を調べると３時間だった。\nこれは2022年の年初に書いた最初の記事で、扱うべきことは単純なもので、タイトル通り完全に同じ内容（当時としてはまだ若かった私）だと考えて、作业をそのままコピーしてブックマークに入れて、しばらく放置していました。ようやくこの件を思い出したのです。\nhugoに移行する際、プラグインが少なすぎて、コードをコピーできず、多くのメモを印象派からブログに移行する際に、コードをコピーする作業が煩雑になり、私の水面下ブログのモチベーションを著しく低下させてしまいました。\n序章 まず、原作者の稿をじっくりと見直し、通読し、作者紹介も確認します。うわー、すごい大佬だ！清華大学で学んでいる学部生で、昔からコンピュータに触れているんだ。なるほど、クールなやつだ。まずはこのブログを確認し、自分が何をすべきか全く覚えていない。ついでに作者のGitHubリポジトリをチェックする。この修正された「even」テーマは今のよりずっと見栄えが良く、新しい機能もたくさんある。早速取り掛かり、関連コードをマージしよう。 新機能：記事の履歴表示、関連提出記録の確認 効果はなかなか良く、記事末尾にスクロールすることで体験できます。 マージ前に作者の元のリポジトリの履歴を確認していなかったので、簡単なマージで済むと思っていましたが、最終的に大量のコードをマージし、その中に衝突やN回の巻き戻しが発生し、無脑覆盖（強制上書き）を行いました。それはすべてフロントエンドとレンダリングのテンプレートコードであり、私が使用するものに合わせました。 リポジトリ：https://github.com/TianlongXiang/hugo-theme-even 中国語の罠です。gitでこのパラメータを調整しないと、生成される履歴リンクが現在の記事のcommit hashを取得できず、履歴リンクの生成に失敗します。完全な記事履歴を生成する際も、自動統合スクリプトを修正する必要があります。必ず現在のリポジトリ全体の履歴をプルしてください。\nfeat: 完全に GitHub リポジトリをプルして、記事の最終更新履歴を動的に更新 chore: パスに日本語が含まれているため、hugo GitInfo でこの設定を有効にする必要がある name: Build Github run: git config --global core.quotePath false \u0026amp;\u0026amp; hugo -b \u0026#34;https://www.xiangtianlong.com/\u0026#34; -d \u0026#34;github_public\u0026#34; \u0026amp;\u0026amp; ls スタイル調整 サイトコンテンツの幅を調整します。以前のデザインはモバイルとPCの両方に対応していましたが、実際にスマートフォンでの閲覧はほとんどなく、私はPCで確認しています。 目次バーを自動伸縮するように変更します。 本文 ouuanのコード記録を参考に半時間以上見てみても、コピーボタンの追加方法がよく分からなかった。\n時光穿梭，一月之后，又想到这事\n正文 今回この課題が理解できなかったため、別の課題をコピーし、必ずしも理解できるものにしました。検索で見つけた結果は、意外にもhugo公式フォーラムにコードのコピーボタンを追加する方法についての投稿がありました。そこを拝見すると、論理が明確でわかりました。混乱していた状況でしたが、戻ってサイトを見るとevenレンダリング生成したコードブロックのスタイルと資料の説明が異なり、この部分は少し複雑です。簡単に記録しておきます。 基本的にはフロントエンド開発は理解していないため、わからない箇所はブラウザの「要素を検査」ツールを使ってコードを分析し、右側のスタイル情報に頼って徐々に論理を理解していきました。「JavaScript」についてはコンソールでログを出力しました。最初は多くのことがわからず、落ち着いて、少しずつ論理を整理・分割していき、必ずや解決策が見つかります。\n\u0026lt;pre\u0026gt;ノードが複数存在し、ここでは個々のコードブロックを指します。テーマが自動的に行番号を表示しており、その結果コピーボタンが2つ表示される テーマの組み込みされたコードハイライト機能を無効化したいのですが、このテーマの設定はよくわかりません。 hugo公式ドキュメントで資料を参照し、半ば理解しながら、コードハイライトを制御できる「markup」設定があることを知りました。 設定ファイルを調整してもなかなかうまくいかず、レンダリング結果と期待値が異なっていた このような設定の「pygmentsOptions」を発見し、さらに資料を調べて設定を調整しました。まず行番号を削除する カスタムCSSスタイルシートとカスタムJavaScriptスクリプトを設定しました。 結局これだけの作業をしたので、この文を見つけたときには、なぜこんなに時間がかかったのか笑ってしまいました。実際には3時間でした。最後に時間をを見ると：3時間。 参考リンク https://ouuan.github.io/post/from-hexo-to-hugo/ https://gohugobrasil.netlify.app/content-management/syntax-highlighting/ https://gohugo.io/getting-started/configuration-markup#highlight https://www.dannyguo.com/blog/how-to-add-copy-to-clipboard-buttons-to-code-blocks-in-hugo/ ","date":"2022-02-25","language":"ja","permalink":"https://ttf248.life/ja/p/add-copy-button-for-simple-task/","tags":["blog","button"],"title":"単なる簡単なことに追加のコードコピーボタンを実装する","year":"2022"},{"categories":["転載 (tenzai)"],"content":"王羲之は言う：「妻との交わりにおいては、上下の人々を思うように、あるいは自分の胸中に納め、世の理を悟る言葉を一つの部屋に集める。あるいは、彼女への信頼を託し、その形骸から離れて放浪する。 」\n人生の一生涯、如昙花一現。草木の春緑枯榮、曦月東升西落。 偏偏人生欲望却有很多。\n幼少の頃、溪頭で臥剥蓮蓬を忙しめ、東風に紙鸢を放ち、急ぎ追う黄蝶も追いかけ、傍桑影で瓜を種付け、帰ってきては飯が食い、黄昏時に蓑衣を脱ぐことなく月明かりの下で眠る。\n大人になったら、金榜題名することを願い、佳人との同伴を願う、財産が絶えず増えることを願う、地位が上がり続けることを願う、高朋の席に満ちることを願う、夜通し笙歌を奏でることを願う。\n老いては健康長寿を望み、童仆が歓迎され、稚子が門前に候い、一盤の棋、一知己、一壺の酒、一庭院を持ち、天倫に安らぐ。\n世人は慌ただしく、ただ碎銀几兩を得ようとするだけだ。しかし、その碎銀几兩こそが、世間の万種な惆悵を解くことができるのだ。\n多くの人々が生活のために苦闘し、人生の意味を追い求める時間があるのだろうか？\n実は人生は、草木や日月のように、欲望の輪廻を体験するほんの一瞬のことだ。\n意味を理解できずに「天地に蜉蝣（かぶつ）と、海に粟（あわ）の一つ」と感じたり、「生は一瞬、長江は無限」と嘆き悲しんだりすることもあるだろう。意味を理解すれば、出会うものに喜び、一時的に自分のもとに与えられたものを大切にし、快楽を知って自足し、老いの到来を悟ることなく生きることができる。\n金銭や名誉を追い求めることもできるし、詩酒花茶（しゅせいか ちゃ）を楽しむこともできる。江上の清風（こうじょうの せいふう）を求めたり、山間の明月（さんげんの めいづつ）を眺めたりすることもできるだろう。\nしかし、結果に過度に執着する必要はない。結果は必ず過ぎ去ってしまうからだ。\n人生の終わりに辿り着くとき、世の中の喜びや悲しみ、怒りや哀れみを最大限に経験し、生老病死（せいろうぼうし）を味わうことが大切だ。\n『大魚海棠』の言葉が好きだ。\n「我々の人生は短い。失われてしまうのだから、大胆に愛することもあるだろう。山を登ることもあるだろう。夢を追いかけることもあるだろう。答えのない多くのことに、大胆になることを。」\n私は『蘭亭集序』と『赤壁賦』を大変気に入っています。\n過去の賢者の興亡に心を動かされることしばしば、もしそれが一つの契機となれば、未だ嘆き悲しむこともなく、そのことを心に留めることができたのに。しかし、結局は一生を死として笑い飛ばすことは虚偽であり、斉彭の犠牲はただの戯言に過ぎないことを知っている。後世が今の私を見れば、今の私が昔のあなたを見ているように思われるだろう。ああ、嘆かわしい！\n","date":"2021-08-31","language":"ja","permalink":"https://ttf248.life/ja/p/what-we-seek-throughout-life/","tags":["人生 (じんせい / jinsei)","意味","探求 (Tanka) / 追求 (Suikyuu)"],"title":"私たちは人生の限り、何を追い求めていたのでしょうか。","year":"2021"},{"categories":["金融知識データベース"],"content":"まれで、時間が経つと必ず遭遇するだろう。関連株式コード：ベアークシル (Berkshire)\n本文 一部株式コードの名称に . やその他の特殊文字が含まれている場合、それを盈透 (IB) に報送する際に、株式コード名の変換が必要となります。\nBRK/B -\u0026gt; BRK B\n本文 盈透証券の場合、分析が可能で、変換のルールは固定されているため、コード実装で実現できます。ルールが固定されていない場合は、通常システム内部で対応するマッピング関係を保存し、ビジネスオペレーション担当者が定期的に更新します。\n参照リンク Berkshire Hathaway Class B Shares のシンボルを TWS に入力する方法は？\n","date":"2021-08-30","language":"ja","permalink":"https://ttf248.life/ja/p/interactive-brokers-stock-code-format-explanation/","tags":["ib","エイトリ証券 (Eitori Shoken)"],"title":"盈透证券株式コード特殊フォーマット説明 (Yingtousheng Guqu Code Tokubetsu Fomat Setsumei)","year":"2021"},{"categories":["メモ書き雑感"],"content":"人生のある段階で、人は迷茫に陥ることがあります。自分が本当に何を求めているのか分からず、仕事の日常に埋もれ、仕事の意味を追究しなくなってしまうのです。卒業した頃を回想すると、胸には熱い憧憬が溢れていました。あの頃の私は、毫不犹豫にこう言いました。「コードを書くことを望んでいる。人々を驚かせる、超絶なコードを。」しかし、今の仕事では、より多くの時間をビジネスレベルの問題に取り組み、その多くは業界発展に伴う恩恵によるものです。\n生活観については、結婚や出産、家を持つのといったことを自分の考えに入れていません。頭の中にはほとんど何もありません。ただ今を楽しみます。週末になると、静かにゲームをするのが好きで、よく一日中家にこもり、自分の小さな世界に浸っています。\n人生は、結局は自分が愛し、全力を尽くせる何かが必要なのです。\n住宅購入 前々年（まえまえねん）から、自分だけの家を買うために貯金を努力していました。毎日、その目標のために細かく計算をしていました。しかし、住宅価格が相変わらず上昇していくのを見て、最初は不安や不満でしたが、最終的には麻痺（まひ）してしまい、たとえ家を買っても、ただ自分に重い荷（かば）を背負うだけだと感じて、その考えを諦めました。\n貯金 当初，存钱是为了实现一些小目标，比如组装一台性能强劲的台式机、购买一直心仪已久的相机，或是来一场说走就走的旅行。但现在，我以一种更随意的态度对待存钱这件事，在日常开销上不再有太多顾虑，看到想吃的东西就去吃，对新奇的事物也能大胆尝试。\n貯金は、当初はちょっとした目標のために行っていた（例えば、高性能なデスクトップPCを組んだり、ずっと欲しかったカメラを買ったり、気軽に旅行に行ったりすること）。しかし、今はもっとリラックスした態度で貯金をしている。日々の生活費には気を遣うことが少なくなり、食べたいものは思いついたら食べるし、面白いものを見つけたら遠慮なく試すことができるようになった。\n帰宅 ついに、自分の心の奥底で一番願っていたのは、ただ故乡へ帰って様子を見ることだった。特に何か特別なことをする必要もない。ただ、あの馴染みの場所に帰り、家という温かさや静けさを感じてみればいいのだ。\n","date":"2021-08-26","language":"ja","permalink":"https://ttf248.life/ja/p/lost-and-confused/","tags":["人生 (じんせい / jinsei)","戸惑い"],"title":"困惑している / 悩んでいる / 迷っている","year":"2021"},{"categories":["金融知識データベース"],"content":"金融市場が絶えず変化する中、投資家たちは投資収益を増やすために、より効果的な投資ツールを模索し始めています。投資家のニーズに応えるため、香港取引及決済所有限公司（香港交易所）は、香港証券取引所に上場している株式先物合約のシリーズを発表しました。これらの合約に代表される株式は、香港交易所の全資傘会社である香港聯交所（連教所）で流通量が高く、取引も活発です。株式先物を投資することで、個別企業の業績に加え、デリバティブ市場が提供するショートセリングやレバレッジ効果などの利便性も享受できます。\n株式先物が代表する株式は、その業界の主要企業であるため、投資家は特定の産業のパフォーマンスが全体的な株式市場よりも優れているか劣っていると判断した場合、それに対応して当該産業の株式先物を選択することができます。\n基本定義 先物契約は、将来の特定日に特定価格（清算値）で買いまたは売り、その価格に相当する一定数量（契約単位）の金融価値を取引する買売り合約です。 すべての株式先物契約は現金決済で行われ、満期時に株式の納品はありません。\n合約満了 契約満了時、受託価格と最終清算価格の差額に合約倍数を掛けた金額が、受託者の預金口座に控除されます。 最終清算価格とは、関連する株式が最終取引日の終値としてシンジカ所の公式発表した価格を指します。 株式 futures の投資家が契約満了前に建玉を決済したい場合、元々ショートポジションを取っていた投資家は、単に１枚の期货合约を購入すれば良いだけであり、ロングポジションを取っていた投資家は、１枚の期货合约を売却する必要があります。\n担保金 先物取引を行う際、買い手と売り手双方には、契約履行の保証として、それぞれ一定額の基本保証金を納付する必要があります。決済所在は、各日の始末後、未決済の先物を市場価格で損益を計算し、投資家の保証金口座から控除する根拠とします。市場が悪化し、投資家が損失を被り、その結果保証金が指定水準を下回った場合、取引所は投資家に指定された期間内に追加資金を充当させ、保証金を元の基本保証金水準（つまり追加購入）に維持するように求めます。\nメリット 取引手数料が安い：各株式先物契約は数千株に相当し、売買契約の委託手数料は枚数によって変動するため、相対的に契約価値に対するコストは非常に低い。 空売りが容易：投資家は株式先物を簡単に空売りできるため、暴落時に空売りすることで利益を得ることができる。 庄協議施：市場の流動性を確保するために、香港証券取引所は市場の庄家に対し、指定されたスプレッド範囲内で買い価格と売り価格を同時に提示させ、株式先物市場の流動性を維持する。 レバレッジ効果：投資家は株式先物契約の売買に、契約価値の少部分のみの保証金を支払うことができるため、ヘッジや取引がコスト効率的に行える。 海外投資家の為替リスクを軽減：株式先物は海外投資家が質の高い国内株式への投資手段を提供し、売買契約の保証金のみを支払うことで、海外投資家が負担する為替リスクを大幅に軽減する。 電子取引システムによる取引：株式先物契約は、香港証交易所が所有する電子取引システムを通じて取引される。すべての注文は価格と時間の順で実行され、即座に買い値、売り値、成約価格が表示されるため、市場の透明度は最高水準にある。 決済会社による履行保証：株式先物契約は、香港証券取引所が所有する香港期货结算有限公司（決済会社）によって登録、決済され、履行保証を提供する。決済会社がすべての未決済契約の相手方であるため、取引参加者間は相手方リスクを負う必要がない。ただし、決済参加者は顧客に対する財務責任を保証しないため、投資家は经纪人を通じて取引する際には注意が必要である。 庄家制度 市場参加者または個別株式・商品先物の登録市場の庄家となり、指定された最大差金幅内で買い価格と売り価格を同時に提示します。取引所参加者およびその顧客は、個別株式・商品先物には市場庄家の登録による売買差金が提供されない場合があり、その売買が市場の取引単位に基づくことに注意する必要があります。投資家は、市場庄家が登録されていない株式・商品先物の売買には流動性リスクが伴う可能性があることを留意し、上場前に慎重に検討する必要があります。\n株式先物取引のリスク 株式先物はハイリスクな取引であり、株式先物を売買することによって生じる損失は、新規建倉時に納付した保証金を超える可能性があり、短期間にさらに保証金を支払う必要が生じる場合があります。支払いができず、保証金の差し押さえが行われた場合、貴方の持ち株やポジションは強制的に決済（平倉）され、その際の損失は全て貴方ご自身が負担することになります。したがって、株式先物取引のリスクを十分に理解し、ご自身の状況に合っているかどうかを慎重に判断する必要があります。取引を行う前に、ご自身の財政状況および投資目標を考慮し、ブローカーまたはファイナンシャルアドバイザーにご相談の上、株式先物およびオプション契約の購入が適しているか確認することをお勧めします。\nコメントの調整 倘正股公司以供股或派发红股等形式更改其股本结构，将会导致股价在除净权益时或生效日期时出现改变，而未平仓合约亦可以因而受到影响。 如果其他情况不变，股东持有的组合价值并不会再除净日改变，但对股票期货的买家或者持有人来说，情况则有所不同，除非期货合约中作出适当的调整。如果没有改变立约成价，而股票期货的合约乘数又保持不变，股价的调整将会对股票期货持仓的价值造成无理及不公平的影响。 结算所决定调整比率时，以维持期货合约的公平价值为原则，并只会在出现重大改变时作出调整。香港交易所会公布调整的详情，而交易所参与者需告知客户有关变化。\n株式先物契約概要 情報提供者コード 参考資料 香港交易所 - 衍生产品/个股/股票期货 HKEX_Stock_Futures_SC.pdf\n","date":"2021-08-18","language":"ja","permalink":"https://ttf248.life/ja/p/hong-kong-futures-basics/","tags":["先物"],"title":"恒生期貨の基本概念 (Kōsekki kyūka no kihon ganongō)","year":"2021"},{"categories":["魚の7秒間の見聞"],"content":"最近の2日間で株式市場は大幅に下落し、最近参入した新規投資家たちが市場のリスクを目の当たりにしました。中国は高齢化が進みつつあり、出生率は著しく低迷しており、関連専門家の予測を大幅に上回る低下が見られ、出生率のボトルネックとなっている業界に対して、我が党は強力な打撃を加えることになります。\n生徒减负 90年代生まれの私たちにとって、そうした多くの習い事や家庭教師のコース、放課後の自由な時間も制限されていませんでした。それは、まず家計の事情が許さないこと、そして当時の家庭教師がブランドイメージを確立していなかったことが理由です。親たちの信頼を得るためには、子供たちが自分の意思で選択し、自由に活動できる環境を提供することが重要でした。\nしかし、時を経て20年が経ち、2019年から始まったK12教育の資本化により、猿輔導などのオンライン家庭教師が次々と登場しました。資本の支援を受け、優秀なリソースを集めて様々なブランドの家庭教師コースが作られ、高額な費用も親たちの熱意を抑えきれませんでした。\n都市化の進展に伴い、多くの家長は学問を通じて貧しい出自から脱し、階級的な飛躍を実現してきました。自身が社畜として働く中で、子供たちに十分な時間を費やすことが難しく、自分自身もまた競争にさらされながら、子供たちが同世代に遅れを取ることを望めないのです。寒門出の貴子（高貴な出自の子）は存在しないため、適切な学歴を得ることができず、普通の家庭では、他の道で現在の階級を維持したり、再び階級を向上させたりすることは困難です。職業高校に進むことは、現在の社会環境において、階級の低下を許容できない多くの家長にとって受け入れがたい選択肢でした。\n学生負担軽減 なぜ課外家庭教師が必要なのか、保護者がなぜ課外家庭教師を必要とするのか、過去を見直してみましょう。教科書の内容や例題は、見ればすぐに理解できます。多くの科目は範囲が広く、内容は表面的なものであり、深く掘り下げていません。才能の選抜メカニズムにはある程度の差別化が必要です。そのため、試験問題が単に教科書の内容から出されるだけでは、選別効果を達成できません。横方向への拡張と縦方向への拡張が必要になります。これらの内容は、教師が授業中にカバーできない領域であり、その存在が課外家庭教師の育成の土壌を育んでいます。\nファイルには多くの内容が含まれており、30条の細則と規範が複数の側面を規定し、ガイドラインの概要は以下の通りです。\n全体的に宿題の量と時間を削減し、生徒の過剰な負担を軽減する 学校の放課後サービスレベルを向上させ、生徒の多様なニーズに対応する 厳格な管理を堅持し、校外トレーニング行為を全面的に規範化する 教育・指導の質を大幅に向上させ、生徒が学校内で十分に学び、良い成績を取れるように保障する 配達的な管理を強化し、支援・保障能力を高める 注意深く組織的に実施し、実効性のある成果を達成することを確実にする 菁英教育 教育業界において、近年、優秀な私立中学校が増加しており、公立学校の質の高いリソースが不足している（派生学区問題）という現象も見られます。様々な規模の教育グループが、高額な給与待遇で優秀な教師を惹きつけ、質の高い学習環境を構築し、徐々に独自のブランドを確立しています。中でも最も有名なのが衡水模式です。地元の中小企業は平均3千人を超え、優れた私立小学校では学年費用が9千～1万ドルに達します。教育グループは健全なサイクルを形成しており、「高い学費だが教師が優秀で、生徒の成績が良いから学費を高め、親は依然として子供をここに送ってくる」という状況が続いています。公立学校のリソース（教師）も徐々に私立学校に引き寄せられ、最終的には劣悪な教育の代名詞となっています。\n算法搾取 有データが示すように、美団に契約している配達員はほぼ400万人に達し、活発な配達員は約45万人です。多くの人々がこの仕事に依存して家族を養い生活しています。アルゴリズムによる絶え間ない搾取により、配送時間は限界を超えていき、人間は測定可能な単位に換算され、アルゴリズムの中で計算され、配達員の崩壊境界線を不断に探求されます。自分たちは非常に賢明だと考えていますが、人性にあたたまらず、資本のために奉仕する。市場がここに存在し、皆で楽しく、持続可能な遊びをすれば良いのです。しかし、独占や特権、資本主義のやり方のように、無秩序かつ蛮横な成長は必ず終わりを迎えるでしょう。\n株式市場の変動 2021年7月24日、新東方を代表する教育株が華麗なパフォーマンスを見せ、米国市場の前場好調な流れに続き、株価は半値まで暴落。\n我国は徐々に高齢化が進み、様々な計画外出生を引き起こす社会現象は取り締まらなければならず、独占的・残業を繰り返すインターネット企業への罰金も科され、資本が集まる教育業界も規制の対象となった。\n株価変動 教育業界が資本化されることを許されない。一票によって関連業界が上場資金調達を行うことが否定され、悲鳴が絶えない。\n腰斩的新东方 (腰斬の新東方) 暴跌的美团 (暴落の美団) 参考リンク 規制強化によるオンライン教育の急激な「減速」 国务院办公厅が、義務教育段階における生徒の宿題負担と外部研修負担に関する意見を发布\n","date":"2021-07-28","language":"ja","permalink":"https://ttf248.life/ja/p/capital-monopoly-and-the-fall-of-online-education/","tags":["新東方 (Shin Tōhō)"],"title":"資本の独占とオンライン教育業界の終焉","year":"2021"},{"categories":["コンピューター"],"content":"システム安定性テストを行うための、システムを破壊するパターン。\n本文 国内的互联网行业总是喜欢折腾点新东西出来，有时候听到个名词，一般人都想不到它是什么东西？\n看了部分文章，还是这段针对混沌工程初期的定义，较为容易接受：\n混沌工程的早期探索，其实在行业内一直有，曾经是以故障测试、容灾演练等身份存在。而随着微服务架构的不断发展，以及分布式系统的不断庞大，混沌工程开始崭露头角，越来越被重视。当 Netflix 正式提出混沌工程概念后，相关理论也开始飞快丰富。Netflix 的实践也证明了混沌工程在稳定性领域所带来的巨大意义。\n参照リンク ByteDance 混沌工程実践まとめ\n","date":"2021-07-28","language":"ja","permalink":"https://ttf248.life/ja/p/chaos-engineering/","tags":["カオスエンジニアリング"],"title":"混沌エンジニアリング","year":"2021"},{"categories":["コンピューター"],"content":"デプロイメントコントローラは、Kubernetesクラスタにおいて非常に重要な機能であるPodの水平スケーリングと縮小を実現します。これは従来のクラウド時代プラットフォームが必須とする能力です。\nあるビジネスシーンで、データベース内のデータを修正する必要があり、修正後にPodノードを再起動します。しかし、Podが実行中に表のフィールドを継続的に変更する必要があるため、一時的にアプリケーションによるテーブルへの更新を停止し、データ修正後にPodを復旧する必要があります。\n削除以外の方法で、同様に一時停止の効果を実現する方法はありますか？\nkubectl scale --replicas=0 deployment/\u0026lt;your-deployment\u0026gt; 回答を見る前に、多くの人が直接プロセスを操作する時代に思い当たり、ビジネスプロセスの直接操作を考えてしまうかもしれません。\n参照リンク Kubernetesでポッドを停止/一時停止する方法\n","date":"2021-07-12","language":"ja","permalink":"https://ttf248.life/ja/p/kubernetes-pause-pod/","tags":["kubernetes"],"title":"KubernetesでPodが停止しました。","year":"2021"},{"categories":["投資 (tōshi)"],"content":"90年代生まれの私たち世代にとって、08年の金融危機は、ほとんど感覚を伴わなかった。なぜなら、当時まだ若く、投資や資産運用といった理財の知識も身につけていなかったからだ。2015年に起きた牛市（うしじ）は、その勢いが凄まじく、終焉を迎える際にも大きな騒ぎとなった。最終的には国家が市場を救済に出たことで落ち着きを見せた。この頃に、基金という概念が一般の人々の目に触れるようになったのである。\n蚂蚁金服と支付宝 支付宝は、その天然のトラフィックインポートとして、蟻（アンチ）グループの下位に生まれた時点で決済ツールとしての位置づけを確立しました。支付宝は、微信と同様に投資ファンドを購入し、ほとんどの人々が支付宝を選択しました。また、支付宝は投資ファンド販売を単なる買い物に変えることに成功しました。2019年以降始まった小牛市（ショーニイシ）において、基金マネージャーの集団暖房、結局のところ、それがパンデミックによる通貨の大規模放出によって引き起こされたものです。入場した人はすべて利益を得て、入場しなかった人は羨望の眼差しを向け、急いで入場しました。新ファンド規模が百億元を超える速度がますます加速しており、マザーズ世代が投資を開始するシーンにおいて、数兆円規模のファンドもすぐそこまで来ているでしょう。\nインターネット基金販売プラットフォームが蟻（アンチ）をコードとする形で爆発的な人気を博す以前、平明百姓が投資ファンドに触れるのは、銀行で貯金をする際に、ブースターが熱心にさまざまな金融商品を紹介してくれる場面でした。インターネットの包装やプロモーションページの情報ガイダンス、投資ファンド販売機関が提供する高額な広告費が、支付宝が提示した投資ファンド広告を完全に非合理的なものに変えました。\n通常の銀行定期預金利回り4％、以前は非常に過熱していたP2P投資で8％、クレジットカード還款利息12％です。当社の主人公である支付宝が宣伝する投資ファンドは150％、250％と市場を席巻し、市場内では誰もが喜びました。市場が下落した場合？それは支付宝が火遊びをしているに等しい。提示されたリターンのデータには、最近3年間の収益グラフのみが表示され、伝統的な投資ファンドは年平均収益のみが表示されます。なぜ単独で毎年の平均収益を表示できないのでしょうか？それは計算が難しいからでしょうか？答えは否定です。なぜなら、そのデータは顧客の投資ファンド購入を誘導するのに適していないからです。\n固定收益理财 中国尚未步入负利率时代，银行存款、国债是最为稳妥的固定收益产品；纯债基金也是不错的选择。中国的平均工资多少，各位自行查阅各地统计局公布的数据即可。 笔者写个简单的场景：资产规模200万，年化收益4%折算，每年的收益都超过了大部分城市的平均工资。\n跋談 これは個人的な経験に基づいたもので、書けることはたくさんある。もっと深く知りたい場合は、経済に関する書籍を色々読んでみることをおすすめする。盲信するようなことはしない方が良い。普通の家庭における資産形成の核心は保全であり、火事を起こして夢のような富を築こうとするのではない。\n曽我伯がいつも言う言葉がある：\n適切なタイミングで適切な行動をとれば、価値は最大になる；勉強しているときは真面目に勉強し、良い学位を得る方が、チラシ配いでアルバイト代を稼ぐよりもずっと良い；就職したら真面目に働くことで、給与の伸び幅が豊かな報酬をもたらしてくれる；家を持ったら、家を守ることを学ぶ必要がある。\n終わりに 興味のある方は、ぜひこちらの講演原稿をご覧ください。「時の流れについて」というテーマで、多くの書籍を読み込むことの大切さを説いています。原文のテキストファイルは当サイトにてご用意しております。\n","date":"2021-07-09","language":"ja","permalink":"https://ttf248.life/ja/p/funds-and-fixed-income-wealth-management/","tags":["ファンド","ストックホルム現象 (Stockholm phenomenon)","投資 (tōshi)"],"title":"ファンドと固定資産運用","year":"2021"},{"categories":["金融知識データベース"],"content":"金融ソフトウェア開発の5年目であり、最も取引するものが交易所とのインターフェースドキュメントである。慣れ親しんでいるのは香港証取引所のドキュメントであり、最近では中国通業務を処理することになり、一部の中国通業務に関連して、深セン証取引所および上海証取引所の資料も参照した。\n香港交易所 公式サイト\n常用 取引時間、取引および決済カレンダー 取引メカニズム 中広金融用語対照表 滬港通および深港通取引カレンダー PDF 滬港通および深港通取引カレンダー CSV 中広金融用語対照表 PDF 市調メカニズム冷静期トリガー記録 証券リスト：基本情報、証券分類 閉会競売取引時間帯証券 市場変動調整メカニズム（市調メカニズム）証券 短売り対象指定証券 証券リスト：基本情報、証券分類 XLSX 行情インターフェースドキュメント：香港株式 + 中華通 行情インターフェースドキュメント概要リンク よくある質問と解答、開発マニュアルの参照、過去の行情インターフェースドキュメントは検索バーからダウンロードアドレスを取得できます。バージョン履歴を検索してください。\n香港株式行情インターフェースドキュメント 中華通行情インターフェースドキュメント HKEX_OMDC_Binary_Interface_Specifications_v_1,-d-,32c.pdf HKEX_OMDC_Developers_Guide_1_11.pdf OMDC_Connectivity_Guide_Securities_Market-Index_datafeed(v2_2).pdf OMD_Interface_Specification_China_Connect_Securities-(v1-3).pdf OMD_Connectivity_Guide_China_Connect_Securities.pdf OMD_Developers_Guide_China_Connect_Securities.pdf 報盤インターフェースドキュメント：港股 + 中華通 報盤インターフェースドキュメント集約リンク\n港股FIXプロトコルインターフェースドキュメント PDF 港股二級制プロトコルインターフェースドキュメント PDF 港股取引所エラーコードリスト XLSX 中華通FIXプロトコルインターフェースドキュメント PDF 中華通二進制インターフェースドキュメント PDF 上交所 行情報盤インタフェースドキュメント エラーインターフェースドキュメントは、他のメニューで取得できます 報盤エラーインターフェースドキュメント XLSX\n深谷証券取引所 行情報盤インタフェースドキュメント 深谷証券取引所は、個別のエラーメッセージを提供していません。報盤インタフェースドキュメントの第6章に補足説明があります。 深圳证券交易所Binary取引データインターフェース規範（Ver1.18）PDF\nニューヨーク証券取引所 休場スケジュール 新規上場情報 終値 グローバル市場の終値\n","date":"2021-01-27","language":"ja","permalink":"https://ttf248.life/ja/p/exchange-interface-documentation/","tags":["hkex","香港証券取引所 (Hónggū zhèngquán qìyuēsuǒ)","中華通","上海証券取引所 (Shanghai Stock Exchange)","東京証券取引所 (とうきょうしょうけんとりひきよ)","ニューヨーク証券取引所 (Nyuu Yookuu Shoquun Torihajo)","APIドキュメント"],"title":"取引所インターフェースドキュメント集約","year":"2021"},{"categories":["コンピューター"],"content":"長年携わってきたのは CentOS オペレーティングシステムであり、mac ユーザーや Ubuntu ユーザーの場合、一部の内容は適用できない。 インストールに関する部分は、清華大学のドキュメントを参照するのが参考になる：https://mirrors.tuna.tsinghua.edu.cn/help/docker-ce/\nインストール 未知の神秘的な力により、国内でのDockerのインストールには、クラウドプロバイダーが提供するレジストリのアドレスを設定することを推奨します。ここではAlibaba Cloudを使用することをお勧めします。\nリポジトリソースの設定 yum install yum-utils device-mapper-persistent-data lvm2 \u0026amp;\u0026amp; \\ sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 最新版のインストール Dockerは一般的なバックエンドサービスとして、起動時に自動で開始されるように設定することを推奨します。以下のコマンドはCentOS 7向けです。\nsudo yum install -y docker-ce docker-ce-cli containerd.io \u0026amp;\u0026amp; systemctl enable --now docker 指定バージョン展開 kubernetesおよびdockerのリリースは完全に同期されておらず、今後kubernetesを展開する場合は、kubernetes展開手順を参照し、指定バージョンのdockerをインストールしてください。\nyum list docker-ce --showduplicates | sort -r sudo yum install -y docker-ce-18.09.2-3.el7 docker-ce-cli-18.09.2-3.el7 containerd.io-18.09.2-3.el7 \u0026amp;\u0026amp; systemctl enable --now docker 通常ユーザーにDocker権限を追加する sudo usermod -aG docker ${USER} 卸載 sudo yum remove -y docker-ce docker-ce-cli containerd.io 日常使用 (にちじょうしよう) 镜像加速 未知の神秘的な力により、イメージの取得時に速度が低下することがあります。この問題を解決するために、国内のクラウドプロバイダーが多くの加速サービスを提供し、引き続き阿里云を推奨します。\n加速用のURLは、ご自身の登録した阿里云アカウントで取得してください。このサービスは無料で利用でき、阿里云からは無料のイメージ構築サービスも提供されています。\ncat \u0026gt; /etc/docker/daemon.json \u0026lt;\u0026lt;EOF { \u0026#34;registry-mirrors\u0026#34;: [ \u0026#34;https://docker.nju.edu.cn\u0026#34;, \u0026#34;https://mirror.baidubce.com\u0026#34;, \u0026#34;https://docker.m.daocloud.io\u0026#34;, \u0026#34;https://docker.mirrors.sjtug.sjtu.edu.cn\u0026#34; ] } EOF systemctl daemon-reload \u0026amp;\u0026amp; \\ systemctl restart docker 強く推奨されるコントロールパネル docker volume create portainer_data \u0026amp;\u0026amp; \\ docker run -d --name=portainer --restart=always -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:2.20.3-alpine 常用イメージの取得集 docker pull rancher/rancher:stable \u0026amp;\u0026amp; docker pull portainer/portainer-ce:2.0.1 \u0026amp;\u0026amp; \\ docker pull centos:7 \u0026amp;\u0026amp; docker pull ubuntu:20.04 \u0026amp;\u0026amp; docker pull ubuntu:18.04 \u0026amp;\u0026amp; \\ docker pull redis:5 \u0026amp;\u0026amp; docker pull redis:6 \u0026amp;\u0026amp; \\ docker pull alpine:3.11 \u0026amp;\u0026amp; docker pull busybox:1.32 \u0026amp;\u0026amp; \\ docker pull rabbitmq:3.7-management \u0026amp;\u0026amp; \\ docker pull mariadb:10.2 \u0026amp;\u0026amp; \\ docker pull nginx:1.18 \u0026amp;\u0026amp; docker pull nginx:1.19 \u0026amp;\u0026amp; \\ docker pull mysql:5.6 \u0026amp;\u0026amp; docker pull mysql:8 \u0026amp;\u0026amp; \\ docker pull elasticsearch:6.8.11 \u0026amp;\u0026amp; docker pull logstash:6.8.11 \u0026amp;\u0026amp; docker pull kibana:6.8.11 \u0026amp;\u0026amp; \\ docker pull zookeeper:3.4 \u0026amp;\u0026amp; \\ docker pull influxdb:1.7 \u0026amp;\u0026amp; docker pull grafana/grafana:7.3.1 \u0026amp;\u0026amp; \\ docker pull percona:8 \u0026amp;\u0026amp; docker pull percona:5.6 \u0026amp;\u0026amp; \\ docker pull cloverzrg/frps-docker:0.34.3 \u0026amp;\u0026amp; docker pull cloverzrg/frpc-docker:0.34.3 常用コマンドの組み合わせ https://docs.docker.com/engine/reference/commandline/docker/\nコンテナの実行状態を確認し、formatパラメータを追加して詳細なコンテナ情報を取得（イメージ情報は無視）。\ndocker ps --format \u0026#34;{{.Names}}: {{.Ports}}: {{.Size}}\u0026#34; #portainer: 0.0.0.0:8000-\u0026gt;8000/tcp, 0.0.0.0:9000-\u0026gt;9000/tcp: 0B (virtual 172MB) #influxdb: 0.0.0.0:8086-\u0026gt;8086/tcp: 183B (virtual 311MB) すべてのコンテナをワンクリックで停止\ndocker stop $(docker ps -a -q) すべてのイメージをワンクリックで削除\ndokcer rmi $(docker images -a -q) イメージのエクスポート\ndocker save \u0026lt;IMAGE NAME\u0026gt;:\u0026lt;IMAGE TAG\u0026gt; \u0026gt; -o XXX.tar イメージをエクスポートして圧縮\ndocker save \u0026lt;IMAGE NAME\u0026gt;:\u0026lt;IMAGE TAG\u0026gt; | gzip \u0026gt; XXX.tar イメージをインポート\ndocker load -i XXX.tar ","date":"2021-01-21","language":"ja","permalink":"https://ttf248.life/ja/p/docker-two-three-things/","tags":["docker","linux","centos"],"title":"Dockerの基礎を理解するための３つのポイント (または、Dockerの基本を理解するための３つのこと)","year":"2021"},{"categories":["コンピューター"],"content":"著者はハードウェアに強い関心を持ち、JMeterを用いて負荷テストを実施し、CentOS 7上にJMeter、InfluxDB、Grafanaをデプロイするプロセスを記録しました。JMeterのインストールとコマンドの使用方法、InfluxDBの特徴とDockerによるインストール方法、Grafanaの簡易的なデプロイと設定について共有しています。高性能プログラムモードに関する経験や参考資料をまとめました。\n背景 広く知られているように、私にはハードウェアに対する強い関心が持っており、テストグループが JMeter を使用して負荷テストを行っている際に、パフォーマンスが向上しないことを発見しました。好奇心旺盛な私は、会社の負荷テストの方法を試してみることに決意しました。また、ある頃合いにオープンソース中国で、より洗練された高性能のパフォーマンス測定グラフを作成する方法に関する投稿を読んだことがあります。Windows版でのテスト実行時に、可視化された TPS データの表示を実現しており、Webパネルを設定することでどのような効果があるのか疑問に思っていました。\n頭の中で思いついたのは、当然のことばかりです。実際に試してみないとしかたないことを理解します。 負荷テストには GUI モードを使用しないでください！ テスト作成とデバッグのみに使用してください。\n背景 公式推奨は、コマンドラインで負荷テストレポートを取得し、GUIで表示する方法ですが、データに誤差が含まれているという問題があります。JMeterの理解が十分ではないため、少なくともLinux版のコンソールパネルを弄り転げる理由を見つけたいと思います。\n開かれた中国（オープンチャイナ）の投稿では、コアコンポーネントのデプロイメント方法があまりにも友好的ではなく、インストールに必要なファイルは公众号を通じてダウンロードする必要があり、現代的な若者として、もちろんDockerで代替します。要するに、サーバーは国内であり、国境を越えたソースアドレスへのアクセス速度が遅いため、少なくともイメージサービスとしては、阿里云には無料の加速があります。\ndocker のインストールとデプロイメントについては、ここでは詳細な説明を省略し、以前の記事を参照してください。\n次の内容は、2つの主要な領域に分かれています：基本的なテスト環境コンポーネントの構築、および各コンポーネントの簡単な認識の説明\nJMeter Apache JMeterはApache組織が開発したJavaベースの負荷テストツールです。ソフトウェアに対する負荷テストに使用され、当初はWebアプリケーションのテスト用に設計されましたが、その後、他のテスト分野にも拡張されています。静的および動的なリソース（静的ファイル、Java小型サービスプログラム、CGIスクリプト、Javaオブジェクト、データベース、FTPサーバーなど）をテストするために使用できます。JMeterは、さまざまな負荷カテゴリからの巨大な負荷をシミュレートして、それらの強度をテストし、全体的なパフォーマンスを分析するために使用できます。さらに、JMeterはアプリケーションの機能/回帰テストに使用でき、断言を含むスクリプトを作成することで、プログラムが期待どおりの結果を返していることを検証します。最大限の柔軟性のため、JMeterは正規表現を使用して断言を作成することを許可しています。\nApache jmeter は、静的および動的なリソース（ファイル、Servlet、Perlスクリプト、Java オブジェクト、データベースとクエリ、FTPサーバーなど）のパフォーマンスをテストするために使用できます。 サーバー、ネットワーク、またはオブジェクトに過剰な負荷をシミュレートして、それらの強度をテストしたり、さまざまなストレスタイプの下での全体的なパフォーマンスを分析したりすることができます。 大規模な同時負荷テストでサーバー/スクリプト/オブジェクトのパフォーマンスを分析したり、グラフィカルなパフォーマンス分析を行ったりするために使用できます。\nJmeter 導入 CentOS7 JDK の実行環境をインストールし、JMeter のインストールパッケージをダウンロードします。\nyum install java-1.8.0-openjdk -y \u0026amp;\u0026amp; \\ wget https://mirrors.bfsu.edu.cn/apache//jmeter/binaries/apache-jmeter-5.4.tgz \u0026amp;\u0026amp; tar -xf apache-jmeter-5.4.tgz 環境変数を設定します。\nexport JMETER_HOME=$HOME/jmeter/apache-jmeter-5.4 export PATH=$JMETER_HOME/bin:$PATH JMeter コマンド 最後に Grafana ダッシュボードに送信し、-l パラメータを入力しなくても、web コンソールでデータを観察できます。\njmeter -n -t /tmp/order-500-10s.jmx -l /tmp/jmeter-order-report-20200109/order-500-10s.jtl # 通常、テスト結果とテストレポートは省略し、コマンドを簡略化します。 jmeter -n -t /tmp/order-500-10s.jmx InfluxDB InfluxDBは、Go言語で記述されたオープンソースの分散型時系列、イベント、指標データベースです。外部依存なしで動作します。このデータベースは現在、大量の時間スタンプデータ（DevOpsモニタリングデータ、APPメトリクス、IoTセンサーデータ、リアルタイム分析データなど）を保存するために主に利用されています。\nInfluxDBの特徴 InfluxDBの特徴は、以下の9点にまとめられます。\n非構造化（非モデリング）：任意の数の列を含めることができます。 メトリクスの保存期間を設定できます。 時間に関連する関数（min、max、sum、count、mean、medianなど）をサポートし、統計分析が容易です。 ストアポリシーのサポート：データの削除および変更に使用できます。（InfluxDBはデータの削除と変更の方法を提供していません。） 連続クエリのサポート：データベース内で自動的にスケジュールされたステートメントのセットであり、ストアポリシーと組み合わせてInfluxDBのシステム使用量を削減できます。 ネイティブなHTTPサポート、組み込みHTTP API。 SQLライクな構文をサポート。 クラスタ内のデータのレプリカ数を設定できます。 定期的なサンプリングデータによる別の測定項目の書き込みをサポートし、粒度ごとのデータを保存できます。 InfluxDB Docker インストール mkdir influxdb \u0026amp;\u0026amp; cd influxdb \u0026amp;\u0026amp; \\ docker run -p 8086:8086 -d --name influxdb -v $PWD:/var/lib/influxdb influxdb:1.7 docker exec -it influxdb /bin/bash でコンテナに入り、コマンドを実行し、手動でデータベースを作成\nroot@bce0a55bbc72:/# influx http://localhost:8086 への接続、バージョン 1.7.10 InfluxDB シェル バージョン：1.7.10 \u0026gt; 対話式パネルでコマンドを実行 InfluxDBデータベースとユーザーの作成 データベースの作成: create database jmeter_t2 データベースの表示: show databases データベースの切り替え: use jmeter_t2 ユーザーの作成: create user \u0026quot;admin\u0026quot; with password 'admin' with all privileges ユーザーの表示: show users\n\u0026gt; show users user admin ---- ----- admin true ユーザー権限がadminでtrueと表示されれば、データベースの準備は完了です。\nGrafana テストケースの作成時に、グラフによる表現はあまり必要ないことがわかりました。インターフェースの tps データのコマンドライン実行で十分観測できます。むしろ、プログラム内部の処理時間を確認したいと考えています。\nGrafana の簡易的なコンソールパネルをデプロイし、InfluxDB と連携するための設定ファイルをインポートします。\nコンソールはラベルによるフィルタリングをサポートしており、通常は 1 つの InfluxDB データベースを設定するだけで済みます：\nアプリケーション名 テストケース名 docker run -d --name=grafana -p 3000:3000 grafana/grafana:7.3.1 ブラウザ版ではサンプリング間隔により、計算された TPS や関連数値が JMeter の集計レポートと一致しないため、参照リンク：https://www.vinsguru.com/jmeter-real-time-results-influxdb-grafana/ を参考にしています。\n資料には、リスナーのカスタム設定方法も記載されています。\n付録 高性能のプログラムパターンは、必然的にone loop threadであるべきであり、ロック、入隊列、出隊列などのものは、不必要なパフォーマンス損失を引き起こす 核心ビジネスロジックの実行時間が、他のコードを導入する時間よりも大きい場合のみ、並行処理が有効に効率を向上させることができ、コアな実行時間が十分に小さい場合は、慎重に他のコードを導入すべき 参考資料 JMeterシリーズのJMeter+Grafana+InfluxDB リアルタイム監視 influxdb 公式イメージ grafana 公式イメージ JMeter 公式サイト CentOS7にApache JMeterをインストールする方法 ","date":"2020-12-22","language":"ja","permalink":"https://ttf248.life/ja/p/linux-setup-jmeter-testing-environment/","tags":["linux","jmeter","負荷テスト (Yōki tesuto)","docker"],"title":"LinuxでJMeterの負荷テスト環境を構築する","year":"2020"},{"categories":["コンピューター"],"content":"オンラインプロ덕ション環境のオペレーティングシステムとして、Red HatとCentOSが主流の選択肢です。2つのシステムのライフサイクルに関する公式サイトへのリンクを記録し、CentOS 8からCentOS 8 Streamへのアップグレード経験を共有しています。\nはじめに オンプレミス（本番環境）のオペレーティングシステムですが、現在の国内環境においては、Red HatとCentOSが主流の選択肢です。2年前にはRed Hat 6のEOL（End of Life）を迎えたため、両システムのライフサイクルに関する公式ウェブサイトへのリンクを記録します。\n正文 Red Hat Enterprise Linux 生命周期 CentOS 产品规范 Red Hat Enterprise Linux（RHEL）および CentOS は、エンタープライズ向けの主要なサーバーオペレーティングシステムです。RHEL は安定したサポートと更新サイクルを提供し、エンタープライズアプリケーションに適しています。CentOS は RHEL のコミュニティ版であり、同様の機能と安定性を提供しますが、公式なサポートはありません。\n追記 この記事を執筆した時点では、2年後に自分が更新することなど想像もしていませんでした。先日、普段使っている仮想マシンをCentOS 8からCentOS 8 Streamにアップグレードしました。本番環境で何を選ぶかは、お話するのが難しいので、ここでは触れません。ローカル環境は最新版を追求します。\nCentOS 8 Streamは、従来のCentOSよりも迅速なアップデートと新機能を提供する、継続的リリース版であり、開発やテスト環境での利用に適しています。\n","date":"2020-07-21","language":"ja","permalink":"https://ttf248.life/ja/p/redhat-centos-lifecycle/","tags":["linux","centos","redhat"],"title":"Red Hat と CentOS のライフサイクル","year":"2020"},{"categories":["魚の7秒間の見聞"],"content":"まず、少し話題を外しますが、中国特色社会主義と資本主義の違いについてです。先輩たちの口から「儲かるためにはまず道路を整備する」という言葉を聞いたことがあります。中国のインフラ建設は国家が資金を出しており、資本主義社会ではこれらのものが請負業者に委託され、偏遠な地域には利益がなく、企業が引き受ける気になれません。これは少し長くなりすぎて、現在の議論から逸脱してしまいますが、一般的には貿易戦争が生活に大きな影響を与えないと感じるかもしれませんが、実際には中国のハイエンド製造業は依然として脆弱です。私が従事しているIT業界では、メモリ、ハードディスク、CPU、グラフィックカードといった構成要素は、海外の工場からのものであり、これらの部品費用の分だけでも全体の価格の50%を占めています。ハイエンド製造業が不可欠であることは言うまでもありません。中国とアメリカの衝突は避けられないのです。\n参考文献 2018年中美贸易战 中国制造2025 ウィキペディア 2018～2020年中美貿易戦争（通称：米中貿易戦争、英語：China–United States trade war）は、中華人民共和国とアメリカ合衆国との間の貿易戦争であり、以下のような内容を含む。\n貿易争端は、2018年3月22日にトランプ大統領が覚書に署名した際に、「中国がアメリカの知的財産および商業秘密を盗み取っている」と主張し、1974年の貿易法第301条に基づき、中国からの輸入品に対する関税を課すことになった。対象となる商品の総額は600億ドルに達した。2018年7月6日には、340億ドルの中国製品に対して25%の追加関税が課せられた。中国側もこれに対し、340億ドルのアメリカ製品に対する25%の追加関税を課した。その中には、アメリカへの輸出額が最も多い大豆が含まれていた。\n中美双方は一時的に2018年5月に貿易戦争の停戦合意に達し、和解に向けた共同声明を発表した。しかし、アメリカ貿易代表オフィス（USTR）は6月16日に、500億ドル相当の中国製品に対する課税リストを公表し、既存の10%関税を25%に引き上げた。中国側はこれに対し、等価な報復措置として、反倒銷調査を開始した。7月6日には、トランプ政権が最初の課税リストに含まれる340億ドルの中国製品に対して25%の関税を正式に適用し、トランプ氏による対中関税政策の実施が開始された（残りの160億ドルの商品は8月23日に25%の関税が適用された）。中国側は声明で、「アメリカはWTOの規則に違反し、史上最大規模の貿易戦争を始めた」と非難した。中国海関総署は、中国側の反撃措置は、アメリカ側の追加関税措置が発動した後即座に実施されたと述べた。\n12月1日には、G20ブエノスアイレス峰会で、習近平国家主席とトランプ大統領が90日間の交渉合意を達成し、交渉期間中は新たな貿易措置を追加しないことに合意した。2019年3月1日の期限までに、アメリカ側は「大幅な進展」があったとして、停戦措置の延長を発表した。\n2019年5月5日、トランプ大統領は、約2000億ドルの中国製品に対して25%の関税を課すことを発表し、6月1日から適用されることになった。5月13日には、中国国务院関税税則委員会が、6月1日から原産地アメリカ製の600億ドル相当の輸入品に対する関税を5～25%に引き上げることを決定した。6月1日には、USTRが、アメリカ側の25%関税の適用を6月15日に延期し、中国側は6月1日に関税措置が実施されると発表した。\n6月29日には、習近平国家主席とトランプ大統領がG20大阪峰会で会談を行い、経済磋商を再開すること、アメリカが中国製品に対する新たな関税を課さないことに合意した。\n8月1日には、トランプ政権が中国政府によるアメリカ農産物の購入の遅延に不満を持ち、ツイッター上で、2019年9月1日から3000億ドルの中国製品に対して10%の関税を課すと発表した。8月5日には、人民元/ドル相場が7円の大台（7.00）を割り込んだ。同日、アメリカ財務省は、中国を為替操作国に指定した。その後、中国政府はアメリカ農産物の購入を一時停止し、8月24日に約750億ドルのアメリカ製品に対する10%または5%の関税、およびアメリカ自動車とその部品に対する関税の再導入を発表した。アメリカ側は次日、3000億ドルの中国製品に対する税率を15%に引き上げ、現在の2500億ドルの中国製品に対する25%の関税を30%に引き上げたが、その後、この措置は保留された。\n2020年1月16日には、中国とアメリカで第一段階の貿易合意が署名された。\n","date":"2020-07-21","language":"ja","permalink":"https://ttf248.life/ja/p/us-china-trade-war/","tags":["貿易戦争 (Bōeki senso)","為替レート","製造業"],"title":"米中貿易戦争 (Bei-Chū Bōgyō Sensō)","year":"2020"},{"categories":["コンピューター"],"content":"著者は幼い頃からPCの組み立てに興味を持ち、大学卒業後に本格的にハードウェアの組み立てを始めました。彼は、CPU、SSD（ソリッドステートドライブ）、HDD（ハードディスクドライブ）やメモリのクロック周波数など、各パーツの性能比較サイトを紹介し、購入に関するアドバイスも行いました。また、ハードウェア選びでの経験談や注意点なども共有しました。\n縁・語り尽くせぬもの 幼い頃から、自分だけのコンピュータを組み立てたいと考えていた。しかし、経済的な条件が許さなかった。ようやく大学に上ると、持ち運びやすいため、構成したのはノートパソコンだった。もし具体的な時期を挙げるとすれば、自分が組立てることを思い始めたのは、故郷の図書館でさえあっただろう。毕竟これは市区レベルの図書館であり、電子閲覧室（実際にはほとんど行ったことがなく、時間課金制だという）や雑誌閲覧室（まさにここで『大众软件』、『电脑报』のような雑誌を読み、コンピュータにあまり触れていなかった私にとって、神に近い科普資料だった）があったからだ。打副本の章节を見て自分もコンピュータを組んで、モンスターを倒し、主力として出力することを考えたし、黒科技を見て本の内容通りに再現できると夢を見た（ハッキングツールの使用について）。もちろん高校では勉強が忙しく、当時の私の認知能力では、読書も遊びも両方楽しむ必要があった。そうした「天真爛漫」な日々を過ごし、図書館へ行くという由縁を作った。特に何もすることがない時、小さな袋を提げてそこへ向かい、市区はそれほど大きくなく、ほとんどが徒歩で図書館へ行った。到着すると空調の効いた部屋で小説、漫画、ゲーム雑誌を見たり、時には真面目な本も読んだりした。\n年を取ると忘れっぽくなるのが普通だ。図書館で生まれたものが初めだったのかもしれない。中学校の頃には、親戚がコンピュータを組み立てていたが、当初その機械は何に使われたのか覚えていない。オペレーティングシステムはWindows 2003で、ゲームは標準搭載のカード＋帝国時代があった。様々な「斗智斗勇」な考えで鍵を盗み、甥っ子と一緒にゲームをした。\n初等学校に入ると学校でコンピュータの基礎的なトレーニングを受けた後、転校し、コンピュータ競技会についても少し知識を得た。そして高校ではNOIPに合格した。ここで言及するのは、校友たちの力だ。高校のコンピュータ棟は校友たちからの寄付によって建てられたもので、コンピュータ教育室と図書館が含まれていた。これは当時、国内インターネット浪潮の初期の波だった。校長もコンピュータ競技会への参加を支援し、前2学年の先輩たちが数名、コンピュータを通じて重点大学に合格していたからだ。\nこれまでこのようなことを振り返ったことはなかった。そうはならないのは当然だろう。卒業後、私は自動化専攻を義無反顧的にコンピュータ業界に転身したが、種はすでに植えられていた。局中の人は自分の状況を知らないだけだった。幼い頃から多くのものに触れていたため、自分がとても優秀だと思っていたが、実際には表面的な知識しか持っていなかった。最大の強みは最初の情熱だった。\n硬件组装 PCバカ、chiphell、知乎のPC自作の板を逛逛し、萌新でも比較的簡単に自分に必要な機材リストを作成できます。2019年以降にCPUを選ぶ場合、経済的な条件が限られている場合は、より高い性能を得るためにAMDを優先的に選びます。 一般的なハードウェア性能比較サイトをご紹介します：https://cpu.userbenchmark.com/　価格に関しては、eBayの米版と咸鱼（中国版ヤフオク）で比較するのが良いでしょう。真の達人であれば、咸魚で中古品を探すことも可能です。大幅に安く購入できます。あまりPCに詳しくない場合は、咸魚は推奨しません。私は偽メモリを購入しましたが、現状使用しても問題がないようです。詳細は不明で、型番とパラメータが完全に一致していません。\nSN550 VS SN750 SN550とSN750の1TB容量の違いは、両者の継続的な読み書き速度が倍になることです。SN550では850MB、SN750では1.6GBですが、日常使用においては違いを感じられません。これは両者が4K性能において同じであるためです。もちろん、ここで言うSN550は1TB容量のものです。500Gや250Gの容量では、順応読み書き速度がより遅くなります。実際には、お金を惜しまないわけではない限り、日常使用であればSN550を購入するのが良いでしょう。私がこのモデルを選ばなかった主な理由は、その容量が最大1TBであることと、SN750が2TB容量を持つことです。私にとって、追加の拡張なしに、マザーボードのM.2 NVMeインターフェースの方がより価値があると感じたからです。\n総じて、ネットユーザーの結論として、B150のマザーボードでもM.2インターフェースに対応したSSDを導入することができます。\n机械硬盘選购 機械硬盘現在價格趨於穩定，對於有大量儲存需求的使用者，需要選購一款合適的機械硬盘，頻繁下載資源的使用者推薦企業級硬盘，常見的有：\n西數金盤 希捷Exos 大容量的機械硬盘推薦進行分区，頻繁的下載操作固定在某个分区進行，日後出現壞道，可以集中在某个分区，廢棄當前分区即可，能有效延長機械硬盘寿命。 希捷系列官方介紹 メモリ周波数 日常業務の観点から見ると、周波数はパフォーマンスに大きな影響を与えません。 メモリ時系列画像 咸鱼メモリ画像\nメモリ時系列（英語：Memory timingsまたはRAM timings）は、シリアル・ダイナミック・ランダム＝アクセスの記憶装置（SDRAM）のパフォーマンスを記述する4つのパラメータです。CL、TRCD、TRP、およびTRASで、クロックサイクル単位で測定されます。これらのパラメータは通常、破折号で区切られた4桁の数字として記述されます（例：7-8-8-24）。第4パラメータ（RAS）は頻繁に省略され、場合によっては5番目のパラメータであるコマンドレート（命令レート）が追加されることがあります。これは通常2Tまたは1Tで、2N、1Nと表記されます。これらのパラメータは、ランダムアクセスメモリの速度に影響を与える潜伏時間（遅延時間）を指定します。数字が低いほど、一般的にパフォーマンスは向上します。\nシステム性能を決定する最終的な要素は、実際の遅延時間です。これは通常ナノ秒単位で測定されます。\nメモリ時系列を実際の遅延時間に変換する場合、クロックサイクル単位であることに注意することが重要です。クロックサイクルの時間を知らない場合、2つの数字のセットがどちらがより速いかを判断することはできません。\nたとえば、DDR3-2000 メモリのクロック周波数は1000 MHzで、そのクロック周期は1 nsです。この1 nsのクロックに基づいて、CL=7 が与えられた絶対遅延は7 ns です。より高速な DDR3-2666（クロック 1333 MHz、各サイクルあたり 0.75 ns）では、より大きな CL=9 を使用できますが、生成される絶対遅延は 6.75 ns となります。\n現代の DIMM には、自動構成を推奨するシリアル存在検出 (SPD) ROM チップが含まれています。PC の BIOS は、パフォーマンスを向上させるためにユーザーがメモリ時系列を調整できるように（安定性にリスクがある）、または特定の状況で安定性を高めるために（推奨された時系列を使用するなど）許可することがあります。\n注：メモリ帯域幅は、メモリの透過量（スループット）を測定し、通常は転送レートによって制限されます。複数の内部バンクに並行して SDRAM にアクセスすることで、ピークレートで連続的にデータを転送できます。潜伏時間を増やすことで帯域幅を増加させる可能性があります。具体的には、各新しい DDR メモリ世代には高い転送レートがありますが、絶対遅延はほとんど変化しません。特に市場に出回った最初の新世代製品では、前世代よりも遅延が長くなる傾向があります。\nメモリの遅延が増加しても、メモリ帯域幅を増やすことで、マルチプロセッサまたは複数の実行スレッドを持つコンピュータシステムのパフォーマンスを向上させることができます。より高い帯域幅は、専用ビデオメモリのない統合グラフィックス カードのパフォーマンスも向上させます。 メモリ時系列パラメータの説明画像\n参考文献 メモリ時系列パラメータに関する説明 ","date":"2020-07-18","language":"ja","permalink":"https://ttf248.life/ja/p/computer-assembly/","tags":["ハードウェア","ディスク (Disukku)","デスクトップパソコン","メモリ"],"title":"PC自作のあれこれ","year":"2020"},{"categories":["コンピューター"],"content":"境内アクセス時のGitHub Pagesの速度が遅いため、著者が個人ドメインを取得し、国内クラウドホスティングプロバイダーのCDN加速サービスを購入しました。設定中に、wwwサフィックスドメインへのアクセスができない問題が発生しましたが、最終的に汎用ドメインのDNS解析を削除し、セカンドレ벨ドメインを個別に設定することで解決しました。著者はまた、CDN加速の原理と設定経験、およびNginxを用いた逆プロキシの試みと教訓についても共有しています。\n背景 ウェブサイトはGitHub Pagesにホストされており、周知のところ、GitHub Pagesへの国内アクセスが遅いことがありました。そこで個人ドメインを取得し、国内クラウドホスティングプロバイダーのCDN加速サービスを購入しました。加速サービスのセットアップ時に、開発マシンにもDocker、frp、k8sなどのサービスをデプロイしており、これらのサービスにはそれぞれダッシュボードが用意されていることを思い出し、無駄を省くという原則に基づき、複数のリバースプロキシを設定し、すべてサブドメインに付与しました。 その時、サブドメインであるwwwがアクセスできなくなったことに気づきました。阿里云でDNS設定を行い、www.xiangtianlong.comとxiangtianlong.comの両方を解析するように設定しましたが、CDN加速を有効にしていないときは両方のドメインが正常に使用できました。 CDN加速を設定した際、サブドメインが多数存在するため、汎用的なルールを有効にし、すべて開発マシンにルーティングしました。その結果、wwwというサブドメインもダウンしてしまいました。はい、正しく理解してくださいましたか？wwwプレフィックスはサブドメインです。実際にはウェブサイトはGitHub Pagesにデプロイされており、開発マシンにはウェブサイトのキャッシュ情報は一切ありません。 開発マシンにサイトをデプロイしなかったのは、静的ブログであり、GitHubが提供するActionで自動的に統合して公開されるため、本当に美味しかった（真香）からです。\nドメイン 非専門的なWeb開発において、ドメインの理解はSEOやクロスオリジン問題といった概念を含まない。ブログサイトとして、裸ドメインがブログ主のサイトを強調しやすく、特に私が漢数字でのローマ字表記をドメイン名としている場合や、現在のモバイルアクセスが多い状況では、入力する文字数を減らすことが望ましい。\nPC版ではキーボードショートカットでwwwとcomの入力を省略可能\nCDN 阿里云和腾讯云都用过，初心者でも扱いやすく、腾讯云には動画で関連概念を解説しています。CDN加速の原理は、京东倉庫と似ています。新商品が出版される際、全国各地の倉庫にまとめて配送し、配送リクエストが発生した際に、最も近い倉庫から配信します。\nキャッシュサーバー（回源アドレス）：ウェブサイトのリソースが元の場所で保存されている場所 キャッシュファイルの設定：ブラウザのF12で管理コンソールを開き、静的リソースと動的リソースを分析する\n全て0日有効期限 .php;.jsp;.asp;.aspx 0日有効期限 .jpg;.png;.js;.css;.woff2 1日有効期限 腾讯云設定ルール：\nキャッシュ过期ルールは最大10件まで設定可能 複数のキャッシュ过期ルール間の優先順位は、下から上にいくほど高い キャッシュ过期時間は最大365日まで設定可能 悲惨自述 以前从未用过Nginx，以为网站随便搜索就能明白反向代理的配置，结果有点混乱，折腾半天连个302跳转也没弄明白，最终毫无用处。就想着笨办法解决一下，DNS解析删除*模式的泛域名解析，单个二级域名进行独立设置。这时突然注意到了阿里云DNS解析有一个叫做“显示URL跳转”的模式，尝试了一下，这不就是我想要的302跳转吗。\n设置了第一个二级域名正常访问，等我设置第二个的时候，发现没用，都快怀疑人生了，等了一会突然就能用了，看来阿里云的DNS扩散偶尔也是会抽风的\n参考資料 なぜ多くのウェブサイトのドメイン名に「www」プレフィックスが付加されないのか？ www付きとそうでないドメイン名の違いは何ですか？ Docker nginx 反向プロキシ設定 ","date":"2020-06-20","language":"ja","permalink":"https://ttf248.life/ja/p/website-acceleration-and-domain-setup/","tags":["ブログ","ドメイン","CDN","Nginx"],"title":"ウェブサイトの高速化とドメイン設定","year":"2020"},{"categories":["コンピューター"],"content":"本記事では、Markdownの基本的な概念と、さまざまなソフトウェアでの利用について紹介しています。VSCodeをIDEとして推奨し、おすすめプラグインも列挙しています。作者はHexoからHugoへの移行経験を共有し、Hugoの柔軟性とカスタマイズ性を強調しています。最後に、新しい技術を迅速に習得するためのヒントや、Hugoテーマのスタイルが更新されない問題を解決する簡単なコツを紹介します。\nはじめに Markdown 軽量マークアップ言語であり、人間が読み書きしやすいプレーンテキスト形式でドキュメントを作成することを可能にする。\nMarkdown 詳細なMarkdown構文については、本文で別途詳述しません。電子書籍を推奨します。こちらをクリック 市場には多くのソフトウェアがMDを記述方法としてサポートしています。CSDNのブログシステムはMD構文に対応したオンラインエディターを導入しており、初回使用時にデフォルトでMD構文に関する紹介記事が表示されます。筆記者自身もそれなりに有用だと感じています。印象笔记では2018年にMDノートのサポートを追加し、ショートカットバーには様々なMDマークアップのオプションがあり、普通の文章を編集するのとほぼ同じように使えます。全体的なインタラクションフローは初心者にもフレンドリーです\nIDE 推奨 この記事を書いているのは2020年であり、VS Code は当然のことながら皆知っているでしょう。なぜなら、Git Page をブログシステムとして構築することを考える業界人は少なくないからです。数年前には、Sublime や Atom も優れた選択肢でした。オープンソースコミュニティの推進により 2 年間にわたって発展し、現在では VS Code が初心者にとっての最初の選択肢となっています。\nMicrosoft の巨頭とオープンソースコミュニティの関係は、対立状態から成功裏に蜜月期に入りました：オープンソースを抱擁しています。筆者所在の会社も最近 2 年間にわたり積極的に Java エコシステムを取り入れており、ビジネス開発においては、現在国内で Java エコシステムはまさに「魅力的」です。\nVSCodeプラグインのおすすめ プラグインにはそれぞれReadmeがあり、基本的な使い方や主要な機能が紹介されています。一部のプラグイン作者は、動的な効果を表示する画像も提供しています。 Paste Imageとhugoの画像プラグイン方式を組み合わせることで、非常に簡単に画像を挿入できます。\nショートカットキーを忘れてしまった場合、VSCodeのショートカットキー管理メニューを開き、「md」で検索して数回確認しましょう。Readmeをもう一度見直すのも良いでしょう。\nHugo 筆者はhexoからhugoに切り替えた。愛折衝は私の天性であり、結局は忍耐強く静かに記事を書くことができないのだ。\nHugoは、個別のフォルダに画像とmdドキュメントを置くことをサポートする。 Academicテーマのデザイン上では、様々な種類の文章スタイルをサポートしている。 様々な便利なカスタム拡張機能がある。 学術 公式サイトではデフォルトでexampleSiteを使用し、メニューのインポートには#component形式が推奨されます。URLのパターンは、ナビゲーションバーをクリックすることで単一ページのジャンプを実現し、ホームページでのスクロールを回避します（これは純粋な個人的な好みです）。\nスタイル：ノート、講演、電子書籍 柔軟性：全体的なスタイルのカスタマイズ、カスタムCSSスタイルの適用 このテーマは、中国語のサポートがまだ十分ではありません。主に視覚的な観点からすると、フォントサイズが中国語の読書習慣に合っていません。Hexoの開発者はほとんどが中国人であり、この点ではHugoよりも優れています。しかし、自分で手を加えて、ブラウザで要素を検証することで、要素を見つけ出し、変更するCSSスタイルの名前を知ることができます。サイドバーでInsert Style Rule Belowをクリックすると、ネストされた多層構造のCSSでも簡単にノード名を取得できます。\nカスタムCSSの導入 カスタムJSの導入 テーマに組み込まれている構文強調表示の設定については、公式ドキュメントを参照してください。 結論 子供たちがまた文句を言っているようだ。「最初から最後まで、曖昧で、細かいこと何も言ってない」と。\n私はこう言うつもりだ。以下のものがあれば十分だ：\n公式マニュアル プラグインの説明書 新しい技術をすぐに使いこなすには、まず公式サイトのドキュメントを読むことを推奨する。完璧に理解しようとする必要はないし、一度読んで理解する必要もない。少なくとも、ある程度の知識は持っておくべきだ。検索エンジンで見つかる結果が、必ずしも最新版と一致しない。誤解を招く可能性もある。新しい本も同様だ。まず目次を見て、著者が何を説明するのか把握する。場合によっては、序文を読むのが良い。特に海外の著作を翻訳した際に、翻訳者の序文は書籍と核心的な内容をカバーしていることがある。\nエッグ（卵） Hugo Academicの組み込みスタイルを切り替え、サイトに公開後、アクセス時にスタイルが変更されない。賢い仲間たちはすでに解決策を見つけており、「ブラウザキャッシュをクリア」することで問題が解決する。私のような機転の利いた者：「F12開発者ツール」でnetworkタブを選択し、disable cacheオプションをチェックしてリフレッシュすれば、完璧！ ","date":"2020-03-31","language":"ja","permalink":"https://ttf248.life/ja/p/blog-ide-environment-and-ramblings/","tags":["markdown","hugo","academic","ブログ"],"title":"ブログIDE環境と雑感","year":"2020"},{"categories":["コンピューター"],"content":"GitHub Actions を使用して、Hugo ブログを GitHub Pages および Gitee に自動でデプロイします。\n背景説明 昨日ブログを更新した際に、Travisサービスが利用できないことを発見しました。Travisのウェブサイトを確認すると、ソースコードの取得時に進捗が止まっていることがわかりました。そこで、GitHubが以前に発表していたActionサービスを思いつきました。 当時、業務が多忙であり、Actionを利用するには申請が必要だったため、現在は正式にリリースされ、週末に暇を持て余している間に、新しいおもちゃを試してみようかと思いました？ 公式資料は、ご自身でウェブサイトをご確認ください。本記事では、より多くの転載を行いません。もしKubernetesをご利用経験がある場合、ActionのYAMLファイル設定がKubernetesと非常に似ていることに気づくでしょう。 入門チュートリアル、あるいは中国語の説明資料については、阮一峰のブログを検索することをお勧めします。2つの記事があり、1つ目は基本的な構文の紹介であり、もう1つは実際のケーススタディです。\n--- 正文 必要な知識点 - GitHub Secrets - Action の構文 コアのジョブは既存のコンポーネントを使用して完了し、国内のGiteeにプッシュするにはコマンドを使用します。このコマンド部分は粗暴で、強制プッシュのみを実装しており、Travisを使用していた際のロジックを継承しています。 ```yaml name: github pages and gitee pages on: push: branches: - hugo jobs: deploy: runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v2 with: submodules: true - name: Setup Hugo uses: peaceiris/actions-hugo@v2 with: hugo-version: \u0026#39;latest\u0026#39; extended: true - name: Build Github and Gitee ## 単独ステップには1つのrunコマンドしか書けない run: hugo -b \u0026#34;https://www.xiangtianlong.com/\u0026#34; -d \u0026#34;github_public\u0026#34; \u0026amp;\u0026amp; hugo -b \u0026#34;https://www.xiangtianlong.com/\u0026#34; -d \u0026#34;gitee_public\u0026#34; \u0026amp;\u0026amp; ls - name: Deploy Github uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.BLOG_TOKEN }} publish_dir: ./github_public publish_branch: master cname: xiangtianlong.com - name: Deploy Gitee run: cd ./gitee_public \u0026amp;\u0026amp; git init \u0026amp;\u0026amp; git config user.name \u0026#34;TianlongXiang\u0026#34; \u0026amp;\u0026amp; git config user.email \u0026#34;tianlongxiang51@gmail.com\u0026#34; \u0026amp;\u0026amp; git add . \u0026amp;\u0026amp; git commit -m \u0026#34;Update TianlongXiang\u0026#39;s Blog\u0026#34; \u0026amp;\u0026amp; git push --force \u0026#34;https://xiangtianlong:${{ secrets.GITEE_PASSWORD }}@gitee.com/xiangtianlong/xiangtianlong.git\u0026#34; master:master 付録 公式マーケットで提供されているactionを見ると、現在サポートされている遊び方があまりにも多い。Dockerイメージを構築すれば、Docker Hubから提供されるサービスへの依存関係もなくなります。\nHugoのissueを調査すると、GitHub Actionを使ってgit pagesを自動デプロイする際に、最終的に公開されるウェブサイトがmasterブランチにある必要があることがわかります。もし他のブランチにデプロイする場合は、設定画面でGitHubはウェブサイトに構文エラーがあると警告します。\nこれは単にHugoのソースファイルがmasterブランチにあるため、GitHubがjellyブログのソースコードとして検出し、構文チェックが通らない場合に発生するエラーです。\n解決策は簡単です。Hugoのソースファイルを他のブランチに配置し、静的ファイルをmasterブランチに公開します。\n","date":"2020-03-29","language":"ja","permalink":"https://ttf248.life/ja/p/auto-integration-system-switch/","tags":["travis","github action","ci","ブログ"],"title":"自動統合システム切り替え","year":"2020"},{"categories":["転載 (tenzai)"],"content":"二十年後に、可愛らしいおじいさんと、可愛らしいおばあさんのそばにいることを願っています。お金持ちや権力者になることにはこだわらないけれど、体が丈夫で、色々なところを旅することができるように。\n動画トランスクリプト Youku Search でお願いします。以降、リンクは提供されません。\n稿件 私が10年後の素敵なご高齢者である自分を想像しています。そうありたいと努力します。未来は良いものでなければなりません。中国には、将来、多くの公民のように公民になる人、そして規則を理解し、活気のある若者が必要です。素晴らしい中国は、魅力的なご高齢者やご高齢婦人がいる国でなければなりません。私が10年後に60歳になったとしても、世界で最も若く、第三の国度に住んでいることになります。\n率直に言うと、皆さんが私の50歳の中国人の男性がこの体型であるなら素晴らしいと思いますが、これは私が信じていることです。越す自律（じりつ）すればするほど自由になる！雨が止むとすぐにランニングに行きます。明日の午後はサッカーをします。50歳になっても、まだ大きな試合でプレーできます。冗談ではありませんし、よくプロと一緒にプレイします。しかし、その裏には何がありますか？それは自律です。私は残りの日々をランニングに費やし、ランニングは多くの人が退屈だと感じるものです。越す自律（じりつ）すればするほど自由になるのです。私は自律することで自由に走ることができます。音楽は聴きません。なぜなら、自分の呼吸が最も美しい音楽だからです。\nまた、私は基本的にトレッドミルを走ることがありません。北京の霧霾が非常に深刻であるにもかかわらず、私は週に5日間ランニングし、そのうち2日間は霧霾のために休むのです。そして、他の人と違う点を冗談っぽく言うと、「断続的に」走っているだけなのです。毎月、日記に自分のランニング体験を記録します。私の経験を1日ごとに描き出すもので、少なくとも18日は走り続け、ランニング中はメガネも外してしまいます。しかし、最も重要なのは、私は毎週サッカーをするということです。私の研究室の学生が最後に授業を受ける場所は、いつも私たちの家です。テーマは「楽しさ」であり、私は楽しさを非常に重要だと考えています。私は、何の楽しみや趣味もない人々と交流することはありません。\n敬うべき存在を遠ざけるべきです。そのような人はとても恐ろしいのです。楽しみがないと、何をしているのか分からず、私は本当に何もしていないように見えます。あなたはどんな仕事が好きですか？私の学生の一人が中国の新聞週刊紙に寄稿し、ある特集で「未来」というテーマについて書きました。10年後の私の学生が卒業するたびに、最後に彼らに課す課題は、10年後に自分自身を書いた文章を書いてもらうことです。そして、私はそれを残して、10年後に彼らに次々と提示します。私自身が50歳で60歳に書いたものを書き、60歳は私が今まで想像もしなかった遠い場所であり、地図上では存在しない場所ですが、それは私の次の20歳への道です。30歳の学生たちへの手紙は、春の情熱を伝えるものです。しかし、50歳で60歳に書くのは、秋末に独り言をつぶやくようなものです。今、私は10年後の自分に向けて、世界から少しずつ自分のベッド、食事、家族のそばを書いているのです。これは自然なことです。\nしかし、60歳になってどのような人になりたいか、私の目標は明確です。長い文章の中で、「快適な」序文を書いています。私が10年後の素敵なご高齢者である自分を想像しています。そうありたいと努力します。中国が魅力的になるためには、将来、多くの公民のように公民になる人、そして規則を理解し、活気のある若者が必要です。現在、60歳以上の人口はすでに2億3千万人を超えています。10年後には3億人を超えるでしょう。つまり、60歳以上の人々の人口だけで見れば、中国の人口は世界で5番目、あるいは3番目の国になる可能性があります。想像してみてください。恐ろしくないですか？\n私はそう思っていません。皆さんが今日オンラインで見た表が、中国の各省市直轄市の平均寿命です。上海と北京の両方が80歳を超えています。男女を合わせて平均寿命を計算しています。平均寿命は男性の方が女性よりも多いでしょう。つまり、私が10年後に60歳になったとしても、世界で最も若く、第三の国度に住んでいることになります。未来。女性が55歳で退職し、80歳まで平均寿命になる場合、退職後の25年間は活動を続けることができます。男性は60歳で退職し、80歳まで平均寿命になる場合、退職後の20年間は活動を続けることができます。ダンスだけをするのではなく、 私は60歳になったとき、最も若いチームの一員として参加しましたが、自分に何をしてほしいのか？中国画では60歳の耳は順じると言われ、信じていますが、あの頃は絶対に聞き入れないでしょう。何に喜ぶか、何に不満を感じるか、常に変化し、より重要なのは若者たちのために何ができるのか！ 良いことのために何をすればいいのでしょうか？怠惰をせず、簡単に妥協せず、反対すべきことは反対し、若者が利益を損なう可能性がある場合、それを阻止することができるでしょうか？今、私はよく鏡を見つめています。私の親友である陶偉はすでに亡くなっていますが、あの頃は頻繁に集まり、私たちの家で会いました。彼は私に一度真実を語ってくれました。私たちは皆、悲しみに暮れ、陳老一代（陳老一代）のような人々は家に集まって物々交換をし、30個ものものを床下に隠してしまったり。彼らに自分の意見を伝えなければなりませんでした。「この服は500元で買ったんだ」「完了、供養のために使います」「毎日お香を焚きます」。だから、私たちの世代は親と知恵比べをする習慣があり、700元で買ったものはいくらになるでしょう？ 220。しかし、それは危険です。陶偉は一度、彼の父親に400元以上のTシャツを買いました。そのTシャツは本当に良かったので、いくらでしたか？99元で買ったものを私も着ました。次の日には、夜帰ってきて陶偉に400元をあげて、私のために4枚買い直してもらうと褒められました。私はそのTシャツを着て出ると、張さんと李大爷（李大爷）たちは皆、そのTシャツが素晴らしいと思って、後に「このような嘘をつくリスクは非常に大きい」と言いました。将来、あなたはこのような老人でなくなるべきではありません。具体的な人物を挙げるわけではありませんが、病院の骨科で高齢者が骨折した原因は、地攤（地摊）で買った靴を履いたことであることが判明しました。もちろん、これは私が話している内容のほんの一部であり、年老いても精神的な生活を維持し、好奇心を持ち続け、若者たちを守るために自分自身を犠牲にすることを拒否しなければなりません。一日を楽しく過ごすことが大切です。 私は60歳になるのを待ち遠しく思っており、それは素晴らしい時が始まると思っており、感謝します。 ありがとうございました。\n","date":"2020-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/future-china-with-good-grandparents/","tags":["白岩松 (Hakken Matsu)","講演 (こうえん)"],"title":"将来の中国は、きっと良いお爺さんやお婆さんがたくさんいる国になるだろう","year":"2020"},{"categories":["転載 (tenzai)"],"content":"非常に一般的な用語である「情報断片化」。高校卒業以来、小説を読む時間を疎かにして以来、じっくり静かに一冊の本を読もうと思っていないのが長い。時々振り返ってみると、仕事をしてきた年月を感じて、自分が毎年何をしたのか覚えていられるだろうか？　多くの場合は、半年が終わる頃には、前半の出来事を忘れてしまっている。ブログを書くことは良い習慣であり、私が書く内容は多くが下品なものでも関係ない。本来は自分自身に向けて書いているものだ。\n私にとって最も忠実な読者は私自身だ\n動画トランスクリプト Youku Search でお願いします。以降、リンクは提供されません。\n稿件 それぞれの18歳は、期待と問いかけの眼差しのようなものであり、誰でも時々、自分の18歳の時に「自分は何者になりたかったのだろうか？」と自問自答します！今の時代、誰もがたくさんのSNSを持ち、友達がいなくて毎日チャットしたり、心を開く人がいなくて、知識は無限にあるけれど知恵には程遠い状況に陥っていること。人はそれぞれ自分の18歳の時に「人を騙しているのではないか？�tそれは本当に自分自身がなりたかったものなのか？」と自問自答すべきです。\n私は、それぞれの18歳が期待と問いかけの眼差しのようなものであると考えています。他人を騙せるかもしれませんが、自分の18歳の時の自分を騙すことはできません。今の自分が、18歳の時になりたかった姿ですか？　まあいいでしょう。物質的な成功や名声など、18歳の時よりもずっと多くのものを手に入れていますが、一方で常に「まだだ」と思っています。18歳の私は放送学院でジャーナリズムを学び、「ファラキのような最高のジャーナリストになる」という夢を持っていました。今もなおその道を歩み続けていますが、これがまさに多くの人が白先生に言っている「あなたはなぜCCTVに残っているのですか？」の理由です。ニュースは変わらず続いています。これは18歳の時の私の視点であり、だからこそ私は、誰でも時々自分の18歳の時に「当初自分は何者になりたかったのだろうか？」と自問自答すべきだと考えています。\nこれは真に他人を騙すことはできません。これは18歳の時の私自身の姿です。あっという間に32年の歳月が流れました。北京大学に入学する学生たちには、必ずこの一枚の写真が残ります。あの時代、天門広場に身につけていた皺くちゃのスーツ、胸元には校章を付けていました。なぜなら、当時の大学生は少なくて校章を付ける必要がないからです。とても誇らしかったのです。その頃の髪は長く、18歳の時の自分自身をとても愛していました。長い年月が経ってから、私は18歳の時に直面したものを振り返り、感謝しています。なぜなら、それは静かに私を形作ってきたからです。1986年5月8日、王府井書店で朦胧詩集を購入しました。その年に国体（中国国家体育館）で崔健の「一无所有」を聴き、今、私は自分の文章スタイルが最も影響を受けたことを突然気づきました。包括的に、私の性格も朦胧詩、ロック音楽、古龍の武侠小説の影響を受けています。\n18歳の時、あなたはどんな経験をしましたか？ それらを持ち込んで道を歩むことができます。今日の18歳はどんな経験をしているのか、特に知りたいです。まるで刀で彫刻するように、一筋縄ではいかないのでしょうか？ 彼はどんな道具を使って、どんな姿にあなたを磨き上げているのでしょうか。今の18歳がたくさんのSNSを持ち、友達がいなくて毎日チャットしたり、心を開く人がいなくて、知識は無限にあるけれど知恵には程遠い状況に陥っていること。誰もが「個性」を語るように見えますが、私のような傍観者からすると、今の若者はとても似通っています。どうすればいいのでしょうか？ 18歳の時に彼らにどんな経験をさせればいいのでしょうか？ 私は1986年をとても好きです。なぜなら、1986年は1966年を解決するための最良の方法だからです。\n1966年の文化大革命は、76年に四人帮を打倒することで終わりました。それは偶然であり、1986年の啓蒙と人間の目覚め、そして個人の成長によってのみ、あなたが心配する根本的な問題を解消できるのです。中国社会が経済的にどれほど進歩し変化しても、人間性を理解するための「一刻」が補えない限り、人性をコントロールし悪の部分を抑制し善の部分を活性化することはできません。未来には依然として多くの懸念事項があるでしょう。だからこそ、私の18歳の時もこの時代の18歳でした。遠くまで行きましたが、当初の出発点に立ち返らずにはいられません。今は「初心」という4つの言葉に凝縮されています。\nだからこそ、どんなに遠くへ行っても、人はそれぞれ自分の18歳の時に自問自答すべきです。18歳の時の写真を撮っておき、定期的に見返すのは良いことです。他人の意見は関係ありません。人を騙すのは簡単ですが、自分自身を騙すのは非常に困難です。私が今20歳の人に言うことは、あなたは常に自分の18歳の時を観察する一\n","date":"2020-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/my-18th-might-be-different/","tags":["白岩松 (Hakken Matsu)","講演 (こうえん)"],"title":"私は18歳で、あなた方とは少し違うかもしれません。","year":"2020"},{"categories":["転載 (tenzai)"],"content":"記者の職業に対する筆者の見解を述べ、記者には社会の良心、知識、そして長距離走のような粘り強さが必要だと強調している。また、50歳の時の自身の洞察も共有し、好奇心の維持、物質と精神のバランス、そして未来への考察について語っている。\n動画トランスクリプト Youku Search でお願いします。以降、リンクは提供されません。\n転写 最好的记者首先要有社会良心，其次要有知识储备，第三是持久力。我不能只跑100米觉得不够瘾了，就跑了。我认为这三者结合，人们期待的是疫苗安全的问题彻底解决掉，就像当初的奶粉事件一样，总是先出了问题、再解决问题，彻底解决问题的这种逻辑循环中前进。否则记者要干什么？\n稿件 まず、一番良いジャーナリストは社会良心を持っていることだと思われます。次に知識を蓄えていることが重要で、そして長距離走も、100メートル走るのに飽きたら、やってみなければなりません。これらの三つが組み合わさって今年50歳になったので、あなた方は私がニュース業界に合う理由を理解できたと思います。私は中国の改革40年と密接に結びついており、30歳の誕生日に松花江の岸辺で、40歳の時に2008年のオリンピック中に入り、オリンピック中に出ることができました。今年50歳になり、全国的に改革開放40周年を記念しているので、確かに対応があります。大時代が40歳、中国の改革40歳は惑っているのか、混乱しているのか？\n40年もの道のりを歩んできた中国は、物質面で多くの人々や国家に十分なものを与えてきました。しかし、不安や混乱が増え続けており、強大で豊かなだけでは良い結果が得られるとは限らないのです。アメリカもあなた方の高科技を攻めていますから、私たちは農産物を輸出する必要があります。この世界には「二番手は簡単ではない」という言葉があります。アメリカでは修理した2台がどれくらいあるでしょうか？したがって、私たちが長い年月を経て、二番手を超越する存在になる必要があります。私は全てを得られるわけではありません。\n幸運なことに、25歳の時にテレビに出始めたところ、まず人物インタビューから始めました。私は数百人、数千人の光環を持つ人物に接触し、若かりし頃は光環が彼女たちを幸せにするものだと考えていましたが、近づいてみるとno、光環と彼女たちの幸福には関係がないことや、むしろ逆の関係にあることもありました。最近、郭沫若の最後の29年を読んだのですが、郭沫若はほとんど苦労せず、国务院副副总理、什么政协副主席、副委员长などの地位に就いていたにもかかわらず、自分の息子が自殺し、もう一人は屋上から投げ落とされて死んだのです。彼は幸せだったでしょうか？\n幸福を測る基準は何ですか？67歳になった時に、連なるようにして二人の息子を失うことは、彼女にとって幸福と言えるのでしょうか。名画や安全な生活は幸福をもたらすことがあります。ですから、私は人を見るのが、最も良い鏡だと考えています。少し重点を置いて言うと、今の多くの人が不安を感じているのは、考えすぎ、読書が少ないからです。これは楊绛老人が若い人に答えた言葉です。読まなければ快餐しかありません。スマートフォンで大力丸を探すなんて、ありえません。私は本を読みながら、ゆっくりと賢くなることを学びました。減算は、本を読む量が増えるにつれて行われる減算です。\nですから、私は全ての人に期待するわけではありませんが、その割合が増えることを願っています。より多くの中国人たちが読書を通して自分自身を向上させることを目指すべきだと考えています。それが最も重要です。誰も地上で星空を見上げて、全てのことを理解しようとするわけではありません。私は鏡を見て、数年前のBBCニュースの司会者が北京に来て、BBCで最も優れたニュースの司会者だと言われ、中国のニュースの司会者と対談しました。その人は対話の中で私に質問をしました。「あなたはBBCがCCTVから何を学ぶべきだと思いますか？」私はまず冗談を言いました。「もちろん、まず中国語を学ばなければなりません。」\n次に冗談を言うと、「BBCは世界に対する好奇心を持つことを学ぶべきです。」私たちはここ数年で急速に世界に行き、さまざまな報道局を設立しました。現在、私たちの学生が海外の新しいものを見ると、非常に興味を持ちます。私たちは大きな好奇心を持って世界を観察し、BBCはすでに英国自体を世界として考えています。彼らは拍子で言いました。「あなた方が不足しているのはこのことです。」2007年に日本を取材した作家が私にこう言いました。「日本の国は希望がない以外、残りのものはすべてあります。」後に理解しました。これは本当に深い言葉です。逆の角度から言うと、10年前には中国は希望がある以外、残りのものが不足していると思っていましたが、今は希望があります。誰も前方に進んでいることを感じています。\nしかし、いつか私たちが希望を失った富裕な国になってしまうのではないかと心配しますか？ 坦白地说，我非常担心中国走到一天是负的，什么都有的时候才觉得自己真穷，我50岁的时候就唯恐自己成为一个一切物质条件都可以得到满足，却成为一个非常贫穷的人。在我们的现实生活中，高学历的、没文化的人很多，存折上有无数个数字的穷人很多，这才是这个时代的问题。真穷是不可怕的，因为前面有奔头有希望。这就是我说道德赤字和人性亏损的原因所在，所以我觉得科学家之所以发明了很多的东西，不是说一开始就承载着伟大的什么使命等等，我觉得好奇。\n好奇我能弄出来他吗？所以我始终在50岁左右的时候就开始督促自己要更好奇，所以我都很开心，我现在很烦的一件事就是坚持，刚才聊天的时候在说您还在坚持，我说别我说一旦坚持离死不远了。过去我们都说坚持就是胜利，中国足球只要坚持黑色三分钟，坚持就咬牙了，没乐趣了就靠坚持了，坚持有的时候很重要，但是相当多的时候这句话要有AB面。我很怕我在做一件某件事情的时候是坚持，比如说这会跟大家聊天的时候，我就坚持把剩下说完，其实到现在我的时间都到了，可是我觉得好奇，跟大家的交流，我会说成什么样？\n给自己一个很小的关键词，但是你自己跟跟大家的互动去聊天，我觉得在50岁的时候，只要你还能保有很大的好奇，没问题，我喜欢所有好玩的东西，但不一定跟现在最好玩的东西，今天的时髦有可能一转眼。每年都有流行词，您还记着几个？今天的互联网某个媒体可能10年后是传统媒体想过吗？所以好玩的东西永远有它好玩的内在的东西，我尊重每一个大家的喜欢，那一定有他的道理，但是长期下来看，最后发现中国人最喜欢的还是打麻将，当你也喜欢吃快餐的时候，做大菜的饭馆自然会慢慢的倒闭。\n很多东西不仅仅是发个感慨就过了。您每天让在手机碎片化的阅读是多少？您长一点的阅读有多少？但是这也是一个过程，手机正在成为我们的手铐。所以我觉得看越短的东西多，慢慢人也会变得短视，但这也是一个过程，我从不担心内容为王。还会回来，您会每天娱乐至死，一直到自己的40岁，就像我看见十几岁的孩子喝可乐，你劝他少喝一点，但你知道他一定会喝，但是另一方面我又乐观，40岁他一定会回到茶的世界里来，这就是中国人的一生。\n很正常，但是我希望接下来的转变会更快一点。我们就是发个感慨，现在的调查记者这么少了，您不看调查了。 谢谢各位。\n","date":"2020-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/what-kind-of-journalists-does-society-need/","tags":["白岩松 (Hakken Matsu)","講演 (こうえん)"],"title":"この社会にはどのようなジャーナリストが必要でしょうか。","year":"2020"},{"categories":["転載 (tenzai)"],"content":"以下是翻译后的日语文本：\n読後感の補足は、ほとんどが2021年に随筆したものであり、白岩松先生の講演稿を文字に起こす作業は、ちょうどコロナ禍が始まった頃でした。二十年後のことや、一年後、二 χρόνια後のことなど、世界の変化は常に人々の予想を上回ります。現在、国内のコロナ禍は終息しつつありますが、海外の疫情は依然として騒がしいです。サッカーについては、数年前から中国代表がよくプレーしていました。コーチも積極的に攻撃を許容し、かつての無邪気な頃に比べると、老人に付き添って観戦することは少し意味がありました。ある国家チームの試合でさえ、おじいさんはチャンネルを変えたいほど飽きてしまうのです。それはどのような経験なのでしょうか？ 動画トランスクリプト Youku Searchでお願いします。以降、リンクは提供されません。\n転写 あなたはまだ中国サッカーに興味がありますか？興味があります、非常に興味があり、さらにどうなることが可能でしょうか？だからこそ、中国サッカーが良くない理由がたくさんあることに気づき、その一つは、誰かがボールを落として自分のところに返ってくるのを恐れ、他の人にパスしてしまえばそれで終わりだということです。そのようなプレー法がないのです。\nもちろん、これはほんの小さな原因に過ぎません。20年のサッカー、20年後の中国サッカーはまるで遠い未来のように感じられます。最初の拡大で48チームになり、中国が参加する可能性も、参加しない可能性もあります。ある国の代表チームにとって最適な年齢は26～30歳ですが、20年後には現在6歳から10歳の子供たちがいます。20年後に楽観的に考えるのは当然ですが、20年後は必ず成功すると言っても、私が今日6歳から10歳の子供たちについて話すと、すぐに表情が厳しくなります。因果関係、種を蒔けば豆が育つように、私たちは今日何を育てているのでしょうか？今日、リーグ戦でプレーする代表選手を育てるためにほぼ種を植えているのと同じことを、私たちは何を生み出しているのでしょうか？誰かがその動きに出ると、すぐに退場処分になる準備をしなければなりません。これは規則に反するので、私はそれほど深く考えませんでした。\nしかし、真剣に考えるべきは、今日6歳から10歳の子供たちがサッカーをしているかどうかということです。あなたがそう思うように20年後の中国サッカーがどうなるかを知ることができます。\n","date":"2020-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/china-football-in-20-years/","tags":["白岩松 (Hakken Matsu)","講演 (こうえん)"],"title":"20年後の中国サッカーはどうなるでしょうか？","year":"2020"},{"categories":["転載 (tenzai)"],"content":"まず、何かをすることにおいては、心が清々しくなければなりません。そうすれば、安心して眠りにつけ、些細な病気や根本的な問題について、誤った判断をする心配がありません。もし間違えてしまったとしても、それを隠蔽したり、忘れようとしたりするのではなく、できる限りの努力をして救おうとすべきです。記憶力が良い種族もいますが、心が安らかであることは、帰る場所であり、自分自身に問いかけても答えられるような、穏やかな生活を送る上で重要です。\n動画トランスクリプト 動画の元のリンクはこちらをクリック 、著作権侵害の場合は、ご連絡の上削除してください。この文書は単なる文字起こし翻訳のみを目的としています。\n稿件 私は八つの字を言い、それが重いと感じています。今私たちは道徳的な赤字と人性的欠如に陥っており、時代は問題が発生するたびに解決策を見つけ出し、完全に解決するための論理的なサイクルの中で前進していく必要があります。あなたは忍耐を持ってその洗練を待つべきです。中国のような国にとって、多くのことはゆっくりとした洗練プロセスであり、絶望的にならず、洗練に専念する必要があります。\nここ数日間、中国は二つの台風と戦っています。一つは形のないものであり、もう一つは形のあるものです。形のない台風はワクチンであり、それは私たちの内なる安全の堤防を打ち砕こうとしています。もう一つの台風は上海から上陸したことがほとんどなく、北京や天津が被害を受けることはありませんでした。これは脇の話です。次にあなたは、自分自身のために善を行うこと、そして大きな変化を起こし、多くの答えを持つことを考える必要があります。周囲の環境が変わらない場合、あなたは幸せですか？私は八つの字を言い、それが重いと感じています。今私たちは道徳的な赤字と人性的欠如に陥っており、これが現在最大の赤字と最大の欠如です。\nしかし人々はワクチンが安全上のリスクを完全に解決することを期待しています。これは当初の粉ミルク事件と同じであり、時には歴史を見ることが重要です。また、米国食薬局の設立と形成における包括的な法律も、当初の粉ミルクや乳製品の不安全に関連しています。三鹿粉ミルク事件は中国を乳製品分野で大きな変革に導き、ワクチンは次々と問題を引き起こしましたが、今回は中止されることを願っています。あなたは時代が問題が発生し、解決策を見つけ出し、完全に解決するための論理的なサイクルの中で前進していくことを知る必要があります。そうでなければ、ジャーナリストは何をするのですか？そうでなければ市民は何をするのですか？\nですから、私は私たち一人ひとりができることは関心を持つことです。しかし中国の人々は簡単に忘れてしまいます。私が言ったように、誰かの車にぶつかってから走り去り、他の人は誰もそれを阻止しません。私たちの隣人や同僚の多くは、そのような人々です。ですから、ゆっくりと変化していく必要があります。そして私のような普通の市民ができることは、彼らに注意を払い、忘れないことです。私はそれが何かを欠いているのではなく、飢えや寒さの中で理想について毎日議論することではないと思います。説得力がないかもしれませんが、彼らが満たされたとき、世界で一番糖尿病患者が多く、高血圧患者が多い国になってしまうのです。そして中国人が走り始め、ダイエットを始めるのを見て、座っている各位の女性は、誰が一度も食事に困った経験をしたことがありますか？それは私です。少し変化があります。\n精神的な側面も同じ原理に従うべきです。満腹になったら走り始め、ダイエットをしなければならないとき、精神的なニーズもそれに伴って増大します。例えば、以前はタバコを吸っていました。しかし、ランニングを始めた後、突然20日以上タバコを吸っていませんでした。私はそれを完全にやめようとしなかったからです。それはあまりにも儀式感がありすぎます。年に数本吸うこともあります。生活習慣が変わるにつれて、多くのものが変わります。中国人の場合、忍耐を持ってその洗練を待つ必要があります。\nますます多くの人が自分自身が幸せではないと感じています。抑うつ状態が増加していますが、一方で、より多くの人々が積極的に生きる方法を探しているという事実もあります。このとき精神的な側面は成長します。だから絶望しないでください。同じ出来事をどのように見るかによって異なります。私は通りで車を追い越し、落胆しますが、すぐに反対側に並んでいる人がもっと多いことに気づき、楽観的になります。これはまさにそのプロセスです。座っている各位が雨上がりの夜にこのような無駄なことを話すこと自体は楽しいことではありませんか？\nこれはまた変化であり、多くのことを別の方法で考える必要があります。もちろん、将来的に成長するものはたくさんあります。例えば、起業について言えば、誰の人生も起業ではありませんか？蘇軾は起業しましたか？李白は起業しましたか？\n\u0026mdash; - 成功事例の創出（そうせいひれいのごうしゅつ）\n深層学習（しんそう gakushū） ニューラルネットワーク（nyuraru nettowāku） （以下、原文の内容を日本語に翻訳します。）\n人生にはたくさんの挫折があるだろうが、最終的に自分のブランドを生み出すことができたからこそ、ほとんどの挫折は関係ない。大切なのは、生きている間に十分な味わいを持ち、自分にとって価値のあるものだと感じることだ。今の私は、中国特有の欠如しているのが、良い失敗を別の成功として捉える価値観だと思っている。中国人たちは成功した結果だけを受け入れるが、反対に良い失敗も成功と見なさない。\nそれが難しいと感じるからこそ、中国サッカーがうまく機能しない原因の一つは、誰もボールを失うことを恐れず、自分からパスをすることさえ避けるという点にある。そのような戦略がない限り、もちろんこれはほんの一つの要因に過ぎない。だから私は、30歳を超えてからは、序論でさえも透明な喜びや、すぐに実現できないことなどを書き記すことに焦りを感じるようになった。そして50歳になると、時間が過ぎ去っていくのが非常に早く、期待していたものがまだ現実にならないことを理解するようになった。しかし一方で、中国のような国にとって、多くのことはゆっくりと洗練されていくプロセスであることも理解している。親の世代の中には、赤や緑の信号が全く意味を持たないものもいるが、時折子供が父親を引っ張るのを目にする。変化し、洗練される。だからこそ、私は忍耐が必要だと考えている。\n","date":"2020-02-15","language":"ja","permalink":"https://ttf248.life/ja/p/moral-deficit-humanity-loss/","tags":["白岩松 (Hakken Matsu)","講演 (こうえん)"],"title":"倫理的欠如、人性的喪失","year":"2020"},{"categories":["転載 (tenzai)"],"content":"国家全体として、より良い方向へ、富強さを増していく傾向にある。もし人々の虚栄心がなければ、そうした変化を理解しやすくなるだろう。1990年代から現在にかけて私が見聞きしてきた家庭においては、皆さんの生活水準は以前に比べて格段に向上しており、同時に富裕層も増加している。市場経済の発展に伴い、避けられない貧富の差拡大も生じている。\n人々が言う「階級固化」「上昇通道の閉塞」といった現象は、現代社会における共通の問題である。中国共産党が人民の基本的な生活水準や社会保障に貢献してきたことは、皆さんが認識すべきだろう。子供たちの教育資源の不均衡問題や、より良い仕事機会や環境、あるいは家族との時間を優先するかという選択など、個人の考えを他者に押し付けるべきではない。特に子供や家族に対して。\n静かに話し合い、生活は着実に向上していく。\n動画トランスクリプト 動画の元のリンクはこちらをクリック 、著作権侵害の場合は、ご連絡の上削除してください。本記事は単なる文字起こし翻訳のみです。\n三十歳 今年、私を含めるとちょうど50歳です。過去は、自分にとって「老頭（おじいさん）」だと思っていたことがないのですが、今になって本当に老頭だと気づきました。これは30歳頃の自分です。30歳になると、自分が若く、とても良く見え、素敵だと思っていましたが、50歳になると振り返ってみると、それなりに良い方へ向いていると思います。30歳で人生で最も感じた最大のことは何でしょうか？　振り返ってみると、「減法（かんぽ）」だと感じます。キーワードは「減」です。ある意味では、「痛並快樂着（つねるなかれがくしゃつ）」も一種の「減」であり、色々なことを経験して、それを言葉にして残し、新しい白い紙やランニングに挑戦します。しかし私にとって30歳は、自分自身だけでなく、皆さんのためにしても、本当に「減法」をすることは非常に重要だと感じました。\n今、私は大学生のビッグプロジェクトを担当しており、彼らに30歳になる前には「加法（か）」を最大限に行い、様々なことに挑戦するように促しています。あなたは自分の可能性や運命がどのようなものなのか分からないので、思いっきり試すべきです。結果がどうなるかは分かりませんが、それでも多くの人は20代に必死に「加法」を積み重ねていきますが、いつまで経っても「減法」を忘れてしまうのです。30歳頃は人生において非常に重要な時期であり、「加法」と「乱走（らんそう）」をしてきた後に、「減法」を行うべき時期です。もし遅れれば、後悔することになります。なぜなら、全てがあなたに合っているわけではなく、合うものもたくさんあるからです。\n8本のロープがあなたを縛り付けている場合、どれだけ走り進めるでしょうか？　それは互いに牽制し合う可能性があります。 30歳になると、私は「格上げ（かくあげ）」されたことになります。つまり、学術的には教授、「ジャーナリスト」としては高級ジャーナリストです。29歳の時に格上げされ、今でも稀なことです。しかし同時に大きな混乱も感じました。2000年のシドニーオリンピックの時の掌声はたくさんありました。私は突然「自分は何をすべきなのか？」と自問するようになりました。捨てるべきものは何か？　その年に私が行った最も重要な「減法」は、番組を打ち切ることでした。1年間出演せず、海外に出ることもなく、当時、「司会者」の仕事は、月に一度でも出鏡すれば十分だと言われました。半年以上出鏡しなければ誰も覚えてもらえないと告げられました。私は自分の顔が「廉価（けんか）」だと言いました。\nその年に番組を打ち切って、新しい番組を開発することにしました。これは「痛並快樂着」が終わった後、01年の1年間番組を打ち切ったことに繋がっています。今日私が歩んでいる道全ては、あの時の「減法」を感慨深く思っているからです。当時、私は多くのことができると思っていましたが、スポーツもできますし、E（インターネット）もできますし、色々な面白いことをしたり、制作人として活躍することもできました。しかし、「ニュース」をするのが一番だと考え、突然3つの番組の制作人を辞めて、今日のような自分になったのです。純粋な気持ちでした。先日、同僚と話している時に、「30歳頃に私が決めた非常に重要なことは、色々なことができるにも関わらず、私はニュースをすることを選んだことだ」と話しました。この決断は、副主任になる可能性のある普通の人よりも優れているものでした。\n今も中央电视台の幹部であり、必ずしも大学生出身ではありません。皆さんが私たちの体制を理解していることを知っていますが、私はそれを拒否しました。私は見てみたいと思っていました。大学生はどれくらい進めることができるのか？　大学生の学歴は、常に学習し、研究生に指導するまで、その可能性を追求できますか？　もちろん、今も研究生を指導しており、毎年11人を指導しています。これは「減法」の結果です。もちろん、これは振り返ったものです。若い頃には、奔波の中で、「全てにおいて私は得られるべきだ」と考えることがあり、もし何か一つでも欠けていることや、何か一つのことが完璧でなければ、とても不快に感じていました。\n皆さんも、ぜひ「減法」を学んでください。30歳になる前に、28歳の時に1996年のオリンピックを見て、「缺陷 月がまだ満ち欠けしていない時ほど素晴らしいけれど、常人から見ればそれは欠陥であり、完璧でなく、究極に達していないとしか思えない。人の人生を台無しにする最も効果的な方法は、彼に完璧を求めさせ、究極を目指させることだ。\n花が完全に咲かない\nこの世界はそうではない。花が完全に咲く前こそ最高だ。満ちた花には、すぐに散りゆく運命が待っている。月もまた同様で、満月に近づくと、次第に薄れていく残月へと変わるのだ。だからこそ、私はこれが30歳の私にとって非常に重要な推進力と啓示だと感じている。40歳はあの頃ほど美しくない。しかし、リラックスし、自由になれたと感じたからだ。なぜ、またスーツや革の着こなしに戻らず、幸福を問うべきではないのだろうか？\n四十岁 中国人有一句话说40不惑，30岁是减法，40岁是困惑，不是不惑。我觉得现在这个时代40岁恐怕困惑的是最多的。我的中年危机来的还偏偏很早，到三十六七岁的时候就开始纠结，我干的这一切有价值吗？ 有意义吗？我到底要什么幸福了吗？这本书就是在这个困惑的基础上诞生出来了，在30岁的时候你会发现你的很多幸福目标是与物质挂钩的。三十而立力指的是学历得立。你得有车有房，要不丈母娘都不打算把你媳妇许配给你，很物质，但是40不惑很难。我觉得古人可能是平均预期寿命比现在长，因此它要浓缩40，他就不惑了。我觉得我40正困惑了，物质没有给我带来，我以为会带给我的幸福。同样在40岁的时候，之所以很多人问我，你幸福吗？ 我那书名是幸福浪吗？是问号，代表的是我内心的困惑。中年危机的诞生，40岁你要去回答自己很多的问号，40岁左右要多跟自己聊聊天，要去读很多的东西，给自己一些答案。我很庆幸在我三十六七的时候走进了《道德经》的世界，我在《白说》里头已经谈到，在40岁的时候还要去思考的时候，如果周边的环境不发生改变，尤其是软环境，您心情舒畅的走出家门，到处是乱闯红绿灯的，你买个东西都是假的，打个疫苗。 我说这两天中国都在跟台风两个台风做斗争，一个台风是无形的，一个台风是有形的，无形的台风就是疫苗，它冲击的是我们内心安全的堤坝。 另一个台风，中国很少有从上海登陆的台风，这是题外话，接下来你就要去思考的是，你独善其身，你发生了很大的变化，你拥有了很多的答案，周围的环境不变化，你会幸福吗？我有八个字说得比较重，我觉得我们现在是道德赤字人性亏损，这才是目前最大的赤字和最大的亏损。前些天就在离这不远，我亲眼见到了两个车相撞，其实撞的没那么严重，该负责任的，因为他撞了另一个车，跟人家说咱停到路边，人家好也慢慢说准备停到路边了，前面的车撒丫子跑了，一车人也没有拦着他的。 这会是一个负责任的父亲吗？这会是一个负责任的儿子吗？更不要说他怎么会是一个负责任的公民，而他可能是您的同事，这就是道德赤字和人性亏损也，必然会影响到你。你不管自己是多么一个大写的人，除非你足不出户，但问题是，足不出户也不妨碍您的孩子要打疫苗，您送外卖，那外卖也有可能有问题！ 所以中国人如何学会由一个小老百姓变成一个公民，这可能是在我40岁的时候，既问给自己这个人，也问给社会的一个重要的命题。 如果说30岁是减法，40岁是困惑，我觉得50岁应该是我送给自己的词是好奇，50岁很尴尬，前不着村后不着店，进、可攻；退、要混，也可以。在自己取得的某种东西上躺10年，混到退休也似乎可以。 最近看一本书，其中一本书上写得非常有意思，说在硅谷里真正成功的创业者，五六十岁的偏多，这跟我们的概念是不同的。中国如何什么时候能够不把创业全部当成年轻的事业，就跟中国不该把志愿者都当成青年志愿者一样。上一周我做了一期节目，是中国马上要招募退休的中小学教师，每年有二三万块钱的补助，然后去乡村当老师，而且必须是优秀的。我说这正是开启了退休后再就业的先河，当然不光是慈善了，但是回到50，离那块还有点距离，你怎么去向前走？\n五十歳 50歳の人にとって、最大の課題は2つあります。1つ目は自分自身です。まだ色々なことに興味があるでしょうか？ 人生観はどのようなものですか？ 私自身の50歳の最大の収穫、あるいは今私が生きるやり方は、今日を大切にするということです。20歳の頃は未来ばかりを考えてしまいがちですが、50歳になると過去ばかり思い出すことがあります。しかし、私は自分を抑え込み、未来も過去も気にせず、今日を大切に生きています。50歳の人には、いつも「明日になったら…」とか「昔は良かった…」と言わないように。\n今日なら蔡琴のCDを聴くのが良いだろうと思います。蔡琴が言った言葉の一つがとても良いものです。「写真を見るたびに、2年前の自分の方が綺麗だったと思うけど、2年前の一日も、自分が綺麗だと思っていたことは一度もない。」本当に味がありますね。30歳の頃はそう思っていませんでした。あの頃は自分の欠点ばかり気にしていたけれど、今振り返ってみると…。\n「私も若いんだ」「髪が多かったな」と、過去を振り返ることで、今日を大切に生きる意味が見えてきます。2年後に今の自分を見返して考えるのは、きっと良いことだと思います。\n史铁生さんが言った言葉のように、私の足が動かなくなった時、私は輪椅子いて毎日、走ったりバスケットボールをしたりした日々を懐かしみました。毎日、懐かしむことでとても苦痛でした。 それから数年後、輪椅子いて褥瘡（ろくそう）になって全身に痛みがありました。その時は、以前何も痛わなかった静かな輪椅子いて過ごす時間を懐かえました。 さらに数年経って、私は尿毒症（にょうどくしょう）になり、透析（とうせき）を受けていました。その時、私は褥瘡だけだった輪椅子の時間に戻りたいと思いました。もし、今日を大切に生きることができなければ、残りの50年は無駄になってしまうだろうと。\n五十歳 実は50歳になってからこの道理を理解するのではなく、30代、40代で理解するのが良いと思います。旅行の一食も、食べなければ30年後に食べることになるでしょう。味もわからないかもしれません。だからこそ、今日という日を大切にすることを知ったのは、50歳になった時のことです。\n2つ目は好奇心です。私は、見すぎて、経験してしまって、多くのことに興味を持つのをやめることはできません。むしろ、自分自身で好奇心を刺激するようにしています。今取り組んでいることにも、常に好奇心を持って取り組んでいます。例えば、携帯電話を立てて写真を撮ってもいいのか、会議に参加してもいいのか、オンライン接続はスムーズに行えるのか、もっと面白く、より印象的なものにしたいと考えています。そして、新メディアを使って発信することも可能です。好奇心こそが、人類の進歩を促す最も重要な原動力です。なぜ、個人を促す最重要動力にはなりえないのでしょうか？ある民族が好奇心を失うと、その民族は衰退します。\nさらに大きな視点として、50歳は重要な試練です。40代、50代になると、中国で「既得利益者」とは何でしょうか。私自身を取り巻く多くの人が、若いうちに夢を追いかけるのは素晴らしいことですが、夢を実現したら「既得利益者」になり、他の人が夢を叶えるのを妨げるようになった場合を考えると心配です。以前は嫌っていたやり方で若い人たちや物事に対処するようになります。\nだからこそ、数年前からボランティアとして毎年11人の大学院生を受け入れ、2年ほど育成してきました。現在、5期目となり、すでに55名の純粋な大学院生が卒業しました。既得利益者になることは素晴らしいことです。ある経験や能力を活かして若い人たちを導き、授業の後に食事をご馳走したり、少額のお金を使えば十分です。しかし、これは良い既得利益者がすべきことです。既得利益者は、2つの側面から存在します。一つは、新たな人材に道を切り開く役割です。「私を助けてくれた人に感謝を言うのはいいけれど、感謝の言葉で阻むべきではない」と私は以前から言っています。もう一つの側面は、他の人のために道を切り開くことです。中国において、物質的、経済的、思想的、文化的など、あらゆる分野の既得利益者がなったとき、どのように行動すべきか考える必要があります。昨日、押し車を引いていた人が、今度は列車を止める立場になるかもしれません。中国の歴史には、このようなことが何度も繰り返されてきました。しかし、そうではありません。時には、もっと多くなることもあります。だからこそ、すべての既得利益者が、若い頃のように希望を持って行動するよう呼びかけています。私が十分に良いことをできなかったとしても、考えて、行動し、発言することを心がけています。\n","date":"2020-02-14","language":"ja","permalink":"https://ttf248.life/ja/p/about-time-and-books/","tags":["白岩松 (Hakken Matsu)","講演 (こうえん)"],"title":"時間の経過についてですが、答えを見つけるには多くの本を読む必要があります。","year":"2020"},{"categories":["コンピューター"],"content":"カスタムディストリビューターは、パフォーマンスを向上させ、メモリ使用効率を高め、頻繁な少量のメモリ割り当ての問題を解決できます。\n前因 近頃、ネットワークパケットの開発に携わり、頻繁に小さなメモリ領域を申請し解放する必要があり、当初はメモリプールを使用することを検討していました。いくつかの既存のメモリプールを確認したところ、この https://github.com/cacay/MemoryPool を見つけました。インターフェースを見たとき、このメモリプールの実装が少し奇妙だと疑問に思いました。「MemoryPool」の実装ロジックは、固定サイズのメモリ領域を申請することです。boostのメモリプールインターフェースを見てみると、テンプレートを提供し、使用時にインスタンス化します。ちょうどこのライブラリには、allocatorという概念について言及した記事があります。\n#### [wiki](https://zh.wikipedia.org/wiki/%E5%88%86%E9%85%8D%E5%99%A8_(C%2B%2B)) C++プログラミングにおいて、割り当て子（英語：allocator）はC++標準ライブラリの重要な構成要素です。C++のライブラリには、リスト、集合などのように、さまざまな「コンテナ」と呼ばれるデータ構造が定義されており、これらのコンテナの共通の特徴は、プログラムの実行時にサイズを変更できることです。この機能を実装するために、動的メモリ割り当てが必要となります。割り当て子は、これらのコンテナがメモリへの割り当てと解放のリクエストを処理するために使用されます。言い換えれば、割り当て子は、標準テンプレートライブラリ（STL）コンテナのメモリ管理に関する低レベルの詳細をカプセル化します。 割り当て子は、アレクサンドル・ステパノフによってC++標準テンプレートライブラリ（STL）の一部として最初に発明されました。その目的は、「ライブラリをより柔軟にし、低レベルのデータモデルに独立した方法で利用できるようにする」ことであり、プログラマがライブラリ内でカスタムポインタや参照型を使用することを可能にするものでした。ただし、標準テンプレートライブラリをC++標準に組み込む際、C++標準委員会は、完全なデータモデル抽象化処理が不可受容なパフォーマンス低下をもたらすことを認識しました。そのため、妥協策として、割り当て子の制限がより厳しくなり、ステパノフの当初の構想と比較して、現在の標準で記述されている割り当て子のカスタマイズ性は大幅に制限されています。 割り当て子のカスタマイズは制限されていますが、多くの状況ではカスタム割り当て子が必要となります。これは通常、異なる種類のメモリ空間（共有メモリと回収されたメモリなど）へのアクセス方法をカプセル化したり、メモリプールを使用したメモリ割り当てのパフォーマンスを向上させたりするために行われます。さらに、メモリ使用量と実行時間から見ると、頻繁に少量のメモリを割り当てるプログラムでは、専用の割り当て子を作成することで利益を得ることができます。 #### [使用需求](https://zh.wikipedia.org/wiki/%E5%88%86%E9%85%8D%E5%99%A8_(C%2B%2B)) カスタムアロケータの主な理由は性能向上です。専用のアロケータを使用することで、プログラムのパフォーマンスを向上させたり、メモリ使用量を削減したり、あるいは両方を組み合わせることも可能です[4][8]。デフォルトのアロケータは`new`演算子を使用してストレージスペースを割り当てるため、これは通常C言語のヒープ割り当て関数（`malloc()`）によって実装されます[9]。ヒープ割り当て関数は、偶発的な大量メモリ割り当てを最適化するように設計されているため、ベクトルや双端キューなどの、一度に大量のメモリを必要とするコンテナにメモリを割り当てる場合は、デフォルトのアロケータは通常効率的です[8]。しかし、連想コンテナと双方向リストのような、頻繁に少量メモリを割り当てて解除するコンテナの場合、デフォルトのアロケータを使用すると、通常効率が低下します[4][9]。さらに、`malloc()`に基づくデフォルトのアロケータには、より悪い参照局所性や、メモリの断片化を引き起こす可能性があるなど、多くの問題があります[4][9]。 要するに、このセクション（……）（まるで）は、この標準におけるアロケータに関する「夢を見た」のスピーチです。夢が実現する前に、移植性を重視するプログラマーは、ステートレスなカスタムアロケータを使用することになります。 ——スコット・メイエス，《Effective STL》 上記を踏まえ、メモリ割り当ての頻度が多い場合に、メモリプールベースのアロケータを使用して問題を解決することがよくあります[8]。オンデマンド割り当てとは異なり、メモリプールベースのアロケータを使用する場合、プログラムは事前に大きなブロックのメモリ（つまり「メモリプール」）を割り当て、次にメモリを割り当てる必要がある場合、カスタムアロケータは、リクエスト元にプール内のメモリへのポインタを返します。オブジェクトが破棄される際には、実際の割り当て解除を行うのではなく、メモリプールのライフサイクルが終了するまで遅延させます[注 1][8]。 「カスタムアロケータ」というトピックに関しては、多くのC++専門家や著者がこの分野で議論しており、スコット・メイエス著の《Effective STL》やアンデル・アレクサンドレスク著の《Modern C++ Design》に言及しています。メイエスは、特定の型`T`のアロケータのすべてのインスタンスが等しいという要件を満たす移植可能なアロケータのインスタンスにはステートを含めない必要があると洞察しており、ステートレスなアロケータの使用を推奨しています。C++標準はライブラリの実装者が状態を含むアロケータをサポートするように奨励していますが、メイエスは「このセクションは、（まるで）素晴らしい見方ですが、ほとんど空言であり」、アロケータの制約は「過度に厳格」であると述べています[4]。たとえば、STLの`list`は`splice`メソッドをサポートしており、これは1つのリストオブジェクト`A`のノードが別のリストオブジェクト`B`に直接挿入されることを意味し、`A`のアロケータによって割り当てられたメモリが`B`のアロケータによって解放される必要があるため、`A`と`B`のアロケータインスタンスは等しいことが導き出されます。メイセスの結論は、アロケータはステートレスな静的メソッドの型として定義するのが最善であるということです。たとえば、C++標準では、アロケータは`rebind`メソッドを実装するその他のクラステンプレートを持つ必要があります。 さらに、ヤン・ストローストルップ著『C++プログラミング言語』では、「割り当てを厳密に制限し、各オブジェクトの情報を異なるようにすることについては、明らかに問題ありません」（大意）と述べており、ほとんどのアロケータはステートを持たず、ステートを持たない場合でもパフォーマンスが向上するという意見を示しています。彼は、メモリプール型アロケータ、共有メモリ型アロケータ、ガベージコレクション型アロケータの3種類のカスタムアロケータを提案し、内部メモリプールを使用して少量メモリを高速に割り当て/解除するアロケータの実装を示しました[3]。ただし、このような最適化は、彼の提供したサンプルアロケータで既に実現されている可能性があると彼は指摘しています。 カスタムアロケータのもう1つの用途は ","date":"2019-12-30","language":"ja","permalink":"https://ttf248.life/ja/p/standard-library-container-memory-allocator/","tags":["c++","allocator"],"title":"標準ライブラリコンテナのメモリ割り当て子：allocator","year":"2019"}]