Python

「判断ロジックさえ言語化できれば、Claude Code で株式投資を自動化できるのでは？」という仮説を立て、3週間試した結果、月次リターン 4.19% を達成したという事例が話題になっています。 なぜAlpacaなのか 日本の主要ネット証券（SBI証券、楽天証券、マネックスなど）は、個人向けの自動売買 API を（調査した限りでは）公開していません。唯一カブコム証券には API がありますが、口座開設の手間や日本株に限定されるという制約があります。 米国株を自動売買したいなら、選択肢はほぼ Alpaca（アルパカ） 一択になります。 AlpacaのAPIが優れている理由 全機能を Python から操作可能: 注文・ポジション管理・履歴取得など 株・ETF・仮想通貨をすべて API で売買できる 「ほぼ自動売買のために作られた証券会社」という印象 ただしデメリットもあります。米国の証券会社であるため、確定申告の手続きが複雑になる点や、日本居住者の口座開設にそれなりの手間がかかる点は事前に承知しておく必要があります。 投資ロジックの言語化 このシステムの核心は「負けなければいい」という考え方です。予測に頼るのではなく、期待値がプラスになるルールを設定して淡々と運用するだけです。 麻雀で相手が満貫や倍満だと分かっているのに、リーのみでリーチしないのと同じ理屈で、期待値が見合っていない状況では投資しないのが原則です。 具体的には以下の3カテゴリのポートフォリオを組んでいます。 1. 資産の70%：配当貴族 「配当貴族」と呼ばれる、何十年も株価が上がり続けている銘柄に損切りなしで長期投資します。 2. 中期成長株 「-8% で損切り、+20% で利確」 というルールを設定しています。 期待値 = (0.33 × 20%) + (0.67 × -8%) = 1.24% 3回に1回勝てばトントン以上になる計算です。予測なしでルールを守るだけで期待値がプラスになります。 3. 短期株 「-3% で損切り、+9% で利確」 という設定です。 期待値 = (0.5 × 9%) + (0.5 × -3%) = +3% 勝率50%でも利益が積み上がる計算になります。 Claude Code + Alpaca API の連携構成 実装は驚くほどシンプルです。判断ロジックを言語化して API と連携するだけなので、特に難しいことはありません。 ...

