HubSpot + LINE でリードを統合管理する — LIFF でアンケート回答者と LINE 友だちを紐づける

LINE 公式アカウントで集客し、HubSpot でリード管理する——この組み合わせを使っている企業は多いはずです。しかし両者のユーザーデータは放っておくと分断されたままです。本記事では、LINE で配布したアンケート LP の回答者(HubSpot リード)と、LINE 友だち(userId)を自動で紐づける仕組みを、追加サーバーなし・HubSpot ネイティブ機能 + LIFF だけで構築する方法を解説します。 課題: LINE 友だちとリードは「別人」のまま LINE 公式アカウントの友だちは LINE 上の userId でしか識別できず、HubSpot のコンタクトはメールアドレスをキーに管理されます。アンケート LP の URL を LINE で配って回答を集めても、そのままでは 「この回答者は LINE のどの友だちなのか」が分からない 「友だちのうち誰が回答済み/未回答か」のセグメントが作れない HubSpot のリスト起点で LINE Push 配信ができない という状態になります。紐づけの鍵は、フォーム送信時に LINE の userId を一緒に HubSpot へ渡すことです。 方式比較 userId をフォームに同乗させる方法は主に 3 つあります。 方式 仕組み 配信方法 確実性 ① LIFF(推奨) LP を LIFF アプリとして開き、SDK で userId を取得 → hidden フィールドで同送 ブロードキャスト可(全員同じ URL) 高 ② パーソナライズ URL ユーザーごとに ?t=<トークン> 付き URL を Push 送信。トークン↔userId の対応表をサーバーで保持 Push のみ(個別配信・通数コスト増) 中(URL 転送リスク) ③ LINE Login LP に「LINE でログイン」ボタンを設置 自由 高(ただし回答前に同意画面が挟まり離脱要因) 「全員に同じ URL をブロードキャストで配れて、ユーザー操作ゼロで userId が付いてくる」のは LIFF だけです。アンケート用途なら実務上ほぼ一択と言えます。 ...

2026年6月4日 · 4 分

HubSpot 重複コンタクトを API でマージする方法 — AI 検知 × 人間承認の 3 ステップ設計

HubSpot を運用していると必ず直面するのが重複リード(コンタクト)の問題です。同じ人がフォーム経由とインポート経由で別レコードになっている、表記揺れで名寄せされていない——こうした重複を放置するとメール配信もスコアリングも狂います。 結論から言うと、API を使って 2 つのコンタクトをマージすることは可能です。HubSpot の API にはコンタクトのマージ用エンドポイントが用意されており、マージ機能自体は Starter プランでも利用できます(API 実行には Private App の作成権限 = Super Admin が必要)。 ただし、「AI エージェントだけで全自動で重複を検知・マージまで完結させる」のは、安全性の観点から少しハードルが高いです。マージは一発勝負でやり直しが効かないからです。 現実的かつ賢いやり方は、「AI に重複を見つけさせてリスト化させ、マージ自体は API で行う(または人間が承認する)」というシステムを組むことです。本記事では具体的な仕組みと API の実装方法を解説します。 AI × API で実現する「自動重複マージ」の設計図 全自動で裏でマージしてしまうと、同姓同名の別人(例:「佐藤一郎」さんという別の会社の人)をマージしてしまうリスクがあります。そのため、以下のような 3 ステップの仕組みを作るのが一般的です。 Step 1: AI が検知 — AI(またはスクリプト)が「名前が一致、かつ会社名や電話番号が類似」しているリードを抽出 Step 2: 人間が確認 — Slack や社内ツール、Google スプレッドシート等に「この 2 人、マージして大丈夫ですか?」と AI が通知 Step 3: API で実行 — 人間が「承認(OK)」ボタンを押したら、システムが HubSpot API を叩いて安全にマージを実行 Step 1「AI が検知」を分解する 「AI が検知」は実際には 4 つの工程に分かれます。すべてを LLM にやらせるのではなく、機械的に絞り込めるところはスクリプトで処理し、あいまいな判断だけを LLM に渡すのがコストと精度のバランスを取るコツです。 ...

