TL;DR3体目のエージェント「レポーティングエージェント」を設計した。Python + HTML でダッシュボードを生成する、道具を作る エージェントagent-scaffold-factory テンプレートで雛形を生成し、CLAUDE.md・スキル・ナレッジを設計。テンプレート効果は健在で、設計作業は半日で完了「道具を使う」エージェントと「道具を作る」エージェントでは、CLAUDE.md に書くべきことが根本的に違う。出力品質の制約をどう伝えるかが設計の肝になった 作ったものGitHub: akira-cloudjob-public/reporting-agent...

今日のゴールWeek 3（Day 15-19）で取り組んだ「エージェントモデリング → n8n エージェントの育成」を振り返り、Week 2 との違いを分析する。得られた教訓を整理し、Week 4 の計画を立てる。 前提条件Day 15〜19 の記事を読んでいると背景が掴みやすい。ただし、各パターンは単独でも読めるように書いているので、「振り返り記事だけ追う」読み方でも大丈夫です。 TL;DRWeek 3 では 1体のエージェント → 2体のチーム にスコープを拡大した。単体では見えなかった「エージェント間の引き継ぎ」という課題が浮上し、スキルで解決したWeek 2...

TL;DRDay 18 で設計したエージェント間インターフェースを 2つのスキルとして実装した分析エージェント → /handover（引き継ぎ書を構造化して出力する）n8n エージェント → /reception-check（情報が揃っているか検証し、不足があれば聞き返す）改善版の引き継ぎ書でワークフロー再生成したところ、Day 17 で 10 個あったエラーが 1 個に減ったエージェント間の品質は「引き継ぎの情報密度」で決まる。スキルで構造化すれば、毎回同じ品質で渡せる 作ったもの/handover スキル — 分析エージェントの SKILL.md...

TL;DRエージェントが生成したワークフローを実際に動かしたら 10 個のエラーが出た。原因はすべて「引き継ぎ不足」エラーを 3 カテゴリ（接続情報 / n8n 固有仕様 / 実行前提）に分類し、エージェント間のインターフェースを設計した分析エージェントに「引き継ぎ」スキル、n8n エージェントに「受付チェック」スキルを持たせれば、PLACEHOLDER 問題は構造的に解消できる 作ったもの引き継ぎ書テンプレート / 受付チェックリスト — エージェント間インターフェースの設計（本記事内に掲載）n8n-workflow-agent リポジトリ — 準備中（スキ...

TL;DR部下育成モデル Phase 2（やらせてみる）として、n8n ワークフローエージェントに初めて実タスクを与えたIssue に要件を書いて渡したら、Phase 0〜5 を自律的に進め、7ノードのワークフロー JSON + ドキュメント2点を生成したPublic API 経由のインポートでは認証トークンの違い（MCP用 vs API用）で詰まったが、エージェント自身がリトライで解決した 作ったものn8n ワークフロー「週次_地域別売上レポート」src/REQ-001/├── 週次_地域別売上レポート.json ← ワークフロー JSON（7ノード）├...

TL;DRDay 15 で設計した4体のエージェントチームのうち、2体目の n8nワークフローエージェント を部下育成モデル Phase 1（設計する）で構築したn8n エージェントの役割は 翻訳者 — データ分析エージェントが確定した SQL を、n8n ワークフロー JSON に変換する。SQL の中身には触らせないn8n の MCP 連携を有効にし、Claude Code から /run-workflow /list-workflows でワークフローを操作できるスキルを設計した 作ったものn8nワークフローエージェントの初期構成n8n-workflow-a...

TL;DRWeek 2 で「1エージェント × 1スキル」を育てた。Week 3 では「複数エージェント × パイプライン」に拡大する「何をエージェント化すべきか」「どう分割すべきか」を判断するエージェントモデリングの手法を整理した共通スキル（BigQuery）× 固有スキル（n8n / Dataflow / Python出力） のコンポジションで、4体のエージェントチームを設計した 作ったものWeek 3 のエージェントチーム設計エージェント共通スキル固有スキル役割データ分析エージェントBigQuery-探索的にデータを分析する...

TL;DRWeek 2 で「汎用エージェントをデータ分析の専門家に育てる」一連の流れを実践したこの過程を 4フェーズの部下育成モデル（設計する → やらせてみる → 指導する → 任せる）として整理した売上分析に限らず、繰り返す定型業務なら同じフレームワークで専門スキルを育てられる 作ったものWeek 2 の成果物:成果物内容data-analysis-agentデータ分析に特化した Claude Code エージェントSales Skill売上データの定型分析を自律実行するスキルサンプルデータBigQuery 環境構築用の C...

TL;DRDay 11-12 で蓄積した [analytics.sales] タグ付きナレッジ6件を使い、4観点（ナレッジ蓄積・動作安定性・ルール遵守・出力品質）の昇格チェックを実施した全項目合格 → Sales Skill としてパッケージし、/query コマンドの確認ステップを「既知パターンなら省略可」に変更した同じ「先月の売上を地域別に見て」で動作確認。初回は2つの承認（スキル実行 + クエリ実行）が必要だが、承認後は確認なしで実行まで完了したGitHub: akira-cloudjob-public/agent-scaffold-factory 今日やる...

