Python

moomoo証券（ムームー証券）が2026年3月13日、国内主要ネット証券としては業界最速級となる米国株APIトレードサービス「moomoo OpenAPI」の提供を開始した。個人投資家が自作プログラムで米国株のリアルタイムデータ取得から自動売買までを実行できるようになる。 moomoo OpenAPI とは moomoo OpenAPIは、プログラムを通じて米国株取引を自動化できるAPIサービスだ。Nasdaq上場企業であるFutu Holdings傘下のmoomoo証券が提供しており、世界2,900万人以上のユーザーを支えるグローバルな技術基盤をベースにしている。 なお、moomoo OpenAPIの対応市場は米国株、香港株、中国A株の3市場であり、日本国内株には対応していない。国内株のAPI取引が必要な場合は、後述するkabu STATION APIなど別のサービスを検討する必要がある。 これまで国内の個人投資家が米国株のAPI取引を行おうとすると、海外証券会社（Interactive Brokersなど）を利用する必要があったが、moomoo OpenAPIにより国内証券でも本格的なAPI取引が可能になった。 主な機能 リアルタイム相場データの取得 株価、板情報（オーダーブック）、約定データなどをリアルタイムで取得できる。取得したデータは独自の分析ロジックやダッシュボードに活用可能だ。 自動売買の実行 プログラムによる自動発注に対応しており、以下のような運用が可能になる: 損切り・利確ルールの自動化: あらかじめ設定したルールに基づく自動決済 アルゴリズムトレード: 移動平均やRSI（相対力指数）などのテクニカル指標に基づく自動売買戦略 スケジュール売買: 特定の時間帯やイベントに連動した自動注文 バックテストとペーパートレード 過去の市場データを使った戦略検証（バックテスト）が可能。さらにペーパートレード（模擬取引）機能により、実際の資金をリスクにさらすことなく、戦略の動作確認ができる。 外部ツール連携 ExcelやGoogleスプレッドシート、自作のダッシュボードとのデータ連携もサポートしている。 対応開発環境 公式SDKが以下の言語で無料提供されている: Python Java C# C++ JavaScript 対応OSはWindows、macOS、Ubuntu、CentOSなど幅広い環境をカバーしている。 特にPythonでは、pipコマンドひとつで開発環境を構築できる: 1 pip install moomoo-api データ分析や機械学習と組み合わせた投資戦略の構築がしやすい点が魅力だ。 差別化ポイント：機関投資家レベルのデータ moomoo証券の強みである「大口投資家の動向」や「空売りデータ」もAPI経由で取得できる。通常、個人投資家がアクセスしにくいこれらのデータをプログラムから自動取得できるのは大きなメリットだ。 利用するには moomoo証券の口座を開設し、OpenAPIの利用申請を行う必要がある。公式ドキュメントは以下で公開されている: 公式APIドキュメント: openapi.moomoo.com Python SDK（GitHub）: MoomooOpen/py-moomoo-api 国内API取引の選択肢 これまで国内で株式のAPI取引を行う場合、主な選択肢は限られていた: kabu STATION API（三菱UFJ eスマート証券、旧auカブコム証券）: 国内株・先物・オプションのAPI取引に対応 楽天証券 MarketSpeed II RSS: Excel連携による国内株の自動売買（米国株は非対応） Interactive Brokers: 海外証券だが日本語対応あり、米国株API取引可能 moomoo OpenAPIは、国内証券で米国株に特化したAPI取引ができる点で新しい選択肢となる。 ...

