記事一覧

https://t.co/xruRnJQLbO — ruma (@FxRumasan) March 24, 2026 「利確」とは何か 利確（りかく） は「利益確定」の略で、保有している株や通貨などの金融商品を売却（または買い戻し）して、含み益を実際の利益として確定させることです。 例えば、1,000円で買った株が1,500円に上がったとします。この時点では「含み益（まだ確定していない利益）」が500円あるだけです。実際に1,500円で売って初めて、500円の利益が「確定」します。これが利確です。 なぜ「利確が上手い」が重要なのか 投資やトレードでは「安く買って高く売る」のが基本ですが、実際に難しいのはいつ売るかの判断です。 売った後にさらに上がれば「早く売りすぎた」と後悔する 待っていたら下がってしまい「あのとき売っておけば」と後悔する つまり利確が上手いとは、この「いつ売るか」の判断を感情に振り回されず、自分が納得できるタイミングで実行できることを意味します。 トレードで一番難しいのは、まさにこの「利確」です。損切りは間違いが確定した後なので決めやすい。一方、利確はまだ伸びるかもしれない利益を自分から手放す判断です。この悩みは何年経っても完全には消えません。 つまり利確は、正解を当てるゲームではなく、納得度を高めるゲーム。そのための設計を作ることが求められます。 今回は、利確が少し上手くなる4つのテクニックを紹介します。 1. 利確に正解はない 多くのトレーダーは神利確を狙ってしまいます。実際に神みたいな利確は生まれますが、一見"神利確"でも時間が経てば"凡利確"になっているものです。 大事なのは、どこまで取れたかではなく、自分が納得できる基準で降りられたかです。 「事前に決めた場所で利確出来たら正解（上手い）」 全部取る神利確は目指さなくていい。後から伸びた利益は、最初から自分の取り分ではないのですから。 2. 逆ポジ質問 「逆ポジ」とは「逆ポジション」の略で、今持っているポジションと反対の方向のことです。買いで持っているなら「売り」、売りで持っているなら「買い」を指します。逆ポジ質問とは、利確したいと思ったときに「ここで逆方向に入れるか？」と自分に問いかけるテクニックです。 保有中というのは、不安の感情が1.8倍くらいに肥大化します（体感）。 「うわっ！利確してぇぇぇ！！」「ここから下落して含み損になったらどうしよう…」みたいな感情から、決済ボタンをクリックしてしまう。結果、「うわぁ利確しなければ、倍の含み益あったなぁ…。」みたいな後悔が連続してしまいます。 そんな不安が肥大化したときは、“感情脳"から"根拠脳"へと切り替えるために逆根拠を考えてください。 例えば、「利確したい場所で、逆方向にエントリーできるほどの根拠あるか？」と自問します。 買いポジなら、利確したい場所で"売れるか？“を考える 売れると思えば、利確してOK 売れないと思えば、保有を続けるべき これは正解かどうかではなく、「根拠で入ったのに、感情で利確する。」という一貫性のない取引を減らすための処置です。 根拠（分析）で入ったのであれば、根拠で決済する。 この習慣を作りましょう。 3. 50/50決済 感情というのは押し込むものではなく、設計で乗り越えるものです。感情を無理やり消そうとする人ほど、ぶっ壊れます。 多くの人は以下の2択しかありません： 感情に従うか それとも抑え込むか だからこそ、感情に負け、抑え込もうとしてストレスで更に負けます。 感情を半分受け入れ、残り半分を理屈に預けること。これを続けると、根拠（理屈）と感情のどちらが正しいのか実体験ベースでわかるようになってきます。根拠の方が正しいと実体験で理解すれば、利確も上手くなります。 まずは、少しずつ変えていく努力が大事ですね。 4. 前提固定利確 みんなエントリーをするときは「上昇トレンドだから入る」「レンジだから細かく取る」と決めていても、いざ利確になるとその前提がなくなって、結局"感情脳"で決済してしまいます。 だから、利確も同じく決めておくこと。 トレードするときも、必ず目線を言語化して、例えば「上昇トレンドに順張りする＝高値更新はすると考えている」みたいに、自分が何を考えて保有したのか「前提」だけでも固定させるべきです。 さらに、その前提が崩れるパターンも考えておきましょう。例えば： 「急落が来たら」想定が崩れたと判断して、トレンド狙いでもレンジ目線で利確可能。（買いの場合） こんな感じで、不規則な動きが多い相場で、どこまで利確シナリオを想定できるかも重要になってくるのです。 まとめ 整理すると： 利確に正しい答えはない — 納得できる基準で降りられたら正解 逆ポジ質問 — 逆方向にエントリーできる根拠があるか自問する 50/50決済 — 感情を半分受け入れ、残り半分を理屈に預ける 前提固定利確 — エントリー時の前提と崩れるパターンを事前に決める つまり、利確はセンスではなく「設計」だと思っています。その中でも、保有中に自分へ問いを投げる"質問形式"はかなり強いです。 保有中に焦ったら、以下の3つだけを問いかけてください： ...

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取引あたりポジション上限）は既にテンプレート変数化されていた： ...

