Claude-Code

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

業務管理システム（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）など、典型的な業務アプリの機能を一通り備えています。 ...

前回の計画編では、移行の方針とフェーズ設計を紹介しました。本記事では、計画を実際に自律実行するためのフレームワーク設計を解説します。 全体アーキテクチャ 自律移行の仕組みは、大きく 3 つのレイヤーで構成されています。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ┌─────────────────────────────────────────────────────┐ │ オーケストレーション層: run-issue.sh │ │ - Issue 読み込み → ブランチ作成 → Claude 起動 │ │ - リトライ → Push → PR 作成 → マージ → Issue 閉じ │ └──────────────────┬──────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ 実行層: Claude Code (claude -p) │ │ - ソースコード調査 → 設計 → 実装 → テスト │ │ - コミット（push はしない） │ │ - サブエージェント: explorer / architect / reviewer│ └──────────────────┬──────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ 品質保証層: Hooks + CI + verify-phase.sh │ │ - Pre-commit: ruff format + check │ │ - PostToolUse: 編集時の即座リント │ │ - CI: lint → Django check → pytest │ │ - Phase 検証: ファイル存在 + 機能チェック │ └─────────────────────────────────────────────────────┘ 責務分離の原則 最も重要な設計原則は、ワークフロー制御と実装作業の責務分離です。 ...

計画編で方針を、自動化基盤編でフレームワークを紹介しました。最終回では、実際に 15 Issue を自律実行した結果と、得られた教訓を共有します。 実行結果サマリー タイムライン 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 12:06 ── Phase 0: 初期セットアップ ────── 12分 (リトライ1回) 12:18 ── Phase 1-1: マスタモデル ──────── 14分 (リトライ1回) 12:33 ── Phase 1-2: 契約モデル ──────── 12分 12:45 ── Phase 1-3: 入金・会計モデル ──── 9分 12:57 ── Phase 2: 認証 & API ────────── 12分 (リトライ1回) 13:09 ── Phase 3-1: テンプレート ──────── 16分 (リトライ2回) 13:25 ── Phase 3-2: マスタ CRUD ────── 21分 13:46 ── Phase 4-1: 契約検索 ──────── 12分 13:58 ── Phase 4-2: 契約 CRUD ──────── 16分 14:14 ── Phase 4-3: 支払・入金 ──────── 21分 (リトライ1回) 14:35 ── Phase 5-1: CSV インポート ──── 24分 (リトライ1回) 14:59 ── Phase 5-2: Excel エクスポート ── 24分 (リトライ1回) 15:00 ── Phase 6: 月次締処理 ──────── 10分 15:34 ── Phase 7: テスト ──────────── 20分 (リトライ2回) 15:54 ── Phase 8: デプロイ準備 ──────── 8分 合計: 約 5.5 時間 数値で見る結果 項目 数値 完了 Issue 15 / 15 総コミット 84 うち修正コミット (fix:) 16 (19%) リトライ発生 Issue 8 / 15 (53%) 最大リトライ回数 2 回 Python コード行数 約 15,000 行 テンプレート 50+ ファイル テスト数 199 テスト通過率 100% 1 Issue あたり平均時間 15〜25 分 うまくいったこと 1. inspectdb による正確なモデル定義 既存 DB ダンプから inspectdb でモデル雛形を生成し、それを整理する方式は非常に効果的でした。カラム名・型・制約が実 DB と完全一致するため、「モデル定義を書いたが DB と合わない」問題が発生しませんでした。 ...

AGI（Artificial General Intelligence、汎用人工知能）とは、特定のタスクに限定されず、人間のように幅広い知的作業をこなせる AI を指す概念だ。現在の AI は特定領域で高い能力を発揮するが、未知の領域への汎用的な対応力では人間に及ばないとされている。 Claude Code に auto mode が導入された。パーミッションの承認を Claude 自身が判断するこの機能について、「次に来るのは Claude 実行自体の auto mode、つまり AGI だ」という指摘が注目を集めている。開発ツールの自律性の進化と、その先にある可能性を考える。 Auto Mode の本質 2026年3月、Anthropic は Claude Code に auto mode を導入した。公式 X アカウントの発表によると: New in Claude Code: auto mode. Instead of approving every file write and bash command, or skipping permissions entirely, auto mode lets Claude make permission decisions on your behalf. Safeguards check each action before it runs. ...

