記事一覧

AIエージェントを本番運用していると、スキルが静かに壊れていく問題に直面する。agent-skill-bus は、エージェントスキルのヘルスモニタリング・自己改善・依存管理を担うフレームワーク非依存の運用基盤だ。 背景: 42体のAIエージェント運用で見えた課題 開発者のシュンスケ氏（@The_AGI_WAY）は、42体のAIエージェントを半年間運用する中で以下の課題に直面したという。 エージェントは壊れる — APIの変更、モデルのアップデート、認証の期限切れなどで、スキルが静かに劣化する タスクは衝突する — 複数のエージェントが同時に同じファイルを編集し、データ破損が発生する 依存関係が管理できない — 複雑なタスクはA→B→Cの順序が必要だが、多くのシステムは並列実行してしまう 学習ループがない — フィードバック機構がないため、同じ失敗が繰り返される 42体を人間が目視で監視するのは現実的ではない。そこで作られたのが agent-skill-bus だ。 3つのモジュール構成 agent-skill-bus は、独立して動作する3つのモジュールで構成されている。 モジュール 役割 Prompt Request Bus DAG（有向非巡回グラフ）ベースのタスクキュー。依存関係の解決とファイルロックを提供 Self-Improving Skills スキル品質の自動モニタリングと修復ループ Knowledge Watcher 外部変更の検知から自動改善トリガーを発火 これらが連携することで、閉ループの自己改善エージェントシステムを形成する。 1 2 3 4 5 外部変更 ──→ Knowledge Watcher ──→ Prompt Request Bus ──→ 実行 ↑ │ │ ↓ Self-Improving ←── スキル実行ログ Skills セットアップと基本的な使い方 Node.js のみで動作し、外部依存はゼロ。 ...

Sequoia Capital パートナーの Julien Bek が 2026年3月に発表した「Services: The New Software」は、AI ビジネスの方向性について本質的な問いを投げかけている。尾原和啓氏がこの論考を日本語で再構成しており、その内容をベースに要点を整理する。 「次の Claude が出たら、自分のプロダクトはただの機能になるんじゃないか」 AI ツールを作っている起業家たちが、心の奥で恐れていること。そしてこの恐怖は正しい。 ツールを売るビジネスはモデルとの競争になる。モデルが賢くなるたびに、自分たちの優位性が削られていく。 Bek の答えはシンプルで本質的だった。 ツールを売るな。仕事ごと引き受けろ。 「会計ソフト」ではなく「経理を丸ごとやる会社」になれ 会計ソフトに年間100万円。税理士・会計士に年間1,500万円。企業はずっとその両方にお金を払ってきた。 次の伝説的な企業は、そのどちらも置き換える。「AI で仕訳できます」ではなく、「経理、全部やっておきました」と言う会社として。 仕事そのものを引き受けるビジネスは、AI モデルが進化するたびに強くなる。速くなる。安くなる。競合されにくくなる。モデルの進化が脅威ではなく自分たちの武器になる。 ルール処理と判断 — AI の得意・不得意 重要な区別がある。 ルール処理とは、複雑なルールに従って処理する能力。コードを書く、書類を作る、申請書を埋める。どれだけ複雑でもルールはルール。正解がある。 判断とは、経験と直感に基づく意思決定。次に何を作るか、誰を採用するか、いつ撤退するか。これは場数と失敗からしか生まれない。 AI はすでにルール処理の大半を人間なしでこなせる水準に達した。その最前線がソフトウェアエンジニアリングで、全職種の AI ツール利用の 50% 以上を占めている。他の全職種はまだ一桁台だ。 ルール処理の比率が高い仕事から順番に、AI への移行が始まる。 「サポートする AI」と「代わりにやる AI」 AI ビジネスの形は今ふたつに分かれつつある。 サポート型は専門家にツールを売る。Harvey は AI を法律事務所に売る。Rogo は AI を投資銀行のアナリストに売る。専門家が主役で、AI はあくまでサポート役。責任は人間が持つ。 代行型はアウトカムを直接売る。法務 AI の Crosby は法律事務所ではなく、NDA が必要な企業そのものに売る。保険 AI の WithCoverage は保険ブローカーではなく、保険が必要な CFO に売る。「ツールを使いこなす」のではなく「結果が来る」という体験を売る。 どんな業界でも、ツールへの支出と人が動く仕事への支出を比べれば、仕事のほうが桁違いに大きい。よく引用される数字がある — ソフトウェアに使われる 1 ドルに対し、サービスには 6 ドルが使われている。代行型 AI は、その 6 ドルを初日から狙いに行く。 ...

