今日のPython

計算の道筋は短い。現地時刻を zoneinfo の Asia/Tokyo つきで作り、UTC へ変換してから swe.julday でユリウス日にする。太陽と月は calc_ut、上昇点は houses_ex にホールサイン指定で取り、いずれも get_ayanamsa で得たラヒリの値を引いてサイデリアル黄経へ直す。時刻を2時間動かした場合、太陽は約0.085度、月は約1.006度に対し、上昇点は円周上を約39.692度も進む。

占星術的な解釈には踏み込まず、記事が扱うのは入力から出力への感度だけ。そのうえで、結果データに何を残すかを設計として挙げる。

• タイムゾーンは IANA の地域名で保存する。`UTC+9` のような固定差分は捨てる
• 星座名のほか、黄経・区分番号・区分内度数・境界までの距離を分けて持つ
• 使った暦、黄道の種類、ayanāṃśa、ハウス方式、ノードの種別を版つきで添える
• 出生時刻が不明なら一点に固定せず、候補の時間帯をまとめて計算する

最後の一項が効くのは、まさに今回のような境界付近の例だろう。分類名だけを保存すると、境界から0.1度の位置と15度の位置が同じ顔をしてしまう。時刻不明の出生記録は、結果を「範囲内で不変」「境界を跨ぐ」「時刻不足で確定不能」に分ければ、不確実さをそのまま画面へ出せる。

再計算で値がずれたときの切り分け順も示す。Swiss Ephemeris のバージョン、使用フラグ、ephemeris file、UTC 変換、ayanāṃśa、ハウス方式。同じ出生情報から違う図が出たとき、バグなのか設定差なのかを追える形にしておくこと。それが、この記事の主張である。

Lambda が載るCPUの世代は指定できない。そこで関数の中から /proc/cpuinfo の CPU part を読み、0xd40 すなわち Graviton3 で動いた回だけを残して平均を取る。30回のうち有効なのは、メモリサイズごとに9〜24件。リージョンの違いや時間帯による揺れ、バーストがどれだけの時間続くのかは、測定の対象から外してある。

初期化フェーズの最初の10秒間は、メモリ量に比例したCPUではなくホスト側の容量のバーストが割り当てられる。その割り当ては実行環境で動くプロセス全部の共有物で、Lambda Extensions も例外ではない。独立したプロセスとして走る Extension は、公式ドキュメントの記述どおり関数本体とCPUを分け合い、2プロセスを立てた検証と同じ形の結果になった。ライブラリの import 時間も同じ枠組みで測っている。

閾値を越えた先の振る舞いも押さえてある。2304MB 以上では設定値に応じて割り当てが増えていく。つまりこの下駄は上限ではなく下限として働く、というのが記事の見立てで、小さいメモリを設定している関数ほど恩恵は大きい。

初期化フェーズが課金対象になった今も、重い import やクライアント生成をそこへ寄せる定石は変わらない、と結論づける。ただし寄せた処理をマルチプロセス化しても、2048MB以下ではまったく速くならない。並列化で稼げるつもりでメモリを削ると、そこだけ計算が合わなくなる。

湿度から水蒸気圧を出す部分は Tetens の式、そこに日射のない室内を前提とした簡易式を重ねる二段構え。5段階のしきい値は日本生気象学会の熱中症予防運動指針を参考にしたもので、環境省が発表する熱中症警戒アラートとは別の、あくまで簡易的な目安という位置づけになる。輻射熱を拾う黒球温度が構成から抜けている以上、直射日光の下へそのまま持ち出す使い方は想定外。

手が止まったのは計算式より配線の側だった。OLED と DHT11 が同時に OSError の ETIMEDOUT（Errno 110）を返す場面で、両者は別々のピンを使っているのだから、個々の結線を疑うより先に 3.3V と GND という共通部分を見るほうが早い、という切り分けを置く。

• machine.I2C を開いて i2c.scan() を呼び、0x3C が見えるか確かめる
• 空のリストが返るなら配線側の問題
• 実際の原因は、ブレイクアウトボードと Pico の挿し込みが甘い半挿入

見た目では気づきにくいので、複数のデバイスがまとめて落ちたら全体を挿し直す。もうひとつの罠が Thonny からの micropython-ssd1306 のインストールで、Windows のユーザー名に日本語が入っていると通らない。顔アイコンを framebuf の基本図形だけで描く draw_face() の実装、結線図とピン対応表、main.py を本体に保存して PC を外しても動かす手順は、著者のブログ側にまとめられた。