概要 django-mptt は README で「This project is currently unmaintained」と宣言している。後継として推奨される django-tree-queries は同じメンテナ（Matthias Kestenholz）の手による Recursive CTE 実装で、書き込みコストが O(N) から O(1) に改善される。 なぜ unmaintained になったのか MPTT（Modified Preorder Tree Traversal）はノード挿入・移動のたびに全ノードの lft/rght を更新する必要があり書き込みが O(N) 並行書き込みに弱く、TreeManager.rebuild() が「壊れることを前提とした API」であることを物語る PostgreSQL 8.4（2009）以降、すべての主要 DB が WITH RECURSIVE をサポートしており、MPTT の存在意義が薄れた メンテナは「放棄」ではなく「アルゴリズム的な世代交代を促している」 django-tree-queries のアプローチ parent 列 1 本だけを持ち、深さや祖先パスをクエリ時に Recursive CTE で動的に計算する。 書き込み: parent_id を更新するだけ → O(1) 読み取り: CTE 1 発で深さ・祖先・並び順を取得 並行性: ツリー操作で他行が壊れない リビルド不要: 冗長データが存在しない 移行手順 1. 整合性確保（移行前） 1 python manage.py shell -c "from myapp.models import Category; Category.objects.rebuild()" 2. モデル定義の差し替え 1 2 3 4 5 6 7 8 9 10 # Before: django-mptt from mptt.models import MPTTModel, TreeForeignKey class Category(MPTTModel): parent = TreeForeignKey('self', null=True, blank=True, on_delete=models.CASCADE) # After: django-tree-queries from tree_queries.models import TreeNode class Category(TreeNode): name = models.CharField(max_length=100) # parent は TreeNode が定義済みなので不要 3. マイグレーション生成 1 2 python manage.py makemigrations # lft / rght / tree_id / level の DROP マイグレーションが自動生成される 4. API 対応表 django-mptt django-tree-queries node.get_descendants() Category.objects.descendants(node) node.get_ancestors() Category.objects.ancestors(node) node.get_children() node.children.all() node.is_leaf_node() not node.children.exists() node.level node.tree_depth（with_tree_fields() 必要） Model.objects.all() Model.objects.with_tree_fields() Model.objects.rebuild() 不要（存在しない） 5. テンプレートタグの置換 1 2 3 4 5 6 7 8 9 10 11 12 13 14 {# Before: django-mptt #} {% load mptt_tags %} {% recursetree categories %} <li>{{ node.name }}</li> {% endrecursetree %} {# After: django-tree-queries #} {% load tree_queries %} {% tree_info categories as tree %} {% for node, structure in tree %} {% if structure.new_level %}<ul>{% endif %} <li>{{ node.name }} {% for level in structure.closed_levels %}</li></ul>{% endfor %} {% endfor %} 落とし穴 Ordered insertion が無い — MPTTMeta.order_insertion_by 相当は存在しない。必要なら position 列を自前で導入 管理画面の UI — DraggableMPTTAdmin は付属しない。必要なら別ライブラリか自作 大規模 CTE のコスト — 数十万ノードの descendants クエリは MPTT の BETWEEN lft AND rght より遅い場合がある。本番データで EXPLAIN を取ること MySQL 5.7 以下は非対応 — Recursive CTE は MySQL 8.0+ が必要 DRF シリアライザの書き直し — MPTT 専用 TreeSerializer を使っていると変更が必要 移行コストの目安 項目 コスト スキーマ移行 数分（makemigrations + migrate） モデル定義変更 数分〜数十分 API 呼び出しの全置換 数日〜数週間（規模次第） テンプレート/Admin 改修 数日 判断基準 ケース 推奨 既存案件で安定稼働中、ツリー編集が稀 django-mptt のまま 新規プロジェクト、PostgreSQL/MySQL 8+ 最初から django-tree-queries MySQL 5.7 以下が必須 django-mptt または django-treebeard 関連ページ FastAPI — Django と同様の Python Web フレームワーク DRF（Django REST Framework） — API 移行時に関連するシリアライザ ソース記事 django-mptt はなぜ「unmaintained」と書かれているのか — そして django-tree-queries への移行 — 2026-04-20

本記事では、Python の AST を活用して AI による脆弱性検出を効率化する手法を紹介します。Qiita の @PythonHaru 氏が公開した記事「コードを1行も読ませずに、AIに脆弱性を100%特定させる方法（理論編）」は 530 いいね・471 ブックマークを獲得し、X（旧 Twitter）でも急速に拡散しました。 この記事のポイント AI（LLM）に生のソースコードを読ませるのは、効率の悪い「情報の暴力」（情報量が多すぎて AI が処理しきれない状態） Python の ast モジュールで生成した Deep Structure Map（コードの骨格図）こそ、AI の推論能力を最大化する データの流入から危険地帯への到達をグラフ理論で定義すれば、理論上 脆弱性は100%特定可能 AIコードレビューの限界 GitHub Copilot や ChatGPT にコードをそのまま貼り付けて「脆弱性ある？」と質問する手法は今や一般的ですが、大規模プロジェクトでは2つの致命的な欠陥が生じます。 コンテキストの霧（AI が変数の出自を追跡できなくなる状態）— 数千行のコードを前にした AI は「どの変数がどこから来たか」を見失い、ハルシネーションを起こしやすくなる トークンの浪費 — コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす そこで著者は、AI にコードを1行も読ませるのをやめました。代わりに渡したのが、自作の解析コードが抽出した「コードの設計図（Deep Structure Map）」です。 Deep Structure Map：AI に「骨格」だけを渡す ソースコードは人間が読むための「肉体」ですが、AI が論理推論に必要なのは純粋な「神経系（ロジック）」です。Python の ast モジュールを使い、コードを以下の構造データへ変換します。 DeepAnalyzer クラス（ast.NodeVisitor を継承） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import ast class DeepAnalyzer(ast.NodeVisitor): def __init__(self): self.classes = [] self.functions = [] self.variables = [] self.scope_stack = [] self.call_graph = {} def visit_ClassDef(self, node): self.classes.append(node.name) self.generic_visit(node) def visit_Call(self, node): # 関数呼び出しをコールグラフとして記録 self.generic_visit(node) ast.NodeVisitor を継承した DeepAnalyzer がコード全体を走査し、クラス・関数・変数のスコープ情報とコールグラフを収集します。AI にはこの「関係性の結晶」だけをインプットします。 ...