30以上のAIエージェント記憶システムを調査した結果、Mem0・MemGPT・Letta・Zepを含むすべてのシステムがコサイン類似度を採用していることが明らかになった。さらに2020〜2026年のNeurIPS・ICML・ACLの主要論文を調べても、これを研究上の問題として指摘した論文は1本も存在しないという。 SuperLocalMemory V3（SLM-V3） はこの構造的問題に対し、フィッシャー情報量メトリクス・シーフコホモロジー・リーマン多様体上の確率微分方程式という3つの数学で挑むシステムだ。 なぜコサイン類似度では不十分なのか コサイン類似度の問題は記憶が増えると顕在化する。 「コサイン近傍」に入るベクトルの数は記憶の総数に比例して線形に増える。一方、「本当に関係ある記憶」はクエリの情報量に縛られた有限個のまま変わらない。記憶を積み重ねるほど、検索ランキングはノイズに溺れていく。 加えて、既存システムには2つの設計上の問題がある。 忘却が手動設定の半減期に依存している（固定パラメータ） 矛盾した記憶はそのまま放置される（検出機構がない） SLM-V3の3つの数学的アプローチ 1. フィッシャー情報量メトリクスによる検索の置き換え コサイン類似度は埋め込みの全次元を均等に扱う。しかし実際には、次元ごとに信頼性が大きく異なる。意味的区別を鮮明に捉える次元もあれば、ノイズしか拾わない次元もある。 論文の具体例が直感的だ。クエリから同じ距離に記憶AとBがあったとする。 記憶A：埋め込み空間で「似たものが周りにたくさんある」密集ゾーン 記憶B：「ここにしかない」希少ゾーン 情報として価値があるのはBのはずだが、コサイン類似度はAとBを同等に扱ってしまう。 SLM-V3は各次元を逆分散（信頼度の高さ）で重み付けするフィッシャー情報量メトリクスに置き換える。これはCencovの定理が示す「統計多様体上で唯一の数学的に自然な計量」だ。 2. シーフコホモロジーによる矛盾の代数的検出 エージェントが長期間動き続けると、矛盾する記憶が積み重なる。「このAPIはREST」と「このAPIはGraphQL」のような相反する情報が共存しても、既存システムはどちらかを黙って返すだけで矛盾に気づけない。 SLM-V3はシーフコホモロジー（代数トポロジーの道具）を使い、矛盾を代数的に検出する。第1コホモロジー群 H¹ が非自明であれば矛盾が存在する。AIエージェント記憶における初の矛盾検出の数学的保証だ。 3. ポアンカレ球面上の確率微分方程式による忘却管理 従来の固定半減期による忘却を廃止し、ポアンカレ球面上の確率微分方程式（リーマン・ランジュバン動力学） で記憶の重要度を管理する。 重要度の低い記憶はポアンカレ球の境界に向かってドリフトし、自然に忘却される。フォッカー・プランク方程式による収束保証付きであり、手動パラメータ調整が不要になる。 ベンチマーク結果（LoCoMoデータセット） LoCoMoベンチマーク6会話での比較結果： 手法 スコア コサイン類似度のみ 58.9% 数学的層あり（SLM-V3） 71.7% 差分 +12.8ポイント 特に注目すべきは、難しい会話ほど差が広がる点だ。最も複雑なconv-44では +19.9ポイントの差を記録している。コサイン類似度が最も苦手なスパース埋め込み領域でフィッシャー計量が効くという理論的予測と一致する。 アブレーション分析では、最も効果が大きかったのはクロスエンコーダ再ランク付け（除去すると-30.7ポイント）だった。数学的層の+12.8ポイントはこれと独立して機能する相補的な仕組みであり、どちらかだけで代替できるものではない。 ゼロLLM構成とEU AI法対応 SLM-V3はゼロLLM構成（クラウドAPI完全不要）で検索品質75%を達成している。これにより、EU AI法（規制2024/1689）のデータ主権要件をアーキテクチャ設計レベルで満たす初の評価となった。2026年8月の完全施行を見据えた設計だ。 コードと利用 コードはMITライセンスで公開されている。 GitHub: qualixar/superlocalmemory まとめ SLM-V3が提起する問題意識は明快だ。AIエージェントの記憶システムはコサイン類似度という「とりあえず動く」実装のまま止まっており、記憶量の増大・矛盾の蓄積・固定半減期という3つの設計上の欠陥を誰も研究問題として指摘してこなかった。 フィッシャー情報量メトリクス・シーフコホモロジー・リーマン・ランジュバン動力学という重厚な数学的道具立ては、記憶システムの「当たり前」を問い直す試みとして注目に値する。