検証は before → gate → after の直列3ノードで、gate の中だけで interrupt() を呼ぶ形。各ノードは呼び出し回数をカウンタに刻むだけの純粋な関数にしてあり、LLM は一切絡まない。何回走ったかを数値で見るための設計。環境は Linux x64 / Python 3.11.15 に uv で仮想環境を作り、langgraph 1.2.11、langgraph-checkpoint 4.2.0、langgraph-checkpoint-sqlite 3.1.1 を入れる。

条件を変えて走らせた組み合わせは5つ。

• checkpointer なしで invoke()：止まるが例外なし
• checkpointer なしで Command(resume=…)：RuntimeError
• InMemorySaver ありで resume せず再 invoke()：前段ノードが二重に走る
• SqliteSaver で別プロセスから resume：前段を再実行せず完了

厄介なのは、中断したときの戻り値が truthy な辞書だという点。通常の状態辞書に __interrupt__ キーが加わっただけの形なので、`if result:` のような素朴な判定はそのまま通過する。スケジュール実行や CI のような無人環境では、承認待ちで止まったグラフが完了扱いで素通りしていく。

公式ドキュメントは interrupt の利用条件として checkpointer を明記しているのに、要件を満たさない呼び出しでも実行時には何も知らせが出ない。不足が表面化するのは、中断から再開までを一周させたときだけ。resume を忘れた再実行では前段ノードの副作用が実行回数ぶん積み上がり、中断中のスレッドへ別の入力を渡すと状態がマージされて履歴が書き換わる、とも記事は書く。承認待ちを跨ぐ処理なら、ファイルに落ちる checkpointer と Command(resume=…) の組み合わせが前提になる。

確定までに一度回り道が挟まる。最初の仮説は「警報が出ない日が続いただけ」で、これを潰すために天気系まとめサイトの警報ページと突き合わせようとした。ところが市区町村単位で警報なのか注意報なのか、発表時刻はいつかを自分のログと同じ粒度で照合できず、切り分けにならない。旧パスと新パスを実際に叩いて中身を比べて、ようやく凍結と確定した。ただし両方とも同じ発表元なので独立した対照群ではない、と記事自身が断っている。

前提も率直に並ぶ。扱っているJSONは気象庁サイトが画面描画に使う内部データで、仕様やSLAが公開されたAPIではない。機械処理の形式としては公開仕様の防災情報XMLが基準で、登録不要のPULL型配信も停止・遅延がありうる非保証の提供。非保証のデータ源を主系統に置いたのは設計判断だ、と位置づけている。新パスに現れる文字列も公開された版体系ではなく、旧URLが移行措置なのか取り残されたのかは説明が無い。

直した後にも穴が残る、として並べているのが次の点。

• 3週間というしきい値に厳密な根拠は無い
• 参照先は都道府県コードではなく気象台の担当区域コードで、複数区域に分かれる県がある
• 注意報に加え、通常の波浪警報と高潮警報は現行実装の対象外

事故そのものの記録は筆者の内部ログに基づく。第三者が独立に確かめられるのは、旧パスがいまも5月28日の日時を返すという一点だけ、と範囲を区切っている。

寸法はモジュールと歯数から芋づる式に出る。ピッチ円直径はモジュール×歯数で6.0mm、外径はモジュール×(歯数+2)で6.6mm。歯の高さも同じ理屈で、ピッチ円から歯先まではモジュールぶん、歯元側にはクリアランス係数0.25を足した深さを取る。圧力角は標準の20°。手で図面を引く代わりに、数字を1つ書き換えれば残りの寸法が全部ついてくる。

小さな1枚を作ったあとは、モジュール2.0・歯数18へ大きさを変え、18枚と36枚を2段でかみ合わせるところまで進む。かみ合う2つの軸の間隔は互いのピッチ円直径から決まり、そこにφ8の軸穴、2mm×1mmのキー溝、重さを減らす肉抜き穴が乗る。3Dプリントで出すことを見込んで、歯と歯のすき間には0.15mmのバックラッシュを入れてある。歯数が17枚を下回ると歯元が削れるアンダーカットが起きるため、転位で逃がす。

読み手として想定されているのは高校生で、モジュールが歯の細かさを表す数字だという話から順に説明が積まれる。歯車は規則正しい繰り返しなので、1歯の断面が正確なら全周も正確になる。回転コピーという作り方は、その性質をそのまま手順にしたもの。コードは MIT ライセンスで公開され、改造して課題に使ってよいと書かれている。

