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

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

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 にフィードバック ○ 現状では難しい部分 一方で、以下の部分には大きなハードルがあります: ...