Untitled

2026-03-30

source: "https://x.com/gura105/status/2025524398745411957" tags:

"clippings"

整理日: 2026-03-16

2ヶ月で16個のClaude Codeスキルを作った。気づいたら、PM業務が丸ごとパイプラインになっていた。

PM業務のパイプライン化の手順

ビジュアルデータ × AIのプロジェクトでPMをやっています。現場にデータ取得に足を運び、日次・週次定例を回しながら、DSチームメンバーと評価指標の設計方針をディスカッションし、技術的な検証結果をステークホルダーに翻訳する。ただの進行管理ではなく、データサイエンスの知見でプロジェクト全体を動かす仕事です。

Claude Codeの活用記事はコーディングの文脈が多いですが、この記事は違います。議事録、メール、データ整備、レポーティング — 開発以外の業務全体をClaude Codeでぶん回した記録です。

なお、同プロジェクトで開発の設計・基盤構築も巻き取っていますが、その話は別で書きます。

最初は愚直にClaude Codeと並走する

最初はあらゆるタスクをClaude Code経由で実行するところから始めました。

「gog-cliでこのメールスレッド検索して」

「Notionに議事録ページ作って」

「このCSVのデータ状況を集計して」

最初は地道にシンプルに

手作業をClaude Codeと一緒にやる。間違えたら指摘する。正しくゴールできたら覚えさせる。

例えばgog-cli経由でGmailのスレッドを取得させたら、古い順に全文を読み始めて最新のやり取りを見落とした。「スレッドは末尾から読め」をスキルに明記。こうした試行錯誤の1つ1つが、後のスキル設計の土台になっています。

この段階では「Claude Code経由でAPIを叩いている」だけです。

構造図

flowchart TD
    A["gog-cli"]
    A --> B["引き継ぎができる。"]
    B --> C["手順書"]
    C --> D["自分の業務を分析して"]
    D --> E["こうすればもっと上手く回る"]
    E --> F["個別業務の手順書6本 — 各業務の入力・出力・使用スキル.."]
    style F fill:#c05746,color:#fff,stroke:none

繰り返す作業を、小さなskillにしていく

数日やると、毎日繰り返す作業が見えてくる。これをClaude Codeのskillにしていきました。

まず、Claude Codeの「手足」になる基盤ツール群があります。

gog-cli — Google Workspace（Gmail, Calendar, Drive）をCLIで操作
Notion MCP Server — NotionのページやDBをClaude Codeから直接操作
DuckDB CLI — CSVファイルにSQLを実行して集計・分析
ptrans — 過去に自作したWhisper APIラッパー。音声→テキストの単機能ツール

これらをClaude Codeのスキルでラップして「手順書」にする。

/create-minutes — Notion MCP経由で議事録DBにテンプレート作成
/email-search — gog-cli経由でGmailをセマンティック検索
/duckdb-csv — DuckDB CLIで管理CSVをSQL集計
/gog-gmail, /gog-calendar, /gog-drive — gog-cliの各サブコマンドをスキル化

1つ1つは小さい。「メールを検索する」「議事録テンプレを作る」レベルの単機能です。

ポイントは、スキルを作るたびに「何をするか」をClaude Codeにmdファイルとして言語化させていたこと。業務の背景や判断基準もドキュメントに残す。この習慣が後で大きく効いてきます。

スキルが組み合わさって、パイプラインになった

毎日の業務で「内部議事録を参照 → 外部向けに変換 → PDF化 → メール送付」を繰り返していることに気づく。

個別スキルを組み合わせた複合スキルを作りました。

/transcribe-to-minutes — MTG録音 → ptransで文字起こし → 誤変換修正 → トピック別に再構成 → Notion内部議事録に登録
/fill-external-minutes — 内部議事録・レポート・検証メモなど4ソースを統合 → 外部向けにフィルタリング・変換 → Notion外部議事録に記入
/share-minutes — Notion議事録 → PDF化 → 要約生成 → ステークホルダーへのメール返信ドラフト作成

複合スキルの中では、基盤ツールとアトミックなスキルが連鎖しています。/share-minutes なら、Notion MCP → /notion-pdf → gog-cli という流れです。

毎日のルーティンがこうなりました。

[内部MTG] DSメンバーと評価指標・検証方針をディスカッション ↓ /transcribe-to-minutes MTG録音を文字起こし → 構造化議事録をNotionに登録 ↓ [Claude Codeと壁打ち] 検証方針や技術的論点を構造化・整理 ↓ /create-minutes 外部向け議事録テンプレートをNotionに作成 ↓ /fill-external-minutes 内部議事録・レポート・検証メモを統合 → 外部向けに変換して記入 ↓ [外部MTG] 検証結果をステークホルダーに翻訳 ↓ /transcribe-and-update 外部MTG録音を文字起こし → 外部議事録を補完 ↓ /share-minutes 議事録をPDF化 → メール返信ドラフト作成

人間のアクションとAIエージェントの作業が一体となったパイプライン

重要なのは、このパイプラインが「定型業務の自動化」だけで構成されているわけではないということです。

内部MTGでDSメンバーとAIモデルの評価指標を議論する。Claude Codeと壁打ちして精度検証の方針を構造化する。その技術的含意をステークホルダーに伝わる形に翻訳する。これらはスキルで自動化されていませんが、すべて「情報の変換」です。

