土木系事務員が数量計算書をCoworkに頼んだら、527セルが壊れて、赤セル方式が生まれた。
これは『Excel役所様式格闘記』全5話＋番外編の第2話。
土木中小企業の事務員が、役所提出書類のExcel作業をAIに任せようとして、何度も壊して何度も学んだ記録のシリーズです。
第2話は、別の戦場で同じ罠にはまり、そこから「赤セル方式」が生まれるまでの記録。
第1話の最後に、自分はこう書いた。
「openpyxlは、既存の複雑なExcelには向かない。これだけは、確かなことだった。」
その撤退の数日後、同じopenpyxlで、自分は別の戦場に立っていた。
毎月のExcelではなく、工事ごとに作る数量計算書のほうだった。
ここで一つ、書いておきたいことがある。
このあと、Coworkと、Claude.aiのチャットの二つが何度も出てくる。
Coworkは実際に手を動かしてファイルを触ってくれる側、Claude.aiのチャットは状況を見せて方針を一緒に考えてくれる側、と自分の中では分けて使っていた。
どちらに何を頼んだのか、本文ではなるべく書き分けていく。
「自分の説明が悪かったんだろうな」と、その日の自分は思っていた
2026年3月5日、お昼を過ぎた時間帯。
Coworkに、ある水道工事の数量計算を任せていた。
当初設計の数量計算書一式を、施工後の値に書き換えるだけのつもりだった。
ところが朝から続けても、同じところで何度も止まる。引き継ぎを書かせても、次のセッションで戻ってこられない。
並行して、Coworkには、CAD図面から本管の管材料を読み取らせる作業もやらせていた。
そちらは進んでいた。
だから全部がだめなわけではなく、数量計算の方だけがほどけずにいた。
夕方前、会社のPCでClaude.aiのチャットを開いた。
「どの様な計画が必要だったと思いますか？」
正直なところ、上手くいかなかったのは自分のやり方か説明の仕方が悪かったんだろうな、と思っていた。
2か月前のことなので記憶は朧気だが、その時はそんな風に感じていたと思う。
返ってきた答えは3つだった。
「最初に地図を作る」「作業を小さく区切る」「引き継ぎを最後ではなく常にやらせる」
ファイル量がコンテキストに対して多すぎた、というのが理由だった。
『なるほど』と読みながら、晩までに、もう一つ聞いた。
「最初の計画からプランモードで進めていたら違っていたか？」
返ってきたのは、「プランモードでも回避困難。Claude Codeなら違う」という答えだった。
当時はその意味の半分も分かっていなかった。
ファイル4本、シート82枚、数式は6万。まず地図から始めた
翌朝、3提案のうち最初の「地図を作る」から取りかかった。
ここから先は、Coworkに動いてもらう番だった。
その数量計算書は、4つのExcelブックでできている。これらは発注者（役所）が当初設計時に使ったもので、自分はそれを竣工時の内容や数値に直して提出する。このようなExcelブックを使って、精算に必要な数量を求めていく、と思っていただければ十分だ。名称は土木業界の慣例なので、深く意味を取らなくて構わない。
合計82シート。
特に土工計算書27シートには、6万を超える数式セルが組み込まれていた。
これを丸裸にする方針は、自分から提案した。
「直打ちのセルをピックアップして、その上と左の見出しを取る。そうすれば手入力すべき項目が分かる」
Coworkに、4ファイルを順番に投げていく。
49シートと27シートはさすがに重く、Coworkはサブエージェントを並列で動かしながら、5〜10シートずつ処理していった。
出力はシートごとにテキストで分割され、合計27ファイル分の解析結果になった。
最後に、Coworkはこう集約してきた。
「入力の起点は『配管図(詳細図)』と『横断図』の2つに集約されます」
4ファイル、82シート、6万を超えるセルを、たった2枚の図面の見方に整理してきた答えだった。
「ありがとうございます。流石の解析力ですね！」
そう返した。本心だった。
給水集計表で、217個も色を塗ってきた
地図ができたあと、4ファイルのうち1ファイル目から順に手を入れていくことにした。
最初は給水集計表。2シートだけの、一番小さいブックだった。
1シート目は施工箇所ごとの数値を手入力するシート、2シート目はその合計を取る集計シートで、こちらは全部数式で動いている。
手で触るのは1シート目だけ。残りは触らない。
そのシートを開いて見ていた時、ふと、引っかかることがあった。
ただ、それは少し後ろの章で書く。今はまだ作業の入り口で、自分も結論を保留して先に進んだ。
入力箇所をCoworkに分かる形にしてもらう方針は、シンプルなはずだった。
「直打ちで入っているセルを、薄緑色で塗ってください」
返ってきたファイルでは、217個のセルが薄緑（#CCFFCC）で塗られていた。
開いて、すぐに『多すぎる』と感じた。
このシートで自分が入力するのは、施工箇所6箇所分の数値だけだ。
217個全部が手入力すべき場所のはずがない。
Coworkは、数式と直打ちの境界を、ここでも完全には判別しきれていなかった。
『これは反対だな』と思った。
「直打ちを判別して色を塗らせる」のではなく、「人間が先に色を塗っておいて、Coworkに読ませる」方が確実だ。
こちらから入力箇所を指定すれば、解釈の余地がなくなる。
このとき思いついた発想は、まだ言葉にはなっていなかった。
ただ、後に「赤セル方式」と呼ぶことになる方法の入り口は、この時に開いていた。
2ファイル目で、自分の提案を取り下げた
次は包括新数計。4シートあって、こちらは数式が一切入っていない。全部、手入力で埋めるブックだった。
給水集計表でCoworkにやらせた「直打ちセルに色を付ける」方式を、そのままもう一度流してみた。
ところが返ってきたファイルを見ると、おかしい。
管材の名前、見出し、施工区分、すべての文字セルが「直打ち」として薄緑色になっていた。
全部が手入力なのだから、全部が直打ち。色分けする意味がない。
『あ、これは無理やな』とすぐに分かった。
直打ちセルをピックアップする方式は、数式と手入力が混じっているシートでしか機能しない。
全部手入力のブックには通用しない。
「私の提案は無理そうだと判断した」
そうClaude.aiのチャットに返して、方針を切り替えた。
新方針はシンプルだった。
シートの中身そのものをCowork側で解析してもらって、どの数値を、どこから持ってきて、どこに入れるか、ひとつずつ確認しながら進める。
意味を理解した上で書き換える、という当たり前のやり方に戻した。
提案は、自分から取り下げる方が早かった。
うまくいかない方法に固執するより、別のやり方に切り替えた方が、結局は早く着く。
「図面の目はかげだん、入力の手はClaude」
数量計算には、配管図と横断図の読み取りが必要だった。
入力の起点はその2枚の図面に集約される、というのは地図作りの段階で分かっていた。
ならばこの図面読み取りもCoworkに任せれば、入力まで自動化できるのではないか。
正直なところ、ここはいけると思っていた。
ただ、Coworkに丸ごと渡す前に、まずはClaude.aiのチャット側で、図面のPDFをどこまで読み取れるか試してみることにした。
A1サイズのPDFをチャットに投げてみた。
返ってきた答えは「画像が大きすぎる」だった。
Claudeが画像として処理できる解像度には上限がある。A1はその上限を超えていた。
PDFを分割し、解像度を落としながら、何度か試した。
読めるようには、なった。なったのだが、中身が怪しい。
「(工)」と書かれている箇所を「(エ)」と読み間違えていたり、別管の土被り値を取り違えていたり、明らかに読めるはずの数値を見落としていたり。
頻度が低ければ修正で済むが、図面読み取りでは数値を一つ間違えるだけで集計が狂う。
ちょっと残念だった。
ここがClaude側で読めるなら、図面からExcelへの自動化は大きく進む。
逆に、ここが読めないなら、自動化の射程はぐっと狭くなる。
それに、数値を自分が図面から読み取ってチャットに渡すだけなら、その手間でExcelに直接打っても変わらない。
わざわざClaudeを通す意味がなくなってしまう。
役割分担を切り替えた。
図面の目は自分が持つ。入力の手はClaudeに任せる。
図面から自分が拾った数値をCoworkに渡し、Excelへの転記はCoworkが行う。
ここから先、図面解析の話は出てこなくなった。
「2041件のエラーが見つかりました」とCoworkから報告が来た
給水集計表のあとは、いよいよ土工計算書だった。
27シート、約6万の数式セル。一番大きく、一番手強いブックだ。
Coworkに、当初設計のファイルを開かせて、施工後の値に書き換える作業を進めた。
作業自体は、最初のうちは進んでいるように見えていた。
しばらくして、Coworkから報告が返ってきた。
2041件のエラーが見つかりました。
『また、来たか』と思った。
内訳はこうだった。
DBCS関数の小文字化（527セル）：DBCSは半角文字を全角に変換するExcel固有の関数で、役所書類で全角に揃えたい場面によく使う。これが、openpyxlがファイルを保存するときに小文字の「dbcs」に書き換えられていた
`#REF!` の小文字化：名前付き範囲の中で、参照エラーを表す `#REF!` が `#ref!` に変わっていた
給水管布設集計の数式消失（66セル）：データを入力した行より下の空き行で、もともと入っていた計算式が消えていた
キャッシュ残存：書き換える前の古いキャッシュが、ファイル内に残ったままになっていた
エラーの直接の原因になっていたのは、527と66、合わせて600セル弱だった。
残りの1500件弱は、その600セル弱を参照していた数式が、参照先の壊れに引きずられて連鎖的にエラーを返していたものだった。元を断たれて、芋づる式に倒れていった、という構図だ。
ファイルそのものは開けるが、開くたびに修復ダイアログが出る。
名前付き範囲を Excel が直そうとして、結局直しきれない。
『やっぱりアカンのね』と思った。
怒りも絶望もなく、すっと出てきた一言だった。
第1話の最後に「openpyxlは、既存の複雑なExcelには向かない」と書いた、あれが、現実として降りてきた感じだった。
『これはもうしょうがない、こういう仕様なんだ』と納得するしかなかった。
Coworkからは、方針切り替えの提案が来た。
openpyxlを使わずに、Excelファイルの中身を直接書き換える方法に切り替えます。これなら名前付き範囲もDBCSも壊れません。
「では、それでお願いします」と返した。
試してみる前から、その判断が正解だろうな、とは思っていた。
読み取りはopenpyxl、書き込みはVBA。そこで線を引いた
土工計算書は、openpyxlを通さない別の手で何とか復旧した。
ただ、この後にはまだ、49シートの材料計算書が残っている。
openpyxlで同じことを繰り返したら、また同じ事故が起きる。
そこで、自分の中で線を引くことにした。
openpyxlは読み取りに使う。書き込みはVBAでやる。
読み取りなら、ファイルを開いて中身を見るだけなので壊しようがない。
書き込みは、Excelが正しく解釈できる形で書き戻す手段、つまりVBAに任せる。
教訓は一行に短くまとめて、自分用のメモに残した。
直す側じゃなくて、壊さないようにする側に運用を寄せる、という線引きだった。
ついでに、Claude.aiのチャットに一つ提案を投げてみた。
「アドインに『ここの数値を変えて』というプロンプトを書いてもらうのは無理ですか？」
返ってきたのは「可能です」という答えだった。
入力すべき数値の一覧を作って、それを Excel アドインに渡せば、書き込みは Excel 側でやってくれる。
読み取りはCowork、書き込みは Excel のアドイン、という分担も成立する。
ただ、その話が本格的に動き出すのは、もう少し先のことになる。
いまは、目の前の49シートを終わらせるのが先だった。
土曜の夜、リビングのiPadで、ちょっと先に進めるかもしれないと思った
土曜日。自宅のリビングだった。
少し肌寒さを感じながら、iPadを持ってソファに座り、ネットとSNSを行ったり来たりしていた。
休みの日はだいたいこの過ごし方になっている。Claudeの新しい使い方や、誰かが試した工夫を見て回るのが、ちょっとした娯楽になっていた。
嫁も同じソファの近くにいる。それぞれが、それぞれの時間を持っているだけで、何かを話すわけではない。
平日の続きを、頭の中で薄く考えていた。
給水集計表で「人間が先に色を塗っておいて、Coworkに読ませた方が早い」と感じたこと。
土工計算書で「書き込みはVBAに任せたい」と線を引いたこと。
そういう断片を、順番に並べてみていた。
並べていたら、繋がっていた。
人間が、入力したい場所のセルを赤色で塗る
Coworkが、その赤いセルの場所を読み取って、「ここに何を入れるか」のリストを作る
リストの内容を、VBAでExcelに書き戻す
書き戻したあとは、元のファイルと比較して、塗ってしまった赤色を元の背景色に戻す
『これでいけるな』ではなかった。
『ちょっと先に進めたかも』、それくらいの感じだった。
解決を見つけたわけではなく、行き詰まりの一部を緩める発想がひとつ見えた、という程度。
ただ、寝かせておくより、Claudeに壁打ちした方がいいと思った。
iPadからClaude.aiのチャットに、思いついた手順を投げた。
嫁には何も言っていない。
返事は早くて、「openpyxl＝読み取り専用、書き込みは全てVBAで統一」と整理して返ってきた。
ちょっと楽しみだな、と思った。
「無事成功しました。」が4回続いた
月曜日。週末の発想を実行に移す日になった。
まず、給水管②③④の管材を整理することから始めた。
自分が図面から読み取った管材データは18本分。これをCoworkに渡して、管材ごとにExcelのどのセルに入るかをマッピングしてもらう。
マッピングの結果は、今度はClaude.aiのチャットに渡して、VBAコードに書き起こしてもらう。
出てきたVBAをExcelに貼り付けて走らせるのは、自分の手元の作業だった。
役割分担はこうなった。
読み取り・マッピング：Cowork
VBAコード生成：Claude.aiのチャット
マクロ実行：自分（手元のExcel）
マクロ1：管材料計算表
3シート、17セルへの書き込み。
走らせてみたら、エラーなく完了した。
「無事成功しました。次のをお願いします」と返した。
マクロ2：管加工表
こちらは構造が個別すぎて、自動化に向かないと判断。手作業で済ませた。
マクロ3：材料明細書
5シート、58セルへの書き込み。
これも一発で動いた。
「無事成功しました。次のをお願いします」を、もう一度返した。
マクロ4：包括新数計
ここで、土曜の夜に思いついた赤セル方式を、初めて正式に試した。
自分が、入力するセルを Excel 上で全部赤に塗る。
そのファイルをCoworkに渡し、赤いセルの位置と、「上の見出し・左の見出し」を読み取ってもらう。
返ってきたのは、どの値をどこに書き込むか、という指示の一覧表だった。
これをClaude.aiのチャットに渡してVBAに起こしてもらい、手元のExcelで走らせた。
2シート、13セル。これも一発で動いた。
「無事成功しました。次のをお願いします」と返した。
最後に背景色復元マクロを作った。
当初設計のファイルと、自分が赤を塗ったファイルを両方開いて、セルごとに背景色を比較する。
違うところを見つけたら、当初設計の色に戻す。
人間が塗った赤は、Excelの上から消える。
作業の痕跡を残さないための仕上げだった。
（このVBAも、Claude.aiのチャットに書いてもらった。）
これも一発で動いた。「無事成功しました。」と返した。
途中、Claude.aiのチャットから一つ確認が来た。
役所からもらった元データには、今回の接合替では使わないシートが沢山あって、シート名の頭に「不要→」と書かれていた。その先のシートにある数値は、ゼロにしておかないといけないですか、という問い合わせだった。
「正直一つ一つ追わないと分からないので、そのままで行きましょう。役所に確認して貰いますwww」
笑いながら書いた。「不要」と書いてある先のシートまで一つずつ見に行って検算する性質の作業ではない。そこは触らずに、役所側で見てもらえばいい。それだけの話だった。
「VBAで出来るならその方が良い」
マクロ4本が動き終わったあと、Claude.aiのチャットに、自分はこう書いた。
VBAで出来るならその方が良いです。一度壊れてしまうと、直しても本当に直ったのかという疑念は残りますから。
これは、土工計算書でDBCSが小文字化されたあとに自分の中でずっと残っていた感覚だった。
壊れた経験は、修復しても消えない。
別の手で直してもらって、エラー数はゼロになった。それでも、もう一度同じファイルをopenpyxlに通したいかと聞かれれば、答えはNoだった。
直す技術ではなく、壊さない手順を選ぶ。
これが、自分なりに辿り着いた線引きだった。
結局、あの表は、使わなかった
マクロ4本が動き、背景色も元通りに戻り、一区切りがついた。あとはCADデータに一覧表を貼り付けて図面を完成させ、データと図面を役所に提出するだけだ。
ここで、章3で書いた「ふと引っかかったこと」が戻ってくる。
給水集計表を最初に開いて、自分が今やろうとしている作業を眺めた、あの場面の話だ。
第1話の冒頭で、CADに貼り付けられた表をPDFから復元してもらった話を書いた。
あの一覧表のことだ。
あの時のCoworkは、ただ復元しただけではなかった。
図面の番号と表の数値の紐付けを自分で読み解き、その後の竣工版への修正まで仕上げ、最後には「こういう毎回ちょっとずつ違う作業のために、作業工程をマークダウンで残しておくといい」と提案までしてくれた。
自分は「時間の節約になりました」と返した。本心だった。
ところが。
給水集計表を最初に開いた瞬間、気付いてしまった。
『あちゃ〜、ここに貼り付ける表がそのまま有るやん』
『やって貰わんでも良かった作業を、お願いしてしまった』
『ちゃんと探してからお願いしたら良かった』
『もうどうしようもないけど』
『せめて使うのは、作って貰った方にしようか？』
『いやいや、同じように作って貰ったけど、貼り付けるのはやっぱり役所のフォーマットの方よね』
『あぁ、やっちゃったなぁ』
最初に役所提供のフォーマットを探した時は、ザッと見ただけで見つけられなかった。
だからCADから復元してもらった。
ところが、数量計算書の中身を上から下まで見ていったら、貼り付け先のはずのフォーマットがそこに、最初から、ある。
順番が逆だった。
本当は、最後に役所提供のフォーマットに数値を貼って、それをCADに戻す。
それが本来の順序だった。
最終的にCADに残ったのは、役所提供のフォーマットの方だった。
Coworkに作ってもらったあの一覧表は、今もSSDの肥やしになっている。
消えてはいない。ただ、最後の最後では、使われずに終わった。
第2話で、気づきは3つだった。
道具は、場面で分ける。openpyxlは読み取り、VBAは書き込み。一つの道具で全部やろうとすると、得意でないところで壊す
赤セル方式は、人間とAIの合図のシステムだった。人が色を塗り、AIが読み、AIが書き、AIが色を戻す
最初に作ってもらうものと、最後に貼るものを取り違えると、丁寧な仕事ほど無駄になる。任せる前に、作業の順番だけは自分で決める
次に試すこと
身につけた役割分担と赤セル方式を、本管側の数量計算で本格運用してみる。
接合替で立ったものが、より大きな対象でも立つかどうかを試す番だった。
撤退から始まったシリーズが、ここで初めて「動いた」記録に変わった。
動いたといっても、壊さない手順を選んだだけ、なのかもしれないが。
次回：同じ工事の本管側。桁が一つ違った話
参考
2026年5月時点の記録です。
