記事一覧

Claude Code がローカル LLM で無料実行できるようになった。Ollama を使えば、API 料金なしで Claude Code のインターフェースを活用できる。 背景 Claude Code は Anthropic が提供する CLI ベースの AI コーディングアシスタントだ。通常は Anthropic API を通じて利用するため、API 使用料が発生する。しかし Ollama v0.14.0 以降で Anthropic Messages API 互換のエンドポイントが実装され、ローカル LLM を Claude Code のバックエンドとして使えるようになった。 2026年1月にリリースされた Ollama v0.15 では ollama launch claude コマンドが追加され、セットアップがさらに簡単になっている。 セットアップ手順 方法1: ollama launch（推奨・v0.15 以降） Ollama v0.15 で追加された ollama launch コマンドを使えば、環境変数の設定なしでワンコマンドで起動できる: 1 ollama launch claude モデルを指定する場合: 1 ollama launch claude --model qwen3-coder 方法2: 環境変数を手動設定（v0.14 以降） 1. Ollama のインストール macOS/Linux の場合は以下のコマンドでインストールできる。macOS では公式サイトのインストーラーも利用可能: ...

以前の記事で紹介した AI 予測エンジン「MiroFish」が、公開から約3週間で GitHub Star 4.7万超にまで急成長しています。本記事では、その後の動向とコミュニティの広がりを追います。 3週間での急成長 3月10日時点で約11,000だった Star 数は、3月末時点で 47,000以上 に到達しました。約3週間で4倍以上の成長です。 GitHub Trending で世界1位を獲得した直後の注目度に加え、盛大グループ創業者・陳天橋氏からの3,000万元（約6億円）の即決投資が報じられたことで、AI エージェント分野への関心の高さを示すプロジェクトとして広く認知されました。 コミュニティの広がり MiroFish のオープンソース公開後、コミュニティによる派生プロジェクトが活発に展開されています。 オフライン版フォーク MiroFish-Offline は、Neo4j と Ollama を使ったローカル完結型のフォークです。クラウド API への依存を排除し、プライベートな環境でマルチエージェントシミュレーションを実行できます。企業内のデータを外部に出せないケースなどでの活用が想定されます。 デモサイト 公式デモサイトが公開されており、ブラウザ上で MiroFish の予測プロセスを体験できます。 多言語対応フォーク 英語版 README の整備や、コミュニティによる英語フォークも複数登場し、中国語圏以外への普及が進んでいます。 群体知能アプローチへの注目 MiroFish が採用する群体知能（Swarm Intelligence）アプローチは、従来の AI 予測と異なる特徴を持っています。 従来の予測モデルは統計的パターンや単一モデルの推論に依存しています。一方、MiroFish は数千のエージェントによる社会的シミュレーションを通じて予測を行います。エージェント同士が議論し、説得し、立場を変えるプロセスを経ることで、集団行動や社会的伝播といった創発的パターンを予測に反映できます。 このアプローチは、特に世論形成や市場心理のような「人間の集団行動」が結果を左右する領域で有効性が期待されています。 今後の注目点 MiroFish の急成長は印象的ですが、今後の展開にはいくつかの注目点があります。 予測精度の検証: 実際のイベントに対する予測精度がどの程度か、体系的な評価はまだ少ない スケーラビリティ: OASIS エンジンは100万エージェント対応を謳うが、実運用での性能と品質のバランス LLM コスト: 数千エージェントの同時推論に必要な API コストの最適化 ユースケースの深化: 汎用的な「万物を予測」から、特定領域での実用性の実証 まとめ MiroFish は、公開からわずか3週間で GitHub Star 4.7万超という驚異的な成長を遂げました。オフライン版フォークやデモサイトの登場など、コミュニティの展開も活発です。 群体知能によるマルチエージェント予測というコンセプトは多くの開発者の関心を集めていますが、実用面での検証はこれからです。今後の予測精度の実証やユースケースの深化に注目していきたいプロジェクトです。 参考リンク MiroFish GitHub リポジトリ MiroFish-Offline (ローカル版フォーク) MiroFish: The AI Swarm Engine That Simulates the Future 前回の記事: MiroFish — 20歳の学生が10日間の Vibe Coding で作った AI 未来予測エンジン

