記事一覧

計画編で方針を、自動化基盤編でフレームワークを紹介しました。最終回では、実際に 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. ...

オープンソースの自律エージェント Dexter が注目を集めている。X では「Claude Code の金融版」と紹介され話題になった。約200行のコードで、銘柄スクリーニングから財務分析、投資根拠のレポート作成までを自動で行うツールだ。 Dexter とは Dexter は、virattt 氏が開発したオープンソースの自律型金融リサーチエージェント。2026年3月時点で GitHub スター数は 18,000 を超える。複雑な金融の質問を受けて、自分でリサーチ計画を立て、データを収集し、結果を検証してレポートにまとめる。 主な機能: 割安な銘柄の自動スクリーニング 財務データの詳細分析 投資根拠のレポート化 作業内容の自己検証（セルフバリデーション） アーキテクチャ: 4つのエージェント構成 Dexter は ReAct（Reasoning + Acting）パターンに基づくマルチエージェントアーキテクチャで構成されている。ReAct とは、LLM が「考える（Reasoning）」と「行動する（Acting）」を交互に繰り返すことで、複雑なタスクを段階的に解決するパターンだ。 エージェント 役割 Planning 金融クエリを分析し、リサーチ計画をステップに分解 Action 計画に基づいてツールを呼び出し、リアルタイムデータを取得 Validation 各ステップの完了を検証し、データの十分性をチェック Answer 収集した情報を統合してレポートを生成 この Validation エージェントが Dexter の特徴的な部分だ。金融分野では精度が重要なため、自分自身の出力を検証するレイヤーを設けている。ループ検出やステップ数制限などの安全機構も備えている。 技術スタック ランタイム: Bun（高速な JavaScript ランタイム） 言語: TypeScript UI: React + Ink（React コンポーネントでターミナル UI を構築するライブラリ） LLM オーケストレーション: LangChain.js LLM プロバイダ: OpenAI、Anthropic、Google、ローカル Ollama に対応 データソース: Financial Datasets API（リアルタイム市場データ） 始め方 リポジトリをクローンして依存関係をインストールする。 ...

mysqldump でデータベースをダンプしようとしたら、こんなエラーが出て止まった経験はないでしょうか。 mysqldump: Got error: 1449: The user specified as a definer ('root'@'%') does not exist when using LOCK TABLES これは MySQL の DEFINER という仕組みに起因するエラーです。ビューやストアドプロシージャの作成時に記録された「定義者（DEFINER）」ユーザーが、現在のサーバー上に存在しない場合に発生します。 なぜ起きるのか MySQL のビュー、ストアドプロシージャ、トリガー、イベントには DEFINER 属性があります。これはそのオブジェクトを作成した MySQL ユーザーを記録したもので、SQL SECURITY DEFINER（デフォルト）の場合、オブジェクトの実行は DEFINER ユーザーの権限 で行われます。 mysqldump は LOCK TABLES を実行する際、ダンプ対象のビューなどの DEFINER ユーザーを参照します。このとき、DEFINER に設定されたユーザー（例: 'root'@'%'）がサーバー上に存在しなければ、エラー 1449 で処理が中断されます。 よくあるシナリオ: 本番環境から別環境にデータベースをコピーした際、元の環境にいた root@'%' が移行先に存在しない MySQL のユーザーを整理した際、ビューの DEFINER を更新し忘れた root@'localhost' しか存在しないのに、ビューが root@'%' で作成されていた DEFINER が問題のオブジェクトを特定する まず、どのオブジェクトが問題の原因かを information_schema で確認します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 -- ビュー SELECT DEFINER, TABLE_SCHEMA, TABLE_NAME FROM information_schema.VIEWS WHERE DEFINER LIKE '%root@%'; -- ストアドプロシージャ / ファンクション SELECT DEFINER, ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE FROM information_schema.ROUTINES WHERE DEFINER LIKE '%root@%'; -- イベント SELECT EVENT_CATALOG, EVENT_SCHEMA, EVENT_NAME, DEFINER FROM information_schema.EVENTS WHERE DEFINER LIKE '%root@%'; -- トリガー SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.TRIGGERS WHERE DEFINER LIKE '%root@%'; 多くの場合、ビューが原因です。該当するオブジェクトが見つかったら、その定義を確認しましょう。 ...

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 フロントマターでメタ情報を定義し、本文にシステムプロンプトを書きます。詳細は 公式ドキュメント を参照してください。 ...

