kanchi-dividend-sop

Kanchi 配当 SOP

概要

Kanchi の 5 段階の手法を、米国の配当投資向けの決定論的なワークフローとして実装します。 積極的に高利回りを追い求めるよりも、安全性と再現性を優先します。

使用する場面

以下が必要な場合に、このスキルを使用します。

• 米国株に適用した、Kanchi スタイルの配当株選定。
• 場当たり的な銘柄選びではなく、再現可能なスクリーニングと押し目買いのプロセス。
• 明確な無効化条件を記載した 1 ページの投資判断メモ。
• モニタリングや税務・口座配置のワークフロー向け引き継ぎパッケージ。

前提条件

API キーの設定

エントリーシグナルのスクリプトには FMP API へのアクセスが必要です。

export FMP_API_KEY=your_api_key_here

入力ソース

ワークフローを実行する前に、以下のいずれかの入力を用意してください。

1. skills/value-dividend-screener/scripts/screen_dividend_stocks.py の出力。
2. skills/dividend-growth-pullback-screener/scripts/screen_dividend_growth_rsi.py の出力。
3. ユーザー提供のティッカーリスト（証券会社のエクスポートまたは手動リスト）。

JSON 入力の形式

--input を使用する場合は、以下のいずれかの形式の JSON を指定してください。

{
  "profile": "balanced",
  "candidates": [
    {"ticker": "JNJ", "bucket": "core"},
    {"ticker": "O", "bucket": "satellite"}
  ]
}

または、簡略形式：

{
  "tickers": ["JNJ", "PG", "KO"]
}

オプションの value-dividend-screener と dividend-growth-pullback-screener の引き継ぎデータでは、stocks[].symbol を使用します。 build_sop_plan.py --input と build_entry_signals.py --input は、 この形式に加え、上記のネイティブ形式である candidates[].ticker と tickers[] も直接受け付けます。

決定論的な成果物を生成するには、以下にティッカーを指定してください。

python3 skills/kanchi-dividend-sop/scripts/build_sop_plan.py \
  --tickers "JNJ,PG,KO" \
  --output-dir reports/

Step 5 のエントリータイミング成果物用です。--yield-floor は必須です。これは Step 1 の利回りゲートです。指定しない場合、すべての行はフェイルセーフとして STEP1-RECHECK になり（Step 1 を通過せずに PASS ティアに到達する行はありません）、run_context 用の --profile／--safety-bias と、Step 4b のスキャン用の --events-json を指定します（省略時はすべての行が SKIPPED として扱われ、TRIGGERED の銘柄は HOLD-REVIEW に制限されます。問題がないものとして処理されることはありません）。

python3 skills/kanchi-dividend-sop/scripts/build_entry_signals.py \
  --tickers "JNJ,PG,KO" \
  --alpha-pp 0.5 \
  --yield-floor 3.0 \
  --profile balanced --safety-bias medium \
  --events-json reports/kanchi_events_2026-05-17.json \
  --output-dir reports/

ワークフロー

1）スクリーニング前に投資方針を定める

まず、パラメーターを集めて確定します。

• 目的：現在の現金収入か、配当成長か。
• 最大保有銘柄数と、1 銘柄あたりの保有上限。
• 対象とする金融商品：株式のみか、REIT／BDC／ETF も含めるか。
• 優先する口座種別：課税口座か、IRA に類する口座か。

references/default-thresholds.md を読み込み、ユーザーが変更を指定しない限り、基準設定を適用します。

2）投資対象ユニバースを構築する

品質を重視したユニバースから始めます。

• コア枠：配当成長が長期にわたる銘柄（例：Dividend Aristocrats 風の高品質銘柄群）。
• サテライト枠：利回りの高いセクター（公益事業、通信、REIT）を別のリスク枠に分けます。

ティッカー収集では、以下の優先順位を明示します。

1. skills/value-dividend-screener/scripts/screen_dividend_stocks.py の出力（FMP／FINVIZ）。
2. skills/dividend-growth-pullback-screener/scripts/screen_dividend_growth_rsi.py の出力。
3. API を利用できない場合は、ユーザー提供の証券会社エクスポートまたは手動のティッカーリスト。

