月末、売上表をまとめているとき。「AIに集計してもらえたら助かる。でも、この合計は合っているのだろうか」。
取引先への案内文を書いているとき。「文章はすぐできた。でも、日付や条件を誰が確認して、いつ送るのだろう」。
翌週、同じ仕事を再開するとき。「前の会話で何を決めたか、もう一度説明しないといけない」。
担当者が異動するとき。「集計表は残っている。でも、どんな条件で作り、どこまで確認したのかがわからない」。
こんな場面を想像してみてください。AIを使って何かを作る入口は広がりました。その先で必要なのは、仕事に合う完成条件を決め、成果物を確かめ、次の人や次の会話へ引き継げることです。
フィールフロウは、この課題に取り組むため、市民開発向けのプラグイン ff-work-toolkit を公開しました。2026年10月2日に公開した v0.1.0は初回試用版 です。Claude Code・Codex上で、業務の言葉から初期設定、文章・集計の作成、確認、記録、再開を支援します。
この記事では、業務を知る人がAIと一緒に仕事の道具を作り、改善する取り組みを「市民開発」と呼びます。入口は、小さな文書や集計でも構いません。以下の場面は使い方を説明するための想定例であり、顧客の導入実績ではありません。
たとえば、こんな仕事から始められます
図：AIとの仕事で起こりそうな課題と、確認・記録を組み合わせる進め方。想定例です。
1. 案内文を毎回ゼロから書いている
たとえば、営業担当者が取引先向けの案内文を作る場面です。過去の文面を探し、宛先や日付を直しているうちに、古い条件が残るかもしれません。
最初の依頼は、仕事の言葉で伝えます。
ff-work-toolkitで、取引先への案内文を作りたいです。対象は既存のお客様で、来月の受付時間の変更を知らせます。まず社内確認用の草案を作りたいです。
AIと目的、相手、必要な情報、完成条件を整理し、草案へ進みます。確認するのは、表現の自然さだけではありません。変更日、受付時間、対象者、問い合わせ先が正しいかも確かめます。
「草案を保存する」と「取引先へ送信する」は別の行為です。保存できたことをもって送信完了にはしません。
2. 毎月の集計で、数字の確認に時間がかかる
たとえば、店舗の月次売上をまとめる場面です。表ができても、元データの抜けや重複があれば、見た目だけでは気づきにくいものです。
ff-work-toolkitで、月別・店舗別の売上をまとめたいです。まずダミーデータで試し、元データの件数と合計が集計結果に一致することを確認したいです。
何を入力にし、どの単位でまとめ、何をもって完成とするかを決めます。集計では、元データと結果の件数・合計の照合が確認の入口になります。業務によっては、空欄や返品の扱いなども先に決める必要があります。
初回版で公開されている検証は、架空の文章・集計を使ったものです。実際の売上データでの効果や、あらゆる表形式への対応が証明されたわけではありません。まず小さなダミーデータで、進め方を確かめてください。
3. 前のAIとの仕事を、次の会話・次の担当者へ引き継げない
たとえば、担当者が翌週に集計の続きを進める場面です。会話履歴だけに判断が残っていると、どの表が完成版で、何が未確認かを探すところから始まります。
ff-work-toolkitで、前の売上集計の続きから始めたいです。記録と成果物を確認して、未確認の点と次の作業を教えてください。
ff-work-toolkitは、完成条件、現在地、判断、未決事項、成果物、次の作業を記録し、再開を支援します。GitHubを使う場合は、一つの目的を一つのIssue（作業記録の単位）で追い、合意した範囲で経過と履歴を残します。使わない場合は、合意したローカルの進捗メモを利用します。
保存に失敗した場合は「未同期」と伝えます。記録が残ったかを確かめることも、仕事の完了条件の一部です。
担当者が変わっても、仕事の続きを見つけられるように
作業を引き継ぐとき、完成した表や文書だけでは足りないことがあります。「返品をどの月に入れたか」「誰の確認がまだ必要か」といった判断まで残っていれば、後任が経緯を確認する手がかりになります。
たとえば、月次集計の担当者が異動する前に、次のように相談する場面です。
ff-work-toolkitで、この集計を次の担当者へ引き継ぐ準備をしたいです。記録と成果物を読み返して、目的、完成条件、判断、未確認事項、成果物の置き場、次の作業を整理してください。
引き継ぐ側は、どの成果物が現在のものか、何を確認済みか、何が残っているかを確かめます。受け取る側は、共有された記録と成果物を読み、業務の条件を理解してから続きに取り組みます。AIとの会話を毎回やり直す負担と、人の記憶だけに頼る引き継ぎを減らすための使い方です。
記録・成果物の共有、アクセス権、必要なツールの導入、扱ってよいデータの範囲は、組織で確認して準備します。ローカル保存のファイルが後任へ自動共有されるわけではありません。初回版の公開検証は別会話からの再開までであり、担当者間の引き継ぎを検証済みの実績として紹介しているものではありません。
品質とガバナンスを、日々の仕事の言葉にする
品質は「その仕事で使えるかを確かめること」、ガバナンスは「誰が何を決め、どこへ保存し、いつ外へ出すかのルールを決めること」と考えると、具体的に話し合えます。
| 観点 | 案内文・集計で考えること | ff-work-toolkitの初回版が支援すること |
|---|---|---|
| 品質 | 日付・条件は正しいか。件数・合計は一致するか | 作る前の完成条件の整理と、成果物に合う確認の提案 |
| ガバナンス | 何を保存してよいか。送信・公開は誰が判断するか | 保存範囲の相談、通常の記録保存と送信・公開の区別 |
| 引き継ぎ | 何が終わり、何が未確認か。次に何をするか | 判断・未決事項・成果物・次の作業の記録と再開 |
保存範囲へ、元データや個人情報を含むファイルを勝手に追加しません。会話全文や認証情報も記録対象にしません。合意した範囲の通常記録は毎回許可を求めず進めますが、外部送信や公開とは分けて扱います。
これは、会社全体のガバナンスを自動で整える機能ではありません。責任者、データの持ち出し条件、承認経路などは、組織のルールとして定める必要があります。ツールキットは、そのルールを考えながらAIとの作業を始める入口です。
なぜ、業務向けのツールキットを作ったのか
開発者向けの仕組みをそのまま渡すと、小さな案内文を作る前に、文書構成や開発管理の用語を理解する負担が増えます。そこで、ff-work-toolkitでは仕事の目的と完成条件から始め、必要になったら文書や仕組みを増やす形にしました。
入口は二つです。初期設定を担う asdd-init と、日常の依頼・確認・再開を担う asdd-work。これらはAIが参照する手順の名前で、利用者がコマンドを覚えることを前提にしません。
最初は短い案内文書から始め、目的、完成条件、保存方法を相談します。最初から7文書や決まったレビュー回数を要求しません。作った後の確認と記録も含めて、次の仕事につなげるための設計です。
開発者向けff-dev-toolkitとの違い
| 比較 | ff-work-toolkit v0.1.0 | ff-dev-toolkit |
|---|---|---|
| 主な対象 | AIと業務を進めたい非エンジニア・市民開発者 | ソフトウェア開発者・開発チーム |
| 入口 | 仕事の言葉で初期設定、依頼、確認、記録、再開 | 開発工程に応じた手順・レビュー・運用 |
| 文書の始め方 | 最小の案内文書から必要に応じて増やす | 開発の規模や工程に合わせて構成する |
| 初回版の収録範囲 | 初期設定と日常作業の2つの入口、文書検索MCP（AIが文書を探す仕組み） | 高度な開発・レビュー・知見蓄積の機能も扱う |
ff-work-toolkitの初回版には、ACE（知見の蓄積）、自動振り返り、複数AIレビュー、plugin Hook、CIの自動構築は収録していません。既存の組織ルールやCIを削除・緩和するものでもありません。
既存設定で未収録の機能が有効な場合は、その値を保持し、開発者向け版への切替を案内します。文書・設定・作業ID・履歴を引き継いで差分を確認する設計です。
始め方：導入を済ませたら、仕事の言葉で相談する
Claude CodeまたはCodexに、ネイティブプラグインとして導入します。スキルファイルを作業フォルダへコピーする方法ではありません。初回の環境設定は、伴走者と一緒に進めても構いません。
Claude Code内での導入手順は次のとおりです。
/plugin marketplace add feel-flow/ff-work-toolkit
/plugin install ff-work-toolkit@ff-work-toolkitCodexでは、ターミナルで次を実行します。
codex plugin marketplace add feel-flow/ff-work-toolkit
codex plugin add ff-work-toolkit@ff-work-toolkit導入・更新後は、利用ツールの案内に従って新しいセッションで始めます。登録名を変更している場合は、そのmarketplace名を使ってください。その後は、たとえば次のように依頼できます。
ff-work-toolkitで、仕事をAIと進める準備をしたいです。まず取引先への案内文をダミー情報で作り、社内確認用の草案として保存したいです。
Node.jsが必要です。成果物の履歴保存や既存ファイルの差分処理にはGitを使います。GitHubに経過を残す場合は、アカウント、認証済みのGitHub CLI、記録先の設定も必要です。GitHub未接続でもローカルで成果物を作れますが、外部への記録保存は行いません。
開発者向け版も導入済みの場合は、「ff-work-toolkitで」と指定してください。AIは実際に読み込んだプラグインの処理だけを使います。最新の導入手順は公開READMEで確認できます。
初回試用版の制限
公開Releaseでは、架空の文章・集計を使い、両ツールでの初期設定、専用の非公開リポジトリへの保存、別会話からの読戻しを確認したとしています。業務導入による時間削減や品質向上の効果を測定したものではありません。
Issue数の多い既存リポジトリでは、記録の照合がタイムアウトする場合があります。 その場合は未同期として再確認が必要です。初回は、専用の小さな記録先からの利用を推奨しています。詳細はv0.1.0のReleaseをご覧ください。
実業務へ育てたい方へ：市民開発 AI伴走コンサルティング
小さな文書や集計で試せたら、次は「自分たちの業務では、何を作り、どの品質で、誰の責任で運用するか」を考える段階です。
フィールフロウの 市民開発 AI伴走コンサルティング は、業務を知る非エンジニアがAIと作ったものを、安全に改善し続けられる業務ツールへ育てるための3ヶ月プログラムです。KPIダッシュボードや集計自動化など、実業務を題材に伴走します。
短い仕様を置く、変更履歴を残す、人が結果を確認する。そのうえで、ツールの持ち主、公開までの承認経路、保存場所、変更の経緯を追える仕組みを考えます。品質とガバナンスを、現場の作業と一緒に整えていく支援です。
担当者が変わるときに、作った人だけがわかるツールを残さないことも大切です。引き継ぐ記録、後任が確認する手順、責任者と共有範囲を、チームの運用として考えるところまで相談できます。
ff-work-toolkitは、公開プラグインを自分で試す入口です。コンサルティングでは、御社のデータ・運用ルール・責任分担に合わせた導入と改善を伴走します。「最初のテーマ選びから相談したい」「試作品を実業務で使える状態に育てたい」という方は、市民開発 AI伴走コンサルティングの内容をご覧ください。