GPUなしで毎秒100ページ以上のPDF→Markdown変換を実現するオープンソースツール「OpenDataLoader PDF」が話題になっている。Apache 2.0ライセンスで完全無料、CPUのみで動作するため、高価なGPUハードウェアは不要だ。 OpenDataLoader PDF とは OpenDataLoader PDF は、PDFドキュメントをAI活用に適した構造化データ（Markdown、JSON、HTML等）に変換するオープンソースのパーサーだ。Java で実装されており、Python・Node.js・Java から利用できる。 主な特徴: 超高速処理: ローカルモードで 0.05秒/ページ（CPUのみ）、8コア以上のマシンでマルチプロセスバッチ処理すると毎秒100ページ以上 GPU不要: CPUだけで高速に動作するため、導入コストが低い 高精度: ベンチマークで総合精度0.90を達成し、読み順・テーブル・見出し抽出で1位 Apache 2.0ライセンス: 商用利用可能な完全オープンソース インストール Python パッケージは Java CLI のラッパーのため、Java 11以上とPython 3.10以上が必要だ。 1 2 3 4 5 # Python pip install -U opendataloader-pdf # Node.js npm install @opendataloader/pdf Java の場合は Maven で opendataloader-pdf-core を依存関係に追加する。 基本的な使い方 Python でのシンプルな変換 1 2 3 4 5 6 7 import opendataloader_pdf opendataloader_pdf.convert( input_path=["file1.pdf", "file2.pdf", "folder/"], output_dir="output/", format="markdown,json" ) フォルダを指定すれば一括変換も可能だ。出力形式は Markdown、JSON、HTML、プレーンテキスト、注釈付きPDFから選べる。 ...

redis-py の Lock クラスは UUID ベースのトークンでロックの所有権を管理するが、フェンシングトークン（単調増加する数値）は提供しない。しかし、Lock クラスは do_acquire や Lua スクリプトをオーバーライドできる設計になっており、サブクラス化でフェンシングトークンを追加できる。 本記事では、redis-py の Lock を拡張してフェンシングトークンを発行する FencedLock クラスの実装例を紹介する。 前提知識：Redis の Lua スクリプティング Redis はバージョン 2.6 から Lua スクリプトの実行機能を内蔵している。EVAL コマンドで Lua スクリプトを Redis サーバー上で直接実行でき、複数の Redis コマンドをアトミック（不可分）に実行できる。 なぜ Lua スクリプトが必要か 通常、Redis コマンドは1つずつ実行される。例えば「キーが存在しなければセットし、同時にカウンターをインクリメントする」という処理を2つのコマンドで行うと、その間に他のクライアントが割り込む可能性がある： クライアント A: SET mykey value NX → 成功 ← クライアント B が割り込む余地 クライアント A: INCR counter → インクリメント Lua スクリプトを使えば、この2つの操作を1回のアトミックな呼び出しにまとめられる： 1 2 3 4 5 6 -- Redis サーバー上で実行される（他のコマンドは割り込めない） local ok = redis.call('SET', KEYS[1], ARGV[1], 'NX') if ok then return redis.call('INCR', KEYS[2]) end return nil Redis CLI での実行例 1 2 # EVAL "スクリプト" キーの数 キー1 キー2 ... 引数1 引数2 ... redis-cli EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue redis-py での実行例 1 2 3 4 5 6 7 8 9 10 import redis r = redis.Redis() # 方法1: eval で直接実行 r.eval("return redis.call('SET', KEYS[1], ARGV[1])", 1, "mykey", "myvalue") # 方法2: register_script で事前登録（推奨） # サーバー側に SHA1 でキャッシュされ、2回目以降はスクリプト本文の転送が不要 script = r.register_script("return redis.call('GET', KEYS[1])") result = script(keys=["mykey"]) セキュリティ上の注意 Lua スクリプトのパラメータは KEYS[] と ARGV[] で渡される。SQL のプリペアドステートメントと同様に、パラメータが文字列としてスクリプトに展開されることはないため、パラメータ経由でのインジェクションはできない。ただし、ユーザー入力でスクリプト文字列自体を動的に組み立てると危険なので、スクリプトは固定文字列として定義すること。 ...