スキルが担うのは定型的な情報変換。自分が担うのはドメイン知識を要する情報変換。両方合わせて1つのパイプラインです。

Claude Codeが定型変換を圧縮してくれるから、自分のデータサイエンスとエンジニアリングの知識を使う変換に集中できる。結果として、知識の適用範囲と速度が圧倒的に広がりました。

「調べる → 試す → 動いたらスキルに組み込む」

パイプラインは一発で完成したわけではありません。壁にぶつかるたびに「調べて、試して、動いたらスキルにする」を繰り返しました。

NotionのPDFエクスポート

議事録をPDF化してステークホルダーに送りたい。しかしNotion公式APIにPDFエクスポート機能がない。Claude Codeに非公式の内部APIを調べさせ、bashスクリプトを一緒に書いた。動いたのでそのまま `/notion-pdf` スキルとして切り出し、/share-minutes から呼ぶ構成にしています。

公式APIに機能がなくても、調べて試して動けばスキルにする。この姿勢がパイプラインの穴を埋めていきました。

過去の自作ツールの再利用

/transcribe-to-minutes には音声の文字起こしが必要です。ここで過去に作ったptransが活きた。「音声→テキスト」だけの単機能ツール。単機能だったおかげで、何も改修せずにパイプラインに組み込めています。

業務フロー全体のリバースエンジニアリング

パイプラインが回り始めると、リポジトリにはスキル定義、議事録、レポートが自然と蓄積されていきます。スキルを作るたびに業務内容をmdとして言語化させていたので、業務の断片がすべて構造化された状態で残っていました。

ある日、Claude Codeにこれらを全部読ませて「自分の業務を分析して」と頼んでみた。

出てきたのがこれです。

Claude Codeが分析した業務フロー

週次サイクルの俯瞰図 — 月曜〜金曜の業務パターン、日次・週次・非定常タスクの3レイヤー構造
情報フロー図 — どの情報がどのスキルを通ってどう変換されるかの全体マップ
個別業務の手順書6本 — 各業務の入力・出力・使用スキル・判断ポイント

自分がボトムアップで積み上げたスキル群の全体構造を、AIが逆算して言語化してくれた。自分でも整理しきれていなかった「毎日何をどの順番でやっているか」が、構造化ドキュメントとして目の前に出てきます。

これは大きい。

引き継ぎができる。 スキル群とフロー図をそのまま渡せば、別のメンバーが同じ業務を再現できる。属人化していたPM業務が、再現可能な構造になった。
自律化の土台になる。 cronや外部トリガーと組み合わせれば、AIエージェントが自律的にパイプラインを回せる。「毎朝9時に前日の議事録を処理して共有する」は、もう手の届く距離にあります。

スキルを作る → パイプラインになる → 全体構造が可視化される → 引き継ぎ可能になる → 自律化の土台になる。この連鎖です。

---

ボトムアップで積み上げたら、UNIX哲学に辿り着いていた

最初から「パイプラインを設計しよう」なんて思っていませんでした。

プロジェクトの業務フローは、進行状況やステークホルダー次第で変わる。トップダウンでルール化できるものではない。ハンズオンで業務を進めながら、1つずつ自動化していき、流れが見えてきたところでパイプライン化する。ボトムアップでしか進められなかった。そして結果的に、この進め方がこの種の業務と非常に相性が良かった。

手作業 → スキル化 → 組み合わせ → 業務フローの可視化。積み上げただけです。

振り返ると、各スキルは「1つのことをうまくやる」ように作られていた。前の出力が次の入力になっている。基盤ツールは単機能のCLI、スキルはそのラッパー、複合スキルはそれらの組み合わせ。レイヤーが分かれているから、組み替えも差し替えも容易です。

ptransが何も改修せずに使えたのも、単機能で作っていたから。スキルが構造化されているから、AIが全体を読み解いてドキュメント化できた。全部が1つの巨大スクリプトだったら、リバースエンジニアリングは不可能だったはずです。

「小さく作って、シンプルに繋ぐ」

50年前のUNIX哲学が、AIエージェント時代のプロジェクトマネジメントで自然に再現されていました。

---

おわりに

Claude Codeの活用はコーディングだけではありません。プロジェクトマネジメントという、直接的に価値を生む業務全体をパイプライン化できる。

パイプラインは道具であって主役ではない。主役はドメイン知識と設計力を持った人間です。データサイエンスのバックグラウンドがあるから評価指標の議論ができる。エンジニアリングの経験があるからスキルの分割と接続を設計できる。Claude Codeは、この知識と経験の適用速度を何倍にも引き上げてくれる。

シニアエンジニア × 元データサイエンティストの能力を、AIで拡張する。一人で回せるプロジェクトの規模と速度が根本的に変わりました。

技術力は「コードを書く力」だけではない。「情報の流れを設計する力」と「ドメイン知識をパイプラインに翻訳する力」が、AI時代の武器になります。

---

この記事ではPM業務のパイプライン化に焦点を当てましたが、同プロジェクトではClaude Codeを使った開発の設計・基盤構築や、AIモデルの精度検証の高度化も並行して進めています。開発 & 精度改善編も需要があれば書きます。

また、このアプローチが完成形だとは思っていません。「こうすればもっと上手く回る」「自分はこういうやり方をしている」といった意見があれば、ぜひお聞かせください。