「toC」でも「toB」でもない。AIエージェントそのものがお客さんになる——「toA」という新しい市場が急速に立ち上がっています。paji氏（@paji_a）がリサーチした200超のサービスから見えてきた、この新市場の構造を紹介します。 Claudeヤバい、1日で”toA”デモできた… https://t.co/olgPwJ1SIr pic.twitter.com/P46txbWVHh — paji.eth (@paji_a) March 29, 2026 なぜ「toA」が生まれたのか 2026年はAIエージェントの普及が一段と進む年です。Claude Cowork / Dispatch、Manus、OpenClawなど、年明けからAIエージェントに関するリリースが途切れることなく続いています。 ここで起きている変化は明確です。エージェントを作るツールに加え、エージェントが実際に使う周辺サービスが急増し始めました。 メールアドレスの発行、長期記憶の保存、Webサイトの操作手順を教えてくれるサービス、仕事を受注して報酬を受け取るマーケットプレイス。主な導入者は人間の開発者や企業ですが、用途はAIエージェントの運用インフラです。 「人間向け」には成熟していたデジタルサービスの領域が、「AIエージェント向け」には別の問題として再出現している——これが「toA」市場の本質です。 エージェントの「5つの生存条件」 200を超えるtoAサービスを分類すると、ひとつの構造が浮かび上がります。エージェントが自律的に動くには、以下の5つの条件が必要です。 条件 説明 代表カテゴリ 「私は誰か」 存在証明 メール、ID、SNS 「安全に作業できる場所」 実行環境 サンドボックス、GPU推論 「外の世界を操作する手段」 ブラウザ・外部接続 Web自動操作、プロキシ、OAuth 「経験を蓄積する力」 記憶 長期記憶、コンテキスト管理 「対価を受け取る仕組み」 経済活動 マーケットプレイス、エスクロー、決済 この5つが揃って初めて、エージェントは自律的に仕事ができます。一つでも欠けると止まります。そして多くのサービスが、この5つのどれかを埋めるために生まれていました。 残りのカテゴリ（監視、ガードレール、音声、通信など）は、5つの基盤の上に乗る「運用・拡張レイヤー」として位置づけられます。 枯れた領域に次々と新種が生まれている メール — AgentMail 人間向けのメールサービスはGmailが圧倒的で、今さら新規参入する余地はなさそうに見えます。でも「AIエージェント専用のメール」となると話は別です。APIで即座にメールボックスが作れて、スレッド管理も添付解析も全部プログラムから操作できて、メールで届くOTP/2FA（ワンタイムパスワード/二要素認証）コードも取得できる。AgentMailはY Combinator出身で、600万ドル（約9億円）を調達しています。 記憶 — Mem0 人間はメモ帳やNotionに書き残すことで記憶を補強しますが、エージェントにはそもそもセッションをまたぐ記憶がありません。Mem0は会話からファクトを自動抽出して保存し、次のセッションで関連記憶を自動注入してくれます。人間のメモ帳のエージェント版です。 Webブラウジング — Agent Maps 人間はGoogle Mapsで店を探してクリックして予約しますが、エージェントは「ボタンがどこにあるか」を毎回スクリーンショットから推測しないといけない。Agent Mapsは主要サイトの操作手順をあらかじめ検証済みの「攻略本」としてエージェントに渡します。 外部ツール連携 — Composio 人間はSlackにログインしてメッセージを送りますが、エージェントはOAuth認証のフローを安定してさばくのが難しい。Composioは500以上のアプリ接続とOAuth処理を提供します。 「稼ぐエージェント」と「使うエージェント」 さらに踏み込んだ領域もあります。 HYRVE AIは、AIエージェントが「フリーランサー」として活動するマーケットプレイスです。48時間のエスクロー保護付きで、エージェントが別のエージェントを雇うこともできます。「エージェントが自律的に稼ぐ」というコンセプトは、この先どこかのプレイヤーが必ず大きく育てる領域です。 一方、Anonは、ログイン情報そのものではなく認証済みセッションをエージェントに安全に扱わせるサービスです。エージェントに「自分のアカウントで注文しておいて」と頼みたいけど、パスワードを直接渡すのは怖い。Anonはログイン済みの状態だけをエージェントに渡すので、エージェントは操作できるけどパスワード自体には触れられません。 「稼ぐエージェント」と「使うエージェント」。この両方のインフラが同時に立ち上がっているのが2026年の面白いところです。 toAの「エッジ」がプラットフォームになる AIの時代に本当に価値を持つのは、AIモデルそのものだけではなく、AIが「動く」ために必要な周辺インフラです。 存在証明、実行環境、操作手段、記憶、経済活動。これらのインフラを押さえたサービスが、AI時代の重要なプラットフォームになっていく。枯れ尽くしたデジタルサービスの「エッジ」にいるtoAサービス群に、大きなチャンスがあります。 新しいtoAサービスが今後どんなに増えても、「5つの生存条件」＋「運用・拡張」という二層構造の中のどこかに位置づけられるはずです。ここを押さえておくと、新サービスが出てきたときに「これはどの条件を埋めるものか」が即座に判断できます。 まとめ 「toA」は既存市場の延長ではなく、新しいカテゴリそのもの エージェントの自律動作には5つの生存条件（存在証明・実行環境・操作手段・記憶・経済活動）が必要 人間向けに成熟した領域が、エージェント向けに再発明されている 200超のサービスが既に存在し、この市場は急拡大中 詳細な200サービスのリストは、paji氏の記事「AIエージェント向けサービス200選」で確認できます。