検証は2026年7〜9月の16開催日・612レース分の単勝オッズ時系列で、相関はSpearman、日ごとに算出している。装置そのものは動いていた。オッズの辞書が空でないかを検品し、値も正常な範囲に収まっていたからだ。予想オッズは各馬のオッズとして自然な数値で、レース全体の1/オッズの合計も実オッズとほぼ同じ1.25前後、人気順も破綻していない。壊れていない装置ほど、疑うきっかけが無い。

土曜の夜、日曜のレースはまだ発売されていない。提供元はその時間帯に限って実売オッズの代わりに独自の予想値を返し、理由の欄には履歴オッズが空である旨が入っていた。予想が高めに見積もった馬は朝に売られ、実勢へ戻っていく。その収束の動きが、直前の資金フローと逆向きに見えていた。公式更新時刻のフィールドが全レース土曜20時15分前後の一括生成だったのも、後から見れば痕跡である。

一般化として挙がるのは三つ。値の分布を見る前に status・flag・source・mode の類を曜日×時刻でクロス集計すること。曜日や時刻でパターンが割れたら、観測対象の性質より先に取得手順を疑うこと。そして「直った」も疑うこと。この装置は7月に2度壊れて2度直り、3度目の今回は壊れてすらいなかった。

適用範囲も添えてある。夏開催の日曜は前夜時点で36レース中34レースが予想値、土曜レースと秋開催初週の日曜は全て実オッズ。記事は分析・検証の記録であって、馬券購入の推奨ではないと断ってある。

Astra の呼び出し口は bedrock-runtime と bedrock-mantle の2系統に分かれ、モデルID も使える API も違う。モデルカードでは Prompt Caching が mantle 側の機能一覧に並び、Guardrails とアプリケーション推論プロファイルは runtime 側の Converse に並ぶ。記載どおりなら、キャッシュを取るかガードレールを取るかの二択になるはずだった。実測では両方のエンドポイントで読み書きが立ち、二択にはならなかった。

新しいコンソールには、どちらのエンドポイントをいつ使うかの基準を示すパネルがある。そこに Prompt Cache は片方にも挙がっていない。エンドポイントは、サーバ側のツール利用やプロジェクト管理、ガードレール、推論プロファイルといった他の機能で選ぶ話になる。

どこまで言えるかについては、記事自身が線を引いている。暗黙のキャッシュは best effort で、同じ条件でも毎回当たる保証はない。クロスリージョン推論は実際の処理先が動きうるため、離れたリージョンから読めたという1回の観測から、キャッシュの物理的な共有範囲や内部のキー仕様までは踏み込めない。

試していないと明記されている範囲も広い。

• 繰り返し測定による再現性
• アカウントをまたぐ共有
• 272K を超える長い文脈
• Chat Completions での明示的な指定

次に確かめたいこととして挙がるのは、Responses API の設定更新で会話の途中に effort を変えたとき、書き込み済みのプレフィックスがどう再利用されるか。GA の翌日に取られた観測である点は、読む側が差し引いておく前提になる。

45通りの中身は、発動幅の係数 k が5水準、決済時間が3水準、損切り幅が3水準の組み合わせ。両方向でまったく同じ格子を使い、調整側で最も成績が良かった1条件だけを取り出して、もう一方の期間に当てている。ラベルを付け替えるのではなく、選択手続きごと組み直したのが要点。

途中で別の罠も踏んでいる。調整期間と検証期間の順位相関が rho=0.73〜0.94 と高く出て、条件の優劣は期間をまたいで安定しているように見えた。中を割ると、平均Rが k と損切り幅の両方について完全に単調。R は損益をリスクで割った値で、そのリスク自体が k と損切り幅で決まるため、小さくすれば分母が縮むだけでRが上がる。通貨単位の損益で測り直すと、金の相関は p=0.097 まで落ちて有意でなくなった。

分割をずらす拡大窓のローリング検証（2016〜2026年の11回）では信頼区間が0をまたがず、いったん「有効」が出る。ところが内訳を割ると、成績はまるごと2021年以降から来ていた。金は2026年を1年抜くだけで年平均が +3.484 から +1.956 へほぼ半減する。

記事自身が置いている限界も明示されている。

• グリッドの範囲も選択基準も窓の切り方も、データを見たあとに決めたもの
• コストは金1.5ドル、ドル円6pips という仮定で、動かせば結論も動く
• 元データは再配布の許諾が確認できず、公開は集計値・図表・方法論のみ

結局この題材で言えるのは「期間による」まで、というのが著者の着地点になっている。