Anthropic の研究者 Prithvi Rajasekaran 氏が、Claude を使ってフルスタックアプリケーションを自律的に構築する「3エージェント・ハーネス」アーキテクチャを公開しました。人間の介入なしに6時間でプレイ可能なゲームエディタを完成させた事例とともに、その設計思想を解説します。 「ハーネス設計」とは何か 「ハーネス（harness）」とは、AI モデルを単体で走らせるのではなく、モデルの外側に構築する制御構造・オーケストレーションロジック全体を指します。具体的には、どのエージェントがどの順番で何を担当するか（役割分離）、エージェント間でどう情報をやり取りするか（契約の交渉）、いつ次に進みいつやり直すか（判定ループ）、何を使ってテストするか（ツール選択）といった設計要素が含まれます。 モデル自体の性能向上とは別の軸で、この制御層をどう設計するかが自律開発の品質を左右します。 背景: AI は自分に甘すぎる このアーキテクチャが生まれた核心的な課題は、AI モデルが自分の出力に対して甘い評価をしがちであるという点です。 「自分が生成した成果物を評価させると、エージェントは自信を持ってそれを称賛する傾向がある —— 人間の目から見れば明らかに品質が低い場合でさえ」（Rajasekaran 氏） この問題は、デザインのような正解/不正解が明確でない領域で特に顕著です。コードにおいても、理論上は正しさを検証できるはずですが、AI エージェントは自分のエラーをスルーしてしまいがちです。 解決策として採用されたのが、GAN（Generative Adversarial Network: 敵対的生成ネットワーク）に着想を得た分離アプローチ —— 「作る役割」と「評価する役割」を完全に分けるという設計です。 3エージェント・アーキテクチャ 最終的に構築されたハーネスは、以下の3つの専門エージェントで構成されるアーキテクチャになっています。 エージェント 役割 Planner 1〜4文のアイデアを完全な製品仕様に展開 Generator 機能ごとにスプリント方式で実装 Evaluator 実行中のアプリを Playwright でテスト・採点 flowchart TD A["ユーザー\n1〜4文のアイデア"] --> B["Planner\n製品仕様に自動展開"] B --> C["スプリント契約の交渉\n終了条件の事前合意"] C --> D["Generator\nReact/Vite/FastAPI で実装"] D --> E["Evaluator\nPlaywright MCP で実アプリテスト"] E -->|"採点: 製品深さ・機能性\nデザイン・コード品質"| F{合格?} F -->|"不合格\nバグ報告 + 改善指示"| D F -->|"合格"| G{次のスプリント?} G -->|"あり"| C G -->|"なし"| H["完成アプリ"] Planner: 仕様の自動展開 初期バージョンでは、生のプロンプトを渡すとモデルがタスクを過小評価する問題がありました。十分に考える前にビルドを開始してしまい、機能の薄いアプリが生成されていたのです。Planner はこの問題を解決するために追加されたエージェントで、短いアイデアを詳細な製品仕様に自動展開します。 ...