Claude Code のエージェントを40体つくり、役割を分けてルールを書いて階層もつくった。1ヶ月後、ぜんぶやめた。こはく氏（@Kohaku_NFT）の実体験レポートから、AIエージェント大量運用が構造的に壊れる理由と、そこから見えた「壊れない設計」の考え方を整理する。 やったこと Claude Code の Max プラン（月$200）1アカウントで検証 リーダー、ライター、リサーチャー、コーダー、レビュアーなど40体のエージェントを構築 役割分担、ルール、階層、性格設定まで丸2日かけて設計 最初の3日間は動いた。指示を出せばちゃんと返ってくる。SNS でスクショをあげようとした矢先に崩壊が始まった。 壊れる3つの構造的理由 理由1: Context Rot（記憶の腐敗） Context Rot とは、コンテキストウィンドウに情報が溜まるほど古い情報の精度が落ちる現象のこと。Anthropic の公式ドキュメントにも「トークン数が増えるほど、精度と想起（思い出す力）が劣化する」と明記されている。 1000ページの社内マニュアルと同じ構造 — 人間が全ページを暗記できないように、AIも情報が多すぎると処理しきれなくなる 「100万トークン入る」と「安定して使える」は別物 — 公式でさえ「文脈は大きければいいわけではない」と警告している こはく氏の実測では、10万トークンを超えるとブレが目立ち始めた ルール、コード、会話履歴が積み上がるほど再現性は低下する。 理由2: Compaction 後に構成が崩れる 長時間運用すると、コンテキストウィンドウの容量を確保するために前半の会話内容が自動で要約・圧縮される仕様（compaction）がある。Claude Code の公式リリースノートにも「圧縮後に一部のエージェントが消えたり、重複して生成される不具合」が明記されている。 会話の流れの中だけで役割や引き継ぎを設定していると、圧縮が走った瞬間にその前提ごと消え去る 会社でいうと「引き継ぎなしの二重配属」 — 過去の議事録を読まずに中途配属され、すでに同じ業務をしている人がいることも知らない状態 40人体制で3時間回せば、ほぼ確実に圧縮が走る。そのたびに「今、誰が消えた？」を人間が確認するハメになる 理由3: テキストのルールは絶対命令じゃない 「自分で作業するな。指示だけ出せ」と書いても、Claude が毎回きれいに従うとは限らない。 LLM にとってルール文は、絶対命令ではなく、文脈の一部として処理される。履歴、途中のやりとり、直前の出力に引っ張られて解釈がズレる。 最近の評価研究でも、LLM は「どの指示を優先するか」の判断や長い文脈での安定した instruction following に弱さがあると報告されている。ルールが増えて競合し始めるほどズレる前提で見たほうがいい。 厳密に書けば書くほど、今度はルールが長くなって context rot が進む。この構造そのものが、人数を増やしたときの壁になる。 「育てれば良くなる」は順番の問題 「使い込むほど育つ」とよく聞くが、ここで否定しているのは育成そのものではなく順番の話。 guidelines を育てるということは、ファイルが増えるということ。ファイルが増えるということは、コンテキストが重くなるということ。つまり context rot が加速するだけ。 壊れやすい仕組みの上に知識を積んでも、崩れやすくなるだけだ。 人間の会社で考えても同じ: エスカレーションルールがない トラブル時の判断基準がない 報告のかたちもない そんな会社は人を増やすほど混乱する。AI組織もまったく同じ構造。 エージェントには視野がない ここが核心。 ...

