AI/LLM

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 はスマートフォンなどのエッジデバイスでの動作も想定した設計としています。 ...

Supabase とは Supabase は Firebase のオープンソース代替 として急成長している BaaS（Backend as a Service）だ。PostgreSQL をベースに、認証・リアルタイムデータベース・ストレージ・Edge Functions をワンストップで提供する。 PostgreSQL がそのまま使える — 独自のクエリ言語ではなく標準 SQL Row Level Security (RLS) — テーブル単位でアクセス制御ポリシーを定義 自動生成 REST API — テーブル定義から即座に CRUD API が生成される オープンソース — セルフホスティングも可能 無料枠あり — 個人プロジェクトなら無料で始められる Firebase との最大の違いは「中身が PostgreSQL」である点だ。NoSQL ではなく RDB なので、既存の SQL 知識がそのまま活かせる。 Supabase を使っているプロジェクトで Claude Code を活用している場合、公式の supabase/agent-skills をインストールするだけでコード品質とパフォーマンスが大幅に向上する。特に Row Level Security (RLS) の書き方ミスを防ぐ効果が高い。 なぜ agent-skills が必要なのか Claude Code は Supabase の細かいベストプラクティスをデフォルトでは把握していない。たとえば RLS ポリシーで頻出する次のパターンを考えてほしい。 1 2 3 4 5 6 7 -- ❌ Claude がデフォルトで書きがちなコード create policy "users can view own records" on public.records for select using (auth.uid() = user_id); -- ✅ パフォーマンスを考慮した正しい書き方 create policy "users can view own records" on public.records for select using ((select auth.uid()) = user_id); auth.uid() をそのまま使うとクエリの行ごとに関数が評価されるが、(select auth.uid() as uid) のようにサブクエリ化することでクエリプランナーが一度だけ評価するよう最適化できる。これによってテーブルスキャン時のパフォーマンスが大幅に改善する。 ...

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

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」を公開した。 ...

「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 ではいずれも使わなければ存在しないのと同じであり、強制されるものではない。 ...

業務管理システム（PHP/Laravel 6.20）を Python/Django 4.2 に移行するプロジェクトを、Claude Code の自律実行でほぼ全自動で完遂しました。 移行元: Laravel 6.20 / PHP 8.0 / MySQL 5.7 / Blade テンプレート 移行先: Django 4.2 LTS / Python 3.11+ / MySQL 8.0 / Django Templates 所要時間: 約 5.5 時間（準備フェーズ除く） 成果物: 17 モデル / 50+ テンプレート / 199 テスト / 15,000 行の Python コード 本記事は 3 部構成です。 計画編（本記事）— なぜやったか、どう計画したか 自動化基盤編 — Claude Code を自律実行させるフレームワークの設計 実行結果・教訓編 — 実際に何が起きたか、次回への教訓 プロジェクトの背景 移行対象は、ある業種特化の業務管理システムです。契約管理・マスタ管理・CSV インポート・Excel エクスポート・月次締処理・外部サービス連携（OAuth2 / REST / GraphQL）など、典型的な業務アプリの機能を一通り備えています。 ...