コロンビア大学の Vishal Misra 教授が、AI のスケーリングの限界と AGI（Artificial General Intelligence: 汎用人工知能）実現に必要な条件について語っている。同教授はコンピュータサイエンス・電気工学を専門とし、AI・コンピューティング副学部長を務める。「モデルを大きくすれば知能に届く」という期待に対し、根本的に異なるアプローチが必要だという指摘だ。 スケーリングだけでは解決しない Misra 教授の主張の核心は明快だ。 いま広く存在している誤解の一つは、スケールを拡大すればすべて解決するというものです。ですが、スケールだけではすべては解決しません。必要なのは、別種のアーキテクチャです。 現在の LLM は、パラメータ数やデータ量を増やすことで性能を向上させてきた。しかし、この「スケーリング則」には限界がある。モデルを大きくしても、タスク固有の性能は上がるが、継続的に適応し汎化する能力は自動的には得られない。これこそが真の知能に必要な能力だ。 継続学習と破滅的忘却のジレンマ AGI に必要な第一の条件として、Misra 教授は「可塑性（plasticity）」を挙げる。これは継続学習（continual learning）によって実装されなければならない。 この継続学習は難しい問題です。新しいことを学べるという利点と、破滅的忘却のリスクを両立させなければならないからです。重みを更新しても、重要だったことや、すでに学んだことを忘れてしまうなら、それは進歩ではありません。そうなると、ただのランダムでカオスなモデルになってしまいます。 破滅的忘却（catastrophic forgetting）は、ニューラルネットワークが新しいタスクを学習する際に、以前のタスクの性能が急激に低下する現象だ。現在の LLM はファインチューニング時にこの問題に直面する。新しい知識を獲得しながら、既存の知識を保持する。この一見シンプルな要件が、技術的には極めて困難な課題だ。 相関から因果へ 第二の条件は、「相関から因果への移行」だ。 AGI に到達するには、二つのことが必要だと私は考えています。一つはこの可塑性であり、これは継続学習によって実装されなければなりません。もう一つは、相関から因果へ移行することです。 現在の LLM は、大量のテキストデータから統計的な相関パターンを学習している。「AのあとにBが来やすい」というパターンは捉えられるが、「AがBを引き起こす」という因果関係の理解は本質的に異なる。因果推論ができなければ、未知の状況での推論や、ある行動がどんな結果をもたらすかの予測は困難だ。 現在の AI 研究への示唆 Misra 教授の指摘は、現在の AI 開発の方向性に対する重要な問題提起だ。 スケーリングの限界: パラメータ数やデータ量の増加だけでは、質的な飛躍は起きない アーキテクチャの革新: Transformer アーキテクチャの改良だけでなく、根本的に新しい設計が求められる 継続学習の実現: 学習と記憶の両立は、脳科学の知見も取り入れた新しいアプローチが必要 因果推論の統合: 統計的パターンマッチングを超えた、因果モデルの構築が不可欠 「大きくすれば賢くなる」という単純な物語は魅力的だが、AGI への道はもっと複雑で、根本的なブレイクスルーが求められている。 参考 Vishal Misra - Columbia University Chatting about AI with our New Vice Dean of AI and Computing - Columbia Engineering