「1ヶ月後のYouTubeはOpenClawが全て運用し『月1000万円』収益を上げるアカウントが大量発生する」——こんな投稿が X（旧 Twitter）で話題になっています。本当にそこまでできるのか、OpenClaw の技術的な能力と YouTube 運用の現実を照らし合わせて検証します。 元の主張の要約 X ユーザー @gagarot200 の投稿では、以下のような主張がなされています: 海外では既に 2000 万円を稼いでいるケースがある 勝負のポイントは編集技術ではなく「企画設計」「視聴維持率」「CTR改善」「投稿導線の最適化」 OpenClaw で競合分析→台本生成→素材選定→動画編集→サムネイル量産→投稿→数値分析を一気通貫で回せる 個人でもチーム運用レベルの全自動化が可能 OpenClaw とは OpenClaw は、GitHub で 34 万スター以上を獲得しているオープンソースの AI エージェントフレームワークです。ローカルマシン上で動作し、ブラウザ操作・ファイル読み書き・シェルコマンド実行・cron ジョブなどを自律的に実行できます。WhatsApp、Telegram、Slack、Discord など多数のメッセージングプラットフォームに対応しています。 技術的に「できること」と「できないこと」 OpenClaw で実現可能な部分 OpenClaw の Skills（プラグイン）機能とブラウザ自動化を組み合わせると、以下のタスクは技術的に実現可能です: タスク 実現方法 実用度 競合チャンネル分析 YouTube Data API + ブラウザスクレイピング ◎ 台本生成 LLM による構成生成 ◎ サムネイル量産 画像生成 AI + テンプレート自動適用 ○ 投稿スケジューリング YouTube Data API / ブラウザ自動化 ○ 数値分析・レポート YouTube Analytics API からのデータ取得・分析 ◎ CTR / 視聴維持率の改善提案 分析データを LLM にフィードバック ○ 現状では難しい部分 一方で、以下の部分には大きなハードルがあります: ...

opencli-rs は、55以上の主要サイトに対応したRust製のCLIツールです。サイトごとにAPIやスクレイピング方法が異なる煩雑さを解消し、1つのコマンドで各プラットフォームの情報を取得できます。 opencli-rs とは opencli-rs は、元々TypeScriptで実装されていた OpenCLI をRustで完全に書き直したツールです。X (Twitter)、YouTube、Reddit、Hacker News、Bilibili、Zhihu、Xiaohongshu（小紅書）など多数のプラットフォームに対応しています。Chromeのログインセッションを再利用するため、APIキーなしでデータを取得できます。 出力形式はテーブル、JSON、YAML、CSV、Markdownに対応しており、用途に応じて使い分けが可能です。また、Electronベースのデスクトップアプリをコマンドラインから制御する機能も備えており、GUIアプリの操作をスクリプト化できます。 主な特徴 処理速度が最大12倍に向上 — TypeScript版と比較して大幅な高速化（例: Bilibili Hot の取得が20.1秒から1.66秒に） メモリ使用量を10分の1に削減 — 95-99MBから9-15MBへ シングルバイナリで動作 — わずか4.7MB、追加のランタイム不要でどの環境にも導入可能 インストール インストールスクリプトが用意されており、システムとアーキテクチャを自動検出してバイナリをダウンロードします。 1 curl -fsSL https://raw.githubusercontent.com/nashsu/opencli-rs/main/scripts/install.sh | sh Rustの開発環境がある場合はソースからビルドすることもできます。 1 2 3 git clone https://github.com/nashsu/opencli-rs.git cd opencli-rs cargo build --release AIエージェントとの連携 opencli-rs はAIエージェントとの連携を前提に設計されています。Claude Code や Cursor などに組み込むことで、「Hacker Newsのトップ記事を取得して要約する」「競合のX投稿を定期的にチェックする」といったWeb情報収集の自動化が可能です。 AIエージェント向けのスキルパッケージ opencli-rs-skill も提供されています。 1 npx skills add https://github.com/nashsu/opencli-rs-skill これにより、AIエージェントが AGENT.md や .cursorrules の設定を通じて利用可能なツールを自動的に検出し、自然言語でWebスクレイピングを実行できるようになります。 ...

