Web開発

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

HubSpot CRM の Line Items（商品項目）API について整理します。Line Items は製品（Product）が取引（Deal）や見積もり（Quote）に紐付けられたときに生成される個別のインスタンスです。 Line Items とは HubSpot における Line Items は、製品カタログ（Products）とは異なる概念です。 Product: 製品カタログ上のマスターデータ Line Item: Product が取引・見積もりなどに追加された際の個別インスタンス Line Items への変更は元の Product には影響しません。取引ごとに価格や数量をカスタマイズできます。 API エンドポイント ベース URL: /crm/v3/objects/line_items 操作 メソッド エンドポイント 作成 POST /crm/v3/objects/line_items 個別取得 GET /crm/v3/objects/line_items/{lineItemId} 一覧取得 GET /crm/v3/objects/line_items 更新 PATCH /crm/v3/objects/line_items/{lineItemId} 削除 DELETE /crm/v3/objects/line_items/{lineItemId} 必要なスコープ スコープ 用途 crm.objects.line_items.read データ取得 crm.objects.line_items.write 作成・更新 tax_rates.read 税率情報の取得 データモデル詳細 Line Item の全プロパティは GET /crm/v3/properties/line_item で取得できます。以下はカテゴリ別の主要プロパティです。 基本情報 内部名 表示名 説明 備考 name 名前 商品項目の名前 必須 description 説明 製品の詳細な説明 hs_sku SKU 製品の固有識別子 hs_product_id 製品 ID 関連する製品ライブラリの ID 製品から作成時に指定 hs_object_id レコード ID Line Item の一意な ID 自動設定・読み取り専用 hs_product_type 製品タイプ INVENTORY（在庫）/ NON_INVENTORY（非在庫）/ SERVICE（サービス） hs_url URL 製品の Web ページ URL hs_images 画像 URL 製品画像の URL 価格・数量 内部名 表示名 説明 備考 quantity 数量 含まれる製品の単位数 price 単価 購入者向けの製品単価 負の値は不可 amount 正価（Net price） 合計金額（数量 × 単価） 計算フィールド hs_cost_of_goods_sold 売上原価 製品の原価 hs_line_item_currency_code 通貨 通貨コード（例: JPY, USD） hs_pricing_model 価格モデル FLAT（定額）または TIERED（段階制） hs_effective_unit_price 有効単価 段階制価格の場合に適用される実効単価 割引 内部名 表示名 説明 備考 hs_discount_percentage 割引率 適用される割引の割合（%） discount 単位割引額 単位あたりの割引金額 hs_total_discount 合計割引額 割引率と割引金額を考慮した総割引額 計算フィールド hs_pre_discount_amount 割引前金額 割引適用前の金額 計算フィールド 税金 内部名 表示名 説明 備考 hs_tax_rate_group_id 税率グループ ID 適用する税率の識別子 tax 税額 適用される税金額 hs_tax_amount 計算税額 税率から自動計算された税額 計算フィールド hs_tax_rate 税率 適用される税率（%） hs_after_tax_amount 税込金額 税額適用後の金額 計算フィールド 定期請求（Recurring Billing） 内部名 表示名 説明 備考 recurringbillingfrequency 請求頻度 定期請求の頻度（monthly, quarterly, annually など） hs_recurring_billing_period 請求期間 ISO-8601 期間形式（例: P12M = 12ヶ月, P1Y = 1年） PnYnMnD / PnW 形式 hs_recurring_billing_start_date 請求開始日 定期請求の開始日 hs_recurring_billing_end_date 請求終了日 定期請求の終了日 hs_recurring_billing_terms 請求条件 FIXED（固定回数）または AUTO_RENEW（自動更新） hs_recurring_billing_number_of_payments 支払い回数 固定回数請求の場合の支払い総数 hs_billing_start_delay_days 請求開始遅延（日） 請求開始を遅延させる日数 hs_billing_start_delay_months 請求開始遅延（月） 請求開始を遅延させる月数 hs_billing_start_delay_type 請求遅延タイプ FIXED_DATE（固定日）または DELAYED_PERIOD（遅延期間） hs_term_in_months 期間（月） 契約期間の月数 収益指標（計算フィールド） 内部名 表示名 説明 hs_tcv 総契約額（TCV） Total Contract Value hs_acv 年間契約額（ACV） Annual Contract Value hs_arr 年間経常収益（ARR） Annual Recurring Revenue hs_mrr 月間経常収益（MRR） Monthly Recurring Revenue hs_margin マージン 売上 − 売上原価 hs_margin_tcv マージン TCV TCV − 売上原価合計 hs_margin_acv マージン ACV ACV − 売上原価（年間） hs_margin_arr マージン ARR ARR − 売上原価（年間） hs_margin_mrr マージン MRR MRR − 売上原価（月間） システムプロパティ（読み取り専用） 内部名 表示名 説明 createdate 作成日時 レコード作成日時 hs_lastmodifieddate 最終更新日時 プロパティが最後に変更された日時 hs_created_by_user_id 作成者ユーザー ID レコードを作成したユーザー hs_updated_by_user_id 更新者ユーザー ID 最後に更新したユーザー hs_object_source レコードソース レコードの作成方法 hs_was_imported インポートフラグ インポートによって作成されたかどうか プロパティの種別 必須: name のみが作成時に必須。ただし price と quantity も通常は指定する 計算フィールド: amount, hs_total_discount, hs_pre_discount_amount, hs_after_tax_amount, hs_tax_amount, 収益指標（TCV/ACV/ARR/MRR）は HubSpot が自動計算する。API から直接設定はできない 読み取り専用: システムプロパティ（作成日時、更新日時、ユーザー ID 等）は自動設定される price の制約: 負の値を設定できない Line Item の作成例 1 2 3 4 5 6 7 8 9 10 POST /crm/v3/objects/line_items { "properties": { "name": "Web開発サービス", "hs_product_id": "12345", "quantity": "1", "price": "500000" } } 取引や見積もりへの関連付けを同時に行う場合は、後述の「関連付け」セクションを参照してください。 ...

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取引ができる点で新しい選択肢となる。 ...