Andrej Karpathy が2026年3月に公開した autoresearch は、AIエージェントにLLMのトレーニングを丸投げするツールだ。GPU1台・一晩放置するだけで、エージェントが自律的にコード修正→実験→評価を繰り返し、人間の研究者なしで性能を改善していく。 実際に Karpathy 自身が約700回の実験を実行したところ、GPT-2の学習時間が2.02時間→1.80時間へ11%短縮された。さらに別の開発者は、8時間・37実験で0.8Bモデルが従来の1.6Bモデルを19%上回るスコアを叩き出している。 autoresearch の仕組み autoresearch はわずか630行のPythonで構成されており、3つのコアファイルで動作する。 3つのコンポーネント ファイル 役割 編集者 program.md エージェントへの指示書（戦略・ルール・評価基準） 人間 prepare.py データ準備・トークナイザー・評価関数（固定） 変更禁止 train.py モデル・オプティマイザ・学習ループ AIエージェント エージェントループ エージェントは以下のサイクルを自動で繰り返す: program.md を読んで戦略を把握 train.py を修正（アーキテクチャ変更、ハイパーパラメータ調整など） 5分間の固定時間でトレーニングを実行 val_bpb（検証ビット/バイト）が改善したか確認 改善 → 変更を保持、悪化 → 変更を破棄 1に戻る 5分の固定時間予算により、1時間あたり約12実験、一晩（8時間）で約100実験が可能になる。 実験結果 Karpathy 自身の実験 Karpathy は自身の nanochat（GPT-2トレーニング環境）に autoresearch を適用: 約700回の実験を2日間で実行 約20個の実質的な改善を発見 GPT-2到達時間: 2.02時間 → 1.80時間（11%短縮） 発見された改善の例: バッチサイズの半減（5分以内のステップ数増加） モデル深度の調整（depth 9への最適化） スライディングウィンドウ比率のチューニング コミュニティの成果 GitHub Discussions で報告された改善: Discussion #32: val_bpb を 0.9979 → 0.9773 に改善（89実験、H100 80GB） Discussion #43: val_bpb を 0.9979 → 0.9697 に改善（126実験、H100 80GB） Tobi のケース: 0.8Bモデルが従来の1.6Bモデルを 19%上回るスコア（37実験、8時間） 使用されるLLM autoresearch のエージェントとして動作するLLM自体は外部モデルを使用する。Karpathy のテストでは Claude や GPT 系モデルが使われている。 ...

オープンソースの AI エージェント基盤 OpenClaw を使って、保有銘柄の株価アラート・決算通知・ニュース収集を自動化した実装事例を紹介します。Zenn の実践記事を元に、設計思想と実装パターンを整理しました。 個人投資家が抱える情報収集の課題 趣味で株式投資をしていると、以下の問題に直面します。 受動的な情報取得 — 自分で証券アプリを開いて確認する必要があり、変動への気付きが遅れる 情報の分散 — 株価、ニュース、決算情報が異なるサービスに散在 文脈の欠如 — 「株価が3%下がった」という事実だけでは理由がわからない 手動メンテナンス — 新規銘柄追加時に各サービスへの個別登録が必要 なぜ OpenClaw が向いているか OpenClaw は Peter Steinberger 氏が開発したオープンソースの AI エージェント基盤です。以下の特徴が情報収集の自動化に適しています。 常時起動・定期実行 — クラウド上で 24 時間稼働し、cron スケジューラーで定期タスクを実行できる LLM による文脈理解 — 単純なアラートと異なり、「何が起きたか」だけでなく「なぜ起きたか」まで Web 検索で調べて報告できる 柔軟な報告内容 — 自然言語でプロンプトに指示を書くだけで報告フォーマットをカスタマイズできる アーキテクチャ全体像 設計の核は Single Source of Truth（信頼できる唯一の情報源） です。 Google スプレッドシート（マスターデータ） ↓ portfolio-sync（毎日 6:20） portfolio.json ─→ interests.json ↓ ↓ 株価アラート ニュース収集 決算通知 週次レポート 銘柄追加・削除時はスプレッドシートを更新するだけで、下流の全システム（ニュース収集、アラート、レポート）に自動反映されます。 cron ジョブ一覧 時刻 ジョブ 内容 6:20 portfolio-sync スプレッドシート → portfolio.json 同期 毎時:30 news-auto-collect 保有銘柄関連ニュースを自動収集 7:00 morning-start 翌日決算があれば通知 10:00 portfolio-alert-am 3%以上変動でアラート 14:30 portfolio-alert-pm 3%以上変動でアラート 17:00 earnings-report 当日決算発表の結果報告 土曜 10:00 weekly-portfolio-image 週次損益レポート画像 実装パターン 1. マスターデータ管理 Google スプレッドシートに以下のカラムを用意します。 ...

