Claude-Code

症状 GitHub Actions の self-hosted runner で claude --print を使った自動処理が突然動かなくなった。 claude CLI failed (rc=1): stdout=Auto mode is unavailable for your plan すべてのエージェント呼び出し（researcher, risk, portfolio optimizer）が同じエラーで失敗し、日次の投資提案が生成されなくなった。 ローカルで claude --print "hello" を実行すると正常に動作する。claude auth status でも Max プランで認証済みと表示される。 原因 2つの問題が重なっていた。 1. OAuth トークンの期限切れ（副次的問題） ワークフローで CLAUDE_CODE_OAUTH_TOKEN 環境変数に 期限切れの OAuth トークン を GitHub Secrets から渡していた。 1 2 3 4 # daily-proposal.yml - name: 日次投資提案を生成 env: CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} # ← 2月に設定したまま GitHub Secrets のトークンは静的で自動更新されない ローカルでは環境変数未設定のため、キーチェーンから有効なトークンが自動取得されて動作していた 2. Opus の auto mode 制限（真の原因） claude --print はデフォルトで auto mode（ツール自動承認）で動作する。Max プランで Opus モデルの auto mode が制限されたため、トークンが有効でも Opus では --print が使えなくなっていた。 ...

Claude Code の auto モードでブログ記事作成を完全自動化しようとしたところ、.claude/ ディレクトリ配下のファイルへの書き込みで毎回同意を求められる問題に遭遇しました。原因と対処法を記録します。 問題：.claude/ 配下は sensitive file 扱い Claude Code には、.claude/ ディレクトリ内のファイルを「sensitive file」（設定やスキル定義など、ツールの動作に影響する重要ファイル）として扱う組み込みのセキュリティチェックがあります。settings.local.json の permissions.allow に Write/Edit の許可パターンを追加しても回避できません。sensitive file チェックは permissions とは別レイヤーで動作するためです。 実際に発生したメッセージ: Claude requested permissions to edit .claude/temp/pr_body.md which is a sensitive file. 背景：ブログ記事作成の自動化ワークフロー このブログでは /blog スキルで記事作成から PR 作成まで自動化しています。ワークフローの概要: git worktree を作成してブランチを切る worktree 内に記事ファイルを作成 Hugo ビルド確認 コミット・プッシュ PR 本文ファイルを書き出し、gh pr create --body-file で PR 作成 ソース元に PR リンクを追記 問題が起きたのはステップ 5 です。PR 本文ファイル（pr_body.md）を .claude/temp/ に Write ツールで書き込もうとすると、sensitive file チェックに引っかかります。 ...

2026年3月31日、Anthropic の Claude Code でソースコード漏洩インシデントが発生しました。npm レジストリに含まれたソースマップファイル（.map）を通じて、ソースコード全体が公開された形です。 何が起きたのか セキュリティ研究者の Chaofan Shou 氏が、@anthropic-ai/claude-code パッケージのバージョン 2.1.88 に、本来デバッグ用の 59.8MB のソースマップファイルが含まれていることを発見しました。このソースマップには、Anthropic の Cloudflare R2 ストレージバケット上の zip アーカイブへの参照が含まれていました。そこから完全な TypeScript ソースコードを復元できる状態だったのです。 数時間以内に、約 512,000 行・約 1,900 ファイルの TypeScript コードベースが GitHub にミラーされ、多数の開発者によって分析が行われました。 ソースマップとは ソースマップ（.map ファイル）は、ミニファイ（コードの圧縮・難読化）やバンドルされた JavaScript を元のソースコードにマッピングするためのファイルです。開発時のデバッグを容易にする目的で生成されますが、プロダクションビルドに含めると、元のソースコード全体が読み取り可能な形で公開されてしまいます。 なぜ漏洩したのか Claude Code は Bun をランタイムおよびバンドラーとして使用しています。ビルド設定でソースマップ生成が有効化されていました。しかし、.npmignore や package.json の files フィールドで .map ファイルを除外する設定が漏れていたことが原因です。公開された npm パッケージには cli.js.map が含まれ、その sourcesContent フィールドにバンドル対象の全 .ts / .tsx ファイルがそのまま格納されていました。 ソフトウェアエンジニアの Gabriel Anhaia 氏は次のように指摘しています。「.npmignore や package.json の files フィールドの設定ミス一つで、すべてが公開されてしまう」 ...

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 では公式サイトのインストーラーも利用可能: ...

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組織もまったく同じ構造。 エージェントには視野がない ここが核心。 ...

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でクローンした実際のパスに置き換えること。 ...

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

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