Theatre.js — GUI でWebアニメーションを直感的に作れるモーションデザインエディタ しば（@shiba_program）氏のポストが、GUI でWebアニメーションを作成できる JavaScript ライブラリ「Theatre.js」を紹介しています。 GUIで直感的にWebアニメーションが作れる「theatre.js」すごいな。編集した内容が即座に反映されるので、これは微調整捗る。GUIで編集できるから、デザイナーに調整任せることもできそう。デモにある高度なものだけでなく、Webサイトで使うシンプルなアニメーションの作成もかなり楽にしてくれるはず — しば（@shiba_program） 投稿が注目している「デザイナーに調整を任せられる」という点は、Theatre.js の設計思想の核心です。コードでアニメーション対象を定義し、ブラウザ上の GUI エディタで動きを調整する。このワークフローにより、エンジニアとデザイナーの協業が自然に成立します。 Theatre.js とは何か Theatre.js はフィンランド・ヘルシンキの Theatre.js Oy が開発するオープンソースの Web モーションデザインライブラリです。GitHub Stars 12.2k、1,600以上のプロジェクトが依存しており、Web アニメーション領域で確固たる地位を築いています。 基本情報 項目 内容 開発元 Theatre.js Oy（ヘルシンキ） ライセンス Apache 2.0（@theatre/core）/ AGPL 3.0（@theatre/studio） 言語 TypeScript 82.6% GitHub Stars 12.2k 現バージョン 0.5（1.0 開発中） 対応技術 Three.js、React Three Fiber、HTML/SVG、任意のJSライブラリ 2つのパッケージ構成 Theatre.js は2つの独立したパッケージで構成されます。 パッケージ 役割 使用場面 @theatre/core アニメーション再生エンジン 開発・本番の両方 @theatre/studio GUI エディタ（シーケンスエディタ、グラフエディタ、プロパティパネル） 開発時のみ この分離設計が重要です。Studio は開発時にのみ使い、本番ビルドには core だけを含めます。エディタのコードが本番バンドルに入らないため、パフォーマンスへの影響はありません。 4つの基本概念 Theatre.js には、理解すべき4つの概念があります。 ...