AWS が「Agent Plugins for AWS」を公開しました。AI コーディングエージェント（Claude Code や Cursor など）に、AWS のアーキテクチャ設計からデプロイ実行までの能力を組み込むオープンソースのプラグインライブラリです。 Agent Plugins for AWS とは Agent Plugins for AWS は、AWS Labs が開発・公開したオープンソースプロジェクトです。コスト見積もり、Infrastructure as Code（IaC）の生成、デプロイといった AWS 固有のスキルセットを AI エージェントに追加できます。 プラグインは以下の要素で構成されています: Agent Skills: 複雑なタスクをステップバイステップで実行するワークフロー。デプロイやアーキテクチャ設計のベストプラクティスを手順として組み込んだもの MCP サーバー: 外部サービス、ドキュメント、料金データなどへのリアルタイム接続 Hooks: 開発者のアクションに対するバリデーションやガードレール deploy-on-aws プラグイン 現時点で提供されている主要プラグインが deploy-on-aws です。「deploy to AWS」と指示するだけで、以下の 5 ステップを自動実行します: コードベースの分析: アプリケーションの構成・依存関係を解析 AWS サービスの推奨: 最適な AWS サービスを理由付きで提案 コスト見積もり: 推奨構成の月額コストを試算 IaC の生成: CDK または CloudFormation でインフラコードを生成 デプロイ実行: ユーザーの確認後にデプロイ AWS によると、従来は数時間かかっていたデプロイフローが約 10 分で完了するとのことです。 Claude Code へのインストール Claude Code では、プラグインマーケットプレイス経由でインストールします: ...

Claude Code で長時間タスクを実行する際、許可プロンプトを回避するために --dangerously-skip-permissions を使っていた開発者は少なくないだろう。しかし、auto mode の登場により、安全性を保ちながら同様の利便性を得られるようになった。この記事では、両者の違いと auto mode への移行方法を解説する。 dangerously-skip-permissions の問題 claude --dangerously-skip-permissions は、すべての権限チェックを無効化するフラグだ。ファイルの書き込み、シェルコマンドの実行、外部通信など、あらゆる操作が無条件で許可される。 このフラグには以下のリスクがある: プロンプトインジェクション: 悪意あるファイルを読み込んだ場合、任意のコマンドが無条件で実行される 意図しない破壊操作: rm -rf のような危険なコマンドもチェックなしで実行される 認証情報の漏洩: .env ファイルの内容を外部に送信するような操作も通過する Anthropic の開発者も不使用: 社内でも使用が推奨されていない 鹿野 壮 氏（@tonkotsuboy_com、Ubie）は当時の状況をこう振り返っている: 「男は黙って claude –dangerously-skip-permissions」。そうやって生きてきたけど、Anthropicの開発者が使ってなかったり、プロジェクトでは禁止されたりで、肩身の狭い日々でした auto mode とは auto mode は、dangerously-skip-permissions に代わる安全な選択肢だ。ツールの実行を自動承認しつつ、バックグラウンドで安全性チェックを行う。 両者の比較 dangerously-skip-permissions auto mode 権限チェック 完全無効 バックグラウンドで実行 安全性 なし セーフガード付き プロンプトインジェクション耐性 なし あり 危険なコマンドの実行 無条件で実行 検出してブロック 公式ステータス 推奨されていない リサーチプレビュー（2026年3月時点） auto mode の設定方法 起動時に指定する 1 claude --permission-mode auto settings.json でデフォルトにする settings.json の permissions に "defaultMode": "auto" を指定すれば、毎回のフラグ指定が不要になる: ...

前回の記事では、NotebookLM を使って「20人の専門家チーム」を構築する方法を紹介しました。この記事では、同じ考え方を Claude Code や Cowork で実現する方法を解説します。 NotebookLM と Claude Code の発想の違い NotebookLM は「入れた資料だけを根拠に回答する」ことが強みです。テーマごとにノートブックを分けることで、各ノートブックが「専門家」として機能します。 Claude Code でも同じアプローチが取れます。さらに、コード実行・ファイル編集・外部ツール連携ができるため、「相談する」だけでなく「調査して、コードを書いて、PR を作成する」ところまで一気通貫で任せられます。 観点 NotebookLM Claude Code 専門家の定義 ノートブック + ソース .claude/agents/ + ナレッジ 知識の投入 PDF / Web / Fast Research MCP / ローカルファイル / WebSearch 同時相談 手動で切替 Cowork / Agent Teams で並行実行 引用元表示 自動リンク ファイルパス・行番号 強み 非技術者でも簡単 コード実行・ファイル編集が可能 方法1: カスタムエージェント（.claude/agents/） 最もシンプルで NotebookLM の「専門家ノート」に直接対応する方法です。 カスタムエージェントの仕組み .claude/agents/ ディレクトリに Markdown ファイルを置くだけで、専門エージェントが定義できます。各ファイルにはそのドメインの専門知識・指示・参照先を書きます。 1 2 3 4 5 .claude/agents/ ├── marketing-expert.md # マーケティング専門家 ├── legal-advisor.md # 法務アドバイザー ├── seo-advisor.md # SEO アドバイザー └── fact-checker.md # ファクトチェッカー エージェント定義ファイルの書き方 Markdown ファイルの先頭に YAML フロントマターでメタ情報を定義し、本文にシステムプロンプトを書きます。詳細は 公式ドキュメント を参照してください。 ...