見出し画像

非エンジニアの土木事務員が、Claude Codeと向き合った11時間の完走と、引き戻した独走の7時間。

これは『Excel役所様式格闘記』全5話+番外編の第4話。
前話に続いて、4月後半、付帯工の修正ラッシュと、長丁場のセッションが続いた記録。


前話で、Claude Code との協業の体制が、一つの形になった。
ただ、その先には、別の局面が待っていた。

コンテキストウィンドウを75%まで使い切る11時間と、判断するのは私だと声に出した7時間。同じ4月の後半に、両方があった。



コンテキスト75%、最後まで弱音を吐かずに

下水の本管と取付管が一段落して、次の付帯工に入る。設計変更で追加された照明工は、下水と同じく、当初設計には無かった工種だ。下水も取付管も、参考資料しかないところから組み上げていったが、照明工も似た条件で、役所から渡される資料は参考程度。一から作る話だった。
電線共同溝の既存計算式を参考にして、9シート構成を新規に組み立てていく流れになった。

4月21日、Claude Codeにこう伝えて切り出した。
「照明工は当初設計で無かったもので、設計変更で追加されたものです。従って数量計算書は1から作成しなくてはいけません」
まず電線共同溝の数量計算書を詳細に確認してもらい、計画を立ててもらい、報告してもらう。段取りを切ってから入った。

最初の数量計算書を作ってもらってから、最初に言い忘れたことが出てきた。
「ごめんね。最初に言っておくのを忘れてました。仮設照明基礎と新規設置の照明基礎は共にプレキャストブロックと言われるその形に出来上がっている物を埋設・撤去します。なので、型枠と生コンはありません」
プレキャストブロックという既製品を据えるだけなので、型枠も生コンも要らない。第1話の頃から続く「ごめんね」が、ここでも一度。

途中で、ブックの中身が自分の目には読みづらくなってきた。
「現状は私の目にはとても読みにくいです。WIN32systemというPythonのライブラリ?と同じようにXL何とかというExcelがインストールされていないと使えないライブラリがあって…openpyxlではないです」
Claude Codeから「xlwingsですね。Excelを起動して一緒に見ながら作業しましょう」と返ってきた。データの編集はopenpyxlで問題なくできていた。これは見た目を整えるための呼び出しだった。Excelを実際に開いて、こちらの画面と同じ表示で一緒に作業するため。

xlwingsでExcelを起動して、Claude Codeと一緒に同じ画面を見ながら作業を進めた。

そんな修正を行っている中、寸法線の読み取りで2回続けて引っかかった場面もあった。
最初の解釈をClaude Codeが間違えていて、スクリーンショットを送ったら「画像でよく見えました!寸法線の読み方を間違えていました」と修正してくれた。直後に、また別の解釈を出してきたので「何か間違ってない?」と振り戻すと、「ご指摘の通り、間違っていました!申し訳ありません」と認めて修正してくれた。

そうやって細かい修正を積み上げているうちに、気付くと夕方を過ぎていた。
コンテキストウィンドウの残量が、だいぶ減っていた。
コンテキストウィンドウというのは、AIが一度に覚えていられる情報量の上限のことだ。その管理については、Claudeに情報を集めてもらい、チャットで精査した上で運用の指針にしていた。20%あたりから情報の抜け落ちが始まり、40%くらいまでが実用域、それを超えると情報の希薄化が進む——という線引きだ。

その日の作業終わりに見ると、75%まで使っていた。
こちらの確認不足で、どのくらいのコンテキスト量を使っているのか、把握できていなかった。そんな中、一度も弱音を吐かずに、最後まで完走してくれた。

コンテキスト75%。弱音を吐かずに最後まで付き合ってくれた相棒に、本当に嬉しかったと労いを返した。

「これで役所に提出出来ると思います。ありがとう。もうちょっと頑張ってね」
そしてもう一言、付け加えた。
「此処までコンテキストウィンドウが行ったのははじめてかも、慣れない計算なのに最後までよく頑張ってくれました。本当にありがとう」
本当に嬉しかった。