Anthropic が 2026年3月17日、Claude Cowork の新機能「Dispatch」のリサーチプレビューを開始した。スマホから指示を出すだけで、PC 上の Claude がタスクを自律的に実行してくれるという機能だ。 Dispatch とは Dispatch は、モバイル端末から PC 上で動作する Claude に対してタスクを割り当てられる機能。Claude Cowork のデスクトップアプリと iOS/Android のモバイルアプリを連携させ、外出中にスマホから指示を送り、帰宅したら作業が完了している、という使い方ができる。 主な特徴 モバイル・デスクトップ連携 スマホの Claude アプリからデスクトップ PC 上の Claude Cowork にタスクを送信する。PC 側では Computer Use（Claude がデスクトップの画面を認識して操作する機能）と組み合わせて、アプリの起動、ブラウザ操作、スプレッドシートへのデータ入力などを自律的に実行する。 永続的な会話スレッド モバイルとデスクトップの間で単一の会話スレッドが維持される。従来の Claude との会話ではセッションごとにコンテキストがリセットされていたが、Dispatch では前回のやり取りを記憶した状態でタスクを継続できる。 ローカル処理によるデータガバナンス タスク実行時のデータ処理はユーザーの PC 上で行われる。これにより、データガバナンスとコンプライアンスの面で優位性がある。 サンドボックス環境 ファイル操作などの重要なアクションは、実行前にユーザーの事前承認が必要。安全性を確保しつつ自律的な動作を実現している。 利用可能なプラン 2026年3月時点での対応状況: プラン 対応状況 Max 20x / Max 5x 利用可能 Pro 数日以内に対応予定 Free 2026年後半に対応予定 対応 OS は macOS のみ（リサーチプレビュー時点）。 OpenClaw との比較 Dispatch は、中国発のデスクトップ操作自動化オープンソースフレームワーク OpenClaw への Anthropic の回答とも位置づけられている。OpenClaw が深圳で大きな話題を呼んだのに対し、Dispatch はエンタープライズ向けの管理性・安全性を重視した設計になっている。 ...

紺野大地氏（@_daichikonno）が、Claude Cowork Dispatch に OpenClaw で育てた AI エージェント人格を移植する試みについて投稿し、「これは Mind Uploading そのものだ」と述べたことが話題になっています。AI エージェントのプラットフォーム間移植が、意識のアップロードという哲学的テーマとどう繋がるのかを考察します。 Claude Cowork Dispatch とは 2026年3月17日に Anthropic がリリースした Claude Cowork の新機能「Dispatch」は、スマートフォンから デスクトップの Claude エージェントを遠隔操作できる仕組みです。 主な特徴: モバイルからの遠隔指示: Claude モバイルアプリから、デスクトップ上の Claude に作業を依頼できる 永続的な会話スレッド: モバイルとデスクトップ間で単一の会話スレッドを共有 ローカル実行: ファイルはローカルに保持され、コードはサンドボックス内で実行 コネクタ・プラグイン連携: メール、Slack、Notion、Google Drive などと接続可能 現在は Max プラン（月額 $100〜$200）で利用可能で、Pro プラン（月額 $20）への展開も予定されています。 OpenClaw とは OpenClaw は 2026年に急速に広まったオープンソースの AI エージェントフレームワークです。公式の説明では「自分のデバイスで動かすパーソナル AI アシスタント」とされていますが、その実態は プログラム可能なワークフローエンジンで、中核に AI がある というものです。 Nvidia が「OpenClaw はエージェント AI にとって、GPT がチャットボットにとってそうであったものだ」と評しています。では、チャットボットにイベントハンドラを定義して Claude Code を呼び出すだけでは「OpenClaw 的」とは言えないのでしょうか？ 答えを理解するには、OpenClaw のアーキテクチャを見る必要があります。 ...