リクルート新卒研修の React 資料が「無料で最高の教材」と言われる理由 sigumataityouda 氏のポストが、リクルートの新卒研修資料を「React を語る上で欠かせないもの」「完成度が非常に高い」と紹介しています。リクルートは 2017 年から毎年、新卒エンジニア向け研修資料を無料公開しており、React 研修資料は特に業界で高く評価されています。 React語る上で欠かせないものとしてリクルートの新卒研修資料というのもがある。完成度が非常に高い。 リクルートの React 研修資料とは React 研修 (2024) は、リクルートのエンジニアコース新卒研修「BootCamp」で使われている講義資料です。約 170 スライド以上で構成され、Speaker Deck で無料公開されています。 研修の位置づけ リクルートの新卒エンジニアは配属前に約 3 ヶ月間の BootCamp を受講します。2024 年度は 24 講座以上が開講されており、React 研修はフロントエンド技術スタックの中核として位置づけられています。 研修カテゴリ 主な講座 フロントエンド JavaScript、TypeScript、React、Next.js バックエンド データベース設計、API 設計 品質・テスト テスト駆動開発（講師: t_wada 氏） セキュリティ セキュリティ演習 AI テキスト生成 AI 活用 マインドセット ソフトウェアエンジニアとしての姿勢と心構え 最初の講座「ソフトウェアエンジニアとしての姿勢と心構え」は、技術顧問の t_wada 氏が担当し、「技術の学び方を学ぶ」ことに重点を置いています。 資料の構成 React 研修資料は 5 つのセクションで構成されています。 1. Web アプリ開発の変遷 React を学ぶ前に、Web アプリケーション開発がどう進化してきたかを整理します。 世代 アーキテクチャ 特徴 第 1 世代 MPA（クラシック SSR） サーバーが HTML を生成、ページ遷移ごとにリロード 第 2 世代 MPA + jQuery DOM 操作で部分的な動的 UI を実現 第 3 世代 SPA（CSR のみ） クライアントで描画、リッチな UX 第 4 世代 SPA（CSR + 事前レンダリング） SSR / SSG で初期表示を高速化 この変遷を理解することで、「なぜ React が必要になったのか」という文脈が掴めます。jQuery 時代の命令的 UI と React の宣言的 UI の違いを、歴史的な流れの中で説明しているのが特徴です。 ...

CloudWatch Logs のエラーを自動で GitHub Issues に課題化する ECS で稼働するWebアプリケーションのエラーログを自動的に GitHub Issues に報告する仕組みを構築しました。手動でログを監視する必要がなくなり、エラー発生時に即座にチームが認識・対応できるようになります。 背景 マルチテナントの業務システムを ECS Fargate 上で運用しています。アプリケーションは2つあり、それぞれ異なるフレームワークで構築されています。 アプリ フレームワーク 用途 web Laravel (PHP) 業務管理システム api Django (Python) API サーバー これまで CloudWatch Logs にログは収集していたものの、エラーの検知は手動確認に頼っていました。500エラーや例外発生を見逃すリスクがあり、自動検知の仕組みが必要でした。 アーキテクチャ Subscription Filter + Lambda + GitHub Issues API の構成を採用しました。 CloudWatch Logs (/ecs/{prefix}-ecs-{app}) └── Subscription Filter (エラーパターンマッチ) └── Lambda Function (Docker/arm64, Python 3.12) ├── エラー解析 (HTTP 5xx, 例外, スタックトレース) ├── ±5秒のログコンテキスト取得 ├── 既存 Open Issue 検索 └── 新規 Issue 作成 or 既存 Issue にコメント追加 この構成を選んだ理由 方式 リアルタイム性 柔軟性 コスト Subscription Filter + Lambda (採用) 高 高 中 Metric Filter + Alarm + SNS 中 (1分以上遅延) 低 低 CloudWatch Logs Insights (定期実行) 低 高 低 Subscription Filter はログ出力時にほぼリアルタイムで Lambda を起動するため、エラー発生から数秒で Issue が作成されます。 ...