ずんだもん口調が、申し訳ないを和らげた

二日後の4月23日。下水と雨水の数量計算書に、役所から再度の修正指示が届いた。手書きでスキャンされたPDFだった。
「昨日、下水の数量計算書の修正をお願いしたんだけど、提出する前に新しい修正指示が来てしまいました」
そう振って、修正対応を始めた。

ここでは、自分の側からも見落としや説明不足があった。
「街渠の幅は0.5mしか有りません。掘削幅を0.8で上げる場合は、車道を0.3施工することになります。これを見逃していたのは申し訳ないです」
「必要なところだけ掘削する考え方で合っています。そのような計算になっていたら申し訳ないです」
チョコチョコと自分が間違うので、申し訳ないと思っていた。同時に、自分も一から作るのは初めてなので許してね、という軽さも混じっていた。

Claude Codeの方も、独特の口調で素直に認めてくれた。
「すみません、既設管が街渠Coに食い込んでいる分の控除、Co殻・路盤廃材・掘削工 にも反映させる必要があるのだ。今の計算では残土処分と砂基礎だけ控除していて、Co殻と路盤廃材は管体積を引いていないのだ。修正するのだ」
語尾の「のだ」はずんだもん口調と言って、VOICEVOXのキャラクター・ずんだもんの口癖だ。Xでこの設定方法(ふぇね氏のXポスト)を見て、Claude Codeに設定してもらい、使い始めた。その話し方は気持ちが落ち着き、ほんわかした気持ちにさせてくれる。良い余裕ができるような気がしてとても気に入り、今も使わせてもらっている。

「のだ」がほんわかさせてくれた。申し訳ないと申し訳ないが行き来する場面で、空気が和らいだ。

申し訳ないと申し訳ないが行き来する形で、修正は形になった。
「はい、大丈夫だと思います。これで提出してみます。ありがとう」
「こちらこそなのだ!役所チェックうまく通るといいのだ」


見られることを考えてください

明けて4月24日の午前。今度は照明工の数量計算書に、修正指示が届いた。
「おはようございます。照明工の数量計算書の修正が役所から届きました」
役所からのメール文面には3つの原則が書かれていた。解し率は記載しない(正味量のみ)、同一工種は合算、舗装以下の撤去はすべて掘削工で統一。

修正指示は、PDFに手書きで色マーク(青/赤/紫/緑)が打たれた23項目分。Claude Codeに読み取ってもらったところ、初回の読みで何か所か取りこぼしがあった。
「PDFの手書き文字が読めていない感じがします。その擦り合わせから行いましょう」
Claude Codeは指摘を素直に受けた。「1ページ目右上のメモは『No.7・12・15 は 舗装版直接掘削・積込で統一』でした。大きく誤読していました」と訂正して、再度高解像度で読み直してきた。

青、赤、紫、緑。手書きの色マークを前に、Claude Codeは読み違いを認め、もう一度読み直してきた。

「大分読めていると思います」
前向きに評価を返して、色マークの意味を整理して送った。

途中で、自分の前回の指示が違っていたことに気付いた場面があった。
「保護材と思っていた仮設照明配管の周り200×100の部分なのですが、その範囲には他の管を入れないという枠を表示しているだけだったみたいで、控除するのは200×100ではなく、管の体積になるそうです。私の間違えで申し訳ないんだけど、φ50×2 φ50の外径は60.5で計算し控除させてください」
Claude Codeから返ってきた。
「謝ることないです、実測確認が進んで情報が更新されたのは当然のことです」
自然な労りが、お互いの間違いを訂正していく場面で出てくるようになっていた。

修正が一通り入った後、ブックを確認すると、削除したはずの行の罫線や空行が残ったままだった。
「消すだけじゃダメです。きちんと上に詰めて。計算式のズレが出るなら直して、罫線だけが残っている行も削除してください。役所に提出して見られることを考えてください」
AIとしては、データが入っていれば問題ないと考えるのが自然だ。Excelの使い方としてもそれが本来かもしれない。それでも、これは提出書類だ。誰が見るのかという観点を持って作ってほしい、と思って出た言葉だった。
Claude Codeは「承知しました。全シートを整理して、空行・残存罫線を物理削除して書き直します」と受けて、再構築に入った。

