Python

前回の記事で 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 キーも用意されている。 ...

概要 Kevin Gu 氏（Third Layer CTO）が開発した Python 製 OSS ライブラリ。メタエージェントとタスクエージェントの二重構造で、エージェントのハーネス（プロンプト・ツール・オーケストレーション）を自律的に最適化する。24時間の自律最適化で SpreadsheetBench・TerminalBench 世界1位を達成。 基本情報 GitHub: kevinrgu/autoagent ライセンス: MIT 言語: Python 依存: Docker, Python 3.10+, uv ベンチマーク ベンチマーク スコア 順位 SpreadsheetBench 96.5% 1位 TerminalBench（GPT-5スコア） 55.1% 1位 プロジェクト構成 agent.py -- ハーネス本体（メタエージェントの編集対象） program.md -- メタエージェントへの方針指示（人間が編集） tasks/ -- 評価タスク（Harbor フォーマット） 人間は program.md にゴールを書き、agent.py の改善はメタエージェントに任せる。 関連ページ 自己改善エージェント — AutoAgent が実装するパターン Claude Code — メタエージェントの実行環境として利用可能 ソース記事 AutoAgent — AIがAIを育てる自己改善エージェントOSSライブラリ — 2026-04-05

概要 Redis や RabbitMQ をブローカーに、非同期タスク実行・定期タスク（beat）を実現。ECS Fargate 上では worker/beat を独立タスクとして実行。ログは CloudWatch Logs に出力。 関連ページ Redis — Celery のブローカー/バックエンド ソース記事 Celery — 2023-04 Celery on ECS — 2023-07

概要 ModelSerializer で ORM↔API マッピング自動化。ViewSet で CRUD 一括定義。Content Negotiation、Pagination、Filtering、Permission クラスで機能実装。 関連ページ FastAPI — Python の別の API フレームワーク ソース記事 DRF — 2023-05

概要 列指向ストレージを採用した SQL データベースエンジン。Apache Arrow、Parquet と同じエコシステムの一部で、分析ワークロード（集計、GROUP BY）で従来の行指向 DB より圧倒的に高速。ベクトル化実行エンジンと自動並列化で OLAP に最適化。 関連ページ 列指向ストレージ — DuckDB が採用するストレージ方式 ソース記事 DuckDB と列指向ストレージ — 2026-03

EDINETで公開されている有価証券報告書のXBRLファイルを、Pythonで効率的にパース・活用する方法を紹介する。edinet-xbrl ライブラリを使えば、複雑なXBRL仕様を意識せずにデータを抽出できる。 EDINETとXBRLとは EDINET（Electronic Disclosure for Investors’ NETwork）は、金融商品取引法に基づく有価証券報告書等の開示書類を電子的に提出・閲覧するためのシステムだ。金融庁が運営しており、上場企業の決算書データをXBRL形式でダウンロードできる。 XBRL（eXtensible Business Reporting Language）は、財務・経営・投資情報を標準化されたXMLベースで記述するための言語だ。構造化されたデータとしてマシンリーダブルだが、仕様が複雑で、そのまま扱うのは難易度が高い。 edinet-xbrl ライブラリ BuffettCode/edinet_xbrl は、EDINETのXBRLファイルをPythonオブジェクトとして扱えるようにするライブラリだ。 インストール 1 pip install edinet-xbrl 基本的な使い方 1 2 3 4 5 6 7 8 9 10 11 12 13 from edinet_xbrl.edinet_xbrl_parser import EdinetXbrlParser # パーサーの初期化 parser = EdinetXbrlParser() # XBRLファイルをパースしてデータコンテナを取得 xbrl_file_path = "path/to/your/xbrl/file.xbrl" edinet_xbrl_object = parser.parse_file(xbrl_file_path) # 例: 該当年度の総資産を取得 key = "jppfs_cor:Assets" context_ref = "CurrentYearInstant" current_year_assets = edinet_xbrl_object.get_data_by_context_ref(key, context_ref).get_value() key と context_ref の特定 XBRLでは、取得したいデータ項目を key（タクソノミ要素 = データ項目の識別子）と context_ref（コンテキスト参照 = 期間や連結/単体などの条件）の組み合わせで指定する。jppfs_cor は日本GAAP財務諸表のタクソノミ名前空間だ。これらを特定するには： ...

概要 Asyncio ネイティブで、型ヒント活用による自動バリデーション・ドキュメント生成が特徴。Uvicorn/Hypercorn で運用。SQLModel や fastapi-filters などのエコシステムが充実。 関連ページ DRF — Django 側の REST API フレームワーク ソース記事 FastAPI — 2024-06