2026年6月4日 · 2 分

HubSpot CMS のキャッシュをバイパスする hsCacheBuster の使い方と注意点

HubSpot CMS で「変更したのにページに反映されない」「自分の環境だけ古いまま見える」といった経験はないだろうか。HubSpot は CDN とサーバーサイドキャッシュが多層構造で動作しているため、保存直後にブラウザでアクセスしても古いキャッシュを掴んでしまうことがある。 そんなときに役立つのが、URL の末尾に付けるだけでキャッシュをバイパスできる ?hsCacheBuster クエリパラメータだ。ただし「キャッシュをクリアする」のではなく「自分のリクエストだけキャッシュを経由させない」挙動なので、その違いを押さえて使うのがポイントになる。 ?hsCacheBuster の基本的な使い方 確認したいページの URL の末尾に ?hsCacheBuster を付与してアクセスする。 1 2 https://www.example.com/landing-page?hsCacheBuster https://www.example.com/landing-page?hsCacheBuster=001 任意の値(数字や文字列)を渡すこともできる。値を変えながらアクセスすれば、確実に毎回キャッシュを通さずに最新コンテンツを取得できる。これは、同一 URL が CDN にキャッシュされる仕組みのため、値が変わると別 URL として扱われ、毎回オリジンから取得されるためだ。 1 2 https://www.example.com/landing-page?hsCacheBuster=20260423-1 https://www.example.com/landing-page?hsCacheBuster=20260423-2 重要 — あくまで「自分の環境」のキャッシュバイパス ?hsCacheBuster で起きるのは 自分のリクエストに対してのみ、キャッシュを経由せず最新コンテンツが返る という挙動である。 ✅ 自分の画面では最新の HTML が確認できる ❌ 他のユーザー(クライアントや訪問者)にもすぐに反映されるわけではない ❌ HubSpot 側のキャッシュ自体が無効化されるわけでもない つまり「変更が自分には見えるが、他の人にはまだ反映されていない」というケースは珍しくない。「キャッシュを消す」ボタンではなく「キャッシュをバイパスして取得する」ボタン と理解しておくのが正確だ。 公開ユーザーにも即時反映させたいとき 公開ユーザー全員にすぐ反映させたい場合は、ページエディター側で軽微な変更をかけて保存し直すのが手軽な方法だ。 ヘッダー HTML や設定欄に半角スペースを 1 つ追加して保存 そのまま再度保存(スペースを消す) これで HubSpot 側がページを再生成し、CDN キャッシュも切り替わる。実コンテンツに変更を加えなくても、保存をトリガーすれば再ビルドが走るのがポイントである(2026 年 4 月時点での挙動)。 ...

2026年4月23日 · 1 分

django-mptt はなぜ「unmaintained」と書かれているのか — そして django-tree-queries への移行

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. ... この時点で「もうメンテしません」と公式宣言がなされた。 ...

2026年4月20日 · 5 分

バフェット・コード徹底分析 — EDINET XBRLを活用した企業分析SaaSの全貌

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

2026年4月7日 · 2 分

HubSpot Line Items 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" } } 取引や見積もりへの関連付けを同時に行う場合は、後述の「関連付け」セクションを参照してください。 ...

2026年3月18日 · 4 分

moomoo証券が米国株API取引に対応 — moomoo OpenAPIで個人投資家も自動売買が可能に

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

2026年3月18日 · 1 分

Theatre.js — GUI でWebアニメーションを直感的に作れるモーションデザインエディタ

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つの概念があります。 ...

2026年3月4日 · 4 分

リクルート新卒研修の React 資料が「無料で最高の教材」と言われる理由

リクルート新卒研修の 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 の違いを、歴史的な流れの中で説明しているのが特徴です。 ...

2026年3月2日 · 2 分

CloudWatch Logs のエラーを自動で GitHub Issues に課題化する

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 が作成されます。 ...

2026年2月24日 · 4 分