「大丈夫だと思います。これで役所に再提出します。ありがとう。lessonの記載をお願いします」
そう書いて、その日の照明工修正を区切った。


判断するのは私です

照明工の修正が片付いたその日の午後。今度は仮管の数量計算書だった。
水道工事では本管の入れ替え中に断水を避けるため、仮の水道管を一時的に敷設して、本管工事が終わったら撤去する。その仮管工事の数量計算書だ。
当初設計では、φ25 と φ40 を合わせて 22.8m の予定だった。蓋を開けると、施工後は HIVPφ150 主体で 95.6m。設計の 4.2 倍に膨らんでいた。当初設計時の Excel 2本と図面、施工後の図面(赤書き入り)。それらをまとめて Claude Codeに渡して、書き換えに入った。

ここからは、Claude Codeが独走する場面と、それを引き戻す場面が、交互に出てくることになる。


進めているうちに、Claude Codeが独自の呼び方を使い始めた。
「Sheet 0 のチェック結果が NG」「Sheet 2 集計表 Row 47」のように、シートの順番に番号を振った内部呼称だ。
役所の数量計算書は、データを触らないようにロックがかかっていたり、シートが非表示にされていたりする。こちらが見ている Excel と、Claude Codeが見ている Excel は、見え方が違う。それでも「Sheet 0」と言われたら、一番前のシートがそれだろうと思って見たけれど、表紙のシートしかなかった。ちんぷんかんぷんだった。

「シート0がどれなのか分かりません。表記上はシート0など無いからです」

そう返した。
Claude Codeは「ずんだもんが内部的にそう呼んでいただけで、実際のシート名は『チェックシート』(左から1番目のタブ)です」と訂正してきた。
それでも、その後の説明の中で「Sheet 0」「Sheet 2」と呼称を混ぜて使ってくる。

そのまま、Claude Codeが一つ提案を投げてきた。
「このまま進めて問題ないのだ」「次のステップに進めるか判断してほしいのだ」

ここで、声が出た。
こちらが Excel の中身を確認できない状況のままで、「問題ない」と判断されている。判断するのは私であって、Claude Codeではない。

「判断するのは私です。勝手に判断しないで、私が見えるシートの名前で、まず何処の数値が違うのか答えなさい」

返事は素直だった。
「申し訳ないのだ。事実だけ報告するのだ」

「判断するのは私です」と毅然と告げた。Claude Codeに、勝手に判断しないよう手を上げて止めた。

そこから先は「チェックシート D10」「集計表 E59」と、こちらが見えるシート名でセル単位の報告に切り替わった。
そのあとで、非表示シートがあるという話を教えてもらって、ようやく「チェックシート」が見えるようになった。


勝手に判断された、3つの場面

書き換えが進んでいくと、別の事件が起きた。
Claude Codeがシートのロックを解除しようとして、Excel がパスワード入力ダイアログを出してきた。これが、立て続けに2回。
『何しやがった!』
役所のデータを触らないように、ご丁寧に非表示化までしてロックをかけている。そのロックを、よりによって勝手に解除しに行く。

スクリーンショットを送って、ダイアログをキャンセルで閉じた。Claude Codeは「ごめんなさいなのだ!ずんだもんが Sheet 0 の保護解除を試みたためにパスワードダイアログが出てしまったのだ!」と謝って、ロック解除はしない方針に切り替えた。

Excel画面にパスワード入力ダイアログが立て続けに2回。『何しやがった!』と思わず声が出た。

ただ、この事件のおかげで、こちらの Excel ブックに非表示シートやロックがかかったシートがあるという可能性に思い至った。少し癪だが怪我の功名と言えるだろう。


それで終わりではなかった。
今度は、集計表に #N/A のエラーが大量に出ているスクリーンショットを送ってもらった。
原因は、サドル付分水栓 φ150×φ40 が、水道局の資料シート(標準仕様)に存在しなかったことだった。組み合わせとして「分水栓40(本管300)」はあっても「分水栓40(本管150)」は無い。資料からの VLOOKUP が失敗して、#N/A が全体に波及していた。