概要 「本番で障害が起きてから対処する」のではなく「テスト段階で意図的に障害を起こして耐性を確認する」カオスエンジニアリングの考え方を pytest に組み込む手法。@pytest.mark.chaos というカスタムマーカーで障害注入テストを分類・選択実行できる。 セットアップ マーカー登録 1 2 3 4 5 # pyproject.toml [tool.pytest.ini_options] markers = [ "chaos: カオスエンジニアリング関連のテスト（障害注入・耐性検証）", ] 選択実行 1 2 3 pytest -m chaos # カオステストのみ pytest -m "not chaos" # 通常の CI（カオステストをスキップ） pytest -m "chaos or integration" 主要な障害注入パターン ネットワーク障害 1 2 3 4 5 @pytest.mark.chaos def test_api_timeout_fallback(): with patch("app.client.requests.get", side_effect=TimeoutError): result = app.client.fetch_user_profile(user_id=123) assert result == app.client.get_cached_profile(user_id=123) データベース障害 1 2 3 4 5 6 @pytest.mark.chaos def test_db_connection_lost(): mock_primary = MagicMock(side_effect=ConnectionError("Connection lost")) with patch("app.db.get_primary_connection", mock_primary): result = app.db.query_user(user_id=123) assert result is not None # リードレプリカから取得 ランダム障害 Fixture（確率的注入） 1 2 3 4 5 6 7 8 9 10 11 @pytest.fixture def chaos_network(monkeypatch): """30% の確率でネットワーク遅延を注入""" original_get = requests.get def unstable_get(*args, **kwargs): if random.random() < 0.3: time.sleep(random.uniform(1.0, 5.0)) if random.random() < 0.1: raise ConnectionError("Chaos: connection refused") return original_get(*args, **kwargs) monkeypatch.setattr("requests.get", unstable_get) Django との統合 1 2 3 4 5 6 @pytest.mark.chaos @pytest.mark.django_db def test_cache_backend_failure(client): with patch("django.core.cache.cache.get", side_effect=Exception("Redis down")): response = client.get("/api/users/1/") assert response.status_code == 200 # キャッシュなしでも正常応答 CI/CD 組み込み（GitHub Actions） 1 2 3 4 5 6 7 8 9 10 11 12 13 name: Chaos Tests on: schedule: - cron: '0 3 * * 1' # 毎週月曜 AM3:00 jobs: chaos-test: runs-on: ubuntu-latest env: CHAOS_ENABLED: "1" steps: - uses: actions/checkout@v4 - run: pip install -r requirements-test.txt - run: pytest -m chaos --tb=long -v 通常 CI では pytest -m "not chaos" で高速に回し、週次スケジュールジョブでカオステストのみ実行する運用が推奨される。 ...