AI エンジニアリングの中心概念が急速に変化している。2022年の「Prompt Engineering」から2025年の「Context Engineering」を経て、2026年は「Harness Engineering」の年になった。Anthropic、OpenAI、そして Martin Fowler まで、業界のキープレイヤーが揃ってこの概念を公式に取り上げている。 3つの時代: プロンプトからハーネスへ Prompt Engineering（2022〜） ChatGPT の登場とともに広まった最初のパラダイム。LLM に対してどんな言葉で指示するかが品質を左右する、という考え方だ。Few-shot、Chain-of-Thought、Role Prompting といったテクニックが次々と開発された。 焦点は「1回のリクエストにおける入力テキストの最適化」にあった。 Context Engineering（2025〜） 2025年中盤、Shopify CEO の Tobi Lutke が X への投稿をきっかけに「Context Engineering」という用語が急速に広まった。LangChain や Anthropic も相次いで解説記事を公開し、業界標準の概念として定着した。 Prompt Engineering が「何を言うか」に注目していたのに対し、Context Engineering は**「LLM に何を見せるか」を動的に制御するシステム**を設計する。RAG（Retrieval-Augmented Generation）、ツール呼び出し、メモリ管理など、LLM の入力コンテキスト全体をエンジニアリングの対象とする発想だ。 Harness Engineering（2026〜） 2026年に入り、AI エージェントの実用化が本格化するなかで、Context Engineering をさらに拡張した「Harness Engineering」が登場した。 Context Engineering が「LLM に何を見せるか」を扱うのに対し、Harness Engineering はエージェントの実行環境全体 —— 役割分担、フィードバックループ、品質検証、セッション管理まで含めた制御構造を設計する。 「ハーネス（harness）」は馬具の意味で、強力な馬（= AI モデル）を制御し、安定した成果を引き出すための仕組み全体を指す。 業界キープレイヤーの動き OpenAI: Codex チームの実践（2026年2月） OpenAI は2026年2月、公式ブログで「Harness engineering: leveraging Codex in an agent-first world」を公開した。 ...

サプライチェーン攻撃とは、ソフトウェアの開発・配布の過程（サプライチェーン）に侵入し、正規のパッケージやツールに悪意あるコードを混入させる攻撃手法です。開発者が信頼して利用しているライブラリが攻撃の入口になるため、通常のセキュリティ対策では気づきにくいのが特徴です。 2026年3月27日、PyPIで月間74万ダウンロードを誇る通信プラットフォーム Telnyx の公式 Python SDK（telnyx）が、まさにこのサプライチェーン攻撃によって汚染されました。攻撃者グループ TeamPCP が悪意あるバージョン 4.87.1 および 4.87.2 を公開しました。これらは import するだけでマルウェアが実行される極めて危険なものです。 何が起きたのか タイムライン 2026年3月27日 03:51 UTC — 悪意あるバージョン 4.87.1 と 4.87.2 が PyPI に公開 同日 10:13 UTC — PyPI によって当該バージョンが隔離（quarantine） 約6時間にわたり、pip install telnyx を実行したユーザーは悪意あるバージョンをインストールする可能性がありました。 攻撃の仕組み 悪意あるコードは telnyx/_client.py に注入されていました。パッケージを import するだけで自動実行される仕組みです。攻撃は以下の手順で進行します: 初期実行: import telnyx だけでマルウェアコードが発動 ペイロード取得: リモートサーバーから WAV 音声ファイルをダウンロード ステガノグラフィ（データを別のファイルに隠す技術）: WAV ファイルのオーディオフレーム内に実行ファイルが埋め込まれている 環境別の挙動: Windows: 永続的な実行ファイルをドロップ Linux/macOS: クレデンシャル（認証情報）を窃取 WAV ファイル内に実行ファイルを隠すステガノグラフィ手法は、通常のセキュリティスキャンやウイルス対策ソフトでは検出が困難です。音声ファイルという無害に見えるファイル形式を悪用している点が巧妙です。 TeamPCP のサプライチェーン攻撃キャンペーン 今回の telnyx 攻撃は単独の事件ではありません。TeamPCP は2026年3月20日以降、以下のような連鎖的なサプライチェーン攻撃を展開しています: 対象 種別 影響 Trivy セキュリティスキャナー CI/CD クレデンシャルの窃取 Checkmarx (KICS) セキュリティツール 同上 LiteLLM AI/LLM プロキシ 認証情報の窃取 telnyx 通信 API SDK クレデンシャル窃取 + マルウェアドロップ 攻撃パターンは一貫しています: ...