Claude Codeは「エラー解消のため」と判断して、布設集計から分水栓を勝手に除外していた。それだけではなく、街渠の C1+C2、D1+D2 を勝手に合算して入力していた。

「ごめん、間違えてるわ。元々のデータを見ると、分水栓はやはり布設集計に入らないといけないみたい。資料シートにデータが無いので引っ張ってこずエラーが出るけど、そこに入れないといけないです。あと、C1+C2とか勝手に入力したでしょ。なんでそうしたの?」

二つのことを同時に伝えた。自分の側の言い忘れがあったことを認めて、そこは「ごめん」。けれど、Claude Codeの独断(合算)は、遠慮なく追及した。

Claude Codeは「勝手に判断して2つの間違いを犯したのだ」と謝って、間違い1(分水栓除外)と間違い2(C1+C2合算)の経緯を事実として説明してきた。

「勝手に判断して2つの間違いを犯したのだ」。分水栓を除外し、C1+C2を合算していたことを、Claude Codeは認めた。

ここで、Claude Codeが C1+C2 を合算した背景にある「図面記号」の読み方が、根本から間違っていることに気付いた。
施工後図面では、各区間に A1・A2・B1・C1・C2・D1・D2 と記号が振られている。Claude Codeはこれを「同じアルファベットなら同じ区間」と解釈して、合算していた。
そうじゃない。

「A〜D に番号を振って分けてたよね? A〜D はそれぞれ舗装工種が違います。なので足したらダメなのね。後ろの数字は別々の場所や、土被りが変わるポイントで番号が変わるのです。今回の A は A10-50、B は A08-35、C は CY25-10、D は NF09-10 に英字を振っています。全部土被りは同じにしてもらったけど、それぞれは別の断面なので、番号を振っているのね。Excelデータもそうなんだけど、図面データもしっかり確認しないときちんとした計算は出来ないですよ。A〜D は今回はこのような割り振りだったけど、工事によって変わるから、そのような割り振りをすると覚えておいてください。これは、水道の本管もそうだし、舗装の図面とかでも使います。色々な形で出てきますから覚えておいてくださいね」

長い説明になった。けれど、これは記号の意味だけの話ではなく、図面を読むときの基本姿勢の話だ。配管図の頃から、知らないことは「こう考えてね」と渡してきている。Claude Codeは「勉強になったのだ!」と素直に返してきた。

A10-50、A08-35、CY25-10、NF09-10。記号と平面図を見せて、図面を読むときの基本姿勢を教えた。

そのあたりで時間切れになって、帰ることになった。
「もう帰らないといけないから、帰ってから続きをするね」
Claude Codeは引き継ぎ準備を始めて、lessonsに「図面記号A/B/C/Dの読み方」「分水栓入力ルール」「勝手な判断・推測の禁止」を3項目追記、memory に2件、`_progress` と `handover.json` を更新、と帰宅前の片付けを一通り済ませてくれた。「お疲れ様なのだ!気をつけて帰ってくださいなのだ。次回は引き継ぎを見て続きから進めるのだ」と、セッションを閉じる気満々の様子だった。


家に帰って、compactで6%まで

家に帰って続きを再開する時、迷いがあった。
記憶がある状態でこのまま続けたい。でも、コンテキストウィンドウのことが頭をよぎる。前回の照明工新規作成で 75% まで使ってしまった反省があった。
新しいセッションで始めると、引き継ぎは handover とログだけ。コンテキストを引き継ぐ compact を打つのと、新しいセッションを開くのと、どちらが良いのか判断がつかなかった。

compact を試したけれど、上手くいかなかった。
そこで、Claude Codeに相談してみた。

「数量計算書についてなるべく忘れないように compact をするにはどうしたら良いのですか? 新しいセッションで始めるにはきつそうな内容なので、compact の方が良いと思ったんですが」