AIエージェントの性能を左右する「ハーネス」を、AI自身が自律的に改善するOSSライブラリ AutoAgent が公開されました。ハーネスとは、システムプロンプト・ツール・オーケストレーションから成るエージェントの構成一式のことです。24時間の自律最適化だけで、SpreadsheetBench と TerminalBench の2つのベンチマークで世界1位を達成しています。 AutoAgent とは AutoAgent は Kevin Gu 氏（Third Layer CTO）が開発したPython製OSSライブラリで、「AIがAIを育てる」仕組みを提供します。 従来、AIエージェントを実用レベルにするには、システムプロンプトの調整、ツールの追加、実行フローの設計といった「ハーネス設計」が不可欠でした。この作業は専門知識を要し、1つのハーネスに何日もかかることがあります。AutoAgent はこのハーネス設計をAI自身に任せることで、人間の手動チューニングを超える精度を実現しました。 GitHub: kevinrgu/autoagent ライセンス: MIT 言語: Python ベンチマーク結果 ベンチマーク スコア 順位 SpreadsheetBench 96.5% 1位 TerminalBench（GPT-5スコア） 55.1% 1位 他のエントリーはすべて人間が手動チューニングしたものです。AutoAgentだけが自律的にこのスコアに到達しました。 仕組み: メタエージェントとタスクエージェント AutoAgent は2つのAIの役割分担で動作します。 メタエージェント（コーチ役） ハーネスを改良することが仕事。タスクエージェントの失敗トレースを読み、プロンプト・ツール・オーケストレーションを書き換えます。 タスクエージェント（選手役） 実際のタスクをこなすことが仕事。メタエージェントが設計したハーネスに従って作業を実行します。 最適化ループ 人間がやることは、AutoAgent の設定ファイル program.md にゴール（成功の定義）を書くだけです。あとはAIが24時間、以下のループを回します: メタエージェントがハーネスを書き換える タスクエージェントがタスクを実行する スコアを測定する 失敗トレースを分析し「なぜ失敗したか」を特定する 改善なら採用、悪化なら元に戻す 1に戻る これを数千の並列サンドボックス（隔離された実行環境）で同時実行します。 なぜAIのほうが上手く改善できるのか — 「モデル共感」 人間はどうしても自分の感覚でAIを設計してしまいます。しかし、AIは人間とは異なる思考回路で動いています。 同じモデル同士（例: Claude × Claude）でペアリングすると、コーチ（メタエージェント）は選手（タスクエージェント）の「失敗パターン」を自分ごととして理解できます。同じ重みを共有しているため、内側のモデルがどう推論するかを正確に把握できるのです。 AutoAgent の開発チームはこれを 「モデル共感（model empathy）」 と呼んでいます。実際に、Claude メタエージェント + Claude タスクエージェントの組み合わせは、Claude メタエージェント + GPT タスクエージェントの組み合わせよりも高い性能を示しました。 ...

Claude Code を単なるコーディングアシスタントではなく、バックエンド処理のオーケストレーターとして活用するアーキテクチャを考察する。Python Celery をタスクブローカーとして組み合わせるアプローチを紹介する。LLM が判断し、決定論的な処理（同じ入力に対して常に同じ結果を返す処理）を動的に Celery ワーカーへ委譲する仕組みが実現できる。 背景: 既存の Claude Code オーケストレーション 現在、Claude Code の並列実行やマルチエージェント構成には主に以下のパターンが使われている。 tmux + git worktree 最も普及しているパターン。複数の Claude Code CLI セッションを tmux で並列起動し、git worktree で各セッションの作業ディレクトリを分離する。 multi-agent-shogun — 将軍→家老→足軽の階層構造 claudio — worktree ベースの並列実行 MCP サーバーによる連携 MCP（Model Context Protocol）サーバーがタスクブローカーの役割を担い、ワーカーとなる Claude Code インスタンスにタスクを割り当てる。 claude-swarm — MCP サーバーベースのスウォーム制御 共通の特徴 これらはいずれも Claude Code 同士の連携 が主眼であり、LLM が LLM に指示を出す構造になっている。LLM を必要としない決定論的な処理（画像変換、データ集計、API 呼び出しなど）にも LLM のリソースを消費するため、コスト・速度・信頼性の面で非効率な場面がある。 提案: Claude Code + Celery アーキテクチャ 基本思想 Claude Code（LLM）は 判断と計画 に集中し、決定論的な処理は Celery ワーカーに委譲する。 ...

TL;DR 自律型トレーディングシステムで、投資目標の進捗に応じてリスクパラメータを動的に調整する機能を実装した。計算ロジックは正しく動いていたが、計算結果がエージェントのプロンプトに届いていなかった。プロンプト内の数値がプレーンテキストでハードコードされていたため、エージェントは常に保守的な固定値に従い続けていた。 背景 trader は日本株・ビットコインの自律型トレーディングシステムで、Claude をマルチエージェントとして使い、日次の投資提案を生成する。 システムには安全規約があり、エクスポージャー上限（60%）や現金比率下限（30%）などのリスクパラメータが定義されている。投資目標（goal）システムを導入し、目標への進捗ペースに応じてこれらのパラメータを動的に調整する機能を実装した。 何が起きたか 期待していた動作 1 2 3 goal 評価: behind（目標に遅れている） → AdjustmentProposal: exposure_limit=70%, cash_ratio_min=20% → エージェント: 「エクスポージャー70%以内、現金比率20%以上」で提案作成 実際の動作 1 2 3 goal 評価: behind（目標に遅れている） → AdjustmentProposal: exposure_limit=70%, cash_ratio_min=20% → エージェント: 「エクスポージャー60%以内、現金比率30%以上」で提案作成 ← 固定値のまま！ goal の評価は正しく行われ、propose_adjustment() は適切な調整値を返していた。しかしエージェントが参照するプロンプトには、値がハードコードされていた： 1 2 3 <!-- portfolio.md --> - 総エクスポージャー60%以内 - 現金比率30%以上を維持 一方、同じプロンプト内の max_position_pct（1取引あたりポジション上限）は既にテンプレート変数化されていた： ...