!シリーズ: Claude Codeエージェント実践シリーズGitHub: agent-scaffold-factory / data-analysis-agent / reporting-agent TL;DR28日間で設計した4体のエージェントのうち、実際に作れたのは2体。設計と現実のギャップは大きかったが、4つのフレームワーク（2層PDCA・部下育成モデル・エージェントモデリング・道具作りパターン）は再利用できる資産になった「自分専用の専門家を揃える」の答え——専門家は育てるものであり、テンプレートから即座に完成するものではない。28日で2体が現実的なペースシリー...

TL;DRWeek 2 のデータ分析エージェントは「既存ツールを使う」、Week 4 のレポーティングエージェントは「ツールそのものを作る」——この違いを設計パターンとして整理したfetch_data() + generate_html() の2関数設計は「入力仕様と出力仕様を分離する」パターンの実践だったDay 26 の反省を踏まえ、エージェント間の引き継ぎ設計を具体的に見直した。速く作れることと正しく作ることは別の話 作ったものGitHub: akira-cloudjob-public/reporting-agent（Week 4 完了後に公開予定）今日はコー...

TL;DRdashboard_generator.py が v2 で止まっていたことに気づき、v3/v4 の SQL 3本 + HTML セクションを一括マージしたBigQuery → Python → HTML → Chrome の全工程を通し実行し、v4 ダッシュボードが実データで表示されることを確認したAIが速く作れる快感で設計上の役割分担を忘れていた。本来は分析エージェント経由の設計なのに、人間が直接改良し続けた反省 今日のゴールDay 22〜25 で段階的に積み上げてきたダッシュボードの設計（SQL 7本・HTMLセクション追加）を、実際に動く dashb...

TL;DRトップ顧客ランキング（セグメント付き）と離反顧客ワーニングを v4 ダッシュボードに追加した離反検出は「前月購入 × 当月ゼロ」の LEFT JOIN + IS NULL パターンで実装金額だけ見ていたダッシュボードに「誰が買っているか」「誰が離れたか」の視点が加わった 今日のゴールv3 ダッシュボードに「トップ顧客ランキング」と「離反顧客ワーニング」を追加し、金額だけでなく「誰が買い、誰が離れたか」が見える v4 を完成させる。 前提条件Day 24 の v3 ダッシュボード（KPI・推移・粗利）が完成していることBigQuery に analy...

TL;DR予算テーブル（analytics.budget）を新設し、KPIカードを「売上実績」→「予算達成率＋粗利」に進化させた月次推移を売上＋粗利の 2本折れ線、カテゴリ別粗利を ドーナツチャート（Canvas API） で新規実装v3 ダッシュボードは「売上だけ」から「利益と予算が見える」状態になり、SQL は 4本 → 5本に増えた 作ったものGitHub: akira-cloudjob-public/reporting-agent（Week 4 完了後に公開予定） v3 ダッシュボードv2 と比べると情報量が段違い。「売上がいくらか」ではなく「利益がど...

TL;DRNext.js 向けに整理した「18種グラフ × 11種コントロール」のダッシュボード設計書を、言語非依存の グラフ選定ガイド に変換して reporting-agent の knowledge/ に注入した知識注入後に v2 ダッシュボードを生成。月次推移が横棒グラフ → 折れ線グラフ に変わり、カテゴリ別売上 セクションが追加された「何の言語で書くか」ではなく「何を伝えたいか」を知識として渡せば、技術スタックの壁は超えられる 作ったものGitHub: akira-cloudjob-public/reporting-agent（Week 4 完了後に公開予...

TL;DR昨日設計したレポーティングエージェントを実際に構築し、BigQuery → Python → HTML のダッシュボード生成に成功したWindows の Python subprocess で bq コマンドが見つからないハマりポイントがあったが、shell=True で解決。「道具を作る」エージェントならではの環境依存問題生成に成功した3つのコンポーネント（サマリーカード、データテーブル、横棒グラフ）をテンプレートとして knowledge/ に切り出した。これが安定生産の第一歩 作ったものGitHub: akira-cloudjob-public/rep...

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 ...