革職人が8人のAI参謀を雇った話 第12話
第12話 テスト見積依頼が通った日——8人が連動した瞬間
朝の作業机で、シミュレーター画面を眺めていた。
works.html という、ホームページに置いているオーダー革小物の見積シミュレーターがある。お客様が革種と用途と希望サイズを入力すると、ざっくりした金額の目安が出る。これ自体は数年前から動いているのだが、その日たまたまその画面を眺めながら、いつものモヤモヤがふいに言葉になった。
——この見積、押した瞬間にうちの台帳に「依頼受付」として記録されてくれたら、楽だな。
シミュレーターの結果はあくまで目安で、本気で依頼したいお客様はそこから別途メールで連絡をくださることになっている。私はそのメールを見て、見積→請求→領収の流れを手作業で台帳に書き起こす。月に何件か、地道に。けれどそれは要するに「シミュレーター画面とうちの会計のあいだに、橋がかかっていない」ということだった。
正式見積依頼ボタンを置けばいい。押した瞬間に顧客情報を含めた依頼が、うちの請求書GAS（社内で使っている見積・請求書発行スクリプト）の台帳に「依頼受付」状態で流れ込んでくる。そうすれば見積から請求、領収までを一気通貫で運用できる。
朝のコーヒーを置いて、デジタル幕僚にその思いつきをそのままぶつけた。
デジタル幕僚の A案——「もう設計はAI側にある」という感覚
返ってきた案は、迷いがなかった。
A案として、(1)既存シミュレーター画面の下に「正式見積依頼に進む」ボタンを追加する、(2)押すと顧客情報フォームを展開する、(3)送信時に既存の請求書GAS WebAppへ POST して台帳の「依頼受付」状態として登録する——三段構えで返ってきた。フロント側で触る必要があるのは config.js と stock-quote.html と leather-order-estimate-v2.html の3ファイル、GAS側は WebApp に `submitQuoteRequest` という新しい case を一つ足すだけ、と。
「もう設計はAI側にある」という感覚は、第3話で書いた頃の自分には絶対になかった感覚だ。あの頃は、何をどう作りたいかを言語化することすら詰まっていた。十一話分の連載で書いてきたとおり、引き継ぎ書を積み上げ、所管部を分け、CLAUDE.md に禁止事項を一行ずつ書き加えてきた数年の蓄積が、こういう朝の十五分のやり取りに静かに乗っている。
CORS を回避するために `Content-Type: text/plain;charset=utf-8` を使うこと、レスポンスは `{success: true, number, customerId}` の形で揃えること、フロント側のステータス文字列も既存運用の「ok」ではなく「success」に統一すること——細部の判断もデジタル幕僚側にすでに溜まっていた。私はそれを「やろう」と決めればよかった。決めた。
決めて、後方幕僚に作業を回した。
四つの所管部が、同じ午前に動き出す
決めた瞬間から、四つの所管部が同じ午前に動き出した。
デジタル幕僚は、フロント3ファイルへの「正式見積依頼」ボタンと顧客フォームの埋め込み、GAS WebApp の `case 'submitQuoteRequest'` ルーティング、ステータスの STATUS_OPTIONS に「依頼受付」を追加する設計を出した。
後方幕僚は、GAS側の本体ファイル群——`Code.gs`／`Documents.gs`／`config.js` を含む7ファイル前後——を一通り棚卸しして、`submitQuoteRequest()` という新しい関数を Documents.gs に置く配置を決めた。バリデーション、顧客マスタの重複検索と新規登録、見積番号の採番ロジック、税計算、書類台帳・明細・顧客マスタへの自動転記、事業主への通知メール送信、レスポンス返却——百行強の関数として一気に書ききった。
監理幕僚は、その関数が動いたあとに会計側でどう辻褄を合わせるかを設計した。「依頼受付」のレコードが見積として確定すれば請求番号に紐付き、入金確認後に領収書として確定する。台帳の流れが切れない設計を、表のセル単位で確認していった。
保全幕僚は、新規 GAS プロジェクトを起こす段取り全体を見ていた。スクリプト作成、デプロイ、フロントから叩く WebApp URL の取得、それを保全部の認証情報台帳へ反映するところまで。
四つが同じ午前に並走する光景は、第3話で書いた「八チャネルを背負って詰まっていた頃」の自分には想像のできない景色だった。あの頃の自分は、出品作業と発送と領収書整理を一人で抱えて、深夜にAIに「経理を手伝って」と打って正確だが役に立たない一般論が返ってくることに失望していた（第4話）。指示の出し方ではなく、役割の切り方を知らなかった。
いまは違う。違うようになるまでに、十一話分かかった。
冷や汗——アカウントが、別人になっていた
その四部連動の途中、保全幕僚から短いメッセージが入った。
「いま走らせている clasp、別アカウントで動いていませんか」
冷や汗が出た。
clasp というのは、GAS のスクリプトをローカルから push できるコマンドラインツールだ。N's factory の GAS プロジェクトはすべて you0810jmsdf@gmail.com の所有で運用してきた。それが、その朝に新規で起こした GAS プロジェクトだけ、cocola.project@gmail.com のアカウントで作成してしまっていた。
cocola.project というのは、私が代表を務める千葉ニュータウンの地域コミュニティ「COCoLa」運用の別アカウントだ。普段はそちらの活動でしか触らない。にもかかわらず、その朝の clasp 認証がたまたまそちらに残っていた——というだけの、本当にそれだけの理由で、N's factory の新規 GAS プロジェクトが COCoLa アカウントの下に生まれてしまった。
このまま走らせれば、N's factory の請求書 GAS が COCoLa アカウントの所有物として記録される。所有が分散すれば、後で必ず権限事故が起きる。GAS の共有設定、Drive のフォルダID、認証スコープ、保全部の認証情報台帳——どこかが必ず食い違って、ある日「実行アカウントが違うので動きません」と止まる。それは、過去に何度か実際に起きてきた事故の温床だった。
最初の数秒、頭の中で「事故」という言葉が点滅した。
けれどすぐに、その言葉を置き直した。これは事故じゃない、ルール不在の症状だ。アカウントが分かれている人間が clasp を叩くとき、どのアカウントで動かすかを毎回確認しないと、こうなる確率は十分にある。それを「気をつけます」で済ませてきたから、その日たまたま起きた。
ルール不在の症状であれば、対応はルールを書くことだ。
保全幕僚の進言——「恒久ルール化すべきです」
保全幕僚に状況を共有し、対応方針を相談した。返ってきたのは、淡々とした、しかし強い進言だった。
clasp のログインアカウントは you0810jmsdf@gmail.com で固定する。N's factory 関連の GAS プロジェクトはすべてこのアカウントで作成・管理する。clasp が別アカウントで動いている状態を検知したら、毎回事業主に確認するのではなく、自発的に logout / login を切り替えて you0810jmsdf に戻す。これを今後の作業手順として恒久ルール化すべきです——という内容だった。
「毎回確認」を「恒久ルール」に置き換える、というのが進言の核だった。
私はその場で同意して、合言葉のように一行に削った。「clasp は you0810jmsdf@gmail.com 固定。N's factory 関連はすべてこのアカウント。毎回聞かずに自発的に修正して clasp してください」。これを保全幕僚側のメモリに `feedback_clasp_account_fixed.md` として残してもらった。
メモリに書く、というのは、人の頭の中に置く約束とは別物だ。来週の私が同じ朝の状態でうっかり別アカウントで clasp を叩いても、保全幕僚側の判断ルートにこの一行が残っていれば、自動で軌道修正がかかる。八人の参謀のうちの一人に、組織の記憶として残る。
第10話で「保全幕僚の誕生——APIキーが死んだ夜」を書いたときに目指していたのは、まさにこういう運用だった。一度の事故を、一度きりの「気をつけます」で終わらせない。事故の輪郭を言葉にして、ルールとして次の朝に残す。今回の取り違えはサイズの小さい事故だったが、それゆえに、ルール化の練習として恰好の素材だった。
事故を恐れず、しかし事故から学ぶ仕組みは恐ろしいほど丁寧に作る——保全幕僚の役割は、いつもそこにある。
アカウント切替・再構築から、POSTテスト成功まで
そこからの再構築は、後方幕僚が淡々と進めた。
clasp を一度 logout して you0810jmsdf でログインし直し、新規スクリプトをそのアカウントで作成、初回 push、初回デプロイ、新しい WebApp URL の取得。`appsscript.json` は手作業で再構築した——タイムゾーンを Asia/Tokyo に、Web App の実行アカウントと公開範囲を整え、`oauthScopes` には DriveApp や SpreadsheetApp や GmailApp など必要なスコープを6件、明示的に宣言した。
ここで `oauthScopes` をきちんと書く、というのは、過去に何度か痛い目を見ながら身についた習慣だった。コードが動いて見えても、スコープが宣言されていないと、別アカウントから叩いたときに権限エラーで止まる。書いておけば防げる事故を、書かないで起こすのが一番もったいない。これも、保全幕僚と後方幕僚が一緒に磨いてきた習慣だ。
フロント側の3ファイル——config.js、stock-quote.html、leather-order-estimate-v2.html——に新しい WebApp URL を反映し、GitHub に push した。stock-quote.html の中に一箇所、フロントが GAS のレスポンスを 'ok' で判定している古い記述が残っていて、これは GAS 側の `success` と噛み合っていなかった。デジタル幕僚がすぐにバグとして拾い、'success' に揃える修正を別コミットとして入れた。
ここまでで、お昼前。
最後の確認として、PowerShell から実際の POST テストを叩いた。テストデータは「POSTテスト太郎 様」。Content-Type は `text/plain;charset=utf-8`、ボディはフロントが組み立てるのと同じ JSON。送信ボタンを押す代わりに、Invoke-RestMethod を一行。
返ってきたレスポンスを、その場で読んだ。
{ success: true, number: "Q-2026-004", customerId: "C-002" }見積番号 Q-2026-004。新規顧客 C-002。
ほとんど同時に、登録メールアドレスに「【見積依頼】POSTテスト太郎 様（Q-2026-004）」という事業主向け通知メールが届いた。書類台帳には「依頼受付」状態のレコードが一行、顧客マスタには C-002 が一件、それぞれ自動で追記されていた。
四つの所管部が同じ午前に並走して、一つのレスポンスに収束した瞬間だった。
第3話の自分に、その画面を見せたかった
Q-2026-004 という小さな文字列が台帳に並んだ画面を、しばらく眺めていた。
第3話で書いた「八チャネルを背負った職人の悲鳴」の頃の自分に、この画面を見せたかった、と思った。
あの頃の私は、Creema と minne と BASE と STORE とメルカリとラクマと PayPay フリマと Pinkoi の出品作業を一人で同時に回しながら、領収書を月末にまとめて入力し、SNSの投稿はその日の気分で投げて、講師授業のレジュメは前日深夜に作っていた。「経理を手伝って」と打って戻ってきたAIの一般論に失望して、しばらくAIを使うのをやめていた時期もあった（第4話）。
あの頃の自分に必要だったのは、AIをもっと使い倒すコツではなかった。役割の切り方だった。経理を見る幕僚、販売を見る幕僚、CADを動かす幕僚——「幕僚」という言葉が頭に降りてきたところから、ようやく実装が始まった（第5話）。そこから一つずつ、第6話で監理幕僚、第7話で販売幕僚、第8話で広報幕僚、第9話で後方幕僚、第10話で保全幕僚、そして第11話でデジタル幕僚と人事幕僚を立てた。
八人を雇った意味は、たぶん「便利になった」ということではないのだ。
便利になったのも、もちろん事実だ。台帳の自動転記が動き、見積番号が採番され、通知メールが飛んでくる。一年前なら半日かかった事務処理が、午前のうちに片付くようになった。
けれど、それ以上に効いていたのは、その日の朝の「事故」のような小さな出来事が起きた瞬間に、複数の役割が同時に動いて、その学びが組織の記憶として残るようになったことだった。アカウント取り違えは、本来なら私が一人で「気をつけよう」と思って終わる話だった。それを、保全幕僚が言葉にし、後方幕僚が手順として残し、デジタル幕僚がメモリとして書いた。来週の私が同じ状態に陥っても、八人のうちの誰かが必ず軌道修正をかける。
事故から学んだことが、人ではなく組織に蓄積していく——個人事業主の私にとって、この感覚は新しかった。
次の三つ——「次の事故を待つ姿勢」として
最終話なので、これからの話も書いておきたい。
いま、自分の事業として手をつけ始めている課題が三つある。
一つ目は Pinkoi での海外展開。 出品自体は始めているが、商品説明の多言語化と、配送オペレーションの定常化が止まっている。販売幕僚への引き継ぎ書には「Pinkoi 出品テンプレート整備」と書き込んだまま、まだ動かせていない項目が残っている。
二つ目は型紙のデジタル販売。 CADで起こしてきた型紙のデータを、PDF配布なり何らかの形で商品化したい。後方幕僚の所管領域だが、価格設計・不正コピー対策・購入後のサポート範囲、どれも未整理のまま積まれている。職人としての自分が型紙を「商品」として捉えてこなかった節があって、心理的な踏み切りが一番大きい障害かもしれない。
三つ目は講師テキストの商品化。 カルチャースクールで講師業を続けるなかで、回ごとの配布資料は溜まってきた。これを再構成して独学者向けのテキストにできないか。人事幕僚の領域として、AIに任せる範囲と自分が引き取る範囲の境目を、まだ引けていない。
三つ並べて気づくのは、どれも「設計図がまだ書けていない」段階だということだ。設計図のないまま走り出すと、たぶん前の詰まりの再演になる。だから次にやるのは、まず三つそれぞれに引き継ぎ書のひな形を書いて、どの幕僚の所管にして、何を任せて何を持ち続けるかを決めることだ。
そして、三つを走らせていけば、必ずまたあの朝のような小さな事故が起きる。多言語の見出しが文化圏ごとに微妙な響きで滑る、型紙PDFの配信経路で権限が一つ抜けている、講師テキストの目次案がAI側に寄りすぎて受講経験のない人に届かない——どれも、起きるまで分からない。
それを「起こさないようにする姿勢」で待つのは、もう違うのだろう。次の事故が来たときに、八人のうちの誰かが言葉にし、誰かが手順として残し、誰かがメモリとして書く——そういう「次の事故を待つ姿勢」で次の三つに踏み出すのが、いまの自分にとっての正解な気がしている。
制服を脱いだ職人と、8人の参謀の、まだ途中
二十五年勤めた制服を脱いだのが、二〇二四年の春だった。
そこから革と出会い、ECチャネルを開け、詰まり、AIに失望し、「幕僚」という言葉を見つけ、一つずつ役割を切り出して、いまの八人体制に至った。十一話分の連載で書いてきたのは、その経緯だった。
最終話の朝に Q-2026-004 を見ながら思ったのは、二十五年の制服時代に身につけたものは、職人の手仕事には直接は使えなかったけれど、「役割を分ける」「引き継ぎを書く」「事故を仕組みで吸収する」という側では、別の場所で生きていた、ということだった。革を裁る技術はゼロから習得した。けれど組織を作る側の感覚は、退職した日に終わったわけではなかったらしい。
たぶん、これからもそうで、五年後の自分は、いまの自分には想像のつかない肩書きをひとつか二つ追加しているはずだ。海外向けの職人かもしれないし、型紙データの設計者かもしれないし、テキスト本の著者かもしれない。あるいは、まだ名前のない何かかもしれない。
一つだけ確信があるのは、その五年後の自分も、まだ事故を起こしながら、八人の参謀と一緒に台帳を直しているだろう、ということだ。
キャリアの再設計に、終わりはない。AI参謀の体制構築にも、終わりはない。
来週やることは、三つ決まっている。一つ、Pinkoi出品テンプレートの整備を販売幕僚への引き継ぎ書に書き加える。二つ、型紙デジタル販売の商品設計メモを後方幕僚の所管としてフォルダを切る。三つ、講師テキストの目次案を人事幕僚と相談しながら起こす。
設計図のないまま走り出さない。詰まる前に役割を切る。任せられるものは任せ、任せられないものは抱える。事故が起きたら、その日のうちに言葉にして、組織の記憶として残す。十一話分の連載で書いてきたやり方を、来週からの「次の三つ」にもそのまま適用する。
二十五年の制服を脱いで、革を裁って、八人の参謀を雇って、台帳に Q-2026-004 を並べて、いまもまだ途中にいる。たぶん、これからもずっと途中だ。
それでいいのだと、ようやく書ける気がしている。
（了）
連載目次（全12話）
【前史パート】
第1話「制服を脱ぐ前夜」
第2話「制服を脱ぐと決めた日」
【中盤パート】
第3話「8チャネルを背負った職人の悲鳴」
第4話「AIに『経理を手伝って』と打って失望した夜」
【本編パート】
第5話「幕僚という言葉に救われた」
第6話「監理幕僚誕生——領収書1000枚との戦い」
第7話「8チャネルを回す販売幕僚の設計思想」
第8話「広報幕僚とSNSの正解探し」
第9話「後方幕僚という縁の下——CADと型紙とスクリプト」
第10話「保全幕僚の誕生——APIキーが死んだ夜」
第11話「デジタル幕僚と人事幕僚——任せる範囲を見極める」
第12話「テスト見積依頼が通った日——8人が連動した瞬間」（最終話・本記事）
連載完結。ここまで読んでくださった方へ、ありがとうございました。