東京大学の院生（shunya_sudo）が、45 本の cron ジョブ・36 個のカスタムエージェント・132 本の Python スクリプト で構成した日常業務自動化システムの全記録を Zenn で公開した。M1 冬から約半年間 Claude Code を使い続けて構築したシステムで、メール処理・論文監視・ML コード開発・システム自己監視まで設計原則と実装を網羅している。 システムの全体構成 macOS 上で以下の構成で稼働している。 構成要素 数 cron ジョブ 45 個 カスタムエージェント 36 個 Python スクリプト 132 本 基本アーキテクチャは 「Python が処理、Claude CLI が判断」 というシンプルな分離原則に基づく。データ取得・加工は Python スクリプトが担い、要約・判断・生成を Claude CLI が受け持ち、定時実行は cron で管理する。 主な自動化タスク メール処理（Gmail API） Gmail API を用いてメールを 4 段階に自動分類 し、返信が必要なものには 下書きを自動生成 する。 緊急対応 / 要確認 / 参照 / アーカイブの 4 レベル分類 Claude が文脈を読んで返信の下書きを生成 最終判断・送信は人間が行う 日程調整（ICS URL） ICS URL を活用してカレンダーを自動更新し、日程調整の候補時間を自動挿入する。手動でのカレンダー確認作業をゼロにした。 ...

django-mptt の README を開くと、いきなり以下の文言が目に飛び込んでくる。 This project is currently unmaintained You can find alternatives to django-mptt on Django Packages. Maybe you do not need MPTT, especially when using newer databases. See django-tree-queries for an implementation using recursive Common Table Expressions (CTE). 「単に飽きて投げ出した」のか、それとも「技術的に役目を終えた」のか。本稿では django-mptt のリポジトリ、CHANGELOG、ソースコードを実際に読んで、その背景と後継への移行可否を整理する。 1. 経緯 — メンテナンス側の事情 CHANGELOG.rst を時系列で追うと、放棄宣言とその後の経緯が見て取れる。 v0.13: 公式に「unmaintained」を宣言 0.13 ==== - **MARKED THE PROJECT AS UNMAINTAINED, WHICH IT STILL IS** - Reformatted everything using black, isort etc. - Switched from Travis CI to GitHub actions. ... この時点で「もうメンテしません」と公式宣言がなされた。 ...

「本番で障害が起きてから対処する」のではなく、「テスト段階で意図的に障害を起こして耐性を確認する」。これがカオスエンジニアリングの基本思想だ。Python の pytest には、この考え方をテストコードに組み込むためのシンプルな仕組みがある。 pytest.mark.chaos とは @pytest.mark.chaos は、pytest のカスタムマーカー機能を使って「カオステスト」を分類するためのラベルだ。pytest にはビルトインのマーカー（@pytest.mark.skip、@pytest.mark.parametrize など）があるが、chaos はユーザーが自由に定義するカスタムマーカーに該当する。 1 2 3 4 5 6 7 import pytest @pytest.mark.chaos def test_network_timeout(): """ネットワークタイムアウト時にフォールバックが機能するか""" result = call_api_with_timeout(timeout=0.001) assert result == "fallback_response" マーカーの登録 カスタムマーカーは pyproject.toml または pytest.ini に登録しておくと、PytestUnknownMarkWarning 警告を抑制できる。 1 2 3 4 5 # pyproject.toml [tool.pytest.ini_options] markers = [ "chaos: カオスエンジニアリング関連のテスト（障害注入・耐性検証）", ] 選択実行 1 2 3 4 5 6 7 8 # カオステストだけを実行 pytest -m chaos # カオステスト以外を実行（通常の CI） pytest -m "not chaos" # カオステストと統合テストを実行 pytest -m "chaos or integration" これにより、通常の CI パイプラインではカオステストをスキップし、定期的なレジリエンス検証時にだけ実行するという運用が可能になる。 ...

