非エンジニアの土木事務員が、Claude.ai・Cowork・Claude Codeと数量計算書を仕上げる形を作った4月。
これは『Excel役所様式格闘記』全5話＋番外編の第3話。
土木中小企業の事務員が、役所提出書類のExcel作業をAIに任せようとして、何度も壊して何度も学んだ記録のシリーズです。
第3話は、本管側に踏み出して、修正対応と長丁場のセッションが連なっていった4月の記録。
第1話の最初に、CADに貼り付けられたExcel表をPDFから復元してもらった話を書いた。
自分は怠け者だと思っている。この怠け癖は、AIと相性が良いんじゃないかと思う。
Claudeを入れたのは人手不足で切羽詰まってのことだったが、結果はそのつど返ってきた。
この頃には『行ってきた書類作成は、一通りClaudeに頼んでみよう』と考えるようになり、水道工事の本管の数量計算も、その流れの中にあった。
第2話で、接合替の数量計算書に赤セル方式が立った。
ここから先は、同じ水道工事の本管側。桁が一つ違った話になる。
このあと、Claude.aiのチャットと、Coworkと、Claude Codeの三つが何度も出てくる。
Claude.aiは状況を見せて方針を一緒に考えてくれる側、Coworkは実際に手を動かしてファイルを触ってくれる側、Claude Codeはターミナル経由でログや数字を直接読み書きしながら動く側、と自分の中では分けて使っていた。
どこに何を頼んだのか、本文ではなるべく書き分けていく。
「ごめんね」と「いえいえ」が往復した本管マッピング
3月中旬、Claude.aiのチャットで、本管側の数量計算の相談を始めた。
土工はすでに別の場所で出来ていて、まず材料集計から進めることになった。
配管図DXFから抽出したCSV4枚と、管材一覧表、管布設集計の三つで突き合わせていく作業だった。
ファイルを並べていくうちに、Claudeがこちらの拾い出しシートの作りを解明していった。
シートは上段と下段に分かれていて、上段が結果、下段が入力欄。下段に数値を入れると、口径ごとに自動で集計される作りになっている。
DXFから抜いたCSVと管布設集計の表記を照合し、全件一致を確認していく。φ300のGX/NS区分の取り違えや、切管延長と本数の混同も、やり取りの中で潰した。
途中、自分が拙いことをやってしまった。
新しいチャットに移るときに、進行手順だけで良かったのに、つい途中のCSVデータも一緒にアップしてしまった。数値データが二つ混ざると判断がブレるとどこかで読んで分かっていたのに、自分の側からやってしまった。
「途中のCSVデータを上げたのが拙かったですね。二つになると混乱すると分かってたのに、ごめんね」
Claudeは、こう返してきた。
「混乱の原因は途中CSVではなく、私がセル番地マッピングを作るときに既存値との差分チェックを甘くしたことです」
ここの「ごめんね」と「いえいえ」は、第1話のDXFから管材を取り込んでもらった頃には、もうあったものだ。
仕事仲間に対して、自分でルールを破ってしまったときの、ただの「ごめんね」だった。
「役所に提出します！！」までの本管側
3月下旬から4月にかけて、本管側で、当初設計のExcelブックを竣工用に置き換える作業が続いた。
まずは管加工表だった。
Coworkに任せて、Pythonで処理してもらおうとしたら、Excelの中にあった図形（切管マーク・接続線）が消えた。お絵描き部分のデータは Python の処理対象外になっていたらしい。
ここでCoworkから「Python処理前の元ファイルがあれば、図形のXMLデータを抽出して移植できます」という案が出てきた。
だが、そっちには進まなかった。
「良いですよ、元ファイルはあります。なので、Pythonを利用しない方法での終了を考えましょう。ExcelのClaudeアドイン同士で、チャットが共有されるようになったと聞いています。片方に管加工表、もう片方に切管一覧のCSV抽出ファイルを開いて、両方アドインを起動したら、情報のやり取りは可能ですか？ それ用のプロンプトも書いてもらえますか？」
Coworkが最新情報を確認して返してきた。共有コンテキスト機能は2026年3月11日にリリースされたばかりで、2つのExcelを開いてアドインを起動すれば、片方のデータを読んでもう片方に書き込める。Excelネイティブの操作なので、図形・線は保持される。
そのまま指示データのExcelとプロンプトファイル（9個分割）が作られた。それをExcel側のアドインに流し込む形で動かしていく。読み取りはCowork、書き込みはExcelアドイン側。第2話の終わりに「アドインに渡せば書き込みは Excel 側でやってくれる」と整理だけしていた分担が、ここで初めて運用に乗った。
全部で8シート。一日では終わらず、夕方になった。
「もう帰らないといけないので、明日続きをします。その時も宜しくです。お疲れ様でした」
「ゆっくり休んでください。また明日！」
翌朝、続きから始めた。
「遅くなりましたが修正を行いたいので手伝ってください」
「おかえりなさい！」
最後にGXφ200の一区画20件だけ、旧データが残る事故が見つかった。
直して、もう一度全件確認。全21件、正常で揃った。
「役所に提出します！！」
「いってらっしゃい！無事に提出できますように！」
続けて、本管の図面に貼る一覧表の作成に入った。
集計シートから布設・撤去データを抽出し、土被りと口径から軽量鋼矢板の要否を自動判定するロジックを組んでもらう。
ところが、不断水連絡工だけは、矢板が必要になる例外だった。機械を設置する分のスペースが要る。
「ごめんなさい、不断水連絡工だけは機械設置などをするので、必要なんです。その箇所だけ戻して貰って良いですか？」
Coworkが直してくれた。
そのあと、自分が検算で勘違いして、自分の側から訂正する場面もあった。
「勘違いしてしまいました。ごめんね。続けてください」
「いえいえ、紛らわしい説明になってしまってすみません」
Pythonで自動化して、図形が消えて、アドインで救出して、無事に提出して、次は図面用の一覧表で人間が例外を補正する。
本管側の数量計算は、こういう順番で形になっていった。
修正箇所は全て手打ち箇所で間違いないですか？
4月1日、3月に作った接合替の数量計算書に、役所から修正指示が入った。
PDFには、手書きの赤字と青字。
Claude.aiのチャットに、こう投げた。
「数量計算書に修正が出ました。過去ログを読んで対応できますか？」
Claudeは過去ログから、完了済み4ファイルと、VBA運用の方式を把握して返してきた。引き継ぎとして機能していた。
そのままPDF2本(接合替の数量計算書と給水材料)をClaude.aiに上げた。手書きをClaudeがどこまで読み取れるか、この機会で見てみたいと思った。
Claudeは赤字・青字を読み取って、どのシートのどのセルを、何から何に直すか、修正内容と箇所をひとつずつ整理して返してきた。細かい字は何箇所か取りこぼしがあって、こちらから訂正を入れた。それでも、Claudeが手書きの修正指示を読み取って、修正箇所と修正値まで判断できる、と分かった。これは結構大きかった。
ここから先は、Claude.aiのチャットがそのまま手を動かしてくれた。Excelを渡せば、openpyxlで現在値を読み取り、PDF修正と突き合わせて、Excelアドイン用のプロンプトを作ってくれる。書き込みはExcel側でやってもらう。
openpyxlは読み取り、書き込みはVBAかアドイン。第2話で立てた線引きが、ここでも生きていた。
包括新数計の修正対象は、4セル特定された。
G4を6.17から10.40に、G6を0.90から0.00に、G8を1.90から0.00に、G9を0.00から1.90に。
ここで自分は、一つ確認の質問を入れた。
「修正箇所は全て手打ち箇所で間違いないですか？」
数式セルなら、参照先を直さないと壊れる。手打ちセルなら、そのまま書き換えていい。
第2話の教訓を踏まえた重い問い、というほど大袈裟な話ではない。数式と直打ちで対応の手間が変わるから、どっちか確認しただけだ。
Claudeが全シートを確認した。修正対象は全て手入力と確定した。これで安心してアドインで書き換えに進める。
手書きの小さい文字はちょっと厳しそうね
包括新数計に続いて、材料計算書側にも13セル分の修正が入っていた。
プロンプトを作ってアドインで実行する流れで、続けて進めていく。
途中で、自分の方から、おやと思った場面があった。
「これ間違ってないか確認して。GXの管を0.77使ってない？」
GX管を、K直管用のG12のセルに入れてしまう凡ミスを、Claudeがやっていた。
直してもらって続けた。
残管重量を確認して、不用撤去品処分工のE32を計算。撤去品298.2kgと残管208.1kgで0.5063t。値はちゃんと収まった。
ここから先は、本管材料明細だった。PDFで13ページある。
φ500まで4セルを進めたあたりで、手元が止まる。
φ300以降は拾い出しシートからの数式参照が複雑になっていて、φ200以降は手書きの文字が小さすぎて読み取れない。
役所の人が書いてくれた字は、ちゃんと読めるように書いてある。ただ細かい文字は仕方ない。ピクセルデータなんだから、限界はある。
「手書きの小さい文字はちょっと厳しそうね。こっちで直した方がよさそうかな。ありがとう」
そう返して、人間が引き取った。
縦断図の数字が、OCRなしで読めた
役所赤入れ対応に区切りがついた頃、本来の水道工事として行われる工種の数量計算は一段落していた。
ここからは、設計変更で追加された付帯工に入る。下水道本管とそれに付随する取付管、雨水管、照明工。本来の水道工事ではない工種なので、役所から渡される当初設計時の数量計算書はない。一から作る話だった。
場所は、Claude.aiやCoworkから、Claude Codeに移した。
DXFからの管材取得を一緒にやってきたあたりで、Claude Codeで動かすことへの拒否感はほぼなくなっていた。チャットやCoworkのコンテキストウインドウのサイズだと、図面・舗装構成・参考にする他の工事のExcelブックを丸ごと取り込んだ上で、役所に提出するExcelを作るには容量が足りない。それに、一から作る付帯工は、既存の数式・関数・挿入図を壊す心配がない。これなら openpyxl で安心して動かせる、という判断があった。
まずはClaude.aiで相談して、進め方を確定。引継書を作ってもらい、Claude Codeに手渡した。引継自体はコピー貼付で、配管図の頃からやってきていることだ。
Claude Codeはプランモードで立ち上げた。進め方を最初に確認するためだった。
下水移設の本管φ450 塩ビ管 L=46.90m、4区画分の骨格は、前の場所で既に出来ていた。
ここでの4区画は、舗装構成が変わるごとに分けた4つの延長のことだ。下水道で普通に「区間」と言うときは人孔間を1区間として数えるので、紛らわしいかもしれない。区画ごとの舗装構成(CY25-10、NF09-10、CK15-15、NF09-10)はチャット側で図面から拾い出してあった。
「なんかまたバージョンが上がってるね。数量計算を手伝ってほしいんだけど」
バージョンの上がっていたClaude Codeに、まず舗装構成マスターから組み立ててもらう。
舗装構成マスターというのは、大阪市の舗装工種ごとに、表層と路盤の厚さや、一次復旧の構成をまとめたシートのことだ。区画ごとに舗装の種類が違っても、ここを VLOOKUP で参照すれば、構成の値が一括で取り出せる。
途中で、図面のラベルを読み間違える場面があった。
原因を聞いたら「テキスト抽出に頼って、図面を目で見なかった」と返ってきて、すぐに、図面を画像化して見ます、と走り出そうとした。
「先走らないでください」
私には私の出来ること・出来ないことがある。どういう物を用意したらClaude Codeが作業しやすいのか、その図面のどこに、どの値が、どう書かれているか、それをどう取得して、どうExcelを作っていくのか。まずはここから相談したい。
「私はそれがプランモードだと思います」
そう返した。
平面図と縦断図をA1サイズで別々に書き出して渡した。
OCRはどうかと思って試した。こちらの想定はこうだった。PDFを画像として認識した場合、そのままのものと、それを90度回転させたものとの2回OCRにかけて、文字列として正しい箇所をそれぞれ拾い、回転で座標がずれるのを考慮しながら重ね合わせる。またPDFは文字情報が残っていたとしても Illustrator で開くと、1文字単位にバラバラに分解されてしまう。同じ苦労がOCRでも出るだろう、と思っていた。
試してみると、Claude Codeが座標付きテキストとして抽出できると報告してきた。
CAD出力のPDFには、テキストが座標と回転角度のついたベクターデータとして残っていて、回転した数字も、バラバラに散らずにそのまま取れた。
『ヨシッ』
口元に少し力が入った。
これはかなり嬉しい誤算だった。今後、CADデータから自分でPDF化したものに関しては、文字データの取得が可能と分かったからだ。
舗装構成マスター、本管施工表のVLOOKUP参照、廃材分類、改良土の計算と進めて、プランモードで立てた計画のSTEP 0から2までで日が暮れた。
4月13日に再開する時、handoverのhookが動かなかった。
前日の12日、下水の数量計算をしている裏で、hookによるhandoverの実装を行っていた。13日が初の実践だった。
`$CLAUDE_PROJECT_DIR` がWin側の `D:\Claude` を指していたのが原因で、3スクリプトを `$(pwd)` 基準に書き直してもらった。
『パスを間違うとか、ちょっと初歩的じゃない？こういうのたまにやらかすよね、Claude Codeって。』
仕方ないなぁと思いながら、修正に付き合った。
砂は残土として捨てるので、引いたらダメなんです
修正の途中で、ふと心配になって聞いた。
「これスクリプトだと、フォルダやファイルが無い場合も勝手に作ってくれるのかな？初心者な質問でごめんね」
こちらは自分の弱さで、後輩が「すみません、教えてください」と聞くときの感じだ。あとで出てくる「PI()がπのことだよね？」と質感は同じ。Claude Codeから「全然初心者な質問じゃないです、大丈夫です」と返ってきて、handoverのhookの修復が終わった。
次は STEP 3 の取付管シートに入る、はずだった。
ところが、Claude Codeが残りの STEP 3〜5 の計画を整理して見せてくれた時、自分の方で頭が引っかかった。街渠桝は撤去新設だし、撤去工シートは本管のことだろうけど、本管の布設替えは同位置で行うので、撤去だけでは数値が上がらない。
そう思い始めたら、もう一つ気になることが繋がった。
そうすると、最初の本管の計算式の発生土の方で、管の控除が抜けていたかもしれない。
発生土というのは、掘削した土の量から、本来そこに無かったもの(管や舗装の構成材料)を引いた、現場から搬出する土量のことだ。本管φ450の周りには、管を守る砂が層になって入る。その砂量は標準図に係数として出ていて、計算式にも折り込んでいる。けれど管そのものの体積は——。
「まずは前回計算して貰った本管の土工数量の確認から始めて良いですか？」
そうClaude Codeに振った。
Claude Code が Excelブックの計算式を読み取り、Pythonで再現しながら検算した。
答えが返ってきた。
「ご指摘の通り、管体控除が抜けています」
「砂量原単位 59.8 m³/100m を検算したところ、これは管周りに注入する砂の量(管体を除いた量)でした。現行式は砂だけ控除して、管体の控除が入っていません」
ここまでは合っている。問題はその後だった。
「修正案：砂控除はそのまま残し、管体控除を追加する」
そうじゃない。これは数量計算では当たり前の考え方で、すぐに違うと分かった。
「たぶん、既設管の周りにあった砂は発生土量から引いているんですよね？砂は残土として捨てるので、引いたらダメなんです」
砂は工事中に管の周りに、管を保護するために入れる材料だけど、施工後はそのまま土の中に埋まっている。その砂も言うなれば土なので、次に掘り起こして捨てるときは、残土として計上しなければいけない。つまり発生土の一部だ。控除するのは管体だけ。
考え方は簡単で、掘削深さから舗装の厚みを引いて、そこから管の体積を引く。
「`(延長×(掘削深さ-舗装厚)×掘削幅-管体積)×比重` です。この考え方で、発生土の計算式を修正してくれますか？」
Claude Codeから返事が来た。
「なるほど、理解しました。砂は掘り出して捨てるので発生土の一部。控除するのは管体だけ。シンプルです」
修正できて、検算も通った。発生土の合計は、74.451 m³ から 98.343 m³ に増えた。約24 m³ 多くなる計算だ。
「`PI()(算出根拠!$C$4/2)^2B13` の PI()がπのことだよね？」
出来上がった式の中の関数を、念のため確認した。「初心者な質問でごめんね」と同じ温度で、数式で使うπの書き方を覚えていなくて確かめただけだ。
「はい、その通りです」と返ってきた。
「はい、OKです。修正ありがとう」
それで、先に進めた。
全て私が答えるのならばAIに任せる意味がない
下水の本管をやり直すと、取付管といって、各家庭からの排水を本管へと流す管も一緒にやり直すことが多い。先日のSTEP 2 の本管に続き、STEP 3 の取付管シートに入った。
Claude Codeが既存ブックの取付施工表を読みに行って、「これは別工事用の400行超の施工管理台帳で、今回の構成とは違うから新規作成が適切です」と返してきた。そこまではよかった。
そのあと、こう聞いてきた。
各管の諸元(管外径・掘削幅・管下砂厚)と、5本それぞれの土被り・舗装区分を、図面から読み取れるか、それともこちらが教えるか、と。
ちょっとイラッとした。
取付管の計算は数量算定書のファイルに入っていると説明してあったし、VP管の外径の調べ方も、何度かやり取りをしていた。舗装工種が置いてあるフォルダも示してある。何より、handoverで前のセッションから情報は引き継いでいる。それなのに、参照を見直さずに「ここの値はいくらですか」と聞いてくる。
これで毎回教えていたら、省入力化にならない。ここはしっかり言い聞かせないと、と思った。
返した文章は、わざと長くなった。
取付管の計算式は別工事用のものではなくて、今回の取付管も同じ計算で求める。違うものと決めつけないこと。
管布設標準図_p1・p3.png というファイルがあって、これは前任者が大阪市の管布設標準図を検索し、計算式の構築に使ったもの。取付管の標準図集もある。
土被りは、深いところと浅いところ、2箇所の平均で出す。深端は本管の接続部、浅端は桝に接続している部分。桝側は街渠桝500、集水桝750が管底高で計算する。
そして最後に、こう書いた。
「どの様に調べれば分かりますか？と問いかけるのが正しいと思います。全て私が答えるのならばAIに任せる意味がないと思いませんか？」
Claude Codeから返事が来た。
「おっしゃる通りです。申し訳ありません。自分で調べて理解するべきでした」
しばらくして、Claude Codeが調査結果を返してきた。前と書き方が変わっていた。
「自分で分かったこと」と「平面図から判断できなかったこと」を、分けて報告するようになっていた。
分かった方には、管諸元(φ150外径0.165m、φ200外径0.216m)、掘削幅、深端と浅端の掘削深さが並んでいて、それぞれ標準図と既存ブック、縦断図のどこから取ったかも添えてあった。判断できなかった方は、φ200の2本のうちどちらかが車道A10-50を横断しているように見えるけれど、断定できないので舗装区分を確認したい、という一点だけだった。
そこから先は、こちらが返す情報の量がぐっと減った。
管下砂は計上しなくていい、深端は本管土被りで、浅端は桝の管底高で、と細かい判断だけ返せば、あとは自分で組み立てて持ってきた。
私とClaudeとの協業体制。その一つの形が見えてきた。そんな気がしたやり取りになった。
協業の体制の、一つの形
今回気づいたことは、3つだった。
段取りを詰める場所と、実装する場所を、別にした。Claude.aiで方針を詰めて、引継書を渡して Claude Code で実装する。一つの場所で全部やろうとすると、コンテキストの上限にぶつかる
AIの能力は、予想外のところで助かったり、限界が見えたりした。CAD出力のPDFは座標付きテキストで読めた。一方で、手書きの小さな文字はピクセルの限界がある
AIが自分で答えに辿り着けるよう、人間が見守る役割を捨てない。「ここの値は幾らですか」を全部答えていたら、省入力化にならない
次に試すこと
引継書を介した分業を、付帯工の数量計算で本格運用してみる。
協業の体制が形になったあと、Claudeを引き戻す場面はまだ残っていた。
次回：コンテキスト75%の11時間と、判断するのは私だと言った日