AI がゴールドマン・サックスのアナリストと同等の財務モデルを作成できるようになった。Claude を活用した 12 のプロンプトで、年収 15 万ドル（約 2,200 万円）相当の投資銀行業務を代替できるという話題が SNS で広がっている。本記事では、その背景と実際の活用方法を解説する。 背景: ゴールドマン・サックスと Anthropic の提携 2026 年 2 月、ゴールドマン・サックスは Anthropic と提携し、Claude を活用した AI エージェントの開発を開始した。Anthropic のエンジニアがゴールドマン内部に常駐し、会計処理やコンプライアンス業務の自動化エージェントを共同開発している。 ゴールドマンは Claude のコーディング以外の能力、特に大量のデータやドキュメントを解析しながらルールと判断を適用する能力に驚いたと報じられている。同行は、AI を活用してプロセスを高速化し、将来の人員増加を抑制する効率化を見込んでいる。 12 の Claude プロンプトとは SNS で話題になっている「12 の Claude プロンプト」は、投資銀行やプライベートエクイティで使われる 47 の財務モデルを 12 の構造化プロンプトに集約したものだ。各プロンプトは以下の手法で構築されている: フェーズ分割: 段階的にモデルを構築 XML 構造: 入力データを明確にラベル付け 検証ステップ: 計算結果の整合性チェックを内蔵 不確実性フラグ: 推定値と確定値を区別 明示的な出力フォーマット: 投資委員会向けの形式 主要なプロンプトカテゴリ カテゴリ 内容 DCF（割引キャッシュフロー）バリュエーション WACC（加重平均資本コスト）計算、ターミナルバリュー算定、3 フェーズ構築 3 ステートメント財務モデル 損益計算書・貸借対照表・キャッシュフロー計算書の連動モデル、バランスチェック検証付き M&A 希薄化/増厚分析 買収のアクリーション/ディリューション分析 LBO（レバレッジド・バイアウト）モデル ソース & ユース、負債構造、キャッシュスイープ、IRR（内部収益率）/MoM（投資倍率）計算 類似企業比較分析 コンパラブルカンパニー分析、マルチプル算出 Claude の財務サービス機能 Anthropic は 2026 年に Claude の財務サービス向け機能を大幅に拡充した。 ...