ローカルの開発モックを ngrok で公開し、Backlog Wiki を自動更新するシェルスクリプト レビュー担当者にモックアプリを見せたいとき、毎回「URL 変わりました」と連絡するのが面倒になったので、ngrok 起動 → Backlog Wiki 自動更新を1コマンドで済ませるスクリプトを作りました。 背景 社内プロジェクトで React のモックアプリを開発しています。レビュー担当者（非エンジニア）にモック画面を確認してもらう際、以下のような手順を毎回踏んでいました： npm run dev でローカルサーバーを起動 ngrok http 3000 でトンネルを張る 発行された URL をコピー Backlog の Wiki ページを開いて URL を貼り替える レビュー担当者に連絡 ngrok の無料プランでは URL が起動ごとに変わるため、毎回 Wiki を手動更新する必要がありました。これを自動化します。 スクリプトの全体像 ./scripts/serve-public.sh [user:password] 1コマンドで以下が実行されます： Vite dev server 起動 ↓ ngrok トンネル開通（Basic認証付き） ↓ Backlog Wiki に URL を自動反映 ↓ Ctrl+C で全プロセス停止 実装のポイント 1. Vite の起動待ち Vite dev server はバックグラウンドで起動しますが、すぐには HTTP リクエストを受け付けません。ポーリングで起動完了を待ちます： 1 2 3 4 5 6 for i in $(seq 1 15); do if curl -s -o /dev/null http://localhost:$PORT 2>/dev/null; then break fi sleep 1 done 15秒以内に応答がなければエラーとして終了します。 ...

uv https://docs.astral.sh/uv/ nix: https://github.com/pyproject-nix/uv2nix インストール 1 % curl -LsSf https://astral.sh/uv/install.sh | sh 1 2 3 4 5 6 7 8 9 10 11 downloading uv 0.5.14 aarch64-apple-darwin no checksums to verify installing to /Users/hdknr/.local/bin uv uvx everything's installed! To add $HOME/.local/bin to your PATH, either restart your shell or run: source $HOME/.local/bin/env (sh, bash, zsh) source $HOME/.local/bin/env.fish (fish) 1 2 3 % source .local/bin/env % which uv /Users/hdknr/.local/bin/uv 1 2 % uv --version uv 0.5.14 (9f1ba2b96 2025-01-02) uvx (uv tool run) uvではdevelop環境で利用するtoolをuv tool(uvx)というコマンド別管理することが可能 ...

Python: HTTP 簡単なHTMLサーバー(http.server + SimpleHTTPRequestHandler) ディレクトリ一覧を返す 1 2 3 4 5 6 7 8 9 10 import http.server import socketserver PORT = 8000 Handler = http.server.SimpleHTTPRequestHandler with socketserver.TCPServer(("", PORT), Handler) as httpd: print("serving at port", PORT) httpd.serve_forever()

メール送信 Djangoでメールを送信する際に、都度サーバーを切り替える方法はいくつかあります。以下の手順で実装できます。 メールサーバーの設定を動的に変更する: DjangoのEmailMessageクラスを使用して、メール送信時にサーバー設定を動的に変更できます。例えば、以下のようにconnectionパラメータを使用して異なるサーバーを指定します。 1 2 3 4 5 6 7 8 9 10 11 12 13 from django.core.mail import EmailMessage, get_connection def send_email(subject, message, from_email, recipient_list, server_settings): connection = get_connection( host=server_settings['EMAIL_HOST'], port=server_settings['EMAIL_PORT'], username=server_settings['EMAIL_HOST_USER'], password=server_settings['EMAIL_HOST_PASSWORD'], use_tls=server_settings['EMAIL_USE_TLS'], use_ssl=server_settings['EMAIL_USE_SSL'], ) email = EmailMessage(subject, message, from_email, recipient_list, connection=connection) email.send() サーバー設定のリストを用意する: 複数のサーバー設定をリストで管理し、メール送信時にランダムまたは順番に選択する方法です。 ...