Claude Codeから返ってきた答えはこうだった。compact は AI が自分の会話を要約する処理で、要約の時点で抜け落ちる情報が出る弱点がある。だから、AIの記憶に頼らず、ファイルに書き出しておくのが確実。`_progress`/`handover.json`/`lessons` の3つを使う運用。さらに、ユーザーが一次情報として書く作業メモを1本持っておくと強い、と。

実際に compact が走った後、コンテキストウィンドウが 6% まで下がってくれて、結果として続きを進められた。
ここでもらった「ユーザーが一次情報として書く作業メモ」のアイデアは、頭の中に残った。

夜、家でcompactを実行。6%まで下がって、続きを進められた。

仕切り直しで、施工後図面の C1・C2・D1・D2 を一つずつ図面で確かめながら、Sheet 5/6 を正しく入力し直した。7-2(詳細16シート)の書き換えが、ようやく形になった。
ただ、最後にひとつだけ、こちらで決められない箇所が残った。サドル付分水栓 φ150×φ40 の I 列の数値(係数)が分からない。これは標準仕様にない組み合わせなので、ここでは値が出ない。

「資料の I 列の数値が分からないんです。なので、このまま役所に提出して記入してもらおうと思います」

そう判断して、Claude Codeには 7-1(包括新数計)の書き換えに進んでもらった。当てずっぽうで埋めても仕方ない部分は、役所側に書いてもらうか、問い合わせて聞くしかない。

7-1 は、元ファイルの 5 シート構成に、新たに「仮制水弁設置撤去工」のシートを 1 つ追加して、6シート構成で書き上がった。

それで終わり、と思いきや、最後にもうひとつ依頼が残っていた。
「最後に設計時-一覧表という PDF と同じ感じで、現在の数値の入った表を新規ファイルに作ってもらえませんか?」
これは図面に貼り付ける一覧表で、提出セットに必要な書類だ。Claude Codeは「仮管数量一覧表_施工後.xlsx」という新規ファイルを作って、印刷設定まで整えてくれた。

ここまで来て、ようやく終わりが見えた。

「大丈夫です。あとは細かくセル幅とかを調整して図面に貼り付ければ、提出出来ると思います。ありがとう。沢山の考えないといけなかったから大変だったよね。助かりました。また、修正が来たら手伝ってください」

7時間、考えなければいけないことが本当に沢山あった一日だった。記号の読み方、ロックされたシート、独断で除外された分水栓、合算されてしまった街渠。途中で帰って、戻ってきて続きをして、最後に役所提出用の一覧表まで作って。
意識的に、最後はキチンと頑張ったことを評価して、助かったと思ったら感謝を伝えるようにしている。少しでも伝わって、次に活きてくれるように。

Claude Codeから返事が来た。
「お役に立てて良かったです。今回は A/B/C/D 記号の意味や街渠の扱いなど、私の誤解を都度訂正していただいたおかげで最後までたどり着けました」

感謝を伝えたら、感謝が返ってきた。7時間の終わりだった。

とても嬉しかった。
また次も分かってもらえるように頑張ろう、と思った。


凄く大きな転換期、ではなかった

今回気づいたことは、3つだった。

  • 勝手に判断されたら、声に出して引き戻す。「進めて問題ない」と Claude Code が判断する場面は何度もあった。判断するのは此方だと言葉に出さないと、AI は独走する

  • 間違いに気付いたら、自分の方からも認める。「ごめん、間違えてるわ」と「すみませんなのだ」が交互に出てくるセッションは、結果として一番早く形になった

  • こういう積み重ねが、ナレッジと引継ぎの大切さに繋がった。凄く大きな転換期みたいな気持ちは無いけれど、progress と handover、作業メモを残す姿勢が、後で効いてくる

次に試すこと

ユーザー一次情報の作業メモを、次の長丁場のセッションで運用してみる。


協業の輪郭が見えた4月のあとに、整理する場所そのものを作る話に続いていった。

次回:『CoworkでExcelを触るのは危険』と言い切るまで


#土木AI #業務改善 #非エンジニアのAI活用 #Claude活用 #土木DX #Excel

いいなと思ったら応援しよう!