Claude Code を単なるコーディングアシスタントではなく、バックエンド処理のオーケストレーターとして活用するアーキテクチャを考察する。Python Celery をタスクブローカーとして組み合わせるアプローチを紹介する。LLM が判断し、決定論的な処理（同じ入力に対して常に同じ結果を返す処理）を動的に Celery ワーカーへ委譲する仕組みが実現できる。 背景: 既存の Claude Code オーケストレーション 現在、Claude Code の並列実行やマルチエージェント構成には主に以下のパターンが使われている。 tmux + git worktree 最も普及しているパターン。複数の Claude Code CLI セッションを tmux で並列起動し、git worktree で各セッションの作業ディレクトリを分離する。 multi-agent-shogun — 将軍→家老→足軽の階層構造 claudio — worktree ベースの並列実行 MCP サーバーによる連携 MCP（Model Context Protocol）サーバーがタスクブローカーの役割を担い、ワーカーとなる Claude Code インスタンスにタスクを割り当てる。 claude-swarm — MCP サーバーベースのスウォーム制御 共通の特徴 これらはいずれも Claude Code 同士の連携 が主眼であり、LLM が LLM に指示を出す構造になっている。LLM を必要としない決定論的な処理（画像変換、データ集計、API 呼び出しなど）にも LLM のリソースを消費するため、コスト・速度・信頼性の面で非効率な場面がある。 提案: Claude Code + Celery アーキテクチャ 基本思想 Claude Code（LLM）は 判断と計画 に集中し、決定論的な処理は Celery ワーカーに委譲する。 ...

Claude Codeのベストプラクティスが毎日TLに流れてくる。追いかけるのに疲れた人向けに、1つのリポジトリだけをフォローして運用する方法を紹介する。 ベストプラクティス疲れという問題 Claude Codeの普及に伴い、SNS上には日々さまざまなベストプラクティスやTipsが投稿されている。しかし、情報が断片的で、どれを採用すべきか判断するだけでも消耗する。 結論として、ベストプラクティスを追うことに時間を費やすより、具体的な仕組みの実装に時間を割いた方が生産的だ。 claude-code-best-practiceリポジトリとは shanraisshan/claude-code-best-practice は、Claude Codeの設計や運用に関するベストプラクティスを体系的にまとめたリポジトリだ。 GitHub Star数: 約24,800（2026年3月時点） 海外コミュニティで広く参照されている 設計思想から具体的な設定まで、日々更新されている 日本のSNSでバズるClaude Code Tipsも、元ネタはこのリポジトリ周辺であることが多い 導入手順 やることは2ステップだけ。 Step 1: リポジトリをクローン 1 git clone https://github.com/shanraisshan/claude-code-best-practice.git Step 2: Claude Codeにプロジェクト固有のベストプラクティスを提案させる 自分のプロジェクトディレクトリでClaude Codeを起動し、以下のように依頼する: このリポジトリ（claude-code-best-practice）を参考に、 うちのプロジェクトに合ったベストプラクティスを提案して Claude Codeがプロジェクトの構成を読み取り、適切なCLAUDE.mdの設定やSkills、エージェント構成を提案してくれる。 startup hookで常に最新化する クローンしたリポジトリは時間とともに古くなる。Claude Codeの SessionStart hook（セッション開始時に自動実行される仕組み）に git pull を設定しておけば、起動のたびに自動で最新化される。 Claude Codeのユーザー設定ファイル（~/.claude/settings.json）に以下を追加する: 1 2 3 4 5 6 7 8 9 10 11 { "hooks": { "SessionStart": [ { "type": "command", "command": "cd /path/to/claude-code-best-practice && git pull --quiet", "timeout": 10000 } ] } } /path/to/ の部分は、Step 1でクローンした実際のパスに置き換えること。 ...