概要 金融庁 EDINET に開示された有価証券報告書の XBRL データを独自にパースし、企業財務データを一括取得・分析できる SaaS。個人投資家向けのスクリーニング機能から、機関投資家・エンジニア向けの API まで幅広く対応する。 主な機能 データアクセス方法 方法 概要 主な用途 Web UI ブラウザでスクリーニング・比較 個人投資家のリサーチ Web API REST API で財務データ取得 システム連携・自動化 スプレッドシート Google Sheets / Excel アドイン 定型レポート作成 MCP Server AI ツールからの直接アクセス Claude Code などとの連携 Python ライブラリ pip install buffett_code データ分析・Jupyter 取得できる主なデータ PER・PBR・ROE・ROIC 等の財務指標 時系列の貸借対照表・損益計算書・キャッシュフロー計算書 スクリーニング（条件絞り込みによる銘柄抽出） MCP Server との連携 Claude Code などの AI ツールから直接バフェット・コードの財務データにアクセスできる MCP Server を提供。自然言語で「PBR が1倍以下でROEが10%以上の銘柄を探して」といった分析が可能になる。 関連ページ EDINET XBRL Python ガイド — EDINET XBRL の基礎と Python での処理 MCP — AI ツール連携のプロトコル ソース記事 バフェット・コード徹底分析 — EDINET XBRLを活用した企業分析SaaSの全貌 — 2026-04-07

概要 EDINET（Electronic Disclosure for Investors’ NETwork）は金融庁が運営する電子開示システムで、上場企業の有価証券報告書を XBRL 形式でダウンロードできる。edinet-xbrl ライブラリを使えば、複雑な XBRL 仕様を意識せずに Python でデータを抽出できる。 必要なもの EDINET API キー（EDINET API で取得） Python 3.x edinet-xbrl ライブラリ（pip install edinet-xbrl） 基本的な使い方 1 2 3 4 5 6 7 8 9 from edinet_xbrl.edinet_xbrl_parser import EdinetXbrlParser parser = EdinetXbrlParser() edinet_xbrl_object = parser.parse_file("path/to/file.xbrl") # 総資産の取得例 assets = edinet_xbrl_object.get_data_by_context_ref( "jppfs_cor:Assets", "CurrentYearInstant" ).get_value() 主要な財務タクソノミキー key 内容 jppfs_cor:Assets 総資産 jppfs_cor:NetSales 売上高 jppfs_cor:OperatingIncome 営業利益 jppfs_cor:OrdinaryIncome 経常利益 jppfs_cor は日本 GAAP 財務諸表のタクソノミ名前空間。context_ref の CurrentYearInstant は当期末時点を指す。 ...

前回の記事で EDINET の XBRL データを Python で扱う方法を紹介した。今回は、その仕組みを活用して構築されている企業分析サービス「バフェット・コード」を分析し、何ができるのかを網羅的にまとめる。 バフェット・コードとは バフェット・コードは、EDINET（有価証券報告書）と TDNET（適時開示）の XBRL データをパースし、企業の財務情報をワンストップで分析できる SaaS サービスだ。バフェットコード株式会社が開発・運営している。 データパイプラインの流れは以下の通り: EDINET / TDNET から XBRL ファイルを取得 XBRL をパースして RDB に格納 過去データと株価を組み合わせて財務指標を算出 スクリーニング・比較用のデータセットを更新 このパイプラインの XBRL パース部分に、前回紹介した edinet_xbrl ライブラリが使われている。 Web アプリケーションでできること バフェット・コードの Web アプリ（buffett-code.com）では以下の機能が利用できる。 企業分析 財務データの閲覧: B/S（貸借対照表）、P/L（損益計算書）、C/S（キャッシュフロー計算書）を一覧表示 企業概況: 設立日、上場日、事業内容などの基本情報 役員一覧: 取締役・監査役の情報 大株主情報: 四半期ごとの大株主構成 セグメント情報: 事業セグメント別の業績データ 類似企業の表示: 同業他社の自動提案 スクリーニング・比較 条件検索: 財務指標（PER、PBR、ROE 等）でフィルタリング 企業比較: 複数企業の財務データを横並びで比較 株主検索: 特定の株主が保有する企業を検索 資料検索 横断検索: EDINET・TDNET の資料に加え、各社の決算説明資料や統合報告書も横断的に検索 CSV ダウンロード: 年間業績や各種指標のダウンロード Web API でできること バフェット・コードは REST API（v4）を提供しており、プログラムから財務データにアクセスできる。API の利用には有償契約が必要だが、テスト用 API キーも用意されている。 ...