採点を単純にするための工夫が先にある。答えを固定の2語に絞れば、文字列の一致だけで正解を判定でき、審判役の別モデルも採点基準表も要らない。ただし落とし穴が1つ。safe という文字は unsafe の中に含まれているので、部分一致で数えると unsafe の答えが全部正解になる。単語単位で照合する1行の修正で済むが、見落とせば数字が静かに壊れる。

学習したのはモデル本体ではなく、上に載せる小さな LoRA アダプタ。10億を超えるパラメータは凍結したまま、約10MB・ベースの0.17%にあたる差分だけを訓練する。外せば元のモデルに戻り、付ければ調整済みになる。だから保存も差し替えも比較も安い。4bit に圧縮したモデル、小さいバッチ、短い入力、訓練する層を絞る設定は、すべて8GBという上限から逆算したもの。もっとも、実際に使ったのは約1.8GB。構えた天井は、結局効いてこなかった。

止め方も記録されている。400ステップ回して検証損失を見て、200ステップの時点に戻す。データは Civil Comments で、各コメントに付いた毒性の値（人間の評価者のうち何割が毒性ありと判断したか）が70%以上のものを unsafe とした。本物のコメントには実際に毒性のあるものが含まれるため、テキスト自体はリポジトリに入れず、導出したラベルと最終的な数字だけを公開する方針を採っている。

記事はそもそもファインチューニングすべきかという問いにも触れる。プロンプトの改善で届くならそちら、モデルが知らない事実が要るだけなら検索で渡す。繰り返される定義の明確な1つの作業を、長いプロンプトなしで毎回同じようにやらせたいとき、2値分類はまさにその形をしている。

幅を標準偏差ではなく最小値と最大値で持つのは、5つの標本で分布を名乗る資格がないから。見えた値をそのまま置けば、読む側が基準と突き合わせて検証できる。許容値をスイート全体に1つ置く作りも捨てた。判定がほぼ決定的なケースと、境界線上の項目でコインを投げるケースを同じ重さで扱っていたため。ゆらぎはスイートの性質ではなく、検査ごとの性質。幅は必ず承認済みの基準側のものを使い、当日の走行に自分の言い訳を広げさせない。安定さを失ったモデルの中に劣化が隠れる道を塞ぐため。

失われた1時間より重いのは、その先で起きること。週に一度から騒ぎする門は、月末には無言でクリックされるようになる。誤報の害は騒がしさではなく、本物の警報を素通りする習慣を育てること。

実際に誤報だった回の内訳は分かれた。

• 適合率は基準の幅の外へ出て、劣化として立った
• 正解率の下がりは幅の内側に収まっていた
• 宣言したしきい値だけを見る見方では21件中1件が引っかかる

次の課題も挙がる。点数が動かないまま判定者の理由づけが変わっているなら、それは偶然当たっているだけで、点数に置いた幅では見抜けない。判定者の文章そのものを残すこと、提供元が出すならモデルのフィンガープリントを別名の横に置くこと。決定は ADR として公開され、3回分の走行と基準・比較結果はコミットを固定した fixtures に置かれている。

検定の手前でやっているのは地味な結合作業で、約定ごとの価格・数量・売買方向・時刻・確定損益といった記録に、その日の市場心理の区分を貼り付けている。比較は二段構え。恐怖側（Fear と Extreme Fear）と強欲側をひとまとめにした直接対決と、5区分を個別に並べた内訳だ。心理の区分が切り替わった日とそれ以外の日を比べる補助チェックも置かれている。

内訳を見ると、極度の強欲は平均損益も勝率も最下位で、値動きを追いかけて外し、当たった分も損を埋めきれないという熱狂相場の典型がそのまま出ている。極度の恐怖はその逆で、勝率は強欲より低いのに平均は全区分で最高。多くの取引は負けていて、パニック時の数回の大きな当たりが平均を引き上げているというテールリスク型の形をしている。地味に目を引くのは中立で、勝率54.3%は全区分でいちばん高く、損益も中位に収まる。退屈で安定した局面という言い方がいちばん近い。

記事自身が、結論を強く言えない理由を並べている。

• 損益の分布は正規から遠く、少数の大勝ちが平均を作る
• 区分ごとの標本数が確認できておらず、薄い区分の極端値は当てにならない
• 心理の極端さとボラティリティは同時に起きるため、値動きのほうが動いている線が残る

次の一手として挙がっているのは、平均に頼らないマン・ホイットニーのU検定と、口座単位で利益がどれだけ偏っているかの確認。ノートブックと統計の詳細、図はリポジトリに置かれている。