ByteDance がオープンソースで公開した AI エージェント基盤「DeerFlow」（Deep Exploration and Efficient Research Flow）が注目を集めている。サブエージェントの自動振り分け、サンドボックスでのコード実行、長期メモリ、Claude Code 連携など、プロダクション運用を見据えた機能が揃っている。 DeerFlow とは DeerFlow は、LangGraph / LangChain をベースに構築されたオープンソースの「SuperAgent ハーネス」。複雑なタスクをサブエージェントに分解し、メモリとサンドボックスを活用しながら自律的に処理する。 2026年2月27日に v2.0 がリリースされ、GitHub Trending で #1 を獲得。v2.0 は v1 とコードを共有しない完全な書き直しで、プロダクション環境でのデプロイに焦点を当てている。 主な機能 サブエージェントの自動振り分け 複雑なタスクを並列のサブエージェントワークフローに分解する。各サブエージェントは隔離されたコンテキストで動作し、スコープされたツールと終了条件を持つ。 サンドボックス実行 タスクはコンテナ化された Docker 環境で実行される。専用のファイルシステムが用意され、入力・作業・出力のディレクトリが分離されている。 /mnt/user-data/uploads/ ← 入力ファイル /mnt/user-data/workspace/ ← 作業ディレクトリ /mnt/user-data/outputs/ ← 最終成果物 3つの実行モードをサポート: ローカル実行 — 開発用 Docker 実行 — 単一サーバーでのプロダクション Kubernetes 実行 — マルチサーバー環境 スキルシステム 機能モジュールは Markdown ファイルとして提供される。リサーチ、レポート生成、スライド作成、Web ページ、画像/動画生成のスキルが組み込まれており、タスクの必要に応じてプログレッシブにロードされる。 長期メモリ セッションをまたいだ永続的なプロファイルを構築できる。ユーザーの好み、ライティングスタイル、蓄積された知識をローカルに保存する。 コンテキスト管理 タスクの要約、中間結果のファイルシステムへのオフロード、長時間セッションでの圧縮された状態管理によって、コンテキストウィンドウを効率的に利用する。 セットアップ Docker での起動（推奨） 1 2 3 4 5 git clone https://github.com/bytedance/deer-flow.git cd deer-flow make config # config.yaml を設定 make docker-init make docker-start http://localhost:2026 でアクセスできる。 ...

Google が 2026年3月に公開した Gemini Embedding 2 は、テキスト・画像・動画・音声・ドキュメントを同一のベクトル空間に埋め込める、初のネイティブマルチモーダル埋め込みモデルだ。RAG パイプラインやマルチモーダル検索を構築する開発者にとって注目すべきモデルとなっている。 主な特徴 ネイティブマルチモーダル対応 従来の埋め込みモデルはテキスト専用か、別モデルで画像を処理する必要があった。Gemini Embedding 2 は全モダリティを 3072次元の統一ベクトル空間 に直接埋め込む。これにより、テキストで検索して関連する画像や動画を取得するといったクロスモーダル検索が自然に実現できる。 対応モダリティと制限: モダリティ 制限 テキスト 最大 8,192 トークン 画像 1リクエストあたり最大 6枚（PNG, JPEG） 動画 最大 120秒（MP4, MOV） 音声 ネイティブ対応（テキスト変換不要） インターリーブ入力にも対応しており、1つのリクエストに画像とテキストを混在させて渡すことができる。 Matryoshka 表現学習（MRL） Matryoshka Representation Learning（マトリョーシカ表現学習）により、重要な意味情報がベクトルの先頭次元に集約される設計になっている。デフォルトの 3,072次元から 1,536 や 768次元に切り詰めても、検索品質の大部分を維持できる。 Google の推奨次元数: 3,072次元：最高品質 1,536次元：高品質（コスト削減向け） 768次元：バランスの良い推奨値 768次元に切り詰めた場合でも、同サイズの固定次元モデルを上回る性能を発揮するとされている。 多言語対応と性能 100以上の言語をサポート MTEB 多言語リーダーボードで 69.9 を記録しトップランク MTEB コード検索でも 84.0 と高スコア 料金 プラン 料金 リアルタイム API $0.20 / 100万トークン バッチ API $0.10 / 100万トークン（50% OFF） OpenAI の text-embedding-3-small（$0.02/100万トークン）と比較すると高価だが、マルチモーダル対応を単一モデルで実現している点が差別化要因となる。 ...