GNU Inetutils の telnetd デーモンに、CVSS 9.8 の深刻なバッファオーバーフロー脆弱性 CVE-2026-32746 が発見された。1994年から存在していたこのバグは、認証前のリモートコード実行（Pre-Auth RCE）を可能にする。telnetd を公開サーバーで運用している管理者は直ちに対応が必要だ。 脆弱性の概要 項目 内容 CVE ID CVE-2026-32746 CVSS スコア 9.8（Critical） 影響範囲 GNU Inetutils 2.7 以前の全バージョン 脆弱性の種類 BSS ベースのバッファオーバーフロー（境界外書き込み） 攻撃条件 認証不要・リモートから実行可能 発見者 イスラエルのサイバーセキュリティ企業 Dream（技術解析: watchTowr Labs） 報告日 2026年3月11日 技術的な詳細 脆弱な箇所 脆弱性は LINEMODE SLC（Set Local Characters）サブオプションハンドラの add_slc 関数に存在する。telnetd はクライアントから送られた SLC トリプレット（3バイト組）を固定サイズのバッファ slcbuf（0x6C バイト）に格納する。この際、境界チェックを一切行っていない。 1 2 3 4 5 6 7 8 9 // 境界チェックなしでバッファに書き込む脆弱なコード if ((*slcptr++ = (unsigned char) func) == 0xff) *slcptr++ = 0xff; if ((*slcptr++ = (unsigned char) flag) == 0xff) *slcptr++ = 0xff; if ((*slcptr++ = (unsigned char) val) == 0xff) *slcptr++ = 0xff; 攻撃の仕組み Telnet の接続確立時に行われるオプションネゴシエーション（機能交渉）中に、特別に細工されたパケットを送信することで攻撃が成立する。具体的には以下のプロトコルフォーマットを悪用する: ...

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

HubSpotを活用してディナータイムの集客を強化するのは、非常に理にかなった戦略です。レストランの場合、**「適切なタイミングで、適切な人に、美味しそうな視覚情報を届ける」**のが鉄則です。 MA（マーケティングオートメーション）の強みを活かした、具体的で即効性のある施策を紹介します。 1. 顧客リストのセグメント化とパーソナライズ 「夜の利用者」を増やすには、まず「誰が夜に来てくれる可能性が高いか」を分類します。 「ランチのみ利用者」の抽出 HubSpotのコンタクト管理で、過去の予約データからランチ利用のみの顧客をリスト化します。「ランチとは違う夜の特別な雰囲気」を訴求するメールを自動送信します。 記念日フラグの活用 誕生日や結婚記念日の1ヶ月前に、「ディナー限定の乾杯スパークリングサービス」などの特典付きワークフローを起動させます。 2. 行動ログに基づいた「空腹時」のプッシュ HubSpotのトラッキング機能を使い、顧客がWebサイトを閲覧した瞬間にアプローチします。 夕方の特定ページ閲覧をトリガーに 16:00〜18:00の間にメニューページや予約ページを見たが予約に至らなかったユーザーに対し、**「本日空席あり。今すぐの予約でデザート1品サービス」**といった内容を、LINE（連携時）やメールで即座に送ります。 HubSpotではカスタムイベントと行動トリガーを組み合わせたワークフローを構築でき、ページ閲覧をトリガーとした自動配信が可能です。行動トリガーメールは、通常の一斉配信メールと比較して約50%高い開封率が期待できるとされています。 3. シーン別のコンテンツ作成とリードマグネット 「夜に行こう」と思うきっかけをWebサイト上に作ります。 利用シーン別のランディングページ (LP) 「接待・会食」「大人のデート」「自分へのご褒美」など、目的別のLPを用意します。HubSpotのCMS Hubを使えば、これらのページを簡単に作成・管理できます。 eBook/クーポンの配布 「ソムリエが選ぶ、お肉料理に合うワインガイド」などの資料ダウンロードと引き換えにメールアドレスを獲得し、そこからディナー誘導のステップメールを流します。 4. HubSpotとSNS・広告の連携 リターゲティング広告 Webサイトのディナーメニューを見たユーザーに対して、Instagramで「夜のシズル感溢れる動画広告」を配信します。HubSpotの広告管理ツールを通じて、Facebook/Instagram広告との連携が可能です。 Google ビジネスプロフィールとの連動 HubSpotで収集したポジティブなレビューをGoogleに反映させる仕組みを作り、「夜の評判」を可視化して新規客の安心感を高めます。 施策の優先順位 施策内容 難易度 期待効果 必要なツール 記念日自動メール 低 高 HubSpot ワークフロー ランチ客へのディナー訴求 低 中 リストセグメント 閲覧行動ベースのリアルタイム配信 中 高 トラッキングコード + ワークフロー シーン別LP作成 中 中 CMS Hub LINE連携について HubSpotとLINEの連携には、LITTLE HELP CONNECT などのサードパーティツールを利用します。連携することで、HubSpotのワークフローからLINEメッセージの自動配信が可能になり、セグメントごとに異なるメッセージを適切なタイミングで届けられます。 まとめ HubSpotのMA機能をレストランの集客に活用することで、「来てほしい人に、来てほしいタイミングで、行きたくなる情報を届ける」仕組みを構築できます。まずは難易度の低い記念日メールやランチ客へのディナー訴求から始め、段階的にトラッキングベースの施策へ拡張していくのがおすすめです。

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