ノードは銘柄、エッジは相関。銘柄ごとの履歴だけを見る予測が捨てている「一緒に動く」という性質を、グラフの形で拾いにいく設計になっている。ノードが持つ特徴は4系統を連結したもので、GRU が直近10日の価格と出来高をまとめて32次元に畳み、FinBERT が Yahoo Finance の見出しから強気・弱気・中立の3次元を出し、業種の5次元と市場全体の3本を足す。市場側に選ばれたのは VIX、10年債利回り、金ETF で、それぞれ恐怖・無リスク金利・逃避需要という理由が添えてある。価格と出来高は銘柄ごとに別々に正規化する。出来高の桁がそのままだと価格を飲み込むから。

相関の窓が30日で動くので、グラフの繋がり方は時点ごとに変わる。2年分をひとつの相関行列で代表させるのではなく、市場の構造が局面で組み替わるところまで見せる作りにしてある。量子回路はシミュレータ上で動かしており、実機ではない。

面白いのは、著者が持ち帰った教訓のほとんどが量子と関係なかったところ。

• ウォークフォワードでの検証は譲れない
• ハイブリッドなモデルに学習率をひとつだけ与えるのは、静かに失敗する型
• 静的な特徴を動的なもののように見せかけると、周りをいくら調整しても何も起きない

量子回路を訓練する感触については、遅く、学習率に異常なほど敏感、と書かれている。記事の末尾には data re-uploading や Graph Attention Networks など6本の参照が並び、限界を書いた節がいちばん大事だと冒頭で断ってもいる。

選択に要る情報は二重に置かれる。wheel ごとの dist-info/variant.json と、インデックス側の {name}-{version}-variants.json。前者があるのでローカルのディレクトリからでも選べ、後者があるので依存解決のたびに wheel 本体を落とさずに済む。pylock.toml にも [packages.variants-json] として同じ内容を書き込めるので、ロックファイル単体で完結する。

並べ替えの順序も決まる。まず従来のプラットフォームタグで絞り、次に対象環境が満たす property を調べ、メタデータ側が持つ namespace の優先順で比べていく。どれにも当てはまらなければ、property を1つも持たない null variant が受け皿になる。変種を持たない普通の wheel は、その下。

決定を揺らさないための約束も付いている。

• 同じラベルは、そのリリース中のどの wheel でも同じ property を指す
• default-priorities の namespace 列は一致するか、片方がもう片方の延長である
• 複数のインデックスをまたぐ場合、その保証は無い

後方互換性の節には、噛み合わない相手が並ぶ。ファイル名を厳しく検査するツールは要素が1つ増えた wheel を弾き、検査しないツールは取り違えて入れてしまう。名前が長くなるぶん Windows のパス長にも触れている。新しいマーカーを知らないリゾルバは、読めない条件に当たって後戻りを始める。そして肝心の部分、つまりどの property を環境が満たすと判断するか、名前空間を誰が決めるか、変種 wheel をどう作るかは、範囲外として後続の PEP に送られた。形式だけが先に固まった段階にある。

破壊的変更として名指しされているのは、vision 側のロータリー位置埋め込みだけ。2D と 3D の扱いが標準化され、アテンション層の中や個別モデルの中に RoPE のグリッド交互配置を抱えていたコードは、中央の実装を呼ぶ形に書き換えなければならない。逆に言えば、そこに触れていない利用者に影響は及ばない。

新しく入った6本は、系統がばらばらで面白い。

• HYV4 は1トークンあたり49B を活性化する 780B の MoE。Multi-head Latent Attention と DeepSeek Sparse Attention、Independent Hyper-Connections を持つ
• VibeVoice は大規模言語モデルの構造の中で next-token diffusion を回し、複数話者の長尺音声を合成する。ポッドキャストやオーディオブックを想定
• NeoMME はテキストと画像パッチを1つの Transformer で処理する多言語エンコーダ。検索向けに調整した派生もある
• Fun-ASR-Nano / KimiLinear / Canary-1B-v2 は中英日のホットワード指定つき音声認識、per-channel forget gate を持つ Kimi Delta Attention の混成、Fast Conformer エンコーダを再利用した多言語 ASR と音声翻訳

地味な修正の側も、動かしている環境によっては効く。Qwen 系の FP8 埋め込みの扱いとテンソル並列でのレイヤ上書きが直り、量子化キャッシュの不具合と、キャッシュの文脈なしに呼ばれた paged attention の失敗も塞がれた。生成では、リモートファイルを無条件に取りに行く挙動も止まっている。速度と正しさの両方に、細かく手が入った版。