Claude Code は強力な AI コーディングエージェントだが、セッションをまたいだ記憶の保持には課題があった。Claude Subconscious は、Letta AI が開発したオープンソースのプラグインで、Claude Code にバックグラウンドで動作する永続メモリを追加する。 Claude Subconscious とは Claude Subconscious は、Claude Code のセッションをバックグラウンドで監視し、ユーザーの作業パターンや好み、未完了のタスクを学習・記憶するエージェントだ。次のセッション開始時に、蓄積した記憶をプロンプトに自動注入することで、毎回ゼロからのスタートではなく、文脈を引き継いだ作業が可能になる。 主な特徴: セッション横断の記憶: 複数セッションをまたいで作業コンテキストを保持・統合 バックグラウンド動作: Claude Code の操作をブロックせず、非同期で動作 自動コンテキスト注入: プロンプトの前に関連する記憶やガイダンスを自動挿入 コードベースの探索: Read、Grep、Glob ツールを使ってプロジェクトのコードを読み取り、理解を深める 完全無料・オープンソース: GitHub リポジトリ で公開中 仕組み Claude Subconscious は Claude Code のフックシステムを利用して、4 つのタイミングで介入する: SessionStart — エージェントに通知し、レガシーファイルをクリーンアップ UserPromptSubmit — 記憶とメッセージを stdout 経由で注入（10 秒タイムアウト） PreToolUse — ワークフロー中の更新を配信（5 秒タイムアウト） Stop — セッションのトランスクリプトをバックグラウンドエージェントに非同期送信 バンドルされたエージェントは 8 つのメモリブロックを管理する: メモリブロック 用途 core_directives 役割定義 guidance アクティブセッションのガイダンス user_preferences 学習したコーディングスタイル project_context コードベースの知識 session_patterns 繰り返しの行動パターン pending_items 未完了の作業 self_improvement メモリ進化のガイドライン tool_guidelines ツール使用の指針 インストール方法 Claude Code のプラグインシステムを使って 2 コマンドでインストールできる: ...

2026年3月、HuggingFace が新ツール hf-mount を発表しました。HuggingFace Hub にホスティングされている巨大な AI モデルやデータセットを、ダウンロードせずに仮想ファイルシステムとして直接マウントできるツールです。 hf-mount とは hf-mount は、HuggingFace の Storage Bucket、モデルリポジトリ、データセットをローカルファイルシステムとしてマウントするツールです。バックエンドには FUSE（Filesystem in Userspace: ユーザー空間でファイルシステムを実装する仕組み）または NFS を使用します。ファイルは最初の読み取り時に遅延フェッチ（lazy fetch）され、実際にアクセスしたバイトだけがネットワークを通ります。 HuggingFace CEO の Clement Delangue 氏は「ローカルマシンのディスクの 100 倍大きなリモートストレージをアタッチできる」と述べています。 主な特徴 ダウンロード不要: モデルやデータセットを事前にダウンロードする必要がない 遅延フェッチ: 実際にアクセスしたファイルだけがネットワーク経由で取得される 2つのバックエンド: NFS（推奨）と FUSE から選択可能 読み書き対応: Storage Bucket は読み書き両対応、モデル・データセットは読み取り専用 Kubernetes 対応: CSI ドライバー（hf-csi-driver）で Pod 内に FUSE ボリュームとしてマウント可能 インストール Linux（x86_64, aarch64）と macOS（Apple Silicon）に対応しています。 1 curl -fsSL https://raw.githubusercontent.com/huggingface/hf-mount/main/install.sh | sh デフォルトでは ~/.local/bin/ にインストールされます。INSTALL_DIR 環境変数で変更可能です。 ...

音声の文字起こし（トランスクリプション）は AI の実用的な応用の一つだが、長時間の音声ファイルを処理するには時間がかかる。insanely-fast-whisper は、OpenAI の Whisper モデルを Flash Attention 2 とバッチ処理で高速化し、150分の音声をわずか98秒で文字起こしできる CLI ツールだ。 概要 insanely-fast-whisper は、Hugging Face の Transformers、Optimum、flash-attn を組み合わせた文字起こし CLI だ。2026年3月時点で GitHub スター 11,000 以上を獲得しており、コミュニティ主導で開発が進んでいる。 主な特徴: 高速処理: Nvidia A100 GPU で 150分の音声を約98秒で文字起こし 簡単なインストール: pipx install でワンコマンド導入 複数モデル対応: Whisper large-v3、distil-whisper など Mac 対応: Apple Silicon (MPS) でも動作 翻訳機能: 文字起こしだけでなく、英語への翻訳も可能 ベンチマーク Nvidia A100 (80GB) での 150分音声の処理時間比較: 構成 処理時間 large-v3 (fp32) 約31分 large-v3 (fp16 + batching + BetterTransformer) 約5分 large-v3 (fp16 + batching + Flash Attention 2) 約1分38秒 distil-large-v2 (fp16 + batching + BetterTransformer) 約3分16秒 distil-large-v2 (fp16 + batching + Flash Attention 2) 約1分18秒 large-v2 (Faster Whisper, fp16) 約9分23秒 Flash Attention 2 の効果が顕著で、BetterTransformer と比較しても約2.5〜3倍の高速化を実現している。 ...