「AI疲れ」という言葉が広がる中、Claude Code のハーネス機能（Skill, Agent, MCP, Memory）は不要であり、シンプルな CLI で十分だという主張が話題になっている。この議論の論点を整理し、実際の開発現場での実用性を考察する。 話題の発端 Kai Aoki 氏（@kaixaoki）が X で投稿した「AI疲れしてる各位に贈るアンサー」が注目を集めた（2026年3月時点で 531 いいね、462 ブックマーク、約9.8万表示）。 主張は以下の4点: ドキュメントが全て — コードや設定よりもドキュメントが最重要 Skill, Agent, MCP, Memory 全て不要 — CLI で解決可能 ハーネス独自機能は全て不要 — 物理マシン/VM で隔離せよ 賢いモデルがいずれ全てを解決する — 機能追加より待つべき さらに「特に Claude Code はハーネスを複雑化してロックインし、虚業を生み出しているので Evil」と結論づけている。 各論点の検討 ドキュメントが全て これは多くの開発者が同意できる主張だ。CLAUDE.md や README に適切な情報を書いておけば、AI エージェントは文脈を理解して適切に動作する。実際、Claude Code の公式ドキュメントでも「CLAUDE.md に何を書くか」が最も重要な設定項目として紹介されている。 ただし、ドキュメントだけでは解決しづらい課題もある。繰り返しのワークフロー自動化や、外部サービスとの連携は、仕組みとして定義した方が効率的なケースがある。 Skill/Agent/MCP/Memory は不要か シンプルな使い方なら不要というのは正しい。1ファイルのバグ修正やコードレビューに Skill や Agent は必要ない。 一方、以下のようなケースではこれらの機能が実用的な価値を持つ: Skill: 定型作業（ブログ記事作成、PR レビュー、デプロイ手順）を毎回説明する手間を省く Agent: 並列タスク実行（ファクトチェックと SEO 分析の同時実行など） MCP: 外部 API やデータベースへのアクセスを安全に管理する Memory: プロジェクト固有の慣習やユーザーの好みを会話をまたいで保持する 要は「必要な人には必要、不要な人には不要」という当たり前の結論になる。問題は、これらの機能がオプトインであるかどうかだ。Claude Code ではいずれも使わなければ存在しないのと同じであり、強制されるものではない。 ...

AWS DMS Serverless Replication（CDC モード）が OOM（Out of Memory）で failed 状態になり、自動再起動の仕組みが検知できずに長期間停止していた問題について、根本原因と対策をまとめます。 構成 RDS (MySQL) → DMS Serverless (CDC) → S3 (Parquet) DMS Serverless Replication で全テーブルの CDC（Change Data Capture）を実行 S3 に Parquet 形式で日付パーティション付きで出力 EventBridge + Lambda で DMS 停止を検知し自動再起動する仕組みを構築済み 発生した事象 症状 prod 環境の DMS Serverless Replication が failed 状態で停止 エラーメッセージ: Replication out of memory. Stop Reason FATAL_ERROR Error Level FATAL CDC が完全に停止し、S3 へのデータ同期が止まっていた 発覚の経緯 手動確認で発見。自動再起動 Lambda の最終実行は約2ヶ月前で、それ以降は検知されていなかった。 根本原因 原因 1: EventBridge ルールのイベントパターンが不完全 自動再起動用の EventBridge ルールが REPLICATION_TASK_STOPPED のみを監視していた。 ...