先に進む前に、枠ごとに分類したティッカーリストを提示します。

3) Kanchi のステップ 1 を適用する（トラップフラグ付きの利回りフィルター）

主要ルール：

• ステップ 1 の利回り＝通常の配当利回り＝latest_declared_regular dividend × cadence-implied frequency / price（WS-1 dividend_basis.py）。 profile.lastDividend / TTM は、最新の増配の反映が遅れ（欠陥 D5）、臨時配当を 気付かないまま含めてしまうため（D4）、絶対に使用しないでください。
• プロファイルの下限（income-now 4.0% / balanced 3.0% / growth-first 1.5%）は、通常の利回りにのみ適用します。

トラップと鮮度の制御（dividend_basis.py が機械的に出力）：

• special_dividend_flag → 臨時配当を除外し、通常利回りと TTM 利回りを報告します。
• variable_policy_flag → FAIL（CALM 型。収入の基盤にはなりません）。
• cut_flag → FAIL、suspension_flag → FAIL。
• freeze_flag → HOLD-REVIEW（収入を生むキャッシュカウ例外は、安全性に問題がなく、阻害要因もない場合に限り、ステップ 8 の総合評価で判断します）。
• データ鮮度ゲート：通常利回りが下限の±0.20pp 以内（floor_borderline）で、最新の配当宣言が信頼できる情報源で確認されていない場合は、STEP1-RECHECK を出力します。決してハード FAIL にしてはいけません（CFR D5 の修正）。

4) Kanchi のステップ 2 を適用する（成長と安全性）— セクター別に振り分け

安全性はセクターごとに異なります。一律の GAAP/FCF の三点評価では、銀行（FCF に意味がない）や規制公益事業（FCF が構造的にマイナス）を誤って評価します。 references/sector-step2-modules.md を使用してください。決定論的な振り分けは scripts/payout_safety.py で行います。

• 配当性向の三点評価を必ず算出します：GAAP-EPS 配当性向、Adjusted-EPS 配当性向、FCF 配当性向。安全性の判定では、（消費者向けの場合は）Adjusted-EPS + FCF、または（銀行／公益事業／保険会社の場合は）セクターモジュールを使用します。
• adjusted_eps_source = UNAVAILABLE ⇒ HOLD-REVIEW を上限とします（フェイルセーフ。暗黙の PASS は決して出しません）。
• GAAP EPS と Adjusted EPS の乖離が 25% 超 ⇒ ステップ 4 の一過性要因フラグ。
• 4 四半期以内に完了した合併では、GAAP EPS が歪んでいると想定します ⇒ 調整後の評価経路を強制するか、HOLD-REVIEW にします（FITB/Comerica の典型例）。
• 規制公益事業：FCF のマイナスは自動的な FAIL ではありません。FFO／負債、認可 ROE、料金改定審査、および株式発行リスクに基づいて判断します。

傾向が混在していても悪化していない場合は、ハードな却下ではなく HOLD-REVIEW に分類します。

5) 米国のセクターマッピングを用いて Kanchi のステップ 3（バリュエーション）を適用する

references/valuation-and-one-off-checks.md を使用し、セクター固有のバリュエーションロジックを適用します。

• 金融：PER x PBR を引き続き主要指標として使用できます。
• REIT：単純な P/E の代わりに P/FFO または P/AFFO を使用します。
• アセットライト型セクター：予想 P/E、P/FCF、過去のレンジを組み合わせます。

各ティッカーについて、使用したバリュエーション手法を必ず報告してください。

6) Kanchi のステップ 4（一過性イベントフィルター）を適用する

最近の利益が一時的な要因に依存している銘柄は、却下するか、評価を引き下げます：

• 資産売却益、訴訟和解、税効果の急増。
• 売上傾向に裏付けられていない利益率の急上昇。
• 「一時的／非反復的」な調整の繰り返し。

監査可能性を保つため、各 FAIL の根拠を 1 行で記録します。

6b) Kanchi Step 4b（構造イベントの前方スキャン）を適用する