OpenClaw エージェントを使って、TradingView の指標を自動スクレイピングし、Pine Script から Python に変換してバックテストまで全自動で実行する手法が話題になっています。 OpenClaw とは OpenClaw は、オーストリアの開発者 Peter Steinberger 氏が 2025 年 11 月に Claude を使って構築したオープンソースの AI エージェントです。ローカルマシン上で動作し、自然言語の指示を受けてタスクを自律的に実行します。GitHub で 32 万以上のスターを獲得しており、2026 年初頭にはユーザー数が 200 万人を超えるなど急成長しています。 主な特徴: マルチプラットフォーム対応: Mac / Windows / Linux で動作 メッセージ連携: WhatsApp、Telegram、Slack、Discord など複数チャネルに対応 スキルシステム: モジュラーなプラグイン（スキル）で機能を拡張可能 永続メモリ: コンテキストを記憶して継続的に動作 トレーディング戦略の自動バックテスト 今回話題になっているのは、OpenClaw エージェントを使ったトレーディング戦略の自動バックテストです。 処理の流れ TradingView 指標の自動スクレイピング: TradingView から 50 以上のテクニカル指標を自動収集 Pine Script → Python 変換: TradingView 独自の Pine Script で書かれた指標を Python コードに自動変換 バックテスト実行: 変換した戦略を過去データで自動検証 結果のフィルタリング: 失敗した戦略を自動除外し、勝ちパターンを抽出 GitHub へのログ: テスト結果を自動で GitHub リポジトリに記録 設定を済ませれば、コードを一切書かずにこの一連のプロセスが自動で回り続けます。 ...

Andrej Karpathy が公開した autoresearch は、AI エージェントが自律的に ML 実験を繰り返すツールだ。寝ている間に AI が 100 回実験し、朝起きたらモデルが賢くなっている——そんな研究スタイルを 630 行の Python コードで実現する。 autoresearch とは nanochat（軽量 LLM 学習コア）をシングル GPU・1 ファイルに凝縮し、AI エージェントが自律ループで学習コードを改善していく仕組み。 基本構造はシンプル: 人間が .md ファイル（プロンプト）を設計する AI エージェントが .py（学習コード）を自律的に改善する 各実験は ちょうど 5 分間 のトレーニングで構成され、1 時間あたり約 12 回、一晩で約 100 回の実験が自動で回る。 人間: program.md を設計（研究の方針・制約を定義） ↓ AI エージェント: 学習コードを修正 ↓ 5分間のトレーニング実行 ↓ 結果を評価（validation loss） ↓ 改善されていれば git commit → 次のイテレーションへ 技術的な特徴 630 行のミニマル設計 autoresearch の核心は「小さく始めて、エージェントに任せる」という哲学にある。 シングル GPU で完結（マルチ GPU 不要） ニューラルネットワークのアーキテクチャ、オプティマイザ、ハイパーパラメータすべてを AI が調整 git feature ブランチ上で動作し、改善があれば自動コミット MIT ライセンスで公開 「コードを書く」のではなく「プログラムをプログラムする」 Karpathy が強調するのは、研究者が Python ファイルを直接触るのではなく、Markdown でエージェントへの指示を設計するというパラダイムシフトだ。 ...

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。 「一人の博士課程ではなく、研究コミュニティを」 The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。） 現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。 技術的な課題 この構想が実現するには、いくつかのハードルがある: 分散タスクシャーディング — 実験をどう分割して割り当てるか 結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。 「一つを賢くする」から「場の設計」へ IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している: AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。 これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。 Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。 ...