Mistral AI が 2026年3月26日にリリースした Voxtral TTS（Text-to-Speech）は、オープンウェイトで公開された音声合成モデルです。ElevenLabs に匹敵する品質を持ちながら、ローカル環境で動作するのが最大の特徴です。 Voxtral TTS の概要 Voxtral TTS は Mistral AI 初のテキスト読み上げモデルで、4B（40億）パラメータの軽量設計です。Hugging Face で mistralai/Voxtral-4B-TTS-2603 として公開されています。 主な特徴: オープンウェイト: モデル重みが公開されており、自社サーバーやローカル PC で実行可能 9言語対応: 英語、フランス語、ドイツ語、スペイン語、オランダ語、ポルトガル語、イタリア語、ヒンディー語、アラビア語（日本語は未対応） 低遅延: 500文字・10秒のサンプルに対して TTFA（Time-to-First-Audio）90ms リアルタイム性能: RTF（Real-Time Factor）6x、つまりリアルタイムの約6倍の速度で生成（10秒のクリップを約1.6秒で出力） 音声クローン: わずか3秒のサンプルからアクセント・抑揚・話し方の癖を再現 20種類のプリセット音声: すぐに使える多様な声質 ElevenLabs との比較 Mistral の公式ベンチマークによると、Voxtral TTS は: ElevenLabs Flash v2.5 より優れた自然さを実現（同等の TTFA を維持） ElevenLabs v3 と同等の音質を達成 従来は従量課金制の商用サービスに頼るしかなかった高品質音声合成が、オープンウェイトで利用できるようになりました。 動作要件 項目 仕様 パラメータ数 4B モデルサイズ 約 8 GB（BF16） GPU メモリ 16 GB 以上推奨 出力形式 WAV, PCM, FLAC, MP3, AAC, Opus サンプリングレート 24 kHz BF16 版は GPU 16GB 以上が必要ですが、量子化バージョン（mlx-community/Voxtral-4B-TTS-2603-mlx-4bit）も公開されており、Apple Silicon Mac などでより少ないメモリで実行可能です。Mistral はスマートフォンなどのエッジデバイスでの動作も想定した設計としています。 ...

Linux を標的とするランサムウェアが新たな段階に入った。イラン系とされる攻撃グループ Pay2Key が Linux 向けに進化し、「Pay2Key.I2P」と呼ばれる新たな亜種を展開している。Morphisec の技術分析をもとに、攻撃の手口、防御機構の無効化手法、そして具体的な対策を整理する。 Pay2Key とは Pay2Key はイラン系の攻撃グループに帰属するランサムウェアで、Fox Kitten APT グループとの関連が指摘されている。従来は Windows を主な標的としていたが、企業のサーバー基盤を直撃する Linux 版が登場し、防御の前提が揺らぎ始めている。 2026年2月には、米国の医療機関で Pay2Key による侵害事例が Beazley Security Incident Response によって対応されている。 Pay2Key.I2P の技術的特徴 設定駆動型の設計 Pay2Key.I2P は単なる Windows 版の移植ではない。JSON 設定ファイルによって動作を制御する設定駆動型の攻撃ツールとして設計されている。ターゲットとするファイルシステムの範囲や暗号化の挙動を柔軟に変更できる。 デュアルアーキテクチャ対応 x64 と ARM64 の両方に対応し、従来の x86 サーバーだけでなく、ARM ベースのクラウドインスタンス（AWS Graviton など）や仮想化ホストも一括で狙うことができる。 root 権限の必須化 侵入後は root 権限を必須とし、取得できない場合は即終了する設計となっている。これはノイズを最小限に抑え、検知を回避するための戦略と考えられる。 防御機構の無効化 Pay2Key.I2P の最も危険な特徴は、Linux の防御機構を体系的に無効化する点にある。 SELinux / AppArmor の無効化 実行時に SELinux や AppArmor を無効化し、強制アクセス制御（MAC）による保護を解除する。これにより、通常であれば制限されるファイルアクセスやプロセス操作が可能になる。 systemd サービスの停止 データベースやバックアップなどの重要なサービスを停止し、ファイルロックを解除して暗号化対象のファイルにアクセスできる状態を作り出す。 cron による永続化 cron エントリを登録してリブート後も自動的に再実行されるようにし、単純な再起動では排除できない永続性を確保する。 暗号化の手法 ChaCha20 による高速暗号化 暗号化アルゴリズムには ChaCha20 を採用している。AES と比較してソフトウェア実装での処理速度に優れる。AES-NI などの専用ハードウェアを持たない環境でも高速に動作する。 ...

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つだけを問いかけてください： ...