Step 4 は過去を振り返る手順です。Step 4b では、保留中または最近発生した構造イベントを検出します（MKC-Unilever の見落とし、D3）。候補として残った銘柄ごとに、情報源の優先順位に従って WebSearch と発行体の IR／SEC を確認します。発行体 IR → SEC 提出書類（8-K/10-Q/10-K/proxy/S-4）→ 取引所／企業のプレゼンテーション資料 → 信頼できる通信社 → 金融ポータル（二次情報のみ）。調査結果を厳選した events JSON に記録し、build_entry_signals.py --events-json を通じて渡します。

• 評価を HOLD-REVIEW に制限するのは、重大な構造イベントに限ります（取引規模が時価総額の 10% 超、株式発行が 10～20% 超、レバレッジが EBITDA 比で 0.5 倍増加、支配権／上場先／本社所在地の変更、対等合併／RMT／スピンオフ／大規模な資産売却、配当／格付け／レバレッジ方針の変更、セクター固有の重要性、または過去 24 か月の累積 M&A が時価総額の 15% 超）。小規模な追加買収は CAUTION の注記のみとします。
• 悲観的な上限設定：Step 5 で TRIGGERED となった銘柄の FAILED-DEGRADED／SKIPPED／NO_EVENT_FOUND ⇒ HOLD-REVIEW ＋ T1 BLOCKED。WebSearch が利用できない（ウェブアプリ／オフライン）場合も同様に扱います。黙ってスキップしてはいけません。CLEAN_CONFIRMED（一次情報源を確認済み）は NO_EVENT_FOUND（検索のみ）よりも信頼性が高いものとします。

7) Kanchi Step 5（ルールに基づく押し目買い）を適用する

エントリートリガーを機械的に設定します。

• 利回りトリガー：現在の利回りが 5 年平均利回りにアルファを加えた水準を上回る（デフォルトは +0.5pp）。
• バリュエーショントリガー：目標倍率に到達（P/E、P/FFO、または P/FCF）。

執行パターン：

• 注文を分割：40% -> 30% -> 30%。
• 注文前のブロッカー：候補に未解決の pre_order_blockers[]（WS-1/2/3 に由来するもの。変動／減配／停止、調整後 EPS が取得不可、GAAP／調整後の乖離、銀行の信用状況、公益事業の FFO／負債、イベントスキャンの失敗／スキップ、配当情報の古さなど）がある、または t1_blocked が true の場合、最初のトランシェはブロックするか、トラッキング用の 20% 以下のトランシェに縮小します。40% にはしません。
• セクター集中リスク：同一セクターの銘柄が SECTOR_CLUSTER_WARN_COUNT 以上合格した場合（例：多数の小規模銀行が同じマクロ要因へのベータを共有）、ポートフォリオ全体に CLUSTER-RISK 警告を出します。
• ブロックされていない買い増しの前に、「構造的な変化に対して投資仮説は維持されているか」という一文の健全性チェックを必須とします。

8) 標準化された出力を作成する

常に次のものを作成します。

1. 実行可能な評価ティアを含むスクリーニング表：CLEAN-PASS、PASS-CAUTION、CONDITIONAL-PASS、HOLD-REVIEW、STEP1-RECHECK、FAIL（Step 1 ＋ Step 2 ＋ Step 4b ＋ブロッカーをもとに verdict.py が統合）。各行に根拠を含めます。
2. 1 ページの銘柄メモ（references/stock-note-template.md を使用）。ティッカーごとの出所情報ブロック（価格／配当／配当性向／イベントの情報源、unresolved_blockers、evidence_refs[]）を含めます。
3. 分割サイズ、ブロッカー判定、無効化条件を含む指値注文計画。
4. 最上位の run_context（profile、yield_floor_pct、safety_bias、universe_source、excluded_asset_types）。これにより、3% 実行の結果が 4% 実行で黙って再利用されることを防ぎます。

出力

次のものを返すか、生成します。

1. SOP スクリーニング概要（Markdown）。
2. references/stock-note-template.md に基づく引受評価メモ一式。
3. skills/kanchi-dividend-sop/scripts/build_sop_plan.py が reports/ に生成する任意の計画成果物ファイル。
4. skills/kanchi-dividend-sop/scripts/build_entry_signals.py が reports/ に生成する任意の Step 5 エントリーシグナル成果物。