個人開発者の Ernest Lopez 氏が、OpenClaw を活用して広告制作を自動化し、年間30万ドル規模のアプリ収益を伸ばしている事例が話題になっている。AIエージェント「Eddie」を中心としたワークフローは、競合リサーチから広告制作、パフォーマンス改善まで一気通貫で回す仕組みだ。 バイブマーケティングとは 「バイブマーケティング（Vibe Marketing）」は、AIエージェントにマーケティング業務を任せる新しいアプローチだ。従来の手作業による広告制作・テスト・改善サイクルを、AIが自律的に回す。Lopez 氏のケースでは、月3万ドルかけていた代理店を OpenClaw エージェントに置き換え、さらに月2万ドルの追加収益を生み出している。 Eddie のワークフロー：5つのステップ Lopez 氏が構築した AIエージェント「Eddie」は、以下の5段階で広告を自動生成する。 1. 競合リサーチ Meta Ad Library から競合の勝ちパターン広告を収集する。Apify（Webスクレイピングツール）で広告動画をスクレイピングし、Whisper（OpenAI の音声認識モデル）で文字起こしして、効果的な訴求軸（アングル）を抽出する。 2. ブランドボイスの学習 AIが「AIっぽい文章」を書かないよう、以下のマークダウンファイルで知識を注入する。 writing-rules.md — AIが多用する表現を禁止するルール voice.md — ブランドの口調・トーン product.md — 製品の詳細情報 icp.md — 理想的な顧客像（Ideal Customer Profile） これにより「商品に精通した高CVR（コンバージョン率）インフルエンサー」のような語り口で台本を生成できる。 3. スクリプト生成 競合広告の分析結果をもとに、ブランドボイスでオリジナルの広告台本を作成する。さらにオーディエンスセグメントごとに50〜100以上のバリエーションを自動生成する。 4. クリエイティブ制作 生成した台本を2つのルートで動画化する： UGCクリエイターへの外注（1本15〜50ドル）— 品質重視のトップスクリプト向け Arcads（AI UGC広告作成ツール） — 複数のAIアクターと組み合わせて大量のバリエーションを生成 Arcads は1,000以上のAIアクターを持ち、リアルな人物ベースのAI動画広告を生成できるプラットフォームだ。 5. 自己改善ループ Singular MMP（モバイル計測プラットフォーム）経由でパフォーマンスデータを取得し、CPA（顧客獲得単価）を分析。効果の高いパターンを学習して次のバッチを改善する PDCA サイクルを自動で回す。 なぜこのアプローチが注目されるのか このワークフローの核心は、単に「AIで広告を作る」だけでなく、リサーチ → 制作 → 計測 → 改善のサイクル全体をAIエージェントが自律的に回す点にある。 従来のマーケティングでは、各工程に専門のスタッフやツールが必要だった。Lopez 氏は OpenClaw のスキルシステムを使い、Claude Opus 4.6 の API で複数のAIエージェントを連携させることで、これを低コストで実現している。 ...