TL;DRDay 11 で見つけた3つの問題（日付ハードコード、考察混入、スコープ逸脱）に対してフィードバックし、ナレッジを修正した修正後の再テストで、日付・考察の問題は改善を確認。一方で「レポート再利用時にルール違反SQLが混入する」という新たな問題も見つかった蓄積したナレッジを「スキル候補」と「一般」に仕分ける記録方法を導入した。これが Day 13 の昇格チェックの材料になるGitHub: akira-cloudjob-public/agent-scaffold-factory 今日やることDay 11 でエージェントに売上分析を依頼した。結果は概ね良好だ...

TL;DRDay 9 で作った /query コマンドを実際の売上データに当てた。「先月の売上を地域別に」→ SQL 生成 → 確認 → 実行 → 3点セット出力、一連の流れが動いた追加で「カテゴリ別の粗利益も」と頼んだら、products テーブルとの JOIN まで自分で判断してきたここで得た知見は、Day 12 以降で Sales Skill としてまとめていく 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory今回は新しいコードを書くのではなく、Day 8-9 で作った仕組みを実データに対して...

TL;DRbq query が Git Bash で動かない原因は、Cloud SDK のインストール先パスにスペースが含まれていたこと.exe インストーラーはパス指定ができないため、ZIP版（bundled-python） で C:\google-cloud-sdk\ に再インストールして解決Cursor（Claude Code）はすべてのウィンドウを閉じて再起動しないと PATH 変更が反映されない 何が起きたかBigQuery のサンプルデータを bq load でテーブルに流し込んでいた。bq load は問題なく動く。ところが bq query を実...

TL;DR/query コマンドを Text-to-SQL パイプライン として実装。SQL が見える、再現できる、修正できるアウトプットは3点セット: 分析レポート + 使った SQL + ローデータ（タブ区切り）MCP で Google Sheets にも接続。CLI があるものは CLI、ないものは MCP 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# Day 9 で追加・変更したファイルdata-analysis-agent/├── CLAUDE.md ...

TL;DR汎用エージェント + ドメイン固有のツール = 専門エージェント追加するのは3つ: commands/、knowledge/technical/、CLAUDE.md の更新Week 2 ではデータ分析エージェントを育てる。今日はその設計編 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# Week 1 の汎用エージェント → Week 2 の専門エージェント汎用エージェント データ分析エージェント├── CLAUDE.md ├── CL...

TL;DRWeek 1 で agent-scaffold-factory の5つのフォルダ構造を解説した私は「2層のPDCA」という考え方でエージェントを運用している技術的なエビデンスがあるわけではなく、8ヶ月の試行錯誤で辿り着いた「今の形」 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# Week 1 で学んだフォルダ構成agent-scaffold-factory/├── CLAUDE.md ← Day 3: 行動ルール定義├── .claude/com...

TL;DRtemplates/ は5つのテンプレート（ヒアリング記録〜完了報告）で成果物の一貫性を担保テンプレートを使うと「何を書くか」で迷わなくなり、エージェントも人間も作業効率が上がるPhase ごとにどのテンプレートを使うかを定義し、承認フローと連動させる 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# 今日学ぶことtemplates/ フォルダの構造 ↓5つのテンプレートと役割 ↓Phase との連動・承認フローDay 5 で knowledge/ のナレッジ管...

TL;DRknowledge/ は4つのカテゴリ（business, technical, people, lessons）でナレッジを構造化起動時は business/ だけを読み込み、他は必要時に参照する（コンテキスト効率化）lessons/ で蓄積した教訓は、繰り返されるなら business/ にルールとして昇格 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# 今日学ぶことknowledge/ フォルダの構造 ↓4つのカテゴリと使い分け ↓昇格フローとコンテキス...

TL;DR.claude/commands/ にMarkdownファイルを置くとスラッシュコマンドになる4つのコマンド（start-req, next-phase, status, approve-phase）でPhase管理が回る自分でコマンドを作りたければ、GitHubの実ファイルを参考に 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# 今日学ぶこと.claude/commands/ のコマンドファイル ↓4つのコマンドの中身 ↓Phase管理の仕組みDay 3 で...

TL;DRCLAUDE.md は「プロジェクトルール + AIの振る舞い」を一元管理するファイル技術スタックだけでなく「曖昧な指示は確認を取る」のような行動ルールも書く長すぎると逆効果。コンテキスト効率を意識して書く 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# 今日学ぶことsrc/agent-framework/CLAUDE.md の読み方 ↓各セクションの意味 ↓カスタマイズのコツDay 2 で /new-agent を使ってエージェントを払い出しました。今日は、払...

TL;DR/new-agent データ分析エージェント ~/projects/data-analyst でエージェントを払い出せる払い出されるのは「CLAUDE.md + コマンド + テンプレート + knowledge構造」のセット払い出し後、すぐに /start-req で依頼を開始できる 作ったものGitHub: akira-cloudjob-public/agent-scaffold-factory# 今日やること/new-agent データ分析エージェント ~/projects/data-analyst ↓払い出されたエージェントを確認...