実施頻度

次の最低限の頻度で実施します。

• 毎週（15 分）：配当と事業ニュースの変化のみを確認します。
• 毎月（30 分）：スクリーニングを再実行し、注文水準を更新します。
• 四半期ごと（60 分）：最新の提出書類／決算を用いて安全性を詳細に確認します。

複数スキル間の引き継ぎ

まずこのスキルを実行し、その後、出力を次のスキルに引き継ぎます。

1. 日次／週次／四半期の異常検知は kanchi-dividend-review-monitor に引き継ぎます。
2. 口座の所在地と税務区分の計画は kanchi-dividend-us-tax-accounting に引き継ぎます。

ガードレール

• Step 4、Step 4b、安全性チェックを行わずに、根拠のない買い推奨を出さないでください。
• カバレッジの質を検証する前に、高利回りを割安と判断しないでください。
• Step 1には通常の予想利回りを使用し、特別配当やTTMを含む数値は使用しないでください。基準値付近で未確認の場合はFAILではなく、STEP1-RECHECKとします。
• TRIGGERED銘柄のイベントスキャンに失敗またはスキップした場合は、HOLD-REVIEWとし、T1をブロックします。Step 4bを黙ってスキップしないでください。
• 前提を明示してください。adjusted_epsやデータが欠落している場合は、安全側に倒してHOLD-REVIEWとし、黙ってPASSにしないでください。

リソース

• scripts/thresholds.py：すべてのSOPしきい値とSCHEMA_VERSION（下流のスキーマ変更ガード）の唯一の信頼できる情報源。
• scripts/dividend_basis.py：WS-1の通常配当／特別配当／変動配当／凍結／減配と、データ鮮度ゲートのエンジン（純粋、オフライン）。
• scripts/payout_safety.py：WS-2のセクター対応GAAP／調整後／FCF配当性向の三指標と、完了済み合併との紐付け。
• scripts/event_scanner.py：WS-3の独立した将来／直近の企業行動スキャナー、重要度ゲート、悲観的な上限。
• scripts/verdict.py：WS-5の実行可能なティアの統合、run_context、evidence_refヘルパー。
• scripts/build_entry_signals.py：オーケストレーター（Step 5の目標値とWS-1/2/3/5の統合）。フラグ：--yield-floor、--events-json、--profile、--safety-bias、--universe-source。
• scripts/build_sop_plan.py：決定論的なSOP計画のひな形ジェネレーター。
• scripts/tests/test_golden_p0.py：P0マージゲート — CALM/ORI/CMCSA/MKC/CFR/cutのエンドツーエンドの固定判定（scripts/run_all_tests.shで実行）。
• references/default-thresholds.md：人が読みやすい形式のしきい値一覧。
• references/sector-step2-modules.md：セクター別のStep 2安全性指標。
• references/valuation-and-one-off-checks.md：Step 3のバリュエーションとStep 4の一時的要因の確認。
• references/stock-note-template.md：1ページのメモと出典情報ブロック。

共通FMPクライアント

FMPデータへのアクセスには、同梱された生成済みのscripts/fmp_client.pyを使用します。既存のCLIキー／環境変数の優先順位、財務計算、成功時の出力形式は維持されます。移行後のパスでは安定版エンドポイントのみを使用します。安定版リクエストが拒否または失敗しても、廃止済みのv3 URLにはフォールバックしません。共通クライアントは生のキーとURLエンコードされたキーのエコーをマスクし、不正なJSONを1回再試行します。また、429の場合は60秒待って1回再試行し、レート制限が再発したら停止します。使用する場合も、FINVIZは引き続き別のクライアントを使用します。

Pythonクライアントでは、sleep_seconds、timeout、api_callsを維持します。Sleepはリクエスト間の最小間隔を設定するようになりました。リクエスト数の計上には、再試行されたHTTPレスポンスも含まれます。株価情報／プロフィールの取得は引き続き、1リクエストにつき1銘柄です。